---
from: qwen
to: dom
date: 2026-06-05
topic: revue-decoupage-v11-5
status: open
priority: high
references:
  - decision: docs/coordination/decisions/2026-06-05_dom_d17-v11-5-chantiers-paralleles.md
---

# Revue de decoupage v11.5 -- 2026-06-05

## 1. Frontieres entre chantiers

### GUI v6
- **Surface** : remplacement de `Pseudonymisation_Gui_V5.py` (2894 lignes, tkinter pur) par une nouvelle GUI customtkinter. La GUI actuelle consomme le moteur via des imports directs (`anonymizer_core_refactored_onnx`, `ner_manager_onnx`, `eds_pseudo_manager`, `camembert_ner_manager`, `vlm_manager`).
- **Fichiers concernes** :
  - `Pseudonymisation_Gui_V5.py` (2894 lignes) -- refonte complete
  - `launcher.py` (698 lignes) -- splash + download modeles, a adapter pour v6
  - `manual_masking.py` (56 lignes) -- embryon, a intégrer ou remplacer
  - `pdf_mask_designer.py` (440 lignes) -- standalone, a raccrocher ou remplacer
  - `format_converter.py` (256 lignes) -- non orchestre GUI
  - Assets `assets/` (logo, icones)
  - `gui_batch_paths.py` -- tests batch GUI
  - WIP Windows existant : branche `backup/windows-wip-2026-06-05`, commit `b8c9c41`, +1250 lignes customtkinter (non mergee, base a partir de `0124457`, 52 commits avant HEAD)
- **Dependances externes** : customtkinter (nouvelle dep), sv_ttk (actuellement optionnel), PIL/Image (deja present pour VLM). Le moteur reste appele via les memes imports -- API interne stable si le contrat `core.anonymize(...)` ne change pas.

### D-13 complet
- **Surface** : extension du mecanisme `admin_mode.py` (66 lignes actuelles) pour proteger TOUS les reglages sensibles dans la GUI v6. Actuellement, seulement le VLM Ollama et le titre fenetre sont proteges. Les reglages reportes sont :
  - Stopwords personnalisables (widget `_sw_listbox` dans V5, ~lignes 914+)
  - Profils techniques : `regex_overrides`, `force_terms` (config YAML)
  - Choix moteur NER (GLiNER, CamemBERT, EDS-Pseudo) -- via `_active_manager`
  - Sauvegarde fichiers config sensibles (`config/dictionnaires.yml`, `config/profiles.yml`)
  - Cases `profile_force_disable_vlm` dans les profils (lignes 1088-1097 V5)
- **Fichiers concernes** :
  - `admin_mode.py` -- extension (nouvelles features a proteger, matrice admin/non-admin)
  - `config_defaults.py` (201 lignes) -- lecture/ecriture config dictionnaires
  - `profile_defaults.py` -- gestion profils runtime
  - `config/dictionnaires.yml`, `config/dictionnaires.default.yml`
  - `config/profiles.yml`, `config/profiles.default.yml`
  - GUI v6 : sections "Parametres avances" et "Profils techniques" (co-concu avec chantier A)
  - `config/admin_rules.yml`, `config/admin_rules.default.yml`
- **Dependances externes** : aucune nouvelle. S'appuie sur `admin_mode.py` existant et les fichiers config YAML. Depend de la GUI v6 pour l'application visuelle des protections.

### Plateforme licence
- **Surface** : deux composants distincts :
  1. **Client** : nouveau `license.py` (n'existe pas encore), module Python embarque dans l'EXE. Verifie la licence au demarrage via signature RSA-PSS 2048 + SHA256. Stocke `license.dat` (chiffre DPAPI Windows). Phone home toutes les 30 jours max. Grace period 15 jours.
  2. **Serveur** : nouveau dossier `platform/` (ou repo separe), FastAPI + PostgreSQL + HTMX/Jinja2, heberge sur `app.aivanov.fr` (infra OVH HDS). Auth fastapi-users, email via Brevo.
- **Fichiers concernes** :
  - `license.py` (creation) -- module client
  - CLE PUBLIQUE RSA embarquee (fichier ou constante) -- CLE PRIVEE cote serveur uniquement
  - `launcher.py` -- point d'entree pour verifier la licence AVANT lancement GUI
  - GUI v6 -- emplacement reserve pour afficher statut licence (banniere, expiration)
  - `platform/` (creation) -- backend FastAPI, DB schema, templates HTMX
  - `anonymisation_onefile.spec` -- eventuellement inclure `license.dat` dans le bundle
- **Dependances externes** : cryptography (nouvelle dep pour RSA-PSS verify), requests (deja present), FastAPI + uvicorn + psycopg2 + fastapi-users + Brevo SDK cote serveur.

## 2. Fichiers a risque de conflit

| Fichier | Chantiers concernes | Type de conflit | Mitigation |
|---|---|---|---|
| `launcher.py` (698 lignes) | **GUI v6** (adapt splash + lancement v6) + **Licence** (check licence avant GUI) | Les deux chantiers modifient le flux de demarrage : splash -> check licence -> launch GUI | Definir un contrat : `launcher.py` appelle `license.check()` avant `App(root)`. Chantier C fournit l'API, chantier A fournit le nouveau point d'entree GUI. Merge sequentiel (C d'abord, puis A). |
| `Pseudonymisation_Gui_V5.py` (2894 lignes) | **GUI v6** (refonte) + **D-13** (protections admin) | D-13 partiel protege des widgets V5 ; D-13 complet doit proteger les widgets V6 | **Pas de conflit reel** si D-13 complet est implemente directement dans la GUI v6 (customtkinter), pas dans V5. Le fichier V5 reste gele. D-13 cible uniquement la GUI v6. |
| `admin_mode.py` (66 lignes) | **D-13** seul | Aucun conflit attendu | Chantier B seul maitre de ce fichier. |
| `anonymisation_onefile.spec` | **GUI v6** (nouveau point d'entree) + **Licence** (cle publique + license.dat) | Les deux ajoutent des fichiers au bundle PyInstaller | Coordination mineure : chaque chantier declare ses fichiers additions. Merge sequentiel resout. |
| `config/profiles.yml` / `config/dictionnaires.yml` | **D-13** (protection ecriture) + **GUI v6** (UI profils) | D-13 restreint l'ecriture de ces fichiers en non-admin ; GUI v6 les lit/edite | Contrat ecrit : GUI v6 appelle `admin_required()` avant toute sauvegarde config sensible. Pas de collision code, juste un contrat API. |

## 3. Dependances cachees

| Dependances | Impact | Chantier affecte |
|---|---|---|
| **GUI v6 doit exister avant D-13 complet** | D-13 complet protege des reglages DANS la GUI. Sans GUI v6, D-13 ne peut pas implementer les protections visuelles (cases cachees/desactivees). Seul `admin_mode.py` peut etre etendu independamment. | **D-13** : peut preparer la matrice admin et etendre `admin_mode.py`, mais ne peut pas fermer le chantier sans GUI v6. |
| **Licence client doit exister avant GUI v6** | La GUI v6 doit afficher le statut licence (banniere "Licence expiree", etc.). Sans `license.py`, l'UI ne peut pas s'adapter. | **GUI v6** : peut reserver un placeholder UI, mais ne peut pas finaliser l'affichage licence sans l'API `license.py`. |
| **launcher.py est un point de convergence** | Il orchestre splash -> download modeles -> launch GUI. Le chantier Licence y ajoute un check pre-GUI, le chantier GUI v6 y change le point d'entree. | **Les 3 chantiers** indirectement. |
| **WIP Windows `b8c9c41` est base sur un vieux commit** | Le WIP GUI v6 (+1250 lignes customtkinter) part de `0124457`, qui est 52 commits avant HEAD. Il ne contient PAS les fixes leak (GRAND, EJNAINI), la quarantaine Q-1, ni `admin_mode.py`. | **GUI v6** : le WIP est une reference visuelle, pas une base a merger. La GUI v6 doit etre reecrite proprement a partir de HEAD. |
| **Customtkinter = nouvelle dependance** | L'installation de customtkinter doit etre valide dans `requirements.txt`, `.spec`, et le build Windows. | **GUI v6** + build system (hors perimetre des 3 chantiers mais bloquant si oublie). |
| **`anonymizer_core_refactored_onnx.py` API** | La GUI v6 suppose une API stable du core. Si le core change (signature de `anonymize()`, parametres), la GUI v6 casse. | **GUI v6** : doit contractualiser l'API core avant codage. |

## 4. Points a contractualiser avant codage

1. **Interface GUI v6 <-> moteur** : Quels sont les appels exacts que la GUI fait au core ? Signature de `core.anonymize()`, format des resultats, gestion des erreurs. Un fichier `gui_core_contract.md` listant les entrees/sorties attendues eviterait les incompatibilites. Le core actuel est importe via `anonymizer_core_refactored_onnx` (lignes 40-48 V5) et appele dans `_run_thread` (lignes 1566+).

2. **API `license.py` cote GUI** : Quel statut la GUI peut-elle lire ? (actif/expires/grace/absent). Fournira-t-on une classe `LicenseStatus` avec des proprietes simples ? La GUI n'a pas besoin de connaitre RSA-PSS, juste `{ok: bool, message: str, expires_at: str}`.

3. **Matrice D-13 admin/non-admin** : Liste exacte de chaque widget/parametre + son etat en admin vs non-admin (visible/cache, actif/desactif, lisible/inscriptible). Sans cette matrice, le chantier B ne peut pas coder et le chantier A ne peut pas concevoir les ecrans.

4. **Flux launcher.py** : Ordre exact des etapes au demarrage :
   ```
   splash -> download modeles -> check licence -> launch GUI v6
   ```
   Qui ecrit le nouveau `launcher.py` ? C (licence) ou A (GUI) ? Recommandation : C fournit `license.py` + un snippet d'integration, A l'integre dans le nouveau launcher v6.

5. **Sortie du WIP Windows** : Le WIP `backup/windows-wip-2026-06-05` (`b8c9c41`) doit etre pousse sur Gitea AVANT tout travail GUI v6. C'est le seul backup existant des +1250 lignes customtkinter. Sans ca, le chantier A repart de zero.

## 5. Ordre de merge recommande

1. **C (Licence -- client `license.py`)** -- Le plus isole. Creer un fichier neuf, tests unitaires de verification RSA-PSS, aucune collision avec le moteur ou la GUI. Mergeable sur `feature/v11-5` independamment.
2. **A (GUI v6)** -- Gros morceau, fichier neuf `Pseudonymisation_Gui_V6.py`. Peut etre developpe en parallele de C, mais merge APRES C pour integrer le check licence dans le launcher.
3. **B (D-13 complet)** -- Se greffe sur A (sections avancees de la GUI v6) et etend `admin_mode.py`. Merge APRES A car il depend des ecrans v6 pour appliquer les protections.

**Justification** : C est le plus decouple (fichier neuf + serveur separe). A est le plus gros et le plus risque (2894 lignes a remplacer). B depend visuellement de A. L'ordre C->A->B minimise les rebase et les conflits. Merge sequentiel sur `feature/v11-5` creee a partir de HEAD apres GO beta.

**Parallelisme reel** : A, B, C peuvent **developper en parallele** sur branches separees (`feature/v11-5-gui`, `feature/v11-5-d13`, `feature/v11-5-licence`). Le merge sequentiel intervient uniquement lors de l'integration sur `feature/v11-5`. Les contrats (sections 4) permettent ce parallelisme.

## 6. Alertes / desaccords pour Dom

| # | Sujet | Question pour Dom |
|---|---|---|
| 1 | **WIP Windows non sauvegarde** | Le WIP GUI v6 (+1250 lignes, commit `b8c9c41`) n'existe que sur le disque de `192.168.1.11`. Veux-tu que je le pousse sur Gitea maintenant (non destructif, branche separee) ou tu le fais toi-meme ? |
| 2 | **Plateforme licence -- Phase 1.1 vs 1.2** | D-14 prevoit ~12h pour le client `license.py` et ~50h pour le serveur. Veux-tu que le chantier v11.5 inclue SEULEMENT la Phase 1.1 (client) et reporte la Phase 1.2 (serveur FastAPI) ? Le client seul peut fonctionner avec une licence generatee manuellement en attendant le serveur. |
| 3 | **GUI v6 -- refonte ou evolution ?** | La GUI v6 sera-t-elle un fichier entierement nouveau (`Pseudonymisation_Gui_V6.py`) ou une evolution du V5 ? Un fichier nouveau est plus sur (pas de collision avec le gel beta), mais demande de re-brancher tous les widgets existants. |
| 4 | **Phase 0 beta Reunion -- pas de licence** | D-14 dit que le beta-testeur n'a pas de licence. Le `license.py` doit-il etre conditionnel (si pas de fichier licence, mode libre) ou faut-il generer une licence de dev pour le beta ? |
| 5 | **customtkinter sur Windows** | customtkinter est une nouvelle dependance. As-tu valide qu'il s'installe correctement sur la machine Windows de build (`192.168.1.11`) et qu'il est compatible PyInstaller --onefile ? |

## 7. Recommandation

**GO pour preparation parallele** avec les conditions suivantes :

1. **Sauvegarder le WIP Windows** (`b8c9c41`) sur Gitea AVANT tout autre travail. C'est le point de perte unique le plus critique.
2. **Rediger les 3 contrats** avant codage lourd :
   - Contrat GUI <-> core (entrees/sorties de `anonymize()`)
   - API `license.py` (statut lisible par la GUI)
   - Matrice D-13 (chaque reglage + etat admin/non-admin)
3. **Branches separees** : `feature/v11-5-gui`, `feature/v11-5-d13`, `feature/v11-5-licence` -- developpement parallele, merge sequentiel C->A->B sur `feature/v11-5`.
4. **Gel beta respecte** : aucune branche v11.5 creee a partir de la branche de livraison tant que Dom n'a pas donne GO apres tests Windows.
5. **Phase 1.1 licence uniquement** : se concentrer sur `license.py` client (12h) et reporter le serveur FastAPI (50h) a une phase ulterieure. Le client peut etre teste avec des licences generees manuellement.
6. **Critere de merge** : les 73/73 tests unitaires doivent rester verts apres chaque merge. Le score qualite `evaluate_quality.py` >= baseline (99.8). Aucun nouveau leak PII.

Le parallelisme est **realiste** car les surfaces sont bien separees (D-17). Le principal risque est `launcher.py` (point de convergence) et le WIP Windows non sauvegarde. Ces deux points sont mitigables avec les actions ci-dessus.
