GitHub Spec Kit vs Kiro vs Flux de travail SDD de Claude Code

Les développeurs qui comparent les configurations de développement piloté par spécifications (Spec-Driven Development) en 2026 ne se demandent généralement pas quel modèle est le plus intelligent. Ils se demandent quel flux de travail permettra de garder un agent IA aligné sans les noyer dans la cérémonie.

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 opèrent des compromis entre portabilité, profondeur d’intégration et la quantité de processus qu’ils imposent.

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

Le SDD devient une catégorie d’outils

Le développement piloté par spécifications (SDD) a cessé d’être un exercice sur le papier à la fin de l’année 2025. Chaque grand fournisseur de codage IA propose désormais une version de la boucle spécifier-planifier-implémenter, et une liste croissante d’outils autonomes rivalise sur la quantité de structure qu’ils ajoutent autour de cette boucle.

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

Comment comparer les configurations SDD

Avant de choisir un outil, nommez ce pour quoi vous optimisez. La même fonctionnalité peut sembler effortless dans une configuration et bureaucratique dans une autre, selon la taille de l’équipe, l’âge de la base de code et la quantité de revue nécessaire.

Portabilité – Les spécifications peuvent-elles vivre en tant que markdown brut 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 seul format propriétaire ?

Friction de configuration – Combien de temps entre « je veux essayer le SDD » et une boucle fonctionnelle spécifier-planifier-tâches ? Le scaffolding CLI, l’installation d’un IDE ou la création de vos propres commandes slash ont tous une énergie d’activation différente.

Qualité des spécifications – L’outil vous aide-t-il à écrire 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 aux explosions de listes de cinquante tâches ?

Points de contrôle de revue – Y a-t-il des portes humaines naturelles entre spécifier, planifier, tâches et implémenter ? Le SDD sans revue n’est qu’un codage à l’intuition 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 revue derrière les choix précédents.

Collaboration d’équipe – Plusieurs personnes peuvent-elles revoir les mêmes artefacts de spécification dans des 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 de fournisseur cloud dans six mois ?

GitHub Spec Kit

GitHub Spec Kit est un kit d’outils CLI open source qui met en place une boucle pilotée par spécifications 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 clarification pour résoudre l’ambiguïté avant le début du travail d’architecture.

L’avantage définissant de Spec Kit est l’indépendance par rapport aux agents. La documentation officielle le positionne comme un outillage qui fonctionne avec Claude Code, GitHub Copilot, Cursor, Gemini CLI, Codex et des dizaines d’autres agents. Vous écrivez les 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 le SDD sans parier sur un fournisseur unique.

Les compromis sont réels. Spec Kit peut produire un grand arbre d’artefacts — constitution, spécification, plan, tâches, contrats — ce qui paie pour les fonctionnalités multi-séances mais semble lourd pour un petit ajustement de CLI. Les fils de Hacker News comparent régulièrement cette surcharge à la cérémonie en cascade (waterfall). Spec Kit est également plus faible si vous voulez un IDE entièrement intégré où les spécifications, les tâches et l’implémentation vivent dans une seule surface guidée. 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 préféré et qui veulent un échafaudage SDD standardisé par-dessus. Il est particulièrement fort pour les fonctionnalités vertes (greenfield), les environnements multi-agents et quiconque refuse le verrouillage par l’éditeur.

AWS Kiro

Kiro est l’IDE piloté par spécifications d’AWS, construit sur un fork de VS Code / Code OSS. Là où Spec Kit apporte le SDD à votre pile existante, Kiro suppose que le SDD mérite un environnement conçu à cet effet. Un prompt génère des artefacts structurés — typiquement requirements.md en notation de style 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 d’interface utilisateur de premier ordre à côté de votre code, et non des fichiers que vous gérez via une CLI séparée. Kiro fournit également des Agent Hooks, des automatisations pilotées par événements qui peuvent mettre à jour les tests, la documentation ou les artefacts associés lorsque l’implémentation change. Cette boucle bidirectionnelle est quelque chose que Spec Kit ne fournit pas par défaut — les spécifications de Spec Kit restent statiques jusqu’à ce qu’un humain les mette à jour.

Les coûts sont la profondeur d’intégration échangée contre la portabilité. Kiro fonctionne 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 niveaux. 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 en être. Kiro a aussi des arêtes vives 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 pour spécifications. C’est une option forte pour les équipes d’entreprise, les environnements lourds en AWS et quiconque migre d’Amazon Q Developer et veut la discipline des spécifications 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 personnalisées et compétences de Claude Code

Claude Code ne fournit pas un seul produit SDD officiel de la manière dont le font Spec Kit ou Kiro. Si vous êtes nouveau dans l’outil lui-même, commencez par le guide d’installation et de configuration de Claude Code pour la configuration, les permissions et les backends locaux. Le motif SDD lui-même vit 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 fusionné les anciens fichiers .claude/commands/*.md dans le mécanisme de compétences, donc le motif durable est un 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 porter une disposition à trois fichiers de style 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 portes de clarification ou de revue à moins que vous ne construisiez ces portes vous-même. Les fils de Reddit et Hacker News sur le « développement piloté par spécifications dans Claude Code » sont pleins de développeurs qui ont copié la compétence d’un autre, l’ont exécutée une fois, et sont retournés au prompting non structuré lorsque la compétence semblait lente. Le SDD de Claude Code fonctionne lorsque vous traitez les compétences comme du code — versionné, revu et maintenu — et non comme un téléchargement de prompt à usage unique.

Pour une implémentation sérieuse, lisez Compétences Claude et SKILL.md pour développeurs et encodez vos phases comme des compétences avec des points de contrôle de revue explicites. Le SDD de Claude Code est le bon choix lorsque vous vivez déjà dans Claude Code, voulez une flexibilité maximale et maintiendrez vous-même le flux de travail. Pour l’étape de porte de revue spécifiquement, les sous-agents de 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 bricoler cette pile de compétences ressemble exactement au problème de discipline que le tableau ci-dessus met en garde, Superpowers mérite un coup d’œil. C’est un paquet de compétences open source — brainstorming, rédaction de plans, développement piloté par sous-agents, développement piloté par les tests, demande de revue de code, et une poignée de compétences de soutien — distribué comme un plugin installable plutôt que comme 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 se mappe étroitement sur la boucle à cinq phases couverte dans Flux de travail du développement piloté par spécifications, des exigences au code : le brainstorming affine une idée vague en un document de conception revu, writing-plans le découpe en petites tâches vérifiables, subagent-driven-development dispatche un sous-agent frais par tâche avec une revue en deux étapes, et test-driven-development impose un strict rouge-vert-refactor avant que quoi que ce soit ne soit considéré comme terminé. Cette dernière partie est plus stricte que la plupart des compétences SDD de Claude Code ne prennent la peine de l’être — Superpowers supprime explicitement le code écrit avant l’existence d’un test défaillant.

Contrairement à une compétence locale au dépôt que vous écrivez vous-même, Superpowers n’est pas exclusif à Claude Code. Il fournit des manifestes de plugins pour Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot CLI, Devin, Factory Droid et plusieurs autres agents, de sorte que la même méthodologie vous suit entre les harnais au lieu de vivre dans un seul dossier .claude/skills/. Cela en fait un terrain intermédiaire entre bricoler votre propre compétence Claude Code et adopter un outil plus lourd et spécifique à l’IDE comme Kiro : vous obtenez une boucle opinionnée et imposée sans renoncer à votre éditeur ou vous engager dans le format de spécification d’un fournisseur unique.

Superpowers convient aux développeurs qui aiment l’approche des compétences Claude Code en principe mais qui glissent constamment vers le prompting non structuré parce que rien n’impose 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 l’arbre d’artefacts de Spec Kit ou l’IDE de 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 de la communauté rapportent une utilisation de jetons matériellement inférieure pour des tâches comparables, au prix 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 rivalise avec Spec Kit sur la portabilité plus qu’avec Kiro sur l’intégration IDE.

BMAD-METHOD (communauté) pousse dans la direction opposée — flux de travail multi-agents, basés sur les rôles, qui simulent les personnalités de propriétaire produit, architecte, développeur et relecteur. BMAD peut être puissant sur de grands efforts verts (greenfield) où la séparation explicite des rôles aide. C’est aussi lourd. Les équipes rapportent fréquemment que la cérémonie ne paie 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 modifications manuelles. C’est la position la plus forte « spécification-comme-source » parmi les outils grand public, 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 poids. Ils méritent d’être surveillés si vous voulez des modèles sans adopter la chaîne d’outils GitHub complète.

Le motif à travers tous eux est le même. Plus de processus aide lorsque l’ambiguïté est coûteuse. Plus de processus nuit lorsque la vitesse de rétroaction compte plus que l’alignement. Faites correspondre le poids de l’outil à la taille de la tâche, et non au hype.

Quelle configuration SDD devriez-vous utiliser ?

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

Développeur solo, base de code existante, petites fonctionnalités. Commencez par 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 un arbre Spec Kit complet pour un changement de cinquante lignes.

Vous voulez l’approche des compétences Claude Code mais continuez à sauter vos propres portes de revue. Installez Superpowers au lieu d’écrire une compétence personnalisée de zéro. Vous renoncez à un peu d’ajustement spécifique au projet en échange d’une boucle brainstorming-planifier-implémenter-revoir imposée qui ne dépend pas de votre discipline ce jour-là.

Développeur solo, fonctionnalité verte (greenfield), plusieurs sessions. Spec Kit ou une compétence SDD Claude Code bien maintenue. Vous avez besoin d’artefacts durables plus que d’une aide de la main de l’IDE.

Petite équipe, éditeurs mélangés. Spec Kit. Spécifications markdown brutes dans Git, revues dans des pull requests, exécutées par l’agent préféré de chaque développeur.

Équipe d’entreprise, native AWS, pression de conformité. Kiro. Artefacts guidés, traçabilité 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 uniquement des compétences Claude Code à moins que vous n’encodiez explicitement des portes de conformité. Les outillages ne remplacent pas les pistes d’audit. Ils ne font que les rendre plus faciles à produire.

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

Produit vert (greenfield), nombreux agents. Spec Kit. La portabilité compte plus que la finition de l’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 motifs de division des rôles entre agents — complémentaire aux artefacts SDD, et non un remplacement pour eux.

Tableau de décision pratique

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

Le choix de l’outil compte 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 négligé. Un plan Spec Kit qui liste cinquante tâches redondantes semblera un waterfall quel que soit l’agent qui l’implémente.

Les pratiques qui voyagent à travers chaque configuration sont ennuyeuses et efficaces. Gardez les spécifications assez petites pour être revues en une seule séance. Écrivez les non-objectifs explicitement. Découpez les tâches en diffs qu’un humain peut lire. Validez par rapport aux critères d’acceptation avant fusion. Mettez à jour la spécification lorsque l’implémentation découvre un meilleur chemin.

Si vous choisissez encore entre le SDD et le prompting non structuré pour une fonctionnalité donnée, lisez Développement piloté par spécifications vs Codage à l’intuition. La comparaison des outils dans cet article ne compte que lorsque vous avez décidé que la fonctionnalité mérite une spécification.

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 paris différents sur la portabilité par rapport à l’intégration. Spec Kit optimise pour le markdown agnostique par rapport aux agents dans votre dépôt. Kiro optimise pour un IDE natif pour spécifications 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 qui ont 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 de leur choix exécuter contre elles.

Liens utiles

• Documentation GitHub Spec Kit – référence du flux de travail officiel de Spec Kit
• Superpowers Quickstart : Installation, Flux de travail et Essai – paquet de compétences open source imposant une méthodologie brainstorming-vers-TDD à travers Claude Code, Cursor, Codex et autres agents
• Martin Fowler sur les outils SDD – analyse de Kiro, Spec Kit et Tessl