Le constat vient de l'éditeur de la plateforme GitHub, qui a publié le 2 septembre 2025 une boîte à outils pour faire de la spécification l'artefact principal d'un projet, avant le code. Un logiciel qui agit seul a besoin d'instructions sans ambiguïté ; sans elles, personne ne peut dire si le résultat correspond au besoin réel. Un article de Microsoft, publié le 10 juin 2026, précise où l'ambiguïté s'installe : à chaque passation entre le besoin exprimé, l'exigence formulée, la conception retenue et le code livré, une part de l'information se perd. Le logiciel accélère l'exécution, il ne comble pas cette perte.

Un test simple révèle si la documentation tient encore debout

Un éditeur d'outils pour développeurs, Augment Code, propose un test dans un billet du 9 avril 2026 : supprimer le code source, ouvrir une session neuve, ne lui donner que les documents de spécification, et voir si le logiciel reconstruit un projet fonctionnellement identique. Les écarts qui apparaissent sont presque toujours des décisions implicites, un code d'erreur choisi par habitude, une bibliothèque préférée à une autre, restées dans la mémoire d'une personne. Une étude académique publiée en janvier 2026 sur 33 000 propositions de code rédigées par cinq agents sur GitHub, dont 600 analysées une par une, confirme l'échelle du problème : les propositions rejetées le sont d'abord pour du travail en double, des fonctionnalités non demandées ou un décalage avec les attentes de l'équipe, rarement pour une incapacité technique.

Ce que ça change concrètement pour une direction

Microsoft cite une équipe qui, en déplaçant ses règles du code vers une configuration écrite, a vu le temps d'intégration d'un nouvel arrivant tomber de deux à trois semaines à quelques jours. La raison tient en une phrase du même billet : la vitesse à laquelle un logiciel produit du code n'est plus ce qui limite un projet, c'est la clarté de ce qu'on lui a demandé. Un chantier peut produire du code très vite et rester bloqué des semaines parce que personne n'a écrit précisément ce qu'il devait faire.

Un document de spécification ne remplace pas la relecture. Un développeur indépendant qui l'a testée, dans un billet du 18 mars 2026, résume la limite : une spécification tenue à jour améliore la probabilité que le code livré soit conforme, elle ne la garantit pas ; la relecture ne disparaît jamais. Il met aussi en garde contre l'excès inverse : rédiger une spécification pour un correctif mineur coûte plus qu'il ne rapporte. La discipline vaut pour ce qui sera repris ou prolongé, pas pour tout.

La règle à en tirer : sur un chantier destiné à être repris ou prolongé, le document qui décrit précisément ce que le logiciel doit faire, pourquoi, et à quelles conditions on considère le travail terminé, mérite autant de soin que le code lui-même, parce que c'est lui qui reste lisible quand le code aura changé trois fois. La condition qui va avec : ce soin ne s'applique qu'aux chantiers voués à durer, jamais à un petit correctif ponctuel, où écrire la spécification coûterait plus cher que le problème qu'elle prétend résoudre.