Initial local backup snapshot

docs/compliance/ISO27001-RISK-001-matrice-ecarts.md

@@ -0,0 +1,33 @@
+# ISO27001-RISK-001 - Matrice d'ecarts initiale
+
+## Etat au 12 juin 2026
+
+### Deja en place dans l'application
+
+- separation production / preproduction ;
+- journal d’audit administrateur ;
+- gestion des roles ;
+- consentement explicite dans plusieurs parcours de saisie ;
+- tour operationnel de supervision ;
+- pages de confidentialite.
+
+### Ecart prioritaire P1
+
+- MFA absente ;
+- verrouillage apres tentatives repetees absent ;
+- auto-service export de donnees absent ;
+- auto-service suppression de compte absent ;
+- politique de retention non outillee.
+
+### Ecart prioritaire P2
+
+- algorithme de mot de passe non aligne sur l’exigence Argon2id du cahier ;
+- registre fournisseurs a formaliser ;
+- procedure d’incident et registre de violation a industrialiser ;
+- mentions legales, cookies et CGU a faire valider juridiquement.
+
+### Ecart prioritaire P3
+
+- etiquetage de classification des donnees a diffuser dans les procedures internes ;
+- declaration d’applicabilite ISO 27001 a construire ;
+- dossier d’audit interne a formaliser.

docs/compliance/README.md

@@ -0,0 +1,33 @@
+# Centre de conformite - Portail Associations 973
+
+Ce dossier regroupe les premiers livrables documentaires pour structurer la mise en conformite RGPD et la preparation ISO 27001.
+
+Contenu initial :
+
+- `SEC-002-gestion-des-sauvegardes-et-restauration.md`
+- `SEC-002A-preuve-execution-sauvegarde.md`
+- `SEC-002B-test-restauration-historise.md`
+- `SEC-001-gestion-des-acces.md`
+- `SEC-005-registre-fournisseurs-et-sous-traitants.md`
+- `RGPD-005-accord-de-traitement-des-donnees-dpa.md`
+- `RGPD-006-politique-de-retention-des-donnees.md`
+- `RGPD-007-procedure-suppression-et-purge-planifiee.md`
+- `RGPD-008-rapport-mensuel-dpo-exploitation.md`
+- `RGPD-002-registre-des-traitements.md`
+- `ISO27001-RISK-001-matrice-ecarts.md`
+- `SEC-003-gestion-des-incidents.md`
+
+Important :
+
+- ces documents sont des bases de travail et non des validations juridiques ;
+- ils doivent etre completes et approuves par la CCDS ;
+- aucune certification ISO 27001 ne peut etre affichee tant qu’un audit externe n’a pas eu lieu.
+
+Usage recommande :
+
+- `SEC-002` pose la politique generale ;
+- `SEC-002A` sert a tracer les preuves d'execution des sauvegardes ;
+- `SEC-002B` sert a historiser les tests de restauration ;
+- `RGPD-008` sert de rapport mensuel DPO / exploitation ;
+- `SEC-003` cadre la gestion des incidents ;
+- `RGPD-002` reste le socle du registre des traitements.

docs/compliance/RGPD-002-registre-des-traitements.md

@@ -0,0 +1,46 @@
+# RGPD-002 - Registre des traitements
+
+## 1. Gestion des comptes utilisateurs
+
+- Finalite : authentifier les utilisateurs et gerer les acces.
+- Donnees : nom, email, role, methode de connexion, horodatages de connexion.
+- Base legale : execution du service / interet legitime.
+- Duree : pendant la vie du compte, puis archivage selon politique a confirmer.
+- Destinataires : services internes habilites, hebergeur, exploitant technique.
+
+## 2. Gestion des profils association
+
+- Finalite : tenir a jour la fiche d’une association.
+- Donnees : nom association, SIRET, RNA, adresse, contacts, gouvernance, thematiques.
+- Base legale : execution du service.
+- Duree : tant que la fiche est active, puis selon politique de conservation a confirmer.
+- Destinataires : services internes habilites, public pour les champs explicitement publies.
+
+## 3. Gestion documentaire
+
+- Finalite : reception, stockage et consultation des pieces justificatives.
+- Donnees : documents administratifs, metadonnees de depot, auteur, dates.
+- Base legale : execution du service / obligation administrative selon le cas.
+- Duree : selon obligations legales et internes a formaliser.
+
+## 4. Gestion des demandes, reservations et materiel
+
+- Finalite : instruire, valider et suivre les demandes.
+- Donnees : informations de demande, dates, decisions, historique de workflow.
+- Base legale : execution du service.
+- Duree : 3 ans cible a confirmer pour les reservations, autres durees a arbitrer.
+
+## 5. Journalisation et securite
+
+- Finalite : securiser le portail, tracer les actions sensibles, enqueter en cas d’incident.
+- Donnees : actions, utilisateur, adresse IP, dates, entites touchees.
+- Base legale : interet legitime de securite.
+- Duree : cible minimale 12 mois.
+
+## Points a finaliser
+
+- coordonnees du responsable de traitement ;
+- coordonnees du DPO ;
+- durees de conservation exactes ;
+- sous-traitants et DPA ;
+- procedures d’exercice des droits.

docs/compliance/RGPD-005-accord-de-traitement-des-donnees-dpa.md

@@ -0,0 +1,57 @@
+# RGPD-005 - Accord de traitement des donnees (DPA)
+
+Reference : RGPD-005  
+Version : 1.0  
+Proprietaire : DPO / RSSI
+
+## Objet
+
+Le present accord encadre le traitement des donnees personnelles effectue par le fournisseur pour le compte du Portail Associations 973 conformement a l'article 28 du RGPD.
+
+## Obligations du sous-traitant
+
+Le sous-traitant s'engage a :
+
+- traiter les donnees uniquement sur instruction documentee ;
+- respecter la confidentialite ;
+- mettre en oeuvre des mesures de securite adaptees ;
+- notifier toute violation de donnees ;
+- assister le responsable de traitement dans ses obligations RGPD ;
+- supprimer ou restituer les donnees a la fin du contrat.
+
+## Mesures minimales de securite
+
+### Controle d'acces
+
+- authentification forte ;
+- gestion des habilitations ;
+- journalisation.
+
+### Protection des donnees
+
+- chiffrement TLS ;
+- chiffrement au repos ;
+- sauvegardes regulieres.
+
+### Continuite
+
+- plan de reprise ;
+- plan de continuite ;
+- surveillance securite.
+
+## Violation de donnees
+
+Toute violation doit etre notifiee :
+
+- dans un delai maximal de 24 heures ;
+- avec description de l'incident ;
+- impact potentiel ;
+- mesures correctives engagees.
+
+## Audit
+
+Le Portail Associations 973 se reserve le droit :
+
+- de demander des justificatifs de conformite ;
+- de realiser un audit documentaire ;
+- d'obtenir les certifications applicables.

docs/compliance/RGPD-006-politique-de-retention-des-donnees.md

@@ -0,0 +1,65 @@
+# RGPD-006 - Politique de retention des donnees
+
+Reference : RGPD-006  
+Version : 1.0  
+Proprietaire : DPO / RSSI
+
+## Objectif
+
+Garantir que les donnees personnelles ne soient conservees que pour la duree strictement necessaire a leur finalite.
+
+## Principes
+
+Les donnees doivent etre :
+
+- exactes ;
+- limitees ;
+- pertinentes ;
+- supprimees lorsqu'elles ne sont plus necessaires.
+
+## Tableau de conservation
+
+| Categorie | Finalite | Duree active | Archivage | Suppression |
+| --- | --- | --- | --- | --- |
+| Comptes utilisateurs | Gestion acces | Duree du compte | 30 jours | Automatique |
+| Profils associations | Gestion administrative | Duree activite | 3 ans | Automatique |
+| Reservations | Historique gestion | 3 ans | 2 ans | Automatique |
+| Documents administratifs | Obligations legales | Selon reglementation | Oui | Selon echeance |
+| Journaux securite | Cybersecurite | 12 mois | Non | Automatique |
+| Consentements RGPD | Preuve juridique | Duree du consentement | 3 ans | Automatique |
+| Tickets support | Support utilisateurs | 2 ans | 1 an | Automatique |
+| Notifications emails | Tracabilite | 12 mois | Non | Automatique |
+| Sauvegardes | Continuite d'activite | 90 jours | Non | Rotation automatique |
+
+## Suppression de compte
+
+1. Demande de suppression  
+2. Compte desactive immediatement  
+3. Periode de retention de 30 jours  
+4. Suppression ou anonymisation definitive
+
+## Archivage
+
+Les donnees conservees pour obligations legales :
+
+- sont isolees ;
+- accessibles uniquement aux personnes habilitees ;
+- protegees par chiffrement.
+
+## Controle automatique
+
+Le systeme doit executer :
+
+- une verification quotidienne des echeances ;
+- une purge automatique ;
+- un journal de suppression.
+
+## Exigence technique
+
+Mettre en place une tache planifiee quotidienne permettant :
+
+- d'identifier les donnees expirees ;
+- d'executer les regles de conservation ;
+- d'anonymiser ou supprimer les donnees concernees ;
+- d'enregistrer l'operation dans les journaux d'audit ;
+- de produire un rapport mensuel de retention consultable par le DPO.

docs/compliance/RGPD-007-procedure-suppression-et-purge-planifiee.md

@@ -0,0 +1,154 @@
+# RGPD-007 - Procedure de suppression et de purge planifiee des donnees
+
+Reference : RGPD-007  
+Version : 1.0  
+Proprietaire : DPO / RSSI  
+Classification : Interne
+
+## Objectif
+
+Assurer la suppression, l'anonymisation et la purge automatique des donnees conformement au RGPD, aux obligations legales de conservation et aux exigences ISO 27001.
+
+## Objectifs
+
+Cette procedure vise a :
+
+- garantir le respect du principe de limitation de conservation des donnees ;
+- eviter la conservation excessive d'informations personnelles ;
+- assurer la tracabilite des suppressions ;
+- automatiser les operations de purge ;
+- permettre une recuperation limitee en cas d'erreur utilisateur.
+
+## Cycle de vie des donnees
+
+Creation -> Utilisation -> Archivage -> Marquage pour suppression -> Periode de retention -> Suppression / Anonymisation -> Journalisation -> Purge definitive
+
+## Etats de suppression
+
+### Etat 1 : Actif
+
+La donnee est utilisee normalement.
+
+### Etat 2 : Desactive
+
+La donnee n'est plus utilisee mais reste disponible.
+
+Actions :
+
+- desactivation immediate ;
+- retrait des acces ;
+- notification utilisateur.
+
+### Etat 3 : En retention
+
+La donnee est conservee temporairement avant suppression definitive.
+
+Duree par defaut : 30 jours.
+
+### Etat 4 : Purge definitive
+
+La donnee est :
+
+- supprimee ;
+- anonymisee ;
+- retiree des systemes actifs.
+
+## Suppression des comptes utilisateurs
+
+1. Demande depuis `Mon compte`  
+2. Confirmation explicite  
+3. Desactivation immediate  
+4. Stockage de `deletion_requested_at` et `purge_scheduled_at`  
+5. Purge ou anonymisation definitive a echeance
+
+## Politique d'anonymisation
+
+Certaines donnees doivent etre conservees pour :
+
+- statistiques ;
+- obligations comptables ;
+- tracabilite administrative.
+
+Exemple :
+
+- Avant : `Jean Dupont / jean@email.com`
+- Apres : `Utilisateur supprime / deleted-user-456`
+
+## Purge planifiee automatique
+
+Frequence : tous les jours  
+Horaire recommande : 03h00
+
+Le moteur de purge recherche les comptes marques pour suppression avec echeance depassee et hors `LEGAL_HOLD`.
+
+Actions executees :
+
+- suppression ou anonymisation du profil ;
+- suppression MFA ;
+- suppression preferences ;
+- purge des documents et metadonnees lorsque le perimetre le permet ;
+- journalisation d'audit.
+
+## Journal d'audit obligatoire
+
+Chaque purge genere une trace contenant au minimum :
+
+- identifiant ;
+- type ;
+- horodatage UTC ;
+- action ;
+- executant ;
+- resultat.
+
+## Sauvegardes
+
+Les donnees supprimees peuvent subsister temporairement dans les sauvegardes.
+
+- duree maximale : 90 jours ;
+- suppression definitive apres rotation ;
+- aucune restauration ciblee d'une donnee supprimee sauf incident majeur documente.
+
+## Controles DPO
+
+Le DPO doit pouvoir consulter :
+
+- comptes supprimes ;
+- comptes en attente ;
+- purges effectuees ;
+- echecs de purge.
+
+## Rapports mensuels
+
+Le systeme doit generer un rapport de retention contenant :
+
+- volumes supprimes ;
+- volumes anonymises ;
+- incidents ;
+- exceptions ;
+- actions manuelles.
+
+Conservation cible : 3 ans.
+
+## Cas d'exception
+
+La suppression peut etre suspendue si :
+
+- obligation legale ;
+- procedure judiciaire ;
+- enquete administrative ;
+- demande d'une autorite competente.
+
+Statut : `LEGAL_HOLD`
+
+## Exigences techniques
+
+Le systeme doit implementer :
+
+- `deletion_requested_at`
+- `purge_scheduled_at`
+- `legal_hold`
+- `legal_hold_reason`
+- tache planifiee quotidienne de retention ;
+- anonymisation automatique ;
+- journalisation d'audit ;
+- rapport de retention.

docs/compliance/RGPD-008-rapport-mensuel-dpo-exploitation.md

@@ -0,0 +1,90 @@
+# RGPD-008 - Rapport mensuel DPO et exploitation
+
+Reference : RGPD-008  
+Version : 1.0  
+Proprietaire : DPO / RSSI / Exploitation  
+Usage : rapport de reference mensuel pour la conformite operationnelle
+
+## Objectif
+
+Fournir un cadre simple pour suivre chaque mois les preuves d'exploitation utiles a la conformite : sauvegardes, restaurations, incidents, retention, ecarts et actions.
+
+## Finalite
+
+Passer d'un suivi declaratif a un pilotage mensuel relu, traçable et presentable en cas d'audit interne, de controle DPO ou de revue de direction.
+
+## Modele de rapport
+
+### 1. Periode
+
+- Mois couvre :
+- Date de generation :
+- Redacteur :
+- Relecture :
+
+### 2. Synthese executive
+
+- Niveau de confiance exploitation : maitrise / sous surveillance / fragile
+- Point fort du mois :
+- Point de vigilance du mois :
+- Decision ou arbitrage attendu :
+
+### 3. Sauvegardes
+
+- Derniere sauvegarde reussie :
+- Taux de succes estime :
+- Echecs notables :
+- Preuve de sauvegarde rattachee :
+- Commentaire exploitation :
+
+### 4. Restaurations
+
+- Dernier test de restauration :
+- Environnement utilise :
+- Resultat :
+- Ecart majeur :
+- Action de suivi :
+
+### 5. Incidents et violations
+
+- Nombre d'incidents securite :
+- Nombre d'incidents a impact donnees personnelles :
+- Notification CNIL necessaire : oui / non
+- Revue post-incident realisee : oui / non / non applicable
+
+### 6. Retention et purge
+
+- Rapport de retention genere :
+- Purges executees :
+- Legal holds actifs :
+- Ecart ou blocage de purge :
+
+### 7. Sous-traitants et preuves documentaires
+
+- DPA ajoutes ou relus :
+- Fournisseurs a revoir :
+- Registre des traitements mis a jour : oui / non
+- Pages publiques juridiques relues : oui / non
+
+### 8. Plan d'action
+
+| Priorite | Sujet | Action | Responsable | Echeance |
+| --- | --- | --- | --- | --- |
+| Haute |  |  |  |  |
+| Moyenne |  |  |  |  |
+| Basse |  |  |  |  |
+
+## Criteres d'un rapport exploitable
+
+Le rapport est juge exploitable s'il permet de repondre simplement aux questions suivantes :
+
+- savons-nous si les sauvegardes ont reellement tourne ;
+- savons-nous quand une restauration a ete testee pour la derniere fois ;
+- savons-nous si un incident a eu un impact RGPD ;
+- savons-nous quels ecarts restent ouverts ;
+- savons-nous qui doit agir et avant quand.
+
+## Conservation cible
+
+- 3 ans minimum ;
+- plus longtemps si le cadre interne, contractuel ou d'audit l'exige.

docs/compliance/SEC-001-gestion-des-acces.md

@@ -0,0 +1,131 @@
+# SEC-001 - Gestion des acces et politique MFA interne
+
+## Objectif
+
+Definir les regles minimales de gestion des acces internes et l’obligation de MFA pour les roles exposant des donnees sensibles, des fonctions d’administration ou des actions metier critiques.
+
+## Principes generaux
+
+- le principe du moindre privilege s’applique a tous les comptes ;
+- les acces internes doivent etre attribues selon le role reel de l’agent ;
+- tout compte interne sensible doit disposer d’un MFA actif ;
+- la methode cible est l’application Authenticator (TOTP) ;
+- la desactivation complete du MFA est interdite pour les roles internes soumis a la politique.
+
+## Roles internes soumis a MFA obligatoire
+
+- `super_admin`
+- `admin`
+- `directrice`
+- `accueil`
+- `service_terrain`
+- `logistique_controle`
+
+Les comptes association, membres association et comptes publics ou lecture seule ne sont pas soumis a cette obligation stricte dans l’etat actuel de la politique.
+
+## Politique par role
+
+### `super_admin`
+
+- MFA obligatoire ;
+- methode cible : `authenticator_app` ;
+- methode email non retenue comme mode normal ;
+- alignement cible prioritaire.
+
+### `admin`
+
+- MFA obligatoire ;
+- Authenticator recommande ;
+- code email tolere en phase transitoire ou secours controle.
+
+### `directrice`
+
+- MFA obligatoire ;
+- Authenticator recommande ;
+- code email tolere en secours controle.
+
+### `accueil`
+
+- MFA obligatoire ;
+- Authenticator fortement recommande ;
+- code email possible au depart pour accompagner la prise en main.
+
+### `service_terrain`
+
+- MFA obligatoire ;
+- Authenticator recommande par defaut ;
+- code email possible en repli temporaire.
+
+### `logistique_controle`
+
+- MFA obligatoire ;
+- Authenticator recommande par defaut ;
+- code email possible en repli temporaire.
+
+## Regles d’activation
+
+- a la creation d’un compte interne, le compte entre dans un statut MFA requis ;
+- au premier acces, le compte doit pouvoir etre oriente vers la configuration du MFA ;
+- pour `super_admin`, l’alignement cible est une activation Authenticator prioritaire ;
+- pour les autres roles internes, une phase transitoire peut subsister avant obligation TOTP complete.
+
+## Regles de blocage
+
+- un compte interne sans MFA ne doit pas etre considere comme conforme a la politique ;
+- la desactivation du MFA est refusee pour les roles internes soumis a obligation ;
+- les fonctions sensibles doivent rester reservees a des comptes authentifies et journalises ;
+- les comptes en transition doivent etre identifies dans les vues de pilotage conformite.
+
+## Reinitialisation et secours
+
+- la reinitialisation MFA doit etre reservee a un role habilite ;
+- toute reinitialisation doit etre journalisee ;
+- en cas de perte du terminal Authenticator :
+  - l’ancien secret doit etre invalide ;
+  - un reenrolement doit etre declenche ;
+  - la tracabilite complete doit etre conservee.
+
+## Journalisation obligatoire
+
+Les evenements suivants doivent etre traces :
+
+- activation MFA ;
+- changement de methode MFA ;
+- desactivation exceptionnelle ;
+- reinitialisation MFA ;
+- echecs repetes de connexion ;
+- verrouillage anti-bruteforce.
+
+## Phases de deploiement
+
+### Phase 1
+
+- MFA obligatoire pour tous les roles internes ;
+- Authenticator cible pour tous ;
+- code email encore tolere hors `super_admin`.
+
+### Phase 2
+
+- Authenticator obligatoire pour :
+  - `super_admin`
+  - `admin`
+  - `directrice`
+
+### Phase 3
+
+- Authenticator obligatoire pour tous les roles internes.
+
+## Mise en oeuvre actuelle dans le portail
+
+- MFA obligatoire active pour les roles internes ;
+- Authenticator disponible pour les comptes locaux ;
+- super administration ciblee en priorite pour l’alignement TOTP ;
+- code email encore present comme repli pour une partie des roles en phase transitoire ;
+- journalisation et verrouillage anti-bruteforce deja en place.
+
+## Points de vigilance
+
+- confirmer le calendrier de bascule Phase 2 puis Phase 3 ;
+- formaliser la procedure de reinitialisation MFA par un role habilite ;
+- documenter la conduite a tenir en cas de perte du terminal ou d’indisponibilite email ;
+- verifier regulierement la couverture TOTP des comptes internes actifs.

docs/compliance/SEC-002-gestion-des-sauvegardes-et-restauration.md

@@ -0,0 +1,113 @@
+# SEC-002 - Gestion des sauvegardes et restauration
+
+Reference : SEC-002  
+Version : 1.0  
+Proprietaire : RSSI / Administrateur Systeme
+
+## Objectif
+
+Garantir la disponibilite, l'integrite et la recuperation des donnees du Portail Associations 973 en cas d'incident, erreur humaine, panne technique ou cyberattaque.
+
+## Politique de sauvegarde
+
+### Sauvegarde quotidienne
+
+- base de donnees ;
+- documents ;
+- configuration systeme.
+
+Conservation : 30 jours
+
+### Sauvegarde hebdomadaire
+
+Conservation : 12 semaines
+
+### Sauvegarde mensuelle
+
+Conservation : 12 mois
+
+## Regle 3-2-1
+
+Le systeme doit maintenir :
+
+- 3 copies des donnees ;
+- 2 supports differents ;
+- 1 copie externalisee.
+
+## Protection des sauvegardes
+
+Les sauvegardes doivent etre :
+
+- chiffrees ;
+- horodatees ;
+- controlees ;
+- protegees contre la modification.
+
+## Revue quotidienne
+
+Verification automatique :
+
+- succes des sauvegardes ;
+- integrite des fichiers ;
+- capacite de stockage.
+
+En cas d'echec :
+
+- alerte automatique ;
+- ouverture d'un ticket.
+
+## Revue mensuelle
+
+Controle du RSSI :
+
+- sauvegardes realisees ;
+- integrite verifiee ;
+- rotation appliquee ;
+- chiffrement actif ;
+- alertes traitees.
+
+## Test de restauration
+
+Frequence : trimestrielle
+
+Etapes :
+
+1. selection d'une sauvegarde ;
+2. restauration dans un environnement isole ;
+3. validation des donnees, documents et services ;
+4. destruction de l'environnement de test.
+
+## Procedure de restauration
+
+1. validation par le RSSI ou l'administrateur ;
+2. identification du point de restauration ;
+3. execution ;
+4. controle fonctionnel ;
+5. remise en production.
+
+## Objectifs de reprise
+
+- RPO : 1 heure
+- RTO : 4 heures
+
+## Journalisation
+
+Chaque operation de sauvegarde ou restauration doit enregistrer :
+
+- date ;
+- type ;
+- resultat ;
+- executant ;
+- reference.
+
+## Rapport de revue des sauvegardes
+
+Un rapport mensuel doit contenir :
+
+- nombre de sauvegardes realisees ;
+- taux de reussite ;
+- incidents detectes ;
+- tests de restauration effectues ;
+- actions correctives.
+
+Conservation cible : 3 ans.

docs/compliance/SEC-002A-preuve-execution-sauvegarde.md

@@ -0,0 +1,76 @@
+# SEC-002A - Fiche de preuve d'execution des sauvegardes
+
+Reference : SEC-002A  
+Version : 1.0  
+Proprietaire : Exploitation / RSSI  
+Usage : preuve operationnelle a completer a chaque revue ou a raccorder a l'outillage d'exploitation
+
+## Objectif
+
+Conserver une preuve simple, exploitable et auditable qu'une sauvegarde a bien ete executee, verifiee et rattachee a un environnement donne.
+
+## Regles d'usage
+
+- une fiche par sauvegarde de reference ou par execution significative ;
+- completable manuellement si aucun connecteur n'est encore branche ;
+- remplaceable plus tard par une remontee automatisee depuis l'outil d'exploitation ;
+- les pieces jointes ou sorties console peuvent etre archivees en annexe si utile.
+
+## Champs minimum a tracer
+
+- date et heure de la sauvegarde ;
+- environnement concerne ;
+- type de sauvegarde ;
+- volume ou perimetre couvert ;
+- statut final ;
+- retention appliquee ;
+- executant ou source de preuve ;
+- commentaire ou anomalie.
+
+## Modele a completer
+
+### 1. Identification
+
+- Reference interne :
+- Date et heure d'execution :
+- Environnement : production / preproduction / test / autre
+- Type : base / documents / systeme / complet / autre
+- Volume ou perimetre :
+- Retention appliquee :
+
+### 2. Resultat
+
+- Statut : succes / succes partiel / echec
+- Integrite verifiee : oui / non
+- Chiffrement confirme : oui / non / non applicable
+- Localisation de stockage :
+- Horodatage de la preuve source :
+
+### 3. Source de preuve
+
+- Outil ou source :
+- Identifiant d'execution / job / ticket :
+- Capture, log ou rapport associe :
+- Personne ou service ayant controle :
+
+### 4. Observations
+
+- Incident ou ecart detecte :
+- Action corrective engagee :
+- Date de cloture :
+
+## Criteres d'acceptation d'une preuve exploitable
+
+Une preuve est consideree exploitable si elle contient au minimum :
+
+- une date et heure verifiables ;
+- un environnement clairement identifie ;
+- un statut explicite ;
+- un perimetre ou volume trace ;
+- une retention indiquee ;
+- une source ou un commentaire permettant de remonter au fait technique.
+
+## Conservation cible
+
+- 3 ans minimum pour les preuves de reference ;
+- plus longtemps si la politique interne ou l'audit l'exige.

docs/compliance/SEC-002B-test-restauration-historise.md

@@ -0,0 +1,82 @@
+# SEC-002B - Fiche de test de restauration historise
+
+Reference : SEC-002B  
+Version : 1.0  
+Proprietaire : Exploitation / RSSI  
+Usage : journal de preuve des restaurations testees
+
+## Objectif
+
+Tracer de facon claire les restaurations reellement testees afin de demontrer que la capacite de reprise n'est pas seulement theorique.
+
+## Regles d'usage
+
+- un enregistrement par test de restauration ;
+- privilegier un environnement isole ;
+- rattacher le test a une sauvegarde ou a une periode source ;
+- conserver le resultat, les ecarts et la validation finale.
+
+## Champs minimum a tracer
+
+- date du test ;
+- environnement de restauration ;
+- perimetre restaure ;
+- source ou point de restauration ;
+- resultat ;
+- responsable ;
+- observations et suites.
+
+## Modele a completer
+
+### 1. Identification du test
+
+- Reference du test :
+- Date du test :
+- Environnement de test :
+- Responsable du controle :
+- Participants :
+
+### 2. Perimetre restaure
+
+- Sauvegarde source / point de restauration :
+- Perimetre : base / documents / systeme / complet / autre
+- Systeme ou service concerne :
+- Objectif du test :
+
+### 3. Resultat
+
+- Resultat global : conforme / partiel / echec
+- Duree reelle de restauration :
+- RPO observe :
+- RTO observe :
+- Integrite des donnees restaurees : oui / non / partiel
+- Verification fonctionnelle realisee : oui / non
+
+### 4. Ecarts et actions
+
+- Ecarts constates :
+- Risques identifies :
+- Actions correctives :
+- Date cible de correction :
+- Responsable de suivi :
+
+### 5. Validation
+
+- Test valide par :
+- Date de validation :
+- Commentaire final :
+
+## Lecture attendue dans le pilotage
+
+Le tableau de pilotage doit pouvoir mettre en avant au minimum :
+
+- la derniere restauration testee ;
+- son resultat ;
+- son environnement ;
+- son responsable ;
+- l'absence de test recent si le delai cible est depasse.
+
+## Frequence cible
+
+- trimestrielle minimum ;
+- immediate apres changement majeur d'infrastructure si necessaire.

docs/compliance/SEC-003-gestion-des-incidents.md

@@ -0,0 +1,88 @@
+# SEC-003 - Gestion des incidents de securite
+
+Reference : SEC-003  
+Version : 1.0  
+Proprietaire : RSSI / DPO  
+Classification : Interne
+
+## Objectif
+
+Definir le processus de detection, d'analyse, de traitement et de suivi des incidents de securite susceptibles d'affecter la confidentialite, l'integrite, la disponibilite ou la tracabilite des donnees et services du Portail Associations 973.
+
+## Definition d'un incident
+
+Est considere comme incident tout evenement pouvant entrainer :
+
+- une indisponibilite du portail ;
+- une compromission de compte ;
+- une fuite de donnees ;
+- une alteration d'informations ;
+- une perte de donnees ;
+- une tentative d'intrusion ;
+- un malware ou ransomware ;
+- un acces non autorise ;
+- un dysfonctionnement critique.
+
+## Classification des incidents
+
+| Niveau | Description | Delai de traitement |
+| --- | --- | --- |
+| Critique | Fuite de donnees, ransomware, indisponibilite majeure | Immediat |
+| Eleve | Compromission de compte administrateur | < 4 h |
+| Moyen | Incident limite a un utilisateur | < 24 h |
+| Faible | Anomalie sans impact securite majeur | < 72 h |
+
+## Processus de gestion
+
+1. Detection  
+   Sources possibles : alertes systeme, supervision, journaux de securite, signalement utilisateur, fournisseur externe.
+
+2. Qualification  
+   Analyse de la nature, du perimetre, des donnees concernees, de la criticite et du risque RGPD. Creation d'un ticket securite.
+
+3. Confinement  
+   Exemples : blocage compte, desactivation service, isolement serveur, suspension acces.
+
+4. Investigation  
+   Analyse de l'origine, de la vulnerabilite, des systemes impactes, des donnees et de la chronologie. Conservation des preuves : logs, captures, rapports techniques.
+
+5. Remediation  
+   Exemples : reinitialisation mots de passe, correctif logiciel, mise a jour de securite, restauration des donnees, suppression acces compromis.
+
+6. Cloture  
+   Service restaure, risque maitrise, rapport final produit.
+
+## Violations de donnees personnelles
+
+En cas de violation :
+
+- evaluation immediate ;
+- identification du nombre de personnes concernees ;
+- qualification des donnees ;
+- analyse de l'impact potentiel ;
+- notification a la CNIL sous 72 heures si necessaire ;
+- information des personnes concernees lorsque le risque est eleve.
+
+## Registre des incidents
+
+Chaque incident doit contenir :
+
+- reference ;
+- date ;
+- niveau ;
+- description ;
+- impact ;
+- actions ;
+- responsable ;
+- date de cloture.
+
+## Revue post-incident
+
+Pour les incidents critiques :
+
+- analyse cause racine ;
+- impacts reels ;
+- delais de reaction ;
+- mesures preventives.
+
+Conservation cible du rapport : 3 ans minimum.

docs/compliance/SEC-005-registre-fournisseurs-et-sous-traitants.md

@@ -0,0 +1,90 @@
+# SEC-005 - Registre des fournisseurs et sous-traitants
+
+Reference : SEC-005  
+Version : 1.0  
+Proprietaire : DPO / RSSI
+
+## Objectif
+
+Identifier, evaluer et controler l'ensemble des prestataires, fournisseurs et sous-traitants ayant acces aux donnees ou participant au fonctionnement du Portail Associations 973.
+
+## Registre des fournisseurs
+
+| Fournisseur | Service | Donnees concernees | Localisation | Contrat DPA | Criticite | Revision annuelle |
+| --- | --- | --- | --- | --- | --- | --- |
+| Hebergeur principal | Hebergement plateforme | Toutes donnees | UE | Oui | Critique | Oui |
+| SMTP / Email | Envoi notifications | Email, nom | UE | Oui | Elevee | Oui |
+| Sauvegarde cloud | Sauvegardes chiffrees | Donnees applicatives | UE | Oui | Critique | Oui |
+| Analytics | Statistiques | Donnees pseudonymisees | UE | Oui | Moyenne | Oui |
+| Paiement (si applicable) | Transactions | Donnees de paiement | UE | Oui | Critique | Oui |
+
+## Criteres d'evaluation fournisseur
+
+### Securite
+
+- certification ISO 27001 ou equivalent ;
+- hebergement europeen ;
+- chiffrement des donnees ;
+- journalisation ;
+- politique de sauvegarde ;
+
+### Conformite
+
+- RGPD ;
+- DPA signe ;
+- gestion des violations de donnees ;
+- localisation des traitements ;
+
+### Continuite
+
+- disponibilite SLA ;
+- PCA / PRA ;
+- support technique ;
+- historique incidents.
+
+## Classification des fournisseurs
+
+### Critique
+
+Impact direct sur :
+
+- disponibilite de la plateforme ;
+- securite des donnees ;
+- integrite des services.
+
+Exemples :
+
+- hebergeur ;
+- base de donnees ;
+- sauvegarde.
+
+### Elevee
+
+Impact important sur le fonctionnement.
+
+Exemples :
+
+- SMTP ;
+- authentification ;
+- stockage documentaire.
+
+### Moyenne
+
+Impact limite.
+
+Exemples :
+
+- statistiques ;
+- monitoring.
+
+## Exigences de gestion
+
+- chaque fournisseur doit etre identifie nominativement ;
+- chaque contrat ou abonnement doit etre rattache a un responsable interne ;
+- la disponibilite d'un DPA doit etre verifiee ;
+- une revue annuelle doit confirmer :
+  - localisation ;
+  - securite ;
+  - conformite ;
+  - incidents significatifs ;
+  - maintien ou remplacement.

docs/compliance/association-directory-official-enrichment.md

@@ -0,0 +1,197 @@
+# Enrichissement officiel du bordereau d'associations
+
+## Objectif
+
+Le bordereau interne reste la source de verite.
+
+Les API externes servent uniquement a :
+
+- rechercher des mises a jour probables ;
+- comparer les informations officielles a la fiche existante ;
+- proposer des enrichissements a validation humaine.
+
+Le systeme ne doit jamais creer automatiquement une nouvelle association depuis une API externe.
+
+## Regles fonctionnelles
+
+### 1. Aucune creation automatique
+
+- une API ne peut pas inserer une nouvelle fiche dans le bordereau ;
+- seules les fiches deja presentes dans le referentiel peuvent etre enrichies ;
+- si aucune correspondance fiable n'est trouvee, aucune mise a jour n'est appliquee.
+
+### 2. Validation manuelle obligatoire
+
+- aucune donnee officielle n'est ecrite directement dans la fiche ;
+- l'admin doit toujours voir une proposition avant application ;
+- l'admin peut :
+  - valider et appliquer ;
+  - ignorer ;
+  - relancer une recherche plus tard.
+
+### 3. Bordereau = source de verite
+
+- l'annuaire public n'affiche que les donnees validees ;
+- les donnees brutes API ne sont jamais publiees directement ;
+- toute proposition doit rester tracable.
+
+## Sources actuellement exploitables
+
+### Recherche Entreprises / Sirene public
+
+Source :
+
+- `https://recherche-entreprises.api.gouv.fr/search`
+
+Usage :
+
+- recherche par nom ;
+- verification SIREN/SIRET ;
+- adresse du siege ;
+- commune ;
+- etat administratif ;
+- identifiant association si disponible.
+
+Cette source fonctionne sans workflow d'email ou validation manuelle externe.
+
+### DJEPVA / Entreprise API
+
+Source :
+
+- `https://entreprise.api.gouv.fr`
+
+Usage :
+
+- RNA ;
+- SIRET siege ;
+- statut actif/inactif ;
+- date de creation ;
+- objet ;
+- adresse ;
+- forme juridique.
+
+Condition :
+
+- necessite `ENTREPRISE_API_TOKEN`.
+
+Si le token est absent, le systeme continue de fonctionner avec la recherche publique.
+
+### HelloAsso
+
+Usage :
+
+- logo ;
+- description publique ;
+- signaux de presence publique.
+
+Regle :
+
+- aucune creation automatique ;
+- enrichissement ou proposition uniquement apres rapprochement.
+
+## Workflow admin attendu
+
+### Bouton de travail
+
+Dans l'admin, le bouton principal est :
+
+- `Rechercher des mises a jour`
+
+Il peut etre utilise :
+
+- sur une fiche du bordereau ;
+- sur une vue filtree du referentiel.
+
+### Resultat
+
+Le systeme :
+
+1. charge la fiche existante du bordereau ;
+2. interroge les sources accessibles ;
+3. compare les champs ;
+4. construit une proposition d'enrichissement ;
+5. stocke cette proposition en statut `pending`.
+
+### Validation humaine
+
+L'admin voit ensuite :
+
+- le resume de la proposition ;
+- la source ;
+- la liste des differences `Actuel / Propose`.
+
+Puis il choisit :
+
+- `Valider et appliquer`
+- `Ignorer`
+
+## Champs actuellement compares
+
+Les propositions couvrent en priorite :
+
+- RNA ;
+- SIRET ;
+- statut de l'association ;
+- date de creation ;
+- adresse ;
+- code postal ;
+- ville ;
+- statut juridique ;
+- objet de l'association.
+
+## Architecture
+
+### Table de propositions
+
+Une table dediee stocke les enrichissements proposes :
+
+- `associationDirectoryUpdateProposals`
+
+Statuts :
+
+- `pending`
+- `applied`
+- `dismissed`
+
+### Rendu admin
+
+Le module admin :
+
+- ne pousse plus directement les donnees officielles dans la fiche ;
+- affiche une carte de proposition explicite ;
+- conserve un workflow de validation metier.
+
+## Ce qui est automatique aujourd'hui
+
+- recherche des sources officielles ;
+- calcul des differences ;
+- creation ou mise a jour d'une proposition en attente ;
+- scan par fiche ;
+- scan par vue filtree.
+
+## Ce qui reste volontairement manuel
+
+- application finale sur la fiche ;
+- refus d'une proposition ;
+- arbitrage en cas de doute ;
+- futur enrichissement avec API protegees par compte, mail ou autorisation supplementaire.
+
+## Etapes suivantes recommandees
+
+### Phase 2
+
+- brancher les logos HelloAsso dans le meme schema de proposition ;
+- ajouter un filtre admin `Propositions officielles en attente` ;
+- afficher des compteurs par statut.
+
+### Phase 3
+
+- ajouter RNA / DINUM / DJEPVA complets selon les acces reels ;
+- enrichir le score de confiance ;
+- proposer des rapprochements plus fins sur dirigeants, email et telephone.
+
+### Phase 4
+
+- historiser visuellement les enrichissements acceptes ;
+- permettre une revue periodique du referentiel ;
+- produire des rapports de mise a jour pour le pilotage.

docs/facturation/projet-facture-ccds-portail-association973-mars-juin-2026.md

@@ -0,0 +1,179 @@
+# Projet de facture - CCDS
+
+Date d'emission: 21/06/2026  
+Periode couverte: mars 2026 a juin 2026  
+Objet: conception, developpement, optimisation, deploiement et exploitation de la plateforme `portail-association973.com`
+
+## 1. Position honnete et recommandee
+
+Pour que la facture soit defendable devant la CCDS, la DSI, la comptabilite ou un elu:
+
+- les **prestations de travail** doivent etre facturees clairement, par grands lots fonctionnels ;
+- les **frais OVH** doivent idealement etre **refactures sur justificatifs** avec leur montant reel ;
+- le **MacBook Pro M5 Pro a 2 400 EUR** ne devrait **pas etre facture en achat integral** sauf accord explicite prealable de la CCDS.
+
+La version la plus propre est donc:
+
+1. **facturer le travail realise en forfait mission** ;
+2. **ajouter les frais OVH reels** sur la periode mars-juin 2026 ;
+3. **ne pas inclure le MacBook en achat complet** dans la facture principale.
+
+Si tu veux malgre tout faire apparaitre le MacBook, la version la plus defendable est de le traiter:
+
+- soit en **quote-part d'equipement / outillage dedie a la mission** ;
+- soit dans une **annexe ou note de frais separee** ;
+- mais **pas comme une ligne materiel brute de 2 400 EUR** sans cadre contractuel.
+
+---
+
+## 2. Version recommandee a adresser a la CCDS
+
+### EMETTEUR
+
+**[Ton nom / raison sociale]**  
+**[Adresse]**  
+**[Code postal - Ville]**  
+**SIRET:** [a completer]  
+**Email:** [a completer]  
+**Telephone:** [a completer]  
+
+### CLIENT
+
+**Communaute de Communes Des Savanes (CCDS)**  
+**[Adresse administrative exacte a completer]**  
+**97310 Kourou**  
+
+### FACTURE
+
+- **Numero de facture:** FA-2026-CCDS-PA973-01
+- **Date:** 21/06/2026
+- **Periode d'execution:** du 01/03/2026 au 21/06/2026
+- **Echeance de paiement:** 30 jours
+
+---
+
+## 3. Detail des prestations
+
+| Ligne | Description | Montant HT |
+|---|---|---:|
+| 1 | Conception fonctionnelle et architecture du portail `portail-association973.com` | 3 800,00 EUR |
+| 2 | Developpement du socle applicatif, authentification, espaces publics et espaces connectes association | 4 200,00 EUR |
+| 3 | Developpement et optimisation des formulaires metier, documents, demandes, reservations et parcours association | 3 900,00 EUR |
+| 4 | Developpement et harmonisation de l'administration: bordereau, logistique, referentiels, conformite, audit et pilotage | 4 600,00 EUR |
+| 5 | Optimisation UX/UI multi-appareils, responsive, densite, navigation, finitions visuelles et coherence globale | 2 800,00 EUR |
+| 6 | Cartographie, styles, integration MapLibre/OpenMapTiles, optimisation de l'experience terrain et des vues admin/publiques | 1 900,00 EUR |
+| 7 | Deploiement, supervision, correctifs de production/preproduction, stabilisation VPS et accompagnement technique | 1 300,00 EUR |
+
+### Sous-total prestations HT
+
+**22 500,00 EUR HT**
+
+---
+
+## 4. Frais techniques et hebergement
+
+### Frais OVH
+
+Les frais OVH doivent etre repris **d'apres les factures reelles**.
+
+| Ligne | Description | Montant HT |
+|---|---|---:|
+| 8 | Hebergement OVH / VPS / services techniques mars a juin 2026 | **[montant OVH reel a reporter]** |
+
+> Recommandation: joindre les factures OVH en annexe et mentionner "refacturation sur justificatifs".
+
+---
+
+## 5. Total facture - version recommandee
+
+### Si tu es en franchise en base de TVA
+
+Mention:
+
+**TVA non applicable, article 293 B du CGI**
+
+Dans ce cas:
+
+- **Total prestations:** 22 500,00 EUR
+- **Frais OVH:** [montant OVH reel]
+- **Total net a payer:** **22 500,00 EUR + frais OVH reels**
+
+### Si tu factures avec TVA
+
+Dans ce cas:
+
+- **Sous-total HT:** 22 500,00 EUR + frais OVH reels
+- **TVA:** [a calculer selon ton regime]
+- **Total TTC:** [a completer]
+
+---
+
+## 6. Formulation d'objet conseillee
+
+**Prestations de conception, developpement, optimisation UX/UI, administration, cartographie, deploiement et pilotage technique de la plateforme Portail Associations 973, realisees de mars a juin 2026, avec refacturation des frais d'hebergement OVH sur justificatifs.**
+
+---
+
+## 7. Version alternative si tu veux absolument faire apparaitre le MacBook
+
+### Important
+
+Cette version est **moins solide** si la CCDS n'a pas valide au prealable l'achat du materiel.
+
+La bonne formulation n'est pas:
+
+- "Achat MacBook Pro M5 Pro: 2 400 EUR"
+
+La formulation plus defendable serait:
+
+| Ligne | Description | Montant HT |
+|---|---|---:|
+| 9 | Quote-part d'equipement et outillage dedie a la mission (poste de travail, tests, environnement de developpement) | 400,00 EUR a 800,00 EUR |
+
+### Variante non recommandee mais possible si accord explicite de la CCDS
+
+| Ligne | Description | Montant HT |
+|---|---|---:|
+| 9 | Acquisition d'un poste de travail dedie au projet (MacBook Pro M5 Pro) | 2 400,00 EUR |
+
+> A n'utiliser que si tu as un accord clair, ecrit ou oralement actable, sinon cette ligne peut etre contestee.
+
+---
+
+## 8. Recommandation finale
+
+La version la plus honnete et la plus professionnelle a envoyer est:
+
+- **Prestations:** 22 500,00 EUR HT
+- **OVH:** montant reel sur justificatifs
+- **MacBook:** non inclus dans la facture principale
+
+Si tu veux une version un peu plus prudente politiquement, tu peux aussi descendre le forfait principal a:
+
+- **19 500,00 EUR HT** + OVH reel
+
+Si tu veux une version plus offensive mais encore defendable vu l'ampleur du travail:
+
+- **24 000,00 EUR HT** + OVH reel
+
+---
+
+## 9. Texte pret a coller sur la facture
+
+**Facturation des prestations realisees sur la plateforme Portail Associations 973 de mars a juin 2026: cadrage, conception, developpement, administration, logistique, bordereau, conformite, optimisation UX/UI multi-appareils, cartographie, deploiement, stabilisation et accompagnement technique. Refacturation des frais d'hebergement OVH sur justificatifs.**
+
+---
+
+## 10. Ce qu'il manque pour en faire une vraie facture definitive
+
+Avant envoi, il faut encore completer:
+
+- ton **nom / raison sociale**
+- ton **adresse**
+- ton **SIRET**
+- ton **regime TVA**
+- l'**adresse exacte de la CCDS**
+- le **montant exact OVH** sur mars-juin 2026
+- le **numero de facture**
+- tes **coordonnees bancaires / RIB**
+

docs/openmaptiles-autonome-premium.md

@@ -0,0 +1,227 @@
+# Cartographie autonome premium avec OpenMapTiles
+
+Ce guide formalise le socle cartographique auto-heberge du portail pour obtenir une carte :
+
+- rapide
+- lisible
+- premium
+- autonome
+- exploitable dans le public comme dans l'admin
+
+## Architecture retenue
+
+Le portail repose sur trois briques distinctes :
+
+1. `OpenMapTiles Server` sur le VPS pour servir :
+   - le `TileJSON`
+   - les tuiles vectorielles `.pbf`
+   - les glyphes
+   - les sprites
+   - le style serveur de base `OSM OpenMapTiles`
+2. `MapLibre` dans le portail pour afficher la carte dans les vues publiques et admin
+3. `Maputnik` pour personnaliser les styles JSON sans casser le serveur de tuiles
+
+## Emplacements actuels sur le VPS
+
+- application prod : `/home/ubuntu/portail-associations`
+- application preprod : `/home/ubuntu/portail-associations-preprod`
+- serveur OpenMapTiles : `/home/ubuntu/openmaptiles-guyane`
+
+Conteneur constate :
+
+- `openmaptiles-guyane-tileserver-gl-1`
+
+## URLs utiles
+
+### Style serveur de base
+
+- [OSM OpenMapTiles](https://www.portail-association973.com/map-tiles/styles/OSM%20OpenMapTiles/style.json)
+
+### Sources auto-hebergees
+
+- [TileJSON](https://www.portail-association973.com/data/openmaptiles.json)
+- glyphes : `https://www.portail-association973.com/fonts/{fontstack}/{range}.pbf`
+- sprites serveur : `https://www.portail-association973.com/styles/OSM%20OpenMapTiles/sprite`
+
+### Styles portail
+
+- [OSM Bright CCDS](https://www.portail-association973.com/map-styles/openmaptiles-positron/style.json)
+- [OSM Bright CCDS Admin Dense](https://www.portail-association973.com/map-styles/openmaptiles-positron-admin/style.json)
+- `OSM Basic auto-heberge` = style serveur OpenMapTiles
+
+## Contraintes utiles a garder
+
+Pour rester stable en exploitation comme en local :
+
+- le style portail `OSM Bright CCDS` doit utiliser un `sprite` absolu
+- les `glyphs` doivent pointer vers `https://www.portail-association973.com/fonts/{fontstack}/{range}.pbf`
+- les piles de polices doivent rester compatibles avec ce que sert vraiment OpenMapTiles
+
+Piles recommandees :
+
+- texte courant carte : `Noto Sans Regular`
+- italique carte : `Noto Sans Italic`
+- compteurs / clusters : `Open Sans Bold`
+
+Eviter :
+
+- `Metropolis *`
+- `Arial Unicode MS Bold`
+- les piles de plusieurs polices non supportees par le serveur de glyphes
+
+## Ordre d'execution recommande
+
+1. verifier le serveur OpenMapTiles
+2. verifier ou regnerer les tuiles Guyane
+3. activer le style cible dans l'admin
+4. ajuster le rendu avec Maputnik
+5. verifier la carte publique et la carte admin
+6. affiner ensuite l'ambiance premium dans Apparence
+
+## 1. Verifier le serveur OpenMapTiles
+
+Depuis le poste local :
+
+```bash
+./scripts/check-openmaptiles-vps.sh
+```
+
+Ce script controle :
+
+- le conteneur Docker
+- le style JSON serveur
+- le TileJSON
+- les glyphes
+
+### Healthcheck recommande
+
+Le conteneur `tileserver-gl` peut rester `unhealthy` si son healthcheck interne vise encore `localhost:8080/health` alors que le serveur tourne sur un autre port expose par la stack, par exemple `8091`.
+
+Le healthcheck doit donc viser le port effectif :
+
+```yaml
+healthcheck:
+  test:
+    [
+      "CMD-SHELL",
+      "node -e \"require('http').get('http://localhost:${TPORT:-8080}/health',res=>process.exit(res.statusCode===200?0:1)).on('error',()=>process.exit(1))\"",
+    ]
+  interval: 30s
+  timeout: 5s
+  retries: 5
+  start_period: 20s
+```
+
+## 2. Generer ou reutiliser les tuiles Guyane
+
+Le depot serveur utilise deja le projet OpenMapTiles officiel dans :
+
+`/home/ubuntu/openmaptiles-guyane`
+
+### Relancer le serveur de tuiles
+
+```bash
+ssh ovh-vps 'cd /home/ubuntu/openmaptiles-guyane && docker compose up -d tileserver-gl'
+```
+
+### Ouvrir Maputnik
+
+```bash
+ssh ovh-vps 'cd /home/ubuntu/openmaptiles-guyane && docker compose up -d maputnik_editor'
+```
+
+Maputnik sera ensuite accessible sur le port expose par le serveur si un proxy ou un tunnel SSH est mis en place.
+
+### Regenerer les tuiles
+
+Commande lourde, a lancer seulement si besoin de regenerer la base :
+
+```bash
+ssh ovh-vps 'cd /home/ubuntu/openmaptiles-guyane && docker compose run --rm generate-vectortiles'
+```
+
+## 3. Activer un style dans le portail
+
+Dans `Administration > Référentiel associations > Carte OpenStreetMap / MapLibre`, utiliser l'un des presets :
+
+- `OSM Bright auto-heberge` : rendu clair premium, lisible pour l'annuaire
+- `OSM Basic auto-heberge` : style serveur brut, plus neutre
+
+## 4. Personnaliser avec Maputnik
+
+Le flux recommande est :
+
+1. partir du style `openmaptiles-positron`
+2. l'ouvrir dans Maputnik
+3. ajuster :
+   - couleurs d'eau
+   - verts
+   - routes
+   - contrastes
+   - labels
+4. reexporter le `style.json`
+5. remplacer le fichier du portail :
+
+`client/public/map-styles/openmaptiles-positron/style.json`
+
+Le style portail doit toujours pointer vers :
+
+- `https://www.portail-association973.com/data/openmaptiles.json`
+- `https://www.portail-association973.com/fonts/{fontstack}/{range}.pbf`
+
+### Direction visuelle premium retenue
+
+Pour la Guyane, la passe visuelle vise un rendu plus institutionnel et plus territorial :
+
+- fond general plus chaud et plus respirant
+- eau plus lisible, avec fleuves et criques mieux marques
+- vegetation plus douce, sans saturer la carte
+- zones urbanisees legerement rechauffees pour mieux separer le bati du fond
+- routes principales plus visibles avec une hierarchie creme / sable / ocre
+- labels de communes et repères plus contrastes, avec halos plus propres pour le mobile
+
+Objectif UX :
+
+- lecture immediate des communes et des axes utiles
+- rendu plus premium, sans basculer dans une carte decorative
+- coherence avec le portail, ses cards et ses panneaux
+
+### Variante admin dense
+
+Une variante plus sobre est aussi disponible pour le pilotage :
+
+- labels legerement plus petits
+- hierarchie de communes plus resserree
+- routes et repères plus discrets
+- lecture plus compacte pour les vues admin denses
+
+## 5. Ambiance premium dans le portail
+
+Le fond immersif et l'opacite doivent rester dans le portail, pas dans le style cartographique lui-meme.
+
+Bonne pratique :
+
+- la carte reste nette et lisible
+- les panneaux et cards restent opaques
+- l'ambiance premium se gere via `Apparence`
+
+## 6. Validation finale
+
+Verifier au minimum :
+
+- carte publique
+- annuaire public
+- carte admin
+- filtres
+- popups
+- mobile
+- desktop
+
+## Decision retenue
+
+Le portail garde deux niveaux propres :
+
+- `Fond de carte` : OpenMapTiles + style MapLibre
+- `Ambiance premium` : Apparence + fond + opacite + habillage du portail
+
+Cela evite de melanger le rendu cartographique metier avec le rendu decoratif global.

docs/runtime-health-maintenance.md

@@ -0,0 +1,127 @@
+# Runtime health, maintenance et redemarrage propre
+
+Ce document formalise la passe d'exploitation qui evite les redemarrages "a l'aveugle" et structure les verifications.
+
+## Endpoints
+
+- `GET /health/live`
+  - confirme que le processus Express est vivant
+  - retourne `503` uniquement pendant l'arret en douceur
+- `GET /health/ready`
+  - confirme que l'application est vraiment exploitable
+  - verifie :
+    - fin du delai de demarrage
+    - etat runtime pret
+    - base disponible si configuree
+    - absence d'arret en cours
+- `GET /health`
+  - alias pratique vers `GET /health/ready`
+
+## Mode maintenance
+
+Le mode maintenance repose sur un drapeau fichier persistant :
+
+- chemin par defaut : `/app/uploads/system/maintenance.flag`
+
+Quand le drapeau existe :
+
+- les pages HTML publiques et internes renvoient une page legere de maintenance
+- les endpoints `/health*`, `/api*` et `/uploads/*` restent accessibles
+
+### Commandes utiles
+
+Depuis le projet :
+
+```bash
+./scripts/maintenance-flag.sh on
+./scripts/maintenance-flag.sh off
+./scripts/maintenance-flag.sh status
+```
+
+Sur le VPS :
+
+```bash
+ssh ovh-vps 'cd /home/ubuntu/portail-associations && MAINTENANCE_FLAG_PATH=/home/ubuntu/portail-associations/uploads/system/maintenance.flag ./scripts/maintenance-flag.sh on'
+```
+
+## Deploiement propre
+
+Le script officiel :
+
+```bash
+./scripts/deploy-vps.sh preprod
+./scripts/deploy-vps.sh prod
+```
+
+Verifie maintenant :
+
+1. le SSH
+2. le check TypeScript
+3. le build local
+4. la synchro
+5. le redeploiement Docker
+6. le retour `200` sur `/health/ready`
+7. le retour `200` sur la home
+
+### Option maintenance
+
+Pour entourer le deploiement d'une page de maintenance :
+
+```bash
+USE_MAINTENANCE_FLAG=1 ./scripts/deploy-vps.sh prod
+```
+
+## Monitoring simple
+
+Verifier plusieurs fois un endpoint :
+
+```bash
+./scripts/monitor-http-health.sh https://www.portail-association973.com/health/ready
+```
+
+Le script remonte notamment les `502` et `503`.
+
+## Industrialisation CI/CD
+
+Le minimum utile pour la chaine de deploiement est :
+
+1. lancer `corepack pnpm check`
+2. lancer `corepack pnpm build`
+3. deployer
+4. attendre `GET /health/ready = 200`
+5. verifier la home
+6. lancer un mini monitoring post-deploiement sur 1 a 2 minutes
+
+Exemple de sequence :
+
+```bash
+./scripts/deploy-vps.sh preprod
+./scripts/monitor-http-health.sh https://preprod.portail-association973.com/health/ready
+```
+
+## Alerting simple
+
+Sans ajouter de grosse brique tout de suite, on peut deja alerter proprement si :
+
+- `/health/ready` ne revient pas en `200`
+- plus d'un `502` ou `503` apparait pendant la fenetre de verification
+- le mode maintenance reste actif par erreur
+
+La premiere etape rentable est de brancher ces controles dans la routine de deploiement ou dans un cron d'observation.
+
+## Limite honnete
+
+Avec un seul conteneur applicatif et une recreation Docker classique, le risque de micro-coupure n'est pas totalement elimine.
+
+Cette passe :
+
+- fiabilise la detection du "pret"
+- ajoute un arret plus propre
+- structure la maintenance
+- rend les controles repetables
+
+Pour viser le zero `502` strict, il faudra ensuite une architecture de bascule plus poussee :
+
+- blue/green
+- double instance applicative
+- ou proxy avec vraie page de maintenance en amont.

docs/ux/PORTAL-SKILLS-SYSTEM.md

@@ -0,0 +1,400 @@
+# Skills portail - integration utile sans surcouche
+
+## Intention
+
+Le portail dispose deja d'un socle UX et metier solide.  
+L'objectif n'est donc pas d'injecter artificiellement une nouvelle couche de "skills", mais de :
+
+- capitaliser sur les briques deja presentes ;
+- renforcer les zones qui apportent un vrai gain utilisateur ;
+- eviter les dependances ou abstractions inutiles ;
+- garder un portail fluide, lisible et robuste.
+
+En pratique, un "skill" correspond ici a un **bloc de capacite reutilisable** :
+
+- regle de layout ;
+- logique UX ;
+- moteur de donnees ;
+- comportement mobile ;
+- outil d'efficacite admin ;
+- aide a l'autonomie association.
+
+## Principe de pilotage
+
+Avant d'ajouter un nouveau skill, verifier :
+
+1. si le portail a deja une brique equivalente ;
+2. si cette brique peut etre etendue proprement ;
+3. si le gain UX ou metier est concret ;
+4. si l'ajout ne degrade pas la performance ou la lisibilite.
+
+## Lecture par priorite
+
+### Priorite 1 - Skills structurels
+
+Ces skills sont deja largement presents et doivent rester la base unique.
+
+#### Responsive Engine
+
+Etat :
+
+- deja present
+
+Points d'appui :
+
+- [client/src/hooks/useMobile.tsx](/Users/selecta/Documents/portail-associations/client/src/hooks/useMobile.tsx)
+- [client/src/components/DashboardLayout.tsx](/Users/selecta/Documents/portail-associations/client/src/components/DashboardLayout.tsx)
+- [client/src/index.css](/Users/selecta/Documents/portail-associations/client/src/index.css)
+
+Role :
+
+- detection mobile / tablette / desktop ;
+- adaptation sidebar / densite / structure ;
+- reduction des regressions multi-appareils.
+
+#### UI Kit Global
+
+Etat :
+
+- deja present
+
+Points d'appui :
+
+- [client/src/components/ui](/Users/selecta/Documents/portail-associations/client/src/components/ui)
+- [client/src/components/portal/PortalSurface.tsx](/Users/selecta/Documents/portail-associations/client/src/components/portal/PortalSurface.tsx)
+
+Role :
+
+- boutons, badges, cartes, dialogues, tables, panneaux ;
+- langage visuel commun entre public, association et admin.
+
+#### Layout Manager
+
+Etat :
+
+- deja present
+
+Points d'appui :
+
+- [client/src/components/DashboardLayout.tsx](/Users/selecta/Documents/portail-associations/client/src/components/DashboardLayout.tsx)
+- [client/src/components/portal/PortalSurface.tsx](/Users/selecta/Documents/portail-associations/client/src/components/portal/PortalSurface.tsx)
+
+Role :
+
+- structure stable ;
+- alignements ;
+- marges ;
+- paddings ;
+- hierarchie des surfaces.
+
+#### Typography System
+
+Etat :
+
+- deja present et relie au module Apparence
+
+Points d'appui :
+
+- [shared/appearance.ts](/Users/selecta/Documents/portail-associations/shared/appearance.ts)
+- [client/src/lib/appearance.ts](/Users/selecta/Documents/portail-associations/client/src/lib/appearance.ts)
+- [client/src/index.css](/Users/selecta/Documents/portail-associations/client/src/index.css)
+
+Role :
+
+- famille de police ;
+- echelle des titres ;
+- lisibilite globale ;
+- personnalisation sans casser la coherence.
+
+### Priorite 2 - Skills UX
+
+#### Smooth Navigation
+
+Etat :
+
+- partiellement present, renforce dans ce tour
+
+Points d'appui :
+
+- [client/src/components/DashboardLayout.tsx](/Users/selecta/Documents/portail-associations/client/src/components/DashboardLayout.tsx)
+- [client/src/pages/Home.tsx](/Users/selecta/Documents/portail-associations/client/src/pages/Home.tsx)
+- [client/src/lib/routePrefetch.ts](/Users/selecta/Documents/portail-associations/client/src/lib/routePrefetch.ts)
+
+Role :
+
+- navigation plus immediate ;
+- prechargement des vues clefs au survol, au focus et au toucher ;
+- reduction de la sensation d'attente entre clic et affichage.
+
+#### Panel Interaction
+
+Etat :
+
+- deja present
+
+Points d'appui :
+
+- composants `Dialog`, `Sheet`, `DropdownMenu`, `Sidebar`
+- regroupements d'actions secondaires deja poses sur plusieurs vues
+
+Role :
+
+- ouverture/fermeture propre ;
+- actions secondaires discretes ;
+- meilleure densite operationnelle.
+
+#### List Enhancer
+
+Etat :
+
+- present par endroits, a propager selon besoin
+
+Points d'appui :
+
+- filtres et vues admin ;
+- densite compacte / detaillee ;
+- recherche sur annuaire et bordereau.
+
+Role :
+
+- tri ;
+- recherche ;
+- pagination ;
+- lecture dense mais lisible.
+
+#### Action Visibility
+
+Etat :
+
+- deja present sur les zones prioritaires
+
+Role :
+
+- mettre en avant valider / ignorer / appliquer / ouvrir ;
+- reduire le bruit visuel ;
+- garder une action principale claire.
+
+### Priorite 3 - Skills Data
+
+#### Matching Engine
+
+Etat :
+
+- deja present
+
+Points d'appui :
+
+- [server/associationDirectoryMatcher.ts](/Users/selecta/Documents/portail-associations/server/associationDirectoryMatcher.ts)
+- [server/routers.ts](/Users/selecta/Documents/portail-associations/server/routers.ts)
+
+Role :
+
+- detection des correspondances ;
+- rapprochement portail / bordereau ;
+- reduction des doublons.
+
+#### Fusion Engine
+
+Etat :
+
+- present en logique de validation, a etendre si besoin
+
+Role :
+
+- fusion propre ;
+- arbitrage humain ;
+- tracabilite.
+
+#### Data Validation
+
+Etat :
+
+- deja largement present
+
+Points d'appui :
+
+- normalisations dans `server/associationDirectory.ts`
+- validations schema Zod dans `server/routers.ts`
+- helpers partages `shared/*`
+
+#### API Connector (RNA / SIRENE / HelloAsso)
+
+Etat :
+
+- present et renforce
+
+Points d'appui :
+
+- [server/associationReferenceSync.ts](/Users/selecta/Documents/portail-associations/server/associationReferenceSync.ts)
+- [docs/compliance/association-directory-official-enrichment.md](/Users/selecta/Documents/portail-associations/docs/compliance/association-directory-official-enrichment.md)
+
+Role :
+
+- enrichissement controle ;
+- aucune creation automatique ;
+- validation admin obligatoire.
+
+### Priorite 4 - Skills Mobile
+
+#### Mobile Scroll
+
+Etat :
+
+- renforce
+
+Points d'appui :
+
+- [client/src/index.css](/Users/selecta/Documents/portail-associations/client/src/index.css)
+- [client/src/lib/appearance.ts](/Users/selecta/Documents/portail-associations/client/src/lib/appearance.ts)
+
+Role :
+
+- limiter les couches couteuses pendant le scroll ;
+- garder les fonds immersifs sans penaliser la fluidite.
+
+#### Lazy Loading
+
+Etat :
+
+- deja present sur les routes et certaines cartes
+
+Points d'appui :
+
+- `lazy(...)` dans [client/src/App.tsx](/Users/selecta/Documents/portail-associations/client/src/App.tsx)
+
+#### Prefetch Engine
+
+Etat :
+
+- ajoute dans ce tour
+
+Points d'appui :
+
+- [client/src/lib/routePrefetch.ts](/Users/selecta/Documents/portail-associations/client/src/lib/routePrefetch.ts)
+
+Role :
+
+- precharger les vues les plus frequentes ;
+- accelerer la navigation percue ;
+- ne rien casser dans le routeur existant.
+
+#### Touch Gestures
+
+Etat :
+
+- a traiter seulement si un vrai besoin apparait
+
+Decision UX :
+
+- ne pas ajouter de gestuelle complexe par defaut ;
+- privilegier une ergonomie simple avant les gestures.
+
+### Priorite 5 - Skills Admin
+
+#### Admin Dashboard
+
+Etat :
+
+- deja present
+
+#### Correspondence Manager
+
+Etat :
+
+- deja present et enrichi
+
+Role :
+
+- correspondances a valider ;
+- propositions officielles ;
+- workflow de decision humain.
+
+#### Notification Engine
+
+Etat :
+
+- deja present
+
+Role :
+
+- alertes ;
+- badges ;
+- suivi des dossiers prioritaires.
+
+### Priorite 6 - Skills Association
+
+#### Association Portal
+
+Etat :
+
+- deja present et fortement harmonise
+
+#### Reservation Flow
+
+Etat :
+
+- deja present
+
+#### Document Center
+
+Etat :
+
+- deja present
+
+## Ce qui a ete ajoute dans ce tour
+
+### 1. Prefetch discret des routes clefs
+
+Ajout du fichier :
+
+- [client/src/lib/routePrefetch.ts](/Users/selecta/Documents/portail-associations/client/src/lib/routePrefetch.ts)
+
+Et branchement sur :
+
+- la sidebar dashboard/admin ;
+- la navigation et les CTA principaux de l'accueil.
+
+Impact attendu :
+
+- navigation plus fluide ;
+- sensation de site plus reactif ;
+- zero changement de logique metier.
+
+### 2. Clarification strategique
+
+On ne traite pas les skills comme des plugins externes a injecter partout.
+
+On les traite comme :
+
+- des capacites internes ;
+- deja presentes ou utiles ;
+- propageres seulement quand elles ont un vrai impact.
+
+## Recommandation UX
+
+Le bon ordre reste :
+
+1. structurel ;
+2. UX ;
+3. data ;
+4. mobile ;
+5. admin ;
+6. association.
+
+Mais dans le code, cela doit se traduire par :
+
+- extension des briques existantes ;
+- pas de sur-abstraction ;
+- pas de moteur supplementaire si la base actuelle couvre deja le besoin.
+
+## Regle de prudence
+
+Un skill n'est utile que s'il rend le portail :
+
+- plus stable ;
+- plus fluide ;
+- plus lisible ;
+- plus simple a administrer ;
+- plus confortable pour l'association.
+
+Sinon, c'est du superflu.

docs/ux/ROADMAP-OPTIMISATION-PORTAIL.md

@@ -0,0 +1,474 @@
+# Roadmap UX - Navigation, Responsive et Cohérence Portail
+
+## Objectif
+
+Structurer l'optimisation UX du portail en tickets séparés, chacun dédié a une zone precise, afin d'obtenir une navigation stable, lisible et professionnelle sur ordinateur, tablette et telephone.
+
+Cette methode permet de :
+
+- traiter les ecrans par perimetre fonctionnel clair ;
+- limiter les regressions ;
+- verifier plus facilement les rendus desktop / tablette / mobile ;
+- deployer par lots plus maitrisables ;
+- obtenir un portail plus coherent pour les associations, les utilisateurs publics et les administrateurs.
+
+## Principes de pilotage
+
+Chaque ticket doit contenir :
+
+- le perimetre exact ;
+- le probleme constate ;
+- les objectifs UX ;
+- les contraintes multi-appareils ;
+- les composants ou vues touches ;
+- les criteres de validation ;
+- le resultat attendu.
+
+## Priorisation recommandee
+
+### Lot 1 - Navigation critique et ecrans les plus frequents
+
+1. `UX-001 - Home publique et menu mobile`
+2. `UX-002 - Navigation publique Annuaire / Carte / Aide`
+3. `UX-003 - Sidebar association et navigation dashboard`
+4. `UX-004 - Sidebar admin et navigation par onglets`
+
+### Lot 2 - Ecrans metier a forte frequence
+
+5. `UX-005 - Nouvelle demande`
+6. `UX-006 - Reservation de salle`
+7. `UX-007 - Materiel evenementiel`
+8. `UX-008 - Mes demandes`
+9. `UX-009 - Mon association`
+
+### Lot 3 - Ecrans admin de pilotage
+
+10. `UX-010 - Gestion des demandes admin`
+11. `UX-011 - Bordereau admin`
+12. `UX-012 - Annuaire CCDS`
+13. `UX-013 - Logistique / services materiel`
+14. `UX-014 - Conformite`
+
+### Lot 4 - Finition et qualite percue
+
+15. `UX-015 - Etats vides, skeletons et confirmations`
+16. `UX-016 - Densite compacte / detaillee`
+17. `UX-017 - Micro-interactions, hover, focus, transitions`
+18. `UX-018 - Revue finale multi-appareils`
+
+---
+
+## Tickets detailles
+
+### UX-001 - Home publique et menu mobile
+
+**Objectif**
+Stabiliser la premiere impression du portail sur mobile et petit desktop.
+
+**Perimetre**
+
+- header public ;
+- hero ;
+- navigation mobile ;
+- CTA principaux.
+
+**Travaux attendus**
+
+- rendre le menu mobile plus lisible et plus compact ;
+- mieux hierarchiser les CTA ;
+- ajuster finement les textes du hero selon la largeur ;
+- garantir un affichage sans debordement sur iPhone et petits Android.
+
+**Validation**
+
+- aucun debordement horizontal ;
+- CTA visibles sans confusion ;
+- navigation claire des l'arrivee sur le site.
+
+### UX-002 - Navigation publique Annuaire / Carte / Aide
+
+**Objectif**
+Assurer une navigation publique coherente entre les vues de consultation.
+
+**Perimetre**
+
+- annuaire public ;
+- carte publique ;
+- liens transverses publics.
+
+**Travaux attendus**
+
+- uniformiser les barres de navigation mobile ;
+- harmoniser les libelles ;
+- clarifier le passage carte / liste ;
+- rendre les filtres plus accessibles.
+
+**Validation**
+
+- meme logique de navigation entre annuaire et carte ;
+- comprehension immediate des vues disponibles.
+
+### UX-003 - Sidebar association et navigation dashboard
+
+**Objectif**
+Faire de la sidebar association un repere stable, intuitif et metier.
+
+**Perimetre**
+
+- sidebar utilisateur / association ;
+- sections de navigation ;
+- etat actif ;
+- version mobile repliee.
+
+**Travaux attendus**
+
+- consolider la hierarchie `Suivi / Demarches / Referentiels` ;
+- harmoniser les icones, espacements et libelles ;
+- garantir la persistance de la sidebar sur les pages du dashboard ;
+- gerer proprement le comportement mobile.
+
+**Validation**
+
+- la meme sidebar apparait de maniere coherente sur toutes les pages association ;
+- les actions principales sont reperables en un coup d'oeil.
+
+### UX-004 - Sidebar admin et navigation par onglets
+
+**Objectif**
+Stabiliser la navigation interne de l'administration.
+
+**Perimetre**
+
+- sidebar admin ;
+- navigation secondaire par onglets ;
+- badges notifications ;
+- etat actif.
+
+**Travaux attendus**
+
+- rendre chaque entree reellement cliquable ;
+- clarifier les groupes metier ;
+- renforcer la lisibilite des etats actifs ;
+- optimiser le comportement tablette / mobile.
+
+**Validation**
+
+- chaque clic change bien de vue ;
+- aucun conflit de navigation ou de cache visible.
+
+### UX-005 - Nouvelle demande
+
+**Objectif**
+Transformer l'entree en demande en parcours accompagne.
+
+**Perimetre**
+
+- page de choix des demandes ;
+- cartes d'entree ;
+- etats vides ;
+- CTA.
+
+**Travaux attendus**
+
+- clarifier les types de demandes ;
+- mieux presenter les priorites ;
+- renforcer le guidage visuel ;
+- optimiser l'affichage mobile.
+
+**Validation**
+
+- l'association comprend rapidement quelle demarche lancer ;
+- aucun bloc ne semble surcharge ou secondairement cache.
+
+### UX-006 - Reservation de salle
+
+**Objectif**
+Rendre le formulaire salle lisible, rassurant et fluide sur tous les supports.
+
+**Perimetre**
+
+- progression ;
+- sections du formulaire ;
+- recapitulatif ;
+- actions de validation.
+
+**Travaux attendus**
+
+- mieux segmenter les blocs ;
+- renforcer les retours de saisie ;
+- faciliter les actions tactiles ;
+- rendre le parcours plus premium sur mobile.
+
+**Validation**
+
+- lecture claire de chaque etape ;
+- aucune perte de contexte pendant la saisie.
+
+### UX-007 - Materiel evenementiel
+
+**Objectif**
+Aligner la qualite percue du materiel sur celle de la reservation de salle.
+
+**Perimetre**
+
+- formulaire materiel ;
+- recapitulatif ;
+- densite des informations ;
+- actions finales.
+
+**Travaux attendus**
+
+- clarifier les zones de saisie ;
+- optimiser la presentation du materiel demande ;
+- rendre les informations logistiques plus lisibles.
+
+**Validation**
+
+- l'ecran reste clair meme avec beaucoup d'informations.
+
+### UX-008 - Mes demandes
+
+**Objectif**
+Rendre le suivi des demandes plus clair et plus pilotable.
+
+**Perimetre**
+
+- liste des demandes ;
+- badges d'etat ;
+- actions `Voir`, `Repondre`, `Voir devis`, `Voir decision` ;
+- retour apres consultation.
+
+**Travaux attendus**
+
+- densifier sans tasser ;
+- clarifier les statuts ;
+- mieux hierarchiser les demandes a action.
+
+**Validation**
+
+- les demandes en attente sont immediatement identifiables ;
+- les documents se consultent sans rompre le parcours.
+
+### UX-009 - Mon association
+
+**Objectif**
+Securiser et fluidifier la mise a jour de la fiche association.
+
+**Perimetre**
+
+- formulaire de profil ;
+- systeme d'alerte avant sortie ;
+- sidebar ;
+- responsive fin.
+
+**Travaux attendus**
+
+- proteger les donnees non enregistrees ;
+- clarifier les champs incomplets ;
+- optimiser la lecture du formulaire sur mobile.
+
+**Validation**
+
+- aucun risque de perte silencieuse de donnees ;
+- fiche exploitable sur petit ecran.
+
+### UX-010 - Gestion des demandes admin
+
+**Objectif**
+Faire de la vue admin un poste de traitement lisible et efficace.
+
+**Perimetre**
+
+- listes ;
+- panneaux d'action ;
+- modales de traitement ;
+- formulaires longs.
+
+**Travaux attendus**
+
+- clarifier la densite ;
+- rendre les modales plus confortables sur mobile ;
+- mieux exposer les actions critiques.
+
+**Validation**
+
+- un agent peut traiter vite sans se perdre dans l'ecran.
+
+### UX-011 - Bordereau admin
+
+**Objectif**
+Faire du bordereau un veritable ecran metier de pilotage.
+
+**Perimetre**
+
+- grille desktop ;
+- referentiel ;
+- correspondances a valider ;
+- filtres ;
+- badges de provenance ;
+- mode compact / detaille.
+
+**Travaux attendus**
+
+- consolider la grille d'affichage ;
+- renforcer la lisibilite des fiches ;
+- mieux exposer les actions de rapprochement ;
+- rendre la toolbar de filtres plus premium.
+
+**Validation**
+
+- lecture immediate des statuts ;
+- ecran exploitable sur grand ecran sans collision visuelle.
+
+### UX-012 - Annuaire CCDS
+
+**Objectif**
+Uniformiser la qualite des referentiels internes.
+
+**Perimetre**
+
+- listes internes ;
+- fiches ;
+- edition ;
+- recherche.
+
+**Travaux attendus**
+
+- aligner les composants avec le bordereau ;
+- clarifier les actions d'edition ;
+- densifier proprement.
+
+### UX-013 - Logistique / services materiel
+
+**Objectif**
+Ameliorer le suivi metier des services internes.
+
+**Perimetre**
+
+- assignation ;
+- retour materiel ;
+- liens terrain ;
+- boutons retour.
+
+**Travaux attendus**
+
+- clarifier les statuts ;
+- rendre les actions plus visibles ;
+- fluidifier les retours vers la vue source.
+
+### UX-014 - Conformite
+
+**Objectif**
+Faire du centre conformite un veritable tableau de pilotage.
+
+**Perimetre**
+
+- syntheses ;
+- preuves ;
+- registres ;
+- DPA ;
+- sauvegardes ;
+- retention.
+
+**Travaux attendus**
+
+- clarifier les niveaux de lecture ;
+- mieux segmenter les preuves et registres ;
+- renforcer la lisibilite des priorites.
+
+### UX-015 - Etats vides, skeletons et confirmations
+
+**Objectif**
+Ameliorer la qualite percue sur tous les parcours.
+
+**Perimetre**
+
+- chargements ;
+- etats vides ;
+- messages de succes ;
+- messages d'erreur.
+
+**Travaux attendus**
+
+- uniformiser les skeletons ;
+- rendre les confirmations plus rassurantes ;
+- remplacer les messages trop techniques.
+
+### UX-016 - Densite compacte / detaillee
+
+**Objectif**
+Permettre un usage adapte au contexte : lecture confortable ou pilotage dense.
+
+**Perimetre**
+
+- bordereau ;
+- listes admin ;
+- listes association ;
+- referentiels.
+
+**Travaux attendus**
+
+- definir un mode compact ;
+- definir un mode detaille ;
+- garder une coherence de comportement entre modules.
+
+### UX-017 - Micro-interactions, hover, focus, transitions
+
+**Objectif**
+Rendre le portail plus premium sans tomber dans l'effet decoratif.
+
+**Perimetre**
+
+- boutons ;
+- cartes ;
+- filtres ;
+- changements d'onglets ;
+- panneaux.
+
+**Travaux attendus**
+
+- standardiser les transitions 150-250 ms ;
+- renforcer hover/focus ;
+- rendre les interactions plus nettes.
+
+### UX-018 - Revue finale multi-appareils
+
+**Objectif**
+Valider la coherence finale sur desktop, tablette et mobile.
+
+**Perimetre**
+
+- toutes les vues critiques ;
+- public ;
+- association ;
+- administration.
+
+**Travaux attendus**
+
+- controles visuels ;
+- corrections residuelles ;
+- verification de l'absence de debordements ;
+- validation des actions tactiles.
+
+## Ordre d'execution conseille
+
+1. Navigation globale
+2. Pages publiques principales
+3. Dashboard association
+4. Formulaires critiques
+5. Vues admin de traitement
+6. Bordereau et referentiels
+7. Conformite et ecrans secondaires
+8. Finitions globales
+9. Revue finale multi-appareils
+
+## Definition de "termine"
+
+Un ticket est considere termine quand :
+
+- le rendu desktop est propre et stable ;
+- le rendu tablette est coherent ;
+- le rendu mobile est lisible et sans debordement ;
+- les actions principales sont clairement visibles ;
+- les etats actifs, hover et focus sont nets ;
+- le comportement est verifie localement puis en ligne si necessaire.