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>
187 lines
9.2 KiB
Gherkin
187 lines
9.2 KiB
Gherkin
# language: fr
|
|
|
|
@rgpd @consent
|
|
Fonctionnalité: Gestion du consentement RGPD
|
|
|
|
Contexte:
|
|
Étant donné que je suis un nouvel utilisateur
|
|
Et que j'accède à l'application pour la première fois
|
|
|
|
# 13.1 - Gestion du consentement avec Tarteaucitron.js + PostgreSQL
|
|
|
|
Scénario: Affichage du banner de consentement au premier lancement web
|
|
Étant donné que j'accède à l'application web pour la première fois
|
|
Quand la page se charge
|
|
Alors un banner RGPD Tarteaucitron.js s'affiche
|
|
Et le banner est en français
|
|
Et le banner propose les options suivantes:
|
|
| option | description |
|
|
| Tout accepter | Active tous les consentements |
|
|
| Tout refuser | Refuse tous les consentements optionnels |
|
|
| Personnaliser | Ouvre le panneau de personnalisation |
|
|
Et le banner est customisé aux couleurs de RoadWave
|
|
|
|
Scénario: Granularité des consentements
|
|
Étant donné que le banner RGPD est affiché
|
|
Quand je clique sur "Personnaliser"
|
|
Alors je vois les catégories de consentements suivantes:
|
|
| catégorie | type | requis |
|
|
| Fonctionnel | Nécessaire | oui |
|
|
| Analytique | Optionnel | non |
|
|
| Marketing | Optionnel | non |
|
|
Et chaque catégorie a une description claire de son usage
|
|
Et je peux accepter ou refuser chaque catégorie individuellement
|
|
|
|
Scénario: Consentement géolocalisation précise - obligatoire
|
|
Étant donné que je suis sur l'application mobile
|
|
Et que l'onboarding est terminé
|
|
Quand l'application a besoin d'accéder à ma position précise
|
|
Alors un écran de demande de consentement s'affiche
|
|
Et le message explique clairement l'usage:
|
|
"""
|
|
RoadWave utilise votre position GPS pour vous proposer du contenu audio géolocalisé pertinent.
|
|
Vos données sont anonymisées après 24h.
|
|
"""
|
|
Et je peux accepter ou refuser
|
|
Et si je refuse, l'application bascule en mode dégradé (GeoIP uniquement)
|
|
|
|
Scénario: Double consentement GPS - banner app + permission OS
|
|
Étant donné que je veux activer la géolocalisation précise
|
|
Quand j'accepte le consentement dans l'application
|
|
Alors l'application demande également la permission au système d'exploitation
|
|
Et sur iOS, la popup système s'affiche: "Autoriser RoadWave à accéder à votre position ?"
|
|
Et sur Android, la popup système s'affiche avec les options "Toujours autoriser / Autoriser seulement pendant l'utilisation / Refuser"
|
|
Et les deux consentements (app + OS) doivent être acceptés pour activer le GPS précis
|
|
|
|
# Historique des consentements - PostgreSQL backend
|
|
|
|
Scénario: Enregistrement du consentement en base de données
|
|
Étant donné que j'ai accepté les consentements suivants:
|
|
| type | accepté |
|
|
| Fonctionnel | oui |
|
|
| Analytique | oui |
|
|
| Marketing | non |
|
|
| GPS précis | oui |
|
|
Quand je valide mes choix
|
|
Alors un enregistrement est créé dans la table `user_consents`
|
|
Et l'enregistrement contient les champs suivants:
|
|
| champ | valeur |
|
|
| user_id | [mon ID utilisateur] |
|
|
| consent_type | fonctionnel / analytique / gps |
|
|
| version | 1 |
|
|
| accepted | true / false |
|
|
| timestamp | [date et heure exacte] |
|
|
Et chaque type de consentement a un enregistrement séparé
|
|
|
|
Scénario: Versioning des consentements
|
|
Étant donné que j'ai accepté le consentement "Analytique" version 1 le 2025-01-01
|
|
Et que les CGU sont mises à jour le 2025-06-01
|
|
Quand je me connecte après la mise à jour
|
|
Alors un nouveau consentement version 2 m'est demandé
|
|
Et mon ancien consentement version 1 reste dans l'historique
|
|
Et je dois accepter la nouvelle version pour continuer à utiliser les analytics
|
|
|
|
Scénario: Historique complet conservé pour preuve légale
|
|
Étant donné que j'ai modifié mes consentements plusieurs fois:
|
|
| date | consent_type | accepted | version |
|
|
| 2025-01-01 | Analytique | oui | 1 |
|
|
| 2025-03-15 | Analytique | non | 1 |
|
|
| 2025-06-01 | Analytique | oui | 2 |
|
|
Quand un auditeur CNIL consulte mon historique de consentements
|
|
Alors tous les enregistrements sont conservés
|
|
Et l'historique prouve que chaque consentement a été donné librement
|
|
Et les timestamps permettent de prouver la conformité à tout moment
|
|
|
|
# Consentements requis vs optionnels
|
|
|
|
Scénario: Consentement analytique - optionnel
|
|
Étant donné que je refuse le consentement "Analytique"
|
|
Quand j'utilise l'application
|
|
Alors aucun cookie Matomo `_pk_id` n'est déposé
|
|
Et aucune donnée d'usage n'est envoyée à Matomo
|
|
Et l'application fonctionne normalement sans analytics
|
|
|
|
Scénario: Consentement notifications push - optionnel
|
|
Étant donné que je refuse le consentement "Notifications push"
|
|
Quand un créateur que je suis publie un nouveau contenu
|
|
Alors je ne reçois pas de notification push
|
|
Mais je peux voir le nouveau contenu dans l'application
|
|
Et l'application fonctionne normalement
|
|
|
|
Scénario: Consentement GPS précis - requis pour fonctionnalités géo
|
|
Étant donné que je refuse le consentement "GPS précis"
|
|
Quand j'utilise l'application
|
|
Alors je peux accéder aux contenus nationaux
|
|
Mais les contenus géolocalisés précis (Ancré, Contextuel) ne sont pas disponibles
|
|
Et les audio-guides nécessitent l'activation du GPS
|
|
Et un banner permanent me rappelle que l'activation du GPS améliore l'expérience
|
|
|
|
# Modification des consentements
|
|
|
|
Scénario: Révocation d'un consentement depuis les paramètres
|
|
Étant donné que j'ai accepté le consentement "Analytique"
|
|
Et que j'utilise l'application depuis 3 mois
|
|
Quand j'ouvre "Paramètres > Confidentialité > Gérer mes consentements"
|
|
Alors je vois la liste de tous mes consentements actuels
|
|
Et je peux révoquer le consentement "Analytique"
|
|
Quand je révoque le consentement
|
|
Alors un nouvel enregistrement est créé avec `accepted = false`
|
|
Et le cookie Matomo est supprimé immédiatement
|
|
Et les analytics sont désactivées à partir de ce moment
|
|
|
|
Scénario: Acceptation d'un consentement précédemment refusé
|
|
Étant donné que j'avais refusé le consentement "GPS précis"
|
|
Quand j'ouvre "Paramètres > Confidentialité > Gérer mes consentements"
|
|
Et que je clique sur "Activer la géolocalisation précise"
|
|
Alors un nouvel enregistrement est créé avec `accepted = true`
|
|
Et la permission OS est demandée si ce n'est pas déjà fait
|
|
Et l'application bascule en mode géolocalisation précise
|
|
Et les contenus géolocalisés deviennent disponibles immédiatement
|
|
|
|
# Preuves légales pour contrôle CNIL
|
|
|
|
Scénario: Export de l'historique des consentements pour audit
|
|
Étant donné qu'un contrôle CNIL est en cours
|
|
Quand l'équipe RoadWave exporte l'historique des consentements
|
|
Alors l'export contient pour chaque utilisateur:
|
|
| champ | description |
|
|
| user_id | ID anonymisé |
|
|
| consent_type | Type de consentement |
|
|
| version | Version des CGU/consentement |
|
|
| accepted | Accepté ou refusé |
|
|
| timestamp | Date et heure exacte |
|
|
| ip_address | IP (anonymisée) au moment du consentement |
|
|
| user_agent | Navigateur/app utilisé |
|
|
Et l'export est au format CSV pour analyse
|
|
Et les données prouvent la conformité RGPD
|
|
|
|
Scénario: Conformité recommandations CNIL
|
|
Étant donné que le système de consentement est implémenté
|
|
Quand un auditeur CNIL vérifie la conformité
|
|
Alors le système respecte les critères suivants:
|
|
| critère CNIL | respecté |
|
|
| Consentement libre | oui |
|
|
| Consentement spécifique (granulaire) | oui |
|
|
| Consentement éclairé (information claire) | oui |
|
|
| Consentement univoque (action positive) | oui |
|
|
| Révocable à tout moment | oui |
|
|
| Preuve du consentement conservée | oui |
|
|
|
|
# Opensource et self-hosted
|
|
|
|
Scénario: Tarteaucitron.js self-hosted
|
|
Étant donné que l'application web utilise Tarteaucitron.js
|
|
Quand je consulte les sources JavaScript chargées
|
|
Alors le script Tarteaucitron.js est hébergé sur les serveurs RoadWave
|
|
Et aucun script tiers (CDN externe) n'est chargé
|
|
Et le code source de Tarteaucitron.js est vérifiable
|
|
Et aucune donnée n'est envoyée à un tiers lors de l'affichage du banner
|
|
|
|
Scénario: Coût de la solution - 0€
|
|
Étant donné que Tarteaucitron.js est opensource
|
|
Et que PostgreSQL est utilisé pour le backend
|
|
Quand on calcule le coût de la solution de consentement
|
|
Alors le coût est de 0€
|
|
Et la solution est entièrement maîtrisée (self-hosted)
|
|
Et aucune dépendance à un service SaaS tiers
|