Dans la majorité des projets logiciels, le code finit souvent par devenir la seule vérité fiable. Les décisions prises au départ se diluent, les règles métier sont éparpillées entre tickets, discussions Slack et souvenirs d’équipe, et chacun avance avec sa propre interprétation.
Au début, cela semble fonctionner. Mais dès que le produit évolue ou que l’équipe grandit, les incompréhensions apparaissent : comportements inattendus, régressions, dette technique, temps perdu à redécouvrir l’évidence.
Ce n’est pas un problème de compétence, mais d’alignement.
L’idée derrière le Spec-Driven Development
Le Spec-Driven Development (SDD) propose un changement simple mais radical :
👉 la spécification devient la source de vérité du projet.
Avant d’écrire du code, on décrit précisément ce que le système doit garantir. Ces garanties guident directement l’architecture, l’implémentation et les tests.
La spec ne vit plus dans un document oublié. Elle devient un artefact opérationnel, consulté et utilisé chaque jour par les développeurs.
Définition synthétique
Le Spec-Driven Development est une approche où la spécification formalisée (exigences, critères d’acceptation, invariants) devient l’artefact central du projet. Elle est versionnée avec le code et sert de référence pour guider le design, l’implémentation et les tests.
Le SDD peut s’appliquer à différentes échelles : une User Story, une feature, un Epic ou même un produit entier. Ce qui le définit n’est pas la taille, mais le principe : formaliser explicitement le comportement attendu avant l’implémentation, puis s’y référer tout au long du cycle.
Pourquoi c’était difficile avant
Historiquement, maintenir une spécification à jour demandait énormément d’efforts. Entre la pression du delivery et la complexité croissante des systèmes, la documentation finissait presque toujours obsolète.
Résultat : On revenait au code comme unique référence, même lorsqu’il était difficile à lire ou à interpréter.
Ce qui définit réellement une approche Spec-Driven
Avant de regarder comment les outils modernes permettent d’appliquer cette démarche, il est utile de clarifier ce qui fait qu’un projet est réellement Spec-Driven Development.
Ce n’est pas la présence d’un document nommé requirements.Ce n’est pas non plus le fait d’écrire plus de documentation.
Le cœur du SDD est ailleurs.
D’abord, la spécification agit comme un contrat. Si une implémentation s’en écarte, ce n’est pas une variante acceptable : c’est un défaut. La discussion ne porte plus sur des préférences techniques, mais sur le respect d’un engagement explicite.
Ensuite, chaque décision doit être traçable.
Un composant répond à une exigence, un test vérifie un critère d’acceptation, une validation protège un invariant. Rien n’apparaît par hasard.
Le SDD impose également une discipline fondamentale : clarifier le quoi avant le comment. On s’accorde sur les comportements attendus avant de débattre de la meilleure manière de les implémenter. Cette séparation évite que l’architecture ne dicte accidentellement le produit.
Enfin, la spécification est vivante. Elle évolue avec le système, au même rythme que le code, parce qu’elle est versionnée dans le même repository et intégrée au même cycle de revue. Si elle cesse d’être maintenue, alors l’approche cesse d’être Spec-Driven Development.
Ces principes peuvent exister avec ou sans IA. Mais les outils actuels vont profondément changer notre capacité à les appliquer dans la pratique.
Comment fonctionne le cycle Spec Driven Development ?
Le cycle SDD fonctionne selon un processus itératif en plusieurs phases :
- Spécifier : rédiger les exigences, objectifs et critères d’acceptation en se concentrant sur le "quoi" (ce que le logiciel doit faire) plutôt que sur le "comment".
- Planifier : découper la spécification en tâches précises, testables et réalisables pour guider le développement.
- Développer et tester : construire le code strictement selon la spécification et produire des tests automatisés basés sur les critères d’acceptation pour garantir la conformité.
- Itérer et maintenir : réviser régulièrement la spécification et le code ensemble, en tenant la documentation à jour pour refléter les changements ou nouvelles exigences.
Ce cycle favorise une ingénierie intentionnelle, réduit les incompréhensions et permet aujourd’hui d’intégrer l’IA pour générer, relire et valider le code à partir de la spécification. La spécification reste ainsi le cœur vivant du projet qui oriente toutes les étapes de développement et maintenance.
Ce que l’IA change vraiment
Les outils modernes permettent aujourd’hui de :
- transformer une intention produit en exigences structurées,
- dériver un design cohérent,
- générer des tâches d’implémentation,
- produire des tests alignés sur les critères d’acceptation,
- vérifier que le code respecte toujours la promesse initiale.
Autrement dit, la spécification cesse d’être un poids. Elle devient un accélérateur.
SDD vs BDD vs PDD : où se situe le Spec-Driven Development ?
Avec l’essor de l’IA, plusieurs approches coexistent. Il est donc utile de situer le Spec-Driven Development par rapport au BDD et au Prompt-Driven Development.
SDD vs BDD
Le Behavior-Driven Development (BDD), introduit par Dan North, vise à décrire clairement le comportement attendu, souvent à travers des scénarios Given / When / Then.
BDD et SDD partagent la même intention : réduire l’ambiguïté.
La différence tient au périmètre.
Le BDD formalise le comportement via des tests. Le SDD structure tout le projet autour de la spécification : exigences, design, tâches et validation.
Autrement dit : le BDD décrit le comportement, le SDD organise le système autour d’une source de vérité. Les deux peuvent coexister.
SDD vs PDD
Le Prompt-Driven Development s’appuie principalement sur l’interaction avec l’IA. On décrit ce que l’on veut via des prompts, on ajuste, on itère. C’est très efficace pour prototyper. Mais le prompt est éphémère. Il dépend du contexte immédiat.
Le SDD adopte une logique différente : le prompt devient un outil, la spécification reste la référence.
Le PDD optimise l’échange avec l’IA. Le SDD structure le projet dans la durée.
Les deux peuvent fonctionner ensemble : la spécification nourrit les prompts, et les prompts exploitent la spécification.
Et c’est précisément là que Kiro devient intéressant
Si la spécification est réellement comprise et exploitée par l’environnement de développement, alors elle cesse d’être un simple document. Elle devient un artefact actif.
C’est exactement ce que permet Kiro en organisant le travail autour de Requirements → Design → Tasks.
Voyons maintenant comment cela se matérialise concrètement.
SDD à l’ère de l’IA : quand la spécification devient vraiment utilisable grâce à Kiro
Le Spec-Driven Development devient réellement actionnable quand l’outil de dev "comprend" la spécification comme un artefact de travail, au même titre que le code. Kiro pousse cette logique loin : il structure le développement autour d’un cycle Requirements → Design → Tasks, et garde ces fichiers de spec au cœur du contexte de travail.
1) Installation de Kiro
Option Desktop Kiro IDE
Kiro propose un IDE desktop. L’installation est volontairement simple :
- Aller sur le site Kiro et télécharger l’installateur.
- Lancer l’installateur (Windows / macOS / Linux).
- Ouvrir Kiro IDE et créer/ouvrir un dossier de projet.
Option Kiro CLI
Kiro propose une CLI qui amène les agents dans ton terminal.
macOS / Linux :
curl -fsSL https://cli.kiro.dev/install | bash
Puis dans ton projet :
cd mon-projet
kiro-cli
2) Créer un projet API de sondages/votes
L’objectif est d’avoir une feature simple, mais suffisante pour illustrer le SDD :
- créer un sondage (poll)
- voter
- consulter les résultats
C’est d’ailleurs un exemple fréquemment utilisé pour démarrer avec Kiro en mode spec-driven.
Crée un dossier :
mkdir sdd-kiro-voting-api
cd sdd-kiro-voting-api
Ouvre le dossier dans Kiro IDE (ou lance kiro-cli dans ce dossier si tu passes par la CLI).
3) Définir l’intention produit : le point de départ du SDD avec Kiro
Dans une approche Spec-Driven Development, on ne commence jamais par écrire du code. On commence par décrire ce que le système doit garantir.
Kiro permet de transformer cette intention en une première version de la spécification en s’appuyant sur une description claire des besoins fonctionnels, des contraintes techniques et des règles métier.
Voici un exemple de prompt en français permettant d’initialiser cette démarche :
Je veux construire une API REST de sondages et de votes.
Objectifs fonctionnels :
- Un utilisateur peut créer un sondage avec une question et plusieurs options de réponse.
- Un utilisateur peut consulter un sondage existant.
- Un utilisateur peut voter pour une option d’un sondage.
- Le système doit retourner les résultats du vote.
- Les données peuvent être stockées en mémoire.
Contraintes techniques :
- Utiliser Python.
- Utiliser FastAPI.
- Les échanges se font en JSON.
Règles métier et validations attendues :
- Un sondage doit avoir au minimum deux options.
- La question ne peut pas être vide.
- Si un identifiant de sondage n’existe pas, retourner une erreur.
- Si une option est invalide, retourner une erreur.
- Le système doit protéger contre les données mal formées.
Ce que j’attends de toi :
- Générer une spécification complète.
- Produire des user stories.
- Définir des critères d’acceptation précis et testables.
- Identifier les cas d’erreur.
- Mettre en évidence les invariants importants du système.
Ce que produit Kiro à partir de cette demande
À partir de cette entrée, la plateforme va générer automatiquement :
- une structuration des fonctionnalités
- des user stories exploitables par les équipes produit et techniques
- des critères d’acceptation formulés de manière testable
- une première identification des validations et scénarios d’erreur
Autrement dit, en quelques minutes, on obtient une base formelle qui peut ensuite servir à dériver le design, le plan d’implémentation et les tests.
Comprendre le requirements.md généré à partir du prompt avec Kiro
Le requirements.md généré à partir du prompt devient immédiatement une pièce centrale pour le développeur travaillant avec Kiro.
Chaque fonctionnalité est reliée à une user story qui explique pourquoi elle existe. Puis viennent les critères d’acceptation qui précisent comment le système doit se comporter : cas nominal, erreurs, validations, invariants.
Pour le développeur, l’impact est immédiat : moins d’hypothèses, moins d’interprétation, moins de dépendance à la mémoire de l’équipe.
Les zones floues disparaissent au profit d’attentes vérifiables.
Avant même de commencer à coder, on peut déjà :
- anticiper les structures nécessaires
- visualiser les cas limites
- comprendre ce qui devra être testé
- identifier les contraintes à ne jamais casser
La spécification n’est plus un document à côté du projet. Elle devient le guide qui sécurise chaque décision technique.
Comment passer des requirements au design
Une fois les exigences formalisées dans le requirements.md, le projet change de nature.
La question n’est plus de savoir ce que le système doit faire : cette partie est actée, partagée et vérifiable. Il faut maintenant déterminer comment l’implémenter de manière cohérente.
C’est précisément le rôle du design.md
Dans une approche Spec-Driven, le design ne repose plus principalement sur des habitudes ou des préférences personnelles. Il dérive directement des exigences.
Si les requirements imposent des validations strictes, des mécanismes adaptés apparaissent naturellement. S’ils exigent des erreurs précises, la gestion des exceptions devient structurante. S’ils définissent des invariants, le modèle doit être capable de les préserver.
Pour les développeurs, cela transforme la lecture de l’architecture. Le design n’est plus une proposition abstraite : c’est la traduction technique du contrat métier. On peut suivre un endpoint ou une règle de stockage et remonter directement au requirement qui justifie son existence.
Cette traçabilité simplifie les discussions. Lorsqu’une question apparaît, la réponse se trouve dans la spécification plutôt que dans une interprétation.
Le design devient ainsi le pont entre l’intention fonctionnelle et la construction logicielle.
À ce stade, une grande partie des décisions complexes est déjà stabilisée. Lorsque le développement commence, il s’agit surtout d’implémenter un cadre réfléchi et partagé.
Comment transformer un design en tâches d’implémentation
Une fois l’architecture définie, le projet entre dans le concret : la génération du tasks.md
Les exigences sont connues, le design est validé. Il faut maintenant transformer cette réflexion en actions exécutables.
Chaque tâche correspond à un objectif précis : créer un modèle, ajouter une validation, exposer un endpoint, écrire un test, protéger un invariant. Le développement cesse d’être improvisé pour devenir l’application méthodique d’une direction déjà établie.
Rien n’est isolé. Chaque ligne à produire renvoie à une exigence identifiée plus tôt.
Pour les développeurs, cela change tout : lorsqu’une question apparaît, la réponse se trouve dans la spécification.
Le tasks.md rend aussi une évidence visible : les tests ne viennent pas après. Ils sont la traduction directe des critères d’acceptation.
À partir de là, le projet n’est plus une intention. C’est un plan que l’on déroule.
Mais un projet évolue toujours.
Si la spécification change alors que certaines tâches ont déjà été implémentées, on met simplement à jour le requirements.md (qui est versionné comme le code).
Ensuite, on crée de nouvelles tâches pour adapter l’implémentation à cette nouvelle version.
La tâche initiale ne devient pas "fausse". Elle correspondait à la spécification telle qu’elle existait à ce moment-là.
C’est exactement la même logique que pour le code : chaque version reflète un état du produit à un instant donné.
Exemple : générer du code à partir d’une spécification
Prenons maintenant la tâche 6.1 Créer l’endpoint POST /polls
Elle impose plusieurs éléments précis : validation des entrées, gestion des erreurs et retour du sondage créé avec le bon statut HTTP. Rien de tout cela n’est laissé à l’interprétation puisque les requirements associés décrivent déjà les comportements attendus.
Lorsque la tâche est lancée, Kiro ne part pas d’une demande vague. Il dispose du contexte complet : la spécification, les critères d’acceptation et les décisions du design. L’implémentation générée s’inscrit donc naturellement dans le cadre défini plus tôt.
Le résultat est immédiatement vérifiable. Les fichiers sont modifiés, l’endpoint apparaît dans l’application et les tests liés aux requirements sont exécutés automatiquement.
Les tests démarrent.
Ils passent tous.
Pas parce qu’on a eu de la chance, mais parce que le comportement était défini avant d’écrire la première ligne.
Et c’est là que la démonstration devient concrète : tout passe.
Les validations fonctionnent, les erreurs retournent les bons statuts et le comportement observé correspond à la promesse faite dans la spécification. Le développeur n’a plus à corriger des oublis après coup. La majorité des contraintes étaient déjà connues avant même l’écriture du code.
On observe alors une continuité rare dans les projets logiciels : l’intention décrite au départ se retrouve directement dans le résultat livré.
La spec n’était pas un document théorique mais elle était un plan d’exécution.
Limites et points de vigilance
Comme toute approche structurante, le Spec-Driven Development n’est pas une solution magique. Mal appliqué, il peut même recréer les problèmes qu’il cherche à résoudre.
Le risque d’une spécification trop lourde
Le premier danger serait de transformer la spécification en phase exhaustive en amont.
Si l’on cherche à tout définir avant de coder, on glisse rapidement vers une logique proche du cycle en V : beaucoup d’intention, peu de feedback.
Le SDD ne doit pas figer le besoin. Il doit clarifier l’intention à l’échelle d’une itération.
La spécification reste vivante, évolutive, et ajustée par les retours utilisateurs.
Le retour d’une documentation décorative
Autre risque : produire des fichiers markdown qui deviennent une charge supplémentaire.
Si la spécification n’a pas d’impact direct sur le design, les tâches ou la validation du code, elle redevient une documentation passive exactement ce que le SDD cherche à éviter.
La clé est simple : la spécification doit produire un effet concret. Sinon, elle perd sa raison d’être.
Des développeurs réduits à un rôle passif ?
Avec l’IA, une crainte apparaît : Les développeurs pourraient-ils devenir de simples exécutants d’une spécification générée ?
En pratique, le SDD ne retire aucune responsabilité. Il structure l’intention. Mais le jugement technique, l’architecture, la remise en question et les décisions restent profondément humains.
L’IA accélère l’exécution. Elle ne remplace ni l’esprit critique ni l’expertise.
Conclusion
Au terme de cette démonstration, une idée s’impose : le Spec-Driven Development n’est pas une production de documents supplémentaires. C’est une manière de préserver en permanence le lien entre l’intention et la réalité du code.
Avec Kiro, les zones floues se réduisent étape après étape. Une intention devient un ensemble de requirements. Les requirements structurent le design. Le design se transforme en tâches. Et ces tâches aboutissent à un comportement vérifié immédiatement par les tests.
Mais le SDD ne remplace ni l’agilité, ni le feedback, ni le jugement humain. Il ne fige pas l’intention. Il la rend explicite.
Ce qui évolue n’est pas seulement la méthode, mais le quotidien du développeur. On ne suppose plus : on travaille à partir d’un cadre partagé, versionné, discutable.
Dans ce contexte, l’IA n’efface pas le rôle des développeurs. Elle amplifie leur capacité à produire vite, tout en restant alignés sur le sens.
Cet alignement apporte quelque chose de rare dans les projets logiciels : de la sérénité.
La sérénité de comprendre pourquoi une ligne existe.
La sérénité de vérifier qu’elle respecte une intention explicite.
La sérénité de faire évoluer le système sans perdre sa cohérence.
Le Spec-Driven Development ne cherche pas à prédire l’avenir d’un projet. Il cherche simplement à s’assurer qu’à chaque étape, ce que l’on construit correspond réellement à ce que l’on a choisi de construire.
Avant d’être écrit, un logiciel doit être compris. Et peut-être que l’IA nous donne enfin les moyens de garder cette compréhension vivante.
