Anonymiser les adresses IP pour le RGPD : guide pratique

L'adresse IP est l'une des données les plus discrètes que collecte un site web. Elle figure dans les logs Apache et Nginx, dans les outils de mesure d'audience, dans les bases applicatives et les systèmes anti-fraude. Elle est aussi, depuis l'arrêt Breyer de 2016, une donnée personnelle au sens du RGPD.

L'anonymiser ou la pseudonymiser n'est pas un gadget : c'est une mesure de minimisation que la CNIL attend explicitement, et qui réduit fortement les risques en cas de fuite ou de demande d'accès. Cet article passe en revue les méthodes concrètes, les outils, et les pièges classiques.

Pourquoi l'IP est-elle une donnée personnelle ?

Le RGPD définit la donnée personnelle à l'article 4(1) comme « toute information se rapportant à une personne physique identifiée ou identifiable ». Le critère clé est l'identifiabilité, même indirecte.

L'arrêt Breyer (CJUE, 19 octobre 2016, C-582/14) a tranché la question pour les adresses IP dynamiques : elles sont des données personnelles dès lors que l'opérateur du site dispose de moyens légaux raisonnables pour remonter à l'identité de la personne, typiquement en sollicitant le fournisseur d'accès. La Cour de cassation française a confirmé cette ligne dans plusieurs arrêts.

La CNIL en tire deux conséquences pratiques :

• la collecte d'IP est un traitement qui doit reposer sur une base légale (intérêt légitime, exécution contractuelle, obligation légale...) ;
• la durée de conservation doit être justifiée et proportionnée (souvent 6 à 13 mois selon la finalité).

Anonymisation, pseudonymisation, hachage : les bonnes définitions

Le vocabulaire compte, parce que les obligations diffèrent.

• Anonymisation (considérant 26 du RGPD) : traitement irréversible qui rend impossible la réidentification, même en croisant avec d'autres jeux de données. Une donnée réellement anonyme sort du champ du RGPD.
• Pseudonymisation (article 4(5)) : traitement réversible qui dissocie la donnée d'un identifiant direct, mais permet la réidentification avec une clé secrète. La donnée reste personnelle au sens du RGPD.
• Hachage simple (SHA-256 sur l'IP, par exemple) : c'est une pseudonymisation, pas une anonymisation. Le même input produit toujours le même hash, donc une attaque par dictionnaire (l'espace IPv4 fait 4 milliards de valeurs) reconstitue trivialement l'IP.

Pour une vraie anonymisation, le G29 (groupe de travail Article 29, ancêtre du Comité européen de la protection des données) a fixé trois critères cumulatifs dans son avis 05/2014 :

1. Individualisation : peut-on encore isoler une personne dans le jeu de données ?
2. Corrélation : peut-on lier des enregistrements concernant la même personne ?
3. Inférence : peut-on déduire des informations sur une personne avec une probabilité significative ?

Si une seule des trois réponses est oui, l'anonymisation est considérée comme imparfaite et le RGPD continue de s'appliquer.

Les méthodes concrètes pour les IP

Trois techniques tiennent la route en production. Elles ont chacune leurs avantages et leurs limites.

1. Masquage des derniers octets

Pour une IPv4 203.0.113.42, on réécrit l'octet de droite : 203.0.113.0. C'est la méthode recommandée par la CNIL pour la mesure d'audience exemptée de consentement : trois premiers octets conservés pour la géolocalisation grossière, dernier octet supprimé.

Pour IPv6 (128 bits), on tronque généralement les 64 ou 80 derniers bits. Beaucoup d'outils opèrent par défaut sur 80 bits.

Avantages : simple, rapide, lisible. Inconvénient : dans certaines configurations (opérateur très petit, IP fixe), la réidentification reste possible.

2. Hachage avec sel rotatif

Pour conserver une clé de regroupement (compter un visiteur unique sur la journée) sans stocker l'IP, on hache l'IP avec un sel qui change chaque jour. Le même visiteur produit le même hash à J0, mais un hash différent à J+1. Plausible et Umami fonctionnent sur ce principe.

Le sel doit être stocké en mémoire et purgé en fin de journée : si vous le persistez, la pseudonymisation devient réversible et l'anonymisation tombe.

3. Suppression pure et simple

Si vous n'avez aucun usage de l'IP, le mieux est de ne pas la stocker. Apache, Nginx et la plupart des frameworks permettent de configurer des formats de log sans IP, ou avec une IP réécrite avant écriture sur disque.

Apache : anonymiser dans les logs

Le mod_remoteip permet d'utiliser le bon header (souvent X-Forwarded-For derrière un reverse proxy), mais il n'anonymise pas tout seul. Pour masquer le dernier octet d'une IPv4 dans les logs, une approche courante consiste à injecter mod_rewrite et mod_log_config :

SetEnvIf REMOTE_ADDR "^(\d+\.\d+\.\d+)\." MASK_IP=$1.0
LogFormat "%{MASK_IP}e %l %u %t \"%r\" %>s %b" anon
CustomLog /var/log/apache2/access.log anon

Les logs ne contiennent plus que le préfixe /24. La géolocalisation grossière reste possible, mais l'identification d'un poste précis derrière un FAI ne l'est plus.

Pour IPv6, la réécriture est plus subtile, et il est souvent plus simple de passer par un script externe comme Anonip (outil maintenu par la Digitale Gesellschaft suisse), invoqué via un pipe sur la sortie des logs.

Nginx : même approche

Nginx ne peut pas piper directement vers un programme externe en mode log_format, mais il sait écrire dans une FIFO. Le schéma classique :

map $remote_addr $masked_ip {
    "~(?<ip>\d+\.\d+\.\d+)\.\d+"  "$ip.0";
    default                       "0.0.0.0";
}

log_format anon '$masked_ip - $remote_user [$time_local] '
                '"$request" $status $body_bytes_sent';

access_log /var/log/nginx/access.log anon;

Le module ipscrub apporte une variante avec hachage rotatif si vous avez besoin de garder un identifiant de session anonymisé.

Matomo : côté analytics

Matomo intègre nativement l'anonymisation IP au niveau du tracker, avant écriture en base. La configuration se fait dans Administration > Confidentialité > Anonymiser les données. Trois options principales :

• masquer 1 octet (géolocalisation précise, anonymisation faible) ;
• masquer 2 octets (géolocalisation région, anonymisation moyenne) ;
• masquer 3 octets (géolocalisation pays seulement, anonymisation forte recommandée par Matomo).

L'IP masquée peut aussi être utilisée pour la géolocalisation au lieu de l'IP complète (option « Use anonymized IP for enriching visits ») : c'est ce qu'il faut activer pour rester dans le cadre exempté de consentement de la CNIL.

Matomo offre également l'option de purger automatiquement les visiteurs anciens, et un job de suppression des données brutes passé un délai paramétrable.

Applicatif : minimiser dès la collecte

Pour les applications métier qui stockent des IP (auth, antifraude, audit), trois bonnes pratiques :

• Séparer la collecte technique de la conservation : l'IP peut servir à vérifier une session sans être stockée durablement. Après usage, elle est masquée ou supprimée.
• Pseudonymiser dans la base : stocker un hash salé (sel par enregistrement, pas par utilisateur) plutôt que l'IP en clair. Permet de répondre « cette IP a-t-elle déjà tenté de se connecter ici ? » sans conserver de valeur identifiante directe.
• Définir une durée de rétention claire : la CNIL accepte 6 à 12 mois pour les logs de sécurité selon les cas, plus si une obligation légale s'applique (LCEN : 1 an pour certaines données de connexion).

Les pièges classiques

Quelques erreurs récurrentes vues en audit :

• L'IP en clair dans plusieurs endroits : anonymisée dans Matomo mais pas dans les logs Apache. La fuite reste possible côté serveur web.
• Le reverse proxy qui écrit l'IP réelle dans un header non masqué : derrière Cloudflare ou un load balancer, le X-Forwarded-For contient l'IP cliente. Il doit être soumis aux mêmes règles que REMOTE_ADDR.
• Les sauvegardes oubliées : anonymiser la production sans toucher les sauvegardes des 12 derniers mois est une demi-mesure. Il faut soit anonymiser aussi les archives, soit purger les anciennes sauvegardes selon une politique formalisée.
• La bannière cookies inutile : si votre Matomo est configuré selon les recommandations CNIL (anonymisation IP forte, pas de croisement, pas de cookies persistants), vous pouvez vous passer de bannière. Beaucoup de sites en imposent une par réflexe alors que ce n'est pas nécessaire.

Récapitulatif : la chaîne à auditer

Pour aller plus loin sur le sujet : Cloud Act et RGPD : pourquoi héberger en France, Sortir de Google Analytics et Les pages légales obligatoires d'un site web.

Datacampus, Matomo et l'infogestion

Chez Datacampus, on installe Matomo en infogestion avec la configuration RGPD pré-câblée (anonymisation IP forte, durées de conservation alignées, exemption de consentement documentée quand c'est applicable). Sur les serveurs web infogérés, on peut aussi appliquer le masquage IP au niveau Apache ou Nginx, et accompagner la formalisation de la politique de rétention. Pour discuter de votre cas : contact.