Qualité des données avant un projet IA : méthode de cadrage

La qualité des données pour un projet d’intelligence artificielle (IA) désigne leur aptitude à soutenir un usage précis. Une donnée n’est pas « bonne » en absolu : elle peut convenir à une recherche documentaire et être insuffisante pour entraîner un modèle, mesurer une performance ou automatiser une décision. Le diagnostic commence donc par le résultat attendu, pas par un nettoyage généralisé du patrimoine.

Les entités à cartographier sont le cas d’usage, la population ou l’objet observé, les sources, les champs, les événements, les transformations, les libellés, les propriétaires et les consommateurs. Cette vue permet de relier chaque défaut à un effet possible : réponse incomplète, biais de sélection, donnée obsolète, fuite entre entraînement et test, absence de preuve ou impossibilité d’exploiter le système dans la durée.

Un inventaire exhaustif peut mobiliser beaucoup d’efforts sans dire quelles données sont nécessaires. Décrivez d’abord l’entrée, la sortie, l’utilisateur, la fréquence, le niveau de vérification et la conséquence d’une erreur. Une aide à la rédaction, une classification de demandes et une prévision de charge n’exigent ni les mêmes historiques, ni la même fraîcheur, ni le même niveau d’explicabilité.

Transformez le besoin en questions de données :

Cette traduction limite l’audit aux données qui influencent réellement la faisabilité et la valeur.

Les dimensions doivent être définies avec une règle de mesure et un seuil propre au cas d’usage. Un taux global masque souvent les défauts concentrés sur une catégorie rare mais importante.

Ajoutez l’unicité lorsque les doublons changent le résultat, et la validité lorsque les formats ou domaines sont contraints. Le tableau de qualité doit relier chaque anomalie à son impact, sa règle de correction et son responsable.

La disponibilité technique ne signifie pas que la donnée est utilisable. Il faut connaître son propriétaire, sa finalité de collecte, ses conditions d’accès, ses dépendances et les transformations subies. Ce travail de gouvernance doit être mené avec les fonctions concernées ; il ne constitue pas une conclusion juridique et ne remplace pas l’analyse compétente propre à l’organisation.

Construisez une fiche par source avec le système d’origine, le contact, le schéma, la fréquence, l’historique disponible, les règles d’accès, les consommateurs et le niveau de confiance. Ajoutez un dictionnaire métier pour les termes ambigus. « Client actif », « dossier résolu » ou « retard » peuvent varier selon les équipes et les périodes ; entraîner ou évaluer un système sans figer ces définitions rend les résultats difficiles à interpréter.

Le lignage décrit le chemin depuis la source jusqu’au jeu utilisé : extractions, filtres, jointures, enrichissements et exclusions. Il permet de reproduire une expérience, d’identifier l’origine d’une anomalie et d’évaluer l’effet d’un changement amont.

Un historique reflète le processus qui l’a produit. Des dossiers absents, des règles anciennes, une population surreprésentée ou des décisions humaines non documentées peuvent limiter ce que le modèle apprend. Comparez les distributions par période, source, catégorie et contexte d’usage. Examinez séparément les cas rares dont l’erreur aurait un impact important.

Une fuite de données survient lorsqu’une information indisponible au moment réel de la prédiction apparaît dans les données d’apprentissage ou d’évaluation. Elle peut venir d’un champ créé après l’événement, d’un agrégat calculé sur le futur, d’un doublon réparti entre deux jeux ou d’une transformation ajustée sur l’ensemble des données. Le résultat de test paraît alors meilleur qu’il ne le sera en exploitation.

• Séparer les jeux selon le temps, le groupe ou l’entité lorsque le cas l’exige ;
• dédupliquer avant la répartition ;
• ajuster les transformations uniquement sur le jeu d’apprentissage ;
• geler un jeu de test final et limiter son utilisation ;
• reproduire les données réellement disponibles au moment de l’inférence.

Le jeu d’évaluation représente les situations sur lesquelles une décision de projet sera prise. Il associe des entrées à une référence, des critères ou une grille de revue. Pour une application générative, toutes les sorties ne possèdent pas une réponse unique : une grille peut examiner la fidélité aux sources, la complétude, le format, la sécurité et l’utilité métier.

Incluez des cas courants, limites, ambigus, incomplets et hostiles. Documentez la provenance et la raison de chaque cas. Lorsque des experts annotent, fournissez des consignes et comparez leurs désaccords : un faible accord peut révéler un objectif mal défini plutôt qu’un problème de modèle.

Le jeu d’évaluation doit rester versionné. Les erreurs rencontrées en pilote ou en production peuvent alimenter un jeu de régression distinct, afin de vérifier qu’une correction ne réintroduit pas un défaut connu.

La préparation n’est pas un verdict binaire sur tout le patrimoine. Elle exprime une décision pour un périmètre, avec des limites et un plan. Le dossier de passage au pilote peut préciser les sources retenues, les défauts connus, les corrections appliquées, les segments exclus, le jeu d’évaluation, les contrôles et les responsables.

Après le lancement, surveillez les schémas, volumes, valeurs manquantes, distributions, retards et changements de définition. La qualité des données est un produit maintenu, avec des propriétaires et des alertes, pas une étape définitivement terminée.