2026 Petites équipes — Mac distant partagé : artefacts de build, rsync, cache NFS et isolation des permissions (concurrence & conflits)

À qui s’adresse cet article : responsables techniques et équipes de 3 à 15 personnes qui mutualisent un ou plusieurs Mac distants pour CI, compilation iOS/macOS ou pipelines hybrides. Vous devez publier des artefacts de build vers un dépôt interne, un partage ou un second nœud sans corrompre les sorties des autres jobs.

Mots-clés cœur : Mac distant partagé, rsync, NFS, artefacts de build, isolation des permissions, cache, concurrence, promotion, miroir.

Cadrez ce sujet avec le reste de votre runbook : la matrice Git worktree et verrous pour les arbres sources, la matrice runner GitHub Actions, routage et files pour la charge, et le guide build partagé SSH/VNC et isolation des permissions. Pour la couche réseau et les accès, croisez avec Jump Host et rotation des certificats SSH par rôle.

1) Rsync en connexion directe (push ou pull). Chaque job invoque rsync vers une cible SSH ou un chemin local distant : simple à auditer, bon pour des promotions ponctuelles. Le risque principal est la fenêtre pendant laquelle les lecteurs voient des fichiers partiellement copiés ; on compense par répertoires temporaires et renommage atomique à la fin.

2) Rsync incrémental (efficacité + historique). Vous réutilisez une base précédente avec --link-dest (instantanés type « time machine » légers) ou des snapshots côté stockage, puis ne transférez que le delta. Idéal quand les artefacts sont volumineux (.app, frameworks, archives) et que la liaison réseau est le goulot. La complexité ops augmente : il faut nommer les snapshots, purger selon la rétention et documenter quel répertoire est « courant ».

3) NFS monté comme cache ou magasin partagé. Les builders et les consommateurs voient le même arbre via le protocole NFS : moins de copies explicites, mais sensibilité aux coupures, aux attributs (UID/GID alignés) et aux verrous distribués. Sur un Mac distant partagé, le NFS brille quand plusieurs nœuds ou utilisateurs doivent lire la même référence sans duplication ; il pénalise les petites écritures aléatoires et les builds très IOPS si le montage n’est pas dimensionné.

Pour une vision multi-nœuds et orchestration, reliez ce choix au guide de collaboration multi-nœuds sur maillage Mac : la cohérence des chemins et des identités y est aussi critique que ici.

Utilisez ce tableau dans vos revues d’architecture ; ajustez les seuils à votre monitoring disque et réseau.

Les files et quotas du pool restent le garde-fou global : la FAQ pool Mac partagé : files, quotas et conflits complète cette matière sur la charge, pas seulement sur la copie des fichiers.

Verrous de répertoire et publication. Autour de la phase « promotion » (rendre une build visible), utilisez un verrou exclusif sur un fichier de contrôle dans le répertoire parent — par exemple flock sous zsh/bash — ou sérialisez cette étape dans votre orchestrateur. Chaque job doit écrire dans son propre préfixe (staging/<run-id>/) puis basculer un lien symbolique ou renommer un dossier unique « release » une fois la copie terminée.

umask. Sur un compte partagé, 027 limite la lecture aux « autres » tout en permettant au groupe service de lire les artefacts. Passez à 077 si chaque pipeline utilise un utilisateur système distinct et que seuls des rôles rsync ou ACL étendues consomment les fichiers. Documentez la décision dans le même runbook que l’isolation des permissions SSH/VNC.

Certificats SSH et séparation des rôles. Distinguez au minimum : (a) compte builder avec droit d’écriture vers le staging, (b) compte promoteur ou automation qui seul renomme vers « current », (c) compte lecteur pour les téléchargements ou miroirs. Émettez des certificats utilisateur différents par rôle (voir la matrice Jump Host citée plus haut) pour révoquer un périmètre sans couper toute l’équipe.

Sur NFS, ajoutez des règles d’équipe : pas deux jobs sur le même fichier de sortie, pas de build Xcode intensif directement sur le montage si la latence dégrade la concurrence utile — gardez NFS pour la distribution et rsync pour les promotions maîtrisées.

Puis-je monter le même NFS en lecture-écriture pour tous les développeurs ?

Techniquement oui, opérationnellement risqué : collisions de noms, suppression accidentelle, dépendance réseau. Préférez RW pour l’automation, RO pour les humains, ou des sous-dossiers quota par personne.

Rsync à travers Jump Host : bonne idée ?

Oui si le bastion est dimensionné et si vous respectez la séparation des rôles ; utilisez ProxyJump et limitez les comptes qui peuvent écrire sur la cible.

Comment tester une nouvelle chaîne sans casser la production ?

Pointez vers un préfixe /artifacts-experimental/ avec ACL distinctes ; validez checksums et temps de publication avant de basculer le symlink « current ».

Le mélange NFS + rsync crée-t-il des doublons inutiles ?

Souvent non : NFS sert de magasin partagé, rsync propulse les builds validés depuis le disque local rapide du Mac. Le doublon devient un problème seulement si vous copiez deux fois la même version sans politique de rétention.

En résumé : choisissez rsync direct pour la simplicité et la traçabilité, rsync incrémental pour les gros artefacts versionnés, et NFS quand plusieurs consommateurs doivent partager la même vue lecture sans multiplier les copies. Combinez verrous, umask et SSH par rôle pour que l’isolation des permissions survive à la concurrence des pipelines.