Data lineage : mesurer l’impact d’un changement de colonne

Une équipe remplace le statut paid par settled dans sa table de commandes. Les colonnes sont les mêmes, les montants aussi. Pourtant, le rapport du chiffre d’affaires payé ne renvoie plus de montant. Sa requête filtre encore sur l’ancienne valeur.

Dans cet exemple fictif, la colonne status n’apparaît pas dans le résultat affiché. Elle décide néanmoins quelles commandes entrent dans le calcul. C’est précisément le type de dépendance à rechercher avant une modification.

Le data lineage, ou lignage des données, décrit les relations entre sources, transformations et usages. Pour une analyse d’impact, on part de l’élément modifié et on suit ses consommateurs en aval. Le résultat attendu est une liste de vérifications et de responsables, accompagnée des zones encore inconnues.

Ce guide propose une méthode pour une équipe data qui prépare un changement de colonne, de règle ou de vocabulaire. Les références ont été vérifiées le 25 octobre 2026. L’exercice est local et synthétique ; aucun catalogue ni environnement BI réel n’a été testé.

Télécharger l’atelier data lineage : graphe explicite, quatre commandes fictives, matrice d’impact et quatorze contrôles exécutables avec Python, sans service cloud.

Trois niveaux de dépendance à distinguer

Au niveau table, le graphe indique qu’un modèle de ventes lit une table de commandes. Cela aide à trouver les traitements concernés, mais ne suffit pas à expliquer l’effet d’une modification d’un champ particulier.

Au niveau colonne, on cherche comment une valeur est construite ou influencée. Un montant peut être copié, converti, additionné, ou retenu seulement lorsque d’autres colonnes respectent un critère. Une jointure peut changer les lignes disponibles et leur nombre.

Au niveau usage, on relie ces sorties aux rapports, extractions et décisions. Le chemin technique peut s’arrêter à une table alors qu’un fichier de clôture, une présentation commerciale ou une application continue à la lire.

Dans la spécification OpenLineage, les relations DIRECT décrivent une dérivation de valeur ; INDIRECT peut notamment représenter un filtre ou une jointure. Cette distinction est documentée dans la facette de lignage de colonnes. Elle indique ce que le format sait exprimer. La couverture effectivement collectée dépend encore de l’intégration utilisée.

La question à poser devant un graphe est donc précise : représente-t-il uniquement les colonnes sélectionnées, les influences sur les lignes, ou aussi les consommateurs BI ?

Ce que vos outils permettent réellement de conclure

Un graphe existant constitue un bon point de départ. Il faut ensuite vérifier son périmètre, son actualité et les droits avec lesquels il a été consulté.

Dans dbt Catalog, la section « Caveats in Catalog » documente une limite importante : les dépendances de colonnes reflètent les usages dans les SELECT, pas ceux des jointures et filtres. La page signale aussi des limites de parsing et de références codées en dur. Elle distingue ce fonctionnement de celui du développement local avec dbt v2. Il serait donc inexact d’étendre cette restriction à tous les modes dbt. Catalog nécessite une offre Enterprise ou Enterprise+ ; le mode local décrit ses propres prérequis. Documentation dbt.

Les exposures dbt permettent de décrire un usage aval, avec des dépendances, un propriétaire et éventuellement une URL. C’est utile pour rattacher un tableau de bord au projet. Une déclaration manuelle reste toutefois aussi complète que l’inventaire qui l’a alimentée. Déclarer une exposure.

Dans Power BI, l’analyse d’impact d’un modèle sémantique recense des rapports et dashboards potentiellement touchés. Microsoft distingue cet impact potentiel d’une panne effective. La consultation exige des droits d’écriture sur le modèle ; les éléments auxquels vous n’avez pas accès peuvent apparaître sous « Limited access ». Ce résultat sert à orienter l’investigation. Il ne démontre pas qu’une mesure précise changera de valeur. Analyse d’impact Power BI.

Ces possibilités se complètent. Un catalogue réduit le travail de recherche, une lecture ciblée du SQL explique les mécanismes, et la recette métier établit si le résultat reste acceptable. L’atelier ci-dessous utilise uniquement la bibliothèque standard Python : il n’exige aucun abonnement à ces produits.

Trois changements, trois contrôles différents

Un montant passe des euros aux centimes

Le nom de la colonne peut rester identique. Si le rapport additionne directement les nouvelles valeurs, son résultat change d’un facteur cent. Cherchez les calculs, mesures, exports et conversions qui lisent ce montant.

Dans ce cas fictif, le contrôle porte sur l’unité attendue à chaque étape. Une comparaison du nombre de lignes ne révèle rien. Vérifiez quelques commandes connues, puis les agrégats par période et segment. Conservez la définition de référence hors du code que vous venez de modifier.

Un statut change sans modification de schéma

C’est le scénario de l’atelier. Le champ de statut influence la sélection des commandes, puis le chiffre d’affaires affiché. Un outil limité aux dérivations directes de valeurs peut laisser ce chemin hors de son graphe.

Le contrôle consiste à rejouer le filtre sur un lot dont les commandes payées sont connues. Une requête qui termine sans erreur n’atteste pas que son résultat répond encore à la même question métier. Une valeur absente ne doit pas être remplacée automatiquement par zéro pour faire passer la recette.

Une clé de jointure ou une segmentation évolue

Une table clients peut modifier la correspondance entre identifiant et segment. Le total des ventes reste parfois identique, mais les montants se déplacent entre catégories. Une jointure devenue multiple peut également dupliquer les ventes.

Vérifiez les clés sans correspondance, les multiplicités et les répartitions attendues. Notre guide sur le schéma en étoile et les doubles comptes détaille cette seconde famille de contrôles. Le lignage aide à choisir où regarder ; le test doit porter sur la règle réellement modifiée.

Construire une matrice d’impact exploitable

Commencez par une modification précise. « Refaire la table commandes » est trop large. « Remplacer les valeurs paid par settled à partir de telle livraison » permet de rechercher des consommateurs et de définir un résultat attendu.

Identifiez la colonne avec son environnement, sa plateforme, sa base, son schéma et sa table. Deux objets portant le même nom en test et en production ne sont pas interchangeables. Fixez aussi la version du code et la date de collecte des métadonnées.

Puis rassemblez les liens du catalogue, le SQL compilé, les connexions BI et les usages déclarés par les équipes. Pour chaque relation importante, gardez une preuve consultable : extrait de requête, configuration de connexion ou déclaration du propriétaire. Une flèche sans provenance est difficile à contester ou à corriger.

La matrice minimale peut prendre cette forme :

Consommateur fictif	Dépendance recherchée	Vérification avant décision
Rapport Finance	Filtre sur le statut puis somme des montants	Retrouver les commandes payées de référence
Rapport Opérations	Somme de toutes les commandes	Confirmer l’absence de filtre caché
Excel de clôture	Connexion et formules encore inconnues	Identifier le propriétaire et ouvrir le fichier

Ajoutez le responsable, la date de collecte, l’état de la recette et le lien vers la preuve. Si un consommateur n’a aucun chemin dans le graphe disponible, marquez-le « inconnu dans ce périmètre ». Pour conclure qu’il n’est pas concerné, il faut une vérification supplémentaire de son usage réel.

La fraîcheur attendue dépend du processus. Pour un modèle modifié chaque jour, un graphe collecté avant la dernière livraison peut être insuffisant. Pour un export mensuel, l’absence de consultation récente ne prouve pas son abandon. Le guide de retrait d’un rapport BI propose une méthode pour examiner ces usages intermittents.

Atelier : montrer le filtre que le graphe direct manque

1. Télécharger et exécuter le kit

Décompressez atelier-lineage.zip, ouvrez un terminal dans le dossier extrait, puis lancez :

python3 atelier.py

Prérequis : Python 3.10 ou plus récent avec le module SQLite standard. Le script ne contacte aucun service. La petite base de données reste en mémoire. Il écrit matrice-impact.csv et resultats.json dans le dossier de l’atelier.

Le fichier graphe.json est déclaré à la main. Il n’est ni un export de votre catalogue ni un événement conforme au schéma OpenLineage. Il contient seulement les relations nécessaires à la démonstration. Les connexions BI représentées sont fictives.

2. Suivre le chemin du statut vers le rapport

Le graphe fourni exprime ce chemin :

orders.status
  -> eligible.amount_cents   [influence du filtre]
  -> daily.revenue_cents     [agrégation]
  -> bi.finance.ca           [lecture du rapport]

Le programme parcourt les descendants d’une colonne. Il garde un chemin témoin par objet et évite de tourner en boucle lorsqu’un cycle apparaît. Il ne cherche pas à extraire des dépendances depuis du SQL arbitraire.

Un contrôle refait le parcours en ignorant les relations indirectes. Dans ce mode, le rapport Finance disparaît des descendants du statut. Ce résultat illustre la limite d’un graphe qui ne représenterait que les valeurs directement transmises.

3. Observer un calcul valide devenu incorrect

Le jeu fictif contient quatre commandes : 100 euros payés, 40 annulés, 50 remboursés et 30 en attente. Les montants sont stockés en centimes. La requête simplifiée est :

SELECT SUM(amount_cents)
FROM orders
WHERE status = 'paid';

Avant le changement, elle renvoie 10 000 centimes. Le script remplace ensuite paid par settled, sans changer les colonnes ni les montants. L’ancienne requête s’exécute toujours, mais ne trouve plus de ligne à additionner : SQLite renvoie NULL, enregistré comme null dans le JSON.

En utilisant le nouveau statut, la somme retrouve 10 000 centimes. La somme brute des quatre commandes reste de 22 000 centimes pendant toute l’expérience. Ce total stable ne prouve donc pas que le rapport filtré fonctionne.

Ces nombres sont ceux du jeu pédagogique. Ils ne constituent ni une mesure de performance ni un résultat obtenu sur un système client.

4. Examiner les résultats et leurs limites

L’exécution vérifiée passe 14 contrôles. Ils couvrent notamment la propagation jusqu’au rapport, le cas sans lien indirect, une colonne inconnue, un cycle artificiel et la comparaison avant/après du filtre.

La matrice conserve l’Excel de clôture en couverture inconnue. Le rapport Opérations n’a pas de chemin depuis le statut dans ce graphe, mais reste à examiner avant une décision réelle. Aucun des contrôles ne certifie que l’inventaire de votre entreprise est complet.

Si une assertion échoue, le script termine avec une erreur. Lisez son nom avant de modifier la référence attendue. Pour nettoyer l’exercice, supprimez le dossier extrait ; aucune base persistante n’a été créée.

Passer de l’exercice au premier pilote réel

Choisissez une colonne associée à un changement déjà prévu et un petit ensemble de consommateurs dont les propriétaires sont identifiés. Constituez d’abord une référence manuelle, puis comparez-la au graphe produit par vos outils.

Mesurez séparément les dépendances confirmées retrouvées, celles qui manquent, les liens proposés mais non confirmés, et les consommateurs encore inconnus. Le taux de couverture éventuel doit annoncer son dénominateur : les usages vérifiés du pilote. Il ne mesure pas automatiquement toute l’entreprise.

Testez une modification de valeur, un filtre et une jointure dans un environnement isolé. Vérifiez les résultats avec les propriétaires, puis actualisez les métadonnées après la livraison. L’effort à chiffrer comprend les connecteurs, les droits, la normalisation des identifiants, l’entretien des déclarations et le temps de recette.

Pour la mise en service, préparez aussi le retour à l’ancienne version et les lecteurs à remettre à jour. La méthode de migration progressive des pipelines complète cette étape.

Vous pouvez commencer avec un inventaire limité et des preuves manuelles si les changements sont rares et les usages bien connus. Quand les transformations et consommateurs se multiplient, automatiser la collecte devient plus utile. Dans les deux cas, le livrable qui aide à décider reste le même : les impacts à tester, les personnes responsables et les inconnues à lever avant de modifier les données.