Centre d'assistance

Un problème sur votre Mac cloud ? Essayez d'abord le mode d'emploi, contactez-nous si ça ne suffit pas

La plupart des problèmes — connexion impossible, besoin de réinstaller, erreurs de CI — se résolvent seul en cinq minutes en suivant les étapes ci-dessous ; si une intervention humaine est nécessaire, le ticket et l'e-mail sont disponibles toute l'année, avec une réponse 24/7 pour les incidents critiques.

Prise en main rapide

Les dix premières minutes après réception des accès

Deux minutes après l'activation, vous recevrez vos identifiants SSH/VNC dans la console et par e-mail. Suivez ces trois étapes pour être opérationnel sur le bureau en dix minutes.

1. Première connexion SSH

Le nom d'hôte fourni ressemble à jp1-1024.hirevps.com ; connectez-vous simplement avec le terminal de votre système :

# replace host and user with your credentials
ssh omac@jp1-1024.hirevps.com
# first login: change your password
passwd

Changez immédiatement le mot de passe après connexion, puis importez votre clé SSH publique dans la console et désactivez l'authentification par mot de passe : plus sûr et plus pratique.

2. Activer VNC / le partage d'écran

Le partage d'écran est activé par défaut à la livraison ; si vous l'avez désactivé manuellement, une seule commande via SSH suffit à le réactiver :

# enable macOS remote management (screen sharing)
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart \
  -activate -configure -access -on -restart -agent

Sur Mac, utilisez l'app « Partage d'écran » ; sur Windows/Linux, n'importe quel client VNC fera l'affaire — saisissez le nom d'hôte avec le port 5900.

3. Checklist de vérification de l'environnement

  • L'image de livraison inclut déjà Homebrew, Git et les Xcode Command Line Tools ; vérifiez les versions avec xcodebuild -version et brew --version dans le terminal.
  • Pour un usage CI/CD, lancez d'abord un build complet en guise de référence : notez les durées à froid et incrémentales, cela servira de base de comparaison en cas de problème de performance.
  • Placez idéalement certificats et clés dans un keychain dédié, et déverrouillez-le explicitement dans le script de build pour éviter les échecs de signature liés au verrouillage de session graphique.
  • Avant de résilier, synchronisez code et artefacts vers votre dépôt ou votre stockage objet — les données sont irrécupérables après effacement (voir la répartition des responsabilités sur les données dans les conditions de service).
Opérations courantes

Réinstallation, changement de version, migration de données : tout se fait depuis la console

Ces trois opérations sont entièrement en libre-service, sans besoin d'ouvrir un ticket ; réinstallation et changement de version sont gratuits et illimités.

Réinstaller macOS

Console → votre instance → « Réinstaller le système », choisissez la version puis confirmez ; l'opération prend environ 15 à 25 minutes (selon mesure réelle).

La réinstallation efface l'intégralité du SSD — poussez votre code vers un dépôt distant et copiez vos artefacts avant de confirmer.

Changer de version du système

Choisissez entre la version stable actuelle et la précédente version majeure (par ex. Sequoia / Sonoma) ; certains nœuds proposent des images bêta, voir la liste dans la console.

Le changement de version suit le même processus de réinstallation et efface également le disque ; pour des tests multi-versions, il est plus pratique de louer une machine à la journée puis de la résilier une fois le test terminé.

Snapshots et migration de données

Avant une réinstallation, vous pouvez créer un snapshot local APFS en sécurité ; pour migrer vers une autre machine, rsync est recommandé :

# create a local snapshot before risky changes
tmutil localsnapshot
# sync your workspace to the new machine
rsync -avz ~/work/ omac@new-host:~/work/

Nous n'accédons pas et ne sauvegardons pas les données présentes sur votre machine (voir notre politique de confidentialité) — pensez donc à synchroniser régulièrement vos données importantes vers un dépôt distant ou un stockage objet ; les snapshots locaux sont eux aussi effacés lors d'une réinstallation.

Intégration CI/CD

Faites de ce Mac votre nœud de build

Machine physique dédiée avec accès root : l'intégration aux principaux outils CI suit la procédure officielle standard, sans aucune adaptation propriétaire. Choisissez votre outil :

Configurer un runner self-hosted

Dans les paramètres Actions de votre dépôt ou organisation, choisissez « Nouveau runner self-hosted (macOS / ARM64) », puis collez dans le terminal de votre Mac cloud les commandes de téléchargement et de configuration fournies :

# run these on your cloud Mac (values come from your Actions settings page)
./config.sh --url <your-repo-url> --token <runner-token> \
  --labels macos,arm64,hirevps
# install as a service so it survives reboots
./svc.sh install && ./svc.sh start

Dans votre workflow, remplacez simplement runs-on par [self-hosted, macos, arm64]. Un M4 en dedicated hardware exécute généralement xcodebuild nettement plus vite qu'un runner hébergé — l'écart réel dépend de votre projet.

Dépannage

Trois problèmes fréquents : commencez par cette checklist

Avant d'ouvrir un ticket, prenez deux minutes pour suivre la checklist correspondante — plus de la moitié des signalements se résolvent dès l'étape 2.

Impossible de se connecter (délai SSH dépassé / écran noir en VNC)
  1. Ouvrez la page de statut pour vérifier que votre nœud fonctionne normalement — si c'est le cas, le problème vient probablement de votre côté.
  2. Faites un ping du nom d'hôte depuis votre machine pour vérifier l'accessibilité ; essayez aussi depuis un partage de connexion mobile pour écarter un blocage des ports 22/5900 par votre réseau d'entreprise ou votre FAI.
  3. Vérifiez le statut de l'instance dans la console : si elle indique « En fonctionnement », essayez d'abord « Redémarrage à distance » ; si elle semble bloquée au démarrage, attendez 3 minutes puis rafraîchissez.
  4. Vérifiez si vous avez modifié le port SSH ou les règles de pare-feu (pfctl) — c'est la cause la plus fréquente d'auto-verrouillage ; le « terminal de secours » de la console permet de contourner le réseau et d'accéder directement au système pour corriger.
  5. Si rien de tout cela ne fonctionne, ouvrez directement un ticket en cochant « Connexion impossible » : il sera traité en priorité P1.
Les builds ralentissent (durée xcodebuild en nette hausse)
  1. Vérifiez d'abord que la tâche elle-même n'a pas changé : après une mise à jour de dépendances ou une montée de version majeure de Xcode, le premier build reconstruit index et cache — un ralentissement ponctuel est normal.
  2. Utilisez top -o cpu pour repérer un processus emballé ; l'indexation initiale de Spotlight peut saturer le CPU, désactivable avec mdutil -a -i off.
  3. Vérifiez si votre CI vide systématiquement DerivedData à chaque exécution — conserver ce cache réduit généralement fortement le temps des builds incrémentaux.
  4. Utilisez df -h pour vérifier l'espace disque disponible : au-delà de 90 % d'occupation du SSD, les performances d'écriture chutent — libérez de l'espace avant de comparer.
  5. Votre machine étant physique et dédiée, il n'y a pas de voisinage bruyant. Si le ralentissement persiste malgré tout cela, ouvrez un ticket avec les journaux de build avant/après, nous investiguerons au niveau matériel.
Disque plein (No space left on device)
  1. Identifiez d'abord les gros consommateurs : du -sh ~/Library/Developer/* — DerivedData, anciens runtimes de simulateur et Archives d'Xcode occupent généralement le plus de place.
  2. Nettoyage sans risque : rm -rf ~/Library/Developer/Xcode/DerivedData ; supprimez les runtimes de simulateur inutilisés avec xcrun simctl runtime delete.
  3. Les snapshots locaux APFS occupent aussi de l'espace : consultez-les avec tmutil listlocalsnapshots /, supprimez les anciens avec tmutil deletelocalsnapshots.
  4. Pour les machines CI, ajoutez une étape de nettoyage régulier dans le pipeline plutôt que d'attendre la saturation.
  5. Toujours à court d'espace après nettoyage ? Il est temps de monter en gamme — une mise à niveau du SSD ne facture que la différence, la migration de données est décrite plus haut, ou choisissez directement une configuration plus grande sur la page des offres.
SLA et délais de réponse

Des engagements de réponse écrits noir sur blanc

Les tickets sont classés en trois niveaux selon leur impact ; le niveau est choisi par vous à l'ouverture, puis confirmé par notre équipe — nous ne promettons que ce que nous pouvons tenir.

Tableau des niveaux de ticket et des délais de réponse
Niveau Cas typiques Première réponse Plage de service
P1 Critique Machine inaccessible, panne matérielle, nœud indisponible ≤ 30 minutes 24/7 toute l'année
P2 Dégradé Performance anormale, réinstallation bloquée, instabilité réseau intermittente ≤ 4 heures 24/7 toute l'année
P3 Courant Questions d'usage, facturation, conseils de configuration ≤ 12 heures Jours ouvrés

Règles de disponibilité et de compensation

  • Engagement de disponibilité mensuelle par instance de 99,9 % ; tous les nœuds fonctionnent en continu 365 jours par an, sans période d'arrêt planifiée.
  • Pour chaque tranche de 0,1 % en dessous de l'engagement, un avoir équivalent à 5 % des frais du mois est accordé, avec un plafond mensuel égal à 100 % des frais de l'instance concernée pour ce mois.
  • Faites votre demande de compensation depuis la console en indiquant la période concernée ; nous vérifions par rapport aux données de supervision et créditons votre compte sous 7 jours ouvrés.
  • Les indisponibilités dues à un cas de force majeure ou à vos propres actions (suppression accidentelle de fichiers système, mauvaise configuration réseau, etc.) ne sont pas couvertes par la compensation — mais nous vous aidons quand même à résoudre le problème.

Comment obtenir la réponse la plus rapide

  • Connectez-vous à la console pour ouvrir votre ticket : le système ajoute automatiquement le numéro de machine et les informations de nœud, évitant un aller-retour par e-mail.
  • Précisez clairement « quand, quelle action, quelle erreur observée », et collez le texte complet de l'erreur plutôt qu'une capture d'écran — cela accélère nettement le diagnostic.
  • Pour un problème P1, cochez directement « Urgent » dans le ticket plutôt que de passer par e-mail — les e-mails sont traités selon les délais P3.
  • Les conditions complètes de compensation figurent dans les conditions de service, qui font foi en cas de divergence.
Service 365 jours par an · sans arrêt planifié

Statut du service et annonces, tout sur une seule page

La disponibilité en temps réel, l'historique et les annonces d'incidents des nœuds de Singapour, Tokyo, Séoul, Hong Kong, Côte Ouest et de la côte ouest américaine sont publiés sur la page de statut ; tout incident affectant le service y est mis à jour en continu. Consultez-la avant de signaler un problème : elle vous aide à distinguer immédiatement un problème côté plateforme d'un problème local.

  • JP TokyoDisponibilité en temps réel et historique sur la page de statut
  • SG SingapourDisponibilité en temps réel et historique sur la page de statut
  • US-W Côte ouestDisponibilité en temps réel et historique sur la page de statut

Le guide ne couvre pas votre cas ?

Connectez-vous à la console, ouvrez un ticket, collez le message d'erreur original — on s'occupe du reste.

Ouvrir un ticket dans la console