Server-side tracking : contrôles RGPD et consentement

Le server-side tracking déplace une partie du traitement vers un serveur que vous configurez. Il peut permettre de filtrer les données avant de les envoyer à une régie. Il peut aussi créer une nouvelle copie de données et poursuivre une transmission que l’internaute croit avoir refusée. Vous pouvez retenir cette architecture pour limiter et contrôler les transmissions, mais elle n’autorise pas à récupérer les conversions que les personnes ont refusé de partager. La conformité dépend des opérations réelles, pas de leur emplacement.

Cartographier les trois étapes

Dans une architecture avec conteneur serveur, les requêtes reçues sont transformées en événements, puis traitées par des balises et dirigées vers leurs destinations. Google décrit ce fonctionnement pour GTM Server-side ; d’autres architectures peuvent varier. Introduction officielle au balisage serveur.

Dessinez trois étapes distinctes : la collecte initiale, le traitement intermédiaire et l’envoi à chaque destination. Attribuez à chacune un responsable et une règle d’arrêt. Pour une même commande, le traitement nécessaire à sa livraison et son utilisation publicitaire sont des opérations différentes.

Cas : une boutique d’affiches sépare commande et publicité

Une PME française fictive vend des affiches. Son agence souhaite envoyer les achats à une plateforme publicitaire via un serveur intermédiaire, afin de réduire les doublons et de filtrer les données. Le projet initial copie tout l’objet « commande », incluant adresse, commentaire de livraison et email, puis retire certains champs juste avant l’envoi final.

La dirigeante refuse cette copie générale. Pour le projet publicitaire, elle exige une autorisation de la finalité, un événement réduit et une destination identifiée. La commande continue d’être traitée dans le logiciel de vente même si cette transmission publicitaire n’est pas autorisée. Le serveur marketing n’est pas utilisé comme archive de facturation.

L’architecture retenue dans cet exemple doit satisfaire les règles suivantes :

Ce tableau est une spécification proposée, pas une fonctionnalité garantie de tous les conteneurs serveurs. L’agence doit montrer comment chaque règle est implémentée dans l’architecture choisie. Une conversion techniquement acceptée par la régie ne démontre pas que l’entreprise avait le droit de l’envoyer.

Un serveur qui retire l’email avant l’envoi à une régie l’a tout de même reçu. Il faut donc examiner la licéité et la conservation de cette première collecte.

Appliquer les règles de traceurs à la collecte

Un cookie déposé sous votre domaine n’est pas exempté parce qu’il est « first-party ». La distinction interne/tiers est technique. L’article 82 de la loi Informatique et Libertés exige un accord pour les opérations qui ne relèvent pas d’une exemption. Règles CNIL sur les cookies.

La mesure d’audience peut être exemptée dans certaines configurations limitées. Ce n’est pas une propriété automatique du serveur, de l’hébergeur ou de la suppression des cookies. FAQ CNIL, mesure d’audience.

Le dossier Google Tag Manager et RGPD aide à vérifier la collecte initiale lorsque le conteneur web déclenche les événements.

Filtrer selon le choix avant toute destination

Définissez les champs autorisés et les règles par finalité. Préférez une liste précise de données attendues à la transmission de tous les attributs d’une commande suivie d’un nettoyage partiel.

Le serveur doit recevoir un signal compréhensible et fiable pour décider des envois dépendant du consentement. Prévoyez le cas où ce signal est absent, mal formé ou périmé. L’absence d’information ne doit pas devenir un accord publicitaire.

Vérifiez également les événements mis en attente, les reprises sur erreur et les imports différés. Un refus dans la CMP ne coupe pas automatiquement ces chemins. Le guide du retrait et de l’arrêt des scripts doit être complété par un contrôle de ces files serveur.

Ne pas confondre hachage et anonymisation

Hacher un email pour le rapprocher d’un compte publicitaire préserve justement une capacité de rapprochement. Cela ne rend pas automatiquement la donnée anonyme. La CNIL distingue l’anonymisation effective de la pseudonymisation, qui reste dans le champ du RGPD. Explications CNIL sur l’anonymisation.

Les Art. 5(1)(b), 5(1)(c) et 6(1) continuent à s’appliquer aux finalités, aux données et à la base légale. La minimisation réduit les risques ; elle ne régularise pas à elle seule un transfert à une nouvelle plateforme. RGPD, chapitre II.

Maîtriser l’hébergement et les journaux

Documentez les accès, sous-traitants et transferts effectifs. Un serveur en Europe ne garantit pas l’absence d’accès depuis un pays tiers ni l’absence de transfert ultérieur à la régie. Le choix de la région doit être vérifié dans les engagements et les flux réels.

Définissez une conservation pour les journaux techniques et évitez d’y enregistrer inutilement le contenu complet des événements. Les logs de sécurité et les données marketing n’ont pas nécessairement la même finalité ni la même durée. La CNIL recommande une journalisation utile à la sécurité et protégée contre les usages détournés. Sécurité : tracer les opérations.

Le dossier des journaux du tracking serveur propose un inventaire des copies souvent oubliées.

Écrire le contrat de données avant de brancher la régie

Pour la boutique d’affiches, le contrat de données est une fiche interne, pas un nouveau contrat commercial. Il décrit le nom de l’événement, les champs autorisés, leur provenance et leur finalité. Toute donnée non prévue est rejetée plutôt que transmise par défaut. Le responsable marketing explique ce qu’il veut mesurer ; le développeur décide comment construire cet événement sans copier inutilement le dossier de vente.

La fiche précise aussi la signification des états. « Accord publicitaire » doit correspondre au choix effectivement présenté, pas à une valeur true placée par défaut dans le connecteur. « Inconnu » ne signifie pas « accord ». Lorsque plusieurs finalités existent, une autorisation statistique ne doit pas devenir une autorisation de rapprochement publicitaire.

L’équipe prévoit une correspondance limitée permettant de faire suivre le retrait dans les événements encore en attente. Elle documente les accès et la durée nécessaire de cette correspondance, sans reconstituer un fichier permanent de toutes les commandes. Si l’architecture ne permet pas de retrouver les événements concernés, elle doit être corrigée avant d’utiliser cette file pour un traitement fondé sur le consentement.

Les restrictions s’appliquent aussi aux reprises : après une panne, renvoyer un ancien lot n’autorise pas à réutiliser une copie périmée des choix. Le traitement comptable de la vente peut se poursuivre sur son propre fondement ; l’envoi publicitaire reste soumis à ses conditions distinctes.

Contrôler la chaîne complète et réagir aux anomalies

Le contrôle commence sur des achats fictifs. L’équipe compare ce qui est produit par le site, reçu par le serveur, conservé dans ses files et transmis à la destination. Elle utilise un identifiant technique de démonstration pour suivre le parcours, puis évite de transformer cet identifiant de contrôle en nouvelle donnée collectée sur tous les clients.

Quatre situations sont obligatoires dans le protocole de ce projet : accord valable, refus, état absent et retrait après mise en attente. Pour chacune, le dossier indique l’événement attendu ou son absence. L’équipe vérifie également une reprise sur erreur, car un flux synchrone correct ne prouve pas que le lot différé respecte les mêmes règles.

Supposons que le retrait soit respecté dans le navigateur, mais que l’achat reste dans la file serveur et parte la nuit suivante. La dirigeante suspend le connecteur publicitaire. L’agence corrige le contrôle de l’état avant expédition et recherche les autres événements concernés. Elle traite également les copies déjà envoyées avec la plateforme selon les droits applicables ; supprimer une ligne locale ne démontre pas leur disparition à destination.

La reprise exige de rejouer le scénario défaillant puis le parcours normal, avec un compte disposant des mêmes permissions que le service réel. Si une destination ne permet pas de maîtriser l’effet du retrait, le projet reste limité ou suspendu pour cette destination. L’équipe ne contourne pas cette difficulté en remplaçant l’email par son empreinte.

Enfin, le bilan commercial sépare les achats du logiciel de vente et les conversions effectivement mesurées dans la plateforme. Leur différence peut provenir d’un refus, d’une restriction, d’un délai ou d’une erreur. Elle ne constitue pas une réserve de conversions que l’agence serait autorisée à « récupérer » sans autre analyse. Documenter cette limite fait partie du livrable, au même titre que la configuration du serveur.

Ce qu’il faut retenir

• Analysez collecte, serveur intermédiaire et transmission séparément.
• Un domaine propriétaire ne crée pas d’exemption de consentement.
• Filtrez les données et traitez les choix absents ou retirés dans les files différées.
• Vérifiez journaux, accès et transferts au-delà de la région d’hébergement.

FAQ

Un serveur dispense-t-il de la CMP ?

Il ne dispense pas des règles de recueil et d’exécution des choix applicables. Le moyen de les mettre en œuvre dépend du parcours et des opérations.

Peut-on récupérer toutes les conversions refusées ?

Le refus doit produire ses effets sur les traitements concernés. Une capacité technique de collecte ne constitue pas une autorisation de contourner ce choix.

Un email haché peut-il être transmis librement ?

Non. S’il permet un rapprochement avec une personne ou un compte, il faut continuer à appliquer les règles de protection des données.

Recevez nos analyses pratiques sur la conformité : inscrivez-vous à la newsletter.

Thiébaut Devergranne est docteur en droit et fondateur de donneespersonnelles.fr. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données personnelles.