Comparez les flux de travail pilotés par des événements et les API requête‑réponse pour les processus de longue durée, en mettant l'accent sur approbations, timers, reprises et traces d'audit dans les applications métier.
Un processus est « long » quand il ne peut pas se terminer en une étape rapide. Il peut durer des minutes, des heures ou des jours parce qu'il dépend de personnes, du temps ou de systèmes externes. Tout ce qui implique des approbations, des transferts ou de l'attente entre dans cette catégorie.
C'est là que la pensée simple « requête‑réponse » commence à montrer ses limites. Un appel d'API est fait pour un échange court : envoyer une requête, obtenir une réponse, passer à autre chose. Les tâches longues ressemblent plus à une histoire en chapitres. Il faut pouvoir faire une pause, se souvenir exactement où on en est, et reprendre plus tard sans deviner.
On voit ça dans les apps métier courantes : approbations d'achats qui nécessitent un manager et les finances, onboarding d'un employé qui attend des vérifications de documents, remboursements dépendant d'un fournisseur de paiement, ou demandes d'accès à examiner puis appliquer.
Quand les équipes traitent un long processus comme un seul appel d'API, quelques problèmes prévisibles apparaissent :
Un scénario concret : un employé demande l'accès à un logiciel. Le manager approuve vite, mais l'équipe IT met deux jours à provisionner. Si l'app ne sait pas conserver l'état du processus, envoyer des rappels et reprendre en sécurité, on obtient des relances manuelles, des utilisateurs confus et du travail supplémentaire.
C'est pourquoi le choix entre flux pilotés par des événements et API requête‑réponse importe pour les processus métier longs.
La comparaison la plus simple revient à une question : le travail se termine‑t‑il pendant que l'utilisateur attend, ou continue‑t‑il après son départ ?
Une API requête‑réponse est un échange unique : un appel entrant, une réponse en sortie. Elle convient aux travaux qui s'achèvent rapidement et de façon prévisible, comme créer un enregistrement, calculer un devis ou vérifier un stock. Le serveur fait le travail, renvoie succès ou erreur, et l'interaction est finie.
Un flux piloté par des événements est une série de réactions dans le temps. Quelque chose se produit (une commande est créée, un manager approuve, un timer expire), et le workflow passe à l'étape suivante. Ce modèle convient aux travaux qui incluent des transferts, de l'attente, des reprises et des rappels.
La différence pratique, c'est l'état.
Avec requête‑réponse, l'état vit souvent dans la requête courante plus la mémoire du serveur jusqu'à l'envoi de la réponse. Avec des workflows pilotés par des événements, l'état doit être stocké (par exemple dans PostgreSQL) pour que le processus puisse reprendre plus tard.
La gestion des échecs change aussi. La requête‑réponse renvoie généralement une erreur et demande au client de réessayer. Les workflows enregistrent l'échec et peuvent retenter en sécurité quand les conditions s'améliorent. Ils peuvent aussi journaliser chaque étape comme événement, ce qui rend l'historique plus facile à reconstituer.
Un exemple simple : « Soumettre une note de frais » peut être synchrone. « Obtenir une approbation, attendre 3 jours, rappeler le manager, puis payer » ne l'est pas.
Les approbations sont le moment où le travail long devient réel. Une étape système finit en millisecondes, mais une personne peut répondre en deux minutes ou deux jours. Le choix clé est de modéliser cette attente comme un processus en pause, ou comme un nouveau message qui arrive plus tard.
Avec les API requête‑réponse, les approbations prennent souvent une forme maladroite :
Tout cela peut fonctionner, mais cela ajoute de la tuyauterie juste pour relier le « temps humain » au « temps API ».
Avec les événements, l'approbation se lit comme une histoire. L'app enregistre quelque chose comme « ExpenseSubmitted », puis reçoit plus tard « ExpenseApproved » ou « ExpenseRejected ». Le moteur de workflow (ou votre propre machine à états) fait avancer l'enregistrement seulement quand l'événement suivant arrive. Cela correspond à la façon dont la plupart des gens pensent déjà les étapes métier : soumettre, examiner, décider.
La complexité apparaît vite avec plusieurs approbateurs et des règles d'escalade. Vous pouvez exiger à la fois un manager et les finances, tout en permettant à un manager senior d'outrepasser. Si vous ne modélisez pas ces règles clairement, le processus devient difficile à raisonner et encore plus difficile à auditer.
Un pattern pratique est de conserver un seul enregistrement « requête », puis de stocker les décisions séparément. De cette façon vous supportez plusieurs approbateurs sans réécrire la logique centrale.
Capturez quelques éléments comme des enregistrements de première classe :
Quelle que soit l'implémentation, enregistrez toujours qui a approuvé quoi, quand et pourquoi comme données, pas comme une simple ligne de log.
L'attente est le point où les tâches longues commencent à sembler désordonnées. Les gens partent déjeuner, les calendriers se remplissent, et « on vous recontacte » devient « qui en est responsable maintenant ? ». C'est une des différences les plus nettes entre workflows pilotés par des événements et API requête‑réponse.
Avec les API requête‑réponse, le temps est gênant. Les appels HTTP ont des timeouts, on ne peut pas garder une requête ouverte pendant deux jours. Les équipes finissent généralement par utiliser du polling, un job planifié qui scanne la base, ou des scripts manuels quand quelque chose est en retard. Ça peut marcher, mais la logique d'attente vit hors du processus. Les cas limites sont faciles à manquer : que se passe‑t‑il quand le job s'exécute deux fois, ou quand l'enregistrement a changé juste avant l'envoi d'un rappel ?
Les workflows traitent le temps comme une étape normale. Vous pouvez dire : attendre 24 heures, envoyer un rappel, puis attendre jusqu'à 48 heures au total et escalader vers un autre approbateur. Le système garde l'état, donc les échéances ne sont pas cachées dans un projet séparé « cron + requêtes ».
Une règle d'approbation simple pourrait se lire ainsi :
Après soumission d'une note de frais, attendre 1 jour. Si le statut est toujours « Pending », envoyer un message au manager. Après 2 jours, si c'est toujours en attente, réaffecter au responsable du manager et enregistrer l'escalade.
Le détail clé est ce que vous faites quand le timer se déclenche mais que le monde a changé. Un bon workflow re‑vérifie toujours l'état courant avant d'agir :
Les reprises interviennent quand quelque chose a échoué pour des raisons hors de votre contrôle : la passerelle de paiement time‑out, le fournisseur d'email renvoie une erreur temporaire, ou votre app sauvegarde l'étape A mais plante avant l'étape B. Le danger est simple : vous réessayez et vous faites l'action deux fois.
Avec les API requête‑réponse, le pattern courant est que le client appelle un endpoint, attend, et s'il n'obtient pas un succès clair, il retente. Pour que cela soit sûr, le serveur doit traiter les appels répétés comme la même intention.
Une correction pratique est une clé d'idempotence : le client envoie un token unique comme pay:invoice-583:attempt-1. Le serveur stocke le résultat pour cette clé et renvoie le même résultat pour les répétitions. Cela évite les doubles prélèvements, les tickets en doublon ou les approbations répétées.
Les workflows pilotés par des événements ont un autre risque de duplication. Les événements sont souvent livrés au moins‑une‑fois, ce qui signifie que des doublons peuvent apparaître même quand tout fonctionne. Les consommateurs doivent dédupliquer : enregistrer l'ID de l'événement (ou une clé métier comme invoice_id + step) et ignorer les répétitions. C'est une différence fondamentale : la requête‑réponse se concentre sur la relecture sûre des appels, les événements sur la relecture sûre des messages.
Quelques règles de reprise valables pour les deux modèles :
Les reprises doivent être explicites dans le processus, pas un comportement caché. C'est ainsi que les échecs deviennent visibles et réparables.
Une trace d'audit est votre fichier « pourquoi ». Quand quelqu'un demande « Pourquoi cette note de frais a‑t‑elle été rejetée ? », vous devez pouvoir répondre sans deviner, même des mois après. Cela compte dans les deux approches, mais le travail diffère.
Pour tout processus long, enregistrez les faits qui permettent de rejouer l'histoire :
Les workflows pilotés par des événements peuvent faciliter l'audit parce que chaque étape produit naturellement un événement comme « ManagerApproved » ou « PaymentFailed ». Si vous stockez ces événements avec le payload et l'acteur, vous avez une chronologie propre. L'important est de garder les événements descriptifs et stockés quelque part consultable par dossier.
Les API requête‑réponse restent auditable, mais l'histoire est souvent dispersée entre services. Un endpoint logge « approved », un autre logge « payment requested », un troisième logge « retry succeeded ». Si chacun utilise des formats ou champs différents, les audits deviennent une enquête.
Une correction simple est une « case ID » partagée (ou correlation ID). C'est un identifiant que vous attachez à chaque requête, événement et enregistrement de la base pour l'instance du processus, par exemple EXP-2026-00173. Vous pouvez alors tracer tout le parcours à travers les étapes.
Le meilleur choix dépend de si vous avez besoin d'une réponse immédiate, ou d'un processus qui continue sur des heures ou des jours.
La requête‑réponse fonctionne bien quand le travail est court et que les règles sont simples. Un utilisateur soumet un formulaire, le serveur le valide, sauvegarde les données et renvoie succès ou erreur. C'est aussi adapté aux actions claires et en une étape comme créer, mettre à jour ou vérifier des permissions.
Les problèmes commencent quand une « requête unique » se transforme en plusieurs étapes : attente d'une approbation, appels à plusieurs systèmes externes, gestion des timeouts, ou branchements selon la suite. Vous gardez soit une connexion ouverte (fragile), soit vous poussez l'attente et les reprises dans des jobs background difficiles à raisonner.
Les workflows pilotés par des événements excellent quand le processus est une histoire dans le temps. Chaque étape réagit à un nouvel événement (approuvé, rejeté, timer déclenché, paiement échoué) et décide de la suite. Cela facilite la mise en pause, la reprise, la reprise d'erreurs et la conservation d'une trace claire des raisons des actions.
Il y a de vrais compromis :
Un exemple pratique : une note de frais qui nécessite l'approbation du manager, puis la revue des finances, puis le paiement. Si le paiement échoue, vous voulez des reprises sans double‑paiement. C'est naturellement événementiel. Si c'est juste « soumettre une note » avec des contrôles rapides, la requête‑réponse suffit souvent.
Les processus longs échouent de façons ennuyeuses : un onglet ferme, un serveur redémarre, une approbation reste deux jours en attente, ou un fournisseur de paiement time‑out. Anticipez ces délais dès le départ, quel que soit le modèle choisi.
Commencez par définir un petit ensemble d'états que vous pouvez stocker et reprendre. Si vous ne pouvez pas identifier l'état courant dans votre base, vous n'avez pas vraiment un workflow reprenable.
Pour survivre aux redémarrages, persistez le minimum de données nécessaire pour continuer en sécurité. Stockez assez pour relancer sans deviner :
Si vous pouvez reconstruire « où on en est » et « ce qui est autorisé ensuite » à partir des données sauvegardées, les délais cessent d'être inquiétants.
Les processus longs montrent leurs faiblesses quand de vrais utilisateurs arrivent. Une approbation prend deux jours, une reprise se déclenche au mauvais moment, et vous vous retrouvez avec un double paiement ou une trace d'audit manquante.
Erreurs fréquentes :
Un exemple simple : une note de frais est approuvée dans le chat, un webhook arrive en retard, et l'API de paiement est retentée. Sans état persistant et idempotence, la reprise peut déclencher deux paiements, et vos enregistrements n'expliqueront pas clairement pourquoi.
La plupart des corrections consistent à être explicite :
Le travail long, ce n'est pas une requête parfaite mais rester correct après délais, personnes et pannes.
Écrivez ce que « sûr pour continuer » signifie pour votre processus. Si l'app redémarre en plein milieu, vous devez pouvoir reprendre depuis la dernière étape connue sans deviner.
Une checklist pratique :
ExpenseRequest-10482) et un modèle de statuts clair (Submitted, Waiting for Manager, Approved, Paid, Failed).Test de sanity : imaginez que le fournisseur de paiement time‑out après que vous ayez déjà débité la carte. Votre conception doit empêcher un double débit tout en permettant au processus de se terminer.
Scénario : un employé soumet un reçu taxi de 120 $ pour remboursement. Il nécessite l'approbation du manager dans les 48 heures. Si approuvé, le système paie l'employé. Si le paiement échoue, il est retenté en sécurité et laisse une trace claire.
Avec les API requête‑réponse, l'app se comporte souvent comme une conversation qui doit vérifier en permanence.
L'employé tape Soumettre. Le serveur crée un enregistrement de remboursement avec le statut « Pending approval » et renvoie un ID. Le manager reçoit une notification, mais l'app de l'employé doit souvent interroger pour voir si quelque chose a changé, par exemple : « GET reimbursement status by ID ».
Pour respecter la limite de 48 heures, vous exécutez soit un job planifié qui scanne les requêtes en retard, soit vous stockez un timestamp et le vérifiez lors des polls. Si le job est retardé, les utilisateurs voient un état obsolète.
Quand le manager approuve, le serveur passe le statut à « Approved » et appelle le fournisseur de paiement. Si Stripe renvoie une erreur temporaire, le serveur doit décider de retenter maintenant, plus tard, ou d'échouer. Sans clés d'idempotence prudentes, une reprise peut créer un double paiement.
Dans un modèle événementiel, chaque changement est un fait enregistré.
L'employé soumet, produisant un événement « ExpenseSubmitted ». Un workflow démarre et attend soit « ManagerApproved », soit un timer « DeadlineReached » à 48 heures. Si le timer saute en premier, le workflow enregistre un « AutoRejected » et la raison.
Sur approbation, le workflow enregistre « PayoutRequested » et tente le paiement. Si Stripe time‑out, il enregistre « PayoutFailed » avec un code d'erreur, programme une reprise (par exemple dans 15 minutes), et n'enregistre « PayoutSucceeded » qu'une fois en utilisant une clé d'idempotence.
Ce que voit l'utilisateur reste simple :
La trace d'audit se lit comme une timeline : soumis, approuvé, échéance vérifiée, paiement tenté, échoué, retenté, payé.
Choisissez un vrai processus et implémentez‑le de bout en bout avant de généraliser. Approvisionnement de dépenses, onboarding et gestion des remboursements sont de bons points de départ car ils mêlent étapes humaines, attentes et chemins d'erreur. Gardez l'objectif petit : un chemin heureux et les deux exceptions les plus courantes.
Écrivez le processus en états et événements, pas en écrans. Par exemple : « Submitted » -> « ManagerApproved » -> « PaymentRequested » -> « Paid », avec des branches comme « ApprovalRejected » ou « PaymentFailed ». Quand les points d'attente et les effets secondaires sont clairs, le choix entre flux événementiel et API requête‑réponse devient pratique.
Décidez où vit l'état du processus. Une base de données suffit si le flux est simple et vous pouvez garantir des mises à jour en un endroit. Un moteur de workflow aide quand vous avez besoin de timers, reprises et branchements, car il suit ce qui doit arriver ensuite.
Ajoutez des champs d'audit dès le départ. Stockez qui a fait quoi, quand et pourquoi (commentaire ou code raison). Quand quelqu'un demande « Pourquoi ce paiement a‑t‑il été retenté ? », vous devez une réponse claire sans fouiller les logs.
Si vous construisez ce type de workflow dans une plateforme no‑code, AppMaster (appmaster.io) est une option où vous pouvez modéliser les données dans PostgreSQL et construire la logique de processus visuellement, ce qui peut faciliter la cohérence des approbations et des traces d'audit entre les apps web et mobiles.
When should I use request-response instead of an event-driven workflow?Utilisez la requête‑réponse quand le travail se termine vite et de façon prévisible pendant que l'utilisateur attend, par exemple créer un enregistrement ou valider un formulaire. Choisissez un workflow piloté par des événements quand le processus s'étend sur des minutes à des jours, inclut des approbations humaines, ou nécessite des timers, des reprises et une reprise sûre après redémarrage.
Why do long-running processes break when built like a single API call?Les tâches longues ne tiennent pas dans une seule requête HTTP : les connexions expirent, les serveurs redémarrent, et le travail dépend souvent de personnes ou de systèmes externes. En les traitant comme un seul appel, on perd l'état, on crée des doublons lors des reprises et on finit avec des scripts background dispersés pour gérer l'attente.
How do I make a long-running process resumable after a restart?Par défaut, persistez un état clair du processus dans votre base de données et n'avancez qu'avec des transitions explicites. Stockez l'ID de l'instance, le statut actuel, qui peut agir ensuite et les timestamps clés pour reprendre en toute sécurité après un déploiement, un crash ou un délai.
What’s the cleanest way to handle human approvals?Modélisez l'approbation comme une étape mise en pause qui reprend quand la décision arrive, plutôt que de bloquer la requête ou de faire du polling constant. Enregistrez chaque décision comme des données (qui, quand, approuvé/rejeté, et la raison) pour que le workflow avance de façon prévisible et qu'on puisse l'auditer après coup.
Is polling for approval status a bad idea?Le polling peut convenir pour des cas simples, mais il génère du bruit et des délais parce que le client demande sans cesse « c'est fini ? ». Par défaut, mieux vaut pousser une notification au changement et laisser le client rafraîchir à la demande, en conservant le serveur comme source de vérité pour l'état.
How should I implement reminders, deadlines, and escalations?Traitez le temps comme une partie du processus : enregistrez les échéances et heures de rappel, et quand un timer se déclenche, re‑vérifiez l'état actuel avant d'agir. Ainsi on évite d'envoyer un rappel après qu'une décision ait déjà été prise et on maintient des escalades cohérentes même si les jobs s'exécutent en retard ou plusieurs fois.
How do I prevent double payments or duplicate emails when retries happen?Commencez par des clés d'idempotence pour tout effet externe (paiement, email) et stockez le résultat pour cette clé. Les reprises deviennent sûres parce qu'une répétition de la même intention renverra le même résultat au lieu d'exécuter l'action à nouveau.
How do I handle duplicate events in an event-driven system?Supposez que les messages peuvent être livrés plusieurs fois et concevez les consommateurs pour dédupliquer. Une approche pratique est d'enregistrer l'ID de l'événement (ou une clé métier pour l'étape) et d'ignorer les répétitions afin qu'un replay n'entraîne pas deux fois la même action.
What should an audit trail include for long-running workflows?Capturez une chronologie de faits : acteur, horodatage, les données connues à ce moment, le résultat, et la version de la règle ou politique utilisée. Associez aussi un identifiant de dossier ou de corrélation unique à tout ce qui concerne le processus pour que le support puisse répondre « où ça bloque ? » sans fouiller des logs non pertinents.
What’s a practical data model for approvals that won’t get messy as rules grow?Gardez un enregistrement de type « requête » comme cas unique, stockez les décisions séparément, et faites évoluer l'état via des transitions persistées et rejouables. Dans un outil no‑code comme AppMaster, vous pouvez modéliser les données dans PostgreSQL et implémenter la logique d'étape visuellement, ce qui aide à garder les approbations, reprises et champs d'audit cohérents dans l'app.
27 janv. 2026
8 min
26 janv. 20268 min
21 janv. 20268 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
