Skip to content Skip to sidebar Skip to footer

Comment simplifier un processus de gestion des dépenses dans un organisme de recherche

Retour d’expérience sur la phase de cadrage UX dans un projet de développement agile

Contexte du projet

Le client est un centre de recherche industriel dédié au manufacturing. Sa vocation est d’améliorer la compétitivité des filières industrielles stratégiques en France en proposant des ruptures technologiques sur les procédés de fabrication. C’est ainsi que des projets de recherche sont mis en place en partenariat avec un ou plusieurs acteurs de l’industrie.

Ces projets font l’objet de situations de dépenses, qui doivent être suivies et validées par les contrôleurs de gestion du centre de recherche. Actuellement, ce suivi est effectué via des feuilles Excel accompagnées de pièces jointes qui sont échangées par email.

Objectif de notre client autour de son développement applicatif

Ce workflow de validation des dépenses fonctionnait très bien au moment du lancement du centre de recherche en 2012, mais fait aujourd’hui face à un problème de volumétrie : Avec plus de 120 membres et près de 90 projets, le procédé n’est plus adapté. Pertes d’informations, erreurs dans les saisies, relances permanentes… Les temps de traitement pour finaliser les dépenses des projets ont explosés.

La décision a été prise de faire appel à Inside Group pour automatiser le processus dans une application web.

L’approche Digital’hub et la phase de cadrage

En accord avec le client, le choix a été fait de développer l’application selon la méthode Agile utilisée par Digital’Hub. Nous avons ainsi mis en place une équipe de 3 développeurs (2 back, 1 front), avec un Proxy Product Owner en support du PO côté client, assuré par un contrôleur de gestion.

Avant de commencer le 1er sprint – et en parallèle du « Sprint 0 » pour la mise en place du socle technique par l’équipe tech – le Proxy PO Digital’Hub a entamé une démarche de cadrage en 6 étapes inspirée du Design Thinking :

Cycle de développement applicatif agile
Cycle de développement applicatif agile

La 1ère étape (La Vision Produit) nous a permis d’aligner les différents acteurs – décideurs et métiers – sur le problème à résoudre et l’objectif à atteindre. Pour cela, nous avons utilisé le Lean Canvas V2 de Jeff Gothelf. Pour rappel, il s’agit d’un schéma synthétique représentant sur une seule page le « Business Model » du projet : Identification du problème à résoudre, panel d’utilisateurs, outcomes, hypothèse de solution, etc. Nous l’avons utilisé durant un atelier regroupant décideurs et responsables métiers, où chacun l’a d’abord rempli individuellement. Ensuite, les résultats ont été mis en commun dans un Lean Canvas unique. Le proxy PO côté Digital’Hub a joué le rôle de facilitateur.

Grâce aux premiers panels d’utilisateurs identifiés dans ce Lean canvas, nous avons entamé la phase de recherche utilisateurs. L’objectif ici est d’identifier les différents Personas et de mieux comprendre leurs activités dans ce processus de gestion des dépenses. Pour cela, nous avons interviewé un chef de projet, un contrôleur de gestion et un acteur de l’industrie. Nous avons ensuite réalisé un diagramme d’activité de l’ensemble du processus pour chacun d’entre eux.

Ayant maintenant une bonne vision du problème à résoudre et connaissant les utilisateurs, il était temps de passer à la phase d’idéation. Pour cela, nous animé un atelier appelé le Six-To-One, pour faire émerger un maximum d’idée. Le principe est de réunir les différents acteurs et de les faire dessiner un maximum de 6 croquis dans un délai restreint. Ils doivent être réalisés différemment les uns des autres pour stimuler l’imagination et la faculté à trouver des solutions. Ensuite, une deuxième phase commence ou chacun doit rassembler dans un unique croquis, les meilleures idées réalisées dans les 6 précédents.

A partir de ce travail mené en atelier, les UI Designer avaient de la matière pour travailler sur un 1er prototype de solution. Ce prototype a ensuite été testé par le panel d’utilisateurs identifiés dans la phase de recherche pour recueillir leur feedback et apporter les modifications nécessaires.

Ue fois le prototype validé, un atelier de StoryMapping a été mené par le Proxy PO en coopération avec le PO côté client. L’objectif d’un StoryMapping est de décortiquer le besoin et de ranger les différentes fonctionnalités par thème et par priorité. Durant l’atelier, chaque participant (PO, métier, technique) vont disposer des post-it représentant chacun une fonctionnalité, sur un tableau :

  • L’axe chronologique horizontal décrit les différentes actions réalisées par l’utilisateur.
  • L’axe vertical représente les fonctionnalité par ordre d’importance, les plus hautes étant en haut, les moins importantes en bas.

En plus des fonctionnalités, cet outil nous donne également une 1ère roadmap des différentes release. Ce StoryMap est ensuite conservé tout au long du projet et peut être amené à évoluer.

Une fois cette phase de cadrage terminée, il y a toute la matière pour commencer à travailler sur le 1er Sprint. Nous avons aussi la certitude que la solution apportée est la bonne puisqu’elle a été testée et co-créé par les utilisateurs. Le Proxy PO Digital’Hub peut commencer à rédiger les 1ères User Story, qui seront ensuite validées par le PO côté client. Les développements peuvent démarrer.

La solution livrée

Après 3 sprint de développement de 3 semaines chacun, la solution a été livrée et déployée en production. Le bilan est satisfaisant, puisque d’après les estimations, la mise en place d’une application web pour valider les situations de dépense a permis de passer d’un temps de traitement de 3 semaines à 10 jours en moyenne.

Développement applicatif agile
Développement applicatif agile