Une donnée est prête pour un projet IA quand elle est assez complète, cohérente, profonde et légitime pour que le modèle apprenne ou réponde juste. On le vérifie avec douze contrôles, mesurables en une heure sur un échantillon, chacun assorti d'un seuil d'arrêt. Sous le seuil, on répare d'abord, on lance ensuite.
Pourquoi mesurer avant de décider quoi que ce soit ?
Le scénario est classique, et nous le composons ici pour l'exemple. Un distributeur de matériel électrique d'une centaine de salariés veut un assistant qui répond aux commerciaux sur les prix et les disponibilités. Le prototype impressionne en démonstration. Trois semaines après, les commerciaux n'y croient plus, parce que le même client apparaît sous quatre écritures et que les tarifs de 2021 se mélangent à ceux de 2024.
Le modèle n'est pas en cause. Il a fait ce qu'on lui demandait avec ce qu'on lui donnait. C'est précisément ce qu'un audit IA de votre entreprise cherche à établir avant la première ligne de code : ce que valent vos données, champ par champ, pour le cas d'usage visé et pas dans l'absolu.
La méthode est volontairement frugale. On prélève un échantillon représentatif (quelques milliers de lignes, ou une centaine de documents), on le passe au crible avec des requêtes simples ou un tableur, et on compare à un seuil fixé avant de regarder le résultat. Fixer le seuil à l'avance évite de le négocier avec soi-même une fois les chiffres sous les yeux.
Un mot sur ces seuils, pour être honnête : ce sont nos seuils de travail, pas une norme. Il existe bien une norme internationale de qualité des données, l'ISO/IEC 25012 publiée en 2008, qui définit quinze caractéristiques réparties entre ce qui tient aux données elles-mêmes (complétude, cohérence, exactitude) et ce qui tient au système qui les héberge (disponibilité, accessibilité). Elle dit quoi mesurer, pas où placer la barre. Les seuils ci-dessous sont des points de départ à ajuster au coût d'une erreur dans votre cas d'usage : une relance d'impayé erronée ne pèse pas comme une erreur de dosage.
Pour la démarche complète côté données, notre guide sur l'audit de données détaille le cadrage ; ici, on reste sur la grille de contrôle.
Doublons, champs vides, valeurs bouche-trou : combien de fiches sont réellement exploitables ?
Trois premiers contrôles, les plus rapides et les plus parlants.
1. Les doublons. On regroupe les enregistrements sur un identifiant métier (SIRET, courriel, référence article) puis, à défaut, sur un rapprochement approximatif du nom et de l'adresse. Une heure suffit sur un échantillon. Seuil : au-delà de 5 % de doublons probables sur les entités clés, on ne démarre pas, car un modèle qui apprend sur des fiches dupliquées surpondère les clients les plus mal saisis.
2. Les champs vides. On ne mesure pas le taux de remplissage de toute la table, mais celui des champs dont dépend le cas d'usage. Pour une relance automatique d'impayés, la date d'échéance et le contact comptable comptent ; la ligne « commentaire » ne compte pas. Seuil : 90 % de remplissage sur chaque champ critique.
3. Les valeurs bouche-trou. Le champ est rempli, mais avec « N/A », « 0 », « test », « 01/01/1900 » ou un point. Techniquement, il passe le contrôle précédent ; sémantiquement, il est vide. On liste les dix valeurs les plus fréquentes de chaque champ critique, et l'œil repère vite l'intrus. Seuil : plus de 10 % de valeurs bouche-trou dans un champ critique, c'est un arrêt.
Ces trois contrôles se font avec la personne qui saisit les données au quotidien, pas seulement avec la DSI. Elle sait que « 999 » signifie « prix à confirmer » depuis une migration dont plus personne ne se souvient.
Formats, référentiels, unités : vos données disent-elles la même chose partout ?
4. Les formats. Dates en jour/mois/année dans un système et en mois/jour/année dans un autre, montants avec virgule ou point, numéros de téléphone avec ou sans indicatif. On compte la part de valeurs qui respectent un format unique après un nettoyage automatique simple. Seuil : 95 % de conformité ; en dessous, la règle de conversion n'est pas assez sûre pour être automatisée.
5. Les référentiels. « Dupont SARL », « DUPONT » et « Éts Dupont » désignent la même société. Pour mesurer, on prend les cent clients ou produits les plus fréquents et on compte combien de graphies existent pour chacun. Seuil : un rapprochement automatique correct sur au moins 90 % des entités ; sinon, on construit d'abord un référentiel maître, c'est un chantier à part entière.
6. Les unités et l'encodage. Prix hors taxes mélangés à des prix toutes taxes comprises, kilos et tonnes dans la même colonne, accents transformés en caractères illisibles après un export. C'est le contrôle qui produit les erreurs les plus silencieuses, parce qu'aucun champ n'est vide. Seuil : aucun mélange non documenté dans un champ numérique critique. Un seul suffit à bloquer, car il fausse tous les calculs en aval.
Ces défauts ne sont pas des fautes de personne. Ils viennent d'années de fusions, de logiciels successifs et de fichiers Excel qui ont servi de passerelle. Il n'est pas rare qu'une entreprise de taille moyenne cumule trois outils successifs et autant de conventions de nommage pour les mêmes clients.
Les historiques sont-ils assez longs et assez fiables pour apprendre du passé ?
Ce bloc concerne surtout les projets de prévision, de détection d'anomalies ou de recommandation. Un assistant documentaire s'en soucie moins, mais il a ses propres équivalents (versions de documents, dates de validité).
7. La profondeur. Combien de temps remonte l'historique exploitable ? Pour prévoir une demande saisonnière, il faut couvrir au moins deux cycles complets, soit 24 mois minimum, faute de quoi le modèle prendra une saison pour une tendance. Seuil : 24 mois pour la prévision saisonnière, à adapter selon le rythme du métier.
8. Les trous. On trace le volume par semaine ou par mois et on cherche les creux. Une panne de collecte, une migration de logiciel ou un export oublié laissent des périodes vides que personne n'a signalées. Seuil : moins de 5 % de périodes manquantes, et aucun trou de plus d'un mois dans une série censée être continue.
9. Les changements de définition. Le « chiffre d'affaires » a-t-il toujours été calculé de la même façon ? Un « client actif » veut-il dire la même chose avant et après la réorganisation commerciale ? On interroge le responsable de la donnée et on cherche les ruptures dans les courbes. Seuil : chaque rupture est identifiée et datée ; si elle ne peut pas l'être, on coupe l'historique à la dernière date fiable, quitte à perdre de la profondeur.
C'est souvent ici que l'on réalise qu'un projet prédictif attendra. L'article sur la transformation de données historiques en modèle prédictif montre ce qu'on peut faire quand la profondeur est au rendez-vous.
A-t-on le droit, et surtout la possibilité technique, d'utiliser ces données ?
10. L'accès. Peut-on lire les données par une API, une base ou un export automatisé, avec un compte technique dédié ? Si la seule voie est un export manuel que quelqu'un déclenche le lundi matin, le projet dépendra de cette personne. Seuil : l'accès technique en lecture est obtenu et testé avant le lancement, pas promis pour plus tard.
11. Les données personnelles. Le projet traitera-t-il des noms, des courriels, des données de santé ou de salariés ? Pour chaque catégorie, on vérifie la base légale, la durée de conservation et l'information des personnes. Seuil : zéro champ sensible sans base documentée. Un oubli ici ne se rattrape pas par du code, il se traite par la conformité et, selon le cas, par la désignation d'un délégué à la protection des données.
12. Le propriétaire. Chaque jeu de données critique a-t-il une personne nommée qui répond de sa qualité et qui tranche en cas de conflit entre deux systèmes ? Seuil : un nom par jeu critique. Sans propriétaire, personne ne corrige les erreurs que le projet fera remonter, et la qualité se dégrade en quelques mois.
Sur ce dernier point, la question rejoint vite celle de la gestion courante des données par des agents. Nous l'abordons dans l'article sur la gestion des données par les agents IA.
Comment lire les résultats et décider de lancer, de réparer ou de réduire ?
Les douze contrôles produisent un tableau à trois couleurs. Voici la grille que l'on remet à la direction à l'issue de l'heure de mesure par contrôle.
| Contrôle | Mesure sur échantillon | Seuil d'arrêt |
|---|---|---|
| Doublons | Part de fiches en double sur l'identifiant métier | Plus de 5 % |
| Champs vides | Remplissage des champs critiques | Moins de 90 % |
| Valeurs bouche-trou | Dix valeurs les plus fréquentes par champ | Plus de 10 % |
| Formats | Conformité après nettoyage automatique | Moins de 95 % |
| Référentiels | Rapprochement des 100 entités les plus fréquentes | Moins de 90 % |
| Unités et encodage | Mélanges dans les champs numériques | Un seul mélange non documenté |
| Profondeur | Mois d'historique exploitable | Moins de 24 mois (prévision) |
| Trous | Périodes manquantes | Plus de 5 %, ou trou supérieur à un mois |
| Définitions | Ruptures datées | Rupture non datée |
| Accès | Lecture automatisée testée | Accès non obtenu |
| Données personnelles | Base légale par catégorie | Champ sensible sans base |
| Propriétaire | Responsable nommé | Aucun nom |
Trois issues sont possibles. Si tout passe, on lance. Si un ou deux contrôles échouent sur des champs qui ne sont pas au cœur du cas d'usage, on lance en réduisant le périmètre. Si un contrôle échoue sur un champ critique, on répare d'abord : c'est souvent un chantier de quelques semaines, qui a l'avantage d'améliorer aussi le reporting et les processus existants, indépendamment de l'IA.
Ce qu'on évite à tout prix, c'est le démarrage « en espérant que le modèle compensera ». Il ne compense pas, il amplifie. Et le coût du défaut grimpe à mesure qu'on avance : peu cher à corriger avant le projet, douloureux en recette, ruineux une fois que les utilisateurs ont perdu confiance. Pour juger si l'effort de remise à niveau se justifie, il faut le rapprocher du gain attendu, ce que détaille l'article sur la mesure du retour sur investissement des projets IA.
Enfin, la checklist se rejoue. Une fois le projet en production, les mêmes contrôles, lancés chaque trimestre sur un échantillon, détectent la dérive avant que les utilisateurs ne la remarquent. C'est l'une des raisons pour lesquelles nous parlons de maintenance supervisée plutôt que de simple livraison : la qualité des données est un état à entretenir, pas une case à cocher.
