École de conduite Easy Driving : un moteur de réservation qui ne peut pas réserver la même voiture deux fois

Easy Driving School offre la préparation à l’examen routier de la SAAQ depuis trois centres du Grand Montréal — Laval, Kirkland et Henri-Bourassa — et a formé plus de 1 100 élèves depuis 2015. Les réservations arrivaient par téléphone, par texto et en personne, puis étaient réconciliées à la main avec la disponibilité des moniteurs et une petite flotte de véhicules à double commande.

Une leçon de conduite est un objet d’horaire plus difficile qu’il n’y paraît. Chaque réservation doit tenir ensemble un élève, un service, un centre, une plage horaire, un moniteur et une voiture précise. N’importe lequel de ces éléments peut changer à court préavis, et se tromper signifie qu’un élève se présente pour une location d’examen et que la voiture n’est pas là.

L’exigence la plus difficile était la concurrence d’accès. Deux personnes qui réservent la dernière place au même centre au même instant ne doivent pas réussir toutes les deux. Sur une plateforme sans serveur, où les requêtes sont traitées par de nombreux processus isolés, « vérifier puis écrire » est une situation de compétition qui attend un samedi achalandé.

La deuxième contrainte, c’étaient les moniteurs. Ils géraient déjà leur vie professionnelle dans Google Agenda et n’avaient aucun intérêt pour un deuxième système à tenir à jour. Toute solution exigeant de maintenir leurs disponibilités à deux endroits aurait été abandonnée en un mois, et l’horaire serait redevenu faux.

La troisième, c’étaient les élèves. Ce sont surtout des adolescents et des nouveaux arrivants qui réservent quelques leçons. Tout ce qui exige un compte, un mot de passe et un courriel de confirmation en fait perdre une part réelle exactement au moment où ils étaient prêts à payer.

Et au Québec, le fonctionnement bilingue n’est pas optionnel, tandis que la Loi 25 fixe de véritables attentes sur la collecte et la conservation des renseignements personnels — y compris ceux de mineurs.

Un parcours de réservation public qui fonctionne sans compte. L’élève choisit un centre et un service, puis réserve ; un lien peut présélectionner les deux, de sorte que l’école peut envoyer quelqu’un directement au bon formulaire depuis une publicité ou un texto. La gestion ultérieure passe par un jeton haché à usage unique plutôt que par une connexion.

Un moteur de disponibilité qui comprend le domaine réel : centres, services, capacité mutualisée quand n’importe quel moniteur qualifié convient, et ressources nommées quand une voiture ou une personne précise est requise. Tampons, exceptions et périodes de fermeture sont de premier ordre plutôt qu’ajoutés après coup.

Un verrou de réservation implémenté comme un Durable Object par centre et par date locale. Les vérifications finales de capacité pour un jour donné à un centre donné sont sérialisées par un coordonnateur unique, ce qui rend la double réservation structurellement impossible plutôt que simplement improbable.

Une intégration Google Agenda par OAuth, avec liste des agendas, requêtes FreeBusy et création d’événements. Les moniteurs continuent de gérer leurs disponibilités là où ils vivent déjà ; le système lit leur état d’occupation réel et écrit une invitation canonique pour l’élève, plus des événements de blocage internes pour le moniteur et le véhicule.

Un portail d’administration conçu pour un téléphone, parce que le propriétaire est rarement à un bureau : une vue du jour, la liste des réservations, des commandes d’urgence pour une voiture en panne ou un moniteur malade, ainsi que la gestion des centres, des services, des ressources, des formulaires et de la rétention.

Une analytique de revenus pour les propriétaires — un rapport et un tableau croisé que l’on peut découper par service, centre, moniteur, forfait, jour de semaine ou mois, avec courbe de tendance, suivi d’objectif, export CSV et forage de n’importe quel chiffre jusqu’aux réservations qui l’ont produit. L’accès est contrôlé : les revenus sont visibles pour les propriétaires et les administrateurs, pas pour le personnel.

Un site web public bilingue, comme application statique distincte, qui lit en direct les données de centres, de services, de forfaits et de disponibilité depuis l’API de réservation plutôt que de les dupliquer.

Aucun compte élève. La décision la plus lourde de conséquences du projet. Les comptes auraient facilité plusieurs fonctions et auraient coûté des réservations à l’école. La gestion par jeton haché donne à l’élève tout ce dont il a besoin — reporter, annuler, consulter — sans rien à retenir ni mot de passe à réinitialiser.

Sérialiser la vérification de capacité, pas toute la réservation. Un verrou large aurait rendu le système lent précisément aux moments les plus achalandés. Le restreindre à un centre pour une date locale garde la garantie là où la justesse compte vraiment et laisse tout le reste concurrent.

Rejoindre les moniteurs dans Google Agenda. Nous aurions pu construire une meilleure interface de disponibilité que Google Agenda. Elle n’aurait pas été utilisée. Lire FreeBusy depuis l’agenda qu’ils tiennent déjà fait que l’horaire reflète la réalité sans demander à personne de changer ses habitudes — le même raisonnement qui a mis WhatsApp au cœur de NextiaDriveOps.

Anonymiser pour la vie privée, agréger pour l’analytique. Une tâche quotidienne de rétention retire les renseignements personnels des réservations historiques tout en préservant les dimensions sur lesquelles reposent les rapports de revenus. L’école garde son analyse d’une année à l’autre ; les dossiers cessent de contenir le numéro de téléphone d’un adolescent longtemps après la leçon. Traiter la rétention comme une donnée de conception plutôt que comme une corvée de conformité est ce qui rend les deux possibles.

Une première version volontairement étroite. Pas de comptes élèves, pas de suivi de progression, pas de paiements, pas de CRM, pas d’automatisation de messagerie, pas d’IA. Chacun a été discuté et chacun a été exclu, parce qu’un système de réservation juste et utilisé vaut mieux qu’une plateforme encore en construction.

La plateforme de réservation et le site public sont tous deux en production, bilingues de bout en bout, sur Cloudflare Workers avec D1 et Durable Objects. Les règles de disponibilité — exigences de ressources, exceptions, tampons, agendas occupés, capacité sérialisée, formulaires et rétention — sont couvertes par une suite de tests automatisés, parce que la logique d’horaire est exactement le genre de code qui casse en silence.

La partie transférable est le motif plutôt que le domaine : un problème de réservation sous contrainte de capacité, une main-d’œuvre qui n’adoptera pas un deuxième outil, une clientèle qui ne créera pas de comptes, et un propriétaire qui doit voir ses revenus par dimension. Cela décrit une grande part des entreprises sur rendez-vous.