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

Spécifications comme source de vérité, ou lenteur cérémonielle ?

Sommaire

Le développement guidé par les spécifications est entré dans l’année 2026 en tant que 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 le code à partir d’une spécification revue, plutôt que d’un prompt improvisé. Difficile de contredire cette théorie.

En pratique, Hacker News a qualifié cela de « Waterfall Strikes Back » (Le Waterfall est de retour).

Les deux camps ont des arguments valables.

Développement guidé par les spécifications versus Vibe Coding

Le cas du SDD dans un monde de Vibe Coding

Le vibe coding – la pratique consistant à écrire un prompt lâche 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 schéma dominant de codage assisté par IA. Les développeurs livraient des scripts, des prototypes et des outils simples à une vitesse jamais vue auparavant.

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 lors de la troisième. Les hypothèses de sécurité étaient abandonnées. Les décisions architecturales changeaient au milieu d’une fonctionnalité parce que l’agent n’avait pas de mémoire durable de l’intention initiale.

Le développement guidé 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 contre ces artefacts, une tranche à la fois. Garder la spécification versionnée et mise à jour.

Les outils de codage IA – GitHub Spec Kit, Kiro, BMAD, et un ensemble croissant de workflows personnalisés Claude Code – sont tous des implémentations de cette idée. Les outils sont réels. L’intérêt est réel. La réaction hostile 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 ce que vous voulez construire, le chemin le plus rapide est de construire quelque chose de grossier et d’y réagir. Le SDD nécessite de savoir quoi spécifier. Si vous ne savez pas encore, les spécifications sont prématurées.

Expériences UI. 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, de les éliminer pour la plupart, et de converger vers quelque chose qui se sent vraiment juste. Un document de exigences ne vous aide pas ici.

Automatisation jetable. Scripts ponctuels, tâches d’extraction de données, assistants de migration – ces éléments ont rarement besoin d’un document de conception. Le coût d’une erreur mineure est faible. Le coût d’un processus lent et cérémoniel est réel.

Retour 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 ralentirait cela sans aucun bénéfice.

L’erreur est de prendre les schémas de succès de ces contextes et de les appliquer aux 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 de manière prévisible à mesure que la portée et les enjeux augmentent.

Modifications multi-fichiers. Une fois qu’une fonctionnalité touche cinq fichiers ou plus, la fenêtre de contexte de l’agent commence à perdre de vue les invariants. Sans document de conception, chaque prompt doit rétablir un contexte qui a été établi et oublié dans une session précédente.

Dérive architecturale. Sans objectifs non explicites, les agents implémentent des choses. L’agent ajoute une couche de mise en cache car cela semble raisonnable. Trois sessions plus tard, l’hypothèse de mise en 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 rappelle 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 exactement le genre 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 en équipe. Si vous l’avez construit via un promptage itératif, 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 guidé 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 se produit. Pour la définition complète – y compris comment le SDD diffère de TDD, BDD et des méthodes formelles – voir Qu’est-ce que le développement guidé par les spécifications ?

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

Un workflow SDD typique passe par cinq phases :

Spécifier. Énoncé du problème, utilisateurs, objectifs, non-objectifs, critères d’acceptation, questions ouvertes.

Planifier. Décisions architecturales, modules affectés, modèle de données, contrats API, préoccupations de sécurité, stratégie de test.

Décomposition des tâches. Tranches d’implémentation petites avec des critères de validation explicites et des points de contrôle de revue humaine.

Implémenter. Une tâche à la fois, avec réinitialisation du contexte entre les tâches, application des contraintes de la spécification, et mise à jour du plan lorsque la réalité diffère de la conception.

Valider. Tests, lint, vérifications de type, critères d’acceptation, différence spécification-code.

L’agent participe à la plupart des phases – rédaction de la spécification, génération de la conception, proposition de tâches – mais les humains révuent 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 appellent cela Waterfall

La critique du Waterfall n’a pas tort. Elle vise simplement le « mauvais » SDD, pas le SDD lui-même.

Le mode de défaillance spécifique est la planification en amont prolongée. La caractéristique définissante du Waterfall est une boucle de rétroaction qui s’étend sur des semaines ou des mois : phase d’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.

Quand 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 à polir le document d’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 de défaillance est identique.

Un commentateur sur HN a décrit l’utilisation de Spec Kit pour un petit outil CLI et a trouvé que c’était « 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 en amont longue avant la rétroaction est mauvaise ». Ce sont des affirmations différentes.

Le juste milieu utile

Un bon SDD évite le piège du Waterfall en gardant la spécification petite et en démarrant l’implémentation tôt.

Spécifications petites. Un document d’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 divisée en fonctionnalités plus petites. Les spécifications trop grandes prennent trop de temps à revuer et deviennent rapidement obsolètes.

Tranches de tâches courtes. Chaque tâche doit être implémentable en une seule session d’agent, révuable comme une petite différence (diff), et testable de manière isolée. Si les tâches sont trop grandes, la boucle d’implémentation s’étire et la correspondance 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 les erreurs de votre spécification. 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 été réellement construit.

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

Ce hybride – petites spécifications, tâches courtes, implémentation précoce, documents vivants – est ce qui fonctionne vraiment. Ce n’est pas du vibe coding et ce n’est pas 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 un SDD léger – lorsque le coût d’une erreur est réel.

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

Modifications d’API en production. Toute modification d’un contrat d’API publique ou interne doit avoir un document de conception. Le document de conception est ce que vous revuez avant que l’agent n’écrive du code qui casse les appelants.

Workflows 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 s’adapter.

Passage de relais en é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 significatives. Les refactorisations qui touchent aux abstractions de base nécessitent une déclaration explicite de ce qui doit rester identique (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 reste meilleur

Le SDD est une surcharge. Parfois, la 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 d’exigences. Écrivez le prompt, vérifiez la sortie, livrez-le.

Expériences. Si vous apprenez si une approche est réalisable – explorer une API, tester une bibliothèque, valider une hypothèse – vous avez besoin de vitesse, pas de structure. Expérimentez d’abord, spécifiez si l’expérience réussit.

Esquisses UI. La conception d’interaction bénéficie de la visualisation plutôt que de la spécification. Construisez plusieurs variations grossières rapidement, réagissez à ce que vous voyez, et ne spécifiez que ce que vous allez réellement livrer.

Automatisation jetable. Scripts ponctuels, imports de données, assistants de migration – le coût d’un résultat légèrement incorrect est généralement faible, et l’artefact va être supprimé après utilisation de toute façon.

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 « quelle quantité de spécification ai-je besoin pour cette tâche spécifique ? »

Utilisez le vibe coding quand :

  • La tâche prend moins d’une journée
  • Vous explorez ou apprenez
  • L’artefact est jetable ou à faible enjeu
  • Vous êtes la seule personne qui touchera à cela
  • La vitesse de rétroaction importe plus que la correction

Utilisez le SDD léger quand :

  • 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 agent continuera le travail
  • Vous devez écrire des tests qui correspondent aux exigences

Utilisez le SDD complet quand :

  • 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
  • La conformité ou les traçabilités d’audit sont requises

L’erreur la plus courante est d’appliquer le SDD complet à des tâches qui n’ont besoin que d’un SDD léger, et d’appliquer aucune spécification du tout à des tâches qui ont besoin d’au moins une version légère.

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 faire 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.