Data collection summary : documenter clairement ce que votre analytics collecte

18 May, 2026
- Analytics ,
- Gouvernance

Installer un outil analytics prend parfois quelques minutes. Expliquer précisément ce qu’il collecte peut prendre beaucoup plus longtemps.

La difficulté ne vient pas seulement du volume de données. Elle vient de la dispersion de l’information. Une partie se trouve dans le plan de marquage, une autre dans la documentation du fournisseur, une autre dans le gestionnaire de consentement, et une dernière dans le code du site. Quand une question arrive, par exemple « transmettons-nous l’URL complète ? », « l’adresse IP est-elle stockée ? » ou « combien de temps gardons-nous les événements ? », personne ne dispose forcément d’une réponse complète.

Un data collection summary est un document court qui rassemble ces réponses. Il décrit la collecte telle qu’elle fonctionne réellement, et non telle qu’on l’imagine à partir d’une page marketing. Ce n’est ni un avis juridique, ni un remplacement du registre des traitements, ni une politique de confidentialité. C’est une vue technique et opérationnelle qui relie les trois.

À quoi sert un data collection summary ?

Le document répond à une question simple :

Pour chaque donnée ou signal collecté, savons-nous d’où il vient, pourquoi nous le collectons, où il va, combien de temps nous le gardons et qui peut y accéder ?

Cette vue est utile à plusieurs équipes.

L’équipe produit peut vérifier qu’un nouvel événement répond à un besoin réel. L’équipe marketing peut comprendre quelles dimensions sont disponibles sans supposer que « l’outil doit sûrement les avoir ». L’équipe technique dispose d’une référence pour les filtres, les transformations et les environnements. Le DPO ou le conseil juridique peut confronter la réalité technique aux documents de conformité. La direction peut enfin savoir quel risque et quelle dette accompagnent la mesure d’audience.

Le RGPD impose notamment des principes de finalité, de minimisation, de transparence et de limitation de la conservation. Il prévoit aussi, selon les situations, une information des personnes et la tenue d’un registre des activités de traitement. Le data collection summary ne crée pas ces obligations, mais il facilite la production d’informations exactes et cohérentes.

Ce document n’est pas le registre des traitements

La distinction est importante.

Le registre des activités de traitement est un document de gouvernance prévu par l’article 30 du RGPD dans les cas où il s’applique. Il décrit un traitement à un niveau relativement large : finalités, catégories de personnes, catégories de données, destinataires, transferts, durées et mesures de sécurité.

Le data collection summary descend au niveau de l’implémentation. Il peut préciser que :

l’URL est enregistrée sans la chaîne de requête ;
l’adresse IP est utilisée brièvement pour une opération technique puis non conservée ;
le user-agent est réduit à une famille de navigateur ;
les paramètres utm_source, utm_medium et utm_campaign sont conservés ;
un identifiant de formulaire n’est envoyé qu’après validation ;
les données brutes et les rapports agrégés n’ont pas la même durée de conservation.

La politique de confidentialité, elle, traduit les éléments pertinents dans un langage destiné aux visiteurs. Elle ne doit pas devenir une copie de la documentation technique, mais elle ne peut être fiable que si cette documentation existe.

On peut donc résumer les rôles ainsi :

Document	Public principal	Niveau de détail	Fonction
Registre des traitements	Interne, conformité	Traitement et catégories	Démontrer et piloter la conformité
Data collection summary	Interne, produit et technique	Champs, flux et contrôles	Décrire la collecte réellement déployée
Politique de confidentialité	Visiteurs et utilisateurs	Information claire	Expliquer les traitements pertinents aux personnes
Plan de marquage	Produit, marketing, développement	Événements et règles	Définir ce qui doit être mesuré

Ces documents se complètent. Ils ne doivent pas se contredire.

Les 10 colonnes d’un résumé utile

Un tableur suffit. L’important est la qualité des colonnes et la discipline de mise à jour.

1. Donnée ou signal

Nommez la donnée sans jargon commercial : chemin de page, domaine référent, type d’appareil, événement de formulaire, identifiant de site, paramètre UTM, pays dérivé, adresse IP temporaire.

Évitez les catégories vagues comme « données techniques ». Elles masquent les choix concrets.

2. Exemple de valeur

Un exemple réduit les ambiguïtés. Pour un chemin de page : /tarifs/. Pour une source : newsletter. Pour un événement : demo_requested.

N’utilisez pas de vraie donnée personnelle dans le document. Un exemple synthétique suffit.

3. Source

Précisez où le signal apparaît : navigateur, serveur, formulaire, CMS, CDN, script analytics ou import externe.

Cette colonne aide à repérer les données collectées indirectement. Un outil peut, par exemple, recevoir une URL ou un en-tête avant même que votre code de tracking ne les transforme.

4. Finalité opérationnelle

Écrivez une phrase qui relie la donnée à une décision : « mesurer les pages d’entrée qui génèrent une demande de démonstration » est plus utile que « analyse marketing ».

Une finalité trop large est un signal d’alerte. Si une donnée sert supposément à tout, son besoin n’est probablement pas assez défini.

5. Transformation avant stockage

Indiquez ce qui est supprimé, tronqué, agrégé ou dérivé :

suppression des paramètres non autorisés ;
normalisation du chemin ;
réduction du user-agent ;
géolocalisation approximative puis suppression de l’adresse IP ;
hachage d’un identifiant, avec la précision qu’un hachage n’est pas automatiquement une anonymisation ;
agrégation quotidienne ou mensuelle.

Cette colonne permet de distinguer ce que le système reçoit de ce qu’il conserve.

6. Destination et sous-traitants

Listez les systèmes qui reçoivent la donnée : endpoint de collecte, stockage brut, base agrégée, outil de BI, export, fournisseur cloud ou prestataire analytics.

Ajoutez la région d’hébergement et les transferts pertinents lorsqu’ils sont connus et documentés. Ne déduisez pas la localisation juridique d’un simple nom de région cloud.

7. Durée de conservation

Séparez les couches lorsque nécessaire :

logs techniques ;
événements bruts ;
données pseudonymisées ;
statistiques agrégées ;
sauvegardes ;
exports manuels.

Une seule durée globale est souvent trompeuse. La CNIL rappelle que la durée doit être déterminée selon la finalité et limitée au nécessaire. Pour les traceurs de mesure d’audience susceptibles d’entrer dans le cadre d’une exemption en France, elle recommande notamment une durée de vie de treize mois pour les traceurs et une conservation des informations collectées limitée à vingt-cinq mois. Ces repères ne dispensent pas d’analyser la configuration réelle.

8. Accès

Décrivez les rôles, pas seulement les noms : administrateurs, analystes, agence, support, prestataire d’hébergement.

Précisez si l’accès porte sur les rapports agrégés, les événements bruts ou les exports. « L’équipe marketing a accès » est insuffisant si un compte générique permet aussi de télécharger toutes les données.

9. Dépendance au consentement ou à la configuration

Cette colonne doit rester factuelle. Indiquez par exemple :

collecté uniquement après signal de consentement ;
désactivé en mode de mesure stricte ;
activé uniquement pour certaines campagnes ;
soumis à une analyse locale ePrivacy ;
utilisé pour une mesure d’audience limitée, sous réserve que toutes les conditions applicables soient remplies.

N’écrivez pas simplement « exempté » sans documenter les conditions, le périmètre et la configuration.

10. Suppression et responsable

Enfin, indiquez comment la donnée disparaît et qui vérifie le processus : suppression automatique, tâche planifiée, purge fournisseur, procédure manuelle, échéance de contrat, suppression d’un export.

Ajoutez un propriétaire interne et une date de dernière revue. Sans responsable, le document vieillit dès la prochaine mise en production.

Exemple minimal pour une PME SaaS

Voici un extrait volontairement simplifié :

Signal	Finalité	Traitement avant stockage	Conservation	Accès
Chemin de page	Mesurer les contenus consultés	Query string supprimée, chemin normalisé	25 mois pour les rapports	Produit, marketing
Domaine référent	Comprendre les sources de visite	Origine uniquement lorsque transmise	25 mois	Marketing
`utm_source`	Identifier une campagne déclarée	Valeurs normalisées selon une nomenclature	25 mois	Marketing
Événement `demo_requested`	Mesurer une conversion B2B	Aucun contenu de formulaire envoyé	25 mois	Produit, ventes en agrégé
Adresse IP	Sécurité et dérivation géographique approximative	Utilisée temporairement, non stockée dans l’événement	Durée technique documentée	Opérations restreintes
User-agent	Répartition technique	Réduit à une catégorie de navigateur et appareil	25 mois	Produit

Ce tableau ne prouve rien à lui seul. Il doit correspondre au réseau observé, au code et aux réglages du fournisseur. C’est pourquoi il est utile de commencer par un audit des traceurs effectivement chargés et de comparer le résultat au plan de marquage minimaliste.

Méthode de construction en cinq étapes

Étape 1 : partir du trafic réseau

Ouvrez les outils de développement du navigateur, rechargez les pages représentatives et observez les requêtes. Faites le test avant et après chaque choix de consentement, sur plusieurs parcours et appareils.

Relevez les domaines, les payloads, les paramètres d’URL et les événements. Le réseau montre ce qui est transmis depuis le navigateur. Il ne montre pas nécessairement toutes les transformations côté serveur, mais il constitue un point de départ vérifiable.

Étape 2 : lire le code et la configuration

Inspectez le script de collecte, le gestionnaire de tags, les règles du CMP, les variables d’environnement et les filtres. Une documentation fournisseur générique ne dit pas quelle option votre site a activée.

Vérifiez également les fonctionnalités annexes : enregistrement de session, enrichissement publicitaire, export vers une régie, connexion CRM ou identifiants utilisateurs.

Étape 3 : interroger le fournisseur avec des questions fermées

Demandez des réponses vérifiables :

l’URL complète est-elle reçue et stockée ?
les paramètres de requête sont-ils filtrables avant stockage ?
l’adresse IP est-elle journalisée ailleurs que dans les événements ?
quelles sauvegardes contiennent encore les données après suppression ?
le fournisseur réutilise-t-il les données pour son propre compte ?
quels sous-traitants et transferts sont concernés ?
les exports obéissent-ils à la même politique de conservation ?

Une réponse « privacy-friendly » ne remplit aucune colonne.

Étape 4 : confronter les documents

Comparez le résumé technique au registre, au contrat de sous-traitance, à la politique de confidentialité et au bandeau de consentement. Les incohérences sont plus importantes que la qualité littéraire de chaque document pris séparément.

Exemple classique : la politique affirme que seules des statistiques agrégées sont collectées, alors que le gestionnaire de tags envoie un identifiant utilisateur à un outil tiers.

Étape 5 : instaurer une revue liée aux changements

Le document doit être revu lors de toute modification significative :

nouvel outil ;
nouvel événement ;
changement de domaine de collecte ;
activation d’un export ;
nouvelle durée de conservation ;
modification du consentement ;
changement de sous-traitant ;
ajout d’une propriété ou d’un site.

Une revue trimestrielle légère permet aussi de détecter les écarts silencieux.

Les erreurs qui rendent le document inutile

Copier la documentation commerciale

La documentation du fournisseur décrit un produit possible. Votre résumé doit décrire votre instance, vos options et vos flux.

Confondre pseudonymisation et anonymisation

Un identifiant haché ou rotatif peut rester une donnée personnelle s’il permet encore de distinguer ou relier une personne. Utilisez des termes précis et documentez le risque de réidentification.

Oublier les URL

Les URL complètes peuvent contenir des emails, identifiants de commande, termes de recherche interne ou jetons. Même un outil conçu pour collecter peu peut recevoir une donnée excessive si le site place cette donnée dans l’adresse.

Ne documenter que le tableau de bord

Le rapport visible n’est qu’une surface. Les logs, exports, événements bruts, sauvegardes et intégrations comptent aussi.

Laisser le document sans propriétaire

Une fiche parfaite mais non maintenue devient rapidement plus dangereuse qu’une fiche absente, car elle donne une confiance injustifiée.

Checklist de validation

Avant d’approuver le résumé, vérifiez que :

chaque donnée a une finalité spécifique ;
les données reçues et les données stockées sont distinguées ;
les paramètres d’URL et champs libres ont été audités ;
les durées sont définies par couche ;
les destinataires et accès sont nommés ;
le consentement et les modes de configuration sont explicités ;
la suppression est testable ;
le contenu concorde avec les documents publics et contractuels ;
un responsable et une date de revue sont indiqués ;
toute affirmation d’anonymisation est techniquement justifiée.

Conclusion

Un data collection summary n’est pas un document de plus à ranger dans un dossier conformité. C’est une interface commune entre produit, marketing, technique et juridique.

Sa valeur vient de sa précision. Une équipe qui sait exactement ce qu’elle collecte peut supprimer les données inutiles, expliquer les données utiles, configurer correctement ses outils et répondre plus vite aux questions internes ou externes.

Commencez par une seule propriété web et les dix signaux les plus importants. Vérifiez-les dans le réseau et le code, puis élargissez seulement si la collecte réelle le justifie.

FAQ

Le data collection summary est-il obligatoire au titre du RGPD ?

Ce format précis n’est pas imposé par le RGPD. Il peut toutefois aider à produire et maintenir des documents obligatoires ou nécessaires, notamment le registre des traitements et l’information des personnes.

Faut-il publier ce document ?

Pas nécessairement. Il contient souvent des détails techniques internes. Les informations pertinentes pour les personnes doivent être reprises clairement dans la politique de confidentialité ou d’autres notices appropriées.

Une adresse IP non stockée doit-elle apparaître ?

Oui si elle est reçue ou utilisée, même brièvement. Le résumé doit distinguer réception, traitement temporaire, transformation et stockage.

Peut-on utiliser le même résumé pour plusieurs sites ?

Seulement si les flux et configurations sont réellement identiques. Pour un environnement multi-sites, gardez un socle commun et documentez les écarts par propriété.

À quelle fréquence faut-il le mettre à jour ?

À chaque changement significatif de collecte ou de destination, avec une revue périodique. Une vérification trimestrielle est un rythme pratique pour une petite équipe, sans constituer une règle juridique universelle.