Les ingénieurs recherchant des vérifications de conformité RGPD en revue de code veulent généralement une chose : une liste courte des obligations juridiques qui peuvent effectivement être violées dans une pull request normale, et non un manuel complet de programme de confidentialité. Le Règlement concerne principalement les processus, les enregistrements et les mesures organisationnelles. Une minorité constante d'obligations se retrouve tout de même dans le code : ce que vous stockez, la durée de conservation, si un chemin de suppression atteint toutes les copies, ce que les valeurs par défaut exposent, comment le traitement est sécurisé et où les données sont hébergées.
Ce guide est cette cartographie. Il ne s'agit pas d'un tutoriel sur un seul bug de limitation de conservation (celui-ci se trouve à /guides/catching-a-gdpr-retention-bug-in-code-review) ni d'une analyse approfondie des contrôles (ceux-ci sont disponibles sous /frameworks/gdpr). Il s'agit de la checklist de revue de code : quels articles citer, à quoi ressemble la modification et ce qu'un relecteur peut demander sans devenir un conseiller juridique.
Les articles qui apparaissent souvent dans un diff
Art. 5(1)(c) minimisation des données : une modification commence à collecter ou à journaliser plus de données personnelles que nécessaire pour la finalité (corps de requête complets, enregistrements d'identité complets copiés dans un stockage secondaire). Art. 5(1)(e) limitation de la conservation : un nouveau stockage ou cache de données personnelles est déployé sans limite de conservation, ou une fenêtre de purge est élargie sans justification. Art. 17 droit à l'effacement : un chemin de suppression ne couvre pas un cache, un index de recherche, une exportation analytique ou une copie du sous-traitant. Art. 25 protection des données dès la conception et par défaut : un champ personnel devient visible ou partagé avec tous les utilisateurs par défaut, ou une valeur par défaut protectrice est désactivée. Art. 32 sécurité du traitement : le chiffrement, le contrôle d'accès ou les mesures d'intégrité sur les données personnelles sont affaiblis (niveau TLS abaissé, stockage de jetons en texte clair, accès admin ouvert). Art. 44 chapitre sur les transferts : des données personnelles sont transférées vers une nouvelle région ou un sous-traitant hors UE sans que l'historique de transfert attendu par votre programme ne soit respecté.
Ces explications sont en langage courant pour les ingénieurs, et non le texte du Règlement. Lorsqu'une découverte cite un article, il s'agit d'un signal pour l'auteur et le contact RGPD, et non d'une détermination que le traitement est illégal.
Exemple concret : la protection des données par défaut inversée pour le "confort du support"
Une équipe de support souhaite un tri des tickets plus rapide. Un ingénieur ouvre une pull request qui modifie l'API de profil client afin que chaque rôle de personnel authentifié reçoive, par défaut dans l'endpoint de liste, le nom complet, l'email, le téléphone et les quatre derniers chiffres de paiement, et non uniquement sur une demande explicite "expand=pii". La modification est minime : un indicateur de sérialiseur passe de false à true. Les tests sont mis à jour pour attendre la charge utile enrichie. La revue de code aborde la taille de la réponse et les en-têtes de cache. Rien ne ressemble à un bug de sécurité ; l'authentification fonctionne toujours.
Ce qui a changé concerne l'Art. 25 protection des données dès la conception et par défaut : les données personnelles sont désormais exposées par défaut à un ensemble plus large de consommateurs internes que la configuration précédente de moindre privilège. La configuration plus sûre conserve le défaut restreint et exige une expansion explicite et auditable pour les outils de support. Il s'agit d'un mode de défaillance différent du bug de conservation (Art. 5(1)(e) sur un nouveau stockage sans purge) et d'un exemple pur de minimisation de la journalisation (Art. 5(1)(c) sur les corps de requête). Une revue consciente de la conformité cite l'Art. 25 (et souvent l'Art. 5(1)(c) comme principe de soutien) sur la PR tant que l'indicateur est encore facile à inverser.
Que demander en revue sans devenir un DPO
Pour toute modification touchant des données personnelles : quels champs sont nouveaux, qui peut les voir par défaut, combien de temps ils sont conservés et si un chemin de suppression ou d'exportation les atteint toujours. Pour les changements de région ou de fournisseur : où vont les données, et le service RGPD suit-il déjà ce sous-traitant ou ce transfert. Pour les PR de "nettoyage" : avons-nous supprimé le chiffrement, les vérifications d'accès ou les lignes d'audit qui protégeaient les données personnelles (lié à l'Art. 32).
Vous n'avez pas besoin de citer le Règlement. Vous devez refuser de fusionner lorsque la réponse est "inconnu" jusqu'à ce que quelqu'un prenne en charge l'étape RGPD, ou restaurer la valeur par défaut la plus sûre.
Où s'intègre heygrc, et la limite d'honnêteté
heygrc est conçu pour analyser chaque pull request par rapport aux frameworks que vous avez sélectionnés, y compris le RGPD lorsqu'il est activé, et pour identifier l'article qu'une modification semble concerner (par exemple, l'Art. 25 sur une charge utile par défaut élargie). Il ne décide pas de la base juridique, ne réalise pas d'AIPD, ne tient pas le registre des activités de traitement, n'approuve pas les transferts ni ne remplace votre DPO. Une revue verte n'est pas une validation de conformité par une autorité de contrôle.
Les relecteurs de bugs et de qualité restent sur la même PR. Ils demandent si le code est correct. Les questions RGPD demandent si les obligations liées aux données personnelles sont toujours respectées. Exécutez les deux.