Retour au portfolio
Case study — Déplacements pro · 2026 Projet en cours

Voyages et notes de frais.

La bonne information au bon moment, en déplacement.

Une application mobile qui accompagne le déplacement professionnel de bout en bout : le voyage (vol, hôtel, transferts) et la gestion des dépenses (scan de reçus, soumission et suivi des notes de frais). L'app existait en deux versions natives vieillissantes — iOS et Android — refondues en une seule base de code Flutter, avec une refonte UX à la clé.

  • RôleConception UX
  • Période2026 → en cours
  • ÉquipeÉquipe design pluridisciplinaire
  • StackFlutter
Écran d'accueil de l'application — voyage à venir mis en avant, liste de tâches et bouton de scan flottant
01 — le projet

Deux apps natives, une seule base Flutter.

L'application assiste le collaborateur en déplacement : elle suit le voyage — vol, hôtel, transferts — et prend en charge les dépenses, du scan du reçu au suivi de la note de frais.

Elle existait en deux versions natives distinctes, iOS et Android, devenues vieillissantes. Le client a souhaité une refonte technique en Flutter — une seule base de code à maintenir — et en a profité pour une refonte UX complète.

Le projet est toujours en cours : ce case study porte sur la conception de l'écran d'accueil, cœur de l'application.

02 — contexte & équipe

Concevoir, et défendre ses choix.

C'est mon projet le plus récent, et le seul mené au sein d'une équipe design structurée, avec des rôles spécialisés. J'y portais la conception UX : analyse de l'application existante, exploitation de la recherche utilisateur disponible, consultation des développeurs sur la faisabilité.

Mes propositions étaient débattues et validées avec l'équipe avant d'être présentées au PM, puis au stakeholder, puis aux développeurs. Un contexte différent de mes projets précédents, souvent menés en autonomie.

Ici, la valeur était autant dans la conception que dans la capacité à défendre mes choix devant des pairs spécialisés.

03 — le défi

Un écran d'accueil « vivant ».

Donner la bonne information au bon moment, sans surcharger — pour un utilisateur souvent pressé ou stressé.

L'écran d'accueil est le cœur de l'application. En déplacement, l'utilisateur n'a ni le temps ni la disponibilité mentale de chercher : l'information utile doit venir à lui, et seulement celle qui compte à l'instant T.

D'où le principe directeur retenu pour structurer tout l'écran : prioriser par urgence temporelle, pas par importance fonctionnelle.

Prioriser par urgence temporelle, pas par importance fonctionnelle.

04 — décisions de design

Trois choix pour l'écran d'accueil.

01

Une section voyage qui s'adapte au moment

L'accueil affiche le voyage en cours s'il y en a un — étape actuelle mise en avant, deux étapes suivantes pour anticiper la suite du trajet —, un voyage à venir s'il est planifié, ou rien si aucun déplacement n'est prévu. L'information voyage est prioritaire parce qu'elle périme vite : une porte d'embarquement, une étape suivante, ça se consulte dans l'instant.

Écran d'accueil, voyage en cours : vol NCE→BCN avec carte d'embarquement, étape suivante en retard et train pour Madrid
A. La section voyage : étape en cours mise en avant, deux étapes suivantes.
02

Les tâches en second — importantes mais non urgentes

Sous le voyage, une liste de tâches — scanner un reçu, resoumettre une note de frais, dossier validé… — classées par priorité et criticité. Elles sont placées plus bas non parce qu'elles comptent moins (la gestion des frais est le cœur de l'app) mais parce qu'elles ne sont pas urgentes à la seconde : une note de frais peut être soumise plus tard. Et le même principe joue à l'intérieur de la liste : une tâche remonte et devient plus critique à l'approche de sa deadline.

Liste de tâches sous le voyage, groupées par criticité : tâches critiques puis avertissements, chacune avec son échéance
B. Les tâches, classées par priorité et criticité, remontent à l'approche de la deadline.
03

Le scan de reçu en accès permanent

Une étude informelle menée par la responsable UX, en déplacement avec ses collègues, avait fait remonter un point de friction de l'application actuelle : les utilisateurs scannent beaucoup de reçus, mais perdent du temps à retrouver le bouton de scan. J'ai traduit cet insight en décision — le scan devient un bouton d'action flottant (FAB), accessible en permanence dès l'écran d'accueil, parce que c'est l'action la plus fréquente sur mobile et qu'elle peut survenir à tout moment. On le retrouve d'ailleurs en bas à droite de chacun des écrans ci-dessus.