Fichiers workspace OpenClaw (SOUL.md, MEMORY.md) sur Mac cloud 2026 : configuration sûre pour les équipes

Les équipes plateforme qui font tourner OpenClaw sur Mac Apple Silicon loués apprennent vite : le choix du modèle et la disponibilité de la passerelle ne font que la moitié du récit — le comportement de l’agent est piloté par des fichiers markdown dans son workspace. Les prompts de type SOUL définissent le ton et les garde-fous ; les fichiers mémoire retiennent des faits durables à réutiliser entre sessions ; les fichiers compagnons décrivent outils et sous-agents. La pratique 2026 : traiter ce répertoire comme de l’infrastructure-as-code — versionner les parties sûres, exclure les secrets, documenter quel utilisateur macOS possède le LaunchAgent qui les lit. Ce guide détaille chaque fichier clé, propose un bootstrap en sept étapes, des modèles bac à sable multi-ingénieurs, des règles d’hygiène Git et une matrice symptômes → correctifs, avec des liens vers le durcissement passerelle et webhooks lorsque le problème n’est pas le markdown.

Un texte de workspace soigné réduit aussi la dépense en tokens : des paragraphes SOUL concis évitent de répéter la politique à chaque conversation, et un MEMORY élagué limite le ré-ingestion coûteux de paragraphes obsolètes à chaque tâche.

Planifiez une revue mensuelle de « dette de prompts » comme pour les tâches cron obsolètes : supprimez les expériences, archivez les consignes de ton dépassées, ne gardez que ce qui correspond encore aux API de production et à la voix de marque.

Pourquoi le markdown workspace compte sur Mac cloud headless

Contrairement à un assistant purement conversationnel, les agents OpenClaw sur les nœuds MacLogin peuvent invoquer des commandes shell, surveiller des dossiers et répondre à des webhooks. Sans contraintes SOUL explicites, un modèle serviable peut supprimer des fichiers, poster dans le mauvais canal Slack ou fuiter des noms d’hôtes internes dans des réponses visibles client. MEMORY, mal utilisé, devient une décharge de rumeurs de projet obsolètes qui écrasent des données plus fraîches du système de tickets. Bien structurer les fichiers réduit le volume d’incidents plus qu’un simple agrandissement de fenêtre de contexte.

Avant de modifier la prose, stabilisez la passerelle avec les étapes de dépannage launchd pour le daemon passerelle — sinon vous chasserez des fantômes markdown pendant que Node redémarre en boucle.

Fichiers workspace clés : tableau de référence

Les distributions OpenClaw évoluent, mais la plupart exposent un dossier workspace sous l’utilisateur de service (souvent sous un arbre caché .openclaw). Utilisez ce tableau comme contrat d’équipe — ajustez les noms de fichiers seulement si votre build le documente.

Fichier	Rôle	À ne pas y stocker
SOUL.md (ou équivalent)	Persona, refus, déclencheurs d’escalade	Clés API, PII clients, instructions tierces non validées
MEMORY.md	Faits durables, conventions, carte des dépôts	Mots de passe, jetons bruts, secrets sensibles au temps
AGENTS.md / TOOLS.md	Sous-agents et outils déclarés	Plugins expérimentaux non revus pour le risque type ClawHub

Bootstrap workspace en sept étapes

1. Choisir le propriétaire : doit correspondre au compte macOS qui exécute le LaunchAgent — propriété mixte = échecs de lecture silencieux.
2. Instantané du répertoire : copier les permissions avec ls -la ; chaque markdown lisible seulement par le groupe prévu.
3. Rédiger SOUL.md : inclure « ne jamais lancer rm -rf hors racines workspace » et exiger confirmation pour les webhooks sortants.
4. Amorcer MEMORY.md : URL des dépôts, branches par défaut, noms d’astreinte ; retirer les entrées de plus de 90 jours lors des revues de sprint.
5. Aligner les manifestes d’outils : retirer ceux que l’hôte ne doit pas exposer publiquement — surtout avec HTTPS entrant depuis des webhooks terminés en TLS.
6. Câbler gitignore : exclure les chemins de brouillon local ; ne jamais committer de copies .env à côté du markdown.
7. Redémarrer et dry-run : rebooter la passerelle, envoyer une invite bénigne qui cite MEMORY, vérifier dans les logs les hash ou marqueurs de chargement attendus.

Modèles bac à sable d’équipe sur un seul Mac mini

Lorsque le budget limite à un Mac mini M4 à Singapour pendant que des ingénieurs sont à Séoul et San Francisco, séparez les contextes plutôt que de partager un MEMORY mutable. Options : sous-dossiers par projet symlinkés dans le workspace actif lors des déploiements, ou branches Git promues par la CI après review. Documentez les passations sur le wiki interne pour que l’astreinte week-end sache quelle branche est live.

Git, sauvegardes et hygiène des secrets

Même les dépôts « internes » fuient quand les prestataires clonent. Traitez MEMORY comme de la config applicative : rédiger les noms clients si inutiles, préférer les IDs de tickets aux transcripts complets, hook pre-commit qui bloque les clés privées. Pour les sauvegardes, chiffrez les copies hors ligne car le markdown contient souvent des indices d’architecture utiles aux attaquants.

Cibles opérationnelles : garder SOUL + MEMORY combinés sous environ 8 000 tokens équivalents sauf si vous implémentez de la récupération ; revues trimestrielles pour supprimer les références d’automation liées à des microservices retirés.

Quand plusieurs humains éditent le même markdown via SSH, adoptez verrous ou revues type pull-request même si le « dépôt » est informel — le dernier écrivain gagnant a déjà mélangé règles de sécurité à moitié anciennes et ton marketing à moitié neuf dans la même session.

Matrice de dépannage

Symptôme	Cause probable	Correctif
L’agent ignore une nouvelle règle SOUL	Passerelle non redémarrée ou mauvais chemin utilisateur	Vérifier ProgramArguments du LaunchAgent et recharger
Réponses contradictoires d’une heure à l’autre	MEMORY obsolète vs données API live	Horodater les puces MEMORY ; préférer les appels d’outil pour l’état volatile
Erreurs outil introuvable	TOOLS.md désynchronisé des plugins installés	Réconcilier avec la sortie openclaw doctor
Texte sensible dans le chat client	MEMORY partagé sans règles de rédaction	Ajouter une clause SOUL exigeant le nettoyage avant canaux externes

Questions fréquentes

SOUL doit-il référencer la voix de marque ? Oui — incluez des exemples de salutations préférées et de formulations interdites pour réduire les cycles de relecture.

MEMORY peut-il tirer de Notion automatiquement ? Uniquement via des outils explicites de confiance ; n’y collez pas d’exports wiki entiers sans découpage.

À quelle fréquence réinitialiser les expériences workspace ? Après les grosses montées de version macOS ou les migrations entre régions MacLogin (HK, JP, KR, SG, US) — chemins et permissions peuvent changer.

Pourquoi le Mac mini M4 sur MacLogin convient aux workspaces riches

De gros fichiers SOUL et MEMORY se chargent plus vite lorsque le disque et la mémoire unifiée ne rivalisent pas avec l’indexation Xcode d’un autre projet. Les nœuds Mac mini M4 offrent des performances single-thread prévisibles pour parser le markdown et lancer des sous-processus d’outils. Héberger à Hong Kong, au Japon, en Corée, à Singapour ou aux États-Unis garde une latence faible pour les opérateurs chat et les expéditeurs de webhooks.

Louez des hôtes séparés pour les agents de production versus les bacs à sable R&D afin que les brouillons SOUL expérimentaux ne partent pas par erreur. Montez en mémoire et CPU via la page tarifs quand vous ajoutez des outils, et gardez l’accès VNC pour les validations GUI ponctuelles que le markdown headless ne remplace pas.