Demandez à n'importe quel responsable data ayant déployé le machine learning à l'échelle de l'entreprise, et il vous dira la même chose : le modèle était rarement le problème. C'était la gouvernance autour de celui-ci. Les modèles qui fonctionnaient à merveille dans les environnements de test se dégradaient en production parce que les données qui les alimentaient n'étaient pas celles sur lesquelles ils avaient été entraînés. Les features construites à partir de données sources que personne ne surveillait ont dérivé silencieusement pendant des mois, et les prédictions du modèle ont suivi. 

Les modèles de machine learning ne valent que ce que valent les données qui les sous-tendent. Pour agir en conséquence, il faut répondre de manière systématique à une question plus difficile : comment une organisation gouverne-t-elle la qualité des données dans un système qui apprend en continu, change fréquemment et fonctionne simultanément sur une douzaine de systèmes sources ? 

Pourquoi la gouvernance des données est importante dans le machine learning 

La gouvernance des données dans un contexte de machine learning n'est pas la même discipline que dans un contexte d'analytique traditionnelle. Un tableau de bord mal gouverné affiche un chiffre incorrect. Un modèle de ML mal gouverné encode cette erreur dans ses prédictions et influence les décisions bien après que le problème de données sous-jacent a été corrigé. 

Une étude McKinsey de 2024 citée par Quinnox a révélé que 42 % des entreprises déployant de l'IA générative citent l'intégrité du contenu et la gouvernance comme un risque opérationnel majeur. Gartner prévoit qu'en 2026, 50 % des grandes entreprises disposeront de programmes formels de gestion des risques liés à l'IA, contre moins de 10 % en 2023. La plupart des échecs de gouvernance du ML surviennent dans cet écart. 

L'AI Act de l'UE, entré en vigueur en août 2024, en a fait une question réglementaire. Comme le note EW Solutions dans son analyse du cadre de gouvernance de l'IA et des données, une mauvaise qualité des données, une lignée opaque et des contrôles d'accès faibles amplifient les biais du modèle et exposent à des sanctions réglementaires. 

Défis courants de qualité des données dans les pipelines ML 

Les pipelines ML sont fragilisés par la dérive comportementale, le changement de distribution, l'incohérence des features et l'asymétrie entraînement-production, autant de modes de défaillance que les programmes de validation fondés sur des règles n'ont pas été conçus pour détecter. 

• Asymétrie entraînement-production : Les données utilisées pour entraîner un modèle présentent des caractéristiques statistiques différentes de celles rencontrées par le modèle en production, parce que le pipeline de données de production n'a pas été surveillé pour rester cohérent avec la distribution d'entraînement. Un modèle de détection de fraude entraîné sur des données de transaction produira des résultats peu fiables lorsque cette distribution évolue à cause d'un nouveau canal de paiement, d'un schéma saisonnier ou d'une modification d'un système source dont personne n'a informé l'aval.

  
  

• Features manquantes et incomplètes : Les features calculées à partir de données sources présentant des taux de valeurs nulles systématiques ou des champs renseignés de manière intermittente produisent des vecteurs de features instables. Lorsque les taux de complétude changent en production, les représentations apprises par le modèle ne tiennent plus. La mauvaise qualité des données coûte en moyenne 15 millions de dollars par an aux organisations, et dans les contextes ML l'effet cumulatif fait de ce chiffre un plancher. 

  
  

• Bruit d'étiquetage et empoisonnement des données : Des enregistrements mal étiquetés, des schémas de classification appliqués de manière incohérente et un empoisonnement délibéré des données produisent des modèles qui se trompent avec assurance de manière spécifique et exploitable. Comme le documente la recherche d'AI Multiple sur la qualité des données pour l'IA, l'empoisonnement des données introduit des informations trompeuses dans les jeux de données d'entraînement d'une manière extrêmement difficile à détecter après le déploiement. 

  
  

• Dérive de schéma dans les systèmes source : Lorsque les systèmes sources en amont ajoutent, suppriment ou renomment des colonnes sans prévenir les équipes de pipeline, les features échouent silencieusement ou sont calculées à partir des mauvais champs. Le modèle continue de produire des résultats. Ces résultats ne sont plus calculés à partir des entrées prévues. 

Risques de gouvernance à travers les sources de données et les modèles 

Le risque de gouvernance dans les écosystèmes de ML se répartit sur chaque source de données contribuant à un modèle, sur chaque transformation convertissant des données brutes en features, et sur chaque environnement où les résultats sont consommés. 

Le schéma de risque de gouvernance le plus courant est la dépendance invisible : un modèle ML ayant des dépendances non documentées à des sources de données spécifiques ou à des versions de schéma particulières, de sorte que les changements dégradent les performances du modèle sans déclencher la moindre alerte. Le modèle n'est pas surveillé pour la dérive comportementale. Les données source ne sont pas surveillées pour les changements structurels. Le pipeline de features n'est pas validé par rapport à sa distribution d'origine. Chacun représente une faille de gouvernance. Ensemble, ils constituent un système non gouverné en production. 

La dérive du modèle aggrave cela. Selon des recherches compilées par Quinnox, 57 % des programmes de gouvernance de l'IA ont mis en œuvre la détection des biais et 45 % utilisent la surveillance de la dérive dans les pipelines MLOps. La majorité restante exécute des modèles qui peuvent dériver sans être détectés. 

Sans lignée documentée depuis la source, en passant par la transformation puis par l'entrée du modèle, il est impossible de remonter la dégradation des performances du modèle jusqu'à sa cause profonde. Le cadre de gouvernance de l'IA d'EW Solutions identifie la documentation de la lignée comme fondamentale. 

Bonnes pratiques pour garantir l'intégrité des données à travers les écosystèmes ML 

Les organisations qui maintiennent l'intégrité des données à travers les écosystèmes ML considèrent la qualité des données comme une discipline continue appliquée tout au long du cycle de vie ML, et non comme une étape de prétraitement appliquée une seule fois avant l'entraînement. 

• Surveiller les données d'entraînement pour détecter une dérive comportementale avant le réentraînement : Avant tout cycle de réentraînement, la surveillance comportementale doit confirmer si les données de production actuelles proviennent toujours d'une distribution cohérente ou si elles ont dérivé. Un modèle réentraîné sur des données dérivées encode la dérive. 

  
  

• Valider les pipelines de features au niveau de l'enregistrement, pas seulement au niveau du pipeline : Un pipeline de features qui s'exécute avec succès n'est pas un pipeline qui produit des valeurs de features correctes. La validation au niveau de l'enregistrement par rapport à des règles métier définies détecte les cas où le pipeline s'exécute mais où les valeurs de features sont erronées. 

  
  

• Suivre les changements structurels dans chaque système source qui contribue à un modèle : Les changements de schéma comptent parmi les causes les plus fréquentes de dégradation silencieuse des features ML. La surveillance structurelle à la source les détecte tôt. 

  
  

• Faire respecter les exigences de fraîcheur des données pour les features sensibles au temps : Les features construites à partir de données obsolètes produisent des prédictions obsolètes. Dans la détection de fraude, la prévision de la demande et l'évaluation des risques en temps réel, la surveillance de la ponctualité des flux de données de features est une exigence de gouvernance. 

  
  

• Maintenir une piste d'audit des métriques de qualité des données dans le temps : Sans un enregistrement chronologique des taux de complétude, des profils de distribution et des versions de schéma, l'analyse des causes profondes de la dégradation du modèle relève de la conjecture. 

Outils et cadres pour la gouvernance des données ML 

Trois catégories comptent. 

La première est la détection d'anomalies comportementales sur les données sources et les features. La mise en œuvre de General Electric sur sa plateforme IIoT industrielle Predix, documentée par AI Multiple, montre une surveillance continue à grande échelle : GE a déployé des outils automatisés garantissant que les données alimentant ses modèles d'IA étaient exactes, cohérentes et fiables, réduisant ainsi l'intervention manuelle. C'est la capacité que digna Data Anomalies fournit : des bases comportementales apprises par l'IA avec détection continue des changements inattendus dans les distributions, les volumes et les schémas de métriques, sans configuration manuelle de seuils. 

La deuxième est la validation au niveau de l'enregistrement. digna Data Validation applique des règles définies par l'utilisateur sur les jeux de données d'entraînement et de features, détectant les enregistrements incomplets, les valeurs invalides et les violations d'intégrité relationnelle avant qu'ils n'atteignent la couche modèle. Associé à digna Schema Tracker, qui surveille en continu les tables sources pour détecter les changements structurels, cela permet de traiter les deux causes les plus courantes de dégradation silencieuse des features. 

La troisième est la surveillance de la ponctualité et des tendances. digna Timeliness détecte les retards et les chargements manquants avant que les pipelines de features n'absorbent des données incomplètes. digna Data Analytics fournit l'enregistrement historique d'observabilité qui répond à la question de gouvernance la plus importante : ces données ont-elles été systématiquement fiables pendant toute la période utilisée pour l'entraînement ou l'évaluation ? 

L'initiative Airbnb Data University est instructive : Airbnb a fait passer l'engagement hebdomadaire avec ses outils internes de data science de 30 % à 45 % grâce à des programmes personnalisés de littératie des données. Les outils de gouvernance sont nécessaires mais ne suffisent pas. Les organisations qui réussissent combinent une infrastructure de surveillance avec une propriété claire des données. 

Dernière réflexion : la gouvernance n'est pas une contrainte pour le ML. C'est le fondement. 

La gouvernance ne ralentit pas le ML. Le ML non gouverné se ralentit lui-même, à travers la dégradation du modèle, les enquêtes sur les incidents, la surveillance réglementaire et l'érosion progressive de la confiance dans les résultats d'IA parmi les parties prenantes qui en dépendent. 

Les organisations qui avancent le plus vite avec le ML sont celles qui ont intégré une surveillance continue et automatisée de la qualité des données dans leurs pipelines. Leurs modèles se réentraînent sur des données qu'ils peuvent vérifier. Leurs features sont calculées à partir de sources qu'ils surveillent. Leurs incidents sont détectés dans le pipeline, et non dans la conséquence métier. 

La gouvernance est ce qui permet de rendre ces données suffisamment bonnes pour être dignes de confiance. 

Construisez la fondation de qualité des données dont votre écosystème ML a besoin. 

digna surveille les anomalies comportementales, valide les enregistrements à la source, suit les changements structurels, impose la fraîcheur des données et fournit le registre historique des tendances qu'exige la gouvernance ML. Le tout dans la base de données, sans que les données quittent votre environnement. 

Réserver une démo  Découvrir la plateforme digna