OpenHands auto-hébergé sur Mac : local ou cloud ?

Votre installation OpenHands fonctionne, mais l’agent ne peut pas terminer l’acceptation du dépôt réel, car votre Mac est occupé ou dépourvu de la chaîne Xcode attendue.
Pour OpenHands auto-hébergé sur Mac, choisissez le local si vous testez seul et rarement ; passez à un Mac cloud isolé dès que plusieurs agents, l’accès distant, la disponibilité continue ou la protection des identifiants deviennent prioritaires.

Cette analyse s’adresse à trois profils :

• l’indépendant qui veut expérimenter OpenHands sans immobiliser durablement son ordinateur principal ;
• l’ingénieur plateforme qui doit fournir un environnement homogène à plusieurs développeurs ;
• l’équipe Apple qui demande à l’agent de modifier, compiler et valider des projets iOS ou macOS, et pas seulement d’éditer du Swift.

Le vrai point de départ : une installation réussie ne prouve rien

OpenHands peut être lancé sur macOS avec Docker Desktop. La documentation officielle indique qu’un système moderne avec au moins 4 Go de mémoire vive est recommandé, et le démarrage local expose généralement l’interface sur le port 3000. Ces éléments suffisent pour commencer, mais ils ne prouvent ni que votre dépôt sera correctement validé, ni que l’environnement restera disponible pendant une longue tâche. La procédure officielle d’installation d’OpenHands détaille les prérequis et les modes de lancement.

Le cas d’échec le plus fréquent n’est donc pas « OpenHands ne démarre pas ». C’est plutôt :

1. l’agent clone le dépôt et modifie plusieurs fichiers ;
2. les tests génériques passent dans le conteneur ;
3. la compilation Apple échoue parce que Xcode, le bon SDK, un simulateur ou une identité de signature ne sont pas disponibles ;
4. le développeur découvre trop tard que le poste utilisé pour l’agent était aussi son poste de travail quotidien.

OpenHands peut-il être déployé directement sur un Mac ? Oui, à condition que Docker Desktop soit disponible et que vous acceptiez de partager les ressources, les ports et une partie de la maintenance avec votre environnement de développement. Cette réponse devient insuffisante dès que l’agent doit rester accessible à distance ou traiter plusieurs tâches sans interrompre votre travail.

Un Mac local reste pertinent dans trois situations précises

Le déploiement local possède un avantage immédiat : vous contrôlez directement le système, le dépôt, les volumes et les journaux. Pour une expérimentation courte, cette proximité réduit le temps de mise en route. Vous pouvez monter le répertoire courant, inspecter les fichiers modifiés et corriger manuellement une configuration sans organiser un accès distant.

Le local est généralement le meilleur choix lorsque :

• vous êtes la seule personne à utiliser OpenHands ;
• les tâches sont ponctuelles et lancées à la demande ;
• le Mac n’est pas votre poste principal, ou vous pouvez accepter qu’il soit momentanément moins réactif ;
• le dépôt ne contient pas de secrets de production ;
• la validation Apple est effectuée sur ce même Mac et vous avez déjà installé les composants nécessaires.

La limite apparaît avec les tâches longues. Un agent qui installe des dépendances, lance des tests, démarre un serveur local ou attend une réponse peut conserver des processus actifs bien après votre dernière interaction. La fermeture du portable, le redémarrage de Docker Desktop, la mise en veille ou la récupération du Mac pour une réunion deviennent alors des causes d’interruption.

Vous devez aussi compter les coûts invisibles :

• votre environnement de travail devient une dépendance de service ;
• les ports utilisés par l’agent peuvent entrer en conflit avec ceux de vos projets ;
• un volume monté trop largement augmente l’impact d’une mauvaise commande ;
• les mises à jour de macOS, Docker Desktop ou Xcode peuvent modifier le comportement attendu ;
• le diagnostic est plus difficile lorsque le problème touche simultanément votre poste et OpenHands.

Attention : la recommandation officielle de 4 Go concerne le démarrage d’OpenHands, pas une capacité garantie pour plusieurs agents, de gros dépôts, des compilations Xcode et des services auxiliaires exécutés en parallèle. Ne transformez pas ce minimum recommandé en dimensionnement de production.

Pour vérifier si le local suffit, ne vous contentez pas de regarder si l’interface s’ouvre. Lancez une tâche représentative, observez l’activité du processeur, de la mémoire, du stockage et du réseau dans le Moniteur d’activité, puis mesurez la durée jusqu’à la fin des tests. Il s’agit d’un protocole de vérification, pas d’une mesure publiée par SSHMac : aucun chiffre de consommation ne doit être déduit sans enregistrement sur votre configuration.

Docker Runtime isole l’exécution, pas tout votre ordinateur

Le Docker Runtime est conçu pour fournir à OpenHands un environnement où l’agent peut lire des fichiers, exécuter des commandes et démarrer des services sans travailler directement dans le processus principal de l’hôte. La documentation décrit le sandbox Docker comme le mode recommandé pour une exécution locale, tandis que le mode processus exécute l’agent directement sur la machine et ne fournit aucune isolation par conteneur. Consulter la présentation officielle des sandboxes OpenHands.

Cela ne signifie pas que Docker constitue une frontière de sécurité absolue. Le niveau de risque dépend notamment de quatre réglages :

• les volumes montés : un répertoire trop large donne à l’agent davantage de fichiers à lire ou modifier ;
• le socket Docker : le montage du socket du démon est une permission sensible et ne doit pas être traité comme un simple partage de fichier ;
• le réseau : une tâche qui peut contacter Internet peut télécharger des dépendances, transmettre des données ou appeler un service externe ;
• les identifiants : variables d’environnement, fichiers de configuration, clés SSH et trousseaux ne doivent pas être exposés par défaut.

La protection doit donc être pensée autour du moindre privilège. Utilisez un compte de travail séparé lorsque le risque le justifie, montez uniquement le dépôt nécessaire et évitez de transmettre au conteneur les répertoires contenant vos clés personnelles, vos profils de signature ou vos secrets de production. Une image isolée ne corrige pas une autorisation trop large donnée par l’hôte.

OpenHands local ou cloud : quelle approche est la plus sûre ? Le cloud n’est pas automatiquement sûr, mais un Mac distant dédié réduit le rayon d’impact par rapport à votre ordinateur personnel. Vous pouvez séparer les comptes, créer un répertoire de travail réservé, limiter les clés disponibles et réinitialiser la machine après une campagne de tests. En local, une mauvaise configuration peut toucher vos projets personnels, vos fichiers de conception, vos bibliothèques audio ou vos identifiants de développement.

Pour un projet créatif audio, vidéo ou design, cette séparation est particulièrement utile : les bibliothèques volumineuses, les fichiers sources et les outils de production n’ont pas besoin d’être visibles par l’agent de codage. Un environnement distant dédié permet de ne monter que le dépôt et les artefacts nécessaires.

La concurrence transforme un poste de développement en file d’attente

Un seul agent qui modifie un dépôt est un cas simple. Plusieurs agents qui travaillent en parallèle forment un problème d’orchestration.

Les conflits les plus courants concernent :

• le même port de serveur de développement ;
• le même répertoire de travail ;
• un cache de dépendances réutilisé au mauvais moment ;
• des fichiers de verrouillage laissés par une tâche interrompue ;
• une base de données locale ou un service auxiliaire partagé ;
• des versions différentes d’un paquet installées dans une même image ;
• des journaux mélangés, qui rendent l’analyse d’un échec incertaine.

Le Docker Runtime peut isoler les processus si chaque tâche obtient son propre conteneur et son propre espace de travail. Il ne résout toutefois pas automatiquement les conflits causés par des volumes communs, des ports fixes ou des ressources partagées. L’architecture officielle explique que le backend OpenHands communique avec le serveur d’exécution par une API et que les images de runtime, les volumes et les ports font partie de la conception de l’environnement. Lire l’architecture officielle du runtime OpenHands.

Quel environnement faut-il pour faire fonctionner plusieurs agents OpenHands ? Il faut d’abord séparer les unités d’exécution, puis définir une règle de réservation des ports, des répertoires et des caches. Pour un indépendant, un seul Mac local suffit généralement si les tâches sont séquentielles. Pour une petite équipe partageant un poste, un Mac dédié local peut convenir, mais il devient rapidement une file d’attente dès que chacun lance des tâches longues. Pour une plateforme automatisée, un environnement distant avec espaces de travail distincts est plus cohérent, même si sa mise en œuvre exige davantage de supervision.

La différence essentielle n’est donc pas seulement la puissance de la machine. C’est la capacité à répondre à cette question : si une tâche échoue ou reste bloquée, qui d’autre est affecté ?

La validation Apple doit se dérouler dans un vrai environnement macOS

Modifier du Swift n’est pas la même chose que valider une application Apple. Un agent peut analyser des fichiers source dans un environnement générique, installer des paquets et exécuter certains tests sans disposer de Xcode. Cela ne suffit pas pour vérifier un projet iOS ou macOS destiné à la livraison.

La chaîne d’acceptation peut nécessiter :

• la version de macOS compatible avec la version de Xcode choisie ;
• le SDK de la plateforme ciblée ;
• les composants de simulateur téléchargés dans Xcode ;
• les certificats, profils et réglages de signature ;
• un appareil physique ou un simulateur adapté ;
• des autorisations liées au trousseau, aux fichiers, à la caméra, au microphone ou à d’autres capacités ;
• une étape d’archivage, de signature ou de notarisation.

Apple précise que les simulateurs sont intégrés à Xcode, qu’ils ne reproduisent pas toutes les caractéristiques d’un appareil physique et que la validation de certains comportements doit être effectuée sur un appareil réel. Voir la documentation Apple sur l’exécution dans un simulateur ou sur un appareil.

La compatibilité dépend également du couple macOS-Xcode-SDK. Apple publie un tableau de compatibilité des versions prises en charge et indique les exigences associées à chaque version de Xcode. Vérifier les exigences système de Xcode.

Comment OpenHands traite-t-il les projets iOS et macOS ? Il peut modifier le code, préparer des scripts et lancer des commandes si les outils correspondants existent dans son environnement. En revanche, OpenHands ne peut pas rendre disponible par magie Xcode, un simulateur, un certificat ou un appareil connecté. Pour une équipe Apple, le bon schéma consiste souvent à faire effectuer l’analyse et la préparation dans un environnement agent isolé, puis à réaliser la compilation et l’acceptation sur un Mac qui possède effectivement la chaîne Xcode requise.

La signature est une autre frontière. Si votre pipeline exige un archivage signé, vous devez vérifier séparément les identités, les profils, les autorisations du trousseau et les règles de distribution. Ne donnez pas à un agent expérimental un accès permanent aux identifiants de livraison simplement pour éviter une étape manuelle de validation.

Première étape : préparer une épreuve représentative avant de choisir

Ne commencez pas par comparer des fiches techniques. Commencez par un dépôt réel, mais non critique, qui contient les mêmes types de dépendances et de validations que vos futurs projets.

Votre protocole peut suivre six étapes :

1. Choisissez un dépôt de référence. Il doit contenir au moins une tâche de modification, une installation de dépendances et une commande de test représentative. Pour un projet Apple, ajoutez une compilation ou une exécution sur simulateur lorsque cela est possible.

2. Lancez OpenHands avec le Docker Runtime. Montez uniquement le répertoire nécessaire, évitez le mode processus pour un dépôt non maîtrisé et n’exposez pas de clé de production. Le sandbox Docker est préférable lorsque l’isolation des tâches est un objectif explicite.

3. Mesurez la continuité, pas seulement le démarrage. Fermez puis rouvrez l’interface, interrompez une tâche, redémarrez le conteneur et vérifiez si l’état utile est conservé. Une solution qui fonctionne uniquement tant que votre session reste ouverte n’est pas encore une plateforme.

4. Répétez l’épreuve avec deux tâches. Utilisez deux copies distinctes du dépôt, deux ports et deux journaux. Notez les conflits de dépendances, les attentes inhabituelles et les erreurs impossibles à attribuer.

5. Validez l’acceptation Apple séparément. Vérifiez la version de Xcode, les composants installés, la destination de lancement, la signature et les autorisations. Si un seul élément manque, classez le problème comme une limite d’environnement, pas comme un simple bug de l’agent.

6. Décidez qui assure la maintenance. Sur un Mac local, vous êtes responsable de Docker Desktop, de macOS, de Xcode, des sauvegardes et des accès. Sur un Mac cloud, vous devez contrôler l’accès distant, la réinitialisation, les comptes et la conservation des données. Dans les deux cas, documentez la procédure de reconstruction.

Les dépendances et les images doivent être stabilisées avant la mise en service

Les tâches OpenHands installent parfois des outils ou utilisent une image de runtime contenant déjà une partie de l’environnement. La documentation officielle prévoit l’utilisation d’images personnalisées, de dépôts d’images et de balises de version ; elle décrit également un système de balises destiné à distinguer les versions et les sources d’image.

Cette distinction change votre décision :

• le Mac local facilite la réutilisation des caches et l’inspection immédiate des fichiers ;
• le Mac cloud permet de standardiser une image et de la recréer à l’identique ;
• une image personnalisée évite de réinstaller les mêmes dépendances à chaque tâche ;
• une balise flottante peut faciliter les mises à jour, mais rend les changements plus difficiles à attribuer ;
• une balise versionnée améliore la reproductibilité, à condition d’organiser les mises à jour.

Vous devez donc conserver séparément le code du projet, la définition de l’image, les variables de configuration et les journaux. Ne confondez pas un cache pratique avec une preuve de reproductibilité : un cache local peut masquer une dépendance absente de l’image réellement déployée.

Expérience à retenir : une image qui réussit sa première installation n’est pas forcément la meilleure image de service. Testez surtout sa reconstruction après suppression des caches, puis vérifiez que le même dépôt produit encore le même résultat.

La grille de décision pour choisir local, cloud ou hybride

Le tableau suivant donne une orientation éditoriale. Les notes ne sont pas des mesures de performance : elles traduisent l’adéquation de chaque modèle à la dimension concernée, sur une échelle de 1 à 5.

Lecture rapide des résultats

• Choisissez le Mac local quotidien si vous êtes seul, que les tâches sont rares et que l’interruption de l’agent ne met rien en production.
• Choisissez un Mac local dédié si vous voulez garder les données sur place, possédez plusieurs projets Apple et pouvez administrer la machine séparément de votre poste.
• Choisissez le Mac cloud dédié si plusieurs utilisateurs doivent accéder à OpenHands, si les tâches doivent continuer sans vous ou si les identifiants de travail doivent rester éloignés de votre ordinateur personnel.
• Choisissez l’hybride si les agents traitent le code général dans un environnement standardisé, mais que la compilation, le simulateur ou la signature doivent rester sur un Mac macOS contrôlé.

Pour accéder à une machine distante depuis votre navigateur ou un client graphique, vérifiez également le mode d’accès et la stabilité de la session. SSHMac présente les possibilités d’accès VNC à un Mac distant, ce qui peut être utile lorsque Xcode exige une intervention visuelle ou une autorisation locale.

Quel modèle reste durable après le premier mois ?

Le Mac local est souvent le meilleur laboratoire. Il permet de comprendre les commandes, les volumes montés, les limites de votre dépôt et les erreurs d’outillage sans ajouter une couche d’accès distant. Il devient moins convaincant lorsque vous devez garantir une disponibilité, répondre à plusieurs personnes ou protéger le poste de travail contre les tâches expérimentales.

Le Mac cloud demande davantage de préparation : authentification, accès distant, rotation des secrets, sauvegarde des réglages, supervision et procédure de remise à zéro. En contrepartie, il sépare mieux l’activité de l’agent de votre environnement quotidien et facilite la transmission d’un même accès à une équipe.

Le modèle hybride est généralement le plus rationnel pour une équipe Apple. Les tâches de génération, de refactorisation, de documentation et de tests génériques peuvent rester dans un environnement agent standardisé. La validation finale s’effectue ensuite sur un Mac qui possède les versions Xcode, les simulateurs, les certificats et les périphériques nécessaires.

Avant de louer une machine, consultez aussi le centre d’aide SSHMac afin de vérifier les modalités d’accès, de conservation des données et de support correspondant à votre usage.

La recommandation SSHMac pour votre scénario

Votre solution actuelle — OpenHands sur le Mac quotidien, un poste partagé ou un environnement générique non Apple — présente trois défauts concrets lorsqu’elle devient permanente : elle immobilise une machine de travail, mélange parfois les accès et les espaces de projet, et ne garantit pas que la chaîne Xcode utilisée pour l’acceptation soit disponible au moment critique. Dans une petite équipe, elle ajoute aussi une file d’attente difficile à prévoir dès que plusieurs agents lancent des tâches longues.

La meilleure approche consiste à exécuter un dépôt réel pendant une courte période, puis à comparer le résultat obtenu avec vos besoins d’accès distant, de concurrence et de validation Apple. Si le test reste individuel et occasionnel, le Mac local est parfaitement défendable. Si vous devez laisser OpenHands actif, isoler les identifiants ou accueillir plusieurs utilisateurs, louer un Mac cloud avec SSHMac offre une séparation plus nette et un accès distant plus adapté. Pour les projets iOS et macOS, confirmez toutefois avant toute décision longue que la machine retenue possède réellement la chaîne Xcode dont votre acceptation dépend.