Données et IA
Préparer ses données pour l'IA agentique : sémantique, contrats et data products
Un agent ne vaut que par le contexte qu'on lui fournit : quelles données, quel sens, quels droits. En 2026, l'enjeu se déplace du modèle vers la préparation des données pour l'IA et, plus précisément, vers la couche sémantique qui explique aux machines ce que les chiffres signifient.
Dans cet article
- Pourquoi les données bloquent les agents avant les modèles
- Ce qui change quand l'utilisateur est un agent
- Cinq couches pour un contexte fiable
- Structuré, non structuré : deux chantiers distincts
- Évaluer la préparation d'un cas d'usage : huit questions
- Par où commencer : un contexte minimal viable
- Conclusion : le contexte est un actif
- Questions fréquentes
- Sources et repères
Pourquoi les données bloquent les agents avant les modèles
- 63 %des organisations n'ont pas, ou ne savent pas si elles ont, les pratiques de gestion des données adaptées à l'IAGartner, février 2025 (1 203 responsables interrogés)
- 60 %des projets d'IA privés de données prêtes pour l'IA seront abandonnés d'ici fin 2026 (prévision)Gartner, février 2025
- jusqu'à 80 %de précision en plus pour les agents d'ici 2027, si la sémantique est priorisée (prévision)Gartner, mai 2026
En février 2025, Gartner publiait une enquête menée auprès de 1 203 responsables de la gestion des données : 63 % des organisations n'ont pas, ou ne savent pas si elles ont, les pratiques adaptées à l'IA. Sur cette base, Gartner prévoyait que, d'ici fin 2026, 60 % des projets d'IA privés de données prêtes pour l'IA seraient abandonnés.
Avec l'IA agentique, le constat se précise. En mai 2026, Gartner affirme que l'absence de sémantique rend les agents imprécis et coûteux : sans connaissance des relations et des règles propres à l'organisation, un agent hallucine davantage et produit des résultats moins fiables, et les modèles de données fondés sur le seul schéma ne suffisent plus, faute de contexte métier. Gartner recommande d'établir une couche de contexte au cœur de l'infrastructure data et analytics, et table sur des gains de précision pouvant atteindre 80 % et des coûts réduits jusqu'à 60 % d'ici 2027 pour les organisations qui donnent la priorité à la sémantique. Ce sont des prévisions, pas des mesures.
Autrement dit : un modèle de langage sait écrire du SQL ; il ne sait pas ce que l'entreprise appelle « un actif disponible », « un contrat actif » ou « une anomalie critique ».
Ce qui change quand l'utilisateur est un agent
Pendant vingt ans, les données ont été préparées pour des humains qui lisent un tableau de bord. Un agent est un utilisateur d'un autre genre : il pose des questions libres, enchaîne les appels et peut agir sur le résultat.
| Exigence | Reporting et BI | Assistant documentaire (RAG) | Agent |
|---|---|---|---|
| Question posée | Prévue à l'avance (tableau de bord) | Libre, sur du texte | Libre, en plusieurs étapes, sur plusieurs sources |
| Sens des données | Défini dans le rapport | Implicite dans les documents | Explicite et lisible par la machine |
| Droits d'accès | Au niveau du rapport | Au niveau du document | Au niveau de l'utilisateur, à chaque appel d'outil |
| Conséquence d'une erreur | Un humain relit le chiffre | La citation permet de vérifier | L'erreur peut déclencher une action |
| Fraîcheur | Planifiée | Selon l'indexation | Souvent quasi temps réel |
| Volume d'appels | Faible | Modéré | Élevé : boucles et essais successifs, avec un coût et une charge sur les sources |
Brancher un agent sur l'entrepôt de données existant, c'est lui demander de deviner le sens, les droits et la fraîcheur à chaque requête. Il le fera, avec aplomb, et parfois à tort.
Cinq couches pour un contexte fiable
- Des données sources fiablesQualité mesurée, fraîcheur observée, lignage (d'où vient la donnée, comment elle a été transformée), propriétaires identifiés.
- Des data products et des contrats de donnéesChaque produit a un propriétaire, une interface et des engagements (schéma, qualité, délais). L'Open Data Contract Standard, projet Bitol de la Linux Foundation (version 3.1 de décembre 2025), décrit schéma, règles de qualité, niveaux de service et propriété dans un format ouvert.
- Une couche sémantiqueDéfinitions uniques des indicateurs, entités, relations, hiérarchies et règles de calcul. L'initiative Open Semantic Interchange, lancée en septembre 2025 par Snowflake, Salesforce, dbt Labs et d'autres, vise une spécification ouverte pour échanger ces définitions entre outils.
- Un accès gouverné pour les agentsServeurs MCP ou API, identité de l'utilisateur propagée (pas de compte technique à tout faire), sécurité par ligne et par colonne, quotas.
- Une récupération adaptée au type de donnéeRecherche documentaire (RAG) pour le non structuré ; requêtes sur le modèle sémantique pour le structuré, plutôt que du SQL généré sur un schéma brut.
Le protocole MCP offre une porte d'entrée standard vers ces données : la spécification prévoit que l'application hôte obtienne le consentement explicite de l'utilisateur avant d'exposer ses données à un serveur ou d'invoquer un outil, et demande de protéger les données par des contrôles d'accès appropriés. Elle précise aussi qu'elle ne peut pas faire respecter ces principes à elle seule : la gouvernance reste à construire côté entreprise.
Structuré, non structuré : deux chantiers distincts
Les données structurées : exposer du sens, pas des tables
Lorsqu'un agent génère du SQL sur un schéma brut, il improvise les jointures et réinterprète les colonnes : la même question peut produire deux réponses différentes d'un jour à l'autre. La parade consiste à exposer des indicateurs et des vues gouvernés (le « chiffre d'affaires » ou la « disponibilité » sont définis une fois) et à valider les réponses sur un jeu de questions de référence dont les résultats sont connus.
Les documents : la recherche documentaire demande de la rigueur
- Versions et statuts : indexer un document obsolète, un brouillon ou un doublon, c'est le faire citer comme s'il faisait foi. Les métadonnées (date, périmètre, statut, propriétaire) doivent accompagner chaque contenu.
- Droits : les permissions du document source doivent être respectées dans l'index et à chaque requête, pas seulement à l'indexation.
- Formats difficiles : tableaux, schémas, PDF numérisés, abréviations métier ; chacun demande un traitement et un test dédiés.
- Citations : toute réponse doit renvoyer vers ses sources, de façon vérifiable par l'utilisateur.
Évaluer la préparation d'un cas d'usage : huit questions
| Dimension | Question à poser | Signal d'alerte |
|---|---|---|
| Périmètre | De quelles données le cas d'usage a-t-il précisément besoin ? | « De toutes » |
| Propriété | Qui répond de chaque source ? | Aucun propriétaire nommé |
| Qualité | La qualité est-elle mesurée, avec des seuils ? | Contrôles manuels ponctuels |
| Sens | Chaque indicateur a-t-il une définition unique ? | Trois définitions de la « disponibilité » selon les équipes |
| Fraîcheur | Quel retard est acceptable pour l'usage ? | Fraîcheur inconnue ou non surveillée |
| Droits | L'agent hérite-t-il des droits de l'utilisateur ? | Compte technique aux droits étendus |
| Traçabilité | Peut-on rejouer ce que l'agent a lu, et pourquoi ? | Aucun journal des accès |
| Évaluation | Existe-t-il un jeu de questions de référence aux réponses validées ? | Évaluation « à l'œil » |
Par où commencer : un contexte minimal viable
La tentation est de lancer un grand chantier de « mise en qualité de toutes les données ». Il est long, coûteux et sans lien visible avec la valeur. Nous préférons construire, pour un ou deux cas d'usage, le contexte minimal viable :
- Choisir un ou deux cas d'usage à valeur mesurable, avec la méthode de qualification des cas d'usage IA.
- Lister les entités et indicateurs réellement mobilisés : quelques dizaines suffisent, pas des milliers.
- Qualifier les données concernées : propriétaire, qualité, fraîcheur, droits.
- Formaliser la sémantique de ce périmètre (définitions, relations, règles de calcul) et la publier sous une forme gouvernée.
- Ouvrir un accès contrôlé (MCP ou API), avec identité de l'utilisateur et journalisation.
- Constituer le jeu de questions de référence et mesurer la fiabilité avant d'élargir le périmètre.
Cette approche crée des fondations réutilisables par les cas d'usage suivants, et s'appuie sur les principes de gouvernance des données que nous recommandons par ailleurs. Elle ne suppose pas de changer de plateforme : l'évolution des architectures data facilite le passage à l'échelle, mais n'est pas un préalable. Pour un programme qui porte sur la plateforme data elle-même, c'est le même fil conducteur : partir de la valeur, qualifier, puis industrialiser.
Conclusion : le contexte est un actif
Les modèles s'échangent et progressent vite ; le contexte, lui, appartient à l'entreprise : ses définitions, ses règles, ses droits, sa mémoire. C'est ce qui rend un agent fiable, et c'est ce qui se capitalise d'un cas d'usage à l'autre. Préparer ses données pour l'IA agentique, c'est d'abord décider de ce que l'on veut que les machines comprennent, et de qui en répond.
Questions fréquentes
Qu'est-ce que des données « prêtes pour l'IA » (AI-ready) ?
Des données dont la qualité, le sens, la fraîcheur, la traçabilité et les droits d'accès sont adaptés à un cas d'usage donné. La notion est relative : les mêmes données peuvent suffire à un assistant documentaire et être insuffisantes pour un agent qui déclenche des actions.
Faut-il un data lakehouse ou un data mesh avant de déployer des agents ?
Non, pas comme prérequis. Ce qui compte, c'est la qualité, la sémantique et l'accès gouverné sur le périmètre du cas d'usage. Une plateforme moderne facilite le passage à l'échelle, mais on peut démarrer sur des sources existantes à condition de les qualifier.
Quelle différence entre une couche sémantique et un catalogue de données ?
Un catalogue inventorie et documente les actifs de données : où ils se trouvent, qui en répond. Une couche sémantique définit le sens métier de façon exploitable par les machines : indicateurs, entités, relations, règles de calcul, que les outils et les agents interrogent de manière cohérente. Les deux se complètent.
RAG ou requêtes SQL pour un agent ?
Les deux, selon la nature de la donnée : recherche documentaire (RAG) pour les contenus non structurés, requêtes sur un modèle sémantique gouverné pour les données structurées. Générer du SQL directement sur un schéma brut est la voie la moins fiable, car le modèle improvise jointures et définitions.
Sources et repères
Les éléments chiffrés et datés de cette analyse ont été vérifiés auprès des sources ci-dessous en octobre 2026. Les prévisions d'analystes sont des prévisions, pas des constats. Le sujet évolue vite : en cas d'écart avec une source primaire, c'est celle-ci qui fait foi.
- Gartner — Lack of AI-Ready Data Puts AI Projects at Risk — communiqué du 26 février 2025 (63 % ; 60 % ; enquête auprès de 1 203 responsables)
- Gartner — Gartner Says Lack of Semantics Causes Inaccurate AI Agents and Wasted Spending — communiqué de mai 2026 (couche de contexte ; prévision à 2027)
- Open Data Contract Standard (Bitol, Linux Foundation) — version 3.1.0 — standard ouvert de contrats de données, décembre 2025
- Snowflake — Open Semantic Interchange Initiative — lancement de l'initiative, 23 septembre 2025
- Model Context Protocol — Spécification — ressources, outils, sécurité et consentement