Alimenter une IA avec ses données : RAG, MCP ou contexte long ?

Vous avez ouvert ChatGPT, vous lui avez demandé de rédiger un compte-rendu sur l’un de vos clients. Et la réponse vous a rappelé pourquoi tout le monde dit que l’IA générative ne sait rien faire de précis : générique, à côté du sujet, sans aucun chiffre exact. Le coupable n’est pas le modèle. Le coupable, c’est que l’IA n’a aucune idée de qui est ce client. Vous lui avez parlé de votre métier comme on parle à un inconnu dans le métro.

Le sujet que personne n’aborde frontalement, c’est celui-là : comment on alimente une IA avec sa propre data. Pas comment on choisit entre Claude et ChatGPT. Pas comment on rédige un meilleur prompt. Comment on lui donne accès, au bon moment et au bon format, à ce que sait l’entreprise. Quatre méthodes existent aujourd’hui, elles ne servent pas aux mêmes besoins, et la plupart des projets IA qui échouent en cabinet ou en ETI échouent là.

Pourquoi votre IA ne sait rien de votre métier

Un grand modèle de langage est entraîné sur du texte public. Il connaît la doctrine fiscale française, les règles RGPD, les formes courantes d’un contrat de service. Il ne connaît ni votre grille tarifaire, ni votre dernier appel d’offres gagné, ni la procédure interne que vous avez mise au point en huit ans pour qualifier un prospect.

Cette absence est structurelle. Ce n’est pas un défaut qu’on règle avec une mise à jour. C’est la conséquence directe de la manière dont les modèles sont construits, et c’est ce qui rend le sujet de l’alimentation en données stratégique, pas technique. La question stratégique pour qui pilote un projet IA en 2026 n’est pas « quel modèle choisir », c’est « quelles données je lui rends accessibles, et comment ». Nous l’avions déjà observé sous un autre angle dans notre analyse sur la guerre des contextes : l’avantage compétitif en IA d’entreprise se déplace du modèle vers la data qu’on parvient à mettre derrière.

Et pourtant, selon le rapport McKinsey « Building the foundations for agentic AI at scale » (avril 2026), huit entreprises sur dix citent les limites de leurs données comme un frein au passage à l’échelle de l’IA agentique. Le blocage n’est pas d’abord dans le modèle. Il est dans la data.

Les quatre façons d’amener vos données à une IA

Il y a aujourd’hui quatre méthodes pour rendre votre data accessible à un grand modèle. Avant d’en lister le détail, une distinction préalable structure tout le reste : utilisez-vous l’IA via une interface conversationnelle (ChatGPT, Claude, Gemini, Vibe de Mistral, ex-Le Chat) ou via une API intégrée dans un workflow, un agent ou un produit ?

Dans le premier cas, la conversation porte la mémoire de la session : ce qu’on a chargé tout à l’heure reste accessible aux questions suivantes tant que la session est ouverte. Dans le second, chaque appel est par défaut isolé. Ce que le modèle voit, c’est exactement ce qu’on lui envoie à cet appel précis, rien de plus. Sa « mémoire » se vide entre deux requêtes, sauf si on a explicitement codé une persistance externe. La même donnée, par exemple un PDF de 30 pages, ne se manipule donc pas pareil selon le canal. C’est la première source de confusion sur le sujet, et la plupart des articles vulgarisateurs l’enjambent. Les quatre méthodes qui suivent prennent leur sens à partir de cette distinction.

Charger des fichiers dans la conversation

Vous prenez un fichier, vous le glissez dans la fenêtre de chat de votre outil habituel. ChatGPT, Claude, Gemini ou Vibe lisent le contenu et s’en servent pour répondre. Tant que la conversation reste ouverte, le fichier est porté par la session : vous pouvez enchaîner cinq questions dessus, le modèle continue d’y avoir accès. Pas de paramétrage, pas de projet IT, pas de coût supplémentaire au-delà de votre abonnement.

C’est la méthode la plus négligée par les articles techniques, et c’est pourtant celle qui suffit dans une majorité de cas opérationnels. Chez Claude, par exemple, un PDF de 100 pages au plus est lu en entier, texte et visuels compris (graphiques, tableaux, images) ; jusqu’à 1 000 pages, seul le texte est lu. Les plafonds varient d’un assistant à l’autre : vérifiez ceux du vôtre avant d’y verser un gros document. Pour un compte-rendu de réunion, une analyse de devis, une synthèse de trois rapports, c’est largement suffisant.

Limites réelles : le PDF reste accessible tant qu’on reste dans la même conversation, même après fermeture et réouverture de l’onglet. En revanche, il n’est pas automatiquement repris dans une nouvelle conversation, ni partagé entre collègues, sauf à passer par un « Projet » ou un espace partagé du produit. Dans Claude, ces Projets font d’ailleurs déjà du RAG à votre place : quand les documents approchent la limite de la fenêtre de contexte, le mode RAG s’active seul, sans réglage, et multiplie la capacité jusqu’à dix fois (offres payantes). Et le volume de la session reste contraint par la taille de la fenêtre de contexte. Quand on multiplie les fichiers, qu’on les met à jour régulièrement ou qu’on a besoin que toute une équipe interroge le même corpus, on bascule vite sur les méthodes qui suivent.

Le contexte long, pour développer une intégration

Quand on sort de l’usage interactif et qu’on développe un workflow, un agent ou un assistant qui appelle un modèle par API, la donne change. Chaque appel API est par défaut stateless : le modèle ne se souvient de rien d’un appel à l’autre. Ce qu’il voit, c’est ce qu’on lui envoie dans le prompt de cet appel, point. Le reste a disparu, comme s’il n’avait jamais existé.

C’est là qu’intervient le contexte long. Les fenêtres ont explosé en 2025, et fin octobre 2026 le million de tokens par requête est devenu la norme du haut de gamme : c’est le cas de toute la gamme Claude actuelle, de la famille GPT-6 d’OpenAI (1,05 million) et de Gemini 4 Argon chez Google. Concrètement : un million de tokens représente environ 555 000 mots selon Anthropic, soit plus d’un millier de pages de texte courant, ou tout un catalogue produit injecté en un seul appel.

C’est massif. Cela permet à un agent qui construit une réponse d’avoir, à chaque appel, l’intégralité du corpus dont il a besoin sous les yeux, sans avoir à le retrouver. On code un assistant qui rédige des notes commerciales dans le style maison ? À chaque appel, on re-injecte les cinquante notes précédentes en référence, et le modèle s’aligne automatiquement. À défaut, il faudrait ré-entraîner le modèle ou monter une mémoire externe.

Le piège, c’est le coût, et il a changé de forme. Chez Anthropic, toute la fenêtre d’un million de tokens est facturée au tarif normal, sans palier (sauf sur le petit modèle Haiku 5.5). Chez OpenAI, le tarif d’entrée double au-delà de 272 000 tokens, sur toute la requête. Dans les deux cas, envoyer un gros contexte à chaque appel reste cher. Un exemple au tarif de Claude Opus 5.5 (4 $ par million de tokens en entrée, constaté au 29/10/2026) : 800 000 tokens coûtent 3,20 $ par appel, soit 3 200 $ par jour pour un agent qui répond mille fois. La parade s’appelle la mise en cache du prompt : quand le même corpus revient d’un appel à l’autre, sa relecture depuis le cache est facturée 5 % du prix normal sur ce modèle, soit 0,16 $ par appel et un peu plus de 160 $ pour les mêmes mille appels, à condition qu’ils se suivent d’assez près pour que le cache reste actif (cinq minutes ou une heure selon l’option choisie). Restent deux limites que le cache ne règle pas : le temps de réponse sur un très gros prompt, et la précision sur un point fin noyé dans la masse. Le contexte long sert donc quand le corpus est ciblé, ou quand c’est toujours le même et qu’on le met en cache. Pour un agent qui doit puiser à chaque question dans un fonds documentaire volumineux et changeant, il ne remplace pas une recherche ciblée.

Le RAG : la mémoire externe à la demande

RAG (Retrieval-Augmented Generation, ou génération augmentée par récupération) est la méthode qui a popularisé l’idée d’une IA « qui connaît votre boîte ». Concept introduit dans un papier de recherche publié en 2020 par Lewis et al., c’est aujourd’hui le pattern le plus déployé en entreprise.

Le principe : vos documents sont découpés en morceaux, transformés en vecteurs numériques (des « embeddings » qui capturent le sens), et stockés dans une base spécialisée. Quand vous posez une question, le système cherche les morceaux les plus pertinents par similarité sémantique, les injecte dans le prompt, et le modèle répond en s’appuyant dessus.

L’avantage : un RAG passe à l’échelle. Vous pouvez y mettre des dizaines de milliers de documents, le coût par requête reste bas, et les données restent à jour si vous ré-indexez régulièrement. C’est la solution naturelle pour un assistant interne, un chatbot support qui s’appuie sur la documentation produit, ou un système qui répond à des questions répétitives sur un corpus volumineux.

Le coût : un RAG demande un effort de mise en place (choix de la base vectorielle, qualité du découpage, stratégie d’indexation), un budget infrastructure mensuel, et surtout une discipline de gouvernance documentaire qu’on sous-estime systématiquement. Le ticket d’entrée technique a toutefois baissé : OpenAI et Google proposent des RAG gérés par API (File Search), où l’on dépose ses fichiers et où découpage, vectorisation et recherche sont pris en charge. Chez Google, depuis novembre 2025, le stockage est gratuit : on paie l’indexation des documents, puis les passages retrouvés au tarif normal des tokens. Un premier prototype se monte alors en quelques jours. La gouvernance documentaire, elle, reste entièrement à votre charge.

Les connecteurs MCP : laisser l’IA aller chercher elle-même

MCP (Model Context Protocol) est le protocole standardisé proposé par Anthropic en novembre 2024 pour donner aux modèles un accès direct à des sources de données vivantes : votre Google Drive, votre base SQL, votre CRM, votre outil de tickets. Là où le RAG suppose que vous ayez préparé vos documents en amont, MCP permet à l’agent de demander ce dont il a besoin au moment où il en a besoin.

C’est la brique la plus récente, et probablement la plus structurante pour les années qui viennent. Nous avions déjà décortiqué pourquoi MCP change la donne : ce protocole transforme le modèle de « boîte qui répond » en « agent qui agit », capable de chercher dans Drive, lire un mail, créer un Jira, mettre à jour un CRM. Le protocole n’appartient plus à Anthropic : en décembre 2025, il a été confié à l’Agentic AI Foundation, une structure de la Linux Foundation cofondée par Anthropic, OpenAI et Block, avec le soutien de Google et Microsoft. On comptait alors plus de 10 000 serveurs MCP publics actifs, et ChatGPT, Gemini, Microsoft Copilot ou Visual Studio Code l’avaient adopté. La spécification est publique, sur modelcontextprotocol.io ; la version en vigueur date du 28 juillet 2026.

Le ticket d’entrée varie beaucoup selon la source. Pour les outils du quotidien (Google Drive, GitHub, Slack, Notion, Figma, Postgres), des connecteurs MCP publics existent déjà et se branchent en quelques minutes sur Claude, ChatGPT, Vibe de Mistral, Cursor ou n’importe quel client compatible. Le panneau des connecteurs prend la forme d’une liste avec des toggles : on coche Google Calendar, l’IA accède à votre agenda. On coche Fireflies, elle voit vos transcripts de réunion. C’est par là qu’on conseille d’expérimenter MCP la première fois, avant tout projet de développement.

Pour des sources internes spécifiques (ERP métier, CRM maison, application développée sur mesure), il faut développer le connecteur, ce qui se compte en semaines. Et quel que soit le cas, MCP demande une politique d’autorisation fine, parce qu’un agent qui a accès à tout peut faire des bêtises rapidement. La spécification prévoit bien une authentification standard (OAuth 2.1) pour les connecteurs distants, mais elle la laisse optionnelle : c’est à vous de l’exiger, avec des droits limités au strict nécessaire.

Reste un coût d’usage souvent passé sous silence. Chaque connecteur MCP actif charge dans le contexte du modèle son schéma d’outils et leurs descriptions. Selon la documentation d’Anthropic, cinq serveurs courants (GitHub, Slack, Sentry, Grafana, Splunk) consomment environ 55 000 tokens de descriptions avant le moindre travail. Chaque appel d’outil ajoute aussi une latence réseau, et les allers-retours s’accumulent dès qu’un agent enchaîne quatre ou cinq actions pour répondre. La même source situe entre 30 et 50 outils disponibles le seuil au-delà duquel le modèle choisit moins bien le bon outil, et le débuggage devient pénible quand un agent se perd entre douze sources possibles. Le retour terrain qui se confirme : commencer par tout connecter, puis désactiver progressivement ce qui ne sert que rarement. Côté développement, une parade existe désormais : le chargement des outils à la demande (« tool search »), qui ne charge que les trois à cinq outils utiles à la requête et réduit cette charge de plus de 85 %. Moins d’outils bien choisis battent toujours plus d’outils approximatifs.

Et le fine-tuning, alors ?

La cinquième voie historique pour spécialiser un modèle sur sa data, c’est le fine-tuning : on prend un modèle de base, on l’entraîne sur un corpus spécifique, et il en sort avec un comportement nouveau intégré dans ses poids. Pendant longtemps, c’était la méthode « noble » pour faire dire à une IA quelque chose qu’elle ne savait pas dire.

En 2026, le fine-tuning a perdu sa centralité pour la plupart des usages d’entreprise. Trois raisons. Le RAG fait nettement mieux pour injecter des connaissances factuelles à jour. Le contexte long absorbe les corpus de référence sans préparation préalable. Et MCP rend les sources vivantes accessibles sans réentraînement. Là où il fallait autrefois trois mois de fine-tuning pour qu’une IA comprenne votre catalogue produit, un RAG bien découpé fait l’affaire en deux semaines pour un coût marginal.

Le fine-tuning reste pertinent pour des cas étroits : imposer un ton de marque très typé, contraindre un format de sortie, spécialiser un petit modèle open source pour réduire les coûts d’inférence à grande échelle, apprendre une classification fine sur un domaine régulé. Ce sont des projets de spécialistes, à coût et risque non négligeables. Pour « rendre l’IA utile à mes équipes », les quatre méthodes traitées plus haut couvrent l’écrasante majorité des besoins. Et pour transmettre une procédure maison (votre méthode de qualification d’un prospect, la trame d’une note), une voie plus légère s’est imposée : les « skills », des dossiers d’instructions et de fichiers que l’agent charge seulement quand la tâche s’y prête. Publié par Anthropic en décembre 2025, ce standard ouvert a été intégré par plus de 70 plateformes d’agents, dont ChatGPT, Cursor et GitHub Copilot, et confié le 22 octobre 2026 à la même fondation que MCP.

Comment choisir, et pourquoi vous choisirez sans doute plusieurs

Présenter les quatre méthodes en parallèle laisse penser qu’il faudrait en choisir une. C’est faux. Sur le terrain, on en combine deux, trois, parfois les quatre, en affectant chaque type de donnée à la méthode la mieux adaptée. La bonne question n’est pas « RAG ou contexte long », c’est « qu’est-ce que je mets où ».

Cinq questions suffisent pour trancher le choix sur chaque type de donnée à exposer.

L’arbre que vous obtenez en répondant à ces cinq questions est presque toujours hybride. Un référentiel volumineux et croissant va dans un RAG. Quelques documents stables et invariants restent en upload direct ou en stockage référencé. Une base de données métier passe par un connecteur MCP. Un dossier ponctuel à analyser bénéficie du contexte long le temps d’une analyse. Vouloir tout faire avec une seule méthode, c’est gâcher.

Le cas BGT : un seul système d’AO combine les quatre méthodes

Sur les appels d’offres, nous avons déployé pour notre propre usage un système qui illustre exactement le pattern combinatoire. Le constat de départ : répondre à un AO prenait cinq jours de travail homme. Beaucoup de ce temps était passé à rechercher dans des AO précédents les mêmes paragraphes, à reformater les mêmes annexes, à reproduire les mêmes schémas d’architecture. La répétition était massive, mais aucune des quatre méthodes prise isolément n’aurait suffi.

L’architecture que nous avons mise en place repose sur un agent Claude Code en local, qui orchestre quatre couches de stockage :

• Une base vectorielle (RAG) contient les AO précédents (une trentaine aujourd’hui, voués à grandir) et les schémas d’architecture qu’on réutilise. C’est de la matière textuelle volumineuse, sur laquelle on cherche par similarité (« les passages où on parle d’authentification », « les architectures avec hébergement souverain »).
• Une base SQL stocke les images, illustrations et assets visuels avec leurs métadonnées. On y accède par référence, pas par recherche sémantique : un schéma de réseau a un identifiant, on le récupère au besoin.
• Un stockage de fichiers stables garde les documents qui ne changent jamais (RIB, KBIS, attestations URSSAF, références). Les mettre dans un RAG serait du gâchis : ces fichiers sont appelés par leur nom, pas par leur contenu.
• Des connecteurs MCP branchent l’agent sur les sources vivantes (notre dépôt de propositions, notre CRM client, notre Drive d’éléments graphiques en cours).

Le moteur agentique tourne dans Claude Code en local, alimenté par l’abonnement Max. Pas d’API à facturer au token, pas d’infra cloud à provisionner pour le prototype. Le coût marginal d’une réponse d’AO est devenu négligeable.

Le résultat opérationnel : on est passé de cinq jours à environ une journée et demie pour produire la même qualité de réponse. Les annexes administratives sont récupérées automatiquement. Les paragraphes méthodologiques sont reformulés à partir des AO similaires. Les schémas sont sortis du catalogue et adaptés. Le rédacteur humain reprend la main là où ça compte le plus : la lecture fine du cahier des charges et la formulation de la valeur spécifique pour ce client. Le reste, l’agent le fait.

Le point qui mérite d’être souligné : ce n’est pas le RAG seul qui produit le gain. Ce n’est pas non plus MCP seul. C’est l’orchestration des quatre couches par un agent qui sait quelle méthode appeler pour quel besoin.

Le piège ignoré : la qualité data conditionne tout

Tout ce qui précède suppose une chose qui n’a rien d’évident en pratique : des données utilisables. Et c’est précisément la conversation que les articles concurrents enjambent : aucune des quatre méthodes ne sauve une donnée mal préparée. C’est ce que dit clairement le rapport McKinsey cité plus haut : les données éparpillées et cloisonnées, qu’on parvenait jusqu’ici à contourner, deviennent ingérables à l’échelle, et une gouvernance inégale complique encore le contrôle des accès et la traçabilité.

Trois péchés capitaux reviennent presque toujours sur les projets que nous reprenons.

Structure cassée. Un fichier Excel financier conçu pour l’œil humain (cellules fusionnées, multi-niveaux d’en-tête, sous-totaux dispersés, notes en pied de page) est illisible pour un modèle. Le mettre tel quel dans un RAG ou en upload, c’est saturer le contexte avec du bruit, et obtenir des réponses qui inventent. La donnée a besoin d’une structure tabulaire propre avant tout traitement.

Contexte manquant. Un PDF nu (un compte-rendu de réunion sans en-tête, un devis sans nom de client, un email sans expéditeur) ne dit rien. Un humain qui retrouve ce fichier deux ans plus tard sait reconstituer le contexte par recoupement. Un modèle, non. Chaque document doit porter ses méta-données : qui, quand, sur quel sujet, pour quel client.

Mises à jour fantômes. Le RAG indexé en mars devient mensonger dès la première mise à jour de doctrine en avril si personne n’a programmé la ré-indexation. Le pire des biais en IA d’entreprise n’est pas l’erreur visible, c’est la réponse confiante qui s’appuie sur une version périmée.

Avant de toucher à RAG ou MCP, il faut donc un audit data élémentaire : ce qui est structuré, ce qui ne l’est pas, ce qui est à jour, ce qui ne l’est pas. Sans cet audit, n’importe quelle méthode produira des résultats médiocres. Avec, même un upload direct bien outillé donne des résultats remarquables. C’est ce que nous rappelions déjà sur le contexte qui fait l’agent, plus que le modèle.

Ce que ça veut dire pour votre projet IA

Si vous structurez aujourd’hui un projet IA dans votre organisation, deux postures sont à éviter. La première : tout mettre dans un RAG parce qu’on a vu un article qui en faisait la solution miracle. La seconde : penser que le contexte long à un million de tokens règle le problème de l’alimentation en données.

Trois questions à poser à un prestataire qui vous propose une architecture IA, dans cet ordre :

1. Quelle méthode pour quel type de donnée ? Si la réponse est « tout en RAG », il y a un problème de réflexion. Si c’est « tout en contexte long » sans mise en cache, il y a un problème de coût qui va se révéler en production.
2. Quel est le plan de ré-indexation et de mise à jour ? Une donnée intégrée une fois, c’est de la donnée morte dès la première évolution. Sans plan opérationnel, n’importe quelle architecture devient mensongère.
3. Quel audit data en amont ? Si on ne vous parle pas de la qualité, de la structure et du contexte de vos documents avant de parler RAG ou MCP, c’est qu’on commence par la fin.

Le sujet n’est pas sexy. Il est même résolument back-office. Mais c’est là que se joue l’écart entre les projets IA qui produisent et ceux qui restent au stade du démonstrateur. La data est le facteur limitant.