La thèse en une phrase : le modèle est la partie facile. Ce qui décide si ton projet d’IA atteint la production ou reste bloqué en démo, ce n’est pas quel modèle tu choisis, c’est l’état de tes données le jour où tu les branches. La donnée en vrac —éparpillée, à moitié remplie, sans propriétaire— est le vrai frein, et c’est aussi la partie dont personne ne parle en rendez-vous de vente parce qu’elle ne fait pas joli en démo. Cet article parle de ça, avec sources et sans fumée.
La qualité des données pour l’IA en entreprise, c’est 80% du travail (et presque personne ne te le dit)
Ce n’est pas l’avis d’un commercial : c’est ce que répètent les gens qui construisent vraiment de l’IA. Andrew Ng, un des noms qui ont fondé le machine learning appliqué, l’a dit sans détour : «si 80% de notre travail est la préparation des données, alors garantir la qualité de la donnée est la tâche la plus critique d’une équipe de machine learning». Et ce n’est pas un cas isolé : selon l’Institute for Business Value d’IBM, les data scientists consacrent entre 60% et 80% du temps d’un projet à préparer la donnée —l’acquérir, la nettoyer, l’étiqueter, la ranger— et non à choisir ou entraîner le modèle. Le modèle prend le titre ; la donnée prend les heures.
La conséquence pratique est gênante : quand un projet d’IA échoue, ce n’est presque jamais parce que le modèle était faible. C’est parce que la donnée que tu lui as donnée arrivait à moitié remplie, se contredisait entre systèmes ou que personne ne savait même où elle vivait. L’algorithme a fait son boulot avec de la camelote, et a rendu de la camelote avec beaucoup d’assurance.
Ce que «données en vrac» veut dire en pratique
Ce n’est pas un problème abstrait de «gouvernance». C’est une liste de choses concrètes que presque toute entreprise reconnaît dès qu’elle les lit :
- Tu ne sais pas quelles données tu as. Elles sont réparties entre le CRM, trois tableurs, la boîte mail de quelqu’un et un dossier partagé que personne n’a nettoyé depuis 2021.
- Les mêmes données se contredisent. Le client figure sous un nom en facturation, un autre dans le CRM et un troisième dans l’outil de support. Pour une personne c’est «évidemment le même» ; pour un modèle ce sont trois entités distinctes.
- Elles arrivent à moitié remplies. Champs vides, catégories non renseignées, dates en cinq formats. Toute automatisation que tu montes dessus hérite de ces trous.
- Personne ne les touche avec discernement. Pas de propriétaire de la donnée : celui qui la saisit la saisit comme il peut, et personne ne décide quelle est la source de vérité quand deux systèmes divergent.
Chacun de ces points est une fissure par laquelle un projet d’IA tombe. Et aucun ne se règle avec un meilleur modèle : ils se règlent en rangeant la donnée avant de rien demander à la machine.
Pourquoi le modèle est la partie facile
Les bons modèles sont aujourd’hui une commodité : les meilleurs sont à un appel d’API et s’améliorent tout seuls tous les quelques mois sans que tu fasses rien. Ce qui est rare —et ce qui sépare vraiment un projet qui marche d’un projet qui ne marche pas— c’est d’avoir la donnée propre, cartographiée et avec un propriétaire pour les alimenter. C’est pour ça que le vrai travail d’un projet d’IA ressemble plus à de la plomberie qu’à de la science : savoir d’où sort chaque donnée, comment elle se connecte, où elle se salit et qui la répare.
Ça a une lecture optimiste. Si le goulot d’étranglement était le modèle, tu serais à la merci d’un fournisseur. Comme le goulot, c’est ta donnée, le remède est dans ton camp —et il s’accumule— : chaque fois que tu ranges une source, tous les projets qui suivent sortent moins chers et plus fiables. La donnée rangée est de l’infrastructure, et l’infrastructure se paie une fois et rapporte plusieurs.
Quoi faire avant de choisir un modèle
Le bon ordre inverse ce que presque tout le monde fait. La donnée d’abord, le modèle ensuite. Concrètement, avant d’allumer quoi que ce soit :
| Étape | Ce que ça règle |
|---|---|
| Cartographier quelles données tu as et où elles vivent | Fini les «données quelque part» : tu sais ce qu’il y a, dans quel système et dans quel état |
| Décider la source de vérité | Quand deux systèmes divergent, il y a une règle, pas une dispute |
| Nettoyer et unifier les entités | Le même client est un client, pas trois ; l’IA arrête de mal compter |
| Donner à la donnée un propriétaire et un processus | La donnée arrive propre à la source et ne se resalit pas le mois suivant |
Ce travail est la partie ennuyeuse —la gouvernance de la donnée— et c’est justement celle qui décide du résultat. Si tu veux le monter bien, on le traite pour ce que c’est, de l’infrastructure, dans le service de gouvernance de la donnée : savoir quelles données tu as, où elles vivent et qui les touche, et on le laisse prêt pour que de la vraie IA tourne dessus avec l’infrastructure d’IA pour l’entreprise. Ce n’est qu’une fois la donnée en ordre qu’il a du sens d’automatiser l’entreprise avec l’IA ou d’entraîner un agent dessus : fais-le avant, et tu automatises le désordre.
Si tu regardes un projet d’IA et que personne ne t’a encore demandé l’état de tes données, c’est le signal d’alarme. Range la donnée d’abord —ou fais-la ranger— puis choisis le modèle. L’IA ne se présente pas en démo sur des données bidon. Elle s’implémente sur la donnée réelle, et c’est le 80% dont personne ne te parle.