BeeAI Framework : construire des agents multi-agents en Python et TypeScript
Build production-ready AI agents in both Python and Typescript.
En bref
- De quoi s’agit-il ?
- BeeAI Framework propose une boîte à outils Apache-2.0 pour écrire des agents et des systèmes multi-agents dans deux langages. Le point à vérifier avant d'adopter : la maturité très inégale entre les deux bibliothèques.
- À qui s’adresse-t-il ?
- Adoptez BeeAI Framework si vous écrivez des agents en Python et voulez un socle Apache-2.0 avec un backend LLM unifié et des intégrations MCP déjà câblées ; évitez-le si votre code est en TypeScript et que vous cherchez une parité de fonctionnalités avec le Python. Avant de vous engager, vérifiez la version publiée de la bibliothèque TypeScript face à celle du Python, et testez le Requirement Agent sur les modèles que vous utilisez réellement.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 7 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Deux bibliothèques, un seul dépôt, deux niveaux de maturité
Le dépôt i-am-bee/beeai-framework héberge deux bibliothèques distinctes, une en Python et une en TypeScript, sous licence Apache-2.0. Le README les présente comme deux chemins équivalents pour construire des systèmes multi-agents. Les dates de publication racontent autre chose. La dernière version Python listée est python_v0.1.83, datée du 19 août 2026. Côté TypeScript, la plus récente est typescript_v0.1.30, du 24 juillet 2026. Le journal des mises à jour du README est presque entièrement dominé par des entrées TypeScript pour l'année 2024, puis bascule vers le Python à partir de février 2025. Autrement dit, le TypeScript a ouvert la voie, et le Python est devenu le centre de gravité. Si vous hésitez entre les deux, ce déséquilibre documenté est le premier élément à intégrer, avant même de regarder les fonctionnalités.
Ce que le Requirement Agent change par rapport à un agent classique
La fonctionnalité mise en avant dans le tableau du README est le Requirement Agent, décrit comme un moyen d'obtenir un comportement prévisible et contrôlé d'un modèle à l'autre en fixant des règles que l'agent doit respecter. C'est une réponse à un problème concret : un agent qui raisonne librement produit des trajectoires différentes selon le modèle branché derrière, ce qui rend les tests instables et les coûts imprévisibles. En imposant des règles, on déplace une partie de la logique hors du prompt et hors du modèle. Le README qualifie cette brique d'expérimentale dans le journal des mises à jour de juin 2025. Il faut donc la traiter comme telle : utile pour cadrer un agent, mais pas comme une garantie de déterminisme. La documentation ne précise pas, dans les éléments fournis, comment ces règles sont exprimées ni ce qui se passe lorsqu'un modèle les ignore.
Le flux de travail : backend, outils, agents
L'architecture visible dans le README s'organise en couches. Le module Backend expose des interfaces unifiées vers les fournisseurs de modèles, avec un exemple concret de fournisseurs multiples listés dans les notes de version. Les Tools étendent les agents, et le README mentionne une intégration MCP via une clé de configuration documentée sous modules/tools#mcp-tool, ainsi qu'une intégration ACP. Les Workflows, introduits en janvier 2025 côté TypeScript, servent à assembler plusieurs agents. Les Agents, enfin, raisonnent et agissent au-dessus de ces briques. La donnée circule donc du backend vers l'agent, qui appelle des outils, le tout pouvant être enchaîné dans un workflow. Ce découpage est classique et lisible. Sa limite est qu'il reste décrit par renvois vers la documentation en ligne : le README ne montre pas de graphe d'exécution ni de contrat d'interface entre ces couches.
Démarrer : deux starters plutôt qu'une installation manuelle
Le README oriente vers deux dépôts de démarrage, beeai-framework-py-starter pour Python et beeai-framework-ts-starter pour TypeScript, présentés comme le moyen d'aller vite. C'est une recommandation explicite du projet, et elle évite de deviner la structure d'un projet fonctionnel. Le README renvoie aussi à un guide de démarrage pour l'installation, sans inclure les commandes exactes dans l'extrait disponible. Deux éléments de configuration apparaissent nommément : l'intégration MCP, documentée à l'adresse framework.beeai.dev/modules/tools#mcp-tool, et l'intégration ACP. Pour le reste, il faut consulter la documentation du site. Un point mérite attention : le projet a été publié en alpha côté Python en février 2025, et l'ensemble des versions listées reste en 0.1.x. Une dépendance en 0.1.x peut casser entre deux versions mineures, ce qui impose de figer les versions dans votre gestionnaire de paquets.
Le cas où ce n'est pas le bon outil
Si votre base de code est en TypeScript et que vous attendez la même richesse fonctionnelle que côté Python, le dépôt ne le promet pas. Le journal des mises à jour montre que les nouveautés récentes, comme le Requirement Agent, sont annoncées pour le Python uniquement. La bibliothèque TypeScript existe, elle est maintenue, mais son rythme de publication est plus lent et sa version plus basse. Un second cas défavorable : si vous cherchez un framework avec des garanties fortes de reproductibilité, le Requirement Agent est encore marqué expérimental, et le README ne fournit aucun élément sur la manière dont les règles sont validées à l'exécution. Enfin, le projet est rattaché à la LF AI & Data et à l'écosystème BeeAI : si vous cherchez une solution totalement indépendante d'un fournisseur ou d'une fondation, ce n'est pas ce que vous trouverez ici.
Face à LangGraph et aux frameworks de graphes d'agents
L'alternative la plus directe est un framework qui modélise explicitement l'orchestration comme un graphe d'états, LangGraph étant l'exemple le plus connu. La différence d'approche est nette. BeeAI Framework propose des Workflows comme un module parmi d'autres, aux côtés d'un backend unifié et d'un ensemble d'outils, avec l'objectif affiché d'un comportement contrôlé par des règles. Un framework de graphe place l'orchestration au centre et vous fait décrire les transitions, les points d'arrêt et la persistance d'état comme des objets de premier ordre. Le choix dépend donc de ce que vous voulez contrôler : si votre difficulté principale est la variabilité des modèles, l'approche par règles du Requirement Agent vise directement ce problème ; si votre difficulté est la reprise après erreur et l'état long, un modèle de graphe sera plus explicite. Le README ne fournit pas de mécanisme de persistance d'état documenté dans l'extrait disponible, ce qui est un argument en faveur du second dans les cas où la reprise compte.
Coût de maintenance et implications de licence
Le projet est publié sous Apache-2.0, une licence permissive qui autorise l'usage commercial, la modification et la redistribution, à condition de conserver les mentions de licence et d'état des modifications, et qui inclut une concession de brevet. Je ne donne pas de conseil juridique : lisez le texte de la licence et faites-le valider si votre contexte l'exige. Sur la maintenance, deux signaux factuels : le dépôt n'est pas archivé et la dernière poussée date du 8 septembre 2026, soit un rythme actif. Mais les numéros de version restent en 0.1.x des deux côtés, ce qui signifie que l'API n'est pas stabilisée. Concrètement, prévoyez de relire les notes de version à chaque montée de version mineure et de figer vos dépendances. Le coût réel n'est pas l'installation, c'est le suivi des changements d'API dans une bibliothèque qui n'a pas encore atteint 1.0.
Conclusion éditoriale
Adoptez BeeAI Framework si vous écrivez des agents en Python et voulez un socle Apache-2.0 avec un backend LLM unifié et des intégrations MCP déjà câblées ; évitez-le si votre code est en TypeScript et que vous cherchez une parité de fonctionnalités avec le Python. Avant de vous engager, vérifiez la version publiée de la bibliothèque TypeScript face à celle du Python, et testez le Requirement Agent sur les modèles que vous utilisez réellement.
Notes de la communauté