Hébergé à Paris, rien avant le consentement.
Où les données sont traitées, ce que le script fait avant et après l’accord du visiteur, combien de temps tout est conservé, et qui peut y accéder.
La base et le calcul sont en région Paris.
La base de données et les fonctions qui reçoivent les événements tournent au même endroit. Deux services optionnels s’y ajoutent, décrits ci-dessous.
Base de données
Postgres chez Supabase, dans un projet en région Paris. Elle porte les comptes, les espaces, les tests et, par défaut, les événements.
Calcul
Fonctions Vercel en région Paris (cdg1), à côté de la base : configuration publique, réception des événements, pages de l’application.
Événements en volume
Option : quand le volume l’exige, les événements peuvent être écrits dans ClickHouse plutôt que dans Postgres.
Fonctions d’IA
Option réservée aux personnes connectées : la consigne et un plan compact de la page modifiée, les questions à « Demandez à Probant » avec les données de l’espace, et le parcours des sessions résumées, sans identifiant du visiteur, sont envoyés à Mistral AI.
La liste complète, avec les données concernées : sous-traitants.
Le script attend le consentement.
Exiger le consentement est le réglage par défaut d’un espace. Le choix du visiteur se transmet à chaque page, dès que votre outil de consentement le connaît.
Avant l’accord, rien ne se passe.
Dans un espace qui exige le consentement, tant que le visiteur n’a pas accepté, le script ne pose aucun cookie, n’affecte personne, n’applique aucune modification et n’envoie rien. S’il accepte une fois la page affichée, elle ne change pas sous ses yeux : sa variante commence à la page suivante. S’il avait accepté lors d’une visite passée, sa variante s’applique dès le chargement, et rien ne part avant que votre outil de consentement ait confirmé.
// accepté : affectation et mesure, sans bascule de la page affichée probant.consent(true); // refusé ou retiré : cookie et traces locales effacés probant.consent(false);
Un refus efface les traces.
probant.consent(false) efface le cookie et les traces locales, vide la file d’envoi et arrête l’observation de la page, même dans un espace qui n’exige pas le consentement.
Après probant.consent(false)
probant_idcookie effacéprobant_expstockage local effacéprobant_seenstockage de session effacéprobant_filefile en attente effacée- file d’envoividée
- observation de la pagearrêtée
Un lien d’opposition, et aucune exemption revendiquée.
Un visiteur peut s’opposer à la mesure depuis la politique de confidentialité du site, avec le bouton que Probant fournit : le script, le module de parcours et l’aide serveur n’affectent alors plus rien, dans tous les modes, et un accord ultérieur de l’outil de consentement ne lève pas ce refus.
L’outil d’auto-évaluation de la CNIL sur la mesure d’audience exemptée de consentement (juillet 2025) range parmi les fonctions à désactiver par défaut « toute création de cohorte d’utilisateurs pour leur présenter des contenus différenciés, que l’appartenance à une telle cohorte soit définie de manière aléatoire » : c’est le principe même du test A/B. Probant demande donc le consentement par défaut, et ne prétend à aucune exemption. Source : outil d’auto-évaluation de la CNIL (PDF), relevé le 8 novembre 2026.
Lien d’opposition, dans la politique de confidentialité
probant_oppositionrefus gardé 390 joursprobant_idcookie effacé- données de l’identifianteffacées chez Probant
- commandes du back-officegardées, déliées
Un seul identifiant, interne au site, jamais prolongé.
Le script et l’aide serveur lisent le même identifiant : un visiteur voit la même variante quelle que soit la façon dont il a été affecté.
- Nom
probant_id- Portée
- Interne au site de la boutique (first-party), partagé par ses sous-domaines, SameSite=Lax, Secure en HTTPS.
- Contenu
- Un identifiant aléatoire, tiré dans le navigateur ou sur votre serveur. Il ne contient ni nom, ni adresse e-mail.
- Durée
- 390 jours au plus après la première visite, soit moins de 13 mois. Reposé par votre serveur avec l’aide serveur, il garde la même échéance : il n’est jamais prolongé.
- Traces locales
- Les tests vus (
probant_exp, stockage local) et les expositions déjà envoyées dans la session (probant_seen, stockage de session), pour rattacher chaque conversion aux bons tests.
Le détail des cookies du site, de l’application et du script : cookies.
Les événements sont supprimés après 13 mois.
Un événement dit qu’un visiteur est venu, a vu une variante, a converti ou a mesuré quelque chose, avec le contexte de sa visite.
Ce que contient un événement
L’espace, le type (visite, exposition, conversion ou mesure), l’identifiant aléatoire du visiteur, le test et la variante, la métrique et sa valeur, la date d’envoi et la date de réception. Le contexte de la visite : type d’appareil, nouveau visiteur ou non, catégorie de la source, campagne et chemin de la page d’entrée. Ni adresse IP, ni navigateur, ni référent.
La purge
Dans la base Postgres, une tâche planifiée supprime chaque nuit les événements reçus il y a plus de 13 mois. La date retenue est celle de réception, posée par le serveur : un navigateur ne peut pas antidater un événement pour le garder plus longtemps.
Dates acceptées
L’API refuse un événement daté de plus de 7 jours dans le passé ou de plus de 5 minutes dans le futur.
Suppression à la demande
Supprimer un espace depuis ses réglages efface ses tests et, dans la base Postgres, ses événements. Les données d’un visiteur s’effacent à sa demande, à partir de son identifiant.
Une clé par usage, une base fermée par défaut.
Chaque espace a une clé pour le navigateur et des clés pour vos serveurs. La base n’est lisible que par l’application, côté serveur.
Clé publique pk_…
Dans vos pages : elle lit la configuration publique (tests en cours, déploiements, consentement) et envoie les événements. Comme pour tout script navigateur, elle est visible. Vous pouvez la réserver aux domaines de votre site dans les réglages de l’espace. L’API limite aussi le nombre d’appels par clé et par adresse.
Clé secrète sk_…
Pour vos serveurs uniquement : commandes du back-office, API de gestion, serveur MCP, drapeaux. Une clé de gestion se crée en lecture ou en écriture, ne dépasse jamais les droits de la personne qui l’a créée et cesse de servir si elle quitte l’espace. Présentée à l’API publique, elle est refusée.
Assistants connectés
Claude, ChatGPT et les autres assistants se branchent au serveur MCP sans clé : vous autorisez chacun sur un écran de Probant, pour un espace et un accès qui ne dépassent jamais votre rôle. PKCE obligatoire ; jetons d’accès de 60 minutes, valables pour le seul serveur MCP ; jeton de renouvellement remplacé à chaque usage, et toute la connexion révoquée s’il est présenté deux fois. Seules leurs empreintes sont conservées ; chaque connexion se coupe dans les réglages.
Stockage des clés
192 bits d’aléa. Seuls l’empreinte SHA-256, un préfixe non secret et les quatre derniers caractères sont conservés ; la comparaison se fait en temps constant.
Base fermée
Sécurité ligne par ligne activée sur toutes les tables, sans aucune politique, et droits retirés aux rôles anonyme et authentifié : aucune clé de la base n’est envoyée au navigateur. La connexion se fait côté serveur ; l’application relit la session en base à chaque page et vérifie le rôle en un seul endroit.
Chaque action a un auteur.
Sur un site en production, l’équipe sait qui a lancé, arrêté ou déployé quoi, et le propriétaire décide de ce que chacun peut faire.
Double authentification
Par une application d’authentification, avec 10 codes de secours à usage unique. Le propriétaire peut l’exiger pour tout l’espace : sans elle, l’espace reste fermé, actions comprises.
Journal d’audit
Qui a fait quoi, sur quoi et quand : lancements, arrêts et décisions, déploiements, clés, membres, réglages, exports et effacements de données. Filtrable, exportable en CSV, conservé 13 mois.
Rôles et permissions
Des rôles fixes et des rôles composés à partir de permissions nommées. Personne n’attribue plus que ses propres droits ; la facturation, les rôles et la suppression de l’espace restent au propriétaire.
Lancements relus
Un lancement peut exiger l’approbation d’un autre membre. Écrire le JavaScript d’une variante est une permission à part, et chaque écriture est consignée au journal.
L’affectation peut se faire sur votre serveur.
Pour un affichage sans aucun clignotement, l’aide serveur affecte le visiteur avant le rendu, sur votre serveur ou en périphérie de réseau. Elle reçoit le choix du visiteur en paramètre et n’affecte personne sans lui quand l’espace l’exige. Le script reste sur la page pour mesurer.
Lire la documentationassignRequest({ cookieHeader, url, userAgent, config, consent })
// → { visitorId, setCookie, assignments }Probant Ou pas encore…
Créez votre espace, ou explorez d’abord la démo avec les données d’une boutique fictive.
- Démo ouverte, sans inscription
- Forfait fixe, jamais de dépassement
- Données hébergées à Paris