Conception de workflows IA : cinq patterns pour les processus d'agents multi-étapes

Points clés

• Les appels d'outils MCP via OpenAI ont atteint 98 fois leur niveau de janvier en août 2026, plus que doublant sur le seul mois d'août (AAIF) — une seule requête utilisateur déclenche désormais un workflow de nombreux appels, ce qui fait de la conception de workflows, et non du prompt, la discipline de production.
• Gartner prévoit que les coûts d'inférence IA par workflow agentique augmenteront de plus de cinq fois d'ici 2028 — les prix par token baissent tandis que les coûts par workflow montent, car les workflows agentiques consomment des ordres de grandeur plus de tokens que le chat.
• La feuille de route MCP a transformé Tasks en extension officielle (SEP-2663) et ajouté Multi Round-Trip Requests (SEP-2322) pour que les flux multi-étapes survivent sur des serveurs sans état — le protocole suppose désormais que le travail s'exécute longtemps et s'étend sur plusieurs tours.
• OpenAI déclare que ses moniteurs de désalignement peuvent mettre en pause « des tâches où un agent s'exécute pendant une période prolongée », et les tâches de l'API s'arrêtent plutôt que de reprendre — un workflow de production doit pouvoir reprendre depuis un état durable, pas depuis un processus vivant.
• Un module RFQ de 38 outils exécute chacun de ces patterns en code — transitions d'état appliquées par des guards, libération idempotente des réservations avec un TTL de 15 minutes, et snapshots de change figés au moment du devis.

Les appels d'outils MCP des utilisateurs de ChatGPT ont atteint 98 fois leur niveau de janvier en août 2026, selon l'analyse d'usage de l'Agentic AI Foundation — et les appels ont plus que doublé sur le seul mois d'août. Le trafic MCP de Resend raconte la même histoire côté fournisseur : 106 719 appels en avril, 1 062 650 en août. Les mainteneurs du protocole tirent eux-mêmes la conclusion opérationnelle dans la nouvelle feuille de route MCP : « Les charges de travail agentiques modernes ne correspondent plus au modèle standard requête-réponse. Les boucles peuvent s'exécuter plus longtemps, les serveurs peuvent pousser des résultats en streaming, et il y a un besoin clair de piloter le travail en plein vol. »

Le chat n'a jamais été la partie difficile. Le workflow l'est : l'éventail de consultations de catalogues derrière une RFQ, l'approbation qui doit arriver avant une écriture dans l'ERP, l'API du fournisseur qui expire en plein devis, le taux de change qui ne doit pas dériver entre la tarification et la réservation. Gartner prévoit que les coûts d'inférence par workflow augmenteront de plus de cinq fois d'ici 2028 même si les prix par token baissent, car les workflows agentiques raisonnent, négocient et se remettent en question sur de nombreux appels. Cet article définit les cinq patterns au niveau du workflow qui décident si un processus d'agent multi-étapes tient sous cette charge — fan-out, checkpoints, compensation, état durable et branchement mesuré — et ancre chacun dans une implémentation RFQ fonctionnelle qui enregistre 38 outils MCP contre un backend GraphQL.

Le workflow est l'unité que vous concevez. Le diagramme ci-dessous compresse les cinq patterns en une minute : le fan-out parallèle des lectures, l'épine dorsale sérialisée des écritures avec ses deux portes humaines, la compensation typée en cas d'échec, et la règle d'état durable qui les relie.

Pattern 1 : Fan-out des lectures, écritures sérialisées

La première décision de workflow est la forme du graphe de dépendances. La plupart des processus d'agents multi-étapes sont majoritairement parallèles : une RFQ a besoin des paliers de prix de trois catalogues fournisseurs, de la disponibilité par lot de cinq lignes, et du segment client — dont rien ne dépend des autres. Sérialiser ces étapes multiplie la latence par le nombre d'étapes et multiplie le rayon d'impact de n'importe quel timeout. Le bon défaut est de fan-outer chaque lecture indépendante en parallèle et de ne sérialiser que la chaîne d'écriture, où chaque étape consomme la sortie de l'étape précédente.

La chaîne d'écriture dans un workflow de devis est strictement ordonnée pour une raison métier, pas technique : demande confirmée → devis créé → disponibilité réservée → échéances programmées. Notre moteur RFQ l'applique avec des operation guards en code — un RequestOperationGuard refuse de créer des devis depuis une demande non confirmée, et un QuoteOperationGuard refuse les modifications de lignes une fois que le devis a dépassé sa fenêtre éditable. Le pattern de workflow est le même dans tous les systèmes : lectures parallèles derrière un batch loader, une colonne sérialisée étroite pour les écritures qui changent l'état, et les guards en code plutôt que dans le prompt. Un agent qui « décide » de l'ordre à chaque exécution est un workflow sans invariants.

Pattern 2 : Les checkpoints humains sont des états, pas des prompts

Le deuxième pattern gouverne où se situe l'humain. Dans une conception à prompts seuls, « demandez à l'utilisateur avant de soumettre » est une suggestion que le modèle peut suivre ou non. Dans une conception de workflow, le checkpoint est un état durable : le processus s'arrête dans un état nommé, persiste tout ce qui est nécessaire pour continuer, et seule une action humaine le fait avancer. La distinction est devenue opérationnellement urgente le 1er septembre, quand OpenAI a révélé que ses moniteurs de désalignement en production peuvent arrêter automatiquement une activité potentiellement non autorisée — et en a honnêtement signalé le coût : les garde-fous « peuvent parfois signaler une activité légitime comme un abus cyber potentiel… Cela peut inclure un travail qui ne semble pas directement lié à la cybersécurité ou des tâches où un agent s'exécute pendant une période prolongée ». Dans ChatGPT et Codex, les utilisateurs sont invités à examiner la tâche suspendue ; sur l'API, la tâche s'arrête.

Un workflow construit pour ce monde traite la pause comme un état conçu, pas comme une exception : l'enregistrement d'exécution montre ce qui est terminé, ce qui est en attente, et quel est le chemin de reprise. Les deux outils de commodité de notre moteur RFQ — confirm_request_and_create_quotes et confirm_quote_and_create_installments — existent précisément parce que la porte humaine se situe entre eux : un humain confirme, puis le travail mécanique multi-étapes s'exécute comme un seul appel audité. L'enquête de Camunda auprès de 1 150 dirigeants IT seniors a révélé que 71 % des organisations utilisent des agents IA mais que seulement 11 % des cas d'usage atteignent la production ; les workflows qui franchissent ce fossé sont ceux où une approbation est un état dans lequel le système peut rester des heures, pas une phrase dans un prompt système. Les mécanismes d'exécution des checkpoints au niveau runtime vivent dans Loop Engineering : pourquoi le runtime de l'agent est le nouveau middleware ; le pattern de workflow consiste à décider, avant que quoi que ce soit ne soit livré, quelles étapes s'arrêtent devant un humain et depuis quel état le processus reprend.

Pattern 3 : Chaque étape avant a besoin d'un chemin de compensation

Le troisième pattern est celui que les tutoriels sautent : qu'est-ce qui annule une étape. Les workflows de longue durée échouent en plein vol — l'API d'un fournisseur renvoie une erreur à la ligne quatre sur cinq, une réservation expire pendant que l'agent tarife, un devis est approuvé mais la programmation du paiement échoue. Un workflow sans chaînes de compensation transforme chaque échec en nettoyage manuel. Un workflow avec compensation transforme chaque échec en une opération inverse typée et idempotente.

L'implémentation de devis en montre l'anatomie. Les réservations de disponibilité expirent avec un TTL de 15 minutes, et la surface d'échec est énumérée en erreurs typées — HOLD_NOT_FOUND, HOLD_ALREADY_EXPIRED, AVAILABILITY_INSUFFICIENT — chacune mappée à une récupération distincte : revérifier, réacquérir ou escalader à un humain. Libérer une réservation est idempotent, si bien qu'un retry après une partition réseau ne peut pas libérer deux fois, et confirmer une réservation ne décompte jamais deux fois. Les appels d'outils sont enveloppés dans un décorateur de retry avec backoff exponentiel, et le statut, la durée et la charge utile de chaque appel (déchargée vers le stockage objet au-delà de 400 Ko) atterrissent dans un enregistrement d'audit. C'est le pattern généralisé : les étapes avant acquièrent des ressources ; les étapes de compensation les libèrent ; chaque compensation peut s'exécuter deux fois sans risque. Si votre workflow ne peut pas nommer l'annulation de chaque étape, il n'a pas de workflow — il a une démo qui n'a pas encore rencontré de panne fournisseur.

Pattern 4 : Protocole sans état, workflow avec état

Le quatrième pattern résout une contradiction apparente dans la spécification MCP 2026-07-28. La spécification a supprimé les sessions au niveau du protocole et le handshake d'initialisation (SEP-2575, SEP-2567) pour que les serveurs scalent horizontalement sans retenir d'état, et la feuille de route a transformé Tasks en extension officielle (SEP-2663) tandis que Multi Round-Trip Requests (SEP-2322) remplaçait les requêtes initiées par le serveur pour que les flux d'elicitation continuent de fonctionner en pleine tâche. Le protocole est sans état ; le workflow est ce qui porte l'état. Concrètement : chaque requête doit arriver autoporteuse, et l'état du workflow vit dans des enregistrements durables et inspectables — pas dans la mémoire d'un serveur.

Ce choix d'architecture est ce qui rend le pattern précédent survivable. Dans notre moteur RFQ, le hold_token et le hold_expires_at de la réservation sont posés directement sur la ligne de devis, et le taux de change est figé avec un horodatage fx_rate_locked_at au moment du devis — des snapshots, pas des références vivantes. N'importe quelle instance de serveur peut prendre la requête suivante ; un processus redémarré reprend depuis l'enregistrement, pas depuis la RAM. Et l'avertissement d'Astra fait de la reprise une exigence d'interaction plateforme, pas seulement une tolérance aux pannes : si le garde-fou d'un modèle de frontière suspend votre exécution non supervisée de 38 heures, le workflow qui survit est celui qui gardait son état hors du processus. Nous couvrons les mécanismes de déploiement de la spécification sans état dans Le protocole MCP sans état : ce qui change pour les déploiements B2B ; au niveau du workflow, la règle est simple — concevez comme si n'importe quelle étape pouvait être la dernière avant une pause, et rendez la prochaine étape reconstructible depuis la piste d'audit.

Pattern 5 : Branchez sur des données mesurées, pas sur le jugement du modèle

Le cinquième pattern gouverne les branches conditionnelles. Un workflow multi-étapes contient des points de décision — cette ligne est-elle assez rentable pour être devisée, ce lot se déplace-t-il assez lentement pour être marqué, ce segment client débloque-t-il un palier de remise. Laisser le modèle improviser ces branches réintroduit de la variance là où le comportement déterministe compte. La réponse du workflow : des portes mesurées — les données portent les indicateurs, et la branche les lit.

Dans le moteur RFQ, chaque ligne de devis porte guardrail_price_per_uom et slow_move_item chargés depuis l'enregistrement de lot — la branche « deviser au prix catalogue » contre « marquer pour revue de marge » lit deux champs au lieu de demander au modèle d'estimer la marge. Les règles de remise se composent à partir de quatre périmètres hiérarchiques (global, segment, article, article fournisseur) comme données, pas comme étapes de raisonnement. C'est aussi là que la conception de workflow rencontre le coût : l'analyse d'inférence de Gartner avertit que « router une tâche vers un modèle de raisonnement agentique augmente les coûts d'inférence du fournisseur d'au moins cinq fois » par rapport à une interaction de base, et recommande un « tiering, routage et orchestration d'inférence hautement optimisés ». Un workflow qui branche sur des indicateurs stockés réserve le raisonnement du modèle aux étapes qui en ont besoin — jugement tarifaire, interprétation des exceptions, rédaction de négociation — et laisse les données typées décider du reste. La même discipline apparaît dans les plateformes de données, où le travail de contexte d'orchestration de Dagster traite les événements de matérialisation comme le contexte opérationnel qu'un workflow consomme plutôt que qu'il redérive.

Les cinq patterns, en une ligne chacun

Fan-out des lectures, écritures sérialisées — la forme est un invariant métier, encodez-la en guards. Les checkpoints sont des états dans lesquels le système peut rester, car la plateforme elle-même vous suspendra. La compensation est une étape de première classe pour chaque étape avant, idempotente par construction. L'état vit dans des enregistrements durables, pas dans le protocole ni le processus. Les branches lisent des indicateurs mesurés, en réservant le raisonnement du modèle aux étapes qui le payent. Aucun de ces patterns ne nécessite de migration de framework ; tous nécessitent de décider, par étape, qui le possède — le modèle, le runtime ou un humain.

Un build représentatif

Un tour-opérateur de taille intermédiaire gérant 200 RFQ de réservations de groupe par semaine entre hôtels, vols et activités a reconstruit son workflow de devis sur ces patterns. Les lectures sont fan-outées en parallèle — cinq catalogues, disponibilité par lot, paliers de prix — via un unique module MCP exposant 38 outils sur 11 mixins de domaine, le schéma de chaque outil étant typé et chaque appel audité. La colonne d'écriture se sérialise : demande confirmée, devis assemblé avec change figé au devis, réservations acquises avec un TTL de 15 minutes et libération idempotente, plans d'échéances programmés. Deux portes humaines se situent là où l'argent s'engage — confirmation de la demande et confirmation du devis — et chaque porte est un état persisté dans lequel le processus peut attendre des heures. Quand l'API d'un fournisseur expire en pleine tarification, l'erreur typée route la ligne vers une revérification au lieu de corrompre le devis. Le délai de devis est passé de trois jours de recherches manuelles à moins de quatre heures, chaque écriture étant approuvée par un humain. Le résultat, c'est une capacité de devis pour une équipe réduite, pas un remplacement d'effectifs.

Lecture associée

• Architecture des agents IA : cinq décisions qui déterminent si votre agent sort — les décisions structurelles (nombre d'agents, propriété de la boucle, routage des modèles, frontières, coordination émergente) qui cadrent quels patterns de workflow vous faut
• Loop Engineering : pourquoi le runtime de l'agent est le nouveau middleware — la mécanique runtime derrière les patterns 2 et 5 : approbations, retries et vérification par grilles appliqués dans la boucle
• Patterns d'agents longue durée : maintenir les agents en vie sur des heures et des jours — le détail de persistance et de checkpointing derrière le pattern 4, y compris le nouveau risque de suspension par garde-fou pour les exécutions prolongées

---

Une équipe capable de dessiner son workflow — le fan-out, les portes, les compensations, l'état — sait déjà quoi construire. Une équipe qui ne le peut pas découvrira le design panne fournisseur après panne fournisseur.

Demandez un build à périmètre défini. Une semaine de discovery. Vous obtenez un inventaire système, une carte des workflows et un périmètre fixe — que vous construisiez avec nous ou non.