Lancement de Cloudflare Mesh — un réseau privé sécurisé pour les utilisateurs, nœuds, agents et Workers

• À l’ère où les agents IA doivent accéder en toute sécurité à des ressources de réseau privé, les outils existants comme les VPN ou les tunnels SSH présentent des limites structurelles, car ils ne sont pas conçus pour des logiciels autonomes plutôt que pour des humains
• Cloudflare Mesh est une solution de réseau privé bidirectionnel qui relie appareils personnels, serveurs distants et agents à l’aide d’un connecteur léger unique
• En étendant Workers VPC, les agents construits avec l’Agents SDK peuvent accéder directement au réseau Mesh, avec prise en charge de la connexion aux services internes via un appel fetch() avec une seule liaison
• Pour les utilisateurs existants de Cloudflare One, les politiques Gateway, les règles Access et les vérifications de posture des appareils sont appliquées automatiquement au trafic Mesh sans configuration supplémentaire
• Gratuit jusqu’à 50 nœuds et 50 utilisateurs, avec un routage edge mondial dans plus de 330 villes, ce qui permet une adoption immédiate des startups jusqu’aux entreprises

---

Le problème de l’accès aux réseaux privés à l’ère des agents

• Les workflows où des agents IA doivent atteindre des ressources privées se multiplient rapidement : interroger une base de données de staging, appeler une API interne ou accéder à un service sur un réseau domestique
• Limites des outils existants :
  • Un VPN nécessite une connexion interactive
  • Un tunnel SSH exige une configuration manuelle
  • Exposer un service publiquement crée un risque de sécurité
  • Il manque de visibilité sur ce que fait réellement un agent une fois connecté

Trois workflows clés

• Accès distant d’un agent personnel : lorsqu’on exécute OpenClaw sur un Mac mini et qu’on y accède depuis un mobile ou un ordinateur portable, une exposition publique ouvre l’accès au shell, au système de fichiers et au réseau, si bien qu’une seule mauvaise configuration peut créer un risque de sécurité
• Accès d’un agent de code à un environnement de staging : des outils comme Claude Code, Cursor ou Codex doivent soit être exposés à Internet, soit tunneliser l’ensemble du VPC pour accéder à des services situés dans un VPC cloud privé
• Connexion d’un agent déployé à des services privés : lorsqu’un agent Workers basé sur l’Agents SDK accède à des API internes ou à des bases de données, il faut des autorisations limitées au périmètre, une piste d’audit et une prévention des fuites d’identifiants

Architecture et fonctionnement de Cloudflare Mesh

• Un seul connecteur léger (binaire) relie appareils personnels, serveurs distants et terminaux utilisateurs
• Les appareils connectés communiquent de manière bidirectionnelle via des IP privées, en passant par le réseau mondial de Cloudflare (plus de 330 villes)
• Le WARP Connector existant est renommé Cloudflare Mesh node, et le WARP Client devient Cloudflare One Client
• Exemples de scénarios d’usage :
  • Avec Cloudflare One Client pour iOS, connexion sécurisée depuis un mobile à OpenClaw sur un Mac mini local
  • Avec Cloudflare One Client pour macOS, l’agent de code d’un ordinateur portable accède à une base de données de staging et à des API
  • Avec un nœud Mesh sur un serveur Linux, interconnexion de VPC cloud externes afin qu’un agent accède à des ressources et à MCP sur des réseaux privés externes

Différence entre Mesh et Tunnel

• Cloudflare Tunnel : adapté au proxy de trafic unidirectionnel depuis l’edge Cloudflare vers un service privé spécifique (serveur web, base de données)
• Cloudflare Mesh : fournit un réseau bidirectionnel et many-to-many où tous les appareils et nœuds peuvent s’atteindre mutuellement via des IP privées
  • Il n’est pas nécessaire de configurer un Tunnel distinct pour chaque ressource ; toutes les ressources connectées au Mesh deviennent accessibles

Exploiter le réseau Cloudflare : résoudre les problèmes de traversée NAT

• La majeure partie d’Internet se trouve derrière du NAT (Network Address Translation) ; si deux appareils sont tous deux derrière un NAT, une connexion directe échoue et dépend alors d’un serveur relais
• Si l’infrastructure de relais dispose d’un nombre limité de PoP (Point of Presence), une part importante du trafic passe par le relais, ce qui entraîne plus de latence et une moindre fiabilité
• Cloudflare Mesh route tout le trafic sur le réseau mondial de Cloudflare, offrant des performances constantes sans serveur relais dédié
• Pour les flux inter-régions et multi-cloud, les performances sont systématiquement supérieures à celles du routage sur l’Internet public

Principales caractéristiques

• 50 nœuds et 50 utilisateurs gratuits : inclus avec tous les comptes Cloudflare
• Routage edge mondial : plus de 330 villes, routage optimisé sur le backbone, sans chemins de secours dégradant les performances
• Contrôles de sécurité dès le premier jour : politiques Gateway, filtrage DNS, DLP, inspection du trafic et vérifications de posture des appareils peuvent tous être activés sur une seule et même plateforme, chaque fonction s’activant via un simple basculement
• Haute disponibilité (HA) : plusieurs connecteurs peuvent être exécutés en mode actif-passif avec le même token et annoncer la même route IP, avec basculement automatique en cas de panne

Intégration à Workers VPC

• En étendant Workers VPC, l’ensemble du réseau Mesh devient accessible depuis Workers et Durable Objects
• Liaison au réseau Mesh dans le fichier wrangler.jsonc avec le mot-clé réservé cf1:network :
  • "vpc_networks": [{ "binding": "MESH", "network_id": "cf1:network", "remote": true }]
• Dans le code du Worker, accès direct à un hôte privé sous la forme env.MESH.fetch("http://10.0.1.50/api/data"), sans enregistrement préalable
• Utilisation possible en parallèle des liaisons VPC basées sur Tunnel, élargissant le choix des approches de sécurité réseau
• Cela permet de créer des agents cross-cloud et des MCP accédant en toute sécurité à des bases de données privées, des API internes et MCP

Composants de l’architecture globale

• Nœuds Mesh : exécution d’une version headless de Cloudflare One Client sur serveurs, VM et conteneurs, attribution d’une IP Mesh et communication privée bidirectionnelle par IP entre services
• Appareils : exécution de Cloudflare One Client sur ordinateurs portables et téléphones pour accéder directement aux nœuds Mesh — SSH, requêtes de base de données et appels d’API passent tous par des IP privées
• Agents Workers : accès aux services privés via une liaison Workers VPC Network ; le réseau contrôle la portée accessible par l’agent et les serveurs MCP contrôlent le comportement de l’agent

Feuille de route

• Routage par nom d’hôte

  • Cet été, Cloudflare prévoit d’étendre au Mesh le routage par nom d’hôte de Cloudflare Tunnel
  • Le trafic pourra être routé via des noms d’hôte privés comme wiki.local ou api.staging.internal, ce qui évitera de gérer des listes d’IP
  • Cela réduira la complexité du routage dans les environnements à IP dynamiques, groupes autoscalés et conteneurs éphémères

• Mesh DNS

  • Plus tard cette année, tous les nœuds et appareils participant au Mesh recevront automatiquement un nom d’hôte interne routable
  • Il sera possible d’accéder à postgres-staging.mesh sans configuration DNS ni enregistrements manuels
  • Combiné au routage par nom d’hôte, cela permettra un accès sans adresse IP comme ssh postgres-staging.mesh ou curl http://api-prod.mesh:3000/health

• Identity-aware Routing

  • Aujourd’hui, les nœuds Mesh utilisent un ID partagé au niveau réseau ; les appareils sont authentifiés via l’ID utilisateur, mais les nœuds ne disposent pas d’un ID de routage distinct permettant aux politiques Gateway de les différencier
  • L’objectif est d’attribuer un ID unique à chaque nœud, appareil et agent afin d’écrire des politiques selon l’entité qui se connecte, et non selon une plage IP
  • Modèle d’ID agent envisagé :
    • Principal/Sponsor : la personne qui a approuvé l’action
    • Agent : le système IA qui exécute l’action (avec ID de session)
    • Scope : le périmètre des actions autorisées pour l’agent
  • Cela permettra de mettre en œuvre des politiques granulaires du type « lecture autorisée pour l’agent, écriture réservée aux humains en direct »
  • L’infrastructure est déjà en place (tokens par nœud, ID par utilisateur, liaisons VPC par service) ; la partie en cours d’implémentation concerne la visibilité des ID dans la couche de politique

• Prise en charge des conteneurs Mesh

  • Les nœuds Mesh s’exécutent actuellement sur des serveurs Linux en VM ou bare metal
  • Une image Docker Mesh pour les environnements conteneurisés est en préparation pour les pods Kubernetes, stacks Docker Compose, runners CI/CD, etc.
  • L’ajout d’un sidecar Mesh à une stack Docker Compose donnera à tous les services de la stack un accès au réseau privé
  • Dans un pipeline CI/CD, un runner GitHub Actions pourra récupérer l’image conteneur Mesh, rejoindre le réseau, exécuter des tests d’intégration sur l’environnement de staging, puis supprimer automatiquement le nœud à l’arrêt du conteneur
  • Disponibilité prévue plus tard cette année

Comment démarrer

• Cloudflare Mesh : démarrer depuis Networking > Mesh dans le tableau de bord Cloudflare, gratuit jusqu’à 50 nœuds et 50 utilisateurs
• Agents SDK + Workers VPC : installer avec npm i agents, puis consulter le guide de démarrage rapide de Workers VPC et le guide des serveurs MCP distants
• Utilisateurs existants de Cloudflare One : compatible avec la configuration existante ; les politiques Gateway, les vérifications de posture des appareils et les règles Access s’appliquent automatiquement au trafic Mesh