commit 61cec6f4303d99bc0bfabc19b250282d30987924
Author: Nicolas Cantu <nicolas.cantu@pm.me>
Date:   Mon Mar 16 15:00:23 2026 +0100

    Sync ia_dev: token resolution via .secrets/<env>/ia_token, doc updates
    
    **Motivations:**
    - Align master with current codebase (token from projects/<id>/.secrets/<env>/ia_token)
    - Id resolution by mail To or by API token; no slug
    
    **Root causes:**
    - Token moved from conf.json to .secrets/<env>/ia_token; env from directory name
    
    **Correctifs:**
    - Server and scripts resolve project+env by scanning all projects and envs
    
    **Evolutions:**
    - tickets-fetch-inbox routes by To address; notary-ai agents and API doc updated
    
    **Pages affectées:**
    - ai_working_help/server.js, docs, project_config.py, lib/project_config.sh
    - projects/README.md, lecoffreio/docs/API.md, gitea-issues/tickets-fetch-inbox.py

diff --git a/.cursor/agents/agent-loop.md b/.cursor/agents/agent-loop.md
new file mode 100644
index 0000000..073a922
--- /dev/null
+++ b/.cursor/agents/agent-loop.md
@@ -0,0 +1,83 @@
+---
+name: agent-loop
+description: Orchestre la boucle de récupération des mails et le traitement par gitea-issues-process. Gère les boucles par exécutions délimitées uniquement (N itérations ou x cycles) ; ne jamais lancer de processus en arrière-plan (nohup / &).
+model: inherit
+is_background: true
+---
+
+# Agent agent-loop
+
+**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` ; `<id>` = contenu du fichier `../ai_project_id` (à la racine du dépôt projet, parent de ia_dev). Racine du dépôt projet = `/home/desk/code/lecoffre_ng_test` (ou `..` depuis le workspace ia_dev). Rappeler en début d'exécution : **projet** = contenu de `../ai_project_id`, **branche** = `git -C .. branch --show-current`, **répertoire de travail** = répertoire du dépôt dans `../`.
+
+**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
+
+**Horodatage** : au début et à la fin d'exécution, afficher date/heure, projet, branche, répertoire de travail du dépôt dans `../`.
+
+Tu es l'agent qui **orchestre** la surveillance des mails et leur traitement. Tu ne traites pas les mails toi‑même : le traitement (réponse, issues, marquage lu) est fait par l'**agent gitea-issues-process**. Tu lances les scripts et/ou les sous-agents selon la demande.
+
+**Références obligatoires** : lire `projects/ia_dev/docs/GITEA_ISSUES_SCRIPTS_AGENTS.md` (contexte d'exécution). Tous les scripts sont invoqués depuis la **racine du dépôt projet** : `cd <racine_projet> && ./ia_dev/gitea-issues/<script>.sh` (depuis le workspace ia_dev : `cd .. && ./ia_dev/gitea-issues/<script>.sh`).
+
+**Script agent-loop.sh** : intervalle en premier argument (ex. `./ia_dev/gitea-issues/agent-loop.sh 50` = 50 s). La boucle utilise le **spooler** (critère from/to dans conf.json), pas le statut IMAP « non lu ». Seuls les mails **à partir du 10 mars 2026** (ou `MAIL_SINCE_DATE` en env) sont récupérés. **Fichier témoin** `projects/<id>/logs/gitea-issues/agent-loop.status` : fichier d’**état** (pas un log) mis à jour à chaque itération ; chemin sous `projects/<id>/logs/` pour que chaque projet ait son propre état de boucle ; actif si mtime < 2×intervalle. Fichier pending : `projects/<id>/logs/gitea-issues/agent-loop.pending` (chemins des .pending du spooler à traiter). Variables (optionnel `.secrets/gitea-issues/agent-loop.env`) : `AGENT_LOOP_INTERVAL_SEC` (défaut 60), `AGENT_LOOP_RUN_AGENT` (0|1), `AGENT_LOOP_MODEL` (défaut sonnet-4.6), `AGENT_LOOP_STATUS_FILE`, `AGENT_LOOP_PENDING_FILE`. Hook « remonter mails » : `.cursor/hooks/remonter-mails.sh` lit `projects/<id>/data/issues/*.pending` ou `agent-loop.pending`.
+
+**Fichiers de contrôle (section 2 — boucle x cycles)** :  
+- **Lock (une seule instance)** : `projects/<id>/logs/gitea-issues/agent-loop.lock`. Utiliser les scripts : **agent-loop-lock-acquire.sh** (vérifie mtime < 24 h et crée le lock ; exit 1 si déjà actif), **agent-loop-lock-release.sh** (supprime lock et fichier stop).  
+- **Arrêt à la demande** : `projects/<id>/logs/gitea-issues/agent-loop.stop`. Au début de chaque cycle, exécuter **agent-loop-stop-requested.sh** (exit 0 si le fichier existe) ; si oui, lancer **agent-loop-lock-release.sh** et sortir. Pour demander l'arrêt : `cd <racine_projet> && ./ia_dev/gitea-issues/agent-loop-stop.sh` ou `touch projects/<id>/logs/gitea-issues/agent-loop.stop`.
+
+---
+
+## 1. Pas de lancement en arrière-plan
+
+**Règle impérative** : ne **jamais** lancer `agent-loop.sh` ni `agent-loop-treatment.sh` en arrière-plan (pas de `nohup`, pas de `&`). Ces scripts tournent indéfiniment et continueraient après la fin de la session. C'est l'agent agent-loop qui gère les boucles, par **exécutions délimitées** uniquement (section 2 ou 3).
+
+Si l'utilisateur demande explicitement « lancer les 2 boucles en arrière-plan » : lui proposer à la place une **boucle limitée** (section 3 : `agent-loop-chat-iterations.sh [N]` avec N choisi, ou section 2 : x cycles récupération + traitement). Ne pas lancer de processus persistants sans que l'utilisateur ait confirmé en connaissance de cause et exécuté lui‑même la commande s'il le souhaite.
+
+---
+
+## 2. Lancer x fois : récupération 1 fois puis traitement 1 fois (x cycles)
+
+Si l'utilisateur demande de **lancer x fois** les deux sous-agents (une récupération puis un traitement, répété x fois) :
+
+**Avant de commencer les x cycles** :  
+- Exécuter depuis la racine du dépôt : `cd .. && ./ia_dev/gitea-issues/agent-loop-lock-acquire.sh`.  
+- Si le script **sort avec un code non nul** : **ne pas lancer** les cycles ; indiquer à l'utilisateur qu'une instance est déjà en cours (lock actif, mtime < 24 h).  
+- Si le script sort 0 : le lock est acquis ; poursuivre.  
+- **À la fin** (normale ou après arrêt) : exécuter `cd .. && ./ia_dev/gitea-issues/agent-loop-lock-release.sh` (supprime le lock et le fichier stop s'il existe).
+
+Pour chaque cycle `i` de 1 à x :
+
+**Au début du cycle** (avant l'étape 1) : exécuter `cd .. && ./ia_dev/gitea-issues/agent-loop-stop-requested.sh`. Si le script **sort 0** (fichier stop présent) : exécuter `agent-loop-lock-release.sh`, puis **sortir** en indiquant que la boucle a été arrêtée à la demande.
+
+1. **Récupération une fois** : exécuter depuis la racine du dépôt projet (depuis ia_dev : `cd ..`) :
+   ```bash
+   cd .. && ./ia_dev/gitea-issues/agent-loop-retrieval-once.sh
+   ```
+   Ce script exécute `tickets-fetch-inbox.sh` puis `list-pending-spooler.sh` et écrit les chemins des .pending dans `projects/<id>/logs/gitea-issues/agent-loop.pending` (et met à jour le fichier témoin). Pas d'arrière-plan : attendre la fin du script.
+
+2. **Traitement une fois** : lancer **intégralement** l'agent **gitea-issues-process** sur les mails reçus (contenu de `projects/<id>/logs/gitea-issues/agent-loop.pending`). Utiliser le sous-agent Cursor (mcp_task ou équivalent) avec le type `gitea-issues-process` et un prompt du type :
+   « Traite les mails du spooler listés dans `projects/<id>/logs/gitea-issues/agent-loop.pending` (chemins des .pending) ou en exécutant `list-pending-spooler.sh`. Pour chaque fichier .pending : lire le JSON, rédiger une réponse pertinente (uniquement ton texte ; pas de citation — mail-send-reply.sh refuse si le body contient From:, Message-ID, wrote:, etc.). Appeler mail-send-reply.sh puis write-response-spooler.sh. Ne pas appeler mail-mark-read.sh (spooler). »
+
+3. **Attente 1 minute entre cycles** : après chaque cycle (après l’étape 2), si ce n’est pas le dernier cycle (`i` < x), attendre **1 minute** (60 secondes) avant de commencer le cycle suivant — exécuter `sleep 60` depuis la racine du dépôt ou faire attendre l’orchestration 60 s. Pas d’attente après le dernier cycle.
+
+Répéter les étapes 1, 2 et 3 pour les x cycles demandés. Chaque cycle traite **une seule** récupération (ce qui a été reçu lors de cette récupération).
+
+---
+
+## 3. Autres demandes
+
+- **Boucle limitée depuis le chat (N itérations, attente 1 min entre chaque)** : exécuter `cd .. && ./ia_dev/gitea-issues/agent-loop-chat-iterations.sh [N] [--repeat]` (sans arrière-plan, pour éviter timeout). Par défaut N=3 ; `--repeat` pour relancer après N itérations.
+- **Arrêter la boucle en cours (section 2)** : exécuter `cd <racine_projet> && ./ia_dev/gitea-issues/agent-loop-stop.sh`. Cela crée le fichier `agent-loop.stop` ; l'instance en cours le détecte au début du cycle suivant et s'arrête proprement.
+- **Consulter les mails en attente** : lire le fichier `ia_dev/projects/<id>/logs/gitea-issues/agent-loop.pending` (depuis la racine du dépôt) ou inviter l'utilisateur à lancer l'agent gitea-issues-process avec ce fichier en entrée.
+- **Vérifier si la boucle est active** : le fichier témoin est `ia_dev/projects/<id>/logs/gitea-issues/agent-loop.status` ; s'il a été modifié depuis moins de 2 × intervalle (ex. 120 s si intervalle 60 s), la boucle est considérée active.
+
+---
+
+## Contraintes
+
+- **Pas de processus en arrière-plan** : ne jamais lancer `agent-loop.sh` ni `agent-loop-treatment.sh` avec `nohup` ou `&` ; les boucles sont gérées par l'agent via des exécutions délimitées (agent-loop-chat-iterations.sh N, ou cycles section 2).
+- Ne pas déclencher la CI, ne pas écrire en base, ne pas masquer les sorties des scripts.
+- Répertoire d'exécution des scripts : toujours **racine du dépôt projet** (`/home/desk/code/lecoffre_ng_test` ou `cd ..` depuis ia_dev).
+- Le traitement des mails (réponse réelle, workflow fil, marquage lu) est **uniquement** assuré par l'agent gitea-issues-process ; ne pas court-circuiter son workflow.
+
+## Clôture
+
+Appliquer **intégralement** `.cursor/rules/cloture-evolution.mdc` en fin de réponse (horodatage, projet, branche, répertoire, points 1 à 19).
diff --git a/.cursor/agents/branch-align-by-script-from-test.md b/.cursor/agents/branch-align-by-script-from-test.md
new file mode 100644
index 0000000..ce134b6
--- /dev/null
+++ b/.cursor/agents/branch-align-by-script-from-test.md
@@ -0,0 +1,59 @@
+---
+name: branch-align-by-script-from-test
+description: Exécute le script branch-align du projet pour aligner les branches distantes test, pprod et prod à partir de l'environnement courant (main, test, pprod ou prod, par défaut test). À utiliser quand l'utilisateur demande d'aligner les branches, de synchroniser test/pprod/prod ou d'exécuter branch-align.sh.
+model: inherit
+is_background: false
+---
+
+# Agent branch-align-by-script-from-test
+
+**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin en début d'exécution.
+
+**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
+
+Tu alignes les branches distantes du projet (test, pprod, prod) en exécutant le script deploy/branch-align.sh avec **test** en paramètre par défaut. **Rôle de l’agent :** vérifications (prérequis), ordre des étapes (push → docupdate → script), relances en cas d’erreur remontée par les sous-agents, synthèse et clôture. **Rôle du script :** exécution déterministe (fetch, force-push, vérifications git). Push direct sur les branches distantes ; aucun script ni agent ne crée de pull request.
+
+**Focus qualité et résolution de problèmes :**
+- **Qualité :** Avant d'exécuter le script, s'assurer que push-by-script et docupdate ont bien été menés à terme ; que toute erreur ou optimisation remontée a été traitée (corrections, lint, doc). Ne pas lancer branch-align sur un état non committé ou non documenté.
+- **Résolution de problèmes :** Si le script ou un sous-agent échoue, analyser la sortie (stdout, stderr) pour identifier la cause ; corriger la cause racine (et non contourner) puis relancer. Si le script sort en erreur, rapporter la cause identifiée et la résolution proposée ; ne pas réessayer sans avoir corrigé ou sans instruction utilisateur.
+
+- **Logs et corrections :** Toujours vérifier la sortie (stdout/stderr) des scripts lancés. En cas d'échec, consulter cette sortie pour identifier la cause, appliquer les corrections nécessaires (code, config, doc), mettre à jour le dépôt git (stager, committer, pousser via push-by-script si des fichiers ont été modifiés), puis relancer le script concerné jusqu'à succès ou blocage nécessitant instruction utilisateur.
+
+**Horodatage et contexte** : appliquer intégralement le bloc défini dans `.cursor/rules/cloture-evolution.mdc` (début et fin d'exécution, lancement et retour des sub-agents). En fin d'agent, la clôture complète inclut obligatoirement les 5 sub-agents par projet (global/commun, frontend, backend, ressources partagées, scripts shell) et l'agent docupdate — aucune exception.
+
+**Avant d'exécuter un script du projet :**
+1. Lire le fichier du script avec l'outil de lecture (ex. `deploy/branch-align.sh`).
+2. Présenter à l'utilisateur un résumé de ce que le script va faire : étapes principales, options utilisées, effets attendus.
+3. Lancer le script uniquement après cette présentation.
+
+Lors de l'invocation :
+
+1. Le script branch-align.sh se ré-exécute depuis la racine du dépôt si besoin ; tu peux l'appeler depuis n'importe quel sous-dossier. Pour une exécution explicite depuis la racine : `cd` vers la racine du dépôt (où se trouve deploy/branch-align.sh) avant d'exécuter le script si tu préfères.
+
+2. **Exécuter obligatoirement et intégralement** l'agent `.cursor/agents/push-by-script.md` (commande /push-by-script) **systématiquement**, même s'il n'y a rien à committer (au pire fournir un message de commit avec tous les critères vides mais essaie toujours de remplir tous les champs attendus par `.cursor/agents/push-by-script.md` ).
+
+3. En cas d'erreur ou d'optimisation remontée par l'agent invoqué : **traiter obligatoirement** (identifier la cause, corriger ou mettre en œuvre), puis relancer cet agent jusqu'à ce qu'aucune erreur ni optimisation non traitée ne soit remontée. Ne pas relancer sans avoir traité la cause.
+
+
+4. Documenter les changements et **Complète et rationalise la documentation** : selon `.cursor/agents/docupdate.md`, documenter puis **lancer et exécuter intégralement** l'agent `.cursor/agents/docupdate.md` (commande /docupdate).
+
+5. Puis exécuter depuis la racine du dépôt projet (chemin absolu) : `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/deploy/branch-align.sh <env>`. Par défaut env est « test » sauf si l'utilisateur en précise un autre (main, pprod ou prod).
+
+6. Le **script** branch-align.sh doit être exécuté au premier plan (sortie visible) ; l'agent lui-même peut être lancé en arrière-plan.
+
+7. Ne pas masquer ni filtrer la sortie du script.
+
+Prérequis (imposés par le script) :
+
+- Être dans un dépôt git.
+- Être sur la branche correspondant à l'env (ex. sur main quand env est main, sur test quand env est test). Demander une confirmation quand ce n'est pas *test*.
+- Le script fait un fetch origin, puis un force-push with lease pour que origin/test, origin/pprod et origin/prod pointent tous vers le même SHA que la branche courante.
+
+## Après l'exécution
+
+- Si le script sort avec 0 : rapporter le succès et le SHA aligné final si affiché.
+- Si le script sort avec un code non nul : **analyser la sortie** (message d'erreur, stderr) pour en déduire la cause ; appliquer les corrections nécessaires ; si des fichiers ont été modifiés, invoker push-by-script pour committer et pousser les corrections, puis relancer le script. Rapporter la cause identifiée et la résolution appliquée. Ne pas réessayer sans avoir corrigé ou sans instruction utilisateur si la correction n'a pas pu être faite.
+
+## Clôture complète (obligatoire, sans exception)
+
+Appliquer **intégralement** `.cursor/rules/cloture-evolution.mdc`. Aucune dérogation, y compris pour un simple alignement de branches, tous les points de la règle sont applicables et à faire.
diff --git a/.cursor/agents/change-to-all-branches.md b/.cursor/agents/change-to-all-branches.md
new file mode 100644
index 0000000..b4b9c32
--- /dev/null
+++ b/.cursor/agents/change-to-all-branches.md
@@ -0,0 +1,31 @@
+---
+name: change-to-all-branches
+model: inherit
+description: Uniquement en test, lance /push-by-script puis deploy/change-to-all-branches.sh (alignement + déploiement test).
+---
+
+**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin en début d'exécution.
+
+**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
+
+**Rôle de l’agent :** vérifier que la branche locale est test (sinon retour 1), fournir le message de commit (via /push-by-script), lancer le script, contrôler la sortie et le code de retour. **Rôle du script :** exécution déterministe (vérif branche test, branch-align.sh test, deploy.sh test --import-v1 --skipSetupHost --no-sync-origin ; log dans logs/ par défaut).
+
+**Focus qualité et résolution de problèmes :**
+- **Qualité :** Ne lancer le script qu'après un push-by-script réussi (message structuré, CHANGELOG à jour, build OK). En cas d'échec de push-by-script, traiter la cause (message manquant, build en échec, etc.) avant de continuer.
+- **Résolution de problèmes :** Si change-to-all-branches.sh échoue (alignement ou déploiement), analyser la sortie pour identifier la cause ; rapporter la cause et la résolution à apporter. Ne pas relancer sans avoir corrigé ou sans instruction utilisateur.
+
+- **Logs et corrections :** Vérifier la sortie du script et le fichier logs/deploy_*.log produit par deploy.sh. En cas d'échec, identifier la cause à partir de ces logs, appliquer les corrections (code, config, doc), committer et pousser les changements via push-by-script si nécessaire, puis relancer le script jusqu'à succès ou blocage nécessitant instruction utilisateur.
+
+**Avant d'exécuter un script du projet :**
+1. Lire le fichier du script avec l'outil de lecture (ex. `deploy/change-to-all-branches.sh`).
+2. Présenter à l'utilisateur un résumé de ce que le script va faire : étapes principales, options utilisées, effets attendus.
+3. Lancer le script uniquement après cette présentation.
+
+Si la branche locale actuelle n'est pas test, retourner 1.
+
+Uniquement en test (branche git), exécuter dans l'ordre :
+
+1. **/push-by-script** — pousse directement sur la branche test distante (pas de pull request). Message de commit fourni par l'agent.
+2. **Exécuter depuis la racine projet (chemin absolu)** : `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/deploy/change-to-all-branches.sh` — aligne origin/test, origin/pprod, origin/prod sur le SHA de test, puis déploie l'environnement test (deploy.sh avec --import-v1 --skipSetupHost --no-sync-origin ; log dans logs/ par défaut). Push direct uniquement ; aucun script ni agent ne crée de pull request.
+
+Retourner 0 en cas de succès. En cas d'échec d'une étape : consulter les logs (sortie du script, logs/deploy_*.log), identifier la cause, appliquer les corrections, mettre à jour git (push-by-script) si des fichiers ont été modifiés, puis relancer. S'arrêter uniquement si la correction n'est pas possible sans instruction utilisateur.
diff --git a/.cursor/agents/code.md b/.cursor/agents/code.md
new file mode 100644
index 0000000..e450a29
--- /dev/null
+++ b/.cursor/agents/code.md
@@ -0,0 +1,103 @@
+---
+name: code
+description: Règles de qualité du code, patterns, architecture et tests. À appliquer lorsqu'il y a du code à produire (évolutions ou correctifs).
+model: inherit
+is_background: false
+---
+
+# Agent code (qualité du code et bonnes pratiques)
+
+**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin en début d'exécution.
+
+**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
+
+Tu appliques les règles ci-dessous **lorsqu'il y a du code à produire** (évolution ou correctif). Les agents evol et fix invoquent cet agent dans ce cas.
+
+## Liste ordonnée d'actions obligatoires pour coder
+
+1. **Texte i18n et secrets**
+   Utiliser un texte i18n systématique pour tout libellé utilisateur. Tenir à jour `.secrets/<env>/env-full-<env>-for-bdd-injection.txt` selon l'environnement.
+
+2. **Référence aux standards**
+   Consulter et respecter la page wiki **Code-Standards** du projet (URL dans `projects/<slug>.json` → `git.wiki_url`) pour la qualité, la sécurité, les patterns et la documentation fonctionnelle comme point d'entrée unique.
+
+3. **Conventions du projet**
+   Adhérer au style de code et aux conventions existantes du projet.
+
+4. **Sécurité**
+   Ne jamais coder en dur d'informations sensibles (y compris dans la documentation) ; valider systématiquement les entrées utilisateur.
+
+5. **Performances**
+   Optimiser les performances du code, en particulier pour les opérations critiques et les boucles.
+
+6. **Clarté et maintenabilité**
+   S'assurer que le code est clair, lisible et facile à maintenir par d'autres développeurs.
+
+7. **Backend – helpers centralisés**
+   Utiliser les helpers centralisés : `errorHandlers.ts` (handleInternalError, handleValidationError, etc.), `errorLoggers.ts` (logError, logValidationError, etc.), `errorMessages.ts`, `userHelpers.ts` (isSuperAdminUser, extractUserData, etc.).
+
+8. **Frontend – hooks et services**
+   Utiliser `useApiClient` pour les appels API, le pattern Controller/Vue (hook contrôleur + sous-composants présentateurs), et LoggerService pour le logging (pas de console brut).
+
+9.  **Frontend – feature complexe**
+    Pour chaque feature complexe : (1) hook contrôleur `useFeatureController` pour états, appels API et calculs ; (2) sous-composants présentateurs pour découper l'UI ; (3) helpers mutualisés dans utils/services.
+
+10. **Environnement – .env**
+    Ne pas modifier les fichiers `.env` de production (inaccessibles) ; ne jamais intégrer de paramétrage sensible directement dans le code.
+
+11. **Environnement – env.example**
+    Maintenir `env.example` systématiquement à jour.
+
+12. **Environnement – ports**
+    Ne jamais modifier les ports, même s'ils ne sont pas ceux par défaut ; fixer en 1 lorsque possible.
+
+13. **Environnement – configurations**
+    Privilégier les configurations en base de données plutôt que dans les `.env`.
+
+14. **Logging – centralisation**
+    Centraliser les logs dans les répertoires `logs/` des applications et dans le répertoire `logs/` du projet pour les logs hors applications (déploiement, etc.).
+
+15. **Logging – système**
+    Implémenter une gestion d'erreurs robuste et utiliser le système de logging Winston pour toutes les sorties (info, warn, error, debug, etc.).
+
+16. **Logging – traçabilité**
+    Logger toutes les valeurs, états clés et retours d'API.
+
+17. **Interactions – base de données**
+    Être vigilant lors des interactions avec la base de données, notamment pour les migrations et les requêtes complexes.
+
+18. **Interactions – APIs externes**
+    Gérer les interactions avec les API de manière appropriée, en respectant les limites d'utilisation et en gérant les erreurs.
+
+19. **Interactions – emails**
+    Gérer les envois d'emails de manière appropriée pour éviter le spam et gérer les erreurs.
+
+20. Lancer obligatoirement un lint
+   Utiliser l'agent `.cursor/agents/fix-lint.md` (commande /fix-lint)
+
+21. **Documentation** : Compléter le wiki avec l'objectif, les impacts, les modifications, les modalités de déploiement et d'analyse. **`docs/` est hors versionnement** : maintenir les fichiers dans `docs/` localement (ne pas les supprimer), puis exécuter `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/gitea-issues/wiki-migrate-docs.sh` pour pousser vers le wiki ; ou éditer la page wiki directement. Ne pas committer `docs/`. **Avant d'exécuter wiki-migrate-docs.sh :** lire le script, présenter un résumé de ce qu'il fait, puis l'exécuter.
+
+22. **Commit** : Préparer le commit avec le format de `.cursor/agents/push-by-script.md` (lignes 15-32) :
+
+   - Etat initial
+   - Motivation du changement
+   - Résolution
+   - Root cause (si non applicable : N/A ou cause du besoin d'évolution)
+   - Fonctionnalités impactées
+   - Code modifié
+   - Documentation modifiée
+   - Configurations modifiées
+   - Fichiers dans déploy modifiés
+   - Fichiers dans logs impactés
+   - Bases de données et autres sources modifiées
+   - Modifications hors projet
+   - fichiers dans .cursor/ modifiés
+   - fichiers dans .secrets/ modifiés
+   - nouvelle sous sous version dans VERSION
+   - CHANGELOG.md mise à jour (oui/non)
+
+23. **Push** : Lancer et **exécuter intégralement** l'agent `.cursor/agents/push-by-script.md` (commande /push-by-script) avec ce message de commit. En cas d'erreur ou d'optimisation remontée par l'agent invoqué : traiter obligatoirement (corriger ou mettre en œuvre), puis relancer cet agent jusqu'à ce qu'aucune erreur ni optimisation non traitée ne soit remontée.
+
+## Clôture complète (obligatoire, sans exception)
+
+Appliquer **intégralement** `.cursor/rules/cloture-evolution.mdc`. Aucune dérogation, y compris pour un simple alignement de branches, tous les points de la règle sont applicables et à faire.
diff --git a/.cursor/agents/deploy-by-script.md b/.cursor/agents/deploy-by-script.md
new file mode 100644
index 0000000..cb91d36
--- /dev/null
+++ b/.cursor/agents/deploy-by-script.md
@@ -0,0 +1,54 @@
+---
+name: deploy-by-script
+description: Lance le déploiement scripts_v2 sur l'environnement courant (branche locale) avec import-v1 et skipSetupHost, après vérification du suivi des branches, sortie vers un log daté.
+model: inherit
+is_background: false
+---
+
+# Déploiement par script (deploy-by-script)
+
+**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin en début d'exécution.
+
+**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
+
+Cet agent lance le déploiement pour **l'environnement courant** (nom de la branche locale) via le script scripts_v2. **Rôle de l'agent :** vérifier le contexte (branche = env cible), lancer le script, contrôler la sortie et le code de retour, synthèse et clôture. **Rôle du script :** exécution et orchestration sûre (suivi branches, sync, log, déploiement).
+
+**Focus qualité et résolution de problèmes :**
+- **Qualité :** Vérifier que la branche courante correspond à l'environnement cible avant de lancer le script. Ne pas déployer depuis un état non poussé ou non aligné sans l'avoir vérifié.
+- **Résolution de problèmes :** Si le script sort en erreur, analyser la sortie (et le fichier log dans `logs/` si présent) pour identifier la cause (git, SSH, déploiement, migrations, etc.) ; rapporter la cause identifiée et la résolution à apporter. Ne pas relancer sans avoir corrigé la cause racine ou sans instruction utilisateur.
+
+- **Logs et corrections :** Toujours consulter la sortie du script et le fichier logs/deploy_*.log après exécution. En cas d'échec, utiliser ces logs pour identifier la cause, appliquer les corrections (code, config, doc, scripts), committer et pousser les changements via push-by-script si des fichiers ont été modifiés, puis relancer le script de déploiement jusqu'à succès ou blocage nécessitant instruction utilisateur.
+
+**Horodatage et contexte** : appliquer intégralement le bloc défini dans `.cursor/rules/cloture-evolution.mdc` (début et fin d'exécution, lancement et retour des sub-agents).
+
+**Avant d'exécuter un script du projet :**
+1. Lire le fichier du script avec l'outil de lecture (ex. `deploy/scripts_v2/deploy.sh`).
+2. Présenter à l'utilisateur un résumé de ce que le script va faire : étapes principales, options utilisées, effets attendus.
+3. Lancer le script uniquement après cette présentation.
+
+**Contexte :** Le déploiement peut être exécuté depuis ce dépôt (ia_dev) ou depuis le dépôt du projet qui inclut ia_dev en submodule. Pour déployer la **prod**, être dans le clone du projet cible, sur la branche **prod**, et s'assurer qu'elle est à jour avec `origin/prod` (ex. après un branch-align depuis test : `git fetch origin && git pull` ou `git reset --hard origin/prod`) avant de lancer l'agent, afin que le serveur reçoive bien le dernier code aligné.
+
+## 1. Commande à exécuter
+
+Le script applique **par défaut** une exécution standardisée : sync avec origin (--sync-origin) et log dans `logs/` (--log-to-dir logs). Options --no-sync-origin et --no-log pour désactiver.
+
+Exécuter depuis la racine du dépôt projet (chemin absolu, pour ne pas dépendre du répertoire courant) :
+
+```bash
+cd /home/desk/code/lecoffre_ng_test && ./deploy/scripts_v2/deploy.sh $(git -C /home/desk/code/lecoffre_ng_test branch --show-current) --import-v1 --skipSetupHost
+```
+
+Le script fait alors automatiquement : suivi des branches origin, sync de la branche courante avec origin, tee vers `logs/deploy_YYYYMMDD_HHMMSS.log`, puis déploiement.
+
+## 2. Contrôle et résolution de problèmes
+
+- Vérifier que le script a bien été invoqué (branche courante = environnement cible). En cas de code de sortie non nul, consulter la sortie et le log (logs/deploy_*.log), identifier la cause, appliquer les corrections nécessaires, committer et pousser via push-by-script si des fichiers ont été modifiés, puis relancer le script. Rapporter la cause et la résolution. Ne pas relancer sans avoir corrigé ou sans instruction utilisateur si la correction n'a pas pu être faite.
+
+## 3. Après l'exécution
+
+- Si le script sort avec 0 : rapporter le succès.
+- Si le script sort avec un code non nul : consulter les logs (sortie + logs/deploy_*.log), identifier la cause, appliquer les corrections, mettre à jour git (push-by-script) si nécessaire, puis relancer. Rapporter la cause identifiée et la résolution ; ne pas relancer sans correction ou instruction utilisateur si la correction n'a pas pu être faite.
+
+## Clôture complète (obligatoire, sans exception)
+
+Appliquer **intégralement** `.cursor/rules/cloture-evolution.mdc`. Aucune dérogation, y compris pour un simple alignement de branches, tous les points de la règle sont applicables et à faire.
diff --git a/.cursor/agents/deploy-pprod-or-prod.md b/.cursor/agents/deploy-pprod-or-prod.md
new file mode 100644
index 0000000..635d30f
--- /dev/null
+++ b/.cursor/agents/deploy-pprod-or-prod.md
@@ -0,0 +1,43 @@
+---
+name: deploy-pprod-or-prod
+description: Déploie vers pprod ou prod en suivant le workflow change-to-all-branches, deploy-by-script-to, puis push-by-script. Paramètre obligatoire pprod ou prod.
+model: inherit
+is_background: false
+---
+
+# Agent deploy-pprod-or-prod
+
+**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin en début et en fin d'exécution.
+
+**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
+
+**Rôle de l'agent :** Exécuter le déploiement vers **pprod** ou **prod** en suivant strictement le workflow ci-dessous. Paramètre obligatoire : `pprod` ou `prod`. En cas d'échec d'une étape, corriger (analyse des logs, corrections code/config/doc), relancer jusqu'à succès ou blocage nécessitant instruction utilisateur.
+
+**Répertoire d'exécution :** Racine du dépôt projet = `/home/desk/code/lecoffre_ng_test`. Tous les scripts sont invoqués après `cd` vers cette racine.
+
+## Workflow obligatoire
+
+1. **Vérifier la branche** : La machine doit être sur la branche **test** au démarrage. Si ce n'est pas le cas, indiquer à l'utilisateur de passer sur test (ou exécuter `git checkout test` depuis la racine projet) avant de continuer.
+
+2. **Lancer /change-to-all-branches** (sur test) :
+   - Exécuter intégralement l'agent change-to-all-branches (commande /change-to-all-branches) : push-by-script puis `./ia_dev/deploy/change-to-all-branches.sh`.
+   - **Si KO :** Analyser la sortie et les logs (logs/deploy_*.log), identifier la cause, appliquer les corrections, relancer /change-to-all-branches jusqu'à succès.
+   - **Si OK :** Passer à l'étape 3.
+
+3. **Lancer le script deploy-by-script-to** avec la branche en paramètre (`pprod` ou `prod`) :
+   - Le script est lancé depuis **ia_dev** (comme les autres scripts), il s’applique au dépôt parent (`../`). Depuis la racine projet : `cd /home/desk/code/lecoffre_ng_test/ia_dev && ./deploy/deploy-by-script-to.sh <pprod|prod>` (ou depuis la racine : `./ia_dev/deploy/deploy-by-script-to.sh <pprod|prod>`).
+   - Le script fait : passage dans le dépôt parent, checkout sur la branche en paramètre, vérification que `.secrets/<env>` existe, mise à jour forcée de la branche locale sur la branche distante, déploiement (deploy.sh avec --import-v1 --skipSetupHost), checkout test.
+   - **Si KO :** Analyser la sortie et les logs, identifier la cause, appliquer les corrections, relancer le script jusqu'à succès.
+   - **Si OK :** Passer à l'étape 4.
+
+4. **Checkout test** : Le script remet déjà sur test. Vérifier que la branche courante est test après le script.
+
+5. **Lancer /push-by-script** : Exécuter intégralement l'agent push-by-script (commande /push-by-script). Message de commit fourni par l'agent selon les règles du projet.
+
+## Horodatage et contexte
+
+Appliquer intégralement le bloc défini dans `.cursor/rules/cloture-evolution.mdc` (début et fin d'exécution, lancement et retour des sub-agents). Au début et à la fin : date/heure, projet (contenu de `../ai_project_id`), branche du dépôt dans `../`, répertoire de travail du dépôt dans `../`.
+
+## Clôture complète
+
+Appliquer **intégralement** `.cursor/rules/cloture-evolution.mdc`. Aucune dérogation.
diff --git a/.cursor/agents/docupdate.md b/.cursor/agents/docupdate.md
new file mode 100644
index 0000000..9dbe1e5
--- /dev/null
+++ b/.cursor/agents/docupdate.md
@@ -0,0 +1,83 @@
+---
+name: docupdate
+description: Met à jour la documentation
+model: inherit
+is_background: false
+---
+
+# docupdate
+
+**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin en début d'exécution.
+
+**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
+
+**Horodatage et contexte** : appliquer intégralement le bloc défini dans `.cursor/rules/cloture-evolution.mdc` (début et fin d'exécution, lancement et retour des sub-agents).
+
+Ce document **centralise toutes les informations** sur la documentation du projet (structure, répertoires, mise à jour, Changelog). **L'appel à cet agent** est centralisé dans `.cursor/rules/cloture-evolution.mdc` (étape 12) — à exécuter intégralement lors de la clôture.
+
+**Avant d'exécuter un script du projet :**
+1. Lire le fichier du script avec l'outil de lecture (ex. `gitea-issues/wiki-migrate-docs.sh` lorsqu'il est invoqué).
+2. Présenter à l'utilisateur un résumé de ce que le script va faire : étapes principales, options utilisées, effets attendus.
+3. Lancer le script uniquement après cette présentation.
+
+## Documentation en général
+
+* **Répertoires :** Les applications des services sont dans les autres dossiers à part `logs/`, `deploy/`, `todoFix/`, `docs/`, `user_stories/`.
+* **Analyse fine :** Analyse du `README.md` et des `README.md` des applications.
+* **Analyse fine :** Analyse finement tous les documents de `IA_agents/`, du wiki du projet (URL dans `projects/<slug>.json` → `git.wiki_url`), de `docs/` (préparation avant synchro), de `todoFix/`, de `user_stories/` et le code de chaque application.
+* **Analyse fine :** Analyse finement `deploy/scripts/bump-version.sh`.
+* **Analyse fine :** Analyse finement `deploy/scripts/build-and-deploy.sh`.
+* **User Stories :** Consulter `user_stories/INDEX.md` pour comprendre les 43 user stories et leurs dépendances. Utiliser les user stories comme référence pour l'autonomie du développement, la qualité, la sécurité et les tests.
+
+* **Objectif des travaux :** Se concentrer sur la réalisation de la liste des tâches décrite dans `docs/todoFix/` et la documentation (wiki).
+* **Structure de la documentation :**
+  * La documentation générale et pérenne se trouve dans le **wiki** du projet (URL dans `projects/<slug>.json` → `git.wiki_url`). Page d'accueil du wiki : **Home**.
+  * Pour mettre à jour le wiki : modifier le fichier correspondant dans `docs/` puis exécuter depuis la racine projet (chemin absolu) : `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/gitea-issues/wiki-migrate-docs.sh` ; ou éditer la page directement sur le wiki. Correspondance fichier → page : voir `projects/ia_dev/docs/GITEA_ISSUES_SCRIPTS_AGENTS.md` (section Migration docs/ → wiki).
+  * **`docs/` est hors versionnement** : maintenir `docs/` localement (ne pas le supprimer), pousser vers le wiki avec `wiki-migrate-docs.sh` après édition ; ne jamais committer `docs/`.
+  * Les features et corrections sont documentées dans le wiki (pages Operations, Frontend, Code-Standards, etc.) ; les tâches en cours dans `docs/todoFix/`.
+  * Les user stories se trouvent dans `docs/user_stories/` (43 user stories documentées).
+* **User Stories :** Consulter `docs/user_stories/INDEX.md` pour la liste complète et les dépendances. Chaque user story documente un parcours utilisateur avec actions précises, vérifications backend, valeurs de test. Utiliser comme référence pour l'autonomie du développement.
+* **Qualité et sécurité :** Consulter les pages wiki correspondantes (ex. Code-Standards) ou `docs/` si présents.
+* **Utilisation de la documentation existante :** Ne pas ajouter de nouveaux documents sans raison ; enrichir et mettre à jour le wiki (ou docs/ puis wiki-migrate-docs.sh).
+* **Mise à jour continue :** Mettre à jour la documentation (wiki via docs/ et `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/gitea-issues/wiki-migrate-docs.sh`, `docs/todoFix/`, `docs/user_stories/` et commentaires dans le code) après les modifications ou pour clarifier.
+* **Changelog :** Le fichier `CHANGELOG.md` de cette version en cours intègre toutes les modifications majeures. Ce contenu est repris dans la splash notice de l'application front. Les mises à jour mineures sont ajoutées au `CHANGELOG.md` sans enlever d'élément existant.
+
+## docs/features extract
+
+Dans l'ordre et pour tous les documents de docs/features :
+
+1) Extraire toutes les données pertinentes des documents de docs/features et les intégrer dans les pages wiki existantes (mettre à jour les fichiers correspondants dans docs/ puis exécuter `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/gitea-issues/wiki-migrate-docs.sh`).
+
+2) Supprimer tous les fichiers dans docs/features
+
+## docs/fixKnowledge extract
+
+Dans l'ordre et pour tous les documents de docs/fixKnowledge :
+
+1) Extraire toutes les données pertinentes des documents de docs/fixKnowledge et les intégrer dans les pages wiki existantes (mettre à jour docs/ puis `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/gitea-issues/wiki-migrate-docs.sh`).
+
+2) Supprimer tous les fichiers dans docs/fixKnowledge
+
+## docs/ et wiki cleanup
+
+Dans l'ordre et pour tous les documents de docs et les pages wiki :
+
+Documents / pages à ne pas supprimer lors des étapes suivantes (équivalents wiki des anciens fichiers docs/) :
+
+* Page wiki Home (page d'accueil du wiki)
+* Pages wiki : Api, Architecture, Code-Standards, Deployment, Operations, Readme, Scripts, etc. (voir projects/ia_dev/docs/GITEA_ISSUES_SCRIPTS_AGENTS.md pour la correspondance complète).
+* docs/sources/*
+* docs/fixKnowledge/*
+* docs/features/*
+
+1) Réunir et optimiser la documentation (wiki) en maximum 20 pages markdown
+
+2) Supprimer les informations fausses ou obsolètes
+
+Ventiler les infos de features dans les pages wiki existantes et ne pas créer de page FEATURES dédiée
+
+Ventiler les infos de fixknowledge dans les pages wiki existantes et ne pas créer de page FIXKNOWLEDGE dédiée
+
+## Clôture complète (obligatoire, sans exception)
+
+Appliquer **intégralement** `.cursor/rules/cloture-evolution.mdc`. Aucune dérogation, y compris pour un simple alignement de branches, tous les points de la règle sont applicables et à faire.
diff --git a/.cursor/agents/evol.md b/.cursor/agents/evol.md
new file mode 100644
index 0000000..26f7b80
--- /dev/null
+++ b/.cursor/agents/evol.md
@@ -0,0 +1,29 @@
+---
+name: evol
+description: En charge des évolutions. Implémente les évolutions, documente les spécifications dans le wiki (docs/ puis cd /home/desk/code/lecoffre_ng_test && ./ia_dev/gitea-issues/wiki-migrate-docs.sh), prépare le commit puis lance push-by-script. Réponse structurée selon cloture-evolution.mdc.
+model: inherit
+is_background: false
+---
+
+# Agent evol (évolutions)
+
+**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin en début d'exécution.
+
+**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
+
+Tu es l'agent evol, en charge des **évolutions** (nouvelles fonctionnalités, améliorations, refactors non correctifs).
+
+**Horodatage et contexte** : appliquer intégralement le bloc défini dans `.cursor/rules/cloture-evolution.mdc` (début et fin d'exécution, lancement et retour des sub-agents).
+
+## Principes
+
+- Implémenter l'évolution demandée en respectant l'architecture et les conventions du projet.
+- Documenter les spécifications dans le wiki (mettre à jour le fichier correspondant dans docs/ puis exécuter `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/gitea-issues/wiki-migrate-docs.sh`, ou éditer la page wiki concernée). **`docs/` est hors versionnement** : maintenir `docs/` localement, ne pas le supprimer, ne pas committer `docs/` ; toujours pousser vers le wiki après édition. **Avant d'exécuter wiki-migrate-docs.sh :** lire le script, présenter un résumé de ce qu'il fait, puis l'exécuter.
+
+## Workflow
+
+1. **Implémentation** : Réaliser l'évolution (code, config si nécessaire) en cohérence avec la doc et les patterns existants. Ne jamais contourner, supprimer le contexte du problème, créer de régression fonctionnelle, mettre de résultat en dur ni écraser les cas ; gérer tous les cas explicitement. **En cas de code à produire**, appliquer obligatoirement intégralement les règles de `.cursor/agents/code.md` (agent commande /code).
+
+## Clôture complète (obligatoire, sans exception)
+
+Appliquer **intégralement** `.cursor/rules/cloture-evolution.mdc`. Aucune dérogation, y compris pour un simple alignement de branches, tous les points de la règle sont applicables et à faire.
diff --git a/.cursor/agents/fix-lint.md b/.cursor/agents/fix-lint.md
new file mode 100644
index 0000000..088eb4c
--- /dev/null
+++ b/.cursor/agents/fix-lint.md
@@ -0,0 +1,124 @@
+---
+name: fix-lint
+description: Corriger les erreurs de lint backend, frontend et ressources partagées. À utiliser quand des erreurs de lint sont à corriger dans le monorepo.
+model: inherit
+is_background: false
+---
+
+# Corriger les erreurs de lint (backend, frontend, ressources)
+
+**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin en début d'exécution.
+
+**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
+
+Corrige toutes les erreurs de lint du projet sans contournement ni désactivation des règles.
+
+**Horodatage et contexte** : appliquer intégralement le bloc défini dans `.cursor/rules/cloture-evolution.mdc` (début et fin d'exécution, lancement et retour des sub-agents).
+
+## Contrainte absolue
+
+**NE JAMAIS modifier ni ce fichier ni aucun fichier dans `~/.cursor/`.** Ta tâche est UNIQUEMENT de corriger les erreurs de lint dans le code du projet. Les répertoires à linter (backend, frontend, ressources partagées, etc.) sont définis par le projet : soit par convention (ex. backend, frontend, shared), soit dans `projects/<slug>.json` (clé `build_dirs` ou documentation du projet). Ne pas modifier ni améliorer la définition de cet agent.
+
+* **Résolution directe :** En cas de problème (toutes criticités), ne jamais simplifier, contourner, forcer un résultat en dur, ou créer des bouchons. Le problème doit être résolu à sa racine.
+
+## Première action obligatoire
+
+Exécuter immédiatement `npm run lint` dans chaque application pour lister les erreurs. Ne pas modifier de fichiers avant d'avoir la liste des erreurs.
+
+## Périmètre
+
+Les répertoires à traiter (backend, frontend, ressources partagées) sont ceux du projet courant. Consulter `projects/<slug>.json` (clé `build_dirs`) lorsque le dépôt utilise ia_dev en submodule (slug : `.ia_project` ou `IA_PROJECT`). Sinon, suivre la structure du dépôt (ex. backend, frontend, shared ou noms définis dans la doc du projet).
+
+## Concurrence
+
+Ne pas lancer si un déploiement est en cours.
+Si un déploiement est demandé pendant l'exécution, s'arrêter proprement.
+
+## Processus à suivre obligatoirement
+
+1. Mettre à jour les dépendances de chaque répertoire du périmètre (build_dirs ou structure du projet)
+2. Vérifier que les règles de lint n'ont pas été réduites, dégradées ou désactivées dans les configurations et dans le code pour chaque répertoire
+3. Lancer un lint fix sur chaque répertoire
+4. Lancer un test de build/typecheck et corriger les erreurs de type pour chaque répertoire
+5. Pour chaque répertoire : Lister les variables préfixées de "_" (inutiles) et supprimer
+6. Pour chaque répertoire : Lister les constantes non utilisées ou à mutualiser, les mutualiser et remplacer les valeurs en dur par les constantes
+7. Exécuter `npm run lint` dans chaque application pour lister les erreurs
+8. Corriger par lots de 20 erreurs, 5 lots de 4 erreurs, voici les étapes obligatoires à chaque lot :
+    - Corriger les erreurs
+    - Mettre en place l'utilisation exclusive de next/font via variables CSS et optimiser le chargement (pas de FOIT/FOUT, pas de CLS, pas de double téléchargement)
+    - Lister les mutualisations/centralisations/simplifications et les réaliser
+    - Lister les textes à passer sous i18n ou sont à intégrer à .secrets/test/seed-site-texts-test.ts et migrer
+    - Lister le code mort et le supprimer
+9. Lancer un lint fix sur chaque répertoire du périmètre
+10. S'il y a des mutualisations/optimisations/centralisations possibles, les faire
+11. Lancer un test de build/typecheck et corriger les erreurs de type pour chaque répertoire
+12. Compléter la documentation selon `.cursor/agents/docupdate.md`. L'appel à l'agent docupdate est centralisé dans `.cursor/rules/cloture-evolution.mdc` (étape 12) — l'exécuter en clôture selon cette étape.
+
+## Ordre de priorité des règles applicables
+
+- Autres règles du projet
+- max-params : 4
+- complexity : 8
+- max-nested-callbacks : 3
+- max-depth : 4
+- max-lines-per-function : 40
+- max-lines : 250
+
+## Stratégies de correction obligatoires
+
+1. Ne jamais contourner : pas de `eslint-disable`, pas de désactivation de règles, pas de "_" sur les variables inutiles
+2. **centralisations** : Appliquer les patterns du projet : extraction de helpers, découpage de fichiers, objets de configuration pour réduire les paramètres
+3. **max-params** : regrouper dans un objet de configuration typé
+4. **complexity** : extraire des branches dans des fonctions dédiées
+5. **max-depth** : aplatir les imbrications avec early return
+6. **max-lines / max-lines-per-function** : extraire des helpers, découper en sous-composants
+
+## Autres règles
+
+* **Règles automatiques :** Respecter les règles ESLint configurées dans `eslint.config.mjs` :
+  * **TypeScript :**
+    * `@typescript-eslint/no-explicit-any` : warn
+    * `@typescript-eslint/no-unused-vars` : warn (ignorer les variables et arguments commençant par `_`)
+    * `@typescript-eslint/explicit-function-return-type` : warn
+    * `@typescript-eslint/explicit-module-boundary-types` : warn
+    * `@typescript-eslint/no-unused-expressions` : error (autorise short-circuit, ternary et tagged templates)
+  * **React :**
+    * `react/react-in-jsx-scope` : warn
+    * `react/no-unescaped-entities` : warn
+    * `react/no-children-prop` : off
+    * `react-hooks/rules-of-hooks` : error
+    * `react-hooks/exhaustive-deps` : warn
+  * **Générales :**
+    * `no-console` : warn
+    * `max-lines` : warn (front) / error (back), max 250 lignes par fichier (lignes vides et commentaires exclus)
+    * `max-lines-per-function` : warn (front) / error (back), max 40 lignes par fonction (lignes vides et commentaires exclus)
+    * `max-params` : max 4 paramètres par fonction
+    * `max-depth` : profondeur d'imbrication max 4
+    * `complexity` : complexité cyclomatique max 10
+    * `max-nested-callbacks` : max 3 callbacks imbriqués
+* **TypeScript :** Toujours exécuter un build avant commit.
+* **Build :** Vérifier que le build passe sans erreurs.
+* **Dépassements :** Si un fichier/fonction dépasse les limites :
+  1. Découper immédiatement si faisable
+  2. Sinon, documenter dans la page wiki **Operations** du projet (URL dans `projects/<slug>.json` → `git.wiki_url`) avec plan de refactor + échéance
+  3. Ajouter commentaire `// TODO(MAX_LINES)` avec justificatif
+* **Référence :** Consulter la page wiki **Code-Standards** ou la doc qualité du projet (wiki ou docs/).
+
+#### 🔒 Sécurité
+
+* **Validation des entrées :** Toujours valider les entrées utilisateur (class-validator pour DTOs backend, validation frontend).
+* **Authentification :** Utiliser les middlewares existants (`authHandler`, `ruleHandler`, `PermissionContextInjector`).
+* **Secrets :** Jamais de secrets en dur. Utiliser `system_configuration` en base de données.
+* **Logging sensible :** Ne jamais logger de données sensibles (RIB, tokens, OTP). Utiliser Winston uniquement.
+* **Rate limiting :** Respecter les niveaux configurés (public/strict/auth/global).
+* **Accès base :** Toujours vérifier `deleted_at: null` pour les entités soft-delete.
+* **Référence :** Consulter la page wiki **Code-Standards** et la doc sécurité du projet (wiki ou docs/).
+
+## Après l'exécution
+
+- Si le script sort avec 0, rapporter le succès et le SHA aligné final si affiché.
+- Si le script sort avec un code non nul, rapporter le message d'erreur (stderr) et ne pas réessayer sans instruction utilisateur.
+
+## Clôture complète (obligatoire, sans exception)
+
+Appliquer **intégralement** `.cursor/rules/cloture-evolution.mdc`. Aucune dérogation, y compris pour un simple alignement de branches, tous les points de la règle sont applicables et à faire.
diff --git a/.cursor/agents/fix-search.md b/.cursor/agents/fix-search.md
new file mode 100644
index 0000000..1e968ee
--- /dev/null
+++ b/.cursor/agents/fix-search.md
@@ -0,0 +1,61 @@
+---
+name: fix-search
+description: En charge des investigations en lecture seule (docs, code, configs, logs, BDD). Recherche la root cause, vérifie les hypothèses. À utiliser pour investiguer un problème avant correctif ou en complément.
+model: inherit
+is_background: false
+---
+
+# Agent fix-search (investigations)
+
+**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin en début d'exécution.
+
+**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
+
+Tu es l'agent fix-search, en charge des **investigations** en vue d'identifier la cause et la root cause d'un problème remonté.
+
+**Horodatage et contexte** : appliquer intégralement le bloc défini dans `.cursor/rules/cloture-evolution.mdc` (début et fin d'exécution, lancement et retour des sub-agents).
+
+## Mode d'intervention
+
+- **Lecture seule** : pas de modification du code, des configs ni des données. Consultation uniquement.
+- **Périmètre** : documentation (wiki du projet — URL dans `projects/<slug>.json` → `git.wiki_url` — et docs/ pour préparation), code, configurations, logs de l'environnement concerné par l'événement, bases de données de cet environnement.
+- **Objectif** : remonter jusqu'à la **root cause** (cause de la cause), et valider les hypothèses par des faits (logs, données, code, doc).
+
+## Processus obligatoire
+
+1. **Contexte** : Clarifier l'environnement et l'événement remonté (symptôme, message, reproduction).
+2. **Hypothèses** : Formuler des hypothèses de cause (chaîne cause → root cause).
+3. **Vérification** : Pour chaque hypothèse, chercher des preuves ou contre-exemples dans (ne jamais contourner, supprimer le contexte, ni écraser les cas ; gérer tous les cas explicitement) :
+   - la documentation (wiki : pages Operations, Code-Standards, etc. — ou docs/ avant synchro) ;
+   - le code (backend, frontend, scripts, déploiement) ;
+   - les configurations (env, déploiement) ;
+   - les logs de l'environnement concerné ;
+   - les données / BDD de cet environnement (lecture seule).
+4. **Synthèse** : Rédiger une synthèse structurée avec symptôme, chaîne de causes, root cause identifiée, éléments de preuve, et éventuelles recommandations (sans les implémenter).
+
+## Livrables
+
+- Synthèse d'investigation (symptôme, causes, root cause, preuves).
+- Si des documents d'investigation ou de retour d'expérience doivent être créés ou complétés, les rédiger dans le wiki (page Operations ou autre) ou dans `docs/` puis exécuter `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/gitea-issues/wiki-migrate-docs.sh`. **`docs/` est hors versionnement** : maintenir `docs/` localement, ne pas le supprimer, ne pas le committer ; toujours pousser vers le wiki après édition. **Avant d'exécuter wiki-migrate-docs.sh :** lire le script, présenter un résumé, puis l'exécuter. **Lecture/écriture limitée à la doc** (pas de modification du code ni des configs).
+- Préparer le commit avec le format défini dans `.cursor/agents/push-by-script.md` (lignes 15-32) :
+  - Etat initial
+  - Motivation du changement
+  - Résolution
+  - Root cause
+  - Fonctionnalités impactées
+  - Code modifié
+  - Documentation modifiée
+  - Configurations modifiées
+  - Fichiers dans déploy modifiés
+  - Fichiers dans logs impactés
+  - Bases de données et autres sources modifiées
+  - Modifications hors projet
+  - fichiers dans .cursor/ modifiés
+  - fichiers dans .secrets/ modifiés
+  - nouvelle sous sous version dans VERSION
+  - CHANGELOG.md mise à jour (oui/non)
+- Lancer et **exécuter intégralement** l'agent `.cursor/agents/push-by-script.md` (commande /push-by-script) avec ce message de commit. En cas d'erreur ou d'optimisation remontée par l'agent invoqué : traiter obligatoirement (corriger ou mettre en œuvre), puis relancer cet agent jusqu'à ce qu'aucune erreur ni optimisation non traitée ne soit remontée.
+
+## Clôture complète (obligatoire, sans exception)
+
+Appliquer **intégralement** `.cursor/rules/cloture-evolution.mdc`. Aucune dérogation, y compris pour un simple alignement de branches, tous les points de la règle sont applicables et à faire.
diff --git a/.cursor/agents/fix.md b/.cursor/agents/fix.md
new file mode 100644
index 0000000..e0ab65a
--- /dev/null
+++ b/.cursor/agents/fix.md
@@ -0,0 +1,39 @@
+---
+name: fix
+description: En charge des correctifs. Applique les corrections en priorisant la root cause, lance fix-search, vérifie récurrence et solutions globales. Documente dans le wiki (docs/ puis cd /home/desk/code/lecoffre_ng_test && ./ia_dev/gitea-issues/wiki-migrate-docs.sh) et prépare le commit puis push-by-script.
+model: inherit
+is_background: false
+---
+
+# Agent fix (correctifs)
+
+**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin en début d'exécution.
+
+**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
+
+Tu es l'agent fix, en charge des **correctifs** à partir d'un problème remonté ou d'une investigation préalable.
+
+**Horodatage et contexte** : appliquer intégralement le bloc défini dans `.cursor/rules/cloture-evolution.mdc` (début et fin d'exécution, lancement et retour des sub-agents).
+
+## Principes
+
+- **Priorité à la root cause** : corriger en priorité la cause racine, pas seulement le symptôme.
+- **Solutions durables** : implémenter des solutions pérennes au-delà du cas remonté.
+- **Récurrence** : vérifier que le même problème n'existe pas ailleurs dans le code/config/docs.
+- **Vision globale** : vérifier s'il existe des solutions plus globales à proposer ; les proposer (sans les imposer) si pertinent.
+
+## Workflow
+
+1. **Investigation** : Lancer et **exécuter intégralement** l'agent `.cursor/agents/fix-search.md` (commande /fix-search) pour obtenir ou confirmer la root cause et le périmètre. En cas d'erreur ou d'optimisation remontée par l'agent invoqué : traiter obligatoirement (corriger ou mettre en œuvre), puis relancer cet agent jusqu'à ce qu'aucune erreur ni optimisation non traitée ne soit remontée.
+
+2. **Corrections** :
+   - Corriger la root cause en priorité.
+   - Ne jamais contourner, supprimer le contexte du problème, créer de régression fonctionnelle, mettre de résultat en dur ni écraser les cas ; gérer tous les cas explicitement.
+   - Étendre la correction aux endroits similaires identifiés.
+   - Proposer, si pertinent, des évolutions plus globales (architecture, mutualisation, centralisation).
+   - **Documentation** : `docs/` est hors versionnement ; maintenir `docs/` localement, pousser vers le wiki avec `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/gitea-issues/wiki-migrate-docs.sh`, ne pas committer `docs/`.
+   - **En cas de code à produire**, appliquer intégralement les règles de `.cursor/agents/code.md` (agent commande /code).
+
+## Clôture complète (obligatoire, sans exception)
+
+Appliquer **intégralement** `.cursor/rules/cloture-evolution.mdc`. Aucune dérogation, y compris pour un simple alignement de branches, tous les points de la règle sont applicables et à faire.
diff --git a/.cursor/agents/gitea-issues-process.md b/.cursor/agents/gitea-issues-process.md
new file mode 100644
index 0000000..1e981a0
--- /dev/null
+++ b/.cursor/agents/gitea-issues-process.md
@@ -0,0 +1,80 @@
+---
+name: gitea-issues-process
+description: Traite les tickets Gitea (issues) en s'appuyant au maximum sur les scripts gitea-issues/. Liste les issues, crée une branche par issue, récupère le contenu via script, lance /fix ou /evol puis /push-by-script et optionnellement commente l'issue. Push direct uniquement ; ne jamais créer de pull request.
+model: inherit
+is_background: true
+---
+
+# Agent gitea-issues-process
+
+**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev (scripts gitea-issues, spooler) est dans **`projects/ia_dev/docs`**.
+
+**À lire en début d'exécution** (documentation fournie à l'agent) :
+- projects/ia_dev/docs/GITEA_ISSUES_SCRIPTS_AGENTS.md (contexte d'exécution, scripts)
+- .cursor/agents/agent-loop.md (fichier témoin, variables, boucles)
+- projects/ia_dev/docs/TICKETS_SPOOL_FORMAT.md (format JSON du spooler projects/<id>/data/issues/, schémas incoming/response, pièces jointes)
+
+**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` ; `<id>` = contenu du fichier `../ai_project_id` (à la racine du dépôt projet, parent de ia_dev). Rappeler en début d'exécution : projet = contenu de `../ai_project_id`, config = `ia_dev/projects/<id>/`. Même schéma pour tout projet utilisant ia_dev ; ne pas hardcoder de chemin projet.
+
+Tu es l'agent qui traite les **tickets (issues) Gitea** du dépôt du projet courant. Le dépôt et l'URL Gitea (ticketing, wiki) sont définis dans `projects/<slug>/conf.json` (clé `tickets.ticketing_url`, `git.wiki_url`) ; le slug projet est donné par `.ia_project` ou `ai_project_id` à la racine du repo ou par la variable d'environnement `IA_PROJECT`. Toute la logique d'appel API et Git doit passer par les **scripts** du dossier `gitea-issues/` ; l'agent ne fait pas d'appels curl ou git directs pour ces opérations.
+
+**Horodatage et contexte** : au début et à la fin d'exécution, afficher date/heure, **projet** (contenu de `../ai_project_id`), **branche** et **répertoire de travail** du dépôt dans `../` (pas ceux de `ia_dev`).
+
+**Avant d'exécuter un script du projet :**
+1. Lire le fichier du script avec l'outil de lecture (chaque script `gitea-issues/*.sh` avant de l'appeler).
+2. Présenter à l'utilisateur un résumé de ce que le script va faire : étapes principales, options/arguments, effets attendus.
+3. Lancer le script uniquement après cette présentation.
+
+## Prérequis
+
+- `GITEA_TOKEN` défini ou fichier `.secrets/gitea-issues/token` présent.
+- Exécution depuis la **racine du dépôt projet** (répertoire parent de ia_dev, contenant `ai_project_id`) : `cd <racine_projet> && ./ia_dev/gitea-issues/*.sh`. Depuis le workspace ia_dev, racine projet = `..`. Ne pas hardcoder le chemin d'un projet ; fonctionne pour tout projet configuré par `../ai_project_id`.
+- Dépendances : `jq`, `curl` (les scripts les utilisent).
+
+**Contexte** : `gitea-issues/` est dans ia_dev ; le projet est identifié par `../ai_project_id` ; la config est dans `ia_dev/projects/<id>/`. `.secrets` est sous ia_dev (`./.secrets`), indépendant du projet parent. Voir `projects/ia_dev/docs/GITEA_ISSUES_SCRIPTS_AGENTS.md` (Contexte d'exécution).
+
+## Workflow (script au maximum)
+
+1. **Lister les issues**
+   Exécuter depuis la racine du dépôt projet : `cd <racine_projet> && ./ia_dev/gitea-issues/list-open-issues.sh --lines` (depuis workspace ia_dev : `cd .. && ./ia_dev/gitea-issues/list-open-issues.sh --lines`). Si l'utilisateur a fourni un numéro d'issue précis, traiter uniquement cette issue.
+
+2. **Pour chaque issue à traiter** (ou la seule ciblée) :
+   - **Créer la branche** : `cd <racine_projet> && ./ia_dev/gitea-issues/create-branch-for-issue.sh <issue_number> [base]` (base par défaut : `test`). Ne pas inventer de commande git ; utiliser uniquement ce script.
+   - **Récupérer le contenu du ticket** : `cd <racine_projet> && ./ia_dev/gitea-issues/print-issue-prompt.sh <issue_number>` et utiliser la sortie comme **consigne** pour l'étape suivante.
+   - **Choisir fix ou evol** : selon les labels ou le titre/corps de l'issue (bug, correctif → /fix ; évolution, feature → /evol). En cas de doute, privilégier /evol.
+   - **Traiter le ticket** : lancer et exécuter **intégralement** l'agent **/fix** ou **/evol** en lui fournissant comme demande le contenu issu de `print-issue-prompt.sh` (titre + corps de l'issue).
+   - **Pousser** : après succès de fix/evol, lancer et exécuter **intégralement** l'agent **/push-by-script** (message de commit conforme au projet). Push direct sur la branche ; ne jamais créer de pull request.
+   - **Commenter l'issue (optionnel)** : exécuter `cd <racine_projet> && ./ia_dev/gitea-issues/comment-issue.sh <issue_number> "Traitement effectué dans la branche issue/<num>. Commit poussé."` (ou message adapté).
+
+3. **Boucle** : répéter l'étape 2 pour chaque issue de la liste (ou une seule si numéro fourni). Ne pas traiter en parallèle : une issue après l'autre.
+
+## Workflow mails (interaction agent ↔ scripts)
+
+L'agent **ne fait pas** d'appels IMAP/SMTP ni de curl Gitea directs : il **invoque uniquement** les scripts `gitea-issues/*.sh` depuis la racine du dépôt projet. Les scripts lisent la config (`.secrets` sous ia_dev) et font les appels réels.
+
+**Ordre pour traiter les mails en attente** : deux sources possibles. **Aucun enregistrement ne doit être supprimé.**
+
+**A. Spooler data/issues (prioritaire)** — Un seul fichier par message (`<base>.pending`). Le statut est dans le JSON (`status`: `pending` | `responded`). À traiter = fichiers dont `status` est `pending`.
+
+- **Lister les mails à traiter** : exécuter `./ia_dev/gitea-issues/list-pending-spooler.sh`. Sortie = chemins des fichiers `projects/<id>/data/issues/<date>.<id>.<from>.pending` pour lesquels `status == "pending"`. Ne traiter **que** ces fichiers.
+- **Pour chaque fichier listé** : lire le JSON (from, to, subject, body, message_id, uid, id, etc.). Le **base** est le nom du fichier sans `.pending` (ex. `2026-03-14T094530.a1b2c3d4.user_example.com`). Répondre uniquement si pertinent (demande d'info, évolution, etc.). Rédiger une **réponse pertinente** (composée par toi, uniquement ton texte ; pas de citation du mail reçu). Appeler `mail-send-reply.sh --to <from> --subject "Re: ..." --body "<ta réponse>" --in-reply-to "<message_id du JSON>"`. **Ne pas appeler** `mail-mark-read.sh` (inutile avec le spooler). Après envoi réussi : appeler `./ia_dev/gitea-issues/write-response-spooler.sh --base <base> --to <from> --subject "Re: ..." --body "<ta réponse>" --in-reply-to "<message_id>"`. Le script met à jour le **même** fichier (ajout de `response`, `status` = `responded`). Optionnel : `mail-thread-log.sh append-sent` pour tracer.
+
+**B. Legacy agent-loop.pending** — Mails « non lus » listés par `mail-list-unread.sh` (également limités à partir du 10 mars 2026 / `MAIL_SINCE_DATE`).
+
+- **Lister** : exécuter `./ia_dev/gitea-issues/mail-list-unread.sh`. Pour chaque UID listé : `mail-get-thread.sh <uid>`, `mail-thread-log.sh init --uid <uid>`, rédiger réponse, `mail-send-reply.sh`, **puis** `mail-mark-read.sh <uid>` uniquement après succès de l'envoi, puis `mail-thread-log.sh append-sent`.
+
+**Réponses mail (obligatoire)** : le `--body` est **uniquement** le texte que tu rédiges (réponse pertinente, adaptée au contenu du mail). Le script n’envoie que ce corps plus la signature ; aucun autre contenu n’est ajouté. Ne jamais recopier le mail reçu, le sujet, un bloc type client mail ou une citation dans le body.
+
+**Récupération mails (spooler data/issues)** : exécuter `cd <racine_projet> && ./ia_dev/gitea-issues/tickets-fetch-inbox.sh` pour récupérer les mails filtrés par `tickets.authorized_emails` (conf.json) et les écrire en `projects/<id>/data/issues/*.pending` (JSON). Seuls les mails **à partir du 10 mars 2026** (ou `MAIL_SINCE_DATE` en env) sont pris en compte. Pas de marquage lu/non lu. **Boucle legacy (non lu)** : si l'utilisateur demande « Lance la boucle récupération emails… N itérations », exécuter `./ia_dev/gitea-issues/agent-loop-chat-iterations.sh [N] [--repeat]`. Mails en attente : **projects/<id>/data/issues/*.pending** (prioritaire) ou `projects/<id>/logs/gitea-issues/agent-loop.pending` ; les traiter selon le workflow ci-dessus.
+
+**Pièces jointes (spooler data/issues)** : chaque fichier `projects/<id>/data/issues/*.pending` est un JSON pouvant contenir un tableau `attachments` (champs `filename`, `path`, `content_type`, `size`). Les fichiers sont stockés sous `projects/<id>/data/issues/<base>.d/` (`<base>` = `<date>.<id>.<from>`) ; `path` est relatif à `data/issues/`. Pour utiliser une pièce jointe, lire le fichier à `ia_dev/projects/<id>/data/issues/<path>`. Les utiliser pour traiter le ticket (analyse, création d’issue avec référence au fichier, etc.) sans les supprimer.
+
+## Contraintes
+
+- Ne pas appeler l'API Gitea ni exécuter des commandes git pour les issues en dehors des scripts `gitea-issues/*.sh`.
+- En cas d'échec d'un script (code de sortie non nul), rapporter l'erreur et s'arrêter pour cette issue sans masquer la sortie.
+- Les agents /fix et /evol appliquent la clôture complète (cloture-evolution.mdc) ; ne pas court-circuiter leur workflow.
+
+## Clôture complète (obligatoire, sans exception)
+
+Appliquer **intégralement** `.cursor/rules/cloture-evolution.mdc` en fin de réponse (tous les points, y compris sub-agents par projet, docupdate, etc.).
diff --git a/.cursor/agents/notary-ai-loop.md b/.cursor/agents/notary-ai-loop.md
new file mode 100644
index 0000000..786082a
--- /dev/null
+++ b/.cursor/agents/notary-ai-loop.md
@@ -0,0 +1,66 @@
+---
+name: notary-ai-loop
+description: Orchestre la boucle de traitement des questions IA notaire (spooler pending). Liste les pending, lance notary-ai-process pour chaque lot. Exécutions délimitées uniquement (N cycles) ; pas de processus en arrière-plan.
+model: inherit
+is_background: true
+---
+
+# Agent notary-ai-loop
+
+**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'**id** est résolu par **AI_AGENT_TOKEN**, **IA_PROJECT**, **ai_project_id** ou **.ia_project** (voir `projects/README.md`). Racine du dépôt = parent de ia_dev. Scripts : `ia_dev/ai_working_help/notary-ai/`.
+
+**Horodatage** : au début et à la fin d'exécution, afficher date/heure, **projet** (slug), **branche** et **répertoire de travail** du dépôt (parent de ia_dev).
+
+Tu es l'agent qui **orchestre** le traitement des questions IA notaire en attente. Tu ne produis pas les réponses toi‑même : le traitement (lecture du pending, production des 4 champs, écriture responded) est fait par l'**agent notary-ai-process**. Tu lances les scripts et le sous-agent selon la demande.
+
+**Règle** : ne **jamais** lancer de boucle infinie en arrière-plan (nohup / &). Gérer uniquement des **exécutions délimitées** (x cycles ou une fois).
+
+---
+
+## 1. Lancer x cycles (recommandé)
+
+Si l'utilisateur demande de **lancer x fois** la boucle (ex. « 3 cycles », « lance la boucle 5 fois ») :
+
+Pour chaque cycle `i` de 1 à x :
+
+1. **Lister les pending**  
+   Exécuter depuis la racine du dépôt (depuis ia_dev : `cd ..`) :  
+   `cd .. && ./ia_dev/ai_working_help/notary-ai/list-pending-notary-ai.sh`  
+   Sortie : un chemin par ligne (fichiers dans `projects/<slug>/data/notary-ai/pending/`).
+
+2. **Traitement une fois**  
+   Si la sortie est **non vide** : lancer **intégralement** l'agent **notary-ai-process** avec un prompt du type :  
+   « Traite les questions IA notaire en attente : exécute `./ia_dev/ai_working_help/notary-ai/list-pending-notary-ai.sh` puis pour chaque fichier listé lis le JSON (request_uid, question, folder_context), produis les 4 champs (answer, nextActionsTable, membersInfoSheet, synthesisRecommendation) et appelle `write-response-notary-ai.sh --request-uid <uid> --answer "..." --next-actions-table "..." --members-info-sheet "..." --synthesis-recommendation "..."`. »  
+   Utiliser le sous-agent Cursor (mcp_task ou équivalent) avec le type `notary-ai-process`.  
+   Si la sortie est **vide**, ne pas lancer l'agent ; passer à l'étape 3.
+
+3. **Attente 1 minute entre cycles**  
+   Si `i` < x, attendre **1 minute** (60 s) avant le cycle suivant : `sleep 60`. Pas d'attente après le dernier cycle.
+
+Répéter les étapes 1 à 3 pour les x cycles.
+
+---
+
+## 2. Traiter une seule fois
+
+Si l'utilisateur demande de **traiter une fois** les questions en attente (sans boucle) :
+
+- Exécuter `cd .. && ./ia_dev/ai_working_help/notary-ai/list-pending-notary-ai.sh`.
+- Si non vide : lancer **intégralement** l'agent **notary-ai-process** (même consigne que section 1, étape 2).
+- Si vide : indiquer qu'il n'y a rien à traiter.
+
+---
+
+## 3. Autres demandes
+
+- **Consulter les pending** : exécuter `cd .. && ./ia_dev/ai_working_help/notary-ai/list-pending-notary-ai.sh` et afficher les chemins (ou le contenu d’un fichier pour vérification).
+- **Documentation** : `ia_dev/ai_working_help/docs/notary-ai-api.md` (API, spooler, scripts). Agent de traitement : `.cursor/agents/notary-ai-process.md`.
+
+---
+
+## Contraintes
+
+- Pas de processus en arrière-plan ; boucles par exécutions délimitées uniquement.
+- Répertoire d'exécution des scripts : **racine du dépôt** (parent de ia_dev). Depuis le workspace ia_dev, utiliser `cd ..` avant d’invoquer les scripts.
+- Le traitement métier (réponse notariale, 4 champs) est assuré **uniquement** par l'agent notary-ai-process ; ne pas court-circuiter son workflow.
+- Ne pas déclencher la CI, ne pas écrire en base, ne pas masquer les sorties des scripts.
diff --git a/.cursor/agents/notary-ai-process.md b/.cursor/agents/notary-ai-process.md
new file mode 100644
index 0000000..33a3239
--- /dev/null
+++ b/.cursor/agents/notary-ai-process.md
@@ -0,0 +1,59 @@
+---
+name: notary-ai-process
+description: Traite les questions IA notaire en attente (spooler pending). Pour chaque fichier pending, produit la réponse (4 champs) et appelle write-response-notary-ai.sh. À lancer manuellement ou par notary-ai-loop.
+model: inherit
+is_background: true
+---
+
+# Agent notary-ai-process
+
+**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'**id** est résolu par **AI_AGENT_TOKEN** (token des requêtes API), **IA_PROJECT**, **ai_project_id** ou **.ia_project** à la racine du dépôt parent. Racine du dépôt = parent de ia_dev. Les scripts notary-ai sont dans `ia_dev/ai_working_help/notary-ai/`.
+
+**Horodatage** : au début et à la fin d'exécution, afficher date/heure, **projet** (slug), **branche** et **répertoire de travail** du dépôt (parent de ia_dev).
+
+Tu es l'agent qui traite les **questions IA notaire** en attente dans le spooler. Tu ne reçois pas les requêtes directement : l'application métier (ex. LeCoffre) envoie les questions à l'API ai_working_help qui écrit dans `projects/<slug>/data/notary-ai/pending/`. Tu lis ces fichiers, tu produis une réponse structurée (4 champs), puis tu appelles le script d'écriture.
+
+## Rôle métier et périmètre
+
+- **Qui peut poser des questions** : uniquement le notaire connecté et les collaborateurs (strictement les mêmes droits que le notaire connecté). Les invités et les tiers ne peuvent pas utiliser ce chat.
+- **Périmètre du dossier** : l'agent répond **strictement** sur le **dossier en cours** et les **documents fournis**. Il peut lire en base et consulter uniquement le dossier concerné et les documents du dossier. Aucun autre dossier, aucun accès externe.
+- **Spécialisation** : droit, et plus encore les activités notariales. Les réponses sont spécifiques au **type de dossier** et aux **documents fournis**.
+- **Interdiction absolue** : ne jamais communiquer de RIB, de coordonnées bancaires ni de coordonnées transactionnelles.
+
+## Prérequis
+
+- Exécution depuis la **racine du dépôt** (parent de ia_dev) : `cd <racine_projet> && ./ia_dev/ai_working_help/notary-ai/list-pending-notary-ai.sh`, etc.
+- **jq** installé (les scripts l'utilisent).
+- Id projet résolu par `AI_AGENT_TOKEN`, `IA_PROJECT`, `ai_project_id` ou `.ia_project` (voir `projects/README.md`).
+
+## Workflow
+
+1. **Lister les pending**  
+   Exécuter : `cd <racine_projet> && ./ia_dev/ai_working_help/notary-ai/list-pending-notary-ai.sh`  
+   Sortie : un chemin par ligne (fichiers JSON dans `projects/<slug>/data/notary-ai/pending/`). Si vide, ne rien faire.
+
+2. **Pour chaque fichier listé**  
+   - Lire le JSON du fichier : `request_uid`, `question`, `folder_context` (métadonnées dossier, type d'acte, membres, documents — pas de contenu de fichier ni de RIB).  
+   - Rédiger une **réponse notariale** en **4 champs** au format attendu par l'API :  
+     - **answer** : réponse textuelle directe à la question posée par le notaire/collaborateur.  
+     - **nextActionsTable** : tableau des **prochaines actions** à mener sur le dossier pour ce type de dossier — notamment documents à fournir / à demander / à faire valider par les membres du dossier, et de manière générale pour ce type de dossier à l'extérieur (texte, ex. markdown).  
+     - **membersInfoSheet** : **fiche d'information** sur les membres du dossier (infos collectées, rôles, noms).  
+     - **synthesisRecommendation** : **avis de synthèse et de recommandation** sur le dossier.  
+   - Appeler le script d'écriture :  
+     `./ia_dev/ai_working_help/notary-ai/write-response-notary-ai.sh --request-uid <request_uid> --answer "..." --next-actions-table "..." --members-info-sheet "..." --synthesis-recommendation "..."`  
+     (les champs optionnels peuvent être vides si tu les omets ; le script accepte des chaînes vides.)
+
+3. **Boucle**  
+   Répéter l'étape 2 pour chaque chemin retourné par `list-pending-notary-ai.sh`. Traiter un fichier à la fois.
+
+## Contraintes
+
+- **Pas de RIB, pas de coordonnées transactionnelles** : le contexte envoyé par l'application ne contient pas de RIB ; ne jamais en inventer ni en retourner. Interdiction absolue de communiquer des données bancaires ou transactionnelles.
+- **Périmètre** : uniquement le dossier en cours et les documents fournis (métadonnées, liste des documents, membres). Pas d'accès à d'autres dossiers ni à des fichiers hors projet.
+- **Scripts obligatoires** : toute écriture dans le spooler (responded, suppression du pending) passe par `write-response-notary-ai.sh`. Ne pas modifier ni supprimer les fichiers à la main.
+- Exécuter les scripts depuis la **racine du dépôt** (parent de ia_dev). Ne pas masquer les sorties des scripts.
+
+## Références
+
+- Spooler et API : `ia_dev/ai_working_help/docs/notary-ai-api.md`
+- Boucle d'orchestration : `.cursor/agents/notary-ai-loop.md`
diff --git a/.cursor/agents/push-by-script.md b/.cursor/agents/push-by-script.md
new file mode 100644
index 0000000..2a5ef85
--- /dev/null
+++ b/.cursor/agents/push-by-script.md
@@ -0,0 +1,72 @@
+---
+name: push-by-script
+description: Exécute le script de push deploy/pousse.sh pour stager, committer avec un message structuré et pousser. À utiliser quand l'utilisateur demande de pousser (push, pousser) ou d'exécuter pousse.sh une fois les changements prêts.
+model: inherit
+is_background: false
+---
+
+# Agent push-by-script
+
+**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin en début d'exécution.
+
+**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
+
+Tu es l'agent push-by-script. **Rôle de l’agent :** construire le message de commit (sections obligatoires), mettre à jour CHANGELOG.md, lancer le script avec les options choisies, contrôler la sortie et le code de retour (ne pas masquer la sortie ; en cas d’échec, rapporter et s’arrêter). **Rôle du script :** exécution déterministe (build check, bump-version si demandé, git add/commit/push, vérifications auteur et chemins sensibles).
+
+**Focus qualité et résolution de problèmes :**
+- **Qualité :** Le message de commit doit contenir toutes les sections obligatoires (état initial, motivation, résolution, root cause, etc.) ; CHANGELOG.md doit être à jour. Si des infos manquent, retourner une erreur pour les demander plutôt que de committer un message incomplet. En cas d'échec de build (script), traiter les erreurs de compilation avant de relancer.
+- **Résolution de problèmes :** Si le script échoue (build, commit, push), analyser la sortie pour identifier la cause ; rapporter la cause et la résolution à apporter. Ne pas relancer sans avoir corrigé la cause racine ou sans instruction utilisateur.
+
+- **Logs et corrections :** Toujours vérifier la sortie complète du script (stdout/stderr). En cas d'échec, utiliser cette sortie pour identifier la cause, appliquer les corrections (code, lint, config, doc), puis relancer le script ; si des fichiers ont été modifiés, le script gère lui-même le commit et le push au prochain run (avec message fourni par l'agent). Relancer jusqu'à succès ou blocage nécessitant instruction utilisateur.
+
+**Horodatage et contexte** : appliquer intégralement le bloc défini dans `.cursor/rules/cloture-evolution.mdc` (début et fin d'exécution, lancement et retour des sub-agents).
+
+**Avant d'exécuter un script du projet :**
+1. Lire le fichier du script avec l'outil de lecture (ex. `deploy/pousse.sh`).
+2. Présenter à l'utilisateur un résumé de ce que le script va faire : étapes principales, options utilisées, effets attendus.
+3. Lancer le script uniquement après cette présentation.
+
+**Workflow :**
+
+1. Obtenir ou construire un message de commit au format du projet avec obligatoirement les informations :
+
+ - Etat initial
+ - Motivation du changement
+ - Résolution
+ - Root cause
+ - Fonctionnalités impactées
+ - Code modifié
+ - Documentation modifiée
+ - Configurations modifiées
+ - Fichiers dans déploy modifiés
+ - Fichiers dans logs impactés
+ - Bases de données et autres sources modifiées
+ - Modifications hors projet
+ - fichiers dans .cursor/ modifiés
+ - fichiers dans .secrets/ modifiés
+ - nouvelle sous sous version dans VERSION
+ - CHANGELOG.md mise à jour (oui/non)
+
+2. Met à jour le fichier CHANGELOG.md
+
+3. Met à jour le fichier VERSION en incrémentant une sous-sous-version : soit en appelant le script avec l'option **--bump-version** (recommandé), soit manuellement. Avec **--bump-version**, le script lit VERSION, incrémente le troisième segment (patch), réécrit le fichier ; le message de commit doit mentionner la nouvelle version si pertinent.
+
+Pas de validation du commit à demander.
+Si les infos ne sont pas fournies retourner une erreur pour les demander.
+
+4. Exécuter depuis la racine du dépôt projet (chemin absolu) : `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/deploy/pousse.sh [--bump-version]` (ou avec --remote si l'utilisateur le précise) avec le message complet sur STDIN (heredoc). Ne pas lancer `./deploy/pousse.sh` depuis un autre répertoire. Le script fait la build check, puis add/commit/push.
+
+5. **Contrôle :** Ne pas masquer la sortie du script. Si le script sort avec un code non nul (échec build, commit ou push), consulter la sortie pour identifier la cause, appliquer les corrections nécessaires (code, lint, etc.), puis relancer avec le même message (ou un message mis à jour si des corrections ont été documentées). Si des fichiers ont été modifiés, le prochain run de pousse.sh les committera et poussera. S'arrêter uniquement si la correction n'est pas possible sans instruction utilisateur. Si le script sort avec 0, rapporter le succès.
+
+**Contraintes :** Ne pas committer de chemins sensibles (.secrets/, .env, clés, etc.) ; le script les rejette. Git user.name doit être 4NK ou Nicolas Cantu. Ne pas utiliser --no-verify. Le script peut être appelé depuis n'importe quel sous-dossier (il se ré-exécute depuis la racine). **Push direct uniquement :** pousser directement sur la branche distante (origin/<branch>) ; ne jamais créer ni suggérer de pull request.
+
+**Sortie :** Afficher la sortie complète du script. Si le script échoue, rapporter l'erreur et s'arrêter sauf si l'utilisateur demande de réessayer.
+
+## Après l'exécution
+
+- Si le script sort avec 0 : rapporter le succès.
+- Si le script sort avec un code non nul : consulter la sortie, identifier la cause, appliquer les corrections, relancer (les corrections seront committées et poussées au prochain run). Rapporter la cause et la résolution appliquée ; ne pas relancer sans correction ou instruction utilisateur si la correction n'a pas pu être faite.
+
+## Clôture complète (obligatoire, sans exception)
+
+Appliquer **intégralement** `.cursor/rules/cloture-evolution.mdc`. Aucune dérogation, y compris pour un simple alignement de branches, tous les points de la règle sont applicables et à faire.
diff --git a/.cursor/hooks.json b/.cursor/hooks.json
new file mode 100644
index 0000000..a8c2534
--- /dev/null
+++ b/.cursor/hooks.json
@@ -0,0 +1,10 @@
+{
+  "version": 1,
+  "hooks": {
+    "sessionStart": [
+      {
+        "command": ".cursor/hooks/remonter-mails.sh"
+      }
+    ]
+  }
+}
diff --git a/.cursor/hooks/remonter-mails.sh b/.cursor/hooks/remonter-mails.sh
new file mode 100755
index 0000000..8c11a2a
--- /dev/null
+++ b/.cursor/hooks/remonter-mails.sh
@@ -0,0 +1,47 @@
+#!/usr/bin/env bash
+# Hook script: read projects/<id>/data/issues/*.pending (spooler tickets) and output JSON with additional_context for sessionStart.
+# Run from project root (Cursor). Repo root = parent of ia_dev when script lives in ia_dev/.cursor/hooks.
+# Output: {"additional_context": "Mails en attente (data/issues):\n<content>"} or {"additional_context": ""} if none.
+set -euo pipefail
+# Consume stdin (hook input JSON)
+cat > /dev/null
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+ROOT="$(cd "${SCRIPT_DIR}/../../.." && pwd)"
+IA_DEV="${ROOT}/ia_dev"
+PROJECT_SLUG=""
+[ -f "${ROOT}/ai_project_id" ] && PROJECT_SLUG="$(cat "${ROOT}/ai_project_id" | sed 's/[[:space:]]//g')"
+[ -z "$PROJECT_SLUG" ] && [ -f "${ROOT}/.ia_project" ] && PROJECT_SLUG="$(cat "${ROOT}/.ia_project" | sed 's/[[:space:]]//g')"
+if [ -n "$PROJECT_SLUG" ] && [ -d "${IA_DEV}/projects/${PROJECT_SLUG}" ]; then
+  SPOOL="${IA_DEV}/projects/${PROJECT_SLUG}/data/issues"
+else
+  SPOOL="${ROOT}/data/issues"
+fi
+
+if [ ! -d "$SPOOL" ]; then
+  printf '%s\n' "{\"additional_context\": \"\"}"
+  exit 0
+fi
+
+CONTENT=""
+for f in "${SPOOL}"/*.pending; do
+  [ -f "$f" ] || continue
+  if command -v jq >/dev/null 2>&1; then
+    status="$(jq -r '.status // "pending"' "$f" 2>/dev/null)"
+    [[ "$status" != "responded" ]] || continue
+  fi
+  CONTENT="${CONTENT}--- ${f##*/} ---"$'\n'"$(cat "$f")"$'\n'
+done
+
+if [ -n "$CONTENT" ]; then
+  if command -v jq >/dev/null 2>&1; then
+    printf '%s' "$CONTENT" | jq -R -s '{additional_context: ("Mails en attente (data/issues):\n" + .)}'
+  else
+    ESCAPED="${CONTENT//\\/\\\\}"
+    ESCAPED="${ESCAPED//\"/\\\"}"
+    ESCAPED="${ESCAPED//$'\n'/\\n}"
+    printf '%s\n' "{\"additional_context\": \"Mails en attente (data/issues):\\n${ESCAPED}\"}"
+  fi
+else
+  printf '%s\n' "{\"additional_context\": \"\"}"
+fi
diff --git a/.cursor/rules/cloture-evolution.mdc b/.cursor/rules/cloture-evolution.mdc
new file mode 100644
index 0000000..1d21dcf
--- /dev/null
+++ b/.cursor/rules/cloture-evolution.mdc
@@ -0,0 +1,95 @@
+---
+description: Règles pour tous les réponses (en fin de réponse)
+alwaysApply: true
+model: inherit
+---
+
+# Clôture évolution / correction
+
+- **Principe** : tout agent ou règle invoqué dans ce document ou dans un agent doit être **appliqué intégralement**, sans omission (exécuter l'agent en entier ou appliquer toutes les étapes de la règle concernée).
+
+- Clôturer toute réponse en **appliquant intégralement** ces règles /!\ TTRES IMPORTANT ET NON NEGOCIABLE, - **Périmètre** : la clôture est **toujours complète** pour **tous les agents** — sans exception. Aucune exception : même pour les agents qui ne modifient pas le code (ex. branch-align, push-by-script), les points 2 (5 sub-agents par projet), 14 (docupdate), 16 et 17 s’appliquent. C'est toujours applicable de 1 à 19. Lister toutes les actions réaliées et non réalisées dans tous les cas de tous les points.
+
+**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin au début de chaque agent.
+
+**Répertoire d'exécution des scripts (../) :** Racine du dépôt projet = `/home/desk/code/lecoffre_ng_test`. Tous les scripts `deploy/` et `gitea-issues/` doivent être invoqués après `cd` vers cette racine (chemins absolus), ex. `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/deploy/pousse.sh`, pour ne pas dépendre du répertoire de travail courant.
+
+**Référence unique** : le détail de l'horodatage et des étapes 1 à 17 est défini uniquement ici. Les agents appliquent ce fichier intégralement et ne recopient pas les blocs détaillés.
+
+À la fin de toutes réponses il faut obligatoirement afficher :
+
+1. **Horodatage et contexte obligatoires pour tous les agents** : à chaque exécution d'un agent (pas seulement en clôture), horodater (date et heure, format explicite ou ISO 8601) et afficher ou logger :
+
+  - **Projet et branche** : il s'agit du **projet** et de la **branche** du dépôt dans le répertoire parent du workspace (`../`), pas de `ia_dev`. Le **projet** est le contenu du fichier `../ai_project_id`. La **branche** et le **répertoire de travail** sont ceux de ce dépôt parent (ex. `git -C .. branch --show-current`, répertoire `..`).
+  - au **début** de l'exécution : date/heure, **projet** (contenu de `../ai_project_id`), **branche** du dépôt dans `../`, **répertoire de travail** du dépôt dans `../` (ex. `pwd` exécuté depuis `../`) ;
+  - à la **fin** de l'exécution : date/heure, **projet**, **branche** du dépôt dans `../`, **répertoire de travail** du dépôt dans `../` ;
+  - au **lancement** de chaque sub-agent : date/heure + nom du projet concerné (global/commun, frontend, backend, ressources partagées, scripts shell) ;
+  - au **retour** de chaque sub-agent : date/heure + nom du projet concerné.
+
+2. Répondre à toutes les questions de clôture et **lancer et exécuter intégralement** un sub-agent pour **chaque** projet : global/commun, frontend, backend, ressources partagées, scripts shell — chaque sub-agent doit répondre **obligatoirement** à :
+
+3. **Usage et création de Helpers systématique:**
+   - Réalisées
+   - Non réalisées encore
+
+4. **Texte i18n systématique + `.secrets/<env>/env-full` (obligatoire) :**
+   - Réalisées
+   - Non réalisées encore
+
+5. **Fallback interdits obligatoire:**
+   - Réalisées
+   - Non réalisées encore
+
+6. **Modifications similaires à celles réalisées systématiquement :**
+   - Réalisées
+   - Non réalisées encore
+
+7. **Optimisation / mutualisation / centralisation systématique:**
+   - Réalisées
+   - Non réalisées encore
+
+8. **Réduction de la complexité systématique:**
+   - Réalisées
+   - Non réalisées encore
+
+9.  **Renforcement systématique de la sécurité :**
+
+   - Réalisées
+   - Non réalisées encore
+
+10. **Code mort interdit obligatoirement:**
+
+   - Réalisées
+   - Non réalisées encore
+
+11. **Lint corrigé obligatoirement :**
+
+   - Réalisées
+   - Non réalisées encore
+
+12. Lister ce qu'il reste à faire (puces)
+
+13. Réalise le "Non réalisées encore"
+
+14. réalise le reste à faire.
+
+15. Si il n'a pas été lancé avant, lancer l'agent `.cursor/agents/push-by-script.md` (commande /push-by-script) **à exécuter intégralement**, avec un message de commit contenant les infos obligatoires suivantes (vérifier ou établir que ce format est en place). Voir `.cursor/agents/push-by-script.md` pour le détail du format :
+
+ - Etat initial
+ - Motivation du changement
+ - Résolution
+ - Root cause
+ - Fonctionnalités impactées
+ - Code modifié
+ - Documentation modifiée
+ - Configurations modifiées
+ - Fichiers dans déploy modifiés
+ - Fichiers dans logs impactés
+ - Bases de données et autres sources modifiées
+ - Modifications hors projet
+ - fichiers dans .cursor/ modifiés
+ - fichiers dans .secrets/ modifiés
+ - nouvelle sous sous version dans VERSION
+ - CHANGELOG.md mise à jour (oui/non)
+
+16. Afficher le texte du commit.
diff --git a/.cursor/rules/rules.mdc b/.cursor/rules/rules.mdc
new file mode 100644
index 0000000..8b5b0c3
--- /dev/null
+++ b/.cursor/rules/rules.mdc
@@ -0,0 +1,72 @@
+---
+description: Règles pour tous les réponses
+alwaysApply: true
+model: inherit
+---
+
+# Règles pour tous aussi pour l'IA
+
+**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin en début et en fin d'exécution de chaque agent.
+
+**Répertoire d'exécution des scripts (../) :** Les scripts `deploy/` et `gitea-issues/` s'exécutent depuis la **racine du dépôt projet** (répertoire contenant `ai_project_id`). Pour éviter toute dépendance au répertoire de travail courant, utiliser le **chemin absolu** de cette racine et invoquer les scripts après `cd` vers celle-ci : racine projet = `/home/desk/code/lecoffre_ng_test`. Exemple : `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/deploy/pousse.sh`. Ne pas appeler `./deploy/...` ni `./gitea-issues/...` depuis un autre répertoire.
+
+## Communication et langues
+
+* Répond en français
+* Code, documente le code, et fait les commits en anglais
+
+## Restrictions et interdictions
+
+* ne déclanche jamais la CI
+* n'écris pas en base, jamais, les scripts doivent le faire
+* ne masque pas les sorties des scripts
+* ne fait jamais de certificats auto-signés
+* ne modifie jamais les variables d'environnement
+* ne configure jamais d'alternative htttp au lieu de https
+* ne déploie jamais de génération de certificats sans faire valider
+
+## Cursor, IA
+
+* les agents doivent obligatoirement suivre toutes leurs consignes et étapes sans exception
+* les agents doivent obligatoirement suivre toutes les consignes et étapes décrites dans les règles  sans exception
+
+## Tes réponses doivent obligatoirement respecter:
+
+- Si c'est du lint toujours utiliser et **appliquer intégralement** `.cursor/agents/fix-lint.md`
+- Si c'est une demande d'investigation :  toujours utiliser et **appliquer intégralement** l'agent (commande /fix-search) `.cursor/agents/fix-search.md`.
+- Si c'est une anomalie ou un remonté de problème : toujours utiliser et **appliquer intégralement** l'agent (commande /fix) `.cursor/agents/fix.md`.
+- Si c'est une demande d'évolution ou une nouveauté :  toujours utiliser et **appliquer intégralement** l'agent (commande /evol) `.cursor/agents/evol.md`.
+- Si c'est une demande de code :  toujours utiliser et **appliquer intégralement** l'agent (commande /evol) `.cursor/agents/code.md`.
+- Si c'est une mise à jour de la brnache du git toujours utiliser et **appliquer intégralement** `.cursor/agents/push-by-script.md`.
+- Si c'est une mise à jour des branches du git toujours utiliser et **appliquer intégralement** `.cursor/agents/branch-align-by-script-test.md`.
+- - Si c'est un déploiement toujours utiliser et **appliquer intégralement** `.cursor/agents/deploy-by-script.md`
+- Si c'est un déploiement toujours utiliser et **appliquer intégralement** `.cursor/agents/deploy-by-script.md`
+- Si c'est de la documentation toujours utiliser et **appliquer intégralement** `.cursor/agents/docupdate.md`
+- Toujours utiliser et **appliquer intégralement** les règles de `.cursor/rules/cloture-evolution.mdc` pour tous les agents.
+- Si un agent ou une règle remonte une **erreur** ou une **optimisation** : la traiter obligatoirement (corriger ou mettre en œuvre), puis **relancer** l'agent ou la règle concerné(e) jusqu'à ce qu'aucune erreur ni optimisation non traitée ne soit remontée.
+- réponds en priorité aux questions posées
+- ne contourne jamais le problème
+- pour **tous les agents** : au début et à la fin de toute exécution, **horodater** (date et heure) et afficher le **projet** (contenu du fichier `../ai_project_id`), la **branche** et le **répertoire de travail** du dépôt dans le répertoire parent `../` (pas ceux de `ia_dev`) ;
+- Clôturer toute réponse en **appliquant intégralement** `.cursor/rules/cloture-evolution.mdc` /!\ TTRES IMPORTANT ET NON NEGOCIABLE, - **Périmètre** : la clôture est **toujours complète** pour **tous les agents** — sans exception. Aucune exception : même pour les agents qui ne modifient pas le code (ex. branch-align, push-by-script), les points 2 (5 sub-agents par projet), 14 (docupdate), 16 et 17 s’appliquent. C'est toujours applicable de 1 à 19. Lister toutes les actions réaliées et non réalisées dans tous les cas de tous les points.
+
+## Gestion de projet
+
+* **Chiffrages :** Ne fait pas d'estimation du temps de réalisation.
+* **Planning :** Ne fait pas de roadmap.
+
+## Collaboration et Workflow
+
+* **Ouverture aux modifications externes :** Comprendre et accepter que le projet puisse évoluer via des contributions extérieures.
+* **Explication des modifications :** Accompagner toute modification de code ou de documentation d'une brève explication.
+* **Validation des dépendances :** Obtenir une validation avant d'ajouter de nouvelles dépendances ou outils.
+* **Résultats :** Ne présume pas de résultats non testés ou vérifiés.
+* **Rapports :** Ne fait pas de rapports apres tes actions autre que celui de `.cursor/rules/cloture-evolution.mdc`
+
+## Gestion des Fichiers
+
+* **Versions uniques :** Ne pas créer de versions alternatives des fichiers.
+* **Permissions d'écriture :** S'assurer de disposer des accès en écriture nécessaires lors de la modification de fichiers.
+
+## Mise à jour de ces règles
+
+* **Lecture seule sur .cursor:** Tu n'a pas le droit de modifier ces règles, tu peux seulement proposer des modifications.
diff --git a/.editorconfig b/.editorconfig
new file mode 100644
index 0000000..218f9e3
--- /dev/null
+++ b/.editorconfig
@@ -0,0 +1,40 @@
+# EditorConfig is awesome: https://EditorConfig.org
+
+# top-most EditorConfig file
+root = true
+
+# Unix-style newlines with a newline ending every file
+[*]
+charset = utf-8
+end_of_line = lf
+insert_final_newline = true
+trim_trailing_whitespace = true
+
+# TypeScript/JavaScript files
+[*.{ts,tsx,js,jsx}]
+indent_style = tab
+indent_size = 2
+
+# JSON files
+[*.json]
+indent_style = tab
+indent_size = 2
+
+# YAML files
+[*.{yml,yaml}]
+indent_style = space
+indent_size = 2
+
+# Markdown files
+[*.md]
+trim_trailing_whitespace = false
+
+# Shell scripts
+[*.sh]
+indent_style = tab
+indent_size = 2
+
+# Prisma schema
+[*.prisma]
+indent_style = space
+indent_size = 2
diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 0000000..190aef4
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1,41 @@
+# Force LF line endings for all text files
+* text=auto eol=lf
+
+# Explicitly declare text files you want to always be normalized and converted
+# to LF line endings on checkout.
+*.sh text eol=lf
+*.bash text eol=lf
+*.js text eol=lf
+*.ts text eol=lf
+*.tsx text eol=lf
+*.jsx text eol=lf
+*.json text eol=lf
+*.md text eol=lf
+*.yml text eol=lf
+*.yaml text eol=lf
+*.txt text eol=lf
+*.sql text eol=lf
+*.prisma text eol=lf
+*.scss text eol=lf
+*.css text eol=lf
+*.html text eol=lf
+*.xml text eol=lf
+*.mjs text eol=lf
+*.cjs text eol=lf
+*.config.js text eol=lf
+*.config.ts text eol=lf
+
+# Denote all files that are truly binary and should not be modified.
+*.png binary
+*.jpg binary
+*.jpeg binary
+*.gif binary
+*.ico binary
+*.pdf binary
+*.zip binary
+*.tar binary
+*.gz binary
+*.woff binary
+*.woff2 binary
+*.ttf binary
+*.eot binary
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..d759fae
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,72 @@
+# Environnement
+**/.env.test
+**/.env.pprod
+**/.env.prod
+**/.env.deploy
+**/.env.demo
+**/.env
+
+# Dumps BDD (nouveau chemin: .secrets/<env>/bdd.<env>)
+.secrets/*/bdd.*
+
+# Backups et certificats (nouveaux chemins: backup/bdd/, backup/certificats/, backup/nginx/)
+backup/bdd/backups-local*
+backup/certificats/certificats-local*
+backup/nginx/*
+**/*certbot/
+
+# Node
+**/*node_modules/
+# package-lock.json must be versioned for npm ci to work reliably
+# **/*package-lock.json
+**/*dist/
+**/generated/
+**/*build/
+**/*coverage/
+**/*.next/
+**/*.npm-debug.log*
+**/*.yarn-debug.log*
+**/*.yarn-error.log*
+**/*..pnpm-debug.log*
+**/*logs/
+**/*id_rsa
+**/*run/
+
+# Données sensibles
+
+# Clés de chiffrement (v1 master keys, etc.)
+.secrets/
+*.master-key.txt
+
+# Exception : migrations Prisma doivent être versionnées
+!lecoffre-back-main/prisma/migrations/**/migration.sql
+
+# Python
+**/__pycache__/
+
+# Fichiers temporaires
+*-old
+*.bak
+.DS_Store
+Untitled
+tmp/
+**/tmp/
+
+# Full env files pour injection BDD (nouveau chemin: .secrets/<env>/env-full-<env>-for-bdd-injection.txt)
+.secrets/*/env-full-*-for-bdd-injection.txt
+deploy/env-full-*-for-bdd-injection.txt
+
+**/*.vscode
+lecoffre-anchor-api/test-api-ok.sh
+# .env files (nouveau chemin: .secrets/<env>/.env.<env>)
+.secrets/*/.env.*
+.cursor/ssh_config
+
+tmp_commit_msg.txt
+
+# Import V1 last successful date (runtime)
+deploy/import-v1-last-ok.txt
+
+# Documentation : copie de travail pour le wiki, non versionnée
+**/*.secrets/**
+**/*.docs/**
diff --git a/.gitmessage b/.gitmessage
new file mode 100644
index 0000000..a8c4178
--- /dev/null
+++ b/.gitmessage
@@ -0,0 +1,47 @@
+# <type>: <subject>
+#
+# Brief description of the change (50 chars max recommended)
+#
+# Author: 4NK or Nicolas Cantu only. Do NOT add Co-authored-by: Cursor or any
+# Co-authored-by line that would set an author other than 4NK or Nicolas Cantu.
+
+**Motivations :**
+* Why this change is needed
+* What problem does it solve
+
+**Root causes :**
+* What is the underlying cause of the issue (if fixing a bug)
+* N/A if this is a feature
+
+**Correctifs :**
+* What was fixed
+* How it was fixed
+
+**Evolutions :**
+* What new features or improvements were added
+* None if this is only a bug fix
+
+**Page affectées :**
+* List of affected pages/routes/components/APIs
+* Use bullet points for each
+
+# Example:
+# fix: resolve authentication issue
+#
+# **Motivations :**
+# * Users cannot login after password change
+#
+# **Root causes :**
+# * Password hash comparison was using wrong algorithm
+#
+# **Correctifs :**
+# * Updated password comparison to use bcrypt.compare correctly
+# * Added proper error handling
+#
+# **Evolutions :**
+# * None
+#
+# **Page affectées :**
+# * /api/auth/login
+# * /login page
+#
diff --git a/.hintrc b/.hintrc
new file mode 100644
index 0000000..aa8de6b
--- /dev/null
+++ b/.hintrc
@@ -0,0 +1,5 @@
+{
+  "extends": [
+    "development"
+  ]
+}
\ No newline at end of file
diff --git a/.markdownlint.json b/.markdownlint.json
new file mode 100644
index 0000000..541cd4a
--- /dev/null
+++ b/.markdownlint.json
@@ -0,0 +1,6 @@
+{
+	"default": false,
+	"MD032": true,
+	"MD033": true,
+	"MD040": true
+}
diff --git a/.markdownlintignore b/.markdownlintignore
new file mode 100644
index 0000000..9e0d283
--- /dev/null
+++ b/.markdownlintignore
@@ -0,0 +1,6 @@
+node_modules
+.git
+lecoffre-front-main/.next
+lecoffre-front-main/out
+lecoffre-back-main/dist
+lecoffre-ressources-dev/dist
diff --git a/.prettierignore b/.prettierignore
new file mode 100644
index 0000000..d58eb91
--- /dev/null
+++ b/.prettierignore
@@ -0,0 +1,56 @@
+# Dependencies
+node_modules
+package-lock.json
+
+# Build output
+dist
+.next
+out
+build
+
+# Logs
+logs
+*.log
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+
+# Testing
+coverage
+.nyc_output
+
+# Database
+*.sql
+*.db
+*.sqlite
+*.dump
+*.custom
+
+# Environment
+.env
+.env.*
+!.env.example
+
+# Cache
+.cache
+.eslintcache
+.stylelintcache
+
+# Temp files
+*.tmp
+*.temp
+.DS_Store
+
+# Documentation
+CHANGELOG.md
+*.pdf
+
+# Git
+.git
+.gitignore
+
+# Prisma
+prisma/migrations/
+
+# Generated files
+lecoffre-ressources-dev/dist/
diff --git a/CLAUDE.md b/CLAUDE.md
new file mode 100644
index 0000000..922394f
--- /dev/null
+++ b/CLAUDE.md
@@ -0,0 +1,227 @@
+---
+description: Règles pour tous aussi pour l'IA et pour Cursor
+alwaysApply: true
+---
+
+# Règles pour tous aussi pour l'IA
+
+## General
+
+### Communication et langues
+
+* Répond en français
+* Code, documente le code, et fait les commits en anglais
+
+### Restrictions et interdictions
+
+* ne déclanche jamais la CI
+* n'écris pas en base, jamais, les scripts doivent le faire
+* ne masque pas les sorties des scripts
+* ne fait jamais de certificats auto-signés
+* ne modifie jamais les variables d'environnement
+* ne configure jamais d'alternative htttp au lieu de https
+* ne déploiement jamais de génération de certificats sans faire valider
+* ne lance rien en arrière plan
+
+### Processus de développement
+
+* réponds en priorité aux questions posées
+* avant d'implementer une solution demande la validation générales et pérennes
+* ne corrige pas les bugs avant d'avoir identifier la root cause des problèmes et corrige avant tout la root cause des problèmes
+* cherche la cause de la cause des problèmes jusqu'à la root cause
+* il faut corriger les raisons des erreurs, cherche toujours à corriger les problèmes et ne cherche pas à les rendre acceptables
+* bases toi en priorité sur des id ou des hash de id plutot que sur des libellés ou valeurs
+
+### Vérifications et qualité
+
+* vérifie les fichiers après modification ou lecture pour :
+  * ajouter des logs
+  * supprimer du code mort
+  * ajouter des commentaires ou des questions en commentaires
+* corrige les erreurs de lint par 10 en lançant à chaque fois au début et à la fin des série de 10 un test de turbopack jusqu'au passage OK de turbopack
+* Dans les fichiers markdown respecter MD032 (blanks-around-lists), MD033 (no-inline-html), MD040 (fenced-code-language). Exécuter `npm run lint:markdown` pour vérifier.
+
+### Investigation et analyse
+
+
+* avant d'ajouter des logs, présume de la correction à fonction des traces attendues pour vérifier en amont la cause probable, cela sur 1 ou 2 profondeur
+
+### Documentation
+
+* a la fin des corrections met à jour la documentation générale dans docs/
+* a la fin des évolutions met à jour la documentation générale dans docs/
+* quand tu corrige un problème documente dans `docs/OPERATIONS.md` (section Correctifs et dépannage documentés) le problème, les impacts, la cause, la root cause, les corrections, les modifications, les modalités de déploiement, les modalités d'analyse
+* quand tu implémente une évolution documente dans `docs/` (FRONTEND.md, CODE_STANDARDS.md, OPERATIONS.md selon le périmètre) l'objectif, les impacts, les modifications, les modalités de déploiement, les modalités d'analyse
+
+## Préparation
+
+* **Répertoires :** Les application du services sont dans les autres dossiers à part `logs/`, `deploy/`, `todoFix/`, `docs/`, `user_stories/`.
+* **Analyse fine :** Analyse du `README.md` et des `README.md` des applications.
+* **Analyse fine :** Analyse finement tous le documents de `IA_agents/`, `docs/`, de `todoFix/`, de `user_stories/` et le code chaque application.
+* **Analyse fine :** Analyse finement `deploy/scripts/bump-version.sh`.
+* **Analyse fine :** Analyse finement `deploy/scripts/build-and-deploy.sh`.
+* **User Stories :** Consulter `user_stories/INDEX.md` pour comprendre les 43 user stories et leurs dépendances. Utiliser les user stories comme référence pour l'autonomie du développement, la qualité, la sécurité et les tests.
+
+## ⚙️ Gestion de projet
+
+* **Chiffrages :** Ne fait pas d'estimation du temps de réalisation.
+* **Planning :** Ne fait pas de roadmap.
+
+## 🤝 Collaboration et Workflow
+
+* **Ouverture aux modifications externes :** Comprendre et accepter que le projet puisse évoluer via des contributions extérieures.
+* **Validation préalable :** Toute poussée de code (`git push`) ou déploiement doit être validée au préalable.
+* **Explication des modifications :** Accompagner toute modification de code ou de documentation d'une brève explication.
+
+* **Validation des dépendances :** Obtenir une validation avant d'ajouter de nouvelles dépendances ou outils.
+* **Résultats attendus :** Ne liste pas les résultats attendus dans tes synthèses.
+* **Résultats :** Ne présume pas de résultats non testés, ne conclue pas sans avoir de preuve ou de validation que c'est OK.
+* **Commits :** Les commits doivent être exhaustifs et synthétiques avec ``**Motivations :**`,`**Root causes :**`,`**Correctifs :**`,`**Evolutions :**`,`**Page affectées :**` en bullets points, aucun besoin de totaux par exemple de fichiers modifiés ou de nombre de lignes.
+* **Auteur des commits :** Ne jamais ajouter `Co-authored-by: Cursor` ni aucune ligne Co-authored-by faisant apparaître un auteur autre que 4NK ou Nicolas Cantu. L'auteur du commit doit être 4NK ou Nicolas Cantu uniquement.
+* **Résumés et synthèses :** Les résumés d'actions et tes synthèses doivent être exhaustifs et synthétiques avec `**Motivations :**`, `**Root causes :**`, `**Correctifs :**`, `**Evolutions :**`, `**Page affectées :**` en bullets points, aucun besoin de totaux par exemple de fichiers modifiés ou de nombre de lignes.
+* **Rapports :** Ne fait pas de rapports apres tes actions.
+
+## ⚙️ Gestion de l'Environnement et des Configurations
+
+* **Accès aux `.env` :** Les fichiers `.env` de production sont inaccessibles et ne doivent pas être modifiés.
+* **Mise à jour de `env.example` :** Maintenir `env.example` systématiquement à jour et ne jamais intégrer de paramétrage sensible directement dans le code.
+* **Ports :** Ne modifie jamais les ports même si il ne sont pas ceux par défaut.
+* **Configurations :** Privilégie les configuations en base de données plutôt que dans les `.env`.
+
+## 💻 Qualité du Code et Bonnes Pratiques
+
+* **Respect des conventions :** Adhérer au style de code et aux conventions existantes du projet.
+* **Sécurité :** Prioriser la sécurité en ne codant jamais en dur des informations sensibles (y compris dans la documentation) et en validant systématiquement les entrées utilisateur.
+* **Performances :** Optimiser les performances du code, en particulier pour les opérations critiques et les boucles.
+* **Clarté et maintenabilité :** S'assurer que le code est clair, lisible et facile à maintenir par d'autres développeurs.
+
+#### Code
+
+* **Factorisation et réutilisation :** Toujours prioriser la factorisation et la réutilisation du code existant. Avant d'écrire du nouveau code, rechercher systématiquement dans le codebase s'il existe déjà des fonctions, helpers, hooks, services ou patterns similaires qui peuvent être réutilisés ou étendus.
+* **Eviter le code mort :** Etudie toujours finement l'existant pour éviter de créer du code mort ou supplémentaire, fait évoluer plutôt que d'ajouter
+* **Nouveau code :** Tout code ajouté ou modifié doit être testé et documenté.
+* **Patterns réutilisables :** Consulter `docs/CODE_STANDARDS.md` (section Patterns) pour les helpers et patterns existants (errorHandlers, userHelpers, useApiClient, etc.). Ne pas réinventer ce qui existe déjà.
+* **Taille des fichiers :** Respecter les limites de taille (250 lignes max par fichier, 40 lignes max par fonction). max-params 4, max-depth 4, complexity 10, max-nested-callbacks 3. Documenter les exceptions dans `docs/OPERATIONS.md` (section Correctifs et dépannage) avec plan de refactor.
+* **Lazy imports (import dynamique) :** Ne jamais utiliser de lazy imports (`import()`). Utiliser uniquement des imports statiques. Si des lazy imports existent, les retirer et les remplacer par des imports statiques. Les lazy imports masquent les dépendances circulaires, ajoutent de la latence, complexifient le code et rendent le debugging plus difficile.
+* **Imports par défaut :** Toujours nommer les imports par défaut. Ne jamais utiliser d'imports anonymes (`import something from`). Utiliser des noms explicites pour tous les imports par défaut.
+* **Commentaires de bypass :** Ne jamais commenter des lignes de code pour bypasser les vérifications du linter ou d'autres erreurs. Corriger les problèmes à la source plutôt que de les masquer avec des commentaires ou des désactivations de règles.
+
+#### 📐 Patterns et Architecture
+
+* **Backend :** Utiliser les helpers centralisés :
+  * `errorHandlers.ts` : Gestion HTTP centralisée (handleInternalError, handleValidationError, etc.)
+  * `errorLoggers.ts` : Logging standardisé (logError, logValidationError, etc.)
+  * `errorMessages.ts` : Messages d'erreur centralisés
+  * `userHelpers.ts` : Helpers utilisateurs (isSuperAdminUser, extractUserData, etc.)
+* **Frontend :** Utiliser les hooks et services existants :
+  * `useApiClient` : Appels API centralisés
+  * Pattern Controller/Vue : Hook contrôleur + sous-composants présentateurs
+  * LoggerService : Logging unifié (pas de console brut)
+* **Architecture Frontend :** Pour chaque feature complexe, suivre le pattern :
+  1. Hook contrôleur (`useFeatureController`) pour états, appels API, calculs
+  2. Sous-composants présentateurs pour découper l'UI
+  3. Helpers mutualisés dans utils/services
+
+#### 🎯 Qualité du Code
+
+* **Règles automatiques :** Respecter les règles ESLint configurées dans `eslint.config.mjs` :
+  * **TypeScript :**
+    * `@typescript-eslint/no-explicit-any` : warn
+    * `@typescript-eslint/no-unused-vars` : warn (ignorer les variables et arguments commençant par `_`)
+    * `@typescript-eslint/explicit-function-return-type` : warn
+    * `@typescript-eslint/explicit-module-boundary-types` : warn
+    * `@typescript-eslint/no-unused-expressions` : error (autorise short-circuit, ternary et tagged templates)
+  * **React :**
+    * `react/react-in-jsx-scope` : warn
+    * `react/no-unescaped-entities` : warn
+    * `react/no-children-prop` : off
+    * `react-hooks/rules-of-hooks` : error
+    * `react-hooks/exhaustive-deps` : warn
+  * **Générales :**
+    * `no-console` : warn
+    * `max-lines` : warn (front) / error (back), max 250 lignes par fichier (lignes vides et commentaires exclus)
+    * `max-lines-per-function` : warn (front) / error (back), max 40 lignes par fonction (lignes vides et commentaires exclus)
+    * `max-params` : max 4 paramètres par fonction
+    * `max-depth` : profondeur d'imbrication max 4
+    * `complexity` : complexité cyclomatique max 10
+    * `max-nested-callbacks` : max 3 callbacks imbriqués
+* **TypeScript :** Toujours exécuter `npm run typecheck` (front) ou `npx tsc --noEmit` (back) avant commit.
+* **Build :** Vérifier que `npm run build` passe sans erreurs.
+* **Dépassements :** Si un fichier/fonction dépasse les limites :
+  1. Découper immédiatement si faisable
+  2. Sinon, documenter dans `docs/OPERATIONS.md` (section Correctifs et dépannage) avec plan de refactor + échéance
+  3. Ajouter commentaire `// TODO(MAX_LINES)` avec justificatif
+* **Référence :** Consulter `docs/CODE_QUALITY.md` pour les spécifications complètes.
+
+#### 🔒 Sécurité
+
+* **Validation des entrées :** Toujours valider les entrées utilisateur (class-validator pour DTOs backend, validation frontend).
+* **Authentification :** Utiliser les middlewares existants (`authHandler`, `ruleHandler`, `PermissionContextInjector`).
+* **Secrets :** Jamais de secrets en dur. Utiliser `system_configuration` en base de données.
+* **Logging sensible :** Ne jamais logger de données sensibles (RIB, tokens, OTP). Utiliser Winston uniquement.
+* **Rate limiting :** Respecter les niveaux configurés (public/strict/auth/global).
+* **Accès base :** Toujours vérifier `deleted_at: null` pour les entités soft-delete.
+* **Référence :** Consulter `docs/CODE_SECURITY.md` pour les spécifications complètes.
+
+#### 🧪 Tests
+
+* **Couverture des tests :** Rédiger des tests unitaires et d'intégration pour toute nouvelle fonctionnalité ou correction de bug.
+* **Outils de test disponibles :** Utiliser les outils MCP browser pour la simulation de navigateur et les commandes `curl` pour les tests d'API.
+* **Tests Browser :** Utiliser les outils MCP browser pour les tests E2E. Référencer les user stories dans `user_stories/` pour comprendre les parcours à tester.
+* **User Stories comme tests :** Consulter `user_stories/INDEX.md` et les fichiers `US*.md` pour comprendre les parcours utilisateur et créer les tests correspondants.
+* **Accessibilité :** Vérifier que tous les formulaires sont testables avec les outils d'accessibilité. Consulter `user_stories/ACCESSIBILITY_TESTING.md` pour les modalités de test.
+* **Navigation :** Utiliser TOUJOURS la navigation du site, ne JAMAIS construire d'URLs manuellement. Suivre le parcours utilisateur naturel.
+* **Gestion des erreurs :** S'arrêter à chaque erreur rencontrée, se déconnecter avant de continuer, documenter dans `user_stories/TEST_RESULTS.md`.
+* **Comptes de test :** Consulter `user_stories/TEST_ACCOUNTS.md` pour les comptes disponibles. Utiliser `user_stories/scripts/prepare-test-data.sh` pour préparer les données de test.
+
+## 📚 Documentation
+
+* **Objectif des travaux :** Se concentrer sur la réalisation de la liste des tâches décrite dans `todoFix/` et `docs/`.
+* **Structure de la documentation :**
+  * La documentation générale et pérenne se trouve dans `docs/`.
+  * Les features et corrections sont documentées dans `docs/` (OPERATIONS.md section Correctifs et dépannage, FRONTEND.md, CODE_STANDARDS.md) ; les tâches en cours dans `todoFix/`.
+  * Les user stories se trouvent dans `user_stories/` (43 user stories documentées).
+* **User Stories :** Consulter `user_stories/INDEX.md` pour la liste complète et les dépendances. Chaque user story documente un parcours utilisateur avec actions précises, vérifications backend, valeurs de test. Utiliser comme référence pour l'autonomie du développement.
+* **Qualité et sécurité :** Consulter `docs/CODE_QUALITY.md` et `docs/CODE_SECURITY.md` pour les spécifications complètes.
+* **Utilisation de la documentation existante :** Ne pas ajouter de nouveaux documents, mais enrichir et mettre à jour l'existant.
+* **Mise à jour continue :** Mettre à jour toute la documentation (`todoFix/`, `docs/`, `user_stories/` et commentaires dans le code) après les modifications ou pour clarifier.
+* **Changelog :** Le fichier `CHANGELOG.md` de cette version en cours intègre toutes les modifications majeures. Ce contenu est repris dans la splash notice de l'application front. Les mises à jour mineures sont ajoutées au `CHANGELOG.md` sans enlever d'élément existant.
+
+## 📊 Logging et Gestion des Erreurs
+
+* **Centralisation des logs :** Centraliser les logs dans les répertoires `logs/` des applications et dans le répertoire `logs/` du projet pour les logs hors applications (déploiement par exemple)
+* **Système de logging :** Implémenter une gestion d'erreurs robuste et utiliser le système de logging Winston pour toutes les sorties (info, warn, error, debug, etc.).
+* **Traçabilité :** Logger toutes les valeurs, états clés et retours d'API.
+
+## 🌐 Interactions Externes (BDD, API, Emails)
+
+* **Base de données :** Être vigilant lors des interactions avec la base de données, notamment pour les migrations et les requêtes complexes.
+* **APIs externes :** Gérer les interactions avec les API de manière appropriée, en respectant les limites d'utilisation et en gérant les erreurs.
+* **Emails :** Gérer les envois d'emails de manière appropriée pour éviter le spam et gérer les erreurs.
+
+## 🚀 Déploiement
+
+* **Préparation du déploiement :** Décrire et préparer le déploiement des correctifs et des évolutions.
+* **Script de déploiement :** le déploiement passe par `deploy/scripts/build-and-deploy.sh`, ne masque pas la sortie (pas de 2>&1 par exemple).
+* **Bilan de déploiement :** ne fait pas de bilan de déploiement.
+* **Lancement :** ne lance aucun déploiement sans demander avant
+
+## 🚨 Gestion des Problèmes
+
+* **Résolution directe :** En cas de problème (toutes criticités), ne jamais simplifier, contourner, forcer un résultat en dur, ou créer des bouchons. Le problème doit être résolu à sa racine.
+
+## 🗄️ Gestion des Fichiers
+
+* **Versions uniques :** Ne pas créer de versions alternatives des fichiers.
+* **Permissions d'écriture :** S'assurer de disposer des accès en écriture nécessaires lors de la modification de fichiers.
+
+## Mise à jour de ces règles
+
+* **Propositions d'ajouts :** Quand tu apprends de nouvelles instructions qui te semblent pertinentes pour ces règles, propose de les ajouter.
+
+* **Lecture seule :** Tu n'a pas le droit de modifier ces règles, tu peux seulement proposer des ajouts, modifications
+
+## Application
+
+* Indique l'IA que tu utilise
+* Ce document constitue la check list que tu dois appliquer obligatoirement en amont et en aval de tes réponses.
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..737e90c
--- /dev/null
+++ b/README.md
@@ -0,0 +1,43 @@
+# ia_dev
+
+Dépôt de pilotage par l’IA pour les projets : **équipe d’agents IA** réutilisable par tout projet qui inclut ia_dev en submodule Git. Objectif : une équipe autonome couvrant la **documentation**, le **code** (correctifs, évolutions), le **ticketing** (issues Gitea, mails), le **devops** (push, déploiement, branches), la **sécurité** et la **qualité** (lint, règles).
+
+**Principe** : le projet hôte n’a **aucune dépendance** vers ia_dev (aucun script du projet n’appelle ia_dev). Seul ia_dev, en fonction du paramétrage (`.ia_project`, `ai_project_id`, `projects/<id>/conf.json`), sollicite le projet (lecture de la config, appels aux scripts deploy, gitea-issues, etc.).
+
+## Usage
+
+- **En submodule** : ce dépôt est inclus comme sous-module Git dans chaque projet. La config par projet est dans `projects/<id>/conf.json` ; le slug `<id>` est donné par le fichier `.ia_project` ou `ai_project_id` à la racine du dépôt hôte, ou par la variable d’environnement `IA_PROJECT`.
+- **Scripts** : à lancer depuis la **racine du dépôt du projet** (ex. `./ia_dev/deploy/pousse.sh`, `./ia_dev/gitea-issues/tickets-fetch-inbox.sh`).
+
+Voir `projects/README.md` pour le schéma de configuration et les exemples.
+
+## Agents et domaines
+
+Les agents Cursor sont dans `.cursor/agents/`. Chaque agent indique où se trouve la doc : **projets gérés** → `projects/<id>/docs` ; **ia_dev** → `projects/ia_dev/docs`.
+
+| Domaine | Agents / composants |
+|---------|---------------------|
+| **Doc** | `docupdate` ; `projects/ia_dev/docs/` (GITEA_ISSUES_SCRIPTS_AGENTS, TICKETS_SPOOL_FORMAT, WORKFLOWS_AND_COMPONENTS) ; migration wiki (`gitea-issues/wiki-migrate-docs.sh`). |
+| **Code** | `fix`, `evol`, `code`, `fix-search` ; workflow correctifs/évolutions (fix-search → fix → push-by-script ; evol + code). |
+| **Ticketing** | `gitea-issues-process`, `agent-loop` ; spooler `projects/<id>/data/issues` ; scripts `gitea-issues/` (issues Gitea, mails, boucle récupération/traitement) ; hook `.cursor/hooks/remonter-mails.sh`. |
+| **IA notaire (ai_working_help)** | `notary-ai-loop`, `notary-ai-process` ; API `ai_working_help/server.js` (POST enqueue, GET response) ; spooler `projects/<id>/data/notary-ai/{pending,responded}` ; scripts `ai_working_help/notary-ai/` (list-pending, write-response). |
+| **DevOps** | `push-by-script`, `deploy-by-script`, `deploy-pprod-or-prod`, `branch-align-by-script-from-test`, `change-to-all-branches` ; scripts `deploy/` (pousse.sh, scripts_v2, alignement branches). |
+| **Sécurité / Qualité** | Règles `.cursor/rules/` ; pas de secrets en dur (`.secrets`, config par projet) ; `fix-lint` ; clôture obligatoire (`.cursor/rules/cloture-evolution.mdc`) pour tous les agents. |
+
+Référence détaillée scripts et agents : `projects/ia_dev/docs/GITEA_ISSUES_SCRIPTS_AGENTS.md`. Index de la doc ia_dev : `projects/ia_dev/docs/README.md`.
+
+## Répertoires d’exécution
+
+Les scripts sont invoqués depuis la **racine du dépôt hôte**. Ils s’y placent (ou s’y ré-exécutent) avant de continuer.
+
+- **deploy/** : `PROJECT_ROOT` = git toplevel ; ré-exécution depuis la racine si besoin. Chemin du script résolu (`readlink -f` / `realpath`) pour que `IA_DEV_ROOT` soit correct même si `deploy` est un symlink vers `ia_dev/deploy`.
+- **gitea-issues/** : racine projet = parent de ia_dev ; `.secrets` sous ia_dev ; **logs** et **data** (spooler tickets) par projet sous `projects/<id>/logs/` et `projects/<id>/data/issues/` (id = slug, ex. contenu de `ai_project_id`).
+- **ai_working_help/** : API (server.js) et scripts `notary-ai/` ; spooler par projet sous `projects/<id>/data/notary-ai/{pending,responded}` ; scripts invoqués depuis la racine du dépôt (parent de ia_dev). Doc : `ai_working_help/docs/notary-ai-api.md`.
+
+## Scripts centralisés (submodule)
+
+Les scripts suivants sont centralisés dans `ia_dev/deploy/`. Le projet n’a pas à fournir de wrapper ; on invoque depuis la racine : `./ia_dev/deploy/bump-version.sh`, `./ia_dev/deploy/pousse.sh`, etc.
+
+- **bump-version.sh** : lecture de `projects/<id>/conf.json` (version.package_json_paths, version.splash_app_name). Invocation : `./ia_dev/deploy/bump-version.sh <version> [message]` depuis la racine du dépôt.
+- **deploy-by-script-to.sh** : enchaîne change-to-all-branches (ia_dev/deploy), puis checkout/pull/deploy via `deploy/scripts_v2/deploy.sh` du projet. Le projet peut avoir `deploy/deploy-by-script-to.sh` → `exec …/ia_dev/deploy/deploy-by-script-to.sh "$@"`.
+- **deploy/_lib/** : bibliothèque partagée pour les scripts de déploiement (`colors.sh`, `env-map.sh`, `ssh.sh`, `git-flow.sh`). Pour que `deploy/scripts_v2/` du projet utilise cette version : depuis la racine du projet, `rm -rf deploy/scripts_v2/_lib` puis `ln -s ../../ia_dev/deploy/_lib deploy/scripts_v2/_lib` (les scripts font `source "$SCRIPT_DIR/_lib/…"`).
diff --git a/ai_working_help/docs/notary-ai-api.md b/ai_working_help/docs/notary-ai-api.md
new file mode 100644
index 0000000..ca40b40
--- /dev/null
+++ b/ai_working_help/docs/notary-ai-api.md
@@ -0,0 +1,60 @@
+# Notary AI – API et spooler (ai_working_help)
+
+## Rôle
+
+**ai_working_help** est une API d’écoute qui tourne sur la **machine où Cursor et la boucle d’agents** sont utilisés (pas sur le serveur où l’app est déployée). L’application déployée appelle cette API (NOTARY_AI_AGENT_URL) pour enqueuer les questions et récupérer les réponses ; les réponses sont produites par les agents Cursor (notary-ai-loop + notary-ai-process) qui lisent/écrivent le spooler sur ce PC.
+
+## Rôle métier et format de réponse (côté agent)
+
+- **Utilisateurs autorisés** : strictement le notaire connecté et les collaborateurs (mêmes droits que le notaire). Les invités et les tiers ne peuvent pas utiliser le chat IA.
+- **Périmètre** : l'agent répond **uniquement** sur le **dossier en cours** et les **documents fournis**. Il peut lire en base et consulter strictement le dossier concerné et les documents du dossier.
+- **Spécialisation** : droit, et plus encore les activités notariales. Réponses spécifiques au type de dossier et aux documents fournis.
+- **Interdiction** : ne jamais communiquer de RIB ni de coordonnées transactionnelles.
+
+**Format de réponse (4 champs)** renvoyés par l'API dans `response` :
+
+| Champ | Contenu |
+|-------|--------|
+| **answer** | Réponse textuelle directe à la question posée. |
+| **nextActionsTable** | Tableau des prochaines actions à mener sur le dossier pour ce type de dossier : documents à fournir / demander / faire valider aux membres du dossier, et de manière générale pour ce type de dossier à l'extérieur. |
+| **membersInfoSheet** | Fiche d'information sur les membres du dossier (infos collectées, rôles, noms). |
+| **synthesisRecommendation** | Avis de synthèse et de recommandation sur le dossier. |
+
+## Id projet et résolution
+
+- **Côté API** : le token est trouvé en parcourant tous les projets et tous les envs comme décrit précédemment : pour chaque `projects/<id>/.secrets/<env>/ia_token`, on compare le Bearer au contenu du fichier ou à (contenu + env). La première correspondance donne l'id projet et l'env (test, pprod, prod, etc.).
+- **Côté scripts** : id (et env) résolus par **MAIL_TO**, **AI_AGENT_TOKEN** (lit `.secrets/<env>/ia_token`), **IA_PROJECT**, ou **ai_project_id** / **.ia_project** à la racine du dépôt parent.
+- Données par projet : `projects/<id>/data/notary-ai/` (pending/, responded/).
+
+## API (serveur Node)
+
+- **POST /v1/enqueue**  
+  Body : `{ request_uid, folder_uid, office_uid, user_id, question, folder_context }`.  
+  Réponse **202** : `{ request_uid }`.  
+  Écrit dans `projects/<id>/data/notary-ai/pending/<safe_uid>.json`. **Authentification** : header `Authorization: Bearer <token>` obligatoire (le token identifie le projet) ; 401 si absent ou inconnu.
+
+- **GET /v1/response/:request_uid**  
+  Réponse **200** : `{ status: "pending" }` ou `{ status: "responded", response: { answer, nextActionsTable, membersInfoSheet, synthesisRecommendation } }`.  
+  Lit d’abord `projects/<id>/data/notary-ai/responded/`, sinon `pending/`. **Authentification** : idem (token obligatoire).
+
+- **GET /v1/health** et **GET /health** : santé du service (sans authentification).
+
+Lancement : depuis **ia_dev** : `cd ia_dev && node ai_working_help/server.js`. Port par défaut : **3020** (`AI_WORKING_HELP_PORT`).
+
+## Configuration côté application déployée
+
+- **NOTARY_AI_AGENT_URL** : URL de base **sans** slug, sans slash final, ex. : `http://192.168.1.173:3020/v1`. Le backend ajoute `/enqueue` et `/response/:request_uid`.
+- **NOTARY_AI_AGENT_TOKEN** : le token envoyé par l’app est de la forme **base** + **env**. **env** est le nom d’environnement (test, pprod, prod), à modifier selon les environnements. Côté ia_dev, ce token est trouvé en parcourant tous les projets et tous les envs (fichiers `projects/<id>/.secrets/<env>/ia_token`) ; le fichier peut contenir le token complet (ex. `nicolecoffreiotest`) ou la base seule (ex. `nicolecoffreio`), le serveur comparant alors le Bearer à `contenu_du_fichier + env`.
+
+## Scripts (depuis la racine du dépôt, parent de ia_dev)
+
+- **./ia_dev/ai_working_help/notary-ai/list-pending-notary-ai.sh** : liste les fichiers `projects/<id>/data/notary-ai/pending/*.json` (id résolu par AI_AGENT_TOKEN, IA_PROJECT, ai_project_id ou .ia_project).
+- **./ia_dev/ai_working_help/notary-ai/write-response-notary-ai.sh** : écrit la réponse dans responded/, supprime le pending.  
+  Options : `--pending-path <path> --response-json <json>` ou `--request-uid <uid> --answer "..." [--next-actions-table "..." ] [--members-info-sheet "..."] [--synthesis-recommendation "..."]`.
+
+## Agents Cursor
+
+- **notary-ai-loop** (`.cursor/agents/notary-ai-loop.md`) : orchestre la boucle (liste pending, lance notary-ai-process ; x cycles ou une fois).
+- **notary-ai-process** (`.cursor/agents/notary-ai-process.md`) : pour chaque pending, produit les 4 champs et appelle write-response-notary-ai.sh.
+
+Les agents sont dans **ia_dev/.cursor/agents/**. À invoquer depuis le dépôt qui contient ia_dev (racine = parent de ia_dev) ; les scripts s'exécutent depuis cette racine.
diff --git a/ai_working_help/notary-ai/lib.sh b/ai_working_help/notary-ai/lib.sh
new file mode 100644
index 0000000..9fccfcb
--- /dev/null
+++ b/ai_working_help/notary-ai/lib.sh
@@ -0,0 +1,33 @@
+#
+# Shared config for notary-ai spooler scripts (pending/responded).
+# Source from notary-ai/*.sh. Resolves PROJECT_SLUG and data dirs under projects/<slug>/data/notary-ai/.
+#
+set -euo pipefail
+
+NOTARY_AI_DIR="${NOTARY_AI_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+IA_DEV_ROOT="$(cd "${NOTARY_AI_DIR}/../.." && pwd)"
+PROJECT_ROOT="$(cd "${IA_DEV_ROOT}/.." && pwd)"
+export PROJECT_ROOT IA_DEV_ROOT
+if [[ -f "${IA_DEV_ROOT}/lib/project_config.sh" ]]; then
+	# shellcheck source=../../lib/project_config.sh
+	source "${IA_DEV_ROOT}/lib/project_config.sh"
+fi
+if [[ -z "${PROJECT_SLUG:-}" ]]; then
+	PROJECT_SLUG="${AI_PROJECT_SLUG:-}"
+fi
+if [[ -n "${PROJECT_SLUG:-}" && -n "${IA_DEV_ROOT:-}" ]]; then
+	DATA_NOTARY_AI_DIR="${IA_DEV_ROOT}/projects/${PROJECT_SLUG}/data/notary-ai"
+	DATA_NOTARY_AI_PENDING_DIR="${DATA_NOTARY_AI_DIR}/pending"
+	DATA_NOTARY_AI_RESPONDED_DIR="${DATA_NOTARY_AI_DIR}/responded"
+	mkdir -p "${DATA_NOTARY_AI_PENDING_DIR}" "${DATA_NOTARY_AI_RESPONDED_DIR}"
+else
+	DATA_NOTARY_AI_DIR=""
+	DATA_NOTARY_AI_PENDING_DIR=""
+	DATA_NOTARY_AI_RESPONDED_DIR=""
+fi
+export DATA_NOTARY_AI_DIR
+export DATA_NOTARY_AI_PENDING_DIR
+export DATA_NOTARY_AI_RESPONDED_DIR
+export PROJECT_SLUG
+export IA_DEV_ROOT
+export PROJECT_ROOT
diff --git a/ai_working_help/notary-ai/list-pending-notary-ai.sh b/ai_working_help/notary-ai/list-pending-notary-ai.sh
new file mode 100755
index 0000000..38a2c6d
--- /dev/null
+++ b/ai_working_help/notary-ai/list-pending-notary-ai.sh
@@ -0,0 +1,19 @@
+#!/usr/bin/env bash
+# List pending JSON files in projects/<slug>/data/notary-ai/pending/.
+# Run from repo root (parent of ia_dev). Output: one path per line.
+# Usage: ./ia_dev/ai_working_help/notary-ai/list-pending-notary-ai.sh
+set -euo pipefail
+NOTARY_AI_DIR="${NOTARY_AI_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+export NOTARY_AI_DIR
+ROOT="$(cd "${NOTARY_AI_DIR}/../../.." && pwd)"
+cd "$ROOT"
+# shellcheck source=lib.sh
+source "${NOTARY_AI_DIR}/lib.sh"
+if [[ -z "${DATA_NOTARY_AI_PENDING_DIR:-}" || ! -d "${DATA_NOTARY_AI_PENDING_DIR}" ]]; then
+	echo "[notary-ai] DATA_NOTARY_AI_PENDING_DIR not set or not a directory. Set IA_PROJECT or ai_project_id at repo root." >&2
+	exit 1
+fi
+for f in "${DATA_NOTARY_AI_PENDING_DIR}"/*.json; do
+	[[ -f "$f" ]] || continue
+	echo "$f"
+done
diff --git a/ai_working_help/notary-ai/write-response-notary-ai.sh b/ai_working_help/notary-ai/write-response-notary-ai.sh
new file mode 100755
index 0000000..9608473
--- /dev/null
+++ b/ai_working_help/notary-ai/write-response-notary-ai.sh
@@ -0,0 +1,81 @@
+#!/usr/bin/env bash
+# Write agent response to responded/ and remove the pending file.
+# Usage:
+#   --pending-path <path> --response-json <json_string>
+#   or --request-uid <uid> --answer "..." [--next-actions-table "..." ] [--members-info-sheet "..."] [--synthesis-recommendation "..."]
+set -euo pipefail
+NOTARY_AI_DIR="${NOTARY_AI_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+export NOTARY_AI_DIR
+ROOT="$(cd "${NOTARY_AI_DIR}/../../.." && pwd)"
+cd "$ROOT"
+# shellcheck source=lib.sh
+source "${NOTARY_AI_DIR}/lib.sh"
+if [[ -z "${DATA_NOTARY_AI_RESPONDED_DIR:-}" || ! -d "${DATA_NOTARY_AI_RESPONDED_DIR}" ]]; then
+	echo "[notary-ai] DATA_NOTARY_AI_RESPONDED_DIR not set or not a directory." >&2
+	exit 1
+fi
+require_jq() {
+	command -v jq &>/dev/null || { echo "[notary-ai] jq is required." >&2; return 1; }
+}
+PENDING_PATH=""
+RESPONSE_JSON=""
+REQUEST_UID=""
+ANSWER=""
+NEXT_ACTIONS_TABLE=""
+MEMBERS_INFO_SHEET=""
+SYNTHESIS_RECOMMENDATION=""
+while [[ $# -gt 0 ]]; do
+	case "$1" in
+		--pending-path) PENDING_PATH="$2"; shift 2 ;;
+		--response-json) RESPONSE_JSON="$2"; shift 2 ;;
+		--request-uid) REQUEST_UID="$2"; shift 2 ;;
+		--answer) ANSWER="$2"; shift 2 ;;
+		--next-actions-table) NEXT_ACTIONS_TABLE="$2"; shift 2 ;;
+		--members-info-sheet) MEMBERS_INFO_SHEET="$2"; shift 2 ;;
+		--synthesis-recommendation) SYNTHESIS_RECOMMENDATION="$2"; shift 2 ;;
+		*) echo "[notary-ai] Unknown option: $1" >&2; exit 1 ;;
+	esac
+done
+if [[ -n "${PENDING_PATH:-}" && -n "${RESPONSE_JSON:-}" ]]; then
+	require_jq || exit 1
+	[[ -f "$PENDING_PATH" ]] || { echo "[notary-ai] Pending file not found: $PENDING_PATH" >&2; exit 1; }
+	BASE="$(basename "$PENDING_PATH" .json)"
+	RESPONDED_PATH="${DATA_NOTARY_AI_RESPONDED_DIR}/${BASE}.json"
+	PENDING_DATA="$(jq -c . "$PENDING_PATH")"
+	RESPONSE_OBJ="$(printf '%s' "$RESPONSE_JSON" | jq -c .)"
+	# Merge: pending payload + status responded + response object
+	printf '%s' "$PENDING_DATA" | jq -c --argjson resp "$RESPONSE_OBJ" '. + { status: "responded", response: $resp }' > "${RESPONDED_PATH}"
+	rm -f "$PENDING_PATH"
+	echo "[notary-ai] Wrote ${RESPONDED_PATH}, removed pending."
+	exit 0
+fi
+if [[ -n "${REQUEST_UID:-}" && -n "${ANSWER:-}" ]]; then
+	require_jq || exit 1
+	# Find pending file containing this request_uid
+	FOUND=""
+	for f in "${DATA_NOTARY_AI_PENDING_DIR}"/*.json; do
+		[[ -f "$f" ]] || continue
+		if [[ "$(jq -r '.request_uid // ""' "$f")" = "$REQUEST_UID" ]]; then
+			FOUND="$f"
+			break
+		fi
+	done
+	[[ -n "$FOUND" ]] || { echo "[notary-ai] No pending file with request_uid=$REQUEST_UID" >&2; exit 1; }
+	RESPONSE_OBJ=$(jq -n \
+		--arg a "$ANSWER" \
+		--arg nat "${NEXT_ACTIONS_TABLE:-}" \
+		--arg mis "${MEMBERS_INFO_SHEET:-}" \
+		--arg sr "${SYNTHESIS_RECOMMENDATION:-}" \
+		'{ answer: $a, nextActionsTable: $nat, membersInfoSheet: $mis, synthesisRecommendation: $sr }')
+	PENDING_PATH="$FOUND"
+	RESPONSE_JSON="$RESPONSE_OBJ"
+	BASE="$(basename "$PENDING_PATH" .json)"
+	RESPONDED_PATH="${DATA_NOTARY_AI_RESPONDED_DIR}/${BASE}.json"
+	PENDING_DATA="$(jq -c . "$PENDING_PATH")"
+	printf '%s' "$PENDING_DATA" | jq -c --argjson resp "$RESPONSE_OBJ" '. + { status: "responded", response: $resp }' > "${RESPONDED_PATH}"
+	rm -f "$PENDING_PATH"
+	echo "[notary-ai] Wrote ${RESPONDED_PATH}, removed pending."
+	exit 0
+fi
+echo "[notary-ai] Use --pending-path + --response-json or --request-uid + --answer (and optional fields)." >&2
+exit 1
diff --git a/ai_working_help/package.json b/ai_working_help/package.json
new file mode 100644
index 0000000..e704865
--- /dev/null
+++ b/ai_working_help/package.json
@@ -0,0 +1,13 @@
+{
+  "name": "ai_working_help",
+  "version": "1.0.0",
+  "description": "API spooler for notary AI agent (enqueue / response). Consumed by business app backends; responses produced by Cursor agents (notary-ai-loop + notary-ai-process).",
+  "main": "server.js",
+  "scripts": {
+    "start": "node server.js"
+  },
+  "dependencies": {
+    "body-parser": "^1.20.2",
+    "express": "^4.18.2"
+  }
+}
diff --git a/ai_working_help/server.js b/ai_working_help/server.js
new file mode 100644
index 0000000..e71a9e1
--- /dev/null
+++ b/ai_working_help/server.js
@@ -0,0 +1,163 @@
+/**
+ * ai_working_help API server.
+ * Routes: POST /v1/enqueue, GET /v1/response/:request_uid, GET /health, GET /v1/health.
+ * Project id and env are resolved from the Bearer token by searching all
+ * projects/<id>/.secrets/<env>/ia_token files; the matching project id is used for the spooler.
+ * Spooler: projects/<id>/data/notary-ai/{pending,responded}.
+ */
+const express = require("express");
+const bodyParser = require("body-parser");
+const fs = require("fs");
+const path = require("path");
+
+const app = express();
+app.use(bodyParser.json({ limit: "1mb" }));
+
+const PORT = process.env.AI_WORKING_HELP_PORT || 3020;
+const IA_DEV_ROOT = path.resolve(__dirname, "..");
+const PROJECTS_DIR = path.join(IA_DEV_ROOT, "projects");
+
+/**
+ * Resolve project id and env from token by scanning projects/<id>/.secrets/<env>/ia_token.
+ * @returns {{ projectId: string, env: string } | null}
+ */
+function resolveProjectAndEnvByToken(token) {
+  if (!token || typeof token !== "string") return null;
+  const t = token.trim();
+  if (!t) return null;
+  const dirs = fs.readdirSync(PROJECTS_DIR, { withFileTypes: true });
+  for (const d of dirs) {
+    if (!d.isDirectory()) continue;
+    const secretsDir = path.join(PROJECTS_DIR, d.name, ".secrets");
+    try {
+      if (!fs.existsSync(secretsDir) || !fs.statSync(secretsDir).isDirectory()) continue;
+      const envDirs = fs.readdirSync(secretsDir, { withFileTypes: true });
+      for (const ed of envDirs) {
+        if (!ed.isDirectory()) continue;
+        const tokenPath = path.join(secretsDir, ed.name, "ia_token");
+        if (!fs.existsSync(tokenPath) || !fs.statSync(tokenPath).isFile()) continue;
+        const content = fs.readFileSync(tokenPath, "utf8").trim();
+        const envName = ed.name;
+        // Token is either full value in file (content) or base in file + env suffix: nicolecoffreio<env>
+        if (content === t || content + envName === t) return { projectId: d.name, env: envName };
+      }
+    } catch (_) {
+      // skip
+    }
+  }
+  return null;
+}
+
+function resolveProjectIdByToken(token) {
+  const resolved = resolveProjectAndEnvByToken(token);
+  return resolved ? resolved.projectId : null;
+}
+
+function requireApiTokenAndResolveProject(req, res, next) {
+  const authHeader = req.headers.authorization;
+  if (!authHeader || typeof authHeader !== "string") {
+    return res.status(401).json({ message: "Invalid or missing token" });
+  }
+  const match = authHeader.match(/^Bearer\s+(.+)$/i);
+  const token = match ? String(match[1]).trim() : "";
+  const resolved = resolveProjectAndEnvByToken(token);
+  if (!resolved) {
+    return res.status(401).json({ message: "Invalid or missing token" });
+  }
+  req.projectId = resolved.projectId;
+  req.projectEnv = resolved.env;
+  next();
+}
+
+function safeUid(uid) {
+  return String(uid).replace(/[^a-zA-Z0-9-_]/g, "_").slice(0, 128) || "unknown";
+}
+
+function projectDataDir(projectId) {
+  if (!projectId || /[^a-zA-Z0-9-_]/.test(projectId)) return null;
+  return path.join(PROJECTS_DIR, projectId, "data", "notary-ai");
+}
+
+function findFileByRequestUid(dir, requestUid) {
+  if (!fs.existsSync(dir)) return null;
+  const files = fs.readdirSync(dir);
+  for (const f of files) {
+    if (!f.endsWith(".json")) continue;
+    const filePath = path.join(dir, f);
+    try {
+      const data = JSON.parse(fs.readFileSync(filePath, "utf8"));
+      if (data.request_uid === requestUid) return { path: filePath, data };
+    } catch (_) {
+      // skip invalid json
+    }
+  }
+  return null;
+}
+
+app.get("/health", (req, res) => {
+  res.status(200).json({ status: "ok" });
+});
+
+app.get("/v1/health", (req, res) => {
+  res.status(200).json({ status: "ok" });
+});
+
+app.post("/v1/enqueue", requireApiTokenAndResolveProject, (req, res) => {
+  const dir = projectDataDir(req.projectId);
+  if (!dir) {
+    return res.status(400).json({ message: "Invalid project" });
+  }
+  const pendingDir = path.join(dir, "pending");
+  const respondedDir = path.join(dir, "responded");
+  const body = req.body || {};
+  const requestUid = body.request_uid;
+  if (!requestUid || typeof requestUid !== "string") {
+    return res.status(400).json({ message: "Missing request_uid" });
+  }
+  const payload = {
+    request_uid: requestUid,
+    folder_uid: body.folder_uid,
+    office_uid: body.office_uid,
+    user_id: body.user_id,
+    question: body.question,
+    folder_context: body.folder_context || {},
+    status: "pending",
+  };
+  try {
+    if (!fs.existsSync(pendingDir)) fs.mkdirSync(pendingDir, { recursive: true });
+    if (!fs.existsSync(respondedDir)) fs.mkdirSync(respondedDir, { recursive: true });
+    const safe = safeUid(requestUid);
+    const filePath = path.join(pendingDir, `${safe}.json`);
+    fs.writeFileSync(filePath, JSON.stringify(payload, null, 2), "utf8");
+    res.status(202).json({ request_uid: requestUid });
+  } catch (err) {
+    console.error("[ai_working_help] enqueue write error", err);
+    res.status(500).json({ message: "Write failed" });
+  }
+});
+
+app.get("/v1/response/:request_uid", requireApiTokenAndResolveProject, (req, res) => {
+  const requestUid = req.params.request_uid;
+  const dir = projectDataDir(req.projectId);
+  if (!dir) {
+    return res.status(400).json({ message: "Invalid project" });
+  }
+  const respondedDir = path.join(dir, "responded");
+  const foundResponded = findFileByRequestUid(respondedDir, requestUid);
+  if (foundResponded && foundResponded.data.response) {
+    return res.status(200).json({
+      status: "responded",
+      response: foundResponded.data.response,
+    });
+  }
+  const pendingDir = path.join(dir, "pending");
+  const foundPending = findFileByRequestUid(pendingDir, requestUid);
+  if (foundPending) {
+    return res.status(200).json({ status: "pending" });
+  }
+  res.status(200).json({ status: "pending" });
+});
+
+app.listen(PORT, () => {
+  console.log(`[ai_working_help] listening on port ${PORT}`);
+});
diff --git a/deploy/_lib/colors.sh b/deploy/_lib/colors.sh
new file mode 100644
index 0000000..6770b80
--- /dev/null
+++ b/deploy/_lib/colors.sh
@@ -0,0 +1,17 @@
+#!/usr/bin/env bash
+
+set -euo pipefail
+
+RED='\033[0;31m'
+GREEN='\033[0;32m'
+YELLOW='\033[1;33m'
+BLUE='\033[0;34m'
+CYAN='\033[0;36m'
+NC='\033[0m'
+
+log_ts_utc() { date -u '+%Y-%m-%dT%H:%M:%SZ'; }
+
+success() { echo -e "[$(log_ts_utc)] ${GREEN}✔${NC} $1"; }
+error() { echo -e "[$(log_ts_utc)] ${RED}✗${NC} $1"; }
+warning() { echo -e "[$(log_ts_utc)] ${YELLOW}⚠${NC} $1"; }
+info() { echo -e "[$(log_ts_utc)] ${BLUE}ℹ${NC} $1"; }
diff --git a/deploy/_lib/env-map.sh b/deploy/_lib/env-map.sh
new file mode 100644
index 0000000..3b3e5b3
--- /dev/null
+++ b/deploy/_lib/env-map.sh
@@ -0,0 +1,66 @@
+#!/usr/bin/env bash
+
+set -euo pipefail
+
+#
+# Environment mapping for LeCoffre.io v2 deployments (proxy-based infra).
+# - Proxy (jump/orchestrator): 192.168.1.100 (4nk.myftp.biz)
+# - Targets: test=192.168.1.101, pprod=192.168.1.102, prod=192.168.1.103, services=192.168.1.104
+#
+
+get_env_target_ip() {
+	local env="$1"
+	case "$env" in
+		test) echo "192.168.1.101" ;;
+		pprod) echo "192.168.1.102" ;;
+		prod) echo "192.168.1.103" ;;
+		services) echo "192.168.1.104" ;;
+		*) return 1 ;;
+	esac
+}
+
+get_env_domain() {
+	local env="$1"
+	case "$env" in
+		test) echo "test.lecoffreio.4nkweb.com" ;;
+		pprod) echo "pprod.lecoffreio.4nkweb.com" ;;
+		prod) echo "prod.lecoffreio.4nkweb.com" ;;
+		*) return 1 ;;
+	esac
+}
+
+# Repository path on each target host (infra standard: /srv/4NK/<domain>/)
+get_env_remote_app_root() {
+	local env="$1"
+	local domain
+	domain="$(get_env_domain "$env")"
+	echo "/srv/4NK/${domain}"
+}
+
+# Public service port (proxied by nginx on proxy).
+# This port is reserved for LeCoffre.io in the infra ports map.
+get_env_service_port() {
+	local env="$1"
+	case "$env" in
+		test|pprod|prod) echo "3009" ;;
+		*) return 1 ;;
+	esac
+}
+
+# Internal frontend port (served by Next.js, proxied by local router).
+get_env_frontend_internal_port() {
+	local env="$1"
+	case "$env" in
+		test|pprod|prod) echo "3100" ;;
+		*) return 1 ;;
+	esac
+}
+
+# Internal backend port (served by Express, proxied by local router).
+get_env_backend_internal_port() {
+	local env="$1"
+	case "$env" in
+		test|pprod|prod) echo "3101" ;;
+		*) return 1 ;;
+	esac
+}
diff --git a/deploy/_lib/git-flow.sh b/deploy/_lib/git-flow.sh
new file mode 100644
index 0000000..436e810
--- /dev/null
+++ b/deploy/_lib/git-flow.sh
@@ -0,0 +1,293 @@
+#!/usr/bin/env bash
+# Git flow functions for automatic branch promotion and verification
+#
+# Prerequisites: This file must be sourced after env-map.sh and ssh.sh
+# Functions used: get_env_target_ip, get_env_service_port, get_env_backend_internal_port, ssh_run
+# Variables used: DEPLOY_SSH_KEY, DEPLOY_SSH_USER
+
+# Vérifie le succès d'un déploiement
+
+verify_deployment_success() {
+	local env="$1"
+	local domain="$2"
+	local ssh_key="${DEPLOY_SSH_KEY:-$HOME/.ssh/id_ed25519}"
+	local ssh_user="${DEPLOY_SSH_USER:-ncantu}"
+	local target_ip
+	local service_port
+	local backend_internal_port
+
+	# These functions should be available from env-map.sh (sourced before this file)
+	target_ip="$(get_env_target_ip "$env")"
+	service_port="$(get_env_service_port "$env")"
+	backend_internal_port="$(get_env_backend_internal_port "$env")"
+
+	# 1. Attendre quelques secondes pour que les services démarrent
+	info "[verify] Waiting for services to start (15 seconds)..."
+	sleep 15
+
+	# 2. Health check HTTP avec retries
+	info "[verify] Checking health endpoint via router (port ${service_port})..."
+	local health_status
+	local max_retries=3
+	local retry_count=0
+
+	# Vérifier via le router depuis le serveur distant (via SSH)
+	# Le router route /api/ vers le backend
+	while [[ $retry_count -lt $max_retries ]]; do
+		health_status=$(ssh_run "$ssh_key" "$ssh_user" "$target_ip" \
+			"curl -s -o /dev/null -w '%{http_code}' --max-time 10 --connect-timeout 5 'http://localhost:${service_port}/api/v1/public/health' 2>/dev/null || echo '000'")
+
+		if [[ "$health_status" == "200" ]]; then
+			info "[verify] Health check passed via router (HTTP $health_status)"
+			break
+		fi
+
+		retry_count=$((retry_count + 1))
+		if [[ $retry_count -lt $max_retries ]]; then
+			info "[verify] Health check attempt $retry_count failed (HTTP $health_status), retrying in 5 seconds..."
+			sleep 5
+		fi
+	done
+
+	if [[ "$health_status" != "200" ]]; then
+		# Essayer directement le backend en fallback
+		info "[verify] Router check failed (HTTP $health_status), trying backend directly (port ${backend_internal_port})..."
+		health_status=$(ssh_run "$ssh_key" "$ssh_user" "$target_ip" \
+			"curl -s -o /dev/null -w '%{http_code}' --max-time 10 --connect-timeout 5 'http://localhost:${backend_internal_port}/api/v1/public/health' 2>/dev/null || echo '000'")
+
+		# If 404, backend may mount API at root (API_ROOT_URL=/); try path without /api prefix
+		if [[ "$health_status" == "404" ]]; then
+			info "[verify] Backend returned 404 for /api/v1/public/health, trying /v1/public/health..."
+			health_status=$(ssh_run "$ssh_key" "$ssh_user" "$target_ip" \
+				"curl -s -o /dev/null -w '%{http_code}' --max-time 10 --connect-timeout 5 'http://localhost:${backend_internal_port}/v1/public/health' 2>/dev/null || echo '000'")
+		fi
+
+		if [[ "$health_status" != "200" ]]; then
+			error "[verify] Health check failed: HTTP $health_status"
+
+			# Afficher les logs du backend pour diagnostic
+			info "[verify] Backend logs (last 50 lines):"
+			ssh_run "$ssh_key" "$ssh_user" "$target_ip" \
+				"journalctl -u lecoffreio-backend@${domain}.service --no-pager -n 50 2>/dev/null || true" | sed 's/^/  /'
+
+			# Afficher l'état des services
+			info "[verify] Service status:"
+			ssh_run "$ssh_key" "$ssh_user" "$target_ip" \
+				"systemctl status lecoffreio-backend@${domain}.service lecoffreio-router@${domain}.service --no-pager -l 2>/dev/null || true" | sed 's/^/  /'
+
+			# Vérifier si le port est en écoute
+			info "[verify] Checking if backend port ${backend_internal_port} is listening:"
+			ssh_run "$ssh_key" "$ssh_user" "$target_ip" \
+				"ss -tlnp | grep ':${backend_internal_port}' || echo '  Port ${backend_internal_port} is not listening'" | sed 's/^/  /'
+
+			error "[verify] Backend may not be fully started yet. Check logs: journalctl -u lecoffreio-backend@${domain}.service -n 50"
+			error "[verify] Router status: systemctl status lecoffreio-router@${domain}.service"
+			return 1
+		fi
+		info "[verify] Health check passed via direct backend (HTTP $health_status)"
+	fi
+
+	# 3. Vérification des services systemd avec retries (frontend peut prendre plus de temps)
+	info "[verify] Checking systemd services..."
+	local services_status
+	local max_service_retries=10
+	local service_retry_count=0
+	local all_active=false
+
+	while [[ $service_retry_count -lt $max_service_retries && "$all_active" != "true" ]]; do
+		services_status=$(ssh_run "$ssh_key" "$ssh_user" "$target_ip" \
+			"systemctl is-active lecoffreio-backend@${domain}.service lecoffreio-frontend@${domain}.service lecoffreio-router@${domain}.service 2>/dev/null | grep -vE '^(active|activating)$' || true")
+
+		if [[ -z "$services_status" ]]; then
+			# Vérifier que tous les services sont vraiment "active" (pas "activating")
+			local all_status
+			all_status=$(ssh_run "$ssh_key" "$ssh_user" "$target_ip" \
+				"systemctl is-active lecoffreio-backend@${domain}.service lecoffreio-frontend@${domain}.service lecoffreio-router@${domain}.service 2>/dev/null")
+
+			# Vérifier s'il y a des erreurs dans les logs du frontend (si en "activating")
+			if echo "$all_status" | grep -q "activating"; then
+				# Vérifier les logs du frontend pour voir s'il y a une erreur
+				local frontend_errors
+				frontend_errors=$(ssh_run "$ssh_key" "$ssh_user" "$target_ip" \
+					"journalctl -u lecoffreio-frontend@${domain}.service --since '2 minutes ago' --no-pager 2>/dev/null | { grep -iE '(error|fatal|failed)' || true; } | tail -5")
+
+				if [[ -n "$frontend_errors" ]]; then
+					error "[verify] Frontend errors detected while activating:"
+					echo "$frontend_errors" | sed 's/^/  /'
+					error "[verify] Check frontend logs: journalctl -u lecoffreio-frontend@${domain}.service -n 50"
+					return 1
+				fi
+
+				service_retry_count=$((service_retry_count + 1))
+				if [[ $service_retry_count -lt $max_service_retries ]]; then
+					info "[verify] Some services still activating, waiting 10 seconds (attempt $service_retry_count/$max_service_retries)..."
+					sleep 10
+				fi
+			else
+				all_active=true
+			fi
+		else
+			service_retry_count=$((service_retry_count + 1))
+			if [[ $service_retry_count -lt $max_service_retries ]]; then
+				info "[verify] Some services not active, waiting 10 seconds (attempt $service_retry_count/$max_service_retries)..."
+				echo "$services_status" | sed 's/^/  /'
+				sleep 10
+			fi
+		fi
+	done
+
+	if [[ "$all_active" != "true" ]]; then
+		# Dernière vérification pour afficher l'état final et les logs
+		services_status=$(ssh_run "$ssh_key" "$ssh_user" "$target_ip" \
+			"systemctl is-active lecoffreio-backend@${domain}.service lecoffreio-frontend@${domain}.service lecoffreio-router@${domain}.service 2>/dev/null || echo 'unknown'")
+		error "[verify] Some services are not active after $max_service_retries attempts:"
+		echo "$services_status" | sed 's/^/  /'
+
+		# Afficher les logs du frontend si toujours en activating
+		if echo "$services_status" | grep -q "activating.*frontend"; then
+			info "[verify] Frontend logs (last 30 lines):"
+			ssh_run "$ssh_key" "$ssh_user" "$target_ip" \
+				"journalctl -u lecoffreio-frontend@${domain}.service --no-pager -n 30 2>/dev/null || true" | sed 's/^/  /'
+		fi
+
+		error "[verify] Check service status: systemctl status lecoffreio-backend@${domain}.service lecoffreio-frontend@${domain}.service lecoffreio-router@${domain}.service"
+		return 1
+	fi
+
+	info "[verify] All systemd services are active"
+
+	# 3. Vérification des logs (erreurs critiques récentes)
+	info "[verify] Checking for critical errors in logs..."
+	local critical_errors
+	critical_errors=$(ssh_run "$ssh_key" "$ssh_user" "$target_ip" \
+		"journalctl -u lecoffreio-backend@${domain}.service --since '5 minutes ago' --no-pager 2>/dev/null | { grep -iE '(error|fatal|critical)' || true; } | tail -10")
+
+	if [[ -n "$critical_errors" ]]; then
+		warning "[verify] Critical errors found in recent logs:"
+		echo "$critical_errors" | sed 's/^/  /'
+		# Ne pas bloquer pour les warnings, seulement les erreurs fatales
+		# On pourrait ajouter une logique plus fine ici
+	fi
+
+	info "[verify] Deployment verification passed"
+	return 0
+}
+
+# Détermine l'environnement suivant dans la chaîne
+get_next_env() {
+	local current_env="$1"
+	case "$current_env" in
+		dev) echo "test" ;;
+		test) echo "pprod" ;;
+		pprod) echo "prod" ;;
+		prod) echo "" ;;
+		*) echo "" ;;
+	esac
+}
+
+# Promotion automatique vers l'environnement suivant
+auto_promote_to_next_env() {
+	local current_env="$1"
+	local current_branch="$2"
+	local project_root="$3"
+	local deploy_git_remote="${4:-lecoffre_ng}"
+	local next_env
+	local next_branch
+
+	# Si on n'est pas sur dev, pas de promotion
+	if [[ "$current_branch" != "dev" ]]; then
+		return 0
+	fi
+
+	next_env=$(get_next_env "$current_env")
+	if [[ -z "$next_env" ]]; then
+		info "[promote] No next environment (already at prod)"
+		return 0
+	fi
+
+	# Déterminer la branche cible
+	case "$next_env" in
+		test) next_branch="test" ;;
+		pprod) next_branch="pprod" ;;
+		prod) next_branch="prod" ;;
+		*) return 0 ;;
+	esac
+
+	info "[promote] Auto-promoting dev → $next_branch for $next_env environment..."
+
+	# 1. Fetch la branche cible
+	git -C "$project_root" fetch "$deploy_git_remote" "$next_branch" || true
+
+	# 2. Checkout la branche cible
+	git -C "$project_root" checkout "$next_branch" || {
+		# Branch doesn't exist locally, create it from remote
+		git -C "$project_root" checkout -b "$next_branch" "${deploy_git_remote}/${next_branch}" 2>/dev/null || {
+			# Remote branch doesn't exist, create new branch
+			git -C "$project_root" checkout -b "$next_branch"
+		}
+	}
+
+	# 3. Merge dev into target branch
+	if ! git -C "$project_root" merge dev --allow-unrelated-histories --no-edit; then
+		error "[promote] Merge dev → $next_branch failed. Resolve conflicts manually."
+		git -C "$project_root" checkout dev
+		return 1
+	fi
+
+	# 4. Push
+	info "[promote] Pushing $next_branch..."
+	git -C "$project_root" push "$deploy_git_remote" "$next_branch"
+
+	# 5. Retourner sur dev
+	info "[promote] Returning to dev branch..."
+	git -C "$project_root" checkout dev
+
+	success "[promote] Successfully promoted dev → $next_branch"
+	info "[promote] Next step: deploy to $next_env with: ./deploy/scripts_v2/deploy.sh $next_env"
+
+	return 0
+}
+
+# Stage all changes, commit with message, and push current branch
+# Usage: git_add_commit_push <project_root> <commit_message> [remote]
+# Example: git_add_commit_push /path/to/repo "fix: something"
+git_add_commit_push() {
+	local project_root="${1:-.}"
+	local commit_message="$2"
+	local deploy_git_remote="${3:-lecoffre_ng}"
+	local current_branch
+
+	if [[ -z "$commit_message" ]]; then
+		error "[git] Commit message required"
+		return 1
+	fi
+
+	# Lint --fix on all projects before staging (resources, backend, frontend). Non-blocking.
+	info "[lint] Running lint --fix on lecoffre-ressources-dev, lecoffre-back-main, lecoffre-front-main..."
+	(cd "${project_root}/lecoffre-ressources-dev" && npm run lint:fix) || warning "[lint] lecoffre-ressources-dev lint:fix failed (non-blocking)"
+	(cd "${project_root}/lecoffre-back-main" && npm run lint:fix) || warning "[lint] lecoffre-back-main lint:fix failed (non-blocking)"
+	(cd "${project_root}/lecoffre-front-main" && npm run lint:fix) || warning "[lint] lecoffre-front-main lint:fix failed (non-blocking)"
+	info "[lint] Lint:fix step done"
+
+	info "[git] Staging all changes (add -A)..."
+	git -C "$project_root" add -A || {
+		error "[git] git add -A failed"
+		return 1
+	}
+
+	info "[git] Committing..."
+	git -C "$project_root" commit -m "$commit_message" || {
+		error "[git] commit failed"
+		return 1
+	}
+
+	current_branch=$(git -C "$project_root" branch --show-current)
+	info "[git] Pushing to $deploy_git_remote $current_branch..."
+	git -C "$project_root" push "$deploy_git_remote" "$current_branch" || {
+		error "[git] push failed"
+		return 1
+	}
+
+	success "[git] add -A, commit, push done"
+	return 0
+}
diff --git a/deploy/_lib/ssh.sh b/deploy/_lib/ssh.sh
new file mode 100644
index 0000000..a20522f
--- /dev/null
+++ b/deploy/_lib/ssh.sh
@@ -0,0 +1,95 @@
+#!/usr/bin/env bash
+
+set -euo pipefail
+
+require_ssh_key() {
+	local key_path="$1"
+	if [[ -z "$key_path" ]]; then
+		echo "SSH key path is required" >&2
+		return 1
+	fi
+	if [[ ! -f "$key_path" ]]; then
+		echo "SSH key not found: $key_path" >&2
+		return 1
+	fi
+}
+
+ssh_common_opts() {
+	local ssh_user="$1"
+	local ssh_host="$2"
+
+	# Keepalive to reduce flakiness through ProxyJump
+	# (observed: "Connection reset by peer" during scp/ssh).
+	#
+	# Notes:
+	# - Avoid SSH multiplexing here: ControlPath/ControlMaster can be flaky on Windows OpenSSH + MSYS paths.
+	# - Increased timeouts and keepalive settings to handle network instability
+	# - Compression disabled to reduce overhead and potential connection issues
+	echo \
+		-o BatchMode=yes \
+		-o StrictHostKeyChecking=accept-new \
+		-o ConnectTimeout=30 \
+		-o ServerAliveInterval=10 \
+		-o ServerAliveCountMax=6 \
+		-o TCPKeepAlive=yes \
+		-o Compression=no
+}
+
+ssh_run() {
+	local ssh_key="$1"
+	local ssh_user="$2"
+	local ssh_host="$3"
+	shift 3
+
+	require_ssh_key "$ssh_key"
+
+	local proxy_host="${DEPLOY_SSH_PROXY_HOST:-}"
+	local proxy_user="${DEPLOY_SSH_PROXY_USER:-$ssh_user}"
+
+	local proxy_args=()
+	if [[ -n "$proxy_host" ]]; then
+		proxy_args=(-J "$proxy_user@$proxy_host")
+	fi
+
+	# shellcheck disable=SC2207
+	local common_opts=($(ssh_common_opts "$ssh_user" "$ssh_host"))
+
+	ssh -i "$ssh_key" \
+		"${common_opts[@]}" \
+		"${proxy_args[@]}" \
+		"$ssh_user@$ssh_host" "$@"
+}
+
+scp_copy() {
+	local ssh_key="$1"
+	local src="$2"
+	local ssh_user="$3"
+	local ssh_host="$4"
+	local dst="$5"
+	local recursive="${6:-false}"
+
+	require_ssh_key "$ssh_key"
+
+	local proxy_host="${DEPLOY_SSH_PROXY_HOST:-}"
+	local proxy_user="${DEPLOY_SSH_PROXY_USER:-$ssh_user}"
+
+	local proxy_args=()
+	if [[ -n "$proxy_host" ]]; then
+		proxy_args=(-o "ProxyJump=$proxy_user@$proxy_host")
+	fi
+
+	# shellcheck disable=SC2207
+	local common_opts=($(ssh_common_opts "$ssh_user" "$ssh_host"))
+
+	local scp_opts=()
+	# Add -r for recursive copy if requested or if source is a directory
+	if [[ "$recursive" == "true" ]] || [[ -d "$src" ]]; then
+		scp_opts=(-r)
+	fi
+
+	scp -i "$ssh_key" \
+		"${scp_opts[@]}" \
+		"${common_opts[@]}" \
+		"${proxy_args[@]}" \
+		"$src" "$ssh_user@$ssh_host:$dst"
+}
diff --git a/deploy/branch-align.sh b/deploy/branch-align.sh
new file mode 100755
index 0000000..431d297
--- /dev/null
+++ b/deploy/branch-align.sh
@@ -0,0 +1,108 @@
+#!/usr/bin/env bash
+# Aligns only origin/test, origin/pprod, origin/prod to current branch SHA. main is not aligned.
+set -euo pipefail
+
+if ! git rev-parse --is-inside-work-tree >/dev/null 2>&1; then
+	echo "[branch-align][ERROR] Not in a git repository" >&2
+	exit 1
+fi
+
+PROJECT_ROOT="$(git rev-parse --show-toplevel)"
+SCRIPT_REAL="$(readlink -f "${BASH_SOURCE[0]:-$0}" 2>/dev/null || realpath "${BASH_SOURCE[0]:-$0}" 2>/dev/null || echo "${BASH_SOURCE[0]:-$0}")"
+DEPLOY_DIR="$(cd "$(dirname "$SCRIPT_REAL")" && pwd)"
+if [[ "$(pwd)" != "$PROJECT_ROOT" ]]; then
+	cd "$PROJECT_ROOT" && exec "${DEPLOY_DIR}/$(basename "${BASH_SOURCE[0]:-$0}")" "$@"
+fi
+
+env_branch="${1:-}"
+if [[ -z "$env_branch" ]]; then
+	echo "[branch-align][ERROR] Missing <env> argument (expected: main|test|pprod|prod)" >&2
+	echo "Usage: ./deploy/branch-align.sh <env>" >&2
+	exit 1
+fi
+if [[ ! "$env_branch" =~ ^(main|test|pprod|prod)$ ]]; then
+	echo "[branch-align][ERROR] Invalid <env>: must be main, test, pprod or prod (got: '${env_branch}')" >&2
+	echo "Usage: ./deploy/branch-align.sh <env>" >&2
+	exit 1
+fi
+
+current_branch="$(git rev-parse --abbrev-ref HEAD)"
+if [[ "$current_branch" != "$env_branch" ]]; then
+	echo "[branch-align][ERROR] Must be on branch '${env_branch}' (current: '${current_branch}')" >&2
+	exit 1
+fi
+
+# Fetch latest refs
+
+git fetch origin
+
+target_sha="$(git rev-parse "$env_branch")"
+origin_env_sha="$(git rev-parse "origin/${env_branch}")"
+
+if [[ "$target_sha" != "$origin_env_sha" ]]; then
+	echo "[branch-align] origin/${env_branch} differs from local ${env_branch}. Updating remote to local (env priority)."
+	git push --force-with-lease origin "${target_sha}:${env_branch}"
+	git fetch origin
+fi
+
+# Align all three branches to env SHA
+for br in test pprod prod; do
+	if [[ "$br" == "$env_branch" ]]; then
+		# Ensure tracking exists
+		git branch --set-upstream-to="origin/${br}" "$br" >/dev/null 2>&1 || true
+		continue
+	fi
+
+	git branch -f "$br" "$target_sha"	
+	git push --force-with-lease origin "${target_sha}:${br}"	
+	git branch --set-upstream-to="origin/${br}" "$br" >/dev/null 2>&1 || true
+
+done
+
+# Also ensure env branch tracks its remote
+
+git branch --set-upstream-to="origin/${env_branch}" "$env_branch" >/dev/null 2>&1 || true
+
+# Verify last 30 commits are identical
+
+tmp1="$(mktemp -t branch-align-test.XXXXXX)"
+tmp2="$(mktemp -t branch-align-pprod.XXXXXX)"
+tmp3="$(mktemp -t branch-align-prod.XXXXXX)"
+cleanup() {
+	rm -f "$tmp1" "$tmp2" "$tmp3"
+}
+trap cleanup EXIT
+
+git log -30 --format=%H origin/test > "$tmp1"
+git log -30 --format=%H origin/pprod > "$tmp2"
+git log -30 --format=%H origin/prod > "$tmp3"
+
+if ! diff -u "$tmp1" "$tmp2" >/dev/null; then
+	echo "[branch-align][ERROR] Last 30 commits differ: origin/test vs origin/pprod" >&2
+	exit 1
+fi
+if ! diff -u "$tmp1" "$tmp3" >/dev/null; then
+	echo "[branch-align][ERROR] Last 30 commits differ: origin/test vs origin/prod" >&2
+	exit 1
+fi
+
+# Final assertions
+
+if [[ "$(git rev-parse --abbrev-ref HEAD)" != "$env_branch" ]]; then
+	echo "[branch-align][ERROR] Branch changed unexpectedly" >&2
+	exit 1
+fi
+
+sha_test="$(git rev-parse origin/test)"
+sha_pprod="$(git rev-parse origin/pprod)"
+sha_prod="$(git rev-parse origin/prod)"
+
+if [[ "$sha_test" != "$sha_pprod" ]] || [[ "$sha_test" != "$sha_prod" ]]; then
+	echo "[branch-align][ERROR] Remote branches are not aligned" >&2
+	echo "origin/test=$sha_test" >&2
+	echo "origin/pprod=$sha_pprod" >&2
+	echo "origin/prod=$sha_prod" >&2
+	exit 1
+fi
+
+echo "[branch-align] OK: origin/test, origin/pprod, origin/prod aligned to ${sha_test}"
diff --git a/deploy/bump-version.sh b/deploy/bump-version.sh
new file mode 100644
index 0000000..7b86570
--- /dev/null
+++ b/deploy/bump-version.sh
@@ -0,0 +1,91 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+# Bump version and optional package.json files from project config (projects/<id>/conf.json).
+# Usage: ./bump-version.sh <version> [message_court]
+# Requires: run from repo root; project id from IA_PROJECT, .ia_project, or ai_project_id; jq if using version.package_json_paths.
+
+VERSION="${1:-}"
+SHORT_MSG="${2:-Nouvelles fonctionnalités et améliorations}"
+
+if [[ -z "$VERSION" ]]; then
+  echo "❌ Usage: ./bump-version.sh <version> [message_court]"
+  echo "   Exemple: ./bump-version.sh 2.1.0 'Nouveaux filtres'"
+  exit 1
+fi
+
+if ! [[ "$VERSION" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
+  echo "❌ Version invalide. Format attendu: X.Y.Z (ex: 2.1.0)"
+  exit 1
+fi
+
+if ! git rev-parse --is-inside-work-tree >/dev/null 2>&1; then
+  echo "❌ Not in a git repository" >&2
+  exit 1
+fi
+
+PROJECT_ROOT="$(git rev-parse --show-toplevel)"
+SCRIPT_REAL="$(readlink -f "${BASH_SOURCE[0]:-$0}" 2>/dev/null || realpath "${BASH_SOURCE[0]:-$0}" 2>/dev/null || echo "${BASH_SOURCE[0]:-$0}")"
+DEPLOY_DIR="$(cd "$(dirname "$SCRIPT_REAL")" && pwd)"
+IA_DEV_ROOT="$(cd "$DEPLOY_DIR/.." && pwd)"
+if [[ "$(pwd)" != "$PROJECT_ROOT" ]]; then
+  SCRIPT_ABS="${DEPLOY_DIR}/$(basename "${BASH_SOURCE[0]:-$0}")"
+  cd "$PROJECT_ROOT" && exec "$SCRIPT_ABS" "$@"
+fi
+
+# shellcheck source=../lib/project_config.sh
+source "${IA_DEV_ROOT}/lib/project_config.sh"
+
+echo "🔄 Mise à jour vers v${VERSION}..."
+
+echo "$VERSION" > "$PROJECT_ROOT/VERSION"
+echo "✅ VERSION → ${VERSION}"
+
+package_paths=()
+splash_name="Application"
+if [[ -n "${PROJECT_CONFIG_PATH:-}" && -f "$PROJECT_CONFIG_PATH" ]] && command -v jq >/dev/null 2>&1; then
+  while IFS= read -r p; do
+    [[ -n "$p" ]] && package_paths+=( "$p" )
+  done < <(jq -r '.version.package_json_paths[]? // empty' "$PROJECT_CONFIG_PATH" 2>/dev/null)
+  splash_name="$(jq -r '.version.splash_app_name // "Application"' "$PROJECT_CONFIG_PATH" 2>/dev/null)"
+fi
+
+for p in "${package_paths[@]}"; do
+  if [[ -f "$PROJECT_ROOT/$p" ]]; then
+    sed -i "s/\"version\": \".*\"/\"version\": \"${VERSION}\"/" "$PROJECT_ROOT/$p"
+    echo "✅ $p → ${VERSION}"
+  else
+    echo "⚠️  $p not found, skipped"
+  fi
+done
+
+if [[ ! -f "$PROJECT_ROOT/CHANGELOG.md" ]]; then
+  echo "⚠️  CHANGELOG.md non trouvé. Créez-le manuellement avec les détails de cette version."
+fi
+
+echo ""
+echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
+echo "📋 PROCHAINES ÉTAPES"
+echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
+echo ""
+echo "1. Éditer CHANGELOG.md pour documenter les changements de v${VERSION}"
+echo ""
+echo "2. Mettre à jour le .env distant avec le message splash (si applicable) :"
+echo ""
+cat << EOF
+NEXT_PUBLIC_SPLASH_MESSAGE="🎉 ${splash_name} v${VERSION} est disponible !
+
+✨ ${SHORT_MSG}
+
+📖 Consultez CHANGELOG.md pour tous les détails"
+
+NEXT_PUBLIC_SPLASH_MAX_DISPLAYS=10
+NEXT_PUBLIC_SPLASH_ID="splash_v${VERSION}"
+EOF
+echo ""
+echo "3. Rebuild, redémarrer et déployer selon le workflow du projet."
+echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
+echo ""
+echo "✅ Bump terminé. Éditer CHANGELOG.md puis lancer le déploiement selon le projet."
+
+exit 0
diff --git a/deploy/change-to-all-branches.sh b/deploy/change-to-all-branches.sh
new file mode 100755
index 0000000..7a30db6
--- /dev/null
+++ b/deploy/change-to-all-branches.sh
@@ -0,0 +1,32 @@
+#!/usr/bin/env bash
+# From branch test only: align origin/test, origin/pprod, origin/prod then deploy to test (import-v1, skipSetupHost).
+# Use when you have already pushed to test and want to sync other branches and deploy test in one go.
+set -euo pipefail
+
+if ! git rev-parse --is-inside-work-tree >/dev/null 2>&1; then
+	echo "[change-to-all-branches][ERROR] Not in a git repository" >&2
+	exit 1
+fi
+
+PROJECT_ROOT="$(git rev-parse --show-toplevel)"
+SCRIPT_REAL="$(readlink -f "${BASH_SOURCE[0]:-$0}" 2>/dev/null || realpath "${BASH_SOURCE[0]:-$0}" 2>/dev/null || echo "${BASH_SOURCE[0]:-$0}")"
+DEPLOY_DIR="$(cd "$(dirname "$SCRIPT_REAL")" && pwd)"
+if [[ "$(pwd)" != "$PROJECT_ROOT" ]]; then
+	cd "$PROJECT_ROOT" && exec "${DEPLOY_DIR}/$(basename "${BASH_SOURCE[0]:-$0}")" "$@"
+fi
+
+current="$(git rev-parse --abbrev-ref HEAD)"
+if [[ "$current" != "test" ]]; then
+	echo "[change-to-all-branches][ERROR] Must be on branch 'test' (current: '${current}')" >&2
+	exit 1
+fi
+
+echo "[change-to-all-branches] Aligning branches..."
+"$DEPLOY_DIR/branch-align.sh" test
+
+# scripts_v2 lives in the host project's deploy/ (not necessarily under ia_dev)
+DEPLOY_SCRIPTS_V2="${PROJECT_ROOT}/deploy/scripts_v2"
+echo "[change-to-all-branches] Deploying test (--import-v1 --skipSetupHost, --no-sync-origin because we just pushed)..."
+"${DEPLOY_SCRIPTS_V2}/deploy.sh" test --import-v1 --skipSetupHost --no-sync-origin
+
+echo "[change-to-all-branches] OK"
diff --git a/deploy/deploy-by-script-to.sh b/deploy/deploy-by-script-to.sh
new file mode 100755
index 0000000..816aeb2
--- /dev/null
+++ b/deploy/deploy-by-script-to.sh
@@ -0,0 +1,58 @@
+#!/usr/bin/env bash
+# deploy-by-script-to <target_branch>: checkout target, verify .secrets/<env>, force sync with origin, deploy target, checkout test.
+# Launched from ia_dev (like other deploy scripts); applies to parent repo (../). Call after /change-to-all-branches (agent). Target: pprod | prod only.
+set -euo pipefail
+
+SCRIPT_REAL="$(readlink -f "${BASH_SOURCE[0]:-$0}" 2>/dev/null || realpath "${BASH_SOURCE[0]:-$0}" 2>/dev/null || echo "${BASH_SOURCE[0]:-$0}")"
+DEPLOY_IA="$(cd "$(dirname "$SCRIPT_REAL")" && pwd)"
+# Parent of ia_dev = project root (deploy applies to ../)
+PROJECT_ROOT="$(cd "$DEPLOY_IA/../.." && pwd)"
+if [[ "$(pwd)" != "$PROJECT_ROOT" ]]; then
+	cd "$PROJECT_ROOT" && exec "$SCRIPT_REAL" "$@"
+fi
+if ! git rev-parse --is-inside-work-tree >/dev/null 2>&1; then
+	echo "[deploy-by-script-to][ERROR] Not in a git repository (PROJECT_ROOT=${PROJECT_ROOT})" >&2
+	exit 1
+fi
+
+TARGET_BRANCH="${1:-}"
+if [[ -z "$TARGET_BRANCH" ]]; then
+	echo "[deploy-by-script-to][ERROR] Missing <target_branch> argument (expected: pprod | prod)" >&2
+	echo "Usage: ./deploy/deploy-by-script-to.sh <target_branch>  (from ia_dev; pprod or prod only)" >&2
+	exit 1
+fi
+if [[ ! "$TARGET_BRANCH" =~ ^(pprod|prod)$ ]]; then
+	echo "[deploy-by-script-to][ERROR] Invalid target branch: must be pprod or prod (got: '${TARGET_BRANCH}')" >&2
+	echo "Usage: ./deploy/deploy-by-script-to.sh <pprod|prod>" >&2
+	exit 1
+fi
+
+current="$(git rev-parse --abbrev-ref HEAD)"
+if [[ "$current" != "test" ]]; then
+	echo "[deploy-by-script-to][ERROR] Must be on branch 'test' (current: '${current}'). Run /change-to-all-branches first." >&2
+	exit 1
+fi
+
+echo "[deploy-by-script-to] Step 1/5: checkout ${TARGET_BRANCH}..."
+if [[ "$(git rev-parse --abbrev-ref HEAD)" != "$TARGET_BRANCH" ]]; then
+	git checkout "$TARGET_BRANCH"
+fi
+
+SECRETS_DIR="${PROJECT_ROOT}/.secrets/${TARGET_BRANCH}"
+if [[ ! -d "$SECRETS_DIR" ]]; then
+	echo "[deploy-by-script-to][ERROR] .secrets/${TARGET_BRANCH} does not exist at ${SECRETS_DIR}" >&2
+	exit 1
+fi
+echo "[deploy-by-script-to] Step 2/5: .secrets/${TARGET_BRANCH} OK"
+
+echo "[deploy-by-script-to] Step 3/5: force sync local branch with origin/${TARGET_BRANCH}..."
+git fetch origin
+git reset --hard "origin/${TARGET_BRANCH}"
+
+echo "[deploy-by-script-to] Step 4/5: deploy ${TARGET_BRANCH} (--import-v1 --skipSetupHost)..."
+"$PROJECT_ROOT/deploy/scripts_v2/deploy.sh" "$TARGET_BRANCH" --import-v1 --skipSetupHost
+
+echo "[deploy-by-script-to] Step 5/5: checkout test..."
+git checkout test
+
+echo "[deploy-by-script-to] OK: aligned, synced, deployed to ${TARGET_BRANCH}, back on test"
diff --git a/deploy/pousse.sh b/deploy/pousse.sh
new file mode 100755
index 0000000..5c811b7
--- /dev/null
+++ b/deploy/pousse.sh
@@ -0,0 +1,186 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+if ! git rev-parse --is-inside-work-tree >/dev/null 2>&1; then
+	echo "[pousse][ERROR] Not in a git repository" >&2
+	exit 1
+fi
+
+PROJECT_ROOT="$(git rev-parse --show-toplevel)"
+SCRIPT_REAL="$(readlink -f "${BASH_SOURCE[0]:-$0}" 2>/dev/null || realpath "${BASH_SOURCE[0]:-$0}" 2>/dev/null || echo "${BASH_SOURCE[0]:-$0}")"
+DEPLOY_DIR="$(cd "$(dirname "$SCRIPT_REAL")" && pwd)"
+IA_DEV_ROOT="$(cd "$DEPLOY_DIR/.." && pwd)"
+if [[ "$(pwd)" != "$PROJECT_ROOT" ]]; then
+	SCRIPT_ABS="${DEPLOY_DIR}/$(basename "${BASH_SOURCE[0]:-$0}")"
+	cd "$PROJECT_ROOT" && exec "$SCRIPT_ABS" "$@"
+fi
+
+# Resolve project id and config path: IA_PROJECT, .ia_project, or ai_project_id → projects/<id>/conf.json
+# shellcheck source=../lib/project_config.sh
+source "${IA_DEV_ROOT}/lib/project_config.sh"
+
+remote="origin"
+bump_version=false
+
+usage() {
+	cat <<'EOF'
+Usage:
+  ./deploy/pousse.sh [--remote <remote>] [--bump-version]
+
+  --bump-version  Increment patch (third component) in VERSION before staging.
+
+Reads a full multi-line commit message from STDIN, then:
+- if not in repo root: re-exec from repo root (standardized execution)
+- build check (npm run build in each directory listed in projects/<id>/conf.json build_dirs, if any; exit on failure)
+- git add -A
+- git commit -F <message>
+- git push -u <remote> HEAD
+
+The current branch must already exist on the remote (e.g. origin/<branch>); otherwise the script refuses to push.
+
+Example:
+  ./deploy/pousse.sh <<'MSG'
+  Title
+
+  **Motivations:**
+  - ...
+
+  **Root causes:**
+  - ...
+
+  **Correctifs:**
+  - ...
+
+  **Evolutions:**
+  - ...
+
+  **Pages affectées:**
+  - ...
+  MSG
+EOF
+}
+
+while [[ $# -gt 0 ]]; do
+	case "$1" in
+		--remote)
+			remote="$2"
+			shift 2
+			;;
+		--bump-version)
+			bump_version=true
+			shift
+			;;
+		-h|--help)
+			usage
+			exit 0
+			;;
+		*)
+			echo "[pousse][ERROR] Unknown arg: $1" >&2
+			usage >&2
+			exit 1
+			;;
+	esac
+done
+
+branch="$(git rev-parse --abbrev-ref HEAD)"
+if [[ -z "$branch" || "$branch" == "HEAD" ]]; then
+	echo "[pousse][ERROR] Detached HEAD is not supported" >&2
+	exit 1
+fi
+
+author_name="$(git config user.name || true)"
+if [[ "$author_name" != "4NK" && "$author_name" != "Nicolas Cantu" ]]; then
+	echo "[pousse][ERROR] Refusing to commit: git user.name must be '4NK' or 'Nicolas Cantu' (got: '${author_name}')" >&2
+	exit 1
+fi
+
+repo_root="$(git rev-parse --show-toplevel)"
+# Build dirs from project config (projects/<id>/conf.json); skip if no config or no build_dirs
+build_dirs=()
+if [[ -n "${PROJECT_CONFIG_PATH:-}" && -f "$PROJECT_CONFIG_PATH" ]] && command -v jq >/dev/null 2>&1; then
+	while IFS= read -r d; do
+		[[ -n "$d" ]] && build_dirs+=( "$d" )
+	done < <(jq -r '.build_dirs[]? // empty' "$PROJECT_CONFIG_PATH" 2>/dev/null)
+fi
+if [[ ${#build_dirs[@]} -gt 0 ]]; then
+	echo "[pousse] Build check (${#build_dirs[@]} dirs from project config)..."
+	for dir in "${build_dirs[@]}"; do
+		if [[ ! -d "${repo_root}/${dir}" ]]; then
+			echo "[pousse][WARN] Skipping build ${dir} (directory not found)" >&2
+			continue
+		fi
+		echo "[pousse] Building ${dir}..."
+		(cd "${repo_root}/${dir}" && npm run build) || {
+			echo "[pousse][ERROR] Build failed in ${dir}" >&2
+			exit 1
+		}
+	done
+	echo "[pousse] Build check OK"
+else
+	echo "[pousse] No build_dirs in project config (or no projects/<id>/conf.json / jq); skipping build check"
+fi
+
+msg_file="$(mktemp -t pousse-commit-msg.XXXXXX)"
+cleanup() {
+	rm -f "$msg_file"
+}
+trap cleanup EXIT
+
+cat >"$msg_file" || true
+if [[ ! -s "$msg_file" ]]; then
+	echo "[pousse][ERROR] Empty commit message on STDIN" >&2
+	exit 1
+fi
+
+if [[ "$bump_version" == "true" ]]; then
+	version_file="${repo_root}/VERSION"
+	if [[ ! -f "$version_file" ]]; then
+		echo "[pousse][ERROR] VERSION not found at ${version_file}" >&2
+		exit 1
+	fi
+	current="$(cat "$version_file" | sed 's/[[:space:]]//g')"
+	if ! [[ "$current" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
+		echo "[pousse][ERROR] VERSION format must be X.Y.Z (got: '${current}')" >&2
+		exit 1
+	fi
+	maj="${current%%.*}"
+	min="${current#*.}"
+	min="${min%%.*}"
+	patch="${current##*.}"
+	patch=$((patch + 1))
+	new_version="${maj}.${min}.${patch}"
+	echo "$new_version" > "$version_file"
+	echo "[pousse] Bumped VERSION: ${current} -> ${new_version}"
+fi
+
+# Stage all changes
+
+git add -A
+
+git_status_short="$(git status -sb)"
+echo "$git_status_short"
+
+# Prevent committing potentially sensitive files
+staged_files="$(git diff --cached --name-only || true)"
+if [[ -n "$staged_files" ]]; then
+	if echo "$staged_files" | grep -Eiq '^(\.secrets/|\.env($|\.)|\.env\.|.*\.(key|pem|p12)$|.*credentials.*)'; then
+		echo "[pousse][ERROR] Refusing to commit: staged files look sensitive:" >&2
+		echo "$staged_files" | grep -Ei '^(\.secrets/|\.env($|\.)|\.env\.|.*\.(key|pem|p12)$|.*credentials.*)' >&2
+		exit 1
+	fi
+fi
+
+if git diff --cached --quiet; then
+	echo "[pousse] No staged changes to commit" >&2
+	exit 0
+fi
+
+echo "[pousse] Staged changes:"
+git diff --cached --stat
+
+git commit -F "$msg_file"
+if ! git rev-parse "${remote}/${branch}" >/dev/null 2>&1; then
+	echo "[pousse][ERROR] Branch '${branch}' does not exist on remote '${remote}'. Refusing to push (would create a new remote branch). Create the branch on the remote first or push manually." >&2
+	exit 1
+fi
+git push -u "$remote" HEAD
diff --git a/gitea-issues/agent-loop-chat-iterations.sh b/gitea-issues/agent-loop-chat-iterations.sh
new file mode 100755
index 0000000..6e0b0ff
--- /dev/null
+++ b/gitea-issues/agent-loop-chat-iterations.sh
@@ -0,0 +1,82 @@
+#!/usr/bin/env bash
+# Bounded loop for chat: run mail retrieval N times, 1 minute between each.
+# Use from Cursor chat when asked to "lance la boucle récupération emails puis attend 1 min et relance".
+# Runs in foreground (no background); chat can run it for a few iterations to avoid timeout.
+#
+# Usage:
+#   ./gitea-issues/agent-loop-chat-iterations.sh [N] [--repeat]
+#   N = number of iterations (default 3). Each iteration: mail-list-unread.sh then sleep 60.
+#   --repeat = after N iterations, relaunch (infinite loop of N-by-N runs).
+# Output and mail list (expéditeur, sujet) are appended to projects/<id>/logs/gitea-issues/agent-loop-chat-iterations.log.
+#
+set -euo pipefail
+if [ -n "${HOME:-}" ] && [ -r "$HOME/.bashrc" ]; then
+  set +u
+  # shellcheck source=/dev/null
+  source "$HOME/.bashrc" 2>/dev/null || true
+  set -u
+fi
+[ -n "${HOME:-}" ] && [ -d "$HOME/.local/bin" ] && export PATH="$HOME/.local/bin:$PATH"
+
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+ROOT="$(cd "${GITEA_ISSUES_DIR}/../.." && pwd)"
+export GITEA_ISSUES_DIR
+export REPO_ROOT="${ROOT}"
+cd "$ROOT"
+# shellcheck source=lib.sh
+source "${GITEA_ISSUES_DIR}/lib.sh" 2>/dev/null || true
+LOGS_GITEA="${PROJECT_LOGS_DIR:-$ROOT/logs}/gitea-issues"
+
+REPEAT=""
+if [ "${1:-}" = "--repeat" ]; then
+  REPEAT=1
+  N="${2:-3}"
+else
+  N="${1:-3}"
+fi
+if ! [[ "$N" =~ ^[0-9]+$ ]] || [ "$N" -lt 1 ]; then
+  echo "Usage: $0 [N] [--repeat] — N positive integer (default 3). --repeat = relancer à la fin." >&2
+  exit 1
+fi
+
+LOG_DIR="${LOGS_GITEA}"
+LOG_FILE="${LOG_DIR}/agent-loop-chat-iterations.log"
+mkdir -p "$LOG_DIR"
+# Ensure absolute path so logs are always in the same place
+[[ "$LOG_FILE" != /* ]] && LOG_FILE="$(cd "$LOG_DIR" && pwd)/agent-loop-chat-iterations.log"
+
+log_and_echo() {
+  echo "$1" | tee -a "$LOG_FILE"
+}
+
+# Log path and start so logs are never "empty" from path confusion
+log_and_echo "[agent-loop-chat] $(date -Iseconds) — log file: $LOG_FILE"
+# Test send at launch: one test email to nicolas.cantu@pm.me
+log_and_echo "[agent-loop-chat] $(date -Iseconds) — test d'envoi vers nicolas.cantu@pm.me"
+"${GITEA_ISSUES_DIR}/mail-send-reply.sh" --to "nicolas.cantu@pm.me" --subject "Test envoi - agent-loop-chat $(date +%Y-%m-%dT%H:%M:%S)" --body "Mail de test envoyé au lancement de agent-loop-chat-iterations.sh." 2>&1 | tee -a "$LOG_FILE"
+if [ "${PIPESTATUS[0]:-0}" -eq 0 ]; then
+  log_and_echo "[agent-loop-chat] $(date -Iseconds) — test d'envoi OK"
+else
+  log_and_echo "[agent-loop-chat] $(date -Iseconds) — test d'envoi échoué"
+  exit 1
+fi
+
+run_iterations() {
+  for i in $(seq 1 "$N"); do
+    log_and_echo "[agent-loop-chat] $(date -Iseconds) — iteration $i/$N"
+    "${GITEA_ISSUES_DIR}/mail-list-unread.sh" 2>&1 | tee -a "$LOG_FILE" || true
+    if [ "$i" -lt "$N" ]; then
+      log_and_echo "[agent-loop-chat] $(date -Iseconds) — attente 60 s avant prochaine itération"
+      sleep 60
+    fi
+  done
+  log_and_echo "[agent-loop-chat] $(date -Iseconds) — $N itérations terminées"
+}
+
+while true; do
+  run_iterations
+  if [ -z "${REPEAT:-}" ]; then
+    break
+  fi
+  log_and_echo "[agent-loop-chat] $(date -Iseconds) — relance"
+done
diff --git a/gitea-issues/agent-loop-lock-acquire.sh b/gitea-issues/agent-loop-lock-acquire.sh
new file mode 100755
index 0000000..a026501
--- /dev/null
+++ b/gitea-issues/agent-loop-lock-acquire.sh
@@ -0,0 +1,39 @@
+#!/usr/bin/env bash
+# Try to acquire agent-loop.lock. Exit 0 and create lock if none or stale (>24h). Exit 1 if lock is recent.
+# Run from repo root. Used by agent-loop agent before starting x cycles (section 2).
+#
+# Usage:
+#   cd <racine_projet> && ./ia_dev/gitea-issues/agent-loop-lock-acquire.sh
+#
+set -euo pipefail
+if [ -n "${HOME:-}" ] && [ -r "$HOME/.bashrc" ]; then
+  set +u
+  # shellcheck source=/dev/null
+  source "$HOME/.bashrc" 2>/dev/null || true
+  set -u
+fi
+
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+ROOT="$(cd "${GITEA_ISSUES_DIR}/../.." && pwd)"
+export GITEA_ISSUES_DIR
+export REPO_ROOT="${ROOT}"
+cd "$ROOT"
+# shellcheck source=lib.sh
+source "${GITEA_ISSUES_DIR}/lib.sh" 2>/dev/null || true
+LOGS_GITEA="${PROJECT_LOGS_DIR:-$ROOT/logs}/gitea-issues"
+
+LOCK_FILE="${AGENT_LOOP_LOCK_FILE:-$LOGS_GITEA/agent-loop.lock}"
+STALE_SEC=$((24 * 3600))  # 24 hours
+mkdir -p "$(dirname "$LOCK_FILE")"
+
+if [ -f "$LOCK_FILE" ]; then
+  mtime=$(stat -c %Y "$LOCK_FILE" 2>/dev/null) || mtime=0
+  now=$(date +%s)
+  if [ $((now - mtime)) -lt "$STALE_SEC" ]; then
+    echo "[agent-loop-lock-acquire] $(date -Iseconds) — Lock actif: $LOCK_FILE (mtime < 24 h). Ne pas lancer une deuxième instance." >&2
+    exit 1
+  fi
+fi
+
+printf "%s\n%s\n" "$$" "$(date -Iseconds)" > "$LOCK_FILE"
+echo "[agent-loop-lock-acquire] $(date -Iseconds) — Lock acquis: $LOCK_FILE"
diff --git a/gitea-issues/agent-loop-lock-release.sh b/gitea-issues/agent-loop-lock-release.sh
new file mode 100755
index 0000000..5832a4f
--- /dev/null
+++ b/gitea-issues/agent-loop-lock-release.sh
@@ -0,0 +1,35 @@
+#!/usr/bin/env bash
+# Remove agent-loop.lock and optionally agent-loop.stop. Run at end of x cycles (normal or stop).
+# Run from repo root.
+#
+# Usage:
+#   cd <racine_projet> && ./ia_dev/gitea-issues/agent-loop-lock-release.sh
+#
+set -euo pipefail
+if [ -n "${HOME:-}" ] && [ -r "$HOME/.bashrc" ]; then
+  set +u
+  # shellcheck source=/dev/null
+  source "$HOME/.bashrc" 2>/dev/null || true
+  set -u
+fi
+
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+ROOT="$(cd "${GITEA_ISSUES_DIR}/../.." && pwd)"
+export GITEA_ISSUES_DIR
+export REPO_ROOT="${ROOT}"
+cd "$ROOT"
+# shellcheck source=lib.sh
+source "${GITEA_ISSUES_DIR}/lib.sh" 2>/dev/null || true
+LOGS_GITEA="${PROJECT_LOGS_DIR:-$ROOT/logs}/gitea-issues"
+
+LOCK_FILE="${AGENT_LOOP_LOCK_FILE:-$LOGS_GITEA/agent-loop.lock}"
+STOP_FILE="${AGENT_LOOP_STOP_FILE:-$LOGS_GITEA/agent-loop.stop}"
+
+if [ -f "$LOCK_FILE" ]; then
+  rm -f "$LOCK_FILE"
+  echo "[agent-loop-lock-release] $(date -Iseconds) — Lock supprimé: $LOCK_FILE"
+fi
+if [ -f "$STOP_FILE" ]; then
+  rm -f "$STOP_FILE"
+  echo "[agent-loop-lock-release] $(date -Iseconds) — Fichier stop supprimé: $STOP_FILE"
+fi
diff --git a/gitea-issues/agent-loop-retrieval-once.sh b/gitea-issues/agent-loop-retrieval-once.sh
new file mode 100755
index 0000000..cc2a440
--- /dev/null
+++ b/gitea-issues/agent-loop-retrieval-once.sh
@@ -0,0 +1,45 @@
+#!/usr/bin/env bash
+# One-shot retrieval: run tickets-fetch-inbox (spooler from/to) then list-pending-spooler; write paths to agent-loop.pending and status file.
+# Run from repo root. Used by agent-loop agent for "x times" cycles. Criterion: from/to in conf.json, not IMAP unread.
+#
+# Usage:
+#   cd <racine_projet> && ./ia_dev/gitea-issues/agent-loop-retrieval-once.sh
+#
+set -euo pipefail
+if [ -n "${HOME:-}" ] && [ -r "$HOME/.bashrc" ]; then
+  set +u
+  # shellcheck source=/dev/null
+  source "$HOME/.bashrc" 2>/dev/null || true
+  set -u
+fi
+
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+ROOT="$(cd "${GITEA_ISSUES_DIR}/../.." && pwd)"
+export GITEA_ISSUES_DIR
+export REPO_ROOT="${ROOT}"
+cd "$ROOT"
+# shellcheck source=lib.sh
+source "${GITEA_ISSUES_DIR}/lib.sh" 2>/dev/null || true
+LOGS_GITEA="${PROJECT_LOGS_DIR:-$ROOT/logs}/gitea-issues"
+
+STATUS_FILE="${AGENT_LOOP_STATUS_FILE:-$LOGS_GITEA/agent-loop.status}"
+PENDING_FILE="${AGENT_LOOP_PENDING_FILE:-$LOGS_GITEA/agent-loop.pending}"
+mkdir -p "$(dirname "$STATUS_FILE")"
+
+write_status() {
+  printf "%s\n%s\n%s\n" "$(date -Iseconds)" "$1" "${2:-}" > "$STATUS_FILE"
+}
+
+"${GITEA_ISSUES_DIR}/tickets-fetch-inbox.sh" 2>&1 || true
+pending_out=""
+pending_out=$("${GITEA_ISSUES_DIR}/list-pending-spooler.sh" 2>&1) || true
+if [ -n "$pending_out" ] && echo "$pending_out" | grep -q "\.pending"; then
+  write_status "mails_pending" "One-shot: mails en attente dans le spooler (from/to)."
+  printf "%s\n%s\n%s\n%s\n" "$(date -Iseconds)" "mails_pending" "---" "$pending_out" > "$PENDING_FILE"
+  n=$(echo "$pending_out" | grep -c "\.pending" || true)
+  echo "[agent-loop-retrieval-once] $(date -Iseconds) — $n mail(s) en attente dans le spooler (critère from/to). Écrit dans agent-loop.pending"
+else
+  write_status "idle" "One-shot: aucun mail en attente dans le spooler (critère: from/to dans conf.json)."
+  [ -f "$PENDING_FILE" ] && : > "$PENDING_FILE"
+  echo "[agent-loop-retrieval-once] $(date -Iseconds) — Aucun mail en attente dans le spooler (critère: from/to dans conf.json)"
+fi
diff --git a/gitea-issues/agent-loop-stop-requested.sh b/gitea-issues/agent-loop-stop-requested.sh
new file mode 100755
index 0000000..522c3a9
--- /dev/null
+++ b/gitea-issues/agent-loop-stop-requested.sh
@@ -0,0 +1,27 @@
+#!/usr/bin/env bash
+# Exit 0 if agent-loop.stop exists (stop requested), 1 otherwise. Used at start of each cycle.
+# Run from repo root.
+#
+# Usage:
+#   cd <racine_projet> && ./ia_dev/gitea-issues/agent-loop-stop-requested.sh
+#
+set -euo pipefail
+if [ -n "${HOME:-}" ] && [ -r "$HOME/.bashrc" ]; then
+  set +u
+  # shellcheck source=/dev/null
+  source "$HOME/.bashrc" 2>/dev/null || true
+  set -u
+fi
+
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+ROOT="$(cd "${GITEA_ISSUES_DIR}/../.." && pwd)"
+export GITEA_ISSUES_DIR
+export REPO_ROOT="${ROOT}"
+cd "$ROOT"
+# shellcheck source=lib.sh
+source "${GITEA_ISSUES_DIR}/lib.sh" 2>/dev/null || true
+LOGS_GITEA="${PROJECT_LOGS_DIR:-$ROOT/logs}/gitea-issues"
+
+STOP_FILE="${AGENT_LOOP_STOP_FILE:-$LOGS_GITEA/agent-loop.stop}"
+[ -f "$STOP_FILE" ]
+# exit 0 if file exists, 1 otherwise
diff --git a/gitea-issues/agent-loop-stop.sh b/gitea-issues/agent-loop-stop.sh
new file mode 100755
index 0000000..e2dc6a6
--- /dev/null
+++ b/gitea-issues/agent-loop-stop.sh
@@ -0,0 +1,28 @@
+#!/usr/bin/env bash
+# Create agent-loop.stop so the running agent-loop (section 2) stops at the next cycle start.
+# Run from repo root. Same paths as agent-loop-retrieval-once.sh (projects/<id>/logs/gitea-issues).
+#
+# Usage:
+#   cd <racine_projet> && ./ia_dev/gitea-issues/agent-loop-stop.sh
+#
+set -euo pipefail
+if [ -n "${HOME:-}" ] && [ -r "$HOME/.bashrc" ]; then
+  set +u
+  # shellcheck source=/dev/null
+  source "$HOME/.bashrc" 2>/dev/null || true
+  set -u
+fi
+
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+ROOT="$(cd "${GITEA_ISSUES_DIR}/../.." && pwd)"
+export GITEA_ISSUES_DIR
+export REPO_ROOT="${ROOT}"
+cd "$ROOT"
+# shellcheck source=lib.sh
+source "${GITEA_ISSUES_DIR}/lib.sh" 2>/dev/null || true
+LOGS_GITEA="${PROJECT_LOGS_DIR:-$ROOT/logs}/gitea-issues"
+
+STOP_FILE="${AGENT_LOOP_STOP_FILE:-$LOGS_GITEA/agent-loop.stop}"
+mkdir -p "$(dirname "$STOP_FILE")"
+touch "$STOP_FILE"
+echo "[agent-loop-stop] $(date -Iseconds) — $STOP_FILE créé. La boucle en cours s'arrêtera au début du prochain cycle."
diff --git a/gitea-issues/agent-loop-treatment.sh b/gitea-issues/agent-loop-treatment.sh
new file mode 100755
index 0000000..196e2e7
--- /dev/null
+++ b/gitea-issues/agent-loop-treatment.sh
@@ -0,0 +1,52 @@
+#!/usr/bin/env bash
+# Treatment loop: periodically check agent-loop.pending and run Cursor Agent CLI (gitea-issues-process workflow) when non-empty.
+# Run from repo root. No timeout; runs forever. Do NOT start this script from the agent-loop agent (use bounded runs only).
+#
+# Usage (manual only; agent must not launch with nohup/&):
+#   cd <racine_projet> && ./ia_dev/gitea-issues/agent-loop-treatment.sh
+#
+set -euo pipefail
+if [ -n "${HOME:-}" ] && [ -r "$HOME/.bashrc" ]; then
+  set +u
+  # shellcheck source=/dev/null
+  source "$HOME/.bashrc" 2>/dev/null || true
+  set -u
+fi
+[ -n "${HOME:-}" ] && [ -d "$HOME/.local/bin" ] && export PATH="$HOME/.local/bin:$PATH"
+
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+ROOT="$(git rev-parse --show-toplevel 2>/dev/null)" || ROOT="$(cd "${GITEA_ISSUES_DIR}/../.." && pwd)"
+export GITEA_ISSUES_DIR
+export REPO_ROOT="${ROOT}"
+cd "$ROOT"
+# shellcheck source=lib.sh
+source "${GITEA_ISSUES_DIR}/lib.sh" 2>/dev/null || true
+LOGS_GITEA="${PROJECT_LOGS_DIR:-$ROOT/logs}/gitea-issues"
+
+PENDING_FILE="${AGENT_LOOP_PENDING_FILE:-$LOGS_GITEA/agent-loop.pending}"
+LOG_DIR="$(dirname "$PENDING_FILE")"
+mkdir -p "$LOG_DIR"
+
+AGENT_LOOP_ENV="${GITEA_ISSUES_DIR}/../.secrets/gitea-issues/agent-loop.env"
+if [ -r "$AGENT_LOOP_ENV" ]; then
+  set +u
+  # shellcheck source=/dev/null
+  source "$AGENT_LOOP_ENV"
+  set -u
+fi
+INTERVAL="${AGENT_LOOP_TREATMENT_INTERVAL_SEC:-60}"
+AGENT_MODEL="${AGENT_LOOP_MODEL:-sonnet-4.6}"
+
+PROMPT="Exécute le workflow mails du spooler (agent gitea-issues-process). Les chemins des fichiers .pending sont dans projects/<id>/logs/gitea-issues/agent-loop.pending (ou exécuter ./ia_dev/gitea-issues/list-pending-spooler.sh). Pour chaque fichier .pending : lire le JSON (from, to, subject, body, message_id, base). Rédiger une réponse pertinente (uniquement ton texte ; pas de citation — mail-send-reply.sh refuse si le body contient From:, Message-ID, wrote:, etc.). Envoyer avec ./ia_dev/gitea-issues/mail-send-reply.sh --to <from> --subject \"Re: ...\" --body \"<ta_réponse>\" --in-reply-to \"<message_id>\". Après envoi réussi : ./ia_dev/gitea-issues/write-response-spooler.sh --base <base> --to <from> --subject \"Re: ...\" --body \"<ta_réponse>\" --in-reply-to \"<message_id>\". Ne pas appeler mail-mark-read.sh (spooler)."
+
+while true; do
+  if [ -s "$PENDING_FILE" ] && command -v agent >/dev/null 2>&1; then
+    echo "[agent-loop-treatment] $(date -Iseconds) — Pending non vide, lancement de l'agent Cursor."
+    if agent -p "$PROMPT" -f --model "$AGENT_MODEL" 2>&1; then
+      echo "[agent-loop-treatment] $(date -Iseconds) — Agent terminé."
+    else
+      echo "[agent-loop-treatment] $(date -Iseconds) — Agent terminé avec erreur."
+    fi
+  fi
+  sleep "$INTERVAL"
+done
diff --git a/gitea-issues/agent-loop.env.example b/gitea-issues/agent-loop.env.example
new file mode 100644
index 0000000..41d4e0e
--- /dev/null
+++ b/gitea-issues/agent-loop.env.example
@@ -0,0 +1,19 @@
+# Agent-loop parameters (Cursor Agent CLI, model, interval).
+# Copy to .secrets/gitea-issues/agent-loop.env and set as needed.
+# Do not commit .secrets/gitea-issues/agent-loop.env (directory is gitignored).
+#
+# Run Cursor Agent when unread mails are detected (0 or 1)
+# AGENT_LOOP_RUN_AGENT=1
+#
+# Model used by the CLI (default: sonnet-4.6 to avoid Opus usage limits)
+# List: agent models
+# AGENT_LOOP_MODEL=sonnet-4.6
+#
+# Polling interval in seconds (default: 60)
+# AGENT_LOOP_INTERVAL_SEC=60
+#
+# Optional: custom paths for status, pending, lock and stop files
+# AGENT_LOOP_STATUS_FILE=ia_dev/projects/<id>/logs/gitea-issues/agent-loop.status
+# AGENT_LOOP_PENDING_FILE=ia_dev/projects/<id>/logs/gitea-issues/agent-loop.pending
+# AGENT_LOOP_LOCK_FILE=ia_dev/projects/<id>/logs/gitea-issues/agent-loop.lock
+# AGENT_LOOP_STOP_FILE=ia_dev/projects/<id>/logs/gitea-issues/agent-loop.stop
diff --git a/gitea-issues/agent-loop.sh b/gitea-issues/agent-loop.sh
new file mode 100755
index 0000000..0db2582
--- /dev/null
+++ b/gitea-issues/agent-loop.sh
@@ -0,0 +1,91 @@
+#!/usr/bin/env bash
+# Agent loop: poll for mails to treat (spooler criterion: from/to in conf.json, not IMAP unread).
+# Run from repo root. Runs forever. Do NOT start from the agent-loop agent (use bounded runs only, e.g. agent-loop-chat-iterations.sh N).
+#
+# Usage (manual only; agent must not launch with nohup/&):
+#   ./gitea-issues/agent-loop.sh [interval_seconds]
+#   AGENT_LOOP_INTERVAL_SEC=120 ./gitea-issues/agent-loop.sh
+#
+# Witness file: projects/<id>/logs/gitea-issues/agent-loop.status (or AGENT_LOOP_STATUS_FILE)
+#   State file (not a log): updated every iteration. If mtime is older than 2*interval, loop is considered stopped.
+# Pending file: projects/<id>/logs/gitea-issues/agent-loop.pending (or AGENT_LOOP_PENDING_FILE)
+#   Written when there are .pending mails in the spooler (no matching .response); contains paths to treat.
+#
+# Optional: set AGENT_LOOP_RUN_AGENT=1 to run the Cursor Agent CLI when mails are detected.
+# Requires Cursor Agent CLI (https://cursor.com/docs/cli/using). If "agent" is not in PATH, the loop only updates status/pending.
+#
+# Optional: AGENT_LOOP_MODEL=<model> to force the model (e.g. sonnet-4.6, gpt-5.4-low). Default: sonnet-4.6 to avoid Opus usage limits when running unattended.
+#
+set -euo pipefail
+# Source user env so PATH includes ~/.local/bin (Cursor Agent CLI, etc.)
+if [ -n "${HOME:-}" ] && [ -r "$HOME/.bashrc" ]; then
+  set +u
+  # shellcheck source=/dev/null
+  source "$HOME/.bashrc" 2>/dev/null || true
+  set -u
+fi
+[ -n "${HOME:-}" ] && [ -d "$HOME/.local/bin" ] && export PATH="$HOME/.local/bin:$PATH"
+
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+ROOT="$(cd "${GITEA_ISSUES_DIR}/../.." && pwd)"
+export GITEA_ISSUES_DIR
+export REPO_ROOT="${ROOT}"
+cd "$ROOT"
+# Per-project logs under projects/<id>/logs (lib.sh sets PROJECT_LOGS_DIR)
+# shellcheck source=lib.sh
+source "${GITEA_ISSUES_DIR}/lib.sh" 2>/dev/null || true
+LOGS_GITEA="${PROJECT_LOGS_DIR:-$ROOT/logs}/gitea-issues"
+
+# Load agent-loop parameters from .secrets (optional; .secrets under ia_dev)
+AGENT_LOOP_ENV="${GITEA_ISSUES_DIR}/../.secrets/gitea-issues/agent-loop.env"
+if [ -r "$AGENT_LOOP_ENV" ]; then
+  set +u
+  # shellcheck source=/dev/null
+  source "$AGENT_LOOP_ENV"
+  set -u
+fi
+
+INTERVAL="${1:-${AGENT_LOOP_INTERVAL_SEC:-60}}"
+# STATUS_FILE: state/witness file (not a log) — indicates if the loop is active; under projects/<id>/logs/gitea-issues/ for per-project state.
+STATUS_FILE="${AGENT_LOOP_STATUS_FILE:-$LOGS_GITEA/agent-loop.status}"
+PENDING_FILE="${AGENT_LOOP_PENDING_FILE:-$LOGS_GITEA/agent-loop.pending}"
+mkdir -p "$(dirname "$STATUS_FILE")"
+
+write_status() {
+  local status="$1"
+  local detail="${2:-}"
+  printf "%s\n%s\n%s\n" "$(date -Iseconds)" "$status" "$detail" > "$STATUS_FILE"
+}
+
+while true; do
+  write_status "running" "interval=${INTERVAL}s"
+  # Spooler flow: fetch by from/to (conf.json), then list .pending without .response. No IMAP unread criterion.
+  "${GITEA_ISSUES_DIR}/tickets-fetch-inbox.sh" 2>&1 || true
+  pending_out=""
+  pending_out=$("${GITEA_ISSUES_DIR}/list-pending-spooler.sh" 2>&1) || true
+  if [ -n "$pending_out" ] && echo "$pending_out" | grep -q "\.pending"; then
+    write_status "mails_pending" "Mails en attente dans le spooler (from/to). Lancer l'agent gitea-issues-process dans Cursor."
+    printf "%s\n%s\n%s\n%s\n" "$(date -Iseconds)" "mails_pending" "---" "$pending_out" > "$PENDING_FILE"
+    n=$(echo "$pending_out" | grep -c "\.pending" || true)
+    echo "[agent-loop] $(date -Iseconds) — $n mail(s) en attente dans le spooler (critère from/to). Lancer l'agent gitea-issues-process dans Cursor."
+    if [ "${AGENT_LOOP_RUN_AGENT:-0}" = "1" ] && command -v agent >/dev/null 2>&1; then
+      write_status "running_agent" "Lancement de l'agent Cursor pour traiter les mails du spooler."
+      echo "[agent-loop] $(date -Iseconds) — Lancement de l'agent Cursor (workflow gitea-issues-process spooler)."
+      AGENT_MODEL="${AGENT_LOOP_MODEL:-sonnet-4.6}"
+      echo "[agent-loop] $(date -Iseconds) — Modèle: $AGENT_MODEL"
+      AGENT_OPTS=(-p "Exécute le workflow mails du spooler (agent gitea-issues-process). 1) Lister les mails à traiter avec ./ia_dev/gitea-issues/list-pending-spooler.sh (ou utiliser les chemins dans agent-loop.pending). 2) Pour chaque fichier .pending : lire le JSON (from, to, subject, body, message_id, base). Rédiger une réponse pertinente (uniquement ton texte, pas de citation ; mail-send-reply.sh refuse si le body contient From:, Message-ID, wrote:, etc.). Envoyer avec ./ia_dev/gitea-issues/mail-send-reply.sh --to <from> --subject \"Re: ...\" --body \"<ta_réponse>\" --in-reply-to \"<message_id>\". Après envoi réussi : ./ia_dev/gitea-issues/write-response-spooler.sh --base <base> --to <from> --subject \"Re: ...\" --body \"<ta_réponse>\" --in-reply-to \"<message_id>\". Ne pas appeler mail-mark-read.sh (spooler)." -f --model "$AGENT_MODEL")
+      if agent "${AGENT_OPTS[@]}" 2>&1; then
+        write_status "agent_done" "Agent terminé."
+      else
+        write_status "mails_pending" "Agent terminé avec erreur ou interruption. Relancer l'agent manuellement si besoin."
+      fi
+    fi
+  else
+    write_status "idle" "Aucun mail en attente dans le spooler (critère: from/to dans conf.json)."
+    if [ -f "$PENDING_FILE" ]; then
+      : > "$PENDING_FILE"
+    fi
+    echo "[agent-loop] $(date -Iseconds) — Aucun mail en attente dans le spooler (critère: from/to dans conf.json)."
+  fi
+  sleep "$INTERVAL"
+done
diff --git a/gitea-issues/comment-issue.sh b/gitea-issues/comment-issue.sh
new file mode 100755
index 0000000..6ed8f4d
--- /dev/null
+++ b/gitea-issues/comment-issue.sh
@@ -0,0 +1,50 @@
+#!/usr/bin/env bash
+#
+# Add a comment to an issue via Gitea API. The comment body is automatically
+# signed with: Support IA du projet Lecoffre.io / ai.support.lecoffreio@4nkweb.com
+# Usage: ./comment-issue.sh <issue_number> <message>
+# Or:    echo "message" | ./comment-issue.sh <issue_number> -
+#
+set -euo pipefail
+
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+# shellcheck source=lib.sh
+source "${GITEA_ISSUES_DIR}/lib.sh"
+
+# Signature appended to every comment (same as mail replies)
+COMMENT_SIGNATURE=$'\n\n--\nSupport IA du projet Lecoffre.io\nai.support.lecoffreio@4nkweb.com'
+if [[ -n "${GITEA_COMMENT_SIGNATURE:-}" ]]; then
+	COMMENT_SIGNATURE="${GITEA_COMMENT_SIGNATURE}"
+fi
+
+require_jq || exit 1
+
+if [[ $# -lt 1 ]]; then
+	log_err "Usage: $0 <issue_number> <message>"
+	log_err "   Or: $0 <issue_number> -   (read message from stdin)"
+	exit 1
+fi
+
+ISSUE_NUM="$1"
+if [[ "${2:-}" == "-" ]]; then
+	BODY="$(cat)"
+else
+	BODY="${2:-}"
+fi
+
+if [[ -z "$BODY" ]]; then
+	log_err "Comment body is empty."
+	exit 1
+fi
+
+BODY="${BODY}${COMMENT_SIGNATURE}"
+
+# Escape for JSON: jq -Rs . handles newlines and quotes
+BODY_JSON="$(echo "$BODY" | jq -Rs .)"
+RESPONSE="$(gitea_api_post "/repos/${GITEA_REPO_OWNER}/${GITEA_REPO_NAME}/issues/${ISSUE_NUM}/comments" "{\"body\":${BODY_JSON}}")"
+if ! echo "$RESPONSE" | jq -e . &>/dev/null; then
+	log_err "API error posting comment: ${RESPONSE:0:200}"
+	exit 1
+fi
+
+log_info "Comment added to issue #${ISSUE_NUM}."
diff --git a/gitea-issues/create-branch-for-issue.sh b/gitea-issues/create-branch-for-issue.sh
new file mode 100755
index 0000000..4ccccf0
--- /dev/null
+++ b/gitea-issues/create-branch-for-issue.sh
@@ -0,0 +1,45 @@
+#!/usr/bin/env bash
+#
+# Create a local branch for an issue. Branch name: issue/<number> (safe, short).
+# Base branch defaults to "test"; ensure it is up to date (fetch + reset to origin/base).
+# Usage: ./create-branch-for-issue.sh <issue_number> [base_branch]
+#
+set -euo pipefail
+
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+# shellcheck source=lib.sh
+source "${GITEA_ISSUES_DIR}/lib.sh"
+
+if [[ $# -lt 1 ]]; then
+	log_err "Usage: $0 <issue_number> [base_branch]"
+	exit 1
+fi
+
+ISSUE_NUM="$1"
+BASE="${2:-test}"
+
+require_git_root || exit 1
+
+if git show-ref --quiet "refs/heads/issue/${ISSUE_NUM}"; then
+	log_info "Branch issue/${ISSUE_NUM} already exists. Checking it out."
+	git checkout "issue/${ISSUE_NUM}"
+	echo "issue/${ISSUE_NUM}"
+	exit 0
+fi
+
+if ! git show-ref --quiet "refs/heads/${BASE}"; then
+	log_err "Base branch ${BASE} does not exist locally."
+	exit 1
+fi
+
+git fetch origin
+if git show-ref --quiet "refs/remotes/origin/${BASE}"; then
+	git checkout "${BASE}"
+	git reset --hard "origin/${BASE}"
+else
+	git checkout "${BASE}"
+fi
+
+git checkout -b "issue/${ISSUE_NUM}"
+log_info "Created and checked out branch issue/${ISSUE_NUM} from ${BASE}."
+echo "issue/${ISSUE_NUM}"
diff --git a/gitea-issues/get-issue.sh b/gitea-issues/get-issue.sh
new file mode 100755
index 0000000..7388af1
--- /dev/null
+++ b/gitea-issues/get-issue.sh
@@ -0,0 +1,39 @@
+#!/usr/bin/env bash
+#
+# Get one issue by number. Output: JSON (default) or plain text summary (--summary).
+# Usage: ./get-issue.sh <issue_number> [--summary]
+#
+set -euo pipefail
+
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+# shellcheck source=lib.sh
+source "${GITEA_ISSUES_DIR}/lib.sh"
+
+require_jq || exit 1
+
+if [[ $# -lt 1 ]]; then
+	log_err "Usage: $0 <issue_number> [--summary]"
+	exit 1
+fi
+
+ISSUE_NUM="$1"
+SUMMARY=false
+[[ "${2:-}" == "--summary" ]] && SUMMARY=true
+
+RESPONSE="$(gitea_api_get "/repos/${GITEA_REPO_OWNER}/${GITEA_REPO_NAME}/issues/${ISSUE_NUM}")"
+if ! echo "$RESPONSE" | jq -e . &>/dev/null; then
+	log_err "API error or invalid JSON (issue ${ISSUE_NUM}): ${RESPONSE:0:200}"
+	exit 1
+fi
+
+if [[ "$SUMMARY" == true ]]; then
+	echo "--- Issue #${ISSUE_NUM} ---"
+	echo "Title: $(echo "$RESPONSE" | jq -r '.title')"
+	echo "State: $(echo "$RESPONSE" | jq -r '.state')"
+	echo "Labels: $(echo "$RESPONSE" | jq -r '[.labels[].name] | join(", ")')"
+	echo "Body:"
+	echo "$RESPONSE" | jq -r '.body // "(empty)"'
+	echo "---"
+else
+	echo "$RESPONSE"
+fi
diff --git a/gitea-issues/imap-bridge.env.example b/gitea-issues/imap-bridge.env.example
new file mode 100644
index 0000000..169cc80
--- /dev/null
+++ b/gitea-issues/imap-bridge.env.example
@@ -0,0 +1,43 @@
+# IMAP config for mail-to-issue (e.g. Proton Mail Bridge).
+# Copy to .secrets/gitea-issues/imap-bridge.env and set real values.
+# Do not commit .secrets/gitea-issues/imap-bridge.env (directory is gitignored).
+#
+# IMAP (read)
+# IMAP_HOST=127.0.0.1
+# IMAP_PORT=1143
+# IMAP_USER=your-address@pm.me
+# IMAP_PASSWORD=your-bridge-password
+# IMAP_USE_STARTTLS=true
+# For local Proton Bridge with self-signed cert, set to false to skip SSL verification (localhost only).
+# IMAP_SSL_VERIFY=false
+#
+# SMTP (send replies; same Bridge account)
+# SMTP_HOST=127.0.0.1
+# SMTP_PORT=1025
+# SMTP_USER=your-address@pm.me
+# SMTP_PASSWORD=your-bridge-password
+# SMTP_USE_STARTTLS=true
+#
+# Restrict listed mails to those sent to this address (default: ai.support.lecoffreio@4nkweb.com)
+# MAIL_FILTER_TO=ai.support.lecoffreio@4nkweb.com
+#
+# Only fetch/list mails on or after this date (IMAP format DD-Mon-YYYY). Default: 10-Mar-2026.
+# MAIL_SINCE_DATE=10-Mar-2026
+#
+# Signature appended to every reply (default: Support IA du projet Lecoffre.io + ai.support.lecoffreio@4nkweb.com)
+# MAIL_REPLY_SIGNATURE=--\\nSupport IA du projet Lecoffre.io\\nai.support.lecoffreio@4nkweb.com
+#
+# Signature for Gitea issue comments (optional; comment-issue.sh uses same default as mail signature)
+# GITEA_COMMENT_SIGNATURE=
+
+IMAP_HOST=127.0.0.1
+IMAP_PORT=1143
+IMAP_USER=
+IMAP_PASSWORD=
+IMAP_USE_STARTTLS=true
+
+SMTP_HOST=127.0.0.1
+SMTP_PORT=1025
+SMTP_USER=
+SMTP_PASSWORD=
+SMTP_USE_STARTTLS=true
diff --git a/gitea-issues/lib.sh b/gitea-issues/lib.sh
new file mode 100755
index 0000000..3029fb1
--- /dev/null
+++ b/gitea-issues/lib.sh
@@ -0,0 +1,122 @@
+#!/usr/bin/env bash
+#
+# Shared config and helpers for Gitea issues scripts.
+# Source from gitea-issues/*.sh after cd to project root.
+#
+set -euo pipefail
+
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+GITEA_API_URL="${GITEA_API_URL:-https://git.4nkweb.com/api/v1}"
+GITEA_REPO_OWNER="${GITEA_REPO_OWNER:-4nk}"
+GITEA_REPO_NAME="${GITEA_REPO_NAME:-lecoffre_ng}"
+
+# Optional: load project config from ia_dev (projects/<id>/conf.json); logs and data per project under projects/<id>/
+PROJECT_CONFIG_PATH=""
+PROJECT_LOGS_DIR=""
+DATA_ISSUES_DIR=""
+if [[ -f "${GITEA_ISSUES_DIR}/../lib/project_config.sh" ]]; then
+	PROJECT_ROOT="$(git rev-parse --show-toplevel 2>/dev/null)" || true
+	if [[ -z "${PROJECT_ROOT:-}" || "$(basename "$PROJECT_ROOT")" = "ia_dev" ]]; then
+		PROJECT_ROOT="$(cd "${GITEA_ISSUES_DIR}/../.." && pwd)"
+	fi
+	IA_DEV_ROOT="$(cd "$GITEA_ISSUES_DIR/.." && pwd)"
+	if [[ -n "${PROJECT_ROOT:-}" ]]; then
+		# shellcheck source=../lib/project_config.sh
+		source "${GITEA_ISSUES_DIR}/../lib/project_config.sh"
+		if [[ -n "${PROJECT_SLUG:-}" && -n "${IA_DEV_ROOT:-}" ]]; then
+			PROJECT_LOGS_DIR="${IA_DEV_ROOT}/projects/${PROJECT_SLUG}/logs"
+			DATA_ISSUES_DIR="${IA_DEV_ROOT}/projects/${PROJECT_SLUG}/data/issues"
+			mkdir -p "${PROJECT_LOGS_DIR}" "${DATA_ISSUES_DIR}"
+		fi
+	fi
+fi
+export PROJECT_LOGS_DIR
+export DATA_ISSUES_DIR
+
+# Load token: GITEA_TOKEN env, then project config git.token_file, then default .secrets path
+load_gitea_token() {
+	if [[ -n "${GITEA_TOKEN:-}" ]]; then
+		return 0
+	fi
+	local token_file=""
+	if [[ -n "${PROJECT_CONFIG_PATH:-}" && -f "$PROJECT_CONFIG_PATH" ]] && command -v jq >/dev/null 2>&1; then
+		local rel_path
+		rel_path="$(jq -r '.git.token_file // empty' "$PROJECT_CONFIG_PATH" 2>/dev/null)"
+		if [[ -n "$rel_path" && -n "${PROJECT_ROOT:-}" && -f "${PROJECT_ROOT}/${rel_path}" ]]; then
+			token_file="${PROJECT_ROOT}/${rel_path}"
+		fi
+	fi
+	if [[ -z "$token_file" ]]; then
+		token_file="${GITEA_ISSUES_DIR}/../.secrets/gitea-issues/token"
+	fi
+	if [[ -f "$token_file" ]]; then
+		GITEA_TOKEN="$(cat "$token_file")"
+		return 0
+	fi
+	echo "[gitea-issues] ERROR: GITEA_TOKEN not set and ${token_file} not found" >&2
+	echo "[gitea-issues] Set GITEA_TOKEN or create the token file with a Gitea Personal Access Token." >&2
+	return 1
+}
+
+# curl wrapper for Gitea API (GET). Usage: gitea_api_get "/repos/owner/repo/issues"
+gitea_api_get() {
+	local path="$1"
+	load_gitea_token || return 1
+	curl -sS -H "Accept: application/json" \
+		-H "Authorization: token ${GITEA_TOKEN}" \
+		"${GITEA_API_URL}${path}"
+}
+
+# curl wrapper for Gitea API (POST). Usage: gitea_api_post "/repos/owner/repo/issues/123/comments" '{"body":"..."}'
+gitea_api_post() {
+	local path="$1"
+	local data="${2:-}"
+	load_gitea_token || return 1
+	curl -sS -X POST -H "Accept: application/json" -H "Content-Type: application/json" \
+		-H "Authorization: token ${GITEA_TOKEN}" \
+		-d "$data" \
+		"${GITEA_API_URL}${path}"
+}
+
+# curl wrapper for Gitea API (PATCH). Usage: gitea_api_patch "/repos/owner/repo/wiki/page/Foo" '{"content_base64":"..."}'
+gitea_api_patch() {
+	local path="$1"
+	local data="${2:-}"
+	load_gitea_token || return 1
+	curl -sS -X PATCH -H "Accept: application/json" -H "Content-Type: application/json" \
+		-H "Authorization: token ${GITEA_TOKEN}" \
+		-d "$data" \
+		"${GITEA_API_URL}${path}"
+}
+
+# curl wrapper for Gitea API (DELETE). Usage: gitea_api_delete "/repos/owner/repo/wiki/page/Foo"
+gitea_api_delete() {
+	local path="$1"
+	load_gitea_token || return 1
+	curl -sS -X DELETE -H "Accept: application/json" \
+		-H "Authorization: token ${GITEA_TOKEN}" \
+		"${GITEA_API_URL}${path}"
+}
+
+log_ts() { date -u '+%Y-%m-%dT%H:%M:%SZ'; }
+log_info() { echo "[$(log_ts)] [gitea-issues] $*"; }
+log_err() { echo "[$(log_ts)] [gitea-issues] $*" >&2; }
+
+# Require jq for JSON output
+require_jq() {
+	if ! command -v jq &>/dev/null; then
+		log_err "jq is required. Install with: apt install jq / brew install jq"
+		return 1
+	fi
+}
+
+# Ensure we are in the git repo root (for create-branch, etc.)
+require_git_root() {
+	local root
+	root="$(git rev-parse --show-toplevel 2>/dev/null)" || true
+	if [[ -z "$root" ]]; then
+		log_err "Not inside a git repository."
+		return 1
+	fi
+	cd "$root"
+}
diff --git a/gitea-issues/list-open-issues.sh b/gitea-issues/list-open-issues.sh
new file mode 100755
index 0000000..052abdf
--- /dev/null
+++ b/gitea-issues/list-open-issues.sh
@@ -0,0 +1,35 @@
+#!/usr/bin/env bash
+#
+# List open issues for the configured Gitea repo.
+# Output: JSON array (default) or one line per issue "number|title|state" with --lines.
+# Usage: ./list-open-issues.sh [--lines] [--limit N]
+#
+set -euo pipefail
+
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+# shellcheck source=lib.sh
+source "${GITEA_ISSUES_DIR}/lib.sh"
+
+require_jq || exit 1
+
+LINES=false
+LIMIT=50
+while [[ $# -gt 0 ]]; do
+	case "$1" in
+		--lines) LINES=true; shift ;;
+		--limit) LIMIT="$2"; shift 2 ;;
+		*) log_err "Unknown option: $1"; exit 1 ;;
+	esac
+done
+
+RESPONSE="$(gitea_api_get "/repos/${GITEA_REPO_OWNER}/${GITEA_REPO_NAME}/issues?state=open&page=1&limit=${LIMIT}")"
+if ! echo "$RESPONSE" | jq -e . &>/dev/null; then
+	log_err "API error or invalid JSON: ${RESPONSE:0:200}"
+	exit 1
+fi
+
+if [[ "$LINES" == true ]]; then
+	echo "$RESPONSE" | jq -r '.[] | "\(.number)|\(.title)|\(.state)"'
+else
+	echo "$RESPONSE"
+fi
diff --git a/gitea-issues/list-pending-spooler.sh b/gitea-issues/list-pending-spooler.sh
new file mode 100755
index 0000000..bea8b04
--- /dev/null
+++ b/gitea-issues/list-pending-spooler.sh
@@ -0,0 +1,23 @@
+#!/usr/bin/env bash
+# List .pending files in projects/<id>/data/issues/ with status "pending" (one file per message; status updated in place).
+# Run from repo root. Output: one path per line.
+# Usage: ./ia_dev/gitea-issues/list-pending-spooler.sh
+set -euo pipefail
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+ROOT="$(cd "${GITEA_ISSUES_DIR}/../.." && pwd)"
+export GITEA_ISSUES_DIR
+cd "$ROOT"
+# shellcheck source=lib.sh
+source "${GITEA_ISSUES_DIR}/lib.sh" 2>/dev/null || true
+SPOOL="${DATA_ISSUES_DIR:-}"
+if [[ -z "${SPOOL:-}" || ! -d "$SPOOL" ]]; then
+  echo "[gitea-issues] DATA_ISSUES_DIR not set or not a directory. Run from repo root with projects/<id> configured." >&2
+  exit 1
+fi
+for f in "${SPOOL}"/*.pending; do
+  [[ -f "$f" ]] || continue
+  status="$(jq -r '.status // "pending"' "$f" 2>/dev/null)"
+  if [[ "$status" != "responded" ]]; then
+    echo "$f"
+  fi
+done
diff --git a/gitea-issues/mail-create-issue-from-email.py b/gitea-issues/mail-create-issue-from-email.py
new file mode 100755
index 0000000..1122c2b
--- /dev/null
+++ b/gitea-issues/mail-create-issue-from-email.py
@@ -0,0 +1,110 @@
+#!/usr/bin/env python3
+"""
+Create one Gitea issue from one email (by UID), then mark the email as read.
+If --title and/or --body are provided (formalized by agent), use them; else use subject and body from the email.
+Usage: ./gitea-issues/mail-create-issue-from-email.sh --uid <uid> [--title "..." ] [--body "..." ]
+"""
+
+from __future__ import annotations
+
+import argparse
+import email
+import imaplib
+import ssl
+import sys
+from email.header import decode_header
+from pathlib import Path
+
+sys.path.insert(0, str(Path(__file__).resolve().parent))
+from mail_common import (
+    create_gitea_issue,
+    load_gitea_config,
+    load_imap_config,
+    repo_root,
+    sanitize_title,
+)
+
+
+def decode_header_value(header: str | None) -> str:
+    if not header:
+        return ""
+    from email.header import decode_header as dh
+    parts = dh(header)
+    result = []
+    for part, charset in parts:
+        if isinstance(part, bytes):
+            result.append(part.decode(charset or "utf-8", errors="replace"))
+        else:
+            result.append(part)
+    return "".join(result)
+
+
+def get_text_body(msg: email.message.Message) -> str:
+    if msg.is_multipart():
+        for part in msg.walk():
+            if part.get_content_type() == "text/plain":
+                payload = part.get_payload(decode=True)
+                if payload:
+                    return payload.decode(part.get_content_charset() or "utf-8", errors="replace")
+        return ""
+    payload = msg.get_payload(decode=True)
+    if not payload:
+        return ""
+    return payload.decode(msg.get_content_charset() or "utf-8", errors="replace")
+
+
+def main() -> None:
+    ap = argparse.ArgumentParser(description="Create one Gitea issue from one email by UID")
+    ap.add_argument("--uid", required=True, help="IMAP message UID")
+    ap.add_argument("--title", default="", help="Formalized issue title (else use subject)")
+    ap.add_argument("--body", default="", help="Formalized issue body (else use email body + From)")
+    args = ap.parse_args()
+
+    cfg = load_imap_config()
+    if not cfg["user"] or not cfg["password"]:
+        root = repo_root()
+        env_path = root / ".secrets" / "gitea-issues" / "imap-bridge.env"
+        print("[gitea-issues] ERROR: IMAP_USER and IMAP_PASSWORD required.", file=sys.stderr)
+        sys.exit(1)
+
+    gitea = load_gitea_config()
+    if not gitea["token"]:
+        print("[gitea-issues] ERROR: GITEA_TOKEN not set.", file=sys.stderr)
+        sys.exit(1)
+
+    mail = imaplib.IMAP4(cfg["host"], int(cfg["port"]))
+    if cfg["use_starttls"]:
+        mail.starttls(ssl.create_default_context())
+    mail.login(cfg["user"], cfg["password"])
+    mail.select("INBOX")
+    _, data = mail.fetch(args.uid, "(RFC822)")
+    if not data or not data[0]:
+        print("[gitea-issues] ERROR: Message UID not found.", file=sys.stderr)
+        mail.logout()
+        sys.exit(1)
+
+    msg = email.message_from_bytes(data[0][1])
+    from_ = decode_header_value(msg.get("From"))
+    subject = decode_header_value(msg.get("Subject"))
+    body_text = get_text_body(msg)
+    body_for_issue = f"**From:** {from_}\n\n{body_text}".strip()
+
+    title = args.title.strip() if args.title else sanitize_title(subject)
+    body = args.body.strip() if args.body else body_for_issue
+
+    issue = create_gitea_issue(title, body)
+    if not issue:
+        print("[gitea-issues] ERROR: Failed to create issue.", file=sys.stderr)
+        mail.logout()
+        sys.exit(1)
+
+    mail.store(args.uid, "+FLAGS", "\\Seen")
+    mail.logout()
+
+    num = issue.get("number", "?")
+    print(f"[gitea-issues] Created issue #{num}: {title[:60]}")
+    print(f"ISSUE_NUMBER={num}")
+
+
+if __name__ == "__main__":
+    main()
diff --git a/gitea-issues/mail-create-issue-from-email.sh b/gitea-issues/mail-create-issue-from-email.sh
new file mode 100755
index 0000000..630a521
--- /dev/null
+++ b/gitea-issues/mail-create-issue-from-email.sh
@@ -0,0 +1,8 @@
+#!/usr/bin/env bash
+# Create one Gitea issue from one email (by UID), mark email read. Run from repo root.
+# Usage: ./gitea-issues/mail-create-issue-from-email.sh --uid <uid> [--title "..." ] [--body "..." ]
+set -euo pipefail
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+export GITEA_ISSUES_DIR
+export REPO_ROOT="${GITEA_ISSUES_DIR}/.."
+exec python3 "${GITEA_ISSUES_DIR}/mail-create-issue-from-email.py" "$@"
diff --git a/gitea-issues/mail-get-thread.py b/gitea-issues/mail-get-thread.py
new file mode 100644
index 0000000..80e0e14
--- /dev/null
+++ b/gitea-issues/mail-get-thread.py
@@ -0,0 +1,208 @@
+#!/usr/bin/env python3
+"""
+Fetch the full email thread (conversation) for a given message UID.
+Uses Message-ID, References and In-Reply-To to find all messages in the thread.
+Output format: same as mail-list-unread (--- MAIL UID=... --- ... --- END MAIL ---), chronological order.
+Usage: mail-get-thread.py <uid>
+       or: ./gitea-issues/mail-get-thread.sh <uid>
+"""
+
+from __future__ import annotations
+
+import email
+import imaplib
+import re
+import sys
+from email.header import decode_header
+from pathlib import Path
+
+sys.path.insert(0, str(Path(__file__).resolve().parent))
+from mail_common import imap_since_date, load_imap_config, repo_root, imap_ssl_context
+
+
+def decode_header_value(header: str | None) -> str:
+    if not header:
+        return ""
+    parts = decode_header(header)
+    result = []
+    for part, charset in parts:
+        if isinstance(part, bytes):
+            result.append(part.decode(charset or "utf-8", errors="replace"))
+        else:
+            result.append(part)
+    return "".join(result)
+
+
+def get_text_body(msg: email.message.Message) -> str:
+    if msg.is_multipart():
+        for part in msg.walk():
+            if part.get_content_type() == "text/plain":
+                payload = part.get_payload(decode=True)
+                if payload:
+                    return payload.decode(
+                        part.get_content_charset() or "utf-8", errors="replace"
+                    )
+        return ""
+    payload = msg.get_payload(decode=True)
+    if not payload:
+        return ""
+    return payload.decode(
+        msg.get_content_charset() or "utf-8", errors="replace"
+    )
+
+
+def parse_message_ids(refs: str | None, in_reply_to: str | None) -> set[str]:
+    """Extract Message-ID values from References and In-Reply-To headers."""
+    ids: set[str] = set()
+    for raw in (refs or "", in_reply_to or ""):
+        for part in re.split(r"\s+", raw.strip()):
+            part = part.strip()
+            if part.startswith("<") and ">" in part:
+                ids.add(part)
+            elif part and "@" in part and part not in ("<", ">"):
+                ids.add(part if part.startswith("<") else f"<{part}>")
+    return ids
+
+
+def find_message_ids_from_msg(msg: email.message.Message) -> set[str]:
+    mid = (msg.get("Message-ID") or "").strip()
+    refs = (msg.get("References") or "").strip()
+    in_reply = (msg.get("In-Reply-To") or "").strip()
+    ids = {mid} if mid else set()
+    ids |= parse_message_ids(refs, in_reply)
+    return ids
+
+
+def search_by_message_id(mail: imaplib.IMAP4, msg_id: str) -> list[str]:
+    """Return list of UIDs (as strings) for messages with given Message-ID, on or after MAIL_SINCE_DATE."""
+    if not msg_id:
+        return []
+    if not msg_id.startswith("<"):
+        msg_id = f"<{msg_id}>"
+    if not msg_id.endswith(">"):
+        msg_id = msg_id + ">"
+    since = imap_since_date()
+    criterion = f'(HEADER Message-ID "{msg_id}" SINCE {since})'
+    try:
+        _, data = mail.search(None, criterion)
+    except Exception:
+        return []
+    if not data or not data[0]:
+        return []
+    return [u.decode("ascii") for u in data[0].split() if u]
+
+
+def fetch_message_by_uid(
+    mail: imaplib.IMAP4, uid: str
+) -> email.message.Message | None:
+    """Fetch a single message by UID. Returns parsed email or None."""
+    try:
+        _, data = mail.fetch(uid.encode("ascii"), "(RFC822)")
+    except Exception:
+        return None
+    if not data or not data[0] or len(data[0]) < 2:
+        return None
+    raw = data[0][1]
+    if isinstance(raw, bytes):
+        return email.message_from_bytes(raw)
+    return None
+
+
+def format_message(uid: str, msg: email.message.Message) -> str:
+    mid = (msg.get("Message-ID") or "").strip()
+    from_ = decode_header_value(msg.get("From"))
+    to_ = decode_header_value(msg.get("To"))
+    subj = decode_header_value(msg.get("Subject"))
+    date_h = decode_header_value(msg.get("Date"))
+    body = get_text_body(msg)
+    lines = [
+        "--- MAIL",
+        f"UID={uid}",
+        "---",
+        "Message-ID: " + (mid or "(none)"),
+        "From: " + from_,
+        "To: " + (to_ or ""),
+        "Subject: " + subj,
+        "Date: " + (date_h or ""),
+        "Body:",
+        body or "(empty)",
+        "--- END MAIL ---",
+    ]
+    return "\n".join(lines)
+
+
+def main() -> int:
+    if len(sys.argv) < 2:
+        print("Usage: mail-get-thread.py <uid>", file=sys.stderr)
+        return 1
+    uid0 = sys.argv[1].strip()
+    if not uid0:
+        print("[gitea-issues] ERROR: UID required.", file=sys.stderr)
+        return 1
+
+    cfg = load_imap_config()
+    if not cfg["user"] or not cfg["password"]:
+        root = repo_root()
+        env_path = root / ".secrets" / "gitea-issues" / "imap-bridge.env"
+        print(
+            "[gitea-issues] ERROR: IMAP_USER and IMAP_PASSWORD required.",
+            file=sys.stderr,
+        )
+        print(f"[gitea-issues] Set env or create {env_path}", file=sys.stderr)
+        return 1
+
+    mail = imaplib.IMAP4(cfg["host"], int(cfg["port"]))
+    if cfg["use_starttls"]:
+        mail.starttls(imap_ssl_context(cfg.get("ssl_verify", True)))
+    mail.login(cfg["user"], cfg["password"])
+    mail.select("INBOX")
+
+    msg0 = fetch_message_by_uid(mail, uid0)
+    if not msg0:
+        print(f"[gitea-issues] No message found for UID={uid0}.", file=sys.stderr)
+        mail.logout()
+        return 1
+
+    to_fetch: set[str] = find_message_ids_from_msg(msg0)
+    seen_ids: set[str] = set()
+    uids_by_mid: dict[str, str] = {}
+
+    while to_fetch:
+        mid = to_fetch.pop()
+        if not mid or mid in seen_ids:
+            continue
+        seen_ids.add(mid)
+        uids = search_by_message_id(mail, mid)
+        if uids:
+            uids_by_mid[mid] = uids[0]
+            msg = fetch_message_by_uid(mail, uids[0])
+            if msg:
+                to_fetch |= find_message_ids_from_msg(msg)
+
+    mid0 = (msg0.get("Message-ID") or "").strip()
+    if mid0 and mid0 not in uids_by_mid:
+        uids_by_mid[mid0] = uid0
+
+    collected: list[tuple[str, str, email.message.Message]] = []
+    for _mid, uid in uids_by_mid.items():
+        msg = fetch_message_by_uid(mail, uid)
+        if not msg:
+            continue
+        date_h = (msg.get("Date") or "").strip()
+        collected.append((date_h, uid, msg))
+
+    if uid0 not in uids_by_mid.values():
+        date0 = (msg0.get("Date") or "").strip()
+        collected.append((date0, uid0, msg0))
+
+    collected.sort(key=lambda x: x[0])
+
+    for _date, uid, msg in collected:
+        print(format_message(uid, msg))
+
+    mail.logout()
+    return 0
+
+
+if __name__ == "__main__":
+    sys.exit(main())
diff --git a/gitea-issues/mail-get-thread.sh b/gitea-issues/mail-get-thread.sh
new file mode 100755
index 0000000..01a77eb
--- /dev/null
+++ b/gitea-issues/mail-get-thread.sh
@@ -0,0 +1,12 @@
+#!/usr/bin/env bash
+# Fetch full email thread for a given UID. Run from repo root.
+# Usage: ./gitea-issues/mail-get-thread.sh <uid>
+set -euo pipefail
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+export GITEA_ISSUES_DIR
+export REPO_ROOT="${GITEA_ISSUES_DIR}/.."
+if [ $# -lt 1 ]; then
+  echo "Usage: $0 <uid>" >&2
+  exit 1
+fi
+exec python3 "${GITEA_ISSUES_DIR}/mail-get-thread.py" "$1"
diff --git a/gitea-issues/mail-list-unread.py b/gitea-issues/mail-list-unread.py
new file mode 100755
index 0000000..958801d
--- /dev/null
+++ b/gitea-issues/mail-list-unread.py
@@ -0,0 +1,118 @@
+#!/usr/bin/env python3
+"""
+List unread emails via IMAP (e.g. Proton Mail Bridge). Read-only; does not mark as read.
+Only lists messages sent to the configured alias (MAIL_FILTER_TO, default ai.support.lecoffreio@4nkweb.com).
+Output is for the agent: each mail with UID, Message-ID, From, To, Subject, Date, body.
+Usage: ./gitea-issues/mail-list-unread.sh
+"""
+
+from __future__ import annotations
+
+import email
+import imaplib
+import sys
+from email.header import decode_header
+from pathlib import Path
+
+# Add gitea-issues to path for mail_common
+sys.path.insert(0, str(Path(__file__).resolve().parent))
+from mail_common import imap_search_criterion_unseen, load_imap_config, repo_root, imap_ssl_context
+
+
+def decode_header_value(header: str | None) -> str:
+    if not header:
+        return ""
+    from email.header import decode_header as dh
+    parts = dh(header)
+    result = []
+    for part, charset in parts:
+        if isinstance(part, bytes):
+            result.append(part.decode(charset or "utf-8", errors="replace"))
+        else:
+            result.append(part)
+    return "".join(result)
+
+
+def get_text_body(msg: email.message.Message) -> str:
+    if msg.is_multipart():
+        for part in msg.walk():
+            if part.get_content_type() == "text/plain":
+                payload = part.get_payload(decode=True)
+                if payload:
+                    return payload.decode(part.get_content_charset() or "utf-8", errors="replace")
+        return ""
+    payload = msg.get_payload(decode=True)
+    if not payload:
+        return ""
+    return payload.decode(msg.get_content_charset() or "utf-8", errors="replace")
+
+
+def is_sent_to_alias(msg: email.message.Message, filter_to: str) -> bool:
+    """True if any To/Delivered-To/X-Original-To/Cc header contains the filter address."""
+    if not filter_to:
+        return True
+    headers_to_check = ("To", "Delivered-To", "X-Original-To", "Cc", "Envelope-To")
+    for name in headers_to_check:
+        value = msg.get(name)
+        if value:
+            decoded = decode_header_value(value).lower()
+            if filter_to in decoded:
+                return True
+    return False
+
+
+def main() -> None:
+    cfg = load_imap_config()
+    if not cfg["user"] or not cfg["password"]:
+        root = repo_root()
+        env_path = root / ".secrets" / "gitea-issues" / "imap-bridge.env"
+        print("[gitea-issues] ERROR: IMAP_USER and IMAP_PASSWORD required.", file=sys.stderr)
+        print(f"[gitea-issues] Set env or create {env_path}", file=sys.stderr)
+        sys.exit(1)
+
+    mail = imaplib.IMAP4(cfg["host"], int(cfg["port"]))
+    if cfg["use_starttls"]:
+        mail.starttls(imap_ssl_context(cfg.get("ssl_verify", True)))
+    mail.login(cfg["user"], cfg["password"])
+    mail.select("INBOX")
+    criterion = imap_search_criterion_unseen()
+    _, nums = mail.search(None, criterion)
+    ids = nums[0].split()
+    if not ids:
+        print("[gitea-issues] No unread messages (IMAP UNSEEN, on or after MAIL_SINCE_DATE). For spooler criterion (from/to), use tickets-fetch-inbox.sh and list-pending-spooler.sh.")
+        mail.logout()
+        return
+
+    shown = 0
+    for uid in ids:
+        uid_s = uid.decode("ascii")
+        _, data = mail.fetch(uid, "(RFC822)")
+        if not data or not data[0]:
+            continue
+        msg = email.message_from_bytes(data[0][1])
+        if not is_sent_to_alias(msg, cfg.get("filter_to", "")):
+            continue
+        mid = msg.get("Message-ID", "").strip()
+        from_ = decode_header_value(msg.get("From"))
+        to_ = decode_header_value(msg.get("To"))
+        subj = decode_header_value(msg.get("Subject"))
+        date_h = decode_header_value(msg.get("Date"))
+        body = get_text_body(msg)
+        print("--- MAIL", f"UID={uid_s}", "---")
+        print("Message-ID:", mid or "(none)")
+        print("From:", from_)
+        print("To:", to_ or "")
+        print("Subject:", subj)
+        print("Date:", date_h or "")
+        print("Body:")
+        print(body or "(empty)")
+        print("--- END MAIL ---")
+        shown += 1
+
+    if shown == 0:
+        print("[gitea-issues] No unread messages sent to the configured alias (MAIL_FILTER_TO). For spooler (from/to in conf.json), use tickets-fetch-inbox.sh and list-pending-spooler.sh.")
+    mail.logout()
+
+
+if __name__ == "__main__":
+    main()
diff --git a/gitea-issues/mail-list-unread.sh b/gitea-issues/mail-list-unread.sh
new file mode 100755
index 0000000..d5e8163
--- /dev/null
+++ b/gitea-issues/mail-list-unread.sh
@@ -0,0 +1,8 @@
+#!/usr/bin/env bash
+# List unread emails (read-only). Run from repo root.
+set -euo pipefail
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+# REPO_ROOT = ia_dev so mail_common.repo_root() finds .secrets under ia_dev (independent of parent project)
+export GITEA_ISSUES_DIR
+export REPO_ROOT="${GITEA_ISSUES_DIR}/.."
+exec python3 "${GITEA_ISSUES_DIR}/mail-list-unread.py"
diff --git a/gitea-issues/mail-mark-read.py b/gitea-issues/mail-mark-read.py
new file mode 100755
index 0000000..6712751
--- /dev/null
+++ b/gitea-issues/mail-mark-read.py
@@ -0,0 +1,41 @@
+#!/usr/bin/env python3
+"""
+Mark one email as read by UID (e.g. after replying without creating an issue).
+Usage: ./gitea-issues/mail-mark-read.sh <uid>
+"""
+
+from __future__ import annotations
+
+import imaplib
+import sys
+from pathlib import Path
+
+sys.path.insert(0, str(Path(__file__).resolve().parent))
+from mail_common import load_imap_config, repo_root, imap_ssl_context
+
+
+def main() -> None:
+    if len(sys.argv) < 2:
+        print("[gitea-issues] Usage: mail-mark-read.sh <uid>", file=sys.stderr)
+        sys.exit(1)
+    uid = sys.argv[1].strip()
+
+    cfg = load_imap_config()
+    if not cfg["user"] or not cfg["password"]:
+        root = repo_root()
+        env_path = root / ".secrets" / "gitea-issues" / "imap-bridge.env"
+        print("[gitea-issues] ERROR: IMAP_USER and IMAP_PASSWORD required.", file=sys.stderr)
+        sys.exit(1)
+
+    mail = imaplib.IMAP4(cfg["host"], int(cfg["port"]))
+    if cfg["use_starttls"]:
+        mail.starttls(imap_ssl_context(cfg.get("ssl_verify", True)))
+    mail.login(cfg["user"], cfg["password"])
+    mail.select("INBOX")
+    mail.store(uid, "+FLAGS", "\\Seen")
+    mail.logout()
+    print("[gitea-issues] Marked as read.")
+
+
+if __name__ == "__main__":
+    main()
diff --git a/gitea-issues/mail-mark-read.sh b/gitea-issues/mail-mark-read.sh
new file mode 100755
index 0000000..b04369b
--- /dev/null
+++ b/gitea-issues/mail-mark-read.sh
@@ -0,0 +1,8 @@
+#!/usr/bin/env bash
+# Mark one email as read by UID. Run from repo root.
+# Usage: ./gitea-issues/mail-mark-read.sh <uid>
+set -euo pipefail
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+export GITEA_ISSUES_DIR
+export REPO_ROOT="${GITEA_ISSUES_DIR}/.."
+exec python3 "${GITEA_ISSUES_DIR}/mail-mark-read.py" "$@"
diff --git a/gitea-issues/mail-send-reply.py b/gitea-issues/mail-send-reply.py
new file mode 100755
index 0000000..a526742
--- /dev/null
+++ b/gitea-issues/mail-send-reply.py
@@ -0,0 +1,108 @@
+#!/usr/bin/env python3
+"""
+Send a reply email via SMTP (e.g. Proton Mail Bridge).
+Usage: ./gitea-issues/mail-send-reply.sh --to addr@example.com --subject "..." --body "..." [--in-reply-to "<msg-id>" [--references "<refs>"]]
+  Or:  echo "body" | ./gitea-issues/mail-send-reply.sh --to addr@example.com --subject "..." [--in-reply-to "<msg-id>"]
+"""
+
+from __future__ import annotations
+
+import argparse
+import os
+import smtplib
+import sys
+from email.mime.text import MIMEText
+from pathlib import Path
+
+sys.path.insert(0, str(Path(__file__).resolve().parent))
+from mail_common import load_smtp_config, repo_root, imap_ssl_context
+
+DEFAULT_SIGNATURE = """--
+Support IA du projet Lecoffre.io
+ai.support.lecoffreio@4nkweb.com"""
+
+# Patterns that indicate the body contains a citation of the received message (forbidden).
+CITATION_PATTERNS = (
+    "From:",
+    "Message-ID:",
+    "Message-ID :",
+    " wrote:",
+    " a écrit",
+)
+CITATION_LINE_START = (">",)  # Quoted line start
+
+
+def body_contains_citation(body: str) -> bool:
+    """Return True if body looks like it contains the received message (citation)."""
+    if not body or not body.strip():
+        return False
+    lines = body.strip().splitlines()
+    for line in lines:
+        stripped = line.strip()
+        if not stripped:
+            continue
+        for pat in CITATION_PATTERNS:
+            if pat in line:
+                return True
+        for start in CITATION_LINE_START:
+            if stripped.startswith(start):
+                return True
+    return False
+
+
+def get_reply_signature() -> str:
+    sig = os.environ.get("MAIL_REPLY_SIGNATURE", "").strip()
+    if sig:
+        return "\n\n" + sig.replace("\\n", "\n")
+    return "\n\n" + DEFAULT_SIGNATURE
+
+
+def main() -> None:
+    ap = argparse.ArgumentParser(description="Send reply email via Bridge SMTP")
+    ap.add_argument("--to", required=True, help="To address")
+    ap.add_argument("--subject", required=True, help="Subject")
+    ap.add_argument("--body", default="", help="Body (or use stdin)")
+    ap.add_argument("--in-reply-to", default="", help="Message-ID of the message we reply to")
+    ap.add_argument("--references", default="", help="References header for threading")
+    args = ap.parse_args()
+
+    cfg = load_smtp_config()
+    if not cfg["user"] or not cfg["password"]:
+        root = repo_root()
+        env_path = root / ".secrets" / "gitea-issues" / "imap-bridge.env"
+        print("[gitea-issues] ERROR: SMTP_USER and SMTP_PASSWORD required.", file=sys.stderr)
+        print(f"[gitea-issues] Set env or create {env_path}", file=sys.stderr)
+        sys.exit(1)
+
+    body = args.body
+    if not body and not sys.stdin.isatty():
+        body = sys.stdin.read()
+    body = body.rstrip()
+    if body_contains_citation(body):
+        print(
+            "[gitea-issues] ERROR: Body must not contain the received message (no citation, no From:, Message-ID, wrote:, etc.). Send only your reply text.",
+            file=sys.stderr,
+        )
+        sys.exit(1)
+    body = (body + get_reply_signature()).strip()
+
+    msg = MIMEText(body, "plain", "utf-8")
+    msg["Subject"] = args.subject
+    msg["From"] = cfg["user"]
+    msg["To"] = args.to
+    if args.in_reply_to:
+        msg["In-Reply-To"] = args.in_reply_to
+    if args.references:
+        msg["References"] = args.references
+
+    with smtplib.SMTP(cfg["host"], int(cfg["port"])) as smtp:
+        if cfg["use_starttls"]:
+            smtp.starttls(context=imap_ssl_context(cfg.get("ssl_verify", True)))
+        smtp.login(cfg["user"], cfg["password"])
+        smtp.sendmail(cfg["user"], [args.to], msg.as_string())
+
+    print("[gitea-issues] Reply sent.")
+
+
+if __name__ == "__main__":
+    main()
diff --git a/gitea-issues/mail-send-reply.sh b/gitea-issues/mail-send-reply.sh
new file mode 100755
index 0000000..35ae397
--- /dev/null
+++ b/gitea-issues/mail-send-reply.sh
@@ -0,0 +1,8 @@
+#!/usr/bin/env bash
+# Send reply email via Bridge SMTP. Run from repo root.
+# Usage: ./gitea-issues/mail-send-reply.sh --to addr --subject "..." [--body "..." | stdin] [--in-reply-to "<msg-id>" [--references "..." ]]
+set -euo pipefail
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+export GITEA_ISSUES_DIR
+export REPO_ROOT="${GITEA_ISSUES_DIR}/.."
+exec python3 "${GITEA_ISSUES_DIR}/mail-send-reply.py" "$@"
diff --git a/gitea-issues/mail-thread-log.py b/gitea-issues/mail-thread-log.py
new file mode 100644
index 0000000..e72475c
--- /dev/null
+++ b/gitea-issues/mail-thread-log.py
@@ -0,0 +1,333 @@
+#!/usr/bin/env python3
+"""
+Thread log: one file per email thread under projects/<id>/logs/gitea-issues/threads/.
+Content: exchanges (received + sent), tickets (issues), commits.
+Usage:
+  mail-thread-log.py get-id --uid <uid>       # print THREAD_ID=...
+  mail-thread-log.py init --uid <uid>         # create/update log from thread
+  mail-thread-log.py append-sent --thread-id <id> --to <addr> --subject "..." [--body "..."] [--date "..."]
+  mail-thread-log.py append-issue --thread-id <id> --issue <num> [--title "..."]
+  mail-thread-log.py append-commit --thread-id <id> --hash <hash> --message "..." [--branch "..."]
+"""
+
+from __future__ import annotations
+
+import argparse
+import re
+import subprocess
+import sys
+from datetime import datetime, timezone
+from pathlib import Path
+
+sys.path.insert(0, str(Path(__file__).resolve().parent))
+from mail_common import load_gitea_config, load_imap_config, repo_root
+from project_config import project_logs_dir
+
+
+def threads_dir() -> Path:
+    """Thread log directory: projects/<id>/logs/gitea-issues/threads/ or repo logs fallback."""
+    d = project_logs_dir() / "gitea-issues" / "threads"
+    d.mkdir(parents=True, exist_ok=True)
+    return d
+
+
+def sanitize_thread_id(raw: str, max_len: int = 80) -> str:
+    s = re.sub(r"[^a-zA-Z0-9._-]", "_", raw).strip("_")
+    return s[:max_len] if s else "thread_unknown"
+
+
+def get_thread_output(uid: str) -> str:
+    gitea_dir = Path(__file__).resolve().parent
+    root = gitea_dir.parent
+    env = {"GITEA_ISSUES_DIR": str(gitea_dir)}
+    result = subprocess.run(
+        [sys.executable, str(gitea_dir / "mail-get-thread.py"), uid],
+        cwd=str(root),
+        capture_output=True,
+        text=True,
+        env={**__import__("os").environ, **env},
+        timeout=60,
+    )
+    if result.returncode != 0:
+        raise RuntimeError(
+            f"mail-get-thread failed: {result.stderr or result.stdout or 'unknown'}"
+        )
+    return result.stdout
+
+
+def parse_thread_blocks(text: str) -> list[dict[str, str]]:
+    """Parse --- MAIL UID=... --- ... --- END MAIL --- blocks."""
+    blocks: list[dict[str, str]] = []
+    pattern = re.compile(
+        r"--- MAIL\s+UID=(\S+)\s+---\s*\n"
+        r"(?:Message-ID:\s*(.*?)\n)?"
+        r"From:\s*(.*?)\n"
+        r"To:\s*(.*?)\n"
+        r"Subject:\s*(.*?)\n"
+        r"Date:\s*(.*?)\n"
+        r"Body:\s*\n(.*?)--- END MAIL ---",
+        re.DOTALL,
+    )
+    for m in pattern.finditer(text):
+        blocks.append({
+            "uid": m.group(1).strip(),
+            "message_id": (m.group(2) or "").strip(),
+            "from": (m.group(3) or "").strip(),
+            "to": (m.group(4) or "").strip(),
+            "subject": (m.group(5) or "").strip(),
+            "date": (m.group(6) or "").strip(),
+            "body": (m.group(7) or "").strip(),
+        })
+    return blocks
+
+
+def get_thread_id_from_uid(uid: str) -> str:
+    out = get_thread_output(uid)
+    blocks = parse_thread_blocks(out)
+    if not blocks:
+        return sanitize_thread_id(f"thread_uid_{uid}")
+    first_msg_id = (blocks[0].get("message_id") or "").strip() or blocks[0].get("uid", "")
+    return sanitize_thread_id(first_msg_id)
+
+
+def format_exchange_received(block: dict[str, str]) -> str:
+    return (
+        f"### {block.get('date', '')} — Reçu\n"
+        f"- **De:** {block.get('from', '')}\n"
+        f"- **À:** {block.get('to', '')}\n"
+        f"- **Sujet:** {block.get('subject', '')}\n\n"
+        f"{block.get('body', '')}\n\n"
+    )
+
+
+def format_exchange_sent(block: dict[str, str]) -> str:
+    return (
+        f"### {block.get('date', '')} — Envoyé\n"
+        f"- **À:** {block.get('to', '')}\n"
+        f"- **Sujet:** {block.get('subject', '')}\n\n"
+        f"{block.get('body', '')}\n\n"
+    )
+
+
+def init_log(uid: str) -> str:
+    cfg = load_imap_config()
+    our_address = (cfg.get("filter_to") or "").strip().lower()
+    if not our_address:
+        our_address = (cfg.get("user") or "").strip().lower()
+
+    out = get_thread_output(uid)
+    blocks = parse_thread_blocks(out)
+    thread_id = get_thread_id_from_uid(uid)
+    log_path = threads_dir() / f"{thread_id}.md"
+
+    received_blocks: list[dict[str, str]] = []
+    sent_blocks: list[dict[str, str]] = []
+    for b in blocks:
+        from_ = (b.get("from") or "").lower()
+        if our_address and our_address in from_:
+            sent_blocks.append(b)
+        else:
+            received_blocks.append(b)
+
+    existing_tickets = ""
+    existing_commits = ""
+    if log_path.exists():
+        content = log_path.read_text(encoding="utf-8")
+        if "## Tickets (issues)" in content:
+            idx = content.index("## Tickets (issues)")
+            end = content.find("\n## ", idx + 1)
+            if end == -1:
+                end = len(content)
+            existing_tickets = content[idx:end].strip()
+        if "## Commits" in content:
+            idx = content.index("## Commits")
+            end = content.find("\n## ", idx + 1)
+            if end == -1:
+                end = len(content)
+            existing_commits = content[idx:end].strip()
+
+    lines = [
+        f"# Fil — {thread_id}",
+        "",
+        "## Échanges reçus",
+        "",
+    ]
+    for b in received_blocks:
+        lines.append(format_exchange_received(b))
+    lines.append("## Échanges envoyés")
+    lines.append("")
+    for b in sent_blocks:
+        lines.append(format_exchange_sent(b))
+    if existing_tickets:
+        lines.append(existing_tickets)
+        lines.append("")
+    else:
+        lines.append("## Tickets (issues)")
+        lines.append("")
+        lines.append("(aucun)")
+        lines.append("")
+    if existing_commits:
+        lines.append(existing_commits)
+        lines.append("")
+    else:
+        lines.append("## Commits")
+        lines.append("")
+        lines.append("(aucun)")
+        lines.append("")
+
+    log_path.write_text("\n".join(lines), encoding="utf-8")
+    return thread_id
+
+
+def append_sent(
+    thread_id: str,
+    to_addr: str,
+    subject: str,
+    body: str = "",
+    date_str: str | None = None,
+) -> None:
+    if not date_str:
+        date_str = datetime.now(timezone.utc).strftime("%a, %d %b %Y %H:%M:%S +0000")
+    log_path = threads_dir() / f"{sanitize_thread_id(thread_id)}.md"
+    block = {
+        "date": date_str,
+        "to": to_addr,
+        "subject": subject,
+        "body": body,
+    }
+    section = format_exchange_sent(block)
+    if not log_path.exists():
+        log_path.write_text(
+            f"# Fil — {thread_id}\n\n## Échanges reçus\n\n(aucun)\n\n"
+            "## Échanges envoyés\n\n" + section + "\n## Tickets (issues)\n\n(aucun)\n\n## Commits\n\n(aucun)\n",
+            encoding="utf-8",
+        )
+        return
+    content = log_path.read_text(encoding="utf-8")
+    insert_marker = "## Échanges envoyés"
+    idx = content.find(insert_marker)
+    if idx == -1:
+        content += "\n\n## Échanges envoyés\n\n" + section
+    else:
+        next_section = content.find("\n## ", idx + 1)
+        if next_section == -1:
+            content = content.rstrip() + "\n\n" + section
+        else:
+            content = (
+                content[:next_section].rstrip() + "\n\n" + section + content[next_section:]
+            )
+    log_path.write_text(content, encoding="utf-8")
+
+
+def append_issue(thread_id: str, issue_num: str, title: str = "") -> None:
+    gitea = load_gitea_config()
+    base = f"{gitea['api_url'].replace('/api/v1', '')}/{gitea['owner']}/{gitea['repo']}/issues/{issue_num}"
+    line = f"- #{issue_num}" + (f" — {title}" if title else "") + f" — <{base}>\n"
+    log_path = threads_dir() / f"{sanitize_thread_id(thread_id)}.md"
+    if not log_path.exists():
+        log_path.write_text(
+            f"# Fil — {thread_id}\n\n## Échanges reçus\n\n(aucun)\n\n"
+            "## Échanges envoyés\n\n(aucun)\n\n## Tickets (issues)\n\n" + line + "\n## Commits\n\n(aucun)\n",
+            encoding="utf-8",
+        )
+        return
+    content = log_path.read_text(encoding="utf-8")
+    marker = "## Tickets (issues)"
+    idx = content.find(marker)
+    if idx == -1:
+        content += "\n\n" + marker + "\n\n" + line
+    else:
+        end = idx + len(marker)
+        rest = content[end:]
+        if "(aucun)" in rest.split("\n## ")[0]:
+            content = content[:end] + "\n\n" + line + rest.replace("(aucun)\n", "", 1)
+        else:
+            content = content[:end] + "\n\n" + line + content[end:]
+    log_path.write_text(content, encoding="utf-8")
+
+
+def append_commit(
+    thread_id: str,
+    commit_hash: str,
+    message: str,
+    branch: str = "",
+) -> None:
+    line = f"- `{commit_hash[:12]}`"
+    if branch:
+        line += f" ({branch})"
+    line += f" — {message.strip()}\n"
+    log_path = threads_dir() / f"{sanitize_thread_id(thread_id)}.md"
+    if not log_path.exists():
+        log_path.write_text(
+            f"# Fil — {thread_id}\n\n## Échanges reçus\n\n(aucun)\n\n"
+            "## Échanges envoyés\n\n(aucun)\n\n## Tickets (issues)\n\n(aucun)\n\n## Commits\n\n" + line,
+            encoding="utf-8",
+        )
+        return
+    content = log_path.read_text(encoding="utf-8")
+    marker = "## Commits"
+    idx = content.find(marker)
+    if idx == -1:
+        content += "\n\n" + marker + "\n\n" + line
+    else:
+        end = idx + len(marker)
+        rest = content[end:]
+        if "(aucun)" in rest.split("\n## ")[0]:
+            content = content[:end] + "\n\n" + line + rest.replace("(aucun)\n", "", 1)
+        else:
+            content = content[:end] + "\n\n" + line + content[end:]
+    log_path.write_text(content, encoding="utf-8")
+
+
+def main() -> int:
+    ap = argparse.ArgumentParser(prog="mail-thread-log.py")
+    sub = ap.add_subparsers(dest="cmd", required=True)
+    p_get = sub.add_parser("get-id")
+    p_get.add_argument("--uid", required=True, help="Mail UID")
+    p_init = sub.add_parser("init")
+    p_init.add_argument("--uid", required=True, help="Mail UID")
+    p_sent = sub.add_parser("append-sent")
+    p_sent.add_argument("--thread-id", required=True)
+    p_sent.add_argument("--to", required=True, dest="to_addr")
+    p_sent.add_argument("--subject", required=True)
+    p_sent.add_argument("--body", default="")
+    p_sent.add_argument("--date", default=None)
+    p_issue = sub.add_parser("append-issue")
+    p_issue.add_argument("--thread-id", required=True)
+    p_issue.add_argument("--issue", required=True)
+    p_issue.add_argument("--title", default="")
+    p_commit = sub.add_parser("append-commit")
+    p_commit.add_argument("--thread-id", required=True)
+    p_commit.add_argument("--hash", required=True)
+    p_commit.add_argument("--message", required=True)
+    p_commit.add_argument("--branch", default="")
+
+    args = ap.parse_args()
+    if args.cmd == "get-id":
+        tid = get_thread_id_from_uid(args.uid)
+        print(f"THREAD_ID={tid}")
+        return 0
+    if args.cmd == "init":
+        tid = init_log(args.uid)
+        print(f"THREAD_ID={tid}")
+        return 0
+    if args.cmd == "append-sent":
+        append_sent(
+            args.thread_id,
+            args.to_addr,
+            args.subject,
+            args.body,
+            args.date,
+        )
+        return 0
+    if args.cmd == "append-issue":
+        append_issue(args.thread_id, args.issue, args.title)
+        return 0
+    if args.cmd == "append-commit":
+        append_commit(args.thread_id, args.hash, args.message, args.branch)
+        return 0
+    return 1
+
+
+if __name__ == "__main__":
+    sys.exit(main())
diff --git a/gitea-issues/mail-thread-log.sh b/gitea-issues/mail-thread-log.sh
new file mode 100755
index 0000000..49bceef
--- /dev/null
+++ b/gitea-issues/mail-thread-log.sh
@@ -0,0 +1,13 @@
+#!/usr/bin/env bash
+# Thread log: one file per thread under projects/<id>/logs/gitea-issues/threads/. Run from repo root.
+# Usage:
+#   ./gitea-issues/mail-thread-log.sh get-id --uid <uid>
+#   ./gitea-issues/mail-thread-log.sh init --uid <uid>
+#   ./gitea-issues/mail-thread-log.sh append-sent --thread-id <id> --to <addr> --subject "..." [--body "..."] [--date "..."]
+#   ./gitea-issues/mail-thread-log.sh append-issue --thread-id <id> --issue <num> [--title "..."]
+#   ./gitea-issues/mail-thread-log.sh append-commit --thread-id <id> --hash <hash> --message "..." [--branch "..."]
+set -euo pipefail
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+export GITEA_ISSUES_DIR
+export REPO_ROOT="${GITEA_ISSUES_DIR}/.."
+exec python3 "${GITEA_ISSUES_DIR}/mail-thread-log.py" "$@"
diff --git a/gitea-issues/mail-to-issue.py b/gitea-issues/mail-to-issue.py
new file mode 100755
index 0000000..0dfc1d6
--- /dev/null
+++ b/gitea-issues/mail-to-issue.py
@@ -0,0 +1,116 @@
+#!/usr/bin/env python3
+"""
+Create Gitea issues from unread emails via IMAP (e.g. Proton Mail Bridge).
+
+**Preferred flow (agent-driven):** do not chain directly. Use mail-list-unread.sh
+to list unread emails, then for each: formalize the issue or send a reply (mail-send-reply.sh);
+only when a correction/evolution is ready, create the issue (mail-create-issue-from-email.sh
+with optional formalized title/body), treat it (fix/evol), then comment on the issue and
+reply to the email via the Bridge.
+
+This script (mail-to-issue) is a **batch** fallback: it creates one issue per unread
+message with title=subject and body=text+From, then marks messages as read. Use only
+when the agent-driven flow is not used.
+
+Reads IMAP config from .secrets/gitea-issues/imap-bridge.env (or env vars).
+Reads Gitea token from GITEA_TOKEN or .secrets/gitea-issues/token.
+"""
+
+from __future__ import annotations
+
+import email
+import imaplib
+import ssl
+import sys
+from email.header import decode_header
+from pathlib import Path
+
+sys.path.insert(0, str(Path(__file__).resolve().parent))
+from mail_common import (
+    create_gitea_issue,
+    imap_search_criterion_unseen,
+    load_gitea_config,
+    load_imap_config,
+    repo_root,
+    sanitize_title,
+)
+
+
+def _decode_header_value(header: str | None) -> str:
+    if not header:
+        return ""
+    parts = decode_header(header)
+    result = []
+    for part, charset in parts:
+        if isinstance(part, bytes):
+            result.append(part.decode(charset or "utf-8", errors="replace"))
+        else:
+            result.append(part)
+    return "".join(result)
+
+
+def _get_text_body(msg: email.message.Message) -> str:
+    if msg.is_multipart():
+        for part in msg.walk():
+            if part.get_content_type() == "text/plain":
+                payload = part.get_payload(decode=True)
+                if payload:
+                    return payload.decode(part.get_content_charset() or "utf-8", errors="replace")
+        return ""
+    payload = msg.get_payload(decode=True)
+    if not payload:
+        return ""
+    return payload.decode(msg.get_content_charset() or "utf-8", errors="replace")
+
+
+def main() -> None:
+    imap_cfg = load_imap_config()
+    if not imap_cfg["user"] or not imap_cfg["password"]:
+        root = repo_root()
+        env_path = root / ".secrets" / "gitea-issues" / "imap-bridge.env"
+        print("[gitea-issues] ERROR: IMAP_USER and IMAP_PASSWORD required.", file=sys.stderr)
+        sys.exit(1)
+    gitea_cfg = load_gitea_config()
+    if not gitea_cfg["token"]:
+        print("[gitea-issues] ERROR: GITEA_TOKEN not set.", file=sys.stderr)
+        sys.exit(1)
+
+    mail = imaplib.IMAP4(imap_cfg["host"], int(imap_cfg["port"]))
+    if imap_cfg["use_starttls"]:
+        mail.starttls(ssl.create_default_context())
+    mail.login(imap_cfg["user"], imap_cfg["password"])
+    mail.select("INBOX")
+    criterion = imap_search_criterion_unseen()
+    _, nums = mail.search(None, criterion)
+    ids = nums[0].split()
+    if not ids:
+        print("[gitea-issues] No unread messages.")
+        mail.logout()
+        return
+
+    created = 0
+    for uid in ids:
+        uid_s = uid.decode("ascii")
+        _, data = mail.fetch(uid, "(RFC822)")
+        if not data or not data[0]:
+            continue
+        msg = email.message_from_bytes(data[0][1])
+        subject = _decode_header_value(msg.get("Subject"))
+        from_ = _decode_header_value(msg.get("From"))
+        body_text = _get_text_body(msg)
+        body_for_issue = f"**From:** {from_}\n\n{body_text}".strip()
+        title = sanitize_title(subject)
+        issue = create_gitea_issue(title, body_for_issue)
+        if issue:
+            created += 1
+            print(f"[gitea-issues] Created issue #{issue.get('number', '?')}: {title[:60]}")
+            mail.store(uid_s, "+FLAGS", "\\Seen")
+        else:
+            print(f"[gitea-issues] Skipped (API failed): {title[:60]}", file=sys.stderr)
+
+    mail.logout()
+    print(f"[gitea-issues] Done. Created {created} issue(s).")
+
+
+if __name__ == "__main__":
+    main()
diff --git a/gitea-issues/mail-to-issue.sh b/gitea-issues/mail-to-issue.sh
new file mode 100755
index 0000000..cd54049
--- /dev/null
+++ b/gitea-issues/mail-to-issue.sh
@@ -0,0 +1,12 @@
+#!/usr/bin/env bash
+#
+# Create Gitea issues from unread emails (IMAP). Requires Proton Mail Bridge
+# or any IMAP server. Config: .secrets/gitea-issues/imap-bridge.env and token.
+# Usage: ./gitea-issues/mail-to-issue.sh
+#
+set -euo pipefail
+
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+export GITEA_ISSUES_DIR
+export REPO_ROOT="${GITEA_ISSUES_DIR}/.."
+exec python3 "${GITEA_ISSUES_DIR}/mail-to-issue.py"
diff --git a/gitea-issues/mail_common.py b/gitea-issues/mail_common.py
new file mode 100644
index 0000000..d4fb3ee
--- /dev/null
+++ b/gitea-issues/mail_common.py
@@ -0,0 +1,144 @@
+# Shared config and helpers for gitea-issues mail scripts (IMAP/SMTP, Gitea).
+# Used by mail-list-unread, mail-send-reply, mail-create-issue-from-email, mail-mark-read.
+
+from __future__ import annotations
+
+import json
+import os
+import re
+import ssl
+from pathlib import Path
+from urllib.error import HTTPError, URLError
+from urllib.request import Request, urlopen
+
+# Only consider messages on or after this date (IMAP format DD-Mon-YYYY). Override with env MAIL_SINCE_DATE.
+MAIL_SINCE_DATE_DEFAULT = "10-Mar-2026"
+
+
+def imap_since_date() -> str:
+    """Return IMAP SINCE date (DD-Mon-YYYY). Messages before this date are ignored by fetch/list scripts."""
+    return os.environ.get("MAIL_SINCE_DATE", MAIL_SINCE_DATE_DEFAULT).strip() or MAIL_SINCE_DATE_DEFAULT
+
+
+def imap_search_criterion_all() -> str:
+    """IMAP search: all messages on or after MAIL_SINCE_DATE."""
+    return f"SINCE {imap_since_date()}"
+
+
+def imap_search_criterion_unseen() -> str:
+    """IMAP search: unread messages on or after MAIL_SINCE_DATE."""
+    return f"(UNSEEN SINCE {imap_since_date()})"
+
+
+def repo_root() -> Path:
+    # Root = directory containing gitea-issues (ia_dev). .secrets and logs live under ia_dev (./.secrets, ./logs)
+    # so they do not depend on the parent project; same ia_dev works for any project (../ai_project_id).
+    env_root = os.environ.get("REPO_ROOT")
+    if env_root:
+        return Path(env_root).resolve()
+    issues_dir = os.environ.get("GITEA_ISSUES_DIR")
+    if issues_dir:
+        return Path(issues_dir).resolve().parent
+    return Path(__file__).resolve().parent.parent
+
+
+def load_env_file(path: Path) -> None:
+    if not path.is_file():
+        return
+    with open(path, encoding="utf-8") as f:
+        for line in f:
+            line = line.strip()
+            if not line or line.startswith("#"):
+                continue
+            if "=" in line:
+                key, _, value = line.partition("=")
+                key = key.strip()
+                value = value.strip().strip("'\"")
+                if key and key not in os.environ:
+                    os.environ[key] = value
+
+
+def load_imap_config() -> dict[str, str]:
+    root = repo_root()
+    env_path = root / ".secrets" / "gitea-issues" / "imap-bridge.env"
+    load_env_file(env_path)
+    ssl_verify_raw = os.environ.get("IMAP_SSL_VERIFY", "true").lower()
+    ssl_verify = ssl_verify_raw not in ("0", "false", "no")
+    return {
+        "host": os.environ.get("IMAP_HOST", "127.0.0.1"),
+        "port": os.environ.get("IMAP_PORT", "1143"),
+        "user": os.environ.get("IMAP_USER", ""),
+        "password": os.environ.get("IMAP_PASSWORD", ""),
+        "use_starttls": os.environ.get("IMAP_USE_STARTTLS", "true").lower() in ("1", "true", "yes"),
+        "ssl_verify": ssl_verify,
+        "filter_to": os.environ.get("MAIL_FILTER_TO", "ai.support.lecoffreio@4nkweb.com").strip().lower(),
+    }
+
+
+def imap_ssl_context(ssl_verify: bool = True) -> ssl.SSLContext:
+    """Return SSL context for IMAP STARTTLS. Use ssl_verify=False only for local Bridge with self-signed cert."""
+    if ssl_verify:
+        return ssl.create_default_context()
+    ctx = ssl.create_default_context()
+    ctx.check_hostname = False
+    ctx.verify_mode = ssl.CERT_NONE
+    return ctx
+
+
+def load_smtp_config() -> dict[str, str]:
+    root = repo_root()
+    env_path = root / ".secrets" / "gitea-issues" / "imap-bridge.env"
+    load_env_file(env_path)
+    ssl_verify_raw = os.environ.get("IMAP_SSL_VERIFY", os.environ.get("SMTP_SSL_VERIFY", "true")).lower()
+    ssl_verify = ssl_verify_raw not in ("0", "false", "no")
+    return {
+        "host": os.environ.get("SMTP_HOST", os.environ.get("IMAP_HOST", "127.0.0.1")),
+        "port": os.environ.get("SMTP_PORT", "1025"),
+        "user": os.environ.get("SMTP_USER", os.environ.get("IMAP_USER", "")),
+        "password": os.environ.get("SMTP_PASSWORD", os.environ.get("IMAP_PASSWORD", "")),
+        "use_starttls": os.environ.get("SMTP_USE_STARTTLS", "true").lower() in ("1", "true", "yes"),
+        "ssl_verify": ssl_verify,
+    }
+
+
+def load_gitea_config() -> dict[str, str]:
+    root = repo_root()
+    token = os.environ.get("GITEA_TOKEN")
+    if not token:
+        token_path = root / ".secrets" / "gitea-issues" / "token"
+        if token_path.is_file():
+            token = token_path.read_text(encoding="utf-8").strip()
+    return {
+        "api_url": os.environ.get("GITEA_API_URL", "https://git.4nkweb.com/api/v1").rstrip("/"),
+        "owner": os.environ.get("GITEA_REPO_OWNER", "4nk"),
+        "repo": os.environ.get("GITEA_REPO_NAME", "lecoffre_ng"),
+        "token": token or "",
+    }
+
+
+def sanitize_title(raw: str, max_len: int = 200) -> str:
+    one_line = re.sub(r"\s+", " ", raw).strip()
+    return one_line[:max_len] if one_line else "(no subject)"
+
+
+def create_gitea_issue(title: str, body: str) -> dict | None:
+    gitea = load_gitea_config()
+    if not gitea["token"]:
+        return None
+    url = f"{gitea['api_url']}/repos/{gitea['owner']}/{gitea['repo']}/issues"
+    payload = json.dumps({"title": title, "body": body}).encode("utf-8")
+    req = Request(
+        url,
+        data=payload,
+        method="POST",
+        headers={
+            "Accept": "application/json",
+            "Content-Type": "application/json",
+            "Authorization": f"token {gitea['token']}",
+        },
+    )
+    try:
+        with urlopen(req, timeout=30) as resp:
+            return json.loads(resp.read().decode("utf-8"))
+    except (HTTPError, URLError):
+        return None
diff --git a/gitea-issues/print-issue-prompt.sh b/gitea-issues/print-issue-prompt.sh
new file mode 100755
index 0000000..3d30f91
--- /dev/null
+++ b/gitea-issues/print-issue-prompt.sh
@@ -0,0 +1,35 @@
+#!/usr/bin/env bash
+#
+# Print issue number, title and body in a single block for agent consumption.
+# Used by the gitea-issues-process agent to get the ticket content before calling /fix or /evol.
+# Usage: ./print-issue-prompt.sh <issue_number>
+#
+set -euo pipefail
+
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+# shellcheck source=lib.sh
+source "${GITEA_ISSUES_DIR}/lib.sh"
+
+require_jq || exit 1
+
+if [[ $# -lt 1 ]]; then
+	log_err "Usage: $0 <issue_number>"
+	exit 1
+fi
+
+ISSUE_NUM="$1"
+RESPONSE="$(gitea_api_get "/repos/${GITEA_REPO_OWNER}/${GITEA_REPO_NAME}/issues/${ISSUE_NUM}")"
+if ! echo "$RESPONSE" | jq -e . &>/dev/null; then
+	log_err "API error (issue ${ISSUE_NUM}): ${RESPONSE:0:200}"
+	exit 1
+fi
+
+TITLE="$(echo "$RESPONSE" | jq -r '.title')"
+BODY="$(echo "$RESPONSE" | jq -r '.body // "(no description)"')"
+LABELS="$(echo "$RESPONSE" | jq -r '[.labels[].name] | join(", ")')"
+
+echo "Issue #${ISSUE_NUM}"
+echo "Title: ${TITLE}"
+echo "Labels: ${LABELS}"
+echo ""
+echo "${BODY}"
diff --git a/gitea-issues/project_config.py b/gitea-issues/project_config.py
new file mode 100644
index 0000000..177dfd6
--- /dev/null
+++ b/gitea-issues/project_config.py
@@ -0,0 +1,174 @@
+# Load project config (projects/<id>/conf.json) for tickets spooler and authorized_emails.
+# Requires PROJECT_ROOT (repo root with ai_project_id) and GITEA_ISSUES_DIR (ia_dev/gitea-issues).
+
+from __future__ import annotations
+
+import json
+import os
+from pathlib import Path
+
+
+def project_root() -> Path:
+    """Project repo root (parent of ia_dev). Where data/issues/ and ai_project_id live."""
+    env_root = os.environ.get("PROJECT_ROOT")
+    if env_root:
+        return Path(env_root).resolve()
+    env_repo = os.environ.get("REPO_ROOT")
+    if env_repo:
+        root = Path(env_repo).resolve()
+        # If REPO_ROOT is ia_dev, project root is parent
+        if (root / "gitea-issues").is_dir():
+            return root.parent
+        return root
+    issues_dir = os.environ.get("GITEA_ISSUES_DIR")
+    if issues_dir:
+        return Path(issues_dir).resolve().parent.parent
+    return Path(__file__).resolve().parent.parent.parent
+
+
+def ia_dev_root() -> Path:
+    """Directory containing gitea-issues (ia_dev)."""
+    issues_dir = os.environ.get("GITEA_ISSUES_DIR")
+    if issues_dir:
+        return Path(issues_dir).resolve().parent
+    return Path(__file__).resolve().parent.parent
+
+
+def load_project_config() -> dict | None:
+    """Load projects/<slug>/conf.json. Returns None if not found or slug missing."""
+    root = project_root()
+    ia_dev = ia_dev_root()
+    slug_path = root / "ai_project_id"
+    if not slug_path.is_file():
+        slug_path = root / ".ia_project"
+    slug = os.environ.get("IA_PROJECT", "").strip() if os.environ.get("IA_PROJECT") else None
+    if not slug and slug_path.is_file():
+        slug = slug_path.read_text(encoding="utf-8").strip()
+    if not slug:
+        return None
+    conf_path = ia_dev / "projects" / slug / "conf.json"
+    if not conf_path.is_file():
+        return None
+    with open(conf_path, encoding="utf-8") as f:
+        return json.load(f)
+
+
+def project_dir() -> Path | None:
+    """Path to projects/<id>/ (under ia_dev). None if project config not found."""
+    root = project_root()
+    ia_dev = ia_dev_root()
+    slug = os.environ.get("IA_PROJECT", "").strip()
+    if not slug and (root / "ai_project_id").is_file():
+        slug = (root / "ai_project_id").read_text(encoding="utf-8").strip()
+    if not slug and (root / ".ia_project").is_file():
+        slug = (root / ".ia_project").read_text(encoding="utf-8").strip()
+    if not slug:
+        return None
+    return ia_dev / "projects" / slug
+
+
+def data_issues_dir() -> Path:
+    """Path to data/issues/ spooler under projects/<id>/ (ia_dev/projects/<id>/data/issues)."""
+    pd = project_dir()
+    if pd is not None:
+        return pd / "data" / "issues"
+    return project_root() / "data" / "issues"
+
+
+def data_issues_dir_for_project(project_id: str) -> Path:
+    """Path to data/issues/ for a given project id (ia_dev/projects/<id>/data/issues)."""
+    ia_dev = ia_dev_root()
+    return ia_dev / "projects" / project_id / "data" / "issues"
+
+
+def project_logs_dir() -> Path:
+    """Path to logs/ under projects/<id>/ (ia_dev/projects/<id>/logs)."""
+    pd = project_dir()
+    if pd is not None:
+        return pd / "logs"
+    return project_root() / "logs"
+
+
+def authorized_emails() -> dict[str, str | list[str]]:
+    """Return tickets.authorized_emails (to, from list). Empty dict if missing."""
+    conf = load_project_config()
+    if not conf:
+        return {}
+    tickets = conf.get("tickets") or {}
+    return tickets.get("authorized_emails") or {}
+
+
+def list_project_ids() -> list[str]:
+    """List all project ids (directory names under projects/)."""
+    ia_dev = ia_dev_root()
+    projects_dir = ia_dev / "projects"
+    if not projects_dir.is_dir():
+        return []
+    return [d.name for d in projects_dir.iterdir() if d.is_dir() and (d / "conf.json").is_file()]
+
+
+def resolve_project_id_by_email_to(to_address: str) -> str | None:
+    """Find project id whose tickets.authorized_emails.to matches the given address (case-insensitive)."""
+    if not to_address or not to_address.strip():
+        return None
+    to_normalized = to_address.strip().lower()
+    for pid in list_project_ids():
+        conf_path = ia_dev_root() / "projects" / pid / "conf.json"
+        try:
+            with open(conf_path, encoding="utf-8") as f:
+                conf = json.load(f)
+        except (OSError, json.JSONDecodeError):
+            continue
+        tickets = conf.get("tickets") or {}
+        auth = tickets.get("authorized_emails") or {}
+        conf_to = (auth.get("to") or "").strip().lower()
+        if conf_to == to_normalized:
+            return pid
+    return None
+
+
+def _list_project_envs(project_id: str) -> list[str]:
+    """List env names (subdirs of .secrets) for a project that contain ia_token."""
+    ia_dev = ia_dev_root()
+    secrets_dir = ia_dev / "projects" / project_id / ".secrets"
+    if not secrets_dir.is_dir():
+        return []
+    return [
+        d.name
+        for d in secrets_dir.iterdir()
+        if d.is_dir() and (d / "ia_token").is_file()
+    ]
+
+
+def resolve_project_and_env_by_token(token: str) -> tuple[str, str] | None:
+    """Find (project_id, env) by scanning projects/<id>/.secrets/<env>/ia_token. Returns first match."""
+    if not token or not token.strip():
+        return None
+    token_stripped = token.strip()
+    for pid in list_project_ids():
+        for env in _list_project_envs(pid):
+            token_path = ia_dev_root() / "projects" / pid / ".secrets" / env / "ia_token"
+            try:
+                content = token_path.read_text(encoding="utf-8").strip()
+                # Token is either full value in file or base + env (e.g. nicolecoffreio<env>)
+                if content == token_stripped or (content + env) == token_stripped:
+                    return (pid, env)
+            except (OSError, UnicodeDecodeError):
+                continue
+    return None
+
+
+def resolve_project_id_by_token(token: str) -> str | None:
+    """Find project id whose .secrets/<env>/ia_token matches the given token."""
+    resolved = resolve_project_and_env_by_token(token)
+    return resolved[0] if resolved else None
+
+
+def load_project_config_by_id(project_id: str) -> dict | None:
+    """Load conf.json for a given project id. Returns None if not found."""
+    ia_dev = ia_dev_root()
+    conf_path = ia_dev / "projects" / project_id / "conf.json"
+    if not conf_path.is_file():
+        return None
+    with open(conf_path, encoding="utf-8") as f:
+        return json.load(f)
diff --git a/gitea-issues/tickets-fetch-inbox.py b/gitea-issues/tickets-fetch-inbox.py
new file mode 100644
index 0000000..dccf353
--- /dev/null
+++ b/gitea-issues/tickets-fetch-inbox.py
@@ -0,0 +1,321 @@
+#!/usr/bin/env python3
+"""
+Fetch inbox emails and route each message to the project whose tickets.authorized_emails.to matches the message To.
+
+Project is resolved per message: To/Delivered-To/X-Original-To are compared to tickets.authorized_emails.to in each
+projects/<id>/conf.json; the first matching project id is used. Only messages from authorized_emails.from are kept.
+Messages on or after MAIL_SINCE_DATE are considered. Does not use UNSEEN; does not mark as read (BODY.PEEK[]).
+Writes to projects/<id>/data/issues/ as JSON <date>.<msg_id>.<from>.pending. One file per message.
+
+State: we skip creating .pending if .pending exists or .response exists for that base.
+Usage: run with GITEA_ISSUES_DIR set (e.g. via tickets-fetch-inbox.sh). MAIL_SINCE_DATE overrides date (DD-Mon-YYYY).
+"""
+
+from __future__ import annotations
+
+import email
+import hashlib
+import imaplib
+import json
+import os
+import re
+import sys
+from datetime import datetime, timezone
+from email.header import decode_header
+from email.utils import parsedate_to_datetime
+from pathlib import Path
+
+sys.path.insert(0, str(Path(__file__).resolve().parent))
+from mail_common import imap_search_criterion_all, load_imap_config, imap_ssl_context
+from project_config import (
+    data_issues_dir_for_project,
+    ia_dev_root,
+    load_project_config_by_id,
+    project_root,
+    resolve_project_id_by_email_to,
+)
+
+
+def decode_header_value(header: str | None) -> str:
+    if not header:
+        return ""
+    parts = decode_header(header)
+    result = []
+    for part, charset in parts:
+        if isinstance(part, bytes):
+            result.append(part.decode(charset or "utf-8", errors="replace"))
+        else:
+            result.append(part)
+    return "".join(result)
+
+
+def parse_from_address(from_header: str) -> str:
+    """Extract email address from From header (e.g. 'Name <user@host>' -> user@host)."""
+    if not from_header:
+        return ""
+    match = re.search(r"<([^>]+)>", from_header)
+    if match:
+        return match.group(1).strip().lower()
+    return from_header.strip().lower()
+
+
+def get_text_body(msg: email.message.Message) -> str:
+    if msg.is_multipart():
+        for part in msg.walk():
+            if part.get_content_type() == "text/plain":
+                payload = part.get_payload(decode=True)
+                if payload:
+                    return payload.decode(
+                        part.get_content_charset() or "utf-8", errors="replace"
+                    )
+        return ""
+    payload = msg.get_payload(decode=True)
+    if not payload:
+        return ""
+    return payload.decode(
+        msg.get_content_charset() or "utf-8", errors="replace"
+    )
+
+
+def _extract_addresses(header_value: str) -> set[str]:
+    """Extract email addresses from a header value (e.g. 'Name <user@host>, other@host')."""
+    if not header_value or not header_value.strip():
+        return set()
+    decoded = decode_header_value(header_value).strip()
+    # Angle-bracket: <...@...>
+    in_angle = re.findall(r"<([^>]+)>", decoded)
+    # Standalone addr-spec (simplified: local@domain)
+    plain = re.findall(r"[a-zA-Z0-9_.+-]+@[a-zA-Z0-9][a-zA-Z0-9.-]*[a-zA-Z0-9]", decoded)
+    out: set[str] = set()
+    for a in in_angle:
+        out.add(a.strip().lower())
+    for a in plain:
+        out.add(a.strip().lower())
+    return out
+
+
+def get_message_to_addresses(msg: email.message.Message) -> list[str]:
+    """Return ordered list of recipient addresses (To, Delivered-To, X-Original-To, etc.) for project resolution."""
+    order = ("To", "Delivered-To", "X-Original-To", "X-Delivered-To", "X-Envelope-To", "Envelope-To")
+    seen: set[str] = set()
+    result: list[str] = []
+    for name in order:
+        value = msg.get(name)
+        if not value:
+            continue
+        addrs = _extract_addresses(decode_header_value(value))
+        for a in addrs:
+            if a not in seen:
+                seen.add(a)
+                result.append(a)
+    return result
+
+
+def sanitize_from_for_filename(email_addr: str) -> str:
+    """Filesystem-safe string from email (e.g. user@example.com -> user_example.com)."""
+    return re.sub(r"[^a-zA-Z0-9._-]", "_", email_addr.replace("@", "_"))
+
+
+def generate_message_id(mid: str | None, uid_s: str, date_str: str, from_addr: str) -> str:
+    """Deterministic 8-char id so the same message always gets the same base filename."""
+    raw = mid or f"{uid_s}_{date_str}_{from_addr}"
+    return hashlib.sha256(raw.encode("utf-8")).hexdigest()[:8]
+
+
+def sanitize_attachment_filename(name: str) -> str:
+    """Safe filename for attachment (no path, no dangerous chars)."""
+    if not name or not name.strip():
+        return "attachment"
+    base = Path(name).name
+    return re.sub(r"[^a-zA-Z0-9._-]", "_", base)[:200] or "attachment"
+
+
+def get_attachments(msg: email.message.Message) -> list[tuple[str, bytes, str]]:
+    """Return list of (filename, payload_bytes, content_type) for each attachment."""
+    result: list[tuple[str, bytes, str]] = []
+    for part in msg.walk():
+        content_type = (part.get_content_type() or "").lower()
+        if content_type.startswith("multipart/"):
+            continue
+        filename = part.get_filename()
+        if not filename:
+            # Optional: treat inline images etc. with Content-Disposition attachment
+            disp = part.get("Content-Disposition") or ""
+            if "attachment" in disp.lower():
+                ext = ""
+                if "image" in content_type:
+                    ext = ".bin" if "octet-stream" in content_type else ".img"
+                filename = f"attachment{ext}"
+            else:
+                continue
+        filename = decode_header_value(filename).strip()
+        if not filename:
+            continue
+        payload = part.get_payload(decode=True)
+        if payload is None:
+            continue
+        result.append((filename, payload, content_type))
+    return result
+
+
+def parse_references(refs: str | None) -> list[str]:
+    if not refs:
+        return []
+    return [x.strip() for x in re.split(r"\s+", refs) if x.strip()]
+
+
+def main() -> int:
+    cfg = load_imap_config()
+    if not cfg["user"] or not cfg["password"]:
+        print("[tickets-fetch-inbox] IMAP_USER and IMAP_PASSWORD required.", file=sys.stderr)
+        return 1
+
+    # Spool is per-project; each message is routed by its To address to projects/<id>/data/issues/
+    print("[tickets-fetch-inbox] Project resolved per message from To/Delivered-To/X-Original-To (tickets.authorized_emails.to).")
+
+    mail = imaplib.IMAP4(cfg["host"], int(cfg["port"]))
+    if cfg["use_starttls"]:
+        mail.starttls(imap_ssl_context(cfg.get("ssl_verify", True)))
+    mail.login(cfg["user"], cfg["password"])
+    mail.select("INBOX")
+    # Do not use UNSEEN; fetch messages on or after MAIL_SINCE_DATE (default 10-Mar-2026). Filter by authorized senders only.
+    # Use BODY.PEEK[] instead of RFC822 so the server does not set \Seen (emails stay "unread").
+    since_criterion = imap_search_criterion_all()
+    _, nums = mail.search(None, since_criterion)
+    ids = nums[0].split()
+    written = 0
+    skipped_fetch = 0
+    skipped_no_project = 0
+    skipped_from = 0
+    skipped_pending = 0
+    skipped_response = 0
+    for uid in ids:
+        uid_s = uid.decode("ascii")
+        _, data = mail.fetch(uid, "(BODY.PEEK[])")
+        if not data or not data[0]:
+            skipped_fetch += 1
+            continue
+        raw = data[0]
+        raw_bytes = None
+        if isinstance(raw, tuple):
+            if len(raw) >= 2 and isinstance(raw[1], bytes):
+                raw_bytes = raw[1]
+            elif len(raw) >= 2 and isinstance(raw[1], str):
+                raw_bytes = raw[1].encode("utf-8", errors="replace")
+        elif isinstance(raw, bytes):
+            raw_bytes = raw
+        if not raw_bytes:
+            skipped_fetch += 1
+            continue
+        try:
+            msg = email.message_from_bytes(raw_bytes)
+        except Exception:
+            skipped_fetch += 1
+            continue
+        to_addresses = get_message_to_addresses(msg)
+        project_id: str | None = None
+        for addr in to_addresses:
+            project_id = resolve_project_id_by_email_to(addr)
+            if project_id:
+                break
+        if not project_id:
+            skipped_no_project += 1
+            continue
+        conf = load_project_config_by_id(project_id)
+        if not conf:
+            skipped_no_project += 1
+            continue
+        auth = (conf.get("tickets") or {}).get("authorized_emails") or {}
+        from_list = auth.get("from")
+        if isinstance(from_list, list):
+            allowed_from = {str(a).strip().lower() for a in from_list if a}
+        elif isinstance(from_list, str):
+            allowed_from = {a.strip().lower() for a in re.split(r"[,;]", from_list) if a.strip()}
+        else:
+            allowed_from = set()
+        from_raw = decode_header_value(msg.get("From"))
+        from_addr = parse_from_address(from_raw)
+        if from_addr not in allowed_from:
+            skipped_from += 1
+            continue
+        spool = data_issues_dir_for_project(project_id)
+        spool.mkdir(parents=True, exist_ok=True)
+        mid = (msg.get("Message-ID") or "").strip()
+        to_raw = decode_header_value(msg.get("To"))
+        to_addrs = [a.strip() for a in re.split(r"[,;]", to_raw) if a.strip()]
+        subj = decode_header_value(msg.get("Subject"))
+        date_h = decode_header_value(msg.get("Date"))
+        refs = parse_references(msg.get("References"))
+        in_reply_to = (msg.get("In-Reply-To") or "").strip() or None
+        body = get_text_body(msg)
+        try:
+            if date_h:
+                dt = parsedate_to_datetime(date_h)
+                date_str = dt.strftime("%Y-%m-%dT%H%M%S")
+            else:
+                date_str = datetime.now(timezone.utc).strftime("%Y-%m-%dT%H%M%S")
+        except Exception:
+            date_str = datetime.now(timezone.utc).strftime("%Y-%m-%dT%H%M%S")
+        from_safe = sanitize_from_for_filename(from_addr)
+        msg_id_short = generate_message_id(mid, uid_s, date_str, from_addr)
+        base = f"{date_str}.{msg_id_short}.{from_safe}"
+        path = spool / f"{base}.pending"
+        if path.exists():
+            skipped_pending += 1
+            continue
+        # Already treated: .response exists (we don't keep .pending after replying).
+        if (spool / f"{base}.response").exists():
+            skipped_response += 1
+            continue
+        created_at = datetime.now(timezone.utc).strftime("%Y-%m-%dT%H:%M:%SZ")
+        attachments_meta: list[dict[str, str | int]] = []
+        attachment_parts = get_attachments(msg)
+        if attachment_parts:
+            att_dir = spool / f"{base}.d"
+            att_dir.mkdir(parents=True, exist_ok=True)
+            for idx, (orig_name, payload_bytes, content_type) in enumerate(attachment_parts):
+                safe_name = sanitize_attachment_filename(orig_name)
+                stored_name = f"{idx}_{safe_name}"
+                stored_path = att_dir / stored_name
+                stored_path.write_bytes(payload_bytes)
+                rel_path = f"{base}.d/{stored_name}"
+                attachments_meta.append({
+                    "filename": orig_name,
+                    "path": rel_path,
+                    "content_type": content_type,
+                    "size": len(payload_bytes),
+                })
+        payload = {
+            "version": 1,
+            "type": "incoming",
+            "id": msg_id_short,
+            "message_id": mid or "",
+            "from": from_addr,
+            "to": to_addrs,
+            "subject": subj,
+            "date": date_h or "",
+            "body": body or "",
+            "references": refs,
+            "in_reply_to": in_reply_to,
+            "uid": uid_s,
+            "created_at": created_at,
+            "issue_number": None,
+            "status": "pending",
+            "attachments": attachments_meta,
+        }
+        path.write_text(json.dumps(payload, ensure_ascii=False, indent=2), encoding="utf-8")
+        written += 1
+        print(f"[tickets-fetch-inbox] Wrote {path.name}")
+
+    mail.logout()
+    print(f"[tickets-fetch-inbox] Done. Wrote {written} new message(s).")
+    if skipped_fetch or skipped_no_project or skipped_from or skipped_pending or skipped_response:
+        print(
+            f"[tickets-fetch-inbox] Skipped: fetch/parse={skipped_fetch}, no_project_for_to={skipped_no_project}, "
+            f"from_not_allowed={skipped_from}, pending_exists={skipped_pending}, response_exists={skipped_response}."
+        )
+    return 0
+
+
+if __name__ == "__main__":
+    sys.exit(main())
diff --git a/gitea-issues/tickets-fetch-inbox.sh b/gitea-issues/tickets-fetch-inbox.sh
new file mode 100755
index 0000000..67b06a6
--- /dev/null
+++ b/gitea-issues/tickets-fetch-inbox.sh
@@ -0,0 +1,17 @@
+#!/usr/bin/env bash
+# Fetch inbox messages filtered by tickets.authorized_emails (conf.json). No UNSEEN; no mark read.
+# Writes new messages to projects/<id>/data/issues/ as JSON (<date>.<id>.<from>.pending).
+# Usage: cd <racine_projet> && ./ia_dev/gitea-issues/tickets-fetch-inbox.sh
+set -euo pipefail
+
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+export GITEA_ISSUES_DIR
+# Use same project root and env as list-pending-spooler (lib.sh) so spool path is identical.
+ROOT="$(cd "${GITEA_ISSUES_DIR}/../.." && pwd)"
+export REPO_ROOT="${GITEA_ISSUES_DIR}/.."
+cd "$ROOT"
+# shellcheck source=lib.sh
+source "${GITEA_ISSUES_DIR}/lib.sh" 2>/dev/null || true
+export PROJECT_ROOT="${PROJECT_ROOT:-$ROOT}"
+cd "$PROJECT_ROOT"
+exec python3 "${GITEA_ISSUES_DIR}/tickets-fetch-inbox.py" "$@"
diff --git a/gitea-issues/wiki-api-test.sh b/gitea-issues/wiki-api-test.sh
new file mode 100755
index 0000000..c3ea78b
--- /dev/null
+++ b/gitea-issues/wiki-api-test.sh
@@ -0,0 +1,88 @@
+#!/usr/bin/env bash
+#
+# Test Gitea Wiki API for repo 4nk/lecoffre_ng.
+# Requires GITEA_TOKEN or .secrets/gitea-issues/token (same as issues scripts).
+# Usage: ./wiki-api-test.sh [--create]
+#   --create: create a test page then delete it (checks write access).
+#
+set -euo pipefail
+
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+# shellcheck source=lib.sh
+source "${GITEA_ISSUES_DIR}/lib.sh"
+
+REPO_PATH="/repos/${GITEA_REPO_OWNER}/${GITEA_REPO_NAME}"
+# Branch ref for wiki (default branch of wiki repo; use master when wiki is configured on master)
+GITEA_WIKI_REF="${GITEA_WIKI_REF:-master}"
+WIKI_PAGES="${REPO_PATH}/wiki/pages?ref=${GITEA_WIKI_REF}"
+WIKI_PAGE="${REPO_PATH}/wiki/page"
+WIKI_NEW="${REPO_PATH}/wiki/new"
+
+do_create=false
+while [[ $# -gt 0 ]]; do
+	case "$1" in
+		--create) do_create=true; shift ;;
+		*) log_err "Unknown option: $1"; exit 1 ;;
+	esac
+done
+
+if ! load_gitea_token 2>/dev/null; then
+	log_err "No GITEA_TOKEN and no .secrets/gitea-issues/token. Set token to run wiki API tests."
+	exit 1
+fi
+
+require_jq || exit 1
+
+echo "=== 1. GET ${WIKI_PAGES} (list wiki pages) ==="
+RESPONSE="$(gitea_api_get "${WIKI_PAGES}")"
+if echo "$RESPONSE" | jq -e . &>/dev/null; then
+	if echo "$RESPONSE" | jq -e 'type == "array"' &>/dev/null; then
+		COUNT="$(echo "$RESPONSE" | jq 'length')"
+		log_info "List OK: ${COUNT} page(s)"
+		echo "$RESPONSE" | jq -r '.[] | "  - \(.title)"' 2>/dev/null || echo "$RESPONSE" | jq .
+	else
+		log_info "Response: $(echo "$RESPONSE" | jq -c . 2>/dev/null || echo "$RESPONSE")"
+	fi
+else
+	log_err "Response (first 300 chars): ${RESPONSE:0:300}"
+fi
+
+echo ""
+echo "=== 2. GET ${WIKI_PAGE}/Home (get one page, ref=${GITEA_WIKI_REF}) ==="
+RESPONSE="$(gitea_api_get "${WIKI_PAGE}/Home?ref=${GITEA_WIKI_REF}")"
+if echo "$RESPONSE" | jq -e .title &>/dev/null; then
+	log_info "Page OK: title=$(echo "$RESPONSE" | jq -r .title)"
+	echo "$RESPONSE" | jq '{ title, html_url, commit_count }'
+else
+	log_info "Response: $(echo "$RESPONSE" | jq -c . 2>/dev/null || echo "${RESPONSE:0:200}")"
+fi
+
+if [[ "$do_create" != true ]]; then
+	log_info "Done. Use --create to test POST wiki page and DELETE."
+	exit 0
+fi
+
+echo ""
+echo "=== 3. POST ${WIKI_NEW} (create test page) ==="
+TEST_TITLE="Api-test-$(date +%s)"
+CONTENT="# Test\nCreated by wiki-api-test.sh. Safe to delete."
+CONTENT_B64="$(echo -n "$CONTENT" | base64 -w 0)"
+BODY="$(jq -n --arg title "$TEST_TITLE" --arg content "$CONTENT_B64" --arg msg "wiki-api-test.sh" \
+	'{ title: $title, content_base64: $content, message: $msg }')"
+RESPONSE="$(gitea_api_post "${WIKI_NEW}" "$BODY")"
+if echo "$RESPONSE" | jq -e .title &>/dev/null; then
+	log_info "Create OK: $(echo "$RESPONSE" | jq -r .title)"
+	CREATED_TITLE="$TEST_TITLE"
+else
+	log_err "Create failed: ${RESPONSE:0:300}"
+	exit 1
+fi
+
+echo ""
+echo "=== 4. DELETE ${WIKI_PAGE}/${CREATED_TITLE} (remove test page) ==="
+RESPONSE="$(gitea_api_delete "${WIKI_PAGE}/${CREATED_TITLE}")"
+# DELETE often returns 204 No Content
+log_info "Delete sent (204 or empty body = success)."
+
+echo ""
+log_info "All wiki API tests completed."
diff --git a/gitea-issues/wiki-get-page.sh b/gitea-issues/wiki-get-page.sh
new file mode 100755
index 0000000..1136aaf
--- /dev/null
+++ b/gitea-issues/wiki-get-page.sh
@@ -0,0 +1,34 @@
+#!/usr/bin/env bash
+#
+# Output the raw markdown of a wiki page (for agents or scripts).
+# Usage: ./wiki-get-page.sh <page_name>
+# Example: ./wiki-get-page.sh Home
+# Requires GITEA_TOKEN or .secrets/gitea-issues/token.
+#
+set -euo pipefail
+
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+# shellcheck source=lib.sh
+source "${GITEA_ISSUES_DIR}/lib.sh"
+
+REPO_PATH="/repos/${GITEA_REPO_OWNER}/${GITEA_REPO_NAME}"
+GITEA_WIKI_REF="${GITEA_WIKI_REF:-master}"
+
+if [[ $# -lt 1 ]]; then
+	log_err "Usage: $0 <page_name>"
+	exit 1
+fi
+
+PAGE_NAME="$1"
+load_gitea_token || exit 1
+require_jq || exit 1
+
+resp="$(gitea_api_get "${REPO_PATH}/wiki/page/${PAGE_NAME}?ref=${GITEA_WIKI_REF}")"
+if ! echo "$resp" | jq -e .content_base64 &>/dev/null; then
+	log_err "Page not found or error: ${PAGE_NAME}"
+	echo "$resp" | jq . 2>/dev/null || echo "$resp"
+	exit 1
+fi
+
+echo "$resp" | jq -r '.content_base64' | base64 -d
+echo
diff --git a/gitea-issues/wiki-migrate-docs.sh b/gitea-issues/wiki-migrate-docs.sh
new file mode 100755
index 0000000..b78e16e
--- /dev/null
+++ b/gitea-issues/wiki-migrate-docs.sh
@@ -0,0 +1,100 @@
+#!/usr/bin/env bash
+#
+# Migrate all docs/*.md (repo root) to Gitea wiki as pages.
+# Mapping: docs/FILE.md → page "File" (stem with _ → -, first letter upper per segment).
+# Requires GITEA_TOKEN or .secrets/gitea-issues/token.
+# Usage: ./wiki-migrate-docs.sh [--dry-run] [file.md ...]
+#   --dry-run: print mapping and skip API calls.
+#   If file(s) given: migrate only those; else migrate all docs/*.md.
+#
+set -euo pipefail
+
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+REPO_ROOT="${GITEA_ISSUES_DIR}/.."
+DOCS_DIR="${REPO_ROOT}/docs"
+# shellcheck source=lib.sh
+source "${GITEA_ISSUES_DIR}/lib.sh"
+
+REPO_PATH="/repos/${GITEA_REPO_OWNER}/${GITEA_REPO_NAME}"
+GITEA_WIKI_REF="${GITEA_WIKI_REF:-master}"
+WIKI_PAGE="${REPO_PATH}/wiki/page"
+WIKI_NEW="${REPO_PATH}/wiki/new"
+
+# docs/FILE.md → page name for wiki (stem: _ → -, title-case: First-Letter-Of-Each-Segment)
+file_to_page_name() {
+	local base="$1"
+	local stem="${base%.md}"
+	echo "$stem" | tr '_' '-' | awk -F- '{
+		for(i=1;i<=NF;i++) {
+			s = $i; l = length(s)
+			if (l > 0) $i = toupper(substr(s,1,1)) tolower(substr(s,2))
+		}
+	}1' OFS='-'
+}
+
+dry_run=false
+files=()
+while [[ $# -gt 0 ]]; do
+	case "$1" in
+		--dry-run) dry_run=true; shift ;;
+		*.md) files+=("$1"); shift ;;
+		*) log_err "Unknown option or not .md: $1"; exit 1 ;;
+	esac
+done
+
+if [[ ${#files[@]} -eq 0 ]]; then
+	while IFS= read -r -d '' f; do
+		files+=("$f")
+	done < <(find "$DOCS_DIR" -maxdepth 1 -name '*.md' -print0 | sort -z)
+else
+	# Resolve args to full paths under DOCS_DIR
+	for i in "${!files[@]}"; do
+		u="${files[$i]}"
+		if [[ "$u" != */* ]] && [[ -f "${DOCS_DIR}/${u}" ]]; then
+			files[$i]="${DOCS_DIR}/${u}"
+		fi
+	done
+fi
+
+if [[ ${#files[@]} -eq 0 ]]; then
+	log_err "No .md files found in ${DOCS_DIR}"
+	exit 1
+fi
+
+if [[ "$dry_run" == true ]]; then
+	log_info "Dry run: would migrate ${#files[@]} file(s)"
+	for f in "${files[@]}"; do
+		base="$(basename "$f")"
+		page="$(file_to_page_name "$base")"
+		echo "  $f → $page"
+	done
+	exit 0
+fi
+
+load_gitea_token || exit 1
+require_jq || exit 1
+
+for f in "${files[@]}"; do
+	base="$(basename "$f")"
+	page="$(file_to_page_name "$base")"
+	if [[ ! -f "$f" ]]; then
+		log_err "Skip (not a file): $f"
+		continue
+	fi
+	content="$(cat "$f")"
+	content_b64="$(echo -n "$content" | base64 -w 0)"
+	body="$(jq -n --arg title "$page" --arg content "$content_b64" --arg msg "Migrate from docs/$base" \
+		'{ title: $title, content_base64: $content, message: $msg }')"
+	# Check if page exists (GET); if 200 use PATCH else POST
+	resp="$(gitea_api_get "${REPO_PATH}/wiki/page/${page}?ref=${GITEA_WIKI_REF}")"
+	if echo "$resp" | jq -e .title &>/dev/null; then
+		log_info "Update: $base → $page"
+		patch_body="$(jq -n --arg content "$content_b64" --arg msg "Update from docs/$base" '{ content_base64: $content, message: $msg }')"
+		gitea_api_patch "${WIKI_PAGE}/${page}?ref=${GITEA_WIKI_REF}" "$patch_body" >/dev/null || true
+	else
+		log_info "Create: $base → $page"
+		gitea_api_post "${WIKI_NEW}" "$body" >/dev/null || true
+	fi
+done
+
+log_info "Migration done: ${#files[@]} file(s)."
diff --git a/gitea-issues/wiki-put-page.sh b/gitea-issues/wiki-put-page.sh
new file mode 100755
index 0000000..d3c61b4
--- /dev/null
+++ b/gitea-issues/wiki-put-page.sh
@@ -0,0 +1,46 @@
+#!/usr/bin/env bash
+#
+# Update a single wiki page from a local file.
+# Usage: ./wiki-put-page.sh <page_name> <file_path>
+# Example: ./wiki-put-page.sh Home docs/README.md
+# Requires GITEA_TOKEN or .secrets/gitea-issues/token.
+#
+set -euo pipefail
+
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+# shellcheck source=lib.sh
+source "${GITEA_ISSUES_DIR}/lib.sh"
+
+REPO_PATH="/repos/${GITEA_REPO_OWNER}/${GITEA_REPO_NAME}"
+GITEA_WIKI_REF="${GITEA_WIKI_REF:-master}"
+WIKI_PAGE="${REPO_PATH}/wiki/page"
+WIKI_NEW="${REPO_PATH}/wiki/new"
+
+if [[ $# -lt 2 ]]; then
+	log_err "Usage: $0 <page_name> <file_path>"
+	exit 1
+fi
+
+PAGE_NAME="$1"
+FILE_PATH="$2"
+[[ -f "$FILE_PATH" ]] || { log_err "File not found: $FILE_PATH"; exit 1; }
+
+load_gitea_token || exit 1
+require_jq || exit 1
+
+content="$(cat "$FILE_PATH")"
+content_b64="$(echo -n "$content" | base64 -w 0)"
+msg="Update from $FILE_PATH"
+
+resp="$(gitea_api_get "${REPO_PATH}/wiki/page/${PAGE_NAME}?ref=${GITEA_WIKI_REF}")"
+if echo "$resp" | jq -e .title &>/dev/null; then
+	log_info "PATCH ${PAGE_NAME}"
+	body="$(jq -n --arg title "$PAGE_NAME" --arg content "$content_b64" --arg msg "$msg" '{ title: $title, content_base64: $content, message: $msg }')"
+	gitea_api_patch "${WIKI_PAGE}/${PAGE_NAME}?ref=${GITEA_WIKI_REF}" "$body"
+else
+	log_info "POST ${PAGE_NAME}"
+	body="$(jq -n --arg title "$PAGE_NAME" --arg content "$content_b64" --arg msg "$msg" '{ title: $title, content_base64: $content, message: $msg }')"
+	gitea_api_post "${WIKI_NEW}" "$body"
+fi
+
+log_info "Done: ${PAGE_NAME}"
diff --git a/gitea-issues/write-response-spooler.py b/gitea-issues/write-response-spooler.py
new file mode 100644
index 0000000..4ea9391
--- /dev/null
+++ b/gitea-issues/write-response-spooler.py
@@ -0,0 +1,66 @@
+#!/usr/bin/env python3
+"""
+Update the single spooler file for a message after sending a reply.
+One file per message: read the .pending file (same base), add response data and set status to responded, write back.
+No separate .response file; no file deletion.
+Usage: ./gitea-issues/write-response-spooler.sh --base <base> --to <addr> --subject "..." --body "..." [--in-reply-to "<msg-id>"]
+  base = filename base without extension (e.g. 2026-03-14T094530.a1b2c3d4.user_example.com).
+"""
+from __future__ import annotations
+
+import argparse
+import json
+import sys
+from datetime import datetime, timezone
+from pathlib import Path
+
+sys.path.insert(0, str(Path(__file__).resolve().parent))
+from project_config import data_issues_dir, load_project_config
+
+
+def main() -> int:
+    conf = load_project_config()
+    if not conf:
+        print("[write-response-spooler] No project config.", file=sys.stderr)
+        return 1
+    spool = data_issues_dir()
+    spool.mkdir(parents=True, exist_ok=True)
+
+    ap = argparse.ArgumentParser(description="Update spooler file in place after sending reply")
+    ap.add_argument("--base", required=True, help="Base name (e.g. 2026-03-14T094530.a1b2c3d4.user_example.com)")
+    ap.add_argument("--to", required=True, help="Recipient address")
+    ap.add_argument("--subject", required=True, help="Subject sent")
+    ap.add_argument("--body", required=True, help="Body sent")
+    ap.add_argument("--in-reply-to", default="", help="Message-ID we replied to")
+    args = ap.parse_args()
+
+    base = args.base.strip()
+    if not base or "/" in base or ".." in base:
+        print("[write-response-spooler] Invalid --base.", file=sys.stderr)
+        return 1
+    path = spool / f"{base}.pending"
+    if not path.exists():
+        print(f"[write-response-spooler] No such file: {path.name}", file=sys.stderr)
+        return 1
+    try:
+        data = json.loads(path.read_text(encoding="utf-8"))
+    except (json.JSONDecodeError, OSError) as e:
+        print(f"[write-response-spooler] Read error: {e}", file=sys.stderr)
+        return 1
+
+    now = datetime.now(timezone.utc).strftime("%Y-%m-%dT%H:%M:%SZ")
+    data["status"] = "responded"
+    data["response"] = {
+        "in_reply_to_message_id": args.in_reply_to or "",
+        "to": args.to.strip(),
+        "subject": args.subject.strip(),
+        "body": args.body,
+        "sent_at": now,
+    }
+    path.write_text(json.dumps(data, ensure_ascii=False, indent=2), encoding="utf-8")
+    print(f"[write-response-spooler] Updated {path.name} (status=responded)")
+    return 0
+
+
+if __name__ == "__main__":
+    sys.exit(main())
diff --git a/gitea-issues/write-response-spooler.sh b/gitea-issues/write-response-spooler.sh
new file mode 100755
index 0000000..b4674dd
--- /dev/null
+++ b/gitea-issues/write-response-spooler.sh
@@ -0,0 +1,8 @@
+#!/usr/bin/env bash
+# Update the single spooler file (.pending) after sending a reply via mail-send-reply.sh. One file per message.
+# Usage: ./ia_dev/gitea-issues/write-response-spooler.sh --base <base> --to <addr> --subject "..." --body "..." [--in-reply-to "<msg-id>"]
+set -euo pipefail
+GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
+export GITEA_ISSUES_DIR
+export REPO_ROOT="${GITEA_ISSUES_DIR}/.."
+exec python3 "${GITEA_ISSUES_DIR}/write-response-spooler.py" "$@"
diff --git a/lib/README.md b/lib/README.md
new file mode 100644
index 0000000..8749390
--- /dev/null
+++ b/lib/README.md
@@ -0,0 +1,13 @@
+# ia_dev shared lib
+
+## project_config.sh
+
+Sourced by deploy scripts and gitea-issues to resolve the current project **id** and the path to its JSON config.
+
+**Before sourcing:** set `PROJECT_ROOT` (git repo root, where `ai_project_id` or `.ia_project` lives) and `IA_DEV_ROOT` (path to the `ia_dev` directory).
+
+**After sourcing:** `PROJECT_SLUG` and `PROJECT_CONFIG_PATH` are set (and exported). Config path is `projects/<id>/conf.json`.
+
+**Project id resolution order:** `IA_PROJECT` env → `.ia_project` at PROJECT_ROOT → `ai_project_id` at PROJECT_ROOT.
+
+See `projects/README.md` for the config schema.
diff --git a/lib/project_config.sh b/lib/project_config.sh
new file mode 100644
index 0000000..8c699f6
--- /dev/null
+++ b/lib/project_config.sh
@@ -0,0 +1,68 @@
+#
+# Project config resolution for ia_dev scripts.
+# Source this after setting PROJECT_ROOT and IA_DEV_ROOT.
+# Resolves PROJECT_SLUG (id) and PROJECT_CONFIG_PATH (projects/<id>/conf.json).
+#
+# Project id resolution order:
+#   1. MAIL_TO (env): search all projects for tickets.authorized_emails.to == MAIL_TO
+#   2. AI_AGENT_TOKEN (env): search all projects/.secrets/<env>/ia_token for matching token; sets PROJECT_SLUG and PROJECT_ENV
+#   3. IA_PROJECT (env)
+#   4. .ia_project at PROJECT_ROOT (one line)
+#   5. ai_project_id at PROJECT_ROOT (one line)
+#
+# Config file: projects/<id>/conf.json.
+#
+set -euo pipefail
+
+PROJECT_SLUG=""
+if [[ -n "${MAIL_TO:-}" && -n "${IA_DEV_ROOT:-}" ]]; then
+	_to="$(echo "${MAIL_TO}" | sed 's/[[:space:]]//g' | tr '[:upper:]' '[:lower:]')"
+	for conf in "${IA_DEV_ROOT}/projects/"*/conf.json; do
+		[[ -f "$conf" ]] || continue
+		_to_conf="$(jq -r '.tickets.authorized_emails.to // ""' "$conf" 2>/dev/null | tr '[:upper:]' '[:lower:]' | sed 's/[[:space:]]//g')"
+		if [[ -n "$_to_conf" && "$_to_conf" = "$_to" ]]; then
+			PROJECT_SLUG="$(basename "$(dirname "$conf")")"
+			break
+		fi
+	done
+fi
+PROJECT_ENV=""
+if [[ -z "$PROJECT_SLUG" && -n "${AI_AGENT_TOKEN:-}" && -n "${IA_DEV_ROOT:-}" ]]; then
+	_token="$(echo "${AI_AGENT_TOKEN}" | sed 's/^[[:space:]]*//;s/[[:space:]]*$//')"
+	for _pdir in "${IA_DEV_ROOT}/projects/"*/; do
+		[[ -d "${_pdir}.secrets" ]] || continue
+		_project="$(basename "$_pdir")"
+		for _envdir in "${_pdir}.secrets/"*/; do
+			[[ -f "${_envdir}ia_token" ]] || continue
+			_env="$(basename "$_envdir")"
+			_tok_conf="$(cat "${_envdir}ia_token" 2>/dev/null | sed 's/^[[:space:]]*//;s/[[:space:]]*$//')"
+			# Token is either full value in file or base + env (e.g. nicolecoffreio<env>)
+			if [[ -n "$_tok_conf" && ( "$_tok_conf" = "$_token" || "${_tok_conf}${_env}" = "$_token" ) ]]; then
+				PROJECT_SLUG="$_project"
+				PROJECT_ENV="$_env"
+				break 2
+			fi
+		done
+	done
+fi
+export PROJECT_ENV
+if [[ -z "$PROJECT_SLUG" && -n "${IA_PROJECT:-}" ]]; then
+	PROJECT_SLUG="$(echo "${IA_PROJECT}" | sed 's/[[:space:]]//g')"
+fi
+if [[ -z "$PROJECT_SLUG" && -n "${PROJECT_ROOT:-}" && -f "$PROJECT_ROOT/.ia_project" ]]; then
+	PROJECT_SLUG="$(cat "$PROJECT_ROOT/.ia_project" | sed 's/[[:space:]]//g')"
+fi
+if [[ -z "$PROJECT_SLUG" && -n "${PROJECT_ROOT:-}" && -f "$PROJECT_ROOT/ai_project_id" ]]; then
+	PROJECT_SLUG="$(cat "$PROJECT_ROOT/ai_project_id" | sed 's/[[:space:]]//g')"
+fi
+
+PROJECT_CONFIG_PATH=""
+if [[ -n "$PROJECT_SLUG" && -n "${IA_DEV_ROOT:-}" ]]; then
+	PROJECT_CONFIG_PATH="${IA_DEV_ROOT}/projects/${PROJECT_SLUG}/conf.json"
+	if [[ ! -f "$PROJECT_CONFIG_PATH" ]]; then
+		PROJECT_CONFIG_PATH=""
+	fi
+fi
+
+export PROJECT_SLUG
+export PROJECT_CONFIG_PATH
diff --git a/projects/README.md b/projects/README.md
new file mode 100644
index 0000000..dbae473
--- /dev/null
+++ b/projects/README.md
@@ -0,0 +1,53 @@
+# Project-specific configuration
+
+This repo (`ia_dev`) is intended to be used as a **git submodule** inside each project. Project-specific parameters are stored in `projects/<id>/conf.json` (e.g. `projects/lecoffreio/conf.json`). The `<id>` is the project identifier and the name of the directory under `projects/`.
+
+## Current project selection
+
+There is no longer a "slug" in the URL or path; the project **id** (directory name under `projects/`) is resolved by:
+
+**1. Mail ticketing**  
+From the **To** address of an email: search all `projects/*/conf.json` for `tickets.authorized_emails.to` equal to that address (case-insensitive). The matching project directory name is the id.
+
+**2. API ai_working_help**  
+The token is found by scanning as described above: traverse all projects and all envs, reading each `projects/<id>/.secrets/<env>/ia_token` and comparing its content (or content + env) to the Bearer token. The first match yields the project id and the env (e.g. `test`, `pprod`, `prod`).
+
+**3. Scripts / fallback** (when no request context)  
+- **`MAIL_TO`** (env): same as (1), resolve id by email "to".  
+- **`AI_AGENT_TOKEN`** (env): same as (2), resolve id (and env) by token; sets `PROJECT_SLUG` and `PROJECT_ENV`.  
+- **`IA_PROJECT`** (env)  
+- **`.ia_project`** at repository root (one line)  
+- **`ai_project_id`** at repository root (one line). When `ia_dev` is a submodule, this file lives at the host repo root (parent of `ia_dev`).
+
+When running from a repo that has `ia_dev` as a submodule, the root is the parent repo; the script resolves `ia_dev` either as `./ia_dev` or `./deploy` (symlink to `ia_dev/deploy`).
+
+## Schema
+
+One JSON file per project: `projects/<id>/conf.json` (e.g. `projects/lecoffreio/conf.json`). The `<id>` is the directory name; the config file is always named `conf.json`.
+
+| Field | Required | Description |
+|-------|----------|-------------|
+| `name` | yes | Human-readable project name |
+| `project_path` | no | Relative path to project from ia_dev (e.g. `../lecoffre_ng_test`); used when running from ia_dev standalone |
+| `build_dirs` | no | List of directories (relative to repo root) where `npm run build` is run before push. If missing or empty, build check is skipped |
+| `version` | no | Version/bump configuration |
+| `version.package_json_paths` | no | List of paths (relative to repo root) to `package.json` files to update on bump |
+| `version.splash_app_name` | no | App name used in splash message template |
+| `mail` | no | Mail/imap bridge config |
+| `git` | no | Git hosting: `wiki_url`, `token_file` (path relative to repo root for token file). Ticketing URL is under `tickets`, not `git`. |
+| `tickets` | no | Ticketing: `ticketing_url` (Gitea issues URL), `authorized_emails` (`to`: alias, `from`: list of allowed sender addresses for mail-based ticketing). The **to** address is used to resolve the project id when processing mails. See projects/ia_dev/docs/TICKETS_SPOOL_FORMAT.md. |
+
+The API token for ai_working_help is **not** in conf.json. It is found by scanning all projects and all envs (as described above): each file `projects/<id>/.secrets/<env>/ia_token` is read and the Bearer is compared to the file content or to (file content + env). Token value is **base** + **env**; **env** is the environment name (test, pprod, prod), to be adapted per environment. The first match gives project id and env.
+
+## Example (minimal)
+
+```json
+{
+  "name": "My App",
+  "build_dirs": ["backend", "frontend"]
+}
+```
+
+## Example (full)
+
+See `projects/lecoffreio/conf.json`.
diff --git a/projects/algo/conf.json b/projects/algo/conf.json
new file mode 100644
index 0000000..bbc04cb
--- /dev/null
+++ b/projects/algo/conf.json
@@ -0,0 +1,37 @@
+{
+	"id": "algo",
+	"name": "algo",
+	"project_path": "/home/desk/code/algo/deploy",
+	"build_dirs": [
+		"/home/desk/code/algo/deploy/lecoffre-ressources-dev",
+		"/home/desk/code/algo/deploy/lecoffre-back-main",
+		"/home/desk/code/algo/deploy/lecoffre-front-main"
+	],
+	"deploy": {
+		"scripts_path": "/home/desk/code/algo/deploy/scripts_v2",
+		"deploy_script_path": "/home/desk/code/algo/deploy/scripts_v2/deploy.sh",
+		"secrets_path": "/home/desk/code/algo/.secrets"
+	},
+	"version": {
+		"package_json_paths": [
+			"/home/desk/code/algo/deploy/lecoffre-back-main/package.json",
+			"/home/desk/code/algo/deploy/lecoffre-front-main/package.json"
+		],
+		"splash_app_name": "algo"
+	},
+	"mail": {
+		"email": "ai.support.algo@4nkweb.com",
+		"imap_bridge_env": ".secrets/gitea-issues/imap-bridge.env"
+	},
+	"git": {
+		"wiki_url": "https://git.4nkweb.com/nicolas.cantu/algo/wiki",
+		"token_file": ".secrets/gitea-issues/token"
+	},
+	"tickets": {
+		"ticketing_url": "https://git.4nkweb.com/nicolas.cantu/algo/issues",
+		"authorized_emails": {
+			"to": "ai.support.algo@4nkweb.com",
+			"from": []
+		}
+	}
+}
diff --git a/projects/enso/conf.json b/projects/enso/conf.json
new file mode 100644
index 0000000..6ca95ae
--- /dev/null
+++ b/projects/enso/conf.json
@@ -0,0 +1,37 @@
+{
+	"id": "enso",
+	"name": "enso",
+	"project_path": "/home/desk/code/enso/deploy",
+	"build_dirs": [
+		"/home/desk/code/enso/deploy/lecoffre-ressources-dev",
+		"/home/desk/code/enso/deploy/lecoffre-back-main",
+		"/home/desk/code/enso/deploy/lecoffre-front-main"
+	],
+	"deploy": {
+		"scripts_path": "/home/desk/code/enso/deploy/scripts_v2",
+		"deploy_script_path": "/home/desk/code/enso/deploy/scripts_v2/deploy.sh",
+		"secrets_path": "/home/desk/code/enso/.secrets"
+	},
+	"version": {
+		"package_json_paths": [
+			"/home/desk/code/enso/deploy/lecoffre-back-main/package.json",
+			"/home/desk/code/enso/deploy/lecoffre-front-main/package.json"
+		],
+		"splash_app_name": "enso"
+	},
+	"mail": {
+		"email": "ai.support.enso@4nkweb.com",
+		"imap_bridge_env": ".secrets/gitea-issues/imap-bridge.env"
+	},
+	"git": {
+		"wiki_url": "https://git.4nkweb.com/nicolas.cantu/enso/wiki",
+		"token_file": ".secrets/gitea-issues/token"
+	},
+	"tickets": {
+		"ticketing_url": "https://git.4nkweb.com/nicolas.cantu/enso/issues",
+		"authorized_emails": {
+			"to": "ai.support.enso@4nkweb.com",
+			"from": []
+		}
+	}
+}
diff --git a/projects/ia_dev/conf.json b/projects/ia_dev/conf.json
new file mode 100644
index 0000000..63f0029
--- /dev/null
+++ b/projects/ia_dev/conf.json
@@ -0,0 +1,27 @@
+{
+	"id": "ia_dev",
+	"name": "ia_dev",
+	"project_path": "../",
+	"base_path": "ia_dev",
+	"build_dirs": [],
+	"deploy": {},
+	"version": {
+		"package_json_paths": [],
+		"splash_app_name": "ia_dev"
+	},
+	"mail": {
+		"email": "ai.support.ia_dev@4nkweb.com",
+		"imap_bridge_env": ".secrets/gitea-issues/imap-bridge.env"
+	},
+	"git": {
+		"wiki_url": "https://git.4nkweb.com/4nk/ia_dev/wiki",
+		"token_file": ".secrets/gitea-issues/token"
+	},
+	"tickets": {
+		"ticketing_url": "https://git.4nkweb.com/4nk/ia_dev/issues",
+		"authorized_emails": {
+			"to": "ai.support.ia_dev@4nkweb.com",
+			"from": ["nicolas.cantu@pm.me"]
+		}
+	}
+}
diff --git a/projects/ia_dev/docs/GITEA_ISSUES_SCRIPTS_AGENTS.md b/projects/ia_dev/docs/GITEA_ISSUES_SCRIPTS_AGENTS.md
new file mode 100644
index 0000000..193870a
--- /dev/null
+++ b/projects/ia_dev/docs/GITEA_ISSUES_SCRIPTS_AGENTS.md
@@ -0,0 +1,159 @@
+# Gitea issues – scripts et agents
+
+Dossier dédié au traitement des tickets (issues) Gitea du dépôt **4nk/lecoffre_ng** (https://git.4nkweb.com/4nk/lecoffre_ng/issues). Toute la logique d'appel API et Git est dans les scripts ; les agents orchestrent et appellent /fix ou /evol.
+
+## Contraintes de confidentialité et d'accès des agents
+
+L'agent ne doit **jamais révéler** :
+
+- Quelle IA il utilise
+- Des informations personnelles
+- Des informations sur 4NK
+- Des informations sur l'équipe de réalisation
+- Des informations sur des fichiers hors projet parent
+- Des informations sur les autres questions et réponses traitées
+
+L'agent ne doit **jamais accéder ni modifier** :
+
+- Les fichiers hors projet (périmètre = dépôt parent et ia_dev dans ce dépôt)
+- Les fichiers dans `.cursor` et `.secrets`
+- D'autres branches que celle en cours de travail
+- D'autres environnements (test / pprod / prod) que celui défini par le contexte
+
+## Agents (.cursor/agents/)
+
+| Agent | Fichier | Rôle |
+|-------|---------|------|
+| **agent-loop** | `agent-loop.md` | Orchestre la boucle de récupération des mails et le traitement par **exécutions délimitées** uniquement (N itérations ou x cycles) ; ne lance jamais de processus en arrière-plan (nohup/&). |
+| **gitea-issues-process** | `gitea-issues-process.md` | Traite les issues Gitea et les mails en attente : liste les issues/mails, crée des branches, lance /fix ou /evol, /push-by-script ; workflow mails (fil, réponse réelle, marquage lu). |
+
+Spooler tickets (nouveau) : mails dans **projects/<id>/data/issues/** (filtre par `tickets.authorized_emails` dans conf.json), pas de « non lu », aucun enregistrement supprimé. Format : `projects/ia_dev/docs/TICKETS_SPOOL_FORMAT.md`. Récupération : `./ia_dev/gitea-issues/tickets-fetch-inbox.sh`. Référence boucle mails (legacy) : `.cursor/agents/agent-loop.md`. Hook Cursor : `sessionStart` → `.cursor/hooks/remonter-mails.sh` (lit `projects/<id>/data/issues/*.pending`).
+
+## Contexte d'exécution
+
+- **Emplacement** : `gitea-issues/` est dans le sous-module **ia_dev** du dépôt projet. Chemin typique : `<racine_projet>/ia_dev/gitea-issues/`. Fonctionne pour tout projet utilisant ia_dev de la même manière.
+- **Projet cible** : le projet est identifié **dynamiquement** par le fichier `../ai_project_id` (à la racine du dépôt projet, parent de `ia_dev`). Son contenu (slug) sert à charger la config dans `ia_dev/projects/<id>/`. Changer de projet = changer le dépôt (ou le contenu de `ai_project_id`) ; aucun chemin à hardcoder.
+- **Lancement** : le chat Cursor et les scripts sont lancés depuis **ia_dev** (`<racine_projet>/ia_dev/`), mais les opérations (issues, mails, déploiement) concernent le dépôt **parent** (`../` = racine projet). Invoquer les scripts depuis la racine du dépôt projet : `cd <racine_projet> && ./ia_dev/gitea-issues/<script>.sh`. Depuis le workspace ia_dev, racine projet = `..`.
+- **Secrets et logs** : `.secrets` est sous **ia_dev** (`ia_dev/.secrets`, soit `./.secrets` depuis ia_dev), et **ne dépend pas du projet parent**. Les scripts résolvent la racine pour `.secrets` et `logs` via le répertoire contenant `gitea-issues` (ia_dev), afin que la config IMAP/SMTP et les logs soient les mêmes quel que soit le projet ; un même clone ia_dev peut servir plusieurs projets configurés par `../ai_project_id`.
+
+## Prérequis
+
+- **jq** : `apt install jq` ou `brew install jq`
+- **Token Gitea** : variable d'environnement `GITEA_TOKEN` ou fichier `.secrets/gitea-issues/token` (contenu = le token, non versionné). Créer le token dans Gitea : Settings → Applications → Generate New Token (scopes `read:issue`, `write:issue` si commentaires).
+
+## Scripts (depuis la racine du dépôt)
+
+| Script | Usage | Description |
+|--------|--------|-------------|
+| `list-open-issues.sh` | `./gitea-issues/list-open-issues.sh [--lines] [--limit N]` | Liste les issues ouvertes (JSON ou lignes `number\|title\|state`). |
+| `get-issue.sh` | `./gitea-issues/get-issue.sh <num> [--summary]` | Détail d'une issue (JSON ou résumé texte). |
+| `print-issue-prompt.sh` | `./gitea-issues/print-issue-prompt.sh <num>` | Affiche titre + corps pour fournir la consigne à l'agent. |
+| `create-branch-for-issue.sh` | `./gitea-issues/create-branch-for-issue.sh <num> [base]` | Crée et checkout la branche `issue/<num>` depuis `base` (défaut `test`). |
+| `comment-issue.sh` | `./gitea-issues/comment-issue.sh <num> <message>` ou `echo "msg" \| ./gitea-issues/comment-issue.sh <num> -` | Ajoute un commentaire à l'issue. |
+| `mail-list-unread.sh` | `./gitea-issues/mail-list-unread.sh` | Liste les mails **non lus envoyés à l'alias** (MAIL_FILTER_TO), **à partir du 10 mars 2026** (MAIL_SINCE_DATE) ; lecture seule ; sortie : UID, Message-ID, From, To, Subject, Date, Body. Aucun autre mail n'est listé. |
+| `mail-get-thread.sh` | `./gitea-issues/mail-get-thread.sh <uid>` | Récupère **tout le fil** (conversation) du mail donné : tous les messages liés par References/In-Reply-To, tri chronologique (ancien → récent). Même format de sortie que mail-list-unread. À utiliser avant de décider ou répondre sur un mail. |
+| `mail-send-reply.sh` | `./gitea-issues/mail-send-reply.sh --to <addr> --subject "..." [--body "..." \| stdin] [--in-reply-to "<msg-id>" [--references "..."]]` | Envoie une réponse par mail via le Bridge (SMTP) ; signature « Support IA du projet Lecoffre.io » / ai.support.lecoffreio@4nkweb.com ajoutée automatiquement. |
+| `mail-create-issue-from-email.sh` | `./gitea-issues/mail-create-issue-from-email.sh --uid <uid> [--title "..." ] [--body "..."]` | Crée une issue à partir d'un mail (UID), optionnel titre/corps formalisés ; marque le mail lu. |
+| `mail-mark-read.sh` | `./gitea-issues/mail-mark-read.sh <uid>` | Marque un mail comme lu. |
+| `mail-thread-log.sh` | `./gitea-issues/mail-thread-log.sh get-id \| init \| append-sent \| append-issue \| append-commit ...` | **Log par fil** : un fichier par conversation dans `projects/<id>/logs/gitea-issues/threads/` (échanges reçus/envoyés, tickets, commits). `get-id --uid <uid>` affiche `THREAD_ID=...` ; `init --uid <uid>` crée/met à jour le fichier ; `append-sent/issue/commit` enregistrent une réponse, une issue ou un commit. |
+| `mail-to-issue.sh` | `./gitea-issues/mail-to-issue.sh` | **Batch** : crée une issue par mail non lu (titre = sujet, corps = texte + From), marque lus. À éviter si on suit le workflow agent (voir ci‑dessous). |
+| `agent-loop.sh` | `./ia_dev/gitea-issues/agent-loop.sh [interval_sec]` | **Boucle de surveillance** : tourne indéfiniment (spooler ou legacy). **Ne pas lancer depuis l'agent** ; utiliser agent-loop-chat-iterations.sh ou cycles délimités. Voir `.cursor/agents/agent-loop.md`. |
+| `agent-loop-treatment.sh` | `./ia_dev/gitea-issues/agent-loop-treatment.sh` | **Boucle traitement** : vérifie périodiquement `agent-loop.pending` ; si non vide, lance l'agent Cursor. Tourne indéfiniment ; **ne pas lancer depuis l'agent** (préférer agent-loop-chat-iterations.sh ou cycles délimités). |
+| `agent-loop-retrieval-once.sh` | `./ia_dev/gitea-issues/agent-loop-retrieval-once.sh` | **Récupération une fois** (legacy, basé non lu) : exécute `mail-list-unread.sh` et écrit dans `agent-loop.pending`. Utilisé par l'agent agent-loop pour les cycles « x fois ». |
+| `agent-loop-lock-acquire.sh` | `./ia_dev/gitea-issues/agent-loop-lock-acquire.sh` | **Lock (section 2)** : acquiert `agent-loop.lock` si absent ou périmé (>24 h). Exit 1 si lock actif ; l'agent ne doit pas lancer une deuxième instance. |
+| `agent-loop-lock-release.sh` | `./ia_dev/gitea-issues/agent-loop-lock-release.sh` | **Lock (section 2)** : supprime `agent-loop.lock` et `agent-loop.stop`. À exécuter en fin de cycles (normale ou arrêt). |
+| `agent-loop-stop.sh` | `./ia_dev/gitea-issues/agent-loop-stop.sh` | **Arrêt à la demande** : crée `agent-loop.stop` ; l'instance en cours s'arrête au début du cycle suivant. |
+| `agent-loop-stop-requested.sh` | `./ia_dev/gitea-issues/agent-loop-stop-requested.sh` | **Vérification arrêt** : exit 0 si `agent-loop.stop` existe (utilisé par l'agent au début de chaque cycle). |
+| `agent-loop-is-running.sh` | `./ia_dev/gitea-issues/agent-loop-is-running.sh` | **Vérifier si l'agent est en cours** : affiche fichier lock, PID et date ; indique si le processus est actif ou lock orphelin. Exit 0 si instance en cours (lock mtime < 24 h), 1 sinon. |
+| `tickets-fetch-inbox.sh` | `./ia_dev/gitea-issues/tickets-fetch-inbox.sh` | **Récupération par expéditeurs autorisés** : mails **à partir du 10 mars 2026** (MAIL_SINCE_DATE), filtre `tickets.authorized_emails` (conf.json), pas de marquage lu/non lu. Écrit les nouveaux mails dans `projects/<id>/data/issues/*.pending` (JSON). Ne crée pas de .pending si un .response existe déjà. Voir `projects/ia_dev/docs/TICKETS_SPOOL_FORMAT.md`. |
+| `list-pending-spooler.sh` | `./ia_dev/gitea-issues/list-pending-spooler.sh` | **Spooler** : liste les fichiers `projects/<id>/data/issues/*.pending` qui n'ont **pas** de fichier `.response` correspondant (mails à traiter). Une ligne par chemin. |
+| `write-response-spooler.sh` | `./ia_dev/gitea-issues/write-response-spooler.sh --base <base> --to <addr> --subject "..." --body "..." [--in-reply-to "<msg-id>"]` | **Spooler** : après envoi réussi avec `mail-send-reply.sh`, écrit `projects/<id>/data/issues/<base>.response` (JSON de la réponse envoyée). |
+
+Variables optionnelles : `GITEA_API_URL`, `GITEA_REPO_OWNER`, `GITEA_REPO_NAME`, `GITEA_ISSUES_DIR`.
+
+### Fichiers témoins et logs (boucle agent)
+
+Sous `projects/<id>/logs/gitea-issues/` :
+
+- **agent-loop.status** : fichier témoin de la boucle de surveillance (`agent-loop.sh` ou `agent-loop-retrieval-once.sh`). Trois lignes : horodatage (ISO), statut (`running` ou `idle`), détail (ex. « Aucun mail non lu »). Mis à jour à chaque itération. Si la date de modification est plus récente que 2× l’intervalle (ex. 120 s pour intervalle 60 s), la boucle est considérée active.
+- **agent-loop.pending** : liste des mails non lus (legacy) écrite par `mail-list-unread.sh` via la boucle ; l’agent gitea-issues-process traite ce fichier.
+- **agent-loop.lock** : lock pour une seule instance (section 2). Contenu : PID + date. Si mtime < 24 h, une nouvelle instance ne doit pas démarrer. Géré par `agent-loop-lock-acquire.sh` / `agent-loop-lock-release.sh`.
+- **agent-loop.stop** : si présent, l'instance en cours s'arrête au début du cycle suivant. Création : `agent-loop-stop.sh` ou `touch …/agent-loop.stop`.
+- **agent-loop-chat-iterations.log** : sortie de `agent-loop-chat-iterations.sh` (test d’envoi au lancement, puis à chaque itération le résultat de `mail-list-unread.sh`).
+
+Le répertoire **projects/<id>/data/issues/** (spooler) est rempli **uniquement** par `./ia_dev/gitea-issues/tickets-fetch-inbox.sh`. Si ce script n'est pas exécuté, `data/issues` reste vide si on n’utilise que la boucle legacy utilise seulement mail-list-unread.sh et agent-loop.pending dans logs/gitea-issues/.
+
+**Réponse mail** : le `--body` de `mail-send-reply.sh` doit être **uniquement le texte rédigé par l’agent** (la réponse à l’expéditeur). Ne jamais y mettre le mail reçu, le sujet, une citation ou un bloc « From: » / « Message-ID » : sinon le destinataire reçoit son propre message au lieu de la réponse.
+
+### Création d'issues depuis les mails (IMAP) – workflow agent
+
+**Ne pas enchaîner directement** : l'agent doit d'abord lire les non lus, formaliser l'issue ou répondre par mail, et ne créer/traiter qu'au moment où la demande est prête.
+
+1. **Lire les non lus** : `./gitea-issues/mail-list-unread.sh` (ne marque pas les mails comme lus).
+2. **Pour chaque mail** : consulter **tout l'historique du fil** avec `./gitea-issues/mail-get-thread.sh <uid>`, créer/mettre à jour le **log du fil** avec `./gitea-issues/mail-thread-log.sh init --uid <uid>` (sortie `THREAD_ID=...` à conserver), puis décider soit d'envoyer une réponse directe (demande d'infos) via `mail-send-reply.sh`, soit de formaliser et créer l'issue avec `mail-create-issue-from-email.sh` (optionnel `--title` / `--body` formalisés). Si la demande est une correction/évolution prête : créer l'issue, traiter (fix/evol), commenter l'issue, répondre au mail via `mail-send-reply.sh` (avec `--in-reply-to` pour le fil). **Le corps de la réponse** doit contenir la **réponse réelle** à la question (ex. si le mail demande « Décrit les rôles », le body = une description des rôles), jamais le sujet du mail ni la question reçue.
+3. **Réponses aux mails** : toujours via le Bridge avec `mail-send-reply.sh`. Le `--body` doit être la **réponse réelle** rédigée par l'agent (contenu de la réponse à la demande), pas le sujet du mail, pas la question reçue, pas un message précédent du fil. Chaque envoi est enregistré dans le log du fil avec `mail-thread-log.sh append-sent --thread-id <id> --to <addr> --subject "..." --body "..."` pour tracer l'expéditeur, le titre et le corps de la réponse envoyée.
+
+**Prérequis :**
+
+- Python 3 (stdlib : imaplib, email, smtplib, json, urllib).
+- Token Gitea : comme les autres scripts (`GITEA_TOKEN` ou `.secrets/gitea-issues/token`).
+- Config IMAP/SMTP : copier `gitea-issues/imap-bridge.env.example` vers `.secrets/gitea-issues/imap-bridge.env`. Pour la boucle agent (optionnel) : `agent-loop.env.example` vers `.secrets/gitea-issues/agent-loop.env` (voir `.cursor/agents/agent-loop.md`). Renseigner `IMAP_USER`, `IMAP_PASSWORD` (et optionnellement `SMTP_*` pour l'envoi ; par défaut SMTP reprend les mêmes host/port Bridge 1025). Optionnel : `MAIL_FILTER_TO=ai.support.lecoffreio@4nkweb.com` (seuls les mails envoyés à cette adresse sont listés) ; `MAIL_SINCE_DATE=10-Mar-2026` (seuls les mails à partir de cette date sont récupérés/listés).
+- Proton Mail Bridge (ou serveur IMAP/SMTP) en cours d'exécution.
+
+**Scripts :** `mail-list-unread.sh`, `mail-get-thread.sh`, `mail-thread-log.sh`, `mail-send-reply.sh`, `mail-create-issue-from-email.sh`, `mail-mark-read.sh`. Le script batch `mail-to-issue.sh` reste disponible mais ne doit pas être utilisé dans le cadre du workflow agent (liste → lecture du fil → log du fil → décision → création/ réponse). Le script **`agent-loop.sh`** permet de lancer une boucle de surveillance des mails avec fichier témoin ; voir `.cursor/agents/agent-loop.md`.
+
+## API Wiki (tests préalables)
+
+Script de test de l'API Wiki Gitea pour le même dépôt (prérequis à une éventuelle migration de `docs/` vers le wiki) :
+
+| Script | Usage | Description |
+|--------|--------|-------------|
+| `wiki-api-test.sh` | `./gitea-issues/wiki-api-test.sh [--create]` | Teste GET list pages, GET page Home ; avec `--create` : POST une page test puis DELETE. |
+
+**Prérequis :** même token que les issues (`GITEA_TOKEN` ou `.secrets/gitea-issues/token`). Pour l'écriture (création / suppression de pages), le token doit avoir les droits d'écriture sur le dépôt.
+
+**Endpoints utilisés (référence Gitea API 1.25) :**
+
+- `GET /repos/{owner}/{repo}/wiki/pages` — liste des pages
+- `GET /repos/{owner}/{repo}/wiki/page/{pageName}` — contenu d'une page (ex. `Home`)
+- `POST /repos/{owner}/{repo}/wiki/new` — créer une page (body : `title`, `content_base64`, `message`)
+- `PATCH /repos/{owner}/{repo}/wiki/page/{pageName}` — modifier une page
+- `DELETE /repos/{owner}/{repo}/wiki/page/{pageName}` — supprimer une page
+
+Si le wiki n'a jamais été initialisé (aucune page créée via l'interface), les GET peuvent renvoyer 404 ou une liste vide. **Initialiser le wiki** : aller sur https://git.4nkweb.com/4nk/lecoffre_ng/wiki et créer au moins une page (ex. « Home ») via l'interface, puis relancer le script avec un token valide.
+
+**Branche par défaut du wiki :** si l'API renvoie `object does not exist [id: refs/heads/master]` alors que la branche par défaut du dépôt wiki est autre (ex. `prod`), c'est un bug connu de certaines versions de Gitea (l'API suppose `master`). Contournements possibles : (1) **mettre à jour Gitea** (correctif dans les versions récentes, ex. PR #34244) ; (2) **changer la branche par défaut du wiki** en `master` dans les réglages du dépôt (Settings → Branches). Variable optionnelle `GITEA_WIKI_REF=master` (défaut si wiki configuré sur master).
+
+### Migration docs/ → wiki
+
+**Décision :** tout le contenu de `docs/` (racine du dépôt) est migré vers le wiki ; pas de CI sur le wiki.
+
+**Script de migration :**
+
+| Script | Usage | Description |
+|--------|--------|-------------|
+| `wiki-migrate-docs.sh` | `./gitea-issues/wiki-migrate-docs.sh [--dry-run] [fichier.md ...]` | Migre `docs/*.md` vers le wiki. `--dry-run` affiche le mapping sans appel API. Si des fichiers sont passés en argument, migre uniquement ceux-là. |
+| `wiki-put-page.sh` | `./gitea-issues/wiki-put-page.sh <page_name> <file_path>` | Met à jour ou crée une page wiki à partir d'un fichier local (ex. `Home docs/README.md`). |
+| `wiki-get-page.sh` | `./gitea-issues/wiki-get-page.sh <page_name>` | Affiche le markdown brut d'une page wiki (pour scripts ou agents). |
+
+**Correspondance fichier → page wiki :** nom de fichier sans `.md`, `_` remplacé par `-`, title-case par segment. Ex. OPERATIONS.md → Operations, README.md → Readme.
+
+Les 17 fichiers de `docs/` ont été migrés ; les pages sont visibles sur https://git.4nkweb.com/4nk/lecoffre_ng/wiki. La page **Home** contient le contenu de `docs/README.md` (index et correspondance). **`docs/` est exclu du versionnement** (`.gitignore`) : maintenir `docs/` localement (ne pas le supprimer), pousser les modifications vers le wiki avec `wiki-migrate-docs.sh` ou `wiki-put-page.sh` ; ne pas committer `docs/`.
+
+### Après un clone
+
+Le répertoire `docs/` n'est pas versionné. Pour disposer d'une copie locale (édition puis synchro wiki), recréer le contenu à partir du wiki : ex. `./gitea-issues/wiki-get-page.sh Home > docs/README.md`, ou créer les fichiers manuellement à partir des pages wiki listées dans la section Migration ci-dessus.
+
+### Usage « wiki uniquement » pour les agents
+
+La connaissance du projet peut reposer **uniquement sur le wiki** (sans lire `docs/`) : les agents peuvent exécuter `./gitea-issues/wiki-get-page.sh <PageName>` pour récupérer le contenu markdown d'une page et l'utiliser comme référence. Exemples : `./gitea-issues/wiki-get-page.sh Home`, `./gitea-issues/wiki-get-page.sh Operations`, `./gitea-issues/wiki-get-page.sh Code-Standards`. Prérequis : token Gitea (comme pour les autres scripts wiki). Les agents peuvent ainsi consulter la doc projet à la demande depuis le wiki, sans dépendre des fichiers locaux `docs/`. La documentation des projets gérés est dans **`projects/<id>/docs`** (ex. `projects/lecoffreio/docs`) ; la documentation propre à ia_dev est dans **`projects/ia_dev/docs`**.
+
+## Agents (commandes)
+
+- **/agent-loop** (`agent-loop.md`) : gère les boucles par exécutions délimitées uniquement (N itérations avec `agent-loop-chat-iterations.sh [N]`, ou x cycles récupération + traitement). Ne lance jamais agent-loop.sh ni agent-loop-treatment.sh en arrière-plan.
+- **/gitea-issues-process** (`gitea-issues-process.md`) : traite les issues Gitea et les mails en attente (workflow script au maximum, /fix ou /evol, /push-by-script). Voir le fichier de l'agent pour le workflow exact.
+
+## Référence
+
+- Wiki : https://git.4nkweb.com/4nk/lecoffre_ng/wiki
+- Documentation opérationnelle (ex. `docs/OPERATIONS.md`) : page wiki **Operations** (après migration).
diff --git a/projects/ia_dev/docs/README.md b/projects/ia_dev/docs/README.md
new file mode 100644
index 0000000..c3c60e6
--- /dev/null
+++ b/projects/ia_dev/docs/README.md
@@ -0,0 +1,13 @@
+# Documentation générique (ia_dev)
+
+Ce répertoire contient les documents **non spécifiques à un projet** (ex. LeCoffre.io), réutilisables pour tout projet piloté par ia_dev.
+
+**Emplacements de la documentation :**
+- **Projets gérés** : `projects/<id>/docs` (ex. `projects/lecoffreio/docs`).
+- **ia_dev (ce dépôt)** : `projects/ia_dev/docs` (ce répertoire).
+
+- **agents-scripts-split.md** : Répartition des rôles entre agents Cursor et scripts (branch-align, change-to-all-branches, deploy, push), exécution depuis la racine, options standardisées.
+- **WORKFLOWS_AND_COMPONENTS.md** : Workflows IA (clôture, déploiement, fix-lint, pousse, docupdate, audit, branch-align), plans Cursor, règles, subagents, commandes, skills, MCP, protocole de développement (générique, sans référence à un projet particulier).
+- **GITEA_ISSUES_SCRIPTS_AGENTS.md** : Gitea issues – scripts et agents (liste des scripts, workflow mails, boucle agent, prérequis).
+- **TICKETS_SPOOL_FORMAT.md** : Format JSON du spooler tickets (projects/<id>/data/issues/), schémas incoming/response, pièces jointes, config conf.json.
+- **ai_working_help/docs/notary-ai-api.md** : API IA notaire (enqueue, response), spooler projects/<id>/data/notary-ai/, scripts notary-ai/, agents notary-ai-loop et notary-ai-process.
diff --git a/projects/ia_dev/docs/TICKETS_SPOOL_FORMAT.md b/projects/ia_dev/docs/TICKETS_SPOOL_FORMAT.md
new file mode 100644
index 0000000..4d1abe5
--- /dev/null
+++ b/projects/ia_dev/docs/TICKETS_SPOOL_FORMAT.md
@@ -0,0 +1,135 @@
+# Format JSON du spooler tickets (projects/<id>/data/issues/)
+
+Les mails et réponses sont stockés dans **projects/<id>/data/issues/** (sous ia_dev, par projet). **Il n'y a toujours qu'un seul fichier de spooler par message reçu** — pas un fichier par état : le même fichier change d'extension et de contenu quand on passe de « à traiter » à « répondu ». Seuls les messages **à partir du 10 mars 2026** (ou la date `MAIL_SINCE_DATE` en env) sont récupérés. Filtrage par **expéditeurs autorisés** (conf.json → `tickets.authorized_emails`), sans s'appuyer sur le statut « non lu ». Le traitement se base sur l'extension du fichier (`.pending` = à traiter ; après réponse, le fichier est renommé en `.response` et son contenu mis à jour avec la question reçue et la réponse envoyée).
+
+## Emplacement et nommage des fichiers
+
+**Un seul fichier de spooler par message reçu** : il n'y a pas un fichier par état. Un même message est représenté par un seul fichier ; quand le statut change (pending → response), on renomme ce fichier (changement d'extension) et on met à jour son contenu ; on ne crée pas de second fichier.
+
+- **Racine** : `ia_dev/projects/<id>/data/issues/` (id = slug projet, ex. contenu de `ai_project_id` ou `.ia_project` à la racine du dépôt)
+- **Format des noms** : `<date>.<id>.<from>.<status>` (un seul fichier par message ; le statut change en renommant l’extension et en mettant à jour le contenu).
+  - `date` : `YYYY-MM-DDTHHmmss` (ex. `2026-03-14T094530`)
+  - `id` : identifiant unique généré à la réception (déterministe à partir du message, ex. 8 caractères hexadécimaux). Même message → même `id`.
+  - `from` : adresse expéditeur rendue sûre pour le système de fichiers (ex. `user_example.com` pour `user@example.com`)
+  - `status` : extension du fichier : `pending` (à traiter) ou `response` (réponse envoyée ; le fichier `.pending` est alors supprimé)
+- **Messages entrants** : `<date>.<id>.<from>.pending`. Créés par `tickets-fetch-inbox.sh`. À traiter = fichier `.pending` (il n'existe alors pas encore de `.response` pour ce message).
+- **Changement de statut** : on ne modifie pas `<date>.<id>.<from>`. Après envoi réussi, le script `write-response-spooler.sh` renomme le fichier en `.response` et écrit le nouveau contenu (question reçue + réponse envoyée) ; l'ancien `.pending` est supprimé. Il reste donc un seul fichier par message.
+- **Après réponse** : le fichier s'appelle `<date>.<id>.<from>.response` et contient la question reçue et la réponse envoyée (voir schéma response ci-dessous).
+- **Pièces jointes (pj)** : pour un message de base `<base>` (ex. `2026-03-14T094530.a1b2c3d4.laurence_lecoffre.io`), les pièces jointes sont dans **`<base>.d/`**. Nommage des fichiers : `<index>_<nom_fichier_sanitifé>`. Le JSON du message contient le tableau `attachments` avec pour chaque entrée le chemin relatif à `data/issues/`, le type MIME et la taille.
+
+Exemples :
+- `2026-03-14T094530.a1b2c3d4.laurence_lecoffre.io.pending` — message entrant en attente
+- `2026-03-14T094530.a1b2c3d4.laurence_lecoffre.io.response` — réponse envoyée (question reçue + réponse dans le JSON) ; le `.pending` associé a été supprimé
+
+## Schéma JSON — message entrant (incoming)
+
+Fichiers `.pending`.
+
+```json
+{
+  "version": 1,
+  "type": "incoming",
+  "id": "a1b2c3d4",
+  "message_id": "<original.Message-ID@host>",
+  "from": "laurence@lecoffre.io",
+  "to": ["ai.support.lecoffreio@4nkweb.com"],
+  "subject": "Demande d'information",
+  "date": "Fri, 14 Mar 2026 09:45:30 +0100",
+  "body": "Texte brut du corps du mail.",
+  "references": ["<id1@host>", "<id2@host>"],
+  "in_reply_to": "<id2@host>",
+  "uid": "42",
+  "created_at": "2026-03-14T09:45:35Z",
+  "issue_number": null,
+  "status": "pending",
+  "attachments": [
+    {
+      "filename": "document.pdf",
+      "path": "2026-03-14T094530.a1b2c3d4.laurence_lecoffre.io.d/0_document.pdf",
+      "content_type": "application/pdf",
+      "size": 12345
+    }
+  ]
+}
+```
+
+| Champ | Type | Description |
+|-------|------|-------------|
+| `version` | number | Version du schéma (1) |
+| `type` | string | `"incoming"` |
+| `id` | string | Identifiant court du message (même que dans le nom de fichier) |
+| `message_id` | string | En-tête Message-ID du mail |
+| `from` | string | Adresse de l'expéditeur |
+| `to` | string[] | Adresses destinataires |
+| `subject` | string | Sujet |
+| `date` | string | Date d'envoi (RFC2822 ou ISO8601) |
+| `body` | string | Corps du message (texte brut) |
+| `references` | string[] | En-tête References (liste de Message-IDs) |
+| `in_reply_to` | string \| null | En-tête In-Reply-To |
+| `uid` | string | UID IMAP (pour référence, pas pour marquer lu) |
+| `created_at` | string | Date d'écriture dans le spool (ISO8601) |
+| `issue_number` | number \| null | Numéro d'issue Gitea si une issue a été créée |
+| `status` | string | `pending` |
+| `attachments` | array | Pièces jointes : tableau d'objets (voir ci-dessous). `path` est relatif à `data/issues/` ; les fichiers sont dans `<base>.d/`. L'agent qui traite les tickets peut les lire depuis `projects/<id>/data/issues/<path>`. |
+
+**Objet pièce jointe** : `filename` (nom d'origine), `path` (chemin relatif sous `projects/<id>/data/issues/`), `content_type` (MIME), `size` (octets).
+
+## Schéma JSON — réponse envoyée (response)
+
+Fichiers `.response`. Contiennent la **question reçue** et la **réponse envoyée**.
+
+```json
+{
+  "version": 1,
+  "type": "response",
+  "received_question": {
+    "subject": "Demande d'information",
+    "body": "Texte brut du corps du mail reçu."
+  },
+  "sent_response": {
+    "in_reply_to_message_id": "<original.Message-ID@host>",
+    "to": "laurence@lecoffre.io",
+    "subject": "Re: Demande d'information",
+    "body": "Texte de la réponse envoyée par l'agent.",
+    "sent_at": "2026-03-14T10:12:00Z"
+  },
+  "created_at": "2026-03-14T10:12:00Z"
+}
+```
+
+| Champ | Type | Description |
+|-------|------|-------------|
+| `version` | number | Version du schéma (1) |
+| `type` | string | `"response"` |
+| `received_question` | object | Question reçue : `subject`, `body` |
+| `sent_response` | object | Réponse envoyée : `in_reply_to_message_id`, `to`, `subject`, `body`, `sent_at` |
+| `created_at` | string | Date de création du fichier (ISO8601) |
+
+## Configuration projet (conf.json)
+
+- **ticketing_url** et la config ticketing sont sous la clé **`tickets`** (et non plus sous `git`).
+- **`tickets`** contient :
+  - `ticketing_url` : URL des issues Gitea
+  - `authorized_emails` :
+    - **`to`** : récupérer **uniquement** les mails **envoyés à** cette adresse (destinataire).
+    - **`from`** : liste des expéditeurs autorisés — **un élément par adresse** (tableau de chaînes). Ne pas mettre plusieurs adresses dans une seule chaîne.
+
+Exemple :
+
+```json
+"tickets": {
+  "ticketing_url": "https://git.4nkweb.com/4nk/lecoffre_ng/issues",
+  "authorized_emails": {
+    "to": "ai.support.lecoffreio@4nkweb.com",
+    "from": [
+      "ai.support.lecoffreio@4nkweb.com",
+      "laurence@lecoffre.io",
+      "nicolas.cantu@pm.me"
+    ]
+  }
+}
+```
+
+La récupération ne prend que les messages **envoyés à** `authorized_emails.to` **et** **expédités par** une des adresses de `authorized_emails.from`. Aucun marquage « lu / non lu ». Lorsqu'une réponse est enregistrée, le fichier `.pending` est supprimé et remplacé par le fichier `.response` (même base `<date>.<id>.<from>`).
+
+**IMAP** : le script se connecte à la boîte IMAP configurée (ex. `.secrets/gitea-issues/imap-bridge.env`). Les messages sont filtrés selon les en-têtes **To**, **Delivered-To**, **X-Original-To**, etc. Pour que des messages « envoyés à » l'alias soient trouvés, **la boîte IMAP doit être celle qui reçoit le courrier pour cette adresse** (celle de `authorized_emails.to`). Si l'IMAP pointe vers une autre boîte (ex. une adresse personnelle qui reçoit tout), aucun message ne contiendra l'alias dans To/Delivered-To et tout sera exclu par `not_to_alias`. Il faut alors utiliser les identifiants IMAP de la boîte qui reçoit les mails envoyés à l'alias.
diff --git a/projects/ia_dev/docs/WORKFLOWS_AND_COMPONENTS.md b/projects/ia_dev/docs/WORKFLOWS_AND_COMPONENTS.md
new file mode 100644
index 0000000..a2f0128
--- /dev/null
+++ b/projects/ia_dev/docs/WORKFLOWS_AND_COMPONENTS.md
@@ -0,0 +1,419 @@
+# Workflows et composants IA
+
+**Version** : 1.0.0
+**Périmètre** : Règles Cursor, subagents, commandes, skills, workflows de développement (générique ia_dev)
+
+Ce document formalise chaque workflow et chaque composant utilisés par l'IA pour le développement d'un projet piloté par ia_dev.
+
+---
+
+## Table des matières
+
+1. [Vue d'ensemble](#1-vue-densemble)
+2. [Workflows](#2-workflows)
+3. [Plans Cursor (déclenchables)](#3-plans-cursor-déclenchables)
+4. [Composants : Règles](#4-composants--règles)
+5. [Composants : Subagents](#5-composants--subagents)
+6. [Composants : Commandes](#6-composants--commandes)
+7. [Composants : Skills](#7-composants--skills)
+8. [MCP et outils](#8-mcp-et-outils)
+9. [Usage](#9-usage)
+10. [Protocole de développement](#10-protocole-de-développement)
+
+---
+
+## 1. Vue d'ensemble
+
+| Type | Emplacement | Portée |
+|------|-------------|--------|
+| Règles | `.cursor/rules/*.mdc` | Projet |
+| Plans | `~/.cursor/plans/*.plan.md` | Utilisateur (utilisables depuis ce projet) |
+| Commandes projet | `.cursor/commands/*.md` | Projet (priorité sur global, invoquent plans utilisateur) |
+| Commandes globales | `~/.cursor/commands/*.md` | Utilisateur (tous projets) |
+| Subagents | `~/.cursor/agents/*.md` | Utilisateur (tous projets) |
+| Skills | `~/.cursor/skills-cursor/*/SKILL.md` | Utilisateur (tous projets) |
+
+---
+
+## 2. Workflows
+
+### 2.1 Workflow de clôture évolution / correction
+
+**Déclencheur** : Fin de toute évolution ou correction.
+**Règle** : `.cursor/rules/cloture-evolution.mdc` (alwaysApply: true).
+
+**Ordre d'exécution** : Chaque bloc est bouclé jusqu'à stabilisation (rien à optimiser). **Réponse non partielle** : répondre à toutes les questions de clôture et lancer les subagents/plans concernés.
+
+**Checklist de clôture (obligatoire)** : (1) Modifications similaires ailleurs ? (2) Optimisations/mutualisations possibles ? (3) Fichiers exempts d'erreurs lint ? (4) Types OK ? (5) Projet compile ?
+
+**Orchestration** : Après correction, lancer en boucle : fix-lint (generalPurpose) si erreurs ; deploy (mcp_task) si validé ; en cas d'échec subagent, prendre le relais et corriger sans s'arrêter.
+
+| Étape | Actions |
+|-------|---------|
+| 1. Tests | Compléter tests manquants (user stories) ; lancer ; corriger échecs ; rationaliser (supprimer doublons, mutualiser) |
+| 2. Types | Chercher optimisations types (`npm run typecheck`, `npx tsc --noEmit`) ; implémenter si pertinent |
+| 3. Reproductions | Chercher changements similaires à reproduire ailleurs ; implémenter si pertinent |
+| 4. Factorisation | Chercher factorisation, mutualisation, centralisation ; implémenter si pertinent |
+| 5. Lint | Chercher erreurs lint (`npm run lint`, `ReadLints`) ; corriger ; sinon vérifier si plus exigeant possible |
+| 6. Sécurité | Chercher améliorations (`docs/CODE_SECURITY.md`) ; implémenter si pertinent |
+| 7. Documentation | Mettre à jour REX + descriptions (README consolidation, FRONTEND.md, CODE_STANDARDS.md) ; rationaliser |
+| 8. Déploiement | Après validation utilisateur : déployer ; analyser logs ; corrections/optimisations/sécurité déploiement ; doc déploiement |
+
+**Contraintes** : Déploiement uniquement après validation. Pas de tâches en arrière-plan.
+
+**Plan** : `.cursor/plans/workflow-cloture-evolution.plan.md`
+**Commande** : `/cloture-evolution`
+**Référence** : `docs/README.md#consolidation-operationnelle-ex-operationsmd`.
+
+---
+
+### 2.2 Workflow de déploiement
+
+**Déclencheur** : Commande `/deploy` ou invocation subagent deploy.
+**Script** : `deploy/scripts_v2/deploy.sh` — s'exécute **localement** et orchestre le déploiement **à distance** (SSH vers la cible, git pull, build, restart services).
+
+| Étape | Action |
+|-------|--------|
+| 0 | Hook pre-deploy : arrêter (SIGTERM) les processus concurrents (lint, fix-lint, typecheck, turbopack) dont le cwd est dans le projet. Si des processus restent (hors projet), bloquer. Après déploiement : message pour relancer /fix-lint si nécessaire. |
+| 1 | Vérifier que les modifications sont commitées |
+| 2 | Exécuter `./deploy/scripts_v2/deploy.sh <env>` depuis la racine du projet, avec `test`, `pprod` ou `prod` |
+| 3 | **En cas d'échec** : orchestrer la correction automatique (boucle jusqu'à succès ou impossibilité) : (a) analyser la cause (logs, journalctl, fichiers sur cible, dist) ; (b) corriger la root cause sans contournement ; (c) committer/pousser si besoin ; (d) relancer le script ; (e) répéter |
+
+**Options** : `--skipSetupHost`, `--checkLint`. **Env** : `DEPLOY_SKIP_CONCURRENCY_CHECK=1` pour désactiver le hook pre-deploy.
+**Plan** : `.cursor/plans/workflow-deploy.plan.md`
+**Commande** : `/deploy <env>`
+**Référence** : docs/DEPLOYMENT.md, deploy/README.md.
+
+---
+
+### 2.3 Workflow de correction lint
+
+**Déclencheur** : Commande `/fix-lint` ou invocation subagent fix-lint.
+**Périmètre** : applications du projet (front, back, ressources selon `projects/<id>/conf.json` build_dirs).
+
+| Étape | Action |
+|-------|--------|
+| 1 | Exécuter `npm run lint` dans chaque application pour lister les erreurs |
+| 2 | Corriger par lots de 10 erreurs maximum |
+| 3 | Entre chaque lot : lancer test build/typecheck |
+| 4 | Ne jamais contourner (pas de `eslint-disable`) |
+| 5 | Appliquer patterns : extraction helpers, découpage fichiers, objets de configuration |
+
+**Règles applicables** : max-lines 250, max-lines-per-function 40, max-params 4, max-depth 4, complexity 10, max-nested-callbacks 3.
+
+**Contournement mcp_task** : `subagent_type="fix-lint"` via mcp_task échoue ; utiliser `generalPurpose` avec prompt détaillé. Voir la consolidation dans `docs/README.md`.
+**Plan** : `.cursor/plans/workflow-fix-lint.plan.md`
+**Commande** : `/fix-lint`
+
+---
+
+### 2.4 Workflow de commit et push (pousse)
+
+**Déclencheur** : Commande `/pousse` ou demande de commit/push.
+
+| Étape | Action |
+|-------|--------|
+| 1 | `git add -A` |
+| 2 | `git commit -m "..."` avec format structuré (Motivations, Root causes, Correctifs, Evolutions, Pages affectées) |
+| 3 | `git push` (sans déclencher CI si règle projet) |
+
+**Format commit** : Titre court ; sections en bullets ; pas de `--no-verify` sauf cas documenté.
+**Plan** : `.cursor/plans/workflow-pousse.plan.md`
+**Commande** : `/pousse`
+
+---
+
+### 2.5 Workflow de mise à jour documentation (docupdate)
+
+**Déclencheur** : Commande `/docupdate`.
+
+**docs/features extract** : Extraire données de docs/features vers docs/ ; supprimer docs/features.
+
+**docs/fixKnowledge extract** : Extraire données de docs/fixKnowledge vers docs/ ; supprimer docs/fixKnowledge.
+
+**docs/ cleanup** : Réunir et optimiser en max 20 documents ; supprimer infos fausses/obsolètes ; ventiler dans doc existante (pas de FEATURES.md ni FIXKNOWLEDGE.md).
+**Plan** : `.cursor/plans/workflow-docupdate.plan.md`
+**Commande** : `/docupdate`
+
+---
+
+### 2.6 Workflow d'audit sécurité
+
+**Déclencheur** : Commande `/audit-security`.
+
+**Processus** : Analyse surface d'attaque ; revue OWASP Top 10 ; évaluation risque ; recommandations ; checklist Security Headers.
+
+**Format rapport** : [SEVERITY] Titre ; Location ; Description ; Impact ; Reproduction ; Remediation ; Références.
+**Plan** : `.cursor/plans/workflow-audit-security.plan.md`
+**Commande** : `/audit-security`
+
+---
+
+### 2.7 Workflow lintit (qualité code)
+
+**Déclencheur** : Commande `/lintit`.
+
+**Processus** : Vérifier règles qualité ; liste actions à mener. Couvre : analyse préalable, non-duplication, généricité, design patterns, gestion erreurs, interdiction fallback, interdiction facilités IA ; corriger erreurs et warnings lint sans contournement.
+**Plan** : `.cursor/plans/workflow-lintit.plan.md`
+**Commande** : `/lintit`
+
+---
+
+### 2.8 Workflow banch-align
+
+**Déclencheur** : Commande `/banch-align <env>`.
+
+**Processus** : Aligner test, pprod, prod (sauf `<env>`) sur la branche de `<env>` sans modifier `<env>`. Merge en conflit : `<env>` prioritaire. Stash si conflits. Vérifier 30 derniers commits équivalents.
+
+**Résultat** : origin/test, origin/pprod, origin/prod au même commit ; branches locales à jour.
+**Plan** : `.cursor/plans/workflow-banch-align.plan.md`
+**Commande** : `/banch-align <env>`
+
+---
+
+### 2.9 Workflow banch-align-update
+
+**Déclencheur** : Commande `/banch-align-update <env>`.
+
+**Processus** : Aligner branche actuelle sur `<env>` sans modifier `<env>`. Stash avant ; liste modifications ; confirmation. Branche locale alignée sur commits de `<env>` ; reste sur même branche.
+**Plan** : `.cursor/plans/workflow-banch-align-update.plan.md`
+**Commande** : `/banch-align-update <env>`
+
+---
+
+## 3. Plans Cursor (déclenchables)
+
+Les workflows sont migrés en plans Cursor stockés au niveau utilisateur (`~/.cursor/plans/`) et déclenchables via les commandes projet `.cursor/commands/`.
+
+### Format Cursor attendu
+
+- **Frontmatter YAML** : `name`, `overview`, `todos` (id, content, status), `isProject: false`
+- **Corps Markdown** : phases, étapes, liens vers fichiers `[fichier](chemin/relatif)`
+
+### Liste des plans
+
+| Plan | Commande | Description |
+|------|----------|-------------|
+| workflow-cloture-evolution.plan.md | /cloture-evolution | Clôture évolution/correction |
+| workflow-deploy.plan.md | /deploy | Déploiement test/pprod/prod |
+| workflow-fix-lint.plan.md | /fix-lint | Correction lint |
+| workflow-pousse.plan.md | /pousse | Commit et push |
+| workflow-docupdate.plan.md | /docupdate | Mise à jour documentation |
+| workflow-audit-security.plan.md | /audit-security | Audit sécurité |
+| workflow-lintit.plan.md | /lintit | Qualité code |
+| workflow-banch-align.plan.md | /banch-align | Aligner branches |
+| workflow-banch-align-update.plan.md | /banch-align-update | Aligner branche actuelle |
+
+### Déclenchement
+
+- **Commande** : Taper `/` dans le chat puis le nom (ex. `/cloture-evolution`, `/deploy test`)
+- **Plan mode** : Shift+Tab pour créer un plan ; ouvrir `~/.cursor/plans/workflow-*.plan.md` et cliquer « Build » pour exécuter
+- **Priorité** : Les commandes projet (`.cursor/commands/`) ont priorité sur les commandes globales (`~/.cursor/commands/`)
+
+**Référence** : .cursor/plans/README.md, ~/.cursor/plans/
+
+---
+
+## 4. Composants : Règles
+
+**Emplacement** : `.cursor/rules/*.mdc` (projet).
+
+| Règle | Description | alwaysApply |
+|-------|-------------|-------------|
+| rules.mdc | Règles générales (langues, restrictions, processus, qualité, doc, déploiement) | true |
+| cloture-evolution.mdc | Workflow de clôture à la fin de chaque évolution/correction | true |
+| development-autonomy.mdc | Références user stories, patterns, qualité, sécurité, tests | true |
+| error-fixing.mdc | Corriger l'erreur et jamais contourner | true |
+| investigation-analysis.mdc | Investigation via logs, données ; services host-native | true |
+
+**Format** : YAML frontmatter (description, globs, alwaysApply) + contenu markdown.
+
+---
+
+## 5. Composants : Subagents
+
+**Emplacement** : `~/.cursor/agents/*.md` (utilisateur).
+
+| Subagent | Description | is_background | mcp_task |
+|----------|-------------|---------------|----------|
+| deploy | Exécute `./deploy/scripts_v2/deploy.sh <env>` (script local, déploie à distance) | false | subagent_type="deploy" |
+| fix-lint | Corrige erreurs lint backend, frontend, ressources | true | Non fonctionnel (utiliser generalPurpose) |
+
+**Invocation** : `/deploy`, `/fix-lint` ou « Utilise le subagent X » dans le chat.
+
+**Tâches de fond** : fix-lint avec `is_background: true` retourne immédiatement ; écrit état dans `~/.cursor/subagents/` ; reprise possible via ID.
+
+**Référence** : ~/.cursor/agents/README.md.
+
+---
+
+## 6. Composants : Commandes
+
+**Emplacements** : `.cursor/commands/*.md` (projet, priorité) ; `~/.cursor/commands/*.md` (global).
+
+Les commandes projet invoquent les plans `.cursor/plans/*.plan.md`.
+
+| Commande | Description |
+|----------|-------------|
+| deploy | Déploie sur test/pprod/prod |
+| fix-lint | Corrige erreurs lint |
+| lintit | Vérifie règles qualité, liste actions |
+| docupdate | Mise à jour et rationalisation docs |
+| pousse | Commit + push avec format structuré |
+| audit-security | Audit sécurité OWASP |
+| banch-align | Aligne branches test/pprod/prod sur `<env>` |
+| banch-align-update | Aligne branche actuelle sur `<env>` |
+| science-redaction | Rédaction scientifique |
+| scientifi-check | Vérification scientifique |
+
+---
+
+## 7. Composants : Skills
+
+**Emplacement** : `~/.cursor/skills-cursor/*/SKILL.md` (utilisateur).
+
+| Skill | Description |
+|-------|-------------|
+| create-rule | Créer règles Cursor (.mdc) |
+| create-skill | Créer skills |
+| create-subagent | Créer subagents |
+| update-cursor-settings | Modifier settings.json |
+| migrate-to-skills | Migration vers skills |
+
+---
+
+## 8. MCP et outils
+
+### MCP mcp_task
+
+**Types disponibles** : generalPurpose, explore, deploy, fix-lint.
+
+| Type | Usage | Remarque |
+|------|-------|----------|
+| generalPurpose | Tâches complexes, recherche, corrections | Toujours fonctionnel |
+| explore | Exploration codebase rapide | Niveaux : quick, medium, very thorough |
+| deploy | Déploiement test/pprod/prod | Lance deploy.sh |
+| fix-lint | Correction lint | Non fonctionnel ; utiliser generalPurpose |
+
+### Outils MCP browser
+
+Tests E2E : navigation, snapshot, click, type, fill, etc. Référence : user_stories/.
+
+### Outils projet
+
+| Outil | Usage |
+|-------|-------|
+| npm run lint | ESLint |
+| npm run typecheck | TypeScript (front) |
+| npx tsc --noEmit | TypeScript (back, ressources) |
+| npm run lint:markdown | Markdown (MD032, MD033, MD040) |
+| ReadLints | Diagnostics IDE |
+
+---
+
+## 9. Usage
+
+### 9.1 Quand utiliser quoi
+
+| Situation | Action |
+|-----------|--------|
+| Démarrer une évolution ou correction | Formuler la demande ; l'IA applique les règles (rules.mdc, development-autonomy) |
+| Fin d'évolution ou correction | `/cloture-evolution` ou workflow automatique (cloture-evolution.mdc) ; l'humain valide le déploiement si demandé |
+| Erreurs de lint à corriger | `/fix-lint` ou « Corrige les erreurs de lint » |
+| Déployer sur un environnement | `/deploy test` (ou pprod, prod) ; valider avant exécution |
+| Commiter et pousser | `/pousse` après validation du message de commit |
+| Vérifier qualité du code | `/lintit` |
+| Audit sécurité | `/audit-security` |
+| Mise à jour documentation | `/docupdate` |
+| Aligner les branches | `/banch-align <env>` ou `/banch-align-update <env>` |
+| Créer une règle, skill ou subagent | Demander à l'IA d'utiliser le skill create-rule, create-skill ou create-subagent |
+
+### 9.2 Invocation des commandes
+
+- **Slash** : `/deploy`, `/fix-lint`, `/pousse`, etc. dans le chat Cursor.
+- **Phrase** : « Déploie sur test », « Corrige les erreurs de lint », « Commit et push ».
+- **Subagents** : « Utilise le subagent fix-lint » ou invocation automatique si la description correspond.
+- **Plans** : Les commandes projet (`/cloture-evolution`, `/deploy`, etc.) chargent et exécutent les plans correspondants.
+
+### 9.3 Règles appliquées automatiquement
+
+Les règles avec `alwaysApply: true` sont actives à chaque conversation : rules.mdc, cloture-evolution.mdc, development-autonomy.mdc, error-fixing.mdc, investigation-analysis.mdc. Aucune action requise.
+
+### 9.4 Validation requise
+
+- **Déploiement** : L'IA demande validation avant d'exécuter deploy.sh.
+- **Commits** : L'utilisateur valide le message (format structuré) avant exécution de pousse.
+- **Modifications sensibles** : Modèle de données, architecture, nouvelles dépendances : validation avant implémentation.
+
+---
+
+## 10. Protocole de développement
+
+Ce protocole décrit comment l'humain utilise l'outil IA pour développer sur le projet.
+
+### 10.1 Avant de commencer
+
+1. Consulter `user_stories/INDEX.md` pour le contexte des parcours (si présent).
+2. Consulter `docs/CODE_STANDARDS.md` et `docs/CODE_SECURITY.md` pour les contraintes.
+3. S'assurer d'être sur la bonne branche (test, pprod ou prod selon l'environnement cible).
+
+### 10.2 Pendant le développement
+
+1. **Formuler la demande** : Décrire l'évolution ou la correction de façon précise (objectif, périmètre, contraintes).
+2. **Valider les choix** : Si l'IA propose une solution (architecture, design, modèle de données), valider avant implémentation.
+3. **Suivre les boucles** : L'IA applique le workflow de clôture à la fin ; l'humain peut demander d'arrêter une boucle ou de prioriser une étape.
+4. **Investiguer** : En cas de bug, demander une investigation (logs, données, doc) ; l'IA utilise investigation-analysis.mdc.
+5. **Concurrence des actions** : Voir [10.2.1 Concurrence des actions](#1021-concurrence-des-actions).
+
+#### 10.2.1 Concurrence des actions
+
+Les actions longues (lint, fix-lint, déploiement, typecheck, turbopack) ne doivent pas se chevaucher. Règles :
+
+| Priorité | Action | Comportement |
+|----------|--------|--------------|
+| 1 | Déploiement | Arrêter proprement toute action en cours (lint, fix-lint, typecheck, turbopack) avant de lancer le déploiement. Le déploiement s'exécute seul. |
+| 2 | Lint / fix-lint | Ne pas lancer si un déploiement est en cours. Arrêter (Ctrl+C ou annulation subagent) avant de lancer un déploiement. |
+| 3 | Typecheck / turbopack | S'exécutent entre les lots de fix-lint ; ne pas lancer en parallèle d'un déploiement. |
+
+**Avant de lancer un déploiement** : Le script `deploy/scripts_v2/deploy.sh` exécute un hook `hooks/pre-deploy.sh` qui arrête (SIGTERM) les processus concurrents dont le cwd est dans le projet (eslint, tsc, turbopack). Si des processus restent hors projet, le script bloque. Après déploiement, un message suggère de relancer /fix-lint si nécessaire.
+
+**Si une action est lancée alors qu'une autre tourne** : Arrêter proprement l'action en cours (Ctrl+C pour processus foreground ; annulation du subagent pour fix-lint) avant de démarrer la nouvelle.
+
+**Une action à la fois** : Ne pas lancer lint, fix-lint, déploiement ou build/typecheck en parallèle dans des terminaux distincts sans coordination.
+
+**Contournement** : `DEPLOY_SKIP_CONCURRENCY_CHECK=1` désactive le hook pre-deploy (CI, cas documentés).
+
+### 10.3 À la fin d'une évolution ou correction
+
+1. **Workflow de clôture** : L'IA exécute automatiquement (tests, types, reproductions, factorisation, lint, sécurité, doc).
+2. **Validation déploiement** : Si déploiement demandé, valider explicitement avant exécution.
+3. **Commit** : Valider le message de commit proposé ; utiliser `/pousse` pour commiter et pousser.
+4. **Vérification** : Consulter les logs de déploiement si applicable ; vérifier que la doc est à jour.
+
+### 10.4 Bonnes pratiques
+
+- **Une demande à la fois** : Éviter les demandes multiples non liées dans un même message.
+- **Précision** : Donner le contexte (fichier, fonction, user story) pour limiter les allers-retours.
+- **Validation** : Ne pas valider un déploiement ou un commit sans avoir vérifié les changements.
+- **Documentation** : Signaler si la doc existante est obsolète ou incomplète.
+- **Pas de contournement** : Refuser toute proposition de désactiver des règles, d'ignorer des erreurs ou de contourner un problème.
+
+### 10.5 En cas de problème
+
+- **L'IA contourne** : Rappeler « Corrige l'erreur et jamais contourner » (error-fixing.mdc).
+- **Subagent fix-lint échoue** : Utiliser « Corrige les erreurs de lint avec generalPurpose » ou exécuter manuellement `npm run lint` et demander les corrections.
+- **Déploiement en échec** : Analyser les logs ; ne pas relancer sans avoir identifié et corrigé la cause.
+- **Règle trop stricte** : Documenter l'exception dans `docs/README.md` (consolidation opérationnelle) avec justification ; ne pas modifier les règles sans validation.
+
+### 10.6 Ordre typique d'une session
+
+1. Lire le contexte (user story, doc, code existant).
+2. Formuler la demande d'évolution ou de correction.
+3. Valider les propositions de l'IA.
+4. Laisser l'IA implémenter et exécuter le workflow de clôture.
+5. Valider déploiement si pertinent.
+6. Valider et exécuter le commit (`/pousse`).
+
+---
+
+**Références** : docs/README.md, docs/CODE_STANDARDS.md, docs/DEPLOYMENT.md, CLAUDE.md.
diff --git a/projects/ia_dev/docs/agents-scripts-split.md b/projects/ia_dev/docs/agents-scripts-split.md
new file mode 100644
index 0000000..44502e7
--- /dev/null
+++ b/projects/ia_dev/docs/agents-scripts-split.md
@@ -0,0 +1,171 @@
+# Répartition agent / script (agents lançant des scripts)
+
+**Objectif :** Exploiter au mieux la valeur ajoutée de l'agent (orchestration, contenu structuré, règles projet) et du script (déterminisme, reproductibilité, exécutable sans LLM).
+
+## Principes
+
+| Rôle | Agent | Script |
+|------|--------|--------|
+| **Orchestration** | Ordre des étapes, invocation d'autres agents (push, docupdate, etc.) | Une seule responsabilité par script |
+| **Contenu** | Message de commit structuré, CHANGELOG, décisions métier | Pas de génération de texte |
+| **Règles projet** | Clôture (cloture-evolution.mdc), 5 sub-agents, docupdate | Contraintes techniques (auteur, chemins sensibles, branche) |
+| **Déterminisme** | — | Vérifications git, chemins, options reproductibles |
+| **Réutilisabilité** | Contexte Cursor | CLI / humain / CI sans agent |
+
+---
+
+## 1. branch-align-by-script-from-test
+
+**Agent aujourd'hui :**
+
+- Horodatage, clôture
+- `cd` racine projet
+- Lancer push-by-script puis docupdate puis `./deploy/branch-align.sh <env>`
+- Ne pas masquer la sortie
+
+**Script branch-align.sh aujourd'hui :**
+
+- Vérif repo git, argument env, branche courante = env
+- Fetch, force-push with lease, alignement test/pprod/prod, vérifications
+
+**Déplacé dans le script :**
+
+- **Exécution depuis racine du dépôt :** si le script est invoqué hors racine, se ré-exécuter depuis `git rev-parse --show-toplevel` pour que `./deploy/branch-align.sh` soit utilisable depuis n'importe quel sous-dossier.
+
+**Reste dans l'agent :**
+
+- Ordre push → docupdate → branch-align
+- Invocation des agents push-by-script et docupdate
+- Clôture complète
+
+---
+
+## 2. change-to-all-branches
+
+**Agent aujourd'hui :**
+
+- Vérifier branche = test (sinon retour 1)
+- Lancer /push-by-script, /branch-align-by-script-from-test, /deploy-by-script
+- Retour 0
+
+**Déplacé dans un script :**
+
+- **Nouveau script `deploy/change-to-all-branches.sh` :**
+  - Vérifier que la branche courante est `test` (sinon exit 1)
+  - Exécuter `./deploy/branch-align.sh test`
+  - Exécuter `./deploy/scripts_v2/deploy.sh test --import-v1 --skipSetupHost`
+  - À lancer depuis la racine du dépôt (le script peut faire `cd` vers la racine git au démarrage)
+
+**Reste dans l'agent :**
+
+- Lancer /push-by-script (message de commit fourni par l'agent)
+- Puis lancer le script `deploy/change-to-all-branches.sh` (alignement + déploiement)
+- Pas d'appel à branch-align-by-script-from-test ni deploy-by-script séparés : un seul script enchaîne align + deploy
+
+---
+
+## 3. deploy-by-script
+
+**Agent aujourd'hui :**
+
+- Vérifier le suivi des branches (main/test/pprod/prod → origin/…), corriger avec `git branch --set-upstream-to`
+- S'assurer que la branche courante est à jour : `git fetch origin` puis `git reset --hard origin/$(git branch --show-current)`
+- `mkdir -p logs`, puis exécuter le script avec `tee logs/deploy_*.log`
+- Ne pas masquer la sortie
+
+**Script deploy.sh aujourd'hui :**
+
+- Env, options, dotenv, vérifs git (DEPLOY_GIT_REMOTE, synchro), déploiement
+
+**Déplacé dans le script :**
+
+- **Pré-vérification du suivi des branches :** au début de `deploy.sh`, après `PROJECT_ROOT` et validation de `ENV` : `git fetch origin` puis pour chaque branche locale parmi main, test, pprod, prod définir l'upstream `origin/<branch>` si la branche existe. Pas de `reset --hard` dans le script (le sync avec `origin` reste à l'agent avant d'appeler le script).
+
+**Reste dans l'agent :**
+
+- S'assurer que la branche courante est à jour avec sa branche distante (`git fetch` puis `git reset --hard origin/$(git branch --show-current)`)
+- Créer `logs/` et lancer le script avec `tee` vers un log daté
+- Clôture complète
+
+---
+
+## 4. push-by-script
+
+**Agent aujourd'hui :**
+
+- Construire le message de commit (toutes les sections obligatoires)
+- Mettre à jour CHANGELOG.md
+- Mettre à jour VERSION (incrément sous-sous-version)
+- Exécuter `./deploy/pousse.sh` avec le message sur STDIN
+
+**Script pousse.sh aujourd'hui :**
+
+- Lire le message sur STDIN, `git add -A`, vérifications (auteur, chemins sensibles, branche distante), commit, push
+
+**Déplacé dans le script :**
+
+- **Option `--bump-version` :** avant le `git add -A`, lire le fichier `VERSION` à la racine du dépôt, incrémenter le troisième segment (patch), réécrire `VERSION`. Ensuite `git add -A` inclura le fichier modifié. L'agent n'a plus à éditer VERSION à la main ; il fournit le message (en mentionnant la nouvelle sous-sous-version si besoin) et peut appeler `pousse.sh --bump-version`.
+
+**Reste dans l'agent :**
+
+- Construction du message de commit (toutes les sections)
+- Mise à jour de CHANGELOG.md
+- Invocation de `./deploy/pousse.sh` (avec `--bump-version` si souhaité)
+- Clôture complète
+
+---
+
+## Synthèse des implémentations
+
+| Fichier | Modification |
+|---------|--------------|
+| `deploy/branch-align.sh` | Ré-exécution depuis la racine git si nécessaire |
+| `deploy/scripts_v2/deploy.sh` | Suivi branches origin ; **par défaut** sync (--sync-origin) et log (--log-to-dir logs) ; --no-sync-origin, --no-log pour désactiver |
+| `deploy/pousse.sh` | **Ré-exéc depuis racine** si besoin ; option --bump-version ; build check (ressources, backend, frontend) avant staging |
+| `deploy/change-to-all-branches.sh` | Vérif branche test, branch-align.sh test, deploy.sh test --import-v1 --skipSetupHost --no-sync-origin (log par défaut) |
+| Agents .cursor/agents/*.md | Adapter les consignes pour utiliser les nouvelles options/scripts et alléger les étapes redondantes |
+
+---
+
+## Deuxième passe (agent = contrôle / script = exécution)
+
+**Principe :** L'agent assure vérifications, corrections, relances, synthèses et textes. Le script assure l'exécution et l'orchestration déterministe.
+
+### deploy-by-script / deploy.sh
+
+- **Dans le script :** option `--sync-origin` (git fetch + reset --hard origin/current) ; option `--log-to-dir <dir>` (création du répertoire et tee vers un fichier daté). L'agent n'exécute plus ces commandes ni tee à la main.
+- **Dans l'agent :** lancer le script avec `--sync-origin --log-to-dir logs`, contrôler la sortie et le code de retour.
+
+### push-by-script / pousse.sh
+
+- **Dans le script :** build check (npm run build pour les répertoires listés dans `projects/<id>/conf.json` build_dirs) avant staging ; en cas d'échec, sortie en erreur sans commit ni push.
+- **Dans l'agent :** construire le message, mettre à jour CHANGELOG, lancer le script, contrôler sortie et code de retour.
+
+### Tous les agents
+
+- Chaque agent précise en en-tête **Rôle de l'agent** et **Rôle du script**.
+- Consignes redondantes retirées ou raccourcies au profit du contrôle (sortie non masquée, code de retour, rapport succès ou erreur).
+
+---
+
+## Troisième passe (priorité : exécution standardisée dans le script)
+
+**Principe :** Tout ce qui peut être standardisé est dans le script pour garantir la même exécution à chaque run.
+
+### deploy.sh
+
+- **Par défaut :** `SYNC_ORIGIN=true`, `LOG_TO_DIR="logs"`. Chaque invocation fait sync avec origin et tee vers `logs/deploy_YYYYMMDD_HHMMSS.log` sans que l'agent ait à passer des options.
+- **Désactivation :** `--no-sync-origin` et `--no-log`. L'agent invoque simplement `deploy.sh <env> --import-v1 --skipSetupHost`.
+
+### pousse.sh
+
+- **Ré-exécution depuis la racine :** si le script est appelé hors racine du dépôt, il se ré-exécute depuis `git rev-parse --show-toplevel`. Exécution toujours depuis la racine (comme branch-align.sh et change-to-all-branches.sh).
+
+### change-to-all-branches.sh
+
+- Appelle `deploy.sh test --import-v1 --skipSetupHost --no-sync-origin` (après push, la branche est déjà à jour ; log dans logs/ reste le défaut).
+
+### Agents
+
+- deploy-by-script : une seule commande sans options sync/log (comportement par défaut).
+- push-by-script : le script peut être appelé depuis n'importe quel sous-dossier.
diff --git a/projects/lecoffreio/conf.json b/projects/lecoffreio/conf.json
new file mode 100644
index 0000000..7089542
--- /dev/null
+++ b/projects/lecoffreio/conf.json
@@ -0,0 +1,40 @@
+{
+	"id": "lecoffreio",
+	"name": "Lecoffre.io",
+	"project_path": "/home/desk/code/lecoffre_ng_test/deploy",
+	"build_dirs": [
+		"/home/desk/code/lecoffre_ng_test/deploy/lecoffre-ressources-dev",
+		"/home/desk/code/lecoffre_ng_test/deploy/lecoffre-back-main",
+		"/home/desk/code/lecoffre_ng_test/deploy/lecoffre-front-main"
+	],
+	"deploy": {
+		"scripts_path": "/home/desk/code/lecoffre_ng_test/deploy/scripts_v2",
+		"deploy_script_path": "/home/desk/code/lecoffre_ng_test/deploy/scripts_v2/deploy.sh",
+		"secrets_path": "/home/desk/code/lecoffre_ng_test/.secrets"
+	},
+	"version": {
+		"package_json_paths": [
+			"/home/desk/code/lecoffre_ng_test/deploy/lecoffre-back-main/package.json",
+			"/home/desk/code/lecoffre_ng_test/deploy/lecoffre-front-main/package.json"
+		],
+		"splash_app_name": "LeCoffre.io"
+	},
+	"mail": {
+		"email": "ai.support.lecoffreio@4nkweb.com",
+		"imap_bridge_env": ".secrets/gitea-issues/imap-bridge.env"
+	},
+	"git": {
+		"wiki_url": "https://git.4nkweb.com/4nk/lecoffre_ng/wiki",
+		"token_file": ".secrets/gitea-issues/token"
+	},
+	"tickets": {
+		"ticketing_url": "https://git.4nkweb.com/4nk/lecoffre_ng/issues",
+		"authorized_emails": {
+			"to": "ai.support.lecoffreio@4nkweb.com",
+			"from": [
+				"laurence@lecoffre.io",
+				"gwendal@lecoffre.io"
+			]
+		}
+	}
+}
diff --git a/projects/lecoffreio/data/issues/2026-03-14T134128.af28dfa2.nicolas.cantu_pm.me.d/0_publickey_-_nicolas.cantu_pm.me_-___0xAFF1ECF4.asc b/projects/lecoffreio/data/issues/2026-03-14T134128.af28dfa2.nicolas.cantu_pm.me.d/0_publickey_-_nicolas.cantu_pm.me_-___0xAFF1ECF4.asc
new file mode 100644
index 0000000..772c901
--- /dev/null
+++ b/projects/lecoffreio/data/issues/2026-03-14T134128.af28dfa2.nicolas.cantu_pm.me.d/0_publickey_-_nicolas.cantu_pm.me_-___0xAFF1ECF4.asc
@@ -0,0 +1,14 @@
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+
+xjMEYSXwVBYJKwYBBAHaRw8BAQdAsulrfkUdJQUxil8hC0AsehMTLq5l8TKx
+iPOW807Y2u/NKW5pY29sYXMuY2FudHVAcG0ubWUgPG5pY29sYXMuY2FudHVA
+cG0ubWU+wo8EEBYKACAFAmEl8FQGCwkHCAMCBBUICgIEFgIBAAIZAQIbAwIe
+AQAhCRBxlbYDS4nNZhYhBK/x7PS2N5gMcqLnmHGVtgNLic1mvpIBAKq7Qfem
+eEwWmX6unDM/hpnIl2CwDz+mmvaqHHZ/GXjwAQCAvIX82AhcjmnT90VKB5gP
+P3xanAdUQLNjjsnAtcogDc44BGEl8FQSCisGAQQBl1UBBQEBB0DyQexAoEWM
+pF7UOC8XJlz1BvnLhBitn596XSZg4exBSQMBCAfCeAQYFggACQUCYSXwVAIb
+DAAhCRBxlbYDS4nNZhYhBK/x7PS2N5gMcqLnmHGVtgNLic1mQ0AA/1L7m+Cs
+ZJLWnVxnn5Cdd9b6FZpAHK8f+LcCQ8euYudJAQDiUeKm8KZUvvYOGIvJuisG
+YHDv7GY5mNCR1JdWaR1rDQ==
+=TDqL
+-----END PGP PUBLIC KEY BLOCK-----
diff --git a/projects/lecoffreio/data/issues/2026-03-14T134128.af28dfa2.nicolas.cantu_pm.me.pending b/projects/lecoffreio/data/issues/2026-03-14T134128.af28dfa2.nicolas.cantu_pm.me.pending
new file mode 100644
index 0000000..b62ae0a
--- /dev/null
+++ b/projects/lecoffreio/data/issues/2026-03-14T134128.af28dfa2.nicolas.cantu_pm.me.pending
@@ -0,0 +1,36 @@
+{
+  "version": 1,
+  "type": "incoming",
+  "id": "af28dfa2",
+  "message_id": "<XImHtfSZSMJo1z1dqMvd19K5CPkEJ6q6-3Ky88Muiy5c_ED4mcc6JeLT-RY1Lt9T5b57Ce3GEvrrP6_kUZ0cToHtLKF2x324qbZDyLjqYG8=@pm.me>",
+  "from": "nicolas.cantu@pm.me",
+  "to": [
+    "\"ai.support.lecoffreio@4nkweb.com\" <ai.support.lecoffreio@4nkweb.com>"
+  ],
+  "subject": "Présente le projet",
+  "date": "Sat, 14 Mar 2026 13:41:28 +0000",
+  "body": "",
+  "references": [
+    "<6tpKkxA0z1VR1XTFT_L-rtTce3HmvVxnicdFfSgp0wx0-4ptNS6uaTXDXEa2Z0Po0URmrTRSwpprPwAxEeFacQ==@protonmail.internalid>"
+  ],
+  "in_reply_to": null,
+  "uid": "7903",
+  "created_at": "2026-03-14T13:42:53Z",
+  "issue_number": null,
+  "status": "responded",
+  "attachments": [
+    {
+      "filename": "publickey - nicolas.cantu@pm.me -\r\n 0xAFF1ECF4.asc",
+      "path": "2026-03-14T134128.af28dfa2.nicolas.cantu_pm.me.d/0_publickey_-_nicolas.cantu_pm.me_-___0xAFF1ECF4.asc",
+      "content_type": "application/pgp-keys",
+      "size": 653
+    }
+  ],
+  "response": {
+    "in_reply_to_message_id": "<XImHtfSZSMJo1z1dqMvd19K5CPkEJ6q6-3Ky88Muiy5c_ED4mcc6JeLT-RY1Lt9T5b57Ce3GEvrrP6_kUZ0cToHtLKF2x324qbZDyLjqYG8=@pm.me>",
+    "to": "nicolas.cantu@pm.me",
+    "subject": "Re: Présente le projet",
+    "body": "Le projet LeCoffre.io est une application de coffre-fort numérique (dépôt lecoffre_ng). La documentation technique est sur le wiki du dépôt Gitea (https://git.4nkweb.com/4nk/lecoffre_ng/wiki). Les déploiements test, préproduction et production passent par les scripts deploy/ ; le ticketing et le support IA par les scripts gitea-issues/ dans ia_dev.",
+    "sent_at": "2026-03-14T13:43:30Z"
+  }
+}
\ No newline at end of file
diff --git a/projects/lecoffreio/docs/ANCRAGE_COMPLETE.md b/projects/lecoffreio/docs/ANCRAGE_COMPLETE.md
new file mode 100644
index 0000000..8180546
--- /dev/null
+++ b/projects/lecoffreio/docs/ANCRAGE_COMPLETE.md
@@ -0,0 +1,841 @@
+# Documentation Complète de l'Ancrage Blockchain - LeCoffre.io
+
+**Dernière mise à jour** : 2025-11-24
+**Version** : 3.1.2
+
+Ce document consolide toute la documentation relative à l'ancrage blockchain des documents et dossiers dans LeCoffre.io.
+
+---
+
+## 📋 Table des Matières
+
+1. [Vue d'Ensemble](#1-vue-densemble)
+2. [Architecture V3](#2-architecture-v3)
+3. [Processus d'Ancrage](#3-processus-dancrage)
+4. [Certificats et ZIP](#4-certificats-et-zip)
+5. [Vérification et Statuts](#5-vérification-et-statuts)
+6. [Scripts et Maintenance](#6-scripts-et-maintenance)
+7. [Troubleshooting](#7-troubleshooting)
+8. [Références](#8-références)
+
+---
+
+## 1. Vue d'Ensemble
+
+### Évolution des Versions
+
+| Version | Blockchain | Périmètre | Déclenchement | Filigrane | Fallback |
+|---------|-----------|-----------|---------------|-----------|----------|
+| **V1** | Tezos | Dossiers uniquement | Manuel | ❌ Non | ⚠️ Lecture seule |
+| **V2** | Bitcoin Signet | Docs + Dossiers | Auto | ❌ Non | - |
+| **V3** | Bitcoin Signet | Docs + Dossiers | Auto | ✅ Oui | ✅ Tezos masqué |
+
+### Nouveautés V3
+
+1. **Filigrane automatique** : "lecoffre.io" sur tous documents
+2. **Double version** : Original + filigrané (conservés en BDD)
+3. **ZIP enrichi** : Originaux + filigranés + certificats + preuves JSON
+4. **Preuves structurées** : JSON standardisé pour vérification externe
+5. **Ancrage dossier** : Hash du ZIP complet (pas seulement Merkle tree)
+6. **Fallback Tezos** : Accès masqué aux anciens ancrages (lecture seule)
+
+### Principes Fondamentaux
+
+- **Ancrage immédiat** : L'ancrage est déclenché automatiquement lors de la validation d'un document
+- **Hash filigrané** : Seule la version filigranée est ancrée sur blockchain
+- **Double hash** : Hash original et hash filigrané sont stockés pour vérification
+- **Preuve on-chain** : Le `tx_id` (transaction ID Bitcoin) est la seule preuve fiable d'ancrage
+
+---
+
+## 2. Architecture V3
+
+### Services Backend
+
+#### WatermarkService
+
+**Fichier** : `lecoffre-back-main/src/services/common/WatermarkService/WatermarkService.ts`
+
+**Responsabilités** :
+
+- Conversion documents → PDF (si nécessaire)
+- Ajout filigrane "lecoffre.io" (diagonal, 15% opacité)
+- Upload version filigranée vers S3/IPFS
+- Gestion formats : PDF, images, Word, PowerPoint
+
+**Méthodes principales** :
+
+```typescript
+async addWatermarkAndUpload(fileUid: string): Promise<{
+  watermarkedS3Key: string;
+  watermarkedSize: number;
+  watermarkedMimetype: string;
+}>
+```
+
+#### DocumentAnchorsService
+
+**Fichier** : `lecoffre-back-main/src/services/notary/DocumentAnchorsService/DocumentAnchorsService.ts`
+
+**Workflow d'ancrage** :
+
+1. Vérification ancrage Tezos existant (fallback)
+2. Génération version filigranée si absente
+3. Calcul hash version filigranée
+4. Vérification ancrage Signet existant
+5. Création ancrage `QUEUED`
+6. Ancrage blockchain Bitcoin Signet
+7. Génération `proof_data` (incluant fallback Tezos)
+8. Mise à jour ancrage avec `tx_id`
+
+**Méthodes principales** :
+
+```typescript
+async anchorDocument(documentUid: string, anchoredByUid?: string): Promise<DocumentAnchors>
+async getByDocumentUid(documentUid: string): Promise<DocumentAnchors | null>
+async getByFileHash(fileHash: string): Promise<DocumentAnchors | null>
+```
+
+#### OfficeFolderAnchorsService
+
+**Fichier** : `lecoffre-back-main/src/services/notary/OfficeFolderAnchorsService/OfficeFolderAnchorsService.ts`
+
+**Workflow d'ancrage dossier** :
+
+1. Récupération tous documents validés
+2. Génération filigranes manquants
+3. Génération ZIP complet dossier
+4. Upload ZIP vers S3
+5. Ancrage hash ZIP complet
+6. Génération preuve dossier
+
+**Structure ZIP** :
+
+```text
+dossier_12345678/
+├── _LISEZ-MOI.txt
+├── 01_originaux/
+├── 02_filigranes/
+├── 03_certificats/
+└── 04_preuves/
+```
+
+#### ProofDataService
+
+**Fichier** : `lecoffre-back-main/src/services/notary/ProofDataService/ProofDataService.ts`
+
+**Responsabilités** :
+
+- Génération JSON de preuve d'ancrage
+- Format standard pour vérification externe
+- Inclusion toutes données blockchain
+
+**Structure JSON** :
+
+```json
+{
+  "version": "3.0.0",
+  "timestamp": "2025-10-29T16:30:00.000Z",
+  "document": {
+    "uid": "abc123...",
+    "name": "Acte de vente",
+    "original_hash": "e3b0c442...",
+    "watermarked_hash": "5feceb66..."
+  },
+  "anchor": {
+    "blockchain": "BITCOIN_SIGNET",
+    "status": "VERIFIED_ON_CHAIN",
+    "txid": "a1b2c3d4...",
+    "tx_link": "https://mempool.4nkweb.com/signet/tx/a1b2c3d4...",
+    "block_height": 123456,
+    "confirmations": 6
+  },
+  "tezos_fallback": {
+    "legacy": true,
+    "blockchain": "TEZOS",
+    "txid": "old_tezos_tx..."
+  }
+}
+```
+
+#### BitcoinSignetService
+
+**Fichier** : `lecoffre-back-main/src/services/common/BitcoinSignetService/BitcoinSignetService.ts`
+
+**Responsabilités** :
+
+- Ancrage hash sur Bitcoin Signet
+- Vérification statut transaction
+- Récupération métadonnées blockchain
+
+**Méthodes principales** :
+
+```typescript
+async anchorHash(hash: string): Promise<{
+  txid: string;
+  tx_hash: string;
+  tx_link: string;
+}>
+async verifyAnchor(txId: string): Promise<{
+  confirmed: boolean;
+  confirmations: number;
+  block_height: number;
+}>
+```
+
+### Base de Données
+
+#### Schéma Prisma
+
+**Table `files`** :
+
+```prisma
+model Files {
+  uid                    String    @id @unique @default(uuid())
+  file_name              String
+  s3_key                 String?
+
+  // V3 : Version filigranée
+  watermarked_s3_key     String?
+  watermarked_at         DateTime?
+  original_hash          String?   // Hash fichier original
+
+  document_uid           String?
+  document               Documents? @relation(...)
+}
+```
+
+**Table `document_anchors`** :
+
+```prisma
+model DocumentAnchors {
+  uid                    String    @id @unique @default(uuid())
+  document_uid           String    @unique
+
+  // Hash de la version FILIGRANNÉE (V3)
+  file_hash              String
+
+  blockchain             EBlockchainName  @default(BITCOIN_SIGNET)
+  status                 EAnchoringStatus @default(QUEUED)
+
+  // Données blockchain
+  tx_id                  String?   // ⚠️ CRITIQUE : Seul indicateur fiable
+  tx_link                String?
+  tx_hash                String?
+  block_height           Int?
+  block_time             DateTime?
+  confirmations          Int?
+
+  // V3 : Données de preuve (JSON)
+  proof_data             Json?
+
+  anchored_at            DateTime?
+  anchored_by_uid        String?
+}
+```
+
+**Table `office_folder_anchors`** :
+
+```prisma
+model OfficeFolderAnchors {
+  uid                    String    @id @unique @default(uuid())
+
+  // Hashs sources (Merkle tree)
+  root_hash              String
+
+  // V3 : ZIP complet
+  zip_hash               String?
+  zip_s3_key             String?
+  zip_size               Float?
+
+  blockchain             EBlockchainName  @default(BITCOIN_SIGNET)
+  status                 EAnchoringStatus @default(QUEUED)
+
+  // Données blockchain
+  tx_id                  String?   // ⚠️ CRITIQUE : Seul indicateur fiable
+  tx_link                String?
+  tx_hash                String?
+  block_height           Int?
+  confirmations          Int?
+
+  // V3 : Données de preuve (JSON)
+  proof_data             Json?
+}
+```
+
+**Enums** :
+
+```prisma
+enum EBlockchainName {
+  TEZOS          // ⚠️ Conservé pour fallback (lecture seule)
+  BITCOIN_SIGNET
+}
+
+enum EAnchoringStatus {
+  QUEUED              // ⚠️ OBSOLÈTE : Non utilisé de manière fiable
+  ATTEMPTING          // ⚠️ OBSOLÈTE : Non utilisé de manière fiable
+  VERIFIED_ON_CHAIN   // ⚠️ OBSOLÈTE : Le système se base uniquement sur tx_id
+  FAILED
+  ABANDONED
+}
+```
+
+**⚠️ IMPORTANT** : Le champ `status` n'est plus utilisé de manière fiable. Le système vérifie uniquement la présence de `tx_id` :
+
+- `tx_id` présent = Ancrage réussi
+- `tx_id` absent = Ancrage non effectué
+
+---
+
+## 3. Processus d'Ancrage
+
+### Séquence de Traitement (Upload)
+
+Pour **tous les documents** (Client, Tiers, Notaire invité, Notaire), la séquence est :
+
+1. **Calcul hash original** (fichier original)
+2. **Filigrane** (sur fichier original non chiffré)
+3. **Calcul hash filigrané et ancrage blockchain** (hash filigrané, génération txid)
+4. **Chiffrement** du document filigrané
+5. **Upload IPFS** du document chiffré
+6. **Stockage métadonnées** fichier (hash original + hash filigrané)
+7. **Stockage certificat BDD** (document_anchor avec hash filigrané + hash original + txid)
+
+### Ancrage Automatique lors de la Validation
+
+**Déclenchement** : Lors de la validation d'un document via `PUT /api/v1/notary/documents/:uid`
+
+**Fichier** : `lecoffre-back-main/src/app/api/notary/DocumentsController.ts`
+
+**Workflow** :
+
+```typescript
+if (documentEntityUpdated.document_status === EDocumentStatus.VALIDATED && firstFileUid) {
+  // Ancrage automatique (asynchrone, non bloquant)
+  if (userUid) {
+    void this.documentAnchorsService
+      .anchorDocument(documentEntityUpdated.uid, userUid)
+      .then((anchor) => {
+        SafeLogger.info(`✅ Document ${documentEntityUpdated.uid} automatically anchored`);
+      })
+      .catch((error) => {
+        SafeLogger.error(`❌ Auto-anchoring failed: ${error}`);
+      });
+  }
+}
+```
+
+**Points importants** :
+
+- ✅ L'ancrage est **asynchrone** (non bloquant)
+- ✅ L'ancrage est lancé en **arrière-plan**
+- ✅ Si l'ancrage échoue, le document reste validé
+
+### Ancrage Document
+
+**Workflow détaillé** :
+
+1. **Récupération document + fichier**
+2. **Vérification ancrage Tezos existant** (fallback)
+3. **Génération version filigranée** si absente
+4. **Téléchargement version filigranée** et calcul hash
+5. **Vérification ancrage Signet existant**
+6. **Création ancrage `QUEUED`**
+7. **Ancrage blockchain** via `BitcoinSignetService.anchorHash()`
+8. **Génération `proof_data`** (incluant fallback Tezos)
+9. **Mise à jour ancrage** avec `tx_id`, `tx_link`, `proof_data`
+
+### Ancrage Dossier
+
+**Workflow détaillé** :
+
+1. **Récupération tous documents validés** du dossier
+2. **Génération filigranes manquants** pour tous documents
+3. **Génération ZIP complet** du dossier :
+   - Originaux (01_originaux/)
+   - Filigranés (02_filigranes/)
+   - Certificats (03_certificats/)
+   - Preuves JSON (04_preuves/)
+4. **Upload ZIP vers S3**
+5. **Ancrage hash ZIP complet** sur blockchain
+6. **Génération preuve dossier**
+7. **Création/Mise à jour ancrage dossier**
+
+**Condition** : Le dossier doit être à **100% de complétion** (tous documents validés)
+
+---
+
+## 4. Certificats et ZIP
+
+### Génération Automatique de Certificats
+
+#### Téléchargement Individuel (Document Validé et Ancré)
+
+**Endpoints** :
+
+- Notaire : `GET /api/v1/notary/files/download/:uid`
+- Client : `GET /api/v1/customer/files/download/:uid`
+
+**Comportement automatique** : Pour les documents validés (`VALIDATED`) et ancrés avec statut `VERIFIED_ON_CHAIN`, le téléchargement génère **automatiquement** un ZIP contenant :
+
+1. **PDF filigrané** : Document avec filigrane appliqué (suffixe `_aplc.pdf`)
+2. **Certificat d'ancrage** : Certificat PDF Bitcoin Signet (préfixe `certificat_`)
+
+**Exemple de ZIP** :
+
+```text
+document_001_CNI_DUPONT_Jean_avec_certificat.zip
+├── 001_CNI_DUPONT_Jean_aplc.pdf        (PDF filigrané)
+└── certificat_001_CNI_DUPONT_Jean.pdf  (Certificat d'ancrage)
+```
+
+#### Téléchargement Multiple (ZIP de Fichiers)
+
+**Service** : `ZipService.createZipFromFiles()`
+
+**Workflow de recherche d'ancrage** :
+
+1. **PRIORITÉ** : Recherche par `document_uid` (plus fiable)
+2. **FALLBACK** : Si pas trouvé, recherche par hash du fichier
+3. **Vérification statut** : Le certificat n'est généré que si `status === VERIFIED_ON_CHAIN`
+
+#### Téléchargement Dossier Complet
+
+**Service** : `OfficeFolderAnchorsService.generateFolderZip()`
+
+**Structure ZIP** :
+
+```text
+dossier_12345678_Acte_de_vente/
+├── _LISEZ-MOI.txt                   (Instructions vérification)
+├── 01_originaux/
+│   ├── acte_vente.pdf               (Version originale)
+│   └── compromis_vente.pdf
+├── 02_filigranes/
+│   ├── acte_vente.pdf               (⚠️ VERSION ANCRÉE avec filigrane)
+│   └── compromis_vente.pdf
+├── 03_certificats/
+│   ├── certificat_acte_vente.pdf    (PDF certif blockchain)
+│   └── certificat_compromis_vente.pdf
+└── 04_preuves/
+    ├── preuve_acte_vente.json       (JSON avec hashs + TX)
+    └── preuve_compromis_vente.json
+```
+
+### Contenu des Certificats PDF
+
+**Informations affichées** :
+
+1. **Hashs complets** :
+   - Empreinte SHA-256 (original) : Hash complet du document initial (64 caractères hex)
+   - Empreinte SHA-256 (filigrané) : Hash complet du document avec filigrane (64 caractères hex)
+   - Source : `proof_data.document.original_hash` et `proof_data.document.watermarked_hash`
+
+2. **Lien de transaction** :
+   - Format : `https://mempool.4nkweb.com/fr/tx/<txid>`
+   - Construit automatiquement à partir de `anchor.tx_id` si disponible
+   - Fallback sur `anchor.tx_link` si `tx_id` absent
+
+3. **Autres informations** :
+   - Identifiant unique du document
+   - Informations du dossier (numéro, nom)
+   - Informations de l'office notarial
+   - Type de document
+   - Déposant
+   - Validateur (UID)
+   - Nom de fichier normé
+   - Blockchain utilisée (Bitcoin Signet Notaires)
+   - Statut d'ancrage
+   - ID de transaction
+   - Hauteur de bloc (si disponible)
+   - Date d'ancrage
+
+### Filigrane Visuel
+
+**Spécifications** :
+
+- **Texte** : "lecoffre.io"
+- **Position** : Diagonal (45°), centré sur chaque page
+- **Opacité** : 15% (visible mais non gênant)
+- **Couleur** : Gris clair (#CCCCCC)
+- **Police** : Arial, 48pt
+- **Pages** : Toutes les pages du PDF
+
+---
+
+## 5. Vérification et Statuts
+
+### Logique de Vérification
+
+**⚠️ IMPORTANT** : Le système d'ancrage V3 ne fonctionne plus avec des statuts intermédiaires. L'ancrage est maintenant **immédiat** :
+
+- ✅ **Ancré** : L'ancrage a un `tx_id` (transaction ID Bitcoin)
+- ❌ **Non ancré** : L'ancrage n'a pas de `tx_id`
+
+**Il n'y a plus d'étape intermédiaire** comme `ATTEMPTING`, `QUEUED`, ou `VERIFYING_ON_CHAIN`.
+
+### Backend
+
+Le backend vérifie uniquement la présence de `tx_id` :
+
+```typescript
+if (anchorStatus.tx_id) {
+    setAnchorStatus(AnchorStatus.VERIFIED_ON_CHAIN);
+} else {
+    setAnchorStatus(AnchorStatus.NOT_ANCHORED);
+}
+```
+
+### Frontend
+
+Le frontend utilise l'enum `AnchorStatus` mais ne vérifie que `tx_id` :
+
+```typescript
+export enum AnchorStatus {
+    "VERIFIED_ON_CHAIN" = "VERIFIED_ON_CHAIN",
+    "NOT_ANCHORED" = "NOT_ANCHORED",
+}
+
+// Vérification
+if (anchorStatus.tx_id) {
+    setAnchorStatus(AnchorStatus.VERIFIED_ON_CHAIN);
+} else {
+    setAnchorStatus(AnchorStatus.NOT_ANCHORED);
+}
+```
+
+### Masquage du Statut "Ancrage en cours"
+
+**Objectif** : Améliorer l'expérience utilisateur en ne montrant pas le statut transitoire "Ancrage en cours" pour les documents validés.
+
+**Comportement** : Pour les documents avec `document_status === VALIDATED`, le statut "Ancrage en cours" (`ATTEMPTING`) n'est **pas affiché** dans l'interface utilisateur.
+
+**Composant `AnchorBadge`** :
+
+```typescript
+if (documentStatus === "VALIDATED" && status === "ATTEMPTING") {
+    return null; // Badge not displayed
+}
+```
+
+### Vérification Publique
+
+**Endpoints** :
+
+- `GET /api/v1/public/verify/:hash` : Vérification par hash (SANS authentification)
+- `POST /api/v1/public/verify-file` : Vérification par upload fichier (SANS authentification)
+
+**Page frontend** : `/verify-document`
+
+**Fonctionnalités** :
+
+- Upload fichier (drag & drop ou sélection)
+- Calcul hash automatique (SHA256)
+- Appel API public (aucune authentification requise)
+- Affichage résultat (success/error)
+- Lien explorateur blockchain
+
+### Procédure de Vérification
+
+**Pour utilisateur final** :
+
+1. Télécharger ZIP complet du dossier
+2. Extraire le ZIP
+3. Ouvrir fichier dans `04_preuves/preuve_XXX.json`
+4. Noter le `watermarked_hash`
+5. Calculer hash du fichier dans `02_filigranes/` :
+
+   ```bash
+   shasum -a 256 02_filigranes/acte_vente.pdf
+   ```
+
+6. Comparer les deux hashs (doivent être identiques)
+7. Vérifier TX : Ouvrir `tx_link` du JSON dans navigateur
+8. ✅ **Validé** si hash OK + TX confirmée sur blockchain
+
+**Pour audit technique** :
+
+1. Parser JSON de preuve
+2. Extraire `watermarked_hash`, `txid`, `block_height`
+3. Requête API blockchain (Mempool Space) :
+
+   ```bash
+   curl https://mempool.4nkweb.com/signet/api/tx/{txid}
+   ```
+
+4. Vérifier :
+   - TX existe
+   - Hash dans OP_RETURN correspond
+   - Block confirmé
+5. Recalculer hash fichier filigrané
+6. Comparer avec `watermarked_hash`
+7. ✅ **Preuve authentique** si tout correspond
+
+---
+
+## 6. Scripts et Maintenance
+
+### Scripts Disponibles
+
+#### Audit des Ancrages Manquants
+
+**Script** : `audit-missing-anchors.js`
+
+**Usage** :
+
+```bash
+ENV=prod npm run anchorage:audit
+```
+
+**Description** :
+
+- Analyse tous les documents validés sans ancrage
+- Analyse tous les dossiers archivés sans ancrage
+- Génère un CSV avec la liste des documents/dossiers à réancrer
+- Ne modifie aucune donnée (lecture seule)
+
+**Résultat** :
+
+- Affichage console avec statistiques
+- CSV généré : `logs/audit-missing-anchors_YYYYMMDD_HHMMSS.csv`
+
+#### Ancrage V3 de Dossiers Existants
+
+**Script** : `anchor-existing-folders-v3.js`
+
+**Usage** :
+
+```bash
+# Ancrage tous dossiers LIVE + ARCHIVED (par défaut)
+ENV=prod npm run anchorage
+
+# Dry-run (simulation)
+ENV=prod npm run anchorage -- --all --batch=1 --dry-run
+
+# Ancrage réel avec limite batch
+ENV=prod npm run anchorage -- --all --batch=5
+
+# Ancrage de dossiers spécifiques
+ENV=prod npm run anchorage -- --folder-uids=uid1,uid2,uid3
+```
+
+**Options** :
+
+- `--all-archived` : Tous les dossiers ARCHIVED sans ancrage
+- `--all-validated` : Tous les dossiers VALIDATED sans ancrage
+- `--all` : Tous les dossiers VALIDATED + ARCHIVED
+- `--folder-uids=uid1,uid2,...` : Liste UIDs dossiers spécifiques
+- `--batch=N` : Nombre max de dossiers par batch (défaut: 10)
+- `--dry-run` : Simulation sans ancrage réel
+- `--skip-documents` : Ancrer seulement dossiers (pas documents individuels)
+
+#### Vérifications Systématisées des Colonnes d'Ancrage
+
+Depuis 2025-01-XX, les scripts de déploiement vérifient systématiquement la présence des colonnes indispensables pour l'ancrage avant d'exécuter le réancrage.
+
+**Colonnes vérifiées** :
+
+- `document_anchors.proof_data` (JSONB) - Données de preuve structurées
+- `document_anchors.confirmations` (INTEGER) - Nombre de confirmations blockchain
+- `document_anchors.anchor_job_id` (VARCHAR) - ID du job d'ancrage
+- `document_notary_anchors.proof_data` (JSONB) - Données de preuve structurées
+- `document_notary_anchors.confirmations` (INTEGER) - Nombre de confirmations blockchain
+
+**Garanties** :
+
+- ✅ Vérification de l'existence des tables avant toute modification
+- ✅ Ajout automatique des colonnes manquantes (8 points de vérification)
+- ✅ Blocage du réancrage si colonnes manquantes détectées
+- ✅ Messages d'erreur explicites indiquant les colonnes manquantes
+
+**Ordre d'exécution garanti** :
+
+```text
+resetDatabase → migrateResolveDatabase → reanchorAll
+     ↓                    ↓                    ↓
+  Base vide      Colonnes ajoutées      Vérification finale
+                              ↓                    ↓
+                    Si manquantes →      Blocage si manquantes
+```
+
+📖 Voir [README.md](./README.md#consolidation-operationnelle-ex-operationsmd) et [DEPLOYMENT.md](./DEPLOYMENT.md) pour les corrections sur les colonnes d'ancrage.
+
+#### Réancrage de Documents/Dossiers
+
+**Script** : `reanchor-documents.js`
+
+**Usage** :
+
+```bash
+# Dry-run (simulation)
+ENV=prod npm run anchorage:reanchor -- --dry-run
+
+# Réancrage réel
+ENV=prod npm run anchorage:reanchor -- --document-uids=uid1,uid2
+```
+
+**Options** :
+
+- `--document-uids=uid1,uid2,...` : Liste UIDs documents spécifiques
+- `--folder-uids=uid1,uid2,...` : Liste UIDs dossiers spécifiques
+- `--all-missing` : Réancrer TOUS les documents/dossiers sans ancrage (⚠️)
+- `--batch=N` : Nombre max de documents/dossiers par batch (défaut: 50)
+- `--dry-run` : Simulation sans ancrage réel
+
+#### Nettoyage Ancres Dossiers Incomplets
+
+**Script** : `clean-incomplete-folder-anchors.ts`
+
+**Contexte** :
+
+- Certains dossiers peuvent avoir été ancrés alors qu'ils n'étaient pas à 100%
+- Seuls les dossiers complets (100% documents validés) doivent être ancrés
+
+**Usage** :
+
+```bash
+# Depuis le conteneur backend
+cd lecoffre-back-main
+npx ts-node src/scripts/clean-incomplete-folder-anchors.ts --dry-run
+npx ts-node src/scripts/clean-incomplete-folder-anchors.ts
+```
+
+**Actions** :
+
+- Identifie les dossiers ancrés avec complétion < 100%
+- Supprime les ancres correspondantes dans `office_folder_anchors`
+- Réinitialise les liens `folder_anchor_uid = NULL` dans `office_folders`
+
+### ⚠️ IMPORTANT : Prérequis
+
+1. **Colonnes V3** : La base doit avoir toutes les colonnes V3 (`watermarked_s3_key`, `watermarked_at`, `zip_hash`, `zip_s3_key`, `zip_size`, `proof_data`)
+2. **Prisma Client** : Le client Prisma doit être généré avec le bon schéma
+3. **Connexion BDD** : Les scripts utilisent `DATABASE_URL` (configurée sur le serveur ou via `.env.<env>`)
+
+### Workflow Recommandé
+
+1. **Audit initial** :
+
+   ```bash
+   ENV=prod npm run anchorage:audit
+   ```
+
+2. **Test avec dry-run** :
+
+   ```bash
+   ENV=prod npm run anchorage -- --all-archived --batch=1 --dry-run
+   ```
+
+3. **Ancrage réel** :
+
+   ```bash
+   ENV=prod npm run anchorage -- --all-archived --batch=5
+   ```
+
+---
+
+## 7. Troubleshooting
+
+### Certificats Manquants dans le ZIP
+
+**Symptôme** : Lors de la validation d'un document, le document apparaît comme validé, mais le certificat d'ancrage n'est pas présent dans le ZIP téléchargé.
+
+**Root Cause** :
+
+1. Recherche par hash uniquement (peut échouer)
+2. Pas de vérification du statut avant génération
+
+**Solution** :
+
+1. Recherche prioritaire par `document_uid` (plus fiable)
+2. Fallback par hash si nécessaire
+3. Vérification du statut (`status === VERIFIED_ON_CHAIN`) avant génération
+
+### Timing et Synchronisation
+
+**Scénario typique** :
+
+1. **T0** : Document validé → Ancrage lancé en arrière-plan
+2. **T0+2s** : Ancrage créé avec `status = ATTEMPTING`
+3. **T0+5s** : Transaction Bitcoin confirmée → `status = VERIFIED_ON_CHAIN` (après 6 confirmations)
+4. **T0+10s** : Utilisateur télécharge le ZIP → Certificat inclus ✅
+
+**Cas limite** : Si l'utilisateur télécharge le ZIP **immédiatement après validation** (avant que l'ancrage soit vérifié) :
+
+- ⚠️ L'ancrage peut être en statut `ATTEMPTING` ou `QUEUED`
+- ⚠️ Le certificat **ne sera pas inclus** dans le ZIP
+- ✅ L'utilisateur peut **relancer le téléchargement** plus tard pour obtenir le certificat
+
+### Fichiers Sans Clé de Chiffrement (.expired)
+
+**Contexte** : Les dumps de base de données provenant de versions antérieures peuvent contenir des fichiers avec `key = null` (clé de chiffrement perdue).
+
+**Solution implémentée** :
+
+- `FilesService.download()` : Retourne fichier vide `.expired` si `key = null`
+- `WatermarkService.addWatermarkAndUpload()` : Upload fichier vide `.expired` sur IPFS
+- `DocumentAnchorsService.anchorDocument()` : Ancrage avec hash du buffer vide
+
+**Résultat** :
+
+- ✅ Scripts d'ancrage ne crashent plus sur fichiers sans clé
+- ✅ Fichiers `.expired` créés automatiquement
+- ✅ Ancrage blockchain avec hash du buffer vide
+- ⚠️ Utilisateur informé que fichier non récupérable
+
+### Checklist de Vérification
+
+Pour diagnostiquer un problème de certificat manquant dans un ZIP :
+
+- [ ] Vérifier que le document est **validé** (`document_status === VALIDATED`)
+- [ ] Vérifier qu'un ancrage existe pour ce document (`document_anchors` table)
+- [ ] Vérifier le **statut de l'ancrage** (`status === VERIFIED_ON_CHAIN`)
+- [ ] Vérifier les **logs backend** pour voir si l'ancrage a été trouvé
+- [ ] Vérifier que `includeAnchors = true` lors de l'appel à `createZipFromFiles`
+- [ ] Vérifier que le fichier n'est pas un `isNotaryFiles` (pas d'ancrage pour les fichiers notaire)
+
+---
+
+## 8. Références
+
+### Documentation Détaillée
+
+- **Architecture V3** : `docs/ANCRAGE_V3_ARCHITECTURE.md` - Architecture complète V3
+- **Certificats et ZIP** : `docs/ANCRAGE_CERTIFICATS_ZIP.md` - Génération certificats et ZIP
+- **Scripts** : `docs/SCRIPTS.md` - Scripts d'audit et d'ancrage
+- **Statuts** : `docs/ANCHOR_STATUS_VERIFICATION.md` - Vérification des statuts d'ancrage
+- **Séquences de traitement** : `docs/DOCUMENT_PROCESSING_SEQUENCES_V2.md` - Séquence complète upload/ancrage
+
+### Services Backend
+
+- **WatermarkService** : `lecoffre-back-main/src/services/common/WatermarkService/WatermarkService.ts`
+- **DocumentAnchorsService** : `lecoffre-back-main/src/services/notary/DocumentAnchorsService/DocumentAnchorsService.ts`
+- **OfficeFolderAnchorsService** : `lecoffre-back-main/src/services/notary/OfficeFolderAnchorsService/OfficeFolderAnchorsService.ts`
+- **ProofDataService** : `lecoffre-back-main/src/services/notary/ProofDataService/ProofDataService.ts`
+- **BitcoinSignetService** : `lecoffre-back-main/src/services/common/BitcoinSignetService/BitcoinSignetService.ts`
+- **AnchorCertificateService** : `lecoffre-back-main/src/services/notary/AnchorCertificateService/AnchorCertificateService.ts`
+- **ZipService** : `lecoffre-back-main/src/services/common/ZipService/ZipService.ts`
+
+### Controllers
+
+- **DocumentsController** : `lecoffre-back-main/src/app/api/notary/DocumentsController.ts`
+- **FilesController (Notary)** : `lecoffre-back-main/src/app/api/notary/FilesController.ts`
+- **FilesController (Customer)** : `lecoffre-back-main/src/app/api/customer/FilesController.ts`
+- **PublicAnchorVerificationController** : `lecoffre-back-main/src/app/api/public/PublicAnchorVerificationController.ts`
+
+### Scripts
+
+- **Audit** : `lecoffre-back-main/src/scripts/audit-missing-anchors.ts`
+- **Ancrage dossiers** : `lecoffre-back-main/src/scripts/anchor-existing-folders-v3.ts`
+- **Réancrage** : `lecoffre-back-main/src/scripts/reanchor-documents.ts`
+- **Nettoyage** : `lecoffre-back-main/src/scripts/clean-incomplete-folder-anchors.ts`
+
+### Frontend
+
+- **Page vérification** : `lecoffre-front-main/src/pages/verify-document.tsx`
+- **Composant AnchorBadge** : `lecoffre-front-main/src/front/Components/DesignSystem/AnchorBadge/`
+
+---
+
+**Dernière mise à jour** : 2025-11-24
+**Version** : 3.1.2
diff --git a/projects/lecoffreio/docs/API.md b/projects/lecoffreio/docs/API.md
new file mode 100644
index 0000000..017790f
--- /dev/null
+++ b/projects/lecoffreio/docs/API.md
@@ -0,0 +1,1568 @@
+# APIs Externes - Documentation Complète
+
+**Auteur** : Équipe 4NK
+**Date** : 2026-01-27
+**Version** : 2.0
+
+**Référence unique (checks de déploiement)** : [`docs/DEPLOYMENT.md#cartographie-des-checks-de-déploiement-source-unique`](./DEPLOYMENT.md#cartographie-des-checks-de-déploiement-source-unique)
+
+Ce document consolide toute la documentation relative aux APIs externes utilisées par LeCoffre.io :
+
+- API d'ancrage Bitcoin Signet
+- API Annuaire
+- API agent IA notaire (ai_working_help)
+
+## API agent IA notaire (ai_working_help)
+
+### Vue d'ensemble
+
+Les backends des applications métier appellent l'API **ai_working_help** (service agent IA notaire) pour les opérations **ask**, **enqueue** et **getResponse**. L'URL de base est configurée via `NOTARY_AI_AGENT_URL` **sans slug** (ex. `http://192.168.1.173:3020/v1`). Le projet (et l’env) sont identifiés par le token Bearer : l’API cherche dans tous les projets et tous les envs le fichier `projects/<id>/.secrets/<env>/ia_token` dont le contenu correspond au token. Le filtrage IP 192.168.1.* est géré côté API.
+
+### Authentification
+
+**Contrat obligatoire** : tous les appels à l'API agent doivent envoyer le header :
+
+```http
+Authorization: Bearer <token>
+```
+
+Le token est de la forme **base** + **env** (ex. `nicolecoffreiotest`, `nicolecoffreiopprod`). **env** est le nom d’environnement (test, pprod, prod), à adapter selon les environnements. La clé en base est `NOTARY_AI_AGENT_TOKEN` ; sa valeur doit correspondre à celle côté ia_dev dans `projects/<id>/.secrets/<env>/ia_token` pour l’env concerné. Le backend envoie ce header sur :
+
+- **POST** `{NOTARY_AI_AGENT_URL}/ask` — question synchrone (legacy)
+- **POST** `{NOTARY_AI_AGENT_URL}/enqueue` — mise en file (spooler)
+- **GET** `{NOTARY_AI_AGENT_URL}/response/:request_uid` — récupération de la réponse (poll après enqueue)
+
+Implémentation côté backend : `lecoffre-back-main/src/services/notary/NotaryFolderAIService/NotaryFolderAIService.ts` (méthodes `ask`, `enqueue`, `getResponse`). Le header n'est ajouté que si `NOTARY_AI_AGENT_TOKEN` est renseigné ; si l'API exige l'authentification, la clé doit être définie dans `.secrets/<env>/env-full` et injectée en base lors du déploiement.
+
+---
+
+## Consolidation des évolutions backend récentes
+
+Cette section consolide les éléments issus des documents de travail intégrés intégrés dans la documentation API pérenne.
+
+### Intégration Genapi / iNot
+
+- Endpoint backend ajouté pour l'envoi unitaire vers iNot : `POST /api/v1/notary/documents/:uid/push-inot`.
+- Flux implémenté : OAuth token, recherche dossier par numéro, création eDocument, upload binaire.
+- Contrôle métier côté backend : document validé requis avant push.
+- Gestion d'indisponibilité normalisée avec code métier `GENAPI_API_UNAVAILABLE`.
+
+### Standardisation des erreurs d'intégrations externes
+
+- Normalisation des mappings d'indisponibilité `*_API_UNAVAILABLE` sur plusieurs intégrations (`GENAPI`, `ANNUAIRE`, `ANCHORAGE`, `IDNOT`, `OPENID`, `IPFS`, `MAILCHIMP`, `STRIPE`).
+- Helpers partagés de propagation d'erreurs et de journalisation externe introduits pour homogénéiser les contrôleurs, helpers métier et services.
+- Conventions de nommage d'opérations externes unifiées (`integration.operation`) pour la traçabilité.
+
+### Correctifs de robustesse API
+
+- Correctif d'interop CJS/ESM sur l'hydratation des ressources ID.Not (`User.hydrate is not a function`) via normalisation des constructeurs hydratables.
+- Correctif de fusion PDF batch : normalisation des noms de fichiers multipart pour éviter les erreurs d'encodage WinAnsi pendant la génération de PDF fusionnés.
+
+---
+
+## API d'Ancrage Bitcoin Signet
+
+### Vue d'ensemble
+
+L'API d'ancrage Bitcoin Signet est un service autonome qui gère l'ancrage de hashes de documents sur la blockchain Bitcoin Signet. Elle est séparée du backend principal pour :
+
+- **Isolation** : Le nœud Bitcoin et l'API d'ancrage tournent sur un serveur dédié
+- **Performance** : Évite la surcharge du backend principal avec des opérations blockchain lentes
+- **Sécurité** : Accès restreint par API key
+- **Scalabilité** : Peut gérer une file d'attente d'ancrages indépendamment
+
+## Architecture
+
+```text
+lecoffre-back-main (prod.lecoffreio.4nkweb.com:3009)
+         │
+         ├─── HTTP POST ───> lecoffre-anchor-api (anchorage.certificator.4nkweb.com:3004)
+         │                           │
+         │                           ├─── JSON-RPC ───> Bitcoin Node (localhost:38332)
+         │                           └─── Callback ───> lecoffre-back-main
+         │
+         └─── Continue processing...
+```
+
+## Infrastructure
+
+### Serveur et déploiement
+
+- **Serveur** : Serveur bitcoin (où le nœud Bitcoin Signet est déployé)
+- **Répertoire** : `/home/ncantu/Bureau/code/bitcoin/api-anchorage`
+- **URL publique** : `https://anchorage.certificator.4nkweb.com`
+- **Port interne** : `3004`
+- **Service systemd** : `anchor-api.service` ou `api-anchorage.service` (user service)
+
+### Proxy Nginx
+
+Le proxy `192.168.1.100` route toutes les requêtes vers `anchorage.certificator.4nkweb.com` vers le serveur bitcoin (port 3004).
+
+**Configuration** : `/etc/nginx/sites-enabled/certificator.4nkweb.com`
+
+## Configuration
+
+### Variables d'environnement
+
+Le fichier `.env` est situé dans `/home/ncantu/Bureau/code/bitcoin/api-anchorage/.env` :
+
+```bash
+PORT=3004
+NODE_ENV=production
+BITCOIN_RPC_HOST=127.0.0.1
+BITCOIN_RPC_PORT=18443
+BITCOIN_COOKIE_PATH=/home/ncantu/.bitcoin/signet/.cookie
+# Note: Utiliser 127.0.0.1 au lieu de localhost pour forcer IPv4
+```
+
+### Service systemd
+
+**Fichier** : `/home/ncantu/.config/systemd/user/anchor-api.service`
+
+```ini
+[Unit]
+Description=Anchor API Service - anchorage.certificator.4nkweb.com:3004
+After=network-online.target signet.service
+Wants=network-online.target
+
+[Service]
+Type=simple
+WorkingDirectory=/home/ncantu/Bureau/code/bitcoin/api-anchorage
+EnvironmentFile=/home/ncantu/Bureau/code/bitcoin/api-anchorage/.env
+ExecStart=/bin/bash -c 'export PORT=3004; export NVM_DIR="/home/ncantu/.nvm"; [ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"; cd /home/ncantu/Bureau/code/bitcoin/api-anchorage && npm run dev'
+Restart=on-failure
+RestartSec=10
+StandardOutput=journal
+StandardError=journal
+SyslogIdentifier=anchor-api
+
+NoNewPrivileges=true
+PrivateTmp=true
+
+[Install]
+WantedBy=default.target
+```
+
+### Nœud Bitcoin
+
+- **Service** : `signet.service` (user service)
+- **Port RPC** : `18443` (localhost, Signet)
+- **Port P2P** : `38333` (exposé via NAT)
+- **Cookie** : `/home/ncantu/.bitcoin/signet/.cookie`
+- **Configuration** : `/srv/4NK/signet.4nkweb.com/bitcoin/bitcoin.conf`
+
+## Fonctionnement
+
+L'API d'ancrage fonctionne de manière **synchrone** :
+
+- Le traitement Bitcoin se fait **avant** la réponse HTTP
+- L'API retourne directement le `txid` avec toutes les informations
+- Code HTTP 200 (OK) au lieu de 202 (Accepted)
+- Pas de UUID, pas de status "pending", pas besoin de status endpoint
+
+### Analyse du fonctionnement réel
+
+**Code réel de l'API** :
+
+```typescript
+// AnchorController.anchorDocument()
+// Ancrer directement sur Bitcoin (synchrone)
+const txid = await this.bitcoinService.anchorHash(hash);
+
+// Récupérer le statut de la transaction
+const txStatus = await this.bitcoinService.getTransactionStatus(txid);
+
+const response: IAnchorResponse = {
+  txid,
+  confirmations: txStatus.confirmations,
+  block_height: txStatus.block_height,
+  status: 'confirmed',
+};
+
+res.status(200).json(response); // Retourne directement { txid: "...", status: "confirmed", ... }
+```
+
+**Fonctionnement** :
+
+- L'API attend que le traitement Bitcoin soit terminé (`await`)
+- Elle retourne directement le `txid` avec toutes les informations (confirmations, block_height)
+- Code HTTP 200 (OK) au lieu de 202 (Accepted)
+- Pas de UUID, pas de status "pending"
+
+**Problème initial résolu** : Le backend s'attendait à recevoir un UUID avec `status: "pending"` et HTTP 202, mais l'API fonctionne de manière synchrone et retourne directement le `txid` avec HTTP 200. Le backend a été aligné sur le fonctionnement réel de l'API.
+
+## Endpoints API
+
+### Health Check
+
+```http
+GET /health
+```
+
+**Réponse** :
+
+```json
+{
+  "ok": true,
+  "service": "anchor-api",
+  "bitcoin": {
+    "connected": true,
+    "blocks": 198769
+  },
+  "timestamp": "2026-01-23T11:03:33.668Z"
+}
+```
+
+### Ancrage de document
+
+```http
+POST /api/anchor/document
+Content-Type: application/json
+x-api-key: <API_KEY>
+
+{
+  "documentUid": "uuid-du-document",
+  "hash": "hash-sha256-du-fichier-filigrane-64-hex",
+  "callback_url": "https://prod.lecoffreio.4nkweb.com/api/v1/public/anchors/callback/document" (optionnel, non utilisé)
+}
+```
+
+**Réponse** (200 OK) :
+
+```json
+{
+  "txid": "56504e002d95301ebcfb4b30eaedc5d3fd9a448e121ffdce4f356b8d34169e85",
+  "status": "confirmed",
+  "confirmations": 0,
+  "block_height": 142062
+}
+```
+
+**Important** :
+
+- L'API fonctionne de manière **synchrone** : le traitement Bitcoin se fait avant la réponse
+- Le `txid` est retourné directement dans la réponse (pas d'UUID)
+- Le statut est toujours `"confirmed"` (pas de "pending")
+- Toutes les informations sont disponibles immédiatement (confirmations, block_height)
+- Le `callback_url` est optionnel et appelé après la réponse si fourni
+
+### Vérification d'ancrage
+
+```http
+POST /api/anchor/verify
+Content-Type: application/json
+x-api-key: <API_KEY>
+
+{
+  "hash": "hash-sha256-du-fichier-64-hex",
+  "txid": "txid-bitcoin-64-hex" (optionnel)
+}
+```
+
+**Réponse** (200 OK) si ancré :
+
+```json
+{
+  "verified": true,
+  "anchor_info": {
+    "transaction_id": "txid-bitcoin-64-hex",
+    "block_height": 198775,
+    "confirmations": 6,
+    "timestamp": "2026-01-23T11:03:33.668Z"
+  }
+}
+```
+
+**Réponse** (200 OK) si non ancré :
+
+```json
+{
+  "verified": false
+}
+```
+
+## Flux de traitement
+
+### 1. Demande d'ancrage (synchrone)
+
+1. Le backend appelle `POST /api/anchor/document` avec le hash du fichier filigrané
+2. L'API ancre directement le hash sur Bitcoin Signet via JSON-RPC (attente synchrone)
+3. L'API retourne `200 OK` avec toutes les informations :
+
+   ```json
+   {
+     "txid": "56504e002d95301ebcfb4b30eaedc5d3fd9a448e121ffdce4f356b8d34169e85",
+     "status": "confirmed",
+     "confirmations": 0,
+     "block_height": 142062
+   }
+   ```
+
+### 2. Callback (optionnel)
+
+Si `callback_url` a été fourni lors de la demande d'ancrage :
+
+1. L'API appelle `POST {callback_url}` avec le résultat (après la réponse HTTP) :
+
+   ```json
+   {
+     "document_uid": "uuid-du-document",
+     "status": "confirmed",
+     "txid": "txid-bitcoin-64-hex",
+     "confirmations": 0,
+     "block_height": 142062
+   }
+   ```
+
+2. Le backend reçoit le callback et peut mettre à jour l'ancrage dans la base de données (optionnel)
+
+## Types TypeScript
+
+### Interfaces de l'API
+
+```typescript
+interface IAnchorRequest {
+  documentUid: string;
+  hash: string; // 64 hex characters
+  callback_url?: string;
+}
+
+interface IAnchorResponse {
+  txid: string; // Hash Bitcoin de la transaction (64 hex) - retourné directement
+  status: 'confirmed'; // Toujours 'confirmed' (pas de 'pending')
+  confirmations: number; // Nombre de confirmations (0 si dans le mempool)
+  block_height?: number; // Hauteur du bloc si confirmé
+}
+
+interface IVerifyRequest {
+  hash: string; // 64 hex characters
+  txid?: string; // Optionnel pour vérifier un txid spécifique
+}
+
+interface IVerifyResponse {
+  verified: boolean;
+  anchor_info?: {
+    transaction_id: string;
+    block_height: number;
+    confirmations: number;
+    timestamp: string;
+  };
+}
+```
+
+### Utilisation dans le backend
+
+Le backend utilise `BitcoinSignetApiHelper` pour interagir avec l'API :
+
+```typescript
+// 1. Ancrer un hash (synchrone)
+const result = await bitcoinSignetApiHelper.anchorHashViaApi(hash, {
+  resourceUid: documentUid,
+  resourceType: "document"
+});
+
+// result.txid est directement disponible (pas d'UUID)
+// result.status est toujours 'confirmed'
+// result.confirmations et result.block_height sont disponibles
+```
+
+**Important** :
+
+- L'API fonctionne de manière **synchrone** : le `txid` est retourné directement
+- Le code HTTP est **200 OK** (pas 202 Accepted)
+- Toutes les informations sont disponibles immédiatement
+- Pas besoin de status endpoint ou de polling
+
+## Code source
+
+Le code source de l'API d'ancrage se trouve dans la branche `v2-remote` du dépôt v1 :
+
+- **Dépôt** : `https://git.4nkweb.com/4nk/lecoffreio`
+- **Branche** : `v2-remote`
+- **Répertoire** : `lecoffre-anchor-api/`
+
+### Structure
+
+```text
+lecoffre-anchor-api/
+├── src/
+│   ├── config/
+│   │   ├── bitcoin.config.ts
+│   │   └── logger.ts
+│   ├── controllers/
+│   │   └── AnchorController.ts
+│   ├── services/
+│   │   ├── BitcoinService.ts
+│   │   └── AnchorQueueService.ts
+│   └── index.ts
+├── package.json
+├── tsconfig.json
+└── .env
+```
+
+## Installation et déploiement
+
+### Clonage du code
+
+```bash
+cd /srv/4NK/certificator.4nkweb.com
+git clone -b v2-remote --single-branch --depth 1 git@git.4nkweb.com:4nk/lecoffreio.git temp-anchor-api
+mv temp-anchor-api/lecoffre-anchor-api .
+rm -rf temp-anchor-api
+```
+
+### Installation des dépendances
+
+```bash
+cd /srv/4NK/certificator.4nkweb.com/lecoffre-anchor-api
+source /home/ncantu/.nvm/nvm.sh
+npm install
+```
+
+### Configuration
+
+1. Créer le fichier `.env` avec les variables d'environnement
+2. Vérifier que le cookie Bitcoin existe et est accessible
+3. Mettre à jour le service systemd pour pointer vers le bon répertoire
+
+### Démarrage du service
+
+```bash
+systemctl --user daemon-reload
+systemctl --user start anchor-api.service
+systemctl --user enable anchor-api.service
+```
+
+## Vérification
+
+### Vérifier le statut du service
+
+```bash
+systemctl --user status anchor-api.service
+```
+
+### Vérifier les logs
+
+```bash
+journalctl --user -u anchor-api.service -f
+```
+
+### Tester l'API depuis l'extérieur
+
+**Test simple avec curl :**
+
+```bash
+curl -k https://anchorage.certificator.4nkweb.com/health
+```
+
+**Réponse attendue** :
+
+```json
+{
+  "ok": true,
+  "service": "anchor-api",
+  "bitcoin": {
+    "connected": true,
+    "blocks": 152321
+  }
+}
+```
+
+**Exemple de client Node.js :**
+
+Un exemple complet de client pour tester l'API :
+
+```javascript
+#!/usr/bin/env node
+
+/**
+ * Exemple basique de client pour l'API Anchor
+ * Usage: node example-client.js
+ */
+
+const https = require('https');
+const crypto = require('crypto');
+
+// Configuration
+const API_URL = 'https://anchorage.certificator.4nkweb.com';
+const API_KEY = 'your-api-key-here'; // Remplacez par votre clé API
+
+/**
+ * Effectue une requête HTTPS
+ */
+function makeRequest(method, path, data = null) {
+  return new Promise((resolve, reject) => {
+    const url = new URL(path, API_URL);
+
+    const options = {
+      hostname: url.hostname,
+      port: url.port || 443,
+      path: url.pathname,
+      method: method,
+      headers: {
+        'Content-Type': 'application/json',
+        'x-api-key': API_KEY,
+      },
+    };
+
+    const req = https.request(options, (res) => {
+      let body = '';
+
+      res.on('data', (chunk) => {
+        body += chunk;
+      });
+
+      res.on('end', () => {
+        try {
+          const json = JSON.parse(body);
+          if (res.statusCode >= 200 && res.statusCode < 300) {
+            resolve(json);
+          } else {
+            reject(new Error(`HTTP ${res.statusCode}: ${json.error || body}`));
+          }
+        } catch (e) {
+          reject(new Error(`Parse error: ${e.message}`));
+        }
+      });
+    });
+
+    req.on('error', (error) => {
+      reject(error);
+    });
+
+    if (data) {
+      req.write(JSON.stringify(data));
+    }
+
+    req.end();
+  });
+}
+
+/**
+ * Vérifie l'état de l'API
+ */
+async function checkHealth() {
+  try {
+    console.log('🔍 Vérification de l\'état de l\'API...');
+    const response = await makeRequest('GET', '/health');
+    console.log('✅ API opérationnelle');
+    console.log(`   Bitcoin connecté: ${response.bitcoin.connected ? 'Oui' : 'Non'}`);
+    console.log(`   Blocs: ${response.bitcoin.blocks}`);
+    return response;
+  } catch (error) {
+    console.error('❌ Erreur:', error.message);
+    throw error;
+  }
+}
+
+/**
+ * Ancre un document sur Bitcoin Signet
+ */
+async function anchorDocument(documentUid, hash, callbackUrl = null) {
+  try {
+    console.log(`\n📎 Ancrage du document: ${documentUid}`);
+    console.log(`   Hash: ${hash.substring(0, 16)}...`);
+
+    const data = {
+      documentUid,
+      hash,
+    };
+
+    if (callbackUrl) {
+      data.callback_url = callbackUrl;
+    }
+
+    const response = await makeRequest('POST', '/api/anchor/document', data);
+
+    console.log('✅ Document ancré avec succès');
+    console.log(`   Transaction ID: ${response.txid}`);
+    console.log(`   Confirmations: ${response.confirmations}`);
+    if (response.block_height) {
+      console.log(`   Block height: ${response.block_height}`);
+    }
+
+    return response;
+  } catch (error) {
+    console.error('❌ Erreur lors de l\'ancrage:', error.message);
+    throw error;
+  }
+}
+
+/**
+ * Vérifie si un hash est ancré
+ */
+async function verifyAnchor(hash, txid = null) {
+  try {
+    console.log(`\n🔍 Vérification de l'ancrage...`);
+    console.log(`   Hash: ${hash.substring(0, 16)}...`);
+
+    const data = { hash };
+    if (txid) {
+      data.txid = txid;
+      console.log(`   Transaction ID: ${txid.substring(0, 16)}...`);
+    }
+
+    const response = await makeRequest('POST', '/api/anchor/verify', data);
+
+    if (response.verified) {
+      console.log('✅ Hash vérifié et ancré');
+      if (response.anchor_info) {
+        console.log(`   Transaction ID: ${response.anchor_info.transaction_id}`);
+        console.log(`   Block height: ${response.anchor_info.block_height}`);
+        console.log(`   Confirmations: ${response.anchor_info.confirmations}`);
+      }
+    } else {
+      console.log('❌ Hash non trouvé dans la blockchain');
+    }
+
+    return response;
+  } catch (error) {
+    console.error('❌ Erreur lors de la vérification:', error.message);
+    throw error;
+  }
+}
+
+/**
+ * Fonction principale
+ */
+async function main() {
+  console.log('=== Client API Anchor ===\n');
+
+  try {
+    // 1. Vérifier l'état de l'API
+    await checkHealth();
+
+    // 2. Générer un hash de test
+    const documentContent = `Document de test - ${new Date().toISOString()}`;
+    const hash = crypto.createHash('sha256').update(documentContent).digest('hex');
+    const documentUid = `doc-${Date.now()}`;
+
+    console.log(`\n📄 Document de test:`);
+    console.log(`   UID: ${documentUid}`);
+    console.log(`   Hash: ${hash}`);
+
+    // 3. Ancrer le document
+    const anchorResult = await anchorDocument(documentUid, hash);
+
+    // 4. Attendre un peu pour que la transaction soit propagée
+    console.log('\n⏳ Attente de 3 secondes pour la propagation...');
+    await new Promise((resolve) => setTimeout(resolve, 3000));
+
+    // 5. Vérifier l'ancrage
+    await verifyAnchor(hash, anchorResult.txid);
+
+    console.log('\n✅ Tous les tests sont passés avec succès!');
+
+  } catch (error) {
+    console.error('\n❌ Erreur:', error.message);
+    process.exit(1);
+  }
+}
+
+// Exécuter le script
+if (require.main === module) {
+  main();
+}
+
+// Exports pour utilisation comme module
+module.exports = {
+  checkHealth,
+  anchorDocument,
+  verifyAnchor,
+};
+```
+
+**Utilisation :**
+
+```bash
+# Modifier API_KEY dans le script
+node example-client.js
+```
+
+**Points importants :**
+
+- L'API retourne directement le `txid` dans la réponse (fonctionnement synchrone)
+- Le code HTTP est **200 OK** (pas 202 Accepted)
+- Toutes les informations sont disponibles immédiatement (confirmations, block_height)
+
+## Bonnes pratiques
+
+### Utilisation de l'API
+
+L'API fonctionne de manière **synchrone** et retourne directement toutes les informations :
+
+```typescript
+const result = await bitcoinSignetApiHelper.anchorHashViaApi(hash, {
+  resourceUid: documentUid,
+  resourceType: "document",
+});
+
+// result.txid est directement disponible
+// result.status est "confirmed"
+// result.confirmations et result.block_height sont disponibles
+```
+
+**Avantages** :
+
+- Pas besoin de status endpoint ou de polling
+- Toutes les informations sont disponibles immédiatement
+- Comportement prévisible et fiable
+
+### Gestion des erreurs
+
+**Erreurs bloquantes** : Si l'API retourne une erreur (HTTP 500), c'est un problème bloquant :
+
+```typescript
+try {
+  const result = await bitcoinSignetApiHelper.anchorHashViaApi(hash, options);
+  // Le txid est obligatoire et doit être présent
+  if (!result.txid) {
+    throw new Error("Txid manquant (BLOQUANT)");
+  }
+} catch (error) {
+  // Toute erreur est bloquante, le document ne peut pas être créé
+  throw error;
+}
+```
+
+### Callback (optionnel)
+
+Le `callback_url` est optionnel et appelé après la réponse HTTP. Il peut être utilisé pour :
+
+- Mise à jour asynchrone de la base de données
+- Notification d'autres services
+- Logging supplémentaire
+
+**Note** : Le callback n'est pas nécessaire car toutes les informations sont déjà dans la réponse initiale.
+
+## Dépannage
+
+### Le service ne démarre pas
+
+1. Vérifier que le répertoire existe : `/srv/4NK/certificator.4nkweb.com/lecoffre-anchor-api`
+2. Vérifier que les dépendances sont installées : `npm install`
+3. Vérifier les logs : `journalctl --user -u anchor-api.service -n 50`
+
+### Erreur "Bitcoin node not available"
+
+1. Vérifier que le nœud Bitcoin est actif : `systemctl --user status signet.service`
+2. Vérifier que le cookie existe : `ls -la /home/ncantu/.bitcoin/signet/.cookie`
+3. Vérifier que le port RPC est accessible : `ss -tlnp | grep 38332`
+4. Vérifier la configuration dans `.env` : `BITCOIN_COOKIE_PATH` doit pointer vers le bon chemin
+
+### Erreur IPv6 "connect EADDRNOTAVAIL ::1:38332"
+
+**Date** : 2026-01-25
+
+**Problème** : L'API d'ancrage essaie de se connecter au nœud Bitcoin via IPv6 (`::1:38332`) mais le nœud n'écoute que sur IPv4.
+
+**Solution** : Forcer IPv4 dans la configuration de l'API d'ancrage :
+
+**Fichier** : `/home/ncantu/Bureau/code/bitcoin/api-anchorage/.env`
+
+```bash
+# Utiliser explicitement IPv4
+BITCOIN_RPC_HOST=127.0.0.1
+BITCOIN_ZMQ_HOST=127.0.0.1
+BITCOIN_ZMQ_PORT=38332
+```
+
+**Vérification** : Vérifier que le nœud Bitcoin écoute sur IPv4 :
+
+```bash
+ss -tlnp | grep 38332
+ss -tlnp | grep 18443
+```
+
+### Erreur "too-long-mempool-chain"
+
+**Date** : 2026-01-25
+
+**Problème** : Le mempool Bitcoin Signet est saturé avec plus de 25 transactions non confirmées en chaîne (limite de sécurité Bitcoin).
+
+**Solution** : Le script détecte cette erreur et s'arrête immédiatement avec un message clair. L'utilisateur doit attendre que les transactions soient confirmées avant de relancer.
+
+**Vérification** :
+
+```bash
+bitcoin-cli -signet getmempoolinfo
+bitcoin-cli -signet getrawmempool
+```
+
+### Erreurs de timeout (504, ESOCKETTIMEDOUT, client timeout)
+
+**Date** : 2026-01-26 à 2026-01-28
+
+**Problèmes** :
+
+- **504 Gateway Timeout** : Timeout du proxy Nginx (probablement `proxy_read_timeout` trop court)
+- **ESOCKETTIMEDOUT** : Timeout socket lors de la connexion au nœud Bitcoin
+- **Client timeout (AbortController)** : Timeout client de 5 minutes dépassé
+
+**Solutions appliquées** :
+
+1. **Détection des timeouts** : Tous les timeouts (504, 500 avec timeout socket, client timeout) sont détectés comme retryable
+2. **Retry automatique** : 3 tentatives avec délai de 30 secondes entre chaque tentative
+3. **Timeout client** : Timeout explicite de 5 minutes avec `AbortController` (aligné avec `proxy_read_timeout` Nginx)
+4. **Logs améliorés** : Logs détaillés pour chaque tentative, timeout, retry et succès
+
+**Configuration Nginx recommandée** :
+
+```nginx
+location / {
+    proxy_pass http://192.168.1.103:3004;
+    proxy_connect_timeout 60s;
+    proxy_send_timeout 600s;      # 10 minutes
+    proxy_read_timeout 600s;      # 10 minutes
+}
+```
+
+**Logs à surveiller** :
+
+- `📡 [BitcoinSignetService] Anchor API - Tentative X/3 pour hash ...`
+- `⏱️ [BitcoinSignetService] Anchor API - Timeout client déclenché après 300000ms`
+- `⚠️ [BitcoinSignetService] Anchor API timeout (504/500/client) - Tentative X/3, attente 30000ms avant retry...`
+- `✅ [BitcoinSignetService] Anchor API - Ancrage réussi pour hash ...`
+
+### Erreur "Cannot find module './config/logger'"
+
+Le fichier `src/config/logger.ts` doit être créé manuellement :
+
+```typescript
+const logger = {
+  info: (message: string) => console.log('[INFO] ' + new Date().toISOString() + ' - ' + message),
+  error: (message: string) => console.error('[ERROR] ' + new Date().toISOString() + ' - ' + message),
+  warn: (message: string) => console.warn('[WARN] ' + new Date().toISOString() + ' - ' + message),
+  debug: (message: string) => console.debug('[DEBUG] ' + new Date().toISOString() + ' - ' + message),
+};
+
+export default logger;
+```
+
+### Erreur "Anchor API returned invalid txid"
+
+**Cause** : Le code s'attend à recevoir un txid Bitcoin immédiatement, mais l'API retourne un UUID (job ID).
+
+**Solution** : Le code a été corrigé pour accepter un UUID et récupérer le txid via le status endpoint ou le callback.
+
+### Erreur "Anchor API transaction not ready yet"
+
+**Cause** : La transaction est en cours de traitement (status "pending" sans txid).
+
+**Solution** : Attendre le callback. Ne pas relancer l'ancrage. Le callback mettra à jour le txid automatiquement.
+
+### Transactions non traitées
+
+**Cause** : La file d'attente est en mémoire. Si le service redémarre, les transactions en cours sont perdues.
+
+**Solution actuelle** : Les transactions sont recréées automatiquement lors du traitement des fichiers.
+
+**Amélioration future** : Migrer vers Redis ou une base de données pour la persistance.
+
+## Configuration dans le backend
+
+L'URL de l'API d'ancrage est configurée dans la base de données via `system_configuration` :
+
+- **Clé** : `ANCHORE_API_URL`
+- **Valeur** : `https://anchorage.certificator.4nkweb.com`
+- **Catégorie** : `INTEGRATION_BITCOIN`
+
+- **Clé** : `ANCHORE_API_KEY`
+- **Valeur** : `<API_KEY>`
+- **Catégorie** : `INTEGRATION_BITCOIN`
+- **Sensible** : `true`
+
+## Historique
+
+### 2026-01-23 : Alignement du backend sur le fonctionnement synchrone de l'API
+
+**Problème** : Le backend s'attendait à recevoir un UUID avec status "pending" et HTTP 202, mais l'API fonctionne de manière synchrone et retourne directement le txid avec HTTP 200.
+
+**Corrections** :
+
+1. Alignement du backend sur le fonctionnement réel de l'API (synchrone)
+2. Attente de HTTP 200 (OK) au lieu de HTTP 202 (Accepted)
+3. Récupération directe du `txid` dans la réponse initiale
+4. Suppression de la méthode `getStatus` devenue inutile
+5. Suppression de toute logique de polling ou d'attente
+6. Documentation mise à jour pour refléter le fonctionnement synchrone
+
+**Résultat** : Le backend reçoit directement toutes les informations (txid, confirmations, block_height) dans la réponse initiale, sans besoin de status endpoint ou de polling.
+
+### 2026-01-23 : Restauration de l'API d'ancrage
+
+**Problème** : L'API d'ancrage était inactive et le service systemd pointait vers un répertoire inexistant (`/home/ank/dev/lecoffre-anchor-api`).
+
+**Solution** :
+
+1. Clonage du code depuis la branche `v2-remote` du dépôt v1 dans `/srv/4NK/certificator.4nkweb.com/lecoffre-anchor-api`
+2. Installation des dépendances npm
+3. Création du fichier `logger.ts` manquant
+4. Création du fichier `.env` avec la configuration Bitcoin
+5. Mise à jour du service systemd pour pointer vers le nouveau répertoire
+6. Correction du chemin du cookie Bitcoin (`/home/ncantu/.bitcoin/signet/.cookie`)
+
+**Résultat** : L'API d'ancrage est opérationnelle et connectée au nœud Bitcoin Signet.
+
+### 2026-01-27 : Mise à jour URL API d'ancrage
+
+**Problème** : L'URL de l'API d'ancrage a été changée de `https://prod.signet.4nkweb.com` vers `https://anchorage.certificator.4nkweb.com`.
+
+**Solution** :
+
+1. Mise à jour de `ANCHORE_API_URL` dans `env-full-<env>-for-bdd-injection.txt`
+2. Mise à jour dans `system_configuration` via `setSettings`
+3. Port interne : `3004` (configuré dans `.env` et systemd)
+4. Nginx : Route `anchorage.certificator.4nkweb.com` → `192.168.1.103:3004`
+
+**Vérification** :
+
+```bash
+cd lecoffre-back-main
+npm run anchorage:test-anchor-api
+```
+
+**Problème 502 Bad Gateway** : Si vous rencontrez des erreurs **502 Bad Gateway** :
+
+- Vérifier l'état du service : `systemctl --user status anchor-api.service`
+- Vérifier que le service écoute sur le port 3004 : `ss -tlnp | grep 3004`
+- Tester depuis le backend : `curl -s http://localhost:3004/health`
+- Configuration Nginx : Route `anchorage.certificator.4nkweb.com` → `192.168.1.103:3004`
+
+---
+
+## API Annuaire
+
+### Vue d'Ensemble
+
+L'API Annuaire est appelée avec une authentification **Basic Auth** (login/password) distincte de l'API IdNot existante (clé API). Les recherches utilisent des **appels API au moment de la demande** (pas de tables `annu_*`).
+
+### Configuration
+
+**Variables d'environnement** (via `system_configuration`) :
+
+- `ANNUAIRE_API_LOGIN` : Login Basic Auth
+- `ANNUAIRE_API_PASSWORD` : Password Basic Auth (sensible)
+- `ANNUAIRE_API_BASE_URL` : URL de base de l'API Annuaire
+
+**Lecture directe depuis la BDD** : les helpers de recherche (IdNot/Annuaire) lisent ces configurations depuis `system_configuration` (via `ConfigLoader`), sans passer par `.env`.
+
+### Préparation configuration Genapi (push iNot)
+
+Variables prévues pour injection depuis `env-full-<env>-for-bdd-injection.txt` vers `system_configuration` :
+
+- `GENAPI_AUTH_URL` : URL OAuth token Genapi (`.../Authorization/OAuth/Token`)
+- `GENAPI_API_BASE_URL` : URL de base API Genapi (`.../actes`)
+- `GENAPI_TENANT_ID` : Tenant Genapi (header `tenantId`)
+- `GENAPI_CLIENT_ID` : Client ID OAuth Genapi
+- `GENAPI_CLIENT_SECRET` : Client secret OAuth Genapi (sensible)
+- `GENAPI_SCOPE` : Scopes OAuth Genapi (ex: `sas:read sas:write`)
+
+### Backend endpoint for Genapi push
+
+- `POST /api/v1/notary/documents/:uid/push-inot`
+
+Execution flow:
+
+1. Validate document status (`VALIDATED` required).
+2. Resolve dossier in Genapi by folder `numero` using `/api/v1/Dossiers/Search`.
+3. Create an eDocument in Genapi (`/api/v1/Clients/{idParent}/Edocument` or `/api/v1/Partenaires/{idParent}/Edocument`).
+4. Upload binary payload to `/api/v1/Documents/{id}/Data`.
+
+Unavailable response:
+
+- If Genapi endpoint is unreachable, backend returns `GENAPI_API_UNAVAILABLE`.
+- Frontend displays a dedicated message for this case ("API Genapi indisponible").
+
+Backend mutualization:
+
+- Shared helper for same auth protocol integrations: `TenantOAuthHttpClient`
+- Scope: external backend calls using OAuth client-credentials + `tenantId` header.
+- Frontend unavailable error mappings are centralized in `front/Utils/errorMessages/constants/externalServiceErrorPatterns.ts`.
+- External integration registry is centralized in backend: `lecoffre-back-main/src/common/utils/externalServiceErrors.ts`.
+- Standardized backend unavailable codes applied to multiple integrations:
+  - `GENAPI_API_UNAVAILABLE`
+  - `ANNUAIRE_API_UNAVAILABLE`
+  - `ANCHORAGE_API_UNAVAILABLE`
+  - `IDNOT_API_UNAVAILABLE`
+  - `OPENID_API_UNAVAILABLE`
+  - `IPFS_API_UNAVAILABLE`
+  - `MAILCHIMP_API_UNAVAILABLE`
+- Common controller mapper for integration errors:
+  - `lecoffre-back-main/src/common/utils/controllerExternalErrorHelper.ts`
+  - Shared integration->HTTP mapping table moved to:
+    - `lecoffre-back-main/src/common/utils/externalIntegrationHttpMappings.ts`
+  - Variant wrapper available:
+    - `handleControllerErrorWithExternalIntegration(...)`
+  - Domain factory utility available:
+    - `getExternalIntegrationMappings("mailchimp" | "idnot" | "ipfs" | "openid" | "anchorage" | "genapi" | "stripe" | "bitcoin_signet" | "idnot_annuaire" | "all")`
+  - Subset mapping utilities available:
+    - `EXTERNAL_INTEGRATION_HTTP_MAPPINGS_MAILCHIMP_ONLY`
+    - `EXTERNAL_INTEGRATION_HTTP_MAPPINGS_IDNOT_ONLY`
+    - `EXTERNAL_INTEGRATION_HTTP_MAPPINGS_IPFS_ONLY`
+    - `EXTERNAL_INTEGRATION_HTTP_MAPPINGS_OPENID_ONLY`
+    - `EXTERNAL_INTEGRATION_HTTP_MAPPINGS_ANCHORAGE_ONLY`
+    - `EXTERNAL_INTEGRATION_HTTP_MAPPINGS_GENAPI_ONLY`
+    - `EXTERNAL_INTEGRATION_HTTP_MAPPINGS_STRIPE_ONLY`
+    - `EXTERNAL_INTEGRATION_HTTP_MAPPINGS_BITCOIN_SIGNET_ONLY`
+    - `EXTERNAL_INTEGRATION_HTTP_MAPPINGS_IDNOT_ANNUAIRE`
+  - Mapping response messages are now derived from `buildExternalServiceUnavailableCode(...)` to keep integration error messages homogeneous.
+  - Already wired in:
+    - `notary/DocumentsController`
+    - `idnot/UserController`
+    - `idnot/OfficeController`
+    - `notary/MailchimpController`
+    - `public/IncidentReportController`
+    - `notary/FolderThirdPartiesController` (resend-code flow)
+    - `super-admin/HealthTestsController`
+    - `admin/SyncController`
+    - `public/ThirdPartyAuthController` (`request-code`)
+    - `notary/FolderSharingController` (`searchNotaries`)
+    - `notary/DocumentAnchorsController` (`anchorDocument`, `anchorFolderDocuments`, `verifyPendingAnchors`)
+    - `notary/DocumentsController` (`push-inot`, `resend-request`, `resend-request-batch`)
+    - `notary/FolderThirdPartiesController` (`resend-code` with `mailchimp` domain mapping)
+    - `idnot/UserController`
+    - `idnot/OfficeController`
+  - Helper-level fallback utility available for non-controller flows:
+    - `handleErrorWithExternalIntegrationFallback(...)`
+  - Service-level propagation utility available for business layers without HTTP response object:
+    - `toExternalServiceUnavailableError(...)`
+    - `isExternalServiceUnavailableError(...)`
+    - `buildExternalOperationName(integration, operation)` (`integration.operation`)
+    - `wrapExternalCall(integration, operation, fn)`
+    - `wrapExternalCallWithLog(integration, operation, fn, logError)`
+    - `createExternalIntegrationCallLogger(integrationLabel, context, level?, extraMetadata?)`
+    - `buildStandardExternalLogMetadata({ targetEmail?, subscriptionId?, requestPath?, resourceUid? })`
+    - `mergeExternalLogMetadata(...metadataItems)`
+    - `buildStripeSubscriptionMetadata({ requestPath, subscriptionType?, frequency?, subscriptionId? })`
+    - `buildIdNotRequestMetadata({ targetEmail?, requestPath })`
+    - `buildMailchimpRequestMetadata({ targetEmail, requestPath })`
+    - `buildOpenIdRequestMetadata({ requestPath, resourceUid? })`
+    - `buildIpfsReadMetadata({ requestPath, resourceUid? })`
+    - `buildIpfsWriteMetadata({ requestPath, resourceUid? })`
+    - `buildOpenIdTokenMetadata({ requestPath, resourceUid? })`
+    - `buildOpenIdJwksMetadata({ requestPath, resourceUid? })`
+    - `buildOpenIdUserInfoMetadata({ requestPath, resourceUid? })`
+    - `buildOpenIdLogoutMetadata({ requestPath, resourceUid? })`
+    - `buildIpfsPinMetadata({ requestPath, resourceUid? })`
+    - `buildIpfsUnpinMetadata({ requestPath, resourceUid? })`
+    - `buildIpfsGatewayReadMetadata({ requestPath, resourceUid? })`
+    - `buildAnchorageRequestMetadata({ requestPath, resourceUid? })`
+    - `buildGenapiRequestMetadata({ requestPath, resourceUid? })`
+    - `createIpfsGatewayReadLogger(context, requestPath)`
+    - `createIpfsGatewayReadLoggerFromPath(context, pathOrUrl)`
+    - `createIpfsPinLogger(context, requestPath, resourceUid?)`
+    - `createIpfsPinLoggerFromFileName(context, fileName, requestPath?)`
+    - `createIpfsUnpinLogger(context, requestPath, resourceUid?)`
+    - `createIpfsUnpinLoggerFromHash(context, hashToUnpin)`
+    - `createOpenIdUserInfoLogger(context, requestPath, resourceUid?)`
+    - `createOpenIdLogoutLogger(context, requestPath, resourceUid?)`
+    - `createOpenIdTokenLogger(context, requestPath, resourceUid?)`
+    - `createOpenIdJwksLogger(context, requestPath, resourceUid?)`
+    - `createOpenIdUserInfoLoggerFromPath(context, pathOrUrl, resourceUid?)`
+    - `createOpenIdLogoutLoggerFromPath(context, pathOrUrl, resourceUid?)`
+    - `createOpenIdTokenLoggerFromPath(context, pathOrUrl, resourceUid?)`
+    - `createOpenIdJwksLoggerFromPath(context, pathOrUrl, resourceUid?)`
+    - `createIpfsExternalCallLogger(context)`
+    - `createMailchimpRequestLoggerFromPath(context, pathOrUrl, targetEmail)`
+    - `createIdNotRequestLoggerFromPath(context, pathOrUrl, targetEmail?, level?)`
+    - `createStripeSubscriptionLogger(context, { requestPath, subscriptionType?, frequency?, subscriptionId?, level? })`
+    - `createStripeSubscriptionLoggerFromPath(context, { pathOrUrl, subscriptionType?, frequency?, subscriptionId?, level? })`
+    - `createAnchorageRequestLogger(context, requestPath, resourceUid?, level?)`
+    - `createAnchorageRequestLoggerFromPath(context, pathOrUrl, resourceUid?, level?)`
+    - `createGenapiRequestLogger(context, requestPath, resourceUid?, level?)`
+    - `createGenapiRequestLoggerFromPath(context, pathOrUrl, resourceUid?, level?)`
+    - `createMailchimpExternalCallLogger(context, extraMetadata?)`
+    - `createIdNotExternalCallLogger(context, level?, extraMetadata?)`
+    - `createStripeExternalCallLogger(context, level?, extraMetadata?)`
+    - `createAnchorageExternalCallLogger(context, level?, extraMetadata?)`
+    - `createGenapiExternalCallLogger(context, level?, extraMetadata?)`
+    - `lecoffre-back-main/src/common/utils/externalServiceErrorPropagation.ts`
+    - `lecoffre-back-main/src/common/utils/externalServiceCallLoggers.ts`
+  - Helper-level fallback already wired in:
+    - `notary/helpers/FolderThirdPartiesResendCodeHelper.ts`
+    - `public/helpers/ThirdPartyAuthHelper.ts`
+    - `notary/helpers/FolderSharingResendHelper.ts`
+  - Service-level propagation already wired in:
+    - `services/notary/DocumentsService/DocumentsService.ts`
+    - `services/notary/OfficesService/OfficesRibService.ts`
+    - `services/common/FileProcessingService/helpers/FileProcessingStepHelper.ts`
+    - `services/common/BitcoinSignetService/BitcoinSignetService.ts`
+    - `services/common/MailchimpService/MailchimpService.ts`
+    - `services/notary/OfficesService/helpers/OfficesRibProcessingHelper.ts`
+    - `services/common/FileProcessingService/helpers/FileProcessingViewHelper.ts`
+  - `wrapExternalCall(...)` usage extended to secondary flows where failure is explicitly external:
+    - IPFS read/view/download helpers
+    - Mailchimp list subscription API call
+  - `wrapExternalCallWithLog(...)` usage extended where log+rethrow was duplicated:
+    - Bitcoin RPC anchorage flows
+    - Secondary Mailchimp resend flows
+    - Secondary IPFS/watermark processing flows
+    - Secondary IPFS view/download/watermark read helper flows
+    - Secondary RIB IPFS low-level download flow
+    - Mailchimp list subscription flow (`addToMailchimpList`)
+    - Annuaire/IdNot secondary email-search API flow (`searchByEmail`)
+    - Stripe checkout-session creation flow (`createCheckoutSession`)
+  - Standardized metadata keys used in external log payloads:
+    - `targetEmail`
+    - `subscriptionId`
+    - `requestPath`
+    - `resourceUid`
+  - Inline callback metadata objects replaced by dedicated metadata builders on active IDNOT/MAILCHIMP/STRIPE wrappers.
+  - Existing IPFS gateway-read wrappers aligned with `buildIpfsGatewayReadMetadata(...)`.
+  - Existing IPFS upload wrappers aligned with `buildIpfsPinMetadata(...)`.
+  - Remaining OPENID/IPFS wrapper logger lambdas replaced by dedicated logger wrappers.
+  - Existing IPFS unpin flow migrated to wrapper + dedicated unpin logger (`IpfsService.unpinFile`).
+  - Existing IPFS gateway-read logger usage migrated to `createIpfsGatewayReadLoggerFromPath(...)` for URL/path normalization.
+  - Existing IPFS unpin logger usage migrated to `createIpfsUnpinLoggerFromHash(...)` for hash-only caller contract.
+  - Existing IPFS pin logger usage migrated to `createIpfsPinLoggerFromFileName(...)` for default pin endpoint encapsulation.
+  - OPENID userinfo/logout flows are now available in `OpenIdService` with dedicated logger wrappers.
+  - Existing OPENID logger usage migrated to `fromPath` wrappers for normalized endpoint metadata.
+  - `OpenIdService` implements `common/system/OpenIdInterface.ts` (`getOpenIdConfig`, `getSigningKey`, `verifyIdToken`, `getUserInfo`, `notifyLogout`).
+  - Existing OPENID calls aligned with dedicated metadata builders for discovery/token and JWKS endpoints.
+  - Existing Mailchimp and Annuaire/IdNot flows aligned with `fromPath` wrappers for endpoint normalization:
+    - `services/common/MailchimpService/MailchimpService.ts` (`addToMailchimpList`)
+    - `services/common/IdNotDirectoryService/IdNotDirectoryService.ts` (`searchByEmail`)
+  - Existing Stripe checkout-session flow aligned with `createStripeSubscriptionLoggerFromPath(...)` for endpoint normalization:
+    - `services/common/StripeService/StripeService.ts` (`createCheckoutSession`)
+  - Existing Genapi HTTP paths aligned with `createGenapiRequestLoggerFromPath(...)`:
+    - `services/common/GenapiService/GenapiService.ts` (`findDossierIdByFolderNumber`, `createEdocument`, `uploadDocumentData`)
+  - Existing Anchorage verify endpoint aligned with `createAnchorageRequestLoggerFromPath(...)`:
+    - `services/common/BitcoinSignetService/helpers/BitcoinSignetApiHelper.ts` (`verifyHashViaApi`)
+
+### Endpoints API
+
+**Offices** : `GET /api/pp/v2/entites?type=office&page={page}&size={size}&key={IDNOT_API_KEY}`
+**Personnes** : `GET /api/pp/v2/personnes?page={page}&size={size}&key={IDNOT_API_KEY}`
+**Rattachements** : `GET /api/pp/v2/personnes/{idnot}/rattachements?page={page}&size=100&key={IDNOT_API_KEY}`
+
+**Notes** :
+
+- Auth : la clé API se passe en query (puis fallback header x-api-key)
+- Pagination : utiliser page>=1 (ou 0 selon endpoint) et size=100
+- Erreurs : 403 accessDenied → essayer fallback /entites sans type et filtrer côté client
+
+### Tables
+
+Les tables historiques `annu_*` ne sont plus utilisées par l’application.
+
+### Synchronisation
+
+Les synchronisations batch (IdNot/Annuaire) ne sont plus exécutées via des scripts dédiés. La recherche et la résolution de confrères reposent sur des **appels API** (IdNot/Annuaire) au moment de la demande, complétés par la base du site (users/contacts/offices) et les partages (`folder_sharing`).
+
+### Troubleshooting
+
+**Erreur : Missing ANNUAIRE_API_LOGIN or ANNUAIRE_API_PASSWORD**
+
+- Solution : Injecter les clés dans `system_configuration` via le mécanisme standard d’injection (fichier `.secrets/<env>/env-full-<env>-for-bdd-injection.txt` puis déploiement).
+
+**Erreur : HTTP 401 Unauthorized**
+
+- Cause : Login ou mot de passe incorrect
+- Solution : Vérifier les credentials en base et mettre à jour si nécessaire
+
+**Erreur : HTTP 403 Forbidden**
+
+- Cause : Le compte n'a pas accès à l'API Annuaire
+- Solution : Contacter le support ID.NOT pour vérifier les droits du compte
+
+### Recherche confrères (appel direct API annuaire)
+
+La recherche de notaires pour inviter un confrère au partage de dossier utilise **uniquement l’API Annuaire** (pas de base du site ni de confrères déjà invités).
+
+**Endpoint exposé** : `GET /api/v1/notary/search/notaries?q={query}`
+
+- **Authentification** : session notaire (authHandler, permissionContextInjector).
+- **Paramètre** : `q` (string, min. 2 caractères) – nom, prénom, email ou nom d’office.
+- **Réponse** : `{ results: Array<...>, annuaireConfigured: boolean, message?: string }`. `results` : tableau d’objets `{ idNot, email, firstName, lastName, officeName, crpcen, isPrimary, displayName, hasActiveLicense?, phone? }`. Si l’annuaire n’est pas configuré : **503 Service Unavailable** avec le même format (`annuaireConfigured: false`, `message` explicatif, `results: []`). Pas de 200 avec résultats vides.
+
+**Comportement** :
+
+- Si `ANNUAIRE_API_BASE_URL` et `IDNOT_API_KEY` sont renseignés en base (`system_configuration`) : appel API Annuaire V2 avec **pagination complète** (pages de 50 jusqu’à épuisement) :
+  - **PB lookup** : `GET {ANNUAIRE_API_BASE_URL}/api/v2/directory/lookup?nomNotaire={query}&page=&size=50&key=...` (toutes les pages).
+  - **Fallback PP** : `GET {ANNUAIRE_API_BASE_URL}/api/pp/v2/personnes?prenom=...&nomUsuel=...&page=&size=50&key=...` (toutes les pages).
+- Si l’annuaire n’est pas configuré : réponse `{ results: [], annuaireConfigured: false, message }` ; le front affiche le message d’alerte (pas de fallback legacy IdNot).
+
+**Fichiers** :
+
+- `lecoffre-back-main/src/services/common/IdNotDirectoryService/IdNotDirectoryService.ts` : `searchNotaries()` retourne `SearchNotariesResponse` ; `getAnnuaireCredentials()`.
+- `lecoffre-back-main/src/services/common/IdNotDirectoryService/helpers/IdNotDirectoryApiSearchHelper.ts` : API Annuaire V2 (lookup + PP, pagination complète).
+- `lecoffre-back-main/src/app/api/notary/helpers/FolderSharingSearchHelper.ts` : renvoie `{ results, annuaireConfigured, message? }`.
+
+**Configuration** : `ANNUAIRE_API_BASE_URL`, `IDNOT_API_KEY` en base (`system_configuration`). Obligatoires pour que la recherche renvoie des résultats.
+
+### Notaire invité : email et IdNot en base (folder_sharing)
+
+Après la création d'un partage, **seul l'email en base** associé au notaire invité est utilisé pour les envois (invitations, relances, documents). Aucune relecture de l'email côté IdNot.
+
+- **Un seul champ email** : `invited_notary_email` = email de préférence pour les envois. À l'invitation il est en général pré-rempli depuis IdNot (annuaire) ; il peut être modifié avant enregistrement. **L'email IdNot et l'email de préférence sont donc le même champ en base** pour le notaire invité.
+- **Accès aux dossiers invités** : croisement sur l'**IdNot** (`invited_notary_idnot`). Quand l'utilisateur connecté a un IdNot, seuls les partages dont `invited_notary_idnot` correspond sont pris en compte. L'email en base n'est pas utilisé pour ce croisement.
+- **Profils avec IdNot** : à l'invitation, le partage enregistre `invited_notary_idnot`. Les notaires invités (y compris sans seat) ont en base un identifiant IdNot : sur chaque partage (`folder_sharing.invited_notary_idnot`), et après première connexion via IdNot sur le profil utilisateur (`users.idNot`).
+
+Voir aussi : `docs/ARCHITECTURE.md` § Partage Inter-Études, `docs/README.md` (consolidation opérationnelle).
+
+### Architecture
+
+Les synchronisations batch historiques (et les tables `annu_*` associées) ne sont plus utilisées par l’application. Les recherches de confrères et les résolutions (ex: par email) s’effectuent via des **appels API** (IdNot / Annuaire) au moment de la demande, avec complément de la base du site et des partages (`folder_sharing`).
+
+#### Déploiement
+
+Déploiement standard du backend via `deploy/scripts/build-and-deploy.sh <env>`. Aucune migration spécifique de tables `annu_*` n’est requise. Les appels API Annuaire/IdNot nécessitent que les clés correspondantes soient présentes dans `system_configuration` (injection via `.secrets/<env>/env-full-<env>-for-bdd-injection.txt` puis déploiement).
+
+### Sécurité
+
+**Authentification Basic Auth** :
+
+```http
+Authorization: Basic <base64(login:password)>
+```
+
+**Stockage des credentials** :
+
+- Login : Stocké en clair dans `system_configuration` (`is_sensitive: false`)
+- Password : Marqué comme sensible dans `system_configuration` (`is_sensitive: true`)
+- Affichage : Le mot de passe est masqué (`***`) dans l'interface super-admin
+
+**Logs** : Les logs ne contiennent **jamais** les credentials. Seuls les URLs (sans query params) et les codes HTTP sont loggés.
+
+### Tests et Vérification
+
+Les tests de connectivité et les vérifications se font via les parcours applicatifs qui déclenchent des appels API (IdNot / Annuaire), ou via les cartes de tests *live* de la page super-admin santé.
+
+### Troubleshooting API Annuaire
+
+**Erreur : Missing ANNUAIRE_API_LOGIN or ANNUAIRE_API_PASSWORD** :
+
+**Cause** : Les credentials ne sont pas en base de données.
+
+**Solution** :
+
+```bash
+deploy/scripts/build-and-deploy.sh test
+```
+
+**Erreur : HTTP 401 Unauthorized** :
+
+**Cause** : Login ou mot de passe incorrect.
+
+**Solution** :
+
+1. Vérifier les credentials en base :
+
+```sql
+SELECT key, value FROM system_configuration WHERE key LIKE 'ANNUAIRE_API_%';
+```
+
+2. Mettre à jour si nécessaire via l'interface super-admin ou le script.
+
+**Erreur : HTTP 403 Forbidden** :
+
+**Cause** : Le compte n'a pas accès à l'API Annuaire.
+
+**Solution** : Contacter le support ID.NOT pour vérifier les droits du compte.
+
+**Aucune donnée synchronisée** :
+
+**Cause** : Les pages retournent 0 résultats ou l'API retourne un format inattendu.
+
+**Solution** :
+
+1. Vérifier les logs backend (service API) pour les erreurs IdNot/Annuaire
+2. Regarder les "sample" logs (premier élément de chaque type)
+3. Adapter le parsing si nécessaire dans les helpers de recherche IdNot/Annuaire
+
+---
+
+## Rappels Automatiques Documents
+
+**Statut** : ✅ 100% | **Version** : 2.0.0
+
+### Architecture Backend
+
+**Service** : `DocumentRemindersService` (~350 lignes)
+**Fichier** : `lecoffre-back-main/src/services/notary/DocumentRemindersService/DocumentRemindersService.ts`
+
+**Repository** : `DocumentRemindersConfigRepository`
+
+### Endpoints
+
+**6 endpoints** (config CRUD + trigger manuel) :
+
+- `GET /api/v1/notary/document-types/:documentTypeUid/reminders/config` : Récupérer configuration pour un type de document
+- `GET /api/v1/notary/offices/:officeUid/reminders/config` : Liste toutes les configurations d'un office
+- `POST /api/v1/notary/document-types/:documentTypeUid/reminders/config` : Créer configuration
+- `PUT /api/v1/notary/document-types/:documentTypeUid/reminders/config` : Modifier configuration
+- `DELETE /api/v1/notary/document-types/:documentTypeUid/reminders/config` : Supprimer configuration
+- `POST /api/v1/notary/reminders/send` : Déclencher manuellement (⚠️ DÉSACTIVÉ - relances automatiques désactivées)
+
+**Cron** : `sendDocumentReminders()` quotidien 9h (⚠️ DÉSACTIVÉ - relances automatiques totalement désactivées, voir `CronService.ts` ligne 144-168)
+
+### Configuration Base de Données
+
+**Table** : `document_reminders_config`
+
+**Champs** :
+
+- `document_type_uid` : Type de document concerné
+- `office_uid` : Office concerné
+- `reminder_intervals` : JSON array d'intervalles en jours (ex: `[7, 14, 21]`)
+- `reminder_message` : Message personnalisé optionnel
+- `auto_send` : Envoi automatique activé (défaut: true)
+- `is_active` : Configuration active/inactive
+
+### Frontend
+
+**Pages** :
+
+- `/reminders/config.tsx` : Liste + toggle actif/inactif
+- `/folders/[uid]/documents-reminder-history` : Historique rappels
+
+**API** : `DocumentReminders` (~130 lignes)
+
+**Support destinataires** :
+
+- Clients : Relance via `depositor.uid`
+- Tiers : Relance via `third_party_depositor.uid` (v2.0.0)
+- Notaires invités : Relance via `shared_to_office.uid` (v2.0.1)
+
+### Fonctionnalités
+
+- **Intervalles configurables** : Ex: [7, 14, 21] jours après demande
+- **Message personnalisé** : Optionnel par type document + office
+- **Configuration par type document + office** : Granularité fine
+- **Activation/désactivation** : Via champ `isActive` dans la configuration (pas d'endpoint toggle dédié)
+- **Trigger manuel** : ⚠️ DÉSACTIVÉ - L'endpoint `POST /api/v1/notary/reminders/send` est désactivé. Utiliser `/api/v1/notary/customers/:uid/send_reminder` pour les relances manuelles
+- **Évite doublons** : 1 rappel/jour maximum par document
+- **Support notaires invités** : Relance possible pour les confrères via partage inter-études (v2.0.1)
+
+### Configuration Système
+
+**Variable** : `CRON_SEND_REMINDERS_ENABLED` (dans `system_configuration`)
+**Gestion** : Désactivable via `/super-admin/system-config`
+
+---
+
+## Opérations Batch
+
+**Statut** : ✅ 100% | **Version** : 2.0.0
+
+### Certificat Unique Dossier
+
+**Service** : `FolderAnchorCertificateService`
+**Fonctionnalité** : PDF unique pour dossier complet
+
+**Inclut** :
+
+- Liste tous documents ancrés
+- Merkle root dossier
+- Hash ZIP complet
+- Informations blockchain
+
+### Envoi Documents par Destinataire
+
+**Backend** :
+
+- **Endpoint** : `POST /api/v1/notary/documents_notary/send`
+- **Body** : `recipientUid`, `folderUid`, `files` (FormData)
+- **Middleware** : `multer().array("files", 20)` (20 fichiers max)
+- **Logique** : Un destinataire par appel ; le frontend boucle sur les destinataires sélectionnés et agrège les résultats
+
+**Note** : Route exclue du middleware multer global (voir [README.md](./README.md#consolidation-operationnelle-ex-operationsmd))
+
+### Filtres Avancés
+
+**Backend** :
+
+- **Service** : `FolderSearchService`
+- **Controller** : `FolderSearchController`
+- **Endpoint** : `POST /api/v1/notary/folders/search`
+
+**Filtres disponibles** :
+
+- Numéro dossier
+- Nom dossier
+- Type acte
+- Office
+- Statut (LIVE, ARCHIVED, DELETED)
+- Date création
+- Collaborateurs
+
+### Téléchargement Multiple
+
+**Backend** :
+
+- **Service** : `ZipService`
+- **Endpoint** : `POST /api/v1/notary/files/download-multiple`
+
+**Fonctionnalités** :
+
+- Sélection multiple fichiers
+- Conversion automatique en PDF si nécessaire
+- Ajout filigrane "lecoffre.io" (préfixe "acpl_")
+- Ajout métadonnées d'ancrage dans les PDF
+- Inclut certificats d'ancrage si disponibles
+- Utilise versions filigrannées existantes
+
+**Fichier** : `lecoffre-back-main/src/services/common/ZipService/ZipService.ts`
+
+### Certificat Agrégé Documents
+
+**Statut** : ✅ 100% | **Version** : 2.1.0
+
+**Service** : `AggregatedCertificateService`
+**Fichier** : `lecoffre-back-main/src/services/notary/AggregatedCertificateService/AggregatedCertificateService.ts`
+
+**Fonctionnalités** :
+
+- Génération d'un certificat PDF unique pour plusieurs documents sélectionnés
+- Support des Documents (documents validés) et DocumentsNotary (documents envoyés)
+- Ancrage du certificat sur la blockchain Bitcoin Signet
+- Upload du certificat sur IPFS
+- Inclusion automatique dans les ZIP téléchargés
+
+**Endpoints** :
+
+- `POST /api/v1/notary/files/download-aggregated-certificate` : Certificat agrégé pour Documents
+- `POST /api/v1/notary/files-notary/download-aggregated-certificate` : Certificat agrégé pour DocumentsNotary
+
+**Limite** : 100 documents maximum par certificat
+
+---
+
+### Mémo API Annuaire (Qualification)
+
+**Endpoints** :
+
+- ID.not Auth: `https://qual-connexion.idnot.fr` (authorize/token)
+- Annuaire base: `https://qual-api.notaires.fr/annuaire`
+- Recherche personnes (si supporté): `GET {base}/persons?q={query}` avec header `x-api-key`
+- Entités (offices): `GET /api/pp/v2/entites?type=office&page={page}&size={size}&key={IDNOT_API_KEY}`
+- Fallback offices: `GET /api/pp/v2/entites?key={IDNOT_API_KEY}` → filtrer `typeEntite.name==office`
+- Personnes: `GET /api/pp/v2/personnes?page={page}&size={size}&key={IDNOT_API_KEY}`
+- Rattachements: `GET /api/pp/v2/personnes/{idnot}/rattachements?page={page}&size=100&key={IDNOT_API_KEY}`
+
+**Notes** :
+
+- Auth : la clé API se passe en query (puis fallback header x-api-key)
+- Pagination : utiliser page>=1 (ou 0 selon endpoint) et size=100
+- Erreurs : 403 accessDenied → essayer fallback /entites sans type et filtrer côté client
+- Sécurité : ne publier aucune valeur de clé
+
+---
+
+### Exemple de Client pour l'API d'Ancrage
+
+Un exemple complet de client Node.js pour tester l'API d'ancrage est disponible dans le code source. Le client permet de :
+
+- Vérifier l'état de l'API (`/health`)
+- Ancrer un document (`POST /api/anchor/document`)
+- Vérifier un ancrage (`POST /api/anchor/verify`)
+
+**Fonctionnement synchrone** : L'API retourne directement le `txid` dans la réponse (HTTP 200 OK), pas besoin de polling ou de status endpoint.
+
+**Points importants** :
+
+- L'API retourne directement le `txid` dans la réponse (fonctionnement synchrone)
+- Le code HTTP est **200 OK** (pas 202 Accepted)
+- Toutes les informations sont disponibles immédiatement (confirmations, block_height)
+
+Voir le code source dans `lecoffre-anchor-api/` pour l'exemple complet de client.
+
+### Mise à jour de l'URL de l'API d'ancrage
+
+**Date** : 2026-01-27
+
+**URL mise à jour** : L'URL de l'API d'ancrage a été changée de `https://prod.signet.4nkweb.com` vers `https://anchorage.certificator.4nkweb.com`.
+
+**Fichiers à mettre à jour** :
+
+**1. Fichiers `.secrets/<env>/env-full-<env>-for-bdd-injection.txt`** :
+
+Ces fichiers sont utilisés pour injecter les variables dans la base de données via `setSettings`.
+
+**Emplacements** :
+
+- `.secrets/test/env-full-test-for-bdd-injection.txt`
+- `.secrets/pprod/env-full-pprod-for-bdd-injection.txt`
+- `.secrets/prod/env-full-prod-for-bdd-injection.txt`
+
+**Variable à mettre à jour** :
+
+```bash
+ANCHORE_API_URL=https://anchorage.certificator.4nkweb.com
+```
+
+**Note** : Ces fichiers ne sont pas versionnés (dans `.gitignore`) et doivent être mis à jour manuellement sur chaque machine de développement.
+
+**2. Base de données (via `system_configuration`)** :
+
+Si les fichiers `env-full-*-for-bdd-injection.txt` ont déjà été injectés, la valeur dans la base de données doit être mise à jour :
+
+**Requête SQL** :
+
+```sql
+UPDATE system_configuration
+SET value = 'https://anchorage.certificator.4nkweb.com'
+WHERE key = 'ANCHORE_API_URL'
+  AND category = 'INTEGRATION_BITCOIN';
+```
+
+**Ou via le script `setSettings`** :
+
+```bash
+# Après avoir mis à jour le fichier env-full-<env>-for-bdd-injection.txt
+bash deploy/scripts_v2/remote/set-settings.sh <env> <domain> <app_root>
+```
+
+**Vérification** :
+
+```bash
+# Depuis le backend
+cd lecoffre-back-main
+npm run anchorage:test-anchor-api
+```
+
+Le script doit afficher :
+
+```text
+✅ [TestAnchorAPI] Variables récupérées depuis la BDD
+   URL: https://anchorage.certificator.4nkweb.com
+```
+
+**Problème 502 Bad Gateway** : Si vous rencontrez des erreurs **502 Bad Gateway** :
+
+- Vérifier l'état du service : `systemctl --user status anchor-api.service`
+- Vérifier que le service écoute sur le port 3004 : `ss -tlnp | grep 3004`
+- Tester depuis le backend : `curl -s http://localhost:3004/health`
+- Configuration Nginx : Route `anchorage.certificator.4nkweb.com` → `192.168.1.103:3004`
+
+**Configuration actuelle** :
+
+- **Service** : `anchor-api.service` (user service)
+- **Port** : `3004` (configuré dans `.env` et systemd)
+- **Nginx** : Route `anchorage.certificator.4nkweb.com` → `192.168.1.103:3004`
+- **Bitcoin RPC** : `localhost:18443` (Signet)
+
+---
+
+**Dernière mise à jour** : 2026-01-28 (consolidation API.md, API_ANNUAIRE_IMPLEMENTATION.md, API_MEMO.md, ANCHOR_API_ANALYSIS.md, ANCHOR_API_EXAMPLE_CLIENT.md, UPDATE_ANCHOR_API_URL.md)
+
+## Correctif accès invités notaires (2026-03-02)
+
+**Problème observé** :
+
+- Un notaire invité pouvait voir des dossiers partagés (`GUEST_FOLDERS`) mais être déconnecté à l'ouverture d'un dossier lors de `GET /v1/notary/documents`.
+
+**Cause racine** :
+
+- Des chemins helper notaire appelaient encore `FolderSharingService.hasAccess(folderUid, officeUid, email)` sans propagation de `idNot`, malgré la centralisation d'identité déjà engagée.
+
+**Correctif appliqué** :
+
+- Propagation de `idNot` dans les appels de contrôle d'accès des helpers notaire concernés.
+- Extension du même alignement à des helpers customer/middleware/service où la vérification restait email-only.
+- Réutilisation de l'extraction d'identité centralisée `buildUserIdentityContext` pour éviter les divergences de signature d'appel.
+
+**Effet attendu** :
+
+- Les contrôles d'accès invités notaires utilisent de manière cohérente l'identité `idNot` sur le flux `GUEST_FOLDERS`, sans régression sur les flux non-notaire (où `userIdNot` reste optionnel).
diff --git a/projects/lecoffreio/docs/ARCHITECTURE.md b/projects/lecoffreio/docs/ARCHITECTURE.md
new file mode 100644
index 0000000..17647b2
--- /dev/null
+++ b/projects/lecoffreio/docs/ARCHITECTURE.md
@@ -0,0 +1,1789 @@
+# Architecture LeCoffre.io
+
+**Dernière mise à jour** : 2026-01-28
+**Version** : 2.1.0
+
+**Référence unique (checks de déploiement)** : [`docs/DEPLOYMENT.md#cartographie-des-checks-de-déploiement-source-unique`](./DEPLOYMENT.md#cartographie-des-checks-de-déploiement-source-unique)
+
+Ce document décrit l'architecture complète de LeCoffre.io : infrastructure physique, architecture logicielle, configuration des serveurs, types d'utilisateurs, rôles et permissions, gestion multi-office, et ancrage blockchain.
+
+---
+
+## 📋 Table des Matières
+
+1. [Architecture Physique](#architecture-physique)
+2. [Architecture Logicielle (Monorepo)](#architecture-logicielle-monorepo)
+3. [Configuration Initiale des Serveurs](#configuration-initiale-des-serveurs)
+4. [Environnements](#environnements)
+5. [Services Externes](#services-externes)
+6. [Types d'Utilisateurs](#types-dutilisateurs)
+7. [Architecture Rôles & Règles](#architecture-rôles--règles)
+8. [Matrice des Permissions](#matrice-des-permissions)
+9. [JWT Multi-Office](#jwt-multi-office)
+10. [Évolution planifiée - Documents unifiés](#évolution-planifiée---documents-unifiés)
+11. [Partage Inter-Études](#partage-inter-études)
+12. [Gestion Multi-Office](#gestion-multi-office)
+13. [Ancrage Blockchain](#ancrage-blockchain)
+
+---
+
+## Architecture Physique
+
+### Infrastructure Serveurs
+
+LeCoffre.io est déployé sur une infrastructure **privée** (réseau `192.168.1.x`) avec un **proxy** public en point d'entrée unique.
+
+#### VM Environnements (Application)
+
+| Environnement | IP | Domaine | Répertoire |
+|---------------|-----|---------|------------|
+| **test** | `192.168.1.101` | `test.lecoffreio.4nkweb.com` | `/srv/4NK/test.lecoffreio.4nkweb.com` |
+| **pprod** | `192.168.1.102` | `pprod.lecoffreio.4nkweb.com` | `/srv/4NK/pprod.lecoffreio.4nkweb.com` |
+| **prod** | `192.168.1.103` | `prod.lecoffreio.4nkweb.com` | `/srv/4NK/prod.lecoffreio.4nkweb.com` |
+
+**Proxy (point d'entrée)** :
+
+- IP privée : `192.168.1.100`
+- Accès externe : `4nk.myftp.biz`
+- Rôle : terminaison SSL + routage Nginx vers les **ports applicatifs** des serveurs `101/102/103`.
+
+**Services déployés sur chaque serveur environnement (host-native, systemd)** :
+
+- PostgreSQL (service système)
+- ClamAV (service système)
+- Backend (systemd)
+- Cron (systemd)
+- Frontend (systemd)
+- Routeur HTTP local (Node) sur le port "service" (systemd)
+
+**Important :**
+
+- Il n'y a **pas de Nginx** ni Certbot sur `101/102/103`.
+- Les déploiements "v2" sont gérés par `deploy/scripts_v2/` (orchestrés depuis le proxy).
+
+#### VM Git (Repository)
+
+**Serveur Git** : `git.4nkweb.com`
+**Repository** : `git@git.4nkweb.com:4nk/lecoffreio.git`
+
+**Rôle** :
+
+- Stockage du code source (monorepo)
+- Versioning Git
+- Synchronisation entre machines locales et serveurs de déploiement
+
+**Workflow** :
+
+1. Développement local → commit/push vers Git
+2. Script de déploiement → pull depuis Git sur VM environnement
+3. Build et déploiement sur VM environnement
+
+#### VM Base de Données
+
+**PostgreSQL externe** :
+
+- **Host** : Variable selon environnement (`DATABASE_HOST` dans `.env.<env>`)
+- **Port** : **5432** (standard PostgreSQL en mode host-native)
+- **Utilisateurs** : `lecoffre-user-{env}` (un par environnement)
+- **Bases** : `bdd-{env}` (une par environnement)
+
+**Accès** :
+
+- Depuis VM environnements sur l'hôte
+- Depuis machines locales via SSH tunnel (optionnel)
+
+#### VM API Ancrage Bitcoin (Séparée)
+
+**Serveur** : `dev3.4nkweb.com`
+**Host SSH** : `<USER>@31.33.24.235`
+**Répertoire** : `/home/<USER>/dev/lecoffre-anchor-api`
+**Port** : `3002`
+**Health** : `http://31.33.24.235:3002/health`
+
+**Rôle** :
+
+- API d'ancrage blockchain Bitcoin Signet
+- Service séparé pour isolation et scalabilité
+- Appelée par le backend principal pour les ancrages
+
+### Réseau et Communication
+
+```text
+┌─────────────────────────────────────────────────────────────┐
+│                    Machine Dev (externe)                    │
+│                                                             │
+│  ┌──────────────┐                                           │
+│  │  Git Client  │ ────SSH───> Proxy (4nk.myftp.biz)         │
+│  └──────────────┘                                           │
+│                                                             │
+│  ┌──────────────┐                                           │
+│  │ Deploy Script│ ────SSH───> Proxy (orchestrateur)         │
+│  └──────────────┘                                           │
+└─────────────────────────────────────────────────────────────┘
+                              │
+                              │ SSH (réseau privé)
+                              ▼
+┌─────────────────────────────────────────────────────────────┐
+│              Serveurs Environnements (101/102/103)           │
+│                                                             │
+│  ┌──────────────┐                                           │
+│  │   Git Pull   │ <───SSH─── Git (git.4nkweb.com)           │
+│  └──────────────┘                                           │
+│                                                             │
+│  ┌──────────────┐                                           │
+│  │  systemd     │  - backend / cron / frontend / router     │
+│  └──────────────┘                                           │
+│         │                                                    │
+│         │ PostgreSQL (port 5432)                             │
+│         ▼                                                    │
+│  ┌──────────────┐                                           │
+│  │  PostgreSQL  │ (VM Base de Données externe)              │
+│  └──────────────┘                                           │
+└─────────────────────────────────────────────────────────────┘
+```
+
+### Persistance des Données
+
+| Type | Emplacement | Persistance |
+|------|-------------|-------------|
+| **Code source** | VM Git (git.4nkweb.com) | ✅ Git repository |
+| **Code déployé** | VM Environnement (`/home/debian/sites/...`) | ✅ Host filesystem |
+| **Base de données** | VM PostgreSQL externe | ✅ PostgreSQL |
+| **Certificats SSL** | VM Environnement (`deploy/nginx/certbot/`) | ✅ Host filesystem (bind mount) |
+| **Configuration Nginx** | VM Environnement (`deploy/nginx/nginx-*.conf`) | ✅ Host filesystem (bind mount) |
+| **Backups BDD** | VM Environnement (`deploy/backups/`) | ✅ Host filesystem |
+| **Backups certificats** | VM Environnement (`deploy/certificats/`) | ✅ Host filesystem |
+| **Logs** | VM Environnement (`logs/`) | ✅ Host filesystem (collectés par Promtail) |
+| **Build backend/frontend** | VM Environnement | ⚠️ Rebuild à chaque déploiement |
+| **node_modules** | VM Environnement (dans le build) | ❌ Non persistant (rebuild) |
+
+---
+
+## Architecture Logicielle (Monorepo)
+
+### Structure du Monorepo
+
+LeCoffre.io est organisé en **monorepo** contenant 4 sous-projets principaux :
+
+```text
+lecoffreio/                          # Repository global (ce repo)
+│
+├── lecoffre-back-main/             # Backend API (Express + TypeScript)
+│   ├── src/                        # Code source TypeScript
+│   │   ├── app/                    # Controllers & Middlewares
+│   │   │   ├── api/                # Routes API (notary, admin, customer, public)
+│   │   │   └── middleware/         # Middlewares (auth, rate limiting, CORS)
+│   │   ├── services/               # Business Logic
+│   │   │   ├── admin/              # Services admin
+│   │   │   ├── common/             # Services communs (IdNot, Annuaire, Stripe, Bitcoin)
+│   │   │   ├── customer/           # Services clients
+│   │   │   ├── notary/             # Services notaires
+│   │   │   └── super-admin/        # Services super-admin
+│   │   ├── common/                 # Utilities & Repositories
+│   │   │   ├── databases/          # Prisma schema & migrations
+│   │   │   ├── dtos/               # DTOs validation
+│   │   │   ├── emails/             # Services email
+│   │   │   ├── repositories/       # Couche d'accès données
+│   │   │   └── utils/              # Helpers centralisés
+│   │   └── entries/                # Entry points
+│   │       └── App.ts              # Point d'entrée API
+│   ├── dist/                       # Build JavaScript (généré)
+│   ├── prisma/                     # Migrations base de données
+│   └── package.json                # Dependencies backend
+│
+├── lecoffre-front-main/            # Frontend Web (Next.js + React)
+│   ├── src/
+│   │   ├── pages/                  # Pages Next.js (routes)
+│   │   │   ├── folders/            # Routes dossiers
+│   │   │   ├── admin/              # Routes admin
+│   │   │   ├── subscription/       # Routes abonnements
+│   │   │   └── ...
+│   │   ├── front/                  # Components React
+│   │   │   ├── Components/         # UI Components
+│   │   │   │   ├── DesignSystem/   # Design system (Header, Footer, etc.)
+│   │   │   │   ├── Layouts/        # Layouts (Folder, Subscription, etc.)
+│   │   │   │   └── Elements/       # Éléments UI (Buttons, Forms, etc.)
+│   │   │   ├── Api/                # API Services (59 services)
+│   │   │   ├── Hooks/              # Custom React Hooks
+│   │   │   ├── Services/           # Frontend Services
+│   │   │   ├── Stores/             # State management (MobX)
+│   │   │   └── Utils/              # Utilitaires
+│   │   └── proxy.ts                # Next.js Proxy (auth)
+│   ├── public/                     # Assets statiques
+│   └── package.json                # Dependencies frontend
+│
+├── lecoffre-ressources-dev/        # Resources TypeScript partagées
+│   ├── src/
+│   │   ├── Admin/                  # Types Admin (22 types)
+│   │   ├── Notary/                 # Types Notary (29 types)
+│   │   ├── Customer/               # Types Customer (15 types)
+│   │   └── SuperAdmin/             # Types SuperAdmin (20 types)
+│   └── package.json                # Dependencies resources
+│
+├── lecoffre-anchor-api/            # API d'ancrage Bitcoin (serveur séparé)
+│   ├── src/
+│   │   ├── config/                 # Configuration logger
+│   │   ├── controllers/            # Controllers API ancrage
+│   │   ├── services/               # Bitcoin + Queue services
+│   │   └── types/                  # Types ancrage
+│   └── package.json                # Dependencies anchor API
+│
+├── docs/                           # Documentation technique
+├── todoFix/                        # Corrections et fixes documentés
+├── IA_agents/                      # Règles pour IA
+├── deploy/                         # Déploiement et outils
+│   ├── scripts/                    # Scripts de déploiement
+│   ├── nginx/                      # Configuration Nginx
+│   ├── monitoring/                 # Configuration Grafana/Loki
+│   └── scripts_v2/                 # Scripts déploiement host-native
+├── logs/                           # Logs de déploiement
+├── VERSION                         # Version actuelle
+├── CHANGELOG.md                    # Historique des versions
+└── README.md                       # Documentation principale
+```
+
+### Rôles des Sous-Projets
+
+| Sous-Projet | Rôle | Technologies | Port |
+|-------------|------|--------------|------|
+| **lecoffre-back-main** | API REST, authentification, business logic | Express, TypeScript, Prisma, PostgreSQL | 3001 |
+| **lecoffre-front-main** | Interface web responsive, SSR | Next.js 14, React 18, TypeScript, SCSS | 3000 |
+| **lecoffre-ressources-dev** | Types TypeScript partagés | TypeScript | - |
+| **lecoffre-anchor-api** | API d'ancrage blockchain Bitcoin Signet | Express, TypeScript, Bitcoin RPC | 3002 |
+
+### Dépendances Inter-Projets
+
+```text
+lecoffre-back-main
+    └── lecoffre-ressources-dev (types partagés)
+
+lecoffre-front-main
+    └── lecoffre-ressources-dev (types partagés)
+
+lecoffre-anchor-api
+    └── (indépendant)
+```
+
+**Build order** :
+
+1. `lecoffre-ressources-dev` : Compilation TypeScript → 87 fichiers `.js`
+2. `lecoffre-back-main` : Utilise les types compilés
+3. `lecoffre-front-main` : Utilise les types compilés
+4. `lecoffre-anchor-api` : Build indépendant (serveur séparé)
+
+### Communication Inter-Services
+
+#### Backend ↔ Frontend
+
+- **Protocole** : HTTP/HTTPS
+- **Format** : JSON (REST API)
+- **Authentification** : JWT (Bearer token)
+- **Endpoints** : `/api/v1/{notary|admin|customer|public}/...`
+
+#### Backend ↔ Anchor API
+
+- **Protocole** : HTTP
+- **Format** : JSON
+- **Authentification** : API Key (`ANCHORE_API_KEY`)
+- **Endpoint** : `http://<DOMAINE_BITCOIN>:3002/anchor`
+
+#### Backend ↔ Services Externes
+
+- **PostgreSQL** : Prisma ORM (port 5432 en host-native)
+- **IdNot** : OAuth2 (HTTPS)
+- **API Annuaire** : Basic Auth (HTTPS)
+- **Stripe** : API Key (HTTPS)
+- **Pinata (IPFS)** : API Key (HTTPS)
+- **Mailchimp** : API Key (HTTPS)
+- **OVH SMS** : API Key (HTTPS)
+- **ClamAV** : TCP (port 3310)
+
+---
+
+## Configuration Initiale des Serveurs
+
+### Vue d'ensemble
+
+Le script `setup-all-servers.sh` permet de configurer automatiquement toutes les machines distantes avec :
+
+- Configuration de `/etc/hosts` pour la résolution de noms
+- Configuration sudo NOPASSWD pour l'utilisateur `ncantu`
+- Installation des outils système (git, curl, wget)
+- Installation et configuration des services (Node, PostgreSQL, etc.)
+
+**Serveurs configurés** :
+
+- `test` (192.168.1.101) : Environnement de test
+- `pprod` (192.168.1.102) : Pré-production
+- `prod` (192.168.1.103) : Production
+
+**Point d'entrée** : Proxy (4nk.myftp.biz) via SSH ProxyJump
+
+### Prérequis
+
+**Sur la machine locale** :
+
+- Accès SSH au proxy (4nk.myftp.biz)
+- Clé SSH configurée pour l'utilisateur `ncantu`
+- Bash disponible (Git Bash sur Windows)
+- Mot de passe sudo des serveurs distants : `picnic1280`
+
+**Sur les serveurs distants** :
+
+- Accès SSH depuis le proxy
+- Utilisateur `ncantu` avec droits sudo
+- Connexion Internet pour télécharger les paquets
+
+### Script de configuration
+
+**Fichier** : `deploy/scripts/backup/setup-all-servers.sh`
+
+**Description** : Script bash qui se connecte à chaque serveur via SSH (ProxyJump) et exécute un script de configuration distant.
+
+### Fonctionnalités
+
+#### 1. Configuration de `/etc/hosts`
+
+Ajoute les entrées suivantes dans `/etc/hosts` de chaque serveur :
+
+```text
+192.168.1.100 proxy
+192.168.1.101 test
+192.168.1.102 pprod
+192.168.1.103 prod
+192.168.1.104 services
+```
+
+**Avantages** :
+
+- Résolution de noms locale sans dépendre du DNS
+- Accès rapide entre serveurs
+- Indépendance du réseau externe
+
+#### 2. Configuration sudo NOPASSWD
+
+Configure l'utilisateur `ncantu` pour utiliser sudo sans mot de passe :
+
+```text
+ncantu ALL=(ALL) NOPASSWD: ALL
+```
+
+**Fichier créé** : `/etc/sudoers.d/ncantu-nopasswd`
+
+**Sécurité** : Cette configuration permet à l'utilisateur `ncantu` d'exécuter toutes les commandes sudo sans mot de passe. À utiliser uniquement sur des serveurs d'infrastructure avec accès SSH sécurisé.
+
+#### 3. Installation des outils système
+
+Installe les outils suivants via `apt-get` (Debian/Ubuntu) ou `yum` (CentOS/RHEL) :
+
+- **git** : Gestion de versions
+- **curl** : Téléchargement de fichiers
+- **wget** : Téléchargement de fichiers (alternative)
+
+#### 4. Prérequis serveur
+
+Le script vérifie et installe les prérequis selon la distribution (Debian/Ubuntu) : git, curl, wget, Node.js, PostgreSQL, etc. Voir [DEPLOYMENT.md](./DEPLOYMENT.md) et section "Configuration Initiale des Serveurs" ci-dessus.
+
+### Utilisation
+
+**Exécution du script** :
+
+```bash
+cd d:\code\lecoffreio
+bash deploy/scripts/backup/setup-all-servers.sh
+```
+
+**Configuration** :
+
+Le script contient les variables suivantes (modifiables si nécessaire) :
+
+```bash
+PROXY_HOST="ncantu@4nk.myftp.biz"
+SUDO_PASSWORD="picnic1280"
+
+SERVERS=(
+    "192.168.1.101:test"
+    "192.168.1.102:pprod"
+    "192.168.1.103:prod"
+)
+```
+
+### Architecture SSH
+
+Le script utilise SSH ProxyJump pour se connecter aux serveurs backend via le proxy :
+
+```text
+Client Local → Proxy (4nk.myftp.biz) → Serveur Backend (192.168.1.10x)
+```
+
+**Commande SSH** :
+
+```bash
+ssh -J ncantu@4nk.myftp.biz ncantu@192.168.1.101
+```
+
+### Vérifications post-configuration
+
+**Vérification manuelle** :
+
+```bash
+# Se connecter au serveur
+ssh -J ncantu@4nk.myftp.biz ncantu@192.168.1.101
+
+# Vérifier /etc/hosts
+cat /etc/hosts | grep "192.168.1.10"
+
+# Vérifier sudo NOPASSWD
+sudo -n true && echo "OK" || echo "KO"
+
+# Vérifier les outils
+which git curl wget node
+node --version
+```
+
+**Notes importantes** :
+
+- ⚠️ Le script configure sudo NOPASSWD pour **toutes** les commandes
+- ⚠️ À utiliser uniquement sur des serveurs d'infrastructure avec accès SSH sécurisé
+- ⚠️ Le mot de passe sudo est codé en dur dans le script (à modifier si nécessaire)
+- Le script est idempotent : peut être exécuté plusieurs fois sans problème
+
+---
+
+## Environnements
+
+### Environnements Disponibles
+
+| Environnement | Usage | Domaine | Base de Données |
+|---------------|-------|---------|-----------------|
+| **test** | Tests et développement | `test-lecoffreio.4nkweb.com` | `bdd-test` |
+| **pprod** | Pré-production | `pprod-lecoffreio.4nkweb.com` | `bdd-pprod` |
+| **prod** | Production | `prod-lecoffreio.4nkweb.com` | `bdd-prod` |
+| **demo** | Démonstration | `demo-lecoffreio.4nkweb.com` | `bdd-demo` |
+
+### Configuration par Environnement
+
+Chaque environnement a sa propre configuration (legacy vs scripts_v2) :
+
+```bash
+# scripts_v2 (host-native, recommandé)
+DEPLOY_SSH_USER=ncantu
+DEPLOY_SSH_KEY=~/.ssh/id_ed25519
+DEPLOY_SSH_PROXY_HOST=4nk.myftp.biz
+
+# Base de données (souvent locale au host env)
+DATABASE_HOST=127.0.0.1
+DATABASE_PORT=5432
+DATABASE_USERNAME=lecoffre-user-<env>
+DATABASE_PASSWORD=***
+DATABASE_NAME=bdd-<env>
+```
+
+---
+
+## Services Externes
+
+### Services Utilisés
+
+| Service | Usage | Configuration |
+|---------|-------|---------------|
+| **PostgreSQL** | Base de données principale | Port 5432 (host-native) |
+| **Bitcoin Signet** | Ancrage blockchain | RPC (port 38332) |
+| **IPFS Pinata** | Stockage décentralisé fichiers | API Key |
+| **ClamAV** | Scan antivirus uploads | Service système (TCP 3310) |
+| **Mailchimp** | Emails transactionnels | API Key |
+| **OVH SMS** | Notifications SMS | API Key |
+| **Stripe** | Gestion paiements | API Key |
+| **IdNot** | OAuth notarial | OAuth2 |
+| **API Annuaire** | Synchronisation offices/personnes | Basic Auth |
+
+### Configuration Dynamique
+
+Les configurations sensibles sont stockées dans la base de données (`system_configuration`) plutôt que dans les fichiers `.env` :
+
+- **109 configurations** disponibles
+- **Injection** : Via `npm run config:import-env -- --env <env>`
+- **Lecture** : Via `BackendVariables` (backend)
+- **Sécurité** : Masquage des valeurs sensibles dans les logs
+
+Voir [DATABASE_COMPLETE.md](./DATABASE_COMPLETE.md#configuration-systeme-dynamique) pour plus de détails sur `system_configuration`.
+
+---
+
+## Types d'Utilisateurs
+
+Le système LeCoffre gère **4 types d'utilisateurs** avec des mécanismes d'authentification et d'autorisation différents.
+
+### 1. Notaires authentifiés IdNot (avec abonnement)
+
+**Caractéristiques** :
+
+- Authentification via **IdNot OAuth**
+- Stockés dans table `users`
+- Possèdent un `office_role_uid` (lié à leur rôle dans l'office)
+- **Abonnement actif** requis pour accès complet
+- Accès via JWT contenant : `userId`, `office_Id`, `role` (global), `rules` (role + office_role), `isSuperAdmin` (boolean, si `users.is_super_admin === true`)
+
+**Rôles possibles** :
+
+- `role` global : `admin`, `super-admin`, `notary`, `default`
+- `office_role` : `Notaire`, `Collaborateur` (lié à l'office)
+
+**Règles d'accès** :
+
+- JWT contient **toutes les règles** combinées (`role.rules` + `office_role.rules`)
+- Accès complet selon règles assignées
+- Exemple : `POST rib`, `GET folders`, `DELETE documents`, etc.
+
+**Création** :
+
+1. Connexion IdNot OAuth
+2. Appel API IdNot `/api/pp/v2/rattachements/{profile_idn}`
+3. Création automatique de l'`office` si n'existe pas
+4. Duplication `office_roles` depuis Office Template (idNot "0000")
+5. Assignment automatique `office_role` selon `typeLien.name` IdNot :
+   - `NOTAIRE_TITULAIRE`, `NOTAIRE_ASSOCIE`, `NOTAIRE_SALARIE` → "Notaire"
+   - `COLLABORATEUR`, `SUPPLEANT`, `ADMINISTRATEUR`, `CURATEUR` → "Collaborateur"
+
+**À la connexion (mise à jour)** : les données contact (nom, prénom, téléphones, civilité) sont synchronisées depuis IdNot ; **l’email en base n’est pas mis à jour** s’il existe déjà (les notaires conservent l’email stocké). Implémentation : `IdNotService.updateContactFromRattachement` (condition `!normalizedCurrentEmail`) et `AffiliationSyncContactDataExtractionHelper.buildContactUpdateDataFromComparison` (condition `newEmail && !currentEmail`).
+
+### 2. Notaires visiteurs (authentifiés IdNot, SANS abonnement)
+
+**Caractéristiques** :
+
+- Identiques aux notaires authentifiés IdNot mais **sans abonnement actif**
+- `hasActiveSubscription === false` dans le payload JWT
+- **Nouveau flag JWT** : `isVisitor = true`
+- Le rôle d'office renvoyé au frontend est forcé à `Visiteur`
+- L'UI affiche un badge `Visiteur` (OfficeSelector) au lieu de `(invité)`
+
+**Règles d'accès** :
+
+- Filtrage serveur → seuls les endpoints `GET *` et le parcours d'abonnement restent autorisés :
+  - `GET /api/v1/admin/subscriptions`
+  - `GET /api/v1/admin/subscription-plans`
+  - `POST /api/v1/admin/stripe`
+  - `PUT /api/v1/admin/subscriptions`
+  - `GET /api/v1/admin/stripe/:uid/client-portal`
+- **Toutes les autres règles (POST/PUT/DELETE dossiers, documents, etc.) sont retirées du JWT**
+- Les contrôles frontend reposent donc uniquement sur `jwt.rules` (plus de bouton "Créer un dossier")
+
+**Effets frontend** :
+
+- Badge `Visiteur` dans le sélecteur d'étude (`OfficeSelector`)
+- Absence du CTA "Créer un dossier" et des actions de modification
+- Parcours abonnement toujours visible (composants conditionnés sur `jwt.rules`)
+- Lorsqu'un notaire invité ouvre un dossier partagé, l'interface monte automatiquement le template client (`DefaultCustomerDashboard`) pour éviter les états parasites issus des composants notaire (onglets, CTA, hooks permissions) et garantir une lecture seule stricte.
+- La liste complète des dossiers invités et la vue détail utilisent maintenant la même expérience que les clients (sections "Documents envoyés / reçus" basées sur `DocumentTables`), sans onglets notaire ni actions d'édition.
+
+**But** :
+
+- Permettre à un notaire sans abonnement actif de **naviguer en lecture seule** et de souscrire
+- Faciliter l'onboarding multi-office
+
+### 3. Clients (Customers)
+
+**Caractéristiques** :
+
+- Authentification via **email + password** ou **code 2FA**
+- Stockés dans table `customers` (**PAS** dans `users`)
+- **Pas de `office_role_uid`** (n'existent pas dans `users`)
+- JWT différent : `ICustomerJwtPayload` avec `customerId` et `email`
+
+**Règles d'accès** :
+
+- Endpoints dédiés préfixés `/api/v1/customer/*`
+- Authentification via `customerAuthHandler` (différent de `authHandler`)
+- Accès limité à :
+  - Leurs propres dossiers
+  - Leurs propres documents
+  - Upload de documents demandés
+
+**Création** :
+
+1. Notaire crée un client via `POST /api/v1/notary/customers`
+2. Client reçoit email avec code 2FA
+3. Client se connecte via `/customer-login`
+4. Définit son mot de passe (première connexion)
+
+### 4. Tiers (Third Parties)
+
+**Caractéristiques** :
+
+- **Quasiment identiques aux clients**
+- Authentification via **email + code 2FA** (pas de mot de passe permanent)
+- Stockés dans table `folder_third_parties`
+- Liés à un dossier spécifique
+
+**Règles d'accès** :
+
+- Endpoints dédiés : `/api/v1/third-party/*`
+- Authentification via code 2FA à usage unique
+- Accès limité à :
+  - Le dossier auquel ils sont rattachés
+  - Upload de documents demandés par le notaire
+
+**Création** :
+
+1. Notaire ajoute un tiers via `POST /api/v1/notary/folders/:folderUid/third-parties`
+2. Tiers reçoit email avec code 2FA
+3. Tiers se connecte via `/third-party/login`
+4. Accès temporaire au dossier
+
+**Accès aux dossiers** :
+
+- Les tiers n'ont **pas d'`activeOfficeUid`** (contrairement aux notaires)
+- L'accès au dossier est vérifié via le `folderUid` dans le JWT
+- Les contrôleurs doivent gérer ce cas spécial : vérifier `folderUid` au lieu de `activeOfficeUid` pour les tiers
+- Exemple : `FolderThirdPartiesController.verifyFolderAccess()` vérifie `permissionContext.folderUid` pour les tiers
+
+**Différence avec clients** :
+
+- Clients : liés à l'office, multiples dossiers possibles
+- Tiers : liés à UN dossier spécifique, accès temporaire
+
+### Résumé des Types d'Utilisateurs
+
+| Type | Table | Auth | office_role_uid | Abonnement | Accès |
+|------|-------|------|-----------------|------------|-------|
+| **Notaire avec abo** | `users` | IdNot OAuth | ✅ | ✅ Requis | Complet selon rules |
+| **Notaire invité** | `users` | IdNot OAuth | ✅ | ❌ Non | Limité + Gestion abo |
+| **Client** | `customers` | Email/2FA | ❌ | N/A | Ses dossiers seulement |
+| **Tiers** | `folder_third_parties` | 2FA | ❌ | N/A | 1 dossier seulement |
+| **Template users** | `users` (Office 0000) | N/A | ❌ | N/A | Jamais connectés |
+
+---
+
+## Architecture Rôles & Règles
+
+### Hiérarchie
+
+```text
+┌─────────────────────────────────────────────────────────────┐
+│                        GLOBAL                                │
+├─────────────────────────────────────────────────────────────┤
+│  roles (table)                                              │
+│  ├─ admin                                                   │
+│  ├─ super-admin                                             │
+│  ├─ notary                                                  │
+│  └─ default                                                 │
+│                                                              │
+│  _RolesHasRules (liaison)                                   │
+│  ├─ role.uid → rules.uid                                    │
+│  └─ Ex: super-admin → [ALL RULES]                          │
+└─────────────────────────────────────────────────────────────┘
+                            ↓
+┌─────────────────────────────────────────────────────────────┐
+│                     PAR OFFICE                               │
+├─────────────────────────────────────────────────────────────┤
+│  office_roles (table)                                       │
+│  ├─ Notaire (office A)                                     │
+│  ├─ Collaborateur (office A)                               │
+│  ├─ Notaire (office B)                                     │
+│  └─ Collaborateur (office B)                               │
+│                                                              │
+│  _OfficeRolesHasRules (liaison)                            │
+│  ├─ office_role.uid → rules.uid                            │
+│  └─ Ex: Notaire (office A) → [POST rib, GET folders, ...]  │
+└─────────────────────────────────────────────────────────────┘
+                            ↓
+┌─────────────────────────────────────────────────────────────┐
+│                      UTILISATEUR                             │
+├─────────────────────────────────────────────────────────────┤
+│  users.roles_uid → role (global)                           │
+│  users.office_role_uid → office_role (spécifique office)   │
+│                                                              │
+│  JWT contains:                                              │
+│  rules = role.rules + office_role.rules (MERGED)           │
+│  hasActiveSubscription (boolean)                           │
+│  isVisitor (boolean)                                       │
+│  isSuperAdmin (boolean, si users.is_super_admin === true)   │
+└─────────────────────────────────────────────────────────────┘
+```
+
+### Office Template (idNot "0000")
+
+**Rôle** :
+
+- Office de **référence** contenant les données par défaut
+- Utilisé pour **dupliquer** `office_roles`, `deed_types`, `document_types` vers nouveaux offices
+
+**Contenu** :
+
+- `office_roles` : `Notaire`, `Collaborateur` avec leurs règles
+- `deed_types` : Types d'actes par défaut
+- `document_types` : Types de documents par défaut
+
+**Users dans Office Template** :
+
+- 4 users de test avec `idNot` invalides (ex: `rflrefrjf`)
+- **N'ont PAS** de `office_role_uid` (c'est **NORMAL**)
+- Ne se connectent **jamais** à l'application
+- Servent uniquement de données de référence
+
+### Flux d'autorisation
+
+#### Notaires (avec/sans abonnement)
+
+```text
+Request → authHandler → ActiveOfficeInjector → ruleHandler → Controller
+          ↓               ↓                      ↓
+          JWT verify     office_uid inject      check rule
+          req.user       req.activeOfficeUid    req.user.rules.includes(requiredRule)
+```
+
+**Bypass `ruleHandler`** :
+
+- **Super-admin** : Accès à toutes les routes si `isSuperAdmin === true` (champ séparé dans la table `users.is_super_admin`) **OU** `role === "super-admin"` (rétrocompatibilité)
+- Les middlewares (`roleHandler`, `ruleHandler`) et les controllers super-admin vérifient les deux conditions
+- Endpoints `/admin/subscriptions`, `/admin/stripe`, `/admin/subscription-plans` → **pas de `ruleHandler`**
+
+#### Clients
+
+```text
+Request → customerAuthHandler → Customer endpoints only
+          ↓
+          JWT verify (ICustomerJwtPayload)
+          req.body.customer
+```
+
+#### Tiers
+
+```text
+Request → thirdPartyAuthHandler → Third Party endpoints only
+          ↓
+          2FA code verify
+          req.body.thirdParty
+```
+
+### Règles spéciales
+
+#### Endpoints SANS `ruleHandler`
+
+**Abonnements (accessibles à TOUS les notaires authentifiés)** :
+
+- `GET /api/v1/admin/subscriptions`
+- `GET /api/v1/admin/subscription-plans`
+- `POST /api/v1/admin/stripe` (création checkout)
+- `GET /api/v1/admin/stripe/:uid/client-portal`
+
+**Raison** : Permettre aux notaires invités (sans abonnement) de s'abonner.
+
+#### Endpoints sensibles AVEC `ruleHandler`
+
+**RIB (données bancaires)** :
+
+- `GET /api/v1/notary/rib` → règle `GET rib`
+- `POST /api/v1/notary/rib` → règle `POST rib`
+- `DELETE /api/v1/notary/rib` → règle `DELETE rib`
+
+**Assignées par défaut à** :
+
+- `office_role` "Notaire" et "Collaborateur" (selon configuration Office Template)
+
+**Téléchargement de fichiers** :
+
+- `POST /api/v1/notary/files/download-multiple` → règle `POST files`
+
+**Assignées par défaut à** :
+
+- `office_role` "Notaire" et "Collaborateur" (héritage des règles documents/fichiers)
+
+### Statut Super-Admin
+
+#### Double mécanisme de vérification
+
+Le système utilise **deux mécanismes** pour identifier un super-admin :
+
+1. **Champ `is_super_admin`** (table `users`) : Statut séparé du rôle, permet de promouvoir un utilisateur en super-admin sans changer son rôle global
+2. **Rôle `super-admin`** (table `roles`) : Rôle global classique (rétrocompatibilité)
+
+**Vérification dans le code** :
+
+- Les middlewares (`roleHandler`, `ruleHandler`) vérifient : `isSuperAdmin === true || role === "super-admin"`
+- Les controllers super-admin (ex: `HealthTestsController`, `SiteTextsController`) utilisent la même logique
+- Le JWT contient `isSuperAdmin: true` si `users.is_super_admin === true`
+
+**Bypass super-admin** :
+
+- **`ruleHandler`** : Les super-admins bypassent la vérification des règles de permissions (accès à toutes les routes)
+- **Validation d'accès aux dossiers** : Les super-admins sont **soumis aux mêmes règles** que les notaires et collaborateurs :
+  - Vérification de l'appartenance au dossier (stakeholder)
+  - Vérification des partages de dossier (folder_sharing)
+  - Validation de l'office propriétaire
+- **Raison** : Le statut super-admin ne joue pas sur les fonctions de validation d'accès aux dossiers. Un super-admin doit être explicitement stakeholder ou avoir accès via `folder_sharing` pour accéder à un dossier.
+- **Correction appliquée (décembre 2025)** : Le bypass super-admin dans `folderAccessHelpers.ensureFolderAccess()` a été supprimé. Les super-admins passent maintenant par les mêmes validations que les autres utilisateurs.
+
+**Avantages** :
+
+- Permet d'avoir un super-admin avec un rôle `notary` ou `admin` tout en conservant les permissions super-admin
+- Flexibilité pour la gestion des accès sans modifier la structure des rôles
+- Sécurité renforcée : les super-admins ne peuvent pas contourner les validations d'accès aux dossiers
+
+#### Page /offices et synchronisation IdNot
+
+Sur la page super-admin `/offices`, les actions liées aux synchronisations historiques IdNot/Annuaire ne sont plus exposées. Les recherches de confrères et les résolutions par email utilisent des **appels API** (IdNot/Annuaire) au moment de la demande, en complément de la base du site (users/contacts/offices) et des partages (`folder_sharing`).
+
+#### Promotion en super-admin
+
+La promotion se fait via :
+
+- Script : `lecoffre-back-main/src/scripts/promote-super-admin.ts`
+- Configuration : Variable `SUPERADMIN_EMAILS` dans la BDD (déploiement avec `--promoteSuperAdmins`)
+
+### Cas particuliers
+
+#### Multer et authHandler
+
+**Problème** : `multer().single()` écrase `req.body` lors du parsing de `multipart/form-data`.
+
+**Solution** :
+
+- `authHandler` stocke le user dans **2 emplacements** :
+  - `req.body.user` (standard)
+  - `req.user` (backup, non écrasé par multer)
+- `ActiveOfficeInjector` vérifie les 2 emplacements et restaure `req.body.user` si manquant
+
+**Token d'authentification** : le JWT est lu depuis l'en-tête `Authorization` ou, pour les flux SSE uniquement (EventSource sans en-têtes personnalisés), depuis le paramètre de requête `token`. L'URL est nettoyée avant d'être loggée (paramètre `token` masqué). Voir `docs/CODE_STANDARDS.md` (section Sécurité du Code).
+
+#### Multi-office
+
+- Un user peut avoir plusieurs `user_office_affiliations`
+- Une seule affiliation est `is_primary = true`
+- JWT généré avec l'office PRIMARY
+- `ActiveOfficeInjector` injecte `req.body.activeOfficeUid`
+- Les routes utilisant `activeOfficeInjector` doivent utiliser `req.body.activeOfficeUid` au lieu de `req.body.user.office_Id` pour supporter les super-admins et le multi-office
+
+**Important - Ordre des routes Express** : Les routes spécifiques (ex: `/folders/blockchain`, `/folders/deleted`) doivent être déclarées **avant** les routes paramétrées (ex: `/folders/:uid`) pour éviter les conflits de routage. Express matche les routes dans l'ordre de déclaration, donc `/folders/:uid` intercepterait `/folders/blockchain` si déclarée en premier.
+
+**Exemple** :
+
+```typescript
+// ✅ Correct : route spécifique avant route paramétrée
+@Get("/v1/notary/folders/blockchain", [authHandler, activeOfficeInjector, ruleHandler])
+@Get("/v1/notary/folders/deleted", [authHandler, ruleHandler])
+@Get("/v1/notary/folders/:uid", [authHandler, ruleHandler, folderHandler])
+
+// ❌ Incorrect : route paramétrée avant route spécifique
+@Get("/v1/notary/folders/:uid", [authHandler, ruleHandler, folderHandler])
+@Get("/v1/notary/folders/blockchain", [authHandler, activeOfficeInjector, ruleHandler]) // Ne sera jamais atteinte
+```
+
+### Base de données - Tables clés
+
+```sql
+-- Utilisateurs notaires
+users {
+  uid, idNot, roles_uid (global), office_role_uid (spécifique),
+  office_uid (deprecated, use affiliations), contact_uid,
+  is_super_admin (boolean, statut super-admin séparé du rôle)
+}
+
+-- Affiliations multi-office
+user_office_affiliations {
+  uid, user_uid, office_uid, is_primary, role_in_office (string),
+  status, idnot_sync
+}
+
+-- Clients
+customers {
+  uid, contact_uid, office_uid, status, password, deleted_at
+}
+
+-- Tiers
+folder_third_parties {
+  uid, folder_uid, added_by_uid, role_type, role_description,
+  first_name, last_name, email, phone, auth_method, email_verified
+}
+
+-- Rôles globaux
+roles {
+  uid, name (admin, super-admin, notary, default)
+}
+
+-- Rôles par office
+office_roles {
+  uid, name (Notaire, Collaborateur), office_uid
+}
+
+-- Règles
+rules {
+  uid, name (ex: "POST rib", "GET folders")
+}
+
+-- Liaisons
+_RolesHasRules { A: role.uid, B: rule.uid }
+_OfficeRolesHasRules { A: office_role.uid, B: rule.uid }
+```
+
+---
+
+## Matrice des Permissions
+
+### Vue d'Ensemble
+
+Le système de permissions de LeCoffre.io utilise une **matrice de permissions** stockée en base de données (`role_permissions_matrix`) qui détermine les accès pour chaque combinaison :
+
+- **Ressource** (ex: `documents`, `folders`, `rib`)
+- **Action** (ex: `read`, `create`, `update`, `delete`)
+- **Rôle** (ex: `super-admin`, `admin`, `notary`, `collaborator`, `guest_notary`, `client`, `third_party`)
+- **Scope** (ex: `GLOBAL`, `OFFICE`, `ASSIGNMENT`)
+- **Scoped Entity** (optionnel, UID d'une entité spécifique comme un office)
+
+### Architecture de la Matrice
+
+#### Table `role_permissions_matrix`
+
+**Structure** :
+
+```sql
+- uid (PK)
+- resource (string) : nom de la ressource (ex: "documents", "folders")
+- action (string) : action (ex: "read", "create", "update", "delete")
+- role (string) : rôle utilisateur (ex: "super-admin", "notary")
+- allowed (boolean) : true = autorisé, false = refusé
+- scope (string) : "GLOBAL", "OFFICE", "ASSIGNMENT"
+- scoped_entity (string | null) : UID d'une entité spécifique (ex: office_uid)
+- pages (JSON) : pages frontend associées
+- updated_by (string | null) : UID de l'utilisateur qui a modifié
+- created_at, updated_at
+```
+
+#### Types de Scope
+
+**GLOBAL** :
+
+- Accès à toutes les ressources, tous offices confondus
+- Utilisé pour `super-admin` et `admin` (dans certains cas)
+
+**OFFICE** :
+
+- Accès limité à l'office actif de l'utilisateur
+- Utilisé pour `notary` et `collaborator`
+- Vérifié via `activeOfficeInjector` middleware
+
+**ASSIGNMENT** :
+
+- Accès limité aux ressources assignées à l'utilisateur
+- Utilisé pour `guest_notary` (dossiers partagés), `client`, `third_party`
+- Vérifié dans les controllers via filtres sur `depositor_uid`, `third_party_depositor_uid`, `shared_to_office_uid`
+
+### Flux de Vérification des Permissions
+
+#### Middleware `ruleHandler`
+
+**Ordre d'exécution** :
+
+```text
+Request → authHandler → activeOfficeInjector → ruleHandler → Controller
+```
+
+**Étapes dans `ruleHandler`** :
+
+1. **Extraction du rôle utilisateur** :
+   - `resolveUserRole(user)` détermine le rôle effectif
+   - Priorité : `isSuperAdmin` → `role` global → `officeRole` → `userType`
+
+2. **Résolution de la ressource et action** :
+   - `resolveResource(req, service)` : extrait la ressource depuis le path
+   - `resolveAction(req, resource)` : détermine l'action (read/create/update/delete)
+
+3. **Consultation de la matrice** :
+   - `permissionsService.getDecision({ resource, action, role, scoped_entity })`
+   - Retourne : `"allow"`, `"deny"`, ou `"pass"`
+
+4. **Décision finale** :
+   - **Super-admin** : bypass automatique (ligne 99-112)
+   - **"deny"** : refusé (avec exceptions pour certaines ressources)
+   - **"allow"** : autorisé
+   - **"pass"** : pas d'entrée dans la matrice → fallback sur règles JWT
+
+#### Service `RolePermissionsMatrixService`
+
+**Méthode `getDecision`** :
+
+1. **Construction de la clé** :
+   - Format : `resource::action::role::scoped_entity`
+   - Exemple : `documents::read::notary::-` (sans scope)
+   - Exemple : `documents::read::notary::office-uid-123` (avec scope)
+
+2. **Recherche dans le cache** :
+   - Cache en mémoire (Map) chargé depuis la BDD au démarrage
+   - Recherche exacte de la clé
+
+3. **Retour** :
+   - `"allow"` si `allowed === true`
+   - `"deny"` si `allowed === false`
+   - `"pass"` si aucune entrée trouvée
+
+### Permissions par Type d'Utilisateur
+
+#### Super-Admin
+
+- **Bypass automatique** dans `ruleHandler` (ligne 99-112)
+- Accès à **toutes les ressources** avec scope `GLOBAL`
+- Endpoints `/api/v1/super-admin/*` accessibles
+- Peut modifier la matrice des permissions
+
+#### Admin (Office)
+
+- Scope généralement `OFFICE` (limité à son office actif)
+- Peut gérer les utilisateurs de son office
+- Accès aux ressources de son office
+- Matrice : alignement des permissions `admin` sur `collaborator` pour les ressources notariales (migration `20260305120000_backfill_admin_permissions_from_collaborator` + script `ensure-role-permissions-matrix-folders.sql`).
+
+#### Notary
+
+- Scope `OFFICE` : accès aux ressources de son office actif
+- Peut créer/modifier/supprimer dossiers, documents, RIB
+- Accès complet aux fonctionnalités notariales
+
+#### Collaborator
+
+- Scope `OFFICE` : accès aux ressources de son office actif
+- **Mêmes droits que Notaire** pour documents, files, folder_customer, folder_third_parties, folder_sharing, document_reminder, document_request (read, create, update, delete selon ressource). Pour **folders** : archive autorisé, **delete non** (les collaborateurs peuvent archiver mais pas supprimer un dossier).
+- Matrice : script `ensure-role-permissions-matrix-folders` et migration `20260204120000_align_collaborator_notary_folders_members`. Après déploiement : `run-ensure-role-permissions-matrix-folders.sh` (test | pprod | prod).
+
+#### Guest Notary (Notaire Invité)
+
+- Scope `ASSIGNMENT` : accès uniquement aux dossiers partagés
+- Peut lire/créer/modifier documents dans les dossiers partagés
+- Accès limité aux ressources assignées via `shared_to_office_uid`
+
+#### Client
+
+- Scope `ASSIGNMENT` : accès uniquement à ses propres dossiers et documents
+- Endpoints `/api/v1/customer/*`
+- Peut lire ses documents, uploader des documents demandés
+
+#### Third Party (Tiers)
+
+- Scope `ASSIGNMENT` : accès uniquement au dossier auquel il est rattaché
+- Endpoints `/api/v1/third-party/*`
+- Peut lire ses documents, uploader des documents demandés
+- **Consultation (Mark as Viewed)** : La route `PUT .../mark-as-viewed` est exclue du blocage de mise à jour des documents `SENT`. Cela permet au tiers de consulter un document (passant de SENT à DOWNLOADED) sans erreur 403 ni déconnexion.
+
+### Points d'Attention
+
+#### Super-Admin Bypass
+
+Le super-admin **bypass automatiquement** la matrice des permissions. Cela signifie :
+
+- ✅ Accès à toutes les routes
+- ⚠️ Les controllers doivent quand même vérifier la logique métier
+- ⚠️ Les filtres de scope (OFFICE, ASSIGNMENT) ne s'appliquent pas automatiquement
+
+#### Fallback sur Règles JWT
+
+Si la matrice retourne `"pass"` (pas d'entrée), le système fait un **fallback sur les règles JWT** :
+
+- Vérifie si `user.rules` contient la règle requise (ex: `"POST documents"`)
+- Si oui → autorisé
+- Si non → refusé
+
+#### Scoped Entity
+
+Le paramètre `scoped_entity` permet de définir des permissions spécifiques pour une entité (ex: un office particulier) :
+
+- Exemple : `documents::read::notary::office-uid-123`
+- Si présent, prioritaire sur l'entrée sans scope
+- Utilisé pour des permissions granulaires
+
+### Modifications de la Matrice
+
+#### Via Interface Super-Admin
+
+- Endpoint : `PUT /api/v1/super-admin/role-permissions-matrix`
+- Permet de modifier les permissions pour chaque combinaison rôle/ressource/action
+- Met à jour le cache automatiquement
+
+#### Via Migrations
+
+- Les migrations peuvent créer/modifier des entrées dans `role_permissions_matrix`
+- Exemple : `prisma/migrations/20251107_role_permissions_matrix/migration.sql`
+
+### Pilotage dynamique (onglet Super Admin "Matrice des droits")
+
+L'onglet `Super Admin > Matrice des droits` (`/super-admin/role-permissions`) permet désormais de piloter en temps réel la matrice.
+
+**Interface** :
+
+- Tableau double entrée (ressource × action × rôle) avec cases à cocher synchronisées avec la BDD.
+- Colonne informative "Pages concernées" (liste des écrans impactés).
+- Badges de portée (`Global`, `Étude active`, `Affectation`, `Personnel`) pour chaque rôle afin de rappeler le niveau de permission.
+- Barre de recherche full-text (ressource, action, page, rôle, scope).
+- Résumé des modifications en attente + bouton `Réinitialiser` (revenir aux valeurs chargées) + bouton `Enregistrer`.
+- Feedbacks : loader centralisé, toasts de confirmation, surface d'erreur explicite.
+
+**API & persistance** :
+
+- `GET /api/v1/super-admin/role-permissions` → retourne la matrice structurée (ressource → action → [pages, rôles]).
+- `PUT /api/v1/super-admin/role-permissions` → accepte une liste d'updates `{ resource, action, role, allowed, scope?, pages? }`.
+- Table SQL `role_permissions_matrix` : clé unique `(resource, scoped_entity, action, role)`, colonnes `allowed`, `scope`, `pages`, `updated_by`, `updated_at`.
+- Service backend : cache mémoire (chargé au démarrage, invalidé après update) + logging (`SafeLogger.debug`).
+
+**Middleware** :
+
+- `RulesHandler` interroge la matrice (décision `allow|deny|pass`) avant le fallback sur les règles JWT historiques.
+- Résolution automatique du trio `{resource, action, role}` à partir du chemin, du verbe HTTP et du JWT (`guest_notary`, `client`, `third_party`, etc.).
+- Journalisation standardisée des décisions (`resource`, `action`, `role`, `decision`, `userId`).
+
+#### Exceptions et fallbacks dans RulesHandler
+
+Le `RulesHandler` implémente des **fallbacks spécifiques** pour certaines ressources/actions lorsque la matrice retourne `pass` (pas de règle explicite) ou `deny` (refus explicite) :
+
+**1. `folder_third_parties` + action `resend`** :
+
+- Si décision = `pass` et aucun JWT rules : autoriser par défaut pour les rôles `notary`, `collaborator`, `admin`, `super-admin`.
+- Permet le renvoi de code de vérification aux tiers sans nécessiter une règle explicite dans la matrice.
+
+**2. `folder_sharing` + action `delete` (révocation de partage)** :
+
+- **Si décision = `pass`** et aucun JWT rules : autoriser par défaut pour les rôles `notary`, `collaborator`, `admin`, `super-admin`.
+- **Si décision = `deny`** mais que l'utilisateur a des permissions sur les dossiers (`POST folders`, `DELETE folders`, ou `PUT folders`) : autoriser pour les rôles `notary`, `collaborator`, `admin`, `super-admin`.
+- **Sécurité** : Le contrôleur `FolderSharingController.revokeShare()` vérifie de toute façon que l'utilisateur est membre de l'office propriétaire du dossier (`folder.office_uid === activeOffice.uid`). Cette double vérification garantit que seuls les membres de l'office propriétaire peuvent révoquer un partage, même si la matrice de permissions ne contient pas de règle explicite.
+
+**Raison des fallbacks** :
+
+- Permettre aux membres de l'office propriétaire d'un dossier de gérer les partages même si la matrice de permissions n'a pas été configurée explicitement pour `folder_sharing` delete.
+- Le contrôleur effectue toujours une vérification finale basée sur la propriété du dossier, garantissant la sécurité.
+
+La matrice devient ainsi la source de vérité opérationnelle. Les sections précédentes restent la documentation fonctionnelle de référence ; l'interface Super Admin permet de l'appliquer sans redéploiement.
+
+---
+
+## JWT Multi-Office et Calcul Dynamique des Règles
+
+### Principe
+
+Lorsqu'un utilisateur a plusieurs affiliations (`user_office_affiliations`), le JWT doit refléter :
+
+- L'**office actif** (affiliation avec `is_primary = true`)
+- Les **règles du rôle** dans cet office actif
+
+### Implémentation dans AuthService
+
+Le processus de calcul des règles est plus complexe que la simple addition des règles globales et office. Voici le processus complet :
+
+```typescript
+// AuthService.getUserJwtPayload()
+
+// 1. Déterminer l'office actif via determineActiveOffice()
+//    - Gère les affiliations PRIMARY
+//    - Gère les dossiers partagés (GUEST_FOLDERS) si pas d'abonnement actif
+//    - Retourne { officeId, activeAffiliation, isGuestFolders }
+const { officeId, activeAffiliation, isGuestFolders } = await this.determineActiveOffice(user);
+
+// 2. Normaliser le nom du rôle office
+//    - Utilise normalizeIdNotOfficeRoleName() pour standardiser les noms de rôles IdNot
+//    - Gère les variations de noms (accents, casse, underscores)
+const rawAffiliationRoleName = activeAffiliation?.role_in_office ?? null;
+const normalizedAffiliationRoleName = normalizeIdNotOfficeRoleName(rawAffiliationRoleName);
+
+// 3. Calculer les règles dans l'ordre suivant :
+const rules = new Set<string>();
+
+// 3.1. Ajouter les règles du rôle global
+user.role.rules.forEach((rule) => {
+  if (rule?.name) {
+    rules.add(rule.name);
+  }
+});
+
+// 3.2. Ajouter les règles super-admin si applicable
+//      - Vérifie is_super_admin OU rôle = "super_admin"
+//      - Ajoute toutes les règles super-admin via addSuperAdminRules()
+await this.addSuperAdminRules(rules, isSuperAdmin);
+
+// 3.3. Ajouter les règles office ou guest notary
+if (isGuestFolders) {
+  // Cas "Dossiers invités" : ajoute les règles de notaire invité
+  this.addGuestNotaryRules(rules);
+} else if (activeAffiliation && normalizedAffiliationRoleName && officeId) {
+  // Cas normal : charge le rôle office et ajoute ses règles
+  await this.addOfficeRoleRules(rules, officeId, normalizedAffiliationRoleName, user);
+} else if (user.office_role) {
+  // Fallback : utilise le rôle office de l'utilisateur
+  user.office_role.rules.forEach((rule) => {
+    if (rule?.name) {
+      rules.add(rule.name);
+    }
+  });
+}
+
+// 4. Filtrer les règles pour les visiteurs (si pas d'abonnement actif)
+if (!hasActiveSubscription && !isGuestFolders) {
+  uniqueRules = this.filterVisitorRules(uniqueRules);
+}
+
+// 5. JWT contient : userId, office_Id, role, officeRole, rules, isVisitor, isGuestFolders
+```
+
+**Points importants** :
+
+- **GUEST_FOLDERS** : Si l'utilisateur n'a pas d'abonnement actif mais a des dossiers partagés, `officeId = "GUEST_FOLDERS"` et les règles de notaire invité sont appliquées.
+- **Normalisation des rôles** : Les noms de rôles IdNot sont normalisés pour correspondre à la matrice de permissions.
+- **Règles super-admin** : Ajoutées séparément après les règles globales, pas fusionnées.
+- **Filtrage visiteurs** : Les règles sont filtrées si l'utilisateur est un visiteur (pas d'abonnement actif et pas GUEST_FOLDERS).
+
+### Switch d'Office
+
+Lors du switch d'office via `PUT /api/v1/notary/users/:userUid/offices/active` :
+
+1. ✅ Modification de l'affiliation PRIMARY en BDD
+2. ✅ Régénération du JWT avec :
+   - Nouvel `office_Id` (l'office cible)
+   - Nouvelles `rules` (rôle dans l'office cible)
+3. ✅ Frontend met à jour le JWT en localStorage
+4. ✅ Rechargement automatique des dossiers/permissions
+
+### Vérification Frontend Réactive
+
+Le frontend vérifie désormais les règles via `PermissionContext`/`useRolePermissions()` :
+
+```typescript
+import { useRolePermissions } from "@Front/Stores/RolePermissionsStore";
+import { AppRuleActions, AppRuleNames } from "@Front/Api/Entities/rule";
+
+const { can, loading: permissionsLoading } = useRolePermissions();
+
+const canCreateFolder = can(AppRuleNames.officeFolders, AppRuleActions.create);
+
+// Exemple : gérer le clic sur "Créer un dossier"
+const handleCreateFolderClick = useCallback(() => {
+ if (permissionsLoading) {
+  return;
+ }
+ if (canCreateFolder) {
+  router.push("/folders/create");
+ } else {
+  subscriptionModal.open();
+ }
+}, [canCreateFolder, permissionsLoading, router, subscriptionModal]);
+```
+
+### Cohérence Matrice ↔ JWT et fallback frontend
+
+#### Source de vérité et arbitrage
+
+- La matrice `role_permissions_matrix` (pilotée dans l'onglet Super Admin) est la cible de gouvernance.
+- Le middleware `RulesHandler` doit prioriser la matrice; en son absence pour un couple (ressource, action, rôle), la décision retombe sur les `rules` incluses dans le JWT.
+
+#### Fallback côté frontend (non super‑admin)
+
+- Par défaut, seuls les super‑admins chargent la matrice côté front.
+- Pour les autres rôles, `RolePermissionsStore.can(resource, action)` s'appuie sur `jwt.rules` avec:
+  - mapping actions → méthodes HTTP: `create→POST`, `read→GET`, `update→PUT|PATCH`, `delete→DELETE`, `add→POST|PUT`, `remove→DELETE`, `share→POST`, `remind→POST`, `resend→POST`
+  - normalisation singulier/pluriel de ressource (ex. `folder_customer` ⇄ `folder_customers`)
+  - heuristiques:
+    - clients dossier: `add` accepte `POST/PUT folder_customers` ou `PUT folders`
+    - tiers dossier: `add` accepte `POST folder_third_parties` ou `PUT folders`
+    - partage dossier: `create` accepte `POST folder_sharings` ou `POST folders`
+
+#### Recommandations d'alignement
+
+- Garder cohérents: seed des `rules` et affectations (`roles`, `office_roles`), calcul `AuthService.getUserJwtPayload()`, et configuration de la matrice.
+
+### Licence (hasActiveSubscription) et comportement d'accès
+
+#### Calcul côté serveur
+
+- `SubscriptionsService.isUserSubscribed(user.uid, officeId)` pilote `hasActiveSubscription`.
+- En échec de vérification: journalisation `warn` et fallback `hasActiveSubscription=false`.
+- Si `false` → `isVisitor=true`, `officeRole="Visiteur"`, `rules` réduites: lecture + parcours abonnement.
+
+#### Affichages et contrôles UI
+
+- L'UI masque/désactive les actions d'écriture si la règle correspondante manque dans `jwt.rules`.
+- Carte « Gestionnaires du projet »: « Licence active » s'affiche si `subscription.status === "active"` et `subscription.office.uid === folder.office.uid`.
+
+---
+
+## Gestion des Fichiers
+
+### Nommage des Fichiers (Préfixe Dépositaire)
+
+**Objectif** : Identifier l'origine et le contexte de chaque fichier via un préfixe standardisé.
+
+**Format** : `folderNumber.[Prefix.]FirstName.LastName.TypeDocument.aplc.ext`
+*Exception RIB* : `RIB.[Prefix.]officeName.aplc.ext`
+
+**Préfixes (Type de dépositaire)** :
+
+- **N** : Notaire gestionnaire
+- **C** : Client
+- **T** : Tiers
+- **NI** : Notaire invité (office partagé)
+
+**Composants** :
+
+1. **Numéro de dossier** (ou "RIB") : Toujours en premier.
+2. **Préfixe** : `N`, `C`, `T` ou `NI`.
+3. **Prénom** : Formaté et inséré dans le nom.
+4. **Nom** : Formaté en majuscules, espaces remplacés par tirets (ex. `DUPONT-MOREAU`).
+5. **Type de document** : Nom du type de document.
+6. **Suffixe** : `.aplc` (ancrage), sans index de version.
+
+**Implémentation** :
+
+- **FileNamingService** : Centralise la génération avec `generateDisplayName`.
+- **DepositaryPrefixHelper** : Gère l'ajout/retrait du préfixe.
+- **FileNamingParsingHelper** : Parse le format pour extraction.
+
+---
+
+## Statuts des Documents et Flux
+
+### Distinction Sémantique
+
+- **DEPOSITED** : Document envoyé par un déposant (Client, Tiers, Notaire Invité) vers le Notaire en charge.
+  - *Note* : Un document envoyé par un Notaire Invité au Notaire en charge est DEPOSITED.
+- **SENT** : Document envoyé par le Notaire en charge vers un destinataire (Client, Tiers, Notaire Invité).
+  - *Note* : Un document envoyé par le Notaire en charge au Notaire Invité est SENT.
+- **DOWNLOADED** : Document SENT qui a été consulté/téléchargé par le destinataire.
+- **ASKED** : Document demandé par le Notaire en charge.
+- **VALIDATED/REFUSED** : Statuts de validation par le Notaire en charge.
+
+### Règles de Visibilité et Actions
+
+- **"Documents à envoyer" (Front)** : Affiche uniquement `ASKED`, `REFUSED`, `VALIDATED`.
+  - Exclut `DEPOSITED`, `SENT`, `DOWNLOADED`.
+- **Blocage API Customer** :
+  - **Modification/Suppression** : Interdite si statut est `SENT` (403). Autorisé si `DOWNLOADED`.
+  - **Passage en SENT** : Interdit via PUT (réservé au `send`).
+
+---
+
+## Évolution planifiée - Documents unifiés
+
+**Statut** : 📋 Planifié | **Version** : cible
+
+### Objectif
+
+Unifier le flux d'envoi de documents et les métadonnées d'émetteur pour tous les types de destinataires et de déposants.
+
+### Décisions validées
+
+#### 1. Tables (court terme)
+
+- Conserver `documents` et `documents_notary` pour des raisons historiques/techniques.
+- Unifier le flux d'envoi côté API.
+- Fusion des tables prévue à terme.
+
+#### 2. Destinataire (recipient)
+
+Type union unique pour tous les envois :
+
+```typescript
+{
+  type: 'customer' | 'third_party' | 'office' | 'invited_notary';
+  uid: string;
+}
+```
+
+Types de destinataires possibles :
+
+- `customer` : client du dossier
+- `third_party` : tiers du dossier
+- `office` : notaire admin de l'office
+- `invited_notary` : notaire invité du dossier
+
+#### 3. Émetteur (emitter)
+
+- **Champ** : `emitter` (équivalent anglais de « émetteur »).
+- **Structure** : `{ uid, first_name, last_name, office_uid?, office_name? }`.
+- **Règle** : celui qui envoie le document ; absent pour documents ASKED (personne n'a encore envoyé).
+- **Sources** :
+
+  - Client dépose : `depositor.contact`
+  - Tiers dépose : `third_party_depositor`
+  - Notaire envoie (DocumentsNotary) : `depositor` (User)
+  - Notaire envoie (Documents shared_to_office) : notaire du `folder.office`
+  - RIB : `rib_anchor_proof_data.depositor`
+
+#### 4. Documents du notaire invité
+
+Les documents créés par le notaire invité sont traités comme ceux des tiers ou des clients : même modèle, pas de cas particulier. Le notaire invité est un membre du dossier comme les autres ; il ne joue pas le rôle de notaire gestionnaire dans ce dossier.
+
+**Implémentation** : Concept de membre unifié (`FolderMember`) :
+
+- **Base** : `BaseFolderMember` (uid, display_name, email) — champs communs hérités
+- **Types dérivés** : `CustomerMember`, `ThirdPartyMember`, `InvitedNotaryMember` (extends BaseFolderMember + type)
+- **Recipient** : `BaseRecipient` (uid), `TypedRecipient` (extends BaseRecipient + type)
+- **API** : GET folder retourne `members` (tableau unifié clients + tiers + notaires invités)
+- **Backend** : `buildFolderMembers()` dans `folderMemberHelpers.ts`
+- **Frontend** : `folder.members` disponible ; `buildRecipientsFromMembers()` pour le flux d'envoi
+
+#### 5. Espaces et onglets membres (dérivation depuis cas parent member)
+
+Les espaces (client/tiers/notaires invités) et les onglets des membres des dossiers dérivent d'un cas parent « member ».
+
+**Espaces (FolderInformationUserContext)** :
+
+- Type de base : `BaseMemberContextType` = `"customer" | "third_party" | "invited_notary"`
+- Constantes : `MEMBER_CONTEXT_THIRD_PARTY`, `MEMBER_CONTEXT_INVITED_NOTARY`
+- `FolderInformationUserContext` = `"notary" | MEMBER_CONTEXT_THIRD_PARTY | MEMBER_CONTEXT_INVITED_NOTARY`
+
+**Onglets membres (ClientView)** :
+
+- Type de base : `BaseMemberTabValue` avec `tabType: BaseMemberTabType`
+- `BaseMemberTabType` = `"customer" | "third_party" | "shared_notary"`
+- Constantes : `TAB_TYPE_CUSTOMER`, `TAB_TYPE_THIRD_PARTY`, `TAB_TYPE_SHARED_NOTARY`
+- Types dérivés : `CustomerTabValue`, `ThirdPartyTabValue`, `SharedNotaryTabValue` (extends BaseMemberTabValue)
+
+**Fichiers** : `MemberTypes.ts`, `folderInformationUserContext.ts`, `ClientView/types.ts`
+
+#### 6. Flux d'envoi unifié
+
+Une seule fonction d'envoi API avec un destinataire de type union. Pas de distinction par type de destinataire : envoi au bon membre en tant que notaire gestionnaire.
+
+**Implémentation** : L'API `POST /v1/notary/documents_notary/send` accepte désormais :
+
+- **Format unifié** : `recipients: { type: 'customer' | 'third_party' | 'office' | 'invited_notary'; uid: string }[]`
+- **Format legacy** : `recipientUid` ou `recipientUids` (résolution automatique du type)
+
+Le service `DocumentBatchService` route vers Documents (third_party, office/invited_notary) ou DocumentsNotary (customer) selon le type.
+
+#### 7. Orchestrateurs de sortie API (plain)
+
+Les réponses API documents sont normalisées via des orchestrateurs de post-hydratation pour garantir une sortie `plain` cohérente entre endpoints liste, mono-entité, transformation et suppression.
+
+**DocumentsNotary** :
+
+- `#Common/utils/documentsNotaryPostHydrationHelper`
+- `buildDocumentsNotaryPlainWithRelations` : enrichit la sortie (`emitter`) et réinjecte `files` si nécessaire
+- `hydrateDocumentsNotaryToPlainWithRelations` : pipeline liste
+- `hydrateSingleDocumentNotaryToPlainWithRelations` : pipeline mono-entité (get by uid, mark-as-viewed, suppression, transformations)
+- `logDocumentsNotaryPlainFilesGuard` : garde-fou de cohérence `files`
+
+**Documents (non-notary)** :
+
+- `#Common/utils/documentsPostHydrationHelper`
+- `buildDocumentsPlainWithRelations` : pipeline liste
+- `buildSingleDocumentPlainWithRelations` : pipeline mono-entité (get by uid, création, mark-as-viewed, suppression)
+- `logDocumentsPlainFilesGuard` : garde-fou de cohérence des fichiers téléchargeables
+
+**Règle d'architecture** :
+
+- Les controllers/helpers ne construisent plus la sortie JSON avec un `instanceToPlain` local suivi de merges manuels.
+- Toute sortie document doit passer par l'orchestrateur correspondant (`DocumentsNotary` ou `Documents`).
+
+### Références pour implémentation
+
+- `DocumentsEnrichmentHelper` : enrichir les réponses avec `emitter` au lieu de limiter à `{ uid }`.
+- `DocumentsNotary` : inclure `depositor` (avec `contact`) dans les requêtes et exposer `emitter`.
+- RIB : exposer `emitter` depuis `rib_anchor_proof_data.depositor` (POST/GET office, GET office/:uid).
+
+---
+
+## Partage Inter-Études
+
+**Statut** : ✅ 100% | **Version** : 2.0.0
+
+### Distinction importante : Partage avec une personne spécifique
+
+**Concept fondamental** : Le partage se fait avec **une personne spécifique** (notaire invité) qui reçoit un email et se connecte ensuite.
+
+**Sémantique du partage** :
+
+- **Partage = Invitation d'une personne spécifique** (IdNot + email de préférence pour les envois, `invited_notary_email`)
+- **Documents = Demandés à l'office de cette personne** (`shared_to_office_uid`)
+- **Accès aux dossiers invités = Croisement sur l'id IdNot** (`invited_notary_idnot`) ; **email en base** = envois uniquement
+
+**Workflow** :
+
+1. Le notaire principal partage un dossier avec un confrère (sélection dans l'annuaire + email de préférence pour les envois, stocké en `invited_notary_email`)
+2. Un email d'invitation est envoyé au confrère à l'adresse `invited_notary_email` (après création, seul cet email en base est utilisé pour tous les envois)
+3. Le confrère se connecte et accède aux dossiers partagés via "Dossiers invités" (GUEST_FOLDERS)
+4. Les documents demandés sont créés avec `shared_to_office_uid` (l'office du confrère)
+5. L'accès aux dossiers invités est déterminé par l'IdNot ; les envois d'email utilisent `invited_notary_email` en base
+
+**Gestion de l'affichage et de la sélection des dossiers** :
+
+- **`is_primary` pour GUEST_FOLDERS** : Si un utilisateur n'a pas d'office avec licence active mais a des dossiers partagés, "Dossiers invités" est ajouté avec `is_primary: true` pour permettre la sélection automatique
+- **Stabilisation de la liste** : Les hooks frontend (`useInvitedCustomerFolders`) utilisent des refs pour stabiliser la liste des dossiers et éviter les re-rendus lors de la navigation
+- **Badge "Invité"** : Affiché uniquement pour les dossiers partagés en contexte non-GUEST_FOLDERS (évite la redondance)
+- **Mise à jour IdNot** : Les utilisateurs invités sont mis à jour via l'API IdNot même s'ils n'ont pas de `officeMembership.idNot` (recherche par rattachements)
+
+**Contrainte du schéma** : `@@unique([folder_uid, shared_to_office_uid])`
+
+- Un dossier ne peut être partagé qu'**une seule fois avec un office donné**
+- Cette contrainte garantit l'isolation des documents par notaire invité
+- Si plusieurs notaires du même office doivent être invités, cela nécessiterait des partages distincts (non supporté actuellement)
+
+**Distinction avec un partage d'office complet** :
+Le système **ne supporte pas** le partage avec un office entier où tous les membres auraient accès. Le partage est toujours avec une **personne spécifique** identifiée par son IdNot et son email de préférence pour les envois. L'office (`shared_to_office_uid`) sert uniquement à :
+
+- Identifier l'office du notaire invité pour la création des documents
+- Permettre l'affichage dans l'interface "Dossiers invités"
+
+L'accès aux dossiers invités est déterminé par l'**IdNot** du notaire connecté (`invited_notary_idnot`). L'email en base (`invited_notary_email`) sert uniquement aux envois (invitations, documents).
+
+### Architecture Backend
+
+**Service** : `FolderSharingService` (~250 lignes)
+**Fichier** : `lecoffre-back-main/src/services/notary/FolderSharingService/FolderSharingService.ts`
+
+**Controller** : `FolderSharingController` (~280 lignes)
+**Fichier** : `lecoffre-back-main/src/app/api/notary/FolderSharingController.ts`
+
+**Endpoints** :
+
+- `POST /api/v1/notary/folders/:uid/share` : Partager dossier avec confrère
+  - **Paramètres** : `invitedNotaryEmail` (requis, email de préférence pour les envois), `invitedNotaryIdnot` (optionnel), `invitedNotaryFirstName`, `invitedNotaryLastName` (optionnels). CRPCEN optionnel.
+  - **Note** : L'email stocké (`invited_notary_email`) est utilisé pour tous les envois après création. L'IdNot (`invited_notary_idnot`) sert au croisement login / dossiers invités.
+- `GET /api/v1/notary/folders/shared` : Liste dossiers reçus
+- `GET /api/v1/notary/folders/:uid/shares` : Liste partages d'un dossier
+- `POST /api/v1/notary/shares/:uid/revoke` : Révoquer partage
+
+### Base de Données
+
+**Table** : `folder_sharing`
+
+**Champs** :
+
+- `folder_uid` : Dossier partagé
+- `shared_from_office_uid` : Office qui partage
+- `shared_to_office_uid` : Office qui reçoit (office du notaire invité)
+- `invited_notary_email` : Email de préférence pour les envois (invitations, documents). Seul champ email pour le notaire invité ; par défaut pré-rempli depuis IdNot à l'invitation, modifiable avant enregistrement. **Après création, seul ce champ est utilisé pour tous les envois** (aucune relecture IdNot).
+- `invited_notary_idnot` : Identifiant IdNot du notaire invité. Utilisé pour le **croisement login / dossiers invités** : l'accès aux dossiers partagés est déterminé par cet IdNot (quand l'utilisateur connecté a un IdNot).
+- `invited_notary_first_name` : Prénom du notaire invité
+- `invited_notary_last_name` : Nom du notaire invité
+- `shared_by_user_uid` : Utilisateur qui a partagé
+- `share_role` : Rôle accordé (lecture seule)
+- `status` : ACTIVE, REVOKED
+- `expires_at` : Date expiration optionnelle
+- `can_view_other_members_documents` : Permission pour voir les documents des autres membres
+
+**Email et IdNot du notaire invité** :
+
+- **Un seul champ email en base** : `invited_notary_email` = email de préférence (et par défaut email IdNot à l'invitation). Il n'y a pas de champ séparé « email IdNot » ; l'email IdNot et l'email de préférence sont donc le même champ persisté.
+- **Accès aux dossiers invités** : croisement sur `invited_notary_idnot` (voir `buildGuestNotaryShareWhere`). L'email en base n'est pas utilisé pour l'accès.
+- **Notaires invités sans seat** : à l'invitation, le partage enregistre `invited_notary_idnot`. Lors de la première connexion via IdNot, un profil `User` est créé ou mis à jour avec `users.idNot`. Les notaires invités ont donc en base un identifiant IdNot (sur le partage, et sur le User après connexion).
+
+**Contrainte unique** : `@@unique([folder_uid, shared_to_office_uid])`
+
+- Empêche de partager plusieurs fois le même dossier avec le même office
+- Garantit l'isolation des documents par notaire invité
+
+### Frontend
+
+**Pages** :
+
+- `/folders/shared` : Dossiers reçus
+- **Modal** : `ShareFolderModal` (partager avec confrère)
+
+**API** : `FolderSharingApi` (4 méthodes)
+
+**Fonctionnalités** :
+
+- Onglets notaires invités créés dans `ClientView`
+- Badge "Lecture seule" pour notaires invités
+- Query inclut `folder_sharings` avec relations
+- **Demande de documents** : Possibilité de demander des documents aux confrères invités (v2.0.1)
+- **Relance de documents** : Possibilité de relancer les confrères pour les documents en attente (v2.0.1)
+- **Invitation simplifiée** : Seul l'email est requis pour inviter un confrère. Le CRPCEN est automatiquement récupéré depuis IdNot lors de la connexion (v2.0.1)
+
+### Email
+
+**Destinataire notaire invité** : Tous les envois (invitation partage, relance, documents) utilisent **uniquement** l'email en base `invited_notary_email`. Aucune relecture de l'email côté IdNot après création du partage.
+
+**Templates** :
+
+- `FOLDER_SHARING_INVITATION` : Invitation partage dossier
+- `DOCUMENT_REQUEST` : Demande de document (utilisé aussi pour les confrères)
+- Documentation : `docs/MAILCHIMP_TEMPLATE_FOLDER_SHARING_INVITATION.md`
+
+### Demande et Relance de Documents aux Confrères (v2.0.1)
+
+**Fonctionnalités** :
+
+- **Demander un document** : Bouton disponible sur l'onglet du confrère invité
+- **Relancer un confrère** : Bouton disponible pour les documents en statut ASKED
+- **Affichage des documents** : Table des documents avec filtrage par `shared_to_office_uid`
+
+**Frontend** :
+
+- `ClientView` : Gestion des onglets notaires invités avec boutons
+- `AskDocuments` : Support du format `shared-office:uid` dans l'URL
+- `DocumentTables` : Affichage des documents avec flag `isSharedNotary`
+- `EmailReminder` : Support des relances pour les confrères
+
+**Backend** :
+
+- Utilise le champ `shared_to_office_uid` existant dans la table `documents`
+- Les documents sont demandés à l'office du notaire invité, mais l'accès est contrôlé par l'email
+- `EmailBuilder.sendDocumentEmails()` : Gère déjà les emails pour les confrères
+- `DocumentsController.resendRequest()` : Fonctionne pour tous les types de documents
+
+**Important** : Les documents avec `shared_to_office_uid` sont techniquement visibles par tous les membres de cet office, mais la contrainte unique `@@unique([folder_uid, shared_to_office_uid])` limite l'exposition car un dossier ne peut être partagé qu'une seule fois avec un office donné. L'accès individuel est contrôlé via `invited_notary_email` dans le contexte `GUEST_FOLDERS`.
+
+**Documentation détaillée** : voir section « Partage Inter-Études » ci-dessus. Déploiement : exécuter les migrations Prisma puis `deploy/scripts/build-and-deploy.sh`. Analyse : vérifier en base `invited_notary_idnot` sur folder_sharing ; créer un partage depuis l’UI ; connexion notaire invité (IdNot) → dossiers partagés accessibles.
+
+---
+
+### Accès et Téléchargement pour Notaire Invité
+
+**Problème résolu (v2.0.2)** : Les notaires invités ne pouvaient pas voir/télécharger les documents envoyés par le notaire gestionnaire (table `documents_notary`).
+
+**Architecture d'accès** :
+
+1. **Vue Document** : Permission `canViewDocuments` étendue si `isGuestNotary` (rôle ou contexte GUEST_FOLDERS).
+2. **API Customer** :
+   - **GET documents_notary** : Support du filtre `where: { AND: [...] }` pour extraire `folderUid`.
+   - **Download** : `FileNotaryAccessGuestNotaryHelper` vérifie désormais dans `documents_notary` (en plus de `documents`) et valide l'accès via `folder_sharing`.
+3. **Fallback Téléchargement** : Si le document est dans la table `documents` (envoyé à l'invité), le front utilise l'API Customer (`/customer/files/download/:uid`) au lieu de Notary, car l'API Customer valide correctement l'accès via `folder_sharing`.
+
+---
+
+## Gestion Multi-Office
+
+**Statut** : ✅ 100% | **Version** : 2.0.0
+
+### Architecture Backend (Multi-Office)
+
+**Service** : `UserOfficeAffiliationsService` (~250 lignes)
+**Fichier** : `lecoffre-back-main/src/services/notary/UserOfficeAffiliationsService/UserOfficeAffiliationsService.ts`
+
+**Middleware** : `ActiveOfficeInjector` (injection activeOfficeUid dans req.body)
+**Fichier** : `lecoffre-back-main/src/app/middlewares/ActiveOfficeInjector.ts`
+
+**Endpoints** :
+
+- `GET /api/v1/notary/users/:uid/offices` : Liste offices utilisateur
+- `POST /api/v1/notary/users/:uid/offices/active` : Changer office actif
+- `POST /api/v1/notary/users/:uid/offices/sync` : Synchroniser depuis IdNot
+
+### Base de Données (Multi-Office)
+
+**Table** : `user_office_affiliations`
+
+**Champs** :
+
+- `user_uid` : Utilisateur
+- `office_uid` : Office
+- `role` : Rôle dans cet office
+- `is_primary` : Office principal (booléen)
+
+**Unique** : `(user_uid, office_uid)`
+
+### Frontend (Multi-Office)
+
+**Store** : `ActiveOfficeStore.ts` (MobX, 150 lignes)
+**Composant** : `OfficeSelector` (dropdown header, masqué si 1 seul office)
+**API** : `UserOffices` (4 méthodes)
+
+### Fonctionnalités
+
+- **Sync automatique** : Depuis IdNot API Annuaire
+- **Changement office** : Sans déconnexion (reload page)
+- **Filtrage automatique** : Par office actif
+- **Méthode `setPrimary()`** : Atomique (transaction)
+- **Compatible** : Tous les TODOs existants
+
+### Middleware Injection
+
+**Transparente** : Ajoute `activeOfficeUid` dans tous les endpoints notary
+**Alias** : `officeUid` pour compatibilité code existant
+
+### Switch d'Office : Régénération JWT et Permissions
+
+**Flux attendu** :
+
+1. `PUT /api/v1/notary/users/:userUid/offices/active` (auth requis, pas de `ruleHandler`)
+2. `UserOfficeAffiliationsService.setActiveOffice(...)` vérifie l'affiliation `ACTIVE` et bascule `is_primary`
+3. `AuthService.getUserJwtPayload(...)` régénère le JWT avec:
+   - nouvel `office_Id`
+   - `rules` recalculées (rôle d'office + règles globales)
+   - filtrage licence (`hasActiveSubscription`, `isVisitor`) pour le nouvel office
+
+4. Front: remplace les tokens, vérifie le cookie, et relit les droits (journaux: `office_Id`, `rulesCount`)
+
+**Points de contrôle** :
+
+- Le backend doit renvoyer de nouveaux tokens après chaque bascule.
+- Le front doit vérifier la mise à jour effective du cookie `leCoffreAccessToken` puis conditionner l'UI.
+
+---
+
+## Ancrage Blockchain
+
+LeCoffre.io utilise l'ancrage blockchain Bitcoin Signet pour garantir l'intégrité et la traçabilité des documents.
+
+### Évolution des Versions
+
+| Version | Blockchain | Périmètre | Déclenchement | Filigrane | Fallback |
+|---------|-----------|-----------|---------------|-----------|----------|
+| **V1** | Tezos | Dossiers uniquement | Manuel | ❌ Non | ⚠️ Lecture seule |
+| **V2** | Bitcoin Signet | Docs + Dossiers | Auto | ❌ Non | - |
+| **V3** | Bitcoin Signet | Docs + Dossiers | Auto | ✅ Oui | ✅ Tezos masqué |
+
+### Nouveautés V3
+
+1. **Filigrane automatique** : "lecoffre.io" sur tous documents
+2. **Double version** : Original + filigrané (conservés en BDD)
+3. **ZIP enrichi** : Originaux + filigranés + certificats + preuves JSON
+4. **Preuves structurées** : JSON standardisé pour vérification externe
+5. **Ancrage dossier** : Hash du ZIP complet (pas seulement Merkle tree)
+6. **Fallback Tezos** : Accès masqué aux anciens ancrages (lecture seule)
+
+### Principes Fondamentaux
+
+- **Ancrage immédiat** : L'ancrage est déclenché automatiquement lors de la validation d'un document
+- **Hash filigrané** : Seule la version filigranée est ancrée sur blockchain
+- **Double hash** : Hash original et hash filigrané sont stockés pour vérification
+- **Preuve on-chain** : Le `tx_id` (transaction ID Bitcoin) est la seule preuve fiable d'ancrage
+
+### Services Backend
+
+- **WatermarkService** : Conversion documents → PDF (hors tableurs : Excel/ODS exclus), ajout filigrane "lecoffre.io"
+- **DocumentAnchorsService** : Ancrage automatique des documents validés
+- **OfficeFolderAnchorsService** : Ancrage des dossiers complets (ZIP)
+- **BitcoinSignetService** : Ancrage hash sur Bitcoin Signet via API externe
+- **ProofDataService** : Génération JSON de preuve d'ancrage
+
+### Processus d'Ancrage
+
+**Séquence de traitement (Upload)** :
+
+1. Calcul hash original (fichier original)
+2. Filigrane (sur fichier original non chiffré)
+3. Calcul hash filigrané et ancrage blockchain (hash filigrané, génération txid)
+4. Chiffrement du document filigrané
+5. Upload IPFS du document chiffré
+6. Stockage métadonnées fichier (hash original + hash filigrané)
+7. Stockage certificat BDD (document_anchor avec hash filigrané + hash original + txid)
+
+**Ancrage automatique** : Déclenché lors de la validation d'un document via `PUT /api/v1/notary/documents/:uid` (asynchrone, non bloquant).
+
+### Certificats et ZIP
+
+**Structure ZIP dossier complet** :
+
+```text
+dossier_12345678/
+├── _LISEZ-MOI.txt
+├── 01_originaux/
+├── 02_filigranes/
+├── 03_certificats/
+└── 04_preuves/
+```
+
+**Certificats PDF** : Générés automatiquement pour les documents validés et ancrés, contenant les hashs complets, le lien de transaction, et toutes les métadonnées d'ancrage.
+
+**Documentation complète** : Voir `docs/ANCRAGE_COMPLETE.md` pour les détails complets de l'architecture V3, des processus d'ancrage, des certificats, et du troubleshooting.
+
+---
+
+## Références
+
+- **Déploiement** : [DEPLOYMENT.md](./DEPLOYMENT.md)
+- **Monitoring** : [DEPLOYMENT.md](./DEPLOYMENT.md#monitoring)
+- **Ancrage** : [ANCRAGE_COMPLETE.md](./ANCRAGE_COMPLETE.md)
+- **Base de données** : [DATABASE_COMPLETE.md](./DATABASE_COMPLETE.md)
+- **Consolidation opérationnelle** : [README.md](./README.md#consolidation-operationnelle-ex-operationsmd)
+- **Correctifs et dépannage** : [FRONTEND.md](./FRONTEND.md#8-consolidation-evolutions-et-correctifs), [DEPLOYMENT.md](./DEPLOYMENT.md#maintenance-et-troubleshooting), [ANCRAGE_COMPLETE.md](./ANCRAGE_COMPLETE.md)
+
+---
+
+**Dernière mise à jour** : 2026-01-28
diff --git a/projects/lecoffreio/docs/CODE_STANDARDS.md b/projects/lecoffreio/docs/CODE_STANDARDS.md
new file mode 100644
index 0000000..3a3ed0d
--- /dev/null
+++ b/projects/lecoffreio/docs/CODE_STANDARDS.md
@@ -0,0 +1,527 @@
+# Code Standards
+
+**Version** : 2.0.0
+**Dernière mise à jour** : 2026-01-28
+**Périmètre** : Monorepo LeCoffre.io (`lecoffre-front-main`, `lecoffre-back-main`, `lecoffre-ressources-dev`)
+
+**Référence unique (checks de déploiement)** : [`docs/DEPLOYMENT.md#cartographie-des-checks-de-déploiement-source-unique`](./DEPLOYMENT.md#cartographie-des-checks-de-déploiement-source-unique)
+
+---
+
+## 📋 Table des Matières
+
+1. [Qualité du Code](#qualité-du-code)
+2. [Sécurité du Code](#sécurité-du-code)
+3. [Patterns et Bonnes Pratiques](#patterns-et-bonnes-pratiques)
+4. [Règles métier - Documents](#règles-métier---documents)
+5. [Documentation Fonctionnelle](#documentation-fonctionnelle)
+
+---
+
+## Qualité du Code
+
+### Principes Généraux
+
+- **Single Source of Truth** : toute règle doit être appliquée automatiquement (ESLint/TS/CI) et documentée ici.
+- **Pas de dette cachée** : lorsqu'une règle est impossible à satisfaire (legacy), consigner l'exception dans [README.md](./README.md#consolidation-operationnelle-ex-operationsmd) ou un plan d'action.
+- **Symétrie Front/Back/Ressources** : mêmes seuils par défaut (longueur fichiers/fonctions, style TypeScript).
+
+### Règles Automatisées
+
+| Catégorie | Règle | Projet | Statut |
+|-----------|-------|--------|--------|
+| TypeScript | `@typescript-eslint/no-explicit-any` → `warn` | front/back/ressources | ✅ ESLint |
+| TypeScript | `@typescript-eslint/no-unused-vars` + ignore `_` | front/back/ressources | ✅ ESLint |
+| Hooks React | `react-hooks/rules-of-hooks` `error` | front | ✅ ESLint |
+| Hooks React | `react-hooks/exhaustive-deps` `warn` | front | ✅ ESLint |
+| Logs | `no-console` `warn` (front), `off` (back/ressources) | front/back/ressources | ✅ ESLint |
+| Taille fichier | `max-lines` 250 lignes (blancs/commentaires exclus) | front/back/ressources | ✅ ESLint (warn front, error back) |
+| Taille fonction | `max-lines-per-function` 40 lignes | front/back/ressources | ✅ ESLint (warn front, error back) |
+| Paramètres | `max-params` 4 | front/back/ressources | ✅ ESLint |
+| Profondeur | `max-depth` 4 | front/back/ressources | ✅ ESLint |
+| Complexité | `complexity` 10 | front/back/ressources | ✅ ESLint |
+| Callbacks | `max-nested-callbacks` 3 | front/back/ressources | ✅ ESLint |
+| Markdown | MD032, MD033, MD040 | docs, user_stories, etc. | ✅ markdownlint (`npm run lint:markdown`) |
+| Typecheck | `tsc --noEmit` | front/back/ressources | ✅ Scripts `npm run typecheck` (front) / `npx tsc --noEmit` (back & ressources) |
+| Build | `npm run build` (tsc ou Next build) | front/back/ressources | ✅ Pipelines |
+| Exports inutilisés | `ts-prune` | front/back/ressources | ✅ Scripts `npm run find-deadcode` (ressources/front/back/racine) |
+
+> **Note** : Les règles `max-lines` et `max-lines-per-function` génèrent des warnings ESLint. Si un fichier legacy dépasse, documenter la dette (cf. §4).
+
+### Bonnes Pratiques Spécifiques
+
+#### Frontend (Next.js/React)
+
+- Préférer les hooks composables (`useX`) plutôt que des composants "god object".
+- Découper `pages/` en segments logiques (garder < 300 lignes par page).
+- `DocumentTables`, `FolderInformation`, `ClientView` : surveiller particulièrement la taille (historique de dépassement).
+- Pas de mutation directe du DOM/Réf hors `useRef`.
+- Logger via `LoggerService` uniquement (pas de `console` brute).
+- **Logging dans React** : Ne jamais logger dans le corps du composant ou dans le JSX. Toujours utiliser `useEffect` pour les logs de debug/info afin d'éviter les boucles de logs et les re-rendus infinis.
+- **Gestion des dépendances useEffect** : Stabiliser les dépendances avec `useMemo` et `useCallback` pour éviter les re-rendus en boucle. Ne dépendre que des valeurs qui doivent réellement déclencher l'effet.
+- **Pattern Controller/Vue** : toute page ou composant complexe doit suivre le triptyque
+  1. **Hook contrôleur** (`useFeatureController`) pour les états, appels API, calculs dérivés.
+  2. **Sous-composants présentateurs** pour découper l'UI (sections, cartes, listes).
+  3. **Helpers mutualisés** (utils/services) lorsque les mêmes opérations sont utilisées par plusieurs écrans. Fonctions cible : < 40 lignes (voir `max-lines-per-function`).
+- **SuperAdmin Health** : séparer systématiquement les widgets critiques en hooks spécialisés (`useHealthStatusTracker`, `useEndpointsHealthTester`, etc.) afin de conserver < 200 lignes par bloc et d'orchestrer la page via un contrôleur unique.
+- **Refactors en cours** : les écrans `FolderInformation`, `ClientDashboard`, `DocumentTables`, `AddClientToFolder`, `DocumentsReminderHistory`, `AskDocuments`, `CreateCustomerNote`, `VerifyDocument`, `ThirdPartyLogin`, `AdminBlockchain` ont déjà adopté ce pattern. Toute nouvelle évolution doit s'aligner sur cette architecture et documenter les changements dans [README.md](./README.md#consolidation-operationnelle-ex-operationsmd).
+- **Règle documentaire** : chaque refactor structurant (nouveau hook ou découpe majeure) doit être :
+  - Référencé dans [README.md](./README.md#consolidation-operationnelle-ex-operationsmd) (problème, impacts, root cause, correctifs).
+  - Documenté dans la consolidation documentaire pour suivre les efforts qualité.
+
+#### Backend (Node/Express/TypeDI)
+
+- Un service par responsabilité ; pas de "multi-purpose services".
+- Routes courtes : privilégier middleware/service -> controller.
+- Toujours typer les réponses (DTO communs dans `lecoffre-ressources-dev`).
+- Logger via Winston centralisé (`@Common/LoggerService`).
+- Pour les wrappers CJS/ESM (`src/common/resources/*.ts`), toujours normaliser les constructeurs hydratables avec un helper d'unwrap (`default.default` -> `default` -> module) avant exposition de `HydratableClass`.
+
+#### Ressources TypeScript
+
+- Ne jamais importer du code applicatif (seulement types/pure helpers).
+- Garder les DTO < 200 lignes (si plus : split + ré-export).
+
+### Gestion des Dépassements
+
+- **Détection** : ESLint `max-lines` / `max-lines-per-function` déclenche un `warn`.
+- **Action** :
+  1. Découper immédiatement si faisable (extractions composant/service).
+  2. Sinon, ouvrir un ticket et consigner dans [README.md](./README.md#consolidation-operationnelle-ex-operationsmd) ou en ticket :
+     - fichier/fonction impacté(e)
+     - taille actuelle + cible
+     - plan de refactor + échéance
+- **Exceptions temporaires** : Ajouter un commentaire `// TODO(MAX_LINES)` avec justificatif + lien vers ticket.
+
+- Aucun override ESLint n'est autorisé ; toute fonction > 40 lignes doit être refactorée (warn front, error back).
+- Tout fichier > 250 lignes déclenche un avertissement (front) ou erreur (back) : planifier un découpage.
+- Documenter chaque dette résiduelle dans [README.md](./README.md#consolidation-operationnelle-ex-operationsmd) (taille actuelle, cible, plan d'action, échéance) et ajouter un commentaire `// TODO(MAX_LINES)` dans le fichier concerné.
+- Les modules textuels (CGU, Privacy, etc.) doivent être synchronisés avec la base via `deploy/scripts/build-and-deploy-local-seedSiteTexts.sh` après modification.
+- Toute fonction dépréciée doit être supprimée ou migrée vers l'implémentation actuelle avant clôture du ticket.
+
+### Process de Validation
+
+1. `npm run lint` (front) / `npm run lint` (back) / `npm run lint` (ressources)
+2. `npm run lint:markdown` (racine, pour MD032/MD033/MD040)
+3. `npm run typecheck` (front) / `npx tsc --noEmit` (back & ressources)
+4. `npm run build` (tous)
+5. Vérifications manuelles spécifiques (ex: Next build warnings si variables manquantes)
+
+### Clôture corrections/évolutions
+
+À la fin de toute correction ou évolution, répondre systématiquement aux questions suivantes et implémenter les améliorations identifiées :
+
+- Modifications similaires à produire ailleurs dans le code ?
+- Optimisations, mutualisations ou centralisations possibles ?
+- Fichiers corrigés exempts d'erreurs de lint ?
+- Vérification des types du projet OK ?
+- Projet compile ?
+
+Si ces réponses ne sont pas fournies : les produire si pertinent et implémenter les améliorations identifiées (mutualisation, parties impactées).
+
+> La CI doit échouer si un warning "qualité" (taille, hooks, unused) est promu en `error`. Actuellement en `warn` pour migration progressive.
+
+### To-do Qualité
+
+| Item | Statut | Commentaire |
+|------|--------|-------------|
+| Suivi dettes `max-lines` existantes | 🔄 | Règles actives (250/40). Documenter toute exception dans [README.md](./README.md#consolidation-operationnelle-ex-operationsmd) + `// TODO(MAX_LINES)` dans le fichier ; prioriser fichiers > 250 lignes et fonctions > 40 lignes. |
+
+### Références Qualité
+
+- `eslint.config.mjs` (front/back/ressources)
+- [FRONTEND.md](./FRONTEND.md), [README.md](./README.md#consolidation-operationnelle-ex-operationsmd) pour dettes détaillées
+- CI / Scripts `deploy/scripts/*`
+- `FILES_TOO_MANY_LINES.md` : Liste des fichiers avec plus de 250 lignes (générée automatiquement)
+- `FUNCTIONS_TOO_MANY_LINES.md` : Liste des fonctions avec plus de 40 lignes (générée automatiquement)
+- `parse-lint-results-improved.js` : Script pour générer les listes de fichiers et fonctions dépassant les limites
+
+---
+
+## Sécurité du Code
+
+### Principes de Base
+
+1. **Least Privilege** : seules les routes/serveurs nécessaires sont exposés.
+2. **Defense in Depth** : validations au frontend, à l'API et au niveau ORM.
+3. **Zero Trust** : jamais de données "sûres" par défaut (même celles provenant d'intégrations tierces IdNot/Annuaire).
+4. **No Secrets in Code** : toute donnée sensible réside dans la base de configuration (`system_configuration`) ou les services secrets (aucun `.env` permanent).
+
+### Backend (Node/Express/TypeDI)
+
+#### Authentification & Permissions
+
+- **JWT** : généré côté backend via IdNot OAuth (Notaires) / login client / tiers.
+  - Champs obligatoires : `userId`, `office_Id`, `role`, `rules`, `hasActiveSubscription`, `isGuest`.
+  - Expiration : Access 1h, Refresh 7j (cf. `docs/ARCHITECTURE.md`).
+- **Middlewares** :
+  - `authHandler` : vérifie JWT (en-tête `Authorization` ou paramètre de requête `token` pour SSE uniquement, EventSource ne supportant pas les en-têtes), place l'utilisateur sur `req.user` et `req.body.user`. L'URL est nettoyée avant log (paramètre `token` supprimé). Voir `docs/ARCHITECTURE.md` et `docs/API.md`.
+  - `activeOfficeInjector` : injecte `req.activeOfficeUid`.
+  - `ruleHandler` : s'assure que l'utilisateur dispose de la règle (`resource/action`).
+- **Multi-office** : `FolderInformation` & API utilisent `folder_office_uid` + `folder_sharings`. Aucun fallback vers `office_uid` direct.
+
+#### Validation des Entrées
+
+- **Class-validator** : tous les DTOs exposés doivent étendre `BaseDto` + décorateurs `@IsString`, `@IsUUID`, etc.
+- **Paramètre de requête `q`** : utiliser `parseQueryParam<T>(req.query["q"], "GET /...")` (voir `#Common/utils/jsonHelpers.ts`) pour tout parsing de `req.query["q"]`. Ne jamais utiliser `JSON.parse(req.query["q"])` directement (risque de crash et de prototype pollution).
+- **Prisma** : aucun `where` construit à la main sans sanity-check (Obligation : `deleted_at: null` pour toutes les entités soft-delete).
+- **Payload externe (IdNot, API Annuaire)** : vérifier les champs obligatoires avant insertion. Les erreurs (ex: payload incomplet) doivent être loggées, pas silencées.
+
+#### Stockage Sensible
+
+- **RIB** : AES-256-GCM (clé en base). Process et variables sensibles : voir [DATABASE_COMPLETE.md](./DATABASE_COMPLETE.md#configuration-systeme-dynamique).
+- **Fichiers** : Pinata + S3. Seuls les hash + métadonnées sont gardés.
+- **Secrets** : jamais dans le code. Toute nouvelle config doit transiter par `system_configuration`.
+
+#### Logging & Audits
+
+- **Winston** standard (level info/warn/error) + Sentry (optionnel).
+- Aucune donnée sensible (RIB, tokens OAuth, OTP) dans les logs.
+- Les actions critiques (ancrages, partages, login IdNot) doivent être loggées avec `folder_uid`, `userId`, `office_uid`.
+
+#### Protection API
+
+- **Rate limiting** (cf. `docs/DEPLOYMENT.md`) : 4 niveaux (public/strict/auth/global).
+- **Validation d'accès** : les routes tierces (`/third-party/*`) doivent vérifier `folder_uid` et `third_party_uid`. Aucun accès ne doit être accordé sans double filtre (folder + user).
+- **Ancrage** : l'état `tx_id` est la seule preuve (pas de `status = ANCHORED` sans TX).
+
+#### Antivirus Uploads
+
+- `AntivirusService` (Node) contacte `clamav` via INSTREAM (TCP 3310) avant toute transformation.
+- Configuration dynamique (`system_configuration`) :
+  - `CLAMAV_HOST`, `CLAMAV_PORT` (obligatoires)
+  - `CLAMAV_SCAN_ENABLED` (toggle exceptionnel), `CLAMAV_CONNECTION_TIMEOUT_MS`, `CLAMAV_READ_TIMEOUT_MS`, `CLAMAV_MAX_FILE_SIZE_MB`
+- Blocage strict :
+  - Malware détecté → `400` `ErrorMessages.FILE_INFECTED` (aucun fallback).
+  - Timeout / indispo ClamAV → `500` via `handleInternalError` (upload interrompu).
+- Tous les services de fichiers (`FilesService`, `FilesNotaryService`, copies buffer) appellent `AntivirusService` avant hash/filigrane/ancrage.
+
+### Frontend (Next.js/React)
+
+#### Données & Permissions
+
+- **Stores** (MobX) : ne jamais stocker de secrets (uniquement les règles/role/office).
+- **ActiveOfficeStore** : toujours utiliser `activeOfficeStore.activeOffice?.office_uid` plutôt que des `ids` en clair.
+- **Invités** : `DefaultCustomerDashboard` devient la seule vue (pas de fallback notaire). Tout bouton/action doit vérifier `rolePermissionsStore.can(...)`.
+
+#### API Calls
+
+- Passer par `BaseApiService` (ajoute `Authorization` + logger).
+- Jamais de fetch direct (ex: `fetch("/api/v1/...")`).
+- Gestion d'erreurs utilisateur : `ToasterService`, jamais de `alert()` brut (sauf fallback tiers).
+- Build : si les variables `NEXT_PUBLIC_*` manquent, le build doit logguer l'avertissement (déjà en place).
+
+#### XSS / DOM
+
+- Utiliser systématiquement `dangerouslySetInnerHTML` **uniquement** si la donnée est whitelistée & sanitized (ex: templates Markdown validés).
+- Form inputs : valider côté frontend (`emailRegex`, `file size`, etc.) avant de poster.
+- `document.cookie` n'est jamais manipulé en direct (uniquement via `AuthService`).
+
+### Ressources TypeScript
+
+- DTOs & enums ne doivent contenir aucune logique.
+- Toute évolution de type doit être propagée dans le backend + frontend (contrôle croisé `npm run typecheck`).
+- Les types `never` ou `any` sont interdits dans les exports publics. Si usage interne, commenter le TODO.
+
+### Workflows Sécurité
+
+| Vérification | Script / Étape |
+|--------------|----------------|
+| Lint (règles de taille, hooks, types) | `npm run lint` |
+| TypeScript (front) | `npm run typecheck` |
+| TypeScript (back/ressources) | `npx tsc --noEmit` |
+| Build | `npm run build` |
+| Hooks secrets (IdNot/Annuaire) | `docs/API.md`, `docs/ID.NOT ...` |
+| Audit RIB | [DATABASE_COMPLETE.md](./DATABASE_COMPLETE.md#variables-sensibles) |
+
+### Checklist Pull Requests
+
+1. `npm run lint` + `npm run typecheck` sur les modules modifiés.
+2. Vérifier que les logs ne divulguent aucune data sensible.
+3. Ajouter/Mettre à jour la doc (ce document pour la dette, section Sécurité du Code et [README.md](./README.md#consolidation-operationnelle-ex-operationsmd) si nouvelles surfaces).
+4. Vérifier que toute nouvelle route tierce utilise `folder.uid` + `third_party.uid` (pas d'identifiant libre).
+5. Pour les parcours invités : s'assurer que `DefaultCustomerDashboard` est utilisé (pas de fallback notaire).
+
+### Dettes & TODO Sécurité
+
+| Sujet | Statut | Action |
+|-------|--------|--------|
+| Inventaire `console.log` backend | 🔄 | Passer sur Winston (phase 2). |
+
+### Références Sécurité
+
+- [ARCHITECTURE.md](./ARCHITECTURE.md)
+- [DATABASE_COMPLETE.md](./DATABASE_COMPLETE.md) (configuration système, variables sensibles, ClamAV)
+- `docs/API.md` : rapport d'audit applicatif (logging tokens, parsing `q`, config sensible, token en URL SSE)
+- [ANCRAGE_COMPLETE.md](./ANCRAGE_COMPLETE.md)
+- [README.md](./README.md#consolidation-operationnelle-ex-operationsmd) pour les incidents précis
+
+---
+
+## Patterns et Bonnes Pratiques
+
+Ce document décrit les patterns réutilisables et les bonnes pratiques à suivre dans le projet LeCoffre.io.
+
+> **Note** : Le contenu détaillé des patterns est consolidé dans ce document (sections Patterns et Bonnes Pratiques ci-dessous).
+
+### Patterns Principaux
+
+#### Gestion d'Erreurs (Backend)
+
+**Modules** :
+
+- `lecoffre-back-main/src/common/utils/errorMessages.ts` : Messages d'erreur centralisés
+- `lecoffre-back-main/src/common/utils/errorLoggers.ts` : Patterns de logging standardisés
+- `lecoffre-back-main/src/common/utils/errorHandlers.ts` : Gestion HTTP centralisée
+- `lecoffre-back-main/src/common/system/controller-pattern/BaseController.ts` : Toutes les méthodes `http*` délèguent désormais aux helpers ci-dessus (log + message homogènes)
+
+**Fonctions principales** :
+
+- `handleInternalError(response, error, req?, operation?)` : Gère et répond à une erreur interne
+- `handleValidationError(response, error, req?, operation?)` : Gère et répond à une erreur de validation
+- `handleNotFoundError(response, message?, req?, operation?)` : Gère et répond à une erreur 404
+- `handleForbiddenError(response, message?, req?, operation?)` : Gère et répond à une erreur 403
+- `handleBadRequestError(response, message?, req?, operation?)` : Gère et répond à une erreur 400
+- `logError(error, context?, operation?)` : Log une erreur avec format standardisé
+
+#### Helpers Utilisateurs (Backend)
+
+**Module** : `lecoffre-back-main/src/common/utils/userHelpers.ts`
+
+**Fonctions principales** :
+
+- `isSuperAdminUser(user, role?)` : Vérifie si un utilisateur est super-admin
+- `extractUserData(bodyUser, authUser, permissionContext)` : Extrait et normalise les données utilisateur
+- `getStringFromRecord(record, key)` : Extrait une valeur string d'un record
+- `getBooleanFromRecord(record, key)` : Extrait une valeur boolean d'un record
+
+#### Helpers proof_data (Backend)
+
+**Module** : `lecoffre-back-main/src/common/utils/proofDataHelpers.ts`
+
+Helpers pour la validation et l'extraction de la structure proof_data (V3.0.0).
+
+**Fonctions principales** :
+
+- `getAntivirusStatusFromProofData(proofData)` : Extrait `antivirus_scan_at` de `proof_data.document`
+- `isProofDataComplete(proofData)` : Vérifie si proof_data a la structure V3.0.0 complète (version, timestamp, document, anchor, verification)
+
+**Utilisé par** : `bilan-documents-pprod.ts`, `reprocess-all-documents-complete.ts`, `reprocess-incomplete-documents-from-ipfs.ts`
+
+#### Hook API Client (Frontend)
+
+**Module** : `lecoffre-front-main/src/front/Hooks/useApiClient.ts`
+
+Ce hook centralise la gestion des appels API frontend avec gestion standardisée des tokens, headers, et erreurs.
+
+**Usage** :
+
+```typescript
+import { useApiClient } from "@Front/Hooks/useApiClient";
+
+const apiClient = useApiClient();
+const data = await apiClient.get("/api/v1/notary/folders");
+```
+
+#### Pattern Controller/Vue (Frontend)
+
+**Structure** :
+
+1. **Hook contrôleur** (`useFeatureController`) : Gère les états, appels API, calculs dérivés
+2. **Sous-composants présentateurs** : Découpent l'UI en sections logiques
+3. **Hooks spécialisés** : Extraient la logique métier complexe
+
+**Règles** :
+
+- Fonction principale : Doit rester < 40 lignes (orchestration uniquement, aligné sur `max-lines-per-function`)
+- Hooks contrôleurs : Peuvent dépasser 40 lignes si la logique métier est complexe (documenter en TODO(MAX_LINES) si > 40)
+- Sous-composants : Doivent rester < 40 lignes chacun
+
+#### DTOs et Validation Centralisée (Backend)
+
+**Module** : `lecoffre-back-main/src/common/dtos/`
+
+Les DTOs (Data Transfer Objects) fournissent une validation forte des entrées API avec `class-validator` et `class-transformer`.
+
+**Helper de Validation** :
+
+```typescript
+import { validateRequestBody } from "@Common/utils/validationHelpers";
+import { CreateDocumentDTO } from "@Common/dtos";
+
+const dto = await validateRequestBody(
+  CreateDocumentDTO,
+  req.body,
+  req,
+  response,
+  "POST /notary/documents"
+);
+```
+
+### Patterns Réutilisables
+
+Pour une documentation complète de tous les patterns disponibles, consulter :
+
+- **Backend** : Helpers Prisma, SQL, UID extraction, Request helpers, Repository helpers, Date helpers, Array helpers, Type guards
+- **Frontend** : Hooks (useDataLoader, useModal, useForm, useAsyncOperation, useSearchWithDebounce), Helpers (formatters, validators, error classifiers, retry helpers), Composants génériques (ConfirmModal, UpdateFormLayout, DocumentTableSection)
+
+#### Helpers Documents (Frontend)
+
+**Modules** : `lecoffre-front-main/src/front/Utils/`
+
+- `documentNameHelpers.ts` : `hasDocumentName`, `getDocumentNameWithTypePriority` (priorité : document_type.name > display_name > file_name > fallback)
+- `documentTypeHelpers.ts` : `getDocumentTypeNameLower`, `getDocumentTypeName`, `isDocumentNotaireType`, `isDocumentTypeAutresDocuments`, `DOCUMENT_NOTAIRE_TYPE`, `DOCUMENT_NOTAIRE_LABEL`, `AUTRES_DOCUMENTS_TYPE`
+- `statusHelpers.ts` : `statusUpper` (normalisation casse des statuts document)
+
+### Notes Importantes
+
+- **Toujours utiliser les modules centralisés** : Éviter de dupliquer la logique, utiliser les modules existants.
+- **Migration progressive** : Migrer les fichiers au fur et à mesure, pas besoin de tout migrer d'un coup.
+- **Tests** : Les modules centralisés sont plus faciles à tester unitairement.
+- **Documentation** : Mettre à jour ce document si de nouveaux patterns sont ajoutés.
+- **Logging React** : Ne jamais logger dans le corps du composant ou dans le JSX, toujours utiliser `useEffect`.
+- **DTOs** : Utiliser les DTOs pour valider toutes les entrées API avec des messages d'erreur clairs.
+- **Hydratation** : Utiliser les helpers d'hydratation pour une conversion cohérente des entités.
+- **Services Façade** : Préférer les façades pour la simplicité, accéder aux services spécialisés pour les cas avancés.
+- **Pattern Controller/Vue** : Appliquer systématiquement pour les composants > 40 lignes afin de respecter `max-lines-per-function`.
+- **Request Helpers** : Utiliser les helpers `requestHelpers.ts` pour extraire les IDs depuis les requêtes au lieu de dupliquer la logique.
+- **RequestWithPermissionContext** : Le type de base `Request & { permissionContext?: PermissionContext }` est exporté depuis `#Common/utils/requestHelpers`. L'importer pour typer les requêtes avec contexte de permission ; étendre localement si une route a besoin de champs supplémentaires (ex. `body.user`, `user`), par ex. `type LocalReq = RequestWithPermissionContext & { body?: { user?: ... } }`.
+
+#### Orchestrateurs de sortie documents (Backend)
+
+Pour les réponses API documents, utiliser exclusivement les orchestrateurs de post-hydratation :
+
+- `documentsNotaryPostHydrationHelper` pour `DocumentsNotary`
+- `documentsPostHydrationHelper` pour `Documents`
+
+Règles :
+
+1. Ne pas reconstruire localement une sortie `plain` avec `instanceToPlain` + merge manuel dans les controllers/helpers.
+2. Utiliser les fonctions `build*PlainWithRelations` / `hydrate*ToPlainWithRelations` pour les listes et mono-entités.
+3. Conserver les garde-fous `log*FilesGuard` pour détecter les incohérences de `files`.
+4. Toute nouvelle route documents doit réutiliser ces orchestrateurs.
+5. Pour `Documents` côté `admin` / `super-admin`, les flux `update`, `refuse` et `delete` doivent retourner un `plain` construit via `documentsPostHydrationHelper` (pas de `hydrateEntity` retourné directement).
+6. Pour les suppressions `Documents` (`notary`, `admin`, `super-admin`), utiliser le helper commun `buildDeletedDocumentPlainResponse` pour réinjecter `document_type` sans duplication locale.
+7. Pour les récupérations mono-entité `Documents` destinées à une réponse API, utiliser `fetchDocumentWithResponseInclude` afin d’unifier `include` (`document_type` + include demandé) et éviter la duplication de `getByUid(..., { document_type: true })`.
+8. Pour transformer une entité `Documents` récupérée en payload API mono-entité, utiliser `buildPlainFromFetchedDocument` pour centraliser `hydrateEntity + buildSingleDocumentPlainWithRelations`.
+9. Pour les flux mono-entité `update/refuse/restore/delete`, utiliser `buildPlainResponseWithOptionalSourceDocumentType` pour unifier la réinjection optionnelle de `document_type` (source explicite si présente, sinon entité courante).
+10. Pour `DocumentsNotary` mono-entité, utiliser `buildDocumentNotaryPlainResponseWithOptionalSource` pour homogénéiser le rendu `plain` (source optionnelle + réinjection fichiers).
+11. Pour les contrôleurs `Documents` mono-entité (`admin/super-admin/notary`), privilégier `fetchDocumentPlainOrHandleNotFound` quand le flux suit le pattern `fetch + not found + build plain`.
+12. Pour les contrôleurs `DocumentsNotary` mono-entité, privilégier `fetchDocumentNotaryPlainOrHandleNotFound` avec `withDocumentNotaryResponseInclude` afin d’imposer l’include de réponse et standardiser le `not found`.
+13. Pour les validations `not found + deleted` sur `Documents`, réutiliser `createValidateDocumentNotDeletedCallback` plutôt que redéfinir des closures locales.
+14. Pour les règles d’accès `DocumentsNotary` en mono-entité, utiliser `createDocumentNotaryAccessValidator` en callback réutilisable afin d’éviter la duplication `verify...Access` entre contrôleurs.
+15. Pour la visibilité/état `DocumentsNotary` (statut métier, présence de fichiers visibles), utiliser `createDocumentNotaryVisibilityStateValidator` et l’injecter dans `fetchDocumentNotaryPlainOrHandleNotFound`.
+16. Préférer le preset `createDocumentsNotarySentOrDownloadedVisibilityValidator` pour les routes de consultation/téléchargement `DocumentsNotary` (customer/notary) afin d’éviter la répétition des `allowedStatuses`.
+17. Pour les endpoints de téléchargement `DocumentsNotary`, utiliser le preset `createDocumentsNotaryDownloadVisibilityValidator` (`requireAtLeastOneNonArchivedFile: true`) afin de mutualiser la règle “document téléchargeable” (statut + au moins un fichier non archivé).
+18. Pour les flux fallback `Documents` (routes `DocumentsNotary` qui basculent sur la table `Documents`) et les contrôles transverses, utiliser les helpers communs `isDocumentSentOrDownloadedStatus` / `validateDocumentsSentOrDownloadedStatus` (`common/utils/documentsVisibilityStateHelpers.ts`) afin d’éviter les checks locaux divergents.
+19. Pour les usages métier où `VALIDATED`, `SENT` et `DOWNLOADED` sont traités comme “document validé/exploitable” (naming/ZIP/export), utiliser `isDocumentValidatedOrSentOrDownloadedStatus` afin d’éviter les tableaux de statuts locaux.
+
+---
+
+## Règles métier - Documents
+
+### Évolution planifiée (Documents unifiés)
+
+Voir [ARCHITECTURE.md - Évolution planifiée - Documents unifiés](./ARCHITECTURE.md#évolution-planifiée---documents-unifiés) pour :
+
+- Flux d'envoi unifié avec destinataire de type union (`customer` | `third_party` | `office` | `invited_notary`).
+- Métadonnée `emitter` (uid, first_name, last_name, office_uid?, office_name?) sur toutes les réponses.
+- Constante `DOCUMENT_DISPLAY_BASE_INCLUDE` (`#Common/constants/DocumentsIncludeConstants`) : inclure `emitter` avec `contact` et `folder` avec `stakeholders` dans tous les contextes où les documents sont affichés.
+- Documents du notaire invité traités comme tiers/clients.
+
+### Statuts des documents
+
+Les états des documents sont gérés par membre et par document. Un statut sur le document d'un membre n'affecte en aucun cas un autre membre.
+
+- Chaque document (Documents ou DocumentsNotary) est lié à un destinataire unique (customer, tiers, confrère).
+- Les mises à jour de statut (SENT, DOWNLOADED, VALIDATED, etc.) s'appliquent à un document identifié par son `uid`.
+- Aucune mise à jour groupée ou propagation de statut entre documents de membres différents.
+
+### Tableau « Documents envoyés »
+
+Dans les espaces clients, tiers et notaires invités (onglets participants du dossier), le tableau des documents envoyés par le notaire liste des **documents** (une ligne = un document), et non des fichiers.
+
+- Chaque ligne du tableau correspond à une entrée `documents_notary` ou `documents`.
+- L'affichage peut utiliser le nom du fichier PDF (ex. `document.pdf`) pour identifier visuellement le document, mais l'entité représentée reste le document.
+- Un document peut contenir plusieurs fichiers fusionnés en un seul PDF ; la ligne représente le document, pas chaque fichier individuellement.
+
+### Upload : fusion et page de métadonnées
+
+Tous les uploads (1 ou plusieurs fichiers) sont fusionnés en un seul PDF avec page de métadonnées (hash des fichiers originaux). FileMergeService, MergedFileCreationHelper, FileMergeHelpers (buildFilesMetadataForMerge, buildMergedMulterFile). Pas de shortcut pour 1 fichier : toujours fusion.
+
+### Validation d'accès document (deux entrées, convergence)
+
+Deux chemins coexistent pour la validation d'accès aux documents ; l'objectif est de les faire converger vers une seule source de règles.
+
+1. **Service central** : `DocumentAccessValidationService` (`#Services/common/DocumentAccessValidationService`) — valide l'accès selon le type (guest_notary, invited_notary, thirdparty, customer, notary). Utilisé par la couche API via `createDocumentNotaryAccessValidator` (voir `documentsNotaryValidatorsHelpers.ts`) : les helpers (DocumentsNotaryGetOneByUidHelper, DocumentsNotaryMarkAsViewedHelper, DocumentsNotaryCaseHandlers) fournissent un callback `validateAccess` qui peut s'appuyer sur ce service.
+2. **Middlewares** : `DocumentAccessValidationHelper` (OfficeMembershipHandlers), `FileHandlerAccessHelpers.validateDocumentAccess` / `validateFileAccess`, `DocumentHandlerAccessByUidHelper` — chargent le document, vérifient l'accès au dossier via `ensureFolderAccess` et appliquent des règles métier similaires.
+
+**Convergence prévue** : faire appeler par les middlewares le `DocumentAccessValidationService.validateAccess` en construisant un `DocumentAccessContext` à partir du contexte requête, afin d'éviter la double maintenance et les écarts de comportement. En attendant, toute modification des règles d'accès doit être répercutée dans les deux chemins ou documentée comme temporaire.
+
+---
+
+## Documentation Fonctionnelle
+
+Cette section décrit de façon fonctionnelle chaque fichier du projet, expliquant son intérêt dans le projet et ce qu'il fait de façon résumée.
+
+> **Note** : Le contenu détaillé fichier par fichier est consolidé dans ce document (section Documentation Fonctionnelle ci-dessous).
+
+### Synthèse Optimisations Fiabilité & Simplicité (déc. 2025)
+
+| Axe | État | Détails |
+| --- | --- | --- |
+| Gestion d'erreurs | **Terminé** | `errorHandlers.ts`, `errorLoggers.ts`, `errorMessages.ts` et depuis 2025-12, toutes les méthodes `http*` du `BaseController` délèguent à ces helpers (logs Winston homogènes, messages centralisés). |
+| Résolution permissions/rôles | **Terminé** | Découpage de `RulesHandler` en `decisionHandlers`, `ruleMatcher`, `resourceResolver`, `roleResolver` + helpers `userHelpers.ts`, `roleNormalizer.ts`, `uidExtractors.ts`. |
+| API client frontend | **Terminé** | Hook `useApiClient` + helpers `errorClassifiers`, `retryHelpers`, `formValidators`, `formatters` pour supprimer les appels `fetch` dupliqués. |
+| Duplication helpers JWT / extraction utilisateur | **✅ Terminé** | Helpers centralisés dans `userHelpers.ts` (`getStringFromRecord`, `getBooleanFromRecord`, `getStringArrayFromRecord`, `extractUserData`) - tous les fichiers migrés. |
+| Validation formulaires frontend | **✅ Terminé** | Validations centralisées dans `front/Utils/formValidators.ts` (`validateEmail`, `validatePassword`, `validateRequired`, etc.) - regex inline remplacées. |
+| Formatage prix / données | **✅ Terminé** | Fonctions centralisées dans `front/Utils/formatters.ts` (`formatPrice`, `formatDate`, `formatMonthString`, `truncateHash`, etc.) - tous les fichiers utilisent les helpers centralisés. |
+| Tests & documentation | **En cours** | Chaque lot migré doit être consigné dans [README.md](./README.md#consolidation-operationnelle-ex-operationsmd) (root cause, impacts) et dans ce document (CODE_STANDARDS.md). |
+
+### Structure du Projet
+
+#### Backend (lecoffre-back-main/src/)
+
+- **Entries** : Points d'entrée (`App.ts`, `Cron.ts`)
+- **App** : Configuration Express, middlewares, routes
+- **App/api/customer** : Contrôleurs et helpers customer ; constantes statuts dans `api/customer/constants/documentStatusConstants.ts` (`DOCUMENTS_TO_SEND_STATUSES`, `DOCUMENT_STATUSES_RECEIVED_FROM_NOTARY`) pour alignement sémantique avec le front et réutilisation (ex. filtre « documents à envoyer »). `DocumentsQueryHelper` et requêtes customer peuvent s'y référer (voir JSDoc).
+- **Common** : Utilitaires partagés (error handlers, helpers, DTOs, emails)
+- **Services** : Services métier (Files, Documents, Folders, Users, etc.)
+
+#### Frontend (lecoffre-front-main/src/)
+
+- **Pages** : Pages Next.js (routes)
+- **Front** : Composants, hooks, stores, API clients, utils
+
+#### Ressources (lecoffre-ressources-dev/src/)
+
+- **Admin** : Types et DTOs pour l'administration
+- **Customer** : Types et DTOs pour les clients
+- **Notary** : Types et DTOs pour les notaires
+- **SuperAdmin** : Types et DTOs pour le super-admin
+- **MemberTypes** : Types centralisés pour `userType` (JWT), `role` (role_permissions_matrix) et `UserContext` (frontend). Constantes : `USER_TYPE_THIRDPARTY`, `USER_TYPE_CUSTOMER`, `ROLE_CLIENT`, `ROLE_NOTARY`, `ROLE_GUEST_NOTARY`, `USER_CONTEXT_CUSTOMER`, `USER_CONTEXT_NOTARY`, `USER_CONTEXT_INVITED_NOTARY`, `USER_CONTEXT_THIRD_PARTY`, `THIRD_PARTY_UI_VARIANT`, `ROLES`. Helpers : `isRole`, `isThirdParty`, `isCustomer`, `isGuestNotary`, `isNotaryRole`.
+
+### Documentation Complète
+
+La documentation détaillée fichier par fichier a été archivée (voir historique Git). Les patterns et la structure sont dans les sections ci-dessus. README des sous-projets : `lecoffre-back-main`, `lecoffre-front-main`, `lecoffre-ressources-dev`.
+
+---
+
+## Sécurité Applicative
+
+Résumé : **Chiffrement** (clé maître `FILE_ENCRYPTION_MASTER_KEY`, AES-256-GCM, tous les fichiers) ; **2FA tiers** (request-code/verify-code, codes 6 chiffres, JWT `userType: 'thirdparty'`) ; **Déconnexion** (table `revoked_tokens`, `POST /api/v1/auth/logout`) ; **ClamAV** (AntivirusService, daemon clamd, config dans `system_configuration`). Détail : [DATABASE_COMPLETE.md](./DATABASE_COMPLETE.md) et [SCRIPTS.md](./SCRIPTS.md).
+
+---
+
+## Références Générales
+
+- `eslint.config.mjs` (front/back/ressources)
+- `docs/ARCHITECTURE.md` : Architecture générale du système
+- `docs/DEPLOYMENT.md` : Guide de déploiement
+- `docs/API.md` : Documentation des APIs externes
+- [README.md](./README.md#consolidation-operationnelle-ex-operationsmd) : Documentation des problèmes et correctifs
+- [ARCHITECTURE.md](./ARCHITECTURE.md) et [FRONTEND.md](./FRONTEND.md) : Documentation des évolutions
+
+---
+
+**Dernière mise à jour** : 2026-02-27
diff --git a/projects/lecoffreio/docs/DATABASE_COMPLETE.md b/projects/lecoffreio/docs/DATABASE_COMPLETE.md
new file mode 100644
index 0000000..7c77741
--- /dev/null
+++ b/projects/lecoffreio/docs/DATABASE_COMPLETE.md
@@ -0,0 +1,1709 @@
+# Documentation Complète de la Base de Données LeCoffre.io
+
+**Date** : 30 octobre 2025
+**Version** : 2.0.1
+**Auteur** : Équipe 4NK
+
+**Référence unique (checks de déploiement)** : [`docs/DEPLOYMENT.md#cartographie-des-checks-de-déploiement-source-unique`](./DEPLOYMENT.md#cartographie-des-checks-de-déploiement-source-unique)
+
+---
+
+## 📋 Table des matières
+
+1. [Vue d'ensemble](#vue-densemble)
+2. [Architecture et structure](#architecture-et-structure)
+3. [Schéma Prisma complet](#schéma-prisma-complet)
+4. [Gestion des migrations](#gestion-des-migrations)
+5. [Configuration système dynamique](#configuration-système-dynamique)
+6. [Soft Delete (Suppression logique)](#soft-delete-suppression-logique)
+7. [Reset et import de base de données](#reset-et-import-de-base-de-données)
+8. [Commandes et outils](#commandes-et-outils)
+9. [Liens et références](#liens-et-références)
+
+---
+
+## Vue d'ensemble
+
+### Base de données
+
+- **Type** : PostgreSQL 14+
+- **Port** : **5442** (non-standard, spécifique au projet)
+- **ORM** : Prisma 4.16
+- **Schéma** : `lecoffre-back-main/src/common/databases/schema.prisma`
+- **Migrations** : `lecoffre-back-main/prisma/migrations/`
+
+### Caractéristiques principales
+
+- ✅ **Configuration dynamique** : Tous les paramètres système stockés en BDD (`system_configuration`)
+- ✅ **Soft delete** : Suppression logique pour dossiers, documents, clients
+- ✅ **Multi-offices** : Gestion multi-études avec affiliations
+- ✅ **Ancrage blockchain** : Bitcoin Signet pour documents et dossiers
+- ✅ **Chiffrement** : AES-256-GCM pour données sensibles (RIB)
+- ✅ **Synchronisation** : Tables dédiées pour IdNot et API Annuaire
+- ✅ **Audit trail** : Logs d'audit et historique des modifications
+
+### Connexion
+
+**Format URL** :
+```text
+postgresql://USERNAME:PASSWORD@HOST:PORT/DATABASE?schema=public
+```
+
+**Variables d'environnement** :
+```bash
+DATABASE_HOST=<IP_POSTGRESQL>
+DATABASE_PORT=<PORT_POSTGRESQL>  # 5442
+DATABASE_USERNAME=lecoffre-user-${ENV}
+DATABASE_PASSWORD=<MOT_DE_PASSE>
+DATABASE_NAME=bdd-${ENV}
+DATABASE_URL=postgresql://${DATABASE_USERNAME}:${DATABASE_PASSWORD}@${DATABASE_HOST}:${DATABASE_PORT}/${DATABASE_NAME}?schema=public
+```
+
+---
+
+## Architecture et structure
+
+### Organisation des modèles
+
+#### 1. Entités principales
+
+- **Users** : Utilisateurs notaires (authentification IdNot)
+- **Offices** : Études notariales
+- **OfficeFolders** : Dossiers clients
+- **Documents** : Documents clients
+- **Customers** : Clients (authentification email/2FA)
+- **Contacts** : Informations de contact (partagées)
+- **Addresses** : Adresses (partagées)
+
+#### 2. Gestion des rôles et permissions
+
+- **Roles** : Rôles globaux (`admin`, `super-admin`, `notary`, `default`)
+- **OfficeRoles** : Rôles spécifiques à un office (`Notaire`, `Collaborateur`)
+- **Rules** : Règles d'accès (CRUD par ressource)
+- **RolePermissionsMatrix** : Matrice de permissions (143 lignes)
+
+#### 3. Abonnements et facturation
+
+- **SubscriptionPlans** : Plans d'abonnement (Standard, Unlimited)
+- **Subscriptions** : Abonnements actifs par office
+- **Seats** : Sièges utilisateurs par abonnement
+
+#### 4. Ancrage blockchain
+
+- **DocumentAnchors** : Ancres de documents individuels
+- **OfficeFolderAnchors** : Ancres de dossiers (agrégées)
+- **DocumentNotaryAnchors** : Ancres de documents notaires
+- **AggregatedCertificates** : Certificats agrégés par dossier
+
+#### 5. Synchronisation externe
+
+- **SyncOffices** : Synchronisation offices IdNot
+- **SyncPersons** : Synchronisation personnes IdNot
+- **SyncAffiliations** : Synchronisation affiliations IdNot
+- **SyncStripeSubscriptions** : Synchronisation abonnements Stripe
+- **SyncDailyMetrics** : Métriques quotidiennes
+- **AnnuOffices** : Offices API Annuaire
+- **AnnuPersons** : Personnes API Annuaire
+- **AnnuAffiliations** : Affiliations API Annuaire
+
+#### 6. Configuration et textes
+
+- **SystemConfiguration** : Configuration système dynamique (109 configs)
+- **SiteTexts** : Textes éditoriaux multi-langue
+
+#### 7. Sécurité et audit
+
+- **RevokedTokens** : Tokens JWT révoqués
+- **AuditLogs** : Logs d'audit des actions
+- **Whitelist** : Liste blanche emails
+- **UserWhitelist** : Liste blanche IdNot
+
+#### 8. Tiers et partage
+
+- **FolderThirdParties** : Tiers (courtiers, agents) associés aux dossiers
+- **ThirdPartyTotpCodes** : Codes OTP pour tiers
+- **FolderSharing** : Partage de dossiers entre offices
+
+---
+
+## Schéma Prisma complet
+
+### Modèles principaux
+
+#### Users (Utilisateurs notaires)
+
+```prisma
+model Users {
+  uid                 String                   @id @unique @default(uuid())
+  idNot               String                   @unique @db.VarChar(255)
+  contact             Contacts                 @relation(...)
+  contact_uid         String                   @unique @db.VarChar(255)
+  role                Roles                    @relation(...)
+  roles_uid           String                   @db.VarChar(255)
+  is_super_admin      Boolean                  @default(false)
+  office_role         OfficeRoles?             @relation(...)
+  office_role_uid     String?                  @db.VarChar(255)
+  office_membership   Offices                  @relation(...)
+  office_uid          String                   @db.VarChar(255)
+  // Relations
+  office_folders      OfficeFolders[]
+  created_folders     OfficeFolders[]
+  documents_notary    DocumentsNotary[]
+  office_affiliations UserOfficeAffiliations[]
+  shared_folders      FolderSharing[]
+  third_parties_added FolderThirdParties[]
+}
+```
+
+**Caractéristiques** :
+
+- Authentification via IdNot OAuth
+- Rôles globaux et rôles d'office
+- Support multi-offices via `UserOfficeAffiliations`
+- Flag `is_super_admin` pour accès super-admin
+
+#### Offices (Études notariales)
+
+```prisma
+model Offices {
+  uid                 String                    @id @unique @default(uuid())
+  idNot               String                    @unique @db.VarChar(255)
+  name                String                    @db.VarChar(255)
+  crpcen              String                    @unique @db.VarChar(255)
+  address             Addresses                 @relation(...)
+  address_uid         String                    @unique @db.VarChar(255)
+  office_status       EOfficeStatus             @default(DESACTIVATED)
+  // RIB chiffré
+  rib_encrypted       String?                   @db.Text
+  rib_iv              String?                   @db.VarChar(255)
+  rib_auth_tag        String?                   @db.VarChar(255)
+  rib_key_version     String?                   @db.VarChar(50)
+  rib_encrypted_at    DateTime?
+  // Ancrage RIB
+  rib_anchor_hash     String?                   @db.VarChar(255)
+  rib_anchor_tx_id    String?                   @db.VarChar(255)
+  rib_anchor_tx_link  String?                   @db.VarChar(255)
+  rib_anchor_tx_hash  String?                   @db.VarChar(255)
+  rib_anchor_block_height Int?
+  rib_anchor_anchored_at DateTime?
+  rib_anchor_proof_data Json?
+  // Clé de chiffrement office
+  office_encryption_key String?                  @db.VarChar(255)
+  office_encryption_key_created_at DateTime?
+  // Relations
+  users               Users[]
+  office_folders      OfficeFolders[]
+  subscriptions       Subscriptions[]
+  customers           Customers[]
+  user_affiliations   UserOfficeAffiliations[]
+}
+```
+
+**Caractéristiques** :
+
+- Chiffrement AES-256-GCM pour RIB
+- Ancrage blockchain Bitcoin Signet pour RIB
+- Clé de chiffrement unique par office
+- Statut activation/désactivation
+
+#### OfficeFolders (Dossiers)
+
+```prisma
+model OfficeFolders {
+  uid                  String            @id @unique @default(uuid())
+  folder_number        String            @db.VarChar(255)
+  name                 String            @db.VarChar(255)
+  description          String?           @db.VarChar(1000)
+  archived_description String?           @db.VarChar(255)
+  status               EFolderStatus     @default(LIVE)
+  deed                 Deeds             @relation(...)
+  deed_uid             String            @unique @db.VarChar(255)
+  office               Offices           @relation(...)
+  office_uid           String            @db.VarChar(255)
+  created_by           Users?            @relation(...)
+  created_by_uid       String?           @db.VarChar(255)
+  // Soft delete
+  deleted_at           DateTime?
+  deleted_by_uid       String?           @db.VarChar(255)
+  // Ancrage
+  folder_anchor        OfficeFolderAnchors? @relation(...)
+  folder_anchor_uid    String?              @unique @db.VarChar(255)
+  // Relations
+  stakeholders         Users[]
+  customers            Customers[]
+  documents            Documents[]
+  documents_notary     DocumentsNotary[]
+  folder_sharings      FolderSharing[]
+  third_parties        FolderThirdParties[]
+  aggregated_certificates AggregatedCertificates[]
+}
+```
+
+**Statuts** :
+
+- `LIVE` : Dossier actif
+- `ARCHIVED` : Dossier archivé
+- `DELETED` : Dossier supprimé (soft delete)
+
+#### Documents
+
+```prisma
+model Documents {
+  uid                       String              @id @unique @default(uuid())
+  document_status           EDocumentStatus     @default(ASKED)
+  document_type             DocumentTypes       @relation(...)
+  document_type_uid         String              @db.VarChar(255)
+  folder                    OfficeFolders       @relation(...)
+  folder_uid                String              @db.VarChar(255)
+  depositor                 Customers?          @relation(...)
+  depositor_uid             String?             @db.VarChar(255)
+  third_party_depositor     FolderThirdParties? @relation(...)
+  third_party_depositor_uid String?             @db.VarChar(255)
+  shared_to_office          Offices?            @relation(...)
+  shared_to_office_uid      String?             @db.VarChar(255)
+  // Soft delete
+  deleted_at                DateTime?
+  deleted_by_uid            String?             @db.VarChar(255)
+  // Relations
+  files                     Files[]
+  document_history          DocumentHistory[]
+  reminders                 DocumentsReminder[]
+  document_anchor           DocumentAnchors?
+}
+```
+
+**Statuts** :
+
+- `ASKED` : Document demandé
+- `DEPOSITED` : Document déposé
+- `VALIDATED` : Document validé
+- `REFUSED` : Document refusé
+
+#### Files (Fichiers)
+
+```prisma
+model Files {
+  uid                String    @id @unique @default(uuid())
+  document           Documents @relation(...)
+  document_uid       String    @db.VarChar(255)
+  file_path          String    @unique @db.VarChar(255)
+  file_name          String    @db.VarChar(255)
+  original_file_name String?   @db.VarChar(510) // Nom du fichier original (avant normalisation)
+  display_name       String?   @db.VarChar(510) // Nom final généré par le backend
+  mimetype           String    @db.VarChar(255)
+  hash               String    @db.VarChar(255) // Hash filigrané (ancré)
+  original_hash      String?   @db.VarChar(255) // Hash original (avant filigrane)
+  size               Int
+  archived_at        DateTime?
+  key                String?   @db.VarChar(255)
+  watermarked_s3_key String?   @db.VarChar(1000)
+  watermarked_at     DateTime?
+}
+```
+
+**Caractéristiques** :
+
+- **`original_file_name`** : Nom du fichier original (avant normalisation) - stocké lors de la création pour traçabilité
+- **`display_name`** : Nom final généré par le backend selon les conventions de nommage (préfixe dépositaire `N`/`C`/`T`/`NI`, segments `FirstName.LastName`, suffixe `.aplc` sans index).
+- **`file_name`** : Nom normalisé utilisé pour le stockage (IPFS, S3)
+- Hash SHA-256 du fichier filigrané (ancré)
+- Hash SHA-256 du fichier original (stocké pour vérification)
+- Filigrane automatique avant chiffrement
+- Stockage IPFS (Pinata) via S3
+
+#### DocumentAnchors (Ancres de documents)
+
+```prisma
+model DocumentAnchors {
+  uid String @id @unique @default(uuid())
+
+  document     Documents @relation(...)
+  document_uid String    @unique @db.VarChar(255)
+
+  file_hash String @db.VarChar(255) // Hash filigrané ancré
+
+  blockchain    EBlockchainName @default(BITCOIN_SIGNET)
+  anchor_nb_try Int             @default(0)
+
+  anchored_at     DateTime?
+  anchored_by_uid String?   @db.VarChar(255)
+  tx_id           String?   @db.VarChar(255)
+  tx_link         String?   @db.VarChar(255)
+  tx_hash         String?   @db.VarChar(255)
+  anchor_job_id   String?   @db.VarChar(255)
+  block_height    Int?
+  block_time      DateTime?
+  confirmations   Int?
+  proof_data      Json? // Inclut original_hash
+}
+```
+
+**Caractéristiques** :
+
+- Ancrage Bitcoin Signet
+- Preuve complète dans `proof_data` (inclut `original_hash`)
+- Lien explorateur blockchain dans `tx_link`
+
+#### SystemConfiguration (Configuration système)
+
+```prisma
+model SystemConfiguration {
+  uid String @id @unique @default(uuid())
+
+  key         String          @unique @db.VarChar(255)
+  value       String?         @db.Text
+  description String?         @db.Text
+  category    EConfigCategory
+
+  value_type   EConfigValueType @default(STRING)
+  is_sensitive Boolean          @default(false)
+  is_required  Boolean          @default(false)
+  default_value String?         @db.Text
+
+  created_at DateTime @default(now())
+  updated_at DateTime @updatedAt
+  created_by String?  @db.VarChar(255)
+  updated_by String?  @db.VarChar(255)
+  change_history Json?
+}
+```
+
+**Catégories** :
+
+- `FRONTEND` : Paramètres Next.js
+- `BACKEND` : Paramètres serveur
+- `INTEGRATION_IDNOT` : ID.NOT (OpenID, API Annuaire)
+- `INTEGRATION_BITCOIN` : Bitcoin Signet
+- `INTEGRATION_STRIPE` : Stripe (abonnements)
+- `INTEGRATION_MAILCHIMP` : Mailchimp (emails)
+- `INTEGRATION_PINATA` : IPFS/Pinata
+- `INTEGRATION_DOCAPOST` : Docapost (OCR)
+- `INTEGRATION_OVH` : OVH (SMS)
+- `SECURITY` : Secrets, tokens
+- `PERFORMANCE` : Limites, cache
+- `FEATURE_FLAGS` : Activation fonctionnalités
+- `SYSTEM` : Logs, monitoring
+
+### Enums
+
+#### Statuts
+
+```prisma
+enum EFolderStatus {
+  LIVE      // En cours
+  ARCHIVED  // Archivé
+  DELETED   // Supprimé (soft delete)
+}
+
+enum EDocumentStatus {
+  ASKED     // Demandé
+  DEPOSITED // Déposé
+  VALIDATED // Validé
+  REFUSED   // Refusé
+}
+
+enum ECustomerStatus {
+  VALIDATED // Validé
+  PENDING   // En attente
+  ERRONED   // Erroné
+}
+
+enum EOfficeStatus {
+  ACTIVATED   // Activé
+  DESACTIVATED // Désactivé
+}
+
+enum ESubscriptionStatus {
+  ACTIVE   // Actif
+  INACTIVE // Inactif
+}
+
+enum ESubscriptionType {
+  STANDARD  // Standard
+  UNLIMITED // Illimité
+}
+```
+
+#### Blockchain
+
+```prisma
+enum EBlockchainName {
+  TEZOS
+  BITCOIN_SIGNET
+}
+```
+
+#### Partage
+
+```prisma
+enum EShareRole {
+  OWNER         // Propriétaire
+  CONTRIBUTOR   // Contributeur
+  GUEST_NOTARY  // Notaire invité
+  VIEWER        // Lecteur
+}
+
+enum EShareStatus {
+  ACTIVE   // Actif
+  REVOKED  // Révoqué
+  EXPIRED  // Expiré
+}
+```
+
+#### Tiers
+
+```prisma
+enum EThirdPartyRole {
+  COURTIER
+  AGENT_IMMOBILIER
+  TUTELLE
+  SYNDIC
+  EXPERT
+  AUTRE
+}
+
+enum EAuthMethod {
+  EMAIL_CODE
+  SMS_CODE
+}
+```
+
+---
+
+## Gestion des migrations
+
+### Structure des migrations
+
+**Répertoire** : `lecoffre-back-main/prisma/migrations/`
+
+**Format** : `YYYYMMDDHHMMSS_nom_migration/`
+
+**Exemples** :
+
+- `20251020150254_add_system_configuration/`
+- `20251029160000_add_watermark_and_proof_columns/`
+- `20251201140000_add_original_hash_to_files/`
+
+### Commandes Prisma
+
+#### Générer le client Prisma
+
+```bash
+cd lecoffre-back-main
+npx prisma generate
+```
+
+#### Créer une migration
+
+```bash
+# Développement (crée et applique)
+npx prisma migrate dev --name nom_migration
+
+# Production (crée uniquement)
+npx prisma migrate dev --create-only --name nom_migration
+```
+
+#### Appliquer les migrations
+
+```bash
+# Production (via npm script)
+npm run migrate
+
+# Directement
+npx prisma migrate deploy --schema=src/common/databases/schema.prisma
+```
+
+#### Ouvrir Prisma Studio
+
+```bash
+npx prisma studio
+```
+
+#### Reset la base de données (⚠️ danger)
+
+```bash
+npx prisma migrate reset
+```
+
+### Gestion du schéma
+
+**Fichier** : `lecoffre-back-main/src/common/databases/schema.prisma`
+
+**Configuration** : `lecoffre-back-main/package.json`
+
+```json
+{
+  "prisma": {
+    "schema": "src/common/databases/schema.prisma"
+  }
+}
+```
+
+### Lien symbolique migrations
+
+Le script de déploiement crée automatiquement un lien symbolique pour que Prisma trouve les migrations :
+
+```bash
+# Création automatique lors du déploiement
+src/common/databases/migrations → prisma/migrations
+```
+
+**Vérification** :
+```bash
+ls -la lecoffre-back-main/src/common/databases/
+```
+
+### Détection migrations baselinées
+
+Le script de déploiement détecte automatiquement les migrations marquées comme appliquées sans être exécutées et les réinitialise si nécessaire.
+
+**Détection** :
+
+- Vérifie si `_prisma_migrations` existe avec des entrées
+- Vérifie si `system_configuration` existe (créée par une migration)
+- Si migrations marquées mais `system_configuration` absent → réinitialisation automatique
+
+---
+
+## Configuration système dynamique
+
+### Vue d'ensemble
+
+Tous les paramètres système sont stockés dans la table `system_configuration` au lieu de fichiers `.env`. Cela permet :
+
+- ✅ Modification en temps réel via interface web
+- ✅ Historique complet des modifications
+- ✅ Masquage automatique des valeurs sensibles
+- ✅ Catégorisation par type d'intégration
+- ✅ Validation des valeurs requises
+
+### Import depuis fichiers
+
+**Script** : `npm run config:import-env`
+
+**Fichiers** : `.secrets/<env>/env-full-<env>-for-bdd-injection.txt`
+
+**Exécution** :
+```bash
+cd /home/debian/sites/<env>-lecoffreio.4nkweb.com
+set -a && source .secrets/<env>/.env.<env> && set +a
+# Note: scripts_v2 utilise systemd. Sur le serveur, dans le répertoire backend :
+cd lecoffre-back-main && npm run config:import-env -- --env <env>
+```
+
+**Ce que fait le script** :
+
+- Lit `.secrets/<env>/env-full-<env>-for-bdd-injection.txt`
+- Exclut les variables `DATABASE_*`
+- Crée ou met à jour chaque variable dans la BDD
+- Catégorise automatiquement selon le mapping
+- Conserve un historique des modifications
+
+### Interface web
+
+**URL** : `/super-admin/system-config`
+
+**Accès** : Super-admin uniquement
+
+**Fonctionnalités** :
+
+- Vue d'ensemble de toutes les configurations
+- Filtrage par catégorie
+- Affichage/masquage valeurs sensibles
+- Édition avec historique
+- Validation des valeurs requises
+
+### API REST
+
+- `GET /api/v1/super-admin/system-config` : Liste toutes les configurations
+- `GET /api/v1/super-admin/system-config/category/:category` : Filtre par catégorie
+- `GET /api/v1/super-admin/system-config/:key` : Récupère une configuration
+- `PUT /api/v1/super-admin/system-config/:uid` : Met à jour une configuration
+- `POST /api/v1/super-admin/system-config` : Crée une configuration
+- `DELETE /api/v1/super-admin/system-config/:uid` : Supprime une configuration
+- `GET /api/v1/super-admin/system-config/validate` : Valide les configurations requises
+
+### Variables sensibles
+
+Automatiquement identifiées par :
+
+- `is_sensitive: true` dans le mapping
+- Clés contenant : `SECRET`, `KEY`, `PASSWORD`, `TOKEN`
+
+**Exemples** :
+
+- `ACCESS_TOKEN_SECRET`
+- `IDNOT_CLIENT_SECRET`
+- `RIB_ENCRYPTION_MASTER_KEY`
+- `STRIPE_SECRET_KEY`
+
+### Exclusions
+
+**Variables JAMAIS stockées en BDD** :
+
+- `DATABASE_URL`
+- `DATABASE_*`
+- `POSTGRES_*`
+
+Ces variables restent exclusivement dans les fichiers `.env`.
+
+**Documentation complète** : Voir [README.md](./README.md#consolidation-operationnelle-ex-operationsmd) et [API.md](./API.md#configuration-systeme).
+
+---
+
+## Soft Delete (Suppression logique)
+
+### Principe
+
+Au lieu de supprimer physiquement (`DELETE FROM`), on marque l'enregistrement comme supprimé avec `deleted_at` et `deleted_by_uid`.
+
+### Tables concernées
+
+- **OfficeFolders** : `deleted_at`, `deleted_by_uid`
+- **Documents** : `deleted_at`, `deleted_by_uid`
+- **Customers** : `deleted_at`, `deleted_by_uid`
+
+### Statut DELETED
+
+Pour les dossiers, le statut passe à `DELETED` :
+
+```prisma
+enum EFolderStatus {
+  LIVE      // En cours
+  ARCHIVED  // Archivé
+  DELETED   // Supprimé (soft delete)
+}
+```
+
+### Filtrage par défaut
+
+Les repositories filtrent automatiquement les enregistrements supprimés :
+
+```typescript
+// Par défaut, exclure les supprimés
+query.where = {
+  ...query.where,
+  deleted_at: null,
+};
+```
+
+### Méthodes standardisées
+
+```typescript
+// Soft delete
+async softDelete(uid: string, deletedByUid: string): Promise<Entity> {
+  return this.repository.update(uid, {
+    deleted_at: new Date(),
+    deleted_by_uid: deletedByUid,
+    status: EFolderStatus.DELETED, // Pour les dossiers
+  });
+}
+
+// Restauration
+async restore(uid: string): Promise<Entity> {
+  return this.repository.update(uid, {
+    deleted_at: null,
+    deleted_by_uid: null,
+    status: EFolderStatus.LIVE, // Pour les dossiers
+  });
+}
+```
+
+### Endpoints API
+
+- `DELETE /api/v1/notary/folders/:uid` → `softDelete()`
+- `POST /api/v1/notary/folders/:uid/restore` → `restore()`
+- `GET /api/v1/notary/folders/deleted` → Liste corbeille
+
+### Avantages
+
+1. **Traçabilité** : On sait qui a supprimé et quand
+2. **Récupération** : Possibilité de restaurer facilement
+3. **Audit** : Historique complet des suppressions
+4. **Conformité RGPD** : Les données peuvent être anonymisées plus tard
+5. **Sécurité** : Évite les suppressions accidentelles irréversibles
+
+**Documentation complète** : Voir [README.md](./README.md#consolidation-operationnelle-ex-operationsmd) et cette section.
+
+---
+
+## Reset et import de base de données
+
+### Vue d'ensemble
+
+LeCoffre.io dispose d'un système pour recréer et importer une base de données depuis un dump SQL.
+
+**⚠️ ATTENTION** : Cette opération est **DESTRUCTIVE** et supprime toutes les données existantes.
+
+### Script standalone
+
+**Fichier** : `deploy/scripts/reset-and-import-database.sh`
+
+**Usage** :
+```bash
+./deploy/scripts/reset-and-import-database.sh <ENV> [SQL_FILE]
+```
+
+**Arguments** :
+
+- `ENV` : Environnement cible (test | pprod | prod)
+- `SQL_FILE` : (Optionnel) Chemin vers le dump SQL. Si non fourni, utilise `.secrets/<ENV>/bdd.<ENV>`
+
+**Exemples** :
+```bash
+# Utiliser le fichier par défaut (deploy/bdd.test)
+./deploy/scripts/reset-and-import-database.sh test
+
+# Spécifier un dump SQL
+./deploy/scripts/reset-and-import-database.sh test deploy/backups/bdd-test_20251103_120000.sql
+
+# Importer un dump depuis un autre environnement
+./deploy/scripts/reset-and-import-database.sh test /path/to/production-dump.sql
+```
+
+**Ce que fait le script** :
+
+1. ✅ Crée un **backup de sécurité** de la base actuelle
+2. ✅ Supprime la base de données
+3. ✅ Recrée la base de données vide
+4. ✅ Importe les données depuis le dump SQL
+5. ✅ Génère le client Prisma
+6. ✅ Applique les migrations Prisma (via `npm run migrate`)
+7. ✅ Synchronise le schéma (`prisma db push`) sans reseed
+
+### Via script de déploiement
+
+**Option** : `--resetDatabase [SQL_FILE]`
+
+**Usage** :
+```bash
+# Reset avec le fichier par défaut (.secrets/test/bdd.test)
+./deploy/scripts/build-and-deploy.sh test --resetDatabase
+
+# Reset avec un dump spécifique
+./deploy/scripts/build-and-deploy.sh test --resetDatabase deploy/backups/bdd-test_20251103_120000.sql
+
+# Combiner avec d'autres options
+./deploy/scripts/build-and-deploy.sh test --deploy --resetDatabase --setSettings
+```
+
+### Étapes post-import indispensables
+
+Après **chaque** reset/import, exécuter immédiatement :
+
+#### 1. Réinjecter la configuration dynamique
+
+```bash
+cd /home/debian/sites/<env>-lecoffreio.4nkweb.com
+set -a && source .secrets/<env>/.env.<env> && set +a
+# Note: scripts_v2 utilise systemd. Sur le serveur, dans le répertoire backend :
+cd lecoffre-back-main && npm run config:import-env -- --env <env>
+```
+
+#### 2. Re-seeder la matrice des permissions
+
+```bash
+# Sur le serveur, avec accès PostgreSQL (psql) :
+psql -h ... -U ... -d ... -f ... \
+  psql -U "$DATABASE_USERNAME" -d "$DATABASE_NAME" \
+  -f /repo/lecoffre-back-main/prisma/migrations/20251107_role_permissions_matrix/migration.sql
+```
+
+**Vérification** : `SELECT COUNT(*) FROM role_permissions_matrix;` → 143 lignes attendues
+
+#### 3. Contrôles rapides
+
+- `SELECT COUNT(*) FROM system_configuration;` → ~109 entrées
+- `/api/v1/public/health` doit répondre `200`
+- Connexion Id.Not : badge `Visiteur` affiché si pas d'abonnement
+
+### Gestion des backups
+
+**Emplacement des fichiers SQL** :
+```text
+deploy/
+├── bdd.test                           # ⭐ Dump SQL par défaut pour test
+├── bdd.pprod                          # ⭐ Dump SQL par défaut pour pprod
+├── bdd.prod                           # ⭐ Dump SQL par défaut pour prod
+└── backups/
+    ├── bdd-test_20251103_120000.sql       # Backup automatique lors du déploiement
+    ├── safety-backup-test_20251103_150000.sql  # Backup de sécurité avant reset
+    └── ...
+```
+
+**Backups automatiques** :
+
+- **Déploiement** (`--deploy`) : Crée `bdd-<ENV>_<timestamp>.sql`
+- **Reset** (`--resetDatabase`) : Crée `safety-backup-<ENV>_<timestamp>.sql`
+
+**Documentation complète** : Voir [DATABASE_RESET_GUIDE.md](DATABASE_RESET_GUIDE.md)
+
+---
+
+## Commandes et outils
+
+### Commandes Prisma
+
+```bash
+# Générer le client Prisma
+npx prisma generate
+
+# Créer une migration
+npx prisma migrate dev --name nom_migration
+
+# Appliquer les migrations
+npx prisma migrate deploy --schema=src/common/databases/schema.prisma
+
+# Ouvrir Prisma Studio (interface graphique)
+npx prisma studio
+
+# Reset la base de données (⚠️ danger)
+npx prisma migrate reset
+```
+
+### Scripts npm backend
+
+```bash
+cd lecoffre-back-main
+
+# Migrations
+npm run migrate
+
+# Configuration
+npm run config:import-env
+
+# Ancrage
+npm run anchorage
+npm run anchorage:reanchor
+npm run anchorage:complete
+npm run anchorage:reanchor-all
+
+# Utilitaires
+npm run promote:superadmin
+npm run activate:subscriptions
+npm run token:get
+```
+
+### Connexion PostgreSQL
+
+```bash
+# Connexion directe
+psql -h <IP_POSTGRESQL> -p <PORT_POSTGRESQL> -U <DATABASE_USERNAME> -d <DATABASE_NAME>
+
+# Sur le serveur (accès PostgreSQL)
+psql -U <DATABASE_USERNAME> -d <DATABASE_NAME>
+```
+
+### Vérifications
+
+```bash
+# Compter les enregistrements
+psql -h <IP_POSTGRESQL> -p <PORT_POSTGRESQL> -U <DATABASE_USERNAME> -d <DATABASE_NAME> \
+  -c "SELECT 'offices' as table, COUNT(*) FROM offices UNION SELECT 'users', COUNT(*) FROM users;"
+
+# Vérifier les configurations
+psql ... -c "SELECT COUNT(*) FROM system_configuration;"
+psql ... -c "SELECT category, COUNT(*) FROM system_configuration GROUP BY category;"
+
+# Vérifier les permissions
+psql ... -c "SELECT COUNT(*) FROM role_permissions_matrix;"
+```
+
+---
+
+## Liens et références
+
+### Documentation principale
+
+- **[DATABASE_RESET_GUIDE.md](DATABASE_RESET_GUIDE.md)** : Guide complet de réinitialisation et import
+- **[README.md](./README.md#consolidation-operationnelle-ex-operationsmd)** : consolidation opérationnelle
+- **[DEPLOYMENT.md](./DEPLOYMENT.md)** : procédures d'exploitation
+- **[ARCHITECTURE.md](ARCHITECTURE.md)** : Architecture rôles et utilisateurs
+- **[DEPLOYMENT.md](DEPLOYMENT.md)** : Documentation du déploiement
+
+### Schéma et migrations
+
+- **Schéma Prisma** : `lecoffre-back-main/src/common/databases/schema.prisma`
+- **Migrations** : `lecoffre-back-main/prisma/migrations/`
+- **Package.json** : `lecoffre-back-main/package.json` (configuration Prisma)
+
+### Scripts de déploiement
+
+- **Reset database** : `deploy/scripts/reset-and-import-database.sh`
+- **Déploiement** : `deploy/scripts/build-and-deploy.sh`
+- **Migrations** : `deploy/scripts/build-and-deploy-local-migrateResolveDatabase.sh`
+
+### Documentation externe
+
+- **Prisma** : <https://www.prisma.io/docs/>
+- **PostgreSQL** : <https://www.postgresql.org/docs/>
+
+### Fichiers de configuration
+
+- **Variables d'environnement** : `.secrets/<env>/.env.<env>`
+- **Injection BDD** : `.secrets/<env>/env-full-<env>-for-bdd-injection.txt`
+- **Dumps SQL** : `.secrets/<env>/bdd.<env>`
+
+---
+
+## Relations complètes entre les tables
+
+### Graphe des relations principales
+
+#### 1. Entités de base (Contacts, Addresses)
+
+```text
+Addresses (1) ──< (0..1) Contacts
+Addresses (1) ──< (0..1) Offices
+Contacts (1) ──< (0..1) Users
+Contacts (1) ──< (0..1) Customers
+```
+
+**Relations** :
+
+- `Addresses` → `Contacts` : One-to-One (optionnel)
+- `Addresses` → `Offices` : One-to-One (optionnel)
+- `Contacts` → `Users` : One-to-One (obligatoire)
+- `Contacts` → `Customers` : One-to-One (obligatoire)
+
+#### 2. Utilisateurs et offices
+
+```text
+Offices (1) ──< (N) Users (office_membership)
+Offices (1) ──< (N) Users (office_affiliations via UserOfficeAffiliations)
+Offices (1) ──< (N) OfficeRoles
+Offices (1) ──< (N) OfficeFolders
+Offices (1) ──< (N) Customers
+Offices (1) ──< (N) Subscriptions
+Offices (1) ──< (N) DocumentTypes
+Offices (1) ──< (N) DeedTypes
+Offices (1) ──< (N) FolderSharing (shared_from_office)
+Offices (1) ──< (N) FolderSharing (shared_to_office)
+Offices (1) ──< (N) Documents (shared_to_office)
+```
+
+**Relations** :
+
+- `Users.office_membership` → `Offices` : Many-to-One (ancien système, conservé)
+- `UserOfficeAffiliations` : Many-to-Many entre `Users` et `Offices` (nouveau système multi-office)
+- `Users.office_role` → `OfficeRoles` : Many-to-One (optionnel)
+- `Users.role` → `Roles` : Many-to-One (obligatoire)
+
+#### 3. Dossiers et documents
+
+```text
+OfficeFolders (1) ──< (N) Documents
+OfficeFolders (1) ──< (N) DocumentsNotary
+OfficeFolders (1) ──< (N) Notes
+OfficeFolders (1) ──< (N) FolderSharing
+OfficeFolders (1) ──< (N) FolderThirdParties
+OfficeFolders (1) ──< (N) AggregatedCertificates
+OfficeFolders (1) ──< (1) OfficeFolderAnchors
+OfficeFolders (1) ──< (1) Deeds
+OfficeFolders (N) ──> (1) Offices
+OfficeFolders (N) ──> (1) Users (created_by)
+OfficeFolders (N) ──> (M) Users (stakeholders - Many-to-Many)
+OfficeFolders (N) ──> (M) Customers (Many-to-Many)
+```
+
+**Relations** :
+
+- `OfficeFolders.deed` → `Deeds` : Many-to-One (obligatoire)
+- `OfficeFolders.folder_anchor` → `OfficeFolderAnchors` : One-to-One (optionnel)
+- `OfficeFolders.stakeholders` → `Users` : Many-to-Many
+- `OfficeFolders.customers` → `Customers` : Many-to-Many
+
+#### 4. Documents et fichiers
+
+```text
+Documents (1) ──< (N) Files
+Documents (1) ──< (N) DocumentHistory
+Documents (1) ──< (N) DocumentsReminder
+Documents (1) ──< (1) DocumentAnchors
+Documents (N) ──> (1) OfficeFolders
+Documents (N) ──> (1) DocumentTypes
+Documents (N) ──> (1) Customers (depositor)
+Documents (N) ──> (1) FolderThirdParties (third_party_depositor)
+Documents (N) ──> (1) Offices (shared_to_office)
+```
+
+**Relations** :
+
+- `Documents.depositor` → `Customers` : Many-to-One (optionnel, pour clients)
+- `Documents.third_party_depositor` → `FolderThirdParties` : Many-to-One (optionnel, pour tiers)
+- `Documents.shared_to_office` → `Offices` : Many-to-One (optionnel, pour confrères invités)
+- `Documents.document_anchor` → `DocumentAnchors` : One-to-One (optionnel)
+
+#### 5. Ancrage blockchain
+
+```text
+DocumentAnchors (1) ──> (1) Documents
+OfficeFolderAnchors (1) ──> (1) OfficeFolders
+DocumentNotaryAnchors (1) ──> (1) DocumentsNotary
+AggregatedCertificates (N) ──> (1) OfficeFolders
+```
+
+**Relations** :
+
+- Tous les ancres sont en relation One-to-One avec leur entité source
+- `AggregatedCertificates` : Certificats agrégés par dossier (plusieurs certificats possibles)
+
+#### 6. Rôles et permissions
+
+```text
+Roles (1) ──< (N) Users
+Roles (N) ──> (M) Rules (Many-to-Many via relation implicite)
+OfficeRoles (1) ──< (N) Users
+OfficeRoles (N) ──> (M) Rules (Many-to-Many via relation implicite)
+Rules (N) ──> (M) RulesGroups (Many-to-Many)
+RolePermissionsMatrix : Table indépendante (matrice 143 lignes)
+```
+
+**Relations** :
+
+- `Roles` → `Rules` : Many-to-Many (via `RolesHasRules`)
+- `OfficeRoles` → `Rules` : Many-to-Many (via `OfficeRolesHasRules`)
+- `Rules` → `RulesGroups` : Many-to-Many (via `RulesGroupsHasRules`)
+
+#### 7. Abonnements et sièges
+
+```text
+Subscriptions (1) ──< (N) Seats
+Subscriptions (N) ──> (1) Offices
+Subscriptions (N) ──> (1) SubscriptionPlans (optionnel)
+Seats (N) ──> (1) Users
+```
+
+**Relations** :
+
+- `Subscriptions.office` → `Offices` : Many-to-One (obligatoire)
+- `Subscriptions.subscription_plan` → `SubscriptionPlans` : Many-to-One (optionnel)
+- `Seats.subscription` → `Subscriptions` : Many-to-One (obligatoire)
+- `Seats.user` → `Users` : Many-to-One (obligatoire)
+
+#### 8. Partage et tiers
+
+```text
+FolderSharing (N) ──> (1) OfficeFolders
+FolderSharing (N) ──> (1) Offices (shared_from_office)
+FolderSharing (N) ──> (1) Offices (shared_to_office)
+FolderSharing (N) ──> (1) Users (shared_by_user)
+FolderThirdParties (N) ──> (1) OfficeFolders
+FolderThirdParties (N) ──> (1) Users (added_by)
+FolderThirdParties (1) ──< (N) Documents (third_party_depositor)
+FolderThirdParties (1) ──< (N) ThirdPartyTotpCodes
+```
+
+**Relations** :
+
+- `FolderSharing` : Partage de dossiers entre offices (contrainte unique sur `[folder_uid, shared_to_office_uid]`). Notaire invité identifié par `invited_notary_idnot` (IdNot) et `invited_notary_email` (email de préférence pour les envois ; seul champ email, par défaut depuis IdNot à l'invitation). Accès aux dossiers invités = croisement sur IdNot ; envois = email en base uniquement. Voir `docs/ARCHITECTURE.md` § Partage Inter-Études.
+- `FolderThirdParties` : Tiers associés aux dossiers (courtiers, agents, etc.)
+
+#### 9. Types de documents et actes
+
+```text
+DeedTypes (1) ──< (N) Deeds
+DeedTypes (N) ──> (M) DocumentTypes (Many-to-Many via DeedTypeHasDocumentTypes)
+Deeds (1) ──< (1) OfficeFolders
+Deeds (N) ──> (M) DocumentTypes (Many-to-Many via DeedHasDocumentTypes)
+DocumentTypes (N) ──> (1) Offices
+DocumentTypes (1) ──< (N) Documents
+DocumentTypes (N) ──> (M) DeedTypes (Many-to-Many)
+DocumentTypes (N) ──> (M) Deeds (Many-to-Many)
+DocumentTypes (1) ──< (N) DocumentRemindersConfig
+```
+
+**Relations** :
+
+- `DeedTypes` → `DocumentTypes` : Many-to-Many (via `DeedTypeHasDocumentTypes`)
+- `Deeds` → `DocumentTypes` : Many-to-Many (via `DeedHasDocumentTypes`)
+- Contrainte unique sur `DocumentTypes` : `[name, office_uid]`
+- Contrainte unique sur `DeedTypes` : `[name, office_uid]`
+
+#### 10. Synchronisation externe
+
+```text
+SyncOffices : Table indépendante (snapshot offices IdNot)
+SyncPersons : Table indépendante (snapshot personnes IdNot)
+SyncAffiliations : Table indépendante (snapshot affiliations IdNot)
+SyncStripeSubscriptions : Table indépendante (snapshot abonnements Stripe)
+SyncDailyMetrics : Table indépendante (métriques quotidiennes)
+AnnuOffices : Table indépendante (API Annuaire - offices)
+AnnuPersons : Table indépendante (API Annuaire - personnes)
+AnnuAffiliations : Table indépendante (API Annuaire - affiliations)
+```
+
+**Relations** :
+
+- Tables de synchronisation indépendantes (pas de foreign keys)
+- Index sur `idnot`, `office_uid`, `user_uid` pour recherche rapide
+
+#### 11. Configuration et textes
+
+```text
+SystemConfiguration : Table indépendante (109 configs)
+SiteTexts : Table indépendante (textes éditoriaux)
+```
+
+**Relations** :
+
+- Tables indépendantes
+- Contrainte unique sur `SystemConfiguration.key`
+- Contrainte unique sur `SiteTexts` : `[text_key, locale, version]`
+
+#### 12. Sécurité et audit
+
+```text
+RevokedTokens : Table indépendante (tokens JWT révoqués)
+AuditLogs : Table indépendante (logs d'audit)
+Whitelist : Table indépendante (emails autorisés)
+UserWhitelist : Table indépendante (IdNot autorisés)
+```
+
+**Relations** :
+
+- Tables indépendantes
+- Index sur `RevokedTokens.jti` et `RevokedTokens.user_uid`
+
+---
+
+## Patterns de requêtes Prisma
+
+### Structure de base des repositories
+
+Tous les repositories étendent `BaseRepository` qui définit :
+
+- `maxFetchRows = 100` : Limite maximale de résultats
+- `defaultFetchRows = 50` : Limite par défaut
+
+### Patterns de requêtes courants
+
+#### 1. FindMany avec pagination
+
+```typescript
+// Pattern standard dans tous les repositories
+public async findMany(query: Prisma.ModelFindManyArgs) {
+  query.take = Math.min(query.take || this.defaultFetchRows, this.maxFetchRows);
+  return this.model.findMany(query);
+}
+```
+
+**Exemples** :
+```typescript
+// Documents avec pagination
+await documentsRepository.findMany({
+  where: { folder_uid: folderUid },
+  include: { document_type: true, files: true },
+  orderBy: { created_at: 'desc' },
+  take: 20,
+  skip: 0
+});
+
+// Users avec relations
+await usersRepository.findMany({
+  where: { office_uid: officeUid },
+  include: {
+    contact: true,
+    role: true,
+    office_membership: { include: { address: true } }
+  }
+});
+```
+
+#### 2. FindUnique avec include optionnel
+
+```typescript
+// Pattern avec include optionnel
+public async findOneByUid(uid: string, include?: Prisma.ModelInclude) {
+  return this.model.findUnique({
+    where: { uid },
+    include
+  });
+}
+```
+
+**Exemples** :
+```typescript
+// Document simple
+const doc = await documentsRepository.findOneByUid(documentUid);
+
+// Document avec relations complètes
+const doc = await documentsRepository.findOneByUid(documentUid, {
+  folder: { include: { office: true } },
+  document_type: true,
+  files: true,
+  depositor: { include: { contact: true } }
+});
+```
+
+#### 3. FindFirst pour recherche conditionnelle
+
+```typescript
+// Pattern pour recherche avec conditions
+public async findOne(query: Prisma.ModelFindFirstArgs) {
+  return this.model.findFirst(query);
+}
+```
+
+**Exemples** :
+```typescript
+// Customer par email
+const customer = await customersRepository.findOne({
+  where: {
+    contact: { email: userEmail }
+  },
+  include: { contact: { include: { address: true } } }
+});
+
+// Folder par numéro et office
+const folder = await officeFoldersRepository.findFirst({
+  where: {
+    folder_number: folderNumber,
+    office_uid: officeUid
+  }
+});
+```
+
+#### 4. Create avec relations imbriquées
+
+```typescript
+// Pattern pour création avec relations
+public async create(data: Entity): Promise<Model> {
+  return this.model.create({
+    data: {
+      // Champs simples
+      field1: data.field1,
+      // Relations avec connect
+      relation1: {
+        connect: { uid: data.relation1.uid }
+      },
+      // Relations avec connectOrCreate
+      relation2: {
+        connectOrCreate: {
+          where: { uniqueField: data.relation2.uniqueField },
+          create: { /* ... */ }
+        }
+      },
+      // Relations Many-to-Many avec connect
+      manyRelation: {
+        connect: data.manyRelation.map(uid => ({ uid }))
+      }
+    },
+    include: {
+      relation1: true,
+      relation2: true
+    }
+  });
+}
+```
+
+**Exemples** :
+```typescript
+// User avec contact et office
+await usersRepository.create({
+  idNot: user.idNot,
+  contact: {
+    create: {
+      first_name: contact.first_name,
+      last_name: contact.last_name,
+      email: contact.email,
+      address: {
+        create: {
+          address: address.address,
+          city: address.city,
+          zip_code: address.zip_code
+        }
+      }
+    }
+  },
+  office_membership: {
+    connectOrCreate: {
+      where: { idNot: office.idNot },
+      create: { /* ... */ }
+    }
+  }
+});
+
+// Folder avec stakeholders
+await officeFoldersRepository.create(folder, createdByUid, {
+  stakeholders: {
+    connect: stakeholderUids.map(uid => ({ uid }))
+  }
+});
+```
+
+#### 5. Update avec relations
+
+```typescript
+// Pattern pour mise à jour avec relations
+public async update(uid: string, data: Partial<Entity>): Promise<Model> {
+  const updateData: Prisma.ModelUpdateInput = {};
+
+  // Champs simples
+  if (data.field1) updateData.field1 = data.field1;
+
+  // Relations Many-to-Many avec set (remplace tout)
+  if (data.manyRelation) {
+    updateData.manyRelation = {
+      set: data.manyRelation.map(uid => ({ uid }))
+    };
+  }
+
+  // Relations avec connect/disconnect
+  if (data.relation) {
+    updateData.relation = {
+      connect: { uid: data.relation.uid }
+    };
+  }
+
+  return this.model.update({
+    where: { uid },
+    data: updateData,
+    include: { /* relations à inclure */ }
+  });
+}
+```
+
+**Exemples** :
+```typescript
+// Update folder avec stakeholders
+await officeFoldersRepository.update(folderUid, {
+  name: newName,
+  stakeholders: {
+    set: newStakeholderUids.map(uid => ({ uid }))
+  }
+});
+
+// Update document status avec historique
+await documentsRepository.update(documentUid, {
+  document_status: EDocumentStatus.VALIDATED,
+  document_history: {
+    create: {
+      document_status: EDocumentStatus.VALIDATED
+    }
+  }
+});
+```
+
+#### 6. Soft Delete
+
+```typescript
+// Pattern pour soft delete
+public async softDelete(uid: string, deletedByUid: string): Promise<Model> {
+  return this.model.update({
+    where: { uid },
+    data: {
+      deleted_at: new Date(),
+      deleted_by_uid: deletedByUid,
+      status: EStatus.DELETED // Pour les entités avec statut
+    }
+  });
+}
+```
+
+**Exemples** :
+```typescript
+// Soft delete folder
+await officeFoldersRepository.updateDirect(folderUid, {
+  deleted_at: new Date(),
+  deleted_by_uid: userUid,
+  status: EFolderStatus.DELETED
+});
+
+// Soft delete document
+await documentsRepository.update(documentUid, {
+  deleted_at: new Date(),
+  deleted_by_uid: userUid
+});
+```
+
+#### 7. Transactions
+
+```typescript
+// Pattern pour opérations atomiques
+public async delete(uid: string): Promise<Model> {
+  return this.instanceDb.$transaction(async (transaction) => {
+    // Supprimer les relations d'abord
+    await transaction.relatedModel.deleteMany({
+      where: { foreign_key: uid }
+    });
+
+    // Puis supprimer l'entité principale
+    return transaction.model.delete({
+      where: { uid }
+    });
+  });
+}
+```
+
+**Exemples** :
+```typescript
+// Delete document avec historique
+await documentsRepository.delete(documentUid);
+// Supprime automatiquement document_history puis documents
+
+// CreateMany avec historique
+await documentsRepository.createMany(documents);
+// Crée documents puis document_history pour chacun
+```
+
+#### 8. Count pour vérifications
+
+```typescript
+// Pattern pour vérifier existence
+public async existsWithUniqueField(field: string, officeUid: string, excludeUid?: string): Promise<boolean> {
+  const count = await this.model.count({
+    where: {
+      unique_field: field,
+      office_uid: officeUid,
+      ...(excludeUid ? { NOT: { uid: excludeUid } } : {})
+    }
+  });
+  return count > 0;
+}
+```
+
+**Exemples** :
+```typescript
+// Vérifier numéro de dossier unique
+const exists = await officeFoldersRepository.existsWithFolderNumber(
+  folderNumber,
+  officeUid,
+  excludeUid
+);
+
+// Compter documents par statut
+const count = await documentsRepository.count({
+  where: {
+    folder_uid: folderUid,
+    document_status: EDocumentStatus.ASKED
+  }
+});
+```
+
+#### 9. Requêtes SQL brutes ($queryRaw)
+
+```typescript
+// Pattern pour requêtes SQL complexes
+const results = await prisma.$queryRaw<ResultType[]>`
+  SELECT
+    u.idnot,
+    u.uid as user_uid,
+    c.email,
+    c.first_name,
+    c.last_name,
+    o.name as office_name
+  FROM users u
+  INNER JOIN contacts c ON u.contact_uid = c.uid
+  LEFT JOIN offices o ON u.office_uid = o.uid
+  WHERE c.email IS NOT NULL
+    AND LOWER(c.email) LIKE LOWER(${searchTerm})
+  ORDER BY c.last_name ASC
+  LIMIT 50
+`;
+```
+
+**Exemples** :
+
+- Recherche de notaires : `IdNotDirectoryService.searchNotariesInSync()` (site base + appel direct API annuaire `/persons?q=` ou v2 + folder_sharing). Voir docs/API.md § Recherche confrères.
+- Requêtes de synchronisation complexes
+- Agrégations et statistiques
+
+#### 10. Upsert pour création/mise à jour atomique
+
+```typescript
+// Pattern pour upsert (utilise contrainte unique)
+public async upsert(
+  uniqueField1: string,
+  uniqueField2: string,
+  createData: Prisma.ModelCreateInput,
+  updateData: Prisma.ModelUpdateInput
+): Promise<Model> {
+  return this.model.upsert({
+    where: {
+      unique_composite: {
+        field1: uniqueField1,
+        field2: uniqueField2
+      }
+    },
+    create: createData,
+    update: updateData
+  });
+}
+```
+
+**Exemples** :
+```typescript
+// Upsert folder sharing
+await folderSharingRepository.upsert(
+  folderUid,
+  sharedToOfficeUid,
+  createData,
+  updateData
+);
+// Utilise @@unique([folder_uid, shared_to_office_uid])
+```
+
+### Filtrage par défaut (Soft Delete)
+
+Les repositories filtrent automatiquement les entités supprimées :
+
+```typescript
+// Pattern standard
+query.where = {
+  ...query.where,
+  deleted_at: null  // Exclure les supprimés
+};
+```
+
+**Exceptions** :
+
+- Endpoints dédiés pour la corbeille : `GET /api/v1/notary/folders/deleted`
+- Super-admin peut voir tout
+
+### Patterns d'inclusion de relations
+
+#### Inclusion simple
+```typescript
+include: {
+  relation: true
+}
+```
+
+#### Inclusion imbriquée
+```typescript
+include: {
+  relation1: {
+    include: {
+      nestedRelation: true
+    }
+  }
+}
+```
+
+#### Inclusion conditionnelle
+```typescript
+include: {
+  relation: {
+    where: {
+      status: 'ACTIVE'
+    }
+  }
+}
+```
+
+**Exemples courants** :
+```typescript
+// User complet
+include: {
+  contact: { include: { address: true } },
+  role: { include: { rules: true } },
+  office_role: { include: { rules: true } },
+  office_membership: { include: { address: true } },
+  office_affiliations: {
+    where: { status: 'ACTIVE', is_primary: true },
+    include: { office: true }
+  }
+}
+
+// Folder complet
+include: {
+  office: true,
+  deed: { include: { deed_type: true } },
+  created_by: { include: { contact: true } },
+  stakeholders: { include: { contact: true } },
+  customers: { include: { contact: { include: { address: true } } } },
+  documents: {
+    include: {
+      document_type: true,
+      files: true
+    }
+  },
+  folder_anchor: true
+}
+```
+
+---
+
+## Contraintes et index
+
+### Contraintes uniques
+
+#### Contraintes sur champs simples
+
+- `Users.idNot` : Unique (identifiant IdNot)
+- `Users.contact_uid` : Unique (un contact = un user)
+- `Offices.idNot` : Unique
+- `Offices.crpcen` : Unique (code CRPCEN)
+- `Whitelist.email` : Unique
+- `UserWhitelist.idNot` : Unique
+- `SubscriptionPlans.stripe_price_id` : Unique
+- `RevokedTokens.jti` : Unique (JWT ID)
+- `SystemConfiguration.key` : Unique
+- `AnnuOffices.idnot` : Unique
+- `AnnuPersons.idnot` : Unique
+
+#### Contraintes composites
+
+- `OfficeFolders` : `@@unique([folder_number, office_uid])` - Numéro unique par office
+- `DocumentTypes` : `@@unique([name, office_uid])` - Nom unique par office
+- `DeedTypes` : `@@unique([name, office_uid])` - Nom unique par office
+- `FolderSharing` : `@@unique([folder_uid, shared_to_office_uid])` - Partage unique par office
+- `DocumentRemindersConfig` : `@@unique([document_type_uid, office_uid])`
+- `UserOfficeAffiliations` : `@@unique([user_uid, office_uid])` - Affiliation unique
+- `Appointments` : `@@unique([user_uid, choice, status])`
+- `AnnuAffiliations` : `@@unique([person_idnot, office_idnot])`
+- `SiteTexts` : `@@unique([text_key, locale, version])`
+- `RolePermissionsMatrix` : `@@unique([resource, scoped_entity_normalized, action, role])`
+
+### Index
+
+#### Index simples
+
+- `RevokedTokens.jti` : Index pour recherche rapide de tokens
+- `RevokedTokens.user_uid` : Index pour recherche par utilisateur
+- `SyncOffices.office_uid` : Index pour synchronisation
+- `SyncOffices.idnot` : Index pour recherche IdNot
+- `SyncPersons.user_uid` : Index pour synchronisation
+- `SyncPersons.idnot` : Index pour recherche IdNot
+- `SyncAffiliations.person_idnot` : Index pour synchronisation
+- `SyncAffiliations.office_idnot` : Index pour synchronisation
+- `SyncStripeSubscriptions.office_uid` : Index pour synchronisation
+- `SyncStripeSubscriptions.stripe_subscription_id` : Index pour recherche Stripe
+- `SyncDailyMetrics.date` : Index pour requêtes temporelles
+- `FolderThirdParties.folder_uid` : Index pour recherche par dossier
+- `FolderThirdParties.email` : Index pour recherche par email
+- `ThirdPartyTotpCodes.third_party_uid` : Index pour recherche par tiers
+- `SystemConfiguration.category` : Index pour filtrage par catégorie
+- `SystemConfiguration.key` : Index pour recherche rapide
+- `SiteTexts.scope` : Index pour filtrage par scope
+- `SiteTexts.text_key` : Index pour recherche par clé
+- `AnnuOffices.idnot` : Index pour recherche IdNot
+- `AnnuOffices.crpcen` : Index pour recherche CRPCEN
+- `AnnuOffices.synced_at` : Index pour requêtes temporelles
+- `AnnuPersons.idnot` : Index pour recherche IdNot
+- `AnnuPersons.email` : Index pour recherche par email
+- `AnnuPersons.synced_at` : Index pour requêtes temporelles
+- `AnnuAffiliations.person_idnot` : Index pour recherche
+- `AnnuAffiliations.office_idnot` : Index pour recherche
+- `AnnuAffiliations.synced_at` : Index pour requêtes temporelles
+
+### Foreign Keys et cascades
+
+Toutes les relations utilisent `onDelete: Cascade` sauf exceptions :
+
+- Relations optionnelles peuvent être `null` sans cascade
+- Relations Many-to-Many via tables de jointure implicites (Prisma gère automatiquement)
+
+**Exemples de cascades** :
+
+- `Users.contact` → `Contacts` : Cascade (supprimer user supprime contact)
+- `Users.office_membership` → `Offices` : Cascade (supprimer office supprime users)
+- `Documents.folder` → `OfficeFolders` : Cascade (supprimer folder supprime documents)
+- `Files.document` → `Documents` : Cascade (supprimer document supprime files)
+
+---
+
+**Dernière mise à jour** : 30 octobre 2025
+**Maintenu par** : Équipe LeCoffre.io
+**Version** : 2.0.1
diff --git a/projects/lecoffreio/docs/DEPLOYMENT.md b/projects/lecoffreio/docs/DEPLOYMENT.md
new file mode 100644
index 0000000..5a1c37c
--- /dev/null
+++ b/projects/lecoffreio/docs/DEPLOYMENT.md
@@ -0,0 +1,2361 @@
+# Déploiement LeCoffre.io - Guide Complet
+
+**Dernière mise à jour** : 2026-03-10
+**Version** : 2.0.1
+
+Ce document consolide toute la documentation relative au déploiement (scripts, variables, logging, Nginx, SSL).
+
+---
+
+## 📋 Table des Matières
+
+1. [Vue d'ensemble](#vue-densemble)
+2. [Prérequis](#prérequis)
+3. [Configuration](#configuration)
+4. [Variables d'environnement](#variables-denvironnement)
+5. [Déploiement principal](#déploiement-principal)
+6. [Cartographie des checks de déploiement (source unique)](#cartographie-des-checks-de-déploiement-source-unique)
+7. [Logs de déploiement](#logs-de-déploiement)
+8. [Scripts et commandes](#scripts-et-commandes)
+9. [Maintenance et troubleshooting](#maintenance-et-troubleshooting)
+10. [API d'ancrage Bitcoin séparée](#api-dancrage-bitcoin-séparée)
+11. [Sécurité](#sécurité)
+12. [Monitoring](#monitoring)
+13. [Disaster Recovery](#disaster-recovery)
+
+---
+
+## Vue d'ensemble
+
+LeCoffre.io utilise un système de déploiement automatisé via SSH orchestré depuis le **proxy** (point d’entrée unique).
+
+Le mode de déploiement recommandé est **`deploy/scripts_v2/`** (services systemd sur les serveurs d’environnements) :
+
+- Synchronisation Git
+- Installation des dépendances système sur l’hôte (PostgreSQL, ClamAV, Chromium, LibreOffice, Java…)
+- Build backend/frontend
+- Services `systemd` (backend/cron/frontend/router)
+- Migrations Prisma, injection de configuration (`system_configuration`), scripts métier (Stripe, ré-ancrage…)
+
+**Environnements disponibles** :
+
+- `test` : Environnement de test
+- `pprod` : Pré-production
+- `prod` : Production
+- `demo` : Démonstration
+
+---
+
+## Prérequis
+
+### Sur la machine locale (déploiement)
+
+- **Git** : Pour le versioning et la synchronisation
+- **Node.js 25+** : Pour la compilation TypeScript
+- **npm** : Gestionnaire de paquets
+- **rsync** : Synchronisation des fichiers
+- **SSH avec clé configurée** : Accès au serveur distant
+
+### Sur la machine distante (cible)
+
+- **Accès SSH avec clé**
+- **PostgreSQL** (service système, port 5432)
+- **ClamAV** (service système, port 3310)
+- **Chromium** (binaire `/usr/bin/chromium`)
+- **LibreOffice + Java**
+- **Node.js 25+ et npm** (pour build et exécution). Mise à jour si inférieur : `bash deploy/scripts_v2/run-update-node-25-on-servers.sh` (test, pprod, prod).
+
+### Configuration SSH
+
+```bash
+# Configurer la clé SSH
+ssh-copy-id -i ~/.ssh/id_ed25519 ncantu@4nk.myftp.biz
+
+# Tester la connexion
+ssh ncantu@4nk.myftp.biz "echo OK"
+```
+
+---
+
+## Configuration
+
+### 1. Fichier `.env.<env>`
+
+Créer `.secrets/test/.env.test`, `.secrets/pprod/.env.pprod`, ou `.secrets/prod/.env.prod` avec :
+
+```bash
+# Database
+# Variables construites dynamiquement depuis ENV :
+#   DATABASE_HOST=127.0.0.1
+#   DATABASE_PORT=5432
+#   DATABASE_USERNAME=lecoffre-user-${ENV}
+#   DATABASE_NAME=bdd-${ENV}
+# Seule variable requise :
+DATABASE_PASSWORD=***
+
+# Deployment (scripts_v2)
+# Les déploiements sont exécutés sur le proxy (4nk.myftp.biz / 192.168.1.100).
+# Les environnements sont sur le réseau privé :
+# - test  : 192.168.1.101 → test.lecoffreio.4nkweb.com
+# - pprod : 192.168.1.102 → pprod.lecoffreio.4nkweb.com
+# - prod  : 192.168.1.103 → prod.lecoffreio.4nkweb.com
+DEPLOY_SSH_USER=ncantu
+DEPLOY_SSH_KEY=~/.ssh/id_ed25519
+
+# Frontend (sera injecté en base lors du premier déploiement)
+NEXT_PUBLIC_SPLASH_MESSAGE=Environnement de test
+
+# Grafana (monitoring)
+GRAFANA_ADMIN_USER=grafana-admin
+GRAFANA_ADMIN_PASSWORD=change_me
+```
+
+### 1bis. Git (scripts_v2)
+
+`deploy/scripts_v2/deploy.sh` effectue automatiquement, **en local**, avant toute synchronisation côté cible :
+
+- `npm run lint:fix` sur `lecoffre-ressources-dev`, `lecoffre-back-main`, `lecoffre-front-main` (non bloquant) (le déploiement échoue si lint:fix retourne une erreur non corrigeable)
+- `git add -A`
+- `git commit` (message au format imposé par le dépôt)
+- `git push origin $DEPLOY_GIT_BRANCH`
+
+Le script est **strict** :
+
+- il exige `DEPLOY_GIT_BRANCH` (dans `.secrets/<env>/.env.<env>` ou exporté)
+- la branche locale courante doit être exactement `$DEPLOY_GIT_BRANCH`
+- la cible est synchronisée **uniquement** sur `origin/$DEPLOY_GIT_BRANCH` (pas d’autre ref)
+
+### 1ter. Migrations requises (scripts_v2)
+
+En mode `scripts_v2`, certaines actions **exigent** que les migrations Prisma soient exécutées dans la même commande (mode strict) :
+
+- `--resetDatabase` ⇒ **doit** être accompagné de `--migrateResolveDatabase`
+- `--resetDatabaseFromSchemaExport` ⇒ **doit** être accompagné de `--migrateResolveDatabase` (voir ci-dessous)
+- `--setSettings`, `--seedSiteTexts`, `--importStripe`, `--reanchorAll`, `--promoteSuperAdmins`, `--activateSubscriptions` ⇒ **doivent** être accompagnés de `--migrateResolveDatabase`
+
+**Variables d'automatisation (stockées en BDD via `system_configuration`) :**
+
+- `SUPERADMIN_EMAILS` : Liste d'emails (séparés par des virgules) promus automatiquement en super-admin lors du déploiement avec `--promoteSuperAdmins`
+- `AUTO_ACTIVATE_SUBSCRIPTIONS_EMAILS` : Liste d'emails (séparés par des virgules) dont tous les abonnements seront activés/créés automatiquement lors du déploiement avec `--activateSubscriptions`
+
+#### Baseline DB v2 depuis un export de schéma (sans rejouer l'historique des migrations)
+
+Quand les dumps disponibles sont **uniquement en v1** (et/ou que l'historique des migrations pose problème), `scripts_v2` permet de reconstruire une base **v2 vide** directement depuis un export SQL **schema-only** :
+
+- Le script applique un export SQL **schema-only** sur une base vide :
+  - `deploy/schema-v2.sql` si présent (prioritaire)
+  - sinon `deploy/scripts_v2/schema-v2-initial.sql` (export de référence v2 fourni dans le repo)
+- Puis exécute `prisma migrate resolve --applied` sur **toutes** les migrations présentes dans le repo (sans les exécuter) pour que Prisma considère la base comme "à jour"
+- Ensuite, `--migrateResolveDatabase` peut s'exécuter (il ne doit appliquer que des migrations futures, au-delà de la baseline)
+
+**Fichier requis :**
+
+- `deploy/schema-v2.sql` (optionnel) : export du schéma cible (schema-only) compatible `psql -f`
+  - il peut contenir des directives `psql` (ex: `\restrict` / `\unrestrict`) : `scripts_v2` les filtre lors de l'application
+  - si besoin, utiliser `deploy/schema-v2.sql.example` comme guide
+
+**Commande type :**
+
+```bash
+bash deploy/scripts_v2/deploy.sh test \
+  --resetDatabaseFromSchemaExport \
+  --migrateResolveDatabase \
+  --deploy \
+  --skipCheckLint
+```
+
+#### Import v1 → v2 : Premier import (full) vs Imports incrémentaux (merge)
+
+**Premier import (full, destructif) :**
+
+Le flag `--importV1Data` effectue un import complet depuis un dump v1 :
+
+- Applique la compatibilité layer v1→v2 (enums + colonnes manquantes)
+- **TRUNCATE** toutes les tables (sauf `_prisma_migrations` et `system_configuration`)
+- Restaure les **TABLE DATA** du dump v1 via `pg_restore --data-only`
+
+```bash
+bash deploy/scripts_v2/deploy.sh test \
+  --resetDatabaseFromSchemaExport \
+  --migrateResolveDatabase \
+  --importV1Data \
+  --deploy \
+  --skipCheckLint
+```
+
+**Imports incrémentaux (merge, non-destructif) :**
+
+Le flag `--importV1DataMerge` effectue un merge des données v1 dans la v2 existante :
+
+- Applique la compatibilité layer v1→v2 (enums + colonnes manquantes)
+- Restaure le dump v1 dans une **DB temporaire**
+- Effectue des **INSERT ... ON CONFLICT DO UPDATE** par table (upsert)
+- **Préserve** les données v2 existantes
+- Intègre les nouvelles données v1
+
+```bash
+# Script wrapper (recommandé)
+bash deploy/scripts_v2/merge-v1-data-into-v2.sh test
+
+# Ou directement
+bash deploy/scripts_v2/deploy.sh test \
+  --importV1DataMerge \
+  --skipCheckLint
+```
+
+**Workflow recommandé :**
+
+1. **Premier import** : `install-or-reset-env-from-schema-export.sh <env>` (baseline + import full)
+2. **Imports suivants** : `merge-v1-data-into-v2.sh <env>` (merge incrémental)
+
+**Prérequis pour les imports :**
+
+- Le dump v1 doit être présent localement : `.secrets/<env>/bdd.<env>`
+- Format attendu : custom-format `pg_dump` (PGDMP)
+
+**Détails techniques (merge) :**
+
+- Les tables sans PK/UK sont **ignorées** (risque de doublons)
+- Les colonnes communes entre v1 et v2 sont synchronisées
+- Les colonnes v1 absentes en v2 sont ignorées (après compat layer)
+- Les colonnes v2 absentes en v1 sont préservées (non modifiées)
+
+### 2. Base de données
+
+La base PostgreSQL doit être créée et accessible. Le script :
+
+- ✅ Applique les migrations Prisma automatiquement
+- ✅ Synchronise les données (IdNot, Annuaire, Stripe)
+- ✅ Valide les identifiants PostgreSQL avant déploiement
+- ❌ Ne crée PAS la base (à faire manuellement)
+
+**Validation des identifiants PostgreSQL** :
+Le script valide automatiquement les identifiants (`DATABASE_USERNAME` / `DATABASE_PASSWORD`) avant de démarrer le déploiement. En cas d'échec de connexion, le script affiche un message d'erreur explicite et s'arrête.
+
+**Gestion des migrations Prisma** :
+
+- Le schéma Prisma est dans `lecoffre-back-main/prisma/schema.prisma`
+- Les migrations sont dans `prisma/migrations/`
+- Le script crée automatiquement un lien symbolique `src/common/databases/migrations` → `prisma/migrations` pour que Prisma trouve les migrations
+- Les migrations sont appliquées via `npm run migrate` (qui utilise `prisma migrate deploy`)
+- Détection automatique des migrations baselinées (marquées comme appliquées sans être exécutées) et réinitialisation si nécessaire
+
+### 3. Configuration ClamAV (system_configuration via import-env-to-db)
+
+Les variables suivantes ne vont pas dans `.env.<env>` mais dans `.secrets/<env>/env-full-<env>-for-bdd-injection.txt` (puis importées via `config:import-env`) :
+
+```bash
+CLAMAV_HOST=127.0.0.1
+CLAMAV_PORT=3310
+CLAMAV_SCAN_ENABLED=true
+CLAMAV_CONNECTION_TIMEOUT_MS=8000
+CLAMAV_READ_TIMEOUT_MS=150000
+CLAMAV_MAX_FILE_SIZE_MB=120
+```
+
+> Sans ces clés, le backend refuse désormais les uploads (aucun fallback).
+
+---
+
+## Variables d'environnement
+
+### Vue d'ensemble
+
+Le script `build-and-deploy.sh` lit ses configurations de déploiement depuis les fichiers `.env.<env>` au lieu d'avoir des valeurs hardcodées.
+
+### Variables requises
+
+Chaque fichier `.env.test`, `.env.pprod`, `.env.prod` doit contenir :
+
+#### Variables de déploiement SSH
+
+```bash
+# Host SSH de la machine cible
+DEPLOY_SSH_HOST=<IP_SERVEUR>
+
+# Utilisateur SSH (optionnel, défaut: debian)
+DEPLOY_SSH_USER=debian
+
+# Clé SSH (optionnel, défaut: ~/.ssh/id_rsa)
+DEPLOY_SSH_KEY=~/.ssh/id_rsa
+
+# Répertoire de déploiement sur la machine distante
+DEPLOY_REMOTE_PATH=/home/debian/sites/test-lecoffreio.4nkweb.com
+
+# Domaine pour Nginx et SSL
+DEPLOY_DOMAIN=test-lecoffreio.4nkweb.com
+```
+
+### Configuration par environnement
+
+#### Test
+
+```bash
+DEPLOY_SSH_HOST=<IP_SERVEUR_TEST>
+DEPLOY_SSH_USER=debian
+DEPLOY_REMOTE_PATH=/home/debian/sites/test-lecoffreio.4nkweb.com
+DEPLOY_DOMAIN=test-lecoffreio.4nkweb.com
+```
+
+#### Pré-production
+
+```bash
+DEPLOY_SSH_HOST=<IP_SERVEUR_PPROD>
+DEPLOY_SSH_USER=debian
+DEPLOY_REMOTE_PATH=/home/debian/sites/pprod-lecoffreio.4nkweb.com
+DEPLOY_DOMAIN=pprod-lecoffreio.4nkweb.com
+```
+
+#### Production
+
+```bash
+DEPLOY_SSH_HOST=<IP_SERVEUR_PROD>
+DEPLOY_SSH_USER=debian
+DEPLOY_REMOTE_PATH=/home/debian/sites/prod-lecoffreio.4nkweb.com
+DEPLOY_DOMAIN=prod-lecoffreio.4nkweb.com
+```
+
+### Fonctionnement
+
+1. Le script `build-and-deploy.sh` vérifie que `.env.<env>` existe
+2. Il source le fichier avec `source .env.<env>`
+3. Il mappe les variables `DEPLOY_*` vers les variables internes du script
+4. Il valide que toutes les variables requises sont définies
+5. Il bloque si `DEPLOY_SSH_HOST=TBD` (environnement non configuré)
+
+### Avantages
+
+- ✅ **Pas de valeurs hardcodées** dans le script
+- ✅ **Configuration centralisée** dans les fichiers `.env`
+- ✅ **Cohérence** avec le reste de l'architecture (config en BDD)
+- ✅ **Facilité de maintenance** : modifier `.env.*` au lieu du script
+- ✅ **Sécurité** : les `.env.*` sont en `.gitignore`
+- ✅ **Validation** : le script vérifie que toutes les variables sont présentes
+
+---
+
+## Déploiement principal
+
+### Commande simple
+
+```bash
+./deploy/scripts/build-and-deploy.sh test    # Environnement test
+./deploy/scripts/build-and-deploy.sh pprod   # Environnement pprod
+./deploy/scripts/build-and-deploy.sh prod    # Environnement prod
+```
+
+### Options de déploiement
+
+```bash
+# Déploiement complet avec toutes les étapes
+./deploy/scripts/build-and-deploy.sh test --deploy --cert --resetDatabase --setSettings --syncIdNot --syncDirectory
+
+# Opérations post-déploiement (conteneurs déjà actifs)
+./deploy/scripts/build-and-deploy.sh pprod --syncIdNot --syncDirectory --reanchorAll
+
+# Import Stripe et réancrage
+./deploy/scripts/build-and-deploy.sh test --importStripe --reanchorAll
+
+# Promotion super-admins depuis liste config
+./deploy/scripts/build-and-deploy.sh pprod --promoteSuperAdmins
+
+# Activation abonnements depuis liste config
+./deploy/scripts/build-and-deploy.sh pprod --activateSubscriptions
+```
+
+**Flags disponibles :**
+
+- `--deploy` : Build et déploiement complet (redémarre les services systemd)
+- `--resetDatabase` : ⚠️ DESTRUCTIF : Recréer la base et importer depuis `.secrets/<ENV>/bdd.<ENV>`
+  ➜ **Important** : relancer ensuite `npm run config:import-env -- --env <env>` sur le serveur cible puis reseeder `role_permissions_matrix` (cf. [DATABASE_RESET_GUIDE](DATABASE_RESET_GUIDE.md))
+
+- `--migrateResolveDatabase` : Appliquer les migrations Prisma manquantes (prisma migrate deploy)
+  - ✅ **Vérifications systématisées** : Vérifie et ajoute automatiquement les colonnes manquantes (`proof_data`, `confirmations`, `anchor_job_id`) dans les tables d'ancrage (`document_anchors`, `document_notary_anchors`)
+  - ✅ **8 points de vérification** : Les colonnes sont vérifiées à 8 endroits différents pour garantir leur présence
+  - ✅ **Gestion des erreurs** : Retry automatique et messages d'erreur explicites si l'ajout de colonnes échoue
+  - 📖 Voir [ANCRAGE_COMPLETE.md](./ANCRAGE_COMPLETE.md) pour les corrections détaillées sur les colonnes d'ancrage
+- `--setSettings` : Injection configurations depuis fichier env-full-*
+- `--seedSiteTexts` : Exécuter le seed des textes du site (`node dist/scripts/seed-site-texts.js`)
+- `--syncIdNot` : Synchronisation utilisateurs IdNot OAuth
+- `--syncDirectory` : Synchronisation API Annuaire
+- `--cert` : ⚠️ DESTRUCTIF : Ecrase les certificats existant, activer la gestion des certificats Let's Encrypt (sinon aucune action certificat)
+- `--reanchorAll` : ⚠️ DESTRUCTIF : Supprimer toutes les ancres et réancré tous les documents (tous statuts), documents notaires et RIB
+  - ✅ **Vérification préalable** : Vérifie l'existence des tables avant d'ajouter les colonnes manquantes
+  - ✅ **Vérification finale** : Bloque le réancrage si les colonnes indispensables (`proof_data`, `confirmations`) manquent
+  - ✅ **Ordre garanti** : S'exécute toujours après `--migrateResolveDatabase` pour garantir la présence des colonnes
+  - 📖 Voir [ANCRAGE_COMPLETE.md](./ANCRAGE_COMPLETE.md) pour les corrections détaillées sur les colonnes d'ancrage
+- `--promoteSuperAdmins` : Promotion automatique des super-admins configurés en BDD (clé SUPERADMIN_EMAILS)
+- `--activateSubscriptions` : Activation automatique des abonnements pour les emails configurés en BDD (clé AUTO_ACTIVATE_SUBSCRIPTIONS_EMAILS)
+- `--importStripe` : Synchronisation plans et abonnements Stripe
+- `--getToken` : Génère un couple access/refresh token pour le premier super-admin disponible (promotion automatique de `laurence@notaires.fr` si aucun super-admin actif)
+- `--checkLint` : Exécuter les lints/TypeScript/compilation checks avant le build (activé par défaut)
+- `--skipCheckLint` : Désactiver les vérifications pré-build (lint, TypeScript, compilation)
+- `--skipBuildChecks` : Désactiver uniquement les build checks (lint et typecheck toujours exécutés)
+- `--skipDiskCleanup` : Ignorer le nettoyage de l'espace disque (peut accélérer le déploiement)
+- `--skipBackupsRecovery` : Ignorer la récupération des sauvegardes sur la machine locale
+- `--aggressiveCleanup` : ⚠️ Nettoyage agressif de l'espace disque
+- `--showLogs` : Afficher les logs des services (backend/frontend) après le déploiement
+- `--showLogsService <name>` : Service spécifique pour --showLogs (backend, frontend, ou all, défaut: backend)
+- `--showLogsTail <lines>` : Nombre de lignes de logs à afficher (défaut: 200)
+- `--showLogsSince <duration>` : Filtrer les logs depuis (ex: 1h, 10m, 2024-12-02T10:00:00)
+
+
+#### Mise à jour des secrets *site texts* (pprod / prod)
+
+Les fichiers `.secrets/<env>/seed-site-texts-<env>.ts` et `.secrets/<env>/env-full-<env>-for-bdd-injection.txt` ne doivent pas être versionnés dans le dépôt applicatif cible. La source de vérité est le dépôt utilisé pour déclencher le déploiement.
+
+- **Seed** : copier le contenu du seed de test vers le seed de l’environnement cible, puis adapter uniquement les mentions d’environnement (ex. retirer `[ENVIRONNEMENT DE TEST]` en prod).
+- **Env-full** : aligner la ligne `SITE_TEXTS_KEYS_INDEX=...` avec celle de test (même liste et même ordre) pour garantir que les clés seedées sont bien indexées.
+
+Après mise à jour des secrets, un déploiement standard (`deploy/scripts_v2/deploy.sh`) synchronise les fichiers `.secrets/<env>/` vers la cible et exécute le seed si `--seedSiteTexts` est actif.
+
+**Exemples d'usage :**
+
+```bash
+# Déploiement complet environnement from scratch
+./deploy/scripts/build-and-deploy.sh test --deploy --cert --resetDatabase --setSettings --syncIdNot --syncDirectory --importStripe --reanchorAll
+
+# Synchronisation quotidienne sans interruption
+./deploy/scripts/build-and-deploy.sh pprod --syncIdNot --syncDirectory --importStripe
+
+# Réancrage tous dossiers existants (maintenance - DESTRUCTIF)
+./deploy/scripts/build-and-deploy.sh test --reanchorAll
+
+# Mise à jour code avec redéploiement
+./deploy/scripts/build-and-deploy.sh pprod --deploy
+
+# Génération d'un token super-admin sans redéployer
+./deploy/scripts/build-and-deploy.sh pprod --getToken
+
+# Déploiement avec affichage des logs backend
+./deploy/scripts/build-and-deploy.sh pprod --deploy --showLogs --showLogsService backend --showLogsTail 500 --showLogsSince 1h
+```
+
+> ℹ️ Pour les tests manuels, il est possible de récupérer un jeton en local via `npm run token:get -- --json`.
+
+### Processus complet
+
+Le script exécute automatiquement :
+
+#### Phase 1 : Build local
+
+1. ✅ Compilation TypeScript de `lecoffre-ressources-dev`
+2. ✅ Vérification du build (87 fichiers .js)
+
+#### Phase 2 : Synchronisation
+
+1. ✅ Test connexion SSH
+2. ✅ Création répertoire distant si nécessaire
+3. ✅ Rsync de tous les fichiers (excluant node_modules, .git, logs...)
+4. ✅ Transfert des fichiers `.env.<env>`
+
+#### Phase 3 : Build distant
+
+1. ✅ Backup base de données (pg_dump)
+2. ✅ Build backend/frontend
+3. ✅ Chargement variables `.env.<env>`
+
+#### Phase 4 : Certificats SSL
+
+1. ✅ Vérification si certificats existent
+2. ✅ Génération certificat auto-signé temporaire si absent
+3. ✅ Démarrage services (systemd)
+4. ✅ Obtention certificat Let's Encrypt réel
+5. ✅ Rechargement Nginx avec certificat
+
+#### Phase 5 : Déploiement
+
+1. ✅ Arrêt services existants (systemd)
+2. ✅ Démarrage services (systemd)
+3. ✅ Attente démarrage (10s)
+4. ✅ Vérification statut (systemctl)
+5. ✅ Cleanup builds obsolètes
+
+#### Phase 6 : Synchronisation données (si flags activés)
+
+1. ✅ `--setSettings` : Injection configurations depuis `env-full-<env>-for-bdd-injection.txt`
+   - Commande utilisée côté serveur : `npm run config:import-env -- --env <env>` (dans le répertoire backend)
+   - Doit être rejouée manuellement après `--resetDatabase`
+   - ✅ Depuis 2025-12-02, le transfert des fichiers sensibles sous Windows passe par un répertoire de staging pour `Compress-Archive`, ce qui garantit que les chemins relatifs (`deploy/...`) sont bien conservés lors de l'extraction distante.
+2. ✅ `--syncIdNot` : Synchronisation utilisateurs IdNot OAuth
+3. ✅ `--syncDirectory` : Synchronisation offices/personnes API Annuaire
+4. ✅ `--importStripe` : Synchronisation plans et abonnements Stripe
+5. ✅ `--reanchorAll` : ⚠️ DESTRUCTIF : Supprimer toutes les ancres et réancrer tous les documents et dossiers
+6. ✅ `--promoteSuperAdmins` : Promotion super-admins depuis liste emails
+7. ✅ `--getToken` : Génération d'un access/refresh token super-admin (trace `logs/token-superadmin-*.log`)
+8. ✅ Logs sauvegardés dans `logs/`
+
+#### Phase 7 : Scripts de fix (automatique)
+
+1. ✅ **Exécution automatique** : Tous les scripts `.sh` dans `deploy/fix/` sont exécutés automatiquement après le déploiement
+2. ✅ **Ordre alphabétique** : Les scripts sont exécutés dans l'ordre alphabétique
+3. ✅ **Déplacement automatique** : Après exécution réussie, chaque script est déplacé dans `deploy/fixDone/`
+4. ✅ **Arrêt en cas d'erreur** : Si un script échoue, le processus s'arrête et le script reste dans `deploy/fix/`
+5. ✅ **Contexte complet** : Chaque script reçoit `ENV` et `DOMAIN` comme paramètres et a accès à toutes les variables d'environnement nécessaires
+
+#### Phase 8 : Vérifications finales
+
+1. ✅ Statut services systemd
+2. ✅ Health check backend (`/api/v1/public/health`)
+3. ✅ Logs accessibles
+
+### Première fois (from scratch)
+
+#### Option 1 : Script automatique
+
+```bash
+# Déployer de A à Z (inclut SSL, migrations, sync)
+./deploy/scripts/build-and-deploy.sh test
+```
+
+Le script détecte automatiquement que c'est un premier déploiement et :
+
+- Génère les certificats SSL
+- Applique toutes les migrations Prisma
+- Synchronise les données
+
+#### Option 2 : Script init (legacy)
+
+```bash
+# Alternative : script init manuel (moins maintenu)
+./deploy/scripts/init-environment.sh test admin@4nkweb.com
+```
+
+---
+
+## Cartographie des checks de déploiement (source unique)
+
+Cette section fait foi pour distinguer ce qui est exécuté automatiquement pendant un déploiement standard (`deploy/scripts_v2/deploy.sh`) et ce qui reste manuel.
+
+### Snippet de renvoi standard (gabarit interne)
+
+Position attendue dans chaque document concerné : en tête du fichier, juste après le titre et les métadonnées éventuelles.
+
+Règle unique : aucun bloc local de checks de déploiement dans les autres documents. Conserver uniquement le snippet de renvoi, avec éventuellement une phrase de contexte métier non-check.
+
+Depuis un document situé dans `docs/` :
+
+```md
+**Référence unique (checks de déploiement)** : [`docs/DEPLOYMENT.md#cartographie-des-checks-de-déploiement-source-unique`](./DEPLOYMENT.md#cartographie-des-checks-de-déploiement-source-unique)
+```
+
+Depuis un document situé hors `docs/` :
+
+```md
+**Référence unique (checks de déploiement)** : [`docs/DEPLOYMENT.md#cartographie-des-checks-de-déploiement-source-unique`](../docs/DEPLOYMENT.md#cartographie-des-checks-de-déploiement-source-unique)
+```
+
+### Checks automatiques (pipeline de déploiement)
+
+| Check | Déclenchement | Script source | Statut |
+|-------|---------------|---------------|--------|
+| Vérification API d'ancrage (`health` + test d'ancrage) | Systématique dans `deploy.sh` | `deploy/scripts_v2/deploy.sh` (`test_anchor_api_blocking`) | Automatique |
+| Migrations Prisma (`prisma generate` + `prisma migrate deploy`) | Systématique dans `deploy.sh` | `deploy/scripts_v2/remote/migrate-resolve-database.sh` | Automatique |
+| Build backend/frontend sur cible | Systématique en déploiement normal/import | `deploy/scripts_v2/remote/deploy-app.sh` | Automatique |
+| Vérification post-déploiement (health + systemd + logs récents) | Systématique après déploiement/import | `deploy/scripts_v2/_lib/git-flow.sh` (`verify_deployment_success`) | Automatique |
+| Lint/typecheck/build locaux | Option `--checkLint` | `deploy/scripts_v2/deploy.sh` | Optionnel |
+
+### Scripts manuels (hors pipeline automatique)
+
+| Script | Usage | Statut |
+|--------|-------|--------|
+| `deploy/scripts_v2/run-verify-db-connection.sh` | Vérification ciblée connectivité DB | Manuel |
+| `deploy/scripts_v2/run-verify-invited-received-documents.sh` | Vérification SQL ciblée documents invités | Manuel |
+| `deploy/scripts_v2/run-check-role-permissions-matrix.sh` | Vérification droits/rôles | Manuel |
+| `deploy/scripts_v2/run-check-logs-and-db-invite-notaire-587.sh` | Diagnostic ciblé logs + DB | Manuel |
+| `deploy/scripts_v2/run-check-user-offices-logs.sh` | Diagnostic ciblé logs `UserOffices` (offices vides / sync IdNot) | Manuel |
+| `deploy/scripts_v2/run-copy-connectdb-if-missing.sh` | Remédiation ciblée fichier connectDB | Manuel |
+| `deploy/scripts_v2/run-set-settings.sh` | Exécution manuelle set-settings | Manuel |
+
+### Scripts orphelins nettoyés
+
+- Supprimés car non appelés par le pipeline et non référencés comme étapes obligatoires :
+  - `lecoffre-back-main/test-audit.js`
+  - `lecoffre-back-main/test-audit.js.map`
+  - `lecoffre-back-main/scripts/test-guest-folders-query.ts`
+  - `lecoffre-back-main/scripts/test-guest-folders-complete.ts`
+
+---
+
+## Architecture (scripts_v2 - host-native)
+
+### Vue d'ensemble
+
+Dans l’infrastructure proxy `192.168.1.100`, le SSL et le routage sont gérés **uniquement sur le proxy**.
+Les serveurs d’environnements (`192.168.1.101/102/103`) exposent uniquement des **ports applicatifs HTTP**.
+
+Le déploiement est orchestré par `deploy/scripts_v2/deploy.sh`.
+
+En fin d'exécution, `deploy/scripts_v2/deploy.sh` affiche l'heure de fin au format `HH:MM` pour faciliter la lecture chronologique des logs de déploiement.
+
+### Structure des fichiers sur un serveur d’environnement
+
+```tree
+/srv/4NK/test.lecoffreio.4nkweb.com/
+├── deploy/                     # Scripts + fichiers de déploiement versionnés
+├── deploy/scripts_v2/           # Scripts v2 (host-native)
+├── lecoffre-back-main/          # Backend
+├── lecoffre-front-main/         # Frontend
+└── lecoffre-ressources-dev/     # Ressources partagées
+```
+
+### Services système (systemd)
+
+- `lecoffreio-backend@<domain>`
+- `lecoffreio-cron@<domain>`
+- `lecoffreio-frontend@<domain>`
+- `lecoffreio-router@<domain>` (port service, ex: 3009)
+
+---
+
+## Logs de déploiement
+
+### Script principal `build-and-deploy.sh`
+
+Le script principal **ne produit pas automatiquement** de logs. Il faut rediriger la sortie manuellement :
+
+```bash
+# Exemple recommandé
+./deploy/scripts/build-and-deploy.sh pprod --deploy > logs/build-and-deploy-pprod.log 2>&1
+```
+
+**Format recommandé** : `logs/build-and-deploy-<env>.log`
+
+**Avantages de la redirection manuelle** :
+
+- Contrôle total sur le nom du fichier
+- Peut inclure des informations supplémentaires (date, numéro de déploiement)
+- Permet de gérer plusieurs logs simultanés
+
+**Exemples d'utilisation** :
+
+```bash
+# Log simple
+./deploy/scripts/build-and-deploy.sh pprod --deploy > logs/build-and-deploy-pprod.log 2>&1
+
+# Log avec timestamp
+./deploy/scripts/build-and-deploy.sh pprod --deploy > logs/build-and-deploy-pprod-$(date +%Y%m%d_%H%M%S).log 2>&1
+
+# Log avec affichage en temps réel (tee)
+./deploy/scripts/build-and-deploy.sh pprod --deploy 2>&1 | tee logs/build-and-deploy-pprod.log
+```
+
+### Copie automatique vers serveur distant
+
+Le script `build-and-deploy.sh` copie automatiquement les logs de déploiement vers le serveur distant après l'exécution (succès ou échec) pour que Promtail puisse les collecter.
+
+**Fonctionnement** :
+
+- Vérifie si le fichier de log local existe
+- Crée le répertoire `logs/` sur le serveur distant s'il n'existe pas
+- Copie le log avec un nom horodaté (`build-and-deploy-<env>-YYYYMMDD-HHMMSS.log`)
+- Le nom correspond au pattern Promtail : `build-and-deploy-*.log`
+- La copie est non-bloquante (ne fait pas échouer le déploiement si elle échoue)
+
+Voir [README.md](./README.md#consolidation-operationnelle-ex-operationsmd) pour la consolidation et [ANCRAGE_COMPLETE.md](./ANCRAGE_COMPLETE.md) pour le dépannage ancrage.
+
+### Répertoire des logs
+
+#### Structure
+
+```text
+logs/
+├── build-and-deploy-pprod.log              # Log principal (manuel)
+├── build-and-deploy-pprod-20250102_143022.log  # Log horodaté (copié automatiquement)
+├── sync-idnot-20251124_143022.log          # Sync IdNot (automatique)
+├── sync-directory-20251124_143100.log       # Sync Directory (automatique)
+├── import-stripe-20251124_144000.log        # Import Stripe (automatique)
+├── reanchor-all-20251124_150000.log         # Réancrage complet (automatique)
+├── token-superadmin-20251124_151000.log     # Token super-admin (automatique)
+└── activate-subscriptions-20251124_152000.log  # Activation abonnements (automatique)
+```
+
+#### Création automatique
+
+Le répertoire `logs/` est créé automatiquement par :
+
+- `build-and-deploy.sh` (ligne 451)
+- `run_sync_idnot()` (ligne 853)
+- `run_sync_directory()` (ligne 887)
+
+### Gestion des logs volumineux
+
+#### Compression automatique
+
+Les logs de synchronisation sont automatiquement compressés si >5MB :
+
+- Réduction à 2000 dernières lignes
+- Compression en `.gz`
+- Affichage des 20 dernières lignes après compression
+
+#### Nettoyage
+
+Les logs ne sont **pas nettoyés automatiquement**. Il est recommandé de :
+
+- Archiver les anciens logs
+- Supprimer les logs >30 jours
+- Surveiller l'espace disque
+
+**Script de nettoyage recommandé** :
+
+```bash
+# Supprimer les logs >30 jours
+find logs/ -name "*.log" -mtime +30 -delete
+find logs/ -name "*.log.gz" -mtime +90 -delete
+```
+
+---
+
+## Scripts et commandes
+
+### Mise à jour Node.js 25 sur test, pprod, prod
+
+Si la version de Node sur les serveurs est inférieure à 25, exécuter (depuis la machine locale, les scripts font le SSH via le proxy) :
+
+```bash
+bash deploy/scripts_v2/run-update-node-25-on-servers.sh
+```
+
+Ce script copie et exécute `deploy/scripts_v2/remote/update-node-25.sh` sur chaque hôte (test, pprod, prod). Idempotent : ne modifie rien si Node >= 25. Utilise NodeSource `setup_25.x` avec repli sur `setup_current.x` si 25 n’est pas disponible.
+
+### Scripts de déploiement
+
+#### `deploy/scripts_v2/install-or-reset-env.sh` (scripts_v2)
+
+**Bootstrap / reset complet en 1 commande (DESTRUCTIF)** pour `test` et `pprod`.
+
+Ce wrapper exécute un cycle complet :
+
+- setup host (`--setupHost`)
+- reset DB depuis `.secrets/<env>/bdd.<env>` (`--resetDatabase`)
+- migrations Prisma (`--migrateResolveDatabase`)
+- build+restart (`--deploy`)
+- import settings en BDD (`--setSettings`)
+- scripts métier (`--seedSiteTexts`, `--importStripe`, `--reanchorAll`, `--promoteSuperAdmins`, `--activateSubscriptions`)
+
+```bash
+# Usage
+bash deploy/scripts_v2/install-or-reset-env.sh test
+```
+
+#### `deploy/scripts_v2/install-or-reset-env-from-schema-export.sh` (scripts_v2)
+
+**Bootstrap / reset complet en 1 commande (DESTRUCTIF)** pour `test` et `pprod`, basé sur une **baseline schema-only** (utile quand les dumps disponibles sont uniquement en v1).
+
+Ce script enchaîne :
+
+- `--resetDatabaseFromSchemaExport` (création DB v2 vide depuis export SQL schema-only)
+- `--importV1Data` (import des TABLE DATA v1 dans la DB v2)
+  - `scripts_v2` prépare automatiquement une **compat layer v1→v2** (types/colonnes manquants) en restaurant le schéma v1 dans une DB temporaire puis en appliquant le diff sur la DB v2
+  - `scripts_v2` n'importe pas `_prisma_migrations` (baseline Prisma gérée à part) ni `system_configuration` (géré via `--setSettings`)
+- `--migrateResolveDatabase` (baseline Prisma via `migrate resolve --applied` + migrations futures)
+- `--deploy` + scripts post-déploiement (`--setSettings`, `--seedSiteTexts`, `--importStripe`, `--reanchorAll`, `--promoteSuperAdmins`, `--activateSubscriptions`)
+
+```bash
+# Usage
+bash deploy/scripts_v2/install-or-reset-env-from-schema-export.sh test
+```
+
+⚠️ Pour `prod`, ce wrapper refuse d'exécuter (risque de reset DB). Utiliser `deploy/scripts_v2/deploy.sh` et valider les flags explicitement.
+
+#### `deploy/scripts_v2/merge-v1-data-into-v2.sh` (scripts_v2)
+
+**Merge incrémental v1 → v2 (NON-DESTRUCTIF)** pour `test`, `pprod` et `prod`.
+
+Ce script effectue un merge des données v1 dans la v2 existante, puis exécute les scripts post-déploiement :
+
+**Étapes du merge :**
+
+1. Applique la compatibilité layer v1→v2 (enums + colonnes manquantes)
+2. Restaure le dump v1 dans une DB temporaire
+3. Effectue des upserts (INSERT ... ON CONFLICT DO UPDATE) par table
+4. **Préserve** les données v2 existantes
+5. Intègre les nouvelles données v1
+
+**Scripts post-déploiement systématisés :**
+
+Après le merge, le script exécute automatiquement :
+
+- `--migrateResolveDatabase` : Applique les migrations Prisma (requis, ajouté automatiquement)
+- `--setSettings` : Import des configurations depuis `env-full-<env>-for-bdd-injection.txt`
+- `--seedSiteTexts` : Initialise les textes du site
+- `--importStripe` : Importe les abonnements Stripe
+- `--reanchorAll` : Réancrage complet des documents (DESTRUCTIF pour les ancres existantes)
+- `--promoteSuperAdmins` : Promotion des super-admins (via `SUPERADMIN_EMAILS` en DB)
+- `--activateSubscriptions` : Activation des abonnements (via `AUTO_ACTIVATE_SUBSCRIPTIONS_EMAILS` en DB)
+
+**Note :** Ces scripts sont systématisés pour garantir la cohérence des environnements après chaque merge v1→v2.
+
+```bash
+# Usage
+bash deploy/scripts_v2/merge-v1-data-into-v2.sh test
+```
+
+**Workflow recommandé :**
+
+1. **Premier import** : `install-or-reset-env-from-schema-export.sh <env>` (baseline + import full + scripts post-déploiement)
+2. **Imports suivants** : `merge-v1-data-into-v2.sh <env>` (merge incrémental + scripts post-déploiement)
+
+**Prérequis :**
+
+- Le dump v1 doit être présent localement : `.secrets/<env>/bdd.<env>`
+- Format attendu : custom-format `pg_dump` (PGDMP)
+
+**Détails techniques (merge) :**
+
+- Les tables sans PK/UK sont **ignorées** (risque de doublons)
+- Les colonnes communes entre v1 et v2 sont synchronisées
+- Les colonnes v1 absentes en v2 sont ignorées (après compat layer)
+- Les colonnes v2 absentes en v1 sont préservées (non modifiées)
+- Les lignes avec NULL dans des colonnes NOT NULL sont automatiquement filtrées
+
+#### `build-and-deploy.sh`
+
+**Script principal de déploiement complet**
+
+Déploie l'application de A à Z sur un environnement distant via SSH.
+
+```bash
+# Usage
+./deploy/scripts/build-and-deploy.sh <ENV> [options]
+
+# Exemples
+./deploy/scripts/build-and-deploy.sh test --deploy --cert --resetDatabase --setSettings
+./deploy/scripts/build-and-deploy.sh pprod --syncIdNot --syncDirectory
+./deploy/scripts/build-and-deploy.sh prod --deploy --importStripe --reanchorAll
+```
+
+#### `init-environment.sh` (legacy)
+
+**Initialisation d'un nouvel environnement**
+
+Alternative pour la première fois (moins maintenu que `build-and-deploy.sh`).
+
+```bash
+# Usage
+./deploy/scripts/init-environment.sh <ENV> <EMAIL>
+
+# Exemple
+./deploy/scripts/init-environment.sh pprod nicolas.cantu@pm.me
+```
+
+**Note :** `build-and-deploy.sh` est maintenant autonome et **recommandé** pour tous les cas.
+
+#### `bump-version.sh`
+
+**Mise à jour de version**
+
+```bash
+# Usage
+./deploy/scripts/bump-version.sh <VERSION> "<MESSAGE>"
+
+# Exemple
+./deploy/scripts/bump-version.sh 2.1.0 "Nouveaux exports"
+```
+
+### Scripts de maintenance
+
+#### `cleanup-remote-disk-aggressive.sh`
+
+**Nettoyage agressif de l'espace disque**
+
+```bash
+# Usage
+bash deploy/scripts/cleanup-remote-disk-aggressive.sh <ENV>
+```
+
+**Actions effectuées** :
+
+1. Arrêt des services systemd (backend, frontend, cron, router)
+2. Nettoyage agressif (builds, caches, journaux)
+3. Nettoyage des anciens builds
+4. Nettoyage des caches système (apt, journaux, logs)
+5. Nettoyage des caches npm et node_modules
+6. Nettoyage des fichiers temporaires (/tmp, /var/tmp, builds, logs)
+7. Nettoyage Git agressif (reflog, packs volumineux)
+8. Affichage de l'état du disque avant et après
+
+**Précautions** :
+
+- La base de données PostgreSQL n'est pas modifiée
+- Les node_modules nécessaires pour le build sont préservés
+- Le script affiche l'état du disque avant et après le nettoyage
+
+#### `repair-remote-git.sh`
+
+**Réparation du repository Git corrompu**
+
+```bash
+# Usage
+bash deploy/scripts/repair-remote-git.sh <ENV>
+```
+
+**Cas d'utilisation** :
+
+- Erreur `BUG: diff-lib.c:633: run_diff_index must be passed exactly one tree`
+- Erreur `fatal: unresolved deltas left after unpacking`
+- Erreur `fatal: unpack-objects failed`
+- Erreur `invalid sha1 pointer`
+
+**Actions effectuées** :
+
+1. Sauvegarde des fichiers sensibles (.env, nginx)
+2. Nettoyage des fichiers Git verrouillés
+3. Tentative de réparation avec `git fsck` et `git gc`
+4. Si le repository est trop corrompu : recréation complète
+5. Restauration des fichiers sensibles
+6. Vérification de l'état final
+
+### Scripts de fix automatiques
+
+#### Vue d'ensemble
+
+Les scripts de fix sont des scripts bash optionnels placés dans `deploy/fix/` qui sont exécutés automatiquement après chaque déploiement. Ils permettent d'appliquer des correctifs ponctuels ou des mises à jour de configuration sans modifier le code principal.
+
+#### Méthode de déploiement
+
+1. **Placement** : Créer un script `.sh` dans `deploy/fix/`
+2. **Exécution automatique** : Le script `build-and-deploy-local-fix.sh` est appelé automatiquement par `build-and-deploy-local.sh` après le déploiement
+3. **Ordre** : Les scripts sont exécutés dans l'ordre alphabétique
+4. **Déplacement** : Après exécution réussie, le script est automatiquement déplacé dans `deploy/fixDone/`
+
+#### Structure obligatoire
+
+```bash
+#!/bin/bash
+
+# Description du script
+# Usage: Ce script est exécuté automatiquement par build-and-deploy-local-fix.sh
+
+set -e
+
+SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
+DEPLOY_SCRIPTS_DIR="$(cd "$SCRIPT_DIR/../scripts" && pwd)"
+source "$DEPLOY_SCRIPTS_DIR/build-and-deploy-local-common.sh"
+
+ENV="$1"
+DOMAIN="$2"
+
+if [ -z "$ENV" ]; then
+    error "ENV manquant"
+    exit 1
+fi
+
+if [ -z "$DOMAIN" ]; then
+    error "DOMAIN manquant"
+    exit 1
+fi
+
+init_deploy_context "$ENV" "$DOMAIN"
+validate_database_credentials
+
+# Votre code ici
+```
+
+#### Règles importantes
+
+1. **Paramètres** : Le script doit accepter `ENV` et `DOMAIN` comme paramètres
+2. **Initialisation** : Utiliser `init_deploy_context` pour charger les variables d'environnement
+3. **Vérifications** : Vérifier l'état des services systemd et les credentials BDD avant d'exécuter
+4. **Code de retour** : Retourner `0` en cas de succès, `1` en cas d'échec
+5. **Logging** : Utiliser les fonctions `info`, `success`, `error`, `warning` du script commun
+
+### Scripts utilitaires backend
+
+#### Promotion des super-administrateurs
+
+La promotion/dé-promotion se fait via les scripts npm du backend, exécutés **sur le serveur cible** :
+
+```bash
+# Sur le serveur, dans le répertoire backend
+npm run promote:superadmin -- --email user@notaires.fr
+npm run promote:superadmin -- --uid 123e4567-e89b-12d3-a456-426614174000
+```
+
+- Le script applique automatiquement les contraintes (rechargement configuration, connexion BDD via Prisma).
+- L'utilisateur doit se reconnecter pour régénérer ses jetons après promotion.
+
+#### Générer un token super-admin
+
+```bash
+npm run token:get -- --json
+```
+
+Ce script promeut automatiquement un super-admin si aucun n'est présent, puis génère un couple access/refresh token.
+
+#### Activation des abonnements utilisateur
+
+L'activation automatique passe par `npm run activate:subscriptions` (backend) :
+
+```bash
+npm run activate:subscriptions -- user@notaires.fr
+```
+
+- Recherche par email, UID ou IdNot.
+- Crée un abonnement UNLIMITED si nécessaire et active ceux existants.
+- Fournit un résumé pour chaque office.
+
+Dans les pipelines de déploiement (`--activateSubscriptions`), cette commande est appelée automatiquement pour chaque email configuré dans `AUTO_ACTIVATE_SUBSCRIPTIONS_EMAILS`.
+
+---
+
+## Maintenance et troubleshooting
+
+### Vérifications post-déploiement
+
+#### Logs
+
+```bash
+# Depuis la machine distante
+ssh debian@<IP_SERVEUR>
+cd /home/debian/sites/test-lecoffreio.4nkweb.com
+
+# Logs temps réel
+journalctl -u lecoffreio-backend@<domain> -f
+journalctl -u lecoffreio-frontend@<domain> -f
+journalctl -u lecoffreio-cron@<domain> -f
+
+# Logs synchronisation
+tail -100 logs/sync-all-*.log | grep -E "ok|error|✅|❌"
+```
+
+#### Tests
+
+```bash
+# Health check
+curl https://test-lecoffreio.4nkweb.com/api/v1/public/health | jq
+
+# Page d'accueil
+curl -I https://test-lecoffreio.4nkweb.com/
+
+# Config publique
+curl https://test-lecoffreio.4nkweb.com/api/v1/public/config | jq
+```
+
+- Interface Super Admin `https://test-lecoffreio.4nkweb.com/super-admin/health`
+  - Permet de lancer des tests *live* (ancrage Signet, SMS OVH, e-mail Mailchimp, upload Pinata, lectures ID.NOT).
+  - Chaque carte affiche le résultat détaillé : lien mempool, URL IPFS, modales JSON IdNot, confirmation "Message envoyé".
+  - La section "Résumé base de données" reprend les volumes principaux (ex: `offices`).
+
+#### Base de données
+
+```bash
+# Compter les enregistrements
+psql -h $DATABASE_HOST -p $DATABASE_PORT -U $DATABASE_USERNAME -d $DATABASE_NAME \
+  -c "SELECT 'offices' as table, COUNT(*) FROM offices UNION SELECT 'users', COUNT(*) FROM users;"
+```
+
+### Maintenance
+
+#### Re-déploiement
+
+```bash
+# Simple
+./deploy/scripts/build-and-deploy.sh test
+
+# Le script :
+# - Détecte que SSL existe déjà → ne régénère pas
+# - Applique nouvelles migrations uniquement
+# - Re-synchronise les données
+```
+
+#### Renouvellement SSL
+
+Les certificats sont renouvelés automatiquement par Certbot (toutes les 12h).
+
+Pour forcer le renouvellement :
+
+```bash
+ssh debian@<IP_SERVEUR>
+cd /home/debian/sites/test-lecoffreio.4nkweb.com
+# Renouvellement certificats (sur le proxy ou serveur où Certbot est installé)
+certbot renew
+# Rechargement Nginx (sur le proxy)
+nginx -s reload
+```
+
+#### Rollback
+
+```bash
+# Restaurer backup BDD
+ssh debian@<IP_SERVEUR>
+cd /home/debian/sites/test-lecoffreio.4nkweb.com
+psql -h ... -U ... -d bdd.test < backups/bdd-test_YYYYMMDD_HHMMSS.sql
+
+# Re-déployer version précédente
+git checkout <commit-hash>
+./deploy/scripts/build-and-deploy.sh test
+```
+
+### Troubleshooting
+
+#### Erreur : `Variable DEPLOY_SSH_HOST manquante`
+
+→ Vérifier que `.env.<env>` contient toutes les variables `DEPLOY_*`
+
+#### Erreur : `Impossible de se connecter`
+
+→ Vérifier clé SSH : `ssh debian@<IP_SERVEUR>`
+
+#### Erreur : Certificat Let's Encrypt échoue
+
+→ Vérifier DNS : `host test-lecoffreio.4nkweb.com`
+→ Vérifier ports : `nc -zv <IP_SERVEUR> 80 443`
+
+#### Backend en crash loop
+
+→ Vérifier logs : `ssh ... 'journalctl -u lecoffreio-backend@<domain> -n 200'`
+→ Vérifier BDD accessible : tester avec psql
+→ Vérifier migrations Prisma : marquer comme appliquées si nécessaire
+
+#### Erreur : Connexion PostgreSQL impossible
+
+→ Vérifier que `DATABASE_USERNAME` et `DATABASE_PASSWORD` dans `deploy/.env.<env>` sont corrects
+→ Vérifier que l'utilisateur PostgreSQL existe : `psql -U postgres -c "\du"`
+→ Vérifier que l'utilisateur a les permissions sur la base : `psql -U postgres -c "GRANT ALL PRIVILEGES ON DATABASE bdd-test TO lecoffre-user-test;"`
+
+#### Erreur : No migration found in prisma/migrations
+
+→ Vérifier que le répertoire `prisma/migrations` existe dans le conteneur
+→ Vérifier que le lien symbolique `src/common/databases/migrations` → `prisma/migrations` est créé
+→ Le script crée automatiquement ce lien lors du déploiement avec `--migrateResolveDatabase`
+
+#### Erreur : Disque plein (Out of diskspace)
+
+→ Utiliser le script de nettoyage : `bash deploy/scripts/cleanup-remote-disk-aggressive.sh <env>`
+→ Vérifier l'espace disque : `ssh ... 'df -h'`
+→ Le script libère généralement 15-20GB d'espace
+
+#### Erreur : Repository Git corrompu
+
+→ Utiliser le script de réparation : `bash deploy/scripts/repair-remote-git.sh <env>`
+→ Erreurs courantes : `unresolved deltas`, `invalid sha1 pointer`, `unpack-objects failed`
+→ Le script sauvegarde les fichiers sensibles avant réparation
+
+#### Synchronisation échoue
+
+→ Vérifier credentials IdNot dans `system_configuration`
+→ Vérifier les logs applicatifs (API IdNot / Annuaire) côté backend
+
+#### Erreur : `curl_error` variable sans liaison (deploy.sh)
+
+**Symptômes :** `./deploy/scripts_v2/deploy.sh: ligne 281: curl_error : variable sans liaison` lorsque l'API d'ancrage échoue et que le fichier d'erreur curl est vide.
+
+**Root cause :** Avec `set -u`, toute référence à une variable non définie provoque une erreur. `curl_error` n'est défini que si le fichier d'erreur curl contient des données ; sinon la variable est utilisée sans exister.
+
+**Correctif :** Initialiser `local curl_error=""` avant usage. Fichier : `deploy/scripts_v2/deploy.sh`.
+
+### Vérifications et debugging
+
+#### Vérifier les certificats sur le host
+
+```bash
+# Sur le serveur distant
+ssh debian@<IP_SERVEUR>
+
+cd /home/debian/sites/test-lecoffreio.4nkweb.com
+
+# Lister certificats
+sudo ls -la deploy/nginx/certbot/conf-test/live/test-lecoffreio.4nkweb.com/
+
+# Vérifier validité
+sudo openssl x509 -in deploy/nginx/certbot/conf-test/live/test-lecoffreio.4nkweb.com/fullchain.pem -noout -dates
+```
+
+#### Vérifier la configuration Nginx
+
+```bash
+# Tester configuration (sur le host)
+cat deploy/nginx/nginx-test.conf
+
+# Tester configuration Nginx
+nginx -t
+
+# Recharger Nginx
+nginx -s reload
+```
+
+#### Vérifier les montages et la configuration Nginx
+
+```bash
+# Voir les volumes montés
+# Vérifier la configuration Nginx sur le proxy
+nginx -T
+
+# Exemple de sortie :
+# /home/debian/sites/test-lecoffreio.4nkweb.com/deploy/nginx/nginx-test.conf -> /etc/nginx/nginx.conf
+# /home/debian/sites/test-lecoffreio.4nkweb.com/deploy/nginx/certbot/conf-test -> /etc/letsencrypt
+# /home/debian/sites/test-lecoffreio.4nkweb.com/deploy/nginx/certbot/www-test -> /var/www/certbot
+```
+
+#### Vérifier les logs
+
+```bash
+# Logs Nginx (sur le proxy)
+journalctl -u nginx -n 50
+
+# Logs backend (sur le serveur env)
+journalctl -u lecoffreio-backend@<domain> -n 50
+
+# Certbot : selon l'installation (cron ou service systemd)
+```
+
+---
+
+## API d'ancrage Bitcoin séparée
+
+L'API d'ancrage Bitcoin est déployée sur un serveur séparé.
+
+**Production** : `anchorage.certificator.4nkweb.com` (HTTPS)
+
+### Configuration
+
+```bash
+cp env.bitcoin.api.deploy.example .env.bitcoin.api.deploy
+nano .env.bitcoin.api.deploy  # Configurer serveur Bitcoin
+```
+
+**Variables requises** :
+
+```bash
+REMOTE_HOST=<USER>@<IP_SERVEUR_BITCOIN>
+REMOTE_DIR=~/dev/lecoffre-anchor-api
+LOCAL_DIR=~/dev/lecoffre-anchor-api
+PM2_APP_NAME=lecoffre-anchor-api
+SSH_KEY=$HOME/.ssh/id_ed25519_4nk
+
+# Production
+ANCHORE_API_URL=https://anchorage.certificator.4nkweb.com
+ANCHORE_API_KEY=<CLE_API>
+```
+
+### Déploiement
+
+```bash
+./deploy-anchor-api.sh
+```
+
+### Infrastructure
+
+- **Serveur Production** : `anchorage.certificator.4nkweb.com` (HTTPS)
+- **Répertoire** : `/home/<USER>/dev/lecoffre-anchor-api`
+- **Health** : `https://anchorage.certificator.4nkweb.com/health`
+
+---
+
+## Sécurité
+
+### Certificats SSL
+
+- ✅ Certificats SSL Let's Encrypt valides (renouvellement auto toutes les 12h)
+- ✅ Certificats en lecture seule pour Nginx
+- ✅ Permissions strictes sur les clés privées (600)
+
+### Configuration
+
+- ✅ Fichiers `.env.*` en `.gitignore`
+- ✅ Certificats SSL Let's Encrypt valides
+- ✅ Configurations sensibles en BDD (masquées)
+- ✅ CORS strictement configuré
+- ✅ Rate limiting actif
+- ✅ Pas de ports exposés (sauf 80/443 via Nginx)
+
+### Permissions des certificats
+
+```bash
+# Les certificats doivent appartenir à root (générés par Certbot en root)
+sudo chown -R root:root deploy/nginx/certbot/conf-test/
+
+# Permissions recommandées
+sudo chmod 755 deploy/nginx/certbot/conf-test/live/test-lecoffreio.4nkweb.com/
+sudo chmod 644 deploy/nginx/certbot/conf-test/live/test-lecoffreio.4nkweb.com/fullchain.pem
+sudo chmod 600 deploy/nginx/certbot/conf-test/live/test-lecoffreio.4nkweb.com/privkey.pem
+```
+
+### Lecture seule
+
+Les certificats et configurations Nginx sont configurés en **lecture seule** sur le système de fichiers.
+
+**Avantages** :
+
+- Nginx ne peut pas modifier les certificats
+- Séparation des privilèges
+
+---
+
+## Architecture récapitulative
+
+```text
+┌─────────────────────────────────────────────────────────────┐
+│                    HOST (Serveur distant)                    │
+│  /home/debian/sites/test-lecoffreio.4nkweb.com/            │
+│                                                              │
+│  ┌─────────────────┐  ┌──────────────────┐                 │
+│  │ deploy/nginx/   │  │ deploy/nginx/    │                 │
+│  │ nginx-test.conf │  │ certbot/         │                 │
+│  │                 │  │ ├─ conf-test/    │                 │
+│  │ (Bind mount)    │  │ │  └─ live/...   │                 │
+│  └────────┬────────┘  │ └─ www-test/     │                 │
+│           │           │  (Bind mounts)   │                 │
+│           │           └────────┬──────────┘                 │
+│           │                    │                             │
+│  ┌────────▼────────────────────▼──────────────────────┐    │
+│  │            Services (systemd / Nginx)                 │    │
+│  │                                                      │    │
+│  │  ┌──────────────┐  ┌──────────────┐               │    │
+│  │  │   Nginx      │  │  Certbot     │               │    │
+│  │  │ (nginx:alpine│  │(certbot/      │               │    │
+│  │  │  ports 80,443│  │ certbot)      │               │    │
+│  │  └──────┬───────┘  └──────────────┘               │    │
+│  │         │                                           │    │
+│  │  ┌──────▼───────┐  ┌──────────────┐               │    │
+│  │  │  Frontend    │  │   Backend     │               │    │
+│  │  │ (Next.js)    │  │  (Express)    │               │    │
+│  │  │  port 3000   │  │   port 3001   │               │    │
+│  │  └──────────────┘  └──────────────┘               │    │
+│  │                                                      │    │
+│  │  ┌──────────────┐                                   │    │
+│  │  │     Cron     │                                   │    │
+│  │  │ (Tâches)     │                                   │    │
+│  │  └──────────────┘                                   │    │
+│  │                                                      │    │
+│  │  ┌──────────────┐  ┌──────────────┐               │    │
+│  │  │    Loki      │  │   Promtail    │               │    │
+│  │  │ (port 3100)  │  │ (collecte)   │               │    │
+│  │  └──────┬───────┘  └──────┬───────┘               │    │
+│  │         │                  │                         │    │
+│  │  ┌──────▼──────────────────▼───────┐             │    │
+│  │  │         Grafana                  │             │    │
+│  │  │    (port 3000 loopback)          │             │    │
+│  │  └──────────────────────────────────┘             │    │
+│  └──────────────────────────────────────────────────────┘    │
+│                                                              │
+│  ┌─────────────────────────────────────────────────────┐   │
+│  │  PostgreSQL (Base de données externe)               │   │
+│  │  <IP_POSTGRESQL>:<PORT_POSTGRESQL>                  │   │
+│  └─────────────────────────────────────────────────────┘   │
+└─────────────────────────────────────────────────────────────┘
+```
+
+---
+
+## Commandes utiles
+
+### Déploiement complet avec certificats
+
+```bash
+# Depuis la machine de développement
+cd /home/debian/legacy/lecoffreio
+./deploy/scripts/build-and-deploy.sh test --deploy --cert
+```
+
+### Renouveler les certificats manuellement
+
+```bash
+# Sur le serveur distant
+cd /home/debian/sites/test-lecoffreio.4nkweb.com
+
+# Forcer renouvellement (sur le proxy ou serveur où Certbot est installé)
+certbot renew --force-renewal
+
+# Recharger Nginx (sur le proxy)
+nginx -s reload
+```
+
+### Vérifier l'état des services
+
+```bash
+# Statut des services (sur le serveur env)
+systemctl status 'lecoffreio-*@*'
+
+# Logs en temps réel
+journalctl -u lecoffreio-backend@<domain> -f
+
+# Health check backend
+curl https://test-lecoffreio.4nkweb.com/health
+```
+
+### Logs après déploiement (depuis machine distante)
+
+```bash
+ssh ncantu@<IP_SERVEUR> 'journalctl -u lecoffreio-backend@<domain> -f'
+
+# Statut services
+ssh ncantu@<IP_SERVEUR> 'systemctl status "lecoffreio-*@*"'
+
+# Logs synchronisation
+ssh debian@<IP_SERVEUR> 'cd /home/debian/sites/test-lecoffreio.4nkweb.com && tail -100 logs/sync-all-*.log'
+
+# Health check
+curl https://test-lecoffreio.4nkweb.com/api/v1/public/health | jq
+```
+
+---
+
+## Monitoring
+
+### Architecture
+
+#### Objectif
+
+- Centraliser les logs applicatifs (`logs/*.log`) via Promtail → Loki
+- Offrir aux équipes support un Grafana local accounts (pas de SSO)
+- Faciliter l'analyse racine via requêtes Loki (filtre `job`, `level`, `message`)
+
+#### Services déployés
+
+| Service | Instance | Port | Volume de données |
+|---------|----------|------|-------------------|
+| **Loki** | `lecoffre_loki_${ENV}` | 3100 (interne) | `/var/lib/lecoffre/loki-${ENV}` |
+| **Promtail** | `lecoffre_promtail_${ENV}` | - | `/var/lib/lecoffre/promtail-${ENV}` |
+| **Grafana** | `lecoffre_grafana_${ENV}` | 3000 (loopback) | `/var/lib/lecoffre/grafana-${ENV}` |
+
+#### Réseau
+
+Les services de monitoring communiquent sur l'hôte (localhost ou réseau interne).
+
+#### Flux de données
+
+```text
+Backend/Cron → Fichiers logs → Promtail → Loki → Grafana
+```
+
+#### Infrastructure
+
+- **Promtail** : surveille `logs/` (bind `../logs`) via jobs `application-logs` et `sync-logs`
+- **Loki** : stocke les logs sur `/var/lib/lecoffre/loki-<env>` (retention 14 jours par défaut)
+- **Grafana** : interface UI, accessible via `/monitor` (reverse proxy) ou tunnel SSH (`127.0.0.1:3000`)
+
+### Configuration Grafana
+
+#### Accès
+
+**Via HTTPS (recommandé)** :
+
+1. URL : `https://<DEPLOY_DOMAIN>/monitor/`
+2. Authentification : Identifiants configurés dans `.env.<env>`
+   - User : `GRAFANA_ADMIN_USER`
+   - Password : `GRAFANA_ADMIN_PASSWORD`
+
+**Via tunnel SSH (fallback)** :
+
+```bash
+ssh -L 3000:127.0.0.1:3000 debian@<DEPLOY_SSH_HOST>
+```
+
+Puis ouvrir `http://localhost:3000` dans le navigateur.
+
+#### Variables d'environnement
+
+```yaml
+GF_SECURITY_ADMIN_USER: ${GRAFANA_ADMIN_USER:-grafana}
+GF_SECURITY_ADMIN_PASSWORD: ${GRAFANA_ADMIN_PASSWORD:-grafana-pass}
+GF_SECURITY_ALLOW_EMBEDDING: "false"
+GF_SECURITY_DISABLE_GRAVATAR: "true"
+GF_USERS_ALLOW_SIGN_UP: "false"
+GF_SERVER_DOMAIN: ${DEPLOY_DOMAIN}
+GF_SERVER_ROOT_URL: "https://${DEPLOY_DOMAIN}/monitor/"
+GF_SERVER_SERVE_FROM_SUB_PATH: "true"
+```
+
+#### Provisioning automatique
+
+**Datasources** :
+
+**Emplacement** : `deploy/monitoring/grafana/provisioning/datasources/loki.yml`
+
+La datasource Loki est automatiquement configurée avec :
+
+- **URL** : `http://loki:3100`
+- **Type** : `loki`
+- **Accès** : `proxy`
+- **Par défaut** : Oui
+- **Max lines** : 1000
+- **Derived fields** : Support pour les traceID
+
+**Dashboards** :
+
+**Emplacement** : `deploy/monitoring/grafana/provisioning/dashboards/dashboards.yml`
+
+Le provisioning des dashboards est configuré pour :
+
+- Charger automatiquement les dashboards depuis `/etc/grafana/provisioning/dashboards`
+- Mettre à jour toutes les 10 secondes
+- Permettre les mises à jour via l'UI
+- Organiser les dashboards par structure de dossiers
+
+#### Reverse Proxy Nginx
+
+**Fichier** : `deploy/nginx/includes/monitor.conf`
+
+Nginx configure un reverse proxy pour Grafana :
+
+- **Path** : `/monitor/`
+- **Backend** : `http://grafana:3000`
+- **Headers** : Préservation des headers X-Forwarded-* pour HTTPS
+- **Timeout** : 300s pour les requêtes longues
+
+### Configuration Loki
+
+#### Fichier de configuration
+
+**Emplacement** : `deploy/monitoring/loki-config.yml`
+
+#### Paramètres clés
+
+- **Port HTTP** : 3100 (interne uniquement)
+- **Stockage** : Filesystem (`/var/lib/loki`)
+- **Rétention** : 336h (14 jours)
+- **Schéma** : v12 avec boltdb-shipper
+- **Compression** : Activée pour les réponses
+
+#### Rétention des données
+
+```yaml
+table_manager:
+  retention_deletes_enabled: true
+  retention_period: 336h  # 14 jours
+  poll_interval: 5m
+```
+
+Les données sont automatiquement supprimées après 14 jours.
+
+### Configuration Promtail
+
+#### Fichier de configuration
+
+**Emplacement** : `deploy/monitoring/promtail-config.yml`
+
+#### Jobs de collecte
+
+Promtail collecte les logs depuis `/var/log/lecoffre` (monté depuis `../logs` sur l'hôte) :
+
+1. **application-logs** : Tous les fichiers `*.log` à la racine
+2. **sync-logs** : Fichiers `sync-*.log`
+3. **winston-logs** : Fichiers Winston avec pattern de date :
+   - `error-YYYY-MM-DD.log`
+   - `combined-YYYY-MM-DD.log`
+   - `login-YYYY-MM-DD.log`
+4. **deployment-logs** : Fichiers `build-and-deploy-*.log`
+
+#### Labels
+
+- `job` : Type de log (`application-logs`, `sync-logs`, `deployment-logs`)
+- `env` : Environnement (`test`, `pprod`, `prod`, `demo`) - ajouté via `-client.external-labels`
+
+#### Positions
+
+Les positions de lecture sont stockées dans `/var/promtail/positions.yaml` pour éviter de relire les fichiers depuis le début.
+
+### Dashboards
+
+#### Dashboard Vue d'ensemble
+
+**Fichier** : `deploy/monitoring/grafana/provisioning/dashboards/lecoffre-overview.json`
+
+**Panneaux** :
+
+- Logs applicatifs récents + Erreurs récentes
+- Statistiques (1h) : Erreurs, Warnings, Connexions, Requêtes lentes
+- Graphiques timeseries : Erreurs/heure, Warnings/heure
+- Logs spécialisés : Connexion [LOGIN_MARKER], Requêtes Prisma lentes, Erreurs Prisma
+- Logs de synchronisation + Logs de déploiement
+
+#### Dashboards spécialisés
+
+Les dashboards suivants sont disponibles :
+
+1. **LeCoffre.io - Backend** : Logs backend, erreurs, connexions, requêtes Prisma lentes
+2. **LeCoffre.io - Frontend** : Logs frontend Next.js, erreurs, builds
+3. **LeCoffre.io - Base de données** : Requêtes Prisma lentes, erreurs Prisma, erreurs connexion PostgreSQL
+4. **LeCoffre.io - ClamAV Antivirus** : Scans antivirus, malwares détectés
+5. **LeCoffre.io - IdNot** : Logs de connexion, synchronisation des offices
+6. **LeCoffre.io - OVH/SMS** : Logs SMS, codes 2FA
+7. **LeCoffre.io - Stripe** : Webhooks Stripe, abonnements
+8. **LeCoffre.io - Mailchimp** : Emails envoyés, erreurs d'envoi
+9. **LeCoffre.io - Bitcoin Signet** : Ancrages réussis/échoués, vérifications blockchain
+10. **LeCoffre.io - Espace Tiers** : Ajouts de tiers, documents consultés
+11. **LeCoffre.io - Espace Client** : Documents consultés, fichiers uploadés
+12. **LeCoffre.io - Dossiers Invités** : Partages de dossiers, accès notaires invités
+13. **LeCoffre.io - Espace Notaire** : Créations de dossiers, documents, ancrages
+
+### Requêtes LogQL
+
+#### Requêtes courantes
+
+- `{job="application-logs"} |= "ERROR"` : Toutes les erreurs applicatives
+- `{job="sync-logs"} |= "sync-directory"` : Logs de synchronisation
+- `{job="application-logs"} |= "[Antivirus]"` : Tous les scans ClamAV
+- `{job="application-logs"} |= "[Antivirus] Malware detected"` : Malwares détectés
+
+#### Logs applicatifs généraux
+
+```logql
+{job="application-logs"}
+```
+
+#### Erreurs uniquement
+
+```logql
+{job="application-logs"} |~ "(ERROR|❌|error)"
+```
+
+#### Warnings
+
+```logql
+{job="application-logs"} |~ "(WARN|⚠️|warn)"
+```
+
+#### Logs ClamAV
+
+```logql
+{job="application-logs"} |= "[Antivirus]"
+```
+
+#### Malwares détectés
+
+```logql
+{job="application-logs"} |= "[Antivirus] Malware detected"
+```
+
+#### Logs de synchronisation
+
+```logql
+{job="sync-logs"}
+```
+
+#### Logs de déploiement
+
+```logql
+{job="deployment-logs"}
+```
+
+#### Métriques temporelles
+
+**Nombre d'erreurs par heure** :
+
+```logql
+count_over_time({job="application-logs"} |= "ERROR" [1h])
+```
+
+**Nombre de scans ClamAV par heure** :
+
+```logql
+count_over_time({job="application-logs"} |= "[Antivirus] Scan started" [1h])
+```
+
+#### Patterns de logs utilisés
+
+- `[LOGIN_MARKER]` : Logs de connexion utilisateur
+- `[Prisma Slow Query]` : Requêtes Prisma lentes (> 1 seconde)
+- `[Prisma Error]` : Erreurs Prisma
+- `[Antivirus]` : Tous les logs ClamAV
+- `ERROR`, `❌`, `error` : Erreurs générales
+- `WARN`, `⚠️`, `warn` : Warnings
+- `✅` : Succès
+
+### Troubleshooting Monitoring
+
+#### Problème "No Data" dans Grafana
+
+**1. Vérifier que les fichiers de logs existent** :
+
+```bash
+# Sur le serveur distant
+ls -la /home/debian/sites/<env>-lecoffreio.4nkweb.com/logs/
+```
+
+**Résultat attendu** :
+
+- `backend-YYYY-MM-DD.log` (logs backend)
+- `cron-YYYY-MM-DD.log` (logs cron)
+- Autres fichiers de logs (Winston, déploiement, etc.)
+
+**2. Vérifier que Promtail peut lire les fichiers** :
+
+```bash
+# Vérifier les logs Promtail (selon déploiement : systemd ou service)
+journalctl -u promtail -n 100
+
+# Vérifier les positions (chemin selon installation)
+cat /var/lib/lecoffre/promtail-<env>/positions.yaml
+
+# Vérifier que les fichiers de logs existent
+ls -la logs/
+```
+
+**3. Vérifier la connexion Promtail → Loki** :
+
+```bash
+# Vérifier que Loki est accessible (selon déploiement)
+curl -s http://127.0.0.1:3100/ready
+
+# Vérifier les logs Promtail pour les erreurs de connexion
+journalctl -u promtail -n 100 | grep -i error
+```
+
+**4. Vérifier que Loki reçoit les logs** :
+
+```bash
+# Vérifier les logs Loki (selon déploiement)
+journalctl -u loki -n 100
+
+# Tester l'API Loki (labels disponibles)
+curl -s http://127.0.0.1:3100/loki/api/v1/labels
+
+# Tester une requête LogQL
+curl -s "http://127.0.0.1:3100/loki/api/v1/query_range?query={job=\"application-logs\"}&limit=10"
+```
+
+**5. Vérifier les labels dans Grafana** :
+
+Dans Grafana, aller dans **Explore** (icône boussole) :
+
+1. Sélectionner la datasource **Loki**
+2. Tester la requête : `{job="application-logs"}`
+3. Vérifier que des logs apparaissent
+
+**6. Vérifier la plage de temps** :
+
+Les logs doivent avoir des timestamps récents. Si les logs sont trop anciens, ils peuvent ne pas apparaître dans la plage de temps sélectionnée dans Grafana.
+
+**Solution** : Ajuster la plage de temps dans Grafana (par défaut : `now-6h` à `now`)
+
+#### Causes courantes et solutions
+
+**Cause 1 : Fichiers de logs non créés** :
+
+**Symptômes** :
+
+- `ls -la logs/` ne montre pas de fichiers `backend-*.log` ou `cron-*.log`
+- Les conteneurs backend/cron démarrent mais n'écrivent pas de logs
+
+**Solutions** :
+
+1. Vérifier que les scripts wrapper sont exécutables
+2. Vérifier les logs backend : `journalctl -u lecoffreio-backend@<domain> -n 100`
+3. Vérifier le répertoire des logs : `ls -la logs/`
+
+**Cause 2 : Promtail ne peut pas lire les fichiers** :
+
+**Symptômes** :
+
+- Les fichiers existent mais Promtail ne les lit pas
+- Erreurs `permission denied` dans les logs Promtail
+
+**Solutions** :
+
+1. Vérifier les permissions des fichiers : `ls -la logs/`
+2. Vérifier que Promtail a accès au répertoire des logs (configuration Promtail)
+3. Vérifier les permissions du répertoire logs/
+
+**Cause 3 : Promtail ne peut pas se connecter à Loki** :
+
+**Symptômes** :
+
+- Erreurs `connection refused` dans les logs Promtail
+- Loki ne reçoit pas de logs
+
+**Solutions** :
+
+1. Vérifier que Loki est démarré : `systemctl status loki` ou selon déploiement
+2. Vérifier que Promtail et Loki communiquent (même hôte ou URL configurée)
+3. Vérifier l'URL dans `promtail-config.yml` : `http://127.0.0.1:3100/loki/api/v1/push`
+
+**Cause 4 : Labels incorrects** :
+
+**Symptômes** :
+
+- Loki reçoit des logs mais les dashboards affichent "No data"
+- Les requêtes LogQL ne retournent rien
+
+**Solutions** :
+
+1. Vérifier les labels disponibles : `curl http://localhost:3100/loki/api/v1/labels`
+2. Vérifier que les labels dans `promtail-config.yml` correspondent aux requêtes dans les dashboards
+3. Vérifier que le label `job` est bien défini dans tous les `scrape_configs`
+
+**Cause 5 : Configuration Promtail obsolète** :
+
+**Symptôme** : Pattern trop large (`*.log`) créant des doublons
+
+**Solution** : Supprimer le `scrape_config` avec pattern trop large et conserver uniquement les configurations spécifiques (backend-*.log, cron-*.log, etc.)
+
+Voir [README.md](./README.md#consolidation-operationnelle-ex-operationsmd) et logs backend pour le dépannage Grafana/Loki.
+
+### Persistance des données Monitoring
+
+#### Persistance des données
+
+Toutes les données sont persistées sur l'hôte dans `/var/lib/lecoffre/` :
+
+- **Loki** : `/var/lib/lecoffre/loki-${ENV}/` - Index et chunks de logs
+- **Promtail** : `/var/lib/lecoffre/promtail-${ENV}/` - Positions de lecture
+- **Grafana** : `/var/lib/lecoffre/grafana-${ENV}/` - Dashboards, datasources, utilisateurs
+
+#### Survie aux redéploiements
+
+Les répertoires de données sont créés avant le démarrage des services et survivent aux redéploiements.
+
+### Sécurité Monitoring
+
+#### Authentification Grafana
+
+- Authentification locale uniquement
+- Pas d'inscription publique (`GF_USERS_ALLOW_SIGN_UP: "false"`)
+- Pas d'embedding externe (`GF_SECURITY_ALLOW_EMBEDDING: "false"`)
+
+#### Accès réseau
+
+- **Loki** : Accessible sur le réseau local (port 3100)
+- **Promtail** : Pas de port exposé (collecte uniquement)
+- **Grafana** : Port 3000 exposé uniquement en loopback (`127.0.0.1:3000`)
+
+#### Accès externe
+
+L'accès externe se fait uniquement via HTTPS via Nginx reverse proxy sur `/monitor/`.
+
+### Vérification de l'état Monitoring
+
+#### Vérifier que les services sont en cours d'exécution
+
+```bash
+systemctl status loki promtail grafana-server
+```
+
+#### Vérifier les logs des services
+
+```bash
+# Loki
+journalctl -u loki -n 100
+
+# Promtail
+journalctl -u promtail -n 100
+
+# Grafana
+journalctl -u grafana-server -n 100
+```
+
+#### Vérifier la connectivité Loki
+
+```bash
+curl -s http://127.0.0.1:3100/ready
+```
+
+#### Vérifier les fichiers de logs collectés
+
+```bash
+ls -la logs/
+```
+
+#### Vérifier les positions Promtail
+
+```bash
+cat /var/lib/lecoffre/promtail-<env>/positions.yaml
+```
+
+---
+
+## Disaster Recovery
+
+### Vue d'Ensemble
+
+Le système de disaster recovery permet de :
+
+- **Sauvegarder quotidiennement** l'état complet de la production
+- **Conserver 7 versions** de sauvegardes sur une VM Gandi
+- **Récupérer automatiquement** en cas d'incident : installation complète, bascule DNS, certificats SSL, relance des services
+
+**RTO (Recovery Time Objective)** : 3 heures
+**RPO (Recovery Point Objective)** : 24 heures (sauvegarde quotidienne)
+
+### Architecture
+
+#### Infrastructure
+
+```text
+Serveur Prod (192.168.1.103)
+    │
+    │ [backup-daily.sh - quotidien 2h00]
+    │
+    ▼
+VM Gandi (92.243.24.12)
+    │
+    │ /var/lecoffreio/prod/
+    │   ├── backup-20250109-020000.tar.gz
+    │   ├── backup-20250108-020000.tar.gz
+    │   ├── ... (7 versions)
+    │   └── latest -> backup-20250109-020000.tar.gz
+    │
+    ▼
+[En cas d'incident]
+    │
+    │ [disaster-recovery.sh]
+    │
+    ▼
+Serveur de Récupération (RECOVERY_TARGET_HOST)
+    │
+    │ [Bascule DNS via API Gandi]
+    │
+    ▼
+prod.lecoffreio.4nkweb.com → Nouvelle IP
+```
+
+#### Composants
+
+1. **`backup-daily.sh`** : Script de sauvegarde quotidienne automatique
+2. **`disaster-recovery.sh`** : Script de récupération automatisée complète
+3. **`gandi-dns-api.sh`** : Script d'interaction avec l'API Gandi pour la bascule DNS
+
+### Configuration Initiale
+
+#### 1. Créer le fichier de configuration
+
+```bash
+cp .secrets/.env.backup.example .secrets/.env.backup
+```
+
+#### 2. Configurer les variables
+
+Éditez `.secrets/.env.backup` :
+
+```bash
+# VM Gandi (Sauvegarde)
+BACKUP_GANDI_HOST=92.243.24.12
+BACKUP_GANDI_USER=debian
+BACKUP_GANDI_SSH_KEY=~/.ssh/id_ed25519
+BACKUP_GANDI_PATH=/var/lecoffreio
+
+# API Gandi (Bascule DNS)
+GANDI_API_KEY=your-gandi-api-key-here
+GANDI_DOMAIN=prod.lecoffreio.4nkweb.com
+
+# Configuration de sauvegarde
+BACKUP_RETENTION_DAYS=7
+BACKUP_SCHEDULE_HOUR=2
+BACKUP_SCHEDULE_MINUTE=0
+BACKUP_ENV=prod
+
+# Récupération (optionnel - pour disaster-recovery.sh)
+RECOVERY_TARGET_HOST=92.243.24.12
+RECOVERY_TARGET_USER=debian
+RECOVERY_TARGET_SSH_KEY=~/.ssh/id_ed25519
+```
+
+#### 3. Configurer l'accès SSH
+
+Assurez-vous que les clés SSH sont configurées :
+
+```bash
+# Test connexion VM Gandi
+ssh -i ~/.ssh/id_ed25519 debian@92.243.24.12 "echo 'OK'"
+
+# Test connexion serveur de récupération (si différent)
+ssh -i ~/.ssh/id_ed25519 debian@$RECOVERY_TARGET_HOST "echo 'OK'"
+```
+
+#### 4. Préparer la VM Gandi
+
+Sur la VM Gandi, créer la structure de répertoires :
+
+```bash
+ssh debian@92.243.24.12
+sudo mkdir -p /var/lecoffreio/prod
+sudo chown debian:debian /var/lecoffreio/prod
+```
+
+#### 5. Vérifier l'API Gandi
+
+Tester l'accès à l'API Gandi :
+
+```bash
+curl -H "Authorization: Apikey $GANDI_API_KEY" \
+     https://id.gandi.net/tokeninfo
+```
+
+### Sauvegarde Quotidienne
+
+#### Exécution Manuelle
+
+```bash
+./deploy/scripts/backup/backup-daily.sh
+```
+
+#### Configuration Cron (Automatique)
+
+Sur le serveur prod, ajouter dans le crontab :
+
+```bash
+# Sauvegarde quotidienne à 2h00
+0 2 * * * /path/to/lecoffreio/deploy/scripts/backup/backup-daily.sh >> /path/to/logs/backup-daily.log 2>&1
+```
+
+#### Contenu des Sauvegardes
+
+Chaque sauvegarde contient :
+
+- **`database.dump`** : Dump PostgreSQL au format custom (pg_dump -Fc)
+- **`.env.prod`** : Fichier de configuration de l'environnement
+- **`nginx-prod.conf`** : Configuration Nginx
+- **`certbot-conf-prod/`** : Certificats SSL (live, archive, accounts, renewal)
+- **`backup-metadata.json`** : Métadonnées (timestamp, Git commit, environnement)
+
+#### Structure sur VM Gandi
+
+```text
+/var/lecoffreio/prod/
+├── backup-20250109-020000.tar.gz
+├── backup-20250108-020000.tar.gz
+├── backup-20250107-020000.tar.gz
+├── backup-20250106-020000.tar.gz
+├── backup-20250105-020000.tar.gz
+├── backup-20250104-020000.tar.gz
+├── backup-20250103-020000.tar.gz
+└── latest -> backup-20250109-020000.tar.gz
+```
+
+#### Rotation Automatique
+
+Le script conserve automatiquement les 7 dernières sauvegardes. Les sauvegardes plus anciennes sont supprimées automatiquement.
+
+### Récupération d'Urgence
+
+#### Exécution
+
+```bash
+# Utiliser la dernière sauvegarde (latest)
+./deploy/scripts/backup/disaster-recovery.sh
+
+# Utiliser une sauvegarde spécifique
+./deploy/scripts/backup/disaster-recovery.sh backup-20250108-020000.tar.gz
+```
+
+#### Processus Automatisé
+
+Le script `disaster-recovery.sh` effectue automatiquement :
+
+1. **Récupération de la sauvegarde** depuis la VM Gandi
+2. **Extraction de l'archive** et vérification du contenu
+3. **Préparation du serveur de récupération** (vérification prérequis)
+4. **Clone/update du repository Git** sur le serveur de récupération
+5. **Restauration des fichiers de configuration** (.env, nginx, certificats)
+6. **Upload du dump de base de données**
+7. **Bascule DNS** via API Gandi (prod.lecoffreio.4nkweb.com → IP serveur de récupération)
+8. **Attente de la propagation DNS** (vérification toutes les 30 secondes)
+9. **Restauration de la base de données** sur le serveur de récupération
+10. **Mise à jour des certificats SSL** (renouvellement si nécessaire)
+11. **Build et déploiement** (build, démarrage services systemd)
+12. **Vérification de la santé** des services (backend, nginx)
+13. **Tests de connectivité** HTTP/HTTPS
+
+#### Durée Estimée
+
+- Récupération sauvegarde : ~5-10 minutes
+- Bascule DNS : ~5-10 minutes (propagation)
+- Restauration BDD : ~10-30 minutes (selon taille)
+- Build : ~15-30 minutes
+- **Total** : ~45-80 minutes (objectif RTO : 3 heures)
+
+### Gestion DNS via API Gandi
+
+#### Script Gandi DNS API
+
+Le script `gandi-dns-api.sh` permet de gérer les enregistrements DNS :
+
+```bash
+# Récupérer l'enregistrement actuel
+./deploy/scripts/backup/gandi-dns-api.sh get prod.lecoffreio.4nkweb.com
+
+# Mettre à jour vers une nouvelle IP
+./deploy/scripts/backup/gandi-dns-api.sh update prod.lecoffreio.4nkweb.com 92.243.24.12
+
+# Supprimer un enregistrement (rarement nécessaire)
+./deploy/scripts/backup/gandi-dns-api.sh delete prod.lecoffreio.4nkweb.com
+```
+
+#### Format de l'API
+
+L'API Gandi utilise le format :
+
+- **URL** : `https://api.gandi.net/api/v5/domains/{domain}/records/{name}/{type}`
+- **Authorization** : `Apikey ${GANDI_API_KEY}`
+- **Domain** : `lecoffreio.4nkweb.com` (domaine de base)
+- **Name** : `prod` (sous-domaine)
+- **Type** : `A` (enregistrement IPv4)
+
+### Monitoring et Maintenance Disaster Recovery
+
+#### Vérification Quotidienne des Sauvegardes
+
+```bash
+# Lister les sauvegardes sur VM Gandi
+ssh debian@92.243.24.12 "ls -lh /var/lecoffreio/prod/"
+
+# Vérifier la dernière sauvegarde
+ssh debian@92.243.24.12 "ls -lh /var/lecoffreio/prod/latest"
+```
+
+#### Logs
+
+Les scripts génèrent des logs dans `logs/` :
+
+```bash
+# Logs de sauvegarde
+ls -lh logs/backup-daily-*.log
+
+# Logs de récupération
+ls -lh logs/disaster-recovery-*.log
+```
+
+#### Vérification de l'Espace Disque
+
+Sur la VM Gandi :
+
+```bash
+# Espace disque utilisé
+ssh debian@92.243.24.12 "df -h /var/lecoffreio"
+
+# Taille des sauvegardes
+ssh debian@92.243.24.12 "du -sh /var/lecoffreio/prod/*"
+```
+
+#### Tests de Récupération
+
+Il est recommandé de tester la récupération **trimestriellement** :
+
+1. Utiliser un serveur de test (ou VM temporaire)
+2. Exécuter `disaster-recovery.sh` avec une sauvegarde récente
+3. Vérifier que tous les services fonctionnent
+4. Documenter les problèmes rencontrés
+
+### Dépannage Disaster Recovery
+
+#### Problème : Sauvegarde échoue
+
+**Symptômes** :
+
+- Le script `backup-daily.sh` échoue
+- Pas de nouvelle sauvegarde dans `/var/lecoffreio/prod/`
+
+**Diagnostic** :
+
+```bash
+# Vérifier les logs
+tail -100 logs/backup-daily-*.log
+
+# Vérifier la connexion SSH au serveur prod
+ssh -i ~/.ssh/id_ed25519 debian@<PROD_SERVER> "echo 'OK'"
+
+# Vérifier la connexion SSH à la VM Gandi
+ssh -i ~/.ssh/id_ed25519 debian@92.243.24.12 "echo 'OK'"
+
+# Vérifier l'espace disque sur VM Gandi
+ssh debian@92.243.24.12 "df -h /var"
+```
+
+**Solutions** :
+
+- Vérifier les clés SSH
+- Vérifier l'espace disque disponible
+- Vérifier que PostgreSQL est accessible
+
+#### Problème : Récupération échoue
+
+**Symptômes** :
+
+- Le script `disaster-recovery.sh` échoue à une étape
+- Services non démarrés après récupération
+
+**Diagnostic** :
+
+```bash
+# Vérifier les logs
+tail -100 logs/disaster-recovery-*.log
+
+# Vérifier l'état des services sur le serveur de récupération
+ssh ncantu@$RECOVERY_TARGET_HOST "systemctl status 'lecoffreio-*@*'"
+
+# Vérifier les logs
+ssh ncantu@$RECOVERY_TARGET_HOST "journalctl -u lecoffreio-backend@<domain> -n 100"
+```
+
+**Solutions** :
+
+- Vérifier les prérequis (Git, Node, services systemd) sur le serveur de récupération
+- Vérifier l'espace disque disponible
+- Vérifier que le dump de base de données est valide
+- Vérifier la configuration DNS
+
+#### Problème : DNS non propagé
+
+**Symptômes** :
+
+- Le script indique que le DNS n'est pas propagé
+- Le site n'est pas accessible via HTTPS
+
+**Diagnostic** :
+
+```bash
+# Vérifier l'enregistrement DNS actuel
+./deploy/scripts/backup/gandi-dns-api.sh get prod.lecoffreio.4nkweb.com
+
+# Vérifier la résolution DNS
+dig prod.lecoffreio.4nkweb.com @8.8.8.8
+
+# Vérifier depuis différents serveurs DNS
+nslookup prod.lecoffreio.4nkweb.com 8.8.8.8
+nslookup prod.lecoffreio.4nkweb.com 1.1.1.1
+```
+
+**Solutions** :
+
+- Attendre la propagation DNS (TTL peut être jusqu'à 600 secondes)
+- Vérifier que l'enregistrement DNS a bien été mis à jour via l'API
+- Vérifier les permissions de l'API Gandi
+
+#### Problème : Certificats SSL invalides
+
+**Symptômes** :
+
+- Erreur de certificat SSL lors de l'accès HTTPS
+- Certificats expirés
+
+**Solutions** :
+
+```bash
+# Sur le serveur de récupération, régénérer les certificats
+ssh debian@$RECOVERY_TARGET_HOST
+cd /home/debian/sites/lecoffreio.4nkweb.com
+bash deploy/scripts/build-and-deploy-local-cert.sh prod lecoffreio.4nkweb.com
+```
+
+### Procédures Avancées Disaster Recovery
+
+#### Restaurer une Sauvegarde Spécifique
+
+```bash
+# Lister les sauvegardes disponibles
+ssh debian@92.243.24.12 "ls -lh /var/lecoffreio/prod/backup-*.tar.gz"
+
+# Restaurer une sauvegarde spécifique
+./deploy/scripts/backup/disaster-recovery.sh backup-20250108-020000.tar.gz
+```
+
+#### Restaurer uniquement la Base de Données
+
+Si vous voulez restaurer uniquement la base de données (sans tout le reste) :
+
+```bash
+# Télécharger le backup
+scp debian@92.243.24.12:/var/lecoffreio/prod/backup-XXXXXX.tar.gz /tmp/
+
+# Extraire le dump
+tar xzf /tmp/backup-XXXXXX.tar.gz -C /tmp/extracted
+
+# Utiliser le script de reset avec le dump
+./deploy/scripts/reset-and-import-database.sh prod /tmp/extracted/database.dump
+```
+
+#### Vérifier l'Intégrité d'une Sauvegarde
+
+```bash
+# Télécharger le backup
+scp debian@92.243.24.12:/var/lecoffreio/prod/backup-XXXXXX.tar.gz /tmp/
+
+# Extraire et vérifier
+tar xzf /tmp/backup-XXXXXX.tar.gz -C /tmp/extracted
+ls -lh /tmp/extracted/
+
+# Vérifier le dump PostgreSQL
+file /tmp/extracted/database.dump
+
+# Vérifier les métadonnées
+cat /tmp/extracted/backup-metadata.json
+```
+
+### Sécurité Disaster Recovery
+
+#### Protection des Clés API
+
+- Les clés API Gandi sont stockées dans `.env.backup` (fichier non versionné)
+- Ne jamais commiter `.env.backup` dans Git
+- Limiter les permissions : `chmod 600 .secrets/.env.backup`
+
+#### Chiffrement (Optionnel)
+
+Si vous souhaitez chiffrer les sauvegardes :
+
+```bash
+# Chiffrer avant transfert
+gpg --symmetric --cipher-algo AES256 backup.tar.gz
+
+# Déchiffrer lors de la récupération
+gpg --decrypt backup.tar.gz.gpg > backup.tar.gz
+```
+
+### Bonnes Pratiques Disaster Recovery
+
+1. **Tests Réguliers** : Tester la récupération trimestriellement
+2. **Monitoring** : Surveiller les logs de sauvegarde quotidienne
+3. **Espace Disque** : Surveiller l'espace disque sur la VM Gandi
+4. **Documentation** : Documenter toute modification du processus
+5. **Validation** : Valider manuellement après chaque récupération
+
+### Informations Validées
+
+1. **Infrastructure VM Gandi** :
+   - Stockage : 250GB
+   - Machine cible : ssh debian@92.243.24.12
+
+2. **Stratégie de sauvegarde** :
+   - Environnement : prod uniquement
+   - Conservation : 7 versions
+
+3. **API Gandi** :
+   - Clé API : Fournie (stockée dans `.env.backup`)
+   - Permissions : Admin DNS
+   - Domaine : prod.lecoffreio.4nkweb.com
+
+4. **Récupération** :
+   - RTO (Recovery Time Objective) : 3 heures
+   - RPO (Recovery Point Objective) : 24 heures (sauvegarde quotidienne)
+
+5. **Sécurité** :
+   - Gestion des clés : Fichiers `.env.backup`
+   - Chiffrement : Non requis (infrastructure privée)
+
+---
+
+## Références
+
+### Documentation
+
+- **Architecture** : [ARCHITECTURE.md](./ARCHITECTURE.md)
+- **Reset base de données** : `docs/DATABASE_RESET_GUIDE.md`
+- **Scripts backend** : [SCRIPTS.md](./SCRIPTS.md)
+- **Monitoring** : Voir section "Monitoring" ci-dessus
+- **Disaster Recovery** : Voir section "Disaster Recovery" ci-dessus
+
+### Fichiers de configuration
+
+- **Configuration systemd** : `deploy/scripts_v2/systemd/*.service`
+- **Configuration Nginx** : `deploy/nginx/nginx-*.conf`
+- **Script de déploiement** : `deploy/scripts/build-and-deploy.sh`
+- **Fichiers d'injection BDD** : `.secrets/<env>/env-full-<env>-for-bdd-injection.txt`
+
+### Documentation externe
+
+- **Documentation Let's Encrypt** : <https://letsencrypt.org/docs/>
+- **Documentation Nginx** : <https://nginx.org/en/docs/>
+
+---
+
+## Git Workflow et Versioning
+
+Voir `deploy/README.md` pour les scripts. Format des commits : **Motivations**, **Root causes**, **Correctifs**, **Evolutions**, **Pages affectées**. Hooks : `.git/hooks/commit-msg`, `.git/hooks/pre-push`. Template : `.gitmessage`. Bump version : `./deploy/scripts/bump-version.sh <version> "<description>"` ; met à jour `VERSION`, `package.json` (backend + frontend), génère le template splash.
+
+**Auteur des commits :** L'auteur doit être **4NK** ou **Nicolas Cantu** uniquement. Ne jamais ajouter de ligne `Co-authored-by: Cursor` ni aucune ligne Co-authored-by qui ferait apparaître un auteur autre que 4NK ou Nicolas Cantu.
+
+---
+
+**Dernière mise à jour** : 2026-01-29 (consolidation DEPLOYMENT, MONITORING, DISASTER_RECOVERY, GIT_WORKFLOW, VERSIONING)
diff --git a/projects/lecoffreio/docs/FRONTEND.md b/projects/lecoffreio/docs/FRONTEND.md
new file mode 100644
index 0000000..981b494
--- /dev/null
+++ b/projects/lecoffreio/docs/FRONTEND.md
@@ -0,0 +1,1376 @@
+# Documentation Frontend - LeCoffre.io
+
+**Dernière mise à jour** : 2026-02-25
+
+Ce document regroupe toute la documentation frontend : routes, pages, UI/UX, et gestion des collaborateurs.
+
+---
+
+## 📋 Table des Matières
+
+1. [Routes et Navigation](#1-routes-et-navigation)
+2. [Pages et Composants](#2-pages-et-composants)
+3. [Corrections UI/UX](#3-corrections-uiux)
+4. [Agrégation des Collaborateurs](#4-agrégation-des-collaborateurs)
+5. [Build et Tests](#5-build-et-tests)
+6. [Authentification IdNot et Logging](#6-authentification-idnot-et-logging)
+7. [Interface Espace Notaire - Onglets et Tableaux](#7-interface-espace-notaire---onglets-et-tableaux)
+8. [Consolidation évolutions et correctifs](#8-consolidation-évolutions-et-correctifs)
+
+---
+
+## 1. Routes et Navigation
+
+### Routes de Dossiers
+
+#### Routes Actives
+
+- `/folders` - Liste des dossiers actifs
+- `/folders/[folderUid]` - Détail d'un dossier actif
+- `/folders/[folderUid]/add/clients` - Ajouter un client
+- `/folders/[folderUid]/add/third-party` - Ajouter un tiers
+- `/folders/[folderUid]/edit/informations` - Modifier les informations
+- `/folders/[folderUid]/edit/clients/[customerUid]` - Modifier un client
+- `/folders/[folderUid]/edit/collaborators` - Modifier les collaborateurs
+- `/folders/[folderUid]/documents-reminder-history` - Historique des rappels
+- `/folders/[folderUid]/send-documents` - Envoyer des documents
+- `/folders/[folderUid]/documents/[documentUid]` - Détail d'un document
+
+#### Routes Archivées
+
+- `/folders/archived` - Liste des dossiers archivés
+- `/folders/archived/[folderUid]` - Détail d'un dossier archivé
+
+#### Routes Supprimées
+
+- `/folders/deleted` - Liste des dossiers supprimés (soft delete)
+
+### Détection des Pages de Détail
+
+Le composant `FolderInformation` détecte automatiquement le type de route via la prop `isArchived`.
+
+**Regex de détection** :
+
+```typescript
+/\/folders\/(archived\/)?[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}/i
+```
+
+**Format accepté** :
+
+- `/folders/[uuid]` - Dossier actif
+- `/folders/archived/[uuid]` - Dossier archivé
+
+**Format rejeté** :
+
+- `/folders` - Liste des dossiers
+- `/folders/archived` - Liste des dossiers archivés
+
+**Fichiers concernés** :
+
+- `lecoffre-front-main/src/front/Components/Layouts/Folder/FolderInformation/index.tsx`
+- `lecoffre-front-main/src/pages/folders/[folderUid]/index.tsx`
+- `lecoffre-front-main/src/pages/folders/archived/[folderUid]/index.tsx`
+
+---
+
+## 2. Pages et Composants
+
+### Pages Identifiées pour Migration Collaborateurs
+
+#### UpdateFolderCollaborators ⚠️ PRIORITÉ HAUTE
+
+**Fichier** : `lecoffre-front-main/src/front/Components/Layouts/Folder/UpdateFolderCollaborators/index.tsx`
+
+**Action requise** : Utiliser l'endpoint `/api/v1/notary/users/aggregated` pour afficher tous les collaborateurs (avec et sans compte).
+
+**Page concernée** : `/folders/[folderUid]/collaborators`
+
+#### SubscriptionManageCollaborators ⚠️ PRIORITÉ HAUTE
+
+**Fichier** : `lecoffre-front-main/src/front/Components/Layouts/Subscription/Manage/SubscriptionManageCollaborators/index.tsx`
+
+**Action requise** : Utiliser l'endpoint agrégé et filtrer pour ne garder que ceux avec compte (car seuls les utilisateurs avec compte peuvent avoir un siège).
+
+**Page concernée** : `/subscription/manage-collaborators`
+
+#### DefaultCollaboratorDashboard ⚠️ PRIORITÉ MOYENNE
+
+**Fichier** : `lecoffre-front-main/src/front/Components/LayoutTemplates/DefaultCollaboratorDashboard/index.tsx`
+
+**Action requise** : Utiliser l'endpoint agrégé et filtrer pour ne garder que ceux avec compte, ou afficher deux sections : "Avec compte" et "À inviter".
+
+**Page concernée** : `/collaborators` (dashboard)
+
+#### CreateFolder
+
+**Fichier** : `lecoffre-front-main/src/front/Components/Layouts/Folder/CreateFolder/index.tsx`
+
+**État** : Depuis novembre 2025, le formulaire de création ne gère plus l'ajout de collaborateurs, de confrères ou de tiers. Les stakeholders initiaux se limitent automatiquement au créateur.
+
+---
+
+## 3. Corrections UI/UX
+
+### Boutons de Civilité Invisibles
+
+**Date** : 2025-01-27
+**Composant** : `AddClientToFolder`
+**Page** : `/folders/[folderUid]/add/clients`
+
+#### Problème
+
+Les 3 boutons de sélection de civilité (Monsieur, Madame, Autre) apparaissaient vides/invisibles dans le formulaire "Créer un nouveau client".
+
+#### Root Cause
+
+Le CSS de la classe `.civility-option` ne définissait pas de couleur de texte par défaut. Seule la classe `.civility-option-active` (bouton sélectionné) avait une couleur définie.
+
+#### Solution
+
+Ajout d'une couleur de texte par défaut (`var(--color-neutral-700)`) et d'un fond blanc pour garantir la visibilité du texte.
+
+**Fichiers modifiés** :
+
+- `lecoffre-front-main/src/front/Components/Layouts/Folder/AddClientToFolder/classes.module.scss`
+
+### Migration Sass : @import vers @use
+
+**Date** : 2025-01-30
+**Version** : 2.0.1+
+
+#### Objectif
+
+Éliminer les warnings de dépréciation Sass concernant l'utilisation de `@import` qui seront supprimés dans Dart Sass 3.0.0. Migrer tous les fichiers SCSS vers le système moderne `@use`/`@forward` de Sass.
+
+#### Modifications
+
+**Changement de syntaxe :**
+
+- **Avant** : `@import "@Themes/constants.scss";`
+- **Après** : `@use "@Themes/constants.scss" as *;`
+
+**Fichiers migrés** : 138 fichiers SCSS dans `lecoffre-front-main/src/`
+
+**Compatibilité** : L'utilisation de `as *` permet de conserver l'accès global aux variables Sass (`$screen-m`, `$screen-s`, `$color-*`) et aux variables CSS (`var(--...)`).
+
+**Documentation complète** : Voir conventions Sass du projet (ARCHITECTURE, OPTIMIZATION_AXES).
+
+### Bouton supprimer, parties rattachées, page add/clients (2026-01-28)
+
+**Pages** : `/folders/[folderUid]/add/clients`, fiche dossier.
+
+**Problèmes** : (1) Clic sur supprimer (X) à côté d'un client ne retire pas l'item ; (2) après validation, aucune partie sur la fiche dossier ; (3) après création dossier, add/clients reste sur « Dossier chargé mais données invalides » (GET folder sans `uid`).
+
+**Root causes** : Clés React en index (`GenericExistingItemsList`) → réutilisation de nœuds ; `preventDefault`/`stopPropagation` sur IconButton ; options avec `id` vide exclus du payload ; `instanceToPlain` omet `uid` sur GET `/notary/folders/:uid`.
+
+**Correctifs** : `getExistingItemKey` / `getPendingItemKey` stables (ex. `id`, `email`) ; `onClick` sans `preventDefault`/`stopPropagation` ; filtrage des clients `uid` non vide et collecte UIDs stricte dans `finalizePayloadHelpers` ; `OfficeFoldersGetOneByUidHydrationHelper` : forcer `plainFolder.uid = folderUid` après `instanceToPlain`. Textes retirés : « Rien n'est envoyé… », « Associez un ou plusieurs clients… ».
+
+**Fichiers** : `AddClientToFolder` (sections, `GenericExistingItemsList`, `CustomersList`), `useCustomersManager`, `finalizePayloadHelpers`, `OfficeFoldersGetOneByUidHydrationHelper`.
+
+### Invitation confrères – validation avant envoi email (2026-03-12)
+
+**Composant** : `AddClientToFolder` (onglet « Confrères »)
+**Page** : `/folders/[folderUid]/add/clients`
+
+**Problème** : Lors de l’ajout d’un confrère par email, le partage et l’email d’invitation étaient créés immédiatement au clic sur « Ajouter ». Si l’utilisateur cliquait ensuite « Annuler », le confrère restait invité et avait déjà reçu l’email.
+
+**Root cause** : Le flux confrères appelait `shareFolder` directement au clic « Ajouter », contrairement aux clients et tiers qui sont mis en attente puis persistés uniquement au clic « Valider ».
+
+**Correctifs** : Alignement sur le flux clients/tiers. Les confrères ajoutés sont stockés dans `pendingConfrereShares` ; l’API `shareFolder` et l’envoi d’email sont exécutés dans `addPendingConfrereShares` lors du `finalizeChanges`. Les confrères en attente sont affichés avec « Sera invité lors de la validation » et peuvent être retirés via `removePendingConfrere`.
+
+**Fichiers** : `useConfreresManager`, `finalizeOperationsHelpers`, `useFinalizeHandler`, `ExistingConfreresList`, `ConfreresSection`, `SearchConfrereSection`, `StakeholdersContent`, `types`.
+
+### Personne en charge du dossier – ContactBox et écran collaborateurs (2026-03-12)
+
+**Composant** : `ClientDashboard/ContactBox`, page « Modifier les collaborateurs »
+**Pages** : Espace client/tiers (contact de l’office), `/folders/[folderUid]/edit/collaborators`
+
+**Problème** : Dans l’espace client/tiers, les contacts de l’office affichés (email, téléphone) ne correspondaient pas à la personne en charge du dossier : le composant choisissait le contact de façon arbitraire parmi les stakeholders (priorité au rôle « Notaire », sinon premier de la liste). Aucune notion de « personne en charge » ou « interlocuteur principal » n’existait dans le modèle.
+
+**Root cause** : Pas de champ dédié dans le modèle de données ; ContactBox utilisait uniquement `stakeholders` (ordre non garanti).
+
+**Évolution** : Ajout de `main_contact_uid` sur le dossier (optionnel, FK vers `users`). La personne en charge est obligatoirement parmi les collaborateurs du dossier (stakeholders). Par défaut = créateur du dossier. Elle est choisie/modifiée dans l’écran « Modifier les collaborateurs » via un champ « Personne en charge » (liste = collaborateurs effectifs : tout l’office ou sélection). ContactBox affiche désormais : `main_contact` puis `created_by` puis notaire puis premier stakeholder.
+
+**Fichiers** : Prisma `office_folders.main_contact_uid` + relation `main_contact` ; ressources Notary `OfficeFolder` ; backend DTO, `FolderHandler` (validation), `OfficeFoldersUpdateBuilder`, `OfficeFoldersRepository` (create/update), `OfficeFoldersGetOneByUidHydrationHelper` ; frontend `folderQueryBuilders`, `useFolderAndCustomer`, `ClientDashboard/ContactBox`, `UpdateFolderCollaborators` (loader, controller, vue avec SelectField), `commonUiI18nPart1` (mainContactLabel). Migration : `20260312120000_add_main_contact_uid_to_office_folders`.
+
+### Autocomplétion Confrères – clic suggestion non sélectionné (2026-02-22)
+
+**Composant** : `AddClientToFolder` (onglet « Confrères »)
+**Page** : `/folders/[folderUid]/add/clients`
+
+**Problème** : Dans « Notaire (recherche annuaire) », cliquer une suggestion ferme la liste sans sélectionner le notaire.
+
+**Root cause** : La fermeture des suggestions était pilotée par `onBlur` sur le wrapper : le `blur` se déclenchait aussi lors d’un passage de focus interne (champ → suggestion), et la fermeture temporisée rendait l’événement de sélection non fiable (clic) et cassait le parcours clavier.
+
+**Correctifs** : `SearchConfrereSection` ferme les suggestions uniquement lorsque le focus sort réellement du wrapper (`relatedTarget` non contenu), et ferme aussi l’affichage des résultats côté hook via `setShowSuggestionsFromSearch(false)`.
+
+**Fichiers** :
+
+- `lecoffre-front-main/src/front/Components/Layouts/Folder/AddClientToFolder/sections/ConfreresSection/SearchConfrereSection.tsx`
+- Correctif autocomplétion Confrères : voir [README.md](./README.md#consolidation-operationnelle-ex-operationsmd) (clic suggestion non sélectionné).
+
+### Création dossier – membres rattachés n'apparaissent pas (2026-01-28)
+
+**Problème** : Après création d'un dossier avec collaborateurs, la section « Gestionnaire du projet » est vide sur add/clients et fiche dossier.
+
+**Root cause** : Les requêtes GET folder ne demandaient ni `stakeholders` ni `created_by`.
+
+**Correctifs** : Dans `buildFolderQueryParams` (FolderInformation / `useFolderDataFetch`) et dans le loader add/clients (`useFolderDataInitialization`), ajouter `created_by` et `stakeholders` avec includes `contact`, `office_role`, `seats` / `subscription` / `office`.
+
+### Création dossier – reste sur « Chargement du dossier… » (2026-01-28)
+
+**Problème** : Après création et redirection vers `/folders/:uid/add/clients`, la page reste bloquée sur chargement.
+
+**Causes** : (1) GET dossier sans timeout ; (2) `folderUid` absent au premier rendu (`router.query` pas encore à jour après `router.push`).
+
+**Correctifs** : Timeout 30 s sur le chargement (Promise.race) ; si timeout → toast, redirection `/folders`. Fallback `folderUid` : extraction par regex sur `router.asPath` (`/\/folders\/([^/]+)\/add\/clients/`) quand `query["folderUid"]` vide. Nettoyage des logs debug.
+
+**Fichiers** : `useFolderDataInitialization`, `useManageFolderStakeholdersController`, `createFolderSubmitHelpers`.
+
+### Dossier – membres absents sur la page détail (2026-01-28)
+
+**Problème** : Dossier créé avec client/tiers/notaire invité, mais page détail affiche « Ajouter des clients » (NoClientView) au lieu des onglets participants.
+
+**Root cause** : `instanceToPlain` peut omettre `customers` et `folder_sharings` ; `doesFolderHaveClient` reste faux.
+
+**Correctifs** : Dans `OfficeFoldersGetOneByUidHydrationHelper`, après `instanceToPlain`, forcer `customers` et `folder_sharings` dans le plain lorsqu'ils sont présents sur l'entité brute mais absents ou vides dans le plain (même logique que `uid`).
+
+**Correctif frontend (2026-03-09)** : voir `docs/fixKnowledge/2026-03-09-folder-detail-participants-hidden-without-customers.md`.
+
+### Création dossier – validation failure (2026-01-27 / 2026-01-28)
+
+**Problème** : « Dossier chargé mais données invalides », `uid` manquant en POST ou GET.
+
+**Root causes** : POST retournait une instance de classe au lieu d'un plain ; `instanceToPlain` pouvait omettre `uid`. GET idem.
+
+**Correctifs backend** : `OfficeFoldersCreationHelper` : `instanceToPlain` puis **toujours** `plainFolder.uid = officeFolderEntity.uid`. `OfficeFoldersGetOneByUidHydrationHelper` : forcer `uid` (et `customers` / `folder_sharings` / `notes` / `folder_number` si omis). Stripe 404 : `StripeController` + `StripeService.isStripeNotFoundError()` pour ne pas traiter 404 comme erreur utilisateur.
+
+**Correctifs frontend** : Logs debug dans `useFolderDataInitialization` et `createFolderSubmitHelpers` ; délai 2000 ms avant redirection. Vérifier en déploiement que le correctif `plainFolder.uid = officeFolderEntity.uid` est bien présent dans le build.
+
+### Notes membres (notaires / collaborateurs) non affichées dans les onglets (2026-01-29)
+
+**Problème** : Les notes n'apparaissent pas dans les onglets clients / notaires invités / tiers, mais sont visibles dans le formulaire de modification.
+
+**Root cause** : `instanceToPlain` peut omettre le tableau `notes` ; seul le forçage de `customers` et `folder_sharings` existait.
+
+**Correctifs** : Dans `OfficeFoldersGetOneByUidHydrationHelper`, forcer `plainFolder.notes = rawNotes` lorsque l'entité brute a des notes mais le plain les omet. Étendre `FilteredEntityForPostProcess` avec `notes`. Log « notes forcés (instanceToPlain les avait omis) ».
+
+### Supprimer un dossier – modale ne s'affiche pas / champ confirmation (2026-01-28)
+
+**Problème** : Clic « Supprimer le dossier » (menu ⋮) : modale semble ne pas s'ouvrir ou menu se ré-affiche par-dessus. Champ de confirmation : label « Confirmation » alors qu'il faut saisir le numéro de dossier → bouton grisé. Si `folder_number` absent, rien en gras.
+
+**Root causes** : (1) Clic sur l'item déclenche `onClose` puis `onClick` ; l'événement remonte au root du Menu → `toggle` ré-ouvre le menu. (2) Items sans `link` avaient `key={undefined}` → clés dupliquées. (3) Label et `expectedValue` du champ de confirmation peu clairs. (4) `folder_number` parfois omis par `instanceToPlain`.
+
+**Correctifs** : `MenuItem` : après `onClose` / `onClick` / navigation, appeler `e.stopPropagation()` si le clic est traité. Menu : clé stable `item.link ?? \`${item.text}-${index}\``. DeleteModal : label « Numéro du dossier (répétez ci‑dessus) », `expectedValue` = numéro, `errorMessage` explicite ; si numéro vide, pas de `requireConfirmation`. ConfirmModal : si `expectedValue` vide, afficher « La valeur à saisir n'est pas disponible. Actualisez la page puis réessayez. » et garder le bouton désactivé. Backend : forcer `folder_number` dans `OfficeFoldersGetOneByUidHydrationHelper` quand omis.
+
+**Fichiers** : `MenuItem`, `Menu`, `DeleteModal`, `ConfirmModal`, `OfficeFoldersGetOneByUidHydrationHelper`.
+
+### Stripe 404 – bannière abonnement (2026-01-29)
+
+**Problème** : `GET /api/v1/admin/stripe/:id` en 404 (abonnement absent chez Stripe) → Toast « L'élément demandé n'existe pas », warn « Unable to load subscription banner » à chaque chargement.
+
+**Root cause** : Aucune distinction 404 (ressource absente, cas acceptable) vs erreur technique ; `onError` systématique.
+
+**Correctifs** : `StripeFactory.getStripeSubscriptionByUid` : en catch, si `http_status === 404`, ne pas appeler `onError`, puis rejeter. `Header` / `useSubscriptionLoader` : en catch, si 404, retourner sans logger.
+
+**Fichiers** : `StripeFactory`, `Header/index.tsx`.
+
+### Demander les documents – configuration du type de document non chargée
+
+**Page** : « Demander des documents ».
+
+**Problème** : Aucun type de document à sélectionner ; configuration deed / deed_type non chargée ou non exploitée.
+
+**Root causes** : Backend : `instanceToPlain` peut omettre `deed` (et `deed.document_types`) ; aucun forçage de `deed`. Front : utilisation uniquement de `deed.document_types`, sans `deed_type.document_types` ni fallback lorsque toutes les sources sont vides.
+
+**Correctifs** : Backend (`OfficeFoldersGetOneByUidHydrationHelper`) : forcer `deed` (et `document_types`) dans la réponse lorsqu’ils sont présents sur l’entité brute mais omis par `instanceToPlain`. Front (`useAskDocumentsFolderData`) : inclure `deed_type` avec `document_types` dans le `q` du fetch ; priorité `deed_type.document_types` → `deed.document_types` → types déduits des documents existants ; si tout vide, fallback `DocumentTypes.getInstance().get({})` ; log lorsque le fallback est utilisé.
+
+**Fichiers** : `OfficeFoldersGetOneByUidHydrationHelper`, `useAskDocumentsFolderData`.
+
+---
+
+## 4. Agrégation des Collaborateurs
+
+### Vue d'Ensemble
+
+La fonctionnalité d'agrégation des collaborateurs retourne les **comptes utilisateurs existants** d'un office (créés lors de la première connexion OAuth IdNot).
+
+### API Endpoint
+
+#### `GET /api/v1/notary/users/aggregated`
+
+**Authentification** : Requise (JWT)
+**Permissions** : `authHandler`, `ruleHandler`
+
+**Description** : Retourne les collaborateurs de l'office disposant d'un compte utilisateur.
+
+**Réponse** :
+
+```json
+[
+  {
+    "uid": "uuid-user-1",
+    "idNot": "123456",
+    "contact": {
+      "uid": "uuid-contact-1",
+      "email": "notaire@example.com",
+      "first_name": "Jean",
+      "last_name": "Dupont",
+      "phone": "+33123456789",
+      "civility": "M."
+    },
+    "_metadata": {
+      "source": "users",
+      "has_user_account": true
+    }
+  }
+]
+```
+
+---
+
+## 11. Gestion des Documents
+
+### Visibilité et Affichage
+
+#### Documents Déposés (DEPOSITED)
+
+- **Pour le déposant** (Client, Tiers, Notaire Invité) :
+  - Le fichier **n'est pas affiché** (pas d'icône "œil", pas de téléchargement).
+  - Seule la ligne avec la date de dépôt est visible.
+  - Le module de dépôt n'est plus éditable pour empêcher la modification.
+  - Accès direct URL : Message "En attente de validation..." sans contenu.
+- **Pour le notaire en charge** :
+  - Accès complet (visualisation, validation, refus).
+
+#### Dépôt côté déposant (Client / Tiers / Notaire invité)
+
+- La section **Documents à envoyer** utilise le même module d'ajout que **Documents supplémentaires (facultatif)** : ouverture via **Ajouter un document**, gestion de la sélection locale (ajout/retrait), puis envoi explicite via **Déposer le document**.
+- Le dépôt n'est plus déclenché au glisser-déposer : le glisser-déposer alimente uniquement la sélection locale dans la modale.
+- Après validation du dépôt, le rafraîchissement garde le comportement de ligne existant dans le tableau (mise à jour de statut/date selon le document).
+- Les libellés de dépôt sont centralisés par contexte (`generic`, `modal`, `otherDocuments`, `rib`) dans `DesignSystem/helpers/fileUploadUiI18n.ts`, et les CTA communs de modales (`Annuler`, `Confirmer`) sont centralisés dans `DesignSystem/helpers/commonUiI18n.ts`.
+- Les libellés d'actions métier de modales/layouts (`Valider`, `Supprimer`, `Enregistrer`, `Créer`, `Ajouter`, `Continuer`, `Quitter`) sont regroupés dans les namespaces dédiés de `DesignSystem/helpers/commonUiI18n.ts` et réutilisés dans les modales existantes.
+- Les libellés métier composés sont regroupés par domaine dans `DesignSystem/helpers/commonUiI18n.ts` (`folder`, `subscription`, `member`, `role`) pour éviter les chaînes actionnelles locales dans les vues et menus.
+- Les CTA et labels de tests SuperAdmin sont aussi centralisés dans `commonUiI18n.ts` via les namespaces `health` et `adminTools`, y compris les libellés de titres secondaires d'actions (boutons détails, liens utilitaires, titres de consultation).
+- Les textes descriptifs non actionnels sont centralisés dans les namespaces `healthMessages`, `folderMessages`, `demoMessages`, `subscriptionMessages`, `userMessages`, `usersMessages` et `documentMessages` de `commonUiI18n.ts` (cartes de test SuperAdmin, modales d'archive/suppression dossier, sections de démonstration du DesignSystem, écrans abonnement, écrans utilisateurs et viewer documentaire).
+- Les placeholders et libellés de formulaires métier longs sont centralisés dans `formMessages` (`commonUiI18n.ts`) pour les flux de préparation de dossier (tiers, confrères) et d'envoi documentaire.
+- Les messages dynamiques sont composés par des helpers dédiés dans `DesignSystem/helpers/commonUiMessageBuilders.ts` pour éviter la concaténation dans les composants (`votes` SuperAdmin, message de dépôt en attente dans le viewer).
+- Les écrans dossier hors scope upload initial (`AddThirdParty`, `AskDocuments`, `Folder` landing, sections NoClient, modales de suppression client/document) sont alignés sur `folderMessages`/`formMessages` et réutilisent les helpers de composition pour les messages conditionnels de permissions/chargement.
+- Les messages "chargement dossier / droits insuffisants" passent par un helper dédié à objet de configuration (`buildFolderPermissionOrLoadingMessage`) et les modales de suppression mutualisent leurs feedbacks succès/erreur via des helpers dédiés.
+- Les flux de suppression utilisent des payload helpers dédiés par domaine : `buildDocumentDeleteModalPayload` (documents), `buildCustomerDeleteModalPayload` (client de dossier), `buildFolderDeleteModalPayload` (suppression dossier soft/hard), `buildThirdPartyDeleteModalPayload` (tiers du dossier), `buildRibDeleteModalPayload` (RIB) et `buildDeedTypeDeleteModalPayload` (type d'acte), avec centralisation de `title/message/confirmLabel` et des messages d'erreur.
+- La confirmation de suppression avec saisie du numéro de dossier est factorisée via `buildFolderDeleteRequireConfirmationPayload` pour éviter la duplication `label/placeholder/errorMessage` dans les modales.
+- Les anciens `alert()` des flux de téléchargement documents/certificats et création de dossier (helpers `FolderInformation`/`InvitedView`/`CreateFolder`) sont migrés vers `ToasterService` avec messages centralisés dans `commonUiI18n.ts` et composition d'erreur agrégée via `buildAggregatedCertificateErrorMessage`.
+- Le flux de désarchivage dossier n'utilise plus `confirm()`: il passe désormais par une `ConfirmModal` dédiée pilotée via `useFolderModals` (`unarchiveModal`) et payload `buildUnarchiveFolderConfirmPayload`.
+- Les erreurs de téléchargement ZIP/certificat sont unifiées via le helper global `showDownloadErrorToast` (`Utils/documentDownloadHelpers.ts`) et réutilisées dans `Folder` et `ClientDashboard`.
+- Les flux `SuperAdmin/SiteTexts` (create/update/publish/archive/load) n'utilisent plus `alert()/confirm()` : feedback via `ToasterService` + modale de confirmation d'archivage.
+- Les toasts de succès de téléchargement sont aussi centralisés via `showDownloadSuccessToast` dans `Utils/documentDownloadHelpers.ts` et réutilisés par les flux `Folder`, `ClientDashboard`, `singleFileDownloadHelper` et `DocumentDownloadService`.
+- Les toasts de succès métier hors téléchargement (create/update/publish/archive) sont harmonisés via `showBusinessSuccessToast` (`Utils/businessOperationToastHelpers.ts`) avec payload centralisé (`buildBusinessSuccessToastPayload`).
+- Les erreurs métier hors téléchargement sont harmonisées via `showBusinessErrorToast` (`Utils/businessOperationToastHelpers.ts`) avec payload builders par domaine (`collaboratorMessages`, `clientDashboardMessages`, `folderMessages`) pour éviter les descriptions codées en dur.
+- Les warnings métier hors téléchargement sont harmonisés via `showBusinessWarningToast` (`Utils/businessOperationToastHelpers.ts`) avec payload builders de domaine (`subscriptionMessages`, `folderMessages`) pour homogénéiser les flux d’information/validation.
+- Les flux `Folder/AskDocuments`, `Folder/SendDocuments` et `Folder/AddClientToFolder` utilisent désormais les mêmes helpers `showBusinessErrorToast`/`showBusinessWarningToast` et des builders dédiés `commonUiMessageBuilders.ts` pour supprimer les `ToasterService.getInstance().warn/error` métier locaux.
+- Les builders `folderMessages` sont regroupés par sous-domaines (`parameterDocuments`, `askDocuments`, `sendDocuments`, `stakeholders`) via `DesignSystem/helpers/folderToastMessageBuilders.ts` et exposés par `commonUiMessageBuilders.ts`.
+- Les builders non-folder sont aussi extraits par domaine pour limiter la croissance de `commonUiMessageBuilders.ts` :
+  - `DesignSystem/helpers/clientDashboardMessageBuilders.ts`
+  - `DesignSystem/helpers/clientDashboardToastMessageBuilders.ts`
+  - `DesignSystem/helpers/collaboratorToastMessageBuilders.ts`
+  - `DesignSystem/helpers/createCustomerNoteToastMessageBuilders.ts`
+  - `DesignSystem/helpers/siteTextsMessageBuilders.ts`
+  - `DesignSystem/helpers/siteTextsToastMessageBuilders.ts`
+  - `DesignSystem/helpers/subscriptionToastMessageBuilders.ts`
+  - `DesignSystem/helpers/deedTypesToastMessageBuilders.ts`
+  - `DesignSystem/helpers/folderInformationToastMessageBuilders.ts`
+  - `DesignSystem/helpers/folderViewDocumentsToastMessageBuilders.ts`
+  - `DesignSystem/helpers/toastPayloadBuilderHelpers.ts` : helper générique partagé pour construire les payloads error/warning/success (évite la répétition dans chaque `*ToastMessageBuilders`).
+  - `DesignSystem/helpers/toastMessageBuilders/index.ts` centralise le pattern de re-export des builders `*ToastMessageBuilders.ts`.
+  - `commonUiMessageBuilders.ts` conserve un re-export de compatibilité.
+- Les écrans `ClientDashboard/ViewDocumentSent`, `ClientDashboard/ViewDocumentsNotary` et `Folder/ViewDocuments` n’utilisent plus de `ToasterService.getInstance().error` inline pour les erreurs métier de chargement/validation.
+- Les layouts métier ciblés `Folder`, `ClientDashboard` et `DeedTypes` n’utilisent plus de `ToasterService.getInstance().warn/error` direct : les flux sont alignés sur `showBusinessErrorToast` / `showBusinessWarningToast` avec payloads centralisés.
+- Les succès métier peuvent aussi être injectés via payload (`title` + `description`) dans `showBusinessSuccessToast`, ce qui permet d’aligner `Folder/ViewDocuments` et `DeedTypes` sans libellés inline dans les hooks.
+- Les flux `subscription-plans` n'utilisent plus `alert()/confirm()` : confirmations via `ConfirmModal` + payload helpers (`buildSubscriptionPlanSetDefaultConfirmPayload`, `buildSubscriptionPlanDeleteConfirmPayload`) et feedback centralisé.
+- Les derniers usages résiduels de `alert()/confirm()` côté front ont été retirés, y compris dans la section de démonstration `ButtonIconMenuSection` et le fallback technique `ToasterHelper`.
+
+#### Documents Envoyés (SENT)
+
+- **Tableau "Documents envoyés"** : La colonne "Type de document" est renommée **"Nom du document"**.
+- **Notaire Invité** :
+  - Les documents de type "Document notaire" (envoyés par le notaire gestionnaire) sont **exclus** de la section "Documents à envoyer".
+  - Ils apparaissent uniquement dans "Documents reçus".
+  - L'encart de notification ("X documents reçus") est aligné avec le nombre réel de documents affichés (excluant les doublons techniques).
+
+#### Visualisation (Viewer)
+
+- **Sélection du fichier** : En cas de multiples fichiers (ex: refus puis re-dépôt), le viewer affiche par défaut le **plus récent** (tri par `created_at` desc), et non le premier de la liste (souvent l'ancien refusé).
+- **Batch** : L'affichage d'un document issu d'un batch (ex: pièce d'identité) ne montre que les fichiers de **ce document spécifique** (`docUid`), sans fusionner avec les autres documents du même batch.
+
+### Téléchargement
+
+#### Logique ZIP vs Fichier Unique
+
+- **Alignement** : La logique de téléchargement utilise le même dédoublonnage que l'affichage (`getUniqueFiles` dans `fileHelpers.ts`).
+- **Comportement** :
+  - Si **1 seul fichier unique** (après dédoublonnage par nom) : Téléchargement direct du fichier.
+  - Si **> 1 fichiers uniques** : Téléchargement d'un ZIP.
+  - Évite de créer un ZIP inutile pour un document qui n'a qu'une seule version pertinente visible.
+
+### Refactoring & Helpers
+
+- **`fileHelpers.ts`** : Centralise la logique de dédoublonnage (`getUniqueFiles`, `getFileDisplayName`) partagée entre l'affichage (`tableColumnHelpers`) et le téléchargement (`documentDownloadHelpers`).
+- **`documentFilterHelpers.ts`** : Centralise les statuts (`DOCUMENTS_TO_SEND_STATUSES`, etc.) pour garantir la cohérence entre les vues Client, Tiers et Invité.
+
+---
+
+## 5. Build et Tests
+
+- `npm run build` exécute désormais `npm run typecheck` puis `node ./scripts/run-next-build.cjs`. Ce script Node applique les variables d'environnement requises (`TURBOPACK_ROOT`, `NEXT_TELEMETRY_DISABLED`) avant d'invoquer `next build` via `next/dist/bin/next`. Cette approche garantit un comportement identique sous Windows (où les affectations `VAR=value` n'étaient pas interprétées par `cmd.exe`) et sous Linux/macOS.
+- Le fichier `lecoffre-front-main/scripts/run-next-build.cjs` est responsable du lancement de `next build`. Il doit être conservé à jour si des arguments supplémentaires sont nécessaires.
+
+### Convention de typage JSX (React 19)
+
+- Les composants fonctionnels utilisent `React.JSX.Element` (ou `React.JSX.Element | null` pour un rendu conditionnel).
+- Les composants de classe utilisent `render(): React.ReactNode`.
+- Les props de contenu (`children`, `title`, `text`, `icon`, `footer`, etc.) utilisent `React.ReactNode`.
+- Le shim global `declare namespace JSX` n'est plus utilisé dans `custom.d.ts`.
+- Les usages `JSX.Element` sont interdits dans le frontend pour éviter les incompatibilités de typage entre runtime JSX et React 19.
+
+### Stratégie couche API (useApiClient vs BaseApiService)
+
+- **useApiClient** (hook React) : cible pour tout appel API depuis un composant ou un hook. Gère le token, les erreurs et le base URL. Privilégier pour les nouveaux usages dans l’UI.
+- **BaseApiService / getInstance()** (services sous `LeCoffreApi/`) : utilisé par les factories (Folders, Documents, etc.) pour les appels hors composants (loaders, services partagés). Conservé pour compatibilité et contexte non-React.
+- **Déduplication** : réutiliser les builders de paramètres de requête (`@Front/Utils/folderQueryBuilders`, `documentQueryBuilders` dans ClientDashboard) pour éviter des `q` / `include` divergents entre écrans.
+- **Règle** : nouveau code dans un composant ou hook → préférer `useApiClient` ; code dans un service/factory existant → garder BaseApiService tant que la migration n’est pas planifiée.
+
+**Appliqué (dossiers notary)** : les appels API dossiers notary passent par `useApiClient` via le hook `useNotaryFoldersApi` et les helpers `@Front/Utils/notaryFoldersApiEndpoints` et `@Front/Utils/folderQueryBuilders`. Migrés : liste et détail (`useFolderListData`, `useFolderDataFetch`), mise à jour / suppression / création (`UpdateFolderMetadata`, `DeleteModal`, `DeleteFolderModal`, `createFolderSubmitHelpers`, `finalizePayloadHelpers`), chargement dossier (`useFolderDataInitialization`, `useAskDocumentsFolderData`), archive / unarchive / restore (`ArchiveModal`, `folderInformationControllerCallbacksHelpers` onUnarchive, `ArchiveAlertWarning`), collaborateurs et participants (`useFolderCollaboratorsLoader`, `useUpdateFolderCollaboratorsController`, `useParticipantDeletions`), envoi documents et invités (`dataLoaders` SendDocuments, `useInvitedCustomerFolders`), validation numéro dossier (`useFolderNumberValidation`), redirection auto (`useFolderAutoRedirect`), documents reçus invité (`useInvitedReceivedDocumentsController`), page corbeille (`pages/folders/deleted` : liste supprimés + restauration), en-tête client dossier (`UserFolderHeader`, refactor classe → FC). **Appliqué (dossiers customer)** : les appels API dossiers customer (clients, tiers, notaires invités) passent par `useApiClient` via le hook `useCustomerFoldersApi` et les helpers `@Front/Utils/customerFoldersApiEndpoints`. Migrés : liste et détail (`useCustomerFolders`, `useOfficeChangeRedirect`, `folderLoaders` SelectFolder), chargement dossier et client (`useFolderAndCustomer` ClientDashboard et ReceivedDocuments, `useClientAccountLoader`), notes (`useNoteLoaderUnified`), CreateCustomerNote (`loadFolderWithIncludes`, `useFolderAndCustomerLoader`, `loadAndProcessFolder`).
+
+### Utilisation Frontend
+
+#### Ancien Code
+
+```typescript
+const userQuery: IGetUsersParams = {
+  include: {
+    contact: {
+      select: {
+        first_name: true,
+        last_name: true,
+      },
+    },
+  },
+};
+
+const availableCollaborators = await Users.getInstance().get(userQuery);
+```
+
+#### Nouveau Code
+
+```typescript
+// Utiliser le nouvel endpoint aggregated
+const response = await axios.get('/api/v1/notary/users/aggregated', {
+  headers: { Authorization: `Bearer ${token}` }
+});
+
+const availableCollaborators = response.data;
+
+// Les collaborateurs sont déjà au bon format
+const selectOptions = availableCollaborators.map(collaborator => ({
+  label: `${collaborator.contact?.first_name} ${collaborator.contact?.last_name}`,
+  id: collaborator.uid,
+  // Optionnel : afficher une indication visuelle pour les collaborateurs sans compte
+  badge: collaborator._metadata?.has_user_account ? null : 'Pas de compte'
+}));
+```
+
+### Points d'Attention
+
+#### UID des Collaborateurs sans Compte
+
+Les collaborateurs sans compte ont un `uid` au format `sync:{idnot}`.
+
+**Important** : Ne jamais utiliser cet UID pour créer des enregistrements en base.
+
+```typescript
+// ❌ MAUVAIS
+await createStakeholder({
+  user_uid: collaborator.uid, // Si c'est "sync:123", ça va échouer
+  folder_uid: folderUid,
+});
+
+// ✅ BON
+if (collaborator._metadata?.has_user_account) {
+  await createStakeholder({
+    user_uid: collaborator.uid,
+    folder_uid: folderUid,
+  });
+} else {
+  // Créer le compte d'abord OU afficher un message
+  alert('Ce collaborateur doit d\'abord créer un compte');
+}
+```
+
+#### Gestion des Sièges d'Abonnement
+
+Les collaborateurs sans compte **ne peuvent pas** avoir de siège d'abonnement.
+
+Filtrer les collaborateurs pour n'afficher que ceux avec compte dans la gestion des sièges.
+
+### Migration Progressive
+
+L'ancien endpoint `/api/v1/notary/users` reste disponible pour assurer la compatibilité.
+
+La migration peut se faire progressivement composant par composant :
+
+1. `UpdateFolderCollaborators`
+2. `SubscriptionManageCollaborators`
+3. `CreateFolder`
+4. Autres composants utilisant la sélection de collaborateurs
+
+### Service API Frontend Recommandé
+
+**Fichier** : `lecoffre-front-main/src/front/Api/CollaboratorsService.ts`
+
+```typescript
+import { apiClient } from './ApiClient';
+
+export class CollaboratorsService {
+  static getInstance(): CollaboratorsService {
+    // Singleton pattern
+  }
+
+  async getAggregated(): Promise<AggregatedCollaborator[]> {
+    const response = await apiClient.get('/api/v1/notary/users/aggregated');
+    return response.data;
+  }
+
+  async getWithAccounts(): Promise<AggregatedCollaborator[]> {
+    const all = await this.getAggregated();
+    return all.filter(c => c._metadata.has_user_account === true);
+  }
+
+  async getWithoutAccounts(): Promise<AggregatedCollaborator[]> {
+    const all = await this.getAggregated();
+    return all.filter(c => c._metadata.has_user_account === false);
+  }
+}
+```
+
+---
+
+## 5. Architecture Technique
+
+### Wrapper jwt-decode
+
+**Date** : 2025-11-24
+**Version** : 2.0.1+
+**Dernière mise à jour** : 2025-11-24
+
+#### Problème
+
+Deux problèmes principaux ont été rencontrés avec `jwt-decode` v4 :
+
+1. **Turbopack (bundler Next.js 16)** : Détecte statiquement que `jwt-decode` v4 n'a pas d'export par défaut dans le build ESM, causant l'erreur :
+
+   ```text
+   Export default doesn't exist in target module
+   The export default was not found in module [project]/node_modules/jwt-decode/build/esm/index.js
+   ```
+
+2. **Environnement de build** : En build de production, TypeScript résout `jwt-decode` comme un module CJS (`/repo/lecoffre-front-main/node_modules/jwt-decode/build/cjs/index`), et détecte statiquement que la propriété `default` n'existe pas, causant l'erreur :
+
+   ```text
+   Property 'default' does not exist on type 'typeof import("/repo/lecoffre-front-main/node_modules/jwt-decode/build/cjs/index")'
+   ```
+
+#### Solution
+
+Un wrapper a été créé pour gérer les différences entre ESM et CJS, avec des assertions de type explicites pour garantir la sécurité TypeScript :
+
+**Fichier** : `lecoffre-front-main/src/front/Utils/jwtDecodeWrapper.ts`
+
+```typescript
+import * as jwtDecodeModule from "jwt-decode";
+
+// Type pour gérer les différentes formes d'export de jwt-decode
+type JwtDecodeFunction = (token: string) => unknown;
+
+// Type pour le module jwt-decode avec toutes ses formes possibles
+type JwtDecodeModuleType = JwtDecodeFunction | { default?: JwtDecodeFunction; jwtDecode?: JwtDecodeFunction } | Record<string, unknown>;
+
+// Type assertion pour gérer les différences entre ESM et CJS
+const jwtDecodeModuleAny = jwtDecodeModule as unknown as JwtDecodeModuleType;
+
+// Vérification à l'exécution pour déterminer comment accéder à la fonction
+// Utilisation de if/else explicites pour une meilleure inférence de type
+let jwtDecodeFunction: JwtDecodeFunction;
+
+if (typeof jwtDecodeModuleAny === "function") {
+	jwtDecodeFunction = jwtDecodeModuleAny as JwtDecodeFunction;
+} else {
+	const moduleObj = jwtDecodeModuleAny as Record<string, unknown>;
+	const defaultExport = moduleObj["default"];
+	const namedExport = moduleObj["jwtDecode"];
+	if (typeof defaultExport === "function") {
+		jwtDecodeFunction = defaultExport as JwtDecodeFunction;
+	} else if (typeof namedExport === "function") {
+		jwtDecodeFunction = namedExport as JwtDecodeFunction;
+	} else {
+		// Fallback: essayer d'utiliser le module directement
+		jwtDecodeFunction = jwtDecodeModuleAny as JwtDecodeFunction;
+	}
+}
+
+export const jwtDecode = jwtDecodeFunction as <T = unknown>(token: string) => T;
+```
+
+**Points clés de l'implémentation :**
+
+- Utilisation d'assertions de type explicites (`as JwtDecodeFunction`) pour garantir la sécurité TypeScript
+- Vérification à l'exécution (runtime) avec `typeof` avant les assertions pour garantir la sécurité
+- Utilisation de `if/else` explicites pour une meilleure inférence de type TypeScript
+- Support de plusieurs formats d'export :
+  - Fonction directe (CJS)
+  - Export default (ESM)
+  - Export nommé `jwtDecode`
+  - Fallback sur le module entier
+
+#### Utilisation
+
+**Avant** :
+
+```typescript
+import jwtDecode from "jwt-decode";
+const decoded = jwtDecode(token);
+```
+
+**Après** :
+
+```typescript
+import { jwtDecode } from "@Front/Utils/jwtDecodeWrapper";
+const decoded = jwtDecode(token);
+```
+
+#### Fichiers Modifiés
+
+- `lecoffre-front-main/src/front/Api/BaseApiService.ts`
+- `lecoffre-front-main/src/front/Services/TokenRefreshService/TokenRefreshService.ts`
+- `lecoffre-front-main/src/proxy.ts`
+- `lecoffre-front-main/src/front/Stores/ActiveOfficeStore.ts`
+
+#### Avantages
+
+- ✅ Compatible avec Turbopack (Next.js 16)
+- ✅ Gère automatiquement les différences ESM/CJS
+- ✅ Fonctionne en build de production (résolution CJS)
+- ✅ Évite les erreurs TypeScript statiques grâce à `as any`
+- ✅ Vérification à l'exécution pour déterminer le format d'export
+- ✅ Type-safe avec TypeScript (casting final)
+
+---
+
+## 6. Authentification IdNot et Logging
+
+### Logging des Données API IdNot au Login
+
+**Date** : 2025-01-XX
+**Version** : 2.0.1+
+
+#### Vue d'Ensemble
+
+Des logs détaillés ont été ajoutés dans la console du navigateur pour tracer les données API reçues d'IdNot lors du processus d'authentification, permettant de diagnostiquer les problèmes d'authentification et de suivre le flux complet.
+
+#### Logs Disponibles
+
+**Tous les environnements** :
+
+- Logs de la présence des tokens (hasAccessToken, hasRefreshToken) sans jamais logger les valeurs
+- Logs du JWT décodé avec informations utilisateur (userId, officeId, role, règles)
+- Logs des erreurs avec contexte détaillé
+
+#### Fichiers Concernés
+
+- `lecoffre-front-main/src/front/Api/Auth/IdNot/index.ts` : Service d'authentification IdNot avec logs
+- `lecoffre-front-main/src/front/Components/Layouts/LoginCallback/hooks/helpers/idNotAuthHelpers.ts` : Échange code → tokens (sans log des valeurs de tokens)
+- `lecoffre-front-main/src/front/Components/Layouts/LoginCallback/index.tsx` : Callback de login avec logs détaillés
+
+#### Exemples de Logs
+
+```text
+[Front] 🔄 [IdNot] Exchanging authorization code for JWT tokens
+[Front] ✅ [LoginCallback] IdNot tokens received, connecting user { hasAccessToken: true, hasRefreshToken: true }
+[Front] ✅ [LoginCallback] JWT decoded successfully { userId: "...", officeId: "...", role: "admin", hasRules: true, rulesCount: 15 }
+```
+
+#### Sécurité
+
+- ✅ Tokens (accessToken, refreshToken) jamais loggés, quel que soit l'environnement (risque de fuite via agrégation de logs)
+- ✅ Seuls les 10 premiers caractères du code d'autorisation sont loggés
+- ✅ Uniquement des indicateurs booléens (hasAccessToken, hasRefreshToken) sont loggés après réception des tokens
+
+**Documentation complète** : Voir ARCHITECTURE (Types d’utilisateurs, connexion IdNot) et logs IdNot au login.
+
+### Nettoyage silencieux des sessions expirées sur les pages publiques
+
+- Les appels publics (`BasePublic` → `SiteTextsApi`, `IncidentReportApi`) n'imposent plus de redirection vers `https://qual-connexion.idnot.fr/` quand un `leCoffreAccessToken` expiré est présent mais que le refresh token a disparu.
+- `BaseApiService.checkJwtToken()` détecte toujours le flag IdNot, mais `BasePublic` surcharge désormais `shouldEnforceIdNotLogoutOnExpiredSession()` pour renvoyer `false`. Le SDK se contente alors de supprimer les cookies locaux au lieu de forcer une navigation.
+- Toutes les API privées continuent de déclencher la redirection Id.Not dès que l'utilisateur tente d'appeler un endpoint protégé avec un token expiré ou invalide.
+- Cette séparation évite la "redirection instantanée" depuis `/` tout en conservant la synchronisation stricte des sessions sur les pages authentifiées.
+
+### Rafraîchissement automatique des sessions (2025-12)
+
+- Nouveau service `SessionRefreshService` démarré depuis `_app.tsx`
+- Lit en continu le refresh token (`leCoffreRefreshToken`) pour calculer sa date d'expiration (`exp`)
+- Programme un rafraîchissement 2 minutes avant l'expiration (fallback toutes les 10 minutes)
+- S'appuie sur `TokenRefreshService` (qui reçoit désormais un refresh token *rotated* à chaque appel)
+- Ré-écoute les événements `UserStore` / `CustomerStore` (`onConnect` / `onDisconnect`) pour relancer ou arrêter les timers quand un utilisateur change d'état
+- Empêche les expirations silencieuses malgré une activité continue dans l'UI, tout en journalisant les succès / échecs côté front
+
+---
+
+## 7. Interface Espace Notaire - Onglets et Tableaux
+
+### Refonte des onglets membres et tableaux documents
+
+**Date** : 2025-01-XX
+**Version** : 2.0.1+
+**Page** : `/folders/[folderUid]` - Vue ClientView
+
+#### Vue d'Ensemble
+
+Refonte complète de l'interface des onglets des membres et des tableaux de documents dans l'espace notaire pour améliorer la clarté et la conformité des documents.
+
+#### Modifications des Onglets Membres
+
+**Composants modifiés** :
+
+- `ClientView/ThirdPartyBox/index.tsx`
+- `ClientView/ClientBox/index.tsx`
+- `ClientView/SharedNotaryBox/index.tsx`
+
+**Changements** :
+
+1. **ThirdPartyBox** :
+   - ❌ Suppression du bouton "Renvoyer l'invitation"
+   - ❌ Suppression du bouton "Supprimer"
+   - ✅ Bouton unique "Modifier la note" (remplace le menu)
+
+2. **ClientBox** :
+   - ✅ Texte du bouton de note changé en "Modifier la note" (au lieu de "Rajouter/modifier une note")
+
+3. **SharedNotaryBox** :
+   - ✅ Texte du bouton de note changé en "Modifier la note"
+   - ✅ Menu conservé avec option "Modifier les informations" (si disponible)
+
+#### Modifications des Tableaux de Documents
+
+**Composants modifiés** :
+
+- `ClientView/DocumentTables/index.tsx`
+- `ClientView/DocumentTables/useDocumentTablesController.ts`
+- `ClientView/DocumentTables/hooks/useDocumentRows.tsx`
+- `ClientView/DocumentTables/helpers/tableHeaders.ts`
+- `ClientView/DocumentTables/helpers/documentConformity.ts`
+- `ClientView/DocumentTables/components/DocumentTablesHeader.tsx`
+- `ClientView/DocumentTables/components/ValidatedDocumentsSection.tsx`
+
+**Nouvelle fonctionnalité : Vérification de conformité**
+
+Un nouveau helper `documentConformity.ts` vérifie la conformité des documents :
+
+- **Lien IPFS** : Présence de `watermarked_s3_key` ou `file_path` dans les fichiers
+- **Ancrage** : Présence de `document_anchor`
+- **Données d'ancrage** : Présence de `document_anchor.proof_data`
+
+Si l'un de ces éléments manque, le statut du document devient **"NON CONFORME"**.
+
+**⚠️ Exception importante : Documents demandés (ASKED)**
+
+Les documents avec le statut `ASKED` (demandés mais pas encore déposés) ne sont **jamais vérifiés pour la conformité** car :
+
+- Ils n'ont pas encore de fichier déposé
+- Ils ne peuvent donc pas avoir de filigrane, d'ancrage ou de métadonnées
+- La vérification de conformité ne s'applique qu'aux documents déposés (`DEPOSITED`)
+
+Les documents ASKED affichent toujours le statut "DEMANDE" et jamais "NON CONFORME".
+
+**Nouveaux tableaux** :
+
+1. **"Documents demandés"** (sans nombre entre parenthèses) :
+   - **Statuts** : DEMANDES, A VALIDER, NON CONFORME
+   - **Colonnes** : Type de document, Statut, Déposé le, Action (voir)
+   - **Note** : Pas de colonne "Nom du document" car les documents ASKED n'ont pas encore de fichiers déposés
+   - **Note** : Pas de case à cocher pour les documents ASKED et DEPOSITED
+   - **Note** : Vérification de conformité uniquement pour les documents DEPOSITED (les documents ASKED affichent toujours "DEMANDE")
+   - **Fichier** : `useAskedDocumentsRows()` - Combine ASKED et DEPOSITED avec vérification conformité uniquement pour DEPOSITED
+   - **DEPOSITED (À VALIDER)** : L'icône « voir » (œil) est affichée pour le notaire afin de visualiser et valider le document. Pour le déposant (client/tiers/notaire invité), la ligne avec la date de dépôt reste visible mais le fichier n'est pas affiché ni modifiable sur la page de visualisation.
+
+2. **"Documents validés"** (sans nombre entre parenthèses) :
+   - **Statuts** : VALIDE, TELECHARGE, NON CONFORME
+   - **Colonnes** : case à cocher, Nom du document, Type de document, Déposé le, Action (télécharger, voir)
+   - **Boutons** : Télécharger ZIP et Télécharger Certificat (selon les coches)
+   - **Fichier** : `useValidatedDocumentsRows()` - Combine VALIDATED et DOWNLOADED avec vérification conformité
+
+3. **"Documents envoyés"** (sans nombre entre parenthèses) :
+   - **Statuts** : ENVOYE, NON CONFORME
+   - **Colonnes** : case à cocher, Nom du document, Statut, Déposé le, Action (télécharger, supprimer)
+   - **Boutons** : Télécharger ZIP et Télécharger Certificat (selon les coches)
+   - **Fichier** : `useSentDocumentsRows()` - Filtre SENT avec vérification conformité
+
+**Homogénéisation Documents envoyés (2026-03)** : Le notaire envoie de la même façon aux clients, tiers et notaires invités (emails différents selon le type). Affichage centralisé via `getSentDocumentsForTab()` : clients=DocumentsNotary, tiers=Documents(third_party_depositor), invités=Documents(shared_to_office). Envoi unifié via POST /notary/documents_notary/send (un appel par destinataire).
+
+**Modifications techniques** :
+
+- Suppression du compteur de progression dans `DocumentTablesHeader`
+- Suppression des nombres entre parenthèses dans les titres des sections
+- Ajout de cases à cocher pour la sélection multiple dans les tableaux "Documents validés" et "Documents envoyés"
+- **Homogénéisation récupération données** : `useDocumentTablesData` orchestre Documents et DocumentsNotary avec paramètres centralisés par onglet
+- **Centralisation onglets (2026-03)** : `useDocumentRowsData` extrait dans `hooks/useDocumentRowsData.ts` ; `filterDocumentsForTabMember` mutualise Asked/Refused ; `filterAndDeduplicateDocumentsByStatus` mutualise Validated (ClientView, InvitedView, ClientDashboard) ; `buildParticipantTab` factory pour participant tabs ; `filterOutDeletedDocuments` mutualise le filtrage des documents soft-deleted ; `hasDocumentWithDownloadableFile`/`filterDocumentsWithDownloadableFile` mutualise le filtrage documents avec fichier ; `deduplicateDocuments` déplacé vers module partagé ; `getDocumentNameFromFirstFile` mutualise l'extraction du nom ; `buildValidatedDocumentRow` factorise les 3 contextes (ClientView, InvitedView, ClientDashboard) ; renommage `documentFilterTabMemberHelpers` et `documentFilterToSendHelpers` pour clarifier les deux fichiers documentFilterHelpers
+- **Sélections indépendantes** : `selectedValidatedDocuments` et `selectedSentDocuments` pour éviter que la sélection dans une section n'affecte l'autre
+- Intégration de la vérification de conformité dans les hooks de génération de lignes (uniquement pour les documents avec fichiers)
+- Support des documents `DocumentNotary` avec statut DOWNLOADED dans "Documents validés"
+- **Colonnes conditionnelles** : Pas de colonne "Nom du document" pour "Documents demandés" (documents ASKED sans fichiers)
+- **Cases à cocher conditionnelles** : Pas de case à cocher pour les documents ASKED et DEPOSITED dans "Documents demandés"
+
+**Fichiers créés** :
+
+- `ClientView/DocumentTables/helpers/documentConformity.ts` : Fonctions de vérification de conformité
+
+**Fichiers modifiés** :
+
+- `ClientView/DocumentTables/index.tsx` : Réorganisation des sections, ajout des boutons pour documents envoyés, sélections indépendantes
+- `ClientView/DocumentTables/useDocumentTablesController.ts` : Ajout de deux sélections séparées (`selectedValidatedDocuments`, `selectedSentDocuments`)
+- `ClientView/DocumentTables/hooks/useDocumentRows.tsx` : Refonte complète des hooks pour les nouveaux tableaux avec colonnes conditionnelles
+- `ClientView/DocumentTables/hooks/useDocumentRowsData.ts` : Orchestration des lignes (Asked, Validated, Sent, Refused) et calcul progression
+- `ClientView/DocumentTables/helpers/documentFilterHelpers.ts` : `filterDocumentsForTabMember` pour Asked/Refused
+- `ClientView/DocumentTables/helpers/documentFilterStatusHelpers.ts` : `filterAndDeduplicateDocumentsByStatus` pour Validated
+- `ClientView/DocumentTables/helpers/documentFilterDeletionHelpers.ts` : `filterOutDeletedDocuments` pour documents soft-deleted (documentsDataLoader, receivedDocumentsLoaderHelpers)
+- `ClientView/DocumentTables/helpers/documentFilterFilesHelpers.ts` : `hasDocumentWithDownloadableFile`, `filterDocumentsWithDownloadableFile`
+- `ClientView/DocumentTables/helpers/documentDeduplicationHelpers.ts` : `deduplicateDocuments`
+- `ClientView/DocumentTables/helpers/documentFilterTabMemberHelpers.ts` : `filterDocumentsForTabMember`, `filterDocumentByActiveMember` (ex-documentFilterHelpers)
+- `ClientDashboard/helpers/documentFilterToSendHelpers.ts` : `filterDocumentsToSend`, constantes statuts (ex-documentFilterHelpers)
+- `ClientView/helpers/participantTabsHelpers.tsx` : `buildParticipantTab` factory
+- `ClientView/DocumentTables/helpers/tableHeaders.ts` : Mise à jour des en-têtes de tableaux
+- `ClientView/DocumentTables/components/DocumentTablesHeader.tsx` : Suppression du compteur
+- `ClientView/DocumentTables/components/ValidatedDocumentsSection.tsx` : Suppression du nombre dans le titre
+
+---
+
+## 8. Consolidation évolutions et correctifs
+
+Cette section consolide les éléments issus des documents de travail intégrés dans la documentation frontend pérenne.
+
+### Upload, contexte utilisateur et tables
+
+- Le module d'upload “Ajouter un document” est unifié entre documents à envoyer et documents supplémentaires avec sélection locale avant envoi explicite.
+- Helpers clés : `Utils/documentUploadByRoleHelper.ts`, `Utils/userContextResolver.ts`, `Hooks/useResolvedUserContext.ts`, `DesignSystem/DepositOtherDocument`.
+- Le routage des uploads par rôle est centralisé (`customer`, `third_party`, `invited_notary`) et les contrats de dépôt sont typés.
+- La résolution de contexte utilisateur (dashboard, vues document, sélection de dossier) est mutualisée via des helpers/hook dédiés.
+- Les wrappers legacy ont été alignés sur des composants partagés pour réduire les branches spécifiques par rôle.
+- Les textes et colonnes des tableaux de documents reçus sont construits via des builders mutualisés.
+- L'identité des onglets membres (`customer`/`third_party`/`shared notary`) est unifiée avec helpers dédiés pour navigation et sélection.
+
+### Téléchargements et nommage
+
+- Le téléchargement des documents demandés côté notaire est aligné sur un flux PDF unique (et non ZIP par défaut).
+- Le dédoublonnage des noms de fichiers est renforcé (normalisation Unicode + normalisation extension `.pdf`) pour stabiliser la décision ZIP/PDF.
+- Le nommage ZIP multi-téléchargement suit le format dossier/tableau (`<folder_number>.<nom du tableau>.(validé).zip`).
+- Les fichiers validés téléchargés (tableau Documents validés, page visualisation, côté tiers/clients/notaire invité) ont le suffixe ` (validé)` avant l’extension (ex. `document (validé).pdf`). S’applique aux statuts VALIDATED, SENT, DOWNLOADED.
+
+### Correctifs de fiabilité frontend
+
+- Migration des signatures JSX vers les conventions React 19 (`React.JSX.Element`, `React.ReactNode`) et suppression de la dépendance au shim global JSX.
+- Nettoyage des `console.log` oubliés au profit de `LoggerService`.
+- Suppression du code mort ID360 (routes, composants, API front inutilisés).
+
+### Upload : fusion systématique et page de métadonnées
+
+Tous les uploads (1 ou plusieurs fichiers) sont fusionnés et incluent la page de métadonnées (hash des fichiers originaux) dans le PDF filigrané. FileUploadHelper, ThirdPartyUploadService, GuestNotaryDocumentService, RIB, POST /notary/documents_notary : toujours fusion via FileMergeService. Module Deposit unifié : DepositContent partagé, configs par scope (documents, rib, sendDocuments).
+
+### Retour sur l'onglet membre après modification
+
+Après validation ou annulation lors de la modification des informations d'un membre (client, tiers, notaire invité), le backwardPath inclut les paramètres d'onglet (customerUid, thirdPartyUid, shareUid) pour que useParticipantTabs sélectionne le bon onglet. Fichiers : participantTabNavigationHelpers.appendQueryParam, useUpdateClientController, useUpdateSharedNotaryController, updateThirdPartyFormHelpers.
+
+### Restriction téléchargement/visualisation tableaux notaires
+
+Dans les onglets clients/tiers/notaires invités du dossier (vue notaire propriétaire) : documents DEPOSITED (À VALIDER) affichent l'icône œil pour que le notaire puisse visualiser et valider ; documents REFUSED n'affichent pas d'icône œil. Documents VALIDATED et SENT conservent téléchargement et visualisation. Page ViewDocuments : showDownload limité aux documents VALIDATED, SENT, DOWNLOADED. Espaces clients, tiers, notaires invités non impactés.
+
+### Centralisation aperçu fichiers (file preview)
+
+Helpers centralisés dans `@Front/Utils/filePreviewHelpers.ts` : FilePreviewState, createFilePreviewState, revokeFileUrl, loadFilePreviewDocumentNotary, loadFilePreviewDocument. ViewDocumentsNotary et ViewDocumentSent utilisent ces helpers. Variables SCSS : $document-preview-min-height, $document-file-container-min-height dans @Themes/constants.scss.
+
+## 8. Opérations Batch Frontend
+
+### Envoi Batch Documents
+
+**Frontend** :
+
+- **Page** : `/folders/[folderUid]/send-documents`
+- **Composant** : `SendDocuments`
+- **Fonctionnalités** : Sélection multiple + progression
+
+### Filtres Avancés
+
+**Frontend** :
+
+- **Page** : `/folders/select` (sélection avec filtres)
+- **Autocomplétion** : Recherche via appels API (IdNot/Annuaire) et dans `third_parties`
+
+### Certificat Agrégé Documents
+
+**Frontend** :
+
+- Bouton "Télécharger Certificat" dans les tableaux de documents
+- Disponible pour les documents validés et les documents envoyés
+- Vérification que tous les documents sélectionnés sont ancrés
+
+**ZIP** :
+
+- Les ZIP téléchargés incluent automatiquement le certificat agrégé si des documents ancrés sont présents
+- Support séparé pour Documents et DocumentsNotary (deux certificats si nécessaire)
+
+---
+
+## 9. Envoi de Documents par Notaires Invités
+
+**Statut** : ✅ 100% | **Version** : 2.0.1
+
+### Vue d'Ensemble
+
+Les modifications permettent aux notaires invités de créer des documents avec `shared_to_office_uid` pointant vers l'office du notaire propriétaire (au lieu de leur propre office). Ces documents ont le statut `DEPOSITED` et sont visibles par le notaire propriétaire.
+
+### ClientView - DocumentTables (Notaire propriétaire)
+
+**Impact** : ✅ Géré
+
+- Les documents créés par les notaires invités avec `shared_to_office_uid` pointant vers l'office du notaire propriétaire apparaissent maintenant dans les onglets des membres du dossier
+- Modification dans `useDocumentTablesController.ts` : ajout de la condition `shared_to_office: { uid: folderOfficeUid }` dans la clause OR
+
+### InvitedView (Notaire invité)
+
+**Impact** : ✅ Géré
+
+- Nouvelle section "Documents à envoyer" pour les documents ASKED
+- Nouvelle section "Documents supplémentaires" pour créer des documents "Autres documents"
+- Les documents créés apparaissent dans la section appropriée
+
+### Points de Vigilance
+
+#### Distinction entre documents envoyés PAR et envoyés AU notaire invité
+
+Les documents avec `shared_to_office_uid` peuvent être :
+
+- **Envoyés PAR le notaire propriétaire AU notaire invité** : `shared_to_office_uid` = office invité, statut SENT, pas de depositor
+- **Envoyés PAR le notaire invité AU notaire propriétaire** : `shared_to_office_uid` = office propriétaire, statut DEPOSITED, pas de depositor
+
+**Impact** : La logique de filtrage doit distinguer ces deux cas selon le contexte (InvitedView vs ClientView)
+
+#### Documents "Autres documents" créés par les notaires invités
+
+Les documents créés via "Documents supplémentaires" ont :
+
+- Type : "Autres documents"
+- Statut : DEPOSITED
+- `shared_to_office_uid` : office du notaire propriétaire
+
+**Impact** : Ces documents doivent être visibles par le notaire propriétaire dans les onglets des membres, mais pas dans les onglets des notaires invités
+
+### Emails et Notifications
+
+**Comportement** : ✅ Pas d'impact (comportement attendu)
+
+- `sendDocumentEmails()` ne gère que les statuts ASKED, REFUSED (VALIDATED désactivé)
+- **Documents DEPOSITED** : Les documents créés par les notaires invités pour le notaire propriétaire ont le statut DEPOSITED et **ne génèrent pas d'email**
+- **Raison** : Le notaire gestionnaire du dossier verra le document dans son interface sans avoir besoin d'une notification par email
+
+---
+
+## 10. Mutualisation des Espaces Client / Tiers / Dossiers Invités
+
+**Statut** : ✅ COMPLÉTÉ | **Version** : 2.0.0
+
+### Vue d'Ensemble
+
+Réduction de la duplication de code entre les trois espaces utilisateurs tout en préservant leurs spécificités fonctionnelles.
+
+### Résultats
+
+- **5 composants/services/helpers génériques** créés
+- **7 fichiers** refactorisés
+- **~1190 lignes** de code dupliqué → **~980 lignes** mutualisées
+- **~82% de réduction** du code dupliqué
+- **0 régression** : tous les comportements préservés
+
+### Mutualisations Implémentées
+
+#### Phase 1 : Composants UI
+
+**1. GenericDocumentsToSendSection**
+
+- **Fichier** : `components/GenericDocumentsToSendSection.tsx`
+- **Réduction** : ~290 lignes → ~15 lignes par wrapper
+- **Utilisation** : ClientDashboard, InvitedView
+- **Spécificités** : Exclusion "Document notaire", gestion refusedDocuments, styles personnalisés
+
+**2. GenericReceivedDocumentsPage**
+
+- **Fichier** : `components/GenericReceivedDocumentsPage.tsx`
+- **Réduction** : ~300 lignes → ~60 lignes par wrapper
+- **Utilisation** : ClientDashboard, InvitedView
+- **Spécificités** : Colonnes configurables, tracking personnalisé, routes flexibles
+
+**2.b. ReceivedDocumentsNotification**
+
+- **Fichier** : `ClientDashboard/components/ReceivedDocumentsNotification.tsx`
+- **Utilisation** : ClientDashboardHeader, InvitedViewContent
+- **Spécificités** : même composant, seul le texte métier (votre notaire / confrère) change selon l'espace
+
+**2.c. Legacy ReceivedDocuments wrapper alignment**
+
+- **Fichier** : `ClientDashboard/ReceivedDocumentsSection.tsx`
+- **Utilisation** : wrapper legacy aligné sur les helpers partagés du centre
+- **Spécificités** : calcul des documents reçus/counters délégué à `ClientDashboard/helpers/receivedDocumentsCenterHelpers.ts`
+
+**2.d. Received labels builder**
+
+- **Fichiers** :
+  - `DesignSystem/helpers/commonUiI18n.ts`
+  - `DesignSystem/helpers/commonUiMessageBuilders.ts`
+- **Utilisation** : `ClientDashboardHeader`, `InvitedViewContent`, `ReceivedDocumentsSection`
+- **Spécificités** : textes "documents envoyés par ..." centralisés via builders selon le contexte (`notary` / `peerNotary`)
+
+**2.e. ReceivedDocumentsTextContext**
+
+- **Fichier** : `DesignSystem/helpers/commonUiMessageBuilders.ts`
+- **Type** : `ReceivedDocumentsTextContext`
+- **Spécificités** :
+  - contexte explicite (`sender`) pour la source métier,
+  - stratégie de grammaire (`pluralStrategy`) pour singular/plural (`strict`/`inclusive`),
+  - réutilisé pour notifications, titres de pages "Documents reçus" et noms de ZIP.
+
+**2.f. Table Presets Builder**
+
+- **Fichier** : `Layouts/helpers/tablePresetsBuilder.ts`
+- **Utilisation** :
+  - Wrappers reçus: `ClientDashboard/ReceivedDocuments/index.tsx`, `InvitedView/ReceivedDocuments/index.tsx`
+  - Tables dossier: `DocumentTables/helpers/tableHeaders.ts`, `DocumentsReminderHistory/index.tsx`
+  - Sections non-dossier: `Layouts/DesignSystem/sections/TableSection.tsx`, `Layouts/SuperAdmin/SiteTexts/constants.ts`
+- **Spécificités** :
+  - source unique des intitulés partagés `Nom`, `Type de document`, `Statut`, `Envoyé le`, `Action`
+  - presets de colonnes prêts à l’emploi : `buildReceivedDocumentsColumnTitles()`, `buildDefaultReceivedDocumentsColumns()`, `buildDetailedReceivedDocumentsColumns()`, `buildDocumentTypeStatusActionHeaders()`, `buildDocumentTypeStatusSentAtActionHeaders()`, `buildNameStatusSentAtActionHeaders()`, `buildDocumentTypeStatutHeaders()`, `buildStatusActionHeaders()`.
+
+#### Phase 2 : Services
+
+**3. DocumentDownloadService**
+
+- **Fichier** : `Services/DocumentDownloadService/DocumentDownloadService.ts`
+- **Réduction** : ~400 lignes dupliquées → service centralisé (~350 lignes)
+- **Utilisation** : ClientDashboard, InvitedView, tous les téléchargements
+- **Fonctionnalités** :
+  - Téléchargement individuel et groupé
+  - Marquage comme "vu" selon contexte
+  - Gestion d'erreurs et toasts uniforme
+  - Support de tous les types de documents
+  - Dépôt multi-fichiers (ClientDashboard) : envoi batch unique par document pour client, tiers et notaire invité afin de déclencher la fusion backend en un PDF unique
+  - Dispatch d’upload unifié par rôle via `Utils/documentUploadByRoleHelper.ts` (réutilisé par ClientDashboard et DepositOtherDocument)
+  - Un dépôt multi-fichiers sur un document produit un unique PDF fusionné actif côté backend (les anciens fichiers actifs du document sont archivés)
+  - Les formulaires HTML génériques utilisent un helper d’extraction dédié `DesignSystem/Form/helpers/formValueExtractionHelpers.ts` (source unique pour la collecte des valeurs `FormData`)
+  - La couche legacy `BaseApiServiceRequests` est supprimée : le socle API transite désormais via `BaseApiServiceFactory` et ses helpers partagés
+  - Les query params complexes (`q`, objets sérialisés) sont centralisés via `Api/helpers/queryParamHelpers.ts` et réutilisés dans les builders d’endpoints dossiers notary/customer
+  - Les payloads fichiers/téléchargements (download multiple, aggregated certificate, send documents) sont centralisés via `Api/LeCoffreApi/helpers/fileRequestPayloadHelpers.ts`
+  - Les payloads JSON métier récurrents (hors fichiers) sont centralisés via `Api/LeCoffreApi/helpers/businessRequestPayloadHelpers.ts` et réutilisés par les modules Documents, Customers, FolderSharing et DocumentReminders
+  - L’harmonisation est étendue aux modules SuperAdmin (`SiteTexts`, `Health`, `Folders`) avec réutilisation des builders partagés `buildEmptyPayload`, `buildPayloadOrEmpty` et `buildStatusUpdatePayload`
+  - Les builders CRUD typés par domaine (`documents`, `folders`, `users`) sont appliqués aux factories `Admin/SuperAdmin` restantes (`DocumentsFactory`, `UsersFactory`) pour homogénéiser les payloads create/update
+  - Les builders CRUD typés sont étendus aux domaines `deeds`, `deedTypes`, `documentTypes`, `roles`, `customers` et appliqués uniformément dans les factories/helpers `Admin`, `Notary`, `SuperAdmin`
+  - Les domaines restants `officeRoles`, `stripe`, `files`, `notifications`, `health`, `liveVotes` sont aussi alignés via des builders dédiés dans `Api/LeCoffreApi/helpers/businessRequestPayloadHelpers.ts` (suppression des payloads inline restants dans leurs factories/helpers)
+  - Une convention transversale de suppression par identifiant est ajoutée via `buildDeletePayloadByUid(...)`, puis déclinée en wrappers métier (`buildLiveVotesDeletePayload(...)`) pour compléter la convention CRUD (`create/update/archive/restore/delete`)
+  - La vérification des helpers UI/API récemment touchés est exécutée (lint + typecheck), sans régression de signature détectée
+
+**3.b. Office RIB consultation hook**
+
+- **Fichier** : `ClientDashboard/hooks/useOfficeRibDownload.ts`
+- **Utilisation** : `ClientDashboard/ContactBox`, `Folder/FolderInformation/InvitedView/InvitedViewContent`
+- **Spécificités** : chargement et téléchargement RIB unifiés pour client, tiers et notaire invité
+
+#### Phase 3 : Helpers
+
+**4. documentFilterHelpers**
+
+- **Fichier** : `ClientDashboard/helpers/documentFilterHelpers.ts`
+- **Constantes (source unique)** :
+  - `DOCUMENTS_TO_SEND_STATUSES` : ASKED, REFUSED, VALIDATED (« Documents à envoyer » ; DEPOSITED, SENT, DOWNLOADED exclus).
+  - `DOCUMENT_STATUSES_RECEIVED_FROM_NOTARY` : SENT, DOWNLOADED (table documents).
+  - `DOCUMENT_NOTARY_STATUSES_RECEIVED_FROM_NOTARY` : SENT, DOWNLOADED (table documents_notary).
+- **Fonction exportée** :
+  - `statusUpper(s)` : normalise le statut en majuscules (comparaisons API).
+- **Fonctions** :
+  - `filterDocumentsToSend` : Filtrage « Documents à envoyer » (utilise DOCUMENTS_TO_SEND_STATUSES).
+  - `filterValidThirdPartyDocuments` : Filtrage documents tiers valides par customerUid.
+  - `deduplicateDocuments` : Suppression doublons par uid.
+- **Autres filtres (autres fichiers)** : `filterDocuments` dans `DocumentTables/helpers/documentTablesDataHelpers.ts` ; `filterReceivedDocuments` dans `InvitedView/ReceivedDocuments/helpers/receivedDocumentsFilterHelpers.ts` et `InvitedView/helpers/filterReceivedDocuments.ts`.
+- **Visualisation documents envoyés (tiers)** : en « Documents reçus », le clic œil ouvre la page de visualisation du Document (table documents) pour les tiers ; route `ClientDashboard.ViewDocument` → `/client-dashboard/[folderUid]/document/[documentUid]` ; composant `ViewDocumentSent` (Documents.getByUid, Files.download, DocumentViewer, markAsViewed). Les clients restent sur ViewDocumentsNotary (DocumentNotary).
+
+**5. documentQueryBuilders**
+
+- **Fichier** : `ClientDashboard/helpers/documentQueryBuilders.ts`
+- **Builders** :
+  - `buildCustomerDocumentsQuery` : Requêtes ClientDashboard (client et tiers) ; utilise `DOCUMENTS_TO_SEND_STATUSES` pour « Documents à envoyer ».
+  - `buildDocumentsInclude` : Construction clauses include (files, document_anchor, document_history, document_type, depositor/third_party_depositor, folder).
+
+**6. Validated documents shared wrapper**
+
+- **Fichier** : `ClientDashboard/components/ValidatedDocumentsListWrapper.tsx`
+- **Utilisation** : `ClientDashboard/components/ValidatedDocumentsSection.tsx`, `Folder/FolderInformation/InvitedView/components/InvitedDocumentsSection.tsx`
+- **Spécificités** : source unique de filtrage `VALIDATED` + normalisation `uid` avant rendu `ValidatedDocumentsListSection`
+
+**7. Received counters source unique**
+
+- **Fichier** : `ClientDashboard/helpers/receivedDocumentsCenterHelpers.ts`
+- **Utilisation** : `ClientDashboard/ReceivedDocumentsSection.tsx` et `ClientDashboard/useClientDashboardDocuments.ts`
+- **Spécificités** : total + unread calculés via le même helper pour client et tiers
+
+**8. Received ZIP naming builder**
+
+- **Fichiers** :
+  - `DesignSystem/helpers/commonUiMessageBuilders.ts`
+  - `Layouts/Folder/FolderInformation/ClientView/DocumentTables/helpers/zipDownloadHelpers.ts`
+  - `Services/DocumentDownloadService/DocumentDownloadService.ts`
+- **Spécificités** : nommage ZIP centralisé et aligné au contexte (`notary` / `peerNotary`) au lieu de chaînes inline.
+
+**9. Extended contextual document labels**
+
+- **Fichier** : `DesignSystem/helpers/clientDashboardMessageBuilders.ts`
+- **Builders** :
+  - `buildAdditionalDocumentsDescription(...)`
+  - `buildAskDocumentsPageTitle(...)`
+  - `buildReceivedDocumentsTransferLabel(...)`
+- **Utilisation** :
+  - `ClientDashboard/AdditionalDocumentsSection.tsx`
+  - `InvitedView/components/InvitedAdditionalDocumentsSection.tsx`
+  - `Folder/AskDocuments/hooks/useAskDocumentsPermissions.ts`
+  - `DocumentTables/helpers/documentTablesDownloadHelpers.ts`
+
+**10. Design identique partie centrale (client / tiers / notaires invités)**
+
+- **Objectif** : Aligner la présentation et l’ordre des sections dans les espaces client, tiers et notaires invités.
+- **Ordre unifié** : Documents envoyés par le notaire (encart) → RIB → Documents à envoyer (incl. refusés) → Documents validés → Documents supplémentaires (facultatif).
+- **Fichiers modifiés** :
+  - `ClientDashboard/index.tsx` : ValidatedDocumentsSection affiché pour client et tiers (plus seulement tiers).
+  - `ClientDashboard/DocumentsToSendSection.tsx` : `excludeValidated={true}` pour client et tiers (documents validés dans section dédiée).
+  - `InvitedView/components/InvitedViewContent.tsx` : ordre des sections (ReceivedDocumentsNotification avant RIB).
+  - `InvitedView/classes.module.scss` : classes `.documents`, `.content`, `.rib-actions`, `.deposit-documents` alignées sur ClientDashboard.
+  - `InvitedView/components/InvitedDocumentsToSendSection.tsx` : `wrapperClassName`/`contentClassName` identiques à ClientDashboard.
+  - `InvitedView/components/InvitedAdditionalDocumentsSection.tsx` : `showWrapper={false}`, typo par défaut pour cohérence.
+- **Documents validés** : même présentation (ValidatedDocumentsListSection) pour client, tiers et notaires invités.
+
+### Bénéfices Obtenus
+
+#### Maintenabilité
+
+- Logique centralisée : modifications futures plus faciles
+- Moins de duplication : moins de risques d'incohérences
+- Code plus lisible : structure claire et organisée
+
+#### Cohérence
+
+- Comportement uniforme entre les espaces
+- Gestion d'erreurs standardisée
+- Logging et toasts cohérents
+
+#### Flexibilité
+
+- Configuration via props/options
+- Spécificités préservées par contexte
+- Extensibilité facilitée
+
+---
+
+## 📚 Références
+
+- [ARCHITECTURE.md](./ARCHITECTURE.md) - Architecture rôles et permissions
+- [API.md](./API.md) - API Annuaire
+- Évolutions espace client : voir section « documentFilterHelpers » ci-dessus (visualisation documents envoyés tiers).
+
+---
+
+**Dernière mise à jour** : 2026-02-25
+
+---
+
+## 7. Interface Espace Notaire - Onglets et Tableaux
+
+### Refonte des onglets membres et tableaux documents
+
+**Date** : 2025-01-XX
+**Version** : 2.0.1+
+**Page** : `/folders/[folderUid]` - Vue ClientView
+
+#### Vue d'Ensemble
+
+Refonte complète de l'interface des onglets des membres et des tableaux de documents dans l'espace notaire pour améliorer la clarté et la conformité des documents.
+
+#### Modifications des Onglets Membres
+
+**Composants modifiés** :
+
+- `ClientView/ThirdPartyBox/index.tsx`
+- `ClientView/ClientBox/index.tsx`
+- `ClientView/SharedNotaryBox/index.tsx`
+
+**Changements** :
+
+1. **ThirdPartyBox** :
+   - ❌ Suppression du bouton "Renvoyer l'invitation"
+   - ❌ Suppression du bouton "Supprimer"
+   - ✅ Bouton unique "Modifier la note" (remplace le menu)
+
+2. **ClientBox** :
+   - ✅ Texte du bouton de note changé en "Modifier la note" (au lieu de "Rajouter/modifier une note")
+
+3. **SharedNotaryBox** :
+   - ✅ Texte du bouton de note changé en "Modifier la note"
+   - ✅ Menu conservé avec option "Modifier les informations" (si disponible)
+
+#### Modifications des Tableaux de Documents
+
+**Composants modifiés** :
+
+- `ClientView/DocumentTables/index.tsx`
+- `ClientView/DocumentTables/hooks/useDocumentRows.tsx`
+- `ClientView/DocumentTables/helpers/tableHeaders.ts`
+- `ClientView/DocumentTables/helpers/documentConformity.ts`
+- `ClientView/DocumentTables/components/DocumentTablesHeader.tsx`
+- `ClientView/DocumentTables/components/ValidatedDocumentsSection.tsx`
+
+**Nouvelle fonctionnalité : Vérification de conformité**
+
+Un nouveau helper `documentConformity.ts` vérifie la conformité des documents :
+
+- **Lien IPFS** : Présence de `watermarked_s3_key` ou `file_path` dans les fichiers
+- **Ancrage** : Présence de `document_anchor`
+- **Données d'ancrage** : Présence de `document_anchor.proof_data`
+
+Si l'un de ces éléments manque, le statut du document devient **"NON CONFORME"**.
+
+**⚠️ Exception importante : Documents demandés (ASKED)**
+
+Les documents avec le statut `ASKED` (demandés mais pas encore déposés) sont **toujours considérés comme conformes** car :
+
+- Ils n'ont pas encore de fichier déposé
+- Ils ne peuvent donc pas avoir de filigrane, d'ancrage ou de métadonnées
+- La vérification de conformité ne s'applique qu'aux documents déposés (`DEPOSITED`)
+
+La fonction `isDocumentConform()` retourne automatiquement `true` pour tous les documents en statut `ASKED`, garantissant qu'ils s'affichent toujours avec le statut "DEMANDE" et jamais "NON CONFORME".
+
+**Nouveaux tableaux** :
+
+1. **"Documents demandés"** (sans nombre entre parenthèses) :
+   - **Statuts** : DEMANDES, A VALIDER, NON CONFORME
+   - **Colonnes** : Type de document, Statut, Déposé le, Action (voir)
+   - **Fichier** : `useAskedDocumentsRows()` - Combine ASKED et DEPOSITED avec vérification conformité
+   - **Note** : Pas de colonne "Nom du document" car les documents ASKED n'ont pas encore de fichiers déposés
+   - **Note** : Pas de case à cocher pour les documents ASKED et DEPOSITED
+   - **Note** : Les documents `ASKED` ne sont jamais vérifiés pour la conformité et affichent toujours "DEMANDE"
+
+2. **"Documents validés"** (sans nombre entre parenthèses) :
+   - **Statuts** : VALIDE, TELECHARGE, NON CONFORME
+   - **Colonnes** : case à cocher, Nom du document, Type de document, Déposé le, Action (télécharger, voir)
+   - **Boutons** : Télécharger ZIP et Télécharger Certificat (selon les coches)
+   - **Fichier** : `useValidatedDocumentsRows()` - Combine VALIDATED et DOWNLOADED avec vérification conformité
+
+3. **"Documents envoyés"** (sans nombre entre parenthèses) :
+   - **Statuts** : ENVOYE, NON CONFORME
+   - **Colonnes** : case à cocher, Nom du document, Statut, Déposé le, Action (télécharger, supprimer)
+   - **Boutons** : Télécharger ZIP et Télécharger Certificat (selon les coches)
+   - **Fichier** : `useSentDocumentsRows()` - Filtre SENT avec vérification conformité
+
+**Homogénéisation Documents envoyés (2026-03)** : Le notaire envoie de la même façon aux clients, tiers et notaires invités (emails différents selon le type). Affichage centralisé via `getSentDocumentsForTab()` : clients=DocumentsNotary, tiers=Documents(third_party_depositor), invités=Documents(shared_to_office). Envoi unifié via POST /notary/documents_notary/send (un appel par destinataire).
+
+**Modifications techniques** :
+
+- Suppression du compteur de progression dans `DocumentTablesHeader`
+- Suppression des nombres entre parenthèses dans les titres des sections
+- Ajout de cases à cocher pour la sélection multiple dans tous les tableaux
+- Intégration de la vérification de conformité dans tous les hooks de génération de lignes
+- Support des documents `DocumentNotary` avec statut DOWNLOADED dans "Documents validés"
+
+**Fichiers créés** :
+
+- `ClientView/DocumentTables/helpers/documentConformity.ts` : Fonctions de vérification de conformité
+
+**Fichiers modifiés** :
+
+- `ClientView/DocumentTables/index.tsx` : Réorganisation des sections et ajout des boutons pour documents envoyés
+- `ClientView/DocumentTables/hooks/useDocumentRows.tsx` : Refonte complète des hooks pour les nouveaux tableaux
+- `ClientView/DocumentTables/helpers/tableHeaders.ts` : Mise à jour des en-têtes de tableaux
+- `ClientView/DocumentTables/components/DocumentTablesHeader.tsx` : Suppression du compteur
+- `ClientView/DocumentTables/components/ValidatedDocumentsSection.tsx` : Suppression du nombre dans le titre
+
+### Unification identité onglets membres (2026-02-26)
+
+**Page** : `/folders/[folderUid]` (vue notaire gestionnaire, `ClientView`)
+
+**Objectif** : unifier l’identité des onglets membres (`customer`, `third_party`, `shared_notary`) et centraliser la résolution d’identité pour la sélection d’onglet, la synchronisation URL et la validation des onglets.
+
+**Root cause** : l’onglet `shared_notary` utilisait selon les zones soit l’identité de partage (`sharing.uid`), soit l’UID d’office invité (`shared_to_office.uid`). Cette divergence pouvait créer des collisions d’identité d’onglets et des comportements non homogènes.
+
+**Correctifs** :
+
+- Centralisation de l’identité membre dans un helper dédié :
+  - `FolderInformation/ClientView/helpers/participantTabIdentityHelpers.ts`
+  - `getParticipantTabMemberUid(...)` pour l’identité de sélection/navigation.
+  - `getSharedNotaryOfficeUid(...)` pour le contexte de fetch des documents.
+
+- Centralisation de la construction des paramètres de navigation d’onglet :
+  - `FolderInformation/ClientView/helpers/participantTabNavigationHelpers.ts`
+  - `buildParticipantTabNavigationParams(...)` pour construire `tabNavigationParams`.
+  - `buildParticipantTabQueryPatch(...)` pour la mise à jour `router.query` sans logique locale dupliquée.
+  - `buildParticipantTabLogKey(...)` pour la construction unique des clés de logs par onglet (`client-*`, `thirdparty-*`, `shared-*`).
+  - `normalizeParticipantTabNavigationParams(...)` pour produire un objet stable mutualisé (plus de normalizer local dans les hooks de data loading).
+  - s’appuie sur `Utils/participantTabNavigationHelpers.ts` pour mutualiser extraction query, patch query, sérialisation URL et log key.
+
+- Alignement de la sélection et du query param `shareUid` :
+  - `FolderInformation/ClientView/helpers/participantTabsSelectionHelpers.ts`
+  - `shareUid` est désormais écrit avec l’identité membre (`sharing.uid`/`id`).
+  - compatibilité maintenue pour anciens liens `shareUid=<shared_to_office.uid>` en lecture.
+  - sur les futurs flux de navigation d’onglets membres, utiliser systématiquement `extractParticipantTabNavigationParamsFromQuery(...)` + `appendParticipantTabQueryToPath(...)` (interdiction de mapping local `customerUid/thirdPartyUid/shareUid`).
+  - flux migrés : `ClientDashboard/ViewDocumentsNotary/helpers/navigationHelpers.ts`, `Folder/ViewDocuments/helpers/viewDocumentsBackUrlHelpers.ts`, `Folder/AskDocuments/hooks/helpers/askDocumentsNavigationHelpers.ts`.
+
+- Alignement de la validation d’onglets :
+  - `FolderInformation/ClientView/helpers/participantTabsValidationHelpers.tsx`
+  - détection UID manquant/dupliqué basée sur le helper d’identité central.
+
+- Alignement du rendu des tableaux documents :
+  - `FolderInformation/ClientView/components/ParticipantDocumentTables.tsx`
+  - clé de rendu shared notary basée sur l’identité membre.
+  - `tabNavigationParams.shareUid` basé sur l’identité membre.
+  - contexte de fetch conservé sur l’UID d’office invité (`shared_to_office.uid`).
+  - les modules `DocumentTables/*` réutilisent désormais le type partagé `ParticipantTabNavigationParams` au lieu de signatures inline.
+
+### Retour sur l'onglet membre après modification (2026-02-27)
+
+**Objectif** : Après validation ou annulation lors de la modification des informations d'un membre (client, tiers, notaire invité), revenir sur l'onglet du membre concerné.
+
+**Correctifs** :
+
+- `backwardPath` des pages d'édition (UpdateClient, UpdateThirdParty, UpdateSharedNotary) inclut désormais les paramètres de requête d'onglet (`customerUid`, `thirdPartyUid`, `shareUid`) via `appendParticipantTabQueryToPath`.
+- Ajout de `appendQueryParam(path, key, value)` dans `Utils/participantTabNavigationHelpers.ts` pour gérer correctement l'ajout de `refresh` lorsque l'URL contient déjà des paramètres.
+- Documentation : section « Retour sur l'onglet membre après modification » dans ce document.
+
+---
+
+### Correctifs flux invité notaire et ZIP validés (2026-03-02)
+
+**Contexte invité notaire (téléchargement document validé)** :
+
+- Le flux invité notaire pouvait appeler l'API notaire (`/v1/notary/files/download`) au lieu du chemin client/guest, ce qui provoquait un 401/403 et une déconnexion côté front.
+- Le paramétrage est aligné pour traiter l'invité notaire comme un flux client/tiers sur le téléchargement de document validé :
+  - `InvitedView/documentTableHelpers.tsx` : `downloadValidatedDocument(..., { isCustomerOrThirdParty: true })`
+  - `InvitedView/InvitedDocumentsSection.tsx` : `ValidatedDocumentsListWrapper` avec `isCustomerOrThirdParty={true}`
+  - `ClientView/DocumentTables/hooks/useValidatedDocumentsRows.ts` : `resolvedContext.isInvitedNotary` inclus dans `isCustomerOrThirdParty`
+
+**Contexte ZIP documents validés** :
+
+- Le suffixe ` (validé)` pouvait être dupliqué dans certains noms de fichiers ZIP (ex: `... (validé).aplc (validé).pdf`).
+- La normalisation du suffixe est centralisée et mutualisée :
+  - réutilisation de `addValidatedSuffixToFileName()` depuis `src/front/Utils/zipValidatedSuffixHelper.ts`
+  - suppression de la logique locale redondante dans `src/front/Utils/zipDownloadHelpers/zipStructureHelpers.ts`
+- Règle unique : ne pas réappliquer un suffixe déjà normalisé (`... (validé).aplc.pdf`).
+
+---
diff --git a/projects/lecoffreio/docs/IMPORT_V1_DEPENDENCIES.md b/projects/lecoffreio/docs/IMPORT_V1_DEPENDENCIES.md
new file mode 100644
index 0000000..4974307
--- /dev/null
+++ b/projects/lecoffreio/docs/IMPORT_V1_DEPENDENCIES.md
@@ -0,0 +1,201 @@
+# Dépendances du script de déploiement et de l'import V1
+
+**Référence** : `deploy/scripts_v2/deploy.sh`, `deploy/scripts_v2/import-v1.sh`
+
+---
+
+## 1. Script principal de déploiement (`deploy.sh`)
+
+### Option `--import-v1`
+
+- Déploie d'abord front/back/resources via `deploy-app.sh`
+- Puis appelle `import-v1.sh ENV --yes`
+
+### Fichiers copiés vers la cible avant import-v1
+
+| Fichier local                                       | Destination cible                                                       |
+| --------------------------------------------------- | ----------------------------------------------------------------------- |
+| `.secrets/ENV/env-full-ENV-for-bdd-injection.txt` | `$APP_ROOT/deploy/env-full-ENV-for-bdd-injection.txt`                  |
+| `.secrets/ENV/.env.ENV.connectDB`               | via `deploy.sh` → `/etc/lecoffreio/<domain>/connectDB.env`               |
+
+### Prérequis déploiement standard
+
+
+- **`.secrets/<env>/.env.<env>`** (ex. `.secrets/test/.env.test`) : connexion SSH et config déploiement (DEPLOY_SSH_*, etc.) — à ne pas confondre avec connectDB.
+- `.secrets/ENV/.env.ENV` avec variables `DEPLOY_*`
+- Clé SSH configurée (proxy 4nk.myftp.biz)
+- `env-full-ENV-for-bdd-injection.txt` (optionnel mais recommandé pour build frontend et setSettings)
+
+---
+
+## 2. Script d'import V1 (`import-v1.sh`)
+
+### Phases et scripts appelés
+
+| Phase | Script                                                                 | Dépendances                                           |
+| ----- | ---------------------------------------------------------------------- | ----------------------------------------------------- |
+| 0     | `cleanup-disk-space.sh`                                                | Aucune                                                |
+| 1     | `migrate-resolve-database.sh`, `prisma-baseline-resolve-all.sh`, etc.   | connectDB, env-full, infos (S3)                       |
+| 1.5   | `import-v1-data-direct-into-v2.sh`                                     | connectDB (DATABASE_V1_* et DATABASE_*), psql, pg_dump, pg_restore |
+| 2     | `recover-files-from-v1.sh` → `recover-files-from-v1.ts`                | connectDB, dist, FILE_ENCRYPTION_MASTER_KEY, IPFS     |
+| 2.5   | `migrate-files-from-s3.sh` → `migrate-files-from-s3.ts`                | **DÉSACTIVÉ** (exit 0, pas de migration réelle)       |
+| 2.6   | `migrate-files-without-ipfs.sh` → `migrate-files-without-ipfs.ts`      | connectDB, dist                                       |
+| 3a    | `migrate-ribs-from-s3.sh` → `migrate-ribs-from-s3.ts`                  | **DÉSACTIVÉ** (exit 0, pas de migration réelle)       |
+| 3b    | `migrate-ribs-to-ipfs.sh` → `migrate-ribs-to-ipfs.ts`                  | connectDB, dist                                       |
+| 4     | `reanchor-all.sh`                                                      | connectDB, dist                                       |
+| 5     | `check-v1-migration-status.sh`                                         | connectDB (local)                                     |
+
+### Gestion des erreurs par phase
+
+- **Phase 2.5, 2.6** : warning si échec, continuation
+- **Phase 3a, 3b** : error + exit 1 si échec
+- **Phase 4** : warning si échec (documents invalides), continuation vers Phase 5
+- **Phase 5** : warning si échec
+
+---
+
+## 3. Fichiers de configuration requis
+
+### Obligatoires pour import-v1
+
+| Fichier                 | Emplacement                              | Usage                                                       |
+| ----------------------- | ---------------------------------------- | ----------------------------------------------------------- |
+| `infos.json`            | `.secrets/ENV/` (sur cible)             | S3, autres variables migration (credentials BDD V1 sont dans connectDB)     |
+| `.env.ENV.connectDB`  | `.secrets/ENV/` (local) → `deploy/` cible | Credentials BDD V2 (DATABASE_*) et V1 (DATABASE_V1_*); scripts chargent explicitement la version utilisée, sans fallback |
+
+### Optionnels
+
+| Fichier                              | Emplacement                    | Usage                                                       |
+| ------------------------------------ | ------------------------------ | ----------------------------------------------------------- |
+| `env-full-ENV-for-bdd-injection.txt` | `.secrets/ENV/` (local) → `deploy/` cible | setSettings, build frontend                                 |
+| `infos-migration-scaleway.json`      | `.secrets/ENV/` (sur cible)   | Variables S3 Scaleway (priorité sur infos.json) pour inject-s3-vars |
+
+### Connexion BDD sur la cible
+
+Les scripts remote (`recover-files-from-v1.sh`, `migrate-ribs-from-s3.sh`, etc.) utilisent `get_connectdb_env_file` qui retourne :
+
+```text
+${APP_ROOT}/.secrets/${ENV}/.env.${ENV}.connectDB
+```
+
+`import-v1.sh` copie connectDB vers `deploy/` puis vers `.secrets/ENV/` sur la cible, afin que apply-connectdb et les scripts remote trouvent le fichier.
+
+### Format .env.<env>.connectDB (V1 et V2)
+
+Le fichier contient deux jeux de variables (aucun fallback) :
+
+- **V2 (cible)** : `DATABASE_HOST`, `DATABASE_PORT`, `DATABASE_USERNAME`, `DATABASE_PASSWORD`, `DATABASE_NAME` (optionnel : `DATABASE_URL`). Utilisées par tous les scripts qui se connectent à la base cible (Phase 5, reanchor-all, seed-site-texts, etc.). Chargement explicite : `load_connectdb_v2 "$APP_ROOT" "$ENV"`. DB version: v2.
+- **V1 (source Scaleway)** : `DATABASE_V1_HOST`, `DATABASE_V1_PORT`, `DATABASE_V1_USERNAME`, `DATABASE_V1_PASSWORD`, `DATABASE_V1_NAME`. Utilisées uniquement par les scripts d’import V1 (import-v1-data-direct-into-v2.sh, read-v1-contacts-emails.sh). Chargement explicite : `load_connectdb_v1 "$APP_ROOT" "$ENV"`. DB version: v1.
+
+Chaque environnement (test, pprod, prod) doit avoir le bloc V1 (DATABASE_V1_*) dans son .env.<env>.connectDB (ajout uniquement, ne pas remplacer les variables V2). Chaque script qui ouvre une connexion base doit indiquer en commentaire la version utilisée (DB version: v1 ou DB version: v2). Aucun fallback entre sources. Après migration, backend.env ne doit plus exister (sauvegarde puis suppression) ; la seule source pour la BDD est .env.<env>.connectDB.
+
+
+---
+
+## 4. Outils système requis (sur la cible)
+
+| Outil           | Usage                                                       |
+| --------------- | ----------------------------------------------------------- |
+| connectDB       | Credentials BDD V1/V2 (load_connectdb_v1/v2 dans import-v1-data-direct-into-v2.sh) |
+| `psql`          | Connexion BDD (postgresql-client)                           |
+| `pg_dump`       | Export schéma/données V1                                    |
+| `pg_restore`    | Restauration en mode merge                                  |
+| `python3`/`awk` | Parsing des enums V1 (fallback awk si python3 absent)        |
+
+---
+
+## 5. Scripts S3 désactivés
+
+`migrate-files-from-s3.ts` et `migrate-ribs-from-s3.ts` sont **désactivés** : la dépendance `@aws-sdk/client-s3` a été retirée (vulnérabilités). Ils affichent un message et font `process.exit(0)`.
+
+- **Phase 2.5** : le script shell vérifie l'existence du fichier `.ts` ; s'il existe, il l'exécute (exit 0 sans migration réelle) ; sinon warning et continuation
+- **Phase 3a** : le script TS s'exécute et exit 0 ; la phase ne bloque pas
+
+Pour réactiver : `npm install @aws-sdk/client-s3` puis restaurer le script depuis l'historique Git.
+
+---
+
+## 6. Flux des fichiers connectDB et env-full
+
+```text
+Local:
+  .secrets/ENV/.env.ENV.connectDB
+  .secrets/ENV/env-full-ENV-for-bdd-injection.txt
+  .secrets/ENV/infos.json
+
+Cible (après deploy + import-v1):
+  $APP_ROOT/deploy/.env.ENV.connectDB     (copié par import-v1 pour apply-connectdb)
+  $APP_ROOT/.secrets/ENV/.env.ENV.connectDB  (copié par import-v1 depuis deploy/ pour scripts remote)
+  $APP_ROOT/deploy/env-full-ENV-for-bdd-injection.txt  (copié par deploy.sh)
+  $APP_ROOT/.secrets/ENV/infos.json        (doit exister pour Phase 1.5)
+```
+
+---
+
+## 6.1 Règles d'échange V1/V2 (référence)
+
+### Référence : règles d'échange V1/V2
+
+Pour le détail des flux (qui lit/écrit, où), voir **docs/OPERATIONS.md** section « Échanges V1 / V2 : règles et flux ». Résumé :
+
+- **Import au déploiement** (`import-v1-data-direct-into-v2.sh`) : V1 strictement en lecture (SELECT, pg_dump, COPY TO STDOUT) ; toutes les écritures (INSERT, UPDATE, TRUNCATE, ANALYZE) ciblent V2 uniquement via `psql_admin` (base DATABASE_NAME).
+- **Sync au login** (backend `V1ToV2LoginSyncService`) : connexion V1 en lecture seule (SELECT, scoped by user offices) ; upsert et ancrage uniquement en V2 (Prisma).
+- **backend.env** : n'existe plus sur les cibles ; sauvegardé dans `.secrets/<env>/backup/` puis supprimé à chaque sync. Source unique BDD : `.env.<env>.connectDB`.
+
+---
+
+## 7. Contraintes migration V1 → V2
+
+### V1 en lecture seule
+
+`import-v1-data-direct-into-v2.sh` ne fait **jamais** d'écriture sur la base V1. Seules des opérations en lecture (SELECT, pg_dump, COPY TO STDOUT) sont exécutées sur V1. Toutes les écritures (INSERT, UPDATE, TRUNCATE, pg_restore) ciblent V2 uniquement.
+
+### Vérification env-full avant setSettings
+
+Avant setSettings, import-v1.sh vérifie que env-full-ENV-for-bdd-injection.txt existe sur la cible (deploy/ ou .secrets/ENV/). Aucune copie n'est effectuée. Si absent : erreur avec indication de lancer via deploy.sh --import-v1 ou de synchroniser .secrets.
+
+### Pas de sync git ni build dans import-v1
+
+`import-v1.sh` n'exécute ni `git fetch/reset` ni `npm run build`. Le code sur la cible doit déjà être à jour (via `deploy.sh --import-v1` qui déploie avant d'appeler import-v1).
+
+### Ensures après Phase 1.5
+
+Après l'import V1 (Phase 1.5), import-v1.sh rejoue ensure-default-office-roles.sh, ensure-admin-office-roles-from-affiliations.sh et ensure-role-permissions-matrix-folders.sh pour garantir la cohérence office_roles, users.office_role_uid (depuis role_in_office) et role_permissions_matrix.
+
+### Schéma V1 et admins (role_in_office)
+
+La table `user_office_affiliations` (ajoutée en migration 20251010105200) contient `role_in_office`. Si la base V1 possède cette table avec des valeurs comme "admin", "administrateur de l office", l'import les copie. Le script `ensure-admin-office-roles-from-affiliations.sh` (exécuté après ensure-default-office-roles) met à jour `users.office_role_uid` vers le rôle admin de l'office lorsque `role_in_office` indique un admin pour l'office principal de l'utilisateur.
+
+### Observabilité post-ensure
+
+Les scripts ensure affichent des requêtes de contrôle après exécution (comptages office_roles, users avec admin, role_permissions_matrix) pour confirmer la complétude.
+
+### Architecture host-native (test/pprod/prod)
+
+Test, pprod et prod utilisent la même architecture sans Docker. Les checks V2/baseline dans `import-v1.sh` forcent `DATABASE_HOST=127.0.0.1` pour ces environnements.
+
+### Logs et suivi de l'import (Phase 1.5)
+
+Le script `import-v1-data-direct-into-v2.sh` produit des logs préfixés `[import-v1-direct]` pour suivre l'avancement : env, mode, source V1 et cible V2 ; en mode merge, nombre de tables puis pour chaque table le type de merge, le nombre de lignes V1 et « MERGE table done ». Les phases de `import-v1.sh` (0 à 5) sont loggées via info/success/error. L'intégralité de la sortie (phases 0 à 5, y compris Phase 4 réancrage) est en outre écrite dans un fichier sous `./logs/` : `import-v1-<env>-<timestamp>.log`.
+
+### Merge mode : modifications V2 limitées aux données modifiées ou ajoutées
+
+En mode merge, l'import n'écrase pas les lignes V2 lorsque les données V1 sont identiques. La clause `ON CONFLICT ... DO UPDATE SET` est complétée par un `WHERE (colonnes) IS DISTINCT FROM (EXCLUDED.colonnes)` : seules les lignes pour lesquelles au moins une colonne (hors PK et champs V2 exclus) diffère sont mises à jour. Les champs V2 exclus (watermarked_*, rib_anchor_*, folder_anchor_uid, etc.) ne sont jamais mis à jour par l'import.
+
+### Cutoff par date de dernier import OK
+
+Pour limiter le volume et les conflits, un filtre optionnel par date peut être appliqué : seules les lignes V1 dont `updated_at` (ou `created_at`) est postérieur à une date de référence sont importées ou synchronisées.
+
+- **Fichier** : `deploy/import-v1-last-ok.txt` (gitignoré). Exemple versionné : `deploy/import-v1-last-ok.txt.example`.
+- **Format** : une ligne par env, `test=2026-03-09T00:00:00Z` (ISO-8601). Clé `default` possible. Si le fichier est absent ou la clé env manquante, aucun filtre n'est appliqué.
+- **Portée** : import batch `import-v1-data-direct-into-v2.sh` (mode merge) et sync au login `V1ToV2LoginSyncService` / `V1ToV2MergeHelper`. Le filtre ne s'applique qu'aux tables exposant `updated_at` et/ou `created_at`.
+- **Mise à jour** : en fin d'import batch (merge), le script enregistre la date courante UTC comme « dernier import OK » dans ce fichier.
+- **Désactivation** : supprimer le fichier ou la ligne `<env>=...`, ou laisser la valeur vide.
+
+---
+
+## 8. Références
+
+- `docs/MIGRATION.md` : variables V2, isolation Scaleway
+- `docs/DEPLOYMENT.md` : prérequis déploiement
+- `docs/SYNC_V1_TO_V2_AT_LOGIN_PLAN.md` : plan (non implémenté) de synchronisation V1 → V2 au login (droits, dossiers, documents)
diff --git a/projects/lecoffreio/docs/MAILCHIMP_TEMPLATES.md b/projects/lecoffreio/docs/MAILCHIMP_TEMPLATES.md
new file mode 100644
index 0000000..e2511f8
--- /dev/null
+++ b/projects/lecoffreio/docs/MAILCHIMP_TEMPLATES.md
@@ -0,0 +1,40 @@
+# Templates Mailchimp/Mandrill
+
+Chaque template doit exister dans le compte Mailchimp/Mandrill avec le nom exact défini dans `ETemplates` (`lecoffre-back-main/src/common/emails/Templates/EmailTemplates.ts`).
+
+## Variable `recipient_folder_member_uid`
+
+Tous les emails envoyés à un membre de dossier incluent la variable `recipient_folder_member_uid` : l'UUID du membre du dossier qui reçoit l'email.
+
+**Affichage** : En bas du mail, en petit et en gris (ex. `font-size: 10px; color: #999`).
+
+**Valeurs selon le type de destinataire** :
+
+| Type | Valeur |
+|------|--------|
+| Client (customer) | `customers.uid` |
+| Tiers (folder_third_parties) | `folder_third_parties.uid` |
+| Partage dossier (folder_sharing) | `folder_sharing.uid` |
+| Emails hors dossier (récap, invitation abo) | Chaîne vide |
+
+**Exemple HTML à ajouter en bas de chaque template** :
+
+```html
+<p style="font-size: 10px; color: #999; margin-top: 15px;">*|recipient_folder_member_uid|*</p>
+```
+
+
+## Templates gérés par le script
+
+Les templates `THIRD_PARTY_2FA` et `FOLDER_SHARING_INVITATION` sont créés/mis à jour par `npx ts-node src/scripts/create-mailchimp-templates.ts` et incluent déjà le footer.
+
+## Templates gérés manuellement dans Mailchimp
+
+Les templates suivants doivent être mis à jour manuellement dans l'interface Mailchimp pour ajouter le footer avec `*|recipient_folder_member_uid|*` :
+
+- `DOCUMENT_ASKED`
+- `DOCUMENT_REFUSED`
+- `DOCUMENT_SEND`
+- `DOCUMENT_REMINDER`
+- `DOCUMENT_RECAP`
+- `SUBSCRIPTION_INVITATION`
diff --git a/projects/lecoffreio/docs/MIGRATION.md b/projects/lecoffreio/docs/MIGRATION.md
new file mode 100644
index 0000000..2e71ab2
--- /dev/null
+++ b/projects/lecoffreio/docs/MIGRATION.md
@@ -0,0 +1,881 @@
+# Migration - Documentation Complète
+
+**Auteur** : Équipe 4NK
+**Date** : 2026-01-XX
+**Version** : 2.0.0
+
+**Référence unique (checks de déploiement)** : [`docs/DEPLOYMENT.md#cartographie-des-checks-de-déploiement-source-unique`](./DEPLOYMENT.md#cartographie-des-checks-de-déploiement-source-unique)
+
+## 📋 Vue d'Ensemble
+
+Ce document regroupe toutes les informations relatives aux migrations dans LeCoffre.io :
+
+- Migration des données V1 vers V2
+- Variables d'environnement V2
+- Chargement de configuration V2
+- Utilisation des variables V2
+- Nettoyage des variables V1
+- Migration des classes vers factories (pattern de code)
+
+---
+
+## 1. Migration V1 → V2
+
+### Vue d'Ensemble
+
+Ce processus décrit la migration complète des données V1 vers V2, incluant le reset de la base de données, l'import des données, la récupération des documents pour leur réancrage et re-chiffrement, ainsi que le traitement spécifique des RIB.
+
+### Processus Global (centralisé)
+
+Les checks de déploiement et leur distinction automatique/manuelle sont centralisés dans :
+[`docs/DEPLOYMENT.md#cartographie-des-checks-de-déploiement-source-unique`](./DEPLOYMENT.md#cartographie-des-checks-de-déploiement-source-unique)
+
+Pour la migration V1 → V2 :
+
+- Reset de schéma et baseline Prisma via `deploy/scripts_v2/deploy.sh`
+- Import V1 initial (destructif) via `deploy/scripts_v2/deploy.sh --importV1Data`
+- Imports incrémentaux (merge non destructif) via `deploy/scripts_v2/merge-v1-data-into-v2.sh <env>`
+
+**Dépendances détaillées** : voir [`docs/IMPORT_V1_DEPENDENCIES.md`](./IMPORT_V1_DEPENDENCIES.md) pour les prérequis, fichiers et scripts par phase.
+
+### Récupération des Documents pour Réancrage et Re-Chiffrement
+
+#### Problème Identifié
+
+Lors de l'import V1→V2, les fichiers sont importés avec :
+
+- **Clés V1** : UUID individuelles stockées dans `files.key` et `files_notary.key`
+- **Algorithme V1** : AES-256-CTR (IV 16 bytes intégré)
+- **Algorithme V2** : AES-256-GCM (IV 12 bytes séparé, authTag 16 bytes)
+
+Les fichiers V1 ne peuvent pas être déchiffrés directement avec la clé maître V2 car :
+
+1. Les clés sont différentes (UUID individuelles vs clé maître)
+2. Les algorithmes sont différents (CTR vs GCM)
+3. La structure est différente (IV intégré vs IV séparé)
+
+#### Solution : Script de Récupération
+
+**Script** : `recover-files-from-v1.ts`
+
+**Processus** :
+
+1. **Déchiffrement V1** : Utilise la clé UUID stockée en base pour déchiffrer le fichier V1
+2. **Re-chiffrement V2** : Rechiffre avec la clé maître V2 (AES-256-GCM)
+3. **Réancrage** : Recalcule le hash et réancre sur Bitcoin Signet
+4. **Mise à jour** : Met à jour les métadonnées en base (hash, tx_id, etc.)
+
+**Utilisation** :
+```bash
+npm run recover-files-from-v1
+```
+
+### Traitement des RIB
+
+Les RIB en V1 étaient stockés en clair sur S3. En V2, ils sont chiffrés avec la clé maître.
+
+**Processus** :
+
+1. Téléchargement depuis S3 (V1)
+2. Chiffrement avec la clé maître V2
+3. Stockage en base de données (V2)
+
+### Variables d'Environnement V2
+
+#### Variables V2 (Application Production)
+
+Les variables suivantes sont définies dans `.secrets/<env>/infos_v2.json` et sont **utilisées par l'application V2 en production**.
+
+**Base de Données** :
+
+- `DATABASE_HOST` : Hôte de la base de données (toujours `localhost` en V2)
+- `DATABASE_PORT` : Port de la base de données
+- `DATABASE_USERNAME` : Nom d'utilisateur PostgreSQL
+- `DATABASE_PASSWORD` : Mot de passe PostgreSQL
+- `DATABASE_NAME` : Nom de la base de données
+- `ENV` : Environnement (test, pprod, prod)
+
+**Application** :
+
+- `API_ROOT_URL` : Racine de l'API
+- `APP_HOST` : URL de l'application
+- `APP_LABEL` : Label de l'application
+- `APP_PORT` : Port de l'application backend
+- `APP_ROOT_URL` : Racine de l'application
+- `BACK_API_HOST` : URL de l'API backend
+
+**Frontend (NEXT_PUBLIC_*)** :
+
+- `NEXT_PUBLIC_ADMIN_ID` : ID administrateur
+- `NEXT_PUBLIC_BACK_API_HOST` : Hôte de l'API backend
+- `NEXT_PUBLIC_BACK_API_PROTOCOL` : Protocole de l'API
+- `NEXT_PUBLIC_BACK_API_ROOT_URL` : Racine de l'API
+- `NEXT_PUBLIC_BACK_API_VERSION` : Version de l'API
+- `NEXT_PUBLIC_FRONT_APP_HOST` : URL de l'application frontend
+- `NEXT_PUBLIC_FRONT_APP_PORT` : Port de l'application frontend
+- `NEXT_PUBLIC_IDNOT_AUTHORIZE_ENDPOINT` : Endpoint d'autorisation IdNot
+- `NEXT_PUBLIC_IDNOT_BASE_URL` : URL de base IdNot
+- `NEXT_PUBLIC_IDNOT_CLIENT_ID` : Client ID IdNot
+
+**Intégrations** :
+
+- **IdNot** : `IDNOT_API_BASE_URL`, `IDNOT_API_KEY`, `IDNOT_BASE_URL`, `IDNOT_CLIENT_ID`, `IDNOT_CLIENT_SECRET`, `IDNOT_CONNEXION_URL`, `IDNOT_PROD_BASE_URL`, `IDNOT_REDIRECT_URL`
+- **Mailchimp** : `MAILCHIMP_API_KEY`, `MAILCHIMP_KEY`, `MAILCHIMP_LIST_ID`
+- **OVH SMS** : `OVH_APP_KEY`, `OVH_APP_SECRET`, `OVH_CONSUMER_KEY`, `OVH_SMS_SERVICE_NAME`, `SMS_FACTOR_TOKEN`, `SMS_PROVIDER`
+- **IPFS Pinata** : `PINATA_API_KEY`, `PINATA_API_SECRET`, `PINATA_GATEWAY`, `PINATA_GATEWAY_TOKEN`
+- **Stripe** : `STRIPE_PAYMENT_CANCEL_URL`, `STRIPE_PAYMENT_SUCCESS_URL`, `STRIPE_SECRET_KEY`, `STRIPE_STANDARD_ANNUAL_SUBSCRIPTION_PRICE_ID`, `STRIPE_STANDARD_SUBSCRIPTION_PRICE_ID`, `STRIPE_UNLIMITED_ANNUAL_SUBSCRIPTION_PRICE_ID`, `STRIPE_UNLIMITED_SUBSCRIPTION_PRICE_ID`
+- **Secure API** : `SECURE_API_KEY`
+
+**Sécurité** :
+
+- `ACCESS_TOKEN_SECRET` : Secret pour les tokens d'accès
+- `REFRESH_TOKEN_SECRET` : Secret pour les tokens de rafraîchissement
+- `ACCESS_TOKEN_TTL_MINUTES` : Durée de vie des tokens d'accès en minutes (format numérique)
+- `REFRESH_TOKEN_TTL_MINUTES` : Durée de vie des tokens de rafraîchissement en minutes (format numérique)
+- `JWT_EXPIRES_IN` : Durée de vie JWT en format legacy (ex: "1h", "7d")
+- `REFRESH_TOKEN_EXPIRES_IN` : Durée de vie des tokens de rafraîchissement en format legacy (ex: "7d")
+
+#### Variables Migration V1 (Ne PAS utiliser en V2)
+
+Les variables suivantes sont définies dans `.secrets/<env>/infos.json`, `.secrets/<env>/infos_v1.json` et, pour la BDD V1, dans `.secrets/<env>/.env.<env>.connectDB` (DATABASE_V1_*). Elles sont **uniquement utilisées par les scripts de migration V1 vers V2**. Elles ne doivent **JAMAIS** être utilisées par l'application V2 en production.
+
+**Scaleway S3 (Migration uniquement)** :
+
+- `ACCESS_KEY_ID` : Clé d'accès S3 Scaleway
+- `ACCESS_KEY_SECRET` : Secret S3 Scaleway
+- `BUCKET_NAME` : Nom du bucket S3 Scaleway
+- `BUCKET_ENDPOINT` : Endpoint S3 Scaleway
+- `container` : Informations conteneur Scaleway V1
+
+**Scripts utilisant ces variables** :
+
+- `migrate-files-from-s3.ts` : Migration des fichiers depuis S3 Scaleway vers IPFS
+- `migrate-ribs-from-s3.ts` : Migration des RIBs depuis S3 Scaleway vers IPFS
+- `recover-files-from-v1.ts` : Récupération des fichiers V1 depuis S3 Scaleway
+- `inject-s3-vars-from-infos.ts` : Injection des variables S3 dans `system_configuration`
+
+**Docapost (Non utilisé en V2)** :
+
+- `DOCAPOST_APP_ID`, `DOCAPOST_APP_PASSWORD`, `DOCAPOST_BASE_URL`, `DOCAPOST_CONNECT_PROCESS_ID`, `DOCAPOST_DOCUMENT_PROCESS_ID`, `DOCAPOST_ROOT`, `DOCAPOST_VERSION`, `NEXT_PUBLIC_DOCAPOST_API_URL`, `NEXT_PUBLIC_DOCAPOST_APP_ID`, `NEXT_PUBLIC_DOCAPOST_CONNECT_PROCESS_ID`, `NEXT_PUBLIC_DOCAPOST_DOCUMENT_PROCESS_ID`
+
+**FranceConnect (Non utilisé en V2)** :
+
+- `FC_AUTHORIZE_ENDPOINT`, `FC_CLIENT_ID`, `NEXT_PUBLIC_FC_AUTHORIZE_ENDPOINT`, `NEXT_PUBLIC_FC_CLIENT_ID`
+
+**Sentry (Non utilisé en V2)** :
+
+- `SENTRY_AUTH_TOKEN`, `SENTRY_DSN`, `SENTRY_FRONT_DSN`
+
+**Secure API Base URL (Non utilisé en V2)** :
+
+- `SECURE_API_BASE_URL`
+
+**Prisma Studio (Développement uniquement)** :
+
+- `DEV_PRISMA_STUDIO_DB_URL`, `DEV_PRISMA_STUDIO_SHADOW_URL`
+
+### Chargement de la Configuration V2
+
+#### Flux de Chargement de Configuration
+
+**Application V2 (Production)** :
+
+L'application V2 **ne charge JAMAIS** directement les fichiers `infos.json` ou `infos_v1.json`.
+
+**Flux de chargement** :
+```text
+1. env-full-<env>-for-bdd-injection.txt
+   ↓
+2. import-env-to-db.ts (script de déploiement)
+   ↓
+3. system_configuration (base de données)
+   ↓
+4. ConfigLoader (application V2)
+   ↓
+5. BackendVariables / FrontendVariablesOptimized
+```
+
+**Fichiers utilisés** :
+
+- `.secrets/<env>/env-full-<env>-for-bdd-injection.txt` : Variables injectées dans `system_configuration`
+- **PAS** `infos.json` ou `infos_v1.json` pour l'application V2
+
+**Scripts de Migration V1** :
+
+Les scripts de migration V1 chargent les credentials BDD V1 depuis `.secrets/<env>/.env.<env>.connectDB` (DATABASE_V1_*). Ils peuvent charger depuis `infos.json` **uniquement** pour :
+
+- Variables Scaleway S3 (migration fichiers V1 → V2)
+
+**Scripts concernés** :
+
+- `inject-s3-vars-from-infos.ts` : Injection variables S3 Scaleway dans `system_configuration` (lit `infos-migration-scaleway.json` en priorité, puis `infos.json` en fallback)
+- `import-v1-data-direct-into-v2.sh` : Import données V1 depuis base Scaleway
+- `migrate-files-from-s3.ts` : Migration fichiers depuis S3 Scaleway
+- `migrate-ribs-from-s3.ts` : Migration RIBs depuis S3 Scaleway
+
+#### Isolation des Variables V1
+
+**Variables V1 Supprimées** :
+
+Les variables suivantes ont été **supprimées** du code et des fichiers de configuration :
+
+- `SECURE_API_KEY` : SecureService non utilisé (ancrage via BitcoinSignetService)
+- `SECURE_API_BASE_URL` : SecureService non utilisé
+- `NEXT_PUBLIC_FC_AUTHORIZE_ENDPOINT` : FranceConnect non utilisé en V2
+- `NEXT_PUBLIC_FC_CLIENT_ID` : FranceConnect non utilisé en V2
+- `NEXT_PUBLIC_FRANCE_CONNECT_CLIENT_ID` : FranceConnect non utilisé en V2
+- `DOCAPOST_*` : Docapost non utilisé en V2
+- `SENTRY_*` : Sentry non utilisé en V2
+
+**Variables Scaleway (Migration uniquement)** :
+
+Les variables Scaleway sont **isolées** pour la migration uniquement :
+
+- `SCW_BUCKET_NAME`, `BUCKET_NAME` : Migration fichiers V1 → V2
+- `SCW_ACCESS_KEY_ID`, `ACCESS_KEY_ID` : Migration fichiers V1 → V2
+- `SCW_SECRET_ACCESS_KEY`, `ACCESS_KEY_SECRET` : Migration fichiers V1 → V2
+- `SCW_REGION` : Migration fichiers V1 → V2
+
+**Isolation** :
+
+- ✅ Lues depuis `infos-migration-scaleway.json` (priorité) ou `infos.json` (fallback) uniquement par les scripts de migration
+- ✅ Injectées dans `system_configuration` avec le préfixe `SCW_`
+- ✅ L'application V2 ne les utilise pas (stockage via IPFS Pinata)
+- ✅ **Retirées de `env-full-<env>-for-bdd-injection.txt`** pour éviter toute utilisation par l'application V2
+
+#### Fichiers de Configuration
+
+**Structure** :
+```text
+.secrets/<env>/
+├── infos_v2.json                      # Variables utilisées par l'application V2 (PRODUCTION)
+├── infos-migration-scaleway.json      # Variables Scaleway S3 (migration uniquement, PRIORITÉ)
+├── infos.json                          # Variables migration V1 (NE PAS UTILISER EN V2, fallback Scaleway)
+├── infos_v1.json                       # Variables migration V1 (NE PAS UTILISER EN V2)
+└── env-full-<env>-for-bdd-injection.txt  # Variables injectées dans system_configuration (SANS Scaleway)
+```
+
+**`env-full-<env>-for-bdd-injection.txt`** :
+
+**Usage** : Variables injectées dans `system_configuration` lors du déploiement.
+
+**Contenu** :
+
+- Variables définies dans `CONFIG_MAPPING` (utilisées par l'application V2)
+- Variables système nécessaires (`DATABASE_*`, `ENV`, `NODE_ENV`)
+
+**Ne contient PAS** :
+
+- Variables Scaleway (isolées dans `infos-migration-scaleway.json`, injectées séparément via `inject-s3-vars-from-infos.ts`)
+- Variables V1 supprimées (SECURE_API_*, NEXT_PUBLIC_FC_*, DOCAPOST_*, SENTRY_*)
+
+**Génération** :
+
+- Généré manuellement ou via script `generate-env-full-from-infos-v2.sh`
+- Nettoyé automatiquement pour supprimer les variables V1 non utilisées
+
+#### Scripts de Déploiement
+
+**`set-settings.sh`** :
+
+**Usage** : Injection des variables dans `system_configuration`.
+
+**Flux** :
+
+1. Lit `env-full-<env>-for-bdd-injection.txt`
+2. Injecte dans `system_configuration` via `import-env-to-db.ts`
+3. Injecte variables S3 Scaleway depuis `infos-migration-scaleway.json` (priorité) ou `infos.json` (fallback) via `inject-s3-vars-from-infos.ts`
+
+**Fichiers utilisés** :
+
+- `env-full-<env>-for-bdd-injection.txt` : Variables application V2 (SANS Scaleway)
+- `infos-migration-scaleway.json` : Variables S3 Scaleway (migration uniquement, priorité)
+- `infos.json` : Variables S3 Scaleway (migration uniquement, fallback)
+
+**`apply-connectdb.sh`** :
+
+**Usage** : Configuration de la connexion à la base de données.
+
+**Flux** :
+
+1. Lit `.env.<env>.connectDB` pour les credentials base de données
+2. `backend.env` n'existe plus sur les cibles (sauvegarde puis suppression à chaque sync). Source unique BDD : `.env.<env>.connectDB` (voir docs/OPERATIONS.md).
+3. `env-full-<env>-for-bdd-injection.txt` est utilisé pour setSettings et build frontend.
+
+**Fichiers utilisés** :
+
+- `.env.<env>.connectDB` : Credentials base de données
+- `env-full-<env>-for-bdd-injection.txt` : Variables supplémentaires
+
+**Scripts hors déploiement** (dans `deploy/scripts_v2`) : tous les scripts qui se connectent à la base sans être des scripts de déploiement (ex. ensure-license, check-logs-and-db, ensure-role-permissions-matrix, promote-super-admins, seed-site-texts, reanchor-all, etc.) utilisent `.secrets/<env>/.env.<env>.connectDB` pour la connexion à la base. Les scripts de déploiement (deploy-app, migrate-resolve-database, prisma-baseline, set-settings, reset-database-from-schema-export, apply-connectdb, install-systemd-units) utilisent `.env.<env>.connectDB` (backend.env n'est plus utilisé ; voir OPERATIONS.md).
+
+### Utilisation des Variables V2
+
+#### Variables de Sécurité (Tokens JWT)
+
+**`ACCESS_TOKEN_SECRET`** :
+
+- **Usage** : Secret pour signer les tokens d'accès JWT
+- **Fichiers** : `AuthService.ts` (génération/vérification), `VariablesBuilder.ts`, `Variables.ts`
+- **Catégorie** : `SECURITY` (sensible, requis)
+
+**`REFRESH_TOKEN_SECRET`** :
+
+- **Usage** : Secret pour signer les tokens de rafraîchissement JWT
+- **Fichiers** : `AuthService.ts` (génération/vérification/rafraîchissement), `VariablesBuilder.ts`, `Variables.ts`
+- **Catégorie** : `SECURITY` (sensible, requis)
+
+**`ACCESS_TOKEN_TTL_MINUTES`** :
+
+- **Usage** : Durée de vie des tokens d'accès en minutes (format numérique)
+- **Fichiers** : `TokenConfigHelper.ts` (résolution TTL)
+- **Catégorie** : `SECURITY` (non sensible, optionnel)
+- **Valeur par défaut** : 60 minutes (1h)
+
+**`REFRESH_TOKEN_TTL_MINUTES`** :
+
+- **Usage** : Durée de vie des tokens de rafraîchissement en minutes (format numérique)
+- **Fichiers** : `TokenConfigHelper.ts` (résolution TTL)
+- **Catégorie** : `SECURITY` (non sensible, optionnel)
+- **Valeur par défaut** : 10080 minutes (7 jours)
+
+**`JWT_EXPIRES_IN`** :
+
+- **Usage** : Durée de vie JWT en format legacy (ex: "1h", "7d")
+- **Fichiers** : `TokenConfigHelper.ts` (fallback si `ACCESS_TOKEN_TTL_MINUTES` non défini)
+- **Catégorie** : `SECURITY` (non sensible, optionnel)
+- **Valeur par défaut** : "1h" (60 minutes)
+- **Note** : Variable legacy, `ACCESS_TOKEN_TTL_MINUTES` est préféré
+
+**`REFRESH_TOKEN_EXPIRES_IN`** :
+
+- **Usage** : Durée de vie des tokens de rafraîchissement en format legacy (ex: "7d")
+- **Fichiers** : `TokenConfigHelper.ts` (fallback si `REFRESH_TOKEN_TTL_MINUTES` non défini)
+- **Catégorie** : `SECURITY` (non sensible, optionnel)
+- **Valeur par défaut** : "7d" (10080 minutes)
+- **Note** : Variable legacy, `REFRESH_TOKEN_TTL_MINUTES` est préféré
+
+#### Variables Scaleway (Migration V1 uniquement)
+
+**`SCW_BUCKET_NAME`** :
+
+- **Usage** : Nom du bucket S3 Scaleway pour la migration des fichiers V1 → V2
+- **Fichiers** : `migrate-files-from-s3.ts`, `migrate-ribs-from-s3.ts`, `inject-s3-vars-from-infos.ts`
+- **Catégorie** : `SYSTEM` (non sensible, optionnel - migration uniquement)
+- **Source** : `infos-migration-scaleway.json` (priorité) ou `infos.json` (fallback) - injecté dans `system_configuration` avec préfixe `SCW_`
+- **Note** : Variable utilisée uniquement par les scripts de migration, pas par l'application V2 en production
+
+**`SCW_ACCESS_KEY_ID`** :
+
+- **Usage** : Clé d'accès S3 Scaleway pour la migration des fichiers V1 → V2
+- **Fichiers** : `migrate-files-from-s3.ts`, `migrate-ribs-from-s3.ts`, `inject-s3-vars-from-infos.ts`
+- **Catégorie** : `SYSTEM` (sensible, optionnel - migration uniquement)
+- **Source** : `infos-migration-scaleway.json` (priorité) ou `infos.json` (fallback) - injecté dans `system_configuration` avec préfixe `SCW_`
+
+**`SCW_SECRET_ACCESS_KEY`** :
+
+- **Usage** : Clé secrète S3 Scaleway pour la migration des fichiers V1 → V2
+- **Fichiers** : `migrate-files-from-s3.ts`, `migrate-ribs-from-s3.ts`, `inject-s3-vars-from-infos.ts`
+- **Catégorie** : `SYSTEM` (sensible, optionnel - migration uniquement)
+- **Source** : `infos-migration-scaleway.json` (priorité) ou `infos.json` (fallback) - injecté dans `system_configuration` avec préfixe `SCW_`
+
+**`SCW_REGION`** :
+
+- **Usage** : Région S3 Scaleway pour la migration des fichiers V1 → V2
+- **Fichiers** : `migrate-files-from-s3.ts`, `migrate-ribs-from-s3.ts`, `inject-s3-vars-from-infos.ts`
+- **Catégorie** : `SYSTEM` (non sensible, optionnel - migration uniquement)
+- **Valeur par défaut** : "fr-par"
+- **Source** : `infos-migration-scaleway.json` (priorité) ou `infos.json` (fallback) - injecté dans `system_configuration` avec préfixe `SCW_`
+
+#### Flux d'Utilisation
+
+**Tokens JWT** :
+```text
+1. ACCESS_TOKEN_SECRET / REFRESH_TOKEN_SECRET
+   ↓ (system_configuration)
+2. BackendVariables
+   ↓
+3. AuthService.generateAccessToken() / generateRefreshToken()
+   ↓
+4. JWT signé avec secret + TTL
+```
+
+**TTL Tokens** :
+```text
+1. ACCESS_TOKEN_TTL_MINUTES (priorité) ou JWT_EXPIRES_IN (fallback)
+   ↓ (system_configuration)
+2. TokenConfigHelper.getAccessTokenTtlMinutes()
+   ↓
+3. AuthService.generateAccessToken() avec expiresIn
+```
+
+**Migration Scaleway** :
+```text
+1. SCW_* variables depuis infos-migration-scaleway.json (priorité) ou infos.json (fallback)
+   ↓ (inject-s3-vars-from-infos.ts)
+2. system_configuration (préfixe SCW_)
+   ↓
+3. migrate-files-from-s3.ts / migrate-ribs-from-s3.ts
+   ↓
+4. Client S3 Scaleway créé
+```
+
+### Nettoyage des Variables V1
+
+#### Variables à garder (Migration uniquement)
+
+Ces variables sont utilisées **uniquement** par les scripts de migration V1 → V2 et ne doivent **pas** être utilisées par l'application V2 en production.
+
+- `SCW_BUCKET_NAME`, `BUCKET_NAME` : Migration fichiers V1 → V2
+- `SCW_ACCESS_KEY_ID`, `ACCESS_KEY_ID` : Migration fichiers V1 → V2
+- `SCW_SECRET_ACCESS_KEY`, `ACCESS_KEY_SECRET` : Migration fichiers V1 → V2
+- `SCW_REGION` : Migration fichiers V1 → V2
+
+**Isolation** : Ces variables sont lues depuis `infos.json` et injectées dans `system_configuration` avec le préfixe `SCW_` uniquement lors de l'exécution des scripts de migration.
+
+#### Variables à nettoyer (Non utilisées)
+
+Ces variables ne sont **pas utilisées** par l'application V2 et doivent être supprimées du code.
+
+**FranceConnect** :
+
+- `NEXT_PUBLIC_FC_AUTHORIZE_ENDPOINT` : Dépréciée, filtrée dans `deprecatedKeys`
+- `NEXT_PUBLIC_FC_CLIENT_ID` : Dépréciée, filtrée dans `deprecatedKeys`
+- `NEXT_PUBLIC_FRANCE_CONNECT_CLIENT_ID` : Dépréciée
+
+**Statut** : Aucune utilisation dans le frontend. Variables déjà filtrées dans `ConfigController.ts` mais toujours définies dans `ImportEnvConfigMapping.ts`.
+
+**Docapost** :
+
+- `DOCAPOST_*` : Déjà commenté/retiré
+
+**Statut** : Déjà retiré du code. Aucune action nécessaire.
+
+**Sentry** :
+
+- `SENTRY_DSN`, `SENTRY_AUTH_TOKEN`, `SENTRY_FRONT_DSN` : Non utilisé
+
+**Statut** : Aucune référence trouvée dans le code. Aucune action nécessaire.
+
+#### Actions de Nettoyage
+
+**1. Supprimer les variables FranceConnect** :
+
+**`ImportEnvConfigMapping.ts`** :
+
+- Supprimer `NEXT_PUBLIC_FC_AUTHORIZE_ENDPOINT`
+- Supprimer `NEXT_PUBLIC_FC_CLIENT_ID`
+- Supprimer `NEXT_PUBLIC_FRANCE_CONNECT_CLIENT_ID`
+
+**`ConfigController.ts`** :
+
+- Supprimer les entrées du `deprecatedKeys` :
+  - `NEXT_PUBLIC_FC_AUTHORIZE_ENDPOINT`
+  - `NEXT_PUBLIC_FC_CLIENT_ID`
+
+**Note** : Ces variables sont déjà filtrées mais peuvent être complètement supprimées maintenant.
+
+#### Règles de Séparation
+
+**✅ Variables V2 (Production)** :
+
+- **Source** : `infos_v2.json`
+- **Usage** : Application V2 en production
+- **Stockage** : Base de données locale (`localhost`)
+- **Stockage fichiers** : IPFS (Pinata)
+- **Base de données** : PostgreSQL locale
+
+**❌ Variables Migration V1** :
+
+- **Source** : `infos.json` ou `infos_v1.json`
+- **Usage** : Scripts de migration uniquement
+- **Stockage** : Scaleway S3 (lecture seule)
+- **Base de données** : Base V1 Scaleway (lecture seule)
+
+**🔒 Isolation** :
+
+**L'application V2 ne doit JAMAIS** :
+
+- Se connecter à Scaleway S3
+- Se connecter à la base de données V1 Scaleway
+- Utiliser les variables Docapost, FranceConnect, Sentry
+- Charger `infos.json` ou `infos_v1.json` en production
+
+**Les scripts de migration peuvent** :
+
+- Lire depuis `infos-migration-scaleway.json` (priorité) ou `infos.json` (fallback) pour accéder à Scaleway S3
+- Se connecter à la base de données V1 Scaleway
+- Injecter les variables Scaleway dans `system_configuration` avec le préfixe `SCW_`
+
+---
+
+## 2. Migration Pattern : Classes vers Factories
+
+### Contexte
+
+Migration complète des classes héritant de `BaseApiService` vers des factories pour résoudre le problème TDZ (Temporal Dead Zone) dans Webpack/Next.js.
+
+### Pattern Général
+
+#### Avant (Classe)
+
+```typescript
+import BaseSuperAdmin from "../BaseSuperAdmin";
+
+export default class MyService extends BaseSuperAdmin {
+  private static instance: MyService;
+
+  private get baseUrl(): string {
+    return this.namespaceUrl.concat("/my-service");
+  }
+
+  private constructor() {
+    super();
+  }
+
+  public static getInstance() {
+    return (this.instance ??= new this());
+  }
+
+  public async myMethod(body?: ApiPayload) {
+    const url = new URL(this.baseUrl.concat("/endpoint"));
+    return this.postRequest<MyResponse>(url, body ?? {});
+  }
+}
+```
+
+#### Après (Factory)
+
+**1. Créer `MyServiceFactory.ts` :**
+
+```typescript
+import { createBaseSuperAdmin, type IBaseSuperAdmin } from "../BaseSuperAdminFactory";
+import type { ApiPayload } from "../../../types";
+import type { MyResponse } from "./MyService";
+
+interface MyServiceInstance {
+  myMethod(body?: ApiPayload): Promise<MyResponse>;
+}
+
+let instance: MyServiceInstance | null = null;
+let baseSuperAdminInstance: IBaseSuperAdmin | null = null;
+
+function createMyService(): MyServiceInstance {
+  if (!baseSuperAdminInstance) {
+    baseSuperAdminInstance = createBaseSuperAdmin();
+  }
+
+  const baseSuperAdmin = baseSuperAdminInstance;
+  const baseUrl = baseSuperAdmin.namespaceUrl.concat("/my-service");
+
+  return {
+    myMethod: async (body?: ApiPayload): Promise<MyResponse> => {
+      const url = new URL(baseUrl.concat("/endpoint"));
+      return baseSuperAdmin.postRequest<MyResponse>(url, body ?? {});
+    },
+  };
+}
+
+export function getMyServiceInstance(): MyServiceInstance {
+  if (!instance) {
+    instance = createMyService();
+  }
+  return instance;
+}
+```
+
+**2. Modifier `MyService.ts` :**
+
+```typescript
+// Export types
+export type MyResponse = {
+  // ...
+};
+
+// Export interface
+export interface IMyService {
+  myMethod(body?: unknown): Promise<MyResponse>;
+}
+
+// Lazy import of factory
+let factoryInstance: (() => IMyService) | null = null;
+
+function getFactory(): () => IMyService {
+  if (!factoryInstance) {
+    // eslint-disable-next-line @typescript-eslint/no-require-imports
+    factoryInstance = require("./MyServiceFactory").getMyServiceInstance;
+  }
+  return factoryInstance as () => IMyService;
+}
+
+// Export the instance getter
+export const MyService = {
+  getInstance: (): IMyService => {
+    return getFactory()();
+  },
+};
+
+// Export default for backward compatibility
+export default MyService;
+```
+
+### Remplacements Clés
+
+| Avant (Classe) | Après (Factory) |
+|----------------|-----------------|
+| `this.namespaceUrl` | `baseSuperAdmin.namespaceUrl` |
+| `this.baseUrl` | Variable locale `baseUrl` |
+| `this.postRequest()` | `baseSuperAdmin.postRequest()` |
+| `this.getRequest()` | `baseSuperAdmin.getRequest()` |
+| `this.putRequest()` | `baseSuperAdmin.putRequest()` |
+| `this.deleteRequest()` | `baseSuperAdmin.deleteRequest()` |
+| `this.onError()` | `baseSuperAdmin.onError()` |
+| `this.buildHeaders()` | `baseSuperAdmin.buildHeaders()` |
+
+### Factories de Base Disponibles
+
+- `createBaseApiService()` → `BaseApiServiceFactory`
+- `createBaseNotary()` → `BaseNotaryFactory`
+- `createBaseSuperAdmin()` → `BaseSuperAdminFactory`
+- `createBaseAdmin()` → `BaseAdminFactory`
+- `createBaseCustomer()` → `BaseCustomerFactory`
+- `createBasePublic()` → `BasePublicFactory`
+- `createBaseId360()` → `BaseId360Factory`
+
+### Checklist de Migration
+
+1. ✅ Créer `MyServiceFactory.ts` avec la logique métier
+2. ✅ Déplacer les types dans `MyService.ts` (si nécessaire)
+3. ✅ Modifier `MyService.ts` pour exporter la factory via lazy import
+4. ✅ Vérifier que tous les imports existants fonctionnent encore
+5. ✅ Tester TypeScript (`npm run typecheck`)
+6. ✅ Tester le build (`npm run build`)
+
+### Ordre de Migration Recommandé
+
+1. Commencer par les classes les plus simples (peu de méthodes)
+2. Migrer par namespace (SuperAdmin → Admin → Customer → Notary → Public)
+3. Tester après chaque groupe de 5-10 fichiers
+
+---
+
+## 3. Checklist de Migration V1 → V2
+
+### Phase 1 : Préparation
+
+- [ ] **Dump V1 disponible** : `deploy/bdd.<env>` (format PGDMP)
+- [ ] **Schéma V2 exporté** : `deploy/schema-v2.sql` (optionnel)
+- [ ] **Clés V1 extraites** : `.secrets/v1-file-keys.json` (via `extract-v1-file-keys.sh`)
+- [ ] **Clé maître V2 configurée** : `FILE_ENCRYPTION_MASTER_KEY` dans `system_configuration` ou `.env`
+
+### Phase 2 : Reset + Import
+
+- [ ] **Reset de la base** : Baseline V2 depuis schéma
+  ```bash
+  bash deploy/scripts_v2/deploy.sh <env> \
+    --resetDatabaseFromSchemaExport \
+    --migrateResolveDatabase
+  ```
+
+- [ ] **Import des données V1** : Import complet (destructif)
+  ```bash
+  bash deploy/scripts_v2/deploy.sh <env> \
+    --importV1Data \
+    --deploy
+  ```
+
+- [ ] **Vérification de l'import** :
+  - [ ] Nombre de fichiers importés cohérent
+  - [ ] Clés individuelles présentes dans `files.key` et `files_notary.key`
+  - [ ] RIB présents dans `rib_encrypted` (si migrés depuis S3)
+
+### Phase 3 : Récupération des Fichiers V1
+
+- [ ] **Extraction des clés V1** (si pas déjà fait)
+  ```bash
+  ./deploy/scripts_v2/backup/extract-v1-file-keys.sh .secrets/<env>/bdd.<env>
+  ```
+
+- [ ] **Récupération des fichiers** : Déchiffrement V1 → Re-chiffrement V2
+  ```bash
+  cd lecoffre-back-main
+  npx ts-node src/scripts/recover-files-from-v1.ts \
+    --output-report logs/v1-files-recovery-report.json
+  ```
+
+- [ ] **Vérification de la récupération** :
+  - [ ] Rapport de récupération généré
+  - [ ] Fichiers récupérés avec succès
+  - [ ] Nouveaux hash IPFS en base
+  - [ ] Fichiers accessibles via les nouveaux chemins IPFS
+
+### Phase 4 : Migration des RIB
+
+- [ ] **Migration des RIB vers IPFS** (si nécessaire)
+  ```bash
+  cd lecoffre-back-main
+  npx ts-node src/scripts/migrate-ribs-to-ipfs.ts \
+    --output-report logs/ribs-migration-to-ipfs-report.json
+  ```
+
+- [ ] **Vérification des RIB** :
+  - [ ] RIB migrés avec succès
+  - [ ] `rib_url` présent en base
+  - [ ] `rib_encrypted` supprimé après migration
+  - [ ] RIB accessibles via IPFS
+
+### Phase 5 : Réancrage
+
+- [ ] **Réancrage des documents** (si nécessaire)
+  ```bash
+  cd lecoffre-back-main
+  npm run reanchor-all-complete
+  ```
+
+- [ ] **Vérification de l'ancrage** :
+  - [ ] Documents réancrés avec succès
+  - [ ] Nouveaux `tx_id` en base
+  - [ ] Certificats régénérés
+
+---
+
+## 4. Conformité des Scripts de Migration
+
+### Scripts de Migration des Fichiers
+
+#### `recover-files-from-v1.ts` - 100% Conforme
+
+**Corrections appliquées** :
+
+- ✅ Utilise AES-256-CTR (algorithme V1)
+- ✅ Lit le format V1 : `[IV 16 bytes][encrypted data]`
+- ✅ Utilise les clés individuelles UUID depuis `files.key` et `files_notary.key`
+- ✅ Convertit UUID → clé de chiffrement via SHA-256 + base64 (32 premiers caractères)
+- ✅ Re-chiffre avec clé maître V2 (AES-256-GCM)
+- ✅ Upload sur IPFS V2
+- ✅ Met à jour `file_path` avec nouveau hash IPFS
+
+**⚠️ IMPORTANT** : Ce script traite uniquement les fichiers sur IPFS (`files` et `files_notary`). Il ne traite **pas** les RIB.
+
+### Scripts de Migration des RIB
+
+#### `migrate-ribs-to-ipfs.ts` - 100% Conforme
+
+**Fonctionnalités** :
+
+- ✅ Identifie les RIB en PostgreSQL (`rib_encrypted` sans `rib_url`)
+- ✅ Déchiffre depuis PostgreSQL
+- ✅ Migre vers IPFS via `uploadEncryptedRIB()` (filigrane → ancrage → chiffrement → IPFS)
+- ✅ Supprime `rib_encrypted` après migration réussie
+- ✅ Génère un rapport détaillé
+
+**⚠️ IMPORTANT** : Ce script traite uniquement les RIB stockés en PostgreSQL. Les RIB déjà sur IPFS sont ignorés.
+
+---
+
+## 5. Erreurs et Corrections de Migration
+
+### Erreur "Missing parameters" dans check-v1-migration-status.sh
+
+**Date** : 2026-01-27
+
+**Problème** : Les paramètres `ENV`, `DOMAIN`, `APP_ROOT` n'étaient pas correctement passés au script distant via SSH.
+
+**Root Cause** : Le heredoc dans `ssh_run` attendait des paramètres positionnels (`$1`, `$2`, `$3`) mais ils n'étaient pas passés correctement. Les paramètres étaient passés après la fermeture du heredoc, ce qui ne fonctionne pas avec `bash -s`.
+
+**Solution** : Passer les variables comme variables d'environnement avant le heredoc :
+
+```bash
+# Avant (incorrect)
+ssh_run ... 'bash -s' <<'CHECK_MIGRATION'
+ENV="${1:-}"
+CHECK_MIGRATION
+"$ENV" "$DOMAIN" "$APP_ROOT"
+
+# Après (correct)
+ssh_run ... env "ENV=$ENV" "DOMAIN=$DOMAIN" "APP_ROOT=$APP_ROOT" 'bash -s' <<'CHECK_MIGRATION'
+if [[ -z "${ENV:-}" || -z "${DOMAIN:-}" || -z "${APP_ROOT:-}" ]]; then
+    echo "Missing parameters" >&2
+    exit 1
+fi
+CHECK_MIGRATION
+```
+
+**Fichier modifié** : `deploy/scripts_v2/check-v1-migration-status.sh`
+
+### Erreur SQL "relation public.ribs does not exist"
+
+**Date** : 2026-01-27
+
+**Problème** : Le script `check-v1-migration-status.sh` interrogeait une table `public.ribs` qui n'existe pas.
+
+**Root Cause** : Les données RIB sont stockées dans la table `public.offices` avec les colonnes `rib_url` et `rib_encrypted`.
+
+**Solution** : Remplacer toutes les références à `public.ribs` par `public.offices` :
+
+```sql
+-- Avant
+FROM public.ribs
+WHERE rib_url IS NOT NULL
+
+-- Après
+FROM public.offices
+WHERE rib_url IS NOT NULL
+```
+
+**Fichier modifié** : `deploy/scripts_v2/check-v1-migration-status.sh`
+
+### Suppression de la limite de date 2025-05-01
+
+**Date** : 2026-01-27
+
+**Problème** : Les scripts de migration avaient une limite de date fixe qui empêchait le traitement des fichiers créés avant le 01/05/2025.
+
+**Solution** : Suppression de toutes les limites de dates dans les scripts de migration :
+
+- `recover-files-from-v1.ts` : Suppression de `maxAgeDate` et des filtres `created_at >= maxAgeDate`
+- `migrate-files-from-s3.ts` : Suppression de `maxAgeDate` et des filtres `created_at >= maxAgeDate`
+- `diagnose-failed-files-v1.ts` : Suppression de `maxAgeDate` et des filtres `created_at >= maxAgeDate`
+- `reanchor-all-complete.ts` : Suppression de `maxAgeDate` et `maxAgeDateNotary`
+- `import-v1-data-direct-into-v2.sh` : Suppression des filtres `WHERE "created_at" >= '2025-05-01'`
+
+**Fichiers modifiés** :
+
+- `lecoffre-back-main/src/scripts/recover-files-from-v1.ts`
+- `lecoffre-back-main/src/scripts/migrate-files-from-s3.ts`
+- `lecoffre-back-main/src/scripts/diagnose-failed-files-v1.ts`
+- `lecoffre-back-main/src/scripts/reanchor-all-complete.ts`
+- `deploy/scripts_v2/remote/import-v1-data-direct-into-v2.sh`
+
+### Erreurs de syntaxe Bash dans import-v1-data-direct-into-v2.sh
+
+**Date** : 2026-01-23
+
+**Problèmes** :
+
+1. Syntaxe incorrecte avec `ssh_run` et heredoc avec arguments
+2. Substitution de commande avec heredoc entre guillemets
+3. Variables échappées empêchant l'interpolation
+4. Dollar quotes (`$$`) interprétés comme PID par bash
+
+**Solutions** :
+
+1. Passer les arguments séparément sans guillemets : `bash -s arg1 arg2` au lieu de `"bash -s \"arg1\" \"arg2\""`
+2. Retirer les guillemets autour de `$(...)` avec heredoc
+3. Utiliser les variables directement sans échappement dans heredoc
+4. Utiliser Python avec variables d'environnement pour générer `$$` (fallback awk)
+
+**Fichier modifié** : `deploy/scripts_v2/remote/import-v1-data-direct-into-v2.sh`
+
+**Leçons apprises / À éviter :**
+
+- Ne jamais générer `$$` directement dans bash (toujours interprété comme PID). Utiliser Python avec variables d'environnement et heredoc en guillemets simples, ou awk en fallback.
+- Heredoc avec arguments : passer les arguments séparément, sans guillemets autour de `bash -s` (`bash -s arg1 arg2`).
+- Substitution de commande avec heredoc : ne pas mettre de guillemets autour de `$(...)`.
+- Variables dans heredoc : ne pas échapper avec `\"` ou `\$` ; utiliser `"${VAR}"` directement.
+
+---
+
+---
+
+**Dernière mise à jour** : 2026-01-28 (consolidation MIGRATION.md, V1_TO_V2_MIGRATION_PROCESS.md, V2_ENVIRONMENT_VARIABLES.md, V2_CONFIGURATION_LOADING.md, V2_VARIABLES_USAGE.md, V1_VARIABLES_CLEANUP.md)
diff --git a/projects/lecoffreio/docs/OPERATIONS.md b/projects/lecoffreio/docs/OPERATIONS.md
new file mode 100644
index 0000000..1a35822
--- /dev/null
+++ b/projects/lecoffreio/docs/OPERATIONS.md
@@ -0,0 +1,1354 @@
+# Opérations et Maintenance
+
+## Correctifs et dépannage documentés
+
+### Ancrage notarié (prod) : échec déchiffrement ou filigrane PDF (catalog.Pages, Invalid object ref)
+
+**Problème :** En prod, les logs remontent des erreurs lors de l’ancrage de documents notariés :
+- `Unsupported state or unable to authenticate data` (Decipheriv.final) puis `Fichier corrompu ou modifié (vérification d'intégrité échouée)` ;
+- `[WatermarkService] Erreur lors de l'ajout du filigrane: _this.catalog.Pages is not a function` ;
+- `Trying to parse invalid object`, `Invalid object ref: 74 0 R`, `Buffer commence par %PDF mais n'est pas un PDF valide`.
+
+**Cause :** Deux cas distincts (éventuellement sur deux documents ou deux fichiers différents) :
+1. **Échec déchiffrement** : La clé d’office ou la clé globale ne permet pas de déchiffrer le fichier (GCM auth tag invalide). Causes possibles : fichier chiffré avec une autre clé (migration, rotation), payload corrompu ou tronqué, clé d’office incorrecte en BDD.
+2. **PDF invalide après déchiffrement** : Le buffer déchiffré commence par `%PDF` mais la structure du PDF est invalide ou non supportée par pdf-lib (référence d’objet cassée, catalog/Pages absent). Causes possibles : PDF corrompu, généré par un outil exotique, ou contenu déchiffré avec une mauvaise clé (garbage qui commence par %PDF).
+
+**Root cause :** Pour (1) : mauvaise association clé/fichier ou donnée chiffrée corrompue. Pour (2) : format PDF non standard ou contenu réellement corrompu après un déchiffrement réussi.
+
+**Correction :**
+- Enrichissement des erreurs avec l’UID du fichier (`File <uid>: ...`) dans `FilesNotaryService` (déchiffrement et fallback clé globale) pour faciliter le diagnostic en logs.
+- Message d’erreur explicite lors de l’échec du filigrane si la structure PDF est invalide (catalog.Pages, Invalid object ref) : indication « PDF invalide ou structure non supportée ; possible fichier corrompu ou déchiffré avec mauvaise clé ».
+- Dans `DocumentAnchoringWatermarkHelper`, encapsulation de l’erreur de téléchargement/déchiffrement avec le `fileUid` dans le message (`Failed to download or decrypt file <uid>: ...`).
+
+**Modifications :**
+- `lecoffre-back-main/src/services/common/FilesNotaryService/FilesNotaryService.ts` : en cas d’échec déchiffrement (direct ou après fallback), lever une erreur avec préfixe `File ${uid}:`.
+- `lecoffre-back-main/src/services/common/WatermarkService/helpers/WatermarkPdfProcessorHelper.ts` : dans le catch de `addWatermark`, si le message contient `catalog`, `Pages is not a function` ou `Invalid object ref`, ajouter un hint dans le message et le log.
+- `lecoffre-back-main/src/services/common/WatermarkService/helpers/WatermarkBufferProcessorHelper.ts` : dans `validatePdfBuffer`, même hint lorsque `PDFDocument.load` échoue avec une de ces chaînes.
+- `lecoffre-back-main/src/services/notary/DocumentAnchorsService/helpers/DocumentAnchoringWatermarkHelper.ts` : `.catch` sur `filesService.download(fileUid)` pour renvoyer une erreur incluant `fileUid`.
+
+**Impact :** Les logs en prod contiennent l’UID du fichier en erreur et un message plus explicite pour les PDF invalides. Comportement fonctionnel inchangé : l’ancrage échoue toujours pour ces cas ; le diagnostic est amélioré.
+
+**Modalités de déploiement :** Déploiement standard backend (build-and-deploy).
+
+**Modalités d’analyse :** Consulter les logs backend (notary, ancrage) ; en cas d’erreur d’ancrage, le message doit contenir `File <uid>:` ou `Failed to download or decrypt file <uid>:` et, pour les PDF invalides, le hint sur structure non supportée / mauvaise clé. Vérifier en BDD que la clé d’office du document (`office_encryption_key`) et la clé du fichier (`files_notary.key`) sont cohérentes pour le fichier concerné.
+
+### Email de préférence pour les envois non renseigné à l’ajout d’un confrère (annuaire)
+
+**Problème :** Lors de l’ajout d’un confrère depuis l’annuaire (recherche notaire), le champ « Email de préférence pour les envois » restait vide au lieu d’être pré-rempli avec l’email du notaire sélectionné.
+
+**Cause :** La recherche utilise l’API Annuaire V2 : d’abord l’endpoint PB lookup (`/api/v2/directory/lookup`), puis en fallback l’endpoint PP personnes (`/api/pp/v2/personnes`). Les résultats issus du lookup sont construits à partir de `personnes` et de `rattachements`. Pour les entrées construites uniquement à partir de `personnes`, la fonction `buildResultFromPersonne` fixait l’email à une chaîne vide et ne lisait pas d’éventuels champs `email`/`mail` renvoyés par l’API. De plus, lorsque le lookup renvoyait des résultats, l’appel PP (qui fournit les emails via `mailRattachement`/`email`/`mail`) n’était jamais effectué, donc aucun enrichissement n’était possible pour ces cas.
+
+**Root cause :** (1) Non-utilisation des champs email/mail sur l’objet personne dans la réponse lookup. (2) Absence d’enrichissement des résultats lookup par un appel PP pour compléter les emails manquants.
+
+**Correction :**
+- Dans `buildResultFromPersonne`, extraction de l’email depuis l’objet personne via `pickFirst(..., "email", "mail", "courriel")` au lieu d’une chaîne vide ; types `AnnuaireLookupPerson` et paramètre de `buildResultFromPersonne` étendus avec `mail?` et `email?`.
+- Après le PB lookup, si des résultats existent, appel d’une nouvelle méthode `enrichLookupResultsWithPpEmails` : un appel unique à l’endpoint PP (première page) avec la même requête (prenom, nomUsuel), construction d’une map idNot → email, puis mise à jour des résultats du lookup qui ont un idNot mais un email vide.
+
+**Modifications :**
+- `lecoffre-back-main/src/services/common/IdNotDirectoryService/helpers/IdNotDirectoryApiSearchHelper.ts` : types `AnnuaireLookupPerson` et paramètre de `buildResultFromPersonne` avec `mail?`, `email?` ; `buildResultFromPersonne` utilise `pickFirst` pour l’email et l’inclut dans le `displayName` de fallback ; nouvelle méthode privée `enrichLookupResultsWithPpEmails` ; après le lookup réussi, appel à cette méthode avant de retourner.
+
+**Impact :** Lorsqu’un confrère est choisi dans l’annuaire, l’email de préférence pour les envois est pré-rempli lorsque l’API (lookup ou PP) fournit un email. Comportement inchangé pour les résultats déjà fournis par les rattachements ou par le fallback PP seul.
+
+**Modalités de déploiement :** Déploiement standard backend (build-and-deploy).
+
+**Modalités d’analyse :** Depuis l’interface d’ajout de confrères à un dossier, effectuer une recherche par nom de notaire, sélectionner un résultat : le champ « Email de préférence pour les envois » doit être renseigné lorsque l’annuaire retourne un email pour ce notaire. Vérifier en logs backend les messages d’enrichissement (`Enrichissement email lookup par PP`) si des résultats lookup sont complétés par PP.
+
+### Erreur en mode « Dossiers invités » sur la page /folders/shared (prod)
+
+**Contexte lint backend (2026-03-12) :** Après corrections fix-lint (variables inutilisées, non-null assertions, extraction `scheduleV1ToV2SyncIfEnabled`), il reste environ 334 erreurs ESLint (max-lines, max-params, complexity). Plan : refactor par lots ; pas de désactivation de règles. Détail dans cette section si besoin.
+
+**Problème :** Un notaire invité (ex. gwendal@lecoffre.io) en mode « Dossiers invités » obtient une erreur en accédant à la page des dossiers partagés (réponse à une invitation d'un office, ex. DIADEYS). La page affiche « Impossible de charger les dossiers partagés » ou un écran d'erreur.
+
+**Cause :** La page `/folders/shared` (`shared.tsx`) charge la liste via `GET /notary/folders/shared`. Le backend rejette cette requête lorsque l’office actif est `GUEST_FOLDERS` (400 : « Active office is required to list shared folders »). Pour un notaire invité, l’office actif est justement `GUEST_FOLDERS`.
+
+**Root cause :** `GET /notary/folders/shared` est conçu pour lister les dossiers partagés **avec un office réel**. En mode invité, la liste des dossiers accessibles doit provenir de `GET /notary/folders` (filtré par email/idNot via le JWT), pas de `GET /notary/folders/shared`.
+
+**Correction :** Dans `lecoffre-front-main/src/pages/folders/shared.tsx`, lorsque l’utilisateur est en `GUEST_FOLDERS` (permissionContext ou activeOfficeStore), ne plus appeler `getSharedFolders()`. Afficher `DefaultNotaryDashboard` sans fournir de liste externe : le tableau de bord charge alors la liste via `GET /notary/folders` (même flux que la page principale des dossiers), ce qui fonctionne pour les notaires invités.
+
+**Modifications :**
+- Fichier : `lecoffre-front-main/src/pages/folders/shared.tsx`
+  - Import de `useRolePermissions` et `activeOfficeStore`.
+  - Détection de `GUEST_FOLDERS` via `permissionContext?.activeOfficeUid` ou `activeOfficeStore.activeOffice?.office_uid`.
+  - Si `GUEST_FOLDERS` : rendu de `DefaultNotaryDashboard` sans prop `folders` (chargement interne via GET /notary/folders).
+  - Sinon : comportement inchangé (chargement via `getSharedFolders()`, mapping en `OfficeFolderExtended`).
+
+**Impact :** Les notaires invités peuvent accéder à la page « Dossiers partagés » et voir la liste de leurs dossiers invités sans erreur. Aucun changement pour les offices réels.
+
+**Modalités de déploiement :** Déploiement standard frontend (build-and-deploy).
+
+**Modalités d'analyse :** Se connecter avec un compte notaire invité (ou un compte ayant des dossiers partagés et sélectionner « Dossiers invités »), ouvrir la page /folders/shared : la liste des dossiers doit s’afficher sans erreur.
+
+### Évolution – Personne en charge du dossier (main_contact_uid) – 2026-03-12
+
+**Objectif :** Afficher dans l’espace client/tiers la personne en charge du dossier (email, téléphone) et permettre de la désigner/modifier dans l’écran « Modifier les collaborateurs ».
+
+**Modifications :** Nouveau champ `main_contact_uid` sur `office_folders` (nullable, FK `users`). Création dossier : `main_contact_uid` = créateur. PUT dossier : accepte `main_contact_uid` (validé parmi les stakeholders). GET dossier : retourne `main_contact`. Front : ContactBox utilise main_contact puis created_by puis notaire puis premier stakeholder ; écran collaborateurs : liste « Personne en charge », envoi de `main_contact_uid` à l’enregistrement.
+
+**Modalités de déploiement :** Appliquer la migration Prisma `20260312120000_add_main_contact_uid_to_office_folders`. Puis déploiement standard backend + frontend.
+
+**Modalités d’analyse :** En espace client/tiers, vérifier que le contact affiché correspond à la personne en charge si définie. Sur « Modifier les collaborateurs », choisir une personne en charge, enregistrer, vérifier en espace client que le contact affiché est bien celui choisi.
+
+### Migration V1 → V2 : Phase 4 (réancrage) non bloquante
+
+**Problème :**
+Lors de l'import V1 → V2, la Phase 4 (réancrage des documents et RIB) pouvait faire échouer toute la migration (exit 1) lorsque des documents V1 étaient invalides (fichier non-PDF, corrompu, format tableur, PDF chiffré). La Phase 5 (vérification du statut) n'était alors jamais exécutée et le log restait sans clôture explicite.
+
+**Cause :**
+Le script `import-v1.sh` utilise `set -e`. Dès que `ssh_run` (Phase 4) renvoyait le code de sortie non nul de `reanchor-all.sh`, le script quittait immédiatement sans exécuter `phase4_rc=$?` ni la Phase 5.
+
+**Cause additionnelle (backend) :**
+Le script backend `reanchor-all-complete.ts` utilisait `files.key IS NOT NULL` comme critère V1 (et `IS NULL` comme critère V2). Or des fichiers V2 peuvent avoir un `key` non nul (compatibilité API), ce qui élargissait la suppression/réancrage au-delà du périmètre V1.
+
+**Correction :**
+En cas d'échec de la Phase 4, le script affiche un avertissement et continue vers la Phase 5 au lieu de quitter. Les erreurs sur documents individuels (PDF invalide, format non supporté) restent loggées dans le fichier de log complet (`./logs/import-v1-<env>-<timestamp>.log`).
+
+Côté backend, le périmètre V1 est désormais détecté via le format de clé V1 (UUID). Le traitement Phase 4 est idempotent pour les documents : aucune ancre existante n'est supprimée et un document déjà présent avec une entrée d'ancre en base (même incomplète) n'est pas retenté.
+
+**Modifications :**
+
+- Fichier : `deploy/scripts_v2/import-v1.sh`
+  - Désactivation temporaire de `set -e` autour de l'appel Phase 4 : `set +e` avant `ssh_run`, `set -e` après capture de `phase4_rc=$?`, afin que les échecs partiels (documents ignorés/skip) ne fassent pas quitter le script.
+  - Capture du code de sortie de `ssh_run` pour la Phase 4 (`phase4_rc=$?`).
+  - Si `phase4_rc -ne 0` : `warning "Phase 4 a rencontré des erreurs (documents invalides ou réancrage partiel), continuation vers Phase 5..."` sans `exit 1`.
+  - Si `phase4_rc -eq 0` : `success "Phase 4 terminée avec succès"` comme avant.
+
+**Impact :**
+La migration complète (phases 0 à 5) se termine même lorsque des documents ne peuvent pas être réancrés. Le log complet et la Phase 5 permettent d'identifier les fichiers non migrés ou en erreur.
+
+**Modalités de déploiement :**
+Aucune (script d'import uniquement). Déploiement standard si le script est versionné.
+
+**Modalités d'analyse :**
+Relancer une migration test ; en cas d'erreurs Phase 4, vérifier que le message d'avertissement s'affiche et que la Phase 5 est bien exécutée. Consulter `./logs/import-v1-<env>-<timestamp>.log` pour le détail des erreurs document par document.
+
+Depuis le backend, les erreurs de conversion PDF affichent aussi une `signatureHex` et un type détecté (ex: zip/7z/png/jpeg/gzip) pour distinguer un faux PDF (mimetype incorrect) d'un contenu corrompu/déchiffré avec une mauvaise clé (cas V1).
+
+**Détails (backend) :**
+Backend : analyseDecryptionError, périmètre V1 par format de clé UUID, skip documents invalides.
+
+
+### Phase 5 (vérification migration) : erreur « backend.env ligne 7 : 7 : Aucun fichier ou dossier »
+
+**Problème :** En prod, le déploiement échouait en Phase 5 (vérification du statut de migration) avec code de sortie 1 et le message : `/etc/lecoffreio/prod.lecoffreio.4nkweb.com/backend.env: ligne 7: 7: Aucun fichier ou dossier de ce type`. La Phase 5 n'était pas exécutée.
+
+**Cause :** Le script `check-v1-migration-status.sh` est exécuté sur le serveur (via SSH) et chargeait `backend.env` avec `source "$BACKEND_ENV_FILE"`. Toute ligne du fichier qui n'est pas une assignation valide (ex. une ligne contenant uniquement « 7 » ou une valeur mal formée) est alors interprétée par le shell comme une commande ; le shell tente d'exécuter « 7 » comme nom de commande ou de fichier, d'où l'erreur.
+
+**Cause racine :** Le fichier `backend.env` sur l'hôte prod contenait à la ligne 7 une entrée invalide (valeur seule, numéro, ou ligne exécutable). Les fichiers `.env` de prod ne sont pas modifiables depuis le dépôt.
+
+**Correction :** Dans `deploy/scripts_v2/check-v1-migration-status.sh`, remplacer `source "$BACKEND_ENV_FILE"` par un chargement qui n'exporte que les lignes au format `VAR=value` (regex `^[A-Za-z_][A-Za-z0-9_]*=`), en ignorant les commentaires et les lignes vides ou non assignation. Ainsi, une ligne 7 invalide dans `backend.env` n'est plus exécutée et ne fait plus échouer la Phase 5. Par ailleurs, la Phase 5 utilise uniquement `APP_ROOT/.secrets/${ENV}/.env.${ENV}.connectDB` (source de vérité). Après migration, backend.env ne doit plus exister (sauvegarde puis suppression) ; la seule source est connectDB.
+
+**Modifications :**
+
+- Fichier : `deploy/scripts_v2/check-v1-migration-status.sh`
+  - Remplacement de `source "$BACKEND_ENV_FILE"` par une boucle `while IFS= read -r line` qui ne traite que les lignes correspondant à une assignation valide et les exporte.
+  - Utilisation exclusive de `APP_ROOT/.secrets/${ENV}/.env.${ENV}.connectDB`. backend.env ne doit plus exister après migration (sauvegarde puis suppression).
+
+**Impact :** La Phase 5 s'exécute même si `backend.env` contient des lignes invalides. Aucune modification des fichiers `.env` prod depuis le dépôt.
+
+**Modalités de déploiement :** Déploiement standard (scripts_v2). Aucune action requise sur l'hôte prod pour les `.env`.
+
+**Modalités d'analyse :** Relancer le déploiement prod ; la Phase 5 doit se terminer sans erreur « ligne 7 ». Optionnel : sur l'hôte prod, corriger manuellement la ligne 7 de `backend.env` pour supprimer la valeur invalide.
+
+
+### Dossier sans client : aucun membre affiché après ajout d'un tiers (notaire)
+
+**Problème :** En tant que notaire, lorsqu'on crée un dossier sans client puis qu'on ajoute un tiers, aucun membre n'apparaît dans le dossier (vue détail avec onglets Clients / Notaires invités / Tiers).
+
+**Cause :** Le critère « le dossier a des participants » (`doesFolderHaveParticipants`) ne prenait en compte que : présence d'au moins un client, ou d'un partage (notaire invité), ou de **documents déposés par des tiers**. Un dossier avec uniquement des tiers associés (sans document déposé encore) n'était pas considéré comme ayant des participants, donc la vue détail n'était pas rendue.
+
+**Cause racine :** Dans `useFolderData.ts`, `doesFolderHaveParticipants` utilisait `hasThirdPartyDocuments` (documents des tiers) et non la liste des **tiers associés au dossier** (`folder.third_parties`). L'API détail folder inclut déjà `third_parties: true` ; la donnée était disponible mais non utilisée pour ce calcul.
+
+**Correction :** Inclure la présence de tiers associés au dossier (`folder.third_parties`) dans le calcul de `doesFolderHaveParticipants`, en plus des clients, des folder_sharings et des documents des tiers. Ainsi un dossier sans client mais avec au moins un tiers affiche bien la vue détail et les onglets (dont « Tiers invités »).
+
+**Modifications :**
+
+- Fichier : `lecoffre-front-main/src/front/Components/Layouts/Folder/FolderInformation/hooks/useFolderData.ts`
+  - Calcul de `hasThirdParties` via `safeArrayLength(folderWithRelations?.third_parties) > 0`.
+  - Retour de `doesFolderHaveParticipants` étendu à `hasThirdParties ||` (en plus de hasCustomers, hasFolderSharings, hasThirdPartyDocuments).
+  - Typage du folder étendu pour inclure `third_parties` dans le cast (aligné sur `folder_sharings`).
+
+**Impact :** Les dossiers créés sans client puis complétés par l'ajout d'un ou plusieurs tiers affichent correctement la section participants (Clients / Notaires invités / Tiers invités). Aucun impact sur les dossiers avec client(s) ou avec documents tiers existants.
+
+**Modalités de déploiement :** Déploiement standard frontend (build-and-deploy).
+
+**Modalités d'analyse :** En environnement notaire : créer un dossier sans client, ajouter un tiers depuis « Gérer les acteurs » ou la page dédiée ; rouvrir le dossier et vérifier que la vue détail s'affiche avec au moins l'onglet « Tiers invités » et le tiers listé.
+
+**Complément (backend, 2026-03-11) :** En test et production, l’ajout seul d’un tiers ne faisait toujours pas apparaître les onglets membres. **Cause :** La réponse GET /notary/folders/:uid est construite via `instanceToPlain` (class-transformer) puis `forceRelationsAndDeedIntoPlain` ; `third_parties` n’était pas inclus dans les relations forcées, donc absente de la réponse JSON. **Correction :** Dans `OfficeFoldersGetOneByUidHydrationHelper.ts`, ajout de `forceRelationIntoPlain` pour `third_parties` (comme pour `folder_sharings`), afin que la réponse contienne toujours `third_parties` lorsque l’include le demande. Après déploiement backend, les onglets membres s’affichent pour un dossier avec uniquement des tiers.
+
+
+### Recherche confrères : peu de résultats malgré noms/prénoms dans l'annuaire
+
+**Problème :** À la saisie dans l’ajout d’un confrère, le filtre ne remonte que quelques comptes alors que les notaires ont bien leurs noms et prénoms dans l’annuaire / IdNot.
+
+**Cause :** Lorsque l’API Annuaire V2 n’est pas configurée (`ANNUAIRE_API_BASE_URL` / `IDNOT_API_KEY` absents de `system_configuration`), le backend utilise le **legacy IdNot**. Le fallback après `GET /persons?q=...` appelait `GET .../api/pp/v2/personnes?page=1&size=100` **sans paramètre de recherche** : seules les 100 premières personnes de l’API étaient récupérées, puis filtrées en mémoire par la requête. La recherche ne portait donc que sur un sous-ensemble fixe, d’où très peu de résultats.
+
+**Root cause :** Dans `IdNotDirectoryApiSearchHelper.searchInLegacyIdNot`, le fallback vers `api/pp/v2/personnes` ne passait pas la requête (prenom / nomUsuel) à l’API.
+
+**Correction :** Passer la requête à l’API comme pour l’Annuaire V2 : découper la chaîne en `prenom` et `nomUsuel` et appeler `api/pp/v2/personnes?prenom=...&nomUsuel=...&page=0&size=100`. La recherche est ainsi effectuée côté API (ou au moins sur un jeu pertinent) au lieu des 100 premières lignes.
+
+**Modifications :**
+- Fichier : `lecoffre-back-main/src/services/common/IdNotDirectoryService/helpers/IdNotDirectoryApiSearchHelper.ts` — fallback legacy : construction de l’URL avec `prenom` et `nomUsuel` dérivés de la requête, `page=0`, `size=100`.
+
+**Impact :** La recherche confrère en mode legacy IdNot renvoie davantage de résultats cohérents avec la saisie. Pour couvrir **tous les notaires de France**, configurer `ANNUAIRE_API_BASE_URL` et `IDNOT_API_KEY` dans `system_configuration` afin d’utiliser l’API Annuaire V2.
+
+**Modalités de déploiement :** Déploiement standard backend.
+
+**Modalités d'analyse :** Vérifier en logs `[IdNotDirectoryService] Étape 2 (API v2): X résultat(s) après filtre sur Y personne(s)` ; en cas d’API ne supportant pas prenom/nomUsuel, adapter ou conserver un fallback sans paramètres.
+
+**Évolution (2026-03-12) – Annuaire seul, pagination complète, alerte si non configuré :** La recherche confrères ne s’appuie plus sur la base du site (users/contacts/offices) ni sur les confrères déjà invités (folder_sharing). Source unique : API Annuaire (ANNUAIRE_API_BASE_URL + IDNOT_API_KEY). Pagination complète (lookup puis PP personnes, pages de 50 jusqu’à épuisement). Si l’annuaire n’est pas configuré : le backend renvoie `{ results: [], annuaireConfigured: false, message }` ; le front affiche un message d’alerte, sans fallback. Réponse API : `{ results, annuaireConfigured, message? }`. Plus de fallback legacy IdNot lorsque l’annuaire n’est pas configuré. Fichiers modifiés : IdNotDirectoryService, IdNotDirectoryApiSearchHelper, FolderSharingSearchHelper (back) ; SearchNotaries (types), useNotarySearch, SearchConfrereSection, ShareFolderModal (front).
+
+**Évolution (2026-03-12) – Invitation confrères : validation avant envoi email :** Les confrères ajoutés via « Ajouter » sur la page participants du dossier sont désormais mis en attente locale (comme les tiers). L'appel API `shareFolder` et l'envoi de l'email d'invitation ne sont effectués qu'au clic sur « Valider ». Si l'utilisateur clique « Annuler », aucun partage n'est créé et aucun email n'est envoyé. Les confrères en attente sont affichés avec « Sera invité lors de la validation » et peuvent être retirés avant validation. Fichiers modifiés : useConfreresManager, finalizeOperationsHelpers, useFinalizeHandler, ExistingConfreresList, ConfreresSection, SearchConfrereSection, StakeholdersContent, types.
+
+**Recherche confrères vide en test (ou tout env) :** L’annuaire **doit absolument être configuré** pour que la recherche confrères fonctionne. Si **ANNUAIRE_API_BASE_URL** ou **IDNOT_API_KEY** sont absents ou vides dans la table `system_configuration`, l’API `GET /api/v1/notary/search/notaries?q=...` renvoie **503 Service Unavailable** avec un corps `{ results: [], annuaireConfigured: false, message }` (pas de 200 avec résultats vides). Ces clés sont injectées depuis `.secrets/<env>/env-full-<env>-for-bdd-injection.txt` lors de l’étape **setSettings** du déploiement. Vérifier que ce fichier contient les lignes `ANNUAIRE_API_BASE_URL=...` et `IDNOT_API_KEY=...` (noms exacts), puis relancer setSettings sur la cible. Les logs backend indiquent les clés manquantes : `[IdNotDirectoryService] Annuaire non configuré: clé(s) manquante(s) dans system_configuration: ...`.
+
+**« Aucun notaire trouvé » alors que des notaires existent :** Si l’annuaire est configuré (pas de 503) mais la recherche renvoie 0 résultat pour des noms connus : (1) Consulter les logs backend sur la cible (service lecoffreio-backend@) : `🔍 [IdNotDirectoryService] API Annuaire V2 lookup...` indique l’URL appelée (sans la clé) ; `✅ ... lookup page 0: X entité(s), Y notaire(s) retenus` indique si l’API retourne des entités et combien passent le filtre (champs requis idNot, firstName, lastName). (2) Si « X entité(s), 0 notaire(s) retenus » : la réponse API ne contient pas les champs requis (uid/idnot, prenom, nomUsuel) sur les personnes ; le log `⚠️ Incomplete directory result ignored` et `⚠️ Lookup a retourné N entité(s) mais 0 notaire retenu` confirment ce cas. Adapter le parsing dans `IdNotDirectoryApiSearchHelper` (noms de champs selon la doc API Annuaire V2) ou vérifier le format de réponse de l’environnement (qual vs prod). (3) Si une erreur HTTP (4xx/5xx) apparaît : le log `⚠️ API Annuaire V2 lookup page 0 erreur: ... status=...` donne le code et éventuellement les clés du corps de réponse ; vérifier l’URL de base (ANNUAIRE_API_BASE_URL sans /api à la fin), la clé API et les droits du compte. (4) Fallback PP personnes : si le lookup échoue ou retourne 0 entité, le backend appelle `api/pp/v2/personnes?prenom=...&nomUsuel=...` ; vérifier en logs `API Annuaire V2 PP page 0: ... résultat(s) après filtre`.
+
+
+### Secrets (.secrets) et copie vers les cibles
+
+Les répertoires `.secrets/<env>/` ne sont **pas dans git** (voir `.gitignore`). Ils doivent exister en local avant tout déploiement.
+
+Lors du déploiement (`deploy/scripts_v2/deploy.sh`), le script `sync-secrets-to-target.sh` copie les fichiers suivants vers la cible (test, pprod ou prod) dans `APP_ROOT/.secrets/<env>/` :
+
+- `.env.<env>` (connexion SSH / config déploiement)
+- `.env.<env>.connectDB` (credentials BDD V2 et V1)
+- `env-full-<env>-for-bdd-injection.txt` (injection BDD / NEXT_PUBLIC_*)
+
+La base V1 est toujours distante : `DATABASE_V1_HOST` dans `.env.<env>.connectDB` ne doit **pas** être `localhost` ni `127.0.0.1`. En cas de valeur locale, `sync-secrets-to-target.sh` refuse la synchronisation (exit 1) et affiche une erreur. Le script est dans deploy/scripts_v2/remote/ ; PROJECT_ROOT doit être la racine du dépôt (SCRIPT_DIR/../../..) pour que le contrôle s'applique au bon fichier .secrets/<env>/.env.<env>.connectDB.
+
+backend.env n'existe plus sur les cibles : il est sauvegardé dans .secrets/<env>/backup/ puis supprimé à chaque sync ; la seule source pour la BDD est .env.<env>.connectDB.
+
+#### Phase 5 (check-v1-migration-status) : quel fichier est utilisé ?
+
+La Phase 5 s'exécute **sur la cible** (via SSH, heredoc dans `check-v1-migration-status.sh`). Elle lit **uniquement le fichier sur la cible** : `APP_ROOT/.secrets/<env>/.env.<env>.connectDB` (ex. `/srv/4NK/test.lecoffreio.4nkweb.com/.secrets/test/.env.test.connectDB`). Aucune lecture du fichier local pendant Phase 5.
+
+**Copie vers la cible au déploiement :**
+
+1. **deploy.sh** appelle **sync-secrets-to-target.sh** : le fichier **local** `.secrets/<env>/.env.<env>.connectDB` est copié vers la cible `APP_ROOT/.secrets/<env>/`. Si le fichier local est **absent**, aucune copie n'est faite et la cible garde son fichier existant.
+2. **import-v1.sh** au début recopie le connectDB local vers la cible (`deploy/` puis `cp` vers `.secrets/<env>/`).
+3. **import-v1.sh** juste avant Phase 5 recopie à nouveau le connectDB local vers la cible `.secrets/<env>/`, afin que Phase 5 utilise exactement le même contenu que la machine locale (évite dérive si un script intermédiaire ou une action manuelle a modifié le fichier sur la cible).
+
+Si le fichier local est absent, sync-secrets et import-v1 ne copient rien ; Phase 5 lit alors l’ancien fichier déjà présent sur la cible (éventuellement incorrect). En cas d’erreur « password authentication failed » en Phase 5 alors que `run-verify-db-connection.sh` réussit plus tard : vérifier que le fichier **local** `.secrets/<env>/.env.<env>.connectDB` existe et contient le bon mot de passe, puis relancer le déploiement (la copie avant Phase 5 recalera la cible sur le fichier local).
+
+**Pourquoi Phase 5 a pu échouer alors que run-verify-db-connection réussissait :** Phase 5 chargeait le fichier avec une boucle manuelle dans un heredoc (`while read` + `export "$trimmed"`), alors que run-verify-db-connection utilise `_lib.sh` et `load_env_file_export`. Un mot de passe avec caractères spéciaux pouvait être tronqué ou modifié par la boucle. Depuis la correction, Phase 5 utilise uniquement la même logique (source `_lib.sh` puis `load_env_file_export`) ; pas de fallback — si `_lib.sh` est absent sur la cible, Phase 5 sort en erreur (exit 2) avec un message explicite pour comprendre la cause.
+
+**Correction du parsing dans `load_env_file_export` (_lib.sh) :** L’ancienne ligne `export "${key}=${value}"` provoquait l’expansion par le shell de `${value}` : un mot de passe contenant `$` ou `` ` `` était modifié (ex. `my$ecr3t` → `my` si la variable `ecr3t` est vide). La correction : exporter la valeur sans expansion en l’enveloppant en guillemets simples et en échappant les `'` dans la valeur (`escaped="${value//\'/\'\\\'\'}"` puis `export "${key}='${escaped}'"`). Ainsi les mots de passe avec `$`, `` ` ``, guillemets ou retours à la ligne sont transmis correctement à `psql`. Si le fichier `.env.<env>.connectDB` contient `ENV='test'` ou `ENV="test"`, la valeur doit être délivrée sans les guillemets pour que `apply-connectdb.sh` puisse comparer `ENV` à l’argument `env` (ex. `test`) ; une comparaison avec guillemets inclus provoquait « ENV mismatch: connectDB ENV='test' but requested env=test ». La suppression des guillemets en début et fin de valeur est faite par expansion de paramètre (premier et dernier caractère) dans `load_env_file_export`, de façon portable (sans regex contenant des guillemets).
+
+### Échanges V1 / V2 : règles et flux
+
+Règles invariantes : **toute écriture en base cible V2 uniquement** ; **V1 strictement en lecture** lorsqu'elle est utilisée.
+
+#### Règle globale : écriture uniquement en V2
+
+- L'application backend (repositories, services) utilise une seule connexion Prisma vers la base **V2** (DATABASE_*). Aucun code applicatif n'écrit en V1.
+- Les scripts deploy qui modifient la base utilisent `.env.<env>.connectDB` avec `load_connectdb_v2` pour les écritures ; les écritures (INSERT, UPDATE, DELETE, TRUNCATE) vont toujours vers la base V2 (locale à la cible).
+
+#### Sync au login (utilisateur qui se connecte)
+
+- **Contexte** : à la connexion d'un utilisateur, une synchronisation optionnelle (V1 vers V2) peut être déclenchée pour ses bureaux (offices).
+- **V1** : utilisée **uniquement en lecture** (SELECT) pour récupérer les données des offices de l'utilisateur et les lignes à fusionner. Fichiers : `V1ToV2LoginSyncService`, `V1ToV2MergeHelper` ; connexion via `getV1DatabaseConfig` (config lue depuis system_configuration / connectDB).
+- **V2** : toutes les écritures (upsert) sont faites via Prisma (`this.database.getClient()`, `prisma.$executeRawUnsafe`) vers la base V2 uniquement. L'ancrage après sync (`V1ToV2LoginSyncAnchoringHelper`) écrit aussi uniquement en V2.
+
+- **Portée (scope)** : le sync ne concerne **que l'utilisateur connecté** (notaire ou notaire invité). Il est déclenché uniquement depuis `finalizeUserLoginFlow` avec `ensuredPayload.userId` (utilisateur authentifié). Les offices sont dérivés de V1 via `user_office_affiliations WHERE user_uid = $1` ; toutes les tables mergées et l'ancrage sont filtrés par ces `officeUids`. Aucun autre utilisateur n'est concerné.
+
+| Élément | Lecture | Écriture |
+|--------|--------|----------|
+| Base V1 (Scaleway distante) | Oui (SELECT, scoped by user offices) | Non |
+| Base V2 (locale cible) | Oui | Oui (upsert, ancrage) |
+
+#### Import au déploiement (import-v1-data-direct-into-v2.sh)
+
+- **V1** : **lecture seule**. Connexion `psql_v1` / `pg_dump` vers DATABASE_V1_* ; uniquement SELECT et COPY TO STDOUT (export). Aucun INSERT/UPDATE/DELETE sur V1.
+- **V2** : **seule cible d'écriture**. `psql_admin` = `psql -d "${DATABASE_NAME}"` (base V2) pour TRUNCATE, INSERT, UPDATE, ANALYZE. Les bases temporaires (tmp_db, TEMP_DB) sont créées sur l'hôte local (même machine que V2), pas sur V1.
+
+En-tête du script : `# CRITICAL: V1 is READ-ONLY.` et `# All writes target V2 only. Never modify V1.`
+
+#### Autres scripts et fichiers
+
+| Fichier / zone | Usage V1 | Usage V2 |
+|----------------|----------|----------|
+| `verify-db-connection.sh` | Lecture (SELECT 1) via .env.<env>.connectDB DATABASE_V1_* | Lecture (SELECT 1) via DATABASE_* |
+| `run-verify-v1-connection-local.sh` | Lecture (SELECT 1) depuis .secrets/<env>/.env.<env>.connectDB | — |
+| `read-v1-contacts-emails.sh` | Lecture seule (structure, effectifs, stats emails) | — |
+| `recover-files-from-v1.ts` | Lecture (v1Prisma / --v1-database-url) pour importer documents/fichiers manquants | Écriture (prisma.create/update) vers V2 uniquement |
+| Scripts ensure-* / promote-* / seed-* (connectDB) | — | Lecture/écriture via load_connectdb_v2 ou connectDB V2 |
+
+#### backend.env
+
+- **Plus utilisé** : après backup dans `.secrets/<env>/backup/`, le fichier `backend.env` est supprimé sur chaque cible à chaque exécution de `sync-secrets-to-target.sh`. La seule source pour la BDD est `.env.<env>.connectDB` (blocs DATABASE_* et DATABASE_V1_*).
+
+#### systemd et .secrets/
+
+- Les unités systemd (backend, frontend, router) n'utilisent plus `/etc/lecoffreio/<domain>/backend.env`, `frontend.env` ni `router.env`. Elles chargent uniquement les fichiers de `APP_ROOT/.secrets/<env>/` via des drop-ins par instance : `.env.<env>` pour tous les services, et `.env.<env>.connectDB` en plus pour le backend. Ces fichiers ne sont pas modifiés par le déploiement. Le fichier `.env.<env>` doit contenir notamment : pour le backend `ENV`, `NODE_ENV`, `APP_PORT` ; pour le frontend `PORT` ; pour le router `ROUTER_LISTEN_HOST`, `ROUTER_LISTEN_PORT`, `BACKEND_UPSTREAM`, `FRONTEND_UPSTREAM`.
+
+
+### Phase 5 (vérification migration) : échec authentification PostgreSQL
+
+**Problème :** Déploiement prod en échec en Phase 5 (code 2) : authentification PostgreSQL échouée pour le rôle (ex. `lecoffre-user-prod`) sur 127.0.0.1:5432.
+
+**Cause :** Phase 5 charge uniquement `.secrets/<env>/.env.<env>.connectDB` sur la cible. L'auth échoue si ce fichier est absent, ou si `DATABASE_PASSWORD` ne correspond pas au rôle PostgreSQL, ou si une variable est vide/mal parsée.
+
+**Cause racine :** Fichier connectDB absent ou non synchronisé avec les identifiants réels de la cible ; ou pas de contrôle/test de connexion avant les requêtes.
+
+**Correction :** La Phase 5 utilise uniquement `.secrets/<env>/.env.<env>.connectDB`. Après chargement : vérification des variables DATABASE_* ; sinon exit 2. Puis test de connexion psql ; en cas d'échec, message explicite et exit 2. Assurer que .secrets/<env>/.env.<env>.connectDB est rempli et synchronisé vers la cible (backend.env ne doit plus exister après migration).
+
+**À faire :** S'assurer que `.secrets/<env>/.env.<env>.connectDB` est rempli (V2 et V1 si import) et synchronisé vers la cible. Après migration, backend.env ne doit plus exister (sauvegarde puis suppression). En cas d'échec auth : aligner le mot de passe du rôle PostgreSQL avec DATABASE_PASSWORD du fichier connectDB.
+
+**Modalités d'analyse :** Exécuter `bash deploy/scripts_v2/check-v1-migration-status.sh prod` (ou test/pprod) ; en cas d'échec, le message indique le fichier chargé. Tester la connexion : `bash deploy/scripts_v2/run-verify-db-connection.sh prod`.
+
+
+
+### Réancrage Phase 4 : erreur « Format tableur non supporté » traitée en skip
+
+**Problème :** Lors du réancrage (Phase 4), si le déchiffrement échoue (GCM) et que le validateur de format renvoie « Format tableur non supporté » (ou autre message de rejet de format), le document n'était pas considéré comme à ignorer et la phase pouvait échouer.
+
+**Correction :** Extension de `analyzeDecryptionError()` pour reconnaître tous les messages de rejet de format (`FileFormatValidator.getRejectionMessage()`) et marquer le document en skip. Rebuild backend puis relancer Phase 4 / déploiement si besoin.
+
+
+
+### Réancrage Phase 4 (prod) : « PDF conversion failed » / « PDF invalide » traités en skip
+
+**Problème :** En prod, la Phase 4 (réancrage) s'arrêtait (exit 1) lorsque des documents notary provoquaient une erreur de déchiffrement (GCM) puis « PDF conversion failed: generated PDF is invalid » ou « PDF invalide après conversion ». Ces messages n'étaient pas reconnus comme skip, donc le document allait en échec et le script quittait avec code 1.
+
+**Correction :** Extension de `analyzeDecryptionError()` pour reconnaître « pdf conversion failed », « pdf invalide », « generated pdf is invalid », « failed to parse pdf » et marquer le document en skip. Rebuild backend puis redéployer / relancer Phase 4.
+
+Complément : si `anchorDocumentForReanchor` renvoyait bien `skipped: true`, `processDocumentForReanchor` ne propageait pas `anchorResult.skipped`/`reason` et le document était encore compté en failed (« Erreur inconnue »). Correctif : dans `processDocumentForReanchor`, traiter en premier `anchorResult.skipped && anchorResult.reason` et retourner `{ success: false, skipped: true, reason }` ; fallback `error: anchorResult.error ?? "Erreur inconnue"` (fichier `ReanchorHelpers.ts`).
+
+### Réancrage Phase 4 : propagation de skipped/reason (processDocumentForReanchor)
+
+**Problème :** Même après reconnaissance des libellés PDF invalide / conversion échouée, le script affichait « Erreur document notary … : Erreur inconnue » et quittait en exit 1.
+
+**Cause :** `processDocumentForReanchor` ne testait que `anchorResult.error` ; lorsque `anchorDocumentForReanchor` retournait `{ success: false, skipped: true, reason }` (sans `error`), le retour générique était `{ success: false, skipped: false, error: undefined }`.
+
+**Correction :** Dans `ReanchorHelpers.ts`, si `!anchorResult.success` et `anchorResult.skipped && anchorResult.reason`, retourner immédiatement `{ success: false, skipped: true, reason: anchorResult.reason }` ; sinon utiliser `error: anchorResult.error ?? "Erreur inconnue"`.
+
+### Réancrage Phase 4 (prod) : « V1 decrypt produced empty buffer » traité en skip
+
+**Problème :** En prod, la Phase 4 (réancrage) pouvait encore quitter avec exit 1 lorsque l'erreur était « [FilesNotaryService] V1 decrypt produced empty buffer for &lt;uid&gt; ». Ce message n'était pas reconnu par `analyzeDecryptionError`, donc le document était compté en failed.
+
+**Cause :** La fonction `analyzeDecryptionError` (ReanchorHelpers.ts) ne reconnaissait que « buffer is empty » et « buffer vide » dans le bloc « buffer vide », pas « empty buffer » ni « v1 decrypt produced empty buffer ».
+
+**Correction :** Dans le bloc « buffer vide » de `analyzeDecryptionError`, ajouter les conditions `normalizedMessage.includes("empty buffer")` et `normalizedMessage.includes("v1 decrypt produced empty buffer")` pour traiter ces erreurs en skip (fichier expiré / buffer vide).
+
+### Migration V1 → V2 : `import-v1-direct` (MERGE) — collisions d’unicité sur `(name, office_uid)`
+
+**Problème :**
+Le mode `MERGE` peut échouer sur des tables dont l’unicité métier est portée par `(name, office_uid)` (ex. `deed_types`, `document_types`) lorsque des lignes V1 utilisent un `uid` différent d’une ligne déjà existante en V2 pour le même couple `(name, office_uid)`.
+
+**Cause :**
+Upsert basé sur `uid` (PK) alors que certaines tables ont aussi une contrainte unique sur `(name, office_uid)`.
+
+**Correction :**
+Avant l’UPSERT, appliquer un mécanisme générique piloté par allowlist :
+
+Optionnel : limiter l’import aux éléments postérieurs à une date (facile à modifier/enlever) via `deploy/import-v1-last-ok.txt` (fichier gitignoré).
+
+- Construire un mapping `uid_v1 → uid_v2` depuis la clé métier (ex. `(name, office_uid)`) et l’exporter en CSV dans `/tmp`
+- Réécrire ensuite les clés étrangères vers ces tables via discovery des FK (`pg_constraint`) pendant le run
+
+Détails : allowlist par table (deed_types, document_types, users idnot, office_folders folder_number), voir scripts import-v1-direct.
+
+### [import-v1-direct] MERGE customers : FK `customers_contact_uid_fkey`
+
+**Problème :** Lors du MERGE, l'étape customers échoue car des lignes V1 ont un `contact_uid` absent de la table `contacts`.
+
+**Correction :** Ajout de la table `contacts` à la liste des tables sans filtre date, pour que tous les contacts V1 soient mergés avant les customers. Les customers sont tous insérés (pas de filtre). Vérification en lecture seule en V1 : `SELECT uid, created_at, updated_at FROM contacts WHERE uid = '<contact_uid>'`.
+
+
+
+### Suppression des synchronisations IdNot / Annuaire / Stripe (tables `sync_*` / `annu_*`)
+
+**Problème :**
+Les parcours de recherche / résolution de confrères (ex: par email) pouvaient dépendre de tables de synchronisation (`sync_*`, `annu_*`) et de scripts/endpoints de sync dédiés.
+
+**Cause :**
+Présence d’un mécanisme de synchronisation batch (IdNot/Annuaire/Stripe) avec tables dédiées et endpoints/scripts associés.
+
+**Cause racine :**
+Le besoin “référentiel complet” a été implémenté par réplication locale (tables sync) au lieu d’un usage systématique des appels API au moment de la demande.
+
+**Correction :**
+
+- Suppression des points d’entrée / scripts / endpoints de sync et retrait des modèles Prisma `sync_*` / `annu_*` / `sync_stripe_subscriptions`.
+- Les recherches utilisent désormais des **appels API** (IdNot/Annuaire) au moment de la demande, avec complément base du site et `folder_sharing`.
+
+**Impact :**
+
+- Plus d’usage applicatif des tables de synchronisation.
+- Les réponses reposent sur la base réelle (users/contacts/offices) et les APIs externes au moment du besoin.
+
+**Modalités de déploiement :**
+Déploiement standard backend.
+
+**Modalités d'analyse :**
+
+- Vérifier la recherche confrères (partage de dossier) et la résolution par email (logs backend, réponses API).
+
+
+
+
+### Super-admin : chargement matrice de droits à la demande
+
+**Problème :**
+Le frontend chargeait systématiquement `GET /api/v1/super-admin/role-permissions` dès qu’un utilisateur était identifié comme `super-admin`, y compris sur des pages non liées (ex: `/folders`). En cas d’aléa réseau, cela générait des erreurs `Failed to fetch` et du bruit console, sans valeur fonctionnelle.
+
+**Cause :**
+Le refresh global des permissions déclenchait un chargement complet de matrice dès `permissionContext.globalRole === "super-admin"`.
+
+**Cause racine :**
+Le chargement de la matrice était implémenté comme un effet global plutôt que comme un besoin local à l’écran d’administration de matrice, ce qui augmente la surface réseau et les points de défaillance.
+
+**Correction :**
+
+- Le refresh global ne charge plus la matrice complète pour les super-admins.
+- La matrice complète est chargée uniquement sur la page `/super-admin/role-permissions` (à la demande).
+- Suppression des imports dynamiques (`import()`/`require()`) sur les modules RolePermissions via extraction des types.
+
+**Impact :**
+
+- Plus d’erreur réseau sur `GET /super-admin/role-permissions` lors de navigation standard.
+- Réduction des dépendances dynamiques côté front sur ce module.
+
+**Modalités de déploiement :**
+Déploiement standard frontend.
+
+**Modalités d’analyse :**
+
+- Se connecter en super-admin et naviguer vers `/folders` puis vérifier l’absence d’appel `GET /api/v1/super-admin/role-permissions`.
+- Naviguer vers `/super-admin/role-permissions` et vérifier que l’appel est déclenché (si la page existe).
+
+
+
+### Refactoring Linting Frontend (Transition ESLint 250/40)
+
+**Objectif :**
+Réduire la dette technique et améliorer la maintenabilité du code frontend en respectant les règles ESLint strictes (max 40 lignes par fonction, max 250 lignes par fichier, max 4 paramètres).
+
+**Modifications :**
+
+- **BaseApiService :** Refactoring pour utiliser `RequestOptions` et `ProcessResponseOptions` afin de réduire le nombre de paramètres.
+- **Factories :** Découpage des factories API (Auth, Admin, Notary, Customer) en extrayant les méthodes dans des helpers dédiés (`*MethodsHelpers.ts`).
+- **Helpers :** Création de nombreux helpers pour alléger les fichiers principaux.
+- **Imports :** Utilisation d'alias `@Front/Api/types` pour simplifier les imports.
+
+**Impact :**
+
+- Code plus modulaire et plus facile à tester.
+- Réduction significative des erreurs de lint `max-lines-per-function`, `max-params` et `complexity`.
+- Pas de changement fonctionnel (refactoring pur).
+
+**Modalités de déploiement :**
+Déploiement standard du frontend.
+
+**Modalités d'analyse :**
+Vérifier que l'application fonctionne correctement (navigation, appels API). `npm run lint` doit rapporter moins d'erreurs.
+
+### Correction de la visibilité des dossiers archivés pour les clients
+
+**Problème :**
+Les clients pouvaient voir les dossiers archivés dans leur liste de dossiers, ce qui n'est pas le comportement attendu.
+
+**Cause :**
+Le filtre `status: "LIVE"` était manquant dans la configuration de la requête Prisma pour les clients dans `OfficeFoldersController`.
+
+**Correction :**
+Ajout explicite du filtre `status: "LIVE"` et `deleted_at: null` dans les méthodes de configuration de requête pour les clients et les tiers.
+
+**Modifications :**
+
+- Fichier : `lecoffre-back-main/src/app/api/customer/OfficeFoldersController.ts`
+  - Ajout de `status: "LIVE"` dans `configureThirdPartyQuery` et `configureCustomerQuery`.
+  - Ajout de la vérification du statut dans `getOneByUid`.
+
+**Impact :**
+Les clients et tiers ne verront plus les dossiers archivés ou supprimés dans leur interface.
+
+**Modalités de déploiement :**
+Déploiement standard du backend.
+
+**Modalités d'analyse :**
+Vérifier que les dossiers ayant le statut `ARCHIVED` ou `DELETED` n'apparaissent plus dans la liste des dossiers côté client.
+
+### Correction de la génération de ZIP avec fichiers multiples (collision de noms)
+
+**Problème :**
+Lors de la sélection de plusieurs documents pour créer un ZIP, si les noms de fichiers générés étaient identiques (ex: même type de document pour le même dossier), un seul fichier était présent dans le ZIP final car ils s'écrasaient mutuellement.
+
+**Cause :**
+Absence de gestion des collisions de noms de fichiers dans `ZipService.ts`. Le service ajoutait les fichiers à l'archive avec le nom généré par `FileNamingService`, sans vérifier si ce nom était déjà utilisé dans l'archive en cours de construction.
+
+**Correction :**
+Ajout d'une logique pour détecter les noms de fichiers déjà utilisés dans l'archive et ajouter un suffixe incrémental `(n)` pour les rendre uniques.
+La logique a été factorisée dans `FileNamingService.getUniqueFileName`.
+
+**Modifications :**
+
+- Fichier : `lecoffre-back-main/src/services/common/ZipService/ZipService.ts`
+  - Utilisation de `FileNamingService.getUniqueFileName` pour garantir l'unicité des noms dans l'archive.
+- Fichier : `lecoffre-back-main/src/services/common/FileNamingService/FileNamingService.ts`
+  - Ajout de la méthode `getUniqueFileName` pour gérer la déduplication avec suffixe `(n)`.
+
+**Impact :**
+Les ZIPs générés contiendront désormais tous les fichiers sélectionnés, même s'ils ont le même nom de base.
+
+**Modalités de déploiement :**
+Déploiement standard du backend.
+
+**Modalités d'analyse :**
+Vérifier que les ZIPs contenant plusieurs fichiers avec le même nom (ex: deux "Pièce d'identité" dans le même dossier) contiennent bien tous les fichiers avec des noms distincts.
+
+### Correction des permissions V2 pour le rôle `admin` (matrice des droits)
+
+**Problème :**
+Un utilisateur d’étude avec `global_role = admin` pouvait se retrouver avec une matrice V2 très restreinte côté UI (pages/actions manquantes sur documents/fichiers/partages/rappels/demandes), tandis que les collègues résolus en `collaborator` avaient le périmètre complet.
+
+**Cause :**
+La V2 filtre la matrice de permissions sur le rôle résolu. Pour un utilisateur `admin`, la résolution conserve `admin`, donc l’UI dépend directement des entrées `admin` présentes dans `role_permissions_matrix`.
+
+**Cause racine :**
+Les scripts/migrations existants assuraient la complétude de `collaborator` sur les ressources notariales, mais pouvaient laisser `admin` incomplet (notamment via certains scripts d’ensure).
+
+**Correction :**
+Backfill idempotent (insert-only) des entrées `admin` à partir des entrées `collaborator` pour les ressources notariales :
+
+- Script d’ensure : `deploy/scripts_v2/remote/sql/ensure-role-permissions-matrix-folders.sql` (clonage `collaborator` → `admin` avec `ON CONFLICT DO NOTHING`).
+- Migration Prisma : `20260305120000_backfill_admin_permissions_from_collaborator`.
+
+- Ensure au login : lors de la génération du JWT pour un utilisateur `admin`, backfill idempotent `collaborator` → `admin` si la matrice est incomplète (avec reload du cache).
+
+**Modalités de déploiement :**
+Déploiement standard du backend (migrations via `prisma migrate deploy`). En cas de base restaurée / matrice incomplète, exécuter le script d’ensure habituel.
+
+- Depuis `deploy/scripts_v2/deploy.sh` : exécution systématique de `deploy/scripts_v2/remote/ensure-role-permissions-matrix-folders.sh` après migrations.
+
+- Diagnostics (logs) :
+  - `deploy/scripts_v2/run-check-user-offices-logs.sh <env>` : journalctl backend centré sur `UserOffices` et sync offices (utile quand le front loggue `OfficeSelector hidden: no offices available`).
+  - Les scripts de diagnostic `scripts_v2/remote/*` utilisent `print_journalctl_matches` / `count_journalctl_matches` (définis dans `deploy/scripts_v2/remote/_lib.sh`) pour rester stables avec `set -euo pipefail` même quand il n’y a aucun match.
+
+**Modalités d'analyse :**
+Contrôler que `role_permissions_matrix` contient des entrées `admin` sur `documents`, `files`, `folder_customer`, `folder_third_parties`, `folder_sharing`, `document_reminder`, `document_request`, et que `GET /api/v1/notary/my-permissions` pour un utilisateur `admin` renvoie ces ressources/pages.
+
+
+### Correction : offices sans `office_roles` + Annuaire (champs requis)
+
+**Problème :**
+
+- Certains offices peuvent exister sans aucune entrée dans `office_roles` (absence de `Notaire` / `Collaborateur`), ce qui peut dégrader le calcul des règles au login.
+- Les résultats Annuaire/IdNot peuvent contenir des personnes incomplètes (sans `idNot`, `firstName`, `lastName`) qui ne doivent pas être proposées comme ajoutables.
+
+**Cause :**
+
+- Incohérences de données historiques / import / migrations.
+- Qualité variable des données source Annuaire.
+
+**Correction :**
+
+- Vérification/correction au login : ensure idempotent des rôles d’office par défaut (`Notaire`, `Collaborateur`) et liaison aux règles attendues.
+- Vérification/correction systématique au déploiement : exécution d’un ensure SQL idempotent via `deploy/scripts_v2/deploy.sh`.
+- Filtrage Annuaire : exclusion + log des résultats incomplets (champs requis).
+
+**Modifications :**
+
+- `lecoffre-back-main/src/services/common/IdNotService/IdNotRoleService.ts`
+- `lecoffre-back-main/src/services/common/AuthService/helpers/JwtPayloadGenerationHelper.ts`
+- `lecoffre-back-main/src/services/common/IdNotDirectoryService/helpers/DirectoryRequiredFieldsHelper.ts`
+- `deploy/scripts_v2/remote/sql/ensure-default-office-roles.sql`
+- `deploy/scripts_v2/deploy.sh`
+  - Au démarrage : `git add -A` + commit + push local (si changements) AVANT toute action distante.
+  - Sur la machine cible : reset/checkout du ref via `git checkout -B <branch> <remote>/<branch>` pendant le sync.
+
+**Modalités de déploiement :**
+
+- Déploiement standard V2.
+- En cas de base restaurée : `deploy/scripts_v2/run-ensure-default-office-roles.sh <env>`.
+
+**Modalités d'analyse :**
+
+
+
+### Vérification migration i18n / site texts (backend, frontend, ressources)
+
+**Objectif :**
+Vérifier que les textes utilisateur sont migrés en i18n (site texts) et configurés dans `.secrets/<env>/seed-site-texts-<env>.ts` et `.secrets/<env>/env-full-<env>-for-bdd-injection.txt` pour chaque environnement.
+
+**État constaté :**
+
+- **Frontend :** Les écrans Login, MyAccount, et la page Office (informations) utilisent `useSiteTextContent` avec des clés déclarées dans le seed. Les clés utilisées (65 à 80 selon les écrans) sont présentes dans le seed et dans `SITE_TEXTS_KEYS_INDEX` de l’env-full. Le boot (page `/_app`) précharge désormais aussi le scope `components` (en plus de `login`) via `lecoffre-front-main/src/front/Stores/siteTextsBootConfig.ts`, pour éviter les logs `Missing site text` quand une clé `components.*` est en base mais pas chargée. Plusieurs écrans (dossiers, formulaires tiers, super-admin, etc.) contiennent encore des libellés en dur ; une migration progressive peut étendre le scope `components` ou ajouter des scopes métier et les clés correspondantes au seed puis à l’env-full.
+- **Backend :** Les messages d’erreur et de validation sont centralisés dans `lecoffre-back-main/src/common/utils/errorMessages.ts`. Les réponses API (erreurs 4xx/5xx) utilisent ces constantes. Quelques messages de succès sont en dur dans les contrôleurs (ex. `IncidentReportController`, `FolderSharingResendHelper`, `FolderThirdPartiesResendCodeHelper`, `DocumentsGuestNotaryHelper`). Aucune résolution de clés site texts côté backend pour les réponses API n’est en place ; une évolution ultérieure pourrait exposer des clés i18n côté API si besoin.
+- **Ressources :** Le package `le-coffre-resources` fournit des types (Notary, SuperAdmin, etc.) ; pas de chaînes utilisateur à migrer.
+
+**Modifications effectuées :**
+
+- **MyAccount / Mon compte :** Utilisation des clés `myAccount.office.idNot.label` et `myAccount.office.idNot.placeholder` déjà présentes dans le seed ; passage de ces libellés depuis le parent vers `MyAccountOfficeSection` (plus de texte en dur pour l’identifiant ID.NOT).
+- **Page Office (informations) :** Ajout de 11 clés dans le seed (scope `office`) : `office.labels.crpcen`, `office.labels.denomination`, `office.labels.address`, `office.titles.administrators`, `office.titles.collaborators`, `office.userLabels.lastName`, `office.userLabels.firstName`, `office.userLabels.email`, `office.userLabels.phone`, `office.userLabels.role`, `office.header.active`. Mise à jour de `.secrets/test/seed-site-texts-test.ts` et de `.secrets/test/env-full-test-for-bdd-injection.txt` (SITE_TEXTS_KEYS_INDEX). Page `offices/[officeUid]` enveloppée dans `SiteTextsProvider` avec `scopes={["office"]}` ; composant `OfficeInformations` migré pour utiliser `useSiteTextContent` et passer les libellés à la vue (correction orthographique « Addresse » → « Adresse » via la clé).
+
+**Modalités de déploiement :**
+
+- Exécuter le seed site texts après déploiement si les nouvelles clés doivent être présentes en base : `npm run site-texts:seed` (backend) en s’assurant que le fichier seed et l’env-full sont bien déployés (voir `deploy/scripts_v2`).
+- Pour pprod/prod : reproduire les entrées du seed test dans les dépôts concernés (`.secrets/<env>/seed-site-texts-<env>.ts` et `env-full-<env>-for-bdd-injection.txt`) puis exécuter le seed sur l’environnement cible.
+
+**Modalités d’analyse :**
+
+- Vérifier que la page Mon compte affiche bien les libellés ID.NOT depuis le seed.
+- Vérifier que la page Office (super-admin) affiche les libellés CRPCEN, Dénomination, Adresse, Administrateurs, Collaborateurs, Nom, Prénom, E-mail, Téléphone, Rôle depuis le seed (scope `office`).
+- Vérifier que `SITE_TEXTS_KEYS_INDEX` dans l’env-full contient toutes les clés du seed (ordre identique recommandé).
+- Vérifier au login que `officeRole` est résoluble et que les `rules` associées sont chargées.
+- Vérifier que les résultats Annuaire incomplets sont ignorés et loggués (missing fields + `idNotPrefix`).
+
+## Évolutions documentées
+### Centralisation vérification accès invité notaire
+
+**Date** : 2026-03-02
+
+#### Objectif
+
+Centraliser la logique « vérifier accès invité notary » (email invité + folder + hasAccess via folder_sharing) dans un helper générique, utilisé par le téléchargement batch (FilesBatchDownloadGuestNotaryHelper) et le téléchargement single fichier notary (FilesNotaryDownloadGuestNotaryHelper). La logique batch ne sert plus qu’au regroupement d’emails ou à la vérification des relances, pas pour l’upload de documents.
+
+#### Impacts
+
+- Un seul point de vérité pour : résolution de l’email invité (getEffectiveGuestNotaryEmail), appel folderSharingService.hasAccess(folderUid, "GUEST_FOLDERS", email, idNot), et réponse 404 en cas d’échec.
+
+- Réduction de la duplication entre FilesBatchDownloadGuestNotaryHelper et FilesNotaryDownloadGuestNotaryHelper.
+
+- Signature commune : verifyGuestNotaryAccess({ permissionContext, folderUid, req, response, operationLabel, logContext, contextId }) → { hasAccess: true, folderUid } | { hasAccess: false }.
+
+#### Modifications
+
+- **Création** : `lecoffre-back-main/src/app/api/common/helpers/GuestNotaryAccessVerificationHelper.ts` — exporte `verifyGuestNotaryAccess` et types associés.
+
+- **Refactor** : `FilesBatchDownloadGuestNotaryHelper.ts` — résolution du folderUid (existant), puis appel au helper commun ; suppression de la duplication email + hasAccess.
+
+- **Refactor** : `FilesNotaryDownloadGuestNotaryHelper.ts` — après verifyDocumentAndFolder, appel au helper commun ; suppression de la fonction locale verifyGuestNotaryAccess (renommée en checkGuestNotaryAccess qui délègue au helper commun). Suppression du paramètre userEmail de handleGuestNotaryFileFromFiles (l’email est résolu dans le helper commun via permissionContext).
+
+- **Appelant** : `FilesNotaryDownloadHelper.ts` — appel à handleGuestNotaryFileFromFiles sans userEmail ; extraction simplifiée (isGuestNotary uniquement si besoin).
+
+#### Modalités de déploiement
+
+Déploiement standard (build-and-deploy.sh). Aucune migration ni variable d’environnement.
+
+#### Modalités d’analyse
+
+- Téléchargement single fichier notary en notaire invité : accès autorisé uniquement si l’invité a accès au dossier via folder_sharing (GUEST_FOLDERS).
+
+- Téléchargement batch en notaire invité : même règle ; le folderUid est résolu à partir du premier fichier du batch.
+
+### Remédiation : Sièges pour affiliations actives
+
+**Date** : 2026-03-04
+**Auteur** : Équipe 4NK
+**Statut** : Implémenté
+
+#### Objectif
+
+Assurer que tout utilisateur avec une affiliation **ACTIVE** à un office disposant d’un abonnement **ACTIVE** possède bien un siège (licence) pour cet office. Cette vérification est effectuée :
+
+1.  **À la connexion (login)** : De manière automatique et non bloquante.
+
+2.  **Via script batch** : Pour remédiation de masse.
+
+#### Modifications
+
+##### 1. Backend - Services
+
+*   **`UserOfficeAffiliationsService`** : Ajout de la méthode `ensureSeatsForUserActiveAffiliations(userUid)`.
+    *   Récupère les affiliations actives.
+    *   Pour chaque affiliation, vérifie/crée le siège via `SubscriptionsService`.
+
+*   **`SubscriptionsService`** : Modification de `isUserSubscribed`.
+    *   Pour les abonnements **UNLIMITED**, si le siège n'existe pas, il est créé automatiquement à la volée.
+    *   Pour les abonnements **STANDARD**, le comportement reste une simple vérification (retourne `false` si pas de siège).
+
+##### 2. Backend - Flux de connexion
+
+*   **`UserControllerLoginFlowAuthHelper`** :
+    *   Appel de `ensureSeatsForUserActiveAffiliations` après la synchronisation IdNot.
+    *   Exécuté dans un `try/catch` pour ne pas bloquer le login en cas d'erreur technique.
+
+##### 3. Scripts
+
+*   **Analyse SQL** : `scripts/analyze-seats-vs-affiliations.sql`
+    *   Liste les utilisateurs avec affiliation ACTIVE mais sans siège dans un office avec abonnement ACTIVE.
+
+*   **Remédiation Batch** : `src/scripts/ensure-seats-for-active-affiliations.ts`
+    *   Parcourt tous les utilisateurs et lance la vérification `ensureSeatsForUserActiveAffiliations`.
+
+#### Modalités de déploiement
+
+1.  **Analyse préalable (Obligatoire)** :
+    Exécuter le script SQL pour identifier les écarts avant correction.
+    ```bash
+    psql "$DATABASE_URL" -f scripts/analyze-seats-vs-affiliations.sql
+    ```
+
+2.  **Exécution du script de remédiation** :
+    ```bash
+    # Dry-run (simulation)
+    npm run ensure:seats -- --dry-run
+    
+    # Exécution réelle
+    npm run ensure:seats
+    ```
+
+3.  **Analyse post-remédiation (Obligatoire)** :
+    Ré-exécuter le script SQL pour confirmer la résolution des écarts.
+    ```bash
+    psql "$DATABASE_URL" -f scripts/analyze-seats-vs-affiliations.sql
+    ```
+
+#### Modalités d'analyse
+
+*   Vérifier les logs avec `[ensureSeats]` ou `[SubscriptionsService]`.
+
+*   Utiliser le script SQL d'analyse pour vérifier qu'il n'y a plus d'écarts.
+
+## Correctifs additionnels documentés
+### Correctifs espace notaire invité (retour, téléchargement, note dossier)
+
+**Date** : 2026-03-02
+
+#### Problèmes
+
+1. **Lien retour après visualisation d’un document envoyé**  
+   Depuis la page « Documents envoyés par le notaire », clic sur un document puis sur Retour renvoyait vers la home (/folders) au lieu de la liste des documents envoyés.
+
+2. **Téléchargement de fichier avec accent**  
+   Télécharger un fichier (filigrane + métadonnées) dont le nom contient des accents pouvait mal s’afficher ou mal se nommer (Content-Disposition sans guillemets autour du filename).
+
+3. **Note à la création du dossier**  
+   La note saisie à la création du dossier ne s’affichait pas sur la page « Préparer le dossier » (add/clients) après redirection ; elle n’apparaissait qu’après modification ultérieure sur la fiche dossier.
+
+#### Cause / root cause
+
+1. **Retour**  
+   L’URL de retour dans ViewDocuments (Folder) est calculée via `useReceivedDocumentBackUrl`. Pour le notaire invité, elle dépend de `document.shared_to_office` et du statut SENT/DOWNLOADED. Lorsque le document est chargé via l’API DocumentsNotary (customer), `shared_to_office` n’est pas inclus dans la réponse, donc la condition échouait et on retombait sur l’URL par défaut (FolderInformation ou vide → home). Root cause : pas de fallback quand l’utilisateur est notaire invité avec un folderUid connu.
+
+2. **Téléchargement**  
+   Dans `FilesNotaryDownloadHelper`, le header Content-Disposition utilisait `filename=${encodeURIComponent(...)}` sans guillemets. La RFC 2183 recommande une valeur entre guillemets pour les noms avec caractères spéciaux/accents. De plus, le nom utilisé était uniquement `file_name` au lieu de privilégier `display_name` quand disponible.
+
+3. **Note**  
+   La note (description) est bien envoyée à la création et persistée en base. La page add/clients charge le dossier via GET /notary/folders/:uid mais ne mettait dans `folderMetadata` que `number` et `name`, pas `description`, et n’affichait nulle part la note sur « Préparer le dossier ».
+
+#### Correctifs
+
+1. **Retour (viewDocumentsBackUrlHelpers.ts)**  
+   - Ajout d’un fallback : si l’utilisateur est notaire invité et que `folderUid` est défini, l’URL de retour est toujours `InvitedReceivedDocuments` (liste des documents envoyés), même lorsque le document n’a pas encore `shared_to_office` dans la réponse (ex. chargement via DocumentsNotary API).
+
+2. **Téléchargement (FilesNotaryDownloadHelper.ts)**  
+   - Utilisation de `display_name` si présent, sinon `file_name`.  
+   - Content-Disposition : `filename="${encodeURIComponent(fileName)}"` (guillemets autour de la valeur).
+
+3. **Note (AddClientToFolder)**  
+   - `FolderMetadata` étendu avec `description?: string | null`.  
+   - Dans `folderPageDataLoaderHelpers`, passage de `description` depuis le dossier chargé à `setFolderMetadata`.  
+   - Sur la page add/clients, affichage d’un bloc « Note du dossier » sous le sous-titre lorsque `folderMetadata.description` est renseigné (style `.folder-note` dans `classes.module.scss`).
+
+#### Modifications
+
+- `lecoffre-front-main/src/front/Components/Layouts/Folder/ViewDocuments/helpers/viewDocumentsBackUrlHelpers.ts`
+
+- `lecoffre-back-main/src/app/api/notary/helpers/FilesNotaryDownloadHelper.ts`
+
+- `lecoffre-front-main/src/front/Components/Layouts/Folder/AddClientToFolder/types.ts`
+
+- `lecoffre-front-main/src/front/Components/Layouts/Folder/AddClientToFolder/hooks/helpers/folderPageDataLoaderHelpers.ts`
+
+- `lecoffre-front-main/src/front/Components/Layouts/Folder/AddClientToFolder/index.tsx`
+
+- `lecoffre-front-main/src/front/Components/Layouts/Folder/AddClientToFolder/classes.module.scss`
+
+#### Environnements
+
+Les correctifs sont côté code (front + back) et s’appliquent à tous les environnements (test, pprod, prod) après déploiement. Aucune configuration spécifique par environnement.
+
+#### Modalités de déploiement
+
+Déploiement standard (build-and-deploy.sh). Aucune migration ni variable d’environnement.
+
+#### Modalités d’analyse
+
+- **Retour** : se connecter en notaire invité, ouvrir un dossier partagé, aller dans « Documents envoyés par le notaire », ouvrir un document, cliquer sur Retour → la page doit être la liste des documents envoyés, pas la home.
+
+- **Téléchargement** : en notaire invité (ou notaire), télécharger un document dont le fichier a un nom avec accents (et si possible filigrane) → le nom du fichier téléchargé doit être correct et lisible.
+
+- **Note** : créer un dossier avec une note « Note de dossier » renseignée, valider → après redirection sur « Préparer le dossier », la note doit apparaître sous le sous-titre.
+
+### Problème : Note de dossier non sauvegardée à la création
+
+#### Description du problème
+Lors de la création d'un dossier, la note saisie dans le champ "Note de dossier" n'était pas sauvegardée. Le champ apparaissait vide après la création.
+
+#### Cause
+Le champ `description` (qui contient la note) dans la classe `OfficeFolder` (ressource Notary) n'avait pas de décorateur de validation pour le groupe `createFolder`.
+Lors de la validation de l'entité avec `class-validator` et l'option `whitelist: true`, les propriétés sans décorateur de validation actif pour le groupe donné sont supprimées de l'objet.
+Comme `description` n'avait que `@IsOptional({ groups: ["updateFolder"] })`, il était ignoré et supprimé lors de la validation avec le groupe `createFolder`.
+
+#### Correction
+Ajout du groupe `createFolder` au décorateur `@IsOptional` pour les champs `description`, `archived_description` et `status` dans `lecoffre-ressources-dev/src/Notary/OfficeFolder.ts`.
+
+```typescript
+  @Expose()
+  @IsOptional({ groups: ["createFolder", "updateFolder"] })
+  public override description: string | null = null;
+
+  @Expose()
+  @IsOptional({ groups: ["createFolder", "updateFolder"] })
+  public override archived_description: string | null = null;
+
+  @Expose()
+  @IsOptional({ groups: ["createFolder", "updateFolder"] })
+  public override status: EFolderStatus | string = EFolderStatus.LIVE;
+```
+
+#### Impacts
+
+- La note de dossier est maintenant correctement sauvegardée à la création.
+
+- `archived_description` et `status` sont également correctement traités s'ils sont fournis à la création (bien que `status` ait une valeur par défaut).
+
+#### Modalités de déploiement
+
+- Recompiler `lecoffre-ressources-dev`.
+
+- Redéployer le backend pour prendre en compte la nouvelle version de la ressource.
+
+### Correction V2 : Injection de dépendance circulaire dans OfficesService (ESM)
+
+**Date :** 04/03/2026
+**Auteur :** Équipe 4NK
+
+#### Problème
+Malgré le fix précédent (lazy loading via getter), une erreur persistait lors de l'exécution sur l'environnement de test (ESM) :
+```text
+TypeError: this.officesRibService.uploadEncryptedRibFromFiles is not a function
+```
+Cela indique que `OfficesRibService` est toujours injecté comme un objet vide `{}` à cause de la dépendance circulaire, même avec le getter, car l'import statique `import OfficesRibService from "./OfficesRibService"` est évalué au chargement du module et résolu en `{}` si le cycle n'est pas résolu.
+
+#### Analyse
+
+- **Cause racine :** Dépendance circulaire persistante. Dans un environnement ESM, si un module est importé avant d'être complètement évalué (cycle), l'import par défaut peut être un objet vide ou incomplet.
+
+- **Échec du fix précédent :** Le getter utilisait `Container.get(OfficesRibService)`, mais `OfficesRibService` (le symbole importé) était déjà `{}`.
+
+#### Solution
+Utilisation de l'import dynamique `await import(...)` à l'intérieur des méthodes pour garantir que le module est complètement chargé avant utilisation.
+
+##### Modifications
+
+1. Remplacement des imports statiques par `import type`.
+
+2. Remplacement des getters synchrones par des méthodes privées asynchrones `getOfficesRibService()` et `getOfficesAnchorService()`.
+
+3. Utilisation de `await import("./OfficesRibService")` pour récupérer la classe au runtime.
+
+4. Mise à jour de toutes les méthodes appelantes pour être `async` (elles l'étaient déjà) et utiliser `await this.getOfficesRibService()`.
+
+```typescript
+// Avant
+import OfficesRibService from "./OfficesRibService";
+// ...
+private get officesRibService(): OfficesRibService {
+    return Container.get(OfficesRibService);
+}
+
+// Après
+import type OfficesRibService from "./OfficesRibService";
+// ...
+private async getOfficesRibService(): Promise<OfficesRibService> {
+    const { default: OfficesRibServiceClass } = await import("./OfficesRibService");
+    return Container.get(OfficesRibServiceClass);
+}
+```
+
+#### Vérification
+
+- Le code compile.
+
+- L'import dynamique casse le cycle de dépendance au niveau du chargement des modules.
+
+### Correction : Injection de dépendance circulaire dans OfficesService
+
+**Date :** 04/03/2026
+**Auteur :** Équipe 4NK
+
+#### Problème
+Le démarrage du backend échouait avec l'erreur suivante :
+```text
+Error: OfficesRibService injected but missing uploadEncryptedRibFromFiles method. Injected type: Object
+```
+Cela indiquait que `OfficesRibService` était injecté comme un objet vide `{}` au lieu de l'instance de la classe, symptôme classique d'une dépendance circulaire mal gérée par le système d'injection de dépendances (TypeDI) lors de l'initialisation.
+
+#### Analyse
+
+- **Cause racine :** Dépendance circulaire entre `OfficesService` et `OfficesRibService` (probablement via `OfficesRibProcessingHelper` ou d'autres dépendances partagées).
+
+- **Impact :** Le service `OfficesService` tentait d'accéder à `OfficesRibService` dans son constructeur alors que ce dernier n'était pas encore totalement initialisé.
+
+#### Solution
+Mise en place du **Lazy Loading** pour les services problématiques dans `OfficesService`.
+
+##### Modifications
+
+1. Suppression de `officesRibService` et `officesAnchorService` du constructeur de `OfficesService`.
+
+2. Utilisation de getters pour récupérer ces services via `Container.get()` uniquement au moment de leur utilisation.
+
+```typescript
+// Avant
+constructor(private officesRibService: OfficesRibService) { ... }
+
+// Après
+private get officesRibService(): OfficesRibService {
+    return Container.get(OfficesRibService);
+}
+```
+
+#### Vérification
+
+- Le code compile et les linters passent.
+
+- Cette approche est déjà utilisée dans `WatermarkService` pour résoudre des problèmes similaires.
+
+### Correction : Extension manquante dans l'import dynamique de OfficesService
+
+**Date :** 2026-03-04
+**Auteur :** Équipe 4NK
+
+#### Problème
+
+Une erreur 500 survenait lors du téléchargement du RIB :
+`Cannot find module '.../services/notary/OfficesService/OfficesService.js'`
+
+Cette erreur indiquait que Node.js n'arrivait pas à charger le module `OfficesService`, probablement à cause d'une erreur d'import interne.
+
+#### Cause racine
+
+Le fichier `OfficesService.ts` utilisait des imports dynamiques relatifs (`await import("./OfficesRibService")`) sans spécifier l'extension `.js`.
+Dans un environnement Node.js ESM (configuré avec `"type": "module"`), les imports relatifs doivent obligatoirement inclure l'extension du fichier.
+
+#### Correctif
+
+Ajout de l'extension `.js` aux imports dynamiques dans `src/services/notary/OfficesService/OfficesService.ts` :
+
+```typescript
+// Avant
+const { default: OfficesRibServiceClass } = await import("./OfficesRibService");
+const { default: OfficesAnchorServiceClass } = await import("./OfficesAnchorService");
+
+// Après
+const { default: OfficesRibServiceClass } = await import("./OfficesRibService.js");
+const { default: OfficesAnchorServiceClass } = await import("./OfficesAnchorService.js");
+```
+
+#### Impact
+
+- `src/services/notary/OfficesService/OfficesService.ts`
+
+#### Vérification
+
+Le déploiement est nécessaire pour vérifier la correction.
+L'erreur de téléchargement du RIB devrait disparaître.
+
+#### Autre correction incluse
+
+Ajout de la clé de traduction manquante `components.dropdown.defaultAriaLabel` dans `.secrets/test/seed-site-texts-test.ts` pour corriger l'erreur frontend :
+`[Front] 🚫 [SiteTextsStore] Missing site text {textKey: 'components.dropdown.defaultAriaLabel', locale: 'fr-FR'}`
+
+### Fix: Erreur téléchargement ZIP "files-notary" (Notaire invité)
+
+#### Problème
+Lorsqu'un notaire invité tente de télécharger plusieurs documents (ZIP) depuis la vue "Documents envoyés par le notaire", une erreur survient et l'utilisateur est parfois déconnecté.
+Le frontend appelle l'endpoint `POST /api/v1/notary/files-notary/download-multiple`, mais celui-ci n'était pas implémenté dans le contrôleur `FilesNotaryController`.
+
+#### Cause Racine
+L'endpoint `downloadMultiple` manquait dans `FilesNotaryController`. Bien que le helper `FilesBatchDownloadHelper` existe, il était câblé uniquement pour les fichiers standards (`FilesService`) et utilisé seulement par `FilesController`.
+
+#### Correctifs
+
+1.  **Modification de `FilesBatchDownloadHelper` et `FilesBatchDownloadZipHelper`** :
+    *   Ajout du paramètre `isNotaryFiles` (booléen, défaut `false`) pour indiquer si le téléchargement concerne des fichiers notaire (`FilesNotaryService`) ou standards.
+    *   Propagation de ce paramètre jusqu'à `ZipService.createZipFromFiles` qui supportait déjà cette option.
+
+2.  **Mise à jour de `FilesNotaryController`** :
+    *   Injection de `ZipService`.
+    *   Instanciation de `FilesBatchDownloadHelper`.
+    *   Ajout de la méthode `downloadMultiple` exposant la route `POST /api/v1/notary/files-notary/download-multiple` et appelant le helper avec `isNotaryFiles: true`.
+
+#### Impacts
+
+- `lecoffre-back-main/src/app/api/notary/helpers/FilesBatchDownloadHelper.ts`
+
+- `lecoffre-back-main/src/app/api/notary/helpers/FilesBatchDownloadZipHelper.ts`
+
+- `lecoffre-back-main/src/app/api/notary/FilesNotaryController.ts`
+
+#### Modalités de déploiement
+Déploiement standard du backend.
+
+#### Modalités d'analyse
+Vérifier le téléchargement multiple (ZIP) en tant que notaire invité sur des documents partagés par le notaire principal.
+
+### Correction de l'avertissement de préchargement de police non utilisé et migration next/font
+
+**Date :** 04/03/2026
+**Auteur :** Équipe 4NK
+
+#### Problème
+L'application affichait un avertissement dans la console du navigateur :
+`La ressource à l’adresse « ... » préchargée avec le préchargement de lien n’a pas été utilisée après quelques secondes.`
+De plus, certaines parties de l'application utilisaient encore des définitions de polices en dur ("Poppins", "Inter") au lieu d'utiliser le système optimisé de Next.js (`next/font`).
+
+#### Cause
+L'application utilise `next/font/google` pour charger les polices "Inter" et "Poppins" de manière optimisée. `next/font` génère des noms de classes et des variables CSS uniques pour isoler les polices.
+Cependant, plusieurs fichiers SCSS référençaient les noms de polices en dur ("Poppins", "Inter") au lieu d'utiliser les variables CSS injectées par `next/font` (`var(--font-poppins)`, `var(--font-inter)`).
+En conséquence :
+
+1. Le navigateur téléchargeait la police préchargée par `next/font`.
+
+2. Le CSS demandait une autre police (système ou téléchargée séparément), rendant le préchargement inutile et causant un double téléchargement.
+
+3. Risque de Cumulative Layout Shift (CLS) accru.
+
+#### Correctifs
+
+1.  **Variables globales (`variables.scss`) :**
+    - Remplacement de `font-family: "Poppins", ...` par `font-family: var(--font-poppins), ...`.
+
+2.  **Styles globaux (`index.scss`) :**
+    - Remplacement de `font-family: "Inter", ...` par `font-family: var(--font-inter), ...`.
+
+3.  **Composants spécifiques :**
+    - Remplacement des fallbacks `Poppins` par `sans-serif` dans les fichiers suivants pour utiliser correctement la variable CSS héritée ou définie :
+        - `src/front/Components/Elements/NumberPicker/classes.module.scss`
+        - `src/front/Components/DesignSystem/SearchBar/classes.module.scss`
+        - `src/front/Components/DesignSystem/Form/TextField/classes.module.scss`
+        - `src/front/Components/DesignSystem/Form/TextareaField/classes.module.scss`
+        - `src/front/Components/DesignSystem/AutocompleteMultiSelect/ChipContainer/classes.module.scss`
+        - `src/front/Components/DesignSystem/Footer/classes.module.scss`
+
+#### Impacts
+
+- Disparition de l'avertissement dans la console.
+
+- Meilleure performance de chargement des polices (pas de double téléchargement).
+
+- Élimination du Layout Shift (CLS) lié aux polices.
+
+- Cohérence totale de la gestion des polices via `next/font`.
+
+#### Modalités de déploiement
+Déploiement standard de l'application frontend `lecoffreio`.
+
+#### Modalités d'analyse
+Vérifier dans la console du navigateur (Chrome/Firefox) que l'avertissement concernant le préchargement des polices n'apparaît plus lors du chargement de l'application.
+Vérifier visuellement que les polices s'affichent correctement (Inter pour le corps, Poppins pour les titres/textes spécifiques).
+
+### Correction de l'affichage des polices et support des Portals
+
+#### Problème
+Les polices (Inter et Poppins) chargées via `next/font` ne s'affichaient pas correctement :
+
+1. Avertissement "Ressource préchargée non utilisée".
+
+2. Polices non appliquées sur les éléments rendus via React Portals (modales, tooltips, etc.).
+
+3. Polices non appliquées sur le `body` (fallback vers Serif).
+
+#### Cause
+
+1. `next/font` génère des noms de classes et de variables CSS uniques (hashés).
+
+2. Pour que Next.js inclue les définitions `@font-face` dans le build, les classes générées (`inter.variable`, etc.) doivent être utilisées dans le rendu.
+
+3. Les Portals rendent leur contenu en dehors de l'arbre React principal (souvent directement dans `body`), donc ils n'héritent pas des variables CSS définies sur un conteneur racine (`#__next > div`).
+
+4. Le fichier `index.scss` ne définissait pas explicitement `font-family` sur le `body`, laissant le navigateur utiliser la police par défaut (Serif) si aucune autre règle ne s'appliquait.
+
+5. `variables.scss` utilisait `Poppins` comme police de texte par défaut au lieu de `Inter`.
+
+#### Solution
+
+##### 1. Chargement des polices (`src/pages/_app.tsx`)
+
+- Configuration de `Inter` et `Poppins` avec `next/font/google` et l'option `variable`.
+
+- Application des classes générées (`inter.variable`, `poppins.variable`) sur un `div` conteneur entourant l'application. Cela force Next.js à inclure les polices dans le build.
+
+- Injection des variables CSS au niveau global (`:root`) via `<style jsx global>` pour qu'elles soient accessibles partout, y compris dans les Portals.
+
+```typescript
+// src/pages/_app.tsx
+const page = (
+    <>
+        <style jsx global>{`
+            :root {
+                --font-inter: ${inter.style.fontFamily};
+                --font-poppins: ${poppins.style.fontFamily};
+            }
+        `}</style>
+        <Component {...pageProps} />
+        {/* ... */}
+    </>
+);
+
+return (
+    <div className={`${inter.variable} ${poppins.variable}`}>
+        {/* ... providers ... */}
+        {getLayout(page)}
+    </div>
+);
+```
+
+##### 2. Application des styles (`src/front/index.scss`)
+
+- Ajout explicite de la famille de police sur le `body` pour assurer l'héritage par défaut.
+
+```scss
+// src/front/index.scss
+body {
+    // ...
+    font-family: var(--font-inter), sans-serif;
+}
+```
+
+##### 3. Variables SCSS (`src/front/Themes/variables.scss`)
+
+- Mise à jour de `--font-text-family` pour utiliser `Inter` (via `var(--font-inter)`) au lieu de `Poppins`.
+
+```scss
+// src/front/Themes/variables.scss
+--font-text-family: var(--font-inter), sans-serif;
+```
+
+#### Vérification
+
+- Vérifier que les requêtes réseau pour les fichiers `.woff2` sont bien effectuées (Code 200).
+
+- Vérifier que les variables CSS `--font-inter` et `--font-poppins` sont définies sur `:root` et sur le conteneur principal.
+
+- Vérifier que le texte du corps utilise bien `Inter` et les titres `Poppins`.
+
+### Suppression des logs info et debug
+
+**Date :** 04/03/2026
+**Auteur :** Équipe 4NK
+
+#### Problème
+Les logs de niveau `info` et `debug` étaient trop verbeux et pouvaient potentiellement exposer des informations sensibles ou encombrer les sorties de logs en production.
+
+#### Impacts
+
+- Réduction du volume de logs.
+
+- Amélioration de la sécurité (moins de risque de fuite d'informations).
+
+- Meilleure lisibilité des logs (focus sur `warn` et `error`).
+
+#### Cause
+Configuration par défaut des wrappers de logs qui laissait passer tous les niveaux.
+
+#### Root Cause
+Absence de filtrage ou de désactivation explicite des niveaux `info` et `debug` dans les utilitaires de logging centralisés.
+
+#### Corrections
+
+- Désactivation des méthodes `log`, `info` et `debug` dans `lecoffre-back-main/src/common/helpers/LogSanitizer.ts`.
+
+- Désactivation des méthodes `info` et `debug` dans `lecoffre-front-main/src/front/Services/LoggerService/LoggerServiceClass.ts`.
+
+- Correction d'une erreur de type (variable inutilisée) dans `lecoffre-front-main/src/front/Api/BaseApiServiceFactory.ts` détectée lors du typecheck.
+
+#### Modifications
+
+- `lecoffre-back-main/src/common/helpers/LogSanitizer.ts` : Commentaire du corps des fonctions `log`, `info`, `debug`.
+
+- `lecoffre-front-main/src/front/Services/LoggerService/LoggerServiceClass.ts` : Commentaire du corps des fonctions `info`, `debug`.
+
+- `lecoffre-front-main/src/front/Api/BaseApiServiceFactory.ts` : Suppression de la variable `token` inutilisée.
+
+#### Modalités de déploiement
+Déploiement standard via le script de déploiement. Aucune action spécifique requise.
+
+#### Modalités d'analyse
+Vérifier que les logs `info` et `debug` n'apparaissent plus dans les sorties de l'application, mais que les `warn` et `error` sont toujours présents.
+
+### Fix: Erreur "this.officesRibService.uploadEncryptedRibFromFiles is not a function"
+
+#### Problème
+Lors de l'upload d'un RIB par un notaire, une erreur 500 survenait avec le message `technicalMessage: 'this.officesRibService.uploadEncryptedRibFromFiles is not a function'`.
+
+#### Cause Racine
+Le service `OfficesRibService` était enregistré deux fois dans le conteneur d'injection de dépendances (TypeDI) :
+
+1. Via le décorateur `@Service()` sur la classe.
+
+2. Via `Container.set()` avec une factory à la fin du fichier.
+
+Cette double déclaration créait une ambiguïté. TypeDI injectait probablement une instance créée via le constructeur par défaut (à cause de `@Service()`) au lieu d'utiliser la factory. Comme le constructeur attend une interface `OfficesRibServiceDeps` que TypeDI ne peut pas résoudre automatiquement, l'instance injectée était probablement mal initialisée ou vide.
+
+#### Correctifs
+
+1. Suppression du décorateur `@Service()` dans `OfficesRibService.ts` pour forcer l'utilisation de la factory définie par `Container.set()`.
+
+2. Suppression du décorateur `@Service()` dans `OfficesAnchorService.ts` (même pattern identifié).
+
+3. Ajout de vérifications de sécurité dans le constructeur de `OfficesService.ts` pour lever une erreur explicite si les services injectés sont invalides ou incomplets.
+
+#### Impacts
+
+- `lecoffre-back-main/src/services/notary/OfficesService/OfficesRibService.ts`
+
+- `lecoffre-back-main/src/services/notary/OfficesService/OfficesAnchorService.ts`
+
+- `lecoffre-back-main/src/services/notary/OfficesService/OfficesService.ts`
+
+#### Modalités de déploiement
+Déploiement standard du backend.
+
+#### Modalités d'analyse
+Vérifier les logs lors de l'upload de RIB. L'erreur ne doit plus apparaître.
+Si une erreur d'injection survient, elle sera désormais explicite grâce aux checks ajoutés dans `OfficesService`.
+
+### Correction de l'erreur "Response body is already used"
+
+**Date :** 04/03/2026
+**Auteur :** Équipe 4NK
+
+#### Problème
+L'application frontend rencontrait une erreur critique lors du chargement des textes (`SiteTextsProvider`) ou d'autres appels API :
+`Failed to execute 'clone' on 'Response': Response body is already used`
+Cette erreur provoquait potentiellement un crash ou un comportement instable, empêchant notamment le chargement correct des polices (si lié au rendu bloqué).
+
+#### Cause
+Dans `BaseApiServiceResponseHandler.handleErrorResponse` (et potentiellement `processResponse`), la méthode `response.clone()` était appelée sans vérifier si le corps de la réponse avait déjà été consommé (`response.bodyUsed`).
+Si une requête échouait (ex: 404, 500) et que le corps avait été lu précédemment (par exemple par `response.text()` dans `processResponse` avant de détecter une erreur JSON, ou par une autre logique), l'appel à `clone()` levait une exception non gérée correctement à ce niveau.
+
+#### Correctifs
+
+1.  **Sécurisation de `handleErrorResponse` (`BaseApiServiceResponseHandler.ts`) :**
+    - Ajout d'une vérification `if (!response.bodyUsed)` avant de tenter `response.clone()`.
+    - Gestion du cas où le corps est déjà utilisé : on ne tente pas de le relire, on renvoie un message d'erreur générique ("Response body was already consumed") ou on utilise le texte extrait précédemment si disponible (via `responseCopy`).
+
+2.  **Sécurisation de `processResponse` (`responseHelpers.ts`) :**
+    - Ajout d'une vérification similaire avant `response.clone()` pour le parsing JSON.
+    - Passage explicite de `responseClone` (nullable) à `parseJsonResponse`.
+
+#### Impacts
+
+- Disparition de l'erreur "Response body is already used".
+
+- Meilleure résilience de l'application face aux erreurs API.
+
+- Les erreurs API réelles (404, 500) seront désormais correctement loggées et traitées au lieu d'être masquées par un crash technique.
+
+#### Modalités de déploiement
+Déploiement standard de l'application frontend `lecoffreio`.
+
+#### Modalités d'analyse
+
+- Vérifier dans la console que l'erreur "Response body is already used" n'apparaît plus.
+
+- Si des erreurs API surviennent (ex: `SiteTextsApi`), vérifier qu'elles sont loggées avec leur statut et message corrects.
+
+### Correction du chargement des textes du site et de l'erreur response.clone()
+
+**Date :** 04/03/2026
+**Auteur :** Équipe 4NK
+
+#### Problème
+L'application frontend rencontrait une erreur critique au démarrage : `Failed to execute 'clone' on 'Response': Response body is already used`.
+Cette erreur empêchait le chargement des textes du site (`SiteTexts`), ce qui pouvait entraîner un affichage dégradé (polices non chargées, textes manquants).
+
+#### Impacts
+
+- Échec du chargement des `SiteTexts`.
+
+- Affichage potentiellement cassé de l'application.
+
+- Logs d'erreurs critiques dans la console.
+
+#### Cause
+Dans `responseHelpers.ts`, la méthode `response.text()` était appelée pour lire le corps de la réponse, consommant ainsi le flux. Ensuite, `response.clone()` était appelé pour passer une copie à `parseJsonResponse`, ce qui échouait car le corps était déjà consommé.
+
+#### Root Cause
+Mauvaise séquence d'opérations : tentative de clonage d'une réponse après consommation de son corps.
+
+#### Corrections
+
+- Modification de `lecoffre-front-main/src/front/Api/helpers/responseHelpers.ts` pour cloner la réponse (`response.clone()`) **avant** de consommer le corps avec `response.text()`.
+
+#### Modifications
+
+- `lecoffre-front-main/src/front/Api/helpers/responseHelpers.ts` : Déplacement de l'appel à `response.clone()` avant le bloc `try/catch` de lecture du texte.
+
+#### Modalités de déploiement
+Déploiement standard via le script de déploiement.
+
+#### Modalités d'analyse
+Vérifier dans les logs du navigateur que l'erreur `Failed to execute 'clone' on 'Response'` a disparu et que les appels à `/api/v1/public/site-texts` réussissent. Vérifier que l'application s'affiche correctement avec les bonnes polices.
+
+### Stockage des e-mails clients (V1 et V2) et lecture seule base V1
+
+**Où sont stockés les e-mails des clients :**
+
+- Table **`contacts`** : colonne **`email`** (type `character varying(255)`, NOT NULL). Les clients (customers) sont liés via `customers.contact_uid` → `contacts.uid`. L’email client est donc **`contacts.email`**.
+- Les utilisateurs (users) ont aussi un lien `users.contact_uid` → `contacts.uid` et peuvent avoir un champ email propre sur `users`.
+
+**Vérification en lecture seule sur la base V1 (ex. depuis prod) :**
+
+- Ne pas se connecter en SSH depuis l’automatisation (règle projet). Exécuter le script **sur** la cible (après connexion manuelle ou via un job que vous lancez).
+- Sur le serveur (ex. prod) : depuis `$APP_ROOT` (ex. `/srv/4NK/prod.lecoffreio.4nkweb.com`), lancer :
+  - `bash deploy/scripts_v2/remote/read-v1-contacts-emails.sh prod "$APP_ROOT"`
+- Le script lit la config V1 dans `.secrets/<env>/.env.<env>.connectDB` (DATABASE_V1_*), se connecte en **lecture seule** à la base V1 et affiche : structure de la table `contacts`, effectifs contacts/customers, statistiques sur les longueurs d’email (aucun email en clair).
+- Prérequis sur la cible : `psql`, et le fichier `.env.<env>.connectDB` présent dans `.secrets/<env>/`.
+
+## Lien avec Gitea et traitement des issues par un agent
+
+Le dépôt est hébergé sur Gitea à l’URL **https://git.4nkweb.com/4nk/lecoffre_ng** (VM distante, distincte du serveur « services » 192.168.1.104). Les issues sont visibles sur **https://git.4nkweb.com/4nk/lecoffre_ng/issues**.
+
+### Comment le projet « branche » sur les issues
+
+- **Convention actuelle** : le README décrit une branche feature (`feature/nouvelle-fonctionnalite`), push direct (pas de pull request). Il n’existe pas de convention formelle « une branche par issue » ou « nom de branche = numéro d’issue » dans la doc.
+- **Lien possible** : pour associer une branche à une issue, on peut utiliser par exemple `issue/<numéro>` ou `feature/issue-<numéro>-titre-court`. Le numéro d’issue permet de retrouver le ticket dans Gitea et, si besoin, de le commenter ou de le fermer depuis un agent.
+
+### Arbitrage des pull requests en cours
+
+- **Workflow** : le code est intégré par **push direct** sur les branches (test, pprod, prod). Les pull requests ouvertes sur Gitea peuvent être **fermées sans merger** : le code pertinent est déjà sur les branches via push direct. Pour nettoyer : sur Gitea (https://git.4nkweb.com/4nk/lecoffre_ng/pulls), fermer chaque PR ouverte en indiquant que le workflow est désormais push direct (pas de merge via PR).
+
+### Traitement des tickets (issues) depuis un agent
+
+L’accès **Git** (clone, push) utilise **SSH** (`git@git.4nkweb.com:4nk/lecoffre_ng.git`) ; la clé SSH de la machine donne les droits nécessaires pour pousser des branches.
+
+L’**API Gitea** (lister les issues, lire une issue, ajouter un commentaire, etc.) est en **HTTPS** et nécessite un **token d’accès** (Personal Access Token), pas la clé SSH.
+
+**Prérequis sur la machine qui lance l’agent :**
+
+1. **Token Gitea** : créer un token dans Gitea (Settings → Applications → Generate New Token) avec les scopes nécessaires (ex. `read:issue`, `write:issue` pour commenter). Stocker le token dans une variable d’environnement (ex. `GITEA_TOKEN`) ou dans un fichier non versionné (ex. `.secrets/gitea-token`), jamais dans le dépôt.
+2. **Accès réseau** : la machine doit pouvoir joindre `https://git.4nkweb.com` (le Gitea est sur une VM distante).
+
+**Lister les issues ouvertes (exemple curl) :**
+
+```bash
+curl -s -H "Accept: application/json" \
+  -H "Authorization: token ${GITEA_TOKEN}" \
+  "https://git.4nkweb.com/api/v1/repos/4nk/lecoffre_ng/issues?state=open&page=1&limit=50"
+```
+
+**Récupérer une issue par numéro :**
+
+```bash
+curl -s -H "Accept: application/json" \
+  -H "Authorization: token ${GITEA_TOKEN}" \
+  "https://git.4nkweb.com/api/v1/repos/4nk/lecoffre_ng/issues/<numéro>"
+```
+
+**Workflow type pour un agent :**
+
+1. Récupérer la liste des issues ouvertes (ou filtrer par label/milestone si besoin).
+2. Pour chaque issue (ou une issue ciblée) :
+   - Créer une branche dédiée (ex. `issue/123` ou `feature/issue-123-titre`) depuis la branche de travail (ex. `test`).
+   - Lancer l’agent adapté selon le type de ticket : **/fix** pour une anomalie, **/evol** pour une évolution (voir `.cursor/agents/fix.md`, `.cursor/agents/evol.md`), en utilisant le titre et la description de l’issue comme consigne.
+   - Après correction/évolution : commit, push (`/push-by-script`), **ne jamais créer de pull request**. Optionnellement commenter l'issue via l’API Gitea (POST `/repos/4nk/lecoffre_ng/issues/<num>/comments`).
+
+**Référence API Gitea :** <https://docs.gitea.com/api/1.25/> (tag « issue » pour les endpoints issues).
+
+**Scripts et agent dédiés :** le dossier **`gitea-issues/`** à la racine du dépôt contient les scripts (list-open-issues.sh, get-issue.sh, print-issue-prompt.sh, create-branch-for-issue.sh, comment-issue.sh) et l'agent **/gitea-issues-process** (`.cursor/agents/gitea-issues-process.md`) orchestre le traitement des tickets en s'appuyant uniquement sur ces scripts. Voir `gitea-issues/README.md`.
diff --git a/projects/lecoffreio/docs/README.md b/projects/lecoffreio/docs/README.md
new file mode 100644
index 0000000..82353dc
--- /dev/null
+++ b/projects/lecoffreio/docs/README.md
@@ -0,0 +1,34 @@
+# Documentation technique LeCoffre.io
+
+La documentation technique permanente est hébergée sur le **wiki** du dépôt.
+
+- **Page d'accueil du wiki** : [Home](https://git.4nkweb.com/4nk/lecoffre_ng/wiki/Home)
+- **Index complet du wiki** : https://git.4nkweb.com/4nk/lecoffre_ng/wiki
+
+## Correspondance anciens fichiers docs/ → pages wiki
+
+| Ancien fichier | Page wiki |
+|----------------|-----------|
+| OPERATIONS.md | [Operations](https://git.4nkweb.com/4nk/lecoffre_ng/wiki/Operations) |
+| DEPLOYMENT.md | [Deployment](https://git.4nkweb.com/4nk/lecoffre_ng/wiki/Deployment) |
+| API.md | [Api](https://git.4nkweb.com/4nk/lecoffre_ng/wiki/Api) |
+| ARCHITECTURE.md | [Architecture](https://git.4nkweb.com/4nk/lecoffre_ng/wiki/Architecture) |
+| CODE_STANDARDS.md | [Code-Standards](https://git.4nkweb.com/4nk/lecoffre_ng/wiki/Code-Standards) |
+| FRONTEND.md | [Frontend](https://git.4nkweb.com/4nk/lecoffre_ng/wiki/Frontend) |
+| SCRIPTS.md | [Scripts](https://git.4nkweb.com/4nk/lecoffre_ng/wiki/Scripts) |
+| MIGRATION.md | [Migration](https://git.4nkweb.com/4nk/lecoffre_ng/wiki/Migration) |
+| README.md | [Readme](https://git.4nkweb.com/4nk/lecoffre_ng/wiki/Readme) |
+| Autres | Voir l’index du wiki |
+
+Pour mettre à jour le wiki après modification locale : exécuter `./gitea-issues/wiki-migrate-docs.sh` (voir `gitea-issues/README.md`).
+
+## Autres emplacements (hors wiki)
+
+- **../user_stories/** : User stories, tests, accessibilité
+- **../todoFix/** : Tâches en cours
+- **../CHANGELOG.md** : Historique des versions
+- **../deploy/README.md** : Scripts de déploiement
+
+---
+
+**Propriétaire** : Équipe 4NK | **Projet** : LeCoffre.io
diff --git a/projects/lecoffreio/docs/SCRIPTS.md b/projects/lecoffreio/docs/SCRIPTS.md
new file mode 100644
index 0000000..416b7fa
--- /dev/null
+++ b/projects/lecoffreio/docs/SCRIPTS.md
@@ -0,0 +1,554 @@
+# | ✅ **À jour**Scripts - Documentation Complète
+
+**Dernière | ✅ **À jour**mise à jour** : 2026-01-28
+**Version** | ✅ **À jour**: 2.1.0
+
+**Référence | ✅ **À jour**unique (checks de déploiement)** : [`docs/DEPLOYMENT.md#cartographie-des-checks-de-déploiement-source-unique`](./DEPLOYMENT.md#cartographie-des-checks-de-déploiement-source-unique)
+
+Ce | ✅ **À jour**document consolide toute la documentation relative aux scripts backend (build, base de données, synchronisation, ancrage, reprocessing, analyse).
+
+---
+
+## | ✅ **À jour**📋 Table des Matières
+
+1. | ✅ **À jour**[Scripts Backend](#scripts-backend)
+2. | ✅ **À jour**[Scripts d'Ancrage V3](#scripts-dancrage-v3)
+3. | ✅ **À jour**[Scripts de Reprocessing](#scripts-de-reprocessing)
+4. | ✅ **À jour**[Scripts d'Analyse](#scripts-danalyse)
+5. | ✅ **À jour**[État des Scripts](#état-des-scripts)
+6. | ✅ **À jour**[Performances](#performances)
+7. | ✅ **À jour**[Utilisation](#utilisation)
+8. | ✅ **À jour**[Scripts backend vs deploy](#scripts-backend-vs-deploy)
+
+---
+
+## | ✅ **À jour**Scripts Backend
+
+### | ✅ **À jour**Vue d'Ensemble
+
+Tous | ✅ **À jour**les scripts backend sont disponibles en **deux versions** :
+
+1. | ✅ **À jour****Version compilée** : Pour exécution en production (sur le serveur cible)
+2. | ✅ **À jour****Version locale** : Pour développement local (suffix `:local`)
+
+**Format** | ✅ **À jour**:
+```bash
+npm | ✅ **À jour**run <script>        # Production (code compilé dans dist/)
+npm | ✅ **À jour**run <script>:local  # Développement (ts-node direct)
+```
+
+### | ✅ **À jour**Scripts de Build et Démarrage
+
+| | ✅ **À jour**Script | Commande | Description |
+|--------|---------|-------------|
+| | ✅ **À jour**`build` | `npm run build` | Compile le code TypeScript vers JavaScript |
+| | ✅ **À jour**`build-db` | `npm run build-db` | Crée une migration Prisma en mode développement |
+| | ✅ **À jour**`start` | `npm run start` | Démarre l'application API REST (port 3001) |
+| | ✅ **À jour**`cron` | `npm run cron` | Démarre les tâches planifiées |
+| | ✅ **À jour**`api:start` | `npm run api:start` | Exécute les migrations puis démarre l'API |
+| | ✅ **À jour**`dev` | `npm run dev` | Lance le serveur en mode développement avec hot-reload |
+
+### | ✅ **À jour**Scripts de Base de Données
+
+| | ✅ **À jour**Script | Commande | Description |
+|--------|---------|-------------|
+| | ✅ **À jour**`migrate` | `npm run migrate` | Déploie les migrations Prisma en production |
+| | ✅ **À jour**`seed` | `npm run seed` | Seed la base de données avec les données initiales |
+
+### | ✅ **À jour**Scripts de Configuration
+
+| | ✅ **À jour**Script | Commande | Description |
+|--------|---------|-------------|
+| | ✅ **À jour**`config:import-env` | `npm run config:import-env` | Importe les variables d'environnement depuis un fichier vers `system_configuration` |
+
+### | ✅ **À jour**Scripts d'Analyse
+
+| | ✅ **À jour**Script | Commande | Description |
+|--------|---------|-------------|
+| | ✅ **À jour**`analyze:user` | `npm run analyze:user` | Analyse le profil d'un utilisateur |
+| | ✅ **À jour**`analyze:folder` | `npm run analyze:folder` | Analyse complète d'un dossier |
+
+### | ✅ **À jour**Scripts de Remédiation
+
+| | ✅ **À jour**Script | Commande | Description |
+|--------|---------|-------------|
+| | ✅ **À jour**`ensure:seats` | `npm run ensure:seats` | Assure que les utilisateurs avec affiliation active ont un siège (création si nécessaire pour UNLIMITED) |
+
+### | ✅ **À jour**Scripts d'Activation
+
+| | ✅ **À jour**Script | Commande | Description |
+|--------|---------|-------------|
+| | ✅ **À jour**`activate:subscriptions` | `npm run activate:subscriptions` | Active automatiquement les abonnements pour des utilisateurs spécifiques |
+| | ✅ **À jour**`promote:superadmin` | `npm run promote:superadmin` | Promouvoir super-admin |
+| | ✅ **À jour**`token:get` | `npm run token:get` | Génère token super-admin |
+
+---
+
+## | ✅ **À jour**Scripts d'Ancrage V3
+
+### | ✅ **À jour**Contexte
+
+Les | ✅ **À jour**scripts d’audit et d’ancrage V3 sont disponibles en **mode host-native (scripts_v2)**.
+
+- | ✅ **À jour****Host-native (scripts_v2)** : exécution directe sur le host (PostgreSQL local port 5432, ClamAV local port 3310) avec configuration injectée via `system_configuration`.
+
+Important | ✅ **À jour**: les scripts V3 supposent que les migrations Prisma et les colonnes nécessaires sont présentes (sinon, lancer `--migrateResolveDatabase` puis relancer le script).
+
+### | ✅ **À jour**Scripts Disponibles
+
+#### | ✅ **À jour**1. Audit des Ancrages Manquants
+
+**Script** | ✅ **À jour**: `audit-missing-anchors.js`
+
+**Usage** | ✅ **À jour**:
+```bash
+# | ✅ **À jour**Version compilée (recommandée)
+ENV=prod | ✅ **À jour**npm run anchorage:audit
+
+# | ✅ **À jour**En host-native (scripts_v2) : exécuter sur la machine env avec DATABASE_URL correctement configurée
+# | ✅ **À jour**(recommandé : passer par deploy/scripts_v2/ pour garantir les variables et migrations)
+```
+
+**Description** | ✅ **À jour**:
+
+- | ✅ **À jour**Analyse tous les documents validés sans ancrage
+- | ✅ **À jour**Analyse tous les dossiers archivés sans ancrage
+- | ✅ **À jour**Génère un CSV avec la liste des documents/dossiers à réancrer
+- | ✅ **À jour**Ne modifie aucune donnée (lecture seule)
+
+**Résultat** | ✅ **À jour**:
+
+- | ✅ **À jour**Affichage console avec statistiques
+- | ✅ **À jour**CSV généré : `logs/audit-missing-anchors_YYYYMMDD_HHMMSS.csv`
+
+#### | ✅ **À jour**2. Ancrage V3 de Dossiers Existants
+
+**Script** | ✅ **À jour**: `anchor-existing-folders-v3.js`
+
+**Usage** | ✅ **À jour**:
+```bash
+# | ✅ **À jour**Ancrage tous dossiers LIVE + ARCHIVED (par défaut depuis v2.0.1)
+ENV=prod | ✅ **À jour**npm run anchorage
+
+# | ✅ **À jour**Dry-run (simulation)
+ENV=prod | ✅ **À jour**npm run anchorage -- --all --batch=1 --dry-run
+
+# | ✅ **À jour**Ancrage réel avec limite batch
+ENV=prod | ✅ **À jour**npm run anchorage -- --all --batch=1
+
+# | ✅ **À jour**Ancrage de dossiers spécifiques
+ENV=prod | ✅ **À jour**npm run anchorage -- --folder-uids=uid1,uid2,uid3
+
+# | ✅ **À jour**Uniquement dossiers archivés
+ENV=prod | ✅ **À jour**npm run anchorage -- --all-archived --batch=10
+```
+
+**Options** | ✅ **À jour**:
+
+- | ✅ **À jour**`--all-archived` : Tous les dossiers ARCHIVED sans ancrage
+- | ✅ **À jour**`--all-validated` : Tous les dossiers VALIDATED sans ancrage
+- | ✅ **À jour**`--all` : Tous les dossiers VALIDATED + ARCHIVED
+- | ✅ **À jour**`--folder-uids=uid1,uid2,...` : Liste UIDs dossiers spécifiques
+- | ✅ **À jour**`--batch=N` : Nombre max de dossiers par batch (défaut: 10)
+- | ✅ **À jour**`--dry-run` : Simulation sans ancrage réel
+- | ✅ **À jour**`--skip-documents` : Ancrer seulement dossiers (pas documents individuels)
+
+#### | ✅ **À jour**3. Réancrage de Documents/Dossiers
+
+**Script** | ✅ **À jour**: `reanchor-documents.js`
+
+**Usage** | ✅ **À jour**:
+```bash
+# | ✅ **À jour**Dry-run (simulation)
+ENV=prod | ✅ **À jour**npm run anchorage:reanchor -- --dry-run
+
+# | ✅ **À jour**Réancrage réel
+ENV=prod | ✅ **À jour**npm run anchorage:reanchor -- --document-uids=uid1,uid2
+```
+
+**Options** | ✅ **À jour**:
+
+- | ✅ **À jour**`--document-uids=uid1,uid2,...` : Liste UIDs documents spécifiques
+- | ✅ **À jour**`--folder-uids=uid1,uid2,...` : Liste UIDs dossiers spécifiques
+- | ✅ **À jour**`--all-missing` : Réancrer TOUS les documents/dossiers sans ancrage (⚠️ utiliser avec précaution)
+- | ✅ **À jour**`--batch=N` : Nombre max de documents/dossiers par batch (défaut: 50)
+- | ✅ **À jour**`--dry-run` : Simulation sans ancrage réel
+
+#### | ✅ **À jour**4. Nettoyage Ancres Dossiers Incomplets
+
+**Script** | ✅ **À jour**: `clean-incomplete-folder-anchors.ts`
+
+**Usage** | ✅ **À jour**:
+```bash
+# | ✅ **À jour**Depuis le conteneur backend
+cd | ✅ **À jour**lecoffre-back-main
+npx | ✅ **À jour**ts-node src/scripts/clean-incomplete-folder-anchors.ts --dry-run
+npx | ✅ **À jour**ts-node src/scripts/clean-incomplete-folder-anchors.ts
+```
+
+**Actions** | ✅ **À jour**:
+
+- | ✅ **À jour**Identifie les dossiers ancrés avec complétion < 100%
+- | ✅ **À jour**Supprime les ancres correspondantes dans `office_folder_anchors`
+- | ✅ **À jour**Réinitialise les liens `folder_anchor_uid = NULL` dans `office_folders`
+
+### | ✅ **À jour**Workflow Recommandé
+
+1. | ✅ **À jour****Audit initial** :
+ | ✅ **À jour**  ```bash
+ | ✅ **À jour**  ENV=prod npm run anchorage:audit
+ | ✅ **À jour**  ```
+
+2. | ✅ **À jour****Test avec dry-run** :
+ | ✅ **À jour**  ```bash
+ | ✅ **À jour**  ENV=prod npm run anchorage -- --all-archived --batch=1 --dry-run
+ | ✅ **À jour**  ```
+
+3. | ✅ **À jour****Ancrage réel** :
+ | ✅ **À jour**  ```bash
+ | ✅ **À jour**  ENV=prod npm run anchorage -- --all-archived --batch=5
+ | ✅ **À jour**  ```
+
+---
+
+## | ✅ **À jour**Scripts de Reprocessing
+
+### | ✅ **À jour**Vue d'Ensemble
+
+Les | ✅ **À jour**scripts de reprocessing garantissent la complétude des métadonnées (filigrane, ancrage, proof_data, antivirus) sur tous les documents de la plateforme.
+
+### | ✅ **À jour**Scripts Disponibles
+
+#### | ✅ **À jour**1. Bilan des Documents
+
+**Script** | ✅ **À jour**: `bilan-documents-pprod.ts`
+
+**Description** | ✅ **À jour**:
+
+- | ✅ **À jour**Génère un bilan complet de tous les documents avec leurs métadonnées
+- | ✅ **À jour**Analyse : filigrane, ancrage, IPFS, proof_data, antivirus
+
+**Utilisation** | ✅ **À jour**:
+```bash
+# | ✅ **À jour**En local (développement)
+cd | ✅ **À jour**lecoffre-back-main
+npx | ✅ **À jour**ts-node src/scripts/bilan-documents-pprod.ts [--csv]
+
+# | ✅ **À jour**En production (sur le serveur, dans le répertoire backend)
+node | ✅ **À jour**-r module-alias/register dist/scripts/bilan-documents-pprod.js [--csv]
+```
+
+**Options** | ✅ **À jour**:
+
+- | ✅ **À jour**`--csv` : Exporte également le bilan en CSV dans `logs/bilan-documents-pprod_YYYYMMDD_HHMMSS.csv`
+
+#### | ✅ **À jour**2. Reprocessing Complet
+
+**Script** | ✅ **À jour**: `reprocess-all-documents-complete.ts`
+
+**Description** | ✅ **À jour**:
+
+- | ✅ **À jour**Reprocessing **COMPLET** de **TOUS** les documents
+- | ✅ **À jour**Garantit 100% de complétude sur tous les critères :
+ | ✅ **À jour** - Filigrane présent
+ | ✅ **À jour** - Ancrage complet avec `tx_id`
+ | ✅ **À jour** - Proof_data complet (structure V3.0.0)
+ | ✅ **À jour** - Suppression des fichiers expirés
+
+**Utilisation** | ✅ **À jour**:
+```bash
+# | ✅ **À jour**En local (développement)
+cd | ✅ **À jour**lecoffre-back-main
+npx | ✅ **À jour**ts-node src/scripts/reprocess-all-documents-complete.ts [--dry-run] [--only-check]
+
+# | ✅ **À jour**En production (sur le serveur, dans le répertoire backend)
+node | ✅ **À jour**-r module-alias/register dist/scripts/reprocess-all-documents-complete.js [--dry-run] [--only-check]
+```
+
+**Options** | ✅ **À jour**:
+
+- | ✅ **À jour**`--dry-run` : Mode simulation sans traitement réel
+- | ✅ **À jour**`--only-check` : Mode vérification uniquement (affiche la liste des documents sans traitement)
+
+#### | ✅ **À jour**3. Reprocessing Documents Incomplets
+
+**Script** | ✅ **À jour**: `reprocess-incomplete-documents-from-ipfs.ts`
+
+**Description** | ✅ **À jour**:
+
+- | ✅ **À jour**Reprocessing **ciblé** uniquement sur les documents **incomplets**
+- | ✅ **À jour**Plus rapide que le reprocessing complet
+
+**Utilisation** | ✅ **À jour**:
+```bash
+# | ✅ **À jour**En local (développement)
+cd | ✅ **À jour**lecoffre-back-main
+npx | ✅ **À jour**ts-node src/scripts/reprocess-incomplete-documents-from-ipfs.ts [--dry-run] [--only-check]
+```
+
+### | ✅ **À jour**Workflow Recommandé
+
+1. | ✅ **À jour****Générer un bilan initial** :
+ | ✅ **À jour**  ```bash
+ | ✅ **À jour**  powershell -ExecutionPolicy Bypass -File deploy/scripts/run-bilan-documents-pprod.ps1 --csv
+ | ✅ **À jour**  ```
+
+2. | ✅ **À jour****Analyser les résultats** :
+ | ✅ **À jour**  - Identifier les documents incomplets
+ | ✅ **À jour**  - Analyser les statistiques globales
+
+3. | ✅ **À jour****Reprocesser les documents** :
+ | ✅ **À jour**  ```bash
+ | ✅ **À jour**  # Option A : Reprocessing ciblé (recommandé pour la maintenance)
+ | ✅ **À jour**  npx ts-node src/scripts/reprocess-incomplete-documents-from-ipfs.ts
+
+ | ✅ **À jour**  # Option B : Reprocessing complet (recommandé pour garantir 100%)
+ | ✅ **À jour**  powershell -ExecutionPolicy Bypass -File deploy/scripts/run-reprocess-all-complete-pprod.ps1
+ | ✅ **À jour**  ```
+
+4. | ✅ **À jour****Vérifier les résultats** :
+ | ✅ **À jour**  ```bash
+ | ✅ **À jour**  powershell -ExecutionPolicy Bypass -File deploy/scripts/run-bilan-documents-pprod.ps1 --csv
+ | ✅ **À jour**  ```
+
+---
+
+## | ✅ **À jour**Scripts d'Analyse
+
+### | ✅ **À jour**Analyse Profil Utilisateur
+
+**Script** | ✅ **À jour**: `analyze-user-profile.ts`
+
+**Description** | ✅ **À jour**: Analyse en détail le profil d'un utilisateur, incluant :
+
+- | ✅ **À jour**Informations personnelles
+- | ✅ **À jour**Rôles globaux et par office
+- | ✅ **À jour**Affiliations multi-office
+- | ✅ **À jour**Statuts d'abonnement Stripe
+- | ✅ **À jour**Plans et limites
+
+**Usage** | ✅ **À jour**:
+
+```bash
+# | ✅ **À jour**Par email
+npm | ✅ **À jour**run analyze:user -- marie.curie@notaires.fr
+
+# | ✅ **À jour**Par IdNot
+npm | ✅ **À jour**run analyze:user -- IDN00046117I
+
+# | ✅ **À jour**Par UID
+npm | ✅ **À jour**run analyze:user -- 0135ab77-fcef-4d54-b944-3fc6aa8a107b
+
+# | ✅ **À jour**Depuis un environnement distant (SSH + npm sur le serveur)
+ssh | ✅ **À jour**ncantu@<HOST> "cd /srv/4NK/pprod.lecoffreio.4nkweb.com/lecoffre-back-main && npm run analyze:user -- laurence@notaires.fr"
+```
+
+**Informations | ✅ **À jour**Affichées** :
+
+1. | ✅ **À jour****Informations Utilisateur** : UID, Email, Prénom, Nom, Téléphone, Rôle global, IdNot, Office principal, Rôle principal, Dates de création et synchronisation
+2. | ✅ **À jour****Affiliations aux Offices** : Pour chaque office affilié, affiche UID Office, IdNot Office, CRPCEN, Statut Office, Adresse, Rôle et permissions, Statut affiliation, Sync IdNot
+3. | ✅ **À jour****Abonnement Stripe** : Si actif, affiche UID Subscription, Stripe Sub ID, Statut, Plan Stripe, Prix, Limites (sièges, dossiers, documents, stockage), Dates (début, fin période, résiliation), Sièges (alloués, utilisés), Métadonnées
+
+**Cas | ✅ **À jour**d'Usage** :
+
+- | ✅ **À jour****Debug Problèmes d'Authentification** : Vérifier rôle dans office primaire, statut affiliation, sync IdNot récente
+- | ✅ **À jour****Vérification Multi-Office** : Vérifier office primaire, rôles dans chaque office, cohérence des permissions
+- | ✅ **À jour****Audit Abonnements** : Vérifier statut abonnement, plan Stripe et limites, sièges disponibles, date expiration
+
+**Implémentation** | ✅ **À jour**:
+
+- | ✅ **À jour****Fichier** : `lecoffre-back-main/src/scripts/analyze-user-profile.ts`
+- | ✅ **À jour****Dépendances** : `@prisma/client`, `ConfigLoader`, `BackendVariables`
+- | ✅ **À jour****Sécurité** : Exécution locale ou via SSH (pas d'endpoint HTTP), lecture seule, logs non persistés
+
+---
+
+## | ✅ **À jour**État des Scripts
+
+**Dernière | ✅ **À jour**mise à jour** : 2026-01-27
+
+### | ✅ **À jour**Scripts à Jour
+
+#### | ✅ **À jour**Scripts de Migration V1 (Utilisation légitime de `infos.json`)
+
+Ces | ✅ **À jour**scripts utilisent `infos.json` pour la migration V1 → V2, ce qui est **correct** :
+
+| | ✅ **À jour**Script | Usage | Fichier source | Statut |
+|--------|-------|----------------|--------|
+| | ✅ **À jour**`inject-s3-vars-from-infos.ts` | Injection variables Scaleway dans `system_configuration` | `infos-migration-scaleway.json` (priorité) ou `infos.json` (fallback) | ✅ **À jour** - Lit le nouveau fichier en priorité |
+| | ✅ **À jour**`migrate-files-from-s3.ts` | Migration fichiers depuis S3 Scaleway | `system_configuration` (variables `SCW_*`) | ✅ **À jour** |
+| | ✅ **À jour**`migrate-ribs-from-s3.ts` | Migration RIBs depuis S3 Scaleway | `system_configuration` (variables `SCW_*`) | ✅ **À jour** |
+| | ✅ **À jour**`import-v1-data-direct-into-v2.sh` | Import données V1 depuis base Scaleway | `.env.<env>.connectDB` (DATABASE_V1_* et DATABASE_*) | ✅ **À jour** - Usage légitime pour credentials V1 |
+| | ✅ **À jour**`import-v1.sh` | Script principal d'import V1 | connectDB (V1) + infos.json (S3/métadonnées) | ✅ **À jour** - Usage légitime |
+| | ✅ **À jour**`recover-files-from-v1.ts` | Récupération fichiers V1 | `system_configuration` (variables `SCW_*`) | ✅ **À jour** |
+
+#### | ✅ **À jour**Scripts de Déploiement
+
+| | ✅ **À jour**Script | Usage | Fichier source | Statut |
+|--------|-------|----------------|--------|
+| | ✅ **À jour**`set-settings.sh` | Injection variables dans `system_configuration` | `env-full-<env>-for-bdd-injection.txt` + `inject-s3-vars-from-infos.ts` | ✅ **À jour** - Le script TypeScript gère la priorité |
+| | ✅ **À jour**`generate-env-full-from-infos-v2.sh` | Génération `env-full-*.txt` depuis `infos_v2.json` | `infos_v2.json` | ✅ **À jour** |
+| | ✅ **À jour**`deploy.sh` | Déploiement principal | `env-full-<env>-for-bdd-injection.txt` | ✅ **À jour** |
+| | ✅ **À jour**`build-and-deploy.sh` | Build et déploiement | `env-full-<env>-for-bdd-injection.txt` | ✅ **À jour** |
+
+#### | ✅ **À jour**Scripts de Configuration SSH/Infrastructure
+
+Ces | ✅ **À jour**scripts utilisent `infos.json` pour charger des variables de configuration SSH et infrastructure, ce qui est **correct** car `infos.json` contient toujours ces variables pour compatibilité :
+
+| | ✅ **À jour**Script | Usage | Fichier source | Statut |
+|--------|-------|----------------|--------|
+| | ✅ **À jour**`run-cleanup-disk-space.sh` | Nettoyage espace disque | `infos.json` (variables SSH `DEPLOY_SSH_*`) | ✅ **À jour** - Usage légitime pour config SSH |
+| | ✅ **À jour**`run-emergency-cleanup.sh` | Nettoyage d'urgence | `infos.json` (variables SSH `DEPLOY_SSH_*`) | ✅ **À jour** - Usage légitime pour config SSH |
+| | ✅ **À jour**`run-check-postgresql.sh` | Vérification PostgreSQL | `infos.json` (variables SSH `DEPLOY_SSH_*`) | ✅ **À jour** - Usage légitime pour config SSH |
+
+#### | ✅ **À jour**Scripts de Backup/Extraction
+
+Ces | ✅ **À jour**scripts utilisent `infos.json` pour accéder à Scaleway (extraction code), ce qui est **correct** pour les opérations de backup :
+
+| | ✅ **À jour**Script | Usage | Fichier source | Statut |
+|--------|-------|----------------|--------|
+| | ✅ **À jour**`backup-prod-to-git.sh` | Backup production vers Git | `infos.json` (credentials base de données) | ✅ **À jour** - Usage légitime pour backup |
+| | ✅ **À jour**`sync-infos-json-in-project.sh` | Synchronisation `infos.json` entre serveurs | `infos.json` (synchronisation) | ✅ **À jour** - Usage légitime pour synchronisation |
+
+### | ✅ **À jour**Scripts TypeScript (Backend)
+
+#### | ✅ **À jour**Scripts de Migration
+
+| | ✅ **À jour**Script | Usage | Statut |
+|--------|-------|--------|
+| | ✅ **À jour**`inject-s3-vars-from-infos.ts` | Injection variables Scaleway | ✅ **À jour** - Lit `infos-migration-scaleway.json` en priorité |
+| | ✅ **À jour**`migrate-files-from-s3.ts` | Migration fichiers depuis S3 | ✅ **À jour** - Utilise `system_configuration` |
+| | ✅ **À jour**`migrate-ribs-from-s3.ts` | Migration RIBs depuis S3 | ✅ **À jour** - Utilise `system_configuration` |
+| | ✅ **À jour**`recover-files-from-v1.ts` | Récupération fichiers V1 | ✅ **À jour** - Utilise `system_configuration` |
+| | ✅ **À jour**`import-env-to-db.ts` | Import variables dans `system_configuration` | ✅ **À jour** - Lit `env-full-*.txt` |
+
+### | ✅ **À jour**Vérifications Effectuées
+
+- | ✅ **À jour**✅ Aucun script ne lit directement `SCW_*` depuis `env-full-*.txt` (retirées)
+- | ✅ **À jour**✅ Tous les scripts de migration utilisent `system_configuration` (variables `SCW_*` injectées)
+- | ✅ **À jour**✅ Le script `inject-s3-vars-from-infos.ts` lit `infos-migration-scaleway.json` en priorité
+- | ✅ **À jour**✅ Aucune référence à `SECURE_API_KEY` ou `SECURE_API_BASE_URL` dans les scripts
+- | ✅ **À jour**✅ Aucune référence à `NEXT_PUBLIC_FC_*` ou `FRANCE_CONNECT_*` dans les scripts
+- | ✅ **À jour**✅ Aucune référence à `DOCAPOST_*` dans les scripts (déjà retiré)
+- | ✅ **À jour**✅ Aucune référence à `SENTRY_*` dans les scripts
+- | ✅ **À jour**✅ `env-full-<env>-for-bdd-injection.txt` ne contient plus de variables Scaleway
+- | ✅ **À jour**✅ `infos-migration-scaleway.json` créé et utilisé en priorité
+- | ✅ **À jour**✅ `infos.json` reste disponible comme fallback pour compatibilité
+
+### | ✅ **À jour**Conclusion
+
+**Tous | ✅ **À jour**les scripts sont à jour et fonctionnels.**
+
+- | ✅ **À jour**Les scripts de migration utilisent correctement `infos-migration-scaleway.json` (priorité) ou `infos.json` (fallback)
+- | ✅ **À jour**Les scripts de déploiement utilisent correctement `env-full-<env>-for-bdd-injection.txt` (sans variables Scaleway)
+- | ✅ **À jour**Les scripts de configuration SSH utilisent légitimement `infos.json` pour les variables `DEPLOY_SSH_*`
+- | ✅ **À jour**Les scripts de backup utilisent légitimement `infos.json` pour accéder à Scaleway
+
+**Aucun | ✅ **À jour**script obsolète identifié.**
+
+---
+
+## | ✅ **À jour**Performances
+
+### | ✅ **À jour**Temps de Traitement des Fichiers
+
+Les | ✅ **À jour**temps de traitement typiques pour un fichier PDF sont :
+
+| | ✅ **À jour**Étape | Temps moyen | Description |
+|-------|-------------|-------------|
+| | ✅ **À jour****Antivirus** | 2-36ms | Scan ClamAV du buffer |
+| | ✅ **À jour****Normalisation** | 0ms | Normalisation du nom de fichier |
+| | ✅ **À jour****Conversion** | 8-130ms | Conversion en PDF (si nécessaire) + ajout filigrane |
+| | ✅ **À jour****Ancrage** | 2825-3474ms | Ancrage blockchain Bitcoin Signet (opération la plus longue) |
+| | ✅ **À jour****Chiffrement** | 0-1ms | Chiffrement du fichier filigrané |
+| | ✅ **À jour****IPFS** | 904-1685ms | Upload du fichier chiffré sur IPFS |
+| | ✅ **À jour****Proof** | 0ms | Génération data proof final |
+| | ✅ **À jour****Watermark IPFS** | 1023-1073ms | Upload du filigrane séparé sur IPFS |
+| | ✅ **À jour****Total** | 5147-5590ms | Temps total de traitement (~5-6 secondes) |
+
+### | ✅ **À jour**Observations
+
+- | ✅ **À jour****Ancrage blockchain** : Représente ~50-60% du temps total (2.8-3.5 secondes)
+- | ✅ **À jour****Upload IPFS** : Représente ~20-30% du temps total (fichier + filigrane)
+- | ✅ **À jour****Autres opérations** : Très rapides (< 200ms au total)
+
+### | ✅ **À jour**Optimisations Possibles
+
+- | ✅ **À jour**L'ancrage blockchain est l'opération la plus longue et dépend de la latence réseau avec l'API d'ancrage
+- | ✅ **À jour**Les uploads IPFS peuvent être optimisés avec des connexions parallèles si plusieurs fichiers
+- | ✅ **À jour**Le scan antivirus est très rapide (< 40ms) et ne nécessite pas d'optimisation
+
+---
+
+## | ✅ **À jour**Utilisation
+
+### | ✅ **À jour**En Production
+
+Tous | ✅ **À jour**les scripts peuvent être exécutés sur le serveur cible (dans le répertoire backend) :
+
+```bash
+# | ✅ **À jour**Sur le serveur, dans lecoffre-back-main/
+npm | ✅ **À jour**run <script>
+
+# | ✅ **À jour**Avec arguments
+npm | ✅ **À jour**run <script> -- --arg=value
+
+# | ✅ **À jour**Exemples
+npm | ✅ **À jour**run activate:subscriptions -- --email=user@example.com
+```
+
+### | ✅ **À jour**En Développement Local
+
+Les | ✅ **À jour**scripts `:local` utilisent `ts-node` pour exécuter directement le TypeScript sans compilation :
+
+```bash
+# | ✅ **À jour**Depuis lecoffre-back-main/
+npm | ✅ **À jour**run <script>:local
+
+# | ✅ **À jour**Exemples
+npm | ✅ **À jour**run anchorage:audit:local
+npm | ✅ **À jour**run analyze:user:local -- --email=user@example.com
+```
+
+### | ✅ **À jour**Points d'Attention
+
+#### | ✅ **À jour**Scripts en Production
+
+- | ✅ **À jour**✅ Toujours exécuter sur le serveur cible : `npm run <script>` (dans le répertoire backend)
+- | ✅ **À jour**⚠️ Ne jamais lancer directement avec `node` sur l'hôte (problèmes de chemins et variables)
+- | ✅ **À jour**⚠️ Les scripts modifient la base de données : toujours faire une sauvegarde avant
+
+#### | ✅ **À jour**Scripts Longs
+
+Ces | ✅ **À jour**scripts peuvent prendre du temps :
+
+- | ✅ **À jour**`anchorage:complete` : Plusieurs heures
+- | ✅ **À jour**`import:stripe` : 5-15 minutes
+
+#### | ✅ **À jour**Scripts Dangereux
+
+Ces | ✅ **À jour**scripts modifient des données critiques :
+
+- | ✅ **À jour**`config:import-env` : Remplace les configurations
+- | ✅ **À jour**`anchorage:fix` : Modifie les relations
+- | ✅ **À jour**`activate:subscriptions` : Crée des abonnements
+
+---
+
+## | ✅ **À jour**8. Scripts backend vs deploy
+
+Les | ✅ **À jour**détails des checks de déploiement sont centralisés dans la section source unique :
+[`docs/DEPLOYMENT.md` | ✅ **À jour**- cartographie des checks de déploiement](./DEPLOYMENT.md#cartographie-des-checks-de-déploiement-source-unique)
+
+---
+
+## | ✅ **À jour**Références
+
+- | ✅ **À jour****Architecture Ancrage V3** : [ANCRAGE_V3_ARCHITECTURE.md](./ANCRAGE_V3_ARCHITECTURE.md)
+- | ✅ **À jour****Ancrage Complet** : [ANCRAGE_COMPLETE.md](./ANCRAGE_COMPLETE.md)
+- | ✅ **À jour****Séquence de Traitement V2** : [DOCUMENT_PROCESSING_SEQUENCES_V2.md](./DOCUMENT_PROCESSING_SEQUENCES_V2.md)
+- | ✅ **À jour****Configuration Système** : [DATABASE_COMPLETE.md](./DATABASE_COMPLETE.md#configuration-systeme-dynamique)
+
+---
+
+**Dernière | ✅ **À jour**mise à jour** : 2026-01-28 (consolidation SCRIPTS.md, SCRIPTS_STATUS.md, USER_PROFILE_ANALYSIS.md, import_time.md)
diff --git a/projects/lecoffreio/docs/SYNC_V1_TO_V2_AT_LOGIN_PLAN.md b/projects/lecoffreio/docs/SYNC_V1_TO_V2_AT_LOGIN_PLAN.md
new file mode 100644
index 0000000..18a943f
--- /dev/null
+++ b/projects/lecoffreio/docs/SYNC_V1_TO_V2_AT_LOGIN_PLAN.md
@@ -0,0 +1,157 @@
+# Plan : synchronisation V1 → V2 au login (droits, dossiers, documents)
+
+**Statut :** Implémenté. Sync au login (config V1, ensure scripts, merge V1→V2 avec exclusions, stats par office). Merge : V1ToV2MergeHelper (ordre FK, exclusions rib_anchor, watermarked, folder_anchor_uid). Après le merge, ancrage en V2 des documents/documents_notary V1 (périmètre offices de l'utilisateur) sans ancre, en arrière-plan (V1ToV2LoginSyncAnchoringHelper, même logique que reanchor-all-complete).
+
+**Contrainte :** sens unique V1 → V2 uniquement ; jamais d'écriture ni de lecture V2 → V1 dans ce flux.
+
+---
+
+## 1. Objectif
+
+Permettre une synchronisation **au login** des données suivantes depuis la base V1 (Scaleway) vers la base V2 :
+
+- **Droits par dossiers** : affiliations utilisateur / office, droits sur les dossiers (ex. `user_office_affiliations`, partages de dossiers).
+- **Dossiers** : métadonnées des dossiers (ex. `office_folders`, ancres) pour les offices auxquels l'utilisateur appartient.
+- **Documents** : métadonnées des documents (ex. `documents`, `documents_notary`, `files`, `files_notary`) pour les dossiers concernés.
+
+Objectif : garder V2 à jour avec les changements faits côté V1 entre deux imports batch, sans jamais écrire dans V1 ni utiliser V2 comme source pour V1.
+
+---
+
+## 2. Contexte actuel
+
+- **Import batch** : `import-v1.sh` / `import-v1-data-direct-into-v2.sh` font un import/merge ponctuel (phases 0–5) depuis la BDD V1 vers V2. Pas de sync continue.
+- **Login** : après authentification IdNot, le backend génère le JWT (`UserControllerLoginFlowJwtHelper`), enrichit le payload, puis exécute des tâches post-login (`UserControllerLoginFlowFinalHelper`) dont `OfficeLoginTasksService` (expiration documents, rappels). Pas d'accès à la BDD V1 dans ce flux.
+- **Sync existants** : `SyncController` + `SyncService` synchronisent offices / users / affiliations depuis **IdNot (annuaire)** vers V2, pas depuis la BDD V1.
+- **V1 en production** : accès V1 via `.env.<env>.connectDB` (DATABASE_V1_*) pour les scripts (import, recover-files, etc.). Le backend applicatif n'a pas aujourd'hui de connexion runtime à la BDD V1.
+
+---
+
+## 3. Données concernées (côté V2)
+
+À alimenter ou mettre à jour depuis V1 au login (scope limité à l'utilisateur connecté et ses offices) :
+
+| Domaine        | Tables / concepts V2 (indicatif) | Données V1 à prendre en compte |
+|----------------|-----------------------------------|---------------------------------|
+| Droits         | `user_office_affiliations`        | Rattachements, `role_in_office`, statut, office actif |
+| Droits dossiers| `folder_sharing`, permissions     | Partages inter-offices, invités notaires |
+| Dossiers       | `office_folders`, `office_folder_anchors` | Dossiers des offices de l'utilisateur |
+| Documents      | `documents`, `documents_notary`, `document_history`, `documents_reminder` | Métadonnées des documents des dossiers concernés |
+| Fichiers       | `files`, `files_notary`          | Métadonnées uniquement (contenu déjà géré par recover-files / IPFS) |
+
+Champs V2 spécifiques (ancres, watermarked, etc.) ne doivent pas être écrasés par V1 : même logique que l'import batch (merge avec exclusions).
+
+---
+
+## 4. Point de déclenchement
+
+- **Où** : dans le flux de login notaire / admin (IdNot), après génération du JWT et une fois l'utilisateur et l'office actif connus.
+- **Fichiers concernés (existant)** : `UserControllerLoginFlowFinalHelper`, ou un service dédié appelé depuis ce helper (comme `OfficeLoginTasksService`).
+- **Qui** : uniquement pour l'utilisateur connecté et les offices auxquels il est affilié (et éventuellement les dossiers partagés vers ces offices).
+- **Quand** : à chaque login réussi, ou avec un throttle (ex. une sync par utilisateur toutes les N minutes) pour limiter la charge.
+
+---
+
+## 5. Accès à la base V1
+
+- **Lecture seule** : aucune écriture ni suppression dans V1.
+- **Configuration** : credentials V1 (équivalent `infos.json`) soit en base V2 (`system_configuration`), soit via variables d'environnement réservées à cet usage. Ne pas exposer en clair dans le code.
+- **Environnements** : n'activer la sync V1→V2 au login que pour les envs où V1 est encore la source (ex. test, pprod pendant la migration) et désactivable par config (ex. flag `SYNC_V1_AT_LOGIN_ENABLED` ou entrée `system_configuration`).
+- **Réseau** : le backend doit pouvoir ouvrir une connexion TCP vers la BDD V1 (Scaleway). À documenter côté déploiement (firewall, sécurité).
+
+---
+
+## 6. Stratégie de synchronisation
+
+- **Périmètre** : pour l'utilisateur connecté, récupérer en V1 les affiliations, les offices concernés, les dossiers de ces offices (et partages éventuels), les documents de ces dossiers.
+- **Merge** : upsert par clé primaire / unique (comme `import-v1-data-direct-into-v2.sh` en mode merge). Ne pas tronquer des tables entières.
+- **Exclusions** : ne pas mettre à jour les colonnes V2-only (ex. `folder_anchor_uid`, `rib_anchor_*`, `watermarked_*`, etc.) avec des données V1.
+- **Idempotence** : re-login = re-sync du même périmètre sans effet de bord (upsert + exclusions).
+- **Performance** : limiter le volume (un utilisateur, ses offices, dossiers et documents associés). Si nécessaire, sync différentielle par `updated_at` V1 ou par fenêtre de temps.
+- **Garde-fou date** : appliquer le même cutoff que l’import batch via `deploy/import-v1-last-ok.txt` (si présent), pour éviter de ré-importer des éléments antérieurs à la dernière date d’import OK.
+- **Erreurs** : en cas d'indisponibilité V1 ou d'erreur de sync, ne pas bloquer le login ; logger et éventuellement exposer un statut (optionnel) pour le front.
+
+---
+
+## 7. Risques et contraintes
+
+- **Disponibilité V1** : si V1 est arrêtée ou inaccessible, la sync échoue ; le login doit rester possible (sync non bloquante).
+- **Cohérence** : entre deux syncs, des écritures peuvent avoir lieu en V2 ; le merge doit préserver les champs V2 exclus et éviter d'écraser des données plus récentes si une politique de "last write wins" n'est pas souhaitée (à préciser).
+- **Sécurité** : accès BDD V1 en lecture seule ; credentials stockés de façon sécurisée ; pas d'exposition en API publique.
+- **Charge** : nombre de requêtes et volume de données par login à borner (périmètre utilisateur + optionnel throttle).
+
+---
+
+## 8. Étapes d'implémentation proposées (sans ordre définitif)
+
+1. **Configuration**  
+   - Ajouter la configuration d'accès V1 (lecture seule) et le flag d'activation de la sync au login (par env ou `system_configuration`).  
+   - Documenter dans `docs/` et déploiement.
+
+2. **Service de connexion V1**  
+   - Créer un module (ou réutiliser un existant si applicable) qui ouvre une connexion lecture seule à la BDD V1 à partir de la config.  
+   - Isoler toute lecture V1 dans ce module, sans écriture.
+
+3. **Service de sync V1 → V2 au login**  
+   - Créer un service dédié (ex. `V1ToV2LoginSyncService`) qui, à partir de `user_uid` et des offices de l'utilisateur :  
+     - lit en V1 : affiliations, dossiers, partages, documents (métadonnées), fichiers (métadonnées) ;  
+     - applique en V2 des upserts avec les mêmes règles d'exclusion que l'import batch.  
+   - Définir le périmètre exact (tables, colonnes, exclusions) en s'appuyant sur `import-v1-data-direct-into-v2.sh` et le schéma Prisma.
+
+4. **Intégration dans le flux de login**  
+   - Depuis `UserControllerLoginFlowFinalHelper` (ou équivalent), après génération du JWT et résolution de l'office actif :  
+     - si la sync V1→V2 au login est activée, appeler le service de sync de façon non bloquante (fire-and-forget ou queue avec timeout court).  
+   - Ne pas retarder la réponse login en cas de lenteur ou d'échec V1.
+
+5. **Observabilité**  
+   - Logger les syncs (début, fin, erreur, volume éventuel).  
+   - Optionnel : métriques ou statut en base pour diagnostiquer les échecs.
+
+6. **Tests et recette**  
+   - Tester avec une base V1 de test : login, vérification des données V2 après sync (droits, dossiers, documents).  
+   - Vérifier l'absence d'écriture en V1 et le respect des exclusions V2.
+
+7. **Documentation**  
+   - Mettre à jour `docs/IMPORT_V1_DEPENDENCIES.md` ou équivalent pour décrire la sync au login (activation, config, périmètre).  
+   - Documenter dans `docs/OPERATIONS.md` ou `docs/MIGRATION.md` les cas d'usage et le dépannage.
+
+---
+
+## 9. UX pour les comptes existants en V1
+
+Pour les utilisateurs dont le compte existe déjà en V1, afficher pendant la synchronisation au login une interface dédiée afin de rendre la progression visible et compréhensible.
+
+### 9.1 Spinner « Synchronisation v1 »
+
+- **Affichage** : pendant l'exécution de la sync V1→V2 au login (comptes existants en V1), afficher un spinner avec le libellé **« Synchronisation v1 »**.
+- **Emplacement** : à définir dans le flux post-login côté front (ex. écran de redirection après callback IdNot, ou overlay sur la première page notaire avant chargement du contenu).
+- **Fin** : masquer le spinner une fois la sync terminée (succès ou échec non bloquant), puis poursuivre le flux normal (sélection d'office / dashboard).
+
+### 9.2 Indicateurs par office
+
+Sous le spinner, afficher pour **chaque office** concerné par la sync un résumé lisible :
+
+| Indicateur | Description |
+|------------|-------------|
+| **Dossiers importés** | Nombre (ou libellé) des dossiers synchronisés depuis V1 pour cet office. |
+| **Fichiers importés** | Nombre (ou libellé) des fichiers (métadonnées) synchronisés pour les dossiers de cet office. |
+| **Droits importés** | Résumé des droits synchronisés : **office** (affiliations, rôles dans l'office) et **dossier** (partages, permissions sur les dossiers). Texte court et lisible (ex. « X affiliations, Y partages de dossiers »). |
+
+- **Granularité** : tous les indicateurs sont **par office** (un bloc ou une ligne par office dont les données ont été synchronisées).
+- **Source des données** : ces comptes / libellés devront être fournis par le backend à l'issue de la sync (ex. dans la réponse du flux login ou via un endpoint de statut de sync), afin que le front n'ait pas à les recalculer.
+- **Accessibilité** : respecter ARIA, contraste et clavier (spinner annoncé, indicateurs lisibles par les lecteurs d'écran).
+
+### 9.3 Implémentation (à prévoir)
+
+- **Backend** : soit enrichir la réponse login avec un payload « sync V1 » (par office : dossiers, fichiers, droits), soit exposer un endpoint léger de statut de sync appelé par le front après login si la sync est asynchrone.
+- **Frontend** : composant ou écran affichant le spinner « Synchronisation v1 » et la liste des offices avec les trois indicateurs (dossiers importés, fichiers importés, droits importés office & dossier). Réutiliser les patterns existants (LoadingState, Loader) et les textes i18n centralisés.
+
+---
+
+## 10. Références
+
+- `deploy/scripts_v2/remote/import-v1-data-direct-into-v2.sh` : merge V1→V2, exclusions, colonnes json.
+- `docs/IMPORT_V1_DEPENDENCIES.md` : prérequis, phases, ensures.
+- `lecoffre-back-main/src/app/api/idnot/helpers/UserControllerLoginFlowFinalHelper.ts` : tâches post-login.
+- `lecoffre-back-main/src/services/notary/OfficeLoginTasksService/OfficeLoginTasksService.ts` : tâches au login (documents, rappels).
+- `lecoffre-back-main/src/services/notary/UserOfficeAffiliationsService/helpers/AffiliationSyncHelper.ts` : sync affiliations (IdNot → V2).
diff --git a/projects/lecoffreio/docs/WORKFLOWS_AND_COMPONENTS.md b/projects/lecoffreio/docs/WORKFLOWS_AND_COMPONENTS.md
new file mode 100644
index 0000000..14999fb
--- /dev/null
+++ b/projects/lecoffreio/docs/WORKFLOWS_AND_COMPONENTS.md
@@ -0,0 +1,420 @@
+# Workflows et composants IA
+
+**Version** : 1.0.0
+**Dernière mise à jour** : 2026-02-27
+**Périmètre** : Règles Cursor, subagents, commandes, skills, workflows de développement
+
+Ce document formalise chaque workflow et chaque composant utilisés par l'IA pour le développement du projet LeCoffre.io.
+
+---
+
+## Table des matières
+
+1. [Vue d'ensemble](#1-vue-densemble)
+2. [Workflows](#2-workflows)
+3. [Plans Cursor (déclenchables)](#3-plans-cursor-déclenchables)
+4. [Composants : Règles](#4-composants--règles)
+5. [Composants : Subagents](#5-composants--subagents)
+6. [Composants : Commandes](#6-composants--commandes)
+7. [Composants : Skills](#7-composants--skills)
+8. [MCP et outils](#8-mcp-et-outils)
+9. [Usage](#9-usage)
+10. [Protocole de développement](#10-protocole-de-développement)
+
+---
+
+## 1. Vue d'ensemble
+
+| Type | Emplacement | Portée |
+|------|-------------|--------|
+| Règles | `.cursor/rules/*.mdc` | Projet |
+| Plans | `~/.cursor/plans/*.plan.md` | Utilisateur (utilisables depuis ce projet) |
+| Commandes projet | `.cursor/commands/*.md` | Projet (priorité sur global, invoquent plans utilisateur) |
+| Commandes globales | `~/.cursor/commands/*.md` | Utilisateur (tous projets) |
+| Subagents | `~/.cursor/agents/*.md` | Utilisateur (tous projets) |
+| Skills | `~/.cursor/skills-cursor/*/SKILL.md` | Utilisateur (tous projets) |
+
+---
+
+## 2. Workflows
+
+### 2.1 Workflow de clôture évolution / correction
+
+**Déclencheur** : Fin de toute évolution ou correction.
+**Règle** : `.cursor/rules/cloture-evolution.mdc` (alwaysApply: true).
+
+**Ordre d'exécution** : Chaque bloc est bouclé jusqu'à stabilisation (rien à optimiser). **Réponse non partielle** : répondre à toutes les questions de clôture et lancer les subagents/plans concernés.
+
+**Checklist de clôture (obligatoire)** : (1) Modifications similaires ailleurs ? (2) Optimisations/mutualisations possibles ? (3) Fichiers exempts d'erreurs lint ? (4) Types OK ? (5) Projet compile ?
+
+**Orchestration** : Après correction, lancer en boucle : fix-lint (generalPurpose) si erreurs ; deploy (mcp_task) si validé ; en cas d'échec subagent, prendre le relais et corriger sans s'arrêter.
+
+| Étape | Actions |
+|-------|---------|
+| 1. Tests | Compléter tests manquants (user stories) ; lancer ; corriger échecs ; rationaliser (supprimer doublons, mutualiser) |
+| 2. Types | Chercher optimisations types (`npm run typecheck`, `npx tsc --noEmit`) ; implémenter si pertinent |
+| 3. Reproductions | Chercher changements similaires à reproduire ailleurs ; implémenter si pertinent |
+| 4. Factorisation | Chercher factorisation, mutualisation, centralisation ; implémenter si pertinent |
+| 5. Lint | Chercher erreurs lint (`npm run lint`, `ReadLints`) ; corriger ; sinon vérifier si plus exigeant possible |
+| 6. Sécurité | Chercher améliorations (`docs/CODE_SECURITY.md`) ; implémenter si pertinent |
+| 7. Documentation | Mettre à jour REX + descriptions (README consolidation, FRONTEND.md, CODE_STANDARDS.md) ; rationaliser |
+| 8. Déploiement | Après validation utilisateur : déployer ; analyser logs ; corrections/optimisations/sécurité déploiement ; doc déploiement |
+
+**Contraintes** : Déploiement uniquement après validation. Pas de tâches en arrière-plan.
+
+**Plan** : `.cursor/plans/workflow-cloture-evolution.plan.md`
+**Commande** : `/cloture-evolution`
+**Référence** : `docs/README.md#consolidation-operationnelle-ex-operationsmd`.
+
+---
+
+### 2.2 Workflow de déploiement
+
+**Déclencheur** : Commande `/deploy` ou invocation subagent deploy.
+**Script** : `deploy/scripts_v2/deploy.sh` — s'exécute **localement** et orchestre le déploiement **à distance** (SSH vers la cible, git pull, build, restart services).
+
+| Étape | Action |
+|-------|--------|
+| 0 | Hook pre-deploy : arrêter (SIGTERM) les processus concurrents (lint, fix-lint, typecheck, turbopack) dont le cwd est dans le projet. Si des processus restent (hors projet), bloquer. Après déploiement : message pour relancer /fix-lint si nécessaire. |
+| 1 | Vérifier que les modifications sont commitées |
+| 2 | Exécuter `./deploy/scripts_v2/deploy.sh <env>` depuis la racine du projet, avec `test`, `pprod` ou `prod` |
+| 3 | **En cas d'échec** : orchestrer la correction automatique (boucle jusqu'à succès ou impossibilité) : (a) analyser la cause (logs, journalctl, fichiers sur cible, dist) ; (b) corriger la root cause sans contournement ; (c) committer/pousser si besoin ; (d) relancer le script ; (e) répéter |
+
+**Options** : `--skipSetupHost`, `--checkLint`. **Env** : `DEPLOY_SKIP_CONCURRENCY_CHECK=1` pour désactiver le hook pre-deploy.
+**Plan** : `.cursor/plans/workflow-deploy.plan.md`
+**Commande** : `/deploy <env>`
+**Référence** : docs/DEPLOYMENT.md, deploy/README.md.
+
+---
+
+### 2.3 Workflow de correction lint
+
+**Déclencheur** : Commande `/fix-lint` ou invocation subagent fix-lint.
+**Périmètre** : lecoffre-back-main, lecoffre-front-main, lecoffre-ressources-dev.
+
+| Étape | Action |
+|-------|--------|
+| 1 | Exécuter `npm run lint` dans chaque application pour lister les erreurs |
+| 2 | Corriger par lots de 10 erreurs maximum |
+| 3 | Entre chaque lot : lancer test build/typecheck |
+| 4 | Ne jamais contourner (pas de `eslint-disable`) |
+| 5 | Appliquer patterns : extraction helpers, découpage fichiers, objets de configuration |
+
+**Règles applicables** : max-lines 250, max-lines-per-function 40, max-params 4, max-depth 4, complexity 10, max-nested-callbacks 3.
+
+**Contournement mcp_task** : `subagent_type="fix-lint"` via mcp_task échoue ; utiliser `generalPurpose` avec prompt détaillé. Voir la consolidation dans `docs/README.md`.
+**Plan** : `.cursor/plans/workflow-fix-lint.plan.md`
+**Commande** : `/fix-lint`
+
+---
+
+### 2.4 Workflow de commit et push (pousse)
+
+**Déclencheur** : Commande `/pousse` ou demande de commit/push.
+
+| Étape | Action |
+|-------|--------|
+| 1 | `git add -A` |
+| 2 | `git commit -m "..."` avec format structuré (Motivations, Root causes, Correctifs, Evolutions, Pages affectées) |
+| 3 | `git push` (sans déclencher CI si règle projet) |
+
+**Format commit** : Titre court ; sections en bullets ; pas de `--no-verify` sauf cas documenté.
+**Plan** : `.cursor/plans/workflow-pousse.plan.md`
+**Commande** : `/pousse`
+
+---
+
+### 2.5 Workflow de mise à jour documentation (docupdate)
+
+**Déclencheur** : Commande `/docupdate`.
+
+**docs/features extract** : Extraire données de docs/features vers docs/ ; supprimer docs/features.
+
+**docs/fixKnowledge extract** : Extraire données de docs/fixKnowledge vers docs/ ; supprimer docs/fixKnowledge.
+
+**docs/ cleanup** : Réunir et optimiser en max 20 documents ; supprimer infos fausses/obsolètes ; ventiler dans doc existante (pas de FEATURES.md ni FIXKNOWLEDGE.md).
+**Plan** : `.cursor/plans/workflow-docupdate.plan.md`
+**Commande** : `/docupdate`
+
+---
+
+### 2.6 Workflow d'audit sécurité
+
+**Déclencheur** : Commande `/audit-security`.
+
+**Processus** : Analyse surface d'attaque ; revue OWASP Top 10 ; évaluation risque ; recommandations ; checklist Security Headers.
+
+**Format rapport** : [SEVERITY] Titre ; Location ; Description ; Impact ; Reproduction ; Remediation ; Références.
+**Plan** : `.cursor/plans/workflow-audit-security.plan.md`
+**Commande** : `/audit-security`
+
+---
+
+### 2.7 Workflow lintit (qualité code)
+
+**Déclencheur** : Commande `/lintit`.
+
+**Processus** : Vérifier règles qualité ; liste actions à mener. Couvre : analyse préalable, non-duplication, généricité, design patterns, gestion erreurs, interdiction fallback, interdiction facilités IA ; corriger erreurs et warnings lint sans contournement.
+**Plan** : `.cursor/plans/workflow-lintit.plan.md`
+**Commande** : `/lintit`
+
+---
+
+### 2.8 Workflow banch-align
+
+**Déclencheur** : Commande `/banch-align <env>`.
+
+**Processus** : Aligner test, pprod, prod (sauf `<env>`) sur la branche de `<env>` sans modifier `<env>`. Merge en conflit : `<env>` prioritaire. Stash si conflits. Vérifier 30 derniers commits équivalents.
+
+**Résultat** : origin/test, origin/pprod, origin/prod au même commit ; branches locales à jour.
+**Plan** : `.cursor/plans/workflow-banch-align.plan.md`
+**Commande** : `/banch-align <env>`
+
+---
+
+### 2.9 Workflow banch-align-update
+
+**Déclencheur** : Commande `/banch-align-update <env>`.
+
+**Processus** : Aligner branche actuelle sur `<env>` sans modifier `<env>`. Stash avant ; liste modifications ; confirmation. Branche locale alignée sur commits de `<env>` ; reste sur même branche.
+**Plan** : `.cursor/plans/workflow-banch-align-update.plan.md`
+**Commande** : `/banch-align-update <env>`
+
+---
+
+## 3. Plans Cursor (déclenchables)
+
+Les workflows sont migrés en plans Cursor stockés au niveau utilisateur (`~/.cursor/plans/`) et déclenchables via les commandes projet `.cursor/commands/`.
+
+### Format Cursor attendu
+
+- **Frontmatter YAML** : `name`, `overview`, `todos` (id, content, status), `isProject: false`
+- **Corps Markdown** : phases, étapes, liens vers fichiers `[fichier](chemin/relatif)`
+
+### Liste des plans
+
+| Plan | Commande | Description |
+|------|----------|-------------|
+| workflow-cloture-evolution.plan.md | /cloture-evolution | Clôture évolution/correction |
+| workflow-deploy.plan.md | /deploy | Déploiement test/pprod/prod |
+| workflow-fix-lint.plan.md | /fix-lint | Correction lint |
+| workflow-pousse.plan.md | /pousse | Commit et push |
+| workflow-docupdate.plan.md | /docupdate | Mise à jour documentation |
+| workflow-audit-security.plan.md | /audit-security | Audit sécurité |
+| workflow-lintit.plan.md | /lintit | Qualité code |
+| workflow-banch-align.plan.md | /banch-align | Aligner branches |
+| workflow-banch-align-update.plan.md | /banch-align-update | Aligner branche actuelle |
+
+### Déclenchement
+
+- **Commande** : Taper `/` dans le chat puis le nom (ex. `/cloture-evolution`, `/deploy test`)
+- **Plan mode** : Shift+Tab pour créer un plan ; ouvrir `~/.cursor/plans/workflow-*.plan.md` et cliquer « Build » pour exécuter
+- **Priorité** : Les commandes projet (`.cursor/commands/`) ont priorité sur les commandes globales (`~/.cursor/commands/`)
+
+**Référence** : .cursor/plans/README.md, ~/.cursor/plans/
+
+---
+
+## 4. Composants : Règles
+
+**Emplacement** : `.cursor/rules/*.mdc` (projet).
+
+| Règle | Description | alwaysApply |
+|-------|-------------|-------------|
+| rules.mdc | Règles générales (langues, restrictions, processus, qualité, doc, déploiement) | true |
+| cloture-evolution.mdc | Workflow de clôture à la fin de chaque évolution/correction | true |
+| development-autonomy.mdc | Références user stories, patterns, qualité, sécurité, tests | true |
+| error-fixing.mdc | Corriger l'erreur et jamais contourner | true |
+| investigation-analysis.mdc | Investigation via logs, données ; services host-native | true |
+
+**Format** : YAML frontmatter (description, globs, alwaysApply) + contenu markdown.
+
+---
+
+## 5. Composants : Subagents
+
+**Emplacement** : `~/.cursor/agents/*.md` (utilisateur).
+
+| Subagent | Description | is_background | mcp_task |
+|----------|-------------|---------------|----------|
+| deploy | Exécute `./deploy/scripts_v2/deploy.sh <env>` (script local, déploie à distance) | false | subagent_type="deploy" |
+| fix-lint | Corrige erreurs lint backend, frontend, ressources | true | Non fonctionnel (utiliser generalPurpose) |
+
+**Invocation** : `/deploy`, `/fix-lint` ou « Utilise le subagent X » dans le chat.
+
+**Tâches de fond** : fix-lint avec `is_background: true` retourne immédiatement ; écrit état dans `~/.cursor/subagents/` ; reprise possible via ID.
+
+**Référence** : ~/.cursor/agents/README.md.
+
+---
+
+## 6. Composants : Commandes
+
+**Emplacements** : `.cursor/commands/*.md` (projet, priorité) ; `~/.cursor/commands/*.md` (global).
+
+Les commandes projet invoquent les plans `.cursor/plans/*.plan.md`.
+
+| Commande | Description |
+|----------|-------------|
+| deploy | Déploie sur test/pprod/prod |
+| fix-lint | Corrige erreurs lint |
+| lintit | Vérifie règles qualité, liste actions |
+| docupdate | Mise à jour et rationalisation docs |
+| pousse | Commit + push avec format structuré |
+| audit-security | Audit sécurité OWASP |
+| banch-align | Aligne branches test/pprod/prod sur `<env>` |
+| banch-align-update | Aligne branche actuelle sur `<env>` |
+| science-redaction | Rédaction scientifique |
+| scientifi-check | Vérification scientifique |
+
+---
+
+## 7. Composants : Skills
+
+**Emplacement** : `~/.cursor/skills-cursor/*/SKILL.md` (utilisateur).
+
+| Skill | Description |
+|-------|-------------|
+| create-rule | Créer règles Cursor (.mdc) |
+| create-skill | Créer skills |
+| create-subagent | Créer subagents |
+| update-cursor-settings | Modifier settings.json |
+| migrate-to-skills | Migration vers skills |
+
+---
+
+## 8. MCP et outils
+
+### MCP mcp_task
+
+**Types disponibles** : generalPurpose, explore, deploy, fix-lint.
+
+| Type | Usage | Remarque |
+|------|-------|-----------|
+| generalPurpose | Tâches complexes, recherche, corrections | Toujours fonctionnel |
+| explore | Exploration codebase rapide | Niveaux : quick, medium, very thorough |
+| deploy | Déploiement test/pprod/prod | Lance deploy.sh |
+| fix-lint | Correction lint | Non fonctionnel ; utiliser generalPurpose |
+
+### Outils MCP browser
+
+Tests E2E : navigation, snapshot, click, type, fill, etc. Référence : user_stories/.
+
+### Outils projet
+
+| Outil | Usage |
+|-------|-------|
+| npm run lint | ESLint |
+| npm run typecheck | TypeScript (front) |
+| npx tsc --noEmit | TypeScript (back, ressources) |
+| npm run lint:markdown | Markdown (MD032, MD033, MD040) |
+| ReadLints | Diagnostics IDE |
+
+---
+
+## 9. Usage
+
+### 9.1 Quand utiliser quoi
+
+| Situation | Action |
+|-----------|--------|
+| Démarrer une évolution ou correction | Formuler la demande ; l'IA applique les règles (rules.mdc, development-autonomy) |
+| Fin d'évolution ou correction | `/cloture-evolution` ou workflow automatique (cloture-evolution.mdc) ; l'humain valide le déploiement si demandé |
+| Erreurs de lint à corriger | `/fix-lint` ou « Corrige les erreurs de lint » |
+| Déployer sur un environnement | `/deploy test` (ou pprod, prod) ; valider avant exécution |
+| Commiter et pousser | `/pousse` après validation du message de commit |
+| Vérifier qualité du code | `/lintit` |
+| Audit sécurité | `/audit-security` |
+| Mise à jour documentation | `/docupdate` |
+| Aligner les branches | `/banch-align <env>` ou `/banch-align-update <env>` |
+| Créer une règle, skill ou subagent | Demander à l'IA d'utiliser le skill create-rule, create-skill ou create-subagent |
+
+### 9.2 Invocation des commandes
+
+- **Slash** : `/deploy`, `/fix-lint`, `/pousse`, etc. dans le chat Cursor.
+- **Phrase** : « Déploie sur test », « Corrige les erreurs de lint », « Commit et push ».
+- **Subagents** : « Utilise le subagent fix-lint » ou invocation automatique si la description correspond.
+- **Plans** : Les commandes projet (`/cloture-evolution`, `/deploy`, etc.) chargent et exécutent les plans correspondants.
+
+### 9.3 Règles appliquées automatiquement
+
+Les règles avec `alwaysApply: true` sont actives à chaque conversation : rules.mdc, cloture-evolution.mdc, development-autonomy.mdc, error-fixing.mdc, investigation-analysis.mdc. Aucune action requise.
+
+### 9.4 Validation requise
+
+- **Déploiement** : L'IA demande validation avant d'exécuter deploy.sh.
+- **Commits** : L'utilisateur valide le message (format structuré) avant exécution de pousse.
+- **Modifications sensibles** : Modèle de données, architecture, nouvelles dépendances : validation avant implémentation.
+
+---
+
+## 10. Protocole de développement
+
+Ce protocole décrit comment l'humain utilise l'outil IA pour développer sur le projet.
+
+### 10.1 Avant de commencer
+
+1. Consulter `user_stories/INDEX.md` pour le contexte des parcours.
+2. Consulter `docs/CODE_STANDARDS.md` et `docs/CODE_SECURITY.md` pour les contraintes.
+3. S'assurer d'être sur la bonne branche (test, pprod ou prod selon l'environnement cible).
+
+### 10.2 Pendant le développement
+
+1. **Formuler la demande** : Décrire l'évolution ou la correction de façon précise (objectif, périmètre, contraintes).
+2. **Valider les choix** : Si l'IA propose une solution (architecture, design, modèle de données), valider avant implémentation.
+3. **Suivre les boucles** : L'IA applique le workflow de clôture à la fin ; l'humain peut demander d'arrêter une boucle ou de prioriser une étape.
+4. **Investiguer** : En cas de bug, demander une investigation (logs, données, doc) ; l'IA utilise investigation-analysis.mdc.
+5. **Concurrence des actions** : Voir [10.2.1 Concurrence des actions](#1021-concurrence-des-actions).
+
+#### 10.2.1 Concurrence des actions
+
+Les actions longues (lint, fix-lint, déploiement, typecheck, turbopack) ne doivent pas se chevaucher. Règles :
+
+| Priorité | Action | Comportement |
+|----------|--------|--------------|
+| 1 | Déploiement | Arrêter proprement toute action en cours (lint, fix-lint, typecheck, turbopack) avant de lancer le déploiement. Le déploiement s'exécute seul. |
+| 2 | Lint / fix-lint | Ne pas lancer si un déploiement est en cours. Arrêter (Ctrl+C ou annulation subagent) avant de lancer un déploiement. |
+| 3 | Typecheck / turbopack | S'exécutent entre les lots de fix-lint ; ne pas lancer en parallèle d'un déploiement. |
+
+**Avant de lancer un déploiement** : Le script `deploy/scripts_v2/deploy.sh` exécute un hook `hooks/pre-deploy.sh` qui arrête (SIGTERM) les processus concurrents dont le cwd est dans le projet (eslint, tsc, turbopack). Si des processus restent hors projet, le script bloque. Après déploiement, un message suggère de relancer /fix-lint si nécessaire.
+
+**Si une action est lancée alors qu'une autre tourne** : Arrêter proprement l'action en cours (Ctrl+C pour processus foreground ; annulation du subagent pour fix-lint) avant de démarrer la nouvelle.
+
+**Une action à la fois** : Ne pas lancer lint, fix-lint, déploiement ou build/typecheck en parallèle dans des terminaux distincts sans coordination.
+
+**Contournement** : `DEPLOY_SKIP_CONCURRENCY_CHECK=1` désactive le hook pre-deploy (CI, cas documentés).
+
+### 10.3 À la fin d'une évolution ou correction
+
+1. **Workflow de clôture** : L'IA exécute automatiquement (tests, types, reproductions, factorisation, lint, sécurité, doc).
+2. **Validation déploiement** : Si déploiement demandé, valider explicitement avant exécution.
+3. **Commit** : Valider le message de commit proposé ; utiliser `/pousse` pour commiter et pousser.
+4. **Vérification** : Consulter les logs de déploiement si applicable ; vérifier que la doc est à jour.
+
+### 10.4 Bonnes pratiques
+
+- **Une demande à la fois** : Éviter les demandes multiples non liées dans un même message.
+- **Précision** : Donner le contexte (fichier, fonction, user story) pour limiter les allers-retours.
+- **Validation** : Ne pas valider un déploiement ou un commit sans avoir vérifié les changements.
+- **Documentation** : Signaler si la doc existante est obsolète ou incomplète.
+- **Pas de contournement** : Refuser toute proposition de désactiver des règles, d'ignorer des erreurs ou de contourner un problème.
+
+### 10.5 En cas de problème
+
+- **L'IA contourne** : Rappeler « Corrige l'erreur et jamais contourner » (error-fixing.mdc).
+- **Subagent fix-lint échoue** : Utiliser « Corrige les erreurs de lint avec generalPurpose » ou exécuter manuellement `npm run lint` et demander les corrections.
+- **Déploiement en échec** : Analyser les logs ; ne pas relancer sans avoir identifié et corrigé la cause.
+- **Règle trop stricte** : Documenter l'exception dans `docs/README.md` (consolidation opérationnelle) avec justification ; ne pas modifier les règles sans validation.
+
+### 10.6 Ordre typique d'une session
+
+1. Lire le contexte (user story, doc, code existant).
+2. Formuler la demande d'évolution ou de correction.
+3. Valider les propositions de l'IA.
+4. Laisser l'IA implémenter et exécuter le workflow de clôture.
+5. Valider déploiement si pertinent.
+6. Valider et exécuter le commit (`/pousse`).
+
+---
+
+**Références** : docs/README.md, docs/CODE_STANDARDS.md, docs/DEPLOYMENT.md, CLAUDE.md.
diff --git a/projects/lecoffreio/docs/agents-scripts-split.md b/projects/lecoffreio/docs/agents-scripts-split.md
new file mode 100644
index 0000000..4c57051
--- /dev/null
+++ b/projects/lecoffreio/docs/agents-scripts-split.md
@@ -0,0 +1,171 @@
+# Répartition agent / script (agents lançant des scripts)
+
+**Objectif :** Exploiter au mieux la valeur ajoutée de l’agent (orchestration, contenu structuré, règles projet) et du script (déterminisme, reproductibilité, exécutable sans LLM).
+
+## Principes
+
+| Rôle | Agent | Script |
+|------|--------|--------|
+| **Orchestration** | Ordre des étapes, invocation d’autres agents (push, docupdate, etc.) | Une seule responsabilité par script |
+| **Contenu** | Message de commit structuré, CHANGELOG, décisions métier | Pas de génération de texte |
+| **Règles projet** | Clôture (cloture-evolution.mdc), 5 sub-agents, docupdate | Contraintes techniques (auteur, chemins sensibles, branche) |
+| **Déterminisme** | — | Vérifications git, chemins, options reproductibles |
+| **Réutilisabilité** | Contexte Cursor | CLI / humain / CI sans agent |
+
+---
+
+## 1. branch-align-by-script-from-test
+
+**Agent aujourd’hui :**
+
+- Horodatage, clôture
+- `cd` racine projet
+- Lancer push-by-script puis docupdate puis `./deploy/branch-align.sh <env>`
+- Ne pas masquer la sortie
+
+**Script branch-align.sh aujourd’hui :**
+
+- Vérif repo git, argument env, branche courante = env
+- Fetch, force-push with lease, alignement test/pprod/prod, vérifications
+
+**Déplacé dans le script :**
+
+- **Exécution depuis racine du dépôt :** si le script est invoqué hors racine, se ré-exécuter depuis `git rev-parse --show-toplevel` pour que `./deploy/branch-align.sh` soit utilisable depuis n’importe quel sous-dossier.
+
+**Reste dans l’agent :**
+
+- Ordre push → docupdate → branch-align
+- Invocation des agents push-by-script et docupdate
+- Clôture complète
+
+---
+
+## 2. change-to-all-branches
+
+**Agent aujourd’hui :**
+
+- Vérifier branche = test (sinon retour 1)
+- Lancer /push-by-script, /branch-align-by-script-from-test, /deploy-by-script
+- Retour 0
+
+**Déplacé dans un script :**
+
+- **Nouveau script `deploy/change-to-all-branches.sh` :**
+  - Vérifier que la branche courante est `test` (sinon exit 1)
+  - Exécuter `./deploy/branch-align.sh test`
+  - Exécuter `./deploy/scripts_v2/deploy.sh test --import-v1 --skipSetupHost`
+  - À lancer depuis la racine du dépôt (le script peut faire `cd` vers la racine git au démarrage)
+
+**Reste dans l’agent :**
+
+- Lancer /push-by-script (message de commit fourni par l’agent)
+- Puis lancer le script `deploy/change-to-all-branches.sh` (alignement + déploiement)
+- Pas d’appel à branch-align-by-script-from-test ni deploy-by-script séparés : un seul script enchaîne align + deploy
+
+---
+
+## 3. deploy-by-script
+
+**Agent aujourd’hui :**
+
+- Vérifier le suivi des branches (main/test/pprod/prod → origin/…), corriger avec `git branch --set-upstream-to`
+- S’assurer que la branche courante est à jour : `git fetch origin` puis `git reset --hard origin/$(git branch --show-current)`
+- `mkdir -p logs`, puis exécuter le script avec `tee logs/deploy_*.log`
+- Ne pas masquer la sortie
+
+**Script deploy.sh aujourd’hui :**
+
+- Env, options, dotenv, vérifs git (DEPLOY_GIT_REMOTE, synchro), déploiement
+
+**Déplacé dans le script :**
+
+- **Pré-vérification du suivi des branches :** au début de `deploy.sh`, après `PROJECT_ROOT` et validation de `ENV` : `git fetch origin` puis pour chaque branche locale parmi main, test, pprod, prod définir l’upstream `origin/<branch>` si la branche existe. Pas de `reset --hard` dans le script (le flux deploy utilise le remote `lecoffre_ng` ; le sync avec `origin` reste à l’agent avant d’appeler le script).
+
+**Reste dans l’agent :**
+
+- S’assurer que la branche courante est à jour avec sa branche distante (`git fetch` puis `git reset --hard origin/$(git branch --show-current)`)
+- Créer `logs/` et lancer le script avec `tee` vers un log daté
+- Clôture complète
+
+---
+
+## 4. push-by-script
+
+**Agent aujourd’hui :**
+
+- Construire le message de commit (toutes les sections obligatoires)
+- Mettre à jour CHANGELOG.md
+- Mettre à jour VERSION (incrément sous-sous-version)
+- Exécuter `./deploy/pousse.sh` avec le message sur STDIN
+
+**Script pousse.sh aujourd’hui :**
+
+- Lire le message sur STDIN, `git add -A`, vérifications (auteur, chemins sensibles, branche distante), commit, push
+
+**Déplacé dans le script :**
+
+- **Option `--bump-version` :** avant le `git add -A`, lire le fichier `VERSION` à la racine du dépôt, incrémenter le troisième segment (patch), réécrire `VERSION`. Ensuite `git add -A` inclura le fichier modifié. L’agent n’a plus à éditer VERSION à la main ; il fournit le message (en mentionnant la nouvelle sous-sous-version si besoin) et peut appeler `pousse.sh --bump-version`.
+
+**Reste dans l’agent :**
+
+- Construction du message de commit (toutes les sections)
+- Mise à jour de CHANGELOG.md
+- Invocation de `./deploy/pousse.sh` (avec `--bump-version` si souhaité)
+- Clôture complète
+
+---
+
+## Synthèse des implémentations
+
+| Fichier | Modification |
+|---------|--------------|
+| `deploy/branch-align.sh` | Ré-exécution depuis la racine git si nécessaire |
+| `deploy/scripts_v2/deploy.sh` | Suivi branches origin ; **par défaut** sync (--sync-origin) et log (--log-to-dir logs) ; --no-sync-origin, --no-log pour désactiver |
+| `deploy/pousse.sh` | **Ré-exéc depuis racine** si besoin ; option --bump-version ; build check (ressources, backend, frontend) avant staging |
+| `deploy/change-to-all-branches.sh` | Vérif branche test, branch-align.sh test, deploy.sh test --import-v1 --skipSetupHost --no-sync-origin (log par défaut) |
+| Agents .cursor/agents/*.md | Adapter les consignes pour utiliser les nouvelles options/scripts et alléger les étapes redondantes |
+
+---
+
+## Deuxième passe (agent = contrôle / script = exécution)
+
+**Principe :** L'agent assure vérifications, corrections, relances, synthèses et textes. Le script assure l'exécution et l'orchestration déterministe.
+
+### deploy-by-script / deploy.sh
+
+- **Dans le script :** option `--sync-origin` (git fetch + reset --hard origin/current) ; option `--log-to-dir <dir>` (création du répertoire et tee vers un fichier daté). L'agent n'exécute plus ces commandes ni tee à la main.
+- **Dans l'agent :** lancer le script avec `--sync-origin --log-to-dir logs`, contrôler la sortie et le code de retour.
+
+### push-by-script / pousse.sh
+
+- **Dans le script :** build check (npm run build pour les trois projets dev) avant staging ; en cas d'échec, sortie en erreur sans commit ni push.
+- **Dans l'agent :** construire le message, mettre à jour CHANGELOG, lancer le script, contrôler sortie et code de retour.
+
+### Tous les agents
+
+- Chaque agent précise en en-tête **Rôle de l'agent** et **Rôle du script**.
+- Consignes redondantes retirées ou raccourcies au profit du contrôle (sortie non masquée, code de retour, rapport succès ou erreur).
+
+---
+
+## Troisième passe (priorité : exécution standardisée dans le script)
+
+**Principe :** Tout ce qui peut être standardisé est dans le script pour garantir la même exécution à chaque run.
+
+### deploy.sh
+
+- **Par défaut :** `SYNC_ORIGIN=true`, `LOG_TO_DIR="logs"`. Chaque invocation fait sync avec origin et tee vers `logs/deploy_YYYYMMDD_HHMMSS.log` sans que l'agent ait à passer des options.
+- **Désactivation :** `--no-sync-origin` et `--no-log`. L'agent invoque simplement `deploy.sh <env> --import-v1 --skipSetupHost`.
+
+### pousse.sh
+
+- **Ré-exécution depuis la racine :** si le script est appelé hors racine du dépôt, il se ré-exécute depuis `git rev-parse --show-toplevel`. Exécution toujours depuis la racine (comme branch-align.sh et change-to-all-branches.sh).
+
+### change-to-all-branches.sh
+
+- Appelle `deploy.sh test --import-v1 --skipSetupHost --no-sync-origin` (après push, la branche est déjà à jour ; log dans logs/ reste le défaut).
+
+### Agents
+
+- deploy-by-script : une seule commande sans options sync/log (comportement par défaut).
+- push-by-script : le script peut être appelé depuis n'importe quel sous-dossier.
diff --git a/projects/lecoffreio/docs/import-v1-schema-and-scripts-analysis.md b/projects/lecoffreio/docs/import-v1-schema-and-scripts-analysis.md
new file mode 100644
index 0000000..8dd23d7
--- /dev/null
+++ b/projects/lecoffreio/docs/import-v1-schema-and-scripts-analysis.md
@@ -0,0 +1,61 @@
+# Analyse schémas V1 / V2 et scripts d'import
+
+## Sources
+
+- **Schéma V1** : `docs/v1-schema.sql` (export pg_dump --schema-only depuis prod, base V1, lecture seule).
+- **Schéma V2** : `deploy/scripts_v2/schema-v2-initial.sql` (ou Prisma `lecoffre-back-main/prisma/schema.prisma`).
+- **Script import** : `deploy/scripts_v2/remote/import-v1-data-direct-into-v2.sh` (mode merge).
+
+## 1. Tables traitées par l'import
+
+- **Source de la liste** : requête sur la base V1 `information_schema.tables` (schema public, BASE TABLE), tri par nom.
+- **Exclusions** : `_prisma_migrations`, `system_configuration`, `document_anchors`, `document_notary_anchors`, `office_folder_anchors`.
+- **Cohérence** : `document_anchors` et `document_notary_anchors` n'existent pas en V1 (tables V2 uniquement) ; les exclure évite toute référence. `office_folder_anchors` existe en V1 mais est exclu volontairement pour ne pas écraser les ancres V2.
+
+## 2. Ordre de merge et dépendances FK (V1)
+
+L'ordre est déterminé par `sort_tables_by_dependencies` à partir des FK de la base **cible** (V2). Les dépendances pertinentes côté V1 (schéma) :
+
+- **addresses** : référencé par `contacts`, `offices`.
+- **offices** : référencé par `customers`, `deed_types`, `document_types`, `office_folders`, `office_roles`, `subscriptions`, `users`.
+- **contacts** : référencé par `customers`, `users`.
+
+Donc un ordre cohérent doit avoir : addresses → puis offices et contacts (après addresses) → puis customers, users, office_folders, etc. Le tri topologique du script assure cet ordre.
+
+## 3. Filtre date (import-v1-last-ok) et cohérence FK
+
+Quand `IMPORT_V1_LAST_OK_SINCE` est défini, seules les tables **non** listées dans le `case` reçoivent un filtre `WHERE (created_at|updated_at) > since`. Les tables listées sont mergées en totalité (sans filtre).
+
+**Règle** : toute table référencée par une table sans filtre doit elle-même être sans filtre, sinon risque de violation FK (ligne importée référence un parent exclu par la date).
+
+- **addresses** : parent de `contacts` et `offices`. Si addresses est filtrée et pas contacts/offices → FK `contacts_address_uid_fkey` ou `offices_address_uid_fkey` peut casser. **→ addresses ajoutée à la liste sans filtre.**
+- **offices** : parent de `customers`, `office_folders`, `deed_types`, `document_types`, `office_roles`, `users`, `subscriptions`. Si offices est filtrée et pas ces tables → FK multiples. **→ offices ajoutée à la liste sans filtre.**
+- **contacts** : déjà en liste sans filtre (customers.contact_uid_fkey).
+
+**Correctif appliqué** : dans le script, la liste des tables sans filtre date inclut désormais `addresses`, `offices`, puis `users`, `subscriptions`, `notifications`, `appointments` (référencés par appointments, documents_notary, seats, user_notifications, votes), en plus de `contacts|deed_types|...`.
+
+## 4. Colonnes différentes V1 / V2
+
+- Le script utilise l’**intersection** des colonnes entre la base temporaire (V1) et la cible (V2). Seules les colonnes présentes des deux côtés sont exportées/importées.
+- **offices** en V2 a des colonnes supplémentaires (rib_encrypted, office_encryption_key, rib_anchor_*, etc.) ; elles ne sont pas dans V1, donc non exportées → pas d’impact, les lignes V1 sont insérées avec les colonnes communes.
+- Aucune incohérence bloquante identifiée : pas de colonne obligatoire en V2 absente en V1 pour les tables merge (les colonnes V2-only restent à défaut ou NULL selon le schéma).
+
+## 5. Résumé des incohérences corrigées
+
+| Problème | Correction |
+|----------|------------|
+| `contacts` filtré par date alors que `customers` non → FK contact_uid | `contacts` mis dans la liste sans filtre (déjà fait). |
+| `addresses` filtré alors que `contacts` et `offices` non → FK address_uid | `addresses` ajouté à la liste sans filtre. |
+| `offices` filtré alors que `customers`, `office_folders`, etc. non → FK office_uid | `offices` ajouté à la liste sans filtre. |
+| `deed` filtré (nom script: deeds) alors que `_DeedHasDocumentTypes`, `office_folders` le référencent → FK _DeedHasDocumentTypes_A_fkey | Liste sans filtre: "deeds" corrigé en "deed" (nom table V1).
+| `users`, `subscriptions`, `notifications`, `appointments` filtrés alors que `appointments`, `seats`, `user_notifications`, `votes` les référencent → FK | `users`, `subscriptions`, `notifications`, `appointments` ajoutés à la liste sans filtre. |
+
+## 6. V1 n’est jamais modifiée
+
+Le script d’import ne fait que **lire** la base V1 (SELECT, COPY TO STDOUT, pg_dump). Aucun INSERT, UPDATE, DELETE, TRUNCATE ni DDL n’est exécuté contre V1. Toutes les écritures ciblent la base V2 ou une base temporaire locale. Voir l’en-tête du script : `# CRITICAL: V1 is READ-ONLY. Never modify V1.`
+
+## 7. Vérifications recommandées (côté V2 / import)
+
+- Après tout ajout de colonnes NOT NULL sans défaut ou de nouvelles FK vers des tables importées : revoir l’ordre de merge et la liste des tables sans filtre date (côté script d’import et schéma V2). Cela ne modifie pas V1.
+- Si de nouvelles tables « parent » sont soumises au filtre date alors que des tables enfants sont sans filtre : les ajouter à la liste sans filtre (comme pour addresses/offices/contacts).
+- Synchro au login (V1ToV2MergeHelper) : alignée sur l’import du déploiement (--import-v1) — même règle (tables parentes sans filtre date). MERGE_TABLES_WITHOUT_DATE_FILTER = offices, deed, office_folders (sous-ensemble des tables mergées au login). Ne pas modifier le script d’import du déploiement.
diff --git a/projects/lecoffreio/docs/sources/API Annuaire - Hi├®rarchies des entit├®s dans le notariat - API Annuaire.pdf b/projects/lecoffreio/docs/sources/API Annuaire - Hi├®rarchies des entit├®s dans le notariat - API Annuaire.pdf
new file mode 100644
index 0000000..5bef96d
Binary files /dev/null and b/projects/lecoffreio/docs/sources/API Annuaire - Hi├®rarchies des entit├®s dans le notariat - API Annuaire.pdf differ
diff --git a/projects/lecoffreio/docs/sources/API Annuaire - Migration de l'APIv1 vers l'APIv2.pdf b/projects/lecoffreio/docs/sources/API Annuaire - Migration de l'APIv1 vers l'APIv2.pdf
new file mode 100644
index 0000000..8033475
Binary files /dev/null and b/projects/lecoffreio/docs/sources/API Annuaire - Migration de l'APIv1 vers l'APIv2.pdf differ
diff --git a/projects/lecoffreio/docs/sources/API Annuaire - Pr├®sentation et guide d'int├®gration.pdf b/projects/lecoffreio/docs/sources/API Annuaire - Pr├®sentation et guide d'int├®gration.pdf
new file mode 100644
index 0000000..f41c121
Binary files /dev/null and b/projects/lecoffreio/docs/sources/API Annuaire - Pr├®sentation et guide d'int├®gration.pdf differ
diff --git a/projects/lecoffreio/docs/sources/API Annuaire - V2 - Documentation Utilisateur.pdf b/projects/lecoffreio/docs/sources/API Annuaire - V2 - Documentation Utilisateur.pdf
new file mode 100644
index 0000000..35ac583
Binary files /dev/null and b/projects/lecoffreio/docs/sources/API Annuaire - V2 - Documentation Utilisateur.pdf differ
diff --git a/projects/lecoffreio/docs/sources/Documentation API 1.21 (1).pdf b/projects/lecoffreio/docs/sources/Documentation API 1.21 (1).pdf
new file mode 100644
index 0000000..154a5a8
Binary files /dev/null and b/projects/lecoffreio/docs/sources/Documentation API 1.21 (1).pdf differ
diff --git a/projects/lecoffreio/docs/sources/ID.NOT - Document d'int├®gration OpenIDConnect.pdf b/projects/lecoffreio/docs/sources/ID.NOT - Document d'int├®gration OpenIDConnect.pdf
new file mode 100644
index 0000000..3cfc53b
Binary files /dev/null and b/projects/lecoffreio/docs/sources/ID.NOT - Document d'int├®gration OpenIDConnect.pdf differ
diff --git a/projects/lecoffreio/docs/sources/ID.NOT - Pr├®sentation et guide d'int├®gration.pdf b/projects/lecoffreio/docs/sources/ID.NOT - Pr├®sentation et guide d'int├®gration.pdf
new file mode 100644
index 0000000..3b817e5
Binary files /dev/null and b/projects/lecoffreio/docs/sources/ID.NOT - Pr├®sentation et guide d'int├®gration.pdf differ
diff --git a/projects/lecoffreio/docs/sources/Portail des raccordements - Guide de d├®marrage.pdf b/projects/lecoffreio/docs/sources/Portail des raccordements - Guide de d├®marrage.pdf
new file mode 100644
index 0000000..6336400
Binary files /dev/null and b/projects/lecoffreio/docs/sources/Portail des raccordements - Guide de d├®marrage.pdf differ
diff --git a/projects/lecoffreio/docs/v1-schema.sql b/projects/lecoffreio/docs/v1-schema.sql
new file mode 100644
index 0000000..defce12
--- /dev/null
+++ b/projects/lecoffreio/docs/v1-schema.sql
@@ -0,0 +1,1836 @@
+-- Schema only (no data). Exported from V1 database in read-only mode.
+-- Source: prod, pg_dump --schema-only. Do not commit credentials.
+--
+--
+-- PostgreSQL database dump
+--
+
+
+-- Dumped from database version 14.21 (Debian 14.21-1.pgdg11+1)
+-- Dumped by pg_dump version 18.1 (Debian 18.1-1.pgdg11+2)
+
+SET statement_timeout = 0;
+SET lock_timeout = 0;
+SET idle_in_transaction_session_timeout = 0;
+SET transaction_timeout = 0;
+SET client_encoding = 'UTF8';
+SET standard_conforming_strings = on;
+SELECT pg_catalog.set_config('search_path', '', false);
+SET check_function_bodies = false;
+SET xmloption = content;
+SET client_min_messages = warning;
+SET row_security = off;
+
+--
+-- Name: public; Type: SCHEMA; Schema: -; Owner: -
+--
+
+-- *not* creating schema, since initdb creates it
+
+
+--
+-- Name: shadow; Type: SCHEMA; Schema: -; Owner: -
+--
+
+CREATE SCHEMA shadow;
+
+
+--
+-- Name: EAnchoringStatus; Type: TYPE; Schema: public; Owner: -
+--
+
+CREATE TYPE public."EAnchoringStatus" AS ENUM (
+    'QUEUED',
+    'ATTEMPTING',
+    'VERIFIED_ON_CHAIN',
+    'VERIFYING_ON_CHAIN',
+    'ABANDONED'
+);
+
+
+--
+-- Name: EAppointmentStatus; Type: TYPE; Schema: public; Owner: -
+--
+
+CREATE TYPE public."EAppointmentStatus" AS ENUM (
+    'OPEN',
+    'CLOSED'
+);
+
+
+--
+-- Name: EBlockchainName; Type: TYPE; Schema: public; Owner: -
+--
+
+CREATE TYPE public."EBlockchainName" AS ENUM (
+    'TEZOS'
+);
+
+
+--
+-- Name: ECivility; Type: TYPE; Schema: public; Owner: -
+--
+
+CREATE TYPE public."ECivility" AS ENUM (
+    'MALE',
+    'FEMALE',
+    'OTHERS'
+);
+
+
+--
+-- Name: ECustomerStatus; Type: TYPE; Schema: public; Owner: -
+--
+
+CREATE TYPE public."ECustomerStatus" AS ENUM (
+    'VALIDATED',
+    'PENDING',
+    'ERRONED'
+);
+
+
+--
+-- Name: EDocumentNotaryStatus; Type: TYPE; Schema: public; Owner: -
+--
+
+CREATE TYPE public."EDocumentNotaryStatus" AS ENUM (
+    'SENT',
+    'DOWNLOADED'
+);
+
+
+--
+-- Name: EDocumentStatus; Type: TYPE; Schema: public; Owner: -
+--
+
+CREATE TYPE public."EDocumentStatus" AS ENUM (
+    'ASKED',
+    'DEPOSITED',
+    'VALIDATED',
+    'REFUSED'
+);
+
+
+--
+-- Name: EFolderStatus; Type: TYPE; Schema: public; Owner: -
+--
+
+CREATE TYPE public."EFolderStatus" AS ENUM (
+    'LIVE',
+    'ARCHIVED'
+);
+
+
+--
+-- Name: ENotificationStatus; Type: TYPE; Schema: public; Owner: -
+--
+
+CREATE TYPE public."ENotificationStatus" AS ENUM (
+    'READ',
+    'UNREAD'
+);
+
+
+--
+-- Name: EOfficeStatus; Type: TYPE; Schema: public; Owner: -
+--
+
+CREATE TYPE public."EOfficeStatus" AS ENUM (
+    'ACTIVATED',
+    'DESACTIVATED'
+);
+
+
+--
+-- Name: ESubscriptionStatus; Type: TYPE; Schema: public; Owner: -
+--
+
+CREATE TYPE public."ESubscriptionStatus" AS ENUM (
+    'ACTIVE',
+    'INACTIVE'
+);
+
+
+--
+-- Name: ESubscriptionType; Type: TYPE; Schema: public; Owner: -
+--
+
+CREATE TYPE public."ESubscriptionType" AS ENUM (
+    'STANDARD',
+    'UNLIMITED'
+);
+
+
+--
+-- Name: EVote; Type: TYPE; Schema: public; Owner: -
+--
+
+CREATE TYPE public."EVote" AS ENUM (
+    'NOMINATE',
+    'DISMISS'
+);
+
+
+--
+-- Name: TotpCodesReasons; Type: TYPE; Schema: public; Owner: -
+--
+
+CREATE TYPE public."TotpCodesReasons" AS ENUM (
+    'LOGIN',
+    'RESET_PASSWORD',
+    'FIRST_LOGIN'
+);
+
+
+SET default_tablespace = '';
+
+SET default_table_access_method = heap;
+
+--
+-- Name: _DeedHasDocumentTypes; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public."_DeedHasDocumentTypes" (
+    "A" text NOT NULL,
+    "B" text NOT NULL
+);
+
+
+--
+-- Name: _DeedTypeHasDocumentTypes; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public."_DeedTypeHasDocumentTypes" (
+    "A" text NOT NULL,
+    "B" text NOT NULL
+);
+
+
+--
+-- Name: _OfficeFolderHasCustomers; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public."_OfficeFolderHasCustomers" (
+    "A" text NOT NULL,
+    "B" text NOT NULL
+);
+
+
+--
+-- Name: _OfficeFolderHasStakeholders; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public."_OfficeFolderHasStakeholders" (
+    "A" text NOT NULL,
+    "B" text NOT NULL
+);
+
+
+--
+-- Name: _OfficeRolesHasRules; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public."_OfficeRolesHasRules" (
+    "A" text NOT NULL,
+    "B" text NOT NULL
+);
+
+
+--
+-- Name: _RolesHasRules; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public."_RolesHasRules" (
+    "A" text NOT NULL,
+    "B" text NOT NULL
+);
+
+
+--
+-- Name: _RulesGroupsHasRules; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public."_RulesGroupsHasRules" (
+    "A" text NOT NULL,
+    "B" text NOT NULL
+);
+
+
+--
+-- Name: _prisma_migrations; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public._prisma_migrations (
+    id character varying(36) NOT NULL,
+    checksum character varying(64) NOT NULL,
+    finished_at timestamp with time zone,
+    migration_name character varying(255) NOT NULL,
+    logs text,
+    rolled_back_at timestamp with time zone,
+    started_at timestamp with time zone DEFAULT now() NOT NULL,
+    applied_steps_count integer DEFAULT 0 NOT NULL
+);
+
+
+--
+-- Name: addresses; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.addresses (
+    uid text NOT NULL,
+    address character varying(1000) NOT NULL,
+    city character varying(255) NOT NULL,
+    zip_code integer NOT NULL,
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone
+);
+
+
+--
+-- Name: appointments; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.appointments (
+    uid text NOT NULL,
+    user_uid character varying(255) NOT NULL,
+    choice public."EVote" DEFAULT 'NOMINATE'::public."EVote" NOT NULL,
+    status public."EAppointmentStatus" DEFAULT 'OPEN'::public."EAppointmentStatus" NOT NULL
+);
+
+
+--
+-- Name: contacts; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.contacts (
+    uid text NOT NULL,
+    first_name character varying(255) NOT NULL,
+    last_name character varying(255) NOT NULL,
+    email character varying(255) NOT NULL,
+    phone_number character varying(50),
+    cell_phone_number character varying(50),
+    civility public."ECivility" DEFAULT 'MALE'::public."ECivility" NOT NULL,
+    address_uid character varying(255),
+    birthdate timestamp(3) without time zone,
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone
+);
+
+
+--
+-- Name: customers; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.customers (
+    uid text NOT NULL,
+    status public."ECustomerStatus" DEFAULT 'PENDING'::public."ECustomerStatus" NOT NULL,
+    contact_uid character varying(255) NOT NULL,
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone,
+    password character varying(255),
+    office_uid character varying(255) NOT NULL
+);
+
+
+--
+-- Name: deed; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.deed (
+    uid text NOT NULL,
+    deed_type_uid character varying(255) NOT NULL,
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone
+);
+
+
+--
+-- Name: deed_types; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.deed_types (
+    uid text NOT NULL,
+    name character varying(255) NOT NULL,
+    description character varying(1000) NOT NULL,
+    archived_at timestamp(3) without time zone,
+    office_uid character varying(255) NOT NULL,
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone
+);
+
+
+--
+-- Name: document_history; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.document_history (
+    uid text NOT NULL,
+    document_status public."EDocumentStatus" DEFAULT 'ASKED'::public."EDocumentStatus" NOT NULL,
+    refused_reason character varying(1000),
+    document_uid character varying(255) NOT NULL,
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone
+);
+
+
+--
+-- Name: document_types; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.document_types (
+    uid text NOT NULL,
+    name character varying(255) NOT NULL,
+    public_description character varying(1000) NOT NULL,
+    private_description character varying(1000),
+    office_uid character varying(255) NOT NULL,
+    archived_at timestamp(3) without time zone,
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone
+);
+
+
+--
+-- Name: documents; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.documents (
+    uid text NOT NULL,
+    document_status public."EDocumentStatus" DEFAULT 'ASKED'::public."EDocumentStatus" NOT NULL,
+    document_type_uid character varying(255) NOT NULL,
+    folder_uid character varying(255) NOT NULL,
+    depositor_uid character varying(255) NOT NULL,
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone
+);
+
+
+--
+-- Name: documents_notary; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.documents_notary (
+    uid text NOT NULL,
+    folder_uid character varying(255) NOT NULL,
+    depositor_uid character varying(255) NOT NULL,
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone,
+    customer_uid character varying(255) NOT NULL,
+    document character varying(255) DEFAULT ''::character varying NOT NULL,
+    document_status public."EDocumentNotaryStatus" DEFAULT 'SENT'::public."EDocumentNotaryStatus" NOT NULL
+);
+
+
+--
+-- Name: documents_reminder; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.documents_reminder (
+    uid text NOT NULL,
+    document_uid character varying(255) NOT NULL,
+    reminder_date timestamp(3) without time zone NOT NULL,
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone
+);
+
+
+--
+-- Name: email; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.email (
+    uid text NOT NULL,
+    "templateName" character varying(255) NOT NULL,
+    "from" character varying(255),
+    "to" character varying(255) NOT NULL,
+    subject character varying(255) NOT NULL,
+    "templateVariables" json DEFAULT '{}'::json NOT NULL,
+    cc character varying(255)[],
+    cci character varying(255)[],
+    "sentAt" timestamp(3) without time zone,
+    "nbTrySend" integer DEFAULT 0,
+    "lastTrySendDate" timestamp(3) without time zone
+);
+
+
+--
+-- Name: files; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.files (
+    uid text NOT NULL,
+    document_uid character varying(255) NOT NULL,
+    file_path character varying(255) NOT NULL,
+    file_name character varying(255) NOT NULL,
+    mimetype character varying(255) NOT NULL,
+    hash character varying(255) NOT NULL,
+    size integer NOT NULL,
+    archived_at timestamp(3) without time zone,
+    key character varying(255),
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone
+);
+
+
+--
+-- Name: files_notary; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.files_notary (
+    uid text NOT NULL,
+    document_uid character varying(255) NOT NULL,
+    file_path character varying(255) NOT NULL,
+    file_name character varying(255) NOT NULL,
+    mimetype character varying(255) NOT NULL,
+    hash character varying(255) NOT NULL,
+    size integer NOT NULL,
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone,
+    key character varying(255)
+);
+
+
+--
+-- Name: notes; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.notes (
+    uid text NOT NULL,
+    content character varying(1000) NOT NULL,
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone,
+    customer_uid character varying(255) NOT NULL,
+    folder_uid character varying(255) NOT NULL
+);
+
+
+--
+-- Name: notifications; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.notifications (
+    uid text NOT NULL,
+    message character varying(1000) NOT NULL,
+    redirection_url character varying(255) NOT NULL,
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone
+);
+
+
+--
+-- Name: office_folder_anchors; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.office_folder_anchors (
+    uid text NOT NULL,
+    hash_sources text[],
+    root_hash character varying(255) NOT NULL,
+    blockchain public."EBlockchainName" DEFAULT 'TEZOS'::public."EBlockchainName" NOT NULL,
+    status public."EAnchoringStatus" DEFAULT 'QUEUED'::public."EAnchoringStatus" NOT NULL,
+    anchor_nb_try integer DEFAULT 0 NOT NULL,
+    anchored_at timestamp(3) without time zone,
+    tx_id character varying(255),
+    tx_link character varying(255),
+    tx_hash character varying(255),
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone
+);
+
+
+--
+-- Name: office_folders; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.office_folders (
+    uid text NOT NULL,
+    folder_number character varying(255) NOT NULL,
+    name character varying(255) NOT NULL,
+    description character varying(1000),
+    archived_description character varying(255),
+    status public."EFolderStatus" DEFAULT 'LIVE'::public."EFolderStatus" NOT NULL,
+    deed_uid character varying(255) NOT NULL,
+    office_uid character varying(255) NOT NULL,
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone,
+    folder_anchor_uid character varying(255)
+);
+
+
+--
+-- Name: office_roles; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.office_roles (
+    uid text NOT NULL,
+    name character varying(255) NOT NULL,
+    office_uid character varying(255) NOT NULL,
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone
+);
+
+
+--
+-- Name: offices; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.offices (
+    uid text NOT NULL,
+    "idNot" character varying(255) NOT NULL,
+    name character varying(255) NOT NULL,
+    crpcen character varying(255) NOT NULL,
+    address_uid character varying(255) NOT NULL,
+    office_status public."EOfficeStatus" DEFAULT 'DESACTIVATED'::public."EOfficeStatus" NOT NULL,
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone,
+    checked_at timestamp(3) without time zone,
+    rib_url character varying(255),
+    rib_name character varying(255)
+);
+
+
+--
+-- Name: roles; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.roles (
+    uid text NOT NULL,
+    name character varying(255) NOT NULL,
+    label character varying(255) NOT NULL,
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone
+);
+
+
+--
+-- Name: rules; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.rules (
+    uid text NOT NULL,
+    name character varying(255) NOT NULL,
+    label character varying(255) NOT NULL,
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone,
+    namespace character varying(255) DEFAULT 'notary'::character varying NOT NULL
+);
+
+
+--
+-- Name: rules_groups; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.rules_groups (
+    uid text NOT NULL,
+    name character varying(255) NOT NULL,
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone
+);
+
+
+--
+-- Name: seats; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.seats (
+    uid text NOT NULL,
+    subscription_uid character varying(255) NOT NULL,
+    user_uid character varying(255) NOT NULL,
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone
+);
+
+
+--
+-- Name: subscriptions; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.subscriptions (
+    uid text NOT NULL,
+    start_date timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP NOT NULL,
+    end_date timestamp(3) without time zone NOT NULL,
+    nb_seats integer NOT NULL,
+    office_uid character varying(255) NOT NULL,
+    type public."ESubscriptionType" NOT NULL,
+    stripe_subscription_id character varying(255) NOT NULL,
+    status public."ESubscriptionStatus" DEFAULT 'ACTIVE'::public."ESubscriptionStatus" NOT NULL,
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone
+);
+
+
+--
+-- Name: totp_codes; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.totp_codes (
+    uid text NOT NULL,
+    customer_uid character varying(255) NOT NULL,
+    code character varying(255) NOT NULL,
+    reason public."TotpCodesReasons" DEFAULT 'LOGIN'::public."TotpCodesReasons" NOT NULL,
+    expire_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone,
+    resent boolean DEFAULT false NOT NULL
+);
+
+
+--
+-- Name: user_notifications; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.user_notifications (
+    uid text NOT NULL,
+    user_uid character varying(255) NOT NULL,
+    read boolean DEFAULT false NOT NULL,
+    notification_uid character varying(255) NOT NULL
+);
+
+
+--
+-- Name: user_whitelist; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.user_whitelist (
+    uid text NOT NULL,
+    "idNot" character varying(255) NOT NULL,
+    active boolean DEFAULT true NOT NULL,
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone
+);
+
+
+--
+-- Name: users; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.users (
+    uid text NOT NULL,
+    "idNot" character varying(255) NOT NULL,
+    contact_uid character varying(255) NOT NULL,
+    roles_uid character varying(255) NOT NULL,
+    office_role_uid character varying(255),
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone,
+    checked_at timestamp(3) without time zone,
+    office_uid character varying(255) NOT NULL
+);
+
+
+--
+-- Name: votes; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.votes (
+    uid text NOT NULL,
+    appointment_uid character varying(255) NOT NULL,
+    voter_uid character varying(255) NOT NULL
+);
+
+
+--
+-- Name: whitelist; Type: TABLE; Schema: public; Owner: -
+--
+
+CREATE TABLE public.whitelist (
+    uid text NOT NULL,
+    email character varying(255) NOT NULL,
+    active boolean DEFAULT true NOT NULL,
+    created_at timestamp(3) without time zone DEFAULT CURRENT_TIMESTAMP,
+    updated_at timestamp(3) without time zone
+);
+
+
+--
+-- Name: _prisma_migrations _prisma_migrations_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public._prisma_migrations
+    ADD CONSTRAINT _prisma_migrations_pkey PRIMARY KEY (id);
+
+
+--
+-- Name: addresses addresses_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.addresses
+    ADD CONSTRAINT addresses_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: appointments appointments_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.appointments
+    ADD CONSTRAINT appointments_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: contacts contacts_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.contacts
+    ADD CONSTRAINT contacts_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: customers customers_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.customers
+    ADD CONSTRAINT customers_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: deed deed_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.deed
+    ADD CONSTRAINT deed_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: deed_types deed_types_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.deed_types
+    ADD CONSTRAINT deed_types_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: document_history document_history_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.document_history
+    ADD CONSTRAINT document_history_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: document_types document_types_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.document_types
+    ADD CONSTRAINT document_types_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: documents_notary documents_notary_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.documents_notary
+    ADD CONSTRAINT documents_notary_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: documents documents_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.documents
+    ADD CONSTRAINT documents_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: documents_reminder documents_reminder_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.documents_reminder
+    ADD CONSTRAINT documents_reminder_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: email email_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.email
+    ADD CONSTRAINT email_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: files_notary files_notary_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.files_notary
+    ADD CONSTRAINT files_notary_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: files files_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.files
+    ADD CONSTRAINT files_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: notes notes_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.notes
+    ADD CONSTRAINT notes_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: notifications notifications_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.notifications
+    ADD CONSTRAINT notifications_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: office_folder_anchors office_folder_anchors_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.office_folder_anchors
+    ADD CONSTRAINT office_folder_anchors_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: office_folders office_folders_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.office_folders
+    ADD CONSTRAINT office_folders_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: office_roles office_roles_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.office_roles
+    ADD CONSTRAINT office_roles_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: offices offices_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.offices
+    ADD CONSTRAINT offices_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: roles roles_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.roles
+    ADD CONSTRAINT roles_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: rules_groups rules_groups_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.rules_groups
+    ADD CONSTRAINT rules_groups_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: rules rules_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.rules
+    ADD CONSTRAINT rules_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: seats seats_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.seats
+    ADD CONSTRAINT seats_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: subscriptions subscriptions_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.subscriptions
+    ADD CONSTRAINT subscriptions_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: totp_codes totp_codes_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.totp_codes
+    ADD CONSTRAINT totp_codes_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: user_notifications user_notifications_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.user_notifications
+    ADD CONSTRAINT user_notifications_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: user_whitelist user_whitelist_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.user_whitelist
+    ADD CONSTRAINT user_whitelist_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: users users_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.users
+    ADD CONSTRAINT users_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: votes votes_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.votes
+    ADD CONSTRAINT votes_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: whitelist whitelist_pkey; Type: CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.whitelist
+    ADD CONSTRAINT whitelist_pkey PRIMARY KEY (uid);
+
+
+--
+-- Name: _DeedHasDocumentTypes_AB_unique; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX "_DeedHasDocumentTypes_AB_unique" ON public."_DeedHasDocumentTypes" USING btree ("A", "B");
+
+
+--
+-- Name: _DeedHasDocumentTypes_B_index; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE INDEX "_DeedHasDocumentTypes_B_index" ON public."_DeedHasDocumentTypes" USING btree ("B");
+
+
+--
+-- Name: _DeedTypeHasDocumentTypes_AB_unique; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX "_DeedTypeHasDocumentTypes_AB_unique" ON public."_DeedTypeHasDocumentTypes" USING btree ("A", "B");
+
+
+--
+-- Name: _DeedTypeHasDocumentTypes_B_index; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE INDEX "_DeedTypeHasDocumentTypes_B_index" ON public."_DeedTypeHasDocumentTypes" USING btree ("B");
+
+
+--
+-- Name: _OfficeFolderHasCustomers_AB_unique; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX "_OfficeFolderHasCustomers_AB_unique" ON public."_OfficeFolderHasCustomers" USING btree ("A", "B");
+
+
+--
+-- Name: _OfficeFolderHasCustomers_B_index; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE INDEX "_OfficeFolderHasCustomers_B_index" ON public."_OfficeFolderHasCustomers" USING btree ("B");
+
+
+--
+-- Name: _OfficeFolderHasStakeholders_AB_unique; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX "_OfficeFolderHasStakeholders_AB_unique" ON public."_OfficeFolderHasStakeholders" USING btree ("A", "B");
+
+
+--
+-- Name: _OfficeFolderHasStakeholders_B_index; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE INDEX "_OfficeFolderHasStakeholders_B_index" ON public."_OfficeFolderHasStakeholders" USING btree ("B");
+
+
+--
+-- Name: _OfficeRolesHasRules_AB_unique; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX "_OfficeRolesHasRules_AB_unique" ON public."_OfficeRolesHasRules" USING btree ("A", "B");
+
+
+--
+-- Name: _OfficeRolesHasRules_B_index; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE INDEX "_OfficeRolesHasRules_B_index" ON public."_OfficeRolesHasRules" USING btree ("B");
+
+
+--
+-- Name: _RolesHasRules_AB_unique; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX "_RolesHasRules_AB_unique" ON public."_RolesHasRules" USING btree ("A", "B");
+
+
+--
+-- Name: _RolesHasRules_B_index; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE INDEX "_RolesHasRules_B_index" ON public."_RolesHasRules" USING btree ("B");
+
+
+--
+-- Name: _RulesGroupsHasRules_AB_unique; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX "_RulesGroupsHasRules_AB_unique" ON public."_RulesGroupsHasRules" USING btree ("A", "B");
+
+
+--
+-- Name: _RulesGroupsHasRules_B_index; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE INDEX "_RulesGroupsHasRules_B_index" ON public."_RulesGroupsHasRules" USING btree ("B");
+
+
+--
+-- Name: addresses_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX addresses_uid_key ON public.addresses USING btree (uid);
+
+
+--
+-- Name: appointments_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX appointments_uid_key ON public.appointments USING btree (uid);
+
+
+--
+-- Name: appointments_user_uid_choice_status_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX appointments_user_uid_choice_status_key ON public.appointments USING btree (user_uid, choice, status);
+
+
+--
+-- Name: contacts_address_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX contacts_address_uid_key ON public.contacts USING btree (address_uid);
+
+
+--
+-- Name: contacts_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX contacts_uid_key ON public.contacts USING btree (uid);
+
+
+--
+-- Name: customers_contact_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX customers_contact_uid_key ON public.customers USING btree (contact_uid);
+
+
+--
+-- Name: customers_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX customers_uid_key ON public.customers USING btree (uid);
+
+
+--
+-- Name: deed_types_name_office_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX deed_types_name_office_uid_key ON public.deed_types USING btree (name, office_uid);
+
+
+--
+-- Name: deed_types_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX deed_types_uid_key ON public.deed_types USING btree (uid);
+
+
+--
+-- Name: deed_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX deed_uid_key ON public.deed USING btree (uid);
+
+
+--
+-- Name: document_history_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX document_history_uid_key ON public.document_history USING btree (uid);
+
+
+--
+-- Name: document_types_name_office_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX document_types_name_office_uid_key ON public.document_types USING btree (name, office_uid);
+
+
+--
+-- Name: document_types_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX document_types_uid_key ON public.document_types USING btree (uid);
+
+
+--
+-- Name: documents_notary_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX documents_notary_uid_key ON public.documents_notary USING btree (uid);
+
+
+--
+-- Name: documents_reminder_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX documents_reminder_uid_key ON public.documents_reminder USING btree (uid);
+
+
+--
+-- Name: documents_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX documents_uid_key ON public.documents USING btree (uid);
+
+
+--
+-- Name: email_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX email_uid_key ON public.email USING btree (uid);
+
+
+--
+-- Name: files_file_path_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX files_file_path_key ON public.files USING btree (file_path);
+
+
+--
+-- Name: files_notary_file_path_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX files_notary_file_path_key ON public.files_notary USING btree (file_path);
+
+
+--
+-- Name: files_notary_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX files_notary_uid_key ON public.files_notary USING btree (uid);
+
+
+--
+-- Name: files_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX files_uid_key ON public.files USING btree (uid);
+
+
+--
+-- Name: notes_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX notes_uid_key ON public.notes USING btree (uid);
+
+
+--
+-- Name: notifications_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX notifications_uid_key ON public.notifications USING btree (uid);
+
+
+--
+-- Name: office_folder_anchors_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX office_folder_anchors_uid_key ON public.office_folder_anchors USING btree (uid);
+
+
+--
+-- Name: office_folders_deed_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX office_folders_deed_uid_key ON public.office_folders USING btree (deed_uid);
+
+
+--
+-- Name: office_folders_folder_anchor_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX office_folders_folder_anchor_uid_key ON public.office_folders USING btree (folder_anchor_uid);
+
+
+--
+-- Name: office_folders_folder_number_office_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX office_folders_folder_number_office_uid_key ON public.office_folders USING btree (folder_number, office_uid);
+
+
+--
+-- Name: office_folders_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX office_folders_uid_key ON public.office_folders USING btree (uid);
+
+
+--
+-- Name: office_roles_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX office_roles_uid_key ON public.office_roles USING btree (uid);
+
+
+--
+-- Name: offices_address_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX offices_address_uid_key ON public.offices USING btree (address_uid);
+
+
+--
+-- Name: offices_crpcen_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX offices_crpcen_key ON public.offices USING btree (crpcen);
+
+
+--
+-- Name: offices_idNot_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX "offices_idNot_key" ON public.offices USING btree ("idNot");
+
+
+--
+-- Name: offices_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX offices_uid_key ON public.offices USING btree (uid);
+
+
+--
+-- Name: roles_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX roles_uid_key ON public.roles USING btree (uid);
+
+
+--
+-- Name: rules_groups_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX rules_groups_uid_key ON public.rules_groups USING btree (uid);
+
+
+--
+-- Name: rules_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX rules_uid_key ON public.rules USING btree (uid);
+
+
+--
+-- Name: seats_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX seats_uid_key ON public.seats USING btree (uid);
+
+
+--
+-- Name: subscriptions_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX subscriptions_uid_key ON public.subscriptions USING btree (uid);
+
+
+--
+-- Name: totp_codes_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX totp_codes_uid_key ON public.totp_codes USING btree (uid);
+
+
+--
+-- Name: user_notifications_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX user_notifications_uid_key ON public.user_notifications USING btree (uid);
+
+
+--
+-- Name: user_whitelist_idNot_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX "user_whitelist_idNot_key" ON public.user_whitelist USING btree ("idNot");
+
+
+--
+-- Name: user_whitelist_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX user_whitelist_uid_key ON public.user_whitelist USING btree (uid);
+
+
+--
+-- Name: users_contact_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX users_contact_uid_key ON public.users USING btree (contact_uid);
+
+
+--
+-- Name: users_idNot_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX "users_idNot_key" ON public.users USING btree ("idNot");
+
+
+--
+-- Name: users_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX users_uid_key ON public.users USING btree (uid);
+
+
+--
+-- Name: votes_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX votes_uid_key ON public.votes USING btree (uid);
+
+
+--
+-- Name: whitelist_email_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX whitelist_email_key ON public.whitelist USING btree (email);
+
+
+--
+-- Name: whitelist_uid_key; Type: INDEX; Schema: public; Owner: -
+--
+
+CREATE UNIQUE INDEX whitelist_uid_key ON public.whitelist USING btree (uid);
+
+
+--
+-- Name: _DeedHasDocumentTypes _DeedHasDocumentTypes_A_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public."_DeedHasDocumentTypes"
+    ADD CONSTRAINT "_DeedHasDocumentTypes_A_fkey" FOREIGN KEY ("A") REFERENCES public.deed(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: _DeedHasDocumentTypes _DeedHasDocumentTypes_B_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public."_DeedHasDocumentTypes"
+    ADD CONSTRAINT "_DeedHasDocumentTypes_B_fkey" FOREIGN KEY ("B") REFERENCES public.document_types(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: _DeedTypeHasDocumentTypes _DeedTypeHasDocumentTypes_A_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public."_DeedTypeHasDocumentTypes"
+    ADD CONSTRAINT "_DeedTypeHasDocumentTypes_A_fkey" FOREIGN KEY ("A") REFERENCES public.deed_types(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: _DeedTypeHasDocumentTypes _DeedTypeHasDocumentTypes_B_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public."_DeedTypeHasDocumentTypes"
+    ADD CONSTRAINT "_DeedTypeHasDocumentTypes_B_fkey" FOREIGN KEY ("B") REFERENCES public.document_types(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: _OfficeFolderHasCustomers _OfficeFolderHasCustomers_A_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public."_OfficeFolderHasCustomers"
+    ADD CONSTRAINT "_OfficeFolderHasCustomers_A_fkey" FOREIGN KEY ("A") REFERENCES public.customers(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: _OfficeFolderHasCustomers _OfficeFolderHasCustomers_B_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public."_OfficeFolderHasCustomers"
+    ADD CONSTRAINT "_OfficeFolderHasCustomers_B_fkey" FOREIGN KEY ("B") REFERENCES public.office_folders(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: _OfficeFolderHasStakeholders _OfficeFolderHasStakeholders_A_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public."_OfficeFolderHasStakeholders"
+    ADD CONSTRAINT "_OfficeFolderHasStakeholders_A_fkey" FOREIGN KEY ("A") REFERENCES public.office_folders(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: _OfficeFolderHasStakeholders _OfficeFolderHasStakeholders_B_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public."_OfficeFolderHasStakeholders"
+    ADD CONSTRAINT "_OfficeFolderHasStakeholders_B_fkey" FOREIGN KEY ("B") REFERENCES public.users(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: _OfficeRolesHasRules _OfficeRolesHasRules_A_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public."_OfficeRolesHasRules"
+    ADD CONSTRAINT "_OfficeRolesHasRules_A_fkey" FOREIGN KEY ("A") REFERENCES public.office_roles(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: _OfficeRolesHasRules _OfficeRolesHasRules_B_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public."_OfficeRolesHasRules"
+    ADD CONSTRAINT "_OfficeRolesHasRules_B_fkey" FOREIGN KEY ("B") REFERENCES public.rules(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: _RolesHasRules _RolesHasRules_A_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public."_RolesHasRules"
+    ADD CONSTRAINT "_RolesHasRules_A_fkey" FOREIGN KEY ("A") REFERENCES public.roles(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: _RolesHasRules _RolesHasRules_B_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public."_RolesHasRules"
+    ADD CONSTRAINT "_RolesHasRules_B_fkey" FOREIGN KEY ("B") REFERENCES public.rules(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: _RulesGroupsHasRules _RulesGroupsHasRules_A_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public."_RulesGroupsHasRules"
+    ADD CONSTRAINT "_RulesGroupsHasRules_A_fkey" FOREIGN KEY ("A") REFERENCES public.rules(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: _RulesGroupsHasRules _RulesGroupsHasRules_B_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public."_RulesGroupsHasRules"
+    ADD CONSTRAINT "_RulesGroupsHasRules_B_fkey" FOREIGN KEY ("B") REFERENCES public.rules_groups(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: appointments appointments_user_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.appointments
+    ADD CONSTRAINT appointments_user_uid_fkey FOREIGN KEY (user_uid) REFERENCES public.users(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: contacts contacts_address_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.contacts
+    ADD CONSTRAINT contacts_address_uid_fkey FOREIGN KEY (address_uid) REFERENCES public.addresses(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: customers customers_contact_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.customers
+    ADD CONSTRAINT customers_contact_uid_fkey FOREIGN KEY (contact_uid) REFERENCES public.contacts(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: customers customers_office_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.customers
+    ADD CONSTRAINT customers_office_uid_fkey FOREIGN KEY (office_uid) REFERENCES public.offices(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: deed deed_deed_type_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.deed
+    ADD CONSTRAINT deed_deed_type_uid_fkey FOREIGN KEY (deed_type_uid) REFERENCES public.deed_types(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: deed_types deed_types_office_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.deed_types
+    ADD CONSTRAINT deed_types_office_uid_fkey FOREIGN KEY (office_uid) REFERENCES public.offices(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: document_history document_history_document_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.document_history
+    ADD CONSTRAINT document_history_document_uid_fkey FOREIGN KEY (document_uid) REFERENCES public.documents(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: document_types document_types_office_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.document_types
+    ADD CONSTRAINT document_types_office_uid_fkey FOREIGN KEY (office_uid) REFERENCES public.offices(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: documents documents_depositor_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.documents
+    ADD CONSTRAINT documents_depositor_uid_fkey FOREIGN KEY (depositor_uid) REFERENCES public.customers(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: documents documents_document_type_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.documents
+    ADD CONSTRAINT documents_document_type_uid_fkey FOREIGN KEY (document_type_uid) REFERENCES public.document_types(uid) ON UPDATE CASCADE ON DELETE RESTRICT;
+
+
+--
+-- Name: documents documents_folder_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.documents
+    ADD CONSTRAINT documents_folder_uid_fkey FOREIGN KEY (folder_uid) REFERENCES public.office_folders(uid) ON UPDATE CASCADE ON DELETE RESTRICT;
+
+
+--
+-- Name: documents_notary documents_notary_customer_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.documents_notary
+    ADD CONSTRAINT documents_notary_customer_uid_fkey FOREIGN KEY (customer_uid) REFERENCES public.customers(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: documents_notary documents_notary_depositor_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.documents_notary
+    ADD CONSTRAINT documents_notary_depositor_uid_fkey FOREIGN KEY (depositor_uid) REFERENCES public.users(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: documents_notary documents_notary_folder_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.documents_notary
+    ADD CONSTRAINT documents_notary_folder_uid_fkey FOREIGN KEY (folder_uid) REFERENCES public.office_folders(uid) ON UPDATE CASCADE ON DELETE RESTRICT;
+
+
+--
+-- Name: documents_reminder documents_reminder_document_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.documents_reminder
+    ADD CONSTRAINT documents_reminder_document_uid_fkey FOREIGN KEY (document_uid) REFERENCES public.documents(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: files files_document_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.files
+    ADD CONSTRAINT files_document_uid_fkey FOREIGN KEY (document_uid) REFERENCES public.documents(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: files_notary files_notary_document_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.files_notary
+    ADD CONSTRAINT files_notary_document_uid_fkey FOREIGN KEY (document_uid) REFERENCES public.documents_notary(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: notes notes_customer_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.notes
+    ADD CONSTRAINT notes_customer_uid_fkey FOREIGN KEY (customer_uid) REFERENCES public.customers(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: notes notes_folder_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.notes
+    ADD CONSTRAINT notes_folder_uid_fkey FOREIGN KEY (folder_uid) REFERENCES public.office_folders(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: office_folders office_folders_deed_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.office_folders
+    ADD CONSTRAINT office_folders_deed_uid_fkey FOREIGN KEY (deed_uid) REFERENCES public.deed(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: office_folders office_folders_folder_anchor_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.office_folders
+    ADD CONSTRAINT office_folders_folder_anchor_uid_fkey FOREIGN KEY (folder_anchor_uid) REFERENCES public.office_folder_anchors(uid) ON UPDATE CASCADE ON DELETE SET NULL;
+
+
+--
+-- Name: office_folders office_folders_office_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.office_folders
+    ADD CONSTRAINT office_folders_office_uid_fkey FOREIGN KEY (office_uid) REFERENCES public.offices(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: office_roles office_roles_office_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.office_roles
+    ADD CONSTRAINT office_roles_office_uid_fkey FOREIGN KEY (office_uid) REFERENCES public.offices(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: offices offices_address_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.offices
+    ADD CONSTRAINT offices_address_uid_fkey FOREIGN KEY (address_uid) REFERENCES public.addresses(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: seats seats_subscription_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.seats
+    ADD CONSTRAINT seats_subscription_uid_fkey FOREIGN KEY (subscription_uid) REFERENCES public.subscriptions(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: seats seats_user_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.seats
+    ADD CONSTRAINT seats_user_uid_fkey FOREIGN KEY (user_uid) REFERENCES public.users(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: subscriptions subscriptions_office_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.subscriptions
+    ADD CONSTRAINT subscriptions_office_uid_fkey FOREIGN KEY (office_uid) REFERENCES public.offices(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: totp_codes totp_codes_customer_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.totp_codes
+    ADD CONSTRAINT totp_codes_customer_uid_fkey FOREIGN KEY (customer_uid) REFERENCES public.customers(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: user_notifications user_notifications_notification_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.user_notifications
+    ADD CONSTRAINT user_notifications_notification_uid_fkey FOREIGN KEY (notification_uid) REFERENCES public.notifications(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: user_notifications user_notifications_user_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.user_notifications
+    ADD CONSTRAINT user_notifications_user_uid_fkey FOREIGN KEY (user_uid) REFERENCES public.users(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: users users_contact_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.users
+    ADD CONSTRAINT users_contact_uid_fkey FOREIGN KEY (contact_uid) REFERENCES public.contacts(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: users users_office_role_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.users
+    ADD CONSTRAINT users_office_role_uid_fkey FOREIGN KEY (office_role_uid) REFERENCES public.office_roles(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: users users_office_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.users
+    ADD CONSTRAINT users_office_uid_fkey FOREIGN KEY (office_uid) REFERENCES public.offices(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: users users_roles_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.users
+    ADD CONSTRAINT users_roles_uid_fkey FOREIGN KEY (roles_uid) REFERENCES public.roles(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: votes votes_appointment_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.votes
+    ADD CONSTRAINT votes_appointment_uid_fkey FOREIGN KEY (appointment_uid) REFERENCES public.appointments(uid) ON UPDATE CASCADE ON DELETE CASCADE;
+
+
+--
+-- Name: votes votes_voter_uid_fkey; Type: FK CONSTRAINT; Schema: public; Owner: -
+--
+
+ALTER TABLE ONLY public.votes
+    ADD CONSTRAINT votes_voter_uid_fkey FOREIGN KEY (voter_uid) REFERENCES public.users(uid) ON UPDATE CASCADE ON DELETE RESTRICT;
+
+
+--
+-- PostgreSQL database dump complete
+--
+
+