Données métier et IA : pourquoi la qualité fait tout

Le blocage que personne ne veut voir

Un système d'IA détecte des patterns dans des données. Si ces données sont fausses, incomplètes ou incohérentes, le système retourne des résultats faux, incomplets ou incohérents. C'est mécanique. Pas un bug — une conséquence directe.

Gartner a publié en février 2025 une alerte sans ambiguïté : 60 % des projets d'IA seront abandonnés d'ici fin 2026 faute de données AI-ready (Gartner, fév. 2025). Pas faute de budget. Pas faute de modèle performant. Faute de données exploitables.

La dimension financière confirme l'ampleur du problème. En 2025, sur 684 milliards de dollars investis dans des initiatives IA à l'échelle mondiale, 547 milliards n'ont pas livré leur valeur attendue (Pertama Partners). Même proportion que l'année précédente. Ce n'est pas une courbe d'apprentissage — c'est un problème structurel.

La donnée métier d'une PME ou d'une ETI cumule plusieurs caractéristiques qui compliquent l'exercice. Elle est dispersée : ERP, tableurs partagés, exports manuels, emails, dossiers sur des serveurs locaux. Elle est rarement documentée : les colonnes changent de nom d'un projet à l'autre, les formats varient selon qui a rempli le fichier. Et elle décroît rapidement. Les données B2B se périment à 22,5 % par an (Landbase). Une base client non maintenue depuis 18 mois est déjà à 40 % périmée.

Un agent IA qui travaille sur ces données ne crée pas de valeur. Il amplifie les problèmes existants, à grande vitesse, sans signaler l'anomalie. Une ETI qui déploie un agent de traitement de contrats sur un CRM avec 40 % de doublons obtient un agent qui traite des doublons — pas un outil opérationnel.

Le coût est moins visible, mais il est réel : la mauvaise qualité des données coûte en moyenne 15 % du chiffre d'affaires annuel aux organisations qui n'en ont pas conscience (Gartner, via data-8.co.uk). Décisions mal informées, process sur des données périmées, doublons traités comme des clients distincts. Ce n'est pas une estimation abstraite — c'est le coût accumulé d'une donnée non gouvernée.

Ce que font les organisations dont les projets tiennent

Les projets IA qui passent en production et y restent ne sont pas toujours ceux qui ont les meilleurs modèles. Ce sont presque toujours ceux qui ont traité la donnée avant de traiter l'IA.

Un propriétaire de donnée par domaine métier. Ce n'est pas une notion IT — c'est une décision organisationnelle. Quelqu'un est responsable de la qualité de la donnée client. Quelqu'un est responsable de la donnée produit, de la donnée fournisseur. Sans cette désignation explicite, la qualité dérive. Dans 63 % des organisations, personne n'est certain que leurs pratiques de gestion de données sont adaptées à l'IA (Gartner Q3 2024, enquête auprès de 248 directeurs de la donnée). Ce vide est organisationnel, pas technique.

Un inventaire des sources avant tout déploiement. Pas un inventaire IT exhaustif — un inventaire métier ciblé. Pour le cas d'usage visé : quelles données sont nécessaires ? Où sont-elles ? Qui les maintient ? À quelle fréquence sont-elles mises à jour ? Cette cartographie prend une semaine. Elle révèle immédiatement les angles morts : bases non documentées, fichiers sans propriétaire, exports manuels jamais mis à jour. Elle évite des mois de debugging post-déploiement.

Des pipelines automatisés avec validation intégrée. Les projets fragiles se basent sur des exports manuels ponctuels. Les projets durables construisent des flux de données automatisés avec validation de schéma, détection d'anomalies et alertes en cas de dérive. La donnée arrive structurée et vérifiable — sans dépendre d'une action humaine. Quand un enregistrement ne respecte pas le schéma attendu, le système le signale plutôt que de le traiter silencieusement. C'est ce qui maintient la confiance dans le système après 12 mois de production.

Comment s'y prendre concrètement

L'erreur classique est de vouloir "nettoyer toutes ses données" avant de démarrer. C'est une impasse sans fin. Les données d'une entreprise ne sont jamais parfaites — et ce chantier exhaustif n'a pas de terme.

L'approche qui fonctionne est différente : travailler par domaine, sur un cas d'usage précis, avec un périmètre borné.

Identifier les données critiques pour un seul process. Si l'objectif est d'automatiser la qualification des demandes entrantes, les données critiques sont les emails entrants, l'historique des qualifications passées, et les règles de routage. Seulement ces données — pas la base entière. Ce périmètre restreint permet d'avancer vite et de démontrer la valeur sans attendre une transformation data globale.

Auditer sur 4 axes simples. Complétude — les champs attendus sont-ils remplis ? Cohérence — les valeurs respectent-elles un format stable ? Fraîcheur — quand la donnée a-t-elle été mise à jour pour la dernière fois ? Unicité — y a-t-il des doublons ? Un audit sur 300 à 500 enregistrements représentatifs donne une image fiable en quelques heures. Pas besoin d'un outil de data quality à six chiffres.

Corriger à la source, pas en patch. Il ne s'agit pas de corriger les données existantes une fois, mais d'empêcher la dégradation future. Validation à la saisie, normalisation des imports, règles de déduplication automatique. Ces ajustements sont souvent légers à implémenter. Personne ne les a faits parce que personne n'avait rendu le problème visible.

Intégrer la supervision dans l'architecture dès le départ. Un agent IA construit sur-mesure surveille la qualité de ses propres entrées. Il ne détecte pas les problèmes après coup — il les signale au moment où ils arrivent. Logs structurés, alertes sur les enregistrements hors normes, indicateurs de qualité visibles sans accéder au code. C'est la différence entre un outil qui tient 18 mois en production et un pilote qui s'effondre six mois après le go-live.

Construire cette architecture correctement dès le départ — c'est ce qu'Aurad System intègre dans chaque projet de développement sur-mesure. L'ingénierie des pipelines de données et la gouvernance des entrées ne sont pas des options de phase 2 — elles conditionnent la viabilité du projet en production.

Ce qu'il faut retenir

• —La donnée est le facteur limitant de la majorité des projets IA. Pas le modèle, pas le budget, pas le talent technique. Gartner prévoit que 60 % des projets IA seront abandonnés d'ici fin 2026 faute de données AI-ready. C'est le seul problème à résoudre en priorité.
• —Nettoyer "toutes ses données" avant de commencer n'est pas une stratégie — c'est un projet sans fin. L'approche qui fonctionne : identifier les données critiques pour un cas d'usage précis, les auditer sur 4 axes, corriger à la source, automatiser. Dans cet ordre.
• —La qualité des données ne se maintient pas seule. Elle demande une gouvernance explicite : un propriétaire par domaine, des pipelines automatisés, une supervision intégrée dès le premier jour. Ce n'est pas un projet IT — c'est une décision business.