Cloudflare pvcli : OHTTP et MASQUE au lieu de proxy ?

```html

Le 27 juillet 2026, l'équipe de Cloudflare Research a rendu public pvcli — un client en ligne de commande pour les protocoles de réseau privés. Extérieurement, c'est un « curl pour OHTTP » : le même style de commandes, mais au lieu d'une requête classique, l'outil assemble un échange crypté à trois voies, où le serveur destinataire ne voit pas votre IP, et le nœud intermédiaire ne voit pas le contenu de la requête. Le code est sous Apache 2.0, et il est prévu de supporter MASQUE et Privacy Pass.

Pour l'industrie des proxies, ce n'est pas « un autre lancement sur GitHub ». C'est le premier moyen pratique de toucher du doigt la pile de protocoles que Apple, Google, Mozilla et Meta intègrent discrètement depuis plusieurs années — et qui est régulièrement présenté comme « un remplacement des proxies ». Analysons ce qui se cache réellement derrière cela et répondons honnêtement à la question principale : cette pile répond-elle aux besoins pour lesquels les gens achètent des proxies résidentiels et mobiles ? Spoiler : non, et la raison est architecturale, et non pas « nous n'avons pas encore atteint ce niveau ».

Ce qui a été ouvert : pvcli en détail

pvcli est écrit en Rust et s'installe avec une seule commande via cargo install --git. Selon le README, c'est un client HTTP/2 et HTTP/3 avec support pour GET et POST, TLS 1.3 et cryptage HPKE (RFC 9180). Le mode principal est l'Oblivious HTTP : le client spécifie le premier saut (relay) et la passerelle, et l'outil effectue lui-même toute la cryptographie et l'emballage en HTTP binaire.

Requête classique : pvcli https://example.com/cdn-cgi/trace, avec le drapeau --http3 — au-dessus de QUIC.
Mode OHTTP : pvcli --ohttp --first-hop https://relay --proxy https://gateway -X POST https://target.
Proxy classique : pvcli -x https://proxy.example.com https://target.example.com — c'est-à-dire que HTTP CONNECT n'a pas disparu.

Les auteurs avertissent honnêtement : le logiciel est expérimental et n'a pas été audité, le HPKE post-quantique n'est pas encore supporté, et certaines spécifications ne sont même pas encore devenues des RFC. C'est un outil de débogage, et non un produit prêt pour la production. Et c'est précisément pourquoi il est intéressant : auparavant, vérifier l'intégration OHTTP d'un tiers ne pouvait se faire qu'avec son propre code en Swift ou Rust.

Oblivious HTTP : séparez et ne dominez pas

OHTTP a été standardisé comme RFC 9458 le 12 janvier 2024. L'idée est simple à l'élégance : dissocier la connaissance de « qui vous êtes » et « ce que vous demandez » entre deux participants indépendants.

Le client chiffre la requête avec une clé éphémère sur la clé publique de la passerelle — une nouvelle paire de clés est générée pour chaque requête.
Le relay (relay obfusqué) voit votre adresse IP, mais reçoit un texte chiffré : il ne peut physiquement pas lire où et sur quoi vous interrogez.
La passerelle déchiffre la requête et la transmet à l'origine, mais voit l'IP du relay, et non la vôtre.

La garantie clé est l'unlinkabilité : l'origine ne peut pas relier vos deux requêtes entre elles. La contrainte clé est la confiance : si le relay et la passerelle se mettent d'accord ou appartiennent au même opérateur, toute la confidentialité s'effondre. Le groupe NCC a noté dans ses audits les difficultés pratiques — rotation des clés, limitation de débit et tolérances aux latences réseau.

En production, le protocole fonctionne déjà, et la liste est impressionnante :

Apple — Private Cloud Compute pour les requêtes Apple Intelligence et Enhanced Visual Search dans « Photos » ; le support OHTTP en Swift est apparu en août 2024.
Google — Privacy Sandbox, k-anonymat et vérification des URL dans Safe Browsing sans révéler l'IP ; Fastly joue le rôle de relay.
Mozilla — collecte de métriques de performance de Firefox sans identification de l'utilisateur.
Meta — Private Processing pour Meta AI dans WhatsApp (2025), également via le relay Fastly.
Flo — « mode anonyme » du tracker de cycle basé sur Cloudflare Privacy Gateway depuis 2022.

Les passerelles, en plus de Cloudflare et Fastly, sont mises en place par l'Internet Security Research Group dans le service Divvi Up. Cela signifie que l'infrastructure est réelle, et non fictive.

MASQUE : cela ressemble déjà à un proxy

La deuxième partie de la pile que Cloudflare promet d'ajouter à pvcli est MASQUE. C'est une famille de protocoles du groupe de travail IETF, qui intègre le proxying à l'intérieur de HTTP :

RFC 9298 (août 2022), CONNECT-UDP — proxying UDP à l'intérieur de HTTP ; le client envoie un CONNECT étendu avec :protocol: connect-udp, et le proxy encapsule les trames QUIC DATAGRAM dans des paquets UDP.
RFC 9484 (octobre 2023), CONNECT-IP — déjà un niveau IP complet : des paquets IP bruts sont enveloppés dans des Datagram HTTP, et le serveur HTTP/3 devient une passerelle VPN capable de gérer simultanément TCP, UDP et ICMP.

Les deux spécifications nécessitent un fallback vers HTTP/2 là où QUIC et UDP sont bloqués au niveau réseau, ce qui se produit régulièrement dans les réseaux d'entreprise et chez les fournisseurs. En substance, MASQUE est ce sur quoi reposent les « relais privés » modernes au niveau du système d'exploitation, où le trafic passe par deux sauts indépendants : le premier vous connaît, mais ne connaît pas le destinataire, le second, au contraire.

Privacy Pass : un passe anonyme au lieu d'un captcha

Le troisième élément — Privacy Pass, standardisé par trois documents : RFC 9576 (architecture), RFC 9577 (schéma d'authentification HTTP) et RFC 9578 (protocoles d'émission de jetons, vérifiables de manière privée et publique). La logique se déroule en deux étapes : émission — vous prouvez une fois que vous êtes un humain ou un client de confiance, et vous recevez un lot de jetons signés de manière aveugle ; échange — vous présentez le jeton au site, et il vous laisse passer sans captcha, sans possibilité de relier le jeton au moment de l'émission.

C'est exactement le mécanisme qui sous-tend l'idée de « donner un accès légitime aux bons bots » — qui est également à la base des agents signés et Web Bot Auth. La tendance est la même : séparer l'identité réseau (IP) et les droits d'accès (jeton, signature).

Cela remplacera-t-il les proxies ? Analyse sans illusions

Chaque fois qu'une nouvelle de cette pile sort, le postulat « pourquoi maintenant utiliser des proxies, s'il y a OHTTP » refait surface. Le problème est que les protocoles privés et les proxies résolvent des problèmes différents, et le remplacement de l'un par l'autre échoue sur quatre points.

1. OHTTP ne fonctionne que là où le site l'a déployé

Ce n'est pas un overlay sur Internet, mais un opt-in du côté du destinataire : la passerelle est mise en place et configurée par l'origine elle-même (ou son sous-traitant). On ne peut pas « entrer via OHTTP » sur n'importe quel marketplace ou réseau social — il n'y a tout simplement pas de passerelle. Tous les déploiements mentionnés sont des entreprises cachant l'IP de leurs propres utilisateurs à leurs propres backends. Pour collecter des données d'un site tiers, le mécanisme n'est pas applicable en principe.

2. Le point de sortie est un centre de données, et tout le monde le sait

Même si la passerelle existe, la requête sort avec l'adresse de Cloudflare, Fastly ou ISRG. Ce sont des ASN connus des fournisseurs d'hébergement avec des plages publiques. Les systèmes anti-bots classent les IP par type de réseau, et l'adresse du relay cloud reçoit exactement le même score que n'importe quelle autre adresse de centre de données. Vous avez obtenu de la confidentialité de l'origine, mais « avoir l'air d'un utilisateur domestique ordinaire » — non. C'est précisément ce pour quoi répondent les proxies résidentiels avec de vraies adresses de fournisseurs et des pools mobiles des réseaux CGNAT des opérateurs.

3. Pas de géographie, de rotation et de sessions collantes

L'infrastructure de proxy offre ce que les protocoles privés n'ont pas par conception : le choix du pays, de la région et de l'opérateur, la rotation gérée des IP, des sessions collantes pour le nombre de minutes nécessaires, différents pools pour différents comptes. OHTTP ne vous permet pas de choisir « sortir d'Allemagne, du réseau d'un ISP spécifique » — il n'y a tout simplement pas de notion de point de sortie à votre disposition. Pour vérifier les résultats locaux, les prix par région ou travailler avec du contenu géo-restreint, c'est une différence irréductible.

4. Le modèle de confiance est différent

OHTTP protège contre le lien des requêtes à une origine spécifique à condition que le relay et la passerelle soient indépendants. Le proxy protège contre le fait que le site voit votre véritable adresse et votre profil réseau. Le premier concerne la confidentialité de la télémétrie et des requêtes de l'utilisateur, le second concerne l'accès et la répartition de la charge. Les tâches se chevauchent seulement partiellement, et le « déménagement » de l'un à l'autre est impossible.

Ce qui sera réellement utile en pratique

Si vous êtes développeur d'un produit qui envoie des télémétries ou des requêtes à votre API — OHTTP via Privacy Gateway ou Divvi Up réduit réellement le volume des données personnelles collectées et simplifie la discussion avec les juristes. pvcli permet désormais de déboguer cela sans écrire un client depuis zéro.
Si vous collectez des données publiques — la pile ne change rien : le point de sortie et sa réputation restent votre problème. Pour le scraping de masse, la combinaison fonctionne toujours — proxy de centre de données avec rotation sur des plateformes loyales et résidentiels là où un anti-bot sérieux est activé.
Si vous travaillez avec plusieurs comptes — les protocoles privés ne résolvent pas la question de l'isolation : les sessions sur les plateformes sont liées non seulement par l'IP, mais aussi par l'empreinte du navigateur et le comportement. La différence entre la couche IP et la couche d'identité est expliquée dans le matériel sur les différences entre proxy et VPN.
Si vous automatisez l'accès « en blanc » — ici, il convient de rester attentif. Privacy Pass et les agents signés s'orientent vers un modèle où le bot se voit accorder l'accès sur présentation d'un jeton, et non sur « ressemblance avec un humain ». C'est la partie la plus prometteuse de la nouvelle.

Conclusion

L'ouverture de pvcli est un bon indicateur de maturité : les protocoles privés sont sortis de la phase des prépublications de recherche et ont acquis des outils de débogage. OHTTP, MASQUE et Privacy Pass redéfinissent réellement la manière dont Internet traite l'adresse du client, et dans quelques années, « le site voit votre IP » cessera d'être une axiom pour le trafic utilisateur.

Mais pour ceux qui collectent des données, gèrent de nombreux comptes ou vérifient les résultats par région, rien ne change. Les protocoles privés vous cachent de ceux vers qui vous êtes venu par invitation. Les proxies sont nécessaires là où les invitations ne sont pas délivrées — et là, le type de réseau, la réputation de l'adresse et la qualité du pool demeurent décisifs. Il est judicieux de suivre Privacy Pass comme un futur canal légal pour les bots tout en maintenant une infrastructure proxy normale pour le réel.