Arrêter d'écrire le logiciel deux fois : le développement guidé par la spécification et la fin des réécritures

Pourquoi le logiciel a toujours été écrit deux fois, une fois en spécifications et une autre en code, et pourquoi cette seconde écriture est enfin en train de disparaître.

Dans le développement logiciel, quand il est bien fait, nous devons écrire le logiciel deux fois : d’abord en spécifications détaillées qui expliquent exactement ce que le logiciel doit faire, puis à nouveau en code qui donne vie à ces spécifications. Mais voici une vérité dure : c’est rarement bien fait la première fois.

Le processus se casse souvent parce que produire des spécifications exhaustives prend du temps et que les équipes capturent rarement tous les détails nécessaires en amont. Cela produit des lacunes, des hypothèses et des reprises coûteuses. Résultat : les projets logiciels dépassent souvent leur budget, manquent leurs délais et laissent tout le monde frustré.

Les coûts cachés d’écrire le logiciel deux fois

Pour comprendre pourquoi écrire le logiciel deux fois est nécessaire mais rarement bien fait, décomposons les deux phases.

1. La première écriture : des spécifications en langage naturel

La première fois que le logiciel est écrit, nous n’écrivons pas de code du tout. Il s’agit de produire des exigences, des récits utilisateur et des documents de conception, rédigés en langage naturel. C’est là que les équipes décrivent comment le logiciel doit fonctionner, ce que les utilisateurs peuvent faire et à quoi l’expérience doit ressembler.

Mais voici le problème : aucune équipe n’a jamais le luxe d’écrire tous les détails. Les responsables produit doivent souvent se précipiter pour tenir des calendriers agressifs, et certains projets n’emploient même pas de responsable produit professionnel. Ils esquissent les grandes lignes, mais des fonctionnalités et des interactions clés passent à la trappe. Comme le disait Steve Jobs, « les grands produits sont faits de 5 000 petites décisions », or dans la plupart des projets nous ne prenons pas ces décisions en amont. Elles sont laissées à l’interprétation ultérieure des développeurs, ce qui mène à la seconde étape.

2. La seconde écriture : traduire les spécifications en code

Une fois les spécifications transmises, les ingénieurs sont chargés de transformer ces descriptions en code fonctionnel. Mais quand la première « écriture » est incomplète, les développeurs sont contraints d’utiliser leur imagination pour combler les vides. Des hypothèses sont faites, et si les ingénieurs maîtrisent peut-être bien la technologie, ils n’ont pas forcément l’image complète de la vision du produit.

C’est là que les problèmes apparaissent :

• Les détails manquants créent de la friction : quand les équipes produit ne spécifient pas une fonctionnalité ou un cas d’usage important, les développeurs doivent deviner ou improviser. Le résultat est souvent une fonctionnalité qui ne répond pas aux attentes.
• Les hypothèses créent des reprises : quand les développeurs comblent les vides, ils peuvent construire des fonctionnalités d’une manière qui ne correspond pas à la vision du produit, provoquant d’énormes reprises plus tard dans le projet.
• Le renvoi de responsabilité devient inévitable : à mesure que les délais glissent et que les budgets dérapent, les équipes se rejettent la faute. Les équipes produit reprochent à l’ingénierie de « ne pas comprendre », tandis que les ingénieurs pointent le produit pour des spécifications floues.

Il en résulte une cascade de problèmes qui mène à des calendriers manqués, des budgets dépassés et des résultats insatisfaisants. L’étude CHAOS du Standish Group documente depuis des années que la majorité des projets logiciels dépassent leur budget et manquent leurs dates de livraison. Une étude de McKinsey avec l’université d’Oxford a constaté que les grands projets informatiques dépassent en moyenne leur budget de 45 % et leur calendrier de 7 %, tout en livrant 56 % de valeur en moins que prévu, et que 17 % des grands projets informatiques se déroulent si mal qu’ils menacent l’existence même de l’entreprise.

Manifestement, quelque chose dans ce processus est cassé.

La pratique a désormais un nom

Le secteur a fixé un terme pour cela pendant que la plupart des gens débattaient de prompts : le développement guidé par la spécification. Écrire d’abord les exigences, les contraintes et les critères de réussite. Traiter cette spécification comme la source de vérité. Laisser l’agent construire contre elle.

GitHub a publié Spec Kit. AWS a publié Kiro. BMAD-METHOD, OpenSpec et Tessl s’y sont tous essayés. Martin Fowler l’a documenté. La convergence n’est pas une coïncidence : c’est ce qui arrive quand toute une catégorie découvre le même mode de défaillance au même moment.

Et le mode de défaillance est celui décrit plus haut. Les outils qui partent du prompt sautent entièrement la première écriture. Ils vont droit à la seconde, en devinant chaque décision que la spécification n’a jamais prise. Ce qui va très bien pour une démonstration et est ruineux pour un produit.

Le développement guidé par la spécification n’élimine pas la première écriture. Il fait de la première écriture la seule qui requiert du jugement humain.

La nouvelle première écriture : des spécifications que l’on peut vraiment finir

Voici ce qui change. La raison pour laquelle personne n’écrivait de spécifications complètes n’a jamais été le manque d’envie : c’était que le travail était trop lent pour être justifiable. Des semaines de découverte pour produire un document qui périmait au contact du premier sprint. Alors les équipes écrivaient les grandes lignes et laissaient les 5 000 petites décisions être découvertes plus tard, une interprétation à la fois.

Quand rédiger une spécification prend des heures au lieu de mois, l’arithmétique s’inverse. Vous pouvez vous permettre d’être exhaustif. Exigences fonctionnelles, design visuel, modèle de données, cas limites : capturés avant que quiconque n’ouvre un éditeur, et assez bon marché pour être révisés quand vous apprenez quelque chose.

Cette dernière partie compte. Une spécification qui ne peut pas être révisée à bas coût devient un mensonge dès l’arrivée de la réalité. C’est le même instinct qui pousse à construire API-first : prendre correctement les décisions porteuses avant que quiconque n’écrive un écran, et le reste suit.

La nouvelle seconde écriture : de la génération de code, pas de la traduction

Une fois la spécification complète, la seconde écriture cesse d’être un problème de traduction. Elle devient un problème de génération. Des langages standard (JavaScript, TypeScript, Python). Des frameworks standard (React, Next.js). Du vrai code, dans les formes que les ingénieurs connaissent déjà, dérivé d’un document qui a déjà pris chaque décision.

La différence n’est pas que les développeurs travaillent plus vite. C’est qu’ils cessent de faire la partie qui n’a jamais été de l’ingénierie : la reformulation mécanique de décisions que quelqu’un d’autre avait déjà prises.

Ce qui change en aval

Trois choses changent d’un coup :

1. La première écriture est enfin terminée : quand le travail de spécification coûte des heures plutôt que des mois, les équipes peuvent se permettre de prendre les petites décisions en amont au lieu de les découvrir en revue.
2. Personne ne comble les vides : du code généré depuis une spécification complète n’exige de personne de deviner ce que l’équipe produit voulait dire. C’est toujours de la devinette que venaient les défauts.
3. Les reprises cessent de se composer : l’intention et l’implémentation partent alignées. Ce qui était une réécriture devient une modification de la spécification.

L’avenir de l’écriture logicielle : le langage naturel

Depuis que quiconque livre du logiciel, le métier exigeait de l’écrire deux fois : une fois en langage naturel, une autre en code. Cette seconde écriture n’a jamais été la partie qui avait de la valeur. C’était le péage que nous payions parce qu’il n’y avait pas d’autre route.

C’est le geste autour duquel s’organise la prochaine génération de constructeurs d’applications par IA : la clarté avant le code. Décrire l’application comme un blueprint, obtenir la bonne architecture, laisser le code être généré contre elle. Pas un raccourci qui contourne le travail de définition : une raison de le faire enfin correctement.

Il existe une autre voie désormais. Le logiciel était censé n’être écrit qu’une fois.

Lectures liées

Le guide complet de la pratique : le développement guidé par la spécification. Les raisons pour lesquelles la génération partie du prompt a sauté cette étape sont couvertes dans le vibe coding a trahi sa promesse, et ce qui la remplace dans ce qui vient après le vibe coding.

Questions fréquentes

Qu’est-ce que le développement guidé par la spécification ? Le développement guidé par la spécification consiste à écrire les exigences, les contraintes et les critères de réussite avant qu’aucun code ne soit généré, et à traiter cette spécification comme la source de vérité contre laquelle l’agent d’IA construit. Il a émergé en 2025 en réponse directe aux méthodes de travail parties du prompt qui sautent entièrement l’étape de définition.

En quoi le développement guidé par la spécification diffère-t-il de la rédaction d’un cahier des charges traditionnel ? Le document repose sur la même idée ; l’économie, non. Les spécifications traditionnelles étaient assez coûteuses pour que les équipes écrivent les grandes lignes et découvrent le reste en revue de code. Quand une spécification prend des heures plutôt que des mois et peut être révisée à bas coût, elle vaut la peine d’être terminée, et d’être maintenue à jour.

Quels outils prennent en charge le développement guidé par la spécification ? GitHub Spec Kit, AWS Kiro, BMAD-METHOD, OpenSpec et Tessl sont les implémentations nommées, et Cursor en prend en charge une version plus légère via les fichiers de règles. Ils diffèrent surtout par la force du lien entre la spécification et le code : selon qu’elle pilote la génération une fois, évolue en parallèle du code, ou soit le seul artefact que vous modifiez.

Le développement guidé par la spécification ralentit-il les équipes ? Il déplace le travail, il ne l’ajoute pas. Les décisions capturées dans une spécification sont des décisions que quelqu’un prend de toute façon : soit délibérément en amont, soit implicitement par un développeur ou un modèle qui devine plus tard. C’est du second chemin que viennent les reprises.

Qu’arrive-t-il aux développeurs si le code est généré depuis des spécifications ? La reformulation mécanique des décisions de quelqu’un d’autre disparaît. Le jugement sur l’architecture, les compromis, la justesse et ce qu’il ne faut pas construire, non. Ce furent toujours les parties qui exigeaient un ingénieur.