On attribue volontiers les échecs de projets ERP à l'outil, ou au prestataire. C'est rarement exact. Les sept causes ci-dessous sont des décisions — prises tôt, souvent pour de bonnes raisons, et coûteuses ensuite.
Chacune a un signal d'alerte reconnaissable, et un remède qui fonctionne encore si on l'applique à temps.
L'essentiel
- Périmètre trop large : vingt modules activés le premier jour, rien en service au bout de trois mois.
- Personne pour trancher : le projet s'arrête au premier désaccord entre deux services.
- Reprise de tout l'historique : le poste le plus coûteux et le moins utile.
- Reproduire l'ancien outil : chaque écart devient une dette à chaque montée de version.
- Formation après la bascule : elle arrive quand les contournements sont déjà installés.
- Tableaux de bord trop tôt : ils affichent des chiffres faux, et ne seront plus consultés.
- Aucune date de bascule : la double saisie s'installe, et les deux systèmes divergent.
Les sept erreurs, leur signal et leur remède
| Erreur | Signal d'alerte | Remède |
|---|---|---|
| Périmètre trop large | Aucune facture réelle émise après 3 semaines | Réduire à 6 modules, dans l'ordre |
| Pas de décideur | Une question ouverte depuis 15 jours | Désigner une personne dont la décision s'applique |
| Reprise de tout l'historique | On parle d'import avant de parler de flux | Soldes d'ouverture + encours + exercice en cours |
| Reproduire l'ancien outil | « Comme dans notre ancien logiciel » | Trois mois sur le standard, puis on arbitre |
| Formation tardive | La bascule est faite, la formation est « prévue » | Former 2 à 5 jours avant |
| Tableaux de bord trop tôt | La direction demande des indicateurs en semaine 2 | Trois indicateurs, au mois 3 |
| Pas de date de bascule | Double saisie depuis plus de 3 semaines | Fixer une date ferme, en période calme |
La colonne du milieu est la plus utile : ce sont des signaux observables, qui ne demandent ni audit ni réunion. Si l'un d'eux est vrai chez vous aujourd'hui, le remède correspondant s'applique encore.
La plus coûteuse : l'absence de décideur
C'est le facteur de réussite le plus net que nous observions, toutes tailles d'entreprise confondues. Et ce n'est pas un rôle technique.
Un projet ERP met en concurrence des façons de faire : la comptabilité veut une numérotation, le commerce en veut une autre ; le magasin veut un emplacement par allée, la direction veut un stock global. Ces arbitrages ne sont pas techniques, et le prestataire ne peut pas les faire à votre place.
Sans une personne dont la décision s'applique, un projet ERP n'avance pas : il attend. Et il attend sur des sujets que personne ne juge assez importants pour provoquer une réunion.
Ce que fait cette personne : elle tranche en moins de 48 heures, elle connaît le métier, et son arbitrage n'est pas rediscuté. Ce qu'elle n'est pas : un chef de projet à temps plein, ni nécessairement un dirigeant.
La plus séduisante : reprendre tout l'historique
Elle est séduisante parce qu'elle paraît prudente. Elle est coûteuse parce que les données anciennes n'ont pas été conçues pour le modèle neuf : chaque champ demande une décision, chaque exception un traitement.
Ce que l'on consulte réellement, c'est l'encours et l'exercice en cours. Le reste sert une ou deux fois par an, et peut rester consultable dans l'ancien système, conservé en lecture seule — ce qui est légal, moins cher et plus sûr.
- À reprendre : clients et fournisseurs avec leurs SIREN, articles, soldes comptables d'ouverture, encours clients et fournisseurs, pièces de l'exercice en cours.
- À laisser : les factures des exercices clos, les devis non suivis d'effet, les contacts inactifs depuis trois ans.
Un bénéfice indirect : la reprise est l'occasion de nettoyer. Les SIREN manquants, par exemple, sont devenus la clé de routage de vos factures électroniques, et un import est le moment le moins coûteux pour les renseigner. Voir l'annuaire et les SIREN.
La plus durable : reproduire l'ancien outil
Celle-ci ne fait pas échouer le projet : elle le rend cher pour toujours. Chaque écran reproduit à l'identique devient un développement, et chaque développement une recette à chaque montée de version.
La question qui désamorce la plupart des demandes tient en une phrase : que se passe-t-il si on fait comme le standard pendant trois mois ? Elle transforme un débat de principe en expérience datée, et la réponse est souvent « rien ».
La règle que nous appliquons : aucun développement spécifique pendant les trois premiers mois. Au bout de trois mois, la liste restante est courte, argumentée, et ce qui est développé alors est réellement utilisé. Voir personnaliser ou rester sur le standard.
La plus silencieuse : pas de date de bascule
Personne ne décide de ne pas basculer. On décide de « faire tourner les deux en parallèle le temps d'être sûr », et le temps passe.
Deux effets se produisent, et le second est irréversible :
- La double saisie épuise les équipes. Elles font deux fois le même travail, et elles le disent de moins en moins fort.
- Les deux systèmes divergent. Au bout de six semaines, personne ne sait lequel fait foi — et la bascule devient plus difficile qu'au premier jour.
Le remède : une date ferme, annoncée, en période calme — jamais en clôture ni en haute saison. Une à deux semaines de parallèle, pas davantage. Et un retour arrière préparé, qui rassure sans servir.
Ce qui marche, en une phrase chacun
- Six modules, dans l'ordre : contacts, ventes, facturation, comptabilité, achats, puis le module métier.
- Une personne qui tranche, en moins de 48 heures.
- Une reprise minimale : soldes, encours, exercice en cours.
- Trois mois sur le standard avant tout développement.
- Former par métier, sur les vrais dossiers, avant la bascule.
- Trois indicateurs au mois 3, pas quinze en semaine 2.
- Une date de bascule ferme, en période calme.
Aucun de ces sept points n'est technique, et c'est le constat le plus utile de cet article. Voir par où commencer une digitalisation et faire adopter l'outil par les équipes.
Questions fréquentes
Quelle est la première cause d'échec d'un projet ERP ?
L'absence d'une personne habilitée à trancher. Un projet ERP met en concurrence des façons de faire entre services, et ces arbitrages ne sont ni techniques ni délégables au prestataire. Sans décideur, le projet n'échoue pas brutalement : il attend, sur des sujets que personne ne juge assez importants pour provoquer une réunion.
Faut-il reprendre tout l'historique dans le nouvel ERP ?
Non, et c'est rarement souhaitable. Reprenez les soldes d'ouverture, les encours clients et fournisseurs, et les pièces de l'exercice en cours. Le reste demeure consultable dans l'ancien système conservé en lecture seule, ce qui est légal, moins cher et plus sûr.
Combien de temps faire tourner l'ancien et le nouveau système en parallèle ?
Une à deux semaines. Au-delà, la double saisie épuise les équipes et les deux systèmes divergent au point que personne ne sait lequel fait foi — la bascule devient alors plus difficile qu'au premier jour.
Quand mettre en place les tableaux de bord ?
Au bout de deux à trois mois d'exploitation réelle, avec trois indicateurs. Plus tôt, ils affichent des chiffres faux parce que les données n'existent pas encore — et un tableau de bord qui a affiché un chiffre faux une fois ne sera plus consulté.
Faut-il un chef de projet dédié dans une PME ?
Pas à temps plein. Il faut quelqu'un qui connaît le métier, qui tranche en moins de 48 heures, et dont l'arbitrage n'est pas rediscuté. C'est une autorité de décision, pas une charge de travail — et c'est le facteur de réussite le plus net.
Pour aller plus loin
- Par où commencer une digitalisation de PME
- Les 6 modules par lesquels commencer
- Faire adopter l'outil par ses équipes
En résumé
Aucune des sept erreurs n'est technique. Réduisez le périmètre à six modules, désignez une personne qui tranche, reprenez le minimum, restez trois mois sur le standard, formez avant la bascule, attendez le mois 3 pour les indicateurs, et fixez une date ferme. Parlons de votre projet.
