Observabilité, audit et conformité

Bienvenue

Un serveur MCPMCPIAModel Context Protocol : protocole permettant de brancher des outils et sources externes (docs, tickets, bases) à un agent LLM via des serveurs dédiés.Voir dans le glossaire qui expose des outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire vers un LLMLLMIAGrand modèle de langage (Large Language Model) entraîné sur d'énormes corpus pour prédire et générer du texte.Voir dans le glossaire ouvre une porte entre un raisonnement statistique et votre système d'information. Tant que cette porte reste consultative, les enjeux de traçabilité restent modestes. Dès qu'un agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire peut écrire dans un CRM, déclencher un virement ou envoyer un e-mail, la question change de nature : il ne s'agit plus de savoir ce que le modèle a dit, mais ce qu'il a fait, pour le compte de qui, et sur quelle base.

Ce chapitre traite l'observabilité MCP comme une discipline d'audit à part entière, distincte du monitoring technique classique (latence, erreurs, disponibilité). L'objectif est de pouvoir répondre, six mois après les faits, à la question : « pourquoi cette action a-t-elle eu lieu ? »

Un serveur MCP en production sans journal d'invocation exploitable n'est pas un serveur incomplet : c'est un système sans preuve. En cas d'incident, l'absence de log ne protège personne — elle transforme une investigation de quelques minutes en reconstruction d'hypothèses.

Pourquoi tracer chaque invocation d'outil

Un pipeline MCP typique enchaîne plusieurs étapes opaques du point de vue de l'utilisateur final : une requête en langage naturel, un raisonnement du modèle, une ou plusieurs sélections d'outils, des appels effectifs au système d'information, puis une synthèse renvoyée à l'utilisateur. Chacune de ces étapes peut diverger de l'intention initiale.

Trois catégories de risques justifient une traçabilité fine :

• Le risque de dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire d'intention. Le modèle interprète mal une instruction ambiguë et invoque un outil destructeur (suppression, annulation, envoi) alors que l'utilisateur attendait une simple consultation.
• Le risque de périmètre. Un agent autorisé à agir sur un tenant ou un dossier accède, par erreur de contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire ou par injection de promptInjection de promptCybersécuritéAttaque visant à détourner un LLM en insérant des instructions malveillantes dans le contexte (entrée utilisateur, document RAG, etc.).Voir dans le glossaire, à des donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire hors de son périmètre légitime.
• Le risque de non-répudiation. Sans journal, il devient impossible de démontrer qu'une action a été initiée par un utilisateur donné plutôt que par un autre, ou par le système lui-même en mode automatisé.

Dans les trois cas, la réponse n'est pas seulement technique. Elle est aussi organisationnelle : qui a le droit d'interroger les journaux, sous quel délai, et pour quel usage.

Tracer une invocation d'outil MCP ne se limite pas à journaliser l'appel réseau. Il faut conserver le contexte qui a conduit à cet appel : le promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire utilisateur, le raisonnement intermédiaire si le modèle l'expose, les paramètres transmis à l'outil, et la réponse reçue en retour.

Le modèle de traçabilité MCP

Un journal d'audit MCP exploitable repose sur un petit nombre de champs structurés, présents sur chaque événement :

Le point le plus souvent négligé est le champ params_redacted. Journaliser les paramètres bruts d'un appel d'outil revient fréquemment à journaliser des données personnelles ou sensibles en clair — un numéro de sécurité sociale transmis à un outil de vérification d'identité, par exemple. La bonne pratique consiste à appliquer une politique de rédaction avant écriture du journal, et non a posteriori sur un journal déjà persistant.

Corrélation session LLM ↔ actions SI

La difficulté propre à MCP, par rapport à un audit applicatif classique, tient à la distance entre l'intention exprimée et l'action exécutée. Une seule session de conversation peut déclencher une dizaine d'invocations d'outils, réparties sur plusieurs systèmes cibles (CRM, ERP, messagerie, base documentaire), sans qu'aucun de ces systèmes ne « sache » qu'il fait partie d'une même chaîne de décision portée par un agent.

La corrélation repose sur la propagation systématique d'un identifiant de session à travers toute la chaîne d'appel, y compris lorsque le serveur MCP relaie l'action à une API tierce. Concrètement, cela signifie :

1. Générer un session_id unique à l'ouverture de la conversation, côté orchestrateur MCP.
2. Propager cet identifiant dans les en-têtes de chaque appel sortant vers le système d'information (par exemple un en-tête X-MCP-Session-Id).
3. Exiger que les systèmes cibles journalisent cet identifiant dans leurs propres logs applicatifs, au même titre qu'un trace_id de télémétrie distribuée.
4. Centraliser les journaux MCP et les journaux applicatifs des systèmes cibles dans un même référentiel d'investigation, ou à défaut garantir qu'ils sont joignables par cet identifiant commun.

Sans cette propagation, un auditeur qui constate une anomalie dans le CRM (un contact supprimé à 8h12) ne peut pas remonter jusqu'à la session de conversation qui en est à l'origine — il voit une action système, mais perd le fil de la décision qui l'a produite.

Un service support utilise un agent MCP pour clôturer automatiquement les tickets résolus depuis plus de sept jours sans réponse du client. Un client se plaint d'un ticket fermé à tort. La recherche par session_id dans le journal MCP montre que l'agent a bien évalué la règle des sept jours, mais que le paramètre de fuseau horaire transmis par l'outil de ticketing était erroné, décalant le calcul d'une journée. Sans corrélation session ↔ action, cette cause aurait été attribuée par défaut à « un bug du connecteur », sans preuve.

Rétention des logs et gestion des PII

Les journaux d'audit MCP contiennent, par construction, des fragments de conversations et des paramètres d'action qui peuvent inclure des données à caractère personnel : noms, adresses, contenus de messages, identifiants clients. Cela place la fonction de journalisation sous le régime du RGPDRGPDConformitéRèglement européen sur la protection des données personnelles. Il s'applique dès qu'un système d'IA traite de telles données, et se cumule avec l'AI Act.Voir dans le glossaire, au même titre que n'importe quel traitement de données personnelles.

Quatre principes structurent une politique de rétention défendable :

• Minimisation à la source. Ne pas journaliser ce qui n'est pas nécessaire à l'investigation. Un paramètre de type mot de passe ou jeton ne doit jamais apparaître, même de façon transitoire, dans un journal.
• Rédaction déterministe. Les champs identifiés comme sensibles sont masqués ou hachés par une règle appliquée uniformément, documentée, et testée — pas laissée à l'appréciation de chaque développeur d'outil.
• Durée de conservation proportionnée. Une durée courte (30 à 90 jours) pour les journaux détaillés permettant le débogage fin, et une durée plus longue mais moins granulaire (statistiques agrégées, indicateurs de risque) pour les besoins d'audit annuel.
• Séparation des accès. L'équipe qui exploite les journaux à des fins de support n'a pas nécessairement besoin d'accéder aux mêmes champs qu'un auditeur de conformité recherchant une preuve dans le cadre d'un contentieux.

Les journaux de conversation LLM sont souvent le point d'entrée oublié d'une fuite de donnéesfuite de donnéesIAErreur consistant à laisser entrer dans l'entraînement une information qui n'existera pas au moment réel de la prédiction. Le modèle affiche des scores excellents puis s'effondre en production.Voir dans le glossaire. Un prompt utilisateur peut contenir, en clair, des informations que l'outil invoqué n'aurait jamais reçues directement — un numéro de carte collé par erreur dans une question, par exemple. Une politique de rétention qui ne couvre que les paramètres d'outils, sans couvrir le contenu de session lui-même, laisse un angle mort.

Si le référentiel d'audit MCP est hébergé chez un tiers, le registre des traitements et l'analyse d'impactAIPDConformitéAnalyse d'impact relative à la protection des données, obligatoire dès qu'un traitement est susceptible d'engendrer un risque élevé — ce qui couvre la plupart des systèmes de profilage.Voir dans le glossaire doivent couvrir explicitement ce flux, au même titre que n'importe quel autre transfert de données personnelles.

Lien avec l'AI Act et l'ISO 42001

Deux cadres structurent aujourd'hui les obligations de traçabilité pour les systèmes d'IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire utilisés en entreprise, sans se substituer l'un à l'autre.

Le règlement européen sur l'intelligence artificielleAI ActConformitéRèglement européen sur l'intelligence artificielle, adopté en 2024. Il classe les systèmes en quatre niveaux de risque selon leur usage — jamais selon leur technologie.Voir dans le glossaire (AI Act) classe les systèmes selon un niveau de risque et impose, pour les systèmes à haut risquehaut risqueConformitéCatégorie de l'AI Act regroupant les usages soumis à conditions strictes : recrutement, crédit, éducation, infrastructures critiques. Elle impose documentation, examen des biais et contrôle humain effectif.Voir dans le glossaire, des obligations de journalisation automatique des événements (article dédié à la tenue de journaux), de traçabilité de la chaîne de décision, et de documentation technique permettant à une autorité de contrôle de reconstituer le fonctionnement du système. Un agent MCP qui agit sur des décisions ayant un effet sur des personnes — accès à un service, évaluation, recrutement — entre potentiellement dans ce périmètre, indépendamment de la technologie sous-jacente : ce qui compte pour la classification, c'est l'usage, pas l'implémentation.

La norme ISO/IEC 42001, référentiel de système de management de l'IA, ne prescrit pas de mécanisme technique précis mais exige la démonstration d'un cycle de gouvernance : identification des risques liés à l'IA, contrôles proportionnés, revue périodique, et — point directement pertinent ici — capacité à produire des preuves d'exploitation cohérentes avec les contrôles déclarés. Un audit ISO 42001 qui porte sur un système exposant des outils MCP demandera concrètement : montrez-moi le journal d'une invocation à risque, montrez-moi qui a validé la politique d'accès à cet outil, montrez-moi la trace de la dernière revue de ce périmètre.

Ne traitez pas la conformité AI Act et ISO 42001 comme deux chantiers séparés. Le même socle de traçabilité MCP — journal structuré, corrélation de session, politique de rétention documentée — sert de preuve pour les deux cadres. Construire ce socle une fois, correctement, coûte moins cher que de le reconstruire séparément pour chaque référentiel.

Ni l'un ni l'autre cadre n'impose de format technique spécifique : ils imposent un résultat, traçabilité démontrable et gouvernance active, que l'architecture décrite plus haut permet d'atteindre sans complexité disproportionnée.

Playbook d'investigation

Lorsqu'un incident est signalé — action inattendue, réclamation d'un utilisateur, alerte de sécurité — la vitesse de résolution dépend directement de la qualité du socle de traçabilité mis en place en amont. Un déroulé type :

1. Isoler la session. Identifier le session_id à partir de l'élément connu (heure approximative, utilisateur, système cible affecté).
2. Reconstruire la chronologie. Extraire l'ensemble des invocations d'outils rattachées à cette session, dans l'ordre chronologique, avec leur decision et leur downstream_status.
3. Vérifier le point de bascule. Identifier l'invocation à partir de laquelle le comportement diverge de l'attendu — souvent un paramètre mal interprété plutôt qu'un outil défaillant.
4. Croiser avec les journaux applicatifs cibles. Confirmer, via le session_id propagé, que l'action vue côté MCP correspond bien à l'action enregistrée côté système cible.
5. Qualifier la cause. Distinguer une erreur de raisonnement du modèle, une politique d'autorisation trop permissive, un paramètre par défaut incorrect, ou une tentative d'injection de prompt.
6. Documenter et clôturer. Consigner la cause racine, l'action corrective (règle de politique resserrée, garde-fou ajouté, prompt système ajusté), et la date de mise en œuvre — cette documentation devient elle-même une preuve de gouvernance active.

Un playbook d'investigation qui n'est jamais répété reste théorique. Planifiez un exercice de simulation d'incident au moins une fois par trimestre : injectez un scénario fictif (action non autorisée, dérive de paramètre) et mesurez le temps réel nécessaire pour remonter du symptôme à la cause racine via les journaux existants.

Indicateurs de risque opérationnel

Au-delà de l'investigation réactive, un tableau de bord d'indicateurs permet de détecter des dérives avant qu'elles ne produisent un incident visible :

• Taux de refus par politique d'autorisation, par outil. Une hausse soudaine peut signaler soit une tentative d'usage hors périmètre, soit une politique devenue trop restrictive après une modification récente.
• Taux d'invocations à fort impact (écriture, suppression, envoi) rapporté au nombre total d'invocations. Une proportion croissante d'actions irréversibles mérite un examen, indépendamment de leur succès technique.
• Latence de décision de politique, distincte de la latence d'exécution de l'outil. Une politique d'autorisation lente incite les équipes à contourner le contrôle plutôt qu'à l'attendre.
• Nombre de sessions sans corrélation complète — cas où le session_id ne se retrouve pas dans les journaux du système cible. Cet indicateur mesure directement la qualité de l'instrumentation, pas le comportement du modèle.
• Écart entre décisions humaines et décisions automatisées sur les mêmes catégories d'actions, lorsqu'un mode de validation manuelle coexiste avec l'automatisation.

Ces indicateurs n'ont de valeur que suivis dans la durée et présentés à un niveau de gouvernance capable d'arbitrer — resserrer une politique, ajouter une étape de validation humaine, ou au contraire alléger un contrôle devenu obsolète après tests concluants.

Checklist de mise en œuvre

• Chaque invocation d'outil MCP génère un événement structuré incluant session_id, request_id, decision et downstream_status.
• Le session_id est propagé jusqu'aux journaux applicatifs des systèmes cibles.
• Une politique de rédaction des champs sensibles est appliquée avant écriture, pas après.
• Les durées de rétention sont différenciées entre journal détaillé et indicateurs agrégés, et documentées dans le registre des traitements.
• Le référentiel de journaux d'audit répond aux exigences de journalisation de l'AI Act pour les usages concernés.
• Un tableau de bord d'indicateurs de risque opérationnel est revu à intervalle régulier par une instance de gouvernance identifiée.
• Un playbook d'investigation existe, est documenté, et a été testé par une simulation récente.

Conclusion

L'observabilité d'un système MCP ne se résume pas à la collecte de logs techniques : c'est la capacité à reconstituer, pour n'importe quelle action passée, la chaîne complète qui va de l'intention exprimée par un utilisateur jusqu'à l'effet produit sur le système d'information. Cette capacité conditionne à la fois la résolution rapide des incidents, la défendabilité juridique des décisions automatisées, et la conformité aux référentiels qui structurent désormais le déploiement de l'IA en entreprise. Elle se construit en amont, dans l'architecture de journalisation, pas après coup lorsqu'un incident impose de reconstituer ce qui aurait dû être enregistré dès le départ.