MAF 1.0, LangGraph ou CrewAI ? Comment choisir un framework d’agent en 2026

Microsoft a publié Agent Framework 1.0 (MAF) le 3 avril 2026. Il regroupe AutoGen et Semantic Kernel en un seul package destiné à l’environnement de production, et il est arrivé sur un marché où LangGraph et CrewAI étaient déjà des choix établis. Les équipes qui se demandaient auparavant quel framework choisir se demandent maintenant s’il convient de faire le changement. Voici une comparaison visant à aider à cette décision, avec toutes les informations mises à jour au 11 avril 2026.

Réponse courte

Utilisez CrewAI pour les prototypes. Choisissez LangGraph pour des workflows Python complexes et indépendants du cloud. Choisissez MAF si vous travaillez sur Azure, car il est disponible tant pour .NET que pour Python. Si vous disposez déjà de code LangGraph, le package langchain-azure-ai le connecte à Azure Foundry, vous épargnant ainsi une réécriture.

Qu’est-ce qui a changé depuis 2025

• AutoGen et Semantic Kernel ont été fusionnés dans MAF 1.0, disponible en général le 3 avril 2026.
• LangGraph v1 a finalisé son environnement de exécution et ses outils associés.
• CrewAI s’est développée autour des flux de travail et du système de points de contrôle.
• MCP, A2A et AG-UI sont passés d’éléments optionnels à des fonctionnalités attendues.

Trois modèles mentaux différents

Ces frameworks ne s’accordent pas sur la définition même d’un agent, et cette divergence est plus importante que n’importe quelle liste de fonctionnalités.

LangGraph modélise un flux de travail sous forme de graphe orienté. Les nœuds représentent des fonctions, les arêtes des décisions, et l’état se déplace visiblement à travers le graphe. On pense en code.

# LangGraph: explicit graph control
from langgraph.graph import StateGraph
from langgraph.checkpoint.sqlite import SqliteSaver

graph = StateGraph(State)
graph.add_node("classify", classify_doc)
graph.add_node("extract", extract_data)
graph.add_conditional_edges("classify", route_by_type)
app = graph.compile(checkpointer=SqliteSaver("agent.db"))

CrewAI modélise une équipe. Chaque agent possède un rôle, un objectif et une histoire personnelle, tous décrits en langage courant, afin que vous puissiez penser en termes d’organigrammes.

# CrewAI: role-based simplicity
from crewai import Agent, Crew, Process

researcher = Agent(role="Researcher", goal="Find accurate data",
                   llm="gpt-4o")
writer = Agent(role="Writer", goal="Draft clear reports",
               llm="gpt-4o")
crew = Crew(agents=[researcher, writer], tasks=[...],
            process=Process.sequential)

MAF propose deux styles sous un même toit : des conversations libres, pilotées par des LLM et héritées d’AutoGen, ainsi que des workflows professionnels fixes, hérités de Semantic Kernel. Vous pouvez les combiner.

# MS Agent Framework: simple agent in Python
import asyncio
from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient

async def main():
    client = AIProjectClient(
        endpoint="https://your-project.services.ai.azure.com/api",
        credential=DefaultAzureCredential()
    )
    agent = client.agents.create_agent(
        model="gpt-4.1",
        instructions="You are a concise data analyst."
    )
asyncio.run(main())

Problèmes de production, un par un

État et persistance

C’est ici que le déploiement réussit ou échoue. LangGraph est le seul des trois à disposer intégralement d’une fonction de réexécution des points de contrôle au niveau des étapes. Si un agent échoue à l’étape 7 sur 12, il est possible d’examiner chaque état antérieur et de reprendre depuis l’étape 6. Dans les industries réglementées, cette fonctionnalité est presque obligatoire, ce qui donne l’avantage à LangGraph.

MAF dispose d’un moteur de flux de travail graphique couvrant les modèles séquentiels, concurrents, de transfert de tâches et de chat en groupe, ainsi que des fonctions Durable pour gérer des états à long terme. Son fichier README mentionne le voyage dans le temps au sein des flux de travail graphiques, mais les outils de réexécution sont moins perfectionnés que ceux proposés par LangSmith. L’intégration des tâches Durable reste en version bêta en Python, et une fois stabilisée, l’écart pourrait se réduire pour les équipes utilisant Azure. CrewAI a besoin d’outils externes à cet égard.

Mémoire

La mémoire est le principal facteur de différenciation, mais aussi la plus grande faiblesse de chaque framework. MAF est le seul à disposer d’une couche de mémoire entièrement gérée capable de s’adapter aux besoins des entreprises, bien qu’il ne fonctionne que sur Azure et reste encore en version préliminaire. La mémoire gérée de Foundry, en version préliminaire publique depuis janvier 2026, extrait des informations des conversations, résout les conflits entre elles et restitue le contexte pertinent lors des sessions ultérieures, sans nécessiter d’infrastructure propre à l’entreprise. Elle est la solution idéale si votre entreprise a déjà adopté Microsoft Foundry comme standard.

LangGraph peut appeler les agents du Foundry Agent Service via langchain-azure-ai, mais la mémoire gérée est une fonctionnalité de MAF qui ne permet pas de relier pleinement ces deux systèmes. LangGraph offre bien une exécution fiable et un état persistant grâce aux points de contrôle, mais il ne les enveloppe pas dans une abstraction de mémoire gérée prête à l’emploi. Pour les installations auto-hébergées, CrewAI dispose de la fonctionnalité de mémoire la plus complète dès le départ.

Débogage et observabilité

Imaginez qu’un agent prenne une mauvaise décision à 3 heures du matin. Que voit l’ingénieur de garde ? LangGraph combiné à LangSmith offre la meilleure solution : la visualisation des traces accompagnée de la répétition des points de contrôle constitue actuellement la meilleure méthode de débogage pour les agents. Les traces de MAF s’intègrent nativement dans Application Insights ainsi que dans le nouveau tableau de bord des Foundry Agents, qui est prêt pour le déploiement en production mais ne permet pas de répétition des séquences. CrewAI, quant à lui, dépend de outils tiers.

Un détail pratique : en installant langchain-azure-ai[opentelemetry], les traces générées par LangGraph atteignent également Azure Application Insights. Cela vous permet d’utiliser LangSmith pendant le développement et Azure Monitor en production.

MCP et A2A

Ces protocoles déterminent la manière dont les agents communiquent avec les outils et entre eux. MAF est ici le meilleur choix. L’onglet Outils du portail Foundry regroupe en un seul endroit les serveurs MCP, les points de terminaison A2A, Fabric, SharePoint, Azure AI Search ainsi que plus de 1 400 connecteurs pour Logic Apps ; aucun autre outil ne propose une telle variété pour l’intégration d’entreprise. Le support des protocoles natifs par CrewAI est solide, tandis que LangGraph nécessite davantage de configuration manuelle.

Python sur Azure : deux options réelles

De nombreuses comparaisons présentent Azure comme un environnement réservé à .NET. Ce n’est pas le cas. Les équipes utilisant Python disposent de deux bonnes options.

Option un : MAF pour Python

MAF 1.0 est devenu disponible pour Python le 3 avril 2026, le même jour que .NET. Il ne s’agit pas d’une version préliminaire.

# MAF Python: working agent in a few lines
import asyncio
from agent_framework import Agent
from agent_framework.openai import OpenAIChatClient

async def main():
    agent = Agent(
        client=OpenAIChatClient(),
        instructions="You are a helpful data analyst.",
        tools=[get_weather, get_menu_specials]
    )
    response = await agent.run("What's the weather in Amsterdam?")
asyncio.run(main())

Cela apporte plusieurs avantages que LangGraph ne peut pas égaler :

• La mémoire gérée par Foundry, qui extrait, consolide et récupère les données entre sessions
• Agent 365, pour une gouvernance centralisée et un déploiement direct dans Microsoft 365 (disponible généralement à partir du 1er mai)
• The Voice Live API, pour des agents de traduction vocale en temps réel natifs
• Foundry IQ, qui offre un RAG dynamique via une seule API de référencement
• Foundry Control Plane, qui regroupe l’identité, les politiques et la capacité d’observation

Le prix est un frein pour les premiers adoptants. Python GA n’avait que huit jours d’existence au moment où ce texte a été écrit. Plusieurs intégrations, à savoir A2A, AG-UI, Azure Functions, Cosmos DB et Mem0, sont encore en version bêta et nécessitent le flag --pre. Les ressources communautaires telles que les tutoriels et les réponses sur Stack Overflow sont moins abondantes que celles de LangGraph, et les versions bêta risquent de causer des problèmes au cours des prochains mois.

Option deux : LangGraph plus langchain-azure-ai

Microsoft gère lui-même langchain-azure-ai (v1.2.1, sorti le 26 mars 2026) et le recommande comme méthode pour exécuter LangChain et LangGraph sur Azure. Il ne s’agit pas d’une solution de contournement communautaire.

# LangGraph + Azure Foundry via the bridge
from langchain_azure_ai.chat_models import AzureAIOpenAIApiChatModel
from azure.identity import DefaultAzureCredential

model = AzureAIOpenAIApiChatModel(
    project_endpoint="https://myproject.services.ai.azure.com/api",
    credential=DefaultAzureCredential(),
    model="gpt-5.2"
)

Vous bénéficiez du débogage éprouvé de LangGraph ainsi que des modèles et services d’Azure. Ce que vous abandonnez, ce sont toutes les fonctionnalités exclusives à MAF : la mémoire gérée Foundry, Voice Live, la gouvernance Agent 365 et Foundry IQ. Le pont relie l’infrastructure d’Azure, et non ses fonctionnalités spécifiques aux agents.

Choix entre les deux

Pour un nouveau projet Azure qui privilégie une intégration profonde, une mémoire gérée, des mécanismes de gouvernance et la voix, optez pour MAF Python et acceptez d’être parmi les premiers à l’utiliser. Si ce qui vous importe le plus, c’est la fiabilité éprouvée, le débogage via des points de contrôle ou la portabilité, choisissez LangGraph avec le pont. Les deux représentent des solutions de production solides, et aucune des deux n’est une erreur.

Coût de fonctionnement

Tous ces trois frameworks sont open source sous la licence MIT, mais le coût total de possession diffère rapidement. Les valeurs approximatives ci-dessous dépendent des tarifs de type GPT, d’une durée moyenne de conversation et d’un taux modéré d’appels aux outils ; elles incluent l’hébergement mais pas le temps d’ingénierie. Considérez-les comme des ordres de grandeur, et non comme des promesses.

CrewAI est le moyen le moins cher pour commencer. LangGraph offre le meilleur rapport qualité/prix en termes de flexibilité. Les services gérés de MAF peuvent économiser des mois de travail d’ingénierie, mais ils vous lient également davantage à Microsoft.

Une méthode de décision en trois questions

1. Êtes-vous sur Azure ? Avec .NET, MAF est clairement le choix idéal. Avec Python, vous avez les deux options mentionnées ci-dessus : MAF pour une intégration la plus profonde, ou LangGraph associé à un outil de pont pour le débogage et la portabilité. Si vous n’êtes pas sur Azure, passez à l’étape suivante.
2. Avez-vous besoin de structures de branchement complexes, de boucles ou d’un débogage basé sur des points de contrôle ? Alors LangGraph, dont le modèle de graphe et les fonctionnalités de navigation temporelle n’ont pas de véritables concurrents.
3. Avez-vous besoin d’un prototype multi-agents fonctionnel d’ici la semaine prochaine ? Alors CrewAI, qui permet de créer une équipe opérationnelle en environ 20 lignes de code. Sinon, LangGraph reste la solution par défaut neutre en termes de cloud : plus de travail au départ, mais moins de regrets à grande échelle.

Comment se déroulent généralement les projets d’entreprise

Une approche courante consiste à créer un prototype avec CrewAI au cours des deux premières semaines pour valider le cas d’usage, puis à reconstituer le système en utilisant MAF ou LangGraph pendant les mois un à trois, avant d’élargir l’échelle sur des infrastructures gérées, que ce soit Foundry Agent Service, LangGraph Cloud ou les deux à la fois.

Les équipes travaillant avec Azure ont tendance à se diviser en deux groupes. Celles qui commencent de zéro privilégient MAF Python, car la gestion mémoire, Agent 365 et le Foundry Control Plane sont difficiles à reproduire ailleurs. Les équipes disposant déjà de code LangGraph utilisent langchain-azure-ai pour intégrer Azure sans avoir à réécrire leur code, ce qui sert de pont de migration et non de recommandation pour de nouveaux projets. Pour les équipes utilisant .NET, MAF 1.0 est clairement le choix préféré, tandis qu’en dehors d’Azure, LangGraph reste la solution par défaut.

Qu’est-ce qui détermine si le projet sera mis en production ?

Après trois ans d’utilisation des agents, ce framework explique peut-être 20 % du résultat final. Les 80 % restants dépendent de cinq facteurs que les SDK ne gèrent pas automatiquement pour vous.

La conception du flux de travail est plus importante que l’architecture. Si une personne ne parvient pas à expliquer clairement la logique de décision, un agent ne pourra pas la créer ; il est donc essentiel de cartographier le processus humain de bout en bout avant d’écrire le moindre code d’agent.

La qualité des données reste le goulot d’étranglement. Les agents amplifient tout ce que vous leur fournissez, il faut donc nettoyer les données d’entrée en premier.

La rédaction des instructions fait la différence entre les bons résultats et les mauvais. Les systèmes LangGraph sophistiqués échouent face à des instructions vagues, tandis que les prototypes simples de CrewAI réussissent parce que quelqu’un a passé deux jours à affiner les instructions. La plupart des équipes investissent bien moins que nécessaire dans ce domaine.

La révision par des humains est une décision de conception, pas une option. Déterminez à l’avance quel niveau de confiance déclenche une révision et quelles actions nécessitent une approbation explicite.

La gestion des changements est la partie la plus difficile. Personne ne prévoit de budget pour cela, et elle fait échouer plus de projets qu’une mauvaise choix technologique ne le ferait jamais.

La capacité d’extension de votre déploiement dépend bien plus de ces éléments fondamentaux que du SDK que vous importez. Choisissez le framework qui correspond aux compétences de votre équipe et à l’ensemble des outils utilisés par votre organisation, puis consacrez des efforts importants à tout ce que le framework ne peut pas faire à votre place.