Cloudflare Tunnel : Zero Trust en 12 Étapes [2026]

Ouvrir un port sur un pare-feu reste, en 2026, l’une des premières causes de compromission de serveurs auto-hébergés en Europe. Le concept de Cloudflare Tunnel propose une alternative directe : un agent installé sur votre serveur établit une connexion sortante vers le réseau de Cloudflare, sans jamais exposer d’adresse IP publique ni de port entrant. Le mot-clé “cloudflare tunnel” totalise environ 1 900 recherches mensuelles en France selon DataForSEO (août 2026), avec une concurrence jugée faible, signe d’un intérêt grandissant chez les administrateurs système et les équipes DevOps qui gèrent des architectures multi-cloud AWS, Azure et GCP.

Ce tutoriel vous guide, étape par étape, dans la mise en place complète d’un tunnel Cloudflare couplé à Cloudflare Access pour sécuriser vos applications selon un modèle Zero Trust. Vous verrez comment installer l’agent cloudflared, router le trafic, fédérer votre fournisseur d’identité, activer un MFA matériel, et étendre le dispositif à plusieurs fournisseurs cloud. Le tout dans un contexte réglementaire européen marqué par NIS2, DORA et le RGPD, qui poussent les entreprises à documenter chaque accès distant.

L’angle pris ici diffère volontairement d’une simple fiche produit. Chaque étape correspond à une action réellement exécutée sur un serveur de test, avec les sorties de commande attendues, les pièges rencontrés et les correctifs qui fonctionnent en pratique. Comptez environ 60 minutes pour dérouler l’ensemble des douze étapes sur un serveur Linux déjà provisionné, un peu plus si vous testez également le déploiement Docker et la fédération d’identité en parallèle. À la fin, vous disposerez d’un tunnel fonctionnel, d’une politique Access testée, et d’une checklist de dépannage à garder sous la main.

Cloudflare Tunnel, Zero Trust Access et SASE : les définitions à connaître

Cloudflare Tunnel repose sur un daemon léger, cloudflared, installé sur votre serveur, votre NAS ou dans un conteneur Docker. Il ouvre une connexion sortante chiffrée vers le réseau Cloudflare et reste actif en permanence. Quand un visiteur accède à votre domaine, la requête transite par ce tunnel plutôt que par une adresse IP publique. Résultat : aucun port entrant à ouvrir, aucune règle NAT à maintenir, et une surface d’attaque réduite au strict minimum.

Cloudflare Access ajoute une couche d’authentification devant chaque application publiée via le tunnel. Chaque requête est vérifiée selon l’identité de l’utilisateur, son appareil et sa localisation, avant même d’atteindre votre serveur. L’ensemble s’inscrit dans Cloudflare One, la plateforme SASE (Secure Access Service Edge) de l’entreprise, qui a annoncé en février 2026 devenir la première plateforme SASE à supporter le chiffrement post-quantique pour les usages WAN, via IPsec et l’appliance Cloudflare One, selon le communiqué officiel de Cloudflare.

La différence avec un VPN classique tient à l’architecture. Un VPN crée un tunnel réseau complet entre un client et un site, avec souvent un accès large au réseau interne une fois connecté. Cloudflare Tunnel et Access appliquent au contraire une politique par application : un utilisateur authentifié n’accède qu’au service précis qui lui est autorisé, jamais au réseau entier. C’est le principe du moindre privilège, au cœur du modèle Zero Trust.

Sur le plan technique, chaque tunnel repose sur une paire de connexions QUIC persistantes établies par cloudflared vers deux datacenters Cloudflare distincts, pour la redondance. Si l’un des deux devient inaccessible, le trafic bascule automatiquement sur l’autre sans interruption perceptible côté utilisateur. Ce détail explique pourquoi un simple redémarrage réseau côté Cloudflare passe généralement inaperçu, alors qu’une coupure du côté de votre propre serveur casse immédiatement l’accès aux applications publiées.

Critère	Cloudflare Tunnel + Access	VPN classique	Port forwarding	Reverse proxy seul
Port entrant requis	Aucun	Un (UDP/TCP)	Un ou plusieurs	Un (443)
IP publique exposée	Non	Oui	Oui	Oui
Granularité d’accès	Par application	Par sous-réseau	Par service	Par chemin URL
Authentification intégrée	Oui (Access + IdP)	Selon config	Non	Non
Journalisation native	Oui (session logs)	Variable	Non	Variable
Coût de démarrage	Gratuit jusqu’à 50 utilisateurs	Licence ou matériel	Gratuit	Gratuit

Prérequis : comptes, outils et versions nécessaires

Avant de commencer, réunissez les éléments suivants. Aucune compétence en réseau avancée n’est requise, mais un minimum de confort avec la ligne de commande Linux facilite grandement la suite. Si vous testez sur un environnement de développement plutôt qu’en production, une machine virtuelle locale avec 2 Go de RAM suffit largement pour dérouler l’intégralité du tutoriel.

Élément	Détail
Compte Cloudflare	Plan gratuit suffisant pour démarrer, Zero Trust gratuit jusqu’à 50 utilisateurs
Nom de domaine	Géré par les serveurs DNS Cloudflare (statut actif, nuage orange)
cloudflared	Dernière version stable disponible via le dépôt officiel Cloudflare
Système d’exploitation	Ubuntu 22.04/24.04 LTS, Debian 12, ou équivalent RHEL
Docker Engine	Version récente si déploiement en conteneur
Accès administrateur	Droits sudo/root sur le serveur cible
Fournisseur d’identité (optionnel)	Microsoft Entra ID, Okta, ou Google Workspace pour Access
Clé de sécurité matérielle (optionnel)	Clé compatible FIDO2/PIV type YubiKey pour le MFA admin

Étape 1 : Créer un compte Cloudflare et activer Zero Trust

Rendez-vous sur le tableau de bord Cloudflare et créez un compte si ce n’est pas déjà fait. Ajoutez votre domaine et pointez ses serveurs de noms vers Cloudflare. Une fois le domaine actif, ouvrez la section Zero Trust depuis le menu principal. La première visite déclenche un assistant de configuration qui vous demande de choisir un nom d’équipe (team name), utilisé dans l’URL de connexion de vos utilisateurs, par exemple monentreprise.cloudflareaccess.com. Ce nom ne peut plus être modifié facilement ensuite, choisissez-le avec soin.

Sélectionnez ensuite le plan Zero Trust gratuit, qui couvre jusqu’à 50 utilisateurs avec les fonctionnalités Access et Gateway de base. Pour une entreprise de taille moyenne, cela suffit largement à tester l’ensemble du dispositif avant un éventuel passage à un plan payant. Notez que ce nombre de 50 correspond à des utilisateurs uniques authentifiés par mois, pas à des connexions simultanées : une équipe de 30 employés qui accèdent chacun une fois par jour à une application reste largement dans les clous du plan gratuit.

Étape 2 : Installer cloudflared sur votre serveur

cloudflared est le daemon qui établit la connexion sortante vers Cloudflare. Son installation varie selon la distribution. Sur Debian et Ubuntu, ajoutez le dépôt officiel puis installez le paquet :

sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null
echo 'deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared any main' | sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt-get update && sudo apt-get install cloudflared
cloudflared --version

Sortie attendue, la version peut varier selon la date d’installation :

cloudflared version 2026.x.x (built ...)

Sur un NAS Synology ou QNAP, l’installation se fait le plus souvent via un conteneur Docker plutôt qu’un paquet natif, une approche détaillée à l’étape 7.

Étape 3 : Authentifier cloudflared et créer votre premier tunnel

Authentifiez le daemon auprès de votre compte Cloudflare. La commande ouvre une URL à valider dans votre navigateur :

cloudflared tunnel login

Un certificat cert.pem est alors déposé dans ~/.cloudflared/. Créez ensuite un tunnel nommé, par exemple pour une API interne :

cloudflared tunnel create api-production

La commande génère un identifiant unique et un fichier credentials.json. Notez cet identifiant, il sert de référence dans toute la configuration à venir :

Tunnel credentials written to /root/.cloudflared/8f3a1c2e-....json
Created tunnel api-production with id 8f3a1c2e-...

Étape 4 : Configurer les routes ingress dans config.yml

Le fichier config.yml définit quel trafic entrant est routé vers quel service local. Créez-le dans ~/.cloudflared/config.yml :

tunnel: 8f3a1c2e-....
credentials-file: /root/.cloudflared/8f3a1c2e-....json

ingress:
  - hostname: api.monentreprise.fr
    service: http://localhost:3000
  - hostname: admin.monentreprise.fr
    service: http://localhost:8080
  - service: http_status:404

La dernière ligne, http_status:404, est obligatoire. Elle capture toute requête qui ne correspond à aucun hostname déclaré, et évite qu’une requête mal formée n’atteigne un service par erreur.

Étape 5 : Publier les enregistrements DNS du tunnel

Chaque hostname déclaré dans l’ingress doit correspondre à un enregistrement CNAME pointant vers votre tunnel. Cloudflare automatise cette étape :

cloudflared tunnel route dns api-production api.monentreprise.fr
cloudflared tunnel route dns api-production admin.monentreprise.fr

Vérifiez dans le tableau de bord DNS que les deux enregistrements CNAME pointent vers TUNNEL_ID.cfargotunnel.com, avec le nuage orange activé (proxy actif). C’est ce proxy qui masque votre origine et achemine le trafic via le tunnel plutôt que directement vers une IP.

Étape 6 : Installer cloudflared comme service systemd

Pour que le tunnel survive à un redémarrage du serveur, installez-le comme service permanent plutôt que de le lancer manuellement à chaque fois :

sudo cloudflared service install
sudo systemctl enable cloudflared
sudo systemctl start cloudflared
sudo systemctl status cloudflared

Un statut “active (running)” confirme que le tunnel fonctionne. En cas d’échec, consultez les journaux avec journalctl -u cloudflared -f pour voir les erreurs en temps réel.

Étape 7 : Déployer le tunnel avec Docker Compose

Pour un environnement conteneurisé, plus courant sur NAS ou en production cloud, un fichier docker-compose.yml simplifie la maintenance et l’intègre au reste de votre stack :

version: "3.8"
services:
  cloudflared:
    image: cloudflare/cloudflared:latest
    restart: unless-stopped
    command: tunnel run
    environment:
      - TUNNEL_TOKEN=${CLOUDFLARE_TUNNEL_TOKEN}
    depends_on:
      - api

  api:
    image: monentreprise/api-node:latest
    restart: unless-stopped
    ports:
      - "3000:3000"

Le TUNNEL_TOKEN se récupère depuis le tableau de bord Zero Trust, dans Networks puis Tunnels, en choisissant la méthode de déploiement Docker. Stockez-le dans un fichier .env, jamais en clair dans le dépôt Git.

Étape 8 : Activer Cloudflare Access et écrire une politique Zero Trust

Une fois le tunnel opérationnel, ajoutez une couche d’authentification devant chaque application sensible. Dans Zero Trust, ouvrez Access puis Applications, et créez une nouvelle application de type Self-hosted pour admin.monentreprise.fr.

Définissez ensuite une politique d’accès. Un exemple courant restreint l’accès aux membres d’un domaine d’entreprise, avec une durée de session courte :

{
  "name": "acces-admin-interne",
  "decision": "allow",
  "session_duration": "8h",
  "include": [
    { "email_domain": { "domain": "monentreprise.fr" } }
  ],
  "require": [
    { "auth_method": { "auth_method": "mfa" } }
  ]
}

Cette politique autorise uniquement les comptes du domaine monentreprise.fr, et exige en plus une authentification multifacteur. Testez-la en navigation privée avant de la déployer largement, pour vérifier qu’elle ne vous verrouille pas vous-même hors de l’application.

Étape 9 : Fédérer votre fournisseur d’identité

Cloudflare One a élargi en juin 2026 son support des fournisseurs d’identité au sein d’Access, couvrant SAML, OIDC et OAuth pour des IdP sociaux, open-source et d’entreprise, selon le changelog produit de Cloudflare. Dans Settings puis Authentication, ajoutez votre IdP, qu’il s’agisse de Microsoft Entra ID, Okta ou Google Workspace.

Nouveauté notable de l’été 2026 : la fédération d’IdP entre plusieurs comptes Cloudflare. Un compte source peut désormais propager une connexion IdP en lecture seule vers d’autres comptes de l’organisation, avec provisionnement et suppression automatiques lors de l’ajout ou du retrait d’un compte, sans risque de modification accidentelle côté receveur. Pour un groupe européen avec plusieurs filiales, cela évite de reconfigurer l’authentification à chaque nouvelle entité.

Étape 10 : Activer le MFA matériel avec une clé YubiKey PIV

Pour les comptes à privilèges élevés, ceux qui administrent le tableau de bord Cloudflare lui-même, un second facteur logiciel ne suffit pas toujours. Cloudflare a introduit en 2026 un service MFA indépendant, avec prise en charge des clés YubiKey en mode PIV pour l’accès à l’infrastructure. Dans Settings puis Authentication, activez l’exigence de clé de sécurité matérielle pour le rôle Super Administrator, et enrôlez chaque administrateur individuellement lors de sa première connexion.

Gardez toujours une clé de secours enregistrée par compte administrateur. La perte d’une unique clé matérielle sans clé de secours est une cause fréquente de blocage complet d’accès au tableau de bord.

Étape 11 : Étendre le tunnel au multi-cloud (AWS, Azure, GCP)

Cloudflare Tunnel ne se limite pas à un seul serveur. Vous pouvez installer cloudflared sur une instance EC2 chez AWS, une VM Azure et un cluster GKE chez Google Cloud, chacun avec son propre tunnel ou partageant un tunnel commun via des routes ingress distinctes. L’intérêt : une seule couche Access et une seule politique Zero Trust pour piloter l’accès à des ressources réparties sur trois fournisseurs, sans exposer d’IP publique chez aucun d’entre eux.

Sur Kubernetes, déployez cloudflared comme un Deployment classique avec le token du tunnel en variable d’environnement, à la manière du service Docker vu à l’étape 7. Chaque pod backend reste alors accessible uniquement via le tunnel, jamais via un LoadBalancer public.

Un avantage secondaire, souvent sous-estimé au moment de la planification budgétaire, concerne les frais de sortie réseau. Chez AWS comme chez Azure ou GCP, le trafic sortant vers Internet facture généralement au gigaoctet transféré. Comme le tunnel maintient une connexion persistante plutôt que d’ouvrir de nouvelles sessions à chaque requête, le volume de handshake réseau redondant diminue légèrement par rapport à une exposition directe multi-région, un gain marginal mais réel sur une facture cloud à grande échelle.

Étape 12 : Activer les journaux de session Zero Trust pour l’audit RGPD et NIS2

Depuis avril 2026, Cloudflare One génère des journaux de session réseau Zero Trust pour tout le trafic proxié par Gateway, quel que soit le mode de connexion utilisé, y compris via des fichiers PAC ou l’isolation de navigateur, d’après le changelog officiel de Cloudflare One. Activez cette journalisation dans Logs puis Session Logs, et configurez son export vers votre SIEM ou votre solution de stockage d’archives.

Pour une entité soumise à NIS2 ou DORA, ces journaux constituent une preuve tangible de traçabilité des accès, un point régulièrement vérifié lors des audits de conformité. Conservez-les au minimum selon la durée exigée par votre régulateur sectoriel, l’ANSSI recommandant généralement plusieurs mois de rétention pour les systèmes considérés comme sensibles.

Cloudflare Tunnel face à NIS2, DORA et RGPD

La directive NIS2, transposée progressivement dans les droits nationaux des États membres, élargit fortement le nombre d’entités concernées par des obligations de cybersécurité en Europe, avec des exigences de gestion des risques et de notification d’incident. DORA impose des règles voisines au secteur financier, avec un accent particulier sur la résilience opérationnique numérique et la traçabilité des accès aux systèmes critiques. Dans les deux cas, la capacité à prouver qui a accédé à quoi, quand et depuis où, devient un critère d’audit central.

Un déploiement Cloudflare Tunnel bien construit répond directement à cette exigence. Les journaux de session Zero Trust évoqués à l’étape 12 enregistrent l’identité authentifiée, l’application visée, l’heure et le résultat de la politique appliquée. Exportés vers un SIEM, ils forment une piste d’audit exploitable sans développement supplémentaire côté équipe sécurité.

Le RGPD ajoute une contrainte distincte : la localisation et la durée de conservation des données de journalisation elles-mêmes. Avant de déployer Cloudflare Tunnel à grande échelle dans une organisation soumise à un contrôle strict de la CNIL ou d’une autre autorité de protection des données, faites valider par votre DPO la configuration de rétention des logs et les clauses contractuelles applicables au traitement de ces données par Cloudflare, en particulier si des filiales hors Union européenne sont concernées.

WARP et Cloudflare Access for Infrastructure : au-delà du HTTP

Les étapes précédentes couvrent un usage HTTP classique, adapté aux applications web. Mais une partie importante des besoins réels concerne l’accès SSH ou RDP à des serveurs internes, pas seulement des sites web. Pour ce cas, Cloudflare propose deux approches complémentaires.

La première repose sur le client WARP, installé sur le poste de chaque utilisateur autorisé. Une fois connecté à votre organisation Zero Trust, WARP route le trafic vers les ressources internes déclarées, avec les mêmes politiques Access que pour une application web. La seconde approche, plus récente, s’appuie sur Access for Infrastructure, pensée spécifiquement pour l’administration système : elle permet de publier un accès SSH nominatif, avec enregistrement de session et révocation immédiate en cas de départ d’un collaborateur, sans distribuer de clé SSH partagée.

cloudflared access ssh-config --hostname ssh.monentreprise.fr --short-lived-cert
ssh -o ProxyCommand="cloudflared access ssh --hostname ssh.monentreprise.fr" [email protected]

Cette commande génère un certificat SSH de courte durée, signé après validation de la politique Access, plutôt qu’une clé statique stockée sur le poste client. En cas de compromission d’un poste de travail, le certificat expire rapidement et ne peut pas être réutilisé indéfiniment, contrairement à une clé SSH classique oubliée dans un fichier authorized_keys.

Tarifs Cloudflare Zero Trust en 2026 : ce qui reste gratuit et ce qui ne l’est plus

Le plan gratuit couvre l’essentiel pour une petite structure ou un usage personnel : création de tunnels illimitée, Access pour un maximum de 50 utilisateurs uniques par mois, et un socle de politiques Gateway DNS. Au-delà, les plans payants ajoutent des fonctionnalités que les grandes organisations demandent en priorité : inspection HTTP approfondie dans Gateway, isolation de navigateur à l’échelle, journaux de session étendus, et support prioritaire.

Fonctionnalité	Plan gratuit	Plans payants
Nombre de tunnels	Illimité	Illimité
Utilisateurs Access	Jusqu’à 50/mois	Selon contrat
Politiques Gateway DNS	Incluses	Incluses + HTTP avancé
Journaux de session Zero Trust	Rétention limitée	Rétention étendue
MFA matériel (YubiKey PIV)	Disponible	Disponible
Isolation de navigateur	Non incluse	Incluse selon plan
Support	Communauté	Prioritaire/dédié

Pour la majorité des PME européennes qui découvrent Cloudflare Tunnel, le plan gratuit suffit à valider l’architecture avant tout engagement financier. Le passage à un plan payant se justifie surtout au-delà de 50 utilisateurs actifs ou lorsque l’inspection HTTP fine devient une exigence de conformité interne.

Projet complet : sécuriser une API Node.js multi-cloud de bout en bout

Assemblons les briques précédentes dans un scénario concret. Une PME héberge son API de facturation sur une instance AWS EC2 et son tableau de bord d’administration sur une VM Azure. L’objectif : publier les deux via un seul point d’entrée, sans port ouvert, avec authentification obligatoire et journalisation complète.

Sur l’instance EC2, cloudflared tourne en service systemd (étape 6) et route api.monentreprise.fr vers le port local 3000.
Sur la VM Azure, un second tunnel via Docker Compose (étape 7) route admin.monentreprise.fr vers le port 8080.
Cloudflare Access protège les deux hostnames avec la politique JSON de l’étape 8, restreinte au domaine d’entreprise et au MFA.
L’IdP Entra ID de l’entreprise est fédéré (étape 9), ce qui synchronise automatiquement l’arrivée et le départ des employés.
Les administrateurs se connectent au tableau de bord Cloudflare avec une clé YubiKey PIV (étape 10).
Les journaux de session (étape 12) sont exportés chaque nuit vers l’outil SIEM interne pour l’audit NIS2.

Résultat mesurable : aucune IP publique exposée sur les deux fournisseurs cloud, un point d’authentification unique, et une politique d’accès modifiable en quelques secondes depuis un seul tableau de bord, plutôt que deux pare-feux distincts à maintenir séparément.

Erreurs fréquentes à éviter avec Cloudflare Tunnel

La plupart des incidents rencontrés lors d’un premier déploiement ne viennent pas d’un bug côté Cloudflare, mais d’une étape de configuration oubliée ou mal ordonnée. La liste suivante rassemble les erreurs qui reviennent le plus souvent dans les retours d’expérience d’équipes DevOps ayant migré leurs premières applications vers ce modèle.

Oublier la règle catch-all http_status:404 dans config.yml, ce qui peut router du trafic non prévu vers le premier service déclaré.
Laisser le nuage DNS en gris (proxy désactivé) sur un enregistrement CNAME du tunnel, ce qui expose directement l’adresse cfargotunnel.com sans les protections Cloudflare.
Committer credentials.json ou le TUNNEL_TOKEN dans un dépôt Git public, une erreur qui revient régulièrement dans les incidents signalés par les équipes DevOps.
Configurer une politique Access trop permissive pendant les tests, puis oublier de la resserrer avant la mise en production.
Ne pas enrôler de clé MFA de secours, ce qui bloque totalement l’accès administrateur en cas de perte de la clé principale.
Multiplier les tunnels sans convention de nommage, rendant l’inventaire des accès illisible au bout de quelques mois.
Ignorer les changements d’API prévus le 5 octobre 2026, qui suppriment les points de terminaison de routes encodées en CIDR et retirent le champ “connections” des réponses de liste de tunnels, cassant les scripts d’automatisation non mis à jour.

Dépannage : 8 problèmes courants et leurs solutions

Quand un tunnel refuse de fonctionner comme prévu, le réflexe le plus rentable consiste à consulter systemctl status cloudflared et les journaux avant de modifier quoi que ce soit dans le tableau de bord. La majorité des problèmes se résolvent en quelques minutes une fois la cause exacte identifiée, résumés dans le tableau ci-dessous par ordre de fréquence observée.

Symptôme	Cause probable	Solution
Erreur 502 Bad Gateway	Le service local n’écoute pas sur le port déclaré	Vérifiez que l’application tourne bien avec curl localhost:PORT
Erreur 1033 Cloudflare Tunnel error	Aucun tunnel actif ne répond pour ce hostname	Contrôlez systemctl status cloudflared et les logs
Le tunnel se déconnecte sans cesse	Restrictions réseau sortantes ou proxy d’entreprise	Autorisez les domaines *.argotunnel.com en sortie
Politique Access jamais déclenchée	Le hostname n’est pas rattaché à une application Access	Recréez l’application dans Access avec le bon hostname exact
Boucle de connexion IdP infinie	Horloge serveur désynchronisée (SAML sensible au temps)	Synchronisez l’heure via NTP (chronyd ou systemd-timesyncd)
DNS ne se propage pas	Enregistrement CNAME créé mais nuage proxy désactivé	Activez le proxy (nuage orange) sur l’enregistrement
cloudflared refuse de démarrer en service	Chemin du fichier config.yml incorrect pour l’utilisateur système	Précisez –config avec le chemin absolu dans l’unité systemd
Accès bloqué après activation du MFA matériel	Aucune clé de secours enregistrée	Contactez le support Cloudflare avec preuve d’identité du compte

Cloudflare Tunnel face à Tailscale, ngrok et Twingate

Cloudflare Tunnel n’est pas le seul outil du marché à supprimer le besoin d’ouvrir un port entrant. Trois alternatives reviennent régulièrement dans les comparatifs des équipes DevOps européennes, chacune avec une philosophie différente.

Tailscale construit un réseau maillé (mesh) fondé sur le protocole WireGuard, où chaque appareil communique directement avec les autres plutôt que de passer systématiquement par un point central. C’est un excellent choix pour connecter des postes de développeurs entre eux ou à un petit cluster, mais son modèle diffère de la publication d’une application web au grand public. ngrok, de son côté, cible avant tout les développeurs qui veulent exposer temporairement un service local pour une démonstration ou un webhook de test, avec une mise en route quasi instantanée mais des fonctionnalités Zero Trust plus limitées côté politiques d’entreprise. Twingate, enfin, adopte une architecture proche de Cloudflare Access, avec un accent marqué sur la segmentation réseau fine pour les grandes organisations.

Outil	Architecture	Cas d’usage principal	Plan gratuit
Cloudflare Tunnel + Access	Proxy inversé sortant + Access	Applications web et infra d’entreprise	Oui, jusqu’à 50 utilisateurs
Tailscale	Mesh WireGuard	Connexion directe entre appareils	Oui, usage limité
ngrok	Tunnel HTTP temporaire	Démonstration, webhook, développement	Oui, très limité
Twingate	Zero Trust segmenté	Grandes organisations, réseaux complexes	Oui, usage limité

Pour une PME qui veut publier une poignée d’applications web internes avec authentification centralisée, Cloudflare Tunnel reste souvent le choix le plus rapide à déployer, en particulier si le domaine est déjà géré chez Cloudflare pour d’autres usages comme le DNS ou la protection DDoS. Le vrai critère de décision tient rarement à la technique pure, mais à l’écosystème déjà en place dans votre organisation.

Rien n’empêche d’ailleurs de combiner plusieurs outils selon les équipes : Tailscale pour le mesh interne entre serveurs de développement, et Cloudflare Tunnel pour la publication contrôlée des applications destinées aux utilisateurs finaux ou aux partenaires externes. Cette approche hybride reste courante dans les organisations qui ont grandi par acquisitions successives, avec des piles techniques hétérogènes à faire cohabiter sans tout réécrire d’un coup.

Astuces avancées : DNSSEC, DNS interne et chiffrement post-quantique

Le client cloudflared prend désormais en charge le DNSSEC passthrough sur son proxy DNS local, une évolution du changelog d’avril 2026 qui renforce l’intégrité de la résolution de noms côté poste utilisateur. Activez-la si votre organisation impose déjà DNSSEC sur son domaine principal, pour éviter toute rupture de la chaîne de validation entre le client et le résolveur.

Cloudflare a également généralisé courant 2026 son service Internal DNS, qui permet de résoudre des noms internes privés directement dans Zero Trust, sans exposer ces enregistrements publiquement. Combiné à une politique Gateway, cela remplace avantageusement un serveur DNS interne traditionnel pour les équipes déjà engagées dans une migration Zero Trust.

Pour les connexions site à site via IPsec, activez le support post-quantique annoncé en février 2026 si votre appliance Cloudflare One le permet. C’est un chantier à anticiper, en particulier pour les secteurs régulés par l’ANSSI en France, qui pousse vers une bascule progressive des mécanismes cryptographiques sensibles avant la fin de la décennie.

Enfin, pour les déploiements à grande échelle, tirez parti du pilotage centralisé des versions client, disponible depuis avril 2026, qui permet de déployer une nouvelle version de cloudflared par groupes d’utilisateurs plutôt qu’en une seule vague, avec possibilité de retour en arrière rapide en cas de régression.

Un dernier réglage mérite l’attention des équipes itinérantes : le client Cloudflare One apprend désormais le comportement réseau de chaque connexion et adapte l’ordre de repli entre HTTP/2 et HTTP/3 selon ce que le réseau local supporte réellement, une amélioration du changelog d’août 2026 qui réduit les micro-coupures observées lors des déplacements entre différents réseaux Wi-Fi ou mobiles au sein de l’Union européenne.

Supervision et alerting : garder un œil sur vos tunnels en production

Un tunnel qui tombe silencieusement en pleine nuit peut couper l’accès à une application critique sans qu’aucune équipe ne s’en aperçive avant le lendemain matin. Trois pratiques limitent ce risque. D’abord, surveillez l’état du service via un moniteur externe classique (Uptime Kuma, Better Uptime, ou équivalent) qui interroge régulièrement le hostname public, indépendamment de Cloudflare lui-même.

Ensuite, exploitez les métriques exposées localement par cloudflared sur son port de diagnostic, activable avec le flag –metrics. Elles remontent notamment le nombre de connexions actives et les erreurs de heartbeat vers le réseau Cloudflare, exploitables par Prometheus si votre stack de supervision en dépend déjà.

cloudflared tunnel --metrics localhost:9090 run api-production
curl http://localhost:9090/metrics | grep cloudflared_tunnel

Enfin, configurez des alertes directement dans le tableau de bord Cloudflare Notifications pour être averti par email ou webhook dès qu’un tunnel passe à l’état dégradé, plutôt que de découvrir l’incident via un ticket client. Pour une PME sans astreinte 24/7, coupler ce webhook à un canal Slack ou Teams dédié reste la solution la plus simple à mettre en place en une dizaine de minutes.

Check-list finale avant la mise en production

Avant de considérer votre déploiement Cloudflare Tunnel comme terminé, passez en revue ces points. Ils reprennent les erreurs les plus fréquemment rencontrées par les équipes qui migrent leur premier service vers ce modèle.

Le nuage DNS est actif (orange) sur tous les enregistrements CNAME du tunnel, pas seulement sur le domaine racine.
Chaque application sensible dispose d’une politique Access testée en navigation privée, avec un compte qui n’est pas celui de l’administrateur.
Le fichier credentials.json et le TUNNEL_TOKEN sont exclus du dépôt Git via .gitignore, et stockés dans un gestionnaire de secrets si possible.
Au moins un administrateur dispose d’une clé MFA matérielle de secours enregistrée, en plus de la clé principale.
Les journaux de session Zero Trust sont activés et leur export vers le SIEM ou l’outil d’archivage est vérifié fonctionnel.
Un moniteur externe indépendant de Cloudflare surveille la disponibilité de chaque hostname publié.
La convention de nommage des tunnels (environnement, service) est documentée pour l’équipe, pas seulement dans la tête de la personne qui a fait le déploiement initial.

Foire aux questions

Cloudflare Tunnel est-il gratuit ?
Oui, la création et l’exploitation de tunnels sont incluses dans le plan gratuit de Cloudflare. Seules certaines fonctionnalités avancées de Zero Trust, au-delà de 50 utilisateurs, nécessitent un plan payant.

Cloudflare Tunnel remplace-t-il un VPN d’entreprise ?
Pour l’accès à des applications web spécifiques, oui dans la plupart des cas. Pour un accès réseau complet type site à site, un VPN classique ou une solution IPsec reste souvent nécessaire en complément.

Peut-on utiliser Cloudflare Tunnel sans domaine Cloudflare ?
Non, le tunnel nécessite que votre domaine soit géré par les serveurs DNS de Cloudflare, au minimum pour les enregistrements du hostname publié.

Le tunnel fonctionne-t-il avec des protocoles non HTTP, comme SSH ?
Oui, cloudflared peut router du trafic SSH, RDP ou TCP brut, généralement via le client Warp ou un accès Access for Infrastructure dédié.

Que se passe-t-il si le serveur Cloudflare tombe en panne ?
Le trafic vers vos applications publiées via tunnel devient inaccessible tant que le service Cloudflare concerné n’est pas rétabli, un point à considérer dans votre plan de continuité d’activité.

Cloudflare Tunnel est-il compatible RGPD ?
L’outil lui-même ne pose pas de blocage particulier, mais vérifiez la localisation de traitement des journaux et discutez des clauses contractuelles avec votre délégué à la protection des données selon votre secteur.

Combien de tunnels peut-on créer par compte ?
Il n’existe pas de limite basse pratique pour un usage normal, mais organisez vos tunnels par environnement (production, préproduction, test) plutôt qu’un tunnel unique pour tout.

Le MFA matériel est-il obligatoire pour tous les utilisateurs ?
Non, il est recommandé pour les comptes à privilèges élevés en priorité. Un MFA logiciel classique (TOTP) reste suffisant pour la majorité des utilisateurs finaux d’une application protégée par Access.

Cloudflare Tunnel fonctionne-t-il derrière un proxy d’entreprise strict ?
Généralement oui, à condition que le proxy autorise le trafic HTTPS sortant vers les domaines Cloudflare requis. Sur un réseau très restrictif, testez d’abord depuis un poste hors proxy pour isoler la cause avant de modifier les règles de sortie.

Faut-il migrer tous les services d’un coup vers Cloudflare Tunnel ?
Non, une migration progressive service par service, en commençant par une application non critique, limite le risque d’incident et laisse le temps à l’équipe de se familiariser avec les politiques Access avant de toucher aux systèmes sensibles.

Contenus associés

Pour aller plus loin sur les architectures cloud sécurisées, consultez notre rubrique Cloud. Sources techniques utilisées pour ce tutoriel : la documentation officielle de Cloudflare Tunnel, le changelog Cloudflare One, le changelog du client cloudflared, le blog Cloudflare One, ainsi que les recommandations de l’ANSSI et de l’ENISA sur la sécurisation des accès distants.

Cloudflare Tunnel : Zero Trust en 12 Étapes, 60 Min [2026]