Ne laissez pas le retrait annoncé de macOS 14 interrompre vos publications : mettez en place une migration parallèle, testez un Runner pris en charge et ne basculez qu’après validation de votre véritable chaîne de construction. Cette méthode convient aux équipes dont les workflows dépendent encore des étiquettes macOS 14 ; si le projet requiert un environnement durablement maîtrisé, évaluez ensuite un Mac distant.

Cet article s’adresse aux développeurs iOS ou macOS qui doivent vérifier la compatibilité de leur projet avec un nouvel environnement.
Il aide les équipes CI à comparer dépendances, caches et livrables sans confondre changement d’image et régression du code.
Les responsables de plateforme y trouveront des critères pour choisir entre Runner hébergé et environnement Mac contrôlé.

Dernière mise à jour : 7 octobre 2026. Les dates, étiquettes et modalités de retrait ont été vérifiées dans l’annonce officielle de GitHub. Les images et logiciels disponibles doivent être revérifiés dans les manifestes officiels des Runner avant la mise en production.

1. Dès l’annonce, repérez chaque dépendance à macOS 14

GitHub a annoncé le 1er octobre 2026 que les images macOS 14 seraient retirées le 2 novembre 2026. Le retrait concerne les étiquettes macos-14, macos-14-large et macos-14-xlarge ; l’annonce précise également les périodes de brownout prévues pendant la transition et les étiquettes vers lesquelles migrer. Ces dates et étiquettes sont des faits datés : consultez à nouveau l’annonce de retrait avant de figer un calendrier, car son statut peut évoluer.

Commencez par inventorier les workflows, et pas seulement le fichier qui lance la publication. Une référence peut se trouver dans un travail appelé par réutilisation, une action composite, un workflow de demande de fusion ou une branche de maintenance qui ne s’exécute pas quotidiennement.

  • [ ] Recherchez macos-14, macos-14-large et macos-14-xlarge dans les fichiers de workflow et les configurations qui les génèrent.
  • [ ] Notez pour chaque occurrence le dépôt, le nom du travail, l’événement déclencheur et les branches concernées.
  • [ ] Distinguez compilation, tests, création d’archive, signature et publication : tous ces travaux ne présentent pas le même niveau de risque.
  • [ ] Repérez les exécutions conditionnelles, les matrices de systèmes et les workflows de secours qui pourraient rester invisibles lors d’un contrôle limité à la branche principale.

La syntaxe des workflows permet de définir les étiquettes dans runs-on, seules ou dans une liste de critères. Vérifiez cette configuration avec la documentation officielle de la syntaxe des workflows, plutôt que de remplacer mécaniquement une chaîne dans un seul fichier.

Attention : un brownout peut rendre un Runner indisponible temporairement pour exposer une dépendance que des exécutions ordinaires ne révèlent pas. Servez-vous du calendrier publié par GitHub pour choisir une fenêtre d’observation, mais n’en déduisez pas que votre migration est terminée tant que vos propres travaux n’ont pas été exécutés et contrôlés.

Établissez une référence avant le premier essai

Une migration comparable commence par une trace de l’environnement qui fonctionne aujourd’hui. Sans cette référence, une différence de résultat peut venir du code, d’une mise à jour d’outil, d’une dépendance résolue différemment ou d’un cache réutilisé, et l’équipe risque de corriger le mauvais élément.

Consignez ce que le workflow utilise réellement. Une valeur attendue dans la documentation du projet n’est pas nécessairement celle sélectionnée pendant l’exécution. Gardez ensemble la configuration déclarée et les informations visibles dans les journaux.

  • La version de Xcode choisie explicitement ou disponible par défaut, ainsi que les SDK et outils appelés par les scripts.
  • Les paramètres de compilation, les destinations de test, la cible de déploiement et les options d’archivage.
  • La méthode de résolution des dépendances, les versions verrouillées et les commandes d’installation.
  • Les clés, chemins et règles de restauration des caches, en distinguant les données mises en cache des éléments générés à nouveau.
  • Les résultats de tests importants, les avertissements connus et la manière de vérifier l’archive, la signature et le livrable final.

Conservez une exécution de référence représentative, ses journaux et les contrôles d’artefact associés. L’objectif n’est pas d’établir une promesse de durée ou de performance, mais de disposer d’éléments assez précis pour distinguer un écart d’environnement d’un défaut de code. Pour les dépendances, vérifiez aussi la portée des clés et la procédure de restauration dans la documentation des caches GitHub Actions.

3. Isolez le nouvel environnement au lieu de remplacer la production

Créez un essai indépendant sur une branche de migration ou ajoutez un travail parallèle au workflow existant. Gardez l’étiquette macOS 14 dans le chemin de production tant que le candidat n’a pas franchi les contrôles propres au projet. Cette séparation évite qu’un changement de Runner transforme directement un essai exploratoire en changement de publication.

L’annonce de GitHub indique les étiquettes de remplacement suggérées ; macOS 15 et macOS 26 figurent parmi les environnements à considérer. Le bon choix dépend cependant du projet et des outils effectivement nécessaires, non d’un numéro de système pris isolément. Avant de lancer les essais, comparez le manifeste correspondant à chaque image : la liste des logiciels de l’image macOS 15 et celle de l’image macOS 26 détaillent leur contenu. Ces listes évoluent ; contrôlez la version courante au moment de l’essai.

Option d’essai À vérifier avant de l’adopter Situation où elle peut convenir
Runner hébergé macOS 15 Manifeste de l’image, outils réellement installés, compatibilité avec le projet et ses dépendances Quand le projet passe les contrôles requis sans imposer une dépendance particulière à une autre image
Runner hébergé macOS 26 Disponibilité des outils, compatibilité des scripts, tests et cibles de déploiement Quand les outils requis sont présents et que les validations du projet réussissent sur cette image
Mac distant avec Runner auto-hébergé Administration de l’hôte, configuration, accès, mises à jour et procédure de reprise Quand le projet nécessite davantage de contrôle ou un environnement persistant, et que l’équipe peut en assurer l’exploitation

Une étiquette décrit le type de Runner demandé ; elle ne garantit pas, à elle seule, la version de Xcode, les paramètres du projet ou la destination de déploiement. Pour clarifier la distinction entre les ressources hébergées et les réglages de workflow, appuyez-vous sur la documentation GitHub des Runner hébergés et sur les manifestes d’image. Ne copiez pas une version de Xcode observée dans un ancien journal sans vérifier qu’elle est encore disponible sur l’image candidate.

Diagnostiquez chaque écart avant de modifier les dépendances

L’essai doit révéler où se situe une différence, pas déclencher une remise à zéro générale. Comparez les journaux de l’ancienne référence et du Runner candidat, puis classez chaque échec selon son origine probable : système, outil de compilation, dépendance, cache, script ou condition d’architecture. Cette classification aide à choisir une correction minimale, vérifiable et réversible.

Par exemple, si une commande échoue parce qu’un outil n’est plus installé de la même manière, le manifeste et les étapes d’installation constituent les premiers éléments à comparer. Si la résolution des dépendances change, examinez les fichiers de verrouillage et les commandes exécutées. Si un échec disparaît après une restauration différente du cache, inspectez la clé et les chemins restaurés avant de supprimer l’ensemble du cache.

Traitez les références à macOS 14 comme des indices, et non comme une preuve que le projet en a besoin. Une ancienne condition de script peut refléter une exigence toujours valable, ou simplement une hypothèse jamais remise en question. Dans le premier cas, documentez la capacité requise et testez une solution compatible ; dans le second, retirez la liaison historique uniquement après avoir démontré qu’elle n’a plus d’effet utile.

Repère de diagnostic : modifiez une seule famille de causes à la fois, puis relancez le travail concerné. Changer simultanément l’image, les dépendances et les caches rend les résultats difficiles à attribuer et complique un éventuel retour arrière.

Les contrôles d’architecture méritent une attention distincte si des scripts sélectionnent des binaires, des outils ou des chemins selon le processeur. Vérifiez le manifeste exact de l’image plutôt que de supposer qu’une étiquette implique automatiquement une architecture ou une version de logiciel. Les images et leur contenu sont maintenus dans le dépôt officiel des Runner ; utilisez-le pour confirmer les capacités disponibles au moment de l’essai.

5. Validez toute la chaîne, puis autorisez le changement

Un passage au vert sur la compilation ne valide pas, à lui seul, un flux de publication. Sur l’image candidate, exécutez les travaux qui correspondent aux chemins utilisés par le projet : construction de l’application, tests sélectionnés, création de l’archive, signature et vérifications précédant le transfert ou la publication. Si certains contrôles sont conditionnels, lancez aussi le chemin qui les active au lieu de déduire leur bon fonctionnement d’une exécution partielle.

Consignez séparément les preuves de compilation, de tests, de signature et de remise du livrable. Une archive peut être générée alors qu’une étape de signature ou une vérification située plus loin échoue. Inversement, une étape de publication peut ne pas s’exécuter dans un essai de branche et doit alors être validée dans un contexte autorisé, sans exposer de secrets dans les journaux.

  • [ ] Le Runner candidat est indiqué dans le journal et son contenu a été confronté au manifeste officiel.
  • [ ] Le projet utilise les versions d’outils attendues, vérifiées dans l’environnement réel plutôt que supposées d’après l’étiquette.
  • [ ] Les tests représentatifs réussissent ; les échecs préexistants sont comparés aux résultats de référence.
  • [ ] L’archive est contrôlée selon les critères du projet, notamment ceux qui concernent signature et livraison.
  • [ ] Le responsable de la chaîne de publication a examiné les preuves et accepté le risque résiduel.

Si le projet exige un appareil réel, une session graphique ou une intervention humaine, délimitez explicitement ce que le Runner hébergé peut faire dans votre workflow et ce qui relève d’un autre environnement. La disponibilité d’une image macOS ne démontre pas qu’un essai reproduit une connexion à un appareil, une session interactive ou chaque étape d’un processus de conception audio ou vidéo. Définissez ces besoins à partir du flux de travail réel, puis testez-les séparément.

Passez en production avec une marche arrière documentée

Remplacez l’étiquette de production seulement après la réussite des travaux critiques et l’accord de la personne responsable. Faites le changement de façon à pouvoir identifier immédiatement les workflows touchés ; supprimez les références à macOS 14 qui ne servent plus qu’après avoir vérifié les branches secondaires, les workflows réutilisables et les scripts d’automatisation.

Avant le basculement, écrivez les conditions d’arrêt : échec d’un test déterminant, archive non conforme, signature refusée, dépendance indisponible ou divergence inexpliquée avec le résultat attendu. Décidez à l’avance qui peut suspendre la publication et quel chemin de retour est autorisé. Une consigne du type « revenir en arrière en cas de problème » est insuffisante si l’ancienne étiquette est déjà indisponible ou si les conditions de retour n’ont pas été testées.

Conservez la configuration précédente et les éléments nécessaires à l’analyse, mais ne supposez pas que l’étiquette retirée restera utilisable après la date annoncée. L’annonce officielle et ses brownouts doivent guider la préparation ; ils ne remplacent pas un plan de repli testé sur l’environnement effectivement disponible. Pour un Runner auto-hébergé, tenez aussi compte des responsabilités de maintenance, de sécurité et de disponibilité décrites dans la documentation GitHub des Runner auto-hébergés.

La décision peut ensuite suivre ces conditions :

  • Si une étiquette hébergée prise en charge permet les compilations, tests et livrables requis, choisissez-la et gardez votre processus de publication sur ce modèle.
  • Si les essais échouent pour une cause identifiée et corrigeable, suspendez le basculement, corrigez cette cause, puis répétez les vérifications ciblées.
  • Si une contrainte avérée impose une maîtrise durable de l’hôte, ou si des tâches continues ne cadrent pas avec votre usage des Runner hébergés, évaluez un Mac distant et son coût d’exploitation en temps, administration et contrôle des accès.
  • Si l’équipe ne peut pas maintenir un Runner auto-hébergé, ne migrez pas par défaut vers ce modèle : vérifiez d’abord si le projet peut fonctionner sur les étiquettes hébergées disponibles.

Questions fréquentes sur le retrait et la migration

Quand les Runner macOS 14 doivent-ils être retirés ?

GitHub a annoncé le retrait des images macOS 14 pour le 2 novembre 2026. Les étiquettes concernées sont macos-14, macos-14-large et macos-14-xlarge, et l’annonce décrit également un calendrier de brownout. Vérifiez sa version à jour avant de planifier votre bascule : cette date et les modalités publiées sont des informations susceptibles d’être modifiées par l’éditeur.

Comment éprouver le workflow avant de remplacer le Runner de production ?

Faites fonctionner le workflow candidat en parallèle ou depuis une branche dédiée, sans changer d’abord le travail de publication. Comparez les journaux à une exécution de référence, puis vérifiez les tests, l’archive et les étapes de signature réellement utilisées. L’équipe peut ainsi traiter un écart sans confondre sa cause avec une modification simultanée du workflow de production.

Que faut-il vérifier en migrant vers macOS 15 ou macOS 26 ?

Commencez par le manifeste correspondant à l’image choisie : le nom de l’étiquette ne garantit pas la présence de chaque outil. Confirmez ensuite les versions effectives de Xcode et des SDK, la résolution des dépendances, les conditions d’architecture, les destinations de test et les paramètres de déploiement du projet. Terminez par les contrôles de livrable et de signature propres à votre chaîne.

Dans quels cas un Mac distant est-il une meilleure piste qu’un Runner hébergé ?

Il mérite une évaluation si le workflow dépend d’un hôte dont l’équipe veut maîtriser durablement la configuration, s’il doit rester disponible pour des tâches continues ou si un besoin opérationnel ne correspond pas aux Runner hébergés. Cette option implique aussi la responsabilité d’administrer le nœud et ses accès. Elle ne constitue donc pas automatiquement le meilleur choix pour une chaîne CI ponctuelle et standard.

Pour la plupart des équipes, le premier choix reste un Runner hébergé pris en charge si les essais prouvent qu’il couvre les besoins de la chaîne. En revanche, un environnement imposé par le service hébergé, des changements d’image à suivre et l’absence de maîtrise directe de l’hôte peuvent peser lorsque le projet réclame une configuration durable ou un nœud toujours disponible ; un Runner auto-hébergé ajoute, lui, la charge de maintenance. Si ces contraintes justifient réellement un Mac distant, comparez les offres et périodes de location RUVCLOUD, puis consultez les options de commande RUVCLOUD avant de choisir. La décision doit découler des essais et des responsabilités que votre équipe peut assumer, pas du seul retrait d’une étiquette.