Construire un flux de développement à distance sur un Mac cloud : réglages pratiques de VS Code Remote-SSH et JetBrains Gateway

Il est deux heures du matin. Depuis ton ordinateur portable à la maison, tu te connectes au Mac mini cloud que tu loues pour reprendre le build qui n'a pas fini de tourner dans la journée. VS Code affiche la barre de progression « Installation des extensions distantes » — elle tourne pendant quarante bonnes secondes, alors que la liste des extensions est exactement la même qu'hier, et pourtant tout est réinstallé depuis zéro. Cette impression de « rencontrer la machine pour la première fois à chaque fois » est le premier piège dans lequel tombent beaucoup de gens quand ils déplacent leur éditeur sur un Mac cloud pour la première fois. Ensuite viennent les sessions coupées par des micro-coupures réseau, et le débogage graphique tout simplement inutilisable. Cet article règle ces problèmes une fois pour toutes.

Pourquoi déplacer l'éditeur sur un Mac cloud plutôt que développer en local

Si tu te connectes seulement de temps en temps pour lancer un xcodebuild, un simple SSH avec la ligne de commande suffit. Mais si tu écris du code, débogues et lances des tests en permanence sur le Mac mini cloud, un terminal nu avec vim est nettement moins efficace qu'une IDE locale — pas de navigation sémantique dans le code, pas de débogage par points d'arrêt, et même la synchronisation du presse-papiers demande une configuration supplémentaire. La démarche la plus pertinente consiste à faire porter au Mac mini uniquement le calcul et la compilation, en laissant l'interface de l'éditeur en local, les deux étant reliés par un protocole distant. C'est justement le véritable usage d'un « Mac cloud » : la machine est une ressource physique qui t'est dédiée, à traiter comme ton propre ordinateur placé dans un datacenter, et non comme un conteneur jetable utilisé une fois puis abandonné.

Connecter le Mac cloud avec VS Code Remote-SSH

Le principe de VS Code Remote-SSH est simple : en local ne tourne qu'un client léger, tandis que les language servers, le terminal et le système de fichiers restent entièrement sur le Mac distant. À la première connexion, VS Code installe un binaire vscode-server ainsi que l'hôte d'extensions dans le répertoire ~/.vscode-server côté distant ; les connexions suivantes réutilisent cet environnement.

Configuration SSH et multiplexage de connexion

Par défaut, chaque connexion refait une poignée de main TCP + SSH complète — pour un accès transpacifique vers un nœud en Asie-Pacifique ou sur la côte ouest américaine, cette latence se traduit directement par « ouvrir un fichier prend un moment ». Le ControlMaster permet, via le multiplexage de connexion, d'économiser la majeure partie de ce coût de poignée de main :

# ~/.ssh/config
Host omac-jp
    HostName <IP de ton nœud>
    User devuser
    Port 22
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h-%p
    ControlPersist 10m
    ServerAliveInterval 30
    ServerAliveCountMax 3

ControlPersist 10m signifie qu'après la fermeture de la connexion principale ou de la fenêtre, le canal mutualisé reste disponible pendant 10 minutes supplémentaires : pendant ce temps, tout nouvel onglet de terminal ou reconnexion VS Code passe par cet ancien canal, évitant ainsi la renégociation du chiffrement. ServerAliveInterval, de son côté, contourne le problème de certains opérateurs dont le NAT coupe silencieusement les connexions inactives.

Cache des extensions et accélération de l'indexation

La « réinstallation systématique des extensions » évoquée plus haut n'est généralement pas un problème de VS Code lui-même, mais vient du fait que l'hôte distant a changé entre deux connexions — par exemple parce que tu as réinstallé le système via la console, ou que tu es passé à une autre instance. Tant que tu utilises systématiquement la même machine, les extensions, les caches de language servers, ainsi que les index TypeScript/Swift dans ~/.vscode-server persistent durablement : dès la deuxième connexion, tout devrait s'ouvrir quasi instantanément.

Si ton projet est volumineux (par exemple un projet Xcode avec plusieurs targets), tu peux lancer en amont une indexation complète côté distant avant de te déconnecter, pour préchauffer le cache :

cd ~/Projects/MyApp
xcodebuild -project MyApp.xcodeproj -scheme MyApp -showBuildSettings > /dev/null

Cette étape ne produit pas d'exécutable, mais construit à l'avance la base d'index d'Xcode, évitant ainsi une reconstruction à la volée lors des sauts vers les définitions dans l'éditeur.

Cas d'usage et limites de JetBrains Gateway

Si ton équipe déploie aussi, sur le même Mac cloud, un service backend (par exemple une API écrite en Kotlin/Go), JetBrains Gateway est une autre option : tu installes en local un client léger, tandis que le backend complet de l'IDE (IntelliJ IDEA, GoLand, etc.) tourne à distance, le rendu étant renvoyé en local via un protocole propriétaire — l'expérience se rapproche davantage d'un éditeur natif qu'une simple Web IDE.

La limite de Gateway est nette : il sert les écosystèmes de langages pour lesquels il existe un IDE JetBrains correspondant. Les outils propres à l'écosystème Apple — projets Xcode, Interface Builder, Swift Playgrounds — ne sont pas couverts par Gateway.

Autrement dit, pour du développement iOS/macOS pur sur un Mac cloud, la chaîne d'outils principale reste VS Code Remote-SSH (écrire du code, exécuter des scripts, consulter les logs) combiné à xcodebuild en terminal. Gateway convient mieux aux équipes qui font tourner « en parallèle » des services backend sur la même instance Mac.

Préserver les sessions avec tmux face aux instabilités réseau

Quelle que soit la solution d'édition à distance utilisée, dès que la connexion sous-jacente est du SSH, le risque de coupure existe — changer de Wi-Fi en déplacement, ou un simple redémarrage du routeur à la maison, peut couper la connexion instantanément. Si un build de 40 minutes tourne justement à ce moment-là, la coupure signifie que le processus de build est tué et que tout le travail effectué est perdu.

La solution consiste à lancer toutes les tâches longues dans une session tmux, plutôt que de les rattacher directement à la session SSH :

ssh omac-jp
tmux new -s build
xcodebuild -workspace MyApp.xcworkspace -scheme MyApp \
  -destination 'generic/platform=iOS' build 2>&1 | tee build.log

Après une coupure, il suffit de se reconnecter et d'exécuter tmux attach -t build pour retrouver exactement la sortie du terminal précédent — le processus de build n'est en rien affecté. Cette habitude n'est pas utile qu'aux builds : les fine-tunings de modèles longs, la surveillance de logs, ou les scripts de packaging fastlane devraient eux aussi tourner dans tmux.

Le débogage graphique : le compromis du VNC/partage d'écran

La ligne de commande couvre la majorité des cas, mais certaines tâches ne peuvent pas éviter l'interface graphique : consulter la timeline mémoire dans Instruments, ajuster des contraintes dans Interface Builder, ou simplement vérifier l'apparence réelle d'une UI une fois rendue. Il faut alors basculer vers le partage d'écran (VNC), dont l'expérience est radicalement différente de la ligne de commande — la latence y est beaucoup plus sensible. Il est recommandé de réduire la résolution à ce qui est réellement nécessaire (par exemple 1440×900 plutôt que du 4K) et de régler la profondeur de couleur sur « milliers de couleurs » : cela améliore nettement la fluidité pour un accès depuis une autre région. Au quotidien, privilégie SSH + éditeur comme méthode principale, et n'active l'interface graphique que ponctuellement selon le besoin — évite de laisser le VNC actif en permanence à consommer de la bande passante.

Checklist et retours d'expérience

Avant de mettre ce flux de travail en place, passe en revue les points suivants :

• configurer ControlMaster/ControlPersist dans le fichier SSH config, pour réduire la latence liée aux poignées de main répétées ;
• utiliser systématiquement la même instance, sans réinstaller fréquemment le système, sinon le cache des extensions et les index seront reconstruits à répétition ;
• placer toute tâche durant plus de quelques minutes dans une session tmux, plutôt que de la rattacher directement à une session SSH nue ;
• bien identifier les limites de Gateway pour le travail lié à Xcode — ne pas s'attendre à ce qu'il prenne en charge la chaîne d'outils graphique Apple ;
• activer le VNC pour le débogage graphique selon le besoin, et réduire résolution et profondeur de couleur pour gagner en fluidité ;
• pour le choix concret des types de machines et des nœuds disponibles, se référer à la configuration actuellement proposée dans la console, et planifier en conséquence les attentes de bande passante et de latence.

Questions fréquentes