Application de commande pour une enseigne de restauration rapide (11 restaurants)

Le contexte

Après le site, il fallait à notre client une vraie app de commande. Pas un site emballé dans une icône : une application que le client installe, où il compose son plat, paie, et vient le chercher. Trois cuisines, des rushs midi et soir, et une équipe qui n'a pas le temps de prendre des commandes par téléphone.

Comme tout ce qu'on construit, l'app a été conçue sur place, dans les cuisines du client, et testée en service avant d'être publiée.

Le problème

La première version était un site web emballé. Apple l'a refusée : pas de fonction native, aucune raison de la publier. Il fallait une vraie app, avec de vraies fonctions.

Ensuite, les commandes arrivaient par message. Le client envoyait lui-même un texte pré-rempli, le restaurant le lisait, le ressaisissait, et le numéro du resto se retrouvait chez tous les clients. En plein coup de feu, ça ne tient pas.

Enfin, l'app affichait « Ouvert » en dur. Un client a commandé à un restaurant fermé. La commande est partie dans le vide, et le client a attendu pour rien.

La solution

Composer son plat comme au comptoir

La carte complète est dans l'app : les plats signature en trois tailles avec le choix de la sauce, les garnitures pré-cochées et les suppléments payants, les menus avec deux sauces au choix, les sides, les desserts, les boissons, les offres. Chaque produit s'ouvre dans une feuille de personnalisation, options obligatoires et maximums compris. Un rappel propose la boisson et les frites après un plat, et un dessert avant de payer. Les codes promo fonctionnent au panier.

Commander en trente secondes

Le client choisit son restaurant, sur place ou à emporter, son heure de retrait, et c'est parti. Compte léger : prénom, téléphone, e-mail vérifié par un code à quatre chiffres, pas de mot de passe. Le mode invité existe pour ceux qui veulent juste commander. Le client peut supprimer son compte en un geste, comme l'exigent les stores.

Payer en ligne ou sur place

Paiement par carte, Apple Pay ou Google Pay via Stripe, ou paiement au comptoir au retrait. Dans les deux cas, la commande part vers Pilot, la plateforme de gestion qu'on a construite pour l'enseigne, et s'affiche sur la tablette de cuisine du bon restaurant. Deux gestes pour l'équipe : « en préparation », puis « prête ». Le ticket sort sur l'imprimante de cuisine.

Prévenir le client quand c'est prêt

Quand l'équipe passe la commande en « prête », le client reçoit une notification push sur son téléphone. L'autorisation est demandée au moment de la commande, jamais au lancement de l'app. L'écran « Mes commandes » garde l'historique et se met à jour tout seul tant qu'une commande est en cours. Aucune recherche par numéro de téléphone : seul le téléphone qui a passé la commande peut la suivre.

Respecter les horaires de chaque restaurant

Les créneaux de service de chaque restaurant sont dans l'app, jour par jour. Si le restaurant est fermé, l'app le dit, affiche la prochaine ouverture et refuse l'envoi en gardant le panier. L'ouverture du troisième restaurant a été programmée à l'avance : visible dans l'app avec sa date, il a accepté sa première commande le jour J sans qu'on touche à rien.

La stack et les choix techniques

L'app est construite avec Capacitor : une seule base de code web, publiée sur iOS et Android, et disponible dans un navigateur comme PWA. On a choisi du JavaScript sans framework pour rester léger et garder la main sur chaque écran.

Le serveur tient en quelques fonctions Netlify : création de la session de paiement, enregistrement de la commande, suivi d'état. Les commandes vivent dans la base Supabase de Pilot, ce qui évite toute double saisie. Les notifications passent par les services natifs d'Apple et de Google, avec un jeton stocké sur la commande et non sur un compte, pour que le mode invité fonctionne.

Le contrôle des horaires se fait au moment de l'envoi, dans l'app. La publication sur Google Play et l'App Store a été menée de bout en bout : captures, fiches, déclaration de confidentialité, compte de démonstration pour les examinateurs.

Les résultats

L'app est publiée sur Google Play, soumise sur l'App Store, et utilisée tous les jours dans les 11 restaurants. Les commandes arrivent en cuisine sans aucune ressaisie, le téléphone du restaurant ne sonne plus pour prendre une commande, et les clients savent quand venir.

Les chiffres sont en cours de consolidation : nombre de commandes par semaine, panier moyen comparé aux plateformes, commissions évitées. On les publiera dès qu'on aura plusieurs mois de recul.

Ce qu'on en retient

Une app de commande doit parler à la cuisine. Si la commande ne tombe pas directement sur un écran en cuisine, elle crée du travail au lieu d'en enlever. Le lien avec l'outil de gestion est le vrai cœur du projet.

Les horaires sont une donnée, pas un texte. Un restaurant qui affiche « ouvert » en dur finira par encaisser une commande fantôme. Les créneaux doivent être lus par la machine.

Les stores ont leurs règles, autant les connaître avant. Fonction native obligatoire, suppression de compte, compte de test pour les examinateurs, boutons décoratifs interdits. On a appris sur les refus essuyés pendant ce projet. Nos prochains clients n'auront pas à le faire.

Essayez-la par vous-même

L'appli de commande s'essaie gratuitement pendant 14 jours sous une enseigne fictive, Burger Station, avec trois restaurants et une carte de burgers. Passez une commande depuis votre téléphone : elle arrive en direct dans la démo de Pilot, comme en cuisine. Ouvrir un accès d'essai.