Un restaurant qui tourne sur son propre logiciel

Alsafi est un restaurant familial irako-levantin de la Hertzstraße, à Heidelberg. Auparavant, commander passait par une plateforme d'agrégation : une commission sur chaque plat, une relation client détenue par quelqu'un d'autre, et une cuisine qui lisait des tickets sortis d'un système que personne sur place n'avait choisi.

Ils tournent désormais sur le leur.

Ce que « l'ensemble » veut vraiment dire

Une seule base de code porte quatre métiers différents, et chacun a une personne différente en face.

• Le client qui hésite à venir. Carte, formule du midi, histoire de la maison, horaires et avis, pensés pour le téléphone d'abord, parce que c'est ainsi qu'on vérifie si un restaurant vaut le déplacement.
• Le client qui commande. Un parcours avec options et suggestions, un paiement Stripe, le pourboire, et un suivi de commande en direct avec une estimation réelle. C'est le chemin de l'argent, et il est conçu pour lever l'inquiétude plutôt que pour gonfler le panier.
• Le client qui a un compte. Peu fréquent, très exigeant : entrer, obtenir ce qu'on veut, ressortir.
• Ceux qui font le service. Soixante-six écrans pour le personnel, un écran de cuisine lisible à distance et sous pression, et les impressions dont la salle se sert réellement.

Cela s'installe depuis le navigateur sur un téléphone, une tablette, un Mac, un PC Windows ou un poste Linux. Une base de code, pas de magasin d'applications, pas de versions séparées à tenir alignées.

La carte est une base de données, pas un PDF

Cent trois plats répartis en quinze catégories, chacun avec ses variantes et ses prix, et ses groupes d'options pour les choix que le client fait réellement — la taille, l'accompagnement, la cuisson. La cuisine édite tout cela. Personne ne redessine un document.

Sous chaque plat se trouve la partie qui intéresse le droit allemand. Quatorze allergènes réglementés par l'UE et seize déclarations d'additifs sont enregistrés par plat et non par carte, contrôlés sur la même matrice que celle dont la cuisine se sert, au lieu d'un PDF que personne ne pense à mettre à jour. Un client peut écarter un allergène, ou réduire toute la carte à végane, végétarienne ou halal, avant de s'engager sur une commande plutôt qu'après.

Le midi tourne sur sa propre rotation, avec ses plats et sa semaine. Un plat épuisé quitte la carte d'un geste et revient dès qu'il est de nouveau là — le client le voit, la caisse le voit, et personne n'a besoin de penser à prévenir l'autre.

Commander, payer, et savoir où en est la commande

La livraison est tracée en zones plutôt qu'en rayon, parce qu'une rue est, ou n'est pas, un endroit où le plat arrive chaud. L'emporter est une première option, pas un repli. Un client qui revient garde ses adresses ; un client de passage n'est pas obligé d'ouvrir un compte pour manger, et peut rattacher sa commande à un compte ensuite s'il tient à l'historique.

Le paiement passe par Stripe, le pourboire traité comme sa propre ligne plutôt que fondu dans le total. Une fois la commande passée, le client obtient un statut en direct avec une estimation réelle et — s'il l'autorise — une notification quand la cuisine le fait évoluer, pour que personne ne reste à rafraîchir une page en se demandant si le dîner arrive.

Les remboursements sont la partie qui doit être juste du premier coup. Une ligne de remboursement est écrite avant l'appel à Stripe et son propre identifiant sert de clé d'idempotence : ni une nouvelle tentative, ni un double clic, ni une connexion perdue ne peuvent rembourser deux fois la même commande. Le total remboursé de la commande est dérivé de ces lignes plutôt que saisi quelque part.

La salle, telle qu'elle est vraiment

Le plan de salle est dans le système : deux établissements, vingt et un espaces, trois cent cinquante-trois tables. Les réservations se posent sur de vraies tables plutôt que sur une capacité abstraite, ce qui fait toute la différence entre un système de réservation et un tableur avec un plus joli formulaire.

La salle, et les gens qui y travaillent

Les terminaux sont appairés au système au lieu d'être crus sur parole parce qu'ils sont sur le réseau — la caisse, les téléphones des serveurs, l'écran de cuisine détiennent chacun un jeton d'appareil, et les codes d'appairage comme les jetons sont stockés sous forme d'empreintes qu'aucun client ne peut relire. Le personnel se connecte avec un code PIN, haché en bcrypt, avec verrouillage après plusieurs échecs, parce qu'une caisse en plein service est le clavier le moins privé du bâtiment.

Les rôles sont réels. Le compte d'un exploitant et un compte de salle ne sont pas la même porte, et l'écran de cuisine affiche des tickets dimensionnés pour être lus au-dessus d'un piano brûlant, pas un tableau de bord réduit pour tenir.

Les heures travaillées, tenues comme la loi le demande

Le planning sépare le brouillon d'un responsable de ce que l'équipe a réellement reçu : un service est publié ou il ne l'est pas. En regard se tient le relevé du temps de travail exigé par l'Arbeitszeitgesetz : début, fin, durée et pause, conservés deux ans.

Les corrections sont la partie intéressante. Modifier un horaire ne l'écrase pas — l'original reste à côté du nouveau, avec un auteur et un motif. Un relevé qui peut être réécrit en silence n'est pas un relevé, et un contrôleur le sait.

La partie que la plupart des agences sautent discrètement

L'Allemagne n'autorise pas un restaurant à simplement encaisser. Chaque transaction doit être signée par un dispositif technique de sécurité certifié, et l'administration fiscale peut réclamer un export DSFinV-K couvrant dix ans d'activité.

C'est intégré. La plateforme dialogue avec un fournisseur de TSE certifié par le BSI, compose le schéma fiscal à partir de la spécification en vigueur plutôt que de mémoire, et exporte l'ensemble DSFinV-K complet à la demande — avec une piste d'audit indiquant qui a exporté quelle période, quand, et l'empreinte exacte de ce qui lui a été remis.

Le reste du tableau fiscal est là parce qu'un contrôleur le demandera. Chaque journée se clôt en un Kassenabschluss, le numéro Z auquel appartient chaque transaction du système. Les mouvements d'espèces qui ne sont pas des ventes — le fonds de caisse, les apports, les prélèvements, les transferts, les écarts constatés, les pourboires, les consignes, les bons — sont enregistrés comme leur propre type d'événement au lieu d'être glissés dans le chiffre d'affaires. Et quand la TSE elle-même tombe, la panne est journalisée avec son heure et sa cause et signalée sur tout ticket émis pendant celle-ci, ce qui est exactement ce qu'exige l'AEAO et exactement ce que personne ne pense à construire.

Une vente signée ne peut pas être supprimée pendant dix ans : le code qui en produit une est donc écrit pour être lu par un contrôleur, pas seulement pour passer un test.

Nous faisons le même travail en Égypte, pour la facturation électronique de l'administration fiscale égyptienne, et en Arabie saoudite pour la ZATCA. Les pays diffèrent ; la discipline, non.

Parlons d'un projet où la conformité est critique

Rien n'arrive à une commande sans un nom dessus

Chaque commande porte un journal d'événements en ajout seul, et ces événements ne sont pas écrits par celui qui se trouve tenir la connexion. Chacun consigne qui a agi, en quelle qualité, depuis quelle surface, et pourquoi — un changement de statut depuis l'écran de cuisine, une modification depuis le bureau, un remboursement assorti d'un motif.

La table des commandes est elle-même en lecture seule pour l'interface d'administration. Toute écriture passe par une fonction serveur, parce que ce sont les seuls appelants capables d'établir qui agit. Une écriture directe dans la table serait enregistrée comme faite par le système, et « c'est le système qui l'a fait » n'est pas une réponse que l'on souhaite donner à un contrôleur.

Le marketing du restaurant, entre les mains du restaurant

Le contenu du site — bandeau d'accueil, blocs d'histoire, galerie, événements — s'édite dans la même administration que le reste, puis se publie comme une tâche plutôt qu'en direct, pour qu'une phrase à moitié écrite ne soit jamais à un rafraîchissement d'un client.

Autour se trouve tout ce qu'un restaurant loue d'ordinaire ailleurs : un blog, des offres d'emploi avec candidatures, les retours des clients, des tickets de support, et des liens courts traçables pour l'imprimé et les QR codes, afin de distinguer un flyer d'un chevalet de table. Les avis Google se synchronisent dans l'administration où vivent les exports fiscaux. Une infolettre hebdomadaire est assemblée à partir des vraies formules du midi de la semaine plutôt qu'écrite depuis rien, avec double opt-in, désinscription en un clic et journal des envois.

Les clients qui veulent une personne en obtiennent une : un chat en direct avec indicateur de saisie et messages vocaux, tenu comme une conversation et non comme un ticket.

Des statistiques qui ne vendent pas les clients

Le restaurant peut voir à quoi ressemblait la journée — chiffre d'affaires, commandes, panier moyen, quel plat retient le plus l'attention, quelles heures sont chargées dans son propre fuseau, d'où viennent les visites, et où une visite devient quelque chose.

Rien de tout cela n'est acheté à un tiers, et rien ne suit personne. Les visiteurs uniques sont comptés avec des empreintes salées à courte durée de vie, purgées au bout de deux jours ; les pays viennent du réseau de diffusion et non d'un traceur. Aucune police, aucune icône, aucun script n'est chargé depuis le serveur d'un tiers. C'est une décision de RGPD et de sécurité du contenu avant d'être une décision de performance, et elle fait qu'un client en train de lire une carte n'est pas discrètement présenté à une régie publicitaire.

Le tableau de bord trace aussi sa propre limite avec soin : il compte les commandes pour la planification et le dit franchement, parce que le chiffre juridiquement contraignant vit dans le rapport Z, pas ici.

Trilingue, et l'arabe correctement

L'allemand fait foi. L'anglais et l'arabe sont livrés pour chaque texte sans exception, et l'arabe est en droite-à-gauche intégral : mise en page en miroir, propriétés logiques, sa propre pile typographique. Pas une traduction vissée à la fin, ce qui fait la différence entre un site qu'un arabophone peut utiliser et un site qu'il peut seulement lire.

Rien n'est considéré comme terminé tant que cela ne tient pas en clair et en sombre, en gauche-à-droite et en droite-à-gauche, et d'un téléphone de 375 pixels jusqu'à un poste de bureau.

Construit pour être vérifié

Quatre cent soixante-six fichiers de test. Accessibilité vérifiée par contrôles automatisés plutôt qu'à l'œil. WCAG AA comme contrainte et non comme ambition, avec des cibles tactiles de 44 pixels et le respect du mouvement réduit partout.

Ce que coûte le fait de ne pas posséder tout cela

Une plateforme d'agrégation peut copier une carte. Elle ne peut pas copier l'accueil d'une famille, et elle ne rendra pas la relation client. Chaque décision de ce projet a été jugée à une seule question : une place de marché aurait-elle fait comme cela ? Là où la réponse était oui, nous avons fait autrement.