Interopérabilité entre administrations : concevoir pour la panne

Quand une plateforme de contrôle sanitaire interroge un référentiel d'opérateurs hébergé ailleurs, la disponibilité du dossier dépend d'un système que l'on ne maîtrise pas. Concevoir l'échange, c'est surtout concevoir son échec.

Appel synchrone ou message asynchrone

L'appel synchrone convient quand la réponse conditionne l'action immédiate de l'utilisateur : vérifier qu'un numéro d'opérateur existe avant d'accepter la saisie. Le message asynchrone convient dès que l'utilisateur n'a pas besoin d'attendre : notifier une attestation, mettre à jour un statut de facturation. Confondre les deux produit soit des interfaces qui se figent, soit des données incohérentes.

L'idempotence n'est pas optionnelle

Un message peut être livré deux fois. Sans clé d'idempotence, la deuxième livraison crée un doublon de facture ou une double attestation. Chaque opération d'écriture exposée doit accepter un identifiant fourni par l'appelant et renvoyer le même résultat si elle est rejouée.

Le rejeu doit être un geste d'exploitation

Les messages en échec doivent atterrir dans une file dédiée, consultable, avec le motif du rejet. Un exploitant doit pouvoir corriger la cause puis rejouer le lot sans intervention de développeur. Sans cela, chaque incident devient un ticket et chaque ticket un déploiement.

Contrats et versions

Un contrat d'API publié est une promesse. Les évolutions se font par ajout de champs optionnels, jamais par modification de sémantique. Quand une rupture est inévitable, une nouvelle version cohabite avec l'ancienne le temps que les partenaires migrent — un délai qui se compte en mois, pas en semaines.