MotoGate

Un pilote se présente à l’entrée, son laissez-passer sur son téléphone. Voici tout ce qui se passe entre le moment où la caméra le voit et celui où la barrière s’ouvre — ou non.

Lu dans scan_ticket_page.dart, participation_repository.dart et la liste des fonctions Supabase. Chaque nom ci-dessous figure tel quel dans le code source.

1. 01

   Le laissez-passer est sur le téléphone du pilote

   Le code ne porte que trois champs : quel événement, quel billet, quel numéro de téléphone. L’écran passe à la luminosité maximale pour rester lisible en plein soleil, et le système reçoit l’ordre de refuser toute capture d’écran.

   • qr_flutter
   • screen_protector
   • FLAG_SECURE
2. 02

   Un commissaire le scanne

   La caméra lit le code et le téléphone vibre dès qu’il tient quelque chose — avant tout verdict. Cette première vibration dit au commissaire de ne plus bouger plutôt que de continuer à viser, et c’est l’essentiel de ce qui fait avancer une file.

   • mobile_scanner
3. 03

   Deux contrôles avant même le réseau

   Un code auquel il manque l’un de ses trois champs est refusé sur place, tout comme un laissez-passer parfaitement valide mais destiné à un autre événement. Ni l’un ni l’autre ne demande un aller-retour : les erreurs courantes reçoivent une réponse immédiate.

   • eventId
   • ticketCode
   • phoneNumber

   ▸Ce qui s’affiche en cas de refus

   « Invalid ticket » ou « Ticket does not belong to this event ». Ce sont deux refus, et tous deux sont consignés.

4. 04

   L’événement est relu depuis le serveur

   La décision ne repose jamais sur ce que le téléphone qui scanne a en mémoire. L’événement est rechargé avec ses invitations, leurs accompagnants, ses équipes, leurs membres et son journal de scans — le tout sous row-level security, si bien que les droits du commissaire décident de ce qui revient.

   • events
   • event_invites
   • event_invite_companions
   • event_teams
   • event_team_members
   • event_scan_logs

   ▸Ce qui s’affiche en cas de refus

   Au bout de douze secondes, « Verification timeout ». L’échec est fermé : un réseau lent ne devient jamais une barrière ouverte.

5. 05

   Le porteur est identifié

   Le code du billet et le numéro de téléphone sont confrontés aux invitations, aux accompagnants qui y sont rattachés et aux membres d’équipe. Si ce numéro correspond à un compte enregistré, le nom du compte remplace celui saisi sur l’invitation — le commissaire lit donc le vrai nom de la personne.

   • profiles
6. 06

   L’historique du billet est vérifié

   Chaque scan antérieur de ce code est examiné. Une seule validation précédente, ou une seule dérogation de superviseur, et le laissez-passer est épuisé. C’est ce qui empêche la capture d’écran d’un QR valide de faire entrer trois amis.

   • event_scan_logs

   ▸Ce qui s’affiche en cas de refus

   « Ticket already used » — affiché avec qui l’a scanné et quand, pour que le commissaire tranche sur place.

7. 07

   La règle de licence est posée à la base de données

   Pour un concurrent, la licence doit être valide le jour de l’événement. Cette règle est une procédure stockée, pas du code applicatif : elle ne se discute pas à l’entrée et une ancienne version de l’application ne peut pas la contourner.

   • participation_entry_check

   ▸Ce qui s’affiche en cas de refus

   « Licence not valid on the event date », avec le motif renvoyé par la base.

8. 08

   Le verdict, et la trace

   Accordé ou refusé, avec la liste des accompagnants auxquels le porteur a droit. Une vibration légère pour l’acceptation, forte pour le refus, afin de le sentir sans regarder. Puis chaque tentative est consignée — refus compris, et une dérogation de superviseur enregistrée sous son propre statut plutôt que discrètement comme une réussite.

   • record_scan_log
   • success
   • failed
   • overriden