OpenSpec : un framework de spécification pour l'IA et les agents de codage
En bref
- OpenSpec propose un cadre léger pour créer et maintenir des spécifications logicielles destinées aux équipes et agents IA.
- Le projet revendique 68 000 étoiles GitHub et une nouvelle spécification créée toutes les deux secondes.
- Le débat HN révèle des usages très disparates : certains trouvent les spécifications utiles surtout pour la structure de processus, d'autres les jugent rapidement obsolètes en projets longs.
Ce que dit la source
OpenSpec se présente comme une solution pour capturer les exigences dans des spécifications, maintenir l'alignement entre équipe humaine et agents de codage, raffiner les besoins, valider qu'ils décrivent la bonne chose et vérifier que l'implémentation correspond. L'outil propose un workflow itératif : explorer le problème, proposer une solution, implémenter, vérifier, archiver.
- Adoption affichée : 68 000 étoiles GitHub, 265 000 développeurs mensuels, spécification créée toutes les deux secondes
- Compatible avec plusieurs fournisseurs d'IA (Claude, Gemini, GitHub Copilot, Mistral, etc.) et CLI généralistes
- Installation via npm/pnpm/yarn/nix, open source sous licence MIT
Dans les commentaires
Débat très polarisé entre enthousiasme (processus utile, meilleur framework SDD pour certains) et scepticisme sérieux (specs deviennent obsolètes, pain plus que bénéfice en projets longs, pas supérieur aux plans natifs des LLM récents).
- Un utilisateur expérimenté (6-9 mois de solo work) a abandonné la partie spécification après avoir constaté une divergence majeure entre code et spec, retenantuniquement le processus de revue itérative et les ADRs.
- Plusieurs commentaires pointent le « spec drift » classique : les spécifications vieillissent rapidement et reproduisent les mêmes échecs que les outils de génération de code des années 1990 (UML, etc.).
- Critiques sur le rituel et la surcharge documentaire : document markdown générés par IA, remplis d'« artefacts d'écriture IA », jamais maintenus à jour, particulièrement lourd pour des changements mineurs.
- Désaccord sur l'utilité relative : certains trouvent les LLM récents assez bons en planification natifs pour rendre les frameworks inutiles ; d'autres estiment que sans contexte massif (deux ordres de magnitude plus), les workflows SDD restent nécessaires.
- Plusieurs développeurs ont forké OpenSpec ou bâti leurs propres harness pour ajouter : suivi de la fraîcheur des artefacts, boucles de révision multi-modèles, gestion de l'ajout différé de fonctionnalités, cérémonie proportionnée au contexte.
Alternatives citées : Spekk (approche Go avec specs déclaratives), SpecKit, SpecDD (architecture-first), des harness personnalisés bâtis par les utilisateurs.
Notre lecture
OpenSpec occupe un créneau réel pour les équipes travaillant avec des agents IA sur des projets structurés, notamment en greenfield. Cependant, le débat révèle qu'aucun framework SDD n'a encore atteint le statut de standard de facto (comme React en frontend). Le problème fondamental, maintenir la spec à jour face au code, reste non résolu; la valeur réelle semble être le processus de revue itérative et la documentation de décisions (ADRs), plutôt que la spec elle-même. À tester sur un proto greenfield modéré avant de l'intégrer à grande échelle; attention particulière à la divergence spec/code dans les projets longs.