Une commande appelle le stock, le paiement, l’ERP, le transport et le CRM avant de rendre la main. La démonstration paraît cohérente ; en production, une dépendance lente transforme chaque pic en timeout. L’équipe propose alors de « tout passer en asynchrone », tandis que la finance réclame un batch nocturne pour retrouver une clôture complète. Trois solutions techniques tentent de répondre à trois promesses qui n’ont jamais été séparées.
Le vrai enjeu n’est pas de choisir un pattern pour l’intégration entière. Il faut attribuer un rythme à chaque opération : verdict immédiat, propagation différée, consolidation périodique ou rattrapage. Le choix dépend de la fenêtre pendant laquelle la donnée crée encore de la valeur, du dommage d’un retard, de la cohérence nécessaire et de la manière dont le support reprend l’écart.
Cette méthode produit une matrice exploitable par métier, architecture et opérations. Elle explicite chemin principal, accusé, statut, idempotence, retry, fenêtre de batch, seuil de backlog et procédure de repli. Le lecteur peut ainsi contredire un choix avant le développement, puis le faire évoluer lorsque volumes et dépendances changent.
Dawap utilise cette granularité dans ses missions d’intégration API sur mesure. Elle évite d’imposer la vitesse maximale aux opérations qui ont surtout besoin de complétude, ou un traitement différé aux décisions qui protègent immédiatement une vente.
Séparer le rythme d’une opération de l’architecture globale
Une architecture synchrone, asynchrone ou événementielle décrit les relations structurantes entre systèmes. La matrice de rythme descend d’un niveau : elle décide comment une opération précise entre, accuse, termine et se rattrape. Une même intégration peut donc combiner un verdict synchrone, une propagation en file et une réconciliation par batch.
Ne pas redessiner le système à chaque arbitrage
L’architecture API synchrone, asynchrone et événementielle fixe les responsabilités, sources de vérité et modes d’échange. Ici, la sortie est différente : une fiche de décision par opération avec délai utile, volume, statut et reprise. Elle alimente l’architecture sans prétendre la remplacer.
Cette frontière évite la cannibalisation des décisions. Choisir qu’une réservation réponde immédiatement ne signifie pas que tous ses enrichissements restent couplés. Inversement, disposer d’un bus événementiel ne prouve pas qu’une validation bloquante puisse être différée.
Savoir quand requalifier le rythme d’une intégration
La matrice s’adresse aux responsables métier, produit, architecture, intégration et opérations lorsqu’un flux mélange plusieurs fenêtres de valeur ou que son mode historique ne tient plus la charge. Elle devient prioritaire lorsque les timeouts augmentent, que le backlog dépasse la promesse ou qu’un batch doit être relancé manuellement sans preuve de complétude.
Éviter une refonte inutile sur les échanges simples
Une lecture ponctuelle, un CRUD peu critique ou un export stable ne réclame pas nécessairement trois temporalités. L’effort devient rentable lorsque plusieurs acteurs attendent des résultats différents, que les dépendances imposent des rythmes incompatibles ou que le support ne peut plus expliquer où se trouve une transaction.
Le niveau de détail suit le dommage potentiel. Un flux marketing tolérant un retard documenté peut garder une matrice courte. Paiement, stock, facturation ou conformité exigent seuils, cohérence, replay et rollback démontrés avant toute bascule.
Découper le flux en décisions et propagations
Le flux est décomposé en verbes métier : vérifier, réserver, accepter, enrichir, notifier, consolider et rapprocher. Chaque verbe possède un appelant, une donnée d’entrée, un résultat exploitable et une conséquence en cas d’absence. Les étapes purement techniques restent rattachées au résultat qu’elles servent.
Repérer ce qui bloque réellement l’acteur suivant
Si l’utilisateur ne peut pas confirmer sans stock réservé, la réservation porte un verdict. L’envoi au CRM peut attendre si aucune action immédiate n’en dépend. Le rapprochement comptable peut viser l’exhaustivité à une heure de clôture plutôt qu’une propagation unitaire instantanée.
Les entrées du découpage sont parcours, règles et dépendances ; les sorties sont opérations nommées et critères de fin. Cette étape empêche un endpoint historique de devenir l’unité de décision simplement parce qu’il regroupe déjà plusieurs responsabilités.
Écrire la fenêtre de valeur métier
La fenêtre de valeur indique combien de temps le résultat reste utile. Un contrôle de disponibilité peut perdre sa valeur en deux secondes ; un enrichissement produit reste utile après dix minutes ; une consolidation de ventes doit être complète avant 6 h. « Temps réel » ne décrit aucune de ces promesses.
Relier retard, dommage et destinataire
Pour chaque opération, le métier décrit le dommage à 1 seconde, 1 minute, 1 heure et 1 jour : conversion perdue, décision retardée, stock divergent, clôture fausse ou simple inconfort. La première rupture significative fournit une borne, à confirmer par l’observation réelle.
La fenêtre distingue aussi échéance continue et rendez-vous. Un prix visible exige une fraîcheur permanente ; un reporting réglementaire exige une complétude à une heure fixe. Le premier favorise propagation fréquente et surveillance d’âge, le second peut favoriser un lot contrôlé avec preuve de totalité.
Réserver le synchrone au verdict bloquant
Le synchrone convient lorsque l’appelant ne peut pas poursuivre sans réponse ferme : autorisation de paiement, réservation, validation réglementaire ou création d’un identifiant faisant foi. Le contrat borne le délai, les erreurs et la responsabilité du timeout.
Réduire le chemin critique au minimum utile
Un verdict synchrone ne doit pas attendre notification, indexation, analytics ou enrichissement secondaire. Il confirme seulement ce qui autorise l’étape suivante. Les dépendances gardées en ligne doivent participer directement à cette décision et posséder une dégradation explicite.
Si trois services externes sont nécessaires et qu’aucun fallback n’existe, alors le rayon de panne du verdict devient leur produit. L’équipe choisit de rapprocher la règle, de réserver sur une projection fiable ou d’assumer le refus ; elle ne masque pas le couplage avec un timeout plus long.
Utiliser l’asynchrone pour absorber la variabilité
L’asynchrone convient lorsqu’une opération peut être accusée avant son résultat, que la charge varie ou qu’une dépendance répond irrégulièrement. Une file découple l’entrée du traitement, mais elle crée une nouvelle promesse : statut lisible, délai maximal et résultat consultable.
Financer attente, retry et quarantaine
Le message porte identifiant métier, version et clé d’idempotence. La politique distingue erreur transitoire, rejet fonctionnel et donnée empoisonnée. Après un nombre borné d’essais, la transaction rejoint une file de quarantaine avec cause et runbook, au lieu de tourner jusqu’à disparition du signal.
Le backlog se mesure en âge du plus ancien élément et temps estimé de vidage, pas seulement en nombre de messages. Si l’âge dépasse la fenêtre métier, alors absorber le pic ne suffit plus : le mode dégradé réduit les entrées ou priorise les opérations critiques.
Choisir le batch pour la complétude et le rattrapage
Le batch convient aux opérations qui gagnent à traiter un ensemble cohérent : rapprochement, agrégation, recalcul, export réglementaire ou synchronisation différentielle massive. Sa force n’est pas d’être ancien ou simple ; elle réside dans une fenêtre, un périmètre et un bilan de complétude explicites.
Conserver checkpoints et preuve de totalité
Chaque lot possède identifiant, borne de début, borne de fin, population attendue, éléments réussis, rejets et checksum éventuel. Les sous-lots permettent une reprise limitée. Un batch marqué terminé sans comparaison entre attendu et produit ne prouve aucune synchronisation.
Contre-intuitivement, un batch court peut protéger davantage le run qu’une émission unitaire permanente. Il limite les appels, stabilise les quotas et facilite le rapprochement. Il devient mauvais lorsque sa fenêtre dépasse la valeur métier ou lorsqu’un échec impose de rejouer aveuglément tout le périmètre.
Décider la cohérence réellement nécessaire
La cohérence forte est utile lorsqu’une décision irréversible dépend de l’état courant. La cohérence éventuelle suffit lorsqu’un décalage borné est visible, corrigible et sans dommage critique. La matrice nomme les invariants qui ne peuvent jamais diverger et les projections qui peuvent attendre.
Ne pas promettre une atomicité distribuée fictive
Un appel HTTP réussi dans deux systèmes ne garantit pas une transaction atomique. L’équipe choisit source de vérité, ordre des écritures, compensation et état intermédiaire. Si une étape aval échoue, le statut reste explicable et le prochain retry ne duplique pas l’effet déjà produit.
Les corrections humaines suivent la même hiérarchie. Une saisie validée ne doit pas être écrasée par un batch plus ancien. Version, origine et règle de priorité accompagnent chaque écriture afin que la fraîcheur technique ne l’emporte pas sur l’autorité métier.
Mesurer le rayon de panne des dépendances
Chaque rythme déplace le risque. Le synchrone expose immédiatement la disponibilité aval ; l’asynchrone expose backlog et capacité de reprise ; le batch expose fenêtre, complétude et durée de rattrapage. La matrice compare le dommage plutôt que de classer un mode comme intrinsèquement robuste.
Tester quota, latence et indisponibilité prolongée
Pour chaque dépendance, l’équipe simule timeout, 429, réponse partielle, donnée incohérente et arrêt de quatre heures. Elle observe ce qui bloque, ce qui s’accumule et le temps nécessaire au retour à la normale. Une reprise qui sature immédiatement le fournisseur n’est pas un plan de résilience.
Le quota devient une capacité budgétée. Une file ou un batch répartit les appels avec rate limiting ; un chemin synchrone conserve une marge pour les verdicts prioritaires. Si le quota est partagé, le reporting ne doit jamais affamer le paiement ou le stock.
Comparer le coût complet du run
Le coût inclut infrastructure, stockage, observabilité, astreinte, reprise, support et correction de données. Un appel synchrone simple peut coûter cher en indisponibilité ; une queue économique peut coûter cher si personne ne sait traiter sa quarantaine ; un batch peut coûter cher en enquête après un lot incomplet.
Attribuer le coût à l’opération qui le crée
Les incidents portent opération, rythme, cause, minutes humaines et impact métier. L’équipe compare coût par transaction aboutie et coût par écart corrigé. Elle évite qu’un flux volumineux paraisse efficace parce que les reprises sont comptées dans une équipe transverse.
Un changement de rythme est justifié s’il réduit le dommage total, pas seulement le temps CPU. Passer en asynchrone peut protéger la disponibilité mais ajouter un support de statut. Remplacer un batch par des webhooks peut améliorer la fraîcheur tout en augmentant les cas de désordre et de déduplication.
Construire une matrice par opération
La matrice rassemble opération, acteur bloqué, fenêtre utile, volume nominal et pic, source de vérité, cohérence, dépendances, accusé, statut, reprise et coût d’échec. Elle propose un rythme principal sans produire un score magique qui compenserait une contrainte critique.
Transformer les critères en décisions actionnables
- À garder synchrone : un verdict indispensable à l’étape suivante et bornable sous la fenêtre utile.
- À passer en asynchrone : une opération différable dont les pics et retries doivent être absorbés sans perdre le statut.
- À regrouper en batch : une opération où totalité, rapprochement ou efficacité de volume domine l’instantanéité.
- À refuser : tout mode sans propriétaire de reprise, identifiant stable ou preuve de fin.
La décision porte une date de révision. Si le volume, le SLA fournisseur, le coût d’astreinte ou la promesse change, alors l’opération repasse dans la matrice. Un choix de rythme n’est pas une propriété éternelle du domaine.
Composer un chemin principal et un rattrapage
La plupart des intégrations robustes combinent les rythmes. Un verdict synchrone produit un état minimal ; une queue propage les enrichissements ; un batch rapproche périodiquement source et cible. Le rattrapage ne remplace pas le chemin principal : il détecte et corrige ses écarts résiduels.
Éviter que deux chemins deviennent deux vérités
Tous les chemins partagent identifiant, version et règle d’autorité. Le batch ne réécrit pas une décision plus récente ; la queue ignore un événement déjà appliqué ; l’appel synchrone n’annonce pas une fin globale lorsque seuls ses invariants sont validés.
Le bilan rapproche événements émis, effets observés et écarts. Une correction crée une trace et peut republier un fait compensateur. Supprimer manuellement une ligne pour faire disparaître l’alerte détruirait précisément la preuve utile au run.
Arbitrer une commande entre trois rythmes
Exemple concret : une commande marketplace doit réserver le stock en moins de deux secondes, transmettre l’ordre à l’ERP sous cinq minutes, enrichir le CRM dans l’heure et rapprocher toutes les lignes avant 5 h. Le système historique exécute ces quatre opérations dans un appel séquentiel.
Donner à chaque promesse son propre contrat
La réservation reste synchrone avec un timeout court et un verdict explicite. L’ordre ERP passe en file avec statut consultable, idempotence et quarantaine. Le CRM utilise la même propagation sans bloquer la commande. Un batch nocturne compare commandes, réservations et documents ERP pour prouver la complétude.
Si l’âge du backlog ERP dépasse trois minutes, alors le trafic est ralenti avant rupture du seuil de cinq. Si le batch trouve plus de 0,5 % d’écarts, alors la réconciliation ouvre un incident et empêche la clôture automatique. Le découpage protège la conversion sans abandonner la vérité comptable.
Définir seuils de bascule et rollback
Chaque choix possède un signal de saturation : p95 synchrone, âge du backlog, durée de lot, taux de rejet et coût de reprise. Les seuils déclenchent une action connue, pas une simple couleur. Monitoring et alerte incluent opération, owner, dépendance et runbook.
Revenir au dernier rythme sûr sans perdre les transactions
Le rollback peut désactiver un enrichissement, remettre une file en lecture seule, réduire un lot ou restaurer un appel direct borné. Les éléments déjà acceptés restent traçables et sont drainés selon leur version. On ne mélange pas ancien et nouveau consommateur sans règle de partage.
Le déploiement tourne d’abord en miroir sur une cohorte. Si les résultats divergent, l’équipe compare décision, ordre et délai avant d’augmenter le trafic. Une bascule complète exige deux fenêtres stables et un exercice de reprise réussi, pas seulement un test nominal vert.
Erreurs fréquentes : imposer un rythme à tout le flux
Mettre du temps réel partout multiplie les dépendances critiques. Passer tout en file masque parfois un verdict dont l’utilisateur a besoin. Conserver un batch géant rend la reprise disproportionnée. Confondre accusé et résultat donne un faux sentiment de fin.
Refuser les choix sans statut ni rattrapage
Retry sans idempotence fabrique des doublons. Batch sans population attendue ne prouve pas la complétude. File sans âge maximal transforme le retard en stock invisible. Synchrone sans dégradation laisse une dépendance secondaire arrêter le parcours principal.
L’erreur inverse consiste à multiplier les technologies pour montrer une architecture moderne. Si deux opérations partagent promesse, risque et reprise, elles peuvent partager un rythme. La matrice vise une complexité justifiée, pas la diversité des composants.
Requalifier une intégration en trente jours
Les entrées sont parcours, opérations, fenêtres utiles, événements, volumes, incidents, coûts et dépendances. Les sorties sont matrice, chemin principal, rattrapage, seuils, owners, monitoring et rollback. Métier valide le dommage ; architecture le contrat ; opérations la reprise ; finance le coût complet.
Passer d’un flux historique à des temporalités gouvernées
- Jours 1 à 5 : nommer les opérations et leurs résultats exploitables.
- Jours 6 à 10 : mesurer délais, volumes, pics, rejets et reprises actuels.
- Jours 11 à 15 : écrire fenêtres utiles, invariants et sources de vérité.
- Jours 16 à 20 : attribuer rythme principal, accusé, statut et rattrapage.
- Jours 21 à 25 : tester dépendances lentes, doublons, backlog et lot incomplet.
- Jours 26 à 30 : lancer une cohorte miroir et tenir le premier verdict.
À trente jours, le comité vérifie que chaque opération possède owner, délai, preuve de fin et repli. À quatre-vingt-dix jours, il compare valeur produite, coût de run, incidents et temps de retour à la normale. Une amélioration de latence qui augmente les reprises humaines bloque la généralisation.
La cohorte miroir conserve ancien et nouveau résultat avec la même clé de corrélation. Chaque divergence est classée entre ordre différent mais acceptable, perte de donnée, doublon, délai dépassé ou autorité mal appliquée. Produit valide le sens, opérations la reprise et data le rapprochement. La décision de bascule publie le périmètre, la version des consommateurs et le point exact auquel l’ancien chemin cesse d’accepter de nouvelles transactions.
- À faire d’abord : sortir les enrichissements du chemin critique.
- À différer : le changement de broker tant que le contrat métier reste flou.
- À corriger : les lots sans checkpoint et les files sans quarantaine.
- À refuser : un choix unique appliqué par convention à toutes les opérations.
Le suivi hebdomadaire relit les opérations proches de leur seuil, la capacité de drainage et les corrections manuelles. Le bilan mensuel compare coût prévu et coût observé, puis retire les chemins transitoires devenus inutiles. Cette gouvernance empêche qu’une migration terminée sur le papier conserve deux implémentations actives pendant des années.
Relier rythme, délai et architecture
La mesure du délai métier de bout en bout vérifie ensuite que la combinaison tient la promesse vécue, y compris files, lots et validations. Elle fournit la chronologie qui permet de réviser une ligne de la matrice sans optimiser le mauvais composant.
Approfondir le mécanisme qui porte le risque dominant
Lorsqu’une file devient le chemin critique, la méthode de dead letter queue et rejeu métier précise quarantaine et retour contrôlé. Lorsqu’un choix modifie plusieurs domaines, le cadre d’architecture conserve source de vérité et responsabilités.
Ces contenus répondent à trois questions séparées : quel rythme attribuer à l’opération, quel délai le parcours produit réellement et comment industrialiser le mécanisme retenu. Garder cette chaîne explicite protège la landing d’intégration et évite les décisions techniques orphelines.
Conclusion : rendre chaque temporalité opérable
Synchrone, asynchrone et batch ne sont pas trois camps. Ce sont trois temporalités à attribuer selon le verdict attendu, la fenêtre de valeur, la cohérence, le volume et le coût de reprise de chaque opération.
La matrice empêche un pattern unique d’envahir tout le flux. Elle compose un chemin principal étroit, une propagation observable et un rattrapage capable de prouver la complétude sans réécrire les décisions récentes.
Dawap vous accompagne pour cadrer ces choix, instrumenter leurs seuils et sécuriser leur bascule dans une intégration API fiable en production, du contrat métier jusqu’au runbook de reprise.
