Qualité des données : qui accepte les exceptions ?

La qualité se décide à partir d’un usage

Le tableau de contrôle est presque entièrement vert. Quelques lignes restent incomplètes, mais la livraison approche. Faut-il bloquer le flux, corriger à la main ou poursuivre avec une réserve ? La difficulté n’est plus de détecter l’anomalie : elle est de savoir qui peut accepter ses conséquences, pour quel usage et pendant combien de temps.

Notre point de vue : une exception acceptable est une décision limitée, explicite et réexaminable. Elle ne transforme pas une donnée incorrecte en donnée correcte. Elle autorise un usage précis malgré un écart connu, avec des protections et une personne habilitée à décider.

Un champ manquant n’a pas le même effet dans une exploration interne et dans une instruction de paiement. Commencez donc par nommer le service rendu : préparer une relance, suivre un stock, établir une facture, alimenter un modèle. Puis identifiez ce que l’erreur empêcherait ou ferait faire à tort. Ce raisonnement donne une priorité aux corrections que ne fournit pas un score global.

La note du W3C Data Quality Vocabulary propose de décrire mesures, annotations et politiques de qualité pour aider les utilisateurs à juger l’adéquation des données à leur usage. Elle ne prescrit ni un seuil universel ni la personne qui doit accepter une exception. L’organisation ci-dessous est notre proposition pratique.

Mesurer sans masquer les écarts

Une règle exploitable précise la population contrôlée, la période, la source et le résultat attendu. « Les adresses sont complètes » est insuffisant. « Chaque commande destinée à l’expédition dispose des informations nécessaires à sa livraison » rapproche le contrôle de son effet opérationnel.

Conservez le nombre de lignes contrôlées, le nombre d’écarts, les exclusions et la date du contrôle. Une amélioration du pourcentage peut venir d’un changement de périmètre ; elle ne prouve pas que les anciennes anomalies ont disparu. Examinez aussi leur concentration : un petit volume peut concerner un client stratégique, une clôture ou une opération difficile à annuler.

Le seuil doit être justifié par l’usage et la capacité de traitement. Si une équipe accepte une vérification manuelle, son volume quotidien et sa disponibilité deviennent des conditions de la décision. Quand ces conditions ne sont plus réunies, l’autorisation doit être revue.

Séparer les responsabilités sans multiplier les comités

Le responsable du flux établit le diagnostic technique, conserve les éléments de contrôle et propose la correction. Le responsable de l’usage apprécie l’effet métier et décide dans le cadre de sa délégation. Le responsable du traitement suit la résolution et présente la preuve de clôture. Une même personne peut cumuler certains rôles dans une petite équipe, mais ces responsabilités doivent rester explicites.

Si plusieurs usages sont concernés, l’accord d’une seule équipe ne couvre pas automatiquement les autres. Une donnée peut être utilisable pour un indicateur exploratoire et exclue d’un processus transactionnel. Si l’écart dépasse la délégation disponible, l’équipe le remonte au décideur prévu ; l’absence de réponse ne vaut pas acceptation.

Le rôle du consultant est de rendre la décision possible : qualifier l’impact, rapprocher les interlocuteurs, mettre en place le contrôle et rendre le suivi simple. L’acceptation du risque reste portée par l’autorité désignée dans l’organisation.

Choisir une réponse proportionnée

Sur petit écran, faites défiler le tableau horizontalement pour lire toutes les colonnes.

Ces réponses ne constituent pas une échelle automatique. Une contrainte contractuelle ou réglementaire ne disparaît pas parce qu’un responsable accepte une réserve. Les exigences applicables au projet restent à vérifier avec les fonctions compétentes.

Exemple fictif : un reporting commercial incomplet

Situation illustrative, sans référence à une mission client. Une équipe prépare un reporting hebdomadaire. Certaines opportunités n’ont pas de secteur d’activité renseigné. Le total commercial reste calculable, mais la ventilation par secteur est incomplète.

Le responsable du reporting peut décider de diffuser le total et une ventilation portant une catégorie « non renseigné », plutôt que d’affecter arbitrairement ces opportunités à un secteur. L’équipe vérifie que les lecteurs comprennent cette limite. Le responsable des données commerciales prend en charge la correction et une date de revue est fixée avant le reporting suivant.

Cette décision ne couvre pas un autre usage qui exige un secteur fiable. Elle est retirée si la part non renseignée dépasse la capacité d’interprétation convenue ou si le périmètre touché change. Après correction, l’équipe rejoue le contrôle, vérifie la ventilation et consigne la clôture. Un ticket marqué « traité » sans nouveau contrôle ne suffit pas.

Une fiche d’exception qui tient sur une page

• Usage et périmètre : quelle décision ou opération utilise ces données ?
• Écart observé : règle, population, volume, date et preuve du contrôle.
• Conséquence : ce qui peut être retardé, faussé ou déclenché à tort.
• Décision : corriger, isoler, autoriser temporairement ou suspendre.
• Responsables : qui décide, qui corrige, qui vérifie la clôture ?
• Protection : restriction, information des utilisateurs ou contrôle complémentaire.
• Validité : date de revue et événement qui invalide l’accord.
• Clôture : résultat du contrôle rejoué et usages à rétablir.

Une référence vers le contrôle et le ticket de correction suffit souvent : il est inutile de recopier les mêmes informations dans plusieurs outils. La fiche doit rendre la décision retrouvable, pas créer une nouvelle charge documentaire.

Que faire avec ces résultats ?

Si l’impact reste inconnu : limitez d’abord l’usage concerné et faites qualifier les conséquences. Chercher un meilleur score ne répondra pas à cette incertitude.

Si l’exception est maîtrisée : enregistrez la décision, les protections et sa date de fin. Vérifiez que les personnes qui exploitent les données voient effectivement la réserve.

Si les exceptions reviennent : examinez la saisie, les transformations, le contrat d’interface et les définitions. Un traitement manuel récurrent signale une amélioration à apporter au fonctionnement, pas seulement un retard à résorber.

Pour commencer, sélectionnez un flux utile au métier et quelques exceptions ouvertes. Reconstituez leur usage, leur propriétaire et leur échéance. À la revue suivante, regardez les exceptions arrivées à expiration, les récidives et les corrections vérifiées, plutôt qu’un simple nombre de tickets fermés.

Spark peut mobiliser les compétences Data Engineering nécessaires pour fiabiliser les flux, rendre les contrôles exploitables et travailler avec les équipes métier. Pour prolonger : la qualité des données avant un projet IA et les définitions derrière les écarts de reporting.

Échanger sur votre besoin Data →