Passer au contenu
megapromotingDiscutons
Produits Menu QR

Outils pour l'hospitalité Développement & démonstrations

Le menu, la table et l’équipe, dans le même flux.

Nous construisons une plateforme pour des menus numériques et des opérations accessibles par QR. Le client accède à l’information depuis son téléphone, et l’équipe gère le menu et les demandes.

  1. 1Cod la masă
  2. 2Meniu în browser
  3. 3Solicitare către echipă
Schemă explicativă ·Menu QR

Menu QR

De l’information au travail accompli.

01

Scanezi

Le code à la table ouvre le menu dans le navigateur.

02

Alegi

Vous explorez les catégories, les options et les informations disponibles.

03

L’équipe continue

Les demandes et les statuts sont organisés selon la configuration du lieu.

Là où il devient utile.

Menu numérique

Gestion des produits, des images et des variantes.

Interactions à la table

Scénarios pour demander le personnel, l’addition ou la commande.

Operațiuni

Rôles et connexions adaptés au mode de travail du lieu.

Les commandes, les paiements et la liaison avec le système de gestion sont confirmés pour chaque mise en œuvre.

Menu QR en détail

Ce que vous pouvez faire avec ce projet.

Meniu QR est la plateforme par laquelle un client scanne le code sur la table, ouvre le menu sur son téléphone sans rien installer, commande, appelle le serveur ou demande l’addition. Le code n’est pas seulement un lien : il peut être lié à une table, à une zone, à un lieu ou à un service, et ce contexte se transmet avec chaque demande, donc le personnel sait d’où elle vient.

En arrière-plan, la structure suit la configuration réelle d’un établissement : restaurant, lieux, zones (intérieur, terrasse, bar, VIP, extérieur), tables, puis au-dessus personnel avec un rôle — serveur, barman, hookah, cuisinier, administrateur ou rôle propre — et répartition par tables. La commande a sept états avec un horodatage pour chaque transition : nouvelle, confirmée, en préparation, prête, livrée, payée, annulée. L’appel du serveur a son propre cycle : en attente, prise en charge, résolue.

Le personnel n’a pas besoin d’une nouvelle application : les notifications passent par Telegram, avec des règles configurées par événement — nouvelle commande, commande non confirmée, appel à la table, feedback négatif, paiement réussi ou échoué. Si personne ne prend en charge dans l’intervalle défini (cinq minutes par défaut), la notification est escaladée vers l’administrateur.

01

Code QR avec contexte, pas seulement un lien

Quatre types de code : table, zone, lieu et service. Les codes sont générés dans la plateforme, peuvent être exportés en PDF pour impression, et le lien construit emporte avec lui l’établissement et la table.

02

Menu avec traductions séparées du contenu

Les catégories et les produits ont leurs propres tableaux de traduction, donc le texte dans une autre langue n’écrase pas l’original. La traduction automatique passe d’abord par Anthropic (`claude-sonnet-4`), et si cette clé manque, par Google (`gemini-2.0-flash`). L’interface est en roumain, russe et anglais.

03

Commande avec états et horodatage

Sept états, chacun avec son moment enregistré : confirmation, préparation, livraison, paiement. Les produits de la commande ont leur propre état et leurs propres options choisies, ce qui permet qu’une partie de la commande parte au bar et une autre en cuisine.

04

Notifications sur Telegram, avec escalade

Bot construit sur grammy, en mode webhook. Les règles se configurent par restaurant et par événement, et si personne ne confirme dans l’intervalle configuré — cinq minutes par défaut — la demande remonte à l’administrateur. Chaque notification envoyée reste dans le journal.

05

Paiements avec les comptes de l’établissement, pas par nous

La plateforme n’intermédie pas l’argent : le restaurant utilise ses propres identifiants. Les connecteurs pour Stripe, espèces et virement sont implémentés. MAIB existe comme squelette, marqué dans le code comme non terminé.

06

Fonctions activées par abonnement, pas toutes d’un coup

Chaque restaurant a un ensemble d’interrupteurs — commande, appel du personnel, paiements en ligne, feedback, plusieurs langues, intégration avec la caisse, addition partagée, réservation de table, promotions. Par défaut, seuls l’appel du personnel et le paiement en espèces sont activés ; le reste s’active selon le plan. La limite de tables est vérifiée à l’ajout, pas à la fin du mois.

Données et fonctionnement

Ce qui entre dans le système. Ce qu'il faut vérifier.

Un seul endroit pour tous les établissements, séparés entre eux
PostgreSQL via Prisma, avec l’identifiant du restaurant sur toutes les tables et des politiques d’accès au niveau des lignes. L’authentification des administrateurs se fait via Supabase, le personnel se connecte via Telegram, et le client à la table n’a pas de compte du tout.
Le client reste anonyme
Le visiteur reçoit un identifiant de session dans un cookie httpOnly, valable 24 heures, marqué `secure` en production. Il ne demande pas de compte, ne demande pas de téléphone, n’installe rien. La commande et l’appel du serveur sont liés à cette session et à la table.
Le menu reste celui de l’établissement
Les catégories, produits, groupes d’options et options sont édités par le restaurant. Les traductions sont stockées dans des tables séparées, donc une mauvaise traduction automatique se corrige sans toucher à l’original.
Ce qui n’est pas connecté automatiquement
Les types de paiement reconnus dans le code sont huit, mais des adaptateurs écrits existent pour quatre, et celui pour MAIB est inachevé. Pour les autres — Moldindconbank, Paynet, Netopia, MobilPay — il n’y a que les noms dans la liste, sans intégration. C’est une distinction à faire avant de promettre quoi que ce soit à un établissement.

De l'exploration à l'implémentation

Comment préparons-nous un projet avec Meniu QR.

01

Nous cartographions l’établissement avant le menu

Locaux, zones, tables, personnel et leurs rôles. Les codes QR sont générés sur cette structure ; si la structure est incorrecte, le contexte de chaque demande l’est aussi.

02

Nous choisissons ce qui démarre dès le départ

Les commandes, le paiement en ligne et l’intégration avec la caisse sont des interrupteurs séparés. Pour un premier établissement, l’appel du serveur et le menu numérique suffisent pour tester le flux avec le personnel réel.

03

Nous terminons la partie paiement et caisse, pour l’établissement concerné

L’adaptateur MAIB et la correspondance des tables avec le système de caisse sont du travail à réaliser, pas de la configuration. L’estimation se fait sur le fournisseur concret de l’établissement, avec ses identifiants et sa documentation.

04

Nous testons avec le personnel, en service réel

Le flux se casse chez les gens, pas dans le code : qui confirme, en combien de temps, que se passe-t-il lorsque personne ne répond. L’escalade à cinq minutes est un point de départ qui se calibre dans l’établissement.

Des questions qui méritent d’être clarifiées.

Un établissement peut-il l’utiliser demain ?

Non. C’est un prototype complet en couverture, mais inachevé et non lancé : une seule migration de base de données, du 4 avril 2026, aucun commit après cette date, aucun test automatisé et aucune installation publique. Ce qui peut être fait demain : une démonstration sur la structure d’un établissement réel, pour voir le flux de bout en bout et estimer ce qu’il manque encore.

Le client doit-il installer une application ?

Non. Il scanne le code et cela s’ouvre dans le navigateur. Il reçoit un identifiant de session dans un cookie httpOnly valable 24 heures — sans compte, sans téléphone, sans données personnelles. La commande et l’appel du serveur sont liés à cette session et à la table du code.

Peut-on payer en ligne ?

Cela dépend du fournisseur, et il faut le dire précisément. L’adaptateur Stripe est fonctionnel, tout comme l’argent liquide et le virement. L’adaptateur MAIB est écrit comme un squelette et marqué dans le code comme non terminé — il a besoin du SDK de la banque et de certificats TLS. Pour Moldindconbank, Paynet, Netopia et MobilPay, il n’y a que les noms dans la liste des types, sans intégration. Point important : la plateforme ne garde pas l’argent ; l’établissement utilise ses propres identifiants.

Se relie-t-il à la caisse enregistreuse du restaurant ?

Partiellement, et la partie qui manque est celle qui compte. Des adaptateurs sont écrits pour iiko (Syrve) et pour Poster, avec authentification et échange de jetons implémentés, donc le menu peut être récupéré depuis leur système. L’envoi de la commande en retour n’est pas prêt : l’appariement de la table de l’établissement avec la table et le groupe de terminaux de leur système reste à résoudre. Donc import oui, synchronisation complète pas encore.

Comment le personnel sait-il que quelqu’un a commandé ou a appelé le serveur ?

Sur Telegram, avec un bot propre en mode webhook — sans nouvelle application à installer sur leurs téléphones. Les règles se définissent par restaurant et par événement : nouvelle commande, commande non confirmée, appel à la table ou à l’administrateur, retour négatif, personnel en pause, paiement réussi ou échoué. Si personne ne prend en charge dans le délai défini, par défaut cinq minutes, la demande est escaladée à l’administrateur, et chaque notification envoyée reste dans le journal.

Dans quelles langues le menu fonctionne-t-il ?

L’interface est en roumain, russe et anglais. Le menu possède des tableaux de traduction séparés pour les catégories et les produits, donc la traduction n’écrase pas le texte original et peut être corrigée manuellement. La traduction automatique essaie d’abord Anthropic (`claude-sonnet-4`) et, si cette clé manque, Google (`gemini-2.0-flash`).

Est-ce la même chose que MEGA QR ?

Non. MEGA QR génère des codes et transfère les données par voie optique. Meniu QR est une plateforme d’hospitalité : menu, commande, appel du personnel, notifications de service et paiements. Le seul point commun est le code sur la table.

Exemple illustratif

Un appel depuis la table qui ne se perd pas

Un scénario d’utilisation, sans données client ni résultats commerciaux attribués.

Situation initiale

Un client scanne le code sur la table 12 dans la zone de terrasse et appuie sur « appeler le serveur ».

Comment ça fonctionne

La demande est liée à la session anonyme du client et à la table du code, avec l’état « en attente ». La règle de notification du restaurant envoie le message sur Telegram au personnel affecté à la zone respective.

Rezultatul

Le serveur confirme depuis Telegram et la demande passe à « prise en charge », puis à « résolue ». Si personne ne confirme dans l’intervalle configuré, par défaut cinq minutes, la demande remonte à l’administrateur. Chaque notification reste dans le journal, donc on peut voir plus tard ce qui a tardé.

Ce este necesar:Structura localului introdusă (locație, zone, mese), personal înregistrat în bot cu rolurile lui, reguli de notificare setate pe evenimente și codurile QR tipărite pe mese. Comenzile și plata online sunt comutatoare separate, care pot rămâne închise la primul local.

Possibilités de collaboration

Meniu QR, dans le contexte de votre organisation.

Points d’accès et transfert local

Codes pour l’accès à des informations publiques, à des instructions ou à des contacts ; transfert optique de fichiers entre appareils compatibles, avec évaluation des politiques de sécurité de l’institution.

Entreprises privées

Nous définissons un pilote autour d’un processus réel : utilisateurs, données, intégrations, coûts et critères d’acceptation. L’extension suit après l’évaluation du résultat.

Institutions et entreprises publiques

Nous établissons les exigences d’accessibilité, d’hébergement, de protection des données et d’interopérabilité. Toute connexion avec des services AGE ou STISC nécessite la validation de l’éligibilité, de l’accès et des approbations.

Ce sont des scénarios d’adaptation, non des déclarations sur des contrats ou partenariats existants. Les fonctions proposées sont confirmées dans le périmètre de travail du projet.

Discuter d'un pilote

Faisant partie d’un écosystème.

Qu'est-ce que vous voudriez voir mieux fonctionner ?

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.

Discutons