Commander ses sushis sans décrocher le téléphone.
Un restaurant japonais à emporter, son WordPress remplacé par une application de commande sur mesure — sans paiement en ligne et sans une seule photographie de produit.
Le point de départ.
Une petite équipe, pas de service informatique, et un site qui ne servait qu'à être là.
- Les commandes arrivent au téléphone et sur Messenger, notées à la main
- Un WordPress à maintenir, sans personne pour s'en occuper
- 138 produits à la carte, et pas une photographie pour les montrer
- La composition d'un roll n'existe que sur la carte papier
Trois partis pris qui commandent le reste.
Ce qui a été décidé avant d'écrire une ligne de code.
Aucun paiement en ligne
Une commande est une demande, pas une vente. Elle n'est ferme qu'après confirmation du restaurant.
- Pas de compte client
- Pas de remboursement à traiter
- Règlement au retrait
- Charge réglementaire réduite d'autant
La conversation reste sur Messenger
Les clients y écrivaient déjà. Le site prépare la commande, Messenger la porte.
- Rien de nouveau à installer
- Le fil de discussion existe déjà
- Le restaurant répond où il a l'habitude
- Confirmation dans la conversation
Rien n'est inventé sur les produits
Toute la composition affichée est dérivée de la carte papier du restaurant.
- Le bandeau de famille donne la base
- Le nom du produit donne la garniture
- Un ingrédient non imprimé n'apparaît pas
- Une seule source de vérité
138 produits, aucune photographie.
Le morceau le plus intéressant du projet.
Le restaurant n'a pas de photographie pour ses produits, et n'en aura jamais. La première version affichait donc une même coupe ronde générique, teintée selon les ingrédients — ce qui donnait une brochette de poulet dessinée comme une tranche de maki.
La solution : douze modèles d'illustration en CSS pur, choisis d'après la famille du produit, et huit formes d'ingrédients composées automatiquement au centre depuis la recette réelle.
- Coupe transversale seulement pour ce qui est réellement roulé — California, maki, snow, egg roll — chacun avec sa construction : riz et sésame dehors et nori dedans pour le California, nori dehors pour le maki, riz nu pour le snow, omelette pour l'egg roll
- Forme réelle pour tout le reste : nigiri, tranches sur assiette, cône, triangle, bol, silhouettes de friture, brochettes, plateau vu de dessus
- La garniture suit la personnalisation : retirer le concombre retire sa forme de la coupe, en direct
- Résultat : aucun visuel à produire par produit. Un plat ajouté à la carte est illustré le jour même, sans photographe et sans travail graphique
Ce qui a été livré.
Quatre modules, plus le passage à Messenger.
La carte
138 produits en 16 catégories, regroupés en univers navigables.
- Recherche par code ou par nom
- Filtres veggie, saumon, thon, crevette, cuit
- Sommaire toujours visible
- Prix et disponibilité tenus à jour
La fiche produit
Ce qu'il y a dans le roll, couche par couche, et de quoi en retirer ce qu'on ne veut pas.
- Composition détaillée par ingrédient
- Retrait à l'unité
- Retrait transmis au restaurant
- Revérifié côté serveur
Les créneaux de retrait
Calculés depuis les horaires d'ouverture réels et le délai de préparation.
- Aucun champ d'heure libre
- Impossible de choisir une heure fermée
- Créneaux trop proches affichés barrés
- Un trou inexpliqué inquiète plus qu'une explication
Le back-office
L'écran de service du restaurant, en temps réel.
- Commandes acceptées ou refusées
- Gestion des disponibilités
- Édition de la carte
- Rattachement de la conversation Messenger
Le parcours, du panier au comptoir.
Le client compose, choisit son créneau, puis termine sur Messenger. Le restaurant confirme, le client règle au retrait.
Ce qu'il y a dessous.
Environ 8 100 lignes de PHP réparties en 68 classes, 56 templates, 23 modules JavaScript et 18 classes de tests. Hébergement mutualisé, déploiement par SSH.
LE PASSAGE À MESSENGER
- L'URL m.me ne porte qu'un jeton aléatoire
- Meta le renvoie sur un webhook signé
- La conversation est rattachée à la commande côté serveur
LA MISE EN PRODUCTION
- Le WordPress de 731 Mo a été déplacé, pas supprimé : retour arrière possible en une commande
- Le code vit hors de la racine web, seul le dossier public y est exposé
- Même une configuration serveur cassée ne peut pas divulguer le code ou les identifiants
- Les URL indexées du WordPress ont été conservées à l'identique
Un projet du même genre ?
Un message suffit : ce que vous voulez obtenir, et pour quand. Réponse en 48 h ouvrées avec un premier ordre de prix.