GitHub a annoncé le 10 septembre 2026 que l’image Runner Xcode 27 fonctionne sur macOS 27 et qu’elle est en préversion publique. C’est le changement confirmé à intégrer à votre recette. La publication d’une image ne signifie pas que chaque workflow, dépendance ou étape de livraison est compatible sans contrôle. L’annonce GitHub précise le changement et son statut.

Pour examiner les logiciels inclus, consultez la documentation de l’image Xcode 27 arm64 dans le dépôt Runner, puis rapprochez ses informations des publications correspondant à la date de votre test. Le nom du fichier indique une image destinée à arm64 ; il ne prouve pas, à lui seul, quel environnement a réellement été provisionné pour un job donné.

Une étiquette de Runner et une image exécutée sont deux éléments distincts. Votre workflow demande un Runner ; l’image effectivement provisionnée détermine le système et les outils disponibles pendant l’exécution. Les règles de sélection sont décrites dans la documentation GitHub sur le choix du Runner pour un job.

Pour confirmer les versions effectives, ajoutez une collecte explicite des informations système et des outils au workflow de recette :

• relevez la version de macOS rapportée pendant l’exécution ;
• relevez la version de Xcode et les outils de développement actifs ;
• conservez le nom du Runner demandé, les informations d’image disponibles et l’identifiant de l’exécution ;
• archivez ces éléments avec le résultat de compilation, plutôt que de déduire l’environnement du seul libellé inscrit dans le fichier de workflow.

Gardez des champs séparés pour le Runner demandé, l’image observée, macOS, Xcode et le résultat du job. Les versions « 27 » de Xcode et de macOS désignent des éléments différents de la chaîne. Pour contrôler les prérequis et les changements documentés par Apple, consultez les exigences système de Xcode et les notes de version Xcode 27. Ne déduisez pas de la seule version de macOS que tous les composants nécessaires à votre projet sont présents.

Commencez par recenser les workflows dont l’étiquette demande l’image Xcode 27, puis classez les jobs par fonction. Une liste des seuls fichiers de configuration ne suffit pas : une même chaîne peut compiler sur un Runner, tester sur un autre et publier dans une étape distincte.

Pour chaque dépôt concerné, consignez les éléments suivants :

• la tâche et l’étiquette de Runner demandée ;
• le type d’exécution : compilation, tests unitaires, tests de simulateur, archivage ou publication ;
• les versions de macOS, de Xcode et des dépendances relevées pendant le job ;
• les secrets et autorisations nécessaires, sans copier leur valeur dans le rapport ;
• le responsable de l’acceptation et la preuve attendue.

Cette cartographie permet d’éviter un raccourci fréquent : marquer un dépôt entier comme « vérifié » parce qu’un job de compilation a réussi. Si le job de signature utilise une autre image, ou si le téléversement passe par une étape différente, ces tâches doivent conserver leur propre statut de validation.

Pour éviter les omissions, classez chaque tâche selon son impact. Une compilation destinée à une branche de développement peut être moins critique qu’une publication destinée aux utilisateurs. À l’inverse, un job apparemment secondaire peut générer l’archive attendue par plusieurs étapes en aval. Notez ces dépendances : une modification de l’environnement qui touche un artefact commun peut affecter plusieurs équipes, même si une seule pipeline est directement configurée avec le libellé du Runner concerné.

Dans une branche isolée ou un workflow de recette, choisissez des projets représentatifs de vos dépôts. Incluez ceux qui utilisent des dépendances, des scripts de génération ou plusieurs cibles de plateformes. Rejouez la résolution à partir des fichiers de verrouillage réellement employés par l’équipe. Enregistrez les versions et les sorties des outils au lieu de considérer une compilation réussie comme une preuve générale de compatibilité.

Votre dossier de validation doit distinguer les résultats suivants :

• Résolution : les dépendances sont récupérées et résolues comme prévu.
• Compilation : les cibles attendues sont produites sans erreur bloquante.
• Tests : les suites prévues démarrent et leurs résultats sont comparés aux références de l’équipe.
• Artefacts : les fichiers attendus sont présents et les différences avec la référence sont examinées.

Une exécution réussie ne prouve ni que tous les dépôts sont compatibles, ni que toutes les combinaisons de dépendances fonctionnent. Indiquez quels projets ont été essayés, quelles exceptions ont été rencontrées et quels artefacts ont été comparés. Limitez la conclusion à ce périmètre précis. Si un dépôt utilise une dépendance ou un script qui n’a pas été inclus dans la recette, signalez-le comme non vérifié au lieu de l’assimiler aux projets testés.

Un cas représentatif peut associer une application iOS à une cible macOS qui génère des ressources audio ou vidéo. Dans ce type de pipeline, distinguez les tests de l’application, la génération des ressources et la production de l’artefact final. Une réussite sur une cible ne valide pas automatiquement les autres étapes de création. Vérifiez aussi que les fichiers générés sont disponibles pour les jobs en aval et que les scripts qui les produisent s’exécutent dans le contexte prévu.

Le changement de système ne prouve pas que votre signature ou votre téléversement échouera ; il ne garantit pas non plus qu’ils fonctionneront sans régression. Faites passer une version de recette par la voie de distribution réellement utilisée par votre équipe. Pour les conditions Apple, vérifiez les consignes de préparation d’une application à la distribution, la documentation sur la signature du code distribué et les règles de téléversement des builds dans App Store Connect.

Conservez un résultat distinct pour chaque étape :

• tests sur les simulateurs utilisés par le projet ;
• création et contrôle de l’archive ;
• signature avec les autorisations, certificats et profils réellement configurés par votre équipe ;
• téléversement et confirmation du résultat dans la destination de publication ;
• journaux et artefacts rattachés à l’exécution de recette.

Les identifiants et secrets doivent rester gérés selon les règles internes de votre organisation. Le rapport indique quels accès ont été testés, sans exposer leur contenu. En cas d’échec, séparez une erreur de compilation d’un problème d’authentification, de signature ou de téléversement. Cette distinction accélère le diagnostic et évite d’attribuer à macOS un échec provoqué par une configuration de publication.

Ne déclarez pas une chaîne validée sur la seule base d’un état vert dans l’interface CI. Associez chaque preuve à une étape explicite : tests terminés, archive produite, signature acceptée et téléversement confirmé. Si la publication comporte une approbation humaine, consignez également cette limite : une exécution automatisée qui s’arrête avant l’approbation ne démontre pas que la livraison complète a été effectuée.

Le statut de préversion publique est une information sur la disponibilité, pas une garantie de disponibilité ni une preuve d’instabilité. Votre décision doit s’appuyer sur la tolérance au changement de votre organisation, ses contrôles internes et les voies de reprise réellement testées. Ne promettez pas un délai de récupération si vous ne disposez pas d’un engagement vérifié applicable à votre environnement.

Définissez trois états d’acceptation distincts : le Runner est accessible ; le job CI s’exécute avec les résultats attendus ; la publication est achevée et confirmée. Un job peut être disponible sans produire un artefact valide, ou compiler correctement sans réussir le téléversement. Ne regroupez pas ces états dans un unique indicateur vert.

Avant d’autoriser une tâche de production, précisez :

• quels workflows peuvent utiliser l’image en préversion ;
• qui peut suspendre son adoption et sur la base de quel constat ;
• quel canal déjà validé peut reprendre les tâches critiques ;
• où sont conservés les journaux et les preuves de recette ;
• quelle modification de l’image ou du statut déclenche une nouvelle validation.

Si vous ne pouvez pas identifier une voie de reprise utilisable et vérifiée, ne déplacez pas encore la publication critique vers cette image. Définissez aussi qui décide de revenir au canal précédent et comment l’équipe reconnaît que cette reprise a effectivement fonctionné. Un document de procédure non testé n’est pas une preuve de récupération.

Le choix ne se résume pas à « Runner géré ou Mac dédié ». Il dépend des changements que vos équipes acceptent, du niveau d’isolation attendu, de la maîtrise nécessaire de la base système et de votre capacité à conserver une voie de publication déjà validée.

Outil de décision pour l’affectation des tâches

• [ ] Si les workflows sont isolés, que les versions effectives sont consignées, que compilation, tests et publication réussissent sur des projets représentatifs, et que votre équipe accepte le statut de préversion, alors vous pouvez conserver les tâches validées sur le Runner géré. Gardez un suivi de l’image et une procédure de réexamen.
• [ ] Si seule la compilation a été testée, alors limitez l’usage à la recette et conservez signature et publication sur leur voie déjà validée.
• [ ] Si vos règles imposent une base système contrôlée, une isolation dédiée ou une reprise dont vous maîtrisez les étapes, alors conservez un canal Mac dédié préalablement vérifié, ou répartissez les tâches entre Runner géré et canal dédié.
• [ ] Si vous ne disposez d’aucune preuve réelle sur la version, la configuration, la disponibilité ou la récupération du nœud envisagé, alors ne le désignez pas comme solution de production sur la base d’une hypothèse.

L’achat d’un Mac en propre peut offrir davantage de maîtrise matérielle et physique, mais vous impose de gérer l’approvisionnement, l’administration, le remplacement et la maintenance. Un Runner géré évite l’administration directe de l’hôte, mais son image peut évoluer et son statut de préversion doit entrer dans votre évaluation. La location d’un Mac distant peut être envisagée pour un besoin temporaire ou un canal dédié, à condition de vérifier les caractéristiques effectivement proposées et de réaliser vos essais de build et de publication avant toute décision.

Pour examiner les informations de commande disponibles, consultez la page Mac mini de KVMNODE. Ne déduisez pas qu’une version précise de macOS ou de Xcode, une configuration particulière ou une procédure de restauration est disponible si ces éléments ne sont pas confirmés dans les informations de livraison et par vos essais.

Votre dossier de décision peut tenir sur une fiche par workflow : image observée, tâches exécutées, artefacts contrôlés, résultat de signature et de téléversement, décision, responsable et voie de retour. Cette fiche transforme une validation ponctuelle en élément vérifiable lors d’un changement ultérieur de manifeste ou de statut. Elle facilite aussi la revue entre développement, plateforme et publication : chaque équipe peut voir quelles étapes ont été acceptées, lesquelles restent ouvertes et qui doit fournir la preuve manquante.

Si vos publications tolèrent un Runner géré après une recette complète, il n’est pas nécessaire de déplacer toutes les tâches vers un nœud dédié. En revanche, si la maîtrise de la base système et une voie de reprise documentée sont des exigences de production, une organisation reposant uniquement sur une image publique en préversion ne répond pas à ces exigences tant qu’elle n’a pas été validée selon vos critères.

Pour un besoin temporaire de tests ou un canal Mac distinct, comparez la voie actuelle à un Mac distant à partir des informations réellement livrables, puis exécutez votre workflow de recette avant d’y confier une publication. Vous pouvez consulter les options proposées par KVMNODE, puis confirmer les environnements et modalités disponibles avant de décider. Aucune version, capacité ou promesse de reprise ne doit être présumée sans vérification.