Guide des régions en Asie-Pacifique

4 régions, un tarif unique

Des Mac mini dédiés, sans virtualisation. Choisissez une région selon l’emplacement de votre équipe et le parcours de vos builds, puis vérifiez la connexion sur votre réseau. La région ne change pas le prix d’une même configuration.

Louer un Mac cloud Voir tous les tarifs

Singapour · Japon (Tokyo) · Corée du Sud (Séoul) · Hong Kong Deux configurations M4 Jour / semaine / mois / trimestre

Tous les tarifs sont en USD. Les machines sont disponibles toute l’année, 365 jours par an. La disponibilité au moment de la commande est indiquée en temps réel dans la console.

Configurations disponibles

Même configuration, région au plus près de vos usages

Les quatre régions proposent GNU Core M4 et GNU Studio M4. Chaque commande porte sur une machine physique dédiée : le processeur, la mémoire et le stockage ne sont pas partagés avec d’autres clients.

SG Collaboration en Asie du Sud-Est

Singapour

Idéal pour les équipes de développement en Asie du Sud-Est. Regroupez runner CI autohébergé, cache de dépendances et builds quotidiens dans une même région pour limiter les transferts entre régions.

GNU Core M4M4 · 16GB RAM · 256GB SSD
Disponible
GNU Studio M4M4 · 24GB RAM · 512GB SSD
Disponible

Options disponibles+1TB SSD, +2TB SSD et connexion Thunderbolt 5 (par machine). Pour relier plusieurs machines, vérifiez d’abord le mode de connexion.

Avant de choisir, testez la réactivité depuis le réseau de votre équipe et les transferts entre le dépôt, le stockage des builds et la machine.

Louer à Singapour

JP Flux de travail pour le marché japonais

Japon (Tokyo)

Idéal pour les équipes au Japon, la localisation en japonais et les builds destinés au marché japonais. Compilez avec Xcode, effectuez les tests de régression sur simulateur et archivez les builds sur la même machine.

GNU Core M4M4 · 16GB RAM · 256GB SSD
Disponible
GNU Studio M4M4 · 24GB RAM · 512GB SSD
Disponible

Options disponibles+1TB SSD, +2TB SSD et connexion Thunderbolt 5 (par machine). Le SSD supplémentaire peut accueillir le cache de build ou les ressources du projet.

La région de la machine ne change pas les règles de validation de l’App Store et ne remplace pas les tests sur le réseau local, des appareils physiques et dans des conditions réelles.

Louer à Tokyo

KR Marché coréen et sortie de jeux

Corée du Sud (Séoul)

Pour les équipes qui travaillent sur la sortie de jeux en Corée du Sud, la compilation de clients et les tests de régression de localisation. Compilez vos projets Unity ou Flutter sur macOS dans cette région, puis transmettez-les au processus de publication de votre équipe.

GNU Core M4M4 · 16GB RAM · 256GB SSD
Disponible
GNU Studio M4M4 · 24GB RAM · 512GB SSD
Disponible

Options disponibles+1TB SSD, +2TB SSD et connexion Thunderbolt 5 (par machine). Pour les projets volumineux, vérifiez l’espace total nécessaire aux ressources, au cache et aux builds.

Pour le débogage interactif, testez d’abord depuis votre réseau de travail. La distance sur une carte ne suffit pas pour choisir une région.

Louer à Séoul

HK Collaboration entre la Chine continentale, Hong Kong et Taïwan

Hong Kong

Idéal pour le développement à distance et la collaboration audiovisuelle entre équipes réparties en Chine continentale, à Hong Kong et à Taïwan. Effectuez les transcodages par lots dans le cloud, puis récupérez les fichiers via SFTP, sans maintenir une connexion graphique pendant toute l’opération.

GNU Core M4M4 · 16GB RAM · 256GB SSD
Disponible
GNU Studio M4M4 · 24GB RAM · 512GB SSD
Disponible

Options disponibles+1TB SSD, +2TB SSD et connexion Thunderbolt 5 (par machine). Si vous gérez beaucoup de ressources, séparez les données du projet du disque système.

Les performances peuvent varier selon l’opérateur. Testez séparément votre connexion fixe au bureau, votre réseau domestique et votre réseau mobile.

Louer à Hong Kong

« Disponible » signifie que la configuration est généralement réservable dans le catalogue. La livraison et les options disponibles sont indiquées en temps réel dans la console ; cette page ne présente ni latence estimée ni données historiques de surveillance.

Commencez par identifier les utilisateurs principaux

Conseils de région : testez toujours votre connexion

Une équipe n’a pas besoin de regrouper toutes ses tâches dans une seule région. Pour les opérations manuelles, testez la réactivité ; pour les builds automatisés, vérifiez les transferts entre dépôt et stockage des builds ; pour l’adaptation au marché, contrôlez séparément les conditions de test.

Choisir une région selon votre flux de travail principal
Besoin principal	Région conseillée	Pourquoi ce choix	À vérifier avant de commander
Pour les utilisateurs en Asie du Sud-Est	Singapour	À tester en priorité si les développeurs, les services de code ou les destinataires des builds se trouvent principalement en Asie du Sud-Est.	Testez la connexion depuis le réseau habituel de l’équipe et vérifiez les chemins de téléchargement des dépendances et d’envoi des builds.
Préparation à la validation de l’App Store japonais et tests de localisation	Japon (Tokyo)	Facilite la collaboration des équipes au Japon et la centralisation des environnements de build. La région ne garantit pas l’issue de la validation.	Vérifiez les besoins liés à la langue, au fuseau horaire, aux simulateurs et aux appareils physiques. Distinguez l’environnement de build de l’environnement réseau du marché visé.
Marché coréen et sortie de jeux	Corée du Sud (Séoul)	Adapté à la compilation de projets, au traitement des ressources et aux tests de régression de localisation avec la participation d’équipes coréennes.	Testez la synchronisation de projets volumineux et les conditions réseau nécessaires pour que le client accède aux services utilisés en production.
Collaboration entre la Chine continentale, Hong Kong et Taïwan	Hong Kong	Une région à envisager pour les builds et le transcodage utilisés en commun par des équipes réparties sur plusieurs sites.	Faites tester la connexion par les utilisateurs de chaque site ; le résultat d’une seule personne ne représente pas toute l’équipe.

Test de connexion

Testez votre réseau habituel avant de choisir une région pour le long terme

Le partage d’écran à distance transmet en continu l’image et les commandes ; il est donc sensible à la latence aller-retour, à la gigue et à la perte de paquets. Les builds lancés via SSH ne nécessitent généralement pas d’affichage continu, mais le téléchargement des dépendances et l’envoi des builds dépendent toujours de la bande passante disponible.

Partage d’écran : vérifiez la réactivité

Depuis le réseau que vous utiliserez au quotidien, commencez par tester les régions candidates avec l’outil de mesure de la console. Après avoir reçu la machine, vérifiez les commandes, le déplacement des fenêtres et le défilement dans l’éditeur avec votre client habituel.

Une image nette qui se fige parfois peut signaler une connexion instable. Si les transferts sont constamment lents, vérifiez aussi les débits montant et descendant de votre réseau local ainsi que les synchronisations en arrière-plan. Réduire la résolution peut diminuer le volume de données vidéo, mais pas la latence aller-retour du réseau.

Builds automatisés : testez toute la chaîne

Ne testez pas uniquement la connexion entre votre poste et la machine. Une tâche CI comprend aussi la récupération du dépôt, le téléchargement des dépendances, l’accès au cache et l’envoi des builds ; l’emplacement de ces services influe sur le temps d’attente réel.

Effectuez un build sans cache, puis un build avec cache, et observez séparément le téléchargement, la compilation et l’envoi. Si la compilation est stable mais que l’envoi est lent, vérifiez d’abord le chemin des builds au lieu d’incriminer la mémoire de la machine.

01
Testez depuis votre réseau habituel
Mesurez la connexion dans la console depuis votre réseau de bureau ou domestique habituel. Ne vous fiez pas à un partage de connexion temporaire pour évaluer votre environnement de travail. Si plusieurs personnes utiliseront la machine, demandez à chacune de tester la connexion.
02
Testez à différentes heures
Répétez les tests pendant vos heures de travail et observez les variations de latence et la stabilité de la connexion. Un seul résultat décrit uniquement l’état du réseau au moment du test, pas toute la durée de location.
03
Notez les résultats avant de contacter l’assistance
En cas de problème, indiquez la région, l’heure du test et le fuseau horaire, le type de client utilisé et les symptômes observés. Pour une commande existante, ouvrez un ticket depuis la console. N’envoyez jamais de mot de passe ni de clé privée par e-mail.

Tester la connexion dans la console Consulter le guide de connexion à distance

Utilisation de plusieurs régions

Définissez clairement le rôle de chaque machine

Les machines situées dans des régions différentes sont indépendantes et ne partagent automatiquement ni disque, ni cache de build, ni fichiers de projet. Avant d’en déployer plusieurs, définissez une convention de nommage, la configuration des environnements et la méthode de transfert des données : vous éviterez de chercher après coup « sur quelle machine se trouve le build ».

01 / Nommage

Indiquez la région et la tâche dans le nom

Adoptez une convention de nommage commune au format « code région-projet-usage-numéro », par exemple jp-mobile-build-01. Dans votre propre registre d’instances, notez également l’identifiant de l’instance dans la console, son responsable et son usage, afin de ne pas identifier les machines uniquement par leur adresse IP.

Il s’agit d’une recommandation de gestion, pas d’un nom d’hôte prédéfini. Après un changement de région ou d’usage, mettez à jour les étiquettes des runners CI et la documentation interne.

02 / Environnement

Uniformisez les outils, séparez les identifiants

Consignez les versions de macOS, Xcode, des outils de dépendances et des scripts de build dans la documentation du projet. Validez la procédure sur une machine, puis appliquez-la aux autres régions pour éviter les écarts dus aux modifications manuelles.

Configurez les clés d’accès séparément sur chaque machine et accordez les autorisations aux dépôts et répertoires de builds selon les besoins. Ne stockez pas les certificats de signature, mots de passe ni clés privées dans le dépôt de code.

03 / Données

Transférez les builds et vérifiez chaque renouvellement

À la fin du build, transférez les fichiers générés, les journaux et les sauvegardes de configuration nécessaires vers un espace de stockage géré par votre équipe. Le SSD supplémentaire fait partie du stockage de la machine : ce n’est ni un disque partagé entre régions ni un service de sauvegarde.

Vérifiez dans la console la période de location et la date d’expiration de chaque commande. Un changement de région nécessite une migration vers une nouvelle instance. Avant de restituer une machine, exportez les données à conserver ; le disque système et le SSD supplémentaire seront ensuite effacés.

Choisissez une région, puis vérifiez la configuration et la durée de location.

Les quatre régions appliquent les mêmes tarifs. Pour les builds légers, privilégiez la configuration 16GB ; pour plusieurs simulateurs ou des tâches d’inférence, évaluez la configuration 24GB. Si vos projets nécessitent beaucoup de ressources et de cache, prévoyez un SSD supplémentaire.

Choisir une configuration par région Louer un Mac cloud