Vos données sont-elles prêtes pour l'IA ?

Quand une entreprise me contacte pour un projet IA, la première question porte presque toujours sur le modèle : GPT ou Claude, cloud ou open-source, agent ou simple assistant. C'est la deuxième bonne question. La première, celle qui décide si le projet tiendra debout, presque personne ne la pose : est-ce que vos données peuvent nourrir cette IA ? Le modèle, aujourd'hui, s'achète sur étagère et il est excellent. Vos données, non. Voici comment savoir si elles sont prêtes, avant de payer qui que ce soit pour coder.

Pourquoi un projet IA échoue-t-il en amont du modèle ?

Parce que le modèle est devenu la partie facile. Il y a quelques années, construire l'intelligence était le vrai défi ; aujourd'hui elle se loue à la minute. Ce qui reste difficile, c'est de lui donner une matière propre à traiter. Un projet IA échoue rarement parce que le modèle manquait de puissance : les modèles récents se trompent surtout quand on les nourrit mal. Il échoue parce que les données étaient incomplètes, dispersées dans dix outils qui ne se parlent pas, ou illisibles pour une machine. C'est l'étape 0 : celle qu'on saute parce qu'elle est moins excitante qu'une démo qui répond du premier coup, et c'est précisément là que se joue la réussite. Avant d'écrire une ligne de code, je regarde vos données. Pas pour les juger, pour savoir sur quoi on peut réellement bâtir, et à quel prix.

Que veut dire « données prêtes », concrètement ?

Prêtes ne veut pas dire parfaites. Aucune entreprise n'a des données parfaites, et attendre de tout ranger avant de commencer, c'est ne jamais commencer. Prêtes veut dire : assez fiables pour qu'une machine s'appuie dessus sans raconter n'importe quoi. Quatre questions suffisent à le vérifier, et vous pouvez déjà y répondre de tête pour votre premier cas d'usage.

• Sont-elles complètes, ou pleines de trous que le modèle comblera en inventant ?
• Sont-elles à jour, ou figées sur un état d'il y a trois ans ?
• Sont-elles rassemblées, ou éparpillées dans dix outils qui ne se parlent pas ?
• Sont-elles exploitables par une machine, ou noyées dans des PDF scannés et des captures d'écran ?

Aucun « non » n'est rédhibitoire, mais chacun a un coût. Le premier est le plus sournois : des données trouées ne bloquent pas le projet, elles le dégradent en silence, parce que le modèle comble les vides avec du plausible. C'est une des mécaniques qui le font halluciner. Le quatrième est le plus fréquent, et le plus sous-estimé : l'information existe, mais dans un format que rien ne peut lire automatiquement.

Pourquoi le format compte-t-il autant que le contenu ?

Parce qu'une donnée juste mais illisible pour une machine ne sert à rien tant qu'on ne l'a pas rendue lisible. Vos contrats, vos factures, vos comptes rendus existent, mais souvent sous forme de PDF scannés, de tableurs bricolés ou de fils d'e-mails. L'information est là, prisonnière d'un format que le modèle ne peut pas exploiter tel quel. La bonne nouvelle : cette barrière est en train de tomber. Les modèles de vision lisent aujourd'hui un document mal numérisé mieux que l'OCR d'hier, et extraire vos factures et vos contrats en données propres coûte désormais une fraction de ce que ça coûtait. La mauvaise nouvelle : presque personne ne mesure l'ampleur du chantier avant de s'y lancer, et c'est là qu'on se trompe de budget.

Comment savoir ce qui est vraiment exploitable aujourd'hui ?

En regardant, pas en supposant. C'est tout le travail d'un audit de vos données : je passe vos sources en revue, je teste ce qu'une machine peut réellement en tirer, et je trie. À la sortie, vous avez trois piles nettes plutôt qu'une intuition floue.

• Ce qui est exploitable tout de suite : on démarre le premier cas d'usage dessus, sans attendre.
• Ce qui le devient avec un nettoyage léger : quelques jours de travail ciblé, pas un chantier de six mois.
• Ce qu'il vaut mieux laisser de côté pour l'instant : trop coûteux à remettre en état pour ce que ça rapporterait.

Ce tri n'a rien d'académique. Il fixe le périmètre du premier projet, son budget réel, et l'ordre dans lequel on avance. Vous cessez de deviner, vous décidez sur des faits.

Que gagne-t-on à le mesurer avant de coder ?

Tout. Le mesurer avant de coder, c'est transformer trois incertitudes en décisions.

• On écarte d'emblée les cas voués à l'échec, au lieu de le découvrir après trois mois de développement.
• On chiffre le vrai coût du projet, données comprises, sans mauvaise surprise à mi-parcours.
• On commence par le nettoyage minimal utile, pas par une refonte totale du système d'information.

C'est aussi ce qui évite le piège le plus courant : un POC brillant qui ne passe jamais en production parce qu'il tournait sur des données de démonstration, triées à la main, que la réalité ne fournira jamais. Vous investissez sur ce qui est prêt, pas sur un rêve qui s'effondre à la première vraie donnée.

Faut-il tout ranger avant de commencer ?

Non, et c'est le contresens le plus coûteux. Vous n'avez pas besoin d'un grand chantier data, d'un entrepôt de données flambant neuf ni d'une gouvernance parfaite avant de lancer votre premier cas d'usage. Vous avez besoin de savoir ce qui est exploitable dès aujourd'hui, et par quoi commencer. On vise le nettoyage minimal utile pour ce premier cas, on livre quelque chose qui marche, et on élargit ensuite avec les données que ce premier succès justifie de préparer. L'inverse, tout ranger d'abord, coûte cher, prend des mois, et démoralise tout le monde avant le moindre résultat. La donnée se prépare au rythme des usages qu'elle sert, pas l'inverse.

On ne bâtit pas l'IA sur des données pas prêtes. On bâtirait sur du sable.

Au fond, la question n'est pas « mes données sont-elles parfaites » mais « qu'est-ce que je peux en faire dès maintenant ». Un audit y répond en quelques jours : ce qui est exploitable tout de suite, ce qu'il faut nettoyer d'abord, et le chemin le plus court vers un premier résultat, avant que vous n'engagiez le moindre euro à coder. Si vous voulez savoir par où commencer avec vos données, parlons-en : un premier échange suffit souvent à y voir clair, sans engagement.