Développement e-commerce pour la restauration et la vente à emporter
La commande en ligne de repas ne ressemble à aucun autre e-commerce : un plat se vend par service, sort de la carte quand la matière première manque, revient le lendemain, et doit finir imprimé en cuisine. C’est le type de mission que je traite sur ce secteur.
Un menu n’est pas un catalogue
Sur une boutique classique, un produit existe ou n’existe pas, et son stock décroît jusqu’à zéro. Sur une carte, la disponibilité est une fonction du créneau : le plat du jour n’existe que le midi, la formule du soir n’ouvre qu’à partir d’une certaine heure, et une rupture de matière première retire un plat en plein service avant qu’il ne réapparaisse le lendemain. Modéliser cela comme une quantité en stock produit des états faux et des commandes que la cuisine ne peut pas honorer.
Les options aggravent le malentendu. Cuisson, accompagnement, sauce, suppléments : ce sont des groupes de choix à contraintes — un choix obligatoire ici, trois au maximum là — dont chacun peut modifier le prix affiché. Traités comme des déclinaisons au sens du CMS, ils provoquent une explosion combinatoire de références dès la deuxième catégorie de la carte. Il faut un modèle d’options rattaché au plat, avec ses propres règles de minimum et de maximum, et non un produit distinct par combinaison.
Ce qui casse quand on part d’un module de vente générique
- La disponibilité est enregistrée comme une quantité, alors qu’elle dépend du service et du jour de la semaine.
- Le tunnel accepte un créneau déjà saturé et ne le refuse qu’après l’encaissement, quand la cuisine découvre la commande.
- Le temps de préparation est fixe, alors qu’il varie selon le contenu du panier.
- La zone de livraison est saisie comme une liste de communes, alors qu’elle se dessine géographiquement autour du point de vente.
- Les frais de livraison partent en totalité sur un taux de TVA unique, ce qui fausse l’addition dès qu’une bouteille entre dans le panier.
- Les allergènes vivent dans une note en bas de carte au lieu d’être une donnée rattachée à chaque plat.
- La commande arrive par e-mail : personne ne la voit passer quand le service bat son plein.
Trois taux dans la même addition, et une donnée allergène par plat
Une addition mélange couramment de la vente à consommer immédiatement, des produits destinés à une consommation différée et des boissons alcoolisées, qui ne relèvent pas du même taux. Aucun des trois CMS que je pratique ne ventile spontanément les frais de livraison entre ces taux : par défaut, la ligne de port porte un taux unique et le document remis au client devient inexact. Il faut donc une ventilation proportionnelle au contenu réel du panier, appliquée au calcul du total, et un modèle de document qui affiche le détail taux par taux.
Les allergènes relèvent d’une logique voisine. L’information est obligatoire, elle se porte plat par plat, et elle change à chaque évolution de recette ou de changement de fournisseur. Écrite au fil de la description, elle est introuvable et impossible à corriger en masse. Structurée comme un attribut du plat, avec une liste de valeurs fermée, elle se filtre, s’affiche au moment du choix et se met à jour en un seul endroit.
Comment j’interviens sur un projet de commande en ligne
-
Reprendre la carte réelle
Je pars du support existant, papier ou logiciel de caisse : plats, groupes d’options, règles de disponibilité par service. C’est ce document qui détermine le modèle de données, pas l’inverse.
-
Poser le moteur de créneaux
Capacité maximale par tranche horaire, jours de fermeture, temps de préparation calculé à partir du panier, zone de livraison tracée sur une carte plutôt que listée. Le créneau se réserve avant le paiement et se libère si le paiement échoue.
-
Fiabiliser la sortie en cuisine
Impression automatique ou écran de production, accusé de prise en compte, file d’attente qui rejoue les tickets après une coupure d’imprimante. Une commande payée qui n’atteint pas la cuisine est perdue deux fois.
-
Désigner la source de vérité de la carte
Le même plat vit sur le site, sur la caisse et sur les plateformes de livraison, chacune avec son référentiel d’articles et ses identifiants. Je choisis un référentiel maître et je construis les synchronisations autour, plutôt que de laisser trois saisies manuelles diverger.
Sujets voisins
-
Commande à table par QR code
Le parcours en salle, où le numéro de table remplace l’adresse et où la commande part directement en production.
-
Synchronisation des menus de livraison
Tenir une carte unique quand les plateformes imposent chacune leur format et leurs identifiants d’articles.
-
Passerelle vers une caisse hébergée
Faire descendre les commandes du site dans le système d’encaissement sans double saisie.
-
Intégration paiement et caisse
Le rapprochement entre le tunnel de paiement en ligne et le terminal du comptoir.
Questions fréquentes
Peut-on gérer les options de plats avec les déclinaisons du CMS ?
Comment empêcher la vente d’un créneau déjà complet ?
Faut-il synchroniser le site avec les plateformes de livraison ?
Comment sont gérés les allergènes sur la fiche d’un plat ?
Et si l’imprimante de cuisine tombe en panne pendant le service ?
La livraison peut-elle être limitée à un périmètre autour du restaurant ?
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.