# Écarts entre la fiche validée et le produit livré

Confrontation point par point de la **fiche sujet validée le 25 octobre 2026** (`QRamen-Fiche-Sujet.pdf`)
avec ce qui est réellement livré et démontrable. **Deuxième passage le 27 octobre 2026** : les écarts de
la veille ont été traités et revérifiés en production, navigateur compris.
**Troisième passage le 28 octobre 2026** : relecture de la fiche validée ligne à ligne. Trois engagements
n'étaient couverts par aucune ligne de ce tableau ; ils sont ajoutés en fin de document.

Légende : ✅ livré et vérifié · 🟡 partiel, assumé · ⏳ dépend d’une action d’Alexis.

## Section 5 — Solution envisagée

| Engagement de la fiche | État | Preuve ou reste-à-faire |
| --- | --- | --- |
| Créer sa carte (nom, prix, photo, catégories) | ✅ | L’import IA écrit nom, description, prix et catégorie ; l’assistant propose les descriptions ; et depuis le 27 octobre le gérant **importe la photo du plat** directement dans `/panel` (workflow `photo` → `uploadAttachment` Airtable, la carte publique affiche la pièce jointe). Vérifié depuis l’interface : trois produits portent une photo envoyée, ils apparaissent sur la carte. |
| Imprimer son QR de table | ✅ | Page `/qr` : 12 QR de table, bouton « Imprimer cette planche », styles d’impression. Les 12 QR ont été décodés un par un (`qramen.fr/menu?t=T01` … `T12`). |
| Commande reçue en cuisine avec alerte sonore | ✅ | Son actif par défaut sur `/cuisine`, préférence mémorisée, notification navigateur demandée au premier clic. |
| La salle suit l’avancement | ✅ | Page `/salle` : colonnes « À servir » et « Servie », bouton « Marquer servie ». Parcours vérifié en navigateur : cuisine passe la commande en préparation, la salle la marque servie. |
| Accès séparés cuisine et salle | ✅ | Trois comptes avec rôles distincts (gérant / cuisine / salle), PIN à quatre chiffres pour la cuisine et la salle. Matrice de dix combinaisons testée, voir `SECURITE-ACCES.md`. |

## Section 7 — Automatisations

| Engagement | État | Preuve ou reste-à-faire |
| --- | --- | --- |
| Ticket cuisine à la validation | ✅ | PDF de 23 à 24 ko attaché en 5 s dans `commandes.ticket`, jamais régénéré deux fois (idempotence vérifiée). |
| Confirmation client : récapitulatif au client, copie au gérant | ✅ | Champ e-mail facultatif dans le panier ; le workflow `commande` envoie le récapitulatif au client et une copie au gérant, après la réponse au client. Envoi réel accepté par le SMTP Amen le 27 octobre 2026. Sans adresse, aucun e-mail. |
| Alerte rupture : le plat disparaît de la carte client et remonte en salle | ✅ | Nouvelle route publique `carte` (lecture seule, filtrée sur `disponible = vrai`). Vérifié en navigateur : plat mis en rupture → **39 produits affichés, le plat a disparu sans redéploiement** ; retour en stock → 40. Mail d’alerte conservé. |

## Fonctionnalités cœur

| Fonctionnalité | État |
| --- | --- |
| Carte par catégories, panier, écran cuisine | ✅ |
| Photos de plats | 🟢 40 visuels sur 40 produits (illustrations, provenance : `docs/RAPPORT-IMAGES.md`) |
| QR par table, planche imprimable | ✅ `/qr` |
| Chevalets A4 / A5 | ✅ `/qr-planche-a4.pdf` (1 feuille, 12 cartes à découper, 468 ko) et `/qr-chevalets-a5.pdf` (12 pages A5, QR sur les deux faces retournées, pli au milieu, 522 ko). QR vectoriels, tous décodés après génération. Comparaison : `QRamen-QR-Comparaison-A4-A5.pdf`. |
| Écran salle | ✅ `/salle` |
| Alerte sonore + notification | ✅ |
| Rôles gérant / cuisine / salle | ✅ |
| Paiement optionnel | ✅ case « Paiement en ligne (démonstration) » dans `/panel`, drapeau Airtable `paiement_actif`, mention côté client. Aucun encaissement : la limite « paiement réel » de la fiche reste valable. |

## Section 8 — Usage de l’IA

| Usage annoncé | État |
| --- | --- |
| Import de la carte par photo ou PDF | ✅ 3,7 s pour une carte de test, catégories réelles ; prompt v2 versionné avec règle de catégorisation ; trois modèles comparés (`RAPPORT-COMPARAISON-MODELES.md`). |
| Génération des données de test | 🟡 usage réel (visuels et cartes de test) mais non documenté comme un lot de données générées. |
| Assistant dans le back-office | ✅ bouton « Compléter les descriptions vides » dans la prévisualisation d’import : l’IA propose une description par plat, le gérant garde ou corrige (workflow `assistant`, `gemini-flash-lite-latest`). |

## Section 9 — Périmètre

- Un établissement de démonstration, 40 produits, 6 catégories, 12 tables : ✅
- Trois parcours gérant / client / cuisine / salle : ✅ (quatre écrans)
- Deux automatisations (ticket + confirmation) et une troisième (rupture) : ✅
- Une brique IA visible : ✅ (deux : import et assistant)
- Accès sécurisés : mot de passe ✅, rôles séparés ✅, PIN cuisine et salle ✅
- QR et chevalets imprimables depuis le navigateur : ✅ planche A4 (12 cartes) et ✅ chevalets A5
  (12 pages, QR recto-verso, pli central) : les deux PDF sont générés, contrôlés et servis.
- Documentation technique, rapport de recette, démonstration, support de soutenance : ✅

## Section 10 — Limites

Inchangées et conformes : paiement réel en production, multi-établissements, gestion de stock, abonnement,
application mobile, titres-restaurant. Toutes restent hors périmètre.

## Outils — écarts assumés

- **Make → n8n auto-hébergé** : écart assumé, documenté dans `ECARTS-ASSUMES.md`.
- **Softr** : 🟡 application montée le 28 octobre 2026 (`qramen.softr.app`, quatre pages, trois blocs de
données branchés sur Airtable, écriture vérifiée). Deux limites du plan gratuit : pas de groupes
d'utilisateurs personnalisés, donc pas de rôles gérant/cuisine dans Softr, et les blocs de données sont
des blocs de code. L'authentification et les rôles sont portés par le site Astro (`SECURITE-ACCES.md`).
Détail dans `docs/SOFTR-APP.md`.

## Défaut trouvé et corrigé pendant ce passage

Quand aucune commande n’était active, le workflow `commandes` renvoyait un **corps vide** au lieu de
`{"ok":true,"commandes":[]}` : les écrans cuisine et salle affichaient « Réponse n8n invalide » au lieu de
« Aucune commande » — exactement l’état d’une base de démonstration propre. Le workflow renvoie maintenant
toujours un objet exploitable. Le proxy du Worker a été corrigé en même temps (corps de réponse lu en
entier, sinon Cloudflare servait une réponse compressée vide).

## Engagements de la fiche non couverts (relecture du 28 octobre 2026)

| Section | Engagement de la fiche validée | État réel |
| --- | --- | --- |
| 1 — Titre | « Deux cartes de démonstration (QRamen et QRoque) » | ❌ **Une seule carte livrée.** Le nom QRoque n'apparaît nulle part dans le produit. La fiche excluant par ailleurs le multi-établissements (section 10), il s'agissait de deux jeux de démonstration, pas de deux clients. **Décision d'Alexis du 28 octobre 2026 : reporté.** QRoque pourra devenir un second restaurant virtuel une fois le projet terminé ; il ne sera pas ajouté avant la soutenance. À annoncer comme écart assumé le jour de l'oral. |
| 2 — Contexte | Étude de marché du 25 octobre 2026 sur les pages tarifaires de 22 éditeurs, 175 000 établissements en France, 1 281 à Rouen, 780 € de matériel (Tabesto), 2 à 5 % de commission (Kwizin) | 🟡 **Refaite le 28 octobre** : `docs/ETUDE-MARCHE.md` — 7 éditeurs chiffrés à la source (Tabesto 780 € confirmé, Innovorder, Qoul, Kiwiz, Zenchef, LivePepper, QR2App) et 4 constats de non-publication. Reste 17 éditeurs à visiter. La fourchette « 2 à 5 % attribuée à Kwizin » n'est pas vérifiable : le nom ne se résout pas (Kiwiz = abonnement sans commission). |
| 6 — Outils | « Évolution documentée — Cloudflare Workers + D1 + R2 en remplacement d'Airtable et Softr à la montée en charge (non livré) » | ✅ **Écrite le 28 octobre 2026** : `docs/EVOLUTION-ARCHITECTURE.md` — seuils de déclenchement, cible, ordre de migration sans arrêt de service, coûts et pertes. Rien n'est livré, conformément à la fiche. |
| 8 — Usage de l'IA | Génération des jeux de données de test | 🟡 usage réel (visuels, cartes de test) mais jamais documenté comme un lot généré. |

Ces quatre lignes sont les seuls écarts de la fiche qui n'étaient inscrits nulle part. Tout le reste de la
fiche est couvert et vérifié.