docs: rationalisation post-0.1.0 (bilan, purge tmp, archives).

- Bilan 29 + index versions 05 ; suivi tickets pointeur Gitea - Purge docs/tmp et archive/temporaires livrés - Archive SuperNounou, liste tickets figée, backlog Phase 2, notes 14/92 - Suppression stubs PROCEDURE/22 ; INDEX et roadmap alignés Co-authored-by: Cursor <cursoragent@cursor.com>
2026-09-14 17:45:43 +02:00
parent 3218daa12e
commit 71b1897678
38 changed files with 379 additions and 2211 deletions
@@ -0,0 +1,37 @@
+# Ticket #14 – Note pour modifications backend
+
+**Contexte :** Première connexion admin → panneau Paramètres, déblocage après clic sur « Sauvegarder ». Le front appelle `POST /api/v1/configuration/setup/complete` au clic sur Sauvegarder.
+
+## Problème
+
+Erreur renvoyée par le back :  
+`invalid input syntax for type uuid: "system"`
+
+- Le controller fait `const userId = req.user?.id || 'system'` puis `markSetupCompleted(userId)`.
+- Le service `set()` fait `config.modifiePar = { id: userId }` ; la colonne `modifie_par` est une FK UUID vers `users`.
+- La chaîne `"system"` n’est pas un UUID valide → erreur PostgreSQL.
+
+## Modifications à apporter au backend
+
+**Option A – Accepter l’absence d’utilisateur (recommandé si la route peut être appelée sans JWT)**
+
+1. **`config.controller.ts`** (route `completeSetup`)  
+   - Remplacer :  
+     `const userId = req.user?.id || 'system';`  
+   - Par :  
+     `const userId = req.user?.id ?? null;`
+
+2. **`config.service.ts`** (`markSetupCompleted`)  
+   - Changer la signature :  
+     `async markSetupCompleted(userId: string | null): Promise<void>`  
+   - Et appeler :  
+     `await this.set('setup_completed', 'true', userId ?? undefined);`  
+   - Dans `set()`, ne pas remplir `modifiePar` quand `userId` est absent (déjà le cas si `if (userId)`).
+
+**Option B – Imposer un utilisateur authentifié**
+
+- Activer le guard JWT (et éventuellement RolesGuard) sur `POST /configuration/setup/complete` pour que `req.user` soit toujours défini, et garder `userId = req.user.id` (plus de fallback `'system'`).
+
+---
+
+Une fois le back modifié, le flux « Sauvegarder » → déblocage des panneaux fonctionne sans erreur.
@@ -0,0 +1,433 @@
+# 📋 Backlog Phase 2 - P'titsPas
+
+**Version** : 1.0  
+**Date** : 25 Novembre 2025  
+**Auteur** : Équipe PtitsPas
+
+---
+
+## 🎯 Objectif de ce document
+
+Ce document liste toutes les **fonctionnalités reportées en Phase 2**. Ces fonctionnalités ne sont pas bloquantes pour le MVP (Phase 1), mais apportent de la valeur ajoutée pour la production intensive.
+
+---
+
+## 📊 Vue d'ensemble
+
+| Catégorie | Nombre de tickets | Estimation |
+|-----------|-------------------|------------|
+| **RGPD avancé** | 3 tickets | ~8h |
+| **Monitoring avancé** | 2 tickets | ~6h |
+| **Statistiques & Reporting** | 4 tickets | ~16h |
+| **Sauvegarde & Restauration** | 2 tickets | ~6h |
+| **Documentation utilisateur** | 3 tickets | ~12h |
+| **Améliorations UX** | 3 tickets | ~10h |
+| **TOTAL** | **17 tickets** | **~58h** |
+
+---
+
+## 🔒 RGPD avancé
+
+### Ticket P2-01 : [Backend] API Suppression compte (soft delete)
+**Estimation** : 3h  
+**Labels** : `backend`, `phase-2`, `rgpd`
+
+**Description** :
+Implémenter le droit à l'oubli (RGPD Article 17) avec suppression logique des comptes.
+
+**Tâches** :
+- [ ] Endpoint `DELETE /api/v1/users/:id` (soft delete)
+- [ ] Ajout champ `supprime_le` TIMESTAMPTZ dans `utilisateurs`
+- [ ] Anonymisation données personnelles (email, téléphone, adresse)
+- [ ] Conservation données légales (acceptations CGU)
+- [ ] Guards (super_admin only)
+- [ ] Tests unitaires
+
+**Justification report Phase 2** :
+- Peu de demandes en phase test
+- Suppression manuelle possible en attendant
+
+---
+
+### Ticket P2-02 : [Backend] API Export données personnelles (RGPD)
+**Estimation** : 3h  
+**Labels** : `backend`, `phase-2`, `rgpd`
+
+**Description** :
+Implémenter le droit à la portabilité (RGPD Article 20) avec export JSON des données personnelles.
+
+**Tâches** :
+- [ ] Endpoint `GET /api/v1/users/:id/export` (JSON)
+- [ ] Export données utilisateur + enfants + acceptations
+- [ ] Format JSON structuré
+- [ ] Guards (utilisateur lui-même ou admin)
+- [ ] Tests unitaires
+
+**Justification report Phase 2** :
+- Export manuel SQL possible en phase test
+- Peu de demandes attendues
+
+---
+
+### Ticket P2-03 : [Backend] Cron anonymisation comptes inactifs
+**Estimation** : 2h  
+**Labels** : `backend`, `phase-2`, `rgpd`, `cron`
+
+**Description** :
+Anonymiser automatiquement les comptes inactifs après X mois (configurable).
+
+**Tâches** :
+- [ ] Cron job quotidien
+- [ ] Détection comptes inactifs (dernière connexion > X mois)
+- [ ] Anonymisation automatique
+- [ ] Notification admin
+- [ ] Configuration durée inactivité (table `configuration`)
+- [ ] Tests
+
+**Justification report Phase 2** :
+- Pas de comptes inactifs en phase test
+- Peut être fait manuellement
+
+---
+
+## 📊 Monitoring avancé
+
+### Ticket P2-04 : [Backend] API Métriques système
+**Estimation** : 3h  
+**Labels** : `backend`, `phase-2`, `monitoring`
+
+**Description** :
+Exposer des métriques système (CPU, RAM, disque, BDD) pour monitoring.
+
+**Tâches** :
+- [ ] Endpoint `GET /api/v1/metrics` (super_admin only)
+- [ ] Métriques système (CPU, RAM, disque)
+- [ ] Métriques BDD (connexions, taille, requêtes lentes)
+- [ ] Métriques application (requêtes/s, temps réponse)
+- [ ] Format Prometheus (optionnel)
+- [ ] Tests
+
+**Justification report Phase 2** :
+- Pas critique pour MVP
+- Logs suffisent pour debugging initial
+
+---
+
+### Ticket P2-05 : [Frontend] Dashboard Monitoring
+**Estimation** : 3h  
+**Labels** : `frontend`, `phase-2`, `monitoring`, `admin`
+
+**Description** :
+Créer un dashboard de monitoring pour le super admin.
+
+**Tâches** :
+- [ ] Page `/admin/monitoring` (super_admin only)
+- [ ] Graphiques temps réel (CPU, RAM, disque)
+- [ ] Alertes (seuils configurables)
+- [ ] Historique métriques (7 jours)
+
+**Justification report Phase 2** :
+- Pas critique pour MVP
+- Monitoring serveur possible via outils système
+
+---
+
+## 📈 Statistiques & Reporting
+
+### Ticket P2-06 : [Backend] API Statistiques dashboard
+**Estimation** : 4h  
+**Labels** : `backend`, `phase-2`, `statistiques`
+
+**Description** :
+Créer les endpoints pour récupérer les statistiques de l'application.
+
+**Tâches** :
+- [ ] Endpoint `GET /api/v1/stats/overview`
+- [ ] Statistiques globales (comptes, enfants, AM, validations)
+- [ ] Statistiques temporelles (inscriptions par mois, validations par semaine)
+- [ ] Statistiques géographiques (par ville)
+- [ ] Cache (rafraîchissement toutes les heures)
+- [ ] Tests
+
+**Justification report Phase 2** :
+- Pas de données = pas de statistiques
+- Nécessite application en production
+
+---
+
+### Ticket P2-07 : [Frontend] Widgets statistiques dashboard
+**Estimation** : 4h  
+**Labels** : `frontend`, `phase-2`, `statistiques`, `gestionnaire`
+
+**Description** :
+Afficher les statistiques dans le dashboard gestionnaire.
+
+**Tâches** :
+- [ ] Widget "Comptes en attente" (nombre)
+- [ ] Widget "Comptes validés ce mois" (graphique)
+- [ ] Widget "Enfants inscrits" (nombre)
+- [ ] Widget "AM disponibles" (nombre)
+- [ ] Graphique évolution inscriptions (6 derniers mois)
+
+**Justification report Phase 2** :
+- Besoin d'utilisateurs réels pour avoir des données
+- Fonctionnalité importante pour vente, mais pas bloquante pour MVP
+
+---
+
+### Ticket P2-08 : [Backend] API Export rapports (CSV/PDF)
+**Estimation** : 4h  
+**Labels** : `backend`, `phase-2`, `reporting`
+
+**Description** :
+Permettre l'export de rapports pour les gestionnaires.
+
+**Tâches** :
+- [ ] Endpoint `GET /api/v1/reports/users` (CSV)
+- [ ] Endpoint `GET /api/v1/reports/validations` (CSV)
+- [ ] Endpoint `GET /api/v1/reports/summary` (PDF)
+- [ ] Génération PDF (librairie PDFKit)
+- [ ] Filtres (date, statut, rôle)
+- [ ] Tests
+
+**Justification report Phase 2** :
+- Export manuel SQL possible en phase test
+- Nécessite données réelles
+
+---
+
+### Ticket P2-09 : [Frontend] Écran Rapports
+**Estimation** : 4h  
+**Labels** : `frontend`, `phase-2`, `reporting`, `gestionnaire`
+
+**Description** :
+Créer un écran de génération de rapports pour les gestionnaires.
+
+**Tâches** :
+- [ ] Page `/admin/rapports` (gestionnaire/admin)
+- [ ] Sélection type de rapport (utilisateurs, validations, synthèse)
+- [ ] Filtres (date, statut, rôle)
+- [ ] Prévisualisation
+- [ ] Téléchargement (CSV/PDF)
+
+**Justification report Phase 2** :
+- Pas prioritaire pour MVP
+- Nécessite données réelles
+
+---
+
+## 💾 Sauvegarde & Restauration
+
+### Ticket P2-10 : [Infra] Script backup PostgreSQL automatique
+**Estimation** : 3h  
+**Labels** : `infra`, `phase-2`, `backup`
+
+**Description** :
+Créer un script de sauvegarde automatique de la base de données.
+
+**Tâches** :
+- [ ] Script `backup.sh` avec `pg_dump`
+- [ ] Compression (gzip)
+- [ ] Rotation (garder 30 derniers jours)
+- [ ] Cron job quotidien (3h du matin)
+- [ ] Notification email en cas d'échec
+- [ ] Tests restauration
+
+**Justification report Phase 2** :
+- Pas bloquant pour développement
+- Backup manuel possible en phase test
+- À faire avant mise en production
+
+---
+
+### Ticket P2-11 : [Doc] Guide sauvegarde & restauration
+**Estimation** : 3h  
+**Labels** : `documentation`, `phase-2`, `backup`
+
+**Description** :
+Documenter les procédures de sauvegarde et restauration pour les admins sys.
+
+**Tâches** :
+- [ ] Procédure sauvegarde manuelle
+- [ ] Procédure restauration
+- [ ] Configuration cron
+- [ ] Troubleshooting
+- [ ] Exemples de commandes
+- [ ] Checklist pré-restauration
+
+**Justification report Phase 2** :
+- Documentation technique, pas bloquante pour MVP
+- À faire avant mise en production
+
+---
+
+## 📚 Documentation utilisateur
+
+### Ticket P2-12 : [Doc] Guide utilisateur Gestionnaire
+**Estimation** : 4h  
+**Labels** : `documentation`, `phase-2`, `formation`
+
+**Description** :
+Rédiger le guide utilisateur pour les gestionnaires.
+
+**Tâches** :
+- [ ] Connexion et première utilisation
+- [ ] Consultation des demandes
+- [ ] Validation/Refus de comptes
+- [ ] Gestion des paramètres
+- [ ] FAQ gestionnaire
+- [ ] Captures d'écran
+
+**Justification report Phase 2** :
+- Formation présentiel prioritaire pour premiers utilisateurs
+- Documentation nécessaire pour scalabilité
+
+---
+
+### Ticket P2-13 : [Doc] Guide utilisateur Parent/AM
+**Estimation** : 4h  
+**Labels** : `documentation`, `phase-2`, `formation`
+
+**Description** :
+Rédiger le guide utilisateur pour les parents et assistantes maternelles.
+
+**Tâches** :
+- [ ] Inscription étape par étape
+- [ ] Création du mot de passe
+- [ ] Connexion
+- [ ] Utilisation de l'application
+- [ ] FAQ parent/AM
+- [ ] Captures d'écran
+
+**Justification report Phase 2** :
+- Formation présentiel prioritaire
+- Documentation nécessaire pour scalabilité
+
+---
+
+### Ticket P2-14 : [Doc] Vidéos tutoriels
+**Estimation** : 4h  
+**Labels** : `documentation`, `phase-2`, `formation`, `video`
+
+**Description** :
+Créer des vidéos tutoriels pour les utilisateurs.
+
+**Tâches** :
+- [ ] Vidéo "Inscription parent" (3-5 min)
+- [ ] Vidéo "Inscription AM" (3-5 min)
+- [ ] Vidéo "Validation comptes gestionnaire" (3-5 min)
+- [ ] Vidéo "Configuration initiale admin" (5-7 min)
+- [ ] Hébergement (YouTube privé ou serveur)
+
+**Justification report Phase 2** :
+- Pas bloquant pour MVP
+- Utile pour scalabilité et autonomie utilisateurs
+
+---
+
+## 🎨 Améliorations UX
+
+### Ticket P2-15 : [Frontend] Mode sombre
+**Estimation** : 3h  
+**Labels** : `frontend`, `phase-2`, `ux`
+
+**Description** :
+Ajouter un mode sombre à l'application.
+
+**Tâches** :
+- [ ] Thème sombre (couleurs, contrastes)
+- [ ] Toggle mode clair/sombre
+- [ ] Sauvegarde préférence utilisateur
+- [ ] Adaptation tous les écrans
+
+**Justification report Phase 2** :
+- Nice-to-have, pas bloquant
+- Améliore confort utilisateur
+
+---
+
+### Ticket P2-16 : [Frontend] Notifications push (optionnel)
+**Estimation** : 4h  
+**Labels** : `frontend`, `phase-2`, `ux`, `notifications`
+
+**Description** :
+Ajouter des notifications push pour les événements importants.
+
+**Tâches** :
+- [ ] Service Worker (PWA)
+- [ ] Notification "Compte validé"
+- [ ] Notification "Nouveau message" (si messagerie)
+- [ ] Gestion permissions
+- [ ] Paramètres notifications
+
+**Justification report Phase 2** :
+- Nice-to-have, pas bloquant
+- Nécessite PWA ou app mobile
+
+---
+
+### Ticket P2-17 : [Frontend] Accessibilité (WCAG 2.1)
+**Estimation** : 3h  
+**Labels** : `frontend`, `phase-2`, `ux`, `a11y`
+
+**Description** :
+Améliorer l'accessibilité de l'application (conformité WCAG 2.1).
+
+**Tâches** :
+- [ ] Audit accessibilité (Lighthouse, axe)
+- [ ] Correction contrastes
+- [ ] Attributs ARIA
+- [ ] Navigation clavier
+- [ ] Lecteur d'écran (test)
+
+**Justification report Phase 2** :
+- Amélioration continue
+- Pas bloquant pour MVP
+- Important pour collectivités (obligation légale)
+
+---
+
+## 📋 Priorisation Phase 2
+
+### Priorité Haute (à faire en premier)
+1. **Sauvegarde & Restauration** (Tickets P2-10, P2-11) → Avant mise en production
+2. **Statistiques** (Tickets P2-06, P2-07) → Argument de vente
+3. **Documentation utilisateur** (Tickets P2-12, P2-13) → Scalabilité
+
+### Priorité Moyenne
+4. **RGPD avancé** (Tickets P2-01, P2-02, P2-03) → Conformité
+5. **Reporting** (Tickets P2-08, P2-09) → Utile pour gestionnaires
+
+### Priorité Basse
+6. **Monitoring avancé** (Tickets P2-04, P2-05) → Nice-to-have
+7. **Améliorations UX** (Tickets P2-15, P2-16, P2-17) → Confort
+
+---
+
+## 🚀 Critères de passage en Phase 2
+
+La Phase 2 peut commencer quand :
+- ✅ Phase 1 terminée (61 tickets)
+- ✅ Application déployée en production (au moins 1 collectivité)
+- ✅ Utilisateurs réels (au moins 10 comptes validés)
+- ✅ Feedback terrain collecté
+- ✅ Bugs critiques corrigés
+
+---
+
+## 📊 Estimation globale Phase 2
+
+**Total** : 17 tickets  
+**Estimation** : ~58h de développement
+
+**Planning suggéré** :
+- Sprint 1 (2 semaines) : Sauvegarde + Statistiques (26h)
+- Sprint 2 (2 semaines) : Documentation + RGPD (24h)
+- Sprint 3 (1 semaine) : Reporting + Améliorations UX (8h)
+
+---
+
+**Dernière mise à jour** : 25 Novembre 2025  
+**Version** : 1.0  
+**Statut** : ✅ Backlog Phase 2 défini
+
@@ -0,0 +1,63 @@
+# Note Backend - Activation du module Gestionnaires (Ticket #92)
+
+## Problème
+L'endpoint `GET /api/v1/gestionnaires` renvoie une erreur **404 Not Found**.
+Cela est dû au fait que le `GestionnairesModule` n'est pas importé dans l'arbre des modules de l'application (via `UserModule` ou `AppModule`).
+
+## Solution de contournement actuelle (Frontend)
+Le frontend utilise actuellement l'endpoint générique `/api/v1/users` et filtre les résultats côté client pour ne garder que les utilisateurs ayant le rôle `gestionnaire`.
+*Fichier concerné : `frontend/lib/services/user_service.dart`*
+
+## Correctif Backend à appliquer
+Pour activer proprement l'endpoint dédié, il faut effectuer les modifications suivantes dans le backend :
+
+### 1. Importer le module dans `UserModule`
+Fichier : `backend/src/routes/user/user.module.ts`
+
+Ajouter `GestionnairesModule` dans les imports.
+
+```typescript
+import { GestionnairesModule } from './gestionnaires/gestionnaires.module';
+
+@Module({
+  imports: [
+    // ... autres imports
+    GestionnairesModule, // <--- AJOUTER ICI
+  ],
+  // ...
+})
+export class UserModule { }
+```
+
+### 2. Ajouter AuthModule dans `GestionnairesModule`
+Fichier : `backend/src/routes/user/gestionnaires/gestionnaires.module.ts`
+
+Le contrôleur utilise `AuthGuard`, qui dépend de `JwtService` fourni par `AuthModule`.
+
+```typescript
+import { AuthModule } from 'src/routes/auth/auth.module';
+
+@Module({
+  imports: [
+    TypeOrmModule.forFeature([Users]), 
+    AuthModule // <--- AJOUTER ICI
+  ],
+  controllers: [GestionnairesController],
+  providers: [GestionnairesService],
+})
+export class GestionnairesModule { }
+```
+
+## Après application du correctif
+Une fois ces modifications backend effectuées :
+1. Redémarrer le serveur backend.
+2. Modifier le frontend (`frontend/lib/services/user_service.dart`) pour utiliser à nouveau l'endpoint dédié :
+   ```dart
+   static Future<List<AppUser>> getGestionnaires() async {
+     final response = await http.get(
+       Uri.parse('${ApiConfig.baseUrl}${ApiConfig.gestionnaires}'),
+       headers: await _headers(),
+     );
+     // ...
+   }
+   ```
@@ -4,11 +4,13 @@ Ancienne documentation **déplacée** depuis `docs/` :

 | Fichier | Motif |
 |---------|--------|
-| `PROCEDURE-API-GITEA.md` | Doublon fonctionnel de
-  [**26_GITEA-API.md**](../../26_GITEA-API.md). |
-| `ARCHITECTURE_TECHNIQUE.md` | Non référencé ; la vue d’ensemble est dans
-  [**02_ARCHITECTURE.md**](../../02_ARCHITECTURE.md). |
-| `STATUS-APPLICATION.md` | Instantané daté ; non tenu comme doc vivante. |
+| `PROCEDURE-API-GITEA.md` | Doublon de [26_GITEA-API.md](../../26_GITEA-API.md) |
+| `ARCHITECTURE_TECHNIQUE.md` | Remplacé par [02_ARCHITECTURE.md](../../02_ARCHITECTURE.md) |
+| `STATUS-APPLICATION.md` | Instantané daté |
+| `23_LISTE-TICKETS.md` | Liste Phase 1 figée (avr. 2026) — suivi = Gitea + bilans |
+| `25_PHASE-2-BACKLOG.md` | Backlog technique figé — voir [05_VERSIONS…](../../05_VERSIONS-ET-MILESTONES.md) |
+| `SuperNounou_*` | CDC / SSS historiques |
+| `14_NOTE-BACKEND-CONFIG-SETUP.md` | Note ticket ponctuelle |
+| `92_NOTE-BACKEND-GESTIONNAIRES.md` | Note ticket ponctuelle |

-Après vérification qu’aucun lien externe ne pointe encore vers ces chemins, on
-peut **supprimer** ce sous-dossier ou ne garder que des pointeurs minimalistes.
+Mémoire produit des versions livrées : [29_BILAN-VERSION-0.1.0.md](../../29_BILAN-VERSION-0.1.0.md).
@@ -0,0 +1,116 @@
+# SuperNounou – SSS-001  
+## Spécification technique & opérationnelle unifiée  
+_Version 0.3 – 27 janvier 2026_
+
+---
+
+## 1. Objet  
+Centraliser tous les aspects **techniques et opérationnels** de la plateforme SuperNounou :  
+- Sauvegarde & Plan de Reprise d’Activité (PRA)  
+- Spécifications des API & intégrations  
+- Directives de déploiement, d’observabilité, de CI/CD
+
+## 2. Portée  
+Instances de production, pré-production et recette (Frontend, Backend, PostgreSQL, stockage objets), scripts d’installation, pipelines CI/CD, journaux et métriques.
+
+## 3. Références  
+- CDC SuperNounou V1.1  
+- ISO 27001 / ISO 22301 bonnes pratiques  
+- Politique sécurité DSI Enedis #SEC-POL-2024  
+- RGPD (2016/679)
+
+---
+
+# A – Sauvegarde & Plan de Reprise d’Activité
+
+### A.1 Architecture de sauvegarde  
+Schéma bloc, chiffrement AES-256 (KMS), réplication hors-site « Object Storage B ».
+
+### A.2 Stratégie de sauvegarde  
+
+| Type              | Fréquence   | Rétention | Support            |
+|-------------------|-------------|-----------|--------------------|
+| Incrémentale      | Quotidienne | 30 j      | Object Storage A   |
+| Complète          | Hebdomadaire| 6 mois    | Object Storage B   |
+| Export logique DB | Mensuelle   | 5 ans     | Stockage Glacier   |
+
+### A.3 PRA  
+RPO 24 h / RTO 4 h – scénarios : panne VM, corruption DB, sinistre DC – procédure détaillée + escalade.
+
+### A.4 Tests de restauration  
+Intégrale semestrielle, partielle trimestrielle – rapport d’audit et actions correctives.
+
+### A.5 Monitoring & alertes  
+Endpoint Prometheus `/metrics`, tableau Grafana « Backup status », alerte > 26 h sans backup.
+
+### A.6 Rôles  
+DevOps Lead (implémentation), DBA (tests restore), RSSI (audit).
+
+---
+
+# B – API & Intégrations
+
+### B.1 Conventions  
+OpenAPI 3 livré (`openapi.yaml`), version URL `/api/v1`, ISO 8601 dates.
+
+### B.2 Sécurité API  
+JWT Bearer (ou OAuth 2), TLS 1.3, rate-limit 100 req/min/IP, signature HMAC pour webhooks.
+
+### B.3 Exemples  
+Collection Postman, scripts cURL, guide « Appeler l’API ».
+
+### B.4 Intégrations futures  
+SSO LDAP/SAML, webhook `contract.validated`, export statistiques CSV.
+
+### B.5 Contrat de gestion des comptes d'administration
+- Création d'un administrateur avec un contrat minimal stable : `nom`, `prenom`, `email`, `password`, `telephone`.
+- Le rôle n'est jamais fourni par le frontend pour ce flux ; le backend impose `ADMINISTRATEUR`.
+- Les champs hors périmètre (adresse complète, photo, métadonnées métier non nécessaires) ne sont pas requis.
+- Les protections d'autorisation restent actives : un `SUPER_ADMIN` n'est pas supprimable et son identité (`nom`, `prenom`) est non modifiable.
+- Côté interface d'administration, les actions d'édition sont conditionnées aux droits ; les entrées non éditables restent consultables en lecture seule.
+
+---
+
+# C – Déploiement, CI/CD et Observabilité  *(nouveau)*
+
+### C.1 Déploiement communal (on-premise)  
+- **Objectif** : installation complète sur un serveur Linux ou VM en moins d’1 h.  
+- **Livrable** : solution de packaging **au choix** (Docker Compose, image VM, paquet .deb/.rpm).  
+- **Script update / rollback** : `update.sh` ou équivalent (backup ➜ pull ➜ migrate ➜ vérif ; rollback ≤ 5 min).  
+- **Config** : fichier `.env.sample` décrivant toutes les variables.
+
+### C.2 Environnements  
+- Developpement local (Docker Compose).  
+- Recette & Production (serveur communal).  
+- Les étudiants doivent décrire la procédure de bascule Recette → Prod.
+
+### C.3 Pipeline CI/CD  
+- Pipeline automatisé (tests unitaires + build image + scan CVE) déclenché à chaque merge.  
+- L’école fournit son propre dépôt Git/runner.  
+- Artifacts : images taguées, notes de version (`CHANGELOG.md`).
+
+### C.4 Observabilité & logs  
+- Journaux applicatifs JSON (timestamp UTC, level, traceId).  
+- Rotation/retention : 7 jours sur disque, 30 jours sur archive compressée.  
+- Export métriques Prometheus (`/metrics`) : latence API, nombre de sessions, files d’attente hors-ligne.  
+- Tableaux Grafana d’exemple inclus (`grafana_dashboard.json`).
+
+### C.5 SLA et performances (indicatifs)  
+- Disponibilité mensuelle cible : **≥ 98 %**.  
+- Temps de réponse P95 des opérations courantes : **< 500 ms**.  
+- Capacité test : **≈ 50 sessions simultanées** sans dégradation (> 1 s).
+
+---
+
+# D – Glossaire  
+AES-256, JWT, KMS, OpenAPI, RPO, RTO, rate-limit, HMAC, Compose, CI/CD…
+
+---
+
+# E – Historique des versions  
+
+| Version | Date       | Auteur           | Commentaire                     |
+|---------|------------|------------------|---------------------------------|
+| 0.1-draft | 2025-04-24 | Équipe projet    | Création du SSS unifié          |
+| 0.2       | 2025-04-24 | ChatGPT & Julien | Ajout déploiement / CI/CD / logs |
+| 0.3       | 2026-01-27 | Équipe projet    | Contrat admin harmonisé et règles d'autorisation |