Mesurer la qualité des données avec les dimensions bancaires et les DQ scorecards

Un virement arrive avec un champ IBAN vide. Ce seul trou peut bloquer un paiement, déclencher une exception de screening sanctions, et finir en cellule rouge sur un scorecard que le Chief Data Officer (CDO) présente au conseil le trimestre suivant. La qualité des données en banque n'a rien d'abstrait. C'est la différence entre un paiement qui passe et un paiement qui reste en compte d'attente.

Cette leçon vous montre comment mesurer la qualité des données à partir de six dimensions standard, les appliquer à des enregistrements de paiement réels, et agréger les résultats dans les scorecards de pass-rate qu'attendent les régulateurs et les conseils d'administration.

Pourquoi la qualité des données est un sujet de conseil d'administration

Les banques fonctionnent avec des données qu'elles n'ont pas toujours collectées proprement. Un client entré en relation en 2009 peut avoir un enregistrement dépourvu de champs devenus obligatoires plus tard. Quand ces données alimentent des reportings réglementaires, les erreurs ressortent là où ça fait mal.

Le point d'ancrage ici, c'est BCBS 239BCBS 239Principe du Basel Committee on Banking Supervision imposant aux grandes banques une traçabilité stricte des données de risque, ayant catalysé la création de nombreux postes de CDO dans le secteur bancaire., les « Principles for effective risk data aggregation and risk reporting » du Comité de Bâle sur le contrôle bancaire (2013). Le texte impose aux grandes banques de démontrer l'exactitude, la complétude et la ponctualité des données qui sous-tendent leurs rapports de risque. Les superviseurs en Europe (la Banque centrale européenne) et aux États-Unis (la Fed, l'OCC) en vérifient activement le respect. Les principes originaux sont consultables gratuitement sur le site de la Bank for International Settlements.

Ce qu'il faut en retenir : **les banques doivent *mesurer* la qualité, pas l'affirmer**. D'où les dimensions et les scorecards.

Les six dimensions de la qualité des données

Le secteur a convergé vers six dimensions, formalisées dans des frameworks comme celui de DAMA (Data Management Association). Les voici, chacune avec un exemple bancaire.

1. Complétude

La donnée est-elle présente là où elle devrait l'être ?

Exemple : sur un virement SEPA (Single Euro Payments Area), les champs IBAN (International Bank Account Number) et BIC (Bank Identifier Code) doivent être renseignés. Un enregistrement sans IBAN échoue sur la complétude.

2. Exactitude

La donnée correspond-elle à la réalité ?

Exemple : un nom de contrepartie indique « Acme Trading Ltd » alors que l'entité juridique enregistrée est « Acme Trading GmbH ». Le champ est complet mais inexact. L'exactitude est la plus difficile à mesurer car elle suppose une référence de confiance (une « golden source »), comme un registre LEI (Legal Entity Identifier) validé.

3. Validité (conformité)

La valeur respecte-t-elle le format ou la règle exigés ?

Exemple : un IBAN a une longueur propre à chaque pays et une clé de contrôle. Un IBAN allemand fait 22 caractères. Si la clé de contrôle échoue, la valeur est invalide même si le champ est rempli.

4. Cohérence

Le même fait concorde-t-il d'un système à l'autre ?

Exemple : le pays de résidence du client est « FR » dans le core banking, « France » en toutes lettres dans l'outil de screening AML (Anti-Money Laundering), et « DE » dans le CRMCRMCustomer Relationship Management : logiciel et stratégie pour gérer et analyser les interactions clients tout au long de leur cycle de vie.Voir la définition complète →. Même client, trois réponses.

5. Unicité

Chaque entité du monde réel est-elle représentée une seule fois ?

Exemple : le même client corporate apparaît sous trois enregistrements distincts à cause d'une fusion et de deux variantes orthographiques. Les contreparties en doublon faussent les calculs d'exposition.

6. Ponctualité

La donnée est-elle à jour et disponible au moment voulu ?

Exemple : une mise à jour de liste de sanctions arrive à 09:00 mais le moteur de paiements ne se rafraîchit qu'à 18:00. Pendant neuf heures, le screening tourne sur des données périmées.

TransformerTransformerUn Transformer est une architecture de réseau de neurones qui utilise le self-attention pour traiter des séquences en parallèle. Elle est au cœur de la plupart des modèles de langage et d'IA générative actuels.Voir la définition complète → les dimensions en règles

Une dimension est un concept. Une règle DQ en est la version testable. On ne mesure pas « la complétude » ; on mesure « le pourcentage d'enregistrements de paiement où l'IBAN n'est pas nul ».

Appliquons cela à un jeu de données de paiements. Prenons un lot de 100 000 paiements SEPA sortants (chiffres illustratifs pour un exemple chiffré, pas des données bancaires réelles).

Calcul détaillé

Pass rate de complétude pour l'IBAN :

Pass rate = (Total records - Failing records) / Total records
          = (100,000 - 1,200) / 100,000
          = 98,800 / 100,000
          = 0.988 = 98.8%

Voilà l'unité atomique d'un scorecard. Chaque cellule verte, orange ou rouge que voit un conseil remonte à une fraction de ce type.

La clé de contrôle IBAN : une règle de validité en code

La validité est l'une des rares dimensions vérifiables par pure logique, sans source externe. L'IBAN suit la norme ISO 13616 avec une clé de contrôle mod-97. Voici le contrôle en Python.

def is_valid_iban(iban):
    iban = iban.replace(" ", "").upper()
    # Déplace les 4 premiers caractères à la fin
    rearranged = iban[4:] + iban[:4]
    # Convertit les lettres en chiffres : A=10, B=11, ... Z=35
    digits = ""
    for ch in rearranged:
        if ch.isdigit():
            digits += ch
        else:
            digits += str(ord(ch) - 55)
    # Valide si le grand nombre modulo 97 vaut 1
    return int(digits) % 97 == 1

print(is_valid_iban("DE89370400440532013000"))  # True

Passez ça sur une table de paiements et vous obtenez directement votre nombre d'enregistrements en échec de validité. Aucune revue manuelle. C'est pour cela que les règles de validité sont en général les gains de qualité les moins chers.

Fixer les seuils : ce qui compte comme un pass

Un pass rate ne veut rien dire sans seuil. Les banques définissent des seuils DQ par règle, souvent sur une base rouge / orange / vert (RAGRAGMéthode qui permet à un modèle d'IA de répondre à partir de vos propres documents, en récupérant les passages pertinents avant de générer une réponse.Voir la définition complète →). Un schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → courant (illustratif) :

• Vert : pass rate supérieur ou égal à 99 %
• Orange : de 95 % à 98,99 %
• Rouge : en dessous de 95 %

Les champs critiques ont des seuils plus stricts. Un champ sensible aux sanctions comme le nom de contrepartie peut exiger le vert à 99,9 %, parce qu'une seule correspondance manquée peut signifier un manquement réglementaire. Un champ de préférence marketing peut tolérer l'orange.

Appliqué à notre tableau : l'exactitude à 96,9 % tombe en orange. C'est l'histoire que le CDO devra expliquer, et le projet de réconciliation LEI qui entre au budget de l'année suivante.

Construire le DQDQLe degré d'aptitude des données à l'usage prévu : exactes, complètes, cohérentes, à jour, valides et uniques. Une data quality faible fragilise l'analytics, le reporting et l'IA.Voir la définition complète → scorecard

Un scorecard agrège les résultats au niveau des règles en quelque chose qu'un conseil assimile en 30 secondes. Il se consolide en général sur trois couches.

Couche 1 : niveau règle. Les pass rates individuels, comme dans le tableau ci-dessus.

Couche 2 : niveau dimension. Moyenne pondérée des règles d'une dimension. Si la complétude compte cinq règles, on moyenne leurs pass rates (souvent pondérés par la criticité du champ).

Couche 3 : niveau domaine. Un score unique pour un domaine de données comme « Paiements » ou « Client ». C'est ce qui apparaît sur le dashboard exécutif.

Une consolidation de domaine simple

Reprenons les six pass rates ci-dessus avec des poids égaux, par simplicité :

Domain score = (98.8 + 99.55 + 96.9 + 99.2 + 99.4 + 99.75) / 6
             = 593.6 / 6
             = 98.93%

Le domaine Paiements obtient 98,93 %, soit orange selon nos seuils. Remarquez comment la faiblesse de la dimension exactitude (96,9 %) tire tout le domaine sous le vert. Les banques réelles pondèrent plus fortement les règles critiques : une règle en échec liée aux sanctions peut donc faire chuter le score plus durement qu'une moyenne à poids égaux.

🎬 [VIDEO: "Data Quality Dimensions Explained" - youtube.com - un parcours clair de 10 minutes sur les six dimensions avec des exemples chiffrés]

Ce que le CDO rapporte réellement

Les conseils ne veulent pas 300 règles. Ils veulent :

1. Les scores par domaine avec statut RAG et tendance par rapport au trimestre précédent.
2. Les principales règles en échec à l'origine du statut rouge.
3. L'état de la remédiation : ce qui est corrigé et pour quand.
4. L'exposition réglementaire : quels échecs touchent les rapports BCBS 239.

Le scorecard est un instrument de gouvernance. Il crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →ée de la responsabilité en nommant un data owner pour chaque domaine, en général un dirigeant métier senior, pas l'IT. Quand Paiements passe au rouge, un dirigeant nommément désigné en répond.

Pièges de mesure courants

Diluer le risque dans la moyenne. Un score de domaine à 98,9 % peut masquer un champ sanctions à 92 %. Faites toujours remonter séparément les échecs sur champs critiques.

Se tromper de dénominateur. Si vous mesurez la complétude de l'IBAN uniquement sur les enregistrements où le champ a été soumis, vous passez à côté de ceux perdus en amont. Mesurez sur la population attendue complète.

Des règles sans propriétaire. Une règle en échec dont personne n'est responsable reste rouge indéfiniment. Chaque règle a besoin d'un propriétaire métier et d'un chemin de remédiation.

Des seuils figés. À mesure que les attentes réglementaires se durcissent, le vert d'hier devient l'orange d'aujourd'hui. Révisez les seuils au moins une fois par an.

À retenir

• Les six dimensions DQ (complétude, exactitude, validité, cohérence, unicité, ponctualité) ne deviennent mesurables qu'une fois traduites en règles testables avec un dénominateur clair.
• Pass rate = (total des enregistrements moins enregistrements en échec) / total des enregistrements. Chaque cellule de scorecard se ramène à cette fraction.
• Les contrôles de validité comme la clé de contrôle mod-97 de l'IBAN s'automatisent à faible coût ; l'exactitude exige une golden source de confiance et reste la plus difficile et la plus coûteuse à corriger.
• Fixez des seuils RAG par règle, plus stricts pour les champs liés aux sanctions et au réglementaire, et ne laissez jamais une moyenne de domaine élevée masquer un échec sur champ critique.
• BCBS 239 fait de la qualité de données mesurable une attente du superviseur : les scorecards avec data owners nommés sont des outils de gouvernance, pas de simples dashboards.