Scanezi
Le code à la table ouvre le menu dans le navigateur.
Outils pour l'hospitalité Développement & démonstrations
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.
Menu QR
Le code à la table ouvre le menu dans le navigateur.
Vous explorez les catégories, les options et les informations disponibles.
Les demandes et les statuts sont organisés selon la configuration du lieu.
Gestion des produits, des images et des variantes.
Scénarios pour demander le personnel, l’addition ou la commande.
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
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.
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.
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.
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.
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.
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é.
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
De l'exploration à l'implémentation
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.
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.
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.
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.
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.
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.
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.
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.
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.
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`).
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 scénario d’utilisation, sans données client ni résultats commerciaux attribués.
Un client scanne le code sur la table 12 dans la zone de terrasse et appuie sur « appeler le serveur ».
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.
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
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.
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.
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 piloteNous construisons des agents qui prennent et passent des appels, utilisent les informations de l'entreprise et travaillent avec vos systèmes.
PlatformăUn assistant connecté aux informations de votre entreprise, dans les canaux où vos clients vous écrivent.
PlatformăMEGA QR comprend un générateur de codes et un outil de transfert optique.
Instrument publicRacontez-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.