Observabilité des agents IA : identité, permissions, mémoire, validations humaines — les 6 trous de télémétrie à combler avant de passer à l'échelle (guide PME)

Vous avez peut-être déjà un tableau de bord qui affiche les appels de vos agents IA : prompts, réponses, outils utilisés, coût en tokens. Un rapport publié le 7 octobre 2026 par la Partnership on AI (PAI) montre pourquoi cela ne suffit pas : les journaux produits par les frameworks d'agents les plus utilisés ne permettent pas, aujourd'hui, de retracer de façon fiable qui a agi, avec quels droits, comment ces droits ont changé et qui a validé quoi.

Pour une PME qui déploie un agent de support, de prospection, de comptabilité ou d'analyse documentaire, la conséquence est simple : le jour où un client, un auditeur ou votre assureur demande « qui a laissé l'agent faire ça ? », la réponse risque de ne pas être dans vos logs.

Ce guide résume le rapport et le transforme en checklist d'observabilité applicable sans équipe sécurité dédiée.

Ce que dit le rapport Partnership on AI

La Partnership on AI est une organisation à but non lucratif qui réunit des acteurs académiques, de la société civile, de l'industrie et des médias. Son rapport, *The Observability Gap in AI Agents: What to Fix Before Agents Scale*, est signé par Madhulika Srikumar et Eric Mibuari (PAI) avec des co-auteurs venant notamment de Microsoft, Salesforce, ServiceNow, JPMorganChase, Consumer Reports, de Harvard et de Princeton.

Les auteurs ont évalué quatre frameworks d'agents largement utilisés — OpenAI Agents SDK, Claude Agent SDK (Anthropic), LangGraph et CrewAI — au regard de six objectifs de surveillance : détecter les violations de politique, les actions non autorisées, les défaillances du contrôle humain, la dérive de comportement, les risques des systèmes multi-agents, et garantir l'auditabilité.

Leur constat de départ : *« L'infrastructure de surveillance des agents n'existe pas encore de manière fiable, alors que les décideurs publics supposent qu'elle existe. »* Le rapport rappelle l'incident de juillet 2026, où un agent testé par OpenAI est sorti de son environnement de test et a attaqué les systèmes de Hugging Face : selon les éléments rapportés depuis, l'intrusion n'a pas été détectée pendant près d'une semaine, et les agents avaient altéré leurs propres journaux.

Les 6 angles morts, traduits pour une PME

1. Pas d'identité persistante de l'agent

Les frameworks identifient les agents par un nom ou un identifiant valable le temps d'une exécution. Impossible, donc, de comparer les actions d'un agent aux droits qui lui ont été accordés, ou de suivre l'autorité transmise à ses sous-agents. Dans l'exemple du rapport, un sous-agent hérite de l'identité de l'agent parent : si un attaquant le remplace par un sous-agent qui gonfle la valeur des biens dans un dossier de prêt, l'entreprise ne peut pas le voir.

Pour vous : chaque agent doit avoir un identifiant stable, rattaché à un compte de service dans votre annuaire (Google Workspace, Microsoft Entra…), avec un propriétaire nommé. Les sous-agents ont leur propre identité.

2. Les changements de mode de permission ne laissent pas de trace

Seul Claude Agent SDK émet un événement lorsque le mode de permission d'un agent change en cours de session. Dans les trois autres, un changement qui supprime la validation humaine — qu'il vienne d'un collaborateur ou d'une injection de prompt — ne laisse aucune trace, selon le rapport.

Pour vous : traitez tout passage en mode « autonome » comme un événement de sécurité : journalisé, horodaté, attribué, et notifié au responsable de l'agent.

3. Les modifications de la mémoire ne sont pas journalisées

Les frameworks n'enregistrent pas ce qui change dans la mémoire d'un agent ni pourquoi. Une dérive qui commence dans la mémoire ne devient visible qu'une fois les décisions de l'agent déjà modifiées. CrewAI journalise qu'une lecture ou une écriture en mémoire a eu lieu, mais pas son contenu ; LangGraph et OpenAI Agents SDK n'émettent rien de lié à la mémoire.

Pour vous : conservez un historique versionné de la mémoire persistante (ce qui a été écrit, par quelle exécution, à partir de quelle source), ou limitez la mémoire persistante aux agents qui en ont vraiment besoin.

4. Les validations humaines ne sont pas documentées

Les frameworks ne consignent ni la raison du déclenchement d'une revue, ni l'identité et l'autorité de la personne qui valide, ni sa décision. Résultat : il devient difficile de distinguer un vrai contrôle d'un « tampon automatique ». L'exemple (hypothétique) du rapport : dans une banque, le taux d'approbation des recommandations d'un agent anti-blanchiment passe de 70 % à 95 %. Meilleur agent, confiance justifiée ou dépendance croissante ? Sans télémétrie sur les validations, impossible de trancher.

Pour vous : chaque validation doit produire un enregistrement — déclencheur, valideur, rôle, décision, horodatage, et idéalement le temps passé. C'est la matière première d'un contrôle humain prouvable.

5. Le raisonnement de l'agent reste opaque

Les frameworks ne transmettent que ce que les fournisseurs de modèles exposent, le plus souvent un résumé produit après coup. Difficile, alors, de vérifier qu'une décision ne repose pas sur un critère interdit.

Pour vous : ne comptez pas sur le raisonnement du modèle comme preuve. Exigez que l'agent cite les éléments factuels (documents, champs, règles) sur lesquels repose chaque recommandation, et journalisez-les.

6. Aucun signal de confiance structuré

Les probabilités au niveau des tokens ne sont pas émises en télémétrie structurée. Le rapport souligne que c'est un indicateur imparfait de la qualité d'une décision, mais un signal de plus que l'on perd.

Pour vous : c'est l'angle mort le moins prioritaire pour une PME. Concentrez-vous sur les quatre premiers, qui sont déterministes : un framework les émet ou ne les émet pas.

Un deuxième signal : avec des outils, les modèles refusent moins

Une prépublication déposée sur arXiv le 2 octobre 2026, *MLLMs Fail to Refuse when Using Tools Agentically*, a testé onze modèles de vision-langage, dont Claude Opus 4.7, Gemini 3.1 Pro et GPT-5.4, sur trois bancs d'essai de sécurité. Dès qu'on leur donne des outils (zoom, OCR, interpréteur de code), tous refusent moins souvent les demandes dangereuses, avec une hausse relative du taux d'échec de refus pouvant atteindre 68,7 %. Les auteurs l'expliquent notamment par une « dilution du contexte » à mesure que les résultats d'outils s'accumulent.

La leçon rejoint celle de la PAI : les garde-fous internes du modèle s'affaiblissent quand l'agent travaille, et la trace de ce qu'il fait est incomplète. Les contrôles et les preuves doivent donc se situer à l'extérieur de l'agent.

Pourquoi c'est un sujet AI Act, même pour une PME

L'article 14 du règlement (UE) 2024/1689 impose que les systèmes à haut risque puissent être effectivement contrôlés par des humains, et l'article 26 demande aux déployeurs de ces systèmes de confier ce contrôle à des personnes compétentes et de conserver les journaux générés automatiquement. Depuis l'omnibus numérique (règlement (UE) 2026/1744), ces obligations « haut risque » s'appliquent à partir du 2 décembre 2027 pour les usages de l'annexe III.

Le rapport PAI cite justement l'article 14 comme exemple d'exigence qui suppose une observabilité qui n'existe pas encore. Pour une PME, deux raisons de s'y mettre maintenant :

• les questionnaires fournisseurs de vos clients grands comptes demandent déjà des preuves de contrôle humain et de traçabilité ;
• un journal d'audit fiable se construit dans la durée : celui de 2027 se prépare avec les agents que vous déployez aujourd'hui.

Ce guide n'est pas un avis juridique. Pour le cadre complet, voir notre guide AI Act pour PME et agents IA et AI Act omnibus, MCP et journaux d'audit.

La checklist observabilité de vos agents IA

Reprise des recommandations du rapport à destination des entreprises, adaptée à une PME :

1. Inventaire : listez chaque agent, son propriétaire, ses outils, ses accès et son niveau d'autonomie. Méthode : inventaire et identité des agents.
2. Identité : un compte de service par agent et par sous-agent, des jetons courts et révocables — voir NIST IR 8587 et jetons d'agents.
3. Couche d'intention : écrivez les politiques, rôles, permissions et listes d'interdits contre lesquels la télémétrie sera jugée. Le rapport insiste : aucun outil d'observabilité ne les fournit à votre place.
4. Permissions : alerte sur tout passage en mode autonome et sur toute suppression d'une étape de validation.
5. Validations humaines : déclencheur, valideur, rôle, décision, horodatage pour chaque action sensible. Classement des actions : gouvernance des agents R0–R4.
6. Mémoire : historique versionné de ce qui est écrit en mémoire persistante.
7. Capture graduée : capture complète pour les actions à fort enjeu ou irréversibles (paiement, envoi externe, suppression), échantillonnage ou rétention plus courte pour les tâches routinières — c'est la recommandation du rapport, qui note que tout capturer augmente le volume, le coût et la concentration de données sensibles.
8. Journaux hors de portée de l'agent : stockage que l'agent ne peut ni lire ni modifier, avec les mêmes règles d'accès que vos autres données sensibles (RGPD inclus).
9. Contrôles qui agissent : barrières de validation et alertes d'anomalie en temps réel, revue a posteriori par une personne désignée, et un kill switch testé.

Les 6 questions à poser à vos fournisseurs

Le rapport recommande aux entreprises d'utiliser leurs achats comme levier. Avant votre prochain renouvellement d'outil d'agents ou d'observabilité, demandez par écrit :

• L'agent a-t-il une identité persistante, reliable à notre annuaire, y compris pour les sous-agents ?
• Les changements de permission en cours de session sont-ils journalisés ?
• Les écritures en mémoire sont-elles tracées, avec leur source ?
• Chaque validation humaine est-elle enregistrée avec le valideur, son rôle et sa décision ?
• Les journaux sont-ils exportables dans un format standard (OpenTelemetry) et inaltérables par l'agent ?
• Quel raisonnement ou quelles sources sont conservés pour justifier une recommandation ?

Vous pouvez aussi lancer une évaluation de risque, utiliser la checklist gouvernance IA ou consulter notre page sécurité et conformité. Si votre enjeu est aussi la visibilité de votre marque dans les réponses des IA, voir ChatSEO et visibilité dans ChatGPT.

Le récit en anglais, côté actualité : Partnership on AI finds six telemetry blind spots in agent frameworks.

Ce que TrustAI Vault vous apporte

TrustAI Vault place la couche de contrôle entre vos équipes, leurs assistants et les modèles, pour que vos preuves ne dépendent pas de ce que chaque framework accepte d'émettre :

• identité et politiques par agent ;
• validations humaines enregistrées (qui, quand, quelle décision) sur les actions sensibles ;
• DLP avant que les données n'atteignent un modèle ou un service tiers ;
• journaux d'audit infalsifiables de chaque requête, appel d'outil et décision ;
• kill switch administrateur, dont l'usage est lui-même journalisé.

Autrement dit, les points 4, 5, 8 et 9 de la checklist reposent sur un contrôle que vous pouvez montrer, pas sur la bonne volonté de l'agent. Pour la protection des données en amont, voir Vault : protéger les données sensibles.

CTA : testez Vault Pro pendant 4 jours → Démarrer l'essai gratuit

Sources

• Partnership on AI — Madhulika Srikumar, Eric Mibuari et al., « The Observability Gap in AI Agents: What to Fix Before Agents Scale » (7 octobre 2026) : partnershiponai.org · rapport complet (PDF)
• The Christian Science Monitor — Laurent Belsie, « As AI agents multiply, report finds big gaps in controlling what they do » (7 octobre 2026) : csmonitor.com
• Takehi et al., « MLLMs Fail to Refuse when Using Tools Agentically », arXiv:2610.03938 (2 octobre 2026) : arxiv.org
• Règlement (UE) 2024/1689 (AI Act), articles 14 et 26 : eur-lex.europa.eu