Guide opérationnel

Passez d’un Mac cloud livré à un environnement prêt à l’emploi

Pas de théorie pour commencer : vérifiez votre commande et les informations de la machine, puis configurez les accès, Xcode, la CI/CD et l’inférence MLX. Chaque section précise les contrôles à effectuer, les critères de validation et les informations de diagnostic à conserver.

Louer un Mac cloud Guide d’accès à distance

Type de machine: Machine physique dédiée, pas une VM
Durée de mise en service: Environ 4 minutes
Disponibilité: Disponible toute l’année, 365 jours par an

Fiche de la machine Mise en service initiale

4 contrôles

Commande et machine Modèle, région, durée et options conformes

Vérifier

Identifiants d’accès À modifier dès la première connexion et à conserver en lieu sûr

Mettre à jour

Outils de développement Vérifier les versions de macOS, Xcode et des outils en ligne de commande

Valider

Réseau et répertoire de travail Vérifier la connectivité, l’espace disponible et les droits du répertoire

Prêt

Critères de validation Connexion, build et reproduction possibles

Parcourir par tâche

Six guides pour repérer votre blocage

Pour une première utilisation, suivez les étapes dans l’ordre. Si un environnement existant rencontre un problème, consultez directement la rubrique correspondante et conservez les sorties de commande, l’heure de l’incident et l’historique des dernières modifications.

Première utilisation

Vérifications de base en quatre minutes

Vérifiez la commande, récupérez les informations de la machine, mettez à jour les identifiants et contrôlez le système, le réseau et le stockage.

Voir la liste de mise en service

Environnement de développement

Définir une base stable pour Xcode et la signature

Vérifiez les versions, les certificats, les accès au trousseau et les outils en ligne de commande, puis lancez un premier build à archiver.

Vérifier l’environnement de développement

CI/CD

Un exécuteur nettoyable et traçable

Définissez le répertoire de travail, les limites du cache, le nombre maximal de tâches simultanées et les journaux d’échec pour éviter les interférences.

Connecter la file de builds

Inférence MLX

Créer un service d’inférence redémarrable

Isolez l’environnement et définissez le répertoire des modèles, les interfaces d’écoute, les tests de charge et les références mémoire.

Déployer le service d’inférence

Stockage et réseau

Évaluez votre espace de travail avant de choisir une extension

Distinguez code source, caches de dépendances, modèles, artefacts de build et fichiers temporaires pour évaluer l’extension SSD et le chaînage des appareils.

Planifier la capacité et le chaînage

Compte et facturation

Envoyer un ticket directement exploitable

Indiquez le numéro de commande, la région de la machine, la version du système, l’heure de l’incident, les étapes de reproduction et les journaux expurgés.

Préparer une demande d’assistance

Première utilisation

Liste de mise en service en quatre minutes

Le chronomètre démarre après la confirmation de la commande. La disponibilité effective est indiquée en temps réel dans la console. Si une étape manque d’informations, ne passez pas à la suivante.

01
Vérifier la commande Environ 45 s
Vérifiez que le modèle, la région de la machine, la durée de location et les options correspondent à votre projet. Configuration standard : M4, 16GB, 256GB ; configuration mémoire élevée : M4 Pro, 64GB, 2TB. En cas d’écart, arrêtez la procédure et ouvrez un ticket.
- Notez le numéro de commande et la région de la machine.
- Vérifiez les besoins d’extension de stockage et de chaînage Thunderbolt 5.
02
Récupérer les informations de la machine Environ 2 min
Attendez la fin de l’attribution automatique et des vérifications système, puis consultez l’adresse de la machine et les informations de connexion dans la console. Ne partagez pas ces informations dans un canal public et ne stockez pas d’identifiants en clair dans un dépôt de code.
- Vérifiez que l’adresse et la région correspondent à la commande.
- Enregistrez les informations initiales dans le gestionnaire d’identifiants approuvé par votre équipe.
03
Mettre à jour les identifiants d’accès Environ 1 min
Après la première connexion, modifiez immédiatement les identifiants et créez une clé distincte pour les tâches automatisées. Séparez les comptes interactifs des comptes d’exécution CI afin d’éviter d’accorder aux scripts des privilèges système inutiles.
- Modifiez le mot de passe initial et vérifiez que les nouveaux identifiants fonctionnent.
- Préparez une clé pour les connexions en ligne de commande et vérifiez l’empreinte de l’hôte.
04
Vérifier le système et le réseau Environ 15 s

Notez les versions de macOS et de Xcode, puis vérifiez la route par défaut, la résolution DNS, l’espace disque disponible et les droits d’écriture du répertoire de travail. Lancez ensuite un petit build ou une requête d’inférence pour vérifier que l’environnement produit un résultat vérifiable.

Voir toutes les étapes de connexion

Environnement de développement

Définissez une base stable pour Xcode et la signature

Des builds reproductibles exigent des versions précises, un trousseau accessible et des outils en ligne de commande cohérents. Ne vous contentez pas de vérifier que le projet s’ouvre dans l’interface graphique : validez aussi son fonctionnement en ligne de commande.

Ordre de configuration

01
Vérifier la version de Xcode
Notez le numéro de version complet et le numéro de build. Vérifiez que le SDK, les runtimes de simulateur et la version minimale du système requis par le projet sont disponibles.
02
Importer les certificats et profils de provisionnement
Importez uniquement les éléments nécessaires au projet en cours. Nommez-les en indiquant le projet et leur usage afin d’en retrouver facilement l’origine lors des changements d’équipe.
03
Vérifier les autorisations du trousseau
Vérifiez que la clé privée est lisible par le compte d’exécution cible. Pour les builds automatisés, effectuez d’abord un test de signature sans interaction afin que la file ne reste pas bloquée sur une demande d’autorisation.
04
Choisir les outils en ligne de commande
Vérifiez que la sélection pointe vers la version de Xcode attendue et consignez le résultat dans la documentation de l’environnement du projet. Après tout changement de version, vérifiez à nouveau les dépendances et la signature.
05
Valider le premier build
Commencez par supprimer les anciens artefacts, puis lancez les tests, l’archivage et la vérification de signature. Conservez la commande, le code de sortie, le chemin des journaux et la somme de contrôle de l’artefact final.

Intégration continue

Traitez l’exécuteur comme une ressource dédiée, pas comme un répertoire temporaire

Une machine physique dédiée fournit des ressources matérielles fixes, mais les tâches peuvent échouer à cause d’un cache pollué, d’une concurrence excessive ou de journaux insuffisants. Définissez les répertoires et les règles de nettoyage avant l’intégration.

Installer un exécuteur autohébergé

Créez un compte système et un répertoire de service dédiés à l’exécuteur, avec uniquement les droits nécessaires aux builds. Après l’enregistrement, lancez une petite tâche sans signature pour vérifier la file, le réseau et le code de sortie.

Critère de validation : reprise automatique des tâches après redémarrage

Organiser les répertoires de travail

Séparez le dépôt du code source, les caches de dépendances, les builds temporaires, les archives et les journaux à conserver. À la fin d’une tâche, ne nettoyez que le répertoire temporaire : ne supprimez pas les caches partagés nécessaires aux tâches suivantes.

Critère de validation : propriétaires des répertoires et règles de nettoyage définis

Limiter le nombre de tâches simultanées

Établissez d’abord une référence de mémoire, d’espace disque et de durée pour une seule tâche, puis augmentez progressivement la concurrence. Si des builds Xcode et des inférences MLX tournent en même temps, surveillez séparément les pics de mémoire et les écritures disque.

Critère de validation : aucune pagination ni saturation du disque en période de pointe

Conserver les éléments de diagnostic des échecs

Pour chaque tâche en échec, conservez au minimum son identifiant, la version du commit, la version de l’exécuteur, l’heure de début, le code de sortie, les journaux importants et le chemin des artefacts. Avant de téléverser les journaux, retirez les jetons et les éléments de signature.

Critère de validation : un autre membre de l’équipe peut reproduire le problème en autonomie

Règles de nettoyage du cache

Utilisez de préférence des clés de cache fondées sur le projet, la branche et la version des outils. Ne remplacez pas la gestion de capacité par une suppression périodique de tout le disque. Avant le nettoyage, vérifiez qu’aucun build ni archivage n’est en cours.

IA et MLX

Un service d’inférence doit pouvoir être testé, surveillé et rétabli

Commencez par faire fonctionner une seule requête, puis augmentez la longueur du contexte et le nombre de tâches simultanées. Séparez les modèles, l’environnement d’exécution et les journaux du service pour éviter qu’une mise à jour des dépendances n’endommage les fichiers du modèle.

Configuration du service MLX Commencer par une seule requête de référence

Apple Silicon

Isolation de l’environnement: Utilisez un environnement Python distinct pour chaque service, verrouillez les versions des dépendances et conservez la liste des paquets installés.
Répertoire des modèles: Séparez les fichiers de modèles du code source et consignez le nom du modèle, le format de quantification, la somme de contrôle et l’espace utilisé.
Interfaces d’écoute: Limitez l’écoute aux interfaces et adresses nécessaires à la tâche. N’exposez pas les points de terminaison de débogage à des réseaux non concernés.
Test de charge concurrent: Testez successivement 1, 2 puis 4 requêtes simultanées. Notez la latence avant le premier jeton, la durée totale, le taux d’échec et le pic de mémoire.
Surveillance de la mémoire: Distinguez la mémoire occupée en permanence par le modèle, la croissance liée au contexte et les caches de requêtes. Arrêtez la montée en charge avant d’atteindre la limite stable.
Stratégie de redémarrage: Consignez la commande de démarrage, le répertoire de travail, les variables d’environnement et le chemin des journaux dans la configuration du service. Vérifiez que le service peut redémarrer après une sortie inattendue.

Capacité et chaînage

Choisissez le stockage selon votre espace de travail, pas selon le nom du projet

Calculez d’abord l’espace maximal nécessaire au code source, aux dépendances, aux modèles, aux artefacts de build, aux journaux et aux fichiers temporaires, puis prévoyez une marge pour le nettoyage et le retour arrière. La capacité SSD de base dépend du modèle choisi.

ArmMesh M4

SSD de base de 256GB

Convient aux extractions de code, aux caches de dépendances courants, aux builds d’un seul projet et aux publications de courte durée. Pour les grands modèles, plusieurs runtimes Xcode ou de nombreuses vidéos, évaluez d’abord l’espace maximal requis.

ArmMesh M4 Pro

SSD de base de 2TB

Convient aux grands dépôts de modèles, aux caches de build conservés longtemps, aux projets parallèles et à l’export audio/vidéo. Une capacité fixe ne remplace pas une stratégie de nettoyage : définissez aussi la durée de conservation des journaux et des artefacts.

Tarifs des options de stockage et de chaînage Thunderbolt 5, facturés en dollars US
Option	Par jour	Par semaine	Par mois	Par trimestre	Quand choisir cette option
+1TB SSD	$2.4	$6.4	$11.9	$32.4	À utiliser lorsque les caches de dépendances, les archives de build ou les modèles de taille moyenne dépassent la capacité de base.
+2TB SSD	$4.8	$12.8	$23.8	$64.8	À utiliser pour les grands modèles, la conservation longue durée des artefacts ou les flux de travail audio/vidéo nécessitant un espace de travail plus important.
Chaînage Thunderbolt 5, par appareil	$1.2	$3.2	$5.9	$16	Avant de faire collaborer plusieurs appareils, définissez le découpage des tâches, la synchronisation des données, la reprise après échec et l’agrégation des résultats.

Cinq vérifications avant de chaîner plusieurs appareils

Les tâches peuvent-elles être réparties en unités indépendantes et relançables ?
Les données d’entrée ont-elles une source unique ? Plusieurs appareils risquent-ils de les modifier en même temps ?
Les versions des modèles, dépendances et outils peuvent-elles rester identiques ?
Les tâches d’un appareil défaillant peuvent-elles être transférées sans générer de doublons ?
Les artefacts de sortie ont-ils des règles communes de nommage, de vérification et de regroupement ?

Dépannage

Cernez le problème avant de modifier la configuration

Ne modifiez qu’un seul paramètre à la fois et consignez les résultats avant et après le changement. Réinstaller sans cesse, vider les caches à répétition ou modifier simultanément le réseau et la chaîne d’outils complique l’identification de la cause réelle.

Connexion impossible

Vérifiez le réseau local, puis l’état de la machine

Vérifiez que le réseau local fonctionne et qu’aucun proxy ni pare-feu ne bloque la connexion.
Vérifiez à nouveau l’adresse de la machine, le port et l’empreinte de l’hôte.
Vérifiez que les identifiants ont été mis à jour et qu’aucun espace ne s’est glissé lors de leur copie.
Vérifiez l’état de la machine dans la console, puis notez la version du client et le message d’erreur exact.

Performances anormales

Distinguez latence, débit et charge de la machine

Répétez les tests sur un réseau stable pour écarter les variations du Wi-Fi.
Comparez la latence interactive et la vitesse de transfert des fichiers ; ne les confondez pas.
Vérifiez si des builds, des synchronisations ou des tâches d’inférence utilisent les ressources.
Notez votre emplacement, la région de la machine, les plages horaires et les résultats de tests successifs.

Échec du build

Déterminez s’il s’agit d’un problème de code ou d’environnement

Figez la version du commit et relancez exactement la même commande de build.
Notez les versions de Xcode, du SDK, des dépendances et des outils en ligne de commande.
Vérifiez les éléments de signature, les autorisations du trousseau et celles du répertoire de travail.
Supprimez les artefacts temporaires du projet concerné, puis réessayez sans effacer tout le disque.

Espace disque insuffisant

Repérez ce qui occupe l’espace avant d’augmenter la capacité

Mesurez séparément l’espace utilisé par les modèles, les caches de dépendances, les archives, les journaux et les répertoires temporaires.
Recherchez les modèles en double, les anciennes archives ou les fichiers laissés par des tâches inachevées.
Supprimez, selon les règles de conservation, les éléments régénérables, puis mesurez à nouveau le pic d’utilisation.
Si le pic dépasse toujours la marge de sécurité, choisissez un SSD de +1TB ou +2TB.

Arrêt du processus d’inférence

Comparez le volume des requêtes et le pic de mémoire

Déterminez si l’arrêt survient au démarrage, au chargement du modèle ou pendant le traitement d’une requête.
Vérifiez si le format du modèle, la longueur du contexte ou le nombre de requêtes simultanées a changé.
Consultez l’utilisation de la mémoire et du disque ainsi que les journaux du service avant l’arrêt.
Rétablissez la référence avec une seule requête, puis augmentez la charge progressivement.

Identifiants invalides

Arrêtez les tentatives et identifiez l’origine du changement

Vérifiez si vous utilisez un compte interactif ou un compte d’automatisation.
Vérifiez si le mot de passe, la clé ou les membres autorisés ont récemment changé.
Supprimez les anciens identifiants des scripts et des caches, puis testez les nouveaux.
Si l’origine du changement reste incertaine, ouvrez un ticket dans la console.

Assistance

Incluez toutes les informations nécessaires au diagnostic dans votre ticket

Pour tout problème technique, ouvrez de préférence un ticket dans la console afin de le relier à votre commande et à votre machine. Si vous ne pouvez pas vous connecter à la console, écrivez à support@armmesh.com.

Six éléments à préparer avant l’envoi

01 Numéro de commande

Indiquez le numéro de commande concerné. Si plusieurs machines sont touchées, mentionnez-les séparément au lieu d’indiquer uniquement le nom de l’équipe.

02 Région de la machine

Précisez la région utilisée et indiquez si le problème concerne une seule machine ou plusieurs.

03 Version de macOS

Indiquez la version complète et le numéro de build. Pour un problème de build, ajoutez aussi les versions de Xcode et des outils en ligne de commande.

04 Heure de l’incident

Précisez le fuseau horaire, l’heure de la première occurrence et de la dernière occurrence, ainsi que la possibilité de reproduire le problème de façon régulière.

05 Étapes de reproduction

En partant d’un état normal, décrivez les actions étape par étape, les entrées, le résultat attendu et le résultat obtenu.

06 Journaux expurgés

Conservez les horodatages, codes d’erreur et éléments de contexte. Supprimez les mots de passe, clés, jetons, éléments de signature et informations confidentielles du projet.

Étape suivante

Choisissez une machine physique, puis validez-la à l’aide de la liste de contrôle

Les deux modèles sont des machines physiques dédiées, pas des VM, disponibles à la location à la journée, à la semaine, au mois ou au trimestre. La disponibilité effective est indiquée en temps réel dans la console.

Louer un Mac cloud Voir les configurations et les tarifs