Contexte : mission menée chez Apave. Mon rôle : discovery, cadrage, parcours de déclaration, conception mobile, back-office et prototypage.
Deux faces d’un même service
Alerte Santé Sécurité permet de signaler une situation dangereuse depuis le terrain, puis de la traiter dans un back-office. Ces deux usages n’ont rien à voir. Sur le terrain, la personne qui déclare est parfois pressée, parfois stressée, souvent sur son téléphone. Au bureau, la personne qui traite doit qualifier, prioriser et suivre de nombreux signalements.
Mon parti pris a été de concevoir les deux faces du service ensemble, pour que le contexte saisi sur le terrain arrive intact jusqu’à celui qui le traite.
Côté terrain : déclarer vite, sans se tromper
L’écran d’accueil existant reposait sur deux gros boutons, avec beaucoup d’espace inutilisé, une hiérarchie faible et des libellés sans contexte. Je l’ai remplacé par une entrée orientée tâches : deux cartes d’action qui expliquent clairement l’intention, une navigation basse simplifiée, un menu latéral et l’accès au profil.
J’ai aussi exploré une variante qui assume une hiérarchie terrain plus forte : le signalement de situation dangereuse devient la carte principale, l’action secondaire passe au second plan, l’historique est résumé et les détails s’ouvrent dans un panneau qui monte depuis le bas de l’écran. L’objectif : réduire le temps de décision et rapprocher l’action la plus fréquente du pouce.
- des entrées explicites plutôt que des boutons sans contexte ;
- une progression par étapes et un contrôle avant envoi ;
- des états visibles pour chaque contrôle (survol, appui, focus, actif) et un bref état de chargement à l’ouverture d’un parcours ;
- une mise en page plafonnée à la largeur d’un téléphone, pour ne jamais trahir la composition mobile.
Côté back-office : qualifier et prioriser
Pour le traitement, j’ai repris l’architecture fonctionnelle de l’écran existant des situations dangereuses (navigation latérale, barre d’actions, recherche, filtres, sélection et tableau) en l’alignant sur le design system Apave. Le tableau reste dense, parce que c’est un outil de travail, mais il reste accessible : action de création clairement identifiée, actions secondaires hiérarchisées, focus visibles.
Ne rien inventer
Une règle a guidé tout le projet : ne pas simuler des contenus métier qui n’étaient pas encore documentés. Lorsque les besoins d’un parcours manquaient, l’interface affichait un état explicite plutôt qu’un faux contenu. C’est moins spectaculaire en démonstration, mais c’est ce qui évite de valider par erreur des décisions que personne n’a prises.
Résultats
- Une nouvelle entrée mobile orientée tâches, et une variante plus directive pour comparer les approches.
- Un prototype de back-office aligné sur le design system Apave, dense mais accessible.
- Des prototypes HTML publiés dans le site de consultation des écrans UX d’Apave, aux côtés de l’Espace Client.
- Un journal de décisions qui documente chaque choix, ses raisons et son impact.
Ce que j’en retiens
Un service de signalement ne vaut que par sa continuité. Une déclaration rapide qui arrive mal qualifiée ne sert à rien, et un back-office parfait ne compense pas une déclaration abandonnée. Concevoir les deux faces ensemble, c’est ce qui permet de préserver le contexte du terrain jusqu’à la décision.
Show Comments