hariri.ch
Prenez contact

Développement Intelligence artificielle

OpenExecutive : ce que propose vraiment ce projet open source de « direction virtuelle » multi-agents

7 min de lecture

Illustration conceptuelle d’un orchestrateur central relié à huit agents spécialisés dans une composition évoquant une équipe de direction virtuelle.

Une première version publique centrée sur un exécutif IA unifié

OpenExecutive a publié sa version 0.1.0 le 2026-06-30, présentée comme sa première version publique. Le dépôt décrit le projet comme une équipe de direction virtuelle propulsée par l’IA : une persona exécutive unique s’appuie sur huit agents spécialistes.

Le socle LLM indiqué dans le dépôt est l’API Anthropic Claude. Par défaut, l’Executive et la plupart des spécialistes utilisent claude-sonnet-4-6. Pour les tâches de raisonnement plus poussées, le projet réserve claude-opus-4-7 à certains rôles : CSO, CFO, GC et Board, avec extended thinking. L’orchestrateur exécutif lui-même est aussi associé à claude-sonnet-4-6.

Concrètement, l’idée n’est pas seulement de répondre à des questions. Le README met en avant un système capable de conserver une mémoire épisodique des décisions et initiatives passées entre plusieurs sessions, ainsi qu’un planificateur intégré chargé de faire remonter des suivis et des actions sensibles au temps.

Une architecture en deux couches : orchestration et spécialistes

La version initiale ajoute un backend Python dans packages/core avec plusieurs briques : service FastAPI, orchestrateur, agents spécialistes, couche RAG adossée à ChromaDB, CLI et mécanisme de cache de prompts. La pile technique mentionne Python 3.11 avec FastAPI côté backend, et Next.js 15 avec App Router et Tailwind côté interface web.

Le fonctionnement décrit dans le dépôt repose sur un appel à des spécialistes qui vont chacun récupérer le contexte pertinent depuis ChromaDB. Le système utilise deux couches de récupération à chaque appel spécialiste :

  • une base de connaissances intégrée en Markdown, décrite comme de niveau MBA, stockée dans knowledge/builtin/ et injectée dans ChromaDB au démarrage ;
  • des documents d’entreprise téléversés, découpés puis stockés dans une collection séparée nommée company_docs.

Cette séparation est importante pour les équipes techniques : elle distingue le savoir générique embarqué par le projet du contexte propre à l’organisation. Le dépôt précise aussi que le magasin vectoriel est un ChromaDB local embarqué, ce qui simplifie les premiers tests mais influence directement les choix de déploiement.

Mémoire, scheduler et contraintes d’exploitation

La partie la plus intéressante d’OpenExecutive n’est sans doute pas l’interface, mais sa tentative de transformer un assistant conversationnel en système de suivi. Après chaque réponse, un passage en arrière-plan avec claude-haiku-4-5 extrait les décisions clés, les initiatives et les conseils pour les enregistrer dans SQLite. Cette base sert de mémoire épisodique.

Le scheduler intégré s’appuie, selon le README, sur une stratégie UPDATE … RETURNING pour éviter qu’une même action soit déclenchée deux fois. Ce détail technique a une conséquence opérationnelle majeure : l’API doit tourner en instance unique. Le dépôt avertit explicitement qu’il ne faut pas faire de montée en charge horizontale sans d’abord encadrer ce scheduler.

Cette contrainte se retrouve dans la configuration de déploiement. La topologie Fly.io mentionne un volume persistant executive_data monté sur /data pour l’application API, et le README indique que max_machines_running = 1 est défini dans les fichiers fly.api.toml et fly.api.qa.toml, avec la consigne de ne pas le modifier.

Autrement dit, OpenExecutive n’est pas conçu, dans son état actuel, comme un service stateless que l’on réplique librement. Sa mémoire SQLite, son ChromaDB local et son ordonnanceur embarqué favorisent une architecture simple à lancer, mais plus délicate à distribuer à grande échelle.

Déploiement, intégrations et parcours de mise en route

La version 0.1.0 inclut une configuration de déploiement pour Docker et Fly.io, ainsi que des intégrations optionnelles pour Slack, Discord et l’email. En local, l’API écoute sur le port 8000 et l’interface sur 3000.

Le premier lancement demande Python 3.11+ et Node 22+. Le README précise aussi que le premier démarrage télécharge un petit modèle d’embedding d’environ 90 Mo afin de construire l’index vectoriel local.

Le bot Discord, lorsqu’un DISCORD_BOT_TOKEN est défini, démarre dans le cycle de vie FastAPI. Le dépôt indique qu’il est embarqué dans le même processus API que le poller email, le scheduler et le resumer, afin de partager la même base SQLite et le même magasin ChromaDB sous /data en production.

Côté environnements, le projet décrit deux cibles Fly.io séparées par branche :

  • dev, déclenché par push ou merge sur main, qui déploie openexec-api-dev et openexec-ui-dev via .github/workflows/deploy.yml ;
  • qa, déclenché par push ou merge sur qa, qui déploie openexec-api-qa et openexec-ui-qa via .github/workflows/deploy-qa.yml.

Pour l’accès, l’interface déployée est protégée par une connexion Google avec liste blanche d’emails, tandis que l’API publique est protégée par un en-tête secret partagé entre le proxy UI et le backend FastAPI.

Performance, routage des modèles et options hors Anthropic

OpenExecutive reste fortement structuré autour d’Anthropic, mais le dépôt prévoit plusieurs chemins de routage. Le modèle par défaut pour le routage d’intention est claude-haiku-4-5-20251001. Le README précise aussi qu’au moins un fournisseur doit être configuré, faute de quoi l’application refuse de démarrer.

Le design du cache de prompts fait partie des optimisations mises en avant. Le prompt système est découpé de façon à mettre en cache séparément la persona Executive, le profil d’entreprise et l’index de connaissances. Le dépôt indique qu’après les premiers tours, cela peut atteindre jusqu’à 85 % de taux de hit.

Le projet peut aussi passer par OpenRouter pour débloquer des modèles non Anthropic agent par agent dans l’interface Council. Et il peut fonctionner avec un serveur local compatible OpenAI, notamment Ollama, LM Studio, vLLM ou llama.cpp, à la place de l’API Anthropic ou en complément.

Mais cette flexibilité a des limites clairement documentées : avec des modèles locaux, la recherche web côté serveur, le cache de prompts Anthropic et l’extended thinking sont automatiquement désactivés, faute d’équivalent local.

Qualité logicielle, évaluation et confidentialité : des signaux utiles pour les équipes

Pour un projet en 0.1.0, OpenExecutive arrive avec un outillage open source relativement complet : licence Apache 2.0, guide de contribution, code de conduite, politique de sécurité, modèles d’issues et de pull requests, ainsi qu’une CI.

Le dépôt mentionne aussi un système d’évaluation avec 29 scénarios couvrant les 8 domaines, notés par claude-opus-4-7 dans un rôle de juge LLM. La barrière CI exige une moyenne d’au moins 3,5 sur 5, et une pull request échoue si une dimension baisse de plus de 10 % par rapport à main. Pour des développeurs, c’est un indicateur utile : le projet ne se contente pas d’une démo, il essaie d’encadrer les régressions.

Sur la confidentialité, le README précise que tout le contenu du répertoire company/ est ignoré par Git : profil d’entreprise en YAML, documents téléversés et magasin vectoriel ChromaDB. Cela ne constitue pas à lui seul une garantie de sécurité globale, mais c’est un garde-fou pratique pour éviter de versionner accidentellement des données internes.

Au final, OpenExecutive ressemble moins à un simple chatbot qu’à une base de travail pour expérimenter un système multi-agents orienté décision, mémoire et suivi. Sa proposition est techniquement cohérente, mais elle s’accompagne de compromis nets : dépendance forte à l’orchestration centralisée, stockage local persistant et impossibilité assumée de scaler horizontalement sans revoir le scheduler.

Pour les équipes d’ingénierie, l’intérêt est donc double : observer une implémentation concrète d’un « executive system » multi-agents, et identifier très tôt les points qui devront évoluer si l’objectif passe du prototype open source à un service de production plus distribué.

À retenir

  • OpenExecutive 0.1.0, publié le 30 juin 2026, est la première version publique du projet.
  • Le système repose sur une persona exécutive unique orchestrant huit agents spécialistes, principalement via l’API Anthropic Claude.
  • L’architecture combine FastAPI, Next.js 15, ChromaDB pour la RAG et SQLite pour la mémoire épisodique.
  • Le scheduler intégré impose une exploitation en instance unique ; le dépôt déconseille explicitement le scaling horizontal sans adaptation.
  • Le projet prévoit Docker, Fly.io, Slack, Discord, email, ainsi qu’un cadre open source complet avec CI et évaluation automatisée.

Publié par :

Sources