Manuel d’assistance technique

Faire passer votre Mac cloud de la connexion à un fonctionnement stable

Suivez l’ordre réel des opérations : vérification des identifiants, connexion au bureau distant VNC, migration de l’environnement et diagnostic des builds. Chaque étape fournit un résultat à contrôler et la suite à donner.

Se connecter au portail pour envoyer un ticket Louer un Mac cloud maintenant
Pour
Mac mini physique dédié
Livraison standard
Environ 4 minutes
Assistance
Ticket dans le portail ou e-mail
RUN / CONNECT-01

Checklist de première connexion

Actionnable
Identifiants récupérés Détails de l’instance dans le portail
01
Réseau accessible Adresse et port cible accessibles
02
Bureau ouvert La session VNC affiche l’interface graphique macOS
03
Résultat de la recette

Après vérification de la correspondance entre modèle, mémoire, stockage et nœud choisi, synchronisez le projet et le cache de build.

Accéder par problème

Six thèmes d’aide pour trouver directement la bonne procédure

Choisissez d’abord le thème correspondant le mieux à votre situation. Pour une connexion impossible, commencez par les identifiants et le réseau ; pour un build en échec, par l’environnement et les journaux ; pour les commandes et l’état du nœud, vérifiez les résultats en temps réel dans le portail.

Connexion à distance

Ouvrir macOS pour la première fois

Vérifiez l’adresse, le port, le nom d’utilisateur et le mot de passe temporaire, puis établissez la session VNC et appliquez les premiers réglages de sécurité.

Voir la procédure de connexion Compte et commande

Consulter les détails de la commande et du nœud

Vérifiez dans le portail le modèle, la durée de location, le nœud, le stockage supplémentaire, la facturation et l’état du service.

Ouvrir le portail Initialisation du système

Effectuer la recette de livraison

Remplacez les identifiants temporaires et contrôlez la version du système, l’espace disque, l’heure réseau et les droits administrateur.

Lancer la checklist de recette Environnement de développement

Reproduire l’environnement Xcode, CI et MLX

Installez la chaîne d’outils à partir de la liste des versions, isolez les dépendances et conservez les traces des builds et des inférences.

Voir le guide de l’environnement Réseau et stockage

Distinguer un problème de liaison d’un problème de capacité

Contrôlez la sortie réseau locale, le port cible, l’espace disque disponible, les tâches de synchronisation et la stratégie de transfert des fichiers volumineux.

Ouvrir l’arbre de diagnostic État du service

Vérifier le résultat d’exécution du nœud et de l’instance

Fiez-vous au retour en temps réel du portail et combinez l’état du nœud, la charge système et l’historique du service pour évaluer l’impact.

Voir les critères d’état
Guide de première connexion

Valider la connexion avant de migrer le projet

Avant de synchroniser un dépôt, un modèle ou des ressources multimédias, effectuez ces quatre contrôles. Vous pourrez ainsi traiter séparément les problèmes de livraison, de réseau et d’environnement du projet.

  1. 01

    Récupérer les identifiants actuels depuis le portail

    Ouvrez les détails de l’instance et vérifiez le numéro du nœud, le modèle, l’adresse VNC, le port, le nom d’utilisateur et le mot de passe temporaire. N’utilisez pas les informations d’anciennes demandes ni les captures historiques, et ne transmettez jamais les identifiants complets à un tiers.

    Le numéro du nœud correspond à la commande L’adresse et le port proviennent de l’instance actuelle Les identifiants ne contiennent pas d’espaces superflus
  2. 02

    Établir la connexion au bureau distant VNC

    Sur un réseau de confiance, ouvrez un client VNC compatible et connectez-vous avec l’adresse et le port indiqués dans le portail. En cas d’échec de négociation, vérifiez d’abord le réseau local, le proxy, le pare-feu et le port cible ; n’essayez pas en boucle un mot de passe erroné.

    Le réseau local accède normalement aux services externes Le proxy ne réécrit pas le port cible Le client utilise l’adresse actuelle
  3. 03

    Modifier les réglages de sécurité du compte

    Dès l’ouverture de l’interface graphique, remplacez le mot de passe de connexion temporaire et vérifiez que le verrouillage d’écran, la connexion automatique et l’accès distant respectent les règles de l’équipe. Pour un usage en équipe, créez un compte local traçable pour chaque membre autorisé.

    Le mot de passe temporaire a été remplacé La politique de verrouillage d’écran est confirmée La liste des membres autorisés est enregistrée
  4. 04

    Vérifier le système et la configuration de la commande

    Contrôlez la version de macOS, la puce M4, la mémoire, la capacité de stockage, l’espace disque disponible, l’heure système et la sortie réseau. SureVM M4 Core doit afficher M4, 16GB, 256GB ; SureVM M4 Plus doit afficher M4, 24GB, 512GB.

    La puce et la mémoire correspondent à l’offre choisie La capacité disque correspond aux options supplémentaires L’heure et l’état du réseau sont normaux
Parcours de migration

Migrer d’un Mac local vers un Mac cloud en trois étapes

L’objectif n’est pas de copier l’ancienne machine entière, mais de reconstruire un environnement vérifiable et réutilisable. Synchronisez d’abord les données nécessaires, reproduisez ensuite la chaîne d’outils, puis connectez les tâches automatisées.

01 Synchronisation des données

Migrer uniquement le nécessaire au projet

Synchronisez en priorité le dépôt de code, les modèles de configuration, les ressources indispensables et les caches validés comme réutilisables. Compressez ou transférez les gros fichiers par lots afin d’éviter de saturer le disque en une seule fois.

  • Récupérer le code et les sous-modules via le contrôle de version
  • Injecter séparément les variables sensibles sans les committer dans le dépôt
  • Documenter les chemins des ressources, modèles et artefacts de build
  • Après la synchronisation, vérifier le nombre et les sommes de contrôle des fichiers clés
Résultat de livraison Les données du projet sont lisibles et l’arborescence est clairement délimitée
02 Reproduction de la chaîne d’outils

Reconstruire l’environnement de développement selon la liste des versions

Commencez par confirmer les versions de Xcode, des outils en ligne de commande, des runtimes et des gestionnaires de paquets, puis installez les dépendances du projet. Ne copiez pas directement des répertoires globaux de l’ancienne machine dont l’origine n’est pas traçable.

  • Épingler les versions de Xcode et de Command Line Tools
  • Consigner les versions de Ruby, Node.js, Python et Java
  • Restaurer les dépendances CocoaPods, SwiftPM et npm depuis les fichiers de verrouillage
  • Effectuer un build propre et conserver le journal complet
Résultat de livraison Le même commit se build de manière stable sur le nouveau nœud
03 Intégration et validation CI

Intégrer le nœud à une file traçable

Attribuez à Runner un répertoire de travail dédié et les droits strictement nécessaires, définissez une stratégie de nettoyage des caches, puis utilisez une branche de test pour valider la récupération, le build, l’archivage et le retour des journaux.

  • Limiter les dépôts et comptes d’exécution accessibles à Runner
  • Séparer les répertoires de cache et d’artefacts de build
  • Vérifier que les tâches en échec renvoient le code de sortie et les journaux
  • Consigner le numéro du nœud, le numéro de tâche et le hash du commit
Résultat de livraison Les tâches automatisées sont reproductibles, traçables et faciles à transmettre
Xcode et CI

En cas d’échec du build, suivre la chaîne de preuves

Ne commencez pas par vider tous les caches ou réinstaller tous les outils. Conservez d’abord le journal d’échec, puis réduisez progressivement le périmètre en examinant les certificats, la signature, le Keychain, les droits de Runner, le cache et le message d’erreur précis.

Chaîne de signature

Certificats, profils de provisionnement et Keychain

  1. Confirmer l’usage et la validité du certificat

    Vérifiez le type de certificat utilisé par la cible, la configuration de l’équipe et la période de validité afin de ne pas mélanger les environnements de développement et de production.

  2. Vérifier la source des réglages de signature

    Contrôlez que la configuration du projet, les paramètres de build et les variables d’environnement CI pointent vers la même stratégie de signature.

  3. Confirmer l’accès de la tâche au Keychain

    La connexion interactive ne garantit pas l’accès de Runner en arrière-plan. Vérifiez le déverrouillage et les droits de lecture avec le compte d’exécution de Runner.

Environnement d’exécution

Droits de Runner, caches et journaux

  1. Confirmer le compte d’exécution réel de Runner

    Vérifiez le répertoire de travail, le Shell, le PATH et les droits de lecture-écriture ; ne vous contentez pas d’un contrôle dans le terminal interactif du bureau distant.

  2. Isoler les caches de dépendances et les données dérivées

    Définissez des répertoires clairs pour CocoaPods, SwiftPM, npm et DerivedData, puis nettoyez d’abord uniquement le cache concerné.

  3. Conserver le premier journal d’échec complet

    Notez le numéro de tâche, le hash du commit, la version de Xcode, le code de sortie et la première erreur ; n’envoyez pas seulement les dernières lignes du résumé.

Ordre d’analyse des journaux

Trouver le premier échec avant les erreurs en cascade

La fin du journal de build contient souvent de nombreux échecs secondaires. Commencez par le premier code de sortie non nul, la première erreur de signature ou la première erreur de résolution de dépendance, puis utilisez l’heure de début de la tâche pour identifier la cause réelle.

01 Contexte de la tâche

Numéro du nœud, numéro de tâche, hash du commit, branche.

02 Contexte de l’environnement

Versions de macOS, Xcode, des runtimes et des dépendances.

03 Contexte de l’échec

Première erreur, code de sortie, commande concernée et heure.

MLX et environnement de développement

Rendre l’environnement expérimental reproductible, pas seulement utilisable pendant la session

Gérez séparément l’environnement Python, les fichiers de modèles, les paramètres et les résultats. Vous maîtriserez ainsi l’espace disque et pourrez comparer rapidement les écarts après une mise à jour des dépendances.

Fiche d’exécution de l’environnement

Répertoires recommandés et périmètre des enregistrements

ENV
Isoler l’environnement Python

Utilisez un environnement virtuel distinct par projet, épinglez la version de Python et versionnez la liste des dépendances avec le projet.

DEP
Installation des dépendances

Installez les dépendances depuis le fichier verrouillé et consignez les versions de MLX et des bibliothèques clés ; avant toute mise à niveau, copiez l’inventaire de l’environnement et les résultats de référence.

MODEL
Gestion des fichiers de modèles

Séparez les modèles, les versions quantifiées et les répertoires de téléchargement temporaires. Notez leur source, leur somme de contrôle et leur occupation disque afin d’éviter les doublons.

RUN
Conserver les résultats d’exécution

Pour chaque expérience, enregistrez le hash du commit, les paramètres, les versions des dépendances, le résumé des entrées, la durée et le chemin de sortie, sans consigner de données sensibles brutes.

Avant de commencer

Vérifier le budget disque

Les fichiers de modèles, environnements virtuels, caches et sorties occupent l’espace simultanément. Vérifiez la capacité disponible avant le téléchargement et gardez une marge pour les fichiers intermédiaires.

  • Ne conserver que les versions nécessaires dans le répertoire des modèles
  • Définir une période de nettoyage claire pour les caches
  • Supprimer les fichiers intermédiaires après archivage des résultats
Après une modification

Valider avec un exemple minimal

Après toute modification de dépendance ou de modèle, exécutez d’abord un petit exemple à entrée fixe. Comparez le code de sortie, la structure des résultats et l’utilisation des ressources avant de relancer la tâche complète.

  • Conserver les inventaires d’environnement avant et après modification
  • Noter la commande en échec et la première erreur
  • Vérifier que le chemin de sortie est accessible en écriture et dispose de suffisamment d’espace
Arbre de diagnostic de connexion

Éliminer les causes étape par étape, des identifiants à l’état du nœud

Chaque niveau doit répondre à une seule question. Ne passez pas au suivant et ne réinstallez pas de logiciel avant d’avoir validé le précédent : vous limiterez les changements inutiles et conserverez des éléments clairs pour le ticket.

01
Identifiants

L’adresse, le port, le nom d’utilisateur et le mot de passe proviennent-ils de l’instance actuelle ?

En cas d’échec

Rouvrez les détails de l’instance dans le portail, recopiez manuellement les informations de connexion actuelles et vérifiez les espaces en début et fin ainsi que les anciennes données du client.

02
Réseau

Le réseau local atteint-il l’adresse et le port cibles ?

En cas d’échec

Désactivez temporairement le proxy qui réécrit le trafic, vérifiez la politique de sortie de l’entreprise et faites un test croisé avec un autre réseau de confiance.

03
Service de bureau distant

Le réseau est-il accessible, mais la session VNC échoue-t-elle pendant la négociation ?

En cas d’échec

Notez le nom et la version du client, le message d’erreur exact et l’heure ; évitez de renvoyer plusieurs fois des identifiants erronés.

04
Charge système

La connexion est établie mais l’affichage est lent : une tâche fortement chargée monopolise-t-elle les ressources ?

À vérifier

Consultez le CPU, la mémoire, l’espace disque disponible et les builds ou inférences en cours. Suspendez d’abord les files non essentielles, puis retestez.

05
État du nœud

Le portail renvoie-t-il l’état normal de l’instance actuelle ?

En cas d’état anormal

Ne redémarrez pas les tâches à répétition. Notez le numéro du nœud, l’état affiché dans le portail, l’heure et les résultats des contrôles précédents, puis envoyez un ticket.

Critères d’état du service

Le résultat en temps réel du portail fait foi

Tous les nœuds sont conçus pour fonctionner normalement 365 jours par an. Si l’état de l’instance, le résultat de connexion et vos contrôles locaux divergent, transmettez au support le nœud concerné et la période précise.

Commencer par noter
Numéro du nœud et heure de l’incident
Puis comparer
État du portail et comportement local
Enfin envoyer
Journaux anonymisés et étapes de reproduction
Envoyer une demande d’assistance

Donner au support les moyens de reproduire directement le problème

Un ticket complet précise l’objet, l’heure, les actions et le résultat. Anonymisez d’abord dans les journaux les adresses de dépôts, jetons, clés privées, données personnelles et informations métier.

TICKET / REQUIRED

Le ticket doit contenir cinq éléments

Envoyer après anonymisation
NODE
Numéro du nœud et région

Indiquez le numéro du nœud affiché dans le portail et précisez : Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong ou côte ouest des États-Unis.

MODEL
Modèle et configuration

Indiquez SureVM M4 Core ou SureVM M4 Plus, ainsi que l’utilisation éventuelle d’un stockage supplémentaire ou d’une interconnexion Thunderbolt 5.

TIME
Heure de l’incident et fuseau horaire

Indiquez la première occurrence, la dernière reproduction et votre fuseau horaire ; évitez les formulations vagues comme « à l’instant » ou « hier environ ».

STEPS
Étapes minimales de reproduction

En partant d’un état normal, décrivez dans l’ordre les actions, les conditions d’entrée, le résultat attendu et le résultat obtenu.

LOG
Journal anonymisé et message d’erreur exact

Conservez l’heure, le code de sortie et le contexte de l’erreur ; supprimez les mots de passe, jetons d’accès, clés privées, identifiants de paiement complets et données métier sensibles.

Utilisateurs ayant déjà commandé

Envoyer un ticket de nœud depuis le portail

Le ticket du portail peut être associé à l’instance, à la commande et à l’état du nœud. Il convient aux problèmes de connexion, de système, de facturation et aux problèmes techniques persistants.

Se connecter et envoyer un ticket
Problème de connexion ou question avant-vente

Envoyer un e-mail au support

Utilisez une adresse e-mail capable de recevoir une réponse et envoyez un résumé du problème. L’unique adresse d’assistance externe est support@surevm.com ; n’envoyez jamais de mot de passe de compte ni de clé privée par e-mail.

support@surevm.com
Étape suivante

Vous avez un problème ? Envoyez les éléments ; besoin d’un nœud ? Configurez-le directement

Le portail sert à gérer les instances et les tickets ; la page de commande permet de choisir entre deux configurations M4, la durée de location et cinq nœuds disponibles.

Ouvrir le portail Louer un Mac cloud maintenant