Microsoft vient de publier un article particulièrement intéressant sur la manière dont ses équipes internes font évoluer leur processus de développement à l’heure de l’IA générative.
Le sujet porte sur le Spec-Driven Development, ou SDD.
À première vue, encore un acronyme. Encore une nouvelle méthode. Encore une tentative de nous expliquer que l’IA va changer le métier de développeur.
Mais lorsqu’on lit attentivement ce que Microsoft décrit, une autre lecture apparaît.
Et elle est autrement plus intéressante.
Car derrière le vocabulaire moderne de l’IA, des agents et des spécifications exécutables se dessine une idée que certains développeurs expérimentés trouveront étrangement familière :
comprendre le problème avant de coder, formaliser les exigences, définir les contraintes d’architecture, lever les ambiguïtés, puis seulement implémenter.
Oui.
Exactement ce que l’industrie logicielle faisait avant que quinze ou vingt années d’Agile mal digéré nous expliquent parfois que réfléchir trop longtemps avant de coder était presque suspect.
Alors, le Spec-Driven Development serait-il le début d’un retour de balancier ?
L’IA est-elle en train de tuer le vibe coding ?
Et, question plus gênante encore :
le SDD est-il réellement compatible avec Agile ?
Ou assistons-nous à la réhabilitation, sous un nouveau nom, d’une partie des méthodes que l’Agile prétendait justement avoir dépassées ?
Microsoft a commencé comme tout le monde : par utiliser l’IA
L’histoire racontée par Microsoft est intéressante précisément parce qu’elle ne commence pas par une théorie.
Les équipes de Microsoft Digital ont commencé leur transformation IA d’une manière assez naturelle : chacun s’est approprié les nouveaux outils, a expérimenté, appris à utiliser les assistants et agents disponibles et a progressivement accéléré son travail.
Le résultat semblait positif.
Les développeurs produisaient plus vite.
Mais Microsoft a rapidement constaté quelque chose de beaucoup plus embarrassant.
Sudhakar Sadasivuni, Principal Group Engineering Manager chez Microsoft Digital, le résume ainsi :
“We quickly identified that improving the individual productivity of a developer was not resulting in a boost to team productivity. That was our hard lesson.”
Autrement dit :
augmenter la productivité individuelle d’un développeur n’augmentait pas automatiquement la productivité de l’équipe.
C’est probablement l’un des constats les plus importants de toute la vague actuelle d’IA générative appliquée au développement.
Nous nous sommes beaucoup focalisés sur la capacité des LLM à générer du code.
On mesure le nombre de lignes produites.
On compare le temps nécessaire pour écrire une fonction.
On admire un agent qui génère une API complète en quelques minutes.
Mais une équipe de développement n’est pas une somme de machines à produire des lignes de code.
Produire plus vite ne signifie pas nécessairement produire mieux.
Et surtout :
la vitesse de génération du code a augmenté beaucoup plus vite que notre capacité collective à décider quel code devait être généré.
C’est là que commence réellement le problème.
Productivité individuelle ≠ productivité d’équipe
Avec Copilot, Codex, Claude Code ou d’autres agents, un développeur peut désormais générer en quelques minutes ce qui lui aurait autrefois demandé plusieurs heures.
Parfait.
Mais imaginons dix développeurs bénéficiant exactement de la même accélération.
On peut obtenir dix développeurs qui :
-
génèrent dix fois plus vite des implémentations légèrement différentes ;
-
introduisent dix fois plus rapidement des décisions architecturales contradictoires ;
-
reproduisent dix fois plus vite une mauvaise compréhension du domaine métier ;
-
créent dix fois plus de code à relire ;
-
ajoutent dix fois plus vite de la dette technique.
La capacité de production n’était peut-être pas le goulot d’étranglement que nous pensions.
Microsoft explique d’ailleurs que son problème n’était pas vraiment celui des outils mais celui du processus entourant ces outils, notamment des pertes d’intention lors des différents passages entre personnes, rôles et artefacts.
L’IA n’a donc pas simplement accéléré le développement.
Elle a aussi accéléré les conséquences de nos imprécisions.
Le vibe coding : aller très vite... quelque part
C’est ici qu’intervient l’une des citations les plus savoureuses de l’article de Microsoft.
Mridul Verma, Senior Software Engineer chez Microsoft Digital, déclare :
“Speed without direction is just expensive chaos—and we learned that the hard way through vibe coding.”
Que l’on pourrait traduire par :
« La vitesse sans direction n’est qu’un chaos coûteux — et nous l’avons appris à nos dépens avec le vibe coding. »
Difficile de résumer plus efficacement le problème.
Le vibe coding n’est pourtant pas intrinsèquement absurde.
Pour explorer une idée, écrire un prototype, produire un outil personnel ou tester rapidement une hypothèse, il peut être remarquablement efficace.
On décrit ce que l’on souhaite.
L’IA produit.
On teste.
On corrige.
On redemande.
Et tant que l’objectif est visible et immédiatement vérifiable, cette boucle peut fonctionner.
Mais une application métier industrielle n’est pas un prototype de week-end.
Elle possède :
-
des contraintes métier ;
-
une architecture ;
-
des invariants ;
-
des règles de sécurité ;
-
des exigences réglementaires ;
-
des performances attendues ;
-
des systèmes existants ;
-
des contrats d’interface ;
-
une stratégie de déploiement ;
-
une dette technique ;
-
plusieurs équipes.
Dans ce contexte, demander :
« Ajoute-moi l’authentification, un dashboard et fais quelque chose de propre »
n’est pas une méthode de développement.
Même si le résultat compile.
Le danger du vibe coding n’est donc pas seulement de produire du mauvais code.
Il est de produire très rapidement du code qui semble correct alors qu’il implémente une intention mal définie.
La réponse de Microsoft : Spec-Driven Development
Microsoft décrit le SDD comme une approche dans laquelle la spécification devient l’artefact principal du cycle de développement.
C’est une différence importante.
Dans beaucoup de projets traditionnels, nous avons :
-
des documents de besoin ;
-
des user stories ;
-
quelques tickets ;
-
des conversations Teams ou Slack ;
-
des décisions prises oralement ;
-
des prompts donnés aux agents ;
-
et finalement le code.
Au fil du projet, le code devient de fait la seule vérité encore fiable.
Le SDD inverse cette logique.
La spécification devient une source de vérité vivante qui contient notamment :
Elle est maintenue et versionnée avec le projet.
Le code devient alors une conséquence de cette spécification.
C’est une différence fondamentale.
Le code n’est plus nécessairement l’artefact central
Microsoft identifie cinq piliers dans son approche :
-
la spécification comme source de vérité ;
-
des artefacts vivants et exécutables ;
-
l’automatisation assistée par IA ;
-
la validation et la collaboration humaines ;
-
la prédictibilité et la mesure.
À mon sens, le premier est de très loin le plus important.
Nous sommes habitués à considérer le code source comme l’artefact central du développement.
C’est logique : jusqu’à présent, le développeur transformait directement l’intention humaine en instructions formelles.
La chaîne ressemblait grossièrement à ceci :
Besoin → développeur → code → compilateur → logiciel
Avec des agents capables de générer une partie importante de l’implémentation, une couche supplémentaire apparaît :
Besoin → spécification → agent → code → compilateur → logiciel
Et cela change potentiellement le métier.
Si l’agent devient suffisamment compétent pour traduire une description formelle en implémentation, alors le travail de plus grande valeur n’est plus nécessairement l’écriture de chaque ligne.
Il devient la formalisation correcte de l’intention.
Une spécification, mais pas un cahier des charges de 600 pages
Une objection apparaît immédiatement.
Avons-nous simplement réinventé le cycle en V ?
Ou pire : Waterfall ?
Pas exactement.
Microsoft insiste sur le caractère vivant de la spécification.
Elle évolue avec le produit.
Elle est versionnée.
Elle peut être divisée en spécifications plus petites.
Ajeya Kumar, Principal Software Engineer chez Microsoft Digital, insiste notamment sur l’importance de specs limitées et ciblées, permettant de construire incrémentalement plutôt que de tout spécifier en une fois.
C’est une différence majeure avec certaines méthodes documentaires du passé.
Le SDD ne signifie donc pas nécessairement :
« Spécifions entièrement un projet pendant six mois puis donnons le document aux développeurs. »
Il signifie plutôt :
Avant d’implémenter une unité de travail, rendons suffisamment explicite ce que nous voulons réellement obtenir.
C’est beaucoup plus subtil.
Et beaucoup plus difficile à rejeter.
Le workflow Microsoft donne pourtant une étrange impression de déjà-vu
Microsoft décrit six étapes principales dans son workflow :
-
définir le problème métier et les résultats attendus ;
-
clarifier les ambiguïtés et questions non résolues ;
-
construire un plan technique d’implémentation ;
-
découper le travail en tâches traçables ;
-
vérifier l’alignement entre exigences et plan ;
-
implémenter et tester.
Prenons un peu de recul.
Nous avons donc :
besoin → clarification → spécification → conception technique → planification → implémentation
Les informaticiens ayant commencé leur carrière avant l’omniprésence de Scrum risquent de ressentir une légère impression de déjà-vu.
À une époque, nous appelions cela :
-
analyse fonctionnelle ;
-
analyse organique ;
-
conception ;
-
architecture ;
-
réalisation.
Certes, les documents étaient souvent trop lourds.
Certes, les cycles pouvaient devenir absurdes.
Certes, certains projets passaient des mois à produire une documentation que personne ne maintenait.
Mais l’idée fondamentale n’était pas idiote :
avant d’implémenter quelque chose, essayons de savoir précisément ce que nous voulons construire.
Sommes-nous en train d’inventer une nouvelle méthode ?
Ou de redécouvrir une vieille évidence parce que l’IA rend maintenant son oubli beaucoup trop coûteux ?
Et voici qu’arrive Agile
Il serait toutefois intellectuellement malhonnête d’affirmer que SDD est nécessairement incompatible avec Agile.
Le Manifeste Agile ne dit pas :
« Ne documentez rien. »
Il dit :
“Working software over comprehensive documentation”
Il ne dit pas non plus :
« Ne planifiez rien. »
Il dit :
“Responding to change over following a plan.”
Et il précise explicitement qu’il existe de la valeur dans les éléments situés à droite, mais que ceux de gauche sont davantage valorisés.
Autrement dit, le Manifeste Agile n’a jamais interdit :
-
la documentation ;
-
la conception ;
-
l’architecture ;
-
les plans ;
-
les spécifications.
Il critique leur utilisation excessive lorsqu’elles prennent le pas sur le produit et la collaboration.
À ce niveau, SDD et Agile ne sont absolument pas antagonistes.
Une spécification vivante peut évoluer.
Elle peut être courte.
Elle peut être raffinée au fur et à mesure.
Elle peut être attachée à une fonctionnalité.
Elle peut parfaitement s’inscrire dans une démarche itérative.
Mais il y a Agile... et ce que nous avons fait d’Agile
Le problème commence lorsque l’on cesse de parler du manifeste pour observer vingt années de pratiques en entreprise.
Dans de nombreuses organisations :
“Working software over comprehensive documentation”
est progressivement devenu :
« La documentation ne sert pas à grand-chose. »
Et :
“Responding to change over following a plan”
est parfois devenu :
« Cela changera de toute façon, inutile de trop réfléchir maintenant. »
La conception s’est parfois résumée à quelques user stories.
L’architecture devait « émerger ».
Les ambiguïtés étaient reportées au sprint suivant.
Et lorsqu’un problème apparaissait :
« Ce n’est pas grave, nous sommes Agile. »
Évidemment, aucune de ces caricatures n’est imposée par le Manifeste Agile.
Mais elles ont bel et bien existé.
Et elles existent encore.
C’est avec cette forme d’Agile industrialisé que SDD entre frontalement en collision.
SDD nous dit exactement l’inverse : ralentissez avant d’accélérer
Microsoft explique que sous SDD, les développeurs doivent commencer par acquérir une compréhension complète du problème et déterminer ce que signifie le succès avant que le code ne soit produit.
Mridul Verma reconnaît même :
“As developers, we get excited and want to jump directly into coding. Changing that habit was really tricky.”
C’est presque une profession de foi.
Ne codez pas immédiatement.
Clarifiez d’abord.
Rendez explicites les hypothèses.
Identifiez les cas limites.
Validez les règles.
Définissez ce qui permettra de dire que l’implémentation est correcte.
Puis produisez.
Nous sommes assez loin de :
« Faisons quelque chose dans le sprint et nous verrons avec le métier si cela lui convient. »
Pourquoi l’IA change complètement l’équation économique
C’est ici que le sujet devient réellement intéressant.
Les méthodes Agile sont apparues dans un contexte où produire du logiciel coûtait cher.
Écrire du code prenait du temps.
Modifier une architecture prenait du temps.
Construire un prototype prenait du temps.
Il était donc rationnel de chercher à obtenir rapidement un logiciel utilisable afin d’apprendre par l’expérience plutôt que d’investir énormément dans une spécification potentiellement erronée.
Mais l’IA modifie brutalement cette équation.
Le coût marginal de production du code s’effondre.
Un agent peut produire en quelques minutes :
La ressource rare devient autre chose.
Elle devient :
Par conséquent :
plus le coût de production du code diminue, plus la valeur de la spécification augmente.
C’est peut-être le paradoxe fondamental de l’IA appliquée au développement.
Nous pensions que l’IA rendrait inutile tout ce qui précédait le code.
Elle pourrait produire exactement l’effet inverse.
Générer davantage de code n’est plus nécessairement un avantage
Vignesh Vijayaraghavan, Senior Software Engineer chez Microsoft Digital, résume cette idée avec une excellente formule :
“In the AI era, the best dev teams aren’t the ones that generate the most code. It’s about how they’re best able to preserve intent.”
En d’autres termes :
les meilleures équipes ne seront peut-être plus celles qui produisent le plus de code, mais celles qui préservent le mieux l’intention.
Cette phrase mérite que l’on s’y arrête.
Le code n’a jamais été une finalité.
Il est seulement la représentation exécutable d’une intention.
Pendant longtemps, nous avons parfois confondu les deux parce que la transformation de l’une en l’autre nécessitait énormément de travail humain.
Si cette transformation devient automatisable, alors la valeur remonte mécaniquement vers ce qui précède le code.
Et l’architecte revient par la grande porte
C’est probablement la partie que je trouve la plus intéressante.
Avant même la rédaction des specs, Microsoft explique que l’équipe définit une constitution.
Cette constitution contient notamment :
-
les principes architecturaux ;
-
les règles de gouvernance ;
-
les standards de sécurité ;
-
les contraintes de développement.
Elle fournit le cadre commun dans lequel humains et agents doivent travailler.
Ce concept existe également dans GitHub Spec Kit, l’outil utilisé pour soutenir ce type de workflow.
Autrement dit, on ne demande pas à l’IA :
« Construis-moi quelque chose de propre. »
On lui donne un espace de décision.
Par exemple :
-
.NET 10 ;
-
architecture hexagonale ou Clean Architecture ;
-
nullable activé ;
-
aucune dépendance UI dans le domaine ;
-
accès aux données derrière des interfaces ;
-
interdiction d’introduire de nouvelles dépendances sans justification ;
-
journalisation structurée ;
-
contraintes de sécurité ;
-
stratégie de tests ;
-
règles de performance.
Puis vient la spécification fonctionnelle.
Puis le plan.
Puis le code.
Ce n’est pas la disparition de l’architecture.
C’est exactement l’inverse.
L’IA rend l’architecture explicite à nouveau
Microsoft attribue explicitement aux architectes la responsabilité de ces guardrails.
Ils doivent établir et maintenir les principes architecturaux, les contraintes de gouvernance et les standards de sécurité qui encadrent le développement.
C’est une évolution remarquable.
Pendant des années, une certaine vision de l’Agile nous a expliqué que l’architecture devait émerger progressivement.
L’idée n’est pas totalement fausse.
Une architecture doit effectivement pouvoir évoluer.
Mais « évolutive » ne signifie pas « inexistante ».
Et avec des agents IA capables de produire énormément de code très rapidement, laisser émerger tous les choix structurants au fil des générations devient particulièrement risqué.
Un agent a besoin de contraintes.
Sans contraintes, il optimise localement.
Il trouve une solution plausible.
Pas nécessairement la solution cohérente avec le système que nous sommes en train de construire.
Le rôle de l’architecte redevient alors évident :
définir l’espace des solutions acceptables.
Le développeur change lui aussi de métier
Microsoft observe également un déplacement du rôle des développeurs.
Ils passent davantage de temps à :
-
raffiner les besoins ;
-
identifier les cas limites ;
-
évaluer les plans ;
-
contrôler les sorties générées ;
-
vérifier que l’implémentation correspond effectivement à l’intention.
Sudhakar Sadasivuni parle même d’:
“agent-first solutioning, not human-first solutioning.”
La formule peut être discutée, mais l’idée est claire.
Le développeur ne doit plus seulement produire une solution compréhensible par lui-même.
Il doit produire suffisamment de contexte explicite pour qu’un agent puisse travailler correctement.
Cela constitue un changement profond.
Le développeur devient moins exclusivement producteur de code et davantage concepteur, superviseur et validateur d’un système de production de code.
Est-ce la mort du développeur ?
Non.
Mais cela pourrait être la mort progressive d’une certaine conception du développeur.
Celle où la valeur individuelle se mesure principalement à la capacité à écrire rapidement une implémentation.
L’agent sera probablement meilleur que nous à ce jeu-là.
En revanche, comprendre qu’une demande métier contient une contradiction, repérer une hypothèse dangereuse, concevoir une abstraction correcte, anticiper les conséquences d’un choix architectural, arbitrer un compromis ou reconnaître qu’une solution techniquement élégante répond au mauvais problème restent des activités de très grande valeur.
En résumé :
l’IA automatise davantage l’exécution que le jugement.
Et cela réévalue mécaniquement les métiers orientés conception.
SDD tue-t-il Agile ?
Je répondrais donc :
non, si l’on parle du Manifeste Agile.
Peut-être en partie, si l’on parle de ce que l’Agile est devenu dans certaines organisations.
SDD reste compatible avec :
Mais il remet fortement en question l’idée selon laquelle on peut compenser un manque de compréhension initial par une succession d’itérations.
Dans un monde où la génération est lente, prendre une mauvaise direction pendant deux jours est regrettable.
Dans un monde où plusieurs agents peuvent produire des milliers de lignes dans cette mauvaise direction pendant ces mêmes deux jours, le problème change complètement d’échelle.
L’Agile disait :
ne tentez pas de prédire tout l’avenir.
Le SDD répond :
certes, mais avant de demander à une machine de construire quelque chose, assurez-vous au moins que vous savez ce que vous lui demandez.
Les deux propositions ne sont pas contradictoires.
Mais l’équilibre entre elles est clairement en train de changer.
SDD est-il un retour en arrière ?
D’une certaine manière, oui.
Et ce n’est pas nécessairement une critique.
Le développement logiciel fonctionne par cycles.
Nous adoptons une idée utile.
Nous la poussons trop loin.
Puis nous redécouvrons les qualités de ce qu’elle avait remplacé.
Les méthodes traditionnelles avaient raison sur un point :
la conception possède une valeur propre.
L’Agile avait raison sur un autre :
une conception ne doit pas devenir un dogme figé indépendamment de la réalité du produit.
Le SDD pourrait finalement représenter une synthèse intéressante :
-
conception explicite ;
-
spécification formelle ;
-
architecture préalable ;
-
mais artefacts vivants ;
-
petites unités ;
-
évolution continue ;
-
génération rapide ;
-
feedback accéléré.
Ce n’est donc peut-être pas le retour du Waterfall.
C’est peut-être le retour de la discipline d’ingénierie débarrassée d’une partie de sa lourdeur documentaire.
L’unité de production pourrait ne plus être le code
Il existe enfin une conséquence encore plus profonde.
Dans quelques années, nous regarderons peut-être notre obsession actuelle pour le code comme nous regardons aujourd’hui l’assembleur.
Il restera essentiel.
Mais beaucoup moins de personnes auront besoin d’en écrire directement autant.
La véritable unité de production du développeur pourrait devenir progressivement :
la spécification exécutable.
C’est-à-dire un ensemble cohérent comprenant :
L’agent transforme ensuite cette représentation en code.
Dans ce modèle, les langages naturels structurés, les DSL, les specs, les contraintes et les tests constituent presque un niveau de programmation supérieur.
On ne programme plus seulement la machine.
On programme l’agent qui programmera la machine.
Le retour du métier d’architecte
Et nous revenons finalement à un métier qui avait parfois été relégué à l’arrière-plan pendant les années Agile.
L’architecte logiciel.
Pas l’architecte qui dessine des boîtes PowerPoint pendant six mois.
Pas celui qui impose une architecture théorique que personne ne pourra modifier.
Mais celui dont le travail consiste à répondre à une question essentielle :
Dans quel espace de solutions voulons-nous laisser nos développeurs et maintenant nos agents travailler ?
Quels invariants doivent être respectés ?
Quelles dépendances sont acceptables ?
Quels compromis avons-nous choisis ?
Quelles règles ne doivent jamais être transgressées ?
Où se trouvent les frontières ?
Quels choix doivent rester cohérents dans le temps ?
Avec un humain écrivant son code manuellement, beaucoup de ces règles pouvaient rester implicites.
Avec plusieurs agents générant en parallèle, l’implicite devient un risque.
L’architecture doit donc devenir plus explicite, pas moins.
Une ironie assez savoureuse
Pendant vingt ans, l’industrie du logiciel a cherché à réduire la distance entre l’idée et le code.
Puis l’IA est arrivée.
Et elle est en train de supprimer presque entièrement cette distance.
Nous découvrons alors que notre principal problème n’était peut-être pas que nous codions trop lentement.
Le véritable problème était parfois que nous ne savions pas suffisamment précisément ce que nous voulions coder.
Le Spec-Driven Development n’est donc probablement pas la négation de l’Agile.
Il pourrait plutôt constituer la correction de certaines de ses dérives.
Quant au vibe coding, Microsoft semble avoir déjà livré un verdict assez clair :
excellent outil d’exploration ;
beaucoup moins convaincant comme méthode d’ingénierie à grande échelle.
Au bout du compte, derrière SDD, GitHub Spec Kit, les agents IA et les « constitutions » se cache peut-être une règle beaucoup plus ancienne :
comprendre d’abord, concevoir ensuite, coder enfin.
Nous n’avions probablement jamais cessé d’en avoir besoin.
Nous avions simplement commencé à l’oublier.
Et paradoxalement, c’est peut-être l’intelligence artificielle qui va nous obliger à nous en souvenir.
J'en suis personnellement très satisfait, c'est un peu la fin de l'imposture Agile telle que cette "méthode" est appliquée sauvagement un peu partout. Notre métier est beau, il évolue sans cesse, mais parfois une bonne petite claque pour rappeler les bases n'est pas inutile...
Stay tuned!