Soft-merge CCDS docs repository
git-subtree-dir: convergence/ccds-docs git-subtree-mainline: 03a8059fec332cefdfab496d02ebd6e9ffb39af7 git-subtree-split: e61f3dc5534db993a82a518c64505eeae432e75c
This commit is contained in:
parent
16964d6c79
commit
a8ec7fd113
28 changed files with 729 additions and 0 deletions
26
convergence/ccds-docs/.gitea/ISSUE_TEMPLATE/01-conformite.md
Normal file
26
convergence/ccds-docs/.gitea/ISSUE_TEMPLATE/01-conformite.md
Normal file
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
name: Conformite / gouvernance
|
||||
about: Demander une mise à jour documentaire, RGPD, ISO 27001 ou procédure
|
||||
title: "[Conformité] "
|
||||
labels: []
|
||||
assignees: []
|
||||
---
|
||||
|
||||
## Domaine
|
||||
|
||||
- RGPD
|
||||
- ISO 27001
|
||||
- procédure
|
||||
- gouvernance projet
|
||||
|
||||
## Document ou sujet concerné
|
||||
|
||||
## Attendu
|
||||
|
||||
## Preuve ou source disponible
|
||||
|
||||
## Critères de clôture
|
||||
|
||||
- [ ]
|
||||
- [ ]
|
||||
|
||||
31
convergence/ccds-docs/README.md
Normal file
31
convergence/ccds-docs/README.md
Normal file
|
|
@ -0,0 +1,31 @@
|
|||
# CCDS Docs
|
||||
|
||||
Base documentaire du projet `ccds`.
|
||||
|
||||
## Perimetre
|
||||
|
||||
- gouvernance projet
|
||||
- conformite RGPD
|
||||
- securite et hygiene d'exploitation
|
||||
- procedures metier et comptes rendus
|
||||
- tickets, feuilles de route et livrables
|
||||
|
||||
## Structure
|
||||
|
||||
- `rgpd/` : traitements, bases legales, privacy by design
|
||||
- `iso27001/` : mesures, preuves, controles
|
||||
- `procedures/` : exploitation, incidents, sauvegardes
|
||||
- `projet/` : vision produit, tickets, roadmaps
|
||||
- `comptes-rendus/` : validations, ateliers, revues
|
||||
|
||||
## Usage
|
||||
|
||||
Ce depot sert de reference stable pour les documents transverses, afin d'eviter de melanger la doc projet avec le code applicatif.
|
||||
|
||||
## Acces rapide
|
||||
|
||||
- [Index gouvernance projet](./projet/index-gouvernance-projet.md)
|
||||
- [Roadmap transverse](./projet/roadmap-initiale.md)
|
||||
- [Socle RGAA projets](./projet/rgaa-socle-projets.md)
|
||||
- [RGPD](./rgpd/README.md)
|
||||
- [ISO 27001](./iso27001/README.md)
|
||||
1
convergence/ccds-docs/comptes-rendus/.gitkeep
Normal file
1
convergence/ccds-docs/comptes-rendus/.gitkeep
Normal file
|
|
@ -0,0 +1 @@
|
|||
|
||||
1
convergence/ccds-docs/iso27001/.gitkeep
Normal file
1
convergence/ccds-docs/iso27001/.gitkeep
Normal file
|
|
@ -0,0 +1 @@
|
|||
|
||||
17
convergence/ccds-docs/iso27001/README.md
Normal file
17
convergence/ccds-docs/iso27001/README.md
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
# ISO 27001
|
||||
|
||||
Ce dossier sert a structurer la trajectoire de securite du projet.
|
||||
|
||||
## Axes prioritaires
|
||||
|
||||
- gouvernance
|
||||
- gestion des acces
|
||||
- sauvegardes et continuite
|
||||
- gestion des incidents
|
||||
- gestion des fournisseurs
|
||||
- revue des risques
|
||||
|
||||
## Documents de depart
|
||||
|
||||
- `matrice-ecarts.md`
|
||||
- `declaration-applicabilite-a-preparer.md`
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
# Declaration d'applicabilite a preparer
|
||||
|
||||
## Objet
|
||||
|
||||
Lister les mesures de securite retenues, partiellement en place ou encore a completer.
|
||||
|
||||
## Domaines a couvrir
|
||||
|
||||
- organisation de la securite ;
|
||||
- gestion des identites et acces ;
|
||||
- journalisation ;
|
||||
- sauvegardes et restauration ;
|
||||
- continuite ;
|
||||
- fournisseurs ;
|
||||
- gestion des incidents ;
|
||||
- protection des donnees personnelles.
|
||||
|
||||
## Statut
|
||||
|
||||
Document a construire a partir des preuves deja presentes dans le portail, des procedures et des pratiques VPS.
|
||||
13
convergence/ccds-docs/iso27001/matrice-ecarts.md
Normal file
13
convergence/ccds-docs/iso27001/matrice-ecarts.md
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
# Matrice initiale des ecarts
|
||||
|
||||
## Ecarts deja identifies
|
||||
|
||||
- certaines preuves d'exploitation restent encore manuelles ;
|
||||
- les tests de restauration doivent etre historises plus regulierement ;
|
||||
- la declaration d'applicabilite ISO 27001 reste a formaliser ;
|
||||
- la procedure incident doit etre adoptee et testee en exploitation ;
|
||||
- la cartographie des fournisseurs et accords DPA doit etre centralisee.
|
||||
|
||||
## Logique
|
||||
|
||||
Cette matrice sert a suivre les ecarts reels, pas a produire une documentation decorative.
|
||||
1
convergence/ccds-docs/procedures/.gitkeep
Normal file
1
convergence/ccds-docs/procedures/.gitkeep
Normal file
|
|
@ -0,0 +1 @@
|
|||
|
||||
32
convergence/ccds-docs/procedures/incident.md
Normal file
32
convergence/ccds-docs/procedures/incident.md
Normal file
|
|
@ -0,0 +1,32 @@
|
|||
# Procedure de gestion des incidents
|
||||
|
||||
## Objectif
|
||||
|
||||
Disposer d'une procedure simple, partagee et exploitable pour classifier, contenir, investiguer et clore un incident.
|
||||
|
||||
## Etapes
|
||||
|
||||
1. detection et qualification
|
||||
2. confinement
|
||||
3. investigation
|
||||
4. correction
|
||||
5. decision RGPD si des donnees personnelles sont concernees
|
||||
6. revue post-incident
|
||||
|
||||
## Niveaux minimaux
|
||||
|
||||
- faible : incident sans impact metier significatif ;
|
||||
- moyen : degradation de service ou anomalie de securite a traiter rapidement ;
|
||||
- eleve : indisponibilite majeure, fuite potentielle ou impact fort ;
|
||||
- critique : incident grave avec risque organisationnel ou legal important.
|
||||
|
||||
## Traces a conserver
|
||||
|
||||
- date et heure ;
|
||||
- personnes mobilisees ;
|
||||
- perimetre ;
|
||||
- actions de confinement ;
|
||||
- cause probable ;
|
||||
- impact donnees personnelles oui/non ;
|
||||
- decision de notification ;
|
||||
- actions correctives.
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
# Sauvegardes et restauration
|
||||
|
||||
## Objectif
|
||||
|
||||
Demonstrer que la continuite technique n'est pas seulement supposee, mais pilotee.
|
||||
|
||||
## Sauvegardes
|
||||
|
||||
Pour chaque sauvegarde de reference, on cherche a conserver :
|
||||
|
||||
- date et heure ;
|
||||
- environnement ;
|
||||
- type de sauvegarde ;
|
||||
- statut succes / echec ;
|
||||
- volume indicatif ;
|
||||
- retention appliquee ;
|
||||
- preuve associee si disponible.
|
||||
|
||||
## Restaurations testees
|
||||
|
||||
Pour chaque test de restauration, on cherche a conserver :
|
||||
|
||||
- date ;
|
||||
- environnement ;
|
||||
- perimetre restaure ;
|
||||
- resultat ;
|
||||
- responsable ;
|
||||
- observations ;
|
||||
- prochaine verification utile.
|
||||
|
||||
## Ambition
|
||||
|
||||
Passer d'une logique declarative a un suivi auditable.
|
||||
1
convergence/ccds-docs/projet/.gitkeep
Normal file
1
convergence/ccds-docs/projet/.gitkeep
Normal file
|
|
@ -0,0 +1 @@
|
|||
|
||||
26
convergence/ccds-docs/projet/decisions/README.md
Normal file
26
convergence/ccds-docs/projet/decisions/README.md
Normal file
|
|
@ -0,0 +1,26 @@
|
|||
# Decisions / ADR
|
||||
|
||||
Ce dossier accueille les decisions structurantes du projet.
|
||||
|
||||
## Objectif
|
||||
|
||||
Garder une trace courte des choix importants :
|
||||
|
||||
- architecture ;
|
||||
- securite ;
|
||||
- exploitation ;
|
||||
- UX structurante ;
|
||||
- cartographie ;
|
||||
- gouvernance.
|
||||
|
||||
## Structure
|
||||
|
||||
- `proposed/` : decisions en preparation
|
||||
- `accepted/` : decisions retenues
|
||||
- `superseded/` : decisions remplacees
|
||||
- `adr-template.md` : modele a reutiliser
|
||||
|
||||
## Regle simple
|
||||
|
||||
Une decision = un fichier court, daté, avec contexte, choix et consequences.
|
||||
|
||||
1
convergence/ccds-docs/projet/decisions/accepted/.gitkeep
Normal file
1
convergence/ccds-docs/projet/decisions/accepted/.gitkeep
Normal file
|
|
@ -0,0 +1 @@
|
|||
|
||||
|
|
@ -0,0 +1,62 @@
|
|||
# ADR-0001 - Separation des depots CCDS
|
||||
|
||||
- Statut : accepted
|
||||
- Date : 2026-06-24
|
||||
- Domaine : gouvernance
|
||||
|
||||
## Contexte
|
||||
|
||||
Le projet portail-association973 a besoin d'un cadre de travail plus lisible et plus durable.
|
||||
|
||||
Au fil des evolutions, quatre besoins differents se sont affirmes :
|
||||
|
||||
- faire vivre le code applicatif ;
|
||||
- piloter l'infrastructure et l'exploitation ;
|
||||
- centraliser la documentation transverse, la conformite et les procedures ;
|
||||
- versionner separement les styles et ressources cartographiques.
|
||||
|
||||
Garder tout dans un seul depot aurait augmente le bruit, melange les responsabilites et rendu l'audit plus difficile.
|
||||
|
||||
## Decision
|
||||
|
||||
L'organisation `ccds` adopte une separation en depots specialises :
|
||||
|
||||
- `portail-associations` pour le produit et le code applicatif ;
|
||||
- `infra` pour le deploiement, l'exploitation, les sauvegardes et la maintenance ;
|
||||
- `docs` pour la gouvernance, la conformite, les procedures et les livrables transverses ;
|
||||
- `cartographie` pour les styles, variantes, ressources et decisions cartographiques ;
|
||||
- `templates` pour les conventions de tickets, checklists et modeles communs ;
|
||||
- `.profile` pour presenter l'organisation et le role de chaque depot.
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positives
|
||||
|
||||
- meilleure lisibilite des sujets ;
|
||||
- responsabilites plus claires ;
|
||||
- meilleure auditabilite RGPD / ISO 27001 / exploitation ;
|
||||
- cartographie mieux isolee comme brique metier ;
|
||||
- organisation Forgejo plus simple a lire pour les equipes.
|
||||
|
||||
### Vigilances
|
||||
|
||||
- eviter les duplications entre `docs`, `infra` et `portail-associations` ;
|
||||
- garder des conventions communes de tickets, labels et milestones ;
|
||||
- relier les depots par des references claires plutot que par des copies.
|
||||
|
||||
## Regles de fonctionnement retenues
|
||||
|
||||
1. Le code produit vit dans `portail-associations`.
|
||||
2. Les procedures d'exploitation et la logique VPS vivent dans `infra`.
|
||||
3. Les documents de conformite, gouvernance et arbitrage vivent dans `docs`.
|
||||
4. Les styles cartographiques et leurs variantes vivent dans `cartographie`.
|
||||
5. Les modeles reutilisables vivent dans `templates`.
|
||||
6. Les decisions structurantes du projet sont historisees dans `docs/projet/decisions`.
|
||||
|
||||
## Mise en oeuvre
|
||||
|
||||
- organisation Forgejo `ccds` creee ;
|
||||
- equipes `technique`, `pilotage` et `lecture` configurees ;
|
||||
- depots specialises initialises ;
|
||||
- labels communs et milestones poses ;
|
||||
- premieres conventions documentaires ajoutees.
|
||||
|
|
@ -0,0 +1,61 @@
|
|||
# ADR-0002 - Conventions de labels et milestones Forgejo
|
||||
|
||||
- Statut : accepted
|
||||
- Date : 2026-06-24
|
||||
- Domaine : gouvernance
|
||||
|
||||
## Contexte
|
||||
|
||||
Une organisation multi-depots devient vite brouillonne si chaque depot emploie ses propres labels et ses propres reperes calendaires.
|
||||
|
||||
Le projet CCDS a besoin d'un langage commun pour :
|
||||
|
||||
- prioriser les sujets ;
|
||||
- reconnaitre les domaines metier ;
|
||||
- suivre les lots dans le temps ;
|
||||
- garder une lecture simple pour le pilotage.
|
||||
|
||||
## Decision
|
||||
|
||||
Les depots CCDS adoptent :
|
||||
|
||||
- un socle commun de labels transverses ;
|
||||
- des labels metier additionnels quand ils apportent un gain reel ;
|
||||
- des milestones datees partagees a l'echelle de l'organisation.
|
||||
|
||||
## Labels communs retenus
|
||||
|
||||
- `bug`
|
||||
- `ux`
|
||||
- `infra`
|
||||
- `conformite`
|
||||
- `cartographie`
|
||||
- `priorite-haute`
|
||||
- `priorite-moyenne`
|
||||
- `a-valider`
|
||||
- `admin`
|
||||
- `association`
|
||||
- `public`
|
||||
- `logistique`
|
||||
- `rgpd-iso27001`
|
||||
|
||||
## Milestones datees retenues
|
||||
|
||||
- `T3 2026 - Socle organisationnel`
|
||||
- `T3 2026 - Exploitation & conformité`
|
||||
- `T3 2026 - UX portail & admin`
|
||||
- `T3 2026 - Cartographie premium`
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positives
|
||||
|
||||
- tickets plus lisibles ;
|
||||
- tri plus rapide ;
|
||||
- pilotage inter-depots plus coherent ;
|
||||
- moins de bruit dans l'organisation.
|
||||
|
||||
### Vigilances
|
||||
|
||||
- eviter de multiplier les labels sans besoin reel ;
|
||||
- fermer les anciennes milestones generiques quand les versions datees existent.
|
||||
|
|
@ -0,0 +1,61 @@
|
|||
# ADR-0003 - Discipline des acces par equipe
|
||||
|
||||
- Statut : accepted
|
||||
- Date : 2026-06-24
|
||||
- Domaine : securite
|
||||
|
||||
## Contexte
|
||||
|
||||
L'organisation Forgejo ne devait pas rester ouverte par defaut sur tous les depots pour toutes les equipes.
|
||||
|
||||
Il fallait distinguer :
|
||||
|
||||
- le besoin de production technique ;
|
||||
- le besoin de pilotage ;
|
||||
- le besoin de simple lecture.
|
||||
|
||||
## Decision
|
||||
|
||||
Les equipes CCDS adoptent la discipline suivante :
|
||||
|
||||
- `technique` : acces fort sur les depots de travail et d'exploitation ;
|
||||
- `pilotage` : acces cible aux depots utiles au suivi projet ;
|
||||
- `lecture` : acces restreint aux depots de consultation et de gouvernance.
|
||||
|
||||
## Repartition retenue
|
||||
|
||||
### technique
|
||||
|
||||
- `portail-associations`
|
||||
- `infra`
|
||||
- `docs`
|
||||
- `cartographie`
|
||||
- `templates`
|
||||
|
||||
### pilotage
|
||||
|
||||
- `.profile`
|
||||
- `docs`
|
||||
- `templates`
|
||||
- `portail-associations`
|
||||
- `cartographie`
|
||||
|
||||
### lecture
|
||||
|
||||
- `.profile`
|
||||
- `docs`
|
||||
- `templates`
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positives
|
||||
|
||||
- meilleure hygiene d'acces ;
|
||||
- exposition reduite des depots sensibles ;
|
||||
- pilotage plus clair ;
|
||||
- verification reelle possible avec comptes non proprietaires.
|
||||
|
||||
### Vigilances
|
||||
|
||||
- revoir les acces si de nouveaux depots ou de nouveaux usages apparaissent ;
|
||||
- tester periodiquement les permissions reelles.
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
# ADR-0004 - Depot templates communs de travail
|
||||
|
||||
- Statut : accepted
|
||||
- Date : 2026-06-24
|
||||
- Domaine : gouvernance
|
||||
|
||||
## Contexte
|
||||
|
||||
Les modeles utiles etaient en train de se disperser entre les depots : tickets, checklists, exemples ADR et conventions de redaction.
|
||||
|
||||
## Decision
|
||||
|
||||
Un depot dedie `templates` sert de reference commune pour :
|
||||
|
||||
- conventions de tickets ;
|
||||
- checklists simples ;
|
||||
- exemples ADR ;
|
||||
- bases de travail reutilisables.
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positives
|
||||
|
||||
- moins de duplication inutile ;
|
||||
- meilleur point d'entree pour les futurs projets ;
|
||||
- pratiques plus homogènes dans l'organisation.
|
||||
|
||||
### Vigilances
|
||||
|
||||
- les modeles actifs specifiques a un depot peuvent rester localement quand cela a du sens ;
|
||||
- le depot `templates` doit rester leger et utile.
|
||||
28
convergence/ccds-docs/projet/decisions/adr-template.md
Normal file
28
convergence/ccds-docs/projet/decisions/adr-template.md
Normal file
|
|
@ -0,0 +1,28 @@
|
|||
# ADR-XXXX - Titre court
|
||||
|
||||
- Statut : proposed / accepted / superseded
|
||||
- Date : YYYY-MM-DD
|
||||
- Domaine : produit / infra / cartographie / conformite / securite
|
||||
|
||||
## Contexte
|
||||
|
||||
Quel probleme ou quelle tension doit-on trancher ?
|
||||
|
||||
## Decision
|
||||
|
||||
Quel choix est retenu ?
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positives
|
||||
|
||||
-
|
||||
|
||||
### Vigilances
|
||||
|
||||
-
|
||||
|
||||
## Mise en oeuvre
|
||||
|
||||
-
|
||||
|
||||
1
convergence/ccds-docs/projet/decisions/proposed/.gitkeep
Normal file
1
convergence/ccds-docs/projet/decisions/proposed/.gitkeep
Normal file
|
|
@ -0,0 +1 @@
|
|||
|
||||
|
|
@ -0,0 +1 @@
|
|||
|
||||
38
convergence/ccds-docs/projet/index-gouvernance-projet.md
Normal file
38
convergence/ccds-docs/projet/index-gouvernance-projet.md
Normal file
|
|
@ -0,0 +1,38 @@
|
|||
# Index de gouvernance projet
|
||||
|
||||
## Finalite
|
||||
|
||||
Donner un point d'entree simple pour piloter le projet sans chercher les informations dans plusieurs depots.
|
||||
|
||||
## A consulter en priorite
|
||||
|
||||
### Vision et pilotage
|
||||
|
||||
- [Roadmap initiale](./roadmap-initiale.md)
|
||||
- [Socle RGAA projets](./rgaa-socle-projets.md)
|
||||
|
||||
### Conformite et securite
|
||||
|
||||
- [RGPD](/Users/selecta/Documents/ccds-forgejo/docs/rgpd/README.md)
|
||||
- [ISO 27001](/Users/selecta/Documents/ccds-forgejo/docs/iso27001/README.md)
|
||||
- [Procedure incident](/Users/selecta/Documents/ccds-forgejo/docs/procedures/incident.md)
|
||||
- [Sauvegardes et restauration](/Users/selecta/Documents/ccds-forgejo/docs/procedures/sauvegardes-et-restauration.md)
|
||||
|
||||
### Exploitation et technique
|
||||
|
||||
- Depot `infra`
|
||||
- Depot `cartographie`
|
||||
- Depot `portail-associations`
|
||||
|
||||
## Repartition des roles de depots
|
||||
|
||||
- `portail-associations` : produit et application
|
||||
- `infra` : exploitation, deploiement, maintenance
|
||||
- `docs` : gouvernance, conformite, procedures
|
||||
- `cartographie` : styles, variantes et publication carto
|
||||
|
||||
## Usage recommande
|
||||
|
||||
1. partir de cet index pour les revues projet ;
|
||||
2. ouvrir ensuite le depot specialise adapte au sujet ;
|
||||
3. garder ici les liens de reference, pas les duplications inutiles.
|
||||
82
convergence/ccds-docs/projet/rgaa-socle-projets.md
Normal file
82
convergence/ccds-docs/projet/rgaa-socle-projets.md
Normal file
|
|
@ -0,0 +1,82 @@
|
|||
# Socle RGAA transverse des projets CCDS
|
||||
|
||||
<div class="ccds-rgaa">
|
||||
<section class="ccds-hero">
|
||||
<div class="ccds-hero-kicker">Accessibilite numerique</div>
|
||||
<h1>Passe RGAA transverse des projets</h1>
|
||||
<p>Cette note fixe un socle commun pour eviter que chaque depot reparte de zero. Elle ne remplace pas un audit complet, mais donne une base exploitable pour le portail, la cartographie, la documentation et les futurs outils internes.</p>
|
||||
</section>
|
||||
|
||||
<section class="ccds-rgaa-grid">
|
||||
<article class="ccds-rgaa-card">
|
||||
<h3>Contenu et structure</h3>
|
||||
<ul>
|
||||
<li>un seul <code>h1</code> par vue ;</li>
|
||||
<li>hierarchie de titres logique ;</li>
|
||||
<li>textes d'action explicites ;</li>
|
||||
<li>liens compréhensibles hors contexte.</li>
|
||||
</ul>
|
||||
</article>
|
||||
|
||||
<article class="ccds-rgaa-card">
|
||||
<h3>Couleurs et contrastes</h3>
|
||||
<ul>
|
||||
<li>contraste suffisant sur texte, badges et boutons ;</li>
|
||||
<li>pas d'information portee par la seule couleur ;</li>
|
||||
<li>fonds immersifs toujours au service de la lisibilite.</li>
|
||||
</ul>
|
||||
</article>
|
||||
|
||||
<article class="ccds-rgaa-card">
|
||||
<h3>Navigation clavier</h3>
|
||||
<ul>
|
||||
<li>ordre de focus coherent ;</li>
|
||||
<li>menus repliables activables au clavier ;</li>
|
||||
<li>modales et panneaux refermables proprement.</li>
|
||||
</ul>
|
||||
</article>
|
||||
|
||||
<article class="ccds-rgaa-card">
|
||||
<h3>Formulaires et retours</h3>
|
||||
<ul>
|
||||
<li>labels visibles et relies aux champs ;</li>
|
||||
<li>erreurs explicites et localisees ;</li>
|
||||
<li>messages de succes comprehensibles ;</li>
|
||||
<li>etats de chargement non ambigus.</li>
|
||||
</ul>
|
||||
</article>
|
||||
|
||||
<article class="ccds-rgaa-card">
|
||||
<h3>Images, cartes et medias</h3>
|
||||
<ul>
|
||||
<li>textes alternatifs utiles pour les images non decoratives ;</li>
|
||||
<li>cartes toujours accompagnees d'une alternative textuelle ou liste ;</li>
|
||||
<li>decorations de cards sans impact sur la lecture.</li>
|
||||
</ul>
|
||||
</article>
|
||||
|
||||
<article class="ccds-rgaa-card">
|
||||
<h3>Documentation et wiki</h3>
|
||||
<ul>
|
||||
<li>README lisibles avec structure simple ;</li>
|
||||
<li>tableaux reserves aux vraies donnees tabulaires ;</li>
|
||||
<li>roadmaps et procedures lisibles sans mise en page complexe.</li>
|
||||
</ul>
|
||||
</article>
|
||||
</section>
|
||||
</div>
|
||||
|
||||
## Priorites de controle
|
||||
|
||||
1. portail-associations : parcours publics, association, admin dense ;
|
||||
2. cartographie : filtres, marqueurs, guidage et lisibilite mobile ;
|
||||
3. docs et Forgejo : lisibilite, navigation et structure des contenus ;
|
||||
4. futurs outils internes : reprendre ce socle des la V1.
|
||||
|
||||
## Definition de fini minimale
|
||||
|
||||
- chaque nouveau module doit passer un controle clavier ;
|
||||
- les couleurs critiques sont verifiees ;
|
||||
- les retours d'erreur et de succes sont lisibles ;
|
||||
- la structure de titres reste propre ;
|
||||
- les principaux ecrans mobiles sont verifies.
|
||||
54
convergence/ccds-docs/projet/roadmap-initiale.md
Normal file
54
convergence/ccds-docs/projet/roadmap-initiale.md
Normal file
|
|
@ -0,0 +1,54 @@
|
|||
# Roadmap transverse CCDS
|
||||
|
||||
<div class="ccds-roadmap">
|
||||
<div class="ccds-roadmap-list">
|
||||
<div class="ccds-roadmap-item">
|
||||
<div class="ccds-roadmap-index">1</div>
|
||||
<div>
|
||||
<h3>Stabilisation produit et UX</h3>
|
||||
<p>Rendre le portail plus lisible, plus rapide et plus confortable en usage reel, sur desktop comme sur mobile.</p>
|
||||
<div class="ccds-badges"><span class="ccds-badge success">Actif</span><span class="ccds-badge">Portail</span></div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="ccds-roadmap-item">
|
||||
<div class="ccds-roadmap-index">2</div>
|
||||
<div>
|
||||
<h3>Cartographie auto-hebergee premium</h3>
|
||||
<p>Consolider OpenMapTiles, styles public / admin et guidage terrain sans perdre la lisibilite institutionnelle.</p>
|
||||
<div class="ccds-badges"><span class="ccds-badge success">Actif</span><span class="ccds-badge">Cartographie</span></div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="ccds-roadmap-item">
|
||||
<div class="ccds-roadmap-index">3</div>
|
||||
<div>
|
||||
<h3>Conformite RGPD, RGAA et trajectoire ISO 27001</h3>
|
||||
<p>Passer d'une base documentaire existante a un pilotage plus probant, plus auditable et plus regulier.</p>
|
||||
<div class="ccds-badges"><span class="ccds-badge">Conformite</span><span class="ccds-badge warn">A renforcer</span></div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="ccds-roadmap-item">
|
||||
<div class="ccds-roadmap-index">4</div>
|
||||
<div>
|
||||
<h3>Industrialisation de l'exploitation</h3>
|
||||
<p>Structurer les sauvegardes, restaurations, healthchecks, maintenance et preuves d'execution.</p>
|
||||
<div class="ccds-badges"><span class="ccds-badge">Infra</span><span class="ccds-badge warn">Pilotage a maturer</span></div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="ccds-roadmap-item">
|
||||
<div class="ccds-roadmap-index">5</div>
|
||||
<div>
|
||||
<h3>Gouvernance documentaire et Forgejo</h3>
|
||||
<p>Maintenir un espace de travail range, tracable et partageable, avec ADR, templates et depots bien separes.</p>
|
||||
<div class="ccds-badges"><span class="ccds-badge">Docs</span><span class="ccds-badge">Forgejo</span></div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
## Regle de pilotage
|
||||
|
||||
Traiter d'abord ce qui renforce la fiabilite, la lisibilite, l'accessibilite et l'usage reel.
|
||||
1
convergence/ccds-docs/rgpd/.gitkeep
Normal file
1
convergence/ccds-docs/rgpd/.gitkeep
Normal file
|
|
@ -0,0 +1 @@
|
|||
|
||||
21
convergence/ccds-docs/rgpd/README.md
Normal file
21
convergence/ccds-docs/rgpd/README.md
Normal file
|
|
@ -0,0 +1,21 @@
|
|||
# RGPD
|
||||
|
||||
Ce dossier rassemble les documents de reference pour la conformite RGPD du portail et des services associes.
|
||||
|
||||
## Priorites
|
||||
|
||||
1. registre des traitements
|
||||
2. information des usagers
|
||||
3. retention, purge et suppression
|
||||
4. incidents a impact donnees personnelles
|
||||
5. preuves d'exploitation utiles au DPO
|
||||
|
||||
## Documents de depart
|
||||
|
||||
- `retention-et-purge.md`
|
||||
- `rapport-mensuel-dpo.md`
|
||||
- `registre-des-traitements-a-preparer.md`
|
||||
|
||||
## Principe
|
||||
|
||||
On cherche ici une conformite praticable : documents relus, traçables et relies aux preuves reelles d'exploitation.
|
||||
26
convergence/ccds-docs/rgpd/rapport-mensuel-dpo.md
Normal file
26
convergence/ccds-docs/rgpd/rapport-mensuel-dpo.md
Normal file
|
|
@ -0,0 +1,26 @@
|
|||
# Rapport mensuel DPO et exploitation
|
||||
|
||||
## Finalite
|
||||
|
||||
Fournir un cadre simple pour suivre chaque mois les preuves d'exploitation utiles a la conformite.
|
||||
|
||||
## A suivre chaque mois
|
||||
|
||||
- derniere sauvegarde reussie ;
|
||||
- preuve de sauvegarde rattachee ;
|
||||
- dernier test de restauration ;
|
||||
- incidents securite ;
|
||||
- incidents a impact donnees personnelles ;
|
||||
- rapport de retention genere ;
|
||||
- ecarts ouverts et actions correctives.
|
||||
|
||||
## Questions de controle
|
||||
|
||||
- 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 quelles actions restent ouvertes.
|
||||
|
||||
## Sortie attendue
|
||||
|
||||
Un document court, relu chaque mois, pouvant etre montre au DPO, a la DSI ou a un auditeur.
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
# Registre des traitements a preparer
|
||||
|
||||
## Traitements a cadrer en priorite
|
||||
|
||||
- comptes association
|
||||
- documents televerses
|
||||
- demandes administratives
|
||||
- notifications et journaux
|
||||
- cartographie et points geographiques
|
||||
- exploitation, sauvegardes et incidents
|
||||
|
||||
## Champs minimaux par traitement
|
||||
|
||||
- finalite ;
|
||||
- base legale ;
|
||||
- personnes concernees ;
|
||||
- donnees traitees ;
|
||||
- destinataires ;
|
||||
- duree de conservation ;
|
||||
- mesures de securite ;
|
||||
- sous-traitants ou hebergeurs.
|
||||
|
||||
## Ambition
|
||||
|
||||
Passer d'une conformite declaree a un registre reellement exploitable.
|
||||
34
convergence/ccds-docs/rgpd/retention-et-purge.md
Normal file
34
convergence/ccds-docs/rgpd/retention-et-purge.md
Normal file
|
|
@ -0,0 +1,34 @@
|
|||
# Retention et purge des donnees
|
||||
|
||||
## Objectif
|
||||
|
||||
Assurer la suppression, l'anonymisation et la purge planifiee des donnees conformement au RGPD, aux obligations legales de conservation et aux bonnes pratiques de securite.
|
||||
|
||||
## Cycle de vie attendu
|
||||
|
||||
1. creation de la donnee
|
||||
2. usage courant
|
||||
3. archivage si necessaire
|
||||
4. marquage pour suppression
|
||||
5. retention temporaire si obligation ou legal hold
|
||||
6. suppression ou anonymisation
|
||||
7. journalisation
|
||||
|
||||
## Regles de base
|
||||
|
||||
- seules les donnees utiles sont conservees ;
|
||||
- la suppression doit etre traçable ;
|
||||
- les exceptions legal hold doivent etre documentees ;
|
||||
- une donnee supprimee ne doit pas etre restauree hors incident majeur documente.
|
||||
|
||||
## Preuves attendues
|
||||
|
||||
- dernier rapport de retention ;
|
||||
- nombre de comptes supprimes ;
|
||||
- purges executees ;
|
||||
- exceptions legal hold ;
|
||||
- incidents lies a la retention s'il y en a.
|
||||
|
||||
## Lien exploitation
|
||||
|
||||
Les preuves reelles doivent etre visibles dans le tableau de pilotage ou rattachees a un rapport mensuel DPO.
|
||||
Loading…
Add table
Add a link
Reference in a new issue