Agentic Workflow : le guide complet en français

Un agentic workflow n'est pas un chatbot amélioré. Ce n'est pas non plus un pipeline Zapier avec un noeud "IA" au milieu. C'est un système où des agents IA prennent des décisions autonomes, utilisent des outils, adaptent leur stratégie en temps réel et gèrent des tâches complexes de bout en bout — sans qu'un humain ait besoin de coder chaque branchement.

Si vous êtes CTO, tech lead ou architecte dans une ETI ou un grand groupe, vous avez probablement déjà automatisé des processus avec des outils no-code. Le problème, c'est que ces workflows classiques atteignent vite leurs limites dès que la tâche demande du jugement, de l'adaptation ou une compréhension du contexte.

Les agentic workflows répondent à ce problème. Et pourtant, il n'existait aucun guide technique en français sur le sujet. C'est désormais chose faite.

Ce guide couvre les fondamentaux, les patterns de conception, le stack technique, les étapes de mise en oeuvre et les pièges à éviter pour déployer des workflows agentiques en production.

Workflow classique vs agentic workflow

Avant de plonger dans les architectures, clarifions la différence fondamentale entre un workflow classique et un workflow agentique.

Le workflow classique : un script déterministe

Un workflow classique — qu'il soit implémenté dans Zapier, Make, n8n ou Airflow — fonctionne sur un principe simple : IF/THEN. Chaque étape est prédéfinie. Chaque branchement est codé à l'avance. Le système suit un chemin linéaire (ou arborescent) sans jamais dévier.

C'est parfait pour l'automatisation simple : quand un email arrive, créer un ticket Jira. Quand une facture est validée, déclencher le paiement. Le flux est prévisible, reproductible, facile à debugger.

Le problème survient quand la tâche nécessite du jugement. Que faire quand la facture ne correspond pas exactement au bon de commande ? Quand le montant est légèrement différent ? Quand il manque une information ? Un workflow classique ne peut pas gérer ces cas sans qu'un développeur code explicitement chaque exception.

L'agentic workflow : un agent qui exécute un plan

Dans un agentic workflow, le LLM décide la prochaine étape en fonction du contexte. Il ne suit pas un script : il interprète une situation, choisit une action, observe le résultat et s'adapte.

Concrètement, un agent peut :

• Boucler sur une étape si le résultat n'est pas satisfaisant
• Demander des clarifications à un humain ou à un autre agent
• Appeler des outils (API, base de données, moteur de recherche) selon les besoins
• Abandonner un chemin et en essayer un autre si la stratégie initiale échoue
• Décomposer une tâche complexe en sous-tâches sans que cette décomposition soit prédéfinie

L'agent n'exécute pas un script. Il exécute un plan — et ce plan peut changer en cours de route.

Tableau comparatif

La bonne approche n'est pas de choisir l'un ou l'autre, mais de savoir quand utiliser quoi. Un formulaire de contact qui crée un lead dans le CRM ? Workflow classique. Un processus de qualification qui analyse le contexte du prospect, enrichit ses données et décide du routing ? Agentic workflow.

Pour aller plus loin sur l'orchestration de ces systèmes, voir notre expertise orchestration.

Les 4 patterns d'agentic workflow

Tous les agentic workflows ne se ressemblent pas. La littérature identifie quatre grands patterns, chacun adapté à un type de problème.

1. ReAct (Reasoning + Acting)

Le pattern le plus fondamental. L'agent alterne entre réflexion et action en boucle.

┌─────────────┐
│   THOUGHT   │ ← L'agent réfléchit à la situation
└──────┬──────┘
       ▼
┌─────────────┐
│   ACTION    │ ← Il choisit et exécute une action (tool call)
└──────┬──────┘
       ▼
┌─────────────┐
│ OBSERVATION │ ← Il observe le résultat
└──────┬──────┘
       ▼
   Suffisant ?
    /       \
  Oui       Non → retour à THOUGHT
   ▼
┌─────────────┐
│   ANSWER    │
└─────────────┘

Principe : L'agent raisonne sur la situation actuelle, décide d'une action, observe le résultat et recommence jusqu'à atteindre l'objectif.

Bon pour : recherche d'information, question-réponse avec outils, tool use simple. C'est le pattern que vous retrouvez quand vous utilisez Claude avec des outils ou ChatGPT avec des plugins.

Limite : sur des tâches longues (plus de 5-6 étapes), l'agent peut perdre le fil ou tourner en boucle.

2. Plan-and-Execute

L'agent sépare explicitement la planification de l'exécution.

┌─────────────────┐
│   PLAN GLOBAL   │ ← Créer un plan structuré
│ (étapes 1→N)    │
└───────┬─────────┘
        ▼
┌─────────────────┐
│  EXECUTE step i │ ← Exécuter l'étape courante
└───────┬─────────┘
        ▼
   Étape OK ?
   /        \
  Oui        Non → RE-PLAN (ajuster le plan)
   ▼                    │
  i < N ?               │
  /    \                │
Oui    Non              │
 ▼      ▼              │
next  DONE    ◄─────────┘
step

Principe : L'agent crée d'abord un plan complet, puis exécute chaque étape séquentiellement. Si une étape échoue, il peut re-planifier en ajustant le reste du plan.

Bon pour : tâches complexes multi-étapes comme l'analyse de contrat, l'audit réglementaire ou le traitement de dossiers. Les tâches où il est important d'avoir une vue d'ensemble avant de commencer.

Limite : le plan initial peut être sous-optimal. Le coût de re-planification peut être élevé si chaque échec déclenche une nouvelle passe LLM.

3. Reflection / Self-Critique

L'agent génère une réponse, puis s'évalue et itère pour l'améliorer.

┌──────────────┐
│   GENERATE   │ ← Produire une première version
└──────┬───────┘
       ▼
┌──────────────┐
│   EVALUATE   │ ← S'auto-évaluer (critères définis)
└──────┬───────┘
       ▼
   Qualité OK ?
   /        \
  Oui        Non → REFINE (améliorer)
   ▼                   │
┌──────────────┐       │
│   OUTPUT     │  ◄────┘
└──────────────┘

Principe : au lieu de produire un résultat en une passe, l'agent génère une version initiale, l'évalue selon des critères explicites (complétude, exactitude, style) et itère. C'est l'équivalent de la relecture humaine.

Bon pour : génération de contenu, code generation, analyse qualité, rédaction de rapports. Toute tâche où la qualité du premier jet est rarement suffisante.

Limite : chaque itération consomme des tokens. Il faut définir un critère d'arrêt clair (nombre max d'itérations ou seuil de qualité).

4. Multi-agent delegation

Un agent superviseur décompose la tâche et la distribue à des agents spécialisés.

┌───────────────────┐
│    SUPERVISOR     │ ← Décompose et distribue
└─┬──────┬──────┬───┘
  ▼      ▼      ▼
┌────┐ ┌────┐ ┌────┐
│ A1 │ │ A2 │ │ A3 │  ← Agents spécialisés
│OCR │ │ERP │ │ANA │    (exécutent en parallèle)
└──┬─┘ └──┬─┘ └──┬─┘
   ▼      ▼      ▼
┌───────────────────┐
│    SUPERVISOR     │ ← Agrège et décide
│   (agrégation)    │
└───────────────────┘

Principe : un superviseur orchestre des agents spécialisés. Chaque agent a son propre rôle, ses propres outils et sa propre expertise. Le superviseur décompose la tâche, distribue les sous-tâches et agrège les résultats.

Bon pour : workflows enterprise complexes où plusieurs domaines d'expertise sont nécessaires. Par exemple : un agent lit la facture, un autre vérifie le bon de commande, un troisième met à jour l'ERP.

Limite : la coordination entre agents est le point critique. Les erreurs de communication se multiplient avec le nombre d'agents. Commencez avec 2-3 agents max.

Pour approfondir l'architecture multi-agent, consultez notre expertise agents IA.

Stack technique pour les agentic workflows

Le choix du framework est déterminant. Voici les options principales en 2025-2026, avec un regard honnête sur leurs forces et limites.

LangGraph — le standard pour la production

LangGraph est le framework que nous recommandons chez Origin 137 pour les déploiements en production. C'est une extension de LangChain qui modélise les workflows comme des graphes d'état avec des cycles.

Pourquoi LangGraph ?

• Graphes d'état : chaque noeud est une étape, chaque arête est une transition. L'état est typé et partagé entre les noeuds.
• Cycles natifs : contrairement à un DAG (Airflow), LangGraph supporte les boucles. Indispensable pour les patterns ReAct et Reflection.
• Human-in-the-loop : pause native du workflow pour intervention humaine, avec reprise.
• Persistance : l'état du workflow est sauvegardé à chaque étape. Si le process crash, il reprend où il en était.
• Streaming : les résultats intermédiaires sont streamés en temps réel.

Voici un exemple simplifié d'un agent ReAct en LangGraph :

from langgraph.graph import StateGraph, END

def reason(state):
    # Le LLM analyse la situation et décide
    response = llm.invoke(state["messages"])
    return {"messages": [response]}

def act(state):
    # Exécuter le tool call décidé par le LLM
    tool_result = execute_tool(state["messages"][-1].tool_calls)
    return {"messages": [tool_result]}

def should_continue(state):
    last = state["messages"][-1]
    return "act" if last.tool_calls else END

graph = StateGraph(AgentState)
graph.add_node("reason", reason)
graph.add_node("act", act)
graph.add_edge("act", "reason")          # après action → réfléchir
graph.add_conditional_edges("reason", should_continue)
graph.set_entry_point("reason")

agent = graph.compile()

En 15 lignes, vous avez un agent ReAct fonctionnel avec boucle, tool use et condition d'arrêt. C'est cette concision qui fait la force de LangGraph.

CrewAI — le prototypage rapide

CrewAI adopte une approche role-based : vous définissez des "agents" avec un rôle, un objectif et des outils, puis vous les organisez en "crew" (équipe).

Forces : syntaxe intuitive, idéal pour prototyper un workflow multi-agent en quelques heures. La courbe d'apprentissage est faible.

Limites : moins de contrôle sur le flow d'exécution, persistance limitée, difficulté à implémenter des patterns complexes (human-in-the-loop conditionnel, branching dynamique). En production, on atteint vite les limites du framework.

Notre recommandation : utilisez CrewAI pour valider un concept en quelques jours, puis migrez vers LangGraph pour la production.

Temporal / Inngest — l'orchestration durable

LangGraph gère la logique de l'agent. Mais qu'en est-il des étapes qui prennent du temps ? Un appel API qui timeout, un process d'approbation humaine qui prend 3 jours, un batch de traitement qui dure des heures.

C'est là qu'interviennent Temporal et Inngest : des moteurs d'orchestration durable qui gèrent les retries, les compensations, la persistance d'état longue durée et la reprise après crash.

L'architecture idéale combine les deux : LangGraph pour la logique agentique (décisions LLM, tool use, boucles) et Temporal/Inngest pour l'orchestration durable (retries, timeouts, état persistant sur des jours).

MCP (Model Context Protocol) — le standard de connexion aux outils

Un agent sans outils ne sert à rien. Le Model Context Protocol (MCP) est le standard ouvert (initié par Anthropic) pour connecter les agents IA aux systèmes d'information : CRM, ERP, bases de données, APIs internes.

MCP définit une interface uniforme pour exposer des outils à un agent. Au lieu de coder une intégration custom pour chaque système, vous exposez vos outils via des serveurs MCP et n'importe quel agent compatible peut les utiliser.

C'est la couche qui transforme un agent conversationnel en agent opérationnel. Pour un guide détaillé, consultez notre guide MCP en entreprise.

Mastra — l'option TypeScript

Si votre stack est JavaScript/TypeScript, Mastra est une alternative crédible. Il fournit des primitives d'orchestration (workflows, agents, outils) nativement en TypeScript, avec un bon support des patterns agentiques.

Tableau comparatif

Construire un agentic workflow en 5 étapes

Passons à la pratique. Voici la méthodologie que nous appliquons chez Origin 137 pour construire des workflows agentiques en production.

Étape 1 : Définir l'objectif et les contraintes

L'erreur la plus fréquente : partir de la technologie au lieu du problème. "On veut utiliser des agents IA" n'est pas un objectif. "Réduire le temps de traitement des factures fournisseurs de 80%" en est un.

Définissez clairement :

• L'objectif mesurable : quel KPI améliorer, de combien ?
• Le périmètre : quelles tâches l'agent gère, quelles tâches restent humaines ?
• Les contraintes : budget tokens, latence max, taux d'erreur acceptable, exigences réglementaires
• Le fallback : que se passe-t-il quand l'agent ne sait pas ? Escalade humaine.

Étape 2 : Identifier et exposer les outils

Un agent est aussi bon que les outils auxquels il a accès. Inventoriez les systèmes que l'agent devra utiliser :

• APIs internes et externes
• Bases de données
• Services métier (ERP, CRM, GED)
• Sources de données (fichiers, emails, documents)

Exposez-les via MCP pour une interface standardisée. Chaque outil doit avoir une description claire (l'agent l'utilise pour décider quand l'appeler), des paramètres typés et une gestion d'erreur robuste.

Étape 3 : Choisir le pattern

Utilisez l'arbre de décision suivant :

• Tâche simple avec tool use → ReAct
• Tâche complexe multi-étapes → Plan-and-Execute
• Tâche créative ou qualitative → Reflection
• Workflow enterprise multi-domaines → Multi-agent delegation
• Combinaison → les patterns se composent (un superviseur multi-agent dont chaque agent utilise ReAct)

Étape 4 : Implémenter avec LangGraph

Le modèle mental est simple :

• Nodes = étapes du workflow (fonctions Python)
• Edges = transitions entre étapes (conditionnelles ou fixes)
• State = contexte partagé entre tous les noeuds (typé avec TypedDict ou Pydantic)

Commencez par le chemin nominal (happy path), puis ajoutez les branchements d'erreur et les boucles. Testez chaque noeud individuellement avant d'assembler le graphe complet.

Étape 5 : Ajouter les guardrails

Un agent sans guardrails est une bombe à retardement. Avant le go-live, implémentez :

• Budget tokens : limite par exécution et par étape. Un agent qui boucle sans limite peut consommer des centaines d'euros en quelques minutes.
• Timeout : durée max par exécution. Au-delà, escalade automatique.
• Fallback humain : human-in-the-loop pour les décisions critiques ou quand la confiance de l'agent est basse.
• Validation des outputs : vérifiez que la sortie de l'agent respecte un schéma attendu (JSON Schema, assertions métier).
• Rate limiting : limitez le nombre d'appels outils par exécution.

Agentic workflow en production : les 6 pièges

Construire un prototype est facile. Le déployer en production de manière fiable est une autre affaire. Voici les six pièges que nous voyons le plus souvent chez nos clients.

1. Pas de budget token

C'est le piège le plus coûteux — littéralement. Un agent qui entre dans une boucle de raisonnement infinie peut consommer des milliers de tokens par seconde. Sans limite, une seule exécution défaillante peut coûter 500 euros ou plus.

Solution : définissez un budget token par exécution ET par étape. Implémentez un circuit breaker qui arrête l'agent si le budget est dépassé.

2. Pas d'observabilité

Quand un agentic workflow produit un résultat inattendu, vous devez pouvoir retracer chaque décision de l'agent : quel prompt a été envoyé, quelle réponse reçue, quel outil appelé, avec quels paramètres, quel résultat obtenu.

Sans trace détaillée, vous ne pouvez pas debugger. Et vous ne pouvez pas améliorer.

Solution : intégrez un outil d'observabilité LLM comme LangFuse dès le premier jour. Pas après le go-live. Dès le développement. Consultez notre partenaire LangFuse pour les détails d'intégration.

3. Pas de human-in-the-loop

La tentation est grande de laisser l'agent agir en totale autonomie. Mais un agent qui prend une mauvaise décision et l'exécute sans validation peut causer des dégâts significatifs : envoyer un mauvais email à un client, modifier des données en production, déclencher un paiement incorrect.

Solution : commencez en mode supervisé. L'agent propose une action, un humain valide. Une fois que le taux de confiance est suffisant sur un type d'action, passez en mode automatique pour ce type uniquement.

4. État non persistant

Si votre agent traite un dossier en 5 étapes et que le process crash à l'étape 3, que se passe-t-il ? Sans persistance d'état, tout est perdu et il faut reprendre de zéro.

Solution : utilisez la persistance native de LangGraph (checkpointing) ou couchez votre workflow sur Temporal pour les processus longs. Chaque étape doit être idempotente : relancer l'étape 3 ne doit pas créer de doublons.

5. Trop d'autonomie trop tôt

L'erreur classique du projet qui veut montrer des résultats rapides : donner à l'agent un scope large et une autonomie totale dès le départ. Le résultat est rarement probant.

Solution : adoptez une approche incrémentale. Commencez par un périmètre étroit (un seul type de tâche) avec une supervision forte. Élargissez le périmètre et réduisez la supervision au fur et à mesure que la confiance se construit. C'est moins spectaculaire, mais c'est ce qui fonctionne.

6. Pas de tests adaptés

Les agentic workflows sont non-déterministes. Le même input peut produire des outputs différents à chaque exécution. Les tests unitaires classiques ne fonctionnent pas.

Solution : remplacez les tests unitaires par des évaluations (evals). Définissez un dataset de cas de test avec des critères de succès (pas des outputs exacts, mais des propriétés attendues). Mesurez le taux de succès sur un corpus représentatif. Automatisez ces evals dans votre CI/CD.

3 cas d'usage en entreprise

La théorie, c'est bien. La pratique, c'est mieux. Voici trois cas d'usage concrets où les agentic workflows transforment des processus métier.

Traitement de factures fournisseurs

Le problème : une ETI reçoit 2 000 factures fournisseurs par mois. Le traitement manuel (saisie, rapprochement, validation) mobilise 3 ETP et prend en moyenne 4 jours par facture.

Le workflow agentique :

1. L'agent reçoit la facture (PDF, email, scan)
2. Il extrait les informations clés via OCR et LLM (fournisseur, montant, lignes, dates)
3. Il recherche le bon de commande correspondant dans l'ERP
4. Il rapproche les lignes de la facture avec le bon de commande
5. Il identifie les écarts (montant, quantité, références)
6. Si tout est conforme : il crée l'écriture comptable et soumet pour validation
7. Si anomalie : il flag le dossier avec un rapport d'écart et escalade à un humain

Résultat : 85% des factures sont traitées automatiquement de bout en bout. 15% sont escaladées avec un rapport d'anomalie détaillé. Le temps de traitement moyen passe de 4 jours à 2 heures.

Découvrez d'autres cas d'usage concrets.

Qualification de leads entrants

Le problème : les leads entrants (formulaire web, demande de contact) sont traités manuellement par les commerciaux. Le temps de réponse moyen est de 48h, et beaucoup de leads froids sont traités avec le même effort que les leads chauds.

Le workflow agentique :

1. L'agent reçoit le lead (formulaire, email, chat)
2. Il analyse le contenu de la demande (intention, urgence, budget estimé)
3. Il enrichit le profil via APIs externes (LinkedIn, Pappers, données entreprise)
4. Il score le lead selon des critères définis (taille entreprise, secteur, intent, budget)
5. Il route le lead vers le bon commercial selon le scoring et la spécialisation
6. Il génère un brief de premier appel avec le contexte enrichi

Résultat : temps de réponse réduit à 15 minutes pour les leads chauds. Taux de conversion en rendez-vous multiplié par 2,3 grâce au routing intelligent et au brief contextuel.

Audit de conformité documentaire

Le problème : une ETI du secteur financier doit vérifier la conformité de centaines de documents contractuels par rapport au référentiel réglementaire. L'audit manuel prend des semaines et mobilise des juristes coûteux.

Le workflow agentique :

1. L'agent ingère le document (contrat, politique interne, procédure)
2. Il extrait les clauses clés et les structure
3. Pour chaque clause, il vérifie la conformité avec le référentiel réglementaire applicable
4. Il identifie les écarts, les manques et les risques
5. Il génère un rapport de conformité structuré avec les recommandations

Résultat : un audit qui prenait 3 semaines est réalisé en 2 jours. Les juristes se concentrent sur les cas complexes flaggés par l'agent au lieu de relire l'intégralité des documents.

Pour un cas concret détaillé, consultez notre case study conformité dans le secteur financier.

Pourquoi Origin 137 pour vos agentic workflows

Origin 137 n'est pas une agence. C'est une ESN IA qui staffe des ingénieurs IA seniors directement dans vos équipes, en régie (modèle FDE — Forward-Deployed Engineers).

Concrètement, cela signifie que nos ingénieurs ne livrent pas un projet puis disparaissent. Ils intègrent votre équipe, comprennent votre contexte métier et construisent des systèmes qui tiennent dans la durée.

Ce que nos FDE apportent sur les agentic workflows

Un stack battle-tested. Nos ingénieurs déploient des agentic workflows en production chez des ETI et grands groupes depuis plus d'un an. Le stack est éprouvé : LangGraph pour la logique agentique, Temporal pour l'orchestration durable, MCP pour la connexion aux outils métier, LangFuse pour l'observabilité.

Une approche incrémentale. On ne propose pas un "grand projet IA" à 6 mois. On commence par un workflow simple sur un périmètre limité. On mesure le ROI. Si ça marche (et ça marche), on étend. Si ça ne marche pas, on a limité l'investissement.

Le transfert de compétences inclus. Nos FDE travaillent avec vos équipes, pas à la place de vos équipes. L'objectif est que votre équipe soit autonome sur la construction et la maintenance des workflows agentiques à la fin de la mission.

L'expertise end-to-end. Du cadrage métier (quel process automatiser ? quel ROI espérer ?) à la mise en production (monitoring, scaling, guardrails), en passant par l'architecture technique et le développement.

Découvrez nos modèles d'intervention :

• Forward-Deployed Engineers
• Staffing IA
• Projets IA

Prochaine étape

Besoin de déployer un agentic workflow en production ? Nos ingénieurs concoivent des systèmes agents robustes — du cadrage au go-live.

Que vous en soyez au stade de l'exploration ("est-ce que l'IA agentique est pertinente pour notre process ?") ou de l'implémentation ("on a un POC, il faut le mettre en production"), un échange de 30 minutes avec un de nos ingénieurs vous donnera une vision claire du chemin à suivre.

Prendre rendez-vous avec un ingénieur Origin 137 →