La donnée n'est pas « bonne ». Elle est pertinente pour quelqu'un.

Série Revolution Summit 2026 - article 2/3

---

Au Revolution Summit Onepoint, j'ai entendu la même formulation dans presque chaque témoignage, secteur après secteur : « notre principal frein, c'est la qualité des données. » Ce diagnostic revient si souvent qu'il a fini par sembler aller de soi : c'est précisément ce qui pose problème.

La qualité n'est pas une propriété, c'est une relation

La qualité d'une donnée n'est pas une caractéristique intrinsèque : c'est une relation entre cette donnée et celui qui l'utilise, qu'il soit humain ou agent.

Prenons un exemple simple. Un indicateur de satisfaction client peut être parfaitement lisible pour un responsable terrain qui en connaît le mode de collecte, les variations saisonnières et la cible par segment. Ce même score, transmis sans contexte à un agent IA chargé de prioriser les relances commerciales, peut conduire à des actions contre-productives ; non parce que la donnée est mauvaise, mais parce que l'agent ne dispose pas du cadre d'interprétation qui lui donne son sens. La donnée est identique ; ce qui manque, c'est sa représentation métier.

La vraie question n'est pas « nos données sont-elles propres ? » mais « propres pour qui, dans quel contexte, avec quelle logique métier ? »

L'enjeu n'est donc pas de nettoyer la data au sens technique du terme, mais de construire une représentation de cette donnée qui soit contextualisée, documentée et lisible par quiconque doit s'en servir, y compris un système qui ne connaît pas les règles implicites de votre organisation.

C'est d'ailleurs ce que confirme mon expérience terrain des déploiements GenAI : la qualité des résultats d'un modèle de langage dépend moins de sa puissance que de la richesse du contexte qu'on lui fournit. Un LLM nourri de données brutes hallucine ou généralise ; le même modèle alimenté par des représentations métier documentées produit des résultats exploitables. La couche sémantique, souvent reléguée à un détail d'architecture, est en réalité ce qui sépare un assistant impressionnant en démonstration d'un agent utile en production.

Un travail qui appartient aux métiers

Ce glissement change radicalement qui doit piloter le chantier. Améliorer la qualité technique des données relève des équipes data et IT. Mais définir ce qu'une donnée signifie dans un contexte métier précis (qui la consomme, dans quel processus, avec quelle règle d'interprétation) est un travail qui appartient d'abord aux métiers, parce que cette connaissance vit dans les équipes opérationnelles, souvent de façon tacite et non documentée.

Cette responsabilité a tendance à flotter entre les équipes métier qui détiennent la connaissance et les équipes IT qui ont besoin qu'elle soit formalisée, sans qu'aucune ne se considère comme légitime pour en être la garante. Ce flottement n'est pas nouveau ; ce qui l'est, c'est le prix qu'il fait payer dès lors que des agents doivent s'appuyer sur cette représentation pour décider et agir.

C'est dans ce vide que j'observe, dans les organisations les plus avancées, l'émergence d'un rôle encore peu formalisé : le « référent sémantique métier ». Ce n'est ni un expert data, ni un product owner au sens classique, mais quelqu'un qui porte la définition opérationnelle d'une donnée dans un domaine précis, qui sait documenter les règles implicites, les exceptions connues des seuls praticiens, les logiques métier qui n'avaient jamais eu besoin d'être écrites parce qu'elles se transmettaient de façon tacite. Ce rôle existait informellement dans toutes les organisations. Il devient structurant dès lors que la donnée doit être lisible non seulement par des humains capables d'inférer le contexte, mais par des systèmes qui ne le peuvent pas.

Ce que ça change dans la pratique

La question que je pose systématiquement avant tout chantier data lié à l'IA n'est pas « vos données sont-elles de bonne qualité ? » mais : « pour qui cette donnée doit-elle être lisible, dans quel contexte, et avec quelle logique métier ? »

Cette question déplace le centre de gravité du projet : elle force à définir les cas d'usage avant les structures de données, et implique les métiers comme architectes de la représentation plutôt que comme validateurs de modèles construits sans eux. Dans la quasi-totalité des cas, elle révèle que les vraies lacunes ne sont pas dans la donnée elle-même, mais dans le fait que sa signification métier n'a jamais eu besoin d'être formalisée jusqu'à maintenant. C'est ce que je recouvre sous le terme de « stress test organisationnel » : l'IA ne crée pas ce dysfonctionnement, elle en révèle l'existence et en accélère les conséquences.

Tant que cette représentation n’existe pas, la donnée ne peut pas être correctement absorbée dans les processus, qu’ils soient humains ou agentiques.

---

Ce deuxième chantier, la donnée par usage, soulève une question en creux : si les métiers doivent en être les architectes, comment éviter de recréer, sous une nouvelle forme, la relation client/fournisseur avec l'IT que tout le monde cherche précisément à dépasser ? C'est l'objet du prochain article.