Configurer un kiosque Ubuntu fiable pour les écrans de restaurant

Configurer un kiosque Ubuntu fiable pour les écrans de restaurant
kiosk mode ubuntu ubuntu kiosk chromium kiosk wayland kiosk linux kiosk

Si vous configurez un kiosque Ubuntu en ce moment, vous n’êtes probablement pas en train de monter un projet de laboratoire. Vous essayez de garder un menu, une page de commande ou un écran orienté client opérationnel pendant un service intense, sans que quelqu’un n’accède au bureau, ne déclenche des mises à jour ou ne vous laisse avec un affichage noir et un responsable qui demande pourquoi l’écran est encore mort.

Cela change la manière de construire le mode kiosque sur Ubuntu. Les démonstrations propres ne suffisent pas. Un kiosque dans un restaurant doit survivre aux manipulations brusques, aux coupures de courant, aux plantages du navigateur, aux sessions périmées et au membre du personnel qui trouve toujours le geste en coin pour quitter le plein écran. La bonne nouvelle, c’est qu’Ubuntu prend en charge l’administration de type kiosque depuis longtemps. Le wiki d’aide communautaire d’Ubuntu documente le mode KioskMode depuis le 19 août 2015, avec des mises à jour aussi récentes que le 2 mai 2026, ce qui montre clairement qu’il ne s’agit pas d’une astuce de niche récente, mais d’un modèle éprouvé dans l’administration Ubuntu (documentation Ubuntu KioskMode).

Table des matières

Pourquoi les kiosques Ubuntu cassent dans le monde réel

Le samedi soir à 21 h, personne ne se soucie que le kiosque ait passé les tests sur un établi mardi après-midi. On se soucie que l’écran du menu vienne de s’éteindre, que Chromium s’affiche avec une invite de restauration après une coupure d’alimentation brusque, ou qu’un membre du personnel ait trouvé un moyen de revenir au bureau en essayant de débloquer la page.

C’est ainsi que les kiosques Ubuntu échouent généralement. Non pas parce qu’Ubuntu ne peut pas assurer la fonction de kiosque, mais parce qu’une installation de bureau par défaut se comporte encore comme un poste de travail. Il veut se mettre en veille, il s’attend à des arrêts propres, il conserve l’état de l’utilisateur et il suppose que la personne qui touche l’écran est autorisée à accéder aux paramètres si elle clique suffisamment longtemps.

J’ai vu cela le plus souvent sur les tableaux de menus de restaurant et les écrans libre-service. L’installation semble stable pendant la configuration. Puis le service commence, l’appareil est tapoté toute la journée, le circuit derrière l’écran est mis hors tension sans avertissement, et quelqu’un finit par brancher un clavier parce que « l’écran était bloqué ». Les vieilles recettes LightDM et X11 ont permis de réaliser bon nombre de ces tâches, mais elles laissaient aussi beaucoup d’échappatoires. Les approches plus récentes basées sur Wayland comblent certaines de ces lacunes, tout en introduisant des choix opérationnels différents.

Les pannes courantes qui vous coûtent du temps de service

Règle pratique : Si un plantage normal du navigateur nécessite encore la présence d’une personne sur place, le kiosque n’est pas prêt pour la production.

Le point faible n’est généralement pas « application web contre application native ». La décision clé est de savoir quelle partie de la pile de bureau vous êtes prêt à laisser en place. Les anciennes constructions de kiosque Ubuntu utilisaient souvent LightDM, un utilisateur à connexion automatique et un script de lancement du navigateur sur X11. Cela peut encore fonctionner, surtout sur du matériel ancien ou dans des établissements où vous connaissez déjà les particularités. Cela laisse aussi plus d’éléments à contrôler. Les sessions kiosque Wayland modernes et les configurations de type appliance suppriment une partie de cette surface, mais elles peuvent être moins indulgentes si vous avez besoin de périphériques personnalisés, d’outils de signalétique hérités ou de pilotes d’écran tactile atypiques.

Un déploiement de menu de restaurant rend le compromis évident. Si la machine doit seulement démarrer, afficher TopFoodApp, récupérer après un plantage et ne jamais exposer un bureau, une session kiosque dépouillée est plus facile à vivre qu’un bureau GNOME complet déguisé. Si l’établissement a également besoin d’outils de support à distance, de tests d’impression, de connexions du personnel ou de dépannage ponctuel sur le même boîtier, l’ancien modèle basé sur le bureau est tentant. C’est souvent cette commodité qui casse en premier.

Ce qui tient vraiment la route

Les kiosques Ubuntu qui survivent aux week-ends sont les plus ennuyeux. Ils utilisent un utilisateur kiosque dédié. Ils désactivent la mise en veille de l’écran et la suspension au niveau du système d’exploitation et de la session. Ils lancent le navigateur à partir d’un chemin de démarrage contrôlé, et non à partir d’un profil shell quelconque. Ils vident ou isolent l’état du navigateur. Ils redémarrent automatiquement l’application si elle se ferme.

Les conseils plus récents de Canonical sur les kiosques s’orientent vers un déploiement natif Wayland plutôt que vers l’ancien modèle « bureau plus navigateur en plein écran », ce qui constitue un signal utile même si vous choisissez encore X11 pour des raisons de compatibilité (Ubuntu Frame et orientation kiosque moderne).

Ce qui tient la route en production, ce n’est pas la configuration la plus élégante. C’est celle qui comporte le moins de pièces mobiles tout en prenant en charge votre matériel, votre navigateur et votre plan de reprise. C’est la norme que j’utilise pour les écrans de menu des cafés et des bars, car la machine finira par être redémarrée de la mauvaise façon, touchée avec les mains mouillées et accusée d’un problème réseau qu’elle n’a pas causé.

Choisir la bonne approche de kiosque

À 16 h, un kiosque basé sur le bureau Ubuntu complet semble flexible. À 21 h, lorsque l’écran du menu est tombé sur une invite de connexion et que le personnel s’aligne pour le coup de feu du dîner, la flexibilité est généralement le problème.

Ubuntu vous offre trois modèles de kiosque encore pratiques aujourd’hui. Je les traite comme trois modèles de défaillance différents. L’ancienne recette X11 et LightDM est facile à inspecter et rapide à réparer sur place. L’approche plus récente Wayland et Frame supprime une grande partie du bagage de bureau, mais vous demande d’accepter un flux de travail plus proche d’une appliance. Un kiosque navigateur simple se situe au milieu et reste la bonne réponse pour beaucoup de tableaux de menus de restaurant.

Kiosque navigateur pour un seul établissement

Un kiosque Chromium ou Firefox convient le mieux lorsque TopFoodApp fonctionne déjà dans le navigateur et que le travail de l’écran est simple : démarrer, se connecter, afficher le menu, récupérer si le navigateur se ferme.

C’est la voie que j’utilise encore en premier pour un restaurant unique ou un bar avec un ou deux écrans. Elle correspond bien au vieux manuel d’administration Ubuntu. Utilisateur dédié, connexion automatique, démarrage de session contrôlé, navigateur en plein écran, chemins de sortie restreints. Si le site est le produit, l’envelopper dans une application native ajoute souvent du travail sans résoudre les problèmes qui vous réveillent la nuit.

Ces problèmes sont opérationnels. Les profils de navigateur s’encrassent. L’état du cache devient périmé. Une mise à jour du navigateur peut modifier le comportement de lecture automatique, des pop-ups ou de l’accélération graphique sans avertissement. Rien de tout cela ne fait des kiosques navigateurs un mauvais choix. Cela signifie que vous avez besoin d’une configuration que vous pouvez réinitialiser rapidement.

Kiosque basé sur Snap pour des installations appliance plus simples

Canonical a orienté les déploiements de kiosque Ubuntu vers des outils natifs Wayland pour une bonne raison. L’ancienne pile de bureau fonctionne, mais elle comporte beaucoup d’éléments dont vous n’avez pas besoin sur un écran de menu mural. L’ancien tutoriel de kiosque Wayland de Canonical renvoie désormais les lecteurs vers des méthodes plus récentes, ce qui est un indicateur utile de l’orientation prise par Ubuntu en matière de kiosque (tutoriel Ubuntu Wayland kiosk).

Pour un exploitant de restaurant qui souhaite moins de réglages au niveau de la session, Ubuntu Frame et un paquet d’application kiosque peuvent être plus propres que de maintenir LightDM, des fichiers de session X11, des options de navigateur et des dérogations de bureau. Les guides communautaires pour ce modèle suivent généralement le même schéma : installer Frame, installer l’application kiosque, la connecter au serveur d’affichage et laisser le système démarrer directement sur la surface de l’application (flux de configuration de type Ubuntu Frame).

Ce modèle plus propre a un compromis. Les corrections ponctuelles sont moins commodes. Si le personnel veut « juste un bureau rapide » pour tester l’imprimante ou les e-mails, cette approche s’y oppose, ce qui est généralement une bonne chose sur un écran de menu destiné au public.

Si votre application est déjà livrée dans une enveloppe mobile et que la décision matérielle est encore ouverte, comparez cela avec le plugin Capacitor Kiosk pour Android. Le matériel Android peut être plus adapté lorsque vous avez besoin d’un verrouillage plus strict de l’application unique que celui qu’offre un mini PC Ubuntu réaffecté.

Ubuntu Core et Frame pour les flottes

Pour plusieurs établissements, Ubuntu Core avec Ubuntu Frame est celui que je choisirais délibérément plutôt que de dériver vers une solution. Il se comporte davantage comme une appliance que comme un bureau maintenu. Cela compte lorsque vous avez des écrans dans plusieurs restaurants et que personne sur place ne devrait modifier les fichiers de démarrage après la fermeture.

Le coût, c’est la flexibilité. Vous perdez une partie de la vieille habitude Ubuntu de se connecter, de modifier un script et de reprendre le service cinq minutes plus tard. Pour un seul panneau de menu au-dessus d’un comptoir, cela peut sembler lourd. Pour une flotte, cela s’amortit souvent en maintenant chaque boîtier cohérent.

Comparaison des approches de kiosque sur Ubuntu

Approche Idéale pour Mises à jour Récupération Verrouillage
Kiosque navigateur sur Ubuntu Desktop Cafés seuls, bars, écrans de menu ponctuels Gérées via apt et les paramètres du navigateur Facile à déboguer localement, mais plus facile à casser Faible
Kiosque basé sur Snap Petites chaînes souhaitant des installations reproductibles Gérées par Snap et centrées sur l’application Modèle de redémarrage d’application plus propre Moyen
Ubuntu Core et Frame Flottes multi-établissements et builds appliance Flux transactionnel, proche d’une image Meilleure cohérence entre les appareils Plus élevé

La question clé n’est pas « web ou natif ». C’est de savoir si vous voulez maintenir une session de bureau, un environnement d’exécution d’application ou une appliance verrouillée.

Pour les écrans de menu de restaurant, je commence encore par le kiosque navigateur, sauf raison claire d’abandonner l’ancien modèle X11 et LightDM. Si le matériel est très tactile, si le déploiement doit être reproductible ou si les écrans sont destinés à plusieurs emplacements, la voie moderne Wayland mérite généralement le travail de configuration supplémentaire.

Construire un kiosque Chromium fonctionnel sur Ubuntu

Le samedi soir à 21 h, personne ne se soucie que Chromium se soit lancé une fois pendant la configuration. On se soucie que le panneau de menu soit revenu après une coupure électrique, qu’il ne soit pas tombé sur un bureau et qu’il n’ait pas laissé un pointeur de souris sur la liste des boissons. C’est la norme que j’utilise pour un kiosque Ubuntu.

Capture d’écran de https://www.chromium.org/

Pour un seul écran de restaurant, Chromium sur Ubuntu reste la voie la plus rapide vers quelque chose avec lequel le personnel peut vivre ce soir. La partie que les vieux tutoriels omettent souvent, c’est le contrôle de session. --kiosk n’est qu’une pièce du puzzle. Vous avez également besoin d’un utilisateur dédié, d’une connexion automatique qui atterrit dans la bonne session à chaque fois, de paramètres de veille qui restent désactivés et d’un chemin de redémarrage pour les plantages du navigateur.

Créer un utilisateur kiosque et garder son monde petit

Utilisez un compte local séparé pour l’écran. Ne réutilisez pas la session de bureau d’un responsable et ne laissez pas le kiosque partager un profil de navigateur normal. Les profils partagés accumulent des extensions, des invites sauvegardées, des notifications de mise à jour et d’autres déchets qui apparaîtront plus tard sur l’écran en direct.

Installez uniquement ce dont le kiosque a besoin :

Je conserve également l’état du navigateur dans son propre répertoire de profil. Cela rend les réinitialisations faciles. Si un cache de site devient corrompu avant le service, vous pouvez supprimer un seul dossier au lieu de fouiller dans un compte de bureau général.

Construire proprement l’ancienne voie X11

Si vous faites le pont entre les anciennes recettes LightDM et les versions plus récentes d’Ubuntu, traitez X11 comme un choix délibéré, pas comme une valeur par défaut résiduelle. Pour les tableaux de menus de restaurant, je l’utilise encore sur le matériel qui s’est déjà montré stable avec LightDM et Chromium. C’est familier, facile à déboguer localement et indulgent lorsque vous devez toucher un script de démarrage à la hâte.

Créez un fichier de configuration LightDM dans /etc/lightdm/lightdm.conf.d/10-kiosk.conf et définissez :

Ajoutez ensuite un fichier de session sous /usr/share/xsessions/ qui pointe vers votre script de lancement.

Ce script de lancement doit accomplir quatre tâches :

  1. Désactiver la mise en veille de l’écran et DPMS.
  2. Démarrer unclutter.
  3. Lancer Chromium avec des options sûres pour le kiosque.
  4. Quitter de manière à permettre à systemd ou à la session de le redémarrer.

Options Chromium utiles pour un affichage de menu :

Laissez le paquet du navigateur système tranquille si la machine est autrement stable. Placez votre comportement personnalisé dans le fichier de session et le script d’enveloppe. Les kiosques sont plus faciles à récupérer lorsque les fichiers appartenant à la distribution restent proches de l’état d’origine.

Désactiver les interruptions au bon niveau

Ubuntu suppose toujours qu’il exécute un bureau, sauf indication contraire. La suspension, la mise en veille de l’écran, les écrans de verrouillage et les actions d’inactivité doivent être désactivés là où la session active les lira.

Sur une configuration LightDM avec session X personnalisée, les anciens outils X11 comptent toujours. xset s off, xset -dpms et xset s noblank doivent figurer dans le script d’enveloppe si la session est X11. Modifier les clés GNOME sur une machine qui n’entre jamais dans une session GNOME fait perdre du temps et vous donne la fausse impression que le problème est résolu.

Beaucoup de constructions de kiosque d’époques mixtes tournent mal. Quelqu’un copie les paramètres GNOME d’un guide Wayland sur un kiosque LightDM, ou copie des commandes X11 sur une session kiosque GNOME plus récente et s’attend au même résultat. Faites correspondre la correction à la session que vous démarrez.

Pour les menus qui changent au cours de la journée, le modèle navigateur simplifie les opérations. Le personnel met à jour l’application web, pas le boîtier au-dessus du comptoir. Ce même modèle fonctionne bien pour les mises à jour de menu QR en temps réel sur plusieurs sites.

Tester l’échec, pas seulement le démarrage

Un kiosque qui ne survit qu’à un redémarrage propre n’est pas encore terminé.

Avant de quitter le site, testez ces cas :

Je vérifie également ce qui se passe après que le navigateur a tourné pendant quelques heures. Certains overlays tactiles et adaptateurs HDMI bon marché se comportent bien pendant dix minutes, puis commencent à faire des choses étranges lorsque la chaleur s’accumule.

Une petite vérification visuelle rapide est utile pour valider les options et le comportement de lancement sur place :

Ajouter un chien de garde

Chromium finira par planter. Prévoyez cela.

Un simple service systemd avec Restart=always est généralement suffisant pour une installation de restaurant à écran unique. Si le script d’enveloppe se termine ou si le navigateur meurt, la session redémarre sans que le personnel ait à toucher un clavier. Cette étape compte plus dans le monde réel que de gagner une minute de plus sur la configuration initiale.

L’objectif est un comportement ennuyeux. Le courant revient. Le réseau revient. Chromium revient. Le menu est de retour à l’écran avant que le personnel du bar ne décide que le boîtier est maudit.

Wayland vs X11 et sessions kiosque GNOME

La plupart des confusions autour du mode kiosque sur Ubuntu proviennent désormais d’un fait. Les anciens guides supposent X11 et LightDM. Les nouveaux systèmes Ubuntu vous orientent de plus en plus vers Wayland et des sessions kiosque orientées GNOME. Les deux peuvent fonctionner, mais ils ne se comportent pas de la même manière.

Un guide récent sur les kiosques Ubuntu sécurisés souligne directement ce décalage. Les guides plus récents mentionnent de plus en plus gnome-kiosk-script-wayland et la configuration de fichiers de session, tandis que les anciennes recettes reposent encore sur l’autologin hérité, les Xsessions et les scripts de lancement de navigateur. Cela laisse les opérateurs deviner quel chemin convient à quelle version d’Ubuntu et à quel mélange de matériel (écart entre les conseils de kiosque Wayland et hérités).

Ce qui change sous Wayland

Avec Wayland, le compositeur s’approprie davantage la session. La mise en veille de l’écran, la gestion des entrées et le comportement des fenêtres sont appliqués différemment. Plusieurs vieilles habitudes X11 ne se transposent pas proprement, en particulier tout ce qui dépend de xset, des bidouillages directs de session X ou des astuces de gestionnaire de fenêtres.

Ce n’est pas une mauvaise chose. Les kiosques Wayland sont souvent plus propres. Mais ils punissent les commandes X11 copiées sans réfléchir.

Pour vérifier ce qu’un système en cours d’exécution utilise, examinez la session avec loginctl et confirmez si le type est wayland ou x11. Ne partez pas du principe en vous basant uniquement sur la version d’Ubuntu.

Quand utiliser chacun

Aspect Session X11 Session Wayland
Recettes de kiosque navigateur Matures et largement documentées Plus modernes, moins de bidouillages hérités
Bizarreries des écrans tactiles Meilleure solution de repli pour le vieux matériel Meilleur choix par défaut sur Ubuntu actuel
Contrôle de l’alimentation et de la veille Souvent piloté par des scripts Plus piloté par le compositeur
Verrouillage de session Plus facile à improviser Plus propre s’il est construit correctement
Maintenance à travers les versions Les guides hérités aident encore Mieux aligné sur l’orientation actuelle

Si vous déployez sur Ubuntu 22.04 ou plus récent et que l’écran tactile est raisonnablement actuel, je choisirais Wayland par défaut. Gardez X11 pour les panneaux plus anciens, les piles graphiques atypiques ou les anciens contrôleurs tactiles qui ne fonctionnent qu’avec des pilotes hérités.

Règle de décision pratique

Pour une connexion automatique GDM vers une session kiosque, utilisez le chemin orienté kiosque de GNOME lorsque vous voulez rester proche de la pile de bureau Ubuntu moderne. Pour un appareil d’affichage géré par le compositeur, Ubuntu Frame est la voie la plus propre. Pour un vieux matériel qui fonctionne déjà sur LightDM plus Openbox ou une session X personnalisée, ne le réécrivez pas simplement parce que Wayland est plus récent.

La mauvaise décision est de mélanger les deux modèles sur une même machine et d’espérer que les parties utiles de chaque pile coopèrent.

Si vous travaillez avec la configuration des sièges ou des wrappers de session, gardez-les minimaux. Une configuration de base de seatd ne doit exister que pour prendre en charge le compositeur ou la pile d’entrées que vous exécutez. N’empilez pas des solutions de contournement X11 héritées sur un kiosque Wayland, à moins d’avoir prouvé un besoin matériel réel.

Écrans tactiles, claviers et gestion des périphériques

Un kiosque qui démarre proprement peut quand même sembler désagréable dans l’établissement si la couche tactile est bâclée. Les clients le remarquent plus vite que les administrateurs. Si l’écran enregistre les touches un peu à côté, si le mauvais moniteur reçoit l’entrée ou si un clavier virtuel apparaît au hasard, la construction semble cassée même lorsque le navigateur fonctionne techniquement.

Ce qu’il faut régler avant la mise en service

Un graphique de guide technique expliquant comment configurer les écrans tactiles, les claviers et les périphériques pour les systèmes en mode kiosque.

Checklist pour l’établissement qui évite les retours

Lorsque je livre un kiosque dans un café ou un bar, j’effectue cette vérification rapide sur place :

Pour les exploitants qui construisent des écrans de menu destinés aux clients, la même discipline s’applique à la couche de contenu. Un bon matériel de kiosque ne peut pas sauver un menu encombré. Ce guide sur la façon de créer un menu numérique avec des photos gratuitement est utile, car l’affichage et la conception du menu doivent se soutenir mutuellement.

Un kiosque stable est invisible. Personne ne le commente parce que personne ne remarque la machine du tout. Les gens utilisent simplement l’écran.

Utiliser les menus TopFoodApp sur un kiosque Ubuntu

Un kiosque Ubuntu basé sur un navigateur s’adapte bien aux plateformes de menu basées sur les QR codes, car la machine n’a qu’un seul travail. Ouvrir l’URL publique du menu, rester en plein écran et récupérer si le navigateur se ferme. Cela maintient le flux de publication de l’établissement séparé du matériel d’affichage.

Capture d’écran de https://topfoodapp.com/kiosk-mode-ubuntu-menu.png

L’adaptation est opérationnelle, pas seulement technique

Pour les écrans de menu, je définirais l’URL publique du menu comme page de démarrage de Chromium et j’ajusterais la taille de la fenêtre en fonction de l’orientation réelle du panneau. Les panneaux en mode portrait nécessitent des hypothèses différentes de celles des écrans de comptoir. Si la locale du navigateur doit piloter la sélection de la langue, le comportement de lancement doit en tenir compte plutôt que de forcer le personnel à changer manuellement.

La partie intéressante de ce modèle, c’est que le kiosque n’a pas besoin de tâches cron, de scripts de synchronisation de contenu local ou de copies manuelles de fichiers chaque fois que l’établissement change un plat. Le navigateur charge simplement la page en direct. Si l’exploitant modifie le contenu du menu, le kiosque le reflète au rafraîchissement.

Retours d’expérience réels sur le terrain

Le comportement hors ligne est important. Si le Wi-Fi de l’établissement n’est pas fiable, appuyez-vous soit sur le comportement du cache du navigateur pour une résilience temporaire, soit donnez au kiosque une solution de repli de connectivité distincte, comme un modeste dongle 4G. C’est souvent plus précieux que de passer une heure de plus à essayer de rendre un Wi-Fi public instable stable.

Je garde également l’interaction serrée :

Si vous évaluez si les écrans libre-service ont un sens commercial au-delà de la configuration technique, cette analyse des coûts et du retour sur investissement des kiosques de restaurant est un compagnon commercial utile à la construction Linux.

Pour les équipes qui n’ont pas encore mis en place leur pile de menus, un créateur de menu gratuit abaisse la barrière, car vous pouvez tester le flux de travail du kiosque avec une vraie URL de menu au lieu d’une page factice.

Durcissement, mises à jour à distance et checklist de maintenance

La pire hypothèse dans le travail de kiosque, c’est de croire qu’une fois l’écran démarré et en plein écran, le travail est terminé. Ce n’est pas le cas. Un kiosque d’établissement est un appareil à distance, et les appareils ont besoin de règles de maintenance.

Une infographie de checklist détaillant quatre étapes de sécurité et de maintenance pour configurer un système de kiosque Linux.

Ce qu’il faut verrouiller

Supprimez les entrées de bureau supplémentaires si la machine n’en a pas besoin. Désactivez les raccourcis de déconnexion et de changement d’utilisateur dans la session active. Si vous restez sur Ubuntu Desktop, gardez les mises à jour des paquets contrôlées afin que le kiosque ne dérive pas en plein service. Si vous gérez de nombreuses unités, poussez les modifications à partir d’un processus centralisé tel qu’Ansible ou un dépôt signé, plutôt que de modifier manuellement chaque boîtier sur place.

Un redémarrage nocturne reste une solution pratique pour les longues sessions de navigateur. Ce n’est pas élégant, mais cela évite souvent la lente accumulation de bizarreries sur les écrans sans surveillance.

Rythme de maintenance qui fonctionne vraiment

Les kiosques ne tombent généralement pas en panne parce que Linux est fragile. Ils tombent en panne parce que personne ne s’approprie la fenêtre de mise à jour, le chemin de récupération ou la checklist.

Si la machine est importante pour le service, traitez-la comme un petit système de production. C’est moins glamour que de peaufiner les options de lancement, mais c’est ce qui maintient l’écran en vie lorsque l’établissement est plein.

TopFoodApp offre aux restaurants un moyen rapide de publier des menus basés sur des QR codes qui fonctionnent bien sur les écrans de kiosque Ubuntu, en particulier lorsque vous voulez une URL publique stable et des modifications instantanées du menu sans toucher au kiosque lui-même. Si vous construisez un affichage de menu, un écran de comptoir ou une configuration libre-service, il vaut la peine de tester votre kiosque navigateur avec un véritable flux de travail de restaurant sur TopFoodApp.

Publié le:
← Retour au blog