Spec-Driven Development : quand le métier cesse d’attendre l’ingénierie

Le cycle de développement moyen d’une nouvelle fonction en entreprise dure de trois à six mois. Lorsqu’elle est enfin livrée, le marché a évolué, les priorités ont changé et une partie des exigences initiales ne reflète plus la réalité. Personne n’est en faute. Le processus fonctionne exactement comme il a été conçu. C’est bien là le problème.

Le Spec-Driven Development entend rompre avec ce modèle, et non le rapiécer.

Là où le développement traditionnel achoppe réellement

Le processus logiciel classique s’apparente au jeu du téléphone sans fil. Le métier formule une idée. Un analyste l’interprète. Un architecte la traduit en spécification technique. Un développeur lit cette spécification à travers son propre modèle mental. L’équipe qualité teste ce qui a été construit, et non ce qui était voulu. À chaque passage de relais, le signal se dégrade, si bien qu’au moment de la livraison le produit met en œuvre quelque chose de proche de l’intention initiale, sans tout à fait y correspondre.

Ce n’est pas une question de talent, mais d’architecture : trop d’interprètes entre l’intention et le résultat.

Le second point de rupture est le coût du changement. Les travaux sur la gestion des exigences montrent de manière constante que corriger une erreur introduite au stade des exigences coûte 5 à 10 fois plus cher une fois qu’elle est inscrite dans du code opérationnel. Le métier le sait et évite donc de modifier les exigences. L’ingénierie le sait et résiste donc aux changements de périmètre. Les deux parties finissent par travailler sur une image dépassée de la réalité, simplement pour éviter la facture des reprises.

Ce que le SDD change réellement

L’idée centrale est d’une simplicité trompeuse : la spécification devient l’artefact de référence de l’ensemble du projet, et les agents d’IA se chargent de la réalisation technique.

Le métier décrit ce que le système doit faire, en langage courant, sans jargon technique. L’agent d’IA détermine comment le réaliser. L’ingénieur contrôle la qualité et l’exactitude de cette traduction. Le code devient un dérivé de la spécification, et non l’inverse.

Trois choses changent fondamentalement.

La vitesse. Un prototype opérationnel d’une nouvelle fonction en quelques jours, et non en quelques semaines. Plusieurs hypothèses testées en parallèle. Une validation rapide des idées métier, sans mobiliser un sprint complet. Selon Bain & Company, les outils d’IA raccourcissent déjà les cycles de développement de 20 à 30 %. Le SDD va plus loin : il automatise non seulement la génération du code, mais aussi la traduction des exigences, étape la plus lente et la plus coûteuse de tout le processus.

Le coût du changement. En développement traditionnel, modifier les exigences en cours de projet relève presque de la crise. En SDD, c’est une opération de routine. Le code étant généré à partir de la spécification plutôt qu’écrit à la main, le régénérer ne coûte presque rien. La logique de décision s’en trouve entièrement modifiée : les équipes peuvent expérimenter, éprouver leurs hypothèses et changer de cap sans redouter la facture des reprises.

Un exemple concret : une équipe bâtit une architecture autour d’un modèle économique donné, puis découvre au bout d’un mois que ce modèle est erroné. En développement traditionnel, ce sont trois à quatre mois de travail perdus. En SDD, la spécification est corrigée en une journée, et le code est régénéré en quelques heures.

La transparence. La spécification n’est pas un document technique : c’est un document métier. Les parties prenantes non techniques peuvent la lire, la vérifier et la modifier. Le métier voit précisément ce qui sera construit avant le début du développement. Tout écart par rapport à la logique métier apparaît au niveau de la spécification, et non après la mise en production. L’historique complet des modifications d’exigences est versionné et consultable.

Ce que cela change pour l’équipe

Le SDD ne supprime pas les ingénieurs. Il change ce qui fait leur valeur. La maîtrise approfondie d’une pile technique compte moins ; la pensée architecturale et la capacité à formaliser les exigences comptent davantage. Un ingénieur qui orchestre des agents d’IA assume désormais la charge de travail qui nécessitait auparavant une équipe de trois ou quatre spécialistes.

McKinsey fait état de gains de productivité de 20 à 45 % dans les organisations qui ont intégré l’IA de manière systématique à leurs processus de développement. Le SDD amplifie ces gains en automatisant le cycle complet, des exigences jusqu’au code.

Un effet moins visible mérite d’être souligné : la préservation des connaissances. Dans le modèle traditionnel, la logique métier réside dans la tête des personnes. Lorsqu’un ingénieur clé s’en va, un savoir essentiel sur les raisons pour lesquelles le système fonctionne ainsi part avec lui. En SDD, la spécification est un document vivant qui contient la description complète de la logique métier du système. Un nouvel arrivant la lit et comprend immédiatement l’ensemble du système.

Là où il donne les meilleurs résultats

Le SDD produit son plein effet dans des situations précises. Les start-up dont les exigences sont très incertaines et qui changent souvent de cap : le coût de l’expérimentation devient quasi nul. Les marchés concurrentiels aux cycles de mise sur le marché rapides : la vitesse de livraison des nouvelles fonctions influe directement sur les parts de marché. Les environnements réglementés : les exigences de conformité sont intégrées à la spécification et vérifiées automatiquement à chaque modification. La modernisation des systèmes hérités : la spécification du système existant est rédigée une fois pour toutes et sert de fondement à une migration maîtrisée.

La réserve qui s’impose

Le SDD ne remédie pas à des exigences mal formulées : il les met au jour. Si le métier ne sait pas décrire clairement ce qu’un système doit faire, aucun agent d’IA ne comblera ce vide. La qualité de la spécification devient le goulet d’étranglement critique. C’est une compétence nouvelle, qu’il faut développer côté métier comme côté ingénierie.

Mais c’est précisément le sens de cette évolution. Le SDD n’automatise pas la réflexion. Il supprime tout ce qui s’interpose entre la réflexion et le résultat.