Des modèles aux agents : réorganisation des trois lignes de défense

L’IA agente remet en question les guides de gouvernance conçus pour les logiciels traditionnels et les modèles classiques, mais cette affirmation est plus facile à comprendre à travers un cas concret. Les années de travail en MLOps, qui couvrent les inventaires de modèles, les pipelines de validation, le suivi de la dérive et les workflows d’approbation dans les environnements d’entreprise et de services financiers, ne sont pas abandonnés lorsque l’organisation adopte des LLM et des agents. Ce qui change est plus restreint et plus spécifique que ce que la plupart des gens imaginent.

Imaginez une équipe chargée de la gestion des risques de modèles qui traite une demande de saisie ordinaire. Le formulaire pose les questions habituelles concernant les données d’entraînement, le numéro de version, l’état d’approbation et la date de la dernière vérification de dérive, et l’équipe en a déjà traité beaucoup. Puis arrive la description du système : quatre agents coopérant, six outils partagés entre eux, un index de recherche reconstruit chaque jour, et un résultat obtenu grâce à une chaîne de processus où chaque étape individuelle semblait correcte. Rien dans le formulaire ne correspond.

Un sondage McKinsey AI Trust de 2026 portant sur environ cinq cents organisations montre une image similaire : près d’un tiers des entreprises affirment que leur niveau de maturité en matière de gouvernance est suffisant pour les agents autonomes déjà en fonctionnement. Les autres continuent d’utiliser l’ancien formulaire de saisie en espérant qu’il soit suffisant. En général, ce n’est pas le cas, il est donc utile de déterminer précisément où il échoue.

Ce que le programme existant couvre déjà

La gouvernance MLOps est l’ensemble des contrôles qui permettent de maintenir la fiabilité d’un modèle de machine learning traditionnel, de sa phase d’entraînement jusqu’à son retrait. En pratique :

• La versionnement des modèles, afin de savoir toujours quel modèle est utilisé en production et pourquoi.
• La surveillance de la dérive, qui permet de détecter le déclin des performances lorsque les données d’entrée changent.
• Le suivi de l’origine des données jusqu’aux ensembles d’entraînement et de validation.
• Des étapes d’approbation avant toute mise en production.
• Les pratiques de CI/CD et de gestion des changements exigées pour tout logiciel en production, qui font partie intégrante de ce programme et non quelque chose qui s’y ajoute en parallèle.

Aucun de ces éléments ne s’applique automatiquement. Quelqu’un doit être responsable de chaque contrôle, et quelqu’un d’autre doit vérifier que cette personne a bien accompli sa tâche.

La responsabilité est généralement attribuée selon le cadre des trois lignes de défense, système que les banques et d’autres secteurs régulés utilisent depuis longtemps pour déterminer les responsabilités. Une précision : l’Institut des auditeurs internes l’a renommé modèle des trois lignes en 2020, en mettant l’accent sur la création de valeur plutôt que sur la simple défense. Les spécialistes des finances et des risques liés aux modèles continuent d’utiliser l’expression « trois lignes de défense », tout comme ce texte, bien que le nom officiel ait changé.

Dans un programme MLOps conventionnel, la répartition se fait comme suit :

• La première ligne, qui couvre le produit, les données et l’ingénierie, est chargée du développement, des tests, du déploiement et de la documentation des modèles.
• La deuxième ligne, qui concerne le respect des réglementations et la gestion des risques, définit les politiques d’utilisation des modèles, surveille les biais et examine les applications à haut risque avant leur mise en œuvre.

La troisième ligne, l’audit interne, a le mandat le plus restreint : confirmer de manière indépendante que les deux premières lignes font bien ce qu’elles prétendent, sans créer ou approuver quoi que ce soit par elle-même.

Cette structure est mature et bien comprise, et elle fonctionne pour les systèmes pour lesquels elle a été conçue, à savoir des modèles dont la structure est fixe, validée une fois et surveillée entre les cycles d’examen.

Comment chaque ligne doit évoluer pour les agents

La gouvernance AgentOps part des mêmes trois lignes, mais la nature des éléments que chacune inspecte diffère, car les systèmes se comportent différemment. Les écarts relevés se résument à cinq différences spécifiques.

Un artefact devient plusieurs. Un modèle classique consiste en une seule entité à versionner. Le système à quatre agents est un ensemble : le modèle de base, quatre prompts système, six définitions d’outils, ainsi qu’une couche de récupération qui se met à jour selon son propre rythme. Chacun de ces éléments peut modifier le comportement, ce qui oblige à versionner et à tester chaque composant. Cela ressemble moins à une entrée de registre qu’à des prompts et des schémas d’outils traités comme du code source, avec un contrôle de version, une revue des demandes de fusion et des tests canari sur un ensemble de données réservé avant toute mise en production. Se concentrer uniquement sur le modèle laisse environ les trois quarts des aspects comportementaux non gérés.

Une sortie correcte relève de la plage acceptable. En fournissant le même entrée à un modèle traditionnel, on obtient la même sortie, ce qui rend la validation simple. Un LLM peut produire deux réponses différentes mais justifiables à différentes exécutions. Ainsi, la deuxième étape cesse de se demander si une réponse est correcte pour vérifier plutôt si les réponses restent dans une fourchette acceptable la plupart du temps. Cela exige une porte d’évaluation avec des seuils définis, comme un taux de réussite minimal sur un ensemble de test étiqueté avant la mise en production, ainsi qu’un mécanisme de révision humaine lorsque la confiance ou les scores d’évaluation descendent en dessous d’un seuil minimum. Définir ce qui est acceptable la plupart du temps pour un cas d’usage donné relève d’un projet à part entière, et non quelque chose qui peut être accompli en une après-midi.

Un seul propriétaire devient une chaîne. Un modèle isolé qui effectue une prédiction isolée a un propriétaire évident. Un système composé de quatre agents n’en a pas. Lorsque le résultat final est erroné mais qu’aucune étape individuelle n’est fausse, le diagnostic nécessite un journal des décisions qui enregistre les transferts intermédiaires ainsi que le produit final : les entrées de chaque agent, chaque décision prise, et ce qui a été transmis. En l’absence de tel journal, personne ne peut déterminer quel agent est responsable, et les premières et les secondes lignes se disputent à ce sujet après un incident au lieu de s’accorder à l’avance.

Le suivi de la dérive n’est pas un suivi du comportement. Les vérifications de dérive comparent les prédictions à une référence connue. Elles ne prennent pas en compte ce que l’agent fait pendant l’exécution : les outils qu’il a invoqués, les actions qu’il a entreprises, ni le fait qu’il reste dans les limites prévues. Les plateformes d’observabilité des agents ciblent ce point aveugle en enregistrant l’intégralité de la trace d’exécution, y compris les appels aux outils, les paramètres, ainsi que la manière dont la sortie d’un agent alimente le suivant. Beaucoup d’entre elles s’appuient sur des normes ouvertes telles que OpenTelemetry, qui permettent aux traces d’être portables entre différents fournisseurs. Pour ce système, la trace est le seul artefact à partir duquel un auditeur peut reconstruire les événements ultérieurement. En l’absence de celle-ci, l’audit de la troisième ligne consiste à examiner une boîte noire et à le qualifier de vérification indépendante.

La réentraînement du calendrier devient un changement continu. Les modèles traditionnels sont réentraînés selon un calendrier prédéfini : mensuellement, trimestriellement, chaque fois que suffisamment de nouvelles données se sont accumulées. Un système basé sur RAG ou sur un affinage continu peut modifier son comportement efficace aussi souvent que sa base de connaissances est mise à jour, éventuellement quotidiennement. Si la couche de récupération est mise à jour chaque nuit, une troisième étape basée sur des revues trimestrielles vérifie le système environ quatre-vingt-dix fois moins souvent que celui-ci ne change.

Où les deux approches se rencontrent

En comparaison directe, les deux approches partagent une structure de base. Les mêmes trois étapes s’appliquent, et toutes deux nécessitent une gestion des versions, des tests, des revues ainsi qu’un audit indépendant. Les différences résident dans la granularité, la fréquence et l’objet que chacune contrôle.

La gouvernance MLOps n’est pas en cause ici. Ses principes reposaient simplement sur l’hypothèse que le comportement du modèle reste stable entre les vérifications, or un système dont l’index de récupération est reconstruit chaque nuit ne peut pas rester inchangé aussi longtemps. Les cinq différences mentionnées proviennent toutes de l’échec de cette hypothèse : ce qui changeait autrefois tous les mois peut désormais le faire quotidiennement, parfois sans que personne ne touche au modèle.

Compléter cette lacune ne nécessite pas la création d’une nouvelle fonction de gouvernance à partir de zéro. Il suffit d’ajouter aux outils existants des capacités dont ils n’avaient pas besoin auparavant, tout en étant honnête quant au coût de chacune d’elles :

• Première mesure : un contrôle de version pour les prompts et les outils, accompagné de tests de canari avant leur mise en production. Il s’agit principalement d’une modification des pratiques d’ingénierie et non de la création d’une nouvelle équipe.
• Deuxième ligne : une porte d’évaluation indiquant les seuils d’acceptation, ainsi qu’une procédure écrite pour l’escalade des décisions impliquant plusieurs agents. Il s’agit d’un véritable projet de rédaction de politiques, et la première étape nécessitera des négociations réelles avec les services juridiques et de conformité.
• Troisième ligne : des outils d’observabilité en temps réel et les compétences nécessaires pour auditer un journal des décisions, au lieu d’une fiche de modèle statique. Pour la plupart des services chargés des risques liés aux modèles, cela signifie recruter de nouveaux collaborateurs ou leur fournir une formation approfondie, et non simplement cocher une case dans un ancien modèle de revue.

Aucun de ces éléments n’est optionnel si l’objectif est de déterminer de manière crédible quel des quatre agents a pris la décision.

Ce que les régulateurs ont dit jusqu’à présent

Aucun cadre réglementaire unique n’a encore pleinement suivi l’évolution de l’IA agente, mais trois modèles existants provenant de secteurs différents montrent quelle direction prend ce domaine.

• Le règlement UE sur l’IA s’applique à tous les secteurs. Les obligations de transparence prévues à l’article 50 entrent en vigueur le 2 août 2026, quelles que soient les autres évolutions. Les exigences plus strictes de l’annexe III relatives aux dispositifs à haut risque étaient initialement prévues pour cette même date, mais le paquet législatif Digital Omnibus, convenu en principe en mai 2026 et encore en attente d’adoption officielle, reporterait leur application au 2 décembre 2027. Un calendrier de conformité devrait indiquer ce report comme étant en attente.
• La manière dont la FDA traite les dispositifs médicaux utilisant l’IA est axée sur le secteur spécifique et le produit, et son outil principal est le Predetermined Change Control Plan. Grâce à ce plan, l’approbation initiale autorise déjà certaines mises à jour de modèles, à condition qu’elles restent dans les limites de performance définies. Il s’accompagne de directives relatives aux bonnes pratiques en apprentissage automatique ainsi que d’un système de qualité orienté vers la norme ISO 13485. En pratique, le contrôle des modifications fait partie intégrante du processus d’approbation, et non une obligation ajoutée ultérieurement.
• Les directives financières sont instructives en partie pour ce qu’elles omettent. Le guide interagences de 2026 SR 26-2, qui a remplacé SR 11-7, exclut explicitement l’IA générative et agente de son champ d’application formel. Un cadre mature admet que les outils conçus pour une génération de modèles ne s’adaptent pas automatiquement à la suivante, et les entreprises qui s’y conforment développent déjà des mécanismes de gouvernance pour les agents avant même les autorités de contrôle.

Aucun de ces trois documents ne constitue un modèle à copier. Lus ensemble, ils indiquent une direction : modifier les limites autorisées à l’avance, les niveaux de risque, ainsi que la reconnaissance ouverte du décalage entre les règles actuelles et le comportement des agents.

Retour au formulaire de demande

Le formulaire de demande existant peut rester en place. Parallèlement, l’équipe a besoin d’un questionnaire distinct pour les systèmes multi-agents, organisé autour des trois axes sur lesquels il s’appuie déjà, et elle doit s’attendre à ce que répondre honnêtement demande un effort réel.

Quelle étape un programme rattrapera-t-il en premier ? Probablement la gestion des versions, car cela ressemble à un problème de contrôle de version que les ingénieurs savent déjà résoudre. La responsabilisation pour les décisions en chaîne restera probablement le point le plus difficile à résoudre. Il s’agit d’un problème de conception organisationnelle sous un aspect technique, et aucune étape d’évaluation ne peut y remédier.

Lectures complémentaires

• Des boucles d’agents aux graphes de flux de travail : états typés, portes de validation et récupération bornée — Pourquoi les agents à exécution prolongée dépassent les limites d’une seule boucle, et comment des nœuds explicites, des arêtes, des artefacts typés, des transitions vérifiées et des permissions par nœud en font des systèmes fiables.
• LLMOps pour un agent assistant aux tâches : MLflow Traces, Evals et une porte CI — Créez un assistant aux tâches PydanticAI avec FastAPI, traçez son fonctionnement avec MLflow, évaluez ses performances avec des outils GenAI et bloquez les dérives dans GitHub Actions, tout cela en utilisant des modèles locaux.

Mémoire à long terme recherchable pour les agents d’ingénierie de données — Comment un système d’ingénierie de données multi-agents a cessé de déboguer les mêmes erreurs : capture automatique, journaux ciblés, organisation structurée des informations et récupération au niveau du contexte.