Récapitulatif de connexion

Connectez-vous à
votre Mac en moins de dix minutes

Vérifiez la connexion avec SSH avant d’ouvrir le partage d’écran. Vous disposez d’un Mac mini physique dédié, avec accès complet à l’interface macOS et à la ligne de commande, idéal pour le télétravail, les builds et les tests.

Les dix minutes correspondent à un objectif de connexion, une fois les identifiants reçus et le client ainsi que le réseau prêts. Ce délai ne concerne pas la livraison de la commande. Utilisez l’adresse, le port et le mode d’authentification indiqués dans la console.

Louer un Mac cloud Voir les identifiants dans la console
Choisissez votre mode d’accès

Le partage d’écran pour le bureau, SSH pour l’automatisation

Utilisez l’interface graphique pour les réglages quotidiens ; privilégiez la ligne de commande pour les compilations, les journaux et les transferts de fichiers. Ces deux modes d’accès se complètent : inutile de garder le bureau ouvert pendant chaque build.

Les ports du tableau sont les ports par défaut des services. Pour vous connecter, utilisez ceux indiqués dans la console.
Mode de connexionUtilisationPort requisAuthentification et remarques
Partage d’écran macOSConfigurer Xcode, utiliser le simulateur, vérifier l’interface graphique et travailler à distanceVNC : TCP 5900 par défaut ; en mode tunnel, ajouter le port SSHUtilisez l’authentification du compte système fourni. La connexion au bureau ne remplace pas l’authentification par clé SSH.
Client VNC tiersAccéder au bureau macOS depuis Windows ou LinuxVNC : TCP 5900 par défaut, ou port du tunnel local dans le clientLe client doit prendre en charge le mode d’authentification du serveur. Pour résoudre un problème de compatibilité, ne désactivez pas l’authentification et n’autorisez pas toutes les sources.
SSH en ligne de commandeLancer des builds, consulter les journaux, enregistrer un runner et transférer des fichiers avec SFTPSSH : TCP 22 par défaut ; le port exposé sur Internet est indiqué dans la consolePrivilégiez l’authentification par clé publique. Lors de la première connexion, vérifiez l’empreinte de l’hôte avant de lui faire confiance.

Vérifiez d’abord le port, puis cherchez le problème côté client.En cas de délai d’attente, commencez par vérifier l’adresse, les règles de trafic sortant et le port cible. Si une demande d’authentification s’affiche, le réseau fonctionne généralement : vérifiez alors le nom d’utilisateur, le mot de passe ou la clé.

Suivez les étapes de votre système

Trois clients, une même méthode de vérification

Commencez par ouvrir une session SSH pour vérifier l’identité de l’instance et le répertoire de travail, puis connectez-vous au bureau. Les étapes ci-dessous ne nécessitent ni de désactiver le pare-feu local ni d’exposer votre Mac cloud à toutes les sources.

Se connecter depuis macOS

  1. Ouvrez Terminal et connectez-vous avec le nom d’utilisateur, l’adresse et le port SSH indiqués dans la console. À la première demande de vérification de l’empreinte, contrôlez-la avant de confirmer.
  2. Pour accéder au bureau, ouvrez Partage d’écran et saisissez l’adresse de partage d’écran de l’instance. Si vous utilisez un tunnel, indiquez plutôt l’adresse et le port d’écoute locaux.
  3. Saisissez le nom d’utilisateur système et le mot de passe. Une fois sur le bureau, vérifiez la disposition du clavier, la résolution de l’écran et le fuseau horaire, puis ouvrez votre projet.
  4. Avant de fermer la session de bureau, vérifiez que les journaux de build ont bien été enregistrés. Fermer le partage d’écran n’arrête ni la location ni les tâches en arrière-plan.

Vérification initiale : le terminal affiche les informations système, Finder s’ouvre et le répertoire du projet est accessible en écriture.

Se connecter depuis Windows

  1. Dans PowerShell, vérifiez que le client OpenSSH est disponible. Si votre appareil professionnel ne permet pas l’installation de composants, demandez d’abord conseil à votre administrateur local.
  2. Utilisez SSH pour vérifier l’adresse et le port. Il est normal que les caractères ne s’affichent pas lorsque vous saisissez le mot de passe : ne le collez pas plusieurs fois.
  3. Installez un client VNC compatible avec l’authentification du partage d’écran macOS, puis renseignez l’hôte et le port séparément. Le format de l’adresse varie selon les clients.
  4. Il est recommandé d’accéder au bureau via un tunnel SSH. En cas d’échec de la négociation, vérifiez d’abord la compatibilité de l’authentification, puis l’état du service. Ne tentez pas des mots de passe au hasard.

Vérification initiale : la session SSH s’ouvre, VNC vous authentifie et les raccourcis clavier conviennent à votre usage quotidien.

Se connecter depuis Linux

  1. Utilisez le client OpenSSH fourni par votre distribution. Vérifiez les permissions de votre clé locale et assurez-vous que les autres utilisateurs n’y ont pas accès.
  2. Connectez-vous en SSH avec les informations fournies. Pour transférer un projet ou des fichiers compilés, vous pouvez utiliser SFTP via le même point d’accès SSH.
  3. Choisissez un client VNC compatible avec l’authentification du serveur. Privilégiez un port local transféré par SSH plutôt que l’exposition directe du service de bureau.
  4. Après votre première connexion au bureau, vérifiez le presse-papiers et la méthode de saisie. Transférez les fichiers en lot avec SFTP ; n’utilisez pas le presse-papiers du bureau comme outil de synchronisation de projet.

Vérification initiale : l’authentification par clé fonctionne, SFTP accède au répertoire cible et la saisie ainsi que l’affichage du bureau sont corrects.

Commandes SSH et tunnel vers le bureau

Dans un terminal local, définissez d’abord les variables :SSH_USER correspond au nom d’utilisateur système,SSH_HOST à l’adresse de l’instance etSSH_PORT au port SSH indiqué dans la console. Ne mettez pas de mot de passe dans une commande ni dans un script.

ssh -p "$SSH_PORT" "$SSH_USER@$SSH_HOST"

ssh -N -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:15900:127.0.0.1:5900 \
  -p "$SSH_PORT" "$SSH_USER@$SSH_HOST"

La deuxième commande ne fonctionne que si le service de partage d’écran distant écoute sur le port TCP 5900 local et autorise le transfert SSH. Laissez ce terminal ouvert, puis connectez votre client VNC à 127.0.0.1:15900. Il s’agit d’un port local, pas d’un port public de l’instance. S’il est déjà utilisé, choisissez un autre port local disponible.

Pour une utilisation fluide

Réduisez la charge d’affichage : c’est plus efficace que d’augmenter la bande passante à l’aveugle

Le bureau à distance dépend de la latence aller-retour, des pertes de paquets, des changements à l’écran et des capacités d’encodage du client. Ces réglages constituent un point de départ, pas une mesure du débit de l’instance ni une garantie de bande passante. Fiez-vous aux résultats mesurés sur votre réseau local.

Commencez par une résolution modeste pour établir une connexion stable, puis augmentez progressivement la qualité
Réseau et tâcheRésolution de départQualité et profondeur des couleursRéglages à essayer
Réseau mobile ou connexion internationale instable1280 × 720Privilégiez la compression adaptative ; essayez 16 bits si votre client le permetDésactivez les effets dynamiques du bureau et mettez en pause la synchronisation des gros fichiers. Vérifiez d’abord la réactivité de la saisie.
Connexion fixe stable, code et documents1920 × 1080Commencez en qualité automatique ; augmentez-la si le texte manque de nettetéNe modifiez qu’un seul réglage à la fois et comparez le défilement, le déplacement des fenêtres et la saisie au clavier.
Vérification de l’interface et retouche d’imagesÀ partir de 1920 × 1080Pour les détails colorimétriques, choisissez 24 bits ou plus, selon les capacités du clientVérifiez le facteur d’échelle et les artefacts de compression. La qualité finale se juge sur le fichier exporté.

Le bureau sert à travailler, pas à évaluer la vidéo ou l’audio en temps réel

L’aperçu vidéo, les animations rapides et les interactions à fréquence d’images élevée multiplient les changements à l’écran. Vous pouvez transcoder des fichiers audio et vidéo à distance, mais téléchargez le rendu final pour le vérifier localement. Ne confondez pas les saccades du bureau à distance avec un problème du fichier exporté.

Ordre conseillé : réduire la résolution → activer la qualité adaptative → vérifier les pertes de paquets → ajuster la profondeur des couleurs.

Ne laissez pas le bureau ouvert pour les builds et les transferts

Pour les builds de longue durée, utilisez un runner ou une tâche en arrière-plan gérable et enregistrez les journaux dans un fichier. Transférez les projets et les fichiers compilés avec SFTP. Après la fermeture du bureau, la tâche ne continue que si son mode de lancement le permet : ne supposez pas que toutes les commandes du terminal resteront actives.

Si vous devez travailler en continu à distance, testez d’abord une session complète avant de choisir une durée de location longue.

Limites du débogage sur appareil réel

Ouvrir le simulateur ne signifie pas que votre téléphone est détectable

Le fait que le Mac cloud soit dédié et l’accessibilité réseau des appareils mobiles sont deux choses distinctes. Xcode, le simulateur et les builds peuvent fonctionner à distance ; pour connecter un iPhone ou un iPad local, il faut aussi que l’appairage, l’approbation de confiance et la découverte réseau soient possibles.

Option 1 : commencer par tester dans le simulateur distant

Ouvrez le projet sur le Mac cloud, vérifiez la compatibilité de Xcode, du SDK et de la configuration du projet, puis lancez le simulateur pour tester l’interface, la logique et les principaux scénarios de régression. Cette étape permet d’éliminer les problèmes de compilation et d’environnement d’exécution.

Le simulateur ne remplace pas les tests sur appareil réel de l’appareil photo, des capteurs, du réseau mobile, des performances et de la gestion thermique. Si vous avez besoin de ces tests, prévoyez une validation sur un appareil réel.

Résultats livrables : journal de build reproductible, journaux de test et résultats d’exécution du simulateur.

Option 2 : vérifier les conditions de débogage réseau de l’appareil

Le débogage réseau exige généralement un appairage valide entre l’appareil et le Mac cible, ainsi que des versions compatibles de Xcode et du système. L’appareil et le Mac doivent aussi pouvoir se détecter ou communiquer via un chemin réseau vérifié.

Un tunnel SSH ne résout pas automatiquement les problèmes de découverte de l’appareil, de premier appairage ou d’approbation de confiance. Une adresse publique accessible ne suffit pas à permettre le débogage sans fil sur un appareil réel.

À confirmer avant de commander : mode d’appairage, topologie réseau, version du système de l’appareil et autorisations nécessaires.

La connexion d’appareils à distance doit faire l’objet d’une vérification spécifique.Le transfert USB et les autres solutions d’accès à distance dépendent de la compatibilité des protocoles, des pilotes, de la reconnexion des appareils et de la qualité du réseau. Ils ne font pas partie des fonctionnalités fournies par défaut et aucun appareil mobile n’est inclus. Si un appareil local doit absolument se connecter à Xcode dans le cloud, communiquez à l’équipe son modèle, la version de son système, le mode d’appairage envisagé et l’objectif des tests. Une fois la faisabilité confirmée, les travaux pourront être planifiés. Pour vérifier uniquement le paquet d’installation, transmettez le build signé à une personne chargée des tests afin qu’elle le teste sur un appareil local ; une session de débogage à distance permanente n’est pas nécessaire.

Vérifier la faisabilité des tests sur appareil réel
Après la connexion

Sécurisez d’abord l’accès, puis transférez vos projets et vos clés

Un Mac physique dédié évite de partager les ressources de calcul avec d’autres clients, mais ne remplace pas la sécurité des comptes. Effectuez ces trois étapes avant de déployer certificats de signature, code métier et identifiants d’automatisation.

  1. Activer la connexion par clé publique

    Générez une clé sur un appareil local de confiance et ajoutez la clé publique au fichier d’autorisations de l’utilisateur distant concerné. Gardez la clé privée en local ; ne la téléversez ni sur la machine ni dans un ticket. Ouvrez un nouveau terminal pour vérifier que la connexion par clé fonctionne. Gardez l’ancienne session ouverte comme accès de secours avant de modifier les paramètres d’authentification par mot de passe.

  2. Changer le mot de passe fourni

    Changez le mot de passe système après la première connexion et enregistrez-le dans un gestionnaire de mots de passe de confiance. Ne le stockez pas dans la configuration d’un runner, l’historique des commandes ni le dépôt du projet. Pour le travail en équipe, attribuez des identifiants d’accès individuels et traçables plutôt que de partager durablement un même compte.

  3. N’ouvrir que les ports nécessaires

    Ne conservez que les accès SSH et bureau dont vous avez réellement besoin ; privilégiez un tunnel dès que possible. Avant de modifier le pare-feu ou les règles d’accès, vérifiez votre accès d’administration actuel et prévoyez une méthode de retour arrière. Pour résoudre un problème de connexion, ne désactivez pas toutes les protections d’un coup.

En cas de problème, quelles informations fournir dans un ticket ?

Indiquez l’identifiant de l’instance, le système et la version du client, le mode de connexion, la date et l’heure avec le fuseau horaire, le message d’erreur exact et le problème rencontré : délai d’attente, connexion refusée ou échec d’authentification. Vous pouvez joindre une capture d’écran expurgée, mais jamais de mot de passe, de clé privée ni d’identifiants complets.

Ouvrir la console et créer un ticket
Vérifications avant connexion

Préparez ces quatre éléments avant votre première connexion

Vérifiez chaque élément dans l’ordre. S’il en manque un, complétez-le avant de poursuivre plutôt que de multiplier les tentatives. Si le réseau de votre entreprise bloque une connexion sortante nécessaire, demandez d’abord une modification de la politique d’accès.

  • Identifiants enregistrés
    L’adresse de l’instance, le nom d’utilisateur système, les informations d’authentification et les ports réels ont été vérifiés dans la console et enregistrés en lieu sûr.
  • Client installé
    SSH fonctionne en ligne de commande ; pour l’interface graphique, un client compatible avec le partage d’écran ou VNC est prêt.
  • Clé publique ajoutée et vérifiée
    Si vous utilisez l’authentification par clé publique, la clé a été ajoutée au bon utilisateur et testée lors d’une nouvelle session. La clé privée reste exclusivement en local.
  • Trafic sortant autorisé sur le réseau local
    Le port SSH réel a été vérifié. Pour une connexion directe au bureau, vérifiez aussi le port VNC ; avec un tunnel, vérifiez le port d’écoute local.

Après la vérification initiale, notez la version du client, le mode de connexion et les réglages qui fonctionnent. Les autres membres de l’équipe pourront reprendre ces étapes, mais ne copiez pas vos clés privées ni vos mots de passe personnels.

Une fois la connexion vérifiée, transférez votre travail.

Testez d’abord le bureau, la ligne de commande et vos tâches réelles. Pour louer une machine, choisissez une configuration adaptée à votre charge de travail ; si vous avez déjà une instance, vérifiez vos identifiants dans la console.

Louer un Mac cloud Accéder à la console