Les entreprises ne manquent pas de données. Elles en possèdent souvent trop, sans savoir quelle version est exacte, encore valide ou accessible à quel collaborateur. En connectant des assistants et des agents IA à ce patrimoine informationnel, elles découvrent que des années de doublons, de documents abandonnés et de règles implicites ont rendu une partie de leurs données inexploitable par une machine.
Les entreprises ont passé des années à accumuler des données dans des CRM, des ERP, des espaces SharePoint, des data lakes, des messageries, des outils métiers et des dossiers personnels. Cette masse devait devenir le carburant de leurs futurs assistants et agents IA.
Le branchement de l’IA sur ce patrimoine produit pourtant une mauvaise surprise. Selon une étude menée auprès de plus de 230 décideurs impliqués dans les stratégies de données IA, publiée en mars 2026 par Cloudera et Harvard Business Review Analytic Services, seules 7 % des organisations estiment que leurs données sont totalement prêtes pour l’IA. Plus d’un quart les considèrent au contraire comme peu ou pas du tout prêtes.
Les silos et les difficultés d’intégration arrivent en tête des obstacles, devant l’absence de stratégie et les problèmes de qualité. Le rapport de Cloudera et Harvard Business Review Analytic Services montre également que 73 % des répondants jugent difficile la préparation des données pour l’IA.
Le décalage est frappant. Dans son rapport State of AI in the Enterprise 2026, Deloitte observe que 42 % des entreprises interrogées se disent très bien préparées sur le plan stratégique. Leur confiance est cependant plus faible concernant l’infrastructure technique et la gestion des données.
Un prototype peut fonctionner avec quelques documents soigneusement sélectionnés. La production l’expose ensuite aux systèmes historiques, aux contrôles de sécurité, aux cas particuliers et aux opérations de maintenance.
La question n’est donc plus seulement de choisir un modèle, une plateforme cloud ou une architecture RAG. Elle consiste à déterminer quelles informations l’IA peut croire, à quelle date, dans quel contexte et pour quel utilisateur.
L’IA révèle ce que les humains corrigeaient en silence
Un salarié expérimenté ne consulte pas les données de l’entreprise comme une machine. Il sait que le fichier intitulé « Tarifs clients final V7 corrigé » est probablement plus fiable que celui simplement nommé « Tarifs clients final ».
Il connaît le dossier partagé qui n’est plus utilisé, le collègue qui maintient encore son propre tableau et la procédure officielle qui n’a jamais remplacé l’ancienne version dans les résultats de recherche.
Il peut aussi repérer qu’un chiffre semble anormal, comprendre qu’un document concerne seulement la filiale française ou interpréter le sens d’un acronyme grâce à son expérience. Ces corrections ne sont généralement ni écrites ni modélisées. Elles restent dans les habitudes, les conversations et la mémoire des équipes.
Une IA d’entreprise ne bénéficie pas spontanément de cette connaissance implicite. Dans une architecture de Retrieval-Augmented Generation, ou RAG, le système recherche des passages pertinents dans les documents internes avant de les transmettre au modèle de langage.
Cette technique, présentée dans notre dossier sur le fonctionnement du RAG, améliore l’ancrage factuel des réponses. Elle ne décide toutefois pas automatiquement si un document est officiel, périmé ou réservé à une autre équipe.
L’IA peut même aggraver la perception du problème. Une mauvaise recherche classique affiche plusieurs fichiers et laisse l’utilisateur trancher. Un assistant génératif fusionne ces sources dans une réponse fluide. L’incertitude documentaire disparaît de l’interface, mais pas des données.
| Ce que l’entreprise croit posséder | Ce que l’IA peut réellement recevoir |
|---|---|
| Une procédure interne | Trois versions, dont deux périmées |
| Un fichier client | Plusieurs enregistrements correspondant à la même personne |
| Un chiffre d’affaires | Des définitions différentes selon la finance et le commerce |
| Des documents sécurisés | Des droits impossibles à reproduire dans l’index IA |
| Une base de connaissances | Des fichiers sans propriétaire, date de validité ou statut |
| Un référentiel produit | Des données différentes entre ERP, site web et support |
Cette distinction explique pourquoi la qualité des données devient beaucoup plus visible avec l’IA. Une donnée peut être lisible et utile pour un humain tout en restant inutilisable pour un agent automatisé.
Le doublon devient une fausse preuve
Un doublon n’est pas toujours une copie strictement identique. Deux présentations commerciales peuvent partager 95 % de leur contenu, avec un tarif ou une condition contractuelle modifié. Un document peut exister dans SharePoint, dans une pièce jointe, dans un dossier réseau et dans l’espace personnel de son auteur.
Lors de l’indexation, ces documents sont découpés en fragments, puis transformés en représentations numériques appelées embeddings. Si plusieurs copies similaires restent présentes, elles peuvent occuper plusieurs places parmi les résultats les mieux classés.
Le système ne voit alors pas seulement une information répétée. Il peut interpréter cette répétition comme un signal de pertinence. Une ancienne règle citée dans quatre copies peut prendre le dessus sur la nouvelle version présente dans un seul document.
La documentation d’Azure Databricks sur la création d’un pipeline RAG recommande donc explicitement d’extraire les métadonnées, de filtrer les documents inutiles et d’éliminer les doublons ou quasi-doublons.
Elle souligne aussi que la conservation de la bonne version doit s’appuyer sur des critères tels que la date de mise à jour, le statut de publication ou le niveau d’autorité de la source. Le guide technique de Microsoft évoque notamment l’utilisation de techniques comme MinHash pour détecter les contenus très proches.
Le problème existe également dans les données structurées. Un client peut être enregistré sous plusieurs noms, adresses ou identifiants dans le CRM, le logiciel de facturation et la plateforme e-commerce.
Le Master Data Management, ou MDM, vise à rapprocher ces enregistrements pour constituer une version de référence. IBM parle de « golden record », un enregistrement maître partagé par les différents systèmes. La présentation du MDM par IBM décrit cette lutte contre la fragmentation, les incohérences et les duplications.
LeBigData.fr consacre également un guide complet au Master Data Management et à la gestion des données de référence.
Les doublons ont enfin un coût d’infrastructure. Chaque copie peut générer de nouveaux embeddings, augmenter le volume de l’index vectoriel, rallonger les opérations de synchronisation et introduire davantage de fragments dans le contexte transmis au modèle.
L’entreprise paie donc pour stocker, traiter et interroger plusieurs fois une information qui n’a parfois qu’une seule valeur métier.
Il ne s’agit pas pour autant de supprimer tout historique. Une ancienne version peut rester nécessaire pour un audit ou un litige. Elle doit simplement porter un statut clair, être exclue des réponses courantes et rester accessible uniquement lorsque la question exige une recherche historique.
Les vieux documents continuent de répondre
Une procédure périmée ne disparaît pas parce qu’une nouvelle version a été publiée. Elle reste souvent dans les moteurs de recherche, les sauvegardes, les dossiers d’équipes et les index vectoriels.
La recherche sémantique accentue le risque. Elle classe les passages selon leur proximité avec la question, pas seulement selon leur date. Un ancien document très bien rédigé peut donc être jugé plus pertinent qu’une courte note de mise à jour récente.
Prenons un assistant destiné au support client. L’entreprise modifie sa politique de remboursement, mais l’ancienne procédure reste dans trois dossiers. La nouvelle version n’explique que les changements. Lorsqu’un client pose une question générale, le système retrouve le document historique, plus complet, et fournit une réponse devenue incorrecte.
Écrire « version finale » dans le nom du fichier ne suffit pas. L’index doit disposer de métadonnées exploitables :
- date de publication et de dernière révision ;
- date d’entrée en vigueur et date de fin de validité ;
- statut brouillon, approuvé, archivé ou retiré ;
- propriétaire responsable de la révision ;
- identifiant du document remplacé ;
- fréquence attendue de contrôle.
Ces informations doivent aussi déclencher des actions. La documentation d’Amazon Bedrock précise qu’une base de connaissances doit être resynchronisée lorsque des fichiers sont ajoutés, modifiés ou supprimés.
Le service réanalyse alors le document, recrée ses fragments et actualise ses embeddings. Un document supprimé de la source peut également être retiré du stockage vectoriel. La documentation d’AWS sur la synchronisation des sources montre que la fraîcheur dépend d’un pipeline opérationnel, pas d’une importation réalisée une seule fois.
Microsoft recommande de son côté de mettre à jour ou reconstruire les index afin d’éviter que l’inférence continue de s’appuyer sur des données périmées. Son guide d’architecture sur les données d’ancrage insiste également sur le nettoyage des incohérences, la standardisation des schémas et la prise en compte des attentes de fraîcheur des utilisateurs.
Une base RAG n’est pas une bibliothèque statique. C’est un produit de données qui doit être surveillé, révisé et maintenu.
Les droits d’accès peuvent faire fuiter la vérité
Connecter une IA à toutes les données de l’entreprise crée un dilemme.
Si l’index contient peu de sources, l’assistant reste prudent mais décevant. S’il contient l’ensemble des documents, il risque de retrouver des contrats confidentiels, des dossiers RH, des informations juridiques ou des données réservées à la direction.
Les droits présents dans le système d’origine doivent donc suivre chaque document jusqu’à l’index, puis être vérifiés au moment de la requête.
Microsoft appelle ce mécanisme le document-level access control. Azure AI Search peut associer les documents à des utilisateurs, groupes ou rôles, puis filtrer les résultats selon l’identité de la personne qui interroge l’assistant.
Les métadonnées de permissions et les étiquettes de sensibilité peuvent également être évaluées pendant la recherche. La documentation Microsoft sur le contrôle d’accès documentaire présente plusieurs approches adaptées aux architectures RAG et aux agents IA.
Sans cette continuité, deux erreurs opposées apparaissent.
La première est la sur-exposition. L’IA restitue une information que l’utilisateur n’aurait jamais trouvée ou ouverte directement.
La seconde est la sous-exposition. Pour éviter toute fuite, l’entreprise exclut tellement de sources que l’assistant perd son intérêt métier.
Une enquête Komprise réalisée en avril 2025 auprès de 200 responsables IT de grandes entreprises américaines illustre le danger. Près de 80 % déclaraient avoir déjà subi un incident lié aux données et à l’IA générative.
Les réponses fausses ou imprécises et les fuites d’informations sensibles figuraient parmi les problèmes les plus cités. Comme il s’agit d’une étude produite par un fournisseur, ces résultats doivent être lus avec prudence. L’enquête Komprise sur les données et l’IA détaille sa méthodologie et ses résultats.
La sécurité doit être conçue avant l’indexation :
- identifier les propriétaires et les catégories de sensibilité ;
- récupérer les listes de contrôle d’accès ;
- conserver ces permissions dans les métadonnées ;
- appliquer un filtrage lié à l’identité lors de chaque recherche ;
- journaliser les sources consultées et les réponses produites ;
- tester le système avec des utilisateurs de métiers et de niveaux différents.
Dans certains environnements, les contraintes de souveraineté obligent également à séparer les index, les régions cloud ou les entités juridiques.
Cette fragmentation augmente les coûts d’orchestration et peut réduire la pertinence des recherches transversales. Elle évite néanmoins qu’un projet IA contourne les règles de localisation et de cloisonnement déjà imposées aux données.
Sans métadonnées, le contexte métier disparaît
Une IA peut lire le contenu d’un fichier sans comprendre sa place dans l’entreprise.
Un tableau intitulé customers.csv ne précise pas s’il regroupe les clients facturés, les utilisateurs inscrits, les prospects ou les comptes actifs. Une colonne revenue ne dit pas si elle contient un chiffre hors taxes, toutes taxes comprises, facturé, encaissé ou annualisé.
Les métadonnées décrivent les données. Elles indiquent notamment leur origine, leur propriétaire, leur domaine métier, leur niveau de confidentialité, leur format, leur langue et les règles permettant de les interpréter.
Pour l’IA, elles servent aussi de filtres. Un agent peut rechercher uniquement les procédures approuvées, les documents applicables en France, les données mises à jour depuis moins de six mois ou les informations accessibles au groupe de l’utilisateur.
Le Data Catalog regroupe traditionnellement ces métadonnées afin d’aider les équipes à découvrir et comprendre les actifs disponibles.
L’arrivée des agents transforme toutefois son rôle. Il ne doit plus seulement permettre à un analyste de trouver une table. Il doit fournir à une machine le contexte nécessaire pour choisir la bonne source.
Google a illustré cette évolution avec son Knowledge Catalog, annoncé en avril 2026. La plateforme agrège des métadonnées techniques et métier, rapproche des définitions conflictuelles et construit un graphe de contexte utilisable par les agents.
Elle peut également enrichir les fichiers non structurés et associer des règles métier vérifiées aux requêtes. L’annonce officielle de Google Cloud présente l’agrégation, l’enrichissement et la recherche comme les trois piliers du système.
Nous avons détaillé cette évolution dans notre article sur le Knowledge Catalog de Google Cloud.
Un socle minimal de métadonnées pour l’IA devrait comprendre :
| Métadonnée | Question à laquelle elle répond |
|---|---|
| Propriétaire | Qui peut confirmer ou corriger cette information ? |
| Source d’autorité | Quel système doit être cru en cas de conflit ? |
| Date de validité | Cette information est-elle encore applicable ? |
| Statut | Le document est-il approuvé ou seulement préparatoire ? |
| Périmètre | À quel pays, produit, service ou population s’applique-t-il ? |
| Sensibilité | Qui a le droit de consulter le contenu ? |
| Lignée | D’où vient la donnée et quelles transformations a-t-elle subies ? |
| Identifiant canonique | S’agit-il d’une copie ou d’un actif distinct ? |
Sans ces attributs, un modèle peut comprendre les mots tout en se trompant sur leur signification opérationnelle.
Deux chiffres vrais peuvent se contredire
Les données contradictoires ne sont pas toujours fausses.
Le département commercial peut définir un client actif comme une entreprise ayant signé un contrat dans les douze derniers mois. La finance peut exiger une facture payée. Le support peut comptabiliser tout compte ayant ouvert un ticket récent.
Les trois chiffres répondent à des questions différentes. Le problème apparaît lorsqu’ils portent tous le même nom dans les tableaux de bord, les fichiers et les conversations.
Une IA interrogée sur le « nombre de clients actifs » peut retrouver les trois définitions, les mélanger ou choisir celle qui ressemble le plus à la formulation de la question.
Elle n’a aucun moyen fiable de savoir quelle définition doit être utilisée pour un comité financier, une campagne marketing ou une analyse du support.
La résolution passe par une couche sémantique. Celle-ci décrit les indicateurs, leurs formules, leurs dimensions, leur fréquence d’actualisation et leur domaine de validité. Les termes métier sont regroupés dans un glossaire partagé.
La lignée des données, ou data lineage, complète ce travail. Elle permet de retracer une valeur depuis sa source jusqu’au rapport, au tableau ou à l’agent qui la consomme.
Databricks présente par exemple la lignée comme un moyen d’analyser l’impact d’une modification, d’identifier l’origine d’un résultat inattendu et de suivre la circulation des informations sensibles. La documentation Unity Catalog sur la lignée des données détaille ces usages.
L’IA peut aider à repérer deux définitions proches, détecter des écarts ou proposer un rapprochement. Elle ne peut pas décider seule si la finance ou le commerce possède la définition officielle.
Choisir la vérité de référence reste une décision de gouvernance.
Cette distinction explique pourquoi une politique de gouvernance des données ne se limite pas à la conformité. Elle attribue des responsabilités et définit les règles permettant aux humains comme aux machines d’utiliser les données avec le même sens.
Tout nettoyer serait le mauvais projet
Face au désordre, la réaction instinctive consiste à lancer un immense programme de nettoyage. Cette approche peut durer plusieurs années sans produire d’assistant utilisable.
Toutes les données n’ont pas besoin d’être préparées immédiatement. Une IA chargée d’aider le support technique n’a pas besoin de l’ensemble des archives financières. Un agent destiné aux achats ne doit pas attendre la remise en état complète du CRM marketing.
La priorité doit partir du cas d’usage :
- quelles décisions l’IA doit-elle éclairer ou exécuter ?
- quelles questions les utilisateurs poseront-ils ?
- quelles erreurs seraient simplement gênantes ?
- lesquelles pourraient entraîner une fuite, une perte financière ou une décision réglementée ?
- quelles sources sont nécessaires pour répondre correctement ?
Les données peuvent ensuite être réparties en quatre groupes.
Les sources d’autorité sont validées, maintenues et utilisées par défaut.
Les sources contextuelles apportent des informations utiles, mais ne peuvent pas trancher seules une décision.
Les archives restent consultables pour les demandes historiques, sans apparaître dans les réponses courantes.
Les contenus exclus sont trop risqués, trop anciens, sans propriétaire ou sans rapport avec le cas d’usage.
Cette sélection réduit les coûts de stockage vectoriel, d’embedding et de surveillance. Elle limite également le bruit envoyé au modèle.
Le rapport Cloudera et Harvard Business Review Analytic Services révèle par ailleurs que 47 % des répondants pensent que les agents IA pourraient résoudre leurs problèmes de qualité des données.
L’automatisation peut effectivement classifier des fichiers, détecter des doublons, suggérer des métadonnées ou repérer des contradictions. Elle ne doit toutefois pas devenir une manière de confier à une machine les décisions d’autorité que l’entreprise a évité de prendre.
La centralisation physique de toutes les données n’est pas toujours nécessaire non plus. Des catalogues fédérés, des couches de virtualisation ou des connecteurs peuvent laisser l’information dans les systèmes existants tout en fournissant un contexte commun.
Cette approche réduit certains déplacements de données et facilite le respect des contraintes de localisation. Elle rend cependant la disponibilité des connecteurs et la cohérence des politiques encore plus importantes.
Vos données sont-elles prêtes pour l’IA ?
Répondez à 25 questions pour évaluer la qualité, la fraîcheur, la sécurité et la gouvernance de vos données.
Votre profil
Vos 3 priorités
Checklist Data + IA
Téléchargez les actions à passer en revue avec les métiers, la DSI et les équipes sécurité.
La solution est une chaîne de confiance
Une entreprise ne transforme pas ses données en données prêtes pour l’IA avec un unique logiciel. Elle construit une chaîne où chaque étape ajoute un niveau de confiance.
Systèmes sources → inventaire → classification → déduplication → source d’autorité → métadonnées → droits d’accès → découpage → embeddings → index → évaluation → surveillance
Chaque étape répond à un risque différent.
L’inventaire indique ce qui existe. La déduplication réduit les copies concurrentes. La source d’autorité désigne la version à croire. Les métadonnées apportent le contexte. Les droits d’accès limitent les informations récupérables. L’indexation transforme les contenus pour la recherche. L’évaluation vérifie enfin que l’ensemble répond correctement aux questions réelles.
L’article 10 de l’AI Act illustre l’importance croissante de cette discipline pour les systèmes à haut risque. Le texte exige notamment des pratiques portant sur l’origine, la collecte, la préparation, le nettoyage, la mise à jour, les lacunes et la pertinence des données.
Il demande également que les jeux concernés soient suffisamment représentatifs, complets et aussi exempts d’erreurs que possible au regard de leur usage. Le texte présenté par le service officiel de la Commission européenne rappelle que la qualité doit être appréciée selon le contexte concret du système.
Son calendrier d’application et ses éventuelles modifications doivent toutefois être vérifiés pour chaque projet.
Un plan de remise en état en trois phases
Première phase : délimiter. L’entreprise choisit un seul cas d’usage, recueille les questions réelles des utilisateurs et identifie les sources indispensables. Elle désigne un propriétaire métier pour chaque ensemble critique.
Deuxième phase : rendre les sources gouvernables. Les équipes détectent les doublons, marquent les documents obsolètes, désignent les versions officielles et ajoutent les métadonnées nécessaires. Les règles d’accès sont testées avant toute ouverture aux utilisateurs.
Troisième phase : industrialiser. Le pipeline de synchronisation est automatisé. Des jeux de questions de référence évaluent la pertinence, la fraîcheur, la traçabilité et le respect des permissions. Les réponses problématiques alimentent ensuite un cycle continu de correction.
Le tableau de bord ne doit pas seulement mesurer la précision générale. Il doit suivre plusieurs dimensions.
| Contrôle | Indicateur conseillé |
|---|---|
| Unicité | Proportion de doublons et quasi-doublons dans le corpus |
| Fraîcheur | Sources possédant une date de validité et une date de révision |
| Autorité | Réponses reposant sur une source officiellement approuvée |
| Sécurité | Résultats non autorisés obtenus lors des tests de permissions |
| Cohérence | Définitions métier conflictuelles encore non arbitrées |
| Traçabilité | Réponses accompagnées de la source, de la version et de la date |
| Maintenance | Délai entre la modification d’une source et sa mise à jour dans l’index |
Une entreprise n’a pas besoin d’attendre que toutes ces mesures atteignent la perfection. Elle doit connaître ses lacunes, limiter le périmètre et rendre le niveau de confiance visible pour chaque usage.
Les données ont été conçues pour les humains, pas pour les agents
Les entreprises découvrent que leurs données sont inutilisables pour l’IA parce qu’elles ont été organisées pour être stockées, recherchées et interprétées par des humains.
Elles n’ont pas été conçues pour permettre à une machine de distinguer automatiquement une copie d’une source officielle, une archive d’une procédure active ou une information publique d’un document confidentiel.
Les doublons brouillent la pertinence. Les documents obsolètes restent présents dans les index. Les droits d’accès disparaissent lors des migrations. L’absence de métadonnées retire le contexte. Les définitions contradictoires produisent plusieurs vérités possibles.
Acheter un meilleur modèle ne résout aucun de ces problèmes. Une IA plus puissante peut lire davantage de documents et formuler une réponse plus convaincante. Elle ne sait toujours pas quelle donnée l’entreprise a décidé de croire.
Le véritable projet consiste donc à bâtir une chaîne de confiance reliant les données, les équipes métier, la sécurité et l’infrastructure cloud.
Cette discipline devient encore plus importante avec les agents autonomes. Une mauvaise réponse peut être corrigée par un utilisateur. Une mauvaise donnée utilisée par un agent pour modifier un contrat, lancer une commande ou bloquer un dossier devient immédiatement un risque opérationnel.
FAQ
Qu’est-ce qu’une donnée prête pour l’IA ?
Une donnée prête pour l’IA est une information suffisamment fiable, contextualisée et accessible pour être utilisée par un modèle ou un agent dans un cas d’usage précis. Elle doit notamment posséder une origine identifiable, un propriétaire, une date de validité, un niveau de sensibilité et une définition compréhensible. La préparation inclut aussi le nettoyage, la déduplication, la gestion des permissions et la mise à jour des index. Il ne suffit donc pas qu’un fichier puisse être techniquement ouvert ou importé dans une base vectorielle.
Comment savoir si les données d’une entreprise sont utilisables par une IA ?
Il faut tester les données avec les questions et les profils d’utilisateurs prévus. L’entreprise doit vérifier si l’IA trouve la bonne version d’un document, cite une source identifiable, respecte les droits d’accès et détecte les informations périmées. Elle doit également contrôler la cohérence des indicateurs métier et la présence de métadonnées. Un bon audit ne mesure pas seulement la quantité de données disponibles. Il évalue leur unicité, leur fraîcheur, leur autorité, leur traçabilité et leur niveau de risque.
Le RAG peut-il compenser une mauvaise qualité des données ?
Non. Le RAG permet à un modèle de rechercher des informations internes avant de répondre, ce qui réduit sa dépendance à ses seules connaissances d’entraînement. Il ne corrige pas automatiquement les sources. Si l’index contient des doublons, des procédures périmées ou des informations contradictoires, le système peut les retrouver et les transmettre au modèle. La qualité du RAG dépend donc du pipeline documentaire, des métadonnées, des filtres, des permissions et des mécanismes de synchronisation placés en amont.
Comment supprimer les doublons avant d’alimenter une IA ?
La déduplication combine généralement plusieurs méthodes. Les copies exactes peuvent être identifiées avec des empreintes numériques. Les quasi-doublons nécessitent une comparaison du contenu, des titres, des dates et des métadonnées. L’entreprise doit ensuite choisir la version à conserver selon son statut, son propriétaire et sa date de validité. Les anciennes versions utiles ne sont pas nécessairement supprimées. Elles peuvent être marquées comme archives et exclues des recherches courantes.
Comment préserver les droits d’accès dans un assistant IA ?
Les permissions du système source doivent être récupérées pendant l’indexation et attachées à chaque document sous forme de métadonnées. Au moment de la question, le moteur de recherche vérifie l’identité, les groupes ou le rôle de l’utilisateur avant de renvoyer les passages au modèle. Des tests doivent confirmer qu’un salarié ne peut pas obtenir indirectement un document qu’il n’aurait pas le droit d’ouvrir. Les réponses et les sources consultées doivent aussi être journalisées pour faciliter les audits.
Qui doit être responsable de la qualité des données utilisées par l’IA ?
La responsabilité doit être partagée, mais elle ne doit pas rester anonyme. Les métiers définissent le sens, la validité et la source d’autorité. Les équipes data construisent les contrôles, les métadonnées et les pipelines. La sécurité gère les droits et les niveaux de sensibilité. Les équipes IA évaluent la recherche et les réponses. Pour chaque domaine critique, un data owner ou un content owner doit pouvoir confirmer quelle information fait foi et décider comment traiter les contradictions.
Sources principales
- Cloudera et Harvard Business Review Analytic Services, Taming the Complexity of AI Data Readiness
- Deloitte, State of AI in the Enterprise 2026
- Commission européenne, AI Act, Article 10
- Microsoft, pipeline de données non structurées pour le RAG
- Microsoft, contrôle d’accès au niveau du document dans Azure AI Search
- Microsoft, conception des données d’ancrage pour les workloads IA
- AWS, synchronisation des sources avec Amazon Bedrock Knowledge Bases
- Google Cloud, présentation du Knowledge Catalog
- IBM, définition et fonctionnement du Master Data Management
- Databricks, data lineage dans Unity Catalog
- Partager l'article :
