Applications

Application mobile pour restaurant : à quoi elle sert vraiment

Une application de restaurant sert à 4 choses : encaisser des commandes à emporter sans commission de plateforme, remplir des tables par la réservation, faire revenir les habitués et les prévenir par notification. Un bon site suffit souvent avant elle. Voici comment trancher, fonction par fonction.

Applications · Lecture : 18 min · Agence DYNSEO

Application de restaurant : la réponse courte avant de dépenser quoi que ce soit

Posez-vous une seule question : parmi vos clients, combien reviennent au moins une fois par mois ? Si la réponse est « peu », l'application ne vous apportera rien que votre site ne fasse déjà. Si la réponse est « un noyau d'habitués qui commandent le midi ou le vendredi soir », une application a un sens, parce qu'elle transforme ces habitudes en un geste de deux secondes : ouvrir l'icône, retrouver sa dernière commande, valider.

L'erreur classique du restaurateur est de demander une application pour être mieux vu. Or une application ne se découvre pas : elle s'installe après avoir déjà mangé chez vous, ou parce que vous l'avez proposée à la caisse. La visibilité vient d'ailleurs : votre fiche Google, votre site, les avis. Pour cette première marche, voyez nos modèles de sites pour la restauration.

Cet article passe en revue ce que l'application fait réellement pour un restaurant, ce qu'elle ne fait pas, ce que la cuisine et la salle lui imposent, et comment la décision se prend. Pour une vue d'ensemble de nos réalisations de ce type, voyez notre page sur le développement d'applications mobiles.

Ce qu'une application de restaurant fait que votre site ne fait pas

Un site se consulte dans un navigateur, souvent une seule fois, souvent depuis une recherche. Une application vit sur le téléphone : son icône est à côté de celles de vos clients, elle garde leur compte ouvert et elle peut leur envoyer un message. Ce sont ces trois propriétés, et seulement elles, qui justifient son coût.

À l'inverse, l'application ne remplace pas ce que fait le site : apparaître dans une recherche, afficher la carte et les horaires à quelqu'un qui ne vous connaît pas, accueillir un lien partagé par un ami. Sur ce terrain, un site sur modèle bien rédigé est plus efficace qu'une application, et il coûte beaucoup moins cher à créer. Retenez la phrase à garder en tête : le site vous fait connaître, l'application vous fait revenir.

Commande à emporter : garder pour vous ce qu'une plateforme de livraison prélève

C'est la raison la plus concrète de lancer une application. Les plateformes de livraison et de commande en ligne se rémunèrent par une commission sur chaque commande, et le restaurateur ne possède ni la relation avec le client ni ses coordonnées. Une application à votre nom change l'équation : la commande arrive directement chez vous, le client est le vôtre, et vous décidez de la manière de le relancer.

Il faut être lucide sur ce que cela ne résout pas. Une plateforme apporte aussi de la découverte : des clients qui ne vous connaissaient pas vous trouvent parce qu'ils cherchaient « sushi près de moi ». Votre propre application n'apporte aucun nouveau client toute seule. Un restaurateur peut donc garder les deux : la plateforme pour la découverte, l'application pour inciter les clients déjà conquis à commander en direct la fois suivante, par exemple avec un avantage réservé à la commande directe.

La commande à emporter dans votre propre application demande quatre éléments. Une carte à jour, avec la possibilité de retirer un plat en un clic quand il est épuisé. Un paiement en ligne, ou le choix de payer au retrait. Des créneaux de retrait, pour que quinze commandes n'arrivent pas toutes à midi quinze. Et un signal clair en cuisine : une tablette ou une imprimante qui reçoit la commande sans que quelqu'un doive surveiller un téléphone.

Si vous vendez aussi des produits (huile, sauces, coffrets cadeaux), la logique de boutique en ligne s'ajoute à celle du restaurant : nous la traitons dans notre article sur les boutiques en ligne WooCommerce. Pour un restaurant seul, la commande à emporter reste le cœur.

Réservation de table dans l'application d'un restaurant : utile, mais pas partout

La réservation est la fonction que tout le monde demande et que peu utilisent à plein. Dans une application, elle peut prendre deux formes : un simple formulaire qui vous envoie la demande (vous confirmez à la main) ou un vrai calendrier relié à votre plan de salle, qui refuse automatiquement quand la salle est pleine. La première est rapide à créer et suffit pour un restaurant de quartier. La seconde demande de modéliser vos tables, vos durées de repas et vos exceptions.

Avant de la développer, regardez ce que vous faites déjà. Si vos réservations passent par un service de réservation en ligne tiers auquel vous êtes abonné, l'application peut simplement renvoyer vers ce service au lieu de le remplacer. Dans ce cas, vous évitez de développer ce qui existe déjà, et vous gardez votre outil habituel côté salle. C'est souvent le choix le plus raisonnable quand votre planning est déjà organisé autour d'un logiciel.

Un point pratique : pensez à ce qui arrive quand le client ne vient pas. Vous pouvez demander une confirmation la veille par notification, ce qui libère des tables que personne n'aurait annulées. Un acompte en ligne est possible pour les grandes tablées ou les soirées spéciales, mais il se paramètre avec soin (conditions d'annulation, remboursement) et il doit être présenté clairement au moment de la réservation.

Fidélité et notifications : faire revenir les habitués de votre restaurant

Une carte de fidélité numérique reproduit ce que fait la carte à tampons, avec trois avantages : elle ne se perd pas, elle ne se falsifie pas, et vous voyez qui revient. Le mécanisme le plus simple est le compteur de visites ou de commandes : au bout de dix, un café, un dessert ou une entrée est offert. Il se comprend en une phrase, ce qui compte plus que la sophistication.

Les notifications sont l'autre moitié du dispositif, et celle qui se gâche le plus vite. Une notification utile dit quelque chose que le client veut savoir : sa commande est prête, la terrasse ouvre, le plat qu'il commande d'habitude est de retour. Une notification qui tombe tous les jours pour une promotion lassera vos clients, qui désactiveront les alertes de l'application ou la désinstalleront. Fixez-vous un rythme bas (une à deux par semaine au maximum) et réservez-les à ce qui a un intérêt réel.

Sur le plan des données, vous traitez des informations personnelles dès qu'un client crée un compte : nom, téléphone, historique de commandes. Il faut lui dire à quoi servent ces données et lui laisser choisir de recevoir ou non des messages promotionnels. Nous revenons sur ce point dans la section consacrée aux obligations.

• Notifications de service : commande reçue, commande prête, table confirmée. Ce sont celles que le client attend, elles ne posent aucun problème de lassitude.
• Notifications d'actualité : plat du jour, fermeture exceptionnelle, soirée à thème. À limiter et à écrire comme on parle à un habitué.
• Notifications d'offre : avantage de fidélité atteint, geste d'anniversaire. Elles marchent d'autant mieux qu'elles sont personnelles et rares.

Site, application ou les deux : le choix d'un restaurateur selon son établissement

Le tableau ci-dessous compare les trois options sur les critères qui comptent pour un restaurant. Il ne dit pas qu'une option est meilleure : il montre ce que chacune fait bien et où elle s'arrête.

Une troisième voie existe, entre les deux : un site conçu pour mobile, qui s'ajoute à l'écran d'accueil du téléphone comme une application. Il ne fait pas tout ce que fait une application installée, mais il couvre le besoin d'accès rapide pour certains établissements. Parlez-en lors du cadrage : la bonne solution dépend de ce que vous voulez vraiment faire faire à vos clients.

Deux restaurants imaginaires, deux décisions différentes

Les deux situations suivantes sont illustratives. Elles ne décrivent pas des clients réels et ne contiennent aucun chiffre d'activité : elles servent à montrer comment le raisonnement se déroule.

Scénario 1 : une brasserie de quartier qui sert surtout le midi

Imaginons une brasserie dont le service du midi attire des salariés des bureaux alentour. Ils commandent souvent la même chose, veulent la récupérer vite et n'ont pas le temps d'attendre au comptoir. Ici l'application a un vrai rôle : retrouver la dernière commande, choisir un créneau de retrait entre douze heures et treize heures, payer en ligne, et être prévenu quand le plateau est prêt. Le restaurateur y gagne un étalement des retraits et une cuisine moins bousculée au coup de feu.

La réservation, elle, reste très secondaire pour ce profil : la clientèle du midi ne réserve pas. On ne la développe donc pas dans la première version. Le budget part dans la commande à emporter, l'interface de réception en cuisine et la désactivation rapide des plats épuisés.

Scénario 2 : un restaurant gastronomique ouvert le soir et le week-end

Imaginons maintenant un restaurant qui sert une cuisine d'auteur sur réservation, avec un menu qui change. La commande à emporter n'a aucun intérêt : on n'emporte pas un menu dégustation. Une application serait ici surdimensionnée. Ce qui compte, c'est un site élégant, une fiche Google soignée, une réservation claire et, au besoin, un envoi de lettre d'information pour annoncer les nouveaux menus.

Si le restaurateur voulait malgré tout une application, ce serait pour un cercle d'habitués : accès anticipé aux dates de réservation, invitation à des soirées. Le raisonnement reste le même : l'application sert une relation qui existe déjà, elle ne la crée pas. Dans ce scénario, nous recommanderions de commencer par le site.

Ce que la salle et la cuisine imposent à l'application d'un restaurant

Un restaurant n'est pas un commerce comme un autre : l'offre change à chaque service, la cuisine a une capacité limite, et l'équipe n'a pas le temps de se pencher sur un outil compliqué. Une application qui ignore ces contraintes sera abandonnée en deux semaines par les équipes, même si les clients l'aiment.

Le premier besoin est le tableau de bord de la cuisine : un écran, de préférence sur une tablette fixée, où arrivent les commandes avec un signal sonore, et où l'on peut passer une commande de « reçue » à « en préparation » puis « prête » d'un appui. Chaque changement de statut déclenche la notification au client. Sans cet écran, la commande se perd entre le téléphone et le passe-plat.

Le deuxième est la gestion de la carte par l'équipe elle-même. Le chef doit pouvoir marquer un plat comme épuisé, changer le plat du jour ou ajuster un prix sans appeler un développeur. Cette autonomie se prévoit dès le cahier des charges ; elle conditionne la durée de vie de l'outil.

Le troisième est le contrôle du flux. Vous fixez un nombre maximal de commandes par quart d'heure, et l'application referme les créneaux complets. C'est ce qui évite que la commande en ligne ne désorganise le service en salle. Enfin, le quatrième est le mode dégradé : que se passe-t-il quand la connexion de la cuisine tombe ou que la tablette s'éteint ? Prévoyez un moyen de recevoir un message de secours, et de suspendre la commande en ligne en un geste.

Allergènes, prix, données clients : ce que l'application d'un restaurant doit respecter

Nous ne sommes pas juristes, et les règles évoluent : le contenu ci-dessous est un repérage général, à faire valider auprès de votre organisation professionnelle ou d'un conseil si un point est incertain. Trois sujets reviennent systématiquement pour un restaurant qui vend en ligne.

L'information sur les allergènes. Un restaurateur doit pouvoir renseigner ses clients sur la présence d'allergènes dans ses plats. Dans une application de commande, cette information doit être accessible sur la fiche du plat ou à côté de la carte, et rester à jour quand une recette change. Prévoyez qui met à jour cette information, et comment : c'est un travail d'organisation avant d'être un travail technique.

L'affichage des prix et le paiement. Un consommateur doit voir le prix à payer avant de valider, toutes taxes comprises, et recevoir une confirmation de sa commande. Si vous utilisez un prestataire de paiement en ligne, c'est lui qui gère les données de carte : l'application ne les stocke pas. Les modalités de remboursement en cas de commande annulée ou non retirée doivent être écrites et accessibles.

Les données personnelles. Dès qu'un compte existe, vous traitez des données personnelles. Il faut une politique de confidentialité compréhensible, un consentement distinct pour les messages promotionnels, et la possibilité de supprimer son compte. Si vous envoyez des notifications, l'utilisateur doit pouvoir les refuser sans perdre l'accès à sa commande. Les boutiques d'applications demandent d'ailleurs une déclaration des données collectées au moment de la publication.

Budget d'une application de restaurant : ce qui fait varier le prix

Chez l'Agence DYNSEO, une application simple démarre à 5 000 € HT et une application métier, avec des fonctions spécifiques à votre activité, se situe entre 8 000 et 15 000 € HT. Une application de restaurant avec commande à emporter, créneaux, paiement et écran de cuisine relève plutôt de la seconde catégorie, alors qu'une application limitée à la carte, à la fidélité et aux notifications relève de la première. Le simulateur de coût d'application mobile donne une première estimation selon les fonctions choisies.

Cinq éléments font monter ou descendre le budget. Le premier est la commande : sans paiement en ligne ni créneaux, l'application est simple ; avec, elle devient un petit système de vente. Le deuxième est l'écran de cuisine, qui est une seconde application côté équipe. Le troisième est la réservation : un formulaire coûte peu, un calendrier lié à un plan de salle beaucoup plus. Le quatrième est le nombre d'établissements : une enseigne de plusieurs adresses demande des cartes, des horaires et des stocks par point de vente. Le cinquième est la connexion à vos outils : caisse, logiciel de réservation, système de fidélité existant.

Sur la technique, nous développons souvent avec Flutter, qui permet de produire une application pour iPhone et pour Android à partir d'un même code. Ce choix évite de payer deux développements. Pensez enfin aux coûts qui ne sont pas dans le devis de développement : le compte développeur sur chacune des deux boutiques d'applications est payant, et le service d'envoi de notifications ou de paiement peut avoir ses propres frais.

Si vous démarrez, la séquence la plus économique consiste à créer d'abord un site sur modèle, dès 500 € HT, avec un bouton de commande ou de réservation, puis à mesurer ce que vos clients utilisent vraiment. C'est la mesure qui justifie, ou non, le passage à l'application.

De l'idée à l'installation chez vos clients : le projet d'application de restaurant en étapes

1. 1

   Cadrer le besoin avec l'équipe de salle et de cuisine

   Un échange d'une heure suffit à lister les fonctions qui comptent, celles qu'on repousse et les contraintes de service. Venez avec vos horaires, votre carte actuelle et les outils que vous utilisez déjà (caisse, réservation).

2. 2

   Valider les maquettes

   Nous dessinons les écrans principaux : carte, panier, créneau de retrait, suivi de commande, côté cuisine. Vous les testez comme un client, puis comme le chef. Les allers-retours sont illimités jusqu'à votre validation.

3. 3

   Développer et connecter

   Écrans, comptes clients, paiement, notifications, écran de cuisine. Les connexions avec vos outils existants se font à cette étape.

4. 4

   Tester en conditions réelles

   Passez des commandes de test comme un client, faites-les traiter en cuisine, annulez-en, remboursez-en. Nous faisons ces tests avec vous, et ils sont offerts, comme la formation de l'équipe.

5. 5

   Publier sur les boutiques d'applications

   Apple et Google peuvent examiner l'application avant de la rendre disponible. Ce délai échappe à l'agence et peut s'allonger si un point est à corriger ; il est donc prudent de ne pas caler le lancement le jour même de la validation.

6. 6

   Lancer auprès de vos clients

   L'application ne se découvre pas seule. Un code à scanner sur les tables et au comptoir, un mot du serveur lors de l'encaissement, un avantage à la première commande dans l'application.

Après le lancement, le travail continue à petite échelle : mettre à jour la carte, répondre aux retours de l'équipe, suivre quelles fonctions sont réellement utilisées. Les systèmes des téléphones évoluent aussi, et une application doit suivre. Prévoyez un contrat de maintenance ; notre équipe peut en discuter dès le cadrage, et une intervention dans l'heure ouvrée est prévue en cas de panne.

Les erreurs qui rendent l'application d'un restaurant inutile

• Commencer par l'application alors que le site est faible. Si votre fiche Google est incomplète et votre site illisible sur téléphone, l'application aura peu de monde à fidéliser.
• Vouloir tout mettre dans la première version. Commande, réservation, fidélité, livraison, jeux concours : chaque fonction ajoutée retarde le lancement. Une première version centrée sur la commande à emporter se teste plus vite.
• Oublier la cuisine. Une commande qui arrive sur le téléphone personnel du chef sera ratée le soir de forte affluence. Prévoyez un écran dédié et une procédure.
• Laisser la carte à mettre à jour par un développeur. Dès que changer un prix passe par un prestataire, la carte de l'application se met à différer de la carte du restaurant.
• Envoyer trop de notifications. Le premier effet d'un rythme trop soutenu est la désactivation des alertes, qui prive l'application de son principal avantage.
• Ne rien prévoir pour amener les clients à l'installer. Sans geste en salle, l'application reste vide. Un avantage lié à la première commande et un affichage au comptoir font la différence.
• Négliger l'information allergènes dans la fiche des plats. Une donnée obsolète est pire qu'une absence de donnée, parce qu'elle donne une fausse assurance.