37c62206ad
Résolution des incohérences #10, #11, et #12 de l'analyse d'architecture. ## Phase 1 : Réorganisation Features BDD (Point #10 - RÉSOLU) - Créer structure features/{api,ui,e2e} - Déplacer 83 features en 3 catégories via git mv (historique préservé) - features/api/ : 53 features (tests API backend) - features/ui/ : 22 features (tests UI mobile) - features/e2e/ : 8 features (tests end-to-end) Domaines déplacés : - API : authentication, recommendation, rgpd-compliance, content-creation, moderation, monetisation, premium, radio-live, publicites - UI : audio-guides, navigation, interest-gauges, mode-offline, partage, profil, recherche - E2E : abonnements, error-handling ## Phase 2 : Mise à jour Documentation ### ADR-007 - Tests BDD - Ajouter section "Convention de Catégorisation des Features" - Documenter règles api/ui/e2e avec exemples concrets - Spécifier step definitions (backend Go, mobile Dart) ### ADR-024 - Stratégie CI/CD Monorepo (NOUVEAU) - Créer ADR dédié pour stratégie CI/CD avec path filters - Architecture workflows séparés (backend.yml, mobile.yml, shared.yml) - Configuration path filters détaillée avec exemples YAML - Matrice de déclenchement et optimisations (~70% gain temps CI) - Plan d'implémentation (~2h, reporté jusqu'au développement) ### ADR-016 - Organisation Monorepo - Simplifier en retirant section CI/CD détaillée - Ajouter référence vers ADR-024 pour stratégie CI/CD ### INCONSISTENCIES-ANALYSIS.md - Point #10 (Tests BDD synchronisés) : ✅ RÉSOLU - Catégorisation features implémentée - ADR-007 mis à jour avec convention complète - Point #11 (70/30 Split paiements) : ✅ ANNULÉ (faux problème) - ADR-009 et Règle 18 parfaitement cohérents - Documentation exhaustive existante (formule, SQL, comparaisons) - Point #12 (Monorepo path filters) : ⏸️ DOCUMENTÉ - Architecture CI/CD complète dans ADR-024 - Implémentation reportée (projet en phase documentation) - Métriques mises à jour : - MODERATE : 6/9 traités (4 résolus + 1 annulé + 1 documenté) - ADR à jour : 100% (19/19 avec ADR-024) ## Phase 3 : Validation - Structure features validée (api/ui/e2e, aucun répertoire restant) - Historique Git préservé (git mv, renommages détectés) - 83 features total (API: 53, UI: 22, E2E: 8) Closes: Point #10 (résolu), Point #11 (annulé), Point #12 (documenté) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
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
|