Technologies d’intégration : les patrons avant les outils
API Management, bus d’entreprise, iPaaS, messaging, event streaming, ETL, BPM, RPA : huit familles techniques — et une méthode pour choisir celle que votre besoin exige vraiment.
L’outil ne sauve pas une architecture — il l’exécute
Le marché de l’intégration vend des plateformes ; les systèmes d’information ont besoin de patrons. Synchrone ou asynchrone, point à point ou publication-abonnement, requête ou événement, temps réel ou lot : ces choix d’architecture précèdent tout choix d’outil — un excellent produit appliqué au mauvais patron produit une excellente dette. Notre méthode : qualifier chaque flux (volume, latence, criticité, couplage acceptable), choisir le patron, puis seulement l’outil — en privilégiant les standards ouverts (API REST, formats ouverts, protocoles de messagerie standard) qui garantissent que vos échanges survivront à vos outils.
Les huit familles techniques de l’intégration
API Management
Exposer des capacités comme des produits : passerelle (gateway) qui centralise sécurité, quotas et supervision ; portail développeurs pour la documentation et l’abonnement ; gestion du cycle de vie et des versions. Sécurité par standards ouverts (OAuth 2.0, OpenID Connect). C’est la brique d’ouverture maîtrisée — vers les partenaires comme entre vos propres applications (plateformes pratiquées à confirmer).
ESB
Le bus de services d’entreprise : médiation entre applications, transformation des messages et des formats, routage, connecteurs vers les systèmes anciens. L’ESB n’est pas mort — il a trouvé sa juste place : la médiation avec l’existant et les échanges internes complexes, pendant que les API et les événements prennent les nouveaux usages.
iPaaS
L’intégration en service cloud : connecteurs prêts à l’emploi vers les SaaS du marché, conception visuelle des flux, exploitation managée. Pertinent quand votre paysage est riche en SaaS et vos équipes d’intégration limitées — avec les points de vigilance que nous documentons : coûts à l’usage, dépendance, données transitant par un tiers (plateformes pratiquées à confirmer).
Messaging
Le découplage par files de messages : l’émetteur n’attend pas le récepteur, les pics s’absorbent, les indisponibilités ne se propagent pas. Garanties de livraison, files d’erreurs, rejeu : les mécanismes qui rendent les échanges asynchrones fiables. Le patron le plus sous-utilisé — et souvent le plus rentable.
Event Streaming
Les flux d’événements à grande échelle (dont Apache Kafka) : chaque changement devient un événement que plusieurs consommateurs exploitent indépendamment, avec historique rejouable. Le socle des architectures événementielles, du temps réel analytique et de la synchronisation entre plateformes — à réserver aux besoins qui justifient son exploitation exigeante.
ETL
Les pipelines de données par lots : extraction, transformation, chargement, orchestration et ordonnancement, gestion des rejets et reprises. La circulation industrielle des données vers les entrepôts et entre référentiels — frontière actée : l’alimentation analytique relève du Data Engineering (service Data et IA), la synchronisation opérationnelle d’ici.
BPM
Les moteurs de processus : modélisation exécutable (notation BPMN), orchestration des tâches humaines et automatiques, gestion des états, des délais et des exceptions, tableaux de suivi. Pour les processus longs qui traversent plusieurs systèmes et plusieurs équipes — là où un simple enchaînement d’API ne suffit plus.
RPA
Les robots logiciels : automatisation par l’interface des applications qui n’offrent pas d’autre accès, orchestrateur, files de travaux, supervision des robots. Techniquement mature — à condition de traiter les robots comme du logiciel : versionnés, testés, supervisés. Et notre position constante : quand une API existe, elle prime sur le robot (plateformes pratiquées à confirmer).
Des flux gouvernés, pas une collection de connexions
Ce qui distingue un patrimoine d’intégration d’un enchevêtrement : un catalogue des flux (qui échange quoi, avec qui, sous quel contrat) ; des conventions de nommage et de format appliquées partout ; la supervision de bout en bout — chaque flux a ses indicateurs, ses alertes et son responsable ; des environnements de test représentatifs ; et la documentation générée depuis les définitions (contrats d’API, schémas d’événements) plutôt que maintenue à la main. C’est l’application à l’intégration de notre exigence transverse : ce qui n’est pas décrit n’est pas maîtrisé.
Quel patron pour quel besoin ?
Exposer des services à des partenaires ou entre applications
API Management — critères clés : sécurité, versionnage, gouvernance des consommateurs
Découpler deux applications qui se ralentissent
Messaging — critères clés : garanties de livraison, absorption des pics
Diffuser des changements vers plusieurs consommateurs, en temps réel
Event Streaming — critères clés : volume, rejeu, indépendance des consommateurs
Faire dialoguer un existant hétérogène ou ancien
ESB / médiation — critères clés : transformations, connecteurs legacy
Connecter des SaaS entre eux et au SI
iPaaS — critères clés : connecteurs disponibles, coût à l’usage, données chez un tiers
Synchroniser des données en masse, périodiquement
ETL — critères clés : volumétrie, fenêtres de traitement, reprises
Orchestrer un processus long, humains et systèmes mêlés
BPM — critères clés : états, délais, exceptions, visibilité métier
Automatiser sur une application sans interface d’accès
RPA — critères clés : stabilité des écrans, volumes, trajectoire de remplacement par API
Règle transverse : un besoin réel combine souvent plusieurs patrons — c’est l’architecture d’ensemble qui les fait coexister proprement.
Exposer sans s’exposer
Chaque flux est une surface d’attaque potentielle : authentification et autorisation par standards (OAuth 2.0, OpenID Connect, mTLS selon les cas), chiffrement des échanges, validation systématique des entrées, quotas et protection contre les abus, journalisation exploitable et cloisonnement des environnements. Les échanges inter-organisations — cœur des projets e-Gov, santé et Open Banking — ajoutent la traçabilité contractuelle : qui a consulté quoi, quand, à quel titre. En cohérence avec le service Cybersécurité, la sécurité des flux se conçoit dans l’architecture, pas en post-traitement.
Questions fréquentes
Non : il a changé de rôle. Les API et les événements portent les nouveaux échanges ; l’ESB reste pertinent pour la médiation avec l’existant et les transformations complexes. Le remplacer partout par principe coûte cher pour un gain discutable — le faire là où il freine, oui.
Pour aller plus loin
Parlons de votre projet
Un besoin de conseil, un projet à cadrer, une solution à intégrer ou des équipes à former : nos experts vous répondent et construisent avec vous la réponse adaptée à votre contexte.