Data governance : le prérequis invisible avant d'automatiser quoi que ce soit

Plus de 80% des projets IA en entreprise échouent à produire la valeur attendue — un taux deux fois supérieur à celui des projets informatiques classiques, selon une étude de la RAND Corporation menée auprès de 65 data scientists et ingénieurs. Parmi les cinq causes racines identifiées, une seule est purement technique. La donnée insuffisante, inaccessible ou de mauvaise qualité en est une cause directe et documentée — et elle précède, dans l'ordre des opérations, tout choix de modèle ou d'outil.

Pourquoi la donnée, pas le modèle, est la cause principale d'échec

Ce que montre l'étude RAND (2024)

L'étude The Root Causes of Failure for Artificial Intelligence Projects, publiée par la RAND Corporation, a synthétisé les expériences de 65 data scientists et ingénieurs pour identifier cinq causes racines d'échec des projets IA : une définition mal comprise du problème à résoudre, une donnée d'entraînement insuffisante ou inaccessible, une approche technologique choisie avant le problème métier, une infrastructure de déploiement inadéquate, et un problème trop complexe pour l'état actuel de la technique. Sur ces cinq causes, une seule — le dernier point — relève réellement d'une limite technologique. Les quatre autres, dont la donnée insuffisante, sont organisationnelles et procédurales.

Le coût direct de la mauvaise qualité de donnée

Gartner évalue le coût moyen de la mauvaise qualité de donnée à environ 12,9 millions de dollars par an et par organisation. Ce chiffre ne concerne pas uniquement les projets d'IA — il touche l'ensemble des décisions prises sur une donnée dégradée — mais il éclaire directement pourquoi un projet d'automatisation construit sur cette même donnée hérite structurellement du problème avant même son premier déploiement.

Le lien avec le facteur organisationnel déjà identifié

Une composante concrète du "learning gap"

Nous avions déjà détaillé, dans notre analyse de la valeur réelle de l'IA générative en entreprise, le concept de "learning gap" identifié par le MIT NANDA — l'incapacité organisationnelle à intégrer un outil d'IA dans des flux de travail existants — ainsi que le poids de la préparation organisationnelle mesuré par McKinsey. La gouvernance des données est l'une des composantes les plus concrètes et les plus mesurables de cette préparation organisationnelle : elle n'est pas un sujet distinct, mais un des mécanismes précis par lesquels ce facteur organisationnel se traduit — ou non — en résultats.

Ce que confirme l'enquête Informatica

Une enquête menée par Informatica auprès de directeurs des données (CDO Insights, 2025) a établi que 43% des organisations interrogées citent la qualité et la préparation de la donnée comme premier obstacle à la réussite de leurs projets d'IA — devant les contraintes budgétaires ou le manque de compétences techniques.

Les 4 dimensions d'une gouvernance de donnée prête pour l'automatisation

Ownership : qui est responsable de quelle donnée

Sans propriétaire clairement identifié pour chaque catégorie de donnée, personne n'est réellement en charge de sa qualité, de sa mise à jour, ou de sa correction en cas d'erreur détectée. C'est l'une des lacunes les plus fréquemment citées dans la littérature sur l'échec des projets IA.

Qualité : exactitude, complétude, fraîcheur

Une donnée incomplète, dupliquée ou obsolète produit un modèle qui reproduit fidèlement ces défauts, à l'échelle. La qualité n'est pas un état ponctuel obtenu une fois, mais une propriété qui doit être maintenue dans la durée à mesure que la donnée évolue.

Accessibilité : silos vs architecture unifiée

Une donnée de bonne qualité mais dispersée entre des systèmes cloisonnés qui ne communiquent pas entre eux reste, en pratique, aussi inutilisable qu'une donnée de mauvaise qualité. L'accessibilité technique — pas seulement l'existence de la donnée — conditionne directement sa mobilisation dans un projet d'automatisation.

Conformité : rétention, vie privée, traçabilité

La conformité réglementaire (durée de conservation, gestion du consentement, traçabilité des traitements) n'est pas une contrainte périphérique : un projet d'automatisation qui ignore ces règles en amont s'expose à devoir être reconstruit une fois le problème découvert, généralement après le déploiement plutôt qu'avant.

Exemple chiffré : évaluer sa préparation avant de lancer un projet

Une grille d'auto-évaluation simple, notée sur 100 points et répartie également sur les quatre dimensions précédentes, permet de situer objectivement où se trouve une organisation avant de lancer un projet :

• Ownership (25 points) : avant tout travail de gouvernance, une organisation typique où la responsabilité de la donnée n'a jamais été formellement assignée obtient environ 10/25.
• Qualité (25 points) : avec des doublons et des champs incomplets non traités, le score initial se situe généralement autour de 12/25.
• Accessibilité (25 points) : une donnée dispersée entre plusieurs systèmes sans architecture unifiée obtient typiquement 8/25.
• Conformité (25 points) : une conformité réglementaire basique mais sans traçabilité documentée des traitements atteint environ 15/25.

Soit un total initial de 45 points sur 100. Après un travail structuré d'assignation de propriétaires, de nettoyage des doublons, de mise en place d'un accès centralisé et de documentation des traitements, ces mêmes dimensions atteignent typiquement 22, 20, 20 et 23 points respectivement, soit un total de 85 points sur 100 — un niveau de préparation qui change fondamentalement la probabilité de succès du projet d'automatisation envisagé, conformément aux causes d'échec identifiées par la RAND Corporation.

Ce que ça implique concrètement avant de lancer un projet IA

L'ordre correct : gouvernance d'abord, outillage ensuite

Le même piège déjà identifié dans notre article sur le marketing automation B2B — configurer l'outil avant d'avoir cartographié le besoin réel — se retrouve ici sous une forme différente : lancer un projet d'IA avant d'avoir évalué la préparation de la donnée sous-jacente. Dans les deux cas, l'erreur est la même : traiter l'outillage comme le point de départ plutôt que comme la dernière étape d'une préparation plus large.

Qui doit être impliqué : pas seulement la DSI

Confier la gouvernance des données à la seule direction des systèmes d'information est une erreur fréquente identifiée dans la littérature : la DSI porte généralement l'infrastructure et l'accessibilité technique, mais la définition de ce qui constitue une donnée de qualité dans un contexte métier donné, ainsi que la responsabilité de sa mise à jour, doivent être portées par les équipes métier elles-mêmes.

Sources

• RAND Corporation (2024). The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed. rand.org
• Gartner (2024-2025). Estimation du coût moyen de la mauvaise qualité de donnée, citée dans plusieurs analyses sectorielles.
• Informatica (2025). CDO Insights Survey.

---

Votre projet d'automatisation repose-t-il sur une donnée dont personne n'a formellement la responsabilité ? Échangeons-en à partir d'un diagnostic honnête de votre préparation réelle.