Chaque machine physique Apple Silicon est attribuée à un seul client. Ce n’est pas une machine virtuelle et son CPU, son GPU et sa mémoire unifiée ne sont pas partagés avec d’autres clients.
Vérifiez l’isolation, les accès et le traitement des données avant d’y transférer vos projets et vos compilations.
Un nœud de votre commande est inaccessible ? Connectez-vous au portail et ouvrez un ticket en indiquant votre numéro de commande et l’heure de l’incident.
Un objectif de disponibilité et les mesures historiques sont deux choses différentes. Nous présentons ici les objectifs de service et leur mode de calcul, sans faire passer un objectif pour un résultat mesuré.
Objectif mensuel de disponibilité
99.9%
Tous les nœuds fonctionnent toute l’année, 365 jours par an. Si la disponibilité mensuelle passe sous les 99,9 %, la durée de location est prolongée au prorata du temps d’indisponibilité.
La jauge turquoise indique l’objectif de service, pas les résultats d’un suivi quotidien.
Nous vérifions l’accessibilité des nœuds, les heures de début et de rétablissement des incidents, ainsi que les commandes concernées. Les détails quotidiens vérifiables ne sont pas publiés sur cette page. Nous n’affichons donc pas une série de jours entièrement au vert et ne prétendons pas que tout a fonctionné normalement pendant les 90 derniers jours.
La disponibilité mensuelle se calcule ainsi : durée totale de service du mois, moins le temps d’indisponibilité vérifié, puis divisée par la durée totale de service du mois. Dans votre demande, indiquez l’heure de l’incident et le fuseau horaire utilisé. Inutile d’en déterminer vous-même la cause ; les messages d’erreur de connexion d’origine sont plus utiles qu’une simple mention « impossible de se connecter ».
Les interruptions dues aux actions de l’utilisateur et les cas de force majeure sont définis dans les conditions de service. Un seul délai d’attente SSH ne suffit pas à prouver qu’un nœud entier était indisponible. L’évaluation tient compte du mode de connexion, du chemin réseau et des journaux du nœud. Consultez les conditions de service pour connaître les modalités applicables.
Une machine dédiée évite la concurrence entre clients. Les permissions des projets, la collaboration et les tâches simultanées restent à gérer sur la machine.
Chaque commande correspond à une machine physique dédiée, et non à une instance virtuelle créée sur un hôte partagé. Les autres clients n’utilisent ni son CPU, ni son GPU, ni sa mémoire unifiée et ne partagent pas votre environnement macOS.
L’interface graphique et la ligne de commande de macOS sont pleinement disponibles. Xcode, les simulateurs et Metal s’exécutent dans un environnement natif. Vos propres compilations, tests et tâches d’inférence simultanés se partagent toujours les ressources de la même machine.
Si plusieurs membres de l’équipe utilisent le nœud à tour de rôle, gérez leurs comptes système, clés publiques SSH et droits sur les répertoires de projet. Une machine dédiée ne signifie pas que chaque membre doit avoir les droits administrateur, ni que vous devez partager une même clé privée.
Pour évaluer les performances, notez également la taille du projet, la version de Xcode, le nombre de tâches simultanées et l’état du cache. Une machine dédiée évite la concurrence avec d’autres clients, mais ne garantit pas une durée de compilation fixe pour toutes les charges de travail.
À la fin de la location, le disque est effacé et le système réinstallé avant que la machine soit attribuée au client suivant. Le nœud n’est pas une solution d’archivage à long terme : conservez vos sauvegardes ailleurs.
Sauvegardez sur un espace de stockage que vous gérez le code non validé, les livrables, les configurations nécessaires et les clés. Vérifiez que la sauvegarde s’ouvre et que le projet peut être récupéré à nouveau ; ne vous contentez pas de vérifier que la commande de copie s’est terminée.
Supprimez les runners qui ne sont plus utilisés et révoquez les jetons de déploiement ainsi que les autorisations d’accès aux dépôts. L’effacement du disque élimine les données locales, mais ne révoque pas les identifiants dans vos systèmes externes.
À la fin de la location, le disque est effacé et le système réinstallé avant la remise de la machine au client suivant. Ne comptez pas sur une machine dont la location est terminée pour récupérer vos fichiers de projet.
Premièrement, le code et les fichiers volumineux : vérifiez que les commits Git et les objets volumineux ont bien été synchronisés. Deuxièmement, les livrables : archives, rapports de test, journaux et résultats de compilation qui n’ont pas encore été envoyés. Troisièmement, l’environnement reproductible : fichiers de verrouillage des dépendances, versions des outils et configuration CI. Il n’est pas nécessaire de tout conserver parmi les caches reproductibles ; exportez en priorité les éléments qui ne peuvent pas être recréés.
Nous ne consultons pas les fichiers ni les données de projet présents sur les nœuds des clients. Les données de compte, les commandes et les identifiants de transaction sont des informations de gestion du service, conservées selon des modalités différentes des fichiers de projet sur le nœud. Pour en savoir plus sur les finalités de collecte et vos droits, consultez notre notice de confidentialité.
La connexion se fait par défaut avec une clé SSH. Après connexion, retrouvez dans le portail les identifiants de connexion et les opérations liées à vos commandes. Vous pouvez réinitialiser vos identifiants si nécessaire.
Générez une clé sur votre propre client et gardez la clé privée sur celui-ci ; ne transmettez que la clé publique. Lors de la première connexion, vérifiez les informations du nœud et l’empreinte de sa clé d’hôte. Si l’empreinte change, vérifiez d’abord si le système a été réinstallé : n’ignorez pas l’avertissement.
Protégez votre clé locale par une phrase secrète. Ne placez pas la clé privée dans un dépôt, des journaux de compilation ou un ticket, et ne partagez pas une même clé privée entre plusieurs membres.
Lorsqu’un membre quitte le projet, supprimez sa clé publique et les droits de compte dont il n’a plus besoin. Pour la CI, utilisez un compte de service et des jetons dédiés ; gérez séparément les accès au dépôt, la compilation et le déploiement.
N’ouvrez que les ports nécessaires. Après la réinitialisation des identifiants, vérifiez que les anciens clients, scripts d’automatisation et runners n’utilisent plus l’ancienne configuration. Vous éviterez ainsi que des échecs de connexion répétés ne masquent le véritable problème.
Dans un ticket, vous pouvez indiquer l’empreinte de la clé publique, la version du client, le texte de l’erreur et des extraits de configuration expurgés. N’envoyez ni mot de passe, ni clé privée SSH, ni jeton d’accès complet, ni variable d’environnement contenant un secret. Si un diagnostic temporaire nécessite des droits supplémentaires, convenez au préalable de leur périmètre et de leur révocation dans le ticket.
Toutes les commandes sont réglées en dollars américains (USD) et deux modes de paiement sont acceptés. Les moyens de paiement disponibles sont ceux indiqués par l’interface de paiement.
Les paiements par carte sont traités par Stripe ; nous ne conservons pas les numéros de carte. Pour rapprocher une commande, nous utilisons les identifiants de transaction associés et le statut du paiement. Vous n’avez pas besoin d’envoyer votre numéro de carte complet ni le cryptogramme par e-mail ou dans un ticket.
En cas d’échec de paiement ou de statut incohérent, indiquez le numéro de commande, l’heure, le montant et le message d’erreur affiché. Masquez vos données personnelles sur les captures d’écran et ne faites pas plusieurs paiements pour vérifier le statut.
Le paiement est vérifié à partir des données de la blockchain. Avant de payer, vérifiez que le réseau, l’adresse de réception et le montant correspondent à ceux de la page de paiement. Pour la vérification, le hash de transaction suffit : ne communiquez ni clé privée ni phrase de récupération de portefeuille.
Si le statut de la commande n’est pas encore à jour après le transfert, conservez le hash de transaction et le numéro de commande, puis ouvrez un ticket. Aucun délai fixe de réception n’est garanti et une capture d’écran ne remplace pas les données de transaction.
Les fichiers des nœuds, les données de compte et les identifiants de transaction sont des catégories de données distinctes. Pour une question de paiement, joignez uniquement les informations liées à la commande ; n’ajoutez pas de fichiers de projet ni de matériel de signature.
Envoyez tout signalement de sécurité à support@xcodenode.com. Pour un incident touchant un nœud lié à une commande, vous pouvez également ouvrir un ticket depuis le portail.
Indiquez la page, la commande ou le nœud concerné, ainsi que le comportement observé. Sans preuve, ne présentez pas une suspicion comme une fuite de données avérée.
Décrivez les actions dans leur ordre réel, avec le résultat attendu et le résultat obtenu. Limitez vos vérifications aux ressources auxquelles vous êtes autorisé à accéder et ne consultez pas les données d’autres clients.
Précisez l’heure et le fuseau horaire, puis joignez un message d’erreur ou une capture d’écran expurgés. Supprimez les jetons, mots de passe, clés privées et données personnelles, tout en conservant le contexte utile.
Complétez les informations par e-mail ou dans le ticket et assurez le suivi dans le même fil. Les incidents empêchant l’accès à un nœud sont traités en priorité ; les réponses précisent la suite donnée.
Ne joignez aucun secret permettant d’accéder directement à un nœud. Si vous pensez qu’un identifiant a été compromis, révoquez d’abord les jetons concernés, supprimez toute clé publique suspecte ou réinitialisez les identifiants. Conservez ensuite les éléments utiles et signalez l’incident.
Choisissez une machine physique dédiée et préparez vos clés, vos sauvegardes et les droits de votre équipe. Les configurations, tarifs selon la durée de location et options sont détaillés sur la page des offres.