II-Agent : un agent open source qui veut couvrir du prompt au livrable
II-Agent: a new open-source framework to build and deploy intelligent agents
En bref
- De quoi s’agit-il ?
- II-Agent est un framework Python sous Apache-2.0 qui assemble backend, frontend, Postgres, Redis et MinIO pour produire sites, applications mobiles, slides et documents. La promesse est large, la contrepartie est un socle d'infrastructure à faire tourner soi-même.
- À qui s’adresse-t-il ?
- II-Agent convient aux équipes qui veulent un agent auto-hébergé produisant des artefacts concrets (sites, slides, documents) et qui acceptent d'exploiter elles-mêmes Postgres, Redis et MinIO. À éviter si vous cherchez une bibliothèque légère à intégrer dans un service existant : le dépôt impose une pile complète.
- 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 30 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
Le problème visé : produire un livrable, pas répondre à une question
La plupart des frameworks d'agents s'arrêtent à l'appel d'outils et à la boucle de raisonnement. II-Agent prend le problème à l'autre bout : le README énumère des sorties finies, application mobile, application web, storybook illustré, jeu de slides, extraction et création de PDF, tableaux Excel avec formules et graphiques, édition Word et PowerPoint. Le projet se présente comme un agent « built for real work », désormais sorti de bêta, et vise explicitement le développeur seul, l'équipe de recherche et l'entreprise qui construit ses outils internes. Le public visé n'est donc pas celui qui veut brancher un LLM sur trois fonctions, mais celui qui veut déléguer une chaîne de production entière.
Le mode Plan va dans le même sens : la planification visuelle intervient avant la construction, ce qui suppose que l'agent manipule un projet persistant et pas une simple conversation. L'édition en direct sur les sites, les slides et les storybooks confirme cette orientation : il faut un état de projet consultable et modifiable, donc un stockage. C'est ce qui explique la lourdeur de l'installation décrite plus bas, et c'est aussi ce qui la justifie.
Ce que make dev-all démarre réellement
La commande centrale du README est make dev-all. Elle lance quatre services d'infrastructure en plus du code applicatif : le backend sur le port 8000, le frontend sur le port 1420, PostgreSQL sur 5432, Redis sur 6379 et MinIO sur 9001, ce dernier étant décrit comme un stockage compatible S3 avec les identifiants minioadmin/minioadmin. Une variante make frontend-dev fait écouter le frontend sur le port 5173, ce qui suggère deux modes de développement selon que le service est lancé seul ou avec le reste de la pile.
Cette répartition indique une architecture classique en trois couches. Le backend Python porte la logique d'agent et les appels aux modèles. PostgreSQL conserve l'état, ce que confirme l'existence de make db-migrate pour exécuter les migrations. Redis sert de courtier ou de cache pour les tâches longues, typiquement la génération de vidéos, de sites ou de slides. MinIO stocke les fichiers produits. Le frontend, construit avec Node et npm, consomme l'API du backend.
Rien dans le matériel fourni ne décrit le format exact des messages échangés entre ces composants, ni le schéma des tables. Toute affirmation sur le protocole interne serait une supposition. Ce qu'on peut dire, c'est que la présence de migrations implique un schéma versionné, donc des mises à niveau à gérer lors des changements de version.
Configurer les modèles : deux chemins, une seule clé
II-Agent fonctionne en BYOK, comprenez que vous fournissez vos propres clés d'API. Le README propose deux méthodes. La première consiste à placer un JSON directement dans .env sous la clé MODEL_CONFIGS, avec un exemple explicite : un tableau d'objets contenant model_id, provider, api_key, display_name et is_default. La seconde consiste à copier model_configs.example.yaml vers model_configs.yaml, à y renseigner les clés, puis à définir MODEL_CONFIGS_FILE=model_configs.yaml dans .env.
Le fichier d'exemple couvrirait, selon le README, Vertex AI, Azure et des modèles auto-hébergés, en plus des fournisseurs directs. Le tableau des fournisseurs cite OpenAI, Anthropic et Google, avec des identifiants de modèles tels que gpt-5.4, claude-opus-4-6 et gemini-3.1-pro-preview. Ces noms proviennent du README et je les rapporte tels quels.
Le choix entre JSON inline et YAML n'est pas anodin. Le JSON dans .env convient à un modèle unique et à un test rapide. Le YAML devient nécessaire dès qu'on veut plusieurs modèles, des points d'accès Vertex ou Azure, ou des modèles locaux, parce qu'un tableau JSON multiligne dans un fichier .env devient vite illisible. Le README mentionne d'ailleurs le changement de fournisseur en cours de conversation dans la section Chat, ce qui suppose plusieurs entrées configurées simultanément.
make setup, make stack : deux niveaux d'engagement
L'installation minimale tient en quatre étapes documentées : cloner le dépôt, lancer make setup qui crée les fichiers .env et installe les dépendances, éditer .env pour y mettre au moins un fournisseur LLM, puis lancer make dev-all. Les prérequis sont Docker, uv (installé via le script officiel astral.sh) et Node.js avec npm.
Une seconde voie évite Python et Node en local : copier docker/.stack.env.example vers docker/.stack.env, renseigner les identifiants, puis make stack. Les commandes make stack-build, make stack-down et make stack-logs complètent l'ensemble. C'est la voie à privilégier sur une machine de CI ou un serveur, parce qu'elle ne dépend pas des versions locales de Python et Node.
Les fichiers de configuration sont au nombre de trois : .env pour le backend (base de données, Redis, stockage, authentification, clés LLM), frontend/.env pour l'URL d'API, l'OAuth Google et le thème, et model_configs.yaml pour les modèles. Le README liste aussi make lint, make format et make test, ce qui indique une chaîne de qualité outillée côté backend et frontend.
Un point pratique : make setup crée les .env à partir des .env.example. Si vous relancez la commande après avoir rempli vos clés, vérifiez qu'elle n'écrase pas votre configuration. Le README ne précise pas ce comportement.
La limite structurelle : une pile à exploiter, pas une bibliothèque
Le coût réel de II-Agent n'est pas dans le code d'agent, il est dans l'exploitation. Postgres, Redis et MinIO doivent tourner, être sauvegardés et être mis à jour. Les migrations de base de données doivent être appliquées à chaque montée de version, et le rythme des publications est soutenu : v0.2 en juin 2025, v0.3 en juillet, v0.4 fin juillet, avec un dernier push sur main en août 2026. Trois versions en deux mois au moment de la sortie de bêta, cela signifie que le schéma a des chances de bouger.
Deuxième limite, l'authentification. Le fichier frontend/.env gère l'OAuth Google. Le README ne décrit pas d'autre mécanisme d'authentification ni de gestion fine des rôles. Pour un déploiement multi-utilisateurs en entreprise, c'est un point à vérifier avant de s'engager, parce qu'un agent qui exécute du code et écrit dans un stockage S3 partagé n'a pas les mêmes exigences d'isolation qu'un simple chatbot.
Troisième limite, l'absence de chiffres. Le README affirme une exécution « significantly improved speed compared to earlier beta iterations » sans donner de mesure. Aucun benchmark reproductible n'est fourni dans le matériel dont je dispose, hormis un lien vers une page GAIA externe dont je ne peux rien dire. Traitez donc les affirmations de performance comme non vérifiées.
Enfin, le périmètre fonctionnel est très large. Un projet qui couvre à la fois la génération de vidéos, l'édition de Word, les slides et le développement d'applications mobiles ne peut pas être également profond partout. La question à se poser n'est pas « est-ce que ça fait tout ? » mais « est-ce que la partie qui m'intéresse est la partie mûre ? ».
Face à un framework d'orchestration généraliste
L'alternative la plus directe n'est pas un autre agent clé en main, c'est un framework d'orchestration comme LangGraph ou l'API Agents de OpenAI, dans lequel vous écrivez vous-même la boucle, les outils et la persistance. La différence d'approche est nette. Ces frameworks vous donnent des primitives : graphe d'états, points de contrôle, définitions d'outils. Vous choisissez votre stockage, votre file de tâches, votre couche d'authentification. II-Agent vous donne un produit assemblé : les migrations Postgres, le stockage MinIO, le frontend, les intégrations Gmail, Slack, GitHub, Notion, Google Calendar, Discord, Dropbox et Canva sont déjà là.
Le compromis est inversé. Avec un framework généraliste, vous passez du temps à construire l'infrastructure et vous gardez le contrôle total sur chaque couche. Avec II-Agent, vous démarrez plus vite sur les cas d'usage couverts, mais vous héritez d'un schéma de base de données, d'un modèle d'authentification et d'un rythme de publication que vous ne décidez pas.
Il existe une troisième voie, plus étroite : un outil spécialisé sur une seule sortie, par exemple un générateur de slides ou un convertisseur de documents. Pour un besoin unique, cette option reste plus simple à opérer qu'un agent généraliste accompagné de quatre services. II-Agent n'a d'intérêt que si vous comptez utiliser plusieurs de ses domaines, ou si vous voulez forker la logique d'agent elle-même.
Licence, maintenance et ce qu'il faut vérifier avant de forker
II-Agent est publié sous Apache-2.0, ce qui autorise l'usage commercial, la modification et la redistribution, à condition de conserver les mentions de copyright et le fichier de licence, et de signaler les fichiers modifiés. La licence inclut une concession de brevet. Je ne suis pas juriste et ce paragraphe ne constitue pas un avis juridique : faites relire le texte de la licence si vous redistribuez le projet dans un produit commercial.
Un point mérite attention : le dépôt ne contient pas de politique de contribution ni de gouvernance décrite dans le matériel fourni. Le projet est porté par Intelligent-Internet, qui exploite aussi une application web hébergée sur agent.ii.inc. Autrement dit, il existe une version SaaS du même produit. Cela ne remet pas en cause la licence, mais cela signifie que la feuille de route peut suivre les besoins du service hébergé avant ceux des utilisateurs auto-hébergés.
Le coût de mise à jour se concentre sur trois postes. Les migrations de base de données, via make db-migrate, à exécuter à chaque montée de version. Les images Docker, à reconstruire avec make stack-build quand les dépendances Python ou Node changent. Et la configuration des modèles, qui peut nécessiter une modification de model_configs.yaml si un identifiant de fournisseur évolue.
Avant de vous engager, testez la chaîne complète sur une machine vierge avec make stack, puis vérifiez deux choses : que votre fournisseur LLM figure bien dans model_configs.example.yaml avec les bons champs, et que le service d'authentification correspond à votre politique d'accès. Si l'un des deux ne colle pas, vous le découvrirez après avoir monté Postgres, Redis et MinIO, pas avant.
Conclusion éditoriale
II-Agent convient aux équipes qui veulent un agent auto-hébergé produisant des artefacts concrets (sites, slides, documents) et qui acceptent d'exploiter elles-mêmes Postgres, Redis et MinIO. À éviter si vous cherchez une bibliothèque légère à intégrer dans un service existant : le dépôt impose une pile complète. Avant d'adopter, vérifiez deux points précis : que le fichier model_configs.example.yaml couvre bien le fournisseur que vous utilisez, et que make db-migrate passe sur votre version de PostgreSQL.
Notes de la communauté