Complexité utile et complexité accidentelle

Réflexion technique sur la complexité utile et la complexité accidentelle et leur impact sur la durabilité des systèmes.

La complexité est souvent perçue comme quelque chose qu’il faudrait éliminer. Dans de nombreux projets, la simplification devient un objectif en soi, au point de considérer que toute forme de complexité traduit une mauvaise conception.

Pourtant, les systèmes backend, les applications métier et les outils internes contiennent inévitablement de la complexité. Une partie est nécessaire, tandis qu'une autre apparaît progressivement sans avoir été véritablement choisie.

Comprendre cette distinction est essentiel pour concevoir des systèmes qui restent stables dans le temps, comme expliqué dans Backend robuste et dans les systèmes sans abonnement .

Pourquoi certaines complexités sont-elles nécessaires ?

Certains problèmes sont intrinsèquement complexes.

Un système peut devoir gérer de nombreuses règles métier, des cas limites, des intégrations API et des contraintes externes qui ne peuvent pas être simplifiées davantage. Dans ces situations, la complexité n'est pas un défaut. Elle constitue une représentation fidèle de la réalité.

La complexité utile présente généralement des caractéristiques reconnaissables :

• elle est explicite
• elle est documentée
• elle reflète directement une exigence réelle
• elle reste compréhensible, même si elle est importante

Ce type de complexité ne peut pas être supprimé par une simple simplification du code, car il appartient au domaine du problème lui-même.

Pourquoi la complexité s'accumule-t-elle ?

À l’inverse, une grande partie de la complexité rencontrée dans les systèmes logiciels ne provient pas du problème à résoudre.

Elle apparaît par accumulation :

• des correctifs rapides devenus permanents
• des solutions locales ajoutées sans simplification ultérieure
• des couches introduites pour éviter de modifier un comportement existant
• des dépendances, outils ou services ajoutés pour résoudre des problèmes temporaires, comme évoqué dans Sécurité des données

Cette complexité n’a jamais été réellement conçue, elle est le résultat de décisions successives.

Elle rend les systèmes plus difficiles à comprendre sans apporter de valeur significative.

À long terme, cette accumulation conduit souvent à ce que l'on appelle une dette technique , qui ralentit les évolutions et augmente progressivement le coût de maintenance.

Pourquoi les deux sont souvent confondues

À mesure que la complexité augmente, il devient plus difficile de distinguer ce qui est nécessaire de ce qui ne l’est pas.

Les équipes finissent par accepter l’ensemble du système comme inévitable.
La simplification devient risquée, car il n’est plus clair quelles parties peuvent être réduites en toute sécurité.

À ce stade, les systèmes deviennent souvent difficiles à faire évoluer.

Les incidents deviennent également plus difficiles à diagnostiquer, comme illustré dans Problèmes backend .

La complexité accidentelle finit par masquer la complexité utile.

Comment simplifier un système sans perdre de fonctionnalités ?

Simplifier un système ne signifie pas supprimer des fonctionnalités ni réduire ses capacités.

Cela consiste plutôt à retirer les éléments qui n’expliquent plus le problème d’origine.

Cette démarche consiste souvent à revoir l'architecture plutôt qu'à multiplier les correctifs locaux, une approche également abordée dans API où l'organisation des échanges participe directement à la simplicité d'un système.

Lorsque la complexité utile reste visible et que la complexité accidentelle est limitée, les systèmes deviennent plus lisibles sans perdre en puissance.

Cette distinction permet d’éviter deux erreurs fréquentes :

• ajouter de la complexité pour anticiper des besoins hypothétiques
• simplifier au point de perdre un comportement nécessaire

Vous pouvez également explorer ces principes de deux façons, à travers une expérience interactive ou une visualisation animée, pour observer comment les choix d'architecture et l'ajout de nouvelles fonctionnalités peuvent influencer la complexité d'un système.

Pourquoi la lisibilité est-elle essentielle sur le long terme ?

Les systèmes les plus durables ne sont ni les plus simples, ni les plus sophistiqués.
Ce sont ceux dont la complexité correspond clairement au problème qu’ils cherchent à résoudre.

Lorsque chaque partie d’un système peut être reliée à une raison précise, la maintenance reste possible, même à mesure que le système grandit.

Cette cohérence facilite également la mise en place de mécanismes de sécurité applicative , qui deviennent plus simples à maintenir lorsque l'architecture reste lisible.

La complexité devient alors un choix intentionnel plutôt qu’une conséquence involontaire.
C’est cette clarté structurelle qui permet à un système de rester compréhensible au fil des années.

Cette clarté structurelle est ce qui permet de concevoir des systèmes backend, des applications métier et des outils internes réellement durables, sans dépendances inutiles ni complexité accumulée.

Cette approche rejoint également les principes présentés dans Pourquoi développer sans SaaS , où la réduction des dépendances constitue un choix d'architecture à part entière.

En savoir plus sur les systèmes sans abonnement