Récupération de compte et relance de la configuration

Ce guide couvre deux situations connexes :

1. Vous avez perdu le mot de passe administrateur et devez récupérer l'accès.
2. Vous souhaitez relancer l'assistant de configuration initiale (/setup) — par exemple pour repartir de zéro avec la plateforme.

Lisez d'abord la section suivante : elle explique pourquoi /setup ne se rouvre pas simplement, afin que vous choisissiez le bon chemin de récupération.

Pourquoi /setup ne se rouvre pas automatiquement

L'assistant de configuration est conditionné par l'existence d'un compte utilisateur — et non par un indicateur « configuration terminée » que vous pourriez remettre à zéro.

Quand le navigateur charge /setup, la plateforme interroge le service d'authentification pour connaître l'état de la configuration. Cet état est calculé à partir de la base de données d'authentification : si au moins une ligne existe dans la table user, la configuration est considérée comme terminée et /setup redirige immédiatement vers /auth/sign-in. L'assistant a créé votre compte administrateur, donc un utilisateur existe, donc l'assistant est fermé.

Il y a donc deux résultats distincts :

• Conserver vos données, juste reprendre l'accès → réinitialiser le mot de passe (recommandé).
• Vraiment repartir de zéro → un opérateur doit vider la table utilisateur pour que l'assistant se rouvre. C'est destructif — voir l'avertissement ci-dessous.

Recommandé : réinitialiser le mot de passe (conserve tout)

C'est presque toujours ce que vous souhaitez. Rien n'est supprimé ; l'administrateur verrouillé obtient simplement un nouveau mot de passe.

Si la distribution d'e-mails est configurée

1. Accédez à /auth/forgot-password.
2. Saisissez l'adresse e-mail de l'administrateur.
3. Suivez le lien de réinitialisation envoyé à cette boîte de réception.

Un lien magique sans mot de passe sur /auth/magic-link fonctionne de la même façon — saisissez l'e-mail, cliquez sur le lien, puis définissez un nouveau mot de passe dans Paramètres → Compte.

Les deux chemins nécessitent une distribution d'e-mails fonctionnelle (le fournisseur SMTP / Resend / SendGrid configuré lors de la configuration). Si le collègue qui connaît le mot de passe est en congé mais peut toujours recevoir des e-mails, il peut effectuer cette opération lui-même depuis n'importe où.

Si la distribution d'e-mails a été ignorée lors de la configuration

L'étape E-mail de l'assistant est facultative, donc un déploiement peut atteindre cet état sans moyen d'envoyer un lien de réinitialisation. Dans ce cas, un opérateur disposant d'un accès au cluster doit intervenir. Par ordre de préférence :

1. Restaurer à partir d'une sauvegarde récente prise pendant que le mot de passe était encore connu — voir Sauvegarde & restauration.
2. Définir le mot de passe via le service api-platform en cours d'exécution. Les mots de passe sont stockés dans la table account sous forme de hachage salé produit par le propre hasheur de Better Auth, donc vous ne pouvez pas coller un mot de passe en texte clair avec psql — il doit être haché de la même façon. Utilisez le chemin de définition de mot de passe administrateur du service d'authentification plutôt que de modifier la colonne directement. Contactez le support Scrydon si vous avez besoin d'aide pour cette opération.
3. Relancer la configuration (destructif) — uniquement s'il n'y a pas de données à préserver. Voir la section suivante.

Dernier recours : relancer l'assistant de configuration (destructif)

Cela rouvre /setup en supprimant tous les comptes utilisateurs. À utiliser uniquement lorsque vous avez l'intention de repartir de zéro.

Un opérateur disposant d'un accès à la base de données exécute ceci contre la base de données auth. Pour le Postgres en cluster intégré :

kubectl exec -it deploy/db -n scrydon-platform -- \
  psql -U postgres -d auth

Pour une instance Postgres gérée, connectez-vous à la base de données auth avec votre client habituel. Puis :

-- 1. Supprimer tous les utilisateurs. Se propage largement (comptes, sessions, appartenances,
--    espaces de travail personnels, ...). C'est ce qui rouvre /setup — la vérification est
--    "existe-t-il un utilisateur ?".
DELETE FROM "user";

-- 2. Effacer l'indicateur de fin de configuration. Hygiène recommandée : remet l'état de
--    fin / protection contre la relecture à une base d'installation initiale. Le nouvel admin
--    est promu super-admin de toute façon — le premier utilisateur créé dans une table user
--    vide est auto-promu par le hook bootstrap d'inscription.
DELETE FROM platform_config WHERE key = 'setup_completed';

Puis accédez à /setup et complétez à nouveau l'assistant.

Remarques :

• Votre licence survit. Elle est stockée dans platform_config (license_jwt), qui est intacte, donc l'étape Licence de l'assistant apparaît comme pré-validée.
• La configuration e-mail survit dans platform_config mais est désormais attachée à l'ancienne organisation (orpheline) pour les valeurs à portée organisationnelle ; reconfirmez-la dans la nouvelle organisation via Paramètres → E-mail.
• Si vous souhaitez conserver l'organisation existante et ses données, n'utilisez pas cette procédure — récupérez le mot de passe à la place (voir ci-dessus) ou contactez le support Scrydon pour rattacher un administrateur récupéré à l'organisation existante.

Référence rapide