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, 80 % des entreprises citent les limites de leur data comme principal frein au déploiement d’IA agentique, selon le rapport McKinsey State of AI 2025. Pas le coût des modèles. Pas la résistance des équipes. 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, Le Chat de Mistral, Claude, Gemini) 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, Le Chat, Gemini ou Claude 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. Selon la documentation officielle d’Anthropic, un modèle haut de gamme accepte jusqu’à 100 pages de PDF par fichier, texte et visuels compris (graphiques, tableaux, images). Les autres acteurs majeurs ont des capacités équivalentes. 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. 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. Les principaux modèles haut de gamme acceptent désormais un million de tokens par requête en API, parfois deux millions chez Google. Concrètement : on peut injecter dans un seul appel l’équivalent de 75 000 lignes de code, ou plusieurs centaines de pages de documentation, ou tout un catalogue produit en une fois.

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. GPT-5.5 a doublé son tarif sur le long contexte récemment, et envoyer 800 000 tokens à chaque requête coûte cher, met du temps à répondre, et perd en précision sur des points fins noyés dans la masse. Le contexte long est utile quand la donnée est ciblée et la requête peu fréquente. Pour servir un agent qui répond mille fois par jour en production, le tarif d’une requête de 500 000 tokens devient rapidement prohibitif.

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 démocratisé 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.

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. La spécification officielle est ouverte et publiée sur modelcontextprotocol.io.

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, 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.

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. Avec quinze connecteurs branchés en même temps, c’est facilement 5 à 10 % de la fenêtre de contexte qui part dans la plomberie avant qu’une seule question soit posée. 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. Plus on multiplie les connecteurs actifs, plus l’agent peine aussi à choisir le bon outil au bon moment, 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. 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 spécifiques mais étroits : imposer un style ou un ton de marque très typé, contraindre fortement un format de sortie, spécialiser un modèle open source plus petit pour réduire les coûts d’inférence à grande échelle, apprendre un comportement métier particulier (classification fine, raisonnement structuré sur un domaine régulé). Ce sont des projets de spécialistes, à coût et risque non négligeables, qui ne se confondent pas avec un projet « rendre l’IA utile à mes équipes ». Pour ce dernier, les quatre méthodes traitées plus haut couvrent l’écrasante majorité des besoins.

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 : 70 % des entreprises qui réussissent leur scaling IA citent comme premier obstacle l’intégration de données dont la qualité, la gouvernance et la fraîcheur restent insuffisantes.

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 en 2026 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 », 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.