Chapitre 9.1 — L’obligation de sécurité (art. 32)

⏱️ TL;DR — L’article 32 t’impose des mesures de sécurité techniques et organisationnelles appropriées au risque. Retiens deux mots : appropriées (pas « maximales » ni « minimales » — proportionnées) et risque (pour les personnes, pas juste pour ton serveur). Le texte cite quatre propriétés à garantir : confidentialité, intégrité, disponibilité, résilience, plus des tests réguliers. C’est une obligation de moyens adaptés au contexte : une PME et une banque n’ont pas les mêmes moyens ni les mêmes risques. Et comme partout dans le RGPD, tu dois pouvoir démontrer que tu as raisonné — donc documenter tes mesures.

🎯 Objectifs

• Comprendre l’approche par le risque de l’article 32 et pourquoi il n’y a pas de checklist universelle.
• Nommer et distinguer les quatre propriétés : confidentialité, intégrité, disponibilité, résilience.
• Savoir que c’est une obligation de moyens appropriés, calibrée sur le risque pour les personnes.
• Relier la sécurité à la responsabilité (accountability) : documenter ses choix.
• Remplir un tableau risque → mesures pour un traitement donné.

« Appropriées » : le RGPD ne te donne pas de recette

C’est la première surprise. L’article 32 ne dit pas « chiffre en AES-256 », « impose 12 caractères », « garde les logs 6 mois ». Il dit : mets en œuvre des mesures appropriées au risque, compte tenu de l’état de l’art, des coûts, de la nature du traitement et des risques pour les droits et libertés des personnes.

Autrement dit, la bonne question n’est jamais « qu’est-ce que la loi m’oblige à cocher ? » mais « que se passe-t-il pour les personnes si ça tourne mal ? ». Une fuite d’adresses e-mail de newsletter et une fuite de dossiers de santé d’élèves n’appellent pas le même niveau de protection. Le curseur se règle sur le risque, pas sur ton confort technique.

💡 Réflexe — Avant de coder un traitement, fais l’analyse de risque du pauvre en trois questions : quelles données ? (sensibles, mineurs, masse ?), que craint la personne si ça fuit, si c’est modifié, si c’est perdu ?, quelles mesures réduisent ce risque à un niveau acceptable ? Ces trois questions sont l’article 32 en pratique. Une AIPD formelle (Partie 11) systématise cette démarche pour les traitements à risque élevé.

Les quatre propriétés à garantir

L’article 32 nomme explicitement les propriétés que tes mesures doivent viser. Un moyen mnémo : C-I-D-R.

La disponibilité et la résilience surprennent souvent les devs : on pense « sécurité = empêcher les fuites » (confidentialité). Mais perdre les données d’apprenants dans un incident sans sauvegarde, c’est aussi un manquement à la sécurité — et une violation de données au sens de la Partie 10 (une violation peut être une perte ou une destruction, pas seulement un accès non autorisé).

📚 Le texte — L’obligation de sécurité est à l’article 32 du RGPD (« sécurité du traitement »). Elle prolonge le 6e principe de l’article 5.1.f (« intégrité et confidentialité »). Le texte cite nommément le chiffrement et la pseudonymisation comme exemples de mesures, la garantie de la confidentialité, intégrité, disponibilité et résilience des systèmes, la capacité à rétablir l’accès après incident, et une procédure de test et d’évaluation réguliers de l’efficacité des mesures.

Obligation de moyens, pas de résultat

Point crucial et rassurant : l’article 32 est une obligation de moyens appropriés, pas de résultat. On ne te demande pas un système inviolable (ça n’existe pas). On te demande d’avoir mis en œuvre des mesures raisonnables au regard du risque et de l’état de l’art.

Concrètement : si tu subis une attaque malgré des mesures sérieuses et documentées, tu es dans une position très différente de celle où tu t’es fait pirater parce que les mots de passe étaient en clair et l’admin sans authentification. La CNIL et le juge regardent ce que tu avais mis en place, pas seulement le fait qu’il y ait eu incident.

C’est pour ça que PME et grande banque n’ont pas les mêmes obligations concrètes : l’« état de l’art » et les « coûts de mise en œuvre » entrent dans l’équation. Une banque manipule des risques financiers massifs et dispose de moyens en conséquence ; une petite EdTech doit viser des mesures proportionnées à ses données et à ses moyens — ce qui ne veut pas dire « rien », mais « les bons fondamentaux, bien faits ».

⚠️ Piège — « On est une petite structure, on n’a pas les moyens d’une grande boîte, donc on est tranquilles. » Faux raisonnement. La proportionnalité joue sur le niveau des mesures, pas sur leur existence. Chiffrer les mots de passe, mettre du HTTPS, cloisonner les accès et faire des sauvegardes n’a rien de coûteux : ce sont des fondamentaux attendus de tout le monde. La CNIL a sanctionné des structures modestes pour des manquements basiques (mots de passe faibles, absence de chiffrement).

La sécurité doit être prouvable

L’article 32 ne vit pas seul : il est adossé au principe de responsabilité (art. 5.2). Tu dois pouvoir démontrer que tu as choisi tes mesures en connaissance de cause. En clair : un raisonnement de sécurité non écrit est, aux yeux du régulateur, un raisonnement qui n’a pas eu lieu.

Ce que « documenter ses mesures » veut dire pour un dev :

• une politique de sécurité (même courte) qui liste les mesures et pourquoi ;
• la mention des mesures de sécurité dans le registre des traitements (art. 30) ;
• une trace des décisions (pourquoi argon2 plutôt que rien, pourquoi telle durée de logs, qui a accès à quoi) ;
• des tests et leur résultat (restauration de sauvegarde réussie le tant, revue des accès du tant).

🧭 Sur FormaCampus — FormaCampus traite des mineurs, des aménagements de handicap (donc de la santé, donnée sensible art. 9), des paiements et des journaux. Le risque pour les personnes est donc élevé sur plusieurs traitements. La plateforme ne peut pas se contenter du minimum : elle formalise une politique de sécurité, calibre ses mesures sur ces risques, et documente le tout pour être en mesure de le démontrer. Les chapitres 9.2 à 9.5 déclinent ces mesures ; ce chapitre pose la grille de décision.

🔒 Côté personne concernée — Quand un parent confie l’aménagement de handicap de son enfant, il n’a aucun moyen de vérifier ta base de données. Il te fait confiance pour que cette information ne fuite pas, ne soit pas altérée, et ne disparaisse pas. L’article 32, vu de son côté, c’est la promesse tenue que la donnée qu’il t’a confiée sera protégée à la hauteur de sa sensibilité — ni plus, ni moins, mais sérieusement.

Un tableau risque → mesures (exemple)

Voici la démarche appliquée à trois traitements de FormaCampus. C’est exactement ce genre de tableau qu’on attend de toi pour documenter l’article 32.

La colonne qui compte est la troisième : c’est elle qui justifie tout le reste. Change le risque, tu changes les mesures. C’est ça, raisonner par le risque.

✏️ Exercices

Exercice 1 — Calibre le curseur. Deux traitements : (a) une liste de diffusion d’une lettre d’information publique (juste des e-mails d’adultes qui se sont abonnés) ; (b) un registre d’incidents scolaires nominatifs mentionnant le comportement d’élèves mineurs. Lequel appelle les mesures les plus strictes, et pourquoi ?

Exercice 2 — Classe par propriété. Range chacune de ces mesures sous la bonne propriété C-I-D-R : (1) sauvegarde quotidienne testée ; (2) chiffrement de la base au repos ; (3) contrainte d’unicité + journal des modifications ; (4) bascule automatique sur un second serveur en cas de panne.

Exercice 3 — Justifie « obligation de moyens ». Une petite plateforme subit une intrusion. Cas A : mots de passe hachés avec argon2, MFA sur les admins, sauvegardes testées, politique de sécurité écrite. Cas B : mots de passe en clair, un seul compte admin partagé sans MFA, aucune sauvegarde. En quoi la position juridique diffère-t-elle, alors que l’incident a eu lieu dans les deux cas ?

🧠 Quiz de révision

Chapitre suivant : Mesures techniques — chiffrement en transit et au repos, pseudonymisation, hachage correct des mots de passe, gestion des secrets et sauvegardes.