MVP de commande pour restaurant avec outils d'IA : parcours idéal et cas limites

Ce dont un MVP de commande pour restaurant a réellement besoin

Un MVP de commande pour restaurant ne fonctionne que si un vrai client peut passer une vraie commande sans rester bloqué. Cela signifie que l'application doit faire plus que montrer un joli menu. Elle doit transformer des tapotements en un ticket clair que la cuisine peut réaliser, et en une confirmation sur laquelle le client peut compter.

Le "happy path" est le parcours le plus simple et le plus fréquent : choisir des articles, sélectionner les modificateurs, entrer les informations, payer (ou choisir de payer sur place), et recevoir une confirmation. Gardez ce parcours délibérément petit et ennuyeux. Moins de choix = moins de risques d'erreur de prix ou de perte de commande.

Votre MVP doit gérer cela de bout en bout :

• Afficher les articles du menu actuels avec prix et disponibilité exacts
• Supporter les modificateurs obligatoires (comme la taille) et les options additionnelles
• Collecter les informations minimales au checkout (nom, téléphone, détails de retrait ou livraison)
• Garder une source unique de vérité pour le total de la commande (articles, taxes, frais, pourboire)
• Confirmer la commande avec un numéro et des étapes claires suivantes

Les applications de commande cassent souvent même quand l'interface a l'air finie, parce que les parties difficiles sont invisibles : les totaux changent, des articles se vendent, des modificateurs sont requis, le paiement peut échouer, et le système doit rester cohérent entre menu, panier et checkout.

Avant de générer du code, décidez des bases pour ne pas tout reconstruire plus tard :

• Retrait, livraison, ou les deux (et quelles données chacune nécessite)
• Horaires, temps de préparation, et ce qui se passe en dehors des heures d'ouverture
• Comment vous modélisez les modificateurs (requis vs optionnel, max de sélections)
• Règles de paiement (payer maintenant vs plus tard, remboursements, paiements échoués)
• Qui reçoit la commande (imprimante, tablette, e‑mail) et ce que signifie "confirmé"

Cartographier le happy path du menu au checkout

Commencez par écrire la commande la plus simple que vous voulez supporter : 1 article, pas de modificateurs, quantité 1, un seul moyen de paiement. Si cela marche à chaque fois, vous avez une base fiable.

Un happy path propre n'est pas seulement une série d'écrans. C'est aussi un ensemble de faits que votre système enregistre à chaque étape pour que la commande puisse être récupérée, remboursée et exécutée.

Voici un flux simple de bout en bout, écrit comme ce que l'utilisateur voit et ce que le système doit enregistrer.

1. Le menu s'ouvre. Utilisateur : catégories et articles. Système : restaurant_id, menu_version, session_id, contexte de localisation (retrait vs livraison).

2. Ajouter au panier. Utilisateur : appuie sur Ajouter. Système : line_item_id, item_id, snapshot du nom, snapshot du prix de base, quantité=1, référence aux règles de taxe.

3. Revue du panier. Utilisateur : voit le sous-total et peut retirer des articles. Système : cart_id, liste des line_items, totaux calculés, avertissements de validation (épuisé, commande minimum).

4. Détails du checkout. Utilisateur : saisit nom, téléphone, heure, adresse si livraison. Système : contact client, type de fulfilment, heure demandée, résultat du contrôle de zone de livraison.

5. Payer et confirmer. Utilisateur : voit la commande confirmée avec un numéro. Système : order_id créé, statut de payment intent/autorisation, totaux finaux, status="confirmed", journal d'audit horodaté des événements clefs.

Définissez le succès en une phrase, et restez strict. Pour la plupart des MVP, le succès signifie : le système crée une commande avec des totaux finaux, le paiement est autorisé (ou marqué paiement plus tard), et l'utilisateur reçoit une confirmation qu'il peut capturer. Si l'un de ces éléments manque, considérez la commande comme échouée et affichez une étape suivante claire.

Pas à pas : le flux le plus simple que vous pouvez livrer

Gardez la première version volontairement ennuyeuse. Votre objectif est une commande propre du menu à la confirmation, avec le moins de décisions possible.

Un flux qui tient en conditions réelles :

1. Démarrez sur le menu. Laissez les gens ouvrir un article pour voir le prix, la description et la photo (optionnelle).
2. Sur l'écran article, laissez-les définir la quantité et choisir les modificateurs seulement s'ils existent (taille, type de lait, options). Pré‑sélectionnez des valeurs sensées.
3. Après "Ajouter au panier", affichez le panier avec des lignes claires : nom de l'article, modificateurs choisis, quantité et total. Facilitez la modification ou la suppression.
4. Collectez ensuite les détails de fulfilment : retrait vs livraison, nom, téléphone et une seule case pour instructions. Ne demandez pas plus que ce que vous allez utiliser.
5. Prenez le paiement, puis affichez un écran de confirmation avec un numéro de commande et la suite (temps estimé, instructions de retrait, ou adresse de livraison).

Un détail qui compte : chaque écran doit avoir une action principale. Sur la page panier, l'action principale est Checkout, pas Appliquer coupon, Ajouter une note et Planifier plus tard qui se concurrencent.

Exemple concret : quelqu'un commande un burger, choisit pas d'oignons et ajoute du fromage, met quantité 2, puis passe de livraison à retrait après avoir vu le frais. Si votre MVP peut gérer ce changement sans perdre les modificateurs ni mal calculer les totaux, vous êtes en bonne voie.

Mettez de côté les fonctionnalités avancées (comptes, promos, paiements partagés, planification). Elles augmentent vite le risque et ne prouvent pas que la boucle de base fonctionne.

Données à modéliser tôt (sinon vous réécrirez plus tard)

La plupart des bugs d'un MVP de commande ne sont pas des bugs UI. Ils viennent de champs manquants et de règles floues dans vos données. Modélisez quelques concepts de base dès le départ et les cas limites deviennent prévisibles.

Commencez par le menu : catégories, articles et prix. Chaque article a besoin d'un flag de disponibilité (et idéalement d'une raison), car "épuisé" et "non proposé aujourd'hui" se comportent différemment au checkout. Décidez aussi si les prix sont par magasin, par emplacement, ou globaux. Même pour un MVP mono‑magasin, expliciter ce choix évite des douleurs plus tard.

Les modificateurs sont le prochain piège de réécriture. Modélisez‑les comme des groupes avec des règles claires : requis vs optionnel, min/max de sélections, et si les choix peuvent se répéter (par ex. extra fromage deux fois). Une structure courante : un article a des groupes de modificateurs, chaque groupe a des options, et chaque option peut changer le prix. Si vous sautez la contrainte max maintenant, vous finirez par coller des validations partout dans l'app.

Les totaux ont besoin d'une source unique de vérité. Décidez comment vous calculez sous‑total, taxes, frais et pourboire, et quand vous arrondissez. Si vous calculez les totaux en trois endroits (client, serveur, reçu), ils seront en désaccord. Écrivez l'ordre des opérations, même s'il est simple.

Les horaires du magasin comptent plus tôt que la plupart des équipes ne le pensent. Modélisez des horaires hebdomadaires plus des overrides ponctuels, les temps de préparation ou fenêtres de retrait, et les zones de livraison (même si votre MVP est retrait‑seulement, enregistrez le choix).

Promos et remises sont optionnels, mais soyez explicite. Modélisez des règles basiques (un code par commande, date d'expiration, minimum) ou indiquez « pas de promos pour l'instant ». Une logique promo à moitié implémentée est une cause fréquente de totaux cassés et de tickets support.

Checkout et confirmation : où la plupart des MVP cassent

Le checkout est l'endroit où l'argent et l'opération réelle touchent votre MVP. L'UI peut sembler terminée tandis que de petits manques ici mènent à des clients énervés, des doubles prélèvements, ou des "nous n'avons jamais reçu la commande".

Autoriser vs capturer : décidez intentionnellement

Beaucoup d'équipes capturent le paiement trop tôt. Un défaut plus sûr est d'autoriser la charge quand le client tape Payer, puis de capturer seulement après que la commande ait été enregistrée avec succès et acceptée pour fulfilment. Si vous capturez immédiatement, prévoyez un plan clair pour des remboursements rapides quand quelque chose tourne mal.

L'échec pour lequel vous devez concevoir : le paiement réussit, mais la commande n'arrive pas à s'enregistrer (erreur base de données, timeout, crash). Traitez cela comme un risque normal, pas un cas rare. Mettez la commande dans une file de récupération afin que le personnel ou le support puisse la recréer ou rembourser rapidement.

Les retries sont un autre tueur silencieux. Les réseaux mobiles chutent, les utilisateurs appuient deux fois, ou le navigateur réessaye une requête. Utilisez une clé d'idempotence par tentative de checkout afin que le serveur puisse retourner le même résultat sans débiter deux fois.

Quand le paiement est fait, la confirmation doit être impossible à manquer et utile. Incluez le numéro de commande, ce qui a été commandé (avec modificateurs), un temps estimé, comment contacter le restaurant ou le support, et le statut du paiement (payé, autorisé, espèces au retrait).

Décidez où la confirmation apparaît. Au minimum, affichez‑la à l'écran. E‑mail ou SMS aident, mais seulement si vous pouvez délivrer de façon fiable et gérer les fautes de frappe.

Exemple : un client paie, voit un spinner, puis perd le signal. S'il rouvre l'app, il doit retrouver la même commande confirmée, pas une seconde charge ou un panier vide.

Principaux cas limites qui cassent les commandes

La plupart des MVP tiennent sur le happy path, puis s'effondrent quand l'état du menu ou du paiement change en cours de commande. Traitez ces cas comme des tests obligatoires.

Changement du menu après construction du panier

Les prix et disponibilités bougent. L'échec le plus simple est quand le prix d'un article change entre la vue menu et le checkout, mais votre total de panier utilise encore l'ancien prix. L'utilisateur se sent trompé, et le personnel voit un total différent.

Presque aussi fréquent : un article est épuisé alors qu'il est déjà dans le panier. Si vous laissez le checkout réussir quand même, la cuisine ne peut pas le préparer. Si vous bloquez le checkout, affichez un message clair et offrez un moyen simple de remplacer l'article.

Les modificateurs causent aussi des cassures silencieuses. Si un modificateur est requis (comme cuisson ou choix d'accompagnement) et que le panier permet une valeur vide, vous aurez des commandes invalides. Cela doit bloquer le checkout, pas échouer plus tard.

Totaux, paiements et retries

Même quand les articles sont corrects, les totaux peuvent diverger à cause d'arrondis, taxes, frais de service, frais de livraison ou remises. Une différence d'un centime entre ce que le client a vu et ce qu'on lui prélève peut déclencher des échecs de paiement et des tickets support.

Les flows de paiement créent les duplications les plus pénibles. Déclencheurs courants : rafraîchir, bouton retour, et réseaux lents. Si l'utilisateur rafraîchit pendant le paiement, il peut créer deux commandes. Si le réseau tombe et que le statut du paiement est inconnu, beaucoup d'utilisateurs réessayeront et vous pouvez vous retrouver avec une commande payée et une autre en attente.

Testez ces points avant le lancement :

• Réévaluez le prix du panier au checkout et affichez ce qui a changé
• Validez articles épuisés et modificateurs requis avant le paiement
• Calculez les totaux en un seul endroit avec règles d'arrondi cohérentes
• Utilisez l'idempotence pour le placement de commande afin que le rafraîchissement ne duplique pas
• Gérez le paiement inconnu avec un chemin de retry sûr

Cas opérationnels que l'on oublie jusqu'au jour du lancement

La façon la plus rapide d'embarrasser un MVP de commande n'est pas un bug sophistiqué. C'est un moment opérationnel simple que votre app n'a pas prévu. Ils arrivent tous les jours dans les restaurants réels et déterminent si le personnel fait confiance au système.

Le restaurant ferme pendant que quelqu'un paie

Les gens naviguent lentement. Si le checkout commence à 21:58 et la fermeture est à 22:00, il faut une règle claire. N'acceptez pas une commande que la cuisine rejettera, et ne débitez pas une carte si vous ne pouvez pas la remplir.

Une approche pratique : revérifier le statut du magasin juste avant le paiement et encore avant de créer la commande. Si le magasin est fermé, affichez un message court et conservez le panier pour que le client puisse réessayer demain.

Modificateurs épuisés et substitutions

Les modificateurs rendent les commandes réelles : pas d'oignons, pain sans gluten, extra épicé. La difficulté vient quand un choix de modificateur devient indisponible. Si le client a déjà payé, le personnel doit avoir une manière sûre de résoudre le problème.

Décidez à l'avance ce que votre MVP supporte. Par exemple : annuler automatiquement avec remboursement complet, mettre la commande en pause et demander l'approbation du client pour une substitution, ou marquer la commande comme nécessitant une attention pour que la cuisine n'entame pas la préparation.

Quand l'imprimante ou le POS est en panne

Même si vous n'êtes pas intégré au POS, votre MVP dépend toujours d'une passation : écran tablette, e‑mail, imprimante de tickets, ou afficheur cuisine. Les appareils tombent hors ligne, le papier manque, le Wi‑Fi saute.

Vous avez besoin d'un plan de secours : la commande doit être visible à un endroit fiable, et le personnel doit pouvoir confirmer qu'il l'a vue.

Les créneaux de retrait se remplissent et le temps de préparation change

Si vous proposez des horaires de retrait, limitez les capacités. Sinon vous vendrez 25 retraits pour 18:15 et garantirez des retards. Le temps de préparation change aussi en cours de service (staff, grosse commande, panne). Faites du créneau de retrait une promesse calculée au checkout, pas un simple menu déroulant statique.

Le personnel modifie ou annule après paiement

C'est courant : mauvaise adresse, appel du client, cuisine incapables. Donnez au personnel un flux clair d'annulation avec motif et d'édition avec note d'audit, et assurez‑vous que totaux, taxes et remboursements restent cohérents.

Pièges courants avec les générateurs de code IA

Les générateurs de code IA peuvent vous faire gagner du temps, mais ils devinent aussi. Les pires échecs arrivent quand le code invente des règles que vous n'avez pas écrites.

Rédigez vos règles métier en clair avant de générer quoi que ce soit : comment fonctionnent les modificateurs, quand la taxe s'applique, si les pourboires sont autorisés, et ce que signifie "épuisé". Sinon l'app se comportera d'une façon quelconque et vous ne le remarquerez qu'avec de vraies commandes.

Pièges récurrents :

• Laisser le générateur inventer des règles métier (arrondis, remises, limites de modificateurs) au lieu d'implémenter vos règles écrites
• Pas de source unique de vérité pour les totaux (frontend vs backend vs reçu en désaccord)
• Données de menu codées en dur qui forcent une réécriture dès qu'il faut éditer
• Secrets exposés (clés API, URLs de base de données, tokens de paiement) dans le dépôt ou envoyés au navigateur
• Validation d'entrée faible (mauvais numéros, adresses incomplètes, caractères inattendus)

Un petit exemple : le total UI inclut un modificateur +2$ pour extra fromage, mais le total serveur ne l'inclut pas. Le client voit 18,50$, est prélevé 16,50$, et le ticket cuisine imprime les mauvais éléments. Ce n'est pas juste un bug, c'est un problème de confiance.

Checklist rapide avant de partager le MVP

Avant d'envoyer votre MVP à un ami (ou un client), faites une passe serrée qui vérifie les quelques points qui causent le plus souvent des échecs embarrassants.

Utilisez un vrai article de menu avec modificateurs (par ex. Burger + cuisson moyenne + pas d'oignon) et placez la même commande deux fois : une fois sur téléphone, une fois sur ordinateur. Si quelque chose paraît incohérent, les utilisateurs le remarqueront vite.

Checklist :

• Le happy path marche sur mobile et desktop : parcourir le menu, choisir modificateurs, ajouter au panier, modifier la quantité, checkout, et voir un écran de succès clair
• Les totaux ne changent jamais de façon inattendue : total ligne, total panier, total checkout et reçu final correspondent exactement (taxes, frais, pourboire, remises inclus)
• Le comportement d'épuisement bloque les mauvaises commandes : les articles indisponibles ne peuvent pas être ajoutés ; si ils s'épuisent dans le panier, l'utilisateur reçoit un message clair et ne peut pas payer
• Les retries sont sûrs : rafraîchir, double‑cliquer sur Payer ou réseaux lents ne créent pas de doubles prélèvements ou de commandes
• Le personnel peut vraiment le voir : la commande apparaît rapidement avec un statut évident et les détails clefs (nom, articles, notes)

Scénario exemple : une commande normale avec des accrocs réalistes

Jordan ouvre votre MVP sur son téléphone à 18:10. Il veut quelque chose de rapide : un burger. Il tape sur le Burger combo et clique sur Personnaliser.

L'UI montre un choix requis : Accompagnement. Jordan choisit Frites. Ensuite il ajoute deux add‑ons optionnels : Extra fromage et Bacon. Tout semble bon, il ajoute au panier.

Deux minutes plus tard, la cuisine marque Bacon comme épuisé. Jordan est déjà dans le panier et appuie sur Checkout. Votre MVP doit attraper ça avant le paiement. Une approche simple : revérifier la disponibilité quand le panier se charge et encore juste avant le débit.

Jordan voit un message clair : "Bacon n'est plus disponible. Retirez‑le ou choisissez un autre add‑on." Le panier met à jour le prix et garde le reste de la commande intact. Jordan retire Bacon et continue.

Sur l'écran livraison, Jordan passe de Retrait à Livraison parce qu'il pleut. L'adresse est dans la zone, donc l'app ajoute un frais de livraison et met à jour la taxe. Le total change immédiatement, et le montant final est rappelé à l'étape de paiement pour éviter les surprises.

Jordan paie par carte. La première tentative est refusée. Au lieu de créer une nouvelle commande, votre système garde une seule commande en attente et laisse Jordan réessayer le paiement. Au second essai, le paiement réussit.

Ce qui est bon à la fin :

• Un seul ID de commande payé, pas deux
• Un seul total de reçu qui correspond au total final du panier
• Un seul ticket cuisine avec les modificateurs corrects (Frites, Extra fromage)
• Statut clair : Payé, en préparation
• Une trace d'audit montrant le changement dû à l'épuisement et la tentative de paiement

Étapes suivantes : durcir un MVP de commande construit par IA pour la production

L'étape suivante est la fiabilité : les vrais clients font des choses imprévisibles. Vous n'avez pas besoin d'une énorme suite de tests le premier jour, mais vous avez besoin d'une méthode répétable pour attraper les échecs qui coûtent des commandes.

Transformez votre happy path et vos cas limites en script de test

Écrivez un petit script que votre équipe exécute à chaque changement de code :

• Passer une commande en retrait avec un modificateur et une note
• Passer une commande en livraison avec taxe + frais + pourboire
• Essayer un article en rupture et confirmer que l'UI répond clairement
• Déclencher un échec de paiement et confirmer que le panier survit
• Vérifier que l'écran de confirmation correspond à ce que la cuisine doit préparer

Décidez ce que vous supportez aujourd'hui vs ce que vous bloquez. Bloquer est acceptable en MVP si c'est expliqué clairement (par ex. livraison non disponible pour cette adresse, ou max 12 articles par commande).

Ajoutez de la journalisation basique pour diagnostiquer les commandes échouées rapidement

Quand une commande échoue, vous avez besoin de réponses en quelques minutes. Logger un seul order ID tout au long du flux (panier, checkout, paiement, confirmation), et enregistrez la raison quand quelque chose est rejeté. Capturez des événements clefs comme payment authorized vs payment captured, et quand l'inventaire a été vérifié.

Si vous avez hérité d'un prototype généré par IA qui a l'air fini mais qui perd des commandes dans des cas limites, une courte passe de diagnostic peut sauver des semaines de patchs. FixMyMess (fixmymess.ai) se concentre sur l'audit et la réparation de code généré par IA, particulièrement autour de la logique de commande, du durcissement de la sécurité et de la préparation au déploiement.