LangGraph vs AutoGen : comparaison du suivi d'état — Checkpoint, reprise après timeout et choix de framework

30 étapes — un Agent de synthèse bibliographique, 2 heures 40 minutes d’exécution au total.

À l’étape 25, timeout de l’interface base de données, crash.

Les 24 premières étapes perdues. Coûts API, temps d’attente, résumés déjà générés — tout remis à zéro.

Ce n’est pas un cas isolé. J’ai construit des workflows complexes avec AutoGen : état incontrôlable, agents hors piste, débogage trois fois plus long que le développement. Puis passage à LangGraph : le simple prototype a exigé plus de cent lignes de définition d’état. Les deux frameworks — les deux avec leurs pièges.

LangGraph vs AutoGen en gestion d’état : des philosophies radicalement différentes. L’un contrôle le flux via une machine à états explicite, l’autre laisse les Agents négocier librement par protocole conversationnel. Choisir le mauvais framework : 80 % des échecs de projets Agent ne viennent pas d’un LLM insuffisant — c’est la piste du suivi d’état qui était fausse dès le départ.

Cet article compare les deux frameworks sur 12 dimensions — Checkpoint, reprise après timeout, support distribué — avec cas réels, arbre de décision et code exécutable. À la fin, vous devriez pouvoir trancher : pour votre projet, lequel choisir.

La ligne de vie de la gestion d’état : pourquoi Checkpoint est vital pour un Agent

J’ai développé pour un client un Agent de synthèse bibliographique : 10 appels consécutifs à des API de bases académiques, 200 résumés d’articles, rapport de synthèse.

Durée estimée : 3 heures. À l’étape 25 (sur 30), timeout de l’interface base de données, crash.

Agent traditionnel sans état — les 24 premières étapes perdues. Résumés générés, coûts API, 2 h 40 d’attente : tout remis à zéro. Relancer depuis le début, brûler à nouveau les coûts API.

Le client demande : peut-on reprendre à l’étape 25 ?

Réponse : non. L’état d’un Agent traditionnel ne vit qu’en mémoire ; à l’arrêt du processus, tout disparaît.

Les 5 catastrophes d’un Agent sans état

J’ai vécu ce piège. Avec AutoGen sur un flux de tickets SAV complexe : état incontrôlable, agents hors piste, débogage trois fois plus long. Puis LangGraph avec un graphe d’états : plus de cent lignes pour un simple prototype.

En résumé, un Agent sans état présente 5 problèmes fatals :

1. Perte de tout l’historique de conversation après redémarrage

Déploiement d’une nouvelle version, maintenance serveur, crash imprévu — toute terminaison de processus efface l’état. Une conversation en cours est coupée net.

2. Impossibilité de reprendre une tâche multi-étapes interrompue

Tâche longue (synthèse bibliographique, pipeline de données) : en cas d’échec, tout recommence. Crash à l’étape 25 sur 30 : les 24 premières étapes perdues.

3. Pas de concurrence multi-utilisateurs, états qui se mélangent

Un même Agent sert plusieurs utilisateurs : états entremêlés. L’historique de l’utilisateur A écrasé par les actions de B, pollution des données.

4. Pas d’audit ni de rejeu de l’exécution

Problème en production, envie de revoir les décisions de l’Agent ? Aucune trace. Reproduire un bug ? Aucun état historique.

5. Échec d’une tâche longue = tout à refaire

Tâches de plusieurs heures (traitement de données, génération batch) : coût d’échec énorme. Frais API, temps, expérience utilisateur — tout perdu.

LangGraph vs AutoGen : maturité des Checkpoints

L’écart entre LangGraph et AutoGen sur les Checkpoints est net.

Dimension	LangGraph	AutoGen
Support Checkpoint natif	Instantané automatique à chaque nœud	En cours sur la roadmap
Maturité production	⭐⭐⭐⭐⭐ (standard de facto 2026)	⭐⭐⭐ (encore en évolution)
Stabilité API	Écosystème LangChain stable	Migration v0.2 → v0.5, projets à réécrire

LangGraph intègre le Checkpoint dès la conception. Chaque nœud exécuté sauvegarde un instantané d’état. Après crash, reprise au point d’interruption sans réexécuter les nœuds déjà terminés.

La gestion d’état AutoGen progresse encore. En avril 2024, Microsoft publie la roadmap Persistence ; en mars 2025, Save/Load pour AgentChat.NET. Les projets en AutoGen v0.2, mis à jour en v0.5 : API invalidées, code à réécrire.

Le Checkpoint n’est pas un plus — c’est la ligne de vie d’un Agent. En production sans persistance d’état, c’est courir à découvert.

Mécanisme Checkpoint LangGraph en profondeur

L’essence du Checkpoint : pas « sauver des messages », mais « l’état complet du graphe »

Beaucoup pensent à tort que Checkpoint = « sauvegarde de l’historique de conversation ».

Ce n’est pas ça.

Un Checkpoint enregistre un instantané complet de l’état du Graph à une étape d’exécution. Il inclut :

• Les valeurs actuelles de tous les Channels (chaque champ de State)
• Le nœud en cours d’exécution
• L’ID du checkpoint parent (chaîne de versions)
• Horodatage et métadonnées

Analogie avec l’historique Git : chaque exécution de nœud produit un « commit », on peut checkout n’importe quel nœud historique. Ce n’est pas une sauvegarde de dialogue, c’est un instantané du workflow entier.

Structure Checkpoint v4 en détail

LangGraph utilise Checkpoint v4 avec 7 champs principaux, selon la documentation LangChain :

class Checkpoint:
    v: int                  # Numéro de version (actuellement 4)
    ts: str                  # Horodatage format ISO
    id: str                  # UUID, identifiant unique de l'instantané
    channel_values: dict     # Valeur actuelle de chaque champ de State
    channel_versions: dict   # Version de chaque champ, pour détection de conflits
    versions_seen: dict      # Versions vues par chaque nœud, évite le retraitement
    pending_sends: list      # File d'attente des messages à envoyer

Point clé sur channel_versions — ce n’est pas un champ inutile.

LangGraph s’en sert pour décider si un nœud doit être réexécuté. Base de la reprise : au restore, vérifier la version de chaque Channel, sauter les nœuds déjà exécutés.

thread_id : coordonnée « univers parallèle » pour l’isolation multi-session

Une même instance de Graph peut servir un nombre illimité de fils de conversation.

Chaque fil a sa propre séquence de Checkpoints, sans interférence. Distinction via thread_id.

Comme une fente de sauvegarde de jeu : chaque thread_id est un fichier de sauvegarde indépendant. L’état de l’utilisateur A n’affecte pas B.

config = {"configurable": {"thread_id": "user-001"}}
result = graph.invoke(input, config)

Changer de thread_id, c’est un autre univers parallèle.

Flux d’exécution Super-Step

Le flux d’exécution LangGraph s’appelle Super-Step. Selon la documentation LangChain :

[Lecture du Checkpoint précédent]
  ↓
[Exécution du nœud courant, mise à jour de State]
  ↓
[Écriture du nouveau Checkpoint (instantané)]
  ↓
[Décision suivante : continuer / attendre / terminer]

Chaque nœud exécuté sauvegarde automatiquement un Checkpoint. Après crash, reprise au point d’interruption.

Trois backends de stockage Checkpoint comparés

Type de stockage	Cas d’usage	Caractéristiques
MemorySaver	Développement / debug	Mémoire, perdu au redémarrage
SqliteSaver	Production mono-instance	Persistance SQLite, léger
PostgresSaver	Production distribuée	PostgreSQL, pause/resume, distribué

En dev : MemorySaver pour le debug. En prod : PostgresSaver, adapté au déploiement distribué.

RedisSaver convient aux scénarios haute concurrence, lectures/écritures rapides.

Reprise après interruption en pratique

Retour au cas initial : Agent bibliographique en 30 étapes, échec timeout à l’étape 25.

Avec le Checkpointer LangGraph, reprise au point d’interruption :

# Reprise après échec à l'étape 7
config = {"configurable": {"thread_id": "research-001"}}
recovered_state = compiled_graph.invoke({"step": 7}, config)
# Saute automatiquement les 6 premières étapes, reprend à la 7

Même thread_id, chargement du Checkpoint le plus récent, exécution continue.

Les 24 premières étapes ne sont pas réexécutées. Coûts API et contenu généré conservés.

État du suivi AutoGen : le prix de l’évolution de la roadmap

Historique de la roadmap gestion d’état

La gestion d’état AutoGen est encore en évolution.

Selon GitHub Issue #2358, Microsoft publie en avril 2024 la roadmap Persistence and state management. La migration API v0.2 → v0.5 force les projets à repartir de zéro.

J’ai vécu ce piège. Projet en AutoGen v0.2, upgrade v0.5 : API invalidées. ConversableAgent, GroupChat — interfaces changées. Code réécrit.

En mars 2025, PR Save/Load for AgentChat.NET (#5841). Agents et teams AgentChat peuvent revenir à des snapshots (Issue #4100). Sérialisation d’état SingleThreadedAgentRuntime documentée (Issue #4108).

Les capacités existent, mais la maturité reste inférieure à LangGraph.

Conditions de terminaison : quatre disjoncteurs

Douleur AutoGen : deux Agents débattent 50 tours sur « guillemet simple ou double », $5 d’API brûlés.

Ou tâche nocturne qui tourne 8 h sans terminer, facture explosive le lendemain.

AutoGen v0.4 : architecture événementielle, boucle d’écoute permanente. Sans terminaison, trou noir de ressources.

Selon la doc AutoGen, quatre types de conditions :

Type de terminaison	Dimension	Cas d’usage
MaxMessageTermination	Contrôle des tours	Limiter à 10 messages max
TextMentionTermination	Contrôle du contenu	Détecter le mot-clé TERMINATE
TimeoutTermination	Contrôle temporel	Éviter les connexions longues
TokenUsageTermination	Contrôle des coûts	Éviter dépassement de budget

Combinaison :

from autogen_agentchat.conditions import (
    MaxMessageTermination,
    TimeoutTermination,
    TokenUsageTermination
)

# Conditions combinées
termination = (
    MaxMessageTermination(max_messages=20)
    | TimeoutTermination(timeout_seconds=3600)
    | TokenUsageTermination(max_tokens=10000)
)

Dès qu’une condition est atteinte, la conversation s’arrête. Disjoncteur contre les boucles infinies.

Protocole conversationnel vs machine à états : implicite vs explicite

Les philosophies AutoGen et LangGraph divergent totalement.

AutoGen : protocole conversationnel (Conversational Programming) :

• ConversableAgent : classe de base d’agent dialoguable
• GroupChat : plusieurs Agents dans un groupe
• GroupChatManager : qui parle ensuite (tour à tour, sélection auto, stratégie custom)

L’Agent est une entité qui discute, collaboration en langage naturel. État implicite dans le flux de dialogue, moins explicite que LangGraph.

LangGraph : machine à états (State Machine) :

• State TypedDict : structure d’état explicite
• Node : logique de chaque nœud
• Edge : connexions et branches conditionnelles

À chaque étape : comment l’état change, où aller ensuite — tout est explicite.

AutoGen : flux de dialogue flexible — prochain locuteur incertain, négociation libre.

LangGraph : contrôle précis — branches conditionnelles claires, chemins prévisibles.

Capacité de sérialisation Checkpoint (AgentChat.NET)

Le Checkpoint AutoGen passe par la sérialisation.

Selon GitHub PR #5841, AgentChat.NET supporte save/load d’état :

# Sauvegarder l'état dans un fichier
team.save_state("checkpoint.json")

# Restaurer depuis un fichier
team.load_state("checkpoint.json")

Sérialisation fichier, pas persistance base de données. Adapté au mono-instance ; déploiement distribué nécessite un adaptateur.

Observabilité : OpenTelemetry — Logs, Metrics, Traces. Monitoring du flux d’événements + Replay pour le debug.

Comparaison centrale et choix technique : tableau quantitatif sur 12 dimensions

Choisir un framework, c’est comme choisir un partenaire — pas le « meilleur », le « plus adapté ».

LangGraph et AutoGen incarnent deux voies : orchestration workflow priorité machine à états, collaboration multi-rôles priorité dialogue.

Tableau comparatif sur 12 dimensions

Dimension	LangGraph	AutoGen	Écart
Modèle de gestion d’état	State TypedDict explicite	Flux de dialogue implicite	LangGraph +2
Mécanisme Checkpoint	Natif, sauvegarde auto à chaque nœud	Roadmap, sérialisation	LangGraph +3
Capacité de reprise	Reprise niveau Super-Step	Rollback dialogue (en développement)	LangGraph +2
Contrôle de terminaison	Arêtes conditionnelles	Classe TerminationCondition	Égalité
Support de persistance	Memory/SQLite/Postgres/Redis	Sérialisation fichier	LangGraph +2
Time travel	Rollback historique arbitraire	Replay	LangGraph +1
Human-in-the-Loop	interrupt() + Command(resume=)	UserProxyAgent	LangGraph +1
Support distribué	PostgresSaver natif	Architecture événementielle	LangGraph +1
Flexibilité de dev	Contrôle fin, State+Edge à définir	Dialogue, prototype rapide	AutoGen +1
Courbe d’apprentissage	Élevée, graphe d’états	Moyenne, mode dialogue	AutoGen +1
Stabilité API	Écosystème LangChain stable	Migration v0.2 → v0.5	LangGraph +2
Maturité production	⭐⭐⭐⭐⭐	⭐⭐⭐	LangGraph +2

Bilan : LangGraph en avance sur la gestion d’état (+14 points), AutoGen sur la flexibilité conversationnelle (+2 points).

Ce n’est pas « LangGraph est meilleur » — c’est « LangGraph convient mieux quand il faut un contrôle d’état précis ». AutoGen quand il faut une collaboration dialogue flexible.

Arbre de décision par cas d’usage

Comment choisir ? Selon vos besoins.

Analyse des besoins
  ↓
Flux avec branches conditionnelles explicites ?
  ├─ Oui → LangGraph
  └─ Non → Négociation libre multi-agents ?
      ├─ Oui → AutoGen
      └─ Non → Tolérance aux pannes sur tâche longue ?
          ├─ Oui → LangGraph
          └─ Non → Prototype rapide ?
              ├─ Oui → AutoGen
              └─ Non → LangGraph par défaut (production)

Scénarios où LangGraph excelle

LangGraph convient à :

1. Workflows complexes à branches conditionnelles

Tickets SAV : type de problème → chemins différents → synthèse. Branches claires, Conditional Edge LangGraph pour un contrôle précis.

2. Tâches longues nécessitant un contrôle d’état fin

Agent bibliographique : 10 appels base de données, 200 articles, synthèse. ~3 h d’exécution, reprise Checkpoint si crash. Reprise Super-Step sans réexécuter les nœuds terminés.

3. Human-in-the-Loop en production

Revue de contrats, e-mails sensibles — pause après brouillon, attente validation humaine. interrupt() + Command(resume=) pour pause/reprise élégante.

4. Débogage time-travel

Reproduction de bug, tests A/B — rollback vers n’importe quelle version, exploration de branches. Séquence Checkpoint checkoutable à tout nœud.

5. Systèmes Agent haute concurrence distribués

Support client : multi-instances, état partagé. PostgresSaver natif distribué, sans conflit d’état.

Scénarios où AutoGen excelle

AutoGen convient à :

1. Négociation libre multi-agents

Jeu de rôle, débat — prochain locuteur incertain, négociation libre. GroupChat avec stratégie de sélection auto.

2. Prototype rapide

PoC — montage rapide sans State+Edge. Piloté par le dialogue, prise en main rapide.

3. Collaboration type jeu de rôle

Rédaction + design + ops — rôles différents, simulation d’équipe réelle.

4. Boucle génération + exécution de code

Code Executor + UserProxyAgent — générer, exécuter, feedback, corriger. Boucle native AutoGen.

5. Flux de dialogue flexible

Étape suivante incertaine — GroupChatManager choisit le locuteur, sans flux prédéfini.

Exemples de code : même besoin, deux implémentations

Même besoin, deux frameworks — comparaison concrète.

Définition du besoin : Agent bibliographique long

Description de la tâche :

• 10 appels consécutifs à des API de bases académiques
• 200 résumés d’articles
• Rapport de synthèse

Durée d’exécution : ~3 heures

Tolérance aux pannes :

• Timeout interface base à l’étape 7
• Reprise Checkpoint sans répéter les 6 premières étapes

Human-in-the-Loop :

• Pause après brouillon
• Rapport final après validation humaine

Implémentation LangGraph

from langgraph.checkpoint.sqlite import SqliteSaver
from langgraph.graph import StateGraph, END
from typing import TypedDict, Annotated
from operator import add

# Définition de la structure State
class ResearchState(TypedDict):
    papers: Annotated[list, add]  # Accumulation, pas d'écrasement
    summaries: Annotated[list, add]
    draft: str
    final_report: str
    step: int
    human_approved: bool

# Fonctions de nœuds
def fetch_papers(state: ResearchState):
    """Appel API base académique"""
    step = state["step"]
    papers = call_database_api(step)  # Appel API fictif
    return {"papers": papers, "step": step + 1}

def summarize_papers(state: ResearchState):
    """Génération de résumés"""
    papers = state["papers"]
    summaries = generate_summaries(papers)  # Génération fictive
    return {"summaries": summaries}

def generate_draft(state: ResearchState):
    """Génération du brouillon"""
    summaries = state["summaries"]
    draft = generate_report(summaries)  # Génération fictive
    return {"draft": draft}

def human_review(state: ResearchState):
    """Nœud de revue humaine (attente resume après interrupt)"""
    return {"human_approved": True}

def generate_final(state: ResearchState):
    """Génération du rapport final"""
    draft = state["draft"]
    final_report = refine_report(draft)
    return {"final_report": final_report}

# Construction du Graph
graph = StateGraph(ResearchState)

# Ajout des nœuds
graph.add_node("fetch", fetch_papers)
graph.add_node("summarize", summarize_papers)
graph.add_node("draft", generate_draft)
graph.add_node("review", human_review)
graph.add_node("final", generate_final)

# Définition des arêtes
graph.add_edge("fetch", "summarize")
graph.add_edge("summarize", "draft")
graph.add_edge("draft", "review")
graph.add_edge("review", "final")
graph.add_edge("final", END)

# Point d'entrée
graph.set_entry_point("fetch")

# Checkpointer (cœur)
checkpointer = SqliteSaver.from_conn_string("research_checkpoints.db")
compiled_graph = graph.compile(
    checkpointer=checkpointer,
    interrupt_before=["review"]  # Pause avant le nœud review
)

# Exécution
config = {"configurable": {"thread_id": "research-session-001"}}
result = compiled_graph.invoke({"step": 0}, config)

# Reprise après échec à l'étape 7
# Même thread_id, saute automatiquement les 6 premières étapes
recovered_state = compiled_graph.invoke({"step": 7}, config)

# Reprise Human-in-the-Loop
# Pause après brouillon, reprise après validation humaine
compiled_graph.invoke(
    Command(resume={"human_approved": True}),
    config
)

Points clés :

• SqliteSaver sauvegarde automatiquement State après chaque nœud
• thread_id isole les sessions
• Reprise : saut des nœuds déjà exécutés (via channel_versions)
• interrupt_before pour pause Human-in-the-Loop

Implémentation AutoGen

from autogen_agentchat.agents import AssistantAgent
from autogen_agentchat.teams import RoundRobinGroupChat
from autogen_agentchat.conditions import (
    MaxMessageTermination,
    TimeoutTermination,
    TokenUsageTermination
)
from autogen_core.models import ChatCompletionClient

# Définition des Agents
research_agent = AssistantAgent(
    name="researcher",
    model_client=ChatCompletionClient(model="gpt-4"),
    system_message="Tu es un assistant de synthèse bibliographique.\
        Appels base de données, résumés, rapport.\
        Dis 'TERMINATE' une fois terminé."
)

human_agent = AssistantAgent(
    name="human_reviewer",
    model_client=ChatCompletionClient(model="gpt-4"),
    system_message="Tu es relecteur. Après revue du brouillon, dis 'APPROVED' ou 'REJECT'."
)

# Conditions de terminaison (anti-boucle infinie)
termination = (
    MaxMessageTermination(max_messages=50)
    | TimeoutTermination(timeout_seconds=10800)  # 3 heures
    | TokenUsageTermination(max_tokens=50000)
    | TextMentionTermination(text="TERMINATE")
)

# Construction de la Team
team = RoundRobinGroupChat(
    participants=[research_agent, human_agent],
    termination_condition=termination
)

# Exécution
async def run_research():
    result = await team.run(
        task="Synthétiser 200 résumés d'articles, produire un rapport"
    )
    return result

# Sauvegarde Checkpoint (AgentChat.NET)
team.save_state("research_checkpoint.json")

# Restauration Checkpoint
team.load_state("research_checkpoint.json")

# Reprise
async def resume_research():
    result = await team.run()
    return result

Points clés :

• TerminationCondition contre boucles infinies (disjoncteur)
• Save/Load état en fichier (sérialisation)
• Architecture événementielle adaptée au distribué
• Protocole conversationnel : collaboration en langage naturel

Synthèse comparative

Caractéristique	LangGraph	AutoGen
Définition d’état	TypedDict explicite	Flux de dialogue implicite
Checkpoint	Sauvegarde auto nœud (base de données)	Sérialisation fichier
Mécanisme de reprise	Super-Step, saut des nœuds exécutés	Rollback dialogue
Human-in-the-Loop	interrupt + resume	UserProxyAgent
Contrôle de terminaison	Arêtes conditionnelles	TerminationCondition
Volume de code	~60 lignes (State+Edge)	~30 lignes (dialogue)

LangGraph : contrôle fin, gestion d’état précise.

AutoGen : prototype rapide, collaboration dialogue flexible.

Recommandations de déploiement production : du dev à la prod

Points clés déploiement LangGraph

Schéma de persistance :

PostgresSaver + RedisSaver combinés.

PostgreSQL pour la persistance, déploiement distribué natif. Redis en cache, lectures/écritures rapides en haute concurrence.

from langgraph.checkpoint.postgres import PostgresSaver
from langgraph.checkpoint.redis import RedisSaver

# Configuration production
postgres_saver = PostgresSaver.from_conn_string(
    "postgresql://user:pass@host:5432/db"
)
redis_saver = RedisSaver.from_conn_string(
    "redis://host:6379/0"
)

# Combinaison : cache Redis + persistance Postgres
compiled_graph = graph.compile(
    checkpointer=postgres_saver
)

Observabilité :

LangSmith tracing + intégration OpenTelemetry.

LangSmith pour la chaîne d’appels — nœud lent, consommation de tokens. OpenTelemetry pour l’existant monitoring.

Optimisation performance :

Sortie stream — premier token immédiat, latence perçue < 1 s.

Appels Tool parallèles — support natif LangGraph.

Précompilation Prompt — ~30 % de temps d’inférence en moins.

Optimisation des coûts :

Stratégie	Réduction	Cas d’usage
Compression Prompt	30-50 %	Général
Routage multi-fournisseur	40-60 %	Failover production
Mécanisme Cache	50-80 %	Requêtes répétées

Routage multi-fournisseur : standard production. API Gateway failover : GPT-4 tombe → bascule Claude, -40 % de coûts.

Points clés déploiement AutoGen

Observabilité :

OpenTelemetry — Logs, Metrics, Traces.

• EventLogger + logs structurés : localisation, audit
• OpenTelemetry Meter : monitoring, capacity planning
• OpenTelemetry Tracer : chaîne d’appels, optimisation latence

from autogen_core.telemetry import (
    enable_telemetry,
    EventLogger
)

# Activation observabilité
enable_telemetry(
    logger=EventLogger(),
    meter=OpenTelemetryMeter(),
    tracer=OpenTelemetryTracer()
)

Monitoring flux d’événements :

Replay — tous les comportements Agent produisent un flux d’événements rejouable.

Adaptation distribuée :

Architecture événementielle native distribuée. Messages inter-agents par événements, sans conflit d’état.

Contrôle des coûts :

TokenUsageTermination — arrêt automatique au plafond budget.

from autogen_agentchat.conditions import TokenUsageTermination

# Disjoncteur coût
termination = TokenUsageTermination(max_tokens=10000)

Logs structurés pour analyser la consommation — dialogues coûteux, Agents onéreux.

Tableau comparatif déploiement production

Dimension	LangGraph	AutoGen
Persistance	PostgresSaver distribué	Sérialisation fichier (adaptation requise)
Observabilité	LangSmith tracing	OpenTelemetry trois piliers
Contrôle des coûts	Routage multi-fournisseur	TokenUsageTermination
Optimisation perf	Stream + Tool parallèles	Monitoring flux d’événements
Distribué	PostgresSaver natif	Adaptation événementielle

Leçon centrale : AI Gateway obligatoire en production

Quel que soit le framework, ajoutez un AI Gateway en production.

Pourquoi ?

1. Failover multi-fournisseur

Bascule automatique si l’API tombe. GPT-4 en panne ? Passage à Claude. Point de défaillance unique éliminé.

2. Monitoring des coûts

Quel Agent consomme, quel dialogue coûte — suivi temps réel. Arrêt auto si budget dépassé.

3. Rate limiting

Éviter la limitation API. File d’attente, retry automatique.

4. Traçage des logs

Tous les appels centralisés. Localisation, audit.

L’AI Gateway n’est pas optionnel — c’est le prérequis d’un Agent production.

Conclusion

LangGraph et AutoGen incarnent deux voies techniques pour les frameworks Agent.

LangGraph : orchestration workflow priorité machine à états. State+Node+Edge explicites, chaque étape contrôlée. Checkpoint natif, reprise sans réexécution. Idéal pour branches conditionnelles, tâches longues, déploiement distribué.

AutoGen : collaboration multi-rôles priorité dialogue. Agents négocient en langage naturel, flux flexible. Conditions de terminaison contre boucles infinies. Idéal pour prototype rapide, négociation multi-agents, scénarios type jeu de rôle.

Le choix n’est pas « lequel est meilleur », mais « lequel convient à votre scénario ».

Branches conditionnelles explicites ? LangGraph. Négociation libre multi-agents ? AutoGen. Tâche longue avec tolérance aux pannes ? LangGraph. Validation rapide de prototype ? AutoGen.

J’ai vécu les pièges des deux. AutoGen : état incontrôlable, migration API, code réécrit. LangGraph : plus de cent lignes pour définir le graphe d’états.

Leçon centrale : AI Gateway obligatoire en production. Failover multi-fournisseur, monitoring des coûts, rate limiting — trois fonctions minimales pour un Agent stable.

Prochaine étape : workflow complexe → LangGraph. Prototype multi-agents rapide → AutoGen. Puis lire « LangGraph gestion d’état en pratique » (série n° 39) pour approfondir le Checkpoint.