Études & Réflexions › Données et IA : les fondations comptent plus que les modèles

L'adoption de l'IA en entreprise progresse vite. Les résultats mesurables sur le résultat d'exploitation progressent beaucoup plus lentement. Ce qui distingue les organisations qui en tirent un impact réel de celles qui n'en tirent rien n'est presque jamais la sophistication du modèle : c'est la qualité des données en amont, la clarté des questions posées, la méthode de déploiement et la discipline de la délégation. Les modèles sont devenus une commodité accessible à toutes les organisations ; les fondations, elles, restent un travail de fond que rien ne remplace. Avant d'aller plus loin, il est utile d'évaluer où l'organisation en est réellement : un diagnostic de maturité data fournit une grille opérationnelle pour identifier les fondations à renforcer en priorité.

Ce qui fait la différence entre un projet data/IA qui livre et un projet qui s'enlise, ce sont les fondations, pas les modèles. Cette conviction a des implications concrètes sur ce qu'il faut faire en priorité quand on lance une démarche data dans son organisation.

Le paradoxe adoption / impact

Un rapport RAND de 2024 rapporte que, selon des estimations antérieures qu'il cite, plus de 80 % des projets IA échouent, soit le double du taux d'échec des projets informatiques classiques. Une enquête S&P Global 2025 (plus de 1 000 entreprises interrogées en Amérique du Nord et en Europe) indique que 42 % des entreprises ont abandonné la majorité de leurs initiatives IA en 2025, contre 17 % l'année précédente. Le cycle est souvent le même : enthousiasme, investissement prématuré, déception, abandon.

Les causes racines des échecs sont rarement techniques au sens strict. Ce sont des questions de méthode : cadrage insuffisant, données fragiles, absence d'utilisateurs impliqués, ambition disproportionnée par rapport à la maturité de l'organisation. La technologie est généralement le maillon le plus solide de la chaîne ; ce sont les maillons humains et organisationnels qui cèdent. L'IA est un amplificateur : elle amplifie la qualité du cadre de mesure s'il est bien conçu, elle amplifie ses défauts dans le cas contraire. La question n'est jamais « faut-il adopter l'IA ? » mais « les fondations sont-elles suffisamment solides pour que l'IA les enrichisse utilement ? ».

La frontière en dents de scie

Une étude de la Harvard Business School et du BCG Henderson Institute, menée auprès de 758 consultants BCG, a documenté ce qu'on appelle la frontière en dents de scie de l'IA générative : sur certaines tâches, l'IA améliore nettement la performance humaine (vitesse en hausse de plus de 25 %, qualité perçue en hausse de plus de 40 % sur les tâches situées à l'intérieur de la frontière) ; sur d'autres, apparemment similaires mais situées hors de cette frontière, elle la dégrade. Et cette frontière n'est pas intuitive à deviner à l'avance.

L'implication opérationnelle est directe : on ne peut pas déduire d'un succès sur une tâche que l'IA sera bonne sur une tâche voisine. Chaque cas d'usage doit être testé empiriquement, et chaque utilisateur doit développer une intuition du périmètre où « son » IA est fiable, par la pratique plutôt que par la théorie. C'est un apprentissage qui prend plusieurs mois et qui ne se transmet pas par une seule formation frontale.

Fondations avant modèles : le vrai premier projet data

Gartner estimait en 2020 que la mauvaise qualité des données coûte en moyenne 12,9 millions de dollars par an aux organisations. Un modèle nourri par des données fragiles produit des prédictions fragiles, avec l'apparence de la précision, ce qui est pire qu'une absence de prédiction. C'est le principe ancien du « garbage in, garbage out », toujours vrai.

Avant de choisir un modèle, il faut évaluer honnêtement la maturité de ses données. Trois questions simples. Les données sont-elles complètes, à jour, cohérentes entre sources ? Les référentiels (codes services, nomenclatures) sont-ils maintenus et partagés ? Les circuits de remontée fonctionnent-ils sans bricolage manuel ? Si une de ces trois réponses est « non » ou « incertain », le vrai premier projet n'est pas un projet IA, c'est un projet de fiabilisation des données.

Ce travail de fondations produit déjà de la valeur avant toute IA : une organisation qui fiabilise ses données descriptives et harmonise ses référentiels voit généralement la qualité de ses décisions s'améliorer, simplement parce que les chiffres deviennent fiables. L'IA est un accélérateur de cette dynamique, pas sa cause. La maturité se construit dans l'ordre : structurer d'abord le processus budgétaire et le reporting avant d'introduire des couches analytiques avancées.

Les pièges récurrents des projets data/IA

Quand un modèle produit un chiffre, la tentation est de l'accepter tel quel. C'est précisément ce que l'étude sur la frontière en dents de scie a observé : les consultants qui utilisaient l'IA sur des tâches pour lesquelles elle n'était pas adaptée produisaient des résultats plus homogènes entre eux, tous ancrés sur la même réponse erronée. L'IA crée un effet d'ancrage collectif ; sans esprit critique actif, cet effet devient un piège. Le modèle peut devenir une autorité qu'on ne questionne plus.

« On voudrait faire un peu d'IA » n'est pas un projet, c'est une intention. Un projet commence quand la question est précise : « on veut prédire le taux d'attrition de chaque service à six mois pour anticiper les tensions de recrutement ». Cadrer demande souvent plus de temps que la construction du modèle lui-même. Mais ce temps investi en amont évite les échecs tardifs, qui coûtent beaucoup plus cher. La règle : si la question ne peut pas se formuler en une phrase précise avec une variable cible, le projet n'est pas prêt à démarrer.

Quand l'IA propose une première réponse, l'humain a tendance à l'utiliser comme point de départ, même quand elle est fausse. Ce biais d'ancrage est documenté en sciences du comportement, et l'IA l'amplifie. La parade est simple mais exigeante : produire d'abord sa propre réponse, puis comparer avec celle de l'IA ; si les deux divergent, investiguer pour comprendre.

Beaucoup d'équipes utilisent l'IA sans formaliser ce qu'elles lui confient. Résultat : responsabilités floues, résultats non vérifiés, dérives invisibles. La délégation à l'IA gagne à être explicite, avec des zones de délégation claires et des points de contrôle définis. C'est une discipline organisationnelle, pas une question technique.

Commencer petit, bien

Dans la plupart des organisations, le réflexe est d'élargir le périmètre d'un projet IA pour justifier l'investissement. C'est souvent l'inverse qu'il faut faire : un nombre restreint de cas d'usage menés jusqu'au bout produit généralement plus de valeur qu'un grand nombre de cas d'usage lancés en parallèle et inaboutis. Cette approche rejoint la logique de la progression par paliers du descriptif vers le prédictif : consolider le descriptif, développer la culture diagnostique, puis expérimenter le prédictif sur un cas maîtrisé, sans sauter d'étape.

La délégation progressive, en bref

Une fois un cas d'usage cadré et les données fiabilisées, la question suivante est celle du niveau de délégation à l'IA : jusqu'où la laisser agir seule, et à partir de quand un humain doit-il reprendre la main ? Cette mécanique, en plusieurs phases progressives, mérite un traitement à part entière : elle est développée dans l'article consacré à la délégation à l'IA. Le point à retenir ici est que la délégation ne se décide pas d'un bloc : elle se construit progressivement, sur un périmètre éprouvé, avec des points de contrôle définis à l'avance.

Questions fréquentes

Faut-il passer à l'IA avant d'avoir structuré ses données ?

Non. Un modèle nourri par des données fragiles produit des prédictions fragiles, avec l'apparence de la précision, ce qui est pire qu'une absence de prédiction. Fiabiliser les sources, harmoniser les référentiels, documenter les circuits de remontée : ce travail moins spectaculaire conditionne tout le reste. Si les données sont jugées solides sur un périmètre restreint, démarrer là ; si elles sont fragiles partout, commencer par les solidifier.

L'IA va-t-elle remplacer les contrôleurs de gestion ?

Non, mais elle change leur rôle. Les tâches répétitives (consolidation, mise en forme, commentaires standards) sont automatisables. Ce qui reste irréductiblement humain, c'est le dialogue avec les opérationnels, l'interprétation d'un écart dans son contexte, l'arbitrage entre priorités concurrentes. Le contrôleur de gestion qui embrasse ce repositionnement devient plus précieux.

Quels cas d'usage démarrer en priorité ?

Les cas où les données historiques sont abondantes, les variables explicatives identifiables, et l'impact métier clair : projection de masse salariale, détection d'anomalies dans la paie, prévision d'absentéisme par service cochent ces trois cases. Éviter les cas d'usage flous (« améliorer la performance globale ») et les cas sans données suffisantes (« prédire les tendances de marché sur un historique de six mois »). Commencer petit, sur un cas maîtrisé.

Faut-il recruter un data scientist dans l'équipe finance ?

Pas forcément en premier lieu. Ce qui manque le plus souvent n'est pas un data scientist, c'est un profil hybride qui comprend à la fois le métier et la donnée, même modestement. Un contrôleur de gestion formé aux fondamentaux statistiques fait souvent plus pour le pilotage qu'un data scientist déconnecté du métier.

Comment évaluer sérieusement un outil d'IA avant d'acheter ?

Avec un test de quelques semaines sur ses propres données, sur un cas d'usage déjà maîtrisé et dont la réponse attendue est connue, pas sur les données du fournisseur. Impliquer les utilisateurs finaux pendant le test, pas seulement après. Évaluer trois critères : la précision du modèle face au jugement expert, la transparence du raisonnement (peut-on expliquer un résultat ?), la portabilité (que se passe-t-il en cas de changement d'outil dans quelques années ?).

Brice Béchet

Consultant en pilotage des organisations

Contrôleur de gestion sénior, data scientist et créateur d'effectivo.fr, application de prévision stratégique des effectifs (Anticipez. Simulez. Décidez), j'accompagne les organisations à structurer leurs données et optimiser leur pilotage.

En savoir plus LinkedIn