Mission Control : un plan de contrôle local pour orchestrer vos agents IA

Pourquoi un plan de contrôle séparé du runtime

Mission Control part d'un constat simple : quand vous avez plusieurs agents qui tournent sur plusieurs runtimes (OpenClaw, Claude Code, Codex), le suivi de qui fait quoi devient vite chaotique. Le projet ne remplace pas le raisonnement ou les boucles d'outils des agents. Il se place au-dessus. Le README le dit clairement : il donne aux opérateurs un endroit pour voir et gouverner le travail autour de ces boucles. C'est une distinction importante, car beaucoup d'outils du marché mélangent le moteur d'agent et le tableau de bord. Ici, le runtime reste ce qu'il est, et Mission Control agit comme une couche de gouvernance. La cible est l'équipe qui ne peut plus répondre à des questions comme : qui possède cette tâche, qu'est-ce qui a été exécuté, quel résultat a passé la revue, où les coûts s'accumulent. Le projet est explicitement déconseillé pour un agent unique sur une machine, car son interface native suffit.

Une architecture à base de SQLite et de workspaces

Le plan de contrôle est auto-hébergé et workspace-aware. SQLite stocke l'état local. Les workspaces partagés peuvent utiliser des intégrations runtime au niveau du déploiement, mais les workspaces stricts bloquent ces intégrations tant que les ressources sous-jacentes ne portent pas la propriété du workspace. C'est un mécanisme de sécurité intéressant : il force une séparation claire entre ce qui appartient au workspace et ce qui vient de l'extérieur. Un gateway est optionnel pour les tâches, projets, agents, planificateurs, webhooks, alertes et coûts. La messagerie de session en direct nécessite un gateway runtime connecté. Concrètement, cela signifie que vous pouvez commencer en mode local sans gateway, mais que certaines fonctionnalités avancées ne fonctionneront pas. Le README précise que les surfaces d'observation couvrent OpenClaw, Claude Code, Codex, CrewAI, LangGraph, AutoGen et les workflows Claude SDK, mais que la profondeur des adaptateurs varie. Il faut donc vérifier la documentation avant de supposer une parité de fonctionnalités.

Installation en trois chemins

L'installation se fait soit par script, soit manuellement, soit avec Docker. Pour une installation source, il faut Node.js 22 ou plus récent et pnpm. Le script install.sh --local clone le dépôt et lance l'installation. Ensuite, ouvrez http://localhost:3000/setup pour créer le premier compte admin, puis copiez la clé API depuis les paramètres si vous voulez un accès headless. Le chemin manuel est plus direct si vous gérez déjà Node et pnpm : nvm use 22, pnpm install, pnpm dev. Sous Windows, le script PowerShell install.ps1 -Mode local fonctionne. Pour Docker, docker compose up suffit, ou vous pouvez tirer l'image multi-architecture ghcr.io/builderz-labs/mission-control:latest et l'exécuter avec un simple docker run. Pour un déploiement accessible sur le réseau, il existe un overlay durci : docker compose -f docker-compose.yml -f docker-compose.hardened.yml up -d. Le guide de déploiement couvre les données persistantes, la terminaison TLS, la connectivité gateway et les builds autonomes. C'est un point fort : plusieurs niveaux d'entrée selon votre niveau de confort.

Connecter un agent via l'API REST

La boucle la plus courte sans gateway utilise l'API REST. Vous exportez les variables d'environnement MC_URL et MC_API_KEY, puis vous enregistrez un agent avec une requête POST sur /api/agents/register. Exemple tiré du README : curl -s -X POST "$MC_URL/api/agents/register" -H "Authorization: Bearer $MC_API_KEY" -H "Content-Type: application/json" -d '{"name":"scout","role":"researcher"}'. Ensuite, vous créez une tâche avec un POST sur /api/tasks, en précisant le titre, l'agent assigné et la priorité. L'agent peut ensuite réclamer sa file d'attente avec GET /api/tasks/queue?agent=scout. Ce flux est simple et reproductible. Il est aussi possible d'utiliser le CLI avec des commandes comme pnpm mc agents list --json ou pnpm mc tasks queue --agent scout --json. Pour les amateurs de MCP, le serveur MCP s'ajoute avec claude mcp add mission-control, en passant les variables d'environnement et le chemin vers le script mc-mcp-server.cjs. Le contrat REST est décrit dans openapi.json, et une instance en cours sert une référence interactive sur /docs.

La revue de qualité Aegis, un garde-fou obligatoire

Le cycle de vie d'une tâche passe par plusieurs étapes : inbox, assignation, exécution, revue, revue de qualité, et complétion. La particularité, c'est le portail Aegis : il exige un enregistrement d'approbation avant qu'une tâche soit marquée comme terminée. Cela force une revue humaine ou un processus d'approbation explicite. Le README donne des consignes aux opérateurs : quand une exécution nécessite une revue, enregistrez l'identité, la tâche, l'appel d'outil, l'approbation, le résultat et les preuves de vérification avant de changer quoi que ce soit. Il faut garder les éléments non résolus distincts du risque accepté. C'est une discipline qui manque souvent dans les outils d'orchestration, où la complétion est automatique. Le fait que ce soit intégré dès le départ est un signe de maturité dans la conception, même si le projet est en alpha. Cela dit, cette exigence peut être perçue comme une lourdeur si vous voulez un flux entièrement automatique.

Les limites à connaître avant de se lancer

Mission Control est en alpha. Le README l'affiche en avertissement : les API, schémas et configurations peuvent changer entre les versions. C'est un risque réel pour une adoption en production. De plus, le projet est explicitement déconseillé si vous avez besoin d'un SaaS multi-tenant géré, ou si vous voulez un framework d'agents pour définir la planification et l'utilisation d'outils. Il ne fait pas cela. Il gouverne, il n'orchestre pas le raisonnement. Autre point : la profondeur des adaptateurs varie selon le runtime. Ne supposez pas que tout est supporté de manière égale. Le README renvoie à la documentation agent-setup.md et cli-integration.md pour vérifier avant. Enfin, le mode strict des workspaces peut bloquer des intégrations si les ressources ne portent pas la propriété, ce qui peut être déroutant au début. Il faut donc lire le guide de déploiement et le guide de sécurité avant d'exposer le service à un réseau.

Alternatives et différences d'approche

La principale alternative est de ne rien utiliser et de se fier aux interfaces natives de chaque runtime. C'est pertinent pour un agent unique, mais cela ne passe pas à l'échelle. Une autre alternative est d'utiliser un framework d'orchestration comme LangGraph, qui gère la logique de planification et d'outils, mais qui ne fournit pas nécessairement une couche de gouvernance avec revues et suivi des coûts. La différence est fondamentale : LangGraph définit comment l'agent raisonne, tandis que Mission Control observe et contrôle ce qui se passe autour. Il y a aussi les plateformes SaaS multi-tenant, mais elles ne sont pas auto-hébergées et peuvent poser des questions de souveraineté des données. Mission Control choisit le compromis : un plan de contrôle local, avec SQLite, qui laisse le runtime faire son travail. C'est une approche modulaire qui peut être plus difficile à intégrer que des solutions tout-en-un, mais qui offre un contrôle direct sur les données.

Coûts de maintenance et licence

Le projet est sous licence MIT, ce qui est permissif et favorable à une adoption commerciale, mais je ne donne pas de conseil juridique. En termes de maintenance, le rythme de sortie est soutenu : les versions 2.1.0, 2.2.0 et 2.3.0 sont sorties en quelques semaines, avec des thèmes de durcissement de sécurité, d'isolation des workspaces et de correctifs de dépendances. Cela montre une activité de développement régulière, mais cela implique aussi que vous devrez suivre les mises à jour pour bénéficier des correctifs de sécurité. Le passage à l'alpha signifie que chaque mise à jour peut casser des schémas ou des API. Il faut donc prévoir un processus de mise à jour avec tests. La documentation mentionne un guide de déploiement, mais je n'ai pas vu de guide de migration entre versions. C'est un point à vérifier avant de s'engager. En résumé, la licence est légère, mais le coût de maintenance est réel, surtout si vous personnalisez l'outil.

Conclusion éditoriale

Mission Control s'adresse aux équipes qui gèrent plusieurs agents sur plusieurs runtimes et qui ont besoin d'un point de contrôle unique pour suivre les tâches, les revues et les coûts. Ne l'adoptez pas si vous utilisez un seul agent sur une machine, si vous voulez un SaaS multi-tenant géré, ou si vous recherchez un framework d'agents pour définir la planification et l'utilisation d'outils. Avant toute mise en réseau, vérifiez la version alpha : les schémas et API peuvent changer entre les versions, et le guide de déploiement hardened doit être appliqué. Testez d'abord en local avec le mode strict pour comprendre les limites d'intégration des workspaces.

Sources officielles

1. Official documentation
2. Official README
3. Project repository
4. Release notes