Un assistant capable de générer plusieurs centaines de lignes en quelques secondes déplace le goulot d'étranglement du développement. Le problème n'est plus d'écrire le code : c'est de savoir si le code écrit correspond bien à ce que l'équipe voulait. Trop souvent, le résultat « a l'air juste » — il compile, les tests passent — mais il résout discrètement le mauvais problème. Ce glissement porte un nom dans les cercles de développement assistés par IA : le drift du « vibe coding », cette dérive où l'on génère au fil de l'eau sans jamais avoir formulé l'intention. La parade tient en une inversion de priorité : écrire la spécification technique avant de coder, et la traiter comme la véritable source de vérité.
Le déplacement de la source de vérité
Pendant des décennies, le code a été considéré comme la source de vérité d'un logiciel : le comportement réel, c'est ce que fait le programme, point. Les spécifications, quand elles existaient, vieillissaient dans un coin et divergeaient du code au premier correctif. L'approche dite Spec-Driven Development (SDD) renverse ce rapport. Selon la documentation publiée autour des outils open source qui la portent, « l'intention est la source de vérité » et le code en dérive. On ne décrit plus l'existant après coup : on spécifie l'intention, puis on génère l'implémentation à partir de cette spécification.
Ce changement paraît subtil ; il est structurant. Quand l'intention est écrite, versionnée et revue, chaque génération de code peut être confrontée à un référentiel stable. Le développeur ne demande plus « écris-moi cette fonction » en espérant que le modèle devine le contexte : il fait produire un artefact intermédiaire — la spec — qu'il peut lire, corriger et approuver avant qu'une seule ligne ne soit écrite.
📖 Le vocabulaire
Le vibe coding désigne la génération de code au fil de la conversation, sans intention formalisée. Le Spec-Driven Development (SDD) formalise cette intention dans une spécification versionnée dont le code découle. La bascule tient en une phrase : passer de « le code est la source de vérité » à « la spec est la source de vérité ».
À quoi ressemble un flux spécifié
Les frameworks SDD apparus récemment convergent vers une séquence assez proche. GitHub Spec Kit, un boîtier open source sous licence MIT (version 0.12.4 publiée le 2 juillet 2026, plus de 118 000 étoiles sur son dépôt, compatible avec une trentaine d'assistants), articule le travail en étapes explicites : constitution (les principes qui gouvernent le projet), specify (les exigences et les critères), puis clarify et analyze pour lever les zones d'ombre, plan, tasks et enfin implement.
AWS Kiro, un fork de VS Code lancé le 14 juillet 2025 (à ne pas attribuer à un autre éditeur : c'est bien un produit AWS/Amazon), découpe le parcours en trois phases : Requirements — des user stories accompagnées de critères au format EARS ; Design — les interfaces, les schémas de base de données, les endpoints d'API ; Tasks — une séquence d'implémentation assortie de tests. D'autres approches, comme OpenSpec ou Tessl, insistent sur la spec vivante synchronisée avec le code au moyen de deltas, ou sur un registre de spécifications destiné à limiter les hallucinations d'API.
Le point commun de tous ces flux n'est pas l'outil : c'est la place de la revue humaine. Elle intervient à chaque jonction — après la spécification, après la clarification, avant l'implémentation. C'est là que se joue la différence entre un artefact généré et un artefact validé.
💡 Le mode plan, sans toucher au code
Au-delà des frameworks dédiés, certains assistants généralistes proposent un mode plan en lecture seule : l'outil décrit d'abord ce qu'il compte faire — fichiers touchés, étapes, ordre — et attend votre approbation avant d'écrire quoi que ce soit. Ce sas est précieux : il rend l'intention lisible et vous laisse rectifier le tir sur un plan plutôt que sur un diff déjà appliqué.
Anatomie d'une bonne spécification
Faire générer une spec est facile ; en obtenir une utile demande de savoir ce qu'elle doit contenir. Une spécification technique exploitable rassemble plusieurs blocs.
Exigences fonctionnelles sans ambiguïté
Ce sont les comportements attendus, décrits sans place pour l'interprétation : les flux nominaux, mais aussi les flux d'erreur, les cas limites, les contraintes et les dépendances. Une exigence qui ne dit rien du chemin d'échec est une exigence à moitié écrite.
Cas limites et exceptions
Le vide, le maximum, le timeout, l'absence de permission : ce sont précisément les situations qu'un modèle a tendance à ignorer si personne ne les nomme. Les expliciter dans la spec, c'est forcer l'implémentation à les traiter.
Contrats d'API et interfaces
Signatures, formats d'échange, schémas de données. C'est l'équivalent de la phase Design décrite par les frameworks : ce que les composants se promettent mutuellement.
Critères d'acceptation testables
Un bon critère d'acceptation est clair, mesurable, focalisé et testable — et il décrit le quoi, pas le comment. Il ne prescrit pas l'implémentation ; il définit la condition de réussite. C'est ce qui permet, plus tard, de vérifier que le code livré fait bien ce que la spec demandait.
Les non-buts
Dire ce que le système ne fera pas est aussi utile que dire ce qu'il fera. Les non-buts bornent le périmètre et coupent court à la sur-ingénierie, cette tendance du modèle à ajouter des capacités que personne n'a demandées.
Pour rédiger des exigences non ambiguës, une notation éprouvée aide beaucoup : EARS (Easy Approach to Requirements Syntax), formalisée en 2009 et adoptée dans l'ingénierie de grands industriels comme Airbus, Bosch, NASA, Rolls-Royce, Siemens ou Intel. Son gabarit se lit d'un trait : « While <précondition>, when <déclencheur>, the <système> shall <réponse> ». Cette structure force à nommer l'état, l'événement et la réaction attendue — exactement ce qui manque à une exigence vague, et exactement ce qu'un modèle a besoin de lire pour générer sans broder.
Pourquoi la revue humaine reste obligatoire
Une spécification produite par une IA est plausible. Elle n'est pas fiable pour autant, et c'est là que se concentre le risque. Plusieurs travaux sur la génération d'exigences par modèle de langage décrivent des défaillances récurrentes : la verbosité conduit à sur-définir, donc à figer un design rigide et sur-ingéniéré ; la perte de contexte engendre des exigences contradictoires ; les contraintes métier non écrites sont tout simplement oubliées ; et le non-fonctionnel — performance, sécurité, ergonomie — est fréquemment mal traité.
Plus insidieux encore : la nature même des sorties d'un modèle. Elles peuvent être « syntaxiquement valides, contextuellement plausibles et sémantiquement fausses ». Autrement dit, une spec bien tournée peut décrire, en toute élégance, le mauvais système. Aucun contrôle automatique ne rattrape cela : seul un relecteur qui connaît le métier repère qu'une contrainte réglementaire manque ou qu'un critère d'acceptation valide en réalité un comportement indésirable.
⚠️ « Tous les tests passent » n'est pas « conforme à l'intention »
Une suite de tests verte prouve que le code respecte les tests. Si les tests dérivent d'une spec lacunaire, ils valident une lacune. La conformité à l'intention ne se déduit pas d'un statut CI : elle se vérifie en confrontant le résultat à ce que l'équipe voulait vraiment — travail humain, non automatisable.
La logique économique renforce l'argument. Il est admis, en ingénierie logicielle, qu'un défaut coûte de plus en plus cher à mesure qu'il est découvert tard — l'écart entre une correction au stade des exigences et une correction en production se compte en ordres de grandeur (de l'ordre de 10× à 100× selon les estimations, dont l'exactitude chiffrée reste discutée). Une heure passée à relire une spec est rarement mieux investie qu'ailleurs.
Coder d'abord, ou spécifier d'abord
Le contraste entre les deux approches se lit dans leurs trajectoires. Coder d'abord, c'est demander directement l'implémentation, obtenir un résultat crédible, puis découvrir au fil des itérations que l'intention réelle n'a jamais été fixée : chaque relance ajoute son propre écart, et le drift s'installe. Spécifier d'abord, c'est produire un artefact stable — la spec — que l'on relit, corrige et versionne, avant d'en dériver un code confrontable à ce référentiel.
Ce cadre s'articule naturellement avec deux gestes voisins que l'IA outille aussi. Avant de spécifier une évolution, il faut souvent comprendre une base de code existante avec l'IA pour ancrer la spec dans le réel plutôt que dans une reconstruction hypothétique. Et une fois le code livré, le mouvement se prolonge lorsqu'on entreprend de documenter son code avec l'IA : la documentation devient le miroir de la spec, non un supplément qui diverge. Sur le plan des principes, cette bascule rejoint l'idée développée côté fondamentaux — spécifier avant de générer : la spec est l'artefact — et le rappel salutaire qu'un prototype n'est pas une mise en production : une spec plausible ne dispense jamais de l'épreuve du réel.
🎯 Le réflexe à installer
Avant chaque tâche non triviale : écrivez l'intention d'abord. Formulez les exigences en EARS, listez les cas limites et les non-buts, posez des critères d'acceptation testables, versionnez la spec, faites-la relire — puis seulement, générez. Le code devient une dérivée que l'on vérifie, pas un pari que l'on espère.
Ce que cette méthode change, concrètement
Pour le développeur, spécifier d'abord transforme la génération en un dialogue vérifiable : on approuve un plan avant un diff. Pour le tech lead, la spec versionnée devient l'objet de revue le plus rentable de la chaîne — celui qui, corrigé tôt, épargne les corrections tardives. Pour le chef de projet produit, l'intention cesse d'être un implicite dans la tête des gens : elle est écrite, opposable, et sert de contrat entre le besoin métier et l'implémentation.
Aucun de ces bénéfices ne se déclenche automatiquement en installant un framework. Spec Kit, Kiro, OpenSpec ou Tessl fournissent la structure ; ils ne fournissent pas le jugement. La valeur d'une spécification tient à la qualité de ce que l'équipe y écrit et de la manière dont elle la relit. L'outil accélère la mise en forme ; il ne remplace pas la décision de savoir ce que le système doit — et ne doit pas — faire.
📖 Encadré honnêteté
L'approche décrite ici (Spec-Driven Development, notation EARS) et les outils cités (GitHub Spec Kit, AWS Kiro, OpenSpec, Tessl) sont sourcés et vivants à la date de publication. En revanche, la qualité de votre spécification dépend entièrement de votre relecture et de votre connaissance métier : nous ne spécifions pas votre projet à votre place, et aucun modèle ne devine les contraintes que vous n'avez pas écrites. Les gains d'efficacité annoncés par les éditeurs n'ont pas été vérifiés indépendamment et ne figurent pas ici.
Pour aller plus loin
La bascule vers « l'intention comme source de vérité » est l'un des changements de fond les plus concrets qu'apporte l'IA au développement. Pour suivre son évolution, les outils qui la portent et les pratiques qui se stabilisent, abonnez-vous à la newsletter AISkillsPro et consultez l'Atlas IA 2026, notre cartographie des outils et méthodes de développement assisté par l'intelligence artificielle.