# Les proxys sont aussi anciens que le 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, *World-Wide Web Proxies*](https://www.w3.org/History/1994/WWW/Proxies/), 1994). Le Web lui-même avait alors trois ans. Les proxys ne constituent pas une solution de contournement ajoutée a posteriori à Internet. Ils sont apparus en même temps que celui-ci.
Il est utile de connaître cette histoire, car leur rôle n’a pratiquement pas évolué en trente ans. **Un proxy** est une machine qui effectue une requête pour le compte d’un tiers et lui transmet le résultat. Tout ce qui s’est développé 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’IA, tout cela n’est que l’application de cette idée à une échelle de plus en plus grande.
> **Points clés à retenir**
> - Le premier article sur les proxys Web a été publié en avril 1994 par le CERN, et il traitait déjà le franchissement 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 est toujours 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 sont un même mécanisme portant 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é *World-Wide Web Proxies*, décrivant un serveur qui permettait aux utilisateurs de sous-réseaux fermés d’accéder au Web à travers un pare-feu ([archives du W3C](https://www.w3.org/History/1994/WWW/Proxies/), 1994). Cet article a ensuite été repris dans *Computer Networks and ISDN Systems*. Le problème qu’il résolvait était banal : les employés se trouvant derrière un pare-feu d’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 une machine 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.
Le cas d’usage initial concernait l’accès, et non le contournement. Une entreprise souhaitait que ses collaborateurs puissent accéder au Web sans avoir à ouvrir une brèche dans le pare-feu pour chaque poste de travail. Le proxy était cette « brèche », au singulier, supervisée et faisant l’objet d’un journal.
Voici la partie qui passe souvent inaperçue. L’article de 1994 traite 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 pratiques entre les types de réseaux, consultez [la comparaison entre les proxys résidentiels et ceux de centres de données](https://joinmassive.com/blog/residential-vs-datacenter-proxies-for-ai-agents), ou commencez par [découvrir ce qu’est un proxy résidentiel](https://joinmassive.com/blog/what-is-a-residential-proxy).
## Pourquoi le Web à ses débuts avait-il besoin de proxys 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 publié sa version 1.0.0 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](https://wiki.squid-cache.org/SquidFaq/AboutSquid), consulté le 31/08/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 à une seule requête. Les caches Harvest pouvaient être organisés en hiérarchies et communiquer entre eux via le protocole Internet Cache Protocol ; ainsi, en cas de « miss » sur un campus, la requête pouvait être traitée par un cache voisin plutôt que par le serveur d’origine.
Événements marquants espacés de manière régulière, non à l'échelle. Sources : archives du W3C (1994), USENIX (1992), RFC 1928 de l’IETF (1996), projet Squid Web Cache, projet Tor, Cloudflare (2026).
C’est grâce aux proxys de mise en cache que le Web des années 1990 a pu s’afficher. Il ne s’agit ni d’une question de sécurité ni d’une question de confidentialité. C’est une question d’économie, et cette dynamique économique est revenue au premier plan.
## Quel problème SOCKS résolvait-il en 1992 ?
SOCKS précède de deux ans l’article sur les proxys Web. En septembre 1992, David Koblas et Michelle R. Koblas ont présenté *SOCKS* lors du troisième symposium USENIX sur la sécurité UNIX à Baltimore ([actes de l’USENIX](https://www.usenix.org/conference/sec92/socks), 1992), et le protocole est devenu accessible au public à partir de ce moment-là. La version 5 a été normalisée sous la référence [RFC 1928](https://www.rfc-editor.org/rfc/rfc1928.html) en mars 1996 ; elle 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. La formulation même de l’IETF, en 1996, met l’accent sur la sécurité et la commodité. Pas sur l’anonymat.
Ce schéma se retrouve tout au long de l’histoire du protocole. Chacune des étapes clés ci-dessous a résolu un problème opérationnel spécifique, et chacun de ces problèmes existe toujours :
| Année | Étape clé | Le problème qu’elle a résolu |
|---|---|---|
| 1992 | Présentation de SOCKS à USENIX | Permettre à des applications TCP arbitraires, et pas seulement aux navigateurs Web, de traverser un pare-feu |
| 1994 | Article du CERN intitulé « *World-Wide Web Proxies* » | Permettre au personnel d'un sous-réseau fermé d'accéder au Web extérieur |
| 1995 | Début des travaux sur le routage en oignon au NRL | Préserver l’anonymat de l’origine du trafic gouvernemental sensible |
| 1996 | La norme RFC 1928 normalise SOCKS5 | Ajout de l’authentification et du protocole UDP au franchissement de pare-feu |
| 1996 | Sortie de Squid 1.0.0 | Réduction de la facture de bande passante en évitant de récupérer deux fois le même document |
| 2002 | Lancement du réseau Tor | Transformation des recherches du NRL en un réseau public d’anonymat |
| 2026 | La majeure partie du trafic devient non humaine | Déterminer d’où doivent provenir des milliards de requêtes machines |
Tor est celui dont on se souvient, et il est apparu une décennie après les autres. Il s’agissait du huitième acte de cette histoire, et non du premier.
SOCKS5 n’est pas une relique de musée. C’est un protocole pris en charge sur le réseau résidentiel de Massive en 2026, aux côtés de HTTP et HTTPS. Un protocole normalisé il y a trente ans figure toujours parmi les fonctionnalités d’un produit commercial, car il a su résoudre son problème dès le départ.
Le routage en oignon, ancêtre de Tor, est issu de la même époque et d’un milieu institutionnel similaire. En 1995, David Goldschlag, Michael Reed et Paul Syverson, au 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 premières conceptions et aux premiers prototypes de routage en oignon, dont l’objectif était de protéger les communications gouvernementales transitant par les réseaux publics ([Histoire du projet Tor](https://www.torproject.org/about/history/), consulté le 31/08/2026). La technologie qui allait plus tard devenir synonyme du dark web a été financée par la Marine américaine afin d’empêcher que le trafic des services de renseignement ne puisse être facilement attribué à son expéditeur.
## Où trouve-t-on des proxys au quotidien ?
Dans la plupart des cas. **Un proxy inverse** est la même machine orientée dans le sens inverse, travaillant pour le propriétaire du site plutôt que pour l’utilisateur, et vous en trouvez un devant presque chaque site web que vous avez consulté aujourd’hui. Les réseaux de diffusion de contenu sont des proxys de mise en cache répartis 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 écoles et des bibliothèques, les passerelles API, les maillages de services : ce sont tous des proxys, qui font exactement ce que faisait le serveur du CERN en 1994.
C’est le vocabulaire qui est intéressant. Lorsque l’intermédiaire travaille pour le propriétaire du site, le secteur parle d’« infrastructure » et l’intègre au schéma d’architecture. Lorsqu’il travaille pour la partie qui effectue la requête, le secteur parle de « proxy ». Même machine, 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 cessent de donner l’impression qu’il s’agit de deux technologies différentes.
## Pourquoi le Web a-t-il plus que jamais besoin de proxys ?
Parce que 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 était non humain, et que 52 % des requêtes des robots d’indexation concernaient l’entraînement de l’IA, contre 22 % au printemps 2025 ([Cloudflare, *Content Independence Day, one year on*](https://blog.cloudflare.com/agentic-internet-bot-report/), 1er juillet 2026).
Source : Cloudflare, « Content Independence Day », 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 fréquemment explorées ont vu leur trafic humain baisser de près de 40 % en moins d’un an ([Cloudflare](https://blog.cloudflare.com/agentic-internet-bot-report/), 1er juillet 2026).
Source : Cloudflare, « Content Independence Day », un an après, 1er juillet 2026.
Mettez ces deux constatations côte à côte et la nature du problème apparaît clairement. Les machines effectuent la majeure partie des requêtes, les utilisateurs passent la plupart de leur temps sur des moteurs de recherche, et le Web ouvert est consulté plus 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 dérivée, qui est désormais centrale.
## Comment se construit un réseau d’appareils moderne ?
Sur la base du consentement. Massive a débuté comme un 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 identifier à qui appartient la connexion ayant acheminé une requête donnée.
Il ne s’agit pas d’une obligation nouvelle. Le proxy du CERN enregistrait chaque requête qui le traversait, car un administrateur système devait être en mesure de rendre compte du trafic. Un réseau d’appareils répond à la même question à un niveau inférieur : non seulement ce qui a été demandé, mais aussi quelle connexion l’a acheminée, et selon quelles conditions son propriétaire a accepté de la transmettre.
Deux questions qu’il convient de poser à tout réseau d’appareils : pouvez-vous préciser les conditions acceptées par le propriétaire de l’appareil, et pouvez-vous remonter jusqu’à la source d’une requête ? Il existe des réponses satisfaisantes à ces deux questions depuis 1994. L’échelle a changé, mais la question d’audit, elle, est restée la même.
Au-dessus de ce réseau se trouve une couche de rendu qui renvoie du code HTML ou Markdown propre à partir de n’importe quelle source publique, où qu’elle se trouve. Il s’agit là de l’énoncé du problème de 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 du consentement dans les réseaux d’appareils, consultez [comment s’articule le consentement dans le partage de bande passante](https://joinmassive.com/blog/what-does-consent-look-like-in-bandwidth-sharing).
[Consultez la documentation](https://docs.joinmassive.com) [Contactez-nous](https://joinmassive.com/contact)
## Foire aux questions
### À quoi servent réellement les proxys ?
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, génération de trafic de recherche par IA. La première utilisation documentée, dans l’article du CERN d’avril 1994, consistait à permettre au personnel se trouvant derrière un pare-feu d’accéder au Web extérieur.
### Quel a été le premier proxy Web ?
`cern_httpd`, décrit dans *World-Wide Web Proxies* par Ari Luotonen et Kevin Altis en avril 1994. Il permettait aux utilisateurs situés sur des sous-réseaux fermés d’accéder aux protocoles HTTP, Gopher, WAIS et FTP à travers un pare-feu, et il mettait en cache les réponses 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ée. Il remplit les deux mêmes fonctions décrites dans l’article du CERN de 1994 : il s’interpose au milieu d’une requête et met le résultat en cache, la flèche pointant vers le propriétaire du site plutôt que vers le demandeur.
### Pourquoi le trafic proxy augmente-t-il en 2026 ?
Parce que 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 d’une application, et peut retirer son consentement. Une certification indépendante (SOC 2, RGPD, AppEsteem) est ce qui distingue une politique déclarée d’une politique auditée.
## Même fonction, à 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 grande échelle en 2026, pour la même raison dans les deux cas. Quelqu’un a besoin d’accéder à une ressource qu’il ne peut pas atteindre directement, et quelque chose doit s’interposer et remplir correctement cette fonction.
Ce qui a changé, c’est l’échelle et l’identité de ceux qui en ont besoin. Le serveur du CERN desservait un seul laboratoire protégé par un pare-feu. Aujourd’hui, la tâche équivalente consiste à générer un trafic machine qui dépasse désormais le trafic humain sur Internet, à partir des bons endroits, sur des appareils dont les propriétaires ont accepté de le transporter.
Trente-deux ans plus tard, c’est toujours une machine qui se trouve au milieu, effectuant une requête pour le compte de quelqu’un et en conservant une trace.
Pour en savoir plus sur l’évolution de la situation économique, consultez [Le blocage des robots d’indexation par l’IA, le paiement à l’indexation et ses implications pour les agents](https://joinmassive.com/blog/the-closing-web-ai-crawler-blocking-pay-per-crawl-and-what-it-means-for-agents).
## Sources
- Luotonen, A. et Altis, K., *World-Wide Web Proxies*, 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., *SOCKS*, UNIX Security Symposium III, USENIX Association, Baltimore, septembre 1992, pp. 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, *Historique*. Consulté le 31 août 2026. https://www.torproject.org/about/history/
- Cloudflare, *Content Independence Day, un an après : construire 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/