Manuel d’assistance technique

De la première connexion au diagnostic, mettez votre Mac dans le cloud en service étape par étape

Voici une procédure directement applicable : vérifiez d’abord la commande et la région du nœud, établissez ensuite la connexion à distance, configurez les outils de développement et l’intégration continue, puis collectez les journaux selon les symptômes avant d’envoyer un ticket.

Ouvrir la console pour envoyer un ticket Voir les moyens de contacter l’assistance
Régions des nœuds
Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong
Fonctionnement du service
Fonctionnement normal 365 jours par an
Canal de traitement
Ticket depuis la console ou e-mail d’assistance
Trouvez le bon parcours

Six types de problèmes, six parcours de résolution optimisés

Si le problème relève de plusieurs catégories, commencez par vérifier les informations de base dans « Première connexion », puis passez à « Dépannage ». L’état réel du compte, de la commande et du nœud est celui renvoyé par la console.

Première connexion

Ne commencez pas par vous reconnecter en boucle : effectuez d’abord cinq vérifications de base

Lors de la première utilisation, les problèmes les plus fréquents viennent d’une erreur de recopie des informations du nœud, de restrictions du réseau local ou de paramètres d’affichage inadaptés. Effectuer les vérifications dans l’ordre évite de confondre un problème d’environnement avec un problème de nœud.

  1. 01

    Consulter les informations de la commande dans la console

    Vérifiez que le numéro de commande, le modèle, la région du nœud, l’adresse de connexion, le nom d’utilisateur et les identifiants d’accès correspondent à la même commande. N’utilisez pas d’ancienne capture de commande ni d’informations historiques issues d’une conversation. Les identifiants doivent uniquement être conservés dans un gestionnaire de mots de passe contrôlé.

    Critère de réussite : le modèle et la région correspondent à la commande actuelle
  2. 02

    Établir la connexion au bureau à distance

    Utilisez un client de bureau à distance prenant en charge l’interface graphique macOS, puis saisissez exactement l’adresse de connexion et le nom d’utilisateur. En cas d’échec, basculez une fois sur un autre réseau local afin d’écarter l’influence d’un proxy d’entreprise, d’un pare-feu de sortie ou des règles d’un réseau public.

    Critère de réussite : l’interface graphique macOS est visible et le bureau est utilisable
  3. 03

    Appliquer les réglages de sécurité de base

    Après la première ouverture de session, changez le mot de passe de connexion système et vérifiez le délai de verrouillage de l’écran. Assurez-vous que les clés privées du projet, les identifiants de signature et les jetons d’accès ne sont pas écrits dans des scripts partagés, l’historique des commandes ou un dépôt public. Ne transmettez jamais de mot de passe ni de clé privée au personnel d’assistance.

    Critère de réussite : les identifiants d’accès ont été changés et sont conservés en sécurité par l’équipe
  4. 04

    Ajuster la résolution et la qualité d’image

    Choisissez le facteur d’échelle adapté à votre écran local. En cas d’instabilité réseau, réduisez d’abord la qualité d’image et la résolution avant d’évaluer la réponse du nœud ; le retard de la souris et une image floue ne signifient pas nécessairement une baisse des performances de compilation ou du disque.

    Critère de réussite : le texte est net et la saisie ainsi que le déplacement des fenêtres répondent de manière stable
  5. 05

    Effectuer les vérifications de première ouverture de session

    Ouvrez le Terminal pour vérifier l’heure système, l’espace disque disponible, la résolution DNS et le chemin des outils en ligne de commande Xcode. Créez ensuite un répertoire temporaire et effectuez des tests d’écriture, de lecture et de suppression afin de confirmer que l’utilisateur actuel dispose des droits requis sur le répertoire du projet.

    Critère de réussite : l’heure, le disque, le réseau et les droits des répertoires sont corrects
Environnement de développement

Commencez par figer les versions et les répertoires, puis installez les dépendances du projet

Le Mac dans le cloud est une machine physique dédiée, et non une machine virtuelle. L’équipe doit néanmoins décrire la configuration dans une checklist reproductible afin d’éviter l’accumulation de modifications manuelles impossibles à restaurer.

Xcode

Figer la version de la chaîne d’outils requise par le projet

Lisez d’abord les contraintes de version indiquées dans la documentation du projet et la configuration CI, puis choisissez la version correspondante de Xcode. Après le changement, vérifiez également le chemin du compilateur, la liste des SDK et les outils en ligne de commande afin d’éviter un décalage entre la version de l’interface graphique et le chemin réellement utilisé dans le Terminal.

xcode-select -p
xcodebuild -version
xcrun --show-sdk-path

Critère : la version majeure de Xcode, le SDK et les chemins d’outils affichés en développement local et en intégration continue sont identiques.

Homebrew

Gérer les dépendances reproductibles avec un Brewfile

Ne vous fiez pas à votre mémoire pour conserver la liste des outils installés. Exportez d’abord un Brewfile depuis l’environnement existant, supprimez les paquets inutiles, puis installez les dépendances sur le Mac dans le cloud selon cette liste. Les jetons d’accès aux sources privées doivent être injectés via des variables d’environnement contrôlées.

brew bundle dump --force
brew bundle check
brew bundle install

Critère : le Brewfile peut être exécuté dans un répertoire propre sans exiger l’écriture de jetons sensibles dans le dépôt.

Git

Séparer l’identité du dépôt des autorisations du projet

Vérifiez le nom d’utilisateur, l’adresse e-mail de commit, la branche par défaut et les règles de fin de ligne. Si plusieurs projets utilisent des autorisations de dépôt différentes, configurez séparément les fichiers de clés et les alias d’hôte afin qu’un identifiant à privilèges élevés ne couvre pas toutes les tâches de build.

git config --global --list
git remote -v
ssh -T git@your-git-host

Critère : les opérations de récupération, de commit et d’accès aux sous-modules utilisent chacune l’identité prévue et les journaux n’affichent aucun jeton.

Signature et ligne de commande

Conserver les éléments sensibles en dehors du processus de build

Les certificats, clés privées et identifiants de signature doivent être importés via un processus sécurisé approuvé par l’équipe, avec un périmètre d’accès minimal par projet. Les outils Node, Ruby, Python et CocoaPods doivent utiliser des versions figées, consignées dans des fichiers de version du dépôt.

node --version
ruby --version
python3 --version
pod --version

Critère : une nouvelle session peut restaurer l’environnement à partir des fichiers de version et les journaux de build ne contiennent aucun identifiant.

Intégration CI/CD

Faire du Mac dans le cloud un nœud de build permanent et traçable

Lors de l’intégration de GitLab CI Runner, définissez d’abord le rôle du nœud, puis enregistrez l’exécuteur. Un nœud peut prendre en charge plusieurs files, mais les tâches de signature à privilèges élevés et les compilations ordinaires doivent utiliser des tags, des répertoires et des périmètres d’identifiants distincts.

Enregistrement

Installer et enregistrer GitLab CI Runner

Effectuez l’installation avec les informations d’enregistrement fournies par le projet ou l’équipe. Attribuez au nœud des tags décrivant l’architecture, la version de Xcode et le type de tâche, et désactivez l’exécution des tâches sans tag afin d’éviter qu’un pipeline arbitraire n’utilise le nœud de build.

  • Consigner le nom du Runner et le projet associé
  • Les tags incluent la chaîne d’outils et le type de tâche
  • Vérifier les droits du répertoire de l’utilisateur d’exécution
Exécution permanente

Gérer les tâches de build permanentes

Exécutez le Runner comme une tâche d’arrière-plan contrôlée et vérifiez sa reprise après redémarrage. Ne laissez pas les processus de build suspendus dans une session de terminal personnelle ; une déconnexion ne doit pas interrompre une compilation ou un test en cours.

  • Vérifier le propriétaire du processus et le mode de démarrage
  • Limiter le nombre de tâches exécutées simultanément
  • Définir une règle d’arrêt pour les tâches dépassant le délai
Cache

Figer le répertoire du cache et ses limites de nettoyage

Séparez le cache des dépendances, DerivedData, les archives et les artefacts finaux. Le cache peut être réutilisé, les archives doivent être suivies et les fichiers temporaires doivent être nettoyés par pipeline. En cas de croissance anormale du disque, localisez d’abord le répertoire au lieu de supprimer directement des données inconnues.

  • Consigner séparément les chemins du cache et des artefacts
  • Définir un répertoire indépendant par projet
  • Vérifier régulièrement l’espace disque et l’origine de sa consommation
Isolation

Isoler les identifiants de signature et les autorisations du dépôt

Injectez par projet les identifiants dotés du niveau de privilège minimal et limitez l’exécution des tâches de signature aux branches protégées. Les journaux doivent uniquement indiquer si le chargement des identifiants a réussi, sans afficher de mot de passe, clé privée, jeton ou contenu de signature.

  • Protéger les variables sensibles et limiter les branches
  • Utiliser des tags distincts pour les compilations ordinaires et les tâches de signature
  • Supprimer les fichiers temporaires à la fin de la tâche
Validation de l’intégration

Valider avec un pipeline minimal plutôt que migrer immédiatement toutes les tâches

  1. Récupérez un dépôt de test sans données sensibles.
  2. Affichez les versions de Xcode, du SDK et des outils de dépendances.
  3. Effectuez une compilation sans signature et enregistrez l’artefact.
  4. Vérifiez le cache, les journaux et le répertoire temporaire après la fin de la tâche.
Disponibilité du service

Évaluer l’état du service avec des indicateurs cohérents, sans tirer de conclusion d’une seule fluctuation réseau

Les nœuds Mac dans le cloud MacMLab fonctionnent normalement 365 jours par an. La qualité de connexion dépend également du réseau local de l’utilisateur, des règles de sortie, des paramètres du bureau à distance et de la charge des tâches ; consignez séparément ces facteurs et l’état du nœud lors du diagnostic.

Indicateur de disponibilité du service
99.9%
Période d’observation de l’état
90jours

Après confirmation que la commande remplit les conditions applicables et que le problème relève du service de la plateforme, l’indemnisation sera traitée conformément aux conditions de service et aux enregistrements de la commande concernée.

Barre d’état quotidienne des 90 derniers jours Les relevés quotidiens servent à évaluer la continuité ; l’état actuel et les informations de commande sont ceux renvoyés par la console.
Enregistrement du fonctionnement normal Des relevés les plus anciens aux plus récents
Arbre de décision du dépannage

Partez du symptôme et ne modifiez qu’une variable à la fois

Notez d’abord l’heure de l’incident et l’erreur originale, puis effectuez les vérifications. Ne réinstallez pas les outils, ne changez pas de réseau et ne nettoyez pas les répertoires simultanément : même si le problème disparaît, sa cause resterait impossible à confirmer.

Point de départ

Le nœud peut-il établir une connexion à distance ?

Vérifiez d’abord dans la console l’état de la commande, la région du nœud et les informations de connexion, puis choisissez la branche la plus proche du symptôme observé.

Connexion impossible

L’adresse ne répond pas ou les identifiants sont refusés

  1. Vérifiez que les informations de connexion proviennent de la commande actuelle.
  2. Basculez sur un autre réseau local et suspendez le proxy avant de refaire le test.
  3. Consignez le message d’erreur original du client et l’heure de l’incident.

À fournir :numéro de commande, région du nœud, type de réseau local, capture de l’erreur et nom du client.

Réponse ralentie

Affichage retardé, saisie lente ou tâche ralentie

  1. Réduisez la résolution et la qualité d’image du bureau à distance.
  2. Distinguez le retard d’affichage du bureau de la durée d’exécution des commandes dans le Terminal.
  3. Vérifiez le CPU, la mémoire, le disque et les tâches concurrentes.

À fournir :nom de l’opération lente, heures de début et de fin, nombre de tâches concurrentes et résumé désensibilisé des ressources.

Espace disque

Échec d’écriture ou baisse continue de l’espace disponible

  1. Vérifiez la taille des répertoires du projet, du cache, des archives et des journaux.
  2. Vérifiez si des tâches échouées ont laissé des fichiers temporaires.
  3. Nettoyez uniquement les caches reconstructibles et ne supprimez aucune donnée inconnue.

À fournir :espace disque disponible, répertoire ayant connu la plus forte croissance, tâches récentes et résultats désensibilisés avant et après le nettoyage.

Échec du build

Erreur du compilateur, des dépendances ou du processus de signature

  1. Consignez les versions de Xcode, du SDK et des outils de dépendances.
  2. Reproduisez la tâche de build minimale dans un répertoire propre.
  3. Comparez les noms des variables d’environnement locales et CI.

À fournir :commande en échec, code de sortie, première erreur pertinente et extrait désensibilisé des journaux associés.

Anomalie du nœud

Plusieurs opérations indépendantes échouent simultanément

  1. Écartez l’hypothèse d’un problème limité à un dépôt, un outil ou un client.
  2. Consignez les symptômes communs au Terminal et à l’interface graphique.
  3. Cessez les nouvelles tentatives répétées et préservez les informations disponibles.

À fournir :numéro de commande, région du nœud, chronologie de l’incident, périmètre impacté et dernière opération ayant fonctionné.

Contacter l’assistance

Pour les problèmes techniques, privilégiez les tickets ; les demandes générales peuvent être envoyées par e-mail

MacMLab propose uniquement deux canaux de contact : les tickets depuis la console et l’e-mail d’assistance. Pour toute question concernant une commande, un nœud ou la facturation, privilégiez le ticket afin de rattacher la demande à la commande et de suivre son traitement.

Parcours recommandé

Se connecter à la console et envoyer un ticket

Ce canal convient aux échecs de connexion, anomalies de nœud, environnements de build, états de facturation et questions relatives aux commandes. Commencez le ticket par la conclusion, puis listez les étapes de reproduction dans l’ordre chronologique.

Suggestion de titre Région du nœud + symptôme + heure de première apparition
Ordre du contenu Numéro de commande → périmètre impacté → étapes de reproduction → erreur originale → vérifications effectuées
Pièces jointes Téléversez uniquement des captures et résumés de journaux désensibilisés ; masquez les mots de passe, clés privées, jetons et identifiants de signature
Se connecter à la console et envoyer un ticket
Demande générale

Envoyer un e-mail à l’assistance

Ce canal convient aux demandes de configuration avant commande, aux besoins des entreprises, aux retours sur la documentation ou aux situations où la connexion à la console est impossible.

support@macminilab.com
Rappel concernant la confidentialité

L’assistance n’a pas besoin de vos informations secrètes

N’envoyez pas de mot de passe système, clé privée, jeton d’accès, identifiant de signature ni données métier complètes. Les journaux doivent conserver le contexte de l’erreur tout en remplaçant les adresses de dépôt, noms d’utilisateur et contenus des clés.

Consulter les informations sur le traitement des données

Préparez le numéro de commande et les étapes de reproduction avant de passer le relais à l’équipe d’assistance

Pour une commande existante, envoyez un ticket depuis la console. Si vous évaluez encore le modèle, la durée ou les quatre régions de nœuds, consultez d’abord les deux formules et la structure tarifaire.

Ouvrir la console pour envoyer un ticket Voir les formules de location