Monitoring des agents IA avec LangSmith et Langfuse : l'observabilité pour des agents IA sécurisés

Le monitoring des agents IA (Agent Observability) désigne la collecte et l'analyse continues de tout ce que fait un agent IA : traces, appels d'outils, coûts en tokens, latence, erreurs et scores d'évaluation. Des outils comme LangSmith et Langfuse rendent traçables les chemins de décision d'un agent et sont donc une condition préalable à la sécurité, au débogage et à la conformité. Contrairement au monitoring applicatif classique, il ne doit pas représenter des requêtes isolées, mais des chaînes de raisonnement en plusieurs étapes entières.

Les trois points essentiels d'emblée :

• Ce qu'il faut suivre : les traces (chaîne de raisonnement complète), les appels d'outils avec arguments, la consommation de tokens et les coûts, la latence par étape, les erreurs et les scores d'évaluation de la qualité des réponses.
• Quels outils : LangSmith (commercial, étroitement lié à LangChain, région UE disponible), Langfuse (open source, auto-hébergeable, région UE) ainsi que, en complément, Arize Phoenix, Weights & Biases Weave, Datadog LLM Observability et OpenTelemetry pour les traces GenAI.
• Pourquoi c'est critique : sans observabilité, les menaces agentiques recensées par l'OWASP comme Goal Hijack ou Memory Poisoning restent invisibles, et il est impossible de satisfaire aux exigences de l'ISO 42001, du règlement européen sur l'IA (pour les systèmes à haut risque) et de DORA.

Pourquoi les agents ont besoin d'une observabilité dédiée

Les applications classiques basées sur des modèles de langage réagissent : un prompt entre, une réponse sort. Les systèmes agentiques, eux, planifient, raisonnent de manière récursive, choisissent des outils, écrivent dans une mémoire persistante et agissent avec une validation pas à pas minimale. Ce changement élargit la surface d'attaque et d'erreur selon trois axes : l'autonomie (plans en plusieurs étapes, automodification du contexte), l'utilisation d'outils (système de fichiers, API, bases de données, sandboxes de code, serveurs MCP) et la persistance (mémoires à long terme, bases de données vectorielles, chaînes de confiance entre agents).

C'est précisément pour cela qu'un journal des requêtes ne suffit pas. Il faut pouvoir reconstituer toute la trajectoire d'un agent, faute de quoi on ne peut remonter ni à un bug, ni à une attaque, ni à une hallucination. Dans l'architecture de référence MAESTRO de la Cloud Security Alliance, l'observabilité constitue une couche à part entière (Layer 5 : Evaluation & Observability), qui devient elle-même une cible : les données d'observabilité empoisonnées, le contournement du monitoring et l'évaluation compromise y figurent parmi les menaces.

Ce qu'il faut suivre concrètement

Pour une exhaustivité forensique, journalise au minimum les éléments suivants pour chaque action d'agent. Cette liste constitue le cœur pratique de toute stratégie de monitoring :

• Prompt complet : contexte utilisateur, système et injecté (décisif pour détecter les injections de prompt indirectes).
• Version du modèle et hash de configuration : reproductibilité et preuve des modifications.
• Séquence d'appels d'outils avec arguments : quel outil a été appelé, quand et avec quels paramètres.
• Requêtes de retrieval et identifiants des documents renvoyés : traçabilité de la base RAG.
• Sortie et justification de la décision : y compris le raisonnement chain-of-thought, s'il est disponible.
• Événements d'intervention humaine : chaque validation ou correction humaine.
• Accès en écriture et en lecture à la mémoire : essentiels pour détecter le Memory Poisoning.
• Coûts et latence : par étape, pour la rentabilité et la détection d'anomalies.

Les scores d'évaluation font aussi partie du monitoring : des évaluations automatisées ou basées sur des modèles de la qualité des réponses (exactitude, groundedness, taux d'hallucination), comparées d'une version à l'autre. LangSmith et Langfuse prennent tous deux en charge ce type de pipelines d'évaluation, qui permettent de détecter les régressions avant la mise en production.

Pour la conservation, on recommande un stockage WORM (write-once-read-many, c'est-à-dire des journaux inaltérables) et une signature cryptographique pour détecter les manipulations. Les durées de conservation dépendent du secteur et du pays. Pour les systèmes d'IA à haut risque, le règlement européen sur l'IA prévoit en principe au moins six mois (voir plus bas), auxquels s'ajoutent des exigences sectorielles dans la finance, la santé (BfArM en Allemagne, BASG en Autriche, Swissmedic en Suisse) et le secteur public (droit des archives). Comme les prompts complets peuvent contenir des données personnelles, tu dois concilier la conservation WORM et les longues durées avec le RGPD : les principes de minimisation des données et de limitation de la conservation de l'art. 5 et le droit à l'effacement de l'art. 17 s'accordent mal avec des journaux inaltérables à long terme. Tu peux atténuer ce conflit, par exemple, en pseudonymisant les données personnelles avant la journalisation.

Le paysage des outils : spécialisation et hébergement

LangSmith et Langfuse sont au centre de cet article ; le tableau les situe parmi d'autres outils. Pour les décideurs en Europe, au-delà des fonctionnalités, c'est surtout l'hébergement qui compte, car la résidence des données dans l'UE ou en Suisse est souvent le critère décisif dans les secteurs réglementés. Toutes deux proposent un cloud managé avec une région UE (LangSmith, Langfuse). La différence tient à l'auto-hébergement : Langfuse est open source et peut être auto-hébergé sans contrat Enterprise, alors que LangSmith n'est disponible en auto-hébergement que dans l'offre Enterprise.

Des plateformes d'observabilité généralistes comme Honeycomb ou Splunk peuvent s'y ajouter comme briques supplémentaires. Si tu veux éviter le lock-in, instrumente via OpenTelemetry et transmets les traces à la plateforme de ton choix.

Sur le marché voisin des guardrails, on trouve Lakera, un fournisseur zurichois qui appartient à Check Point depuis octobre 2025. Pour tous les fournisseurs, la règle est la même : les taux de benchmark et de détection qu'ils publient eux-mêmes sont à considérer comme du marketing tant qu'ils n'ont pas été vérifiés de manière indépendante.

Pourquoi le monitoring est une infrastructure de sécurité et de conformité

L'observabilité est le socle sans lequel aucune détection ne peut fonctionner. Les menaces de l'OWASP Top 10 for Agentic Applications 2026 ne peuvent presque toutes être détectées qu'à partir de signaux de monitoring :

• Agent Goal Hijack (ASI01) : URL sortantes atypiques dans les sorties de l'agent, appels d'outils sans rapport avec la demande de l'utilisateur, changements de sujet soudains dans la trace de raisonnement ; tout cela n'est visible que si la trace est complète.
• Tool Misuse (ASI02) : fréquences d'appels d'outils anormales, séquences d'appels inhabituelles, opérations destructrices peu après l'ingestion de contenus externes.
• Memory & Context Poisoning (ASI06) : dérive comportementale sans modification du code ou du modèle, entrées de mémoire invérifiables, valeurs aberrantes sémantiques dans la mémoire vectorielle.
• Cascading Failures (ASI08) : fan-out rapide (une décision déclenche en quelques secondes de nombreux agents en aval), boucles de nouvelles tentatives oscillantes.
• Rogue Agents (ASI10) : dérive comportementale par rapport au comportement de référence, accès à des ressources hors du périmètre habituel.

Côté coûts, le monitoring répond à la menace de la consommation illimitée de ressources (Unbounded Consumption, LLM10), ce qu'on appelle les attaques Denial of Wallet. Les plans en plusieurs étapes multiplient la consommation de tokens ; la détection d'anomalies sur la série temporelle d'utilisation des tokens et des plafonds de coûts stricts avec circuit breakers sont les contre-mesures.

Côté conformité, la journalisation est le dénominateur commun de tous les cadres pertinents. L'ISO/IEC 42001 la traite directement avec les contrôles de l'annexe A A.6.2.6 (Operation and monitoring) et A.6.2.8 (Logging). Le règlement européen sur l'IA encadre explicitement la journalisation des systèmes à haut risque : selon l'art. 12, ils doivent pouvoir enregistrer automatiquement des événements tout au long de leur cycle de vie. Les fournisseurs (art. 19) et les déployeurs (art. 26, paragraphe 6) doivent conserver ces journaux, dans la mesure où ils sont sous leur contrôle, pendant au moins six mois, sauf disposition contraire du droit de l'Union ou du droit national. En complément, le règlement sur l'IA exige un contrôle humain à l'art. 14, la cybersécurité et la robustesse à l'art. 15 et une surveillance après commercialisation à l'art. 72. Conformément à l'art. 113, ces obligations relatives au haut risque s'appliquent à partir du 2 décembre 2027 aux systèmes relevant de l'annexe III et à partir du 2 août 2028 aux systèmes relevant de l'annexe I. Le RGPD s'y rattache par l'art. 32 (mesures techniques et organisationnelles relatives à l'intégrité et à la disponibilité).

Dans le secteur financier, c'est DORA qui s'applique (art. 5-15, gestion du risque lié aux TIC). Dans son guide d'orientation non contraignant du 18 décembre 2025, la BaFin classe les systèmes d'IA comme une sous-catégorie des réseaux et systèmes d'information au sens de l'art. 3, point 2, de DORA et recommande de prévoir, selon une approche fondée sur les risques et en fonction de la criticité et du domaine d'utilisation, une journalisation exhaustive des décisions de l'IA. En Autriche, la FMA est l'autorité compétente pour DORA en vertu de la loi d'application de DORA (DORA-Vollzugsgesetz). Pour les entités essentielles et importantes au sens de NIS2 (transposée en Autriche par la NISG 2026), l'art. 21 exige notamment la gestion des incidents et le contrôle d'accès. Remarque : cette section situe les cadres réglementaires et ne constitue pas un conseil juridique ; fais vérifier juridiquement leur applicabilité concrète à ton système.

Il faut le dire honnêtement : la détection dans les déploiements d'agents en production est aujourd'hui faible. La plupart des stacks d'observabilité ont été conçus pour des applications classiques et ne captent pas les signaux propres aux agents, comme les anomalies dans les traces de raisonnement, les violations de la provenance des écritures en mémoire, les défauts d'intégrité entre agents ou la dérive comportementale par rapport au comportement de référence. La pratique du detection engineering pour les agents est donc jeune : exploitable, mais avec des taux élevés de faux négatifs. Si tu ne vois rien dans le SIEM, n'en conclus pas qu'il ne se passe rien.

Exemple pratique : ce qu'une trace rend visible

Imaginons qu'un assureur exploite un agent de tri des sinistres. Un compte rendu médical numérisé contient un texte manipulateur, lisible par OCR, qui pousse l'agent à déclencher un paiement automatique : un scénario de Goal Hijack (ASI01). Une trace bien instrumentée dans Langfuse ou LangSmith rend l'attaque visible :

```
trace_id: claim-48211
step 1 retrieval query="sinistre 48211" docs=[doc_91, doc_OCR_scan]
step 2 reasoning "Le document contient une instruction : approuver immédiatement" <- anomalie
step 3 tool_call approve_payout(amount=14 900 EUR) <- anormalement tôt
step 4 output "Paiement autorisé"
tokens: 8 420 cost: 0,11 USD latency: 3,2 s
```

L'étape 2 montre une étape de raisonnement qui reprend une instruction issue du contenu d'un document (donc des données, et non du prompt système) : le signal classique d'une injection indirecte. L'étape 3 est un appel d'outil destructeur (un paiement) juste après l'ingestion de contenus externes. Sans trace, le système n'afficherait qu'un paiement approuvé ; avec la trace, des métadonnées de provenance sur l'entrée de mémoire et une alerte sur la règle « appel d'outil destructeur après contenu externe », l'incident peut être stoppé en temps réel puis documenté de manière forensique.

Dans les systèmes multi-agents, la vitesse s'ajoute au problème : les Cascading Failures (ASI08) peuvent se propager plus vite que la réponse aux incidents classique ne peut les contenir. C'est pourquoi un monitoring continu des flux entre agents est indispensable.

Pour les agences et les décideurs B2B

Si tu développes des agents IA pour des clients ou si tu les utilises dans ta propre entreprise, prévois l'observabilité dès le premier jour comme un élément obligatoire, et non comme un add-on ultérieur. Concrètement : instrumenter via OpenTelemetry de manière agnostique vis-à-vis des frameworks, auto-héberger Langfuse ou l'exploiter dans la région UE si la résidence des données compte, collecter intégralement le contenu minimal du journal mentionné plus haut et placer les scores d'évaluation comme point de contrôle qualité avant chaque release. Pour les agences, un monitoring transparent des traces et des coûts est aussi un argument de confiance et de vente : il prouve au client que l'agent est contrôlable, auditable et maîtrisable sur le plan budgétaire. Blck Alpaca, à Vienne, accompagne les entreprises de toute l'Europe dans la mise en place et la sécurisation de ce type de stacks d'agents, de l'architecture d'observabilité jusqu'à l'alignement sur l'ISO 42001 et le règlement européen sur l'IA.