RGPD Article 32 : obligations de sécurité technique pour les applications web

Article 32 : le texte que personne ne lit

L'article 32 du RGPD est court mais fondamental. Il impose au responsable de traitement de mettre en oeuvre des "mesures techniques et organisationnelles appropriées" pour garantir un niveau de sécurité adapté au risque. Mais que signifie "approprié" concrètement pour une application web ?

Obligation 1 : Pseudonymisation et chiffrement

Le texte cite explicitement la pseudonymisation et le chiffrement comme mesures techniques. En pratique, cela signifie :

Chiffrement en transit : TLS 1.2 minimum sur tous les échanges. Configurez HSTS pour forcer HTTPS. Vérifiez que votre certificat couvre tous les sous-domaines.

Chiffrement au repos : les données sensibles (santé, finance, identité) doivent être chiffrées en base. Supabase et Firebase proposent le chiffrement au repos par défaut, mais les exports et backups ne sont pas toujours chiffrés.

Pseudonymisation : séparez les données identifiantes (nom, email) des données métier (transactions, historique). Utilisez des identifiants techniques plutôt que des identifiants personnels.

Obligation 2 : Confidentialité, intégrité, disponibilité

Le triptyque classique de la sécurité de l'information.

Confidentialité : seules les personnes autorisées accèdent aux données. En Supabase, cela signifie des politiques RLS correctes. En Laravel, des middleware auth et des vérifications de rôle. La règle : chaque endpoint vérifie qui appelle ET si cette personne a le droit d'accéder à CETTE ressource.

Intégrité : les données ne peuvent pas être modifiées sans autorisation. Vérifiez que vos politiques RLS couvrent UPDATE et DELETE, pas seulement SELECT. Ajoutez des logs d'audit pour tracer les modifications.

Disponibilité : les données restent accessibles. Sauvegardes automatiques, plan de reprise d'activité, monitoring.

Obligation 3 : Capacité de restauration

L'article 32 exige la capacité de rétablir la disponibilité des données en cas d'incident. Cela implique des sauvegardes automatisées et testées, une procédure de restauration documentée, et un RTO (Recovery Time Objective) défini.

Obligation 4 : Tests réguliers

Le texte exige une "procédure visant à tester, à analyser et à évaluer régulièrement l'efficacité des mesures techniques". C'est la base légale de l'audit de sécurité. Un audit annuel minimum est la norme attendue par la CNIL.

Notre revue externe remplit cette obligation. Le rapport documente les tests effectués, les vulnérabilités trouvées, et les mesures recommandées.

Le piège de la "proportionnalité"

L'article 32 parle de mesures "appropriées" en tenant compte de l'état des connaissances, des coûts de mise en oeuvre, et de la nature des données. Une PME n'est pas tenue aux mêmes standards qu'une banque. Mais une startup qui traite des données de santé doit mettre en oeuvre des mesures proportionnées à la sensibilité de ces données.

La CNIL sanctionne quand les mesures sont manifestement insuffisantes par rapport au risque. Pas de RLS sur une table patients ? Pas de chiffrement sur des données de santé ? C'est une insuffisance manifeste.

Notre rôle

Notre audit évalue si vos mesures techniques sont "appropriées" au sens de l'article 32. Le rapport fournit une preuve de diligence et un plan de mise en conformité technique.