5e5fcf4714
Réorganise la documentation du projet selon les principes du Domain-Driven Design (DDD) pour améliorer la cohésion, la maintenabilité et l'alignement avec l'architecture modulaire du backend. **Structure cible:** ``` docs/domains/ ├── README.md (Context Map) ├── _shared/ (Core Domain) ├── recommendation/ (Supporting Subdomain) ├── content/ (Supporting Subdomain) ├── moderation/ (Supporting Subdomain) ├── advertising/ (Generic Subdomain) ├── premium/ (Generic Subdomain) └── monetization/ (Generic Subdomain) ``` **Changements effectués:** Phase 1: Création de l'arborescence des 7 bounded contexts Phase 2: Déplacement des règles métier (01-19) vers domains/*/rules/ Phase 3: Déplacement des diagrammes d'entités vers domains/*/entities/ Phase 4: Déplacement des diagrammes flux/états/séquences vers domains/*/ Phase 5: Création des README.md pour chaque domaine Phase 6: Déplacement des features Gherkin vers domains/*/features/ Phase 7: Création du Context Map (domains/README.md) Phase 8: Mise à jour de mkdocs.yml pour la nouvelle navigation Phase 9: Correction automatique des liens internes (script fix-markdown-links.sh) Phase 10: Nettoyage de l'ancienne structure (regles-metier/, diagrammes/, features/) **Configuration des tests:** - Makefile: godog run docs/domains/*/features/ - scripts/generate-bdd-docs.py: features_dir → docs/domains **Avantages:** ✅ Cohésion forte: toute la doc d'un domaine au même endroit ✅ Couplage faible: domaines indépendants, dépendances explicites ✅ Navigabilité améliorée: README par domaine = entrée claire ✅ Alignement code/docs: miroir de backend/internal/ ✅ Onboarding facilité: exploration domaine par domaine ✅ Tests BDD intégrés: features au plus près des règles métier Voir docs/REFACTOR-DDD.md pour le plan complet.
257 lines
13 KiB
Gherkin
257 lines
13 KiB
Gherkin
# language: fr
|
|
|
|
@rgpd @administrative @dpo
|
|
Fonctionnalité: Conformité administrative RGPD (Registre, Breach, DPO)
|
|
|
|
# 13.8 - Registre des traitements (Article 30 RGPD)
|
|
|
|
@registre-traitements
|
|
Scénario: Registre des traitements en Markdown versionné Git
|
|
Étant donné que RoadWave doit tenir un registre des traitements
|
|
Quand on consulte la documentation
|
|
Alors un fichier `docs/rgpd/registre-traitements.md` existe
|
|
Et le fichier est versionné dans Git
|
|
Et l'historique des modifications est traçable via Git
|
|
Et chaque traitement est documenté dans une section dédiée
|
|
|
|
Scénario: Contenu obligatoire pour chaque traitement
|
|
Étant donné que le registre des traitements contient le traitement "Géolocalisation utilisateurs"
|
|
Quand on lit la section correspondante
|
|
Alors les informations suivantes sont présentes:
|
|
| information obligatoire | exemple |
|
|
| Nom du traitement | Géolocalisation utilisateurs |
|
|
| Finalité | Recommandation de contenu géolocalisé |
|
|
| Catégories de données | Coordonnées GPS, historique de position |
|
|
| Base légale | Consentement (Article 6.1.a RGPD) |
|
|
| Durée de conservation | 24h (précis), puis geohash anonymisé |
|
|
| Destinataires | Aucun tiers |
|
|
| Transferts hors UE | Aucun |
|
|
| Mesures de sécurité | TLS 1.3, anonymisation après 24h |
|
|
|
|
Plan du Scénario: Traitements documentés dans le registre
|
|
Étant donné que le registre des traitements est complet
|
|
Quand on liste tous les traitements
|
|
Alors le traitement "<traitement>" est documenté avec la base légale "<base_legale>"
|
|
|
|
Exemples:
|
|
| traitement | base_legale |
|
|
| Géolocalisation utilisateurs | Consentement |
|
|
| Historique d'écoute | Intérêt légitime |
|
|
| Création de contenu | Exécution du contrat |
|
|
| Analytics (Matomo) | Consentement |
|
|
| Paiements (Mangopay) | Exécution du contrat |
|
|
| Modération contenus | Intérêt légitime |
|
|
| Notifications push | Consentement |
|
|
|
|
Scénario: Review trimestrielle du registre
|
|
Étant donné que le registre des traitements existe
|
|
Quand on consulte l'historique Git
|
|
Alors une mise à jour est effectuée au moins tous les 3 mois
|
|
Et chaque mise à jour a un commit avec message explicite
|
|
Et un tag Git marque chaque review trimestrielle
|
|
Et les modifications sont traçables (auteur, date, changements)
|
|
|
|
Scénario: Mise à jour immédiate si nouveau traitement
|
|
Étant donné qu'une nouvelle fonctionnalité nécessite un traitement de données
|
|
Quand la fonctionnalité est développée
|
|
Alors le registre est mis à jour AVANT le déploiement en production
|
|
Et le nouveau traitement est documenté complètement
|
|
Et un commit Git enregistre l'ajout
|
|
Et le DPO valide la conformité RGPD du nouveau traitement
|
|
|
|
Scénario: Migration future vers interface admin PostgreSQL
|
|
Étant donné que RoadWave dépasse 100 000 utilisateurs
|
|
Quand la complexité du registre augmente
|
|
Alors une interface admin PostgreSQL est développée
|
|
Et le registre Markdown est migré vers la base de données
|
|
Et l'historique Git est conservé pour audit
|
|
Et l'interface permet une gestion plus efficace des traitements
|
|
|
|
# 13.9 - Notification violations de données (Breach)
|
|
|
|
@breach-notification
|
|
Scénario: Détection automatique d'événements critiques
|
|
Étant donné que le système de monitoring est actif
|
|
Quand un événement critique se produit
|
|
Alors une alerte est envoyée selon le type d'événement:
|
|
| événement | outil | alerte |
|
|
| Erreur backend critique | Sentry | Discord/Slack immédiat |
|
|
| Pic requêtes anormal | Grafana | Email équipe |
|
|
| Accès non autorisé DB | PostgreSQL logs | SMS fondateur |
|
|
| Authentification suspecte | Zitadel alerts | Email équipe |
|
|
Et les alertes permettent une réaction rapide
|
|
|
|
Scénario: Runbook de procédure breach disponible
|
|
Étant donné qu'une violation de données potentielle est détectée
|
|
Quand l'équipe consulte la documentation
|
|
Alors un runbook `docs/rgpd/procedure-breach.md` existe
|
|
Et le runbook contient une checklist 72h CNIL
|
|
Et chaque étape est clairement documentée
|
|
Et les contacts d'urgence sont listés
|
|
|
|
Scénario: Checklist 72h en cas de breach
|
|
Étant donné qu'une violation de données est confirmée
|
|
Quand l'équipe suit la procédure breach
|
|
Alors les étapes suivantes sont exécutées dans les délais:
|
|
| délai | étape |
|
|
| H+0 | Détection et confinement immédiat |
|
|
| H+24 | Évaluation gravité (données concernées, users impactés) |
|
|
| H+48 | Notification CNIL si risque pour utilisateurs |
|
|
| H+72 | Notification utilisateurs si risque élevé |
|
|
Et chaque étape est documentée pour audit
|
|
|
|
Scénario: Évaluation de la gravité du breach
|
|
Étant donné qu'une violation de données est détectée
|
|
Quand l'équipe évalue la gravité
|
|
Alors les critères suivants sont analysés:
|
|
| critère | exemple |
|
|
| Type de données concernées | Emails, mots de passe, GPS, etc. |
|
|
| Nombre d'utilisateurs impactés | 10, 100, 10000, etc. |
|
|
| Mesures de sécurité existantes | Chiffrement, hachage, anonymisation |
|
|
| Risque pour les droits et libertés | Faible, modéré, élevé |
|
|
Et si le risque est élevé, la CNIL est notifiée sous 72h
|
|
|
|
Scénario: Notification CNIL dans les 72h
|
|
Étant donné qu'un breach avec risque élevé est confirmé à 10:00 le 2025-01-20
|
|
Quand la gravité est évaluée comme nécessitant une notification
|
|
Alors la CNIL est notifiée avant 10:00 le 2025-01-23 (72h)
|
|
Et la notification contient:
|
|
| information |
|
|
| Nature de la violation |
|
|
| Données concernées |
|
|
| Nombre d'utilisateurs impactés |
|
|
| Conséquences probables |
|
|
| Mesures prises |
|
|
| Mesures de remédiation |
|
|
Et un email pré-rédigé (template) est utilisé pour gagner du temps
|
|
|
|
Scénario: Notification des utilisateurs si risque élevé
|
|
Étant donné qu'un breach impacte 5000 utilisateurs
|
|
Et que le risque est élevé (mots de passe non chiffrés exposés)
|
|
Quand la CNIL est notifiée
|
|
Alors les utilisateurs impactés sont notifiés dans les 72h
|
|
Et l'email contient:
|
|
"""
|
|
Objet: Alerte sécurité - Action requise
|
|
|
|
Bonjour,
|
|
|
|
Nous vous informons qu'une violation de données a affecté votre compte RoadWave.
|
|
|
|
Données concernées: [liste]
|
|
Date de l'incident: [date]
|
|
Actions prises: [mesures]
|
|
|
|
Action requise: Changez immédiatement votre mot de passe.
|
|
|
|
Pour toute question: security@roadwave.fr
|
|
"""
|
|
Et un lien de réinitialisation de mot de passe est inclus
|
|
|
|
Scénario: Aucune notification si risque faible
|
|
Étant donné qu'un breach mineur est détecté (logs techniques exposés, aucune donnée personnelle)
|
|
Quand l'équipe évalue la gravité
|
|
Alors le risque est jugé faible
|
|
Et aucune notification CNIL n'est requise (Article 33.1 RGPD)
|
|
Et aucune notification utilisateur n'est envoyée
|
|
Et un log interne est créé pour traçabilité
|
|
|
|
Scénario: Monitoring proactif pour éviter découverte tardive
|
|
Étant donné que Sentry et Grafana sont configurés
|
|
Quand un comportement anormal est détecté
|
|
Alors une alerte est envoyée en temps réel
|
|
Et l'équipe peut réagir avant qu'un breach majeur ne se produise
|
|
Et les logs sont analysés quotidiennement pour détecter des anomalies
|
|
Et cette approche proactive limite les risques de découverte tardive
|
|
|
|
# 13.10 - DPO (Délégué à la Protection des Données)
|
|
|
|
@dpo
|
|
Scénario: Fondateur = DPO temporaire (MVP)
|
|
Étant donné que RoadWave est en phase MVP
|
|
Et que l'entreprise a moins de 250 employés
|
|
Quand on vérifie l'obligation légale d'avoir un DPO
|
|
Alors le DPO n'est pas obligatoire selon le RGPD Article 37
|
|
Et le fondateur assume temporairement le rôle de DPO
|
|
Et le fondateur suit la formation CNIL gratuite (4h)
|
|
|
|
Scénario: Formation CNIL du DPO temporaire
|
|
Étant donné que le fondateur est DPO temporaire
|
|
Quand on vérifie sa formation
|
|
Alors le fondateur a suivi la formation CNIL en ligne (4h)
|
|
Et le fondateur a obtenu la certification "Atelier RGPD" (gratuit)
|
|
Et le certificat est conservé pour audit
|
|
Et la formation couvre:
|
|
| sujet |
|
|
| Principes fondamentaux du RGPD |
|
|
| Droits des personnes |
|
|
| Sécurité des données |
|
|
| Violations de données (breach) |
|
|
| Registre des traitements |
|
|
|
|
Scénario: Contact DPO publié et accessible
|
|
Étant donné que je consulte les mentions légales de RoadWave
|
|
Quand je cherche le contact du DPO
|
|
Alors l'email "dpo@roadwave.fr" est clairement affiché
|
|
Et cet email est également dans les CGU
|
|
Et le délai de réponse garanti est de 1 mois maximum (RGPD Article 12.3)
|
|
Et une adresse postale est également fournie
|
|
|
|
Scénario: Demande d'exercice de droits RGPD au DPO
|
|
Étant donné que je veux exercer mon droit d'accès à mes données
|
|
Quand j'envoie un email à dpo@roadwave.fr
|
|
Alors je reçois un accusé de réception dans les 48h
|
|
Et ma demande est traitée dans un délai maximum de 1 mois
|
|
Et si le délai dépasse 1 mois, je suis informé de la prolongation (max 2 mois supplémentaires)
|
|
Et la réponse est complète et conforme au RGPD
|
|
|
|
Scénario: Types de demandes gérées par le DPO
|
|
Étant donné que je contacte le DPO
|
|
Quand j'envoie une demande
|
|
Alors le DPO peut traiter les demandes suivantes:
|
|
| type de demande |
|
|
| Droit d'accès (Article 15) |
|
|
| Droit de rectification (Article 16) |
|
|
| Droit à l'effacement (Article 17) |
|
|
| Droit à la portabilité (Article 20) |
|
|
| Droit d'opposition (Article 21) |
|
|
| Plainte RGPD |
|
|
| Question sur le traitement des données |
|
|
Et chaque demande reçoit une réponse personnalisée
|
|
|
|
Scénario: Migration vers DPO externe si croissance
|
|
Étant donné que RoadWave dépasse 100 000 utilisateurs
|
|
Quand la charge de travail DPO augmente
|
|
Alors un DPO externe mutualisé est engagé
|
|
Et le coût est d'environ 200€/mois
|
|
Et le DPO externe a les certifications CNIL requises
|
|
Et un contrat de sous-traitance RGPD est signé
|
|
|
|
Scénario: Recrutement DPO interne si >10 employés
|
|
Étant donné que RoadWave a plus de 10 employés
|
|
Quand l'entreprise se structure
|
|
Alors un DPO interne peut être recruté
|
|
Et le DPO interne a une certification CNIL (AFCDP ou équivalent)
|
|
Et le DPO est indépendant et ne peut être licencié pour ses fonctions
|
|
Et le DPO a un accès direct à la direction
|
|
|
|
# Coût total conformité RGPD
|
|
|
|
Scénario: Récapitulatif des coûts RGPD
|
|
Étant donné que toutes les mesures RGPD sont en place
|
|
Quand on calcule le coût total mensuel
|
|
Alors le récapitulatif est le suivant:
|
|
| mesure | implémentation | coût |
|
|
| Consentement | Tarteaucitron.js + PostgreSQL | 0€ |
|
|
| Anonymisation GPS | Geohash PostGIS (24h) | 0€ |
|
|
| Export données | JSON+HTML+ZIP asynchrone | 0€ |
|
|
| Suppression compte | Grace period 30j + anonymisation | 0€ |
|
|
| Mode dégradé | GeoIP IP2Location + GPS optionnel | 0€ |
|
|
| Conservation | Purge auto 5 ans inactivité | 0€ |
|
|
| Analytics | Matomo self-hosted | ~5€/mois |
|
|
| Registre traitements | Markdown Git | 0€ |
|
|
| Breach detection | Sentry + Grafana + runbook | 0€ (< 5K events) |
|
|
| DPO | Fondateur formé CNIL | 0€ |
|
|
Et le coût total est d'environ 5€/mois
|
|
Et cette conformité est 100% opensource et maîtrisée
|