Une règle absente derrière un tableau rassurant
Dans cette scène fictive située en 2021, une équipe prépare le lancement d’un outil de planification. Le tableau de bord affiche un taux de complétude de 98 %, mais deux agences attribuent des significations différentes au champ « date disponible ». L’une indique la réception physique ; l’autre indique la fin du contrôle. Le planning additionne ces valeurs comme si elles décrivaient le même événement. Tous les chiffres, personnages et résultats qui suivent sont inventés à des fins pédagogiques. Aucun ne représente une mission client de CYTIZEN. Le problème n’est pas un manque de cellules remplies : c’est une décision métier non explicitée.
La qualité des données devient un projet caché lorsque le programme promet une capacité nouvelle sans traiter les règles nécessaires pour l’utiliser. Nettoyer un fichier avant migration peut masquer le défaut sans empêcher son retour. L’enjeu est de décider ce que les valeurs signifient, quelles erreurs empêchent quelle décision, qui corrige la cause et comment une exception reste visible. Cette analyse revient sur le contexte de 2021 avec des sources officielles consultées en octobre 2026. Le cadre gouvernemental britannique publié en décembre 2020 constitue un repère historique ; les versions actuelles des pages sont identifiées comme telles.
Partir d’une décision précise
La première question n’est pas « nos données sont-elles bonnes ? », mais « quelle décision doit-on prendre avec elles ? ». Pour le planning fictif, il faut décider si un lot peut être promis à une date donnée. Le responsable opérationnel précise les événements nécessaires : réception, contrôle terminé, disponibilité au bon emplacement. Un même champ ne peut pas remplacer ces trois événements sans une règle explicite. Le programme identifie alors les données critiques pour cette décision, au lieu de mesurer indistinctement tous les champs disponibles dans le système.
La mesure doit combiner plusieurs dimensions selon l’usage. Une date peut être présente, conforme au format et pourtant fausse. Une référence peut être exacte mais arrivée trop tard pour être utile. Un identifiant peut apparaître une seule fois tout en désignant le mauvais objet. Le propriétaire métier explique les conséquences de chaque défaut. Cela permet de choisir une sévérité et une réaction proportionnées. Le seuil n’est pas un objectif décoratif : il doit dire si la décision reste possible, nécessite une revue humaine ou doit être suspendue.
Transformer les définitions en règles exécutables
Pour chaque donnée critique, rédiger une règle qui comprend le périmètre, le test, le moment d’application, la réaction et le propriétaire. « Date correcte » est trop vague. « Pour un lot proposé à la vente, la date de disponibilité correspond au contrôle final terminé et ne précède pas la réception » peut devenir un contrôle. Les cas historiques ou les imports particuliers demandent des règles adaptées. Une validation syntaxique peut s’exécuter automatiquement ; une contradiction métier peut exiger une comparaison avec une preuve ou une décision d’un responsable habilité.
La définition se négocie avec les personnes qui produisent, utilisent et corrigent la donnée. L’équipe technique peut implémenter un contrôle, mais elle ne devrait pas décider seule quelle version de la vérité métier prévaut. Dans la scène, les opérations choisissent de conserver deux dates distinctes. La finance demande de préserver les événements utiles à ses rapprochements. Le responsable de planification accepte un blocage lorsqu’un contrôle final manque. La décision est enregistrée avec sa date d’effet et une méthode de traitement des anciens dossiers, pour éviter un changement silencieux de sens.
Une règle possède une version. Si la définition change, le programme précise si les mesures précédentes restent comparables. Un taux de défaut peut baisser parce que le périmètre a rétréci ou qu’un contrôle a été désactivé ; ce n’est pas une amélioration de qualité. Le rapport doit donc associer le résultat à la population testée et à la version des règles. Les exclusions sont comptées et motivées. L’utilisateur voit ce qui a été contrôlé, ce qui ne l’a pas été et ce que la mesure permet réellement de conclure.
Un registre de règles et de décisions rempli
Le tableau ci-dessous est un modèle fictif rempli. Les seuils illustrent des choix de contrôle pour une décision définie ; ils ne constituent pas une norme sectorielle. Le registre complet ajoute la source des données, le responsable de correction, l’échéance et la preuve. Il distingue une erreur détectée, une exception autorisée et une règle qui doit être rediscutée.
| Décision et donnée | Règle fictive | Réaction et responsable | Exception documentée |
|---|---|---|---|
| Promettre un lot ; contrôle final | Statut terminé et date présente pour chaque lot proposé | Bloquer la promesse ; responsable qualité atelier | Lot de démonstration exclu de la vente, justification et date de fin |
| Rapprocher une réception ; référence fournisseur | Référence liée à un fournisseur actif et au document reçu | File de revue ; gestionnaire achats | Fournisseur temporaire, validation du responsable achats |
| Calculer le délai ; événements | Contrôle final postérieur ou égal à la réception | Corriger à la source ; propriétaire opérations | Reprise historique isolée, preuve du journal conservée |
Ce registre ne doit pas devenir une liste de contrôles sans usage. Chaque ligne mentionne la décision protégée et la conséquence du défaut. Cela aide à prioriser : une valeur manquante dans un champ rarement utilisé peut attendre, tandis qu’une ambiguïté dans une donnée de promesse exige un arbitrage rapide. Le propriétaire de la donnée n’est pas nécessairement celui qui saisit la valeur. Il possède l’autorité pour fixer la définition, accepter une exception et obtenir une correction durable du processus qui produit l’information.
Gérer les exceptions sans effacer les erreurs
Une exception acceptable est explicite, limitée et révisable. Elle indique le dossier concerné, la raison, le risque, le décideur et une date de réexamen. Le traitement opérationnel précise ce qui reste autorisé. Dans le scénario, un lot réservé à une démonstration peut suivre un parcours distinct, mais il ne doit pas entrer silencieusement dans le stock disponible à la vente. Une exception générale comme « les anciennes données sont imparfaites » n’aide personne à décider. Elle doit être remplacée par un périmètre, une règle transitoire et un responsable.
Le suivi affiche séparément les défauts ouverts, les corrections réalisées et les exceptions actives. Si les exceptions augmentent, le taux global ne doit pas paraître meilleur simplement parce qu’elles sont sorties du calcul. Une exception répétée peut indiquer que la règle est inadaptée, mais elle peut aussi révéler une pression pour contourner le contrôle. Le comité examine les motifs et décide de changer la règle, de réparer le flux ou de maintenir le blocage. La donnée ne devient pas fiable par la seule signature d’une dérogation.
La correction commence à la source lorsque cela est possible. Reconstituer les dates dans un entrepôt analytique protège un rapport, mais laisse les équipes opérationnelles exposées au même défaut. L’analyse cherche pourquoi la valeur est mauvaise : formulaire ambigu, responsabilité absente, interface qui tronque un code, saisie avant l’événement réel ou objectif de performance qui encourage une date anticipée. La réponse dépend de la cause. Ajouter un champ obligatoire ne résout pas une définition contradictoire ; former les utilisateurs ne répare pas une transformation incorrecte dans une interface.
Dans l’exemple, le programme introduit deux événements distincts et un contrôle de cohérence. Il vérifie ensuite si le défaut revient sur les nouveaux lots. Cette observation est plus instructive qu’une photographie juste après nettoyage. Un échantillon relu par les opérations permet de détecter les cas qui passent les contrôles automatiques mais restent faux. Le résultat doit préciser les limites de l’échantillon. Aucun contrôle ne justifie de promettre une absence totale d’erreur ; l’objectif est de rendre la décision suffisamment fiable et les incertitudes exploitables.
Faire de la qualité un critère de passage
Avant migration ou lancement, le programme fixe les règles critiques qui doivent passer, les exceptions admises et l’autorité qui accepte le risque résiduel. Le compte rendu conserve les résultats et la population testée. Un taux moyen ne suffit pas si une catégorie importante reste inutilisable. Dans la scène, le lancement peut être autorisé pour les lots standard et différé pour les lots repris d’un ancien système. Cette décision limitée évite de transformer une difficulté localisée en blocage global ou, à l’inverse, de cacher le problème derrière une moyenne favorable.
Après lancement, le service reprend le registre et les responsabilités. Les contrôles restent observés lorsque le programme disparaît. La charge de correction, le temps avant décision et les erreurs récurrentes donnent une mesure utile de la valeur. Le projet caché devient visible lorsque le sponsor comprend le coût des définitions absentes et peut financer leur résolution. Il n’est pas nécessaire de créer une vaste initiative sur toutes les données : un premier périmètre relié à une décision importante peut établir les règles de gouvernance et une méthode réutilisable.
Choisir les données critiques selon le secteur
Dans l’industrie, les événements physiques et les identifiants de lots demandent une cohérence entre atelier, logistique et planification. Dans les services financiers, une définition commune des contreparties ou des événements peut conditionner les rapprochements et les contrôles. Dans le secteur public, les données d’éligibilité doivent permettre des décisions compréhensibles et des corrections accessibles aux personnes concernées. Dans les services professionnels, les statuts de mission et les périodes de charge doivent avoir le même sens pour ceux qui planifient et ceux qui facturent.
Ces exemples sont des pistes de conception. Ils n’établissent ni seuil obligatoire ni résultat de mission. Dans chaque cas, le programme doit demander qui peut décider malgré le défaut, quelle preuve manque et quelle exception est acceptable. La qualité devient alors une relation entre données et usage, avec un propriétaire et une trace. Un tableau de bord peut soutenir cette relation ; il ne peut pas remplacer la discussion sur les règles, les conséquences et les responsabilités.
Sources officielles et date de consultation
Sources consultées en octobre 2026. Le cadre britannique de 2020 insiste sur une qualité adaptée à l’usage ; sa guidance accompagne une démarche structurée. Les règles, seuils et cas de cet article sont des constructions pédagogiques et ne sont pas des prescriptions extraites de ces pages.
- GOV.UK — The Government Data Quality Framework, publié le 3 décembre 2020.
- GOV.UK — The Government Data Quality Framework: guidance, publication de 2020 consultée dans sa version actuelle.