Par Andrew Tan
Tableaux de bord trompeurs
De nombreuses entreprises dépensent plus de six chiffres pour des outils de traçabilité des données. Leurs démonstrations sont impressionnantes : des visualisations tentaculaires montrant chaque table, pipeline et dépendance à travers un entrepôt de données. Les couleurs indiquent la fraîcheur. Les flèches montrent le flux de données. Cela ressemble à la salle de contrôle d'une centrale nucléaire.
Tout cela est formidable et sophistiqué, mais l'une des questions sans réponse est ce qui se passe lorsque la table X contient de mauvaises données.
Vous pouvez cliquer sur les diagrammes, zoomer et vous déplacer, localiser la table, inspecter les consommateurs en aval et les transformations auxquelles elle a contribué. Et puis vous pouvez constater que douze tableaux de bord utilisent 'adresse client'.
La vraie question, cependant, est de savoir quels processus métier se brisent. L'expédition s'arrête-t-elle ? Les factures vont-elles au mauvais endroit ? Les rapports de conformité échouent-ils ? Vous voyez l'idée.
Le tableau de bord sait que les données ont circulé de A à B, mais il n'a aucune idée de ce que B était réellement pour.
Théâtre de la traçabilité
C'est ce que j'appelle le théâtre de la traçabilité : la pratique consistant à construire des diagrammes de flux de données impressionnants qui satisfont les listes de contrôle de conformité et les démonstrations des fournisseurs, mais qui n'aident pas réellement lorsque les choses se cassent.
Les fournisseurs d'outils ont optimisé pour la mauvaise chose. Ils vendent des visualisations. Ce dont les équipes de données ont besoin, c'est de contexte : la capacité de retracer un problème de qualité des données à son impact commercial en moins de 60 secondes.
Vous pouvez voir ce schéma dans de nombreuses entreprises. Ils mettent en œuvre des outils de traçabilité avec grand enthousiasme. Les diagrammes apparaissent sur les téléviseurs des bureaux (cool), et l'équipe de gouvernance des données rédige de la documentation sur la documentation. Puis, six mois plus tard, un système en amont change un nom de colonne et le diagramme de traçabilité s'illumine comme un sapin de Noël tandis que l'impact commercial réel reste un mystère.
L'équipe finit par faire ce qu'elle aurait fait sans l'outil : parcourir Slack, vérifier avec les parties prenantes, retracer manuellement quels rapports comptent pour quelles décisions.
Le fossé du contexte commercial
Voici le problème fondamental : la traçabilité technique et la traçabilité commerciale sont des choses différentes, et la plupart des outils ne font que la première.
La traçabilité technique répond à : D'où viennent ces données et où vont-elles ?
La traçabilité commerciale répond à : Quelles décisions dépendent de ces données, et que se passe-t-il si elles sont erronées ?
Le fossé entre elles est là où se produisent les catastrophes de données. Un pipeline peut être correct à 100 % d'un point de vue technique : tous les travaux sont verts, tous les tests réussis : tout en produisant un résultat catastrophiquement erroné pour l'entreprise.
Disons que vous êtes une entreprise fintech, et que votre modèle d'approbation de prêt est techniquement parfait. La traçabilité montre des données propres de l'application à l'ingénierie des fonctionnalités jusqu'à l'évaluation du modèle. Ce que la traçabilité ne capture pas, c'est qu'un changement de schéma récent avait échangé deux champs aux noms similaires, "revenu_annuel" et "revenu_mensuel", d'une manière que les règles de validation du pipeline n'ont pas détectée.
Le modèle traite maintenant le revenu mensuel comme un revenu annuel. Les seuils d'approbation qui auraient dû exiger 60 000 $/an se déclenchent à 5 000 $/mois. Le diagramme de traçabilité montre des flèches vertes. Le résultat commercial est un mois de mauvais prêts qui prennent six mois à dénouer.
À quoi ressemble réellement une traçabilité utile
Les équipes qui réussissent bien la traçabilité ont une chose en commun : elles la traitent comme un exercice de cartographie commerciale, pas comme une tâche de documentation technique.
Vous devez adopter une approche différente : chaque data Asset dans votre entrepôt a trois étiquettes :
- Criticité : Est-ce utilisé pour des rapports réglementaires, des décisions opérationnelles ou uniquement des analyses ?
- Processus en aval : Quelles fonctions commerciales dépendent de cela ? (Pas quelles tables, mais quelles fonctions : facturation, décisions cliniques, conformité)
- Impact des erreurs : Que se passe-t-il si ces données sont erronées ? (Retard, perte financière, problème réglementaire, sécurité des patients)
L'outil de traçabilité résultant est techniquement simple : juste un suivi de dépendance de base. Mais combiné avec ces trois étiquettes, il vous dit exactement ce que vous devez savoir lorsque quelque chose se casse.
Lorsque votre table de traitement des réclamations a un problème de qualité des données, vous n'avez pas besoin de retracer à travers quinze tables en aval. Vous regardez les étiquettes, voyez "Criticité : Réglementaire, En aval : Dépôt mensuel CMS, Impact des erreurs : pénalité de 2 M$ si en retard," et savez immédiatement qu'il faut alerter le CFO et initier le processus de sauvegarde de dépôt manuel.
La réponse à l'incident entier prend quelques minutes. Pas besoin de navigation dans le diagramme.
Pourquoi nous construisons la mauvaise chose
Alors pourquoi les équipes continuent-elles d'acheter des outils de traçabilité axés sur la visualisation qui ne résolvent pas le vrai problème ?
En partie, c'est du théâtre d'approvisionnement. La personne qui achète l'outil n'est souvent pas celle qui débogue l'incident à 2 heures du matin. Ils achètent quelque chose qui semble complet pour l'audit de conformité ou la présentation au conseil d'administration. De beaux diagrammes cochent des cases. La cartographie du contexte commercial nécessite un travail organisationnel qui ne se photographie pas bien.
En partie, c'est la nature de la façon dont ces outils sont vendus. Les fournisseurs font des démonstrations avec des environnements de données synthétiques et propres où la traçabilité est évidente. Les environnements de données d'entreprise réels sont super désordonnés : des décennies de systèmes hérités, des transformations non documentées, des connaissances tribales qui n'ont jamais été écrites. La cartographie du contexte commercial nécessite de parler aux gens, pas seulement de scanner du code. Cela ne se met pas à l'échelle aussi proprement que la découverte technique automatisée.
Et en partie, c'est que la traçabilité technique est plus facile à construire. Vous pouvez scanner les journaux de requêtes, analyser le SQL, inspecter les DAGs. Le contexte commercial nécessite des entretiens, de la documentation, une maintenance continue à mesure que les processus changent. C'est un travail organisationnel déguisé en travail technique.
Comment réparer votre traçabilité
Si vous êtes déjà investi dans un outil de traçabilité (et la plupart des entreprises le sont à ce stade), vous n'avez pas besoin de le retirer. Vous devez y ajouter du contexte commercial.
Commencez par votre historique d'incidents. Regardez les cinq derniers incidents de qualité des données qui ont causé un impact commercial réel. Pour chacun, identifiez :
- Quelles données étaient erronées
- Quel processus commercial a été cassé
- Qui avait besoin de savoir
- Combien de temps il a fallu pour le comprendre
Maintenant, regardez votre outil de traçabilité. Aide-t-il avec l'une de ces questions ? Sinon, vous avez votre feuille de route d'amélioration.
Étiquetez manuellement les Assets critiques. Ne tentez pas de tout étiqueter. Commencez par vos 20 principaux data Assets par impact commercial. Pour chacun, documentez : quelles décisions il alimente, qui possède ces décisions, et que se passe-t-il si les données sont mauvaises.
Cela prend du temps : peut-être 30 minutes par Asset ; peut-être plus. Mais cela transforme votre traçabilité d'un joli diagramme en un outil opérationnel.
Construisez des alertes conscientes du contexte commercial. La plupart des alertes de qualité des données sont techniques. "Ce travail a échoué" ou "cette colonne a des valeurs nulles." Ajoutez des alertes conscientes du contexte commercial : "Le résumé quotidien des revenus a des valeurs suspectes, qui alimente le tableau de bord du PDG à 8 heures."
L'alerte devrait inclure non seulement ce qui est erroné, mais ce qui en dépend et qui doit être informé.
Pratiquez la réponse aux incidents. Faites un exercice de simulation. Simulez un problème de qualité des données dans un système critique en amont. Chronométrez combien de temps il faut pour répondre : quelles décisions commerciales sont affectées, qui doit être informé, et quelles sont les options d'atténuation.
Si cela prend plus de cinq minutes, votre traçabilité a besoin de plus de contexte commercial.
Le produit que j'aimerais qu'il existe
J'ai examiné certains des outils de traçabilité sur le marché. Ils sont tous des variations sur le même thème : scannez votre infrastructure, construisez un graphe, montrez-vous de jolies visualisations.
Ce que je veux est différent. Je veux un outil qui commence par les processus commerciaux et travaille à rebours. Cartographiez d'abord les décisions, puis remontez jusqu'aux données qui les alimentent. Lorsque quelque chose se casse, dites-moi quelles décisions sont à risque, pas seulement quelles tables sont affectées.
Mais vous n'avez pas besoin d'une nouvelle plateforme pour obtenir une meilleure traçabilité. Vous devez cesser de traiter la traçabilité comme un problème technique et commencer à la traiter comme un problème organisationnel. Le diagramme n'est pas le produit. Le contexte commercial l'est.
Le test pour votre outil de traçabilité
Voici un test simple. Choisissez un data Asset critique dans votre système : quelque chose qui serait douloureux s'il était erroné. Maintenant, répondez à ces questions sans regarder le code :
- Quelles décisions commerciales dépendent de ces données ?
- Qui prend ces décisions, et quand ?
- Quel est le coût de l'erreur ?
- Qui doit être informé s'il y a un problème de qualité ?
Si vous ne pouvez pas répondre à ces questions en 60 secondes, votre outil de traçabilité ne fait pas son travail : peu importe à quel point le diagramme est beau.
L'objectif n'est pas une observabilité parfaite. C'est un contexte utilisable. Et c'est plus difficile à construire, mais infiniment plus précieux.
Andrew Tan est un entrepreneur en série et fondateur de layline.io, construisant une infrastructure de traitement de données d'entreprise qui gère des charges de travail à la fois par lots et en temps réel à grande échelle.
