Dans la gestion de projet, on parle sans cesse de change management. On le sait tous : c’est important. Mais derrière ce joli anglicisme, est-ce qu’on mesure toujours vraiment ce qu’implique l’accompagnement au changement ?
Sur le papier, la recette paraît assez simple : on communique sur le projet, on explique les bénéfices de la future solution, on implique les Key Users, on prépare des supports, on forme les utilisateurs avant le démarrage… Et comme dit la fameuse expression, « compter 21 jours pour ancrer durablement une habitude ».
Et ça roule ma poule. Enfin, en théorie.
Parce qu’entre comprendre comment fonctionne un nouvel outil et être réellement à l’aise avec lui au quotidien, il peut se passer beaucoup de choses.
Changer d’outil, c’est aussi perdre ses automatismes
On sous-estime facilement à quel point nos habitudes de travail sont ancrées. Quelqu’un qui utilise le même logiciel depuis dix ans ne réfléchit probablement plus à une grande partie de ce qu’il fait.
Il sait où cliquer. Il connaît l’ordre des écrans. Il sait comment retrouver une information. Il connaît les raccourcis. Il sait que, dans tel cas particulier, il faut passer par tel menu ou contourner telle étape. Il sait même parfois interpréter des messages d’erreur à force de les avoir vus. Tout cela demande très peu d’effort cognitif parce que les gestes sont devenus automatiques. Puis arrive le nouvel outil.
Les écrans ne sont plus les mêmes. Les informations ne sont pas présentées au même endroit. Les documents générés ont changé. Les workflows sont différents. Certains boutons ont disparu. Une opération qui prenait deux clics en prend maintenant quatre, alors qu’une autre qui nécessitait dix manipulations est désormais automatisée. Et surtout, les anciens réflexes ne fonctionnent plus.
On peut avoir expliqué dix fois les avantages de la nouvelle solution, cela ne change rien à cette sensation très concrète : pendant un certain temps, travailler demande davantage d’effort.
« C’était mieux avant »
C’est souvent à ce moment-là qu’apparaît la fameuse phrase : « Franchement, c’était mieux avant. »
Lorsqu’on maîtrise parfaitement un outil et qu’on le compare à un système que l’on découvre à peine, la comparaison est forcément biaisée. L’utilisateur compare plusieurs années d’expérience et d’automatismes dans l’ancien système avec ses premières semaines d’utilisation dans le nouveau. Une opération toute simple peut alors sembler laborieuse simplement parce qu’il faut réfléchir à chaque étape. Où chercher un champ, vérifier si l’on est dans le bon écran, se demander quel bouton utiliser, puis recommencer parce qu’on aurait oublié quelque chose…
C’est lent. C’est frustrant. Et dans une journée déjà chargée par la gestion du quotidien qui ne diminue pas, cette frustration se ressent rapidement.
Avec la pratique, une partie de cette difficulté disparaît naturellement. Ce qui demandait cinq minutes et beaucoup de concentration devient progressivement un geste banal. C’est aussi cela, l’adoption d’un nouvel outil. Il serait facile de mettre toutes ces réactions dans la case « résistance au changement ». Mais ce serait une erreur.
Résistance au changement – oui, mais attention aux autres pièges
Il y a cependant un piège inverse. Celui qui consiste à répondre à toute critique par : « C’est normal, ils doivent s’habituer. »
Parfois l’utilisateur a vraiment raison : le nouveau processus est inutilement plus compliqué. Une information indispensable manque réellement dans un écran. Une séquence demande trop de manipulations. Une fonctionnalité nécessaire n’a pas été prévue. Une automatisation qui existait auparavant a effectivement disparu. Ou le nouveau processus a été pensé en atelier sans mesurer complètement ce qu’il représente lorsqu’on doit l’exécuter cinquante fois par jour.
C’est là que le travail de l’équipe projet et du support devient beaucoup plus intéressant. Il faut réussir à distinguer la difficulté liée à l’apprentissage de la difficulté liée à la solution elle-même. Quand dix utilisateurs remontent le même problème, il mérite probablement d’être regardé. Quand une procédure nécessite systématiquement un contournement, il y a peut-être quelque chose à revoir. Quand une opération paraît longue les trois premiers jours mais devient naturelle deux semaines plus tard, on était probablement davantage face à un sujet d’appropriation.
Le change management ne consiste donc pas uniquement à convaincre les utilisateurs que le nouvel outil est formidable. Il consiste aussi à écouter ce que leur expérience nous apprend et prendre les bonnes décisions en conséquence.
Une formation avant le déploiement ne peut pas faire tout le travail
C’est peut-être l’un des points que l’on sous-estime le plus. On construit un plan de formation. Les utilisateurs suivent deux ou trois heures de formation quelques semaines avant le démarrage. Ils voient les principaux écrans, exécutent quelques exercices et repartent avec un support. Case cochée : utilisateurs formés.
En réalité, entre « avoir assisté à une formation » et « savoir travailler seul en production », il y a tout un monde. D’abord parce que l’utilisateur ne retient pas tout. Ensuite parce qu’une formation reste souvent relativement théorique tant que l’on ne travaille pas sur ses propres dossiers, avec de vraies contraintes et de vraies exceptions.
C’est généralement après le déploiement que commencent les vraies questions : « Je fais quoi dans ce cas-là ? », « Pourquoi cette commande est bloquée ? », « Je me suis trompé, comment j’annule ? » … Et c’est normal. On ne peut pas former à l’avance à toutes les situations qui seront rencontrées en production La formation donne les bases, alors que l’apprentissage continue ensuite sur le terrain.
Les premières semaines comptent probablement autant que la formation elle-même
C’est là que le support post go-live devient une véritable action de conduite du changement : ce n’est pas un simple dispositif de correction de bugs.
Un utilisateur qui rencontre un problème peut vivre deux expériences complètement différentes.
Dans la première, il ne sait pas vers qui se tourner. Il essaie plusieurs fois. Il demande à ses collègues. On lui donne des réponses contradictoires. Il finit par trouver un contournement dans Excel ou pire encore commettre des erreurs. Conclusion : « le nouvel outil ne fonctionne pas ».
Dans la seconde, il sait immédiatement à qui poser sa question. Quelqu’un lui explique ce qui s’est passé, lui montre la bonne manipulation et lui explique éventuellement la logique du nouveau processus. La prochaine fois, il saura probablement le faire seul.
Même problème initial. Mais pas du tout la même trajectoire d’adoption.
La disponibilité du support dans les premières semaines, la qualité des réponses et leur rapidité peuvent avoir énormément d’impact sur la perception du nouvel outil.
Les Key Users jouent un rôle beaucoup plus difficile qu’on ne le pense
Dans les projets de transformation, on parle beaucoup des Key Users. On a tendance à croire que leur rôle se résume à participer aux ateliers d’expression de besoin, à tester et à assurer le relais auprès des équipes.
Dans la réalité, on leur demande beaucoup. Ils doivent parfois apprendre le nouvel outil alors qu’il est encore en construction, participer aux tests utilisateur, signaler les anomalies, comprendre les nouveaux processus, rassurer leurs collègues, préparer ou animer des formations et devenir le premier niveau de support après le démarrage.
Tout cela sans forcément être déchargés de leur activité habituelle. Et surtout, ils se retrouvent parfois entre deux mondes. D’un côté l’équipe projet, qui connaît la logique de la solution. De l’autre leurs collègues, qui vivent très concrètement les difficultés du changement.
Le choix des Key Users, leur disponibilité et l’accompagnement qu’on leur donne sont donc loin d’être accessoires. Mettre quelqu’un dans une liste avec l’étiquette « Key User » ne suffit pas à en faire un ambassadeur du changement.
Les procédures aussi doivent vivre
Autre réflexe classique : produire de la documentation avant le démarrage c’est très utile, certes, mais il est important de la faire évoluer et ne pas oublier les supports après quelques semaines d’utilisation réelle. Tout simplement, parce que les utilisateurs découvrent de nouveaux cas, certaines erreurs reviennent régulièrement, des solutions plus simples sont trouvées ou des questions que personne n’avait anticipées apparaissent.
La documentation peut non seulement évoluer mais aussi devenir progressivement plus pragmatique.
On n’a pas forcément besoin d’ouvrages de trente pages. Parfois une fiche très courte, une FAQ, quelques captures d’écran ou une base de connaissances alimentée au fil des incidents récurrents seront beaucoup plus utiles au quotidien.
Le changement ne se pilote pas uniquement avant le go-live
Parfois notre vision du change management peut être trop courte. On s’investit beaucoup avant la mise en production du système : communication, présentations, formations, supports, réunions, newsletters…
Puis le système démarre. On considère implicitement que le changement a eu lieu. Techniquement, oui, mais pour les utilisateurs ce n’est que le début du processus. C’est à ce moment qu’ils commencent réellement à abandonner leurs anciennes habitudes, à construire de nouveaux réflexes et à comprendre la logique du nouveau système. C’est aussi à ce moment que les frustrations sont les plus fortes, parce que l’ancien système reste encore très présent dans les mémoires alors que le nouveau n’est pas encore maîtrisé.
En conséquence, c’est à ce moment que l’accompagnement doit être le plus concret avec les équipes support prévues et pleinement disponibles afin d’observer les difficultés récurrentes, répondre rapidement aux utilisateurs, corriger si besoin, faire circuler les bonnes pratiques.
L’adoption, ça prend du temps
On aime bien associer la conduite du changement à quelques grandes actions visibles : communiquer, former, impliquer. Cela est sans doute nécessaire.
Mais l’adoption se joue probablement davantage dans des centaines de petites interactions après le lancement :
- Une question à laquelle quelqu’un répond
- Une erreur que l’on explique
- Une procédure que l’on simplifie
- Un utilisateur qui réussit seul une opération qui lui semblait incompréhensible
- Un Key User qui montre une astuce à son équipe
- Un irritant réel que le projet accepte de corriger
Progressivement, l’outil cesse d’être « le nouveau système » et devient simplement l’outil avec lequel on travaille tous les jours. Et c’est peut-être là que le changement est réellement terminé : lorsque les équipes n’ont plus besoin de comparer en permanence ce qu’elles font aujourd’hui avec ce qu’elles faisaient avant.
Finalement le change management ne résume pas à préparer les utilisateurs au changement, le vrai challenge de cette activité est d’accompagner les utilisateurs suffisamment longtemps pour que ce changement devienne leur nouvelle normalité.