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

78 % des organisations utilisent l'IA dans au moins une fonction en 2024, selon McKinsey^[1]. Mais seules 6 % en tirent un impact mesurable sur leur résultat d'exploitation. L'adoption est massive. Les résultats concrets, beaucoup moins. Ce chiffre ne m'étonne pas.

Je développe avec l'IA tous les jours — régression logistique pour le scoring d'attrition, distribution de Poisson pour l'absentéisme, simulations Monte Carlo pour la projection de scénarios dans effectivo. Précisément parce que je suis un praticien quotidien, je sais où elle excelle et où elle échoue. Et ce qui distingue les 6 % des 72 % 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é.

Je voudrais dans cet article défendre une conviction simple : 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. Et cette conviction a des implications très concrètes sur ce qu'il faut faire en priorité quand on lance une démarche data dans son organisation.

Le paradoxe adoption / impact

RAND Corporation estime que 80 % des projets IA échouent, soit le double du taux d'échec des projets informatiques classiques^[2]. S&P Global rapporte que 42 % des entreprises ont abandonné la majorité de leurs initiatives IA en 2025, contre 17 % l'année précédente^[3]. Le cycle est toujours le même : enthousiasme, investissement prématuré, déception, abandon. Le marché de l'IA en entreprise rejoue en accéléré le cycle de Gartner.

Quand je regarde ce qui distingue les projets qui réussissent de ceux qui échouent, je retrouve systématiquement les mêmes causes racines. Aucune n'est technique au sens strict. Toutes 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.

Cette observation rejoint ce que je décris dans l'article sur l'IA appliquée au pilotage : 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 « nos fondations sont-elles suffisamment solides pour que l'IA les enrichisse utilement ? ». C'est une bascule mentale qui change radicalement la discussion — et qui, malheureusement, arrive rarement en début de projet.

La frontière en dents de scie

Une étude HBS/BCG menée auprès de 758 consultants BCG a documenté ce qu'on appelle désormais la frontière en dents de scie de l'IA^[4] : sur certaines tâches, l'IA améliore spectaculairement la performance humaine ; sur d'autres, apparemment similaires, elle la dégrade. Et cette frontière n'est pas intuitive.

Concrètement : les consultants utilisant GPT-4 pour produire des idées créatives ont gagné 25 à 40 % en performance. Sur des tâches d'analyse quantitative apparemment proches, ceux qui utilisaient l'IA ont produit des résultats 19 % moins fiables que ceux qui s'en passaient — parce qu'ils acceptaient des calculs erronés sans les vérifier. Même outil, même contexte, résultats inverses. C'est la frontière en dents de scie. Ce phénomène est analysé en détail dans l'article dédié : naviguer la frontière en dents de scie de l'IA.

L'implication opérationnelle est forte : 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, pas par la théorie. C'est un apprentissage qui prend plusieurs mois, et qui ne se transmet pas par formation frontale.

Fondations avant modèles : le vrai premier projet data

Gartner estime que la mauvaise qualité des données coûte en moyenne 12,9 millions de dollars par an aux organisations^[5]. 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. C'est le fameux « garbage in, garbage out », formule ancienne et toujours aussi vraie.

Avant de choisir un modèle, il faut évaluer honnêtement la maturité de ses données. Trois questions simples. Vos 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 est ingrat. Il ne donne pas de démo spectaculaire. Il ne fait pas la une d'un rapport d'activité. Mais il conditionne tout le reste. C'est précisément ce que je reprends en mission quand une organisation veut « passer à l'IA » : je commence par regarder les données, pas par discuter des modèles. La plupart du temps, le diagnostic révèle qu'il faut reprendre 3 à 6 mois de consolidation avant même d'envisager un premier projet prédictif.

Un point qui surprend souvent mes interlocuteurs : 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 mécaniquement 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. C'est pour cette raison que je recommande systématiquement de structurer d'abord son processus budgétaire et son reporting avant d'introduire des couches analytiques avancées. La maturité se construit dans l'ordre.

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

Après des dizaines de missions, les mêmes pièges reviennent avec une régularité frappante. Les connaître permet de les éviter — ou au moins de les reconnaître tôt.

La surconfiance dans les résultats

Quand un modèle produit un chiffre, la tentation est de l'accepter tel quel. C'est précisément ce que l'étude HBS/BCG a observé chez les consultants : ceux 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. J'ai vu des équipes abandonner tout réflexe de vérification face à un chiffre « sorti de la machine ». Le modèle devient une autorité qu'on ne questionne plus.

Le cadrage insuffisant du cas d'usage

« 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 à 6 mois pour anticiper les tensions de recrutement ». Cadrer demande du temps — plus que la construction du modèle lui-même, souvent. Mais ce temps investi en amont évite les échecs tardifs, qui coûtent beaucoup plus cher. La règle : si vous ne pouvez pas formuler la question en une phrase précise avec une variable cible, vous n'êtes pas prêt à lancer le projet.

Le biais d'ancrage technologique

Quand l'IA propose une première réponse, l'humain l'utilise comme point de départ — même quand elle est fausse. Ce biais est documenté depuis Kahneman, 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. Ne jamais se contenter de la réponse IA comme point de départ — sinon on n'apprend rien, et on se prive de la valeur du jugement humain.

L'opacité de la délégation

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 : 3-4 cas d'usage plutôt que 6 mal faits

Une analyse BCG sur l'adoption de l'IA en entreprise montre que les organisations qui ont obtenu un impact mesurable ont en moyenne déployé 3 à 4 cas d'usage aboutis, contre 6 à 10 cas d'usage non aboutis dans les organisations sans impact^[6]. Moins de cas d'usage, mais mieux menés. Cette règle n'a rien d'intuitif — dans la plupart des organisations, le réflexe est d'élargir le périmètre pour justifier l'investissement. C'est exactement l'inverse qu'il faut faire.

Cette approche rejoint ce que je décris dans l'article sur l'évolution descriptif → prédictif : on ne saute pas les étapes. Consolider le descriptif, développer la culture diagnostique, puis expérimenter le prédictif sur un cas maîtrisé. La séquence compte plus que la vitesse.

La délégation progressive : 3 phases qui changent tout

La dernière erreur que je veux éviter — et celle qui coûte le plus cher quand elle se produit — c'est la délégation hâtive. Confier à l'IA une tâche sensible sans période de supervision produit des dégâts proportionnels à la confiance mal placée. Je propose une méthode en trois phases, testée dans mes propres outils et en mission.

Phase 1 : l'IA assiste

L'IA produit des premières versions, des suggestions, des hypothèses. L'humain fait tout le travail de validation : vérifier les calculs, challenger les résultats, ajuster. C'est la phase d'apprentissage mutuel. Elle peut durer plusieurs mois. Elle ne se saute pas. C'est pendant cette phase que se construit l'intuition de la frontière en dents de scie — où l'IA est fiable, où elle ne l'est pas.

Phase 2 : l'IA exécute sous supervision

Sur les tâches où l'IA a fait ses preuves pendant la phase 1, on lui confie l'exécution avec un contrôle ponctuel mais régulier. L'humain n'examine plus tout ; il échantillonne, vérifie par sondage. Cette phase suppose qu'on ait formalisé des indicateurs de qualité : taux d'erreur toléré, seuils de déclenchement d'alerte, périmètres d'autorisation.

Phase 3 : l'IA alerte

L'IA fonctionne en autonomie sur son périmètre éprouvé. Elle alerte l'humain uniquement en cas d'anomalie détectée ou de sortie de zone de confiance. C'est la phase la plus efficace — mais aussi celle qui suppose le plus de maturité. On n'y accède pas directement ; on y arrive après les phases 1 et 2.

Cette progression est conforme à l'esprit de l'approche souveraine et responsable de l'IA : l'humain reste responsable, la délégation est explicite et révisable, la boucle de contrôle est maintenue. Un outil comme effectivo illustre cette philosophie : les modèles sont transparents (régression logistique, distribution de Poisson), les résultats sont commentés par un humain avant diffusion, et les zones de décrochage sont documentées.

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. Fiabiliser les sources, harmoniser les référentiels, documenter les circuits de remontée : ce travail moins spectaculaire est celui qui conditionne tout le reste. Si vos données sont fragiles partout, commencez 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. La projection de masse salariale, la détection d'anomalies dans la paie, la prévision d'absentéisme par service cochent ces trois cases. Évitez les cas d'usage flous et les cas sans données suffisantes.

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

Pas forcément en premier. Ce qui manque le plus souvent, ce n'est pas un data scientist, c'est un profil hybride qui comprend à la fois le métier et la data — même modestement. La double compétence vaut mieux que la sur-spécialisation isolée.

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

Un POC de 4 à 6 semaines sur vos propres données, avec un cas d'usage que vous maîtrisez et dont vous connaissez la réponse attendue. Pas sur les données du fournisseur. Impliquez les utilisateurs finaux pendant le POC, pas seulement après. Évaluez trois critères : précision du modèle, transparence du raisonnement, portabilité.

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