Masterclass sur la traçabilité des données : guides pratiques, évaluation de la couverture et retour sur investissement

Ce guide s'adresse aux ingénieurs de données, gouvernance et les CDO qui ont dépassé le stade du « nous devrions mettre en place la traçabilité des données » et qui ont besoin de savoir comment s'y prendre concrètement au sein d'une pile technologique moderne, comment évaluer si cela fonctionne et comment démontrer sa valeur à l'entreprise.

Ce guide aborde les thèmes suivants : comment évaluer votre couverture actuelle en matière de traçabilité et identifier les lacunes, les guides de mise en œuvre spécifiques à chaque pile technologique, comment calculer le retour sur investissement, les erreurs courantes en matière de traçabilité et comment les éviter, ainsi que la manière d'étendre la traçabilité aux systèmes d'IA.

Types de traçabilité des données : une comparaison

Avant de mettre en œuvre la traçabilité, définissez les types dont votre organisation a besoin. Chaque type répond à des objectifs différents et nécessite des approches techniques distinctes.

Quels types privilégier :

Commencez par établir la traçabilité technique et la traçabilité jeu de données pour tous les pipelines : cela permet de définir le graphe de dépendances qui rend possible l’analyse d’impact. Ajoutez la traçabilité au niveau des colonnes pour chaque pipeline traitant des données réglementées, des informations à caractère personnel (PII) ou des indicateurs stratégiques pour l’entreprise. Ajoutez la traçabilité métier afin de rendre le graphe technique interprétable par les analystes et les responsables de données. Ajoutez la traçabilité temporelle et la traçabilité IA/ML à mesure que le programme évolue ou lorsque des exigences réglementaires spécifiques l’imposent.

Évaluation de votre couverture généalogique actuelle

Avant d'investir dans l'amélioration de votre lignée, établissez un état des lieux objectif de votre situation actuelle. Le cadre d'évaluation des écarts présenté ci-dessous génère un chiffre unique (de 0 à 100) qui reflète le niveau de maturité actuel de votre lignée et identifie les améliorations les plus efficaces.

Les quatre dimensions

Couverture (pondération de 40 %) : Pourcentage de tables et de colonnes de votre parc de données bénéficiant d'une documentation automatisée de la traçabilité. Il s'agit de la dimension la plus importante, car un programme de traçabilité ne couvrant que 30 % des actifs laisse 70 % du parc sans gouvernance.

Mesure : compter le nombre de tables avec l'historique / le nombre total de tables dans le catalogue. Répéter l'opération pour les colonnes si une couverture au niveau des colonnes est requise.

Actualité (20 % du poids) : Pourcentage des enregistrements de lignée mis à jour au cours des 90 derniers jours. Une lignée qui était exacte il y a six mois peut ne plus refléter les configurations actuelles du pipeline. Une lignée obsolète est, à certains égards, pire que l'absence totale de lignée : elle engendre une fausse confiance.

Mesure : nombre d'enregistrements de lignée dont la date « last_updated » remonte à moins de 90 jours / nombre total d'enregistrements de lignée.

Profondeur (pondération de 20 %) : Pourcentage d'enregistrements de traçabilité qui assurent un suivi au niveau des colonnes plutôt qu'jeu de données seul jeu de données du jeu de données . La traçabilité au niveau des colonnes est nettement plus coûteuse à mettre en œuvre, mais présente une valeur ajoutée considérablement plus importante pour l'analyse d'impact et la conformité.

Mesure : nombre d'actifs disposant d'une traçabilité au niveau des colonnes / nombre total d'actifs disposant d'une traçabilité, quelle qu'elle soit.

Validation (pondération de 20 %) : Pourcentage d'entrées de traçabilité pour lesquelles des tests de réconciliation automatisés ont confirmé l'exactitude de la traçabilité. Une traçabilité sans tests correspond à une simple documentation. Une traçabilité accompagnée de tests correspond à une documentation vérifiée.

Mesure : nombre d'entrées de traçabilité ayant réussi les tests automatisés / nombre total d'entrées de traçabilité.

Formule du « gap-score »

Score = (% de couverture × 0,40) + (% de nouveauté × 0,20) + (% de profondeur × 0,20) + (% de validation × 0,20)

Exemple de calcul :

• Couverture : 60 % → 60 × 0,40 = 24
• Fraîcheur : 80 % → 80 × 0,20 = 16
• Profondeur : 30 % → 30 × 0,20 = 6
• Validation : 50 % → 50 × 0,20 = 10
• Score Gap : 24 + 16 + 6 + 10 = 56

Niveaux de maturité

Ce que révèle ce score

Un score inférieur à 45 signifie que la priorité doit être donnée à l'infrastructure de base du réseau de distribution : c'est en améliorant la couverture et la fraîcheur des produits que l'on obtiendra le meilleur retour sur investissement.

Un score compris entre 45 et 65 indique que la profondeur au niveau des colonnes est la priorité : le graphe jeu de données existe déjà, et l'ajout d'une couverture au niveau des colonnes pour les actifs à forte valeur ajoutée constitue la prochaine amélioration offrant le meilleur rapport coût-efficacité.

Un score supérieur à 65 signifie que la validation et la lignée temporelle sont prioritaires : le programme de lignée de base fonctionne, et les prochaines améliorations porteront sur la vérification de sa précision et son extension afin de couvrir les cas limites et les systèmes d'IA.

Guides de mise en œuvre par pile

Guide pratique n° 1 : Snowflake et dbt

Architecture : Les données sont importées dans la couche brute de Snowflake. dbt transforme les données brutes, via des modèles de transit et intermédiaires, en tables MART utilisées par outils bi.

Approche de capture de la lignée : dbt génère, lors de la compilation, un fichier manifest.json contenant le graphe complet des dépendances pour chaque modèle : quels modèles dépendent de quels autres modèles, et quelles colonnes de chaque modèle proviennent de quelles colonnes des modèles en amont. Associé à requête de Snowflake, cela permet d’obtenir une traçabilité au niveau des colonnes sur l’ensemble de la chaîne de transformation.

Étapes de mise en œuvre :

1. Analyser le fichier manifest.json après chaque exécution de dbt afin d'extraire les dépendances des modèles et la traçabilité au niveau des colonnes.
2. À associer à requête Snowflake pour suivre la traçabilité des requêtes exécutées en dehors de dbt.
3. Mettez en correspondance les noms des modèles dbt avec ceux des tables Snowflake en utilisant le schéma cible et la configuration de la base de données.
4. Enregistrez le graphe de lignée obtenu dans votre métadonnées , en utilisant comme clés les noms complets des tables et des colonnes Snowflake.
5. Configurez le catalogue pour qu'il réimporte le fichier manifest.json à chaque exécution de dbt, afin que la traçabilité reste à jour.

Approche de test : Rédiger des tests de réconciliation qui vérifient que le nombre de lignes et la répartition des champs clés correspondent entre les tables source et cible pour chaque modèle dbt. Les tests échoués indiquent une rupture de lignage ou un problème de qualité des données au niveau de la transformation.

Problèmes courants :  métadonnées d'alias de colonne dbt ne métadonnées pas toujours générées par défaut. Configurez dbt pour qu'il capture métadonnées au niveau des colonnes métadonnées les génère dans le manifeste. Sans cela, la traçabilité des colonnes est déduite à partir de l'analyse syntaxique du SQL plutôt que déclarée explicitement, ce qui réduit la précision pour les transformations complexes.

Guide pratique n° 2 : Databricks, Delta Lake et Unity Catalog

Architecture : Importation de donnéesStreaming par lots dans Delta Lake. Les tâches Spark transforment les données via les couches Bronze, Silver et Gold. Unity Catalog gère métadonnées les droits d'accès.

Approche de capture de la traçabilité : Unity Catalog fournit une traçabilité native au niveau des colonnes pour les opérations Spark SQL et les écritures dans Delta Lake. Il capture automatiquement la traçabilité pour les opérations exécutées via l’entrepôt SQL de Databricks et les notebooks Spark. Pour les opérations Spark Python, la traçabilité doit être capturée via une instrumentation explicite ou un métadonnées prenant en charge la traçabilité.

Étapes de mise en œuvre :

1. Activez la capture de la traçabilité Unity Catalog dans la configuration de l'espace de travail Databricks.
2. Veillez à privilégier autant que possible les opérations Spark SQL plutôt que les appels à l'API Python : Unity Catalog enregistre automatiquement la traçabilité des données basées sur SQL, mais nécessite une instrumentation explicite pour Python .
3. Pour les tâches Python , ajoutez l'instrumentation de traçabilité au niveau de la tâche : enregistrez les tables sources, les tables cibles et le type de transformation (jointure, agrégation, filtrage) dans un métadonnées de traçabilité.
4. Connectez votre métadonnées à l'API de traçabilité de Unity Catalog afin d'extraire des enregistrements de traçabilité selon une fréquence programmée ou axé sur des événements .
5. Pour streaming , enregistrez la traçabilité au niveau des micro-lots, notamment le sujet ou le flux source, la logique de transformation et la table Delta de destination.

Approche de test : Utiliser la fonctionnalité de « voyage dans le temps » de Delta Lake pour valider la traçabilité en comparant les données actuelles à une version historique dont la validité est avérée. Les tests de détection de dérive de schéma vérifient que les modifications apportées au schéma en amont ont été correctement propagées à travers les couches de transformation.

Problèmes courants : La couverture de la traçabilité dans Unity Catalog est complète pour les opérations basées sur SQL, mais nécessite un travail supplémentaire pour les tâches Python qui utilisent l'API DataFrame. Les organisations ayant Python importantes doivent prévoir une instrumentation explicite de la traçabilité dans ces pipelines.

Guide pratique n° 3 : Apache Airflow et un entrepôt de données cloud

Architecture : Airflow coordonne les tâches ETL et ELT au sein d'un entrepôt de données cloud BigQuery, Redshift ou Snowflake). Chaque tâche exécute des transformations SQL, des appels d'API et des chargements de fichiers.

Approche de capture de la traçabilité :  métadonnées d’Airflow contient l’historique d’exécution de chaque DAG et de tâche. Les outils de traçabilité peuvent extraire la traçabilité tâche en analysant les enregistrements tâche d’Airflow : quels DAG ont été exécutés, quelles tâches ont été exécutées, quelles entrées elles ont lues et quelles sorties elles ont écrites. Les tâches basées sur SQL permettent d’obtenir une traçabilité au niveau des colonnes grâce à l’analyse SQL. Les tâches non SQL nécessitent une instrumentation explicite de la traçabilité.

Étapes de mise en œuvre :

1. Connectez un outil de traçabilité à métadonnées d'Airflow afin d'extraire les enregistrements relatifs aux DAG et tâche .
2. Pour les tâches SQL, analysez le code SQL exécuté dans chaque tâche extraire les tables sources, les tables cibles et la logique de transformation au niveau des colonnes.
3. Pour les tâches non SQL (Python , appels d'API, chargements de fichiers), ajoutez des annotations de traçabilité explicites à chaque tâche des fonctionnalités de traçabilité d'Airflow ou d'un métadonnées personnalisé.
4. Mettez en correspondance tâche Airflow avec les tables de l'entrepôt correspondantes à l'aide des configurations de connexion définies dans le magasin de connexions d'Airflow.
5. Enregistrez les historiques de version dans votre métadonnées en indiquant tâche , l'ID du DAG, l'horodatage d'exécution, les ressources sources et les ressources cibles.

Approche de test : Créer des capteurs Airflow qui vérifient la fraîcheur des tables en aval et le nombre de lignes après chaque exécution de DAG. Des alertes sont déclenchées lorsque les données attendues n'arrivent pas dans SLA , ce qui déclenche une enquête sur la traçabilité.

Problèmes courants : La qualité de la documentation sur la traçabilité d’Airflow dépend entièrement de la qualité du code SQL et des annotations présentes dans chaque tâche. Les tâches qui exécutent du SQL dynamique (c’est-à-dire du SQL généré à l’exécution à partir de variables) nécessitent un traitement particulier pour extraire une traçabilité précise : l’analyse statique du SQL dynamique produit des résultats incomplets ou incorrects.

Guide pratique n° 4 : Kafka et Streaming

Architecture :les événementsproviennent des systèmes sources et transitent par des sujets Kafka. Les consommateurs traitent ces événements et enregistrent les résultats dans des bases de données, des entrepôts de données ou des sujets Kafka en aval.

Approche de capture de la traçabilité :Streaming est assurée au niveau des consommateurs : chaque consommateur déclare ses sujets d'entrée, les transformations qu'il applique et ses destinations de sortie. Le registre de schémas (Schema Registry) assure le suivi des versions de schéma pour chaque sujet, fournissant ainsi la composante temporelle de la traçabilité. Les outils de traçabilité se connectent au registre de schémas et aux configurations des consommateurs pour construire le graphe streaming .

Étapes de mise en œuvre :

1. Enregistrez chaque sujet Kafka dans le registre de schémas avec un schéma défini. Le registre de schémas fournit l'historique des schémas qui permet de retracer la traçabilité temporelle.
2. Configurer chaque application client pour qu'elle génère métadonnées de traçabilité métadonnées son démarrage et lorsqu'elle traite un lot : sujet d'entrée, version du schéma utilisée, transformation appliquée, sujet de sortie ou table de destination.
3. Connectez votre métadonnées au registre de schémas afin de suivre l'évolution des schémas au fil du temps.
4. Pour les consommateurs qui écrivent dans un entrepôt de données ou une base de données, étendez le graphe de traçabilité depuis le sujet Kafka jusqu'à la table de destination en passant par le consommateur, en utilisant la même approche de traçabilité au niveau des colonnes que celle décrite dans les guides de traitement par lots ci-dessus.
5. Configurer la surveillance de l'actualité de la lignée : streaming doit être mise à jour dans les minutes qui suivent les modifications apportées au pipeline, et non pas quotidiennement.

Approche de test : La surveillance de la file d'attente des messages perdus détecte les violations de schéma et les échecs de transformation. La surveillance du retard des consommateurs détecte lorsque ceux-ci prennent du retard, ce qui indique des problèmes de santé du pipeline susceptibles d'affecter la précision de la traçabilité.

Problèmes courants : Streaming est plus complexe que celle des traitements par lots, car les schémas d’événements évoluent en permanence et les consommateurs peuvent exécuter plusieurs versions simultanément. Le registre de schémas est une infrastructure essentielle : sans lui, il est pratiquement impossible de maintenir streaming précise streaming .

Guide pratique n° 5 : Pipelines d'apprentissage automatique Python

Architecture : Python ou frameworks Python frameworks scikit-learn, PyTorch, TensorFlow, MLflow) chargent jeux de données, effectuent l'ingénierie des caractéristiques, entraîner et enregistrent les artefacts des modèles.

Approche de capture de l'historique : La traçabilité ML nécessite de suivre quatre éléments : les jeu de données utilisées pour apprentissage, les transformations d’ingénierie des caractéristiques appliquées, les apprentissage du modèle et les résultats d’évaluation, ainsi que la version de l’artefact du modèle enregistrée pour déploiement. MLflow fournit un suivi natif des expériences pour les paramètres, les métriques et les artefacts. jeu de données est reliée aux pipelines de données en amont qui ont produit les apprentissage .

Étapes de mise en œuvre :

1. Utilisez MLflow (ou un outil équivalent) pour suivre chaque apprentissage : consignezjeu de données apprentissage , jeu de données de validation, la configuration de l'ingénierie des caractéristiques, les hyperparamètres, les indicateurs d'évaluation et l'artefact du modèle.
2. Reliezjeu de données apprentissage au catalogue de données que la traçabilité en amont jeu de données— depuis le système source jusqu'à la apprentissage , en passant par toutes les transformations — puisse être assurée à partir de l'artefact de modèle.
3. Pour l'ingénierie des caractéristiques, consignez les colonnes d'entrée, la logique de transformation et les noms des caractéristiques de sortie pour chaque caractéristique dujeu de données apprentissage .
4. Enregistrez les artefacts du modèle dans un registre de modèles (MLflow Model Registry, Databricks Model Registry ou équivalent) en y indiquant la référence à apprentissage qui les a générés.
5. Reliez le registre des modèles à votre catalogue de données que chaque version de modèle dispose d'une chaîne de traçabilité visible, depuis les données sources jusqu'à l'artefact de modèle, en passant par les caractéristiques.

Approche de test :des tests de validation des donnéessont effectués surjeux de données apprentissage jeux de données apprentissage afin de vérifier que les données respectent les seuils de qualité définis. Des testsapprentissage permettent de s'assurer que les indicateurs de performance du modèle se situent dans des plages acceptables avant que celui-ci ne soit enregistré en vue de déploiement.

Problèmes courants : Python utilisés pour le développement de modèles ad hoc ne génèrent souvent pas métadonnées de traçabilité. Mettez en place une politique stipulant que apprentissage des modèles de production apprentissage s’appuyer sur des expériences suivies dans MLflow ou un outil équivalent, plutôt que sur des notebooks non suivis. apprentissage non suivies ne peuvent être ni auditées ni reproduites.

Calcul du retour sur investissement (ROI) de la traçabilité des données

Le retour sur investissement de Lineage provient de quatre sources : une réponse plus rapide aux incidents, une réduction des coûts de préparation aux audits, la prévention des pannes en production et l'amélioration de la productivité des analystes.

Réduction du temps de réponse aux incidents

Les incidents liés aux données — rapports erronés, pipelines défaillants, valeurs inattendues — nécessitent une analyse des causes profondes. En l'absence de traçabilité, les ingénieurs doivent remonter manuellement la piste des problèmes à travers requête , les journaux des pipelines et la documentation du système. Grâce à la traçabilité, cette même analyse permet de parcourir le graphe de traçabilité depuis la sortie concernée jusqu'à la source du problème.

Amélioration typique : Le temps moyen de résolution (MTTR) des incidents liés aux données passe de 4 à 8 heures à moins de 30 minutes pour les incidents dont la cause se situe dans un pipeline tracé.

Formule : Économies annuelles liées à la gestion des incidents = (Nombre d'incidents par an) x (Nombre d'heures économisées par incident) x (Coût horaire total des ingénieurs)

Exemple : 50 incidents par an, chacun permettant un gain de temps de 4 heures à 100 $ de l'heure = 20 000 $ par an et par ingénieur de l'équipe d'enquête.

Réduction des coûts liés à la préparation de l'audit

La préparation d'un audit réglementaire nécessite de rassembler la documentation relative à la traçabilité des données concernées par l'audit. En l'absence de traçabilité automatisée, il s'agit d'un processus manuel qui prend plusieurs semaines. Grâce à la traçabilité automatisée, les rapports d'audit sont générés à la demande des enregistrements déjà conservés dans le catalogue.

Amélioration typique :le temps de préparation des auditspasse de 3 à 6 semaines à 1 à 3 jours pour les audits portant sur des actifs de données traçables.

Formule : Économies annuelles liées à l'audit = (Nombre de cycles d'audit par an) x (Nombre de jours économisés par audit) x (Coût journalier total du temps de travail de l'équipe chargée de la conformité)

Exemple : 4 cycles d'audit par an, chacun permettant un gain de temps de 15 jours, avec une équipe de conformité de 4 personnes à 800 $ par personne et par jour = 192 000 $ par an.

Prévention des défaillances de production

Les modifications apportées aux schémas et aux pipelines qui affectent les ressources en aval provoquent des pannes de production qui nuisent aux systèmes de reporting, d'analyse et d'exploitation. L'analyse d'impact basée sur la traçabilité permet aux ingénieurs d'identifier et de corriger les modifications susceptibles de provoquer des pannes avant leur mise en production.

Amélioration typique : Les défaillances de production dues à des répercussions en aval non détectées diminuent de 40 à 60 % après la mise en œuvre d’un suivi de la lignée au niveau des colonnes pour les pipelines critiques.

Formule : Économies annuelles liées à la prévention des pannes = (nombre de pannes évitées par an) × (coût moyen par panne — temps d'ingénierie, impact sur l'activité, SLA )

Exemple : Éviter 10 pannes de production par an, dont le coût moyen s'élève à 15 000 $ chacune, représente une économie de 150 000 $ par an.

Amélioration de la productivité des analystes

Les analystes qui ne parviennent pas à retracer la provenance d'un indicateur transmettent le cas à l'équipe chargée des données afin qu'elle le valide. La traçabilité, qui présente le parcours complet du calcul depuis la source jusqu'au tableau de bord et qui est visible dans le catalogue de données , permet d'éviter la plupart de ces transmissions.

Amélioration typique :les demandes d'intervention adressées à l'équipe chargée des donnéespar les analystes concernant des questions liées à la traçabilité diminuent de 50 à 70 % après la publication de la traçabilité métier pour indicateurs clés.

Formule : Économies annuelles liées à la productivité des analystes = (nombre d'escalades évitées par mois) × 12 × (temps moyen consacré à chaque escalade) × (coût horaire total du temps de travail de l'équipe chargée des données)

Exemple : Éviter 30 escalades par mois, à raison de 2 heures chacune à 80 $ de l'heure = 57 600 $ par an.

Calcul du retour sur investissement total

Retour sur investissement annuel par lignée = Économies réalisées grâce à la gestion des incidents + Économies réalisées grâce aux audits + Économies réalisées grâce à la prévention des défaillances + Économies réalisées grâce à la productivité des analystes

Exemple de montant total :20 000 $+ 192 000 $ + 150 000 $ + 57 600 $ = 419 600 $ par an

Exemple de coût annuel de la plateforme : 150 000 $

Taux de rentabilité (ROI) :(419 600 $ – 150 000 $) / 150 000 $ = 180 %

La plupart des organisations ayant mis en place des solutions de traçabilité abouties enregistrent un retour sur investissement positif dans les 6 à 12 mois suivant déploiement.

Pannes courantes liées à la lignée et analyses rétrospectives

Échec n° 1 : Lineage a été déployé mais n'est pas maintenu

Ce qui s'est passé : En 2023, une organisation a mis en place un système de traçabilité sur 200 pipelines. En 2025, 60 % des enregistrements de traçabilité n'avaient pas été mis à jour depuis plus d'un an. Les ingénieurs ont cessé de se fier à la traçabilité, car celle-ci ne reflétait plus la configuration actuelle des pipelines. Le catalogue est alors devenu un document historique plutôt qu'un outil opérationnel.

Cause première : La traçabilité a été enregistrée via une importation massive ponctuelle plutôt que par une capture automatisée continue liée à l'exécution des pipelines. Lorsque les pipelines ont été modifiés, les enregistrements de traçabilité n'ont pas été mis à jour.

Solution : La capture de la traçabilité doit être axé sur des événements déclenchée par l'exécution des pipelines, les modifications de schéma et les mises à jour du catalogue — et non planifiée comme une tâche batch périodique. Reliez l'ingestion de la traçabilité aux événements de la plateforme d'orchestration afin que la traçabilité soit mise à jour lors de l'exécution des pipelines.

Erreur n° 2 : la traçabilité jeu de données est considérée comme suffisante pour garantir la conformité

Ce qui s'est passé : Une organisation de services financiers a mis en place une traçabilité jeu de données pour l’ensemble de ses processus de reporting réglementaire. Lors d’un audit BCBS 239, les autorités de régulation ont exigé une traçabilité au niveau des champs, de la source jusqu’à la soumission réglementaire, pour certains indicateurs de risque spécifiques. La traçabilité jeu de données ne permettait pas de répondre à cette exigence. Sous la pression de l’audit, l’organisation a passé trois semaines à reconstituer manuellement la traçabilité au niveau des colonnes.

Cause première : la traçabilitéjeu de données a été mise en œuvre car elle était plus rapide et moins coûteuse. La traçabilité au niveau des colonnes était considérée comme une amélioration future. Les exigences réglementaires présupposaient une traçabilité au niveau des colonnes.

Solution :Définirles exigences en matière de traçabilité en fonction des obligations réglementaires avant le début de la mise en œuvre. Pour les données réglementées dans les secteurs des services financiers, de la santé et de l'industrie pharmaceutique, la traçabilité au niveau des colonnes n'est pas facultative. Il convient de la mettre en œuvre dès le départ pour les pipelines réglementés.

Échec n° 3 : mise en œuvre de Lineage sans tenir compte du contexte métier

Ce qui s'est passé :uneentreprise du secteur de la distribution a mis en place une traçabilité technique complète au niveau des colonnes sur l'ensemble de son parc de données. Les ingénieurs pouvaient retracer n'importe quel champ à travers n'importe quel pipeline. Les analystes et les utilisateurs métier ne pouvaient toutefois pas exploiter cette traçabilité, car celle-ci était exprimée exclusivement en termes techniques (noms de tables, noms de colonnes, opérations SQL), sans aucun lien avec les concepts métier ou les indicateurs.

Cause première :la mise en œuvre de la traçabilitérelevait entièrement de la responsabilité de l'équipe d'ingénierie des données, sans aucune contribution des responsables de données ni des utilisateurs métier. La traçabilité métier — c'est-à-dire la mise en correspondance des actifs techniques avec les termes métier et les indicateurs clés de performance — n'a jamais été mise en place.

Solution : Mettez en place dès le départ une traçabilité métier parallèlement à la traçabilité technique. Collaborez avec les responsables des données et les propriétaires de domaine pour établir une correspondance entre les indicateurs métier clés (chiffre d'affaires, nombre de clients, taux de désabonnement) et leurs chaînes de traçabilité technique. Publiez cette correspondance dans le catalogue de données les analystes puissent y accéder.

Échec n° 4 : la traçabilité apprentissage de l'IA n'est mise en œuvre qu'après l'audit du modèle

Ce qui s'est passé : Un organisme de santé a entraîné un support la décision clinique sur un jeu de données des données issues d’un système source qui avait été abandonné et remplacé. Le système source de remplacement présentait des caractéristiques de qualité différentes. Les performances du modèle se sont dégradées après déploiement. Lorsque les auditeurs ont demandé la provenance apprentissage , l’organisme n’a pas été en mesure de fournir un enregistrement complet de la traçabilité, enregistrement la traçabilité apprentissage de l’IA n’avait pas été mise en place.

Cause première : La traçabilité des données a été mise en place pour les pipelines analytiques, mais n’a pas été étendue aux apprentissage en IA. apprentissage ont été sélectionnées et traitées en dehors du parc de données réglementé.

Solution :Étendrela traçabilité aux pipelines d'IA avant que les modèles n'entrent en production. Définir une politique stipulant que tout modèle de production doit disposer d'une traçabilité documentée apprentissage comme condition préalable déploiement. Utiliser MLflow ou un outil équivalent pour suivre apprentissage et relierjeu de données apprentissage au catalogue de données en amont.