Niveaux de confiance

Tous les événements ne méritent pas la même confiance. Une write key publique est livrée dans le source de votre page ; tout ce qu’un navigateur affirme, le propriétaire du navigateur peut le forger. Kilden rend explicite le niveau de confiance de chaque événement au lieu de faire comme s’il n’existait pas.

Les trois niveaux

Niveau	Comment il s’établit	verified
Client	Write key publique, aucune preuve d’identité	Événements anonymes : false par convention — il n’y a pas d’identité à vérifier, et rien ne les traite comme suspects. Événements identifiés sans token valide : false, au sens de non prouvé
Client vérifié	Write key publique + un JWT de vérification d’identité valide, signé par votre backend (sub = le distinct_id de l’événement)	true
Serveur	Write key secrète, depuis votre backend uniquement	true — la clé secrète est l’authentification

La vérification est toujours calculée, sur chaque événement identifié, quel que soit le mode d’application du projet — le mode monitor mesure donc exactement ce que enforce bloquerait.

Quelles fonctionnalités en tiennent compte

• Analytics : tout compte. Les événements non vérifiés sont conservés (verified: false), jamais jetés ni réécrits — ce sont des données, simplement pas des données de confiance.
• Déclencheurs de campagne : les personnes identifiées doivent être vérifiées pour démarrer un parcours. Les événements anonymes passent. Les événements de sortie passent toujours (sortir est la direction sûre).
• Mutations d’identité ($identify, $set, $set_once) : gouvernées par le mode du projet — en enforce, les mutations non vérifiées d’utilisateurs identifiés ne peuvent ni créer ni modifier de personnes.
• Lectures de messagerie (messenger in-app à venir) : vérification toujours exigée, dans tous les modes — lire le fil de messages de quelqu’un n’est pas un risque de type “monitor”.

Deux classes de write keys

• Clé publique — sûre à embarquer dans les navigateurs et applis mobiles. Identifie le projet, n’authentifie rien. Peut être restreinte avec les origines autorisées.
• Clé secrète — backend uniquement, jamais embarquée dans un client. Les événements envoyés avec sont des faits serveur. L’API decide rejette carrément les clés secrètes (403) pour qu’elles ne soient jamais tentées de finir dans du code frontend.

Règle simple : les données qui doivent être vraies passent côté serveur. Revenu, état d’abonnement, tout ce qui déclenche de l’argent ou de la messagerie — envoyez-le depuis votre backend avec la clé secrète. Utilisez le navigateur pour le comportement, le backend pour les faits, et la vérification d’identité pour rendre l’identité navigateur digne de confiance.