Proxies pour GitHub depuis l'Iran : comment un développeur sous sanctions peut conserver l'accès au code

```html

GitHub a bloqué l'accès pour les utilisateurs d'Iran en 2019 à la demande de l'OFAC — le régulateur américain qui contrôle le respect des sanctions. Depuis lors, les développeurs iraniens font face à la même situation : les dépôts sont inaccessibles, les push et pull échouent, et le compte peut être gelé à tout moment. Cependant, le travail ne s'arrête pas — les équipes continuent de committer, déployer et participer à des projets open-source. Dans cet article, nous examinons ce qui fonctionne réellement en 2024–2025, quels proxies conviennent à GitHub, et comment les configurer correctement sans perte de vitesse.

Pourquoi GitHub bloque l'Iran : sanctions et mise en œuvre technique

En juillet 2019, GitHub a commencé à restreindre l'accès pour les utilisateurs d'Iran, de Crimée, de Cuba, de Syrie et de Corée du Nord. La raison en est les exigences de l'OFAC (Office of Foreign Assets Control) dans le cadre de la législation sur les sanctions américaine. Microsoft, propriétaire de GitHub depuis 2018, est tenu de respecter ces restrictions en tant qu'entreprise américaine.

Techniquement, le blocage fonctionne à plusieurs niveaux :

• Géoblocage par IP : GitHub détermine le pays par l'adresse IP et bloque les requêtes provenant de la plage d'adresses iraniennes (blocs AS appartenant aux fournisseurs iraniens).
• Gel des comptes : Les comptes enregistrés avec des IP iraniennes ou indiquant l'Iran dans le profil peuvent être mis en mode lecture seule ou complètement gelés.
• Blocage des dépôts privés : Les dépôts publics sont partiellement accessibles en lecture, mais les dépôts privés sont complètement fermés.
• Restrictions sur GitHub Actions et Packages : Les pipelines CI/CD et les registres de packages sont également inaccessibles depuis les régions bloquées.

Cependant, GitHub a déclaré à plusieurs reprises qu'il s'opposait à ces restrictions et fait pression pour des assouplissements auprès des régulateurs. En 2019, la société a obtenu l'autorisation de fournir un accès gratuit aux dépôts publics pour les développeurs iraniens, mais le blocage complet n'a toujours pas été levé.

⚠️ Il est important de comprendre : Le blocage vise les organisations et les structures gouvernementales sous sanctions, et non les développeurs individuels. La plupart des programmeurs iraniens travaillent dans des équipes internationales et ne sont pas personnellement soumis aux sanctions — mais techniquement, le système bloque tout le monde par IP.

C'est pourquoi la solution au problème réside dans le changement d'adresse IP — c'est le seul moyen de contourner techniquement le géoblocage. Voyons quels outils conviennent à cela.

Ce qui fonctionne réellement : proxies, VPN et contournements

Les développeurs iraniens utilisent plusieurs approches. Chacune a ses avantages et ses inconvénients — examinons-les honnêtement, sans marketing.

1. Proxies résidentiels

Les proxies résidentiels utilisent de vraies adresses IP d'utilisateurs domestiques d'autres pays — Allemagne, Pays-Bas, États-Unis, Turquie. Du point de vue de GitHub, cette requête ressemble à celle d'un utilisateur ordinaire d'un pays autorisé. C'est l'option la plus fiable pour un travail permanent : risque minimal de blocage du proxy lui-même, haute stabilité.

Inconvénient : la vitesse est inférieure à celle des proxies de centres de données, et le coût est plus élevé. Pour les opérations Git (push/pull/clone), cela n'est généralement pas critique : les dépôts pèsent des mégaoctets, pas des gigaoctets.

2. Proxies de centres de données

Les proxies de centres de données fonctionnent plus rapidement et coûtent moins cher. Ils conviennent pour cloner de grands dépôts, télécharger des artefacts, travailler avec l'API GitHub. Cependant, les IP des centres de données sont plus faciles à identifier comme proxies — certaines plages sont déjà sur les listes noires de GitHub. Nous recommandons d'utiliser des proxies de centres de données provenant de localisations européennes (DE, NL, FR) — elles sont moins souvent bloquées.

3. VPN

Le VPN est l'outil le plus populaire parmi les utilisateurs iraniens. Il fonctionne au niveau de l'ensemble du système d'exploitation, ne nécessite pas de configuration dans chaque application séparément. Inconvénients : de nombreux serveurs VPN sont déjà bloqués par GitHub (en particulier les gratuits populaires), la vitesse est instable, et en cas de rupture de connexion, le trafic peut fuir via l'IP iranienne.

4. Tor

Tor fonctionne techniquement, mais GitHub bloque activement les nœuds de sortie de Tor. La vitesse est extrêmement basse — cloner même un petit dépôt peut prendre des heures. Pour un accès occasionnel à l'interface web, cela peut convenir, mais pas pour un développement régulier.

5. Tunnels SSH via un serveur dans un autre pays

Si vous avez un VPS en Europe ou aux États-Unis, vous pouvez créer un proxy SOCKS5 via un tunnel SSH. C'est techniquement fiable et gratuit (si vous avez un serveur), mais cela nécessite des connaissances de base en Linux. Plus de détails sur la configuration se trouvent dans la section sur Git.

Quels types de proxies conviennent à GitHub : tableau comparatif

Examinons toutes les options dans un tableau pour faciliter le choix selon votre situation :

Si votre compte a déjà reçu des avertissements ou a été temporairement gelé, envisagez d'utiliser des proxies mobiles — ils utilisent des IP des opérateurs de téléphonie mobile, que GitHub ne bloque pratiquement jamais, car derrière une IP mobile se trouvent des milliers d'utilisateurs.

Comment configurer un proxy dans Git, le terminal et l'IDE : guide étape par étape

Le principal avantage de la configuration du proxy directement dans Git (et non au niveau système ou VPN) est que vous contrôlez quel trafic passe par le proxy. Les requêtes locales restent directes, seul le trafic GitHub est acheminé via une IP externe.

Configuration d'un proxy HTTPS dans Git (globalement)

Ouvrez le terminal et exécutez les commandes suivantes, en remplaçant HOST et PORT par les données de votre proxy :

# Pour un proxy HTTP/HTTPS :
git config --global http.proxy http://HOST:PORT

# Pour un proxy SOCKS5 (recommandé) :
git config --global http.proxy socks5://HOST:PORT

# Si le proxy nécessite une authentification (login + mot de passe) :
git config --global http.proxy socks5://USERNAME:PASSWORD@HOST:PORT

# Appliquer uniquement pour github.com (ne pas toucher aux autres dépôts) :
git config --global http.https://github.com.proxy socks5://HOST:PORT

La dernière commande est la plus utile : elle applique le proxy uniquement pour les requêtes vers github.com, sans affecter GitLab, Bitbucket ou les dépôts internes de l'entreprise.

Vérification de la configuration

# Voir les paramètres proxy actuels dans Git :
git config --global --list | grep proxy

# Tester la connexion à GitHub via le proxy :
git ls-remote https://github.com/github/gitignore HEAD

Si la commande ls-remote a renvoyé le hash du commit — le proxy fonctionne. Si vous obtenez une erreur Connection refused ou Could not resolve host — vérifiez l'exactitude de HOST et PORT.

Désactivation du proxy (lorsqu'il n'est pas nécessaire)

# Supprimer le proxy global :
git config --global --unset http.proxy

# Supprimer le proxy uniquement pour github.com :
git config --global --unset http.https://github.com.proxy

Configuration dans VS Code

VS Code utilise les paramètres proxy système pour le terminal intégré et les extensions. Si vous avez configuré le proxy dans Git via le terminal, le terminal intégré de VS Code adoptera automatiquement ces paramètres. Pour un proxy HTTP dans l'éditeur lui-même (par exemple, pour installer des extensions), ouvrez :

Fichier → Préférences → Paramètres → recherche "proxy" → indiquez l'adresse du proxy dans le champ http.proxy.

Configuration via un tunnel SSH (si vous avez votre propre VPS)

Si vous avez un VPS en Europe ou aux États-Unis, vous pouvez créer un proxy SOCKS5 local via SSH avec une seule commande :

# Créer un proxy SOCKS5 sur le port local 1080 via SSH :
ssh -D 1080 -C -N user@your-vps-ip

# Ensuite, dans Git, indiquez ce proxy local :
git config --global http.proxy socks5://127.0.0.1:1080

Le drapeau -D 1080 ouvre un proxy SOCKS5 sur le port 1080, -C active la compression, -N dit à SSH de ne pas exécuter de commandes — juste de maintenir le tunnel.

SSH vs HTTPS : ce qui fonctionne le mieux via un proxy pour GitHub

C'est l'une des questions les plus fréquentes : quel protocole utiliser pour travailler avec GitHub via un proxy — SSH (port 22 ou 443) ou HTTPS (port 443) ?

HTTPS via un proxy

Les connexions HTTPS sont faciles à proxy — les commandes git config http.proxy, que nous avons examinées ci-dessus, fonctionnent spécifiquement pour HTTPS. Inconvénient : à chaque push/pull, Git demande un login et un mot de passe (ou un Personal Access Token). La solution consiste à enregistrer le token dans le gestionnaire d'identifiants :

# Activer le stockage du token dans le trousseau système :
git config --global credential.helper store

# Après le premier push réussi, le token sera enregistré automatiquement

SSH via un proxy (ProxyCommand)

Les connexions SSH ne peuvent pas être proxy via le standard http.proxy dans Git — une configuration distincte est nécessaire dans ~/.ssh/config. Ajoutez le bloc suivant :

Host github.com
    HostName ssh.github.com
    User git
    Port 443
    ProxyCommand nc -X 5 -x HOST:PORT %h %p

Ici, ssh.github.com:443 est un point de terminaison SSH spécial de GitHub qui fonctionne sur le port 443 (HTTPS), ce qui aide à contourner les blocages sur le port 22. nc -X 5 utilise un proxy SOCKS5.

Vous pouvez vérifier la connexion SSH avec la commande :

ssh -T [email protected]
# Réponse attendue : Hi username! You've successfully authenticated...

Risques pour le compte et comment les minimiser

L'utilisation de proxies pour GitHub n'est pas seulement une question technique, mais aussi une question de sécurité du compte. Une mauvaise configuration peut attirer l'attention sur le compte ou créer de nouveaux problèmes.

Risque 1 : Changement constant d'IP

Si vous utilisez des proxies rotatifs (l'IP change à chaque requête ou toutes les quelques minutes), GitHub peut détecter une activité suspecte : un compte se connecte depuis des dizaines d'IP différentes en peu de temps. Cela déclenche une vérification de sécurité et un potentiel blocage.

Solution : Utilisez des proxies statiques (sticky) avec une IP fixe ou des proxies de session avec une longue durée de session (à partir de 24 heures). Pour GitHub, la rotation n'est pas nécessaire — la stabilité est requise.

Risque 2 : Utilisation d'IP de centres de données bloquées

Certaines plages d'IP de fournisseurs d'hébergement populaires (AWS, DigitalOcean, Vultr) sont déjà sur les listes noires ou suscitent une attention accrue. GitHub ne les bloque pas directement, mais peut demander une vérification supplémentaire.

Solution : Choisissez des centres de données européens (DE, NL, CH) — ils sont moins souvent bloqués. Avant une utilisation permanente, vérifiez l'IP via ipinfo.io ou scamalytics.com.

Risque 3 : Données iraniennes dans le profil

Si votre profil GitHub indique l'Iran (dans le champ Localisation), le compte a plus de chances d'être soumis à des restrictions, indépendamment de l'IP. Cela ne signifie pas qu'il faut cacher son origine — mais il est important de comprendre que c'est un facteur supplémentaire.

Risque 4 : Travailler avec des dépôts organisationnels

Si votre organisation sur GitHub est enregistrée en tant qu'entreprise iranienne ou a des administrateurs iraniens, les restrictions peuvent être plus strictes — jusqu'à geler l'ensemble de l'organisation. Dans ce cas, un proxy aide pour un compte personnel, mais ne résout pas le problème au niveau de l'organisation.

Que faire si le compte est déjà gelé

GitHub propose un processus officiel de dégel de compte pour les développeurs individuels. Écrivez à [email protected] en expliquant la situation. Dans le message, indiquez :

• Que vous êtes un développeur individuel, non lié à des organisations sous sanctions
• Que votre activité est open-source ou le développement commercial de logiciels
• Liens vers vos dépôts publics et votre activité

D'après l'expérience de la communauté, GitHub rétablit l'accès pour la plupart des développeurs individuels dans un délai de 1 à 4 semaines.

Checklist : vérification rapide de la configuration du proxy pour GitHub

Utilisez cette checklist pour vous assurer que tout est correctement configuré avant de commencer à travailler :

Conclusion

Les restrictions de sanctions de GitHub sont une réalité désagréable pour les développeurs iraniens, mais ce n'est pas une impasse. Une solution technique existe et fonctionne : un proxy avec une IP étrangère associé à une configuration correcte de Git permet de mener un développement complet — de pousser des commits, cloner des dépôts, travailler avec GitHub Actions et participer à des projets open-source.

Principales conclusions de l'article :

• Pour un travail quotidien, choisissez des proxies résidentiels ou de centres de données statiques d'Europe — une IP stable sans rotation.
• Configurez le proxy dans la configuration Git, et non au niveau système — cela donne un contrôle ciblé sans affecter tout le trafic.
• Si le compte est déjà sous suspicion — utilisez des IP mobiles, elles ne sont pratiquement jamais bloquées.
• Si le compte est gelé — écrivez à [email protected], GitHub rétablit l'accès pour les développeurs individuels.
• Utilisez SSH via le port 443 (ssh.github.com) — cela contourne la plupart des blocages au niveau du fournisseur.

Si vous recherchez une solution fiable pour un travail permanent avec GitHub, nous vous recommandons d'envisager des proxies résidentiels — ils utilisent de vraies IP d'utilisateurs domestiques de pays autorisés, attirent minimalement l'attention des systèmes de protection et assurent une connexion stable pour les opérations Git. Pour des tâches à forte charge (clonage de grands dépôts, pipelines CI/CD), une bonne alternative serait des proxies de centres de données — elles sont plus rapides et plus économiques pour le traitement de grands volumes de données.