KPI data-driven pour les équipes produit et risque

Un analyste fraude d'une banque digitale de taille moyenne ouvre le dashboard du matin : le match rate de la vérification d'identité est passé de 96 % à 89 % du jour au lendemain. Personne n'a touché au modèle. Ce qui a changé, c'est un flux de données d'un bureau de 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 →édit qui a commencé à renvoyer des champs d'adresse incomplets. Trois heures plus tard, la conversion à l'onboarding est en baisse de 14 %, et personne dans la salle ne sait s'il s'agit d'un problème de données ou d'un problème de risque. C'est les deux, et c'est tout l'objet de cette leçon.

Les directions produit et risque en fintech ne lisent pas les logs brut de qualité de données. Elles lisent des KPIKPIKey Performance Indicator : une valeur mesurable qui montre l'efficacité avec laquelle vous atteignez un objectif précis, suivie dans le temps par rapport à une cible.Voir la définition complète → (key performance indicators) : des chiffres compacts qui traduisent la santé des données sous-jacentes en décisions business. Votre travail, que vous soyez data analyst, product manager ou responsable risque, consiste à construire le pont entre les deux.

Les données derrière les KPI

Avant qu'un KPI ne signifie quoi que ce soit, il faut savoir ce qui l'alimente.

Données d'identité et de vérification : scans de pièces d'identité, biométrie selfie, empreintes d'appareil, données opérateur téléphonique. Utilisées dans les contrôles KYC (Know Your Customer, l'obligation réglementaire de vérifier l'identité du client) et KYB (Know Your Business).

Données de crédit et de bureau : de fournisseurs comme Experian, Equifax, TransUnion aux États-Unis, ou Schufa en Allemagne et des données d'open bankingopen bankingCadre réglementaire (PSD2 en Europe) obligeant les banques à partager les données clients via des API standardisées, avec consentement, transformant les données bancaires en actif compétitif. type Credit Kudos au Royaume-Uni. Alimentent l'underwriting et le scoring de risque.

Données de transaction : réseaux cartes (Visa, Mastercard), ACH (Automated Clearing House, le rail de virements bancaires américain), virements SEPA (Single Euro Payments Area). C'est la donnée au plus fort volume et à la plus forte vélocité que traitent la plupart des fintechs.

Données open banking / de compte : via des agrégateurs comme Plaid (US) ou des acteurs régulés sous DSP2 (la Payment Services Directive 2 européenne, qui impose le partage des données bancaires via APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète →) en Europe.

Données comportementales et d'appareil : logs de session, usage de l'app, géolocalisation. De plus en plus utilisées dans les modèles de fraude.

Chaque source a une fréquence de rafraîchissement, un profil d'erreur et une sensibilité réglementaire différents. Un KPI ne vaut que la plus faible des sources de données qui l'alimentent.

De la qualité de données aux KPI business

Voici la couche de traduction. Les équipes data mesurent la qualité ; la direction veut de la performance.

Match rate

Ce qu'il mesure : le pourcentage d'enregistrements qui se relient avec succès entre deux jeux de données, par exemple une pièce d'identité soumise correspondant à un enregistrement de bureau, ou une transaction correspondant à un profil client connu.

Pourquoi la direction s'y intéresse : un match rate faible signifie des coûts de revue manuelle plus élevés, un onboarding plus lent et une exposition réglementaire potentielle (clients non vérifiés au regard des règles KYC).

Exemple chiffré : une néobanque traite 10 000 demandes d'onboarding. 8 700 matchent automatiquement avec les données de bureau au premier passage. Match rate = 8 700 / 10 000 = 87 %. Si le benchmark interne acceptable est de 92 % et plus (une cible informelle courante citée par des fournisseurs de vérification d'identité comme Jumio et Onfido, à titre d'estimation), un écart de 5 points signale soit un problème de flux de données, soit une hausse réelle des demandeurs thin-file (peu d'historique de crédit).

Decision latency

Ce qu'elle mesure : le temps entre la réception des données et une décision de risque ou de crédit. Souvent décomposée en sous-métriques : temps d'ingestion des données, temps de scoring du modèle, temps de revue humaine.

Pourquoi la direction s'y intéresse : la latence affecte directement la conversion. Chaque seconde supplémentaire dans un parcours d'approbation de prêt est corrélée à de l'abandon ; les benchmarks UX en fintech citent couramment des hausses d'abandon notables au-delà de 3 à 5 secondes d'attente, même si les chiffres exacts varient selon le produit et doivent être considérés comme des estimations directionnelles.

Exemple chiffré : un acteur BNPL (buy-now-pay-later) vise des décisions en moins de 2 secondes au checkout. Si le temps de réponse de l'API du bureau passe de 400 ms à 1,8 seconde aux heures de pointe, la decision latency totale peut dépasser 2,5 secondes, ce qui rompt le SLASLAEngagement formel définissant le niveau de service qu'un fournisseur garantit à un client, avec des objectifs mesurables et des conséquences en cas de manquement.Voir la définition complète → (service-level agreement) et déclenche des abandons de panier.

Data coverage ratio

Ce qu'il mesure : la proportion de clients ou de transactions pour lesquels un champ de données requis est présent et exploitable, par opposition à manquant ou nul.

Pourquoi la direction s'y intéresse : les trous de couverturecouvertureLe nombre de personnes uniques exposées à votre message sur une période donnée. Contrairement aux impressions, le reach compte chaque personne une seule fois, quel que soit le nombre d'expositions.Voir la définition complète → biaisent silencieusement les modèles de risque. Si les données de revenu manquent de façon disproportionnée pour les demandeurs de la gig economy, le modèle soit les rejette par défaut, soit les score sur une information incomplète, un enjeu de fair lending au regard de lois comme l'Equal Credit Opportunity Act américain (ECOA).

Exemple chiffré : sur 50 000 comptes de prêt actifs, 46 500 disposent de données complètes de vérification de revenu. Coverage ratio = 46 500 / 50 000 = 93 %. Segmentez par canal : si la couverture tombe à 78 % pour une intégration partenaire spécifique, c'est là l'insight actionnable, pas le chiffre agrégé.

Les métriques de gouvernance qui se trouvent en dessous

Les KPI produit et risque reposent sur des fondamentaux de gouvernance qui apparaissent rarement directement sur le dashboard de la direction mais qui expliquent pourquoi il bouge :

• Complétude : pourcentage de champs requis renseignés.
• Fraîcheur : actualité de la donnée, par exemple le flux du bureau est-il mis à jour quotidiennement ou hebdomadairement.
• Exactitude : validée contre une source de vérité de confiance.
• Lineage : pouvez-vous retracer un chiffre jusqu'à son système d'origine, point critique pour les audits dans des cadres comme SR 11-7 (guidance de la Fed américaine sur la gestion du risque modèle) ou DORA (Digital Operational Resilience Act européen, applicable en 2025).

Un contrôle de gouvernance simple, exécuté en Python sur un flux de transactions, peut ressembler à ceci :

import pandas as pd

df = pd.read_csv("transactions.csv")

completeness = df["customer_id"].notna().mean()
timeliness_hours = (pd.Timestamp.now() - df["ingested_at"].max()).total_seconds() / 3600

print(f"Completeness: {completeness:.1%}")
print(f"Data freshness (hours since last record): {timeliness_hours:.1f}")

Ce type de contrôle alimente le coverage ratio et les KPI de latence ci-dessus. Ce n'est pas glamour, mais c'est la plomberie.

Construire le dashboard de direction fictif

Quand vous briefez la direction, structurez le dashboard en trois niveaux :

1. KPI de tête (match rate, decision latency, coverage ratio) : courbes de tendance, semaine après semaine, avec un seuil ou une ligne de cible claire.
2. Décompositions par segment : par canal, produit, géographie. Les agrégats masquent la vraie histoire, comme dans l'exemple du coverage ratio ci-dessus.
3. Marqueurs de cause racine : une courte couche d'annotations signalant les incidents de données connus (par exemple « API bureau dégradée de 03:00 à 06:00 UTC ») pour que la direction ne confonde pas une panne de pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète → avec un échec de stratégie.

Sources de benchmark à connaître : le Consumer Financial Protection Bureau publie des données de fair lending et de réclamations utiles pour recouper les trous de couverture aux États-Unis. En Europe, l'European Banking Authority publie des lignes directrices sur la gestion du risque TIC et données, pertinentes pour la conformité DORA.

🎬 [VIDEO: "How Fintechs Use Data to Make Real-Time Decisions" - youtube.com/results?search_query=fintech+real+time+data+decisions - cherchez du contenu explicatif récent de plateformes data fintech comme Plaid ou Marqeta sur l'architecture de décision en temps réel]

Points clés

• Le match rate, la decision latency et le data coverage ratio sont la couche de traduction entre la qualité brute des données et ce sur quoi les directions produit et risque agissent réellement.
• Chaque KPI remonte à une source de données spécifique (flux de bureau, fournisseurs KYC, rails de transaction) dont la fréquence de rafraîchissement et le profil d'erreur plafonnent la fiabilité du KPI.
• Les chiffres agrégés masquent le risque. Segmentez toujours par canal ou produit avant de présenter une métrique de tête.
• Les fondamentaux de gouvernance (complétude, fraîcheur, exactitude, lineage) sont la plomberie sous le dashboard ; quand un KPI bouge de façon inattendue, vérifiez-les d'abord.
• Les cadres réglementaires (ECOA, DORA, DSP2) ne sont pas de simples cases juridiques à cocher, ils déterminent directement quels trous de qualité de données portent un vrai risque business et de conformité.