Conditions de location de Mac dans le cloud

L’accès au site, la création d’une commande, le paiement, la réception des informations de connexion ou l’utilisation effective d’un appareil valent lecture, compréhension et acceptation des présentes conditions ainsi que des règles affichées dans l’interface de commande. Toute personne agissant au nom d’une équipe ou d’une organisation doit disposer de l’autorité nécessaire pour accepter ces conditions et gérer les commandes.

Les présentes conditions sont respectées conjointement par l’utilisateur et l’entité exploitant la plateforme. Les lois de la juridiction où cette entité est établie régissent le droit applicable et l’interprétation du contrat ; les litiges qui ne peuvent être résolus par un échange raisonnable relèvent des tribunaux compétents de cette juridiction.

Si l’utilisateur n’accepte pas ces conditions, il doit cesser de créer une commande ou d’utiliser le service. Pour une commande déjà créée mais dont les étapes suivantes ne sont pas terminées, il peut passer par unticket dans la consoleou envoyer un e-mail àsupport@deploymini.comen indiquant les informations de la commande et le problème rencontré.

DplyMini propose la location de machines physiques dédiées Mac dans le cloud. Chaque commande valide correspond au nœud physique indiqué dans la commande ; l’appareil n’est pas virtualisé. La configuration, le stockage, la région du nœud et la durée de location sont ceux confirmés par l’utilisateur.

Le catalogue actuel comprend les configurations DeployMini M4 16 et DeployMini M4 24. Le stockage supplémentaire et l’agrégation Thunderbolt 5 sont des options distinctes ; seuls les éléments explicitement sélectionnés et confirmés dans la commande font partie de la livraison. L’adresse réseau, les paramètres de connexion et les informations du nœud sont ceux du relevé de livraison réel.

Le service fournit une interface graphique macOS et un environnement en ligne de commande pour le développement iOS/macOS, la CI/CD, les builds automatisés, les tests et les tâches expérimentales conformes à ces conditions. L’utilisateur doit vérifier lui-même la compatibilité des versions logicielles, dépendances, licences, ressources mémoire, stockage et liaisons régionales avec la configuration choisie.

Avant de passer commande, l’utilisateur doit vérifier le modèle, la mémoire, le stockage de base, le stockage supplémentaire, le nœud cible et la durée de location. Les nœuds disponibles sont Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong et États-Unis — côte Ouest ; les deux modèles peuvent être commandés sur ces cinq nœuds. La disponibilité réelle est celle renvoyée en temps réel par la console.

Après confirmation de la commande, l’état de livraison, les informations de l’appareil, l’adresse de connexion, la durée et les opérations d’administration disponibles sont enregistrés dans la console. À réception des informations de livraison, l’utilisateur doit vérifier rapidement leur concordance avec la commande et l’appareil ; en cas d’écart de configuration, de région ou de durée, il doit suspendre l’écriture de données importantes et envoyer un ticket depuis laconsole.

L’utilisateur doit utiliser les accès d’administration associés à la commande dans la console et ne doit pas modifier la cible de connexion ou les paramètres de livraison à partir d’informations provenant d’une source inconnue. Pour les connexions à distance, consultez leguide d’assistance.

Le service applique uniquement les tarifs journaliers, hebdomadaires, mensuels et trimestriels indiqués sur lapage des offreset dans l’interface de confirmation de commande. La durée choisie constitue l’unité de facturation de la commande concernée et ne peut pas être automatiquement convertie, fractionnée ou remplacée par une autre durée.

Les frais des appareils, du stockage supplémentaire et de l’agrégation Thunderbolt 5 sont tous facturés en dollars américains (USD). Le montant total dépend du modèle, de la durée, des options disponibles pour le nœud et des suppléments choisis par l’utilisateur ; le montant final est celui affiché lors de la confirmation avant l’envoi de la commande.

Avant de confirmer la commande, l’utilisateur doit évaluer lui-même la durée de sa tâche. À l’approche de la fin de la location, il doit prévoir suffisamment de temps pour exporter les artefacts, migrer les données du projet, révoquer les identifiants temporaires et organiser la suite de la location.

DplyMini accepte uniquement USDT-TRC20 ainsi que Visa / Mastercard / Amex (via Stripe). Les passerelles réellement disponibles sont celles renvoyées par l’interface au moment de l’envoi de la commande ; tous les montants sont libellés et réglés en dollars américains (USD).

L’utilisateur doit vérifier le réseau de paiement, le montant de la commande, les informations du bénéficiaire et l’état de la transaction. Avec USDT-TRC20, il doit s’assurer que le réseau sélectionné correspond exactement. Avec une carte bancaire, il doit effectuer les vérifications demandées dans l’interface de paiement. En cas d’erreur de saisie, de mauvais réseau ou de paiement lancé plusieurs fois, il doit conserver immédiatement l’identifiant de transaction et demander une vérification via un ticket dans la console.

Les demandes d’assistance ne doivent pas contenir de données de paiement complètes. Pour retrouver un paiement, l’utilisateur peut fournir le numéro de commande, l’identifiant de transaction, l’heure du paiement, le montant et une capture d’écran partiellement masquée. La plateforme ne traite que les statuts de transaction et identifiants associés nécessaires à l’exécution de la commande, au rapprochement comptable, aux contrôles de sécurité et aux obligations applicables.

L’utilisateur peut employer l’appareil pour le développement logiciel, les builds, les tests, l’automatisation, le traitement des données, la validation de l’inférence de modèles et les tâches audio-vidéo licites. Il doit respecter les lois applicables, les règles de propriété intellectuelle, les licences logicielles, les exigences de cybersécurité et les limites d’utilisation raisonnable.

Il est interdit d’utiliser le service pour obtenir un accès non autorisé, effectuer des scans malveillants, voler des identifiants, diffuser du code malveillant, mener des attaques réseau, contourner des contrôles d’accès, porter atteinte à la propriété intellectuelle ou commettre toute autre activité illégale. Il est également interdit de perturber le réseau du nœud, les systèmes de la plateforme, les services en amont ou l’utilisation normale par d’autres utilisateurs.

Une consommation durable et anormale des ressources réseau, un trafic susceptible d’affecter sensiblement la stabilité du nœud, le contournement de limites techniques ou la dissimulation d’un usage à haut risque peuvent déclencher un contrôle de sécurité. À réception d’une demande de vérification, l’utilisateur doit fournir la description de la tâche, l’heure, le périmètre cible et les journaux masqués liés à l’incident, puis cesser rapidement toute opération susceptible d’en aggraver les effets.

L’utilisateur est responsable de la protection de son compte console, de ses clés SSH, identifiants de connexion, clés de build, jetons de dépôt de code et autres éléments d’accès. Chaque personne doit utiliser des identifiants distincts et traçables ; il ne faut pas partager durablement une même clé privée ni envoyer d’informations sensibles dans des conversations, des dépôts publics ou le corps d’un ticket standard.

L’utilisateur doit limiter les autorisations, retirer rapidement les accès des personnes ayant quitté l’équipe et, en cas de suspicion de fuite, révoquer immédiatement les clés concernées, renouveler les jetons et vérifier les opérations récentes. Les opérations effectuées sur l’appareil avec le compte de l’utilisateur ou des identifiants autorisés par celui-ci relèvent de la gestion de l’utilisateur et de son équipe.

En cas de connexion inhabituelle, de processus inconnu, de changement d’adresse de connexion ou de modification de configuration inattendue, l’utilisateur doit d’abord arrêter les tâches sensibles, conserver les journaux masqués et les informations horaires nécessaires, puis envoyer un rapport via unticket dans la console. Les tickets ne doivent contenir ni mot de passe, ni clé privée, ni données de paiement complètes.

L’utilisateur est responsable du code, des modèles, ressources, caches, artefacts de build, fichiers de configuration et identifiants écrits sur la machine physique dédiée. L’appareil est un environnement d’exécution et ne doit pas constituer l’unique emplacement de sauvegarde des données du projet.

Les données importantes doivent disposer d’une copie indépendante et être protégées, selon leur sensibilité, par le chiffrement, le contrôle d’accès et la vérification d’intégrité. Pour les fichiers volumineux ou les lots de ressources, il est recommandé de transférer les données par lots et de vérifier les sommes de contrôle. Avant tout nettoyage, écrasement, formatage ou script à grande échelle, il faut confirmer le chemin cible et l’existence d’une copie récupérable.

Avant la fin de la location, l’utilisateur doit exporter le projet et les artefacts de build, sauvegarder les journaux et configurations nécessaires, migrer les données encore utiles, révoquer les identifiants temporaires, supprimer les contenus sensibles inutiles et vérifier la suite de la commande dans la console. Commencer la migration après la fin de la location peut empêcher l’achèvement prévu de la tâche.

Pour traiter une demande d’assistance, la plateforme n’a besoin que d’informations masquées directement liées à l’identification de la panne. L’utilisateur ne doit pas envoyer par e-mail ou dans un ticket l’intégralité des données du projet, une clé privée, un mot de passe ou des données de paiement complètes. Les règles de traitement des informations sont disponibles dans lapolitique de confidentialité.

Tous les nœuds sont fournis avec un objectif de fonctionnement normal 365 jours par an, toute l’année. Une panne matérielle, un incident réseau, un événement affectant un service en amont, un cas de force majeure ou une opération de l’utilisateur peuvent néanmoins affecter la connexion, l’exécution des tâches ou le transfert des données.

En cas de problème de connexion, l’utilisateur doit vérifier successivement son réseau local, le DNS, l’adresse cible, le port, les identifiants, le service distant et l’état du nœud dans la console. Pour les builds continus, il doit conserver les journaux, le code de sortie et les informations de la dernière exécution réussie afin de distinguer un problème d’environnement, de projet ou de nœud.

Si l’intervention de la plateforme est nécessaire, l’utilisateur doit envoyer depuis la console un ticket associé à la commande et fournir le numéro de commande, le nœud, l’heure de l’incident, l’environnement client, les étapes de reproduction, le message d’erreur et les journaux masqués. La plateforme examinera et traitera l’incident selon son impact et les possibilités de rétablissement.

Les conséquences d’un cas de force majeure, d’une opération de l’utilisateur, de son réseau, de sa configuration logicielle ou d’un comportement dépassant l’autorisation accordée sont traitées selon la cause de l’incident et les règles applicables. Les deux parties doivent prendre des mesures raisonnables pour limiter l’extension des effets et conserver les éléments nécessaires à l’analyse.

En cas de violation grave de ces conditions, de risque de sécurité avéré, de défaut de règlement d’une échéance, d’interférence avec un nœud ou un autre utilisateur, de refus de cesser un comportement à haut risque ou d’obligation de restriction imposée par les règles applicables, la plateforme peut, selon le niveau de risque, limiter certaines opérations, suspendre l’accès ou résilier la commande concernée.

Lorsque les conditions le permettent et sans accroître le risque de sécurité, la plateforme indiquera le problème à traiter dans la console, par ticket ou via les coordonnées associées à l’utilisateur. Après notification, l’utilisateur doit sauvegarder rapidement les données nécessaires, cesser l’opération non conforme et coopérer au contrôle. En cas d’incident de sécurité urgent, des mesures restrictives peuvent être prises avant la communication détaillée de l’incident.

Chaque partie est responsable des comptes, systèmes, données et opérations relevant de son contrôle. La responsabilité est déterminée en tenant compte de la commande, de la cause réelle de l’incident, des mesures raisonnables prises par les deux parties et des règles applicables ; toute limitation de responsabilité s’applique dans les limites autorisées par ces règles.

L’utilisateur doit réduire les risques liés aux points de défaillance uniques grâce aux sauvegardes, au principe du moindre privilège, à la rotation des identifiants, aux journaux de tâches et aux scripts de déploiement reproductibles. La plateforme gère les nœuds et la livraison ; l’utilisateur gère les données du projet, la configuration logicielle, le périmètre des autorisations et les actions de son équipe : ces responsabilités forment ensemble la chaîne complète d’exploitation.

Les présentes conditions ont été mises à jour le 21 août 2026. La plateforme peut les modifier en raison de changements dans le périmètre des services, le processus de commande, les exigences de sécurité ou les obligations applicables. Les changements importants seront signalés de manière visible sur le site, dans la console ou via les coordonnées associées à la commande.

Les conditions mises à jour s’appliquent aux accès, commandes et utilisations ultérieurs à compter de la date d’entrée en vigueur indiquée sur la page. L’utilisateur doit vérifier la version en vigueur avant de créer une nouvelle commande ou de modifier une utilisation à long terme ; la poursuite de l’utilisation vaut acceptation des conditions alors en vigueur.

Les questions relatives aux conditions, aux commandes, à la comptabilité, aux rapports de sécurité ou aux partenariats peuvent être envoyées àsupport@deploymini.com. Pour une commande existante, une connexion à un appareil ou un problème d’exploitation urgent, connectez-vous en priorité à laconsole pour envoyer un ticketafin d’associer la demande aux données de la commande et du nœud.

Lors de la prise de contact, indiquez le type de problème, le numéro de commande concerné, le nœud cible, l’heure de survenue et le paragraphe des conditions à confirmer. N’envoyez ni mot de passe, ni clé privée, ni données de paiement complètes.