Workflows agentiques : graph vs loop (hybride gagnant)

Deux paradigmes : l’agent “qui improvise” vs le workflow “qui encadre”

Je caricature volontairement, mais ça aide à choisir.

Paradigme 1 — Agent loop (LLM-first)

Le modèle pense → agit → observe → recommence.

Le papier ReAct (Reasoning + Acting) formalise précisément cette alternance : le modèle raisonne, fait une action, observe le résultat, puis continue.¹

Avantages :

• très flexible,
• facile à prototyper,
• excellent quand vous ne connaissez pas à l’avance le chemin exact.

Limites (en prod) :

• comportement parfois imprévisible (“pourquoi il a fait ça ?”),
• risque de boucles,
• difficulté à garantir des invariants (idempotence, sécurité),
• et debugging dépendant des traces (sinon vous jouez au détective).

Paradigme 2 — Graph-first (workflow/state machine)

Le workflow impose des transitions :

• étape A → étape B,
• branche si condition,
• retry sur erreur,
• escalade si dépassement,
• fin.

Le LLM n’est plus “le pilote unique”.
Il devient un module à l’intérieur d’un système.

Avec LangGraph, cette approche s’exprime comme un graphe (StateGraph) : vous définissez un state et des nœuds qui le transforment, avec des branches, des boucles, des routes conditionnelles.²³

Avantages :

• contrôlable,
• rejouable,
• auditable,
• parfait pour des processus métier.

Limites :

• plus de design upfront,
• moins “magique” en démo,
• et vous devez être honnête : certains chemins restent incertains (donc LLM).

Pourquoi la prod adore les graphes (même quand le marketing préfère les loops)

La prod aime :

• les contrats (entrées/sorties),
• les timeouts,
• les retries,
• les DLQ,
• et les post-mortems.

La prod déteste :

• “le modèle a décidé que…”
• “ça dépend du contexte”
• “impossible à reproduire”

Un workflow graph-first vous force à être adulte.

1) Définir un état (state) = rendre le système intelligible

Dans LangGraph, le state définit souvent le schéma d’entrée/sortie du graphe, et vous pouvez utiliser des structures typées (TypedDict, Pydantic) pour le rendre clair.²

Même si vous n’utilisez pas LangGraph, l’idée reste :
l’état est votre contrat.

Exemple d’état (conceptuel) :

• input: message, canal, tenant
• artifacts: docs OCR, champs extraits, citations
• decisions: route, score de risque, escalade
• actions: outils appelés, idempotency keys, résultats
• trace: ids de corrélation

Quand ce state existe, votre agent cesse d’être un “chat qui pense”. Il devient un système.

2) Isoler les nœuds “incertains” (LLM) des nœuds “durs” (outils)

Un workflow hybride typique :

• extraction doc (LLM/OCR) → vérification (règles) → action outil (API) → notification (LLM)

Vous gardez les invariants hors du LLM :

• permissions,
• idempotence,
• contrôles métiers,
• sécurité.

3) Normaliser la gestion d’erreurs (retries, backoff, jitter)

Les agents échouent rarement “parce que le LLM est nul”. Ils échouent parce que :

• l’API downstream renvoie 429,
• un service time out,
• le réseau clignote,
• un parseur tombe sur un PDF tordu.

AWS Step Functions documente l’usage de Retry avec backoff dans les workflows.⁴

L’AWS Builders’ Library rappelle des principes très concrets sur timeouts, retries, backoff et jitter (et pourquoi les retries “sans jitter” peuvent aggraver une panne).⁵

Temporal se positionne justement comme une solution de “durable execution” pour orchestrer des processus, avec des activités qui supportent timeouts et retries.⁶

Traduction : vous ne voulez pas que votre stratégie d’erreur dépende de “ce que le LLM imagine”. Vous voulez qu’elle dépende de l’infrastructure.

LangGraph : quand “agent” devient “workflow” sans perdre la souplesse

LangGraph fournit un Graph API qui illustre comment composer des séquences, branches et boucles, tout en s’appuyant sur un state défini.²

Quelques points clés, utiles pour le design :

State comme schéma

LangGraph explique que le state peut être un TypedDict/Pydantic/dataclass, et qu’il détermine l’input/output schema par défaut.²

Ce détail a un impact énorme :

• vous forcez les nœuds à produire des sorties structurées,
• vous réduisez les “phrases floues”,
• et vous rendez les transitions testables.

Contrôle du flow (send/command)

Le Graph API mentionne des mécanismes de contrôle (ex. Send API, Command API) pour gérer routing et mises à jour d’état plus finement.²⁷

Ce n’est pas juste “joli”. C’est la différence entre :

• “l’agent improvise un chemin”
• et “le workflow autorise des chemins, mais dans un cadre”

Persistance (checkpointers) = debug, replay, audit

LangGraph documente la persistance via des checkpointers : l’idée de sauvegarder l’état du workflow pour reprendre, rejouer, ou débugger.⁸

Ça rejoint directement l’observabilité agentique : traces, replay, régressions (voir /blog/agents-ia/observabilite/observabilite-agents-traces-evals-2026).

“Loop” et “graph” ne s’opposent pas : ils se composent

Le piège est de croire que vous devez choisir un camp.

En pratique, vous composez :

• des nœuds déterministes (API calls, règles, calculs),
• des nœuds probabilistes (LLM pour interpréter, classer, rédiger),
• et un contrôle (budgets, retries, escalade).

Pattern 1 — Skeleton workflow + LLM nodes (le standard entreprise)

Workflow :

1. Ingestion (normalisation, hash, trace)
2. Extraction (LLM/OCR)
3. Validation (règles, cohérence)
4. Action (outils, idempotence)
5. Rédaction (LLM)
6. Audit log

Le LLM n’a pas besoin de décider “quoi faire ensuite” partout. Il décide dans ses zones : extraction, classification, rédaction.

Pattern 2 — Agent loop “encadré”

Vous laissez un agent loop décider d’actions… mais vous imposez :

• un budget strict,
• un allowlist d’outils,
• une validation humaine pour actions sensibles,
• et une sandbox pour l’exécution.

Le loop reste utile quand le chemin n’est pas connu, mais vous évitez le “stagiaire sans plafond”.

Pattern 3 — Graph-first + supervisor multi-agents

Vous avez un graphe d’états, et certains nœuds délèguent à des agents spécialisés (extraction doc, critic, exécution).

Ça combine :

• gouvernance du flow (graph),
• spécialisation (multi-agents),
• et arbitrage (supervisor).

LangGraph propose des patterns multi-agents supervisés.⁹

Cas concrets : où le paradigme change la vie (ou vous ruine)

Assurance : “instruction de sinistre” (le workflow est votre garde-fou)

Les assureurs vivent dans :

• des règles,
• des exceptions,
• des audits,
• et des délais.

Graph-first (ou hybride) est naturellement aligné :

• étapes explicites,
• validation de complétude,
• escalade sur risque,
• et action SI idempotente.

Un agent loop pur peut marcher… mais il devient fragile dès que :

• l’API renvoie des erreurs,
• le dossier est incomplet,
• ou le client envoie un document bizarre.

Marketing faceless : le loop est tentant, le workflow est rentable

Créer du contenu, c’est “flou” (donc LLM).
Mais publier, versionner, vérifier, et itérer, c’est “dur” (donc workflow).

Le pattern robuste :

• LLM pour idées/scripts/variantes,
• workflow pour QA, scheduling, tracking des performances.

Le graph vous évite le “on a publié 12 vidéos identiques parce que l’agent était inspiré”.

Prospection : la gouvernance n’est pas optionnelle

Un SDR automatique sans garde-fou, c’est un spammer.

Un workflow hybride impose :

• enrichment (source),
• rédaction (LLM),
• compliance (règles),
• validation (HITL ou sampling),
• envoi (outil),
• logs (audit).

Ce n’est pas glamour. C’est ce qui évite le bad buzz et les comptes suspendus.

Mini-exemple : un workflow hybride (pseudo-graph) qui tient en prod

Prenons un cas volontairement “classique” : triage d’un e-mail avec pièces jointes.

Objectif : classer la demande, extraire les champs, vérifier la complétude, puis créer un ticket.

Ce qui est flou :

• classification du mail,
• extraction quand le document est bancal,
• rédaction du message client.

Ce qui est dur :

• créer un ticket une seule fois,
• appliquer les règles d’escalade,
• gérer les timeouts/retries correctement.

Un workflow hybride ressemble à ça :

// pseudo-code : l’idée est plus importante que la syntaxe
type State = {
  inputEmail: { subject: string; body: string; attachments: string[] }
  intent?: "sinistre" | "resiliation" | "info" | "autre"
  extracted?: { contractId?: string; date?: string; amount?: number }
  missing?: string[]
  ticketId?: string
  escalate?: boolean
}
 
// Graph-first : on enchaîne des étapes explicites
// (et on peut persister l'état via un checkpointer)
START
  -> classifyIntent(LLM)
  -> extractFields(OCR + LLM)
  -> validateRules(code)
  -> branch:
       if missing -> draftEmail(LLM) -> END(escalate)
       else -> createTicket(API, idempotent) -> draftEmail(LLM) -> END(ok)

Le “truc” important est caché : la branche.

Dans un agent loop pur, la branche existe, mais elle est implicite : le modèle doit y penser, la réinventer, et ne pas se tromper quand il est fatigué (spoiler : il se trompe).

Dans un graph, vous encodez la branche comme une règle. Le LLM ne “décide” pas d’ignorer la validation : il n’en a pas le droit.

Si vous avez déjà vécu “le modèle a créé deux tickets”, vous voyez où je veux en venir.

Concevoir un state minimal (sans transformer votre agent en grenier)

Un mauvais state, c’est un fourre-tout :

• la conversation complète,
• les documents en brut,
• les logs,
• et parfois même des secrets (oui, ça arrive).

Un bon state est minimal et intentionnel.

Une heuristique simple : le state contient uniquement ce qui est nécessaire pour :

1. reprendre (si ça coupe),
2. dédupliquer (si ça retry),
3. auditer (si ça casse).

Tout le reste vit ailleurs :

• documents bruts : stockage objet (avec accès contrôlé),
• embeddings/RAG : index (vector DB),
• conversation : store dédié (si vous en avez besoin),
• traces : observabilité (OTel/LangSmith/etc).

LangGraph insiste justement sur la persistance via des checkpointers : vous checkpoint l’état du graphe, pas votre roman complet.⁸

“Durable execution” : quand votre agent doit survivre au monde réel

Votre workflow est rarement une exécution de 3 secondes.

En entreprise, il y a :

• des délais (attente de pièce manquante),
• des appels à des systèmes lents,
• des opérations asynchrones (queues),
• des incidents réseau,
• des maintenances.

Temporal se positionne précisément pour gérer ce type de processus via des workflows et des activités, avec une promesse de durabilité (“durable execution”).⁶

Et côté cloud, Step Functions documente la gestion d’erreurs (Retry/Catch) et le contrôle de flows dans des workflows.⁴

Même si vous n’utilisez pas ces outils, retenez l’idée :

• un agent “prod” n’est pas un script,
• c’est un processus qui doit continuer malgré des pannes partielles.

Si vous mettez toute la logique dans un prompt, vous n’avez pas de durabilité. Vous avez un pari.

Tests & régressions : comment éviter “ça marchait hier”

Un workflow agentique se teste comme un logiciel… mais avec une couche probabiliste.

Donc vous combinez :

1. tests d’outils (contrats, erreurs, idempotence)
2. tests de workflow (branches, retries, escalade)
3. evals sur traces (qualité des décisions LLM, stabilité)

L’observabilité agentique (traces + replay) est le pont entre “workflow” et “LLM”.
Sans replay, pas de regression testing réaliste.

OpenAI documente des approches d’“agent evals” et de “trace grading” pour industrialiser l’évaluation des exécutions d’agents.¹⁰¹¹

Vous n’avez pas besoin d’épouser l’outil. Vous devez épouser la discipline :

• capturer des exécutions,
• définir des critères,
• rejouer régulièrement,
• détecter les régressions,
• et mesurer coût/latence.

Checklist de design (le kit de survie)

Avant de choisir “loop” ou “graph”, posez-vous 10 questions :

1. Ai-je une définition claire de “done” ?
2. Quelles actions sont irréversibles ?
3. Quelles données sont non fiables (docs externes, e-mails, web) ?
4. Quels outils l’agent peut appeler (allowlist) ?
5. Quelles permissions minimales par étape/agent ?
6. Quelle stratégie d’erreur (timeouts, retries, backoff, jitter) ?⁵
7. Quelle idempotence (clés, déduplication) ?
8. Quelles traces dois-je conserver (audit, replay) ?
9. Quel budget d’exécution (tokens, tool calls, durée) ?
10. Quand escalader à un humain ?

Si vous ne répondez pas, le loop va vous punir. Si vous répondez, le graph va vous récompenser.

FAQ