L’écosystème open source des agents IA s’est fragmenté rapidement. Il y a un an, on comptait trois ou quatre candidats sérieux. Aujourd’hui, il y en a des dizaines, chacun avec un README soigné, un nombre croissant d’étoiles sur GitHub et un Discord rempli d’utilisateurs enthousiastes. La vraie question n’est pas « quels frameworks existent ? » — c’est « sur lequel miserais-je le système de production d’un client ? »
Voici notre réponse à cette question, à mi-2026. Pas une checklist de fonctionnalités. Pas un classement de benchmarks. La shortlist honnête d’une équipe de développement — les frameworks que nous avons réellement utilisés, ceux que nous avons écartés, et les critères qui ont fait la différence.
Pour comprendre l’architecture sous-jacente avant de choisir un framework, Architecture des agents IA, expliquée pour les décideurs est un bon point de départ.
Les critères de sélection qui comptent vraiment
Avant de lister les candidats, il vaut la peine de nommer les axes qui guident nos choix de frameworks. Ils viennent de l’observation de projets d’agents qui réussissent et échouent en production — pas de la lecture de documentation.
Observabilité out of the box. Un agent qui ne peut pas expliquer pourquoi il a mal tourné n’est pas prêt pour la production. Le tracing, le logging au niveau des étapes et les pistes d’audit des tokens doivent exister nativement ou via une intégration bien supportée — pas comme un ajout plaqué six mois après le lancement.
Coût de maintenance par fonctionnalité. Certains frameworks sont puissants mais vous demandent de gérer beaucoup de plomberie vous-même. D’autres abstrahent si agressivement qu’on se retrouve à lutter contre l’abstraction dès que les exigences s’écartent du chemin nominal. Aucun des deux extrêmes n’est gratuit.
Maturité de l’écosystème et santé de la communauté. Les étoiles, c’est de la vanité. Ce que nous regardons : la fréquence des releases, la réactivité sur les issues, les signes d’un soutien commercial, et si la communauté résout de vrais problèmes de production ou ne fait que répéter le tutoriel d’introduction.
Support multi-agent sans acrobaties. La plupart des déploiements réels finissent par nécessiter plus d’un agent travaillant ensemble. Les frameworks qui traitent le multi-agent comme une préoccupation de premier niveau économisent une réécriture conséquente par la suite. Voir notre traitement approfondi dans Systèmes multi-agents : quand un seul agent IA ne suffit pas.
Neutralité vis-à-vis des fournisseurs de LLM et d’outils. Le lock-in au niveau du framework s’ajoute au lock-in au niveau du modèle. Préférez les frameworks qui traitent le LLM comme une dépendance substituable.
La shortlist : les frameworks sur lesquels nous parions
LangGraph
LangGraph est le framework auquel nous faisons appel lorsque la complexité du control flow est élevée et que les conséquences d’une mauvaise action sont significatives. Il modélise les agents comme des graphes avec état — les nœuds sont des étapes d’exécution, les arêtes sont des transitions, et vous définissez exactement ce qui se passe quand le graphe rencontre une erreur ou une condition de branchement.
Cette explicité a de vrais coûts. L’onboarding prend plus de temps. Les agents simples semblent sur-ingéniérisés dans LangGraph. Mais pour les systèmes multi-étapes et multi-agents où vous avez besoin de chemins de récupération déterministes, de checkpointing et d’interruptions human-in-the-loop, rien d’autre dans cette catégorie ne vous donne le même niveau de contrôle.
LangSmith (la couche d’observabilité de LangChain) s’intègre étroitement et couvre bien le gap de tracing. Un support commercial est disponible. Le projet est activement maintenu. Ce sont des prérequis fondamentaux, et LangGraph les satisfait. Pour une analyse approfondie, voir CrewAI vs LangGraph : choisir le bon framework d’agents.
Idéal pour : L’orchestration complexe, les workflows financiers ou de conformité, les systèmes nécessitant des pistes d’audit, les équipes à l’aise avec Python et les primitives de graphe.
Pas le bon choix quand : Vous déployez une simple boucle de tâches à agent unique, ou que votre équipe n’est pas prête à assumer la charge cognitive du modèle graphe.
CrewAI
CrewAI a rendu la coordination multi-agent accessible. L’abstraction rôle/tâche/crew correspond naturellement à la façon dont les non-techniciens pensent au travail (« nous avons un chercheur, un rédacteur et un éditeur ») — ce qui signifie que le framework comble le fossé entre les exigences produit et l’implémentation de manière inhabituellement efficace.
Il abstrait davantage que LangGraph, ce qui est à la fois un atout et un risque. La plupart des workflows clients s’inscrivent dans le modèle de CrewAI sans friction. Quand ce n’est pas le cas — quand vous avez besoin d’une gestion précise de l’état, de flux non linéaires ou de backends mémoire personnalisés — vous sentirez le plafond. CrewAI a ajouté des fonctionnalités enterprise et poursuit un développement actif, le plafond s’est donc relevé, mais il existe toujours.
Idéal pour : Les workflows multi-agents avec une séparation claire des rôles, les équipes qui veulent avancer vite sur une structure de tâches bien définie, les pipelines de contenu, les tâches de recherche et de synthèse.
Pas le bon choix quand : Le workflow est très stateful, les exceptions sont fréquentes, ou vous avez besoin d’un contrôle fin sur ce qui se passe entre les étapes.
OpenAI Agents SDK
Publié début 2025, l’OpenAI Agents SDK (anciennement connu en preview sous le nom de « Swarm ») est l’option la plus légère orientée production de cette liste. Les primitives sont minimales : agents, handoffs et outils. Ce minimalisme est un choix délibéré, et pour les déploiements simples, il fonctionne bien.
L’aspect à garder en tête mérite d’être nommé : le SDK est optimisé pour les modèles OpenAI, et les intégrations les plus étroites — tracing, outils intégrés, guardrails — sont natives OpenAI. Utiliser des modèles tiers est techniquement possible, mais on perd la plupart de ces capacités natives. C’est une contrainte d’écosystème plutôt qu’un lock-in technique dur, mais c’est une vraie considération stratégique pour tout client réfléchissant à la flexibilité de fournisseur à long terme.
Idéal pour : Les équipes déjà engagées dans le stack OpenAI, les projets avec un périmètre clair et délimité, le prototypage rapide où la simplicité de l’abstraction est un vrai atout.
Pas le bon choix quand : La flexibilité de fournisseur de modèle est importante, ou vous construisez quelque chose d’assez complexe pour que les primitives minimales doivent être réinventées au niveau applicatif.
Mastra
Mastra est un nouvel entrant à surveiller. Il est TypeScript-natif, ce qui compte pour les équipes qui construisent une logique d’agent proche d’un backend Node.js ou Next.js — cela supprime le problème de bridging Python qui crée de la complexité opérationnelle dans les stacks mixtes. Il propose des primitives de workflow sensées, un support intégré pour l’exécution durable et un ensemble croissant d’intégrations.
Nous l’avons utilisé sur des projets où l’équipe frontend devait posséder la logique des agents sans changer de contexte vers Python. L’expérience était sensiblement meilleure que les alternatives. L’écosystème est encore en maturation, donc le profil de risque est plus élevé que LangGraph ou CrewAI pour les systèmes critiques. Mais pour les équipes TypeScript-first, Mastra mérite une évaluation sérieuse.
Idéal pour : Les stacks Node.js/TypeScript, les équipes qui veulent éviter les déploiements polyglottes, les agents adjacents aux applications web.
Frameworks évalués et écartés (pour l’instant)
AutoGen / AG2. La contribution de Microsoft à l’écosystème est genuinement intéressante pour les cas d’usage de recherche et les simulations multi-agents complexes. Dans le travail client en production, le modèle basé sur la conversation ajoute de la friction : on raisonne sur des agents qui échangent des messages plutôt qu’exécutent des étapes discrètes, ce qui rend le debugging plus difficile et le contrôle des coûts moins prévisible. Le projet a également traversé un fork et un changement de nom significatifs (AG2) qui ont introduit une fragmentation dans la communauté. Note : à partir d’octobre 2025, Microsoft a placé AutoGen en mode maintenance — corrections de bugs et patches de sécurité uniquement, pas de nouvelles fonctionnalités — et a lancé le Microsoft Agent Framework (fusion d’AutoGen et de Semantic Kernel) comme successeur en production, avec un GA 1.0 en avril 2026. Les équipes évaluant l’écosystème Microsoft devraient examiner l’Agent Framework plutôt qu’AutoGen ; le fork communautaire AG2 continue indépendamment sous ag2ai.
smolagents. Le framework de Hugging Face est délibérément minimal et privilégie l’exécution de code comme mécanisme principal d’utilisation des outils. C’est un choix de conception fondé — les agents code-first sont puissants. Mais le minimalisme signifie que vous assemblez vous-même votre histoire d’observabilité, de mémoire et de déploiement depuis zéro. Pour les équipes qui savent ce qu’elles font et veulent éviter l’overhead du framework, c’est une option légitime. Pour la plupart des missions clients, le coût d’assemblage n’en vaut pas la peine.
VoltAgent. TypeScript-first comme Mastra, mais avec des compromis différents. VoltAgent est à un stade plus précoce et a un écosystème plus petit. À surveiller, notamment pour les équipes évaluant des options TypeScript. Pas là où nous placerions notre premier pari en production aujourd’hui.
Une matrice de décision pour les praticiens
| Framework | Langage | Granularité de contrôle | Multi-Agent | Observabilité | Maturité en production |
|---|---|---|---|---|---|
| LangGraph | Python | Très élevée | Premier niveau | Forte (LangSmith) | Élevée |
| CrewAI | Python | Moyenne | Premier niveau | Modérée | Élevée |
| OpenAI Agents SDK | Python / TypeScript | Basse–Moyenne | Via handoffs | Native OpenAI | Moyenne–Élevée |
| Mastra | TypeScript | Moyenne | Supporté | En croissance | Moyenne |
| AutoGen/AG2 | Python | Élevée | Premier niveau | Faible en production | Moyenne |
Ce que cela signifie pour votre projet
Le choix du framework n’est pas la partie la plus difficile de la construction d’un système d’agents IA. Les questions plus difficiles viennent en amont : quel problème résolvez-vous vraiment ? À quoi ressemble le succès en production ? Quel est le mode de défaillance contre lequel vous devez le plus vous prémunir ?
La décision build vs buy influence également ce choix. Les équipes adoptant des frameworks open source choisissent implicitement d’assumer la maintenance, le versioning et les cycles de mise à jour. C’est le bon choix dans de nombreuses situations — notamment quand les exigences de personnalisation sont élevées, ou quand vous devez maintenir les données sensibles dans une infrastructure contrôlée. Mais c’est un choix qui doit être fait explicitement, pas par défaut.
Surtout : le choix du framework doit suivre l’architecture, pas la précéder. Si vous choisissez LangGraph avant d’avoir cartographié les transitions d’état de votre agent, vous sur-ingéniérerez. Si vous choisissez CrewAI sans vérifier si votre workflow s’adapte à l’abstraction rôle/tâche, vous atteindrez rapidement le plafond. Un test de production-readiness appliqué avant de vous engager évite une réécriture conséquente.
La rigueur d’ingénierie, des interfaces d’outils bien définies, l’observabilité dès le premier jour et un périmètre réaliste — ce sont les facteurs qui séparent les systèmes d’agents fiables de ceux qui nécessitent une supervision constante. Le framework est rarement la variable déterminante.
Parlez à une équipe qui a déjà fait ces choix
Si vous évaluez des frameworks agents IA open source pour un vrai projet — pas un prototype, mais quelque chose qui doit fonctionner de manière fiable dans six mois — la question du framework mérite une vraie conversation. La bonne réponse dépend de votre stack, de votre équipe, de votre environnement de données et de ce que vous cherchez réellement à automatiser.
Nous travaillons avec des entreprises suisses et européennes pour concevoir et développer des agents IA sur mesure en utilisant les frameworks les mieux adaptés à chaque situation. Cela signifie être honnête quand un framework est le mauvais outil, et tout aussi honnête quand une approche plus légère sert mieux qu’un développement custom.
Réservez un appel de 30 minutes avec notre équipe pour examiner votre cas d’usage, les contraintes techniques et le framework — ou la combinaison — que nous recommanderions réellement. Pas de pitch deck, pas de conseils génériques. Juste une conversation directe sur votre situation spécifique.
Vous pouvez aussi en apprendre davantage sur notre approche du développement d’agents IA chez Orange ITS.