Les échecs de connexion, problèmes d’identifiants, changements de version Xcode, manque d’espace, accès réseau et questions de facturation suivent chacun leur propre parcours. Effectuez d’abord les six vérifications rapides ; si le problème persiste, ajoutez la commande, le nœud, l’heure et les étapes de reproduction au ticket depuis la console.
Chaque parcours commence par des informations actuellement vérifiables, sans devoir deviner la cause de la panne. Si plusieurs symptômes apparaissent, vérifiez en priorité l’état de la commande, l’alimentation de l’appareil et la chaîne de connexion.
Pour les délais d’attente, refus de connexion, interruptions de session ou impossibilité d’établir l’interface graphique. Vérifiez d’abord l’adresse du nœud, le port, la sortie réseau locale et le mode d’accès distant choisi.
Consulter le guide de connexionPour les échecs de connexion, les identifiants dont l’état est inconnu ou les informations de commande introuvables. N’essayez pas plusieurs fois d’anciens identifiants : vérifiez d’abord dans la console que la commande et les informations de connexion correspondent au même appareil.
Vérifier la commande et les identifiantsPour les versions incompatibles, échecs d’importation de certificats, erreurs de signature, interruptions Fastlane ou impossibilité d’exporter les artefacts. Conservez l’étape complète de l’erreur, mais supprimez les données sensibles avant l’envoi.
Dépanner l’environnement de buildDistinguez les fichiers du projet, caches de dépendances, archives de build, fichiers de modèles et sorties temporaires. Ne supprimez pas directement les répertoires inconnus : notez d’abord leur chemin, leur taille et la tâche associée.
Voir les points de contrôle de l’espaceVérifiez la sortie réseau locale, le port cible, la résolution DNS et les sources de dépendances du projet. Si le même nœud se comporte différemment selon le réseau, notez les résultats obtenus dans les deux environnements.
Vérifier la connexion et le réseauPréparez le numéro de commande, la durée de location choisie, le nœud et les options supplémentaires. Le paiement est accepté uniquement en USDT-TRC20 et par Visa / Mastercard / Amex (via Stripe), en dollars américains (USD).
Voir la commande et la facturationNotez les résultats dans l’ordre. Chaque vérification réduit le périmètre du diagnostic et évite de confondre réseau local, mode de connexion et état de l’appareil.
Vérifiez que la commande est toujours dans sa période de location active et que le numéro consulté correspond à l’appareil actuel. Si l’état de la page change, notez les actions effectuées avant et après ce changement.
Vérifiez le nœud de Singapour, du Japon (Tokyo), de Corée du Sud (Séoul) ou de Hong Kong, ainsi que l’adresse et le port renvoyés par la console. Ne déduisez pas l’adresse actuelle de l’historique des connexions.
Vérifiez que l’appareil peut accepter une connexion. Après un redémarrage ou une mise à jour système, notez l’heure de l’opération et attendez que la console renvoie l’état le plus récent de l’appareil.
Vérifiez que le réseau actuel autorise l’accès au port cible. Dans un environnement contrôlé, vous pouvez comparer avec un réseau fiable et noter si le même délai d’attente apparaît.
Distinguez ligne de commande, interface graphique, transfert de fichiers et tâches automatisées. Les ports, réglages du client et messages d’erreur diffèrent selon le mode utilisé.
Vérifiez que vous utilisez les informations de connexion les plus récentes de la commande actuelle. Ne collez jamais de mot de passe, clé ou identifiant d’accès complet dans une capture publique ou dans l’objet d’un e-mail.
« Échec du build » ne constitue pas un sujet de ticket suffisamment précis. Déterminez d’abord si l’échec survient lors de l’installation des dépendances, de la compilation, des tests, de la signature, de l’archivage ou de l’exportation des artefacts.
Notez la version actuelle, la version requise par le projet, le chemin des outils en ligne de commande et la tâche où la différence est apparue pour la première fois. Dans un environnement multiversion, vérifiez aussi le chemin réellement utilisé par l’automatisation.
Vérifiez l’objet importé, l’emplacement du trousseau, les autorisations d’accès et la validité du certificat. Le ticket doit uniquement contenir le nom anonymisé et le texte de l’erreur ; ne téléversez pas de clé privée de certificat.
Notez la cible, la configuration de build, l’étape de l’échec et les lignes d’erreur importantes. Décrivez séparément les problèmes de code du projet et ceux où l’environnement ne trouve pas les éléments de signature.
Indiquez le nom de la lane, le mode de déclenchement, l’étape d’arrêt, le résultat de la nouvelle tentative et l’emplacement des journaux. Si l’opération manuelle réussit mais l’automatisation échoue, fournissez les différences entre les deux parcours.
Vérifiez que l’archivage est terminé, que le répertoire d’exportation est accessible en écriture, que l’espace disque restant est suffisant et qu’aucune interruption ne s’est produite pendant le transfert des artefacts.
Un modèle qui ne se charge pas, une inférence interrompue ou une session déconnectée peuvent avoir des causes différentes. Observez simultanément l’environnement, l’emplacement des fichiers, l’évolution de la mémoire, le répertoire de sortie et le mode de maintien de la session.
Notez l’environnement Python, la version de MLX, la commande de lancement et le résultat de l’installation des dépendances. Si le même script fonctionnait auparavant, indiquez les changements récents de l’environnement ou du code.
Vérifiez la taille du modèle, son chemin réel, les copies en cache et le répertoire de sortie. En cas d’interruption du téléchargement, conservez l’état des fichiers temporaires afin d’éviter un nouveau téléchargement inutile.
Notez l’évolution de la mémoire avant le chargement, après le chargement du modèle et pendant l’exécution. Si la tâche est interrompue, indiquez la taille du lot, la taille du contexte et l’état des ressources juste avant l’arrêt.
Distinguez l’exécution de la tâche d’une interruption de la connexion locale. Utilisez une session récupérable, écrivez continuellement les journaux et fichiers de sortie, puis vérifiez l’état du processus après reconnexion.
La liste de la base de connaissances est automatiquement triée par date de publication et regroupée par mois. Les repères de date à gauche servent à accéder au mois, tandis que le contenu à droite affiche les articles correspondants ; les titres suivent le format « AAAA, mois M ».
Couvre la vérification de l’environnement MLX, la planification du stockage des modèles et la gestion des caches, du disque et des ports pour le développement conteneurisé sur Mac dans le cloud.
De la vérification de la connexion à la livraison des artefacts, découvrez le parcours complet du travail créatif à distance, des tunnels SSH et de l’automatisation Fastlane.
Découvrez comment nommer les appareils, attribuer les autorisations, définir une base d’environnement, suivre les actifs et transférer les nœuds lors de projets menés en parallèle.
Plus la description se rapproche d’un relevé reproductible, plus il est facile de déterminer s’il s’agit du nœud, de l’accès système, de l’environnement logiciel ou de la tâche du projet. Pour une commande existante, envoyez de préférence le ticket depuis la console afin de l’associer à la commande et à l’état de l’appareil.
Indiquez le numéro de commande et le nœud utilisé : Singapour, Japon (Tokyo), Corée du Sud (Séoul) ou Hong Kong.
Indiquez l’heure de la première apparition du problème, la dernière utilisation normale et la période des nouvelles tentatives.
Listez dans l’ordre les modes de connexion, commandes ou actions dans l’interface, et indiquez à quelle étape l’erreur apparaît.
Ajoutez le texte des erreurs importantes ou des captures anonymisées. Ne conservez que les zones nécessaires au diagnostic et n’affichez pas l’adresse complète ni les informations d’accès.
Les tickets, e-mails et captures ne doivent contenir ni mot de passe, ni clé, ni clé privée de certificat, ni code de récupération, ni identifiant d’accès complet, ni données de paiement complètes.
Envoyez un e-mail à support@rentmymini.com. Indiquez le type de demande dans l’objet et conservez dans le corps une adresse e-mail permettant de vous joindre ainsi que les informations anonymisées nécessaires.
La file d’assistance classe les demandes selon la commande, le nœud, la chaîne de connexion et les éléments de reproduction. Les quatre catégories suivantes nécessitent des preuves différentes et suivent des parcours distincts.
| Niveau du problème | Éléments vérifiables par RentMini | Informations à fournir | Accès recommandé |
|---|---|---|---|
| Disponibilité du nœud | Association à la commande, état du nœud, état de l’appareil et informations de connexion côté service | Numéro de commande, nœud, heure de l’incident, état de la console | Ticket depuis la console |
| Accès au système | Informations de connexion, chaîne d’accès distant, réponse de l’appareil et état des identifiants | Mode de connexion, étape de l’erreur, résultat de la comparaison du réseau local | Guide de connexion |
| Configuration de logiciels tiers | Capacité du Mac dans le cloud à installer, lancer et consulter des fichiers normalement | Version du logiciel, mode d’installation, étapes de configuration et journaux anonymisés | Contacter l’équipe d’assistance |
| Problème lié au code du projet | Aide à distinguer les limites entre l’appareil, l’environnement système et la tâche du projet | Reproduction minimale, versions des dépendances, étape en échec et changements côté projet | Liste de la base de connaissances |
Le ticket de la console conserve la description du problème, les informations complémentaires et l’historique. Ajoutez les résultats au ticket d’origine afin d’éviter de diviser un même problème en demandes impossibles à relier.
Si le nœud, le comportement de l’erreur, l’environnement réseau ou les étapes de reproduction changent, décrivez les changements dans l’enregistrement d’origine. Renvoyer les mêmes captures n’apporte aucune information exploitable supplémentaire.
Indiquez dans l’objet la commande concernée et la tâche actuellement impossible à terminer, puis joignez le résultat du diagnostic minimal. La file d’assistance classe les demandes selon leur impact et leur reproductibilité.
RentMini propose deux configurations de Mac dans le cloud, RentMini M4 16 et RentMini M4 24, à partir de $19.4/jour. Les quatre nœuds de Singapour, du Japon (Tokyo), de Corée du Sud (Séoul) et de Hong Kong figurent au catalogue ; la disponibilité réelle est celle renvoyée en temps réel par la console.