Data Lineage — Lignée des données

Définition complète

Le data lineage — ou lignée des données en français — est la représentation documentée du chemin que parcourent les données depuis leurs sources opérationnelles jusqu'à leurs consommateurs finaux : tables de rapports, dashboards, API analytiques, exports. Il capture les dépendances entre objets de données (tables, vues, colonnes, métriques) et les transformations qui les relient, formant un graphe orienté acyclique (DAG) qui peut être parcouru dans les deux sens.

La lignée en amont (upstream lineage) répond à la question : d'où viennent les données de cet objet ? Elle permet de remonter jusqu'aux sources opérationnelles pour comprendre l'origine d'un chiffre ou diagnostiquer une anomalie. La lignée en aval (downstream lineage) répond à la question inverse : qu'est-ce qui dépend de cet objet ? Elle est indispensable avant toute modification d'un modèle ou d'une source pour anticiper les impacts sur les rapports et les métriques en production.

Il existe quatre niveaux de granularité du lineage, du plus grossier au plus précis : le lineage au niveau système (quel système source alimente quel système cible), le lineage au niveau table ou dataset (quelle table alimente quelle table), le lineage au niveau colonne (quelle colonne source devient quelle colonne cible après transformation), et le lineage au niveau métrique (quelles colonnes et transformations produisent quelle métrique business). La majorité des organisations commence au niveau table et progresse vers le niveau colonne au fur et à mesure que la maturité analytique croît.

Comment mettre en place le data lineage

La meilleure approche est de générer le lineage automatiquement à partir du code, plutôt que de le documenter manuellement. La documentation manuelle du lineage échoue invariablement à l'échelle : elle est coûteuse à maintenir, rapidement obsolète après les premiers changements de pipeline, et personne ne met à jour les diagrammes Confluence quand la priorité est de livrer la prochaine feature analytique.

Pour la grande majorité des équipes data de 3 à 15 personnes, la combinaison dbt natif + Datafold couvre l'essentiel des cas d'usage à un coût raisonnable. Les solutions enterprise (Alation, Collibra) sont justifiées pour des organisations avec 50+ personnes dans la data et des exigences de gouvernance réglementaire strictes.

Exemple concret

Prenons une scale-up française de 85 personnes avec une équipe data de 4 ingénieurs. Leur stack : Postgres (production), Fivetran (ingestion), Snowflake (warehouse), dbt (transformation), Tableau (dashboards). Sans lineage documenté, quand le directeur financier signale que le chiffre de « revenus récurrents annualisés » dans le rapport du lundi est différent de celui présenté en comité de direction le vendredi, l'équipe data passe en moyenne 3 heures à remonter manuellement les dépendances pour identifier l'origine de l'écart.

Après activation du lineage dbt natif et intégration de Datafold dans leur workflow GitHub, la même investigation prend 12 minutes. Le lineage au niveau colonne révèle immédiatement que la colonne arr_calculated dans le modèle fct_subscriptions dépend de deux colonnes sources — subscriptions.mrr et subscriptions.billing_cycle — dont la colonne billing_cycle a été renommée en cycle_type lors d'un déploiement applicatif du jeudi soir sans mise à jour coordonnée du modèle dbt. La valeur nulle résultante dans 340 lignes a silencieusement produit un ARR sous-estimé de 127 000 €.

L'analyse d'impact en aval révèle que 7 modèles dbt et 12 dashboards Tableau dépendent de ce modèle — information qui aurait pris une heure de travail à reconstituer sans lineage. La correction est déployée en 20 minutes, et l'équipe met en place une alerte dbt qui vérifie désormais que arr_calculated est non nul pour plus de 95 % des lignes à chaque exécution du pipeline.

Analyse approfondie

Le data lineage est fondamentalement un actif de confiance organisationnelle. Dans les organisations sans lineage, les décideurs — COO, CFO, VP Sales — finissent par cesser de faire confiance aux chiffres analytiques après quelques incidents où des discordances sont apparues sans explication satisfaisante. Cette défiance est économiquement coûteuse : elle conduit à des vérifications manuelles en tableur, des réunions de validation chronophages, et in fine à des décisions basées sur l'intuition plutôt que sur des données fiables. Le lineage résout ce problème structurellement en rendant chaque chiffre explicable et vérifiable.

La relation entre lineage et gouvernance des données est directe et pratique. Le RGPD exige que vous puissiez localiser et supprimer les données personnelles d'un individu sur demande (droit à l'oubli). Sans lineage, cette opération nécessite une investigation manuelle dans chaque système et modèle analytique — une procédure qui peut prendre plusieurs jours et introduit des risques d'omission. Avec un lineage au niveau colonne documentant quels modèles analytiques contiennent des colonnes PII (email, nom, identifiant client), vous pouvez générer la liste exhaustive des objets à mettre à jour en quelques minutes. Ce cas d'usage seul justifie l'investissement dans le lineage pour toute organisation traitant des données personnelles de résidents européens.

Le lineage cross-système est le niveau le plus opérationnellement utile, et le plus difficile à atteindre. Il s'agit de tracer le chemin d'une donnée depuis son origine transactionnelle (une ligne insérée dans la table orders de votre Postgres de production) jusqu'à sa représentation finale dans un dashboard consommé par un directeur commercial (la courbe de revenus dans Tableau). Ce chemin traverse typiquement 4 à 8 systèmes différents — base de production, outil d'ingestion, data warehouse, outil de transformation, couche sémantique, outil de visualisation. Chacun de ces systèmes utilise ses propres conventions de nommage et ses propres API de lineage. OpenLineage est la tentative de standardisation la plus prometteuse pour assembler un lineage cross-système cohérent à partir de ces sources hétérogènes.

Le lineage est également le fondement des initiatives d'AI Analytics qui se multiplient depuis 2024. Les agents IA capables de répondre à des questions sur les données d'une organisation — « Quel est notre taux de rétention sur le segment PME ce trimestre ? » — doivent être capables de naviguer le graphe de lineage pour identifier quels modèles et quelles métriques contiennent la réponse, d'évaluer la fraîcheur et la qualité des données concernées, et de citer leurs sources. Sans lineage structuré et lisible par machine, l'AI Analytics se réduit à de la retrieval augmentée sur des métadonnées textuelles — utile, mais nettement moins fiable qu'une navigation dans un graphe de dépendances formellement défini.

La maturité du lineage dans une organisation suit généralement une progression prévisible. Le niveau 1 est l'absence de lineage : chaque ingénieur data connaît dans sa tête les dépendances qu'il a créées, mais cette connaissance n'est pas documentée et disparaît avec chaque rotation d'équipe. Le niveau 2 est le lineage au niveau table généré par dbt : documenté, versionné, consultable via l'interface dbt docs. Le niveau 3 ajoute le lineage au niveau colonne via des outils spécialisés. Le niveau 4 est le lineage cross-système couvrant l'ensemble du chemin de la donnée, intégré dans le processus de review des changements de pipeline. La plupart des équipes data en 2025 se situent entre les niveaux 1 et 2 — et le passage au niveau 2 représente le meilleur retour sur investissement en termes d'heures d'investigation économisées.

Erreurs fréquentes dans la gestion du data lineage

• ✗

  Tenter de maintenir le lineage manuellement : les diagrammes Lucidchart, les pages Confluence et les fichiers Excel de dépendances sont obsolètes dès le premier changement de pipeline non répercuté. À l'échelle, la maintenance manuelle du lineage coûte plus cher que son bénéfice et crée un faux sentiment de sécurité — les équipes qui s'appuient sur une documentation manuelle font des analyses d'impact basées sur des informations périmées. La seule approche viable à l'échelle est de générer le lineage automatiquement à partir du code.

• ✗

  Confondre lineage et catalogage des données : le lineage documente les dépendances entre objets de données ; le data catalog documente les objets eux-mêmes (schéma, propriétaire, description, classification). Les deux sont complémentaires et souvent fournis par les mêmes outils (Atlan, Castor), mais répondent à des questions différentes. La question « d'où vient cette table ? » est une question de lineage. La question « à quoi sert cette table et qui en est responsable ? » est une question de catalogue. Négliger l'un au profit de l'autre laisse des angles morts importants dans la gouvernance analytique.

• ✗

  Ne pas intégrer le lineage dans le processus de review des changements : le lineage n'a de valeur opérationnelle que s'il est consulté avant de modifier un modèle ou une source, pas uniquement après un incident. La bonne pratique est d'intégrer l'analyse d'impact downstream dans le processus de pull request dbt — Datafold le fait automatiquement en affichant les modèles impactés directement dans la review GitHub. Sans cette intégration, le lineage reste un outil de post-mortem plutôt qu'un outil de prévention.

Comment Fairview utilise le data lineage

Fairview maintient un graphe de lineage interne couvrant l'ensemble du chemin de vos données depuis les sources connectées (Stripe, Salesforce, bases opérationnelles) jusqu'aux métriques présentées dans les dashboards opérationnels. Ce lineage est utilisé pour trois finalités concrètes : générer des explications automatiques quand une métrique change de façon inattendue (« le MRR de ce segment a diminué de 8 % car 3 abonnements ont été annulés dans Stripe hier soir »), calculer l'impact d'une modification de source avant qu'elle soit appliquée, et maintenir une cartographie des colonnes contenant des données personnelles pour faciliter les demandes de suppression RGPD. Vous bénéficiez de cette infrastructure de lineage sans avoir à la construire ou à la maintenir vous-même.

Questions fréquentes