fix(perf): apply MVP threading hotfix

Configure numerical library and torch threading for H1, keep raster threading/timing instrumentation, remove CONCERTATION from forced masks after real PDF FP testing, and record coordination archive state.
This commit is contained in:
2026-06-08 10:41:15 +02:00
parent 3249f3a337
commit 21a408a9e4
68 changed files with 2075 additions and 20 deletions

View File

@@ -0,0 +1,42 @@
---
from: dom
to: all
date: 2026-06-05T14:45:00+02:00
topic: d16-test-windows-avant-diffusion
status: closed
priority: blocker
references:
- file: docs/coordination/inbox/for-dom/2026-06-05_claude_pack-beta-build-report.md
---
# D-16 — Test Windows local avant diffusion OwnCloud
## Decision
Aucun upload OwnCloud pour le moment.
Dom teste d'abord l'application sous Windows a partir du pack deja genere sur la
machine de build.
## Consequences immediates
- Le pack `release/Anonymisation-Windows.zip` reste local sur `192.168.1.11`.
- Aucune diffusion externe, aucun envoi OwnCloud, aucun partage beta sans GO
explicite de Dom.
- Le ZIP auto-suffisant est suffisant pour le test local.
## Installateur Inno Setup
Inno Setup doit etre telecharge/installe sur la machine Windows, mais seulement
pour preparer la suite du packaging.
Apres les tests Windows de Dom et apres GO explicite :
1. installer Inno Setup via le script prevu ;
2. relancer le packaging avec generation installateur ;
3. recalculer les SHA-256 ;
4. produire un nouveau rapport de build/package.
## Statut
En attente des tests Windows de Dom.

View File

@@ -0,0 +1,54 @@
---
from: dom
to: all
date: 2026-06-05T17:55:00+02:00
topic: d17-v11-5-chantiers-paralleles
status: closed
priority: high
references:
- decision: docs/coordination/decisions/2026-06-05_dom_d16-test-windows-avant-diffusion.md
- decision: docs/coordination/decisions/2026-06-02_dom_d13-partial-scope.md
- decision: docs/coordination/decisions/2026-06-02_dom_d14-plateforme-licence-architecture.md
---
# D-17 — v11.5 en chantiers parallèles après bêta
## Décision
Après les tests Windows de Dom et le GO bêta, la v11.5 doit être préparée en
chantiers parallèles sous pilotage Claude + agents.
Les trois chantiers prioritaires sont :
1. **GUI v6** — reprise/transposition de l'interface.
2. **D-13 complet** — protection complète des réglages avancés.
3. **Plateforme licence** — architecture `app.aivanov.fr` / client licence.
## Règle de gel bêta
Tant que Dom n'a pas terminé les tests Windows et donné son GO :
- ne pas perturber le package bêta v11 ;
- ne pas modifier le code packagé pour la bêta ;
- ne pas mélanger correctifs MVP et refonte v11.5 ;
- ne préparer que plans, découpage, inventaires et branches dédiées si besoin.
## Intention
Ces trois chantiers peuvent avancer en parallèle parce que leurs surfaces sont
distinctes si les interfaces sont contractualisées :
- GUI v6 consomme le moteur existant via API interne stable ;
- D-13 définit les règles d'accès admin et les applique à la GUI/config ;
- licence définit le serveur, le module client et le modèle de distribution.
## Point de synchronisation
Avant tout développement lourd, Claude doit produire pour Dom un plan v11.5 avec :
- découpage en branches ou agents ;
- fichiers touchés / frontières ;
- dépendances entre chantiers ;
- risques ;
- ordre de merge recommandé ;
- critères d'acceptation.

View File

@@ -0,0 +1,60 @@
---
from: dom
to: all
date: 2026-06-05T19:20:00+02:00
topic: d18-app-aivanov-dev-parallele
status: closed
priority: high
references:
- decision: docs/coordination/decisions/2026-06-02_dom_d14-plateforme-licence-architecture.md
- decision: docs/coordination/decisions/2026-06-05_dom_d16-test-windows-avant-diffusion.md
- decision: docs/coordination/decisions/2026-06-05_dom_d17-v11-5-chantiers-paralleles.md
---
# D-18 - Lancement parallele app.aivanov.fr
## Decision
Lancer en parallele le developpement de la plateforme web `app.aivanov.fr`.
Cette plateforme remplace la cible OwnCloud pour la distribution produit :
- le client se connecte ;
- le client voit ses licences ;
- le client active un poste ;
- le client telecharge l'application et les checksums ;
- Dom gere clients, licences, postes, renouvellements et revocations.
## Perimetre de la premiere tranche
MVP portail :
- FastAPI ;
- PostgreSQL cible, SQLite autorise en developpement local ;
- Jinja2 + HTMX ;
- authentification email/password ;
- pages client "Mes licences" ;
- back-office Dom ;
- API activation/check/version/download ;
- signature RSA-PSS cote serveur ;
- cle privee jamais commitee.
## Organisation
Le projet est separe du repo Windows :
- projet web : `/home/dom/ai/app_aivanov` ;
- repo Windows beta : `/home/dom/ai/anonymisation`.
Claude prend le developpement plateforme.
Qwen prend les tests, la securite, le contrat API licence et la validation RGPD.
Codex orchestre, relit et integre.
## Garde-fous
- Ne pas modifier le pack beta Windows pendant les tests Dom.
- Ne pas connecter l'EXE beta actuel a la plateforme dans cette tranche.
- Ne pas utiliser OwnCloud comme cible produit.
- Ne pas deployer publiquement `app.aivanov.fr` sans GO explicite Dom.
- Ne pas commiter de cle privee, secret Brevo, token SSH ou artefact patient.

View File

@@ -0,0 +1,55 @@
---
from: dom
to: all
date: 2026-06-05T19:30:00+02:00
topic: d19-performance-mvp-p1
status: closed
priority: blocker
references:
- decision: docs/coordination/decisions/2026-06-05_dom_d16-test-windows-avant-diffusion.md
- decision: docs/coordination/decisions/2026-06-05_dom_d18-app-aivanov-dev-parallele.md
---
# D-19 - Performance MVP bloquante
## Signal Dom
Pendant le test Windows, l'anonymisation est beaucoup trop lente pour un MVP.
Observation utilisateur :
- CPU application plafonne autour de 12 % ;
- RAM utilisee autour de 16 Go ;
- experience trop lente pour une beta exploitable.
## Decision
La performance devient un sujet P1 bloquant avant diffusion.
Le traitement ne doit pas rester mono-coeur sur les phases lourdes si une machine
multi-coeurs est disponible. Il faut identifier, mesurer et corriger les points
les plus couteux avant toute diffusion externe.
## Pistes deja identifiees
- En mode EXE PyInstaller/frozen, la rasterisation PDF semble passer en mode
sequentiel au lieu de `ProcessPoolExecutor`.
- La sortie raster PDF est activee systematiquement en batch.
- L'OCR docTR a 300 dpi peut consommer beaucoup de RAM sur PDF scannes.
- Les logs actuels ne donnent pas assez de timings par etape pour diagnostiquer
rapidement le goulot.
## Attendu
- diagnostic ligne/fichier ;
- mesure PDF natif vs PDF scanne ;
- proposition hotfix MVP faible risque ;
- criteres d'acceptation performance ;
- pas de regression RGPD : toute option rapide reste fail-closed.
## Garde-fous
- Ne pas degrader le score leak.
- Ne pas desactiver silencieusement la sortie securisee sans choix explicite.
- Ne pas melanger refonte GUI v11.5 et hotfix performance MVP.
- Le hotfix performance, si necessaire, reste sur la branche beta/hotfix dediee.