LangGraph, CrewAI ou API directe : choisir un framework d’agents en 2026

Le paysage des frameworks d’agents en 2026 est plus mature que deux ans plus tôt et pas plus clair. LangChain/LangGraph reste dominant mais de plus en plus remis en question. CrewAI a trouvé une niche. Pydantic AI gagne des adeptes pour la sécurité des types. Les SDK Agents d’OpenAI et Claude d’Anthropic croissent. Et un mouvement silencieux d’équipes revient à l’appel direct à l’API, en particulier en production.

Chaque framework a ses partisans et ses critiques. Les débats sont bruyants. La décision est généralement personnelle plus qu’objective.

Cet article écarte le bruit pour adopter le point de vue d’un architecte en exercice : ce que fait réellement chaque framework, les situations où il convient et les schémas observés en production. Aucune guerre de chapelles, seulement des compromis.

À quoi sert un framework d’agents

Avant de comparer, précisons l’objet du choix. Un framework d’agents fournit généralement :

1. Un moyen de définir les agents — quel est leur rôle, quelles sont leurs outils, quel est leur comportement.
2. Un cycle d’exécution — appeler un LLM, analyser la sortie, décider quoi faire, appeler des outils, répéter.
3. La gestion de l’état — ce que l’agent se souvient, comment cela est organisé.
4. L’intégration d’outils — comment les outils sont définis et exposés.
5. L’orchestration — plusieurs agents travaillant ensemble, flux de travail divergents, réessais.
6. Des points d’intégration pour l’observabilité — traçage, journalisation et débogage.
7. Les utilitaires pratiques — modèles de prompt, schémas courants, assistants.

Chaque framework priorise ces éléments différemment. Certains sont lourds en orchestration ; certains se concentrent sur la définition des agents ; certains sont des couches minimales sur les API du modèle.

Le paysage

LangChain / LangGraph

Le grand. LangChain a commencé comme une bibliothèque Python pour chaîner les appels LLM ; il est devenu le framework de fait pour de nombreux projets d’IA. LangGraph est le framework spécifique aux agents construit dessus.

Ce qu’il fait bien :

• LangGraph pour les machines à états. Le modèle de graphe (nœuds pour les étapes, arêtes pour les transitions, état transmis) est bien adapté aux flux de travail d’agents complexes.
• Écosystème riche. Beaucoup d’intégrations : bases de données vectorielles, fournisseurs de modèles, outils, observabilité.
• LangSmith pour l’observabilité. Interface de traçage et de débogage mûre.
• Adoption large. Beaucoup d’exemples, beaucoup de documentation, beaucoup de personnes qui le connaissent.

Ce qu’il ne fait pas :

• Taxe d’abstraction. LangChain en particulier a de nombreuses couches d’abstraction. Le débogage est plus difficile ; comprendre ce qui se passe réellement demande un effort.
• Évolutions fréquentes de l’API. Les ruptures de compatibilité sont courantes et le code datant de 12 mois exige souvent des mises à jour.
• Surcoût de performance. Les couches d’indirection coûtent en latence et en tokens.
• Courbe d’apprentissage. Une maîtrise réelle prend des semaines.

Quand le choisir :

• Des flux de travail d’agents complexes avec des états divergents.
• Des équipes qui bénéficient d’un framework standard (beaucoup d’ingénieurs, des schémas courants).
• Lorsque vous souhaitez l’observabilité de LangSmith.

Quand l’éviter :

• Des chatbots simples ou des boucles d’agents uniques (l’appel direct à l’API est plus simple).
• Des équipes qui ont été affectées par les changements fréquents de LangChain auparavant.
• Des projets où chaque milliseconde de latence compte.

CrewAI

Un framework multi-agents axé sur les agents basés sur des rôles. Chaque agent a un rôle, un objectif, un arrière-plan ; ils collaborent sur des tâches.

Ce qu’il fait bien :

• Orchestration multi-agents. Support intégré pour les agents qui s’adressent les uns aux autres, qui délèguent, qui collaborent.
• Modèle mental basé sur les rôles. Facile à penser (“l’agent Rechercheur fait X ; l’agent Écrivain fait Y”).
• Plus simple que LangGraph pour les multi-agents. Plus rapide pour commencer.
• Communauté active.

Ce qu’il ne fait pas :

• Profondeur limitée pour un seul agent. Si votre tâche est un agent complexe unique, les abstractions de CrewAI peuvent sembler mal adaptées.
• Performance. Les configurations multi-agents multiplient les appels LLM ; le coût et la latence augmentent rapidement.
• Maturité moindre. Plus jeune que LangChain, il comporte encore certaines aspérités.
• Opinionné. Moins de flexibilité que les frameworks directs.

Quand le choisir :

• Des flux de travail multi-agents où la différenciation des rôles a du sens.
• Des cadres “Crew” (un groupe d’agents travaillant ensemble).
• Prototyper rapidement des idées multi-agents.

Quand l’éviter :

• Des tâches à un seul agent, pour lesquelles il est trop lourd.
• En production où la performance compte (les multi-agents sont coûteux).
• Des tâches où le cadre “collaboration d’agents” est plus du théâtre que de la substance.

Pydantic AI

Un framework plus récent axé sur la sécurité des types et l’expérience du développeur.

Ce qu’il fait bien :

• Typage fort. Fondé sur Pydantic, il type les entrées et sorties et détecte les erreurs pendant le développement.
• API propre. Moins d’abstraction que LangChain ; plus proche des API du modèle.
• Python moderne. Async, indices de type, Pydantic v2.
• Indépendant du modèle. Fonctionne avec la plupart des fournisseurs.

Ce qu’il ne fait pas :

• Écosystème plus petit. Moins d’intégrations que LangChain.
• Moins éprouvé à grande échelle. Plus récent ; les schémas de production émergent encore.
• Moins d’outils d’orchestration. Pas aussi riche que LangGraph pour les flux de travail complexes.

Quand le choisir :

• Des équipes Python soucieuses de la sécurité des types.
• Des configurations à un seul agent ou simples multi-agents.
• Des équipes qui préfèrent un minimum d’abstraction.

Quand l’éviter :

• Des orchestrations très complexes (LangGraph pourrait convenir mieux).
• Des projets non Python (il est uniquement en Python).
• Lorsque vous avez besoin d’un écosystème vaste d’intégrations prêtes à l’emploi.

OpenAI Agents SDK

Le framework d’agents officiel d’OpenAI, optimisé pour les modèles OpenAI.

Ce qu’il fait bien :

• Optimisé pour OpenAI. Conçu spécifiquement pour les schémas GPT-5/o3.
• API simple. Moins abstrait que LangChain.
• Transferts intégrés. Les transferts multi-agents sont de première classe.
• Traçage mûr. Observabilité intégrée liée au tableau de bord OpenAI.

Ce qu’il ne fait pas :

• Dépendance à OpenAI. Conçu pour les modèles OpenAI, il s’adapte mal aux autres fournisseurs.
• Moins de flexibilité. Certains schémas sont plus faciles dans des frameworks plus généraux.
• Plus récent que LangChain. Communauté plus petite.

Quand le choisir :

• Engagement total sur les modèles OpenAI.
• Souhait d’un chemin soutenu par le fournisseur.
• Complexité d’agent simple à modérée.

Quand l’éviter :

• Stratégie multi-fournisseurs, pour laquelle un framework généraliste ou des API directes conviennent mieux.
• Vous utilisez principalement Anthropic ou Google.

Anthropic Claude SDK

Similaire — le chemin d’Anthropic pour construire des agents avec Claude.

Ce qu’il fait bien :

• Optimisé pour Claude. Très bien adapté aux réflexions étendues de Claude, à l’utilisation informatique, à l’intégration MCP.
• Idiomatique pour les modèles Claude.
• Support fort MCP.

Ce qu’il ne fait pas :

• Verrouillage Claude. Même compromis que le SDK Agents d’OpenAI.

Quand le choisir :

• Engagement total sur Claude.
• Utilisation intensive des fonctionnalités spécifiques à Claude.

Quand l’éviter :

• Stratégie multi-fournisseurs.

Appel direct à l’API

Ignorez entièrement les frameworks : appelez directement les API OpenAI, Anthropic ou Gemini et écrivez vous-même la boucle.

Ce qu’il fait bien :

• Contrôle total. Tout aspect du système est le vôtre.
• Aucun coût d’abstraction. Ce que vous voyez correspond à ce qui s’exécute.
• Facile à déboguer. Aucune couche à creuser.
• Facile à optimiser. Aucun surcoût de framework.
• Aucun changement de version. Vous mettez à niveau quand vous le souhaitez.

Ce qu’il ne fait pas :

• Plus de code. Les schémas que le framework gère, vous les gérez.
• Réinventer. Les schémas courants sont réimplémentés par projet.
• Moins de standardisation. Les différentes équipes construisent des systèmes similaires différemment.

Quand le choisir :

• Des équipes matures déployant des systèmes de production où la fiabilité prime sur le confort.
• Des cas d’utilisation uniques qui n’ont pas besoin de la flexibilité d’un framework.
• Des chemins critiques en termes de performance.
• Après avoir prototypé avec un framework et avoir appris les schémas.

Quand l’éviter :

• Phases initiales et exploratoires d’un projet, où le framework aide à découvrir les schémas utiles.
• Des équipes avec une capacité d’ingénierie limitée.

LlamaIndex

A commencé comme une bibliothèque RAG ; a grandi vers des territoires plus larges d’agents.

Ce qu’il fait bien :

• Systèmes RAG lourds. Classe mondiale pour les agents axés sur la récupération.
• Connecteurs de données. Beaucoup d’intégrations pour les sources de données.
• Abstractions de récupération mûres.

Ce qu’il ne fait pas :

• Abstractions d’agents plus faibles. Meilleur pour RAG que pour les agents généraux.
• Quelques chevauchements avec l’écosystème LangChain.

Quand le choisir :

• Focus lourd sur la récupération / RAG.
• Besoin de nombreux connecteurs de sources de données.

Quand l’éviter :

• Travail d’agents non RAG.

Microsoft Autogen, Semantic Kernel

Les offres de Microsoft. Autogen pour les multi-agents ; Semantic Kernel pour les applications générales d’IA.

Ce qu’ils font bien :

• Intégration avec l’écosystème Microsoft. Fonctionne bien avec Azure, .NET, Microsoft 365.
• Semantic Kernel : plus enterprise que les alternatives.
• Autogen : fort pour la recherche multi-agents.

Ce qu’ils ne font pas :

• Communauté plus petite en dehors des entreprises Microsoft.
• Moins de momentum que LangChain/LangGraph.

Quand les choisir :

• Équipes Microsoft.
• Intégration lourde avec Azure.

Les dimensions à considérer

Il ne s’agit pas de désigner un gagnant, mais d’adapter les compromis à votre projet.

Dimension 1 : Complexité de l’orchestration

Quel est le degré de complexité de vos flux de travail agentiques ?

• Simple (chatbot, agent unique, flux linéaire) : appel direct à l’API ou Pydantic AI.
• Modéré (agent unique, logique divergente) : Pydantic AI, LangGraph, appel direct à l’API.
• Complexe (plusieurs agents, machines à états, réessais) : LangGraph, CrewAI ou solution personnalisée.
• Très complexe (machines à états importantes, agents parallèles, routage complexe) : LangGraph ou solution personnalisée.

Dimension 2 : Maturité de production

Quelle importance accordez-vous à la fiabilité par rapport à l’expérimentation ?

• Expérimentation / prototypage : tout framework vous aide à avancer rapidement.
• Production, orientée client : préférez les frameworks bien connus (LangChain a le plus de schémas ; l’appel direct à l’API a le plus de contrôle).
• Production, critique : l’appel direct à l’API gagne souvent ; vous comprenez chaque ligne.

Dimension 3 : Taille et compétences de l’équipe

• Petite équipe (1 à 3 ingénieurs) : privilégiez une API directe ou un framework simple afin de limiter le surcoût.
• Équipe moyenne (5-15) : un framework aide à standardiser. LangChain ou Pydantic AI.
• Grande équipe (20+) : le framework est essentiel pour les schémas partagés. LangGraph ou framework interne.

Dimension 4 : stratégie de fournisseurs

• Multi-fournisseurs : frameworks généraux (LangChain, Pydantic AI) ou appel direct à l’API.
• Un seul fournisseur : SDK fournisseur (OpenAI Agents SDK, Anthropic Claude SDK).

Dimension 5 : Sensibilité à la performance

• Critique en latence (UX en temps réel) : appel direct à l’API. Les frameworks ajoutent de la latence.
• Critique en coût (volume élevé) : appel direct à l’API. Les frameworks peuvent ajouter des tokens.
• Standard : tout framework est acceptable.

Dimension 6 : Besoins d’observabilité

• Solution complète prête à l’emploi : LangChain + LangSmith.
• Solution personnalisée : n’importe quel framework associé à votre propre couche d’observabilité.

L’évolution vers les API directes

Un schéma que nous voyons de plus en plus en 2026 : les équipes matures passent des frameworks à l’appel direct à l’API en production.

Pourquoi :

• Après un à deux ans de travail sur les agents, les équipes maîtrisent les schémas et le rôle pédagogique du framework perd de sa valeur.
• Les frameworks changent. L’appel direct à l’API ne change pas. La stabilité en production favorise l’appel direct.
• Performance : les frameworks ajoutent un surcoût. L’appel direct à l’API ne l’ajoute pas.
• Facilité de débogage : lorsqu’un problème survient, une API directe rend son déroulement évident.
• Personnalisation : chaque système de production a des exigences uniques. Les frameworks résistent à la personnalisation ; l’appel direct à l’API l’embrasse.

Ce n’est pas une condamnation des frameworks. Ils sont excellents pour l’apprentissage, le prototypage et les systèmes de production modérément complexes. Mais pour la production mûre : l’appel direct à l’API est souvent le meilleur choix.

Le schéma de migration :

1. Commencer avec LangChain ou similaire.
2. Construire les premières versions.
3. Apprendre les schémas.
4. Remarquer les points de friction (débogage, performance, personnalisation).
5. Migrer les chemins chauds vers l’appel direct à l’API.
6. Finalement, la plupart du code de production est l’appel direct à l’API.

Ce n’est pas une défaillance des frameworks ; c’est leur cycle de vie naturel pour certaines équipes.

Un cadre de décision pratique

Si vous choisissez pour un nouveau projet :

Étape 1 : Définir le projet.

• Quelle est la complexité de l’agent ?
• Combien d’ingénieurs ?
• Production ou prototype ?
• Un seul fournisseur ou plusieurs ?

Étape 2 : Appliquer des heuristiques.

Étape 3 : prototyper, puis évaluer.

Passez une semaine avec le framework choisi. Construisez une tranche représentative. Évaluez :

• S’adapte-t-il à vos schémas ?
• Combattez-vous le framework ou travaillez-vous avec lui ?
• Le débogage est-il maîtrisable ?
• La performance est-elle acceptable ?

Si oui : continuez. Si non : essayez un autre ou allez directement.

Étape 4 : Ne verrouillez pas irrévocablement.

Même dans un framework, structurez votre code de manière à ce que le changement soit possible. Isolez l’utilisation du framework à une couche mince ; construisez votre logique dans du code indépendant du framework.

Schémas communs à tous les frameworks

Quel que soit le choix de framework, certains schémas sont universels :

Séparation des responsabilités. Séparez la gestion des prompts, la logique des agents, les définitions d’outils et la boucle d’exécution. Chaque framework en prend certaines en charge ; les autres vous incombent.

Observabilité. Tracez chaque appel LLM. Tracez chaque appel d’outil. Agrégez les métriques. C’est votre travail, indépendamment du framework.

Budgets de pas et sorties de secours. Chaque agent de production en a. Les frameworks ne les imposent pas ; vous devez les ajouter.

Ensembles d’évaluation. Les frameworks ne comprennent pas d’outils d’évaluation sérieux. Construisez-les séparément (Promptfoo, Braintrust, personnalisé).

Durcissement pour la production. Limitation du débit, idempotence, gestion des erreurs et solutions de repli. Le framework fournit quelques primitives ; vous construisez le reste.

Si vous vous concentrez sur ces schémas universels, le choix spécifique de framework importe moins. La discipline de l’équipe importe davantage.

Verdicts par framework

Après avoir travaillé avec beaucoup de ces frameworks, notre opinion :

LangChain/LangGraph : puissant mais lourd. Vaut la peine d’apprendre. En production, souvent migré pour les chemins chauds.

CrewAI : attrayant pour explorer les idées multi-agents. En production, ce paradigme est souvent appliqué inutilement. Utilisez-le avec discernement.

Pydantic AI : sous-estimé. La sûreté des types produit des bénéfices durables et mérite un essai.

OpenAI Agents SDK / Anthropic Claude SDK : bon si vous êtes engagé sur ce fournisseur. Sinon, risque de verrouillage.

LlamaIndex : encore le roi pour les travaux RAG lourds. Moins convaincant pour les agents généraux.

API directe : voie fréquente pour les équipes matures. Il n’est pas nécessaire de commencer ainsi, mais le code critique de production peut finir par y converger.

Microsoft Autogen / Semantic Kernel : bon pour l’écosystème Microsoft ; moins convaincant en dehors.

Une histoire de migration

Pour rendre concret, une progression réelle :

Mois 1-3 : L’équipe construit les premières fonctionnalités IA en LangChain. Rapide à déployer, beaucoup de schémas appris.

Mois 4-6 : Des exigences de production émergent — observabilité, évaluations, performance. L’équipe les construit sur LangChain.

Mois 7-9 : Certaines abstractions de LangChain deviennent des points de friction. L’équipe commence à envelopper LangChain dans ses propres interfaces.

Mois 10-12 : Une mise à jour de version de LangChain brise plusieurs systèmes. L’équipe réécrit les chemins chauds en appel direct à l’API. Les chemins froids restent en LangChain.

Année 2 : La plupart du code de production est l’appel direct à l’API. LangChain est utilisé pour des prototypages occasionnels. L’« agent framework » interne de l’équipe — construit sur l’appel direct à l’API — est le standard.

C’est une trajectoire valide. D’autres sont valides également — certaines équipes restent dans LangChain avec satisfaction ; certaines le sautent dès le début.

Un autre angle : ce que vous choisissez vraiment

Au-delà du framework, vous choisissez :

• Une communauté d’apprentissage.
• Un rythme de changement d’API à vivre.
• Un ensemble de schémas à standardiser.
• Une expérience de débogage.
• Une histoire d’observabilité.
• Un coût de migration futur.

Le framework est une expression de ces éléments. Mais ce sont ces choses qui affectent votre équipe au quotidien.

Un framework qui s’adapte à votre communauté, à votre tolérance au changement, à vos schémas, à votre style de débogage, à vos besoins d’observabilité — c’est le bon choix. Sans ces adéquations, même le framework le plus populaire est mauvais pour vous.

À retenir

Il n’y a pas de meilleur framework d’agents universel en 2026. Le bon choix dépend de la complexité du projet, de la taille de l’équipe, de la maturité de la production, de la stratégie fournisseur et des préférences de l’équipe.

Une approche pragmatique consiste à :

• Adapter le framework aux exigences du projet à l’aide des heuristiques ci-dessus.
• Prototyper avant de s’engager.
• Structurer le code de manière à ce que le changement soit possible.
• Se concentrer sur les schémas universels indépendamment du framework.
• S’attendre à évoluer — ce qui convient maintenant peut ne pas convenir dans 12 mois.

Beaucoup d’équipes matures convergent vers l’appel direct à l’API pour le code critique en production. Les frameworks restent utiles pour le prototypage, l’apprentissage et l’orchestration modérément complexe. Le choix n’est pas religieux ; il est contextuel.

Choisissez celui qui convient aujourd’hui et changez lorsqu’il ne convient plus. Le système construit importe davantage que le framework utilisé.