Bascule v0.1 vers v0.2
Évolution en préparation
Cette page décrit une évolution non livrée. État au 2026-10-11, d'après
backend/docs/migration.md, la configuration Keycloak de référence de SenSaaS et la
décision du 2026-10-11 sur le backend mutualisé.
En bref
La bascule est conduite par SenSaaS sur sa plateforme mutualisée. Les administrateurs des revendeurs n'ont rien à migrer ni rien à maintenir : ni base, ni serveur, ni script. Les comptes existants sont repris par SenSaaS avec leurs identifiants. Le seul effet visible : tout le monde se reconnecte une fois, au moment de la bascule.
Ce que le revendeur fait : rien, sauf prévenir
| Sujet | Côté revendeur |
|---|---|
| backend, magasin de sessions, plateforme d'authentification | rien : exploités par SenSaaS |
| données de l'ancien backend | rien : elles ne sont pas reprises, il n'y a plus de base |
| comptes des utilisateurs | rien : repris par SenSaaS, mêmes identifiants |
| connecteurs des clients | rien de plus que la mise à jour en v2 : voir Migrer un connecteur v1 vers la v2 |
| utilisateurs | les prévenir qu'ils devront se reconnecter une fois |
Tout le monde se reconnecte une fois
Ce n'est pas un effet de bord, c'est le déroulé normal. À la bascule, les requêtes en cours reçoivent une demande de reconnexion, la webapp redirige vers la page de connexion de la plateforme d'authentification, et une nouvelle session est créée.
Rien à migrer
Le nouveau backend ne lit aucune base locale : les tables d'utilisateurs, de serveurs, de dossiers et de jetons de la version précédente n'ont plus de consommateur. Les sessions naissent vides dans le magasin de sessions. Le script de migration de l'ancienne base a été retiré : il n'y a plus de base à alimenter.
Les comptes : reprise par SenSaaS
Les comptes du portail actuel sont importés par SenSaaS dans la plateforme d'authentification, avec leur organisation et leur revendeur. L'exigence posée par la source : une reprise transparente pour l'utilisateur - mêmes identifiants, pas d'adresse à revalider, pas de profil à compléter. Le mot de passe actuel est vérifié à la première connexion, puis converti au format de hachage de la plateforme.
Un point que SenSaaS contrôle à la reprise : l'adresse électronique de chaque compte doit être celle de l'utilisateur dans le connecteur, puisque c'est elle qui relie l'utilisateur à ses dossiers.
L'ordre de mise en place, côté SenSaaS
L'ordre est impératif : la version 0.2 du backend ne sait parler ni à l'ancienne webapp, ni à un connecteur qui n'accepte pas les jetons de la plateforme. SenSaaS le déroule ainsi :
- Plateforme d'authentification de production, puis reprise des comptes.
- API centrale - l'annuaire qui dit à un utilisateur connecté à quels connecteurs il a accès, interrogé avec le jeton de cet utilisateur.
- Connecteurs - ils acceptent les jetons de la plateforme : livré dans le connecteur v2 le 2026-10-02.
- Webapp - connexion par redirection, cookie de session, plus de jeton dans le navigateur.
- Backend v0.2 sur la plateforme mutualisée, puis routage des appels de la webapp vers lui.
Le déroulé de la bascule
- SenSaaS déploie le magasin de sessions et vérifie l'état détaillé de chaque instance du backend : magasin et plateforme d'authentification doivent tous deux répondre.
- Le routage bascule vers le backend v0.2, à chaud.
- Les utilisateurs reçoivent une demande de reconnexion et sont redirigés vers la page de connexion ; la nouvelle session est créée.
- SenSaaS surveille les journaux, les indisponibilités passagères et l'annuaire.
Revenir en arrière
Le retour consiste à re-router les appels vers les instances précédentes, à condition que l'ancienne webapp soit redéployée en même temps : les deux contrats sont incompatibles. Aucune session de la nouvelle version n'est réutilisable par l'ancienne. C'est une manœuvre d'urgence de SenSaaS, sans action du revendeur.
C'est une porte à sens unique
Une fois les comptes gérés par la plateforme d'authentification et les rattachements par l'API centrale, revenir au modèle précédent exigerait de reprovisionner les utilisateurs.
Questions fréquentes
Le revendeur doit-il planifier une intervention ?
Non. Il n'a rien à installer ni à migrer. Il prévient ses utilisateurs de la reconnexion.
Que deviennent les mots de passe des utilisateurs ?
Ils sont repris par la plateforme d'authentification : l'utilisateur se reconnecte avec son mot de passe habituel. Il gère ensuite son compte (mot de passe, passkeys, double authentification) dans la console de compte de la plateforme.
Faut-il arrêter les connecteurs pendant la bascule ?
Non. Le connecteur v2 accepte les deux émetteurs de jetons, la plateforme et sa propre connexion directe, toujours actifs en parallèle : il n'y a rien à coordonner de son côté.