2026 Petites équipes — Mac distant partagé : matrice Git (certificats SSH, helper HTTPS, Trousseau, concurrence) — credential helper multi-comptes, rotation de jetons et checklist moindre privilège

Un même utilisateur macOS peut exécuter plusieurs agents CI, des scripts de synchronisation et des sessions interactives. Dès qu’un remote HTTPS pointe vers github.com sans chemin fin, le credential helper peut réutiliser le premier jeton valide — parfois celui d’un autre mandat. Symétriquement, ssh git@github.com sans IdentitiesOnly risque de proposer la mauvaise clé. Les bonnes pratiques de rotation de jetons et droits minimaux sur les canaux d’alerte s’appliquent aussi au dépôt : périmètre étroit, durée courte, preuve de contrôle après rotation.

Objectif opérationnel : une relation (compte forge × mandat client) → une chaîne d’outils prévisible (fichier ~/.gitconfig inclus, hôte SSH dédié, ou PAT stocké avec granularité par URL). Les tableaux suivants aident à trancher sans dogme.

Utilisez ce tableau pour choisir la première brique d’identité sur un nœud mutualisé (équipes 5–30 personnes, un ou plusieurs dépôts actifs par siège).

Synthèse : mélangez volontairement SSH pour les dépôts à forte exigence d’audit machine et HTTPS+PAT pour les pipelines où la rotation API est déjà industrialisée — mais ne mélangez pas les identités au même hôte sans alias ni chemin.

Les worktrees et jobs CI déclenchent souvent plusieurs git fetch simultanés. Risques observés : (1) un script écrit ~/.git-credentials en mode concurrent ; (2) un helper universel répond avec le mauvais utilisateur parce que l’URL ne discrimine pas l’organisation ; (3) surcharge du Trousseau sur toutes premières authentifications. Remèdes : fichiers d’inclusion par racine de travail, pas de credential glob mutable par des jobs anonymes, et timeouts alignés sur la matrice worktree pour ne pas multiplier les retries aveugles.

• Préférer git config credential.useHttpPath true pour les remotes HTTPS.
• Isoler les essais destructifs dans un clone jetable avec GIT_CONFIG_SYSTEM=/dev/null si besoin de reproduire sans toucher la config globale.
• Sérialiser les rotations de jeton (fenêtre de maintenance) quand plusieurs pipelines partagent encore une entrée unique.

Avant de valider un poste ou un nœud build, cochez mentalement les points suivants (revue trimestrielle recommandée).

1. Découper Git par mandat (fichier ~/.gitconfig) :

[includeIf "gitdir:~/clients/acme/"]
    path = ~/.gitconfig-acme
[credential]
    helper = osxkeychain
    useHttpPath = true

Dans ~/.gitconfig-acme, fixez utilisateur et éventuellement une stratégie supplémentaire ; gardez un dépôt témoin sous ce préfixe pour tester.

2. Alias SSH pour séparer les comptes GitHub/GitLab (~/.ssh/config) :

Host github.com-acme
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_acme
    IdentitiesOnly yes

Adaptez les remotes en git@github.com-acme:org/repo.git. Pour les certificats émis par une CA d’équipe, reportez-vous aux paramètres de confiance et de renouvellement décrits dans la matrice jump host.

3. Vérifications rapides (à enchaîner après changement) :

1. git remote -v dans chaque clone critique : URL conforme au mandat.
2. ssh -T git@github.com-acme (ou équivalent GitLab) : message de bienvenue du bon compte.
3. git ls-remote origin HEAD puis git fetch réel sur deux dépôts en parallèle : pas d’erreur d’authentification intermittente.
4. Après rotation : ancien jeton révoqué côté forge, nouveau fetch réussi, build pipeline vert sur branche témoin.

Faut-il préférer SSH ou HTTPS sur un Mac partagé ?

Les deux conviennent si vous séparez explicitement les identités : SSH avec alias et IdentitiesOnly ; HTTPS avec useHttpPath et jetons distincts. SSH facilite l’audit des clés ; HTTPS simplifie les rotations API très fréquentes.

Pourquoi le Trousseau semble « mélanger » les comptes ?

Sans granularité de chemin d’URL, Git peut réutiliser la première entrée valide pour l’hôte. Activez credential.useHttpPath et veillez à ce que chaque remote HTTPS porte le chemin complet du dépôt.

Les pulls parallèles sont-ils fiables avec un seul utilisateur macOS ?

Oui pour des dépôts et identités déjà résolues ; méfiance si un script réécrit des fichiers credential partagés ou si plusieurs rotations simultanées touchent la même entrée Trousseau — dans ce cas, sérialisez ou isolez par configuration.

En résumé : traitez les identités Git comme des contrats par mandat — pas comme un réglage par défaut du système. Documentez alias SSH, chemins HTTPS et fenêtres de rotation ; validez avec des fetch parallèles contrôlés avant d’élargir la charge CI.