Projet

MPS Organisation

Le client

MPS Organisation organise des journées de roulage pour moto sur des circuits en France et dans les pays limitrophes. L'organisation d'événements est au coeur de leur métier et depuis de nombreuses années maintenant, nous travaillons ensemble sur leur logiciel interne.
L'objectif est clair, simplifier et fluidifier le travail en amont et pendant l'événement via la création d'un outil ultra personalisé et en constante évolution.

La problématique

Avant d'entrer sur le circuit, chaque motard doit passer par une vérification de sécurité ainsi qu'un contrôle de son groupe de niveau.
Mais avec près de 150 personnes par jour et des groupes de niveau qui changent plusieurs fois par jour, il devenait compliqué de traiter les entrées sur le circuit en un temps minimum.
 

 

Approche

Différentes solutions ont été envisagées pour permettre un contrôle rapide des pilotes. La première était d'utiliser une puce NFC que les pilotes auraient sur eux.
Une fois cette puce scannée par l'opérateur, les informations contenues à l'intérieur ou une redirection vers la base de données auraient permis les vérifications.
Deux soucis se posent avec le NFC, les terminaux de lecture n'ont pas une forte portée. Et les temps de chargements auraient été trop long, la puce NFC ne pouvant que contenir un nombre très faible d'informations.
 

Solution

La solution retenue est une PWA, une application web, qui garde en stockage interne l'ensemble des informations à afficher. L'app se retrouve autonome et n'a pas besoin de réseau pour fonctionner. Un lecteur de QRCode permet de scanner chaque pilote à son passage et de très rapidement passer à la personne suivante.

 

Wireframes du scan pour les opérateurs pitlane

 

Un des premier besoin exprimé par le client est de pouvoir faire le maximum de scans en un temps réduit (30 scans en 2-3 minutes). De ce besoin découle directement l'idée de travailler sur l'efficience, effectuer une tâche en mettant en œuvre un minimum de ressources, de faciliter le nombre d'actions à faire entre chaque scan et d'afficher via des codes couleur l'état du pilote.

Plutôt que d'installer un timer, qui permettrait au bout de x secondes de revenir vers la caméra pour effectuer un nouveau scan, on laisse le libre choix de l'action d'un nouveau scan à l'utilisateur.

Effectivement un timer aurait été source d'erreur si les informations disparaissent trop vite ou de frustration si au contraire elles mettent trop de temps à partir. Si les informations disparaissent, il faut alors refaire un scan pour les voir s'afficher de nouveau, on perd alors le gain de temps qu'aurait engendré le retour automatique via un timer.