Vérifiez d’abord l’appareil, la région et les autorisations d’accès. Établissez ensuite la connexion SSH et contrôlez l’environnement de build. Cette checklist vous accompagne lors d’une première configuration comme en cas de problème. Utilisez les coordonnées, le nom d’utilisateur et la clé indiqués dans votre commande.
Vous avez déjà passé commande ? Ouvrez-la dans la console, puis suivez les vérifications dans l’ordre indiqué à droite.
Vérifiez avant de connecter
Les exemples publics ne contiennent aucune adresse réelle, clé privée ni aucun jeton d’accès. Fiez-vous aux informations affichées dans la console.
Consultez chaque élément dans les détails de la commande. Ne reprenez pas d’anciennes notes ou conversations, car les informations de connexion peuvent avoir changé. Si vous n’avez pas encore commandé, consultez d’abord la page Modèles et tarifspour comparer les configurations et durées de location disponibles.
Vérifiez le Mac, le modèle et l’identifiant d’instance associés à la commande. Si vous gérez plusieurs appareils, identifiez d’abord celui sur lequel vous allez intervenir afin d’éviter d’y transférer les fichiers du projet par erreur.
Vérifiez la région choisie et récupérez l’adresse de connexion, le port et le nom d’utilisateur dans les informations de gestion de l’appareil. N’utilisez pas l’adresse de démonstration de cette page pour vous connecter.
Vérifiez que le compte utilisé peut consulter la commande et ses informations de connexion. Conservez la clé privée dans un environnement local sécurisé ; ne l’envoyez pas dans un ticket, un dépôt ou sur une page publique.
Ne transmettez jamais d’identifiants sensibles.Pour diagnostiquer un problème, vous pouvez fournir des messages d’erreur expurgés de toute donnée sensible. N’envoyez ni clé privée, ni jeton complet, ni contenu de certificat, ni journaux bruts contenant des données personnelles.
Récupérez les paramètres réels de votre commande, puis préparez votre clé locale et vérifiez l’identité de l’hôte lors de la première connexion. La connectivité réseau, l’autorisation du compte et l’identité de l’hôte sont trois points à contrôler séparément. Ne vous contentez pas de voir apparaître une invite de connexion.
Connectez-vous à la console, ouvrez la commande concernée et notez l’adresse, le port, le nom d’utilisateur et les consignes fournis pour l’appareil. Si les informations de connexion ne sont pas encore disponibles, vérifiez l’état de la commande au lieu de deviner l’adresse.
Vérifiez les droits d’accès au fichier de clé privée sur votre machine, puis configurez la clé publique correspondante comme indiqué dans la commande. Prévoyez des identifiants à accès limité pour la CI ; ne copiez pas directement la clé privée de votre poste de développement dans le dépôt de build.
Lors de la première connexion, comparez l’empreinte de l’hôte aux informations fiables de l’appareil. Si elle ne correspond pas ou change soudainement, interrompez la connexion et vérifiez l’appareil, l’adresse et le chemin d’accès sélectionnés. N’ignorez pas l’avertissement.
Les sorties ci-dessous illustrent uniquement l’ordre des vérifications. Elles ne correspondent pas à la version réelle d’un système, à un résultat de build ni à un projet configuré. L’adresse de démonstration 192.0.2.10 n’est pas l’adresse de connexion de votre commande. Remplacez-la par les informations fournies dans la console avant d’exécuter les commandes.
Vérifiez d’abord que vous accédez au bon appareil, puis contrôlez le chemin des outils de ligne de commande Xcode et lancez enfin votre tâche de build dans le répertoire du projet. Chaque échec peut être diagnostiqué séparément : inutile de déployer toute la chaîne CI d’un coup pour la tester.
$ ssh -i ~/.ssh/id_ed25519 operator@192.0.2.10
Sortie d’exemple : connexion à l’appareil cible établie, vérifiez son identité
$ xcodebuild -version
Sortie d’exemple : affiche la version de Xcode installée sur l’appareil
$ fastlane build
Sortie d’exemple : vérifie la configuration du projet, puis renvoie le résultat du buildLes commandes d’exemple ne contiennent aucun identifiant réel.fastlane build s’applique uniquement si la tâche correspondante est définie dans le projet. Utilisez les commandes prévues par la configuration du projet.
Une connexion réussie confirme uniquement l’accès à l’appareil, pas la compatibilité de l’environnement de développement avec votre projet. Effectuez les vérifications suivantes avant de configurer un runner ou de transférer de nombreux fichiers. Les versions du système et des outils dépendent de l’environnement réel de l’appareil loué.
Notez la version de macOS, la version actuelle de Xcode et le répertoire de développement indiqué par xcode-select -p Si votre projet requiert un SDK précis, vérifiez les versions disponibles avant de lancer le build.
À vérifier : version du système, version de Xcode et chemin des outils en ligne de commande.
Installez les dépendances à partir du fichier de verrouillage du dépôt. Vérifiez le gestionnaire de paquets, l’environnement d’exécution des scripts et les extensions requises par le projet. Gérez séparément l’installation des outils, la configuration du projet et les éléments de signature : un échec de build ne signifie pas forcément que l’appareil est en cause.
À vérifier : fichier de verrouillage, journaux d’installation, versions des dépendances.
Dans le répertoire du projet, commencez par lancer une commande de vérification ou de build reproductible. Notez la commande, son code de sortie et l’emplacement de la première erreur. Une fois le build manuel validé, intégrez la même tâche à la CI.
À vérifier : répertoire d’exécution, commande complète, première étape en échec.
La CI/CD doit permettre de réexécuter les commandes validées dans un environnement traçable, avec les mêmes dépendances et autorisations. L’enregistrement du runner et la configuration de l’exécuteur dépendent de votre système CI. Ne collez jamais de jeton d’enregistrement réel dans une configuration publique.
Enregistrez un runner pour l’appareil cible dans votre système CI et vérifiez qu’il reçoit bien les projets et les tâches prévus. Contrôlez l’utilisateur d’exécution, le répertoire de travail et la gestion des tâches concurrentes.
Stockez les clés d’accès et les éléments de signature dans le gestionnaire de secrets sécurisé de votre système CI. Ne les inscrivez ni dans le dépôt, ni dans la sortie des scripts de build, ni dans le cache. Accordez uniquement les autorisations nécessaires à la tâche.
Définissez les chemins du cache des dépendances et ses conditions de nettoyage. Enregistrez les artefacts de build à l’emplacement choisi par votre équipe. Si une erreur est impossible à reproduire, relancez d’abord le build sans l’ancien cache pour comparer.
À la fin de la tâche, vérifiez les fichiers temporaires, les processus en arrière-plan et l’état de la session. Avant de transférer l’appareil ou de modifier les autorisations, révoquez les accès devenus inutiles et vérifiez qu’aucun identifiant ne reste dans le répertoire de travail.
Notez à quelle étape le problème survient et conservez la commande correspondante, son code de sortie et les journaux expurgés de toute donnée sensible. N’envoyez pas seulement une capture d’écran finale indiquant « Échec » : la première erreur est souvent plus utile que le résumé de la dernière ligne.
Vérifiez d’abord la commande et l’appareil cible, puis l’adresse, le port et l’accès depuis votre réseau local. Contrôlez ensuite le nom d’utilisateur, les droits de la clé et le message concernant l’identité de l’hôte. Distinguez les délais d’attente des refus d’accès : dans le premier cas, vérifiez le chemin réseau ; dans le second, les autorisations.
Vérifiez la cohérence entre la configuration de signature du projet, la cible de build et l’utilisateur exécutant la tâche CI. Ne collez aucun certificat ni aucune clé privée dans votre demande d’assistance : indiquez plutôt la ligne d’erreur expurgée et l’étape de build qui l’a déclenchée.
Comparez les chemins Xcode, les versions des dépendances, les répertoires de travail et la provenance des variables d’environnement entre l’exécution manuelle et la tâche CI. Repérez la première erreur de compilation ou de script avant de décider s’il faut vider le cache et relancer le build.
Vérifiez l’espace disponible et distinguez les fichiers du projet, les artefacts de build, le cache des dépendances et les fichiers temporaires. Avant tout nettoyage, vérifiez à qui appartiennent les fichiers. Si votre charge de travail nécessite durablement plus d’espace, consultez les options de stockage supplémentaires sur la page des offreset vérifiez les options de stockage supplémentaires.
Pour contacter l’assistance, indiquez :le modèle d’appareil et la région associés à la commande, la date et l’heure du problème, les commandes exécutées, l’emplacement de la première erreur et les démarches déjà effectuées. Supprimez les jetons, certificats, clés privées et données personnelles avant l’envoi.
Pour un problème concernant une commande existante, connectez-vous à la console, vérifiez les informations de l’appareil et créez un ticket associé à cette commande. Pour choisir une offre ou poser une question avant de commander, consultez la checklist de préparation par e-mail sur la page Contact. N’indiquez jamais le mot de passe de votre compte ni une clé complète dans votre demande.
Choisissez parmi trois modèles de Mac à puce Apple Silicon, en location à la journée, à la semaine, au mois ou au trimestre. Vérifiez le modèle et la durée souhaités, puis récupérez vos informations de connexion dans la console après la commande.