« Le waterfall contre-attaque » : notre réponse, point par point

225 points et 191 commentaires : le fil Hacker News qui accuse le spec-driven development de ressusciter le waterfall a marqué les esprits. Trois critiques précises, une réponse chiffrée, sans esquive.

Un fil Hacker News intitulé « Spec-Driven Development: The Waterfall Strikes Back » a réuni 225 points et 191 commentaires (news.ycombinator.com/item?id=45935763). L'accusation : écrire une spécification avant le code fait revenir le mal que l'agile avait chassé. Trois critiques précises s'en dégagent. Voici notre réponse, sans en écarter aucune.

Critique 1 : « la spec devient un fouillis en profondeur de projet »

Vraie pour une spec unique qui grossit indéfiniment. Chez Maestro, rien ne s'écrit d'un bloc : le brief, la spécification, l'architecture et le découpage en stories sont des documents courts et séparés, chacun validé avant le suivant par une gate humaine, le « Ça me va ». Un document qui grossit trop se retravaille avant de continuer, il ne s'empile jamais sur les précédents. C'est le principe qui a produit un rapport d'environ dix entre notre méthode et BMAD-METHOD sur le volume de contexte de méthode injecté : la sobriété n'est pas un supplément, c'est la contrainte de départ.

Critique 2 : « des heures sans voir de code, aucun feedback itératif »

C'est la critique la plus juste contre un big design upfront classique. Notre réponse est structurelle : après le découpage, le développement et la vérification tournent story par story, jamais sur le produit entier d'un coup. Le retour arrive à l'échelle d'une story, quelques minutes à quelques heures, pas à la fin d'un chantier de plusieurs semaines. Sur nos campagnes de mesure, un produit complet franchit la ligne pour quelques dizaines de dollars en une poignée d'heures, pas en jours sans nouvelle.

Critique 3 : « le LLM est un compilateur non déterministe »

Celle-ci vise juste et ne se résout pas par de la rhétorique. Notre réponse : borner le non-déterminisme par des tests écrits AVANT le code (le contrat de vérification est figé dès le découpage), et signaler tout test que l'agent altère en cours de réparation, même préexistant. Le modèle reste probabiliste ; ce qu'il doit satisfaire ne l'est plus. C'est le même principe de mesure qui nous a fait tirer chaque version de notre méthode d'un défaut trouvé par un jury, jamais d'une intuition.

Ce que la défense générique ne dit pas

Martin Fowler a comparé Kiro, Spec-Kit et Tessl sans trancher entre eux (martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html), et le repo github/spec-kit affiche 130 054 étoiles (api.github.com/repos/github/spec-kit, vérifié le 18 août 2026) : le spec-driven development est un mouvement, pas encore une architecture éprouvée contre ses propres critiques. Défendre la thèse sans mesurer ce qu'elle change en pratique laisse la contre-attaque du fil HN sans réponse concrète.

Ce que nos chiffres disent

Sur les campagnes menées entre notre méthode et BMAD-METHOD, la référence ouverte la plus proche d'un waterfall documentaire classique (PRD volumineux, stories nombreuses, code livré mince), l'écart se creuse précisément là où les trois critiques du fil pointent : moins de contexte mort, un retour story par story, et un code qui passe ses propres tests plutôt que des documents qui décrivent une intention.

Ce qu'on concède

Une spec-as-source qui ne serait jamais découpée, jamais validée par petits bouts, mérite en effet le procès du waterfall. La nôtre n'y échappe que parce que chaque étape est petite, jetable, et jugée sur ce qu'elle produit, pas sur ce qu'elle promet. Le fil HN avait raison de se méfier d'une spécification qui devient un projet en soi ; il n'avait pas prévu qu'on la découperait en tranches assez fines pour qu'aucune ne devienne jamais un projet. La beta de Maestro est gratuite, sur invitation : bemaestro.fr.