---
from: qwen
to: dom
date: 2026-06-05
topic: plan-modele-onnx
status: open
priority: normal
references:
  - inbox/for-qwen/2026-06-04_17-05_claude_nouveaux-jobs-tn-to.md
---

# Plan de sauvegarde du modèle camembert-bio-deid ONNX

## Contexte

- `models/camembert-bio-deid/onnx/model.onnx` (440 Mo) est un modèle fine-tuné
  maison, **non re-téléchargeable** depuis une source publique.
- Gitignoré via la règle `models/` (`.gitignore` ligne 32).
- Embarqué dans l'EXE au build (`.spec` datas l.23 :
  `("models/camembert-bio-deid/onnx", "models/camembert-bio-deid/onnx")`).
- Le launcher (`launcher.py:302`) vérifie sa présence au démarrage mais
  **ne le télécharge pas** — contrairement à EDS-Pseudo (`AP-HP/eds-pseudo-public`
  via edsnlp) et GLiNER (`urchade/gliner_multi_pii-v1` via HuggingFace).
- La machine de build (192.168.1.11) possède le fichier en backup.
- Produit en local en établissement de santé, **sans cloud**.
- Dom a confirmé : **pas bloquant pour la beta**, mais risque de perte définitive
  à long terme si la machine de build tombe.

## Comparaison des options

### 1. Git LFS

- **Faisabilité** : dépend du support LFS sur l'instance Gitea locale
  (`localhost:3100`). Gitea supporte nativement LFS depuis la v1.18, mais il
  faut vérifier que c'est activé sur l'instance (paramètre `LFS_START_SERVER`
  dans `app.ini`). Si désactivé : activation côté admin Gitea requise, puis
  `git lfs install` + `git lfs track "*.onnx"` + commit/push.
- **Effort** : faible si LFS déjà activé (~30 min : config + push initial du
  fichier 440 Mo). Modéré si LFS à activer sur Gitea (accès admin, redémarrage
  service).
- **Reproductibilité** : excellente. Le modèle devient versionné comme le reste
  du code. Clone = code + modèle. Historique des versions possible.
- **Contraintes RGPD** : aucun problème — le modèle ONNX ne contient pas de PII
  (c'est un modèle de NER entraîné, pas de données patient). Tracabilité
  améliorée via git log.
- **Impact repo** : +440 Mo sur le repo Gitea. Le clone passera de ~50 Mo à
  ~490 Mo — acceptable sur réseau local. LFS évite de gonfler l'historique git
  (un seul objet LFS, pas de delta).
- **Risque** : si Gitea LFS n'est pas activable ou si le stockage Gitea local
  est contraint (ex. partition /var limitée). À vérifier avant de s'engager.
- **Recommandation** : **option preferred** si LFS est disponible. C'est la
  solution la plus simple et la plus pérenne pour un repo auto-hébergé.

### 2. Script de téléchargement (`scripts/fetch_models.py`)

- **Faisabilité** : requiert une **source de téléchargement** existante ou à
  créer. Options de provenance :
  - Export HTTP interne (ex. `http://192.168.1.11/models/camembert-bio-deid.onnx`)
    — simple mais nécessite un service HTTP permanent sur la machine de build.
  - Gitea Release Asset — voir option 3.
  - HuggingFace privé — mais contrarie le principe "pas de cloud".
  - Partage réseau SMB (`\\192.168.1.11\models\model.onnx`) — fonctionne en
    réseau local établissement.
- **Effort** : modéré. Script Python (~50 lignes) avec : URL/SMB source,
  vérification SHA-256, fallback si offline, message clair si échec.
  Intégration dans le workflow de build à documenter.
- **Reproductibilité** : bonne si la source est fiable. Mais introduit une
  dépendance externe (machine 192.168.1.11 doit être accessible au moment du
  build). Si la machine est hors ligne = build bloqué.
- **Contraintes RGPD** : le transfert se fait en interne (réseau local
  établissement), pas de donnée PII dans le modèle. OK. Le SHA-256 garantit
  l'intégrité du fichier reçu.
- **Risque** : dépendance à une machine externe au repo. Si cette machine
  tombe ET qu'il n'y a pas de backup secondaire = même problème. Le script
  seul ne résout pas la sauvegarde, il la suppose.
- **Recommandation** : utile **en complément** de l'option 1 ou 3, pas en
  solution unique. Le script est une bonne pratique mais ne remplace pas un
  backup versionné.

### 3. Release asset Gitea

- **Faisabilité** : Gitea supporte les assets de release nativement. Le modèle
  serait déposé sur chaque release (`/api/v1/repos/{owner}/{repo}/releases`).
  Le script de build PowerShell (`scripts/build_windows_oneclick.ps1`) pourrait
  le récupérer via API Gitea avant le build PyInstaller.
- **Effort** : modéré à élevé. Nécessite :
  - Dépôt initial du `.onnx` comme asset (manuel ou CI).
  - Modification du script de build pour télécharger l'asset avant PyInstaller.
  - Gestion du token d'API Gitea pour le download (ou release publique sur
    Gitea local).
  - Vérification SHA-256 post-téléchargement.
- **Reproductibilité** : bonne. Chaque release a son modèle associé. Le build
  est reproductible tant que Gitea est accessible et que les assets ne sont pas
  supprimés.
- **Contraintes RGPD** : OK — transfert interne, pas de PII. Traçabilité via
  les releases Gitea (qui versionne le modèle avec le code).
- **Risque** :
  - Les assets de release ne sont pas versionnés au sens git (pas de rollback
    facile, pas de diff).
  - Si Gitea tombe, plus de source de build.
  - Complexité supplémentaire vs Git LFS pour un résultat similaire.
- **Recommandation** : viable mais **moins élégant que Git LFS** pour un repo
  auto-hébergé. À considérer si LFS n'est pas activable sur Gitea.

### 4. Statu quo documenté

- **Faisabilité** : immédiate. Il suffit d'ajouter une section dans
  `docs/build-windows-oneclick.md` expliquant où trouver le modèle et comment
  le placer avant build.
- **Effort** : minimal (~10 min de rédaction).
- **Reproductibilité** : faible. Dépend entièrement de :
  - La mémoire/opération manuelle du développeur.
  - La disponibilité de la machine 192.168.1.11.
  - L'absence de rotation/perte du fichier sur cette machine.
  Aucune garantie que le modèle sera présent dans 6 mois ou après un départ.
- **Contraintes RGPD** : OK sur le plan données (pas de PII dans le modèle),
  mais **faible sur la traçabilité** — pas de preuve de provenance, pas de hash
  vérifié, pas d'audit trail.
- **Risque** : élevé sur le long terme. C'est l'option "on verra plus tard" —
  le scénario classique de perte de modèle custom.
- **Recommandation** : acceptable **en attendant** une meilleure solution, mais
  insuffisant comme stratégie long terme. À documenter en tout cas, même si on
  choisit une autre option.

## Tableau comparatif

| Option | Faisabilité | Effort | Reproductibilité | RGPD | Recommandation |
|---|---|---|---|---|---|
| 1. Git LFS | Moyenne (dépend config Gitea) | Faible (~30 min) | Excellente | OK (pas de PII) | **Preferred** si LFS activable |
| 2. Script download | Bonne (source à créer) | Modéré (~2h) | Bonne (dépendance externe) | OK (SHA-256, interne) | Complément, pas solution unique |
| 3. Release asset Gitea | Bonne | Modéré-élevé (~3h) | Bonne | OK (traçabilité release) | Alternative si LFS indisponible |
| 4. Statu quo documenté | Immédiate | Minimal (~10 min) | Faible | OK mais faible traçabilité | OK temporaire, insuffisant long terme |

## Recommandation finale

**Approche en 2 temps :**

1. **Court terme (cette semaine)** : documenter le statu quo (option 4) dans
   `docs/build-windows-oneclick.md` avec :
   - Chemin exact du modèle : `models/camembert-bio-deid/onnx/model.onnx`
   - Localisation du backup : `192.168.1.11`
   - SHA-256 du fichier actuel (à calculer une fois) pour vérification d'intégrité
   - Procédure manuelle de copie pré-build

2. **Moyen terme (prochaines semaines)** : activer Git LFS sur Gitea local
   (option 1) et pousser le modèle. C'est la solution la plus propre pour un
   repo auto-hébergé : versionné, traçable, reproductible, sans dépendance
   externe. Vérifier au préalable :
   - `LFS_START_SERVER = true` dans `app.ini` de Gitea
   - Espace disque disponible sur la partition Gitea (440 Mo + marge)
   - Que les clones sur réseau local restent acceptables en performance

**À écarter pour l'instant** : l'option 2 (script) seule car elle suppose une
source existante, et l'option 3 (release asset) car Git LFS couvre le même
besoin avec moins de complexité.
