Les organisations qui comptent des dizaines de systèmes font généralement face à un enchevêtrement de connexions point à point : chaque système dialogue directement avec plusieurs autres, chacun avec son propre protocole et son propre contrat. Résultat : modifier un système en casse plusieurs autres, et l'ajout d'un nouveau canal, comme une application mobile, exige des mois de travail d'intégration. Lorsqu'une équipe veut connaître la dernière transaction d'un client, elle doit interroger trois systèmes et combiner les réponses à la main. La couche d'intégration est, de fait, répartie de manière invisible dans chaque système et n'appartient à personne.
C'est important, car la vitesse de la transformation numérique d'une organisation est directement liée à la vitesse de son intégration. Si chaque nouveau produit exige de se reconnecter aux systèmes centraux, le coût d'expérimentation des idées nouvelles devient prohibitif. Chaque connexion directe constitue en outre un point de sécurité non supervisé : qui appelle, avec quelle autorisation, à quel débit ? Sans couche partagée, ces questions reçoivent une réponse distincte pour chaque connexion, ce qui signifie en pratique que personne ne détient la réponse complète.
L'architecture recommandée associe deux modèles complémentaires. La passerelle API est le point d'entrée unique des interactions synchrones : un consommateur envoie une requête et reçoit une réponse dans le même instant. La passerelle applique de manière uniforme l'authentification, l'autorisation, la limitation de débit, le versionnage et l'observabilité. L'architecture orientée événements sert les interactions asynchrones : lorsqu'un fait se produit, comme l'ouverture d'un compte ou un changement d'adresse, le système source publie un événement et tout système intéressé le consomme, sans que la source ait besoin de connaître ses consommateurs. Une file de messages durable entre les deux garantit qu'aucun événement n'est perdu.
La première considération pratique est la conception des contrats. Les API comme les événements sont des contrats et doivent être traités comme tels : avec un schéma explicite, un versionnage explicite et une règle claire distinguant les changements compatibles des changements incompatibles. Par exemple, ajouter un champ facultatif à un événement « client mis à jour » est un changement compatible, mais modifier le type d'un champ existant exige une nouvelle version publiée en parallèle de l'ancienne pendant une période de transition. Un registre central de schémas permet aux équipes de vérifier automatiquement la compatibilité avant le déploiement plutôt que de découvrir une rupture en production.
La deuxième considération est de bien choisir entre synchrone et asynchrone. La règle empirique : si le consommateur a besoin de la réponse immédiatement pour poursuivre son propre traitement, utilisez une API ; s'il lui suffit de savoir qu'un fait s'est produit, utilisez un événement. Une consultation de solde est synchrone. La notification d'une transaction au système de lutte contre le blanchiment est asynchrone. Nombre de problèmes de performance et de couplage dans les organisations proviennent d'interactions asynchrones implémentées sous forme d'appels synchrones, où un seul système lent ralentit toute la chaîne.
La troisième considération est l'observabilité de bout en bout. Lorsqu'une requête entre par la passerelle, traverse plusieurs services et produit plusieurs événements, l'équipe doit pouvoir suivre l'ensemble du parcours grâce à un identifiant de corrélation unique. Cet identifiant doit circuler aussi bien dans les en-têtes des API que dans les métadonnées des événements. Sans lui, le diagnostic d'un problème se réduit à un rapprochement manuel des horodatages dans les journaux de plusieurs systèmes, ce qui, aux heures de pointe, est pratiquement impossible.
Les écueils courants se répartissent en quelques catégories. Premièrement, faire de la passerelle API le siège de la logique métier ; la passerelle doit appliquer des politiques, non prendre des décisions métier. Deuxièmement, des événements « lourds » qui transportent l'enregistrement complet et lient les consommateurs à la structure interne de la source, ou des événements « légers » qui ne portent qu'un identifiant et obligent chacun à rappeler la source. Troisièmement, ignorer l'ordre et les doublons ; un consommateur doit pouvoir reconnaître un événement répété et traiter un événement arrivé dans le désordre. Quatrièmement, l'absence de responsable de la couche d'intégration, qui la ramène insensiblement à son état antérieur.
Chez Niadad, cette triade est mise en œuvre sous la forme de trois plateformes complémentaires. Sepehr («سپهر») est la passerelle API de l'entreprise : authentification, autorisation, limitation de débit, versionnage et observabilité pour toutes les interactions synchrones. Jarian («جریان») est la plateforme d'événements : publication, abonnement et schémas d'événements avec conservation de l'historique. Payam («پیام») est la file de messages durable qui garantit la livraison et la gestion des erreurs pour les traitements asynchrones. Dans le programme bancaire de Niadad, ces trois plateformes forment la colonne vertébrale de l'intégration et se connectent aux couches d'identité, des tiers et des données.
Une passerelle API et une architecture orientée événements sont deux réponses à deux questions différentes, et une organisation mature dispose des deux. Ce qui en fait une infrastructure unique, ce sont des contrats explicites, une identité partagée et une observabilité de bout en bout. Avec ces trois éléments, l'ajout d'un nouveau canal ou d'un nouveau système passe d'un projet de plusieurs mois à une affaire de quelques jours. C'est la véritable mesure d'une couche d'intégration : non pas l'élégance de son schéma, mais le peu d'obstacles qu'elle oppose au changement suivant.