cloudflared tunnel --url localhost:8080 : cette seule commande a remplacé un serveur de démonstration partagé que nous maintenions depuis plusieurs années, sur lequel chaque projet client disposait d’un sous-domaine dédié pointant vers une instance Docker isolée. Ce serveur, pratique à l’origine, avait fini par accumuler une dette technique caractéristique de ce type d’infrastructure mutualisée à usage interne : versions de PHP disparates entre projets, ports à réserver manuellement pour éviter les conflits, et une charge de maintenance qui ne diminuait jamais malgré des projets de démonstration qui, eux, se terminaient régulièrement.
Le constat déclencheur a été simple : sur les douze derniers mois, ce serveur avait hébergé en moyenne huit projets actifs simultanément, mais son historique de configuration en comptait plus de quarante, la plupart abandonnés sans être proprement désinstallés par manque de temps au moment où le projet se terminait. Un tunnel Cloudflare par projet, ouvert à la demande depuis l’environnement local du développeur, a permis de supprimer complètement ce besoin de serveur central.
Le principe : exposer un environnement local, pas un serveur distant
Plutôt que de déployer chaque projet de démonstration sur une infrastructure partagée distante, le tunnel Cloudflare expose directement l’environnement de développement local du poste du développeur, via une connexion sortante chiffrée établie par le client cloudflared, sans qu’aucun port entrant n’ait besoin d’être ouvert sur le réseau local. Le client reçoit une URL publique en HTTPS, valable tant que le tunnel reste actif, sans configuration DNS manuelle à chaque nouvelle démonstration.
Mise en place pour un projet type
# Installation ponctuelle du client
brew install cloudflared
# Ouverture d'un tunnel vers l'environnement local DDEV du projet
cloudflared tunnel --url https://projet-client.ddev.site:443
Pour une démonstration récurrente sur plusieurs semaines plutôt qu’un test ponctuel, un tunnel nommé avec un sous-domaine stable reste préférable à un tunnel jetable dont l’URL change à chaque redémarrage :
cloudflared tunnel create demo-client-xyz
cloudflared tunnel route dns demo-client-xyz demo-xyz.notre-domaine-agence.fr
cloudflared tunnel run --url https://projet-client.ddev.site:443 demo-client-xyz
Ce que ce changement supprime concrètement
- Plus de réservation manuelle de ports ou de sous-domaines sur un serveur central partagé entre plusieurs développeurs.
- Plus de mise à jour de version PHP ou de dépendances système à synchroniser entre projets hébergés sur la même machine.
- Plus de nettoyage périodique de projets abandonnés : un tunnel s’arrête simplement quand le développeur ferme sa session, sans laisser de trace résiduelle sur une infrastructure partagée.
Ce que ce changement demande en contrepartie
Cette approche a une limite qu’il faut assumer : la démonstration dépend de la machine du développeur qui reste allumée et connectée pendant toute la durée de la démo. Pour une démonstration ponctuelle en visioconférence, ce n’est pas un problème. Pour un accès que le client souhaite pouvoir tester de façon autonome sur plusieurs jours sans que le développeur soit présent, un environnement plus pérenne (staging classique ou WordPress Playground selon le cas) reste plus adapté que le tunnel.
Sécuriser l’accès au-delà du simple lien
Un tunnel Cloudflare génère une URL publique accessible à quiconque la connaît. Pour les démonstrations sensibles, une couche d’authentification Cloudflare Access a été ajoutée, limitant l’accès à une liste d’adresses email autorisées avec vérification par code à usage unique envoyé par email, sans nécessiter de compte ou de mot de passe partagé côté client.
Un serveur de démonstration partagé rend service au premier projet et devient un fardeau au vingtième. Le vrai gain d’un tunnel par projet n’est pas la rapidité de mise en place, mais l’absence totale de dette accumulée dans le temps.
Notre retour d’expérience
Depuis l’abandon du serveur de démonstration central, le temps consacré à la maintenance d’infrastructure de démo est passé de quelques heures par mois à pratiquement zéro. Le principal changement d’habitude a été culturel plutôt que technique : accepter qu’une démonstration client dépende d’un environnement local temporaire, ouvert à la demande, plutôt que d’une adresse fixe toujours disponible, ce qui a en réalité rarement posé de difficulté en pratique.
