Récupération administrateur

Quand un administrateur perd à la fois son mot de passe et son second facteur, plus aucun parcours dans l’application ne permet de rentrer. La reprise en main passe alors par le serveur : l’accès au serveur est la preuve de propriété.

Cette procédure réinitialise la double authentification d’un compte et déclenche l’envoi d’un lien de réinitialisation de mot de passe.

Ce que la commande fait

Dans cet ordre :

elle désactive la double authentification TOTP du compte ;
elle purge ses codes de récupération ;
elle consigne l’événement recovery.cli dans le journal d’audit, avec un acteur système ;
elle émet un jeton de réinitialisation de mot de passe valable 30 minutes ;
elle envoie l’email de récupération à l’adresse existante, ou à la nouvelle adresse si vous en fournissez une.

Ce qu’elle ne fait pas

Elle ne change pas le mot de passe directement : c’est le lien reçu par email qui le fait.
Elle ne crée pas de compte administrateur, et ne modifie aucun rôle.
Elle ne récupère pas la passphrase de master key saisie au wizard d’installation, ni la passphrase de sauvegarde. Ces deux valeurs ne sont stockées nulle part et restent irrécupérables.

Sur une ressource Coolify

Ouvrez un terminal Coolify sur le service backend, puis lancez :

node src/jobs/cenaclo-admin-recover.ts <communaute-slug-ou-id> <email-du-compte>

Pour rediriger l’email vers une adresse dont vous avez le contrôle, ajoutez-la en troisième argument :

node src/jobs/cenaclo-admin-recover.ts <communaute-slug-ou-id> <email-du-compte> <nouvel-email>

Rien à préparer avant : la commande charge elle-même les fichiers d’environnement écrits par la stack — /listmonk-seed/.seed.env pour les identifiants du routeur email, /var/lib/cenaclo/generated/env.sh pour les secrets produits au premier démarrage. Un terminal ouvert après coup voit donc exactement la configuration du serveur en fonctionnement.

En Docker Compose

Depuis le dépôt de déploiement, sur l’hôte :

docker compose --env-file infra/compose/.env -f infra/compose/docker-compose.yml exec -T backend node src/jobs/cenaclo-admin-recover.ts <communaute-slug-ou-id> <email-du-compte>

Ajoutez un troisième argument pour rediriger l’email, et -e RECOVER_LOCALE=en juste avant le nom du service pour l’envoyer en anglais.

La commande vise le conteneur backend déjà démarré : la stack doit donc être en fonctionnement, base de données comprise.

Le wrapper infra/ops/cenaclo-admin-recover.sh fait la même chose depuis l’hôte, et accepte les mêmes arguments :

./infra/ops/cenaclo-admin-recover.sh <communaute-slug-ou-id> <email-du-compte>

Variables reconnues par le wrapper

Variable	Rôle	Défaut
`COMPOSE_FILE`	Fichier Compose ciblé	`infra/compose/docker-compose.yml`
`BACKEND_SERVICE`	Nom du service backend	`backend`
`RECOVER_LOCALE`	Langue de l’email envoyé, `fr` ou `en`	`fr`

Codes de sortie

Code	Signification
`0`	Succès : double authentification réinitialisée, email envoyé, audit consigné
`1`	Usage invalide, ou communauté ou utilisateur introuvable
`2`	Configuration d’environnement invalide ou incomplète : le message nomme les variables en cause
`3`	Erreur technique : base injoignable, routeur email indisponible, clé invalide

Un code 2 désigne toujours la configuration du déploiement, jamais la façon dont la commande a été lancée. « Configuration d’environnement invalide — le backend ne peut pas démarrer » liste les variables refusées à la validation ; si le service tourne, ce message ne devrait pas apparaître. « Configuration manquante : … est requis pour exécuter cenaclo-admin-recover » n’en nomme qu’une, exigée au moment de l’envoi — URL publique, identifiants du routeur email, pepper d’empreinte — et qui reste facultative pour démarrer le serveur : à renseigner dans les variables de la ressource, puis redéployer.

Le premier argument accepte indifféremment le slug ou l’identifiant de la communauté. L’email doit être celui du compte, tel qu’enregistré.

L’email doit pouvoir partir

Si l’email n’arrive pas alors que le SMTP est bon, relancez simplement la commande : elle est rejouable, et un nouveau jeton de 30 minutes est émis.

Traçabilité

Chaque exécution laisse une trace recovery.cli dans le journal d’audit de la communauté, consultable depuis le backoffice d’administration. Cette trace est la seule preuve, côté produit, qu’un accès a été rendu par le serveur : traitez toute occurrence inattendue comme un incident de sécurité, et vérifiez qui avait accès au serveur à ce moment-là.

Les situations vraiment sans retour

Élément perdu	Conséquence
Mot de passe ou second facteur d’un administrateur	Récupérable par cette page
Passphrase de sauvegarde	Les archives chiffrées deviennent illisibles — voir Restaurer une instance
Passphrase de master key du wizard	Les secrets chiffrés au repos ne peuvent plus être déchiffrés

Les autres pannes d’accès — domaine, certificat, service qui ne démarre pas — sont traitées dans Dépannage.