Une requête pose une question et attend la réponse. Un événement annonce un fait et poursuit son chemin.

Presque toute décision d’intégration se ramène à cette phrase — et presque tout paysage difficile à exploiter résulte de l’avoir ignorée. Les deux modèles ne sont pas rivaux ; ils répondent à des questions différentes. La douleur commence quand on force l’un à faire le travail de l’autre.

Le modèle n’est pas une préférence technique. C’est une promesse sur la façon dont deux systèmes tomberont ensemble.

L’essentiel

Choisissez requête-réponse quand l’appelant ne peut pas continuer sans la réponse. Choisissez un événement quand le fait intéresse plus de consommateurs que vous ne pouvez en nommer aujourd’hui.

Ce que promet réellement chaque modèle

01

Un appel synchrone couple la disponibilité

Quand le système A appelle le système B et attend, A a hérité en silence de sa disponibilité, de sa latence et de ses fenêtres de maintenance. À un appel de profondeur, cela ne pose pas de problème. À trois sauts, le système le plus faible de la chaîne fixe la disponibilité de tout le parcours — et personne n’a accepté cela.

02

Un événement découple le temps

Le producteur annonce “collaborateur recruté”, “commande créée”, “écriture libérée” — et c’est terminé. Les consommateurs traitent à leur rythme, peuvent être ajoutés sans toucher au producteur et peuvent rejouer les messages après une panne. Le prix : personne n’attend, donc personne ne sait immédiatement si l’aval a réussi.

03

C’est dans l’échec que les modèles diffèrent vraiment

Un appel qui échoue échoue bruyamment, au nez de l’appelant, au moment de la question — idéal quand une personne attend la réponse. Un événement qui échoue échoue silencieusement, plus tard, dans une file — idéal quand la livraison doit survivre à une panne, et dangereux quand personne ne surveille cette file.

Décider selon les dimensions qui tranchent

DimensionRequête-réponse convientUn événement convient
Le besoinUne question qui appelle une réponse maintenantUn fait que d’autres devraient connaître
ConsommateursExactement un, connu aujourd’huiPlusieurs — ou encore inconnus
TemporalitéL’appelant est bloqué sur le résultatLe différé est acceptable, la perte non
Profil de chargeRégulier, au rythme humainPar rafales — clôture mensuelle, modifications de masse, migrations
Mode de défaillanceÉchouer vite, au nez de l’appelantTamponner, réessayer et survivre à la panne

SAP Integration Suite porte les deux modèles — les flux Cloud Integration et les API gérées d’un côté, les capacités d’event mesh de l’autre — si bien que le choix peut se faire par interface plutôt que par plateforme.

Le paysage a besoin des deux — délibérément

Les paysages réels sont mixtes : qui consulte les coordonnées bancaires d’un collaborateur a besoin d’une réponse synchrone ; le recrutement qui a créé ce collaborateur aurait dû être un événement, car la paie, le provisionnement informatique, la gestion des accès et l’analytique s’y intéressent tous, et aucun ne devrait retenir la transaction de recrutement.

Le signal d’alerte, c’est l’uniformité. Un paysage où tout est un appel d’API point à point a généralement recréé l’enchevêtrement qu’il entendait remplacer — avec de meilleurs journaux. Un paysage où tout est un événement a généralement découvert que certaines questions appelaient bel et bien une réponse.

Nommer l’interaction→Question ou fait ?→Choisir le contrat→Concevoir d’abord le chemin d’échec

Des règles qui survivent au contact de la production

  • Décidez par interaction, pas par projet. Un même processus contient généralement à la fois une question et plusieurs faits.
  • Rendez chaque consommateur idempotent. Les reprises et les rejeux sont une caractéristique d’une intégration résiliente, pas une anomalie — traiter deux fois le même message doit être sans danger.
  • Donnez un responsable à chaque file. Une file de messages non distribués sans supervision est une panne à retardement.
  • Versionnez le contrat, pas la liste des consommateurs. Tout l’intérêt d’un événement est que le consommateur de demain ne coûte rien au producteur.

Le point de vue de VISCAP

Notre avis

La dette d’intégration est une dette de disponibilité. Chaque saut synchrone ajouté aujourd’hui est une panne que vous cosignez pour plus tard.

Quand nous examinons un paysage, nous lisons la liste des interfaces à l’aune d’une seule question : qui attend qui, et quelqu’un l’a-t-il décidé exprès ? La carte des attentes accidentelles — des traitements par lots bloqués sur des appels en direct, des interfaces bloquées sur des chaînes de services — est souvent la voie la plus rapide vers la stabilité et la vitesse à la fois.

La question à poser à chaque nouvelle interface

Pas “API ou événement ?” d’abord — mais “si l’autre côté tombe pendant une heure, que doit-il se passer ici ?” Répondez honnêtement, et le modèle se choisit généralement de lui-même.