Un client signale qu’un prix est passé de 149 à 14,90 euros. Le vendeur affirme avoir envoyé 149, le PIM affiche 14,90, l’index 149 et le cache sert les deux selon la page. L’équipe ouvre le fichier SFTP, les logs d’import, une règle de conversion et trois bases. Deux heures plus tard, personne ne sait encore quelle transformation a déplacé la virgule.
Le problème ne vient pas seulement d’une mauvaise valeur. Le catalogue a perdu la chaîne qui relie source, mapping, règle, validation et destination. Sans lineage, une correction directe restaure l’écran mais laisse la cause active ; le prochain batch reproduit l’erreur et écrase la réparation opérateur.
Le vrai enjeu du data lineage catalogue d’une marketplace opérateur est de répondre rapidement à « d’où vient cette valeur, pourquoi a-t-elle gagné et où est-elle publiée ? ». Contre-intuitivement, tracer tous les appels ne suffit pas : la provenance doit suivre l’identité et le champ métier.
Vous allez comprendre comment modéliser identités, sources, imports, transformations, autorités, versions et destinations. Le dispositif relie chaque valeur à un run et une règle ; le back-office explique l’histoire, tandis que le monitoring mesure ruptures, sources orphelines et capacité de rollback jusqu’au rendu public.
Définir le lineage utile
Partir des questions opérationnelles
Qui a fourni le prix ? Quel mapping a produit l’attribut ? Quelle règle a traduit le titre ? Quel système sert encore l’ancienne version ? Chaque question définit les nœuds et preuves à conserver. Un graphe technique exhaustif sans lien vers l’offre n’aide pas le support.
Le contrat reçoit identité, champ, marché et instant ; il retourne valeur, source, transformations, décision, version et destinations. Les étapes possèdent owners. La réponse doit être disponible depuis le back-office en quelques secondes, sans accès direct à la production.
Choisir le bon grain
Produit, variante, offre, attribut, valeur localisée et média peuvent avoir des sources différentes. Le lineage suit le champ ou le fragment qui porte une décision. Tracer seulement le produit agrégé masque qu’un titre vient de l’opérateur et un prix du vendeur.
Le compromis oppose granularité et coût. Les champs critiques gardent un historique complet ; les contenus lourds peuvent citer le lot et l’empreinte. L’équipe commence par prix, stock, titre, catégorie et obligations, puis étend selon incidents et usages.
Stabiliser les identités
Séparer identifiants internes et externes
SKU vendeur, GTIN, identifiant PIM, clé ERP et URL ne sont pas interchangeables. Un registre les associe à l’identité marketplace avec période de validité et source. Les imports utilisent l’identifiant externe dans son namespace, jamais un libellé supposé unique.
Une fusion crée un événement avec anciennes et nouvelle identités. Les références historiques restent résolubles. Une scission conserve la relation et les commandes concernées. Le graphe de provenance ne perd pas son chemin lors d’une opération de déduplication.
Versionner les correspondances
Le mapping d’un code fournisseur vers une catégorie ou une valeur change dans le temps. Chaque correspondance possède version, auteur, confiance et date d’effet. Une correction ne réinterprète pas silencieusement les anciens lots sans migration décidée.
Par exemple, le code BLUE est mappé à bleu marine puis corrigé en bleu. Si la correction vise seulement les nouveaux imports, les valeurs existantes gardent leur version. Si une migration est décidée, elle produit un lot, une population, un diff et un rollback.
Qualifier les sources
Décrire producteur et responsabilité
Vendeur, fabricant, PIM, équipe éditoriale, moteur de prix ou conformité peuvent produire une valeur. La source contient type, système, entité, contact, SLA et champs autorisés. « API » n’est pas un owner ; elle transporte une donnée dont quelqu’un répond.
Les contrats précisent format, fréquence, fraîcheur et garantie. Un stock temps réel n’est pas traité comme un titre trimestriel. Le dashboard distingue source silencieuse, retard, rejet et contenu identique, afin de ne pas confondre absence de changement et panne.
Le registre reçoit en entrée le contrat signé, le namespace et les champs produits ; sa sortie expose owner, version, statut et consommateurs dépendants. L’instrumentation rapproche volumes reçus et cadence attendue. Le monitoring ouvre une alerte vers le runbook approprié lorsqu’une source dérive. Un changement incompatible reste en shadow et le rollback conserve la dernière version exploitable jusqu’à réconciliation.
Mesurer confiance et fraîcheur
Chaque valeur transporte instant source, instant reçu, validation et niveau de confiance. Une donnée ancienne peut rester correcte ; une donnée récente peut être suspecte. La policy combine âge, source et contrôle pour décider usage ou repli.
Si un prix vendeur n’a pas été rafraîchi depuis 24 heures alors que le SLA est quinze minutes, l’offre est revalidée ou limitée. Le lineage explique la décision et la dernière valeur sûre. Support ne promet pas que « la base est à jour » sans preuve.
Tracer les ingestions
Créer un identifiant de run
Fichier, webhook, API ou saisie manuelle reçoit un ingestion_run_id, une version de schéma, un producteur et une empreinte. Chaque enregistrement garde position ou identifiant source. Un même lot rejoué utilise une clé idempotente et ne crée pas deux histoires.
Le run possède début, fin, compteurs, rejets, checkpoint et code déployé. Les fichiers originaux suivent une rétention et un accès contrôlé. Une valeur peut toujours revenir au fragment d’entrée exact ou à sa preuve, sans conserver indéfiniment des données sensibles inutiles.
Conserver acceptations et rejets
Valide, corrigé, mis en quarantaine ou rejeté sont des verdicts structurés. Le motif cite champ, règle et version. Un rejet ne disparaît pas du lineage ; il explique pourquoi la source n’a pas atteint le catalogue et permet au vendeur de corriger.
Scénario : 10 000 lignes arrivent, 9 800 sont acceptées et 200 mises en quarantaine. Si le batch est rejoué après correction, seules les lignes concernées reprennent depuis le checkpoint. Les valeurs déjà publiées ne reçoivent ni nouvel événement ni nouvelle date artificielle.
Tracer les transformations
Nommer chaque règle matérielle
Normalisation d’unité, conversion de devise, concaténation de titre, classification et arrondi possèdent identifiant et version. Le résultat cite entrées et sortie. Une fonction anonyme dans un ETL ne suffit pas pour expliquer un prix ou reproduire un attribut.
Les transformations déterministes sont rejouables sur une fixture. Les enrichissements probabilistes conservent modèle, score, seuil et décision humaine. Un score ne devient pas automatiquement une catégorie ; le lineage garde proposition puis approbation.
Distinguer calcul et override
Une correction opérateur crée une couche avec motif, owner, portée et expiration. Elle ne remplace pas la valeur source ni la transformation. La résolution indique que l’override gagne et continue de signaler les changements amont qui pourraient le rendre obsolète.
Par exemple, l’opérateur corrige le titre après une erreur vendeur. Si le prochain import renvoie l’ancien texte, alors le système conserve l’override et ouvre un conflit. Il ne réintroduit pas l’erreur ni ne bloque silencieusement tous les futurs changements.
Résoudre l’autorité par champ
Définir la priorité des sources
Prix et stock viennent souvent de l’offre vendeur ; identité produit du fabricant ou de l’opérateur ; conformité d’une équipe autorisée. Une matrice indique sources admissibles, priorité et fallback par champ, marché et catégorie. Elle refuse deux autorités de même rang.
Le moteur reçoit candidats et contexte, puis retourne gagnant, raisons et version de policy. La décision est conservée avec la valeur publiée. Une source secondaire peut être plus récente sans gagner si elle n’est pas autorisée à modifier ce champ.
Traiter les conflits
Un conflit se produit lorsque deux sources légitimes divergent au-delà d’un seuil. La file affiche valeurs, preuves, impact et owner. L’opérateur peut choisir, demander une correction ou limiter la publication. La décision devient une règle ou une exception datée.
Si prix ERP et vendeur diffèrent de plus de 5 %, alors l’offre quitte la confirmation et rejoint la revue. La fiche peut rester visible sans engagement précis. Le retour exige source réconciliée, décision tracée et invalidation des destinations qui avaient servi l’écart.
Versionner règles et valeurs
Créer un snapshot publiable
Le snapshot contient identités, valeurs, sources, transformations, policy et instant. Il est immuable. Une nouvelle version référence la précédente et les changements. La page, l’index et l’API peuvent citer le même numéro sans relire des tables mouvantes.
Le diff distingue source modifiée, règle modifiée, override et recalcul sans changement. Cette information oriente la revue. Un changement de code qui réécrit 100 000 valeurs identiques ne doit pas créer une fausse actualité catalogue.
Reproduire un état historique
Une commande garde la version de prix, titre et obligations qu’elle a consommée. Le support peut reconstruire la fiche vue par le client. Les données actuelles restent disponibles séparément. Cette capacité réduit les litiges fondés sur des captures impossibles à vérifier.
Le recalcul historique s’exécute en simulation avec les anciennes versions de règles. S’il manque une dépendance, le système le déclare. Il ne fabrique pas une réponse depuis le présent. Les règles et artefacts nécessaires suivent une rétention proportionnée au risque.
Suivre jusqu’à la publication
Créer un manifeste de destinations
Catalogue, index, cache, flux publicitaire, partenaire et rendu web reçoivent snapshot et version. Le manifeste liste destinations attendues et leur accusé. Un événement envoyé n’est pas une publication réussie tant que la surface critique ne sert pas la valeur.
Les consommateurs enregistrent version active et résultat. Une destination en retard rejoint une file. Le statut global reste partiel. L’opérateur voit que la base contient 149 euros mais que l’index sert 14,90, sans lancer une enquête externe.
Invalider et vérifier le rendu
Les clés de cache et documents indexés citent l’identité et la version. Une invalidation cible les dépendances connues. Des sondes échantillonnent le rendu public et comparent au manifeste. La couverture est pondérée par trafic et criticité.
Par exemple, si 99 % des offres utilisent le bon prix mais que dix best-sellers restent anciens, alors la publication est en échec. Le run invalide les clés et mesure les sessions exposées. Le retour au vert attend deux sondes cohérentes.
Répondre aux incidents
Identifier la population exposée
Depuis une règle, une source ou un run, le graphe retourne valeurs et destinations affectées. L’équipe sait quelles offres, pages et commandes ont consommé la version fautive. L’impact combine trafic, chiffre et période, pas seulement un nombre de lignes.
L’entrée d’incident est la valeur constatée ; la sortie attendue est une population, une cause et une action. Le runbook attribue catalogue, plateforme, vendeur et support. Cette traçabilité évite de purger tout le site lorsqu’un seul mapping est fautif.
Corriger sans perdre la cause
Le rollback peut réactiver snapshot précédent, retirer une destination ou poser un override temporaire. Il ne supprime pas le run fautif. Une correction durable modifie source, mapping ou règle, puis republie un nouveau snapshot avec lien vers l’incident.
Scénario : une conversion divise 2 400 prix par dix. Si la valeur exposée dépasse 50 000 euros, alors le checkout est limité et les commandes rejoignent une revue. Le rollback restaure la version saine ; la réconciliation traite chaque commande avant clôture.
Rendre la provenance exploitable
Afficher une chronologie de champ
Le back-office montre valeur actuelle, source gagnante, dernières versions et conflits. Un clic ouvre le run, l’entrée, les règles et destinations. Les codes techniques sont traduits en motifs actionnables. Les accès sensibles restent masqués par rôle.
Support peut copier une référence de lineage dans le ticket. Le seller manager voit quelle donnée corriger et pourquoi sa source a perdu. L’administrateur autorisé peut simuler une nouvelle valeur, mais l’interface n’écrit pas directement dans la projection.
Prévisualiser une modification
Avant de changer mapping ou priorité, l’opérateur demande la population et le diff prévus. La simulation indique valeurs, destinations, risque et durée. Au-delà d’un seuil, la double approbation et le canary deviennent obligatoires. La commande porte idempotence et rollback.
Si une règle touche plus de 10 000 offres ou un champ financier, alors la publication commence à 1 %. Le dashboard compare erreurs et divergence. Une extension automatique n’a lieu que si les sondes et la réconciliation restent vertes.
Gouverner qualité et couverture
Mesurer la couverture utile
La couverture indique part des champs critiques dont source, transformation, décision et destination sont connues. Elle est pondérée par offres actives et trafic. Compter les tables documentées ne prouve pas que le prix public possède un chemin complet.
Les SLI suivent temps de réponse, lineage cassé, sources sans owner, destinations en retard et valeurs non reproductibles. Chaque seuil déclenche une action. Une dette ancienne sur un champ critique bloque les nouveaux pipelines qui augmenteraient l’exposition.
Gouverner schémas et owners
Le catalogue de données référence producteurs, consumers, policies et runbooks. Un changement de schéma notifie les propriétaires en aval et passe un test de compatibilité. Les champs abandonnés possèdent date de retrait et migration.
Une revue mensuelle examine incidents, overrides et chemins jamais utilisés. Les transformations sans owner sont retirées ou attribuées. Trois corrections manuelles similaires deviennent une évolution de source ou de règle, pas une nouvelle procédure support.
Adapter la méthode et éviter les erreurs
Pour qui le data lineage catalogue convient
Il devient indispensable avec plusieurs vendeurs, imports, règles et canaux. Une petite plateforme peut commencer par identifiant, source, run et version pour prix et stock. Elle n’a pas besoin d’un graphe sophistiqué pour rendre les premières valeurs explicables.
Catalogue porte les identités ; vendeurs les sources ; plateforme les runs ; métier les règles ; support l’enquête ; sécurité les accès ; opérations la publication. Chaque nœud critique possède un owner et une rétention avant mise en service.
Erreurs fréquentes dans le data lineage
Tracer seulement les tables, perdre les identifiants aux transformations, écraser les sources, ignorer les overrides et s’arrêter avant le rendu sont les erreurs majeures. Elles produisent un beau diagramme incapable d’expliquer une valeur vue par un client.
Une autre erreur consiste à tout tracer avec la même profondeur. Le coût explose et le signal disparaît. La priorité va aux champs qui déterminent prix, disponibilité, droit, promesse et décision support ; les autres s’étendent selon incidents mesurés.
Plan d’action pour installer le data lineage
Semaines 1 à 4 : identités et runs
La première semaine choisit prix, stock, titre, catégorie et conformité sur deux flux. L’équipe reconstitue vingt incidents et liste les preuves manquantes. La deuxième fixe identités, sources, owners et grain de champ. Chaque producteur reçoit namespace et contrat.
Les semaines trois et quatre instrumentent ingestion_run_id, checkpoints, décisions et versions de transformations. Le back-office ouvre la chronologie de champ. Les tests couvrent doublon, rejet partiel, mapping changé, override et fusion d’identité.
Semaines 5 à 8 : destinations et run
La cinquième semaine crée snapshots et manifestes pour catalogue, index et cache. La sixième ajoute recherche d’impact et rollback. L’instrumentation suit couverture, lineage cassé, retard et population sans owner.
Les semaines sept et huit migrent un flux en canary puis provoquent prix erroné, source périmée et destination résistante. Le go exige valeur reproductible, population retrouvée sous cinq minutes et réconciliation du rendu public.
Le dossier final conserve modèle, dictionnaire, policies, dashboards, seuils de couverture et runbooks. Tout nouveau pipeline déclare identités, sources, transformations, consumers et destinations ; toute règle sensible fournit simulation, preuve de réconciliation et rollback. Les corrections directes de projection sont interdites, même pendant une urgence, car elles couperaient précisément la chaîne nécessaire à l’enquête.
- À faire d’abord : tracer cinq champs critiques depuis leur source au rendu.
- À tester ensuite : mapping modifié, import rejoué, override et cache résistant.
- À différer : les champs sans décision opérationnelle associée.
- À refuser : toute correction qui masque le run ou la transformation responsable.
Ressources complémentaires pour l’opérateur
Structurer catalogue et enquête
Le catalogue PIM marketplace pose les identités, attributs et sources.
Les écrans du back-office opérateur rendent chronologies et incidents exploitables.
Borner les premiers flux
Le MVP marketplace avant ouverture aide à limiter les sources critiques.
La méthode pour ouvrir une première catégorie éprouve le lineage sur un catalogue réel.
Conclusion : expliquer chaque valeur
Un lineage utile relie une valeur métier à son identité, sa source, ses transformations et ses destinations réellement actives.
Versions, décisions et overrides rendent l’histoire reproductible sans empêcher les corrections opérateur.
La recherche d’impact et le rollback transforment un incident catalogue en population et en reprise mesurables.
Pour construire cette traçabilité, Dawap peut vous accompagner dans votre marketplace opérateur.
