PARCOURS D’ASSISTANCE
Cette page propose une procédure fixe, de la première connexion au diagnostic des builds et des performances. Vérifiez d’abord le réseau local, l’adresse cible, les informations d’authentification et l’état du nœud, puis examinez les outils et les ressources afin d’éviter les essais répétés et de permettre une reproduction plus rapide par l’assistance.
TROUVEZ LE PARCOURS
Saisissez un message d’erreur, un mode de connexion, une tâche système ou un état de nœud. La recherche porte uniquement sur la documentation visible de cette page et n’envoie pas votre saisie.
7 parcours d’assistance affichés
Vérifiez que le nœud est prêt, que les identifiants proviennent de la bonne source et que le réseau local est accessible. Contrôlez également la disposition du clavier et le fuseau horaire.
Vérification prévue : 3 à 5 min Problème de connexionIsolez successivement le réseau local, l’adresse cible, les informations d’authentification, l’état du nœud et les réglages du client.
Effectuez les 5 niveaux de vérification dans l’ordre Tâche de buildCommencez par figer les versions des outils, puis vérifiez les éléments de signature, le cache des dépendances, l’espace disque disponible et les journaux de tâche.
Conservez les commandes complètes et les horodatages Diagnostic des performancesAu moment de l’anomalie, relevez simultanément le CPU, la mémoire, le disque et le réseau. Évitez de fournir une seule capture instantanée.
Échantillonnage continu recommandé : 5 à 10 min Escalade du ticketClassez la demande par compte, nœud inaccessible, anomalie matérielle ou demande relative aux données, et joignez les preuves minimales correspondantes.
Pour les commandes existantes, utilisez un ticket depuis la console Évaluation de l’étatComparez plusieurs points de la même région, testez différents réseaux et consultez l’état dans la console afin de décrire précisément l’étendue de l’impact.
Déterminez d’abord l’étendue de l’impact, puis escaladez Préparation des éléments de preuveRassemblez l’identifiant du nœud, la période concernée, le message d’erreur exact, les étapes de reproduction et des journaux désensibilisés pour limiter les demandes complémentaires.
Ne transmettez ni mots de passe, ni clés privées, ni code source du projetEssayez de conserver uniquement les termes clés de l’erreur ou sélectionnez « Tout ». Si le problème concerne une commande existante, créez un ticket depuis la console avec le message d’erreur exact.
Ouvrir la console pour créer un ticketPREMIÈRE SESSION
Ne modifiez pas plusieurs paramètres de connexion à la fois. Notez le résultat de chaque étape afin d’identifier si le problème vient du poste local, du réseau, de l’authentification ou du nœud.
Dans la console, vérifiez que le nœud cible est indiqué comme prêt, puis contrôlez son identifiant, sa région et le modèle choisi. Tant que le nœud est en préparation, ne concluez pas à une panne de connexion à partir d’une erreur du client.
Critère de réussite : l’identifiant correspond à la commande et l’état autorise la connexion.Copiez l’adresse, le port et le nom d’utilisateur depuis la fiche du nœud actuel dans la console. N’utilisez pas d’ancien ticket, d’ancienne capture ou de données enregistrées pour un autre nœud. Lors du collage du mot de passe, vérifiez les espaces et les caractères pleine chasse.
Critère de réussite : l’adresse, le port et le nom d’utilisateur proviennent de la même fiche de nœud.Vérifiez d’abord l’accès HTTPS standard, puis testez séparément le réseau professionnel et un réseau de secours fiable. La sortie d’entreprise, le pare-feu ou le proxy peuvent bloquer certains ports : l’ouverture d’une page web ne garantit donc pas l’accessibilité de la connexion distante.
Critère de réussite : notez le réseau utilisé, le type de sortie et l’heure de l’échec.Après avoir ouvert l’interface graphique macOS, testez les lettres, les chiffres, les symboles ainsi que les touches Command et Option. Si les symboles ne correspondent pas, notez la disposition locale et celle sélectionnée à distance.
Critère de réussite : le terminal saisit correctement les guillemets, barres obliques et traits d’union des commandes.Indiquez systématiquement le fuseau horaire dans les journaux de tâche, les traces CI et les horaires des tickets. Lorsqu’une erreur intermittente survient, « 14:20 » sans fuseau ne peut pas être rapproché des événements du nœud ; utilisez une date et une heure complètes avec fuseau.
Critère de réussite : les heures locales, du nœud et de l’automatisation peuvent être converties entre elles.ARBRE DE DÉCISION
Un délai d’attente indique généralement le réseau ou l’adresse ; un échec d’authentification concerne plutôt le nom d’utilisateur, le mot de passe, la clé ou la configuration du client. Orientez-vous d’abord selon le type d’erreur, puis effectuez les cinq vérifications.
Désactivez les proxys temporaires qui modifient le routage, puis réessayez avec un réseau de secours fiable. Si le réseau professionnel échoue mais que le réseau de secours fonctionne, notez la stratégie de sortie et les ports concernés ; transmettez en priorité le problème à l’administrateur réseau local.
Condition pour continuer :Une tentative de connexion à la même cible a été effectuée sur au moins un réseau fiable.
Revenez dans la console et recopiez les informations de la cible ; ne réutilisez pas une adresse issue de l’historique des commandes. Pour le bureau à distance dans le navigateur, utilisez l’accès fourni par la console ; avec SSH, vérifiez que l’hôte, le port et le nom d’utilisateur figurent dans la même fiche de connexion.
Condition d’arrêt :L’adresse a changé ou les données proviennent d’un autre nœud ; mettez-les à jour et retestez.
Vérifiez la casse du nom d’utilisateur, les espaces autour du mot de passe, les permissions du fichier de clé et le fichier d’identité sélectionné. Lors de la première apparition de l’empreinte SSH, comparez-la aux informations de la console. En cas de changement inattendu, interrompez la connexion et demandez-en la raison via un ticket.
Éléments requis :Conservez le message d’erreur exact, mais masquez le mot de passe, le contenu de la clé et l’adresse d’accès complète.
Actualisez la fiche du nœud et vérifiez son état, son identifiant et la date de dernière modification. Si l’état est anormal, n’enchaînez pas les redémarrages ; notez l’état initial, les actions effectuées et l’heure de chacune afin de préserver les éléments du diagnostic.
Condition d’escalade :L’état du nœud est anormal, ou il est normal mais inaccessible depuis deux réseaux fiables.
Si la page du navigateur est blanche, utilisez la version stable actuelle, effacez les données de session du site et réessayez. En cas de clavier incorrect, réduisez la configuration à une seule disposition. Si la session SSH se coupe fréquemment, désactivez les extensions du terminal et établissez une session de comparaison avec des commandes de base.
Critère de réussite :Notez le nom et la version du client, le mode de connexion et les étapes reproductibles.
Indiquez en priorité le type de réseau, l’heure de l’échec, la région cible, les résultats comparés sur deux réseaux et l’état du nœud dans la console. Ne transmettez pas uniquement une capture sans heure ni identifiant de nœud.
Vérifiez le nom d’utilisateur du nœud actuel, le mode d’authentification et le fichier d’identité du client. Dans le ticket, indiquez uniquement le mode d’authentification et le message d’erreur ; n’envoyez ni mot de passe, ni clé privée, ni identifiant utilisable.
PIPELINE DE BUILD
Prenez comme point de départ la première erreur explicite du build, et non le résumé de la dernière ligne. Figez d’abord la chaîne d’outils, puis vérifiez la signature, les dépendances, le disque et les processus d’automatisation.
Notez la version de macOS, la version de Xcode, le chemin des outils en ligne de commande et la commande de build. L’interface graphique et l’automatisation peuvent appeler des chemins différents et produire des résultats différents sur un même nœud.
Distinguez l’absence de certificat, l’incompatibilité du profil, l’autorisation insuffisante et l’échec d’accès au trousseau. Pour le diagnostic, conservez le nom et la validité du certificat ainsi que le texte de l’erreur, mais masquez les fichiers de certificat, les mots de passe et les identifiants sensibles du projet.
Déterminez d’abord si l’échec est reproductible avec le fichier de verrouillage, puis nettoyez le cache dans un périmètre minimal. Supprimer toutes les dépendances et tous les caches de build à la fois augmente les variables et peut faire disparaître temporairement le problème initial.
L’archivage, la décompression des dépendances et les fichiers temporaires nécessitent de l’espace supplémentaire. La taille du répertoire du projet ne suffit pas : vérifiez aussi l’espace disponible, les répertoires temporaires, le cache de build et l’arrêt éventuel du processus d’automatisation par manque de ressources.
ÉCHANTILLONNAGE DES PERFORMANCES
Une seule capture du CPU ne permet pas d’expliquer l’attente disque, la pression mémoire ou les fluctuations réseau. Effectuez un échantillonnage continu de 5 à 10 minutes avant et après le problème, en indiquant le début et l’échec de la tâche.
| Indicateur | À relever au minimum | Phénomènes à surveiller | À comparer avec la tâche |
|---|---|---|---|
| CPU | Utilisation totale, processus principaux, heure de l’échantillon | Occupation prolongée par un processus, pic de charge, absence de baisse après la fin de la tâche | Indiquer le début de la compilation, de l’édition de liens, des tests ou de l’inférence |
| Mémoire | Mémoire utilisée, pression mémoire, espace d’échange | Pression croissante, échanges fréquents, processus arrêté par le système | Noter le nombre de tâches parallèles et la taille des entrées |
| Disque | Espace disponible, débit de lecture/écriture, attente d’E/S | Espace presque épuisé, attente marquée lors de la décompression ou de l’archivage | Distinguer le téléchargement des dépendances, le cache de compilation et l’écriture des artefacts |
| Réseau | Type de réseau local, latence aller-retour, pertes de paquets | Anomalie sur une seule sortie, interactions lentes malgré une tâche normale sur le nœud | Distinguer l’affichage distant, le téléchargement des dépendances et la récupération du code |
Commencez à relever la base avant la tâche et poursuivez au moins 1 minute après l’anomalie. Les seules données de l’instant critique ne permettent pas de déterminer si les ressources sont la cause ou la conséquence.
Avec le même projet, les mêmes dépendances et le même niveau de parallélisme, enregistrez une tâche normale. Comparez les étapes et les courbes de ressources, pas seulement la durée totale.
Si l’affichage distant saccade mais que la tâche sur le nœud garde une durée stable, vérifiez d’abord le réseau. Si la tâche elle-même ralentit, examinez le CPU, la mémoire et le disque.
ÉLÉMENTS MINIMAUX
Il n’est pas nécessaire d’envoyer l’intégralité du projet. Les champs ci-dessous suffisent généralement pour une première analyse ; l’assistance demandera les éléments manquants si besoin.
Identifiant et région du nœud, version de macOS, version de Xcode ou du client. Ne renseignez ni mot de passe, ni clé privée, ni identifiant d’accès complet.
Utilisez « date + heures, minutes et secondes + fuseau horaire » et indiquez la première apparition, la dernière apparition et la reproduction la plus récente.
Copiez un texte interrogeable, pas seulement une capture. Conservez le code d’erreur, l’étape en échec et le contexte des journaux avant et après la première erreur.
Partez d’un état connu comme fonctionnel et énumérez les actions, commandes, résultats attendus et résultats obtenus, dans l’ordre. Précisez la fréquence de reproduction.
Indiquez l’heure et le résultat des changements de réseau, mises à jour d’adresse, nettoyages du cache ou redémarrages de tâche afin d’éviter de répéter des actions qui écraseraient les éléments du diagnostic.
RÈGLES D’ESCALADE
Un ticket doit décrire un seul problème principal. Si l’accès au compte et une panne de nœud surviennent simultanément, créez deux dossiers afin d’éviter de mélanger leur état de traitement.
| Catégorie | Cas concerné | Éléments recommandés | Canal prioritaire |
|---|---|---|---|
| Problème de compte | Accès impossible à la console, informations de compte ou validation d’accès anormales | E-mail d’inscription, heure, message d’erreur de la page, version du navigateur | E-mail d’assistance |
| Nœud inaccessible | Le nœud autorise la connexion, mais le bureau distant dans le navigateur et SSH ne parviennent pas à établir de session | Identifiant du nœud, région, résultats de deux tests réseau, heure et message exact de l’erreur | Ticket dans la console |
| Anomalie matérielle | Redémarrages anormaux répétés, erreurs de stockage ou anomalies de ressources inexpliquées par une seule tâche | Identifiant du nœud, période des journaux système, tâche précédant l’anomalie, fréquence de reproduction | Ticket dans la console |
| Demande relative aux données | Libération du nœud, export de données ou demande relative aux droits de confidentialité | Identifiant de commande, périmètre de la demande, action souhaitée, informations nécessaires de vérification d’identité | Ticket dans la console |
L’état du nœud autorise la connexion, mais après des tests sur deux réseaux fiables, le bureau distant dans le navigateur et SSH restent inaccessibles. Fournissez l’identifiant et la région du nœud ainsi que l’heure de la dernière connexion réussie.
Le nœud est accessible, mais le build ou l’automatisation échoue systématiquement avec une chaîne d’outils figée. Fournissez la première erreur, la commande complète, le code de sortie et la procédure de reproduction minimale.
Le nœud est disponible, mais la question concerne le clavier, la résolution, le cache des dépendances ou l’optimisation du workflow. Décrivez la configuration actuelle, le résultat souhaité et les solutions déjà vérifiées.
CONTINUITÉ DU SERVICE
Tous les nœuds sont conçus pour fonctionner normalement 365 jours par an. En cas d’incident, distinguez selon l’étendue de l’impact une fluctuation réseau régionale, une panne isolée du nœud ou un problème local de connexion.
Plusieurs sources de connexion d’une même région présentent presque simultanément une hausse de la latence, des pertes de paquets ou des interruptions de session, tandis que les tâches du nœud peuvent continuer à s’exécuter.
Le réseau local et les autres services de la même région fonctionnent, mais le nœud cible a un état anormal, perd régulièrement la connexion ou présente une erreur système inexpliquée par la tâche de l’utilisateur.
Le nœud cible est accessible depuis un réseau de secours ou un autre client ; seul un accès professionnel, une configuration de navigateur ou un client SSH échoue.
« Le nœud SG-exemple est inaccessible via SSH depuis le 08/08/2026 à 14:20 +0800 ; les réseaux domestique et professionnel expirent, tandis que la console indique toujours que la connexion est autorisée. »
N’écrivez pas seulement « le serveur est en panne », « le réseau est lent » ou « la connexion se coupe parfois ». Sans nœud, horaire, source réseau et message d’erreur exact, l’étendue de l’impact ne peut pas être déterminée.
RÉPONSES RAPIDES
Vérifiez d’abord l’identifiant et l’état du nœud dans la console, puis recopiez l’adresse, le port et le nom d’utilisateur depuis la fiche du nœud actuel. Effectuez ensuite une comparaison avec un réseau de secours fiable. N’enchaînez pas plusieurs actions modifiant l’état du nœud avant d’avoir consigné son état.
Envoyez en priorité au moins 50 lignes avant et après la première erreur, la commande de build complète, le code de sortie, la version de Xcode et l’heure de l’incident. Désensibilisez les chemins de projet, adresses de dépôt et informations de signature, sans supprimer les codes d’erreur ni les horodatages.
Une capture ne représente qu’un instant et ne permet pas de savoir si l’évolution des ressources précède ou suit la tâche. Relevez pendant 5 à 10 minutes le CPU, la mémoire, le disque et le réseau, en indiquant le début, l’anomalie et la fin de la tâche.
Pour les commandes existantes et les demandes concernant les nœuds, le matériel ou les données, utilisez en priorité un ticket dans la console afin d’associer les enregistrements. Pour les problèmes de compte empêchant l’accès à la console, écrivez à support@macworker.com. Ce sont les deux seuls canaux de contact disponibles.
N’envoyez ni mot de passe, ni clé privée, ni données de paiement, ni adresse d’accès complète, ni code source du projet. Masquez les valeurs sensibles des journaux, mais conservez les noms de champs, versions, codes d’erreur, horodatages et ordre des appels.
PRÊT À ESCALADER
Associez la commande existante via un ticket dans la console et joignez les étapes minimales de reproduction ainsi que les journaux désensibilisés. Si vous n’avez pas encore loué de nœud, accédez au portail pour choisir une configuration de nœud physique dédié, une région et une durée.