Typologie des flux de données en système d'information
Comment choisir entre ESB, EAI, EDI, APIM ou flux direct ?

Un flux de données relie toujours un émetteur à un récepteur, avec un mode de transport et un niveau de chiffrement propres. Cette définition, posée par l'ANSSI dans son guide de cartographie du système d'information de décembre 2018, sert de point de départ à une question récurrente en architecture d'entreprise : ce flux mérite-t-il un ESB, une plateforme EAI, un canal EDI, une API exposée, ou simplement une connexion directe ?

Qu'est-ce qu'un flux de données dans un système d'information ?

Dans la vue des applications de son guide de cartographie, l'ANSSI attache trois attributs à l'objet Flux : l'émetteur, le récepteur, et l'état du chiffrement. Cette sobriété n'est pas un manque de rigueur, elle traduit une contrainte de sécurité : avant de qualifier un flux de critique ou de sensible, il faut d'abord savoir strictement qui parle à qui, et si l'échange est protégé. Le même guide range explicitement les plateformes EAI et ESB parmi les types d'applications à cartographier, aux côtés des ERP et autres applications.

Vu depuis la couche métier, la littérature académique rattache le flux d'information au cycle économique de l'entreprise, en amont de toute traduction technique : un flux existe d'abord parce qu'un processus en a besoin, l'architecture applicative vient ensuite. Cette antériorité du métier sur la technique reste le point de départ de toute typologie sérieuse : on ne choisit pas un mode d'intégration avant d'avoir nommé le flux, sa fréquence, son volume et sa sensibilité.

Comment distinguer les flux selon leur nature technique et fonctionnelle ?

Un premier axe sépare les flux synchrones des flux asynchrones. Dans un flux synchrone, l'application appelante émet une requête et attend une réponse immédiate — un appel API pour vérifier un stock avant de valider une commande, par exemple. IBM Think, dans sa fiche consacrée à l'intégration d'applications d'entreprise mise à jour en avril 2026, rappelle que cette immédiateté a un coût : les services restent fortement couplés, et la moindre latence se répercute en cascade dès qu'un volume important d'appels s'accumule.

Un flux asynchrone inverse la logique : le message est déposé dans une file, un courtier logiciel (message broker) le route, et le récepteur le traite quand il le peut. IBM cite l'exemple d'un CRM qui alimente en continu un ERP en mises à jour clients ; l'ERP peut différer ce traitement aux heures creuses sans dégrader le service rendu aux utilisateurs. Cette tolérance au découplage temporel est précisément ce que Gregor Hohpe et Bobby Woolf ont documenté en 2003 dans Enterprise Integration Patterns : soixante-cinq patterns, du canal point à point à la publication-souscription, qui donnent encore aujourd'hui un vocabulaire commun aux architectes d'intégration.

Un second axe sépare les flux internes des flux interentreprises. Un flux interne relie deux applications du même système d'information ; il peut se permettre des formats propriétaires puisque les deux extrémités sont sous la même gouvernance. Un flux B2B franchit la frontière de l'organisation : il exige un format normé, compris par un partenaire qu'on ne maîtrise pas. C'est le terrain historique de l'EDI. Le SaaS complique légèrement cette lecture : un logiciel de paie ou un CRM hébergé chez un éditeur cloud transite, du point de vue réseau, par internet, mais il reste, du point de vue de l'usage, une application interne, puisque seuls les salariés de l'entreprise la consomment. La frontière qui compte ici n'est pas celle du réseau physique, c'est celle de la gouvernance et de l'usage.

Pourquoi le modèle point-à-point échoue-t-il à grande échelle ?

Relier deux applications directement, sans intermédiaire, reste la solution la plus rapide à mettre en œuvre — et souvent la bonne, pour un système d'information restreint. IBM Think situe la bascule autour de quelques services seulement : au-delà, chaque nouvelle connexion s'ajoute aux précédentes sans grille de lecture commune, et le nombre de liaisons croît plus vite que le nombre d'applications.

La littérature académique nomme ce phénomène le spaghetti integration. Un article publié sur arXiv en 2013 sur l'évaluation des architectures orientées services décrit comment chaque application ajoutée impose l'écriture d'un code de liaison spécifique, ce qui alourdit la maintenance à chaque itération. Les pannes deviennent difficiles à isoler puisqu'aucun composant ne supervise l'ensemble des échanges, et un audit de sécurité doit rejouer chaque connexion une à une plutôt que d'interroger un point de contrôle unique.

C'est cette accumulation de coûts cachés, pas un jugement de valeur sur le point-à-point en tant que tel, qui a fait émerger dans les années 1990 le modèle hub-and-spoke : un logiciel central absorbe la complexité que les connexions directes dispersaient partout dans le système.

Quand un ESB ou une plateforme EAI apporte-t-il une réelle valeur ?

Le hub-and-spoke déplace la complexité vers un point unique : l'Enterprise Service Bus. L'article arXiv de 2013 le définit comme une plateforme d'intégration standardisée combinant messagerie, services web, transformation de données et routage intelligent. Contrairement à une idée reçue, l'ESB ne se limite pas aux services web, il prolonge directement les patterns d'intégration d'entreprise (EAI) déjà en place.

IBM Think résume les responsabilités confiées au hub : routage, gouvernance, authentification, supervision et conversion de données. En centralisant ces fonctions, un ESB permet d'ajouter une application sans toucher aux intégrations existantes, et facilite l'audit puisque tous les échanges transitent par un plan de gestion partagé, un vrai gain pour la cartographie ANSSI qui recommande justement de documenter la plateforme EAI/ESB comme un type d'application à part entière du système d'information.

Mais ce même point de passage devient un point de défaillance unique (SPOF) : une panne du bus paralyse l'ensemble des échanges qui transitent par lui. Un article publié en 2023 sur la mise en œuvre d'architectures événementielles modernisées pointe un travers récurrent, celui de dissimuler une complexité applicative réelle derrière un ESB plutôt que de la traiter à la racine, ce qui explique en partie pourquoi une partie des tenants des microservices a fini par se détourner du terme même d'architecture événementielle. Un ESB bien gouverné absorbe la complexité ; un ESB mal gouverné se contente de la déplacer et de la maquiller.

Pourquoi séparer l'API Management de l'intégration interne ?

Une fois la question de l'intégration interne posée, une autre se pose : comment exposer un service à des consommateurs qu'on ne maîtrise pas, un partenaire, une application mobile, un développeur tiers ? C'est le terrain de l'API Management, et le critère de choix tient en une phrase que je reprends volontiers depuis des années de mission : l'ESB pour intégrer des applications internes hétérogènes, l'API Management pour exposer des services vers l'extérieur.

La distinction dépasse la technique. Un ESB gère un modèle d'exposition orienté intégration : il connaît les deux extrémités du flux et adapte les formats en conséquence. Une plateforme APIM gère un modèle de consommation : elle documente un contrat stable, souvent décrit avec l'OpenAPI Specification maintenue par la Linux Foundation, impose l'authentification et le quota d'appel, et ne présume rien du système qui consomme l'API. C'est aussi le terrain naturel des microservices : IBM Think note qu'ils s'appuient désormais sur des passerelles API ou des maillages de services plutôt que sur un ESB central, une différence d'échelle autant que de philosophie — le SOA gère des applications d'entreprise, les microservices découpent un même domaine en composants plus fins.

Reste la question que pose justement le SaaS : une application vendue nativement avec ses propres API, mais destinée aux seuls utilisateurs internes, relève-t-elle de l'ESB ou de l'APIM ? En pratique, ni tout à fait l'un ni tout à fait l'autre. IBM Think observe que les organisations, en particulier les plus grandes, combinent un EAI historique pour leurs systèmes internes on-premise et une plateforme d'intégration en mode service (iPaaS) pour leurs intégrations cloud et SaaS : l'iPaaS n'est alors qu'une variante hébergée de la même logique d'intégration interne, pas un API Management au sens strict. Le critère décisif reste celui posé plus haut : qui consomme le flux, et sous quelle gouvernance. Consommer l'API d'un CRM SaaS pour ses propres besoins internes reste une intégration, au même titre qu'un flux vers un logiciel on-premise ; exposer sa propre API à des partenaires ou à des développeurs tiers est une décision architecturale différente, même si la plomberie technique (contrat OpenAPI, jeton d'authentification) se ressemble dans les deux sens. Réserver le terme APIM à ce second cas évite de confondre consommation et exposition.

Pour les flux asynchrones exposés à l'extérieur (événements, webhooks, files Kafka ou MQTT partagées avec un partenaire) la spécification AsyncAPI, dans sa version 3.0.0, joue le même rôle que l'OpenAPI Specification côté synchrone : elle documente le contrat indépendamment du protocole de transport retenu.

L'EDI a-t-il encore sa place face aux API ?

L'échange de données informatisé précède de plusieurs décennies l'EAI et les API. IBM Think situe son origine dans les années 1960, quand administrations et grandes entreprises ont commencé à automatiser l'échange de documents commerciaux pour se passer du papier. L'UN/CEFACT, dans son guide explicatif de l'EDIFACT-ONU, définit l'EDI comme un échange de données d'ordinateur à ordinateur sous forme de messages normalisés, une définition qui, plus de soixante ans après ses débuts, n'a pas vraiment vieilli.

Ce qui distingue toujours l'EDI d'un flux API classique, c'est que la normalisation vient d'un cadre réglementaire ou sectoriel plutôt que d'un choix d'architecture. Le secteur de la santé américain doit échanger ses données via le protocole X12 imposé par la loi HIPAA, tandis qu'une bonne partie du commerce international s'appuie sur le standard EDIFACT. Un flux EDI n'est donc pas un concurrent de l'API : c'est souvent une contrainte de conformité qui s'impose avant même qu'on discute d'architecture, en particulier sur les flux interentreprises soumis à une réglementation sectorielle.

Choisir entre flux direct, EAI, EDI et APIM : une grille de lecture

Le choix ne se réduit jamais à une préférence technologique. Il dépend de quatre variables qu'un architecte doit qualifier avant de trancher : le nombre d'applications concernées, l'hétérogénéité des protocoles en jeu, la nature interne ou externe du récepteur, et le niveau de gouvernance exigé par la sensibilité du flux. La cartographie ANSSI retient d'ailleurs le besoin de sécurité — disponibilité, intégrité, confidentialité, traçabilité — comme un attribut à part entière de chaque application et de chaque flux, ce qui en fait un bon quatrième critère de décision.

Cette grille n'est pas un algorithme figé. Un même système d'information combine, dans la durée, les quatre approches sur des flux différents : un ESB historique pour les échanges entre l'ERP et l'entrepôt de données, une API Management pour l'application mobile grand public, un canal EDI pour la facturation fournisseurs, et quelques connexions directes qui n'ont jamais eu besoin d'autre chose.

Et quand le flux transporte une donnée à caractère personnel ?

Un dernier filtre s'ajoute dès qu'un flux transporte une donnée à caractère personnel, quel que soit le mode d'intégration retenu. La CNIL impose de documenter, dans le registre des activités de traitement prévu par l'article 30 du RGPD, les destinataires de chaque flux et, le cas échéant, les transferts hors Union européenne. Ce registre recoupe directement la cartographie technique : un flux tracé côté ANSSI par son émetteur, son récepteur et son chiffrement doit pouvoir répondre, côté CNIL, aux mêmes questions posées sous l'angle de la protection des données. Choisir un ESB, un EDI ou une API n'exonère jamais de cette double lecture : l'architecture organise le flux, la conformité en documente la finalité.

Le bon choix d'architecture, ou le bon niveau de complexité ?

Un flux ne mérite un ESB que le jour où le point-à-point coûte plus cher à maintenir qu'à remplacer. Avant cela, la plateforme d'intégration est un surcoût organisationnel qu'on paie pour un problème qu'on n'a pas encore. La bonne typologie ne sert pas à justifier un investissement ; elle sert à repousser, aussi longtemps que raisonnable, le moment où celui-ci devient nécessaire.