LMI : Comment identifier les données puis les préparer/nettoyer afin qu’elles soient facilement assimilables, existe-t-il ou va-t-on vers un standard de normalisation ?

William Saadi : La première étape, c’est de comprendre ce qu’on a vraiment. Avant de faire du machine learning, il faut faire du data learning. Dans beaucoup d’organisations, les données sont éparpillées : fichiers Excel, bases SQL, PDF, emails, CRM… On commence donc par un audit data, une cartographie complète des sources et de leur fraîcheur. Des outils comme Collibra ou Alation permettent de visualiser cette cartographie, mais l’essentiel reste humain : il faut savoir pourquoi chaque donnée existe et à quoi elle va servir. Ensuite, vient la préparation. C’est la phase la plus ingrate, mais la plus cruciale : nettoyage, déduplication, harmonisation des formats, enrichissement sémantique… On automatise tout ce qu’on peut avec Spark, Pandas ou Airflow, mais les règles métier doivent toujours être co-construites avec les experts du terrain. J’ai vu un client dans la santé réduire de 40 % ses erreurs simplement en appliquant des règles de validation sur ses données médicales avant l’entraînement des modèles. Enfin, la normalisation. Aujourd’hui, il n’existe pas de standard universel, mais des approches émergent comme Data Mesh, Schema.org, ISO 8000, ou des ontologies métiers spécifiques. Nous disons souvent à nos clients que la normalisation est un équilibre, trop rigide, elle bloque l’innovation, trop souple, elle génère du bruit. L’enjeu, c’est de traiter chaque jeu de données comme un produit, avec son propriétaire et ses KPIs de qualité.

Comment ingérer les différentes sources de données ?

L’ingestion, c’est un vrai sujet d’architecture. On ne parle pas simplement d’extraire des données, mais de faire dialoguer des écosystèmes qui n’ont jamais été pensés pour ça. ERP, CRM, IoT, SharePoint, bases documentaires, chacun parle son propre langage. Les plateformes d’ingestion modernes telles que Kafka, Debezium, Fivetran, permettent d’orchestrer des flux en temps réel et de bâtir des pipelines robustes. Prenons le cas d’un client dans le retail qui faisait encore ses traitements la nuit. En basculant sur du streaming temps réel, il a réduit ses latences de 70 % et a rendu ses modèles de recommandation beaucoup plus pertinents. Le secret, c’est la modularité, cela signifie de séparer ingestion, transformation et validation pour pouvoir faire évoluer chaque brique sans tout casser. Et surtout, impliquer les métiers dès le départ car l’ingestion n’est pas un projet IT, c’est un partenariat métier-tech.

Le Data Hoarding qui consiste à archiver ou à ne jamais supprimer les données est très répandu. Pourquoi les entreprises n’effacent-elles pas leurs données même celles jugées inutiles ?

C’est un sujet culturel. Les entreprises gardent tout parce qu’elles ont peur de perdre la donnée magique qui servira un jour. Et comme le stockage ne coûte presque rien, la tentation est forte de ne jamais rien effacer. Mais le coût réel est ailleurs, dans la complexité, dans le bruit que ces données inutiles ajoutent aux modèles, et dans les risques RGPD. Chez un client bancaire, on a mesuré +30 % de coûts de stockage par an simplement à cause de données obsolètes. La solution passe par la classification automatique (avec Microsoft Purview ou Varonis) et des règles de rétention métier. Et, surtout, il faut instaurer une culture de responsabilité car chaque donnée a un coût, une durée de vie et un propriétaire. Le data hoarding, c’est le signe d’une gouvernance immature. Dans les entreprises matures, chaque dataset a une date d’expiration et un responsable identifié.

Comment aider les métiers à valider des données et les qualifier en continu alors qu’eux même n’ont pas le temps ou ne trouvent pas forcément les bons experts (quid de la formation en interne) ?

On ne peut pas parler de qualité des données sans parler des métiers. Ce sont eux qui savent ce qui est juste, ce qui a du sens. Mais ils n’ont ni le temps ni les outils pour valider les données à la main. C’est là qu’interviennent les plateformes no-code / low-code comme Dataiku ou Tellery. Elles permettent à un utilisateur métier de définir ses propres règles (“le chiffre d’affaires ne peut pas être négatif”, “le champ adresse ne doit pas être vide”) sans écrire une ligne de code. On y ajoute des alertes automatiques sur Slack ou Teams pour les anomalies, et des tableaux de bord de qualité intégrés.
Concernant la formation, elle doit être concrète. Pas une session de deux heures sur le RGPD, mais des ateliers pratiques : nettoyer un jeu de données, annoter des documents, comprendre les biais d’un modèle. Chez un assureur, on a formé les souscripteurs à annoter 10 % de leurs données chaque mois via une interface simple. Résultat : +25 % de précision sur les modèles de tarification.

Comment prendre en compte la réglementation en vigueur (RGPD et autres) dans la stratégie datas et IA ? Faut-il procéder à un audit approfondi du patrimoine existant de données ?

L’IA ne se construit pas sans cadre. Le RGPD, et demain l’AI Act, imposent une traçabilité complète des données, en particulier pour les systèmes à haut risque. Le point de départ, c’est l’audit data. Identifier les données sensibles, les biais potentiels, les traitements non conformes. Des outils comme OneTrust ou BigID facilitent cet inventaire, mais l’essentiel, encore une fois, reste organisationnel, c’est donc d’impliquer le DPO, le juridique et les équipes data dès la conception. Ensuite, il faut penser privacy by design avec la pseudonymisation, du chiffrement, du contrôle d’accès et une journalisation des accès. C’est un investissement, mais il rapporte. Un client a évité une amende de deux millions d’euros après avoir découvert, grâce à un audit, que ses données clients non anonymisées étaient utilisées dans un modèle de scoring.

Ce passage à l’échelle d’un projet IA (de type RAG ou moteurs de recherche sémantique) ne peut se faire que si l'infrastructure de stockage supportent des volumes importants tout en garantissant performances et sécurité et que si l’on utilise en interne des solutions de lakehouse ou de bases vectorielles comme Pinecone ou Weaviate. Qu’en pensez-vous, faut-il d’un outillage adapté ?

Passer d’un prototype IA à un système de production, c’est un changement d’échelle. Les projets RAG ou sémantiques ne peuvent tourner efficacement que si l’infrastructure suit, c’est-à-dire de disposer d’un stockage performant, d’une base vectorielle rapide et d’une sécurité intégrée. Les architectures lakehouse (Databricks, Snowflake…) sont aujourd’hui la norme : elles unifient data lake et data warehouse avec une gouvernance intégrée. Côté sémantique, les bases vectorielles (Pinecone, Weaviate, Qdrant) permettent de faire de la recherche contextuelle à grande échelle. Et pour les environnements sensibles, on adopte des architectures hybrides : cloud pour l’élasticité, on-premise pour les données critiques. L’outillage est un accélérateur, pas une fin en soi. Chez un industriel, nous avons réduit les coûts de 40 % en optimisant les index vectoriels et en adoptant une stratégie multi-cloud, Azure pour l’IA, AWS pour l’analytique.