Parametres & Maintenance

Toute plateforme a besoin d'un tableau de bord central pour ses reglages fondamentaux : pouvoir mettre le site en pause pendant une mise a jour, definir les seuils qui declenchent des alertes, et gerer les comptes administrateurs en toute securite. Cette page regroupe ces fonctions essentielles pour qu'elles soient accessibles en quelques clics.

La section couvre la configuration globale du site (mode maintenance, maintenance planifiee, seuils d'alerte systeme) et les parametres du compte administrateur (profil, securite TOTP obligatoire, gestion des sessions, journal d'audit).

Mode maintenance

Il arrive qu'il faille interrompre temporairement l'acces au site --- pour appliquer une migration de base de donnees, un deploiement majeur, ou une correction urgente. Le mode maintenance redirige tous les utilisateurs non-admin vers une page de maintenance dediee (/auth/maintenance), pendant que les administrateurs disposant d'un cookie HMAC valide conservent l'acces complet au site.

Activation

Action	Description
Activation immediate	Bascule le site en maintenance instantanement via le toggle Switch
Maintenance planifiee	Definir une fenetre de maintenance avec date/heure de debut et duree configurable

Maintenance planifiee

La maintenance planifiee est particulierement utile pour les operations previsibles : vous definissez a l'avance quand le site sera inaccessible, et le systeme gere tout automatiquement. Le composant MaintenanceSettings supporte la planification via datetime picker :

Parametre	Description
Date et heure	Datetime picker (date + heure de debut)
Duree	Select parmi : 30 min, 1h, 2h, 4h, 8h, 12h, 24h
Countdown	Affichage d'un compte a rebours actif visible dans l'interface admin
Annulation	Bouton annuler avec AlertDialog de confirmation

Le middleware verifie maintenance_schedule dans site_settings et applique la maintenance automatiquement pendant la fenetre programmee. Les planifications expirees sont nettoyees automatiquement au prochain GET.

Regles de bypass

Pendant une maintenance, certaines personnes et certaines routes doivent rester accessibles. Voici les mecanismes qui permettent de contourner le blocage :

Mecanisme	Description
Cookie HMAC admin	Les administrateurs authentifies avec un cookie HMAC valide (`beepass-admin-token`, jose JWT HS256) accedent normalement au site pendant la maintenance. La verification du cookie est effectuee dans le middleware avant le check IP whitelist.
Whitelist IP	Des adresses IP specifiques peuvent etre ajoutees a une liste blanche pour contourner le mode maintenance
Routes auth	Les routes `/auth/*` restent toujours accessibles (sinon les admins ne pourraient pas se connecter --- une boucle de redirection)
Routes API	Les routes `/api/*` sont exclues par le matcher middleware

Stockage technique

La configuration de maintenance est stockee dans la table site_settings :

Cle `site_settings`	Type JSONB	Description
`maintenance_mode`	`boolean`	Mode maintenance actif ou non
`maintenance_schedule`	`{ start: string, end: string }`	Fenetre de maintenance planifiee (ISO 8601). `null` si pas de planification.

Maintenance planifiee

Preferez la maintenance planifiee pour les operations previsibles (mises a jour, migrations). La fenetre programmee active et desactive automatiquement le mode maintenance aux heures definies, evitant d'oublier la reactivation du site.

Verification post-maintenance

Apres desactivation du mode maintenance, verifiez que le site est accessible pour les utilisateurs non-admin en ouvrant une fenetre de navigation privee. Le cache CDN (Cloudflare) peut temporairement servir la page de maintenance.

Seuils d'alerte

Plutot que de decouvrir un probleme une fois qu'il est trop tard (disque plein, CPU sature, backups obsoletes), les seuils d'alerte vous permettent de definir des limites au-dela desquelles le systeme vous previent automatiquement. Pensez-y comme des jauges sur un tableau de bord de voiture : quand l'aiguille entre dans la zone rouge, un voyant s'allume.

Ces seuils alimentent les notifications synthetiques d'avertissement ou critiques. La carte "Seuils d'alerte" est situee sous les parametres de maintenance dans la page /backoffice/settings.

Ressources serveur (sliders 0-100%, step 5)

Parametre	Cle JSONB	Defaut	Description
CPU --- Avertissement	`cpu_warning`	80%	Seuil CPU pour declenchement notification synthetique
CPU --- Critique	`cpu_critical`	95%	Seuil CPU critique (reserve futur, gravite differenciee)
Memoire --- Avertissement	`memory_warning`	80%	Seuil memoire pour notification
Memoire --- Critique	`memory_critical`	95%	Seuil memoire critique
Disque --- Avertissement	`disk_warning`	80%	Seuil disque pour notification
Disque --- Critique	`disk_critical`	90%	Seuil disque critique

Services et securite (champs numeriques)

Parametre	Cle JSONB	Defaut	Plage	Description
Age maximum backup	`backup_max_age_hours`	26h	1-168h	Notification si le dernier backup depasse ce nombre d'heures. 26h couvre un backup quotidien 03:00 UTC + 2h marge.
Expiration certificat TLS	`tls_cert_warning_days`	30j	1-90j	Alerte avant expiration du certificat TLS (reserve futur)
Seuil taux d'erreur	`error_rate_threshold`	10	1-1000	Notification si le nombre d'erreurs API en 24h depasse ce seuil

Toggle

Parametre	Cle JSONB	Defaut	Description
Worker non sain	`worker_unhealthy_notify`	Active (`true`)	Notification si le container `beepass-worker` est unhealthy (Docker inspect)

Boutons d'action

Sauvegarder

Enregistre les seuils dans site_settings (cle alert_thresholds, JSONB) via PUT /api/admin/alerts/config
Le bouton est grise si aucune modification n'a ete effectuee
Les changements prennent effet immediatement (cache invalide via invalidateAlertCache())
Les prochaines ouvertures de la cloche notifications utiliseront les nouveaux seuils

Reinitialiser

Remet tous les parametres aux valeurs par defaut (ALERT_DEFAULTS) dans le formulaire
Ne sauvegarde pas automatiquement --- il faut cliquer "Sauvegarder" ensuite
Confirmation demandee (AlertDialog)

Stockage technique

Les seuils sont stockes dans la table site_settings avec la cle alert_thresholds. Le helper src/lib/alert-thresholds.ts fournit :

Export	Description
`loadAlertThresholds()`	Charge les seuils depuis `site_settings`, merge avec `ALERT_DEFAULTS`, cache memoire 5 minutes
`invalidateAlertCache()`	Invalide le cache immediatement (appele apres PUT)
`ALERT_DEFAULTS`	Objet avec toutes les valeurs par defaut exportees

// Valeurs par defaut (src/lib/alert-thresholds.ts)
export const ALERT_DEFAULTS: AlertThresholds = {
  cpu_warning: 80,
  cpu_critical: 95,
  memory_warning: 80,
  memory_critical: 95,
  disk_warning: 80,
  disk_critical: 90,
  backup_max_age_hours: 26,
  tls_cert_warning_days: 30,
  worker_unhealthy_notify: true,
  error_rate_threshold: 10,
}

Valeurs recommandees

CPU : warning 80%, critical 95%
Memoire : warning 80%, critical 90-95%
Disque : warning 80%, critical 90%
Backup max age : 26h (couvre backup quotidien 03:00 UTC + marge 2h)
TLS expiry : 30 jours
Error rate : 10 erreurs/24h (ajuster selon le volume de trafic)

Notifications avant maintenance

Lors de la planification d'une maintenance, vous pouvez configurer des rappels automatiques envoyes aux administrateurs avant le debut de la fenetre de maintenance. Les rappels sont envoyes par email (Brevo) + push notification + notification in-app.

Configuration

Cochez les delais souhaites dans le formulaire de planification :

Delai	Description
1h avant	Rappel une heure avant le debut
2h avant	Rappel deux heures avant
6h avant	Rappel six heures avant
12h avant	Rappel douze heures avant
24h avant	Rappel vingt-quatre heures avant

Par defaut, les rappels 1h et 24h sont pre-selectionnes.

Fonctionnement technique

Un cron job (/api/cron/maintenance-notify) verifie toutes les 15 minutes si un rappel doit etre envoye. Le tracking des rappels deja envoyes est stocke dans le champ notifications_sent du JSONB maintenance_schedule, ce qui rend le mecanisme idempotent (pas de doublon meme si le cron tourne plusieurs fois).

Le script cron est deploye sur l'hote Hetzner : scripts/cron-maintenance-notify.sh.

Canaux d'alerte

Les canaux d'alerte controlent comment les notifications d'alerte sont delivrees aux administrateurs. Trois canaux sont configurables :

Canal	Description	Parametre additionnel
Email	Notifications par email via Brevo	---
Push	Notifications push navigateur (Web Push API)	---
Webhook	Appel HTTP POST vers une URL externe	URL du webhook

Test d'alerte

Le bouton "Envoyer un test" declenche une notification de test via tous les canaux actives, permettant de verifier que la configuration fonctionne correctement.

Historique

Les 5 dernieres notifications sont affichees en bas de la carte, avec le type, le message, le canal utilise et l'horodatage relatif.

Agents IA

L'onglet Agents IA permet d'activer ou desactiver individuellement chaque agent d'intelligence artificielle. Les changements prennent effet immediatement.

Agent	Flag	Defaut	Effet quand desactive
Jarvis (Assistant IA admin)	`ai_assistant`	Active	Masque la bulle flottante AI dans le backoffice. API `/api/admin/ai-assistant` retourne 403.
Oracle (Chatbot IA)	`chatbot_enabled`	Active	Masque le widget chatbot (public + eleveur). API `/api/chatbot` retourne 403.
Loki (Agent SEO)	`seo_agent_enabled`	Active	Desactive l'agent SEO. API `/api/admin/seo/chat`, `/api/admin/seo/scan`, `/api/admin/seo/translate` retournent 403.
Gandalf (Auditeur Code)	`code_auditor_enabled`	Active	Desactive l'audit code post-deploy. API `/api/cron/code-audit` retourne SKIP, `/api/admin/audit/chat` retourne 403.
Morpheus (Audit Securite)	`security_audit_enabled`	Active	Desactive les scans securite automatiques. API `/api/cron/security-audit` retourne OK sans scanner.
Mapping Import IA	`import_mapper_enabled`	Active	Desactive les suggestions IA d'import. API `/api/import/map` retourne `{ llmAvailable: false }`.

Feature flags

Les feature flags permettent d'activer ou desactiver des fonctionnalites de la plateforme sans deploiement. Les changements prennent effet immediatement cote API (cache serveur invalide) et cote UI (hook useFeatureFlags rafraichi via event feature-flags-refresh).

Flags disponibles

Flag	Defaut	Effet quand desactive
Inscription publique (`public_registration`)	Active	Affiche un message "inscriptions fermees" sur la page register. API `/api/auth/register` retourne 403.
Role testeur auto (`auto_tester_role`)	Active	Le role `testeur` n'est plus automatiquement ajoute aux `eleveur` a l'inscription.
Sync calendrier (`calendar_sync`)	Active	Masque les options de sync dans le drawer CalendarSettings. API `/api/calendar/sync` retourne 403.
Notifications push (`push_notifications`)	Active	Masque le toggle push + le bandeau PWA. API `/api/push/subscribe` retourne 403.

Double enforcement

Chaque flag (agents IA + feature flags) est enforce a deux niveaux :

API (serveur) : loadFeatureFlags() dans src/lib/feature-flags.ts (cache 30 min, invalidation instantanee). Les routes retournent HTTP 403 si le flag est desactive.
UI (client) : hook useFeatureFlags() dans src/hooks/useFeatureFlags.ts (fetch unique /api/feature-flags, cache in-memory partage, refresh via custom event).

Stockage

Cle feature_flags dans site_settings (JSONB, 10 booleens). Endpoint public GET /api/feature-flags (pas d'auth requise, les flags ne sont pas sensibles).

Rate limits

Les rate limits protegent les endpoints critiques contre les abus (brute-force, spam, DoS). 10 limiters sont configurables depuis l'interface admin, les 12 autres restent hardcodes.

Limiters configurables

Groupe	Limiter	Defaut	Description
Auth	Login eleveur	10/15min	Tentatives de connexion par IP
Auth	Inscription	3/1h	Creations de compte par IP
Auth	Reset mot de passe	3/1h	Demandes de reinitialisation par IP
Public	Formulaire contact	5/1h	Soumissions formulaire contact par IP
Public	Chatbot IA	20/1min	Messages chatbot par IP
Chat	Messages chat	30/1min	Messages communautaire par utilisateur
Admin	Login admin	5/15min	Tentatives connexion admin par IP
Admin	Validation TOTP	5/15min	Codes TOTP admin par IP
Admin	Suppression utilisateur	5/1h	Suppressions par admin
API	Creation cle API	10/1h	Cles API creees par utilisateur

Fonctionnement

Les overrides sont stockes dans site_settings cle rate_limits (JSONB). Seuls les limiters modifies sont stockes (les valeurs identiques aux defauts sont nettoyees). Le helper src/lib/rate-limit.ts charge les overrides avec un cache memoire 5 min et les applique via createRateLimiter().

Un badge "Personnalise" apparait a cote des limiters modifies. Le bouton "Reinitialiser tout" remet toutes les valeurs aux defauts (sauvegarde {} en DB).

Session config

Configuration des durees de session pour les administrateurs et les eleveurs.

Parametre	Options	Defaut	Description
Duree session admin	2h, 4h, 8h, 12h, 24h	8h	Duree de validite du cookie HMAC admin
Heartbeat eleveur	1, 5, 10, 15, 30 min	5 min	Intervalle de verification de session dans AuthContext

Stockage : cle session_config dans site_settings (JSONB).

Table `site_settings`

La table site_settings est le "coffre-fort" de configuration de la plateforme. Elle stocke toutes les configurations globales sous forme de paires cle/valeur JSONB (un format flexible qui peut contenir des booleens, des objets, des tableaux...).

Cle	Type valeur	Description	Modifiable depuis
`maintenance_mode`	`boolean`	Mode maintenance actif/inactif	Parametres
`maintenance_schedule`	`{ start_at, duration_minutes, notify_before_hours, notifications_sent, ... }` ou `null`	Fenetre de maintenance planifiee + rappels	Parametres
`maintenance_allowed_ips`	`string[]`	IPs autorisees en mode maintenance	Parametres
`alert_thresholds`	`AlertThresholds` (objet)	Seuils d'alerte systeme (10 parametres)	Parametres
`alert_channels`	`{ email_enabled, push_enabled, webhook_enabled, webhook_url }`	Canaux de livraison des alertes	Parametres
`feature_flags`	`FeatureFlags` (10 booleens)	Activation/desactivation de fonctionnalites (4 systeme + 6 agents IA)	Parametres
`session_config`	`{ admin_session_hours, breeder_heartbeat_minutes }`	Configuration sessions	Parametres
`rate_limits`	`Record<string, { limit, window }>`	Overrides rate limits (10 limiters)	Parametres
`ai_agents_config`	`{ rag, assistant, audit, import, deps }`	Configuration des 5 agents IA	Configuration IA

Schema de la table

CREATE TABLE site_settings (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  key TEXT UNIQUE NOT NULL,
  value JSONB NOT NULL DEFAULT '{}',
  updated_by UUID REFERENCES auth.users(id) ON DELETE SET NULL,
  updated_at TIMESTAMPTZ DEFAULT NOW(),
  created_at TIMESTAMPTZ DEFAULT NOW()
);

Migration : 20260210100000_site_settings_maintenance.sql
RLS : service_role only (aucune policy publique --- seul le backend peut lire et ecrire)
Le champ updated_by trace l'admin ayant effectue la derniere modification

Compte administrateur

La page /backoffice/account-settings est votre espace personnel d'administration. Elle propose 3 onglets : Profil, Notifications et Securite. L'authentification utilise le cookie HMAC admin (verifyAdminFromRequest()), independant de la session Supabase eleveur --- les deux systemes coexistent sans conflit.

Profil

Champ	Description	Editable
Avatar	Photo de profil (upload FormData vers Supabase Storage)	Oui
Nom	Prenom et nom de l'administrateur (`full_name`)	Oui
Email	Adresse email du compte (utilisee pour l'authentification). Mise a jour via `auth.admin.updateUserById()` avec `email_confirm: true`.	Oui
Roles	`admin` ou `super_admin` --- affichage en lecture seule avec badges colores	Non (modification via `super_admin` uniquement)

Apres modification du profil ou de l'avatar, le cookie HMAC est re-signe automatiquement pour que le header admin reflete les changements immediatement.

Onglet Notifications

7 toggles controlant l'envoi d'emails via Brevo. Voir la section Preferences de notification pour le detail complet.

TOTP 2FA

La securite d'un compte administrateur est cruciale : un acces compromis donnerait acces a toutes les donnees utilisateurs, aux configurations systeme et aux outils de modification. C'est pourquoi l'authentification a deux facteurs par code TOTP (Time-based One-Time Password --- un code a 6 chiffres qui change toutes les 30 secondes, genere par une application comme Google Authenticator) est obligatoire pour tous les comptes administrateur. Elle ne peut pas etre desactivee --- toute tentative retourne un HTTP 403.

Flow d'authentification complet

Le login admin suit un processus en deux etapes. La premiere verification (email + mot de passe) ne donne qu'un acces temporaire de 10 minutes, le temps de saisir le code TOTP. C'est seulement apres la validation du code que le vrai cookie admin est emis.

Login email/password
    │
    ├── totp_enabled = true
    │   └── Pre-auth cookie (10min, totpSetup=false)
    │       └── /auth/admin-totp → Saisie code 6 chiffres
    │           └── Code valide → Real cookie → /backoffice
    │
    └── totp_enabled = false (premier login)
        └── Pre-auth cookie (10min, totpSetup=true)
            └── /auth/admin-totp-setup → QR + backup codes + verify
                └── Code valide → Real cookie → /backoffice

Le login admin n'emet jamais directement le vrai cookie. Un cookie intermediaire est utilise comme "sas de securite" :

Propriete	Valeur
Nom	`beepass-admin-preauth`
TTL	10 minutes (600s) --- etendu de 5min pour laisser le temps au scan QR + sauvegarde backup codes
Issuer	`beepass-admin-preauth` (distinct de `beepass-admin`, rejete par `verifyAdminToken()`)
Claim additionnel	`totpSetup: boolean` --- determine le routing vers setup ou validation

Le middleware Edge lit le claim totpSetup pour router vers la bonne page sans requete DB.

Configuration initiale

Lors du premier login, vous devez configurer TOTP. Le processus est guide etape par etape :

Scanner le QR code affiche avec une application d'authentification (Google Authenticator, Authy, 1Password, etc.)
Alternativement, saisir la cle manuelle dans l'application
Cocher la checkbox confirmant que les codes de secours ont ete sauvegardes
Valider en entrant un code TOTP a 6 chiffres pour confirmer la configuration
Le pre-auth cookie est automatiquement upgrade en vrai cookie admin

Codes de secours

Que faire si vous perdez votre telephone ou si l'application TOTP est desinstallee ? C'est a cela que servent les codes de secours. Lors de l'activation TOTP, 8 codes de secours sont generes :

Propriete	Detail
Nombre	8 codes uniques
Format	`XXXX-XXXX` (8 caracteres alphanumeriques)
Generation	`crypto.randomBytes()` (cryptographiquement securise)
Stockage	Haches SHA-256 avec salt individuel aleatoire en base de donnees (le code en clair n'est jamais stocke)
Usage unique	Chaque code ne peut etre utilise qu'une seule fois
Cas d'usage	Perte ou indisponibilite de l'application d'authentification

Conservation des codes

Les codes de secours ne sont affiches qu'une seule fois lors de la generation. Conservez-les dans un gestionnaire de mots de passe securise. En cas de perte des codes et de l'application TOTP, la recuperation necessite l'intervention d'un super_admin.

Restrictions

Regle	Description
Desactivation interdite	Toute tentative de desactivation du TOTP sur un compte admin via l'endpoint `/api/admin/auth/totp/disable` retourne HTTP 403
Rate limiting	Maximum 5 tentatives de validation TOTP par fenetre de 15 minutes (Upstash Redis). Cela empeche les attaques par force brute (essayer tous les codes possibles).
Librairie	`@otplib/preset-default` (import explicite, compatible Turbopack --- `otplib` root import casse avec dynamic re-export)

Quand le setup est fait via pre-auth cookie (flow obligatoire premier login), l'API verify effectue la sequence suivante :

Verifie le code TOTP avec authenticator.check()
Active totp_enabled = true en base de donnees
Signe un vrai admin cookie avec les claims du pre-auth (nom, email, role)
Supprime le pre-auth cookie (maxAge=0)
Retourne { success: true, cookie_upgraded: true }

API routes TOTP admin

Endpoint	Methode	Auth	Description
`/api/admin/auth/totp/setup`	POST	Admin cookie OU pre-auth (`totpSetup=true`)	Genere secret TOTP + QR data URL + 8 backup codes haches
`/api/admin/auth/totp/verify`	POST	Admin cookie OU pre-auth (`totpSetup=true`)	Confirme 1er code TOTP, active `totp_enabled`, upgrade cookie
`/api/admin/auth/totp/validate`	POST	Pre-auth cookie	Valide code au login, echange pre-auth contre real cookie
`/api/admin/auth/totp/disable`	POST	Bloque (403)	TOTP obligatoire, ne peut pas etre desactive

TOTP eleveur (optionnel)

Le TOTP est egalement disponible pour les eleveurs, mais contrairement aux admins, il est optionnel --- les eleveurs choisissent de l'activer ou non dans leurs parametres de securite.

Aspect	Admin	Eleveur
Activation	Obligatoire au premier login	Volontaire (SecurityTab)
Desactivation	Interdite (403)	Autorisee (requiert code courant)
Cookie	`beepass-admin-preauth` → `beepass-admin-token`	`beepass-totp-verified`
Middleware	Check HMAC cookie pour `/backoffice/*`	Check `user_metadata.totp_enabled` + cookie
API routes	`/api/admin/auth/totp/*`	`/api/auth/totp/*`

Changement de mot de passe

Le changement de mot de passe est effectue depuis la section Securite (AdminSecurityTab). Contrairement a de nombreux sites, le mot de passe actuel n'est pas demande car l'admin est deja authentifie via cookie HMAC --- une couche de securite forte. Les regles de validation sont appliquees cote serveur (backend regex enforcement) pour empecher le contournement :

Regle	Description
Longueur minimale	8 caracteres minimum
Chiffre	Au moins un chiffre requis
Caractere special	Au moins un caractere special requis
Mot de passe actuel	Non requis (l'admin est deja authentifie via cookie HMAC)

L'evenement est enregistre dans le journal d'audit (password_change). La route PUT /api/admin/account/password effectue la validation et la mise a jour via auth.admin.updateUserById().

Sessions actives

Cette section repond a une question de securite fondamentale : "Qui est connecte a mon compte en ce moment ?". Elle affiche toutes les sessions actives du compte administrateur. Les donnees proviennent de la table auth.sessions (GoTrue interne, le systeme d'authentification de Supabase) via des fonctions SQL SECURITY DEFINER (des fonctions qui s'executent avec des privileges eleves, necessaires pour acceder aux tables systeme d'auth).

Informations par session

Colonne	Description
Appareil	Type d'appareil et navigateur (parsage User-Agent via `parseUserAgent()`)
Adresse IP	IP source de la connexion (suffixe CIDR `/32` strip automatiquement). IPs localhost masquees
Derniere activite	Horodatage du dernier heartbeat (signal de vie envoye toutes les 5 minutes par `AuthContext` via `getUser()`)
Session courante	Bordure verte, ping dot anime, badge "Session actuelle" (identifiee par JWT `session_id` claim)

Actions

Action	Description
Revoquer une session	Deconnecte une session specifique --- utile si vous reprez une session suspecte. L'evenement `session_revoked` est enregistre dans l'audit. AlertDialog de confirmation (style amber).
Revoquer toutes les sessions	Deconnecte toutes les sessions sauf la session courante

Fonctions SQL

Fonction	Type	Description
`get_user_sessions(p_user_id)`	`SECURITY DEFINER`	Retourne les sessions actives (id, created_at, updated_at, user_agent, ip::TEXT, refreshed_at::TIMESTAMPTZ, aal::TEXT)
`revoke_user_session(p_user_id, p_session_id)`	`SECURITY DEFINER`	DELETE `auth.sessions` pour la session specifiee. Retourne `BOOLEAN`.
`revoke_all_user_sessions(p_user_id)`	`SECURITY DEFINER`	Revoque toutes les sessions de l'utilisateur (utilisee apres password reset)

Notes techniques

auth.sessions.refreshed_at est TIMESTAMP (sans timezone), pas TIMESTAMPTZ. Le cast explicite ::TIMESTAMPTZ est necessaire dans la fonction.
auth.sessions.ip est de type inet. Le cast ::TEXT inclut le suffixe CIDR (/32). L'affichage doit stripper avec .replace(/\/\d+$/, '').
p_user_id est toujours extrait de la session serveur (jamais du client) pour empecher les attaques IDOR (Insecure Direct Object Reference --- quand un utilisateur manipule un identifiant pour acceder aux donnees d'un autre).

Journal d'audit recent

La tracabilite est un pilier de la securite : savoir qui a fait quoi et quand. En bas de la section Securite, un extrait du journal d'audit affiche les 5 dernieres actions de securite liees au compte via GET /api/admin/account/audit.

Types d'evenements affiches

Event type	Description
`login_success`	Connexion reussie (email)
`login_failed`	Echec de connexion
`admin_login`	Connexion admin (success + fail)
`admin_logout`	Deconnexion admin
`logout`	Deconnexion eleveur
`password_change`	Changement de mot de passe
`password_reset_request`	Demande de reinitialisation (HMAC token + Brevo)
`session_revoked`	Revocation de session
`mfa_enabled`	Activation MFA TOTP
`mfa_disabled`	Desactivation MFA (eleveur uniquement)

Chaque entree affiche : type d'evenement (avec icone/couleur), navigateur et OS (parsage User-Agent), adresse IP, horodatage relatif.

Pour l'historique complet de tous les administrateurs et utilisateurs, consultez le journal d'audit global accessible depuis la section Utilisateurs dans le sidebar (page Audit Log).

18 types d'evenements audit (systeme complet)

La table auth_audit_log supporte 18 types d'evenements au total, couvrant l'ensemble du cycle de vie de la securite :

Event type	Source	Description
`login_success`	`AuthLogin.tsx`, `/auth/callback`	Connexion eleveur reussie (email + OAuth)
`login_failed`	`AuthLogin.tsx`	Echec connexion
`logout`	`AuthContext`	Deconnexion eleveur
`password_change`	`SecurityTab.tsx`	Changement mot de passe
`password_reset_request`	`/api/auth/password-reset`	Demande reset (HMAC + Brevo)
`account_deletion`	`/api/auth/delete-account`	Suppression compte
`device_verification`	Client	Verification appareil
`session_revoked`	`/api/auth/sessions`	Revocation session
`admin_login`	`/api/admin/auth/login`	Connexion admin
`admin_logout`	`/api/admin/auth/logout`	Deconnexion admin
`role_change`	`/api/admin/roles`	Approve/reject role
`user_banned`	`/api/admin/users/[id]/ban`	Ban/unban utilisateur
`subscription_change`	`/api/billing/webhook`	Changement abonnement Stripe
`queen_import`	`/api/admin/reference-queens/import`	Import bulk reines
`mfa_enabled`	`SecurityTab.tsx`	Activation MFA TOTP
`mfa_disabled`	`SecurityTab.tsx`	Desactivation MFA
`api_key_created`	`/api/keys`	Creation cle API
`api_key_revoked`	`/api/keys/[id]`	Revocation cle API

API routes

Configuration site

Endpoint	Methode	Auth	Description
`/api/admin/settings`	GET	HMAC admin	Lecture `site_settings` (maintenance_mode, schedule, IPs). `?key=xxx` pour une cle specifique
`/api/admin/settings`	POST	HMAC admin	Toggle maintenance mode ON/OFF
`/api/admin/settings`	PUT	HMAC admin	Update generique cle/valeur (feature_flags, session_config, alert_channels, rate_limits) + maintenance_schedule + allowed_ips
`/api/admin/alerts/config`	GET	HMAC admin	Seuils actuels + defaults. Retourne `{ thresholds, defaults }`
`/api/admin/alerts/config`	PUT	HMAC admin	Sauvegarder seuils (validation + merge + invalidation cache)
`/api/feature-flags`	GET	Public	Retourne les 10 feature flags (4 systeme + 6 agents IA, cache serveur 30 min)
`/api/cron/maintenance-notify`	POST	Bearer CRON_SECRET	Verifie les rappels maintenance et envoie les notifications dues

Compte administrateur

Endpoint	Methode	Auth	Description
`/api/admin/account/profile`	GET	HMAC admin	Profil admin + email (`auth.users`)
`/api/admin/account/profile`	PUT	HMAC admin	Update `full_name` + email optionnel. Re-signe cookie HMAC
`/api/admin/account/avatar`	POST	HMAC admin	Upload FormData (Supabase Storage). Re-signe cookie HMAC
`/api/admin/account/password`	PUT	HMAC admin	Validation >= 8 chars + chiffre + special. Audit log `password_change`
`/api/admin/account/sessions`	GET	HMAC admin	Liste sessions actives (RPC `get_user_sessions`)
`/api/admin/account/sessions`	DELETE	HMAC admin	Revoquer session (RPC `revoke_user_session`). Audit log `session_revoked`
`/api/admin/account/audit`	GET	HMAC admin	5 derniers events `auth_audit_log`
`/api/admin/account/notifications`	GET	HMAC admin	Preferences notification (JSONB `profiles.notification_prefs`)
`/api/admin/account/notifications`	PUT	HMAC admin	Sauvegarder preferences notification

TOTP

Endpoint	Methode	Auth	Description
`/api/admin/auth/totp/setup`	POST	Admin cookie OU pre-auth	Genere secret + QR + 8 backup codes
`/api/admin/auth/totp/verify`	POST	Admin cookie OU pre-auth	Confirme TOTP, upgrade cookie
`/api/admin/auth/totp/validate`	POST	Pre-auth cookie	Valide code login, echange pre-auth → real cookie
`/api/admin/auth/totp/disable`	POST	---	Bloque (403). TOTP obligatoire.

Fichiers sources

Fichier	Description
`src/app/components/admin/account-settings/AdminAccountSettingIndex.tsx`	Container 3 onglets (Profil / Notifications / Securite)
`src/app/components/admin/account-settings/AdminAccountTab.tsx`	Onglet profil (avatar, nom, email, roles)
`src/app/components/admin/account-settings/AdminNotificationTab.tsx`	Onglet notifications (7 toggles + timezone)
`src/app/components/admin/account-settings/AdminSecurityTab.tsx`	Onglet securite (password, TOTP notice, sessions, audit)
`src/app/components/admin/AlertThresholdsCard.tsx`	Carte seuils d'alerte (sliders, inputs, toggle, save/reset)
`src/app/components/admin/AlertChannelsCard.tsx`	Carte canaux d'alerte (email/push/webhook toggles + test + historique)
`src/app/components/admin/FeatureFlagsCard.tsx`	Carte feature flags (4 toggles systeme + tooltips)
`src/app/components/admin/AIAgentsCard.tsx`	Carte agents IA (6 toggles : Jarvis, Oracle, Loki, Gandalf, Morpheus, Import Mapper)
`src/app/components/admin/SessionConfigCard.tsx`	Carte session config (admin timeout + heartbeat)
`src/app/components/admin/RateLimitsCard.tsx`	Carte rate limits (10 limiters, 5 groupes, edit limit/window)
`src/app/components/admin/MaintenanceSettings.tsx`	Toggle maintenance + planification + countdown + rappels
`src/lib/alert-thresholds.ts`	Helper seuils : `ALERT_DEFAULTS`, `loadAlertThresholds()`, `invalidateAlertCache()`
`src/lib/feature-flags.ts`	Helper flags : `loadFeatureFlags()`, `invalidateFeatureFlagsCache()`, `FEATURE_FLAGS_DEFAULTS`
`src/lib/rate-limit.ts`	Rate limiters + overrides DB : `loadOverrides()`, `invalidateRateLimitCache()`, `RATE_LIMIT_DEFAULTS`
`src/hooks/useFeatureFlags.ts`	Hook client : `useFeatureFlags()`, `invalidateClientFeatureFlags()`
`src/app/api/feature-flags/route.ts`	Endpoint public feature flags
`src/app/api/cron/maintenance-notify/route.ts`	Cron rappels maintenance (Bearer CRON_SECRET)
`scripts/cron-maintenance-notify.sh`	Script cron hote Hetzner (/15 * * *)
`src/lib/admin-auth.ts`	`signAdminToken()`, `verifyAdminToken()` (jose JWT HS256)
`src/lib/verify-admin.ts`	`verifyAdminFromRequest()` : HMAC cookie + fallback SSR
`src/lib/security-helpers.ts`	`parseUserAgent()`, `cleanIp()`, `formatRelativeTime()`, `getEventStyle()`
`src/app/auth/admin-totp/page.tsx`	Page saisie code TOTP (6 chiffres + fallback backup code)
`src/app/auth/admin-totp-setup/page.tsx`	Page setup obligatoire (QR, secret, backup codes, checkbox, verify)

Variables d'environnement

Variable	Requis	Description
`SUPABASE_SERVICE_ROLE_KEY`	Oui	Utilise comme secret HMAC pour le cookie admin (jose JWT HS256). Sert aussi d'acces service_role Supabase.
`NEXT_PUBLIC_SUPABASE_URL`	Oui	URL Supabase pour les RPC sessions
`UPSTASH_REDIS_REST_URL`	Oui	URL Redis Upstash pour rate limiting TOTP
`UPSTASH_REDIS_REST_TOKEN`	Oui	Token Redis Upstash

Mode maintenance​

Activation​

Maintenance planifiee​

Regles de bypass​

Stockage technique​

Seuils d'alerte​

Ressources serveur (sliders 0-100%, step 5)​

Services et securite (champs numeriques)​

Toggle​

Boutons d'action​

Sauvegarder​

Reinitialiser​

Stockage technique​

Notifications avant maintenance​

Configuration​

Fonctionnement technique​

Canaux d'alerte​

Test d'alerte​

Historique​

Agents IA​

Feature flags​

Flags disponibles​

Double enforcement​

Stockage​

Rate limits​

Limiters configurables​

Fonctionnement​

Session config​

Table site_settings​

Schema de la table​

Compte administrateur​

Profil​

Onglet Notifications​

TOTP 2FA​

Flow d'authentification complet​

Pre-auth cookie​

Configuration initiale​

Codes de secours​

Restrictions​

Cookie upgrade (setup obligatoire)​

API routes TOTP admin​

TOTP eleveur (optionnel)​

Changement de mot de passe​

Sessions actives​

Informations par session​

Actions​

Fonctions SQL​

Journal d'audit recent​

Types d'evenements affiches​

18 types d'evenements audit (systeme complet)​

API routes​

Configuration site​

Compte administrateur​

TOTP​

Fichiers sources​

Variables d'environnement​

Mode maintenance

Activation

Maintenance planifiee

Regles de bypass

Stockage technique

Seuils d'alerte

Ressources serveur (sliders 0-100%, step 5)

Services et securite (champs numeriques)

Toggle

Boutons d'action

Sauvegarder

Reinitialiser

Stockage technique

Notifications avant maintenance

Configuration

Fonctionnement technique

Canaux d'alerte

Test d'alerte

Historique

Agents IA

Feature flags

Flags disponibles

Double enforcement

Stockage

Rate limits

Limiters configurables

Fonctionnement

Session config

Table `site_settings`

Schema de la table

Compte administrateur

Profil

Onglet Notifications

TOTP 2FA

Flow d'authentification complet

Pre-auth cookie

Configuration initiale

Codes de secours

Restrictions

Cookie upgrade (setup obligatoire)

API routes TOTP admin

TOTP eleveur (optionnel)

Changement de mot de passe

Sessions actives

Informations par session

Actions

Fonctions SQL

Journal d'audit recent

Types d'evenements affiches

18 types d'evenements audit (systeme complet)

API routes

Configuration site

Compte administrateur

TOTP

Fichiers sources

Variables d'environnement