Mixpanel et RGPD : guide de conformité 2026

Un projet Mixpanel peut recevoir des événements du navigateur, du serveur et d’un entrepôt de données. Bloquer un SDK ne coupe pas nécessairement les autres sources. L’audit doit donc relier chaque collecte à sa finalité, au choix de la personne et au projet qui la reçoit.

Définir un plan de collecte limité

Listez les événements utiles à votre question produit : création d’un compte, utilisation d’une fonction ou abandon d’une étape. Pour chaque événement, justifiez les propriétés, la durée et les destinataires. Un identifiant technique peut rester une donnée personnelle même s’il ne contient pas de nom.

Évitez les copies de textes libres, les adresses dans les URL et les propriétés collectées « pour plus tard ». Le principe de minimisation de l’Art. 5(1)(c) du RGPD s’applique à l’analyse produit comme aux autres traitements.

Une collecte automatique doit être examinée avec autant de soin qu’un événement manuel. Lorsqu’un besoin peut être satisfait avec un comptage agrégé, documentez pourquoi une chronologie individuelle ou un rapprochement de profils serait nécessaire. Pour le rejeu de session, ajoutez les contrôles de masquage des formulaires.

Examiner l’exemption selon la configuration

Il ne faut pas confondre l’absence de nom avec l’anonymat, ni déclarer qu’une marque est toujours exemptée ou toujours exclue pour toute opération possible. La FAQ cookies de la CNIL décrit les conditions strictes de l’exemption de mesure d’audience.

Un suivi individualisé utilisé pour enrichir un CRM, recouper des parcours ou activer des audiences ne correspond pas à une simple mesure d’audience exemptée. Les opérations non exemptées sur le terminal doivent attendre le consentement. La base légale du traitement des données doit également être documentée.

Pour les événements purement serveur, examinez leur origine et leur finalité : le seul changement de transport ne supprime pas une obligation attachée à la collecte initiale. Le guide du tracking côté serveur expose cette distinction.

Faire respecter le refus sur toutes les sources

Mixpanel documente opt_out_tracking_by_default et les méthodes d’accord ou de refus dans sa page de protection des données. Celle-ci précise que le refus côté client n’affecte pas automatiquement les événements serveur. Les données déjà reçues ne sont pas effacées du seul fait de ce refus.

Votre recette doit donc vérifier séparément le navigateur, les applications, les traitements programmés et les imports. Utilisez un compte fictif et comparez les événements reçus avant accord, après refus et après retrait. Prévenez aussi la réidentification après déconnexion sur un terminal partagé.

Distinguez trois opérations dans la procédure : arrêter les futurs envois, retirer une activation commerciale et traiter une demande d’effacement. Elles ne sont pas interchangeables.

Vérifier les véritables points d’entrée européens

La documentation de résidence européenne distingue le projet et les adresses utilisées par les intégrations. L’ingestion européenne passe par api-eu.mixpanel.com, tandis que les requêtes et exports utilisent d’autres adresses spécifiques. La documentation indique que le transfert automatique des anciens flux américains vers la plupart des projets européens concernés a cessé en juillet 2026.

Vérifiez donc les destinations dans chaque SDK, tâche serveur et connecteur. Ne prenez pas l’adresse européenne du tableau de bord comme preuve que tous les envois suivent la bonne route. Conservez l’identifiant du projet et les paramètres effectivement déployés.

Une résidence européenne ne règle pas à elle seule tous les accès et sous-traitants. Le DPA de Mixpanel du 2 juin 2026 doit être lu avec la configuration et les garanties de transfert applicables.

Ajouter les fonctions d’IA au périmètre de l’audit

Le dossier ne peut plus s’arrêter aux seuls tableaux de bord. La documentation de confidentialité de Mixpanel AI, actualisée le 31 août 2026, décrit des fonctions activées par défaut pour certaines offres, avec des exceptions, et la possibilité de les désactiver dans les réglages de l’organisation.

Elle indique également que certaines entrées et sorties peuvent être traitées par des prestataires d’IA hors de l’Union, même lorsqu’un projet bénéficie de la résidence européenne. Vérifiez les fonctions réellement actives et les données accessibles à leurs utilisateurs avant de les autoriser. Une connexion vers un outil d’IA choisi par votre équipe constitue aussi un flux à examiner.

Organiser conservation et droits

Fixez des durées selon les analyses utiles, puis vérifiez l’effet de la suppression sur les événements, profils, exports et destinations connectées. Conservez seulement les correspondances nécessaires à l’exercice des droits, avec des accès limités.

Évitez de transformer un identifiant analytique en identifiant général partagé avec tous les prestataires. Si des cohortes alimentent le marketing, la procédure de retrait des audiences publicitaires doit couvrir les synchronisations qui pourraient réintroduire la personne.

Transformer une question produit en collecte justifiée

Une fiche par analyse aide à éviter l’accumulation d’événements sans usage défini. Commencez par la décision à prendre : simplifier une étape, comprendre un échec ou mesurer l’adoption d’une fonction. Décrivez ensuite les données strictement nécessaires pour éclairer cette décision. Le fait qu’un champ soit disponible dans l’application ne suffit pas à justifier son envoi à l’outil d’analyse.

Prenons un exemple entièrement fictif. L’éditeur Saule veut comprendre pourquoi la configuration d’un espace de travail est abandonnée. Le projet initial prévoit l’envoi du nom de l’espace, du texte saisi et de l’adresse électronique de son créateur. Une première analyse du besoin pourrait proposer de commencer avec l’étape atteinte, le type d’erreur et la version de l’application, sans ces contenus.

Cette réduction proposée ne démontre pas que les événements restants sont anonymes ni que le consentement est inutile. Il faut encore examiner les identifiants, les rapprochements et les opérations sur le terminal. Elle rend cependant le débat concret : l’équipe produit doit expliquer ce que chaque propriété supplémentaire permettrait réellement de décider. Aucun résultat de mesure ou essai de Mixpanel n’est supposé dans cet exemple.

Préparer une recette qui suit la personne entre les flux

Construisez un parcours de vérification avec des comptes et contenus fictifs. Décrivez l’état initial du choix, l’action effectuée, la source susceptible d’envoyer un événement et le résultat attendu. Le protocole doit être adapté au fondement retenu pour chaque traitement ; tous les événements de l’application ne relèvent pas nécessairement de la même finalité.

Pour un suivi soumis au consentement, examinez notamment la visite avant tout choix, le refus, l’accord puis le retrait. Ajoutez le passage d’une visite non connectée à un compte connecté et, si votre application le permet, l’utilisation d’un autre appareil. Une correspondance entre identifiants ne doit pas transformer silencieusement un ancien refus en autorisation.

La réception de chaque scénario demande plusieurs pièces complémentaires. La capture de l’interface montre le choix présenté. La configuration explique la règle attendue. Les traces d’envoi et de réception permettent d’examiner ce qui s’est produit dans les conditions du parcours. Une absence d’événement observée sur un navigateur ne couvre pas une tâche nocturne ou un import lancé depuis un autre système.

Documentez aussi le traitement des événements en attente. Déterminez à quel moment votre chaîne vérifie le choix applicable et ce qui arrive lorsqu’un retrait intervient avant l’envoi. Si une relance technique peut rejouer des données, elle doit conserver les restrictions pertinentes. Ces questions concernent votre architecture ; les réponses doivent être vérifiées avec les équipes qui administrent chaque source, sans présumer le comportement d’un connecteur.

Donner une suite exploitable aux demandes des personnes

La procédure de droits doit commencer par une recherche maîtrisée. Identifiez les références effectivement utilisées pour relier les données analytiques à une personne, sans collecter de nouvelles informations disproportionnées. Vérifiez ensuite les périmètres concernés : projet, fichiers exportés et destinations alimentées. L’existence d’un outil de suppression chez un prestataire ne prouve pas que toutes les copies détenues par votre organisation seront traitées.

Une demande peut associer retrait du consentement, accès et effacement. Enregistrez ces objets séparément afin de vérifier la réponse apportée à chacun. L’Art. 7(3) du RGPD permet le retrait sans remettre en cause la licéité du traitement antérieur fondé sur le consentement ; l’Art. 17 fixe les conditions de l’effacement. Une conservation résiduelle doit donc être justifiée, et non déduite du seul fait que l’historique était licite lors de sa collecte.

Enfin, faites correspondre la notice aux usages autorisés. Une nouvelle analyse individuelle ou une destination supplémentaire peut modifier les informations à fournir et les choix nécessaires. L’Art. 13(3) exige notamment une information préalable lorsqu’un traitement ultérieur poursuit une autre finalité. Conservez la version de la notice, la décision interne et les paramètres associés pour pouvoir expliquer le fonctionnement du projet à la date concernée.

Ce qu’il faut retenir

• Le plan de collecte doit décrire toutes les sources, pas seulement le SDK web.
• Le refus côté navigateur ne coupe pas automatiquement les envois serveur.
• Vérifiez les points d’entrée européens et les changements de juillet 2026.
• Incluez les fonctions d’IA et leurs prestataires dans l’analyse des flux.

FAQ

Un identifiant haché rend-il les événements anonymes ?

Pas automatiquement. Si les événements restent rattachables à une personne ou à un profil individuel, les règles relatives aux données personnelles peuvent continuer à s’appliquer.

Le retrait du suivi supprime-t-il l’historique ?

Non. L’arrêt des futurs envois et le traitement des données déjà collectées sont deux opérations distinctes à prévoir.

La résidence européenne couvre-t-elle tous les usages d’IA ?

Elle ne permet pas cette conclusion générale. Examinez les fonctions activées et les informations de Mixpanel sur les prestataires et lieux de traitement.

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.