Files
siop2/docs/00-vision/personas.md
pr-daaif 04e61056f6 docs(r0): kickoff SIOP V2 — vision, cadrage, charte graphique, maquettes HD
Refondation design-first du projet SIOP (v1 gelée) :
- Playbook 00-vision (charte projet, personas, benchmark Atlas)
- Playbook 01-cadrage (releases R0→R5 + DoD, user-story map, exigences, risques)
- Playbook 02-design : charte graphique, tokens.css bi-thème (palettes
  analytics validées CVD/contraste par script), maquettes HD navigables
  (7 écrans dont démo-login DEMO_MODE, bilan codé, portail QR, mobile)

Prochaine étape : validation des maquettes par le référent avant tout code.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-15 21:06:33 +01:00

3.3 KiB

Personas — SIOP V2

Rôle de ce document (playbook) : un persona n'est pas une fiche décorative — chaque écran conçu en phase design doit pouvoir répondre à « quel persona, quelle tâche, quel contexte ? ». Les rôles applicatifs (matrice de permissions) dérivent de ces personas.

P1 — Salma, dispatchrice (bureau)

  • Contexte : au bureau SPELEV, 2 écrans, toute la journée dans l'application.
  • Tâches : recevoir les demandes, créer/assigner les OT, surveiller les urgences, relancer les techniciens, préparer les bons de commande.
  • Douleurs : jongler entre téléphone et papier ; ne pas savoir qui est où ; urgences « personne bloquée » à traiter en secondes.
  • Attentes produit : tableau de bord temps réel, création d'OT en < 30 s, assignation en 1 clic, alertes visibles.
  • Rôle applicatif : Dispatcher (tout voir, tout créer/éditer, pas d'administration).

P2 — Ahmed, technicien itinérant (terrain)

  • Contexte : en déplacement, souvent en sous-sol sans réseau, gants, pressé.
  • Tâches : consulter ses OT du jour, scanner le QR en cabine, dérouler la checklist du mois, saisir le bilan codé, faire signer le client, repartir.
  • Douleurs : réseau absent, ressaisie au bureau le soir, carnet papier perdu.
  • Attentes produit : mobile offline-first, gros boutons, checklist en 2 taps, synchro automatique au retour du réseau.
  • Rôle applicatif : Technicien (ses OT, saisie terrain ; « voir autre » limité).

P3 — Karim, gardien d'immeuble (demandeur)

  • Contexte : occasionnel, smartphone, aucune formation à l'outil.
  • Tâches : signaler une panne (photo à l'appui), suivre l'avancement.
  • Douleurs : ne sait pas si sa demande a été vue ; rappelle 3 fois.
  • Attentes produit : portail ultra-simple (ou scan du QR en cabine → formulaire prérempli), suivi du statut sans jargon interne.
  • Rôle applicatif : Demandeur (ses demandes uniquement, rien d'autre).

P4 — Nadia, gestionnaire (back-office)

  • Contexte : mi-temps sur l'outil ; responsable stock, achats, contrats.
  • Tâches : inventaire, seuils et réappro, bons de commande, tiers, documents (certificats, notices), coûts par équipement.
  • Attentes produit : tables efficaces (tri/filtre/export), alertes de stock, bibliothèque documentaire rangée.
  • Rôle applicatif : Gestionnaire (stock, achats, tiers, fichiers ; lecture OT).

P5 — M. Bennis, direction (lecture)

  • Contexte : consulte 1 fois par semaine, souvent sur mobile.
  • Tâches : indicateurs (pannes, coûts, taux de préventif, réactivité), décisions contrat/renouvellement de parc.
  • Attentes produit : tableau de bord lisible en 30 s, tendances, export.
  • Rôle applicatif : Vue seule (analytics + lecture).

P0 — L'administrateur (transverse)

Paramètre l'instance : utilisateurs, permissions, référentiels du bilan codé, gabarits de périodicité. Rôle Administrateur (tout). C'est aussi le compte de démonstration par défaut du sélecteur DEMO_MODE.


Correspondance personas → rôles de la matrice : Administrateur, Dispatcher, Technicien, Technicien limité (variante « voir autre » restreinte de P2), Gestionnaire, Demandeur, Vue seule — 7 rôles seedés dès R0, tous accessibles en 1 clic via le sélecteur démo.