Le coût caché des décisions techniques

Le prix d’une décision technique n’est presque jamais celui de la facture.

C’est ce que la décision fait à toutes celles qui viennent après

Prenez un framework choisi parce que l’équipe le connaissait. Le coût visible est nul: pas de formation, pas de recrutement. Le coût caché apparaît deux ans plus tard, quand plus personne ne veut rejoindre un projet sur une stack que le marché a quittée, et que chaque estimation de migration commence par «il faudrait d’abord».

Prenez une base de données partagée entre deux services, choisie parce que c’était plus rapide qu’une API. Le coût visible est une semaine gagnée. Le coût caché, c’est que les deux services ne pourront plus jamais être déployés, dimensionnés ou modifiés indépendamment, et que chaque changement de schéma est désormais une négociation.

Prenez une bibliothèque ajoutée pour gagner un après-midi. Le coût visible est un après-midi. Le coût caché est une dépendance à mettre à jour, une vulnérabilité à suivre, une montée de version qui casse le build un vendredi.

Aucun de ces choix n’est mauvais en soi. Ce qui les rend chers, c’est qu’ils ont été pris comme s’ils étaient gratuits, sans que personne ne pose la seule question qui compte: qu’est-ce que cela rend plus difficile plus tard, et qui paiera ?

J’en suis venu à demander trois choses à toute décision technique qui survivra au sprint. Nommer l’option à laquelle on renonce. Nommer le moment où l’on voudrait revenir en arrière. Écrire les deux là où la prochaine personne les trouvera.

Cela prend dix minutes, et c’est le travail d’architecture le moins cher que je connaisse