Combien de Mac faut-il pour des builds iOS parallèles avec GitHub Actions en 2026 ? Estimation selon la taille de l’équipe

Il n’existe pas de nombre universel de Mac pour les builds iOS parallèles avec GitHub Actions : mesurez d’abord les workflows macOS actifs, leur attente en file et leur durée d’occupation pendant une période représentative, puis augmentez la capacité par petits paliers. Cette méthode convient si l’objectif est de réduire une attente réellement récurrente, plutôt que de transformer un pic ponctuel en capacité permanente.

Cette estimation s’adresse aux petites équipes iOS qui hésitent à ajouter des exécuteurs, aux responsables de plusieurs dépôts qui doivent répartir la capacité et aux équipes plateforme qui gèrent des Runner auto-hébergés. Si les builds ne sont pas bloqués et que les retards sont rares, l’ajout de Mac n’est pas nécessairement la première mesure à prendre.

Projet individuel : comment estimer le besoin à partir des temps d’attente ?

Pour un projet individuel, la question n’est pas de savoir combien de builds un développeur peut lancer, mais si les exécutions se chevauchent assez souvent pour créer une file d’attente pénalisante. Une série de commits rapprochés peut provoquer un retard visible sans révéler un manque de capacité durable. À l’inverse, des attentes qui reviennent aux mêmes moments, par exemple après les demandes de fusion ou avant une livraison, méritent une analyse plus précise.

La première mesure consiste à reconstituer, pour chaque exécution, les événements et durées utiles : création du job, démarrage sur un Runner, fin du job, résultat et identité du Runner. L’API des jobs de workflows expose notamment des horodatages tels que created_at, started_at et completed_at, ainsi que des informations sur le Runner et le résultat. Ces champs permettent de distinguer l’attente avant démarrage du temps passé à exécuter le job, au lieu de traiter la durée totale comme un bloc unique. Consultez la documentation de l’API des jobs de workflows pour vérifier les données disponibles.

Calculez ensuite, à partir des horodatages, le délai entre création et démarrage, puis la durée d’occupation entre démarrage et fin. Relevez également combien de jobs macOS se chevauchent pendant les périodes où l’attente devient gênante. Ce relevé permet de différencier trois situations : une file inhabituelle après des lancements groupés, une capacité généralement suffisante avec quelques pointes, ou un engorgement fréquent qui coïncide avec une occupation élevée des exécuteurs.

Pour éviter de dimensionner sur une journée atypique, choisissez une période représentative de l’activité du dépôt et comparez ses différentes plages de travail. Notez les commits ou campagnes de tests exceptionnels, les tâches relancées après échec et les changements de cache. Une compilation froide, une tâche de publication et un test unitaire n’occupent pas nécessairement un Runner de la même manière ; une moyenne générale peut donc masquer l’origine du retard.

Une file qui apparaît juste après une série de commits n’est pas, à elle seule, un motif d’achat ou de location. Vérifiez si l’attente revient dans les périodes habituelles et si les exécuteurs sont réellement occupés au moment du blocage.

Si les données montrent une attente occasionnelle, gardez la capacité actuelle et continuez la mesure lors d’une autre période comparable. Si elles révèlent un blocage répétitif, essayez une augmentation limitée, puis vérifiez que le temps avant démarrage diminue sans dégradation du taux de réussite. Une seule compilation lente, sans information sur les autres jobs, ne permet pas de conclure que le nombre de Mac est insuffisant.

Petite équipe : faut-il dimensionner les Mac selon la moyenne ou le pic ?

Le nombre de personnes dans une équipe ne donne pas directement le nombre de Mac requis. Des membres peuvent travailler sur des tâches différentes, tandis qu’un seul événement — une intégration fréquente ou une validation de livraison — peut lancer plusieurs workflows en même temps. Le bon indicateur est donc le chevauchement réel des jobs macOS et le délai d’attente que l’équipe juge acceptable.

Pour l’estimer, séparez les déclencheurs : push, demande de fusion, exécution planifiée et publication. Repérez les plages où ils se concentrent, puis comparez l’attente à la durée d’occupation observée pour chaque type de tâche. Le nombre de jobs demandés au même moment décrit une pression de pointe ; il ne signifie pas automatiquement que tous ces jobs doivent disposer en permanence d’un exécuteur dédié. Une partie peut attendre sans conséquence si l’équipe accepte ce délai.

La capacité visée dépend donc d’un compromis explicite. Si les développeurs ont besoin d’un retour rapide sur chaque modification, une file courte devient plus importante. Si le contrôle complet ne bloque pas le travail en cours, une attente plus longue peut être acceptable, notamment pour les tâches planifiées ou les validations qui s’exécutent en arrière-plan. Ces choix doivent être discutés avec les personnes qui utilisent les résultats, et non déduits uniquement de la taille de l’équipe.

La configuration concurrency de GitHub Actions sert à contrôler les exécutions appartenant à un même groupe de concurrence. La documentation précise le comportement de ces groupes, notamment la gestion des exécutions en cours et en attente. Il faut donc vérifier que le contrôle de concurrence défini dans les workflows correspond au comportement souhaité avant d’attribuer chaque attente à un manque de Mac : une règle peut elle-même limiter les exécutions autorisées. Les règles de concurrence des workflows et des actions décrivent ce mécanisme.

Pour une estimation réutilisable, définissez une durée de mesure, un seuil d’attente acceptable et les workflows à inclure. Relevez ensuite le nombre de jobs macOS simultanés au moment où le seuil est dépassé. La capacité à tester doit couvrir ces chevauchements qui comptent pour l’équipe, pas la totalité des lancements observés sur une période prolongée. Il ne s’agit pas d’une garantie de plateforme : c’est une règle de décision construite à partir des données propres au dépôt.

Pour formaliser le calcul, notez A(t) le nombre de jobs macOS prêts à démarrer à un instant donné et O(t) le nombre de jobs effectivement en cours. La différence entre ces valeurs signale une demande non servie à cet instant. Le délai entre création et démarrage indique combien de temps cette demande est restée en attente. Étudiez les valeurs observées lorsque le délai dépasse votre seuil : ce sont elles, plutôt qu’une moyenne calculée sur toute la période, qui orientent la capacité à tester.

Plusieurs dépôts : comment répartir la concurrence macOS entre les projets ?

Dans un environnement multi-dépôts, un pool partagé peut absorber les pointes lorsque les projets ne construisent pas tous en même temps. Mais il ne convient pas à toutes les organisations : certains workflows peuvent nécessiter une séparation pour des raisons d’accès, de priorisation ou de configuration. Il faut donc décider à la fois de la capacité globale et des règles qui permettent à chaque job de sélectionner le bon Runner.

Commencez par classer les charges de travail plutôt que les dépôts seuls. Distinguez les tests rapides, les constructions complètes et les tâches de publication. Pour chacune, consignez le dépôt, le workflow, les étiquettes demandées, les périodes de lancement et la durée d’occupation. Une tâche courte exécutée souvent peut contribuer fortement à la file ; une publication plus longue peut, elle, occuper un exécuteur pendant un intervalle plus étendu. Sans cette séparation, le volume total des workflows n’indique pas la nature du blocage.

Les groupes de Runner permettent d’organiser les exécuteurs et de contrôler quels dépôts peuvent les utiliser. La documentation officielle explique les règles d’accès et la sélection des groupes : vérifiez-les avant de fusionner des capacités jusque-là séparées ou de créer des pools réservés. Les groupes de Runner GitHub Actions aident à définir cette organisation. La configuration d’un workflow doit aussi demander un Runner dont les étiquettes et les critères de sélection correspondent à ceux disponibles, comme le décrit la syntaxe des workflows, dont runs-on.

Un job en attente ne prouve pas à lui seul que le pool partagé manque de capacité. Vérifiez si un Runner éligible est libre, si le job demande les bonnes étiquettes et si le dépôt a accès au groupe prévu. Les consignes sur les Runner auto-hébergés et leur sélection permettent de contrôler les critères pertinents. Les paramètres disponibles et les limites de la plateforme doivent être vérifiés dans la documentation GitHub en vigueur ; il ne faut pas supposer un quota ou une capacité identique pour toutes les organisations.

Pour un pool partagé, suivez aussi l’attente par dépôt et par type de tâche. Si un seul projet monopolise souvent les exécuteurs et retarde tous les autres, une règle d’accès, une séparation de groupe ou une priorité opérationnelle peut être plus appropriée qu’une augmentation uniforme. À l’inverse, si les pointes ne coïncident pas et que les dépôts peuvent utiliser les mêmes Runner, une capacité commune peut éviter de réserver des exécuteurs qui restent inactifs. Cette décision se vérifie à partir des données de tous les projets concernés, pas en extrapolant un dépôt isolé.

Responsable plateforme : comment distinguer un manque de Runner d’une étape mal conçue ?

Avant d’augmenter le nombre d’exécuteurs, examinez le chemin suivi par les jobs. Une attente qui se termine lorsque le job est attribué à un Runner pointe vers un problème de capacité ou de sélection. Une durée d’exécution anormalement élevée après le démarrage appelle plutôt une analyse des étapes, des dépendances, des scripts et du cache. Des échecs répétés peuvent aussi provoquer des relances et accroître la pression, sans que l’ajout de machines corrige la cause initiale.

Pour chaque workflow concerné, comparez les horodatages de création, de démarrage et de fin avec son résultat, le Runner attribué et les étiquettes demandées. Vérifiez ensuite le fichier de workflow pour repérer les dépendances entre jobs et les parties volontairement exécutées en série. Consultez aussi les recommandations GitHub pour surveiller et dépanner les Runner auto-hébergés : elles permettent de contrôler les problèmes de fonctionnement et de connectivité qui peuvent ressembler à une pénurie.

Voici une procédure de vérification avant toute extension du pool :

• [ ] Les données couvrent une période représentative, y compris les périodes où l’attente est la plus gênante.
• [ ] Les workflows macOS sont séparés selon leur rôle : tests, construction complète ou publication.
• [ ] Les temps avant démarrage sont distingués des temps d’occupation.
• [ ] Les jobs attendus demandent des étiquettes disponibles et un groupe auquel leur dépôt a accès.
• [ ] Les règles de concurrence et les dépendances entre jobs sont conformes au comportement attendu.
• [ ] Les tâches relancées, les échecs, les compilations froides et les changements de cache sont identifiés.
• [ ] L’équipe a défini un seuil d’attente acceptable avant de tester une capacité supérieure.
• [ ] Après l’essai, l’attente, l’occupation et les échecs sont comparés aux données de départ.

Cette procédure permet d’éviter une erreur fréquente : ajouter des Mac alors qu’un workflow n’est pas routé vers eux, qu’une règle limite les lancements ou qu’une étape séquentielle allonge le cycle. Si les jobs restent en attente malgré des Runner disponibles, examinez les étiquettes, les groupes et les accès. Si les exécuteurs sont bien attribués mais que la construction reste lente, optimisez les étapes concernées et mesurez à nouveau avant de revoir la capacité.

Décision de capacité : comparer les options avant de généraliser

Le tableau ci-dessous ne fixe aucun quota ni nombre de machines : il associe les symptômes mesurés à une décision de test. La capacité à retenir est celle qui respecte le seuil d’attente choisi par l’équipe dans ses propres conditions, et non un chiffre transféré d’un autre projet.

Situation mesurée	Décision à tester	Contrôle après le changement
Attente rare après des lancements groupés, sans blocage récurrent	Conserver la capacité et poursuivre la mesure sur une période comparable	Vérifier si l’attente se reproduit et si elle gêne réellement les validations
Attente fréquente quand plusieurs jobs sont prêts, avec les Runner occupés	Ajouter une capacité limitée pendant une période d’essai	Comparer délai avant démarrage, occupation et résultats des jobs
Jobs en attente alors que des Runner semblent disponibles	Corriger la sélection, les étiquettes, l’accès au groupe ou les règles de concurrence	Confirmer que les jobs sont attribués aux exécuteurs attendus
Jobs attribués rapidement, mais temps d’exécution élevé	Examiner les étapes lentes, les dépendances et le comportement du cache	Mesurer séparément le temps d’attente et le temps d’occupation
Plusieurs dépôts se bloquent en même temps	Tester un pool partagé si l’accès et les configurations le permettent	Suivre l’attente par dépôt afin de repérer une concurrence déséquilibrée

Lors d’un essai, n’augmentez pas simultanément la capacité et plusieurs paramètres de workflow. Si tout change à la fois, une amélioration ou une dégradation devient difficile à attribuer. Gardez une période de comparaison, consignez les changements et vérifiez que les tâches attendues utilisent effectivement les nouveaux exécuteurs. Si le délai ne s’améliore pas, revenez à l’analyse du routage, des dépendances et des étapes ; ne poursuivez pas les ajouts par défaut.

Les coûts des appels à des modèles d’IA ne doivent pas être mélangés aux coûts des ressources de construction macOS. Les premiers dépendent de l’usage des services concernés ; les seconds dépendent du mode de mise à disposition des Mac, de leur durée d’utilisation et des conditions contractuelles applicables. Une estimation de CI doit conserver ces postes distincts, puis comparer le coût d’une capacité permanente avec celui d’une capacité utilisée seulement pendant des périodes où le besoin est établi. Aucun montant générique ne permet de trancher à la place des conditions réelles d’un projet.

Pour transformer le besoin mesuré en choix d’exploitation, comparez l’achat de Mac, une capacité locale et la location à distance selon la durée prévue, la nécessité d’un accès physique, la maîtrise du matériel et les pointes de charge. Une charge soutenue et stable peut justifier l’évaluation d’un parc détenu en propre ; un besoin temporaire ou variable mérite plutôt un essai à durée limitée. Pour étudier une offre de location, consultez les informations effectivement publiées par Zutcloud sur ses Mac disponibles à Singapour et vérifiez les conditions actuelles avant de prendre une décision. La documentation du centre d’aide Zutcloud peut également servir à clarifier les modalités de mise en œuvre.

Si la capacité existante suffit la plupart du temps, que les pointes sont rares et qu’aucun seuil d’attente n’est dépassé durablement, conserver l’organisation actuelle reste un choix mesuré. Si les données montrent des blocages réguliers et que le routage est correct, une location de Mac Zutcloud peut permettre d’essayer une capacité distante sans transformer immédiatement un besoin de pointe en parc permanent. Les équipes dont la charge est durablement élevée ou qui ont besoin d’interfaces physiques doivent, elles, comparer sérieusement cette option à des Mac détenus sur site ; dans tous les cas, la décision gagne à partir des mesures de GitHub Actions, puis des conditions réelles de disponibilité et de livraison.

À lire aussi

• Choisir entre Xcode Cloud et une ferme de build Mac distante pour une équipe iOS
• Accélérer les builds iOS parallèles avec des nœuds cloud M4