Data Quality : mesurer, alerter, corriger, dans cet ordre
Exactitude, complétude, fraîcheur, cohérence, unicité : mesurer la qualité dans les pipelines, alerter les bonnes personnes et corriger à la source.
Un tableau de bord faux est pire qu'un tableau de bord absent : il donne confiance. Dans un contexte industriel, une donnée erronée se traduit par une commande passée en double, un stock fantôme ou une maintenance planifiée sur la mauvaise machine. La qualité des données ne se décrète pas ; elle se mesure, elle déclenche des alertes, et elle se corrige à la source. Dans cet ordre.
Les cinq dimensions de la qualité
Parler de « données de qualité » ne veut rien dire tant qu'on n'a pas précisé ce qu'on attend. Cinq dimensions couvrent l'essentiel.
L'exactitude. La valeur enregistrée correspond-elle à la réalité ? Une température lue par un capteur décalibré est complète, fraîche et cohérente, mais fausse.
La complétude. Les champs attendus sont-ils remplis ? Un ordre de fabrication sans référence article, une intervention de maintenance sans durée, une commande fournisseur sans date de livraison prévue : autant de trous qui rendent les analyses impossibles.
La fraîcheur. La donnée est-elle arrivée dans les délais attendus ? Ce qui convient à un rapport mensuel est inacceptable pour un ordonnancement en temps réel.
La cohérence. Les données concordent-elles entre elles ? Une quantité produite supérieure à la quantité lancée, une date de fin antérieure à la date de début, un total qui ne correspond pas à la somme des lignes.
L'unicité. Chaque objet réel n'apparaît-il qu'une fois ? Les doublons de références articles, de fournisseurs ou d'équipements sont le mal chronique des systèmes industriels.
Mesurer : des contrôles automatisés dans les pipelines
La qualité ne se mesure pas une fois par an dans un audit. Elle se mesure à chaque exécution du pipeline, automatiquement.
Les tests dans dbt
Un outil de transformation comme dbt permet de déclarer des tests à côté des modèles de données. Les tests de base couvrent déjà beaucoup : une colonne ne doit pas être nulle, une clé doit être unique, une valeur doit appartenir à une liste fermée, une clé étrangère doit exister dans la table de référence.
Des tests plus riches expriment des règles métier : la quantité produite ne dépasse pas la quantité lancée, la date de fin d'intervention est postérieure à la date de début, le taux de rebut reste dans une plage plausible. Ces règles s'écrivent en SQL, sont versionnées avec le code et relues comme lui. Une transformation qui viole une règle n'alimente pas silencieusement le tableau de bord de la direction.
Les règles d'intégrité en amont
Certaines règles doivent vivre dans les systèmes sources : une nomenclature sans référence valide ou un badge affecté à deux personnes ne devraient pas pouvoir être enregistrés. Quand la plateforme détecte ce type d'anomalie, elle révèle un défaut du système source ou du processus de saisie, qu'il faut remonter.
Les contrôles de fraîcheur
Sur une plateforme comme Snowflake, il est simple de vérifier l'heure de dernière mise à jour de chaque table et de la comparer à un seuil attendu. Un flux de production qui n'a rien reçu depuis le début de l'équipe du matin signale un problème d'intégration, une panne d'automate ou un arrêt de ligne.
Alerter : les bonnes personnes, au bon niveau
Mesurer sans alerter revient à installer un détecteur de fumée sans sirène. Mais alerter tout le monde de tout revient à débrancher la sirène au bout d'une semaine.
Des indicateurs lisibles. Pour chaque domaine, quelques indicateurs suffisent : part d'enregistrements passant l'ensemble des tests, nombre de règles en échec, ancienneté de la dernière mise à jour. Ils sont affichés sur un tableau de bord accessible aux propriétaires de données.
Des alertes hiérarchisées. Un test de fraîcheur en échec sur un flux critique déclenche une notification immédiate à l'exploitation. Une règle métier en échec sur quelques lignes génère un rapport quotidien au propriétaire des données. Une dérive lente de la complétude fait l'objet d'une revue mensuelle. Trois niveaux, trois destinataires, trois rythmes.
Un destinataire nommé. Une alerte envoyée à une liste de diffusion n'est traitée par personne. Chaque alerte a un responsable, qui la prend en charge ou la réassigne explicitement.
Responsabilité métier, responsabilité IT
L'IT est souvent tenue pour responsable de la qualité des données, alors qu'elle n'en produit aucune. Elle les transporte, les transforme et les expose.
Le métier est responsable du contenu. Le propriétaire de données définit les règles, arbitre les cas ambigus et fait corriger les saisies erronées dans les systèmes qu'il pilote.
L'IT est responsable de la mécanique. L'équipe de la plateforme implémente les tests, garantit que les pipelines s'exécutent, que les alertes partent et que les indicateurs sont fiables. Elle est garante du fait que la mesure est juste, pas du fait que la donnée l'est.
Sans propriétaires nommés, la qualité reste un sujet technique sans pilote.
Corriger : à la source, sinon ce n'est pas corrigé
La tentation est grande de corriger dans la plateforme. Cela fonctionne un temps, puis les règles de correction s'accumulent, et la plateforme finit par afficher une réalité qui n'existe dans aucun système source.
La boucle saine passe par la source.
- Le test détecte l'anomalie et l'attribue à un propriétaire.
- Le propriétaire qualifie : erreur de saisie, défaut de processus, règle mal définie.
- La correction est faite dans le système source (ERP, gestion de maintenance, référentiel).
- Si l'anomalie se répète, la cause est traitée : formation, contrôle de saisie ajouté à la source, règle clarifiée.
Les corrections dans la plateforme restent possibles, mais elles doivent être temporaires, documentées et liées à un ticket de correction à la source.
Pourquoi une IA sur des données non fiables est dangereuse
Un modèle de langage ne sait pas qu'une donnée est fausse. Interrogé sur le stock disponible d'une référence, un assistant qui s'appuie sur un doublon de nomenclature répondra une quantité doublée avec la même assurance qu'une quantité juste.
Le danger n'est pas dans l'IA. Il est dans la confiance qu'inspire une réponse bien formulée. Un tableau de bord faux peut être contesté par un lecteur expérimenté ; une réponse en langage naturel, fluide et argumentée, est bien plus difficile à remettre en question.
C'est pourquoi les contrôles de qualité sont un préalable à tout usage d'IA sur des données d'entreprise. Un système de recherche augmentée par génération (RAG), un assistant analytique, un agent qui déclenche des actions : tous héritent de la qualité des données qu'on leur donne. Quel que soit le modèle, Claude, GPT, Mistral ou un modèle interne, la sortie ne sera jamais plus fiable que l'entrée.
La gouvernance et la qualité des données ne freinent donc pas l'IA. Elles sont ce qui permet de lui dire oui, en sachant sur quoi elle s'appuie.
À retenir
- La qualité a cinq dimensions : exactitude, complétude, fraîcheur, cohérence, unicité.
- Les tests vivent dans les pipelines, versionnés avec le code, exécutés à chaque transformation.
- Les alertes sont hiérarchisées et adressées à des personnes nommées.
- Le métier est responsable du contenu ; l'IT est responsable de la mécanique de mesure.
- Une correction qui ne remonte pas à la source n'est pas une correction.
- Une IA sur des données non fiables produit des erreurs convaincantes : la qualité est un préalable.
Checklist
- Chaque domaine a des règles de qualité écrites et validées par son propriétaire.
- Les tests de base (non nul, unique, référence existante) sont déclarés sur tous les modèles exposés.
- Les règles métier critiques sont traduites en tests versionnés.
- La fraîcheur de chaque flux critique est contrôlée contre un seuil attendu.
- Chaque correction dans la plateforme est liée à un ticket de correction à la source.
- Aucun usage IA n'est ouvert sur un domaine dont les tests de qualité ne passent pas.