IA agentique : de l'observabilité technique à la gouvernance opérationnelle

Quand les agents IA entrent dans le SI

Pendant « longtemps », l’IA générative est restée limitée à des usages relativement circonscrits, à savoir produire un texte, résumer un document, assister un développeur ou répondre à des questions simples. L’agent IA marque une étape, une évolution différente, puisqu’il peut choisir un outil, appeler une API, consulter une base documentaire, créer un ticket, voire enchaîner plusieurs opérations dans un même processus.

Ce changement modifie naturellement le niveau de risque, car si un chatbot peut se tromper dans une réponse, un agent connecté au SI peut déclencher une action incorrecte, exposer une donnée, appeler le mauvais service ou produire un résultat difficile à expliquer… avec des conséquences plus ou moins graves.

Dès lors, l’agent doit être traité comme un composant opérationnel, avec un périmètre, des droits, des dépendances et une responsabilité.

Des systèmes moins prévisibles que les applications classiques

Dans les grandes lignes, la différence d’un agent IA avec une application traditionnelle tient à la manière d’agir. Là où un logiciel classique va exécuter une logique codée, un agent IA, lui, interprètera une intention, mobilisera des outils, récupèrera des informations et ajustera son chemin selon ce qu’il rencontre.

Deux requêtes proches peuvent donc produire des séquences différentes.

Cette part de non-déterminisme n’est pas un défaut en soi. Elle fait aussi l’intérêt des agents, capables de traiter des situations moins rigides que des workflows classiques.

Mais elle complique le diagnostic.

Une erreur peut venir du modèle, d’un prompt, d’un outil mal décrit, d’une donnée récupérée, d’un droit trop large ou d’un enchaînement inattendu. Autrement dit, le code ne suffit plus à comprendre ce qui s’est passé. Il faut pouvoir relire la trace complète de l’action.

L’observabilité, condition technique de confiance

L’observabilité devient alors le premier prérequis. Un agent en production doit laisser des traces exploitables (documents consultés, temps de réponse, erreurs, validations humaines éventuelles, etc.). Sans ces éléments, impossible de corriger, ni d’auditer ou d’améliorer.

Fabien Pasquet, Lead Développeur Fullstack JS/IA pour l'agence de développement IA, Eleven Labs détaille : « Sans observabilité, un agent IA devient vite difficile à piloter en production. Au Lab IA d’Eleven Labs à Paris, on mène des travaux de R&D en continu pour identifier les meilleurs outils, mécanismes et pratiques en matière de traçabilité : suivi des prompts, analyse des décisions, monitoring des appels outils. Dans ce cadre, on a identifié que des solutions comme Langfuse permettent de comprendre le comportement de l’agent, détecter les dérives et améliorer le système dans la durée. »

Cette approche rejoint les travaux menés autour d’OpenTelemetry, qui cherchent à adapter l’observabilité aux systèmes agentiques, en instrumentant notamment les appels aux modèles, aux outils et aux bases de connaissance. Plusieurs plateformes d’observabilité LLM décrivent désormais l’exécution d’un agent comme une chaîne complète à suivre, depuis les prompts jusqu’aux appels d’outils, afin de comprendre le comportement réel du système.

Une IA non observable recrée une boîte noire au cœur du système d’information. C’est précisément ce que les entreprises cherchent à éviter lorsqu’elles veulent passer du prototype à l’usage métier.

Le build accéléré par l’IA change aussi la dette applicative

En plus de transformer les processus, l’IA agentique modifie également la manière de produire des composants logiciels. Génération de code, documentation assistée, migration de scripts, création d’interfaces, recomposition de briques applicatives… certaines entreprises peuvent désormais envisager de reprendre en interne des pans d’applications auparavant externalisés ou consommés en SaaS.

Un mouvement qui peut être tout à fait vertueux, puisqu’il permet de réduire certaines dépendances, d’adapter plus finement les outils aux métiers et de redonner de la maîtrise à la DSI.

Mais il crée aussi un nouveau risque : confondre vitesse de construction et capacité à maintenir.

Audrey Rousset-Bat, Directrice d’Amoddex, société de conseil en transformation des SI et stratégie data, présent à Toulouse, Pau et Paris, analyse ce mouvement de réappropriation applicative sous l’angle de la transformation organisationnelle, de la gouvernance et de la maîtrise des données : « La réappropriation de certaines applications SaaS par du développement interne accéléré par l’IA ne doit pas être réduite à une question de coûts ou de souveraineté technologique. C’est d’abord une transformation organisationnelle : quelles compétences internaliser, quelles responsabilités clarifier, quels processus industrialiser, quels modèles de run mettre en place, et avec quelle gouvernance de la donnée ? L’IA permet d’aller plus vite dans le build, mais elle impose encore plus de rigueur sur les fondations : cartographie des données, fiabilité des indicateurs, responsabilités clairement définies, supervision des flux, observabilité des usages et capacité à maintenir dans la durée. Chez Amoddex, nous accompagnons ces trajectoires au croisement du Make or Buy, de la transformation des organisations et de notre offre Data 360°. Nous sommes convaincus que cette démarche ne se limite pas à refaire en interne ce que le SaaS faisait hier, mais de reprendre le contrôle de ce qui crée réellement de la valeur, avec une donnée fiable, lisible, gouvernée et exploitable. C’est à cette condition que l’IA devient un accélérateur maîtrisé, et non un nouveau facteur de complexité et de risques cyber sur la durée. »

Un point central, plus le build s’accélère, plus le run doit être solide. Une application recomposée avec l’aide de l’IA doit être documentée, testée, supervisée, sécurisée, maintenue et intégrée dans les cycles de vie du SI. À défaut, l’entreprise change seulement la forme de sa dette applicative...

Du run technique à la gouvernance opérationnelle

Bien sûr, encore faut-il décider ce que l’organisation fait de cette visibilité. Qui autorise la mise en production ? Quelles données l’agent peut-il consulter ? Quelles opérations exigent une validation humaine ? À quelle fréquence les performances, les coûts et les dérives sont-ils revus ? Les questions sont multiples…

Aussi la gouvernance des agents doit être menée de façon très pragmatique, avec inventaire des agents, propriétaire métier, responsable technique, classification par criticité, droits d’accès, journalisation, tests réguliers, procédures d’escalade, mécanisme d’arrêt ou encore revues de performance. De nombreux spécialistes insistent d’ailleurs sur la nécessité d’un socle combinant gouvernance, sécurité, supervision, droits de décision, suivi du cycle de vie et gestion proactive des risques à mesure que l’autonomie des agents augmente.

La gouvernance opérationnelle commence donc là où le (simple) projet IA s’arrête, à savoir dans la durée, les exceptions, les incidents et les décisions à documenter.

Une gouvernance transverse des agents IA

Les agents IA ne relèvent ni seulement de la DSI, ni seulement des métiers, ni seulement du RSSI, ils agissent dans les processus, manipulent des données, s’appuient sur des applications et peuvent produire des effets opérationnels. Leur gouvernance doit donc associer ceux qui portent la valeur métier, ceux qui maîtrisent l’architecture, ceux qui sécurisent les accès et ceux qui garantissent la conformité.

Il faut expérimenter vite, puis industrialiser seulement ce qui peut être observé, sécurisé et maintenu. Car tant qu’un agent conseille, le risque reste contenu. Mais lorsqu’il agit, il entre dans le régime du SI opérationnel, et doit alors être suivi comme un composant, gouverné comme un processus et arrêté si son comportement sort du cadre prévu. C’est seulement à ce prix que l’autonomie promise par les agents peut devenir une capacité maîtrisée.

Contenu proposé par Cloudlist, le carrefour de l’information sur le secteur IT