Retrait de macOS-14 d’Azure Pipelines : migration entreprise 2026

Le choix recommandé est un pool hybride : migrez les builds PR sans état vers une image macOS officiellement supportée, mais conservez sur un Mac autogéré les outils figés, les dépendances privées et la signature de production. Ne basculez pas toutes les tâches vers macOS-latest avant d’avoir exécuté le même commit sur les deux voies et validé la compilation, les tests, l’archivage et la publication.

Cet article s’adresse aux responsables Azure Pipelines qui utilisent encore macOS-14 et doivent agir avant son retrait. Il concerne également les équipes IT qui arbitrent entre Microsoft-hosted Agent, Mac autogéré, agent Apple Silicon et pool hybride pour préserver la continuité des livraisons iOS et macOS.

Dernière mise à jour : 20 septembre 2026. Le calendrier et les états d’image doivent être revérifiés dans la documentation officielle avant toute fermeture de pool. Le calendrier annoncé prévoit un brownout en octobre 2026 et le retrait de macOS-14 le 2 novembre 2026 : calendrier officiel des images hébergées Azure Pipelines.

Pourquoi un pipeline encore vert peut-il échouer pendant la migration ?

Le signal trompeur est simple : un pipeline peut réussir aujourd’hui parce que l’image macOS-14 est encore sélectionnée, tout en étant déjà exposé à une interruption planifiée. Le brownout ne ressemble pas à une défaillance progressive du code. Il provoque l’indisponibilité temporaire d’une image afin de révéler les tâches qui n’ont pas été migrées.

Après le retrait officiel, un vmImage explicite peut empêcher l’allocation de l’agent. Ce cas doit être séparé de trois autres causes :

• une version Xcode absente ou déplacée sur la nouvelle image ;
• un Simulator Runtime non installé ou incompatible avec le projet ;
• un échec indépendant du changement d’image, par exemple une dépendance privée inaccessible ou un certificat inutilisable.

Le premier inventaire doit donc porter sur le YAML, et non sur le statut général de l’agent. La liste officielle des images et des logiciels préinstallés doit servir de référence, car les tags, les versions Xcode et les composants disponibles évoluent : référentiel officiel des images macOS.

Première étape : transformer le YAML en registre de migration

Chaque pipeline doit être résumé dans un tableau d’actifs. Le minimum utile est le suivant :

Cette étape évite une erreur fréquente : déclarer la migration réussie parce que l’agent démarre. Le démarrage ne prouve ni la compatibilité du SDK, ni la production d’un artefact signé.

Build PR sans état : image hébergée ou Mac autogéré ?

Les compilations sans état, les tests unitaires et les contrôles statiques sont généralement les meilleurs candidats à une image hébergée supportée. Chaque job repart d’un environnement propre. Cette propriété limite les dérives silencieuses : fichiers laissés par un job précédent, certificat oublié dans le trousseau ou outil installé manuellement.

La contrepartie est la reconstruction de l’environnement à chaque job. Les caches doivent être mesurés avec le même commit, et non supposés efficaces parce que le pipeline termine. Un cache mal restauré peut masquer une incompatibilité ou produire des résultats différents entre deux agents.

Pour choisir entre macOS-15 et macOS-26, l’équipe doit comparer la matrice réellement utilisée par le projet :

1. version Xcode et SDK demandé ;
2. runtime de simulateur ;
3. architecture du binaire et des dépendances ;
4. extensions, plugins et scripts installés ;
5. outils de signature utilisés même pendant les builds de test.

Une version plus récente n’est pas automatiquement le meilleur remplacement. Si le projet dépend d’un runtime historique ou d’un plugin non validé, le changement de tag peut transformer un simple retrait d’image en migration de chaîne d’outils.

La commande ci-dessous permet de rendre visible l’environnement choisi dans les journaux :

pool:
  vmImage: 'macos-15'

steps:
  - script: |
      sw_vers
      xcodebuild -version
      xcrun simctl list runtimes
    displayName: "Inventorier l'environnement macOS"

Un résultat exploitable doit afficher l’image, la version Xcode et les runtimes effectivement présents. Il ne suffit pas de voir « agent ready ». Les différences doivent être conservées avec l’identifiant du commit et l’artefact généré.

Rappel de validation : un job de PR ne doit pas accéder au certificat de production uniquement parce qu’il partage le même pool qu’un job de publication. La séparation des rôles doit être visible dans les pools, les permissions et les variables secrètes.

Outils figés et anciens SDK : quand le Mac autogéré devient nécessaire

Le passage à une image moderne devient risqué lorsque le projet ne consomme pas seulement le compilateur. Certains pipelines dépendent également d’un Simulator Runtime précis, d’une extension Xcode, d’un générateur de code ou d’un script dont le comportement n’a jamais été testé sur une nouvelle version de macOS.

Dans ce scénario, trois options existent.

La mise à niveau directe convient si les dépendances sont maintenues, si le runtime cible est disponible et si le même commit produit un archive identique au niveau attendu. Le terme « identique » doit être défini par l’équipe : succès de compilation, tests, signature, contenu de l’archive et installation sur les appareils de validation.

Le pool de compatibilité temporaire convient lorsqu’une mise à niveau est engagée mais que plusieurs équipes doivent encore livrer. Ce pool doit avoir une date de sortie et un propriétaire. Sans limite claire, il devient un refuge permanent pour les projets non entretenus.

Le Mac autogéré devient préférable lorsque l’environnement doit rester figé, lorsque l’accès aux dépendances est privé ou lorsque la publication exige un trousseau contrôlé. Le self-hosted macOS agent ne signifie pas que toutes les tâches doivent y être exécutées. Il doit recevoir uniquement les jobs qui justifient cette confiance.

Les conditions d’acceptation doivent couvrir au minimum :

• résolution complète des dépendances ;
• compilation dans une configuration représentative ;
• tests unitaires et tests avec simulateur ;
• création de l’archive ;
• export et signature ;
• publication vers la destination prévue ;
• nettoyage ou rotation des secrets après le job.

Les agents autogérés ont aussi une surface d’exploitation : compte d’exécution, accès SSH, mises à jour, journaux, redémarrage et suppression des fichiers temporaires. La documentation officielle décrit le fonctionnement et les responsabilités liées aux agents : documentation des agents Azure Pipelines.

Apple Silicon et Xcode 27 : valider avant de remplacer

Apple Silicon doit être traité comme une contrainte d’architecture, pas comme une simple variante de processeur. Une dépendance native, un binaire auxiliaire ou un script d’installation peut se comporter différemment sous arm64. Les tests doivent donc inclure les outils secondaires, pas uniquement xcodebuild.

Xcode 27 demande une prudence supplémentaire. Une image Arm64 peut être documentée dans le référentiel officiel tout en restant inadaptée à une adoption immédiate pour un projet de production. L’équipe doit distinguer les éléments suivants :

• image officiellement disponible ou encore en préversion ;
• exécution sur Microsoft-hosted Agent ou sur un Mac Apple Silicon autogéré ;
• disponibilité du simulateur requis ;
• compatibilité des dépendances binaires ;
• capacité de revenir à l’environnement précédent.

La documentation officielle de l’image Xcode 27 Arm64 doit être relue au moment du test, car l’état et la liste des logiciels peuvent changer. Un projet audio, vidéo ou design mérite aussi un scénario réel : import d’un média de test, génération d’une prévisualisation, rendu ou traitement d’un fichier représentatif. Un build vert ne prouve pas que les outils créatifs annexes fonctionnent.

Deuxième étape : exécuter un double parcours contrôlé

Le double parcours doit utiliser :

• le même commit ;
• les mêmes paramètres de build ;
• les mêmes dépendances verrouillées ;
• le même jeu de tests ;
• des artefacts conservés pour comparaison.

Le pipeline peut router temporairement deux jobs vers des pools différents :

jobs:
  - job: build_hosted
    pool:
      vmImage: 'macos-15'
    steps:
      - script: ./ci/build-and-test.sh
        displayName: "Build hébergé"

  - job: build_self_hosted
    pool:
      name: 'macos-signing-validation'
    steps:
      - script: ./ci/build-and-test.sh
        displayName: "Build sur Mac autogéré"

La sortie attendue doit répondre à une question précise : la différence vient-elle de l’image, de l’architecture, du réseau, du trousseau ou du code ? Un simple indicateur de réussite ne permet pas de l’établir.

Dépendances privées et signature : séparer les nœuds de confiance

Un dépôt Git interne, un registre de paquets privé, un serveur de licences ou une sortie réseau fixe modifie la décision. Une image hébergée peut convenir au code public et échouer dès qu’elle doit atteindre une ressource non exposée à Internet.

La signature de production impose une séparation encore plus stricte. Le certificat, le profil de provisioning et la clé privée ne doivent pas être disponibles sur un pool destiné à des pull requests provenant de branches ou de projets non fiables. Les tâches de publication doivent rejoindre un Agent Pool réservé, avec un compte d’exécution limité et un accès contrôlé au trousseau.

Le modèle de circulation des secrets doit être documenté :

Commit PR
   ↓
Pool de compilation hébergé
   ↓
Artefact non signé
   ↓ approbation
Pool de signature autogéré
   ↓
Trousseau et certificat de production
   ↓
Artefact publié

La vue d’ensemble officielle de la sécurité des pipelines doit accompagner cette cartographie. Les contrôles à vérifier sont notamment les permissions du pool, les variables secrètes, les approbations, les comptes de service et la conservation des journaux.

Un Mac autogéré ne devient pas automatiquement sécurisé parce qu’il se trouve dans un réseau privé. Il faut encore limiter les projets autorisés, empêcher l’utilisation interactive non nécessaire, supprimer les fichiers temporaires et tester le redémarrage. Les recommandations spécifiques aux agents macOS sont détaillées dans la documentation de sécurité des agents macOS.

Pool hybride pour les pics de publication : quelle capacité conserver ?

Un pool hybride associe plusieurs scénarios plutôt qu’une seule technologie. Les builds PR rapides peuvent rester sur une image hébergée. Les compilations exigeant un outil figé passent sur un Mac autogéré. La signature de production utilise un pool séparé. Une capacité de secours est enfin prévue pour une panne ou une maintenance.

La capacité ne doit pas être estimée uniquement à partir du nombre de développeurs. Les variables pertinentes sont la durée des jobs, leur simultanéité, le calendrier de publication, la tolérance à la file d’attente et le temps de récupération d’un agent indisponible.

Le coût total doit aussi inclure l’administration, la surveillance, les mises à jour Xcode, le remplacement matériel, la sauvegarde de configuration et les tests de reprise. Une location ponctuelle d’un Mac distant peut être étudiée pour un PoC ou une capacité de débordement, sans transformer automatiquement toutes les tâches en environnement loué. Les options de location de Mac mini peuvent servir de point de comparaison lorsque l’entreprise veut tester un nœud dédié sans acheter immédiatement du matériel.

Pour un essai régional, la comparaison doit porter sur le chemin réseau et non sur le seul prix affiché. La page de commande d’un Mac mini distant peut être rapprochée des exigences de latence, de sortie réseau, d’accès privé et de récupération définies par l’équipe.

Matrice de décision avant la fermeture de macOS-14

La migration peut être autorisée lorsque les critères suivants sont documentés :

• l’image cible est confirmée dans la liste officielle au moment de la décision ;
• le même commit passe la résolution, la compilation et les tests ;
• l’archive et l’export sont produits avec les paramètres attendus ;
• la signature utilise le bon pool et le bon trousseau ;
• les dépendances privées sont accessibles sans élargir inutilement les droits ;
• un retour vers le pool précédent ou vers un nœud de secours est testé ;
• la file d’attente et le temps de récupération restent acceptables pour les fenêtres de publication.

Le choix peut alors être formulé simplement :

• Image hébergée si le job est sans état, public ou isolé, et si la validation complète est conforme.
• Mac autogéré si le job exige un outil figé, une ressource privée, une architecture précise ou un trousseau contrôlé.
• Pool hybride si l’entreprise combine ces contraintes ou si les pics de publication rendent le repli indispensable.

FAQ : décisions de migration Azure Pipelines

Que se passe-t-il après le retrait de macOS-14 dans Azure Pipelines ?

Les tâches qui demandent encore explicitement l’image macOS-14 peuvent rencontrer des interruptions pendant les périodes de brownout, puis ne plus démarrer après son retrait officiel. Un pipeline peut donc rester vert jusqu’à une fenêtre précise, avant d’échouer pour une raison d’image indisponible. Il faut distinguer cette cause d’un échec de compilation ou de signature.

Faut-il choisir macOS-15 ou macOS-26 pour la migration ?

Le choix dépend de la compatibilité réellement validée, et non du numéro le plus récent. macOS-15 convient lorsqu’il conserve les SDK, simulateurs et extensions nécessaires. macOS-26 peut être retenu pour préparer une évolution, mais uniquement si l’image est officiellement disponible et si le même commit passe la compilation, les tests et l’archivage.

Quels builds iOS doivent passer sur un Mac autogéré ?

Les tâches qui nécessitent un accès privé, un certificat de production, un trousseau contrôlé, une version Xcode figée ou un simulateur absent des images hébergées sont les premières candidates. Un self-hosted macOS agent est aussi pertinent lorsque l’équipe doit conserver une configuration stable, un accès réseau déterministe ou une capacité de reprise maîtrisée.

Comment valider Xcode et la signature avant la fin de macOS-14 ?

Sélectionnez un commit représentatif et exécutez-le en parallèle sur l’image cible et sur l’environnement actuel. Comparez la résolution des dépendances, la compilation, les tests unitaires et simulateur, l’archivage, l’export et la signature. La validation n’est terminée que lorsque les artefacts, les journaux et le comportement du trousseau sont conformes.

Comment combiner les agents Mac hébergés et autogérés ?

Réservez les images hébergées aux builds PR sans état et aux contrôles rapides. Placez les dépendances privées, les outils figés et la signature dans des Agent Pool autogérés séparés. Le routage doit être explicite dans YAML, tandis que les droits du projet, du compte d’exécution et du pool doivent empêcher qu’un job non fiable atteigne un nœud de production.

Le remplacement direct par macOS-latest est donc une mauvaise stratégie de migration. Un environnement Azure Pipelines hébergé reste avantageux pour les tâches sans état, mais il expose davantage les équipes aux changements d’image et aux contraintes de disponibilité des runtimes. À l’inverse, un Mac acheté ou autogéré offre davantage de contrôle, mais ajoute l’administration, la maintenance, la reprise et la capacité immobilisée. Pour un double parcours limité, un pic de publication ou un nœud de secours, louer un Mac distant auprès de SFTPMAC peut offrir une voie plus souple : l’entreprise conserve une séparation entre le pool courant et le nouvel environnement sans acheter immédiatement une machine dédiée.

La décision la plus sûre consiste à sélectionner une vraie PR et une vraie publication, à les exécuter sur les deux voies, puis à documenter les écarts avant la date de retrait. Si les dépendances privées, la signature ou les outils figés échouent sur l’image cible, un Mac autogéré dédié ou loué doit être évalué avant toute migration en masse.