Contournement de pare-feu, mise en cache, équilibrage de charge, résiliation TLS, diffusion de contenu, passerelles API, sortie de données d'entreprise, collecte de données géolocalisées et, de plus en plus, trafic de requêtes d'IA en amont. La première utilisation documentée, dans l'article du CERN d'avril 1994, consistait à permettre au personnel situé derrière un pare-feu d'accéder au Web extérieur.
Les serveurs proxy existent depuis les débuts du Web : un bref historique de leur fonctionnement réel
Un ingénieur du CERN et un ingénieur d'Intel ont publié en avril 1994 le premier article décrivant un proxy du World Wide Web (Luotonen et Altis, Proxys du World Wide Web, 1994). Le Web lui-même existait depuis trois ans. Les serveurs proxy ne constituent pas une solution de contournement ajoutée a posteriori à Internet. Ils sont apparus en même temps que celui-ci.
Il est intéressant de connaître cette histoire, car ce métier n'a pratiquement pas évolué en trente ans. Un mandataire Il s'agit d'une machine qui effectue une requête pour le compte d'un tiers et lui transmet le résultat. Tout ce qui a été mis en place depuis 1994 – les hiérarchies de mise en cache, les réseaux de diffusion de contenu, les passerelles d'entreprise, les réseaux d'appareils alimentant aujourd'hui les systèmes d'intelligence artificielle – n'est que cette idée unique appliquée à une échelle de plus en plus grande.
Points clés à retenir
- Le premier article consacré aux proxys Web a été publié en avril 1994 par le CERN ; il traitait déjà le contournement des pare-feu et la mise en cache comme une seule et même tâche (Luotonen et Altis, 1994).
- Le protocole SOCKS fête cette année ses trente-quatre ans. Il s'agit toujours d'un protocole pris en charge.
- Cloudflare a indiqué le 1er juillet 2026 qu'en juin 2026, plus de 50 % du trafic Internet n'était pas généré par des humains.
- Les proxys inversés, les CDN, les équilibreurs de charge et les passerelles API constituent un même mécanisme sous des noms différents.
D'où vient réellement le proxy Web ?
En avril 1994, Ari Luotonen, du CERN, et Kevin Altis, d'Intel, ont publié Proxys du World Wide Web, décrivant un serveur qui permettait aux utilisateurs de sous-réseaux fermés d'accéder au Web via un pare-feu (Archives du W3C, 1994). Cet article a ensuite été publié dans Réseaux informatiques et systèmes RNIS. Le problème qu'il a permis de résoudre était tout à fait banal : les employés protégés par le pare-feu de l'entreprise ne pouvaient pas accéder au Web extérieur, et quelqu'un devait servir d'intermédiaire.
C'est là tout le principe, et cela n'a pas changé. Un proxy est un serveur qui effectue une requête en votre nom. La mise en œuvre du CERN, cern_httpd, prenait en charge les protocoles HTTP, Gopher, WAIS et FTP, ce qui vous donne une idée de l'époque à laquelle cela remonte.
Au départ, le cas d'usage visait l'accès, et non le contournement. Une entreprise souhaitait que ses collaborateurs puissent accéder à Internet sans avoir à ouvrir une brèche dans le pare-feu pour chaque poste de travail. Le proxy constituait cette brèche, unique, supervisée et faisant l'objet d'un journal de suivi.
Voici le point qui passe souvent inaperçu. L’article de 1994 considère la mise en cache et le contrôle d’accès comme un même ensemble de fonctionnalités, fournies par le même dispositif. Tous les débats que nous menons encore en 2026, concernant qui peut récupérer quoi, à quelle fréquence, et si le serveur d’origine doit en supporter le coût, étaient déjà perceptibles dans un article rédigé avant même que la majeure partie du Web n’existe.
Pour connaître les différences concrètes entre les différents types de réseaux, veuillez consulter Comparaison entre les proxys résidentiels et ceux destinés aux centres de données, ou commencez par Qu'est-ce qu'un proxy résidentiel ?.
Pourquoi le Web de ses débuts avait-il besoin de serveurs proxy pour survivre ?
La bande passante constituait la contrainte limitante, et les proxys de mise en cache étaient la solution. Squid, qui est encore largement utilisé aujourd’hui comme proxy de mise en cache, a vu sa version 1.0.0 sortir en juillet 1996 ; il s’agissait d’un fork réalisé par Duane Wessels à partir du cache d’objets Harvest développé à l’université du Colorado à Boulder (Projet « Squid Web Cache », consulté le 31 août 2026).
En 1996, une université payait sa connexion au mégaoctet. Si quatre mille étudiants consultaient chacun la même page d'accueil, l'établissement payait quatre mille fois pour un seul document. Un proxy de mise en cache a permis de réduire ce nombre de requêtes à une seule. Les caches Harvest pouvaient être organisés en hiérarchies et communiquer entre eux via le protocole ICP (Internet Cache Protocol), de sorte qu’une requête non satisfaite sur un campus pouvait être traitée par un campus voisin plutôt que par le serveur d’origine.
C'est grâce aux proxys de mise en cache que le Web des années 1990 pouvait s'afficher. Il ne s'agit ni d'une question de sécurité ni d'une question de vie privée. C'est une question économique, et les enjeux économiques ont refait surface.
Quel problème le protocole SOCKS visait-il à résoudre en 1992 ?
SOCKS a précédé de deux ans l'article sur les proxys Web. En septembre 1992, David Koblas et Michelle R. Koblas ont présenté CHAUSSETTES lors du troisième symposium USENIX sur la sécurité UNIX, à Baltimore (Actes de la conférence USENIX, 1992), et le protocole a été rendu accessible au public à partir de ce moment-là. La version 5 a été normalisée sous le nom de RFC 1928 en mars 1996, qui décrit un cadre permettant aux applications client-serveur d'« utiliser de manière pratique et sécurisée les services d'un pare-feu réseau ».
Relisez cette phrase. L'IETF elle-même, en 1996, mettait l'accent sur la sécurité et la commodité. Pas sur l'anonymat.
Ce schéma se retrouve tout au long de l'évolution de la lignée. Chacune des étapes clés ci-dessous a permis de résoudre un problème opérationnel spécifique, et chacun de ces problèmes persiste encore aujourd'hui :
C'est Tor dont tout le monde se souvient, alors qu'il est arrivé dix ans après les autres. Il s'agissait du huitième acte de cette histoire, et non du premier.
Le routage en oignon, ancêtre de Tor, est né à la même époque et dans un contexte institutionnel similaire. En 1995, David Goldschlag, Michael Reed et Paul Syverson, du Laboratoire de recherche de la Marine américaine, ont commencé à se demander s'il était possible d'établir des connexions Internet sans révéler qui communiquait avec qui. Ces travaux ont donné naissance aux premiers concepts et prototypes de routage en oignon, dont l'objectif était de protéger les communications gouvernementales transitant par les réseaux publics (Historique du projet Tor, consulté le 31 août 2026). La technologie qui est par la suite devenue synonyme du « dark web » a été financée par la Marine américaine afin d'empêcher que les communications du renseignement puissent être facilement identifiées.
Dans quelles situations les mandataires interviennent-ils au quotidien ?
La plupart d’entre eux. Un proxy inverse Il s’agit de la même machine orientée dans l’autre sens, travaillant pour le propriétaire du site plutôt que pour l’utilisateur, et on en trouve une devant presque tous les sites web que vous avez consultés aujourd’hui. Les réseaux de diffusion de contenu (CDN) sont des proxys de mise en cache déployés en périphérie. Les équilibreurs de charge sont des proxys. La résiliation TLS en amont d’un serveur d’applications est un proxy. Les passerelles de sortie d’entreprise, les filtres de contenu des établissements scolaires et des bibliothèques, les passerelles API, les maillages de services : ce sont tous des proxys, qui font exactement ce que faisait le boîtier du CERN en 1994.
C'est le vocabulaire qui est intéressant. Lorsque l'intermédiaire travaille pour le propriétaire du site, on parle dans le milieu d'« infrastructure » et on l'indique sur le schéma d'architecture. Lorsqu'il travaille pour la partie qui envoie la requête, on parle alors de « proxy ». Il s'agit de la même machine, occupant la même position dans le chemin de la requête. Seule la direction de la flèche a changé, et avec elle, le terme utilisé.
Bon à savoir, ne serait-ce que pour que le schéma d'architecture et la liste des fournisseurs ne donnent plus l'impression de correspondre à deux technologies différentes.
Pourquoi le Web a-t-il plus que jamais besoin de serveurs proxy ?
Car le Web a cessé d’être principalement humain. Dans un rapport publié le 1er juillet 2026, Cloudflare a constaté qu’en juin 2026, plus de 50 % du trafic sur Internet n’était pas d’origine humaine, et que 52 % des requêtes des robots d’indexation concernaient l’entraînement de l’IA, contre 22 % au printemps 2025 (Cloudflare, La Journée de l'indépendance du contenu, un an après, 1er juillet 2026).
Dans ce même rapport de 2026, Cloudflare a également constaté que, pour chaque heure passée en ligne à rechercher des informations, seules quinze minutes sont consacrées au Web ouvert, et que certaines des catégories les plus explorées par les robots d'indexation ont enregistré une baisse du trafic humain pouvant atteindre 40 % en moins d'un an (Cloudflare, 1er juillet 2026).
Mettez ces deux constatations côte à côte et la nature du problème apparaît clairement. Les machines se chargent de la majeure partie de la collecte d’informations, les utilisateurs passent la majeure partie de leur temps sur les moteurs de recherche, et le Web ouvert est plus consulté que jamais tout en étant moins visité que jamais. Chacune de ces lectures effectuées par des machines doit bien provenir de quelque part. Il s’agit là d’une question secondaire, mais qui est désormais la question centrale.
Comment se construit un réseau d'appareils modernes ?
En matière de consentement. Massive a vu le jour en tant que produit de monétisation d’applications, dans lequel les utilisateurs échangeaient une partie de leur puissance de calcul inutilisée contre des fonctionnalités premium, et chaque adresse IP est enregistrée via le SDK Massive. Cela représente plus d’un million d’appareils résidentiels vérifiés dans plus de 195 pays, certifiés SOC 2, conformes au RGPD et certifiés AppEsteem, avec une piste d’audit complète de la source à la requête. L’opérateur peut ainsi identifier la connexion à l’origine d’une requête donnée.
Il ne s'agit pas d'une nouvelle obligation. Le proxy du CERN enregistrait chaque requête qui transitait par lui, car un administrateur système devait pouvoir rendre compte du trafic. Un réseau de terminaux répond à la même question à un niveau inférieur : il ne s'agit pas seulement de savoir ce qui a été demandé, mais aussi quelle connexion l'a acheminé, et selon quelles conditions celle-ci a accepté de le faire.
Au-dessus de ce réseau se trouve une couche de rendu qui génère du code HTML ou Markdown propre à partir de n'importe quelle source publique, où qu'elle se trouve. Il s'agit là du problème tel qu'il était défini en 1994 : accéder au Web public depuis n'importe quel endroit où vous en avez réellement besoin, avec les formats de sortie attendus par un pipeline de 2026.
Pour une analyse plus approfondie de la question du consentement dans les réseaux d'appareils, veuillez consulter À quoi ressemble le consentement dans le cadre du partage de bande passante ?.
Vous développez un projet qui nécessite l'accès au Web public ?
Le même travail, mais à une échelle bien plus grande
Les proxys ont résolu un véritable problème en 1994 et ils en résolvent une version plus importante en 2026, pour la même raison dans les deux cas. Quelqu’un a besoin d’accéder à une ressource à laquelle il ne peut pas accéder directement, et un intermédiaire doit s’interposer pour s’en charger efficacement.
Ce qui a changé, c’est l’ampleur du phénomène et l’identité de ceux qui en sont à l’origine. Le serveur du CERN desservait un seul laboratoire protégé par un pare-feu. Aujourd’hui, l’équivalent consiste à générer un trafic provenant de machines qui dépasse désormais le trafic humain sur Internet, depuis les bons endroits, sur des appareils dont les propriétaires ont accepté de les transporter.
Trente-deux ans plus tard, il s'agit toujours d'un système intermédiaire qui transmet une demande au nom d'une personne et en conserve une trace.
Pour en savoir plus sur l'évolution de la situation économique, consultez Le blocage des robots d'indexation basés sur l'IA, le paiement à l'indexation et ce que cela implique pour les agents.
Sources
- Luotonen, A. et Altis, K., Proxys du World Wide Web, CERN et Intel, avril 1994. Consulté le 31 août 2026. https://www.w3.org/History/1994/WWW/Proxies/
- Koblas, D. et Koblas, M. R., CHAUSSETTES, UNIX Security Symposium III, Association USENIX, Baltimore, septembre 1992, p. 77-83. Consulté le 31 août 2026. https://www.usenix.org/conference/sec92/socks
- IETF, RFC 1928 : Protocole SOCKS version 5, mars 1996. Consulté le 31 août 2026. https://www.rfc-editor.org/rfc/rfc1928.html
- Projet « Squid Web Cache », Qu'est-ce que Squid ?. Consulté le 31 août 2026. https://wiki.squid-cache.org/SquidFaq/AboutSquid
- Projet Tor, Histoire. Consulté le 31 août 2026. https://www.torproject.org/about/history/
- Cloudflare, « Content Independence Day », un an après : élaborer le modèle économique d’un Internet « agentique », 1er juillet 2026. Consulté le 31 août 2026. https://blog.cloudflare.com/agentic-internet-bot-report/
Foire aux questions
À quoi servent réellement les serveurs proxy ?
Quel a été le premier proxy Web ?
cern_httpd, décrit dans Proxys du World Wide Web par Ari Luotonen et Kevin Altis en avril 1994. Ce système permettait aux utilisateurs de sous-réseaux fermés d’accéder aux protocoles HTTP, Gopher, WAIS et FTP à travers un pare-feu, et il mettait les réponses en cache afin que les requêtes répétées ne sollicitent pas deux fois le serveur d’origine.
Un CDN est-il un proxy ?
Oui. Un réseau de diffusion de contenu (CDN) est un proxy inverse à mise en cache distribué. Il remplit les deux mêmes fonctions décrites dans l’article du CERN de 1994 : il s’interpose entre la requête et la réponse et met cette dernière en cache, la flèche pointant vers le propriétaire du site plutôt que vers le demandeur.
Pourquoi le trafic proxy est-il en augmentation en 2026 ?
En effet, la majeure partie du trafic web n'est plus générée par des humains. Cloudflare a indiqué le 1er juillet 2026 qu'en juin 2026, le trafic non humain avait dépassé les 50 % et que 52 % des requêtes des robots d'indexation concernaient l'entraînement de l'IA, contre 22 % au printemps 2025. L'entraînement des modèles, la récupération de données et les flux de travail des agents s'effectuent tous à l'échelle des machines.
Comment fonctionne le consentement sur un réseau résidentiel ?
Le propriétaire de l'appareil donne son accord dès le départ, généralement en échange d'un avantage concret, tel que des fonctionnalités premium de l'application, et peut se rétracter. C'est la certification indépendante (SOC 2, RGPD, AppEsteem) qui fait la différence entre une politique déclarée et une politique vérifiée.