Ajoute la doc de soutenance, corrige Vercel->Netlify, bouton stats

- docs/DEFENSE_QA.md : reponses courtes aux questions techniques
probables pour la soutenance
- README/API/WORKFLOW : wording corrige (frontend heberge sur
Netlify, pas Vercel)
- web/index.html : bouton de navigation vers stats.html

README.md

@@ -37,7 +37,7 @@ yely_ai_module/
 │   └── crnn_fuel_pump_best.pt   # modèle sérialisé (livrable)
 ├── train/                # scripts d'entraînement (reproductibilité)
 ├── tests/                # tests unitaires (postprocess, règles)
-├── web/                  # interface web de démo (déploiement Vercel)
+├── web/                  # interface web de démo (déploiement Netlify)
 ├── docs/                 # documentation par module + limites identifiées
 ├── Dockerfile            # déploiement Hugging Face Spaces
 └── requirements.txt
@@ -115,5 +115,5 @@ limitant est la diversité du jeu de données, pas les hyperparamètres.
 
 ## Déploiement
 
-Voir `docs/WORKFLOW.md` §6 : frontend (`web/`) sur Vercel, API sur
+Voir `docs/WORKFLOW.md` §6 : frontend (`web/`) sur Netlify, API sur
 Hugging Face Spaces (ce dépôt, via le `Dockerfile` à la racine).

app/main.py

@@ -57,10 +57,10 @@ logger.addHandler(_file_handler)
 
 app = FastAPI(title="YELY — Module IA pompiste (CRNN)")
 
-# Le frontend (Vercel) et l'API (Hugging Face Spaces) sont sur des domaines
+# Le frontend (Netlify) et l'API (Hugging Face Spaces) sont sur des domaines
 # différents : sans CORS, le navigateur bloquerait la lecture de la réponse
 # même si la requête aboutit côté serveur. ALLOWED_ORIGINS est une liste
-# d'origines séparées par des virgules (ex. "https://yely-demo.vercel.app").
+# d'origines séparées par des virgules (ex. "https://yely-demo.netlify.app").
 _allowed_origins = os.environ.get("ALLOWED_ORIGINS", "*")
 
 app.add_middleware(

docs/API.md

@@ -42,9 +42,9 @@ chaque rechargement de code redémarre le worker et donc le modèle.
 
 `ALLOWED_ORIGINS` (variable d'environnement, origines séparées par des
 virgules) contrôle quels domaines peuvent appeler l'API depuis un
-navigateur — nécessaire car le frontend (Vercel) et l'API (Hugging Face
+navigateur — nécessaire car le frontend (Netlify) et l'API (Hugging Face
 Spaces) sont sur des domaines différents. Par défaut `"*"` (permissif,
-adapté à une démo) ; à restreindre au domaine Vercel réel en production.
+adapté à une démo) ; à restreindre au domaine Netlify réel en production.
 
 ## Journalisation
 

docs/DEFENSE_QA.md

@@ -0,0 +1,88 @@
+# Questions techniques probables, reponses courtes (soutenance)
+
+Aide-memoire pour repondre vite en jury. Chaque reponse tient en 2-3 phrases ; les details complets sont dans les fichiers cites.
+
+## Architecture generale
+
+**Pourquoi un CRNN plutot que l'OCR generique (PaddleOCR/EasyOCR) ?**
+L'OCR generique ne "sait" pas ce qu'il lit (il devine si un nombre est un prix ou un volume par sa magnitude), et n'apprend jamais de ses erreurs. Le CRNN est entraine sur nos propres photos de pompes : il apprend a lire ce type d'ecran precisement, et sa precision peut s'ameliorer avec plus de donnees. Voir `docs/ARCHITECTURE.md`.
+
+**Le pipeline en une phrase ?**
+Photo -> detection ecran (OpenCV) -> decoupage en 3 lignes (prix/volume/prix_litre) -> lecture CRNN ligne par ligne -> normalisation numerique -> calcul de coherence -> moteur de regles (bloque ou valide) -> reponse JSON.
+
+**Pourquoi trois modules separes (preprocessing, recognizer, postprocess, rules) au lieu d'un seul script ?**
+Chaque etape est testee independamment (`tests/`), et une amelioration future du modele de reconnaissance ne touche pas au moteur de regles ni au pretraitement. Voir `docs/ARCHITECTURE.md`.
+
+## Pretraitement (detection ecran + decoupage)
+
+**Comment l'ecran est-il detecte dans la photo ?**
+Contours (Canny) + fermeture morphologique pour relier les bords, puis on garde le plus grand rectangle dont la forme ressemble a un ecran (ratio largeur/hauteur entre 1 et 8). Heuristique, pas un modele entraine. Voir `docs/PREPROCESSING.md`.
+
+**Comment l'ecran est-il decoupe en 3 lignes ?**
+Binarisation (CLAHE + Otsu), puis projection horizontale : on compte les pixels "texte" par ligne de pixels, on repere les bandes actives. Si la projection ne trouve pas exactement 3 bandes, repli sur un decoupage proportionnel (3 tiers egaux).
+
+**Quelle est la limite connue de cette methode ?**
+86% des images du jeu d'annotation tombent sur le repli proportionnel, pas la detection precise -> c'est la cause n°2 identifiee du plafond a 70.2% (`docs/LIMITATIONS.md`).
+
+**Pourquoi CLAHE avant la binarisation ?**
+Les ecrans LCD ont un eclairage inegal (reflets, angle de prise de vue) ; CLAHE renforce le contraste localement plutot que globalement, ce qui rend le seuillage Otsu plus fiable.
+
+## Modele et entrainement
+
+**Quelle precision atteint le modele actuellement ?**
+70.2% de precision exacte par ligne en validation (epoch 32/60), contre 55.3% pour la version initiale. Voir `train/models/v2/history.json`.
+
+**Qu'est-ce qui limitait le modele a 55% au depart ?**
+Un bug de redimensionnement : a l'entrainement, les images etaient etirees sans preserver le ratio d'aspect, alors qu'a l'inference le ratio etait preserve. Le modele apprenait donc sur des chiffres deformes differemment de ce qu'il voit en production. Corrige (resize + padding identiques aux deux etapes).
+
+**Qu'est-ce qui limite encore la precision aujourd'hui ?**
+Le manque de diversite du dataset : 310 echantillons mais seulement 30 valeurs distinctes (probablement des rafales de photos des memes tickets). Le modele memorise plus qu'il ne generalise. Voir `docs/LIMITATIONS.md`.
+
+**Y a-t-il un risque d'overfitting ?**
+Le signal est visible dans les logs (perte d'entrainement ~0.10 contre perte de validation qui plafonne ~0.93-0.95). Mitige par la selection du checkpoint sur la meilleure perte de validation (pas la derniere epoch) et par l'arret avant la fin des 60 epochs prevues.
+
+**Comment le train/val split evite-t-il la fuite de donnees ?**
+`split_lines.py` et `prepare_doctr_dataset.py` nettoient desormais le dossier de sortie avant de regenerer le split a chaque execution -- un bug precedent laissait d'anciens fichiers en place, ce qui faisait apparaitre une meme image dans train ET val.
+
+**Pourquoi ne pas viser directement 90%+ ?**
+Le facteur limitant est la quantite/diversite de donnees annotees, pas les hyperparametres. Collecter plus de transactions distinctes est le levier le plus efficace, mais aussi le plus long -- priorise pour une iteration future plutot que pour cette version.
+
+## Moteur de regles metier
+
+**Quelle est la regle la plus importante ?**
+Le prix du litre configure cote YELY fait toujours autorite sur celui lu a l'ecran (`fuel_price` fourni par l'appelant prime). Le prix lu a l'ecran n'est utilise qu'en repli, si aucun prix n'est fourni.
+
+**Dans quel ordre les blocages sont-ils evalues ?**
+1) qualite image non valide (floue/sombre/surexposee) -> 2) aucune donnee detectee -> 3) litres ET montant manquants, ou prix manquant -> 4) incoherence montant/litres/prix -> 5) confiance sous le seuil -> sinon succes. Le premier echec fixe le message. Voir `app/rules.py`.
+
+**Comment le score de confiance est-il calcule ?**
+`confidence_score = confiance OCR moyenne x 0.6 + score qualite image x 0.4`, plafonne a 1.0. Voir `app/rules.py::_compute_confidence_score`.
+
+**Pourquoi verifier la luminosite avant le flou dans le controle qualite ?**
+La variance du Laplacien (mesure de flou) depend du contraste, qui s'effondre deja dans une image sombre meme si elle est nette. Verifier le flou en premier classait a tort des photos sombres comme "floues". Corrige cette session.
+
+## Monitoring et apprentissage continu
+
+**Comment le systeme s'ameliore-t-il avec l'usage ?**
+Boucle de feedback : `POST /feedback` permet a un pompiste de corriger une lecture erronee (photo deja sauvegardee cote serveur) ; `monitoring/feedback.py` convertit ces corrections en nouvelles entrees d'annotation, relues manuellement (`annotate.py --review-pending`) avant un reentrainement. Voir `docs/MONITORING.md`.
+
+**Pourquoi une relecture humaine avant reentrainement, pas un cycle automatique ?**
+La detection d'ecran automatique n'est pas fiable a 100% -- injecter silencieusement des crops mal cadres degraderait le dataset plutot que de l'ameliorer. Un cout humain court est prefere a un risque de regression silencieuse.
+
+**Comment suit-on les performances en production ?**
+`GET /metrics` agrege `logs/api.log` a la volee (taux de succes, confiance moyenne, causes de blocage). `GET /failures` liste les dernieres transactions bloquees avec leur photo, pour investigation immediate.
+
+## Deploiement
+
+**Pourquoi Hugging Face Spaces et pas Vercel/Netlify pour l'API ?**
+L'API embarque PyTorch + doctr + OpenCV (bien au-dela des limites de taille des plateformes serverless) et l'inference prend 60-100s sur CPU (au-dela des timeouts serverless). HF Spaces (Docker) n'a pas ces limites. Voir `docs/WORKFLOW.md` §6.
+
+**Ou est heberge le frontend ?**
+Netlify (fichiers statiques, `web/`), separement de l'API sur Hugging Face -- d'ou le CORS configure dans `app/main.py`.
+
+## Limites assumees (a dire spontanement si demande)
+
+- 70.2% de precision exacte par ligne, en dessous du seuil de 90% vise initialement.
+- Dataset petit et peu diversifie en valeurs (30 valeurs distinctes / 310 echantillons).
+- Decoupage en lignes imprecis sur 86% des images (repli proportionnel).
+- Le CRNN reste separe du reste du pipeline (regles, qualite, API) -- une amelioration future du modele ne casse rien d'autre.

docs/WORKFLOW.md

@@ -130,21 +130,23 @@ Contenu minimal :
 
 ## 6. Déploiement
 
-**Frontend (`web/`) → Vercel** : parfaitement adapté (statique ou
-Next.js), pas de souci particulier.
-
-**API IA → PAS Vercel.** Point d'attention important avant d'aller plus
-loin : Vercel (Serverless Functions) limite la taille du build (~250 Mo
-décompressés) et le temps d'exécution par requête. Cette API embarque
-PyTorch + doctr + OpenCV, qui dépassent déjà largement cette taille à eux
-seuls, et l'inférence CRNN prend actuellement 60-100+ secondes par image
-(bien au-delà des temps d'exécution autorisés par Vercel, même sur les
-plans payants). Déployer tel quel sur Vercel échouera au build ou au
+**Frontend (`web/`) → Netlify** : parfaitement adapté (fichiers statiques,
+pas de build nécessaire), pas de souci particulier.
+
+**API IA → PAS d'hébergement serverless classique (Vercel, Netlify
+Functions...).** Point d'attention important avant d'aller plus loin : ce
+type d'hébergement limite la taille du build (souvent ~250 Mo décompressés)
+et le temps d'exécution par requête. Cette API embarque PyTorch + doctr +
+OpenCV, qui dépassent déjà largement cette taille à eux seuls, et
+l'inférence CRNN prend actuellement 60-100+ secondes par image (bien
+au-delà des temps d'exécution autorisés, même sur les plans payants).
+Déployer tel quel sur ce type de plateforme échouera au build ou au
 timeout, pas juste "sera lent".
 
 **Décision retenue : Hugging Face Spaces (Docker SDK)** pour l'API.
 Gratuit, pensé pour les démos ML, pas de limite stricte de temps
-d'exécution comme Vercel, `Dockerfile` déjà préparé (`yely_ai_module/Dockerfile`).
+d'exécution comme un hébergement serverless, `Dockerfile` déjà préparé
+(`yely_ai_module/Dockerfile`).
 
 Étapes de déploiement (à faire manuellement, action externe) :
 1. Créer un Space sur huggingface.co → SDK "Docker" → visibilité au choix.
@@ -163,9 +165,9 @@ d'exécution comme Vercel, `Dockerfile` déjà préparé (`yely_ai_module/Docker
 3. Pousser le contenu de `yely_ai_module/` (avec `models/crnn_fuel_pump_best.pt`
    inclus) vers le dépôt git du Space.
 4. Noter l'URL publique du Space (`https://<user>-<space>.hf.space`) — c'est
-   l'URL que le frontend Vercel appellera pour `/analyze`.
+   l'URL que le frontend Netlify appellera pour `/analyze`.
 5. Ajouter `CORSMiddleware` dans `app/main.py` pour autoriser le domaine
-   Vercel du frontend (sinon le navigateur bloquera les réponses).
+   Netlify du frontend (sinon le navigateur bloquera les réponses).
 6. (Optionnel, payant) Activer le **stockage persistant** du Space et
    définir la variable d'environnement `YELY_DATA_DIR` sur son point de
    montage — sans quoi `photos/`, `logs/` et `monitoring/feedback.jsonl`

web/config.js

@@ -6,4 +6,4 @@
 // sur un sous-domaine dédié : https://<user>-<space-en-minuscules-tirets>.hf.space
 // Vérifier l'URL exacte en ouvrant le Space et en regardant l'adresse dans
 // la barre du navigateur une fois l'app chargée (ou l'onglet réseau).
-window.YELY_API_URL = "https://danielxdata-yely-ai-module.hf.space/analyze";
+window.YELY_API_URL = "https://danielxdata-yely-ai-module.hf.space/analyze";

web/index.html

@@ -32,9 +32,12 @@
       padding: 2rem 1rem;
     }
     .app { width: 100%; max-width: 480px; }
-    .brand { display: flex; align-items: center; gap: 0.6rem; margin-bottom: 0.25rem; }
+    .brand { display: flex; align-items: center; justify-content: space-between; gap: 0.6rem; margin-bottom: 0.25rem; }
+    .brand-left { display: flex; align-items: center; gap: 0.6rem; }
     .brand .dot { width: 10px; height: 10px; border-radius: 50%; background: var(--accent); }
     .brand h1 { font-size: 1.3rem; margin: 0; }
+    .brand a { color: var(--muted); font-size: 0.85rem; text-decoration: none; border: 1px solid var(--border); padding: 0.4rem 0.7rem; border-radius: 8px; }
+    .brand a:hover { border-color: var(--accent); color: var(--text); }
     .subtitle { color: var(--muted); font-size: 0.9rem; margin: 0 0 1.5rem; }
 
     .card {
@@ -112,7 +115,10 @@
 </head>
 <body>
   <div class="app">
-    <div class="brand"><span class="dot"></span><h1>YELY |  Vérification pompiste</h1></div>
+    <div class="brand">
+      <div class="brand-left"><span class="dot"></span><h1>YELY, verification pompiste</h1></div>
+      <a href="stats.html">Statistiques</a>
+    </div>
     <p class="subtitle">Démo du module IA : photo du terminal ->  lecture automatique ->  vérification de cohérence.</p>
 
     <div id="banner" class="banner"></div>