Louez un Mac cloud sur une machine physique dédiée et raccordez-y vos dépôts, outils et pipelines existants. Ce guide suit l’ordre des opérations. Si vous disposez déjà d’un dépôt et de scripts de build, prévoyez environ 30 à 60 minutes pour migrer l’environnement, hors transfert de données et téléchargement de Xcode.
Vous avez déjà une instance ? Connectez-vous à la console pour consulter les informations de connexion. Les commandes et sorties ci-dessous sont des exemples. Les adresses et identifiants réels sont ceux indiqués dans la console.
Au moment de commander, définissez trois éléments : le modèle détermine les ressources disponibles pour la compilation et les tâches parallèles, la région influe sur la latence des connexions à distance et la durée de facturation fixe la période d’utilisation. Les trois modèles sont des machines physiques dédiées, et non des machines virtuelles. Leur disponibilité en temps réel est indiquée dans la console.
ZSH 16 convient pour valider un premier pipeline de build. Pour la compilation parallèle ou un runner actif en continu, envisagez ZSH 24. Pour les expérimentations MLX nécessitant davantage de mémoire unifiée, découvrez ZSH Pro 64. Choisissez ensuite la région en fonction de l’emplacement principal de votre équipe.
À vérifier : modèle, capacité SSD, région et durée de facturation (jour, semaine, mois ou trimestre).
Payez en USDT-TRC20 ou par Visa, Mastercard ou Amex via Stripe. Avant un transfert USDT, vérifiez qu’il s’agit bien du réseau TRC20. Pour les cartes, suivez les étapes de la passerelle indiquée sur la page de paiement.
À vérifier : le résultat du paiement et le statut de la commande dans la console. Les moyens de paiement disponibles dépendent de la réponse du système.
Une fois l’instance livrée, notez dans la console son adresse de connexion, le nom d’utilisateur, les identifiants de première connexion et l’empreinte de l’hôte. Ne stockez pas ces informations dans un dépôt, des journaux de build ou des documents d’équipe accessibles à tous.
À vérifier : la connexion SSH fonctionne et l’interface graphique de macOS s’ouvre.
Commencez par réussir un build autonome d’un dépôt sur la nouvelle machine, puis connectez les tâches automatisées. En cas d’erreur, vous pourrez ainsi déterminer si elle vient de données manquantes, d’une version d’outil différente ou de la configuration du runner.
Transférez le dépôt avec rsync ou clonez-le à nouveau depuis un dépôt distant contrôlé. Transférez séparément les certificats, profils de provisionnement et exportations du trousseau, en les chiffrant. Ne placez pas de clé privée dans un répertoire de synchronisation classique.
Durée indicative de vérification manuelle : 10 à 20 minutes, hors transfert des données.
Installez les dépendances en ligne de commande avec Homebrew et gérez les versions de Xcode requises par le projet avec xcodes. Vérifiez d’abord la cible de xcode-select avant de synchroniser les dépendances nécessaires à fastlane, CocoaPods et SPM.
xcodebuild -version ainsi que la version requise par le projet.Durée indicative de vérification manuelle : 10 à 20 minutes, hors téléchargement des logiciels.
Intégrez la machine à votre workflow GitHub Actions ou GitLab Runner existant. Suivez les étapes d’enregistrement fournies par le dépôt ou l’organisation afin que les builds s’exécutent sous un compte système dédié.
Durée indicative de vérification manuelle : 10 à 20 minutes, hors première tâche.
Ces durées servent uniquement à planifier les vérifications manuelles ; elles ne garantissent pas les délais de mise à disposition ou de téléchargement. Si le build dépend de nombreux caches, migrez d’abord une configuration reproductible, puis décidez si les fichiers de cache doivent aussi être transférés.
Les exemples ci-dessous sont des sorties de terminal fictives, pas l’adresse, l’empreinte ou le résultat de build réels de votre instance. Remplacez les adresses et le scheme d’exemple par les valeurs de la console et du projet. Lors de la première connexion SSH, comparez impérativement à l’identique l’empreinte de l’hôte affichée dans la console.
Connexion et vérification de l’empreinte
zsh % ssh -o StrictHostKeyChecking=ask mac@203.0.113.10
The authenticity of host '203.0.113.10' can't be established.
Host key verification required before continuing.Vérifier le build
zsh % xcodebuild -version
Xcode 16.2
zsh % xcodebuild -scheme App -configuration Release build
** BUILD SUCCEEDED **Vérifier le processus de distribution
zsh % fastlane beta
Running lane 'beta'
Archive complete
Upload to TestFlight completeSSH convient pour installer des dépendances, récupérer du code et lancer des builds. Pour les réglages Xcode, le simulateur et les outils graphiques, utilisez le partage d’écran de macOS. Consultez dans la console l’adresse et les identifiants de partage d’écran de l’instance, puis connectez-vous depuis l’application de partage d’écran de votre ordinateur.
Lors de votre première session, vérifiez que la résolution et le facteur d’échelle conviennent à votre réseau. Si l’affichage à distance manque de réactivité, réduisez d’abord la résolution et désactivez les animations graphiques superflues, puis comparez la connexion depuis différents réseaux. Utilisez la synchronisation du presse-papiers uniquement pour du texte non sensible. Pour transférer un certificat ou une clé privée, choisissez une méthode chiffrée et contrôlée.
Une connexion réussie ne suffit pas à terminer la passation. Effectuez les quatre vérifications ci-dessous avant d’intégrer l’instance à la CI permanente. L’équipe qui utilise réellement cette machine doit confirmer chaque point ; une simple capture d’écran d’une connexion réussie ne suffit pas.
softwareupdate -l pour rechercher les mises à jour. Avant d’installer une mise à niveau susceptible d’affecter l’environnement de build, sauvegardez vos données et vérifiez la compatibilité de Xcode avec le projet.
Consultez la page des commandes de la console pour connaître les dates de début et de fin de la période en cours, les factures et l’option de renouvellement. Fiez-vous aux rappels affichés dans la console et aux notifications de service reçues ; ne vous basez pas uniquement sur votre calendrier local. Pour continuer à utiliser l’instance, vérifiez le modèle, la région, la durée et le montant dans la console avant de renouveler.
Avant de terminer votre utilisation, sauvegardez les modifications non poussées du dépôt, les éléments de signature, les artefacts de build et les journaux d’audit nécessaires. Vérifiez depuis un autre appareil que la sauvegarde est accessible, puis demandez la libération dans la console. Après la libération, le disque est effacé et le système réinstallé : ne considérez pas cette opération comme une méthode de sauvegarde.
Pour approfondir SSH, VNC et la configuration quotidienne de votre environnement de développement, consultez les articles sur la mise en place d’un environnement Mac distant. Pour les paramètres de build, les caches et la configuration du runner, poursuivez avec le guide de compilation Xcode dans le cloud. En cas de problème avec l’instance ou la facturation, contactez l’assistance technique.
Découvrez comment gérer les clés SSH, configurer Homebrew, activer le partage d’écran et connecter un éditeur à distance.
Approfondissez les versions de Xcode, les caches de build, les commandes de test et la connexion d’un runner self-hosted.
En cas d’échec de connexion, de problème d’environnement de build ou de question sur un renouvellement, commencez par les étapes de dépannage, puis ouvrez un ticket depuis la console.
Choisissez un modèle, une région et une durée. Une fois l’instance livrée, suivez cette checklist pour vous connecter, migrer votre environnement et tout vérifier.