Avec l'IA agentique, la spécification redevient le vrai actif logiciel

Avec l’IA agentique, la spécification redevient le vrai actif logiciel

On a longtemps considéré la spécification comme un mal nécessaire. Le manifeste agile, en 2001, préférait « un logiciel qui fonctionne » à « une documentation exhaustive », et vingt ans de projets en ont fait une habitude : on documente peu, tard, et personne ne relit vraiment. Ce désamour restait sans conséquence tant que des humains écrivaient le code. Il devient un problème sérieux depuis que des agents l’écrivent à leur place.

Du vibe coding à l’Agentic Engineering

Le développement applicatif a débordé le cercle des développeurs et des DSI : ce sont souvent les équipes métiers, séduites par l’apparente magie de l’IA générative, qui s’en emparent, et la majeure partie du code produit est désormais générée par des modèles de langage. Ce qui pilote cette production reste largement artisanal : des prompts improvisés dans une fenêtre de chat, puis perdus quand la session se ferme. Andrej Karpathy l’avait baptisée en 2023 « vibe coding » : coder à l’intuition, sans intention formalisée. Sur un système d’information, cela fabrique une dette d’un genre nouveau, la dette de compréhension : du code qui fonctionne, mais que plus personne ne sait l’expliquer ni le maîtriser.

Le vibe coding peut servir un POC ; déployé à l’échelle, il devient un danger, et les DSI l’ont compris. Car une application d’entreprise exige expertise et maîtrise à tous les niveaux. C’est ce que recouvre l’Agentic Engineering et sa pratique emblématique, le Spec-Driven Development : décrire précisément ce que l’on attend, dans un document structuré et versionné, puis laisser les agents générer le code. Le code devient un artefact vérifiable, comparable à l’intention, voire régénérable. Mais le vrai changement n’est pas dans les outils : la réflexion d’ingénierie se déplace du code vers la spécification. La méthodologie impose impérativement un code compris et validé par l’humain, qui reste maintenable dans le temps.

Ni retour au cycle en V, ni utopie du « tout spec »

Gardons-nous de deux contresens : le retour au cycle en V documentaire, ou l’utopie d’un logiciel dont on n’éditerait plus jamais le code. Les travaux récents distinguent trois niveaux de maturité. Le premier, « spec-first » : la spécification initie la génération, le code peut ensuite diverger. Le deuxième, « spec-anchored » : spécification et code évoluent ensemble, des tests automatisés vérifiant leur alignement. Le troisième, « spec-as-source », où l’humain n’édite plus que la spécification, jamais le code généré, reste une aspiration précoce. En production, le deuxième constitue le bon point d’équilibre. Les hallucinations et la dérive ne disparaissent pas parce qu’on a bien rédigé sa spécification ; elles se minorent, et se gèrent avec méthode.

Encore faut-il s’entendre sur ce qu’est une spécification à l’ère agentique. Pas un cahier des charges en prose, mais un artefact semi-structuré, lisible par les humains comme par les agents, dont les exigences s’appuient sur des règles métiers explicites et normalisées, et dont les critères d’acceptation adoptent un formalisme hérité du Behavior-Driven Development. Rédigées ainsi, elles se transposent presque directement en cas de test : la spécification devient exécutable.

Ce que cela change dans la mécanique du delivery

Ce basculement se joue très en amont. La structuration des entrants devient un vrai travail d’ingénierie, organisé autour d’une chaîne d’artefacts : un PRD qui fixe l’intention précise du produit, des SPECS que le business analyst valide minutieusement, un PLAN d’implémentation que le développeur valide avec la même exigence, et des tests de bout en bout versionnés avant la première ligne de code générée. S’y ajoute un changelog tenu à jour, trace de chaque évolution et condition de la maintenabilité applicative dans la durée. L’ensemble alimente un corpus contextuel, règles d’architecture, conventions, décisions du projet, que les agents consultent via des protocoles standardisés.

Ce retour en grâce rebat les cartes des rôles. Le business analyst retrouve une valeur centrale : c’est lui qui transforme le besoin métier en exigences exploitables par les agents et garantit que la formalisation dit ce que le métier veut exprimer. Le client, lui, ne valide plus seulement des écrans en recette : il valide la source de vérité elle-même. Critères d’acceptation et tests de bout en bout sont approuvés en atelier, puis confrontés au logiciel à chaque merge et livraison.

La spécification devient alors le contrat entre le métier, l’équipe et les agents, et la référence quand le comportement observé s’écarte de l’intention déclarée. Cette dérive, autrefois découverte en recette, se surveille désormais en continu : tests et analyse statique rendent un verdict qui ne dépend pas de l’humeur d’un modèle.

La logique s’étend au-delà du produit. Des normes dans l’industrie codifient désormais la façon même de travailler des agents, sous forme de compétences versionnées comme du code : découper un plan en micro-tâches vérifiables, écrire les tests avant l’implémentation, faire relire chaque incrément pour sa conformité à la spécification puis pour la qualité du code. C’est à nos yeux le cœur déjà acquis d’une méthodologie de delivery agentique : ce savoir-faire se capitalise de projet en projet. L’objet du jugement humain se déplace : moins de frappe, plus de revue et d’arbitrage sur la sémantique métier, la structure logicielle et le risque. L’architecte de spécifications est en train de succéder au prompt engineer.

Pour le DSI, un actif de gouvernance

Pourquoi s’en préoccuper maintenant ? Parce qu’un patrimoine de spécifications versionnées, alignées sur le code, change la position de la DSI sur plusieurs fronts. La documentation cesse de mentir, puisque les tests la vérifient. L’auditabilité devient native, quand la réglementation européenne sur l’IA impose la traçabilité. La réversibilité redevient réelle, vis-à-vis des prestataires comme des outils. Et elles seront la matière première de la régénération, le jour où il faudra changer de framework ou d’architecture.

Le code n’a jamais été aussi facile à produire. L’intention formalisée et qualifiée qui le gouverne, elle, est redevenue rare. À l’ère agentique, la question à se poser n’est plus « qu’avons-nous codé ? », mais « qu’avons-nous spécifié ? ». La qualité et la maintenabilité du code, elles, restent non négociables.

Source : Journal du Net

Source
Leave a Comment

Comments

No comments yet. Why don’t you start the discussion?

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *