Le scan de billets doit marcher sans réseau — pas « en secours »

À l'entrée d'un événement, la connexion est toujours mauvaise au pire moment. Pourquoi on conçoit le contrôle d'accès pour fonctionner d'abord hors-ligne, et pas l'inverse.

Il y a une vérité que tout le monde découvre le soir du premier gros événement : au moment exact où mille personnes arrivent devant les portes, le réseau s'effondre. Trop de monde, trop de téléphones, trop de data au même endroit. Si votre scan a besoin d'Internet pour valider un billet, vous avez un problème.

La plupart des systèmes traitent le hors-ligne comme un mode de secours — quelque chose qu'on active quand ça casse. C'est l'erreur. Chez nous, le hors-ligne est le mode par défaut, et le réseau une commodité.

Concrètement : l'appli du contrôleur télécharge la liste des billets valides de l'événement avant l'ouverture des portes. La validation d'un billet se décide localement, en quelques millisecondes, sans aucun aller-retour serveur. Le scan est instantané parce qu'il ne dépend de personne.

Le vrai défi n'est pas de valider hors-ligne — c'est d'empêcher qu'un même billet passe deux fois sur deux portes différentes qui ne se voient pas. On gère ça par une synchronisation différée : chaque validation est enregistrée localement, puis remontée dès qu'un bout de réseau réapparaît, et les appareils se réconcilient entre eux. Un double-scan est détecté et signalé, sans jamais bloquer la file.

Le résultat se mesure en secondes par personne. Sur une entrée de plusieurs milliers de participants, gagner deux secondes par scan, c'est vider une file d'attente au lieu de la laisser grossir.

Concevoir hors-ligne d'abord, c'est accepter une contrainte au départ pour ne plus jamais dépendre du réseau au moment où tout se joue. En Afrique comme ailleurs, c'est ce qui sépare une entrée fluide d'une soirée qui commence mal.