Développement piloté par les spécifications vs programmation intuitive : Waterfall ?

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

Sommaire

Le développement dirigé par les spécifications (Spec-Driven Development) est entré en 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 meilleurs et plus cohérents lorsqu’ils implémentent à partir d’une spécification revue plutôt que d’une prompte ad hoc. Difficile de contredire cette théorie.

En pratique, Hacker News l’a qualifié de « Waterfall Strikes Back » (Le Waterfall revient).

Les deux camps ont raison.

Développement dirigé par les spécifications contre Vibe Coding

Le cas du SDD dans un monde de Vibe Coding

Le vibe coding – la pratique consistant à écrire une prompte approximative et à itérer sur ce que l’agent IA produit – fonctionne remarquablement bien pour des travaux petits, exploratoires et jetables. Pendant les six premiers mois de 2025, c’était le modèle dominant de codage IA. 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 lors de la troisième. Les hypothèses de sécurité étaient abandonnées. Les décisions architecturales changeaient en plein milieu d’une fonctionnalité car l’agent n’avait pas de mémoire durable de l’intention.

Le développement dirigé 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 de la prompte. Écrire d’abord les exigences, une conception et un plan de tâches. Laisser l’agent implémenter ces artefacts tranche par tranche. Garder la spécification versionnée et mise à jour.

GitHub Spec Kit, Kiro, les workflows SDD de Claude Code et BMAD, ainsi que d’autres échafaudages communautaires, sont tous des implémentations de cette idée. Les outils sont réels. L’intérêt est réel. Le rejet 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 d’interface utilisateur (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 en grande partie et de converger vers quelque chose qui fonctionne vraiment. Un document de exigences ne vous aide pas ici.

Automatisation jetable. Scripts ponctuels, travaux d’extraction de données, assistants de migration – ceux-ci nécessitent rarement un document de conception. Le coût d’une erreur légère est faible. Le coût d’un processus lent et cérémoniel est réel.

Retour rapide. Lorsque vous devez 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 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.

Là 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 prompte doit rétablir le contexte qui a été établi et oublié lors d’une session précédente.

Dérive architecturale. Sans non-objectifs 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 son removal est coûteux.

Contraintes oubliées. « Seuls les utilisateurs authentifiés peuvent déclencher cela » 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 le nouveau point d’entrée.

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.

Passation de relais d’équipe. Si vous l’avez construit par prompte itérative, 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 Dirigé 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 du TDD, du BDD et des méthodes formelles – voir Qu’est-ce que le Développement Dirigé 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 Enregistrements 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.

Le SDD passe par cinq phases – spécifier, planifier, tâches, implémenter, valider – avec une étape de révision humaine à chaque étape. Voir Flux de Travail du Développement Dirigé 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 révise les artefacts avant que l’implémentation ne commence. Cette étape de révision est la différence centrale entre le SDD et le vibe coding.

Pourquoi les Développeurs l’appellent Waterfall

La critique du waterfall n’est pas fausse. Elle vise simplement un mauvais SDD, pas le SDD lui-même.

Le mode de défaillance spécifique est la planification longue en amont. 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 déjà 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 à polir 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 de défaillance est identique.

Un commentateur de HN a décrit l’utilisation de Spec Kit pour un petit outil CLI et a trouvé cela « trop lent, trop de réglages 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 « la planification longue en amont 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 seul é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 à être révisées et deviennent rapidement obsolètes.

Tranches de tâches courtes. Chaque tâche doit être implémentable en une seule session d’agent, révisable comme une petite différence, et testable de manière isolée. Si les tâches sont trop grandes, la boucle d’implémentation s’étire et la cartographie spécification-code devient difficile à vérifier.

Implémentation précoce. Spécifiez la première tâche, implémentez-la, validez-la, puis passez à 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 choses que votre spécification a mal comprises. 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 cela », il devrait 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 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 un SDD léger – lorsque le coût de l’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 types 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 doit avoir un document de conception. Le document de conception est ce que vous révisez avant que l’agent n’écrive du code qui casse les appelants.

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 s’emboîter.

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

Refonte significative. Les refontes 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 est encore 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 de exigences. Écrivez la prompte, vérifiez la sortie, livrez-le.

Expériences. Si vous apprenez si une approche est réalisable – exploration d’une API, test d’une bibliothèque, validation d’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 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 sera de toute façon supprimé après utilisation.

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 lorsque :

  • La tâche prend moins d’un jour
  • 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 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 d’équipe sont impliqués
  • L’organisation exige une révision de conception avant l’implémentation
  • La conformité ou les traces 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 légère. Quel que soit le niveau que vous choisissez, la spécification reste utile seulement si quelque chose continue de la vérifier par rapport au code ; Maintenir Spécifications, Tests et Code Synchronisés dans le Développement IA couvre les vérifications de traçabilité qui capturent 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. Connaître 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.