mesurer la santé d'un pipeline : SLA, drift et downtime

L'incident de 3 h du matin

À 3 h 14, l'agrégateur de bank feeds d'une néobanque de taille moyenne (un service comme Plaid ou Tink qui récupère les données de transaction des banques partenaires 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 →) a déployé une mise à jour. Personne ne l'a annoncée. Un champ appelé transaction_type est discrètement passé d'un code numérique (1, 2, 3) à une chaîne de texte ("debit", "credit", "transfer").

Le 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 → n'a pas planté. Il a continué à ingérer des données toute la nuit. Mais chaque job en aval qui filtrait sur les anciens codes numériques a silencieusement renvoyé zéro ligne correspondante. À 8 h, 40 000 clients ont ouvert l'application pour y voir des soldes obsolètes et des transactions manquantes. Aucune erreur, aucune alerte, juste des données fausses livrées avec une confiance totale.

C'est une défaillance de type schema drift : la structure des données entrantes change sans que le pipeline casse franchement. C'est l'un des modes de défaillance les plus fréquents et les plus difficiles à détecter dans les infrastructures data fintech, parce que « le système tourne techniquement » et « les données sont justes » sont deux affirmations différentes. Cette leçon construit les métriques qui détectent l'écart entre les deux.

Les données qui comptent : les sources à surveiller

Avant de définir des métriques, sachez ce que vous mesurez. En fintech, les sources de données les plus à risque sont :

• Les API de bank feed (Plaid, Tink, MX, Yodlee) : des agrégateurs tiers qui récupèrent les données de transaction et de solde depuis des milliers de connexions bancaires que vous ne contrôlez pas.
• Les données des réseaux cartes et des rails de paiement (Visa, Mastercard, ACH, SEPA en Europe) : fichiers de règlement et messages d'autorisation aux formats stricts.
• Les exports du core banking : données de ledger et de comptes issues d'éditeurs comme Mambu, Temenos, ou de mainframes legacy.
• Les flux des bureaux de crédit (Experian, Equifax, TransUnion aux États-Unis ; Schufa en Allemagne, Experian au Royaume-Uni) : fichiers batch qui notent la solvabilité.
• Les données KYC/AML (Know Your Customer, Anti-Money Laundering) : flux de vérification d'identité de fournisseurs comme Onfido ou LexisNexis.
• Les flux de market data : données de prix et de FX, souvent via Bloomberg ou Refinitiv, pour les fonctions trading ou trésorerie.

Chacune a une volatilité différente. Les API de bank feed changent souvent de 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 → parce que vous agrégez des centaines de formats bancaires sous-jacents. Les fichiers des réseaux cartes sont rigides et normalisés (messagerie ISO 8583), donc le drift y est plus rare mais plus perturbant quand il arrive.

Les métriques de 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 → : définir « ça fonctionne »

Un SLA (Service Level Agreement) est une promesse mesurable sur le comportement du pipeline. Pour les pipelines de données, les métriques de SLA essentielles sont :

1. Fraîcheur (latence)

Quel âge ont les données quand elles arrivent ? Exemple : « Les données de transaction doivent être disponibles dans le warehouse dans les 15 minutes suivant leur comptabilisation par la banque. »

2. Complétude

Tous les enregistrements attendus sont-ils arrivés ? Si vous attendez 50 000 lignes de transaction quotidiennes d'une banque partenaire et que vous en recevez 12 000, c'est une défaillance de complétude, même si le pipeline « s'est exécuté avec succès ».

3. Uptime / disponibilité

Pourcentage du temps pendant lequel le pipeline ou l'endpoint API est joignable et répond. Souvent exprimé en « trois neuf » (99,9 %) ou « quatre neuf » (99,99 %).

Exemple chiffré : 99,9 % d'uptime sur un mois de 30 jours autorise :

30 days × 24 hours × 60 minutes = 43,200 minutes total
Allowed downtime = 43,200 × (1 - 0.999) = 43.2 minutes/month

À comparer à 99,99 % (quatre neuf) : downtime autorisé = 4,32 minutes/mois, soit environ dix fois plus strict. Les rails de paiement et les systèmes d'autorisation carte visent généralement quatre neuf ou mieux, parce que chaque minute de downtime bloque des achats en direct. Les pipelines d'analytics internes tolèrent souvent trois neuf, un dashboard en retard étant gênant, pas visible du client.

4. Exactitude

Les données correspondent-elles à la réalité ? Plus difficile à mesurer automatiquement, généralement échantillonné par réconciliation (comparaison de la sortie du pipeline avec une source de confiance, comme le relevé de la banque elle-même).

Le data drift : le mode de défaillance silencieux

Le schemaschemaUn schema est le plan formel qui définit comment les données sont structurées, nommées, typées et reliées entre elles au sein d'une base de données, d'un fichier ou d'un message.Voir la définition complète → drift, comme dans notre exemple de 3 h du matin, en est un type. Il y en a trois à distinguer :

• Schema drift : les noms de champs, les types ou la structure changent (un code numérique devient une chaîne).
• Drift distributionnel : la forme des données change alors que le schéma reste identique. Exemple : le montant moyen des transactions passe de 45 $ à 450 $ parce qu'une nouvelle catégorie de marchands a été mal routée.
• Drift de volume : le nombre de lignes explose ou s'effondre. Un batch qui livre normalement 2 millions d'enregistrements en livre soudain 200.

Approche de détection : posez des seuils statistiques, pas seulement des contrôles de présence/absence.

# Contrôle de drift simplifié : comparer la distribution du jour à une baseline de 30 jours
import numpy as np

baseline_mean, baseline_std = 45.0, 12.0  # sur une fenêtre glissante de 30 jours
today_mean = df['transaction_amount'].mean()

z_score = (today_mean - baseline_mean) / baseline_std
if abs(z_score) > 3:
    alert("Distributional drift detected: transaction amounts")

Un z-score supérieur à 3 (trois écarts-types par rapport à la moyenne historique) est un seuil de déclenchement courant pour les alertes d'anomalie, même si le bon chiffre dépend du niveau de bruit habituel de vos données.

Parmi les outils open source conçus pour cela : Great Expectations et Evidently AI, tous deux gratuits et largement utilisés pour les contrôles automatisés de qualité de données et de drift dans les pipelines en production.

Les métriques de gouvernance : qui est responsable

La qualité des données n'est pas seulement technique, elle est organisationnelle. Les métriques de gouvernance suivent la responsabilité :

• Couverture du data lineage : pourcentage des datasets critiques dont le chemin de la source jusqu'au dashboard est documenté. Des régulateurs comme la BCE (Banque centrale européenne) et la Réserve fédérale attendent de plus en plus une documentation du lineage pour les données pertinentes en matière de risque, notamment dans le cadre de référentiels comme 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. (principes du Comité de Bâle pour l'agrégation des données de risque).
• Time to detect (TTD) : délai entre le moment où un problème de données survient et celui où il est signalé. Dans l'incident ci-dessus, le TTD était d'environ 5 heures (3 h 14 jusqu'aux plaintes clients de 8 h), et c'est là la véritable défaillance : non pas que le drift se soit produit, mais que personne ne l'ait détecté vite.
• Time to resolve (TTR) : de la détection au correctif déployé.
• Taux de récurrence des incidents : même cause racine qui se reproduit dans une fenêtre définie (par exemple 90 jours), signe que les correctifs sont des rustines, pas du structurel.

Un benchmark utile : les équipes data fintech matures visent un TTD sous les 15 minutes pour les pipelines tier-1 (ceux qui touchent aux soldes clients ou aux paiements) grâce à l'alerting automatisé, contre des heures ou des jours quand on s'appuie sur la revue manuelle ou les plaintes clients.

Construire le dashboard d'uptime qui aurait détecté l'incident

Revenons à l'incident. Quels éléments de dashboard auraient signalé le schema drift avant que les clients ne le voient ?

1. Contrôles de validation de schéma exécutés à chaque ingestion, comparant les types de champs entrants à un contrat de schéma enregistré. Des outils comme Great Expectations peuvent en faire un gate pré-ingestion.
2. Alertes d'anomalie sur le nombre de lignes : même si le volume n'a pas baissé, un changement brutal dans la *distribution des valeurs* de transaction_type (toutes les valeurs passant d'entiers à chaînes) aurait déclenché instantanément un contrôle de non-concordance de type.
3. Monitoring du taux de nulls en aval : suivez le pourcentage de résultats nuls ou sans correspondance dans les jobs dépendants. Un passage de 0,1 % à 100 % de correspondances nulles est un signal impossible à manquer si vous le surveillez.
4. Alerting sur le burn rate du SLA : comme dans la pratique Site Reliability Engineering (SRE) de Google qui suit le « error budget burn rateburn rateLe burn rate est la vitesse à laquelle une entreprise consomme sa trésorerie, généralement mesurée par mois, avant d'atteindre la rentabilité ou de lever de nouveaux fonds.Voir la définition complète → », les équipes peuvent alerter non seulement sur un dépassement de complétude, mais sur la *vitesse* à laquelle la métrique de complétude se dégrade.

Le point commun : aucun de ces dispositifs n'exige de prédire la défaillance précise. Ils exigent de monitorer les *propriétés* de données saines (schéma, distribution, complétude, fraîcheur) et d'alerter sur la déviation, quelle qu'en soit la cause.

Points clés

• Les métriques de SLA (fraîcheur, complétude, uptime, exactitude) définissent numériquement ce que « sain » signifie. Un pipeline qui « tourne » mais perd silencieusement des données n'est pas sain au sens de ces définitions.
• Le drift existe en trois variantes : schéma, distribution et volume. Les incidents les plus coûteux relèvent du drift distributionnel ou de schéma, parce que le pipeline ne plante pas, il devient simplement faux en silence.
• Le time to detect (TTD) compte plus que le time to resolve. Un écart de détection de cinq heures, comme dans le scénario de 3 h du matin, est souvent la vraie cause racine du dommage visible par le client, plus que le changement de schéma lui-même.
• Les seuils statistiques (comme les z-scores) et les contrats de schéma transforment « surveiller les données » en un contrôle automatisable et testable, au lieu de compter sur le fait que quelqu'un remarque quelque chose.
• Les métriques de gouvernance comme la couverture du lineage et le taux de récurrence des incidents intéressent les régulateurs (BCE, Réserve fédérale, principes BCBS 239) autant que les ingénieurs, car « qui est responsable de ce dataset » est désormais une question de supervision, pas seulement une affaire interne.