Déploiement ERP : 7 symptômes que les Projets en Échec ont en Commun
Déploiement ERP : 7 signaux d’échec que personne ne voulait voir
Les patterns structurels d’un projet qui dérape. Et la fenêtre d’intervention que personne n’ouvre à temps.
Le projet est officiellement « vert ». Le planning tient. Les Steering Committees valident. L’intégrateur livre ses rapports dans les délais.
Et pourtant, tout le monde sait.
Le chef de projet qui ne regarde plus personne dans les yeux. Les Key Users « en urgence opérationnelle » depuis 3 mois. Le registre des risques ouvert en janvier, jamais retouché.
Selon Panorama Consulting Group (2024), 68% des projets ERP dépassent leur budget initial. Gartner estime que plus de la moitié n’atteignent pas leurs objectifs. Ces chiffres ne font pas les manchettes. Ils s’enterrent dans des bilans internes que personne ne partage.
En plus de 20 ans d’interventions sur des programmes SI (de l’aérospatial à l’agroalimentaire, en Europe et aux Etats-Unis), j’ai appris une chose : les mêmes patterns se répètent. Un projet D365 F&O qui dérape en 2025 reproduit exactement la cinématique d’un déploiement SAP raté en 2018. Le déni, l’atterrissage brutal : même séquence, mêmes acteurs.
Voici les 7 signaux que j’ai vus, à chaque fois.
1. Le planning est « vert » mais personne ne croit aux dates
C’est ma signature de diagnostic. La première chose que je regarde.
Tout est vert sur le tableau de bord. En réunion, quand on pose la question directe (« Est-ce qu’on va tenir le Go Live ? »), les regards se détournent. Personne ne dit non, et personne ne dit oui non plus.
Dans un déploiement ERP, le Green Status est une convention sociale avant d’être un outil de pilotage. Passer en rouge, c’est déclencher une escalade. Alors on ajuste les critères de complétion. On repousse les jalons d’une semaine à la fois. On rebaptise un retard en « recalage du planning ».
J’ai vu un déploiement ERP piloté par un Big4 où tous les indicateurs sont restés au vert pendant 18 mois. Sur le terrain, aucun test de bout en bout n’avait été validé avec des données réelles. Le projet vivait dans une simulation parfaite, déconnectée de l’activité, jusqu’au crash de la mise en service.
Le seuil critique : tant que l’écart entre planning affiché et planning réel reste sous les 20%, le projet est récupérable. Au-delà, on ne redresse plus. On limite les dégâts.
2. Le conflit intégrateur vit dans les couloirs, le périmètre dérive en silence
Je fusionne volontairement 2 signaux ici, parce qu’ils se nourrissent l’un l’autre.
Le conflit invisible. Les réunions officielles sont cordiales. Les comptes-rendus sont lisses. Mais dans les mails de fin de soirée, le ton change. Le ton change : accusations croisées sur le périmètre, disputes sur les TMA, reproches sur les livrables. Formaliser ce conflit, c’est risquer d’activer des clauses contractuelles. Alors la direction « gère la relation ». On lisse. On évite.
Le scope creep silencieux. En parallèle, sprint après sprint, de petites adaptations s’accumulent. « Exception métier » ici, « ajustement mineur » là. Cumulées sur 6 mois : 30% de charge supplémentaire non budgétée. Le métier obtient ses adaptations. L’intégrateur facture. Personne n’a intérêt à consolider le total.
Le mécanisme est le même : ce qui n’est pas documenté ne se résout pas, ça grossit. Un conflit non formalisé et un changement de périmètre non tracé par Change Request produisent le même effet. Une dette invisible qui explose au moment du Go Live.
3. La migration de données n’a ni responsable ni Data Owner
De tous les signaux d’un déploiement ERP, c’est celui qui fait le plus de dégâts. Et le plus silencieux.
Sur une migration récente dans le secteur manufacturier, nous avons découvert que 40% des nomenclatures produits n’existaient que dans les fichiers Excel personnels des opérationnels. Le système legacy ne contenait qu’une fraction de la réalité opérationnelle. On a passé 6 mois à parler de « complexité de mapping » plutôt que d’admettre le vrai problème : le socle de données de l’entreprise était devenu une tradition orale.
Il y a toujours une ligne dans le RACI. Mais quand on demande « Qui est responsable de la qualité des données sources ? », l’intégrateur pointe vers le client. Le client pointe vers l’IT. L’IT pointe vers le métier.
La règle est simple : si la propriété des données n’est pas assignée nominativement (un nom, pas une fonction) avant la fin de la phase Design, la migration sera en retard. C’est une certitude statistique sur 20 ans de projets.
Test rapide à faire lundi matin
Posez cette question en réunion : « Qui signe personnellement la qualité des données de migration ? »
Si la réponse prend plus de 5 secondes, vous avez votre signal.
4. Le SteerCo valide sans décider : le théâtre de la gouvernance
Les slides défilent, les indicateurs sont verts, la DSI hoche la tête. 45 minutes plus tard, c’est plié. Personne n’a posé une seule question de fond.
J’appelle ça le théâtre de la gouvernance : le Comité de Pilotage se transforme en chambre d’enregistrement de diapositives lissées. On valide la forme pour éviter de trancher le fond. Le rituel de la réunion l’emporte sur l’arbitrage du réel.
Les executives n’ont pas le temps de creuser. Questionner, c’est risquer de paraître ignorant du détail technique. Valider, c’est déléguer la responsabilité vers le bas. C’est confortable. C’est mortel pour le projet.
Un Steering qui ne pose jamais de questions difficiles n’exerce pas de gouvernance. Il fournit une couverture institutionnelle.
Vous reconnaissez ces signaux ? Si vous en avez identifié 3 ou plus dans votre programme en cours, la fenêtre d’intervention est encore ouverte, mais elle se referme vite. Parlons-en.
5. Pas de critères Go/No-Go : on avance à l’inertie
Ce signal est le plus sous-estimé. Tout le monde parle du Go Live. Personne n’a défini les conditions du No-Go.
Sans critères explicites et mesurables (taux de complétion des tests, volumétrie de migration validée, formation des utilisateurs certifiée), la décision de passer en production sur un déploiement ERP devient politique. On y va parce qu’on a annoncé la date, et parce que revenir en arrière coûterait trop cher en crédibilité.
Le fiasco Phoenix au Canada (un système de paie fédéral déployé sans que les signaux d’alerte des phases de test aient été pris en compte) reste le cas d’école mondial. Quand le calendrier politique écrase les critères techniques, c’est l’organisation entière qui paie.
Le Go/No-Go n’est pas une réunion. C’est un jeu de critères objectifs définis en phase de cadrage. Pas la veille du déploiement.
6. Les Key Users ne sont jamais disponibles (et ce n’est pas leur faute)
Ils figurent dans le RACI. Mais en pratique, ils sont toujours « sur une urgence opérationnelle ». Les ateliers se tiennent avec des remplaçants de dernière minute. Les validations sont signées sans lecture approfondie.
Le vrai blocage est au-dessus : le management n’a pas arbitré la charge.
Personne n’a arbitré leur charge. Ils portent 100% de leur activité courante plus 50% de charge projet. L’équation est impossible et tout le monde le sait. Mais personne ne veut prendre la décision de les libérer, parce que ça rend visible le vrai coût du projet pour l’organisation.
Sur un déploiement PLM multi-sites que j’ai piloté entre l’Europe et les Amériques, chaque filiale avait désigné des Key Users « en plus de leur poste ». Au bout de 4 mois, aucun n’avait participé à plus de la moitié des ateliers. On a déployé un outil que personne n’avait validé. Le rejet en production a été immédiat.
Un ERP paramétré sans implication réelle des Key Users sera rejeté en production. La phase UAT révélera des inadéquations fonctionnelles majeures, trop tard pour les corriger proprement.
7. Le registre des risques est un document mort
Il existe, créé en phase de cadrage. Dernière mise à jour : il y a 3 mois.
C’est un signal d’une banalité désarmante, et pourtant c’est un des meilleurs indicateurs de santé d’un déploiement ERP. Un registre vivant, c’est une équipe qui accepte de regarder le réel en face. Un registre mort, c’est une équipe en mode survie qui a abandonné la gouvernance proactive.
Les risques réalisés ne sont pas marqués. Les nouveaux risques identifiés en réunion ne sont jamais consignés. Dans une équipe déjà sous pression, c’est la première tâche sacrifiée. Normal, mais fatal.
Les risques qui ne sont pas nommés ne disparaissent pas. Ils se réalisent en silence.
Ce que fait un Project Fixer (et ce qu’il ne fait pas)
Un Fixer fait une seule chose : il nomme ce que tout le monde voit mais que personne ne dit. Les écarts réels, les risques concrets, les décisions en attente. Il crée les conditions pour que l’équipe du déploiement ERP reprenne la maîtrise, puis il sort.
5 questions à poser dès lundi matin
- « Qui est responsable de la qualité des données de migration, nominativement ? » (L’hésitation dit tout.)
- « Montrez-moi le dernier Change Request validé. » (S’il n’y en a pas, le scope creep est déjà là.)
- « Quand le registre des risques a-t-il été mis à jour pour la dernière fois ? » (La date suffit.)
- « Les Key Users ont-ils été libérés à 50% minimum pour le projet ? »
- « Quel est le dernier point de désaccord documenté avec l’intégrateur ? »
Ces 5 questions nécessitent la volonté de nommer le réel. C’est exactement ce que les équipes immergées ne peuvent plus faire seules.
FAQ
Comment savoir si mon projet ERP est vraiment en dérive ?
Les signaux sont rarement spectaculaires. Le meilleur indicateur : comparez le discours officiel avec ce qui se dit dans les couloirs. Si les 2 ne racontent pas la même histoire, la dérive est déjà là. Vos tableaux de bord ne l’ont simplement pas encore captée.
À quel moment faut-il appeler un Project Fixer ?
Dès que vous identifiez 3 signaux parmi les 7 listés ici. La fenêtre d’intervention se referme vite : passé un certain seuil, on ne redresse plus, on négocie une sortie de crise. Sur un déploiement ERP, 2 semaines de cadrage changent la trajectoire. 2 mois de déni la verrouillent.
Peut-on récupérer un projet ERP à 6 mois du Go Live ?
Oui, si les décisions structurelles sont prises dans les 2 premières semaines d’intervention. Un redressement, c’est une série d’arbitrages difficiles que personne n’a voulu faire. Avec un mandat clair et un sponsor qui assume, ça se fait.
Prochaine étape
Session de diagnostic stratégique, 45 min. Pas un audit formel. Une conversation structurée pour cartographier où en est votre déploiement ERP et identifier les 2-3 leviers à activer en priorité.
Une question que je pose toujours en fin de session : « Qu’est-ce que tout le monde sait mais que personne n’a encore dit à voix haute ? » La réponse change généralement la trajectoire du projet.
