Cloudflare devant tout : ce qu'un proxy protège

« On a mis Cloudflare devant, on est protégés. » La phrase est à moitié vraie. Un proxy inverse placé devant un site ou une application change beaucoup de choses : les attaques par saturation s’arrêtent avant le serveur, les requêtes suspectes sont filtrées, les fichiers partent d’un cache proche du visiteur. Mais il ne voit que ce qui passe par lui, et il agit parfois en votre nom sans que vous l’ayez demandé. Cet article fait la part des choses, dans le cadre de notre guide du socle d’infrastructure cloud.

Nous prenons Cloudflare pour exemple parce que nous l’utilisons et que ses réglages sont documentés publiquement. Le même montage existe ailleurs : chez les grands clouds (Amazon CloudFront avec AWS WAF, Azure Front Door, Google Cloud Armor), chez des réseaux de diffusion comme Fastly, Akamai ou l’européen Bunny, ou avec un proxy inverse installé sur votre propre serveur. Les questions de cet article valent pour tous.

Ce que fait un proxy inverse

Ce placement explique tout le reste : le proxy protège ce qui passe par lui, et seulement cela.

Ce qu’il protège

Les attaques par saturation. Une attaque qui inonde un serveur de requêtes le met à terre, quelle que soit la qualité de son code. Un réseau mondial absorbe ce volume avant qu’il n’arrive chez vous. La documentation de Cloudflare sur la protection DDoS indique qu’une protection standard et sans limite de volume, des couches réseau jusqu’à la couche applicative, est comprise dans toutes les offres.

Les requêtes suspectes. Le pare-feu applicatif examine les requêtes web et API entrantes et filtre le trafic indésirable selon des jeux de règles : règles gérées par l’éditeur, règles que vous écrivez, limites de fréquence. L’étendue dépend de l’offre : sur l’offre d’entrée, un seul jeu de règles gérées et une seule règle de limitation de fréquence.

Le chiffrement et le cache. Le proxy présente un certificat aux visiteurs, et sert depuis son cache les fichiers qui ne changent pas. Un site statique y gagne le plus : ses pages entières sont des fichiers.

L’adresse de votre serveur. Quand les enregistrements DNS passent par le proxy, le visiteur ne voit que les adresses du proxy. À une condition, détaillée plus bas : que rien d’autre ne trahisse l’adresse réelle.

Ce qu’il ne protège pas

Le serveur joignable en direct. Cloudflare détaille, dans sa page sur la protection du serveur d’origine, ce qui peut trahir l’adresse réelle : des enregistrements DNS non relayés (SPF, TXT), un serveur de messagerie hébergé sur la même machine, l’historique DNS d’avant la mise en place du proxy. Ses parades : n’accepter sur le serveur que le trafic venant des adresses de Cloudflare, authentifier les requêtes du proxy, ou un tunnel sortant qui évite toute adresse publique. Et changer l’adresse du serveur après la mise en place.

L’application elle-même. Un pare-feu applicatif reconnaît des attaques connues ; il ne corrige pas une extension vulnérable ni une logique fautive. Les mises à jour restent votre affaire, comme le montre notre article sur les sites WordPress piratés.

Les identifiants. Une connexion avec un mot de passe ou une clé d’API volés ressemble à une connexion normale. Ce risque se traite ailleurs : un gestionnaire de mots de passe pour l’équipe et la protection des clés d’API des projets d’IA.

Un proxy agit aussi en votre nom

Un proxy peut modifier ce que votre site sert : ajouter des en-têtes, réécrire une adresse, injecter un fichier. Ces options sont utiles quand on les choisit, piégeuses quand elles sont activées par défaut.

La règle qui en découle est simple : on vérifie ce que sert l’adresse de production, pas ce que contient le dépôt. Les conséquences de ce blocage sur la visibilité dans les assistants d’IA sont détaillées dans notre article sur ce qui rend un site citable par les IA.

Un point de passage unique

Tout passe par le proxy : s’il tombe, vos services tombent avec lui, même si votre serveur va bien. Cloudflare a publié le récit détaillé de sa panne du 18 novembre 2025 :

1. 11 h 20 UTC

   Le réseau de Cloudflare commence à échouer à acheminer le trafic. Un fichier de configuration de la gestion des robots, devenu trop gros après une modification de droits dans une base de données, fait planter le logiciel du proxy.

2. 17 h 06 UTC

   Tous les systèmes de Cloudflare fonctionnent de nouveau normalement.

Ce n’est pas un argument contre les proxys : un serveur seul tombe aussi, et plus souvent. C’est un argument pour l’écrire dans le plan. Trois précautions suffisent : une sonde extérieure qui teste le service à travers le proxy (voir notre guide de la supervision), une procédure écrite pour servir le site sans le proxy si la panne dure, et des accès au compte du proxy rangés avec les autres accès de secours dans le plan de reprise après sinistre.

Ce que nous faisons

Sur un serveur à soi, le même principe s’applique en plus petit : un proxy inverse unique devant tous les services, qui centralise les certificats et les règles d’accès, avec les services eux-mêmes fermés à internet.

Par où commencer

1. 01Inventorier ce qui est exposé.

   Chaque domaine et sous-domaine, ce qu’il sert, et s’il passe par le proxy.

2. 02Fermer l’accès direct.

   Le serveur n’accepte que le proxy, puis changer son adresse si elle a déjà circulé.

3. 03Relire les options activées.

   Gestion des robots, réécritures, fichiers ajoutés : garder ce qu’on a choisi, retirer le reste.

4. 04Vérifier ce qui est servi.

   Robots.txt, en-têtes et redirections, à l’adresse de production.

5. 05Prévoir la panne.

   Une sonde extérieure, une procédure de contournement écrite, des accès de secours.

Le reste du chantier

Le proxy n’est qu’une couche du socle. Le lieu d’hébergement se choisit selon l’usage (serveur dédié, VPS ou cloud) et sa facture se surveille (les postes qui gonflent une facture cloud). Ce que le proxy ne protège pas se traite par les sauvegardes, par une base de données bien exploitée (Postgres géré ou à soi) et par une infrastructure qu’on sait reconstruire (l’infrastructure as code). Kubernetes n’est pas nécessaire pour mettre un proxy devant quelques services (quand une PME n’en a pas besoin), et n8n en production se place derrière lui comme les autres (n8n auto-hébergé). La messagerie, qui peut trahir l’adresse d’un serveur, a son propre article (e-mail pro : Google, Microsoft ou hébergeur européen). Côté décisions : les outils à sortir du SaaS en premier, le coût d’une sortie du SaaS sur trois ans, la migration cloud sans tout casser, la dépendance au cloud américain, le matériel pour faire tourner un modèle d’IA et NIS2 en France.

Notre sortie du SaaS installe vos outils derrière un proxy inverse unique, sur un serveur à vous, avec sauvegardes testées et documentation d’exploitation : 5 500 € et trois semaines.

Questions fréquentes

Sources

1. Cloudflare, protection DDoS (nouvel onglet)developers.cloudflare.com
2. Cloudflare, pare-feu applicatif (WAF) (nouvel onglet)developers.cloudflare.com
3. Cloudflare, protéger son serveur d’origine (nouvel onglet)developers.cloudflare.com
4. Cloudflare, Cloudflare outage on November 18, 2025 (nouvel onglet)blog.cloudflare.com