Vérifiez d’abord, contactez l’assistance ensuite

Commencez par rechercher votre problème

Problème de connexion, paiement non confirmé ou environnement de développement à configurer ? Recherchez un symptôme et suivez les étapes dans l’ordre. Pour toute question concernant une commande ou une instance, ouvrez un ticket depuis la console.

Vous avez déjà une commande ? Consultez d’abord les informations de connexion, la durée de location et le statut du paiement dans les détails de l’instance.

Accès par problème

Quatre catégories pour trouver rapidement une solution

Commencez par identifier l’étape concernée. Un échec de connexion ne signifie pas forcément que le nœud est en panne, et un paiement non confirmé ne signifie pas qu’il faut payer à nouveau.

Dépannage de connexion

Vérifiez d’abord les identifiants, puis le réseau

Ne commencez pas par réinstaller la machine. Notez le message d’erreur exact et distinguez délai d’attente, refus de connexion et échec d’authentification pour aider l’assistance à cerner le problème.

Délai d’attente SSH : la connexion n’atteint pas l’étape de connexion

En cas de délai d’attente, vérifiez d’abord le chemin réseau au lieu de saisir votre mot de passe à répétition. Si la connexion est refusée, vérifiez le port et l’état du service. En cas d’échec d’authentification, consultez la vérification des identifiants ci-dessous.

  1. 01Recopiez l’adresse

    Dans les détails de l’instance de la console, copiez l’adresse actuelle de l’hôte et le port SSH. Supprimez les espaces ajoutés au collage et n’utilisez pas les informations de connexion d’une ancienne commande ou d’un autre nœud.

  2. 02Vérifiez votre accès réseau

    Vérifiez que votre réseau local autorise l’accès à ce port. Un réseau d’entreprise, un proxy ou un logiciel de sécurité peut limiter les connexions sortantes. Si vous y êtes autorisé, essayez un autre réseau pour comparer.

  3. 03Vérifiez l’instance et les règles

    Dans la console, vérifiez l’état de l’instance ainsi que les règles de pare-feu et les restrictions d’adresse IP source que vous avez définies. N’ouvrez pas tous les ports pour dépanner : vérifiez d’abord que votre adresse IP de sortie figure parmi les adresses autorisées.

Dans votre terminal, affichez les détails de connexion. Remplacez les champs en majuscules avant d’exécuter la commande :

ssh -vv -p SSH_PORT USER@HOST

Avant de transmettre les journaux, masquez les informations sensibles comme l’adresse de l’hôte, le nom d’utilisateur et les chemins locaux. Ne joignez ni clé privée ni mot de passe.

Écran noir en partage d’écran : vérifiez la session et réduisez la qualité

Un écran noir dans l’interface graphique et une connexion SSH impossible sont deux problèmes distincts. Essayez d’abord SSH pour vérifier que la machine est accessible. Si la ligne de commande fonctionne, concentrez-vous sur la session graphique et la configuration du client.

  1. 01Vérifiez le mode de connexion

    Utilisez les informations affichées dans les détails de l’instance. Le port SSH n’est pas celui du partage d’écran. Vérifiez que le protocole, l’hôte et le mode d’authentification du client correspondent.

  2. 02Reconnectez la session en cours

    Déconnectez le client, puis reconnectez-vous. Vérifiez si l’écran est verrouillé ou affiche l’écran de connexion. Évitez de modifier les réglages d’affichage depuis plusieurs clients à la fois : cela compliquerait la reproduction du problème.

  3. 03Réduisez la charge de transmission

    Réduisez d’abord la résolution et la qualité d’image, puis réessayez après avoir interrompu les transferts de fichiers volumineux. Si l’écran noir ne survient qu’avec un client précis, notez sa version et ses réglages, puis joignez une capture d’écran au ticket.

Identifiants refusés : ne confondez pas échec d’authentification et problème réseau

Un échec d’authentification indique généralement que la connexion a atteint le serveur. Vérifiez le nom d’utilisateur et le mode d’authentification plutôt que de changer d’emplacement à répétition.

  1. 01Vérifiez le nom d’utilisateur

    Utilisez le nom d’utilisateur de l’instance en cours. Après une réinstallation du système ou une migration, récupérez à nouveau les informations de connexion. Si vous avez changé le mot de passe, utilisez le nouveau.

  2. 02Vérifiez la clé privée

    Utilisez la clé privée correspondant à la clé publique configurée sur la machine et vérifiez les permissions du fichier de clé privée local. Ne fournissez pas le fichier de clé publique à SSH comme clé privée et ne transmettez jamais votre clé privée à l’assistance.

  3. 03Conservez le message d’erreur exact

    Notez l’heure de l’échec, le mode d’authentification et le message d’erreur. Si la clé d’hôte change après une réinstallation, vérifiez d’abord l’identité de l’instance dans la console, puis mettez à jour l’entrée locale.

Facturation et paiements

Vérifiez le statut de la commande avant tout nouveau paiement

Les seuls moyens de paiement acceptés sont USDT-TRC20 et Visa, Mastercard ou Amex via Stripe. Tous les paiements sont en dollars américains. Les options réellement disponibles sont indiquées dans la console.

USDT-TRC20 envoyé : pourquoi ma commande n’est-elle pas encore confirmée ?

Le statut « envoyé » affiché par votre portefeuille ne signifie pas que la commande est confirmée. Vérifiez le réseau, l’adresse de réception et le montant dû indiqués sur la page de paiement, puis consultez le statut de la transaction sur la blockchain. Le délai de confirmation d’un paiement USDT-TRC20 dépend de l’avancement de la transaction sur la blockchain ; aucun délai fixe n’est garanti.

Retournez dans la console pour vérifier le statut du paiement. Ne transférez pas de fonds selon des informations de paiement qui ne sont plus valides ou qui ne correspondent pas à la commande en cours. Si la transaction est confirmée mais que la commande n’est pas mise à jour, envoyez le numéro de commande, le hash de transaction, le montant et l’heure du transfert, avec le fuseau horaire. Ne communiquez ni clé privée, ni phrase de récupération, ni mot de passe. Ne relancez pas le transfert pendant l’attente.

Que faire si le paiement par Visa, Mastercard ou Amex échoue ?

Commencez par lire le message d’erreur sur la page de paiement. Vérifiez notamment que votre carte autorise les achats en ligne et en dollars américains, que le plafond disponible est suffisant, que les informations de facturation correspondent et que la vérification demandée par la banque émettrice a été effectuée. Si nécessaire, contactez votre banque pour connaître le motif du refus et évitez les tentatives répétées à intervalles rapprochés.

Si le navigateur s’interrompt, si la page de vérification se ferme ou si le retour à la page est anormal, vérifiez d’abord le statut de la commande dans la console avant de réessayer. Pour ouvrir un ticket, indiquez uniquement le numéro de commande, le message d’erreur et l’heure du problème. Masquez les informations sensibles sur les captures d’écran. Ne nous envoyez ni numéro de carte complet ni cryptogramme : Stripe traite les informations de paiement par carte.

Comment renouveler, vérifier le montant en dollars et télécharger une facture ?

Dans la console, vérifiez la date d’expiration de l’abonnement en cours, choisissez le renouvellement et confirmez le tarif. Avant de payer, vérifiez le modèle, la durée, l’emplacement et les options supplémentaires. Après le paiement, assurez-vous que la nouvelle durée de location s’affiche. Les services sont payables d’avance à la journée, à la semaine, au mois ou au trimestre ; la facturation à l’heure n’est pas proposée. Le montant du renouvellement et sa date d’effet sont indiqués dans la confirmation de commande.

Tous les prix du catalogue sont en dollars américains. XN Core M4 : 21,4 $ par jour, 57,7 $ par semaine, 106,8 $ par mois, 290,5 $ par trimestre ; XN Pro M4P : 59,3 $ par jour, 160,1 $ par semaine, 296,4 $ par mois, 806,2 $ par trimestre. Sur la facture, vérifiez séparément le tarif de base et les options choisies. Consultez et téléchargez vos factures depuis l’historique de facturation de la console. Si le téléchargement échoue, ouvrez un ticket avec le numéro de facture.

Vous recevrez un rappel avant l’expiration, mais celui-ci ne remplace pas une sauvegarde. Ajoutez un rappel à votre calendrier, vérifiez à l’avance le paiement et la durée de location, et synchronisez régulièrement vos fichiers importants avec votre propre stockage.

Système et environnement

Sauvegardez votre travail avant de modifier l’environnement

Machines physiques dédiées, non virtualisées, avec interface graphique macOS et accès en ligne de commande. Avant d’installer des outils, de changer de version ou de réinstaller le système, vérifiez vos sauvegardes et les dépendances de votre projet.

Que préparer avant de réinstaller macOS ?

Arrêtez les compilations, transferts et tâches expérimentales en cours, puis sauvegardez le code, les artefacts, la configuration de l’environnement et les certificats à conserver. Une réinstallation modifie l’environnement système et peut effacer les données locales : ce ne doit pas être votre première démarche pour résoudre un problème de connexion.

Dans la console, consultez les options de réinstallation de l’instance et les instructions de confirmation. Si vous avez besoin d’aide, ouvrez un ticket depuis la commande concernée en précisant l’instance à réinstaller et les sauvegardes déjà effectuées. Une fois l’opération terminée, récupérez les nouveaux identifiants de connexion, vérifiez la version de macOS, les chemins des outils et l’espace disque, puis restaurez votre projet. Ne vous fiez pas aux anciennes informations de connexion pour évaluer le nouvel environnement.

Comment vérifier et changer de version de Xcode et des outils en ligne de commande ?

Vérifiez d’abord les versions de Xcode, du SDK et de macOS requises par votre projet, puis contrôlez le répertoire développeur sélectionné. Si plusieurs versions de Xcode sont installées, celle ouverte dans l’interface graphique peut différer de celle utilisée pour les compilations en ligne de commande.

xcode-select -p
xcodebuild -version
uname -m
df -h

Les trois premières commandes affichent respectivement le répertoire développeur, la version de Xcode et l’architecture ; la dernière vérifie l’espace disque. Sur Apple Silicon, l’architecture native doit être arm64. Pour changer de version, vérifiez d’abord que le chemin de l’application existe, puis utilisez sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer pour sélectionner le répertoire correspondant. Cette commande influence les prochaines compilations en ligne de commande.

Avant d’utiliser Homebrew, vérifiez command -v brew et brew --versionpour confirmer que la commande provient de l’environnement attendu. Installez les dépendances en respectant les versions verrouillées par le projet et évitez de modifier à la fois la chaîne d’outils, les dépendances et les scripts de compilation. En cas d’échec, indiquez les versions des outils, la commande exécutée et la fin du message d’erreur : c’est plus utile que « la compilation ne marche pas ».

Quels fichiers sauvegarder et vérifier avant l’expiration ?

Rassemblez au minimum trois catégories de fichiers : le code non envoyé et la configuration du projet ; les artefacts de compilation et résultats d’expériences ; la liste des dépendances et les fichiers de licence nécessaires à la restauration de l’environnement. Chiffrez les certificats et les clés, partagez-les uniquement selon les autorisations de l’équipe et ne les incluez ni dans un dépôt public ni dans les pièces jointes d’un ticket.

Vous pouvez synchroniser les fichiers vers votre propre espace de stockage avec scp ou rsync. Transférez d’abord un petit échantillon pour vérifier le chemin, les permissions et la lisibilité, puis copiez le dossier complet. Une fois le transfert terminé, comparez le nombre et la taille des fichiers ou leurs sommes de contrôle, puis ouvrez les artefacts importants. Un SSD supplémentaire est un espace de stockage externe, pas une sauvegarde indépendante, et ne synchronise pas automatiquement les données entre les nœuds.

Ne comptez pas sur une récupération des données après l’expiration. Les modalités de conservation et de suppression sont celles affichées dans la console et prévues par les règles applicables. Si vous avez besoin d’une migration particulière, ouvrez un ticket avant la fin de la location et terminez vos sauvegardes.

Réseau et emplacements

Choisissez un emplacement adapté à votre flux de travail, puis testez-le

Les six emplacements proposent les deux modèles. Tenez compte de la position des utilisateurs, du sens des transferts de code et d’artefacts, ainsi que de votre usage habituel de SSH ou de l’interface graphique.

Comment choisir parmi les six emplacements et évaluer la latence ?

Commencez par restreindre les choix selon la situation géographique, puis testez avec votre propre réseau. Le tableau indique des pistes de sélection, pas une latence mesurée ou garantie : le routage de votre opérateur et le réseau local peuvent modifier les résultats. SSH nécessite peu de transmission vidéo continue, tandis que le partage d’écran dépend davantage de la latence aller-retour et de la bande passante.

Couverture des six emplacements et conseils de vérification de la connexion
Emplacement Régions à privilégier Vérifications à effectuer
Singapour Asie du Sud-Est Comparez la réactivité et la vitesse de synchronisation du code sur votre réseau habituel.
Japon (Tokyo) Asie de l’Est Testez avec votre client de partage d’écran habituel, en commençant par une qualité d’image réduite.
Corée du Sud (Séoul) Asie du Nord-Est Comparez les itinéraires réseau depuis votre accès local au lieu de vous fier uniquement à la distance sur la carte.
Hong Kong Sud de la Chine et Asie du Sud-Est Vérifiez les restrictions de votre réseau local et l’effet des transferts de fichiers volumineux sur la réactivité.
États-Unis (côte Est) Est de l’Amérique du Nord et Europe de l’Ouest Observez à la fois le transfert des artefacts de compilation et la réactivité de la connexion interactive.
États-Unis (côte Ouest) Côte Ouest de l’Amérique du Nord Vérifiez où se trouvent votre équipe, votre stockage de code et les destinataires des artefacts.

En cas de lenteur, interrompez d’abord les transferts volumineux et réduisez la résolution du partage d’écran pour comparer. Si le problème reste marqué, notez votre type de réseau local, l’emplacement, la version du client et la plage horaire concernée. Ne concluez pas qu’un nœud entier est indisponible après un seul test.

Comment migrer vers un autre emplacement ?

Sauvegardez les données de l’instance d’origine et notez les versions des outils, les variables d’environnement, la configuration des tâches et les règles d’accès réseau. Vérifiez ensuite dans la console les modalités de commande pour l’emplacement cible. Si la migration concerne un abonnement existant, ouvrez d’abord un ticket pour confirmer les frais et la prise d’effet. Ne supposez pas que changer d’emplacement transfère automatiquement le disque.

Lorsque l’instance cible est accessible, restaurez les fichiers et vérifiez la compilation, la signature, le transfert des artefacts et les tâches planifiées. Mettez à jour l’adresse de l’hôte utilisée par l’équipe et les règles d’adresse IP source. Une fois la nouvelle instance opérationnelle, vous pourrez gérer l’ancienne. Pendant la migration, évitez d’exécuter simultanément sur les deux instances des tâches de publication susceptibles de produire des résultats en double.

Quels modèles sont disponibles dans chacun des six emplacements ?

Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong, États-Unis (côte Est) et États-Unis (côte Ouest) proposent tous le XN Core M4 (M4 / 16 Go / SSD 256 Go) et le XN Pro M4P (M4 Pro / 64 Go / SSD 2 To). La disponibilité affichée au catalogue est élevée pour ces deux configurations ; consultez la console pour connaître la disponibilité en temps réel.

Le XN Core M4 convient aux compilations d’apps courantes et à l’intégration continue. Pour les compilations parallèles lourdes et les tâches nécessitant davantage de mémoire unifiée, choisissez le XN Pro M4P. Vous pouvez ajouter un SSD externe de 1 To ou de 2 To ; cela ne modifie pas les caractéristiques du disque principal du modèle. Les nœuds fonctionnent normalement 365 jours par an. En cas de problème de connexion, procédez par étapes et vérifiez le réseau, l’authentification et le système.

Préparer un ticket

Présentez clairement les vérifications déjà effectuées

Connectez-vous à la console et sélectionnez la commande concernée dans la rubrique des tickets pour décrire le problème. Réservez les informations de commande à votre ticket et n’envoyez ni mot de passe de connexion ni données de paiement complètes dans une demande publique.

Préparez ces quatre éléments avant l’envoi

  1. 01Commande et instance

    Indiquez le numéro de commande, l’emplacement et le nom du modèle. Si vous avez plusieurs instances, précisez laquelle est concernée afin de ne pas joindre les journaux d’une autre machine.

  2. 02Heure et symptômes

    Indiquez l’heure et le fuseau horaire de la première occurrence, ainsi que la fréquence du problème. Précisez la dernière opération qui a fonctionné et les réglages modifiés avant l’apparition du problème.

  3. 03Étapes et vérifications

    Détaillez les étapes suivies, les versions du client ou des outils, le message d’erreur exact et les vérifications déjà effectuées. Vous pouvez aussi indiquer le résultat d’un test avec un autre réseau ou un autre client.

  4. 04Pièces jointes expurgées

    Joignez les captures d’écran ou extraits de journaux nécessaires. Supprimez les mots de passe, clés privées, informations sensibles des certificats et données de sécurité des paiements, tout en conservant les codes d’erreur utiles.

Suivez cet ordre

Emplacement et modèle → numéro de commande → heure du problème et fuseau horaire → résultat attendu → erreur constatée → vérifications déjà effectuées. Si une compilation ou une publication est touchée, précisez la tâche concernée plutôt que d’écrire simplement « c’est urgent ».

Après l’envoi, ajoutez les nouveaux résultats dans le même ticket afin de conserver tout le contexte. Les horaires de réponse, l’avancement du traitement et le délai estimé figurent dans la console et les réponses au ticket ; aucun délai fixe de réponse non confirmé n’est garanti ici. La disponibilité du nœud et les délais de réponse de l’équipe sont deux choses différentes.

Vous n’avez pas trouvé votre réponse ?

Demandez conseil avant l’achat, ouvrez un ticket pour votre instance

Vous n’avez pas encore commandé ? Indiquez-nous votre usage, la durée de location envisagée et votre région pour obtenir des conseils sur les modèles et les emplacements. Pour une commande existante, ouvrez un ticket depuis la console afin que nous puissions associer le problème à votre instance.

Pour les questions avant achat, les achats d’équipe et toute autre demande, contactez-nous à l’adresse support@xcodenet.com. N’envoyez ni mot de passe, ni clé privée, ni numéro de carte complet par e-mail.