42 % des projets IA échouent — et ce n'est pas un problème de technologie

Un chiffre qui dérange

Dans son Founder's Playbook, Anthropic avance un chiffre brut : 42 % des startups construisent un produit dont personne ne veut. Pas par manque de talent ni de moyens techniques. Simplement parce qu'elles ont résolu le mauvais problème, très bien, et très vite.

Ce constat ne concerne pas que les startups de la tech. Il décrit avec une précision gênante ce qui se passe aujourd'hui dans beaucoup d'ETI et de PME françaises lancées dans des projets d'automatisation et d'IA. On déploie des agents, on connecte des outils, on automatise des tâches. Et six mois plus tard, le gain promis n'est pas là. Le problème n'est presque jamais la technologie. Il est en amont.

Automatiser un mauvais processus, c'est accélérer le désordre

Quand un processus est bancal, l'automatiser ne le corrige pas. Elle le fige et le démultiplie. Vous prenez une procédure approximative, pleine d'exceptions non documentées, de validations informelles et de fichiers Excel qui se baladent entre trois services — et vous la faites tourner à vitesse maximale, sans supervision humaine.

Le résultat est mécanique : les erreurs se propagent plus vite, les cas particuliers passent à la trappe, et personne ne sait expliquer pourquoi le système produit tel résultat. On ne peut pas automatiser le chaos. On ne peut que l'industrialiser.

C'est exactement le piège du chiffre d'Anthropic, transposé à l'entreprise. On exécute parfaitement une chose qui n'aurait pas dû être faite ainsi. La performance technique masque l'erreur de fond.

La dette opérationnelle, ce coût invisible

Le danger des projets d'automatisation mal préparés, c'est qu'ils ne plantent pas spectaculairement. Ils accumulent une dette opérationnelle silencieuse, qui se révèle des mois plus tard :

• des agents déployés sans architecture documentée, que personne ne sait plus maintenir quand le prestataire part ;
• des processus jamais nettoyés, avec leurs règles implicites et leurs contournements maison désormais coulés dans le code ;
• des données non structurées, dispersées, dupliquées, sur lesquelles l'automatisation s'appuie sans fiabilité ;
• des dépendances invisibles entre outils qui rendent chaque modification risquée.

Cette dette ne se voit pas dans le tableau de bord du trimestre. Elle apparaît quand vous voulez faire évoluer le système, changer un fournisseur, ou expliquer une décision à un client ou à un auditeur. À ce moment-là, le coût de remise en ordre dépasse largement ce qu'aurait coûté un travail de fond fait dès le départ.

Le vrai problème n'est pas l'outil

Face à un projet qui ne donne pas les résultats attendus, le réflexe est de chercher un meilleur outil. Une plateforme plus puissante, un modèle plus récent, un connecteur en plus. C'est rarement la bonne réponse.

Si 42 % des projets échouent, ce n'est pas parce que la technologie était insuffisante. C'est parce qu'on a sauté l'étape qui consiste à comprendre, avant de construire. La question à se poser n'est pas « quel outil ? » mais « est-ce que ce processus mérite d'être automatisé tel quel ? ».

Un bon audit répond à des questions simples mais souvent évitées : quelles tâches apportent réellement de la valeur, lesquelles sont des résidus historiques, où se trouvent les données, qui valide quoi, et quelles règles métier sont vraiment stables. Tant que ces réponses n'existent pas par écrit, automatiser revient à parier.

Un exemple concret

Prenons une PME de distribution B2B, 120 salariés. Elle veut automatiser le traitement de ses commandes entrantes : e-mails, PDF, parfois fax scannés. Le projet démarre côté technique, un agent est mis en place pour extraire les données et créer les commandes dans l'ERP.

Trois mois plus tard, le service client passe plus de temps à corriger les erreurs de l'agent qu'avant. Pourquoi ? Parce que personne n'avait documenté que 30 % des commandes contenaient des références client spécifiques, gérées à la main par deux personnes qui « connaissaient les clients ». Ce savoir tacite n'avait jamais été formalisé. L'automatisation l'a ignoré.

En reprenant le projet par le début — cartographier le flux réel, identifier les exceptions, structurer le référentiel produit et client — la même PME a pu automatiser 70 % des commandes de façon fiable, en laissant les 30 % restants en validation humaine assistée. Le bon périmètre, au lieu du périmètre maximal.

Cartographier et nettoyer avant d'automatiser

C'est la logique de la méthode Lynakor. Avant tout déploiement d'agents, nous menons un travail d'audit et de structuration. L'objectif : transformer votre organisation en organisation requêtable — un système où les processus sont documentés, les données structurées et les règles explicites.

Concrètement, cela veut dire trois étapes dans l'ordre :

• Cartographier les processus réels, pas ceux des procédures officielles, avec leurs exceptions et leurs zones grises.
• Nettoyer : supprimer les étapes inutiles, expliciter les règles tacites, structurer les données.
• Automatiser seulement ce qui est sain, stable et utile, avec une architecture documentée et supervisée.

Cette approche coûte un peu de temps en amont. Mais c'est précisément ce temps qui sépare les 42 % de projets qui échouent du reste. Automatiser n'est pas le point de départ. C'est l'aboutissement d'un travail de clarification.