Comment configurer HTTPS_PROXY pour Cursor et Claude Code dans un réseau d'entreprise

Si votre entreprise bloque le trafic sortant via un proxy d'entreprise, les assistants IA comme Cursor et Claude Code cessent simplement de répondre : l'autocomplétion se bloque, le CLI renvoie ETIMEDOUT ou problème de certificat SSL. Voyons comment bien définir les variables d'environnement HTTPS_PROXY, configurer l'authentification et éviter les erreurs courantes qui font perdre des heures aux développeurs à déboguer les paramètres réseau au lieu du code.

Pourquoi les assistants IA ont besoin d'un proxy dans un réseau d'entreprise

Cursor et Claude Code ne sont pas des modèles locaux. Ils accèdent constamment à des API externes : Cursor se connecte à ses serveurs d'indexation de code et aux API des modèles (OpenAI, Anthropic, Google selon le fournisseur choisi), tandis que Claude Code — se connecte directement à l'API d'Anthropic via HTTPS. Dans un réseau d'entreprise, l'accès direct à Internet est souvent bloqué par un pare-feu, et tout le trafic sortant doit passer par un serveur proxy (Squid, Zscaler, Blue Coat, Fortinet FortiProxy ou passerelle interne d'entreprise). Sans les variables d'environnement correctement configurées, l'application ne sait tout simplement pas que le trafic doit passer par le proxy et essaie de se connecter à Internet directement — ce qui entraîne des délais d'attente.

Une difficulté supplémentaire est que Cursor est construit sur Electron (qui est essentiellement Chromium + Node.js), tandis que Claude Code est une application CLI Node.js. Chacun a sa propre logique de lecture des paramètres du proxy : Electron hérite partiellement des paramètres système de l'OS, tandis que les processus Node.js lisent les variables d'environnement HTTP_PROXY/HTTPS_PROXY directement ou via des bibliothèques comme undici et node-fetch. Cela crée de la confusion : les paramètres sont définis, mais l'outil ne les « voit pas ».

Variables HTTP_PROXY, HTTPS_PROXY et NO_PROXY : comment cela fonctionne

La méthode classique pour spécifier un proxy pour les applications Node.js, Python et Go en console est via des variables d'environnement. La différence entre HTTP_PROXY et HTTPS_PROXY est fondamentale : le premier est utilisé pour les requêtes via le protocole HTTP, le second pour les requêtes HTTPS (et presque tout le trafic des assistants IA passe par HTTPS). Il est conseillé de spécifier les deux, même si le trafic réel est uniquement HTTPS — certaines bibliothèques effectuent des requêtes HTTP de service au démarrage.

export HTTP_PROXY="http://proxy.company.local:8080"
export HTTPS_PROXY="http://proxy.company.local:8080"
export NO_PROXY="localhost,127.0.0.1,.company.local"

Notez que même pour le trafic HTTPS, le schéma dans l'adresse du proxy est spécifié comme http://, et non https:// — c'est l'adresse du serveur proxy lui-même, et non la ressource cible. Se connecter au proxy via HTTP est normal, le chiffrement vers le serveur final fonctionne toujours via le mécanisme de tunneling CONNECT.

La variable NO_PROXY est nécessaire pour exclure les adresses internes de l'entreprise du proxy — sinon, les requêtes vers les dépôts git internes, Jira ou les services de développement locaux passeront également par le proxy externe et ne seront soit pas trouvées, soit ralenties. Un point important : certaines bibliothèques sont sensibles à la casse des variables. Pour plus de sécurité, spécifiez les deux variantes — en majuscules et en minuscules :

export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export no_proxy="$NO_PROXY"

Configuration du proxy pour Cursor

Cursor utilise partiellement les paramètres proxy système de l'OS (surtout sur macOS et Windows), mais pour un fonctionnement stable dans un réseau d'entreprise, il est préférable de les configurer explicitement via des variables d'environnement et, si nécessaire, via le fichier de configuration de l'application.

Sur macOS et Linux, il est plus simple d'ajouter l'exportation des variables dans le fichier de profil de la shell, afin qu'elles soient prises en compte à chaque lancement du terminal à partir duquel Cursor est lancé :

# ~/.zshrc ou ~/.bash_profile
export HTTP_PROXY="http://user:[email protected]:8080"
export HTTPS_PROXY="http://user:[email protected]:8080"
export NO_PROXY="localhost,127.0.0.1,*.company.local"

Après avoir modifié le fichier de profil, exécutez source ~/.zshrc et redémarrez complètement Cursor (ne vous contentez pas de réduire la fenêtre — terminez le processus via le Moniteur d'activité ou le gestionnaire de tâches, car les applications Electron mettent en cache l'environnement au démarrage).

Sur Windows, il est plus pratique de définir les variables via les paramètres système d'environnement (Panneau de configuration → Système → Paramètres système avancés → Variables d'environnement) ou via PowerShell pour une sauvegarde permanente :

[System.Environment]::SetEnvironmentVariable('HTTPS_PROXY','http://user:[email protected]:8080','User')
[System.Environment]::SetEnvironmentVariable('HTTP_PROXY','http://user:[email protected]:8080','User')
[System.Environment]::SetEnvironmentVariable('NO_PROXY','localhost,127.0.0.1','User')

Si après cela, Cursor ne se connecte toujours pas à l'API des modèles, vérifiez les paramètres du proxy dans l'application elle-même : Paramètres → Réseau (ou Général) — il peut y avoir un champ Proxy URL distinct qui remplace les variables système. Dans certaines versions de Cursor, il est également nécessaire d'activer explicitement l'option « Utiliser les paramètres proxy système ».

Configuration du proxy pour Claude Code

Claude Code est un outil CLI sur Node.js, lancé via npm/npx, donc il lit directement les variables d'environnement de la session de terminal dans laquelle il a été appelé. Cela simplifie la configuration : il suffit d'exporter les variables avant le lancement.

export HTTPS_PROXY="http://user:[email protected]:8080"
export HTTP_PROXY="http://user:[email protected]:8080"
claude

Si vous lancez Claude Code dans le cadre d'un pipeline CI ou à partir d'un script, passez les variables explicitement dans la commande de lancement, pour éviter la dépendance à l'environnement global de la shell :

HTTPS_PROXY="http://proxy.company.local:8080" \
HTTP_PROXY="http://proxy.company.local:8080" \
claude --print "Vérifiez les tests dans le projet"

Pour une configuration permanente, il est plus pratique de fixer les variables dans un fichier .env à la racine du projet et de le charger via direnv ou le support intégré de dotenv, si votre shell le prend en charge. C'est particulièrement pratique lorsque différents projets nécessitent différentes configurations de proxy (par exemple, un projet fonctionne avec une API interne, tandis qu'un autre fonctionne avec des services externes).

Authentification sur le proxy d'entreprise

La plupart des proxies d'entreprise nécessitent une authentification — Basic Auth, Digest ou NTLM. Pour Basic Auth, le login et le mot de passe peuvent être intégrés directement dans l'URL du proxy, comme indiqué ci-dessus : http://user:[email protected]:8080. Un point important — si le mot de passe contient des caractères spéciaux (@, #, %), ils doivent être encodés en URL, sinon le parseur de chaîne du proxy échouera à la frontière entre le login et l'hôte.

# Si le mot de passe est P@ssw0rd#2024, encodez les caractères spéciaux :
# @ -> %40, # -> %23
export HTTPS_PROXY="http://user:P%40ssw0rd%[email protected]:8080"

C'est plus compliqué avec l'authentification NTLM (souvent utilisée avec Microsoft ISA Server, Forefront TMG ou Fortinet) — Node.js et la plupart des clients HTTP ne prennent pas en charge NTLM « par défaut ». Dans ce cas, la solution standard consiste à mettre en place un proxy intermédiaire local qui gère la poignée de main NTLM, puis fournit un « proxy HTTP propre » pour l'application. Pour cela, on utilise souvent cntlm ou px (proxy NTLM local en Python). Le schéma est simple : Cursor/Claude Code → localhost:3128 (cntlm) → proxy NTLM d'entreprise → Internet.

# Exemple de configuration de cntlm (/etc/cntlm.conf)
Username    votre_login
Domain      ENTREPRISE
Password    votre_mot_de_passe_ou_hash
Proxy       proxy.company.local:8080
Listen      3128

# Après avoir démarré cntlm, indiquez l'adresse locale :
export HTTPS_PROXY="http://127.0.0.1:3128"
export HTTP_PROXY="http://127.0.0.1:3128"

Certificats et MITM : problème SSL dans un réseau d'entreprise

Si l'entreprise déploie un produit de type Zscaler, Netskope ou tout autre filtre web avec inspection SSL, le trafic est déchiffré sur le proxy et signé avec le certificat CA racine d'entreprise. Node.js (et donc Claude Code, ainsi que la plupart des modules internes de Cursor) fait par défaut confiance uniquement à son ensemble intégré de certificats racines et renverra une erreur UNABLE_TO_VERIFY_LEAF_SIGNATURE ou certificat auto-signé dans la chaîne de certificats.

La solution consiste à exporter le certificat CA d'entreprise (généralement, il peut être obtenu auprès du service informatique ou extrait du magasin de certificats du navigateur) et à indiquer à Node.js le chemin vers celui-ci via la variable NODE_EXTRA_CA_CERTS :

export NODE_EXTRA_CA_CERTS="/etc/ssl/certs/company-root-ca.pem"

Il est fortement déconseillé de désactiver globalement la vérification des certificats via NODE_TLS_REJECT_UNAUTHORIZED=0 — cela supprime la protection contre les attaques MITM sur tout le processus, y compris les connexions légitimes. Utilisez ce drapeau uniquement pour un diagnostic ponctuel et assurez-vous de rétablir la protection par la suite.

Erreurs courantes et leurs solutions

Erreur	Cause	Solution
ETIMEDOUT / ECONNREFUSED	Les variables proxy ne sont pas exportées dans la session où l'application est exécutée	Vérifiez echo $HTTPS_PROXY dans le même terminal, redémarrez complètement l'application
407 Proxy Authentication Required	Login/mot de passe non spécifiés ou obsolètes	Mettre à jour les informations d'identification dans la chaîne proxy, encoder les caractères spéciaux du mot de passe
certificat auto-signé dans la chaîne de certificats	Le proxy MITM d'entreprise remplace le certificat	Indiquer NODE_EXTRA_CA_CERTS avec le CA racine d'entreprise
Le proxy fonctionne dans le terminal, mais pas dans Cursor	Cursor n'est pas lancé depuis le bon terminal ou via un raccourci sans environnement	Lancer Cursor avec la commande depuis le terminal avec les variables exportées, ou définir les variables globalement dans le système
NTLM authentication failed	Le client ne prend pas en charge la poignée de main NTLM	Mettre en place un proxy intermédiaire cntlm ou px entre l'application et le proxy d'entreprise

Vérification de la connexion via curl

Avant de comprendre pourquoi Cursor ou Claude Code ne fonctionne pas, assurez-vous que le proxy est accessible et qu'il proxy correctement le trafic HTTPS. Pour cela, utilisez curl — il lit les mêmes variables d'environnement et permet de localiser rapidement le problème sans lancer des applications lourdes.

# Vérification de l'accessibilité du proxy et de l'authentification
curl -v -x "http://user:[email protected]:8080" https://api.anthropic.com

# Vérification en tenant compte du certificat d'entreprise
curl -v --cacert /etc/ssl/certs/company-root-ca.pem \
  -x "http://user:[email protected]:8080" \
  https://api.anthropic.com

Si curl reçoit une réponse avec succès (même 401 ou 403 — c'est normal, cela signifie que la poignée de main TLS a réussi), mais que Claude Code ne se connecte toujours pas — le problème ne vient pas du réseau, mais du fait que le processus ne voit pas les variables d'environnement. En revanche, si curl échoue également avec une erreur de certificat ou un délai d'attente — le problème se situe au niveau du réseau ou du proxy, et les outils n'y sont pour rien.

Quand un proxy externe est nécessaire au lieu d'un proxy d'entreprise

Parfois, la tâche ne se limite pas à l'accès depuis le réseau d'entreprise vers l'extérieur. Les développeurs qui testent des intégrations avec des API géo-dépendantes, vérifient le comportement du service depuis différents pays ou déboguent les politiques de limitation de taux des fournisseurs de modèles, se rendent compte que le proxy d'entreprise fournit la même adresse IP d'entreprise pour toutes les requêtes. Dans de tels scénarios, il est pratique de faire passer le trafic de test via un proxy externe parallèlement à l'environnement de travail principal.

Pour des sessions de test stables et de longue durée avec un risque minimal de blocage par IP, les proxies résidentiels sont adaptés — ils utilisent de vraies adresses IP de fournisseurs domestiques et ressemblent à un trafic utilisateur ordinaire, ce qui est important lors de la vérification des réponses API géo-spécifiques. Si vous devez reproduire le comportement d'un client mobile ou tester des scénarios sensibles au type de réseau, envisagez des proxies mobiles. Pour des tests massifs parallèles de requêtes à des API publiques, où la vitesse et le coût du trafic sont plus importants que la dissimulation en tant qu'utilisateur ordinaire, des proxies de centre de données suffisent généralement.

Important : un tel proxy externe est configuré de la même manière via les variables HTTPS_PROXY/HTTP_PROXY, mais pour un environnement de test ou un profil de terminal distinct, afin de ne pas le mélanger avec le trafic de travail principal via la passerelle d'entreprise. Si la politique de l'entreprise exige que tout le trafic de l'entreprise passe uniquement par le proxy interne, l'utilisation d'un proxy externe doit être approuvée par l'IT/Sécurité — de nombreuses entreprises interdisent explicitement le contournement de la passerelle d'entreprise sans autorisation.

Liste de contrôle de la configuration

Conclusion

La plupart des problèmes avec Cursor et Claude Code derrière un proxy d'entreprise se résument à trois choses : les variables d'environnement n'atteignent pas le processus, l'authentification est mal configurée, ou le certificat MITM d'entreprise n'est pas ajouté aux certificats de confiance. En vérifiant ces trois points dans l'ordre — via curl, et non directement via l'application elle-même — vous économisez des heures de débogage et localisez rapidement la cause.

Si la tâche dépasse le cadre du réseau d'entreprise et que vous devez tester le comportement de l'API depuis différentes régions ou avec différents types d'IP, nous vous recommandons d'essayer les proxies résidentiels — ils offrent un trafic stable et moins suspect pour les services externes par rapport aux adresses de centres de données ordinaires.