Leçons apprises en gestion du changement

[00:00:00] Super. Merci beaucoup à tous de vous être connectés aujourd’hui. Euh, nous allons, oui, nous allons vous parler de la gestion du changement. C’est un sujet qui est revenu très souvent dans notre discussion dernièrement. Donc je me suis dit qu’il était temps de rassembler quelques personnes pour échanger sur les différents sujets qui nous préoccupent.

Ce que je souhaite ici, c’est simplement un moment pour partager et enrichir notre savoir commun, car nous avons tous vécu la gestion du changement dans nos projets ou organisations, en étant à la fois acteur et bénéficiaire. J’aimerais donc qu’on profite de ce temps pour partager des histoires, et aussi, oui, discuter de ce que nous avons appris au fil du temps afin d’aider les autres, peu importe où ils en sont, dans leur propre processus ou leur propre changement.

C’est aussi tout l’intérêt de cette communauté : construire ce savoir collectif. Donc, j’ai demandé à quelques personnes de venir avec des histoires à raconter. Si vous n’en avez pas, ce n’est pas grave. Si l’une vous vient à l’esprit pendant la séance, n’hésitez pas non plus. Ce que je veux, c’est que nous puissions [00:01:00] partager quelques expériences.

Au fur et à mesure que des questions émergent, sentez-vous libre de les écrire dans le chat ou de les formuler directement. Ce sera vraiment une discussion ouverte. Nous pourrons partager nos apprentissages au fil du temps. L’idée, c’est qu’en repartant aujourd’hui, nous disposions tous de quelques outils ou idées supplémentaires pour aborder le changement dans nos propres projets.

Une des personnes à qui j’avais demandé d’apporter une histoire pour lancer la discussion était Fred. Fred, si cela ne te dérange pas, tu peux commencer. Nous allons démarrer ainsi. Et comme je l’ai dit, questions dans le chat, interventions main levée… Ce sera convivial.

Merci. Premièrement, merci [00:02:00] d’avoir organisé cela. Je trouve ça non seulement super de voir ce type d’événement, mais encore plus lorsque c’est en réponse directe à des questions ou interrogations de membres. Cela renforce vraiment l’esprit communautaire.

Merci de m’avoir invité à partager une histoire. Pour présenter mon parcours : je viens du design de systèmes pédagogiques, j’ai même un doctorat dans ce domaine. J’ai donc abordé toutes les théories et modèles, et dans le design de systèmes pédagogiques, une grande part concerne le développement organisationnel. Et une grosse part là-dedans, c’est la gestion du changement.

Je n’ai pas forcément beaucoup d’expérience formelle, au sens d’avoir fait partie d’une équipe de gestion du changement dans une structure apprenante, mais j’ai un peu étudié le sujet, comme, par exemple, le concept d’organisation apprenante selon Peter Senge — « la cinquième discipline », ou encore le modèle en 8 étapes de Kotter et celui de Lewin : « geler, dégeler, regel ». Ces modèles sont de bons outils de réflexion sur le changement, et aident à réfléchir [00:03:00] aux processus et à ce qu’il faudrait mettre en place, même dans la conduite de projets.

Everett Rogers a aussi travaillé sur la diffusion de l’innovation et de l’adoption. L’idée est qu’on atteint une masse critique lors de l’adoption d’une technologie : il y a d’abord les innovateurs, toujours motivés par la nouveauté, puis les premiers adoptants, et une fois la « masse critique » atteinte, tout le monde s’intéresse au sujet et cela se généralise, jusqu’aux adopteurs tardifs, les « retardataires », qui restent réticents — dans chaque organisation, il y en a toujours quelques-uns qui refusent d’utiliser Teams ou autre outil imposé.

Je viens de l’enseignement supérieur, et même lorsqu’une école entière utilise Google ou Microsoft, il y aura toujours trois enseignants qui préfèrent utiliser une autre adresse email car ils la jugent meilleure. « Mais comment fait-on pour avoir rendez-vous avec vous ? » Là, cela devient un vrai casse-tête d’organisation…

Tout ça pour dire que des modèles et théories existent, mais pour ne pas trop m’étaler, je vais partager une expérience concrète. J’ai accompagné beaucoup d’organisations dans leur transition sur l’outil monday.[00:05:00]com et similaires. Un de mes clients créait des modules e-learning pour de grandes sociétés. Ils avaient déjà utilisé Monday, mais de façon improvisée, sans réelle réflexion préalable.

Beaucoup de « projets Monday » que j’ai suivis n’étaient pas vraiment des projets Monday, mais plutôt des projets d’optimisation de processus métier. Souvent, les procédures internes n’étaient pas établies ni les flux de travail cartographiés, ce qui rendait difficile toute modification ou évolution. Impossible de changer si on ne sait pas d’où on part ! Pour ce client, il m’a fallu près d’un an pour revoir leur système, ce qui a permis d’améliorer leur performance, la livraison et de réduire les problèmes qualité.

Tout s’est fait de façon itérative : « À quoi ressemble le processus idéal ? Et le vôtre actuel ? Comment les rapprocher ? » C’est une démarche simple, mais qui se retrouve dans tous les modèles de gestion du changement.

C’est universel : que l’on cherche à perdre du poids, à apprendre une compétence, à réaliser un projet personnel, il faut d’abord analyser l’existant, définir l’objectif et chercher comment s’améliorer… Quelques leçons tirées de ce projet : commencer par définir clairement [00:06:00] la problématique, cartographier les processus et veiller à ce que le problème soit bien identifié avant d’envisager toute solution technique ou organisationnelle.

J’insiste sur l’importance de faire exprimer au client ses attentes et ses besoins ; je ne touche pas à Monday ou à tout autre outil avant d’avoir tout clarifié. C’est comme en programmation : on ne se lance pas dans le code sans d’abord savoir ce qu’on cherche à obtenir. C’est de la planification, un exercice pas forcément naturel pour moi mais que j’ai appris à apprécier car il fait vraiment la différence.

Enfin, il faut aider le client à construire sa propre feuille de route : « Que voulez-vous exactement ? Vers qui est envoyé ce livrable, quelles sont les étapes suivantes, d’où viennent les éléments d’entrée ? » Le but, c’est de dresser une véritable cartographie du processus.

Peut-être que ce récit est un peu à côté, je peux développer, mais je ne voudrais pas accaparer le temps… J’aimerais d’ailleurs savoir, parmi vous, qui a connu des situations similaires ou des approches différentes [00:11:00] dans la gestion du changement.

Si personne n’a rencontré ce genre de problème, c’est une expérience complètement unique ! Mais j’imagine que, comme moi, vous avez déjà été confrontés à des résistances au changement, à de nouveaux process ou idées…

Je vois que certaines caméras sont coupées, peut-être êtes-vous simplement en train d’écouter tout en faisant autre chose, pas de souci. Merci encore. D’ailleurs, Fred, j’ai une question : quand la connaissance du processus n’existe que dans la tête d’une personne (comme la propriétaire dont tu parlais), comment la convaincre que c’est important de prendre du temps pour la transmettre, surtout quand le contexte est chaotique et qu’elle déborde d’urgences ?

Il y a beaucoup d’idées qui me viennent. Une chose que je dis souvent, c’est qu’en tant que chef de projet, on n’est pas « au volant », on est sur le siège passager avec la carte, et on dit « il faut tourner à gauche d’ici 500m, allumez le clignotant ». Mais si la personne ne tourne pas, ce n’est pas nous qui sommes au volant… À la fin du trajet, elle demandera pourquoi on a perdu du temps, et on explique que chaque virage raté a demandé de trouver un autre chemin.[00:13:00]

Parfois les clients pensent que tout est structuré alors qu’en réalité ce n’est pas le cas, ou croient que tout le monde a compris, alors que non. Avec cette cliente en particulier, beaucoup de nos réunions consistaient à l’écouter passer d’un sujet à l’autre, débordée… Il était parfois difficile d’obtenir plus qu’un accord sur les prochaines étapes à travailler, et le plus souvent je devais valider en fin de réunion ou par e-mail les trois tâches dont j’avais l’autorisation de m’occuper pour éviter de perdre le fil.

En mode régie (facturation à l’heure) cela passe, mais en forfait il faut être plus ferme sinon on gaspille beaucoup de temps sur des tâches annulées.

Des fois, on se retrouve à avancer sur une piste car le client l’a demandé et, arrivé à mi-chemin, il change d’avis… Et nous, en tant que consultants, si c’est à l’heure, tant pis, mais en forfait, il faut cadrer tout de suite sinon on jette des semaines de travail.

Pour revenir à l’exemple, ce qui a fonctionné était de faire comprendre qu’on était contraint par sa disponibilité ; à la fin d’une réunion parfois un peu « dispersée » je synthétisais les tâches à faire et sollicitais son accord. Régulièrement, je renvoyais un e-mail récapitulatif et en début de réunion suivante, je rappelais les points non traités car en attente d’éléments. Maintenir « une trace écrite » aide énormément à clarifier les responsabilités.[00:17:00]

J’espère que ça répond à ta question…

Je me pose aussi la question suivante : concernant la distinction entre gestion du changement et gestion de projet — car tout peut être un projet. Marissa a très bien expliqué que la gestion du changement, c’est le processus d’accompagnement de ces changements — par exemple, quand on livre un nouveau site web, qu’adviendra-t-il pour l’équipe ? Faut-il former les personnes, repenser le process, gérer des résistances — comme l’évoquait Fred ?

Personnellement, je gère un projet où j’ai dû, dès le premier jour, annoncer à un client que suite à de mauvais choix en amont (car d’autres parties n’avaient pas été consultées), la date de mise en ligne devait être repoussée et qu’il fallait injecter un budget conséquent pour rattraper les erreurs…

Le client avait contraint l’accès aux parties prenantes. Lorsque l’équipe a enfin pu faire des tests utilisateurs, nous avons découvert qu’une mauvaise cible avait été actionnée. Nous avons finalement rectifié le tir par une sorte de « soft launch » progressif, où l’on donnait la parole aux utilisateurs, ce qui a permis de mieux accepter le changement. Être entendu facilite l’acceptation de la nouveauté, même si elle est imposée.[00:22:00]

Il a fallu revoir tout le mode de communication, instaurer un système de « pression positive entre pairs » via mailing pour suivre qui avançait dans la prise en main. Bref, beaucoup de pièces mobiles et de changements parfois délicats à conduire et à faire accepter.

La question de Fred sur comment annoncer une très mauvaise nouvelle (ex : erreur massive) est aussi très pertinente. En tant que chef de projet externe, le fait d’arriver comme « nouveau regard » a aidé : j’ai pu exposer factuellement la situation, proposer des pistes, et du fait de mon recul, c’était mieux accepté que si j’avais été à bord depuis le début. Je peux expliquer le raisonnement derrière chaque décision, tout en proposant des solutions.[00:24:00]

Pour résumer, projet management = pilotage du projet ; gestion du changement = accompagnement pour s’assurer que les utilisateurs adoptent le changement livré (formation, communication, gestion de la résistance). Les deux coexistent et s’alimentent.[00:25:00]

Est-ce que certains ont déjà collaboré avec une équipe dédiée à la gestion du changement ? Il y a souvent chevauchement, mais la valeur existe : rassembler, prioriser, mettre les bonnes personnes autour de la table. Quand ce n’est pas fait, le lancement d’un projet peut échouer, car personne n’a pensé à l’adoption par les utilisateurs.[00:27:00]

Dans un grand cabinet de conseil, il y avait un pôle gestion du changement, qui se concentrait principalement sur les communications, la recherche d’adhésion et la coordination des grands déploiements. Leur rôle était parfois mal compris, mais il était essentiel pour garantir la cohérence du changement à l’échelle globale.[00:28:00]

Dans une autre expérience en grande entreprise, la gestion du changement décidait par exemple si tel contenu devait être communiqué en réunion ou par email, et le/la chargé(e) de communication rédigeait le contenu. Cette division nette montrait la richesse d’une équipe spécialisée ; dans l’agence digitale, c’est souvent absent.[00:29:00]

Une autre histoire pour illustrer : dans une petite agence créative où j’ai travaillé, suite à plusieurs vagues de licenciements, l’équipe créative avait disparu et il fallait donc revoir la manière d’utiliser l’outil principal (Asana). J’étais seul responsable des process, sans le temps d’écrire une documentation de 40 pages ; il fallait donc faire simple, pertinent, compréhensible et non surcharger l’équipe d’infos inutiles.[00:31:00]

Étape 1 : définir le problème ; étape 2 : voir ce qui existe déjà ; étape 3 : composer un mini-programme de formation en mini-tâches dans Asana (par exemple vidéos de 5 minutes existantes, bonnes pratiques, attentes de notification, etc.), à suivre séquentiellement. Cela a permis de lever des confusions entre l’usage d’Asana et de Slack.[00:35:00]

Pour s’assurer que tout le monde suit, j’étais copié sur chaque mini-tâche, et j’ai expliqué pourquoi aider à clarifier les process rendrait la vie plus facile. Si un point n’était pas clair, on pouvait en discuter. Ce fonctionnement responsabilisait chacun, tout en gardant une trace pour prouver l’accompagnement.[00:39:00]

L’équipe (principalement chercheurs/stratèges) a bien participé. Le fait de tenir une trace écrite (paper trail) est crucial quand on gère un changement, sinon on ne peut pas prouver ce qui a été transmis. Seule l’équipe créa, par le passé, résistait au cadre, mais le contexte post-licenciement responsabilisait tout le monde.[00:42:00]

Si des changements créaient de la fatigue ou de la résistance, il fallait rappeler que sans chef de projet adjoint, chacun devait être autonome et à jour.

Questions/réponses sur la « fatigue du changement » : comment gérer la lassitude face à des changements récurrents, des priorités qui évoluent sans cesse, après des périodes de licenciements massifs ou de mouvements ? Avez-vous des conseils pour accompagner vos équipes, ou pour vous protéger vous-même de la lassitude ?

Dans l’enseignement supérieur, quand une crise soudaine impose un changement (ex : pandémie et passage à distance), une partie du succès repose sur la capacité de trouver des points de repère familiers dans la nouveauté. Cela rassure et facilite l’acceptation. Plus la culture est habituée à changer souvent, plus la (re)confiance dans les outils diminue. La gestion du changement devient alors un vrai enjeu culturel.[00:46:00]

Pour les équipes épuisées, il faut assumer que les choses prendront plus de temps lors de grosses transitions, et parfois accepter un « coup de frein » temporaire. En tant que chef de projet, il faut aussi modéliser le comportement attendu, et rester positif/ouvert malgré les difficultés (car son état d’esprit déteint sur celui de l’équipe). Maintenir un rythme raisonnable, donner des objectifs atteignables, valoriser le travail accompli, même plus lentement, aide à tenir le cap.[00:50:00]

Veiller à cette dynamique, accepter la baisse temporaire de productivité comme normale lors de périodes intenses de changement, faire preuve de bienveillance et de lucidité, c’est essentiel pour éviter la démotivation. Enfin, partager des bonnes pratiques, se rappeler qu’il y a des saisons, et que la progression n’est pas linéaire.[00:53:00]

Merci à tous d’avoir participé à cette discussion. C’était enrichissant d’échanger sur nos expériences, nos méthodes, et j’espère que chacun repart avec quelques outils ou idées applicables dans son organisation ou ses projets. Prochain événement : le 23 mai, forum en direct pour échanger librement sur toutes vos problématiques du moment au travail. Au plaisir de vous y retrouver, bonne journée à tous et à très vite sur Slack ! [00:54:00] [00:55:00] [00:56:00]