Profils et parcours

Cette page décrit qui utilise BlockLucky et comment. Elle croise deux sources : les profils de travail et le parcours conçus par l'équipe dans son livrable « Recherche utilisateurs et parcours » (dossier 03, daté du 6 novembre 2026), et les rôles et écrans réellement implémentés dans le code.

#Les profils de travail

Le livrable de recherche définit quatre profils hypothétiques. Ce ne sont pas des personas validés : l'équipe précise qu'ils gardent le statut d'hypothèses tant que les entretiens et les tests n'ont pas eu lieu. Ils servent au recrutement des testeurs et à la conception des écrans.

La cible principale reste celle du kickoff : les 18 à 35 ans, soit 35 % des 120 000 habitants. Le livrable marketing ouvre le dispositif à tous les adultes pour répondre à l'objectif d'inclusion.

#Le protocole de recherche prévu

Le seuil de décision pour envisager un pilote (hypothèse H03) est d'au moins 4 parcours réussis sans aide critique et 4 reformulations correctes sur 5. Une double confirmation ou un montant mal compris est un incident critique à corriger avant toute ouverture. Ces tests restent à réaliser.

#Les rôles dans le code

Le modèle de données connaît trois rôles (énumération Role de backend/prisma/schema.prisma). Les visiteurs non connectés forment un quatrième profil.

La redirection après connexion est faite par homeForRole dans frontend-web/src/hooks/useAuth.ts. Le contrôle réel des droits est fait par le backend : requireRoles de backend/src/middlewares/rbac.middleware.ts relit le rôle en base à chaque requête et refuse un administrateur qui n'a pas activé la double authentification. La matrice complète est dans Autorisations et matrice des droits.

#Le parcours principal du citoyen

L'équipe a conçu un parcours en six étapes, chacune instrumentée par un événement analytique. Le tableau reprend la conception du livrable et indique ce que fait le code.

sequenceDiagram
    participant C as Citoyen
    participant W as Frontend web
    participant B as Backend
    participant K as Contrat BlockLucky
    C->>W: Ouvre la page municipale
    C->>W: Lit les règles
    C->>W: Saisit son email et confirme sa majorité
    W->>B: POST /auth/login
    B-->>C: Code à 6 chiffres par email
    C->>W: Saisit le code
    W->>B: POST /auth/2fa/verify
    B->>B: Crée le portefeuille et verse la dotation
    C->>W: Confirme l'achat d'un ticket
    W->>B: POST /lottery/buy
    B->>K: buyTickets signé par le portefeuille du citoyen
    K-->>B: Événement TicketsPurchased
    B-->>W: Ticket confirmé et 50 EtherPoints
    K-->>B: WinnerPicked après le tirage VRF
    B-->>W: draw:winner en temps réel

Ce diagramme suit le web. Sur le web, un compte dont l'âge n'est pas vérifié voit à la billetterie une alerte qui mène à /profil/identite, où il envoie le recto et le verso de sa pièce. Sur mobile, la connexion passe par POST /auth/signup ou POST /auth/signin, puis l'application ouvre d'elle-même l'écran de vérification d'âge tant que la pièce n'a pas été envoyée ou a été refusée (voir Navigation et écrans). L'achat n'est possible qu'après la décision de la Mairie.

Les étapes antérieures à la connexion envoient des événements anonymes. Le livrable demande aussi qu'un nouvel appui après une erreur reprenne l'état existant pour éviter les doublons : c'est le rôle de l'en-tête Idempotency-Key accepté par POST /api/v1/lottery/buy.

#Les états à couvrir

Le livrable liste six états à tester. Le code les traite ainsi :

#Les parcours secondaires du citoyen

#Le parcours du commerçant partenaire

flowchart LR
    A["Connexion espace pro"] --> B["Créer son établissement"]
    B --> C["Créer une offre en EtherPoints"]
    C --> D["Importer des codes promo CSV"]
    D --> E["Valider un code en caisse"]
    E --> F["Suivre la consommation"]

Le commerçant se connecte depuis /connexion?espace=pro. Il crée son établissement, actif dès sa création (la Mairie peut ensuite le suspendre), puis des offres (titre, coût en EtherPoints, stock, date d'expiration facultative). La date d'expiration est enregistrée dans Redis mais n'est vérifiée nulle part : une offre expirée reste échangeable. Il importe des codes promo par fichier .csv ou .txt d'au plus 1 Mo, valide en caisse le code présenté par le citoyen et suit le taux de consommation. Chaque action est vérifiée contre la propriété de l'établissement (ownerId). Voir Partenaires.

#Le parcours de la Mairie

L'administrateur se connecte depuis /connexion?espace=pro. Tant qu'il n'a pas activé la double authentification, le backend refuse toutes les routes d'administration avec une réponse 403 : la première étape est donc /profil/securite/2fa.

Le détail est dans Administration Mairie et Disjoncteur.

#Les parcours hors application