Étude de cas : Développement d’une application de gestion de dossiers nommé « PACMAN »

Notre client, une filiale d’un grand groupe français avec qui nous travaillons depuis quelques années, nous sollicite pour développer une application de suivi des dossiers. Si le produit délivré répond aux attentes, il sera ensuite porté au niveau National et sera accessible par les autres agences du territoire.

Le contexte

Le client manage une équipe de cinq personnes, et doit suivre les dossiers traités par son équipe.

La saisie de ces dossiers dans l’application existante permet au responsable d’équipe de suivre l’avancement des dossiers, mais aussi de réaliser un document statistique (pdf) qu’il réalise à partir d’exports Excel.

L’application existante, qui se limite à des formulaires de saisie, est inadaptée à la réalité du métier. Elle s’est transformée en une immense base de données, qu’il fallait ensuite retraiter manuellement dans des tableaux Excel.

Nous avons déterminé avec le client les problèmes que la nouvelle application devait résoudre :

• Les interfaces ne sont pas ergonomiques : la saisie des dossiers est longue et fastidieuse
• Les marqueurs de suivi des dossiers ne sont pas adaptés à la réalité du métier.
• La production du document statistique nécessite de nombreuses opérations manuelles, et est extrêmement chronophage.

Nous avons ainsi pu définir Le « quoi » et le « comment » pour garantir le meilleur retour sur investissement (ROI) : Revoir les interfaces pour une saisie simplifiée (gain de temps) et produire des tableaux de bord en temps réel pour suivre la qualité des dossiers.

Nous commençons alors avec le client l’élaboration du cahier des charges :

• Quels sont les données utiles au bon suivi d’un dossier pour améliorer le suivi des dossiers
• Quelles sont les statistiques à produire pour réaliser le rapport statistiques trimestriel
• Quels sont les règles métiers à implémenter dans les interfaces pour améliorer l’ergonomie des interfaces

Un métier complexe qui milite pour la mise œuvre d’une expérimentation

Les échanges avec le client ont révélé un métier complexe, avec de nombreuses règles et exceptions.

Nous décidons donc, avec le client, de réaliser très rapidement un MVP (de l’anglais : minimum viable product) : Une version du produit limitée qui permettra d’obtenir un maximum de retours client avec un minimum d’effort.

Nous commençons donc la conception d’un projet d’expérimentation avec  peu de graphisme et des interfaces simplifiées : Cela nous permettra de voir très rapidement si nous allons dans la bonne direction.

Enfin, nous conserverons tout le code du MVP afin de construire dessus la version définitive de l’application. Ainsi nous ne perdons pas le temps associé à la conception et au développement du MVP.

Bilan de l’expérimentation

Suite à l’utilisation du MVP, nous nous rendons compte que le module d’affectation est une fonction peu pertinente compte tenu de la taille des équipes : En effet le ROI, temps de saisie / bénéfice rendu, sur le module d’affectation est trop faible.

Aussi, si la fonction de suivi est pertinente, nous déciderons de ne pas réaliser le module d’affectation afin de réaliser d’autres choses plus utiles et de ne pas surcharger l’application.

A l’inverse, nous comprenons que le module de suivi des aléas (erreurs) est une fonction clé :

• Ce sont les aléas qui créent les tensions entre les bureaux d’étude et le pôle cartographique.
• La performance du pôle cartographique en terme de mise à jour (et le respect des délais) dépend principalement de la qualité des dossiers fournis et de la fluidité des corrections

Les aléas sont les indicateurs clés pour la production de statistiques.

Chez OMG, nous ne séparons jamais totalement la phase de conception de la phase de développement, et le besoin se dévoile au fur et à mesure de la réalisation de l’application

Allotissement et définition des sprints

Nous avons définit avec l’aide du client le cahier des charges : les règles métiers, mais aussi les rôles et droits utilisateurs.

Après la phase de spécification réalisée par l’équipe de développement, nous avons découpé le projet en lots. En accord avec le client, nous avons décidé de réaliser 5 lots que nous avons livrés toutes les 2 semaines.

Un sprint comprend le développement et la livraison d’un lot sur la plateforme de recette.

Sprint 1 : Adaptations du MVP

Nous avons pris en compte le bilan réalisé sur le MVP : supprimé le code inutile et ajouté les améliorations souhaitées.

Sprint 2 et 3 : Statistiques

Les statistiques est le point le plus important du projet : il est donc nécessaire de bien identifier les données à exploiter et comment les interpréter correctement. Nous avons fait une livraison à mi-parcours (2 Sprint) afin de pouvoir ajuster rapidement le travail en cours.

Sprint 4 : Intégration graphique (Design)

La phase de conception du design était une gérée en parallèle du projet. C’est lors de nos réunions hebdomadaires, nous présentions aussi  l’avancement du travail graphique.

Nous avons néanmoins créé un sprint et une livraison, pour l’intégration graphique.

Sprint 5 : Pages d’administration

Les interfaces d’administration, n’impliquant que peu de retours clients, ont été réalisées en fin de projet.

L’UX Design concerne tout le travail sur l’ergonomie des interfaces.

Nous avions noté le besoin d’une ergonomie simple pour les utilisateurs, afin que l’outil puisse leur faire gagner du temps. C’est pourquoi nous avons travailler très en amont sur des maquettes très détaillées, que nous avons fait valider par le client.

La conception graphique s’est déroulé en parallèle de la phase de développement en suivant la même méthodologie AGILE.

L’application est un outil interne, sans accès extérieur. Nous n’avions donc pas besoin de travailler une image de marque, avec une réflexion poussée sur les cibles. Nous nous sommes donc contentés de réaliser un logo et des guidelines, néanmoins travaillés avec soin par notre graphiste, afin que l’application reste élégante.

Afin de se différencier des autres applications, grises et ennuyeuses, le client nous avait néanmoins fait part d’un volonté d’un graphisme « fun »

l’acronyme « PACMAN » nous a immédiatement amené vers le personnage de jeu vidéo, que nous avons stylisé.

Le client a tout de suite été convaincu par la proposition initiale, et a ensuite choisi la déclinaison qu’il préférait.

La phase de conception graphique se termine par la production d’un document, délivré au client : Le brandBook

Ce document est nécessaire pour réaliser l’intégration graphique : Il contient tous les éléments graphiques que peut contenir l’application.

Mais il est aussi utile lorsque l’on souhaite faire évoluer l’application dans le temps, pour conserver une unité graphique globale.

Nous avons mis en place une architecture avec un « back » qui s’occupe de toute la gestion de la base de données, et un « front » qui s’occupe de l’affichage.

L’avantage de cette architecture est que l’on peut aisément changer le « front » sans avoir à changer le « back ».

De plus, le « back » fournit les données via API que le front exploite. Ainsi cette API pourrait être exploité par ailleurs par une autre application dans le cas où nous devrions « servir » ces données au sein d’un système d’information plus étendu.