Test A/B respect vie privée : mesurer sans surinterpréter

Un clic sur un onglet montre une action effectuée dans une interface donnée.

Il ne révèle pas pourquoi la personne a cliqué, si ce choix lui convient durablement, si le tirage lui paraît juste ou si la lecture améliore son bien-être.

C’est notre contrat de confiance : ne pas transformer une trace technique limitée en récit intime sur l’utilisateur.

Avant toute mesure, plusieurs faits doivent encore être vérifiés sur la configuration réellement déployée : les événements envoyés, les clés de stockage terminal, les identifiants, les destinataires, les sous-traitants, les points de collecte, la durée de conservation, la suppression et la preuve éventuelle du consentement.

La qualification juridique d’un usage précis de localStorage reste elle aussi à établir selon sa finalité et son fonctionnement.

Sans ces contrôles, aucune exemption ni conformité ne doit être affirmée.

Ce guide propose une méthode éditoriale et technique, pas un avis juridique. Les clics auto-sélectionnés restent descriptifs, un test randomisé n’évalue que l’effet déclaré d’un défaut sur un résultat déclaré, et aucune question, note de journal ou lecture personnelle ne doit entrer dans les données de mesure.

Phase 1 : observer des onglets choisis par l’utilisateur

Dans cette première phase, l’utilisateur voit un même tirage et choisit lui-même un registre de lecture. Cette auto-sélection permet de décrire l’utilisation de l’interface, sans comparer causalement les effets des deux registres.

Pour voir ce qui change entre les deux lectures, il faut revenir au contenu lui-même plutôt que de demander aux données analytiques de l’expliquer.

Avant de compter les clics, définissez qui est éligible à l’observation. Par exemple : une personne ayant chargé la carte commune et vu les deux onglets disponibles. Une visite où l’un des onglets ne s’affiche pas ne constitue pas la même exposition.

Fixez ensuite le moment exact de chaque événement :

exposition lorsque les deux choix sont effectivement affichés ;
selection_explicite au premier clic volontaire sur un onglet ;
changement lors du passage du registre affiché vers l’autre ;
completion lorsque le seuil technique préalablement défini est atteint.

Ce dernier événement est particulièrement facile à surinterpréter. Une fin de défilement ou une action de fermeture peut indiquer qu’un parcours technique est allé jusqu’au point prévu. Elle ne prouve ni lecture attentive ni satisfaction.

Le dénominateur compte autant que le total. « 42 changements » ne dit presque rien si l’on ignore combien de personnes étaient éligibles, combien ont réellement vu les deux onglets et à quel instant l’événement a été déclenché.

Nous retenons donc une règle simple : documenter l’exposition avant de commenter la sélection.

Un contrat d’événements fermé et vérifiable

Un contrat fermé limite chaque propriété à une liste de valeurs prévues. Il refuse les chaînes libres, même lorsqu’elles semblent pratiques pour le débogage. Les noms ci-dessous décrivent un modèle à auditer ; ils ne prétendent pas reproduire les données actuellement déployées sur Arcane Clair.

Événement	Propriétés fermées autorisées	Fait observable	Interprétation non étayée	Charge utile interdite	Dépendance au stockage
`exposition`	`modes_visibles: les_deux`, `support: mobile/ordinateur`, `version_interface: valeur_documentee`	Les deux onglets ont été affichés dans le contexte défini	La personne les a lus, compris ou comparés	Question brute, texte du tirage, note personnelle, sujet relationnel	À préciser ; aucune persistance ne doit être supposée nécessaire
`selection_explicite`	`mode_choisi: intuitif/miroir`, `origine: clic/clavier`	Un mode a été activé explicitement	Motivation, préférence stable, personnalité ou besoin émotionnel	Libellé libre, extrait de journal, contenu généré	À préciser selon la déduplication réellement requise
`changement`	`depuis: intuitif/miroir`, `vers: intuitif/miroir`, `rang: premier/suivant`	L’affichage est passé d’un mode à l’autre	Insatisfaction, hésitation, amélioration ou rejet du premier mode	Texte consulté, réponse saisie, contexte intime	À examiner si le rang est conservé entre pages ou sessions
`completion`	`mode_affiche: intuitif/miroir`, `seuil: valeur_documentee`	Le seuil technique déclaré a été atteint	Lecture complète, bénéfice, vérité, satisfaction ou effet thérapeutique	Défilement détaillé associé au texte privé, enregistrement de session sur les champs privés	À examiner selon le calcul et la portée de session

Exemple annoté : un changement de mode

événement : changement
depuis : intuitif
vers : miroir
rang : premier

Observation défendable : après avoir eu accès aux deux onglets, l’utilisateur a fait passer l’interface du mode intuitif au mode miroir pour la première fois dans la portée définie.

Interprétations interdites : « le mode intuitif était moins bon », « la personne préfère le mode miroir », « elle cherche une réponse sur sa relation », « le second texte l’a davantage aidée ». Le changement ne contient aucune de ces informations.

Données à ne pas joindre : la question posée, une carte de tarot accompagnée de son texte personnalisé, une note libre, le contenu d’une lecture ou un identifiant permettant de reconstituer un parcours intime.

Ce contrat doit être comparé aux requêtes réellement émises par le navigateur. Un beau tableau ne protège rien si un outil ajoute automatiquement une URL détaillée, un identifiant ou la valeur d’un champ privé (c’est précisément le type d’écart qu’un audit doit repérer).

Ce qu’une « préférence » ne prouve pas

Une sélection explicite peut être appelée « choix observé » dans le rapport. Le mot « préférence » exige davantage de prudence, car il suggère parfois une disposition stable que le clic isolé ne mesure pas.

Une personne peut ouvrir le second onglet par curiosité, revenir sur le premier, tester le fonctionnement ou cliquer sans avoir encore lu. Les événements fermés ne permettent pas de départager ces raisons. Ajouter une explication supposée après coup reviendrait à inventer une variable.

Le nombre de completion ne mesure pas davantage la qualité d’une lecture. Même si un mode obtient davantage de parcours achevés, on ne peut pas conclure qu’il favorise une meilleure réflexion, qu’il dit plus vrai ou qu’il procure un bénéfice thérapeutique. Il faudrait définir séparément le résultat recherché, la manière de l’évaluer et les éléments de preuve adaptés.

La formulation du compte rendu doit rester proche de la trace : « parmi les expositions éligibles, le mode miroir a été sélectionné dans telle proportion ». Évitez « les utilisateurs veulent », « les lecteurs ont besoin de » ou « ce mode fonctionne mieux » lorsque les données ne décrivent qu’un clic.

Pour garder les questions personnelles hors de la mesure, la limite la plus sûre reste structurelle : ne jamais prévoir de propriété capable de recevoir ce texte.

Phase 2 : ce qu’exige un défaut randomisé

Un test de défaut randomisé répond à une autre question. Il attribue de façon aléatoire et cohérente le mode affiché par défaut, puis mesure son effet sur un résultat déclaré à l’avance. Il ne transforme pas les clics en témoignages sur la vérité d’un tirage ou la motivation d’une personne.

Dispositif	Attribution	Inférence défendable	Rapport minimal	Règle d’exposition	Examen de confidentialité
Onglets auto-sélectionnés	Choix effectué par l’utilisateur	Description des expositions, sélections, changements et seuils atteints	Population éligible, dénominateur, moment des événements, taux par contexte	Compter seulement lorsque les deux onglets sont disponibles	Vérifier événements, identifiants, destinataires, stockage et textes exclus
Défaut randomisé	Attribution aléatoire cohérente selon un plan déclaré	Effet du défaut attribué sur la métrique déclarée, sous les hypothèses du plan	Métrique, référence, effet minimal détectable, variance, allocation, niveau alpha, puissance et plan d’analyse	Enregistrer l’exposition réelle à la variante attribuée	Examiner la nécessité, le mécanisme d’affectation, la persistance et les destinataires
Exposition fragmentée	Défaut variable ou attribution incohérente entre chargements	Résultats descriptifs difficiles à attribuer ; pas d’effet causal propre	Fréquence des changements d’attribution, pertes, données manquantes et limites	Distinguer attribution prévue et variante réellement affichée	Revoir les écritures terminales et les identifiants avant toute exploitation

Avant le lancement, nommez une métrique principale. Déclarez aussi son niveau de référence, l’effet minimal que le test doit pouvoir détecter, l’estimation de sa variance, la répartition entre variantes, le seuil alpha et la puissance visée. Sans ces éléments, un calcul de taille d’échantillon donnerait une précision trompeuse.

Une ressource consacrée aux tests A/B mentionne une puissance de 80 % ou davantage dans son contexte.

Ce chiffre ne constitue ni une règle universelle ni une réponse automatique pour Arcane Clair : le niveau retenu dépend du plan, de la métrique, du coût des erreurs et de l’analyse prévue (Deng, A/B Testing and Causal Inference).

L’affectation doit rester cohérente. Si une personne reçoit alternativement deux défauts au fil des chargements sans règle documentée, l’exposition se fragmente et l’interprétation se dégrade. Il faut distinguer au minimum l’attribution prévue de la variante effectivement affichée.

Enfin, analysez selon le plan annoncé plutôt qu’en cherchant après coup le segment le plus favorable. Une randomisation teste l’effet du défaut déclaré sur le résultat déclaré. Elle ne teste ni le bien-être, ni la sincérité du texte, ni une supposée « affinité » psychologique.

Stockage terminal et consentement : une décision par finalité

L’article 82 de la loi Informatique et Libertés pose comme règle générale un consentement préalable pour les opérations de lecture ou d’écriture dans le terminal, sous réserve des exceptions applicables.

La CNIL présente notamment le cadre des traceurs ayant pour finalité exclusive de permettre ou faciliter une communication électronique, ou strictement nécessaires à la fourniture d’un service expressément demandé par l’utilisateur (CNIL, lignes directrices relatives aux cookies et autres traceurs).

Ce cadre ne permet pas, à lui seul, de classer l’usage exact de localStorage envisagé ici. Il faut connaître la finalité réelle, les valeurs écrites, leur portée, leur durée, les destinataires et le caractère demandé ou non du service. L’opérateur et une personne qualifiée doivent examiner l’outil dans sa configuration déployée avant de conclure à une exemption ou à l’obligation de recueillir un consentement.

La page de la CNIL datée du 4 juillet 2025 sur les solutions de mesure d’audience fournit une ressource d’auto-évaluation. Elle ne vaut pas certification de l’outil ni de l’installation d’Arcane Clair. Des statistiques présentées comme anonymes peuvent encore reposer, en amont, sur un traitement de données à caractère personnel.

Arbre de décision avant déploiement

La mesure est-elle nécessaire à une finalité précise et documentée ?
- Non → Ne pas mesurer.
- Oui → Une lecture ou une écriture a-t-elle lieu dans le terminal ?
  - Non → Mesurer au minimum, après vérification du reste du traitement.
  - Oui → Une exception liée au service demandé pourrait-elle s’appliquer ?
    - Non → Rechercher le consentement avant l’opération.
    - Oui ou incertain → La configuration exacte a-t-elle fait l’objet d’un examen qualifié ?
      - Oui → Appliquer la conclusion documentée et mesurer au minimum.
      - Non → Non résolu : ne pas déployer.

Cet arbre sert à bloquer une décision insuffisamment instruite. Il ne remplace pas l’analyse juridique. En cas de doute sur une propriété, une clé ou un destinataire, la bonne sortie n’est pas « probablement exempté », mais « non résolu : ne pas déployer ».

Liste de contrôle de la configuration

Données interdites dans la mesure

Certains contenus doivent rester hors du schéma, même s’ils faciliteraient une segmentation. Nous excluons la question brute, les notes de journal, le texte d’une lecture générée, les sujets relationnels et tout champ libre susceptible de révéler un contexte intime.

La même règle s’applique aux filtres et aux libellés. Remplacer une phrase personnelle par une catégorie telle que « rupture », « santé » ou « conflit familial » ne rend pas automatiquement la collecte acceptable. Cette propriété continue de révéler le contexte que le contrat cherche à écarter.

Contrôle d’exclusion avant mise en production

Aucun événement ne reçoit de texte libre.
Aucun paramètre d’URL ne transporte une question ou une note.
Aucun intitulé analytique ne reprend le contenu d’une lecture.
Aucun filtre ne révèle un sujet relationnel ou intime.
Aucun enregistrement de session ne couvre les champs privés.
Aucun message de débogage ne copie leur contenu.
Les valeurs autorisées sont des énumérations fermées et documentées.
Tout ajout de propriété déclenche un nouvel examen.

Un outil de relecture de session ne doit pas enregistrer les zones privées, même pour résoudre un défaut d’interface. Le masquage annoncé par un fournisseur doit être vérifié dans les données effectivement reçues ; à défaut, l’outil reste désactivé sur ces parcours.

Pour une cartographie plus large des catégories de données et de leurs sorties, consultez le dossier consacré aux données privées du journal.

Auditeur local du schéma d’événements

L’auditeur doit fonctionner localement, sans envoyer les réponses vers une interface externe. Il accepte seulement des choix fermés pour l’événement, les identifiants, les destinataires, le stockage terminal, la conservation, l’usage entre sites et la présence éventuelle de champs libres.

Entrée	Choix attendus	Signal de blocage
Événement	`exposition`, `selection_explicite`, `changement`, `completion`	Tout autre événement non documenté
Identifiants	`aucun`, `session`, `persistant`, `inconnu`	Valeur persistante ou inconnue sans examen
Destinataires	`interne`, `sous_traitant_documente`, `inconnu`	Destinataire inconnu
Stockage terminal	`aucun`, `session`, `persistant`, `inconnu`	Opération ou finalité non examinée
Conservation	`documentee`, `non_documentee`	Durée non documentée
Usage entre sites	`non`, `oui`, `inconnu`	Oui ou inconnu
Champ libre	`absent`, `present`	Présence de texte libre

Le résultat attendu est une liste d’actions : retirer la charge utile interdite, documenter la propriété manquante, vérifier le destinataire ou suspendre le déploiement. L’auditeur ne doit jamais accepter un exemple de question personnelle, appeler une interface externe, rendre un verdict juridique ou calculer une taille d’échantillon.

Une seule URL canonique pour les deux registres

Les deux onglets présentent des états d’une même page. Ils doivent donc rester sur une URL canonique unique, sans créer de variante indexable pour chaque mode. Le contenu commun, le tirage partagé et les changements d’état appartiennent à une seule entité éditoriale.

Une valeur locale peut piloter l’onglet visible si son usage a passé l’examen de confidentialité et de consentement. Elle ne doit pas produire des adresses distinctes que les moteurs pourraient traiter comme des pages concurrentes. Il faut vérifier la balise canonique rendue, les liens internes et l’absence de variantes indexables.

Google Search Central recommande une URL canonique cohérente pour consolider les signaux de pages dupliquées. Cette recommandation concerne l’indexation, pas la confidentialité : une balise canonique n’empêche ni la collecte d’un paramètre, ni l’accès à une URL, ni la transmission d’une donnée sensible.

Conservez donc un seul chemin pour retrouver le guide des deux lectures, puis gérez le changement d’onglet comme un état d’interface contrôlé.

Registre des points encore non vérifiés

Chaque ligne non résolue doit rester visible jusqu’à l’examen de la configuration réelle. Une supposition ne devient pas un fait parce qu’elle paraît techniquement probable.

Point à vérifier	État publiable	Preuve attendue avant déploiement
Noms et contenus des clés de stockage	Non résolu	Inspection du navigateur et inventaire de chaque lecture ou écriture
Destinataires des événements	Non résolu	Configuration de l’outil et requêtes réseau
Sous-traitants impliqués	Non résolu	Registre contractuel et chaîne de traitement
Points de collecte	Non résolu	Liste des domaines, chemins et serveurs destinataires
Identifiants de session ou persistants	Non résolu	Charge utile réelle, cookies et stockage terminal
Comportement entre sites	Non résolu	Test de navigation et documentation technique
Durée de conservation	Non résolu	Paramétrage actuel et règle de suppression
Suppression effective	Non résolu	Procédure documentée et essai contrôlé
Preuve du consentement	Non résolu	Mécanisme, horodatage et portée applicables
Statut au regard de la liste d’auto-évaluation de la CNIL	Non résolu	Évaluation datée de la configuration exacte

Aucune durée numérique actuelle ne ressort des textes officiels capturés pour cette configuration. Les anciennes valeurs de 13 ou 25 mois ne doivent donc pas être reprises comme limites actuelles. Tant que la conservation n’est pas documentée, le tableau reste marqué « non résolu ».

Questions fréquentes

Un clic sur un mode prouve-t-il une préférence ?

Non. Il montre une sélection observée dans un contexte précis, pas sa motivation ni une préférence stable. Le rapport doit indiquer l’exposition, le choix disponible et le moment du clic.

Quelle différence entre préférence et test A/B ?

L’auto-sélection décrit ce que les utilisateurs choisissent, tandis qu’un test A/B attribue aléatoirement et de façon cohérente un défaut. Ce test exige une métrique, une référence et un plan d’analyse déclarés avant d’observer les résultats.

Quelles données Arcane Clair ne doit jamais mesurer ?

Arcane Clair ne doit jamais mesurer les questions brutes, les notes de journal, les textes de lecture ni les contenus libres intimes. Ces données doivent être exclues techniquement du schéma, des paramètres d’URL, des journaux de débogage et des enregistrements de session.

Faut-il un consentement pour mémoriser le mode choisi ?

Le consentement préalable constitue la règle générale pour une opération de lecture ou d’écriture dans le terminal, sous réserve des exceptions prévues par l’article 82. La finalité et la configuration exactes de cette mémorisation restent non résolues ici ; elles nécessitent un examen qualifié avant tout déploiement ou toute affirmation d’exemption.

Pourquoi garder les deux modes sur la même URL ?

Une seule URL conserve une entité éditoriale commune et évite de créer des variantes d’état indexables. La balise canonique aide à consolider les URL pour les moteurs de recherche, mais elle ne protège pas les données et ne remplace aucun contrôle de confidentialité.

Vérifier chaque événement et laisser les textes personnels hors mesure

Avant d’activer la persistance ou l’analyse, confrontez chaque événement au contrat fermé, inspectez la charge utile réelle et bloquez tout champ privé. Si une finalité, une durée, un destinataire ou une opération terminale reste inconnu, gardez la mesure désactivée jusqu’à sa vérification.

Sources

CNIL, lignes directrices relatives aux cookies et autres traceurs et exceptions de l’article 82, texte examiné le 8 août 2026.
CNIL, « Cookies : solutions pour les outils de mesure d’audience », page datée du 4 juillet 2025 et examinée le 8 août 2026.
Google Search Central, consolidation des URL en double, documentation examinée le 8 août 2026.
Deng, « A/B Testing and Causal Inference », ressource capturée le 8 août 2026.
Plan de site figé Arcane Clair, section 5.3, et recherche validée G4, état au 8 août 2026 : interdictions relatives aux données et registre de déploiement non résolu.

Dernière mise à jour : 8 août 2026

Information générale uniquement, sans avis juridique ni certification de la CNIL. La qualification du stockage terminal, le consentement, les destinataires, les charges utiles et la conservation doivent être vérifiés sur la configuration déployée par l’opérateur, l’équipe d’analyse et une personne juridiquement qualifiée. Aucun texte de question, de journal ou de lecture ne doit être envoyé dans les données analytiques.