Développement guidé par la spécification : la pratique sur laquelle la catégorie a convergé

Tous les outils sérieux de code par IA ont livré la même fonctionnalité à environ un an d’intervalle, ce qui n’arrive presque jamais par accident.

En 2025, la question intéressante était de savoir à quel point les modèles devenaient bons. En 2026, la question intéressante est de savoir ce qu’on leur remet.

GitHub a publié Spec Kit. AWS a publié Kiro, un environnement de développement bâti autour de l’idée. BMAD-METHOD, OpenSpec et Tessl s’y sont chacun essayés. Cursor y est arrivé par les fichiers de règles. Martin Fowler a publié une comparaison des implémentations. Quand six équipes indépendantes convergent vers la même réponse en douze mois, elles ne se copient pas. Elles heurtent toutes le même mur.

Le mur a un nom désormais. Le correctif aussi.

Ce qu’est réellement le développement guidé par la spécification

Écrire les exigences, les contraintes et les critères de réussite avant qu’aucun code ne soit généré. Traiter ce document comme la source de vérité. Laisser l’agent construire contre lui.

C’est tout. Ce n’est pas une idée nouvelle : c’est de l’ingénierie des exigences, que le secteur a passé trente ans à faire mal avant de l’abandonner largement comme trop lente. Ce qui a changé n’est pas le concept. C’est l’économie.

Les spécifications étaient coûteuses à écrire et coûteuses à maintenir à jour, ce qui signifiait que la plupart des équipes écrivaient les grandes lignes et découvraient tout le reste en revue de code. C’était un compromis rationnel quand un développeur mettait de toute façon trois semaines à construire la fonctionnalité. Il a cessé de l’être quand la génération est devenue rapide, parce que désormais la spécification est la partie lente, et la partie lente est celle où vit tout le jugement.

Le mode de défaillance contre lequel il a été inventé

Les outils qui partent du prompt sautent entièrement la spécification. Vous décrivez un résultat, l’outil produit quelque chose qui y ressemble, et chaque décision que la description ne couvrait pas est prise silencieusement par le générateur.

Quelles décisions ? Celles qui s’avèrent compter. Si une adresse e-mail est unique, et unique par rapport à quoi. Ce qu’un compte résilié peut encore voir. Ce qui se passe quand deux personnes modifient le même enregistrement. Si cette liste a besoin d’une pagination avant d’avoir dix mille lignes.

Personne n’a posé ces questions, donc personne n’y a répondu, mais l’application a une réponse à chacune, choisie par déduction depuis un contexte qui n’a jamais inclus votre activité.

La même dynamique apparaît dans chaque outil qui saute l’étape de définition. C’est le mécanisme derrière le problème des 70 % : le progrès s’arrête non pas parce que le travail restant est difficile, mais parce qu’il est bloqué par une décision architecturale prise implicitement, des centaines de générations plus tôt, qui ne peut plus être changée sans démonter le système.

Les données sur ce qui arrive sans cela

Le rapport 2025 de DORA sur le développement logiciel assisté par IA est la lecture la plus claire disponible. 90 % des professionnels de la technologie utilisent désormais l’IA au travail et plus de 80 % estiment qu’elle a accru leur productivité. Et une adoption plus forte de l’IA est associée à une hausse du débit de livraison logicielle et à une hausse de l’instabilité de cette livraison, en même temps.

Plus rapides à livrer. Moins bons à maintenir les choses en marche. Les deux, ensemble.

L’analyse de GitClear en 2026 sur 623 millions de modifications de code montre la forme des dégâts. Par rapport à la référence de 2023 : blocs de code dupliqués en hausse de 81 %, copier-coller au sein d’un même commit passant de 9,4 % en 2022 à 15,7 % au premier semestre 2026, constructions qui masquent les erreurs en hausse de 47 %. Pendant ce temps, les appels de fonctions entre fichiers, le meilleur indicateur disponible de la réutilisation de code, en baisse de 35 %, et l’activité de refactorisation effondrée de 21 % des modifications en 2022 à 3,8 % en 2026.

Les développeurs sont désormais environ cinq fois plus susceptibles de copier-coller que de refactoriser. En 2022, ce rapport allait dans l’autre sens.

Rien de tout cela n’est un problème de qualité de modèle. C’est ce qui arrive quand la génération est bon marché et que la structure n’est le travail explicite de personne.

Les trois degrés d’engagement

Tout le monde n’entend pas la même chose par là, et les différences comptent en pratique. Le cadrage de Martin Fowler est le plus net que j’aie vu.

Spécification d’abord. Vous écrivez la spécification, vous générez depuis elle, puis vous maintenez le code à la main. La spécification pilote la construction initiale puis devient progressivement historique. Le plus facile à adopter, les garanties les plus faibles : six mois plus tard, le document décrit un système qui n’existe plus.

Spécification comme ancrage. La spécification et le code évoluent ensemble. On change la spécification, on régénère les parties concernées, on maintient les deux à jour. Plus de discipline, et le bénéfice est que le document reste digne de confiance.

Spécification comme source. La spécification est le seul artefact que vous modifiez. Le code est une sortie, comme un binaire compilé est une sortie : on ne le rapièce pas à la main. Les garanties les plus fortes, et le plus grand saut dans la façon dont une équipe travaille.

La plupart des équipes qui se disent guidées par la spécification pratiquent la spécification d’abord. C’est une véritable amélioration par rapport au prompt à l’aveugle, et c’est aussi la version qui se dégrade silencieusement.

Ce qui appartient à la spécification

Le test utile : si le générateur devait deviner, cela appartient au document.

• Le modèle de données. Entités, relations, cardinalité, ce qui rend un enregistrement unique, ce qui se passe à la suppression. C’est la section à plus forte valeur et celle qu’on saute le plus souvent.
• Les types d’utilisateurs et les permissions. Qui existe, ce que chacun peut voir et faire, ce qui se passe aux frontières.
• Les invariants. Les règles qui ne doivent jamais être violées, énoncées platement. Pas « gérer les erreurs élégamment » : c’est un souhait, pas une contrainte.
• Les critères de réussite. Comment vous saurez que la chose fonctionne, en des termes assez précis pour qu’un désaccord sur son bon fonctionnement soit tranchable.

Ce qui n’y appartient pas : les détails d’implémentation que le générateur choisit mieux que vous. Une spécification qui nomme des variables n’est pas une spécification, c’est du code avec un moins bon outillage.

La partie que tout le monde rate

Une spécification n’aide que si elle est applicable ailleurs que dans de la prose.

Si une contrainte ne vit que dans le document, c’est une suggestion. Le générateur l’a lue une fois et l’a peut-être honorée, ou non, dans le quatorzième fichier qu’il a touché. Les contraintes doivent finir quelque part où le système les vérifie : non-null et unique dans la base de données plutôt que dans un gestionnaire de formulaire, des types aux frontières plutôt que dans un commentaire, l’autorisation comme une politique que le système évalue plutôt qu’une condition que quelqu’un a pensé à écrire.

C’est la différence entre le développement guidé par la spécification comme pratique et le développement guidé par la spécification comme genre littéraire. Le document est la façon de décider. L’application est la façon de tenir la décision.

Comment savoir si vous le pratiquez vraiment

Quatre questions, inconfortables à dessein.

1. Quand quelque chose casse, corrigez-vous le code ou la spécification ? Si la réponse est toujours le code, vous en êtes au mieux à la spécification d’abord et le document est déjà périmé.
2. Une nouvelle recrue pourrait-elle lire la spécification et prédire le comportement du système ? S’il lui faut lire le code pour savoir, la spécification est un résumé plutôt qu’une source.
3. Y a-t-il quoi que ce soit dans la spécification que le système ne puisse pas violer ? Si toutes les règles sont de la prose, aucune n’est garantie.
4. Relisez-vous la spécification ou le diff ? Relire des milliers de lignes de code généré est du théâtre. Débattez du document tant que débattre est encore bon marché.

Où cela laisse les outils

La plupart des implémentations actuelles sont guidées par la spécification pour la génération de code spécifiquement. Elles produisent une spécification et génèrent une implémentation contre elle, et l’artefact sur lequel elles opèrent est une base de code.

La version plus exigeante étend la même logique à toute l’application (le modèle de données, la surface d’API, la frontière d’authentification, l’interface) de sorte que la spécification couvre non seulement ce que fait le code mais ce que le système est. C’est ce qu’est la phase de blueprint d’Archie, et c’est pourquoi je la décris comme du développement guidé par la spécification appliqué à toute la stack plutôt qu’à un dépôt. Périmètre différent, même principe : définir avant de générer.

Des gens raisonnables ne sont pas d’accord sur jusqu’où pousser. Personne de sérieux ne plaide pour revenir en arrière.

Ce que cela coûte

Charger le jugement en amont est plus lent la première semaine d’un projet et plus rapide toutes les semaines suivantes. Ce coût est réel et il est payé exactement au moment où l’élan semble le plus précieux, pendant qu’un concurrent livre quelque chose de visible. Il y aura des sprints où l’équipe qui a sauté cette étape aura l’air de gagner.

La discipline se dégrade aussi. Écrire des contraintes est moins plaisant que regarder une interface apparaître, et relire un document est moins satisfaisant que relire du code. Ces habitudes s’érodent sous la pression des délais, qui est la même pression qui les rend importantes.

Et cela ne s’applique véritablement pas à tout. Si vous validez une idée ce week-end et comptez jeter le résultat, jetez-le. Rien de tout cela ne vaut la peine pour un logiciel qui a deux jours d’espérance de vie.

La raison pour laquelle cela a pris

Chaque tentative précédente d’amener les équipes à écrire d’abord des spécifications a échoué, et pour une bonne raison : la spécification était un surcoût par-dessus le travail réel. Vous écriviez le document et il vous restait quand même à construire la chose.

Ce n’est plus le compromis. Désormais le document est l’essentiel du travail, et la construction est la partie bon marché. Six équipes indépendantes l’ont remarqué à un an d’intervalle parce que c’était la conséquence évidente du fait que le modèle est devenu bon.

La pratique n’a pas gagné un débat. L’économie a bougé sous elle.

Lectures liées

Le diagnostic d’origine : le vibe coding a trahi sa promesse. Où la catégorie est allée ensuite : ce qui vient après le vibe coding. Le même argument appliqué à des systèmes entiers : la conception logicielle AI-first depuis les premiers principes. Et la formulation plus ancienne de la même idée : arrêter d’écrire le logiciel deux fois.

Questions fréquentes

Qu’est-ce que le développement guidé par la spécification ? É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 et 2026 en réponse directe aux méthodes de travail parties du prompt qui sautent l’étape de définition.

En quoi diffère-t-il des cahiers des charges traditionnels ? Le concept est le même ; l’économie, non. Les spécifications traditionnelles étaient assez coûteuses pour que les équipes écrivent les grandes lignes et découvrent le reste pendant l’implémentation. Quand en rédiger une prend des heures au lieu de mois et peut être révisé à bas coût, cela vaut la peine de la terminer et de la maintenir à 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, ou soit le seul artefact que vous modifiez.

Quels sont les trois degrés du développement guidé par la spécification ? La spécification d’abord, où la spécification pilote la construction initiale et où vous maintenez le code à la main. La spécification comme ancrage, où spécification et code évoluent ensemble. La spécification comme source, où la spécification est la seule chose que vous modifiez et où le code est traité comme une sortie. La plupart des équipes qui la pratiquent en sont à la spécification d’abord.

Le développement guidé par la spécification ralentit-il les équipes ? Il déplace le travail plutôt que de l’ajouter. Les décisions d’une spécification sont prises soit délibérément en amont, soit implicitement par un générateur qui devine plus tard, et c’est du second chemin que viennent les reprises. C’est plus lent la première semaine et plus rapide ensuite.

Que faut-il mettre dans une spécification ? Tout ce que le générateur devrait autrement deviner : le modèle de données avec ses relations et ses règles d’unicité, les types d’utilisateurs et les permissions, les invariants qui ne doivent jamais être violés et des critères de réussite assez précis pour trancher un désaccord. Laissez de côté les détails d’implémentation que le générateur choisit mieux que vous.

Le développement guidé par la spécification est-il la même chose que la conception AI-first ? Le développement guidé par la spécification est la pratique consistant à définir avant de générer. La conception AI-first est l’ensemble plus large des conséquences architecturales, qui couvre aussi l’endroit où les contraintes sont appliquées, l’ordre dans lequel vous prenez les décisions et la conception pour des consommateurs agents en plus des humains.