GitHub Spec Kit contre Kiro contre les flux de travail SDD de Claude Code

Les développeurs qui comparent les configurations de développement spécifié (Spec-Driven Development) en 2026 ne demandent généralement pas quel modèle est le plus intelligent. Ils se demandent quel flux de travail maintiendra un agent IA aligné sans les noyer dans des formalités 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 font des compromis entre portabilité, profondeur d’intégration et la quantité de processus qu’ils imposent.

Si vous avez besoin des concepts d’abord, lisez Qu’est-ce que le développement spécifié ? et le guide neutre en termes d’outils Flux de travail de développement spécifié 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 spécifié (Spec-Driven Development) a cessé d’être un exercice sur le papier à un certain moment de la fin 2025. Tous les grands fournisseurs de codage IA proposent désormais une version de la boucle spécifier-planifier-implémenter, et une liste croissante d’outils autonomes se dispute quant à 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 Claude Code sont modifiables. De mauvaises spécifications rendent tous les agents pires, quel que soit l’enveloppe choisi. De bonnes spécifications voyagent entre les outils.

Comment comparer les configurations SDD

Avant de choisir un outil, nommez ce sur 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 relecture dont vous avez besoin.

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 au prochain trimestre ? Ou sont-elles liées à un seul IDE, à un seul cloud ou à un format propriétaire ?

Friction de configuration – Combien de temps passe-t-il entre « je veux essayer SDD » et une boucle fonctionnelle spécifier-planifier-tâches ? Le scaffolding CLI, l’installation 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 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 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 par intuition (vibe coding) plus lent.

Ancrage au dépôt – Le flux de travail lit-il les conventions du projet, les enregistrements de décisions, 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 révisée derrière les choix précédents.

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

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

GitHub Spec Kit

GitHub Spec Kit est un kit d’outils CLI open source qui met en place une boucle de développement spécifié dans votre dépôt et confie l’exécution à l’agent de codage que vous utilisez déjà. Le 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 l’ambiguïté avant que le travail d’architecture ne commence.

L’avantage déterminant de Spec Kit est l’indépendance par rapport à l’agent. La documentation officielle le positionne comme un outil 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, les commitez comme du code et changez l’exécutant sans réécrire le processus. Cela fait de Spec Kit la recommandation par défaut pour les équipes qui veulent SDD sans miser 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 – qui se paie pour les fonctionnalités multi-sessions, mais qui semble lourd pour un petit ajustement de CLI. Les fils de Hacker News comparent régulièrement cette surcharge à la cérémonie waterfall. Spec Kit est aussi moins efficace 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 le 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 greenfield, les environnements multi-agents et quiconque refuse le verrouillage d’éditeur.

AWS Kiro

Kiro est l’IDE spécifié d’AWS, construit sur une fourche VS Code / Code OSS. Là où Spec Kit apporte SDD à votre pile existante, Kiro suppose que SDD mérite un environnement dédié. 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 un CLI séparé. Kiro expédie également des Agent Hooks, des automatisations pilotées par des événements qui peuvent mettre à jour les tests, la documentation ou les artefacts connexes lorsque l’implémentation change. Cette boucle bidirectionnelle est quelque chose que Spec Kit ne fournit pas par défaut – les spécifications Spec Kit restent statiques jusqu’à ce qu’un humain les mette à jour.

Les coûts sont une 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 les 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 être du même avis. Kiro a aussi des bords rugueux 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 spécification. C’est une option forte pour les équipes d’entreprise, les environnements centrés sur 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 dans VS Code aujourd’hui et que vous adorez votre configuration actuelle, Kiro demande un changement plus important que Spec Kit.

Commandes personnalisées et compétences de Claude Code

Claude Code n’expédie pas de produit SDD officiel unique comme Spec Kit ou Kiro. Si vous êtes nouveau sur 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 de 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 des Skills, 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 s’adapte à un seul dépôt. Claude Code lit CLAUDE.md pour le contexte projet toujours actif et tire les compétences lorsque la tâche correspond. Cette révélation progressive maintient les sessions concentrées sans charger une constitution complète à chaque invite.

L’inconvénient est la discipline. Rien ne vous force à passer par les portes de précision ou de revue à moins que vous ne construisiez ces portes vous-même. Les fils Reddit et Hacker News sur le « développement spécifié dans Claude Code » sont remplis de développeurs qui ont copié la compétence de quelqu’un d’autre, l’ont exécutée une fois, puis sont revenus au prompting non structuré lorsque la compétence leur semblait lente. Le SDD Claude Code fonctionne lorsque vous traitez les compétences comme du code – versionnées, révisées et maintenues – 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 encodent vos phases en tant que 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 vous-même le flux de travail. Pour l’étape de porte de revue spécifiquement, les sous-agents Claude Code peuvent exécuter une passe de revue indépendante à contexte isolé sur le code généré avant que vous ne fusionniez une tâche – un substitut léger au 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 créer cette pile de compétences à la main ressemble exactement au problème de discipline que le tableau ci-dessus met en garde, Superpowers} mérite un regard. 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é en tant que plugin installable plutôt que quelque chose que vous écrivez de zéro. Il vise 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 de développement spécifié Des exigences au code : la brainstorming affine une idée vague en un document de conception révisé, la rédaction de plans le découpe en petites tâches vérifiables, le développement piloté par sous-agents dispatche un nouveau sous-agent par tâche avec une revue en deux étapes, et le développement piloté par les tests 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 Claude Code ne se donnent la peine d’être – Superpowers supprime explicitement le code écrit avant qu’un test échoué n’existait pour lui.

Contrairement à une compétence locale au dépôt que vous écrivez vous-même, Superpowers n’est pas exclusif à Claude Code. Il expédie 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 à travers les harnais au lieu de vivre dans un seul dossier .claude/skills/. Cela en fait un terrain d’entente entre créer votre propre compétence Claude Code et adopter un outil plus lourd, spécifique à l’IDE comme Kiro : vous obtenez une boucle opinée et imposée sans renoncer à votre éditeur ou vous engager envers 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 continuellement vers le prompting non structuré parce que rien ne force les portes de revue. C’est un choix plus faible 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’arbre 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 utilisation de tokens matériellement plus faible pour des tâches comparables, au prix d’une structure initiale moins grande. 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é plus qu’avec Kiro sur l’intégration IDE. Voir le guide de démarrage rapide d’OpenSpec} pour les étapes d’installation, la boucle explorer-propose-apply-archive et les pièges qui apparaissent le plus sur Reddit.

BMAD-METHOD (communauté) pousse dans la direction opposée – flux de travail multi-agents, basés sur les rôles, qui simulent les personas de propriétaire produit, architecte, développeur et réviseur. 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 fréquemment que la cérémonie ne se 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 éditions manuelles. C’est la position « spécification comme source » la plus forte parmi les outils mainstream, mais Tessl reste en bêta et porte le verrouillage de 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.

gstack va un pas au-delà de la couche de spécification : il enveloppe l’agent de codage dans une équipe virtuelle de génie complète – revue produit, revue d’architecture et de conception, QA navigateur, audits de sécurité, et la chaîne de publication ship-deploy – de sorte que la spécification est l’une des plusieurs étapes imposées au lieu d’être la colonne vertébrale. Il fonctionne sur Claude Code et neuf autres agents, et le guide couvre comment laisser Spec Kit (ou OpenSpec) posséder la colonne vertébrale de la planification tandis que gstack fournit les couches qu’un outil de spécification n’impose pas.

Le motif à 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 compte plus que l’alignement. Adaptez le poids de l’outil à la taille de la tâche, pas à l’hypocrisie.

Quel environnement 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 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 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-réviser 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 maintenue. Vous avez besoin d’artefacts durables plus que d’une prise de main IDE.

Petite équipe, éditeurs mixtes. Spec Kit. Spécifications markdown simples dans Git, révisées dans les demandes de tirage, 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 maintiennent 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 les portes de conformité explicitement. Les outils ne remplacent pas les pistes d’audit. Ils ne les rendent que plus faciles à produire.

Base de code existante, changement 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 à du waterfall. Réservez la structure plus lourde pour les fonctionnalités transversales.

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

Les équipes qui expérimentent l’orchestration multi-agents devraient aussi regarder Oh My OpenCode Agents} pour les motifs de division des rôles entre les agents – complémentaire aux artefacts SDD, pas un remplacement pour eux. Si votre équipe exécute un agent premier en terminal au lieu d’un intégré à l’IDE, le guide pratique de la CLI OpenCode montre la version plus légère, au niveau du prompt, de la même discipline planifier-avant-d-implémenter – utile lorsque un arbre Spec Kit complet est plus de cérémonie que la tâche ne le justifie.

Tableau de décision pratique

Ce qui détermine réellement la réussite

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 paresseux. Un plan Spec Kit qui liste cinquante tâches redondantes ressemblera au 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 révisées en une seule séance. Écrivez les non-objectifs explicitement. Découpez les tâches en diffs que l’on peut lire. Validez par rapport aux critères d’acceptation avant la 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 prompting non structuré pour une fonctionnalité donnée, lisez Développement spécifié vs Codage par intuition. La comparaison des outils dans cet article n’a de sens que lorsque vous avez décidé que la fonctionnalité mérite une spécification.

De mauvaises spécifications rendent tous les agents pires. 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 maintenez-vous les agents IA alignés entre les sessions – avec différents paris sur la portabilité par rapport à l’intégration. Spec Kit optimise pour un markdown agnostique de l’agent dans votre dépôt. Kiro optimise pour un IDE natif 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 moins profonde qui élimine encore l’ambiguïté pour la fonctionnalité en cours. Ajoutez de la structure lorsque la douleur de coordination apparaît, et non lorsque le billet 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 s’exécuter contre elles.

Liens utiles

• Documentation GitHub Spec Kit – référence officielle du flux de travail Spec Kit
• Superpowers Guide de démarrage rapide : Installation, Flux de travail et Essai} – paquet de compétences open source imposant une méthodologie de brainstorming à TDD à travers Claude Code, Cursor, Codex et d’autres agents
• gstack : Une pile de génie logiciel IA opinée} – l’option de l’équipe de génie virtuelle complète, et comment elle se combine avec Spec Kit, OpenSpec et Superpowers
• Martin Fowler sur les outils SDD – analyse de Kiro, Spec Kit et Tessl