Encore une nouvelle appli ? Une nouvelle procédure ? Et pourtant : tout a été planifié avec soin — le calendrier du déploiement, la communication, la formation. Et malgré cela, j’assiste régulièrement à la même scène : les utilisateurs ne souhaitent pas ou peu adhérer.
Je ne parle pas seulement de protestations ouvertes ; je parle de silence et d’inertie, de ce « on fait mais on n’y croit pas ». Je me suis demandé : et si ce n’était pas eux le problème, mais plutôt la façon dont nous abordons le changement ?
Je ne prétends pas détenir la vérité ; je suis simplement convaincue que cette résistance est trop souvent traitée comme une anomalie à corriger ou comme une simple étape de « change request » plutôt que comme un signal à écouter.
Pourquoi cette résistance ? Au delà des causes classiques
Les explications communes
Vous avez sans doute lu les guides sur la conduite du changement ou les causes d’échec des projets de système d’information : manque de communication, de formation, d’implication. Bien sûr, ces éléments sont centraux. Dans l’article de Prosci « Comprendre pourquoi les individus résistent au changement », on y lit : « la principale cause de résistance est le manque de sensibilisation à l’objectif et à la raison d’être du changement. ».
Les causes plus structurantes et souvent ignorées
Mais d’expérience, je vois aussi autre chose :
- La perte de repères : l’ancien outil ou la vieille méthode n’était pas parfait(e), mais il/elle était connu(e). Le nouveau impose l’inconnu (et ça fait peur).
- La crainte de perdre statut, autonomie ou compétence : pour certains, le changement est perçu comme une menace directe à leur identité professionnelle. (source : INSPQ)
- Une certaine forme de clairvoyance utilisateur : j’ai rencontré des utilisateurs qui ralentissent parce qu’ils pressentent que l’outil ne va pas simplifier leur flux, ou qu’il va compliquer ce qu’ils maîtrisent déjà. Alors oui, on peut penser qu’ils ne sont juste pas adaptables… mais parfois, c’est leur expérience qui s’exprime intuitivement.
- Le biais du statu quo : l’idée que « on garde ce qui marche », même imparfait, plutôt que d’adopter ce qui pourrait marcher mais qui est incertain. (source : Status Quo Bias in Users Information Systems (IS) Adoption and Continuance Intentions: A Literature Review and Framework)
Cela m’amène à poser un constat : nous avons souvent cherché à « faire adhérer » au changement (de force?). Et si, parfois, la vraie question était de prendre le temps pour réfléchir : comment le changement est‑il vécu, perçu, reçu ?
Ma posture après des années en tant que Business Analyst
A mes débuts dans la business analyse, je considérais que mon rôle consistait essentiellement à formaliser les besoins, et à faire le pont entre métier & IT.
Avec le temps, j’ai compris que mon rôle pouvait (devait ?) être plus large : celui de « détectrice » de tensions invisibles, interprète des réticences et facilitatrice d’adhésion sincère (voire enthousiaste) des utilisateurs.
Je suis tombée plusieurs fois dans ce biais couramment rencontré en gestion de projet : penser qu’ “il suffit” de former, communiquer, et qu’ “ils” adhéreront. Mais mes retours terrain m’ont appris que ce qui se passe ensuite dépend largement de la façon dont le changement est vécu.
Quand les utilisateurs me disent : « Oui, j’ai été formé(e), j’ai reçu l’accès… mais je ne l’utilise pas. », je les entends dire autre chose : « Je ne vois pas ce que cela change pour moi. »
Et c’est là une omission trop fréquente : on parle “valeur pour l’organisation”, et “valeur pour l’utilisateur”. Mais concrètement, va-t-on en vérifier sur le terrain et sur le long terme le gain concret ?
Comment anticiper la résistance : quelques pistes concrètes
Je ne propose pas de recette miracle. Ce sont des pistes issues de mes expériences et de lectures (sources en fin d’article):
- Impliquer tôt… et vraiment : pas seulement valider une maquette, mais co‑concevoir, offrir aux utilisateurs une vraie place dans le projet. Cela renvoie à un futur « fait par nous » plutôt que « imposé à nous ». Et ne croyez pas que seules les approches agiles le permettent. C’est un état d’esprit.
- Identifier les relais volontaires : ceux qui croient, s’investissent, peuvent devenir porte‑parole auprès de leurs pairs. Ces ambassadeurs sont fondamentaux.
- Communiquer autrement : la communication ne se fait pas qu’avec des slides. En tant que BA, nous devons nous approprier les processus métier, le jargon, les émotions ressenties et l’expérience vécue par nos utilisateurs. Puis intégrer ces éléments dans nos échanges, que nous pouvons illustrer de « récits métier », d’exemple terrains.
- Mesurer l’adhésion réelle : suivre l’usage réel, et ne pas arrêter son rôle une fois la formation utilisateurs achevée. Par exemple : « Combien de fois l’outil a‑t‑il été sollicité ? Quelles tâches ont été réalisées ? Quels retours spontanés ? »
- Se mettre à leur place : j’ai parfois invité les utilisateurs à endosser le rôle de concepteurs. À travers un exercice de simulation ou de brainstorming (voire de brainstorming inversé), ils repensent l’outil comme s’ils devaient convaincre leurs collègues de l’utiliser. Cela révèle très vite ce qui coince ou manque de sens.
La résistance comme signal (et non plus comme obstacle)
J’ai vu des organisations investir dans des outils ultra complexes (processus digitalisés, ergonomie repensée, valeur métier)… et constater que, sur le terrain, l’outil était finalement contourné, ignoré ou non adopté.
Pourquoi ? Parce que personne ne s’était demandé comment ce changement serait reçu.
Alors au lieu de vouloir “faire passer” le changement, pourquoi ne pas chercher à co‑habiter avec la réalité terrain ?
Pas en intellectualisant le processus, mais en le vivant.
Cela implique parfois de ralentir, de revenir, d’ajuster. Ce n’est pas confortable et la vision « court-termiste » n’aime pas ce qui ne va pas vite. Ce n’est pas “agile” au sens pur. Mais est‑ce plus durable ? Je crois personnellement que les projets les plus solides sont ceux qui ont su s’ajuster quand “ça freine” plutôt que de forcer coûte que coûte.
Pistes contre-intuitives?
- La résistance n’est pas toujours mauvaise. Elle peut être un signe d’intelligence collective, un appel à repenser le changement.
- Trop de participation peut nuire à la clarté. Si l’on cherche à intégrer toutes les opinions, on peut se retrouver avec un projet incohérent ou trop lent à exécuter. Parfois, décider nécessite de trancher. Je vous avoue que, personnellement, cette piste contre-intuitive m’est délicate, tant j’aime rendre les utilisateurs unanimement satisfaits. Mais parfois, en voulant plaire à tout-le-monde, on finit par ne plaire à personne.
- Et si je me voyais chef d’orchestre en vue de faciliter l’adhésion plutôt que “simple collecteur de besoins” ? Cela change ma posture et mes interactions.
- Une dernière : et si on arrêtait de sur‑surveiller l’adoption ? Ce que je veux dire, c’est que parfois, ne vaut-il pas mieux laisser les utilisateurs s’approprier l’outil, le détourner même, et en faire quelque chose d’adapté à leur quotidien opérationnel ? Parfois la “subversion” est un moteur d’amélioration.
Conclusion : et si on écoutait vraiment ?
Je ne dis pas que c’est facile. Ni que toute résistance est légitime. Certes, il y a des freins structurels, des sabotages volontaires, des projets mal conçus. Mais je suis convaincue que c’est dans ces zones d’inconfort, dans ces moments où “ça ne passe pas”, que naissent les projets les plus solides.
Alors : dans votre prochain projet, que ferez‑vous quand ça râle en réunion, quand les tickets support s’accumulent, quand les utilisateurs font “semblant” d’adhérer ? Les ferez‑vous taire ? Ou choisirez‑vous d’écouter … vraiment ?
Sources
- « Les 12 raisons de la résistance au changement », Beeshake. (Beeshake)
- « Les facteurs de résistance au changement en entreprise », Appvizer. (Appvizer)
- « Résistance au changement : les 5 étapes pour y faire face », Culture‑RH. (Culture RH)
- « Comment vaincre la résistance au changement en entreprise », Wayden. (Wayden)
- « Mieux comprendre les sources de résistance au changement », Revue Gestion. (revuegestion.ca)
- « Le concept de résistance au changement », CÉTO / HEC Montréal. (INSPQ)
- « Les refontes d’interface au défi de la résistance des utilisateurs », Medium. (Medium)
