K-AI
FREN
Demander une démo
SolutionComment ça marcheImpactActualitésPartenaires
FREN
Demander une démo
← Toutes les actualités
Presse · 3 juillet 2026 · 10 min de lecture

Context engineering : pourquoi la compilation de contexte échoue si votre corpus documentaire ment

Context engineering : pourquoi la compilation de contexte échoue si votre corpus documentaire ment

Pinecone, Glean, Vectara, Sinequa déplacent le RAG vers la compilation de contexte. Aucun ne traite le cas où le corpus source est lui-même contradictoire.

Selon Pinecone, un agent IA d’entreprise passe aujourd’hui jusqu’à 85 % de son effort de calcul à récupérer de la connaissance plutôt qu’à raisonner dessus — et le taux de complétion de tâches plafonne à 50-60 % dans les déploiements agentiques actuels (Pinecone, 4 mai 2026). La réponse du marché, en cette première moitié de 2026, tient en deux mots : context engineering. Le problème n’est plus seulement de bien récupérer un document — c’est de compiler, pour chaque tâche d’agent, un contexte structuré et exploitable. Pinecone, Glean, Vectara et Sinequa y consacrent chacun un narratif produit distinct. Mais tous partagent un même point aveugle : ils supposent un corpus documentaire source cohérent. Quand ce n’est pas le cas, la compilation de contexte ne corrige rien — elle industrialise l’erreur.

Le nouveau vocabulaire qui déplace le débat RAG

Le retrieval-augmented generation classique — trouver les k passages les plus proches sémantiquement d’une requête — a longtemps été traité comme un problème d’algorithme de recherche. Le context engineering déplace la question : il ne s’agit plus de retrouver des chunks, mais de compiler, pour un agent et une tâche donnés, un ensemble structuré d’informations directement actionnables. Pinecone a formalisé cette bascule avec Nexus et KnowQL, un langage de requête déclaratif conçu pour que les agents interrogent des artefacts de connaissance déjà compilés plutôt que du texte brut (Pinecone). Glean parle de son côté d’un « system of context », combinant un graphe d’entreprise et un graphe personnel pour nourrir chaque requête (Glean, 10 mars 2026). Vectara, à l’inverse, alerte sur les limites des fenêtres de contexte longues : passer de 8 192 tokens en 2023 à plusieurs centaines de milliers aujourd’hui n’a pas résolu la fiabilité, les modèles continuant à se dégrader sur les tâches longues (Vectara). Sinequa, enfin, défend une orchestration de cinq types de retrieval (vectoriel, mot-clé, graphe, structuré, multimodal) comme condition d’un RAG agentique fiable (Sinequa).

Ces quatre approches sont réelles et documentées. Elles s’attaquent toutes à la même couche : ce qui se passe entre le corpus et le modèle. Aucune ne s’attaque à ce qui se passe avant — l’état du corpus lui-même.

Ce que ces approches font — et ce qu’elles ne font jamais

Il faut être précis sur ce point, car c’est un angle mort structurel plutôt qu’un oubli isolé. Glean, dans sa propre documentation, identifie quatre modes d’échec du contexte : le poisoning (informations incorrectes ou obsolètes intégrées au contexte), la distraction (trop de contenu non pertinent), la confusion (contenu superflu qui égare le raisonnement) et le clash (informations contradictoires dans le contexte assemblé) (Glean). Ces quatre modes existent bel et bien. Mais l’article qui les définit ne les traite jamais comme un problème de corpus source — il les traite comme un problème d’assemblage au moment de la requête, réglable par un meilleur système de retrieval.

C’est là que se situe le glissement. Le poisoning et le clash ne sont pas seulement des artefacts de mauvais assemblage : ils sont, dans une proportion significative de corpus d’entreprise, déjà présents dans les documents sources avant toute requête — versions contradictoires d’une même procédure, politiques obsolètes jamais archivées, définitions divergentes d’un même terme selon les directions métier. Un système de compilation de contexte, aussi sophistiqué soit-il, ne peut pas distinguer une contradiction légitime (deux politiques régionales différentes, à juste titre) d’une contradiction pathologique (une politique périmée qui traîne encore dans un répertoire partagé). Il compile ce qu’on lui donne.

Ce qui se passe quand le corpus source ment avant la compilation

Prenons le mécanisme au sérieux. Un compilateur de contexte comme KnowQL promet, selon Pinecone, jusqu’à 90 % de réduction de la consommation de tokens et un taux de complétion supérieur à 90 % — contre 50-60 % en RAG classique (Pinecone). Ce gain repose entièrement sur la qualité des artefacts de connaissance compilés en amont. Si le corpus source contient des versions concurrentes d’un même document, le compilateur doit soit les fusionner (au risque de produire un artefact incohérent), soit en choisir une arbitrairement (au risque de choisir la mauvaise), soit les exposer toutes (annulant le gain de compression qui justifiait la compilation). Dans les trois cas, le problème que le context engineering promettait de résoudre — l’agent qui se perd dans un contexte trop large ou contradictoire — revient par la porte de derrière, simplement déplacé en amont du pipeline plutôt que résolu.

Ce n’est pas une hypothèse théorique. Unstructured.io, partenaire d’ingestion cité directement par Pinecone dans son propre article sur Nexus, rappelle qu’environ 80 % de la connaissance d’une organisation reste non structurée et largement inaccessible aux agents — un chiffre qui remonte à une étude IDC relayée par l’éditeur (Unstructured.io, 9 juin 2026). Cette masse documentaire non structurée n’est pas seulement volumineuse : elle est, par nature, rarement gouvernée avec la même rigueur que les données structurées d’un entrepôt. C’est précisément le terrain sur lequel un compilateur de contexte, quelle que soit sa sophistication, hérite du passif documentaire de l’entreprise plutôt que de le corriger.

Sur les diagnostics de corpus menés par K-AI, la présence de documents dupliqués, de versions contradictoires ou de contenus obsolètes dans le périmètre exact soumis à un projet d’agent IA revient systématiquement comme la première cause identifiée de dérive — avant même les limites de l’architecture de retrieval choisie. L’ampleur varie fortement d’une organisation à l’autre selon la maturité de sa gouvernance documentaire ; ce n’est pas un chiffre unique généralisable, mais un constat récurrent d’un diagnostic à l’autre.

Le “context poisoning” et le cluster context engineering vus depuis la gouvernance documentaire

Le vocabulaire du context poisoning, du clash ou de la distraction décrit des symptômes observés au moment de l’inférence. Vu depuis la gouvernance documentaire, ces symptômes ont des causes largement identifiables et corrigeables en amont : absence de gestion de version documentaire, absence d’un owner métier clairement identifié par domaine de contenu, absence de mécanisme de détection de contradictions inter-documents, absence de traçabilité de fraîcheur. Ce ne sont pas des problèmes de modèle. Ce sont des problèmes de cycle de vie documentaire — la discipline que Squirro qualifie, dans un registre proche, d’« AI grounding » : le choix d’architecture qui détermine la fiabilité et l’auditabilité d’une IA d’entreprise davantage que le modèle ou l’interface (Squirro, 2 juillet 2026).

C’est le territoire qu’occupe la couche Neural Semantic Graph de K-AI : non pas un compilateur de contexte supplémentaire au moment de la requête, mais une couche de gouvernance sémantique en amont — détection de doublons, de contradictions inter-documents et d’obsolescence, avant que le corpus n’alimente un système de retrieval, un compilateur de contexte ou un agent. « Start Clean, Stay Clean » ne s’oppose pas au context engineering ; il en est la condition silencieuse, généralement absente du narratif produit des éditeurs qui vendent la couche de compilation.

Ce que ça change pour une équipe qui évalue Pinecone, LlamaIndex ou Glean

Pour une équipe DSI, CDO ou VP Innovation en train d’évaluer un compilateur de contexte ou une plateforme de « system of context », trois questions permettent de sortir du seul argumentaire produit :

Le fournisseur mesure-t-il la cohérence du corpus source avant compilation, ou seulement la pertinence du résultat compilé ? La plupart des benchmarks cités par les éditeurs de context engineering (taux de complétion, réduction de tokens, précision de récupération) évaluent la sortie du pipeline, jamais l’état du corpus en entrée. Un score de sortie excellent sur un corpus non audité ne dit rien sur sa robustesse une fois le corpus réel connecté.

Que se passe-t-il, concrètement, quand deux documents sources se contredisent ? La réponse révèle si le fournisseur a conçu un mécanisme de résolution de conflit ou s’il laisse simplement le modèle arbitrer au moment de la génération — ce qui revient à déplacer le hasard, pas à le supprimer.

Qui, dans l’organisation, est responsable de la qualité du corpus une fois le compilateur de contexte déployé ? Un compilateur de contexte est un outil ; il n’installe pas, par lui-même, une gouvernance documentaire continue. Sans owner métier ni processus de mise à jour, la dette documentaire se reconstitue au même rythme qu’avant, simplement masquée par la sophistication du pipeline en aval.

Foire aux questions

Qu’est-ce que le “context engineering” et en quoi diffère-t-il du prompt engineering ?

Le prompt engineering optimise la formulation d’une instruction envoyée à un modèle. Le context engineering va plus loin : il conçoit l’ensemble du contexte fourni à un agent pour une tâche donnée — documents pertinents, mémoire, historique, outils disponibles — en le structurant et en le compilant en amont plutôt qu’en espérant qu’un bon prompt compense un contexte mal assemblé. Glean définit ainsi quatre couches de contexte (contenu, structure, tâche, activité) qui doivent être orchestrées ensemble, pas seulement le texte de la requête.

Pourquoi un agent IA peut-il halluciner même avec un système de retrieval sophistiqué ?

Parce que le retrieval, même excellent, ne corrige pas un corpus source défaillant. Si les documents récupérés contiennent eux-mêmes des contradictions, des versions obsolètes ou des doublons, le modèle reçoit un contexte de mauvaise qualité et produit une réponse cohérente en apparence mais fondée sur des prémisses fausses. C’est un problème de qualité des données en amont, pas de capacité de récupération.

Quelle est la différence entre nettoyer un corpus documentaire et compiler du contexte pour un agent ?

Nettoyer un corpus consiste à détecter et résoudre les doublons, contradictions et obsolescences dans les documents sources, en amont de tout usage. Compiler du contexte consiste à assembler, pour une tâche d’agent précise, les informations jugées pertinentes issues de ce corpus. Le second dépend entièrement de la qualité du premier : compiler un contexte impeccable à partir d’un corpus contradictoire ne fait que rendre la contradiction plus difficile à repérer, pas moins présente.

Comment évaluer si des solutions comme Pinecone, LlamaIndex ou Glean résolvent le problème de qualité documentaire ou seulement le problème de retrieval ?

En examinant si leur documentation produit traite explicitement l’état du corpus source comme une variable de risque — et pas seulement la performance de récupération ou de compilation. La plupart de ces plateformes documentent des modes d’échec liés au contexte (comme le “context poisoning” chez Glean) sans détailler de mécanisme dédié pour les détecter et les corriger à la source. Une évaluation rigoureuse doit inclure un audit du corpus réel de l’organisation, pas uniquement un benchmark sur données de démonstration.

Qu’est-ce qu’un Neural Semantic Graph et en quoi diffère-t-il d’un knowledge graph classique ?

Un knowledge graph classique modélise des entités métier et leurs relations (comme l’Enterprise Graph de Glean). Le Neural Semantic Graph de K-AI s’applique en amont, à la structure et à la cohérence du corpus documentaire lui-même : il détecte les relations de similarité, de contradiction et de dépendance entre documents pour identifier doublons, versions concurrentes et incohérences sémantiques, avant que ce corpus n’alimente un système de retrieval ou un compilateur de contexte.

Pour aller plus loin

L’audit d’un corpus documentaire avant un projet d’agent IA — quel que soit le compilateur de contexte envisagé en aval — permet d’identifier ces angles morts avant qu’ils ne se traduisent en coûts de token, en incidents de confiance ou en dette de gouvernance. Pour évaluer où se situe votre organisation sur ces enjeux, contactez contact@k-ai.ai.

K-AI accompagne déjà CMA CGM, Veolia, PwC, BNP Paribas, TotalEnergies et CEVA Logistics. Partenaires : AWS, Snowflake, Microsoft, Wavestone, Devoteam.

Sources citées

Sur le même sujet

Et chez vous, quel est votre patrimoine documentaire ?

30 minutes avec un fondateur. On audite gratuitement un échantillon de vos documents et on vous montre exactement ce que K-AI détecte.

Demander une démo → Lire d’autres articles