Semarchy a interrogé les entreprises sur leur préparation à l’IA : 98 % d’entre elles rencontrent des obstacles de qualité des données dès le démarrage de leurs projets. Pour Julien Peltier, VP Platform Success, une donnée « AI-ready » repose sur cinq piliers essentiels : qualité, documentation, traçabilité, gouvernance et usages autorisés.
SNC : Pour vous, qu’est-ce qui définit vraiment une donnée prête pour l’IA ?
Julien Peltier : Déjà, il faut se mettre d’accord sur ce qu’on entend par « prête pour l’IA ». Selon l’usage – expérimentation en sandbox ou automatisation en production – on ne va pas exiger le même niveau de qualité ni la même fraîcheur de la donnée. Dans un cas, l’humain peut encore interpréter les résultats en connaissance de cause. Dans l’autre, on va prendre des décisions basées sur l’IA, donc le niveau d’exigence est beaucoup plus élevé. Une fois ce contexte posé, je vois cinq grands piliers.
Le premier, c’est la documentation des usages autorisés et du niveau de sécurité associé. Une hiérarchie interne n’a pas le même niveau de sensibilité qu’une base clients avec des données personnelles. Cette dernière ne peut pas être utilisée pour tous les usages IA : il faut que le consentement et les traitements autorisés soient clairs.
Le deuxième pilier, c’est le niveau de qualité. On doit pouvoir estimer le niveau réel de qualité et le niveau de confiance que l’on peut accorder à la donnée : est-ce acceptable pour le business ? Et surtout, où sont les zones moins fiables, qui peuvent introduire des biais dans l’apprentissage ?
Le troisième pilier, c’est la documentation, au sens métier, et la capacité à publier un modèle sémantique associé. Si on donne juste une table de chiffres à l’IA, elle ne peut pas faire grand-chose. Si on précise ce que contient chaque attribut, les formules de calcul, le sens métier, là cela devient exploitable et enrichissable.
Les deux derniers piliers sont la traçabilité et la gouvernance : savoir d’où viennent les données, quels traitements elles ont subi, par quels systèmes elles sont passées, quand elles ont été mises à jour pour la dernière fois, qui en est propriétaire et à qui demander l’accès.
Votre enquête montre que 98 % des entreprises rencontrent des obstacles de qualité des données au lancement de leurs projets IA. Quels problèmes ressortent le plus souvent ?
J. P. : Très souvent, quand un projet IA démarre, les data scientists se débrouillent pour récupérer des jeux de données « à droite à gauche ». On retrouve des problèmes classiques : difficulté à savoir quelles données existent, où se trouve la référence, qui les gère, comment y accéder. Il y a un vrai sujet de mise à disposition et de communication autour des données.
Pour moi, un facteur clé de succès, c’est la mise en place d’un portail qui expose les jeux de données et les data products disponibles, avec toutes les caractéristiques dont on parlait : description, niveau de qualité, usages autorisés, profondeur historique, modes d’accès (batch, fichiers, API, dashboards existants, etc.). Cela permet à n’importe quel acteur data – data science, data engineering, métiers – de venir consulter la « carte » des données de l’entreprise, puis de les intégrer facilement dans son projet.
Aujourd’hui, les data scientists passent encore le plus gros de leur temps à retravailler et nettoyer les données, plutôt qu’à en dégager de la valeur. L’idée est vraiment de leur simplifier cette partie amont.
De ce que vous observez, la documentation reste un maillon faible…
J. P. : Oui, la documentation reste un maillon faible, mais au-delà, je dirais que c’est la communication qui manque.
Lors de nos journées clients Semarchy, aux États-Unis, en Angleterre et en France, on a posé une question simple à des clients qui gèrent des données de référence gouvernées et de qualité : « Savez-vous si vos données sont utilisées par des projets d’IA ? »
La moitié ne savait pas répondre. Une partie disait non, une grande partie disait « je ne sais pas », et seulement environ un tiers savait qu’il y avait des usages IA derrière.
Pour moi, ce n’est pas normal. Quand on fait du MDM, on doit savoir à quoi servent les données et être reconnu pour ça. Une donnée qui passe par un système MDM, c’est une donnée qui a déjà 70 % de ce dont l’IA a besoin. Il ne reste plus grand-chose à faire derrière.
L’avantage, dans notre solution, c’est que la modélisation se fait de manière sémantique et qu’on documente directement les modèles de données. Quand on génère ensuite un modèle sémantique pour l’exposer à des usages IA, il est déjà documenté : on ne duplique pas le travail.
Vous parlez aussi d’un manque de culture data dans les organisations…
J. P. : Oui. Les équipes data science se sont souvent créées dans des silos expérimentaux, pas forcément intégrées dans les équipes data ou IT historiques. Aujourd’hui encore, on trouve plusieurs équipes data par filiale, qui communiquent plus ou moins entre elles, sans forcément d’initiative globale.
Dès qu’on veut lancer des initiatives IA globales, on se heurte à ces silos. On ne sait pas, par exemple, si un même client est présent dans différentes filiales ou s’il est dupliqué.
Si, en amont, on a mis en place un référentiel client groupe, avec une identité unique pour chaque client, on facilite énormément le travail des équipes data science. Elles disposent d’un modèle pivot clair et peuvent se concentrer sur les modèles, pas sur le rattrapage des incohérences.
L’explicabilité devient critique, notamment avec les réglementations européennes. Comment l’intégrer dès la préparation des données ?
J. P. : Pour moi, l’explicabilité couvre deux grands sujets. Le premier, ce sont les sources de données : être capable de remonter tous les systèmes dont on s’alimente, y compris les chaînes en cascade. Il faut comprendre par où la donnée est passée et où elle est consommée.
Le deuxième, ce sont les traitements appliqués à la donnée : où a-t-on normalisé des noms, des prénoms, des adresses ? Où a-t-on dédoublonné ? Où a-t-on rejeté ?
Toute cette capacité à rejouer l’histoire de la donnée est essentielle pour une équipe de data science qui veut savoir sur quoi elle travaille avant de construire ses modèles.
Comment concilier données « AI-ready » et exigences de confidentialité ou de souveraineté ?
J. P. : Cela passe d’abord par une documentation très claire des usages autorisés. Quand j’expose une donnée comme data product, je dois indiquer : « Vous avez le droit de la consommer pour ceci, pas pour cela », en fonction des réglementations applicables.
Pour certaines données sensibles, on peut imaginer des workflows d’approbation, avec plusieurs niveaux de validation, jusqu’au DPO s’il s’agit de données personnelles. L’idée, c’est de vérifier que l’usage est légitime et que la finalité est bien conforme.
C’est d’autant plus important que beaucoup de collaborateurs utilisent encore l’IA de manière peu contrôlée, avec des comptes personnels sur des services publics. Copier-coller des verbatims d’enquêtes dans un GPT public, par exemple, peut poser problème si des informations identifiantes sont présentes. De plus en plus de grands groupes mettent en place leurs propres solutions de génération internes, mais tous n’en sont pas encore là, donc il y a encore un gros travail de pédagogie.
Quels sont les signaux d’alerte qui montrent qu’un projet IA risque d’échouer faute de qualité ou de gouvernance ?
J. P. : Le premier signal, c’est le niveau de confiance dans le modèle. Si on n’arrive pas à obtenir un taux de prédiction suffisamment élevé, cela montre qu’il y a des failles, soit dans l’entraînement du modèle, soit dans la qualité des données. Si on entraîne un modèle sur des données à 80–90 % de qualité et qu’on le met en production, on va retrouver ces 80–90 % en production, avec le risque que cela ne soit pas suffisant pour le cas d’usage.
Un autre signal, ce sont les projets qui n’arrivent pas à converger : on passe son temps à corriger des problèmes de données, à revenir dessus, à recoder des règles. À un moment, il faut se demander si c’est un processus itératif normal ou si l’on est dans une dérive. Si l’on passe trop de temps sur les données, il faut parfois accepter de reprendre le projet à zéro, reposer les fondamentaux et explorer d’autres data products plutôt que de s’accrocher à des hypothèses de départ qui ne tiennent pas.
Est-ce que certains secteurs avancent plus vite que d’autres dans cette préparation data pour l’IA ?
J. P. : Oui. Le secteur financier, par exemple, travaille depuis longtemps avec des algorithmes, des modèles de risque, des architectures de données structurées. Il a déjà des standards internes assez élevés. On voit aussi une bonne dynamique dans la santé, avec des cas d’usage autour des soins et des études épidémiologiques, et dans l’industrie, avec la maintenance prédictive sur les chaînes de production. Dans le retail, on est dans l’extension de ce qui se faisait déjà en marketing, avec des algorithmes de recommandation produits, mais là encore, la qualité et la gouvernance des données changent la donne.
Comment voyez-vous évoluer les exigences autour des données dans les prochaines années ?
J. P. : Je pense que la prochaine grande exigence sera d’anticiper beaucoup mieux l’intégration avec les systèmes. Cela veut dire documenter tous les points d’intégration possibles entre un data product et les systèmes qui veulent le consommer, et aussi échanger le modèle sémantique. Nous avons, par exemple, une intégration avec Microsoft Fabric où l’on publie à la fois une copie de la base métier et le modèle sémantique. Un utilisateur peut alors, via Copilot, demander un tableau de bord en langage métier, et Copilot sait automatiquement comment interpréter les données.
On voit aussi émerger des standards comme les serveurs MCP, des serveurs d’instructions pour les IA. Notre vision, c’est d’associer un serveur MCP à chaque data product, pour permettre à n’importe quelle IA générale de savoir comment interroger ces données et en comprendre la sémantique. Cela va faciliter encore davantage l’usage des données à l’échelle, via des IA généralistes appuyées sur des agents spécialisés.
Le concept de « données AI-ready » va-t-il, selon vous, devenir une certification, un standard ou simplement une bonne pratique interne ?
J. P. : Je le vois plutôt comme une forme de certification interne, adossée à un framework. Chacun va arriver avec sa propre approche. On voit des consortiums émerger sur les modèles sémantiques, pour les rendre interopérables. Mais sur l’« AI-readiness » elle-même, je pense qu’il sera difficile d’avoir un standard externe unique, parce que cela dépend énormément de la nature des données et des usages.
Je présente cela à mes clients comme un « score de fitness » : cela dépend de votre niveau de maturité et de ce que vous voulez faire avec l’IA. C’est à vous de définir vos critères et vos niveaux, de l’exploration à la production.
Nous, notre rôle, c’est de proposer une manière d’organiser ces niveaux de readiness dans la solution. Déjà, si toutes les équipes data d’une organisation partagent la même définition de ce qu’est une donnée « AI-ready », on aura franchi une grande étape.
