Pourquoi les projets ERP échouent : les vraies causes

Vous avez forcément croisé le chiffre : « 70 % des projets ERP échouent ». Il ouvre la plupart des articles sur le sujet, avant de dérouler les mêmes conseils. Tel qu’il circule, ce chiffre veut dire peu de chose, et à force de brandir une statistique floue, on passe à côté de l’essentiel : à quoi ressemble un échec réel, pourquoi il se produit et comment le voir venir. Chez FiveForty, nous avons un point d’observation particulier, puisque nous reprenons des projets Dynamics 365 en difficulté. Ce qui suit décrit ce que l’on constate en ouvrant des projets qui ont déraillé.

Commençons par la vérification que personne ne fait. Le « 70 % » est un collage de sources qui ne mesurent ni la même chose, ni sur le même périmètre.

Le chiffre le plus souvent invoqué vient de McKinsey : environ 70 % des transformations échouent à atteindre leurs objectifs. Il porte sur les programmes de transformation en général, et pas spécifiquement sur les ERP. Gartner publie de son côté une prévision précise : d’ici 2027, plus de 70 % des projets ERP récemment déployés n’atteindront pas pleinement les objectifs de leur dossier d’investissement, et jusqu’à un quart échoueront gravement. Bain & Company indiquait en 2024 que 88 % des transformations d’entreprise n’atteignent pas leurs ambitions initiales.

D’où vient la confusion ? De la définition de l’échec. Selon les études, « échouer » peut signifier un abandon, un dépassement de budget ou de délai, ou des objectifs partiellement atteints. Gartner parle des objectifs du dossier d’investissement, Bain des ambitions initiales, et un projet arrêté avant le démarrage finit dans la même statistique qu’un projet livré en retard qui fonctionne.

Faut-il en conclure que le risque est exagéré ? Le chiffre exact reste inconnaissable, mais la réalité qu’il pointe est solide : quelle que soit l’étude, une part importante des projets ERP n’atteint pas ce qu’elle promettait. Le bon réflexe consiste donc à comprendre les mécanismes, qui se répètent avec une régularité remarquable.

L’échec spectaculaire, avec un projet abandonné ou un démarrage qui paralyse l’entreprise, existe mais reste minoritaire. La plupart des échecs que nous constatons sont silencieux, ce qui les rend dangereux.

Vert en comité, rouge sur le terrain

Les tableaux de bord affichent des jalons tenus et les comptes rendus rassurent, pendant que les ateliers patinent et que les décisions s’empilent sans être tranchées. Le décalage entre le reporting et la réalité peut durer des mois, parce que personne n’a intérêt à porter la mauvaise nouvelle. Quand il éclate, souvent à l’approche des tests ou de la bascule, il est tard et cher. Les signaux qui doivent alerter aident à le repérer avant.

Le projet « réussi » sur le papier

Le démarrage a eu lieu, le budget a à peu près tenu, et pourtant la valeur manque. Les utilisateurs contournent l’outil, les fichiers Excel ont survécu, les fonctionnalités payées dorment. Officiellement, ce projet ne figurera jamais dans les statistiques d’échec ; économiquement, c’en est un. Le reporting le plus trompeur est souvent celui de l’adoption : sur le papier, les équipes sont formées et l’outil est utilisé, alors que chacun est retourné à ses anciens fichiers.

Quand on reprend un projet en difficulté, on refait toujours le même chemin à rebours : les symptômes sont récents, les causes anciennes. Cinq familles reviennent systématiquement.

Une gouvernance qui filtre les mauvaises nouvelles

La technique lâche rarement en premier : le circuit de la vérité cède avant elle. Sponsor absent, comité qui enregistre au lieu d’arbitrer, indicateurs d’avancement déclaratifs, et le projet perd sa capacité à voir ses propres problèmes. Un pilotage digne de ce nom se juge à sa capacité à faire remonter tôt ce qui fâche.

Un cadrage expédié

Périmètre sans exclusions écrites, objectifs non mesurables, chiffrage sans hypothèses : les décisions esquivées au départ ressurgissent en cours de route, quand elles coûtent bien plus cher. Les projets que nous reprenons ont presque tous un dossier de cadrage mince, voire inexistant.

Les données traitées en fin de course

La reprise et la qualité des données sont reléguées après le paramétrage. Les tests déraillent alors sur des données fausses, les recettes ne prouvent rien, et le démarrage est repoussé ou risqué. C’est la cause technique la plus fréquente, et la plus évitable.

La sur-personnalisation

À force d’accepter chaque demande d’écart au standard, le projet construit un système unique, long à livrer, coûteux à tester et fragile à chaque mise à jour. Une partie de notre travail de reprise consiste précisément à défaire du spécifique pour revenir au standard.

L’humain compté pour zéro

Formation rognée, utilisateurs clés sans temps dédié, métier absent des ateliers : le système arrive dans des équipes qui ne l’attendent pas, l’adoption ne suit pas, et l’on retombe dans l’échec silencieux. L’étude de Bain le confirme : le meilleur prédicteur de réussite d’une transformation reste la capacité à mobiliser les bons talents sans surcharger les meilleurs. La formation des utilisateurs est le mécanisme qui transforme l’investissement en résultats.

Il manque un élément à cette liste : le choix de l’outil. Dans les projets que nous reprenons, la plateforme est rarement le problème ; c’est la façon dont le projet a été cadré et gouverné qui a déraillé. Ces causes-là se corrigent.

On mesure spontanément un échec ERP en budget consommé, la partie la plus visible. Dans les projets que nous reprenons, les coûts les plus lourds se trouvent ailleurs.

Le coût du temps

Chaque mois de dérive prolonge la double vie de l’entreprise, entre l’ancien système qu’il faut maintenir et le nouveau qu’il faut finir, avec des équipes mobilisées sur les deux.

Le coût humain

Des équipes projet usées et des utilisateurs clés démotivés laissent une confiance entamée, qui rendra le prochain projet plus difficile, quel qu’il soit.

Le coût d’opportunité

C’est le plus invisible : l’ouverture de filiale repoussée, l’obligation réglementaire traitée dans l’urgence, comme la facture électronique, ou l’acquisition qu’on n’ose pas intégrer parce que le socle n’est pas prêt.

Le coût de l’échec silencieux

Il se paie chaque mois : un système sous-exploité coûte sa licence complète pour une fraction de sa valeur.

La reprise de projets nous a forgé une conviction : intervenir tôt coûte toujours moins cher que laisser durer. Un diagnostic posé au début de la dérive se traduit par des ajustements ; le même diagnostic posé tard se traduit par une reconstruction.

C’est le cas d’école de l’échec ERP, tous éditeurs confondus : plier l’outil à chaque habitude de l’entreprise au lieu d’interroger les habitudes. Chaque développement spécifique paraît raisonnable pris isolément ; leur accumulation produit un système unique au monde, que personne ne sait plus tester ni faire évoluer sans risque.

Lidl en a fait l’expérience la plus chère connue. En 2018, l’enseigne a arrêté le remplacement de son système de gestion des marchandises après sept ans et environ 500 millions d’euros, selon le Handelsblatt. Elle pilotait ses stocks à partir des prix d’achat quand le logiciel standard raisonnait en prix de vente, et elle a préféré faire adapter le logiciel plutôt que de changer de méthode.

Dans l’univers Dynamics 365, la sanction est devenue mécanique. Avec One Version, Microsoft publie jusqu’à quatre mises à jour de service par an, dont au moins deux à installer, et une seule peut être repoussée à la suite. Chaque surcouche non standard doit donc être revalidée à chaque cycle. La discipline qui protège : exiger, pour chaque demande de spécifique, la démonstration que le standard ne sait pas faire et que le processus mérite d’être défendu tel quel.

Un projet bascule rarement d’un coup. Des signaux faibles précèdent la crise de plusieurs mois, et toute direction attentive peut les observer :

• des jalons éternellement « presque terminés » qui ne se ferment pas ;
• des comités qui se succèdent sans trancher une seule décision ;
• une liste de points ouverts qui s’allonge plus vite qu’elle ne se réduit ;
• le report répété de la première reprise de données réelle ;
• des équipes métier qui délèguent leur présence aux ateliers, puis n’y viennent plus ;
• un renouvellement fréquent dans l’équipe projet, côté client ou côté intégrateur.

Aucun de ces signaux n’est fatal isolément, mais leur accumulation ne pardonne pas. Plutôt que d’attendre le jalon suivant pour « voir », mieux vaut provoquer un diagnostic indépendant tant qu’il est encore temps de corriger la trajectoire sans tout arrêter.

Quand le calendrier serre, on rogne rarement sur les développements : on rogne sur les tests. Tests d’intégration écourtés, reprise de données validée sur un échantillon complaisant, scénarios de bout en bout jamais déroulés avec de vraies commandes ni de vraies clôtures. Le projet passe en production, et les défauts qu’on n’a pas cherchés se présentent d’eux-mêmes, au pire moment.

Microsoft en a fait un point de passage obligé : sa méthode Success by Design prévoit une revue de préparation au démarrage, qui vérifie notamment le plan de bascule, ses critères de décision et les répétitions de démarrage. Quand la phase de tests devient la variable d’ajustement du planning, l’échec est seulement différé, et c’est souvent là que commencent les histoires qui finissent en reprise de projet.

La symétrie est exacte : ce qui fait échouer les projets, inversé, décrit ce qui les fait réussir.

• Une gouvernance qui veut la vérité et la récompense.
• Un cadrage exigeant, avec des objectifs mesurables et des exclusions écrites.
• Les données traitées comme un chantier à part entière, dès le premier jour.
• Le standard de la plateforme comme point de départ, chaque écart devant se justifier par la valeur.
• Des tests protégés, jamais compressés pour tenir une date.
• Une adoption travaillée dans la durée, bien au-delà de la semaine du démarrage.

Et quand le projet est déjà en difficulté ? Un projet qui déraille peut être redressé. Diagnostiquer honnêtement, resserrer le périmètre, réordonner les chantiers et reconstruire la confiance des équipes forment un métier en soi, celui de la reprise de projets complexes. L’erreur la plus coûteuse consiste à laisser durer un projet en difficulté en espérant qu’il se redresse seul.

Le « 70 % d’échecs » est une statistique trop floue pour être utile, mais le risque qu’elle désigne est réel et ses causes sont précises : une gouvernance sourde aux mauvaises nouvelles, un cadrage esquivé, des données négligées, du spécifique accumulé, l’humain oublié. Toutes se voient venir, pour peu qu’on regarde les bons signaux plutôt que des tableaux de bord complaisants. La reprise de projets nous l’enseigne : les échecs ERP sont presque toujours des trajectoires, et une trajectoire se corrige.

FiveForty, spécialiste exclusif de Dynamics 365 Finance & Operations, intervient aux deux bouts de cette réalité : en amont, pour cadrer et piloter des projets solides, et en secours, pour reprendre ceux qui ont quitté la route. Si vous êtes en train de choisir un partenaire, notre guide pour choisir son intégrateur Dynamics 365 détaille les questions qui font la différence.

Votre projet montre ces symptômes ?

Recevez notre guide « Reprendre la main sur votre ERP » : auto-diagnostic en quatre familles de signaux. Et chaque vendredi, Le Vendredi ERP raconte les coulisses des projets ERP.

Recevoir le guide