Faut-il nettoyer toutes vos données avant de lancer un projet IA ?

Une donnée prête pour un projet IA n’est pas forcément parfaite. C’est une donnée dont l’équipe connaît :

• la source et le propriétaire ;

• la signification métier ;

• la date ou la règle de mise à jour ;

• les droits d’accès et les conditions d’utilisation ;

• les défauts connus ;

• l’effet de ces défauts sur le résultat attendu.

Pour un assistant documentaire, la fraîcheur des procédures et les autorisations peuvent compter davantage que l’uniformité de tous les noms de fichiers. Pour une aide au chiffrage, une référence produit erronée ou un tarif périmé peut être bloquant, même si le reste de la fiche est complet.

Le NIST recommande notamment de documenter la provenance, la qualité, les hypothèses, les limites et les données d’évaluation d’un système d’IA générative. Le projet doit donc pouvoir expliquer sur quelles données il s’appuie et comment leur fiabilité a été testée.

Une donnée disponible n’est pas nécessairement utile. Et une donnée imparfaite n’est pas automatiquement inutilisable : elle peut rester exploitable si son défaut est visible, borné et couvert par un contrôle.

1. Définir le résultat attendu

Formulez le processus en une phrase observable : « préparer une première réponse à une demande de devis », « retrouver la procédure applicable à un incident » ou « classer les demandes entrantes avant revue humaine ».

Précisez ce qui constitue une réponse acceptable, une erreur tolérable et une erreur bloquante. Sans ces critères, il est impossible de savoir si une anomalie mérite une correction immédiate.

2. Cartographier seulement les données nécessaires

Pour chaque étape, listez l’information consommée, sa source, son propriétaire, sa fréquence de mise à jour, les droits d’accès et la règle à appliquer si deux sources divergent.

Cette cartographie part du workflow, pas du système d’information entier. Un inventaire exhaustif de toutes les bases peut devenir un projet distinct sans améliorer le premier cas d’usage.

3. Constituer un échantillon représentatif

Prélevez des cas ordinaires, des exceptions, des dossiers incomplets et des cas ayant déjà provoqué des erreurs. Pour un processus à faible volume, utilisez tous les cas récents pertinents. Pour un volume élevé, choisissez un échantillon qui couvre les principales catégories et les situations rares à fort impact.

L’objectif n’est pas de produire un chiffre rassurant sur un lot facile, mais d’exposer le système à la variété réelle du travail.

4. Noter la qualité selon l’usage

Évaluez chaque source sur cinq dimensions :

• exactitude : l’information correspond-elle à la réalité métier ?

• complétude : les champs nécessaires sont-ils présents ?

• fraîcheur : l’information est-elle encore applicable ?

• cohérence : les formats, unités et règles concordent-ils ?

• traçabilité et droits : peut-on identifier l’origine, le propriétaire et les usages autorisés ?

Ajoutez une colonne « impact si faux ». Une anomalie rare mais critique doit passer avant un défaut fréquent sans effet sur la décision.

5. Établir un contrat de données minimal

Ce contrat opérationnel précise, pour chaque donnée utilisée, la source de référence, le format attendu, le responsable, la fréquence de mise à jour, le seuil d’acceptation et le comportement du système si la donnée manque ou paraît incohérente.

Il transforme un nettoyage ponctuel en responsabilité durable et évite que le pilote fonctionne le jour de la démonstration puis se dégrade lorsque les sources évoluent.

6. Lancer un pilote instrumenté

Le pilote doit enregistrer les sources consultées, les contrôles déclenchés, les corrections humaines et les cas refusés. Chaque défaut devient une décision : corriger la source, adapter l’intégration, ajouter un contrôle, limiter le périmètre ou accepter le risque documenté.

La décision de généraliser repose sur les résultats du test, pas sur une impression de démonstration.

Le coût dépend moins du volume brut que de la diversité des sources, du taux de défaut, de la sensibilité des données et de la disponibilité des responsables métier.

Chiffrez séparément cinq postes :

1. inventaire : identifier les sources, propriétaires et règles ;

1. remédiation : corrections, dédoublonnage, suppression ou enrichissement ;

1. intégration : extraction, transformation, contrôle des accès et synchronisation ;

1. validation métier : cas de test, revue des résultats et arbitrage des exceptions ;

1. maintenance : suivi de fraîcheur, alertes, réévaluation et traitement des dérives.

Pour chaque source, estimez le volume concerné, le taux de défaut observé sur l’échantillon, le temps de correction par type d’erreur, la part automatisable et le coût d’une erreur non détectée. Comparez ce coût au gain attendu sur le workflow. Cette méthode produit un budget défendable sans prétendre qu’un tarif universel existe.

Un distributeur veut aider ses commerciaux à préparer une première proposition à partir d’un courriel client. Ses données sont réparties entre un CRM, un catalogue produits, plusieurs grilles tarifaires et des fichiers historiques.

Il n’a pas besoin de normaliser tout l’historique du CRM avant le test. En revanche, il doit :

• désigner la grille tarifaire en vigueur ;

• identifier la source de référence pour les disponibilités ;

• exclure les anciens tarifs ;

• harmoniser les unités nécessaires au calcul ;

• contrôler les droits sur les documents clients ;

• prévoir une revue humaine avant envoi.

Les notes commerciales anciennes, les champs marketing inutilisés et les archives de produits retirés peuvent rester hors du pilote. Si les tests montrent qu’une donnée reportée provoque des erreurs fréquentes, elle rejoint le lot suivant de nettoyage.

Cet exemple illustre la logique : le périmètre de données suit le périmètre de décision.

Un pilote raisonnable demande au minimum un propriétaire du processus, un interlocuteur pour chaque source critique, une règle d’arbitrage, des cas de test incluant les exceptions, des règles de sécurité, un mode de supervision humaine et des critères d’arrêt et de généralisation.

Si personne ne peut confirmer ce qu’une donnée signifie ou quelle version fait foi, le problème n’est pas seulement technique. Il faut d’abord prendre une décision de gouvernance.

Pour sécuriser les premiers essais avec des informations sensibles, consultez Documents clients et IA : le protocole à valider avant le premier test. Pour comprendre pourquoi la qualité du contexte interne peut devenir un avantage durable, voir Le prochain avantage IA ne sera pas le modèle, mais le contexte de votre entreprise.

Cette approche par périmètre n’autorise pas à ignorer les obligations applicables. Lorsque des données personnelles sont traitées, la finalité, la minimisation, la sécurité et les droits des personnes doivent être examinés dès la conception. Pour les systèmes d’IA à haut risque qui utilisent des jeux de données d’entraînement, de validation ou de test, l’article 10 du règlement européen sur l’IA prévoit des exigences spécifiques de qualité et de gouvernance. Cette règle ne doit pas être étendue indistinctement à tous les projets, mais elle illustre le niveau d’exigence attendu lorsque le risque augmente.

Un autre danger consiste à nettoyer l’échantillon tout en laissant la source de production inchangée. Le pilote paraît alors fiable, mais ses performances se dégradent dès qu’il rencontre les données courantes. Le contrôle doit porter sur le flux réel et continuer après le lancement.

Enfin, une meilleure donnée ne compense pas un objectif flou, un processus inutile ou l’absence de responsabilité humaine. Le nettoyage n’est pas une fin : c’est une condition de la décision métier visée.

Choisissez un seul workflow, réunissez son propriétaire métier et le responsable de ses sources, puis appliquez la grille « avant le pilote / pendant le pilote / reporter » à un échantillon représentatif. Vous obtiendrez un premier périmètre de données, des critères d’acceptation et une base de chiffrage.

La position d’Atalas est simple : mieux vaut un projet étroit, traçable et mesuré qu’un grand programme de nettoyage sans décision cible.

Si vous voulez cadrer ce périmètre et construire un pilote relié à vos données réelles, découvrez le Studio IA d’Atalas.

Peut-on lancer un projet IA avec des données incomplètes ?

Oui, si les données manquantes sont identifiées, si leur effet est mesuré et si le système sait refuser ou demander une vérification. Une donnée manquante devient bloquante lorsqu’elle est indispensable à une décision sûre.

Faut-il créer un entrepôt de données avant tout projet IA ?

Pas nécessairement. Un premier cas d’usage peut s’appuyer sur un nombre limité de sources avec une intégration contrôlée. Un entrepôt devient pertinent si plusieurs usages exigent une consolidation durable, des règles communes et une traçabilité centralisée.

Qui doit être responsable de la qualité des données ?

Le métier définit le sens, la règle et le niveau de qualité attendu. L’IT ou la data peut automatiser les contrôles et l’intégration. La responsabilité ne devrait pas être abandonnée au seul prestataire IA.

Comment savoir si une donnée doit être exclue ?

Excluez-la si son origine ou ses droits sont incertains, si elle est trop ancienne pour l’usage, si elle contredit la source de référence sans règle d’arbitrage, ou si elle n’influence pas le résultat attendu.

Le nettoyage s’arrête-t-il après le pilote ?

Non. Les sources, formats et règles métier évoluent. Le projet doit surveiller la fraîcheur, les anomalies, les corrections humaines et les changements de provenance après la mise en production.