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.

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.

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.