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.

Avant un premier accès fédéré, vérifiez ce que le produit propose réellement : ouvrir un compte déjà existant, demander un rattachement ou permettre une création. La présence d'une confirmation ne prouve pas que ces trois possibilités existent. Pour conserver une autonomie vis-à-vis de la fédération, un moyen direct de connexion doit être documenté et vérifié ; sa disponibilité ne peut pas être déduite du seul lien My DOHM.

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. Une conception sans fusion automatique doit exiger la preuve des comptes concernés, expliquer les conséquences et laisser le produit appliquer ses règles métier. Cela ne signifie pas qu'un outil de fusion ou de rapprochement soit proposé. 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. Le retrait d'un rattachement doit être distingué de la suppression du compte natif et de ses données. Avant de le retirer, vérifiez vous-même le chemin direct annoncé et ses conditions ; ne présumez pas que l'interface effectue ce contrôle. Le refus des nouveaux passages et le devenir des sessions déjà ouvertes doivent être confirmés séparément selon le produit. Le scénario synthétique local acquis pour My DOHM distingue révocation du rattachement et maintien de l'accès natif ; il ne qualifie pas à lui seul une reprise réelle dans chaque application.

Après un changement d’adresse de contact vérifiée

Distinguez trois opérations : modifier une coordonnée dans un compte existant, ouvrir un autre profil et rattacher un compte produit à un profil. Une vérification de la nouvelle boîte établit le contrôle de cette adresse selon la procédure suivie ; elle ne prouve pas que vous avez retrouvé le même profil My DOHM, déplacé ses rattachements ou fusionné deux comptes. Ne prenez pas l’adresse affichée comme seule preuve du compte retrouvé.

Avant une modification volontaire, identifiez le service qui gère la coordonnée et consultez sa procédure officielle. Repérez les comptes produits et leurs accès directs déjà utilisables, sans retirer les rattachements ni supprimer un profil pour préparer le changement. Le site ne démontre pas qu’une fonction de remplacement d’adresse existe dans My DOHM, ni qu’une modification dans un produit se propage aux autres.

Après confirmation par le service, vérifiez séparément le compte natif du produit, le profil My DOHM présenté et les accès effectivement visibles. Si un accès manque ou qu’un autre profil apparaît, suspendez toute nouvelle inscription, importation ou opération de rattachement destinée à compenser. Notez le service où le changement a été effectué, l’étape et le message ; utilisez son assistance officielle sans transmettre de code, de mot de passe ou d’adresse complète de retour de connexion.

Un compte produit existant doit rester distingué d’un nouveau compte. La documentation de rattachement My DOHM consultée exclut la création, la fusion ou le changement d’identité d’un compte produit par cette opération. Elle ne constitue pas une procédure de transfert après changement d’adresse. Ne supposez pas qu’une nouvelle vérification de contact réactive un accès retiré ou que le rattachement manuel est disponible dans votre application.

Exemple fictif : Camille change sa coordonnée dans un produit par sa procédure officielle, puis constate que l’accès attendu manque dans My DOHM. Elle vérifie le compte natif encore accessible et le profil présenté, puis signale la différence au service concerné. Elle ne crée pas un profil supplémentaire et ne déplace pas ses données pour retrouver une carte. Le diagnostic reste ouvert tant que le service n’a pas confirmé le compte et le rattachement attendus.

Distinguer conception, livraison et parcours vérifié

Une règle décrit le comportement attendu. Une implémentation livrée montre qu'un mécanisme a été développé et publié. Une qualification établit ce qui a réellement été vérifié, pour une version, un environnement et un scénario donnés. Un contrôle public sans connexion ne démontre pas le rattachement d'un compte réel ; un essai local avec des identités fictives ne le démontre pas non plus à distance.

Les preuves My DOHM acquises pour le choix explicite d'un accès établissent des contrôles synthétiques locaux et une livraison publique, sans qualification distante authentifiée globale. Elles ne prouvent ni création universelle de compte, ni récupération commune, ni connexion directe opérationnelle pour tous les produits. Pour choisir un accès effectivement présenté et vérifier le retour, utilisez le guide dédié.

Exemple fictif : Malik découvre un bouton vers My DOHM dans son application. Il ne conclut pas qu'un nouveau compte sera créé ou que le portail récupérera son accès. Il lit l'opération proposée, identifie son compte existant et vérifie le chemin direct documenté avant de dépendre du passage fédéré. Si ce chemin reste inconnu, il le note comme tel et demande une précision au service concerné.

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.