Transformation de l’ingénierie logicielle

Une bascule profonde de notre activité de software engineer est en cours : en plus de l’ingénierie logicielle “classique”, l’ingénierie agentique pose le cadre de l’agent IA via de nouveaux mécanismes : contexte, boucles de feedback, preuve et vérifiabilité. Pour une chaîne logicielle robuste, ces deux types d’ingénierie doivent fonctionner de pair. Ce chapitre décrit cette transformation : ce que l’IA déplace dans l’ingénierie classique, puis les nouveaux espaces qu’ouvre l’ingénierie agentique.

L’ingénierie logicielle classique

Les enjeux ci-dessous ne sont pas nouveaux : l’IA en déplace les curseurs et les démultiplie, mais ces enjeux étaient déjà présent à l’ère pré-IA.

L’humain augmenté, toujours en maîtrise de ce qu’il construit

Les enjeux du développement logiciel restent les mêmes, avec ou sans IA, et l’humain y garde un rôle central.

• Contrôle et arbitrage : l’IA apporte une assistance précieuse pour guider les choix, mais l’humain doit impérativement rester aux commandes.
• Compétences et expérience : faire des choix pertinents exige le recul, le jugement, le goût (taste) et l’expérience que seul l’humain possède. Mais c’est “The ironies of automation” : cette expertise n’est plus acquise par les humains du fait de cette automatisation, alors qu’elle devient encore plus critique.
• L’humain augmenté : le concept clé est celui d’un humain dont les capacités sont démultipliées par l’IA, tout en gardant une maîtrise totale de la trajectoire.

Trois périmètres d’ingénierie constants et avec plus d’importance : l’intention en amont, la production en aval, et l’architecture et le design en transverse.

Les enjeux d’ingénierie logicielle traditionnelle sont toujours d’actualité avec un focus encore plus crucial sur trois périmètres :

• En amont, la définition du besoin et de la solution. La valeur se déplace vers ce qui doit être construit* : les besoins des utilisateurs et la valeur métier apportée par la solution. Définir l’intention, les problèmes à résoudre et le modèle du domaine relève du jugement humain.
• En aval, la production et la conformité. Automatiser l’envoi en production d’un code souvent généré par l’IA impose de renforcer les mécanismes de CI/CD et d’y intégrer des garde-fous (guardrails) stricts. Au-delà de l’observabilité et de la production readiness (capacité à passer en production avec les exigences qualités attendus), l’enjeu central est maintenant la production correctness : garantir que le comportement en production reste parfaitement aligné avec l’intention de départ.
• En transverse, architecture et exigences non-fonctionnelles. Il s’agit de garantir la cohérence globale du système, sa modularité, son design et celui des concepts métiers qu’il manipule (son domaine), tout en adressant les exigences non-fonctionnelles de qualité (Non Functional Requirements ou NFRs) : fiabilité, performance, scalabilité, opérabilité, sécurité, etc. bref toutes les “.ilities”. Sur ce point, l’IA en fait évoluer plusieurs : la maintenabilité change de paradigme ; la sécurité fait face à des menaces exponentielles, exigeant un durcissement (hardening) encore plus important des systèmes ; la testabilité évolue vers une notion plus globale de vérifiabilité du système.

Une stratégie de test démultipliée

L’usage de l’IA démultiplie l’importance de la stratégie de test. Deux familles d’approches se complètent :

• Mécanismes computationnels et déterministes (tests classiques) : validation dès la phase de design (approche Outside-In, Acceptance Testing, TDD en double boucle), complétée par les tests d’intégration, end-to-end, de charge / performance et de sécurité. Ils garantissent que le système répond strictement aux comportements et aux NFR attendus. Ici l’IA nous permet d’aborder le territoire du property-based testing et d’aller au delà de l’example-based testing.
• Mécanismes inférentiels (LLM-as-a-Judge) : des modèles de langage portent un jugement qualitatif — revue de code, évaluation de la maintenabilité, de la modularité, du respect des patterns d’architecture — là où les tests déterministes sont nécessaires mais pas suffisants.

Au-delà du TDD : la boucle de feedback de l’humain doit-elle remonter vers l’amont ?

Conviction. Cette section sur l’évolution du TDD relève encore de la conviction, à éprouver à l’épreuve du réel. Nous le signalons comme tel : le reste du handbook s’appuie sur des pratiques avérées.

Avant l’IA, le TDD était bien plus qu’une pratique de test c’était une pratique de conception : une boucle de feedback pour l’humain pour évaluer ce que l’on construit et notre compréhension. Écrire un test sur un exemple concret, avec de vraies valeurs, révélait immédiatement si l’on avait compris ou non son domaine. On s’exerçait sur les concepts, on avançait par petits pas, et la compréhension fine du métier se construisait dans ce geste.

Dès lors que c’est l’agent qui écrit le code, cette boucle se rompt. L’humain perd le retour immédiat, et surtout il perd le fait de s’exercer sur le domaine. Il ne s’agit pas d’« aller au-delà » du TDD au sens de le dépasser : le TDD ne répond simplement plus au besoin qui était le sien, c’est à dire donner à l’humain un retour sur sa propre compréhension.

Le TDD garde une place mais pour l’agent. On continue de demander à l’agent un TDD en double boucle : c’est alors un harnais pour l’agent, une discipline qu’on lui impose pour qu’il produise mieux (cf. Vérifier son travail), et non plus une boucle d’apprentissage pour l’humain.

Le vrai enjeu devient donc de reporter cette boucle de feedback pour l’humain vers l’amont, là où se loge désormais la valeur : l’intention. Comme pour le TDD, cette boucle de retour doit se compter en minutes.

L’invariant, lui, ne bouge pas : comprendre son domaine en s’exerçant avec de vraies valeurs. Définir un besoin, c’est d’abord avoir compris le problème et les concepts du domaine employés pour le résoudre. On ne raisonne pas sur « une demande de crédit » en abstrait, mais sur « une demande de tel montant, avec telles caractéristiques, dans tel contexte de liability » : ce sont ces exemples concrets qui révèlent si le domaine est réellement compris. Et comme on ne peut jamais tout connaître à l’avance (l’écueil historique du waterfall…) la démarche reste itérative et incrémentale. L’IA ne supprime pas ce besoin, elle en change la vitesse et les artefacts.

Reste qu’on ne « vibecode » pas une application de production. Entre l’intuition et la prod, il faut un artefact intermédiaire, la spec, sans zone d’ombre, idéalement appuyée sur un modèle de domaine et des approches par scénario. Cette spec est confiée à un agent, mais piloté par un humain, un software engineer, qui :

• transmet à l’agent toutes les règles propres à la stack (celles que l’on retrouve disséminées dans le code) ;
• prend les décisions liées aux NFRs — modularité, performance, architecture, patterns, etc. — qu’un product owner ne peut pas prendre ;
• et surtout vérifie que l’agent produit bien ce qui a été demandé.

C’est bien cette activité “cadrer, décider, vérifier autour de l’agent” que l’on nomme ingénierie agentique.

Le legacy, un enjeu toujours majeur

Les systèmes legacy (brownfield) sont un enjeu toujours fort. Il pose des défis d’ingénierie bien plus complexes que le développement de zéro (greenfield).

• Objectifs opérationnels : assurer le maintien en condition opérationnelle (MCO / continuity), faire évoluer, moderniser ou refondre les systèmes.
• Défis techniques : reprendre le contrôle sur un système dont on ne connaît pas/plus le comportement attendu, gérer le double run, piloter les transitions et réussir les migrations.
• Rôle de l’IA : son apport est indéniable pour aider sur ces sujets, notamment la reprise de contrôle et la compréhension de systèmes Legacy compliqués, mais sans le discernement d’un expert humain, elle peut générer encore plus de bruits que de signal et donner l’illusion du contrôle.

L’ingénierie logicielle agentique

L’IA ouvre de nouveaux espaces d’ingénierie : l’intégrer comme un acteur à part entière du cycle de vie, et déployer des mécanismes de preuve et de vérifiabilité bien plus robustes. C’est l’objet de ce livret, et le cœur de notre approche.

Cadrer signifie mettre en place un harnais autour de l’agent sur 3 sujets :

• « Comment le faire ? » où l’on assemble tout ce qui permet à l’agent de savoir comment réaliser correctement ce qu’on lui demande, son contexte. We arrange the context.
• « Quoi faire ? » en donnant une description claire de la tâche à réaliser et du résultat attendu, c’est l’instruction. We instruct the job.
• « Comment vérifier que le résultat est correct ? » via des mécanismes de validation et des boucles de feedback mis à disposition de l’agent afin qu’il vérifie ce qu’il a généré et puisse itérer : tests, rendu navigateur, agent de review. Certains mécanismes tranchent en pass/fail, d’autres fournissent un jugement. We assert the result.

Ces trois questions reprennent le pattern AAA - Arrange, Act, Assert - bien connu des développeurs pour leur activité de test que nous adaptons en Arrange, Instruct, Assert. Nous utilisons cette analogie tout au long du livret, car elle sépare clairement les responsabilités, à la manière d’un test unitaire :

• Arrange the context : construire le contexte employé par l’agent ;
• Instruct the job : l’action ou le travail demandé à l’agent ;
• Assert the result : les mécanismes qui vérifient que le résultat est conforme à l’intention et aux exigences de qualité.

Cette analogie tient sur une posture : si un agent ne produit pas le résultat attendu en terme de qualité ou tout simplement de correctness avec l’intention initiale, il nous faut agir sur ou plusieurs de ces trois piliers : raffiner le contexte, l’instruction ou le feedback. Le présent livret vous aide à outiller ces trois phases.