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.

Je n’ai pas effacé Linux et les Containers comme un échec

Changer de direction ne signifiait pas que je voulais considérer tout ce que j’avais construit jusqu’au 14 comme un échec.

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.

Mais elles ne définissaient pas le Cell final.

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é.

Cette distinction comptait. Si je continuais à pousser la structure de Containers simplement parce que j’y avais déjà consacré beaucoup de temps, le produit finirait par être dirigé par son environnement d’exécution. La quantité déjà implémentée ne justifiait pas ce choix.

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.

Le produit passait avant l’environnement d’exécution

Le 14, je réfléchissais à la manière de répartir et d’intégrer plusieurs IA. Le 15, j’ai de nouveau réfléchi à la nature du Cell dans lequel elles allaient réellement vivre.

Il n’était pas indolore de changer de direction vers le macOS native après avoir déjà beaucoup préparé les Containers. Mais si le produit devait manipuler des apps macOS, Xcode, ainsi que l’OAuth et la Memory propres à chaque utilisateur, l’environnement d’exécution devait lui aussi suivre cet objectif.

Un Cell n’était pas simplement un process isolé. C’était un environnement complet d’IA personnelle, dans lequel une personne travaille avec sa propre authentification, sa mémoire, son espace de travail et ses outils.

Le 15 est le jour où j’ai décidé de ne plus empiler des Containers sur une Linux VM, mais d’utiliser l’utilisateur macOS lui-même comme frontière du Cell.