Saff
Gestion de file d'attente pour événements et guichets : tickets numériques, écran d'appel et suivi en temps réel, en français, arabe et anglais.
Le problème
Une file d'attente physique est invisible pour l'organisateur et frustrante pour le public : personne ne sait combien de temps il reste à attendre, et l'équipe n'a aucune donnée sur ce qui bloque.
Le résultat
Un ticket numérique pris depuis un téléphone, un écran d'appel par guichet, et un suivi en temps réel côté organisateur — sans installer quoi que ce soit.
Le contexte
Aux guichets d’un événement, d’une administration ou d’un salon, l’attente se gère encore au jugé : on prend la file, on ne sait pas combien de temps elle durera, et l’organisateur n’apprend qu’après coup quel poste a saturé.
Les systèmes de gestion de file existants sont conçus pour des installations permanentes : bornes physiques, écrans propriétaires, contrat annuel. Rien de tout cela n’a de sens pour un événement qui dure trois jours, ni pour une structure qui veut tester avant d’investir.
Les contraintes
- Aucune installation. Le public prend son ticket depuis son propre téléphone.
- Trois langues, dont l’arabe en écriture droite-à-gauche sur toute l’interface.
- Plusieurs guichets en parallèle appelant sur la même file, sans jamais servir deux fois le même ticket.
- Un réseau qui n’est pas fiable : sur un site événementiel, la connexion tombe.
Les décisions techniques
L’appel concurrent. C’est le cœur du produit. Deux agents qui appuient sur « suivant » à la même seconde ne doivent jamais obtenir le même ticket. Le problème n’est pas résolu côté applicatif — il est résolu par la base, qui est le seul point où l’ordre des opérations est garanti. L’attribution d’un ticket est une opération atomique, verrouillée le temps de la transaction, et jamais une lecture suivie d’une écriture.
SQL écrit à la main, sans ORM. Sur un produit dont la valeur tient dans quelques requêtes concurrentes précises, une couche d’abstraction masque exactement ce qu’il faut voir : quel verrou est pris, pendant combien de temps, et dans quel ordre.
Le multilingue dès la première ligne. Les interfaces sont construites en propriétés logiques plutôt que directionnelles, pour que le passage en arabe ne soit pas une reprise mais un changement d’attribut. Convertir après coup coûte plusieurs jours ; le prévoir coûte quelques minutes.
Un système d’accès à plusieurs niveaux — organisateur, agent de guichet, administration du produit — avec une isolation stricte entre organisations.
Où ça en est
Le back-end et le front-end sont substantiellement construits, le panneau d’administration et le contrôle d’accès sont en place. Le produit est en bêta : il fonctionne, il n’est pas encore exploité en conditions réelles.
TODO — Ajouter, dès la première utilisation réelle : le nombre de tickets traités, le nombre de guichets simultanés, la durée de l’événement. Un chiffre issu du terrain vaut mieux que tout ce qui précède.