GitHub Spec Kit, Kiro et les flux de travail SDD de Claude Code

Les développeurs qui comparent les approches de développement piloté par spécification (SDD) en 2026 ne demandent généralement pas quel modèle est le plus intelligent. Ils se demandent quel flux de travail permettra de garder l’agent IA aligné sans les submerger de formalismes inutiles.

GitHub Spec Kit, AWS Kiro et les flux de travail personnalisés de Claude Code implémentent tous la même idée générale — exigences, conception, tâches, implémentation, validation — mais ils présentent des compromis en matière de portabilité, de profondeur d’intégration et du degré de processus imposé.

Si vous avez besoin d’abord de comprendre les concepts, lisez Qu’est-ce que le développement piloté par spécification ? et le guide neutre en termes d’outils Flux de travail du développement piloté par spécification situé dans le cluster de documentation Architecture d’application. Cette comparaison se trouve dans le hub Outils de développement IA, aux côtés des évaluations d’assistants et des guides de flux de travail.

Le SDD devient une catégorie d’outils

Le développement piloté par spécification a cessé d’être un exercice théorique à la fin de 2025. Tous les principaux éditeurs de code IA proposent désormais une version du cycle spécifier-planifier-implémenter, et une liste croissante d’outils autonomes rivalise sur la quantité de structure qu’ils ajoutent autour de ce cycle.

La comparaison qui compte n’est pas « quel outil gagne ». C’est la profondeur du processus face à la portabilité. Kiro est intégré. Spec Kit est portable. Les flux de travail Claude Code sont modifiables. De mauvaises spécifications rendent chaque agent moins performant, quel que soit le conteneur choisi. De bonnes spécifications voyagent entre les outils.

Comment comparer les configurations SDD

Avant de choisir un outil, définissez ce sur quoi vous optimisez. La même fonctionnalité peut sembler sans effort dans une configuration et bureaucratique dans une autre, selon la taille de l’équipe, l’âge de la base de code et le niveau de revue nécessaire.

Portabilité – Les spécifications peuvent-elles vivre en tant que markdown simple dans votre dépôt et fonctionner avec l’agent de votre choix le trimestre prochain ? Ou sont-elles liées à un seul IDE, un seul cloud ou un format propriétaire ?

Friction de configuration – Combien de temps se passe-t-il entre « je veux essayer le SDD » et une boucle de spécification-planification-tâches fonctionnelle ? Le gén de CLI, l’installation d’un IDE ou la création de vos propres commandes slash ont tous des énergies d’activation différentes.

Qualité des spécifications – L’outil vous aide-t-il à rédiger des exigences et des critères d’acceptation précis, ou génère-t-il principalement de longs documents ? La structure est utile. Le volume ne l’est pas.

Exécution des tâches – Comment l’outil découpe-t-il le travail en tranches révisables ? Les tâches peuvent-elles s’exécuter en parallèle ? Résiste-t-il à l’explosion des listes de cinquante tâches ?

Points de contrôle de revue – Existe-t-il des points de contrôle humains naturels entre spécifier, planifier, lister les tâches et implémenter ? Le SDD sans revue n’est que du vibe coding plus lent.

Ancrage au dépôt – Le flux de travail lit-il les conventions du projet, les registres de décision, les ADR, AGENTS.md et le code existant avant la planification ? Les agents sans ancrage réinventent l’architecture parce qu’ils ne voient jamais l’intention validée derrière les choix antérieurs.

Collaboration d’équipe – Plusieurs personnes peuvent-elles réviser les mêmes artefacts de spécification dans les demandes de tirage (pull requests) ? Peut-on mélanger des agents sans réécrire le processus ?

Verrouillage (Lock-in) – Que perdez-vous si vous changez d’éditeur, de modèle ou d’éditeur cloud dans six mois ?

GitHub Spec Kit

GitHub Spec Kit est un kit d’outils CLI open source qui génère une boucle pilotée par spécification dans votre dépôt et confie l’exécution à l’agent de codage que vous utilisez déjà. La CLI specify dépose des modèles, des commandes slash et une structure de dossiers conventionnelle. Les commandes typiques suivent une séquence constitution-spécifier-préciser-planifier-tâches-implémenter, avec une étape explicite de précision pour résoudre les ambiguïtés avant le travail d’architecture.

L’avantage distinctif de Spec Kit est son indépendance vis-à-vis des agents. La documentation officielle le présente comme un outillage qui fonctionne avec Claude Code, GitHub Copilot, Cursor, Gemini CLI, Codex et des dizaines d’autres agents. Vous écrivez des spécifications une fois en markdown, vous les commitez comme du code, et vous changez d’exécuteur sans réécrire le processus. Cela fait de Spec Kit la recommandation par défaut pour les équipes qui veulent du SDD sans miser sur un seul éditeur.

Les compromis sont réels. Spec Kit peut produire un arborescence d’artefacts importante – constitution, spécification, plan, tâches, contrats – ce qui se révèle payant sur les fonctionnalités multi-sessions, mais semble lourd pour une petite modification CLI. Les fils de discussion sur Hacker News comparent régulièrement cette surcharge à la cérémonie en cascade (waterfall). Spec Kit est également moins performant si vous voulez un IDE entièrement intégré où spécifications, tâches et implémentation vivent sur une surface guidée unique. Il superpose un processus sur votre éditeur existant plutôt que de le remplacer.

Spec Kit convient aux équipes qui ont déjà un assistant de codage IA privilégié et veulent une échafaudage SDD standardisée par-dessus. Il est particulièrement puissant pour les fonctionnalités en terrain vert (greenfield), les ateliers multi-agents et quiconque refuse le verrouillage d’éditeur.

AWS Kiro

Kiro est l’IDE piloté par spécification d’AWS, construit sur un fork de VS Code / Code OSS. Là où Spec Kit apporte le SDD à votre pile existante, Kiro part du principe que le SDD mérite un environnement dédié. Un prompt génère des artefacts structurés – typiquement requirements.md en notation de type EARS, design.md, et un tasks.md séquencé par dépendances – avant que les agents n’écrivent du code de production.

L’expérience guidée est le principal argument de vente de Kiro. Les exigences, la conception et les tâches sont des objets UI de premier ordre à côté de votre code, et non des fichiers que vous gérez via une CLI séparée. Kiro propose également des Agent Hooks, des automatisations pilotées par événements qui peuvent mettre à jour les tests, la documentation ou des artefacts liés lorsque l’implémentation change. Cette boucle bidirectionnelle est quelque chose que Spec Kit ne fournit pas nativement – les spécifications Spec Kit restent statiques jusqu’à ce qu’un humain les mette à jour.

Les coûts sont une profondeur d’intégration au détriment de la portabilité. Kiro s’exécute dans son éditeur, utilise des modèles soutenus par AWS Bedrock et facture via un modèle de tarification basé sur des crédits avec des plans par paliers. Les équipes d’entreprise déjà sur l’infrastructure AWS trouvent souvent cela acceptable. Les développeurs solo et les équipes multi-éditeurs peuvent ne pas être d’accord. Kiro a également des imperfections typiques d’un IDE plus récent – compatibilité des extensions, surprises de flux de travail, et la question habituelle « ai-je vraiment besoin d’un autre éditeur ? ».

Kiro convient aux développeurs qui veulent l’expérience SDD la plus guidée et sont à l’aise pour adopter un IDE natif de spécification. C’est une option solide pour les équipes d’entreprise, les environnements fortement orientés AWS, et quiconque migre depuis Amazon Q Developer et veut une discipline de spécification sans assembler la chaîne d’outils manuellement. Si vous vivez aujourd’hui dans VS Code standard et aimez votre configuration actuelle, Kiro demande un changement plus important que Spec Kit.

Commandes et compétences personnalisées Claude Code

Claude Code ne propose pas un seul produit SDD officiel de la manière dont Spec Kit ou Kiro le font. Si vous êtes nouveau sur l’outil lui-même, commencez par le guide d’installation et de configuration Claude Code pour la configuration, les autorisations et les backends locaux. Le modèle SDD lui-même réside dans les commandes personnalisées, les compétences (skills) et les modèles markdown locaux au dépôt que les développeurs maintiennent. Anthropic a intégré les anciens fichiers .claude/commands/*.md dans le mécanisme de compétences, donc le modèle durable est un fichier SKILL.md (ou équivalent) qui définit votre liste de contrôle spécifier-planifier-implémenter, chargé à la demande.

Cette approche est la plus légère et la plus modifiable. Vous pouvez transposer une structure à trois fichiers de type Kiro, refléter les phases de Spec Kit avec des commandes slash, ou inventer un flux de travail minimal qui convient à un seul dépôt. Claude Code lit CLAUDE.md pour le contexte de projet toujours actif et tire les compétences lorsque la tâche correspond. Cette divulgation progressive garde les sessions focalisées sans charger une constitution complète à chaque prompt.

L’inconvénient est la discipline. Rien ne vous force à passer par des étapes de précision ou de revue à moins que vous ne construisiez ces portes vous-même. Les fils de discussion Reddit et Hacker News sur le « développement piloté par spécification dans Claude Code » sont pleins de développeurs qui ont copié la compétence de quelqu’un d’autre, l’ont exécutée une fois, et sont retournés au promptage non structuré lorsque la compétence semblait lente. Le SDD Claude Code fonctionne lorsque vous traitez les compétences comme du code – versionné, révisé et maintenu – et non comme un téléchargement de prompt unique.

Pour une implémentation sérieuse, lisez Compétences Claude et SKILL.md pour les développeurs et encodez vos phases en compétences avec des points de contrôle de revue explicites. Le SDD Claude Code est le bon choix lorsque vous vivez déjà dans Claude Code, voulez une flexibilité maximale et maintiendrez le flux de travail vous-même. Pour l’étape de porte de revue spécifiquement, les sous-agents Claude Code peuvent exécuter un passage de revue indépendant et à contexte isolé sur le code généré avant que vous ne fusionniez une tâche – un substitut léger pour le rôle de vérification que les Agent Hooks de Kiro fournissent nativement.

Superpowers : Une version empaquetée de la pile de compétences DIY

Si le fait de créer cette pile de compétences à la main ressemble à exactement le problème de discipline sur lequel le tableau ci-dessus met en garde, Superpowers vaut le détour. C’est un paquet de compétences open source – brainstorming, écriture de plans, développement piloté par sous-agents, développement piloté par les tests, demande de revue de code, et quelques compétences de soutien – distribué sous forme de plugin installable plutôt que quelque chose que vous écrivez de zéro. Il cible directement la limite « la qualité dépend entièrement de la discipline de l’auteur » : les compétences se déclenchent automatiquement et sont censées être un flux de travail obligatoire, et non des suggestions optionnelles que l’agent peut ignorer.

Le flux de travail qu’il impose correspond étroitement à la boucle en cinq phases couverte dans Flux de travail du développement piloté par spécification, des exigences au code : le brainstorming affine une idée vague en un document de conception révisé, writing-plans le découpe en petites tâches vérifiables, subagent-driven-development distribue un nouveau sous-agent par tâche avec une revue en deux étapes, et test-driven-development impose un strict red-green-refactor avant que quoi que ce soit soit considéré comme terminé. Cette dernière partie est plus stricte que ce que la plupart des compétences SDD Claude Code se donnent la peine d’être – Superpowers supprime explicitement le code écrit avant l’existence d’un test échoué pour lui.

Contrairement à une compétence locale au dépôt que vous écrivez vous-même, Superpowers n’est pas réservé à Claude Code. Il fournit des manifests de plugins pour Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot CLI, Devin, Factory Droid et plusieurs autres agents, donc la même méthodologie vous suit entre les harnais (harnesses) au lieu de vivre dans un seul dossier .claude/skills/. Cela en fait un compromis entre le fait de créer votre propre compétence Claude Code et l’adoption d’un outil plus lourd, spécifique à un IDE, comme Kiro : vous obtenez une boucle imposée et avisée sans abandonner votre éditeur ou vous engager dans le format de spécification d’un seul éditeur.

Superpowers convient aux développeurs qui aiment en principe l’approche des compétences Claude Code mais continuent de dériver vers le promptage non structuré parce que rien ne force les portes de revue. C’est un choix moins adapté si vous avez déjà une compétence SDD spécifique au projet ajustée à votre pile – dans ce cas, vous échangez une petite quantité de personnalisation contre une plus grande quantité de cérémonie imposée.

BMAD, OpenSpec et autres flux de travail

Toutes les équipes ne veulent pas de l’arborescence d’artefacts Spec Kit ou de l’IDE Kiro. Deux alternatives apparaissent constamment dans les comparaisons de 2026.

OpenSpec (Fission AI) adopte une approche centrée sur le changement avec moins de fichiers générés que Spec Kit. Les benchmarks communautaires rapportent une consommation de jetons matériellement inférieure pour des tâches comparables, au coût d’une structure initiale moindre. OpenSpec a tendance à gagner lorsque vous modifiez une base de code existante et voulez des spécifications révisables sans une phase de planification de 800 lignes. Il concourt avec Spec Kit sur la portabilité plutôt qu’avec Kiro sur l’intégration IDE. Voir le guide rapide OpenSpec pour les étapes d’installation, la boucle explorer-propose-apply-archive, et les pièges qui apparaissent le plus souvent sur Reddit.

BMAD-METHOD (communauté) pousse dans la direction opposée – des flux de travail multi-agents, basés sur les rôles, qui simulent des personnalités de propriétaire de produit, architecte, développeur et relecture. BMAD peut être puissant sur de grands efforts greenfield où la séparation explicite des rôles aide. C’est aussi lourd. Les équipes rapportent souvent que la cérémonie ne se révèle payante que lorsque la douleur de coordination est déjà aiguë.

Tessl traite la spécification comme la source littérale du code généré, marquant la sortie comme dérivée et décourageant les éditions manuelles. C’est la position la plus forte « spécification-source » parmi les outils mainstream, mais Tessl reste en bêta et porte le verrouillage produit le plus élevé du groupe.

Spec Kitty et d’autres échafaudages communautaires se situent entre OpenSpec et Spec Kit en termes de poids. Ils méritent d’être observés si vous voulez des modèles sans adopter toute la chaîne d’outils GitHub.

Le modèle à travers tous est le même. Plus de processus aide lorsque l’ambiguïté est coûteuse. Plus de processus nuit lorsque la vitesse de feedback importe plus que l’alignement. Ajustez le poids de l’outil à la taille de la tâche, pas au hype.

Quelle configuration SDD devriez-vous utiliser ?

Il n’y a pas de vainqueur universel. La bonne configuration dépend de qui vous êtes, de ce que vous construisez et de combien de structure vous maintiendrez réellement.

Développeur solo, base de code existante, petites fonctionnalités. Commencez avec les compétences Claude Code ou OpenSpec. Écrivez un bloc d’exigences court, une liste de tâches minimale, et un point de contrôle de revue. N’installez pas une arborescence Spec Kit complète pour une modification de cinquante lignes.

Vous voulez l’approche des compétences Claude Code mais vous sautez constamment vos propres portes de revue. Installez Superpowers au lieu d’écrire une compétence personnalisée de zéro. Vous abandonnez un peu de réglage spécifique au projet en échange d’une boucle idée-plan-implémente-révisé imposée qui ne dépend pas de votre discipline ce jour-là.

Développeur solo, fonctionnalité greenfield, plusieurs sessions. Spec Kit ou une compétence SDD Claude Code bien entretenue. Vous avez besoin d’artefacts durables plus que d’une main guidée IDE.

Petite équipe, éditeurs mélangés. Spec Kit. Spécifications markdown simples dans Git, révisées dans les pull requests, exécutées par l’agent que chaque développeur préfère.

Équipe d’entreprise, native AWS, pression de conformité. Kiro. Artefacts guidés, traceabilité des exigences, et des hooks qui gardent la documentation et les tests plus proches de l’implémentation.

Environnement réglementé. Kiro ou Spec Kit plus votre propre liste de contrôle de validation – pas seulement les compétences Claude Code à moins que vous n’encodiez explicitement des portes de conformité. Les outils ne remplacent pas les pistes d’audit. Ils ne font que les rendre plus faciles à produire.

Base de code existante, modification brownfield. OpenSpec ou un flux de travail Claude Code léger. La cérémonie Spec Kit complète sur chaque correction de bogie ressemblera à un waterfall. Réservez une structure plus lourde pour les fonctionnalités transversales.

Produit greenfield, nombreux agents. Spec Kit. La portabilité importe plus que la finition IDE lorsque Copilot, Claude Code et Cursor peuvent tous toucher le même dépôt.

Les équipes expérimentant l’orchestration multi-agents devraient également regarder Oh My OpenCode Agents pour des modèles sur la séparation des rôles entre agents – complémentaire aux artefacts SDD, et non un remplacement pour eux. Si votre équipe exécute un agent centré sur le terminal plutôt qu’un intégré à un IDE, le guide pratique de la CLI OpenCode montre la version plus légère, au niveau du prompt, de la même discipline de planifier-avant-implémenter – utile lorsque l’arborescence Spec Kit complète est plus de cérémonie que la tâche ne le mérite.

Tableau de décision pratique

Ce qui détermine réellement le succès

Le choix de l’outil importe moins que la qualité des artefacts. Un fichier d’exigences Kiro avec des critères d’acceptation vagues produira la même dérive qu’un prompt Claude Code paresseux. Un plan Spec Kit qui liste cinquante tâches redondantes ressemblera à un waterfall quel que soit l’agent qui l’implémente.

Les pratiques qui voyagent entre toutes les configurations sont ennuyeuses et efficaces. Gardez les spécifications assez petites pour être révisées en une seule séance. Écrivez les non-objectifs explicitement. Découpez les tâches en diffs que l’humain peut lire. Validez contre les critères d’acceptation avant fusion. Mettez à jour la spécification lorsque l’implémentation découvre un meilleur chemin.

Si vous hésitez encore entre le SDD et le promptage non structuré pour une fonctionnalité donnée, lisez Développement piloté par spécification vs Vibe Coding. La comparaison d’outils dans cet article n’a d’importance que lorsque vous avez décidé que la fonctionnalité mérite une spécification du tout.

De mauvaises spécifications rendent chaque agent moins performant. De bonnes spécifications voyagent entre les outils.

Conclusion

GitHub Spec Kit, Kiro et les flux de travail Claude Code sont trois réponses à la même question – comment garder les agents IA alignés entre les sessions – avec des mises différentes sur la portabilité face à l’intégration. Spec Kit optimise pour du markdown indépendant des agents dans votre dépôt. Kiro optimise pour un IDE natif de spécification guidé avec des agents soutenus par AWS. Les compétences Claude Code optimisent pour des flux de travail modifiables et légers qui ne réussissent que lorsque vous les maintenez.

Choisissez la configuration la plus superficielle qui supprime encore l’ambiguïté pour la fonctionnalité en question. Ajoutez de la structure lorsque la douleur de coordination apparaît, et non lorsqu’un article de blog vous le dit. Les développeurs qui tirent de la valeur du SDD en 2026 ne sont pas ceux ayant la chaîne d’outils la plus élaborée. Ce sont ceux qui écrivent des spécifications dignes d’être implémentées – puis laissent l’outil qu’ils ont choisi exécuter contre elles.

Liens utiles

• Documentation GitHub Spec Kit – référence officielle du flux de travail Spec Kit
• Guide rapide Superpowers : Installation, flux de travail et essai – paquet de compétences open source appliquant une méthodologie de brainstorming à TDD entre Claude Code, Cursor, Codex, et autres agents
• Martin Fowler sur les outils SDD – analyse de Kiro, Spec Kit, et Tessl