OpenSpec ajoute un workflow de spécifications aux assistants de codage IA
OpenSpec structure les exigences et les propositions de modification afin que les assistants de codage puissent implémenter et vérifier le travail par rapport à une spécification explicite.
En bref
- De quoi s’agit-il ?
- Un projet TypeScript qui apporte aux assistants de codage IA un workflow de spécifications basé sur Markdown, de la proposition à l'archivage.
- À qui s’adresse-t-il ?
- Le texte de la licence MIT fournit le logiciel tel quel, sans garantie, et le README renvoie aux propres dossiers openspec/specs et openspec/changes du dépôt comme exemple vivant du workflow qu'il décrit.
- 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 TypeScript, 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
Une couche de spécifications légère
OpenSpec est un projet TypeScript qui ajoute une couche de développement piloté par les spécifications aux assistants de codage IA. Le README pose le problème ainsi : les assistants IA sont puissants mais imprévisibles lorsque les exigences ne vivent que dans l'historique de discussion. La réponse du projet est une couche de spécifications légère pour que l'humain et l'IA s'accordent sur ce qui doit être construit avant d'écrire du code. La philosophie énoncée est : fluide et non rigide, itératif et non en cascade, simple et non complexe, conçu pour le brownfield et pas seulement le greenfield, évolutif des projets personnels aux entreprises. Le dépôt n'est pas archivé et, au moment de la rédaction, ses métadonnées affichent 63 848 étoiles et 4 407 forks ; la page d'accueil du projet est openspec.dev.
Le workflow piloté par les artefacts
Le README s'ouvre sur un workflow qu'il appelle piloté par les artefacts, centré sur des commandes slash tapées dans un assistant de codage. La commande canonique est /opsx:propose, qui crée un dossier sous openspec/changes/ contenant proposal.md, un dossier specs/, design.md et tasks.md. La commande compagnon /opsx:explore est décrite comme un partenaire de réflexion sans risque qui lit le code, pèse les options et façonne un plan avant que quoi que ce soit soit écrit. Une fois le plan établi, /opsx:apply implémente les tâches et /opsx:archive déplace la modification vers openspec/changes/archive/ avec un nom de dossier daté. Le README montre ce flux sous forme de transcription de conversation mais ne précise pas quels outils prennent en charge quelles commandes, notant seulement que le nom canonique peut être orthographié différemment selon l'outil.
Les spécifications sont du Markdown simple
Les spécifications sont du Markdown simple, sans syntaxe particulière à apprendre. L'exemple du README montre une section 'ADDED Requirements', une exigence selon laquelle l'application SHALL permettre aux utilisateurs de basculer entre thèmes clair et sombre en suivant par défaut la préférence système, et un scénario décrivant l'action de bascule avec des étapes WHEN et THEN. Le README indique que l'IA écrit ces artefacts et que l'humain révise le plan avant que du code soit écrit. Il indique aussi qu'OpenSpec est construit avec OpenSpec, renvoyant aux dossiers openspec/specs et openspec/changes du dépôt comme exemples réels à l'échelle.
Les Stores pour la planification en équipe
Pour l'usage en équipe, le README présente les Stores, actuellement en bêta. Un Store est un dépôt à part entière contenant la même structure openspec/ de spécifications et de modifications, partagée par git push comme n'importe quoi d'autre. Les usages prévus sont les fonctionnalités transversales, où une seule modification couvre du code livré dans plusieurs dépôts ; les exigences partagées, où une équipe plateforme possède les spécifications et les équipes produit les référencent en lecture seule ; et le plan avant code, où le plan est capturé dans le Store avant que les dépôts de code ne suivent. Le README renvoie à un guide utilisateur des Stores pour la configuration mais ne décrit pas dans le README principal la mécanique de création ou de synchronisation d'un Store.
Installation et noms de commandes
L'installation exige Node.js 20.19.0 ou plus. Le chemin documenté est npm install -g @fission-ai/openspec@latest suivi de openspec init dans le répertoire du projet. Le README dit que openspec init imprime la forme de commande correcte pour les outils choisis par l'utilisateur, car la commande canonique /opsx:propose peut apparaître comme /opsx-propose dans Cursor et GitHub Copilot, @opsx-propose dans Amazon Q, ou $openspec-propose dans Codex. Le README revendique la prise en charge de plus de 30 outils et dit que la CLI fonctionne aussi avec pnpm, yarn, bun et nix, avec des options d'installation dans la documentation. Le profil par défaut inclut /opsx:explore et /opsx:propose ; un profil étendu ajoute /opsx:new, /opsx:continue, /opsx:ff, /opsx:verify, /opsx:bulk-archive et /opsx:onboard, sélectionné avec openspec config profile et appliqué avec openspec update.
Les comparaisons du README
Le README positionne OpenSpec contre deux alternatives nommées et contre l'absence totale de couche de spécifications. Face à github/spec-kit, il argue que cet outil est complet mais lourd, avec des portes de phase rigides, beaucoup de Markdown et une configuration Python, tandis qu'OpenSpec est plus léger et permet d'itérer librement. Face à Kiro (AWS), il argue que cet outil est puissant mais enferme l'utilisateur dans un IDE spécifique et limite aux modèles Claude, tandis qu'OpenSpec fonctionne avec les outils déjà utilisés. Face à rien, il argue que le codage IA sans spécifications signifie des invites vagues et des résultats imprévisibles. Ce sont des affirmations du README, pas des benchmarks indépendants ; le README ne fournit aucune donnée de performance ni évaluation de tiers. Il recommande aussi des modèles à haut raisonnement, citant Codex 5.5 et Opus 4.7 pour la planification et l'implémentation, et conseille de vider la fenêtre de contexte avant de commencer l'implémentation.
Maintenance, télémétrie et licence
La mise à jour se fait avec la même commande npm install, suivie de openspec update dans chaque projet pour régénérer les instructions IA et activer les dernières commandes slash. La télémétrie est activée par défaut et ne collecte que les noms de commandes et la version, sans arguments, chemins, contenu ni données personnelles, et elle est automatiquement désactivée en CI ; le refus se fait avec export OPENSPEC_TELEMETRY=0 ou export DO_NOT_TRACK=1. Le guide de contribution dit que les petites corrections se soumettent directement en pull requests, tandis que les changements plus importants doivent commencer par une proposition de changement OpenSpec ; le code généré par IA est bienvenu s'il est testé et vérifié, et la PR doit mentionner l'agent et le modèle utilisés. Le dépôt est sous licence MIT, et le texte de la licence accorde le droit d'utiliser, copier, modifier, fusionner, publier, distribuer, sous-licencier et vendre des copies, le logiciel étant fourni tel quel sans garantie ; le texte ne dit rien sur la posture de sécurité, le support ou l'aptitude à la production.
Conclusion éditoriale
Le texte de la licence MIT fournit le logiciel tel quel, sans garantie, et le README renvoie aux propres dossiers openspec/specs et openspec/changes du dépôt comme exemple vivant du workflow qu'il décrit.
Notes de la communauté