Un QR code, ce n'est jamais qu'une image. Et une image, ça se copie. Alors comment ScanPass garantit-il qu'un billet présenté à l'entrée est authentique, à usage unique, et n'a pas été modifié ? La réponse tient en trois mots : signature cryptographique asymétrique.
1. Ce qu'il y a dans un QR code ScanPass
Le QR code n'encode pas une URL ni un identifiant simple : il contient un payload signé qui inclut l'identifiant unique du billet, l'identifiant de l'événement, la catégorie de billet, la date d'émission et une signature numérique générée avec une clé privée détenue uniquement par nos serveurs.
À la lecture, l'application Scan extrait ces données et vérifie la signature en utilisant la clé publique correspondante (embarquée dans l'app). Si un seul caractère du payload a été modifié — date, identifiant, catégorie — la signature ne correspond plus et le billet est rejeté immédiatement.
2. Pourquoi la capture d'écran ne marche pas
Beaucoup d'utilisateurs pensent qu'il suffit de prendre une capture d'écran de leur billet et de la partager pour que deux personnes entrent. C'est techniquement faux dès le premier scan validé : ScanPass marque le billet comme « utilisé » dans la base de données serveur, et toute deuxième présentation (même depuis l'original) est rejetée avec une alerte visuelle.
L'app Scan affiche le nom du porteur enregistré, l'heure du premier scan, et l'appareil utilisé : impossible pour un contrôleur d'être trompé par une copie. Et comme le QR contient une signature, on ne peut même pas créer un faux QR « du bon format » : il faudrait connaître la clé privée.
3. Le mode hors-ligne (offline-first)
Sur un site sans 4G fiable (festival en pleine nature, salle souterraine, sous-sol parisien), l'app Scan continue de fonctionner. Elle vérifie la signature cryptographique localement (sans appel serveur), enregistre les scans validés en base locale, et synchronise dès que la connexion revient.
Conséquence importante : un billet validé hors ligne sera bien marqué comme utilisé, mais s'il est présenté simultanément sur un autre point de scan également hors ligne, les deux scans pourront être acceptés localement. Le serveur détecte ensuite le conflit et flag les deux entrées pour vérification manuelle. C'est rare en pratique, mais documenté.
4. Et la revente entre particuliers ?
Si l'organisateur autorise les transferts, l'utilisateur passe par la fonction « Transférer ce billet » dans l'app : un nouveau QR signé est généré pour le destinataire, et l'ancien est invalidé serveur. Aucun risque que les deux soient acceptés.
Si l'utilisateur revend hors plateforme (en envoyant son PDF à un acheteur sur Marketplace), le QR original reste fonctionnel… jusqu'à ce que l'un des deux scanne en premier. Le second arrivé est refusé. C'est une protection passive mais redoutablement efficace contre la fraude à la revente.
5. Que faire si un participant est rejeté par erreur ?
L'app Scan a un mode « override admin » qui permet à l'organisateur principal d'autoriser manuellement une entrée même si le QR est rejeté (cas typique : doublon dû à une mauvaise manip). Chaque override est loggé avec horodatage, scanner et raison, ce qui protège l'organisateur en cas de litige.
6. Conclusion
La signature cryptographique combinée à la base serveur centrale rend la fraude pratiquement impossible sans complicité interne. C'est un standard que peu de billetteries grand public implémentent vraiment (beaucoup se contentent d'un identifiant aléatoire dans l'URL), et c'est une vraie différenciation pour les organisateurs sensibles à l'anti-revente.