Les doubles saisies ont un coût quotidien.

Nouvelles tentatives, ordre et contrôle de cohérence métier

Après l'expiration d'un délai d'attente, une interface ne peut pas toujours savoir si l'autre partie a déjà traité une demande. Une nouvelle tentative à l'aveugle peut alors créer des écritures en double. Pour les opérations d'écriture, nous définissons comment un identifiant unique associe les requêtes répétées et combien de temps cette information est conservée. L'identifiant seul ne suffit pas : le traitement et le stockage du résultat doivent correspondre au modèle transactionnel.

Pour les événements, nous tenons compte en outre de l'ordre et des livraisons tardives. Une annulation peut arriver avant qu'un service en aval n'ait traité la commande d'origine. Des transitions d'état autorisées et des informations de version aident à traiter ces cas sur le plan métier. Les files d'erreur nécessitent un responsable et une reprise maîtrisée. Un contrôle de cohérence régulier des données importantes détecte des écarts qu'une simple surveillance des réponses HTTP réussies ne révèle pas.

Faire évoluer les contrats sans surprendre les équipes connectées

Outre les types de données, un contrat d'API décrit la signification des données, les cas d'erreur et les limites. Nous précisons si un champ manquant, une valeur vide et une suppression explicite constituent des opérations différentes. Les montants ont besoin d'une devise et de règles d'arrondi, les dates d'un référentiel clair. Pour les grands volumes de données, la pagination, les possibilités de filtrage et un tri stable font partie du contrat. Des exemples de requêtes permettent aux consommateurs de vérifier ces règles.

Même des changements apparemment additifs peuvent poser problème si un client n'accepte que des valeurs connues. C'est pourquoi nous recensons les consommateurs et vérifions les changements par rapport à leurs attentes. Les nouvelles versions bénéficient d'une voie de transition avec documentation, possibilité de test et plan de dépréciation. Pour les webhooks, la vérification de l'origine et la gestion des livraisons multiples sont définies. Un historique d'intégration clair aide le support à suivre un dossier métier concret à travers plusieurs systèmes.

Contenir les pannes et contrôler les accès partenaires

Un système cible lent ne doit pas générer un nombre illimité de connexions en attente dans tous les services en amont. Nous planifions des délais d'expiration, des tentatives limitées et des limites de capacité adaptées au processus métier. Certaines tâches peuvent être mises en cache, d'autres doivent échouer avec un message compréhensible. La valeur de repli d'un service en panne ne doit pas laisser croire à une information à jour ou validée alors qu'elle ne l'est pas.

Les accès sont attribués séparément pour les partenaires et les applications, et conçus pour être révocables. La limitation de débit ne suffit pas à elle seule à empêcher un accès illégitime aux données ; les autorisations métier sont vérifiées en complément. Les journaux doivent permettre d'analyser les erreurs sans diffuser d'identifiants ni de données sensibles complètes. Le transfert comprend donc aussi le renouvellement des accès, l'alerte en cas d'arriéré et une procédure de retraitement ciblé des messages en erreur.