# Wakdo — Project Context

**Source de verite du projet.** Ce document est injecte comme contexte dans tous les agents BYAN utilises pour ce projet (expert-merise-agile, architect, dev, ux-designer, tea, quinn, etc.). Il doit etre mis a jour des qu'une decision structurante change.

---

## 1. Identite projet

| Champ | Valeur |
|---|---|
| Nom du projet | **Wakdo** — borne de commande fictive (pastiche McDonald's) |
| Auteur | Corentin |
| Cadre | Epreuve RNCP 37805 — Titre Developpeur Web, B2, option **DevOps** |
| Centre | Acadenice |
| Contexte pro | Alternance en tant qu'admin sys + etudiant B2 DevOps |
| Deadline soutenance | **Septembre 2026** |
| Budget heures | 10-15 h/semaine — cible ~240 h effectives |
| Mode de travail | Solo |
| Date de creation du doc | 2026-04-23 |

---

## 2. Contexte metier

Wakdo est une **borne de commande tactile** pour un restaurant de restauration rapide. L'utilisateur final (client) compose sa commande sur ecran tactile, valide, recupere un numero, puis retire son produit au comptoir.

### Acteurs

| Acteur | Role | Interface |
|---|---|---|
| **Client** | Passe sa commande sur la borne | Borne tactile (Bloc 1) |
| **Accueil** | Saisit commandes au **comptoir** (client au guichet) ou au **drive** (client en voiture via intercom + casque equipier), remet les commandes livrees aux clients | Back-office (Bloc 2) |
| **Preparation** | Voit les commandes a preparer triees par heure croissante, les declare "preparees" | Back-office (Bloc 2) |
| **Administration** | CRUD sur donnees (produits, menus, prix, images) + gestion utilisateurs + stats | Back-office (Bloc 2) |

### Processus metier cle

```
Client                Borne (Bloc 1)           API (Bloc 2)          BDD
  │                       │                       │                    │
  │─compose panier──────▶│                       │                    │
  │                       │─GET menus,produits───▶│───SELECT──────────▶│
  │                       │◀──────────JSON────────│◀───────────────────│
  │─valide────────────────│                       │                    │
  │─saisit numero─────────│                       │                    │
  │                       │─POST /api/orders─────▶│───INSERT──────────▶│
  │                       │◀──────────201─────────│                    │
  │─recupere au comptoir  │                       │                    │
                          Preparation voit commande pending
                          → declare "preparee"
                          Accueil voit commande prete
                          → declare "livree"
```

### Regles metier (MCT - a modeliser en Merise)

- Un **menu** = burger + accompagnement (frites OU salade) + boisson + sauce
- Les **accompagnements** et **boissons** ont **2 tailles** (normale / grande)
- **Grande taille** = +0,50 € sur le prix de base
- Une **commande** a un **numero** saisi par le client (remplace le paiement dans le cadre de l'exam)
- Statuts commande : `pending` -> `preparing` -> `ready` -> `delivered` (ou `cancelled`)
- **Source commande** (trace sur chaque commande) : `kiosk` (borne autonome) | `counter` (comptoir) | `drive` (drive-thru)
- La preparation voit les commandes triees par **heure de livraison croissante** (tous canaux confondus)
- **Horaires service** : 10h00 → 01h00 du matin (service continu 15h, pas de fermeture intermediaire)
- **Pas de notion de "session de service" a modeliser** : les equipiers se relaient, chacun se connecte a sa prise de poste et se deconnecte a la fin. Pas de "shift" a tracer dans la BDD (hors scope RNCP)
- **Fenetre de maintenance systeme** : 01h30 → 09h30 (crons lourds, backups, agregations) — evite toute interference avec le service actif
- **Notion de "jour de service"** (important pour les stats et l'agregation) :
  - Un jour de service J = toutes les commandes creees entre **J 10h00** et **J+1 01h00**
  - Exemple : la soiree du 22/04 = commandes `22/04 10:00 → 23/04 01:00`, regroupees sous `service_day = 2026-04-22`
  - Une commande creee a 23h55 le 22/04 et livree a 00h30 le 23/04 appartient au meme jour de service (22/04)
  - **Implementation** : colonne `service_day` calculee sur la table `orders`, ou vue SQL :
    ```sql
    service_day = CASE
      WHEN HOUR(created_at) < 10 THEN DATE(created_at - INTERVAL 1 DAY)
      ELSE DATE(created_at)
    END
    ```
  - Les requetes de stats (CA jour, produits top, etc.) utilisent `service_day` et non `DATE(created_at)` brut

---

## 3. Contexte academique — RNCP 37805

**Referentiel** : [certifpro.francecompetences.fr](https://certifpro.francecompetences.fr/api/fiches/refActivity/24345/472313)

### Blocs couverts

| Bloc | Nom | Statut | Activites |
|---|---|---|---|
| **Bloc 1** | Developpement Front-End | Tronc commun obligatoire | A1 (integration), A2 (fonctionnalites JS) |
| **Bloc 2** | Developpement Back-End | Tronc commun obligatoire | A3 (data/BDD), A4 (back-end) |
| **Bloc 5** | DevOps (option 3) | Option choisie | A7 (automatisation + conteneurisation + CI/CD) |

### Validation

- **50 % minimum par bloc** pour le valider
- **50 % moyenne globale** pour valider le titre
- **Stage** = 20 % de la note finale (couvert par l'alternance)
- **Controle continu** 30 % + **Examens jurys** 50 %

---

## 4. Strategie de projet

### Strategie B — unifiee

**Un seul codebase, deux FQDN d'exposition publique.** Le front Bloc 1 et le back Bloc 2 coexistent dans la meme arborescence. Une bascule mode JSON-seuls (Bloc 1 isole) vs mode API-connecte doit rester possible via configuration.

**Pourquoi pas strategie A (deux rendus isoles)** : le Bloc 5 DevOps impose une conteneurisation **unique** qui lance la stack complete avec `make init` en une commande (Cr 7.c.4). Deux codebases isolees seraient incoherentes avec cette exigence.

### Compatibilite evaluation par bloc

- **Jury Bloc 1** : voit le front seul ; le front peut tomber en fallback sur JSON statiques fournis (`src/public/borne/data/*.json`) si l'API est indisponible.
- **Jury Bloc 2** : voit le back-office + teste l'API via curl/Postman de maniere autonome, sans dependre du front.
- **Jury Bloc 5** : lance `make init` ou `docker compose up`, verifie la CI/CD, les crons, l'archi, les scripts.

---

## 5. Architecture

### 2 FQDN exposes

| FQDN | Role | Bloc | Auth |
|---|---|---|---|
| `corentin-wakdo.acadenice.fr` | Borne client (kiosk tactile) | Bloc 1 | Public |
| `corentin-wakdo-admin.acadenice.fr` | Back-office + API REST (sous `/api/*`) | Bloc 2 | Sessions (back-office) + tokens (API ecriture) |

**CORS** : la borne (`corentin-wakdo.acadenice.fr`) consomme l'API (`corentin-wakdo-admin.acadenice.fr/api/*`). Headers CORS explicites avec origine precise (pas de wildcard `*`), argumentable comme durcissement securite face au jury.

### Services Docker

```
┌─────────────────────────────────────────────────────────────────┐
│                       Traefik (existant)                         │
│                    (admin_proxy network)                         │
└──────────┬────────────────────────────┬─────────────────────────┘
           │                            │
   wakdo.acadenice.fr      wakdo-admin.acadenice.fr
           │                            │
           ▼                            ▼
    ┌──────────────────────────────────────────┐
    │       wakdo-web (Apache Alpine)           │
    │   Front controller + reverse vers FPM     │
    └──────────┬───────────────────────────────┘
               │ FastCGI :9000
               ▼
    ┌──────────────────────────────────────────┐
    │      wakdo-app (PHP 8.3-fpm Alpine)       │
    │   POO MVC — borne.php, admin.php, api.php │
    └──────────┬───────────────────────────────┘
               │ PDO MySQL
               ▼
    ┌──────────────────────────────────────────┐
    │          wakdo-db (MariaDB 11)            │
    │            volume persistant              │
    └──────────────────────────────────────────┘

    ┌──────────────────────────────────────────┐
    │       wakdo-cron (Alpine + PHP CLI)       │
    │  crond — backup BDD, purge sessions, ...  │
    └──────────────────────────────────────────┘
```

Reseaux :
- `admin_proxy` (external) — expose `wakdo-web` a Traefik
- `wakdo_internal` (bridge, interne) — isole `wakdo-app`, `wakdo-db`, `wakdo-cron`

---

## 6. Stack technique lockee

| Couche | Choix | Version | Raison |
|---|---|---|---|
| Front langages | HTML5 + CSS3 + JavaScript | Standards 2024+ | Exigence Bloc 1 (vanilla) |
| Front framework | **Aucun** | — | Sujet Bloc 1 impose |
| Front dep JS | **Aucune** | — | Exigence explicite |
| Back langage | PHP | **8.3** LTS | Moderne, support jusqu'a 2027 |
| Back framework | **Aucun** | — | Sujet Bloc 2 "from scratch" |
| Autoloader | **Manuel** (spl_autoload_register, PSR-4) | — | Defend "from scratch", Cr 4.c.3 compatible |
| Tests | **PHPUnit** via `.phar` autonome | 11.x | Cr 4.g.2 sans Composer |
| Composer | **Non utilise** | — | Colle au "from scratch" |
| BDD | MariaDB | **11** LTS | Compatible MySQL, LTS 2028 |
| Driver BDD | PDO (prepared statements uniquement) | natif PHP | Cr 4.e.1 anti-injection |
| Serveur web | Apache httpd | Alpine latest | Reverse proxy vers PHP-FPM |
| Serveur app | PHP-FPM | 8.3-fpm-alpine | Contenairisation propre |
| Reverse proxy | Traefik (deja en place) | existant | `admin_proxy` network |
| TLS | Let's Encrypt via Traefik | auto | `acme.json` existant |
| Conteneurisation | Docker + docker compose | v2 | Cr 7.c |
| Orchestration locale | Makefile | — | Cr 7.b (script) + Cr 7.c.4 (une commande) |
| CI/CD | GitHub Actions | — | Cr 7.d |
| Versioning | Git + GitHub | — | Cr 4.f (collaboration) |
| Hooks Git | pre-commit + commit-msg | versionnes dans `.githooks/` | Conventional Commits |

---

## 7. Scope fonctionnel

### Bloc 1 — Borne client (Front)

**IN scope :**
- Affichage dynamique menus + produits (charges par Ajax depuis API ou JSON fallback)
- Composition panier : produits unitaires OU menus (burger + accompagnement + boisson + sauce)
- Options taille (normale / grande, +0,50 € sur grande) pour accompagnements et boissons
- Options de personnalisation simples (ex : sans oignon, avec fromage)
- Recapitulatif panier (ajout, modification quantite, suppression)
- Validation commande + saisie numero (remplace paiement)
- Envoi POST JSON de la commande vers l'API
- Ecran de confirmation avec numero
- Responsive cible 1920x1080 portrait (borne) **+ adaptatif** autres resolutions
- **Accessibilite RGAA** : police OpenDys pour dyslexiques, navigation clavier, contrastes, alts, pas d'info via couleur seule
- **SEO / semantique** : balises HTML5 (`article`, `aside`, `nav`), schema.org, meta tags uniques, canonical, favicon

**OUT scope :**
- Paiement reel (remplace par numero de commande)
- Authentification client (pas de compte fidelite)
- Multi-langue (FR uniquement)
- Offline mode

### Bloc 2 — Back-office + API (Back)

**IN scope — Back-office :**
- Authentification sessions securisees (hash bcrypt/argon2, protection CSRF, fixation session) — duree de session adaptee a un poste complet d'equipier (idle timeout 4h, absolute timeout 10h)
- 3 roles RBAC : `admin`, `preparation`, `accueil`
- **Admin** : CRUD categories, produits (nom, description, prix, image, dispo), menus (composition + options), utilisateurs
- **Preparation** : liste commandes a preparer triees par heure livraison croissante, bouton "declarer preparee"
- **Accueil** : saisir commande manuellement (comptoir ou drive-thru via casque/intercom), bouton "declarer livree" ; champ `source` enregistre sur chaque commande (`counter` ou `drive`)
- Upload images produits (validation type MIME + taille + stockage dans volume `wakdo_uploads`)
- Historique commandes par statut
- Stats de base (commandes du jour, CA jour, produits top)

**IN scope — API REST :**
- `GET /api/categories` — liste categories produits
- `GET /api/products` — liste produits (filtrable par categorie)
- `GET /api/menus` — liste menus avec compositions et options
- `POST /api/orders` — creer une commande (body JSON, retour `{id, number, status}`)
- `GET /api/orders/{number}` — recuperer statut commande
- Headers CORS explicites pour l'origine borne
- Reponses JSON standardisees : `{data: ..., error: null}` ou `{data: null, error: {code, message}}`

**IN scope — Transverse :**
- Architecture **MVC** stricte (Models / Views / Controllers)
- **Heritage** entre classes (ex : `BaseController` -> `AdminController` -> `ProductController`)
- **Namespaces** + autoloader PSR-4 manuel
- **Anti-injection** : PDO prepared statements exclusivement
- **RGPD** : hash mdp, droit consultation/modif/suppr user, info stockage/utilisation donnees

**OUT scope :**
- Paiement reel, systeme comptable
- Multi-restaurants / multi-bornes
- Fidelite client
- Rapports avances / exports CSV

### Bloc 5 — DevOps

**IN scope :**
- Dockerfile custom PHP-FPM avec extensions
- `docker-compose.yml` orchestrant les 4 services (web, app, db, cron)
- `Makefile` avec cible `make init` qui lance tout en une commande (Cr 7.c.4)
- Scripts Bash d'automatisation (backup, deploy, migrate)
- **Cron tab** avec au moins 3 jobs planifies dans la fenetre de maintenance (01h30-09h30) :
  - `0 3 * * *` — backup BDD quotidien a 03h00 (entre fin service 01h et ouverture 10h)
  - `*/15 * * * *` — purge sessions expirees toutes les 15 min (leger, peut tourner en service)
  - `30 4 * * *` — agregation stats commandes a 04h30 sur le **jour de service** ecoule (10h J-1 → 01h J)
- **CI GitHub Actions** : lint PHP + PHPUnit sur PR -> dev
- **CD GitHub Actions** : deploy auto sur merge main (SSH + pull + `make rebuild`)
- `.env.example` documente, secrets hors du repo
- Healthcheck Traefik + readiness probes
- Logs centralises (stdout des conteneurs)
- Documentation deploiement + architecture (schemas dans `docs/`)

**OUT scope :**
- Kubernetes / Swarm
- Monitoring complet type Prometheus/Grafana (trop chronophage)
- Multi-environnements (pre-prod, staging)
- Blue-green deployment

---

## 8. Criteres RNCP — mapping feature

### Bloc 1

| Critere | Libelle court | Feature Wakdo couvrant |
|---|---|---|
| Cr 1.a.1 | Integration conforme maquette | Integration HTML/CSS fidele au prototype |
| Cr 1.a.2 | Normes W3C + accessibilite | Validator W3C vert + RGAA |
| Cr 1.a.3 | Tests validator passent | Test en soutenance via W3C validator |
| Cr 1.a.4 | Code commente, indente | Conventions de code appliquees partout |
| Cr 1.a.5 | Balises semantiques | `<article>`, `<aside>`, `<nav>`, `<header>`, `<main>`, `<section>` |
| Cr 1.b.1-3 | Responsive + multi-navigateurs | Media queries + @supports + tests Chrome/FF/Safari |
| Cr 1.c.1-4 | Accessibilite RGAA/OpenDys | alt, aria-label, navigation clavier, police OpenDys, pas d'info via couleur seule |
| Cr 1.d.1-4 | Classes CSS reutilisables | Convention BEM ou similaire, regroupe par theme, sans repetition |
| Cr 1.e.1-11 | SEO + meta + semantique | hierarchie titres, schema.org, canonical, alt images, favicon, temps chargement |
| Cr 2.a.1-5 | JS ES6+ + DOM + animations | Modules ES6, classes, async/await, pas de jQuery |
| Cr 2.b.1-3 | Validation formulaires | Validation client temps reel (regex) + validation serveur |
| Cr 2.c.1-4 | Ajax async | `fetch()` avec gestion erreurs, pas d'exposition donnees sensibles |
| Cr 2.d.1-3 | Librairies externes | **Non applicable** (zero dep JS) — argumenter "developpement sans lib externe" |

### Bloc 2

| Critere | Libelle court | Feature Wakdo couvrant |
|---|---|---|
| Cr 3.a.1-4 | Analyse + modele donnees | Dictionnaire + MCD + cardinalites |
| Cr 3.a.3 | Exploiter donnees externes d'API | API interne consommee par le front (auto-consommation) |
| Cr 3.b.1-3 | Construction BDD | MCD → MLD → DDL MariaDB, FK + typage coherent |
| Cr 3.c.1-3 | Requetes SQL optimisees | PDO prepared, index sur FK, LIMIT/tri explicites |
| Cr 3.d.1-4 | RGPD | hash mdp, droit acces/modif/suppr, info utilisation donnees |
| Cr 4.a.1-4 | Conceptualisation | Schema fonctionnel des vues + interactions |
| Cr 4.b.1-6 | Syntaxe + indentation + erreurs | PSR-12 style, try/catch cibles, logs |
| Cr 4.c.1-3 | POO + heritage + namespaces | `BaseModel` -> `Product`, `BaseController` -> `AdminController`, PSR-4 |
| Cr 4.d.1-3 | MVC | `src/Models/`, `src/Views/`, `src/Controllers/`, separation stricte |
| Cr 4.e.1-3 | Securite | PDO prepared (anti-SQLi), sessions regeneration, role-based middleware |
| Cr 4.f.1-4 | Git + collaboration | Commits Conventional, branches feat/*, PR descriptions, squash merge |
| Cr 4.g.1-4 | Preparation livraison | PHPUnit tests verts, pas d'erreur en prod, testee deployee |

### Bloc 5

| Critere | Libelle court | Feature Wakdo couvrant |
|---|---|---|
| Cr 7.a.1-3 | Analyse infra + securite | Audit code + proposition automatisation documentee |
| Cr 7.b.1 | Langage de script | Bash (deploy, backup) + Makefile |
| Cr 7.b.2 | Automatisation fiabilisee | Makefile avec exit codes, retries, logs |
| Cr 7.b.3 | **Cron tab** | `wakdo-cron` service avec crontab : backup BDD, purge sessions, stats |
| Cr 7.c.1 | VM operationnelle | Serveur existant Acadenice |
| Cr 7.c.2 | OS conteneur installe | Docker Engine |
| Cr 7.c.3 | App conteneurisee complete | 4 services (web, app, db, cron) |
| Cr 7.c.4 | **Une ligne de commande** | `make init` lance toute la stack + migrate + seed |
| Cr 7.d.1 | Architecture serveur | Traefik reverse + reseaux segmentes documentes |
| Cr 7.d.2 | Tests avant deploy | CI PHPUnit + lint sur PR |
| Cr 7.d.3 | Integration/deploiement continus | GitHub Actions deploy automatique sur merge main |

---

## 9. Conventions

### Git

**Branches :**
```
main            ← production (tag vX.Y.Z sur chaque release)
  dev           ← integration
    feat/*      ← nouvelles features
    fix/*       ← corrections
    refactor/*  ← refactos
    docs/*      ← doc seulement
    ci/*        ← GitHub Actions
    db/*        ← migrations / schema BDD
    chore/*     ← tooling, config
    test/*      ← ajout de tests
```

Les branches `main` et `dev` sont **protegees** cote GitHub. Pas de commit direct autorise. Hook pre-commit local les bloque egalement.

**Flow :**
1. `git checkout -b feat/menu-composition` (depuis `dev`)
2. Commits atomiques Conventional Commits
3. Push + PR vers `dev`
4. Merge squash
5. Periodiquement `dev` -> `main` via PR avec tag semver

**Commits** — Conventional Commits, en anglais :

```
<type>(<scope>): <description imperative min 5 chars>

<body optionnel si changement complexe>
```

- **Types** : `feat`, `fix`, `refactor`, `test`, `docs`, `chore`, `ci`, `db`, `perf`, `style`
- **Scopes Wakdo** : `front`, `back`, `api`, `admin`, `auth`, `db`, `docker`, `ci`, `docs`
- **Interdits** : emoji (Mantra IA-23), description en francais, WIP commits
- **Exemples :**
  - `feat(front): add menu composition screen with size options`
  - `fix(api): correct order total calculation with large size`
  - `db: add migration 003 orders with fk to users`
  - `docker: add cron service with daily backup job`
  - `ci: add phpunit workflow on pull_request`

### Code PHP

- **PSR-12** style (indentation 4 espaces, namespaces 1 classe par fichier, `{` sur nouvelle ligne pour classes/methodes)
- **Namespaces** : `App\Controllers`, `App\Models`, `App\Core`, `App\Services`
- **1 classe = 1 fichier**, nom fichier == nom classe (PascalCase)
- **Proprietes typees** (PHP 8.3) : `private int $id`, `private string $name`
- **Retours typees** : `public function find(int $id): ?Product`
- **Commentaires** : pour le **pourquoi** (Mantra IA-24), pas le quoi
- **Docblocks** : sur methodes publiques uniquement, concis

### Code JavaScript

- **Vanilla ES6+** : `const`/`let`, arrow functions, destructuring, modules `import`/`export`
- **Pas de `var`**
- **Modules** : fichiers `.js` avec `export` explicite
- **Async** : `async/await` prefere au chaining `.then()` complexe
- **Event delegation** : sur conteneurs parents plutot que listener par element
- **Aucune lib externe** (pas jQuery, pas Lodash)

### Code CSS

- **BEM** naming : `.block__element--modifier`
- **Variables CSS** dans `:root` (palette couleurs, spacings, fonts)
- **Mobile-first** : `min-width` media queries
- **1 fichier par composant** dans `src/public/assets/css/components/`, assemble via `@import` ou concat build

### BDD

- **Tables** : `snake_case`, pluriel (`products`, `orders`, `order_items`)
- **Colonnes** : `snake_case`
- **PK** : `id` BIGINT UNSIGNED AUTO_INCREMENT
- **FK** : `<table_singulier>_id` (ex : `product_id`, `user_id`)
- **Timestamps** : `created_at`, `updated_at` (DATETIME default CURRENT_TIMESTAMP)
- **Soft delete** : `deleted_at` DATETIME NULL quand applicable
- **Index** systematique sur FK + colonnes de recherche frequente
- **Collation** : `utf8mb4_unicode_ci`

---

## 10. Decisions techniques lockees — recap

| # | Decision | Justification |
|---|---|---|
| 1 | Strategie B unifiee | Cr 7.c.4 impose une stack unique lancable en 1 commande |
| 2 | PHP 8.3 LTS | Moderne, supporte jusqu'en 2027 |
| 3 | Pas de framework PHP | Sujet Bloc 2 "from scratch" explicite |
| 4 | Pas de Composer | Colle au "from scratch", autoloader manuel autorise par Cr 4.c.3 |
| 5 | PHPUnit via .phar | Tests unitaires requis Cr 4.g.2, sans dep Composer |
| 6 | MariaDB 11 LTS | LTS 2028, compatible MySQL |
| 7 | Apache Alpine + PHP-FPM Alpine | Demande utilisateur (admin sys), images legeres |
| 8 | 2 FQDN | Separation claire borne publique / admin+API interne, defensible jury |
| 9 | API sous `/api` sur le FQDN admin | Simplicite d'exploitation, CORS explicite gere |
| 10 | Service cron dedie | Cr 7.b.3 explicite + realiste prod |
| 11 | Makefile avec `make init` | Cr 7.c.4 + demonstration DevOps |
| 12 | Conventional Commits + hooks | Cr 4.f.x + discipline de versioning |
| 13 | Branches feat/* -> dev -> main | Pipeline propre pour jury, GitHub PR trace |
| 14 | CI/CD GitHub Actions | Cr 7.d explicite dans referentiel |
| 15 | RGPD implemente minimal | Cr 3.d.1-4 evaluees meme projet ecole |

---

## 11. Planning — budget heures

| Phase | Scope | Budget (h) | Deadline intermediaire |
|---|---|---|---|
| **P0 - Setup** | PC, arborescence, Docker, hooks, CI squelette, init Git/GitHub | 20 | Semaine 1 |
| **P1 - Conception Merise** | Dictionnaire, MCD, MCT, MLD, schemas fonctionnels, DDL | 30 | Semaine 3 |
| **P2 - Back squelette** | POO base (Core, Router, Autoloader, DB), auth + roles | 30 | Semaine 6 |
| **P3 - Back CRUD admin** | Produits, menus, utilisateurs, views | 40 | Semaine 10 |
| **P4 - API REST** | Endpoints + CORS + tests | 20 | Semaine 12 |
| **P5 - Front borne** | Integration maquette, Ajax, accessibilite, responsive | 60 | Semaine 16 |
| **P6 - Tests + finition** | PHPUnit, tests E2E borne, corrections | 25 | Semaine 18 |
| **P7 - DevOps finalisation** | CI/CD deploy auto, crons, docs argumentation | 20 | Semaine 19 |
| **P8 - Prep soutenance** | README pour jury, schemas finaux, repetitions, modifs en direct | 15 | Semaine 20 |
| **TOTAL** | | **260** | **Semaine 20 = fin aout 2026** |

Buffer : ~20 h pour imprevus. Cible effective : ~240 h sur 20 semaines = **12 h/semaine**.

---

## 12. Livrables

### Par bloc

**Bloc 1 :**
- App front deployee et fonctionnelle sur `https://corentin-wakdo.acadenice.fr`
- Code source Git accessible au jury
- Validator W3C screenshot (HTML + CSS verts)
- Checklist RGAA auto-evaluee

**Bloc 2 :**
- **Dictionnaire de donnees** (`docs/merise/dictionary.md`)
- **MCD** schema (`docs/merise/mcd.md` + image)
- **MCT** schemas (`docs/merise/mct.md` + diagrammes)
- **MLD** (`docs/merise/mld.md`)
- **Schema fonctionnel** de l'app (`docs/architecture/functional-schema.md`)
- **BDD** deployee (dump SQL dans `db/migrations/` + script init)
- App back-office deployee sur `https://corentin-wakdo-admin.acadenice.fr`
- Documentation API (OpenAPI minimal ou README API)

**Bloc 5 :**
- `docker-compose.yml` commente
- Dockerfiles customs commentes
- `Makefile` avec `make help`
- `.github/workflows/` avec CI + CD
- Crontab documente
- Script de backup/restore teste
- Architecture serveur decrite (`docs/architecture/deployment.md`)

### Pour la soutenance (tous blocs)

- **README.md** synthetique (quick start + liens docs)
- **Presentation** (slides ou live) argumentant les choix
- **Demo** live : borne + back-office + API (Postman/curl) + `make init`
- **Capacite modification en direct** (Cr 4.a.1) : code structure pour permettre modifs sans casser

---

## 13. Risques et mitigations

| Risque | Probabilite | Impact | Mitigation |
|---|---|---|---|
| Sous-estimation temps front (accessibilite RGAA stricte) | Haute | Moyen | 60 h budgetees + tests W3C/axe-core pendant le dev, pas a la fin |
| Complexite MCT (statuts commande) mal modelisee | Moyenne | Fort | Valider MCT avec un pair ou prof avant d'implementer Bloc 2 |
| Dockerfile PHP extensions manquantes decouvert tard | Moyenne | Faible | Tester `make up` + un vrai appel BDD des P0 |
| Conflit reseau Docker `wakdo_internal` existant | Faible | Faible | Verifie au setup, fallback nom `wakdo_backend` |
| CORS mal configure bloque la borne | Moyenne | Moyen | Test immediat apres setup 2 FQDN |
| Performance borne sur ecran tactile reel | Faible | Fort | Optimiser images + lazy loading + tests sur device tactile si possible |
| Scope creep (ajout fonctionnalites non RNCP) | Haute | Fort | Sticker le scope, OUT scope documente ici, refuser les ajouts |
| Gestion secrets (`.env`) leaked sur Git | Faible | Tres fort | `.env` liste dans `.gitignore` des P0, pre-commit hook check secrets futur |

---

## 14. Glossaire metier (fast-food)

| Terme | Definition |
|---|---|
| **Menu** | Combinaison burger + accompagnement + boisson + sauce |
| **Combo** | Synonyme menu (terme marketing US) |
| **Borne** | Ecran tactile autonome dans le restaurant, le client compose lui-meme (canal `kiosk`) |
| **Comptoir** | Guichet physique, equipier saisit la commande pour le client (canal `counter`) |
| **Drive** | Piste drive-thru : client en voiture, borne intercom + haut-parleur, equipier avec casque + tablette saisit la commande (canal `drive`) |
| **Jour de service** | Periode d'activite 10h J -> 01h J+1 (15h continu), unite d'agregation pour toutes les stats commerciales |
| **Fenetre de maintenance** | Periode 01h30 -> 09h30 reservee aux taches systeme (backups, stats, purges) |
| **Accompagnement** | Frite, salade, potatoes — option avec taille |
| **Supplement** | Ajout optionnel sur un produit (fromage, bacon) — peut impacter prix |
| **Option** | Retrait ou modif produit (sans oignon, sans sauce) — neutre prix |
| **Panier** | Liste des produits/menus selectionnes par le client avant validation |
| **Commande** | Panier valide, dote d'un numero, en attente de preparation |
| **Preparation** | Etat "en cuisine" |
| **Livraison** | Remise au client au comptoir |
| **Ticket** | Numero de commande (remplace paiement dans l'exam) |

## 15. Glossaire technique

| Terme | Definition |
|---|---|
| **Borne** | Interface tactile publique pour client final (Bloc 1) |
| **Back-office** | Interface interne pour employes (Bloc 2) |
| **API interne** | API consommee par la borne, non publique a tiers |
| **PSR-4** | Standard PHP d'autoloading classes par namespace |
| **PDO** | Abstraction BDD PHP avec prepared statements (anti-SQLi) |
| **BEM** | Convention naming CSS Block__Element--Modifier |
| **RGAA** | Referentiel General d'Amelioration de l'Accessibilite (France) |
| **OpenDys** | Police de caractere pour personnes dyslexiques |

---

## 16. Points d'attention jury (prep argumentation)

Le jury Bloc 2 demande **capacite a modifier le code en direct** (Cr 4.a.1). Il faut donc :

- **Connaitre son code** : pouvoir expliquer chaque fichier et la raison de sa presence
- **Argumenter les choix** : pas Laravel ? pourquoi pas. POO + heritage ? demontrer l'arbre. MVC ? montrer qu'une route traverse un controller puis un model puis une vue
- **Justifier l'archi Docker** : pourquoi 4 services, pourquoi Alpine, pourquoi Traefik
- **Comprendre la BDD** : defendre les cardinalites, les contraintes, les index
- **Expliquer les choix securite** : PDO prepared, bcrypt, CSRF, sessions, CORS
- **Avoir un plan B** : savoir repondre "si le jury vous demande d'ajouter X, par ou commencer"

Preparer des **questions frequentes** :
- "Pourquoi pas Laravel/Symfony ?" → Sujet impose from scratch + demo maitrise des fondamentaux
- "Pourquoi pas Composer ?" → Criteres Cr 4.c.3 autorise manuel, plus defendable "from scratch"
- "Comment gerez-vous l'injection SQL ?" → PDO prepared statements exclusivement, montrer exemple dans Models
- "Votre API ne gere pas X role" → Fallback : middleware RBAC par role, montrer code
- "Comment deploieriez-vous en prod vrai ?" → Ajouter monitoring, blue-green, IaC, secrets manager

---

## 17. Regles invariantes

Ces regles tiennent lieu de garde-fous pendant toute la duree du projet. Les enfreindre demande une mise a jour explicite de ce document.

1. **Zero emoji** dans code, commits, docs techniques (Mantra IA-23)
2. **Zero Composer, zero vendor/** dans le repo
3. **Zero dep JS front** (pas jQuery, pas Bootstrap)
4. **Zero secret en clair dans Git** (`.env` liste dans `.gitignore`)
5. **Zero commit direct sur `main` ou `dev`** (hook bloque)
6. **Zero requete SQL sans prepared statement** (anti-SQLi)
7. **Zero hash mdp en clair** (bcrypt ou argon2)
8. **Zero CORS `*`** (origine explicite uniquement)
9. **Zero deployment manuel** en condition normale (CI/CD)
10. **Zero feature hors scope** sans mise a jour de ce document

---

*Document vivant — version 1.0 — 2026-04-23. A mettre a jour a chaque decision structurante.*