Développer avec l'IA : Spec is the new Code !

En quelques mois, l'IA a profondément changé ma façon de développer des applications, et je continue jour après jour d'ajuster mes méthodes, mettant à profit chacune de mes expériences.
Mes premières tentatives de Vibe Coding avec Lovable, Bolt et Base44 sont déjà loin derrière moi. Elles ne répondent pas à mes besoins en termes de développement d'applications professionnelles.
Je me suis donc tourné vers une alternative plus solide, connue sous l'appellation Spec-Driven Development, qui allie rigueur et simplicité. Plusieurs solutions clé-en-main existent - je les évoquerai - mais c'est surtout l'approche que je retiens, et que j'adapte à mes propres besoins pour préserver un maximum de flexibilité.
Les limites du Vibe Coding
Le Vibe Coding repose sur une succession d'échanges avec l'IA, afin de développer de manière itérative une application. Cette approche a un côté magique car elle permet d'obtenir des résultats dès les premiers prompts. Mais elle induit aussi des problématiques qui tendent à s'amplifier au fil du projet.
1. Amorçage
Un prompt de démarrage résume l'intention du concepteur. On l'enrichit et on le formate avec l'aide de son IA préférée, et c'est parti ! On jette les dés et la magie opère. C'est la phase la plus gratifiante. À ce stade, on laisse une très grande liberté à l'IA qui, à défaut de pouvoir cerner clairement toutes nos intentions, va devoir improviser.
2. Affinage
Le manque de précision initial va devoir être compensé par une série d'ajustements. Prompt après prompt, on essaie de réaligner le projet avec notre vision. Plus l'application est complexe, plus ce travail d'ajustement est laborieux, et plus les risques de régression sont grands.
3. Tests
Face aux risques de régression, les plateformes de Vibe Coding proposent la génération automatique de tests. Mais pour définir ces tests, l'IA s'appuie sur les quelques prompts disponibles, et sur le code qu'elle a elle-même généré. Les tests tendent ainsi à valider le code développé, et non le code attendu. En d'autres termes, l'IA est juge et partie.
4. Corrections
Pour faire face aux imprécisions initiales et aux nombreuses régressions, les prompts de correction se succèdent. On décrit enfin précisément nos attentes en spécifiant les limites, les cas spécifiques. A défaut, on court le risque d'introduire de nouvelles régressions.
5. Review & Refactoring
Le moment est venu de garantir la maintenabilité, l'évolutivité et la scalabilité de votre application. C'est le début d'une longue campagne de revue de code et de refactoring. D'autant plus longue et laborieuse que les considérations d'architecture auront été omises des prompts initiaux.
Spécifier mieux, prompter moins
Plutôt que de guider l'IA par une longue succession de prompts, le Spec-Driven Development mise sur la rédaction d'une spécification qui servira de référence à l'IA. Cette approche a plusieurs avantages :
-
La spécification est l'unique source de vérité. Les intentions du concepteur ne sont pas éparpillées dans une multitude de prompts parfois oubliés. Elles sont cristallisées dans un document de référence qui alimente le contexte de l'IA.
-
La spécification est lisible par tous. Elle peut être partagée, validée, révisée par les acteurs du projet, et versionnée. Elle facilite ainsi le travail en équipe.
-
La spécification limite les ambiguïtés. Rédigée avec précision, elle permet un développement plus fluide, avec moins d'ajustements, moins de régressions, moins de corrections.
-
La spécification guide les tests. L'IA s'appuie sur la spécification pour définir des tests fiables, sans être influencée par l'implémentation. Elle cesse d'être juge et partie.
Newsletter
Vous aimez ce type de contenu ? Chaque mois, je partage mes analyses sur l'IA, la Data et le Digital Learning.
S'abonner →- Nouveaux articles
- Actualités du mois
- Tendances observées
- Ressources dénichées
Quelques solutions populaires
Voici quelques solutions populaires de Spec-Driven Development. La liste n'est pas exhaustive. Elle a pour seule vocation d'être représentative des tendances.
BMAD
Le BMAD Method est l’une des approches les plus structurées du marché. Son point fort est de reproduire les rôles d’une équipe projet — chef de produit, architecte, développeur, QA — à travers des agents IA spécialisés qui collaborent autour d’une même spécification.
Concrètement, BMAD convient bien aux projets d’envergure ou aux organisations qui veulent transformer l’IA en véritable méthode de production, et pas seulement en outil d’assistance.
GitHub Spec Kit
Spec Kit est sans doute l’approche la plus accessible pour débuter. Le principe est simple : avant de coder, on rédige trois documents clés — le besoin, le design et les tâches à réaliser.
Sa grande force est sa simplicité : il s’intègre facilement dans un workflow existant et permet d’apporter de la méthode sans bouleverser les habitudes de l’équipe. C’est souvent la porte d’entrée idéale vers le Spec-Driven Development.
OpenSpec
OpenSpec met l’accent sur la flexibilité et l’ouverture. L’outil est particulièrement intéressant pour les projets déjà existants, car il aide à formaliser les évolutions d’un produit sans repartir de zéro.
Là où certaines approches sont très adaptées aux nouveaux projets, OpenSpec se distingue par sa capacité à accompagner les évolutions progressives d’un produit déjà en production.
Kiro
Kiro se distingue par son positionnement plus “clé en main”. Il ne s’agit pas seulement d’une méthode, mais d’un environnement de développement pensé nativement autour des spécifications.
En pratique, Kiro guide l’utilisateur depuis l’idée initiale jusqu’aux tâches de développement, avec une forte intégration de l’IA. C’est probablement l’une des solutions les plus abouties pour industrialiser le Spec-Driven Development au quotidien.
Une approche trop bureaucratique ?
Passer beaucoup de temps à spécifier avant de coder peut paraitre anachronique à l'heure de l'IA. Les développeurs chevronnés se souviennent des cycles en V (analyse, spécification, implémentation, tests), souvent abandonnés au profit de méthodes plus agiles.
Le but n'est bien sûr pas d'alourdir ou de ralentir les processus de développement, mais au contraire de conserver l'agilité des méthodes modernes, tout en apportant une couche de cadrage et de contrôle de l'IA.
Il faut ainsi veiller à appliquer le bon niveau de spécification en fonction du projet, en tenant compte à la fois :
- De la surface fonctionnelle du projet, c'est-à-dire sa richesse et sa complexité sur le plan fonctionnel ;
- De sa profondeur technique, induisant la nécessité d'un contrôle architectural plus ou moins poussé ;
- De sa complexité organisationnelle, autour d'une équipe structurée d'acteurs humains et agentiques.
Ma propre solution
Après plusieurs expérimentations, voici le système que j'utilise désormais sur tous mes nouveaux projets, et que je continue d'affiner au fil du temps.
Contenu de la spécification
| Fonctionnel | Features, pages associées, plan de mise en œuvre |
| Technique | Pour chaque module : structures de données, logiques métier, mécanismes d'accès (API, CLI) |
| Règles | Design d'interface, architecture technique |
Principes d'utilisation
-
Spécification assistée par IA : la spécification est développée progressivement, avec l'aide de l'IA, en partant de la description générale d'une fonctionnalité. Les spécifications techniques sont générées, puis revues et ajustées si nécessaire.
-
Mise en œuvre progressive : l'effet tunnel existe avec l'IA, tout comme il existait avec les développeurs. Pas question donc de laisser l'IA coder une application entière sans point de contrôle. On avance et on valide pas à pas pour éviter les dérives.
-
Modifications par spécification : les demandes de modification se font prioritairement via la spécification. L'IA analyse les changements et les met en œuvre. On oublie les demandes de modification directement par prompt, afin d'éviter les divergences entre spécification et implémentation.
-
Rétro-spécification : il peut arriver que le développement d'une fonctionnalité impacte d'autres zones de code dépendantes. Dans ce cas, l'IA met à jour les fichiers de spécification affectés. De même, on peut partir d'une base de code existante pour générer la spécification.
-
Amélioration continue des règles générales : les règles générales (design system et architecture technique) sont rarement parfaites dès le premier jet. Chaque résolution de problème, chaque correction, est l'occasion d'améliorer ces règles pour renforcer la cohérence future du projet.
Conclusion
Les développeurs expérimentés ont connu plusieurs révolutions dans les langages de programmation, de l'assembleur jusqu'à la programmation orientée objet. Chaque génération a apporté une nouvelle couche d'abstraction, plus accessible, plus lisible par l'être humain.
Grâce à l'IA, le langage naturel devient le nouveau langage de programmation, ce qui le met à la portée de tous, en théorie. Mais en pratique, développer revient surtout à maîtriser un processus. L'IA accélère ce processus, mais elle n'en change pas les fondamentaux.
La spécification est une étape essentielle de ce processus, car elle permet de cristalliser et de partager l'intention du concepteur, ce dont l'IA a besoin pour être pertinente. C'est pourquoi l'approche Spec-Driven Development est en train de devenir la nouvelle norme pour le développement professionnel.
En vidéo