Comment estimer le nombre de Mac de compilation pour le CI/CD iOS d’équipe ? Planification de capacité 2026

Verdict rapide

Adapté : si vous devez dimensionner une file de compilation iOS, estimez le nombre de Mac à partir du rythme d’arrivée des travaux, de leur durée, des pics de concurrence et de l’attente tolérée, puis confirmez votre hypothèse par un essai représentatif. Inadapté : si vous cherchez une conversion directe entre effectif et machines ; ce ratio ne décrit pas votre charge CI réelle. Une charge régulière peut justifier une capacité fixe, tandis qu’un pic ponctuel mérite d’être évalué séparément avant d’ajouter une capacité extensible.

Cet article s’adresse aux responsables techniques qui planifient la capacité CI/CD d’une équipe iOS, aux responsables IT dont les travaux s’accumulent dans la file et aux personnes qui comparent achat fixe et capacité à la demande.

Point de départ : les traces de votre Mac de compilation

Avant de chercher combien de machines ajouter, déterminez si le ralentissement vient d’un manque de capacité, d’une tâche particulière ou des règles de planification. Le nombre de développeurs ne permet pas de trancher : une équipe peut lancer peu de travaux simultanés, tandis qu’un flux de demandes de fusion, de tests et d’archivages peut générer une pointe d’activité concentrée.

Rassemblez les événements de votre plateforme CI dans un export exploitable. Pour chaque tâche, relevez l’heure de déclenchement, l’heure de début réel d’exécution et l’heure de fin ; ajoutez le type de travail, son résultat, les éventuelles relances et l’agent qui l’a prise en charge. Vous obtenez ainsi trois mesures issues de vos propres traces : la durée en file, le temps d’exécution et la fréquence des échecs ou des reprises. Ce sont des données de votre environnement, pas des valeurs génériques à recopier.

Classez ensuite les travaux selon leur rôle. Une vérification rapide à chaque demande de fusion n’a pas les mêmes conséquences qu’une suite de tests complète ou qu’un archivage destiné à une livraison. Les actions de construction, de test, d’analyse et d’archivage font partie des étapes documentées dans les actions de flux de travail Xcode. Les instructions Apple sur les flux CI qui construisent des paquets Swift ou des applications qui les utilisent donnent également un point de repère pour identifier les tâches à suivre.

Ne regroupez pas les résultats en une moyenne unique. Distinguez les périodes ordinaires, les fenêtres de publication et les moments où plusieurs équipes ou dépôts sollicitent les agents en même temps. Une moyenne peut sembler acceptable alors que les travaux urgents attendent précisément au moment où les développeurs ont besoin d’un retour rapide.

Estimation du besoin à partir des périodes d’activité

Votre hypothèse de capacité doit répondre à deux questions différentes : quelle concurrence faut-il absorber de manière habituelle, et quel délai de retour est acceptable pour chaque type de travail ? Les réponses dépendent de vos objectifs internes. Un contrôle de demande de fusion peut être jugé sensible au délai, alors qu’une tâche planifiée sans intervention immédiate peut parfois attendre davantage.

Pour établir cette hypothèse, observez les déclenchements pendant les périodes qui comptent pour l’équipe. Relevez les travaux qui se chevauchent, leur durée réelle et le temps d’attente avant démarrage. Comparez ensuite ces observations au délai que vous avez défini avec les équipes de développement. Si plusieurs tâches longues démarrent ensemble et que les agents sont occupés, la concurrence est probablement un facteur important. Si une tâche isolée passe soudainement beaucoup plus de temps à s’exécuter, ajouter un Mac ne résoudra pas nécessairement la cause.

La capacité ne se résume donc pas à une formule universelle. Un modèle de calcul qui multiplie un effectif par un coefficient fixe masquerait la fréquence des déclenchements, les différences entre tâches et les heures de pointe. À la place, documentez les hypothèses sous une forme que vous pourrez confronter aux résultats :

les catégories de travaux à protéger contre une attente excessive ;
les périodes où les tâches arrivent simultanément ;
la durée habituelle et les variations constatées pour chaque catégorie ;
le délai d’attente que votre équipe juge acceptable ;
les travaux qui peuvent être différés sans bloquer une livraison ou une validation.

Cette liste devient votre référence de test. Elle vous évite de confondre un pic ponctuel avec une demande durable et de commander une capacité permanente pour corriger un problème de courte durée.

Traduction de la concurrence en agents Mac disponibles

Une tâche qui attend n’indique pas automatiquement qu’il manque une machine. Vérifiez d’abord combien de travaux peuvent effectivement démarrer en parallèle selon les limites de la plateforme CI, les groupes ou étiquettes d’agents, les règles propres aux dépôts et les autorisations d’accès. Un Mac disponible mais exclu du groupe auquel une tâche est affectée n’augmente pas la capacité utilisable de cette file.

Si votre équipe utilise GitHub Actions, sa documentation distingue notamment l’administration des agents auto-hébergés et la configuration des flux de travail et de leur concurrence. Servez-vous-en pour examiner votre configuration dans cette plateforme ; ne transposez pas ses règles à un autre ordonnanceur. Les mécanismes de concurrence, de regroupement et d’affectation varient selon l’outil employé.

Option de capacité	Ce qu’elle couvre bien	Points à vérifier avant décision	Quand elle mérite un essai
Capacité fixe	Une charge régulière qui occupe durablement les agents	Coût récurrent réel, maintenance, mises à jour, disponibilité hors pointe et règles d’accès	Les files persistent pendant les périodes ordinaires et les travaux utiles sont régulièrement en attente
Capacité fixe avec tâches mieux planifiées	Une charge stable perturbée par des chevauchements évitables	Priorités, affectation par étiquette, tâches redondantes, réservations d’agents et possibilités de décaler les travaux non urgents	Des agents sont parfois disponibles alors que certaines files restent bloquées
Capacité fixe complétée à la demande	Une base prévisible avec des pointes limitées dans le temps	Délai de mise à disposition, configuration de l’environnement, compatibilité des tâches, accès et prix réellement proposés	Les pics sont identifiables, mais ne justifient pas des machines permanentes supplémentaires
Augmentation durable de la capacité fixe	Une demande plus élevée qui persiste au-delà des pointes	Utilisation observée, tâches déplacées ou évitées, entretien et coût total	Les mesures et les essais confirment un besoin régulier, et non seulement un problème temporaire

Pour des machines Mac hébergées à distance, la région et la disponibilité effective des configurations influencent également la pertinence opérationnelle. Vous pouvez consulter les configurations Mac disponibles pour vérifier les options réellement publiées ; ne déduisez pas du seul nom d’une configuration qu’elle conviendra à vos compilations ou à vos contrôles d’accès. Votre tâche représentative reste nécessaire.

Questions fréquentes sur les capacités de compilation

Faut-il partir du nombre de développeurs ? Non. Utilisez les effectifs comme un indice pour anticiper l’évolution possible des déclenchements, mais établissez la capacité avec les événements CI, la concurrence réellement observée et les délais acceptés.

Quelle attente justifie une extension ? Celle qui dépasse votre objectif défini pour une catégorie de tâche pendant des périodes significatives. Examinez aussi la disponibilité des agents et les règles d’affectation avant d’ajouter une machine.

Comment exploiter les journaux existants ? Reliez chaque déclenchement à son démarrage, sa fin, son résultat et ses reprises, puis séparez les types de travaux et les périodes d’activité.

Que faire des pointes de publication ? Vérifiez leur fréquence et leur durée. Si elles sont brèves, comparez une capacité complémentaire à une augmentation permanente, sans oublier le délai nécessaire pour préparer l’environnement.

Validation par un essai représentatif

Une estimation tirée des journaux reste une hypothèse tant qu’elle n’a pas été éprouvée avec des travaux comparables à ceux de l’équipe. Choisissez des tâches qui représentent les chemins importants : vérification rapide, compilation de branche principale, tests et archivage si ces opérations font partie de votre flux. La référence Apple des flux Xcode Cloud permet de recouper les étapes usuelles d’un flux Xcode ; elle ne fournit pas votre capacité cible, qui dépend de vos projets et de vos agents.

Réalisez un essai dans des conditions identifiables. Notez la version du projet, les types de travaux déclenchés, les règles d’affectation et la disponibilité des agents. Pendant le test, suivez séparément la durée d’attente, le temps d’exécution, les échecs, les relances et les signes de concurrence pour les ressources. Comparez ensuite chaque observation aux objectifs internes définis auparavant, au lieu de juger le résultat sur une impression générale.

Si l’attente reste excessive alors que les agents prévus sont occupés par des travaux utiles, essayez une capacité additionnelle ou réduisez le chevauchement, puis répétez le test avec un scénario comparable. Si les agents restent libres alors que les tâches attendent, examinez les groupes, les étiquettes, les limites de concurrence et les autorisations. La documentation Apple sur les variables d’environnement et identifiants d’action Xcode peut vous aider à vérifier les informations disponibles dans l’environnement d’exécution, mais elle ne remplace pas l’analyse des réglages de votre ordonnanceur.

Attribuez une note qualitative à chaque option avec les critères de votre équipe : respect des délais, stabilité des exécutions, charge d’exploitation et coût documenté. Une option qui améliore la file tout en ajoutant une procédure d’accès difficile à maintenir n’est pas forcément préférable à une correction de planification. À l’inverse, un agent supplémentaire ne doit pas être rejeté uniquement parce qu’il ne sert pas en permanence si les essais montrent qu’il répond à une pointe métier importante.

Révision continue et comparaison des coûts

La demande évolue : un changement de version Xcode, un projet supplémentaire, une matrice de tests élargie ou une modification des contrôles avant livraison peut changer la durée ou le chevauchement des travaux. La capacité ne devrait donc pas rester figée sur l’observation initiale. Réexaminez les mêmes indicateurs après un changement notable du flux de développement et comparez les périodes équivalentes, plutôt que d’attribuer automatiquement toute variation à un manque de Mac.

Pour comparer une capacité fixe à une capacité extensible, renseignez des postes provenant de vos devis et de votre comptabilité. Ne complétez pas les cellules avec des tarifs supposés : la comparaison dépend des offres réelles, des périodes de location disponibles et de l’usage que vous prévoyez.

Poste à renseigner	Capacité fixe	Capacité à la demande
Mise à disposition et coût d’acquisition ou de location	Montant du devis, selon votre durée d’engagement	Tarif publié ou proposé pour la période réellement disponible
Usage pendant les périodes sans pointe	Temps d’inactivité et coûts associés	Coût des périodes effectivement commandées
Maintenance et mises à jour	Temps d’administration, renouvellement et suivi de l’agent	Temps de préparation, de vérification et de retrait de l’agent
Préparation de l’environnement	Configuration initiale et maintien de l’image logicielle	Répétabilité de l’installation et disponibilité des outils requis
Accès et sécurité	Gestion des comptes, secrets, dépôts et séparation des tâches	mêmes vérifications, plus les conditions d’accès à la machine distante
Continuité du service	Procédure en cas d’indisponibilité ou de maintenance	Délai de disponibilité et solution de repli documentés
Capacité requise lors d’un pic	Agents maintenus disponibles en permanence	Coût réel de la capacité supplémentaire et délai pour l’obtenir

Pour chaque scénario, ajoutez votre volume CI observé, vos durées, vos attentes en période de pointe et les coûts effectivement vérifiables. Une capacité fixe est plus facile à justifier lorsque la charge utile est régulière et durable. Une option extensible mérite d’être examinée lorsque le besoin supplémentaire est ponctuel, à condition que la configuration et l’accès répondent aux exigences du pipeline. Les informations de fiabilité publiées par SDKMac peuvent servir à préparer les questions de disponibilité à vérifier ; elles ne remplacent ni un engagement contractuel ni la validation de votre propre flux.

Décision à partir de vos résultats

Au terme de l’analyse, vous devez pouvoir expliquer pourquoi une file s’allonge, quelles catégories de tâches en sont responsables et quelles mesures confirmeraient qu’un agent supplémentaire apporte une amélioration. Si les attentes proviennent d’un mauvais groupe d’agents, corrigez l’affectation avant d’augmenter le parc. Si la concurrence utile dépasse régulièrement la capacité disponible et que l’essai confirme un gain, comparez l’augmentation fixe à une capacité complémentaire selon les devis et conditions réels.

L’achat de Mac en propre peut convenir lorsque vous avez besoin d’un environnement physique durable, d’interfaces matérielles spécifiques ou d’un contrôle local qui ne peut pas être remplacé. En contrepartie, vous devez intégrer à votre décision l’immobilisation de matériel, sa maintenance, son renouvellement et les périodes où il reste peu sollicité. Une capacité distante mal préparée comporte, elle aussi, des contraintes : accès réseau, préparation de l’environnement, règles de sécurité et dépendance au délai de disponibilité. Le choix doit donc suivre vos essais et vos exigences, pas une promesse générique de coût ou de performance.

Une fois votre charge de base et vos pointes séparées, vérifiez les configurations et périodes de location proposées par SDKMac, puis confrontez-les à vos tâches représentatives, à vos besoins d’accès et à votre budget réel. Si une machine distante satisfait ces conditions, elle peut compléter votre capacité de pointe sans vous obliger à maintenir en permanence tout le parc nécessaire aux périodes les plus chargées.

Questions fréquentes

Comment déterminer combien de Mac de compilation une équipe iOS doit prévoir ?

Commencez par extraire les heures de déclenchement, la durée d’attente et le temps d’exécution des tâches depuis vos journaux CI. Séparez les contrôles de demandes de fusion, les compilations de branche principale, les tests et les archivages. Comparez les périodes de pointe et les périodes ordinaires, puis validez votre estimation avec des tâches représentatives avant d’ajouter des machines.

Faut-il dimensionner les Mac selon le nombre de développeurs ou les compilations simultanées ?

Le nombre de développeurs ne décrit pas directement la charge soumise au système : les habitudes de déclenchement, la répartition des tâches et leur durée comptent aussi. Utilisez la concurrence réellement observée, les files et le délai de retour attendu. Les effectifs peuvent aider à anticiper un changement d’activité, mais ils ne suffisent pas à fixer le nombre d’agents de compilation.

À partir de quel délai d’attente faut-il ajouter un agent Mac ?

Il n’existe pas de délai universel qui justifie à lui seul une extension. Définissez d’abord un délai acceptable pour chaque catégorie de tâche, puis comparez-le aux attentes observées pendant les périodes de pointe. Si le dépassement persiste alors que les agents sont occupés, testez une capacité supplémentaire ; si les agents restent disponibles, recherchez plutôt un problème de planification ou de configuration.

Quelles données des anciens travaux CI permettent d’estimer la capacité iOS ?

Conservez les heures de déclenchement, de prise en charge et de fin, la catégorie de travail, le temps passé en file, les échecs et les relances. Ces éléments permettent de distinguer une arrivée simultanée de tâches d’une exécution devenue plus lente. Analysez-les par période et par type de travail : une moyenne globale pourrait masquer les pics qui provoquent réellement l’attente.