Idée principale

La complexité d'un produit se lit d'ordinaire dans son code — taille des fichiers, nombre de couches, dépendances. C'est la partie la moins coûteuse. Une fonctionnalité livrée se paie ensuite chez l'utilisateur qui doit comprendre à quoi elle sert, dans les tickets de support qu'elle ouvre, dans la documentation qu'il faut écrire et maintenir, dans la cohérence d'une expérience qui se brouille à chaque ajout, et dans la capacité de l'organisation à expliquer ce qu'elle fabrique.

Ces postes-là ne s'accélèrent pas. Quand le code devient le maillon rapide, les goulots d'étranglement se déplacent vers la revue, la sécurité, le cadrage fonctionnel, l'intégration et l'absorption humaine — qui deviennent même plus critiques qu'avant, puisqu'ils reçoivent davantage.

Un produit devient donc illisible, pour ses utilisateurs comme pour ses équipes, dès qu'on ajoute des fonctionnalités plus vite qu'on ne comprend leur usage. Produire plus de code n'est pas produire plus de valeur ; c'est déplacer la facture vers des services qui ne l'ont pas provisionnée.

Pourquoi c'est important

Cela change ce qu'on compte quand on arbitre un ajout. Le coût de développement, désormais faible, cesse d'être un indicateur du coût total, et un chiffrage qui s'arrête au code sous-estime systématiquement ce qu'une fonctionnalité engage.

Cela donne aussi au support et à la documentation un statut d'alerte avancée : ce sont les premiers endroits où une complexité décidée ailleurs devient mesurable.

Nuances et limites

Toute complexité n'est pas subie par l'utilisateur. Une fonctionnalité invisible, activée par défaut et sans surface d'usage, peut alourdir considérablement le code sans rien coûter en adoption ni en support — la facture reste entière, mais à l'intérieur de l'équipe.

Et le raisonnement a une borne : une organisation qui ne livrerait que ce que le support absorbe sans effort livrerait peu, et laisserait un concurrent occuper la place. La question est la provision, pas l'abstention.

Questions ouvertes

• Comment estimer, avant de livrer, la charge d'adoption et de support d'une fonctionnalité, autrement qu'en constatant après coup les tickets qu'elle génère ?