Pourquoi une infrastructure data AI-ready est si dure ?

Parce que le sujet n’est pas seulement technique. Une infrastructure data AI-ready demande des données fiables, mais surtout des décisions claires sur les responsabilités, les priorités, les risques et les budgets. L’IA ne pardonne pas les angles morts, elle les automatise et les amplifie.

Pourquoi l’IA révèle le problème data ?

L’IA révèle le problème data parce qu’elle enlève les rustines humaines qui masquaient déjà les failles. C’est souvent là que je vois le malentendu chez les dirigeants. Ils pensent avoir un sujet IA, alors qu’ils ont surtout un sujet de maturité data.

Les problèmes existaient avant. Les données étaient déjà dispersées entre CRM, ERP, outils métier, fichiers Excel, exports manuels et bases locales. Les définitions métier n’étaient pas toujours alignées. Un “client actif” ne voulait pas dire la même chose pour la finance, le commerce et le support. Les référentiels étaient incomplets. Les tableaux de bord racontaient parfois deux versions différentes de la même réalité. Et quand une donnée était fausse, personne ne savait vraiment qui devait la corriger.

Avant l’IA, ça tenait parce que les humains compensaient. Un analyste voyait une anomalie et retraitait le fichier. Un manager ajoutait le contexte en réunion. Quelqu’un disait “Attention, ce segment n’est pas fiable depuis la migration”. On temporisait. On posait des questions. On bricolait, parfois très bien d’ailleurs. J’ai vu des équipes sauver des décisions importantes juste parce qu’une personne connaissait l’historique caché derrière les chiffres.

Avec l’IA, cette marge disparaît en partie. Un modèle ne sait pas toujours que votre historique client est incomplet depuis six mois. Il peut prendre une donnée obsolète, biaisée ou mal définie, calculer un score, produire une recommandation et l’afficher avec beaucoup d’assurance. C’est ça le vrai danger. Pas l’erreur visible. L’erreur crédible.

Prenons un cas simple. Vous lancez un scoring client pour prioriser les efforts commerciaux. Le modèle regarde l’historique d’achat, les interactions support, les ouvertures d’emails et les opportunités CRM. Sauf que pendant un changement d’outil, une partie des échanges commerciaux n’a jamais été reprise. Certains clients fidèles semblent donc moins engagés qu’ils ne le sont vraiment. Le modèle les classe en faible priorité. Les commerciaux suivent la recommandation. Résultat, vous baissez l’effort sur des comptes importants, juste parce que la donnée de départ racontait une histoire incomplète.

Le problème n’est pas que l’IA se trompe. Le problème, c’est qu’elle industrialise vos angles morts. Elle prend ce qui était local, manuel, connu par quelques personnes, et elle le transforme en décision automatisée ou semi-automatisée.

Avant, un humain compensait	Maintenant, l’IA risque d’amplifier
Une définition métier floue corrigée en réunion	Une recommandation basée sur une mauvaise définition
Un fichier incomplet repéré par un analyste	Un modèle entraîné sur un historique biaisé
Un tableau de bord contradictoire discuté entre managers	Une décision automatisée présentée comme objective
Une responsabilité qualité implicite	Une erreur répétée à grande échelle

Où se cachent les vrais blocages ?

Le vrai sujet, ce n’est presque jamais “est-ce qu’on peut connecter cette source à notre stack data”. Bien sûr qu’on peut. Avec assez de temps, d’API, d’ETL ou de scripts, on finit toujours par brancher quelque chose. Le blocage arrive après, quand il faut décider si cette donnée est fiable, qui la possède, qui a le droit de la corriger, et surtout qui prend la responsabilité si l’IA s’en sert mal.

La qualité, l’intégration, la gouvernance et la sécurité des données sont indispensables. Mais dans la vraie vie, ces chantiers échouent rarement à cause d’un manque d’outils. Ils échouent parce que certaines décisions restent dans un angle mort. Qui est responsable de la donnée client ? Qui tranche quand le commerce et la finance n’ont pas la même définition du chiffre d’affaires ? Qui finance la remise à niveau d’un référentiel vieux de dix ans ? Qui accepte le risque quand une donnée sensible entre dans un workflow IA ? Qui valide qu’un modèle peut utiliser telle donnée dans tel contexte ?

J’ai vu ça chez plusieurs clients. Le plus dur n’était pas de brancher les données dans Snowflake, BigQuery, Databricks ou un outil d’automatisation. Le plus dur, c’était de faire accepter une définition commune du “client actif”. Pour le marketing, c’était quelqu’un qui ouvrait les emails. Pour le commerce, quelqu’un avec une opportunité en cours. Pour la finance, quelqu’un qui avait payé une facture récemment. Trois définitions, trois vérités, et une IA qui ne sait pas laquelle choisir.

C’est là que la confiance devient le vrai socle technique. Les équipes data doivent faire confiance aux métiers pour définir le sens. Les métiers doivent faire confiance à l’IT pour industrialiser proprement. Le juridique et la sécurité doivent être intégrés tôt, pas appelés à la fin pour dire non. Sinon, chaque workflow IA devient une négociation au cas par cas, lente, fragile, impossible à scaler.

Des cadres comme le NIST AI Risk Management Framework et l’ISO/IEC 42001 rappellent simplement une chose saine : L’IA demande une gestion explicite des risques, des rôles et des contrôles. Ce ne sont pas des documents à brandir en comité. Ce sont des garde-fous pour éviter que personne ne sache qui décide, qui valide, qui surveille.

Problème organisationnel	Symptôme visible	Conséquence sur l’IA
Pas de propriétaire clair de la donnée	Les corrections tournent entre équipes	Les modèles apprennent sur des données instables
Définitions métier non arbitrées	Chaque reporting donne un chiffre différent	L’IA produit des recommandations contradictoires
Budget de remise à niveau non décidé	Les référentiels restent incomplets ou obsolètes	Les workflows IA restent bloqués au prototype
Risque non assumé	Le juridique, la sécurité et le métier se renvoient la balle	Les cas d’usage IA avancent trop lentement ou sont stoppés
Validation d’usage inexistante	Personne ne sait si une donnée peut alimenter un agent ou un modèle	L’entreprise expose des données sensibles sans contrôle fiable

Pourquoi vouloir tout préparer bloque ?

Le piège, c’est de confondre ambition et périmètre géant. Je le vois souvent. Une entreprise veut devenir AI-ready, donc elle décide de rendre toutes ses données propres, documentées, gouvernées, accessibles, sécurisées, alignées, avant de lancer le moindre cas d’usage IA. Sur le papier, c’est sérieux. Dans la vraie vie, ça bloque.

Le réflexe est compréhensible. On se dit qu’il faut préparer le CRM, l’ERP, le support client, le tracking web, les données produit, les référentiels, les historiques, les droits d’accès. Tout. Comme si l’IA avait besoin d’un entrepôt parfait avant de produire la moindre valeur. Mais plus le périmètre grossit, plus l’énergie se dilue.

J’ai vu des équipes passer des mois à cartographier des tables que personne n’allait utiliser dans les 6 prochains mois. Pendant ce temps, aucun modèle n’était testé, aucun assistant IA n’était mis entre les mains des métiers, aucune hypothèse business n’était validée. On nettoyait. On classifiait. On débattait. Mais on n’apprenait pas.

Le vrai problème, c’est que cette approche transforme l’AI-ready en programme massif. Donc coûteux. Donc politique. Donc lent. Chaque source devient un sujet. Chaque règle de qualité devient un arbitrage. Chaque définition métier devient une réunion. Et la gouvernance, au lieu d’aider, devient vite perçue comme une couche administrative de plus.

La gouvernance sans cas d’usage clair finit souvent rejetée. Pas parce que les équipes sont contre la qualité ou la sécurité. Elles veulent juste comprendre à quoi ça sert maintenant. Si je demande à une équipe support de documenter 80 champs, mais que je ne peux pas lui montrer le chatbot interne, la réduction du temps de réponse, ou l’automatisation derrière, elle va décrocher. Normal.

Il ne s’agit pas de refuser l’ambition. Il s’agit de refuser l’ambition floue. Une portée utile part d’un objectif concret. Par exemple améliorer la qualification des leads, réduire les tickets support, automatiser l’analyse des verbatims clients. Là, on sait quelles données préparer en priorité. On avance plus vite, et surtout, on apprend sur du réel.

Portée utile	Portée dangereuse
Un cas d’usage IA identifié	Toutes les données à préparer avant de commencer
Quelques sources critiques	CRM, ERP, support, web, produit, finance en même temps
Une valeur business testable	Une promesse générale de transformation
Une gouvernance ciblée	Une gouvernance perçue comme administrative
Des apprentissages rapides	Des mois de préparation sans retour terrain

Comment construire par cas d’usage ?

La meilleure façon de construire une infrastructure data AI-ready, c’est de ne pas essayer de tout rendre parfait partout. Je pars toujours d’un cas d’usage précis, avec un vrai enjeu métier. La donnée devient prioritaire quand elle sert une décision, une expérience client ou un workflow concret.

Un bon cas d’usage coche quatre cases simples : un sponsor métier, une valeur mesurable, une donnée disponible ou récupérable, et un risque maîtrisable. Sans sponsor, ça flotte. Sans valeur mesurable, ça devient un chantier technique qui s’épuise. J’ai vu ça plusieurs fois chez des clients : tout le monde veut “faire de l’IA”, mais personne ne sait quelle décision doit changer lundi matin.

Prenons la réduction du churn, donc la baisse du nombre de clients qui partent. C’est un bon cas d’usage parce qu’il touche directement le chiffre d’affaires. On va chercher les données utiles : comportement client, engagement produit, satisfaction, historique d’achat ou d’usage, signaux de risque, interactions avec le support. Pas toute la donnée de l’entreprise. Juste celle qui aide à détecter un client fragile et à déclencher une action.

À partir de là, je stabilise le périmètre. Il faut clarifier quelques points avant de parler modèle IA :

• Définir ce qu’est un client “à risque”, un client “actif”, un client “perdu”.
• Mettre des contrôles qualité sur les données clés, comme les dates, les statuts, les doublons, les valeurs manquantes.
• Identifier les propriétaires de données, ceux qui savent vraiment ce que les champs veulent dire.
• Définir les accès, parce que tout le monde n’a pas besoin de voir les données sensibles.
• Poser les règles de sécurité, surtout si on manipule des données personnelles.
• Choisir les indicateurs de succès : baisse du churn, taux de détection, revenus sauvés, taux d’action des équipes.

On ne rend pas toute l’entreprise AI-ready d’un coup. On rend d’abord un périmètre utile, mesurable et gouverné. C’est beaucoup plus réaliste. Et surtout, ce premier socle devient réutilisable. Les données d’engagement, de satisfaction et de support peuvent ensuite servir à du scoring commercial, de la personnalisation, de la priorisation des comptes ou de l’assistance client augmentée.

Critère	Question à poser	Score simple
Impact	Est-ce que le cas d’usage change vraiment un résultat business ?	Faible / Moyen / Fort
Faisabilité	Est-ce que la donnée existe ou peut être récupérée sans projet interminable ?	Faible / Moyen / Fort
Risque	Est-ce que les enjeux sécurité, conformité ou adoption sont maîtrisables ?	Faible / Moyen / Fort
Réutilisabilité	Est-ce que le socle servira à d’autres cas d’usage proches ?	Faible / Moyen / Fort

Cette approche force à construire petit, mais solide. Et c’est souvent comme ça qu’on avance le plus vite.

Comment scaler sans perdre le contrôle ?

À ce stade, le vrai sujet n’est plus de prouver que l’IA peut marcher. C’est de réussir à la faire grandir sans créer un bazar ingérable.

Après un premier cas d’usage réussi, je ne repars jamais de zéro. Je capitalise. Les modèles de données, les définitions métier, les règles de qualité, les droits d’accès, la documentation, le monitoring, les responsabilités, les retours terrain… Tout ça devient un socle. Pas un socle parfait. Un socle vivant.

Le piège, c’est de traiter chaque nouveau projet IA comme une aventure isolée. Une équipe refait ses pipelines, une autre redéfinit “client actif”, une autre donne accès à des données sensibles sans vraie logique commune. Au début ça va vite. Puis ça casse. Et surtout, plus personne ne sait vraiment ce qui est fiable.

L’IA impose une surveillance continue. Une donnée peut dériver, c’est-à-dire changer progressivement de comportement. Un flux peut être modifié par une équipe source sans prévenir. Un modèle peut répondre moins bien parce que le contexte métier a bougé. Ce n’est pas dramatique, c’est normal. Mais il faut le voir vite.

Côté sécurité et conformité, je garde une approche simple. Je contrôle qui accède à quoi. Je trace les usages. Je minimise les données sensibles, donc je ne donne pas plus que nécessaire. Et quand l’impact est important, décision RH, crédit, santé, pricing sensible, je garde une validation humaine. Pas pour ralentir. Pour éviter l’automatisation aveugle.

Les meilleurs projets IA que je vois avancent par boucles courtes. Un cas d’usage concret, des métiers impliqués dès le départ, des retours rapides, puis on renforce les règles communes. La confiance ne se construit pas avec des promesses. Elle se construit avec des preuves visibles.

Élément à standardiser	Ce que je garde après chaque cas d’usage
Données	Modèles réutilisables, définitions métier, sources validées.
Qualité	Règles de contrôle, seuils d’alerte, tests automatisés.
Sécurité	Droits d’accès, traçabilité, gestion des données sensibles.
Exploitation	Monitoring, logs, alertes sur les dérives et erreurs.
Gouvernance	Responsables identifiés, documentation, validation humaine si nécessaire.
Métier	Retours utilisateurs, limites connues, critères de succès mesurables.

Et si le vrai chantier IA était déjà dans vos données ?

Une infrastructure data AI-ready ne se construit pas en achetant un nouvel outil ou en lançant un grand programme de nettoyage global. Je partirais plutôt d’un cas d’usage clair, avec une valeur business visible, puis je traiterais les données nécessaires à ce périmètre : qualité, définition, accès, sécurité, responsabilité. L’IA rend les vieux problèmes data plus coûteux, parce qu’elle les exécute vite et à grande échelle. Le bon réflexe, c’est donc de réduire la portée, prouver la valeur, puis élargir. Vous gagnez du temps, vous limitez le risque et vous construisez une base data vraiment utile pour vos décisions.

FAQ

• Qu’est-ce qu’une infrastructure data AI-ready ?
  C’est une infrastructure où les données utiles à l’IA sont accessibles, fiables, bien définies, sécurisées et gouvernées. Je ne parle pas seulement de stockage ou de pipelines. Je parle aussi de responsabilités claires, de règles qualité, de contrôles d’accès et d’un lien direct avec des cas d’usage business.
• Pourquoi l’IA rend les problèmes de données plus dangereux ?
  Parce qu’elle peut automatiser une mauvaise décision à grande vitesse. Avant, un analyste ou un manager pouvait repérer une incohérence et corriger à la main. Avec l’IA, une donnée incomplète ou biaisée peut produire une recommandation fausse, parfois présentée avec beaucoup d’assurance.
• Faut-il nettoyer toutes les données avant de lancer un projet IA ?
  Non, c’est souvent le piège. Nettoyer toute l’entreprise avant de créer de la valeur peut prendre des mois, voire des années. Je préfère partir d’un cas d’usage prioritaire, traiter les données nécessaires, prouver l’impact, puis élargir progressivement le socle.
• Quel est le meilleur premier cas d’usage IA pour structurer la data ?
  Le meilleur premier cas d’usage est celui qui combine impact business, faisabilité data et risque maîtrisé. La réduction du churn est un bon exemple si l’entreprise dispose déjà de données client, d’engagement, de satisfaction, d’historique et de signaux de risque exploitables.
• Qui doit piloter un chantier data AI-ready ?
  Pas uniquement la DSI ou l’équipe data. Il faut un sponsor métier, des responsables data identifiés, l’IT, la sécurité, parfois le juridique, et les équipes qui utiliseront vraiment les résultats. Sans arbitrage métier, la gouvernance reste théorique et l’IA ne passe pas à l’échelle.

 

 

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne les entreprises sur le tracking avancé server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA, le SEO et le GEO. J’ai travaillé avec des équipes comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Mon sujet, c’est simple : rendre la data exploitable, fiable et utile au business. Si vous voulez structurer vos données pour des usages IA concrets, contactez-moi.