La page officielle des versions de Bazel référence Bazel 9.1.0 comme version publiée : ce numéro de version ne constitue toutefois pas une preuve de gain pour votre chaîne iOS CI (notes de version officielles de Bazel 9.1.0). Le cache distant Bazel 9 ne mérite donc pas une activation générale sans mesure préalable : activez-le seulement si les actions sont reproductibles, réellement répétées sur plusieurs nœuds et servies par un réseau stable. Dans le cas contraire, conservez une base de nœuds Mac fixes, lancez un essai en lecture seule et réservez le budget à la capacité Mac lorsque les files d’attente ou les tâches non réutilisables restent le principal goulot d’étranglement.

Symptôme : les compilations répétées restent longues, mais vous ne savez pas si le problème vient du calcul, de la file d’attente ou du transfert des artefacts. Solution la plus rapide : mesurez la répétition des actions, testez un cache en lecture seule sur une configuration Mac identique, puis choisissez entre cache, nouveaux nœuds Mac ou combinaison des deux.

Cet article s’adresse aux responsables de l’efficacité développeur qui utilisent déjà Bazel sur un projet iOS important, aux responsables IT et FinOps qui arbitrent entre infrastructure partagée et capacité supplémentaire, ainsi qu’aux équipes sécurité qui doivent encadrer l’écriture, l’accès et la purge des artefacts.

Dernière mise à jour : 1er septembre 2026. Les informations de compatibilité ont été vérifiées à partir de la documentation Bazel, des dépôts officiels rules_apple et rules_swift, des notes de version Bazel et des exigences système d’Apple.

Commencez par mesurer le bon goulot d’étranglement

Un cache distant Bazel ne transforme pas un serveur Linux en machine capable d’exécuter Xcode. Il réutilise les sorties d’actions Bazel déjà produites, tandis que l’exécution d’Xcode, les tests sur simulateur, la signature, l’archivage et les contrôles dépendant de macOS continuent de nécessiter un nœud Mac approprié.

Avant de demander une infrastructure de cache, rassemblez les éléments suivants sur une période représentative :

  • la proportion de compilations répétant les mêmes actions sur plusieurs nœuds ;
  • le nombre de tâches placées en file d’attente lorsque les Mac sont occupés ;
  • la fréquence des compilations propres, qui invalident naturellement une partie des sorties précédentes ;
  • le recouvrement réel entre les branches, les commits et les configurations de build ;
  • la durée de téléchargement et d’envoi des objets, ainsi que les échecs de transfert ;
  • la part des tâches qui se terminent par une signature, un archivage ou un test de simulateur non couvert par la réutilisation d’actions.
Ne concluez pas à partir d’une seule durée de build. Un build plus court peut simplement avoir utilisé une machine moins chargée, tandis qu’un cache apparemment efficace peut déplacer le temps vers le téléchargement, augmenter la pression sur le stockage ou masquer une divergence d’environnement.

Le premier arbitrage

Le cache est généralement le meilleur candidat lorsque plusieurs jobs reconstruisent des actions identiques avec le même graphe, la même version d’outillage et des entrées stables. L’ajout de Mac est prioritaire lorsque les jobs attendent dans une file, exécutent des actions Apple non réutilisables ou utilisent des versions de Xcode différentes.

Séparez dès le départ quatre solutions qui ne répondent pas au même problème :

  • Cache distant Bazel : réutilise des sorties d’actions déjà calculées ;
  • Exécution distante : déplace l’exécution d’actions vers d’autres workers, ce qui constitue une architecture différente et ne remplace pas automatiquement un environnement Mac ;
  • Cache de compilation natif d’Xcode : dépend du fonctionnement propre à Xcode et ne doit pas être assimilé au cache d’actions Bazel ;
  • Ajout de nœuds Mac : augmente la capacité pour les actions qui doivent réellement s’exécuter sur macOS.

Vérifiez la reproductibilité avant de parler de performance

La réutilisation d’une action n’est valable que si Bazel identifie correctement ses entrées et si la sortie peut être consommée par le nœud demandeur. La documentation officielle décrit le protocole de cache distant, les chemins d’objets et les conditions générales de lecture et d’écriture (documentation Bazel sur le cache distant).

Dans un environnement Apple, plusieurs écarts peuvent empêcher une réutilisation correcte ou rendre un artefact dangereux à consommer :

  • une variable d’environnement injectée uniquement sur un nœud ;
  • un chemin absolu différent entre deux Mac ;
  • un outil externe présent sur une machine mais absent d’une autre ;
  • une version divergente de Xcode, du SDK, de Swift ou d’un outil de génération ;
  • des paramètres de compilation dépendant de la branche, du profil ou du secret ;
  • une règle qui lit indirectement un fichier non déclaré comme entrée ;
  • une architecture ou une plateforme Apple différente de celle attendue par le job.
Le cas rules_apple mérite une vérification distincte. Consultez le dépôt officiel et ses versions publiées avant de déclarer Bazel 9 compatible avec votre combinaison exacte de règles, de rules_swift, de Xcode et de SDK ([dépôt officiel rules_apple](https://github.com/bazelbuild/rules_apple) et [dépôt officiel rules_swift](https://github.com/bazelbuild/rules_swift)). Une mention de compatibilité dans un dépôt signifie que la combinaison est reconnue dans un périmètre donné ; elle ne prouve ni la stabilité de vos macros internes, ni la validité de vos scripts de signature, ni l’acceptation de vos artefacts par la chaîne de distribution.

Construisez une matrice de compatibilité exploitable

Classez chaque combinaison dans trois catégories :

  • Support officiel : la combinaison Bazel 9, rules_apple, rules_swift, Xcode et SDK est explicitement couverte par les versions et notes disponibles ;
  • Validée par votre équipe : le support existe, mais votre projet a encore besoin d’une validation avec ses macros, ses scripts et ses profils ;
  • À isoler : version de développement, correctif non fusionné, branche de prépublication ou association absente des informations officielles.
Les éléments de la troisième catégorie ne doivent pas entrer dans le cache partagé de production. Maintenez-les dans un espace séparé, car une expérimentation de compatibilité ne doit pas contaminer les artefacts consommés par les branches de livraison.

Apple publie les exigences système et les relations entre Xcode, macOS et les SDK ; utilisez cette page pour vérifier que le nœud Mac prévu pour le CI satisfait bien la combinaison retenue (exigences système officielles de Xcode). Cette vérification doit porter sur les machines de compilation, pas uniquement sur le poste du développeur.

Pourquoi un projet rules_apple peut-il ne pas atteindre le cache sur plusieurs Mac ? Les causes les plus fréquentes sont une clé d’action différente, un outil externe ou un chemin non déclaré, une divergence de version Xcode ou SDK, ou encore une entrée liée à l’environnement local. Le fait que deux Mac utilisent la même puce ne suffit pas : la reproductibilité doit être démontrée par les journaux d’actions et par la comparaison des entrées, pas déduite du matériel.

Mesurez le rendement du cache avec plusieurs indicateurs

Le taux de succès des requêtes est utile, mais il ne répond pas seul à la question « le cache distant Bazel accélère-t-il réellement l’iOS CI ? ». Un cache peut afficher des lectures fréquentes tout en ajoutant une latence de réseau importante ou en ne couvrant que des actions peu coûteuses.

Pour chaque même soumission, enregistrez au minimum :

  • les lectures distantes réussies et manquées ;
  • les téléchargements et téléversements d’objets ;
  • la durée consacrée au transfert séparément de la durée d’exécution ;
  • les erreurs réseau, les reprises et les objets introuvables ;
  • la croissance du stockage et les résultats après un démarrage à froid ;
  • le temps de file d’attente du nœud Mac ;
  • la durée totale jusqu’à l’archive signée ou au résultat de test.
La documentation Bazel consacrée au diagnostic des échecs de cache fournit les points de contrôle nécessaires pour distinguer une absence normale de correspondance, une clé différente et un dysfonctionnement de transport ([guide officiel de diagnostic du cache distant](https://bazel.build/versions/7.1.0/remote/cache-remote?hl=en)). Même si la page de diagnostic porte sur une version documentaire antérieure, utilisez-la comme méthode de lecture des symptômes et vérifiez ensuite les changements applicables à votre version de Bazel.

Comparez les topologies, pas seulement les machines

Un cache placé dans la même région réseau que les Mac de build limite généralement le trajet des objets. Un cache éloigné ajoute une dépendance à la latence, au débit disponible et aux politiques de sortie du réseau. Pour une équipe distribuée, l’accès des développeurs ne doit pas automatiquement passer par le même chemin que les jobs CI : les besoins d’un poste interactif et ceux d’un pipeline d’intégration ne sont pas identiques.

Conservez trois observations séparées :

  • cache et Mac de build dans une même zone réseau ;
  • cache et Mac dans des régions distinctes ;
  • accès d’une équipe distante vers le cache, avec ses contraintes de VPN, de pare-feu et d’authentification.
Le transfert devient défavorable lorsque le temps nécessaire pour récupérer une sortie dépasse le calcul évité, ou lorsque les échecs provoquent une reconstruction locale. Ne publiez donc pas de promesse universelle du type « le cache divise les builds par deux » : aucune proportion d’accélération ne peut être déduite de la seule documentation du protocole. Elle doit provenir de vos journaux, d’un benchmark reproductible ou d’une mesure clairement publiée.

Encadrez les écritures et les artefacts sensibles

Autoriser chaque poste de développement à écrire dans un cache partagé est une mauvaise base de gouvernance. Le risque n’est pas seulement une erreur de configuration : un artefact construit avec une entrée inattendue peut être réutilisé par un job ultérieur, tandis qu’une fuite dans les journaux peut exposer un chemin, un paramètre ou une information liée au produit.

Utilisez au moins trois profils opérationnels :

  • Nœud de lecture : peut consommer des artefacts approuvés, mais ne peut pas modifier le cache ;
  • Nœud d’écriture contrôlée : réservé à des runners CI identifiés, avec une configuration d’outils figée et des journaux audités ;
  • Cible exclue du cache : signature, secrets, archivage final ou toute action dont les entrées ne peuvent pas être vérifiées avec assez de précision.
Une matrice de droits doit relier le type de nœud à la tâche autorisée, au mode de cache, à l’identité utilisée, à la trace conservée et à l’action de confinement. En cas d’artefact suspect, vous devez pouvoir retirer le runner, empêcher les nouvelles écritures, isoler l’espace concerné, reconstruire à partir d’un environnement propre et comparer le résultat avec une exécution sans cache.

Le cache ne doit pas devenir un canal de contournement

Contrôlez les points suivants avant le passage en production :

  • chiffrement du transport et validation de l’identité du service ;
  • rotation et portée minimale des jetons ;
  • séparation des projets, branches sensibles et environnements ;
  • limitation des droits d’écriture aux runners gérés ;
  • journalisation des lectures, écritures, suppressions et erreurs ;
  • politique de rétention et purge vérifiable ;
  • absence de secrets ou de données confidentielles dans les sorties mises en cache ;
  • procédure de reconstruction sans cache après suspicion de corruption.
**Comment vérifier qu’un cache Bazel distant n’a pas contaminé les artefacts ?** Exécutez le même commit avec cache désactivé, cache en lecture seule puis cache en écriture contrôlée, sur des Mac dont l’environnement est identique. Comparez les manifestes, les sommes ou les signatures de sortie attendues, les journaux de provenance et le résultat de l’archive finale. Une différence doit suspendre l’extension du cache jusqu’à l’identification de l’entrée ou de l’action responsable ; un simple build « vert » ne suffit pas comme preuve d’intégrité.

Reliez le rendement à la capacité Mac et au TCO

Le cache distant ne supprime pas les besoins liés à Xcode, aux simulateurs, à la signature et à l’archivage. Apple définit les contraintes de système pour Xcode et ses SDK ; votre plan de capacité doit donc réserver des Mac conformes à la matrice retenue, même si une partie des actions est réutilisée (exigences système officielles de Xcode).

Votre modèle de coût doit contenir des variables distinctes :

  • coût de mise en place et d’exploitation du cache ;
  • stockage des objets et croissance liée à la rétention ;
  • trafic réseau et éventuels transferts interrégion ;
  • temps d’administration, d’audit et de restauration ;
  • coût des nœuds Mac réservés au CI ;
  • coût de la file d’attente lorsque la capacité manque ;
  • coût des builds propres, des signatures et des tests non réutilisables ;
  • coût d’un incident provoqué par un artefact erroné ou un environnement divergent.
Ne renseignez pas ces variables avec une économie théorique annoncée par le fournisseur d’un outil. Remplissez-les avec vos factures, vos journaux CI, vos temps d’attente et vos tests. La bonne comparaison comporte trois options :
  • Cache seul : pertinent si les actions répétées dominent le temps et si la capacité Mac existante absorbe les tâches finales ;
  • Mac supplémentaires : préférable si les files d’attente, les tests de simulateur ou les archives sont le principal délai ;
  • Cache plus Mac élastiques : adapté lorsque le cache réduit les reconstructions récurrentes, mais que les pointes de livraison nécessitent temporairement davantage de machines.
Pour une équipe qui veut comparer un nœud local et un **Mac distant**, calculez le coût sur la même période et avec le même niveau de service. Incluez l’accès administrateur, l’isolement, le temps de remise à zéro, la connectivité et la capacité réellement disponible ; ne comparez pas uniquement le prix d’achat d’un Mac avec une ligne de location.

Si vos nœuds fixes ne permettent pas de séparer un essai du trafic de production, une capacité Mac temporaire peut servir de baseline indépendante. Pour comparer une configuration Apple Silicon destinée aux essais et un renfort de CI, vous pouvez examiner les options de Mac M4 Commander et vérifier séparément la région, l’accès et les conditions d’exploitation correspondant à votre protocole.

MACGPU propose des accès à des Mac hébergés, accessibles à distance, ce qui peut être évalué comme environnement de validation ou comme renfort ponctuel ; consultez les options de Mac distant disponibles uniquement après avoir défini vos critères de test.

Le cache distant et l’ajout de nœuds Mac, lequel est le plus rentable ? Le cache est le choix rationnel lorsque les mêmes actions coûteuses sont reconstruites sur plusieurs nœuds et que le transfert reste inférieur au calcul évité. L’ajout de Mac est préférable lorsque la file d’attente provient de tâches de signature, d’archivage ou de simulateur, car ces tâches continuent de consommer une machine réelle même avec un cache bien alimenté.

Conduisez un essai A/B qui puisse être audité

Votre pilote doit utiliser le même commit, les mêmes paramètres de build, la même version de Bazel, la même combinaison rules_apple et rules_swift, ainsi que des Mac comparables. Changez une seule variable à la fois et conservez les journaux complets, y compris les erreurs et les reconstructions après échec.

Organisez trois conditions :

  • Sans cache : établit le coût de référence des actions exécutées localement ;
  • Cache en lecture seule : mesure le bénéfice des artefacts existants sans autoriser votre pipeline à alimenter le référentiel ;
  • Cache en lecture et écriture contrôlées : mesure le comportement de production avec des runners explicitement autorisés.
Répétez chaque condition sur une compilation récurrente, une compilation propre, une branche modifiée et une séquence comprenant archive, signature et tests. Les valeurs de temps, de volume, de taux de hit et de débit doivent rester attachées à leur environnement de mesure ; si le réseau, le Mac ou le commit change, la série n’est plus directement comparable.

Décidez avec des conditions explicites

  • Si les actions récurrentes sont reproductibles, que les lectures distantes sont stables, que les erreurs sont traçables et que la file d’attente Mac reste le goulot principal après réutilisation, alors poursuivez avec un cache contrôlé.
  • Si le cache réduit les calculs mais que les archives, signatures ou simulateurs saturent encore les nœuds, alors conservez le cache et dimensionnez des Mac supplémentaires pour ces tâches.
  • Si les gains disparaissent lorsque le cache et les Mac changent de région, alors rapprochez le stockage des runners ou abandonnez l’extension interrégion.
  • Si les clés divergent à cause des outils, des chemins ou des variables, alors corrigez la reproductibilité et relancez le pilote avant toute décision budgétaire.
  • Si un artefact différent apparaît entre l’exécution sans cache et l’exécution avec cache, alors bloquez les écritures, isolez la cible concernée et revenez à une reconstruction propre.
  • Si les tâches non couvertes dominent la durée totale et que les files d’attente restent élevées, alors arrêtez d’investir dans le cache seul et augmentez la capacité Mac.
  • Si vous ne pouvez pas fournir de nœud de référence isolé, de journaux complets et de droits séparés, alors reportez le déploiement partagé.
Prévoyez enfin trois exercices opérationnels : indisponibilité du cache, détection d’un artefact incorrect et reconstruction complète d’un nœud Mac. La décision de production doit inclure le temps de retour au mode sans cache, la personne autorisée à désactiver les écritures et la preuve permettant de confirmer que les jobs suivants utilisent des sorties propres.

Ce que cette décision implique pour votre infrastructure

Un cache distant Bazel 9 est un multiplicateur de réutilisation, pas une capacité de calcul Apple. Il peut améliorer l’utilisation de nœuds existants lorsque les actions sont identiques et reproductibles, mais il ne remplace ni Xcode, ni les simulateurs, ni la signature, ni l’archivage. Les exigences d’outillage doivent être réexaminées à chaque changement de Bazel, de rules_apple, de rules_swift, de Xcode ou de SDK ; utilisez les versions publiées de Bazel et les dépôts officiels comme sources de vérification, non comme garantie de production.

Après votre essai, convertissez la file d’attente de pointe, les tâches de signature et les actions non couvertes en capacité Mac mesurable. Si votre parc actuel ne fournit pas l’isolement nécessaire ou si vous devez absorber un pic temporaire sans achat durable, louer un Mac distant auprès de MACGPU peut offrir un environnement de référence ou un renfort de construction plus facile à retirer qu’un investissement matériel permanent. Cette approche ne convient toutefois pas à une charge lourde stable qui exige un contrôle physique des interfaces : dans ce cas, un parc Mac acheté et administré en interne peut rester le choix le plus cohérent.

La bonne décision n’est donc pas « cache ou Mac » par principe. C’est : cache validé pour les actions effectivement réutilisables, puis capacité Mac dimensionnée pour tout ce qui doit encore s’exécuter, se signer et se vérifier sur Apple Silicon ou macOS.