MCP et base de connaissances : connecter les agents IA sans perdre les droits

Le knowledge management headless sépare l’endroit où la connaissance est gouvernée des endroits où elle est lue. La base de connaissances devient une source unique : chaque contenu y a un responsable, une date de revue, des droits d’accès et une origine que l’on peut citer. Les équipes, Microsoft Copilot et les agents IA la consultent ensuite par des interfaces ouvertes (la recherche, une API, le Model Context Protocol ou MCP), depuis les outils qu’ils utilisent déjà.

Une même procédure peut aujourd’hui être lue dans cinq outils différents. Chacun peut changer l’an prochain ; la source, elle, doit rester juste pour tous. C’est donc dans la gouvernance de la source que se joue la valeur.

D’où vient le mot "headless"

En informatique, un serveur headless ("sans tête") fonctionne sans écran ni clavier. Personne ne s’assoit devant : d’autres systèmes l’interrogent par le réseau.

La gestion de contenu a repris l’idée. En octobre 2009, Daniel Jacobson, alors directeur du développement applicatif de NPR, la radio publique américaine, décrit la méthode de son équipe : COPE, pour "create once, publish everywhere" (créer une fois, publier partout). Les contenus entrent dans un seul système, puis le site, les applications mobiles et les autres supports les lisent par une API. Séparer le contenu de son affichage est, selon lui, l’un des principes clés de la méthode. Les outils bâtis sur ce principe (un référentiel de contenus et une API, sans interface de lecture propre) ont ensuite pris le nom de CMS headless.

La gestion des connaissances en est au même point, pour une autre raison. La "tête" d’une base de connaissances, c’était son portail : on y allait pour chercher et pour lire. Aujourd’hui, la même procédure est lue dans un ticket, dans une conversation avec un assistant dans Teams ou Slack, par Copilot, par un agent développé par la DSI, et sur un portail d’aide ouvert aux clients. La plupart de ces lecteurs n’ouvrent jamais la base elle-même.

Une base de connaissances headless : une source, plusieurs interfaces

Une base de connaissances headless se compose de deux parties. La première est la source. Elle porte la connaissance et, pour chaque contenu, quatre informations :

• Le responsable : qui en répond aujourd’hui, nommément.
• La validité : quand le contenu a été vérifié, et quand il doit l’être à nouveau.
• Les droits : qui peut le lire, et donc qui peut recevoir une réponse construite à partir de lui.
• L’origine : d’où vient chaque affirmation, pour qu’une réponse puisse la citer.

La seconde, ce sont les interfaces qui exposent la source : une recherche sémantique, une API de base de connaissances pour les applications internes, un serveur MCP pour les assistants et les agents IA. Chaque outil de lecture passe par l’une d’elles, avec ses propres attentes envers la source.

"Headless" désigne ici une architecture, pas une catégorie de logiciels. Les outils de lecture gardent d’ailleurs toute leur importance : nous y revenons à la fin de l’article.

MCP et base de connaissances : ce que le protocole règle, et ce qu’il laisse ouvert

Ce qu’est MCP. Un protocole ouvert qui relie les applications d’IA aux données et aux outils, et dont la spécification en vigueur est datée du 28 juillet 2026. Notre guide sur la gestion des connaissances pour l’IA explique comment les agents IA s’en servent pour se connecter à une base de connaissances.

Qui le gouverne. MCP est désormais une "Series of LF Projects", une structure de la Linux Foundation, et sa spécification est publiée sous licence Apache 2.0. Le 9 décembre 2025, la Linux Foundation a créé l’Agentic AI Foundation, avec MCP parmi ses premiers projets. Le protocole Agent2Agent (A2A), qui fait dialoguer les agents entre eux, l’a rejointe le 27 août 2026.

Ce que préparent les organismes de normalisation. L’Internet Engineering Task Force (IETF), qui normalise les protocoles d’Internet, est en train de créer un groupe de travail sur la communication entre agents, agentproto. Son projet de charte laisse MCP et A2A à leurs propres mainteneurs, et son calendrier s’achève en mars 2028, quand le protocole doit être soumis pour approbation comme proposition de norme. Aux États-Unis, le NIST (National Institute of Standards and Technology) a lancé en février 2026 une initiative sur les standards des agents IA ; l’un de ses trois piliers porte sur la sécurité et l’identité des agents.

Ce que MCP laisse à votre charge. Le protocole règle la connexion. Il ne dit pas qui peut lire quoi. La spécification indique que l’autorisation est optionnelle. Quand un serveur l’utilise en HTTP, elle doit en principe suivre OAuth 2.1 : le serveur n’accepte que les jetons émis pour lui, et le client demande les droits les plus réduits possible. Le texte précise aussi que MCP ne peut pas faire respecter ses principes de sécurité au niveau du protocole : les écrans de consentement et les contrôles d’accès reviennent à ceux qui l’implémentent. Il ne dit pas comment un serveur doit aligner ce qu’il renvoie sur les droits de chaque personne dans le système source.

La connexion suit un standard ; les droits, eux, restent l’affaire de la source.

Les droits suivent la réponse

Sur les droits, les guides publics de sécurité sont plus précis que les protocoles.

L’ANSSI a publié 35 recommandations de sécurité pour les systèmes d’IA générative en avril 2024. Elle demande de prendre en compte le besoin d’en connaître dès la conception (R8) : les données d’entraînement ne peuvent pas porter de droits d’accès, alors que les données ajoutées en production le peuvent, selon les outils qui les stockent. Elle demande un contrôle des autorisations d’accès, en plus de l’authentification, sur chaque échange entre le système d’IA et les applications métier (R26). Elle recommande enfin de revoir les droits des outils d’IA générative sur la messagerie, les espaces documentaires et les dépôts de code dès leur activation, puis régulièrement, "ex. : tous les mois" (R35).

En mai 2025, des agences de sécurité des États-Unis, du Royaume-Uni, d’Australie et de Nouvelle-Zélande ont publié un guide commun sur les données utilisées par les systèmes d’IA. Il tranche la question des réponses : ce que produit un système d’IA doit en général être classifié au même niveau que les données qu’il a reçues.

La CNIL et le Conseil de l’IA et du numérique ont ajouté un point en juillet 2026, dans une note exploratoire sur l’IA agentique : quand un agent passe d’un service à l’autre, il devient plus difficile d’établir qui est responsable de quoi.

Mis bout à bout, ces textes donnent la règle des droits d’une architecture headless :

1. Une réponse est aussi confidentielle que sa source la plus confidentielle. La source doit donc connaître le niveau de chaque document, en plus de celui du dossier qui le contient.
2. Chaque outil lit au nom de la personne qui pose la question. Un connecteur qui lit avec un compte de service très large donne à tout le monde les droits de ce compte.
3. Les droits se revoient connecteur par connecteur. Chaque outil de lecture est un nouveau lecteur, avec ses propres autorisations.

Ces guides s’arrêtent avant les cas les plus difficiles. Aucun ne dit quoi faire quand une réponse combine des documents aux droits différents, ni quand un droit est retiré après qu’un document a été copié dans un index séparé. Une architecture qui lit la source au moment de la question, avec les droits de la personne, évite le second cas : une copie garde les droits du jour où elle a été faite.

Pourquoi la source décide de la réponse

Le responsable et la date de revue comptent, parce que les modèles croient volontiers les documents qu’on leur donne. Dans une étude publiée en janvier 2026 dans The Lancet Digital Health, revue à comité de lecture, des chercheurs ont testé 20 grands modèles de langage sur de fausses informations médicales. Insérée dans un vrai compte rendu de sortie d’hôpital, une fausse recommandation a été acceptée dans 46,1 % des cas, contre 8,9 % pour les fausses affirmations tirées des réseaux sociaux. Des trois types de textes testés, ce sont les comptes rendus cliniques, rédigés dans une prose d’allure officielle, que les modèles ont crus le plus souvent. Or, pour un modèle, une procédure d’entreprise a l’air tout aussi officielle. Notre article sur le WYKIWYG ("what you know is what you get") détaille ces travaux.

Ce que cela change pour un déploiement

Tout part des sources. Avant de choisir le prochain assistant, faites la liste de ce que lit chaque outil existant, et d’où. Une checklist d’audit des connaissances donne la structure : quels espaces, quels responsables, quelles dates de revue, quels droits. Une lacune trouvée là apparaîtra dans tous les outils à la fois.

Les outils de lecture sont nombreux. Tenez-en la liste, avec un responsable nommé pour chaque connexion.

Testez ce que chacun lit. Posez les mêmes questions dans chaque outil, au nom de personnes aux droits différents, et comparez les réponses et les sources citées. Le profil du NIST pour l’IA générative (NIST AI 600-1, juillet 2024) recommande de réévaluer les risques après l’ajout d’une génération augmentée par la recherche (RAG). Ajouter un outil de lecture à la même source relève du même type de changement. Voir aussi notre article sur le RAG.

Un exemple public montre cette architecture à l’échelle d’un pays. En février 2026, data.gouv.fr, la plateforme ouverte des données publiques, a lancé à titre expérimental un serveur MCP que tout assistant compatible peut interroger sans clé, en lecture seule. Son guide prévient que les réponses peuvent être incomplètes ou erronées, et renvoie les usages sérieux vers l’API, pour des résultats traçables. Les données ouvertes n’ont pas besoin de droits par personne. Les connaissances d’une entreprise, si : c’est pourquoi la règle des droits pèse plus lourd en interne.

Là où la thèse s’arrête

L’argument headless vaut pour la lecture. Il vaut moins pour l’écriture.

L’outil où l’on écrit façonne ce que l’on écrit. Les bonnes contributions naissent dans un éditeur, avec des modèles, un flux d’approbation et un responsable identifié. On écrit là où c’est simple, et une fenêtre de conversation se prête mal à la rédaction d’une procédure que 200 collègues vont suivre. Une source où il est difficile d’écrire se dégrade, quelles que soient ses interfaces.

L’adoption, elle aussi, se joue dans l’outil de lecture. Les équipes jugent la connaissance à la réponse qu’elles voient dans leur outil, et une réponse fausse leur fait douter de la connaissance elle-même. Ces outils méritent donc du soin. Mais ce n’est pas là que la connaissance se gouverne.

La comparaison avec la gestion de contenu a aussi ses limites. Une page web se publie et se lit. Une procédure vieillit, change de responsable et finit par contredire une version plus récente. C’est la partie la plus difficile, celle que le knowledge as code aborde avec des pratiques venues du logiciel : versions, relecture, historique de chaque modification.

Ce que les standards ne règlent pas, et ce que fait Elium

Les textes cités plus haut disent peu de choses de la source elle-même : qui est responsable de chaque document, quand il expire, comment ses droits parviennent à chaque lecteur. C’est la partie que nous construisons chez Elium, plateforme européenne de gestion des connaissances. Si vos ingénieurs ont bâti leur propre RAG, ils sont dans leur métier. Nous prenons en charge ce dont ce RAG dépend : des connaissances exactes et à jour.

• Une source gouvernée. Chaque article a un responsable nommé, chargé de le tenir exact et à jour, et peut porter une date de vérification. À l’approche de cette date, l’article apparaît dans la liste de tâches de son responsable. Voir Garder vos articles à jour et Permissions et visibilités.
• Une lecture au nom de la personne. Le serveur MCP d’Elium fonctionne avec ChatGPT, Claude, Microsoft Copilot Studio et les autres assistants compatibles. Chaque appel au serveur s’exécute avec les droits de la personne connectée : un assistant ne voit jamais un contenu que cette personne ne pourrait pas ouvrir. Voir À propos de MCP.
• Une validité vérifiable. Quand un assistant lit un article, il reçoit aussi son responsable, sa date de revue ou d’expiration et son statut d’approbation, et peut donc dire si sa source est à jour. Voir Rechercher et lire du contenu avec MCP.
• Plusieurs outils de lecture. La même plateforme se lit par l’API, dans une extension de navigateur à côté d’un ticket et sur un portail public pour les clients. Voir API et applications connectées, Extension navigateur et À propos du portail public.

Au Département de l’Orne, par exemple, les techniciens reçoivent les réponses dans leurs tickets GLPI, et chaque procédure porte une date d’expiration qui déclenche une revue annuelle. Le témoignage de l’Orne décrit le dispositif.

Pour aller plus loin

• Le guide de référence : la gestion des connaissances pour l’IA.
• Comparer : knowledge base software, 10 solutions comparées.
• Utiliser un modèle : la checklist d’audit des connaissances.
• Le faire avec Elium : connecter un assistant à Elium avec MCP.

FAQ

Questions fréquentes

Qu’est-ce que le knowledge management headless ?

C’est une gestion des connaissances où la connaissance reste dans une source unique et gouvernée, lue ailleurs par les équipes et les agents IA, via la recherche, une API ou MCP. La rédaction, la revue et les droits restent dans la source ; la lecture se fait dans Teams, un ticket, Copilot, un agent ou un portail d’aide.

Comment connecter une base de connaissances à MCP sans perdre les droits d’accès ?

En vérifiant que le serveur MCP lit au nom de la personne connectée, avec les droits de cette personne. La spécification MCP rend l’autorisation optionnelle et, en HTTP, recommande OAuth 2.1 : c’est au serveur de filtrer chaque réponse selon les droits de la personne dans la base.

Quelle différence entre un CMS headless et une base de connaissances headless ?

Un CMS headless sépare le contenu de son affichage, pour publier un même article sur plusieurs canaux. Une base de connaissances headless fait de même pour des lecteurs, humains ou agents IA, mais ses contenus vieillissent et portent des droits : la source gère donc aussi les responsables, les dates de revue et les droits d’accès.

Faut-il encore ouvrir la base de connaissances elle-même ?

Oui, pour écrire et pour vérifier. Les auteurs ont besoin d’un éditeur, de modèles et d’un flux d’approbation, et un lecteur veut parfois voir l’article complet et son responsable derrière une réponse. La lecture du quotidien, elle, peut se faire dans les outils déjà utilisés.

Comment appliquer les droits quand un agent IA répond ?

Une réponse doit être classifiée au même niveau que les données à partir desquelles elle a été construite, comme le recommande le guide commun d’agences américaines, britanniques, australiennes et néo-zélandaises (mai 2025). Chaque outil lit au nom de la personne qui demande, et les droits de chaque connecteur IA sont revus régulièrement, chaque mois dans l’exemple de l’ANSSI.

Sources

• Daniel Jacobson (NPR), COPE : Create Once, Publish Everywhere, ProgrammableWeb, 13 octobre 2009 (copie archivée par l’université de North Texas, en anglais).
• Model Context Protocol, Specification, version du 28 juillet 2026, section Authorization, et Governance and stewardship (en anglais).
• Linux Foundation, Linux Foundation announces the formation of the Agentic AI Foundation, 9 décembre 2025 (en anglais).
• Projet A2A, A new chapter for A2A : joining the Agentic AI Foundation, 27 août 2026 (en anglais).
• IETF, groupe de travail Agent Communication Protocols (agentproto), projet de charte et calendrier (en anglais).
• NIST, Center for AI Standards and Innovation, Announcing the AI Agent Standards Initiative for interoperable and secure innovation, 17 février 2026 (en anglais).
• NIST, Generative Artificial Intelligence Profile (NIST AI 600-1), juillet 2024 (en anglais).
• ANSSI, Recommandations de sécurité pour un système d’IA générative, version 1.0, 29 avril 2024.
• NSA Artificial Intelligence Security Center, CISA, FBI, ASD’s ACSC, NCSC-NZ et NCSC-UK, AI Data Security : Best Practices for Securing Data Used to Train and Operate AI Systems, mai 2025 (en anglais).
• CNIL et Conseil de l’IA et du numérique, IA agentique et données personnelles : note exploratoire, 20 juillet 2026.
• Mahmud Omar et al., Mapping the susceptibility of large language models to medical misinformation across clinical notes and social media, The Lancet Digital Health 8(1), janvier 2026 (en anglais).
• data.gouv.fr, Le serveur MCP de data.gouv.fr, et Jacques Cheminat, Data.gouv.fr expérimente un serveur MCP, Le Monde Informatique, 27 février 2026.