Il y a un an environ je suis intervenu, pour le compte d’une agence, dans une grande entreprise semi-publique pour facilité des ateliers avec les utilisateurs finaux d’une application interne de gestion des clients, une sorte de super CRM (Customer Relationship Management). J’avais donc d’un côté des ateliers avec les utilisateurs et de l’autre des ateliers avec les chefs de projets et une partie des équipes de développement. La situation m’avait été présentée comme difficile et effectivement j’ai rapidement été menacé si je ne faisais pas ce que voulait la SSII qui avait vendu la solution, ce qui a eu assez peu d’impact sur mon travail en réalité.
Je commence à travailler, à aller voir les utilisateurs, puis organiser des ateliers sur les premiers sujets qu’il faut traiter. Ça se passe super bien avec les utilisateurs. Les chefs de projets concernés sont contents du résultat qui amène une vraie réflexion de fond. Naturellement, je me retrouve à être de plus en plus sollicité. Là, je m’aperçois de plusieurs choses :
- Certains sujets sont traités en silos, alors qu’ils font partie d’un même sujet du point de vue utilisateurs et clients finaux.
- Il y a dans l’outil en développement et dans le découpage prévu des aberrations en termes d’architecture de l’information. Un même contrat peut se retrouver à plusieurs endroits sous des formes différentes. Et par exemple, la consultation, la modification et la résiliation d’un contrat se font par des chemins différents.
- Le travail avec les chefs de projets se passe très bien, mais notre travail n’est pas « compris » par les niveaux supérieurs de la hiérarchie.
Au bout d’un moment, les ateliers avec les chefs de projets prennent une étrange tournure. Les ateliers sont noyautés par la hiérarchie pour que tout se passe « bien », voir trop bien. Malgré cela, les chefs de projet dont certains sont issus du terrain, se rendent bien compte des problèmes « Mais, il va falloir 10 rendez-vous pour traiter un dossier… ». Quelque temps après la mission se conclut sur une absence de décision.
Que s’est-il passé ?
Oui, ce qui intéressant c’est de comprendre ce qui s’est passé en termes de fonctionnement du groupe. Ce qu’on peut observer c’est :
- Des informations ont été recueillies auprès de la base, mais elles n’ont pas été écoutées.
- Individuellement chacun fait son travail.
- L’entreprise est fortement hiérarchisée. Le respect de la hiérarchie est fort et le groupe se connaît depuis longtemps.
- La hiérarchie ne participe pas aux ateliers avec les utilisateurs finaux. Elle est loin du terrain.
Ces différents éléments font que le groupe va donc privilégier son fonctionnement interne à la réalisation de sa mission. Il va négliger les informations qui pourraient remettre en cause les décisions prises au début dans le choix de la SSII et du CRM. Ça permet à la hiérarchie de ne pas perdre la face et à l’organisation de continuer de fonctionner. La satisfaction des utilisateurs finaux va passer à la trappe, mais il y aura aussi probablement un autre cycle pour se trouver des excuses quand les utilisateurs montreront leur mécontentement.
L’effet Janis
En termes scientifiques, cet effet s’appelle l’effet Janis, du nom du chercheur qui l’a mis en évidence. Je cite :
» L’effet « Janis » tendrait à se constituer lorsqu’un groupe vise à établir un consensus sur la solution la plus acceptable pour sauvegarder la cohésion du groupe et éviter les discussions susceptibles d’être sources de conflit. Un certain climat de complicité cherche à s’instaurer dans le groupe. Les membres évitent de prendre des initiatives ou de suggérer des contre-hypothèses. La solution préférée initialement par le groupe est soutenue de façon sélective. Le groupe aveuglé par ses préjugés est victime de l’esprit de corps qui tend à étouffer toute pensée critique indépendante.
5 conditions prédisposent à cet effet :
- la cohésion élevée du groupe ;
- l’isolement par rapport au corps social ou à d’autres groupes ;
- l’absence de définition de la méthode dans le travail du groupe ;
- le leadership très directif ;
- la situation globale anxiogène et stressante.
2 symptômes principaux émergent :
- l’illusion collective : illusions de moralité, de rationalité, d’unanimité et d’invulnérabilité du groupe ;
- la censure collective qui s’applique à soi-même et aux autres.
4 caractéristiques signent les décisions prises par effet « Janis » :
- la pauvreté de l’information recherchée ;
- les biais et les distorsions dans le traitement de l’information et la définition des objectifs ;
- l’absence de prise en compte des risques potentiels que la décision comporte ;
- le manque de recherche d’alternatives logiques et cohérentes.
Pour qu’un groupe cohésif évite cet effet, il doit accepter les divergences, les désaccords et ne pas rejeter les arguments neufs et les solutions originales. »
Conclusion
Tous les groupes ne sont donc pas aptes à rentrer dans une démarche de design thinking. Une telle démarche peu déstabiliser des organisations. Elles ont alors le choix entre se préserver ou profiter du déséquilibre pour évoluer.
Bibliographie : La psychologie des groupes – Alain Blanchet Alain Trognon – Nathan Université
Merci pour cet article,
Il semble que d’une manière générale, il est très difficile de démarrer une démarche de design thinking ou centrée utilisateur quand les développements ont déjà démarré, entre autre dans une organisation où le principe de l’itération n’est pas réellement acquise. Cela génère de « l’inconfort » à tous les étages et donc potentiellement du conflit. C’est ce que l’on cherche généralement à éviter (alors qu’il faudrait au contraire chercher à les dénouer). Il y a là un vrai risque de rejet de la méthode (et donc plus grave, de la profession, mais c’est un autre sujet).
En qualité d’intervenant extérieur ça semblait plutôt compromis « dés le départ ». Le cadre d’action semblait « naturellement » limité par l’écosystème en place et l’avancement du projet. Cette expérience est intéressante car elle montre certaines choses. D’abord, il ne suffit pas d’avoir « envie » pour que ça marche. Le client qui fait appel à toi avait envie d’améliorer sa démarche et toi tu avais envie de « l’accompagner » (=> contrat). Seulement voilà, il n’est pas acquis que le client sache ce qu’est réellement une démarche de design thinking et que toi tu connaisses l’organisation (sa structure, son histoire, les liens entre les individus). Et c’est donc à la fin, quand le statu quo est décidé qu’on se rend compte qu’une étape essentielle a peut-être été oubliée. Cette étape, c’est l’étape où chacun prend conscience de l’écosystème l’entourant. C’est à dire l’étape où d’un côté, on doit prendre conscience de ce qu’est le design thinking et de l’autre, ce qu’est l’organisation. En réalité quand cette étape s’étale sur la durée du projet, c’est généralement déjà tard. Il faudrait commencer par ça. Mais il n’y a pas de recette miracle. Une piste possible serait de démarrer l’intervention par un atelier (si possible avec la hiérarchie) en s’appuyant sur les matrices que l’on utilise pour le Profile-T, et de commencer par faire un état des lieux, puis une projection de ce que l’on souhaite obtenir et faire. L’état des lieux est important car il permet à chaque partie de « prendre conscience » et les oblige à définir un langage commun (ainsi que la place de chacun). Dit autrement, on formalise le cadre des « envies ». Cela permet aussi de mettre le doigt sur de potentielles zones de conflits. On a plus de solutions quand on peut anticiper un conflit, que lorsqu’on est sous le feu des mitraillettes. On joue carte sur table dés le départ.
Concernant l’effet de groupe perçu, il est le signe d’un désengagement général face à l’enjeu et face à la difficulté de la hiérarchie de se « désengager » de certaines décisions passées. C’est une illusion, car il y a en réalité une vraie rupture. Il est simplement moins engageant et moins risqué à titre individuel de ne rien faire. Ça donne un sentiment de confort immédiat (mais risqué à long terme, pour la réussite du projet et donc pour l’organisation). Alors que certaines Startup savent « pivoter », d’autres organisations restent « gelées » face aux enjeux. D’où l’intérêt de travailler au plus prêt de la hiérarchie dés le départ. L’idée est aussi de leur faire intégrer certaines idées pour préparer les bases solides d’un changement de position parfois mineur mais absolument nécessaire… et donc leur donner le sentiment de construire plutôt que de celui de « se désavouer ». Même si ce n’est pas la hiérarchie qui « fabrique », on voit bien que dans certaines organisations, c’est elle qui « impulse ». A un moment donné, quand on est dans l’idée d’adapter les méthodes à l’organisation (et qu’on ne peut pas faire l’inverse), c’est là que se trouve la clé.
Dernier point, à notre époque où l’on a tendance à ériger certaines démarches de design comme recettes miracles à tous nos problèmes (je caricature un peu), je crois qu’il est sein de dire que cela peut aussi être être lent et compliqué à mettre en oeuvre, ou que tout simplement, cela peut ne pas fonctionner. Avoir envie ne suffit pas. Ce genre de retour d’expérience nous invite donc à avoir encore plus de rigueur dans notre approche… même si ce n’est pas toujours très sexy.
On pourrait penser que tout cela est en dehors du cadre initiale de la mission, mais je crois que pour la profession, ce type de problématiques relève d’une question de crédibilité à long terme.
Merci,
Olivier 🙂
Merci pour cet article, en effet je constate la même chose en intervenant en grand groupe. cependant, point intéressant, le Design Sprint lui passe beaucoup mieux, lorsqu’il est accepté.
– Le décideur, ou un validé à la décision est présent pendant le sprint. Tout peut donc être validé et avancer jusqu’à un prototype.
– Ce même prototype, avec les tests utilisateurs recueillis en sortie de sprint donne une base support et argumentaire pour la direction du pôle, par rapport à la hiérarchie supérieure. Si une équipe + Experts + Questionnaires + Tests utilisateur valident une direction, des hypothèse, le décideur supérieur à tous les « indices de risques » à disposition pour laisser suivre la démarche engagée.
Il y a encore d’autres point positifs, si tu souhaites échanger, au plaisir 🙂 Merci encore !
Bonjour,
Non, quelque soit la méthodologie, les même problèmes vont se poser. L’effet Janis n’est pas forcément conscient au sein de l’organisation. Là les décideurs ont validés la prestation et étaient sur une partie des ateliers. Ça ne change rien. Tu peux faire un joli design sprint, puis il va rester dans le carton. Rien ne sortira pour de vrai mais la hiérarchie se vantera d’avoir des méthodes innovantes et renforcera sa position.
Je comprend ton Point de vue. Je sors de 3 jours avec Auchan Drive, donc dans le genre hiérarchie on est pas mal en effet.
Après, l’avantage d’un Sprint, quelque soit les méthodes durant, reste quand même la transformation en Prototype concret, suite à réflexion de groupe + interviews experts + tests et questionnaires lors de la co-conception + Tests finaux sur un panel d’utilisateurs types.
Cela, pour l’équipe de Auchan par exemple, fait beaucoup de Data, et donc d’éléments pour convertir l’efficacité de ce genre de travail en euros pour les dirigeants.
Donner un indice risque fiable et chiffré, comme ils aiment tant !
Je ne dis pas qu’il vont réussir à tout faire passer en une fois, mais la répétition, les influences interne et externe, cela va donner du poids et ensuite rentrer dans les esprits des dirigeants qui auront leur indice confiance suffisamment haut pour dérouler.
Cela ne voudra pas dire qu’il sauront vraiment ce que c’est, il sauront juste que c’est efficace en terme d’euros et gestion de leurs ressources humaines…
C’est quelque part aussi triste que la réflexion du bien-être en entreprise seulement pour optimiser la « performance », mais peut-être est-ce sur le chemin de quelque chose de meilleur, en tout cas, j’aime à y croire, cela donne de la dynamique 🙂
Bonjour,
Comme toi je constate dans de grands groupes que l’on se gargarise de mots à la mode, que l’on accepte (en surface) des méthodologies qui ont bonne presse, mais que dans les faits toutes les inerties sont là. Un peu (beaucoup ?) l’impression de servir de faire-valoir sur certains projets… Entre les décisions impactantes prises sans avoir étudier le sujet de près avec les utilisateurs et qu’il va falloir coute que coute mettre en musique, et les ateliers utilisateurs conduits pour se donner bonne conscience en monde « on en a fait, donc on ne pourra pas nous dire que nous n’écoutons pas » … Ou encore : c’est bon un des services de la SI s’appelle « User experience », on y parle de parcours, c’est bien la preuve que nous sommes ouverts… Sans parler des stagiaires d’école utilisés pour couvrir le besoin UX de projets à fort enjeux internes …
Je ne connaissais pas cette théorisation du fonctionnement de groupe par Janis ; merci pour cet apport.
Si le concept de « designwashing » n’existe pas, c’est peut-être le moment de l’inventer 🙂