Intégrez la location au planning de livraison

De la commande au premier ipa, le jour même

Continuez à coder sous Windows et confiez la compilation nécessitant macOS à un Mac cloud. Louez à la journée et accédez à la machine le jour même après paiement, sans acheter un Mac pour un projet de courte durée.

La machine est disponible le jour même. La compilation peut toutefois prendre plus longtemps si les dépendances du projet, la version de Xcode ou les éléments de signature ne sont pas prêts. Vérifiez les six points ci-dessous, puis suivez les étapes correspondant à votre framework.

Mac Mini M4 : $20.2/jour. Machine physique dédiée, pas une VM ; à la fin du projet, le service s’arrête à l’échéance sans renouvellement.

Vérifiez les éléments avant le début de la facturation

Avant de commander, validez ces six points

Vous pouvez louer dès maintenant si le code est accessible, si les éléments de signature sont autorisés et si une compilation est prévue prochainement. En revanche, attendez si le client n’a pas encore confirmé l’identifiant de bundle ou le titulaire de la signature : la machine resterait inutilisée.

  • Objectif : que devez-vous livrer ?

    Précisez s’il s’agit de compiler, de tester l’intégration ou de préparer la publication. Indiquez la version cible, l’identifiant de bundle, la méthode de build et le destinataire final. Une seule compilation d’archive et plusieurs jours de tests d’intégration n’impliquent pas la même durée de location.

  • Nœud : choisissez selon l’emplacement des utilisateurs

    Quatre nœuds sont disponibles : Singapour, Tokyo, Séoul et Hong Kong. Prenez en compte le réseau utilisé par l’équipe qui se connectera le plus souvent. Si vous transférez fréquemment des fichiers, vérifiez aussi le trajet de transfert. La proximité géographique ne garantit pas les mêmes performances sur chaque réseau ; l’expérience réelle dépend de votre connexion.

  • Durée : estimez le temps d’utilisation

    Tarifs à la journée, à la semaine, au mois ou au trimestre. Mac Mini M4 : $20.2 par jour, $54.6 par semaine, $101.1 par mois ou $275 par trimestre. À partir de trois jours d’utilisation continue, le tarif hebdomadaire revient moins cher que le paiement journalier. Si le calendrier n’est pas encore fixé, comparez les durées avant de payer.

  • Paiement : vérifiez les moyens disponibles

    Paiement en USDT-TRC20 ou par Visa / Mastercard / Amex (via Stripe), en dollars américains (USD) uniquement. Les moyens réellement disponibles dépendent des options renvoyées par le système de paiement. Vérifiez le montant de la commande et les instructions au moment du paiement ; ne vous fiez pas aux informations d’une ancienne commande.

  • Signature : certificat et clé privée indispensables

    Demandez au responsable du projet de confirmer l’autorisation de signature développeur et préparez le certificat, la clé privée et le profil de provisionnement correspondants. Un certificat seul ne suffit pas pour signer. Vérifiez sa validité, l’équipe associée, l’identifiant de bundle et l’usage prévu pour l’export. Transmettez ces éléments par un canal sécurisé, jamais dans un dépôt public.

  • Fin de location : désignez un responsable

    Confiez la fin de location à une personne clairement désignée. Le service s’arrête à l’échéance sans renouvellement ni frais de résiliation ; ne prenez pas l’arrêt de la machine pour une sauvegarde. Prévoyez le temps nécessaire à l’export des archives, à la validation par le client et aux éventuelles corrections. Renouvelez pour une nouvelle période uniquement si le délai est prolongé.

Du planning à la commande

Choisissez la machine selon la taille du projet

Les deux offres comprennent un Mac mini physique dédié. Choisissez la configuration en fonction de la charge du projet, puis sélectionnez le nœud et la durée. Inutile de prendre une machine plus puissante pour une compilation ponctuelle.

Mac Mini M4

M4 / 16 Go de RAM / SSD 256 Go

Adapté aux petits projets natifs, aux compilations Flutter classiques et aux tests d’intégration de courte durée. Vérifiez l’espace total requis par le code source, les dépendances, les simulateurs et les archives ; ne vous fiez pas uniquement à la taille du dépôt.

Moins adapté au stockage prolongé de nombreux fichiers multimédias, de plusieurs gros projets et de toutes les anciennes archives sur une seule machine.

$20.2/jour · $54.6/semaine
$101.1/mois · $275/trimestre

Mac Mini M4 Pro

M4 Pro / 64 Go de RAM / SSD 2 To

Adapté aux gros projets Unity, aux builds avec plusieurs targets et au traitement de dépendances plus lourdes. La mémoire et le stockage supplémentaires offrent plus d’espace aux projets complexes, sans garantir un gain de vitesse fixe pour chaque projet.

Peu adapté à la compilation occasionnelle d’un petit projet, surtout si l’équipe passe l’essentiel de son temps à attendre les validations du client.

$59.3/jour · $160/semaine
$296.3/mois · $805.9/trimestre

  1. 01

    Vérifiez la configuration

    Sur la page de commande, sélectionnez le modèle, le nœud et la durée de facturation. Ajoutez du stockage si nécessaire. Avant de valider, vérifiez la configuration complète et le montant total. La disponibilité affichée dans la console fait foi.

  2. 02

    Effectuez le paiement

    Suivez les instructions du moyen de paiement choisi, puis consultez la commande pour vérifier le résultat. Le paiement doit correspondre au statut de la commande. En cas d’écart, ouvrez un ticket avec le numéro de commande et le justificatif de paiement.

  3. 03

    Consultez l’instance

    La machine est activée le jour même après le paiement. Ouvrez les détails de l’instance correspondante dans la console pour consulter les informations de connexion et la date d’expiration. Ne reprenez pas l’adresse ou les identifiants d’une ancienne machine.

Connectez-vous avant de transférer le projet

Lors de la première connexion, vérifiez l’environnement

Pour commencer, utilisez le bureau à distance afin de vérifier l’interface graphique, le disque et Xcode, puis lancez les commandes de build via SSH. Les deux méthodes donnent accès au même nœud physique, pas à deux environnements distincts.

Poste de travail affichant du code, illustrant la vérification de l’environnement de build après connexion
Vérifiez que l’environnement de build est opérationnel avant de transférer le code client et les éléments de signature. Photo d’illustration.

Bureau à distance : pour la première vérification et l’archivage

Connectez-vous à la console, ouvrez les détails de l’instance correspondante et suivez les instructions de connexion, avec l’adresse et les identifiants indiqués. Lors de la première connexion, vérifiez l’identifiant de la machine, l’interface macOS, l’espace disque disponible et le répertoire du projet.

Le bureau à distance est plus pratique pour modifier les réglages de signature dans Xcode, consulter les simulateurs ou traiter les alertes graphiques. Ne partagez pas vos identifiants dans une conversation de groupe et ne faites pas modifier le même répertoire de build par plusieurs personnes à la fois.

Privilégiez l’interface graphique au début

SSH : pour les builds en ligne de commande et les journaux

Depuis le terminal Windows, utilisez un client SSH. L’adresse, le port, le nom d’utilisateur et le mode d’authentification sont indiqués dans les détails de l’instance. Lors de la première connexion, vérifiez l’identité de l’hôte. Si elle a changé, recherchez-en la cause avant de continuer.

Une connexion SSH réussie ne garantit pas que la signature fonctionne. Vérifiez aussi l’utilisateur actif, les droits d’accès au trousseau, le chemin des outils de build et les dépendances du projet. Les tâches automatisées doivent également être testées dans l’environnement de l’utilisateur concerné.

Automatisez seulement après validation des commandes

Après l’installation ou le changement de Xcode, vérifiez la version réellement utilisée

Commencez par vérifier les versions de Xcode et du SDK requises par le projet. Si la machine dispose déjà d’une version compatible, inutile de la réinstaller. S’il manque des outils, configurez Xcode et les outils en ligne de commande, puis effectuez les étapes requises lors du premier lancement dans l’interface graphique.

Les deux commandes ci-dessous affichent le chemin des outils de développement et la version de Xcode. Vérifiez que les résultats correspondent aux exigences du projet avant de restaurer les dépendances. La présence de Xcode dans le dossier Applications ne suffit pas pour commencer à déboguer le code.

À exécuter dans le terminal du Mac cloud

xcode-select --print-path
xcodebuild -version

Si la version ou le chemin ne convient pas, sélectionnez les outils installés à leur emplacement, puis vérifiez à nouveau. Ne copiez pas le chemin d’installation d’une autre machine.

Suivez les étapes du framework sans négliger la signature

Faites de votre premier build une livraison reproductible

Commencez par compiler une version de commit identifiée, puis intégrez-la au flux de travail courant. Quelle que soit la méthode, vérifiez les versions des dépendances, les éléments de signature et l’usage prévu pour l’export : une compilation réussie ne signifie pas que la livraison est terminée.

Xcode natif : archivez avant l’export

  1. Récupérez le commit validé et restaurez les dépendances selon les instructions du projet. Si le gestionnaire de dépendances génère un workspace, n’ouvrez pas le fichier project seul.
  2. Vérifiez le Scheme, l’identifiant de bundle, le numéro de version et le numéro de build. Importez le certificat, la clé privée et le profil de provisionnement autorisés par le client, puis confirmez qu’ils correspondent au Target actif.
  3. Choisissez une destination adaptée à l’archivage et lancez Product → Archive. Vérifiez l’archive dans Organizer, puis exportez le fichier ipa selon l’usage prévu pour la livraison.
  4. Conservez l’archive, les fichiers de symboles et les journaux de build. Associez les livrables au commit correspondant afin de pouvoir retrouver leur origine en cas de modification ultérieure.

En cas de problème de signature, vérifiez d’abord la correspondance entre le certificat et le profil de provisionnement. Évitez de supprimer à répétition l’ensemble du cache du projet.

Flutter : vérifiez d’abord la chaîne d’outils iOS

Utilisez la version de Flutter définie par le projet. Depuis sa racine, vérifiez la chaîne d’outils, restaurez les dépendances, puis lancez la compilation :

flutter doctor -v
flutter pub get
flutter build ipa --release

Si le projet utilise des flavors, un point d’entrée personnalisé ou une configuration d’export, ajoutez les paramètres prévus dans ses instructions de build. La commande par défaut ne convient pas nécessairement à tous les projets.

Une fois la chaîne d’outils validée, vérifiez la signature et les dépendances natives du projet iOS. Contrôlez le chemin du fichier ipa et le résultat de l’export dans la sortie de build.

React Native : vérifiez la configuration Release

  1. Installez les dépendances JavaScript à partir du fichier de verrouillage et utilisez les versions de Node et du gestionnaire de paquets définies par le projet.
  2. Restaurez les dépendances natives iOS, ouvrez le workspace correspondant et vérifiez le Scheme et la configuration Release.
  3. Vérifiez le bundle des ressources JavaScript, les modules natifs, la configuration d’environnement et les éléments de signature, puis lancez l’archivage et l’export.
  4. Vérifiez que le package exporté ne dépend pas d’un serveur de développement. Le fonctionnement en mode développement ne remplace pas la validation en Release.

Gérez séparément les variables d’environnement et les clés client. N’inscrivez pas la configuration de production dans les journaux et ne la commitez pas dans le dépôt.

La séparation des clients ne se résume pas au nom des dossiers

Une machine partagée à tour de rôle ou une par client ?

Une machine dédiée signifie qu’un client loue un nœud physique pour son usage exclusif. Cela ne sépare pas automatiquement les projets de plusieurs clients hébergés par le même studio. Si vous utilisez une machine à tour de rôle, séparez également les comptes, les trousseaux et les répertoires de livrables.

Une machine à tour de rôle : pour les compilations ponctuelles

Si plusieurs petits projets ne sont pas livrés en même temps, créez un compte macOS par client pour séparer les projets, les trousseaux et les historiques de build. Avant chaque changement de tâche, vérifiez le compte actif et évitez de partager un répertoire de téléchargements désorganisé.

En contrepartie, les tâches doivent être planifiées à tour de rôle et les changements de compte gérés manuellement. Les différents comptes restent sur la même machine ; cette solution ne répond pas nécessairement à toutes les exigences de séparation des clients.

Vérifiez d’abord que le client accepte cette organisation

Une machine par client : pour les livraisons simultanées

Si plusieurs clients doivent recevoir leurs builds la même semaine ou si le contrat exige une séparation plus nette des environnements, louez une machine physique dédiée par client. Nommez chaque machine selon le client et le projet, et conservez certificats, clés privées, code et archives sur le nœud correspondant.

En contrepartie, chaque machine est facturée séparément. Même avec des environnements séparés, contrôlez les droits d’accès, conservez des sauvegardes et désignez un responsable du renouvellement et de la fin de location pour chaque machine.

Builds en parallèle, passation séparée
Projet livré : pensez aussi à la fin de location

Récupérez le projet avant l’arrêt de la machine

Le service s’arrête si vous ne renouvelez pas. La machine ne doit pas être l’unique emplacement d’archivage du projet : exportez les fichiers et vérifiez-les avant de décider d’arrêter ou de prolonger la location.

  1. 01

    Exportez et vérifiez

    Téléchargez le fichier ipa, l’archive, les fichiers de symboles, les journaux de build et les configurations nécessaires. Exportez de façon sécurisée les éléments de signature à conserver, avec l’autorisation du client. Vérifiez l’intégrité des fichiers sur votre ordinateur ou sur le stockage désigné par le client. Conservez les clés privées séparément des mots de passe.

  2. 02

    Supprimez les accès devenus inutiles

    Supprimez les identifiants de dépôt, les clés temporaires et les liens avec les tâches automatisées dont vous n’avez plus besoin. Vérifiez qu’aucun build n’est encore envoyé à cette machine. Le système est nettoyé avant sa réattribution, mais sauvegardez vos données et révoquez les accès nécessaires au préalable.

  3. 03

    Confirmez l’arrêt ou le renouvellement

    Si le projet est terminé, vérifiez la date d’échéance dans la console et ne renouvelez pas. S’il est prolongé, renouvelez la durée adaptée depuis l’abonnement ou la commande de l’instance, puis vérifiez la nouvelle date d’échéance après le paiement. Pour une réinstallation ou une aide sur l’état de la machine, ouvrez un ticket dans la console en indiquant son identifiant et votre demande.

Que fournir si la connexion, la signature ou le paiement bloque ?

Dans votre ticket, indiquez l’identifiant de la machine, le nœud, l’heure de l’incident, les étapes suivies et le message d’erreur complet. Évitez de faire apparaître les mots de passe et les clés privées dans les captures d’écran. Si vous n’avez pas encore loué de machine, vous pouvez écrire à support@vmssd.com en précisant la durée du projet et le framework utilisé. Pour un problème sur une instance existante, ouvrez de préférence un ticket depuis la console afin de le rattacher à la commande correspondante.

Préparez les éléments avant le début de la facturation

Choisissez un modèle, un nœud et une durée ; la machine est activée le jour même après paiement. Commencez par un build reproductible, puis choisissez la durée de renouvellement en fonction du calendrier du projet.