Cloudflare rend sa passerelle web et sa DLP programmables avec des Workers exécutés dans la politique
Le 15 octobre 2026, Cloudflare ajoute une action Forward et des Custom Functions à Cloudflare Gateway, qui exécutent votre propre code au moment précis où la politique de sécurité tranche. Si vous maintenez des pools de proxies NGINX pour injecter des en-têtes ou des pipelines Logpush pour alerter, remplacez-les par un Worker unique.
15 octobre 2026. Cloudflare annonce la programmabilité de Cloudflare Gateway et de la DLP (Data Loss Prevention) via son edge computing. 15 octobre 2026. L’action Forward entre en bêta publique ; les Custom Functions arrivent avant la fin de l’année. 330+ localisations. Le réseau où la passerelle et les Workers tournent déjà sur les mêmes machines. Pourquoi c’est important : pour la première fois, une équipe peut exécuter son propre code à l’endroit exact où la décision Autoriser / Bloquer est prise — sans héberger un seul proxy.
Le compromis binaire que tous les pare-feux imposent
Depuis l’existence des pare-feux, chaque équipe sécurité fait face au même choix. Soit elle maintient son propre moteur de détection — son firewall, ses proxies — au prix d’une charge d’exploitation lourde et d’une portabilité faible, en échange d’une personnalisation totale. Soit elle accepte les contraintes d’un éditeur, délègue la maintenance, mais perd la capacité de résoudre les problèmes propres à son environnement.
Cloudflare a entendu cette tension pendant six ans de construction de Gateway. L’exemple le plus parlant : une équipe qui migre les contrôles d’accès d’une application interne doit injecter des en-têtes HTTP à partir des claims d’un JWT émis par son fournisseur d’identité. La donnée existe dans le contexte de la requête, mais Gateway ne sait ni lire le JWT ni écrire l’en-tête. Résultat : l’équipe déploie une flotte de proxies NGINX uniquement pour cette transformation — une infrastructure qu’il faut patcher, surveiller et sécuriser indéfiniment.
Une autre équipe veut une notification Slack dès qu’un employé s’inscrit à un nouveau service SaaS. Le moteur de politique détecte l’événement, mais ne peut qu’autoriser ou bloquer. Elle bâtit donc une chaîne Logpush → SIEM → Slack avec cinq à quinze minutes de délai et aucune garantie de livraison.
Dans les deux cas, la passerelle sait déjà ce qu’il faut faire ; elle n’a simplement pas le droit d’exécuter la logique qui manque.
Pourquoi seul Cloudflare peut le faire
Le terme « programmable » est galvaudé dans le secteur. La plupart des éditeurs le revendiquent parce qu’ils offrent des API publiques, des providers Terraform ou des webhooks. Cloudflare fait valoir que la vraie programmabilité, c’est exécuter son propre code — une logique arbitraire écrite pour son environnement — en ligne dans le chemin d’évaluation de la politique, au moment où la décision de sécurité est prise.
L’atout structurel : Gateway et Workers tournent sur les mêmes machines, dans les mêmes datacenters, sur les 330+ localisations du réseau. Quand Gateway transfère du trafic vers un Worker, l’appel est un appel de fonction local. Il n’y a ni hairpinning ni latence de franchissement de frontière réseau. C’est ce qui sépare Cloudflare des fournisseurs SASE autonomes, qui doivent déployer leur automatisation dans un cloud séparé et subir l’aller-retour réseau d’un assemblage de systèmes déconnectés.
Deux points d’entrée : Forward et Custom Functions
Deux mécanismes permettent d’appeler un Worker depuis une politique Gateway. L’action Forward, disponible en bêta publique, et les Custom Functions, attendues avant la fin de l’année.
L’action Forward achemine une requête HTTP correspondant à une règle vers un Worker qui agit comme un intergiciel inline. Le Worker reçoit les en-têtes complets et le corps de la requête, peut les modifier, transmettre à l’origine, modifier aussi la réponse, puis renvoyer le résultat à l’utilisateur. Gateway conserve la gestion des connexions TCP, la terminaison TLS, les certificats et la négociation HTTP. Le Worker ne porte que la logique de transformation :
export class GatewayMiddleware extends WorkerEntrypoint {
async handle(request, context, next) {
const clientIP = context.srcIp;
request.headers.set("X-Gateway-Client-IP", clientIP);
const response = await next(request);
response.headers.set("X-Processed-By", "gateway-middleware");
return response;
}
}Une Custom Function, elle, est appelée en ligne pendant l’évaluation de la politique et renvoie une valeur typée — chaîne, nombre ou booléen — exposée comme un sélecteur dans le builder de règles, au même titre qu’un sélecteur natif comme Source IP ou Content Category. Le contrat est simple : des données en entrée, une valeur en sortie.
Ce que ça permet de construire
Injection dynamique d’en-têtes. Une Custom Function parse le JWT de l’en-tête Authorization, extrait le rôle de l’utilisateur et le renvoie comme valeur de sélecteur. Une règle Gateway associe cette valeur à un en-tête X-App-Role ajouté à la requête montante. Plus de pool NGINX, plus d’infrastructure à maintenir.
Alertes en temps réel sur correspondance de politique. Un Worker lié à une politique Forward reçoit le trafic dès qu’un profil DLP correspond, puis envoie un message Slack ou PagerDuty avec l’e-mail de l’utilisateur, la règle déclenchée et l’URL de destination — sans délai de pipeline.
Pages de justification. Un Worker intercepte l’accès à une destination sensible et renvoie une page demandant à l’utilisateur de justifier par écrit sa demande. Il écrit la session dans KV avec un TTL pour ne solliciter qu’une fois par période, et consigne l’identité et la justification dans D1 pour l’audit. C’était l’une des demandes les plus anciennes de la base clients.
Performance, disponibilité et coût
Comme Gateway et Workers partagent les mêmes machines, la distribution vers un Worker n’introduit aucun saut réseau : l’impact se limite au temps d’exécution de votre code. Quand une Custom Function échoue — exception, délai dépassé, valeur inattendue — vous configurez un comportement de repli par fonction, et une valeur par défaut est exigée par le contrat.
Côté tarification, le trafic distribué vers vos Workers est facturé comme des requêtes Worker standard, sur tous les plans. L’action Forward est en bêta publique ; les Custom Functions et la disponibilité générale couvriront tous les plans. Attention au plan Workers Free, dont les limites de temps d’exécution et de requêtes quotidiennes se feront sentir si vous y faites transiter un volume important de trafic Gateway.
La DLP apprend à valider ce qu’elle détecte
Le volet DLP illustre le mieux la logique. Les produits de protection des données détectent des motifs — expressions régulières, listes de mots — mais ne savent pas si l’occurrence détectée correspond à une vraie exfiltration. Un secret GitHub détecté peut être révoqué depuis longtemps. Les fonctions de validation personnalisées, disponibles dès aujourd’hui, comblent ce trou : un Worker peut interroger l’API GitHub pour vérifier si la clé détectée est encore active, puis décider si le profil DLP doit réellement correspondre.
Inspection de fichiers. Quand un téléchargement correspond à certains critères, un Worker peut envoyer le fichier à un service tiers de sandboxing pour détonation et analyse, ou l’écrire intégralement dans R2 comme enregistrement permanent, sans que le fichier ne quitte le réseau de Cloudflare.
Ce que les concurrents ne peuvent pas copier
La position de Cloudflare tient à une coïncidence d’architecture que les fournisseurs SASE historiques — Zscaler, Netskope ou les appliances héritées — ne peuvent pas répliquer sans reconstruire leur réseau. Ces éditeurs possèdent une passerelle et un cloud, mais pas de plateforme de calcul colocalisée avec la passerelle. Leur « programmabilité » passe donc par des webhooks, des API et de l’automatisation externe : la logique s’exécute après la décision, jamais dans la décision.
C’est la différence entre un pare-feu que l’on étend et un pare-feu que l’on programme. Quand la menace évolue à la vitesse de l’IA, le premier impose d’attendre la prochaine version de l’éditeur ; le second laisse l’équipe sécurité écrire la parade elle-même, le jour même. Les Custom Functions exploitables dans les règles réseau de niveau 4 en sont l’illustration : la même logique s’applique au trafic TCP/UDP arbitraire, pas seulement au HTTP.
Verdict
Si vous maintenez des pools de proxies NGINX pour injecter des en-têtes, ou des chaînes Logpush → SIEM → Slack pour alerter, migrez-les vers un Worker : vous supprimez une infrastructure à patcher sans perdre la logique. Si vous opérez de la DLP avec des secrets d’éditeur, testez les fonctions de validation pour ne bloquer que les secrets encore actifs — c’est la différence entre un faux positif et un incident. Si votre fournisseur SASE n’a pas de plateforme de calcul colocalisée, gardez en tête que « programmable » ne veut pas dire grand-chose : le code doit s’exécuter dans le chemin de la décision, pas dans un cloud voisin.