Faire accepter une nouvelle application web métier dans l’entreprise.

Le taux d’acceptation d’une application métier est très important pour son succès. Toute application a pour but de simplifier le métier pour rendre les utilisateurs plus performants. Les outils qui composent l’application doivent naturellement être faciles d’utilisation et centrés sur les réels besoins utilisateurs. Le développement Agile et les applications web permettent cela. Pour le premier car c’est une gestion de projet centrée sur l’utilisateur et la seconde car c’est un support multi-plateforme. Malgré tout, il arrive qu’une application ne soit pas acceptée dans l’entreprise du fait de la résistance au changement, on a tous dit un jour « j’ai toujours fait comme ça et ça marche ». Il faut faire comprendre que l’application ne remet pas en cause les méthodes de travail passées, elle est même souvent basée sur le processus métier. Elle n’a donc pas vocation a changer une méthode qui marche mais à exacerber le processus métier gagnant et performant.

Pour que le taux d’acceptation d’une application métier soit bon, voici plusieurs points non exhaustifs que vous pouvez mettre en pratique :

1. Communiquer sur la nouvelle application.

Le point de départ est d’annoncer à ses équipes que l’on va leur donner de nouveaux outils pour accomplir leurs travaux. Il faut directement entrer dans le vif du sujet et expliquer pourquoi on développe ces nouveaux outils et présenter leurs avantages. Avant même que le projet ne commence à prendre forme, ces réunions avec l’ensemble des utilisateurs (ou une bonne partie) leur permettront de se sentir intégrés au projet. Les intégrer dès le début et régulièrement permettra d’augmenter proportionnellement le taux d’adoption de l’application.

2. Intégrer des utilisateurs dans la conception.

Toute bonne conception d’application repose sur les bons principes d’ergonomie et de compréhension des utilisateurs. Mais c’est aussi une bonne manière de comprendre leur ressenti sur les éléments essentiels qui composent leur métier au quotidien. Ce dont ils ont le plus besoin ou ce qu’ils utilisent le plus souvent. Si les utilisateurs doivent passer plus de dix minutes sur une application afin de commencer à réaliser la tâche qu’ils réalisent plusieurs fois dans la même journée, alors ils ne comprendront pas pourquoi ils doivent faire ce chemin long et fastidieux.

3. Intégrer les utilisateurs dans le développement.

Le développement selon les principes Agiles doit se centrer sur l’utilisateur. Le chef du département informatique n’a qu’une vision biaisée des utilisateurs. Ce qui lui paraît simple d’utilisation ou primordial dans le processus métier ne l’est peut être pas pour l’utilisateur. Dans ce cas le développement devra être axé sur le besoin réel de l’utilisateur. L’agilité est un processus intéressant sur le fait qu’il apporte plus de transparence vis à vis de l’utilisateur par un contact direct entre le développeur et l’utilisateur. L’utilisateur porte parole doit être un utilisateur clé qui pourra synthétiser les avis de plusieurs utilisateurs, à propos de toute l’application. Selon la taille de l’application ils peuvent être un ou plusieurs.

4. Répondre aux besoins.

Cela peut paraître logique mais ce n’est pas toujours le cas. Dans un premier temps, il faut commencer à développer les fonctionnalités qui auront un ROI fort. Ce sont les primo-fonctionnalités. Les autres fonctionnalités sont par la suite intégrées et développées.

D’autres part, l’utilisateur n’a que faire d’avoir plusieurs façons de réaliser une tâche. Il veut la plus facile pour lui. Un bon exemple est Apple qui réalise des applications simples où la technologie disparaît au service de l’utilisabilité.

5. Tests.

Les tests sont souvent un peu mis à l’écart. A tort. Contrairement à ce que l’on peut penser, ce n’est pas une perte de temps par rapport au développement. Ils sont le garant que la fonctionnalité fonctionne pour chaque type de cas possible. Imaginons qu’une fonctionnalité soit bonne dans 8 cas sur 10, c’est 20% de chance que l’utilisateur n’ait pas confiance en l’application. Une batterie de tests permet un risque faible d’erreur et donc d’augmenter le taux d’utilisation et de satisfaction de l’usager.

6. Bilan: suivi des besoins.

Une fois que l’application est déployée et mise en place dans l’entreprise, il faut faire son bilan régulièrement. Le bilan doit reprendre évidemment les performances de l’application et les bénéfices mais aussi les frustrations et les éléments bloquants. Très clairement, le recueil permettra de cibler les points à reprendre et à améliorer. Il permettra aussi d’analyser les nouveaux besoins qui vont se créer et les nouvelles idées qui pourraient apparaître.

7. Stratégie de déploiement (tout d’un coup ou au coup par coup par service).

Développer une application par version est doublement avantageux. D’une part d’un point de vue économique car il permet d’étaler les coûts de l’application, et d’autre part cela donne le temps au utilisateurs d’adopter le cœur de l’application simplement. Dans la seconde version, grâce au retour utilisateur, l’application pourra être améliorée et enrichie de nouvelles fonctionnalités.

Développer l’application service par service permet aussi de faciliter la transition. Commencer par un service (exemple: commercial ou comptable) permet de ne pas se confronter à l’ensemble de la chaîne métier et se heurter à tous les groupes en même temps. Il est préférable de faire adopter un groupe qui en fera la promotion puis un autre.

Le déploiement progressif, dans la mesure du possible, permet de limiter le nombre de retours simultanés et de créer des wagons d’utilisateurs. Les utilisateurs du premier wagon une fois bien formés à l’application ne voudront plus revenir en arrière et seront à même de répondre aux questions des utilisateurs nouvellement formés.

8. Créer des groupes d’enthousiastes.

Lorsque vous allez communiquer sur votre nouvelle application, certaines personnes vont être naturellement attirées par ce nouvel outil. Ce sont des « early adopter » dans l’âme. Essayer de les repérer, ce sont souvent ceux qui posent les questions pertinentes et apportent des idées. Ils vont très vite adopter et participer à la vie du projet en l’améliorant. Il ne faut pas tomber dans l’excès à vouloir écouter tout le monde. Il faut savoir trancher.

Dans un processus continu, il pourront même devenir de véritables ambassadeurs, voir même des formateurs pour les autres usagers. Attention tout de même aux détracteurs qui pourraient passer de prime abord pour des enthousiastes alors qu’ils ne seront pas bénéfiques au projet.

De plus vos utilisateurs auront toujours plus de mal à dénigrer l’application s’ils ont pris part au processus de développement.

9. Formation courte.

La formation est un élément important pour l’acceptation de l’application. C’est de l’énergie et un certain budget qu’il faut prévoir pour former l’équipe au nouvel outil. Normalement, grâce au processus Agile et à l’implication des utilisateurs de l’application, la formation sera courte. C’est un objectif car si la formation est longue, il sera plus difficile à l’utilisateur d’adopter l’application.

10. Lutter contre la résistance au changement.

C’est le suivi, les lettres d’informations ou les différentes réunions sur le projet qui permettront l’adoption la plus large. Certains irrésistibles utilisateurs ne pourront pas s’adapter au changement. C’est toujours difficile, ces personnes doivent être beaucoup plus accompagnées. La pédagogie et la patience sont des atouts pour convertir l’ensemble de vos collaborateurs en utilisateurs.

Ce sont quelques points que nous avons remarqués lors de nos projets et des conseils que nous donnons à nos clients. Qu’en pensez vous ? Avez vous d’autres conseils pour faire accepter les nouveaux outils ? Des retours d’expérience ? On aimerait beaucoup débattre sur ce sujet !