K-AI
FREN
Demander une démo
SolutionComment ça marcheImpactActualitésPartenaires
FREN
Demander une démo
← Toutes les actualités
Presse · 26 juin 2026 · 11 min de lecture

Model Context Protocol et corpus d'entreprise : ce que MCP normalise, ce qu'il laisse sans gouvernance

Model Context Protocol et corpus d'entreprise : ce que MCP normalise, ce qu'il laisse sans gouvernance

MCP standardise l'accès aux sources documentaires pour les LLM — pas leur qualité. Ce que les architectes RAG doivent savoir avant de connecter SharePoint.

En juin 2026, le rapport KPMG Redefining Excellence in the Age of Agentic AI a été retiré de tous les sites du cabinet après que GPTZero a documenté que 40 de ses 45 citations pointaient vers des sources inexistantes ou fabriquées (TechCrunch, 13 juin 2026). Ce n’était pas un problème d’accès aux documents. KPMG disposait d’un pipeline IA, de sources, d’un système de récupération de contenu. Le problème était en amont : la qualité des sources auxquelles le système avait accès.

Cet incident se répète, à des degrés divers, dans les déploiements RAG enterprise chaque semaine. Il illustre une confusion structurelle qui prend une forme nouvelle en 2026 avec la montée en puissance du Model Context Protocol.

Ce que MCP standardise pour les sources documentaires

Publié par Anthropic en novembre 2024 (spécification officielle), le Model Context Protocol est devenu en quelques mois le standard de fait pour connecter des agents LLM à des sources de données externes. Le protocole repose sur une architecture simple : un hôte LLM (Claude, GPT-4o, Gemini) se connecte à des serveurs MCP qui exposent des ressources (documents, bases de données, API) via une interface unifiée en JSON-RPC.

Pour les sources documentaires d’entreprise, MCP standardise trois éléments techniques précis :

1. La découvrabilité. Un serveur MCP expose la liste des ressources disponibles via la primitive resources/list. Un agent peut ainsi inventorier dynamiquement les documents accessibles dans un SharePoint, un espace Confluence, un système GED — sans connaissance préalable de la structure.

2. L’accès normalisé. La primitive resources/read retourne le contenu d’un document identifié par son URI (par exemple sharepoint://tenant/site/library/document.docx), accompagné de métadonnées de base : type MIME, titre, dernière modification si le serveur la fournit.

3. L’interopérabilité. Un agent peut basculer d’un serveur MCP SharePoint à un serveur MCP Confluence sans modifier son architecture de retrieval. L’Atlassian MCP Server, ouvert en mai 2026, donne accès aux espaces Confluence et aux projets Jira via ce protocole (SiliconANGLE, 6 mai 2026). Microsoft a fait de même pour SharePoint.

Ces trois capacités sont réelles et précieuses. MCP réduit significativement la friction d’intégration entre agents LLM et sources documentaires enterprise. C’est son bénéfice principal.

Ce que MCP ne voit pas — et pourquoi c’est un problème structurel

La spécification MCP ne définit aucun mécanisme pour les éléments suivants :

  • La validité du document : est-ce que ce document est encore en vigueur, ou a-t-il été remplacé par une version plus récente non invalidée formellement ?
  • La détection de conflits : ce document contredit-il un autre document du même corpus sur le même sujet ?
  • La canonicité de version : parmi trois versions d’une procédure stockées dans le même SharePoint, laquelle fait autorité ?
  • Les métadonnées de gouvernance : qui est responsable de ce document ? Quelle est sa date de validité contractuelle ? A-t-il un propriétaire actif ?
  • Le score de qualité sémantique : ce document est-il cohérent avec les autres sources que le pipeline RAG va interroger simultanément ?

Ces lacunes ne sont pas un défaut de conception de MCP — elles sont hors périmètre délibéré. MCP est un protocole de transport et d’accès, pas un framework de gouvernance documentaire. La confusion vient du fait que les deux problèmes — accéder à un document et savoir si ce document est fiable — se résolvent maintenant avec des outils différents à des niveaux différents de la stack.

Un serveur MCP SharePoint connecté à une bibliothèque de 40 000 documents va exposer ces 40 000 documents avec une latence et une cohérence technique exemplaires. Si 23 % de ces documents sont périmés, s’il existe 1 400 paires de documents en conflit sur des questions de politique RH ou de procédures réglementaires, le protocole ne verra rien. L’agent LLM non plus.

Le scénario concret : normaliser l’accès au chaos

Un survey de 132 leaders IA enterprise publié par VentureBeat en juin 2026 (lien) documente que le principal point de défaillance des agents en production n’est pas le modèle, c’est la couche knowledge. Les équipes investissent dans des retries et de l’orchestration là où le problème est la cohérence des sources. L’investissement en retrieval optimization a bondi de 19 % à 28,9 % des budgets d’infrastructure IA au Q1 2026. Les équipes techniques investissent dans des rerankers, des hybrid search, des GraphRAG — toutes des améliorations de la couche de retrieval. Aucune de ces technologies ne détecte qu’une note de service d’avril 2023 stockée dans Confluence est contredite par une directive de janvier 2026 dans le même espace.

Une étude d’arXiv sur la précision factuelle des citations dans les agents de recherche IA (arXiv:2605.06635, mai 2026) révèle que même les modèles frontière les plus performants n’atteignent que 77 % de précision factuelle sur leurs citations ; les modèles open-source descendent en dessous de 39 %. Ces mesures portent sur des agents avec accès web — les RAG enterprise sur corpus privés ne disposent pas encore de cadre d’évaluation standardisé équivalent, ce qui rend le problème potentiellement plus prononcé sur des corpus non gouvernés. La cause n’est pas dans l’architecture de retrieval. Elle est dans la qualité des sources.

MCP rend ces sources accessibles plus facilement. Il ne les rend pas plus fiables.

La couche DKP comme upstream d’un serveur MCP

Il existe deux approches architecturales pour traiter ce problème.

Approche réactive : ajouter de la vérification post-retrieval — fact-checking, reranking de confiance, filtrage de sources par date. Cette approche traite les symptômes à la sortie du pipeline. Elle est coûteuse en compute, non déterministe, et ne fonctionne pas pour les contradictions inter-documents (si deux sources contradictoires sont récupérées, le pipeline n’a pas les moyens de savoir laquelle est correcte sans connaître leur historique de versions).

Approche préventive : auditer et gouverner le corpus avant qu’il ne soit exposé via le serveur MCP. C’est ce que fait une Document Knowledge Platform. Sur un seul référentiel documentaire lors d’un premier diagnostic, les équipes K-AI relèvent en général plusieurs centaines d’anomalies documentaires — doublons divergents, documents en conflit sur des seuils réglementaires, versions périmées non invalidées formellement, documents orphelins sans owner actif. Ces anomalies sont détectables avant indexation, pas après.

Dans une architecture MCP-DKP, la séquence est la suivante :

Sources brutes (SharePoint, Confluence, GED, S3...)
         ↓
    [Couche DKP]
    Audit → Nettoyage → Scoring → Monitoring continu
         ↓
  Corpus gouverné (documents valides, conflits résolus)
         ↓
    [Serveur MCP]
    Exposition normalisée aux agents LLM
         ↓
   Agent / Pipeline RAG

Le serveur MCP reçoit en input un corpus déjà qualifié. Les ressources qu’il expose ont une validité documentée, une version canonique, un statut de conflit résolu. L’agent LLM peut construire sur cette couche avec une probabilité de cohérence documentaire mesurable.

Recommandations pour les équipes qui déploient des agents MCP

Avant de connecter un serveur MCP à une source documentaire enterprise :

  1. Auditer la source avant de l’exposer. Ne pas supposer qu’un SharePoint ou un Confluence est “propre” parce qu’il est organisé. La structure d’accès (bibliothèques, espaces, permissions) ne dit rien sur la cohérence sémantique du contenu.

  2. Distinguer les sources à fort risque de conflit. Les espaces de politique RH, les procédures réglementaires, les documentations produit multi-versionnées sont les territoires à auditer en priorité avant exposition MCP. Les documents techniques figés (rapports archivés, contrats) posent moins de risque de contradiction active.

  3. Instrumenter le monitoring continu, pas seulement l’audit one-shot. Un corpus audité avant déploiement MCP dérive après. Les nouvelles versions, les mises à jour partielles, les documents importés sans contrôle créent des conflits post-audit. La gouvernance documentaire continue — ce que nous appelons “Stay Clean” — est la condition de durabilité de la qualité du corpus dans un contexte MCP.

  4. Intégrer les métadonnées de gouvernance dans les annotations MCP. La spécification MCP permet aux serveurs d’exposer des annotations personnalisées sur les ressources. Un serveur MCP connecté à un corpus DKP peut remonter : score de qualité, statut de validité, identifiant de version canonique, date de dernier audit. Ces métadonnées permettent à l’agent de pondérer dynamiquement sa confiance dans chaque source.

  5. Consulter les obligations Article 12 pour les systèmes haut-risque. Si votre pipeline MCP alimente un système IA à haut risque au sens de l’Annexe III de l’AI Act, le logging des sources consultées par l’agent entre dans le périmètre de l’obligation de traçabilité. La qualité documentaire amont est une condition de défendabilité de ce log.

Foire aux questions

MCP peut-il remplacer un système de gouvernance documentaire en entreprise ?

Non. MCP est un protocole de transport et d’accès : il normalise la façon dont un agent LLM découvre et lit des documents, pas la façon dont ces documents sont qualifiés, maintenus ou gouvernés. Un système de gouvernance documentaire audite la cohérence sémantique du corpus (conflits inter-documents, doublons divergents, obsolescence non marquée), produit un scoring de qualité, et surveille la dérive en continu. Ces deux couches sont complémentaires, pas substituables. MCP sans gouvernance documentaire expose efficacement un corpus potentiellement non fiable.

Comment savoir si mon corpus SharePoint est prêt à être exposé via MCP pour un agent LLM ?

Trois indicateurs pratiques : (1) Proportion de documents sans date de validité explicite ou sans propriétaire actif — un taux supérieur à 30 % est un signal d’alerte. (2) Existence de doublons de noms de fichier avec des versions multiples dans la même bibliothèque — chaque doublon divergent est un risque de retrieval non déterministe. (3) Présence de documents en conflit sur des seuils réglementaires ou des procédures opérationnelles — la détection de conflits inter-documents nécessite une analyse sémantique, pas une comparaison de métadonnées. Un audit de corpus documentaire, tel que décrit dans notre méthode des 6 axes, fournit ces trois indicateurs avant exposition MCP.

Que retourne concrètement un serveur MCP pour un document SharePoint ?

La primitive resources/read d’un serveur MCP SharePoint retourne le contenu textuel du document, son URI, son type MIME, et les métadonnées de base si le serveur les expose (titre, date de dernière modification, auteur). Ce que le serveur ne retourne pas : statut de validité du document, indicateur de conflit avec d’autres documents du corpus, version canonique en cas de multiples versions actives, score de qualité sémantique. Ces informations doivent être produites par une couche d’audit documentaire en amont et injectées comme annotations personnalisées dans le serveur MCP.

Quel est le risque concret pour un agent LLM connecté à un corpus non audité via MCP ?

L’agent récupère et synthétise des sources contradictoires sans pouvoir le détecter. Exemple : une procédure d’approbation budgétaire a été mise à jour en mars 2026, mais l’ancienne version d’octobre 2024 reste indexée dans le même espace Confluence. Le serveur MCP expose les deux. Le reranker ne voit pas la contradiction sémantique — il voit deux documents pertinents sur le même sujet. L’agent génère une réponse basée sur l’une ou l’autre selon l’ordre de récupération — comportement non déterministe qui érode la confiance opérationnelle. Le scénario KPMG (40/45 citations invérifiables) est l’extrême de ce type de défaillance.

Comment K-AI s’intègre-t-il dans une architecture MCP ?

K-AI opère en amont du serveur MCP : la Document Knowledge Platform audite le corpus source (SharePoint, Confluence, GED, systèmes propriétaires), résout les conflits et doublons, marque les documents périmés, et produit un score de qualité par document. Le corpus gouverné est ensuite exposé via le serveur MCP — avec des annotations enrichies (validité, version canonique, score de qualité) disponibles pour l’agent. K-AI propose une intégration MCP native qui permet aux équipes d’architecture de connecter la couche DKP directement dans leur infrastructure agentique.

Pour aller plus loin

Ces questions s’inscrivent dans un contexte plus large de gouvernance documentaire pour l’IA agentique. Nos publications antérieures documentent les dimensions complémentaires :

Pour une conversation sur l’intégration K-AI dans votre architecture MCP : contact@k-ai.ai

K-AI accompagne déjà CMA CGM, Veolia, PwC, BNP Paribas, TotalEnergies et CEVA Logistics. Partenaires : AWS, Snowflake, Microsoft, Wavestone, Devoteam.

Sources citées

Et chez vous, quel est votre patrimoine documentaire ?

30 minutes avec un fondateur. On audite gratuitement un échantillon de vos documents et on vous montre exactement ce que K-AI détecte.

Demander une démo → Lire d’autres articles