Adieu le Vibe Coding: pourquoi les spécifications sont devenues le pilier du développement avec l'IA

En février 2025. Andrej Karpathy poste sur X ce qui deviendra une formule de référence : « vibe coding », l’art de donner une intention vague à un agent IA et de regarder le code sortir. Il ne s’en cache pas, il aime ça. Et pour des prototypes jetables, des side-projects sans exigences particulières (sécurité, durée, évolution, performance, etc.) c’est un étonnamment productif.

Le problème survient quand on essaie de faire la même chose sur quelque chose qu’on veut maintenir le plus longtemps possible.. J’ai vu des équipes laisser tourner un agent pendant une heure sur une fonctionnalité définie en deux lignes de prompt. Le code compilait. Les tests passaient. Et l’architecture avait silencieusement dérivé de ce qui avait été décidé deux semaines plus tôt.

L’IA code vite. Elle ne sait pas dans quelle direction aller si personne ne lui dit. Mais elle y va.

En résumé — Le Spec-Driven Development transforme les spécifications formelles en source unique de vérité avant toute ligne de code. À l’ère des agents IA autonomes, c’est la différence entre déléguer avec un mandat clair et déléguer à l’aveugle. Pertinent pour toute équipe qui travaille avec des agents de codage sur des projets destinés à durer. La limite principale : le coût amont d’une spec rigoureuse, qui exige de l’expertise pour anticiper les cas limites avant d’avoir écrit une seule ligne.

Photo : Brooke Cagle sur Unsplash

Le vibe coding : rapide, agréable, mais difficile à diriger

Le terme popularisé par Andrej Karpathy décrit une approche où l’intention remplace la spécification. On décrit ce qu’on veut en langage naturel, l’agent produit le code, on corrige au feeling. C’est agréable. C’est parfois étonnamment efficace.

Mais le vibe coding porte un défaut structurel : il n’y a pas de contrat. L’agent interprète, infère, comble les angles morts avec ce qui lui semble cohérent d’après son entraînement. Sur une fonction isolée, c’est rarement problématique. Sur une fonctionnalité qui touche cinq fichiers et qui doit respecter des invariants architecturaux définis il y a trois mois, c’est une source de dérive silencieuse.

Les agents actuels comme Claude Code ou GitHub Copilot CLI planifient, exécutent et itèrent avec un niveau d’autonomie qui n’existait pas il y a dix-huit mois. Cette autonomie est précisément ce qui rend les spécifications indispensables : plus l’agent agit loin de la supervision humaine, plus son point de départ doit être précis.

La spec comme contrat exécutable

Le Spec-Driven Development (SDD) n’est pas un concept nouveau. Il tire ses racines du Design by Contract d’Eiffel, des user stories de l’Extreme Programming, des spécifications formelles des méthodes agiles. Ce qui est nouveau, c’est le contexte dans lequel il s’applique.

Avec les agents IA, une spécification bien écrite devient un contrat exécutable : un document qui définit le « quoi » et le « pourquoi » avant que l’agent génère le « comment ». Elle contient les exigences fonctionnelles, les critères d’acceptation, les invariants architecturaux, les contraintes techniques. Tout ce qu’un développeur humain accumule en réunion de planning, mais que l’agent ne possède pas par défaut.

On peut y voir une analogie avec les Object Calisthenics formalisées en instructions persistantes que j’explique avoir adopté dans un précédent article : dans les deux cas, on formalise des règles qui guident la génération en amont plutôt que de corriger les dérives à posteriori. La spécification est la version macro de ce principe : pas des règles de style, mais des décisions d’architecture et d’intention.

Ce que ça change concrètement : la dérive architecturale devient détectable. Si l’agent propose quelque chose qui contredit la spec, c’est une exception qui remonte ; pas un bout de code qui se glisse en silence dans la codebase, créant une dette technique et de conception invisible.

Pourquoi les spécifications sont indispensables avec les agents IA ?

La réponse courte : parce que les erreurs d’intention coûtent plus cher que les erreurs de syntaxe.

Un LLM corrige un bug de syntaxe en trente secondes. Il ne corrige pas spontanément une décision architecturale absente de son contexte. Et il n’a aucun moyen de savoir qu’une fonctionnalité générée correctement en juin 2026 entre en conflit avec une contrainte décidée en mars, si cette contrainte n’est formalisée nulle part.

Trois problèmes concrets que le SDD adresse :

• La dérive architecturale : sans spec, chaque session agentique repart de zéro sur les décisions déjà prises. La spec porte la mémoire que l’agent n’a pas. Tout au mieux elle fait de la déduction à partir de l’existant. Tout au pire, elle laisse l’agent inventer une nouvelle architecture à chaque session.
• La régression silencieuse : les LLMs optimisent localement. Une spec avec critères d’acceptation permet de valider que la fonctionnalité livrée correspond à l’intention initiale, et pas seulement qu’elle compile.
• L’absence de traçabilité : versionner la spec avec le code, c’est expliquer pourquoi quelque chose a été construit ainsi, pas seulement comment. C’est la même logique que celle des Architecture Decision Records, appliquée à l’ensemble du processus de développement.

Comment un workflow SDD fonctionne-t-il en pratique ?

Le workflow décrit par le GitHub Spec Kit articule quatre phases distinctes :

1. Spécifier: Définir les objectifs fonctionnels et les critères d’acceptation : ce que le système doit faire, ce qu’il ne doit pas faire, les cas limites attendus.
2. Planifier: Traduire l’intention en architecture technique : stack, découpage des responsabilités, contraintes d’intégration.
3. Décomposer: Diviser le plan en tâches atomiques, chacune avec son critère de validation. Une tâche par fichier modifié est une bonne heuristique.
4. Implémenter: L’agent génère le code étape par étape, chaque implémentation validée contre la spécification correspondante.

Ce qui différencie ce workflow du planning habituel, c’est que la spec n’est pas un document qu’on écrit avant de coder puis qu’on oublie. Elle est le point de référence de chaque étape, y compris de la validation. Martin Fowler, dans son analyse des outils SDD, note que la valeur clé n’est pas dans le format de la spec, mais dans la discipline de la consulter avant chaque décision d’implémentation.

Quels outils structurent cette approche aujourd’hui ?

L’écosystème SDD pour les agents IA est encore en formation, mais trois approches se dégagent en 2026 :

GitHub Spec Kit est un toolkit open-source qui structure le workflow SDD pour GitHub Copilot, Claude Code et Gemini CLI. Il fournit des templates de spec, des scripts d’initialisation et des prompts système adaptés à chaque agent. C’est l’entrée la plus accessible pour une équipe qui part de zéro.

Kiro est l’IDE agentique d’AWS, lancé en preview en juin 2025. Il organise le développement autour d’un flux explicite Requirements → Design → Tasks, avec une interface visuelle pour gérer les spécifications. Son pari : rendre la spec la couche de première classe de l’IDE, pas un fichier Markdown qu’on consulte en parallèle.

Tessl pousse le principe encore plus loin avec le concept de « spec-as-source » : la spécification est la source de vérité, et le code en est un dérivé généré. Régénérer le code depuis la spec à chaque changement d’intention. C’est radical, et ça pose des questions ouvertes sur la place des contributions humaines directes dans la base de code.

Ces trois outils partagent la même conviction : l’intention formalisée avant l’implémentation. Les différences tiennent au degré de structure imposée et à l’intégration dans l’outillage existant.

Ce que le SDD n’est pas

Le Spec-Driven Development n’est pas du tout une promesse de perfection. Il n’est pas non plus une opportunité de réduire le nombre de développeurs ou de développeuses: la qualité de la spec détermine la qualité du code généré ; une spec vague produit un code vague. L’expertise humaine pour anticiper les cas limites, formaliser les contraintes et structurer l’intention est plus que jamais cruciale. Le SDD n’est pas un substitut à la réflexion humaine, c’est au contraire un amplificateur de cette réflexion.

Ce n’est pas non plus une solution aux problèmes organisationnels. Si les décisions d’architecture ne sont pas discutées et actées entre humains, aucun outil ne les inventera.

Sur le même sujet : L’IA développeur est devenue un agent · Object Calisthenics comme contrat machine · RTK : économiser 80 % de tokens en session agentique

Questions fréquentes

Le Spec-Driven Development est-il adapté aux petits projets ?

Oui, à condition d’adapter le niveau de formalisme. Un side-project solo n’a pas besoin d’une spec de trente pages : un fichier SPEC.md de vingt lignes qui décrit les objectifs, les contraintes techniques et les cas limites principaux suffit pour guider un agent efficacement. La règle pratique : la spec doit contenir ce qu’un nouveau développeur aurait besoin de savoir pour ne pas refaire les décisions déjà prises. Sur un projet exploratoire ou jetable, le vibe coding reste pertinent ; c’est dès qu’on pense à la maintenance que le SDD rapporte.

Quelle est la différence entre une spec SDD et un simple fichier README ?

Un README explique ce que le projet fait ; une spec SDD définit ce que le code doit faire, les contraintes qu’il doit respecter et les critères qui permettent de valider qu’il le fait. La spec inclut les invariants architecturaux (« ce service ne doit pas accéder directement à la base de données »), les cas limites attendus et les critères d’acceptation testables. Le README est une documentation statique ; la spec est un contrat actif qui guide chaque décision d’implémentation, y compris celles prises par un agent IA.

Le code généré par IA est-il de moins bonne qualité sans spécification ?

Pas nécessairement en termes de syntaxe ou de tests unitaires locaux : les LLMs actuels génèrent du code fonctionnel sur des tâches isolées sans spec. Le problème est systémique. Sur la durée, un code généré sans spec accumule des décisions implicites qui divergent progressivement des intentions de l’équipe. La dérive est invisible ligne par ligne ; elle n’est visible que quand on prend du recul. La spec ne rend pas le code « meilleur » à la ligne ; elle maintient sa cohérence avec l’intention à l’échelle du projet.

Faut-il versionner la spec avec le code ?

Oui, systématiquement. La spec versionnée avec le code permet de répondre à la question « pourquoi cette décision architecturale ? » en remontant dans l’historique git. C’est la même logique que celle des Architecture Decision Records : les décisions prises ont une date, un contexte, et parfois une alternative explicitement rejetée. Sans versionnement, la spec est un document vivant qui ment sur son propre historique ; et une spec qu’on ne peut pas faire évoluer tracée dans le temps n’est qu’un vœu pieux.