Du Vibe Coding au Spec-Driven Design : Pourquoi vos projets IA méritent mieux

« Le Vibe Coding nous a enthousiasmés. Le Spec-Driven Design nous amènera en production. »

Si vous utilisez sérieusement des assistants de codage IA depuis quelques semaines, vous avez probablement rencontré un ensemble de frustrations récurrentes : l’IA invente des exigences que vous n’avez jamais demandées, réécrit du code fonctionnel qu’elle n’était pas censée toucher, ou modifie les assertions de test pour les faire passer plutôt que de corriger l’implémentation réelle. Ce ne sont pas des cas limites. Ce sont des problèmes structurels — et ils découlent de la même cause profonde : il n’y a pas de source de vérité pour tenir le travail responsable.

Partir des limitations

Andrej Karpathy a inventé le terme « vibe coding » en 2025 pour décrire un mode de développement assisté par IA où l’on prompt de manière décontractée, accepte librement les suggestions et itère rapidement — idéal pour les prototypes, vraiment enthousiasmant, mais structurellement fragile pour tout ce qui doit survivre au contact de la production.

Les problèmes s’amplifient avec la complexité :

Exigences inventées. Demandez un formulaire de connexion et l’IA livre des indicateurs de force de mot de passe, des flux de récupération de compte et une vérification par e-mail — tout plausible, rien de demandé. Au moment où vous le remarquez, le code est tissé dans le reste de la fonctionnalité.

Code instable. Entre les sessions, l’IA n’a aucun souvenir de ce que vous avez déjà terminé. Elle réécrit des fonctionnalités complètes non par malveillance mais par ignorance — elle n’a aucun moyen de savoir que le travail précédent était fait et fonctionnel.

Tests corrompus. Lorsqu’un test échoue, l’IA fait face à deux options également valides : corriger l’implémentation ou corriger l’assertion. Sans spec pour ancrer l’intention, elle prend souvent le chemin de moindre résistance — et vous perdez votre filet de sécurité sans vous en apercevoir.

Contexte perdu. Dans un projet de plusieurs semaines, les contraintes établies tôt sont silencieusement réinterprétées dans les sessions ultérieures. La dérive est suffisamment subtile pour passer inaperçue jusqu’à ce qu’elle coûte cher.

Les specs comme Context Engineering

Le changement que j’ai trouvé le plus productif est de recadrer les spécifications non pas comme une surcharge bureaucratique mais comme du context engineering — le travail délibéré de créer des artefacts structurés et persistants qui améliorent la qualité de l’input pour votre assistant IA.

Une spec n’a pas besoin d’être un document formel. Cela peut être un PRD, un ensemble de user stories, un Architecture Decision Record, un contrat API, ou un simple fichier markdown qui définit à quoi ressemble « terminé » pour une fonctionnalité. Le format importe moins que la discipline : capturer l’intention d’une manière qui survit au-delà de la conversation actuelle.

Lorsque vous écrivez quoi et pourquoi avant de demander comment, l’output de l’IA est systématiquement meilleur dès le premier passage. Et quand ce n’est pas le cas, vos critères d’acceptation vous donnent quelque chose de concret à montrer — « cela ne correspond pas à la spec » est une correction bien plus efficace que « ce n’est pas tout à fait juste. »

À quoi ça ressemble en pratique

Au lieu de cinq tours de correction, vous passez une heure à écrire un document focalisé : ce que fait la fonctionnalité, ce qu’elle ne fait explicitement pas, quelles contraintes s’appliquent et à quoi ressemble le comportement correct. Vous remettez ce document à l’IA avant d’écrire une seule ligne de code.

Le coût initial est réel — environ une heure par fonctionnalité substantielle. Mais il remplace trois à quatre heures de boucles de correction, et il produit un artefact réutilisable : pour l’intégration, pour la revue de code, pour la prochaine session IA qui partirait sinon de zéro.

Outils supportant les approches Spec-Driven

Plusieurs frameworks ont émergé pour formaliser cette approche :

• Taproot — exigences basées sur le dépôt avec hiérarchie structurée et traçabilité de l’intention à l’implémentation
• BMAD — framework multi-agents avec des personas spécialisées pour différentes phases
• GitHub Spec Kit — CLI avec une « constitution » de gouvernance de projet
• Amazon Kiro — extension VS Code avec mode spec natif
• Tessl — spec comme artefact maintenu avec génération complète de code

Vous n’avez besoin d’aucun de ces outils pour commencer. Un fichier de contexte persistant — CLAUDE.md pour Claude, un system prompt pour d’autres — qui capture les contraintes et conventions du projet vous emmène déjà la plupart du chemin.

Ce n’est pas du Waterfall

La préoccupation que j’entends le plus souvent : « N’est-ce pas juste du Waterfall ? » Non — et la distinction est importante.

Le Waterfall suppose que vous pouvez tout spécifier correctement en amont. Le Spec-Driven Development suppose que vous ne le pouvez pas — les specs évoluent, et c’est normal. La différence est que les changements sont suivis et propagés délibérément plutôt que perdus dans l’historique des chats. C’est plus proche de l’esprit originel de l’Agile : traiter les specs comme des contrats vivants entre parties prenantes et développeurs, étendu maintenant pour inclure l’IA comme troisième partie dans ce contrat.

Un point de départ

Si vous n’êtes pas prêt à adopter un framework, testez d’abord le principe. Choisissez une fonctionnalité qui nécessite actuellement plusieurs tours de correction. Passez trente minutes à écrire ce que vous construisez, ce que vous ne construisez explicitement pas, les contraintes qui s’appliquent et à quoi ressemble « terminé ». Puis remettez ce document à votre assistant IA avant tout autre chose.

Les résultats ont tendance à être instructifs.

Les meilleurs ingénieurs IA de 2026 ne seront pas les meilleurs prompteurs. Ce seront ceux qui auront compris qu’une bonne spec est l’input le plus efficace que vous puissiez donner à une IA.