---
from: claude (Agent D — intégration)
to: dom
date: 2026-06-05T18:40:00+02:00
topic: planD-integration-v11-5
status: open
priority: high
references:
  - plan: docs/coordination/inbox/for-dom/2026-06-05_claude_plan-v11-5-parallele.md
  - decision: docs/coordination/decisions/2026-06-05_dom_d17-v11-5-chantiers-paralleles.md
  - decision: docs/coordination/decisions/2026-06-05_dom_d16-test-windows-avant-diffusion.md
  - decision: docs/coordination/decisions/2026-06-02_dom_d14-plateforme-licence-architecture.md
  - decision: docs/coordination/decisions/2026-06-02_dom_d13-partial-scope.md
---

# Plan D — Intégration / merge v11.5 (anti-collision 3 agents)

**Planification uniquement — lecture seule.** Aucun code modifié, aucun commit.
Ce document définit comment les chantiers A (GUI v6), B (D-13 complet) et
C (licence) s'intègrent sans se marcher dessus.

État vérifié au moment de la rédaction (HEAD `57aa0f0`, branche `feature/q1-quarantine-mvp`) :
- Suite `tests/unit` : **98 tests collectés** (baseline confirmée).
- `admin_mode.py` (2.4 ko) et `config_defaults.py` (5.8 ko) **existent déjà** → B étend, ne crée pas.
- `license.py`, `gui_v6/`, `platform/` : **n'existent pas encore** → créations propres (A, C).
- `Pseudonymisation_Gui_V5.py` (119 ko) : fichier de livraison bêta → **gelé**, sert de référence à A.
- `backup/windows-wip-2026-06-05` : **déjà poussé sur Gitea** (section 0 du plan maître close).

---

## 1. Frontières de fichiers (qui crée / modifie quoi)

### Agent A — GUI v6 (zone PROPRE)
| Fichier / dossier | Action | Note |
|---|---|---|
| `Pseudonymisation_Gui_V6.py` | **CRÉE** (neuf) | réécriture propre, pas de merge brut du WIP |
| `gui_v6/` (nouveau package) | **CRÉE** | onglets, widgets, thèmes, assets |
| `gui_v6/assets/`, thèmes | **CRÉE** | maquette v6 validée 2026-05-06 |
| `Pseudonymisation_Gui_V5.py` | **NE TOUCHE PAS** | reste le point d'entrée bêta jusqu'à bascule finale |

A consomme le moteur via l'API interne stable (mêmes signatures qu'en v5).
A **réserve deux emplacements UI** : (a) section « Paramètres avancés / Profils
techniques » pour B, (b) bannière état licence (statut/expiration) pour C.

### Agent B — D-13 complet (zone PROPRE + zone partagée avec A)
| Fichier / dossier | Action | Note |
|---|---|---|
| `admin_mode.py` | **ÉTEND** (existe déjà) | ajoute la matrice de réglages protégés, garde `is_admin()`/`admin_required()` |
| `config_defaults.py` | **ÉTEND** (existe déjà) | flags admin/non-admin par réglage |
| `gui_v6/` sections « avancé » | **CO-ÉCRIT avec A** | B = règles d'accès, A = écrans |
| moteur de détection (`anonymizer_core_*`) | **NE TOUCHE PAS** | garde-fou n°1 |

### Agent C — Licence (zone PROPRE, la plus isolée)
| Fichier / dossier | Action | Note |
|---|---|---|
| `license.py` | **CRÉE** (neuf) | client : vérif RSA-PSS, expiration, grace 15 j, offline 30 j, révocation |
| `platform/` (serveur) | **CRÉE** (neuf) | activation poste, 1 licence = 1 machine_id (D-14 phase 1.2) |
| clé **publique** embarquée | **CRÉE** | clé privée RSA **jamais** dans le repo client (serveur OVH uniquement) |
| GUI, core | **NE TOUCHE PAS** | C n'expose qu'une API statut/expiration consommée par A |

### Agent D — Intégration (ce document)
| Zone | Action |
|---|---|
| `docs/coordination/` | docs de merge, ce plan |
| `tests/` (structure, CI) | organisation des nouveaux dossiers de tests par chantier |
| code applicatif | **NE TOUCHE PAS** |

### Fichiers PARTAGÉS à risque (à surveiller en priorité)
1. **`gui_v6/` sections « avancé »** — seule vraie co-édition (A↔B). Mitigation :
   contrat écrit A↔B avant tout code ; B livre une **interface de règles**
   (`admin_mode.get_field_policy(field) -> visible|disabled|hidden`) que A appelle,
   plutôt que B éditant les écrans directement.
2. **`Pseudonymisation_Gui_V6.py`** — propriété exclusive A. B et C n'y écrivent pas ;
   ils exposent des fonctions, A les branche.
3. **`requirements.txt` / `.spec` PyInstaller** — touchés par C (dépendances RSA :
   `cryptography`) et par le build final. Mitigation : un **seul** agent (D, au merge)
   consolide `requirements.txt` et le `.spec` ; A/B/C déposent leurs deltas de deps en doc.
4. **`config_defaults.py`** — B l'étend. A le lit seulement. Pas d'écriture concurrente.

---

## 2. Dépendances entre agents

```
C (licence)  ──API statut/expiration──►  A (GUI v6, bannière licence)
B (D-13)     ──API get_field_policy────►  A (GUI v6, écrans avancés)
A (GUI v6)   ──écrans + emplacements───►  B se greffe dessus
```

- **B dépend de A** pour les écrans : B ne peut finaliser ses sections « avancé »
  qu'une fois la structure d'onglets v6 posée par A. B peut **démarrer en parallèle**
  sur la logique pure (matrice de règles dans `admin_mode.py` + tests headless),
  puis brancher l'UI quand A a livré.
- **A dépend de C** pour l'API licence (statut/expiration). A peut avancer avec un
  **stub** d'interface licence (contrat figé) tant que C n'a pas fini, puis brancher
  le vrai `license.py`.
- **C ne dépend de personne** → chantier le plus isolé, mergeable en premier.
- **D dépend de tous** (validation finale).

Règle d'or : chaque dépendance passe par une **interface contractualisée** (signature
de fonction figée tôt), pas par un partage de fichier. Cela permet le parallélisme.

---

## 3. Ordre de merge recommandé (et justification)

Confirme la proposition §6 du plan maître :

1. **Base** : après **GO bêta** (D-16), figer la branche de livraison
   (`feature/q1-quarantine-mvp` à `15f73f8` ou le hotfix éventuel), puis créer
   `feature/v11-5` **depuis cette base figée**.
2. **C (licence) en premier** — *le plus isolé* : `license.py` + `platform/` neufs,
   zéro conflit moteur/GUI. Mergeable seul, testable seul. Réduit le risque tôt.
3. **A (GUI v6) ensuite** — gros morceau, fichier neuf `Pseudonymisation_Gui_V6.py`.
   Branche la bannière licence sur l'API de C (déjà mergée). Pas de conflit avec C
   (surfaces disjointes).
4. **B (D-13) en dernier** — se *greffe sur A* (sections avancées de la GUI v6).
   Merge après A pour que les écrans existent. La logique `admin_mode.py` étant déjà
   prête et testée headless, le merge B = branchement UI + tests matrice.
5. **Validation D** — qualité + tests + build, puis bascule de v6 par défaut
   (changement du point d'entrée v5→v6) en **dernier commit**, isolé et réversible.

Justification : on merge du moins couplé au plus couplé. C isolé d'abord retire le
risque cryptographique tôt ; A pose le squelette UI dont B a besoin ; B greffé en
dernier minimise la fenêtre de co-édition. La bascule v5→v6 est le tout dernier pas,
trivialement réversible (revert d'un seul commit).

---

## 4. Critères d'acceptation v11.5 (gate de merge)

Aucun merge dans `feature/v11-5` n'est accepté sans :

| Critère | Cible | Vérification |
|---|---|---|
| Non-régression moteur | `tests/unit` **98 passed** (inchangé) | `pytest tests/unit -q` |
| Leak score | **100/100** inchangé | `tests/unit/test_leak_scanner.py` + audit_30 |
| Audit qualité | `evaluate_quality.py` **≥ 98.5** (baseline) | `scripts/evaluate_quality.py` |
| Build EXE | **reproductible** (PyInstaller --onefile, config externe) | build Windows 192.168.1.11 |
| GUI v6 (A) | smoke lancement + workflow principal OK ; contrat moteur identique v5 | tests `gui_batch_paths`, `manual_masking` conservés |
| D-13 (B) | chaque réglage protégé caché/désactivé en non-admin ; `admin_required` lève ; sauvegarde config sensible bloquée non-admin | nouveaux tests matrice admin |
| Licence (C) | signature RSA-PSS (valide/falsifiée), expiration, grace 15 j, offline 30 j, révocation ; serveur : 1 licence = 1 machine_id | nouveaux tests `license.py` + serveur |

**Garde-fou non négociable** : les 98 tests verts + leak 100/100 sont le filet.
Le moteur de détection ne bouge pas → tout chantier qui ferait baisser ces deux
chiffres est rejeté, point.

---

## 5. Stratégie de branches

```
feature/q1-quarantine-mvp  (livraison bêta — GELÉE jusqu'au GO Dom)
        │  ◄── hotfix MVP éventuel possible ICI uniquement (D-16)
        │
   [GO BÊTA] → tag de livraison figé (ex: beta-v11)
        │
        └──► feature/v11-5            (créée APRÈS GO, depuis la base figée)
                ├── feat/v11-5-licence   (C)  → merge 1
                ├── feat/v11-5-gui-v6     (A)  → merge 2
                └── feat/v11-5-d13        (B)  → merge 3 (greffé sur A)
```

Règles :
- **Aucune branche v11.5 créée avant le GO bêta** (gel D-16/D-17).
- `feature/v11-5` part de la **base figée** (tag de livraison), pas de `main` ni
  d'une branche en mouvement.
- Sous-branches par chantier, merge dans `feature/v11-5` dans l'ordre §3.
- Hotfix MVP, s'il survient pendant la bêta, reste sur `feature/q1-quarantine-mvp`
  et sera **rebasé/cherry-pické** dans la base figée avant création de `feature/v11-5`
  (ne jamais mélanger hotfix et refonte).
- Tag de sécurité conservé sur `backup/windows-wip-2026-06-05` (anti-gc).

---

## 6. Risques principaux + mitigations

| Risque | Impact | Mitigation |
|---|---|---|
| GUI v6 casse le moteur | leak/qualité régressent | Contrat moteur strict (mêmes I/O que v5) + 98 tests verts obligatoires au merge |
| Co-édition A/B sur écrans avancés | conflits Git, double logique | Contrat écrit A↔B AVANT code ; B expose `get_field_policy()`, A consomme — pas de co-édition de fichier |
| Mélange hotfix MVP / v11.5 | divergence, régression bêta | Gel respecté ; v11.5 sur branche dédiée créée APRÈS GO ; hotfix cherry-pické proprement |
| Clé privée RSA fuit | licences forgeables | Clé privée **serveur OVH uniquement** (D-14) ; client n'embarque que la clé publique |
| `requirements.txt` / `.spec` édités par 3 agents | build cassé, conflits | Consolidation par **un seul** agent (D) au merge ; deltas de deps livrés en doc |
| WIP GUI v6 sur disque unique | perte de la base A | Déjà mitigé : backup poussé sur Gitea + tag anti-gc |
| Plateforme licence = ~50h | dérapage planning | Phasage D-14 : 1.1 client (~12h) avant 1.2 serveur (~50h) ; C livrable client d'abord |
| Bascule v5→v6 par défaut | régression point d'entrée | Bascule = dernier commit isolé, revert trivial |

---

## 7. Rappel garde-fous

- **GEL BÊTA** : rien ne démarre en *code* avant le GO de Dom (D-16/D-17). Seuls
  plans, inventaires, contrats d'interface et docs sont produits maintenant.
- **Le moteur de détection ne bouge pas.** v11.5 = refonte UI + ajouts périphériques
  (licence, admin). Le leak score 100/100 et les 98 tests sont intouchables.
- **Interfaces contractualisées** entre A/B/C : tout passe par des signatures de
  fonctions figées tôt, jamais par du partage de fichier — c'est ce qui rend le
  parallélisme sûr.
- **Un seul agent (D) consolide** `requirements.txt` et le `.spec` au merge.

— Claude (Agent D)
