Cloudflare a rendu disponible la fonctionnalité « Private Origins », permettant à ses services — comme le pare-feu applicatif (WAF) ou le gestionnaire de bots — d’agir sur des applications dont l’adresse IP est strictement privée. L’idée est simple, mais la portée est grande : on peut pointer un enregistrement DNS proxifié vers une IP interne (par exemple, 10.0.0.50) et Cloudflare s’occupe de la connexion sans jamais forcer l’ouverture de ports sur le pare-feu local.

Cette évolution répond à un besoin client récurrent, signalé lors de la phase bêta lancée en juin. Beaucoup d’entreprises développent des API internes, des serveurs d’agents d’IA ou des outils opérationnels qui ne sont pas conçus pour le grand public. Pourtant, ces services ont parfois besoin d’accepter des requêtes de partenaires externes ou d’agents sur Internet. Avant cette nouveauté, l’intégration de Cloudflare en amont de ces services signifiait généralement qu’il fallait révéler une adresse IP publique ou installer un logiciel de type cloudflared en permanence.

Selon developers.cloudflare.com, cette mise à disposition générale signifie que lorsque vous configurez un enregistrement A ou AAAA proxifié pointant vers une adresse IP privée, Cloudflare utilise votre connexion existante via Cloudflare One. Que ce soit par IPsec, GRE, Cloudflare Tunnel ou Cloudflare Mesh, le trafic est acheminé via le réseau privé du client avant d’atteindre l’origine interne. Les protections habituelles — WAF, limitation de débit, mise en cache — s’appliquent intégralement, comme elles le feraient pour un site accessible publiquement.

Les mécanismes derrière le routage privé

Le fonctionnement repose sur un signal spécifique au niveau DNS. En ajoutant l’attribut private_routing: true à l’enregistrement, vous indiquez à la plateforme de Cloudflare que la destination doit être atteinte par un chemin réseau privé. Au lieu d’essayer de se connecter directement à l’IP interne depuis l’Internet public, le proxy de Cloudflare transmet la requête à sa couche de réseau privée, laquelle gère le pontage à travers l’infrastructure de connectivité déjà en place chez vous.

Cette fonctionnalité s’active automatiquement pour les plages d’adresses RFC 1918, telles que les réseaux IPv4 privés. Toutefois, pour que le routage fonctionne, il est indispensable d’avoir préalablement configuré l’une des solutions de connectivité Cloudflare One requises, comme IPsec ou Cloudflare Tunnel.

Ce que cela implique pour l’architecture interne

Ce qui change pour les architectes réseau, c’est la possibilité d’uniformiser la sécurité. Imaginez un employé accédant à wiki.entreprise.internal depuis son poste de travail en télétravail ; grâce à cette intégration, ce trafic bénéficiera du même niveau de contrôle qu’une requête externe sur un site public. Ce bénéfice s’étend aussi aux communications de service à service entre différents centres de données ou entre différentes infrastructures cloud.

Pour ceux qui gèrent les déploiements par API, le processus reste relativement propre : il s’agit simplement d’ajouter un attribut à un enregistrement DNS standard. Cependant, si le trafic échoue, les développeurs doivent vérifier d’abord que les routes de retour de Cloudflare sont correctement définies dans leur infrastructure privée, car c’est là que se sont situées les erreurs de configuration les plus fréquentes lors de la phase bêta.

À l’avenir, Cloudflare travaille sur l’extension de ce concept au trafic privé-vers-privé, c’est-à-dire permettre à des agents ou des services situés sur un réseau privé d’interroger des applications sur un autre réseau privé via les services Cloudflare. Ils ciblent une bêta fermée début 2027 pour cette fonctionnalité.

Sources

• Connectivity options · Cloudflare One docs, developers.cloudflare.com
• Private origins (beta) · Cloudflare DNS docs, developers.cloudflare.com
• Cloudflare services for private origins is now generally available, Cloudflare, 30 octobre 2026

Crédits photo

• Image en une : Technician with laptop working on server rack at NERSC, par Derrick Coetzee from Berkeley, CA, USA, CC0, via Wikimedia Commons (recadrée)
• Image dans l’article : EFTA00002520 – Server rack filled with colorful cables and hard drives in a cluttered data center, par Federal Bureau of Investigation, Public domain, via Wikimedia Commons (recadrée)