
Sommaire
Un plan de conduite du changement pour un programme ERP décrit comment les gens passeront de leur façon de travailler d'aujourd'hui à celle que le nouveau système exige, et qui est responsable de les y conduire. Il démarre à la mobilisation, pas à la formation. Il comporte sept parties, chacune avec un responsable nommé, et il est relié à la charte, aux ateliers de conception et aux quality gates au lieu d'être mené comme un flux parallèle.
La plupart des résistances ne sortent pas de nulle part. Elles montent doucement, bien avant le lancement. On les entend dans des remarques en biais lors des premières réunions. On voit des référents métier clés se taire. Quand un plan de changement formel est rédigé, une bonne partie des dégâts est déjà faite.
Elles naissent en général dans quelques endroits prévisibles :
- Des utilisateurs clés tenus à l'écart de la conception initiale.
- Des directeurs de département surpris par des impacts dont personne n'avait discuté avec eux.
- Une communication floue qui pousse à douter de tout.
- Des projets ratés dans le passé, qui ont laissé une défiance silencieuse.
Ce sont des problèmes structurels, pas seulement des problèmes de communication. Si le comité de pilotage est passif, attendez-vous à des frictions. Si la charte du projet ne dit rien de l'adoption, vous avez déjà perdu un levier.
- MobilisationCartographier l'influence et recueillir l'histoire informelle
- ConceptionConvenir des KPI d'adoption, les super-utilisateurs cosignent
- TestsLes utilisateurs métier testent leurs propres processus
- FormationPar rôle, sur des données réelles, à des moments où les gens peuvent venir
- Validation du go-liveDes seuils d'adoption, pas seulement une validation fonctionnelle
- 90 premiers joursSuivre connexions, erreurs, tickets et contournements
Contournements repérés avant qu'ils ne deviennent des habitudes
Un plan de changement n'est pas un calendrier de communication. Voici les sept composantes et qui doit porter chacune.
| Composante | Objectif | Responsable |
|---|---|---|
| Cartographie des rôles et de l'influence | Toutes les personnes concernées, avec leur influence, pas seulement leur titre | Responsable du changement |
| Analyse d'impact du changement | Comment les rôles, processus et outils de chaque groupe changent | Propriétaires de processus avec l'équipe changement |
| Plan de communication | Publics, messages, canaux et calendrier, avec des boucles de retour | Responsable de la communication |
| Formation et accompagnement | Cursus par rôle, pratique, contrôles de préparation | Responsable de la formation |
| Mobilisation des dirigeants | Dirigeants alignés, informés et soutenant visiblement le changement | Sponsor exécutif avec le responsable du changement |
| KPI d'adoption | Mesures de comportement convenues en conception et suivies après le go-live | Responsable du changement |
| Suivi de la résistance | Signaux d'alerte précoces rattachés aux équipes | Tous les responsables de chantier |
La communication, dans la plupart des plans de changement, c'est des newsletters, des e-mails et des réunions plénières. Ce n'est pas ce qui fait bouger les gens.
Je me souviens d'un déploiement où nous avions tout communiqué dans les temps, mais où personne ne savait expliquer pourquoi le processus changeait. Nous avions du volume, mais pas de clarté.
Adaptez le message au public. Les cadres dirigeants veulent d'abord l'impact métier. Les utilisateurs finaux doivent l'entendre de leur propre manager, pas d'un responsable de programme qu'ils n'ont jamais rencontré. Les responsables fonctionnels réagissent mieux quand ils portent une partie du message.
Prévoyez des retours. Une communication à sens unique n'est que la moitié d'un plan. J'ai travaillé avec une équipe où des points questions-réponses hebdomadaires ont eu plus d'effet que n'importe quel e-mail. Reliez ce que vous entendez au registre des risques, pour que les points faibles apparaissent avant de surgir en public.
Soignez le calendrier. Trop tôt, cela crée de la confusion. Trop tard, cela paraît forcé. Dans un déploiement, des utilisateurs pensaient que leurs postes allaient être remplacés. Personne ne l'avait dit. Mais le silence a comblé les blancs. Abordez la peur directement et tôt, avant que quelqu'un d'autre ne le fasse à votre place.
Ne reprenez pas la carte des personnes du dernier projet. L'influence change d'un programme à l'autre. Construisez la carte de zéro et mettez-la à jour chaque mois.
Pour chaque personne, suivez trois éléments : à quel point le changement l'affecte, où elle en est aujourd'hui (favorable, neutre ou résistante), et quelle influence elle exerce sur les autres. Un cadre intermédiaire résistant, suivi par son équipe, compte plus qu'un utilisateur résistant isolé.
Recueillez aussi l'histoire informelle. Les projets ratés du passé façonnent les comportements d'une façon que les documents de retour d'expérience n'enregistrent jamais. Quelques heures à écouter ce dont les gens se souviennent vous disent à quoi vous avez réellement affaire. Mon guide de gestion des parties prenantes détaille cette cartographie.
La formation est un élément de la conduite du changement, pas son tout. L'échec classique, c'est une formation trop tardive, dans le mauvais format, qui s'arrête avant que les gens soient à l'aise. Une journée de cours deux semaines avant le go-live n'est pas de la préparation.
Ce qui marche :
- Un contenu par rôle. Enseignez à chaque groupe ce dont il a besoin pour son propre métier, pas une visite du système.
- S'exercer sur des données réelles. Utilisez les données et les transactions de l'entreprise, pas des scénarios de démo.
- Les super-utilisateurs comme formateurs. On apprend mieux auprès de collègues en qui l'on a confiance. Traitez les super-utilisateurs comme des coauteurs de la conception, pas seulement comme des testeurs.
- Une formation au bon moment. Une équipe finance avec laquelle j'ai travaillé séchait les sessions parce qu'elles étaient planifiées au mauvais moment. Les déplacer a réglé le problème.
- Un soutien après le go-live. La confiance baisse après le go-live, pas avant. Dotez l'hypercare de personnes capables de répondre vite à de vraies questions.
Les tests d'acceptation utilisateur font aussi partie de l'adoption. Je me souviens d'une séance d'UAT où une petite erreur dans la logique de tarification aurait provoqué une facturation erronée. Un chef d'équipe l'a repérée. Personne d'autre ne l'avait vue. Cette seule détection a évité des semaines de reprise, et elle est arrivée parce qu'un utilisateur métier considérait que le système était un peu le sien.
Mettez des seuils d'adoption dans vos quality gates. « Le système fonctionne » est une validation fonctionnelle. « Les utilisateurs sont prêts à travailler dedans » en est une autre, et la plupart des programmes ne demandent que la première. Mon guide des stratégies de formation SAP approfondit le plan de formation.
KPI d'adoption à convenir avant le go-live
Fixez-les pendant la conception, pour avoir une base de référence à laquelle comparer :
- Taux de connexion par groupe d'utilisateurs sur les 90 premiers jours.
- Taux d'erreur sur les transactions clés par rapport à la base de l'ancien système.
- Tickets de support par volume et par catégorie.
- Fréquence des contournements : exports vers des tableurs, enregistrements parallèles, approbations manuelles hors du système.
- Confiance déclarée par les managers, via de courtes enquêtes flash.
La fenêtre est étroite. J'ai vu des utilisateurs revenir discrètement aux tableurs en quelques semaines, non parce que le système était défaillant, mais parce que personne ne les avait aidés à traverser le changement. Quelques mois après le go-live, les contournements deviennent des habitudes.
Outils d'adoption numérique
SAP a finalisé l'acquisition de WalkMe en septembre 2024, pour une valeur des fonds propres d'environ 1,5 milliard de dollars. SAP avait alors indiqué que les capacités d'IA de WalkMe ajouteraient à Joule une aide contextuelle dans l'ensemble des flux. SAP possède donc désormais deux outils d'adoption aux forces différentes :
- SAP Enable Now convient au contenu de formation structuré : on enregistre un processus une fois et on en tire de la documentation, des simulations et des scripts de test.
- WalkMe convient à l'assistance dans l'application au moment de l'usage, et il peut couvrir des applications SAP et non-SAP.
Évaluez-les ensemble. Whatfix est la principale alternative indépendante si vous voulez un outil d'adoption qui n'est pas lié à SAP. Aucun de ces outils ne remplace un manager qui explique pourquoi le changement compte.
Je me souviens d'un déploiement où nous avions tout communiqué dans les temps, mais où personne ne savait expliquer pourquoi le processus changeait. Nous avions du volume, mais pas de clarté.
Même avec une bonne préparation, de nouvelles frictions apparaissent. Les contrôler à outrance se retourne généralement contre vous. L'objectif est de les voir tôt.
Les signaux d'alerte : ateliers manqués, silence en réunion, retours vagues pendant les tests, utilisateurs clés qui bricolent des contournements non officiels. Rattachez chaque signal à l'équipe d'où il vient, pour agir avant qu'il n'atteigne le comité de pilotage.
Une pratique qui marche : faire tourner les responsables du changement par phase. Une seule personne chargée du changement sur un programme de deux ans finit en général par s'épuiser et par perdre du recul. À mesure que la nature de la résistance change, les personnes chargées de la traiter doivent changer aussi.
Surtout, gardez la conduite du changement à l'intérieur de la structure du programme. Les résultats comportementaux ont leur place dans la charte du projet. Les risques humains, comme la surcharge des équipes et la défiance héritée du passé, ont leur place dans le registre des risques, à côté des risques techniques. Quand la conduite du changement remonte dans un point PMO générique, elle devient une case à cocher.
Que doit contenir un plan de conduite du changement ?
Sept parties : cartographie de l'influence, analyse d'impact du changement, plan de communication avec boucles de retour, formation par rôle, mobilisation des dirigeants, KPI d'adoption et suivi de la résistance. Chacune a besoin d'un responsable nommé, et le plan doit être relié à la charte, aux ateliers de conception et aux quality gates.
Quels sont les 5 C de la conduite du changement ?
Il en existe plusieurs versions. Celle que j'utilise : clarté (les gens savent ce qui change pour eux), cohérence (les dirigeants disent la même chose), engagement (le sponsor reste visible), communication (pertinente, opportune et à double sens) et capacité (formation, soutien et temps d'adaptation). Si l'un des cinq manque, les gens reviennent à leurs anciennes habitudes.
Quels sont les 7 R de la gestion du changement ?
Ils viennent de la gestion des services informatiques et servent à évaluer une demande de changement avant d'agir. Qui l'a soumise, la raison, le retour attendu, les risques, les ressources nécessaires, le responsable, et la relation avec les autres changements. Ils s'appliquent au contrôle technique des changements plutôt qu'au volet humain d'un programme.
Quelle est la différence entre la conduite du changement organisationnel et la gestion technique des changements ?
La conduite du changement organisationnel prépare les gens : communication, formation et accompagnement face à un changement de leur façon de travailler. La gestion technique des changements contrôle ce qui entre dans le système SAP, par les transports, les approbations, les tests et le retour arrière. Les programmes ERP gèrent en général bien le versant technique ; les échecs d'adoption viennent du versant organisationnel. Mon guide des outils SAP de gestion technique des changements couvre le versant technique.
Faut-il utiliser WalkMe ou SAP Enable Now ?
Souvent les deux. SAP Enable Now est plus fort pour créer du contenu de formation structuré avant le go-live. WalkMe est plus fort pour l'assistance dans l'application après le go-live, surtout quand les utilisateurs passent entre SAP et d'autres applications. Comme SAP détient les deux, évaluez-les ensemble. Whatfix est la principale alternative indépendante.
Quand la conduite du changement doit-elle commencer sur un projet ERP ?
À la mobilisation, avant le premier atelier de conception. Les premières actions qui comptent le plus : cartographier l'influence, recueillir l'histoire informelle des projets passés, inscrire des résultats comportementaux dans la charte et fixer le rythme de communication du sponsor.
Prochaine étape
Vous menez un programme ERP en ce moment ?
Si cet article fait écho à un programme que vous menez en ce moment, un échange de 30 minutes va généralement plus loin qu'une semaine supplémentaire d'analyse interne.




