Pourquoi 70 % des projets ERP échouent (et comment éviter ça)

La salle était pleine. La direction générale, le comité projet, les chefs de service, les intégrateurs. On présentait fièrement le nouvel ERP. Budget : 2,4 millions d’euros. Déploiement prévu en 18 mois. Trois ans plus tard, rien n’avait été livré. Les métiers refusaient le système. L’intégrateur accusait le client. Le client accusait l’intégrateur. Et l’IT… était aux abonnés absents.

Ce n’est pas une caricature. C’est une scène réelle. Et c’est exactement ce que j’ai retrouvé, sous différentes formes, dans plusieurs de mes missions de transition. Car les projets ERP ne meurent pas dans des explosions visibles. Ils s’éteignent à petit feu, étouffés par les compromis, les silences, les glissements progressifs.

Alors que se passe-t-il ? Pourquoi 70 % des projets ERP échouent ou déçoivent ? Et surtout : comment les sauver ?

D’abord, il faut comprendre une chose essentielle : un ERP n’est pas un projet IT. C’est un projet de transformation métier, piloté par la direction, vécu par les équipes, et supporté par l’IT. Quand il est pensé comme un chantier technique, il est condamné à échouer.

Dans mes interventions, je retrouve toujours les mêmes causes profondes de dérive.

Première cause : l’absence de sponsor clair et actif.

Un ERP transforme les processus, bouscule les habitudes, oblige à arbitrer. Sans un dirigeant sponsor qui prend les décisions difficiles, le projet devient un champ de bataille entre directions métier. Chacun défend sa version des choses. Personne ne tranche. Le système devient incohérent avant même d’être déployé.

Deuxième cause : une gouvernance trop lourde ou trop floue.

Trop de comités, trop de slides, trop de politique. Ou au contraire : aucun pilotage formel. Moi, je mets en place une gouvernance resserrée : un comité projet agile, une boucle de décision rapide, une cellule PMO qui suit la roadmap au jour le jour. L’ERP ne se pilote pas en regardant le tableau de bord tous les deux mois.

Troisième cause : une mauvaise conduite du changement.

Le projet est souvent présenté aux équipes comme un “mal nécessaire” ou un “outil imposé”. Résultat : ils freinent, sabotent parfois involontairement, ou “travaillent à côté”. Le secret ? Rendre le projet utile. Tangible. Porté par des ambassadeurs internes. Je crée des cas d’usage concrets, visibles, qui répondent à de vrais problèmes terrain.

Quatrième cause : un modèle de données bâclé.

L’ERP, c’est du code, mais surtout de la structure : clients, articles, fournisseurs, prix, nomenclatures. Si les données sources sont mal préparées, si les règles ne sont pas posées, si le nettoyage est sous-estimé, tout le projet devient une machine à erreurs. Je mets en place une task force data dès le début, avec un plan de migration et de contrôle rigoureux.

Cinquième cause : le “pilotage par l’intégrateur”.

Trop d’entreprises se reposent sur leur prestataire pour faire avancer le projet. Mais un intégrateur ne connaît ni vos métiers, ni votre culture, ni vos résistances internes. Il exécute. C’est à l’entreprise de piloter. En mission, je reprends ce rôle de chef d’orchestre : cadrage, priorisation, pression sur les délais, vérification de la qualité. Je protège le budget. Et je protège les métiers.

Sixième cause : le syndrome “on veut tout tout de suite”.

On lance l’ERP sur 12 filiales, 8 pays, 3 métiers et tous les modules. Forcément, ça échoue. Moi, je préconise toujours un déploiement progressif, avec une logique de “core model + local fit”. On stabilise un socle robuste, on en tire des retours, puis on étend. C’est plus lent… mais ça marche.

Quand je suis appelé sur un projet ERP en dérive, j’interviens comme relanceur stratégique. J’audite en 10 jours l’état réel du projet, ses blocages humains, ses risques techniques. Puis je construis une roadmap de sortie de crise, validée DG, DAF, métiers, IT et prestataires.

Ensuite, je m’implique : planification serrée, gouvernance resserrée, comité hebdo, animation des équipes, clarification des livrables. Je coupe ce qui est accessoire, je renforce les fondamentaux. Je mets de l’ordre, du rythme et du sens.

En moins de 100 jours, le projet reprend vie.

Les métiers voient leur quotidien amélioré. Les incidents diminuent. Les arbitrages sont pris. Le projet devient crédible. Et la direction reprend confiance.

Mais attention : un ERP ne réussit jamais par hasard. Il demande du courage, de la méthode, de l’humilité. Et surtout : un pilotage fort, incarné, transversal.

Un DSI de transition n’est pas là pour “changer d’outil”.

Il est là pour remettre de la cohérence, du sens et de la valeur dans un système qui s’était déconnecté de ses objectifs.