Une file d’exécution sature pendant les validations, tandis que la signature de production exige un environnement Mac que personne ne veut laisser sans surveillance.
Solution la plus rapide : les validations standard, les tests temporaires et les charges irrégulières doivent aller vers un agent macOS hébergé ; les archives signées, les dépendances privées, les tâches longues et l’environnement Xcode figé doivent rester sur un Mac autogéré. Pour la plupart des entreprises, deux files Buildkite séparées constituent le compromis le plus contrôlable.
Qui devrait lire ce guide ?
Ce guide s’adresse aux équipes qui utilisent déjà Buildkite et doivent ajouter des ressources iOS ou macOS, sans confondre le choix de l’agent avec celui du plan de contrôle.
Il concerne également les responsables IT, achats, sécurité et publication qui doivent arbitrer entre capacité élastique, secrets de signature, accès privé, continuité de service et coût total.
00La matrice de répartition
Le premier choix ne devrait pas être « hébergé ou autogéré » pour toute la chaîne. Il faut d’abord classer les travaux selon le niveau de contrôle requis. Dans l’architecture Buildkite, le plan de contrôle orchestre les travaux, tandis que l’agent les exécute sur une ressource macOS réelle ou hébergée. La documentation officielle de l’architecture Buildkite décrit cette séparation entre ordonnanceur, files et agents.
| Type de travail | Contrôle requis | File recommandée | Justification |
|---|---|---|---|
| Validation de demande de fusion | Faible à modéré | Agent hébergé | Environnement standard et capacité variable |
| Tests avec simulateur | Modéré | Hébergé ou autogéré | Dépend du besoin de cache et de la reproductibilité |
| Archive de publication | Élevé | Agent autogéré | Contrôle du trousseau, des certificats et de l’environnement |
| Signature de production | Très élevé | File autogérée isolée | Les identifiants ne doivent pas être partagés avec du code non approuvé |
| Dépendance au réseau interne | Élevé | Mac autogéré | Accès aux dépôts, mandataires ou services privés |
| Tâche longue ou sensible à la file | Élevé | Selon les limites vérifiées | La durée et la récupération doivent être prouvées par des essais |
Cette séparation est importante : une file destinée à des agents hébergés ne doit pas être traitée comme une file générale dans laquelle l’équipe ajouterait ensuite des Macs autogérés. Les règles de gestion des files Buildkite servent précisément à associer des agents et des travaux selon des propriétés contrôlées. Une file hébergée et une file autogérée doivent donc être créées et testées séparément.
Le plan de contrôle Buildkite n’est pas le Mac qui compile. L’agent macOS hébergé est une capacité d’exécution opérée par Buildkite ; l’agent autogéré est le logiciel installé par l’entreprise ; le Mac qui porte cet agent reste, lui, sous la responsabilité de l’équipe ou de son fournisseur d’infrastructure. Cette distinction évite d’attribuer au service de contrôle une responsabilité qui incombe en réalité au propriétaire du nœud.
01Le contrôle des versions et des outils
La version de macOS proposée dans une file hébergée peut convenir à une validation standard, notamment lorsque le projet suit une combinaison Xcode officiellement disponible. La page Buildkite consacrée aux agents macOS hébergés doit toutefois être consultée au moment de l’achat : images disponibles, versions proposées, rythme de mise à jour, limites de capacité et état des fonctionnalités peuvent évoluer.
La compatibilité ne se déduit pas du seul nom de Xcode. Les exigences propres à Xcode 26, notamment celles qui concernent la version du système, doivent être vérifiées dans les notes de version Xcode 26 d’Apple. Une image qui démarre correctement peut encore être inadaptée si le projet dépend d’un outil de signature, d’un gestionnaire de paquets, d’un compilateur ou d’un script qui n’est pas présent.
Un Mac autogéré offre un contrôle plus fin : l’équipe peut conserver une version validée de macOS, plusieurs versions de Xcode, des modules particuliers, des caches locaux et des outils internes. Cette liberté ajoute cependant une charge de gouvernance. Il faut documenter les versions, tester les mises à jour, supprimer les outils obsolètes et empêcher qu’un script d’installation modifie silencieusement la base de production.
« Choisir le système » ne signifie donc pas « figer toutes les dépendances ». La vérification doit couvrir :
- l’image ou l’installation de base réellement utilisée ;
- les modules et outils additionnels ;
- les variables d’environnement ;
- les crochets d’agent exécutés avant ou après le travail ;
- les caches de dépendances et leur stratégie d’invalidation ;
- les certificats, profils et trousseaux ;
- les différences entre une installation neuve et un nœud déjà utilisé.
Pour un projet audio, vidéo ou de design qui génère de lourds artefacts, le cache et l’espace temporaire peuvent peser davantage que la seule puce Apple Silicon. La question est alors moins « quel agent est le plus rapide ? » que « quelle configuration reste reproductible lorsque le cache est froid, lorsqu’un module est mis à jour et lorsqu’un second travail arrive simultanément ? ».
02La frontière de confiance et les secrets
Les validations de branches non fiables et les signatures de production ne devraient pas partager les mêmes identifiants, même si elles utilisent le même dépôt. Une étape qui manipule un certificat, un profil de provisioning ou une clé privée doit être placée dans une file dont les permissions, les agents et les contrôles d’accès sont explicitement documentés.
| Élément de sécurité | Agent hébergé | Mac autogéré |
|---|---|---|
| Code temporaire ou non approuvé | Environnement à durée limitée à vérifier | Nœud dédié et règles de nettoyage obligatoires |
| Certificat de production | À éviter sans mécanisme de secret et d’effacement prouvé | Trousseau et accès contrôlés par l’entreprise |
| Jeton Buildkite | Géré selon les options du service | Rotation et stockage sous responsabilité de l’équipe |
| Dépôt privé | Vérifier la connectivité et l’autorisation | Mandataire, pare-feu et sortie réseau configurables |
| Nettoyage après tâche | Confirmer le comportement documenté | Automatiser le nettoyage et l’inspecter |
| Extension ou module tiers | Liste autorisée à établir | Liste blanche, revue et versionnement à maintenir |
Pour un agent autogéré, le jeton ne doit pas être copié dans les scripts du dépôt. Les recommandations Buildkite sur les jetons des agents autogérés constituent la référence pour leur création, leur portée et leur renouvellement. La configuration doit aussi préciser quels modules peuvent être chargés et quels travaux peuvent atteindre le nœud.
L’accès au réseau interne mérite un contrôle indépendant. Le Mac doit pouvoir atteindre les services strictement nécessaires : dépôt privé, registre, serveur de dépendances, coffre de secrets ou service de notification. Une ouverture générale des connexions sortantes simplifie parfois le premier essai, mais elle rend l’audit et l’analyse d’incident plus difficiles. La documentation Buildkite sur la distribution des travaux aide à relier l’affectation des travaux aux caractéristiques déclarées par les agents.
La liste suivante doit être validée avant l’utilisation d’une signature réelle :
- [ ] file de production distincte de la file de validation ;
- [ ] identifiants de signature absents des travaux non approuvés ;
- [ ] jeton d’agent stocké hors du dépôt et renouvelable ;
- [ ] accès au réseau interne limité aux destinations nécessaires ;
- [ ] nettoyage vérifié après succès, échec et interruption ;
- [ ] journal d’accès aux secrets conservé par l’entreprise ;
- [ ] procédure de révocation testée avant le premier déploiement.
03La capacité, la file et la reprise
Une file qui termine rapidement un travail isolé peut malgré tout produire une mauvaise expérience lorsque plusieurs validations arrivent ensemble. La capacité doit être évaluée avec le temps d’attente, le temps d’exécution, le taux de reprise, le taux d’échec et la disponibilité des caches. Une mesure unique de durée de compilation ne suffit pas pour déduire le débit global.
L’agent hébergé est pertinent lorsque la charge varie fortement : validations après une série de commits, tests de simulateur pendant une campagne de correction, ou génération temporaire d’artefacts audio et vidéo. L’équipe paie alors pour une capacité qu’elle peut ajuster selon les règles et tarifs publiés par Buildkite, à vérifier sur la page officielle de tarification Buildkite. Il faut relever les limites en vigueur plutôt que réutiliser une valeur ancienne.
Le Mac autogéré devient préférable lorsque la file doit conserver une base stable, lorsqu’un cache volumineux est essentiel, ou lorsque le projet dépend d’un service interne qui ne peut pas être exposé à une capacité hébergée. Cette option n’est saine que si le nœud peut redémarrer sans intervention manuelle et si une capacité de remplacement existe.
Les preuves à demander lors d’un essai sont concrètes :
- démarrage automatique après une coupure électrique ou un redémarrage système ;
- reconnexion de l’agent après perte du réseau ;
- détection d’un agent silencieux ou bloqué ;
- redémarrage distant sans accès physique ;
- retrait propre d’un travail interrompu ;
- bascule vers une autre capacité lorsque le nœud est indisponible ;
- conservation des journaux nécessaires à l’analyse.
Un fournisseur de Mac distant peut être utile lorsque l’entreprise veut un nœud physique administrable sans acheter immédiatement le matériel. Dans ce cas, l’équipe doit demander les conditions de livraison, les modalités de redémarrage et le périmètre de récupération avant de classer le nœud comme « production ». Les informations de présentation de NUKCLOUD peuvent servir de point de départ, mais elles ne remplacent pas une fiche d’acceptation signée par les responsables techniques.
04Le modèle TCO et les seuils de décision
Le coût total doit refléter les ressources consommées et le travail nécessaire pour les rendre fiables. Pour l’option hébergée, le modèle peut être écrit ainsi :
TCO hébergé = consommation des agents + options de capacité + stockage ou transfert éventuel + coûts liés aux secrets et au réseau + temps d’intégration.
Pour le Mac autogéré :
TCO autogéré = matériel ou location + hébergement + alimentation et connectivité + licences + administration + maintenance + validation des mises à jour + capacité inactive + pertes liées aux incidents.
Les variables doivent être remplies avec une facture Buildkite, un devis ou un relevé interne. La location d’un Mac ne doit pas être présentée comme moins chère par principe : elle peut déplacer le coût d’achat et de maintenance vers une dépense récurrente, tout en apportant une capacité de remplacement ou une livraison plus rapide. Les modalités de commande Mac de NUKCLOUD doivent être consultées pour la période, la livraison et les conditions réellement disponibles au moment de l’étude.
| Profil de charge | Option généralement rationnelle | Coûts à surveiller | Preuve attendue |
|---|---|---|---|
| Charge stable toute l’année | Mac autogéré ou loué dédié | Capacité inactive, maintenance, remplacement | Historique de file et coût par artefact |
| Charge irrégulière | Agent hébergé | Consommation de pointe, attente, caches | Factures et temps d’attente par période |
| Pics liés aux publications | Double file | Surcapacité temporaire et secrets | Scénario de pointe rejoué |
| Dépendances privées permanentes | Mac autogéré | Réseau, administration, sauvegarde | Test d’accès et journal d’incident |
| Signature de production critique | Nœud isolé autogéré | Contrôle d’accès et reprise | Révocation, restauration et redémarrage |
| Outils variables ou expérimentaux | Hébergé sous contrôle | Compatibilité d’image et nettoyage | Reproduction sur image déclarée |
L’analyse de sensibilité doit faire varier au moins trois paramètres : le volume de travaux, la durée moyenne et le niveau de pointe. Si le volume double temporairement, l’équipe doit savoir si elle préfère payer une capacité hébergée supplémentaire ou maintenir une réserve autogérée inutilisée. Si la durée augmente à cause de tests de simulateur, le temps d’attente peut devenir le facteur dominant. Si un incident de signature bloque une publication, le coût métier dépasse rapidement la différence de facture entre deux solutions.
05Le pilote à double file
Le pilote doit reproduire les travaux réels, et non un projet vide. Une file hébergée peut recevoir les validations de demandes de fusion et les tests sans secret de production. Une file autogérée, sur un Mac réel isolé, peut recevoir l’archive et la signature avec les dépendances privées nécessaires. Les deux files doivent utiliser des identifiants de projet et des règles d’affectation explicites.
Le protocole suivant permet une décision traçable :
- Inventorier les travaux. Pour chaque pipeline Buildkite, relever le type d’artefact, la version Xcode, le besoin de simulateur, le réseau requis, les secrets, la durée et la sensibilité du code.
- Créer les files séparées. Attribuer des étiquettes distinctes aux agents hébergés et autogérés, sans mécanisme de repli silencieux vers la mauvaise frontière de confiance.
- Construire l’image de référence. Déclarer macOS, Xcode, outils, crochets, variables, caches et certificats attendus ; comparer cette liste aux exigences Apple.
- Lancer les mêmes travaux. Rejouer des validations, des tests de simulateur, une archive et un scénario avec accès privé sur chaque capacité autorisée.
- Mesurer la file. Conserver temps d’attente, durée, échecs, reprises, cache froid et cache chaud, sans transformer une seule exécution en promesse de débit.
- Tester les incidents. Couper le réseau, interrompre un travail, redémarrer le Mac autogéré et vérifier la reprise ou la réaffectation.
- Calculer le TCO réel. Rapprocher la facture Buildkite, les coûts du Mac, le temps d’administration et le coût d’une capacité de secours.
- Décider avec des critères écrits. Maintenir l’hébergé si les contrôles et limites conviennent ; passer à l’autogéré si la sécurité, le réseau ou l’environnement l’exigent ; retenir le double dispositif si les charges mélangent élasticité et contrôle strict.
La décision est favorable au seul hébergé si aucun travail n’exige un accès privé permanent, une dépendance non disponible dans l’image ou une conservation stricte du trousseau. Elle est favorable au seul autogéré si la charge est stable, la version doit rester figée et l’équipe possède une procédure crédible de remplacement. Le double dispositif est le choix le plus défendable lorsque les validations sont nombreuses mais que la signature de production doit rester isolée.
06Questions d’achat à verrouiller
Avant de signer, l’équipe devrait demander les réponses écrites à ces points :
- Quelles images macOS et versions Xcode sont disponibles aujourd’hui, et comment les changements sont-ils annoncés ?
- Quelle est la frontière exacte entre le plan de contrôle Buildkite, l’agent et le Mac qui exécute le travail ?
- Quels secrets peuvent être injectés, pendant combien de temps, et comment leur révocation est-elle vérifiée ?
- Quel comportement est attendu lorsqu’un agent autogéré devient silencieux ?
- Les tâches longues, les caches et les artefacts sont-ils compatibles avec les limites publiées ?
- Quel accès réseau est requis, et quelles destinations peuvent être autorisées sans ouverture générale ?
- Comment le coût est-il calculé lorsque la charge passe d’un niveau stable à un pic de publication ?
- Quelle preuve de redémarrage distant et de capacité de remplacement sera conservée dans le dossier d’acceptation ?
Le choix ne doit pas être formulé comme une préférence abstraite pour le nuage ou pour le matériel. Il doit relier chaque catégorie de travail à une file, un niveau de confiance, une responsabilité d’exploitation et une ligne budgétaire.
Une infrastructure entièrement hébergée peut laisser l’équipe dépendante des images disponibles, des limites de capacité, de la connectivité vers les services privés et du nettoyage réellement garanti entre les travaux. Une infrastructure entièrement autogérée impose, à l’inverse, l’achat ou la location de réserve, la maintenance des versions Xcode, la surveillance du Mac, la reprise après panne et la gestion continue des certificats. Lorsque ces contraintes se rencontrent, louer auprès de NUKCLOUD un Mac distant contrôlable peut offrir une base de production plus simple à opérer qu’un matériel acheté mais sous-utilisé, à condition de valider les engagements de livraison, d’accès et de récupération dans le pilote.
La prochaine étape raisonnable consiste à router séparément les validations, les tests de simulateur et les signatures, puis à comparer les journaux Buildkite et les coûts réellement observés. Si la file autogérée doit rester disponible pour une charge de production, les responsables peuvent examiner les conditions d’assistance NUKCLOUD avant de définir les critères d’acceptation du Mac distant.