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

> Comment restreindre l'accès à un environnement de préview découplé aux seules personnes autorisées, sans imposer un VPN à toute une équipe éditoriale ?

- Auteur : WordPress Développement
- Publié le : 2022-12-07
- Mis à jour le : 2022-12-07
- Catégorie : Headless & API
- URL : https://www.wpmoderne.fr/headless/cloudflare-access-preview-headless-sans-vpn/

## L’essentiel

- Cloudflare Access s'appuie sur l'identité existante, pas un VPN dédié
- La règle d'accès se configure sans toucher au code du front
- Un e-mail professionnel suffit à autoriser une personne

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.

> L'essentiel à retenir : Cloudflare Access s'appuie sur l'identité existante, pas un VPN dédié ; La règle d'accès se configure sans toucher au code du front ; Un e-mail professionnel suffit à autoriser une personne

## É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.