Questions techniques avant achat
Aucune promesse vague ici. Vérifiez directement la machine attribuée, les configurations M4, les nœuds disponibles, les quatre cycles de facturation, les conditions de connexion, la gestion des données et le périmètre du support avant de louer.
Type de produit
Commencez par vérifier si les ressources sont dédiées et à quels travaux de développement elles conviennent.
Non. XcodeVM fournit un Mac dans le cloud sur une machine physique dédiée. Les ressources de la machine sont réservées à la commande en cours : processeur, mémoire et stockage local ne sont pas partagés entre plusieurs locataires. Vous utilisez macOS via une interface graphique distante ou la ligne de commande, tandis que la machine reste dans le nœud physique sélectionné.
Cette formule convient aux tâches nécessitant une machine attitrée, un environnement de build stable ou la conservation durable d’un cache de projet. La puce, la mémoire, le stockage, le nœud et la durée sont ceux indiqués dans la confirmation de commande.
Les usages courants incluent le développement iOS et macOS, les builds Xcode, GitLab Runner, les builds React Native, les exports Unity iOS, les scripts automatisés, le développement à distance et les expériences MLX. L’interface graphique macOS et la ligne de commande sont disponibles : la machine convient donc au développement interactif comme aux pipelines d’intégration continue.
Lors du choix, privilégiez la mémoire maximale, le nombre de builds simultanés, la taille du cache de dépendances et la durée des tâches. Les codes, éléments de signature et données métier à conserver longtemps doivent faire l’objet d’une sauvegarde applicative distincte.
Les quatre nœuds sont conçus pour fonctionner normalement 365 jours par an. L’état du service est enregistré en continu et la disponibilité réelle dépend de l’instance associée à la commande. En cas d’accès impossible, notez d’abord l’heure, le nœud, l’opérateur et le message d’erreur, puis envoyez une demande via le processus d’assistance.
Configurations matérielles
Le catalogue commercial ne propose que deux configurations, sans modèle hors catalogue.
Convient au développement sur un seul projet, aux scripts, aux builds peu parallèles et aux caches de dépendances maîtrisés. Si les builds atteignent souvent la limite mémoire, évaluez directement la configuration supérieure.
Choisir XVM M4 CoreConvient à plusieurs projets en parallèle, aux arbres de dépendances volumineux, aux builds fortement parallèles et aux expériences MLX nécessitant davantage de mémoire. Pour l’inférence, vérifiez d’abord la taille du modèle et sa consommation réelle.
Choisir XVM M4 PlusMesurez d’abord, dans votre environnement local ou actuel, le pic mémoire, la taille du cache et le niveau de concurrence d’une tâche complète. Pour un projet unique et peu parallèle, commencez par évaluer XVM M4 Core. Pour plusieurs builds simultanés ou un pic proche de 16GB, évaluez XVM M4 Plus plutôt que de compter durablement sur la mémoire d’échange.
Les configurations actuellement disponibles sont uniquement M4 / 16GB / 256GB et M4 / 24GB / 512GB. Pour augmenter la capacité, vous pouvez sélectionner une extension SSD facturée séparément ; sa disponibilité est celle affichée en temps réel dans la console.
Choix du nœud
La distance géographique n’est qu’un indicateur. Le chemin réel dépend aussi de la sortie opérateur, du routage international et de la congestion aux heures de pointe.
Convient aux tests sur les liaisons d’Asie du Sud-Est et peut servir de candidat de connexion pour les équipes réparties sur plusieurs régions.
Convient aux workflows nécessitant un chemin réseau japonais ou un nœud de build situé à Tokyo.
Convient aux équipes de Corée et des régions voisines souhaitant tester les liaisons opérateur et la réactivité à distance.
Convient aux équipes de développement internationales qui évaluent le routage, la synchronisation du code et les liaisons de build continu.
Pas forcément. Singapour, le Japon (Tokyo), la Corée du Sud (Séoul) et Hong Kong peuvent utiliser des interconnexions opérateur et des sorties internationales différentes. Depuis votre réseau professionnel réel, effectuez plusieurs séries de ping et de traceroute en notant P50, P95, le taux de perte et l’heure des tests, plutôt que de retenir une seule valeur minimale.
Oui. XVM M4 Core et XVM M4 Plus sont disponibles à Singapour, au Japon (Tokyo), en Corée du Sud (Séoul) et à Hong Kong. La disponibilité réelle au moment de la commande est celle affichée en temps réel dans la console.
Consignez au minimum l’opérateur local, la ville de test, le nœud cible, l’heure, le nombre d’échantillons consécutifs, P50, P95, le taux de perte et le nombre de sauts. Si l’affichage distant saccade, ajoutez la résolution, la version du client, le mode de connexion et la reproductibilité du problème.
Tarifs et durée
L’hôte, le stockage supplémentaire et le mode Thunderbolt 5 en parallèle sont facturés séparément, selon la période choisie.
| Formule | Par jour | Par semaine | Par mois | Par trimestre |
|---|---|---|---|---|
| XVM M4 Core M4 / 16GB / 256GB |
$19.1 |
$51.7 |
$95.7 |
$260.3 |
| XVM M4 Plus M4 / 24GB / 512GB |
$39.5 |
$106.6 |
$197.4 |
$536.9 |
| Options | Par jour | Par semaine | Par mois | Par trimestre |
|---|---|---|---|---|
| +1TB SSD | $2.7 |
$7.3 |
$13.5 |
$36.7 |
| +2TB SSD | $5.4 |
$14.6 |
$27 |
$73.4 |
| Thunderbolt 5 en parallèle Facturé par machine |
$1.5 |
$4.1 |
$7.6 |
$20.7 |
Pour une validation courte, un export ponctuel ou une expérience unique, privilégiez le tarif journalier ou hebdomadaire. Pour un développement continu, un Runner fixe ou un projet long, comparez les tarifs mensuel et trimestriel. Ne comparez pas seulement le prix par jour : tenez compte de la durée prévue, du coût d’initialisation et du nombre de migrations.
Non. Ce sont des options séparées, facturées selon les mêmes périodes — jour, semaine, mois ou trimestre — que l’hôte. Avant de commander, vérifiez la configuration, la capacité ajoutée, le nombre de machines parallèles et le total.
Avant le paiement, le modèle, le nœud, la période, les options et le total renvoyés par la console font foi. Si la configuration ne correspond pas à vos attentes, interrompez le paiement et vérifiez à nouveau avant de continuer.
Paiement et règlement
Toutes les commandes sont réglées en dollars américains (USD). Les passerelles réellement disponibles sont celles renvoyées par l’interface backend.
Avant de payer, vérifiez le type de réseau, les informations du bénéficiaire, le montant et l’identifiant de commande. Après le transfert, conservez l’identifiant de transaction pour faciliter la vérification en cas d’anomalie.
Les paiements par carte sont traités par Stripe. La page de règlement affiche le montant et les passerelles disponibles ; XcodeVM ne vous demande pas d’envoyer des données de paiement complètes dans une demande d’assistance.
Toutes les formules, options et commandes sont affichées et réglées en dollars américains (USD). Vérifiez le montant final en dollars affiché avant le paiement.
Ne payez pas une seconde fois. Conservez d’abord l’identifiant de commande, l’heure, le montant et les informations de transaction masquées, puis connectez-vous à laconsole pour envoyer une demande. Pour un paiement USDT-TRC20, vous pouvez joindre l’identifiant de transaction ; pour une carte, joignez l’état affiché sur la page de commande, sans envoyer le numéro complet ni le code de sécurité.
Connexion à distance
Vérifiez d’abord les identifiants et le port, puis déterminez si le problème vient du client, de la session ou du chemin réseau.
Vérifiez que l’identifiant de commande, le nœud, l’adresse, le port et les identifiants initiaux appartiennent à la même instance.
Depuis votre réseau actuel, vérifiez le DNS, le port cible, la latence aller-retour et le chemin de routage.
Adaptez la résolution, la qualité des couleurs et la disposition du clavier aux capacités du client, puis enregistrez les paramètres.
Conservez l’heure, l’opérateur, le nœud, le message d’erreur et les journaux masqués pour faciliter le diagnostic.
Préparez une connexion stable vers le nœud cible, un client distant compatible et les informations fournies par la console. Vérifiez l’adresse et le port avant de saisir les identifiants. Après la connexion, remplacez les identifiants initiaux et stockez les informations dans un gestionnaire sécurisé.
Attendez d’abord que le client libère l’ancienne session, puis reconnectez-vous à la même instance. En cas d’échecs répétés, vérifiez successivement le réseau local, le port cible, la résolution DNS et les changements de routage. Ne masquez pas le problème en créant sans cesse de nouvelles sessions ; notez l’heure et le message d’erreur.
Réduisez d’abord la résolution et la qualité des couleurs, puis désactivez les animations inutiles. Testez ensuite en continu la latence, la gigue et les pertes sur le même réseau. Si le problème n’apparaît qu’à certaines heures, comparez les échantillons normaux et anormaux pour voir si le routage opérateur a changé.
Consultez leguide de diagnostic du support.
Évitez les identifiants partagés et non contrôlés. Attribuez les accès selon le principe du moindre privilège, consignez leur périmètre et leur durée, puis révoquez-les rapidement lors d’un changement de rôle. Les mots de passe, clés privées et éléments de signature ne doivent apparaître ni dans les dépôts, ni dans les journaux de build, ni dans les pièces jointes au support.
Gestion des données
Une machine dédiée ne constitue pas une sauvegarde automatique. Vous devez gérer votre propre cycle de vie des données.
Mettez en place des sauvegardes distinctes du code, des configurations de build, des artefacts et des données d’expérimentation, puis vérifiez régulièrement la restauration.
Limitez l’accès aux clés et éléments de signature. Évitez de les écrire dans les dépôts, journaux, paquets de cache et pièces jointes au support.
Copiez à l’avance les données nécessaires, vérifiez leur accessibilité depuis la destination, puis nettoyez le répertoire de travail local et les identifiants temporaires.
La sauvegarde applicative relève de l’utilisateur. Conservez le code source dans un dépôt contrôlé, versionnez les configurations et scripts essentiels, puis copiez les artefacts non reproductibles ou données d’expérience vers un stockage distinct. Validez la sauvegarde par un test de restauration, pas seulement en vérifiant que les fichiers ont été copiés.
Ne placez dans l’instance que les données nécessaires à la tâche. Un nœud de build ne doit synchroniser que les dépôts et dépendances utiles ; lors d’une demande d’assistance, fournissez uniquement des journaux masqués, sans base complète, clé privée, mot de passe ni données de paiement.
Vérifiez que le code est envoyé, que les artefacts sont transférés, que les sauvegardes sont restaurables et que les clés sont renouvelées ou révoquées. Nettoyez le cache et les fichiers temporaires. Ne planifiez pas la dernière migration juste avant l’expiration : prévoyez du temps pour les contrôles et les nouvelles tentatives.
Support et SLA
La disponibilité n’est pas une note subjective : elle doit correspondre à une instance, une période et des relevés d’état vérifiables.
Disponibilité cible
En cas d’interruption, notez l’identifiant de commande, le nœud de l’instance, les heures de début et de rétablissement, le message d’erreur, les étapes de reproduction et les journaux masqués. Les relevés, la fenêtre de mesure, le périmètre, les exclusions, le délai de demande et les modalités de crédit de service sont définis par lesconditions de service.
Les 99,9 % correspondent à l’objectif de disponibilité utilisé pour évaluer l’accessibilité du service associé à la commande pendant la fenêtre de mesure applicable. Le calcul, les relevés, les exclusions — notamment les événements indépendants de la volonté du service et les actions de l’utilisateur — ainsi que les conditions de crédit sont définis par les conditions de service.
Connectez-vous à laconsole pour envoyer une demande et indiquez l’identifiant de commande, le nœud, l’heure du problème, les étapes de reproduction, le résultat attendu, le résultat réel et les journaux masqués. Si le problème concerne le réseau, ajoutez l’opérateur local, la ville de test, la latence, le taux de perte et les résultats de routage.
Envoyez un e-mail à support@xcodevm.com. Indiquez l’adresse e-mail associée au compte, l’identifiant de commande, le nœud, l’heure de l’incident et les informations d’erreur masquées. N’envoyez ni mot de passe, ni clé privée, ni justificatif de paiement complet, ni données métier non masquées.
Mise en service
Vérifiez d’abord les deux configurations M4, puis choisissez parmi les quatre nœuds celui qui offre le meilleur chemin réseau réel. Avant le règlement, confirmez le montant en dollars, la durée et les options.