SDD Ce N'est Pas Trois Outils — C'est une Pile de Huit Phases
L'article de Martin Fowler sur les outils SDD mérite d'être lu. Fowler a une rare capacité à nommer les choses avec précision, et son cadrage du développement piloté par specs comme réponse au problème du "collapse de contexte" dans le développement assisté par IA est l'articulation la plus claire du problème central que j'ai vue publiée.
Mais l'analyse s'arrête à trois outils. Et ce point d'arrêt obscurcit ce qui rend SDD difficile en pratique.
Ce Que Fowler a Raison
Fowler identifie les trois outils vers lesquels la plupart des implémentations SDD convergent : un format de spec, un mécanisme de validation et un portail d'approbation. Il a raison que ces trois primitives sont nécessaires. Une spec sans validation est une liste de souhaits. La validation sans portail d'approbation produit du chaos — des agents implémentant des exigences à moitié approuvées puis faisant marche arrière.
Son observation que le goulot d'étranglement a migré de la génération de code vers la vérification de la correction est également précise et sous-estimée. Le problème n'est pas que les agents IA écrivent lentement. Le problème est qu'ils écrivent avec confiance dans la mauvaise direction quand les exigences sont ambiguës — et personne ne le remarque jusqu'à ce que la fonctionnalité soit livrée.
Où le Cadre des Trois Outils est Insuffisant
Les trois outils que Fowler décrit — spec, valider, approuver — couvrent la boucle d'implémentation. Ils ne couvrent pas ce qui se passe avant, ni ce qui se passe après.
Avant l'implémentation, il y a un problème. Un développeur a une idée. Cette idée doit être externalisée (brainstorm), structurée en critères d'acceptation (spec), testée de manière adversariale pour en vérifier l'exhaustivité (challenge), et vérifiée pour la disponibilité d'implémentation avant qu'un agent touche au code (vérification de disponibilité). Ces quatre phases se produisent avant l'étape d'approbation, et les ignorer explique pourquoi les specs arrivent au portail d'approbation avec des critères trop vagues pour être implémentés correctement.
Après la fusion, il y a un problème différent. Le code qui satisfait les critères d'acceptation au moment de la fusion peut s'éloigner de la spec des semaines plus tard, à mesure que des changements adjacents s'accumulent. Les trois outils de Fowler n'ont rien à dire à ce sujet. Le cycle approuver-valider se termine à la fusion.
Les Huit Phases
Un cycle de vie SDD complet compte huit phases :
1. BRAINSTORM → capturer l'idée avant qu'elle ne se dissolve
2. SPEC → la structurer en critères d'acceptation testables
3. CHALLENGE → sonder adversarialement la spec pour détecter lacunes et contradictions
4. READINESS CHECK → vérifier que la spec est implémentable avant de commencer à coder
5. APPROVE → l'humain valide le contrat
6. IMPLEMENT → l'agent exécute contre la spec
7. VALIDATE → vérifier l'implémentation contre chaque critère
8. HEAL → détecter et corriger rétroactivement la dérive post-fusionLes trois outils de Fowler correspondent aux phases 5, 6 et 7. Cela laisse cinq phases non couvertes.
Les phases que les équipes sautent le plus souvent sont la 3 (challenge) et la 8 (heal). Sauter le challenge signifie que les critères d'acceptation arrivent à l'approbation avec des ambiguïtés cachées qui n'apparaissent que pendant l'implémentation. Sauter le heal signifie que la dérive s'accumule silencieusement après la fusion, et la spec devient un artefact historique plutôt qu'un contrat vivant.
Pourquoi Cela Importe pour le Choix des Outils
Si vous évaluez les outils SDD en demandant "a-t-il un format de spec, un mécanisme de validation et un portail d'approbation", presque tous les outils du paysage actuel passent le test. C'est la mauvaise question.
La bonne question est : quel outil couvre les huit phases, et quelles phases nécessitent une intervention manuelle ?
Un outil qui couvre les phases 5–7 mais pas les 1–4 oblige les développeurs à gérer le workflow pré-implémentation en dehors de l'outil. Les phases de challenge et de vérification de disponibilité — qui existent précisément pour détecter ce que les humains manquent — sont absentes.
Un outil qui couvre les phases 5–7 mais pas la phase 8 traite la fusion comme la fin du cycle de vie. Pour les bases de code à long terme avec de fréquents changements adjacents, c'est une lacune significative.
Le Cadre de Fowler Reste Utile
Rien de tout cela n'est une critique de l'analyse de Fowler. Le cadre des trois outils est une description précise du workflow SDD minimum viable. Pour les équipes adoptant SDD pour la première fois, les phases 5, 6 et 7 sont le bon point de départ — elles apportent la plus grande valeur avec le moins de surcharge.
Le cadre devient un plafond quand les équipes essaient de passer à l'échelle. À vitesse plus élevée, avec des agents en parallèle et des specs de longue durée, les phases en dehors de la fenêtre des trois outils créent la friction qui limite le débit.
La Pile Complète
Les outils SDD ne sont pas une liste de contrôle de fonctionnalités. C'est un pipeline. La question n'est pas de savoir si un outil a le support des specs — c'est de savoir si l'outil couvre le pipeline de bout en bout, y compris les phases que la plupart des analyses ignorent.
Du brainstorm au heal, sans lacunes.
Lectures complémentaires : Plus d’articles sur le développement piloté par specs · Mode Autonome : SDD bout en bout avec /autonomous-sdd · Planu vs Outils SDD