Netlify : « unrecognized Git contributor » sur repo privé, le correctif gratuit
Sur le plan gratuit de Netlify, un dépôt Git privé n’accepte qu’un seul Git Contributor reconnu : Netlify vérifie en priorité le compte GitHub OAuth qui exécute le push, pas seulement le nom ou l’email inscrit dans les commits. Le correctif ne passe pas forcément par un plan payant : il consiste d’abord à faire pousser le code par le bon compte.
Un Git Contributor désigne un compte que Netlify autorise à déclencher un build, un déploiement ou une Deploy Preview depuis un dépôt Git privé, sans lui donner accès à l’espace de travail Netlify de l’équipe source : Netlify Docs, 2026. Sur le plan Free, ce statut est limité à une seule identité reconnue par repo privé.
Pourquoi ça arrive
- Le plan Free limite un repo privé à un Git Contributor vérifié : au-delà, Netlify bloque le build au lieu de le laisser passer source : Netlify Docs, 2026.
- Netlify croise deux identités distinctes : l’auteur/committer du commit et le compte GitHub OAuth qui a physiquement exécuté le push. Une divergence entre les deux déclenche le blocage.
- Un commit peut être signé au nom du propriétaire du compte Netlify tout en ayant été poussé depuis un compte GitHub différent : c’est l’identité du push qui prime, pas celle du commit.
- Un bot d’automatisation ou un agent IA qui commite avec sa propre identité ajoute mécaniquement un contributeur, sauf exception documentée pour certains bots connus comme Renovate ou Claude source : Netlify Docs, 2026.
- Sous macOS, les outils en ligne de commande Xcode installent un gitconfig système qui impose
credential.helper=osxkeychain: le trousseau garde en cache un ancien jeton OAuth même après un changement de compte apparent.
1. Lire précisément ce que dit Netlify
Le message rapporté sur le forum officiel est explicite : « Build blocked: Unrecognized Git contributor. This plan allows only verified account members to push to private repos » source : Forum Netlify, 2026. Avant de toucher à quoi que ce soit, ouvre le détail du déploiement échoué : Netlify affiche une ligne « by … on GitHub » qui indique le compte GitHub réellement crédité du push. C’est cette ligne, pas le nom dans le commit, qui explique le blocage.
2. Vérifier quel compte GitHub pousse réellement
Lance gh auth status et compare avec git remote -v pour confirmer quel compte est actif sur la machine qui pousse. Le 28 mai 2026, sur un projet client en repo privé et plan Netlify gratuit, on a buté exactement sur ce cas : déploiement refusé avec « Build failed: unrecognized Git contributor », alors que tout l’historique Git avait été réécrit au nom du propriétaire du compte Netlify. Auteur et committer étaient identiques sur chaque commit, sans divergence visible. Le facteur décisif se trouvait ailleurs : dans le log de déploiement, la ligne « by … on GitHub » pointait vers un compte GitHub différent de celui attaché au site Netlify. Une fois le code repoussé depuis le compte GitHub du client, celui que Netlify reconnaissait, le déploiement est passé sans autre changement.
3. Réécrire l’identité des commits si nécessaire
Si l’auteur des commits ne correspond à aucun compte reconnu par Netlify, corrige git config user.name et user.email avant de pousser, puis réécris l’historique si besoin avec git commit --amend ou un rebase interactif. Ce n’est toutefois pas toujours suffisant : un dépôt confirmait qu’un commit signé par un bot d’automatisation (Claude Code, avec l’adresse noreply@anthropic.com) créait un second contributeur malgré une identité de push par ailleurs cohérente source : dépôt GitHub emails-tp. Netlify regarde les deux signaux, l’identité du commit et celle du push, pas l’un au détriment de l’autre.
4. Le piège du gitconfig système d’Xcode (osxkeychain)
Le credential helper est le mécanisme Git qui mémorise vos identifiants ou votre jeton OAuth pour éviter de les ressaisir à chaque push. Sur macOS, les outils Xcode installent par défaut un gitconfig système qui force credential.helper=osxkeychain. Même après un gh auth switch vers le bon compte, git push peut continuer de s’authentifier avec l’ancien jeton, resté en cache dans le trousseau système. gh auth status n’aide pas à le détecter : il affiche seulement Token: gho_**** sans indiquer d’où vient ce jeton source : GitHub cli/cli, issue #13330.
Sur le projet du 28 mai, ce second piège a retardé la résolution : le gitconfig système imposait credential.helper=osxkeychain et conservait l’ancien compte malgré le gh auth switch effectué. La solution durable a consisté à vider le credential helper au niveau du dépôt, avec git config --local credential.helper "" exécuté dans le dossier du projet, pour forcer Git à redemander l’authentification plutôt que de piocher silencieusement dans le trousseau macOS. Purger manuellement l’entrée avec git credential-osxkeychain erase fonctionne aussi, contrairement à une croyance répandue selon laquelle cette commande ne servirait à rien source : Gist GitHub, jonjack.
5. Ajouter proprement un second Git Contributor
Si plusieurs comptes doivent légitimement pousser sur le même repo privé, un Team Owner peut ajouter manuellement chaque nouveau Git Contributor à chaque demande de déploiement, ou activer l’auto-approval dans les paramètres d’équipe pour automatiser ce processus source : Netlify Docs, 2026. C’est la bonne réponse quand un second développeur rejoint durablement le projet, plutôt qu’un contournement technique côté Git.
6. Savoir quand un plan payant a du sens
Depuis le 14 avril 2026, Netlify a supprimé la facturation par siège sur son plan Pro : les Owners, Developers, Git Contributors, Reviewers et Billing Admins sont illimités pour 20 $/mois source : Flexprice, 2026. C’est une option à envisager quand une équipe grandit durablement, pas la première réponse à un blocage ponctuel réglé en cinq minutes avec le bon compte GitHub.
Tableau récapitulatif
| Cause | Solution |
|---|---|
| Le push vient d’un compte GitHub non reconnu par Netlify | Pousser depuis le compte GitHub attaché au site Netlify |
| Ancien jeton OAuth caché dans le Keychain (macOS + Xcode) | git config --local credential.helper "" dans le repo, puis repousser |
| Un bot ou une IA commite avec sa propre identité | Vérifier s’il est whitelisté (Renovate, Claude), sinon l’ajouter comme Git Contributor |
| Besoin durable de plusieurs contributeurs sur repo privé | Ajouter un Git Contributor via les Team Settings |
| Équipe qui grandit, plusieurs devs à demeure | Passer au plan Pro (sièges illimités depuis avril 2026) |
Pour aller plus loin sur les blocages de déploiement côté configuration, on a aussi documenté un déploiement Vercel refusé sans message et les causes courantes d’échec sur Netlify. Si le sujet est plutôt de choisir sa plateforme d’hébergement, notre comparatif Netlify face à Vercel en 2026 détaille les différences de fonctionnement.
L'erreur « unrecognized Git contributor » apparaît-elle seulement sur les repos privés ?
Essentiellement oui, puisque c’est sur les repos privés que Netlify limite le nombre de contributeurs reconnus sur le plan gratuit. Des signalements existent toutefois pour des déploiements en drag-and-drop bloqués par le même message, sans repo lié source : Forum Netlify, 2026.
Changer git config user.email suffit-il à résoudre l'erreur ?
Pas toujours. Netlify vérifie aussi le compte GitHub OAuth qui exécute le push, en plus de l’identité inscrite dans le commit. Si le push part d’un compte différent, corriger uniquement user.email localement ne change rien.
Pourquoi gh auth switch ne change pas le compte qui pousse sur macOS ?
Parce que le gitconfig système installé par les outils Xcode force credential.helper=osxkeychain, qui garde en cache l’ancien jeton OAuth indépendamment de ce que rapporte gh auth status. Vider le credential helper au niveau du dépôt force une nouvelle authentification.
Un bot CI ou un agent IA compte-t-il comme Git Contributor ?
Ça dépend du bot. Netlify documente explicitement que des bots connus comme Renovate ou Claude ne comptent pas comme contributeur distinct, mais un autre commit automatisé non whitelisté sera vu comme un second contributeur et déclenchera le blocage.
Le repo était forké ou déplacé vers un autre compte, l'erreur peut-elle venir de là ?
Oui. Un cas documenté montre qu’un commit initial poussé depuis un compte personnel, puis un repo déplacé ou forké sous un autre compte, laisse Netlify reconnaître l’identité d’origine et bloquer les pushs suivants venus d’ailleurs source : Forum Netlify, 2026.
Quand passer la main à un pro
Si le blocage persiste après avoir vérifié le compte GitHub qui pousse, purgé le credential helper et confirmé l’identité des commits, le problème vient probablement d’une configuration d’équipe plus large : permissions OAuth mal accordées lors du lien initial entre le repo et Netlify, ou héritage d’accès d’un ancien prestataire. Dans ce cas, un inventaire complet des accès avant de reprendre un projet évite de perdre des heures à deviner qui possède quoi, et une revue des clés SSH et jetons d’authentification permet de repartir sur une base propre plutôt que de multiplier les contournements.
Ce problème, Peechy s'en occupe
Plutôt que de tout gérer seul, confiez votre site à une agence qui s'occupe de tout, hébergement, sécurité, maintenance et corrections. Encore plus simple en abonnement : on règle les soucis avant même que vous les remarquiez.
Confier mon site à Peechy
