# Soutenance QRamen — plan de dix minutes

État de référence : **26 octobre 2026 à 22 h (Europe/Paris)**, d’après les faits de production fournis et les preuves conservées. Site en ligne : **[qramen.fr](https://qramen.fr)**, **Cloudflare Pages**, projet **`qramen-soutenance`** (domaine acheté chez Amen, DNS délégué à Cloudflare, mis en service le 26 octobre 2026 à 22 h 50 ; l’adresse `qramen-soutenance.pages.dev` reste accessible en secours).

Support à préparer : dix diapositives, une minute prévue par diapositive. Ces durées sont un budget de présentation, pas des mesures du produit. Aucun gain commercial ni score de performance n’est revendiqué. Distinguer les faits actuels fournis des essais historiques et de leurs limites.

**Le support est produit** : `QRamen-Support-Soutenance-v6.pdf` (dix diapositives 16:9, identité Kōban Vitrine, avec les notes orales « à dire » pour la répétition) et `QRamen-Support-Soutenance-v5-projection.pdf` (les mêmes sans les notes, pour projeter). Générateur : `build_diapos.py` (`--propre` pour la projection). Version 5 du 28 octobre 2026 (diapositive 9 : chiffres Lighthouse du 28 octobre — 100 en accessibilité, bonnes pratiques et SEO sur 10 pages, 100 en performance médiane, carte à 103 Ko ; version 4 : le back-office no-code livré dans Softr est intégré au récit (diapositives 6, 7 et 10), l'écart « pas de Softr » est supprimé).

| Diapositive | Message à prononcer | Preuve à montrer | Chiffre à citer et source |
| --- | --- | --- | --- |
| 1 — Besoin et périmètre | « QRamen démontre la commande à table par QR code pour un restaurant fictif de ramen à Rouen, de la carte au suivi cuisine. » | Site en ligne et architecture de `TECHNIQUE.md` | Trois parcours : client, gérant, cuisine |
| 2 — Offre et données | « Le catalogue est structuré et ses limites visuelles sont assumées. » | Carte et catégories | 40 produits, six catégories, 40 visuels de plats (illustrations générées) : état fourni à 22 h ; douze tables dans les fixtures |
| 3 — Identité et accessibilité | « Les mêmes composants assurent la continuité du parcours en clair et sombre. » | Captures menu mobile clair/sombre et `DESIGN-SYSTEM.md` | Deux thèmes : `tokens.css` et preuves navigateur |
| 4 — Commande client | « Le panier conserve produits, quantités et table ; la validation envoie la commande à n8n puis Airtable. » | `/menu?t=T07` → `/panier` → `/confirmation` ; capture de secours | Quantité 2 exercée dans la recette locale initiale ; essai distant décrit dans `RAPPORT-FRONT-N8N.md` |
| 5 — Fiabilité et ticket | « Une clé réutilisée évite de recréer la commande en revalidation ; le serveur génère le ticket cuisine. » | Clé, ID Airtable et présence du ticket, rapport front n8n | Une seule commande après revalidation dans le test initial ; commande et ticket idempotents, sans preuve de concurrence transactionnelle |
| 6 — Gérant et cuisine | « La cuisine lit les commandes partagées et transmet les statuts ; le gérant a son back-office no-code dans Softr, branché sur la même base, et l'import de carte dans le panel. » | `/panel`, `/cuisine`, `qramen.softr.app` (commandes, carte, avis) | Trois statuts : `recue`, `en-cuisine`, `servie` ; quatre pages Softr, trois blocs de données |
| 7 — Architecture et IA | « Astro sert le site, Airtable stocke les données et n8n orchestre ; l’IA propose une carte et des descriptions que le gérant corrige avant création. » | Schéma technique, `RAPPORT-IMPORT-AIRTABLE.md`, `RAPPORT-COMPARAISON-MODELES.md` | Treize workflows actifs ; import 15 Mo maximum, lots de 30 produits ; import mesuré à 3,7 s, trois modèles comparés |
| 8 — Sécurité livrée | « L’accès du personnel est protégé ; une seconde clé serveur protège les traitements n8n. Le client peut commander sans compte. » | Worker et tableau des routes dans `TECHNIQUE.md`, sans afficher de secret | Deux webhooks publics et huit administratifs ; 401 côté Worker, 403 côté n8n sans clé |
| 9 — Recette et preuves | « Les scripts, résultats et captures attestent des cas précis ; ils ne constituent pas un audit complet. » | `RECETTE.md`, `RAPPORT-LIGHTHOUSE.md`, rapports front n8n, import et sécurité | 28 audits parcours initiaux : sept pages × deux thèmes × deux largeurs ; 32 vues historiques du Worker : huit pages × deux thèmes × deux largeurs ; Lighthouse du 26 octobre sur `qramen.fr` : accessibilité, bonnes pratiques et SEO à 100 sur les trois pages publiques, performance 95 à 100 |
| 10 — Bilan et limites | « Les quatre parcours sont raccordés et le domaine est en service ; l’écart Make → n8n est assumé ; la couverture visuelle est complète, mais ce sont des illustrations. » | `ECARTS-FICHE.md`, limites techniques et recette | Dix pages Astro, quatre parcours (client, gérant, cuisine, salle) ; 40 visuels de plats, tous générés ; e-mails fonctionnels |

Préparer une commande sur le navigateur de démonstration avant de montrer cuisine et avis ; la cuisine utilise un accès authentifié. Garder les captures locales en secours. Le repli réseau est indiqué par « Mode démo locale » : ne pas le présenter comme une écriture Airtable réussie. Les pages publiques de confirmation et d’avis affichent la commande mémorisée sur l’appareil, sans ouvrir l’administration.

Ne pas annoncer de quota commercial actuel, coût mesuré, volume d’exécution, délai de ticket, taux de disponibilité ou e-mail reçu sans preuve. Les contrôles historiques ne sont pas rejoués en production par la mise à jour documentaire. Seuls les scores Lighthouse du 26 octobre consignés dans `RAPPORT-LIGHTHOUSE.md` peuvent être cités : ils portent sur trois pages publiques, un poste et un réseau, pas sur une mesure d’usage réel.

## Automatisations réellement utilisées

**Make est remplacé par n8n auto-hébergé.** C’est un écart assumé par rapport à la fiche validée, pour éviter le plafond de crédits Make ; le VPS conserve ses coûts et limites de ressources. Les justifications, preuves chiffrées et impacts figurent dans [ECARTS-ASSUMES.md](ECARTS-ASSUMES.md). Les définitions et scripts sont versionnés dans **`outils/n8n/`**. Les **treize workflows actifs** correspondent à :

- Publics : `commande`, `avis` (POST).
- Administratifs : `commandes`, `statut`, `rupture`, `ticket`, `confirmation`, `produits`, `importer-carte` (POST) et `catalogue` (GET).

Le chemin actuel est `/webhook/qramen-soutenance/<action>` ; les anciens chemins `tableqr/*` des notices sont historiques. Les appels admin du navigateur passent par `/api/admin/<action>` sur Pages.

L’import suit **photo JPEG/PNG/WEBP ou PDF, 15 Mo maximum → n8n → Gemini (`gemini-flash-lite-latest`) → prévisualisation éditable → validation → webhook `produits` → Airtable par lots de 30**. Les catégories sont liées ; une catégorie inconnue est signalée dans la réponse. La qualité de lecture dépend du document, d’où la validation humaine. **Écart local :** le validateur de ce dépôt accepte JPEG/PNG/PDF mais refuse encore WEBP ; le support WEBP de production est fourni, pas testé ici.

Le service local **`tableqr-pdf`**, **fpdf2**, **Liberation Sans**, port **8798** (`172.19.0.1:8798`), utilise une clé dédiée. Le workflow commande déclenche le ticket côté serveur, puis le PDF est joint dans **`commandes.ticket`**, avec idempotence. Il remplace CraftMyPDF/PDF.co ; le client public n’a pas besoin d’appeler le webhook admin `ticket`.

Les e-mails **fonctionnent** depuis un test réel du 26 octobre 2026 à 22 h 32 : LWS refusait l’authentification depuis l’IP du VPS, la chaîne est passée chez **Amen** (`smtp-fr.securemail.pro`, port 465, compte `contact@qramen.fr`) et l’envoi a réussi. Le domaine `qramen.fr` est acheté et en service. Cela concerne les confirmations et les alertes ; « workflow actif » ne signifie pas « e-mail reçu », la preuve est l’envoi de test conservé.

## Sécurité à expliquer sans jargon

Le client scanne le QR code et commande sans compte : c’est le parcours voulu. Les webhooks `commande` et `avis` restent donc ouverts par conception. Leurs URL sont visibles ; les risques d’abus restent une limite assumée.

Les outils du personnel ont deux protections. D’abord, le Worker Cloudflare demande un identifiant et un mot de passe sur `/panel`, `/cuisine` et `/api/admin/*` (Basic Auth sur HTTPS, SHA-256 et comparaison des empreintes à temps constant). Il refuse l’accès sans justificatifs valides (**401**). Les réponses protégées demandent aux moteurs de ne pas indexer (`X-Robots-Tag: noindex, nofollow`) et aux caches de ne pas conserver (`Cache-Control: no-store`).

Ensuite, le proxy du même Worker ajoute **`X-Gerant-Key` depuis la variable Cloudflare `GERANT_KEY`**, uniquement côté serveur : le secret n’apparaît jamais dans le navigateur. n8n refuse les huit webhooks admin sans cette clé (**403**), même en accès direct. Le Worker répond **503** si la variable manque.

Ce mécanisme n’utilise aucun cookie et ne collecte aucune donnée personnelle nominative. Il emploie un compte partagé, sans séparation de rôles ni suivi individuel. Les données d’avis (prénom, commentaire, e-mail facultatif) sont un traitement distinct ; aucune conformité RGPD globale n’est revendiquée. Les secrets Airtable et PDF restent aussi côté serveur, hors dépôt.

**Softr est livré, mais pas à la place prévue par la fiche.** La fiche validée demande Softr pour les interfaces gérant et cuisine ; le parcours client et les écrans terrain (`/panel`, `/cuisine`) sont finalement en Astro statique, sur la même pile que le site, avec le Worker Cloudflare pour la sécurité. Le back-office du gérant, lui, est bien construit dans Softr : quatre pages (`Accueil`, `Commandes`, `Carte`, `Avis`) à `qramen.softr.app`, trois blocs branchés sur la même base Airtable. Deux limites du plan gratuit sont à énoncer : les groupes d'utilisateurs personnalisés (rôles) sont payants, et les blocs créés par l'API sont des blocs de code, pas des blocs standard posés à la souris. Voir [ECARTS-ASSUMES.md](ECARTS-ASSUMES.md) et [SOFTR-APP.md](SOFTR-APP.md). Un serveur Astro local ne met pas en œuvre la protection Worker : la démonstration des accès doit utiliser Pages ou Wrangler.

## Sept questions probables du jury

1. **Pourquoi Astro et pourquoi n8n plutôt que Make ?** Astro sert un site statique avec des interactions TypeScript et un catalogue compilé depuis Airtable, avec repli fixtures. Les traitements partagés passent par n8n auto-hébergé et Airtable ; le Worker protège l’administration. n8n remplace Make dans un écart assumé à la fiche validée : dix workflows actifs versionnés, sans plafond de crédits Make, avec les coûts et limites du VPS à gérer.
2. **La cuisine reçoit-elle les commandes d’un téléphone client ?** Oui : la commande publique passe par n8n et est écrite dans Airtable ; la cuisine authentifiée relit les commandes via le proxy et peut transmettre les statuts. Un essai conservé dans `RAPPORT-FRONT-N8N.md` atteste une création et une relecture. En panne réseau, le mode démo local est signalé et ne prouve pas une transmission ; aucun temps réel garanti n’est revendiqué.
3. **Airtable et l’import IA sont-ils vraiment raccordés ?** Oui : lecture de carte par synchronisation avant build, lecture administrative GET `catalogue`, et écritures métier via n8n. L’import analyse un document avec Gemini, puis le gérant corrige et valide les produits envoyés par lots de 30, avec liens catégories et signalement des catégories inconnues. Le rapport import Airtable atteste des créations et prix relus. Le formulaire courant de nom/prix reste local ; WEBP est annoncé en production mais encore refusé par le validateur local.
4. **Où sont les secrets et les droits d’accès ?** Basic Auth protège les pages du personnel et le proxy ; celui-ci injecte `X-Gerant-Key` depuis `GERANT_KEY` côté serveur. n8n répond 403 sans cette clé ; elle ne figure jamais dans le navigateur. Le mécanisme ne crée ni cookie ni collecte nominative. C’est un compte partagé, sans rôles distincts. Commande et avis restent publics pour le parcours QR sans compte.
5. **L’idempotence empêche-t-elle tous les doublons ?** La commande réutilise sa clé et le workflow est idempotent ; le ticket vérifie s’il est déjà joint dans `commandes.ticket`. Le test local atteste une revalidation séquentielle, pas une garantie transactionnelle pour des requêtes simultanées. L’import de produits n’est pas idempotent : après un délai réseau, vérifier Airtable avant de réessayer.
6. **Qu’est-ce qui fonctionne et qu’est-ce qui reste à faire ?** Le site est en ligne sur `qramen.fr`, les mutations métier sont raccordées, dix workflows sont actifs, le ticket est généré côté serveur et l’import est éditable avant écriture. Le back-office du gérant est livré en no-code dans Softr. Les scripts, JSON et captures prouvent les cas délimités dans `RECETTE.md`. Les e-mails fonctionnent depuis l’envoi de test du 26 octobre 2026 à 22 h 32 via Amen (`contact@qramen.fr`), après le refus initial de LWS ; les 40 visuels de plats sont des illustrations générées, les webhooks client restent ouverts ; l’écart Make → n8n et l’usage partiel de Softr sont documentés et assumés. Les tests ne couvrent pas tous les navigateurs, tous les cas négatifs, la charge ou un audit sécurité complet ; aucun paiement en ligne.

7. **Softr, alors : livré ou abandonné ?** Livré, pour le back-office du gérant : `qramen.softr.app`, quatre pages, trois blocs de données branchés sur la même base Airtable, connexion obligatoire. Ce n'est pas l'usage prévu par la fiche (Softr y couvrait gérant **et** cuisine) : les écrans terrain restent en Astro, parce qu'ils ont besoin du panier, de la prise de commande et d'un rendu mobile rapide, et parce que le plan gratuit de Softr limite les applications et interdit les groupes d'utilisateurs personnalisés — donc pas de séparation des rôles. C'est un écart partiel, documenté et assumé.