Comment construire un dashboard admin RGPD en solo

Un dev solo a autant besoin de metriques qu'une equipe de 50 personnes. Peut-etre meme plus. Quand tu es seul a gerer le backend, le frontend, le marketing et le support, tu ne peux pas te permettre de deviner ce qui se passe. Tu as besoin de voir : combien d'utilisateurs sont actifs, quelles fonctions sont utilisees, est-ce que le backend tient la charge, est-ce que le pipeline vocal plante.

J'ai construit un dashboard admin complet pour TAMSIV, un systeme d'alertes email pour les incidents critiques, et un tracking analytics conforme au RGPD. Voici comment tout ca s'articule, et pourquoi chaque brique est indispensable quand tu operes en solo.

Points cles a retenir :
- Un dashboard admin n'est pas un luxe — c'est vital pour un dev solo en production
- GA4 avec Consent Mode permet d'etre conforme au RGPD sans sacrifier les metriques
- Les alertes email (AlertService) detectent les problemes avant les utilisateurs
- Le cookie consent a 3 toggles avec versioning est le minimum RGPD en Europe
- Le double tracking (GA4 + Supabase) couvre les metriques web ET les metriques metier

Pourquoi un dev solo a-t-il besoin d'un dashboard admin ?

La reponse courte : parce que tu n'as pas d'equipe SRE, pas de product manager, pas d'analyste. Tu es tout ca a la fois. Et sans visibilite sur ce qui se passe dans ton app, tu prends des decisions a l'aveugle.

Avant le dashboard, je decouvais les problemes par les retours utilisateurs (quand ils prenaient la peine d'ecrire). Un crash du pipeline vocal pouvait rester invisible pendant des heures. Un pic d'inscriptions passait inapercu. Une fonctionnalite que personne n'utilisait continuait de me couter du temps de maintenance.

Le dashboard admin a change ca. Accessible a /admin/dashboard sur tamsiv.com, il me donne une vue en temps reel de tout ce qui compte :

• Utilisateurs : Inscriptions quotidiennes, utilisateurs actifs (DAU/WAU/MAU), retention
• Fonctionnalites : Utilisation du dictaphone, creation de taches/memos/evenements, gamification
• Infrastructure : Latence WebSocket, taux d'erreur STT, fallback LLM declenches
• Business : Conversions Free → Pro, revenus RevenueCat, taux de desabonnement

Comment construire un dashboard admin avec Recharts et Supabase ?

Le dashboard est construit avec Recharts, une librairie de graphiques React basee sur D3.js. Pourquoi Recharts ? Parce qu'elle s'integre nativement avec React, supporte le SSR (important pour Next.js), et le rendu est propre sans configuration complexe.

L'architecture est simple :

1. Donnees : Tout vient de Supabase via des fonctions RPC. Chaque graphique a sa propre RPC qui aggrege les donnees cote serveur.
2. Cartes de stats : En haut du dashboard, des cartes montrent les KPI en temps reel (total utilisateurs, actifs aujourd'hui, taches creees, etc.).
3. Graphiques temporels : Courbes d'inscriptions quotidiennes, utilisation par fonctionnalite, histogrammes de retention.
4. Tableaux : Liste des derniers evenements (inscriptions, erreurs, alertes).

Un point important : les RPC Supabase utilisent des parametres avec le prefixe p_ (convention du projet). Par exemple, p_start_date, p_end_date, p_metric_type. Ces RPC font les calculs d'aggregation directement en PostgreSQL — bien plus performant que de rapatrier des milliers de lignes cote client.

Le dashboard est protege par une verification de role admin au niveau du middleware Next.js. Seuls les utilisateurs avec le role admin dans Supabase Auth peuvent y acceder.

Qu'est-ce que l'AlertService et pourquoi est-il critique en production ?

Le dashboard, c'est pour quand tu es devant ton ecran. Mais les incidents n'attendent pas que tu ouvres le dashboard. L'AlertService est mon systeme de veille automatique qui m'envoie un email quand quelque chose d'anormal se produit.

Voici les alertes configurees :

• Fallback LLM declenche : Quand le modele principal (via OpenRouter) echoue et que le fallback prend le relais. Ca indique un probleme chez le provider ou un pic de charge.
• Erreurs repetees pipeline vocal : Si le STT ou le TTS echouent plus de X fois en Y minutes, je recois un email. Ca peut indiquer une panne Deepgram ou un probleme de quota OpenAI.
• Rate limiting excessif : Si un utilisateur ou une IP declenche le rate limiter de maniere repetee, ca peut etre un abus ou un bot.
• Echec d'inscription : Si le flow d'inscription (email ou QR code) echoue pour plusieurs utilisateurs, il y a probablement un bug.

Les emails sont envoyes via Resend, un service d'email transactionnel simple et fiable. Chaque alerte est aussi loguee dans une table Supabase pour l'historique — je peux retrouver l'historique des incidents dans le dashboard admin.

Comment implementer GA4 avec le Consent Mode RGPD ?

Le RGPD (Reglement General sur la Protection des Donnees) est non-negociable pour un site europeen. Ca signifie : pas de tracking sans consentement explicite. Google Analytics 4 supporte nativement le Consent Mode, un mecanisme qui ajuste son comportement selon le consentement de l'utilisateur.

Voici comment ca fonctionne dans tamsiv.com :

1. Initialisation en mode "denied" : GA4 est charge au demarrage du site, mais avec analytics_storage: 'denied' et ad_storage: 'denied'. Aucune donnee n'est collectee.
2. Consentement explicite : Quand l'utilisateur accepte les cookies analytics dans la banniere, le consentement est mis a jour via gtag('consent', 'update', { analytics_storage: 'granted' }).
3. Modelisation : Avec le Consent Mode, Google utilise la modelisation pour estimer les donnees des utilisateurs qui n'ont pas consenti. Tu obtiens des tendances fiables meme si 50% des visiteurs refusent le tracking.

Le tag GA4 (G-VVLHW673V3) est initialise une seule fois, au premier chargement de page. Le consentement est persiste dans un cookie first-party et restaure a chaque visite. Si l'utilisateur change d'avis, il peut modifier ses preferences dans la banniere cookies accessible depuis le footer.

Comment concevoir un cookie consent conforme au RGPD ?

La banniere cookie de TAMSIV a 3 toggles, chacun avec un role precis :

• Necessaires (toujours actifs, non desactivables) : Session auth, preferences de langue, consentement cookie lui-meme. Sans ces cookies, le site ne fonctionne pas.
• Analytics (desactive par defaut) : GA4, metriques de navigation Supabase. Active uniquement apres consentement.
• Marketing (desactive par defaut) : Prevu pour le futur (retargeting, pixels publicitaires). Desactive pour l'instant car pas utilise.

Un point souvent neglige : le versioning du consentement. Si la politique de cookies change (ajout d'un nouveau tracker, modification des finalites), la banniere doit reapparaitre pour tous les utilisateurs, meme ceux qui ont deja consenti. J'ai implemente ca avec un numero de version stocke dans le cookie de consentement. Quand la version change, la banniere se reaffiche.

Pourquoi utiliser un double tracking GA4 + Supabase ?

GA4 est excellent pour les metriques web standard : pages vues, taux de rebond, sources de trafic, conversions. Mais il y a des metriques que GA4 ne peut pas capturer, ou pas assez finement :

• Parcours conversion detaille : Le chemin exact d'un visiteur de la landing page a l'inscription, avec les interactions intermediaires (clic CTA, ouverture FAQ, changement de langue).
• Metriques metier : Nombre de taches creees via le web vs l'app mobile, taux de completion des taches, activite de gamification.
• Attribution multi-device : Un utilisateur qui decouvre le site sur desktop et telecharge l'app sur mobile. GA4 ne fait pas ce lien. Supabase, avec l'UUID d'auth, si.

Le tracking Supabase fonctionne avec un UUID anonyme par visiteur (genere au premier chargement, stocke dans le localStorage). Chaque interaction significative est loguee dans une table Supabase. Quand le visiteur s'inscrit, l'UUID anonyme est lie a son compte auth — ce qui permet de reconstruire le parcours complet, du premier clic a l'inscription.

Ce double tracking me donne deux lectures complementaires : GA4 pour les tendances macro (d'ou viennent les visiteurs, quelles pages performent) et Supabase pour les insights micro (quel est le parcours type qui mene a une conversion).

Quelles metriques suivre en priorite pour une app mobile ?

Quand tu demarres, tu es tente de tout mesurer. Mauvaise idee — tu te noies dans les donnees sans actionner quoi que ce soit. Voici les metriques que je suis en priorite dans le dashboard TAMSIV :

1. DAU (Daily Active Users) : Le pouls de l'app. Si ca baisse, quelque chose ne va pas.
2. Taux de retention J1/J7/J30 : Combien d'utilisateurs reviennent. C'est la metrique la plus importante pour un produit de productivite.
3. Taux de completion premiere tache : Est-ce que les nouveaux utilisateurs reussissent a creer leur premiere tache ? Si non, l'onboarding a un probleme.
4. Conversion Free → Pro : Le nerf de la guerre. Combien d'utilisateurs gratuits passent payants, et apres combien de jours d'utilisation.
5. Taux d'erreur pipeline vocal : Le pourcentage de conversations vocales qui echouent. Doit rester sous 2%.

Chacune de ces metriques a son graphique dans le dashboard, avec une tendance sur 7j et 30j. Un systeme de seuils colores (vert/orange/rouge) me permet de voir en un coup d'oeil si tout va bien.

Comment les alertes email ont-elles sauve ma production ?

Exemple concret : un samedi soir, j'ai recu un email "Fallback LLM declenche — 12 fois en 15 minutes". Le modele principal sur OpenRouter etait en surcharge. Sans alerte, je l'aurais decouvert lundi en regardant les metriques. Grace a l'alerte, j'ai verifie que le fallback fonctionnait correctement (il fonctionnait) et j'ai pu communiquer proactivement si necessaire.

Autre exemple : un pic de rate limiting sur une IP specifique. En investiguant, j'ai decouvert un script automatise qui tentait de creer des comptes en masse. Le rate limiter avait fait son travail, mais l'alerte m'a permis de bloquer l'IP et de renforcer la protection.

L'AlertService est mon filet de securite. Il ne remplace pas le monitoring (j'utilise aussi les logs Railway pour le backend), mais il me previent des incidents les plus critiques sans que j'aie besoin de surveiller activement.

FAQ

Faut-il un dashboard admin des le lancement ?

Pas necessairement au jour 1, mais des que tu as des utilisateurs en production, oui. Je l'ai construit quelques semaines avant le lancement et ca m'a sauve plusieurs fois. Au minimum, configure les alertes email — c'est plus urgent que le dashboard visuel.

GA4 est-il compatible avec le RGPD sans consentement ?

Non. Meme avec le Consent Mode en mode "denied", GA4 envoie des pings anonymes a Google. Pour etre 100% conforme, tu dois afficher une banniere cookie et ne charger GA4 qu'apres consentement, ou utiliser le Consent Mode qui ajuste le comportement. Le Consent Mode est la solution recommandee par Google et acceptee par la plupart des DPA europeennes.

Pourquoi Recharts plutot que Chart.js ou D3 directement ?

Recharts est un wrapper React autour de D3. L'avantage : les graphiques sont des composants React declaratifs, pas du code imperatif. C'est plus naturel dans un projet Next.js. Chart.js fonctionne aussi, mais necessite plus de code d'integration avec React.

Combien coute le systeme d'alertes email avec Resend ?

Le plan gratuit de Resend inclut 3000 emails par mois. Pour des alertes (quelques dizaines par mois en fonctionnement normal), c'est largement suffisant. Le cout est donc zero pour un petit projet en production.

Le tracking Supabase ne fait-il pas double emploi avec GA4 ?

Non, ils mesurent des choses differentes. GA4 excelle sur le trafic web (sources, comportement, conversions). Supabase mesure le comportement dans l'app (taches creees, fonctionnalites utilisees, parcours multi-device). Les deux sont complementaires, pas redondants.