2 Tout assistant d’IA d’entreprise vit ou meurt de ce qui se trouve derrière lui. Le modèle est la partie dont parlent les fournisseurs ; la base de connaissances d’entreprise pour l’IA est celle qui détermine si les réponses sont exactes, à jour et défendables. Il s’agit du système en couches qui rassemble les graphes de connaissances de l’entreprise, les sources de génération augmentée par récupération (RAG), la documentation interne et la longue traîne de contenus structurés et non structurés dispersés dans l’organisation — puis qui fournit la bonne portion de ces contenus à un modèle de langage à chaque appel d’inférence. Ce guide explique comment cette base de connaissances se construit de bout en bout : quelles sources de contenu l’alimentent, comment les contenus structurés et non structurés sont réconciliés, quelle est la place des graphes de connaissances d’entreprise, comment les sources RAG sont sélectionnées et actualisées, et sur quel socle de stockage repose l’ensemble de la pile. Qu’est-ce qu’une base de connaissances d’entreprise pour l’IA ? Une base de connaissances d’entreprise pour l’IA est le corpus organisé, indexé et actualisé en continu des connaissances de l’organisation, qu’un modèle de langage consulte au moment de l’inférence pour fonder ses réponses sur des contenus actuels et faisant autorité. C’est le socle de données et de récupération qui se trouve derrière le RAG, la recherche d’entreprise, les workflows agentiques, les copilotes et toute application dans laquelle un modèle doit raisonner sur des faits sur lesquels il n’a pas été entraîné. En ce sens, une base de connaissances n’est pas un référentiel unique. C’est une fédération. Les contenus sources résident dans des systèmes de gestion documentaire, des plateformes de ticketing, des hébergeurs de code, des plateformes de gestion de la relation client, des entrepôts de données, des sites SharePoint, des wikis, des intranets, des partages de fichiers, et dans l’inévitable lecteur partagé dont personne n’admet l’existence. Une partie de ces contenus est fortement structurée — lignes d’un entrepôt, champs d’un CRM, nœuds et arêtes d’un graphe de connaissances d’entreprise. La majorité est non structurée — PDF, présentations, contrats, transcriptions, fils d’e-mails, réunions enregistrées. Le rôle de l’architecture est de transformer cette fédération en une surface de récupération unique sans effacer les distinctions qui comptent. Une clause réglementaire n’a pas la même provenance qu’un message Slack. Une écriture du grand livre financier n’a pas les mêmes contrôles d’accès qu’une brochure marketing publique. La base de connaissances doit préserver ces distinctions, les associer sous forme de métadonnées dès l’ingestion et les conserver jusqu’au moment où une citation est présentée à un utilisateur. Pourquoi les bases de connaissances d’entreprise pour l’IA diffèrent de celles du grand public Un chatbot grand public construit sur une exploration du web public peut considérer son corpus comme à peu près homogène. Ce n’est pas le cas en entreprise. Quatre facteurs imposent une conception plus rigoureuse. La sensibilité. La documentation interne comprend des contrats, des dossiers du personnel, des données financières, des données clients et l’architecture de sécurité. La récupération doit respecter les contrôles d’accès existants ; un utilisateur qui interroge un copilote ne doit jamais voir un contenu qu’il ne pourrait pas ouvrir directement. La provenance. Chaque fragment récupéré doit être associé à sa source, sa version, son propriétaire, son horodatage, sa juridiction et sa classe de conservation. Sans cela, les citations ne sont pas auditables et les régulateurs ne sont pas satisfaits. Le volume. Une grande entreprise type compte des dizaines de millions de documents sources et des milliards de fragments après prétraitement, avec des écritures continues issues de flux de capture des modifications (change data capture). Le socle doit absorber ce volume sans obliger les équipes à transiger sur la latence ou sur les coûts. L’hétérogénéité. Les enregistrements structurés, les documents non structurés et les relations du graphe doivent tous pouvoir être interrogés dans un même appel de récupération. Un index purement vectoriel masque la structure ; une base purement relationnelle masque la similarité sémantique. Les systèmes de production hybrident les approches. Ces quatre conditions façonnent tous les choix de conception en aval — de la façon dont les sources de contenu sont connectées à la manière dont le graphe de connaissances d’entreprise s’articule avec le corpus documentaire, jusqu’à la façon dont la couche de récupération fusionne les résultats entre modalités. Les sources de contenu qui alimentent la base de connaissances La première question de conception porte sur la couverture des sources. Une base de connaissances de production puise généralement dans six familles de contenus sources. Les référentiels documentaires. SharePoint, Confluence, Google Drive, Box, Notion. L’essentiel des connaissances non structurées de l’entreprise se trouve ici : politiques, procédures d’exploitation, documentation produit, spécifications de conception, documents du conseil d’administration. Les systèmes de ticketing et de support. Jira, ServiceNow, Zendesk, Salesforce Service Cloud. Les tickets conservent la mémoire institutionnelle de la manière dont les problèmes ont été diagnostiqués et résolus, exactement ce qu’un copilote de support doit pouvoir récupérer. Les hébergeurs de code. GitHub, GitLab, Bitbucket. Code source, fichiers README, registres de décisions d’architecture, discussions de pull requests. Essentiels pour les copilotes d’ingénierie et pour les revues de conformité de ce que l’organisation livre réellement. Les archives de communication. E-mails, Slack, Teams, réunions enregistrées avec leurs transcriptions. La couche non structurée où se trouvent souvent le contexte, les décisions et le raisonnement. La sensibilité y est maximale ; les contrôles d’accès doivent être irréprochables. Les systèmes de référence structurés. Entrepôts de données, CRM, ERP, SIRH. Des tables, des champs et des relations plutôt que de la prose. La couche de récupération les traite différemment des documents : requêtes tenant compte du schéma plutôt que recherche par similarité. Les contenus externes faisant autorité. Réglementations, normes, documentation des fournisseurs, études de marché sous licence. Intégrés via des connecteurs sous licence ou des robots d’exploration contrôlés, avec un suivi de la provenance pour respecter les conditions de licence. Une architecture de production expose chaque famille de sources au moyen d’un connecteur dédié, qui gère l’extraction des formats, l’authentification, les mises à jour incrémentielles et la capture de la provenance. Les connecteurs écrivent leurs résultats dans une archive source durable sur un stockage objet optimisé pour la capacité, qui devient la copie unique et reconstructible à partir de laquelle chaque index en aval est recréé. Structuré, non structuré et graphe de connaissances d’entreprise La partie la plus difficile de la conception de ce type de base de connaissances consiste à réconcilier le monde structuré et le monde non structuré. Trois modèles dominent. La récupération centrée sur le non structuré Les documents sont découpés en fragments, convertis en embeddings et servis par un index hybride vectoriel et par mots-clés. Les enregistrements structurés sont aplatis en texte — « Client 4711 : niveau Platinum, renouvellement le 30/09/2026, responsable de compte Maria Schultz » — et indexés aux côtés des documents. Simple à mettre en œuvre, faible sur les requêtes relationnelles, mais c’est le modèle de production dominant aujourd’hui. La récupération centrée sur le graphe de connaissances Un graphe de connaissances d’entreprise encode les entités (personnes, produits, clients, contrats, systèmes) et les relations qui les unissent. Les requêtes parcourent le graphe et renvoient le sous-graphe environnant comme contexte. Excellent pour les questions relationnelles et de conformité, mais plus difficile à faire évoluer vers des requêtes libres en langage naturel, car le graphe ne peut pas répondre à ce que son schéma ne contient pas. La récupération hybride sur un socle graphe et documents C’est l’approche de niveau production. Le graphe de connaissances d’entreprise indexe les entités et les relations ; les documents non structurés sont reliés au graphe par des références d’entités (un nœud de contrat pointe vers son PDF, un nœud de compte vers les tickets de support qui le concernent, un nœud de décision d’architecture vers les commits de code qu’il a influencés). La récupération effectue d’abord un parcours du graphe, rassemble les documents liés, puis exécute la récupération vectorielle et par mots-clés sur cet ensemble filtré. Le graphe restreint l’espace de recherche ; le corpus documentaire fournit la prose que le modèle doit lire. C’est vers la récupération hybride que se tournent la plupart des entreprises après qu’un premier déploiement RAG naïf s’est heurté à ses limites sur les requêtes relationnelles. C’est aussi là que le socle de stockage compte le plus : le stockage du graphe, celui des fragments, celui des embeddings et la couche de métadonnées doivent tous évoluer indépendamment et rester cohérents malgré des écritures continues. Pour la conception appliquée de la récupération, l’article architecture d’une base de connaissances pour l’IA : guide de conception complet (en anglais) traite en profondeur la partie fragments et embeddings. Les sources RAG, la fraîcheur et le problème des changements Les sources RAG sont le sous-ensemble de la base de connaissances que la récupération expose réellement au modèle. Leur sélection est un choix de conception, et non une option par défaut. Un déploiement naïf indexe toutes les sources connectées en espérant que le classement fasse le tri. Les déploiements de production font une sélection. Ils définissent quelles sources font autorité pour quels types de questions, associent des métadonnées de priorité des sources afin que le moteur de récupération puisse pondérer davantage les contenus faisant autorité, et excluent les sources qui contiennent des informations obsolètes ou en double. Cette sélection fait la différence entre un copilote qui cite la politique en vigueur et un autre qui cite un brouillon vieux de cinq ans parce qu’il s’est mieux classé en similarité lexicale. La fraîcheur est la discipline complémentaire. Une base de connaissances qui n’est pas actualisée produit en toute confiance des réponses périmées. Trois modèles de fraîcheur sont couramment utilisés. La réindexation planifiée. Des reconstructions complètes ou incrémentielles périodiques, à un rythme quotidien ou hebdomadaire. Simple, prévisible, lente à refléter les changements. L’ingestion par capture des modifications. Les systèmes sources émettent des événements de modification ; le pipeline d’ingestion écrit les objets nouveaux et mis à jour dans l’archive source, et le découpage, les embeddings et les mises à jour du graphe en aval suivent le flux de modifications. La fraîcheur hybride. Une couche dynamique des changements récents coexiste avec l’index principal. La récupération consulte les deux ; cette couche est fusionnée dans l’index principal à intervalles réguliers. Chaque modèle impose des exigences différentes au socle de stockage. La capture des modifications et la fraîcheur hybride exigent des charges de travail simultanées d’écriture et de lecture, sans verrouillage ni dégradation des performances des requêtes. Le choix dépend du degré d’obsolescence acceptable des réponses : quelques minutes pour le support d’une salle de marchés, quelques heures pour le service client, quelques jours pour la recherche en conformité. Les exigences de stockage de la base de connaissances Une façon utile d’aborder l’architecture consiste à associer chaque couche à son profil de stockage. CoucheSchéma d’accèsExigence de latenceProfil de stockageArchive sourceÉcritures par rafales, lectures raresDe quelques secondes à quelques minutesObjet optimisé pour la capacitéStockage des fragmentsLectures intensives lors des reconstructionsQuelques secondesObjetStockage des embeddingsLectures très concurrentes lors des reconstructionsQuelques secondesObjetGraphe de connaissances d’entrepriseSuivi de pointeurs, parcoursQuelques millisecondesBase de graphe sur flashIndex vectoriel (chaud)Lectures aléatoires, en mémoire ou sur flashMoins d’une millisecondeFlash / NVMeIndex par mots-clésLectures aléatoires, principalement en cacheMoins d’une millisecondeFlashCouche de métadonnéesFiltrage et récupération à la requêteQuelques millisecondesService de métadonnées indexéArchive de conservationLectures rares, conservation réglementaireQuelques minutesObjet optimisé pour la capacité ou bande Un système de stockage unique optimisé pour une couche dessert mal les autres. Les équipes qui exécutent toute la pile sur un NAS généraliste ou un seul bucket cloud se heurtent systématiquement soit à des dépassements de coûts (surprovisionnement de flash pour des données d’archive), soit à des violations de latence (lectures d’index passant par des disques rotatifs). Une architecture hiérarchisée qui associe le type de support au schéma d’accès est la norme en production. L’article le stockage hiérarchisé pour l’IA : performances évolutives et maîtrise des coûts (en anglais) traite le sujet plus largement, et les pipelines de contexte pour l’IA : architecture, étapes et flux décrit le flux de récupération de bout en bout. Questions fréquentes Qu’est-ce qu’une base de connaissances d’entreprise pour l’IA ? Une base de connaissances d’entreprise pour l’IA est le corpus organisé, indexé et actualisé en continu qu’un modèle de langage consulte au moment de l’inférence pour fonder ses réponses sur des contenus actuels et faisant autorité de l’organisation. Elle fédère des sources structurées et non structurées — référentiels documentaires, systèmes de ticketing, hébergeurs de code, archives de communication, entrepôts de données, graphes de connaissances d’entreprise et contenus externes sous licence — au moyen de connecteurs qui capturent la provenance et les contrôles d’accès. L’architecture expose cette fédération comme une surface de récupération unique grâce à une récupération hybride vectorielle, par mots-clés, par graphe et par métadonnées. Quelle est la place d’un graphe de connaissances d’entreprise ? Un graphe de connaissances d’entreprise encode les entités (clients, produits, contrats, systèmes, personnes) et les relations qui les unissent. Dans une conception de récupération hybride, le graphe restreint l’espace de recherche — une requête parcourt d’abord le graphe pour trouver le sous-graphe pertinent — et les documents non structurés reliés au graphe fournissent la prose que lit le modèle de langage. La récupération centrée sur le graphe traite des questions relationnelles et de conformité qu’un index purement vectoriel ne peut pas traiter, et la récupération documentaire et vectorielle traite des questions libres en langage naturel que le schéma du graphe ne couvre pas. La plupart des systèmes de production utilisent les deux ensemble. Que sont les sources RAG dans une base de connaissances d’entreprise ? Les sources RAG sont le sous-ensemble des systèmes connectés et des collections de contenus que la récupération expose réellement au modèle. Leur sélection relève d’une discipline de curation : les équipes définissent quelles sources font autorité pour quels types de questions, associent des métadonnées de priorité afin que le moteur de récupération puisse les pondérer, et excluent les collections obsolètes ou en double. Une curation rigoureuse des sources fait la différence entre un copilote qui cite la politique en vigueur et un autre qui cite un brouillon vieux de cinq ans. Comment combine-t-on données structurées et non structurées ? Trois modèles dominent. La récupération centrée sur le non structuré aplatit les enregistrements structurés en texte et les sert par le même index vectoriel et par mots-clés que les documents. La récupération centrée sur le graphe de connaissances parcourt un graphe d’entités et de relations et renvoie le sous-graphe environnant. La récupération hybride sur un socle graphe et documents relie les documents non structurés au graphe par des références d’entités et effectue un parcours du graphe suivi d’une récupération documentaire. C’est vers la récupération hybride que se tournent la plupart des entreprises lorsqu’un premier déploiement naïf atteint ses limites sur les requêtes relationnelles. De quel stockage une base de connaissances d’entreprise pour l’IA a-t-elle besoin ? Le socle doit comprendre un stockage objet durable pour l’archive source, le stockage des fragments et les embeddings persistés ; un niveau chaud à faible latence pour les index vectoriels et par mots-clés ; une base de graphe offrant une latence de parcours de l’ordre de la milliseconde ; une couche de métadonnées capable d’évoluer jusqu’à des milliards de lignes pour les requêtes de filtrage et de récupération ; des lectures très concurrentes pour alimenter les workers d’embeddings et les constructeurs d’index ; ainsi que l’immuabilité et l’audit pour les environnements réglementés. Un stockage hiérarchisé sous un espace de noms unique, avec un cycle de vie piloté par des politiques, est la norme en production. Comment fonctionne la fraîcheur dans une base de connaissances d’entreprise pour l’IA ? Trois modèles de fraîcheur dominent. La réindexation planifiée s’exécute chaque jour ou chaque semaine ; elle est simple mais lente à refléter les changements. L’ingestion par capture des modifications écrit les mises à jour dans l’archive source au fil de l’eau et alimente le découpage, les embeddings et les mises à jour du graphe à partir du flux de modifications. La fraîcheur hybride maintient une couche dynamique des changements récents à côté de l’index principal et les fusionne à intervalles réguliers. Le choix dépend du degré d’obsolescence acceptable des réponses et de la charge simultanée d’ingestion et de requêtes que le socle de stockage peut absorber. Pour aller plus loin Architecture d’une base de connaissances pour l’IA : guide de conception complet (en anglais) Les pipelines de contexte pour l’IA : architecture, étapes et flux La génération augmentée par récupération et le stockage pour l’IA (en anglais) Le stockage pour bases de données vectorielles (en anglais) La gestion des métadonnées pour la génération augmentée par récupération (en anglais) Le stockage hiérarchisé pour l’IA : performances évolutives et maîtrise des coûts (en anglais) L’infrastructure de stockage pour l’IA agentique (en anglais) Les pipelines de données d’IA (en anglais) Conclusion Une base de connaissances d’entreprise pour l’IA ne se définit ni par le modèle qui la lit ni par l’index vectoriel qui la sert. Elle se définit par la cohérence avec laquelle fonctionnent ensemble les connecteurs de sources, les couches structurées et non structurées, le graphe de connaissances d’entreprise, les sources RAG, la récupération et la fraîcheur — et par la capacité du socle de stockage sous-jacent à porter à grande échelle l’archive source, les embeddings, le graphe et les métadonnées. Construisez les couches avec soin, et choisissez le socle avec le même soin, car c’est là que ces systèmes réussissent ou échouent sans bruit.
