Pourquoi 95 % des pilotes d'IA échouent avant de produire le moindre résultat
Il existe une scène qui se répète dans presque toutes les entreprises de taille intermédiaire que je connais. L'équipe technologique présente un pilote d'intelligence artificielle. Les chiffres initiaux sont prometteurs. Le conseil d'administration approuve l'investissement. Et six mois plus tard, le pilote est toujours un pilote. Personne ne l'arrête officiellement. Il ne monte pas non plus en charge. Il occupe simplement... de l'espace dans la feuille de route et dans les réunions de suivi.
Dennis Woodside, président et PDG de Freshworks, a publié il y a quelques jours une analyse dans Fortune qui donne un nom à ce phénomène. Et même si l'article sert également de positionnement commercial pour son entreprise, le diagnostic qu'il propose mérite d'être pris au sérieux pour une raison simple : les données externes qu'il cite sont inconfortables pour tout cadre dirigeant qui promet depuis plus d'un an des résultats en matière d'IA à son conseil d'administration.
Le MIT a constaté que 95 % des pilotes d'IA générative échouent avant d'atteindre la production. Boston Consulting Group a publié en septembre 2025 que 60 % des entreprises ne génèrent aucune valeur matérielle avec l'IA, et ce pourcentage s'est aggravé par rapport à l'année précédente, malgré l'amélioration des modèles et l'augmentation de l'expérience accumulée. Freshworks ajoute sa propre donnée : un quart du budget IA des PME est consommé par l'intégration, le nettoyage des données et l'effort pour faire communiquer des systèmes qui n'ont jamais été conçus pour s'articuler entre eux.
Ce que ces trois chiffres ont en commun, ce n'est pas le modèle d'IA choisi. C'est l'état de l'environnement opérationnel dans lequel on tente de le déployer.
La décision qui sépare ceux qui avancent de ceux qui stagnent
Woodside décrit le cas de Seagate Technology avec une précision qui s'avère utile précisément parce qu'elle n'a rien de glamour. L'équipe IT disposait de trois mois pour migrer 30 000 employés vers une nouvelle plateforme de gestion des services, contrainte par l'expiration d'un contrat. La décision évidente, celle que presque toute organisation prendrait sous cette pression, était de transférer les configurations existantes telles quelles et de résoudre les problèmes ensuite. C'est la voie la plus sûre à court terme. C'est aussi celle qui garantit que toute couche d'IA construite par-dessus fonctionnera sur des fondations défectueuses.
L'équipe de Seagate a choisi l'inverse. Elle a reconstruit de zéro : restructuré le catalogue de services, établi des niveaux de service cohérents entre les régions, réécrit les hiérarchies de catégories pour que les tickets puissent être acheminés automatiquement sans qu'un agent ait à deviner. Elle l'a fait dans le même délai de trois mois. Un an plus tard, l'agent d'IA déployé sur cette base dévie environ un tiers des tickets entrants et la résolution au premier contact est 27 % au-dessus du standard de l'industrie.
Cette décision — reconstruire plutôt que répliquer — est le pivot de l'argumentation de Woodside. Et elle comporte une lecture organisationnelle qui va bien au-delà de la technologie.
Ce que Seagate a fait a nécessité que quelqu'un, à un moment donné du processus, engage une conversation que personne ne voulait avoir : celle qui reconnaît que les processus hérités ne sont pas simplement inefficaces, mais qu'ils constituent un obstacle actif à toute amélioration future. Cette conversation a un coût politique. Dire que les processus actuels ne seront pas transférés, c'est dire que des années de travail de configuration, de personnalisation et d'ajustement ne voyageront pas vers le nouvel environnement. C'est invalider, au moins partiellement, des décisions passées. Peu d'organisations ont l'appétit pour cela sous pression temporelle.
Ce qui distingue Seagate, ce n'est pas d'avoir disposé de plus de ressources ni de plus de temps. C'est d'avoir eu la lucidité, ou le courage managérial, de ne pas traîner le passé vers l'avenir lorsque le contrat est arrivé à échéance. C'est la variable qui n'apparaît dans aucun manuel de mise en œuvre de l'IA.
La taxe invisible que paie celui qui ne regarde pas ses processus
Woodside introduit le concept de « taxe de complexité » pour décrire ce qui se passe lorsqu'une entreprise tente de déployer l'IA sur une architecture fragmentée. Ce n'est pas une métaphore décorative. C'est une mécanique financière concrète.
Si 25 % du budget IA se perd en intégration et en nettoyage de données avant que le modèle ne produise un seul résultat utile, une entreprise qui alloue un million de dollars à l'IA achète, en pratique, 750 000 dollars de capacité. Les 25 % restants sont absorbés par la dette technique accumulée. Pour une grande entreprise dont les budgets de transformation se comptent en centaines de millions, cette fraction peut être tolérée. Pour une entreprise de 500 à 20 000 employés, avec des équipes IT réduites et des marges de manœuvre plus étroites, cette perte peut faire la différence entre une initiative qui prospère et une qui est silencieusement annulée lors du prochain cycle budgétaire.
L'argument de Woodside sur les « entreprises agiles » — son terme pour désigner cette catégorie d'organisations de taille intermédiaire — a une logique que les grands médias ignorent généralement parce que le segment n'est pas aussi photogénique que les récits de transformation numérique des entreprises du Fortune 500. Mais c'est précisément là que va se gagner ou se perdre la bataille de productivité que promet l'IA. Les PME représentent la majorité du tissu entrepreneurial mondial. Si l'IA ne fonctionne pas là, la promesse de gains de productivité agrégés ne se concrétise pas, quoi que fassent Google, Microsoft ou Amazon avec leurs propres modèles.
Ce qui rend l'analyse encore plus intéressante, c'est que le problème ne réside pas dans la sélection du modèle. Il se situe à une couche antérieure et plus difficile à résoudre : la qualité de l'environnement opérationnel. Des données dispersées dans des systèmes qui ne communiquent pas. Des flux de travail définis par l'histoire de l'entreprise plutôt que par sa logique. Des taxonomies de tickets, des catégories de services ou des hiérarchies de produits que personne n'a révisées parce qu'elles avaient toujours « suffisamment bien fonctionné ». Lorsqu'on demande à un agent d'IA d'opérer sur cette infrastructure, il n'échoue pas parce que le modèle est mauvais. Il échoue parce que l'environnement lui fournit des informations ambiguës, incomplètes ou contradictoires, et aucun modèle ne peut compenser cela.
Robert Lyons, directeur technologique de Katz Media Group, une unité d'affaires de 800 personnes au sein d'une entreprise de 10 000 employés, offre dans l'analyse de Woodside ce qui est peut-être le conseil le plus pratique de l'article complet : avant de déployer tout outil d'IA, son équipe a nettoyé et étiqueté les données, et a organisé un séminaire d'introduction à l'IA pour tous les employés de l'entreprise, dispensé non pas par l'équipe IT mais par un cabinet de recherche indépendant. La distinction est importante. Lorsque l'IT présente l'IA, elle le fait avec le biais implicite de celui qui a intérêt au résultat. Lorsqu'un tiers neutre le fait, le message passe différemment et la résistance organisationnelle diminue.
Lyons décrit également une matrice valeur/effort pour prioriser les projets d'IA : la facilité de mise en œuvre sur un axe, la valeur pour l'entreprise sur l'autre. Il commence par le quadrant à haute valeur et faible effort. Son avertissement — « ne commencez pas par le pire problème en premier, vous n'allez pas générer de valeur » — est une critique directe d'un modèle que j'observe fréquemment dans des organisations qui traitent l'IA comme une opportunité de résoudre les problèmes qu'aucune autre initiative n'a pu résoudre. Cette logique est compréhensible, mais elle est contre-productive. Les projets d'IA les plus visibles et les plus ambitieux sont aussi les plus fragiles, parce qu'ils opèrent sur les environnements de données les plus désordonnés et les flux de travail les moins structurés.
Ce que Nucor et New Balance ont en commun avec une aciérie
Woodside cite deux comparaisons qui méritent une attention séparée. La première est entre Nike et New Balance. Nike opère avec 80 000 employés ; New Balance avec 9 000. Woodside soutient que New Balance gagne du terrain concurrentiel en consolidant son infrastructure IT sur une plateforme unique avec une source de vérité centralisée, libérant les équipes du travail de maintenance et reconfigurant la façon dont l'entreprise fonctionne. La deuxième comparaison concerne Nucor et Steel Dynamics, deux des quatre plus grands fabricants d'acier des États-Unis, qui selon Woodside maintiennent depuis des décennies une discipline opérationnelle qui produit des environnements que l'IA peut optimiser directement.
Le modèle qui relie ces cas est le même que celui qui apparaît chez Seagate : l'IA fonctionne là où l'environnement opérationnel était prêt à la recevoir. Pas parfait. Prêt. Des données consolidées, des flux de travail définis, des systèmes capables d'échanger des informations sans intervention manuelle, et un résultat mesurable que l'agent d'IA doit améliorer.
Cela a une implication managériale que peu de gens nomment clairement. Les entreprises qui ont le plus de difficultés à déployer l'IA ne sont pas celles qui ont choisi le mauvais modèle ou qui ont engagé les mauvais consultants. Ce sont celles qui, pendant des années, ont pris des décisions technologiques en privilégiant la continuité opérationnelle sur la cohérence architecturale. Chaque fois que quelqu'un a dit « ajoutons ce système parce qu'il résout ce problème maintenant » sans se demander comment ce système allait s'intégrer avec le reste, il accumulait un passif qui se paie aujourd'hui sous forme de budget IA consommé en intégration.
Ce passif n'est pas un défaut technique. C'est le résultat cumulé de conversations sur l'architecture qui n'ont pas eu lieu, d'évaluations de dette technique qui ont été reportées parce que le trimestre exigeait de la vitesse, de configurations héritées que personne n'a voulu revisiter parce que le coût politique de les remettre en question était trop élevé.
Ce que les cas réussis décrits par Woodside ont en commun, c'est que quelqu'un, à un moment donné, a pris la décision de payer ce passif. Seagate l'a fait sous la pression d'un contrat arrivant à expiration. New Balance l'a fait dans le cadre d'un pari stratégique sur la vitesse. Nucor et Steel Dynamics l'ont fait pendant des décennies sans savoir qu'ils construisaient les fondations d'un avantage concurrentiel en matière d'IA.
Celui qui dirige doit payer le coût de regarder ce que l'organisation évite de nommer
Il y a un élément de l'argumentation de Woodside que l'article effleure tangentiellement, mais qui mérite d'être nommé de front : la plupart des organisations bloquées dans des pilotes d'IA le savent. Ce n'est pas de l'ignorance technique. C'est que la conversation sur l'état de l'environnement opérationnel a un coût politique que personne ne veut payer.
Admettre que 25 % du budget IA se perd en intégration et en nettoyage de données, c'est admettre que les décisions architecturales du passé ont été coûteuses. Admettre que les processus hérités ne peuvent pas être transférés vers le nouvel environnement, c'est admettre que des années de configuration ne survivent pas au changement. Admettre que les données sont en mauvais état, c'est admettre que les initiatives de qualité des données des dernières années n'ont pas tenu leurs promesses.
Ces admissions exigent quelque chose que la dynamique de nombreux conseils d'administration décourage : la capacité de nommer un problème structurel sans que la personne qui le nomme soit associée à l'échec qu'elle décrit.
Le travail de celui qui dirige dans ce contexte n'est pas technique. C'est de créer les conditions pour que ces conversations puissent avoir lieu sans que le messager en paie le prix. Les organisations qui génèrent des résultats avec l'IA — les cas décrits par Woodside — n'ont pas des environnements parfaits. Elles ont des dirigeants qui ont décidé de payer le coût de la clarté avant de payer le coût d'une mise en œuvre ratée.
Cette séquence n'est pas intuitive sous pression. Mais c'est la seule qui produit des résultats qui ne disparaissent pas lors du prochain cycle de révision budgétaire.
