Vos données sont-elles prêtes pour l'IA ? La question avant toutes les autres

Quand on me demande d’évaluer la faisabilité d’un projet d’IA, je ne regarde pas d’abord le cas d’usage. Je regarde les données. C’est là que se joue la faisabilité réelle, et c’est l’étape qu’on saute le plus souvent parce qu’elle est ingrate.

Voici les quatre contrôles que je fais passer, dans l’ordre où ils éliminent le plus vite les projets qui ne tiendront pas.

1. La donnée est-elle atteignable par un programme ?

Première question, et premier couperet.

Une information affichée dans un logiciel n’est pas nécessairement accessible. Elle peut vivre dans une base à laquelle personne n’a accès en lecture, dans un progiciel sans interface programmable, dans un fichier régénéré chaque nuit, ou dans un PDF produit par un tiers.

La différence est décisive : dans le premier cas, on branche ; dans les autres, il y a un chantier — parfois plus gros que le projet d’IA lui-même.

Le test que je fais passer est concret : récupérer dix enregistrements réels, par un moyen reproductible, en moins d’une journée. Si ce n’est pas possible, le projet n’est pas un projet d’IA — c’est un projet d’accès aux données, et il faut le nommer comme tel avant de chiffrer.

2. La donnée est-elle fraîche, et le sait-on ?

Une donnée d’hier n’a pas la même valeur selon l’usage. Pour analyser une tendance, la fraîcheur importe peu. Pour répondre à un client sur l’état de son dossier, une information de la veille est une erreur.

Ce que je vérifie :

• la latence réelle entre l’événement et sa disponibilité — pas celle annoncée, celle mesurée sur quelques cas ;
• la présence d’une date de mise à jour exploitable. Sans elle, impossible de dire à l’utilisateur « au 12 août à 9 h », et donc impossible de le protéger d’une décision prise sur une donnée périmée.

Ce second point est souvent traité comme un détail d’affichage. C’en est un jusqu’au jour où quelqu’un agit sur une information obsolète, et il devient alors le sujet principal.

3. Sait-on ce que chaque champ signifie ?

C’est le contrôle qui fait dérailler le plus de projets, et le plus difficile à faire admettre.

Dans presque toutes les bases que j’ouvre, je trouve des champs dont plus personne ne connaît la règle : un statut à onze valeurs dont trois ne sont plus utilisées mais restent en base, un champ « date » qui contient parfois la date de création et parfois celle de dernière modification, un booléen dont le sens a été inversé lors d’une migration.

Ces ambiguïtés sont sans gravité tant qu’un humain manipule la donnée : il sait, ou il demande. Elles deviennent graves dès qu’on automatise, parce que la machine applique la règle qu’on lui a donnée, y compris quand elle est fausse.

Et elles deviennent invisibles quand on ajoute un modèle de langage : il produira une phrase fluide et plausible à partir d’une donnée mal interprétée. Sans IA, une donnée douteuse produit un tableau bizarre que quelqu’un remarque. Avec, elle produit une réponse crédible que personne ne conteste. C’est le point que je répète le plus.

Le contrôle : prendre les dix champs qui alimenteront la fonctionnalité, et faire écrire leur définition par la personne qui les utilise au quotidien. Si deux personnes donnent deux définitions différentes, il y a un arbitrage métier à faire avant toute ligne de code.

Photo : domaine public (CC0).

4. A-t-on le droit d’utiliser cette donnée pour cet usage ?

Dernier contrôle, et il ne s’agit pas d’une formalité de fin de projet.

Une donnée collectée pour une finalité ne peut pas systématiquement servir à une autre. Un historique de conversations collecté pour la traçabilité n’est pas nécessairement utilisable pour évaluer un modèle. Une base de clients constituée pour la facturation n’autorise pas n’importe quel traitement.

Trois questions suffisent à savoir si le sujet a été regardé :

• pour quelle finalité ces données ont-elles été collectées, et l’usage envisagé en fait-il partie ?
• sortent-elles de l’entreprise, et pour aller où ?
• combien de temps sont-elles conservées, et par quel mécanisme sont-elles supprimées ?

Quand la réponse à la deuxième est « chez un fournisseur d’IA », il faut regarder ce que dit son contrat, et savoir que cela change. C’est une vérification à refaire, pas un dossier à classer.

Photo : Wilfred Iven — licence CC0.

L’ordre des contrôles n’est pas négociable

Un mot sur la séquence, parce qu’on est souvent tenté de la prendre à l’envers.

La tentation naturelle est de commencer par le point 4 — le cadre juridique — parce qu’il est le plus impressionnant, ou par le point 3 — le sens des champs — parce qu’il est le plus intéressant. C’est une perte de temps : il est inutile de statuer sur la finalité d’une donnée qu’on ne peut techniquement pas récupérer.

Je passe donc toujours dans l’ordre 1, 2, 3, 4, et je m’arrête au premier blocage. Sur les projets que j’évalue, un sur trois s’arrête au point 1 — et l’entretien dure une heure au lieu d’une semaine.

5. Y a-t-il assez d’exemples, et sont-ils représentatifs ?

Le contrôle qui décide de la faisabilité, et qui arrive toujours après les autres.

La question n’est pas « combien de données avons-nous » mais « combien de cas de chaque type ». Un jeu de dix mille documents dont neuf mille huit cents sont des factures standard ne permet pas de traiter correctement les deux cents autres — et ce sont précisément elles qui coûtent du temps aux équipes.

Ce que je regarde : la distribution des cas, pas le volume total. Combien de variantes de mise en page, combien d’émetteurs différents, combien de cas manuels par mois. Si la catégorie qui pose problème compte trente exemples, il faut le savoir avant de promettre un taux de réussite.

Et un point qui surprend souvent : les cas résolus manuellement ne sont presque jamais tracés. Personne n’a noté pourquoi ce dossier a été rejeté ni ce qui a été corrigé. C’est l’information la plus précieuse, et elle n’existe pas — la produire est parfois le premier chantier.

Le contrôle qui coûte le moins et rapporte le plus

Avant tout projet, j’extrais cent lignes au hasard et je les lis à l’écran, une par une, avec quelqu’un du métier.

Cet exercice prend une demi-journée et il remplace des semaines de discussion. On y découvre systématiquement trois choses : un champ dont l’usage a changé en cours de route, une convention officieuse que personne n’avait mentionnée, et une proportion de valeurs vides bien supérieure à ce qui était annoncé.

Aucun tableau de bord de qualité ne remplace cette lecture. C’est en regardant les données réelles qu’on découvre l’écart entre ce que le système est censé contenir et ce qu’il contient.

Le cas des données éparpillées entre plusieurs systèmes

C’est la configuration la plus fréquente, et celle qui fait déraper les plannings.

L’information nécessaire existe, mais répartie : une partie dans l’outil métier, une partie dans un tableur tenu par une personne, une partie dans les pièces jointes des courriels. Chacune est exploitable ; c’est leur réconciliation qui coûte.

Trois questions à trancher avant de s’engager. Existe-t-il un identifiant commun ? Sans lui, le rapprochement se fait sur des noms, avec un taux d’erreur qu’il faut mesurer et non supposer. Qui fait foi en cas de désaccord ? C’est une décision métier, et elle doit être écrite. À quelle fréquence chaque source est-elle mise à jour ? Croiser une donnée quotidienne avec une donnée trimestrielle produit des incohérences que personne ne saura expliquer.

Ma position : tant que ces trois réponses n’existent pas, le projet n’est pas prêt à démarrer — et ce n’est pas un sujet d’intelligence artificielle, c’est un sujet de gouvernance.

Ce que je réponds quand tout n’est pas prêt

Rarement « non ». Presque toujours « pas dans cet ordre ».

La plupart des projets que je vois bloqués ne le sont pas par le modèle mais par les points 1 et 3. Ce sont des chantiers connus, chiffrables, qui produisent de la valeur même si le projet d’IA est ensuite abandonné : un accès programmatique propre et un dictionnaire de données servent à tout le reste du système d’information.

C’est d’ailleurs l’argument qui débloque le plus souvent la discussion budgétaire. Ce travail n’est pas un préalable qu’on subit avant le vrai projet — c’est un investissement qui survit au projet, quelle que soit la technologie qui le remplacera dans trois ans.