Tableau de bord
Le tableau de bord est la page d'accueil du backoffice (/backoffice). Son objectif est de fournir une photographie instantanee de la sante de la plateforme : est-ce que les revenus progressent ? Les utilisateurs sont-ils actifs ? Le serveur tient-il la charge ? Plutot que de devoir consulter Stripe, Supabase et le serveur separement, tout est reuni ici en un coup d'oeil.
Il agrege 12 widgets affichant en temps reel les indicateurs cles de la plateforme : revenus, utilisateurs, genetique, support, emails et infrastructure.
Widgets
1. Revenue Chart
Pourquoi suivre les revenus mensuellement ? Pour detecter rapidement les tendances -- une baisse soudaine peut signaler un probleme de facturation, tandis qu'une hausse confirme l'impact d'une campagne marketing.
Graphique en barres (ApexCharts) affichant le chiffre d'affaires mensuel sur 12 mois glissants. Les donnees proviennent des factures Stripe payees via l'API /api/admin/revenue. Un survol affiche le montant exact en EUR pour chaque mois.
Les revenus sont calcules via priceToPlanAsync() qui resout les plans depuis la table stripe_plans (cache 5 min) avec fallback sur les variables d'environnement STRIPE_PRICE_BREEDER / STRIPE_PRICE_SELECTOR pour les anciens price IDs.
2. Yearly Breakup
Graphique donut (ApexCharts) affichant le montant total des revenus de l'annee en cours compare aux 3 dernieres annees. L'indicateur de croissance (pourcentage et fleche) permet d'identifier la tendance annuelle -- la plateforme est-elle en acceleration ou en stagnation ? Les donnees agregent les factures Stripe par annee.
3. Monthly Earning
Revenu du mois en cours avec le pourcentage de croissance par rapport au mois precedent. Ce widget se met a jour en quasi temps reel via le polling Stripe (5 min) et Supabase Realtime sur la table profiles. C'est l'indicateur le plus reactif pour evaluer la performance commerciale du moment.
4. Customers
Nombre total d'utilisateurs inscrits sur la plateforme, avec la croissance par rapport au mois precedent. Les donnees proviennent de la table profiles via Supabase Realtime -- la mise a jour est instantanee a chaque nouvelle inscription. Ce compteur inclut tous les comptes, quel que soit leur plan d'abonnement.
5. Plan Distribution
Ce widget repond a une question cle : quelle proportion d'utilisateurs paie, et pour quel plan ? Il aide a evaluer la conversion entre le plan gratuit et les plans payants.
Graphique en secteurs (pie chart) montrant la repartition des utilisateurs par plan d'abonnement :
| Plan | Slug DB | Prix mensuel | Prix annuel | Essai gratuit |
|---|---|---|---|---|
| Decouverte | discovery | Gratuit | Gratuit | -- |
| Eleveur | breeder | 12 EUR | 115 EUR | 30 jours |
| Selectionneur | selector | 39 EUR | 374 EUR | 30 jours |
| Groupe de selection | program | Sur devis | Sur devis | -- |
La repartition est calculee depuis profiles.subscription_plan via Realtime instantane.
6. Active Queens
Graphique en aire (area chart) sur 12 mois montrant l'evolution du nombre de reines F0 (reines reproductrices) enregistrees, ventilees par race. Ce compteur reflete la croissance du patrimoine genetique de la plateforme -- plus il y a de reines enregistrees, plus les evaluations genetiques seront fiables.
Ce compteur inclut les reines de tous les utilisateurs ainsi que les reines de reference publiques (owner_id IS NULL). Les donnees proviennent de la table queens_f0 via Realtime.
7. Support KPIs
Le support est un indicateur indirect de la qualite de la plateforme. Un pic de tickets ouverts peut signaler un bug ou une fonctionnalite confuse. Ces trois metriques aident a evaluer la reactivite de l'equipe.
Trois indicateurs du centre de support (Peppermint) :
| KPI | Description | Source |
|---|---|---|
| Tickets ouverts | Nombre de tickets en attente de reponse | Peppermint API |
| Temps de reponse moyen | Delai entre la creation du ticket et la premiere reponse admin | Peppermint API |
| Temps de resolution moyen | Delai entre la creation et la cloture du ticket | Peppermint API |
Le widget AdminSupportKPIs utilise un polling de 5 minutes (interval: 300000).
8. Brevo KPIs
Les emails sont le principal canal de communication avec les eleveurs (confirmations, notifications, campagnes). Si les taux de livraison chutent, les utilisateurs ne recoivent plus leurs codes de verification ou leurs notifications -- d'ou l'importance de surveiller ces metriques.
Statistiques d'envoi email depuis l'API Brevo (polling 5 min) :
| KPI | Description |
|---|---|
| Taux de livraison | Pourcentage d'emails livres avec succes |
| Taux d'ouverture | Pourcentage d'emails ouverts par les destinataires |
| Taux de clic | Pourcentage d'emails ayant genere au moins un clic |
Les donnees sont recuperees depuis l'endpoint /api/admin/brevo qui agrege les statistiques Brevo sur 30 jours avec un cache serveur de 5 minutes.
9. Latest Registrations
Ce widget permet de voir immediatement qui vient de s'inscrire, de verifier que les inscriptions se deroulent normalement, et d'identifier rapidement les nouveaux utilisateurs qui pourraient necessiter un accompagnement.
Tableau des 10 derniers utilisateurs inscrits avec les colonnes suivantes : nom, date d'inscription, plan choisi, pays. Un clic sur une ligne ouvre la fiche detaillee de l'utilisateur dans /backoffice/users/[id].
Les donnees proviennent de la table profiles via Supabase Realtime -- les nouvelles inscriptions apparaissent instantanement.
10. Server Health
Si le serveur est sature, c'est toute la plateforme qui ralentit ou tombe. Ce widget fournit une surveillance permanente pour anticiper les problemes avant qu'ils n'impactent les utilisateurs.
Widget avec 4 jauges SVG circulaires affichant l'utilisation serveur en temps reel :
| Jauge | Source | Seuils de couleur |
|---|---|---|
| CPU | Beszel API (PocketBase) | Vert < 70% / Ambre 70-90% / Rouge > 90% |
| RAM | Beszel API (PocketBase) | Vert < 70% / Ambre 70-90% / Rouge > 90% |
| Disque | Beszel API (PocketBase) | Vert < 70% / Ambre 70-90% / Rouge > 90% |
| Containers | Docker API | Vert = 100% healthy / Ambre < 100% / Rouge = 0 running |
Le composant AdminServerHealth.tsx utilise un polling de 30 secondes. Si Beszel ou Docker sont indisponibles, les jauges affichent "--" sans crash (degradation gracieuse -- la page reste fonctionnelle meme si un service de monitoring est en panne).
Les seuils d'alerte CPU, memoire et disque sont configurables depuis /backoffice/settings (section "Seuils d'alerte"). Les valeurs par defaut sont calibrees pour un serveur Hetzner CCX23/CX53 :
| Metrique | Avertissement | Critique |
|---|---|---|
| CPU | 80% | 95% |
| Memoire | 80% | 95% |
| Disque | 80% | 90% |
| Age max backup | 26h | -- |
| Erreurs API / 24h | 10 | -- |
11. Changelog
Savoir ce qui a ete deploye recemment est essentiel pour diagnostiquer un probleme : "Est-ce que ce bug existait avant le dernier deploiement ?"
Les 5 derniers commits deployes sur l'environnement de production. Chaque entree affiche le hash court, le message de commit et la date de deploiement. Ce widget lit le fichier data/changelog.json genere par le script generate-changelog.mjs lors du deploiement via ./scripts/deploy.sh.
12. Error Rate
Ce widget sert de signal d'alarme. Un pic soudain d'erreurs API peut indiquer un deploiement defectueux, un service externe en panne ou une attaque. La comparaison avec la periode precedente aide a distinguer un pic ponctuel d'une degradation progressive.
Nombre d'erreurs API enregistrees dans les dernieres 24 heures, avec la tendance par rapport a la periode precedente. Les erreurs proviennent de la table api_error_logs alimentee par le helper errorResponse() en mode fire-and-forget (l'enregistrement de l'erreur n'impacte pas le temps de reponse de l'API).
Colonne api_error_logs | Description |
|---|---|
route | Chemin API (ex : /api/queens/f0) |
method | Methode HTTP (GET/POST/PUT/DELETE) |
status_code | Code HTTP (defaut 500) |
error_message | Message tronque a 1000 caracteres |
error_stack | Stack trace tronquee a 4000 caracteres |
metadata | Contexte additionnel (JSONB) |
Quick Actions
Le header du dashboard affiche une barre de Quick Actions permettant d'acceder rapidement aux operations courantes. Un raccourci clavier Cmd+K (ou Ctrl+K) ouvre la Command Palette pour naviguer rapidement dans le backoffice -- pensez-y comme un moteur de recherche interne pour les pages admin.
Notifications synthetiques
Contrairement aux notifications classiques stockees en base, les notifications admin sont calculees a la volee a chaque requete. Pourquoi ? Parce qu'elles refletent l'etat actuel du systeme plutot qu'un historique d'evenements. Si un backup est en retard maintenant, vous le voyez immediatement -- et la notification disparait des que le backup est termine.
L'icone cloche dans le header affiche ces notifications synthetiques calculees a chaque requete sur /api/admin/notifications. Leur ID est prefixe synth_. Elles incluent 8 checks :
| Notification | Condition de declenchement | Lien |
|---|---|---|
| Backup en retard | Age dernier backup > seuil (backup_max_age_hours) | /backoffice/monitoring |
| Espace disque critique | Usage disque > seuil (disk_warning) | /backoffice/monitoring |
| CPU eleve | Usage CPU > seuil (cpu_warning) | /backoffice/monitoring |
| Memoire elevee | Usage memoire > seuil (memory_warning) | /backoffice/monitoring |
| Worker non sain | Container beepass-worker unhealthy | /backoffice/docker |
| Pic d'erreurs API | Erreurs 24h > seuil (error_rate_threshold) | /backoffice/error-logs |
| Validation de role en attente | Comptes avec pending_* dans les roles | /backoffice/role-validation |
| Tickets sans reponse | Tickets ouverts > 48h sans reponse admin | Peppermint |
Chaque check est enveloppe dans son propre try/catch -- si un check echoue (par exemple, Peppermint est temporairement inaccessible), les autres continuent normalement.
Strategies de rafraichissement
Chaque widget utilise le hook useAutoRefresh avec une strategie adaptee a sa source de donnees. Le choix entre Realtime (mise a jour instantanee via WebSocket) et Polling (requete periodique) depend de la nature des donnees :
| Widget | Source | Realtime | Polling | Focus |
|---|---|---|---|---|
| Revenue Chart | Stripe API | profiles | 5 min | oui |
| Yearly Breakup | Stripe API | profiles | 5 min | oui |
| Monthly Earning | Stripe API | profiles | 5 min | oui |
| Customers | profiles | profiles | -- | oui |
| Plan Distribution | profiles | profiles | -- | oui |
| Active Queens | queens_f0 | queens_f0 | -- | oui |
| Support KPIs | Peppermint API | -- | 5 min | oui |
| Brevo KPIs | Brevo API | -- | 5 min | oui |
| Latest Registrations | profiles | profiles | -- | oui |
| Server Health | Beszel + Docker API | -- | 30 s | oui |
| Changelog | Fichier local | -- | 5 min | oui |
| Error Rate | api_error_logs | -- | 5 min | oui |
Les widgets bases sur Supabase Realtime (Customers, Plan Distribution, Active Queens, Latest Registrations) se mettent a jour instantanement lorsqu'un INSERT, UPDATE ou DELETE est detecte sur la table ecoutee. C'est possible car ces donnees vivent dans la base Supabase. Le polling n'est utilise que comme filet de securite pour les sources externes (Stripe, Brevo, Beszel) dont les donnees ne transitent pas par Supabase.
Les montants affiches dans les widgets financiers proviennent des factures Stripe via l'API. Un delai de quelques minutes peut exister entre le paiement effectif et l'apparition dans le dashboard. Le webhook Stripe met a jour profiles.subscription_plan et profiles.subscription_status en temps reel, mais les montants agreges necessitent un polling vers l'API Stripe.
Prerequis Supabase Realtime
Pour que le Realtime fonctionne, les tables doivent etre ajoutees a la Replication dans le dashboard Supabase. Sans cette configuration, les evenements postgres_changes ne sont pas emis et les widgets ne se mettent pas a jour automatiquement.
- Aller dans
Database>Replication - Activer
profilesetqueens_f0
Pages complementaires du backoffice
En plus du dashboard, le backoffice comporte les pages suivantes :
| Page | Route | Description |
|---|---|---|
| Account Settings | /backoffice/account-settings | Profil admin, securite TOTP, preferences notifications (3 onglets) |
| Env Compute | /backoffice/env-compute | 5 sections : ONE SHOT + ENV + XGB + EBV + THRG |
| Reference Queens | /backoffice/reference-queens | Import CSV multi-format (SmartImportWizard) |
| Role Validation | /backoffice/role-validation | Approbation/rejet des roles proteges |
| Users | /backoffice/users | Liste, filtres, export CSV, creation |
| User Detail | /backoffice/users/[id] | Detail, edition, ban, suppression |
| Plans | /backoffice/plans | Configuration des 4 plans Stripe |
| Services | /backoffice/services | Couts infrastructure CRUD |
| Orders | /backoffice/orders | Datatable factures Stripe (TanStack) |
| Error Logs | /backoffice/error-logs | Journal erreurs HTTP (stack expandable) |
| Changelog | /backoffice/changelog | Historique commits Git deployes |
| Docker | /backoffice/docker | Containers, health, logs, restart |
| Monitoring | /backoffice/monitoring | Beszel + Server Upgrades + Backups + Cron |
| Emails | /backoffice/emails | Brevo KPIs + events + contacts bloques |
| Cloudflare | /backoffice/cloudflare | 8 onglets (Traffic, WAF, Cache, DNS, SSL, Perf...) |
| Security Center | /backoffice/security | 19 outils d'audit securite |
| Security Reports | /backoffice/security-reports | Rapports automatises + export PDF |
| WireGuard | /backoffice/wireguard | Gestion peers VPN |
| Settings | /backoffice/settings | Mode maintenance + seuils d'alerte |
| Notifications | /backoffice/notifications | Centre de notifications admin |
Voir aussi : Gestion des utilisateurs | Finances & Abonnements | Vue d'ensemble