Cloudflare Gateway ouvre la transformation du trafic à du code sur mesure

Dans une entreprise, une passerelle web peut appliquer des règles aux connexions des collaborateurs : autoriser un service, bloquer une destination ou examiner un échange. Cloudflare Gateway propose ce type de contrôle. Le 15 octobre 2026, Cloudflare annonce l’action Forward en bêta publique : elle peut appeler un Worker, un programme exécuté sur son infrastructure, pour adapter le traitement à un besoin particulier. Cela dépasse le choix entre autoriser et bloquer, mais ajoute du code à maintenir.

Ce qui est disponible, ce qui reste annoncé

La documentation de Forward confirme une bêta publique sur tous les forfaits Zero Trust ; l’usage de Workers suit sa propre tarification. Les Custom Functions de Gateway, qui doivent fournir une valeur utilisable dans une condition de règle, sont annoncées avant la fin de l’année dans le calendrier de l’éditeur. Elles ne doivent pas être confondues avec l’action Forward accessible aujourd’hui.

Avec Forward, le programme peut modifier une requête ou une réponse. Un exemple de besoin serait d’ajouter un en-tête attendu par une application interne. Un en-tête est une information technique accompagnant l’échange, distincte du contenu de la page. Le bénéfice doit être formulé précisément : quelle application attend cette information, pour quelles connexions et avec quelle valeur ? « Personnaliser la sécurité » reste trop vague pour juger l’utilité du développement.

HTTP est le protocole des échanges web ; HTTPS les chiffre pour en protéger le contenu pendant le transport. Pour que Forward puisse traiter ce contenu, les prérequis Cloudflare imposent le déchiffrement et un certificat racine reconnu comme fiable par les appareils concernés. Ce certificat leur permet d’accepter l’inspection par la passerelle. Faites configurer ce dispositif par le responsable informatique sur les appareils autorisés pour l’essai. Un échange couvert par une règle Do Not Inspect, qui l’exclut de l’inspection, n’appelle pas le Worker. Listez donc les exclusions avant de conclure qu’un essai fonctionne sur toutes les connexions visées.

Le schéma ne signifie pas que le programme remplace tous les contrôles. La documentation sur l’ordre de traitement précise qu’une règle HTTP de blocage empêche l’appel du Worker. Une décision de blocage issue des contrôles du corps peut aussi interrompre un Worker déjà lancé. L’appel du programme ne prouve donc pas que l’inspection a réussi. Le corps désigne ici les données transportées dans la requête, par exemple le contenu envoyé par un formulaire.

Définir un essai qui révèle aussi les erreurs

Avant de demander un développement, écrivez trois résultats attendus : le traitement normal, le traitement d’une requête hors périmètre et le comportement en cas d’échec. Dans un exemple hypothétique, seul l’outil de réservation interne doit recevoir un en-tête supplémentaire. L’essai doit montrer que cet outil le reçoit, qu’un autre site ne le reçoit pas et qu’une panne simulée du programme sur ce périmètre de test bloque bien la requête et est signalée au responsable. Utilisez des données fictives plutôt que des dossiers clients pour vérifier la logique.

Faites préciser qui lit les journaux, quelles données ils contiennent et comment retirer la règle de test. Un programme qui reproduit les échanges dans un autre service élargit les accès aux informations ; il faut examiner ce transfert avant l’essai. Demandez également un relevé de consommation Workers. Le fait qu’une action figure dans un forfait ne signifie pas que le code exécuté n’a ni coût ni limite.

Si le Worker tombe en panne, les requêtes concernées sont bloquées. Une erreur d’appel, du programme ou de communication avec Gateway ne déclenche pas un passage automatique de la requête initiale vers le service : c’est le comportement décrit dans les limites de Forward. Avant le test, convenez avec le responsable de la personne qui peut désactiver la règle et des vérifications nécessaires pour reprendre l’accès sans cette transformation.

La documentation précise que supprimer un Worker sans modifier la règle Forward qui le référence provoque des erreurs HTTP 500 : les requêtes concernées n’atteignent plus leur destination. Elle recommande aussi de désactiver la règle de test pendant la correction d’un programme défaillant. Ces consignes de dépannage justifient de commencer sur un périmètre limité, avec une personne capable de rétablir le fonctionnement prévu.

Distinguer les protections du site et celles des usages internes

Le bon choix commence par le trajet à protéger : visites reçues par votre site ou connexions effectuées par l’équipe. La page Cybersécurité de Gaia présente l’hébergement, la maintenance et des protections complémentaires du site, dont des prestations Cloudflare à examiner selon l’environnement. Ce périmètre ne suffit pas à établir une offre de développement Gateway et Workers. Pour votre site, les niveaux de maintenance permettent déjà de comparer les contrôles et les modalités d’intervention utiles avant de définir une extension sur mesure.