Architecture · Livraison statique + environnement explicite
WordPress statique avec environnement dynamique sur AWS
Conservez la livraison publique des pages WordPress sur S3 et CloudFront, puis attribuez à chaque fonction interactive son propre environnement du navigateur au service, sans replacer tout le site sur PHP et MySQL.
CMS WordPress ↓ Static Publisher S3 + CloudFront ├→ Gatey → Amazon Cognito ├→ Flow → backend de workflow ├→ AI-Kit → backend d’IA/connaissances configuré ├→ chemins protégés → accès signé └→ actions applicatives → API protégées
Limite d’exécution
Classez l’environnement par fonction, pas par site
« Statique » décrit la livraison de la page. Cela n’impose pas la disparition de la connexion, des formulaires, des discussions, de l’IA ou des actions applicatives. Chaque capacité peut franchir une limite d’exécution distincte uniquement lorsqu’un visiteur l’utilise.
Requête de page publique → CloudFront → HTML/ressources statiques Connexion → navigateur → Cognito Chemin statique protégé → identité → accès signé → CloudFront Formulaire / brouillon / discussion → navigateur → backend Flow IA / DocSearch → navigateur → mode local ou backend configuré Écriture applicative → navigateur → API autorisée
Limite de confiance La visibilité dans le frontend n’est pas une autorisation. L’identité, l’accès aux fichiers protégés, la validation des formulaires, l’accès à l’IA et les écritures d’API doivent être imposés par le service responsable.
Plan de contrôle et plan d’exécution
Cette matrice sépare la responsabilité éditoriale de l’exécution. Elle montre ce qui reste dans WordPress et ce qui passe au navigateur ou aux services AWS lorsque la livraison publique devient statique.
| Responsabilité | Rôle de WordPress | Rôle AWS/environnement | Pourquoi cette séparation compte |
|---|---|---|---|
| Contenu et mise en page | Les éditeurs créent les pages dans Gutenberg et publient les CPT | La livraison statique sert le résultat rendu | Le workflow éditorial reste familier et le trafic public évite PHP. |
| Interface d’authentification | La page contient un bloc, shortcode ou widget Gatey | Cognito gère connexion, MFA, SSO et jetons | La connexion survit à l’export, car elle s’exécute dans le navigateur face à Cognito. |
| Contenu protégé | WordPress définit l’emplacement des sections protégées | Les cookies signés CloudFront imposent l’accès aux objets | Les pages statiques privées n’exigent pas de sessions WordPress. |
| Formulaires et workflows | Mise en page et intention sont éditées dans WordPress | Le backend valide, stocke, achemine et déclenche les actions | Les soumissions évoluent indépendamment de la livraison des pages. |
| Fonctions d’IA | Blocs, chatbot, sources KB et réglages vivent dans WP Admin | Appels de modèles, RAG, garde-fous et journaux tournent dans le backend | L’intelligence du contenu devient une capacité gouvernée, pas un proxy PHP. |
| Fonctions applicatives | WordPress rend boutons, conteneurs et interface liée au compte | API Gateway et Lambda imposent l’autorisation et écrivent l’état | Le frontend reste statique tandis que l’application reste interactive. |
Limite d’exécution Flow après le modèle backend
Ce tableau se concentre sur Flow. Il sépare routes visiteurs, routes administratives et exécution asynchrone afin d’expliquer pourquoi ces responsabilités sont hors de la requête WordPress.
| Surface | Routes d’exemple | Responsabilité | Pourquoi hors de PHP |
|---|---|---|---|
| Formulaires frontend | /frontend/forms/{formId}/submit, /drafts, /upload-url | Valider les entrées, accepter brouillons et références, déclencher le traitement ultérieur. | Le navigateur soumet depuis une page statique ; le backend gère validation, abus et durabilité. |
| Opérations d’administration | /admin/forms, /admin/submissions, /admin/templates, /admin/workflows, /admin/webhook-endpoints | Configurer définitions, modèles et workflows via des routes protégées. | Les écritures peuvent exiger Cognito/IAM, portées et restrictions IP indépendamment de la livraison. |
| Exécution des workflows | Dispatchers EventBridge pour soumissions, états, e-mail et webhooks | Traiter de façon asynchrone et consigner les événements sans garder la requête ouverte. | Les formulaires deviennent des workflows fiables, pas un POST WordPress synchrone fragile. |
Carte des surfaces d’exécution
Utilisez cette matrice comme liste de contrôle sécurité et exploitation. Elle associe chaque surface à son authentification, son risque principal et la limite d’application recommandée.
| Surface | Authentification typique | Composant WP Suite | Risque principal | Limite recommandée |
|---|---|---|---|---|
| Page anonyme | Aucune | Sortie Static Publisher | Pages, listes ou ressources obsolètes | Base vérifiée, manifeste maîtrisé, invalidation CloudFront et vérification publique. |
| Interface connexion/profil | Client public Cognito | Blocs Gatey Authenticator et Account Attribute | URL de rappel ou hypothèses de jeton incorrectes | Cognito App Client, domaine de rappel et gestion des jetons. |
| Chemin statique protégé | Cognito avant émission du cookie | Flux Static Site Guardian | Portée, expiration et rotation | Cookies signés CloudFront et service de signature. |
| Appel public de formulaire ou d’IA | NONE + reCAPTCHA/WAF ou Cognito | Routes AI-Kit et points Flow | Abus et coût de modèle/soumission | Limites, validation, reCAPTCHA, WAF et quotas. |
| Appel API membre | JWT Cognito ou IAM | Accès API protégé par Gatey | Confondre visibilité et autorisation | Mécanisme API Gateway, portées ou signatures IAM. |
| Opération d’administration | IAM ou portées Cognito admin | Routes admin AI-Kit, opérations KB | Exposer des opérations privilégiées | Route /admin distincte, authentification stricte, liste IP. |
Conception des API et du cache
La séparation des environnements modifie aussi les règles de livraison. Le tableau traduit l’architecture en choix de cache, séparation des API, CORS, état et gestion visible des erreurs.
| Domaine | Bon modèle | Mauvais modèle | Pourquoi |
|---|---|---|---|
| Cache HTML statique | Cache longue durée avec invalidation déterministe après publication | Cache court partout parce qu’un composant est dynamique | Un widget dynamique ne doit pas replacer toute la page en mode serveur. |
| Routes d’API | Surfaces /frontend et /admin séparées avec authentification et limitation distinctes | Un point générique pour toutes les actions | Widgets publics et opérations privilégiées ont des risques différents. |
| CORS | Autoriser précisément les domaines statiques et environnements nécessaires | CORS générique avec requêtes authentifiées | Les sites statiques ont souvent plusieurs hôtes ; CORS doit être explicite. |
| Widgets avec état | Stocker l’état dans Cognito, DynamoDB, des objets S3 temporaires ou un backend dédié | Supposer une session WordPress après l’export | La page exportée n’a pas de session PHP lors des requêtes publiques. |
| Gestion des erreurs | Afficher des états utiles : authentification requise, réessayer, indisponible | Échec silencieux de la page lorsque l’API est bloquée | Le frontend devient la limite d’exécution visible. |
Parcours d’implémentation
Séparez d’abord la livraison, puis ajoutez uniquement les environnements nécessaires
L’architecture est plus simple à exploiter lorsque chaque besoin dynamique possède un responsable et un chemin de défaillance explicites.
- Conserver WordPress comme source éditoriale — Créez et révisez les pages dans WordPress, puis publiez des résultats cacheables avec Static Publisher vers S3 et CloudFront.
- Associer les fonctions interactives à leur limite de service — Utilisez Cognito pour l’identité, Flow pour l’état des formulaires et workflows, AI-Kit pour les chemins d’IA locaux ou configurés, l’accès signé pour le contenu statique protégé et des API dédiées pour les écritures.
- Protéger chaque environnement indépendamment — Appliquez l’autorisation, la validation, CORS, le WAF, la limitation ou les contrôles anti-abus adaptés à chaque limite de service, sans compter sur une session WordPress ou un état frontend caché.
- Tester la production comme une application de navigateur — Vérifiez ressources exportées, URL de rappel, CORS, états authentifiés et anonymes, pannes d’API et accès expirés depuis le domaine de production.
Quand cette architecture constitue la bonne limite
Bon choix
Sites principalement cacheables avec certaines fonctions actives
- Le site public est surtout éditorial, mais les utilisateurs ont encore besoin de connexion, formulaires, discussions, IA ou ressources protégées.
- Vous souhaitez conserver WordPress comme CMS familier sans placer PHP et MySQL dans chaque requête publique.
- Les différentes fonctions d’exécution exigent des limites distinctes de sécurité, de mise à l’échelle ou de responsabilité.
Choisir un autre modèle
Un autre environnement peut être plus simple lorsque
- La plupart des pages doivent être personnalisées côté serveur avant leur rendu.
- Une application frontend séparée est déjà une exigence produit, rendant l’architecture headless intentionnelle.
- WordPress dynamique traditionnel répond déjà proprement au besoin et séparer les services n’ajoute aucune limite opérationnelle utile.
Guides pratiques
Étapes suivantes à partir de l’architecture
Comment rendre WordPress statique sans perdre les fonctions dynamiques ?
Commencez par Rendez WordPress statique sans perdre ses fonctions dynamiques. Le guide associe connexion, formulaires, discussions, notes, IA et contenu protégé à des environnements explicites.
Comment conserver WordPress pour l’édition sans l’exposer publiquement ?
Consultez Conserver WordPress pour l’édition sans l’exposer publiquement pour la séparation entre origine éditoriale et livraison publique, puis utilisez cette architecture pour choisir les environnements actifs.
Comment les formulaires longs et workflows de révision fonctionnent-ils après une publication statique ?
Consultez Enregistrer un long formulaire et le reprendre, Remplacer les validations par e-mail et tableur par un workflow et Créer un workflow de révision avec formulaires, discussion et notes pour les chemins Flow.
Comment la connexion et le contenu protégé fonctionnent-ils sans sessions PHP ?
Consultez Ajouter une connexion à WordPress statique sans réintroduire les sessions PHP pour l’identité Cognito et WordPress statique sécurisé avec des cookies signés CloudFront pour le mécanisme de livraison.
Commencez par le problème d’acheteur
Choisissez la limite d’exécution selon la fonction à préserver
Utilisez d’abord les guides pratiques pour identifier l’interaction requise, puis revenez à l’architecture pour définir les limites d’implémentation et de confiance.