Privacy by design et by default : méthode RGPD
Traduire l’article 25 RGPD en exigences de conception, réglages par défaut et preuves de mise en œuvre pour vos projets numériques.
- Deux obligations complémentaires de l’article 25
- Commencer par les décisions métier
- Cahier des charges à adapter
- Vérifier les réglages réellement livrés
- Choisir un prestataire compatible avec les exigences
- Conserver des preuves et revoir les changements
- Appliquer la méthode à un portail de réparation
- Décider de la mise en service sur des preuves définies
- Ce qu’il faut retenir
- FAQ
Un service peut proposer un bouton de suppression tout en conservant ses exports indéfiniment. Il peut afficher une préférence de confidentialité sans l’appliquer aux liens de partage. La protection dès la conception et par défaut demande de vérifier le fonctionnement complet, pas seulement la présence d’options.
Deux obligations complémentaires de l’article 25
L’Art. 25(1) impose au responsable des mesures techniques et organisationnelles appropriées, lors de la détermination des moyens et pendant le traitement, pour rendre les principes du RGPD effectifs. Il tient compte des connaissances, coûts, caractéristiques du traitement et risques pour les personnes.
L’Art. 25(2) impose que, par défaut, seules les données nécessaires à chaque finalité spécifique soient traitées. Il vise la quantité, l’étendue des usages, la conservation et l’accessibilité. En particulier, les données ne doivent pas être accessibles à un nombre indéterminé de personnes sans intervention de la personne concernée. Source : RGPD, Art. 25(1) et (2).
| Conception | Paramétrage par défaut |
|---|---|
| Prévoir la suppression dans les données actives, copies et interfaces | Définir une durée adaptée au lieu de laisser « illimitée » |
| Concevoir plusieurs niveaux d’accès | Attribuer seulement l’accès nécessaire au nouvel utilisateur |
| Distinguer les usages et leurs conditions | Désactiver un usage optionnel nécessitant un choix tant que celui-ci n’existe pas |
| Permettre une réponse aux droits | Éviter qu’un export standard révèle inutilement des données de tiers |
Commencer par les décisions métier
Décrivez la finalité, les personnes, les données nécessaires, les destinataires et les durées avant de définir les écrans. Identifiez le fondement de chaque usage et les règles particulières applicables. Un choix technique ne corrige pas l’absence de base légale.
Exemple hypothétique : un portail d’assistance permet au client de joindre des documents. Le besoin est de résoudre une difficulté, pas de réunir tous ses documents personnels. Le projet peut limiter les types de pièces, afficher une consigne, restreindre les accès et fixer le sort des pièces après résolution.
La grille de minimisation des données permet de transformer cette description en choix de champs, de formats et d’accès.
Cahier des charges à adapter
| Exigence proposée | Critère d’acceptation concret |
|---|---|
| Collecte limitée | Chaque champ correspond à un usage défini ; les données facultatives sont clairement signalées |
| Information accessible | La personne trouve l’explication au moment où l’opération le justifie |
| Habilitations | Un nouveau compte ne voit que les données nécessaires à sa fonction |
| Conservation | Les catégories et points de départ sont configurés ; les exceptions sont justifiées et suivies |
| Droits | Une demande peut être exécutée dans les systèmes concernés sans exporter inutilement toute la base |
| Partage | Le périmètre et les destinataires sont visibles avant l’envoi ; les liens sont maîtrisés |
| Journaux | Les données techniques utiles sont distinguées des contenus privés inutiles |
| Sortie | Le contrat et le système permettent le renvoi ou la suppression selon les obligations applicables |
Ces critères sont des propositions de travail. Le RGPD n’impose pas universellement une API, un mécanisme de purge identique, un algorithme de chiffrement ou une durée de journalisation unique. L’objectif est de démontrer l’efficacité des mesures pour votre traitement.
Les liens de partage contenant des données personnelles illustrent les conséquences d’un paramètre d’accès trop large.
Vérifier les réglages réellement livrés
Ouvrez un compte neuf, créez un dossier et observez ce qui est visible sans action supplémentaire. Contrôlez aussi les espaces administrateurs, exports, notifications et connexions à d’autres outils. Comparez le fonctionnement au cahier des charges.
Une fonction protectrice disponible mais non activée ne prouve pas la protection par défaut. Inversement, le réglage adapté dépend de la finalité : le texte n’impose pas de désactiver absolument toute fonction qui utilise des données.
Lorsque le consentement est requis, il doit satisfaire les Art. 4(11) et 7. Une case précochée ne fournit pas l’acte positif attendu. Mais toute transmission à un tiers n’exige pas universellement un consentement : il faut qualifier la transmission et son fondement. Source : RGPD, Art. 7.
Choisir un prestataire compatible avec les exigences
L’Art. 25 vise le responsable du traitement. Un éditeur peut également être responsable pour certains usages ou sous-traitant pour d’autres, avec les obligations correspondant à ces rôles. Présenter tous les concepteurs comme extérieurs au RGPD serait donc inexact.
Au stade de l’achat, examinez les possibilités de configuration, les limites contractuelles et les garanties effectives. Le questionnaire d’évaluation des sous-traitants aide à identifier ce que l’outil permet réellement et les mesures restant à votre charge.
Les environnements de démonstration doivent eux aussi être conçus pour éviter les remontées accidentelles de données réelles : utilisez la fiche préparer une démo avec des données fictives.
Conserver des preuves et revoir les changements
Conservez la version du besoin, les arbitrages, les réglages observés, les écarts et leur correction. La documentation doit correspondre à l’outil en service, pas à une configuration ancienne.
L’AIPD est obligatoire lorsque les conditions de l’Art. 35 sont remplies ; elle peut structurer l’examen des risques. Elle ne remplace pas la mise en œuvre des mesures. Le DPO conseille et contrôle ; les décisions sur les finalités et les moyens appartiennent au responsable. En cas de modification du risque, la revue d’une AIPD après un changement de produit précise les éléments à reprendre.
Appliquer la méthode à un portail de réparation
Prenons une conception fictive : Atelier Aster souhaite ouvrir un portail pour suivre les réparations de mobilier de ses clients particuliers. L’équipe prévoit une fiche de dossier, des photographies du meuble et des messages. Le client doit pouvoir retrouver l’avancement ; seuls les professionnels chargés du dossier doivent accéder aux informations utiles. Il n’existe aucun besoin d’annuaire public des clients.
Le chef de projet distingue trois décisions. La gestion de la réparation utilise les données nécessaires à l’exécution du contrat avec le client, sur l’Art. 6(1)(b). Les mesures de sécurité et leur journalisation font l’objet d’une justification propre, notamment au regard de l’Art. 6(1)(f) et de leur nécessité. Une éventuelle publication promotionnelle des photographies serait un usage distinct, exclu de cette première version. Ces hypothèses ne dispensent pas de vérifier les données effectivement contenues dans chaque image. Source : bases légales, Art. 6(1).
Une photographie utile peut montrer le défaut du meuble. Elle n’a pas à révéler les enfants, les courriers ouverts ou l’ensemble du logement. Le portail propose une consigne avant le dépôt et permet de remplacer une image inadéquate. Le professionnel qui constate une pièce superflue suit une procédure de retrait ; la seule présence de la consigne ne suffit pas à limiter ce qui est conservé.
Fiche de conception P-38 renseignée
| Décision | Configuration prévue pour Aster | Vérification attendue |
|---|---|---|
| Ouverture d’un dossier | Référence de réparation et contact nécessaire ; pas de date de naissance demandée | Une création aboutit sans ce champ et aucun connecteur ne le réclame ensuite |
| Accès du client | Son dossier uniquement, sans annuaire des autres clients | Chaque compte fictif accède à son dossier, mais pas à celui de l’autre |
| Accès métier | Dossiers confiés à l’équipe concernée ; administration justifiée séparément | Un compte nouvellement créé n’hérite pas de tous les dossiers de l’atelier |
| Photographies | Dépôt privé rattaché à une réparation ; aucun affichage public | L’adresse d’une image ne permet pas sa lecture par une personne non autorisée |
| Notifications | Annonce d’une mise à jour, sans pièce jointe ni description détaillée | L’aperçu du message ne dévoile pas le contenu du dossier |
| Clôture | Retrait des accès devenus inutiles ; tri des documents selon leurs échéances | Une facture conservée ne maintient pas automatiquement toutes les images en usage courant |
| Nouvel usage | Aucune galerie commerciale dans la version initiale | Aucun export automatique vers le site promotionnel ou l’agence |
Cette fiche est une spécification proposée, pas le résultat d’un essai réellement exécuté. Elle fournit cependant des critères auxquels le développeur et le métier peuvent répondre autrement que par « conforme ». Chaque observation doit indiquer la version examinée et le profil utilisé.
Pourquoi le réglage le plus fermé n’est pas toujours la réponse
Le réparateur habilité a besoin de voir les photographies utiles sans demander au client une nouvelle autorisation pour chaque consultation nécessaire. Une conception qui exige cette démarche à chaque ouverture pourrait empêcher le service de fonctionner sans mieux protéger les personnes. La protection par défaut consiste ici à attribuer le bon périmètre, pas à rendre toutes les fonctions inutilisables.
À l’inverse, un accès public aux images sous prétexte que le client pourra ensuite le désactiver déplace sur lui la correction d’un réglage excessif. La conception doit rendre l’accès approprié dès le départ. Le client qui transmet une image pour obtenir une réparation ne demande pas, par cet acte seul, sa publication commerciale.
La même logique s’applique à la conservation. Une commande soldée peut laisser subsister des pièces qui répondent à une obligation légale ou à un besoin de preuve identifié. L’outil doit permettre de séparer ces pièces des échanges devenus inutiles, avec des accès adaptés. Un unique bouton « conserver tout le client » rend cette distinction difficile ; le cahier des charges doit prévoir un tri par catégories et des exceptions documentées.
Décider de la mise en service sur des preuves définies
Le chef de projet recueille les constats techniques, le métier vérifie les parcours, et le responsable prend la décision de lancement. Le dossier contient les exigences retenues, les observations correspondantes et les réserves, avec un responsable et une suite pour chacune. L’Art. 24(1) lie mise en œuvre et capacité à démontrer la conformité. Source : responsabilité du traitement.
Si l’isolation des dossiers n’est pas démontrée, l’ouverture aux clients n’est pas prête. Une formation des utilisateurs ou une phrase dans la notice ne compense pas cet accès non maîtrisé. Une version réduite peut être envisagée seulement si elle retire effectivement la fonction concernée et si son propre périmètre est suffisamment évalué. Conserver les mêmes flux en masquant un bouton ne réalise pas cette réduction.
Lors d’une mise à jour ultérieure, reprenez les décisions susceptibles de changer : un partage nouvellement public, un connecteur activé ou un export supplémentaire. La preuve de la version précédente reste utile à l’historique, mais elle ne démontre pas le comportement d’une fonction nouvelle. L’examen porte sur la modification réelle, sans devoir reconstruire artificiellement tout le dossier si le reste demeure inchangé.
Ce qu’il faut retenir
- La protection dès la conception se poursuit pendant toute la vie du traitement.
- Les réglages par défaut concernent quantité, usages, durée et accès.
- Vérifiez l’effet réel des mesures avec les équipes métier et techniques.
- Documentez les décisions, les observations et les corrections.
FAQ
Une petite organisation est-elle concernée ?
Oui, lorsqu’elle est responsable d’un traitement soumis au RGPD. Les mesures tiennent compte du contexte et des risques ; la taille ne supprime pas l’obligation.
Une AIPD est-elle obligatoire pour chaque projet ?
Non. Son obligation dépend de l’Art. 35 et des règles applicables. L’Art. 25 doit être respecté même lorsqu’aucune AIPD n’est requise.
Une politique de confidentialité suffit-elle comme preuve ?
Non. Elle informe ; elle ne démontre pas que les paramètres, accès ou suppressions fonctionnent. Conservez des éléments qui relient l’information au fonctionnement effectif.
Recevez nos analyses pratiques sur la conformité RGPD dans la newsletter.
Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.