Ingénierie des agents IA en 2026 : comment choisir entre LangGraph et OpenAI Agents SDK
"Documentation OpenAI Agents SDK"
Une demo d’agent de recherche client sait déjà chercher dans la documentation, résumer les résultats et envoyer un message Lark. Le vrai problème arrive au moment de la mise en production : files d’attente, validations, reprise après échec, logs, plafonds de coûts et tests de régression manquent encore. Quand le chef de produit demande si l’équipe opérations peut l’utiliser la semaine suivante, le développeur comprend que le choix entre LangGraph et OpenAI Agents SDK ne dépend pas de la vitesse de la demo. Il dépend de sept axes d’ingénierie : persistance d’état, validation humaine, observabilité, budget de coûts, modèle de permissions, eval dataset et reprise après échec.
OpenAI Agents SDK : le choix léger en premier
OpenAI Agents SDK est un outil léger, code-first, pour construire des agents proches de l’écosystème OpenAI de modèles et d’appels d’outils.
Ses primitives clés sont les suivantes :
| Primitive | Rôle | Limite |
|---|---|---|
| Agents | Une unité composée de instructions, model, tools, MCP servers, handoffs et guardrails | Ce n’est pas un graphe d’état explicite ; l’état métier reste à concevoir |
| Handoffs | Mécanisme de transfert multi-agent, où un agent peut passer la tâche à un autre | Ce n’est pas un contrôle de workflow longue durée |
| Guardrails | Guardrails input/output qui exécutent des contrôles en parallèle et déclenchent une exception en cas de tripwire | Ce n’est pas un modèle complet de permissions, d’audit ou de conformité |
| Tracing | Traces/spans intégrés, avec processor personnalisé et contrôle des données sensibles | Ce n’est pas un système complet de monitoring, alerting, budget ou rollback |
| Tools | Prise en charge des OpenAI Hosted tools, des outils de fonctions personnalisées et des MCP servers | Les types d’outils et la portée MCP doivent être vérifiés dans la documentation actuelle |
| Sessions / HITL | La documentation officielle inclut des entrées pour sessions, human-in-the-loop et sandbox agents | Ce n’est pas du graph checkpointing, time travel ou replay à la LangGraph |
Si vous devez construire rapidement un agent léger en code, principalement basé sur les modèles et outils OpenAI, avec handoffs multi-agents, garde-fous autour des entrées/sorties, tracing SDK et complexité réduite, OpenAI Agents SDK est l’option la plus légère. Exemples typiques : support client, recherche documentaire + résumé, ou agents qui traitent les étapes en séquence.
Le coût, c’est la responsabilité. Les guardrails peuvent valider les entrées et sorties, mais les workflows d’approbation complexes, l’isolation des permissions et les logs d’audit restent à implémenter dans la couche métier. Le tracing peut se connecter à OpenTelemetry ou à un processor personnalisé, mais l’équipe doit encore brancher logs, métriques, alertes, budgets et tests de régression. Sessions et HITL couvrent une partie de la conversation et de l’intervention humaine. Si vous avez besoin d’un graphe d’état explicite, de checkpoints, de resume/replay, de time travel ou de contrôle de workflow longue durée, il faut toujours évaluer LangGraph, Temporal ou une couche d’état métier.
Les mauvais cas d’usage sont nets : branches d’état complexes, pause puis reprise après validation, processus métier à SLA fort avec retries, rollback et traçabilité obligatoire, ou workflows qui exigent du replay d’état et une orchestration longue durée.
Note sur les faits volatils : l’API OpenAI Agents SDK, les modèles par défaut, les Hosted tools, le support MCP, sessions, sandbox agents, le comportement de tracing et les prix peuvent changer. Vérifiez la documentation OpenAI Agents SDK avant intégration.
LangGraph : fort sur l’état explicite et la persistance
LangGraph est un low-level orchestration framework pour stateful agents. Il met l’accent sur durable execution, HITL, memory et time travel.
Capacités clés :
| Capacité | Rôle | Usage typique |
|---|---|---|
| Durable execution | Persiste les threads et checkpoint/state snapshots via un checkpointer | Reprendre ou rejouer depuis un checkpoint après échec |
| Human-in-the-loop | Utilise interrupt pour suspendre l’exécution et Command resume pour continuer ; permet approve/reject/edit/review des tool calls | Workflows d’approbation complexes, validation humaine d’actions sensibles |
| Memory | Fournit une comprehensive memory pour le contexte court et long terme | Conception de systèmes de mémoire d’agent |
| Time travel | Rejoue ou fork depuis des checkpoints historiques | Reproduire une exécution échouée et comparer des branches |
Mécanique de persistance
La persistance LangGraph n’est pas un simple historique de chat. Elle repose sur les threads et les checkpoints :
Thread : le fil d’exécution d’une conversation ou d’un workflow. Checkpoint : un snapshot complet de l’état à un moment donné, incluant graph state, pending tasks et pending writes. Resume/Replay : reprendre depuis un checkpoint ou rejouer un chemin d’exécution historique.
Ce modèle convient aux cas qui nécessitent pause/reprise, retry après échec et replay d’état. Par exemple : workflows d’approbation client, workflows métier multi-étapes, agents de recherche longue durée.
Human-in-the-loop(HITL)
Le HITL de LangGraph ressemble davantage à une pause/reprise dans un workflow avec état :
Interrupt : suspend l’exécution à un nœud et attend une entrée humaine. Command resume : reprend après approve, reject ou edit. Tool-call review : peut suspendre avant un appel d’outil pour obtenir une validation humaine.
Par rapport aux guardrails d’OpenAI Agents SDK, les guardrails sont plutôt des contrôles avant ou après exécution, tandis que le HITL de LangGraph suspend et reprend au milieu du workflow. Si votre flux d’approbation exige plusieurs tours, un état sauvegardé, du replay et des branches, LangGraph est souvent plus adapté.
Si vous avez besoin de branches d’état complexes, de reprise, de pauses d’approbation et de replay d’état, LangGraph est plus proche de l’orchestration production. Exemples : workflows d’approbation client, workflows métier multi-étapes, agents de recherche longue durée.
Le coût est une complexité plus élevée. Vous devez concevoir et maintenir un graphe d’état. Vous devez aussi choisir un backend de persistance, dont le support peut évoluer ; vérifiez donc la documentation actuelle avant intégration.
Les mauvais cas d’usage : tâches courtes, prototypes avec peu d’état, projets surtout dépendants de l’écosystème OpenAI sans besoin de persistance ou d’approbations complexes.
Note sur les faits volatils : LangGraph v1, Platform/Studio/Deployment et les backends de persistance pris en charge peuvent changer. Vérifiez la documentation LangGraph avant intégration.
Pour approfondir la gestion d’état avec LangGraph, consultez LangGraph en pratique : gestion d’état et LangGraph vs AutoGen : suivi d’état.
AutoGen, CrewAI et Temporal : collaboration multi-agent et durable execution
Le choix ne se résume pas à OpenAI Agents SDK contre LangGraph. Si votre priorité est la collaboration multi-rôles, le prototypage de recherche ou une couche indépendante d’infrastructure workflow, regardez aussi AutoGen, CrewAI et Temporal.
AutoGen / AG2
AutoGen est un layered framework avec Core API, AgentChat API, Extensions et Studio, conçu pour les conversations et applications collaboratives multi-agents.
Core API couvre le runtime agent de bas niveau et le routage des messages. AgentChat API fournit des abstractions de dialogue et de collaboration de plus haut niveau. Extensions intègre des outils, modèles et plateformes externes. Studio apporte une surface visuelle de construction et de debugging.
Cas adaptés : recherche et prototypes de conversations/collaborations multi-agents ; équipes déjà familières avec l’écosystème AutoGen.
À évaluer séparément : persistance d’état, reprise après échec, observabilité, permissions et déploiement. Vérifiez aussi la relation de versions AutoGen/AG2, la stabilité API et le point d’entrée de documentation dans la documentation AutoGen.
Note sur les faits volatils : les migrations AutoGen/AG2, la relation avec Microsoft Agent Framework et la stabilité API peuvent changer. Cet article traite AutoGen comme un candidat de collaboration multi-agent, pas comme une conclusion fixe sur sa roadmap de versions.
CrewAI
CrewAI organise la collaboration multi-agent autour de concepts comme crews, agents, tasks, processes et flows, avec Flows pour une orchestration plus structurée.
Concepts clés : Crews regroupe agents et tasks. Agents définit les rôles. Tasks décrit le travail concret. Processes définit le flux d’exécution. Flows offre un modèle d’orchestration multi-étapes plus structuré.
Cas adaptés : applications agent à rôles collaboratifs ; orchestration rapide et prototypes.
À évaluer séparément : modules produit, capacités hébergées, pricing, fonctionnalités enterprise. Vérifiez la documentation CrewAI avant intégration.
Note sur les faits volatils : les modules produit, capacités hébergées, pricing et fonctionnalités enterprise de CrewAI peuvent changer. Cet article ne classe pas CrewAI comme “le plus fort” ; il le place dans la catégorie collaboration multi-agent.
Temporal
Temporal n’est pas un framework d’agent. C’est une durable execution infrastructure. Il fournit workflow, activity, retry, timeout et visibility, ce qui le rend adapté aux processus métier qui doivent s’exécuter de manière fiable.
Capacités clés : Workflow définit les processus longue durée. Activity encapsule les opérations externes susceptibles d’échouer. Retry/Timeout configure les stratégies de réessai et les limites de temps. Visibility permet d’interroger et surveiller l’état d’exécution d’un workflow.
Relation avec les frameworks d’agent : un agent peut être une étape dans un workflow ou une activity Temporal. Temporal porte le processus métier fiable ; le framework d’agent porte les étapes intelligentes.
Cas adaptés : processus métier à SLA fort, où retry, rollback et traçabilité sont obligatoires ; workflows d’entreprise complexes avec queue, retry, timeout et audit.
Ce que ce n’est pas : une raison de mettre toute la logique dans un framework d’agent. Temporal + Agent SDK ou LangGraph peut être une séparation plus propre.
Note sur les faits volatils : Temporal Cloud pricing, les API SDK et les options de déploiement peuvent changer. Vérifiez la documentation Temporal avant intégration.
Matrice de sélection : différences sur les axes production
La sélection n’est pas un classement de popularité. C’est une vérification sur sept axes d’ingénierie : persistance d’état, approbation HITL, observabilité, budget de coûts, modèle de permissions, eval dataset et reprise après échec. Le tableau ci-dessous compare cinq options sur ces axes et leurs limites.
| Framework | Persistance d’état | Approbation HITL | Observabilité | Budget de coûts | Modèle de permissions | Eval dataset | Reprise après échec |
|---|---|---|---|---|---|---|---|
| OpenAI Agents SDK | Sessions peut maintenir un contexte de conversation, mais ce n’est pas du graph checkpoint ni du time travel | HITL et guardrails existent, mais les approbations complexes restent à concevoir côté métier | Tracing intégré ; logs, métriques et alertes restent à brancher | Pas de système complet intégré ; à implémenter | Guardrails n’est pas un modèle complet de permissions, d’audit ou de conformité | À implémenter | Retries, reprise et rollback restent à concevoir dans la couche métier |
| LangGraph | Checkpointer + thread + checkpoint/state snapshots, avec resume/replay | Interrupt + Command resume, avec approve/reject/edit/review des tool calls | Connexion possible à OpenTelemetry ; logs, métriques et alertes restent à brancher | Pas intégré ; à implémenter | À implémenter dans les nœuds du graph ou la couche métier | À implémenter | Resume ou replay depuis checkpoint ; patterns de retry et replay |
| AutoGen | Persistance à évaluer séparément | HITL à évaluer séparément | Intégrations d’observabilité à évaluer séparément | À évaluer séparément | À évaluer séparément | À évaluer séparément | À évaluer séparément |
| CrewAI | Persistance à évaluer séparément | HITL à évaluer séparément | Intégrations d’observabilité à évaluer séparément | À évaluer séparément | À évaluer séparément | À évaluer séparément | À évaluer séparément |
| Temporal | Workflow + activity prennent en charge l’état des workflows longue durée | Les workflows peuvent attendre une entrée humaine ; les approbations peuvent vivre dans la couche workflow | Visibility intégré ; connexion possible à OpenTelemetry | Contrôle possible au niveau workflow/activity | Vérifications possibles au niveau workflow/activity | À implémenter | Retry/timeout intégré ; adapté à l’exécution fiable et à la reprise |
Lecture clé : LangGraph et Temporal sont plus forts sur la persistance d’état, l’approbation HITL et la reprise après échec. OpenAI Agents SDK est plus léger, mais la gouvernance production complexe reste à construire. Côté observabilité, toutes les options exigent les logs, métriques et alertes de votre équipe ; OpenAI Agents SDK et LangGraph fournissent des abstractions de tracing, Temporal fournit visibility. Budgets de coûts, modèles de permissions et eval datasets restent votre responsabilité. Ne partez pas du principe qu’un framework d’agent les résout déjà. AutoGen et CrewAI conviennent à la collaboration multi-rôles et aux prototypes, mais leurs axes production doivent être évalués séparément.
Gardez aussi les limites en tête : tracing n’est pas une observabilité complète. Guardrails n’est pas un modèle complet de permissions, d’audit ou de conformité. Checkpoints et threads ne suppriment pas le besoin de queues, bases de données ou workflow engines.
Arbre de décision : de la demo qui fonctionne à la production
Si votre demo d’agent fonctionne déjà, passez par ce flux de décision avant de la mettre devant de vrais utilisateurs.
Étape 1 : juger la complexité de la tâche
Question : votre agent est-il une tâche courte avec peu d’état, ou comporte-t-il des branches et des pauses/reprises ?
Tâche courte / peu d’état : exemples, question-réponse ponctuelle, recherche documentaire + résumé, traitement de données en une fois. Commencez par OpenAI Agents SDK : léger, proche des modèles et outils OpenAI, sans gestion d’état complexe.
Branches / pause et reprise : exemples, workflow d’approbation client, workflow métier multi-étapes, agent de recherche longue durée. Passez à l’étape 2.
Étape 2 : juger l’écosystème d’outils et les besoins d’état
Question : votre agent dépend-il surtout des outils OpenAI, ou a-t-il besoin d’un graphe d’état explicite ?
Écosystème OpenAI d’abord : si vous utilisez surtout OpenAI Hosted tools, MCP servers et modèles OpenAI, commencez par OpenAI Agents SDK. Si vous avez aussi besoin d’approbations complexes ou de replay d’état, évaluez LangGraph ou une combinaison Temporal + Agents SDK.
Graphe d’état explicite nécessaire : en cas de branches complexes, reprise, pauses d’approbation et replay d’état, choisissez LangGraph. Attendez-vous à plus de complexité, car il faut concevoir et maintenir le graphe d’état.
Étape 3 : juger la gouvernance production
Question : s’agit-il d’un prototype de recherche, ou faut-il une gouvernance production ?
Prototype de recherche : pour des conversations/collaborations multi-agents, ou une équipe déjà à l’aise avec AutoGen/CrewAI, évaluez AutoGen et CrewAI. Vérifiez séparément persistance, reprise, observabilité, permissions et déploiement.
Gouvernance production : pour des processus métier à SLA fort, avec retry, rollback et traçabilité obligatoires, envisagez LangGraph + Temporal. Temporal porte le workflow métier fiable externe ; LangGraph porte le graphe d’état agent et l’orchestration LLM.
Point de décision
Quel que soit le framework choisi, ajoutez ces capacités avant le lancement :
| Capacité | Checklist |
|---|---|
| Persistance d’état | Avez-vous des checkpoints/threads ? Pouvez-vous faire resume ou replay ? |
| Approbation HITL | Avez-vous interrupt/Command resume ? Le flux d’approbation est-il complet ? |
| Observabilité | Le tracing est-il connecté aux logs, métriques et alertes de l’équipe ? |
| Budget de coûts | Avez-vous des limites de budget, un suivi des coûts et des alertes ? |
| Modèle de permissions | Avez-vous isolation des droits, audit logs et validation de conformité ? |
| Eval dataset | Avez-vous des tests de régression, eval datasets et définitions de métriques ? |
| Reprise après échec | Avez-vous retry, rollback et chemins de reprise humaine ? |
Étape suivante : si vous choisissez OpenAI Agents SDK, vous devez encore brancher logs, métriques, alertes, budgets, permissions, eval datasets et reprise après échec. Si vous choisissez LangGraph, concevez le graphe d’état, choisissez un backend de persistance, puis branchez observabilité, coûts, permissions et evals. Si vous choisissez Temporal plus un framework d’agent, définissez workflows et activities, configurez retry/timeout, puis branchez observabilité, coûts et permissions.
Étapes suivantes et lectures complémentaires
Une fois la direction du framework choisie, approfondissez axe par axe :
Articles BetterLink existants : Développement d’agent IA en pratique : guide d’architecture et d’implémentation pose les bases d’architecture agent, avec frontières de composants, tool calling et conception d’état. LangGraph en pratique : gestion d’état explique checkpoints, threads, resume/replay et reprise après échec. LangGraph vs AutoGen : suivi d’état compare les deux approches de state tracking. Monitoring, alerting et reprise après échec pour agents IA approfondit logs, alertes, recovery et reprise humaine. Conception d’un système de mémoire pour agents est la suite logique pour mémoire court/long terme et gestion du contexte.
Les prochains articles de cette série détailleront le context engineering, les workflows d’approbation HITL, la budgétisation et le contrôle des coûts, les modèles de permissions, le design de state machine, les eval datasets et tests de régression, ainsi que la checklist complète de lancement de la demo à la production.
Si vous êtes encore en phase de choix, commencez par l’arbre de décision : complexité de la tâche, écosystème d’outils et besoins d’état. Ne vous arrêtez pas à “la demo fonctionne”. Avant le lancement, vérifiez persistance d’état, approbation HITL, observabilité, budgets de coûts, modèles de permissions, eval datasets et reprise après échec.
Choisir une stack d'ingénierie pour agents IA
Une méthode de sélection pour passer d'une demo fonctionnelle à la production, en décidant le framework principal, le workflow engine externe et les briques de gouvernance manquantes.
⏱️ Estimated time: 30 min
- 1
Step 1: Déterminer si la tâche est une session courte ou un workflow long
Vérifiez si le travail se limite à une question-réponse, une recherche ou un résumé ponctuel, ou s'il traverse plusieurs étapes, validations humaines, temps d'attente et reprises. - 2
Step 2: Lister les exigences de gouvernance en production
Écrivez explicitement les besoins d'état, d'approbation, de droits d'outils, de reprise après échec, de budget, de trace/audit et d'eval dataset. - 3
Step 3: Cartographier les responsabilités de chaque framework
Associez OpenAI Agents SDK, LangGraph, AutoGen/CrewAI et Temporal aux primitives agent légères, aux graphes d'état, à la collaboration multi-rôles et aux workflows fiables. - 4
Step 4: Tester avec une vraie tâche métier
Utilisez une tâche réelle pour vérifier traces, retries, reprise humaine, isolation des droits et tests de régression, au lieu de vous arrêter à une demo hello world. - 5
Step 5: Décider le framework principal et les systèmes à compléter
Décidez quel framework d'agent porte les étapes intelligentes, quel workflow engine porte la fiabilité, et comment l'observabilité, les coûts et les permissions sont implémentés.
FAQ
LangGraph et OpenAI Agents SDK se remplacent-ils ?
Faut-il toujours LangGraph pour un agent de production ?
AutoGen et CrewAI valent-ils encore la peine d'être étudiés ?
Comment répartir les rôles entre Temporal et LangGraph ?
Qu'est-ce que les équipes oublient le plus souvent en choisissant un framework d'agent IA ?
13 min de lecture · Publié le: 11 sept. 2026 · Mis à jour le: 11 sept. 2026
Guide d'ingénierie AI Agent
Si vous arrivez depuis la recherche, le plus rapide est de passer à l’article précédent ou suivant de cette série.
Précédent
Architecture DeepAgents : outils de planification, sous-agents et système de fichiers
Analyse approfondie des quatre piliers de DeepAgents : Planning Tools, Sub-agents, File System et System Prompts, comparaison avec LangGraph, AutoGen et autres frameworks, avec exemples de code et bonnes pratiques
Partie 16 sur 22
Suivant
Context Engineering pour agents IA : séparer System Prompt, Memory, Tools et Files
Un cadre pratique pour répartir le contexte d’un agent entre system prompt, règles développeur, memory, files, retrieval, tool schema, runtime state et output contract afin d’éviter le gonflement du contexte et l’oubli des règles.
Partie 18 sur 22
Commentaires
Connectez-vous avec GitHub pour laisser un commentaire