Panel : une mesure d’audience qui ne peut suivre personne
Un outil d’analytics web sans cookie et sans bandeau de consentement, en production sur panel.raicode.tech, conçu, développé et exploité par Raicode.
Contexte
Mesurer son audience sans bandeau cookie
La plupart des outils d’analytics reconnaissent un visiteur d’un jour à l’autre grâce à un cookie ou à un identifiant stocké sur son appareil, et c’est ce stockage qui impose un bandeau de consentement. Panel part de la contrainte inverse : un visiteur est identifié par une empreinte calculée avec un secret remplacé chaque nuit, l’ancien étant détruit. L’adresse IP sert à calculer cette empreinte et à déduire un pays, puis elle disparaît : elle n’est écrite ni en base ni dans un journal. Reconnaître quelqu’un le lendemain n’est pas interdit par une règle, c’est impossible par construction.
Réalisation
Ce que nous avons livré
Un script de suivi léger
Une seule balise à coller. Le script ne dépose aucun cookie, n’écrit rien dans le navigateur et retire de l’URL la chaîne de requête, hormis les paramètres utm_. Son poids compressé est plafonné, et le build échoue s’il dépasse ce budget ou si une API de stockage y apparaît.
Une collecte qui ne dit rien
Le point de collecte répond 204 à toute requête, valide ou non, pour ne jamais confirmer qu’une clé existe. Les événements passent par une file Redis avant d’être écrits par lots dans PostgreSQL.
Un tableau de bord d’audience
Pages vues, visiteurs, pages d’entrée et de sortie, référents et campagnes, pays, appareil, navigateur et temps réel, avec un filtre sur chaque ligne.
Événements, objectifs et entonnoirs
Des événements nommés anonymes, des objectifs et des entonnoirs comptés dans la journée, puisque rien ne relie un visiteur à celui du lendemain.
Partage et rapport du lundi
Des tableaux de bord partagés par lien, révocables et protégeables par mot de passe, et un rapport envoyé chaque lundi par e-mail, avec une désinscription qui ne demande pas de se connecter.
Search Console et manifeste de collecte
La connexion à Google Search Console fait remonter les requêtes de recherche que le référent ne transmet plus. Chaque site peut publier une page qui décrit les données collectées, générée à partir du code.
Architecture
Une stack simple, tenue par des tests
API
Fastify, Prisma et better-auth
Une API Node.js en TypeScript : Fastify, Prisma sur PostgreSQL et une authentification better-auth avec vérification de l’adresse e-mail. Redis porte la file d’ingestion, les compteurs temps réel, le secret du jour et la limitation de débit.
Application
React et Vite
Le tableau de bord est une application React construite avec Vite, TanStack Query, Tailwind CSS et i18next. L’interface existe en français et en anglais, et ses tests vérifient le comportement plutôt que le balisage.
Site
Next.js
Le site public, bilingue, est prérendu au build et servi sur le même domaine que l’application et l’API.
Données
Isolation des données
Les données de chaque organisation passent par une instance Prisma qui ajoute le filtre d’organisation à chaque opération. Un accès aux données d’une autre organisation répond 404, jamais 403, pour ne pas confirmer qu’elles existent. Chaque organisation gère ses sites, ses clés publiques révocables et les invitations de son équipe.
Pays
Une géolocalisation hors ligne
Le pays est déduit d’une base embarquée dans l’image de l’API : aucune adresse IP n’est envoyée à un service tiers.
Monorepo
Un contrat partagé
Un monorepo pnpm et Turborepo. Le chemin du script et les règles de masquage des URL sont définis une fois dans un paquet partagé, lu par l’API, l’application et le site.
Exploitation
En production, et maintenu
Docker et Dokploy
GitHub Actions construit trois images, l’API, l’application et le site, et les publie sur GHCR. Le serveur ne compile jamais : Dokploy récupère les images et les lance avec Docker Compose.
Une CI qui teste ce qui casse
À chaque pull request : lint, vérification des types, tests unitaires, tests d’intégration sur une vraie base PostgreSQL et tests du script de suivi dans un vrai Chromium. Sur main, des parcours Playwright de bout en bout et des vérifications sur la pile Docker complète.
Un budget mémoire écrit
Chaque service déclare sa limite mémoire, et leur somme reste sous la mémoire libre d’un serveur partagé avec d’autres projets.
Un arrêt propre
Des sondes /health et /ready. À l’arrêt, l’API cesse d’annoncer qu’elle est prête et termine les requêtes en cours avant de fermer.
Méthode
Ce que Panel dit de notre façon de construire un MVP
Panel a été construit comme nous construisons un MVP pour un founder. La promesse produit est écrite d’abord, puis tenue dans le code plutôt que dans le discours. Le périmètre se définit aussi par ce qu’on refuse : aucune fonctionnalité qui exigerait un identifiant persistant. Les risques les plus coûteux, comme une fuite de données d’une organisation à l’autre, sont couverts par des tests d’intégration. La mise en production est outillée dès le départ, avec les images Docker, la CI et les sondes de santé. Et une fois en ligne, nous exploitons le produit.
Votre produit est le prochain ?
Parlez-nous de votre idée ou de votre projet bloqué : nous vous répondons sous 48 h.