Données métier et IA : 93 % des entreprises ne sont pas prêtes

Le vrai blocage : ce qu'on donne à l'IA à traiter

La plupart des projets IA calent avant même d'avoir produit quoi que ce soit d'utile. On attribue l'échec au modèle, à l'intégration, aux résistances humaines. Rarement à la donnée — pourtant c'est là que se joue la majorité des blocages.

Gartner prédit que 60 % des projets IA sans données AI-ready seront abandonnés d'ici fin 2026 (SR Analytics / Gartner). Pas abandonnés parce que le modèle n'était pas assez puissant. Parce que les données d'entrée ne permettaient pas de produire un résultat fiable.

Le problème est structurel. Les systèmes de production accumulent depuis des années des données inconsistantes, mal étiquetées, silotées dans des outils qui ne se parlent pas. Un ERP qui n'exporte pas au même format que le CRM. Des documents PDF non structurés. Des libellés libres dans des champs censés être normalisés. L'IA, elle, ne fait pas la distinction entre une bonne donnée et une mauvaise. Elle traite ce qu'on lui donne.

43 % des directeurs des données citent la qualité et la préparation des données comme premier obstacle à l'adoption de l'IA dans leur organisation (Informatica CDO Insights 2025). Devant le budget, devant les compétences, devant la gouvernance. La donnée, en premier.

65 % des organisations déclarent avoir du mal à briser leurs silos de données pour alimenter leurs projets IA. 62 % peinent à mesurer et surveiller la qualité des données en continu. Et seulement 23 % disposent d'une stratégie données établie pour l'IA — les autres sont en train de la construire au fil des projets, ce qui revient à poser les fondations après avoir monté les murs.

Le résultat financier de cette situation est documenté : les entreprises perdent en moyenne 25 % de leur chiffre d'affaires annuel à cause d'inefficacités et de mauvaises décisions liées à la mauvaise qualité des données (Integrate.io, Data Transformation Challenge Statistics 2026). Ce n'est pas un coût caché — c'est une hémorragie silencieuse sur chaque ligne de P&L.

Ce que font les organisations qui avancent

Les entreprises qui déploient avec succès des projets IA en production ont un point commun : elles traitent la donnée comme un prérequis, pas comme un chantier parallèle. Elles ne commencent pas à nettoyer les données quand le pilote plante. Elles auditent avant de commencer.

Elles cartographient les flux avant de choisir un cas d'usage. Avant de décider quel processus automatiser, elles tracent le chemin complet de la donnée : où elle naît, dans quel système elle transite, sous quel format elle arrive à l'étape suivante. Ce travail révèle souvent des ruptures invisibles au quotidien — un champ texte libre là où on attendait une liste normalisée, une table non mise à jour depuis 18 mois, un export CSV avec trois encodages différents selon l'opérateur qui l'a produit.

Elles séparent les rôles autour de la donnée. Le cas American Airlines est instructif : l'équipe a formalisé trois rôles distincts — les data owners qui définissent les standards de qualité, les data custodians qui maintiennent les pipelines sans les dégrader, et les data consumers qui appliquent des validations à chaque usage. Sans cette séparation, chaque équipe optimise pour ses propres besoins et la qualité globale dérive.

Elles mesurent la qualité en continu, pas lors d'audits annuels. La différence entre une donnée exploitable en reporting et une donnée exploitable par un modèle IA est une question de cadence. Un rapport mensuel tolère des anomalies corrigées après coup. Un agent IA qui traite des tickets en temps réel a besoin de signaux de qualité mesurés en heures. Les organisations qui réussissent ont mis en place des pipelines avec validation automatique à chaque étape — pas une vérification manuelle en bout de chaîne.

GE l'a fait à grande échelle sur sa plateforme Predix : des outils de nettoyage et validation automatisés sur les données industrielles, avec monitoring en continu. Résultat : les modèles d'analyse tournent sur des données cohérentes, les interventions manuelles sont rares, et la fiabilité des insights est maintenable dans le temps — pas seulement lors du lancement.

Comment s'y prendre concrètement

La préparation des données n'est pas un projet en soi. C'est une phase de chaque projet IA. Voici comment la structurer sans en faire un chantier ouvert.

Commencer par un inventaire ciblé sur le cas d'usage. On n'audite pas tout le patrimoine données de l'entreprise. On identifie les sources qui alimenteront le cas d'usage retenu, et on les évalue sur trois critères : exhaustivité (est-ce que la donnée couvre bien la période et le périmètre attendus ?), cohérence (les mêmes entités sont-elles représentées de la même façon partout ?), et fraîcheur (quelle est la latence entre un événement réel et son enregistrement dans le système ?). Cet inventaire prend deux à trois jours. Il évite trois mois de corrections en cours de projet.

Construire des pipelines avec validation intégrée. Chaque transformation de données doit embarquer ses propres contrôles. Un pipeline qui ingère des devis doit vérifier que les montants sont dans des plages attendues, que les identifiants client existent dans le référentiel, que les dates sont cohérentes. Ce n'est pas de la sur-ingénierie — c'est ce qui permet de détecter une dérive trois jours après le déploiement plutôt que trois mois après. La conception de ces pipelines est une compétence à part entière, distincte du choix du modèle IA.

Documenter les règles métier dans le code, pas dans les têtes. "Un devis est valide si la marge est positive et le client actif depuis moins de 24 mois." Ce type de règle existe dans chaque organisation. Elle vit rarement dans la documentation, souvent dans la mémoire d'un expert. Les projets IA qui tiennent dans la durée ont formalisé ces règles en amont et les ont encodées dans les pipelines de validation. Quand l'expert change de poste, la règle reste.

Définir un seuil de qualité minimum avant de passer en production. Un agent IA métier ne devrait pas passer en production si le taux de données exploitables sur le périmètre cible est inférieur à 85-90 %. Ce seuil est arbitraire selon le cas d'usage — mais il doit exister. Sans lui, on déploie avec des données dégradées et on découvre les problèmes sur des cas réels, devant les utilisateurs. L'impact sur la confiance est difficile à réparer.

Ce qu'il faut retenir

• —93 % des entreprises ne disposent pas de données complètement prêtes pour l'IA. Ce n'est pas une fatalité — c'est un chantier qu'on peut cadrer en amont de chaque projet, sur le périmètre ciblé, sans attendre d'avoir tout nettoyé.
• —La qualité des données n'est pas un projet infrastructure séparé. C'est une phase de chaque projet IA. Les pipelines de validation, les règles métier encodées, le monitoring continu — tout cela se conçoit en même temps que l'agent, pas après.
• —Le vrai risque n'est pas que l'IA échoue — c'est qu'elle tourne sur de mauvaises données sans que personne ne s'en rende compte. Un modèle qui produit des résultats plausibles mais faux est plus dangereux qu'un modèle qui plante.