Archestra, plateforme IA d’entreprise : à qui elle s’adresse et premier lancement Docker

À qui elle s’adresse

• Le positionnement officiel est « la plateforme IA d’entreprise open source tout-en-un » : elle assure à la fois les rôles de MCP registry, de gateway et d’orchestrator, et non celui d’un MCP server à usage unique. La forme adaptée : une équipe auto-héberge la plateforme sur ses propres machines et fait pointer utilisateurs, agent et clients Claude / Codex / Cursor vers la même URL ; les appels d’outils sont pris en charge par la plateforme et les clients ne connaissent qu’une seule porte d’entrée.
• Son MCP gateway utilise OAuth + On-Behalf-Of pour que les outils s’exécutent en tant que l’utilisateur lui-même, et non sous un compte de service partagé ; les équipes attachées à ce que chaque appel soit attribué à une personne y gagnent clairement.
• Critère de jugement : si votre problème se résume à « il manque un outil à un client », un seul MCP server suffit ; la couche plateforme n’intervient que lorsqu’il faut gérer ensemble plusieurs services, plusieurs clients et plusieurs identités.
• Environnement adapté : équipes capables de faire tourner Docker en local ou sur l’intranet et prêtes à évaluer le coût du montage de socket ; le quickstart lie les ports à l’adresse de bouclage, ce qui convient à un essai sur une seule machine avant un fonctionnement au long cours, une fois les effets secondaires acceptés.
• Prérequis : Docker sur la machine. Les preuves ne donnent ni configuration minimale, ni systèmes d’exploitation pris en charge, ni mode d’exécution autre que Docker — autant de points non confirmés.

Une première tentative en 3 minutes

• Avant d’agir, confirmez que vous acceptez les deux effets secondaires explicitement signalés par la note officielle : d’une part, la commande monte le /var/run/docker.sock de l’hôte, ce qui permet au conteneur de piloter le daemon Docker de l’hôte ; d’autre part, le tag latest de l’image pointe vers la release la plus récente et exécute généralement une release candidate. Ces deux points figurent dans la note officielle : ils comptent dès l’évaluation, ce ne sont pas des détails à régler après le déploiement.
• Le premier lancement n’est pas non plus une opération en lecture seule : les volumes nommés archestra-postgres-data et archestra-app-data écrivent les données de la base et de l’application dans des volumes Docker locaux ; aucune commande officielle de nettoyage ou d’annulation n’est fournie, et les preuves ne disent pas si les anciennes données perturbent les démarrages suivants entre essais répétés — ne testez pas à la légère sur un hôte qui contient des données importantes.
• Une fois accepté, exécutez la commande officielle de démarrage rapide :

docker pull archestra/platform:latest

docker run \
  -p 127.0.0.1:9000:9000 -p 127.0.0.1:3000:3000 \
  -e ARCHESTRA_QUICKSTART=true \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v archestra-postgres-data:/var/lib/postgresql/data \
  -v archestra-app-data:/app/data \
  archestra/platform:latest

• Le signal de succès vérifiable s’arrête à ce niveau : le conteneur reste en marche et les deux ports ne se lient qu’à l’adresse de bouclage 127.0.0.1 ; la configuration explicitement exigée par le quickstart, c’est ARCHESTRA_QUICKSTART=true plus ce jeu de ports et de montages. Liés au seul bouclage, les ports ne sont par défaut accessibles que depuis la machine locale ; la configuration d’un accès distant n’est pas abordée par les preuves.
• L’étape suivante consiste à faire pointer Claude / Codex / Cursor vers cette URL unique ; la valeur exacte de l’URL ne figure pas dans la commande et se confirme côté plateforme après le démarrage. La façon de réaliser la première connexion n’est pas mentionnée non plus.

Cas d’usage

• Cas 1 : une entrée unique pour plusieurs clients. Scénario : dans l’équipe, certains utilisent Claude, Codex et Cursor, sans vouloir brancher MCP séparément pour chaque client. Démarche : lancer la plateforme en quickstart comme ci-dessus et pointer les clients vers la même URL Archestra. À attendre : les appels d’outils passent par le MCP gateway et s’exécutent en tant que l’utilisateur lui-même, les mêmes outils desservant les trois clients par la même entrée. Limite : les preuves ne donnent pas la liste des services que la plateforme accepte ; vérifiez avant de brancher que les services voulus y figurent.
• Cas 2 : rien sur un compte de service partagé. Scénario : l’équipe refuse que tous les appels d’outils soient enregistrés au nom d’un compte de service partagé. Il s’appuie sur le même mécanisme d’identité du gateway. Démarche : après le branchement, vérifier que les outils tournent en tant que l’utilisateur ; si de l’automatisation tourne aujourd’hui sous un compte partagé, la comparaison avant/après est possible. Ce qui est confirmable : l’énoncé officiel le dit ; l’allure de l’interface de configuration des comptes et des journaux d’appels n’apparaît pas dans les preuves — n’en présumez pas l’existence.
• La différence entre les deux cas : le cas 1 vérifie l’entrée unifiée, le cas 2 l’attribution des identités ; essayez chacun une fois, l’un après l’autre.

Limites d’utilisation

• Nature lecture/écriture : le premier lancement écrit déjà un état local (deux volumes nommés) ; le montage de socket donne au conteneur la capacité de manipuler les conteneurs de l’hôte — l’effet secondaire le plus lourd, à peser à part.
• Identifiants et identité : le gateway dépend d’OAuth ; la façon de configurer le fournisseur et l’obligation éventuelle de brancher d’abord une source d’identité ne sont pas expliquées par les preuves, donc non confirmées.
• Relation client-plateforme : la ligne officielle est de faire pointer utilisateurs, agent ou clients vers une URL et de laisser la plateforme gérer le reste ; les versions ou greffons requis côté clients ne sont pas mentionnés.
• Limite de version : la ligne officielle est que les déploiements de production devraient épingler un tag de version exact ; latest correspond généralement à une release candidate, ne lui confiez pas directement une charge réelle.
• Ordre des actions : accepter d’abord le montage de socket et la question de version, puis exécuter la commande ; faire le premier essai de préférence en bouclage local, sans l’ouvrir directement sur Internet.
• Informations clés non confirmées : consommation de ressources, étapes de montée de version et de retour arrière, sauvegarde des données, déclarations lecture/écriture des outils MCP dans la plateforme, politique initiale des identifiants — rien de tout cela n’est couvert par les preuves ; ne mettez pas de données réelles dans l’environnement du premier essai. L’absence de documentation ne vaut pas absence de risque ; les documents officiels font foi.