Proxy et VPN se font souvent confondre parce que tous deux s’interposent dans une communication. Il faut pourtant les distinguer nettement : le VPN chiffre l’ensemble de la liaison entre l’appareil et le réseau distant, tandis qu’un proxy relaie et filtre au niveau applicatif (HTTP/HTTPS) sans virtualiser le réseau dans son ensemble.
Trois modèles d’usage se distinguent : le forward proxy (ou proxy explicite) côté client, via PAC/WPAD et authentification ; le transparent proxy, interceptant le trafic au niveau du routeur ou du pare-feu, sans configuration côté client ; et le reverse proxy, côté serveurs, en frontal des applications publiées.
Le forward proxy
Un forward proxy est l’intermédiaire des postes internes lorsqu’ils accèdent au web : il filtre, met en cache, compresse, authentifie, et peut inspecter le TLS — si la politique de l’organisation l’autorise — pour appliquer ses règles.
flowchart LR C[Client interne] -->|HTTP/HTTPS| P[Forward proxy] P -->|Internet| W[Web/SaaS]
Ses fonctions principales : filtrage (conformité, contrôle parental ou d’entreprise, anti-malware, anti-phishing), cache d’objets statiques (images, JS, CSS — moins de bande passante consommée), compression, contrôle d’accès par utilisateur ou groupe (SSO NTLM/Kerberos/OIDC), masquage d’IP (la cible ne voit que l’IP du proxy), et parfois déchiffrement/rechiffrement TLS pour appliquer DLP ou antivirus — à réserver à un usage sélectif.
Les clients l’utilisent de deux façons : de manière explicite, via un fichier PAC (Proxy Auto-Config) ou WPAD, le navigateur sachant alors qu’il doit dialoguer avec le proxy ; ou de manière transparente, par interception au niveau du pare-feu ou du routeur — solution moins riche du point de vue de l’authentification.
Pièges classiques
L’inspection TLS impose des listes d’exemption (banques, santé), une communication claire aux utilisateurs, et une gestion soignée du certificat racine interne. Côté identité, privilégier le SSO (Kerberos/Negotiate, OIDC) plutôt que des mots de passe en clair. Les journaux, enfin, ne conservent que le strict nécessaire, dans le respect du RGPD — et le fichier PAC doit exclure explicitement les domaines internes, sous peine de détour inutile.
Le reverse proxy
Le reverse proxy est le frontal des applications web : il termine le TLS, répartit la charge, met en cache, réécrit des URL, authentifie avant d’atteindre le backend, et sert souvent de point d’ancrage au WAF. Les clients Internet dialoguent avec lui, jamais directement avec l’application.
flowchart LR U[Utilisateur Internet] --> RP[Reverse proxy] RP --> APP1[Backend 1] RP --> APP2[Backend 2]
Ses fonctions se déploient sur plusieurs plans : la terminaison TLS (certificats, ACME, renouvellement automatique, SNI multi-hôte) ; la répartition de charge proprement dite (round-robin, moindre nombre de connexions, hachage pour l’affinité, sondes de santé) ; le cache des pages statiques et des requêtes GET d’API, qui abaisse le temps de première réponse ; la réécriture des chemins et en-têtes ; l’authentification centralisée (OIDC/SAML) avant même d’atteindre l’application ; l’injection d’en-têtes de contexte (X-Forwarded-For, X-Forwarded-Proto, Forwarded) ; les en-têtes de sécurité (HSTS, CSP, X-Frame-Options, Referrer-Policy) ; et, pour les applications sensibles, le mTLS entre le proxy et le backend.
Pièges classiques
Sans injection soignée de
X-Forwarded-For, l’application perd toute connaissance de l’IP réelle du client. Si l’application maintient un état de session, une affinité (sticky session) par cookie ou par IP devient nécessaire. Forcer TLS 1.2/1.3 avec des chiffrements AEAD et l’agrafage OCSP est la norme minimale. Un WAF se déploie d’abord en mode détection, avant d’être basculé en blocage une fois les règles affinées. Et comme pour tout composant exposé, le reverse proxy vit en DMZ, avec des flux stricts vers le LAN.
Répartition de charge : ce que le reverse proxy n’est pas
Il faut ici lever une confusion fréquente : un reverse proxy n’est pas, en soi, un répartiteur de charge (load balancer, LB) — même s’il peut en embarquer les fonctions.
Le LB distribue les requêtes vers un pool de serveurs selon un algorithme (round-robin, moindre nombre de connexions, latence) couplé à des sondes de santé (health-checks). Le DNS round-robin, à l’inverse, est le « load-balancing du pauvre » : sans notion de disponibilité réelle ni de reprise fine, il peut fort bien continuer d’envoyer du trafic vers un nœud tombé en panne. Un reverse proxy comme Nginx ou HAProxy termine le TLS, met en cache, réécrit, route par contenu — mais ce n’est un LB à part entière que s’il en embarque explicitement les fonctions.
Repère mental
La couche 4 (TCP/UDP) est rapide et simple ; la couche 7 (URL, cookies, en-têtes) est plus fine, et c’est elle qui rend possibles l’affinité de session et la terminaison TLS.
flowchart LR C[Client] -->|HTTPS| RP[Reverse Proxy/LB] RP -->|HTTP| W1[Web01] RP -->|HTTP| W2[Web02] H((Health-check)) -.poll.-> W1 H -.poll.-> W2
Pour une haute disponibilité web typique, on combine reverse proxy avec terminaison TLS et LB de couche 7 vers un pool de serveurs, des sondes de santé sur un endpoint dédié, et une affinité de session si l’application la requiert. Un déploiement blue/green n’est qu’une variante de ce schéma : router 90 % du trafic vers une version stable, 10 % vers la nouvelle, et basculer si tout se passe bien. À l’inverse, une sonde de santé qui détecte une panne retire simplement le nœud défaillant du pool — sans intervention manuelle.