Cloudflare lance la disponibilité générale de Private Origins pour acheminer les requêtes vers des services privés via des connexions existantes

Le 30 octobre 2026, Cloudflare a annoncé que ses services pour les origines privées sont désormais en disponibilité générale. Le propriétaire d’un site fait pointer un enregistrement DNS proxifié vers une adresse IP privée, et Cloudflare atteint l’origine par une connexion Cloudflare One que le client possède déjà. L’origine reste privée, et Cloudflare affirme que son pare-feu applicatif web (WAF), la mise en cache, la gestion des robots et Workers fonctionnent comme pour des origines publiques.

Cloudflare indique avoir lancé cette capacité en bêta fermée en juin, après que des clients ont décrit des API internes, des backends d’agents d’IA, des serveurs MCP et des outils d’exploitation qui n’avaient pas été conçus pour faire face à Internet, mais devaient quand même accepter des requêtes de partenaires, de clients ou d’agents. Avant la bêta, placer Cloudflare devant un tel service supposait d’exposer une IP publique, d’ouvrir un port du pare-feu ou d’exécuter cloudflared à côté de l’origine. Ces voies laissaient souvent les applications privées sans les protections des applications publiques. Pendant la bêta, l’accès passait par les équipes de compte, et l’article dit qu’aujourd’hui Cloudflare ouvre l’accès au-delà de ce groupe. La disponibilité générale exige toujours le droit Private Origins sur le compte, que l’article invite le client à demander à son équipe de compte.

La configuration passe par un enregistrement A ou AAAA proxifié. Le paramètre « Use private network routing » s’active automatiquement pour les adresses IPv4 privées de la RFC 1918, les adresses CGNAT de la RFC 6598 (100.64.0.0/10) et les adresses IPv6 locales uniques de la RFC 4193 (fc00::/7) ; pour ces plages, il ne peut pas être désactivé, et une tentative via l’API renvoie une erreur. Si une origine a une IP publique joignable uniquement par le réseau privé du client, le paramètre peut être activé à la main. Dans l’API, c’est un attribut de plus sur un enregistrement DNS standard : private_routing à true. Le proxy de Cloudflare apprend ce drapeau auprès de son API d’origine et, au lieu de se connecter à l’adresse par Internet public, confie la requête à une couche réseau privée. Cette couche utilise la connectivité existante du client : IPsec, GRE, Cloudflare Tunnel, CNI ou Cloudflare Mesh. La terminaison TLS, le WAF, les règles et le cache continuent de s’exécuter sur le réseau de Cloudflare. L’origine n’a besoin d’aucune exception entrante dans le pare-feu. Avec Cloudflare WAN, aucun logiciel connecteur n’est nécessaire sur l’origine, et avec Cloudflare Mesh, un connecteur à l’intérieur du réseau privé peut servir plusieurs origines.

Avant de commencer, le client a besoin du droit Private Origins, d’une connectivité Cloudflare One par IPsec, GRE, CNI, Cloudflare Tunnel ou Cloudflare Mesh, et de Unified Routing activé sur le compte, sauf s’il passe par Cloudflare Tunnel, qui n’en a pas besoin. Avec Cloudflare WAN ou Cloudflare Mesh, il doit aussi configurer une route de retour pour les plages sources de Cloudflare : 100.64.0.0/12 en IPv4 et 2606:4700:cf1:5000::/64 en IPv6. Le conseil de Cloudflare, tiré de la bêta, est de vérifier d’abord la route de retour lorsque les requêtes expirent et que rien n’arrive à l’origine, car l’absence de cette route a été l’échec de configuration le plus fréquent. Certaines fonctions ne sont pas prises en charge : Argo Smart Routing et les Dedicated CDN Egress IPs ne fonctionnent pas avec les origines privées, et les contrôles d’état de l’origine exigent Load Balancing. L’article renvoie à la documentation pour développeurs pour la liste complète des limites. Lorsque nous avons lu cette page de documentation, elle portait encore une date de mise à jour du 7 mai, la mention bêta fermée et une note réservée à l’offre Enterprise : l’article de blog et la page de documentation n’étaient donc pas encore d’accord.

Cloudflare dit que l’étape suivante est le trafic de privé à privé, c’est-à-dire des utilisateurs, des services et des agents d’IA situés sur un réseau privé qui atteignent des applications d’un autre réseau privé grâce aux services applicatifs de Cloudflare. Les travaux d’ingénierie sont en cours, avec une bêta fermée visée pour début 2027. Pour les équipes qui exploitent déjà IPsec, GRE, CNI, Tunnel ou Mesh, la version d’aujourd’hui permet de placer WAF, limitation de débit et cache devant des services internes sans les exposer à Internet, à condition que le droit et la route de retour soient en place.