[🛠] AI Orchestration #2: J’ai remplacé le Cell conçu comme un Linux Container par un utilisateur macOS

✨ Résumé de GPT-5.6 Sol

Le récit de l’abandon du plan qui faisait d’une Linux VM et de Containers par utilisateur la solution par défaut, pour redéfinir l’unité d’exécution comme un utilisateur macOS par employé avec OpenClaw native.

J’ai renversé la structure de base en une seule journée

Hier, j’ai relié un coordinateur et plusieurs workers en pratique. J’ai expérimenté une méthode pour séparer les résultats produits par plusieurs IA entre Worktrees, Branches et commits, avant de les réunir de nouveau.

En parallèle, je construisais aussi l’environnement d’exécution d’AI Orchestration. Jusqu’au 14, la structure de base était la suivante.

Mac mini
→ 1 Colima Linux VM
→ OpenClaw Cell Containers par employé

Créer une Image commune et séparer le Network et le Volume de chaque employé semblait faciliter le déploiement et la reproductibilité. J’avais déjà vérifié l’Image Linux arm64 officielle d’OpenClaw et créé une child Image ainsi qu’un contrat de Cell Network. La voie qui consistait à isoler l’environnement de chaque employé dans un Container était déjà très concrète.

Pourtant, le 15, j’ai retiré cette structure de la solution par défaut.

Ce que je voulais construire n’était pas un service de Containers

En reformulant l’objectif d’AI Orchestration, j’ai vu ce qui ne correspondait pas.

Je voulais créer un environnement où les employés n’auraient qu’à décrire leur objectif dans le WebChat, puis où une IA personnelle découperait le travail nécessaire, choisirait les outils et le mènerait jusqu’au bout. Il ne s’agissait pas seulement de produire du code et des documents. L’IA devait aussi manipuler des apps Mac, lancer Xcode et Simulator, et laisser des résultats réels dans le Workspace et sous la Git identity de l’utilisateur.

Dès qu’on force un Linux Container à appeler des fonctions macOS, la structure devient étrange. Il faut placer un exécuteur séparé hors du Container, reconnecter ensuite les droits et les états, puis transmettre le Keychain et la GUI Session de l’utilisateur. La couche ajoutée pour isoler oblige justement les fonctionnalités essentielles à emprunter sans cesse des chemins détournés.

OpenClaw n’était pas non plus un simple stateless worker. Il ressemblait davantage à un environnement personnel qui réunit le Gateway, le Profile, la Session, la Memory, l’OAuth et l’état d’exécution d’un utilisateur. Dans ce cas, c’était peut-être la définition même d’un Cell comme un Container qui était erronée.

Le 15, j’ai redéfini le Cell.

1 employé
= 1 utilisateur macOS
= 1 OpenClaw Gateway indépendant
= 1 ensemble UID·HOME·Keychain
= 1 ensemble ChatGPT OAuth·CODEX_HOME
= 1 ensemble Workspace·Git identity·Session·Memory

Cette nouvelle structure crée un utilisateur macOS indépendant pour chaque employé sur un même Mac mini, puis exécute un OpenClaw Gateway complet en native dans chacun de ces comptes.

Les Containers sont restés des sandboxes optionnelles

L’expérience avec les Containers avait apporté des constats clairs. Les preuves concernant l’Image officielle, l’exécution non-root, une root read-only, la séparation du Network, les frontières des Volumes et credentials, l’Image provenance et le restart conservaient leur valeur.

La Linux VM et les Containers ne constituaient plus l’environnement Pilot par défaut. Ils devenaient des candidats au rôle de sandbox, réservés aux tâches particulières qui exigeaient réellement une isolation. Le macOS native devenait la base, et le Container un outil à employer une fois son besoin démontré.

Séparer les utilisateurs macOS ne suffisait pas non plus à garantir l’isolation

La structure native semblait simple, mais elle soulevait encore plus de points à vérifier.

• l’employé connecté et l’utilisateur macOS qui exécute réellement le processus sont-ils bien la même personne ?
• le Gateway, l’OAuth, le Workspace et l’auteur Git de cet utilisateur sont-ils correctement liés ?
• si l’authentification d’un utilisateur échoue, le système évite-t-il de basculer vers celle d’un autre ?
• est-il impossible d’accéder au HOME, au Keychain, au Port et au Workspace d’un autre utilisateur ?
• après un changement rapide d’utilisateur ou un reboot, chaque Gateway retrouve-t-il son propre état ?

Je ne me suis donc pas contenté de changer la topology dans les documents. J’ai créé un nouveau contrat et de nouvelles Acceptance pour le native macOS Cell, puis laissé en NOT_READY les éléments dépourvus de preuves réelles dans le Runtime.

La réussite d’un test fixture ne permettait pas non plus d’affirmer que l’isolation entre deux vrais utilisateurs était terminée. J’ai séparé le hash des fichiers d’entrée externes des preuves d’exécution des probes réels, puis continué à corriger le système pour empêcher le contournement des vérifications par une valeur imitant un autre utilisateur, un symlink ou un alias de chemin macOS lié à la casse ou à Unicode.

Après avoir changé la topology à midi, j’ai passé l’après-midi à enchaîner les commits pour fermer les « brèches qui permettaient de mentir en prétendant que le test était passé ». Rendre honnêtes les conditions de réussite de la nouvelle structure a demandé davantage de code que le changement de structure lui-même.

J’ai aussi séparé les Workflows communs de l’état personnel

Même en donnant à chaque employé un environnement totalement indépendant, les Workflows communs gérés par l’entreprise devaient être distribués dans une même version. À l’inverse, la mise à jour d’un Workflow commun ne devait modifier ni l’OAuth, ni la Memory, ni le Workspace personnels.

Dans l’après-midi du 15, j’ai fixé chaque Workflow Release par version et content hash, puis créé un contrat d’admission qui n’autorisait que les releases validés. La sélection d’un nouveau release devait changer de manière atomique ; les tâches en cours devaient rester fixées sur le release choisi à leur démarrage ; et aucun release utilisé ne devait disparaître pendant un rollback ou un nettoyage.

Là encore, je n’ai pas écrit que le système était déployé dans l’emplacement partagé du Mac simplement parce que le Source et les tests existaient. Un Runtime non installé est resté NOT_READY jusqu’au bout.

Environnement d’exécution par défaut et validations restantes

• Cell par défaut : un compte utilisateur macOS natif par employé, avec un OpenClaw Gateway indépendant
• Isolation optionnelle : un Linux Container sandbox uniquement pour les tâches dont le besoin est démontré
• État commun : un Workflow release fixé par version et content hash
• État personnel : OAuth, Memory, Workspace, Git identity et Session
• Isolation réelle entre plusieurs utilisateurs dans le Runtime : NOT_READY

Le 15, j’ai arrêté la topologie. L’isolation réelle entre deux utilisateurs et l’installation du Workflow commun devaient encore être confirmées par des preuves Runtime ultérieures.