En ligne app.bizleen.com
Bizleen Orbit
L’espace de travail de l’équipe, dans Bizleen.
En clair
Bizleen Orbit (anciennement StaffClock) est un produit de Bizleen : l’espace de travail connecté de l’équipe, pointage, pourboires, salaires estimés, congés, planning, événements, notifications et documents, servi sur la tablette partagée de l’établissement et sur le téléphone de chaque salarié en 14 langues.
Né pour un restaurant, il sert aujourd’hui onze verticales avec neuf modules livrés, un moteur de réservation par couverts, et un moteur de rendez-vous en cours d’unification. Un Worker Cloudflare unique : Hono 4, React 19, Drizzle, D1, R2, trois Durable Objects. En ligne sur app.bizleen.com, relié à Bizleen par un SSO bidirectionnel actif en production ; le domaine historique staffclock.app reste servi.
Points forts
-
SSO bidirectionnel actif en production
Depuis le 16 septembre 2026, le SSO Bizleen est actif en production dans les deux sens : une session sur bizleen.com ouvre app.bizleen.com sans mot de passe, et depuis app.bizleen.com un gérant rejoint Bizleen Studio ou Insights par un jeton à usage unique valable 60 secondes, avec révocation en cascade tracée dans l’audit.
-
Niveau d’espace (interne / autonome)
Contrat definirNiveauEspace : un établissement en gestion interne coupe la prise de rendez-vous publique autonome sans rien perdre de son cahier ni de ses droits.
-
Barre de navigation à 5 cases personnalisée
Barre mobile plafonnée à 5 cases claires avec libellés toujours lisibles ; le gérant choisit lui-même ses onglets épinglés sous le doigt (ongletsEpingles).
-
Règles de politesse rigoureuses
Tutoiement du salarié sur son espace personnel et son calendrier ; vouvoiement strict de la direction, des gestionnaires et des prestataires indépendants.
-
Styles d’icônes & mode sombre étendu
Style d’icônes au choix par appareil (au trait ou plein/couleur) dans les réglages ; thème sombre étendu aux prestataires et à la tablette partagée.
-
Réabonnement push web automatique
L’application se réabonne seule en cas de perte de souscription push, affiche l’état réel de l’appareil et offre un désabonnement clair.
-
Pointage en un geste
Tablette de consultation partagée en salle, PIN serveur et PIN manager, entrées journalières, lieux de travail. Les gros boutons viennent du premier restaurant : il faut pouvoir pointer en plein coup de feu.
-
Pourboires en 3 modes
Trois modes de répartition mémorisés jour par jour, un axe distinct pour les espèces, règlements hebdomadaires idempotents : un règlement rejoué ne paie jamais deux fois.
-
Salaires estimés
Calcul, exports, envois de paie programmés, clôtures mensuelles : chaque salarié voit son estimation, l’établissement clôture son mois.
-
Congés & planning
Demandes de congés avec validateurs désignés, planning de quarts, échanges entre salariés et patrons de repos.
-
Espace salarié en 14 langues
Espace personnel traduit en 14 langues d’équipe, gardé par des empreintes cryptographiques pour empêcher toute désynchronisation.
-
Moteur de rendez-vous fiabilisé
Clôture de prestation en 1 clic, plancher temporel strict, prise en compte des absences et ciblage des demandes d’avis Google (< 3 jours).
En chiffres
- 9 Modules livrés
- 11 Verticales servies
- 13 990 Cas de test
- 87 Tables en base
- 113 Migrations SQL
- 573 Points d’entrée API
Le récit
Pourquoi j’ai construit ça
Un restaurant comptait ses heures sur une application lente, avec un sélecteur d’heure impossible à manier en plein coup de feu ; les pourboires par carte étaient répartis à la main et les salaires estimés au doigt mouillé. J’ai construit l’outil le 3 juin 2026 pour ce besoin précis, sous son premier nom : pointage à gros boutons, répartition automatique au centime près, salaires estimés, clôtures formelles.
Une fois l’outil en place pour un établissement, je l’ai ouvert à plusieurs (superadmin, établissements, administrateurs invités par courriel), puis à onze verticales servies par des axes de comportement plutôt que par le nom du métier. Par-dessus le pointage sont venus les congés, le planning de quarts, l’événementiel, les notifications, les documents et la paie estimée : neuf modules livrés.
En août 2026, le raccordement au site public Bizleen a commencé, parce qu’un mini-site sait afficher une grille de prestations mais pas dire si le créneau de mardi 15 heures est libre, et que cette information vit dans l’outil qui tient déjà le planning.
L’outil est devenu Bizleen Orbit sur toutes les surfaces que le client voit : application, manifeste, courriels, logos, et le domaine app.bizleen.com. Le 16 septembre 2026, le SSO unifié avec Bizleen a été allumé en production dans les deux sens, complété par sept canaux RPC. Le tout tourne dans un Worker Cloudflare unique, avec 300 310 lignes de test pour 301 870 lignes de production.
Décisions techniques structurantes
Une tablette partagée en salle, et des rôles qui la modélisent
Dans un restaurant, l’appareil qui pointe n’appartient à personne : c’est une tablette posée au passe, que tout le monde touche. Les rôles d’Orbit partent de cette réalité au lieu de la contourner. La tablette est un poste de consultation partagé ; un PIN serveur ou manager élève les droits le temps d’un geste, et cette élévation est tracée.
Le téléphone de chaque salarié est son espace privé : ses heures, ses pourboires, ses congés, rien d’autre. Côté données, 74 tables sont cloisonnées par établissement, et l’entrée du superadmin dans un établissement est tracée dans l’audit.
Onze verticales servies par des axes de comportement, pas par le nom du métier
Orbit ne teste jamais « si restaurant alors ». Chaque métier est décrit par des axes purs : traceur privé, primes médicales, pourboires, relevé solo, organisateur d’événements. Une verticale est une combinaison de ces axes, et ouvrir un douzième métier est un travail de configuration, pas une duplication de code. C’est ce qui a permis de passer d’un restaurant à onze verticales sans forker le moteur.
Des couches vérifiables et un domaine sans effet de bord
Le serveur est découpé pour que la séparation se vérifie, pas seulement se déclare : 46 fichiers de routes (573 verbes) qui ne portent que la validation et l’autorisation, 92 fichiers de services, 89 fichiers de domaine pur sans effet de bord, 58 repositories, et aucun repository n’importe un service.
Sous cette pile, un socle d’intégration : outbox transactionnel avec bail et lettre morte, inbox de consommation, registre d’idempotence capable de rejouer la réponse d’origine, projections en lecture du catalogue publié par Bizleen. Et des dizaines de fichiers de test rejouent les migrations SQL jusqu’à vérifier la présence des déclencheurs dans sqlite_master.
Trois Durable Objects, chacun pour une seule raison
Un coordinateur de réservation par établissement, qui sérialise les demandes sur une date ; un debounce des notifications de pourboires, qui regroupe les rafales avant l’envoi push ; et une garde qui refuse toute commande adressée à la mauvaise instance. Le fan-out des notifications est borné par établissement et par fenêtre de temps, pour qu’une rafale de saisies ne devienne jamais une rafale de push.
Un client React sans gestionnaire d’état ni bibliothèque de composants
48 écrans chargés à la demande le long des frontières de rôle, aucun gestionnaire d’état, aucune bibliothèque de composants, et un seul appel à fetch dans tout le client : toutes les requêtes passent par la même porte. Le SPA est servi en Static Assets à côté de l’API, dans le même Worker.
Le challenge non-trivial
Le moteur de rendez-vous : fiabilisation et convergence
C’est le plus gros bloc du parc, comptant des dizaines de tables dédiées, des contraintes CHECK nommées et des déclencheurs SQL stricts. Il empile trois moteurs (règles, allocation avec solveur déterministe borné, et orchestration sous Durable Object).
La semaine du 13 au 20 septembre a permis de clore les défauts historiques majeurs : les créneaux passés sont interdits par un plancher temporel strict, les salariés en congé sont retirés automatiquement de la vente en ligne, la fin de prestation s’exécute en un seul clic, et les demandes d’avis Google ne sont déclenchées que pour les prestations réellement terminées de moins de 3 jours.
Leçon retenue
Un outil construit pour un seul restaurant peut devenir l’espace connecté de onze métiers, à deux conditions que j’ai apprises ici. D’abord, les moteurs ne doivent jamais connaître le nom du métier : chaque verticale est une combinaison d’axes de comportement, et un métier de plus est de la configuration.
Ensuite, une architecture en couches ne vaut que si elle se vérifie : des routes qui ne font que valider et autoriser, un domaine sans effet de bord, des repositories qui n’importent jamais un service, et des tests qui rejouent les migrations jusqu’aux déclencheurs.
C’est ce qui permet de maintenir un ratio de test proche de un pour un avec le code de production (300 310 contre 301 870).
Fiche technique
Où ça tourne Cloudflare Workers (Worker unique) · Cloudflare D1 (SQLite) · R2 · 3 Durable Objects · Hono 4
| Runtime | Cloudflare Workers (Worker unique) · Static Assets · 3 Durable Objects |
|---|---|
| Backend | Hono 4 · TypeScript strict · Zod · 573 points d’entrée (46 routes) |
| Données | Cloudflare D1 (SQLite) · Drizzle ORM · 87 tables · 113 migrations · R2 |
| Frontend | React 19 · 48 écrans chargés à la demande · Tailwind CSS 4 · Vite 8 |
| Environnements | Production · Démonstration isolée (base, bucket, sous-domaine et secrets propres) |
| Tests | 300 310 lignes de test · 13 990 cas · 301 870 lignes de production (ratio 0,99) |
