fatal: unable to access 'https://github.com/agence/theme-client.git/': Failed to connect to github.com port 443: Connection timed out. Ce message, tombé au milieu d’un déploiement chez un client dont le réseau interne passe par un proxy d’entreprise, a d’abord été traité comme un problème de token d’accès personnel expiré. Trois régénérations de token plus tard, l’erreur persistait à l’identique — le signe qu’on cherchait le problème au mauvais endroit.
Ce cas est plus fréquent qu’il n’y paraît dans les environnements d’agence qui déploient depuis des postes ou des serveurs situés derrière une infrastructure réseau contrôlée : administrations, grands comptes, établissements de santé. Le symptôme trompe presque toujours vers une piste d’authentification, alors que la cause est réseau.
Symptôme : un clone qui ne part jamais
La commande git clone ou git pull reste bloquée plusieurs dizaines de secondes avant d’échouer avec un message évoquant un problème de connexion, parfois accompagné d’une mention SSL selon la configuration du proxy. Le piège classique consiste à interpréter ce blocage comme un défaut de credentials, puisque GitHub renvoie parfois un message générique qui ne distingue pas clairement une erreur réseau d’une erreur d’authentification refusée.
Diagnostic : isoler la couche réseau
La première vérification consiste à sortir Git de l’équation et à tester la connectivité brute avec curl, en pointant explicitement vers le même hôte :
curl -v https://github.com
# Si la commande échoue de la même façon, le problème est confirmé réseau,
# pas Git ni les identifiants.
echo $http_proxy
echo $https_proxy
Si curl échoue à l’identique sans jamais interroger de mécanisme d’authentification Git, la cause est nécessairement en amont : DNS, pare-feu ou proxy. Sur ce projet, les variables d’environnement http_proxy et https_proxy existaient bien au niveau du système, mais Git ne les reprend pas automatiquement dans toutes les configurations, en particulier lorsqu’il est invoqué depuis un utilisateur système dédié au déploiement, dont l’environnement shell diffère de celui de l’utilisateur interactif.
Correctif : déclarer le proxy à Git explicitement
Git dispose de sa propre configuration de proxy, indépendante des variables d’environnement système, et c’est elle qui doit être renseignée pour un utilisateur de déploiement non interactif :
git config --global http.proxy http://proxy.interne.client:3128
git config --global https.proxy http://proxy.interne.client:3128
# Vérification
git config --global --get http.proxy
Une fois cette configuration posée pour l’utilisateur exécutant réellement le pipeline de déploiement — souvent un compte de service distinct du compte personnel utilisé pour les tests manuels —, le clone est reparti immédiatement, confirmant que le token d’accès n’avait jamais été le problème.
Le cas particulier des certificats d’inspection SSL
Sur certains réseaux, le proxy pratique une inspection SSL qui substitue son propre certificat à celui de GitHub. Dans ce cas, la commande curl échoue avec une erreur de certificat plutôt qu’un timeout, et la solution consiste à importer le certificat racine de l’entreprise dans le magasin de confiance du système, jamais à désactiver la vérification SSL avec -k ou http.sslVerify=false, qui neutraliserait une protection légitime pour un gain de confort ponctuel.
Prévention : documenter la configuration réseau du déploiement
- Consigner dans la documentation du projet les variables de proxy attendues pour l’utilisateur de déploiement, pas seulement pour les postes de développement ;
- Tester le clone depuis le compte de service exact utilisé en production, jamais depuis un compte personnel qui masquerait la différence de configuration ;
- Ajouter une étape de diagnostic réseau (
curl -v) avant toute étape de clone dans les scripts de déploiement automatisés, pour distinguer immédiatement une panne réseau d’un refus d’authentification.
Un message d’erreur Git générique masque presque toujours une cause plus bas dans la pile réseau. Reproduisez-la avec un outil plus simple avant de suspecter les identifiants.
En résumé
Face à une erreur de clone Git sur un réseau contrôlé, la piste réseau doit être vérifiée avant la piste d’authentification, et non l’inverse. Un simple curl -v vers l’hôte concerné permet de trancher en quelques secondes, évitant de perdre du temps à régénérer des tokens qui n’ont jamais été en cause. La configuration de proxy propre à Git, distincte des variables système, reste le détail le plus souvent oublié sur les comptes de service dédiés au déploiement.
