QR codes et RGPD : ce qu'un scan collecte et ce que vous devez faire

Le code imprimé ne traite rien. Il s'agit d'un motif statique de carrés, il est décodé hors ligne et il n'est pas davantage soumis au droit de la protection des données qu'un numéro de téléphone sur une affiche.

La redirection derrière lui est une autre affaire. Dès que quelqu'un ouvre le lien décodé, votre serveur reçoit une adresse IP, un user agent, un horodatage et, généralement, un référent. Il s'agit d'un traitement de données personnelles, et tout ce que le RGPD rattache au traitement s'applique ici : une base légale, une notice réellement accessible, une durée de conservation et une réponse défendable à la question de savoir qui d'autre y a accès.

Cet article explique ce qu'un scan génère réellement et ce que chaque élément exige. La vue d'ensemble pour les liens se trouve dans RGPD pour les raccourcisseurs d'URL, et la question des cookies est traitée dans le consentement aux cookies pour les liens courts.

Ce qu'un scan produit réellement

Le décodage se fait sur l'appareil, sans aucune connexion réseau. À ce stade, rien n'a quitté le téléphone, raison pour laquelle le code lui-même n'est pas la question de conformité que l'on imagine.

L'ouverture du lien produit une requête HTTP ordinaire. La redirection voit l'adresse IP, la chaîne du user agent, l'heure et parfois un référent. Un code dynamique ajoute un saut avant la destination : c'est donc votre serveur qui voit ces éléments en premier, puis celui de la destination.

Une adresse IP est une donnée personnelle dans le cas ordinaire. La Cour de justice l'a confirmé dans l'affaire Breyer, et l'article 4 définit les données personnelles de façon à inclure l'identification indirecte. Deux conséquences que l'on a du mal à accepter en découlent : vous n'avez pas besoin de savoir qui est quelqu'un pour que la donnée soit personnelle, et les compteurs agrégés ne la rendent pas anonyme par magie, car l'agrégation intervient après la collecte.

Quelle base légale

Pour compter les scans, l'intérêt légitime au titre de l'article 6(1)(f) est normalement la bonne base, et c'est celle que la plupart des campagnes devraient utiliser plutôt qu'une bannière de consentement que personne ne lit.

Cette base n'est pas gratuite. Elle exige un test de mise en balance rédigé avant la campagne : quel est l'intérêt (savoir si l'affiche à l'entrée nord fonctionne), pourquoi il est nécessaire, quel est son impact sur la personne et ce que vous avez fait pour le minimiser. Tronquer les adresses IP, conserver le pays plutôt que les coordonnées et fixer une courte durée de conservation sont les mesures d'atténuation qui font pencher le test en votre faveur.

Le consentement devient nécessaire à un moment précis, et il vaut la peine de savoir exactement où se situe la limite. Pas pour le comptage. Pas pour l'agrégation au niveau du pays. Oui pour les cookies non essentiels déposés sur la page de destination : c'est la règle ePrivacy plutôt que le RGPD, et elle s'applique quelle que soit votre base pour les données sous-jacentes. Oui pour créer un profil qui suit la personne d'un site à l'autre, ce que fait un pixel de retargeting sur la destination.

C'est la distinction véritablement utile dans tout ce domaine : le comptage des scans et la publicité intersites sont des activités différentes, régies par des règles différentes, et c'est le fait de les traiter comme une seule chose qui produit à la fois une collecte excessive et des bannières inutiles.

Ce que la notice doit dire et où

L'affiche ne peut pas porter la notice de confidentialité et, au moment où la page se charge, le traitement a déjà eu lieu. La notice se trouve donc sur la page de destination, accessible sans avoir à la chercher, et elle doit parler honnêtement d'un scan précis plutôt que du site web en général. Cette même page porte une obligation d'accessibilité qui lui est propre, traitée dans l'accessibilité des QR codes.

La version exploitable dit ceci : le scan de ce code ouvre une page qui enregistre la visite, nous enregistrons l'heure, le pays approximatif et le type d'appareil, nous le faisons pour mesurer l'efficacité des emplacements, sur la base de l'intérêt légitime, nous conservons les enregistrements bruts pendant une courte période définie, et voici qui traite ces données pour notre compte.

Deux problèmes reviennent régulièrement. Un code qui apparaît sur un support physique dans un pays alors que la notice de la page de destination n'existe que dans une autre langue n'est pas réellement transparent. Et une notice qui décrit « notre site web » alors que la campagne consiste en un autocollant posé sur le bord d'une étagère en magasin ne décrit pas ce qui s'est réellement passé.

C'est la conservation qui fait dévier la plupart des campagnes

La limitation des finalités fait le travail ici. Un rapport de campagne a besoin des enregistrements bruts pendant des semaines ; personne n'a besoin du journal brut de chaque scan effectué sur une affiche de 2024.

Le schéma qui tient la route : une courte durée de conservation pour les enregistrements bruts, puis des agrégats conservés indéfiniment. Les compteurs par jour, par pays et par code subsistent ; la ligne contenant une adresse IP, non. Cela respecte la limitation de la conservation sans perdre les chiffres que l'on vous demandera un jour.

Cela répond aussi à la question délicate des demandes d'accès et d'effacement, car une fois la durée écoulée, il ne reste plus rien de rattachable à remettre ou à supprimer.

L'endroit où les données sont physiquement stockées compte aussi, et pour les campagnes dans l'UE, c'est la différence entre une réponse simple et une analyse de transfert. La résidence des données dans l'UE pour le marketing traite ce sujet, et Schrems II et les pixels de tracking explique ce qui se passe lorsque l'outil d'analytics n'est pas situé dans l'UE.

Quand une AIPD est-elle réellement nécessaire ?

Rarement pour un code marketing. Un scan d'affiche qui produit une consultation de page et un compteur est un traitement à faible risque, quelle que soit l'analyse retenue.

Le seuil est franchi lorsque le scan est rattaché à une personne identifiable plutôt qu'à un compteur : un code de fidélité lié à un compte, un code destiné aux salariés qui enregistre qui se trouvait où et quand, ou un code qui combine des données de localisation pour créer un schéma de déplacement. Il s'agit d'une surveillance systématique, et l'article 35 commence alors à s'appliquer. SOC 2 et HIPAA pour le tracking des liens traite de la question voisine du tracking dans les contextes réglementés.

L'autre risque qui mérite d'être mentionné ne vient pas de vous. Un QR code dissimule sa destination, ce qui est précisément ce qui permet au quishing de fonctionner. Un code sur votre emballage qu'un inconnu recouvre d'un autocollant devient un problème pour votre réputation, même si le traitement ne vous appartenait pas, et la mesure d'atténuation consiste à utiliser un domaine que les gens reconnaissent et à vérifier périodiquement que les codes présents sur le terrain résolvent toujours vers la bonne destination.

Choisir une redirection qui conserve les données de scan dans l'UE par défaut est la décision la plus simple à prendre correctement : créez un lien sur le plan gratuit et vérifiez où sont stockées ses analytics avant l'impression de la campagne.

Lire la série pilier

Cet article appartient au cluster conformité. Commencez par le RGPD pour les raccourcisseurs d'URL pour l'analyse au niveau de la redirection, puis consultez le consentement aux cookies pour les liens courts pour savoir où le consentement s'applique réellement. La page de confiance présente notre propre posture en matière de traitement.

À lire aussi sur le blog

• RGPD pour les raccourcisseurs d'URL : ce que la redirection enregistre
• Qu'est-ce qu'un QR code et comment un scan fonctionne-t-il réellement ?
• Les QR codes sont-ils sûrs ? Quishing et moyens de rester protégé
• Résidence des données dans l'UE pour les équipes marketing
• Accessibilité des QR codes : WCAG, contraste et solutions de remplacement