Analytics QR code sans cookies : ce que les équipes soucieuses du RGPD doivent savoir
La plupart des analytics web fonctionnent côté client : un script se charge dans le navigateur, pose un cookie, et rapporte à un serveur. Un scan de QR code n'a pas du tout besoin de fonctionner ainsi, et comprendre pourquoi compte pour toute équipe qui doit répondre de là où vont les données visiteurs.
Un scan est déjà une requête serveur
Quand quelqu'un scanne un QR code dynamique, son téléphone fait une requête HTTP vers un serveur de redirection avant même d'atteindre la page de destination finale. Cette requête porte déjà un signal utile — le pays (via le réseau), le type d'appareil et l'OS (via le user agent), l'heure exacte, et si le code en a un, un référent. Rien de tout ça ne nécessite un script s'exécutant dans le navigateur du visiteur, parce que le point de mesure est la redirection elle-même, pas la page vers laquelle elle envoie.
C'est une position structurellement différente de la plupart des outils d'analytics, qui doivent injecter un script dans une page qu'ils ne contrôlent pas pour observer quoi que ce soit. Une redirection de QR code est le point de contrôle — la mesure est un effet secondaire naturel de la redirection, pas un ajout greffé dessus.
Pourquoi ça veut dire pas de bandeau cookies
Un bandeau cookies existe parce qu'un outil stocke un identifiant dans le navigateur du visiteur pour le reconnaître entre deux visites. L'enregistrement de scan côté serveur n'a pas besoin de faire ça pour produire des analytics agrégés utiles — pays, appareil, OS, référent, et heure de la journée ne nécessitent pas d'identifier durablement un visiteur individuel, seulement de catégoriser la requête qui vient de se produire.
Les analytics de Stelyo vont un cran plus loin et ne stockent jamais d'adresse IP brute du tout : chaque scan est enregistré avec un hash visiteur qui tourne chaque jour, suffisamment utile pour dédupliquer les scans répétés dans une même journée sans être un identifiant durable qui persiste entre les jours ou qui relie à une vraie personne. Pas de pixel de tracking, pas de cookie, pas de bandeau de consentement requis — et pas de dette de conformité qui s'accumule en arrière-plan.
Ce que ça change concrètement pour une équipe basée en UE
Pour une équipe qui doit penser au RGPD, ça retire toute une catégorie de gestion du consentement spécifiquement pour le suivi de scan QR — pas de cookie à déclarer, pas d'état de consentement à vérifier avant d'enregistrer un scan, pas de script côté client dont la présence doit être documentée dans une politique de cookies. Combiné à une infrastructure hébergée en UE (Irlande, dans le cas de Stelyo) et, sur les plans payants, un DPA signé, la question de la résidence des données a une réponse simple plutôt que pleine de réserves.
Ce que vous obtenez, et ce que vous n'obtenez pas
Vous obtenez des chiffres réels, utiles, vérifiés côté serveur : scans totaux, tendance dans le temps, répartition par pays et appareil, source de référence, tendances par heure de la journée — exportables en CSV ou récupérables via l'API REST. Ce que vous n'obtenez pas, c'est le suivi d'un visiteur individuel entre sessions ou entre jours, des profils comportementaux inter-sites, ou quoi que ce soit qui nécessiterait un bandeau de consentement en premier lieu. Pour mesurer si une campagne QR fonctionne, c'est le bon compromis — vous avez rarement besoin de savoir qui a scanné, seulement combien, d'où, et avec quoi.