Choisissez le canal le plus rapide selon l'urgence
La documentation en libre-service est la plus rapide, le ticket le plus complet, l'e-mail idéal pour garder une trace, et la page de statut vous aide à savoir d'emblée si le problème vient de la plateforme.
Centre de documentation
Cette page réunit prise en main, réinstallation, CI/CD et procédures de dépannage — copiez-collez les commandes directement.
Voir plus bas →Système de tickets
Connectez-vous à la console pour ouvrir un ticket, automatiquement lié aux informations de votre machine ; priorité disponible pour les incidents critiques.
Ouvrir un ticket dans la console →Assistance par e-mail
support@hirevps.com, pratique pour joindre captures d'écran, journaux et autres éléments à conserver.
Nous écrire →Page de statut
Disponibilité en temps réel de chaque nœud d'un coup d'œil — un rapide contrôle avant de signaler un incident peut vous éviter un aller-retour.
Voir le statut en temps réel →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 -versionetbrew --versiondans 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).
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.
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.
Configurer un nœud Jenkins
Dans « Gérer les nœuds » de Jenkins, créez un nouvel agent (méthode de lancement : inbound), puis démarrez le processus agent sur votre Mac cloud :
# download agent.jar from your Jenkins controller first
java -jar agent.jar \
-url <your-jenkins-url> \
-name hirevps-m4 \
-secret <agent-secret> \
-workDir ~/jenkins-agent
Il est recommandé d'enregistrer l'agent comme service via launchd pour un démarrage automatique, et d'ajouter au nœud le label macos-arm64 pour faciliter le routage des pipelines. Besoin d'un exemple de fichier plist ? Ouvrez un ticket et nous vous l'envoyons directement.
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)
- 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é.
- 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.
- 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.
- 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.
- 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)
- 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.
- 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.
- 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.
- 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.
- 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)
- 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.
- Nettoyage sans risque : rm -rf ~/Library/Developer/Xcode/DerivedData ; supprimez les runtimes de simulateur inutilisés avec xcrun simctl runtime delete.
- Les snapshots locaux APFS occupent aussi de l'espace : consultez-les avec tmutil listlocalsnapshots /, supprimez les anciens avec tmutil deletelocalsnapshots.
- Pour les machines CI, ajoutez une étape de nettoyage régulier dans le pipeline plutôt que d'attendre la saturation.
- 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.
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.
| 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.
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