Évaluation des données

Objectif

L'évaluation des données établit si les données disponibles suffisent pour réaliser un cas d'usage précis et ce que coûte l'écart. Elle se place après le cadrage du cas d'usage et avant le choix d'un modèle ou d'un fournisseur.

Neil Lawrence constate que les propositions de projet accordent peu d'attention aux données, sous-estiment le travail qu'elles demandent et lui donnent trop peu de ressources. Nithya Sambasivan et ses coauteurs ont interrogé 53 praticiens de l'IA dans des domaines à fort enjeu. Ils appellent «cascades de données» les effets négatifs qu'un problème de données déclenche en aval. Ces effets restent souvent invisibles et arrivent tard. Parmi les praticiens interrogés, 92% en ont vécu au moins une.

Le livrable est un registre d'évaluation des données. Chaque ligne décrit un jeu de données: le résultat des contrôles, la bande atteinte, le statut, le responsable de chaque écart et son coût estimé. CRISP-DM documente la compréhension des données dans des rapports sur la collecte initiale, la description, l'exploration et la qualité des données. Le registre condense en une ligne par jeu les rapports de collecte, de description et de qualité. L'exploration revient à l'analyse exploratoire des données. Le sponsor lit dans le registre ce que le projet devra payer avant le premier modèle.

Usage

Quand l'utiliser

• Cas d'usage d'IA cadré: vérifier les données des blocs de l'AI Canvas avant d'engager un budget.
• Offre d'un fournisseur à évaluer: contrôler que l'organisation détient les données que la solution suppose.
• Données qui «doivent exister quelque part»: obtenir un extrait avant que le planning ne repose sur elles.
• Nouvelle question posée à des données déjà utilisées: refaire le contrôle d'adéquation.
• Fusion de deux jeux déjà évalués: évaluer le jeu combiné, qui pose ses propres risques de réidentification.
• Assistant génératif sur des documents internes: évaluer le corpus comme un jeu de données.
• Tableau de bord ou analyse sans IA: appliquer les mêmes contrôles aux sources avant de construire le rapport.

Quand ne pas l'utiliser

• Cas d'usage pas encore choisi: sans tâche, la bande A ne se juge pas et la liste des données reste à deviner. Recenser et prioriser les cas d'usage d'abord.
• Jeu retenu et chargé, à comprendre en profondeur: passer à l'analyse exploratoire des données.
• Données d'un système encore à construire: rien n'existe à évaluer. Définir les éléments dans un dictionnaire de données.

Description

Les bandes de maturité de Lawrence

Neil Lawrence a proposé en 2017, dans un article de position, des niveaux de maturité des données (data readiness levels) sur le modèle des niveaux de maturité technologique de la NASA. Aucun organisme ne les a normalisés. Les niveaux forment trois bandes notées A, B et C. Chaque bande compte des sous-niveaux, de C4 pour les données les moins prêtes à A1 pour les plus prêtes.

La bande C porte sur l'accès. En C4, quelqu'un affirme que la donnée existe et personne ne l'a vue. Lawrence parle de données par ouï-dire: «Le service des ventes doit avoir un relevé de ça.» En C1, la donnée se charge dans un logiciel d'analyse. Les questions éthiques et juridiques de son traitement sont réglées.

La bande B porte sur la fidélité. La donnée chargée décrit-elle ce qu'elle prétend décrire? Lawrence situe dans cette bande la difficulté principale du data scientist: l'écart entre ce que les gens croient avoir dans leurs données et ce qui s'y trouve. Atteindre B1 est souvent la partie la plus coûteuse du projet. En B1, l'analyste connaît les limites du jeu. Sous B1, un défaut de fidélité reste ouvert.

La bande A porte sur l'adéquation à une tâche. Un jeu de données n'y entre qu'une fois la tâche définie. Un jeu propre et complet peut ne contenir aucune trace de la variable à prédire. Le même jeu peut atteindre A1 pour prédire les résiliations et rester en B1 pour prédire la réaction à une offre.

Nous rangeons selon ces bandes les contrôles que fournissent le guide de l'IIBA et CRISP-DM.

Partir de la décision et de la tâche

L'analyste commence par la tâche: elle fixe la liste des données à évaluer. Il reprend le cas d'usage cadré: la décision servie, ce que le modèle prédit, l'action qui suit. Il dresse la liste des données nécessaires: les données d'entrée, la variable à prédire et la période d'historique. La liste distingue les données déjà collectées de celles à collecter.

Pour planifier la collecte, l'analyste fixe aussi quand et comment collecter les données et comment les valider une fois collectées.

Fixer les critères avec le métier

Le guide de l'IIBA confie la validation métier aux parties prenantes qui ont autorité sur les données. Elles approuvent les sources et fixent les critères d'acceptation. Un critère dit par exemple quelle part de valeurs vides reste tolérable pour la variable à prédire ou quelle période l'historique doit couvrir. Avant les contrôles, l'analyste les écrit comme des critères d'acceptation vérifiables. Un seuil fixé après la mesure se règle sur le résultat.

Vérifier l'existence et le propriétaire

Pour chaque ligne de la liste, l'analyste note qui détient la donnée et dans quel système. Une affirmation comme «le centre d'appels enregistre le motif de chaque appel» reste en C4 jusqu'à ce qu'un extrait la confirme. Sans extrait, le projet découvre en développement un champ vide ou une autre période. L'analyste demande au propriétaire un extrait réel sur la période visée. Une description de champ ou un schéma de base ne remplace pas l'extrait. Le dictionnaire de données dit ce que le champ devrait contenir. L'extrait montre ce qu'il contient.

Vérifier l'accès et le droit d'usage

L'accès pose des questions techniques: le format, l'emplacement, la dispersion de la donnée sur plusieurs systèmes. Un registre tenu à la main, un PDF ou un ancien format machine en sont des cas courants. Une donnée interne coûte souvent moins cher à obtenir qu'une donnée externe. Le guide de l'IIBA ajoute les exigences non fonctionnelles de la source: confidentialité, sécurité, durée de conservation, fréquence de collecte et accords de niveau de service. Une exigence de confidentialité ou de sécurité peut à elle seule rendre un jeu inutilisable.

Le droit d'usage pose des questions juridiques et contractuelles. CRISP-DM demande de vérifier ce droit. Une donnée collectée pour exécuter un contrat ne peut pas toujours entraîner un modèle. Une licence de données externes peut exclure cet usage. L'analyste nomme la contrainte et le service qui la tranche. Les données personnelles relèvent de la loi fédérale sur la protection des données.

Contrôler la qualité sur l'extrait

L'analyste mesure la qualité sur l'extrait que le projet utilisera. Le guide de l'IIBA nomme cinq caractéristiques et propose un test pour chacune. CRISP-DM et Lawrence ajoutent le codage des valeurs manquantes.

Une donnée passée par un tableur demande un contrôle supplémentaire. Lawrence cite le tri qui oublie une colonne et décale des valeurs sans message d'erreur. Il range aussi dans la bande B la vérification du processus de collecte: était-il aléatoire ou orienté? Le guide de l'IIBA précise que la validation reste sommaire à ce stade. L'analyse exploratoire des données fait ensuite l'examen détaillé.

Retracer le lignage

Le lignage dit d'où vient la donnée, quelles transformations elle a subies et où elle est stockée. Sans lignage, l'analyste ne peut pas juger la qualité. Une donnée agrégée peut cacher ses valeurs manquantes. Lawrence rapporte un projet de prévision du paludisme en Ouganda. Les données par district avaient été agrégées sans traiter les valeurs manquantes. Le modèle n'a d'abord montré aucune corrélation spatiale. Sur les données brutes, l'équipe a traité les valeurs manquantes et retrouvé la corrélation attendue. Une erreur de traitement en bande B a produit un résultat négatif en bande A. Personne n'avait documenté l'agrégation. Le lignage rend visible une étape de ce type avant la modélisation.

Deux sources codent parfois la même information différemment: des chiffres dans l'une, des lettres dans l'autre. L'analyste note la correspondance à établir. Le data mapping la spécifie ensuite.

Juger le volume et la représentativité pour la tâche

Aucune des sources citées ne fixe de volume minimal. La réponse dépend de la tâche et du modèle. Nous conseillons de poser une question vérifiable: chaque cas que la décision doit distinguer compte-t-il assez d'exemples dans l'historique? Un événement annuel comme une échéance de contrat demande plusieurs années d'historique. Un canton à faible clientèle ou un produit récent peut ne compter que quelques dizaines de cas.

La représentativité se juge par rapport à la population sur laquelle le modèle décidera. Une enquête dont l'échantillon diffère de la population visée est le cas classique. Un historique qui ne contient que les dossiers choisis par un collaborateur reflète ce choix. Ces biais se repèrent à ce stade avant qu'un modèle les apprenne.

Ce contrôle classe un jeu en bande A pour une tâche donnée. Changer de tâche change le résultat.

Décider: lancer, corriger d'abord ou arrêter

Aucune des sources citées ne formule cette décision à trois issues. C'est notre recommandation de praticien. L'analyste donne d'abord un statut à chaque jeu de données: retenu, à corriger ou écarté. Le cas d'usage reçoit ensuite sa décision.

Les parties prenantes qui ont autorité sur les données approuvent les sources retenues et signent le registre.

La décision sur le cas d'usage dépend de ses jeux indispensables. Quand tous sont retenus, il se lance. Un jeu indispensable à corriger donne «corriger d'abord»: le cas d'usage attend la correction. Un jeu indispensable écarté arrête le cas d'usage. Un jeu accessoire écarté réduit le périmètre. Le modèle se construit sans lui. Google conseille de lancer un produit sans apprentissage automatique tant que les données manquent. Selon ce guide, une heuristique simple obtient une partie du gain attendu.

Le guide de l'IIBA admet qu'une question de recherche soit abandonnée quand les données coûtent trop cher à obtenir. Lawrence imagine les phrases que ses niveaux rendraient possibles. L'une estime le coût d'amener un jeu en B1. Une autre reporte une étude jusqu'à ce qu'un partenaire garantisse un jeu en C1.

Ce qui fausse l'évaluation

La qualité mesurée sur l'entrepôt. L'équipe data affirme que l'entrepôt est propre. Le projet filtre pourtant une période, un produit ou une région. L'analyste mesure l'extrait du projet, qui porte ses propres défauts.

La fusion non réévaluée. Deux jeux évalués séparément donnent un jeu combiné à réévaluer. Selon Lawrence, des données médicales peuvent se réidentifier facilement une fois croisées avec d'autres jeux. Deux protocoles de collecte différents rendent aussi la fusion difficile.

Le travail sur les données sous-estimé. Lawrence prévoyait quelques heures d'un week-end pour rendre chargeables les métadonnées des actes d'une conférence. Le travail a pris environ six jours ouvrés. Le jeu comptait 3'198 articles et ne posait aucune question de confidentialité. Le registre chiffre chaque écart pour que ce coût entre au budget.

Considérations IA

Un assistant IA qui exécute du code accélère le profilage. À partir d'un dictionnaire de données, il écrit les requêtes de comptage des valeurs nulles, des doublons et des valeurs spéciales. Il résume la sortie d'un outil de profilage en une liste d'anomalies à soumettre au propriétaire. Il lit un échantillon d'un champ en texte libre et estime son contenu. Il rédige les questions à poser à chaque propriétaire de données.

L'assistant ne confirme pas l'existence d'une donnée. Un assistant qui affirme «votre CRM enregistre probablement la date du dernier contact» produit du ouï-dire. Sa phrase reste en C4 comme toute affirmation sans extrait. Il ne juge pas le droit d'usage, que tranchent le juriste et le propriétaire. L'extrait contient souvent des données personnelles. L'analyste le soumet seulement à un assistant que son organisation a validé. À défaut, il travaille sur un extrait anonymisé.

Pour un assistant génératif qui répond à partir de documents internes, les données sont ces documents. Nous appliquons les mêmes contrôles au corpus. En bande C: les documents existent-ils sous forme lisible? Qui a le droit de lire lequel? En bande B: quelle version fait foi? Lesquelles sont périmées? En bande A: couvrent-ils les questions que les utilisateurs poseront? La génération augmentée par récupération ne corrige aucun de ces défauts: elle les restitue dans ses réponses.

Le règlement européen sur l'IA formule des contrôles proches aux paragraphes 2 à 4 de son article 10. Cet article s'applique aux systèmes d'IA à haut risque. Il atteint aussi un fournisseur suisse qui met un tel système sur le marché de l'Union européenne. Les pratiques de gouvernance des données y comprennent l'évaluation de la disponibilité, de la quantité et de l'adéquation des jeux nécessaires et l'identification des lacunes. Les jeux doivent être pertinents, suffisamment représentatifs, dans toute la mesure du possible exempts d'erreurs et complets au regard de la destination du système. Ils tiennent compte du cadre géographique, contextuel, comportemental ou fonctionnel de son utilisation. Un projet hors du haut risque peut s'en servir comme grille de contrôle.

Exemples

Un assureur ménage romand veut prédire quels clients résilieront leur police à l'échéance. Les polices et les sinistres sont indispensables au cas d'usage. Les motifs d'appel sont accessoires. Le registre au 30 juin 2025 donne un statut à chaque jeu de données.

Aucun budget ne comble l'historique manquant des motifs d'appel. Seul le temps le remplit. Pour les sinistres, cinq jours de travail sur la correspondance des codes rendent six ans d'historique exploitables. Ce coût justifie de corriger le jeu.

Visualisations

Le registre tient en un tableau: une ligne par jeu de données, une colonne par contrôle, la bande et le statut en fin de ligne. Une couleur par statut rend le registre lisible pour un comité. Quand plusieurs cas d'usage partagent un jeu de données, une colonne par cas d'usage montre la bande que ce jeu atteint pour chacun.

Coût

Outils

Un tableur suffit pour tenir le registre. L'analyste profile un extrait en SQL sur la base source. En Python, ydata-profiling compte les valeurs nulles, les doublons et les distributions par champ. Great Expectations écrit les contrôles de qualité sous forme de règles exécutables. OpenRefine sert à explorer un extrait sans programmer. Un catalogue de données comme DataHub, Collibra ou Microsoft Purview donne les propriétaires et le lignage quand l'organisation en tient un. Le dictionnaire de données fournit la définition attendue de chaque champ, que l'extrait confirme ou dément.

Sources

Aucun référentiel ne décrit l'évaluation des données comme une technique à part entière. Le guide de l'IIBA en décrit les contrôles. Les bandes de Lawrence sont la proposition d'un auteur. La décision à trois issues est notre synthèse.

• IIBA (2020), Guide to Business Data Analytics, §2.2 Source Data (§2.2.1 à §2.2.4) et §2.3.3 Explore Data: la planification de la collecte, les exigences non fonctionnelles, les lacunes de données, le lignage, la validation métier et technique, les cinq caractéristiques de qualité.
• Lawrence, N. D. (2017), Data Readiness Levels, arXiv:1705.02245: les bandes C, B et A, les données par ouï-dire, la fusion de jeux et les deux études de cas.
• Chapman, P. et al. (2000), CRISP-DM 1.0: Step-by-step data mining guide: la phase de compréhension des données, ses rapports et le droit d'utiliser les données.
• Règlement (UE) 2024/1689 sur l'intelligence artificielle, article 10, paragraphes 2 à 4: la gouvernance des données des systèmes à haut risque.
• Sambasivan, N. et al. (2021), «Everyone wants to do the model work, not the data work»: Data Cascades in High-Stakes AI, CHI '21: la notion de cascade de données et sa fréquence chez 53 praticiens de l'IA dans des domaines à fort enjeu.
• Google, Rules of Machine Learning, règle 1: lancer sans apprentissage automatique tant que les données manquent.