Relier des applications sans fusionner leurs comptes ni leurs données

Compte natif et identité facultative

Lorsqu’un produit exige un compte, il reste autorité de ses utilisateurs, rôles et organisations. Une identité fédérée facultative peut simplifier l’accès, mais elle ne ferme pas l’inscription ou la récupération natives. Le rattachement est explicite, révocable et ne fusionne pas deux comptes sur une simple égalité d’adresse.

Au premier accès fédéré, le produit crée ou rattache son propre compte après confirmation. Il fournit ensuite un moyen direct de connexion afin que l’utilisateur conserve l’accès si la fédération est indisponible.

Prévenir les collisions et préserver la récupération

Une même personne peut avoir créé deux comptes avec des adresses, méthodes d’accès ou rôles différents. Le système ne les fusionne pas automatiquement : il exige une session valide pour chaque compte, explique les conséquences et laisse le produit décider des règles métier. En cas de doute, les comptes restent séparés et la personne conserve deux chemins de connexion plutôt qu’une fusion irréversible.

La récupération d’accès demeure gérée par le produit qui possède le compte. Détacher l’identité fédérée ne supprime ni le compte natif ni ses données. Avant révocation, l’interface vérifie qu’un moyen direct est utilisable ; après révocation, les anciens grants sont refusés et les sessions produit suivent leur propre politique d’expiration.

Redirection d’identité

Un flux d’autorisation utilise une origine déclarée, state, nonce et PKCE selon son contrat. Le grant est court, borné au client et consommable une fois. L’application cible crée sa propre session et applique ses propres autorisations.

Aucun produit ne lit directement le cookie d’un autre. Le navigateur ne transporte pas de rôle métier dans un paramètre libre. Une demande inconnue ou expirée échoue sans élargir les droits.

Handoff d’intention

Un handoff ne déplace qu’une intention minimale : ouvrir une ressource publique, préparer une action ou proposer un choix. Un gateway privé peut émettre un jeton opaque après authentification du service appelant. Le produit cible le consomme et demande confirmation avant toute mutation.

Sans gateway qualifié, le site utilise seulement un mode autonome explicitement public et local. Il ne fabrique pas de protocole, de signature ou de secret client.

Synchronisation de données

Une synchronisation exige un contrat distinct : finalité, champs, source, destinataire, version, consentement, conflit, suppression et révocation. Les données restent minimales et l’application destinataire ne reçoit pas l’ensemble du compte ou du foyer par commodité.

Un aperçu précède l’import lorsque la donnée influence une liste ou un classement. L’idempotence et la déduplication évitent les doublons. La révocation arrête les échanges futurs sans rendre le compte natif inaccessible.

Modèles d’architecture comparés

Le catalogue de liens est le plus simple et le moins couplé. La fédération simplifie l’accès mais ajoute une dépendance d’identité. Le handoff convient à une intention ponctuelle. La synchronisation répond à un besoin récurrent de données mais exige la gouvernance la plus forte. Le compte central unique maximise le couplage et ne doit pas être supposé par défaut.

Le choix part du besoin, pas du désir de connecter tout le portefeuille.

Consentement et révocation

Le consentement décrit le produit source, le produit destinataire, la donnée ou l’action, la finalité et la durée. Il n’est pas noyé dans l’acceptation générale du compte. La personne peut refuser sans perdre le fonctionnement autonome qui ne dépend pas de cet échange.

La révocation est visible par application et prend effet sur les accès futurs. Elle ne promet pas d’effacer des données que le produit devait légitimement conserver ; ces règles appartiennent à sa politique propre.

Incidents et fail-closed

Une audience invalide, un grant rejoué, une origine non autorisée ou un contrat inconnu sont refusés. L’application conserve son parcours direct. Les journaux expurgés décrivent l’identifiant technique, le résultat et la date sans payload métier.

Un incident de fédération ne devient pas une panne générale du produit. Le catalogue peut continuer à orienter vers la connexion native et afficher la limite.

Checklist d’interopérabilité

Avant d’annoncer une connexion entre produits, vérifiez le besoin et la preuve publique.

• Fonction exacte identifiée : catalogue, identité, handoff ou synchronisation.
• Compte et récupération natifs restent disponibles lorsqu’ils sont requis.
• Consentement séparé et révocation par application.
• Données minimales, contrat versionné et aperçu si nécessaire.
• state, nonce, PKCE, audience, TTL et usage unique selon le flux.
• Aucun cookie ou rôle lu entre applications.
• Échec fermé sans casser le parcours direct.
• Limites visibles dans le guide et la fiche.