ADR-0007 — Vues par persona, instigation pour compte, retraitements de données¶
Statut : accepté (2026-06-12, arbitrages user). Contexte : jusqu'au Jalon 3, le rail de navigation était identique pour tous les personas (échafaudage du Jalon 2). Or la vue client doit être façonnée par son parcours réel — solliciter, corriger ses données, suivre, recevoir — pas par les outils internes du cabinet. Ce cadrage précède le chantier « ingestion RH réel + rapport livrable ».
🎯 À retenir
Trois arbitrages. (1) Navigation par persona : le client voit « Mes demandes » + le Référentiel en lecture ; le staff voit le Cabinet et les outils, l'externe gardant Labo et Ad-hoc. (2) Instigation : un senior ouvre une demande pour le compte d'un client (dans le tenant client, jamais d'usurpation, journalisée). (3) Retraitements journalisés : le fichier RH brut est une pièce d'audit jamais modifiée — les corrections mineures sont consignées sur une photo dérivée par le client seul, les erreurs structurelles imposent un re-téléversement.
Décision 1 — Navigation et écrans par persona¶
| Entrée | Client | Junior | Senior | Externe |
|---|---|---|---|---|
| Tableau de bord | ✓ | ✓ | ✓ | ✓ |
| Mes demandes | ✓ | — | — | — |
| Cabinet | — | ✓ | ✓ | ✓ |
| Studio DBO · Labo · Ad-hoc | — | ✓ | ✓ | ✓ |
| Référentiel | ✓ (lecture) | ✓ | ✓ | ✓ |
| Corbeille | — | ✓ | ✓ | ✓ |
- Le Référentiel reste visible au client (lecture seule) : la transparence normative — sur quelles normes s'appuie l'étude — est un argument de confiance, pas un outil interne.
- L'externe garde le labo et l'ad-hoc : un auditeur qui peut contre-calculer indépendamment est un meilleur auditeur.
- Les pages outils sont gardées côté serveur (
lib/sessionServeur.ts) : un client qui force l'URL est renvoyé au dashboard ; un staff qui ouvre « Mes demandes » est renvoyé au Cabinet. Le backend reste l'autorité sur les données (les permissions fines par route = Jalon 4).
Décision 2 — Instigation : demande « pour le compte d'un client »¶
Un senior peut ouvrir une demande pour un client qui ne peut pas accéder à la plateforme (accord informel, problème technique ponctuel).
- C'est une action, pas un écran : carte « Nouvelle demande pour un client » au panneau Actions du Cabinet (pattern établi).
- La demande naît dans le tenant du client (
POST /api/demandes/pour-compte, gardé senior) ; le tenant est créé à la volée si inconnu. - Jamais d'usurpation (esprit ADR-0003) :
creee_par_cabinet=truesur la demande, événementcreation_pour_compteau journal immuable (acteur réel = le senior, visible client), badge « Ouverte par le cabinet » dans « Mes demandes » du client.
Décision 3 — Corrections de données : retraitements journalisés¶
Pour le chantier ingestion (à venir) : le fichier RH brut téléversé est une pièce d'audit — il n'est jamais modifié.
- Erreurs mineures (format, doublon de matricule, virgule décimale…) : corrigeables dans l'interface, consignées comme retraitements journalisés (qui, quoi, avant/après) sur une photo dérivée ; le brut reste intact. C'est la pratique actuarielle réelle (retraitements documentés en annexe du rapport).
- Erreurs structurelles (colonne manquante, fichier illisible) : re-téléversement obligatoire.
- Le client seul saisit les retraitements (la responsabilité de la donnée reste contractuellement chez lui) ; le staff recommande.
- L'annexe « Retraitements des données » du futur rapport PDF se génère depuis ce journal.
Alternatives écartées¶
- Écran « Demandes clients » dédié au senior : un écran de plus à entretenir pour une action ponctuelle — le panneau suffit.
- Édition libre in-app du fichier RH : divergence silencieuse entre la source et le calcul — inacceptable pour une chaîne d'audit.
- Re-téléversement seul : défendable (responsabilité 100 % client) mais UX rugueuse ; les retraitements journalisés gardent la traçabilité ET la fluidité.