Il y a un an, on « vibe-codait » : on décrivait vaguement un besoin à un agent, on récupérait du code qui avait l'air juste, et on priait. GitHub le résume sans détour : « parfois le code ne compile pas, parfois il résout une partie du problème mais rate l'intention réelle » (GitHub, Spec Kit). La réponse qui s'impose partout en 2026 porte un nom : le spec-driven development (SDD).
Le principe, tel que le formule Thoughtworks : « écrire une spec avant d'écrire du code avec l'IA - la spec devient la source de vérité pour l'humain et pour l'IA » (Birgitta Böckeler, martinfowler.com). Chez Ippon, la même intuition est posée comme un renversement : « la spécification devient la source de vérité du projet », un artefact opérationnel « consulté et utilisé chaque jour », et non plus « un document oublié » (Ippon).
Si cette idée vous semble familière, c'est normal : c'est la conviction fondatrice de Survol. « La spec validée EST le prompt », écrivions-nous dès le premier jour. Voir l'industrie entière converger vers cette thèse est, disons-le, une jolie confirmation. Mais les meilleures analyses vont plus loin - et pointent, sans toujours le résoudre, le vrai problème.
Pourquoi maintenant : la « taxe d'ambiguïté »
Le SDD répond à un mal précis. specdriven.ai lui donne un nom : la « taxe d'ambiguïté » - « les cycles coûteux d'hallucination et de reprise causés par des exigences floues » (specdriven.ai). Microsoft décrit le même phénomène autrement : « les équipes livrent un logiciel qui fonctionne mais rate l'intention d'origine… la perte de sens à mesure que les idées passent du besoin aux exigences, à l'architecture, à l'implémentation » (Microsoft Developer Blog).
La conséquence pratique est unanime : il faut s'aligner d'abord, accélérer ensuite. « Au lieu de prompter puis de recadrer, les équipes s'alignent d'abord et laissent l'IA accélérer l'exécution à partir d'une spec claire » (Microsoft). C'est le cœur du sujet, et c'est un sujet d'équipe autant que de code : décider ensemble ce que « bon » veut dire, avant de lancer l'agent.
La question que presque personne ne tranche : la maintenance de la spec
C'est l'analyse la plus lucide du lot, et elle vient de Thoughtworks. Böckeler distingue trois niveaux de SDD, rarement explicités :
- Spec-first : on écrit une bonne spec, on l'utilise pour la tâche du moment… puis on l'oublie.
- Spec-anchored : la spec est conservée après la tâche, pour faire évoluer et maintenir la fonctionnalité dans le temps.
- Spec-as-source : la spec est le fichier source principal ; l'humain n'édite que la spec, jamais le code.
Et voici son constat, que nous considérons comme le point aveugle du SDD tel qu'on l'outille aujourd'hui :
« Toutes les approches SDD que j'ai trouvées sont spec-first, mais toutes ne cherchent pas à être spec-anchored ou spec-as-source. Et souvent, ce que doit être la stratégie de maintenance de la spec dans le temps est laissé vague, ou totalement ouvert. » - Birgitta Böckeler, Thoughtworks
Traduction : la plupart des outils SDD savent vous aider à écrire une belle spec pour démarrer une tâche. Presque aucun ne répond à la question qui compte sur la durée d'un vrai produit - qui met la spec à jour quand la fonctionnalité évolue, qui la relie aux versions livrées, qui garantit qu'elle reste la vérité et ne redevient pas ce « document oublié » que dénonçait Ippon ? écrire une spec est un geste. La garder vivante est un système.
C'est précisément la promesse de Survol. Chez nous, la spec n'est pas un fichier markdown à côté du code, qui dépend de la discipline d'un développeur pour survivre. C'est un objet produit de premier plan : chaque fonctionnalité porte sa spec, versionnée, reliée à ses versions livrées (v1.0, v1.1, v2.0…) et aux décisions qui l'ont façonnée. Spec-anchored par construction - la spec vit aussi longtemps que le produit.
Les garde-fous : la « constitution » du projet
Deuxième brique commune à tous les outils SDD : un socle de règles persistantes. specdriven.ai l'appelle la « constitution » - un constitution.md qui « établit les principes permanents du projet (stack technique, standards de code, règles de sécurité) servant de contexte immuable à toutes les opérations de l'IA ». Côté AWS, c'est la même logique, poussée un cran plus loin : apprendre à l'agent vos conventions une fois pour toutes via un CLAUDE.md, des hooks, et des skills - des fichiers d'instructions réutilisables - empaquetés en plugins partageables (Gunnar Grosch, AWS Builder). L'idée maîtresse, dit-il : « pour ne plus expliquer les mêmes workflows à chaque session ».
Excellent principe - mais qui, dans une équipe, possède et fait évoluer ces fichiers ? S'ils vivent dans le dépôt, à la main, ils dérivent : chaque développeur a sa version, la règle de sécurité d'hier n'est plus injectée aujourd'hui. Survol traite ce socle comme ce qu'il est : une infrastructure de gouvernance. Nos contraintes techniques d'organisation - sécurité, librairies, conventions - sont injectées automatiquement au début de chaque session d'agent, avec trois niveaux (impérative, forte, préférence) et une journalisation de chaque application. Et les fichiers d'orientation de l'agent (type CLAUDE.md, skills) sont administrables depuis Survol comme depuis le code source - une seule vérité, jamais dérivée. La « constitution » cesse d'être un vœu pieux ; elle s'applique.
Le vrai goulot d'étranglement : la revue humaine
Reste l'angle mort le plus coûteux, et il est chiffré. Le SDD déplace le rôle du développeur : de « codeur » à « architecte et relecteur » (specdriven.ai). Formidable - sauf que la relecture devient alors le facteur limitant. Les données sont brutales : sur 10 000+ développeurs, les équipes à forte adoption d'IA « complètent 21 % de tâches en plus et fusionnent 98 % de pull requests en plus - mais le temps de revue des PR augmente de 91 %, créant un goulot critique à l'approbation humaine » (C.J. Roth, citant le Productivity Paradox Report de Faros AI). C'est la loi d'Amdahl appliquée au logiciel : le système ne va pas plus vite que son maillon le plus lent. Et ce maillon, désormais, c'est l'humain qui valide.
Une spec claire réduit déjà ce coût - on relit contre une intention explicite, pas contre un ressenti. Mais Survol va plus loin en outillant la revue elle-même, au lieu de la laisser reposer sur l'héroïsme d'un lead :
- Une préview à valider à chaque version, avant toute fusion - on teste l'intention, pas des lignes de diff.
- Des cahiers de tests d'acceptation, déroulés par un humain sur un environnement identifié : la vérification est structurée, traçable, réutilisable.
- Des revues d'experts à la demande - une synthèse lisible par un non-développeur, dont chaque constat devient une tâche pour l'agent en un clic.
Le même rapport note que les gains d'IA vont massivement aux ingénieurs seniors - « près de cinq fois » ceux des juniors - parce qu'ils « savent à quoi ressemble du bon code » et peuvent donc relire et corriger efficacement (Addy Osmani, cité par C.J. Roth). Une plateforme qui structure la revue, c'est une façon de diffuser ce discernement au-delà des seuls seniors - et c'est aussi la raison d'être de nos revues d'experts.
Là où Survol change la donne : le SDD comme sport d'équipe
Voici le fil rouge qui relie toutes ces sources. Les outils SDD d'aujourd'hui - Spec Kit, Kiro, Tessl et consorts - sont d'abord des outils de développeur, dans un terminal, une tâche à la fois. Ils sont excellents pour ça. Mais la spec y reste un fichier technique, dont la maintenance est « laissée vague », dont les garde-fous dépendent de la discipline individuelle, et dont la revue engorge un humain seul.
Survol prend le même principe - la spec comme source de vérité - et le fait passer à l'échelle d'un produit et d'une équipe :
- La spec est un objet produit, pas un fichier : écrite en français, discutée, versionnée, reliée aux versions livrées. Spec-anchored par défaut.
- L'alignement précède l'exécution : les décisions produit se tranchent en équipe - datées, votées, rattachées à la fonctionnalité - avant de lancer l'agent. Le « s'aligner d'abord » de Microsoft, outillé.
- Les garde-fous sont une infrastructure : contraintes injectées à chaque session, fichiers d'orientation administrables centralement.
- La revue est structurée : préviews, cahiers de tests, synthèses d'experts - pour desserrer le goulot que tout le monde constate.
- Les non-techniciens pilotent vraiment : la spec étant l'interface, un PM, un dirigeant, un fondateur sans équipe technique orchestrent l'agent sans écrire une ligne de code.
Ce qu'on en retient
- Le spec-driven development est en train de gagner : la spec, pas le prompt ni le code, devient la source de vérité de l'IA. GitHub, Microsoft, Thoughtworks et AWS le confirment.
- Le point aveugle, pointé par Thoughtworks : la maintenance de la spec dans le temps est presque toujours « laissée vague ». écrire une spec est un geste ; la garder vivante est un système.
- Deux chantiers sous-estimés : des garde-fous qui s'appliquent vraiment (la « constitution »), et une revue humaine qui n'engorge pas (91 % de temps de revue en plus, selon Faros AI).
- Survol répond aux trois : spec anchored comme objet produit, contraintes injectées et administrées, revue outillée - le SDD sorti du terminal, devenu sport d'équipe.
« À mesure que l'IA banalise la génération de code, le goulot d'étranglement de l'ingénierie s'est déplacé de l'écriture de la syntaxe vers la définition de l'intention » (specdriven.ai). Nous ne pourrions être plus d'accord - et nous ajouterions : définir l'intention, la garder vivante, l'entourer de garde-fous et la faire relire, c'est un travail d'équipe, continu, qui mérite mieux qu'un fichier dans un coin du dépôt. Ce travail-là, c'est celui que Survol outille.
Sources : B. Böckeler, « Understanding Spec-Driven Development », martinfowler.com · GitHub, « Spec-driven development with AI » (Spec Kit) · Microsoft Developer Blog · specdriven.ai · Ippon · H. Park, « Using spec-driven development with Claude Code » · G. Grosch, AWS Builder · C.J. Roth, « Building an Elite AI Engineering Culture ».
