Relier des outils sans fusionner les comptes ni les données

Choisir le niveau d’intégration le plus simple

Un lien contextuel transmet seulement une destination et, si nécessaire, un identifiant public. Un export/import transfère un lot sous contrôle humain. Un calendrier échange des événements et des dates. Un webhook signale un changement. Une API permet une lecture ou une action structurée. La fédération d’identité authentifie une personne sans déplacer automatiquement ses données métier.

Commencez au niveau qui ferme le besoin. Un lien peut être plus robuste qu’une API lorsque l’utilisateur doit confirmer dans l’outil cible. Un fichier versionné convient à un transfert périodique contrôlé. Une API devient pertinente pour un volume, une fréquence ou un délai que la procédure manuelle ne peut plus soutenir.

L’intégration reste optionnelle lorsque le produit doit fonctionner seul. Son indisponibilité masque l’action transverse ou propose une reprise ; elle ne bloque pas le parcours principal.

Écrire un contrat lisible avant le connecteur

Le contrat nomme la version, les opérations, champs, types, valeurs absentes, identifiants, erreurs, limites et règles de fraîcheur. Il distingue les données publiques, privées, personnelles et secrètes. Un exemple ne remplace pas le schéma ; un schéma ne remplace pas la signification métier.

Précisez qui est autorité pour chaque objet et comment une correction se propage. Une application ne doit pas recalculer silencieusement le résultat d’un moteur propriétaire si le contrat demande de le restituer. Une valeur inconnue reste inconnue ; elle ne devient ni zéro, ni disponible, ni autorisée.

La compatibilité est bornée à une version. Une évolution additive peut ajouter un champ ignoré ; une rupture demande une nouvelle version et une période de migration documentée.

Transmettre le minimum et garder les données personnelles hors URL

Les URL apparaissent dans l’historique, les journaux, les captures et parfois les en-têtes de référence. Elles ne doivent contenir ni stock personnel, liste de courses, adresse, contenu de document, identité sensible, quantité ou secret. Utilisez un identifiant public lorsqu’il désigne un contenu public ; pour un état privé, un jeton opaque court et consommable une fois est émis par un service autorisé.

Le destinataire ne reçoit que les champs nécessaires à l’action confirmée. La CNIL recommande la minimisation des données ; elle s’applique aussi aux événements techniques et aux analytics. Les métriques agrègent réussite, refus, expiration et erreur sans recopier le contenu métier.

Un secret de signature ne se place jamais dans un navigateur ou une application publique. Lorsqu’une preuve serveur est nécessaire, le backend autorisé l’émet et la vérifie ; sans ressource réelle, le parcours échoue fermé et n’invente pas un transfert réussi.

Rendre le consentement et la confirmation compréhensibles

Avant un transfert, l’utilisateur voit la source, la destination, l’action, les données concernées et la possibilité d’annuler. Le consentement n’est ni déduit de l’installation ni inclus dans une case générale. Une action à conséquence importante reçoit une confirmation dans l’application qui en demeure responsable.

Le rattachement d’un compte commun reste facultatif et révocable produit par produit. La révocation ferme le passage fédéré sans supprimer le compte natif ni ses données. Un premier accès peut proposer de créer ou rattacher explicitement un compte cible, puis fournir une connexion directe et une récupération autonome.

Une confirmation affichée ne prouve pas à elle seule que l’action a été exécutée. Le résultat vient du service cible et possède un état vérifiable.

Complément vérifié le 14 octobre 2026. Le mot consentement ne désigne pas toutes les décisions du parcours. La CNIL le décrit comme une base légale possible pour un traitement de données, avec un choix libre, spécifique, éclairé et univoque ; il ne remplace pas toute autre base légale. Se connecter établit une identité selon le service, autoriser une liaison fixe un périmètre technique, accepter un contrat engage un autre objet. Relisez ce qui est effectivement demandé sans déduire ces trois décisions les unes des autres.

Avant de répondre, vérifiez l’application demandeuse, le compte et l’espace concernés, le destinataire, les données ou actions accessibles, la durée annoncée et le moyen de retrait. Un bouton accepté ne démontre pas à lui seul qu’une transaction encore valide a été traitée ni qu’un droit est désormais actif. Distinguez choix effectué, demande transmise, décision enregistrée, droit effectivement accordé dans le périmètre indiqué et résultat ou reçu consultable quand le service le propose. Un retour au catalogue ou une page fermée n’est pas une preuve de ces états.

Concevoir les refus, expirations et rejouements

Le système refuse une origine, un rôle, une version, une signature ou un paramètre inattendu. Un jeton expiré ou déjà consommé ne peut pas être rejoué. Deux demandes concurrentes ne produisent pas deux effets. Les messages indiquent comment reprendre sans exposer de détail de sécurité.

Le connecteur utilise identifiants stables, clés d’idempotence et checkpoints quand le contrat le permet. Les retries respectent un backoff et une limite. Les éléments invalides vont en quarantaine ; ils ne sont ni perdus ni publiés comme valides.

Le mode dégradé conserve l’autonomie : ouvrir l’application cible sans contexte, télécharger un fichier, reprendre manuellement ou réessayer plus tard. Il ne transforme pas un échec en succès fictif.

Côté lecteur, après un refus, conservez ce choix : une erreur ou un retour inattendu ne vous oblige pas à accepter pour sortir du parcours. Si le formulaire est indiqué expiré ou déjà utilisé, ne le soumettez pas à nouveau depuis l’historique et ne modifiez pas son adresse. Reprenez depuis l’application officielle et son action de liaison ou de partage, si vous souhaitez toujours l’effectuer, puis relisez la nouvelle demande ; son destinataire ou son périmètre peut avoir changé.

Après une coupure réseau, une attente sans confirmation ou un écran illisible, gardez le résultat comme incertain. Évitez les clics répétés et les formulaires ouverts en parallèle. Ouvrez le service par son accès officiel et consultez l’état de la liaison, du partage ou des autorisations s’il est disponible avant de lancer une nouvelle demande. Si cet état manque ou reste contradictoire, contactez le support officiel avec la date, l’action et une référence non secrète. Ne transmettez ni adresse complète de retour contenant des paramètres privés, ni code, ni jeton dans un message ou une capture publique.

Cas fictif : Camille souhaite autoriser l’outil B à lire un dossier précis de l’outil A, puis choisit Refuser. Le navigateur affiche ensuite une erreur réseau. Camille ne transforme pas cette erreur en accord ni en preuve que le refus a été enregistré : elle vérifie le statut par l’accès officiel et demande une confirmation ciblée si nécessaire. Dans une autre variante, elle voulait accepter mais le formulaire a expiré ; elle reprend depuis l’action officielle, vérifie à nouveau le dossier et le destinataire, puis attend un résultat explicite. Ces exemples décrivent une méthode de vérification ; ils n’accordent aucun droit réel.

Tester la frontière plutôt que seulement les deux écrans

La recette couvre le départ depuis la source, la confirmation, la réception, l’effet cible et le retour. Elle vérifie aussi annulation, expiration, refus, réseau coupé, double clic, seconde session et révocation. Les données de test sont fictives et aucune information réelle n’est laissée dans les journaux.

Contrôlez les versions et empreintes du contrat et de l’adaptateur. Pour un module navigateur public, vérifiez l’origine autorisée, l’absence de credentials implicites et le comportement sans réseau. Pour une API privée, vérifiez audience, identité workload, coffre, rotation et audit expurgé.

Une preuve locale ne qualifie pas automatiquement le domaine public. Le même artefact est déployé, puis un smoke court vérifie seulement le parcours et le rollback concernés.

Checklist d’une interopérabilité facultative

• Action et résultat utilisateur écrits avant la technique.
• Application source et cible utilisables seules.
• Autorité de chaque donnée nommée.
• Niveau d’intégration minimal retenu.
• Contrat, version, erreurs et fraîcheur documentés.
• Aucune donnée privée ni secret dans l’URL.
• Consentement et confirmation explicites.
• Refus, expiration, rejeu et concurrence testés.
• Métriques expurgées et rollback défini.

Limites et rôle de DOHM

Ce guide décrit une architecture générale, pas un protocole universel. Une intégration financière, médicale, réglementée ou à fort impact exige des contrôles propres au domaine et aux fournisseurs concernés.

DOHM présente des produits indépendants pouvant devenir interopérables avec consentement lorsque des contrats versionnés et des ressources réelles existent. L’appartenance au même portefeuille ne prouve ni partage de compte, ni connexion active, ni circulation de données.