Quand Rosetta 2 cessera-t-il d’être pris en charge ? Liste de migration CI Mac d’entreprise 2026

Apple a confirmé que macOS 27 est la dernière version majeure destinée à fournir la prise en charge générale de Rosetta pour les applications macOS exclusivement conçues pour Intel. Certaines versions de macOS 26.4 et ultérieures peuvent également afficher des rappels de migration. La formulation exacte doit toutefois être contrôlée dans la version finale et dans les notes de version correspondantes.

Cela signifie que macOS 27 est une fenêtre de migration, pas un nouveau délai illimité. Vous pouvez encore observer une application Intel fonctionner, mais cette observation ne démontre ni la pérennité de votre CI, ni la compatibilité de ses extensions, ni la capacité à restaurer un agent après redémarrage.

Ne confondez pas quatre situations différentes :

• un Mac Intel physique, dont la question relève de la compatibilité matérielle et de la version de macOS ;
• une application macOS uniquement x86_64 lancée sur Apple Silicon grâce à Rosetta ;
• un Universal Binary contenant à la fois des tranches arm64 et x86_64 ;
• un binaire Intel exécuté dans une machine virtuelle Linux, qui relève d’un mécanisme différent décrit dans la documentation Apple sur les binaires Intel dans les VM Linux.

Le dernier cas ne doit pas être utilisé pour conclure que les outils macOS de votre pipeline sont protégés. Une VM Linux, un agent macOS et une extension de signature Apple ne partagent pas les mêmes contraintes.

Attention. Ne validez pas une migration parce que l’interface de l’outil s’ouvre. Dans une CI, le processus critique peut être lancé par un script, un plugin ou un démon plusieurs étapes plus tard.

L’équipe IT doit fournir une méthode d’inventaire reproductible. Le contrôle du seul binaire principal de Xcode ou de l’application de build est insuffisant. L’inventaire doit couvrir chaque commande exécutée par les tâches de test, d’archivage et de publication.

Ajoutez au registre, pour chaque composant :

• le nom et le chemin exact de l’exécutable ;
• l’architecture détectée : arm64, x86_64 ou Universal Binary ;
• la tâche qui l’appelle et l’étape concernée ;
• le propriétaire technique ;
• la version actuelle et la version de remplacement envisagée ;
• le type de dépendance : outil, bibliothèque dynamique, agent, plugin, interpréteur ou installateur ;
• l’impact d’un échec sur les branches, les releases et les correctifs urgents ;
• la preuve de validation : journal, empreinte, rapport de test ou artefact publié.

Les éléments les plus souvent oubliés sont les binaires installés dans un répertoire de gestion de paquets, les scripts d’installation, les hooks avant et après installation, les LaunchAgents, les chargeurs de plugins et les outils invoqués par un script shell qui ne figure pas dans le fichier CI principal.

Sur un nœud de test, conservez au minimum les résultats des commandes nécessaires à la vérification :

file /chemin/vers/outils/outillage
lipo -info /chemin/vers/binaire

Ces commandes ne remplacent pas l’observation des processus. Un outil arm64 peut appeler un sous-processus x86_64. Vous devez donc enregistrer l’architecture des processus pendant l’exécution représentative, puis rapprocher ce résultat du journal de la tâche et du rapport système.

Pour un agent permanent, examinez aussi le contexte de lancement. Un composant peut fonctionner dans une session interactive mais échouer lorsqu’il est lancé sans interface graphique, sans trousseau déverrouillé ou sans variables d’environnement personnalisées. La migration n’est acceptée que si le même mode de lancement est utilisé en production.

Le responsable de la chaîne d’outils doit attribuer une décision à chaque ligne de l’inventaire. Trois réponses sont possibles.

Remplacement direct

Choisissez la version arm64 officielle lorsqu’elle existe et lorsque son comportement est documenté pour votre version de macOS et de Xcode. Vérifiez ensuite les formats d’artefacts, les chemins d’installation, les extensions et les versions transitives. Un gestionnaire de paquets natif ne garantit pas que toutes les formules ou tous les plugins installés par-dessus le soient également.

Recompilation interne

Pour un outil développé en interne, produisez une version arm64 ou un Universal Binary. Le guide Apple consacré à la construction d’un Universal Binary décrit le principe des deux tranches, mais votre validation doit porter sur votre chaîne de distribution.

Contrôlez notamment :

• la signature de chaque tranche ;
• la présence des bibliothèques dynamiques attendues ;
• les scripts d’installation et de mise à jour ;
• la compatibilité des plugins ;
• l’empreinte du binaire distribué ;
• le comportement lorsque le processus est lancé sans session interactive.

Le guide Apple de portage des applications vers Apple Silicon aide à structurer cette analyse, mais il ne remplace pas un test sur le projet qui produit réellement vos applications.

Isolement temporaire

Un outil fermé sans version arm64 peut entrer dans une liste d’exceptions. Cette décision doit comporter un propriétaire, une justification, une date de sortie et une tâche précise. Le nœud compatible ne doit pas devenir le chemin par défaut pour de nouveaux projets.

Refusez l’exception si elle exige une baisse du niveau de sécurité du système, une signature contournée, une autorisation manuelle après chaque redémarrage ou une présence humaine permanente. Une « compatibilité » qui disparaît après un redémarrage n’est pas une capacité de production.

La plateforme CI doit créer deux pools explicites :

• un pool natif, réservé aux tâches validées en arm64 ;
• un pool compatible, réservé aux exceptions x86_64 documentées.

Utilisez des étiquettes, des files ou des groupes de nœuds distincts. Ne partagez pas sans contrôle les caches, les répertoires de dépendances et les variables d’environnement entre les deux architectures. Un cache produit sur un nœud peut masquer une dépendance qui réapparaîtrait sur un nœud propre.

La double exécution doit inclure des demandes représentatives :

• une demande de fusion avec compilation et tests ;
• une archive de distribution ;
• une tâche de signature et de notarisation ;
• une publication interne ou externe ;
• une restauration après redémarrage du nœud.

Comparez les résultats fonctionnels avant de comparer la durée. Les données de temps, de capacité de file et de récupération doivent provenir des journaux de votre entreprise ou d’une mesure clairement identifiée comme telle. Il ne faut pas inventer un gain de performance à partir de l’architecture seule.

La preuve minimale pour chaque tâche comprend :

1. le commit testé et l’environnement exact ;
2. l’architecture de chaque processus critique ;
3. le succès des tests et de l’archivage ;
4. l’empreinte des artefacts comparables ;
5. le statut de signature et de notarisation ;
6. le comportement après redémarrage ;
7. la décision du propriétaire de la tâche.

Les notes de version de Xcode 27 doivent être relues en parallèle des notes de macOS 27. Une mise à niveau de l’OS ne suffit pas à certifier les plugins, les scripts de distribution ou les outils périphériques de votre chaîne.

La compilation est rarement le seul point de rupture. Une équipe de publication doit vérifier que les deux architectures d’un Universal Binary passent la signature avec les bons identifiants et que le produit distribué correspond bien à celui testé.

Cochez les contrôles suivants pour chaque flux de production :

• [ ] Le trousseau utilisé par l’agent est accessible dans le contexte non interactif prévu.
• [ ] Les certificats et profils sont disponibles après redémarrage.
• [ ] La signature couvre le binaire et ses composants chargés dynamiquement.
• [ ] La notarisation est exécutée avec le même mode d’authentification qu’en production.
• [ ] Les plugins internes sont présents dans l’architecture attendue.
• [ ] Les démons et LaunchAgents redémarrent sans intervention.
• [ ] Les journaux de restauration sont conservés.
• [ ] Aucun réglage de sécurité ne doit être abaissé pour maintenir l’outil.

Un fichier signé n’est pas nécessairement un flux de publication validé. Il faut contrôler le produit final, les scripts d’emballage et la restauration d’un agent vierge. Les erreurs liées à une extension peuvent ne se manifester qu’au moment de l’archivage ou lors d’une publication déclenchée par une branche protégée.

Le pool compatible doit être traité comme une dette avec sortie planifiée. Utilisez la matrice suivante pendant le comité de migration :

Cette grille évite de choisir automatiquement la location ou l’achat. Elle impose d’abord une preuve technique, puis une décision d’infrastructure.

Le responsable infrastructure doit convertir les résultats de validation en modèle de capacité. Le nombre de développeurs ne permet pas, à lui seul, de dimensionner une flotte de build.

Utilisez au moins ces variables :

• nombre de tâches candidates au pool natif ;
• nombre de tâches encore confinées au pool compatible ;
• capacité utile observée par nœud ;
• durée et volume du double parcours ;
• pointe de publication ;
• marge de redondance ;
• date de retrait prévue pour les exceptions ;
• temps acceptable de reprise après panne.

Votre décision peut suivre cette logique :

• si les tâches natives absorbent la charge avec une marge documentée, réduisez progressivement le pool compatible ;
• si le double parcours allonge la file au-delà du seuil accepté, ajoutez temporairement de la capacité Apple Silicon ;
• si le besoin est limité à une campagne de validation, testez d’abord un nœud Mac distant isolé pour un PoC ;
• si la charge est permanente, comparez le coût total d’achat, d’administration, de remplacement et de capacité de pointe avec une solution distante ;
• si une contrainte impose un accès physique à un périphérique, la location distante peut ne pas convenir.

Pour un environnement expérimental ou un pic de migration, vous pouvez consulter les formules de location Mac de CALMVPS. La décision finale doit rester fondée sur vos journaux CI, vos exigences de conformité et votre modèle d’exploitation, non sur une promesse générale de performance.

IT et gestion de flotte

• [ ] Les Mac Apple Silicon concernés par macOS 27 sont identifiés.
• [ ] Les versions de système et de Xcode sont consignées.
• [ ] Chaque nœud possède une étiquette d’architecture explicite.
• [ ] Les nœuds compatibles ne partagent pas leurs caches critiques avec le pool natif.
• [ ] Une procédure de retour à l’état précédent est documentée.
• [ ] Le propriétaire de chaque exception est connu.

Équipe plateforme CI/CD

• [ ] Les tâches représentatives sont sélectionnées.
• [ ] Les exécutables et sous-processus sont analysés.
• [ ] Les files natives et compatibles sont séparées.
• [ ] Les artefacts, journaux et empreintes sont conservés.
• [ ] Le redémarrage sans session interactive est testé.
• [ ] Aucune nouvelle dépendance x86_64 n’est acceptée sans approbation.

Outils et développement

• [ ] Chaque composant possède une version arm64, une version Universal Binary ou une exception.
• [ ] Les interpréteurs, plugins et installateurs sont inclus dans l’analyse.
• [ ] Les tests portent sur un projet réel et non sur une commande isolée.
• [ ] Les dépendances transitives sont vérifiées.
• [ ] Les scripts de publication sont exécutés sur un nœud propre.

Sécurité et publication

• [ ] La signature des deux tranches est vérifiée.
• [ ] Keychain, certificats et profils fonctionnent après redémarrage.
• [ ] Les composants chargés dynamiquement sont contrôlés.
• [ ] La notarisation est validée.
• [ ] Toute réduction de sécurité bloque l’acceptation ou déclenche une sortie urgente.

macOS 27 pourra-t-il encore lancer des applications Intel ?

Oui, dans la limite annoncée par Apple pour la dernière version majeure offrant la prise en charge générale de Rosetta. Cette compatibilité ne couvre pas automatiquement les plugins, les scripts secondaires, les agents sans interface graphique ni les futures évolutions de l’OS. Testez donc chaque chaîne complète avant de considérer votre nœud comme migré.

Comment vérifier si une CI Mac dépend encore de Rosetta 2 ?

Ne vous limitez pas à l’application principale. Analysez les exécutables, bibliothèques, agents, installateurs et plugins appelés pendant une tâche réelle. Utilisez file et lipo, puis observez les processus lancés pendant la compilation, l’archivage et la publication. Archivez les sorties avec le journal CI afin de pouvoir rattacher chaque dépendance à un propriétaire.

Comment migrer un outil de build x86_64 vers arm64 ?

Cherchez d’abord une version arm64 officiellement distribuée. Pour un composant interne, recompilez-le ou créez un Universal Binary, puis testez ses bibliothèques, plugins, scripts d’installation et signatures. La validation doit utiliser un projet représentatif et inclure l’archivage, la publication et le redémarrage de l’agent. Le simple succès de l’installation n’est pas une preuve suffisante.

Faut-il conserver un nœud compatible macOS 27 dans une entreprise ?

Oui, uniquement lorsqu’une dépendance précise n’a pas encore de remplacement et qu’une échéance de retrait est approuvée. Le nœud doit être placé dans un pool séparé et ne doit pas recevoir de nouvelles tâches permanentes. Si personne ne possède l’exception ou si sa date de sortie est inconnue, vous devez la traiter comme un risque opérationnel, pas comme une architecture cible.

Quels scripts CI risquent d’échouer lorsque Rosetta ne sera plus disponible ?

Tout script qui lance indirectement un binaire x86_64 peut échouer, y compris un hook d’installation, un chargeur de plugin, une bibliothèque dynamique ou un outil de signature. Les problèmes peuvent aussi apparaître après redémarrage, lorsque l’agent n’a plus de session interactive. Testez les étapes de compilation, d’archivage, de notarisation et de publication sur un nœud natif propre.

Ne planifiez pas la mise à niveau de toute la flotte parce que Rosetta fonctionne encore sur un nœud de référence. Autorisez-la lorsque les tâches de production ont obtenu une preuve arm64 complète, que les exceptions possèdent une date de retrait et que la capacité du pool natif couvre le double parcours ainsi que les publications urgentes.

Si votre infrastructure actuelle repose sur des Mac Intel physiques, elle ajoute une contrainte de matériel et de version qui ne disparaît pas avec un simple changement de script. Si vous avez déjà acheté des Mac Apple Silicon mais conservez un pool Rosetta indéfini, vous supportez deux chaînes d’exploitation, deux profils de cache et deux chemins de dépannage. Enfin, une capacité cloud générique peut compliquer l’accès au trousseau, aux signatures, aux journaux et aux exigences macOS spécifiques.

Après l’inventaire, une courte location de Mac Apple Silicon peut donc servir de zone d’essai isolée pour exécuter vos vraies tâches, vérifier la signature et mesurer la reprise avant d’engager un achat durable. Vous pouvez commencer par les options de Mac distant disponibles auprès de CALMVPS, puis conserver uniquement la capacité nécessaire lorsque les preuves de migration sont acceptées. L’objectif n’est pas de remplacer automatiquement votre flotte, mais de ne pas laisser une dépendance x86_64 non documentée décider de votre calendrier de mise à niveau.