Bizleen × Bizleen Orbit
En ligne · bizleen.com + app.bizleen.comUn seul produit, servi par deux dépôts. Bizleen, le site public, vend : carte numérique, catalogue, horaires, réservation, en neuf langues. Bizleen Orbit, l’espace connecté, exécute : heures, pourboires, congés, planning, paie estimée, sur la tablette partagée et sur le téléphone de chaque salarié. Les deux bases de données restent distinctes. Quatre surfaces partagées sont livrées et servies : la carte publique affichée en plein écran dans la tablette, le plat du jour traduit par lots, l’en-tête Orbit sur bizleen.com et le widget de réservation protégé par Turnstile. Les quatre pièces du pont (appairage, contrat de service à onze méthodes, pont de catalogue, provisionnement) sont construites et testées des deux côtés ; leur mise en service commerciale est en cours.
Un seul produit, deux dépôts
Bizleen est né le 23 mai 2026 comme une carte de visite numérique : une page publique, un identifiant, un QR, une vCard. Onze jours plus tard, le 3 juin 2026, un restaurant avait besoin d’un outil pour pointer les heures, répartir les pourboires et estimer les salaires : il est né StaffClock, et il est devenu Bizleen Orbit. Pendant juin et juillet, les deux dépôts ne se parlaient pas. Le 18 août 2026, j’ai écrit le premier des 23 documents d’échange, pour une raison commerciale avant d’être technique : le mini-site savait afficher une grille de prestations tarifées, mais il ne savait pas dire si le créneau du mardi 15 heures était libre, et cette information vivait dans l’outil qui tenait déjà le planning de l’équipe. J’ai donc cessé de parler de deux produits. Le site public vend, l’espace connecté exécute, et j’ai construit les quatre pièces du pont dans l’ordre : appairage, contrat de service à onze méthodes, pont de catalogue, provisionnement. Le 4 septembre 2026, le dernier document d’échange concluait que le côté Bizleen était terminé. Le pont est construit et testé des deux côtés ; sa mise en service commerciale est en cours. Le moteur de rendez-vous qui répondra à la question du créneau côté Orbit est, lui, en construction. Les deux bases restent distinctes : ce qui traverse est nommé, et rien d’autre ne traverse.
Décisions structurantes
Le catalogue permanent (prestations, variantes, prix, allergènes, accords) se gère dans Bizleen, parce qu’on l’édite rarement et longuement ; Orbit n’en garde qu’une projection en lecture seule. Le plat du jour se saisit dans Orbit, parce qu’on l’écrit tous les jours en trente secondes, dans l’outil déjà ouvert pour préparer le service. Le responsable ne change pas d’application au moment où il a le moins de temps, et personne ne saisit la même information deux fois.
Publier le plat du jour est un appel sortant d’Orbit ; récupérer ses traductions en est un autre. Aucune route entrante n’a été ouverte sur Orbit pour recevoir un retour de Bizleen, donc aucune signature à vérifier, aucun rejeu à craindre sur Internet. Quand le pont a eu besoin du sens inverse (une réservation à poser, un instantané de catalogue à publier), je ne l’ai pas ouvert sur le web : il passe par une liaison de service interne au compte Cloudflare, sans surface HTTP publique.
Chaque méthode du contrat prend le secret de l’établissement comme premier argument ; aucune ne résout un établissement à partir d’un slug. Orbit ne garde que l’empreinte de ce secret, Bizleen le conserve chiffré et lié à la ligne qui le porte. Un seul appairage vivant à la fois, une révocation datée plutôt qu’effacée : le jour où il faut comprendre ce qui s’est passé, l’historique est encore là.
Il aurait été séduisant d’ouvrir la fiche client au personnel présent ce jour-là. C’est un mauvais critère : la présence bouge toute la journée, et elle transforme un droit d’accès en effet de bord du planning. Les préférences et allergies restent donc réservées aux responsables et à la tablette d’accueil, et le salarié reçoit une information dimensionnée à son besoin réel : combien de couverts, quelle est la plus grande table.
Le challenge non trivial
La tentation, quand deux dépôts servent le même produit, est de leur donner une base commune, ou de construire entre eux une couche de synchronisation que personne ne teste vraiment. J’ai gardé la contrainte inverse : deux bases, et tout ce qui traverse porte un nom, une version et un propriétaire. Le catalogue appartient à Bizleen ; Orbit n’en accepte un instantané que si sa révision est strictement croissante, et ses déclencheurs refusent d’en supprimer une ligne, si bien qu’une prestation retirée reste lisible dans les rendez-vous déjà pris. Les réservations traversent dans l’autre sens par le contrat de service, avec le secret de l’établissement à chaque appel et un registre d’idempotence qui rejoue la réponse d’origine quand un appel est répété. Le plat du jour, lui, est enregistré localement d’abord, puis publié ; si Bizleen refuse le jeton ou réclame une offre supérieure, l’écran le dit dans les mots du métier au lieu d’empiler un échec silencieux. Vingt-trois documents d’échange ont fixé ces règles avant que le code ne les applique.
Leçon retenue
Un seul produit n’oblige pas à une seule base. Ce qui relie deux dépôts doit rester plus petit qu’eux et entièrement nommé : quatre surfaces, onze méthodes, un secret par établissement, aucun stockage intermédiaire hors d’une projection en lecture seule. C’est ce qui permet de déployer l’un sans redéployer l’autre, et de dire précisément ce qui est en service et ce qui ne l’est pas encore. La deuxième leçon porte sur les droits : quand on décide qui voit quoi, il faut s’appuyer sur une propriété stable de la personne, son rôle, et pas sur une propriété mouvante comme sa présence du jour. Un droit d’accès indexé sur le planning devient impossible à auditer le lendemain.
Fonctionnalités
Le formulaire est une iframe Bizleen Orbit embarquée sur bizleen.com, servie avec une CSP qui n’autorise que ce domaine à l’encadrer. La route publique ne demande aucune clé d’API : elle se défend par Turnstile, un champ piège, une limite de cadence et un opt-in par établissement. Bizleen n’a donc aucun accès à la base d’Orbit.
Le plat du jour se règle dans Bizleen Orbit, là où l’équipe prépare déjà le service, puis part vers l’API d’intégration Bizleen avec un jeton porteur propre à l’établissement. Ce jeton est un secret serveur : collé une seule fois par le super-admin, il n’est jamais renvoyé au navigateur ni visible dans les réglages de l’établissement.
La traduction est produite côté Bizleen et met de 3 à 25 secondes, l’anglais arrivant avant les autres langues. Plutôt que d’ouvrir une route entrante à défendre, Bizleen Orbit ne bloque pas la saisie et repasse chercher le résultat selon une cadence dégressive (2,5 / 5 / 9 / 14 / 20 / 27 s), en s’arrêtant dès que les langues se stabilisent.
La réservation alimente un profil client durable : visites, absences non honorées, dernière venue, tout est recalculé depuis l’historique des réservations. Les préférences et allergies restent un champ de texte libre, choix délibéré : le service note ce que le client a dit, pas ce qu’une liste déroulante avait prévu.
Réservations et fiches clients sont réservées aux responsables et à la tablette d’accueil ; le rôle salarié n’a aucun droit global, et le code refuse même de lui pousser un lien vers cet écran. Un salarié en salle reçoit un récapitulatif anonymisé de son service (nombre de couverts attendus, plus grande table), jamais un nom, jamais une allergie.
Chaque salarié a son compte personnel et une application installable sur son téléphone. En parallèle, un seul compte tablette par établissement couvre le poste d’accueil, avec deux codes distincts (serveur, manager) et une élévation de droits tracée qui expire au bout de 15 minutes. La tablette ne mémorise jamais de mot de passe, d’où une session longue et glissante plutôt qu’une reconnexion en plein service.
Le 1er de chaque mois, une tâche planifiée génère le détail des heures en PDF et l’envoie à un administrateur désigné, le comptable en copie (trois destinataires au maximum). Désactivé par défaut, activable par établissement. L’envoi est réservé par un verrou en base avant d’être effectué, avec rattrapage jusqu’au 3 du mois : jamais deux fois, jamais zéro fois.
En mode tablette, la carte publique Bizleen s’ouvre en plein écran depuis Bizleen Orbit. Le menu n’est donc jamais recopié dans l’outil interne : le client attablé et le client sur son téléphone regardent exactement la même page.
Orbit émet un secret par établissement et n’en garde que l’empreinte SHA-256 ; Bizleen le conserve chiffré, avec une donnée associée liée à la ligne et à la carte qui le portent, si bien qu’une enveloppe recopiée d’un établissement à un autre échoue au déchiffrement. Un index unique partiel garantit un seul appairage vivant ; une révocation est datée, jamais supprimée. Construit et testé des deux côtés.
Service à service, interne au compte Cloudflare, sans surface HTTP publique : publication d’instantané de catalogue, vérification de révision, capacités, disponibilité, pose, rafraîchissement et libération de retenue, confirmation, proposition et acceptation de déplacement, annulation. Le secret est le premier argument de chaque méthode, jamais un identifiant public. Construit et testé des deux côtés.
Bizleen publie ce qu’il vend ; Orbit en garde une projection en lecture seule, acceptée uniquement si la révision est strictement croissante et protégée par des déclencheurs qui refusent toute suppression. Une prestation retirée reste lisible dans les rendez-vous déjà pris, et le pont distingue « pas encore configuré » de « retiré délibérément ». Construit et testé des deux côtés.
Trois méthodes (ouvrir un espace, réémettre un appairage, lire l’état de l’espace), gardées par un secret global distinct du secret d’appairage et appelées depuis le webhook Stripe : le paiement d’un abonnement devient l’événement qui crée le compte de l’autre côté. Câblé et testé ; en cours de mise en service.