Comment construire un dashboard admin RGPD en solo

Un dev solo a autant besoin de métriques qu'une équipe de 50 personnes. Peut-être même plus. Quand tu es seul à gérer 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 utilisées, 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 système d'alertes email pour les incidents critiques, et un tracking analytics conforme au RGPD. Voici comment tout ça s'articule, et pourquoi chaque brique est indispensable quand tu opères en solo.

Points clés à retenir :
- Un dashboard admin n'est pas un luxe — c'est vital pour un dev solo en production
- GA4 avec Consent Mode permet d'être conforme au RGPD sans sacrifier les métriques
- Les alertes email (AlertService) détectent les problèmes avant les utilisateurs
- Le cookie consent à 3 toggles avec versioning est le minimum RGPD en Europe
- Le double tracking (GA4 + Supabase) couvre les métriques web ET les métriques métier

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

La réponse courte : parce que tu n'as pas d'équipe SRE, pas de product manager, pas d'analyste. Tu es tout ça à la fois. Et sans visibilité sur ce qui se passe dans ton app, tu prends des décisions à l'aveugle.

Avant le dashboard, je découvais les problèmes par les retours utilisateurs (quand ils prenaient la peine d'écrire). Un crash du pipeline vocal pouvait rester invisible pendant des heures. Un pic d'inscriptions passait inaperçu. Une fonctionnalité que personne n'utilisait continuait de me coûter du temps de maintenance.

Le dashboard admin a changé ça. Accessible à /admin/dashboard sur tamsiv.com, il me donne une vue en temps réel de tout ce qui compte :

• Utilisateurs : Inscriptions quotidiennes, utilisateurs actifs (DAU/WAU/MAU), rétention
• Fonctionnalités : Utilisation du dictaphone, création de tâches/mémos/événements, gamification
• Infrastructure : Latence WebSocket, taux d'erreur STT, fallback LLM déclenchés
• Business : Conversions Free → Pro, revenus RevenueCat, taux de désabonnement

Comment construire un dashboard admin avec Recharts et Supabase ?

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

L'architecture est simple :

1. Données : Tout vient de Supabase via des fonctions RPC. Chaque graphique a sa propre RPC qui aggrège les données côté serveur.
2. Cartes de stats : En haut du dashboard, des cartes montrent les KPI en temps réel (total utilisateurs, actifs aujourd'hui, tâches créées, etc.).
3. Graphiques temporels : Courbes d'inscriptions quotidiennes, utilisation par fonctionnalité, histogrammes de rétention.
4. Tableaux : Liste des derniers événements (inscriptions, erreurs, alertes).

Un point important : les RPC Supabase utilisent des paramètres avec le préfixe p_ (convention du projet). Par exemple, p_start_date, p_end_date, p_metric_type. Ces RPC font les calculs d'aggrégation directement en PostgreSQL — bien plus performant que de rapatrier des milliers de lignes côté client.

Le dashboard est protégé par une vérification de rôle admin au niveau du middleware Next.js. Seuls les utilisateurs avec le rôle admin dans Supabase Auth peuvent y accéder.

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

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

Voici les alertes configurées :

• Fallback LLM déclenché : Quand le modèle principal (via OpenRouter) échoue et que le fallback prend le relais. Ça indique un problème chez le provider ou un pic de charge.
• Erreurs répétées pipeline vocal : Si le STT ou le TTS échouent plus de X fois en Y minutes, je reçois un email. Ça peut indiquer une panne Deepgram ou un problème de quota OpenAI.
• Rate limiting excessif : Si un utilisateur ou une IP déclenche le rate limiter de manière répétée, ça peut être un abus ou un bot.
• Échec d'inscription : Si le flow d'inscription (email ou QR code) échoue pour plusieurs utilisateurs, il y a probablement un bug.

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

Comment implémenter GA4 avec le Consent Mode RGPD ?

Le RGPD (Règlement Général sur la Protection des Données) est non-négociable pour un site européen. Ça signifie : pas de tracking sans consentement explicite. Google Analytics 4 supporte nativement le Consent Mode, un mécanisme qui ajuste son comportement selon le consentement de l'utilisateur.

Voici comment ça fonctionne dans tamsiv.com :

1. Initialisation en mode "denied" : GA4 est chargé au démarrage du site, mais avec analytics_storage: 'denied' et ad_storage: 'denied'. Aucune donnée n'est collectée.
2. Consentement explicite : Quand l'utilisateur accepte les cookies analytics dans la bannière, le consentement est mis à jour via gtag('consent', 'update', { analytics_storage: 'granted' }).
3. Modélisation : Avec le Consent Mode, Google utilise la modélisation pour estimer les données des utilisateurs qui n'ont pas consenti. Tu obtiens des tendances fiables même si 50% des visiteurs refusent le tracking.

Le tag GA4 (G-VVLHW673V3) est initialisé une seule fois, au premier chargement de page. Le consentement est persisté dans un cookie first-party et restauré à chaque visite. Si l'utilisateur change d'avis, il peut modifier ses préférences dans la bannière cookies accessible depuis le footer.

Comment concevoir un cookie consent conforme au RGPD ?

La bannière cookie de TAMSIV a 3 toggles, chacun avec un rôle précis :

• Nécessaires (toujours actifs, non désactivables) : Session auth, préférences de langue, consentement cookie lui-même. Sans ces cookies, le site ne fonctionne pas.
• Analytics (désactivé par défaut) : GA4, métriques de navigation Supabase. Activé uniquement après consentement.
• Marketing (désactivé par défaut) : Prévu pour le futur (retargeting, pixels publicitaires). Désactivé pour l'instant car pas utilisé.

Un point souvent négligé : le versioning du consentement. Si la politique de cookies change (ajout d'un nouveau tracker, modification des finalités), la bannière doit réapparaître pour tous les utilisateurs, même ceux qui ont déjà consenti. J'ai implémenté ça avec un numéro de version stocké dans le cookie de consentement. Quand la version change, la bannière se réaffiche.

Pourquoi utiliser un double tracking GA4 + Supabase ?

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

• Parcours conversion détaillé : Le chemin exact d'un visiteur de la landing page à l'inscription, avec les interactions intermédiaires (clic CTA, ouverture FAQ, changement de langue).
• Métriques métier : Nombre de tâches créées via le web vs l'app mobile, taux de complétion des tâches, activité de gamification.
• Attribution multi-device : Un utilisateur qui découvre le site sur desktop et télécharge 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 (généré au premier chargement, stocké dans le localStorage). Chaque interaction significative est loguée dans une table Supabase. Quand le visiteur s'inscrit, l'UUID anonyme est lié à son compte auth — ce qui permet de reconstruire le parcours complet, du premier clic à l'inscription.

Ce double tracking me donne deux lectures complémentaires : GA4 pour les tendances macro (d'où viennent les visiteurs, quelles pages performent) et Supabase pour les insights micro (quel est le parcours type qui mène à une conversion).

Quelles métriques suivre en priorité pour une app mobile ?

Quand tu démarres, tu es tenté de tout mesurer. Mauvaise idée — tu te noies dans les données sans actionner quoi que ce soit. Voici les métriques que je suis en priorité dans le dashboard TAMSIV :

1. DAU (Daily Active Users) : Le pouls de l'app. Si ça baisse, quelque chose ne va pas.
2. Taux de rétention J1/J7/J30 : Combien d'utilisateurs reviennent. C'est la métrique la plus importante pour un produit de productivité.
3. Taux de complétion première tâche : Est-ce que les nouveaux utilisateurs réussissent à créer leur première tâche ? Si non, l'onboarding a un problème.
4. Conversion Free → Pro : Le nerf de la guerre. Combien d'utilisateurs gratuits passent payants, et après combien de jours d'utilisation.
5. Taux d'erreur pipeline vocal : Le pourcentage de conversations vocales qui échouent. Doit rester sous 2%.

Chacune de ces métriques a son graphique dans le dashboard, avec une tendance sur 7j et 30j. Un système de seuils colorés (vert/orange/rouge) me permet de voir en un coup d'œil si tout va bien.

Comment les alertes email ont-elles sauvé ma production ?

Exemple concret : un samedi soir, j'ai reçu un email "Fallback LLM déclenché — 12 fois en 15 minutes". Le modèle principal sur OpenRouter était en surcharge. Sans alerte, je l'aurais découvert lundi en regardant les métriques. Grâce à l'alerte, j'ai vérifié que le fallback fonctionnait correctement (il fonctionnait) et j'ai pu communiquer proactivement si nécessaire.

Autre exemple : un pic de rate limiting sur une IP spécifique. En investiguant, j'ai découvert un script automatisé qui tentait de créer 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 sécurité. Il ne remplace pas le monitoring (j'utilise aussi les logs Railway pour le backend), mais il me prévient des incidents les plus critiques sans que j'aie besoin de surveiller activement.

FAQ

Faut-il un dashboard admin dès le lancement ?

Pas nécessairement au jour 1, mais dès que tu as des utilisateurs en production, oui. Je l'ai construit quelques semaines avant le lancement et ça m'a sauvé 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. Même avec le Consent Mode en mode "denied", GA4 envoie des pings anonymes à Google. Pour être 100% conforme, tu dois afficher une bannière cookie et ne charger GA4 qu'après consentement, ou utiliser le Consent Mode qui ajuste le comportement. Le Consent Mode est la solution recommandée par Google et acceptée par la plupart des DPA européennes.

Pourquoi Recharts plutôt que Chart.js ou D3 directement ?

Recharts est un wrapper React autour de D3. L'avantage : les graphiques sont des composants React déclaratifs, pas du code impératif. C'est plus naturel dans un projet Next.js. Chart.js fonctionne aussi, mais nécessite plus de code d'intégration avec React.

Combien coûte le système 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 coût est donc zéro pour un petit projet en production.

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

Non, ils mesurent des choses différentes. GA4 excelle sur le trafic web (sources, comportement, conversions). Supabase mesure le comportement dans l'app (tâches créées, fonctionnalités utilisées, parcours multi-device). Les deux sont complémentaires, pas redondants.