feat(bdd): réorganiser features en catégories api/ui/e2e et créer ADR-024
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>
This commit is contained in:
jpgiannetti
176
features/api/rgpd-compliance/anonymisation-gps.feature
Normal file
176
features/api/rgpd-compliance/anonymisation-gps.feature
Normal file
@@ -0,0 +1,176 @@
|
||||
# language: fr
|
||||
|
||||
@rgpd @anonymization @gps
|
||||
Fonctionnalité: Anonymisation des données GPS après 24h
|
||||
|
||||
# 13.2 - Geohash après 24h (conformité RGPD + CNIL)
|
||||
|
||||
Contexte:
|
||||
Étant donné que je suis un utilisateur avec le GPS activé
|
||||
Et que j'utilise l'application depuis plusieurs jours
|
||||
|
||||
Scénario: Conservation des données GPS précises pendant 24h
|
||||
Étant donné que j'écoute un contenu à la position GPS 48.8566, 2.3522 (Paris, Tour Eiffel)
|
||||
Et qu'il est 10:00 le 2025-01-20
|
||||
Quand l'événement d'écoute est enregistré en base de données
|
||||
Alors les coordonnées précises 48.8566, 2.3522 sont stockées
|
||||
Et le champ `anonymized` est à `false`
|
||||
Et le champ `created_at` contient "2025-01-20 10:00:00"
|
||||
Et ces données précises servent à la recommandation personnalisée
|
||||
|
||||
Scénario: Conversion en geohash après 24h
|
||||
Étant donné que j'ai écouté un contenu le 2025-01-20 à 10:00 à la position 48.8566, 2.3522
|
||||
Quand le job quotidien d'anonymisation s'exécute le 2025-01-21 à 02:00
|
||||
Alors les coordonnées précises sont converties en geohash précision 5
|
||||
Et le geohash correspond à une zone d'environ 5km²
|
||||
Et les coordonnées originales 48.8566, 2.3522 sont supprimées définitivement
|
||||
Et le champ `anonymized` passe à `true`
|
||||
Et il est impossible de retrouver la position précise d'origine
|
||||
|
||||
Scénario: Requête SQL d'anonymisation (PostGIS)
|
||||
Étant donné que le job quotidien d'anonymisation s'exécute
|
||||
Quand la requête SQL suivante est exécutée:
|
||||
"""sql
|
||||
UPDATE location_history
|
||||
SET location = ST_SetSRID(ST_GeomFromGeoHash(ST_GeoHash(location::geography, 5)), 4326)::geography,
|
||||
anonymized = true
|
||||
WHERE created_at < NOW() - INTERVAL '24 hours' AND anonymized = false;
|
||||
"""
|
||||
Alors toutes les positions vieilles de plus de 24h sont anonymisées
|
||||
Et le processus est automatique et irréversible
|
||||
Et les données sont conformes RGPD
|
||||
|
||||
Scénario: Précision du geohash niveau 5
|
||||
Étant donné qu'une position GPS est convertie en geohash précision 5
|
||||
Quand on analyse la zone couverte
|
||||
Alors la zone fait environ 5km² (4.9km × 4.9km)
|
||||
Et cette précision est suffisante pour des analytics agrégées
|
||||
Et cette précision ne permet pas d'identifier un individu (conformité CNIL)
|
||||
|
||||
Scénario: Exemple de conversion Paris
|
||||
Étant donné que ma position précise est 48.8566, 2.3522 (Tour Eiffel)
|
||||
Quand la conversion en geohash précision 5 est appliquée
|
||||
Alors le geohash généré est "u09wh"
|
||||
Et ce geohash couvre une zone de ~5km² autour de la Tour Eiffel
|
||||
Et toutes les positions dans cette zone partagent le même geohash
|
||||
Et il est impossible de distinguer deux utilisateurs dans cette zone
|
||||
|
||||
# Exception: Historique personnel
|
||||
|
||||
Scénario: Conservation de l'historique personnel utilisateur
|
||||
Étant donné que j'ai écouté des contenus aux positions suivantes:
|
||||
| date | heure | latitude | longitude | lieu |
|
||||
| 2025-01-15 | 08:30 | 48.8566 | 2.3522 | Paris |
|
||||
| 2025-01-16 | 14:00 | 43.6047 | 1.4442 | Toulouse |
|
||||
| 2025-01-17 | 19:00 | 45.7640 | 4.8357 | Lyon |
|
||||
Quand j'ouvre mon historique personnel dans "Profil > Mes trajets"
|
||||
Alors je vois mes trajets avec les positions précises intégrales
|
||||
Et ces données ne sont pas anonymisées tant que mon compte est actif
|
||||
Et seul moi peut accéder à ces données
|
||||
Et elles ne sont pas utilisées pour des analytics globales
|
||||
|
||||
Scénario: Anonymisation pour analytics globales uniquement
|
||||
Étant donné que RoadWave génère des analytics agrégées
|
||||
Quand l'équipe analyse les zones géographiques populaires
|
||||
Alors seules les données anonymisées (geohash) sont utilisées
|
||||
Et les positions précises de l'historique personnel ne sont jamais agrégées
|
||||
Et les heatmaps de trafic utilisent uniquement les geohash ~5km²
|
||||
|
||||
# Job quotidien automatique
|
||||
|
||||
Scénario: Planification du job d'anonymisation
|
||||
Étant donné que le système est en production
|
||||
Quand on consulte les jobs planifiés (cron)
|
||||
Alors un job "anonymize_gps_data" est configuré
|
||||
Et le job s'exécute tous les jours à 02:00 (heure creuse)
|
||||
Et le job traite toutes les positions vieilles de plus de 24h
|
||||
Et un log est généré pour traçabilité
|
||||
|
||||
Scénario: Exécution du job avec métriques
|
||||
Étant donné que le job d'anonymisation s'exécute le 2025-01-21 à 02:00
|
||||
Quand le job se termine
|
||||
Alors un rapport est généré avec:
|
||||
| métrique | valeur |
|
||||
| Nombre de positions traitées | 15420 |
|
||||
| Nombre de positions anonymisées| 15420 |
|
||||
| Durée d'exécution | 3.5s |
|
||||
| Erreurs | 0 |
|
||||
Et le rapport est loggé dans Sentry/Grafana
|
||||
Et une alerte est envoyée si le job échoue
|
||||
|
||||
Scénario: Performances du job d'anonymisation
|
||||
Étant donné que 100 000 positions doivent être anonymisées
|
||||
Quand le job s'exécute
|
||||
Alors le traitement se fait en moins de 30 secondes
|
||||
Et la requête PostGIS est optimisée avec index
|
||||
Et aucun impact sur les performances de l'application en production
|
||||
|
||||
# Vraie anonymisation RGPD
|
||||
|
||||
Scénario: Impossibilité de réidentification
|
||||
Étant donné qu'une position a été anonymisée en geohash "u09wh"
|
||||
Quand un attaquant tente de retrouver la position précise d'origine
|
||||
Alors il est impossible de déterminer la position exacte
|
||||
Et des milliers de positions précises correspondent au même geohash
|
||||
Et il n'y a aucune traçabilité vers la position originale
|
||||
Et cette anonymisation est irréversible
|
||||
|
||||
Scénario: Conformité CNIL - données véritablement anonymisées
|
||||
Étant donné que les positions sont converties en geohash précision 5
|
||||
Quand un auditeur CNIL vérifie la conformité
|
||||
Alors les données sont considérées comme véritablement anonymisées
|
||||
Et elles ne sont plus considérées comme des données personnelles
|
||||
Et aucun consentement n'est requis pour leur traitement analytique
|
||||
Et elles peuvent être conservées indéfiniment
|
||||
|
||||
# Analytics agrégées autorisées
|
||||
|
||||
Scénario: Heatmap de trafic avec données anonymisées
|
||||
Étant donné que RoadWave génère une heatmap des zones populaires
|
||||
Quand on analyse les données utilisées
|
||||
Alors seules les positions anonymisées (geohash) sont agrégées
|
||||
Et la heatmap montre des zones de ~5km²
|
||||
Et aucune position précise n'est révélée
|
||||
Et cette analyse ne nécessite pas de consentement utilisateur (données anonymes)
|
||||
|
||||
Scénario: Statistiques géographiques par département
|
||||
Étant donné que RoadWave analyse l'utilisation par département
|
||||
Quand les statistiques sont générées
|
||||
Alors les données anonymisées sont agrégées par département
|
||||
Et les résultats montrent: "Paris (75): 12 500 écoutes, Lyon (69): 8 300 écoutes"
|
||||
Et aucune donnée personnelle n'est révélée
|
||||
Et les statistiques sont RGPD-compliant
|
||||
|
||||
# PostGIS natif - 0€
|
||||
|
||||
Scénario: Coût de la solution d'anonymisation
|
||||
Étant donné que PostGIS est utilisé pour l'anonymisation GPS
|
||||
Quand on calcule le coût de la solution
|
||||
Alors le coût est de 0€ (PostGIS inclus dans PostgreSQL)
|
||||
Et aucune librairie tierce n'est nécessaire
|
||||
Et la solution est entièrement maîtrisée (self-hosted)
|
||||
|
||||
# Cas limites
|
||||
|
||||
Scénario: Anonymisation respecte les positions en cours de session
|
||||
Étant donné que je suis en train d'écouter du contenu actuellement
|
||||
Et que certaines de mes positions ont plus de 24h
|
||||
Quand le job d'anonymisation s'exécute
|
||||
Alors mes positions de plus de 24h sont anonymisées
|
||||
Mais ma position actuelle (session en cours) reste précise
|
||||
Et la recommandation continue de fonctionner normalement
|
||||
|
||||
Scénario: Suppression de compte et anonymisation GPS
|
||||
Étant donné que je demande la suppression de mon compte
|
||||
Quand le compte est supprimé (après grace period de 30j)
|
||||
Alors toutes mes positions GPS (précises et anonymisées) sont supprimées
|
||||
Et mon historique personnel de trajets est supprimé
|
||||
Et aucune donnée GPS ne subsiste, même anonymisée
|
||||
|
||||
Scénario: Export de données avant anonymisation
|
||||
Étant donné que je demande un export de mes données
|
||||
Et que certaines de mes positions ont été anonymisées
|
||||
Quand l'export est généré
|
||||
Alors les positions précises de mon historique personnel sont incluses
|
||||
Mais les positions déjà anonymisées (>24h, analytics) apparaissent en geohash
|
||||
Et l'export précise quelles données ont été anonymisées et pourquoi
|
||||
Reference in New Issue
Block a user