Le piège du RAG sans état : pourquoi l’architecture d’IA au moment de la requête montre ses limites

By Mirko Peters · 2026-08-13

Automatically translated with AI from the original post. Read the English original

Cover: Your Copilot Has No Memory — Why RAG Fails and LLM Wiki Fixes It

Bienvenue sur le blog ! Si vous suivez nos échanges podcast sur l’intelligence artificielle en entreprise, vous savez que nous prenons le temps d’aller au-delà de l’engouement initial pour les outils de productivité modernes. Lors d’une démonstration classique, des outils comme Microsoft Copilot peuvent paraître remarquablement intelligents. Ils trouvent un document de projet, résument une stratégie, extraient des informations de SharePoint et relient des éléments de contenu d’entreprise pour former une réponse convaincante. Mais derrière cette expérience utilisateur impressionnante se cache une limite architecturale fondamentale : la récupération n’est pas une mémoire. Copilot peut interroger le contenu de votre organisation, mais cela ne signifie pas qu’il a construit une compréhension durable de celle-ci. Dans cet article, nous allons examiner en détail le fonctionnement de la génération augmentée par récupération (RAG) afin de comprendre comment le découpage en fragments et les boucles de requêtes sans état empêchent l’IA de conserver le contexte accumulé au fil des interactions en entreprise. N’hésitez pas à écouter l’épisode podcast associé, Your Copilot Has No Memory — Why RAG Fails and LLM Wiki Fixes It, pour une analyse audio plus approfondie de ces concepts.

Copilot ne se souvient pas : il récupère

L’utilisation de Copilot crée une illusion importante. Lorsqu’il relie avec succès des informations provenant de Microsoft 365, on peut avoir l’impression que le système a appris quelque chose sur votre organisation. Pourtant, si vous posez plus tard une question similaire, le système peut produire un résultat différent, car il effectue une nouvelle opération de récupération au lieu de simplement restituer la compréhension qu’il avait établie auparavant. Cette distinction devient critique lorsque les organisations dépassent la simple synthèse et attendent de l’IA qu’elle appuie de véritables décisions.

Si des questions essentiellement identiques peuvent produire des réponses incohérentes selon les informations récupérées, les utilisateurs deviennent rapidement réticents à s’appuyer sur l’IA pour des travaux critiques pour l’activité. Le problème peut alors relever de l’adoption plutôt que de la simple technique. Les utilisateurs veulent de la prévisibilité : lorsqu’un assistant donne une réponse le lundi et une réponse contradictoire le jeudi, pour exactement la même requête, la confiance s’effrite rapidement.

Ce que fait réellement la génération augmentée par récupération

RAG signifie Retrieval-Augmented Generation, soit génération augmentée par récupération. De façon simplifiée, les documents de l’entreprise sont découpés en fragments, ces fragments sont représentés sous forme de vecteurs (embeddings), la question de l’utilisateur est transformée en une représentation comparable, et le système recherche les fragments sémantiquement pertinents. Les éléments les mieux classés sont ensuite fournis au modèle de langage comme contexte pour générer sa réponse.

Cette architecture est extrêmement utile. Elle permet à un grand modèle de langage de répondre à partir d’informations qui ne faisaient pas partie de ses données d’entraînement initiales, et offre un moyen concret d’ancrer les réponses de l’IA dans le contenu de l’entreprise. Elle impose toutefois une contrainte architecturale importante : le modèle reçoit des fragments sélectionnés pour la requête en cours, et non une représentation persistante complète des connaissances de l’organisation.

Le problème du découpage

Les connaissances d’entreprise existent rarement sous forme de paragraphes isolés. Un plan de projet peut contenir des dépendances réparties sur des dizaines de pages. Une stratégie peut renvoyer à une autre stratégie. Une architecture technique peut dépendre de décisions documentées des mois plus tôt dans des comptes rendus de réunion, des conversations Teams, des pages SharePoint et des documents de conception.

Le RAG traditionnel découpe ces sources en unités plus petites et détermine quels fragments semblent pertinents pour la question posée. Le modèle voit donc des éléments sélectionnés, sans comprendre nécessairement le document complet ni l’ensemble de ses relations. Pour une simple recherche d’information, cela peut fonctionner très bien. En revanche, dès que la question implique des relations, un contexte historique, des dépendances, des décisions accumulées ou un raisonnement sur de nombreuses sources, les limites deviennent beaucoup plus visibles.

Le piège du RAG sans état

Un workflow de récupération classique n'a aucune notion intrinsèque de connaissance déjà acquise. Une question est reçue, des informations sont récupérées, une réponse est générée, et le processus repart effectivement de zéro pour l'opération de récupération suivante. C'est précisément là que l'absence d'état du RAG'devient un obstacle majeur.

Les connaissances découvertes au cours d'une interaction ne deviennent pas automatiquement des connaissances durables de l'organisation, accessibles à chaque interaction future. Pour l'IA en entreprise, cette distinction est capitale. Les organisations n'ont pas simplement besoin d'une meilleure recherche. Elles ont de plus en plus besoin de systèmes capables de maintenir une compréhension structurée des projets, des processus, des stratégies, des technologies, des personnes, des décisions, des dépendances et des relations qui les unissent.

Rechercher des connaissances vs compiler des connaissances

C'est ce qui nous amène à l'idée d'architecture centrale que nous explorons dans notre dernière série audio : plutôt que de reconstruire sans cesse la connaissance organisationnelle au moment de la requête, et si l'IA compilait cette connaissance à l'avance ? Un LLM Wiki incarne ce changement de perspective.

Plutôt que de traiter chaque document de l'entreprise comme un nouvel ensemble de fragments en attente de récupération, l'intelligence artificielle peut synthétiser l'information en artefacts de connaissance structurés, qui représentent ce que l'organisation comprend actuellement. Le changement important ne réside pas simplement dans une nouvelle interface utilisateur. Il consiste à faire passer l'intelligence de la reconstruction au moment de la requête vers une synthèse persistante des connaissances.

Pourquoi un LLM Wiki change le modèle

Imaginez des milliers de documents décrivant le même produit, le même client, le même projet, la même stratégie ou la même architecture. Le RAG traditionnel attend une question, puis tente de localiser les fragments les plus susceptibles d'y répondre. Une approche LLM Wiki cherche au contraire à transformer en continu ces sources fragmentées en pages de connaissances cohérentes.

Les relations, décisions, définitions, dépendances, contextes historiques et sources de référence peuvent faire partie d'une représentation des connaissances maintenue à jour. Copilot ou un autre agent d'IA peut alors effectuer ses recherches dans une couche qui contient une compréhension organisationnelle synthétisée, plutôt que de tenter sans cesse de reconstituer cette compréhension à partir de documents bruts.

Du référentiel documentaire à la couche de connaissances

Cela modifie le rôle de systèmes tels que SharePoint. SharePoint peut continuer à servir de référentiel faisant autorité pour les documents, pages, stratégies, présentations, comptes rendus de réunion et contenus de collaboration. Mais le contenu brut de l'entreprise ne constitue pas automatiquement une connaissance organisationnelle exploitable.

Une couche de connaissances générée par l'IA peut se superposer à ces systèmes sources et transformer des informations éparses en une sorte de carte de l'organisation : des projets reliés à des décisions, des stratégies reliées à des processus, des systèmes reliés à leurs propriétaires, et des concepts reliés à leurs preuves à l'appui. L'objectif n'est pas d'éliminer les documents sources. Il s'agit de rendre explicites les relations qui y sont implicitement contenues.

Pourquoi de meilleurs prompts ne résolvent pas l'architecture

L'ingénierie des prompts peut améliorer la façon dont un LLM interprète le contexte récupéré, mais elle ne peut pas garantir que le bon contexte a été récupéré en premier lieu. Si la couche de récupération renvoie des fragments incomplets, passe à côté d'une dépendance importante ou remonte un document obsolète, même un excellent modèle raisonne sur un ensemble d'informations incomplet.

C'est pourquoi l'amélioration du seul modèle ne peut pas résoudre tous les problèmes de l'IA en entreprise. La qualité et la structure des connaissances fournies au modèle restent fondamentales. Aucune astuce de prompt ne peut corriger une architecture qui repose sur des résultats de recherche éphémères au lieu d'une mémoire structurée et persistante.

Le problème de gouvernance s'aggrave

Cette architecture comporte également un avertissement important. Si l'environnement SharePoint d'une organisation contient des stratégies obsolètes, de la documentation en double, des processus abandonnés, des instructions contradictoires ou des documents sans propriétaire clairement identifié, un LLM Wiki peut synthétiser ces mauvaises informations avec la même efficacité que les bonnes.

Le risque est que les connaissances synthétisées paraissent bien plus propres et plus fiables que ne le mérite le contenu sous-jacent. L'IA rend donc la gouvernance traditionnelle de l'information plus importante, et non moins importante. La propriété du contenu, la gestion de son cycle de vie, le contrôle de version, la rétention, les processus d'archivage, les sources faisant autorité, les métadonnées et des systèmes de référence clairement définis deviennent des composants fondamentaux de l'architecture de l'IA.

La préparation à l’IA commence par la qualité du contenu

Les organisations abordent souvent la préparation à Copilot comme un projet de licences, de sécurité, de déploiement ou de formation. Ces éléments comptent, mais l’environnement de connaissances sous-jacent n’est pas moins déterminant. Si personne ne sait quel document représente le processus en vigueur, l’IA ne peut pas, par magie, résoudre l’ambiguïté organisationnelle.

Si trois services tiennent à jour des versions contradictoires d’une stratégie, l’IA a hérité de trois versions de la vérité. Si une documentation obsolète reste indéfiniment consultable, elle demeure un matériau d’ancrage potentiel. L’IA d’entreprise met donc en lumière une dette de gestion des connaissances que les organisations pouvaient jusqu’alors ignorer.

Pourquoi la confiance détermine l’adoption de Copilot

Les conséquences techniques deviennent rapidement des conséquences métier. Les utilisateurs peuvent tolérer des incohérences occasionnelles lorsque l’IA sert à rédiger un courriel ou à résumer une réunion. Ils le tolèrent beaucoup moins lorsqu’on attend de l’IA qu’elle explique une stratégie, qu’elle accompagne des décisions client, qu’elle interprète l’état d’avancement d’un projet, qu’elle fournisse des informations de conformité ou qu’elle guide des processus opérationnels.

Dès lors que les utilisateurs constatent des réponses incohérentes à des questions importantes, ils reviennent fréquemment vers des experts humains de confiance et vers les processus manuels établis. C’est une raison majeure pour laquelle l’adoption de Copilot peut stagner après un déploiement apparemment réussi. La confiance devient donc une exigence d’architecture, et non simplement un indicateur d’adoption.

Conclusion

En résumé, si la génération augmentée par récupération (RAG) a donné à l’IA d’entreprise un moyen puissant d’exploiter des documents externes, ses boucles de requêtes sans état et les limites du découpage en fragments (chunking) font qu’elle est souvent loin d’une véritable mémoire organisationnelle. Sans compilation persistante des connaissances, des systèmes comme Copilot continueront à peiner sur la cohérence, les relations contextuelles profondes et la confiance des entreprises. Passer de dépôts de documents bruts à une couche de connaissances structurée et compilée, comme l’approche émergente du LLM Wiki, est la clé pour combler le fossé entre démonstrations spectaculaires et outils métier fiables. Pour approfondir ce sujet et écouter notre analyse complète sur la correction de la mémoire de l’IA d’entreprise, écoutez l’épisode intégral sur Your Copilot Has No Memory — Why RAG Fails and LLM Wiki Fixes It.