Cloudflare Access devant une préview headless, sans déployer de VPN

Comment restreindre l’accès à un environnement de préview d’un front Next.js découplé aux seules personnes de l’équipe éditoriale, sans demander à chacune d’installer un client VPN ni de retenir un mot de passe partagé qui finit toujours par fuiter ? Cette question s’est posée sur un projet dont l’environnement de préview, hébergé sur un sous-domaine distinct de la production, restait accessible publiquement à quiconque en connaissait l’URL.

La réponse ne demande ni infrastructure VPN ni modification du code applicatif : Cloudflare Access, une fonctionnalité de la suite Zero Trust de Cloudflare, s’intercale devant le sous-domaine de préview et exige une authentification avant de laisser passer la moindre requête, sans qu’aucune ligne de code du front n’ait à en tenir compte.

Le problème initial

L’environnement de préview reposait sur un déploiement Vercel séparé, accessible via un sous-domaine du type preview.exemple.fr, sans aucune restriction d’accès autre qu’une éventuelle protection basique par mot de passe partagé au niveau de la plateforme d’hébergement — une protection contournable dès que le mot de passe circule au-delà de l’équipe initiale, ce qui finit toujours par arriver sur la durée d’un projet.

La solution : Cloudflare Access en frontal

Cloudflare Access fonctionne comme une couche d’authentification placée devant un sous-domaine, sans nécessiter de modification du service qu’il protège. Une fois le sous-domaine configuré pour passer par Cloudflare (DNS proxifié), une règle d’application Access peut être définie directement dans le tableau de bord Cloudflare Zero Trust.

Étapes de configuration

1. Ajouter le sous-domaine preview.exemple.fr comme application protégée, dans Cloudflare Zero Trust > Access > Applications.
2. Définir une politique d’accès basée sur le domaine e-mail professionnel de l’équipe, par exemple toute adresse se terminant par @exemple.fr.
3. Choisir une méthode d’authentification : Cloudflare propose nativement l’authentification par code envoyé par e-mail (« one-time PIN »), sans compte préalable à créer.
4. Publier la politique et vérifier qu’une tentative d’accès depuis une adresse hors domaine autorisé est bien rejetée.
5. Documenter la procédure pour l’équipe éditoriale : un e-mail professionnel suffit, sans identifiant supplémentaire à retenir.

Ce que cela donne concrètement

Requête vers preview.exemple.fr
        │
        ▼
   Cloudflare Access intercepte la requête
        │
        ├── Session valide existante → laisse passer vers Vercel
        │
        └── Pas de session
              └── Redirection vers la page de connexion Access
                    └── Saisie de l'e-mail professionnel
                          └── Code a usage unique envoye par e-mail
                                └── Verification du domaine autorise
                                      └── Session ouverte, acces accorde

Aucune requête n’atteint jamais directement le déploiement Vercel sans être passée par cette vérification, puisque le sous-domaine, une fois proxifié par Cloudflare, ne peut plus être atteint autrement — à condition, bien sûr, que l’URL directe de déploiement Vercel elle-même reste, elle, non communiquée publiquement.

Une variante plus fine : accès par groupe

Pour les équipes plus larges incluant des prestataires externes sans adresse e-mail au domaine de l’entreprise, Cloudflare Access permet de définir une politique par liste d’adresses e-mail explicites plutôt que par domaine complet, ou de s’appuyer sur un fournisseur d’identité existant (Google Workspace, Microsoft Entra ID) déjà utilisé par ailleurs dans l’organisation.

• Politique par domaine e-mail : la plus simple pour une équipe interne homogène.
• Politique par liste d’adresses : adaptée à des prestataires ponctuels.
• Intégration à un fournisseur d’identité existant : évite de dupliquer une gestion des accès déjà en place ailleurs.

Un environnement de préview mérite la même rigueur d’accès qu’un environnement de production, dès lors qu’il expose du contenu non encore publié : la différence de criticité perçue ne doit jamais se traduire par une absence de contrôle d’accès.

Pour aller plus loin

Cette configuration ne traite volontairement pas la sécurité de l’environnement de production lui-même, qui suit généralement des règles différentes, notamment parce qu’il doit rester accessible publiquement par définition. Elle répond à un besoin plus circonscrit : garantir qu’un contenu en cours de rédaction ne soit visible que par les personnes légitimement autorisées à le consulter, sans ajouter la moindre friction technique côté équipe éditoriale.