Spec Kit : le guide 2027 du toolkit de GitHub, de la spec au code

Spec Kit, c'est la réponse de GitHub au vibe coding qui part dans tous les sens : un toolkit open source qui fait écrire la spécification avant de laisser un agent coder. Sorti en septembre 2025, passé en 1.0 cet été, il tourne aujourd'hui avec une quarantaine d'agents, de Claude Code à Copilot. On le range volontiers dans la boîte à outils des Développeurs, alors qu'une bonne partie du travail qu'il demande se fait côté Produit. Décryptage d'un outil à cheval entre le Produit et la Tech, de son fonctionnement à ses limites.

"Written for business stakeholders, not developers."

C'est écrit noir sur blanc dans les consignes que Spec Kit donne à l'agent chargé de rédiger chaque spécification : le document s'adresse aux parties prenantes métier plutôt qu'aux Développeurs. Venant d'un outil signé GitHub, qu'on installe en ligne de commande avec Python et un gestionnaire de paquets, la consigne a de quoi surprendre !

Elle a pourtant sa logique. Spec Kit fait passer chaque fonctionnalité par deux temps : une spec, qui décrit le besoin sans un mot de technique, puis un plan et des tâches, où l'équipe fait ses choix techniques avant que l'agent code. Pour livrer quelque chose qui tient, l'outil a donc besoin que le Produit fasse sa part avant que la Tech fasse la sienne.

Sommaire

1. Spec Kit, c'est quoi ?
2. Comment fonctionne Spec Kit : de la constitution au code
3. Comment installer Spec Kit et lancer un premier projet ?
4. Qui écrit la spec ? Le partage entre Product Manager et Développeur
5. Comment utiliser Spec Kit avec Claude Code, Copilot ou Cursor ?
6. Quelles sont les limites de Spec Kit ?
7. Spec Kit, OpenSpec, BMAD : quelles différences ?
8. Alors, qu'est-ce que Spec Kit change pour une équipe Produit ?
9. FAQ

Spec Kit, c'est quoi ?

Spec Kit est un toolkit open source de GitHub pour faire du spec-driven development avec un agent de code. Concrètement, c'est une CLI, specify, qui installe dans votre projet une série de commandes : on décrit ce qu'on veut construire et pourquoi, et l'agent en tire un plan, une liste de tâches, puis le code.

Le spec-driven development, c'est le principe derrière tout ça : la spécification devient la source de vérité que l'agent exécute, au lieu de consignes égrenées au fil d'une conversation. Et GitHub ne chôme pas sur le sujet. Présenté le 2 septembre 2025 sous licence MIT, Spec Kit est passé en 1.0 le 21 août 2026 et en était à la 1.2.6 le 2 novembre, avec 240 versions publiées depuis le lancement, soit à la louche une tous les deux jours !

Au fil de ces versions, l'outil a pris de l'épaisseur. Son README propose désormais trois processus prêts à l'emploi : le spec-driven development, une extension pour corriger des bugs, et une autre pour évaluer une idée avant d'écrire la moindre spec (celle-là, on y revient plus bas, parce qu'elle parle directement aux PM).

Une précision pour ceux qui cherchent un serveur MCP : Spec Kit fonctionne autrement, en déposant des commandes (ou des skills, selon l'agent) directement dans le projet. La commande specify mcp, arrivée récemment, reste expérimentale et sert seulement à inspecter l'installation, en lecture seule.

Comment fonctionne Spec Kit : de la constitution au code

Spec Kit avance par étapes, et chaque étape laisse un fichier markdown que la suivante reprend. On pose une constitution une fois pour toutes, puis chaque fonctionnalité passe par le même circuit, avec une relecture humaine entre deux commandes.

La constitution, c'est le règlement intérieur du projet : les principes que l'agent doit respecter à chaque changement, comme écrire les tests avant le code ou commencer simple. Et pour qu'elle ne reste pas un vœu pieux, le gabarit du plan l'intègre comme point de contrôle avant toute décision technique.

Converge, la dernière arrivée (juin 2026), est sans doute la plus maligne. Elle compare le code produit à la spec, au plan et aux tâches, puis remet dans la liste ce qui manque encore. On relance l'implémentation jusqu'à ce que tout converge. Un agent qui annonce fièrement "terminé" un peu trop tôt, c'est précisément ce qu'elle sert à attraper.

Petit piège pour démarrer : la syntaxe des commandes change selon l'agent (/speckit-specify avec les skills de Copilot ou de Claude Code, /speckit.specify dans la documentation de référence, $speckit-specify avec Codex). Le plus sûr est de reprendre ce qu'affiche specify init à la fin de l'installation.

Comment installer Spec Kit et lancer un premier projet ?

L'installation demande Python 3.11 ou plus, le gestionnaire de paquets uv et un agent de code, sous Linux, macOS ou Windows. Après, deux commandes suffisent, ici pour Claude Code :

uv tool install specify-cli
specify init mon-projet --integration claude

Avec Claude Code et la version 1.2.6, on récupère deux dossiers : .claude/skills/, avec une skill par commande, et .specify/, qui contient la constitution à remplir, les gabarits de spec, de plan et de tâches, et les scripts qui ouvrent un dossier par fonctionnalité. On lance ensuite l'agent dans le projet, en commençant par la constitution.

Pour la spec, on écrit comme on rédigerait une expression de besoin :

/speckit-specify Les clients doivent pouvoir exporter leurs commandes en CSV depuis la page "Mes commandes", pour les retraiter dans leur outil de comptabilité. Priorité : les commandes du mois en cours. Hors périmètre : la planification automatique des exports.

Pas un mot sur la base de données ni sur la manière de générer le fichier : ces questions-là attendront le plan.

Sur un projet existant, la documentation conseille de partir d'un dépôt propre (tout committer, ouvrir une branche), de lancer specify init --here --force --integration claude, puis de relire le diff. Spec Kit ne réécrit pas l'application et ne devine aucune spec à partir du code. Pour un premier essai, le guide recommande un changement bien délimité, comme un export CSV sur une page qui existe déjà, et déconseille explicitement le chantier "documenter tout le système existant".

Qui écrit la spec ? Le partage entre Product Manager et Développeur

Les fichiers de Spec Kit désignent assez clairement le Product Manager pour la spec, et l'équipe Tech pour le plan, même si l'outil ne le formule jamais ainsi.

Dès novembre 2025, le Technology Radar de Thoughtworks relevait que, quand ces outils produisent des PRD ou des user stories, on ne sait pas toujours à qui ils s'adressent. Dans Spec Kit, la réponse figure dans les consignes de l'agent : la spec décrit ce dont les utilisateurs ont besoin et pourquoi, jamais le comment (ni stack, ni API, ni structure de code), et elle s'écrit pour les "business stakeholders" de l'introduction.

Dans le document de méthode du projet, GitHub imagine même un Product Manager qui modifie des critères d'acceptation, et des plans qui signalent aussitôt les décisions techniques touchées. C'est une ambition, difficile à vérifier dans l'outil aujourd'hui, mais on voit bien à qui la spec est destinée.

Le gabarit de la spec, lui, parle couramment le langage Produit : des user stories priorisées (P1, P2, P3), chacune assez autonome pour être testée seule et constituer un MVP, des scénarios d'acceptation en "étant donné, quand, alors" (le fameux Given, When, Then du langage Gherkin), les cas limites, et des critères de succès mesurables qui ne disent rien de la technique (on a connu des PRD moins exigeants !). Parmi les exemples, on tombe même sur une métrique business : réduire de moitié les tickets de support sur un sujet donné.

Côté agent, la consigne est stricte : trois points "à clarifier" au maximum dans la spec, présentés comme des options à trancher. La commande clarify prend ensuite le relais avec cinq questions au plus, posées une par une, et seulement celles dont la réponse change quelque chose au produit ou au code, un tri qui est le pain quotidien d'un PM.

On peut en tirer un partage assez naturel :

• Le Product Manager écrit la demande qui lance la spec, relit spec.md, répond aux questions de clarification et porte les critères de succès.
• L'équipe Tech rédige la constitution, choisit la stack au moment du plan, relit les tâches et le code.
• Les deux ensemble lisent le rapport d'analyse avant l'implémentation et vérifient, à la fin, que ce qui a convergé correspond bien à la spec.

Ce partage suppose de savoir séparer le besoin de sa mise en œuvre… et qui n'a jamais lu une user story qui imposait la couleur du bouton ? Avec un agent, ce vieux réflexe coûte plus cher, parce qu'il applique la spec à la lettre, couleur comprise. En présentant l'outil, Den Delimarsky, chez GitHub, invitait d'ailleurs à voir les agents moins comme des moteurs de recherche que comme des binômes de programmation qui prennent tout au pied de la lettre.

Avant la spec : l'extension assess pour décider si une idée vaut le coup

Depuis juillet 2026, une extension remonte encore plus en amont. Baptisée assess, elle ressemble beaucoup à de la discovery outillée : cinq étapes (recueil de l'idée, recherche, définition du problème, mise en forme des options, décision), et pas une ligne de code. Le fichier qui définit le problème recense les utilisateurs concernés, les objectifs et les non-objectifs, les métriques de succès et le coût de l'inaction.

Le passage le plus savoureux concerne les idées qui arrivent déjà sous forme de solution ("il faut construire X") : l'agent doit alors remonter au problème que X est censé résoudre. Exactement ce qu'on attend d'un PM quand on débarque avec un "il faudrait juste un bouton qui…" ! La décision tombe ensuite en trois verdicts, "go", "à clarifier" ou "kill", et la documentation précise qu'abandonner une idée pour une raison documentée est un résultat utile.

La recherche reste évidemment celle d'un agent. La documentation prévient elle-même qu'une hypothèse non sourcée n'est pas un fait établi, et aucune extension ne remplace un entretien avec un vrai utilisateur. Une fois l'idée validée, on passe à la spec en donnant à specify le résumé de la décision.

Brancher Spec Kit sur les outils de l'équipe Produit

Côté outils, le catalogue de la communauté a de quoi intéresser un PM : plusieurs extensions synchronisent specs et tâches avec Jira ou Linear (en epics, stories ou tickets selon les cas), et une autre tire des specs un PRFAQ, un PRD allégé ou une synthèse pour les parties prenantes. La documentation propose même un exemple de configuration pensée pour le rôle de Product Manager, de la discovery jusqu'au passage de la spec à la roadmap, à adapter à sa sauce.

À manier avec prudence, quand même. Le README précise que ces extensions ne sont ni auditées ni recommandées par GitHub, et la plupart sont l'œuvre d'un seul auteur. Mieux vaut les essayer sur un projet bac à sable avant d'en faire une pièce du process d'équipe.

Comment utiliser Spec Kit avec Claude Code, Copilot ou Cursor ?

Spec Kit s'intègre à une quarantaine d'agents. Le choix se fait à l'initialisation, avec une clé : claude pour Claude Code, copilot pour GitHub Copilot, cursor-agent pour Cursor, codex pour Codex CLI, gemini pour Gemini CLI, et ainsi de suite jusqu'à Mistral Vibe ou Kiro CLI. Changer d'agent en cours de route ne demande pas de tout recommencer, parce que les spécifications, elles, ne bougent pas.

Quand le sortir, et quand s'en passer ? Manfred Riem, qui maintient le projet chez GitHub, tranche lui-même en le comparant au mode plan de Copilot : le mode plan pour le travail ponctuel, Spec Kit quand la traçabilité compte. Le raisonnement vaut aussi pour le mode plan des autres agents. Pour un bug à corriger ou un écran à ajuster, un plan dans la conversation fait très bien l'affaire. Une fonctionnalité qui mobilise plusieurs personnes, et que quelqu'un devra encore comprendre dans six mois, mérite en revanche une spec écrite et relue.

Quelles sont les limites de Spec Kit ?

Les limites de Spec Kit tiennent surtout à son poids : il produit beaucoup de markdown à relire pour chaque fonctionnalité, ce qui devient vite disproportionné sur les petits sujets, et rien ne garantit que l'agent suive toutes les consignes.

Les équipes de Thoughtworks l'ont constaté en testant l'outil, surtout sur du code existant. Leur Technology Radar d'avril 2026 le classe en "Assess", autrement dit à explorer avant d'envisager de l'adopter. La constitution les a aidées à cadrer les agents, mais les fichiers markdown trop verbeux alourdissent la charge mentale, et les instructions qui s'accumulent finissent par noyer l'agent. Elles s'en sont mieux sorties en adaptant les gabarits, par exemple pour générer moins de fichiers.

Le même Radar note que ce sont les Ingénieurs expérimentés, rompus au code propre et à l'architecture, qui en tirent le plus. Rien de très surprenant : une spec soignée ne vaut que si quelqu'un, côté Tech, sait juger le plan et le code qui en sortent.

Ces écueils ne datent pas de la 1.0. Dès octobre 2025, Birgitta Böckeler, elle aussi chez Thoughtworks, jugeait le workflow disproportionné pour une fonctionnalité de taille moyenne, et voyait l'agent ignorer certaines consignes malgré les garde-fous. Logique, au fond : les listes de contrôle restent lues par un modèle, qui ne les respecte pas forcément.

Tout ne mérite donc pas une spec, et Spec Kit le reconnaît en proposant un circuit à part pour les bugs. Dérouler le workflow complet pour changer un libellé, c'est un peu prendre un 38 tonnes pour aller chercher le pain : il faut un sujet d'une certaine taille pour amortir le temps passé à écrire et relire tous ces fichiers.

Sur le code existant, les avis divergent. GitHub y voit le terrain où l'approche donne le plus, alors qu'une autre fiche du même Radar juge les frameworks comme Spec Kit plus adaptés aux projets neufs. Dans tous les cas, la documentation demande à l'équipe de choisir comment ses specs vieilliront : archive figée, contrat vivant qu'on tient à jour, ou spec qu'on réconcilie avec ce que le code a appris. Encore faut-il que quelqu'un se charge de ce choix.

Le spec-driven development traîne aussi le soupçon d'un cycle en V réécrit en markdown, auquel Den Delimarsky répondait dès septembre 2025. Rien dans l'outil n'oblige à figer la spec. Le risque apparaît quand l'équipe l'écrit d'un bloc et la confie à l'agent comme on remettait autrefois un cahier des charges. Revenir sur la spec dès que le code révèle quelque chose reste le meilleur garde-fou.

Spec Kit, OpenSpec, BMAD : quelles différences ?

Spec Kit n'est pas seul à faire travailler un agent à partir d'une spécification. OpenSpec, BMAD Method et Kiro partent de la même idée, avec un poids et un découpage du travail très différents :

OpenSpec revendique d'être pensé pour le code existant et se veut plus léger. Son README décrit d'ailleurs Spec Kit comme complet mais lourd… venant d'un concurrent, on prend ça avec des pincettes.

Alors, qu'est-ce que Spec Kit change pour une équipe Produit ?

Pas grand-chose sur le fond. Décider de ce qu'on construit, c'était déjà le travail d'une équipe Produit, et les "business stakeholders" de la consigne ne font que le rappeler. Sauf qu'une mauvaise décision coûte plus cher maintenant qu'un agent code vite, et plutôt bien : une spec bancale ne se rattrape plus au fil des échanges avec les Développeurs, l'agent la code telle quelle. La valeur se concentre donc sur le jugement, sur la capacité à bien décider de ce qui mérite d'être construit et de ce qu'on laisse de côté. C'est ce qu'on appelle le Product Taste, et ça s'apprend surtout avec l'expérience.

Spec Kit peut servir de béquille à ce jugement. Ses gabarits obligent à prioriser les user stories et à leur fixer des critères de succès mesurables, et l'extension assess pousse à se demander, avant même la spec, si l'idée mérite d'être construite. Un PM expérimenté y trouve un cadre pour poser son jugement noir sur blanc. Un PM qui débute, lui, s'entraîne à chaque spec à trancher des questions qu'il aurait volontiers laissées en suspens. La béquille sert aussi aux Développeurs, que l'IA rapproche du Produit à mesure que l'agent prend en charge une bonne partie du code : la spec devient pour eux le terrain où discuter du besoin avec le PM, avant de parler technique.

FAQ

Spec Kit est-il gratuit ?

Oui, Spec Kit est open source, sous licence MIT. Ce qui coûte, c'est l'agent de code qu'on branche dessus (abonnement ou consommation de tokens), et un workflow complet consomme plus qu'une simple conversation, parce que l'agent produit et relit plusieurs fichiers par fonctionnalité.

Spec Kit est-il un serveur MCP ?

Non. Spec Kit est une CLI qui installe des commandes ou des skills dans le projet, et le workflow se pilote depuis l'agent de code. La commande expérimentale specify mcp lance bien un serveur MCP, mais seulement en lecture, pour inspecter l'installation.

Qu'est-ce que la constitution dans Spec Kit ?

C'est le fichier des principes du projet, que l'agent applique à chaque changement et que le plan vérifie. Elle fixe la manière de construire, et c'est la spec qui dit quoi construire. Le gabarit en donne des exemples : tests écrits avant le code, tests d'intégration sur les contrats entre services, consigne de commencer simple.

Spec Kit fonctionne-t-il en français ?

On peut écrire ses demandes en français. Les gabarits sont en anglais, mais des presets servent à adapter gabarits, commandes et terminologie aux habitudes d'une équipe.

Peut-on utiliser Spec Kit sur un projet existant ?

Oui, en lançant specify init --here dans le dépôt. Spec Kit ne tire aucune spec du code en place : on s'en sert pour le prochain changement, de préférence bien délimité. Une extension de la communauté propose de cartographier l'architecture existante pour démarrer plus vite.

Quelle différence entre une spec Spec Kit et un PRD ?

Une spec Spec Kit couvre une seule fonctionnalité et sert d'entrée directe à un agent, qui en tire un plan et des tâches. Un PRD couvre en général un périmètre plus large et s'adresse à des humains. Leur contenu se ressemble beaucoup (problème, user stories, critères d'acceptation, métriques de succès), au point que le document de méthode de Spec Kit parle lui-même de PRD pour désigner ce que devient la spécification.