Développement guidé par les spécifications vs Vibe Coding : Waterfall ?

Les spécifications comme source de vérité, ou lente cérémonie ?

Sommaire

Le développement piloté par les spécifications (Spec-Driven Development) a fait son entrée en 2026 comme la réponse sérieuse des développeurs à la dérive du « vibe coding ».

L’argument est simple : les agents IA produisent des résultats de meilleure qualité et plus cohérents lorsqu’ils implémentent à partir d’une spécification revue, plutôt que d’un prompt improvisé. Difficile de discuter de ce point en théorie.

En pratique, Hacker News l’a surnommé « Waterfall Strikes Back » (Le retour du cycle en cascade).

Les deux camps ont un point.

Développement piloté par les spécifications face au Vibe Coding

Le cas pour le SDD dans un monde du Vibe Coding

Le Vibe coding – la pratique consistant à écrire un prompt vague et à itérer sur ce que l’agent IA produit – fonctionne remarquablement bien pour les travaux petits, exploratoires et jetables. Pendant les six premiers mois de 2025, c’était le modèle de codage IA dominant. Les développeurs livraient des scripts, des prototypes et des outils simples plus rapidement que jamais.

Puis les projets ont grandi. Les fonctionnalités multi-fichiers ont commencé à dériver. Les contraintes établies lors de la première session étaient oubliées à la troisième. Les hypothèses de sécurité étaient abandonnées. Les décisions architecturales changeaient en cours de route parce que l’agent n’avait pas de mémoire durable de l’intention.

Le développement piloté par les spécifications (SDD) est apparu comme la réponse disciplinée. L’affirmation centrale : faire de la spécification l’artefact central, et non du prompt. Écrire d’abord les exigences, une conception et un plan de tâches. Laisser l’agent implémenter à partir de ces artefacts, une tranche à la fois. Garder la spécification versionnée et à jour.

GitHub Spec Kit, Kiro, les flux de travail SDD de Claude Code et BMAD, ainsi que d’autres squelettes communautaires comme Superpowers, sont toutes des implémentations de cette idée. Les outils sont réels. L’intérêt est réel. La réaction en chaîne l’est aussi.

Ce que le Vibe Coding fait bien

Avant de rejeter le vibe coding, il est utile d’être précis sur ce qu’il fait bien.

Prototypes exploratoires. Lorsque vous ne savez pas exactement ce que vous voulez construire, le chemin le plus rapide est de construire quelque chose de rudimentaire et d’y réagir. Le SDD exige de savoir quoi spécifier. Si vous ne le savez pas encore, les spécifications sont prématurées.

Expérimentations d’interface utilisateur. La mise en page visuelle et le ressenti des interactions sont difficiles à spécifier à l’avance. Le vibe coding vous permet de voir rapidement des options, d’en éliminer la plupart et de converger vers quelque chose qui a réellement le bon ressenti. Un document de exigences ne vous est d’aucune utilité ici.

Automatisation jetable. Des scripts ponctuels, des tâches d’extraction de données, des assistants de migration – ceux-ci n’ont presque jamais besoin d’un document de conception. Le coût d’une légère erreur est faible. Le coût d’un processus lent et cérémoniel est réel.

Rétroaction rapide. Lorsque vous avez besoin d’apprendre quelque chose rapidement – cette API fonctionne-t-elle comme je le pense ? – le vibe coding réduit la boucle d’apprentissage à quelques minutes. Le SDD la ralentirait sans aucun bénéfice.

L’erreur consiste à prendre les modèles de succès de ces contextes et à les appliquer à des fonctionnalités de production avec de vraies contraintes, de vrais utilisateurs et de vraies conséquences en cas d’erreur.

Où le Vibe Coding échoue

Le vibe coding se dégrade prévisiblement lorsque la portée et les enjeux augmentent.

Modifications multi-fichiers. Dès qu’une fonctionnalité touche cinq fichiers ou plus, la fenêtre de contexte de l’agent commence à perdre le fil des invariants. Sans document de conception, chaque prompt doit rétablir un contexte qui avait été établi puis oublié lors d’une session précédente.

Dérive architecturale. Sans objectifs négatifs explicites (non-goals), les agents implémentent des choses. L’agent ajoute une couche de cache parce que cela semble raisonnable. Trois sessions plus tard, l’hypothèse de cache est intégrée au modèle de données et sa suppression est coûteuse.

Contraintes oubliées. « Seuls les utilisateurs authentifiés peuvent déclencher ceci » est une phrase dans un document de exigences. Dans une session de vibe coding, c’est quelque chose que vous avez mentionné une fois lors de la première session et que l’agent ne se souvient plus lors de la quatrième session lorsqu’il écrit la nouvelle extrémité (endpoint).

Hypothèses de sécurité cachées. Les règles d’autorisation, les limites de validation des entrées, la gestion des secrets – ce sont précisément le type d’exigences implicites qui sont manquées lorsque l’agent optimise pour un code fonctionnel plausible plutôt que pour un code correct et contraint.

Passage de relais d’équipe. Si vous l’avez construit par prompts itératifs, l’artefact qui enregistre ce qui a été décidé et pourquoi est… le journal git. Bonne chance avec ça.

Ce que le développement piloté par les spécifications change

Le SDD ne prétend pas éliminer l’itération. Les bonnes versions du SDD sont explicitement itératives. Ce qu’elles changent, c’est l’endroit où l’itération a lieu. Pour la définition complète – y compris comment le SDD diffère de la TDD, de la BDD et des méthodes formelles – voir Qu’est-ce que le développement piloté par les spécifications ?

Au lieu d’itérer sur le code et de déduire l’intention à partir des différences (diffs), vous itérez sur la spécification puis vous implémentez. La spécification devient l’artefact qui enregistre ce qui a été décidé, pourquoi, et ce qui est hors périmètre – remplissant une fonction similaire aux Registres de décisions architecturales mais orientée vers l’intention fonctionnelle plutôt que vers des choix de niveau système. Le code implémente cette intention.

Le SDD passe par cinq phases – spécifier, planifier, tâches, implémenter, valider – avec une porte de revue humaine à chaque étape. Voir Flux de travail du développement piloté par les spécifications : des exigences au code pour le processus complet, les modèles et les points de contrôle. L’agent participe à la plupart des phases, mais les humains reviennent les artefacts avant que l’implémentation ne commence. Cette étape de revue est la différence centrale entre le SDD et le vibe coding.

Pourquoi les développeurs l’appellent Waterfall

La critique du modèle en cascade (waterfall) n’est pas fausse. Elle vise juste le mauvais SDD, et non le SDD lui-même.

Le mode d’échec spécifique est la planification préalable longue. La caractéristique définissante du waterfall est une boucle de rétroaction qui s’étire sur des semaines ou des mois : phase de exigences, phase de conception, phase de construction, phase de test, livraison. La rétroaction arrive tard. Au moment où vous découvrez que l’hypothèse de conception était fausse, vous avez construit dessus pendant des semaines.

Lorsqu’un développeur utilise Spec Kit et génère une liste de tâches de 200 lignes avant d’écrire une seule ligne de code, puis passe deux jours à peaufiner le document de exigences avant que l’agent ne touche à quoi que ce soit, c’est du waterfall. C’est du waterfall avec du markdown au lieu de UML, mais le mode d’échec est identique.

Un commentateur HN a décrit l’utilisation de Spec Kit pour un petit outil CLI et a trouvé cela « trop lent, trop d’ajustements avant de voir du code ». C’est la mauvaise version. Cet utilisateur avait raison de le rejeter pour cette tâche.

La critique utile n’est pas « les spécifications sont mauvaises ». C’est « une planification préalable longue avant la rétroaction est mauvaise ». Ce sont des affirmations différentes.

Le juste milieu utile

Le bon SDD évite le piège du waterfall en gardant la spécification petite et en commençant l’implémentation tôt.

Spécifications petites. Un document de exigences pour une seule fonctionnalité devrait tenir sur un écran. Si la spécification fait dix pages, c’est soit une conception de plateforme, soit elle doit être découpée en fonctionnalités plus petites. Les spécifications trop grandes prennent trop de temps à être revues et deviennent obsolètes rapidement.

Tranches de tâches courtes. Chaque tâche devrait être implémentable en une seule session agent, révisable comme une petite différence (diff), et testable en isolation. Si les tâches sont trop grandes, la boucle d’implémentation s’étire et le mappage spécification-code devient difficile à vérifier.

Implémentation précoce. Spécifier la première tâche, l’implémenter, la valider, puis passer à la tâche suivante. Ne spécifiez pas tout avant d’implémenter quoi que ce soit. La première implémentation révélera ce que votre spécification a mal fait. Mettez à jour la spécification avant de continuer.

Spécification vivante. Lorsque la réalité diffère de la conception – et ce sera le cas – mettez à jour la spécification, pas seulement le code. La spécification n’est utile que si elle reflète ce qui a réellement été construit.

Tests comme rétroaction exécutable. Chaque critère d’acceptation devrait correspondre à au moins un test. La suite de tests est la version machine-lisible de la spécification. Si la spécification dit « seuls les utilisateurs authentifiés peuvent déclencher ceci », il devrait y avoir un test qui vérifie que les requêtes non authentifiées sont rejetées.

Cet hybride – spécifications petites, tâches courtes, implémentation précoce, documents vivants – est ce qui fonctionne réellement. Ce n’est ni du vibe coding ni du waterfall. C’est une itération contrôlée avec des artefacts durables.

Quand le SDD bat le Vibe Coding

Utilisez le SDD – même le SDD léger – lorsque le coût d’une erreur est réel.

Logique métier à risque. Facturation, permissions, migrations de données, idempotence – toute logique où un comportement incorrect est coûteux ou difficile à inverser. Le vibe coding laisse ce type d’exigences implicites. Le SDD les rend explicites et révisables avant l’implémentation.

Modifications d’API de production. Toute modification d’un contrat d’API public ou interne devrait avoir un document de conception. Le document de conception est ce que vous réviser avant que l’agent n’écrive du code qui casse les appels.

Flux de travail multi-agents. Lorsque plusieurs agents implémentent différentes parties d’une fonctionnalité, la spécification est la source de vérité partagée. Sans elle, chaque agent optimise localement et les pièces peuvent ne pas correspondre.

Passage de relais d’équipe. Si un autre développeur ou un autre agent va continuer ce travail, la spécification est l’artefact de passage de relais. Un journal git et un README ne suffisent pas.

Refactorisations importantes. Les refactorisations qui touchent les abstractions de cœur ont besoin d’une déclaration explicite de ce qui doit rester le même (comportement) et de ce qui est autorisé à changer (structure). Sans cela, l’agent peut casser des contrats que vous pensiez préservés.

Quand le Vibe Coding est toujours meilleur

Le SDD est une surcharge. Parfois, cette surcharge n’en vaut pas la peine.

Scripts rapides. Un script de 50 lignes pour renommer des fichiers ou transformer du JSON n’a pas besoin d’un document de exigences. Écrivez le prompt, vérifiez la sortie, livrez-le.

Expérimentations. Si vous apprenez si une approche est faisable – explorant une API, testant une bibliothèque, validant une hypothèse – vous avez besoin de vitesse, pas de structure. Expérimentez d’abord, spécifiez si l’expérience réussit.

Esquisses d’interface. La conception d’interaction profite de la vision plutôt que de la spécification. Construisez rapidement plusieurs variations rudimentaires, réagissez à ce que vous voyez, et ne spécifiez que ce que vous allez réellement livrer.

Automatisation jetable. Scripts ponctuels, importations de données, assistants de migration – le coût d’un résultat légèrement erroné est généralement faible, et l’artefact sera de toute façon supprimé après usage.

Prototypes solo. Si vous êtes la seule personne qui verra jamais ce code et que l’objectif est l’apprentissage plutôt que la production, le vibe coding est plus rapide et les inconvénients sont contenus.

Un cadre de décision simple

La question pratique n’est pas « SDD ou vibe coding ? ». C’est « combien de spécification ai-je besoin pour cette tâche spécifique ? »

Utilisez le vibe coding lorsque :

  • La tâche prend moins d’une journée
  • Vous explorez ou apprenez
  • L’artefact est jetable ou peu risqué
  • Vous êtes la seule personne qui y touchera
  • La vitesse de rétroaction compte plus que la correction

Utilisez le SDD léger lorsque :

  • La tâche prend deux jours ou plus
  • Plusieurs fichiers sont affectés
  • Il y a des exigences explicites de sécurité ou de correction
  • Une autre personne ou un autre agent continuera le travail
  • Vous devez écrire des tests qui correspondent aux exigences

Utilisez le SDD complet lorsque :

  • La fonctionnalité touche une interface publique ou un contrat de données
  • Plusieurs agents ou membres de l’équipe sont impliqués
  • L’organisation exige une revue de conception avant l’implémentation
  • Des traçabilités de conformité ou d’audit sont requises

L’erreur la plus courante est d’appliquer le SDD complet à des tâches qui n’ont besoin que du SDD léger, et d’appliquer aucune spécification à des tâches qui en ont besoin au moins une légère. Quel que soit le niveau que vous choisissez, la spécification ne reste utile que si quelque chose la vérifie continuellement par rapport au code ; Garder les spécifications, les tests et le code synchronisés dans le développement IA couvre les vérifications de traçabilité qui détectent une spécification qui devient silencieusement obsolète.

Le mauvais SDD est du waterfall avec du markdown. Le bon SDD est une itération contrôlée avec des artefacts durables. Le vibe coding est le bon outil pour les bonnes tâches – et le mauvais outil pour les mauvaises. Savoir la différence est la compétence.

Liens utiles

S'abonner

Recevez de nouveaux articles sur les systèmes, l'infrastructure et l'ingénierie IA.