En ligne ou asynchrone ? Comment choisir la manière d'intégrer vos systèmes

Imaginez un jeudi de clôture de mois. Votre service des opérations charge un fichier de 50 000 avenants pour ajuster le tarif du portefeuille. Le portail les reçoit et les envoie, aussi vite qu'il le peut, au système central. Au bout de quelques minutes, le système central commence à ralentir. Puis il cesse de répondre. Les agents qui émettaient de nouvelles polices au même moment voient des écrans figés, et personne ne sait lesquels des 50 000 avenants ont été appliqués et lesquels non.

Personne ne s'est trompé dans le code : on a choisi, sans le dire, une seule manière d'intégrer (l'appel en ligne) pour un travail qui en demandait une autre. Cet article s'adresse à celui ou celle qui répond de l'exploitation ou de la technologie dans une entreprise réglementée ou de distribution : il pose trois questions, dans l'ordre.

Intégrer, ce n'est pas « connecter des systèmes ». C'est décider comment l'entreprise se comporte quand l'un d'eux tarde, tombe en panne ou reçoit dix fois plus de travail qu'à l'ordinaire.

Première question : avez-vous besoin de la réponse à cet instant, ou peut-elle attendre ?

Posez-la par processus, non par entreprise.

• En ligne (synchrone) : celui qui demande reste à attendre la réponse pour pouvoir poursuivre. Un devis à l'écran : la personne ne peut pas avancer sans le prix. C'est un appel téléphonique.
• Asynchrone : celui qui demande dépose le travail, reçoit un accusé de réception et poursuit ses tâches ; l'autre système termine à son rythme et prévient. L'émission d'une police ou le timbrage d'une facture (certification fiscale) : l'important est que cela se fasse bien et que l'on sache à quel stade cela en est, non que cela se produise à la même seconde. C'est une démarche au guichet.

Quatre critères :

1. Une personne regarde-t-elle l'écran, en attendant ? Si oui, et que la réponse est brève, penchez pour le en ligne.
2. Le travail dure-t-il plus longtemps que la patience de cette personne ? Longues secondes, minutes ou heures : asynchrone.
3. L'autre système supporte-t-il le volume au pire moment ? S'il se sature lors d'un pic, un appel en ligne entraîne avec lui le canal qui en dépend. Asynchrone.
4. Dépend-il d'un tiers qui peut tarder ou échouer ? (une banque, l'autorité fiscale, un fournisseur). Asynchrone, et avec un numéro de suivi.

Règle pratique : ce qui décide d'un écran va en ligne ; ce qui déplace de l'argent, des documents ou des stocks va généralement en asynchrone.

Si c'est en ligne : REST ou gRPC ?

La décision est technique ; le critère, lui, relève de la direction :

• REST quand pèse davantage la compatibilité avec ceux qui appellent (un partenaire, une application, un fournisseur) ou la possibilité pour quiconque de tester et déboguer facilement. C'est la langue commune d'internet : presque tous les outils la comprennent. Il peut aussi avoir des contrats versionnés.
• gRPC quand un contrat strict, des clients générés à partir de lui, une transmission continue ou une performance mesurée justifient que ceux qui appellent l'acceptent ; c'est pourquoi on le trouve généralement entre systèmes propres, où les deux extrémités le parlent.

Habitude fréquente, non une règle : REST vers l'extérieur, gRPC entre systèmes propres. Le détail se trouve dans l'article « REST ou gRPC : quand choisir l'un ou l'autre, et pourquoi votre système central ne parle ni l'un ni l'autre » (/blog/rest-ou-grpc-quand-choisir-chacun).

Si c'est asynchrone : quelle variante ?

Pour cette décision, il convient de distinguer six options fréquentes, qui peuvent se combiner ; la littérature de messagerie d'entreprise (Hohpe et Woolf) et la documentation des grands fournisseurs de cloud [1][2] en décrivent bien d'autres. Aucune n'est « la bonne » : chacune résout un problème différent.

Avis de retour : « nous vous prévenons avec votre numéro de suivi »

Utilisez-la lorsque le travail dure des secondes ou des minutes et que celui qui a demandé peut recevoir des avis. Le système récepteur répond aussitôt « reçu, votre numéro de suivi est le 4821 » et se met au travail. Quand il termine, il prévient en retour avec le numéro de suivi. Sur le plan technique, le résultat revient par un callback (rappel) ; s'il est remis par HTTP à une adresse enregistrée, on l'appelle généralement webhook.

Le numéro de suivi est ce qui associe chaque réponse à sa demande (identifiant de corrélation [3]). Sans numéro de suivi, un avis est un papier sans propriétaire.

Consultation par état : « revenez avec votre numéro de suivi et demandez »

Utilisez-la lorsque celui qui a demandé ne peut pas recevoir d'avis (pare-feu, application mobile, tiers soumis à des restrictions). Vous revenez avec votre numéro de suivi et vous demandez « est-ce prêt ? » à intervalles réguliers.

La documentation de Microsoft le décrit ainsi : la réponse initiale est un « accepté » (code HTTP 202) qui indique où consulter, et la consultation renvoie des états tels qu'en attente, en cours, réussi ou en échec [4]. Cela fonctionne là où l'avis n'arrive pas, et elle propose d'exiger une clé par demande pour ne pas la traiter deux fois [4].

File d'attente : la file des tâches

Utilisez-la lorsque le système qui reçoit a une limite de rythme et que celui qui envoie peut produire bien davantage. Celui qui envoie dépose son travail et se retire ; celui qui traite le prend à son propre rythme. C'est avant tout un amortisseur : la documentation de Microsoft l'appelle Queue-Based Load Leveling et le décrit comme un tampon entre celui qui demande et le service, qui lisse les charges intermittentes susceptibles de faire échouer le service [5]. Pour plus de vitesse, on ajoute des opérateurs sur la même file (Competing Consumers), si les tâches sont indépendantes [6].

Scénario (chiffres illustratifs, sans client). Un portail reçoit 50 000 avenants ; le système central en supporte 20 par minute. Sans amortisseur, le portail pousse tout d'un coup et le système central se sature. À 20 par minute, le temps théorique est d'environ 42 heures (50 000 ÷ 20 = 2 500 minutes) ; le temps réel dépend des validations, des reprises et des fenêtres d'exploitation. La file régule l'entrée ; le numéro de suivi par lot, le tableau d'avancement et les alertes se conçoivent à part, et en contrepartie il n'y a pas de système central à terre aux heures de pointe.

La file ne rend pas le système central plus rapide : elle fait que sa limite cesse d'être une surprise. Elle ne convient pas si l'on a besoin d'une réponse immédiate ni si le volume est faible et stable [5].

Événement ou sujet : l'annonce au haut-parleur

Utilisez-la lorsque un même fait doit mettre plusieurs choses en mouvement à la fois : documents, avis au client, CRM, fraude. Les précédentes vont de un à un ; l'événement, de un à plusieurs. Au lieu de dire à un système « faites ceci », celui qui vit le fait l'annonce : « police émise », « paiement appliqué ». Tous les abonnés en reçoivent une copie, et celui qui l'émet ne sait pas combien ils sont. Dans la littérature de messagerie, c'est la différence entre un canal point à point (un récepteur) et un canal de publication-abonnement (tous les intéressés) [7].

Son coût : tout est cohérent à terme (eventually consistent) ; pendant un moment, certains systèmes connaissent la nouvelle et d'autres non. Il ne convient pas si l'on a besoin d'une seule transaction atomique entre l'émetteur et les récepteurs [8].

Flux d'événements à haut volume : la bande que l'on peut rembobiner

Utilisez-le lorsque les événements sont très nombreux, continus, et qu'il importe de les conserver pour les relire. Apache Kafka le définit comme la capture d'événements en temps réel, leur stockage durable pour les consulter ensuite, et leur traitement tant sur le moment que rétrospectivement [9]. L'image : une bande de faits que plusieurs équipes lisent à leur rythme, tant que dure la période de rétention configurée [9].

Il a du sens pour la télémétrie, les stocks ou la fraude ; pas pour une commande ponctuelle, car c'est une machinerie que quelqu'un doit exploiter. Selon la documentation de chaque fournisseur, les garanties de livraison, d'ordre, de doublons et de relecture varient selon le produit et la configuration [10][11].

Échange par tables ou fichiers : quand l'autre système ne peut plus rien recevoir

Utilisez-le lorsque le système destinataire est un ancien système central qui ne sait parler aucune des langues précédentes. Un tel système a généralement quatre limites :

• Il n'expose pas d'interfaces permettant à d'autres de lui demander des choses, et il ne prévient pas non plus quand quelque chose change à l'intérieur.
• Il n'accepte des données que dans une zone d'échange : des tables ou des fichiers convenus, où l'on dépose l'information.
• Il les traite à son rythme, souvent par lots, en déclenchant un processus propre qui les prend, les exécute et écrit le résultat.
• Il supporte peu de charge, et la réponse arrive quand ce processus se termine, non quand on la demande.

La zone d'échange est un guichet au format fixe : on y dépose chaque instruction avec son numéro de suivi, et le système central y dépose le résultat, au même endroit. Son mérite : on n'écrit pas dans les tables internes du système central. Son coût : quelqu'un doit surveiller la zone, et la réponse met le temps que met le lot.

Sur cette zone vient une couche anticorruption : un traducteur des contrats modernes vers les champs et les rythmes que le système central comprend [12]. On modernise ainsi par étapes (Strangler Fig) pendant que le système central continue de fonctionner [13].

Reçu ne veut pas dire traité

Si vous ne retenez qu'une idée de cet article, que ce soit celle-ci : un accusé de réception n'est pas une confirmation de résultat. On croit souvent que, parce que l'accusé est arrivé, ce qui a été envoyé est réglé.

Il y a trois niveaux de réponse, et il convient de savoir à lequel se trouve chacun de vos processus :

Seul le troisième niveau dit si la facture existe, si le paiement est arrivé ou si la commande sera honorée. Banxico (la Banque du Mexique) l'illustre : liquidé signifie que le SPEI (système de paiements électroniques interbancaires du Mexique) a liquidé et prévenu l'institution réceptrice, et le CEP (Constancia Electrónica de Pago, preuve électronique de paiement) atteste le crédit sur le compte bénéficiaire [16].

L'industrie sépare déjà recevoir et traiter. HTTP définit le code 202 comme « accepté pour traitement, mais le traitement n'est pas terminé » ; la demande pourrait ne jamais être exécutée et le protocole n'a aucun moyen de renvoyer ensuite l'état [17]. Dans AS2, le standard d'échange de documents entre entreprises, l'exemple officiel de reçu signé porte ce commentaire : « Cela n'est pas une assurance que le message ait été entièrement traité ou compris par le traducteur récepteur » [18].

Ce que nous avons vu. Dans une intégration de commandes entre deux systèmes d'entreprise que nous avons examinée, sur une huitaine d'appels, deux renvoyaient l'identifiant du document créé ; les six autres, seulement un accusé. Les erreurs arrivaient par courriel du service récepteur, environ trois jours plus tard. Dans le même lot, il y avait plus de dix cas identiques que personne n'avait vus : on ne découvre que ceux que quelqu'un examine par hasard, et le reste est indiscernable de ceux qui se sont bien passés. C'est la mesure d'un seul cas, non un chiffre du secteur. Ce qui a fonctionné de moins coûteux : vérifier que la référence retournée correspond au bon enregistrement. Sur 234 enregistrements, aucune fausse alerte.

Ce qu'il faut demander, selon la variante :

• Dans toutes : un numéro de suivi par opération qui voyage à l'aller et au retour, pour associer chaque résultat à sa demande [3].
• Avis de retour : qu'il prévienne du résultat ; un « j'ai terminé » sans dire si c'est appliqué est un autre accusé.
• Consultation par état : un état clair par numéro de suivi (en attente, en cours, réussi ou en échec) et, en cas d'échec, le motif [4].
• File d'attente : que les messages en échec soient mis de côté pour examen, avec leur origine notée [15].
• Tables ou fichiers : une ligne de résultat pour chaque enregistrement envoyé.

Et deux défenses de plus. Un état explicite pour ce qui n'est pas revenu (« sans confirmation depuis 10 h 40 ») : le pire n'est pas l'erreur, c'est de ne pas savoir. Et un rapprochement périodique qui compare ce qui a été envoyé à ce qui a été confirmé, avec une alarme pour ce qui n'est pas revenu à temps ; le silence devient ainsi une tâche avec un responsable.

Problème du secteur, première question, variante

Guide de conversation, non recette : le normal est de combiner les variantes.

Les risques, en langage métier

Une variante asynchrone n'élimine pas les problèmes : elle les déplace. Cinq pour la table.

• « Il a été débité deux fois ». La plupart des files livrent chaque message au moins une fois : il peut arriver en double. Microsoft demande que le traiter plusieurs fois donne le même résultat, afin d'éviter des « enregistrements en double ou des débits répétés » [5] : chaque instruction porte une clé unique et le système enregistre lesquelles il a déjà traitées.
• L'ordre. Quand plusieurs opérateurs prennent dans la même file, rien n'assure que les tâches se terminent dans l' ordre où elles sont entrées [5][6]. Si « annuler la police » arrive avant « émettre la police », il y a un problème. Définissez la clé d'ordre de votre métier (police, paiement, sinistre) et respectez-la là où cela compte.
• Des reprises sans frein. Une erreur passagère mérite une nouvelle tentative ; un rejet fonctionnel (« compte inexistant ») ne se règle pas en le répétant. Ce qui est recommandé est de le mettre de côté dans une file d'exceptions et de la surveiller [5][6].
• Ne pas savoir à quel stade en est quelque chose. C'est le risque de la section précédente ; pour les événements, il convient en outre d'avoir un identifiant qui parcoure chaque opération de bout en bout [8].
• Chacun voit une version différente, pendant un moment [8]. Décidez d'avance qui est propriétaire de la donnée finale et comment on rapproche une opération à moitié faite.

Le format des avis est un accord que l'on versionne ; CloudEvents exige que source plus id soit unique par événement, ce qui aide à détecter les renvois [14].

Cinq questions pour votre prochain comité

1. Quelles décisions exigent une réponse immédiate et lesquelles peuvent se résoudre avec un numéro de suivi ?
2. Quel est le rythme maximal que supporte notre système central, et que se passe-t-il s'il en arrive dix fois le volume ?
3. Qui est propriétaire de l'état final de chaque opération, et comment rapproche-t-on une opération restée incomplète ?
4. Comment vérifions-nous qu'une reprise ne duplique pas un paiement, une police, un CFDI ou un mouvement ?
5. Parmi ce que nous avons envoyé hier, quelles opérations ont une confirmation de résultat (appliquée ou rejetée) et lesquelles seulement un accusé de réception ?

Si, à deux de ces questions ou plus, la réponse est « je ne sais pas », votre risque peut se trouver là.

Par où commencer cette semaine

Notez vos processus les plus importants (émission, encaissement, timbrage, stocks), quel système répond à chacun et combien de travail par minute il supporte ; et si celui qui le déclenche a besoin de la réponse tout de suite ou si un numéro de suivi lui suffirait. Vous verrez où l'on utilise un appel en ligne pour un travail qui demandait une file.

Ensuite, prenez une interface et comptez combien d'opérations envoyées hier ont une confirmation de résultat, et pas seulement un accusé.

Ce que fait Hábil

Hábil est une société mexicaine de conseil en ingénierie, fondée en 2006, qui travaille entre les systèmes qu'une entreprise possède déjà et les canaux qu'elle doit ouvrir. Voyez la page Unifier votre activité et vos canaux.

La première conversation est sans frais : elle part d'une carte de vos intégrations actuelles et de l'endroit où votre exploitation pourrait perdre de l'argent, du temps ou des preuves. Écrivez-nous sur WhatsApp.

Les descriptions de services de fournisseurs reflètent leur documentation au 6 octobre 2026 ; ce sont des attributions du fournisseur, non des mesures propres.