Étude de cas
Ma Certif’ Pro Santé
UI Dev IA
Concevoir de zéro un téléservice national pour un million de soignants qui n’ont rien demandé.
Volontairement flouté : le service n’est pas encore en ligne, je ne suis pas libre d’en montrer les écrans.
- Rôle
- UI / Product designer, conception from scratch des écrans professionnels de santé
- Période
- 2026 · MVP en préparation
- Contexte
- Agence du Numérique en Santé, via Atos / Eviden
- Outils & stack
- DSFR (sans thématisation) · RGAA · Prototypes HTML navigables · Driver.js
La population de ce service est très majoritairement sur le terrain, mobile, avec peu de temps écran, et elle n’a pas demandé cette obligation légale. Elle ne visitera l’application que rarement, parfois une fois par an. Concevoir pour elle, ce n’est pas « faire un dashboard » : c’est rendre une contrainte subie compréhensible en trois secondes, sur smartphone, entre deux gardes.
Les décisions
52 référentiels, une seule interface
L’hypothèse fondatrice. Chaque profession a son référentiel d’actions, rédigé par son Conseil National Professionnel sur un cadre méthodologique commun (HAS). Le projet reposait sur une hypothèse implicite : cadre commun, donc référentiels homogènes, donc une interface unique pour tous.
Ce que j’ai démontré. En croisant la donnée consolidée par l’ANS avec les 52 PDF sources, l’hypothèse s’est révélée fausse : 52 référentiels, 2 951 actions, zéro structure uniforme. La profondeur varie de 3 à 5 niveaux selon la profession, et la règle « 2 actions par axe » qu’on croyait universelle ne l’est pas : certaines professions en exigent 3, d’autres comptent en points, d’autres imposent des minimums horaires. Conséquence : impossible de coder le moteur de règles en dur, la base devait paramétrer la validation profession par profession.
Le choix. Plutôt qu’attendre une harmonisation des 52 CNP (12 à 18 mois), un tronc commun MVP pragmatique : deux critères structurels minimaux avec tolérances paramétrables, et une classification des 52 référentiels en 5 statuts, matérialisée dans un fichier d’arbitrage. Résultat : 45 référentiels intégrables en V1, 6 reportés en V2, et un référentiel découvert entièrement absent de la donnée consolidée, signalé et corrigé.
Ce que ça a changé. Le projet est passé d’un « une UI pour tous » implicite à un périmètre MVP explicite et une base paramétrable. Pas un rétrécissement : une lecture chiffrée et arbitrable de ce qui n’était qu’une hypothèse non vérifiée.
Passer d’une logique comptable à une logique de progression
L’existant affichait des fractions froides, une barre temporelle trompeuse (elle mélangeait le temps qui passe et l’avancement) et aucune action visible à l’arrivée. La refonte : un CTA principal dès l’arrivée, un countdown à la place de la fausse progression, des axes nommés en clair, un vrai moment de célébration quand le cycle est complet. Et surtout : un onboarding par thèmes, pour que personne ne se retrouve jamais seul face à 2 951 actions possibles.
Un seul panneau latéral, deux états
Plutôt que des panneaux empilés, un seul panneau à deux états (détail / édition). Pour les justificatifs, tout ou rien : rien n’est enregistré avant « Enregistrer », et la modale de garde n’apparaît qu’à la fermeture si des changements sont en cours. Plus simple à maintenir, plus propre côté RGAA.
La sémantique des états avant le pattern
Un état vide n’est pas une erreur, qui n’est pas un chargement. Un référentiel encore en cours d’écriture par la profession est un état vide légitime : pas d’alerte rouge, pas de faux chargement. Chaque choix de composant DSFR se défend en réunion sur une base d’accessibilité et de sens, jamais sur le goût. Même logique pour le tour guidé : déclenché automatiquement à la première connexion, parce qu’un tour opt-in n’est jamais vu.