OpenExecutive : huit agents spécialisés derrière une seule voix de direction

Le problème : une seule voix pour huit domaines

Interroger un modèle de langue sur une décision d'entreprise donne souvent une réponse plate, sans point de vue tranché. Empiler huit assistants séparés produit l'effet inverse : l'utilisateur doit savoir lequel consulter, et les réponses se contredisent d'un onglet à l'autre. OpenExecutive prend le parti intermédiaire. L'utilisateur ne parle qu'à un orchestrateur, qui décide en interne quels spécialistes appeler. Le README est explicite sur ce point : l'architecture interne des agents n'est jamais exposée à l'utilisateur.

Le découpage couvre huit rôles nommés dans la documentation : Chief Strategy Officer, Chief Financial Officer, Chief HR/People Officer, General Counsel, Chief Operating Officer, Chief Marketing Officer, Chief Product Officer et Board Communications Director. Chacun a un périmètre annoncé dans le README, par exemple le CFO pour la modélisation financière et les levées de fonds, le General Counsel pour les contrats et les bases du droit du travail. C'est un public de fondateurs et de petites équipes dirigeantes, pas de grandes directions juridiques.

Le positionnement mérite d'être noté tel quel : le README parle d'un conseiller senior avec des connaissances de niveau MBA Harvard, personnalisé pour votre entreprise. Cette formulation vient du projet lui-même et n'est étayée par aucune évaluation publiée dans le matériel fourni.

Le flux réel : orchestrateur, appels parallèles, synthèse

Le schéma du README décrit une chaîne courte. Un message utilisateur arrive dans l'Executive Orchestrator, propulsé par claude-sonnet-5. L'orchestrateur utilise le tool use pour lancer des appels parallèles vers les spécialistes concernés. Chaque spécialiste interroge ChromaDB, récupère du contexte, puis renvoie sa contribution. L'orchestrateur assemble le tout en une réponse unique.

La partie intéressante est la double couche de connaissance. Le premier niveau est un corpus Markdown versionné dans le dépôt, sous knowledge/builtin/, injecté dans ChromaDB au démarrage. Le second est constitué des documents d'entreprise téléversés par l'utilisateur, découpés en morceaux et stockés dans une collection distincte nommée company_docs. Deux collections, deux origines, un seul pipeline de récupération par appel de spécialiste.

Un détail d'implémentation qui a des conséquences pratiques : le contexte RAG est injecté dans le tour utilisateur, jamais dans le prompt système mis en cache. C'est cohérent avec la stratégie de cache décrite plus loin, mais cela signifie que le volume de contexte récupéré pèse sur chaque requête envoyée, pas sur un préfixe réutilisable.

Le choix des modèles est différencié. claude-sonnet-5 sert par défaut à l'orchestrateur et à la plupart des spécialistes. claude-opus-5 est réservé au CSO, au CFO, au General Counsel et au Board, avec extended thinking activé. Le README ne donne aucune mesure de latence ou de coût pour ce partage.

Mémoire épisodique et planificateur proactif

Après chaque réponse, un passage en arrière-plan sur claude-haiku-4-5 extrait les décisions, initiatives et conseils marquants et les écrit dans SQLite. À la session suivante, un bloc <past_decisions> est injecté en ouverture. L'objectif annoncé est que l'Executive se souvienne de ce qu'il a recommandé le mois précédent. C'est une mémoire d'épisodes, pas une base de connaissances : elle stocke ce que le système a dit, pas ce qui est vrai.

Le planificateur fonctionne différemment. Un job runner intégré réclame les actions arrivées à échéance via UPDATE ... RETURNING, ce qui évite qu'un même job soit traité deux fois. Cette technique ne protège que contre la concurrence à l'intérieur d'une même base. Le README en tire la conclusion sans détour : l'API doit tourner en instance unique, et il ne faut pas la mettre à l'échelle horizontalement sans avoir d'abord verrouillé le planificateur.

C'est la contrainte opérationnelle la plus lourde du projet. Elle élimine d'emblée les déploiements multi-régions actifs-actifs et complique les stratégies de haute disponibilité. Le dépôt fournit d'ailleurs des configurations Fly.io distinctes pour l'API et l'UI, en développement et en QA (fly.api.toml, fly.ui.toml, fly.api.qa.toml, fly.ui.qa.toml), ainsi qu'un fly.honcho.toml présenté comme optionnel pour une application de mémoire Honcho.

Mise en route : make dev et variables d'environnement

Le parcours documenté tient en quelques commandes. On clone le dépôt, on copie .env.example vers .env, on y renseigne ANTHROPIC_API_KEY, puis on lance make dev. L'API écoute sur le port 8000, l'interface sur le port 3000, et l'URL d'entrée est http://localhost:3000.

La configuration est centralisée dans le .env à la racine. Le README précise que make dev et make docker chargent tous deux ce fichier, pour l'API comme pour l'UI, car Auth.js a besoin de AUTH_SECRET, AUTH_GOOGLE_ID et AUTH_GOOGLE_SECRET au moment de l'exécution. Un packages/ui/.env.local est également lu pour les clés propres à l'UI, mais en cas de doublon, c'est le .env racine qui gagne. Ce point de précédence est une source classique de confusion quand une clé semble ignorée.

Pour ceux qui n'utilisent pas make, le README donne la séquence manuelle : se placer dans packages/core, lancer uv sync, activer le venv avec source .venv/bin/activate, puis démarrer uvicorn openexecutive.api.main:app --reload --port 8000. Dans un second terminal, cd packages/ui puis npm install et npm run dev.

Le premier lancement est lent, et le README l'assume. uv sync tire ChromaDB et sentence-transformers avec PyTorch, et le premier démarrage télécharge un petit modèle d'embedding d'environ 90 Mo pour construire l'index vectoriel local. Il faut Python 3.11 ou plus et Node 22 ou plus. Les démarrages suivants sont rapides. Le dépôt contient aussi un workflow CI, un dossier evals avec des scénarios et un runner LLM-as-judge, et un dossier fixtures avec des profils de démonstration.

Le cache de prompt et ce qu'il impose au contenu dynamique

Le prompt système est structuré pour que trois éléments soient mis en cache séparément : la persona de l'Executive, le profil d'entreprise et l'index de connaissance. Le README annonce jusqu'à 85 % de taux de succès du cache après les premiers tours. Aucun contenu dynamique ne doit entrer dans un bloc mis en cache, sinon le cache est invalidé.

Cette règle explique la décision vue plus haut : le contexte RAG va dans le tour utilisateur. Si les documents récupérés étaient insérés dans le prompt système, chaque requête produirait un préfixe différent et le cache ne servirait à rien. La conception est donc cohérente, mais elle a un coût : tout ce qui varie, y compris les extraits de company_docs, est renvoyé à chaque appel. Le gain de cache porte sur la persona et le profil, pas sur la connaissance récupérée.

Le chiffre de 85 % est une affirmation du README. Aucun protocole de mesure, aucune trace, aucun rapport ne l'accompagne dans le matériel fourni. À prendre comme une intention de conception, pas comme un résultat vérifié.

Limites et cas où l'outil ne convient pas

La contrainte mono-instance est la première barrière. Toute équipe qui héberge déjà ses services derrière un équilibreur de charge avec plusieurs réplicas devra revoir sa copie ou geler le planificateur. Le README ne décrit pas de mécanisme de verrouillage distribué ni de variable d'environnement pour désactiver le scheduler ; il dit seulement de ne pas passer à l'échelle horizontale sans l'avoir gating au préalable.

Le General Counsel couvre, selon les termes du README, les contrats, la propriété intellectuelle, les bases du droit du travail et la conformité. C'est un point de départ pour formuler des questions, pas un avis juridique. Un utilisateur qui traite la sortie comme une revue contractuelle se trompe d'outil.

La mémoire épisodique vit dans SQLite et le planificateur s'appuie sur UPDATE ... RETURNING. Ces choix supposent un déploiement avec un système de fichiers persistant. Sur une plateforme qui recycle les conteneurs sans volume monté, l'historique des décisions disparaît au redémarrage. Le dépôt ne documente pas de chemin de migration vers Postgres.

Enfin, la licence. Le badge du README indique Apache 2.0, mais les métadonnées du dépôt renvoient NOASSERTION pour le champ de licence. Cette divergence doit être tranchée en lisant le fichier LICENSE avant tout usage en production. Je ne peux pas dire lequel des deux est exact à partir du matériel fourni.

Face à quoi : un assistant unique contre un orchestrateur

L'alternative la plus directe n'est pas un autre framework multi-agents, c'est un assistant unique bien outillé. Un seul appel à Claude avec un long prompt système, quelques documents en contexte et une recherche vectorielle donne souvent 80 % du résultat pour une fraction de la complexité. Pas de routage à maintenir, pas de planificateur, pas de contrainte mono-instance, pas de seconde base de données.

La différence d'approche est réelle pourtant. Un assistant unique mélange les registres : il répondra à une question de trésorerie avec le vocabulaire du marketing si le prompt ne le cadre pas. OpenExecutive sépare les domaines au niveau du routage, ce qui permet de donner à chaque spécialiste ses propres instructions et sa propre récupération documentaire. Le CSO et le CFO ne lisent pas forcément les mêmes extraits.

Le prix de cette séparation est le coût par requête. L'orchestrateur appelle claude-sonnet-5, puis un ou plusieurs spécialistes, dont certains sur claude-opus-5 avec extended thinking, puis une passe d'extraction sur claude-haiku-4-5 après la réponse. Le README ne publie aucun ordre de grandeur de coût. C'est la première chose à mesurer soi-même avant de généraliser l'usage.

Un point que le README laisse ouvert : la façon dont l'orchestrateur choisit les spécialistes à appeler n'est pas décrite en détail. Le schéma montre « tool use → parallel specialist calls », sans indiquer s'il existe un plafond sur le nombre d'appels simultanés ni comment les conflits entre spécialistes sont arbitrés.

Intégrations, coût de maintenance et suite

Le dépôt déclare un dossier integrations couvrant Slack, Email, Telegram, Google Chat et Discord, avec des scripts d'exploitation pour les secrets Fly et l'authentification Google. Le README détaille uniquement la mise en place du bot Discord, et s'interrompt au moment de créer l'application sur le portail développeur. Les quatre autres canaux sont listés dans l'arborescence sans procédure associée dans le matériel fourni.

Le coût de maintenance se lit dans la pile : Python 3.11, uv, ChromaDB embarqué, SQLite, Next.js 15 en App Router, Tailwind, et une dépendance à l'API Anthropic pour quatre modèles distincts. Chaque montée de version de modèle ou de SDK touche l'orchestrateur, les huit agents et le gestionnaire de cache. Le dossier evals avec son runner LLM-as-judge existe précisément pour détecter ces régressions, mais le README ne dit pas combien de scénarios il contient ni comment les lancer.

Côté licence, si Apache 2.0 se confirme, elle autorise l'usage commercial, la modification et la redistribution, avec obligation de conserver les mentions de copyright et le texte de licence, et une clause de brevets. Le badge et le fichier LICENSE devraient dire la même chose. En l'état, seul le fichier fait foi, et je ne peux pas le lire depuis les métadonnées.

Conclusion éditoriale

À adopter si vous voulez un assistant de direction qui garde une voix unique tout en allant chercher des réponses dans huit domaines, et si vous acceptez de faire tourner l'API en instance unique. À éviter si vous avez besoin d'un service répliqué ou d'une isolation stricte entre juridictions et sociétés. Avant de déployer, vérifiez trois choses dans le dépôt : le contenu réel de knowledge/builtin/, la licence exacte du fichier LICENSE puisque l'API GitHub renvoie NOASSERTION, et la façon dont l'orchestrateur injecte le contexte RAG dans le tour utilisateur plutôt que dans le prompt système mis en cache.

Sources officielles

1. Issues
2. Project website
3. README
4. SenteLabsAI/OpenExecutive on GitHub