Fédération plutôt qu'embeddings : laissez les agents IA interroger les données là où elles vivent

Avant de construire une infrastructure vectorielle, pensez à la fédération : des agents IA avec accès aux outils de vos systèmes existants. Pour la plupart des cas d’usage enterprise, c’est tout ce qu’il vous faut.

On vous a dit de pivoter vers l’IA. D’ajouter une couche IA. « On doit être IA-first. »

D’accord. Vous commencez donc à réfléchir : de quoi l’IA a-t-elle besoin ? Des données. Évidemment.

Le manuel s’écrit tout seul : centralisez les données, montez une base vectorielle, découpez en chunks, construisez un pipeline RAG, affinez peut-être un modèle. Puis interrogez-le. Livrez le chatbot. Déclarez victoire.

C’est ce que j’appelle la taxe de centralisation IANon pas le coût d’un data warehouse, souvent justifié. La taxe, c’est de construire une infrastructure de données parallèle spécifique à l’IA par-dessus ce que vous avez déjà : bases vectorielles, pipelines d’embedding, stratégies de découpage, modèles sur mesure. Toute une nouvelle couche, juste pour l’IA.

Vous en aurez peut-être besoin un jour, en partie. Mais probablement pas encore. Et probablement pas pour les cas d’usage que vous imaginez.

Vous avez déjà des systèmes qui stockent vos données : CRM, plateformes de support, systèmes de facturation, peut-être un data warehouse. La question n’est pas de savoir s’il faut centraliser les données (vous l’avez probablement déjà fait). La question est de savoir si l’IA a besoin de sa propre copie, transformée en embeddings, stockée dans encore une autre base.

La réponse est presque toujours non.

Si vous cherchez à vous différencier, à prouver vos unit economics, à garder une longueur d’avance sur vos concurrents, construire une infrastructure spécifique à l’IA avant d’avoir le moindre retour est une erreur stratégique. Vous créez un domaine de données parallèle pour des questions que vous n’avez pas encore validées.

Et voilà le piège : une fois que vous avez investi des mois à construire des pipelines d’embedding et une infrastructure vectorielle, pivoter est douloureux même quand de meilleures options émergent. Ce n’est pas seulement de la dette technique. C’est un verrouillage stratégique sur une architecture peut-être déjà obsolète.

Soyons directs

Quelqu’un demande : « Quel est l’état de santé de ce client ? »

Vous n’avez pas besoin d’un pipeline RAG pour ça. Ni d’une base vectorielle. Ni de votre propre modèle. Ni d’un data warehouse avec des mois de travail ETL.

Ce qu’il vous faut : un agent IA avec des capacités de tool calling et un bon modèle de fondation. C’est tout. Le reste, c’est de l’optimisation.

Un système IA agentique avec accès aux outils peut interroger votre CRM, récupérer les tickets de support récents, vérifier le statut de facturation et synthétiser une évaluation en quelques secondes, avec des données en temps réel, sans aucune infrastructure à construire ou maintenir.

Ce n’est pas théorique. C’est ce qui est possible dès maintenant avec MCP (Model Context Protocol) et les frameworks d’orchestration d’agents.

Si votre cas d’usage IA ressemble à « donne-moi des informations sur X dans nos systèmes », arrêtez. Ne sortez pas le manuel de la centralisation. Il existe un chemin plus rapide.

Le manuel de centralisation IA

Quatre approches, même piège : construire une infrastructure spécifique à l’IA au lieu de tirer parti de ce que vous avez déjà :

Pipelines RAG. Découpez vos documents en chunks, générez des embeddings, stockez-les dans une base vectorielle, récupérez les top-k correspondances, injectez-les dans le contexte. Ça marche pour « chatter avec votre PDF ». Ça s’effondre quand vous avez besoin de résultats structurés précis : demandez un comptage ou une agrégation, et vous obtenez des chiffres hallucés. Les équipes continuent d’optimiser les stratégies de découpage et les seuils de similarité en résolvant le mauvais problème.

Modèles fine-tunés sur mesure. Collectez des données d’entraînement, sélectionnez des exemples, lancez les jobs de fine-tuning, déployez, surveillez la dérive. Des semaines, voire des mois de travail. Au moment de livrer, les modèles de base ont progressé et votre fine-tune est déjà dépassé.

Data warehouses pour l’AI. Vous avez déjà Snowflake ou BigQuery pour l’analytics. Le manuel IA dit : construisez maintenant des couches sémantiques, créez des transformations spécifiques à l’IA, répliquez peut-être dans un vector store. Plus d’infrastructure, plus de maintenance, alors qu’un agent IA pourrait simplement interroger votre warehouse existant directement via tool calling.

Graphes de connaissance pour l’AI. Modélisez votre domaine sous forme d’entités et de relations, ingérez les données, construisez la logique de traversal. Des mois de travail, fragile quand les schémas changent, pour résoudre un problème que les systèmes agentiques avec outils gèrent souvent par le raisonnement.

Même pattern : supposer que l’IA a besoin de sa propre couche de données. Même problème : vous construisez une infrastructure parallèle au lieu de vous connecter à ce qui existe.

Fédération : l’alternative au RAG qui se livre

Une question plus simple : pourquoi l’IA aurait-elle besoin de sa propre copie des données ?

Si les agents IA peuvent raisonner, que les outils peuvent interroger des systèmes, et que les LLM peuvent synthétiser, les données peuvent rester là où elles vivent déjà. Interrogez au runtime. Synthétisez à la demande.

C’est la fédération. Plutôt que de copier les données dans une infrastructure spécifique à l’IA, donnez aux agents des outils pour interroger directement vos systèmes existants.

*Précision importante : Un warehouse Snowflake avec un serveur MCP, c’est de la fédération. Vous interrogez les données là où elles vivent. Le warehouse remplit son rôle, et les agents IA y accèdent directement sans avoir besoin d’une couche vectorielle par-dessus. La fédération n’est pas anti-warehouse, elle est anti-duplication.*

Ce qui rend ça viable aujourd’hui :

Capacités des modèles. Les LLM frontier gèrent le raisonnement multi-étapes et l’orchestration d’outils de façon fiable. Les fenêtres de contexte contiennent les résultats de plusieurs requêtes système. Les modèles font une synthèse qui aurait nécessité du code sur mesure il y a deux ans.

Standardisation des outils via MCP. Le Model Context Protocol s’est imposé comme le standard pour connecter les agents IA aux systèmes externes. Les principaux fournisseurs de modèles : Anthropic, OpenAI l’ont adopté. L’écosystème compte désormais des milliers d’intégrations prêtes à l’emploi : CRM, systèmes de support, plateformes de facturation, bases de données, outils développeurs. Et il existe des MCP runtimes qui gèrent les autorisations au moment de la requête, les agents s’authentifient en tant qu’utilisateur plutôt que de s’appuyer sur des comptes de service sur-privilégiés.

Frameworks d’agents. La couche d’orchestration a mûri. Le raisonnement chain-of-thought permet aux agents de se corriger et de converger vers les bonnes réponses. La gestion des erreurs qui nécessitait du code explicite est désormais un comportement émergent.

Trois patterns d’architecture pour agents IA

Chaque pattern s’appuie sur le précédent. Commencez simple, ajoutez de la complexité seulement quand vous atteignez les limites.

Pattern 1 : fédération simple avec tool calling

Le pattern fondamental. Un agent IA reçoit une requête, utilise le tool calling pour interroger les systèmes sources via des serveurs MCP, et synthétise la réponse.

Ne sous-estimez pas ça. Avec les LLM actuels, la fédération simple gère la plupart des requêtes « donne-moi des informations sur X » : vérifications de statut, recherches, investigation cross-systèmes, sans aucune infrastructure sur mesure.

L’insight clé : l’agent est la couche de jointure. Il raisonne entre les sources, gère les différences de schéma par compréhension sémantique, et synthétise des réponses cohérentes. Vous n’avez pas besoin de modéliser les relations à l’avance : l’agent les résout au moment de la requête.

Fonctionnement : L’agent maintient un état minimal, juste assez pour suivre la conversation et coordonner les appels d’outils MCP. Chaque requête frappe directement les systèmes sources, obtient des données fraîches, retourne les résultats. Les frameworks d’agents comme LangGraph offrent la persistance d’état et les checkpoints out of the box, ce qui vous emmène déjà très loin.

Adapté pour : Vérifications de statut, recherches, requêtes cross-systèmes, tâches de recherche. « Quel est l’état de santé d’Acme Corp ? » « Montre-moi les tickets récents de ce client. » « Quel est notre pipeline ce trimestre ? » « Compare l’historique support de ce client avec son statut de facturation. »

Limites : Ajoute de la latence (typiquement 2-5 secondes pour des requêtes multi-systèmes, en plus du temps d’inférence du modèle). Pas de mémoire persistante entre les sessions ; à mesure que davantage d’outils et de systèmes sont interrogés dans une session, le contexte grossit et la précision peut se dégrader.

Quand ça craque : Les requêtes nécessitant des calculs sur de grands datasets (agrégations sur des milliers d’enregistrements), les exigences de réponse en sous-seconde, ou les requêtes où la latence des API sources s’accumule de façon inacceptable.

Pattern 2 : fédération avec calcul éphémère

La fédération simple gère la plupart des requêtes. Mais certaines tâches nécessitent plus : agrégations complexes, transformations de données, jointures sur de grands ensembles de résultats, ou génération d’artefacts à partir des données récupérées.

Pour ces cas, ajoutez du calcul éphémère.

Fonctionnement : L’agent IA récupère les données via les outils MCP, puis lance un environnement de calcul temporaire et sandboxé où il peut exécuter du code, lancer du SQL contre des bases en mémoire, ou traiter les données de façon programmatique. Les résultats reviennent, le calcul se supprime. Des environnements sandboxés comme E2B sont conçus spécifiquement pour ce pattern.

Adapté pour : Jointures cross-systèmes sur des milliers d’enregistrements, agrégations complexes, génération de code à partir de données, assemblage de documents, scripts analytiques.

Limites : Orchestration plus complexe. Ajoute de la latence (temps de démarrage du calcul plus temps d’exécution). La logique de jointure elle-même peut être complexe quand les schémas ne s’alignent pas : vous écrivez du matching flou ou demandez à l’agent de raisonner sur la résolution d’entités.

Quand ça craque : Les datasets qui dépassent la mémoire disponible (typiquement 100 000+ enregistrements selon la largeur du schéma), les requêtes nécessitant des données historiques que les systèmes sources ne conservent pas, ou quand vous avez besoin de résultats mis en cache pour un accès répété.

Pattern 3 : IA agentique avec mémoire long terme

Ajoutez un contexte persistant qui s’accumule entre les sessions. L’agent IA fédère pour les données courantes, mais maintient aussi une mémoire des décisions, du contexte et des précédents.

Fonctionnement : Avant d’interroger les systèmes en direct, l’agent consulte la mémoire pour trouver l’historique pertinent. Il ne s’agit pas d’embedder l’intégralité de votre patrimoine de données, mais de persister le contexte généré par l’agent : décisions prises, précédents établis, préférences utilisateur apprises. Des couches mémoire comme Mem0 et Zep émergent pour résoudre ce problème.

La différence avec le RAG traditionnel : Vous stockez le contexte généré par l’agent, pas les documents sources bruts. C’est de l’intelligence accumulée à partir des interactions, pas des données répliquées. La mémoire est append-only et grandit organiquement à partir de l’usage réel.

Adapté pour : Aide à la décision avec précédents (« Doit-on approuver cette remise ? Qu’avons-nous fait pour des deals similaires ? »), expériences personnalisées qui s’améliorent dans le temps, pistes d’audit du raisonnement de l’agent.

Limites : L’architecture mémoire est encore en train de mûrir dans l’écosystème. Vous devez décider explicitement ce qui vaut la peine d’être persisté. La récupération en mémoire ajoute de la latence et peut faire remonter du contexte non pertinent.

Et les cas limites ?

« Et les incompatibilités de schémas ? » Quand le champ « Account » de Salesforce ne correspond pas au « Customer » de Stripe, c’est un problème SQL, pas un problème vectoriel. Un agent IA avec le contexte du schéma peut écrire des jointures qui gèrent les conventions de nommage et le matching flou. Ce qu’il vous faut, c’est un modèle capable et des outils MCP bien conçus, pas des embeddings.

« Et la recherche de clients similaires ? » Avant de vous tourner vers la similarité vectorielle, posez-vous la question : est-ce que le pattern matching SQL, les jointures et les filtres suffisent ? La plupart des cas de « similarité » sont structurels, pas sémantiques. Le raisonnement d’un agent avec des outils peut y arriver.

« Et la latence et les coûts API ? » Oui, l’inférence LLM coûte de l’argent. Comparez ça à trois mois d’investissement infrastructure avant d’avoir validé si le cas d’usage a de l’intérêt. Le coût du modèle est la façon la moins chère d’apprendre.

Quand vous avez vraiment besoin de la recherche vectorielle : Recherche sémantique sur de grands ensembles de documents non structurés où la recherche par mots-clés échoue. C’est là que le RAG brille. Construisez-le comme un outil isolé : un vector store exposé via MCP, pas comme une couche de données IA centralisée.

Le pattern : résoudre des problèmes isolés avec des outils isolés.

L’asymétrie qui compte

Vous aurez peut-être besoin d’un vector store pour la recherche sémantique sur des documents. Peut-être d’un modèle fine-tuné pour un langage spécifique à votre domaine. Peut-être d’embeddings pour de la vraie similarité à grande échelle.

Mais vous n’avez pas besoin de construire tout ça pour commencer à créer de la valeur.

C’est l’asymétrie. Vous pouvez toujours ajouter une infrastructure spécifique à l’IA plus tard : vector stores, modèles sur mesure, pipelines d’embedding pour les cas d’usage isolés qui en ont vraiment besoin. L’architecture tools-first l’accommode. Construisez le vector store quand vous avez prouvé que vous avez besoin de recherche sémantique. Fine-tunez un modèle quand les modèles de base s’avèrent clairement insuffisants.

Vous ne pouvez pas facilement faire l’inverse. Une fois que vous avez investi des mois dans des pipelines d’embedding et une infrastructure vectorielle, vous avez des équipes qui les maintiennent et des parties prenantes qui défendent l’investissement. Pivoter vers des approches plus simples basées sur des outils signifie une infrastructure abandonnée et des conversations difficiles sur les coûts irrécupérables.

Commencez avec les outils MCP. Livrez de la valeur en quelques jours. Ajoutez de la complexité seulement là où elle est méritée.

Si vous commencez par le manuel de centralisation IA ? Le temps que vous ayez construit les pipelines d’embedding et livré l’infrastructure vectorielle, les concurrents qui ont commencé avec des outils en sont à leur troisième itération. Ils ont validé ce que les utilisateurs veulent vraiment. Ils gagnent des parts de marché pendant que vous déboguez la précision de la récupération.

En deux mots

Vos données vivent quelque part : CRM, plateformes de support, systèmes de facturation, data warehouses. Les agents IA avec des outils MCP peuvent interroger ces systèmes directement et synthétiser des réponses en quelques secondes.

Incompatibilités de schémas ? Un agent avec du contexte peut les raisonner. Jointures cross-systèmes ? Calcul éphémère. Recherche de similarité ? Souvent juste du pattern matching SQL. Recherche sémantique sur des documents non structurés ? C’est là qu’un vector store gagne sa place : comme un outil MCP parmi d’autres, pas comme le fondement de votre architecture.

Le pattern qui fonctionne encore et encore : commencer par la fédération, livrer de la valeur rapidement, puis ajouter une infrastructure spécialisée seulement pour les problèmes spécifiques qui en ont vraiment besoin. Vector stores, modèles sur mesure, pipelines d’embedding : tout cela a sa place. Mais cette place est généralement plus étroite que ce que le manuel par défaut laisse entendre.

La plupart des cas d’usage IA enterprise sont des variantes de « donne-moi des informations sur X dans nos systèmes ». Pour ça, les agents et les outils suffisent. Les organisations qui livrent le plus vite l’ont compris.

Interrogez les données là où elles vivent. Ajoutez de la complexité seulement là où elle est méritée.