Avant le retrait de GitHub Actions macOS-14, comment calculer le budget CI d’entreprise ? 2026

Pour établir le budget CI d’entreprise avant le retrait de GitHub Actions macOS-14, ne choisissez pas une solution sur le seul tarif à la minute : séparez d’abord les tâches qui exigent macOS, puis chiffrez l’usage réel, les quotas, l’exploitation et les conditions d’accès. Si vos données le confirment, commencez par répartir les tâches et combinez plusieurs environnements ; n’élargissez le parc autogéré ou loué qu’après un essai représentatif.

Cette analyse s’adresse aux responsables IT et plateforme qui doivent fixer les limites de la solution de remplacement, aux équipes FinOps et achats qui rapprochent factures et coûts d’exploitation, ainsi qu’aux responsables CI/CD qui doivent déterminer quels travaux peuvent quitter macOS.

Dernière vérification : 27 octobre 2026. La date et les étiquettes concernées ont été vérifiées dans l’annonce officielle de GitHub sur le retrait de macOS-14. Les règles de facturation doivent être revérifiées avant décision dans la documentation de facturation GitHub Actions et la référence tarifaire des Runner Actions.

Pour l’IT, fixer le périmètre du budget avant de choisir un remplaçant

GitHub a annoncé le retrait de l’image macOS 14 le 2 novembre 2026. Les étiquettes citées dans l’annonce sont macos-14, macos-14-large et macos-14-xlarge ; GitHub indique également qu’une réduction de capacité avant le retrait pourrait allonger les délais d’attente. Ces éléments sont des annonces officielles, pas la preuve que votre organisation subit déjà des retards ou paie davantage. Vérifiez les conséquences sur vos propres exécutions dans l’annonce de retrait.

Le budget à construire porte sur la capacité qui remplacera les tâches affectées, pas sur le coût d’une migration de version ou sur un plan de dépannage. Gardez ces sujets distincts : le remplacement du Runner peut exiger des adaptations techniques, mais les mélanger aux dépenses d’hébergement empêche de comparer correctement les options.

Pour délimiter l’analyse, partez des workflows qui déclarent une des étiquettes concernées, puis confrontez cette liste aux journaux d’exécution et aux dépendances réelles. L’étiquette runs-on indique où le travail est demandé ; elle ne suffit pas à démontrer que toutes les étapes de ce travail doivent s’exécuter sur un Mac. Les critères de sélection des environnements sont détaillés dans la documentation GitHub sur le choix du Runner d’un job.

Pour la plateforme CI, isoler les tâches qui ont réellement besoin de macOS

La décision de capacité se prend au niveau des jobs et de leurs dépendances, pas au niveau du nom du pipeline. Examinez les commandes, les outils, les fichiers produits et les prérequis de chaque job ; consignez aussi le Runner employé, la durée observée et l’importance du job pour une livraison.

Classez les tâches selon leur fonction :

• Compilation Apple : une compilation qui utilise Xcode ou une chaîne d’outils macOS dépend d’un environnement Mac compatible. Relevez la configuration effective et les artefacts produits, plutôt que de déduire le besoin du seul nom du dépôt.
• Tests avec simulateur : les tests qui lancent le simulateur iOS requièrent un environnement capable de fournir ces outils et ressources. Mesurez leur durée séparément : leur profil peut différer de celui de la compilation.
• Signature et publication : les étapes qui utilisent des certificats, des profils ou le trousseau demandent une attention particulière aux accès et au contexte d’exécution. Elles ne se déplacent pas comme de simples tâches de compilation sans vérification des contrôles.
• Contrôles génériques : vérifications de format, analyse de fichiers, calculs indépendants de Xcode, préparation de versions ou contrôles de dépendances peuvent être de bons candidats à la répartition, si leurs scripts ne dépendent pas d’outils macOS.
• Tâches mixtes : séparez les étapes indépendantes dans des jobs différents lorsque les artefacts, les secrets et les dépendances le permettent. Mesurez le coût éventuel du transfert des artefacts et ses effets sur la durée totale du pipeline.

N’attribuez pas une proportion de tâches à chaque catégorie sans preuve. Les journaux, les fichiers de workflow et les scripts doivent étayer le classement ; gardez les tâches ambiguës à part jusqu’à validation. Cette analyse permet de distinguer les tâches pour lesquelles un GitHub Actions macOS Runner est indispensable de celles qui peuvent être exécutées ailleurs.

Pour FinOps, bâtir un modèle que vous pouvez recalculer

Le prix affiché d’un Runner ne suffit pas à établir le coût d’une période. La facture peut dépendre des minutes effectivement facturées, de la catégorie de Runner, des quotas ou allocations applicables à votre compte et d’autres postes couverts par les règles de facturation. Vérifiez la définition en vigueur dans la documentation de facturation GitHub Actions et dans la référence tarifaire des Runner ; ne figez pas dans un prévisionnel un tarif ou une règle que votre compte ne confirme pas.

Pour chaque groupe de workflows, réunissez les variables suivantes :

• le nombre d’exécutions sur la période retenue, à partir de l’historique plutôt que d’une moyenne supposée ;
• la durée réellement facturée par exécution, distincte du temps total ressenti par un développeur ou du temps passé dans la file ;
• le type et l’étiquette du Runner, en vérifiant la correspondance entre la configuration du workflow et la facturation ;
• les quotas, allocations ou dépassements qui apparaissent sur la facture de l’organisation ;
• les autres dépenses directement liées, comme le stockage ou les artefacts, lorsqu’elles sont effectivement facturées ;
• la charge d’administration, le coût d’inactivité et les exigences de reprise, estimés séparément pour les solutions autogérées ou louées.

Une estimation par mois peut s’écrire ainsi :

Coût mensuel estimé = coût des exécutions facturées + dépenses associées mesurées + coût d’exploitation estimé.

Pour passer à une projection annuelle, additionnez les coûts mensuels prévus sur la période de planification et explicitez les hypothèses de changement de charge, de tarif et de capacité. Ne multipliez pas simplement un mois atypique par douze si les lancements, les publications ou les périodes de test font varier l’usage. Présentez les résultats mesurés et les hypothèses dans des colonnes distinctes : le service achats pourra ainsi distinguer une facture constatée d’un effort de travail évalué en interne.

Testez ensuite la sensibilité du modèle : que devient le budget si le nombre de compilations augmente, si les tests de simulateur durent davantage, ou si une partie des contrôles génériques est déplacée ? Utilisez vos propres valeurs de facturation et de journaux pour chaque scénario. Sans données internes, aucun montant ni pourcentage d’économie ne serait crédible.

Pour l’exploitation, comparer les responsabilités et le coût complet

La comparaison utile ne se limite pas à la ligne « calcul ». Elle doit inclure le niveau de contrôle souhaité, la capacité inutilisée, les interventions nécessaires et la manière de reprendre le service après une indisponibilité.

• Runner macOS hébergé — L’ajustement des ressources est souvent simple lorsque la demande varie et que l’organisation veut éviter l’administration du matériel. En contrepartie, vous dépendez des environnements proposés, des règles de facturation et de la disponibilité du service. Vérifiez les quotas, les caractéristiques des Runner et les conditions applicables à votre compte dans la documentation des Runner plus grands et la documentation tarifaire officielle. Ne traitez pas une éventuelle attente en file annoncée avant le retrait comme une dépense déjà réalisée.
• Mac autogéré avec Runner auto-hébergé — Vous maîtrisez le matériel, les outils installés et les règles locales, mais la capacité est limitée à ce que vous administrez. Votre équipe prend en charge l’hôte, les mises à jour, la surveillance, les accès et la remise en service. La documentation des Runner auto-hébergés aide à valider le fonctionnement et les contraintes du modèle ; elle ne permet pas de supposer que l’isolation ou la sécurité sont automatiques.
• Mac distant loué — Cette option peut convenir à une charge qui exige un véritable environnement Mac sans achat immédiat de matériel, sous réserve de vérifier les disponibilités, les conditions contractuelles et les mécanismes d’accès réellement proposés. L’équipe doit toujours traiter les identités, les secrets, les mises à jour logicielles, les journaux et la reprise, selon le service retenu. N’inscrivez au modèle que les configurations, durées, tarifs et conditions que vous pouvez confirmer.
• Approche hybride — Les jobs non dépendants de macOS peuvent rester sur d’autres environnements, tandis que les compilations, les tests avec simulateur et les publications admissibles utilisent une capacité Mac. Vous devrez maintenir plusieurs chemins de pipeline, contrôler le transfert des artefacts et vérifier que les identifiants ne deviennent pas plus largement accessibles.

Pour évaluer ces options, attribuez à chacune une appréciation explicite selon les mêmes critères : flexibilité, charge d’administration, coût d’inactivité, contrôle de l’environnement et reprise après incident. Une appréciation « forte », « moyenne » ou « faible » n’est utile que si vous notez les éléments qui la justifient. Le coût d’une machine achetée est une dépense observable ; les heures d’administration et le risque de capacité insuffisante sont des variables distinctes à estimer, et non des montants qu’on peut remplacer par le prix d’achat.

Un Runner auto-hébergé ou un accès distant ne garantit pas à lui seul l’isolation des tâches. Vérifiez les droits de l’hôte, les secrets accessibles, les utilisateurs autorisés et les possibilités de nettoyage après chaque exécution avant d’approuver le scénario.

Pour la sécurité, éliminer d’abord les options incompatibles

La sécurité peut être une condition bloquante, et non une simple ligne du budget. Avant de comparer les coûts, consignez les exigences de réseau privé, l’accès aux dépôts et aux services internes, la conservation des certificats de signature, les droits d’administration et le niveau d’isolement requis entre projets ou équipes.

Pour chaque solution, posez des questions vérifiables : qui peut administrer l’hôte ? Quel compte exécute les jobs ? Quels secrets sont accessibles dans le contexte de chaque job ? Les tâches non fiables peuvent-elles accéder au trousseau ou à des ressources persistantes ? Comment l’équipe révoque-t-elle les accès et récupère-t-elle le service après incident ? Les réponses doivent venir de votre architecture et des conditions effectivement documentées, pas de l’étiquette du Runner ou de l’expression « Mac distant ».

Chiffrez séparément les contrôles supplémentaires que votre politique impose : segmentation réseau, gestion des secrets, surveillance, sauvegarde ou intervention d’un administrateur. Si une option ne permet pas de satisfaire une exigence obligatoire, retirez-la de la comparaison financière principale ; son coût théorique ne la rend pas admissible.

Pour les achats, appliquer une grille de décision avant d’étendre la capacité

Cochez les conditions qui correspondent à vos journaux, à vos factures et à vos règles de sécurité. Pour chaque ligne, retenez l’action indiquée ; si la condition n’est pas démontrée, ne généralisez pas l’option et revenez à un essai ou à la répartition des tâches.

• [ ] Les jobs utilisent Xcode, un simulateur iOS ou un outil macOS indispensable. Gardez ces jobs sur une capacité Mac compatible ; si cette dépendance n’est pas confirmée, vérifiez les scripts avant d’affecter un Runner Mac.
• [ ] La charge varie et l’équipe ne veut pas exploiter les hôtes. Privilégiez les Runner hébergés pour les tâches admissibles, puis contrôlez la facture et les règles applicables à votre organisation.
• [ ] Les journaux montrent une charge Mac régulière et une équipe peut gérer le matériel. Comparez un Mac autogéré au coût complet, en intégrant l’inactivité, la maintenance, les accès et la reprise.
• [ ] Un environnement Mac est nécessaire, mais l’achat immédiat n’est pas souhaité. Évaluez un Mac distant ; avant de l’inclure dans le budget, vérifiez la configuration, la durée de location, le tarif et les modalités d’accès effectivement publiés.
• [ ] Une exigence de signature, d’isolation ou de réseau exclut une solution. Écartez cette solution, même si son coût apparent est inférieur, ou révisez le découpage des jobs avant de refaire la comparaison.
• [ ] Les relevés ne suffisent pas à départager les options. Lancez un essai limité, mesurez les mêmes critères pour chaque environnement et ne validez une extension qu’après revue des résultats.

Cette grille fournit une décision conditionnelle : si une case est étayée par des éléments observés, appliquez l’action correspondante ; si elle ne l’est pas, ne la traitez pas comme une hypothèse acquise. En particulier, un Runner auto-hébergé ne devient pas moins coûteux simplement parce que le prix d’achat du matériel est connu, et une location n’est pas avantageuse sans tarifs et conditions vérifiés.

Pour qu’un essai soit utile, choisissez des workflows qui couvrent les cas ayant un effet réel sur la facture et la livraison : compilation, tests avec simulateur, signature et tâches candidates à la répartition. Relevez les durées facturées, les files d’attente observées, les interruptions, le temps d’administration et les incidents d’accès. Fixez une date de revue dans votre calendrier interne, puis comparez les observations au modèle initial ; arrêtez l’essai si une exigence de sécurité n’est pas satisfaite ou si les mesures nécessaires ne peuvent pas être recueillies.

Pour examiner une option de location sans introduire de prix supposé, consultez les configurations Mac publiées par VPSMAC, puis vérifiez les informations disponibles au moment de votre décision. La présentation des services Mac de VPSMAC peut également vous aider à repérer les informations à confirmer sur l’accès et les modalités proposées. N’ajoutez aucune configuration ou durée au prévisionnel avant de l’avoir vérifiée.

Questions fréquentes sur le budget CI après macOS-14

Comment recalculer le budget CI après le retrait de macOS-14 ?

Repartez des exécutions enregistrées, pas du seul tarif affiché par minute. Pour chaque workflow, relevez le Runner utilisé, la durée facturée, la fréquence et les frais associés, puis séparez les tâches qui exigent réellement macOS de celles qui peuvent être exécutées ailleurs. Appliquez ensuite les règles de facturation et les quotas en vigueur pour votre organisation, et comparez les coûts avec l’exploitation des autres solutions.

Quels travaux iOS peuvent quitter un Runner Mac ?

Les tâches qui appellent Xcode, compilent une application Apple, utilisent un simulateur iOS ou signent et publient un binaire doivent rester dans un environnement Mac compatible. En revanche, l’analyse de sources générique, la validation de fichiers, certains contrôles de dépendances et la préparation de livrables peuvent parfois être déplacés. Vérifiez les scripts et les dépendances effectives avant de décider : l’étiquette du workflow, à elle seule, ne prouve pas qu’il nécessite macOS.

Quels coûts comparer entre Runner hébergé, Mac autogéré et Mac distant ?

Comparez les frais directement facturés, mais aussi l’achat ou la location de la machine, les périodes d’inactivité, la maintenance, la supervision, les mises à jour, la sécurité et la reprise après incident. Distinguez les montants constatés sur les factures des heures de travail estimées par votre équipe. Un achat matériel ne représente pas le coût total si vous devez également gérer l’accès, les sauvegardes, la capacité disponible et le remplacement.

Faut-il compter le temps d’inactivité et les heures d’exploitation ?

Oui, dès lors que ces éléments mobilisent une ressource payée ou une capacité réservée à votre équipe. Pour une machine dédiée, mesurez les heures d’exécution et celles où elle reste disponible sans traiter de tâche ; pour toute option, estimez séparément les interventions de maintenance, d’administration et de sécurité. Si vous ne disposez pas de relevés fiables, inscrivez ces éléments comme hypothèses à valider plutôt que de les présenter comme des dépenses déjà mesurées.

Pour votre arbitrage final, les Runner hébergés peuvent laisser une dépendance aux règles de facturation, aux quotas et à la capacité disponible ; un Mac acheté immobilise du capital et demande une exploitation continue ; un environnement distant exige encore de valider l’accès, la sécurité et les conditions du service. Si votre besoin est temporaire ou variable, comparez la location d’un Mac avec ces options : elle peut éviter l’achat d’une capacité qui resterait inutilisée, sans garantir pour autant une économie. Vérifiez les conditions et les tarifs que VPSMAC publie actuellement avant de retenir cette hypothèse ; si votre charge est durable, prévisible et fortement administrée en interne, comparez aussi l’achat et l’exploitation sur le même modèle complet.