Connectez-vous avant de lancer les tests

SSH pour les commandes, VNC pour le bureau :
les deux fonctionnent

Vous vous connectez à un Mac physique dédié, et non à une machine virtuelle. Consultez l’adresse IP, le port de connexion et les identifiants dans la fiche de la machine, sur la console. Utilisez SSH pour compiler et lancer des tests, et VNC pour accéder à l’interface graphique de macOS. Vous pouvez combiner les deux méthodes sans devoir effectuer chaque compilation depuis le bureau distant.

Louer un Mac dans le cloud Trouver mes identifiants

Vous avez passé commande ? Vérifiez d’abord que la machine est livrée, puis connectez-vous. Le port, le nom d’utilisateur et le mode d’authentification sont indiqués dans la fiche de votre instance : ne les déduisez pas d’un exemple.

Choisissez selon votre tâche

SSH pour compiler, VNC pour l’interface graphique

Commencez par établir une connexion stable en ligne de commande, puis ouvrez le bureau. Vous pourrez ainsi distinguer les problèmes de réseau de ceux d’authentification et éviter que le rafraîchissement du bureau n’empiète sur la bande passante nécessaire au retour des journaux de compilation.

SSH : exécuter des commandes sur la machine

Idéal pour exécuter xcodebuild et des scripts, consulter les journaux et gérer les artefacts de compilation. Vous pouvez utiliser Terminal sur macOS, OpenSSH dans Windows Terminal ou un client SSH sous Linux.

  • Relevez le port SSH dans la fiche de l’instance. Le port 22 est souvent utilisé par défaut, mais ce n’est pas nécessairement celui de votre instance.
  • Lors de la première connexion, vérifiez l’empreinte de l’hôte. Confirmez que vous vous connectez à la bonne machine avant de vous authentifier.
  • Configurez l’authentification par clé publique. Gardez votre clé privée en local : ne la placez ni dans le dépôt du projet ni dans un ticket.
  • Pour les tâches longues, utilisez une session persistante ou un exécuteur de pipeline déjà configuré. Ne comptez pas sur l’état de connexion de votre terminal local pour garantir leur exécution.
Voir les exemples SSH et compilation

VNC : afficher directement le bureau macOS

Idéal pour modifier les réglages du projet, vérifier l’affichage du simulateur et diagnostiquer les problèmes visibles uniquement dans l’interface graphique. Vous pouvez utiliser le partage d’écran de macOS ou un client compatible comme RealVNC. Les modes d’authentification disponibles dépendent du client et des réglages de l’instance.

  • Dans le client, indiquez l’adresse IP de l’instance et le port VNC. N’utilisez pas le port SSH pour accéder au bureau.
  • Utilisez les identifiants d’accès au bureau indiqués dans la fiche de l’instance ; ne supposez pas qu’ils sont identiques à ceux de SSH.
  • Pour commencer, essayez une résolution de 1440 × 900, puis ajustez-la en fonction de votre écran et de votre réseau.
  • Si votre client le permet, essayez d’abord une profondeur de couleur de 16 bits. Augmentez la qualité si vous devez examiner les détails des couleurs.
Voir l’ordre des réglages du bureau

Le VNC ne remplace pas l’accès aux périphériques USB locaux. Les tests sur simulateur et l’accès au bureau distant peuvent être planifiés directement. Si vos tests nécessitent un périphérique externe, vérifiez d’abord les conditions de connexion avant de choisir votre offre.

De la connexion aux résultats des tests

Vérifiez l’empreinte avant d’exécuter les commandes du projet

Les exemples ci-dessous illustrent des journaux et ne reflètent pas l’état actuel d’un nœud. Définissez localement les variables d’environnement avec les valeurs réelles de votre instance. App est un nom de scheme donné à titre d’exemple : remplacez-le par un nom présent dans votre projet.

metalvnc — tokyo-node — zsh 
$ ssh -p "$SSH_PORT" "$MAC_USER@$MAC_IP"

The authenticity of host cannot be established.
ED25519 key fingerprint is displayed by your SSH client.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
yes
Authenticated using publickey.

$ xcode-select -p
/Applications/Xcode.app/Contents/Developer

$ xcrun simctl list devices available
== Devices ==
Available simulators are listed by the installed runtime.

$ xcodebuild -scheme App -destination 'platform=iOS Simulator' test
Test Suite 'AppTests' started.
Executed 128 tests, with 0 failures.
** TEST SUCCEEDED **

$ fastlane beta
Build processing completed.
Upload completed successfully.
fastlane finished successfully.

Ordre de lecture : confirmez l’authentification SSH → vérifiez la chaîne d’outils → vérifiez les simulateurs → lancez les tests → contrôlez la compilation et l’envoi.

Les 128 tests réussis et les 0 échec de l’exemple illustrent uniquement la lecture des journaux. Le nombre de tests, leur durée et le résultat de l’envoi dépendent de votre projet.

Empreinte différente ? Vérifiez avant de continuer

Lors de la première connexion, comparez l’empreinte affichée dans le terminal à une valeur provenant d’une source fiable. Si la fiche de l’instance n’indique pas l’empreinte, confirmez-la via un ticket dans la console. Si un avertissement signale ensuite un changement d’identité de l’hôte, ne supprimez pas l’ancienne entrée pour passer outre : vérifiez d’abord si la machine a été réinstallée ou remplacée.

Une commande qui s’exécute ne signifie pas que le projet est configuré

Avant de lancer les tests, vérifiez le chemin de Xcode, le runtime du simulateur, les dépendances du projet et le scheme partagé. fastlane beta nécessite un lane correspondant dans le projet, les éléments de signature et les identifiants d’envoi. Ce n’est pas une commande d’envoi universelle utilisable telle quelle dans n’importe quel projet.

Comparez les nœuds dans les mêmes conditions

Mesurez d’abord la latence aller-retour, puis évaluez le confort du bureau

Vous avez le choix entre Singapour, Tokyo, Séoul et Hong Kong. La qualité de la liaison entre votre ville et le nœud influe davantage sur la réactivité que la distance géographique. Les résultats peuvent aussi varier selon l’opérateur, même dans une même ville.

État des données : Aucune mesure vérifiable par ville n’est disponible pour le moment. Le tableau indique donc « Non mesuré » au lieu de présenter des estimations comme des médianes mesurées. Avant de choisir, effectuez vos propres tests réseau. Pour évaluer la liaison en amont, contactez-nous par e-mail ou ouvrez un ticket dans la console.

Ville d’origine × nœud : médiane de la latence ICMP aller-retour, en ms
Ville de testSingapourTokyoSéoulHong Kong
ShanghaiNon mesuréNon mesuréNon mesuréNon mesuré
ShenzhenNon mesuréNon mesuréNon mesuréNon mesuré
TaipeiNon mesuréNon mesuréNon mesuréNon mesuré
BangkokNon mesuréNon mesuréNon mesuréNon mesuré
SydneyNon mesuréNon mesuréNon mesuréNon mesuré
Los AngelesNon mesuréNon mesuréNon mesuréNon mesuré
Protocole de mesure commun : connexion Internet résidentielle, aux heures de pointe du soir à Pékin. Envoyez 100 requêtes ICMP à chaque destination, calculez la médiane des temps aller-retour des réponses reçues et consignez également le taux de perte de paquets. Ce tableau répertorie les mesures à effectuer : il ne s’agit pas d’un rapport déjà établi. Les résultats ultérieurs sont fournis à titre indicatif et ne constituent pas une garantie de latence.

Lancez les tests en local, pas depuis la machine distante

Exécutez la commande ci-dessous en local sous macOS ou Linux. Sous Windows, utilisez ping -n 100 suivi de l’adresse IP cible. Notez l’opérateur d’origine, l’heure, le nombre de réponses reçues et la sortie brute. Pour comparer les résultats, gardez le réseau et les conditions identiques.

ping -c 100 "$MAC_IP"

Ne vous limitez pas à la médiane : observez aussi la gigue et les pertes

La moyenne récapitulative de ping n’est pas la médiane : calculez celle-ci à partir des temps de réponse bruts. Des pertes de paquets répétées ou des pics de latence occasionnels peuvent rendre le VNC saccadé, même si la médiane est faible. Si les requêtes ICMP sont filtrées, cela ne signifie pas que SSH ou VNC est inaccessible : vérifiez les ports de connexion concernés.

Enfin, testez le bureau avec la même résolution, la même profondeur de couleur et la même séquence d’actions : saisissez du texte, faites glisser une fenêtre et vérifiez la régularité du rafraîchissement.

Ne changez qu’un paramètre à la fois

Réservez la bande passante aux images que vous devez vraiment voir

Commencez par des réglages peu gourmands pour établir une référence, puis augmentez la qualité étape par étape. Après chaque modification, répétez la saisie, le défilement et le déplacement d’une fenêtre. Ne changez pas les quatre options en même temps : vous ne sauriez pas laquelle a fait la différence.

  1. 01

    Réduisez la profondeur de couleur

    Si votre client le permet, commencez par une profondeur de couleur de 16 bits ou un réglage de qualité inférieur afin de réduire le volume de données transférées à chaque rafraîchissement. Rétablissez une qualité supérieure pour examiner une maquette, des couleurs ou un problème de capture d’écran. Une faible profondeur de couleur ne convient pas à la validation des couleurs.

  2. 02

    Désactivez le fond d’écran animé

    Choisissez un fond d’écran fixe et arrêtez les vidéos et animations inutiles. Le rafraîchissement de l’arrière-plan consomme de la bande passante pour des pixels sans rapport avec votre tâche. Pour examiner les animations du simulateur, ne gardez à l’écran que les fenêtres nécessaires.

  3. 03

    Limitez la résolution

    Commencez par 1440 × 900, puis augmentez la résolution une fois que l’éditeur et la fenêtre de test sont lisibles. Ne réglez pas automatiquement le bureau distant sur la résolution maximale prise en charge par votre écran local : davantage de pixels sollicitent plus le transfert et le décodage.

  4. 04

    En cas de réseau lent, privilégiez la ligne de commande

    Utilisez SSH pour les compilations, l’installation des dépendances et la consultation des journaux. Ouvrez VNC uniquement lorsque l’interface est nécessaire. Transférez séparément les artefacts et les journaux pour éviter que les fichiers volumineux et le rafraîchissement du bureau ne se disputent la bande passante montante.

Une fois connecté, limitez les accès

Gardez une session de secours avant de modifier l’authentification

Une machine physique dédiée vous laisse gérer votre environnement, mais ne rend pas automatiquement les connexions publiques sécurisées. Avant toute modification de l’authentification ou du pare-feu, gardez une session connectée et vérifiez les nouveaux réglages dans une deuxième session.

Changez le mot de passe initial

Après la livraison, remplacez rapidement le mot de passe initial par un mot de passe unique et suffisamment long. Ne réutilisez pas celui de votre dépôt de code ni de votre messagerie. Conservez les identifiants uniquement dans un gestionnaire de mots de passe sécurisé, jamais dans les journaux de compilation ou le dépôt.

Vérification : testez les nouveaux identifiants dans une nouvelle session, puis fermez l’ancienne une fois la connexion confirmée.

Authentifiez SSH uniquement par clé

Installez d’abord la clé publique et vérifiez la connexion avec la clé privée avant de modifier la politique d’authentification SSH. Utilisez des clés distinctes pour les tâches automatisées et attribuez à chacune les droits nécessaires. Révoquez rapidement la clé publique concernée lorsqu’une personne quitte l’équipe ou qu’une clé est compromise.

Vérification : un deuxième terminal se connecte avec la clé privée prévue, sans dépendre de l’ancienne session.

N’ouvrez que les ports nécessaires

Ne conservez que les accès requis par vos tâches et, si possible, limitez-les aux adresses IP autorisées. Privilégiez une connexion protégée pour le bureau distant. Vérifiez séparément les règles SSH et VNC ; ne désactivez pas durablement toutes les protections pour diagnostiquer un problème.

Vérification : les ports nécessaires sont accessibles et les accès inutiles restent fermés.

Verrouillez le bureau avant de partir

À la fin d’une session de débogage, verrouillez l’écran, déconnectez le client et supprimez les fichiers sensibles téléchargés temporairement. Ne partagez pas une même clé privée avec l’équipe. Gérez les clés et certificats nécessaires aux compilations selon les procédures déjà en place dans votre équipe.

Vérification : une authentification est requise pour accéder de nouveau au bureau ; les journaux et captures d’écran ne contiennent aucun secret.

Diagnostiquez chaque étape de la connexion

Impossible de se connecter ? Ne réinstallez pas tout de suite le système

Commencez par distinguer un délai d’attente, un refus de connexion et un échec d’authentification. Vérifiez une seule couche à la fois et conservez le message d’erreur d’origine. Modifier plusieurs fois le mot de passe, le port et le pare-feu risque d’effacer les indices utiles.

  1. 01

    Vérifiez l’adresse IP et l’instance

    Rouvrez la fiche de la machine dans la console. Vérifiez que l’instance est livrée et que l’adresse cible correspond à la machine actuelle. N’utilisez pas une ancienne note, une capture d’écran ou l’adresse d’une autre machine. Ne saisissez pas non plus directement les noms de variables d’un exemple dans le client.

  2. 02

    Vérifiez le protocole et le port

    Utilisez le port SSH dans le client SSH et le port du bureau dans le client VNC. En cas de délai d’attente, vérifiez d’abord le réseau et les règles ; en cas de refus de connexion, vérifiez le port et l’écoute du service. Une réponse au ping ne garantit pas l’accès au port de l’application.

  3. 03

    Vérifiez le nom d’utilisateur et les identifiants

    En cas d’échec d’authentification, vérifiez le nom d’utilisateur, le fichier de clé et le mode d’authentification choisi dans le client. Éliminez les espaces ajoutés lors d’un copier-coller et assurez-vous d’utiliser les identifiants de l’instance actuelle. Si l’empreinte de l’hôte semble anormale, vérifiez son identité sans ignorer l’avertissement.

  4. 04

    Vérifiez les règles réseau locales

    Vérifiez le pare-feu de votre machine, le proxy, la sortie réseau de l’entreprise et les autorisations du client. Si vous y êtes autorisé, refaites le test sur un autre réseau pour savoir si le problème dépend de la liaison. Ne désactivez pas durablement votre logiciel de sécurité pour réussir une connexion ponctuelle.

Toujours bloqué ? Ouvrez un ticket reproductible

Indiquez l’identifiant de l’instance, le protocole de connexion, le port cible, le message d’erreur exact, la date et l’heure avec le fuseau horaire, ainsi que les vérifications déjà effectuées. Préciser « SSH fonctionne, mais pas VNC » est plus utile que d’écrire seulement « impossible de se connecter ». Avant de joindre des captures d’écran ou des journaux, retirez les mots de passe, clés privées, jetons et autres informations sensibles.

Pour un problème lié à une machine déjà achetée, ouvrez un ticket dans la console afin qu’il soit associé à l’instance. Pour une question avant achat sur la liaison réseau ou la compatibilité d’un client, écrivez à support@metalvnc.com.

Ouvrir un ticket dans la console Voir les autres guides
Vous savez comment vous connecter

Choisissez le nœud le plus proche et démarrez

Comparez la mémoire et le stockage des deux configurations M4, puis choisissez un nœud et une durée de facturation. Testez SSH et le bureau sur votre réseau avant de planifier des compilations continues. La disponibilité indiquée dans la console fait foi.

Louer un Mac dans le cloud Choisir une configuration et une durée de facturation