Pourquoi les projets ERP perdent le contrôle malgré des tableaux de bord au vert

La plupart des projets ERP n’échouent pas brutalement

Ils dérapent progressivement.

Les jalons sont « respectés ».
Les tests « avancent ».
Les rapports d’avancement restent au vert.

Puis, quelques mois plus tard, les délais s’allongent, les coûts explosent, et la direction se demande comment la situation a pu se dégrader aussi vite.

Dans la majorité des cas, les signaux d’alerte étaient déjà présents.
Ils n’étaient simplement pas visibles dans le reporting classique.

Le vrai problème n’est pas l’exécution, mais la fausse impression de contrôle

Les programmes ERP échouent rarement parce que les équipes cessent de travailler.
Ils échouent parce que l’exécution continue alors que le contrôle se dégrade.

Les tableaux de bord mesurent l’activité.
Ils ne mesurent pas le risque structurel.

Voici les schémas récurrents que l’on retrouve dans les projets qui dépassent les délais et les budgets, même lorsque tout semble maîtrisé en apparence.

1. Le projet avance alors que des dépendances critiques restent non résolues

C’est l’un des signaux les plus précoces — et les plus dangereux.

On le retrouve notamment lorsque :

• des données de référence ne sont pas validées de bout en bout,
• la décommission des systèmes existants est supposée, mais non séquencée,
• des prérequis réglementaires, d’audit ou techniques sont reportés « à plus tard ».

Le projet progresse, mais sur des fondations instables.
Cela crée une illusion d’avancement, alors que le risque s’accumule silencieusement.

2. La préparation financière est technique, pas opérationnelle

Les rapports existent.
Les chiffres s’alignent.

Mais si la fonction Finance n’a pas validé les états critiques avec des données réelles comme étant exploitables pour la prise de décision, l’organisation n’est pas prête.

Ce décalage apparaît presque toujours tardivement — en UAT, en phase de double run ou juste après le go-live — lorsque les corrections deviennent coûteuses et que la crédibilité est déjà entachée.

3. Les tests valident l’effort, pas la réalité

Des scénarios scriptés confirment que des étapes peuvent être exécutées.
Ils ne confirment pas que le système fonctionne dans des conditions réelles.

Un indicateur fort de dérive future est un dispositif de tests qui :

• évite les rôles de sécurité réels,
• utilise des données simplifiées ou nettoyées,
• cherche à confirmer que « tout marche » plutôt qu’à révéler les failles.

Lorsque les tests sont conçus pour valider le succès, les défauts structurels restent invisibles… jusqu’à ce qu’il soit trop tard.

4. La responsabilité est diluée, plus qu’absente

Les projets en difficulté ne manquent pas de gouvernance.
Ils manquent d’un responsable clairement identifié en cas d’échec.

Une question simple permet de le vérifier immédiatement :

Si le projet prend trois mois de retard, qui expliquera personnellement pourquoi à la direction générale ?

Si la réponse est floue, partagée ou conditionnelle, le contrôle est déjà fragilisé — quel que soit le niveau de maturité des comités en place.

5. Les acteurs clés sont engagés sur le papier, pas dans les faits

Beaucoup de projets supposent une disponibilité métier sans la sécuriser réellement.

Les utilisateurs clés participent aux ateliers, mais continuent d’assurer l’opérationnel.
Les décisions ralentissent.
La qualité des tests se dégrade.
La fatigue s’installe.

Lorsque le manque de capacité devient visible, le projet est déjà affecté.

6. L’entreprise évolue, mais le plan reste figé

Réorganisations, contraintes budgétaires, acquisitions ou changements stratégiques n’arrêtent pas les projets ERP.

Ils sont absorbés… de manière informelle.

Lorsque le plan projet ne reflète plus la réalité de l’entreprise, les indicateurs restent au vert par inertie — jusqu’au moment où ils ne peuvent plus masquer la dérive.

7. Les fonctions de contrôle sont informées, pas réellement engagées

Juridique, Audit interne, Sécurité, Achats, Conformité bloquent rarement les projets au début.

Ils les bloquent à la fin.

Lorsqu’ils sont consultés tardivement, les reprises, retards et surcoûts deviennent inévitables.
Le risque n’est pas l’opposition, mais le moment où elle survient.

Une règle simple à garder en tête

Une règle se vérifie presque systématiquement dans les programmes ERP :

S’il n’y a pas une personne clairement responsable d’expliquer un échec, et si les ressources clés ne sont pas réellement disponibles, le projet n’est plus en conditions de pilotage maîtrisé — quels que soient les tableaux de bord.

Détecter tôt préserve les options.
Découvrir tard les supprime.

Le contrôle est plus facile à restaurer avant d’être visiblement perdu

La plupart des projets ERP n’échouent pas par manque d’engagement ou d’efforts.

Ils échouent parce qu’ils continuent d’avancer alors qu’un arrêt temporaire aurait permis de reprendre le contrôle.

Plus ce moment est identifié tôt, plus la direction conserve de marge de manœuvre.

Cet article fait partie de la série FitGap™ Finance — une approche pragmatique et orientée métier de la gouvernance ERP, de la prise de décision et du contrôle au-delà du go-live.

🇬🇧 Version anglaise disponible ici : https://www.fitgapfinance.com/erp-projects-lose-control-dashboards-green/