Aller au contenu principal

DMV — Backlog de sécurisation V1 préprod

Date : 2026-06-07
Source : audit complémentaire sécurité / confidentialité / RBAC / résilience
Périmètre : api, dmv-public, dmv-workspace, exploitation DMV
Statut : backlog d’exécution priorisé

1. Objectif​

Ce document recense tout ce qu’il reste à faire pour amener DMV vers un niveau de sécurité, de confidentialité, de résilience et d’exploitabilité proche de 9/10 sur les domaines audités.

Il est conçu pour une exécution progressive, en environnement préprod utilisé :

  • ne pas casser le produit ;
  • ne pas lancer de refactor large non demandé ;
  • travailler par petits lots ;
  • valider après chaque phase ;
  • éviter toute régression fonctionnelle ou sécurité.

2. Règles d’exécution obligatoires​

  • Toujours traiter une seule phase à la fois.
  • Toujours commencer par audit du code concerné avant modification.
  • Ne pas modifier le design, l’UX ou le périmètre métier, sauf si la sécurité l’impose directement.
  • Ne pas renommer ou déplacer massivement des fichiers.
  • Ne pas ouvrir plusieurs chantiers de sécurité en parallèle si leurs effets se croisent.
  • Après chaque phase :
    • lancer les validations ciblées ;
    • vérifier les routes et permissions affectées ;
    • faire un commit isolé ;
    • documenter ce qui a été fait et ce qui reste.
  • Si une zone est ambiguë, s’arrêter, documenter, et ne pas improviser.

3. Priorités globales​

PrioritéObjectifStatut cible
P0Bloquer les risques sécurité / confidentialité incompatibles avec un pilote propreobligatoire avant montée de criticité
P1Rendre la plateforme exploitable, traçable et RGPD-opérationnellefortement recommandé avant ouverture plus large
P2Durcir l’architecture pour tendre vers un niveau 9/10 durablerecommandé après stabilisation

4. P0 — Correctifs immédiats​

P0-1 — Remplacer le rôle admin monolithique par un RBAC minimum viable​

Priorité : critique
Repos : api, puis dmv-workspace, dmv-public si interfaces concernées

Problème

  • Le backoffice Laravel repose aujourd’hui sur un accès global admin.
  • Cela concentre trop de pouvoir sur un seul rôle.

Travail attendu

  • Introduire au minimum les rôles suivants :
    • platform_admin
    • support_agent
    • content_moderator
    • billing_admin
    • municipal_manager
  • Définir les permissions minimales par module.
  • Remplacer les gates purement admin là où une permission plus fine est possible.
  • Conserver les comportements existants tant que la permission équivalente est bien accordée.

Fichiers de départ

  • api/app/Modules/Admin/Routes/api.php
  • api/app/Http/Middleware/EnsureUserIsAdmin.php
  • api/app/Modules/Identity/Models/UserRole.php
  • api/app/Modules/Identity/Services/ProfileService.php

Critères d’acceptation

  • Un agent support ne peut pas administrer les abonnements.
  • Un modérateur ne peut pas voir ou modifier les données de support.
  • Un gestionnaire mairie ne peut pas accéder au backoffice global.
  • Un platform_admin conserve l’accès complet.

Validation

  • tests permissions ciblés ;
  • vérification manuelle des routes admin ;
  • php artisan test ciblé sur auth/admin si disponible.

P0-2 — Sécuriser la fonction de réponse support​

Priorité : critique
Repos : dmv-public, potentiellement api

Problème

  • La fonction de réponse support authentifie un utilisateur Supabase, mais ne vérifie pas qu’il est autorisé à agir comme support.

Travail attendu

  • Bloquer toute réponse support pour un utilisateur non autorisé.
  • Vérifier le rôle via une source de vérité métier.
  • Conserver le flux existant de réponse une fois autorisé.

Fichiers de départ

  • dmv-public/supabase/functions/send-team-reply/index.ts
  • si nécessaire, ajouter une vérification via API Laravel dédiée

Critères d’acceptation

  • un simple utilisateur connecté ne peut jamais répondre à un thread support ;
  • seuls les rôles explicitement autorisés peuvent le faire ;
  • aucun message support ne part sans contrôle métier.

Validation

  • test manuel avec utilisateur non admin ;
  • test manuel avec rôle autorisé ;
  • revue des erreurs 401/403.

P0-3 — Mettre en place un audit log central​

Priorité : critique
Repos : api

Problème

  • Il n’existe pas de journal d’audit central fiable couvrant les actions sensibles.

Travail attendu

  • Créer une table audit_logs.
  • Créer un service unique d’écriture des audits.
  • Tracer au minimum :
    • attribution / retrait de rôle ;
    • lecture d’une fiche utilisateur via admin ;
    • lecture d’un thread support ;
    • réponse support ;
    • validation / rejet / annulation de claim ;
    • modification admin d’un acteur ;
    • modération / suppression / restauration ;
    • export / suppression de compte quand ils existeront.

Fichiers de départ

  • api/app/Modules/Admin/Services/AdminUserService.php
  • api/app/Modules/Admin/Services/AdminClaimService.php
  • api/app/Modules/Admin/Controllers/AdminMessagesController.php

Critères d’acceptation

  • chaque action sensible laisse une trace exploitable ;
  • acteur, utilisateur, admin auteur, action, contexte et timestamp sont conservés ;
  • l’historique claim ne dépend plus d’une table absente ou implicite.

Validation

  • tests feature ciblés ;
  • contrôle manuel des inserts d’audit ;
  • vérification lecture triée par date.

P0-4 — Tester réellement la restauration​

Priorité : critique
Repos : exploitation / dmv-docs

Problème

  • La sauvegarde est documentée mais la restauration n’est pas prouvée dans le flux courant.

Travail attendu

  • Exécuter un backup réel.
  • Restaurer sur un environnement non production.
  • Vérifier un jeu minimal de données critiques :
    • profils
    • acteurs
    • publications
    • claims
    • messages
    • rôles
  • Mesurer un temps de restauration.
  • Documenter précisément la procédure réelle.

Fichiers docs

  • dmv-docs/docs/11-devops/16-backup.md
  • dmv-docs/docs/09-data/14-backups.md

Critères d’acceptation

  • backup lisible prouvé ;
  • restauration réussie prouvée ;
  • runbook réaliste ;
  • limites explicites sur buckets et off-site.

P0-5 — Aligner la politique de confidentialité sur la réalité​

Priorité : critique
Repos : dmv-public, dmv-docs si besoin

Problème

  • Le texte juridique ne doit pas annoncer une réalité d’hébergement ou de traitement inexacte.

Travail attendu

  • Vérifier et corriger :
    • hébergement réel ;
    • transferts hors UE réels ;
    • durées réellement tenables ;
    • droits effectivement implémentés ;
    • contact et procédure d’exercice des droits.

Fichier de départ

  • dmv-public/app/confidentialite/page.tsx

Critères d’acceptation

  • plus d’écart manifeste entre le texte et l’architecture réelle ;
  • pas d’annonce de droit ou de rétention non soutenue par l’exploitation.

5. P1 — Mise à niveau forte​

P1-1 — Implémenter l’export utilisateur​

Repos : api, dmv-workspace

Travail attendu

  • Ajouter une route d’export compte.
  • Exporter au minimum :
    • profil ;
    • rôles ;
    • communes gérées ;
    • acteurs liés ;
    • publications de l’utilisateur ;
    • messages support liés ;
    • claims liées.

Critères

  • export générable à la demande ;
  • format exploitable ;
  • journal d’audit associé.

P1-2 — Implémenter suppression / anonymisation de compte​

Repos : api, dmv-workspace

Travail attendu

  • Ajouter un flux de demande de suppression ;
  • anonymiser ou supprimer selon contraintes métier et légales ;
  • conserver uniquement ce qui doit l’être ;
  • journaliser la demande et son exécution.

Critères

  • droit à l’effacement exécutable ;
  • aucune suppression sauvage d’objets métier partagés ;
  • impact métier maîtrisé.

P1-3 — Ajouter une vraie politique de rétention technique​

Repos : api, dmv-public, dmv-docs

Travail attendu

  • Définir puis implémenter la rétention sur :
    • claims
    • messages
    • contact_rate_limits
    • logs techniques
    • anciens tokens/sessions si concernés
  • Ajouter les jobs planifiés nécessaires.

Critères

  • la rétention ne repose plus sur un texte seul ;
  • les purges sont codées et documentées.

P1-4 — Corriger tous les formulaires publics sensibles​

Repos : dmv-public

Travail attendu

  • Vérifier que tout captcha affiché est bien validé côté backend.
  • Ajouter un contrôle backend réel sur :
    • contact équipe ;
    • contact acteur ;
    • proposition de fiche ;
    • claims si nécessaire.
  • Ajouter anti-duplicate simple quand pertinent.

Fichiers de départ

  • dmv-public/app/[commune]/AddActorModal.tsx
  • dmv-public/app/components/ContactActorModal.tsx
  • dmv-public/supabase/functions/contact-team/index.ts
  • dmv-public/supabase/functions/send-actor-message/index.ts

Critères

  • aucun flux sensible n’est protégé uniquement en frontend ;
  • les erreurs 429/403 sont propres ;
  • pas de régression UX visible hors message d’erreur normal.

P1-5 — Chiffrer les téléphones et données privées les plus sensibles​

Repos : api, éventuellement Supabase schema

Travail attendu

  • Chiffrer en priorité :
    • téléphone profil ;
    • téléphone claim ;
    • téléphone message support si conservé ;
    • futures préférences sensibles.

À ne pas chiffrer en V1 par défaut

  • email ;
  • prénom/nom ;
  • organisation ;
  • rattachement commune.

Critères

  • lecture toujours possible dans les flux métiers autorisés ;
  • fuite DB moins directement exploitable.

P1-6 — Masquer davantage les PII en backoffice​

Repos : api, interface consommatrice si nécessaire

Travail attendu

  • Réduire les listes admin qui exposent les emails/téléphones sans besoin direct.
  • Afficher uniquement le minimum utile par rôle.
  • Réserver l’accès au détail PII à un rôle explicitement autorisé.

Critères

  • support et modération ne voient pas plus que nécessaire ;
  • le backoffice respecte le principe de minimisation.

6. P2 — Durcissement vers un vrai 9/10​

P2-1 — RBAC complet par permissions et scopes​

  • introduire un système permissions/scopes durable ;
  • documenter la matrice rôle → permissions ;
  • couvrir aussi les futures apps PlayLoop, AssoSuite, Mairie.

P2-2 — MFA obligatoire pour rôles sensibles​

  • imposer MFA pour :
    • platform_admin
    • support_agent
    • billing_admin
    • futur security_admin

P2-3 — Sauvegarde off-site et PRA formalisé​

  • copie hors VPS ;
  • sauvegarde buckets ;
  • test de restauration périodique ;
  • RPO/RTO explicites.

P2-4 — Alerting sécurité et coût​

  • alerte sur :
    • pics IA ;
    • erreurs auth ;
    • échecs backup ;
    • activité admin anormale ;
    • volume claims/messages anormal.

P2-5 — Extension des tests RLS et frontières de confiance​

  • étendre les tests RLS aux autres tables sensibles ;
  • documenter ce qui est protégé par RLS et ce qui doit passer par Laravel ;
  • supprimer les zones ambiguës entre sécurité API et sécurité Supabase.

7. Ordre d’exécution recommandé​

  1. P0-2 — sécuriser send-team-reply
  2. P0-1 — RBAC minimum viable
  3. P0-3 — audit logs
  4. P0-5 — politique de confidentialité
  5. P0-4 — backup + restore prouvés
  6. P1-4 — formulaires publics sensibles
  7. P1-1 — export utilisateur
  8. P1-2 — suppression / anonymisation
  9. P1-3 — rétention
  10. P1-5 — chiffrement ciblé
  11. P1-6 — minimisation backoffice
  12. P2-* — durcissement long terme

8. Conditions de réussite​

Le chantier ne doit être considéré comme réussi que si :

  • chaque phase est isolée ;
  • les validations passent après chaque phase ;
  • aucun comportement métier existant n’est cassé ;
  • les accès refusés sont propres ;
  • les permissions sont testées ;
  • les documents de sécurité et d’exploitation sont mis à jour en même temps que le code.

9. Conditions de stop​

Le chantier doit être interrompu si :

  • une phase exige une refonte trop large non prévue ;
  • le comportement réel de production n’est pas clair ;
  • une dépendance Supabase / Cloudflare / Laravel n’est pas vérifiée ;
  • un doute subsiste sur la non-régression d’un flux utilisé en préprod.

Dans ce cas :

  • documenter l’écart ;
  • ne pas improviser ;
  • reprendre dans un lot séparé.