Votre agent IA boucle-t-il en production ? Personne ne le voit

Un agent IA lâché en boucle autonome peut brûler des milliers d'euros de calcul sans jamais avancer d'un pas vers son objectif. Ce n'est pas un scénario rare : dans la communauté qui construit ces agents, le phénomène a déjà un nom, « loopmaxxing ». L'agent ne plante pas. Il ne renvoie pas d'erreur. Il a l'air de travailler — il appelle des outils, il raisonne, il relance une recherche, il réécrit un fichier, il recommence. Et il tourne en rond.

Personne ne le voit, parce que rien ne crie. Un programme classique qui échoue lève une exception, remplit un log rouge, réveille quelqu'un. Un agent qui échoue en boucle ne lève rien du tout : il continue, poliment, à consommer des jetons.

Un logiciel plante. Un agent dérive.

C'est la différence qu'il faut intérioriser avant de déployer le moindre agent en production. Un logiciel classique a un espace d'états fini et des chemins d'erreur qu'on connaît d'avance : il plante, on le répare, le correctif est local. Un agent IA, lui, ne suit pas un chemin figé — il décide, à chaque tour, quel outil appeler et quand s'arrêter. Il n'y a pas de ligne de code qui « plante » quand cette décision devient mauvaise. Il y a une dérive, progressive, silencieuse, qui ne déclenche par construction aucune alarme.

Et une dérive n'a de sens que pour qui observe dans la durée. Un agent qui boucle pendant dix minutes un mardi n'est un problème que si quelqu'un compare ce mardi à la semaine précédente. Sans point de référence, il n'y a pas d'anomalie — il n'y a que du bruit.

C'est là qu'intervient une image qui vaut mieux qu'un long discours : l'enregistreur de vol. Une boîte noire n'empêche pas un crash. Elle ne pilote rien, elle n'intervient jamais sur les commandes. Son seul rôle est de rendre l'incident explicable après coup — et c'est précisément parce qu'on peut l'expliquer qu'on finit par éviter le suivant. Un agent IA en production sans trace, c'est un vol sans boîte noire : s'il dérape, personne ne saura jamais pourquoi, et la même dérive se reproduira, identique, la semaine suivante.

Observer n'est pas piloter

Il y a une tentation naturelle, une fois qu'on a compris le problème : ajouter un garde-fou qui coupe l'agent dès qu'il sort des clous. C'est une erreur de conception, et elle mérite d'être expliquée plutôt que balayée.

Un dispositif qui s'interpose entre l'agent et ses actions — qui filtre, qui bloque, qui réécrit à la volée — devient lui-même un point de panne. Il ajoute de la latence, il peut bloquer une action légitime sur un faux positif, et surtout : il change le comportement de l'agent que vous avez choisi. Un agent bridé par un filtre en amont n'est plus l'agent évalué, ni l'agent facturé, ni l'agent dont l'éditeur répond des performances. C'est un troisième système, hybride, dont personne n'a vraiment mesuré le comportement.

La posture juste est différente : observer sans intercepter. La veille écoute ce que l'agent fait — elle lit ses traces, elle les score, elle alerte — mais elle n'injecte rien dans son fonctionnement et ne bloque aucune de ses actions. C'est exactement la différence entre l'enregistreur de vol et le pilote automatique. L'un explique, l'autre agit. Confondre les deux, c'est soit accepter un système qui bride sans le dire, soit renoncer à observer par peur de brider. Aucune des deux options n'est tenable pour un agent qu'on met vraiment au travail.

Ce qu'il faut pouvoir constater — et que presque personne ne mesure

Voici les questions concrètes à se poser sur un agent en production, indépendamment de l'éditeur ou du framework utilisé.

Est-ce qu'il boucle ? Le signal n'est pas une erreur, c'est une répétition : les mêmes appels d'outils reviennent, dans le même ordre, sans que l'état du problème n'ait progressé entre deux tours. Un agent sain converge — le nombre d'étapes diminue à mesure qu'il approche du but. Un agent qui boucle stagne, ou pire, oscille entre deux ou trois séquences sans jamais en sortir.

Est-ce qu'il dérive dans le temps ? Un agent connecté à un modèle qu'un éditeur met à jour, à des outils dont les API changent, à des données qui évoluent, ne se comporte pas identiquement en janvier et en juillet. Sa latence moyenne, son taux d'erreur d'outil, la longueur de ses chaînes de raisonnement sont des signaux qui doivent être suivis semaine après semaine — pas mesurés une fois au moment de l'achat, puis oubliés.

Quels outils appelle-t-il vraiment ? C'est souvent la première surprise d'un développeur qui instrumente son agent pour la première fois : la liste réelle des appels diverge de ce qu'il croyait avoir configuré. Un outil rarement utile est invoqué à chaque tour ; un outil qu'on pensait central ne sert presque jamais.

Où partent les données qu'il manipule ? Chaque appel d'API depuis un agent est, du point de vue RGPD, un transfert potentiel. Un agent qui résume un document interne et l'envoie à un service tiers pour une recherche complémentaire fait sortir de la donnée — souvent sans que personne ne l'ait explicitement décidé au moment du design.

Peut-on reconstituer une décision, trois mois après ? C'est le test qui sépare un système documenté d'un système qui ne l'est pas. L'AI Act, à son article 12, impose une journalisation suffisante pour permettre la traçabilité du fonctionnement d'un système tout au long de son cycle de vie. « Suffisante » veut dire : on doit pouvoir répondre, a posteriori, à la question « pourquoi cet agent a-t-il fait ça ».

A-t-on la trace de ce qu'on a vérifié, et quand ? C'est la face la moins visible de l'obligation de moyens. Documenter la conformité, ce n'est pas seulement documenter le système — c'est documenter sa propre diligence : la preuve qu'on a regardé, à une date donnée, et qu'on continue de regarder.

Une matière qui existe déjà, et que presque personne n'exploite pour la conformité

Le point le plus contre-intuitif de ce sujet, c'est que l'instrumentation nécessaire n'est pas à inventer : elle existe déjà, sous forme de standard. Les frameworks d'agents modernes émettent des traces OpenTelemetry — le standard ouvert porté par la CNCF, déjà omniprésent dans le monde du monitoring applicatif. Une exécution d'agent se découpe en spans : un span « invoque l'agent », des spans enfants « appelle le modèle », « exécute un outil », chacun avec sa durée, ses paramètres, son statut.

Cette matière est déjà collectée, dans l'immense majorité des cas, à des fins de performance : trouver le goulot d'étranglement, réduire la latence, comparer deux versions d'un prompt. Elle est presque jamais relue à des fins de conformité — pour prouver, justement, ce que l'agent a fait, à qui, et pourquoi. C'est le même flux de données, détourné vers un usage différent : la preuve plutôt que l'optimisation. La donnée technique et la donnée de conformité sont, il se trouve, la même donnée.

Ce qu'EuTrustedIA apporte sur cette brique

POSITRONIA-Observe s'héberge chez vous — self-host, en Europe — et observe vos agents en production, en continu. Il reçoit les traces OpenTelemetry déjà émises par vos agents, les score selon les axes décrits plus haut — boucle, dérive temporelle, usage réel des outils, flux de données — et scelle localement les rapports produits. C'est un enregistreur de vol, pas un pilote automatique : Observe-only, la veille écoute, elle n'intercepte jamais. Vos traces restent chez vous ; seuls les rapports finaux, scellés, remontent vers votre espace client.

L'intégration à l'application desktop POSITRONIA en un clic est encore à venir — aujourd'hui, la connexion à vos traces OpenTelemetry se fait par le déploiement self-host. Nous préférons le dire tel quel plutôt que de promettre une simplicité qu'on n'a pas encore livrée.

Cette brique complète la première question de gouvernance que nous détaillons dans notre grille de déploiement des agents autonomes : l'axe « observabilité dans la durée » y était identifié comme le maillon que presque personne n'outille. C'est très précisément ce que cette brique traite. Et comme nous l'écrivions dans notre article sur la chaîne de souveraineté IA, un agent autonome active à lui seul tous les maillons du système — l'observer en continu n'est pas un luxe, c'est la seule façon de savoir ce qui s'est réellement passé.

Par où commencer

Vous n'avez pas besoin d'attendre un outil pour commencer. La première étape est gratuite et prend une heure : ouvrez la documentation du framework qui fait tourner vos agents (LangChain, LlamaIndex, un SDK propriétaire, un orchestrateur maison) et vérifiez s'il émet déjà des traces OpenTelemetry. Dans la majorité des cas récents, la réponse est oui — et elles dorment, non exploitées, dans un exporteur jamais branché.

Une fois les traces disponibles, posez-vous les six questions listées plus haut sur une semaine d'activité réelle. Vous découvrirez probablement au moins une des deux surprises classiques : un outil qui revient bien plus souvent que prévu, ou une séquence qui se répète sans jamais converger. C'est déjà, à ce stade, une observation utile — avant même de parler d'outillage.

Si vous voulez aller plus loin sans exposer votre code, POSITRONIA-Observe reçoit ces traces, les score et scelle les rapports, en local, chez vous.