Vérifiez la livraison, l’utilisation et la responsabilité des données avant d’activer votre Mac dans le cloud

En accédant à ce site, en créant un compte, en passant une commande, en effectuant un paiement ou en commençant à utiliser un nœud physique livré par VMArm, vous reconnaissez avoir lu, compris et accepté les présentes conditions ainsi que les politiques associées. Toute personne agissant au nom d’une organisation confirme également disposer de l’autorité nécessaire pour accepter ces conditions et gérer les commandes de cette organisation.

Si vous n’acceptez pas les conditions en vigueur, cessez de créer des commandes ou d’utiliser le nœud. La simple consultation des contenus publics ne constitue pas une acceptation par VMArm d’une demande d’achat ; la relation de service est établie conjointement par les informations de commande, la confirmation du paiement et les relevés de livraison du nœud.

VMArm fournit des Mac physiques dédiés dans le cloud basés sur Apple Silicon. Chaque commande valide correspond à un nœud physique indépendant doté de la configuration sélectionnée ; les ressources ne sont pas partagées avec d’autres commandes par l’intermédiaire d’une machine virtuelle. La livraison comprend le modèle, la mémoire, le stockage, la région du nœud, les options supplémentaires et la période de location confirmés dans la commande.

Le catalogue actuel comprend VMArm M4 Core (M4, 16 Go, 256 Go) et VMArm M4 Plus (M4, 24 Go, 512 Go). Les nœuds sont disponibles à Singapour, au Japon (Tokyo), en Corée du Sud (Séoul), à Hong Kong et dans l’ouest des États-Unis. Les combinaisons du catalogue sont généralement disponibles à la commande ; leur disponibilité réelle est indiquée en temps réel par la console.

Le service n’inclut pas les licences de logiciels tiers, les accès aux référentiels de code, les éléments de signature, la migration des données métier ni la publication d’applications qui ne figurent pas dans la commande. L’utilisateur doit vérifier lui-même que les dépendances de son projet et les licences logicielles respectent les exigences des fournisseurs concernés.

Avant de passer commande, l’utilisateur doit vérifier ses coordonnées, le modèle, le nœud, la période de facturation, le stockage supplémentaire et le nombre de connexions parallèles. Après confirmation du paiement, le système lance l’attribution et l’initialisation du nœud. Une commande standard nécessite environ 4 minutes entre la confirmation du paiement et la génération des informations de connexion.

1. Environ 1 minute
   Confirmation du paiement

   Vérification du montant de la commande, de l’état du paiement et de l’identifiant de commande correspondant.

2. Environ 1 minute
   Attribution du nœud

   Association d’un nœud physique dédié selon le modèle et la région sélectionnés.

3. Environ 1 minute
   Initialisation du système

   Préparation de l’environnement système et vérification de l’état d’accès de base.

4. Environ 1 minute
   Génération des informations de connexion

   Mise à disposition, dans la console, de l’adresse du nœud, des informations du compte et des accès aux opérations suivantes.

Les 4 minutes correspondent à la durée standard du processus et ne constituent pas un engagement de délai fixe pour chaque commande. En cas de conflit dans les informations de commande, d’impossibilité d’associer automatiquement le paiement, de signal de risque inhabituel ou de configuration nécessitant une vérification supplémentaire, VMArm peut procéder à un examen manuel et demander les informations nécessaires via un ticket dans la console ou l’adresse e-mail d’assistance.

Tous les frais sont réglés en dollars américains (USD). Les seuls modes de paiement acceptés sont USDT-TRC20 ainsi que Visa, Mastercard et Amex (via Stripe). Les passerelles effectivement disponibles sont déterminées par la réponse de l’interface côté serveur au moment du paiement.

Le prix réel du modèle, de la période et des options supplémentaires est celui indiqué sur la page des offres et dans la confirmation du paiement avant l’envoi de la commande. Avant de payer, l’utilisateur doit vérifier le montant, la devise, le réseau de paiement, les informations du bénéficiaire et l’identifiant de commande. En cas de problème dû au choix d’un mauvais réseau, à la saisie d’informations erronées ou à un paiement en double, il doit soumettre via un ticket un justificatif de transaction vérifiable.

La commande n’entre dans le processus de livraison qu’après confirmation du paiement et association avec la commande correspondante. Le prestataire de paiement peut effectuer les vérifications nécessaires en matière de sécurité des transactions ; VMArm ne traite que les informations nécessaires à la confirmation de la commande, à sa livraison et au rapprochement comptable.

Le droit d’utiliser le nœud est calculé selon la période de jour, semaine, mois ou trimestre confirmée dans la commande. Le renouvellement ne prend effet qu’après confirmation par l’utilisateur et validation du paiement correspondant. Avant la fin de la période en cours, l’utilisateur doit vérifier la date d’expiration dans la console et prévoir suffisamment de temps pour la confirmation du paiement et la migration des données.

À la fin de la période, si le renouvellement n’a pas été confirmé, l’accès au nœud peut être interrompu. L’utilisateur ne doit pas considérer l’accès après expiration comme une solution de conservation des données ni attendre le dernier moment pour effectuer une sauvegarde unique. Le code important, les artefacts de build, les certificats et les fichiers métier doivent être conservés en permanence dans un emplacement indépendant.

Toute demande d’annulation doit être soumise via un ticket dans la console et préciser le numéro de commande, le périmètre de l’annulation et le délai de traitement souhaité. Les périodes déjà commencées, les ressources de nœud déjà livrées et les options déjà activées sont examinées selon l’état de la commande et l’exécution effective. Une demande d’annulation n’annule pas automatiquement un paiement confirmé ni une livraison effectuée.

Dans le cadre d’autorisations légales, l’utilisateur peut employer le nœud pour le développement iOS, macOS et visionOS, la compilation et l’archivage Xcode, la préparation des mises en ligne TestFlight, les runners CI/CD self-hosted, la création de builds Unity iOS et les expérimentations avec des modèles locaux.

L’utilisateur ne doit pas utiliser le nœud pour commettre ou faciliter les actes suivants :

• Accès non autorisé :Scanner, tenter d’accéder à ou contrôler des systèmes, comptes, réseaux ou données auxquels il n’est pas autorisé à accéder.
• Propagation de programmes malveillants :Créer, déployer ou distribuer des programmes qui endommagent des systèmes, dérobent des informations ou contournent les contrôles de sécurité.
• Abus des ressources réseau :Lancer des attaques, envoyer en masse des informations non sollicitées ou monopoliser durablement les ressources au détriment d’autres services.
• Atteinte aux droits :Stocker, créer ou diffuser des contenus portant atteinte à la propriété intellectuelle, à la vie privée ou à d’autres droits légitimes.
• Mise en danger de la sécurité du nœud :Contourner les contrôles d’accès, détruire les journaux d’audit, perturber la détection de sécurité ou modifier sans autorisation l’état des connexions matérielles.
• Revente de l’accès :Revendre les identifiants de connexion ou le contrôle du nœud comme service indépendant sans confirmation écrite préalable.

Si un comportement susceptible de menacer le nœud, le réseau ou d’autres utilisateurs est détecté, VMArm peut prendre les mesures nécessaires, notamment limiter l’accès, préserver les journaux, demander une mise en conformité ou résilier la commande concernée. Ces mesures tiennent compte de l’étendue du risque, de son urgence et des éléments vérifiables ; dans la mesure du possible, le gestionnaire de la commande en est informé via la console.

L’utilisateur doit protéger soigneusement les identifiants de connexion à la console, les comptes système, les identifiants VNC, les certificats de signature, les jetons d’accès, les clés de référentiel de code et les informations d’enregistrement du runner. Les identifiants ne doivent pas être diffusés dans des documents publics, des messages non chiffrés ou des journaux de build accessibles à des personnes non concernées.

Les utilisateurs d’une organisation doivent attribuer les accès selon le principe du moindre privilège et révoquer rapidement les autorisations, mettre à jour les mots de passe et renouveler les jetons lorsqu’un membre quitte le projet, change de fonction ou qu’une fuite d’identifiants est suspectée. Le partage d’identifiants permanents entre plusieurs personnes réduit la traçabilité ; créez des comptes et des journaux d’audit distincts pour chaque rôle.

Les opérations effectuées avec des identifiants valides sont en principe considérées comme autorisées par le compte. En cas de connexion anormale, de tâche de build inconnue, de fuite des informations de connexion ou de modification accidentelle de la configuration, l’utilisateur doit immédiatement fermer les sessions concernées, renouveler les identifiants et ouvrir un ticket dans la console en indiquant le numéro de commande, l’heure de découverte et les mesures déjà prises.

L’utilisateur est responsable du code, des artefacts de build, des éléments de signature, des caches de dépendances, des fichiers de modèles et des données métier téléversés, créés, compilés ou conservés sur le nœud. Il doit s’assurer de disposer des autorisations nécessaires pour traiter ces contenus et établir une stratégie indépendante de sauvegarde et de restauration adaptée aux risques du projet.

Le répertoire de travail du nœud ne doit pas constituer l’unique copie des données. Il est recommandé de conserver le code dans un référentiel contrôlé, de synchroniser les artefacts de build vers un stockage indépendant, de stocker les certificats et éléments de restauration dans un emplacement isolé et de vérifier régulièrement que les sauvegardes peuvent réellement être restaurées. Les caches peuvent être reconstruits et ne doivent pas être inclus dans la même stratégie de sauvegarde que les données sources irremplaçables.

Avant une annulation, une expiration, une migration ou une modification de configuration, l’utilisateur doit exporter les données et vérifier les copies. L’utilisateur assume les responsabilités correspondantes en cas de perte due à une suppression, à un script erroné, à une fuite d’identifiants, à l’absence de sauvegarde ou à l’absence de vérification de la restauration.

Les nœuds VMArm fonctionnent normalement 365 jours par an, sans interruption périodique programmée. Leur disponibilité continue peut néanmoins être affectée par des incidents réseau, des pannes matérielles, des risques de sécurité, les actions de l’utilisateur, des incidents d’infrastructure en amont ou un cas de force majeure.

Pour corriger des vulnérabilités critiques, maintenir la sécurité du système ou rétablir un nœud défaillant, VMArm peut effectuer les mises à jour de sécurité, restrictions d’accès ou opérations de rétablissement nécessaires. Lorsque l’impact peut être anticipé, la console indique son périmètre, les actions recommandées et l’évolution de l’état ; en cas d’urgence imprévisible, VMArm donne priorité à la maîtrise du risque et met à jour les informations dès que des éléments vérifiables sont disponibles.

Si le nœud d’origine ne peut plus répondre aux exigences de sécurité ou de stabilité, VMArm peut proposer une migration nécessaire. L’utilisateur doit coopérer pour confirmer les informations de connexion, la date de migration et l’état de préparation des données. Avant le début de la migration, il doit continuer à conserver indépendamment le code, les certificats, les artefacts de build et les données métier essentielles.

La configuration de l’utilisateur, les dépendances tierces, les défauts du code, l’état des référentiels externes, le réseau local et le comportement du client ne relèvent pas de la disponibilité du nœud physique en tant que telle. Pour analyser un problème, les deux parties doivent s’appuyer sur l’état du nœud, les tests de connexion, les journaux système et de build ainsi que l’heure de survenue afin de distinguer les responsabilités.

Chaque partie est responsable de ses actes concernant l’exécution de la commande, la gestion des identifiants, les sauvegardes et l’utilisation légale. Pour les problèmes imputables à la livraison du service, VMArm agit sur la base des relevés de commande, de l’état du nœud et de l’impact vérifiable ; VMArm n’assume pas de responsabilité au-delà de celle exigée par les règles applicables pour les pertes dues à une erreur de configuration de l’utilisateur, à un accès non autorisé, à une défaillance d’un service tiers, au réseau local, à un cas de force majeure ou à l’absence de sauvegarde indépendante.

Pour toute réclamation ou tout litige concernant le service, l’utilisateur doit d’abord ouvrir un ticket dans la console ou envoyer un e-mail à support@vmarm.com en indiquant le numéro de commande, le nœud, l’heure de survenue, l’étendue de l’impact, les étapes de reproduction et des journaux expurgés. Les deux parties doivent d’abord vérifier les faits à partir des éléments disponibles et rechercher une résolution directe.

La conclusion, l’interprétation et l’exécution des présentes conditions sont régies par le droit de la juridiction où est établi l’opérateur de la plateforme. Tout litige non résolu à l’amiable peut être soumis à un tribunal compétent de cette juridiction.

VMArm peut mettre à jour les présentes conditions en raison de l’évolution des processus de service, des exigences de sécurité ou des règles applicables. Toute mise à jour ayant une incidence substantielle sur les droits ou obligations de l’utilisateur indiquera sa version et sa date d’entrée en vigueur sur le site ou dans la console. Continuer à créer des commandes, à renouveler un service ou à utiliser un nœud après l’entrée en vigueur d’une mise à jour vaut acceptation des conditions mises à jour.