Solutions · Restaurants et HoReCa
Le menu d’un établissement n’est pas une brochure : il a des prix et des volumes qui doivent être exacts, il change souvent et il est lu par des personnes qui parlent trois langues. Nous construisons le menu comme des données, nous générons la page à partir d’elles et nous vérifions avant chaque publication, y compris que les prix descendent dans chaque catégorie et que chaque photo existe.
Déjà construitDouă meniuri digitale în producție, verificabile din exterior azi. Primul: 119 produse în 21 de categorii, cu preț, volum, compoziție și fotografie, plus câte un text scurt de prezentare și un set de recomandări de asociere pentru fiecare produs; generatorul are 402 linii, iar verificarea dinaintea publicării are 233 de linii și 16 blocuri. Al doilea, site-ul-soră cu același motor: 146 de produse în 31 de categorii, generator de 377 de linii, verificare de 210 linii cu 14 blocuri, iar integrarea continuă regenerează pagina din surse și respinge modificarea dacă rezultatul diferă de fișierul din depozit. Ambele răspund 200 și niciunul nu pune vreun cookie — verificat de mine pe 06.09.2026. Spunem și că sunt două lucrări cu același motor și același proprietar, nu două lucrări independente.
Un PDF scanné sur un code QR ne résout rien de ce qu’un établissement a à résoudre. On ne peut pas le parcourir, on ne le traduit pas, il ne s’agrandit pas correctement sur téléphone et on ne peut pas le modifier sans réimprimer le code. Et le menu change souvent : la cuisine retire un plat, le bar reçoit une autre marque, le prix d’un article augmente. Le menu est un ensemble de données qui se modifie chaque semaine, pas un document imprimé une fois.
C’est pourquoi nous le traitons comme des données. Les vraies sources sont quelques fichiers structurés — produits, textes de présentation, recommandations d’association, traductions — et un générateur écrit en Python compose à partir d’eux une seule page. Dans l’un des établissements : 119 produits dans 21 catégories, chacun avec prix, volume, composition et photographie, plus 119 textes brefs et 119 ensembles de « avec quoi cela va ». Dans l’autre : 146 produits dans 31 catégories. La page ne s’édite pas directement — elle est régénérée.
La traduction ne s’arrête pas aux boutons. Le roumain est la base, et le russe ainsi que l’anglais couvrent les catégories, les intitulés, les volumes, les compositions, les 82 étiquettes de goût et tous les textes de présentation. Dans une ville où la table voisine commande dans une autre langue, un menu traduit à moitié est plus agaçant qu’un menu non traduit : il vous laisse croire que vous pouvez tout lire.
La partie que nous considérons comme la plus importante et que personne ne demande dans le brief : le panier, la liste des favoris et le partage de l’addition fonctionnent dans le navigateur, sans compte et sans serveur, et le site ne pose aucun cookie et ne demande rien à un domaine tiers. Ce n’est pas une promesse de la politique de confidentialité — c’est une règle imposée par des vérifications automatiques qui s’exécutent avant chaque publication et qui rejettent la modification si un traceur, une ressource externe ou une police prise ailleurs apparaît.
Ce que cela comprend
Les produits, les textes de présentation, les recommandations et les traductions sont stockés dans des fichiers structurés ; un générateur écrit en Python — 402 lignes dans l’un, 377 dans l’autre — en compose une seule page. La page publiée ne s’édite pas à la main ; quand quelqu’un le fait, l’intégration continue le détecte, car elle régénère la page et compare le résultat.
Dans un bar, le volume fait partie du prix : la même dénomination en 40 et en 100 millilitres représente deux produits différents, et le client qui ne voit pas le volume pense qu’on lui a dit autre chose. La structure de données garde ces quatre champs comme obligatoires, et non comme optionnels, justement pour qu’une position incomplète n’aille pas sur la table.
La traduction couvre l’interface, les catégories, les dénominations, les volumes, les compositions, les 82 étiquettes de goût et tous les courts textes de présentation, chaque clé roumaine ayant son pair en russe et en anglais. L’un des contrôles avant publication échoue si le menu n’est pas complet dans les trois langues.
Sans compte, sans serveur, sans données envoyées nulle part. Le client compose sa commande sur son téléphone et la montre au serveur ou l’utilise pour partager l’addition. Conséquence technique : il n’existe pas de base avec ce qu’ont commandé vos clients, parce qu’aucune n’est créée.
Vérifié de l’extérieur : aucun en-tête de cookie sur aucun des deux sites, et la politique de contenu de l’un d’eux n’autorise absolument rien de l’extérieur. Les polices sont hébergées sur le même domaine, pas chez un service externe. Les seules adresses externes de la page sont les liens vers les réseaux sociaux de l’établissement — que le visiteur clique, et que la page n’appelle pas.
Seize blocs de contrôle dans un établissement, quatorze dans l’autre : pas de traceurs, pas de ressources chargées automatiquement depuis des tiers, polices auto-hébergées, fichiers structurés valides, chaque photo existe, menu complet en trois langues, données structurées de la page valides et — celle qui surprend tout le monde — les prix descendent dans chaque catégorie. Un prix saisi incorrectement se voit comme une discontinuité dans l’ordre de la liste, et non lors de la réclamation du client.
À chaque modification, l’intégration continue régénère la page à partir des sources et rejette la modification si le résultat diffère du fichier du dépôt. C’est la seule garantie réelle que ce qui apparaît sur l’écran du client provient des données que l’établissement édite localement, et non d’une intervention manuelle oubliée là il y a trois mois.
Dans la configuration serveur de l’un des établissements : masquage des adresses IP, en-têtes d’identification supprimés du journal et conservation limitée, avec référence explicite au principe de limitation de la conservation. L’intégration continue refuse la modification si ces lignes disparaissent de la configuration — donc la protection ne peut pas être perdue silencieusement lors d’un changement de serveur.
Il ne prend pas la commande en cuisine et ne confirme pas une réservation : pour cela, il faut une connexion au système d’exploitation de l’établissement, ce qui est un travail séparé. Et nous ne publions pas de fonctions qui promettent quelque chose qui doit être honoré à la caisse — une réduction de type « happy hour » ou un horaire de cuisine ne se lancent pas sans l’accord écrit de l’établissement, parce que celui qui paie pour la promesse affichée à l’écran, c’est la personne au comptoir.
Traseul
La première livraison, c’est le menu en tant que données : catégories, articles, prix, volume, composition, photographie. C’est là aussi que les manques apparaissent — articles sans volume, catégories qui sont en réalité deux, produits sans photographie. Un menu numérique construit sur des données incomplètes paraît incomplet, quelle que soit la qualité du design.
Les catégories, les désignations, les volumes, les compositions, les étiquettes de goût et les textes de présentation reçoivent leurs équivalents en russe et en anglais. Nous livrons le menu complet en trois langues et la vérification automatique qui échoue si une clé reste non traduite.
Sans traceurs, sans ressources tierces, polices auto-hébergées, fichiers valides, chaque photographie présente, prix en ordre décroissant par catégorie, données structurées valides. Nous livrons le script de vérification dans le dépôt, afin que l’établissement puisse aussi l’exécuter sans nous.
La publication se fait lors de la fusion de la modification, après que l’intégration continue a régénéré la page et l’a comparée aux sources, et après qu’une copie de la version précédente a été conservée. Nous livrons les accès et la procédure de retour en arrière — pas seulement le site en service.
Les données
Les règles diffèrent d’un secteur à l’autre. Voici celles qui s’appliquent aux restaurants & horeca.
Un cas
La situation
Dans un menu de plus d’une centaine d’éléments, l’erreur la plus fréquente n’est pas de conception, mais de saisie : un chiffre en trop dans un prix ou un élément sans photo. Les deux sont généralement découverts quand le client les montre au serveur.
Ce que nous avons construit
Nous avons mis en place avant la publication un script de vérification — 233 lignes dans un établissement, 210 dans l’autre — qui exécute seize, respectivement quatorze blocs : qu’aucun traqueur ne s’est glissé, que la page ne demande rien à un domaine tiers, que les polices sont hébergées localement, que les fichiers de données sont valides et que chaque photo existe, que le menu est complet dans les trois langues, que les données structurées de la page sont valides et que les prix diminuent dans chaque catégorie. À part, l’intégration continue régénère la page à partir des sources à chaque modification et la rejette si le résultat diffère du fichier publié.
Ce qui en est sorti
Une erreur de saisie dans le prix casse l’ordre décroissant et arrête la publication, et une photo manquante n’arrive jamais à l’écran de la table. La page publiée correspond toujours aux données que l’établissement modifie localement, sinon elle n’est pas publiée.
Ce que le cas ne dit pas
Les vérifications attrapent ce qui peut être vérifié mécaniquement. Un prix saisi de travers, mais plausible — et dans l’ordre — passe ; pour lui, il n’existe pas d’autre mécanisme que quelqu’un qui regarde. La documentation de l’un des projets indique « 14 vérifications » là où le script comporte 16 blocs ; le chiffre correct est celui du script.
Questions
Oui. On modifie les données, pas la page ; la page est régénérée à partir d’elles. L’intégration continue vérifie la régénération à chaque modification et rejette la modification si la page publiée ne correspond plus aux sources. Ainsi, il n’existe pas de scénario où quelqu’un a corrigé un prix directement dans la page et où la modification a disparu à la publication suivante.
Parce qu’un menu qui ne collecte rien n’a pas besoin de bandeau de consentement, n’a rien à divulguer et n’a rien à expliquer à un contrôleur. La vérification est à la portée de tout le monde : une seule requête vers le site montre qu’aucun en-tête de cookie ne revient. Et la politique de contenu de l’un des établissements n’autorise absolument aucune ressource externe.
Le panier fonctionne dans le navigateur, comme une liste que le client montre au serveur ou utilise pour partager l’addition. L’envoi de la commande en cuisine nécessite une connexion au système de l’établissement et constitue un travail séparé, avec vérification de compatibilité au préalable. Nous n’appelons pas « commande en ligne » un panier qui n’arrive nulle part.
C’est possible à construire, mais nous ne le lançons pas sans l’accord écrit de l’établissement, car c’est une promesse honorée à la caisse. Notre règle : les fonctions qui engagent l’établissement vis-à-vis du client — réductions, horaires de cuisine, disponibilités — ne sont pas publiées sur la base d’une discussion verbale.
Trois : roumain comme base, russe et anglais. Complet signifie catégories, dénominations, volumes, compositions, étiquettes de goût et textes de présentation, pas seulement les boutons. Une vérification automatique échoue si le menu n’est pas complet dans les trois — c’est pourquoi il n’arrive pas sur le site à moitié traduit.
Parmi les vérifications avant publication, il y en a une qui exige que les prix diminuent dans chaque catégorie. Ce n’est pas une règle commerciale, c’est un détecteur d’erreurs de saisie : un élément saisi avec un chiffre en plus ou en moins casse l’ordre et arrête la publication. Les autres vérifications s’occupent des photos manquantes et des fichiers invalides.
Le résultat est une page unique générée, avec les polices hébergées sur le même domaine et sans ressources demandées à des domaines tiers. Cela signifie moins de connexions à ouvrir et rien qui attende un service externe. Nous ne publions pas de chiffres de vitesse mesurés dans des conditions autres que les vôtres.
Oui, et dans ce cas la politique de contenu de la page autorise exactement ce domaine, rien d’autre. Sur l’un des deux locaux, cela se voit de l’extérieur. Il faut aussi mentionner l’envers : à ce moment-là, la page n’est plus « sans rien d’extérieur », donc la décision se prend en connaissance de cause, et non comme un bonus.
Ce sont deux sites avec le même moteur, du même propriétaire, et nous le disons explicitement. La différence fonctionnelle déclarée entre eux est constituée par les recommandations d’association par produit, que le second n’a pas. Nous pourrions les présenter comme des travaux indépendants ; ce serait une exagération de portfolio.
Racontez-nous votre processus. Ensemble, nous décidons ce qui vaut la peine d'être construit, ce que nous pouvons connecter et comment nous vérifions le résultat.