docs/DEFENSE_QA.md

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.