18 juin 2026
IA et data : pourquoi la qualité des données fait tout
Pourquoi la plupart des projets IA bloquent moins sur le modèle que sur la qualité des données : sources incomplètes, schémas incohérents, contexte absent, exports obsolètes, et checklist avant de lancer un système IA en production.
Le modèle est rarement le premier vrai problème
Dans beaucoup de discussions sur l'IA, on parle encore comme si le choix du modèle décidait de tout. C'est rarement ce que j'observe sur le terrain. Le projet IA échoue plus souvent parce que les données sont floues, mal nommées, exportées à la main, sans propriétaire clair, ou trop pauvres pour porter une décision fiable. Le modèle peut être excellent ; s'il reçoit une base documentaire contradictoire, des champs incomplets et un historique sans contexte, il produira surtout une version plus rapide du désordre existant.
C'est une réalité que l'on retrouve dans des contextes très différents : médias, enseignement supérieur, culture, opérations internes. Les équipes ont souvent beaucoup de matière, mais pas toujours des données structurées. Elles ont des fichiers, des CMS, des tableurs, des notes, des tickets, des exports CRM ou ERP. Ce n'est pas encore un socle exploitable. Pour une IA en production, la qualité des données n'est pas un sujet technique secondaire. C'est le cœur du système.
Les formes les plus coûteuses de mauvaise donnée
La mauvaise donnée n'est pas seulement une donnée fausse. Elle peut être non labellisée, donc impossible à utiliser pour évaluer correctement un système. Elle peut avoir un schéma incohérent, avec trois noms différents pour la même notion métier. Elle peut être exacte mais privée de contexte : une date sans fuseau horaire, un statut sans définition, un commentaire client sans lien vers le contrat. Elle peut aussi être périmée, parce que le pipeline dépend encore d'un export mensuel que personne ne vérifie vraiment.
Les données manquantes sont particulièrement dangereuses, car elles donnent une illusion de couverture. On croit disposer de tout le corpus, puis on découvre que les cas complexes, les exceptions commerciales ou les contenus les plus récents n'ont jamais été intégrés. Dans un copilote interne, cela crée des réponses incomplètes. Dans un workflow de classification, cela biaise les catégories. Dans un agent connecté à des outils métier, cela peut provoquer une action techniquement valide mais opérationnellement mauvaise.
Ce que veut dire good enough pour un système IA
La bonne nouvelle est qu'un projet n'a pas besoin de données parfaites pour démarrer. Il a besoin de données suffisamment bonnes pour le risque visé. Pour un assistant de recherche interne, good enough signifie souvent : sources identifiées, documents récents, métadonnées minimales, droits d'accès cohérents, et capacité à remonter la source. Pour une automatisation qui modifie des données métier, la barre est plus haute : schémas stables, règles d'arbitrage explicites, logs, validation humaine sur les cas limites, et rollback possible.
Cette nuance est importante. La qualité des données n'est pas une quête abstraite de pureté. C'est une décision produit et business. On accepte plus facilement un champ incomplet si le système propose une suggestion réversible. On l'accepte beaucoup moins si le système déclenche une action client, une écriture en base ou une décision de conformité. Le bon niveau de nettoyage dépend donc du coût de l'erreur, du volume traité et de la place de l'humain dans la boucle.
La gouvernance n'est pas de la bureaucratie, c'est de l'ingénierie
Quand je parle de gouvernance avec des clients, je ne parle pas de créer un comité de plus. Je parle de savoir qui possède chaque source, qui peut la modifier, à quelle fréquence elle est rafraîchie, quelles règles métier elle encode, et comment le système réagit quand deux sources se contredisent. Sans cette gouvernance légère, un pipeline IA devient vite fragile : une colonne change de nom, un export s'arrête, une équipe ajoute une catégorie, et le système commence à dériver sans bruit.
Le meilleur travail se fait souvent avant la première intégration modèle. Cartographier les sources, documenter les champs critiques, éliminer les doublons, choisir les identifiants stables, définir les droits d'accès, puis brancher seulement ensuite le modèle. Ce n'est pas moins ambitieux que de faire une démo rapide. C'est simplement plus sérieux. Une IA utile repose sur une chaîne de confiance : source, transformation, contexte, modèle, évaluation, supervision.
Checklist avant de lancer un projet IA
Avant de démarrer, je pose toujours quelques questions simples. Quelle décision ou quelle tâche le système doit-il améliorer ? Quelles sources sont nécessaires et lesquelles sont réellement fiables ? Les données structurées existent-elles déjà ou faut-il les créer ? Où sont les données manquantes ? Qui valide les labels ? Quel est le rythme de mise à jour ? Quels champs ne doivent jamais être exposés au modèle ? Comment saura-t-on qu'une réponse ou une action est incorrecte ?
Si l'équipe n'a pas de réponse, ce n'est pas une raison pour abandonner. C'est le vrai début du projet IA. Commencer par le nettoyage, le pipeline et la gouvernance évite de confondre prototype impressionnant et système durable. Le modèle reste important, bien sûr. Mais en production, il ne sauvera pas une donnée mal comprise. La différence entre une IA gadget et une IA utile se joue souvent là : dans la qualité du contexte que l'entreprise accepte enfin de rendre exploitable.