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.