GitHub Spec Kit vs Kiro vs Claude Code SDD Workflows

Les développeurs qui comparent les configurations de développement piloté par spécifications (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 submerger de cérémonies 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 négocient différemment la portabilité, la profondeur d’intégration et la quantité de processus imposés.

Si vous avez besoin de comprendre les concepts en premier, lisez Qu’est-ce que le développement piloté par spécifications ? et le guide neutre en matière d’outils Flux de travail du développement piloté par spécifications dans le cluster de documentation Architecture d’application. Cette comparaison se trouve dans le hub Outils de développement IA aux côtés d’analyses d’assistants et de guides de flux de travail. Elle couvre les trois configurations sur lesquelles les développeurs débattent le plus sur Hacker News et les forums de style Reddit, ainsi que les alternatives plus légères et plus lourdes qui les entourent.

Le SDD devient une catégorie d’outils

Le développement piloté par spécifications (SDD) a cessé d’être un exercice théorique vers la fin de 2025. Chaque grand fournisseur de code IA propose désormais une version du cycle spécifier-planifier-implémenter, et une liste croissante d’outils autonomes concurrence sur la quantité de structure qu’ils ajoutent autour de cette boucle.

La comparaison qui compte n’est pas « quel outil gagne ». C’est profondeur du processus contre portabilité. Kiro est intégré. Spec Kit est portable. Les flux de travail Claude Code sont modulables. De mauvaises spécifications rendent chaque agent pire, quel que soit l’enveloppe que vous choisissez. De bonnes spécifications voyagent d’un outil à l’autre.

Comment comparer les configurations SDD

Avant de choisir un outil, nommez ce pour 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 la quantité d’examen nécessaire.

Portabilité — Les spécifications peuvent-elles vivre en 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 format propriétaire ?

Friction de configuration — Combien de temps faut-il entre « je veux essayer le SDD » et une boucle fonctionnelle spécifier-planifier-tâches ? Le scaffolding CLI, l’installation de l’IDE ou la création de vos propres commandes obliques 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 divise-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 tâches à cinquante éléments ?

Points de contrôle de révision — Y a-t-il des portes humaines naturelles entre spécifier, planifier, tâches et implémenter ? Le SDD sans révision n’est qu’un codage à l’intuition (vibe coding) plus lent.

Ancrage au dépôt — Le flux de travail lit-il les conventions du projet, les enregistrements de décision, les ADR, AGENTS.md et le code existant avant la planification ? Les agents sans ancre réinventent l’architecture car ils ne voient jamais l’intention revue 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 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 échafaude une boucle pilotée par spécification dans votre dépôt et délègue l’exécution à l’agent de codage que vous utilisez déjà. Le CLI specify dépose des modèles, des commandes obliques et une disposition de dossiers conventionnelle. Les commandes typiques suivent une séquence constitution-spécifier-clarifier-planifier-tâches-implémenter, avec une étape de clarification explicite pour résoudre les ambiguïtés avant le début du travail d’architecture.

L’avantage distinctif de Spec Kit est l’indépendance des 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 des spécifications une fois en markdown, les validez comme du code et changez l’exécuteur sans réécrire le processus. Cela fait de Spec Kit la recommandation par défaut pour les équipes qui souhaitent le SDD sans miser sur un seul fournisseur.

Les compromis sont réels. Spec Kit peut produire un grand arbre d’artefacts — constitution, spécification, plan, tâches, contrats — ce qui est rentable pour 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 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 surface guidée unique. Il superpose un processus à 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 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 de l’éditeur.

AWS Kiro

Kiro est l’IDE piloté par spécifications d’AWS, construit sur un fork VS Code / Code OSS. Là où Spec Kit apporte le SDD à votre stack existant, Kiro suppose que le SDD mérite un environnement conçu à cet effet. Une invite 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 le code de production.

L’expérience guidée est le principal atout de Kiro. Les exigences, la conception et les tâches sont des objets UI de premier plan à côté de votre code, pas des fichiers que vous gérez via un CLI séparé. Kiro est également livré avec des Agent Hooks, des automatisations pilotées par é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 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 échangée contre 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 gradés. Les équipes entreprises déjà sur l’infrastructure AWS trouvent souvent cela acceptable. Les développeurs solo et les équipes multi-éditeurs ne le sont peut-être pas. Kiro présente également les aspérités 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 avec l’adoption d’un IDE natif aux spécifications. C’est une option solide pour les équipes entreprises, les environnements lourds AWS et quiconque migre d’Amazon Q Developer et souhaite une discipline de spécification sans assembler la chaîne d’outils manuellement. Si vous vivez dans VS Code aujourd’hui 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 livre pas un seul produit SDD officiel comme le font 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 modèle SDD lui-même réside dans les commandes personnalisées, les compétences 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 SKILL.md (ou équivalent) qui définit votre liste de contrôle spécifier-planifier-implémenter, chargé sur demande.

Cette approche est la plus légère et la plus modulable. Vous pouvez importer une disposition à trois fichiers de style Kiro, mirer les phases de Spec Kit avec des commandes obliques, ou inventer un flux de travail minimal qui convient à un seul dépôt. Claude Code lit CLAUDE.md pour le contexte du 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 invite.

L’inconvénient est la discipline. Rien ne vous force à passer par des portes de clarification ou de révision à 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écifications 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, 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ées, révisées et maintenues — et non comme un téléchargement de prompt ponctuel.

Pour une implémentation sérieuse, lisez Claude Skills et SKILL.md pour les développeurs et encodez vos phases en tant que compétences avec des points de contrôle de révision 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.

BMAD, OpenSpec et autres flux de travail

Toutes les équipes ne veulent pas de l’arbre d’artefacts de 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 matérielle de jetons inférieure pour des tâches comparables, au détriment d’une structure en amont 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 concurrence Spec Kit sur la portabilité plutôt que Kiro sur l’intégration IDE.

BMAD-METHOD (communauté) pousse dans la direction opposée — des flux de travail multi-agents, basés sur les rôles, qui simulent les personas chef de produit, architecte, développeur et réviseur. BMAD peut être puissant sur les efforts greenfield importants où la séparation explicite des rôles aide. C’est également 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 « spécification-comme-source » la plus forte parmi les outils grand public, mais Tessl reste en beta et porte le verrouillage produit le plus élevé du groupe.

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

Le schéma à 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 importe plus que l’alignement. Adaptez le poids de l’outil à la taille de la tâche, pas au battage médiatique.

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 révision. N’installez pas un arbre Spec Kit complet pour un changement de cinquante lignes.

Développeur solo, fonction greenfield, plusieurs sessions. Spec Kit ou une compétence SDD Claude Code bien maintenue. Vous avez besoin d’artefacts durables plus que d’assistance IDE.

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

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

Environnement régulé. Kiro ou Spec Kit plus votre propre liste de validation — pas seulement les compétences Claude Code à moins que vous n’encodiez explicitement les portes de conformité. L’outillage ne remplace pas les traçabilités d’audit. Il les rend seulement plus faciles à produire.

Base de code existante, changement brownfield. OpenSpec ou un flux de travail Claude Code léger. La cérémonie complète de Spec Kit sur chaque correctif de bug semblera comme une cascade. Réservez une structure plus lourde pour les fonctionnalités transversales.

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

Les équipes expérimentant avec l’orchestration multi-agent devraient également regarder Oh My OpenCode Agents pour des modèles de division des rôles entre agents — complémentaire aux artefacts SDD, pas un remplacement.

Tableau décisionnel 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 négligent. Un plan Spec Kit qui liste cinquante tâches redondantes semblera comme une cascade, 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. Divisez les tâches en diffs qu’un humain peut lire. Validez contre les critères d’acceptation avant la fusion. Mettez à jour la spécification lorsque l’implémentation découvre un meilleur chemin.

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

De mauvaises spécifications rendent chaque agent pire. De bonnes spécifications voyagent d’un outil à l’autre.

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 différents paris sur la portabilité contre l’intégration. Spec Kit optimise pour le markdown agnostique aux agents dans votre dépôt. Kiro optimise pour un IDE natif aux spécifications guidé avec des agents soutenus par AWS. Les compétences Claude Code optimisent pour des flux de travail légers et modulables qui ne réussissent que lorsque vous les maintenez.

Choisissez la configuration la plus superficielle qui élimine tout de même l’ambiguïté pour la fonctionnalité en question. Ajoutez de la structure lorsque la douleur de coordination apparaît, pas quand un article de blog vous le dit. Les développeurs qui tirent de la valeur du SDD en 2026 ne sont pas ceux avec 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
• Martin Fowler sur les outils SDD — analyse de Kiro, Spec Kit et Tessl