Dans une PME, les navigateurs et logiciels des salariés n’utilisent pas toujours le même chemin pour accéder à Internet. Un serveur proxy côté clients, aussi appelé proxy direct, sert d’intermédiaire pour les requêtes que les applications lui confient. Il peut aider à appliquer des règles communes ou à journaliser certains accès, mais ne protège pas automatiquement tout le trafic d’un appareil et ne rend pas les connexions anonymes.
Le choix dépend donc des applications concernées, des besoins de filtrage et de la confiance accordée à l’exploitant du proxy. Voici comment distinguer les options, préparer le déploiement et contrôler le résultat.
Pourquoi faire passer les postes par un proxy ?
Un proxy direct est un intermédiaire choisi par le client, généralement le navigateur ou une application. Celle-ci lui transmet une requête ; le proxy la relaie vers le site demandé, puis renvoie la réponse. La définition du protocole HTTP précise que le client peut choisir ce relais au moyen de sa configuration locale et que des organisations l’utilisent notamment pour regrouper des requêtes, appliquer des contrôles ou partager un cache, selon la spécification HTTP du RFC 9110. Un cache conserve certaines réponses pour éviter de les récupérer de nouveau, lorsque les règles applicables le permettent.
Pour une PME, ce dispositif peut faciliter l’application de règles d’accès communes, le contrôle de certaines destinations ou l’analyse d’incidents. Il peut aussi fournir un point de sortie unique pour les applications compatibles. Cela ne remplace toutefois ni une politique de sécurité, ni la protection des postes, ni la gestion des identités : un relais mal configuré ou indisponible peut au contraire devenir un point de panne partagé.
Le sujet relève de la rubrique technologie et infrastructures numériques. Il faut aussi distinguer le proxy direct du relais placé devant un serveur : dans le premier cas, le client choisit le proxy pour ses requêtes sortantes ; dans le second, le proxy reçoit des requêtes destinées à un service que l’organisation publie ou héberge.
Quelles informations le proxy peut-il voir ?
La confidentialité dépend du protocole utilisé entre le poste et le proxy, puis entre le proxy et le site. Avec un proxy HTTP ordinaire, les requêtes vers des sites en HTTP circulent sans chiffrement de bout en bout. Pour un site HTTPS, le navigateur peut demander au proxy d’établir un tunnel avec la méthode CONNECT, puis négocier TLS directement avec le site. Le RFC 9110 décrit CONNECT comme une demande de tunnel et indique que le nom de l’hôte figure dans la demande ; un proxy HTTP peut donc connaître la destination même lorsque le contenu HTTPS reste chiffré entre le navigateur et le site.
Le chiffrement TLS protège le contenu échangé après l’établissement du canal, mais ne masque pas toutes les métadonnées ni le volume des échanges. La spécification TLS 1.3 du RFC 8446 précise que TLS apporte confidentialité et intégrité aux données transmises, tout en notant que la longueur des données reste observable. Un proxy configuré pour inspecter le trafic HTTPS peut modifier ce modèle : il faut alors comprendre le mécanisme utilisé, la gestion des certificats et les données auxquelles l’exploitant peut accéder.
En pratique, demandez qui administre le proxy, quelles données sont consignées, qui peut consulter les journaux, combien de temps ils sont conservés et quelles applications sont inspectées. Un service externe ne doit pas être traité comme un simple réglage technique : il reçoit une partie des communications qui lui sont confiées. N’y transmettez pas des identifiants ou des données sensibles sans validation de la configuration et des règles internes.
Proxy, VPN ou accès direct : que choisir ?
Un proxy convient si le besoin porte sur des applications qui savent l’utiliser et sur des contrôles liés à leurs requêtes web. Un VPN répond à une autre logique : il établit un réseau virtuel par tunnel et peut protéger les échanges entre un appareil et une passerelle, selon les routes et protocoles configurés. Le glossaire du NIST consacré au VPN le décrit comme un lien ou réseau virtuel protégé qui s’appuie sur le tunneling et des contrôles de sécurité. Ni l’un ni l’autre ne rend automatiquement anonyme : le niveau de protection dépend de l’opérateur, des réglages et du trafic effectivement acheminé.
Microsoft documente plusieurs types de proxy dans Edge, ce qui illustre pourquoi il faut vérifier le cas concret plutôt que parler d’un proxy universel. Dans cette documentation, le proxy HTTP standard utilise le port par défaut 80, le proxy HTTPS 443, et SOCKS4 ou SOCKS5 1080. Ces valeurs sont des paramètres par défaut documentés pour Edge, pas des ports obligatoires : une entreprise peut configurer d’autres ports. La même page indique que, dans Edge, les proxys HTTP/1.1 sont limités à 32 connexions simultanées entre domaines ; ce détail concerne ce navigateur et ne doit pas être généralisé à tous les clients.
Le proxy HTTP(S) correspond souvent aux besoins de navigation web. SOCKS peut convenir à certains logiciels et usages réseau, mais la prise en charge varie selon l’application. Un VPN est à envisager quand le besoin est de joindre un réseau d’entreprise ou de faire transiter un ensemble plus large de communications. Enfin, l’accès direct reste pertinent pour les destinations internes ou les applications qui ne doivent pas emprunter le relais, à condition que les exceptions soient définies et maîtrisées.
Comment préparer le réglage des postes ?
Avant le déploiement, établissez une liste courte des applications et usages à couvrir : navigateur, outils bureautiques connectés, mises à jour, visioconférence et logiciels métier. Pour chacun, vérifiez s’il utilise les paramètres du système, ceux du navigateur ou ses propres réglages. La documentation Microsoft sur la prise en charge des proxys dans Edge distingue la configuration manuelle, les règles de contournement et le script PAC. Un PAC, pour Proxy Auto-Configuration, est un fichier de règles qui indique au client quel chemin utiliser selon l’adresse demandée.
Choisissez ensuite une méthode cohérente avec l’administration du parc. Un réglage manuel peut être simple pour un petit nombre de postes, mais devient difficile à maintenir à mesure que les exceptions changent. Une configuration automatique peut appliquer des règles selon la destination ; elle demande toutefois de contrôler le contenu et la disponibilité de la configuration. Dans les deux cas, consignez l’adresse du proxy, le port, les protocoles pris en charge, les mécanismes d’authentification et les destinations qui doivent rester en accès direct.
Évitez les exceptions trop larges : une règle de contournement mal écrite peut faire sortir du proxy des destinations qui devaient être contrôlées. À l’inverse, forcer toutes les connexions à passer par un relais qui ne prend pas en charge un protocole peut interrompre des fonctions métier. Pour réduire le risque, pilotez d’abord la configuration sur quelques postes représentatifs, puis élargissez-la après vérification des applications critiques.
Comment vérifier que le trafic suit le chemin prévu ?
Testez séparément les usages qui doivent passer par le proxy et ceux qui doivent le contourner. Contrôlez l’accès à un site HTTP et à un site HTTPS, l’authentification, les ressources internes et les applications non intégrées au navigateur. Confirmez également le comportement en cas d’indisponibilité du proxy : selon les règles choisies, l’application peut s’arrêter, essayer un relais secondaire ou basculer en accès direct. Ce dernier comportement peut améliorer la continuité, mais il peut aussi contourner les contrôles attendus.
Comparez les journaux du proxy avec les résultats observés côté client : adresse de destination, heure, utilisateur ou poste, décision d’accès et erreur éventuelle. Ne concluez pas qu’un poste est entièrement couvert parce que le navigateur affiche le bon proxy ; vérifiez les clients réseau séparément. Une réponse HTTP 407 signale une demande d’authentification du proxy, tandis qu’une erreur serveur 500 renvoie à un problème côté service destinataire ou à un intermédiaire. Pour distinguer ces cas et orienter le diagnostic, examinez les vérifications liées à une erreur serveur 500.
Enfin, refaites ces contrôles après une modification de règles, de certificat, de logiciel ou de réseau. Le résultat utile n’est pas seulement que la page s’ouvre : c’est de confirmer que chaque application suit le chemin prévu, que les exceptions sont limitées et que les données visibles par le proxy correspondent à ce que l’entreprise accepte de lui confier.
Questions fréquentes
Un proxy modifie-t-il l’adresse IP visible par les sites ?
Pour les requêtes qui passent par lui, un proxy peut présenter sa propre adresse de sortie au serveur destinataire. Cela ne garantit pas l’anonymat : le proxy connaît au minimum les connexions qu’il relaie, et les requêtes ou applications peuvent transmettre d’autres informations. Les connexions directes, les règles de contournement et les logiciels qui ignorent le proxy suivent un autre chemin.
Un proxy protège-t-il le Wi-Fi public comme un VPN ?
Pas à lui seul. Un proxy ne traite que le trafic que l’application dirige vers lui. Une connexion HTTPS conserve généralement son chiffrement TLS jusqu’au site, mais le proxy peut voir des informations de connexion comme la destination. Pour protéger un ensemble plus large de communications entre l’appareil et un réseau distant, un VPN établit un tunnel selon sa configuration.
Pourquoi certains logiciels ne passent-ils pas par le proxy du navigateur ?
Les logiciels choisissent eux-mêmes comment accéder au réseau : certains reprennent les réglages système ou du navigateur, d’autres ont leur propre configuration, et certains ne prennent pas en charge le proxy utilisé. Il faut donc vérifier chaque application importante, notamment les outils de mise à jour, de visioconférence et les clients métier, plutôt que de supposer qu’un réglage du navigateur couvre le poste entier.
Que signifie l’erreur 407 avec un proxy ?
Le code HTTP 407 signifie que le proxy demande une authentification avant de relayer la requête. Vérifiez que l’utilisateur dispose des droits nécessaires, que le logiciel sait gérer la méthode d’authentification attendue et que l’horloge ou les identifiants du poste ne posent pas problème. Dans une organisation, les journaux du proxy et du client aident à distinguer un refus d’accès d’une panne réseau.
