Privacy by design : intégrer le RGPD dans le cycle de développement

Un directeur technique peut lire dix fois l'article 25 du RGPD sans savoir quoi en faire lundi matin. Le texte parle de mesures techniques et organisationnelles appropriées, pas de schéma de base de données, de valeur par défaut d'un interrupteur ni de jeu de test. C'est pourtant là que la conformité se gagne ou se perd : la CNIL a prononcé 800 000 euros d'amende contre un éditeur parce que fermer la fenêtre de son application ne coupait pas le micro, et 1,5 million contre un autre parce que son outil d'export ne permettait pas de choisir les colonnes. Cet article traduit le privacy by design en tickets, en critères de definition of done et en points de revue de code.

Ce que l'article 25 exige vraiment, et pourquoi ce n'est pas une obligation de moyens vague

L'article 25, paragraphe 1, du RGPD impose des mesures techniques et organisationnelles appropriées, telles que la pseudonymisation, destinées à mettre en oeuvre les principes de protection des données de façon effective, et cela « tant au moment de la détermination des moyens du traitement qu'au moment du traitement lui-même ». Deux moments, donc deux régimes : l'un vise la conception, l'autre l'exploitation.

Les lignes directrices 4/2019 du Comité européen de la protection des données, adoptées dans leur version 2.0 le 20 octobre 2020, donnent à cette formule une portée très concrète. Les moyens du traitement « couvrent tant les éléments généraux que les éléments concrets détaillés de la conception du traitement, notamment l'architecture, les procédures, les protocoles, la présentation et l'apparence », et le moment de leur détermination « comprend le moment d'acquisition et de mise en oeuvre des logiciels, du matériel et des services de traitement de données ». Le choix d'un fournisseur de mesure d'audience, la structure d'une table, le libellé d'un écran d'inscription et l'ajout d'une bibliothèque tierce sont donc des actes soumis à l'article 25.

Le second apport de ces lignes directrices est l'exigence d'effectivité : le comité invite à définir des indicateurs clés de performance pour démontrer que les principes sont réellement mis en oeuvre. Nombre de comptes inactifs restants après le passage de la purge, proportion des champs d'une réponse d'API réellement consommés, délai moyen de traitement d'une demande d'effacement : trois métriques valent mieux qu'une politique de dix pages.

Ce que le manquement coûte, y compris au dirigeant

Le manquement à l'article 25 relève du plafond de l'article 83, paragraphe 4 : 10 millions d'euros ou 2 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu. La particularité française est ailleurs. L'article 226-17 du code pénal punit de cinq ans d'emprisonnement et de 300 000 euros d'amende « le fait de procéder ou de faire procéder à un traitement de données à caractère personnel sans mettre en oeuvre les mesures prescrites aux articles 24, 25, 30 et 32 » du RGPD. L'article 25 y est nommément visé. Le pénal se poursuit contre des personnes physiques, et un arbitrage pris contre la protection des données en réunion de cadrage laisse une trace écrite de cet arbitrage.

L'éditeur SaaS est sous-traitant, et l'article 25 le rattrape quand même

L'article 25 vise le responsable de traitement. Un éditeur qui héberge les données de ses clients agit le plus souvent comme sous-traitant, et pourrait croire la question sans objet. Deux mécanismes l'y ramènent. Le considérant 78 du RGPD invite « les fabricants de produits, les prestataires de services et les producteurs d'applications à prendre en considération le droit à la protection des données lors de l'élaboration et de la conception de tels produits, services et applications ». Surtout, l'article 83, paragraphe 2, sous d), impose de tenir compte, pour fixer le montant d'une amende, des mesures mises en oeuvre en vertu des articles 25 et 32, y compris par le sous-traitant. Vos choix de conception pèsent donc sur la sanction encourue, même lorsque l'obligation formelle repose sur votre client.

Protection dès la conception et protection par défaut : deux obligations distinctes

L'article 25, paragraphe 2, est un texte différent du premier, et c'est celui que les éditeurs sous-estiment le plus. Il impose des mesures « pour garantir que, par défaut, seules les données à caractère personnel qui sont nécessaires au regard de chaque finalité spécifique du traitement sont traitées », et précise que « cela s'applique à la quantité de données à caractère personnel collectées, à l'étendue de leur traitement, à leur durée de conservation et à leur accessibilité ».

Le Comité européen définit « par défaut » exactement comme un ingénieur le ferait : « la valeur préexistante ou présélectionnée d'un paramètre configurable qui est attribuée à une application logicielle, un programme informatique ou un dispositif informatique ». La valeur initiale d'un interrupteur dans un écran de réglages n'est donc pas une décision d'expérience utilisateur, c'est une décision juridique. Un profil visible par défaut, une géolocalisation active par défaut, un partage d'activité avec l'équipe activé par défaut, une case marketing présélectionnée : chacune de ces valeurs engage l'entreprise.

La délibération SAN-2022-020 du 10 novembre 2022 en donne l'illustration la plus nette. L'éditeur d'une messagerie communautaire a été sanctionné de 800 000 euros pour des manquements aux articles 5, paragraphe 1, sous e), 13, 25, paragraphe 2, 32 et 35 du RGPD. Le grief tiré de l'article 25, paragraphe 2, portait sur un comportement de l'application : fermer la fenêtre principale ne quittait pas le logiciel, si bien qu'un utilisateur connecté à un salon vocal continuait d'être entendu. La formation restreinte a retenu que « ce paramétrage par défaut de l'application, qui prévoyait qu'elle n'est pas quittée lorsque la fenêtre principale est fermée, conduisait à ce que des données à caractère personnel de l'utilisateur puissent être communiquées à des tiers sans qu'il en ait nécessairement conscience ».

La défense mérite d'être connue, parce que toute équipe produit l'a déjà formulée : les utilisateurs savent comment fonctionne l'application, et une alerte dégraderait l'expérience de jeu. Elle a été écartée au motif que d'autres applications informent la personne ou lui laissent paramétrer ce comportement. L'argument de l'usage attendu ne tient donc pas dès lors qu'une alternative moins intrusive se pratique déjà sur le marché.

Point de vigilance : dans un produit collaboratif, la question à poser en revue de conception n'est pas « peut-on désactiver ce partage ? » mais « que se passe-t-il si personne ne touche à ce réglage ? ». L'article 25, paragraphe 2, ne juge pas la richesse de vos options, il juge l'état du produit à l'installation. Je fais lister les valeurs par défaut de chaque paramètre touchant à la visibilité, à la conservation et à la transmission à un tiers, puis justifier chacune par une finalité écrite.

Traduire la minimisation des données en modèle de données

Le principe de minimisation de l'article 5, paragraphe 1, sous c), veut que les données soient adéquates, pertinentes et limitées à ce qui est nécessaire. Le Comité européen en tire trois éléments clés de conception : l'évitement du recours aux données quand la finalité le permet, la limitation de la quantité collectée, et la limitation de l'accès, c'est-à-dire concevoir le traitement « de manière à ce qu'un nombre minimal de personnes aient besoin d'accéder aux données ». Ces trois éléments se lisent dans un schéma de base de données, pas dans une politique de confidentialité.

La délibération SAN-2022-009 du 15 avril 2022 montre ce que coûte un modèle mal conçu. Un éditeur de logiciels pour laboratoires d'analyses médicales a été sanctionné de 1 500 000 euros après la diffusion sur internet, le 23 février 2021, des données de près de 500 000 patients. Sur le grief tiré de l'article 29 du RGPD, la société a expliqué que son outil d'extraction « ne permettait que de procéder à une extraction totale du fichier des patients du laboratoire concerné, sans possibilité d'ajouter des filtres sur les champs à exporter ». Une fonctionnalité d'export conçue sans sélection de colonnes a donc fabriqué, à elle seule, un traitement excédant les instructions du client. C'est un défaut de conception, pas une faute d'exploitation.

Les quatre arbitrages qui se jouent dans le modèle

• La granularité. Une date de naissance complète là où une tranche d'âge suffit, une adresse là où un code postal suffit, un horodatage à la seconde là où le jour suffit. Chaque degré de précision superflu est une donnée excédentaire.
• Le champ de texte libre. La CNIL recommande d'éviter les zones de commentaire, qui favorisent les collectes inutiles. Un champ « notes » sur une fiche client finit toujours par contenir un état de santé, une opinion ou une situation familiale, c'est-à-dire des données relevant de l'article 9, dont vous n'avez ni la base légale ni les mesures de sécurité adaptées.
• La réponse des interfaces de programmation. Un point d'accès qui renvoie l'objet utilisateur complet et laisse le client filtrer expose tout ce que le modèle contient. Le filtrage appartient au serveur.
• Le contenu des événements analytiques. Les outils de mesure d'audience reçoivent souvent bien plus que ce qu'ils exploitent, parce que l'équipe a envoyé l'objet entier au cas où. C'est le flux le plus facile à réduire et le plus rarement audité.

Les durées de conservation sont une fonctionnalité, pas un document

C'est ici que l'écart entre le juridique et la technique est le plus grand : une politique de conservation rédigée, validée et publiée ne supprime aucune ligne. Le Comité européen le dit sans détour parmi les éléments clés de la limitation de la conservation, « Automatisation : la suppression de certaines données à caractère personnel devrait être automatisée », et ajoute que le responsable doit s'assurer qu'il n'est pas possible de récupérer des données supprimées, ce qui pose immédiatement la question des sauvegardes et des réplicas.

Dans l'affaire du 10 novembre 2022 déjà citée, la CNIL a constaté que la société n'avait aucune politique écrite de conservation et que son registre ne mentionnait aucune durée. La base contenait 2 474 000 comptes d'utilisateurs français inactifs depuis plus de trois ans et 58 000 comptes inutilisés depuis plus de cinq ans. La société a soutenu qu'elle avait « déterminé et mis en oeuvre des durées de conservation directement codées dans le service ». L'argument n'a pas prospéré, et la leçon vaut dans les deux sens : une durée codée mais non documentée ne se prouve pas, une durée documentée mais non codée n'efface rien. Sur le seuil applicable, la CNIL renvoie à son référentiel du 3 février 2022 relatif à la gestion des activités commerciales, qui recommande de considérer un compte comme inactif au bout de deux ans et de le supprimer, sauf si l'utilisateur exprime le souhait de le maintenir actif.

Ce qu'une purge doit atteindre et ce qu'on oublie toujours

Une tâche de purge qui ne traite que la table principale ne fait pas le travail. Le périmètre réel comprend les tables liées en cascade, les journaux applicatifs qui contiennent identifiants et adresses, les files de messages et leurs enregistrements morts, l'entrepôt analytique alimenté par réplication, les exports au format tableur déposés sur un espace de stockage, les caches, les index de recherche, les sauvegardes et l'outil de suivi des erreurs qui capture des variables de contexte. La suppression logique, celle qui se contente de positionner un indicateur, n'est pas une suppression : elle conserve la donnée et la rend seulement invisible dans l'interface.

La contrepartie technique tient en un test d'intégration continue : créer un compte, avancer l'horloge applicative, déclencher la purge et vérifier l'absence de la donnée dans chacun des systèmes cités. Une obligation juridique devient une assertion exécutable. C'est la meilleure pièce de preuve qu'un éditeur puisse produire en contrôle, et elle coûte une journée de développement.

L'analyse d'impact déclenchée par une user story, pas par un projet

L'article 35, paragraphe 1, impose une analyse d'impact, conduite avant le traitement, « lorsqu'un type de traitement, en particulier par le recours à de nouvelles technologies, et compte tenu de la nature, de la portée, du contexte et des finalités du traitement, est susceptible d'engendrer un risque élevé pour les droits et libertés des personnes physiques ». Le paragraphe 3 vise trois cas obligatoires, et la délibération n° 2018-327 du 11 octobre 2018, modifiée par la délibération n° 2019-011 du 31 janvier 2019, y ajoute quatorze types d'opérations pour lesquelles la CNIL considère l'analyse requise.

La décision du 10 novembre 2022 est instructive sur la méthode. La société soutenait qu'aucun de ses traitements ne figurait dans la liste publiée par la CNIL ni dans les cas de l'article 35, paragraphe 3. La formation restreinte a néanmoins retenu le manquement, en se fondant sur deux des neuf critères des lignes directrices WP 248 rev.01 du 4 octobre 2017 : la collecte à grande échelle et la collecte de données concernant des personnes vulnérables, cette seconde qualification tenant au fait que le service était accessible dès quinze ans. Un mineur de quinze à dix-huit ans reste un enfant, donc une personne vulnérable. Aucune case à cocher, donc, mais une appréciation de risque que l'équipe doit savoir refaire.

Une analyse d'impact ne se déclenche par conséquent pas au lancement d'un projet, mais à l'apparition d'une caractéristique. Ajouter un moteur de recommandation, ouvrir le produit à un public plus jeune, croiser deux jeux de données jusqu'alors séparés, brancher un modèle d'apprentissage sur des données clients : chacune de ces user stories peut faire basculer un traitement existant dans le champ de l'article 35 sans qu'aucun nouveau projet n'ait été ouvert.

Conseil d'avocat : j'inscris dans le gabarit d'epic trois questions de déclenchement. Cette fonctionnalité ajoute-t-elle une catégorie de données, un croisement ou un public nouveaux ? Produit-elle une décision ou un score sur une personne ? Change-t-elle l'échelle du traitement ? Une seule réponse positive ouvre une analyse d'impact ou met à jour celle qui existe. Une analyse conduite en amont se compte en jours, une fonctionnalité à démonter après mise en production se compte en trimestres.

Le ticket privacy et la definition of done

Le privacy by design échoue quand il reste une revue de fin de cycle. Il fonctionne quand il devient un critère d'acceptation, au même titre que la couverture de tests. Trois artefacts suffisent, et aucun ne demande d'outillage nouveau.

Un bloc « données » dans le gabarit d'user story. Quatre lignes : quelles données personnelles cette story crée, lit ou transmet, à quelle finalité, sur quelle base légale, sujet que traite notre article sur le choix de la base légale de l'article 6, et pendant combien de temps elles sont conservées. Une story qui ne touche à aucune donnée personnelle le déclare et passe en dix secondes. Une story incapable de répondre n'est pas prête à être estimée.

Une definition of done augmentée. Cinq critères suffisent : les nouveaux champs sont documentés avec leur durée de conservation et couverts par la purge, les valeurs par défaut retenues sont les plus protectrices, aucune donnée personnelle nouvelle n'est écrite dans les journaux, tout appel à un service tiers est rattaché à un contrat de sous-traitance existant, et le registre des traitements est mis à jour lorsque la finalité change.

Un point privacy en revue de conception. Dix minutes en fin de conception technique, avec le même rituel que la revue de sécurité. La CNIL fournit le matériel : son guide RGPD de l'équipe de développement, publié sous licence libre et organisé en dix-huit fiches, couvre exactement ce périmètre, de « Préparer son développement » à « Gérer la durée de conservation des données ». C'est un document que l'on met entre les mains d'une équipe sans traduction juridique préalable.

Données de production en recette, le risque le plus fréquent et le moins traité

Copier la base de production dans un environnement de recette est la pratique la plus répandue et la moins défendable. Juridiquement, ce n'est pas un détail d'exploitation mais un traitement nouveau : la finalité change, ce qui heurte l'article 5, paragraphe 1, sous b), les destinataires changent, puisque prestataires, stagiaires et outils tiers y accèdent, et le niveau de sécurité baisse, ce que l'article 32 n'admet pas. Pour un éditeur sous-traitant s'y ajoute l'article 28, paragraphe 3, sous a) : traiter les données d'un client dans un environnement de test sans instruction documentée, c'est traiter hors instruction.

La CNIL est explicite dans la fiche consacrée à l'encadrement des développements informatiques de son guide de la sécurité des données personnelles. Parmi les précautions élémentaires figurent l'usage d'environnements distincts pour le développement et la production, la vigilance sur « l'absence de secrets lors du dépôt de code » et la réalisation d'« un test de non-régression et/ou une revue de code avant tout passage en production ». Parmi ce qu'il ne faut pas faire figure, sans nuance, le fait d'utiliser des données personnelles réelles pour les phases de développement et de test.

La sanction du 15 avril 2022 déjà citée montre ce que produit l'accumulation de ces négligences. Les manquements retenus au titre de la sécurité comprenaient l'absence de procédure spécifique pour les opérations de migration, l'absence de chiffrement des données stockées sur un serveur de télémaintenance, l'absence d'effacement automatique après migration, l'absence d'authentification requise depuis internet pour accéder à la zone publique de ce serveur, et l'utilisation de comptes partagés entre plusieurs salariés. Des données de production oubliées sur un environnement technique, sans chiffrement ni purge : c'est le scénario de la fuite des dossiers de près de 500 000 patients.

Le jeu de test que l'on peut défendre

Trois options, par ordre de solidité. La génération de données synthétiques est la seule qui sorte totalement du champ du RGPD, et les bibliothèques disponibles rendent l'exercice raisonnable pour la plupart des schémas. L'anonymisation d'un extrait de production vient ensuite, à condition d'être réelle : si la réidentification reste possible par croisement, il n'y a pas anonymisation. La pseudonymisation ferme la marche, car une base pseudonymisée reste composée de données personnelles au sens de l'article 4, point 5, et demeure soumise à l'ensemble du règlement. Deux règles ferment ensuite le sujet : les environnements hors production ont une durée de vie limitée et sont détruits, et tout export depuis la production passe par une procédure tracée et nominative.

La revue de code sous l'angle des données

Une revue de code orientée données ne demande aucune compétence juridique. Elle demande une liste de motifs à refuser, que voici, par ordre de fréquence constatée.

1. La journalisation d'objets entiers. Tracer une requête en enregistrant le corps complet fait entrer adresses, jetons et parfois mots de passe dans les journaux, avec une durée de conservation que personne n'a décidée. La CNIL considère qu'une durée de six mois est en général adaptée pour les journaux d'accès.
2. Le filtrage côté client. Un point d'accès qui renvoie plus que ce que l'écran affiche laisse la donnée accessible à quiconque lit la réponse réseau.
3. L'absence de contrôle d'accès par ressource. Vérifier que l'utilisateur est authentifié ne suffit pas, il faut vérifier qu'il a le droit d'accéder à cet objet précis. C'est la faille la plus courante et la plus directement constitutive d'un manquement à l'article 32.
4. Le secret déposé dans le dépôt. Une clé d'API poussée dans l'historique reste accessible après suppression du fichier, et le guide de la CNIL en fait un point de vigilance explicite.
5. La brique tierce ajoutée sans contrat. Chaque bibliothèque qui transmet des données à un service distant, chaque outil de suivi d'erreurs, chaque assistant de génération de code branché sur le dépôt est un sous-traitant ultérieur au sens de l'article 28, paragraphes 2 et 4, et doit figurer sur la liste communiquée à vos clients, sujet que détaille notre mode d'emploi du DPA pour un éditeur SaaS.
6. L'absence de journalisation des accès sensibles. Un back-office qui laisse un salarié consulter n'importe quel compte client sans trace est un point de défaillance qui apparaîtra le jour d'un incident, pas avant.

Ce que la conception change en appel d'offres, en contrôle et par où commencer

L'argument commercial est aujourd'hui plus fort que l'argument de la sanction. Un questionnaire de sécurité de grand compte demande la liste des sous-traitants ultérieurs, les durées de conservation par catégorie de données, la politique applicable aux environnements de test et la description des mesures de l'article 32. Un éditeur qui répond en trois jours avec des éléments vérifiables gagne un temps considérable sur celui qui découvre les questions, et le même dossier sert en due diligence comme dans la négociation du droit d'audit de l'article 28, paragraphe 3, sous h).

La pression réglementaire, elle, se déplace vers le produit. Le règlement (UE) 2024/2847 sur la cyberrésilience impose des exigences de sécurité dès la conception aux produits comportant des éléments numériques, avec des obligations de signalement des vulnérabilités activement exploitées et des incidents graves applicables à compter du 11 septembre 2026, le reste du dispositif s'appliquant au 11 décembre 2027. Du côté de la CNIL, environ 20 % des contrôles annuels relèvent des thématiques prioritaires, qui portent en 2026 sur le recrutement, le répertoire électoral unique et les fédérations sportives. Les autres naissent des plaintes et des notifications de violation, c'est-à-dire d'incidents que la conception aurait souvent évités.

Par où commencer si rien n'existe : inventorier les valeurs par défaut de tous les paramètres touchant à la visibilité et à la transmission de données, écrire une durée de conservation par table et la faire exécuter par une tâche automatisée testée, puis sortir les données de production des environnements de recette. Ces trois chantiers couvrent la majeure partie de l'exposition réelle et se mesurent en semaines. Le reste ne coûte presque rien une fois ces trois points réglés. Un audit de conformité mesure l'écart de départ, et nos bonnes pratiques RGPD applicables aux solutions SaaS complètent le sujet du côté contractuel.

J'interviens auprès des équipes techniques pour traduire l'article 25 en critères vérifiables, arbitrer les valeurs par défaut d'un produit et rédiger les pièces qui tiennent devant un client comme devant un contrôleur, dans le cadre d'un audit RGPD adapté aux contraintes des éditeurs de logiciels et SaaS. Si une fonctionnalité vous inquiète ou si un questionnaire client vous attend, vous pouvez échanger sur votre situation directement avec moi.