Pratiquement aucune entreprise ne fonctionne plus de manière isolée. La conception des produits se fait en collaboration avec les fournisseurs, la gestion des commandes passe par des partenaires logistiques, les données relatives au service après-vente proviennent des distributeurs, et les clients s'attendent à retrouver toutes ces informations en un seul et même endroit. Cette évolution — parfois appelée « entreprise étendue », « écosystèmes de fournisseurs » ou encore « opérations en réseau » — a une conséquence très concrète : votre système d'information doit s'ouvrir.
Autrefois, les applications servaient simplement à consulter du contenu. Aujourd'hui, elles constituent le principal canal par lequel une entreprise communique avec ses clients, ses collaborateurs, ses fournisseurs et ses partenaires. L'ouverture du système n'est plus une simple option informatique ; c'est une condition indispensable à l'exercice de toute activité commerciale.
La plupart des entreprises en conviennent. Ce qui leur pose problème, c'est de déterminer comment s'ouvrir. Stabilité, comportement en temps réel, évolutivité, normalisation, sécurité, gouvernance, surveillance : chacun de ces choix est étroitement lié à la stratégie de croissance de l'entreprise. Et deux technologies sont au cœur de cette décision : le bus de services d'entreprise et la gestion des API.
ESB ou gestion des API : les deux volets d'une même stratégie d'intégration
Cette comparaison est trop souvent présentée comme une rivalité, alors qu'elle ne le mérite pas. L'ESB et la gestion des API ne sont pas des réponses concurrentes à une même question. Elles répondent à deux questions différentes qui se trouvent simplement être liées :
- Comment les services de mon système d'information communiquent-ils entre eux ? C'est le rôle de l'ESB.
- Comment puis-je contrôler ce que je divulgue à l'extérieur ? C'est là tout l'intérêt de la gestion des API.
Ces outils se recoupent suffisamment pour qu'il soit facile de les confondre : tous deux acheminent des messages, transforment les charges utiles et enregistrent le trafic. Mais ils s'articulent autour de principes fondamentaux différents, et le fait de remplacer l'un par l'autre aboutit généralement à une architecture qui ne remplit correctement aucune des deux fonctions.
Le rôle réel d'un ESB
Un bus de services d'entreprise (ESB) est le mécanisme qui sécurise et normalise les échanges de données entre les sources et les destinations au sein de votre environnement. Son cœur est le bus d'applications : un canal unique sur lequel les applications publient et s'abonnent, au lieu de se connecter directement les unes aux autres.
La valeur réside davantage dans l'architecture que dans la fonctionnalité. Sans bus, relier n systèmes implique de maintenir des liaisons point à point qui se multiplient à mesure que le parc s'étend. Avec un bus, chaque système ne se connecte qu'une seule fois. La conversion de format, les règles de routage, la gestion des erreurs et la logique de réessai sont centralisées en un seul endroit — qui est d'ailleurs le seul endroit où il faut chercher en cas de panne.
Si vous êtes encore en train d'évaluer l'architecture sous-jacente, notre comparaison entre l'ESB, le middleware et les microservices présente plus en détail les avantages et les inconvénients de chacune de ces solutions.
Ce qu'apporte la gestion des API
La gestion des API (APIM) régit la manière dont les API sont publiées, mises en avant, sécurisées et surveillées. Elle couvre l'ensemble du cycle de vie : la conception d'une interface, la gestion des versions, le contrôle des utilisateurs autorisés à l'appeler et de la fréquence d'utilisation, le suivi de la consommation, ainsi que sa mise hors service le moment venu. La plupart des plateformes intègrent un portail dédié aux développeurs afin que les utilisateurs, qu'ils soient internes ou externes, puissent découvrir les ressources disponibles et observer comment elles sont utilisées.
Alors que l'ESB vise à garantir la fiabilité des échanges, l'APIM vise à contrôler l'exposition. Il s'agit de la couche contractuelle entre un fournisseur de services et un consommateur de services — et c'est là que les politiques de gouvernance des API sont réellement appliquées, et non pas simplement documentées.
Pourquoi ces deux-là vont bien ensemble
Un « bus » dépourvu de gestion des API permet certes de transférer efficacement les données, mais n’offre aucune vision cohérente quant aux personnes extérieures à l’organisation autorisées à accéder à quelles données. À l’inverse, une gestion des API sans « bus » a tendance à exposer des points de terminaison fragiles et étroitement couplés, qui cessent de fonctionner dès qu’un système backend subit une modification.
Utilisés conjointement, l'ESB gère l'orchestration interne et protège les utilisateurs de la complexité du backend, tandis que l'APIM définit et contrôle les limites d'accès. Une même stratégie d'intégration, deux couches.
Mettez en place une base de données fiable pour permettre une automatisation pilotée par l'IA et une prise de décision sûre. Téléchargez le livre blanc pour découvrir comment faire de la gouvernance des données une capacité stratégique — et tirer pleinement parti de l'automatisation évolutive et de l'IA.
Huit questions qui déterminent votre stratégie d'intégration
Une fois les rôles clairement définis, le vrai travail commence : déterminer à quoi doit ressembler votre stratégie d’intégration. Il n’existe pas de modèle tout fait. La bonne réponse dépend de l’importance du partage des données dans votre modèle économique et de la manière dont vous envisagez l’évolution des échanges avec votre écosystème. Les exigences métier priment ; les contraintes techniques viennent ensuite.
Ces huit questions constituent un cadre de départ utile.
1. Que divulguez-vous, à qui et pourquoi ?
Commencez par l'objectif, et non par le résultat final. Un catalogue de produits destiné aux distributeurs, un service de suivi des sinistres pour les assurés et une API de tarification destinée aux partenaires impliquent chacun des exigences très différentes en matière de sécurité, de disponibilité et de gestion des versions.
2. Quelles sont les exigences de votre modèle économique en matière de flux entrants et sortants ?
Mettez en correspondance les flux avec le modèle commercial. Quels sont les services que l'entreprise doit réellement proposer ou utiliser, et en quelle quantité ? C'est là que vous découvrez qu'un service que tout le monde considérait comme secondaire génère la moitié de votre trafic de transactions.
3. Quel niveau de sécurité et de contrôle est nécessaire ?
Authentification, autorisation, limitation du débit, pistes d'audit, localisation des données. Le niveau de sécurité est déterminé par la sensibilité des données et le cadre réglementaire, et non par ce qui est pratique du point de vue des outils.
4. À quelle vitesse l'intégration doit-elle pouvoir évoluer ?
Dix partenaires la première année et quatre cents la troisième année, cela représente une architecture fondamentalement différente d’un ensemble stable d’une douzaine de partenaires. Renseignez-vous sur le débit prévu par service, et pas seulement sur le débit global.
5. Quel niveau de granularité souhaitez-vous lors de l'ouverture des services ?
Tous les consommateurs bénéficieront-ils du même accès, ou y aura-t-il dès le départ différents niveaux : des clients « premium » disposant de données plus riches ou de limites plus élevées, et tous les autres avec un ensemble réduit ? Il est difficile d'introduire a posteriori une hiérarchisation dans un modèle forfaitaire.
6. À quel point votre écosystème est-il mature ?
La scalabilité de votre stratégie dépend entièrement de la capacité de vos partenaires à suivre le rythme. Si les fournisseurs doivent harmoniser leurs méthodes de transmission des données avant que le système ne fonctionne de bout en bout, cet effort doit être intégré au plan et au calendrier.
7. Faut-il convenir au préalable des procédures avec les partenaires ?
Pour une simple mise à disposition — la publication de données de catalogue, par exemple —, ce n'est généralement pas le cas. Pour tout ce qui implique un échange en plusieurs étapes, un état partagé ou un engagement de part et d'autre, la définition du processus doit passer en premier. C'est là qu'un projet d'intégration se transforme insidieusement en projet de gestion des processus métier.
8. De quel type de partage de données s'agit-il ?
S'agit-il d'un partenariat, d'un service commercial ou d'un service gratuit ? Les API monétisées nécessitent dès le départ un système de comptage, une intégration de la facturation et des niveaux de service. Les API gratuites nécessitent quant à elles des garanties d'interopérabilité, mais le modèle de gouvernance est plus souple.
De la stratégie à la plateforme : les éléments à prendre en compte
Une fois la stratégie définie, la question est de savoir quelle technologie permettra de la mettre en œuvre. Certains critères sont plus importants que la simple énumération des fonctionnalités.
Étendue de la connectivité. Chaque système existant que vous ne pouvez pas connecter devient une solution de contournement manuelle. Le X4 BPMS est livré avec plus de 200 adaptateurs préconfigurés et un ESB intégré, ce qui élimine la plupart des travaux de développement de connecteurs sur mesure qui font grimper les budgets d'intégration.
Processus et intégration au sein d'une même plateforme. De nombreuses organisations exploitent leur bus et leur moteur de processus comme des environnements distincts, puis passent des années à les harmoniser. X4 BPMS modélise les processus en BPMN 2.0 et les exécute sur la même plateforme qui achemine les données ; ainsi, un service mis à la disposition d'un partenaire et le processus qui le sous-tend sont gérés comme un tout.
Une gouvernance portant sur l'exécution, et pas seulement sur la conception. Phoenix élargit cette vision en intégrant la gouvernance de l'intégration et de l'exécution au sein de l'entreprise, notamment la gestion du cycle de vie des API — cette couche qui vous indique quelles interfaces existent, qui les utilise et si elles fonctionnent toujours conformément aux spécifications.
Visibilité. Les défaillances d'intégration coûtent cher, principalement parce qu'elles sont détectées trop tard. Process Monitor offre aux équipes opérationnelles une vue en temps réel des échanges en cours, plutôt qu'un fichier journal à analyser a posteriori.
Notre présentation générale de l'intégration transparente et notre guide de choix d'une plateforme d'intégration de données abordent ces critères de sélection de manière plus approfondie.
Trois erreurs qui font capoter les déploiements d'ESB et d'APIM
Considérer cela comme un choix technique. Choisir une plateforme avant de s'être mis d'accord sur ce que l'entreprise souhaite mettre à disposition revient à apporter une réponse coûteuse et bien conçue à une mauvaise question.
Exposer directement les systèmes backend. Publier une API qui reflète une table de base de données lie chaque utilisateur à votre schéma interne. La migration suivante devient alors un véritable casse-tête avec tous ceux qui ont déjà utilisé cette API.
Nous reviendrons plus tard sur la gouvernance. Les conventions de gestion des versions, la politique de dépréciation, la responsabilité et les normes de sécurité sont peu coûteuses à mettre en place pour cinq API, mais très onéreuses à appliquer à quatre-vingts. C'est également là que l'architecture d'entreprise prend tout son sens.
La stratégie d'intégration doit être guidée par les objectifs de l'entreprise
D’un point de vue métier, l’ouverture du système d’information constitue une véritable transformation. D’un point de vue informatique, il s’agit d’une démarche plus modeste et plus précise : étendre à l’ensemble de l’écosystème une approche orientée services qui existe déjà en interne. Le principe sous-jacent n’a pas changé depuis vingt ans : cesser d’accumuler des connexions point à point entre les applications.
Il y a des choix techniques à faire en cours de route. La gestion des versions des API, la stratégie relative aux jetons, l'emplacement de la zone démilitarisée (DMZ) et la topologie de la passerelle sont autant de questions qui nécessitent des réponses. Mais il s'agit là de décisions en aval. Ce qui doit déterminer votre stratégie d'intégration et d'ouverture, c'est l'orientation que prend l'entreprise, et le dilemme entre l'ESB et la gestion des API se résout de lui-même une fois que cela est clair : vous avez besoin des deux, chacun remplissant la fonction pour laquelle il a été conçu.
En tant que directeur des produits, Édouard Canteest chargé de l'orientation stratégique et du développement du portefeuille de produits de SoftProject. Fort d'une excellente connaissance du marché et d'un esprit d'innovation très marqué, il promeut des solutions centrées sur le client et veille à la compétitivité à long terme de l'entreprise.
FAQ : référentiel client unique
Quelle est la différence entre un ESB et la gestion des API ?
Un ESB orchestre et sécurise les échanges de données entre les systèmes au sein de votre système d'information, en faisant office de bus d'applications centralisé plutôt que de liaisons point à point. La gestion des API régit la manière dont celles-ci sont mises à la disposition des utilisateurs : publication, gestion des versions, contrôle d'accès, surveillance et retrait. L'ESB gère les flux internes ; la gestion des API gère la mise à disposition contrôlée vers l'extérieur.
La gestion des API peut-elle remplacer un ESB ?
Non. Une passerelle API peut acheminer et sécuriser les appels, mais elle n'est pas conçue pour orchestrer des flux internes complexes, effectuer des conversions entre des formats hérités ou gérer des échanges de longue durée impliquant un état. Le remplacement d'un bus par une passerelle a généralement pour effet de transférer cette logique vers les applications elles-mêmes, ce qui constitue précisément le problème de couplage que le bus était censé résoudre.
A-t-on besoin à la fois d'un ESB et d'une solution de gestion des API ?
C'est le cas de la plupart des organisations qui exposent leurs services au-delà de leurs propres murs. Si votre intégration est entièrement interne, un bus seul peut suffire. Dès que des partenaires, des clients ou des développeurs externes utilisent vos services, vous avez besoin d'une couche de gouvernance qui définisse et fasse respecter le contrat à la frontière.
Par où commencer pour élaborer une stratégie APIM pour un ESB ?
C'est le modèle économique qui prime, pas l'architecture. Déterminez ce que vous souhaitez exposer, à qui, et quelle relation commerciale se cache derrière. Les exigences techniques — niveau de sécurité, évolutivité, granularité, gestion des versions — découlent de ces réponses, et non l'inverse.
Qu'est-ce que la gouvernance des API ?
La gouvernance des API désigne l'ensemble des règles et des processus qui garantissent la cohérence d'un parc d'API à mesure de son expansion : conventions de nommage et de gestion des versions, normes de sécurité, responsabilité, exigences en matière de documentation et politique de dépréciation. Les plateformes de gestion des API constituent le mécanisme permettant de faire respecter ces règles.
