Cloudflare

Statut

Document de cadrage DevOps — v1.1 — relu le 2026-05-11, corrigé le 2026-07-18 après vérification directe du Dashboard Cloudflare.

Rôle

Cloudflare est stratégique pour l'écosystème DMV, principalement comme couche d'entrée réseau et sécurité.

Il peut contribuer à DNS, proxy, TLS, cache, protection, Pages, Workers et éventuellement gateway pour certains usages futurs.

État actuel confirmé (2026-07-18)

Contrairement à ce qu'indiquait la version précédente de ce document (« pas de configuration Cloudflare dédiée visible »), la configuration production est active et a été vérifiée directement dans le Dashboard :

• Deux projets Cloudflare Pages : dmv-public (domaines dansmonvillage.fr, www.dansmonvillage.fr, dmv-public.pages.dev) et dmv-workspace (Custom Domain mon-espace.dansmonvillage.fr, actif — voir remarque ci-dessous).
• Un Worker Cloudflare (nommé mon-espace, nom historique — voir 06-architecture/wall-engine/08-workspace-boundary.md) proxifie dansmonvillage.fr/acteur* et dansmonvillage.fr/mairie* vers le projet Pages dmv-workspace, afin que la gestion acteur/mairie reste sur la même origine que le site public — condition nécessaire à la continuité de la PWA en mode standalone sur iOS.
• Le Custom Domain mon-espace.dansmonvillage.fr reste actif au niveau Cloudflare Pages mais est un domaine technique/historique, à ne plus utiliser dans les parcours utilisateurs (voir règles non négociables du document de référence).
• Détail complet (table de routage, diagramme de flux, variables) : 06-architecture/wall-engine/08-workspace-boundary.md, désormais la référence pour cette architecture.

Le frontend public contient une dépendance @marsidev/react-turnstile, ce qui indique un usage possible de Cloudflare Turnstile côté interface publique.

Usages cibles

Usage	Rôle
DNS	Centraliser la gestion des domaines et sous-domaines.
Proxy	Masquer l'origine et absorber une partie du trafic.
TLS	Fournir HTTPS et renouvellement simplifié côté edge.
Cache	Accélérer assets et contenus publics.
WAF	Filtrer requêtes suspectes et protéger routes sensibles.
Pages	Déploiement possible de frontends statiques si retenu.
Workers	Automatisations edge ciblées, sans logique métier sensible.
Turnstile	Protection anti-abus sur formulaires publics.

Politique de cache

Le cache doit rester prudent.

Peuvent être cacheables :

• assets statiques ;
• images publiques ;
• pages publiques explicitement non personnalisées ;
• contenus publics peu sensibles.

Ne doivent pas être cacheés sans règle stricte :

• réponses authentifiées ;
• backoffice ;
• données utilisateur ;
• endpoints de paiement ;
• webhooks ;
• réponses IA personnalisées ;
• espaces mairie, AssoSuite ou administration privés.

IA et Cloudflare

Cloudflare peut devenir une brique d'infrastructure pour une gateway, du filtrage ou des Workers.

Cela relève de la vision cible. La logique IA métier doit rester centralisée côté backend ou AI Gateway, sans accès direct non contrôlé aux données.

Principes

• Cloudflare complète Laravel et Nginx, il ne les remplace pas.
• Les règles critiques doivent exister aussi côté backend.
• Toute règle WAF doit être testée pour éviter les faux positifs.
• Les changements DNS doivent être tracés.
• Les webhooks Stripe doivent rester compatibles avec la validation de signature.

Points à clarifier

• Zones Cloudflare réellement actives.
• Plan Cloudflare utilisé.
• Règles WAF et cache en production.
• Usage de Cloudflare Pages ou Workers.
• Politique Turnstile.
• Procédure de désactivation temporaire en cas d'incident.