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 réels 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 durables, comme expliqué dans les systèmes techniques autonomes.

Complexité utile

Certains problèmes sont intrinsèquement complexes.

Un système peut devoir gérer de nombreuses règles métier, des cas limites ou des contraintes externes qui ne peuvent pas être simplifiés davantage. Dans ces situations, la complexité n’est pas un défaut. Elle est 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.

Complexité accidentelle

À 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 ajoutées pour résoudre des problèmes temporaires

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.

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.

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

Simplifier sans réduire les capacité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.

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

Une question de lisibilité à 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.

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 construire des systèmes réellement durables, sans dépendances inutiles ni complexité accumulée.

Voir comment cela se traduit concrètement → systèmes techniques autonomes