Après des années à faire tourner un petit parc Mac en interne pour les builds iOS et la CI, nous l'avons fermé et sommes passés au Mac cloud tout géré VNCMac. Voici une réflexion sur les raisons pour lesquelles le calcul économique et la charge opérationnelle ont fini par pencher en faveur des Mac mini managés plutôt que de notre propre rack.
Le rack Mac en interne : ce que nous avions
Nous avions quelques Mac mini en colocation : alimentation, refroidissement, réseau, et notre propre accès SSH et VNC. Nous possédions le matériel et payions le datacenter pour l'espace et la bande passante. Sur le papier, le coût par machine-heure semblait inférieur au « cloud ». En pratique, nous passions beaucoup de temps sur des sujets qui n'avaient rien à voir avec la livraison produit.
Les pannes étaient notre affaire : alimentations mortes, disques défaillants, machines qui ne redémarraient pas après une micro-coupure. Nous n'avions pas de capacité de pointe ; ajouter un nœud impliquait d'acheter du matériel, de l'expédier et d'attendre que le colo le monte en rack. Les mises à jour macOS et Xcode devaient être planifiées et testées selon notre propre calendrier. Lorsqu'une CVE critique tombait, c'était à nous de patcher et de redémarrer.
Où se trouvait vraiment le coût
Le coût brut par Mac-heure n'était qu'une partie de l'histoire. Nous avons mesuré le temps passé sur l'exploitation du datacenter et des Mac : provisionnement, imaging, gestion des clés, surveillance et gestion des incidents. Même avec seulement quelques machines, cela représentait plusieurs jours-ingénieur par trimestre. Au coût salarial chargé habituel, c'était bien plus que l'écart entre notre facture colo et un service Mac managé.
- Cycle de vie matériel : achat, expédition, décommissionnement. Aucune élasticité ; soit nous sur-dimensionnions, soit nous tournions à flux tendu.
- Propriété des incidents : tout problème matériel ou OS relevait de notre astreinte. Aucun SLA fournisseur pour « Mac ne démarre pas ».
- Conformité et sécurité : nous devions documenter et maintenir nous-mêmes le durcissement, les correctifs et les contrôles d'accès pour les audits.
Les données du secteur vont dans le même sens. À grande échelle, certaines entreprises font l'inverse : Grab, par exemple, a déplacé 200 Mac hors du cloud vers son propre datacenter et a annoncé environ 2,4 M$ d'économies sur trois ans, en citant des minutes de build macOS cloud environ dix fois plus chères que Linux et des engagements d'utilisation minimale de 24 heures. Ce calcul tient la route lorsque l'on dispose de centaines de machines et d'une équipe ops dédiée. Pour une petite équipe avec quelques dizaines de nœuds de build ou moins, le coût fixe de faire tourner son propre parc Mac perd généralement face à un fournisseur managé qui répartit ce coût sur de nombreux clients.
« Dès que nous avons ajouté le coût de notre temps — ops, incidents et coût d'opportunité — le prix à l'heure de nos Mac en colo n'était plus inférieur au Mac cloud managé. » — Architecte senior, 2026
Pourquoi nous avons choisi VNCMac tout géré
Nous avions besoin de Mac mini dédiés (et non de VMs partagées) pour Xcode, la signature de code et la CI. Nous voulions aussi une facturation à l'heure et aucun engagement long terme afin de pouvoir monter en charge pour les releases et redescendre ensuite. VNCMac proposait exactement cela : Mac mini bare metal, accès SSH et VNC, contrôle total du système d'exploitation et paiement à l'usage. Pas de contrat minimum et pas besoin de toucher au matériel ou au datacenter.
Du point de vue de l'architecte, le compromis était clair. Nous avons abandonné l'illusion de « posséder » la courbe de coût et gagné un prix à l'heure prévisible, quelqu'un d'autre pour le matériel et les locaux, et la possibilité d'ajouter ou de retirer des nœuds en quelques minutes au lieu de semaines. Notre équipe pouvait se concentrer sur les pipelines de build et le produit au lieu du câblage en rack et des disques défaillants.
Ce que nous n'avons pas abandonné
Passer au managé ne signifiait pas perdre le contrôle. Nous utilisons toujours les clés SSH, nos propres configs et nos agents CI (par ex. GitLab Runner, Fastlane) sur les Mac loués. Nous tunnelisons le VNC via SSH et traitons les instances comme éphémères d'un point de vue sécurité : pas de secrets longue durée sur disque que nous ne gérons pas. Le fournisseur s'occupe de l'alimentation, du refroidissement et du remplacement matériel ; nous gérons tout ce qui est au-dessus du OS. Cette séparation des responsabilités a rendu le changement acceptable pour la sécurité et la conformité.
Recommandation pour les autres équipes
Si vous êtes architecte senior ou tech lead et que vous pesez capacité Mac en interne contre Mac cloud managé, faites le modèle de coût complet : matériel, colo et — crucial — le coût du temps de votre équipe pour l'approvisionnement, l'exploitation et les incidents. Pour des parcs Mac de taille petite à moyenne (grosso modo en dessous de 50–100 nœuds), les services managés comme VNCMac gagnent souvent sur le coût total de possession et permettent à l'équipe de se concentrer sur la livraison. Pour des parcs très importants avec des équipes infra dédiées, l'équation peut s'inverser ; l'essentiel est de faire les calculs en incluant l'ops et le coût d'opportunité.
En résumé
Nous avons fermé notre datacenter Mac en interne et sommes passés au Mac cloud tout géré VNCMac parce que le coût total de possession — y compris notre temps — favorisait le managé. Nous avons conservé SSH, le VNC via SSH et le contrôle total du OS ; nous avons abandonné la propriété du matériel et des locaux. Pour des équipes de notre taille, ce compromis a été le bon. Si vous envisagez le même mouvement, modélisez votre coût complet et comparez-le à un fournisseur Mac managé ; vous constaterez peut-être, comme nous, que l'option colo « moins chère » ne l'était qu'en apparence.