Bascule v0.1 vers v0.2¶

Évolution en préparation

Cette page décrit une évolution non livrée. État au 2026-09-11, d'après backend/docs/migration.md et les fiches d'intégration du chantier.

En bref

Il n'y a rien à migrer : aucune donnée de l'ancien modèle n'est reprise. En revanche l'ordre des étapes est impératif — la version 0.2 ne sait parler ni à l'ancienne application, ni à un connecteur qui n'accepte pas encore les jetons du serveur d'identité. Et tout le monde se reconnecte une fois, au moment de la bascule.

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 vers la base chiffrée locale a été retiré : il n'y a plus de base à alimenter.

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, l'application redirige vers la page de connexion du serveur d'identité, et une nouvelle session est créée. Prévenez les utilisateurs.

L'ordre impératif des prérequis¶

Les quatre premiers points précèdent le backend. Aucun ne peut être sauté.

Serveur d'identité — le domaine principal, un client par déploiement (avec son adresse de retour, son adresse de déconnexion centralisée et l'option de déconnexion liée à la session activée), le périmètre qui porte l'audience attendue par les connecteurs, le périmètre d'organisation, les durées de session (7 jours), la rotation des jetons de renouvellement, et pas de jeton hors ligne.
Portail — devient client d'identité, et expose l'annuaire des connecteurs de l'utilisateur connecté, interrogé avec le jeton de cet utilisateur.
Connecteurs — validation des jetons du serveur d'identité par ses clés publiques, contrôle de l'audience, route qui expose la liste des dossiers de l'utilisateur ; le mode direct reste disponible en option.
Application (SPA) — connexion par redirection, cookie de session, suppression du jeton et de l'ancien enrobage des corps de requête, en-tête de protection contre les requêtes forgées, routes v2.
Backend v0.2 — ses variables de configuration, puis le routage des appels /api/* du point d'entrée vers les nouvelles instances.

Le déroulé de la bascule¶

Déployer le magasin de sessions (contrôle d'accès et journal d'écriture activés), puis vérifier l'état détaillé de chaque instance du backend : magasin et serveur d'identité doivent tous deux répondre.
Basculer le routage du point d'entrée vers le backend v0.2 — le rechargement se fait à chaud.
Les utilisateurs reçoivent une demande de reconnexion, l'application les redirige vers le serveur d'identité, et la nouvelle session est créée.
Surveiller : les journaux par identifiant de corrélation, les indisponibilités passagères (magasin de sessions ou serveur d'identité), et les erreurs de passerelle signalant un portail injoignable.

Revenir en arrière¶

Le retour consiste à re-router les appels vers les instances précédentes, à condition que l'ancienne application 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 ; les utilisateurs se reconnectent avec leurs identifiants du portail.

C'est une porte à sens unique

La suppression de la base locale chiffrée et de la connexion par mot de passe est assumée. Une fois les comptes gérés par le serveur d'identité et les rattachements par le portail, revenir au modèle précédent exigerait de reprovisionner les utilisateurs. Le retour décrit ci-dessus est une manœuvre d'urgence immédiate, pas un mode de fonctionnement.

Questions fréquentes¶

Peut-on basculer un seul déploiement à la fois ?

Oui : chaque déploiement a son propre client d'identité, avec sa propre adresse de retour. Mais chaque déploiement bascule d'un bloc — l'ancienne et la nouvelle application ne coexistent pas sur la même plateforme.

Que deviennent les mots de passe des utilisateurs ?

Ils ne sont pas repris par le backend. Les comptes sont gérés par le serveur d'identité, qui fournit la connexion, la réinitialisation et la console de compte.

Faut-il arrêter les connecteurs pendant la bascule ?

Non. Les connecteurs acceptent les deux émetteurs de jetons dès le départ : il n'y a pas de bascule à coordonner de leur côté, seulement l'ajout du validateur. Voir Prérequis d'exploitation.