Le projet en huit chiffres mesurés
Chaque valeur sort d'un test daté et rejouable. Aucun chiffre n'est une projection.
Les documents du dossier
Support, preuves, écarts, annexes techniques. Les fichiers sont téléchargeables et versionnés dans le dépôt du projet.
Le produit, en accès direct
Rien à installer : le parcours client se fait depuis un téléphone, les écrans du personnel sont protégés par identifiant.
Les écarts assumés
Ce qui diffère de la fiche validée, pourquoi, et ce que ça coûte. Un écart écrit n'est pas un oubli : c'est une décision.
Make → n8n auto-hébergé
La fiche validée prévoyait Make. n8n tourne sur mon serveur : je garde la fabrication du ticket PDF côté machine et je ne dépends d'aucun quota de crédits. Conséquence assumée : l'exploitation et la maintenance du serveur sont à ma charge.
Softr partiel
Le back-office du gérant est bien dans Softr (quatre pages branchées sur Airtable). Les écrans cuisine et salle restent en Astro : ils ont besoin du panier et d'un rendu mobile rapide, et le plan gratuit de Softr interdit les groupes d'utilisateurs personnalisés, donc les rôles séparés.
Carte rendue en JavaScript
Les plats sont lus depuis Airtable et affichés par le parcours, pas figés dans le HTML. Coût mesuré : la page source ne contient aucun nom de plat. Atténué par deux blocs JSON-LD (Restaurant et Menu) générés à la compilation, et par un CLS ramené à 0.
Visuels générés
Les 40 visuels de plats sont des illustrations générées, jamais des photographies du restaurant. Le gérant dépose ses vraies photos depuis l'interface.
Une seule carte de démonstration
La fiche citait deux cartes (QRamen et QRoque). Une seule est livrée ; QRoque est reportée après la soutenance, et c'est une décision datée, pas un oubli.
Le marché, prix vérifiés à la source
Relevé du 28 octobre 2026 sur les pages publiques. Quand un éditeur ne publie pas ses prix, c'est écrit « non publié » — et c'est un résultat.
| Éditeur | Modèle | Prix relevé | Source |
|---|---|---|---|
| Tabesto | Matériel loué | 780 € / location | tabesto.com/en/tarifs |
| Innovorder | Abonnement | 79 à 299 € / mois | innovorder.com/prix |
| Qoul | Commission | 0 € + 7 % et 0,25 € · ou 79 €/mois + 4,5 % | qoul.fr/tarifs |
| Kiwiz | Abonnement par volume | 4,99 à 49,99 € HT / mois | kiwiz.io/prix |
| Zenchef | Sans commission | 0 € par couvert, abonnement par paliers | zenchef.com/fr/formules |
| LivePepper | Abonnement | dès 59 € / mois | livepepper.com/tarifs |
| QR2App | Abonnement sans commission | 19,90 à 39,90 € / mois | qr2app.com/tarifs |
Trois modèles cohabitent et ne se comparent pas dans la même unité : matériel loué (Tabesto, 780 €), commission au passage (Qoul, 7 % — soit 700 € sur 10 000 € de commandes), et abonnement fixe (de 19,90 à 299 €). Les acteurs les plus visibles ne publient aucun tarif.
Ce que le projet m'a appris
Quatre leçons qui viennent d'un défaut rencontré, pas d'un principe général.
Le prompt d'import est devenu une pièce du produit
Sans règle écrite, le modèle inventait une catégorie « Carte ». Le prompt v2 est versionné dans le dépôt avec la liste des six catégories réelles : c'est ce qui rend le résultat reproductible.
L'idempotence se prouve, elle ne se promet pas
La commande porte une clé générée par le navigateur : renvoyée, elle retrouve la commande au lieu d'en créer une seconde. Vérifié en production. Je n'ai pas de preuve sous requêtes strictement simultanées, et je le dis.
Ce qui n'est pas mesuré ne se raconte pas
Chaque chiffre vient d'un test daté. Quand je n'ai pas la mesure, je réponds « je ne l'ai pas mesuré » plutôt que d'avancer une estimation.
Un défaut trouvé vaut mieux qu'un défaut caché
Quand aucune commande n'était active, le workflow renvoyait un corps vide : les écrans affichaient « réponse invalide » au lieu de « aucune commande ». Corrigé, et écrit dans la recette.
Les questions du jury, réponses prêtes
Une réponse = un fait, sa preuve, sa limite. Jamais de promesse chiffrée non mesurée.
Pourquoi n8n et pas Make ?
Make était dans la fiche. Le ticket cuisine est un PDF fabriqué par un service local, ce que Make faisait mal ou indirectement, et je ne voulais pas dépendre d'un quota de crédits. Écart assumé, documenté, avec la contrepartie : le serveur est à ma charge.
Où est le no-code, si le site est en Astro ?
Trois briques sur quatre : Airtable porte les données, n8n les automatisations, Softr les interfaces du gérant. Astro ne sert que la vitrine et le parcours client. Le gérant change un prix ou met un plat en rupture sans qu'on touche au code.
Comment l'IA décide-t-elle de la catégorie d'un plat ?
Le prompt est versionné et contient une règle écrite : classer dans l'une des six catégories existantes, n'en créer une qu'en dernier recours. Sans cette règle, le modèle inventait « Carte » — c'est mesuré et corrigé. Et rien n'entre en base sans validation du gérant.
Deux clients commandent en même temps ?
Clé d'idempotence générée par le navigateur et réutilisée en cas de revalidation : un renvoi retrouve la commande. Vérifié en production, même identifiant, aucun doublon. Limite assumée : pas de preuve d'unicité transactionnelle sous requêtes simultanées.
Et les webhooks client, ils sont ouverts ?
Oui, par conception : on commande sans compte, c'est tout l'intérêt du QR de table. Deux routes publiques contre huit routes d'administration authentifiées. Le risque est écrit dans la documentation plutôt que masqué.
Combien ça coûte par mois ?
Je ne donne pas un chiffre que je n'ai pas mesuré. Ce que je peux dire : site sur Cloudflare Pages, base sur Airtable, n8n sur un serveur que j'exploite déjà, et le modèle IA « lite » — c'est pour ça que j'ai comparé trois modèles.
Qu'est-ce qui n'est pas fini ?
Les 40 visuels sont des illustrations générées, pas des photos prises en cuisine. Aucun paiement en ligne, un seul établissement, pas de test de charge, et le catalogue est borné à 100 produits.
Comment savez-vous que ça marche ?
Trois niveaux : des parcours rejoués en production le 26 octobre (commande, ticket en 5 s, statuts, avis, rupture, import IA), un Lighthouse à 100 en accessibilité, bonnes pratiques et SEO, et une recette écrite qui liste aussi ce qui n'a pas été testé.
Si le restaurant a trois établissements ?
Pas prévu aujourd'hui : la base porte un seul établissement. La structure s'y prêterait, mais il faudrait ajouter la notion de site partout, tickets et statuts compris. Je le présente comme une suite, pas comme un acquis.
Le client peut payer ?
Non, et c'est annoncé sur le site : règlement au restaurant. Le parcours s'arrête à la commande confirmée et au suivi cuisine. Stripe en mode test est la suite logique.
Ce qui n'est pas fini, dit franchement
Les 40 visuels sont des illustrations générées, pas des photographies prises en cuisine. Aucun paiement en ligne, un seul établissement, aucun test de charge, catalogue borné à 100 produits, et pas de preuve d'unicité transactionnelle sous requêtes strictement simultanées. Chacune de ces limites est écrite dans la recette du projet.