Un projet ERP, c’est un chantier noble : on remet de l’ordre dans les processus, on fiabilise les données, on prépare l’entreprise pour grandir. Sur le papier, tout le monde est pour. Dans la vraie vie, l’ERP est aussi un révélateur : il met en lumière les zones grises, les habitudes, et le fameux : “oui mais nous on fait différemment” (phrase officiellement classée “haut potentiel de dérapage planning”).
La bonne nouvelle : les projets ERP réussissent très souvent pour les mêmes raisons. La moins bonne : ils dérapent aussi… pour des raisons tout aussi répétitives. Alors on fait simple, concret, et actionnable — avec un petit sourire, parce que sinon on pleure.
Pourquoi un projet ERP échoue rarement à cause du logiciel
On accuse parfois l’outil : “l’ERP n’est pas adapté”. En réalité, la majorité des difficultés viennent de choses très humaines : la gouvernance (qui décide ?), le rythme (est-ce qu’on avance régulièrement ?), la disponibilité (est-ce qu’on a du temps, vraiment ?), et la clarté des objectifs (où va-t-on ?).
Un ERP, c’est comme une partition : même la meilleure n’aura pas de musique si l’orchestre ne répète pas ensemble. Et si le batteur ne vient qu’un mardi sur deux, on obtient un concept inédit : le jazz administratif.
Les 5 facteurs clés du succès : de la slide à la réalité
Une Direction Générale impliquée (pas seulement “au courant”)
Un ERP touche aux fondations : ventes, achats, stock, comptabilité, production, service… Donc : c’est un projet d’entreprise, pas un projet “informatique”.
L’implication de la Direction Générale est déterminante pour :
donner une priorité claire au projet,
arbitrer quand les services ne sont pas d’accord,
éviter l’effet “on veut tout” (et donc on n’obtient rien),
sécuriser les ressources et la disponibilité des équipes.
Le bon niveau d’implication :
un sponsor identifié,
des points de pilotage réguliers,
une capacité d’arbitrage rapide.
Sans cela, le projet avance… mais avec le frein à main.
Un point de contact unique avec une vraie vision métier
Il faut une personne (ou un binôme) qui porte la vision métier et centralise les décisions : chef de projet interne, responsable transformation, référent transverse, Product Owner…
Son rôle n’est pas “d’être partout”, mais de garantir :
une cohérence globale des flux,
une priorisation claire,
des validations rapides,
un langage commun entre métiers et intégrateur.
Sans point de contact unique, on obtient souvent :
des validations à 10 personnes,
des retours contradictoires,
des décisions qui changent selon l’interlocuteur,
et beaucoup de rework.
Traduction : l’ERP devient un mille-feuille. C’est riche… mais personne n’a demandé ça pour le petit-déjeuner.
Une équipe projet disponible (un projet à 5% avance à 5%… mais ne coûte pas à 5%)
C’est le nerf de la guerre. Un ERP demande des ateliers, des validations, des tests, des reprises de données, de la formation, de la conduite du changement.
Si les key users et référents métiers ne sont disponibles que “quand ils peuvent”, le projet subit un phénomène très coûteux : l’avancement par à-coups. On croit économiser du temps en “faisant au fil de l’eau”. En réalité, on paie une taxe invisible : la taxe de redémarrage.
Chez Auguria, on fait systématiquement des comptes rendus… mais ce n’est pas suffisant
Les comptes rendus sont indispensables : ils clarifient et sécurisent. Mais un CR raconte ce qui s’est dit. Or, un ERP a surtout besoin qu’on conserve ce qui a été décidé, pourquoi, et ce que ça implique ensuite.
Sans rythme, même de très bons comptes rendus ne suffisent pas à empêcher la perte de contexte.
Pourquoi le manque de disponibilité coûte beaucoup plus cher
On perd du temps à se “reconnecter”.
Quand le projet s’interrompt régulièrement, chaque reprise implique recontextualisation, relecture des CR, rappels de décisions, réexplications. Ce temps n’ajoute aucune valeur… mais il se répète.
Les décisions arrivent trop tard : on attend ou on avance “au hasard”.
Un ERP avance à la vitesse des arbitrages métiers (règles, exceptions, validations). Sans disponibilité, l’intégrateur attend ou avance sur hypothèses — puis reprend. Dans un cas on paye l’attente, dans l’autre on paye la correction. Souvent les deux.
On fait et on défait (et on finit par payer deux fois).
Les validations tardives entraînent ajustements de paramétrage, retouches, reprise des tests, parfois reprise de la formation. Le rework est un des plus gros postes de surcoût.
Les tests utilisateurs deviennent chaotiques.
Sans disponibilité, les anomalies s’accumulent, les corrections arrivent en rafale, la mise en production devient stressante, et le planning se dégrade.
La reprise de données se dégrade.
Sans temps métier pour nettoyer et fiabiliser, on importe des données “pas propres” et on corrige après — ce qui coûte plus cher et perturbe l’exploitation.
Des objectifs clairs et formalisés (sinon, c’est “installer un ERP”)
“Mettre en place un ERP” n’est pas un objectif, c’est un moyen.
Un projet ERP doit être guidé par quelques objectifs simples, compréhensibles et mesurables, par exemple :
réduire le délai de facturation,
fiabiliser le stock et diminuer les écarts,
standardiser le cycle achats,
réduire les ressaisies,
améliorer le reporting (J+3 au lieu de J+15),
accélérer le traitement des commandes.
Pourquoi c’est vital : cela permet de prioriser, d’éviter l’empilement de demandes non essentielles, et de garder un cap quand il faut arbitrer.
Un planning ambitieux mais réaliste (l’ERP déteste les marathons sans eau)
Un bon planning ERP n’est ni une promenade du dimanche, ni un sprint suicidaire.
Il doit intégrer :
la charge interne (ateliers, validations, tests),
les contraintes business (pics d’activité, clôtures),
des jalons de décision,
des livrables réguliers.
Le risque d’un planning trop long : le projet s’étale, les équipes décrochent, et les décisions se diluent.
Le point d’attention qui change tout : les coupures régulières font perdre le fil
Quand un projet ERP subit des “stop & go”, il perd son rythme, sa mémoire, sa dynamique. Et surtout, il prend un risque fort : la perte d’information.
Un mois sans travailler sur un projet coûte cher
Soyons clairs : un mois sans activité, ce n’est pas “neutre”. C’est un redémarrage coûteux (recontextualisation, revalidation), des sujets qui se rouvrent, des décisions qui se contredisent, et du rework qui apparaît “comme par magie”. (La magie, ici, c’est surtout celle de la facture.)
Le risque de perte d’information : réel et dangereux
Perte de contexte : on oublie pourquoi une décision a été prise.
Décisions implicites non tracées : “ok on fait comme ça”… puis plus personne ne s’en souvient.
Absences / turnover : un référent change, un responsable part, et une partie du projet disparaît avec lui.
Réouverture des sujets : faute de trace, on rediscute, on retarde, on refait.
Conséquence : incohérences, retards, rework… et stress au Go-live.
Comment sécuriser la réussite (conseils simples)
Pour éviter le projet “en pointillés”, quelques pratiques très efficaces :
Rythme stable : même léger, mais continu (ateliers + validations + avancées chaque semaine).
Journal des décisions : qui a tranché quoi, quand, pourquoi (et impacts).
Backlog priorisé : ce qui est important maintenant vs plus tard.
Livrables fréquents : valider quelque chose toutes les 2–3 semaines.
Disponibilité planifiée : du temps réservé dans les agendas, pas “quand on peut”.
Conclusion : un ERP réussi, c’est une affaire de gouvernance et de rythme
Les facteurs clés sont simples :
une Direction Générale impliquée,
un point de contact unique avec vision métier,
une équipe projet disponible,
des objectifs clairs,
un planning ambitieux mais réaliste,
et un rythme sans coupures répétées.
Le message à retenir : un projet ERP avec peu de disponibilité ne ralentit pas seulement. Il coûte plus cher, parce qu’il génère de l’attente, du rework, des tests chaotiques, une reprise de données dégradée… et un risque élevé de perte d’information.
Si vous voulez mettre toutes les chances de votre côté, le meilleur investissement n’est pas une “fonction en plus”. C’est un projet cadré, rythmé, et porté par l’entreprise.