Spec Kit ou OpenSpec : lequel convient à votre flux de codage avec l'IA

Spec Kit et OpenSpec sont deux outils open source sous licence MIT qui visent le même problème : lorsque les exigences n’existent que dans l’historique de chat, le résultat d’un assistant de codage IA est difficile à prévoir ; on écrit donc la spécification et l’on laisse l’humain et l’IA se mettre d’accord avant d’écrire du code. Ils diffèrent par le poids du processus, la façon d’organiser les spécifications et la chaîne d’outils.

Notre position d’abord

Le flux de travail de HagiCode repose sur OpenSpec : nous avons donc un parti pris. Les faits ci-dessous proviennent de la documentation officielle des deux projets, vérifiée le 2026-10-26, et tout ce qui relève de notre opinion est indiqué comme tel. Les deux projets évoluent vite : lisez la documentation la plus récente de chacun avant de choisir.

Ce qui est comparé

• Spec Kit : proposé par GitHub. La ligne de commande est specify (le paquet Python specify-cli) ; voir Installer Spec Kit pour l’installation et l’usage.
• OpenSpec : proposé par Fission AI. La ligne de commande est openspec (le paquet npm @fission-ai/openspec) ; voir l’Introduction à OpenSpec.

Principales différences

Critère	Spec Kit	OpenSpec
Environnement d’exécution	Python 3.11+, installé avec uv ou pipx	Node.js 20.19.0+, installé avec npm ou Homebrew
Commande d’installation	uv tool install specify-cli	npm install -g @fission-ai/openspec@latest
Initialisation	specify init my-project --integration claude	openspec init dans le projet
Préfixe des commandes	/speckit-*	/opsx:* (/opsx-* dans certains assistants, $openspec-* dans Codex)
Flux principal	constitution → specify → clarify → plan → checklist → tasks → analyze → implement → converge ; le chemin le plus court est specify → plan → tasks → implement → converge	Le profil par défaut comprend propose, explore, apply, update, sync et archive ; le profil étendu ajoute new, continue, ff, verify et d’autres
Artefacts par fonctionnalité	spec.md, plan.md, tasks.md, plus les listes de contrôle et les résultats d’analyse	Un dossier de changement contenant proposal.md, specs/, design.md et tasks.md
Organisation des spécifications	Une spécification complète rédigée autour d’une seule fonctionnalité	Construit autour des spécifications delta : ADDED et MODIFIED décrivent le changement et sont fusionnés dans les spécifications durables à l’archivage
Extensibilité	Extensions et préréglages ; les extensions officielles incluent bug et assess	Schémas personnalisés et schémas communautaires
Plusieurs dépôts	Nous n’avons pas trouvé de prise en charge multi-dépôts dédiée dans le flux principal de la documentation officielle	Stores (bêta) conserve la planification dans un dépôt à part et la partage entre les dépôts de code
Assistants pris en charge	La documentation officielle liste des dizaines d’intégrations	La documentation officielle annonce plus de 30 outils
Licence	MIT	MIT

Poids du processus : la différence la plus souvent citée

Le README d’OpenSpec résume Spec Kit comme complet mais lourd, avec des portes de phase rigides, beaucoup de Markdown et une installation Python, et se positionne comme plus léger, en permettant de réviser n’importe quel artefact à tout moment. C’est la description qu’OpenSpec fait de lui-même.

Pour être juste : le guide de démarrage de Spec Kit propose lui-même un chemin le plus court en cinq étapes où constitution, clarify, checklist et analyze sont facultatifs, et le profil étendu d’OpenSpec compte lui aussi bien des commandes. La vraie différence n’est pas le nombre de commandes mais la posture par défaut. Spec Kit ressemble davantage à un pipeline qui va de la spécification à l’implémentation et converge à la fin, tandis qu’OpenSpec insiste sur le fait que chaque changement est un dossier indépendant que l’on peut modifier à tout moment.

Choisir selon le scénario

Les conseils ci-dessous sont notre jugement, pas une conclusion officielle de l’un ou l’autre projet.

Votre situation	Meilleur choix	Pourquoi
Un nouveau projet, avec l’envie d’un flux complet de la spécification à l’implémentation	Spec Kit	Un flux complet, une constitution qui encadre tout le projet et converge pour boucler par rapport à la spécification
Beaucoup de code existant, avec de petits changements à chaque fois	OpenSpec	Les spécifications delta ne décrivent que ce qui change, sans réécrire une spécification complète pour les fonctionnalités existantes
Une équipe surtout Python, habituée à uv	Spec Kit	La méthode d’installation correspond à la pile
Une équipe surtout Node.js	OpenSpec	Une seule commande npm l’installe
Une fonctionnalité touche plusieurs dépôts	OpenSpec	Stores peut conserver le plan dans un dépôt partagé ; notez qu’il est encore en bêta
Vous voulez beaucoup d’extensions toutes faites (correction de bugs, évaluation d’idées)	Spec Kit	Le site officiel liste davantage d’extensions et de préréglages
Les exigences changent souvent et vous voulez modifier spécifications et plans à tout moment	OpenSpec	Les artefacts n’ont pas de phases strictes : on peut revenir en arrière et les modifier

Conseils pour décider

1. Regardez votre pile et vos habitudes avant les fonctionnalités. Les deux se recoupent beaucoup en capacités, et la friction d’un environnement mal adapté compte souvent davantage.
2. Essayez chacun sur la même petite fonctionnalité. Choisissez une exigence réalisable en une demi-journée et parcourez le flux complet avec chacun. C’est plus fiable que de lire dix articles comparatifs.
3. N’installez pas les deux dans le même projet. Les deux outils génèrent des commandes et des répertoires dans le projet, et les mélanger encombre la liste de commandes de votre assistant.
4. Jugez sur trois points : l’écriture de la spécification a-t-elle réellement réduit les reprises, votre assistant IA est-il officiellement pris en charge, et l’équipe est-elle prête à maintenir ces fichiers Markdown.

La pratique de HagiCode

Nous utilisons OpenSpec depuis longtemps et avons construit autour de lui la gestion de spécifications multi-dépôts et le choix d’un Agent par étape, décrits dans ces deux articles : Optimiser l’efficacité des différentes phases d’OpenSpec avec différents agents : Résumé des pratiques HagiCode et MonoSpecs qu’est-ce que c’est : pourquoi c’est une évolution et une extension supplémentaire d’OpenSpec. C’est notre choix et il n’est pas forcément meilleur pour toutes les équipes. Si Spec Kit convient mieux à la vôtre, il fonctionne tout aussi bien avec les Agent CLI pris en charge par HagiCode, comme Claude Code et Codex ; voir Installation des AI Agent CLI pour la préparation.

Parcours recommandé

• Pour en essayer un rapidement : choisissez celui qui correspond à votre pile, installez-le et ne suivez que le chemin le plus court sur une petite fonctionnalité.
• Pour comparer sérieusement : appliquez le point 2 ci-dessus avec les deux, puis décidez selon « la quantité de reprises » et « l’adhésion de l’équipe ».
• Pour approfondir : lisez Installer Spec Kit et l’Introduction à OpenSpec.