Pourquoi Vos Collaborateurs Sabotent (Sans le Vouloir) Votre Nouvel ERP

Sommaire

• Le Projet Technique Parfait qui Échoue Quand Même
• Ce Qu’on Appelle « Sabotage » N’est (Presque) Jamais Volontaire
• Les Signes Précoces à Repérer
• Les Trois Racines Réelles du Rejet
• L’Erreur de Timing la Plus Fréquente
• Ce Que le Terrain Enseigne Que le Comité de Pilotage Ignore
• Construire l’Adoption Dès la Conception, Pas Après le Go-Live
• Checklist Anti-Rejet
• FAQ
• Regard d’Expert
• Références

Le Projet Technique Parfait qui Échoue Quand Même

Le scénario est connu de tout DSI ou Product Owner ayant piloté une migration ERP : le système fonctionne, les tests de recette sont passés, l’intégrateur a livré dans les temps — et six mois après le go-live, une partie significative des équipes continue à utiliser des tableurs Excel parallèles pour compenser ce que le nouveau système « ne fait pas bien » selon elles. Le projet est un succès technique et un échec d’adoption. C’est la combinaison la plus frustrante qui soit, parce qu’elle ne se voit dans aucun indicateur de recette.

Ce Qu’on Appelle « Sabotage » N’est (Presque) Jamais Volontaire

Le mot « sabotage » est trompeur. Il suggère une intention malveillante qui n’existe presque jamais dans la réalité. Ce qu’on observe est plutôt un contournement rationnel : des collaborateurs compétents, de bonne foi, qui trouvent que l’ancien outil (même imparfait) leur permettait de faire leur travail plus vite ou plus précisément que le nouveau. Ce n’est pas de la résistance au changement par principe — c’est une réponse logique à un système perçu comme moins efficace sur leur usage quotidien réel, pas sur la démonstration faite en comité de pilotage.

Les Signes Précoces à Repérer

• Des tableurs Excel « de secours » qui réapparaissent dans les semaines suivant le go-live.
• Des demandes répétées de formation complémentaire sur les mêmes fonctionnalités, signe que la formation initiale n’a pas suffi.
• Des données saisies de façon incohérente entre équipes censées suivre le même processus.
• Un silence inhabituel des utilisateurs en comité de suivi — l’absence de retour est souvent pire qu’une critique ouverte.

Les Trois Racines Réelles du Rejet

Premièrement, un processus reconstruit sans les utilisateurs finaux dans la boucle de conception. Quand les ateliers de cadrage impliquent surtout les managers et rarement les utilisateurs opérationnels, le système reflète ce que la hiérarchie pense être le travail, pas ce qu’il est réellement.

Deuxièmement, une formation calée sur le calendrier projet, pas sur le rythme d’apprentissage réel. Une session unique de deux heures avant le go-live ne suffit jamais pour un changement d’outil substantiel — c’est pourtant le format le plus fréquent, parce qu’il coûte le moins cher à court terme.

Troisièmement, l’absence de relais locaux crédibles. Sans un ou deux collègues respectés qui défendent le nouvel outil de l’intérieur de chaque équipe, l’adoption dépend entièrement d’un mandat descendant — qui s’érode dès que l’attention de la direction se porte ailleurs.

L’Erreur de Timing la Plus Fréquente

La conduite du changement est presque toujours planifiée comme la dernière étape du projet, juste avant le go-live — alors qu’elle devrait démarrer au moment même du cadrage. Un utilisateur consulté dès la phase de spécification devient un allié du projet. Le même utilisateur, informé seulement à la formation de pré-lancement, devient au mieux un spectateur passif, au pire un contributeur silencieux au contournement du système.

Un utilisateur formé tôt et bien devient un relais, pas un frein.

Ce Que le Terrain Enseigne Que le Comité de Pilotage Ignore

Sur des déploiements multi-pays ou multi-sites, la présence physique sur le terrain change fondamentalement la nature des objections remontées. Un atelier de cadrage à distance capte les objections formulables par écrit. Une présence sur site capte les objections qu’un utilisateur n’oserait jamais formuler dans un compte rendu — souvent les plus révélatrices sur les vraies raisons du rejet à venir.

La conduite du changement démarre au cadrage, pas à la veille du go-live.

Construire l’Adoption Dès la Conception, Pas Après le Go-Live

• Intégrer des utilisateurs opérationnels réels (pas seulement des managers) dans les ateliers de cadrage, dès la phase de spécification.
• Prévoir une formation étalée dans le temps, adaptée au rythme réel d’appropriation, pas une session unique avant le go-live.
• Identifier et former des relais locaux crédibles dans chaque équipe avant le déploiement, pas après les premiers signes de rejet.
• Mettre en place un canal de retour simple et réellement écouté pendant les 90 premiers jours suivant le go-live — pas seulement un ticket support.

Checklist Anti-Rejet

• Des utilisateurs opérationnels réels ont-ils participé aux ateliers de cadrage, pas seulement leurs managers ?
• La formation est-elle étalée dans le temps plutôt que concentrée en une seule session pré-lancement ?
• Des relais locaux crédibles sont-ils identifiés et formés dans chaque équipe concernée ?
• Un canal de retour actif existe-t-il pour les 90 premiers jours post-lancement, avec un vrai suivi des remontées ?

FAQ

Combien de temps après le go-live peut-on encore agir si l’adoption patine ?
Les 90 premiers jours sont la fenêtre la plus efficace — au-delà, les habitudes de contournement se sont installées et deviennent beaucoup plus coûteuses à déloger.

Faut-il sanctionner les équipes qui reviennent à l’ancien système ?
Rarement une bonne réponse — la sanction traite le symptôme (le contournement) sans traiter la cause (un système perçu comme moins efficace sur l’usage réel).

Un excellent système peut-il quand même échouer à l’adoption ?
Oui, régulièrement — la qualité technique du système et la qualité de la conduite du changement sont deux axes largement indépendants l’un de l’autre.

Les relais locaux doivent-ils être des managers ?
Non, et c’est souvent contre-productif — un relais crédible est respecté pour sa compétence opérationnelle réelle, pas pour sa position hiérarchique.

Regard d’Expert

Sur des déploiements ERP et CRM multi-pays, j’ai vu la même dynamique se répéter : les projets qui réussissent vraiment l’adoption sont ceux où la conduite du changement a démarré en même temps que le cadrage technique, pas après. Le facteur le plus prédictif du succès n’est presque jamais la qualité du système livré — c’est la présence, dès le premier jour, des utilisateurs qui devront vivre avec au quotidien. C’est précisément ce diagnostic de terrain que notre plateforme Diagnoz® permet de structurer en amont.

Je suis actuellement disponible pour accompagner la conduite du changement d’un programme ERP ou CRM, en France ou à l’international.

👉 Contactez Notoriti pour construire une adoption réelle dès la conception de votre projet.

Références

• Expérience professionnelle directe — programmes de transformation ERP/CRM multi-pays et multi-sites
• Prosci, Best Practices in Change Management (référentiel méthodologique ADKAR)