Frameworks d’agents IA en 2026 : panorama et matrice de décision

Microsoft a livré Agent Framework v1.0 le 3 avril 2026. C’était la fin d’un long bras de fer interne entre les équipes Semantic Kernel et AutoGen, et probablement le début d’une période de calme relatif dans un écosystème qui en avait besoin. Pendant deux ans, choisir un framework d’agents IA revenait à parier sur le mauvais cheval un trimestre sur deux. Ce n’est plus tout à fait le cas. Une dizaine d’acteurs structurent désormais le marché, avec des rôles assez nets pour qu’on puisse en faire le tour.

L’écosystème des frameworks d’agents IA s’est stabilisé

Si on cherche à dater l’écosystème, 2024 a été l’année du RAG, 2025 celle des agents, et 2026 ne se laisse pas étiqueter aussi facilement. Elle est en revanche plus simple à vivre. La course aux annonces s’est calmée. Sur les trimestres précédents, il y avait régulièrement une nouvelle librairie, un nouveau protocole, ou un débat de fond sur le bon niveau d’abstraction. Du point de vue des équipes qui construisaient en production, ça ressemblait surtout à du risque. Engager une migration ou un investissement de formation pour découvrir six mois plus tard qu’on a pris la mauvaise piste, ça finit par user.

Cette accalmie vient en bonne partie de Microsoft. Depuis 2023, l’éditeur entretenait deux projets parallèles qui répondaient au même usage : Semantic Kernel, taillé pour les développeurs .NET enterprise, et AutoGen, plus orienté recherche multi-agents. Cumulés, 75 000 étoiles GitHub, deux philosophies incompatibles, et beaucoup de questions de la part de développeurs qui ne savaient sur lequel investir. La fusion a été annoncée en octobre 2025, AutoGen est passé en maintenance mode en février 2026, et le 3 avril, Agent Framework v1.0 est sorti en GA, avec un engagement de support long terme — chose qui reste rare dans cet écosystème.

Au-delà de cette consolidation, deux protocoles ouverts se sont imposés en parallèle. MCP, lancé par Anthropic, est devenu le standard de fait pour exposer des outils à un agent. Plus de deux cents serveurs publics aujourd’hui : GitHub, Slack, Notion, PostgreSQL, Jira, Salesforce. A2A, initié par Google, joue le même rôle pour la communication entre agents. Aucun framework récent n’a fait l’économie de les supporter, à des degrés divers.

Le dernier changement est plus diffus, mais peut-être le plus important. La conviction qu’un framework allait finir par tout absorber, encore très partagée mi-2025, n’a plus beaucoup de défenseurs sérieux. Les discussions ont changé de nature. On ne demande plus quel framework va gagner, on demande lequel correspond à quel cas. Et c’est précisément ce déplacement qui rend la cartographie utile.

Trois familles de frameworks d’agents IA

Une fois cette stabilisation comprise, il reste à se repérer dans le paysage. Quand on aligne ces frameworks côte à côte, ils ne se ressemblent pas tant que ça. Pour s’y retrouver, deux questions suffisent : à quel niveau veut-on travailler, et dans quel environnement ?

D’un côté, il y a les frameworks qui mettent les mains dans le cambouis. LangGraph, Microsoft Agent Framework, AWS Strands, Pydantic AI, Smolagents. On écrit son graphe, on déclare ses états, on gère ses transitions. Tout est explicite. C’est plus long à apprendre, mais on tient la machine.

De l’autre, ceux qui donnent des poignées plus naturelles. CrewAI, AG2, Claude Agent SDK, OpenAI Agents SDK, Google ADK, OpenAgents. On parle de rôles, d’équipes, de handoffs, de sub-agents. La mécanique est cachée derrière des abstractions qui ressemblent à de l’organisation humaine. On va beaucoup plus vite, mais on perd un peu en finesse de contrôle.

Et puis il y a les outils visuels. LangSmith Studio, CrewAI Studio, OpenAI Agent Builder, Microsoft Foundry DevUI, n8n. On clique, on glisse-dépose, un runtime hébergé fait tourner le tout derrière. On pourrait imaginer des outils visuels qui exposeraient les primitives bas niveau, mais personne n’a vraiment réussi. Dès que la logique se complique un peu, l’interface graphique craque. On finit par éditer du code dans des cases de formulaire, et ça devient moins lisible que du Python pur. C’est pour ça que la zone « visuel + contrôle fin » reste vide.

Les 10 frameworks d’agents IA à connaître en 2026

Une fois la carte posée, le détail des frameworks. Voici comment chacun se positionne aujourd’hui, en commençant par celui qui a le plus pesé dans la stabilisation de l’écosystème.

LangGraph

LangGraph s’est imposé sans qu’on le décide vraiment. Quand des équipes comme celles de Klarna, Uber, J.P. Morgan ou LinkedIn ont commencé à mettre des agents en production, elles ont convergé indépendamment sur la même librairie. Un peu par défaut, beaucoup parce que rien d’autre ne tenait dans la durée. Le projet de LangChain ne séduit pas particulièrement à la première ouverture du repo. Il oblige à penser en graphes typés, à déclarer ses états, à expliciter ses transitions. Et c’est exactement ce qu’on lui reproche en démo, et ce qui en fait la colonne vertébrale en production.

Le modèle vient de Pregel et d’Apache Beam. Un agent est un graphe orienté avec des nœuds (qui sont des fonctions), des edges (qui sont des transitions), et un état partagé. Les checkpointers donnent la durable execution. Pour le développement local, MemorySaver convient. En production, on passe sur un checkpointer persistant : PostgreSQL, Redis, ou une implémentation managée selon l’infrastructure. On peut interrompre un agent, le redémarrer, il reprend où il en était. LangSmith fournit l’observabilité, avec un time-travel debugging que peu d’autres outils proposent dans cette catégorie. C’est austère, et c’est l’idée. Les frameworks qui promettent qu’on n’aura pas à comprendre la mécanique se retrouvent en difficulté dès que la complexité dépasse celle de la démo.

Microsoft Agent Framework v1.0

Réussir la fusion de Semantic Kernel et AutoGen tenait du pari. Deux bases de code que la communauté connaissait par cœur, deux philosophies opposées, deux populations d’utilisateurs qui ne se ressemblaient pas. À cela s’ajoutait l’engagement de Microsoft d’aligner tout ça sous une seule API avec un support de long terme. Le résultat est sorti le 3 avril 2026, et il tient la route.

Concrètement, Agent Framework v1.0 est une fusion plus pragmatique qu’idéologique. Semantic Kernel a fourni la fondation : kernel, plugins, connecteurs aux écosystèmes Microsoft. AutoGen a apporté les patterns d’orchestration multi-agents (sequential, concurrent, handoff, group chat, Magentic-One). Les deux runtimes, .NET et Python, partagent désormais une API commune. Six providers basculent en une ligne : Azure OpenAI, OpenAI, Claude, Bedrock, Gemini, Ollama.

Mais ce qui rend Microsoft Agent Framework difficile à ignorer en 2026, c’est moins technique que politique. C’est aujourd’hui le seul framework majeur livré avec un engagement Long-Term Support officiel. Pour une DSI qui investit sur trois ou cinq ans, ce détail change la décision. MCP est natif. Le support A2A v1 est arrivé fin avril côté .NET, avec découverte via /.well-known/agent-card.json, streaming SSE et exposition d’agents. OpenTelemetry est intégré, l’architecture de référence Azure App Service est documentée. Toute la stack a clairement été pensée pour passer en achat enterprise sans tordre le bras à personne.

CrewAI

CrewAI fait partie des frameworks les plus visibles et les plus adoptés de l’écosystème open source, et pourtant ce n’est probablement pas celui qu’un Lead Engineer choisirait à froid. Avec 1,3 million d’installations PyPI mensuelles, sa traction dépasse largement celle de concurrents techniquement plus pointus. La raison tient au modèle mental qu’il propose : des rôles, des objectifs, des équipes (crews) qui exécutent des tâches. Vingt lignes suffisent pour mettre debout un workflow recherche-rédaction. C’est direct, ça ressemble à de l’organisation humaine, ça passe une démo.

Côté outillage, la version 1.12 sortie en mars 2026 a apporté les agent skills, les providers OpenAI-compatibles natifs (OpenRouter, DeepSeek, Ollama, vLLM), un backend mémoire Qdrant Edge et l’isolation hiérarchique de la mémoire. La plateforme hostée propose un palier gratuit jusqu’à cinquante exécutions mensuelles, un palier Professional à 25 dollars par mois, et un palier Enterprise certifié SOC 2 avec déploiement K8s ou VPC.

La contrepartie de cette élégance est connue de toutes les équipes qui ont essayé de mettre du CrewAI en production. Le checkpointing est limité, le contrôle fin sur la communication inter-agents passe par les outputs de tâche plutôt que par un protocole explicite, et la gestion d’erreurs reste grossière. On voit donc revenir un scénario classique : un prototype CrewAI qui démarre en deux semaines, une démo qui passe la direction, puis une migration vers LangGraph six mois plus tard quand la production l’exige.

AG2 (anciennement AutoGen)

L’histoire d’AG2 est celle d’un fork qui n’aurait pas dû marcher et qui a partiellement marché. Quand Microsoft a annoncé en novembre 2024 la rewrite d’AutoGen en version 0.4, les contributeurs originels du projet de recherche ont décidé de continuer leur propre route. AG2 préserve l’API 0.2 telle quelle. Les codes existants tournent sans modification. L’argument était simple : une partie de la communauté ne suivrait pas Microsoft sur sa nouvelle voie enterprise.

Cet argument tient encore aujourd’hui. Avec 48 000 étoiles GitHub et une communauté académique solide, AG2 reste le terrain de jeu de la recherche multi-agents. Magentic-One y est toujours disponible, l’équipe préconfigurée de cinq agents spécialisés (Orchestrator, WebSurfer, FileSurfer, Coder, ComputerTerminal) capable de traiter des tâches ouvertes.

L’événement de mars 2026 a été le lancement d’AG2 Beta, une refonte event-driven avec architecture de streaming, support multi-provider, dependency injection, outils typés et testing first-class. C’est la réponse à la critique principale qu’on faisait à AutoGen : sa difficulté historique à passer en production. Pour autant, AG2 reste cantonné à la recherche et à l’exploration de patterns multi-agents. Sur du fort volume, les coûts en tokens deviennent rapidement prohibitifs, parce que chaque tour de GroupChat consomme l’historique conversationnel complet.

Anthropic Claude Agent SDK

Claude Agent SDK ne joue pas dans la même catégorie que les autres. Là où LangGraph orchestre et où CrewAI structure, Anthropic propose un harness : un environnement d’exécution dans lequel Claude gère lui-même la boucle d’appels d’outils. Le développeur n’écrit plus le tool loop. Il décrit ce qu’il veut, les outils disponibles, et Claude se débrouille.

Dans cette approche, l’intégration MCP est de loin la plus profonde du marché. Les custom tools sont implémentés comme serveurs MCP in-process, ce qui évite la surcharge de communication d’un sous-processus séparé. Le SDK ouvre l’accès à un système de fichiers réel, à des commandes shell, à la navigation web, avec un modèle de permissions granulaire. Pour qui construit un agent qui doit lire et modifier une codebase, exécuter du shell, naviguer dans une arborescence, l’expérience est qualitativement différente de ce qu’on obtient en assemblant les briques soi-même.

Anthropic a complété l’offre en avril 2026 avec Claude Managed Agents, encore en beta (header managed-agents-2026-04-01). Mieux vaut bien distinguer les deux côtés du dispositif. Claude Agent SDK donne un contrôle local sur le harness et les outils, pour les équipes qui veulent garder la main sur l’orchestration. Claude Managed Agents externalise le runtime, le sandbox, la persistance et l’exécution longue côté Anthropic, pour celles qui préfèrent déléguer l’infrastructure d’exécution. Sur des tâches longues qui durent des minutes ou des heures, avec multiples appels d’outils, c’est une alternative crédible à un déploiement maison. La limite, qu’Anthropic assume, est que le SDK est verrouillé sur les modèles Claude. Pour un agent multi-modèle, on combine généralement avec un orchestrateur externe comme LangGraph, où Claude n’est qu’un nœud parmi d’autres.

OpenAI Agents SDK

OpenAI a abandonné Swarm, son framework expérimental, en mars 2025. Ce qui l’a remplacé, Agents SDK, est plus opinioné, plus léger, et assumé comme tel. Quatre primitives, pas une de plus : Agents, Tools, Handoffs, Guardrails. La sobriété est revendiquée, et c’est ce qui en fait l’intérêt. On lit le code et on comprend ce qui se passe sans avoir à reverse-engineerer une couche d’abstraction obscure.

La signature du SDK, c’est le handoff. Un agent transfère explicitement le contrôle à un autre, qui hérite du contexte conversationnel complet. Très naturel pour le support tiered, le triage médical, le routage commercial. La limite arrive vite. Au-delà de huit ou dix agents, ces chaînes de handoffs se transforment en graphes implicites mal documentés que personne dans l’équipe ne sait lire en entier, et qu’on évite de toucher pour ne pas casser la prod.

L’évolution majeure est arrivée le 15 avril 2026, avec un harness model-native (la même architecture qui propulse Codex, l’assistant de codage interne d’OpenAI) et des Sandbox Agents, des spécialistes qui exécutent leur travail dans un workspace isolé, avec fichiers, packages, ports et snapshots. C’est un rapprochement assumé de ce que propose Anthropic, pour l’instant en Python uniquement (le TypeScript suit). Le SDK supporte des modèles non-OpenAI via toute API compatible Chat Completions, mais les capacités les plus intégrées (tool search, computer use, compaction des contextes longs, hosted shell, certains patterns de sandbox) dépendent des modèles et surfaces OpenAI les plus récents. En pratique, on raisonne plutôt en termes de modèles OpenAI compatibles Responses API (GPT-5.4 et GPT-5.5 pour les capacités les plus avancées) qu’en figeant un seuil sur une version donnée.

Google ADK

Google a livré ADK en avril 2025 et l’a fait mûrir pendant un an. Sa signature est une structure hiérarchique d’agents, où un root agent délègue à des sub-agents qui peuvent eux-mêmes avoir leurs propres sub-agents. La délégation se fait par description : chaque agent annonce son périmètre, et le parent route en conséquence. Le modèle correspond bien aux organisations métier qui pensent en silos fonctionnels.

L’intégration avec Vertex AI et Gemini est naturellement la plus profonde, mais ADK reste model-agnostic via LiteLLM, supportant Claude, GPT, Mistral, Llama. Le déploiement se fait sur Agent Runtime, sur Cloud Run, ou sur un conteneur Docker custom. Rien de très original sur la partie déploiement, donc.

Là où ADK tire son épingle du jeu, c’est sur l’A2A. Génération automatique des Agent Cards via /.well-known/agent-card.json, intégration profonde avec Vertex et le reste de Google Cloud. C’est le framework où ce protocole se sent le plus chez lui. Mais ADK n’est plus seul à prendre A2A au sérieux. Microsoft Agent Framework a renforcé son support A2A v1 fin avril 2026, et AWS Strands expose un support Python et TypeScript. Pour qui cherche à faire dialoguer des agents construits sur des frameworks différents, ADK reste un excellent point de départ. La maturité production est plus jeune que celle de LangGraph, certes, mais l’adossement Vertex et la trajectoire Google Cloud rendent l’investissement raisonnable.

AWS Strands Agents

Strands est arrivé tard dans la course mais avec un argument lourd : c’est le SDK code-first d’AWS, open-sourcé en mai 2025 sous Apache 2.0, et utilisé en interne par Amazon Q Developer, AWS Glue, Kiro et VPC Reachability Analyzer. La philosophie est explicitement model-driven : plutôt que d’imposer une orchestration rigide, Strands laisse le modèle planifier, chaîner ses pensées, appeler les outils et réfléchir. Trois composants suffisent : un modèle, un system prompt, une liste d’outils. Le reste, c’est le LLM qui le fait.

Ce qui fait la valeur de Strands, c’est son intégration AWS. Bedrock pour l’inférence, Lambda et Fargate pour le runtime, IAM pour les permissions, S3 pour la persistance, OpenTelemetry pour l’observabilité. Et pourtant le framework reste vraiment model-agnostic : Bedrock, Anthropic direct, OpenAI, Gemini, Mistral, Llama via LiteLLM, Ollama. Anthropic a contribué l’intégration de son API. Meta a ajouté le support Llama. Côté patterns multi-agents, on a Swarm, Graph, Workflow DAG et Agents-as-Tools out of the box. Sur l’interopérabilité enfin, Strands expose un support A2A en Python et TypeScript, ce qui le place dans le même cercle que Google ADK et Microsoft Agent Framework sur ce volet.

L’événement d’avril 2026 a été l’arrivée du harness AgentCore intégré à Strands : un déploiement en trois appels API, microVM dédiée par session, support multi-modèles (Bedrock, OpenAI, Gemini), neutralité du framework côté runtime (LangGraph, LlamaIndex et CrewAI peuvent aussi tourner sur AgentCore). Pour les équipes déjà sur AWS, c’est aujourd’hui le chemin le plus court entre un agent qui marche en local et un agent en production avec IAM, VPC et secrets management gérés.

Smolagents, Pydantic AI, OpenAgents

À côté des grands acteurs, trois projets plus spécialisés valent le détour selon le contexte.

Smolagents, porté par Hugging Face, joue la carte de la légèreté radicale. Sa philosophie tient en une ligne : un agent est une fonction qui écrit et exécute du code Python. Pas d’abstraction inutile, quelques centaines de lignes de framework, intégration native avec le hub Hugging Face. C’est l’outil qu’on choisit pour des prototypes de recherche, des notebooks d’exploration, ou des agents simples sans envie d’embarquer une dépendance lourde.

Pydantic AI, sorti par l’équipe Pydantic, joue lui la carte de la rigueur typée. Son approche déclarative s’est renforcée avec les Capabilities (unités composables de comportement) et AgentSpec, qui charge des agents depuis des fichiers YAML ou JSON avec modèle, instructions, paramètres et capacités. La syntaxe rappelle FastAPI : déclarative, validée, agréable à manipuler. Pour une équipe Python qui valorise la sécurité de type, les sorties structurées et l’intégration avec un backend existant, c’est un choix naturel.

OpenAgents enfin propose un paradigme réseau. Des agents persistants, hétérogènes (LangGraph, CrewAI, agents custom) communiquent via MCP et A2A natifs. Le projet vise les architectures où on ne veut pas centraliser l’orchestration, mais laisser des agents se découvrir et collaborer comme des microservices. La communauté est plus jeune, et le positionnement reste unique sur l’interopérabilité radicale.

Frameworks d’agents IA : la chronologie 2024-2026

Cet écosystème actuel est le résultat de trois années de mouvements rapprochés. Onze événements en résument la trajectoire.

Le pivot de l’année est la sortie en GA d’Agent Framework le 3 avril. Onze jours plus tard, OpenAI livre une refonte majeure de son SDK. Dans le même mois, Anthropic ouvre Claude Managed Agents en beta. Trois éditeurs, trois architectures comparables, alignées en moins d’un mois. Difficile d’y voir une coïncidence. C’est plutôt le signe que le marché a fini par converger sur un certain canon.

Comparatif des frameworks d’agents IA : 8 critères qui comptent en production

Maintenant que chaque framework est posé, l’enjeu est de pouvoir les comparer sur ce qui compte vraiment. Sur le papier, ils promettent à peu près la même chose : faire tourner un agent qui appelle des outils. La différence se joue ailleurs. Sur huit points, en réalité, qui font qu’un projet tient ou ne tient pas une fois passé en production : le modèle d’orchestration, la gestion de l’état, le support de MCP, le support d’A2A, la qualité du streaming, l’observabilité, la maturité production réelle, et la facilité de prise en main pour une équipe qui débarque. Le tableau ci-dessous résume où chacun se situe.

En regardant ce tableau de près, plusieurs choses ressortent. Personne ne gagne partout, c’est le premier constat. LangGraph est solide sur quasiment tout sauf la prise en main, qui demande un vrai investissement. CrewAI démarre vite mais sa gestion d’état reste fragile. Claude SDK domine sur MCP mais reste verrouillé sur les modèles Anthropic. Ces écarts ne sont pas des bugs, ce sont des partis-pris assumés par les éditeurs, et c’est précisément ce qui rend l’écosystème lisible aujourd’hui.

Au-delà de ce constat, MCP est devenu un acquis. Il y a un an, c’était encore un argument commercial. Aujourd’hui, tout le monde le supporte, à des niveaux variables. Ce qui distingue vraiment Claude SDK sur ce volet, c’est la profondeur de l’intégration : les outils tournent in-process plutôt qu’à travers un sous-processus séparé. À l’usage, ça change beaucoup de choses sur la latence et le debugging.

Sur A2A, en revanche, les choses ont bougé ces derniers mois. Google ADK garde l’intégration la plus naturelle, autour des Agent Cards et de l’écosystème Vertex/Gemini. Microsoft Agent Framework a renforcé son support A2A v1 fin avril 2026, surtout côté .NET. AWS Strands expose lui aussi un support A2A en Python et TypeScript. Pour les autres, on reste sur du wrapping ou de l’intégration via gateway, avec des niveaux qui varient pas mal. Ce n’est plus binaire comme il y a six mois. Ça se joue maintenant sur des degrés de profondeur d’intégration et de naturel d’écriture.

Sécurité des agents IA en production : les vrais risques

Choisir le bon framework et bien lire la matrice ne suffit pas pour aller en production. La mise en production d’agents IA ne se résume pas au choix du framework. Dès qu’un agent accède à des outils, des bases de données, des fichiers, des APIs internes ou des workflows métier, la surface d’attaque augmente fortement. MCP standardise l’accès aux outils et aux systèmes externes, et c’est précieux. Mais la standardisation du transport ne supprime pas les risques de prompt injection, d’escalade de privilèges, de fuite de données ou d’exécution non désirée.

En production, chaque outil doit donc être traité comme une frontière de sécurité. Permissions minimales, scopes explicites, allowlist réseau, validation humaine pour les actions irréversibles, logs d’audit, traçabilité des appels d’outils, isolation des sessions, séparation stricte des identités utilisateur, agent et outil. Voilà ce qui distingue un agent qui passe une démo d’un agent qui passe une revue de sécurité.

Les runtimes managés comme Microsoft Foundry Agent Service, Claude Managed Agents ou Amazon Bedrock AgentCore apportent une partie de ces garanties : sandbox, isolation par session, gestion d’identité fédérée. Ils ne remplacent pas pour autant une architecture de gouvernance. Le framework orchestre l’agent. La plateforme sécurise son exécution. L’entreprise reste responsable des droits, des données et des effets métier. Aucun éditeur ne couvre les trois.

Quel framework d’agents IA choisir selon votre contexte

Tout ce qui précède aide à comprendre l’écosystème, mais n’éclaire pas encore le choix concret. Pas de réponse universelle ici. En revanche, en regardant les projets qui passent réellement en production, sept situations reviennent. Le bon réflexe au moment de choisir, c’est de se poser deux questions dans l’ordre. Est-ce qu’on écrit du code ou est-ce qu’on consomme un service managé ? Est-ce qu’on est attaché à un cloud précis ou pas ? Les hyperscalers ont chacun leur stack maintenant, et c’est sans doute le changement le plus important par rapport à l’année dernière.

Projet régulé multi-cloud : LangGraph + LangSmith

C’est le cas typique d’un workflow long en banque, en santé ou dans le public. Il faut de la traçabilité réglementaire, du human-in-the-loop, et un comportement propre quand un modèle ou une API tombe. Pour ce genre de projet, la combinaison LangGraph, LangSmith et PostgresSaver en self-hosted reste le meilleur compromis. On le déploie sur Azure ou OVH selon les exigences de souveraineté. Le checkpointing PostgreSQL et la durable execution ne se discutent pas. C’est aussi le choix qu’on fait quand on veut pouvoir basculer d’un cloud à l’autre plus tard sans tout réécrire.

Prototype rapide en équipe développeur : CrewAI

L’objectif ici est de tester une idée en quelques semaines avant de décider si on continue. La productivité passe avant le contrôle. CrewAI est fait pour ça. Sa plateforme hébergée fait gagner du temps pour les démos, et les data scientists ou les product managers techniques peuvent contribuer sans avoir à apprendre les graphes typés. Si la valeur est prouvée, on regarde si on migre vers LangGraph. Cette trajectoire est devenue tellement classique qu’on en parle ouvertement dans les retex, et le coût est moins élevé que ce que les équipes craignent au moment où elles posent la question, parce que les prompts et la logique métier sont portables.

Intégration métier sans développeur : n8n

Une équipe ops, marketing ou commerciale veut intégrer un agent dans des workflows déjà en place. L’agent doit poster sur Slack, mettre à jour un CRM, traiter des emails, écrire dans une base SQL. Personne dans l’équipe ne fait du Python à temps plein. Dans ce contexte, n8n est probablement la meilleure option. Le nœud AI Agent natif et la bibliothèque de connecteurs évitent de coder un client API à chaque fois.

Sur le terrain, deux règles sont à respecter sans négocier. D’abord, fixer une borne stricte sur maxIterations, souvent entre 5 et 10 selon le workflow (la valeur par défaut de n8n est 10). Au-delà, le risque de boucle augmente fortement et la facture en tokens peut exploser sans qu’on s’en rende compte. Ensuite, toute action qui a un effet visible (envoyer un email, écrire en base, générer un document) doit passer par un point de validation. Humain ou automatique, peu importe, mais il en faut un.

Le pattern le plus solide observé dans les déploiements qui tiennent fonctionne en deux temps. On laisse l’agent raisonner et produire un plan d’action, puis on exécute ce plan via un workflow n8n classique, déterministe. L’IA décide, l’automatisation exécute. Avec ces garde-fous, le coût mensuel d’un agent de complexité moyenne tourne autour de 150 à 500 euros tout compris. Sans ces garde-fous, on se retrouve avec une boucle qui consomme du GPT-4 toute la nuit.

Agent intensif en outils : Claude Agent SDK

On parle ici des assistants développeur internes, des agents qui auditent du code, des copilotes qui analysent des logs. Tous les cas où l’agent doit ouvrir des fichiers, exécuter du shell, naviguer dans une arborescence. Claude Agent SDK change clairement la donne sur ce terrain. Le harness, la gestion fine des permissions et le sandbox sont d’un autre niveau qu’un assemblage maison. Pour les tâches qui durent plusieurs minutes ou qui tournent en asynchrone, Claude Managed Agents prend en charge le runtime côté serveur, ce qui évite d’avoir à monter sa propre infrastructure.

Stack Azure-native : Microsoft Agent Framework + Foundry

L’organisation est sur Azure, les équipes connaissent .NET ou Python, et l’IT exige du LTS, du networking privé, des évaluations en continu, du tracing OpenTelemetry. Depuis mars-avril 2026, Microsoft Agent Framework couplé à Foundry Agent Service coche toutes ces cases. On orchestre en code avec MS Agent Framework v1.0 (GA), et on déploie sur le runtime managed Foundry Agent Service, wire-compatible avec le Responses API d’OpenAI, avec hosted agents disponibles dans plus de six régions Azure. Pour les équipes qui ne veulent pas construire leur propre runtime et qui acceptent le verrouillage Azure comme un compromis raisonnable, c’est aujourd’hui la stack la plus aboutie côté Microsoft.

Stack AWS-native : AWS Strands + Bedrock AgentCore

L’architecture est event-driven sur Lambda, Fargate ou EC2, et les équipes capitalisent sur Bedrock, IAM, S3, EventBridge. AWS Strands avec Bedrock AgentCore est le chemin le plus direct entre un prototype local et un agent en prod. Strands fournit le SDK code-first et ses patterns multi-agents (Swarm, Graph, Workflow DAG), AgentCore fournit le harness managé : microVM dédiée par session, déploiement en trois appels API depuis avril 2026.

Côté facturation, AgentCore Runtime est facturé à l’usage, principalement selon les ressources CPU/mémoire consommées pendant l’exécution active. AWS donne un exemple de calcul autour de 0,0007 dollar par session pour un scénario type, mais ce chiffre dépend fortement de la durée, de la mémoire, du temps CPU, des appels d’outils, de la mémoire AgentCore, du Gateway et de l’inférence modèle. C’est une référence d’ordre de grandeur, pas un prix fixe. Détail intéressant au passage : AgentCore est neutre côté framework. On peut tout à fait y faire tourner du LangGraph ou du CrewAI à la place de Strands, ce qui ouvre la porte à des architectures hybrides.

Stack GCP-native : Google ADK + Vertex AI Agent Engine

L’organisation est sur Google Cloud, les données vivent dans BigQuery, et les modèles préférés sont les Gemini. Dans ce cas, Google ADK avec Vertex AI Agent Engine (rebrandé Gemini Enterprise Agent Platform au Cloud Next 2026) est le choix qui s’impose. ADK reste l’un des frameworks où A2A est le plus naturel, avec génération automatique des Agent Cards via /.well-known/agent-card.json. Vertex AI Agent Engine fournit le runtime managé serverless avec des cold starts en sous-seconde et le support des agents long-running. Ce qu’aucun autre framework n’égale en 2026, c’est la dimension multimodale : Gemini gère nativement images, audio et vidéo, ce qui ouvre des cas d’usage (inspection visuelle, support vocal, compréhension documentaire) que les autres frameworks doivent reconstruire avec des briques externes.

Migrer entre frameworks d’agents IA sans tout réécrire

Choisir un framework aujourd’hui ne veut pas dire choisir pour toujours. Toute équipe qui construit sur un framework finit par envisager une migration. C’est arrivé à beaucoup d’utilisateurs de CrewAI quand le projet a grandi au-delà de ce que le framework pouvait porter. C’est arrivé deux fois aux utilisateurs d’AutoGen 0.2 en deux ans : vers AG2, ou vers Microsoft Agent Framework. La bonne nouvelle, c’est que le coût réel d’une migration est plus faible que ce que la plupart des équipes craignent, à condition d’avoir bien découplé.

Concrètement, ce qui se conserve presque toujours, ce sont les prompts système et les instructions agent (du texte, indépendant du framework), la logique métier et les fonctions outils (si elles sont écrites comme fonctions Python ou TypeScript pures, elles sont portables vers MCP ou n’importe quelle abstraction d’outil), et les schémas de données : contrats Pydantic ou JSON Schema qui décrivent inputs et outputs.

Ce qui se réécrit systématiquement en revanche : la couche d’orchestration (graphes LangGraph, crews CrewAI, handoffs OpenAI sont par construction spécifiques au framework), la gestion d’état persistante (un MemorySaver LangGraph ne se traduit pas tel quel en sessions Microsoft Agent Framework), et l’intégration observabilité (passer de LangSmith à OpenTelemetry pur ou à Cloud Trace demande de revoir tracing et instrumentation).

La règle pratique tient en un ratio. Compter sur 70 % de code conservé et 30 % réécrit lors d’une migration entre frameworks majeurs. Si l’estimation tend vers 50/50, c’est probablement que le découplage initial était insuffisant, et c’est un signal qu’il faut traiter avant de migrer, pas pendant.

Frameworks d’agents IA : ce qui va durer

L’écosystème des frameworks d’agents IA en 2026 n’est plus une jungle. Il est stabilisé, avec des positions claires, des protocoles partagés, et une diversité qu’on a fini par accepter au lieu de la combattre. La compétence qui compte vraiment pour un Lead AI ou ML Engineer aujourd’hui, ce n’est pas la maîtrise fine d’une API qui aura changé dans deux ans. C’est la capacité à lire un projet sur ses vraies dimensions (orchestration, état, sécurité, écosystème cloud, équipe) et à défendre un choix de stack qui tient pour ce que le projet va devenir, pas juste pour ce qu’il est aujourd’hui.

Pas de framework universel, donc. Des contextes, chacun avec son outil. Cette fragmentation est devenue une force, à condition d’avoir le cadre de décision pour la naviguer. Les principes qui resteront stables ne sont pas dans les API : découplage clair entre la logique métier et le framework, observabilité sérieuse dès le premier prototype, portabilité des prompts et de la logique, choix structurel sur le niveau d’abstraction. C’est là-dessus qu’il faut bâtir, parce que c’est ce qui survit aux changements de version.