Le mur de la donnée statique : pourquoi le RAG ne suffit plus

Vous avez déployé un chatbot basé sur un RAG (Retrieval-Augmented Generation, génération augmentée par récupération) pour répondre aux questions de vos équipes sur la documentation interne. Tout fonctionne, jusqu'au jour où un collaborateur demande : « Quels jeux de données ont été mis à jour cette semaine ? ». La réponse tombe, immuable : « Je ne dispose pas d'informations en temps réel. » Ce scénario, la Direction interministérielle du numérique (DINUM) le décrit noir sur blanc dans son analyse de février 2026 sur les MCP.

Le problème est structurel. Un système RAG fonctionne par indexation : au moment de la construction (build-time), on vectorise un corpus documentaire, puis on interroge cet index figé. La connaissance est photographiée à un instant T. Dès qu'une donnée bouge — un catalogue produit, un ticket ouvert, une météo, un solde comptable — le RAG devient aveugle. Pire encore, il ne sait pas agir. Il lit, il ne fait rien.

Les deux impasses des IA « bibliothécaires »

J'appelle ces systèmes des IA bibliothécaires : elles connaissent le contenu des rayons, mais ne peuvent ni vérifier ce qui vient d'arriver, ni écrire un nouveau livre. Deux impasses concrètes reviennent dans nos audits :

  • L'obsolescence silencieuse : l'utilisateur ne sait pas que la réponse date de la dernière indexation. Il prend une décision sur une donnée périmée, sans alerte, ce qui est particulièrement dangereux en comptabilité, en gestion de stock ou en suivi réglementaire.
  • L'incapacité à agir : demander à un RAG de créer un ticket, d'envoyer un e-mail ou de mettre à jour une fiche client est impossible par construction. Il n'a aucun bras, seulement une mémoire.

C'est cette double frontière que le MCP fait tomber. Il transforme l'IA statique en IA agentique — capable d'interroger le réel au moment de la question (runtime) et d'exécuter des tâches. Pour comprendre le vocabulaire sous-jacent, notre glossaire IA détaille les notions de RAG, d'embeddings et d'agents.

MCP Model Context Protocol : l'USB de l'intelligence artificielle

Imaginez un monde où chaque périphérique aurait son propre connecteur propriétaire — c'était la réalité avant l'USB. Le MCP applique exactement cette logique de standardisation à l'IA. Comme le formule la DINUM, « MCP fait pour l'IA ce qu'USB a fait pour l'électronique ». N'importe quel grand modèle de langage — Claude, Mistral, ChatGPT — peut se connecter à n'importe quelle source de données ou outil compatible MCP, sans intégration spécifique.

Origine et gouvernance ouverte

Le protocole a été introduit par Anthropic, la maison mère de Claude, fin 2024. Les Bases du numérique d'intérêt général, portées par l'ANCT, le confirment dans leur fiche de mars 2026. Point décisif pour la souveraineté : le protocole est désormais hébergé par la Linux Foundation. Il ne s'agit donc plus d'un format contrôlé par un seul éditeur, mais d'un bien commun technologique gouverné collectivement. C'est cette neutralité qui permet à un intégrateur comme IAPRO de le recommander sans enfermer un client dans un écosystème propriétaire.

La fin des intégrations sur mesure

L'apport économique est direct. Auparavant, connecter votre CRM, votre ERP et votre outil de tickets à trois assistants différents exigeait neuf développements distincts. Avec le MCP, un seul serveur par source de données suffit : il expose vos données une fois, et toutes les IA compatibles y accèdent. On passe d'une matrice de coûts en N×M à une addition en N+M. Sur un système d'information de PME, cela représente des semaines de développement économisées à chaque nouveau modèle testé.

RAG vs MCP : comprendre la complémentarité stratégique

C'est la question qui revient dans chaque réunion de direction : « J'ai déjà un RAG, pourquoi investir dans le MCP ? ». La réponse tient en un mot : ils ne résolvent pas le même problème. Ils sont complémentaires, jamais concurrents. Le tableau ci-dessous synthétise la distinction établie par la DINUM.

Critère RAG MCP
Temporalité Données statiques (build-time) Données dynamiques (runtime)
Fraîcheur Limitée à la date d'indexation Toujours à jour
Actions Lecture seule Lecture et écriture

La règle de décision est simple à mémoriser pour vos équipes :

  • « Que dit le code des marchés publics sur les seuils ? » → RAG idéal. La donnée est stable, la doctrine ne change pas d'une heure à l'autre, l'indexation est pertinente.
  • « Quels jeux de données ont été mis à jour cette semaine ? » → MCP indispensable. Un index figé donnerait une réponse périmée ; seul l'accès runtime garantit la fraîcheur.
  • « Résume-moi la doctrine CNIL sur les cookies. » → RAG idéal, connaissance statique.
  • « Crée un ticket JIRA pour signaler ce bug. » → MCP obligatoire. Le RAG ne peut pas écrire ; le MCP dispose de l'outil d'exécution.

Concrètement, dans une installation IAPRO type, les deux cohabitent. Le RAG gère la base documentaire — contrats types, procédures qualité, conventions collectives. Le MCP gère le vivant — état des stocks, tickets ouverts, dernières factures. Le modèle arbitre à la volée quelle brique mobiliser selon la question. Pour chiffrer le gain de ce type d'architecture sur votre organisation, notre calculateur de ROI IA intègre les deux scénarios.

Architecture technique : hosts, clients et serveurs

Sous le capot, le MCP repose sur une architecture modulaire à trois rôles, qu'il faut distinguer clairement pour dialoguer avec un intégrateur.

  • Le Host : c'est l'application qui embarque le modèle — votre interface conversationnelle, par exemple OpenWebUI branché sur un Mistral local via Ollama. C'est là que réside l'intelligence.
  • Le Client : c'est le connecteur logiciel qui parle le protocole MCP au nom du Host. Il ouvre et maintient la liaison avec un serveur donné.
  • Le Serveur : c'est la brique qui expose une source de données ou un service. Un serveur pour votre ERP, un autre pour data.gouv.fr, un troisième pour votre messagerie.

Les trois piliers exposés par un serveur

Un serveur MCP ne se contente pas de livrer des données brutes. Il structure ce qu'il offre selon trois catégories fonctionnelles, ce qui donne au modèle un contrat clair :

  • Resources (ressources) : des données contextuelles en lecture — le contenu d'un fichier, une fiche client, une métadonnée de jeu de données. C'est la matière première que le modèle peut consulter.
  • Prompts : des workflows pré-remplis, des gabarits d'interaction que le serveur propose pour guider des tâches récurrentes, réduisant le risque d'erreur de formulation côté utilisateur.
  • Tools (outils) : des fonctions exécutables que le modèle appelle dynamiquement, comme search_datasets(query="qualité air") ou create_ticket(...). C'est le bras agissant du dispositif.

La DINUM classe d'ailleurs les serveurs selon leur fonction dominante : accès données (lire dans des API publiques ou bases internes), actions (créer un ticket, envoyer un mail) et outils de transformation (conversion, validation, calcul). Cette granularité permet de cadrer finement les permissions — un point capital que nous abordons dans la section conformité.

L'interopérabilité comme levier d'IA souveraine en France

Le MCP n'est pas qu'une commodité technique : c'est un levier de souveraineté. La dépendance aux connecteurs propriétaires des hyperscalers américains est l'un des angles morts des stratégies IA d'entreprise. Quand vos intégrations sont verrouillées dans l'écosystème d'un fournisseur cloud unique, changer de modèle ou rapatrier vos données on-premise devient prohibitif. Le standard ouvert inverse ce rapport de force.

Cette logique rejoint les travaux européens sur l'interopérabilité sémantique. L'initiative AI4OP (AI for Interoperability) du centre SEMIC de la Commission européenne, documentée sur le portail Interoperable Europe, explore précisément comment l'IA et les standards sémantiques peuvent « faire tomber les silos de données » dans le secteur public. Le MCP est l'incarnation opérationnelle de cette ambition au niveau des connecteurs.

Souveraineté par l'ouverture, pas par la fermeture

C'est un paradoxe que j'assume volontiers dans nos accompagnements : on ne construit pas la souveraineté en fermant les portes, mais en standardisant les serrures. En adoptant un protocole ouvert et gouverné par la Linux Foundation, une PME française conserve la maîtrise complète de sa donnée — qui reste sur ses serveurs, à Roubaix ou ailleurs — tout en la rendant exploitable par le modèle souverain de son choix. La donnée ne quitte jamais le périmètre local ; seul le protocole d'accès est mutualisé. C'est exactement la philosophie de l'installation on-premise que nous détaillons dans notre offre métiers.

Étude de cas : le serveur MCP de data.gouv.fr

L'État français n'attend pas : il expérimente déjà. L'équipe de data.gouv.fr a mis en ligne un serveur MCP officiel, datagouv-mcp, en open source. Sa documentation officielle est accessible dans les guides de data.gouv.fr, et le serveur est joignable à l'adresse https://mcp.data.gouv.fr/mcp.

Le principe est limpide : n'importe quel assistant conversationnel compatible MCP peut désormais interroger le catalogue de données publiques en langage naturel, sans qu'on développe une API spécifique pour chaque outil. Le dépôt du projet documente d'ailleurs la configuration avec Claude, ChatGPT et Mistral — la compatibilité multi-modèles n'est pas théorique.

Ce que le serveur permet aujourd'hui

Les cas d'usage résolus sont concrets et vérifiables :

  • Rechercher des jeux de données par thème, par exemple ceux sur la qualité de l'air mis à jour dans la semaine écoulée.
  • Récupérer des métadonnées et des données en temps réel — « télécharge les dernières données INSEE sur la population parisienne ».
  • Guider un utilisateur non spécialiste dans l'exploration d'un catalogue complexe, en langage courant plutôt qu'en requêtes API.

La trajectoire : de la lecture vers l'écriture

Point crucial pour comprendre la maturité du dispositif : à ce stade, le serveur fonctionne uniquement en lecture, sans autoriser aucune modification. Mais l'ANCT annonce clairement l'ambition : tester à terme des usages d'édition et de publication de données, « toujours avec prudence, et en s'appuyant sur des modèles souverains ». Cette montée en puissance progressive — lecture d'abord, écriture ensuite, sous garde-fous — est exactement le modèle de déploiement responsable que nous recommandons à nos clients. Notez que pour des automatisations robustes et rejouables à grande échelle, l'équipe data.gouv.fr rappelle elle-même que l'API classique reste le point d'entrée le plus adapté : le MCP ne remplace pas tout.

Cas d'usages concrets : de l'administration aux PME/ETI

Descendons au niveau du terrain, car c'est là que se joue l'adoption. Bpifrance Le Lab, dans une enquête relayée par France Num, rappelle que 58 % des dirigeants de PME-ETI considèrent l'IA comme un enjeu de survie à 3-5 ans, mais qu'une proportion égale n'a aucune stratégie en la matière. Le frein n'est pas l'intérêt : c'est la difficulté à cerner des applications créatrices de valeur. Le MCP répond directement à ce blocage en rendant l'IA utile sur les données du quotidien.

Pour une PME industrielle de 80 salariés

Prenons un cas que nous rencontrons souvent. Une PME industrielle veut que ses commerciaux interrogent l'état des stocks et le statut des commandes en langage naturel. Un serveur MCP branché sur l'ERP expose deux outils — get_stock(reference) et get_order_status(id). Le commercial demande « Reste-t-il des références X en stock pour livrer avant fin de semaine ? » et obtient une réponse fraîche, tirée du système en temps réel, pas d'un index vieux de trois jours. Gain estimé : plusieurs heures hebdomadaires de vérifications manuelles, et zéro promesse client erronée.

Pour un cabinet de services de 12 salariés

Autre exemple, un cabinet de conseil de 12 salariés qui croule sous les tickets internes. Un serveur MCP connecté à l'outil de ticketing permet à l'assistant de créer, prioriser et router les demandes. Là où le RAG ne pouvait que documenter la procédure, le MCP l'exécute. Combiné à un modèle souverain hébergé localement, l'ensemble respecte la confidentialité des dossiers clients — un impératif absolu pour les professions réglementées. Sur ces déploiements, notre objectif opérationnel est une mise en production en moins de six mois, en commençant par un périmètre restreint puis en élargissant. Les dispositifs de financement pour ce type de projet sont recensés dans notre hub aides, et le simulateur d'aides permet d'estimer votre reste à charge.

Sécurité, confidentialité et conformité au AI Act

Une implémentation « type IAPRO » ne se juge pas à ses fonctionnalités mais à ses garde-fous. Le protocole MCP intègre par conception plusieurs principes de sécurité que nous renforçons systématiquement.

Les principes de sécurité natifs

  • Consentement explicite de l'utilisateur : le modèle ne déclenche pas un outil sensible — écriture, envoi, suppression — sans validation. Le Host doit exposer clairement à l'utilisateur quelle action va être exécutée avant de la lancer.
  • Limitation de visibilité serveur : un serveur MCP n'a pas vocation à voir l'intégralité de la conversation. On restreint son horizon aux seules données nécessaires à l'outil appelé, ce qui limite drastiquement la surface d'exposition.
  • Gestion fine des permissions : chaque outil est cadré. Un serveur de lecture ne doit jamais pouvoir écrire ; les droits sont attribués au plus juste, principe de moindre privilège appliqué à la lettre.

L'articulation avec le Règlement (UE) 2024/1689

Sur le plan réglementaire, le MCP touche à un point sensible : quand votre IA agit sur des données réelles, la question de la responsabilité et de la traçabilité devient centrale. Les fournisseurs de modèles d'IA à usage général (GPAI) sont soumis à des obligations spécifiques depuis le 2 août 2025, notamment la documentation technique et la transparence, comme le rappellent les lignes directrices de la Commission européenne sur les GPAI. Le MCP ne modifie pas ces obligations, mais il facilite leur respect : en journalisant chaque appel d'outil, il produit nativement la traçabilité qu'exige une gouvernance sérieuse. Je ne détaille pas ici l'ensemble du dispositif du Règlement (UE) 2024/1689 — pour cadrer précisément vos obligations selon votre profil de risque, référez-vous au guide de conformité dédié aux PME.

Feuille de route pour une implémentation type IAPRO

Voici la méthode que nous appliquons, condensée en quatre étapes actionnables.

Étape 1 — Cartographier les silos de données prioritaires

On commence par lister les sources vivantes qui bloquent aujourd'hui vos usages IA : ERP, CRM, ticketing, bases métier. On priorise selon deux axes — fréquence d'accès et valeur du gain. Inutile de tout connecter d'emblée ; on cible le silo dont l'ouverture rapporte le plus vite.

Étape 2 — Choisir le serveur MCP

Open source ou propriétaire ? Notre biais assumé va à l'open source pour préserver la réversibilité et éviter le verrouillage fournisseur. Pour les données publiques, datagouv-mcp est directement réutilisable. Pour vos systèmes internes, on déploie ou on adapte un serveur open source plutôt que d'accepter un connecteur cloud fermé.

Étape 3 — Sélectionner le modèle souverain compatible

On branche un modèle hébergé localement — Mistral 7B, Llama 3 ou Qwen selon les besoins de raisonnement et les contraintes matérielles — via Ollama et une interface comme OpenWebUI. La compatibilité MCP de Mistral, déjà démontrée sur data.gouv.fr, garantit qu'on reste dans un périmètre souverain de bout en bout.

Étape 4 — Définir les Tools critiques

On identifie les fonctions à automatiser en priorité, en commençant systématiquement par la lecture avant d'ouvrir l'écriture. Chaque outil est documenté, testé, et assorti de ses permissions. On procède par itérations : un périmètre modulaire et évolutif vaut mieux qu'un big-bang ingérable. C'est cette approche progressive qui tient l'objectif des six mois.

FAQ — MCP Model Context Protocol

Quelle est la différence fondamentale entre le RAG et le MCP ?

Le RAG interroge une base de connaissances figée, indexée au moment de la construction : il est idéal pour des données statiques comme une doctrine juridique. Le MCP, lui, accède aux données au moment de la question (runtime) et peut exécuter des actions comme créer un ticket. Le RAG lit du passé indexé, le MCP agit sur le présent vivant. Ils sont complémentaires.

Pourquoi le MCP est-il considéré comme un standard ouvert par la Linux Foundation ?

Introduit par Anthropic fin 2024, le protocole a été confié à la Linux Foundation, fondation à but non lucratif qui gouverne des standards communs comme Linux ou Kubernetes. Cet hébergement garantit qu'aucun fournisseur unique ne contrôle le protocole, assurant sa neutralité, sa pérennité et sa compatibilité entre modèles concurrents — un gage de réversibilité essentiel pour les entreprises.

Peut-on utiliser le MCP avec des modèles d'IA locaux ou souverains comme Mistral ?

Oui, et c'est démontré en production. Le serveur MCP officiel de data.gouv.fr documente sa configuration avec Mistral, aux côtés de Claude et ChatGPT. Un modèle Mistral hébergé localement via Ollama peut donc interroger vos sources compatibles MCP sans qu'aucune donnée ne quitte votre infrastructure, ce qui en fait la brique idéale d'une architecture souveraine on-premise.

Quels sont les trois types de fonctionnalités qu'un serveur MCP peut exposer ?

Un serveur MCP expose trois piliers : les Resources (données contextuelles en lecture, comme un fichier ou une métadonnée), les Prompts (workflows pré-remplis guidant des tâches récurrentes) et les Tools (fonctions exécutables appelées dynamiquement par le modèle, comme rechercher un jeu de données ou créer un ticket). Cette structuration donne au modèle un contrat clair et sécurisable.

Comment le protocole MCP garantit-il la confidentialité des données utilisateur ?

Le MCP intègre le consentement explicite de l'utilisateur avant toute action sensible et limite la visibilité du serveur sur l'ensemble de la conversation : il ne voit que ce qui est nécessaire à l'outil appelé. Combiné à une gestion des permissions au moindre privilège et à un hébergement local des modèles, ce cadre restreint fortement la surface d'exposition des données.

Le serveur MCP de data.gouv.fr permet-il déjà d'écrire ou de modifier des données ?

Non, pas encore. À ce stade de l'expérimentation, le serveur datagouv-mcp fonctionne uniquement en lecture : il permet d'explorer et d'interroger les données publiques ouvertes, sans autoriser aucune modification. L'ANCT annonce l'ambition de tester à terme des capacités d'édition et de publication, mais avec prudence et en s'appuyant sur des modèles souverains.

Quels sont les gains de productivité attendus pour une PME en adoptant cette architecture ?

Les gains portent sur l'accès temps réel aux données métier et l'automatisation des tâches répétitives : consultation instantanée des stocks, gestion des tickets internes, accès rapide aux données projet. France Num rappelle que 58 % des dirigeants voient l'IA comme un enjeu de survie. Concrètement, nous visons une mise en production en moins de six mois avec un périmètre progressif et mesurable.

Comment le MCP s'inscrit-il dans le cadre réglementaire du AI Act européen ?

Le MCP ne crée pas d'obligation nouvelle mais facilite la conformité au Règlement (UE) 2024/1689. En journalisant chaque appel d'outil, il produit nativement la traçabilité attendue. Les fournisseurs de modèles à usage général restent soumis à leurs obligations de documentation et de transparence depuis le 2 août 2025. Pour cadrer votre profil de risque, consultez le guide de conformité dédié.

Est-il nécessaire de développer un serveur MCP pour chaque nouvelle source de données ?

Un serveur MCP par source suffit, et non par assistant. C'est l'inverse du modèle propriétaire : au lieu de multiplier les intégrations sur mesure (une par couple source-modèle), vous exposez chaque source une fois, et toutes les IA compatibles y accèdent. On passe d'une matrice N×M à une addition N+M, réduisant drastiquement le coût d'intégration.

Qu'est-ce que la fonction 'Sampling' dans le protocole MCP et quels sont ses risques ?

Le Sampling est une fonction avancée par laquelle un serveur MCP peut demander au modèle du Host de générer une complétion, inversant le flux habituel. Elle permet des workflows agentiques riches mais accroît la surface de risque : un serveur mal maîtrisé pourrait solliciter le modèle de façon non désirée. On l'encadre strictement par du consentement utilisateur et des permissions limitées, en désactivant cette capacité tant qu'elle n'est pas nécessaire.

Pour aller plus loin avec IAPRO

Le MCP n'est pas un gadget de laboratoire : c'est la couche d'interopérabilité qui transforme votre IA de bibliothécaire passive en agent actif, sans sacrifier votre souveraineté. Chez IAPRO, nous concevons des installations on-premise qui combinent RAG pour la connaissance et MCP pour l'action, autour de modèles souverains hébergés chez vous. Pour évaluer votre cas d'usage et bâtir une feuille de route sur mesure, contactez-nous : nous partons de vos silos de données réels, pas d'une démo générique.

Liens utiles