Trois mots qui sonnent pareil, trois catégories qui ne font pas le même métier. La grille de lecture qui sépare KM, Knowledge AI et DKP.

Knowledge AI, Knowledge Management, Document Knowledge Platform : démêler les 3 catégories avant de saboter votre projet IA d’entreprise

Une majorité de la connaissance utile d’une grande entreprise ne vit pas dans une base de données. Elle vit dans des PDF, des présentations, des notes Confluence, des e-mails, des comptes-rendus. Databricks chiffre à 80 % de la connaissance d’entreprise la part « fonctionnellement invisible », piégée dans des documents non-structurés que les pipelines analytiques classiques ne touchent pas (Databricks, 2026). Atlan documente une croissance du non-structuré de 40 à 60 % par an chez ses clients (Atlan, 2026). Et dans le même temps, trois mots se disputent sur le marché l’étiquette qui désignerait la solution : Knowledge Management, Knowledge AI, Document Knowledge Platform. Cinq éditeurs majeurs — Glean, Sinequa, Squirro, Writer, Workday/Sana — revendiquent tous l’un de ces termes dans leur communication des deux derniers mois. Aucun ne démêle vraiment ce qui les sépare.

Cette confusion n’est pas un détail sémantique. Quand un DSI ou un CDO achète « du Knowledge AI » en pensant régler le problème du corpus documentaire, il prend la mauvaise solution. Quand un Head of Knowledge Management se voit imposer « un Document Knowledge Platform » en pensant qu’on lui parle d’un nouveau Confluence, il rate le sujet. Cette note tente de poser une grille de lecture, en clarifiant qui fait quoi — et où K-AI s’inscrit, en sachant que nous ne sommes ni les premiers ni les seuls à occuper notre case.

Pourquoi trois mots qui sonnent pareil ne désignent pas la même chose

Le bruit ambiant vient de ce que ces trois catégories ont en commun la matière première : la connaissance documentaire d’une entreprise. Mais elles n’agissent pas sur la même couche, ne s’adressent pas aux mêmes commanditaires, et ne se mesurent pas avec les mêmes indicateurs.

Pour résumer la grille avant de la déplier : Knowledge Management est une discipline organisationnelle — un ensemble de pratiques et d’outils dont le but est que les humains d’une organisation accèdent à la bonne information au bon moment. Knowledge AI est une couche d’usage — un assistant ou un agent qui répond à une question, rédige un brief, exécute une tâche, en s’appuyant sur le corpus de l’entreprise. Document Knowledge Platform (DKP) est une couche amont — l’infrastructure qui rend le corpus exploitable par une IA : audit, dédoublonnage, détection de contradictions, marquage d’obsolescence, surveillance continue. Trois métiers. Trois lignes budgétaires. Trois fournisseurs différents quand l’organisation est mûre, parfois un seul quand elle débute — mais avec la conscience de ce qu’elle achète et de ce qu’elle n’achète pas.

Ce n’est pas une vue théorique. C’est exactement la grille que nous voyons s’imposer en RFP quand un grand groupe sérieux compare ses trois propositions concurrentes : « Quel besoin résout-on en premier ? Quelle couche est manquante ? À qui parle-t-on en interne ? »

Catégorie 1 — Knowledge Management : une discipline organisationnelle, pas une pile technique

Le Knowledge Management est l’ancêtre. C’est une discipline qui a structuré la gestion des connaissances en entreprise depuis les années 1990 — d’abord autour des intranets, puis des wikis (SharePoint, Confluence, Notion), puis des knowledge bases de service client (Document360, Zendesk Guide, Salesforce Knowledge). Sa mesure n’est pas un score de précision IA. C’est un taux d’usage, un temps de résolution de ticket, une réduction d’onboarding.

Le commanditaire d’un projet KM est rarement un CTO. C’est un Chief People Officer, un VP Customer Care, un Head of Knowledge Management, un Chief Operating Officer. Les outils du marché — Sinequa, Lucidworks, Atlassian Confluence, Document360 — ajoutent depuis trois ans une couche d’intelligence (recherche fédérée, suggestions de tag, résumés automatiques). Sinequa, par exemple, structure une partie de sa communication 2026 autour de la formule « Empowering Enterprise Knowledge Management with AI » (Sinequa, janvier 2026) et publie des métriques de retour sur investissement direct atteignant 21,7 % pour les projets unified information access (Sinequa, avril 2026).

Ce que le KM ne fait pas — et n’a jamais cherché à faire — c’est nettoyer le corpus en amont. Un Confluence dont la qualité documentaire est dégradée reste un Confluence. Le KM rend la connaissance trouvable et navigable ; il ne la rend pas cohérente, non contradictoire et à jour. C’est une discipline d’organisation et d’accès, pas une infrastructure de qualité.

Catégorie 2 — Knowledge AI : la couche d’usage qui répond aux questions

Le Knowledge AI est la catégorie qui émerge le plus vite depuis 2023 et qui se cristallise en 2026. Elle désigne la couche logicielle qui interprète une intention, formule une réponse en langage naturel, ou déclenche une action en s’appuyant sur le corpus de l’entreprise. Glean en est la figure la plus visible. L’éditeur s’est positionné comme une Work AI Platform, a annoncé en mai 2026 un AI coworker qui ne se contente plus de répondre mais exécute, et a publié le 12 mai un Enterprise Agent Development Lifecycle en sept étapes pour codifier la mise en production d’agents en entreprise (Glean, 12 mai 2026).

À côté de Glean, le territoire est encombré. Writer pousse son enterprise Knowledge Graph et son Control Panel, présentés comme la couche unique pour gouverner, sécuriser et passer à l’échelle les sources de connaissance (Writer, 2026). Squirro communique sur du GraphRAG qui revendique des précisions extrêmes en réponse à questions complexes (Squirro, 2026). Workday a racheté Sana Labs en novembre 2025 pour 1,1 milliard de dollars et le positionne comme la full AI platform for enterprise-wide knowledge, agents, and automation (Workday, 17 mars 2026). Microsoft Copilot, Notion AI, Atlassian Rovo occupent des cases adjacentes selon la verticale.

Le commanditaire d’un projet Knowledge AI est, lui, un acteur très différent : c’est un CTO, un Chief Innovation Officer, un Chief Digital Officer. Sa mesure est une adoption usage, un taux de réponse pertinente, un cost per task. Pinecone — qu’on a longtemps connu comme fournisseur de bases vectorielles — a publié le 5 mai 2026 un constat parlant en lançant son Nexus knowledge engine : 85 % de l’effort d’un agent passe en retrieval, et les pipelines RAG fragmentés font tomber le taux de complétion entre 50 et 60 % (Pinecone, 5 mai 2026). Autrement dit : un acteur que tout le monde rangeait dans l’infrastructure dit aujourd’hui que la couche d’usage IA ne suffit plus à elle seule, et qu’il faut composer la connaissance en amont. C’est le pont vers la troisième catégorie.

Catégorie 3 — Document Knowledge Platform : la couche amont qui rend le corpus AI-Ready

La Document Knowledge Platform (DKP) est la catégorie qui se cristallise en 2026 pour traiter ce que ni le KM ni le Knowledge AI ne traitent : l’état du corpus documentaire avant qu’une IA l’utilise. Le DKP audite, dédoublonne, détecte les contradictions, marque l’obsolescence, expose une couche sémantique exploitable par tout système IA en aval — chatbot, agent, copilot, search.

C’est la case dans laquelle nous nous inscrivons chez K-AI, et nous ne sommes pas seuls. Iris.ai parle d’AI knowledge foundation (Iris.ai, 2026). NetDocuments a annoncé le 5 mai 2026 son Legal Context Graph, dans la même logique mais verticalisée au juridique (LawNext, 5 mai 2026). Pryon pousse une variante sémantique avec AI memory. Côté data catalog, BigID et Atlan ont annoncé le 9 mars 2026 le first unified structured and unstructured data catalog for AI governance (BigID + Atlan, 9 mars 2026). Le mot platform n’est pas figé, mais le mouvement est sans ambiguïté : une catégorie nouvelle se forme entre l’IDP (extraction de documents) et le Knowledge AI (usage IA).

Chez K-AI, notre version du DKP s’articule autour de deux phases — Start Clean puis Stay Clean — et d’un Neural Semantic Graph qui matérialise les relations entre documents (et non un simple index vectoriel). Lors d’un premier diagnostic sur un seul référentiel documentaire d’une organisation cliente, nous détectons régulièrement plus d’un millier d’anomalies — procédures qui se contredisent, doublons divergents, informations obsolètes jamais retirées. Et ce référentiel n’est qu’un parmi d’autres dans l’organisation. C’est ce constat répété qui motive l’existence du DKP comme couche distincte.

Le commanditaire d’un projet DKP est, dans nos déploiements, un binôme CDO / Head of Knowledge Management, parfois un CIO en posture AI Readiness. La mesure n’est ni un taux d’usage, ni un cost per task : c’est une réduction mesurable du nombre de conflits, des doublons et des passages obsolètes dans le corpus, et une élévation de la précision des réponses générées par les couches IA aval. Sa promesse est que ces métriques d’amont conditionnent toutes les métriques d’aval.

Document Knowledge Platform : la transposition du Data Catalog et du Data Mesh au non-structuré

Pour un CDO ou un Chief Data Officer, la grille la plus directe est probablement celle-ci : un Document Knowledge Platform est au monde du document ce qu’un Data Catalog ou un Data Mesh est au monde structuré. Ce n’est pas une analogie commerciale, c’est une transposition de discipline. Un data catalog inventorie, classe, traque la lignée et applique des politiques sur des tables et des colonnes. Un DKP fait la même chose sur des paragraphes, des sections, des versions, des auteurs, des contradictions inter-documents — avec la spécificité que l’information utile n’est pas dans un schéma mais dans la phrase.

BigID et Atlan, avec leur unified data catalog du 9 mars 2026, ont fait le pas en posant que l’unstructured devait être adressé par les outils de gouvernance data. C’est un mouvement légitime. Mais il convient de distinguer deux gestes complémentaires : un catalog inventorie la donnée, en exposant ses métadonnées et sa lignée ; un DKP nettoie et maintient la donnée, en intervenant sur la matière même. Atlan le formule à sa manière dans un billet de référence : « l’unstructured n’est pas un problème de stockage, c’est un problème de lineage IA » (Atlan, 2026). Le DKP ajoute : « ni de stockage, ni seulement de lineage — c’est aussi un problème de qualité, qui se mesure et se traite en amont ».

Cette transposition n’est pas innocente côté budget. Là où le Knowledge AI est généralement porté par un budget innovation ou digital workplace, et le KM par un budget opérations ou RH, le DKP émarge naturellement sur le budget data et data governance, qui en 2026 reçoit l’investissement croissant de toutes les organisations sérieuses sur l’IA. Gartner observe que les organisations dont les initiatives IA réussissent investissent jusqu’à quatre fois plus, en pourcentage de revenu, dans les fondations data, gouvernance et AI-ready people, comparé à celles qui obtiennent des résultats médiocres (Gartner, 16 avril 2026). Le DKP est le mécanisme par lequel cet investissement amont produit du résultat aval.

Cinq erreurs catégorielles qui sabotent un projet IA d’entreprise

Démêler les catégories n’est pas un exercice doctrinal. Ce sont cinq erreurs très concrètes que nous voyons réapparaître chaque trimestre dans les RFP qui nous arrivent.

La première est d’acheter une couche Knowledge AI sans traiter en amont la qualité du corpus. C’est l’erreur la plus coûteuse parce qu’elle est la plus invisible : le projet réussit techniquement (l’assistant répond), mais les réponses sont fausses, incohérentes ou contradictoires. Les utilisateurs perdent confiance en six semaines. La couche Knowledge AI prend la facture commerciale d’un problème qui ne dépend pas d’elle.

La deuxième est de confondre KM SaaS et DKP. Un Confluence amélioré par une recherche IA n’est pas un DKP. Il devient trouvable, pas propre. La question utile en RFP : si je débranche votre couche IA, le corpus reste-t-il dans le même état ? Si oui, ce n’est pas un DKP.

La troisième est de penser que Microsoft Copilot ou Glean sont par construction un DKP parce qu’ils touchent au corpus. Ils sont la couche d’usage en aval. Pinecone, en parlant publiquement le 5 mai d’un retrieval qui consomme 85 % de l’effort d’un agent, dit en creux la même chose : on règle ces 85 % en amont, pas dans l’agent.

La quatrième est de prendre un data catalog unifié (BigID, Atlan, Collibra étendu au non-structuré) pour un DKP. C’est un mouvement légitime de la part des catalogs — mais inventorier n’est pas nettoyer. La complémentarité fonctionne très bien (le DKP alimente le catalog en métadonnées de qualité). La substitution, non.

La cinquième est plus subtile : confondre AI memory (Pryon) ou enterprise knowledge graph (Writer, Squirro) avec un DKP. Une memory est un composant utile ; un knowledge graph est une représentation. Aucun des deux ne traite, à lui seul, l’audit et le monitoring continu de la qualité du corpus. Un DKP peut, et chez K-AI doit, exposer un graphe sémantique — mais le graphe est l’output, pas la catégorie.

Bien composer la pile

Une fois la grille posée, l’architecture cible d’une organisation mature ressemble à ceci : un Document Knowledge Platform en amont, qui audite et entretient le corpus ; une couche Knowledge AI qui interroge ou agit sur ce corpus ; une discipline Knowledge Management qui gouverne le tout, structure les rôles humains, mesure l’adoption. Les trois couches ne s’achètent pas forcément en même temps, ni au même fournisseur. Mais elles se commandent dans cet ordre : si le DKP n’est pas en place, la couche Knowledge AI échouera, et le KM n’aura rien à faire monter en qualité.

Le pari de K-AI est de tenir la couche amont — c’est tout, et c’est le sujet le plus difficile. Nous laissons aux Glean, Sana, Writer et autres la couche d’usage IA, et aux Sinequa, Lucidworks, Confluence la couche KM. Notre conviction est que c’est l’absence du DKP qui fait basculer aujourd’hui la majorité des projets IA enterprise dans l’échec discret — ceux qui produisent une démo réussie et un déploiement décevant.

Foire aux questions (FAQ)

Quelle est la différence entre Knowledge AI et Knowledge Management ?

Le Knowledge Management est une discipline organisationnelle décennale, dont l’objet est de rendre la connaissance d’une entreprise accessible aux humains qui en ont besoin — via des wikis, des bases de connaissance support, des intranets, des outils de recherche fédérée. Le Knowledge AI est une couche logicielle plus récente qui ajoute une intelligence conversationnelle ou agentique au-dessus de cette connaissance : un assistant qui répond, qui rédige, qui exécute. Le KM mesure son succès par un taux d’usage, une réduction d’onboarding, un temps de résolution de ticket. Le Knowledge AI mesure son succès par une précision de réponse, un volume de tâches automatisées, un cost per task. Les deux coexistent et se complètent — mais ce sont deux métiers distincts qui ne s’achètent pas chez le même fournisseur, ne se mesurent pas avec les mêmes indicateurs et ne s’adressent pas au même commanditaire en interne.

Qu’est-ce qu’une Document Knowledge Platform et en quoi est-ce différent d’un Data Catalog ?

Une Document Knowledge Platform (DKP) est l’infrastructure qui rend un corpus documentaire utilisable par une IA : elle l’audite, élimine les doublons, détecte les contradictions inter-documents, marque les passages obsolètes, et expose une couche sémantique sur laquelle se branchent les systèmes IA aval. Un data catalog (Atlan, BigID, Collibra, Alation) inventorie la donnée, expose ses métadonnées, traque sa lignée et applique des politiques. Le geste est différent : un catalog inventorie et gouverne, un DKP nettoie et maintient. Les deux se complètent — un DKP de qualité alimente un catalog en métadonnées fiables — mais ils ne se substituent pas l’un à l’autre. L’annonce conjointe BigID + Atlan du 9 mars 2026 sur le unified structured & unstructured data catalog étend la couverture des catalogs au non-structuré, mais ne couvre pas l’opération de nettoyage proprement dite.

Pourquoi Copilot ou Glean ne trouve-t-il pas mes documents SharePoint ou les trouve-t-il mal ?

Plusieurs causes coexistent. Microsoft documente quatre raisons techniques classiques : permissions mal posées, indexation incomplète, scopes d’authentification mal configurés, taille de fichier au-dessus du seuil. Mais il existe une cinquième cause que les fournisseurs IA documentent rarement : le document est trouvé, mais il est inutilisable parce que le corpus est pollué. Deux versions d’une procédure se contredisent, un document obsolète n’a jamais été retiré, des doublons divergents existent côté SharePoint et côté Teams. L’assistant remonte alors un contenu trouvable mais faux, ce qui est pire que de ne rien remonter du tout. C’est ce que traite un Document Knowledge Platform en amont.

Comment évaluer la qualité de mon corpus avant un projet IA ?

Un audit corpus structuré mesure six axes : anomalies internes (ruptures de cohérence dans un même document), conflits inter-documents, doublons divergents, obsolescence non marquée, traçabilité (auteur, date, validation, source), fraîcheur par segment. Chacun de ces axes admet un KPI mesurable, un seuil d’alerte, et une procédure de remédiation. Nous décrivons la méthode K-AI en détail dans notre note de méthode du 15 mai. Le livrable type d’un premier audit est un rapport contextualisé par périmètre documentaire — pas un score global agrégé, qui masquerait les disparités entre référentiels.

Pourquoi une part importante des projets RAG n’atteint-elle pas la production ?

Plusieurs études convergent sur ce constat. Un billet de référence publié sur Medium en février 2026 trace 80 % des échecs RAG à la couche d’ingestion — duplicates qui gonflent les embeddings, stale records non détectés, métadonnées incohérentes (Medium, février 2026). Pinecone, le 5 mai 2026, mesure que 85 % de l’effort d’un agent passe en retrieval et que le taux de complétion plafonne entre 50 et 60 % sur des pipelines RAG fragmentés. Ces deux chiffres pointent dans la même direction : le verrou n’est pas le modèle, c’est la qualité de la couche en amont du modèle. C’est précisément l’objet d’un DKP.

Mon entreprise compte 1 000 à 10 000 collaborateurs et beaucoup de données non-structurées. Par quoi commencer ?

L’ordre recommandé est : (1) cadrer un périmètre documentaire pilote — généralement un référentiel critique (procédures qualité, base de connaissance support, documentation produit), (2) auditer ce périmètre sur les six axes décrits plus haut, (3) prioriser la remédiation sur les anomalies à fort impact métier, (4) brancher ensuite seulement la couche Knowledge AI (chatbot, copilot, agent). Cet ordre évite l’erreur la plus coûteuse — investir dans la couche d’usage avant d’avoir nettoyé la matière première. Sur un premier diagnostic sur un seul référentiel client, K-AI détecte régulièrement plus de 1 300 anomalies, et le volume documentaire chute en moyenne de 32 % en une semaine après nettoyage initial (doublons, documents obsolètes éliminés). Ce sont des chiffres qui ne valent que sur le périmètre audité, mais ils donnent l’ordre de grandeur d’un point de départ réaliste.

Faut-il acheter un DKP, un Knowledge AI et un KM séparément ?

Pas nécessairement. Une organisation qui débute peut acheter un acteur qui couvre plusieurs cases, à condition d’en avoir clairement conscience. La question utile en RFP est : cet acteur traite-t-il explicitement la qualité du corpus en amont, ou suppose-t-il que le corpus est déjà propre ? Si la réponse est « nous supposons que le corpus est propre », alors il s’agit d’un Knowledge AI seul, et la couche DKP reste à acquérir. Si la réponse est « nous audites et maintenons le corpus en amont, et exposons une couche sémantique consommable par les usages IA », alors l’acteur joue un rôle de DKP. La plupart des organisations matures finiront par séparer les couches pour des raisons de gouvernance, de cycle de vie et de spécialisation des fournisseurs.

Pour aller plus loin

Si vous êtes en train de cadrer un projet IA d’entreprise et que la question catégorielle s’est posée pendant votre dernière revue avec les achats ou la DSI, nous serons heureux d’en discuter. Vous pouvez nous écrire à contact@k-ai.ai. Le premier échange ne porte pas sur K-AI mais sur votre périmètre — c’est plus utile pour vous et pour nous.

Sources citées

Databricks Blog — PDFs to Production: Announcing state-of-the-art document intelligence on Databricks — 2026. databricks.com
Atlan — Unstructured Data Isn’t a Storage Problem. It’s an AI Lineage Problem. — 2026. atlan.com
Sinequa — Empowering Enterprise Knowledge Management with AI — 5 janvier 2026. sinequa.com
Sinequa — How to Measure Enterprise AI Search and Agentic AI ROI 2026 — 1 avril 2026. sinequa.com
Glean Press — Glean Introduces the Enterprise Agent Development Lifecycle — 12 mai 2026. glean.com
Writer — Starter guide: Graph-based RAG for enterprise — 2026. writer.com
Squirro Blog — Roadmap to Knowledge Graph-Powered GenAI — 2025-2026. squirro.com
Workday Newsroom — Introducing Sana from Workday: Superintelligence for Work — 17 mars 2026. workday.com
Pinecone Blog — Pinecone Nexus: The Knowledge Engine for Agents — 5 mai 2026. pinecone.io
PRNewswire — BigID & Atlan Introduce the First Unified Structured & Unstructured Data Catalog for AI Governance — 9 mars 2026. prnewswire.com
Gartner Newsroom — Gartner Says Organizations with Successful AI Initiatives Invest Up to Four Times More in Data and Analytics Foundations — 16 avril 2026. gartner.com
LawNext — NetDocuments unveils Legal Context Graph to map legal knowledge — 5 mai 2026. lawnext.com
A. Byakod, Medium — Why RAG Systems Fail in Production — Part 2 — février 2026. medium.com
Iris.ai — AI knowledge foundation for regulated enterprises. iris.ai

Knowledge AI, Knowledge Management, DKP : démêler les 3 catégories avant de saboter votre projet IA