Pourquoi le monitoring d'infrastructure ne voit rien passer
Un agent IA peut tourner sur une infrastructure parfaitement saine et produire malgré tout une réponse fausse. Le CPU est normal, la mémoire stable, l'API disponible, le temps de réponse correct, et pourtant l'agent a choisi le mauvais outil ou inventé une réponse avec assurance. C'est le piège du monitoring classique : il vérifie l'état de la machine, pas le raisonnement suivi par l'agent.
Dans une application classique, le parcours d'une requête est globalement connu à l'avance : un contrôleur, une règle métier, une base de données, une réponse. Un agent IA construit au contraire son chemin pendant l'exécution. Il peut appeler un outil, reformuler sa question, relancer une recherche documentaire, changer de stratégie ou s'arrêter trop tôt. La documentation de Google Cloud sur l'observabilité des agents le formule directement : les agents IA peuvent dériver, halluciner et se dégrader silencieusement, et ils peuvent échouer de façons très différentes d'un logiciel classique non agentique.
Un exemple concret illustre le problème. Sur un workflow support, deux demandes clients presque identiques arrivent. La première se déroule normalement : l'agent récupère le dossier client, vérifie le contrat, propose la bonne réponse. La seconde déclenche le mauvais outil CRM, parce qu'un mot de la demande a été interprété comme une intention commerciale au lieu d'un problème technique. Techniquement, tous les indicateurs restaient au vert. Fonctionnellement, le résultat était faux. C'est exactement ce que la traçabilité totale doit rendre visible.
Ce que la traçabilité totale doit couvrir
Pour reconstruire le raisonnement réel d'un agent, il faut tracer le chemin complet depuis la requête utilisateur jusqu'à la réponse finale : le prompt d'entrée, le système de consignes, le modèle utilisé, les paramètres (température, nombre maximum de tokens), les appels au modèle, la latence, l'usage de tokens, les appels d'outils et leurs réponses, les documents récupérés, les erreurs, les tentatives de reprise et les décisions de routage. Google Cloud décrit une logique proche pour ses propres outils d'observabilité d'agents : suivre les interactions avec le modèle (prompts, réponses, usage de tokens, latence, taux d'erreur), l'usage des outils externes, le comportement et le raisonnement de l'agent, la performance de bout en bout, ainsi que la sécurité et la qualité des sorties produites.
| Élément à tracer | Pourquoi | Exemple |
|---|---|---|
| Appel au modèle | Comprendre le raisonnement demandé, le modèle utilisé, le coût et la latence | Modèle, température 0,2, 1 240 tokens |
| Outil externe | Vérifier ce que l'agent appelle et ce que l'outil répond | Appel CRM pour récupérer le statut client |
| Récupération documentaire (RAG) | Voir quelles sources influencent la réponse | Trois pages récupérées avec scores de similarité |
| Erreur | Identifier les pannes, timeouts et retry inutiles | Timeout API après 10 secondes, retry effectué |
| Sortie finale | Comparer la réponse produite avec le contexte disponible | Réponse envoyée avec sources citées |
Le piège des données personnelles dans les traces
Une trace n'est pas une poubelle où l'on déverse toute la donnée brute. Les données personnelles, les secrets d'API, les clés et les informations business sensibles doivent être masqués ou pseudonymisés avant d'être stockés ou envoyés vers une plateforme d'observabilité. Pseudonymiser consiste à remplacer une donnée identifiable par une valeur stable mais non directement exploitable, par exemple remplacer un email par un identifiant interne. C'est un point que les DSI français ne peuvent pas ignorer : un prompt utilisateur tracé intégralement peut contenir un nom, un numéro de contrat ou une adresse, autant de données à caractère personnel au sens du RGPD.
Sur ce terrain, certaines plateformes traitent le sujet en amont de l'appel au modèle plutôt qu'au moment du stockage de la trace. C'est le principe retenu par Moon Blur, le dispositif de Moon AI, qui remplace les données personnelles par des jetons avant l'envoi aux modèles tiers, puis les rétablit au retour. Le procédé étant réversible, il s'agit d'une pseudonymisation au sens de l'article 4-5 du RGPD, pas d'une anonymisation : la donnée reste, par construction, rattachable à la personne concernée via la table de correspondance.
Les métriques qui pilotent le coût et la fiabilité
Une trace raconte une exécution précise. Une métrique agrège une tendance : elle indique si la performance se dégrade, si le coût augmente, si l'agent échoue plus souvent, si les utilisateurs escaladent davantage vers un humain. Les deux ne se remplacent pas : la métrique dit où regarder, la trace explique pourquoi.
| Métrique | Signal | Action possible |
|---|---|---|
| Latence p95 | Les cas lents augmentent | Optimiser les outils, réduire le contexte, revoir les timeouts |
| Coût par exécution | Le budget dérive | Compresser les prompts, limiter les retries, changer de modèle si besoin |
| Taux d'échec | L'agent casse plus souvent | Lire les traces, isoler les erreurs par étape |
| Erreurs par outil | Un connecteur devient instable | Ajouter des fallbacks, corriger l'API, surveiller les quotas |
| Taux de réponses non conformes | La sortie ne respecte plus les règles | Renforcer les schémas, ajouter des validations |
| Taux d'escalade humaine | L'agent ne résout pas assez | Améliorer la base documentaire et les garde-fous |
Un signal fréquemment observé : le coût en tokens grimpe de 40 % sans amélioration du taux de résolution. Dans ce cas, il faut inspecter les prompts, les boucles d'appel d'outils et la récupération documentaire. Le problème vient souvent d'un contexte RAG trop large, avec des documents hors sujet qui polluent la réponse, plutôt que d'un défaut du modèle lui-même.
Quels outils pour construire cette observabilité
Le choix d'un outil dépend de la stack existante, du niveau de maturité et des contraintes de données.
| Outil | Intérêt principal | Limite typique |
|---|---|---|
| Langfuse | Observabilité LLM open source : traces, prompts, coûts, évaluations. Auto-hébergeable ou en cloud avec une région européenne dédiée. | Demande de la discipline sur l'instrumentation |
| LangSmith | Très fluide avec LangChain, debugging et tests intégrés | Moins naturel hors écosystème LangChain |
| Arize AI / Phoenix | Évaluation et monitoring de la qualité à grande échelle | Peut être trop avancé pour une première visibilité simple |
| Datadog LLM Observability | Relie l'observabilité LLM au monitoring applicatif existant | Moins pertinent hors écosystème Datadog |
| OpenTelemetry | Standard ouvert pour structurer traces, logs et métriques, repris par les conventions sémantiques GenAI de Google | Pas un produit clé en main, à connecter à un outil |
Langfuse, projet open source, propose un auto-hébergement via Docker, Kubernetes ou des modèles Terraform pour AWS, Azure et GCP, ainsi qu'une offre cloud avec une région européenne distincte de la région américaine. Pour un DSI français soucieux de savoir où transitent les traces, qui peuvent contenir des fragments de prompts utilisateur, ce choix d'hébergement compte autant que la richesse fonctionnelle de l'outil.
Arize, de son côté, revendique le traitement de mille milliards de spans et un milliard d'évaluations par an, et affiche sur son centre de confiance des certifications SOC2, PCI, ISO, RGPD et HIPAA. Ce sont des éléments communiqués par l'éditeur lui-même, à vérifier au cas par cas selon le contrat retenu. Google Cloud recommande par ailleurs de construire les agents avec son Agent Development Kit, qui repose sur OpenTelemetry et produit une télémétrie conforme aux conventions sémantiques GenAI, afin de déboguer les échecs, suivre les coûts et analyser le comportement des agents déployés sur sa plateforme.
La discipline de l'observabilité s'inscrit plus largement dans ce que la communauté technique appelle le harness engineering, la conception de l'environnement complet qui entoure un agent : interface d'outils, gestion du contexte, mémoire, permissions, observabilité. Un cas cité dans cette communauté illustre l'enjeu de bout en bout : l'agent SRE d'Azure aurait traité plus de 35 000 incidents en production, faisant passer le délai moyen de mitigation sur Azure App Service de 40,5 heures à 3 minutes, selon la documentation du projet qui décrit cette architecture. Ce chiffre, rapporté par une seule source, reste à considérer comme une donnée communiquée par l'éditeur concerné plutôt que comme un fait vérifié de façon indépendante.
Ce que cela implique pour la conformité en France
Les sources disponibles ne détaillent pas les obligations précises que l'AI Act européen impose aux systèmes à risque. Ce qu'elles montrent, en revanche, c'est que la logique même de l'observabilité, conserver une trace complète du prompt, du modèle, des outils appelés et de la décision prise, construit de fait la matière que toute démonstration de conformité ou tout audit viendrait chercher : qui a décidé quoi, avec quelles données, à quel moment.
Sur le volet RGPD, le sujet central identifié par les sources est celui des données personnelles présentes dans les prompts et les traces. Masquer ou pseudonymiser ces données avant stockage, ou avant envoi à un modèle tiers, réduit le risque, mais ne doit pas être confondu avec une anonymisation : une pseudonymisation reste réversible par construction, donc soumise au RGPD au même titre qu'une donnée identifiante. Un DSI qui déploie un agent IA en production doit donc traiter séparément deux questions : où sont hébergées les traces d'observabilité, et que deviennent les données personnelles au moment où elles quittent l'environnement interne pour atteindre un modèle tiers.
Questions fréquentes
Faut-il tracer toutes les exécutions d'un agent IA ou seulement celles qui échouent ?
Il faut tracer le chemin complet de chaque exécution, pas seulement les cas d'échec. Un agent peut produire une réponse techniquement valide, sans erreur ni timeout, et pourtant fonctionnellement fausse, comme dans le cas d'un mauvais outil CRM déclenché à tort. Sans trace complète, ce type d'erreur reste invisible.
Quelle est la différence entre une trace et une métrique ?
Une trace décrit une exécution précise : le prompt, les appels d'outils, les réponses intermédiaires, les erreurs, le chemin suivi. Une métrique agrège une tendance sur plusieurs exécutions : latence p95, coût par exécution, taux d'échec. Les métriques indiquent où regarder, les traces expliquent pourquoi le problème survient.
Vaut-il mieux choisir un outil open source auto-hébergé ou une plateforme cloud ?
Cela dépend de la stack, de la maturité de l'équipe et des contraintes de données. Un outil comme Langfuse peut être auto-hébergé en quelques minutes via Docker ou déployé en production via Kubernetes, ce qui laisse le choix de la localisation des données. Une plateforme comme Datadog ou Arize a du sens si l'organisation est déjà outillée dans cet écosystème.
La pseudonymisation des traces suffit-elle à garantir la conformité RGPD ?
Non. La pseudonymisation réduit le risque en remplaçant une donnée identifiable par un identifiant stable, mais elle reste réversible : la donnée d'origine peut être retrouvée via la table de correspondance. Elle ne constitue donc pas une anonymisation et ne suffit pas, à elle seule, à établir une conformité complète au RGPD.