TempsFrais (Apave) : reconstruire une application métier dense sans perdre le réel

Contexte : mission menée chez Apave, groupe spécialisé dans la maîtrise des risques. Mon rôle : audit, cartographie des rôles, architecture, parcours, UI, cas limites, responsive et préparation du handoff.

TempsFrais : un outil interne au cœur du quotidien

TempsFrais est l’application interne d’Apave dédiée aux temps et aux frais : saisie de la semaine, déplacements, frais à justifier, validation et contrôle. Derrière un même outil se croisent des réalités très différentes : collaborateurs, managers, gestionnaires de frais en agence et en centre de services partagés, gestionnaire du parc automobile, administrateurs, direction et support informatique.

Chacun y vient avec une intention précise : déclarer sa semaine, valider celle d’une équipe, contrôler une dépense, corriger un compte rendu. L’application devait être reconstruite sur Angular Material et sur les fondations du design system Apave, sans perdre les règles métier qui font sa valeur.

L’enjeu : rendre visibles les règles sans alourdir l’interface

Une application de temps et de frais est dense par nature. Statuts, délégations, contrôles, justificatifs, rôles : tout compte. Le risque d’une refonte est double. Soit on simplifie au point d’effacer des règles indispensables, soit on empile les contrôles jusqu’à rendre chaque écran illisible.

Mon objectif était donc de rendre visibles les règles, les statuts et les contrôles sans augmenter la charge cognitive, et de traiter le mobile comme un usage à part entière plutôt qu’une réduction du desktop.

Méthode 1 : partir du produit réel, pas d’une page blanche

Le premier travail a été un audit complet de la matière existante. Elle était riche : plan de l’application, cartographie des rôles et des accès, correspondance entre rôles et écrans, notes sur les patterns d’interface, notes techniques et captures classées par rôle. Le problème n’était pas le manque d’information, mais un signal mélangé : des références utiles côtoyaient des exports mal formés, des documents vides et d’anciens essais.

J’ai classé chaque élément (à garder, à déplacer, à refondre, à archiver), réorganisé l’espace de travail par phase, et surtout fait apparaître les angles morts. Les captures se concentraient sur les managers, tandis que plusieurs rôles, comme les gestionnaires de frais, le parc automobile ou le support, n’étaient documentés par aucune capture. Savoir ce que l’on ne sait pas était une condition pour ne rien inventer.

Méthode 2 : penser en familles d’écrans

Plutôt que de redessiner écran par écran, j’ai regroupé l’application en onze familles, chacune décrite par son objectif, ses rôles, ses blocs de contenu, sa densité d’interaction, sa fréquence d’usage et ses irritants visibles :

• le cadre de l’application et la navigation ;
• les tableaux de bord selon le rôle ;
• les tableaux de données denses, les filtres et la recherche ;
• les formulaires, les fiches détaillées et les blocs de workflow propres à chaque rôle ;
• les statuts, badges et alertes ;
• les exports, les paramètres et les pages de support.

Cette grille a permis de décider où standardiser (là où l’existant était simplement incohérent) et où refondre plus fortement (là où la structure était réellement faible), sans changer le comportement métier que les utilisateurs connaissent.

Méthode 3 : appliquer le design system Apave et Angular Material

La reconstruction s’appuie sur les tokens sémantiques du design system Apave et sur Angular Material, avec une référence HTML commune pour la densité, la typographie et le comportement des composants. Quelques règles ont structuré les décisions :

• Desktop d’abord pour les tâches de gestion, avec un cadre de page, une hiérarchie et des espacements homogènes ;
• une densité maîtrisée : contrôles compacts réservés aux tableaux et aux barres d’outils, taille standard ailleurs, cibles tactiles d’au moins 44 px dans les contextes mobiles ;
• une séparation claire entre les chips interactives et les badges de statut, en lecture seule ;
• un tableau de données type : recherche, filtres et export en barre d’outils, actions de ligne discrètes, pagination.

Une décision structurante : organiser l’interface autour de la semaine

La décision la plus importante a été d’organiser l’interface autour de la semaine, de la mission et de l’activité réelle, plutôt qu’autour de la structure technique des données. Chaque semaine devient un compte rendu suivi par statut, ce qui permet à chacun de voir immédiatement ce qui est en cours, en retard, rejeté ou approuvé, et ce qui l’attend.

Méthode 4 : le mobile comme usage à part entière

Réduire un tableau dense à la taille d’un téléphone ne produit pas une application mobile. J’ai donc défini le mobile à partir des tâches réellement utiles en déplacement : consulter, vérifier un statut, valider rapidement, saisir une information simple.

Quatre premiers écrans servent à valider la direction (cadre de l’application, aperçu rapide, fiche détaillée, revue de validation), avec des règles d’adaptation explicites : la navigation latérale devient une barre supérieure avec menu, les tableaux denses deviennent des listes empilées, les filtres se regroupent dans un panneau, et chaque bloc ne garde qu’une action principale. Les écrans d’administration lourds restent volontairement sur desktop.

Résultats

• Un audit classé de toute la matière existante, avec les angles morts identifiés par rôle.
• Une feuille de route en cinq phases : audit, référence produit existant, application de la fondation, préparation de la reconstruction, préparation mobile.
• Une cartographie en onze familles d’écrans qui guide les priorités de reconstruction.
• Des prototypes desktop et mobile et une base de patterns partageable avec les métiers et l’équipe de développement avant la reconstruction technique.

Ce que j’en retiens

Sur une application métier dense, la qualité d’une refonte se joue avant le premier écran : dans la capacité à distinguer ce qui relève du comportement métier, à conserver absolument, de ce qui relève d’une incohérence d’interface, à corriger. Partir du produit réel, nommer les angles morts et formaliser les règles avant de dessiner évite d’inventer, et rend chaque décision défendable auprès des métiers comme des développeurs.