Spec Kit : une boîte à outils open source pour le développement piloté par les spécifications
Boîte à outils pour vous aider à démarrer avec le développement piloté par les spécifications. Spec Kit Définissez ce qu'il faut construire avant de le construire, avec n'importe quel agent de codage IA.
En bref
- De quoi s’agit-il ?
- Une boîte à outils Python open source qui transforme les spécifications en artefacts exécutables pour les agents de codage IA, avec extensions, préréglages et bundles par rôle.
- À qui s’adresse-t-il ?
- Le README présente Spec Kit comme une boîte à outils axée sur le processus : spécifier ce qu'il faut construire, planifier, décomposer en tâches, implémenter et converger, avec des extensions et des bundles pour la personnalisation. La licence MIT accorde des droits étendus mais aucune garantie, et le projet cite les travaux de John Lam comme influence principale.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Le dépôt a reçu de nouveaux commits au cours des dernières 24 heures.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Ce que le README dit du développement piloté par les spécifications
Le README commence par une définition plutôt qu'une liste de fonctionnalités. Le développement piloté par les spécifications, tel qu'il y est décrit, inverse l'ordre traditionnel : au lieu d'écrire d'abord le code et de traiter les spécifications comme un échafaudage jetable, les spécifications deviennent exécutables et génèrent directement des implémentations fonctionnelles. Le dépôt se présente comme une boîte à outils open source pour construire des logiciels de qualité avec n'importe quel agent de codage IA, offrant soit un processus prêt à l'emploi, soit la possibilité d'apporter le vôtre. Le README ne fournit ni benchmarks ni résultats de production ; toute affirmation sur des résultats mesurés devrait donc être vérifiée ailleurs.
Installation de la CLI Specify et initialisation d'un projet
L'installation nécessite uv, un gestionnaire de paquets Python. Le README montre l'installation de la CLI depuis le dépôt git avec un tag de version, en conservant le v initial (l'exemple donné est v0.12.11). Le paquet est aussi publié sur PyPI sous le nom specify-cli. Après installation, `specify init my-project --integration copilot` crée un projet et configure l'intégration de l'agent. Des commandes d'auto-gestion permettent de vérifier les nouvelles versions (`specify self check`), de prévisualiser une mise à jour (`specify self upgrade --dry-run`), de mettre à jour sur place ou d'épingler un tag précis. Le README précise aussi que les exécutions uvx (éphémères) et les extractions de code source sont détectées et produisent des recommandations spécifiques au chemin plutôt que d'exécuter un installeur.
Le flux de commandes slash après init
Une fois initialisé, l'agent expose des commandes. La plupart des agents exposent spec-kit sous forme de commandes slash `/speckit.*` ; la CLI Codex en mode compétences utilise `$speckit-*` à la place, et la CLI GitHub Copilot utilise `/agents`. Le flux principal est : `/speckit.constitution` pour créer les principes directeurs, `/speckit.specify` pour décrire ce qu'il faut construire, `/speckit.plan` pour fournir les choix de pile technique, `/speckit.tasks` pour décomposer le plan en tâches, et `/speckit.implement` pour les exécuter. Les commandes optionnelles incluent `/speckit.clarify` pour les zones imprécises, `/speckit.analyze` pour les contrôles de cohérence et `/speckit.checklist` pour générer des listes de contrôle qualité personnalisées. Pour les intégrations compatibles avec le mode compétences, passer `--integration-options="--skills"` installe des compétences d'agent au lieu de fichiers de commandes slash.
Extensions, préréglages et pile de priorité
Spec Kit se personnalise via deux systèmes plus des remplacements locaux au projet. La pile de priorité, de la plus haute à la plus basse, est : remplacements locaux dans `.specify/templates/overrides/`, préréglages dans `.specify/presets/templates/`, extensions dans `.specify/extensions/templates/` et le noyau dans `.specify/templates/`. Les modèles sont résolus à l'exécution, en prenant la première correspondance depuis le haut ; les commandes d'extension et de préréglage sont appliquées à l'installation via `specify extension add` et `specify preset add`. Les extensions ajoutent de nouvelles commandes et de nouveaux modèles, tandis que les préréglages remplacent les modèles et commandes existants, y compris ceux des extensions installées. Le README donne des exemples comme l'intégration Jira et la traçabilité réglementaire, mais ne liste pas de catalogue complet.
Bundles pour des configurations par rôle
Un bundle regroupe extensions, préréglages, étapes et flux de travail dans une configuration versionnée et orientée rôle, décrite par un manifeste `bundle.yml` écrit à la main. Un bundle sans champ `integration` est agnostique et hérite de l'intégration déjà utilisée par le projet. Les commandes incluent la recherche, l'information, l'installation, la liste, la mise à jour et la suppression. Les bundles sont résolus à partir d'une pile de catalogues priorisée (projet, utilisateur, intégré), avec des politiques d'installation qui autorisent l'installation ou limitent une source à la seule découverte. Le README énonce des garanties : info montre exactement ce qu'install ajoute ; les installations sont idempotentes et limitées à la racine du projet ; remove ne touche jamais aux composants dont un autre bundle installé a encore besoin ; toutes les commandes de consommation et de création fonctionnent hors ligne contre des sources locales ou épinglées. Quatre exemples de manifestes (chef de produit, analyste métier, chercheur en sécurité, développeur) se trouvent dans `examples/bundles/`.
Phases de développement et objectifs expérimentaux
Le README décrit trois phases de développement. Le développement 0-à-1 (greenfield) génère à partir de zéro, des exigences de haut niveau aux applications prêtes pour la production. L'exploration créative prend en charge des implémentations parallèles sur plusieurs piles techniques et motifs d'expérience utilisateur. L'amélioration itérative (brownfield) traite la modernisation des systèmes existants, en ajoutant des fonctionnalités ou en adaptant les processus. Une autre section liste des objectifs expérimentaux : indépendance technologique, contraintes d'entreprise, développement centré utilisateur, et processus créatifs et itératifs. Le README cite les travaux de John Lam comme influence majeure. Il ne fournit aucun calendrier, feuille de route ou plan de publication pour ces objectifs.
Prérequis, support et licence
Les prérequis sont Linux, macOS ou Windows ; un agent de codage IA pris en charge ; uv (recommandé) ou pipx pour la gestion des paquets ; Python 3.11 ou plus ; et Git. Le README indique que 30+ agents de codage IA sont pris en charge et renvoie à un guide pour la liste complète, sans les nommer tous. Le support passe par les issues GitHub. L'extrait de licence MIT accorde les droits d'utilisation, de copie, de modification, de fusion, de publication, de distribution, de sous-licence et de vente, sous réserve des conditions de la licence, et fournit le logiciel "tel quel", sans garantie d'aucune sorte. Le texte de licence ne dit rien sur la posture de sécurité, les engagements de support ou les garanties de maintenance.
Conclusion éditoriale
Le README présente Spec Kit comme une boîte à outils axée sur le processus : spécifier ce qu'il faut construire, planifier, décomposer en tâches, implémenter et converger, avec des extensions et des bundles pour la personnalisation. La licence MIT accorde des droits étendus mais aucune garantie, et le projet cite les travaux de John Lam comme influence principale. Ce que le README ne documente pas, comme les performances en production ou la liste complète des intégrations, ne peut pas être établi à partir de cette source.
Notes de la communauté