Les outils de travail se rapprochent de leurs utilisateurs

Partager

Le POC, ou Proof of Concept, est un procédé qui intègre les futurs utilisateurs d’une solution dans son processus de test et de validation. À la clé : un applicatif pensé pour ceux qui s’en servent et donc plus rapidement adopté par les collaborateurs.

 

Daniel Gonçalves, Senior Manager chez Orange Consulting, explique comment cette démarche est mise en place chez les clients d’Orange Business Services.

Éclairages / En quoi consiste la démarche de Proof of Concept ?
Daniel Gonçalves / Le POC consiste à tester les fonctionnalités,  l’ergonomie et/ou les performances techniques d’un outil auprès de ses futurs utilisateurs avant d’envisager un déploiement plus large. Ce test se fait sur une durée limitée et, autant que possible, dans des conditions proches de la réalité : on peut toutefois tester une version incomplète de la solution ou mener le POC sur un échantillon représentatif de la population utilisatrice…

E. / Comment cela se déroule précisément ?
D.G / La démarche dépend largement du type de solution à tester et des ambitions du projet. Les tests peuvent se dérouler sur une journée ou plusieurs semaines, impliquer un petit nombre d’utilisateurs ou une population vaste, vérifier un ou plusieurs produits…

Le POC doit répondre à des objectifs mesurables définis en amont du lancement.

Pour structurer le POC, on peut définir une démarche en 4 étapes clés :

  • la définition de la situation cible à laquelle doit aboutir le projet,
  • la définition des objectifs du POC et de ses modalités,
  • la mise en œuvre de la phase de tests,
  • la phase de bilan qui validera les enseignements du POC et permettra de statuer sur l’opportunité du déploiement.


E. / Quels sont les avantages du POC par rapport à une démarche de déploiement classique ?
D.G / En confrontant le projet à la réalité du terrain avant son déploiement, le POC permet de rectifier ou d’améliorer l’outil, ou de lever le doute sur la pertinence du projet. Les collaborateurs, en tant que futurs utilisateurs, vont valider l’adéquation du projet à leurs besoins, ce qui modère les risques de rejet. Observer le comportement des testeurs permet enfin d’anticiper l’accompagnement des utilisateurs à prévoir lors du déploiement.

E. / Et si les utilisateurs invalident le projet, le POC ne risque-t-il pas de bouleverser son déroulement ?
D.G / Cela fait partie des règles du jeu. Dans les faits, le choix d’une solution informatique est souvent dépendant d’un existant technique et d’un schéma directeur. Les outils sont alors choisis avant même que les besoins n’aient été détaillés avec les métiers. Les POC sont un moyen rationnel d’orienter le choix, en mettant dans la balance l’expérience utilisateur. Par exemple, l’un de nos clients souhaitait mettre en place une plateforme collaborative pour quelques dizaines de milliers de collaborateurs. Lors d’un POC, trois solutions concurrentes ont été soumises à un échantillon de 100 personnes. Après une journée de test, les collaborateurs ont désigné un outil qui n’était pas celui pressenti par les équipes projet. À l’échelle de plusieurs dizaines de milliers d’utilisateurs, l’impact d’une telle remise en cause était loin d’être neutre ! Mieux vaut le savoir en amont du projet que de le constater par une faible utilisation par la suite.

E. / Quels sont vos conseils pour un POC réussi ?
D.G / Pour être pertinent, le POC doit être mené dans des conditions proches de la réalité. Cela suppose un investissement temps de la part de testeurs, qui peuvent n’avoir accès qu’à un nombre limité de fonctionnalités, voire faire face à certains dysfonctionnements. Toutefois, le but n’est pas de faire le test parfait, mais bien d’apprendre et de prendre les bonnes décisions. Cela suppose de faire simple, si possible court, de rythmer la démarche et mesurer ce qui a de l’importance. L’enjeu est donc de bien clarifier les objectifs, le périmètre et les modalités du POC, dès le début, pour éviter les frustrations et pour obtenir un feedback de qualité.

En outre, il faut être prêt à assumer les conséquences du test, et accepter par exemple qu’un POC ne débouche pas systématiquement sur un déploiement. Si la démarche met en évidence le manque de valeur ajoutée d’un projet, les testeurs peuvent avoir le sentiment d’avoir perdu leur temps… pourtant ils en ont fait gagner à leur entreprise !


Pour aller plus loin

>> Le collaboratif, colonne vertébrale de l'entreprise agile ?

>> Leroy Merlin : une démarche communautaire "maison" !