OpenCode 2.0 sur un Mac partagé ne doit pas être considéré comme un dispositif d’isolation entre collègues : le service partagé documenté gère l’état de l’application pour le compte utilisateur courant. Si plusieurs personnes doivent utiliser la même machine, vérifiez les comptes macOS, les dossiers, les identifiants et les accès au service ; tant que ces frontières ne sont pas établies, ne confiez pas des projets distincts à une même session utilisateur.
Cet article s’adresse aux responsables de laboratoire qui évaluent le partage d’un Mac exécutant OpenCode 2.0.
Il concerne aussi les administrateurs chargés des comptes et des répertoires, ainsi que les développeurs de logiciels de recherche qui préparent un environnement accessible à l’équipe.
Dernière vérification : 3 novembre 2026, d’après la documentation officielle V2 et l’historique des versions d’OpenCode.
OpenCode 2.0 sur un Mac partagé : distinguez machine et identité
« Même Mac » ne signifie pas nécessairement « même contexte », mais cela ne garantit pas non plus des contextes séparés. Pour décider, il faut nommer précisément ce qui est commun. Trois situations différentes se cachent souvent derrière l’expression « partager OpenCode ».
- Une seule personne utilise un compte macOS commun, à tour de rôle. Les sessions, fichiers accessibles, réglages et secrets associés à cet utilisateur peuvent rester disponibles pour les autres personnes qui ouvrent la session.
- Chaque personne a son propre compte macOS sur la même machine. Les répertoires personnels et les droits du système constituent alors des frontières à vérifier. Cela ne permet pas, à lui seul, de conclure qu’un service lancé par un utilisateur est accessible ou inaccessible aux autres.
- Plusieurs clients se connectent au même service OpenCode. Dans ce cas, la cible de connexion et le compte qui exécute le service importent autant que l’identité utilisée pour ouvrir chaque client.
La documentation V2 de l’interface en ligne de commande et du service décrit le service comme gérant les sessions, la configuration, les intégrations, les autorisations et l’exécution des outils pour le compte utilisateur courant. Elle présente aussi les modes autonome et de connexion à un serveur désigné. Il ne faut donc pas transformer cette description en promesse d’isolation pour plusieurs personnes utilisant le même compte macOS.
Avant de tester, consignez quatre informations par personne : le compte macOS ouvert, le client utilisé, l’adresse ou la cible du service et le projet sélectionné. Si l’équipe ne peut pas renseigner ces éléments sans ambiguïté, elle ne dispose pas encore d’une frontière opérationnelle fiable.
Les sessions et les réglages suivent le service, pas le nom affiché du client
Ouvrir deux fenêtres ou deux clients sous des noms différents ne prouve pas que les sessions et les configurations sont distinctes. Les questions à résoudre sont plus concrètes : qui a démarré le service ? Quel utilisateur possède son processus ? Où se trouvent les fichiers de configuration ? Les clients se connectent-ils à des services différents ou à la même cible ?
La documentation V2 de la configuration décrit les réglages pris en compte par OpenCode. Pour une vérification d’équipe, comparez les fichiers de configuration réellement utilisés, plutôt que les seules préférences visibles dans une fenêtre. La documentation des autorisations décrit la gestion des autorisations dans l’application ; ces réglages ne remplacent pas les permissions macOS.
Nous conseillons de faire un essai sans données de recherche :
- ouvrez une session avec le compte prévu pour le test ;
- lancez le service selon le mode envisagé ;
- notez le chemin de configuration et l’identité du processus ;
- connectez le second client à la cible prévue ;
- comparez la liste des sessions et vérifiez les réglages visibles depuis chaque client.
Une différence d’affichage n’est pas une preuve suffisante de cloisonnement. Recommencez en fermant puis en relançant les clients, et vérifiez que le service n’est pas resté associé au premier utilisateur. Enfin, consultez les notes de version officielles avant de généraliser le résultat à une autre version : les fonctions et leurs comportements peuvent évoluer.
Les dossiers de projet restent une frontière distincte
Une session OpenCode et un répertoire de fichiers ne sont pas la même chose. Même lorsque les clients affichent des conversations différentes, une mauvaise sélection du chemin de travail peut conduire à modifier le dépôt d’un collègue. Le risque est particulièrement concret dans un laboratoire où plusieurs personnes alternent entre analyse de données, scripts de traitement, édition de documents, audio ou vidéo.
Nous séparons donc le contrôle en deux questions : OpenCode montre-t-il la session attendue ? Et le système de fichiers autorise-t-il uniquement les opérations prévues ? Un contrôle positif sur la première ne répond pas à la seconde.
Pour tester les limites de travail, créez un dépôt temporaire sans données sensibles. Demandez à chaque personne d’ouvrir son projet, de créer un fichier de test, puis vérifiez le chemin réellement modifié, la branche active et l’emplacement des résultats. La documentation de Git sur git worktree explique comment gérer plusieurs répertoires de travail associés à un même dépôt ; cette organisation peut aider à éviter certaines collisions de fichiers, mais elle ne constitue pas une mesure d’isolation des comptes ou des secrets.
| Organisation | Ce qu’elle peut clarifier | Ce qu’elle ne garantit pas |
|---|---|---|
| Même compte macOS et même copie de travail | Un accès commun et simple aux fichiers | La séparation entre personnes, sessions ou identifiants |
| Comptes macOS distincts et répertoires séparés | Des identités système et des emplacements de travail différenciés | Une séparation automatique du service ou des secrets mal stockés |
| Répertoires de travail Git distincts | L’emplacement des modifications et le travail parallèle | L’isolation des droits macOS ou l’authentification du service |
| Machines ou environnements distincts | Une frontière plus nette entre les contextes d’exécution | La conformité aux règles de l’établissement sans vérification complémentaire |
Vérification des répertoires avant un vrai projet
Nous utilisons une copie de test pour vérifier les opérations de lecture et d’écriture, et non un dépôt actif de l’équipe. L’utilisateur A crée un fichier identifiable dans son espace. L’utilisateur B tente ensuite d’ouvrir ce chemin et d’enregistrer un fichier dans son propre projet. Le résultat doit être vérifié sur le disque, pas seulement dans l’interface.
Apple décrit la création de comptes dans son guide pour ajouter un utilisateur sur Mac et documente les permissions d’accès aux fichiers et dossiers. Pour un dossier que l’équipe doit réellement partager, consultez aussi les réglages de partage de fichiers sur Mac. Ces mécanismes servent à configurer l’accès système ; ils ne prouvent pas que le service OpenCode est isolé.
Les identifiants et les commandes peuvent dépasser le projet ouvert
Un répertoire de projet ne contient pas nécessairement toutes les ressources auxquelles un processus peut accéder. Des variables d’environnement, des clés de fournisseur, des fichiers personnels et des commandes disponibles dans le terminal peuvent être accessibles selon le compte qui exécute OpenCode. Si plusieurs personnes utilisent la même session macOS, elles peuvent potentiellement agir avec les droits de cet utilisateur et atteindre ses ressources accessibles.
L’application et le système d’exploitation imposent des niveaux de contrôle différents. Les autorisations configurées dans OpenCode encadrent le comportement de l’application ; elles ne créent pas une identité macOS distincte. Inversement, un compte séparé ne suffit pas si les secrets sont copiés dans un dossier partagé ou si une configuration commune les expose à tous.
Pour chaque compte utilisé par l’équipe, établissez une liste des éléments à vérifier : emplacement des identifiants, variables d’environnement, droits d’accès au trousseau et aux fichiers, commandes autorisées, emplacement des journaux et procédure de révocation. N’inscrivez pas de véritable secret dans un dépôt de test. Utilisez un identifiant fictif et vérifiez que le compte qui ne devrait pas y accéder ne peut ni le lire ni l’utiliser.
La question se pose aussi lors de la production créative. Une personne peut traiter des enregistrements audio ou exporter une vidéo pendant qu’une autre exécute des outils de développement. Un partage de compte rend plus difficile l’attribution d’une commande ou d’un fichier produit à la bonne personne. Lorsque la traçabilité est importante, conservez des comptes distincts et attribuez à chaque travail un répertoire et des identifiants propres.
L’accès distant élargit le périmètre à contrôler
Un service utilisé localement n’a pas nécessairement le même périmètre qu’un service accessible depuis le réseau. Avant d’autoriser un accès distant, confirmez si cette fonction est activée, quelle adresse écoute le service, comment les clients s’authentifient et quelles origines ou machines sont autorisées. La documentation officielle sur le service Web distant indique que l’accès distant est une fonction à activer explicitement ; il faut vérifier les paramètres de la version réellement déployée.
Ne déduisez pas qu’un service est protégé parce qu’une personne connaît un mot de passe, ni qu’un transport chiffré suffit à répondre aux règles de sécurité de l’établissement. Ces mesures ne déterminent pas à elles seules qui peut accéder aux projets, comment les secrets sont conservés ou quelles données peuvent quitter le laboratoire.
| Mode d’accès | Vérifications indispensables | Risque si la limite reste floue |
|---|---|---|
| Connexion locale sur le Mac | Compte actif, service lancé, cible effectivement utilisée | Confusion entre sessions ou processus d’utilisateurs |
| Accès depuis le réseau du laboratoire | Adresse d’écoute, authentification, machines autorisées | Accès plus large que le seul poste prévu |
| Accès distant hors du laboratoire | Activation explicite, authentification et règles institutionnelles | Exposition des projets et identifiants au-delà du périmètre attendu |
Liste de contrôle à cocher avant la mise en service
- [ ] Chaque personne sait quel compte macOS elle utilise.
- [ ] Le responsable du service et sa cible de connexion sont identifiés.
- [ ] La liste des sessions et les fichiers de configuration ont été vérifiés avec des comptes de test.
- [ ] Chaque projet possède un chemin de travail explicite, contrôlé par une écriture de test.
- [ ] Les droits d’accès aux dépôts, aux fichiers produits et aux dossiers partagés correspondent aux rôles de l’équipe.
- [ ] Les identifiants de test ne sont pas réutilisés pour les fournisseurs ou les projets réels.
- [ ] Le mode d’accès distant a été vérifié dans la version installée et reste désactivé s’il n’est pas nécessaire.
- [ ] Les personnes responsables savent comment retirer un accès et révoquer un identifiant.
FAQ : sessions, projets et choix des comptes
Que partage le service OpenCode entre ses clients ?
La documentation V2 décrit un service qui gère les sessions, la configuration, les intégrations, les autorisations et l’exécution des outils pour le compte utilisateur courant. Cela ne prouve pas que plusieurs personnes utilisant le même compte macOS soient isolées. Vérifiez qui lance le service et quelle cible chaque client rejoint.
Des collègues peuvent-ils voir les projets ouverts par d’autres ?
Cela dépend du compte macOS, des droits sur les fichiers et du chemin de travail choisi. Une session distincte ne crée pas une barrière de fichiers. Testez les lectures et écritures dans un dépôt sans données sensibles, puis contrôlez les branches, les chemins et les fichiers produits avant de faire travailler l’équipe sur le code réel.
Quelles vérifications faire avant d’autoriser un accès distant ?
Vérifiez si le service distant est activé, son adresse d’écoute, son authentification et les origines autorisées. La documentation décrit cet accès comme une option à activer explicitement. Un mot de passe ou un transport chiffré ne remplace pas la validation de sécurité de l’établissement ni les contrôles sur les données.
Quand faut-il créer des comptes séparés ?
Utilisez un compte partagé uniquement si les personnes doivent réellement partager les fichiers, les sessions et les identifiants, et si cette décision est acceptée par l’équipe. Pour des projets ou des secrets distincts, préférez des comptes macOS séparés et vérifiez les permissions. Si aucune frontière ne peut être démontrée, séparez également les environnements.
Décider entre compte commun, comptes séparés et environnement distinct
La décision porte sur le niveau de séparation nécessaire, pas seulement sur le nombre de personnes utilisant l’ordinateur. Appliquez ces conditions dans l’ordre :
- Si une seule personne utilise le Mac, que les projets sont les siens et que l’accès distant n’est pas nécessaire, testez d’abord le service dans le contexte de son compte. Documentez le chemin du projet et les identifiants utilisés.
- Si plusieurs personnes travaillent sur des projets compatibles avec un accès commun, choisissez un compte partagé uniquement après validation des dossiers, des secrets, des autorisations et des règles du laboratoire. Chaque personne doit savoir quels éléments sont communs.
- Si les projets, les identifiants ou les responsabilités doivent rester distincts, créez des comptes macOS séparés. Validez les droits et refaites les tests de service et de fichiers sous chaque identité.
- Si l’équipe ne peut pas démontrer qui peut accéder à une session, un dépôt ou un identifiant, ne partagez pas le même compte pour les projets concernés. Revenez à des comptes ou environnements indépendants.
- Si l’accès réseau n’apporte aucun besoin de travail concret, ne l’activez pas. S’il est requis, faites valider son périmètre par la personne responsable de la sécurité avant d’y connecter des données de recherche.
Pour les comptes et les répertoires, le guide Apple sur la configuration des permissions de fichiers aide à vérifier les contrôles du système. Pour les paramètres du service et les autorisations d’OpenCode, revenez aux documentations officielles citées plus haut et contrôlez la version installée plutôt que de transposer un résultat observé sur un autre poste.
Un Mac distant peut compléter un parc de laboratoire composé surtout de machines Linux ou Windows lorsqu’un outil de recherche ou un test nécessite macOS. Il ne résout pas automatiquement les problèmes d’attribution des comptes, de confidentialité des dépôts ou de conformité aux règles de l’établissement. Avant d’y déplacer des données, faites valider les règles d’accès et les secrets par votre équipe.
Si votre équipe a besoin d’un poste macOS interactif sans acheter immédiatement une machine, vous pouvez examiner les modalités proposées par metalvnc. Pour clarifier les conditions d’utilisation et les questions pratiques avant de décider, consultez également le centre d’aide de metalvnc. Comparez cette option à vos machines actuelles : un serveur Linux ou Windows peut ne pas fournir l’environnement macOS recherché, l’accès à un poste local peut être difficile à partager à distance, et l’achat d’un Mac immobilise le budget de l’équipe. La location peut répondre au besoin temporaire d’un environnement macOS, mais elle ne constitue ni une garantie d’isolation entre utilisateurs ni une validation de conformité.
Questions fréquentes
Quelles informations le service partagé d’OpenCode conserve-t-il pour un compte ?
La documentation V2 décrit un service qui gère, pour le compte utilisateur courant, les sessions, la configuration, les intégrations, les autorisations et l’exécution des outils. Cela ne prouve pas que des personnes utilisant le même compte macOS soient isolées les unes des autres. Vérifiez quel compte lance le service et quelle cible chaque client rejoint.
Deux personnes utilisant un Mac commun peuvent-elles accéder aux mêmes fichiers de projet ?
Cela dépend notamment du compte macOS, des droits d’accès aux fichiers et du chemin de travail choisi par OpenCode. Une session distincte ne crée pas à elle seule une frontière de fichiers. Avant tout travail réel, testez les lectures et écritures dans un dépôt sans données sensibles et examinez les branches ainsi que les fichiers produits.
Comment contrôler l’accès à un service OpenCode distant ?
Commencez par déterminer si le service distant est activé, puis vérifiez son adresse d’écoute, son mode d’authentification et les origines autorisées. La documentation décrit l’accès distant comme une configuration à activer explicitement. Un mot de passe ou un transport chiffré ne remplace pas l’approbation de sécurité exigée par votre établissement.
Pour un laboratoire, faut-il partager un compte ou créer des comptes séparés ?
Réservez le compte commun aux usages contrôlés où les personnes, les fichiers, les identifiants et les accès sont explicitement partagés. Pour des projets ou des secrets distincts, créez des comptes macOS séparés et vérifiez leurs permissions. Si les frontières restent impossibles à démontrer, utilisez des environnements indépendants plutôt que de supposer que l’application les garantit.
Séparez vos environnements de travail sur un Mac dédié
Avec metalvnc, louez un Mac mini M4 physique dont les ressources ne sont pas partagées avec d’autres clients.