Pourquoi les projets ERP échouent : les vraies causes

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, agité comme un épouvantail avant de dérouler les mêmes conseils. Le problème, c’est que ce chiffre, tel qu’il circule, ne veut pas dire grand-chose. Et qu’à 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 : nous reprenons des projets Dynamics 365 en difficulté. Ce que nous décrivons ici n’est pas une théorie, c’est ce que l’on constate en ouvrant le capot de projets qui ont déraillé. Voici ce que les statistiques ne disent pas.

Que vaut vraiment le fameux « 70 % d’échecs » ?

Commençons par le fact-checking que personne ne fait. Le « 70 % » est en réalité 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. Mais il porte sur les programmes de transformation en général, pas spécifiquement sur les projets ERP. Gartner est cité tantôt pour des taux d’échec « dépassant 75 % », tantôt pour un constat très différent : moins de la moitié des projets atteignent ou dépassent leurs cibles. Bain avance de son côté que 88 % des transformations d’entreprise n’atteignent pas leurs ambitions initiales. Et de vieilles enquêtes sur les projets informatiques concluent prudemment qu’« au moins la moitié » des projets ERP déçoivent.

D’où vient la confusion ? De la définition de l’échec. Selon les études, « échouer » peut signifier un abandon pur et simple, un dépassement de budget ou de délai, ou simplement des objectifs partiellement atteints. Entre un projet arrêté avant le go-live et un projet livré avec six mois de retard mais qui fonctionne, il y a un monde ; les statistiques agrégées les mettent pourtant dans le même sac.

Faut-il en conclure que le risque est exagéré ? Non, et c’est le point important : le chiffre exact est 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. Simplement, le bon réflexe n’est pas de retenir un pourcentage : c’est de comprendre les mécanismes. Car eux, contrairement aux statistiques, se répètent avec une régularité remarquable.

À quoi ressemble un échec ERP, en vrai

Deuxième idée reçue à corriger : l’échec spectaculaire (le projet abandonné, le go-live catastrophique qui paralyse l’entreprise) existe, mais il est minoritaire. La plupart des échecs que nous constatons sont silencieux, et c’est ce qui les rend dangereux.

Le plus répandu est le projet « vert en comité, rouge sur le terrain ». Les tableaux de bord affichent des jalons tenus, les comptes rendus sont rassurants, et pendant ce temps les ateliers patinent, les décisions s’empilent sans être tranchées, les équipes métier décrochent. 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.

L’autre échec silencieux est le projet « réussi » sur le papier : le go-live a eu lieu, le budget a tenu à peu près, et pourtant la valeur n’est pas là. Les utilisateurs contournent l’outil, les fichiers Excel ont survécu, les fonctionnalités payées ne sont pas utilisées. Officiellement, ce projet ne figurera jamais dans les statistiques d’échec. Économiquement, c’en est un.

Les vraies causes, vues depuis la reprise de projets

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

• Une gouvernance qui filtre les mauvaises nouvelles. Ce n’est presque jamais la technique qui lâche en premier, c’est le circuit de la vérité. Sponsor absent, comité qui enregistre au lieu d’arbitrer, indicateurs d’avancement déclaratifs : le projet perd sa capacité à voir ses propres problèmes. Un pilotage digne de ce nom se juge à sa capacité à faire remonter ce qui fâche, tôt.
• Un cadrage expédié. Périmètre sans exclusions écrites, objectifs non mesurables, chiffrage sans hypothèses : toutes les décisions esquivées au départ ressurgissent en cours de route, au moment où elles coûtent dix fois plus cher. Les projets que nous reprenons ont presque tous un dossier de cadrage mince, ou pas de dossier du tout.
• 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 ». Résultat : des tests qui déraillent sur des données fausses, des recettes qui ne prouvent rien, et un démarrage repoussé ou risqué. C’est la cause technique la plus fréquente, et la plus évitable.
• La sur-personnalisation. À force de dire oui à 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étricoter 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 sur l’échec silencieux décrit plus haut. La formation n’est pas un poste de budget, c’est le mécanisme qui transforme l’investissement en résultats.

On remarquera ce qui manque à cette liste : le choix de l’outil. Dans les projets que nous reprenons, la plateforme est rarement le problème. C’est presque toujours la façon dont le projet a été cadré, gouverné et incarné qui a déraillé. Bonne nouvelle, d’ailleurs : ces causes-là se corrigent.

Ce qu’un échec coûte vraiment

On mesure spontanément un échec ERP en budget consommé, et c’est la partie la plus visible. Mais dans les projets que nous reprenons, les coûts les plus lourds sont ailleurs.

Il y a d’abord le coût du temps : chaque mois de dérive prolonge la double vie de l’entreprise, l’ancien système qu’il faut maintenir et le nouveau qu’il faut finir, avec des équipes mobilisées sur les deux. Il y a ensuite le coût humain : des équipes projet usées, des utilisateurs clés démotivés, et une confiance entamée qui rendra le prochain projet plus difficile, quel qu’il soit. Il y a le coût d’opportunité, le plus invisible : l’ouverture de filiale repoussée, l’obligation réglementaire traitée dans l’urgence, l’acquisition qu’on n’ose pas intégrer parce que le socle n’est pas prêt. Et il y a le coût de l’échec silencieux, qui se paie chaque mois : un système sous-exploité facture sa licence complète pour une fraction de sa valeur.

Ce chiffrage explique une conviction que la reprise de projets nous a forgée : intervenir tôt coûte toujours moins cher que laisser durer. Un diagnostic à trois mois de dérive se traduit par des ajustements ; le même diagnostic à dix-huit mois se traduit par une reconstruction.

Les signaux d’alerte qui précèdent la crise

Un projet ne bascule jamais d’un coup. Des signaux faibles précèdent la crise de plusieurs mois, et ils sont observables par toute direction attentive. Des jalons éternellement « à 90 % » 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 turnover qui s’installe dans l’équipe projet, côté client ou côté intégrateur. Aucun de ces signaux n’est fatal isolément ; leur accumulation, elle, ne pardonne pas. Le bon réflexe n’est pas d’attendre le jalon suivant pour « voir », c’est de provoquer un diagnostic indépendant pendant qu’il est encore temps de corriger la trajectoire sans tout arrêter.

Ce qui sauve les projets

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 ; Microsoft propose d’ailleurs avec Success by Design un cadre public de revues qui structure exactement cela. Les données traitées comme un chantier à part entière, démarré dès le premier jour. Le standard de la plateforme comme point de départ, l’écart devant se justifier par la valeur. Des tests sanctuarisés, jamais compressés pour tenir une date. Et une adoption travaillée dans la durée, pas expédiée la semaine du go-live.

Et quand le projet est déjà en difficulté ? Il faut savoir qu’un projet qui déraille n’est pas condamné. Diagnostiquer honnêtement, resserrer le périmètre, réordonner les chantiers, reconstruire la confiance des équipes : c’est un métier en soi, celui de la reprise de projets complexes. L’erreur la plus coûteuse n’est pas d’avoir un projet en difficulté, c’est de le laisser durer en espérant qu’il se redresse seul.

Conclusion

Le « 70 % d’échecs » est une statistique trop floue pour être utile, mais le risque qu’elle désigne est réel, et il a des causes précises : une gouvernance qui n’entend pas la vérité, un cadrage esquivé, des données négligées, du spécifique accumulé, l’humain compté pour zéro. Aucune de ces causes n’est une fatalité ; toutes se voient venir, pour peu qu’on regarde les bons signaux plutôt que les tableaux de bord complaisants. C’est peut-être la leçon la plus utile de la reprise de projets : les échecs ERP ne sont presque jamais des accidents. Ce sont des trajectoires, et une trajectoire, ça 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 qui ne dérailleront pas, et en secours, pour reprendre ceux qui ont déjà quitté la route.