Mac dans le cloud ou achat : configurations M4, durées et conseils

Options d'équipement

Le prix de la machine ne fait pas tout

Comparez l'achat du matériel, le temps de mise en place et la responsabilité liée aux périodes d'inactivité. Les capacités d'une machine virtuelle dépendent du service choisi : son nom ne suffit pas à les déterminer.

Coûts et responsabilités pour trois modes d'utilisation
Critère	Mac acheté	Machine virtuelle	Serveur dédié XcNode
Coût initial	Achat du matériel en une fois ; prévoyez aussi son emplacement, l'alimentation, le réseau et l'accès à distance.	Facturation selon la configuration et la durée du fournisseur ; vérifiez les quotas et les éventuels frais supplémentaires.	Prépaiement à la journée, à la semaine, au mois ou au trimestre, sans achat préalable de matériel.
Mise à disposition	Après réception, installez vous-même les outils, configurez le réseau et vérifiez le processus de build.	Créez une instance selon la procédure du fournisseur ; vérifiez séparément l'image système et les versions des outils.	Consultez le paiement et l'état de livraison dans le portail ; connectez-vous avec vos identifiants et vérifiez votre projet.
Licence macOS	Fonctionne sur du matériel Apple ; l'utilisation des logiciels reste soumise aux licences applicables.	Vérifiez le matériel hôte, la méthode de virtualisation et les conditions du service : le nom du système ne suffit pas.	macOS s'exécute en natif sur un serveur physique Apple Silicon, sans livraison sous forme de machine virtuelle.
Stabilité des performances	Vous gérez les ressources ; interactions locales, tests et builds peuvent se concurrencer.	Vérifiez le partage de l'hôte, les quotas CPU, la prise en charge GPU et les limites de stockage.	Chaque machine est attribuée à un seul locataire ; vos propres tâches parallèles peuvent néanmoins se disputer ses ressources.
Travail en équipe	Gérez vous-même l'accès réseau, les droits des membres, les clés et l'ordre d'utilisation de l'interface graphique.	Tout dépend des droits sur l'instance, des méthodes d'accès et des limites de collaboration du fournisseur.	Organisez le développement à distance ou la CI ; l'équipe gère les accès, la file de builds et les sessions de bureau.
Coût d'inactivité	Vous conservez la machine après le projet et assumez sa dépréciation, son stockage et son entretien.	La désactivation suit les règles du fournisseur ; vérifiez si les disques, instantanés et autres éléments restent facturés.	Choisissez une durée adaptée au projet ; un cycle commencé n'est pas automatiquement suspendu lorsque les builds s'arrêtent.

Configurations

Deux modèles, caractéristiques détaillées

Commencez par la mémoire unifiée et les besoins de votre projet, puis comparez les tarifs. Les prix ci-dessous concernent les configurations de base, hors extension de stockage et options de mise en parallèle Thunderbolt 5.

Deux modèles disponibles ; tous les prix sont en dollars américains
Configuration / durée	Node Core M4	Node Pro M4
Puce	M4	M4 Pro
Mémoire unifiée	16GB	64GB
SSD	256GB	2TB
À la journée	$21.3/jour	$59.1/jour
À la semaine	$57.6/semaine	$159.6/semaine
Au mois	$106.7/mois	$295.6/mois
Au trimestre	$290.2/trimestre	$804/trimestre
Emplacements disponibles	Singapour / Tokyo / Séoul / Hong Kong	Singapour / Tokyo / Séoul / Hong Kong
Pour commencer	Builds Xcode individuels, automatisation séquentielle des releases et distribution TestFlight.	Tests simultanés sur simulateur, grands projets Swift et expérimentations de modèles locaux gourmands en mémoire.
Choisir une configuration	Louer Node Core M4	Louer Node Pro M4

Les deux configurations sont proposées dans quatre emplacements. La disponibilité réelle est celle indiquée en temps réel dans le portail. Le choix du modèle ne garantit pas les performances : la taille des dépendances, les options de compilation, l'efficacité du cache et le nombre de tests simultanés influent sur les ressources utilisées.

Durée de location

À la journée ou à la semaine pour un sprint ; au mois ou au trimestre pour la CI

Chaque tarif du tableau correspond à un cycle distinct, et non à une estimation calculée en additionnant le prix journalier. Plus la durée est longue, plus il est important de vérifier que le projet utilisera la machine en continu.

Comparatif des quatre durées pour chaque modèle
Modèle	Jour	Semaine	Mois	Trimestre
Node Core M4	$21.3	$57.6	$106.7	$290.2
Node Pro M4	$59.1	$159.6	$295.6	$804

Rush de livraison : délimitez d'abord vos besoins

Pour reproduire un build, préparer une release ou valider une chaîne d'outils, commencez à la journée. Si le travail s'étend sur une semaine complète, comparez le tarif hebdomadaire. Comptez aussi le téléchargement des dépendances, la configuration des certificats et la sauvegarde des artefacts : ne vous limitez pas aux quelques minutes de compilation.

Tâches continues : vérifiez la durée d'exécution

Pour exécuter la CI chaque jour, conserver un cache de build fiable ou maintenir un environnement de développement pour l'équipe, comparez les tarifs mensuel et trimestriel. Validez d'abord avec un projet réel avant de vous engager sur une durée plus longue. Une machine toujours disponible ne signifie pas que vos runners et scripts de build sont configurés pour démarrer automatiquement.

Facturation en dollars américains. Paiement par USDT-TRC20 ou Visa / Mastercard / Amex (via Stripe) uniquement. Les moyens de paiement disponibles dépendent de la réponse de la passerelle côté serveur. Consultez la page des offres pour le prix des options et le détail de la facture.

Voir durées et options

Ressources dédiées

Une machine dédiée, sans partage de l'hôte

GPU natif, mémoire unifiée et environnement macOS complet vont de pair. L'ordonnancement des tâches, la compatibilité du projet et la qualité du réseau restent à vérifier selon vos besoins.

Toutes les ressources pour un seul locataire

XcNode ne divise pas une machine en instances virtuelles pour plusieurs locataires. Le CPU, le GPU et la mémoire unifiée ne sont pas partagés avec d'autres locataires et ne reposent pas sur une émulation de GPU. Xcode, les simulateurs et Metal fonctionnent dans un environnement macOS natif.

Une machine dédiée n'offre pas un parallélisme illimité. Les processus de compilation, les simulateurs, l'indexation et l'inférence de modèles utilisent toujours la mémoire de votre machine. Surveillez la pression mémoire avant d'augmenter le parallélisme ; évitez de lancer tous vos runners à pleine charge d'emblée.

Un locataire, un serveur dédié

Validez l'environnement avec vos charges réelles

Pour savoir si une machine virtuelle convient à votre projet, vérifiez la prise en charge du GPU, les droits système, le partage de l'hôte et la compatibilité des outils. Il serait inexact d'affirmer que toutes les machines virtuelles sont lentes, tout comme de considérer qu'un macOS qui démarre constitue à lui seul un environnement de développement complet.

Un serveur physique nécessite lui aussi de vérifier la version de Xcode, l'architecture des dépendances, la configuration de signature et les runtimes de simulateur. Le bureau à distance dépend également de la latence aller-retour ; pour les builds en ligne de commande, privilégiez SSH et une file d'automatisation.

Validez avant d'augmenter le parallélisme

Préparer la migration

Données → outils → CI

Organisez la migration en trois étapes vérifiables. Les durées ci-dessous sont des estimations de préparation manuelle, pas des engagements de livraison. Le transfert d'un grand dépôt, le téléchargement des dépendances et une suite complète de tests peuvent prendre plus longtemps.

01 · Données

Synchronisez le projet et les fichiers utiles

Prévoir : 15–60 min

Récupérez le code avec Git, les fichiers volumineux avec Git LFS ou synchronisez le répertoire de travail avec rsync. Évitez de transférer tous les caches. Vérifiez le dépôt, les sous-modules et les ressources nécessaires au build avant d'envoyer les certificats de signature via une connexion sécurisée.

rsync -av --exclude DerivedData \
  ~/project/ cloud-mac:~/project/

À vérifier : version du code identique, ressources accessibles et aucun fichier sensible dans un dépôt public.

02 · Outils

Alignez les versions, sans approximation

Prévoir : 20–90 min

Vérifiez le chemin et la version de Xcode, puis consignez la configuration de Homebrew, des dépendances Ruby et de Fastlane. Lancez d'abord un build avec un script local avant de passer à une plateforme d'automatisation : vous distinguerez ainsi plus facilement un problème de chaîne d'outils d'un problème de runner.

xcode-select -p
xcodebuild -version
bundle exec fastlane --version

À vérifier : versions identifiées, commande de build reproductible et artefact conforme aux attentes.

03 · CI

Enregistrez le runner, puis activez le démarrage automatique

Prévoir : 15–45 min

Récupérez les instructions d'enregistrement depuis GitHub Actions ou GitLab CI et associez le runner au projet de l'équipe. Commencez par une faible concurrence pour valider le build, les tests et l'envoi des artefacts. Configurez ensuite le démarrage automatique, après avoir vérifié que le compte de service peut accéder au projet, au trousseau et au répertoire de cache.

cd ~/actions-runner
./svc.sh install
./svc.sh start

À vérifier : le runner récupère les tâches, les logs sont consultables et le service fonctionne comme prévu après redémarrage.

Dans les commandes, cloud-mac est l'alias du serveur défini dans votre configuration SSH. L'exemple de runner suppose que le téléchargement et l'enregistrement ont déjà été effectués. Une fois la migration terminée, conservez une sauvegarde locale et vérifiez les artefacts archivés et les résultats des tests avant de nettoyer l'ancien environnement.

Guide SSH et CI

Trois questions pour décider

Choisissez d'abord le modèle, puis la durée

Les besoins en mémoire déterminent la configuration ; la durée d'utilisation détermine le cycle. Une CI en continu n'impose pas à elle seule le modèle Pro.

Besoin de tests parallèles gourmands en mémoire ?

Si plusieurs simulateurs, de grands projets Swift ou des modèles locaux fonctionnent en même temps et que vous constatez une forte pression mémoire, comparez en priorité les 64GB de mémoire unifiée du Node Pro M4. Pour les builds séquentiels et les releases en solo, commencez par tester le Node Core M4.

Choisir Node Pro M4

La machine fera-t-elle tourner la CI en continu ?

Commencez par compter les tâches exécutées simultanément, plutôt que de vous fier au seul mot « CI ». Pour un pipeline séquentiel, testez d'abord le Core ; pour des tests en parallèle, évaluez le Pro. Si la machine doit récupérer des tâches chaque jour et conserver le cache, comparez les tarifs mensuel et trimestriel, puis configurez le démarrage du service et la sauvegarde des artefacts.

Choisir Node Core M4

La durée d'utilisation est-elle connue ?

Pour diagnostiquer un problème, valider un build ou préparer une release, comparez les tarifs à la journée et à la semaine. Une fois l'environnement validé et le projet lancé dans la durée, examinez les tarifs mensuel et trimestriel. Avant la fin, exportez les artefacts, sauvegardez le projet et vérifiez le renouvellement ou la date d'expiration ; ne conservez pas vos seules données sur le serveur.

Choisir selon le projet

Choisissez séparément l'emplacement et le modèle. Les deux configurations sont disponibles à Singapour, Tokyo, Séoul et Hong Kong. Testez la connexion depuis le réseau habituel de votre équipe et privilégiez l'emplacement adapté à ses principaux utilisateurs. La distance géographique ne suffit pas à garantir une faible latence.

Louez pour votre projet, sans acheter de machine

Commencez par un build réel. Choisissez votre modèle, votre emplacement et votre durée, vérifiez la configuration et le montant final dans le portail, puis passez commande.

Louer à la demande Voir tous les tarifs