Accès distant · Connectez-vous, puis compilez

Connectez-vous à votre Mac dans le cloud

VNC ouvre l’interface graphique de macOS ; SSH prend en charge les scripts et la CI. Vous accédez à un Mac physique dédié, pas à une machine virtuelle. Choisissez le bon accès pour le débogage Xcode et les builds automatisés.

Votre machine est prête ? Munissez-vous de son adresse, du port SSH, de votre nom d’utilisateur et de vos identifiants de connexion. Le tunnel SSH présenté ci-dessous est la méthode recommandée pour utiliser VNC.

Interface graphique
Partage d’écran VNC
Commandes
SSH / runner
Espace de travail macOS Illustration après connexion
Projet Xcode Vérification du build Release

Interface graphique et ligne de commande sur le même serveur physique

BuildSettings.xcconfigRelease
CONFIGURATION = Release
SDKROOT = iphoneos
DEBUG_INFORMATION_FORMAT = dwarf-with-dsym
ENABLE_TESTABILITY = NO
ArchivageSignatureExport
Aperçu du simulateur
Vérification de l’interface Mise en page · interactions
VNC : afficher et contrôler le bureau SSH : lancer des commandes de build
Illustration de l’espace de travail, sans bureau en temps réel ni mesure de performances. L’interface et les versions des outils dépendent de la configuration de la machine.
Choisissez votre accès

Besoin du bureau ou seulement de la ligne de commande ?

Lors de la première configuration de votre chaîne d’outils, utilisez le partage d’écran pour vérifier les réglages graphiques. Une fois le pipeline stabilisé, laissez le runner travailler en ligne de commande. Les deux méthodes accèdent à la même machine : inutile de configurer un environnement de build distinct pour les tâches graphiques.

Interface graphique

Partage d’écran VNC

Ouvrez Xcode, vérifiez le simulateur, consultez les réglages du trousseau et diagnostiquez les étapes qui nécessitent la souris. Vous voyez le bureau de la machine distante : la compilation ne s’exécute pas sur votre ordinateur.

  • Commencez avec un seul écran et une résolution raisonnable, puis vérifiez le texte, la souris et le clavier.
  • Utilisez de préférence un tunnel SSH et n’exposez pas directement le port VNC sur Internet.
  • Fermer le client VNC n’éteint pas la machine. Confiez les tâches longues à la CI ou à une session qui peut reprendre.
Idéal pour : débogage graphique, configuration initiale, diagnostic interactif
Ligne de commande

SSH et runner auto-hébergé

Installez des dépendances, lancez xcodebuild, consultez les journaux et enregistrez un runner CI. SSH ne transmet pas le bureau : vos scripts quotidiens n’ont pas besoin de laisser VNC connecté.

  • Lors de la première connexion, vérifiez l’empreinte de la machine avant d’accepter sa clé.
  • Pour l’administration interactive, privilégiez une clé publique SSH ; pour l’automatisation, utilisez des identifiants distincts et révocables.
  • Confiez les builds continus au service runner, sans laisser un terminal ouvert sur votre ordinateur portable.
Idéal pour : builds automatisés, gestion des dépendances, diagnostic des journaux

Le mot de passe du bureau VNC, le mot de passe SSH et la phrase secrète de votre clé privée sont trois éléments distincts. En cas d’échec, vérifiez d’abord les identifiants associés au protocole utilisé avant de modifier les réglages du client.

Client macOS

Lancez la connexion depuis le Finder et partagez le bureau

Commencez par établir le tunnel SSH décrit plus bas, puis connectez-vous à l’adresse transférée localement. Le trafic VNC emprunte ainsi un canal chiffré, sans qu’il soit nécessaire d’ouvrir séparément le port du bureau distant.

  1. 01

    Vérifiez les informations de connexion

    Connectez-vous au portail et consultez les informations de connexion de l’instance concernée. Notez l’adresse de la machine, le port SSH et le nom d’utilisateur ; vérifiez séparément les identifiants VNC. Si l’adresse ou le port diffère de l’exemple, utilisez toujours les valeurs indiquées pour votre instance.

  2. 02

    Laissez le tunnel ouvert

    Dans un terminal local, exécutez la commande de transfert présentée sur cette page. Avec l’option -N, l’absence d’invite de commande interactive après la connexion est normale. Laissez le terminal ouvert. En cas d’erreur, corrigez-la avant de tenter de vous connecter au bureau.

  3. 03

    Saisissez l’adresse VNC

    Dans le Finder, choisissez « Aller → Se connecter au serveur », ou appuyez sur ⌘ K, puis saisissez vnc://127.0.0.1:15900. L’app « Partage d’écran » s’ouvre. Suivez les instructions pour saisir les identifiants VNC de la machine distante.

  4. 04

    Testez avant d’ajuster l’affichage

    Vérifiez d’abord que vous pouvez utiliser le Finder, saisir du texte et ouvrir Xcode. Pour interagir, choisissez le mode contrôle plutôt que le mode observation. Si le bureau dépasse la fenêtre locale, activez la mise à l’échelle avant d’ajuster la qualité selon votre réseau.

L’adresse de bouclage locale n’est accessible que depuis l’ordinateur où le tunnel est actif. Pour ouvrir le client sur un autre ordinateur, créez-y un tunnel distinct : la connexion locale du premier ordinateur ne peut pas être réutilisée.

Clients Windows / Linux

Renseignez séparément la machine et le port, puis commencez avec une qualité modérée

Utilisez un client compatible VNC, par exemple TigerVNC. Sous Windows, vous pouvez créer le tunnel avec le client OpenSSH ; sous Linux, utilisez la commande ssh dans un terminal. Connectez ensuite le client graphique au port transféré localement.

Windows : lancez SSH, puis le client VNC

Exécutez la commande de création du tunnel dans PowerShell ou Windows Terminal. Si le système indique que ssh est introuvable, vérifiez que la fonctionnalité client OpenSSH est installée.

Dans le client VNC, saisissez 127.0.0.1 dans le champ de l’hôte et 15900 dans celui du port. Certains clients interprètent le nombre après un deux-points comme un numéro d’affichage. Si vous ne disposez que d’un champ d’adresse, suivez le format de « port explicite » propre au client.

Clavier : vérifiez d’abord les touches Command, Option et les raccourcis usuels.

Linux : diagnostiquez séparément le tunnel et l’affichage

Laissez le tunnel SSH ouvert dans un terminal, puis lancez le client graphique VNC. Si le tunnel est fermé, l’échec de connexion au port local du client ne signifie pas que le mot de passe du bureau distant est incorrect.

Si vous installez le client via le gestionnaire de paquets, choisissez une version compatible avec la méthode d’authentification distante. En cas de message « type de sécurité non pris en charge », vérifiez la compatibilité au lieu de désactiver l’authentification ou d’affaiblir la sécurité du serveur.

Réseau : vérifiez que le client se connecte bien au port transféré localement.
Ces réglages constituent un point de départ, pas une garantie de qualité d’image ou de fréquence d’images. Les options varient selon la version du client.
Réglage Valeur de départ Quand l’ajuster
Profondeur de couleur Automatique ; essayez 16 bits si la connexion est limitée Choisissez les couleurs complètes pour vérifier des captures d’écran, des couleurs ou des caractères fins. Une profondeur réduite ne convient pas à la validation des couleurs.
Encodage et compression Conservez l’encodage automatique et activez la compression adaptative Augmentez légèrement la compression si les fenêtres saccadent au déplacement ; réduisez la compression avec perte si le texte devient flou.
Taille du bureau Commencez par 1440 × 900 ou 1600 × 900 Augmentez la résolution une fois l’interaction stable, afin d’éviter de transmettre d’emblée de grandes images haute résolution.
Actualisation continue Utilisez la mise à jour adaptative et désactivez l’actualisation continue si elle est inutile Augmentez la fréquence de rafraîchissement uniquement pour diagnostiquer une interface dynamique. La modification de code n’exige pas une mise à jour vidéo.
Presse-papiers Activez la synchronisation selon vos besoins ; désactivez-la pour les opérations sensibles Avant de copier un mot de passe de certificat ou des identifiants, vérifiez le sens de synchronisation entre votre ordinateur et la machine distante.
Connexion recommandée

Faites passer VNC par un tunnel SSH

Les adresses ci-dessous sont fournies à titre d’exemple et ne permettent pas de se connecter. Remplacez 192.0.2.10, macuser et le port par les informations de connexion indiquées dans le portail. Cet exemple suppose que le service VNC distant écoute sur le port 5900 de la machine.

Client local127.0.0.1:15900
Canal SSH chiffréAdresse de la machine et port SSH
Service VNC distant127.0.0.1:5900
À exécuter sur votre ordinateur
ssh -N -T -L 127.0.0.1:15900:127.0.0.1:5900 -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -p 22 macuser@192.0.2.10

Fonctionnement de la commande

-L écoute uniquement sur l’adresse de bouclage locale. Le premier port est le point d’accès local ; le dernier est celui du service VNC distant. -p définit le port SSH, et non le port VNC. -N -T ne fait que transférer le trafic, sans ouvrir de terminal interactif distant.

Vérifier la connexion et fermer le tunnel

Lors de la première connexion, vérifiez l’empreinte SSH. Une fois la connexion établie, connectez le client au port local ; appuyez sur Ctrl C pour fermer le tunnel. Si le port local est déjà utilisé, remplacez 15900 par un port libre et modifiez aussi l’adresse dans le client.

Diagnostiquez chaque couche

En cas de délai d’attente, vérifiez l’adresse, le port SSH et les restrictions réseau. En cas d’échec d’authentification, vérifiez le nom d’utilisateur et la clé. Si le transfert est refusé, vérifiez le service VNC distant et son port. Ne tentez pas de résoudre tous les problèmes de connexion en changeant plusieurs fois le mot de passe.

Vérifiez la connexion par clé avant de désactiver les mots de passe

Créez une clé Ed25519 dédiée sur votre ordinateur et protégez-la par une phrase secrète. Ajoutez uniquement la clé publique au fichier ~/.ssh/authorized_keys de l’utilisateur distant. Gardez la clé privée sur votre ordinateur ; ne la téléversez ni sur la machine, ni dans un dépôt ou un ticket.

Si une clé portant déjà ce nom existe, ne l’écrasez pas. Choisissez un autre nom de fichier et indiquez-le avec -i lors de la connexion. Le fichier de clé publique se termine par .pub ; la clé privée n’a pas cette extension.

Créer une clé dédiée à la connexion
ssh-keygen -t ed25519 -a 64 -f ~/.ssh/armrdp_ed25519

Sous macOS et Linux, le répertoire ~/.ssh de l’utilisateur distant est généralement réglé sur 700 et le fichier authorized_keys sur 600. Sur Windows, limitez l’accès à la clé privée locale au moyen des permissions de fichier ; ne reproduisez pas mécaniquement les commandes de permissions Unix.

Affichage et réseau

Allégez d’abord l’affichage, puis évaluez la distance au serveur

La compilation s’exécute à distance, mais la réactivité du bureau dépend aussi de votre réseau local, du routage, de la résolution et de la quantité de changements à transmettre. Ne prenez pas le déplacement d’une fenêtre VNC pour une mesure des performances de la machine, et ne déduisez pas la latence de la seule distance géographique.

  1. 01

    Réduisez d’abord la zone affichée

    Gardez un seul écran et limitez les bureaux haute résolution, les fonds animés et les animations de fenêtres. Réduire la taille du bureau distant diminue davantage les données à transmettre que de simplement réduire la fenêtre du client local.

  2. 02

    Ne modifiez qu’un réglage à la fois

    Testez successivement la résolution, la profondeur de couleur et la compression. Répétez une même action, par exemple ouvrir le même projet ou déplacer la même fenêtre. Si vous modifiez plusieurs réglages ensemble, vous ne saurez pas lequel a fait la différence.

  3. 03

    Vérifiez ensuite le réseau

    Mettez en pause les transferts de fichiers volumineux sur votre réseau local et privilégiez une connexion filaire stable. Comparez la réactivité de SSH avec le rafraîchissement de VNC : si le premier est fluide et le second lent, vérifiez d’abord les réglages d’affichage au lieu de changer immédiatement de machine.

Repères géographiques et horaires pour les 5 nœuds. Il ne s’agit pas de mesures de latence réalisées dans chaque ville ; la disponibilité indiquée par le portail fait foi.
Nœud Fuseau horaire local À prendre en compte
Singapour UTC+8 Si votre équipe se trouve principalement en Asie du Sud-Est, commencez par tester ce nœud.
Japon (Tokyo) UTC+9 Si votre équipe se trouve principalement au Japon ou en Asie de l’Est, comparez le routage réel depuis votre réseau.
Corée du Sud (Séoul) UTC+9 Si votre équipe se trouve principalement en Corée du Sud ou en Asie du Nord-Est, tenez compte du routage de votre opérateur.
Hong Kong UTC+8 Si votre équipe se trouve principalement dans le sud de la Chine ou en Asie du Sud-Est, vérifiez la réactivité et le chemin d’accès à votre dépôt.
Ouest des États-Unis UTC−8 / UTC−7 À privilégier si votre équipe se trouve surtout sur la côte ouest de l’Amérique du Nord. Le fuseau varie avec l’heure d’été locale.

Si vous n’utilisez le bureau qu’occasionnellement pour la configuration, tenez aussi compte de l’emplacement de votre dépôt, du cache des dépendances et du chemin utilisé pour téléverser les artefacts. Pour les builds réguliers, privilégiez la stabilité de la chaîne d’outils et du pipeline : VNC n’a pas besoin de rester connecté toute la nuit.

Sécurité des connexions

À chaque renforcement, gardez une méthode de vérification

L’ordre des changements de sécurité compte. Vérifiez d’abord que la nouvelle méthode fonctionne, puis révoquez l’ancienne. Évitez de modifier en même temps les clés, les adresses autorisées et les règles d’authentification : vous pourriez ne plus savoir d’où vient le problème.

Avant de désactiver l’authentification par mot de passe

Gardez votre session SSH actuelle ouverte. Dans un autre terminal, établissez une nouvelle connexion avec la clé prévue et vérifiez que vous disposez des droits d’administration nécessaires. Une fois la connexion testée, modifiez les règles d’authentification SSH par mot de passe. Vérifiez la syntaxe de la configuration avant de l’appliquer selon le mode de gestion des services de votre système.

Validation : une nouvelle session s’ouvre avec la clé publique et les commandes nécessaires s’exécutent normalement.

Avant de restreindre les adresses IP sources

Vérifiez d’abord si l’adresse IP publique de sortie de votre réseau local est fixe, puis autorisez-la dans les règles réseau ou d’accès à la machine concernées. Ne considérez pas l’adresse temporaire de votre réseau domestique comme permanente et n’appliquez pas de commande de pare-feu à une interface que vous n’avez pas identifiée.

Validation : les réseaux autorisés peuvent se connecter et les autres sources ne peuvent pas accéder aux ports concernés.

Renouvelez régulièrement les identifiants

Utilisez des clés distinctes pour chaque personne et chaque tâche automatisée. Lorsqu’un membre quitte l’équipe, qu’un appareil est perdu ou qu’une clé risque d’avoir été divulguée, déployez et testez une nouvelle clé publique avant de supprimer l’ancienne. Vérifiez aussi les identifiants enregistrés dans la CI et les journaux d’accès associés.

Validation : l’ancienne clé est révoquée et le runner ainsi que les connexions d’administration fonctionnent toujours.

La connexion échoue toujours ? Précisez à quelle étape

Connectez-vous au portail pour ouvrir un ticket. Indiquez l’identifiant de la machine, le système et la version du client, le protocole utilisé, le message d’erreur exact, la date et le fuseau horaire, ainsi que l’utilisation éventuelle d’un tunnel SSH. Avant d’ajouter une capture d’écran, masquez les mots de passe, jetons et autres informations sensibles. N’envoyez jamais de clé privée ni de certificat complet.

Testez la connexion, puis confiez les builds au runner

Louez à la journée pour effectuer un test ponctuel, à partir de $21.1/jour. Vérifiez d’abord que SSH et le partage d’écran fonctionnent, puis fixez les versions de Xcode et de vos dépendances pour compiler au quotidien sans laisser votre ordinateur connecté.