Architecture · Page pilier
Architecture de référence WordPress sur AWS
Une cartographie technique détaillée pour conserver WordPress comme couche éditoriale tandis qu’AWS prend en charge l’identité, la diffusion statique, l’environnement d’exécution protégé, l’IA et les workflows.
Thèse architecturale : WordPress doit rester le CMS et l’interface d’administration, sans constituer l’unique frontière d’exécution de chaque fonctionnalité. WP Suite transforme WordPress en frontend d’application composable en déplaçant l’identité, la diffusion protégée, l’IA, les API et les workflows vers des services AWS appartenant au client.
Pourquoi cette architecture existe
La plupart des schémas d’architecture WordPress partent encore de la même hypothèse : WordPress assure l’environnement d’exécution public. PHP génère la page, MySQL traite la requête, les extensions s’exécutent dans le même processus et la montée en charge consiste à ajouter de la capacité au même stack.
WP Suite suit une autre voie. WordPress reste le plan de contrôle éditorial et administratif, mais les responsabilités d’exécution sont réparties entre les services AWS les mieux adaptés : diffusion statique en périphérie, identité dans Cognito, API dans API Gateway et Lambda, IA dans des services reposant sur Bedrock et workflows dans une infrastructure événementielle.
L’objectif n’est pas de remplacer WordPress par une reconstruction headless. Il s’agit de ne plus faire passer chaque besoin applicatif par l’environnement d’exécution WordPress lorsque le site est déjà devenu plus qu’un simple site de publication.
Frontière du système
Éditeurs / administrateurs
│
▼
WordPress + Gutenberg
contenu, mise en page, réglages, UX d’administration
│
couche d’intégration WP Suite
│
┌─────────────────────────┼─────────────────────────┐
│ │ │
▼ ▼ ▼
Diffusion statique Plan d’identité API d’exécution
Static Publisher Gatey + Cognito API Gateway + Lambda
S3 + CloudFront User/Identity Pools logique métier
│ │ │
└──────────────┬──────────┴──────────────┬──────────┘
▼ ▼
Environnement du navigateur Plan IA / workflows
pages générées avec Gutenberg Bedrock, S3, DynamoDB,
composants côté client EventBridge, SES, WAF
La frontière est volontairement simple : WordPress gère la création de contenu, la structure des URL, le balisage Gutenberg, les workflows éditoriaux et la configuration des modules. AWS gère les chemins d’exécution qui nécessitent une mise à l’échelle indépendante, une isolation renforcée, un accès tenant compte de l’identité, le traitement d’événements ou l’accès aux modèles.
Static Publisher fait partie de la stratégie de diffusion, mais ne constitue pas à lui seul un stack CloudFormation. Il exporte et publie le site généré vers une cible de diffusion AWS ; les capacités reposant sur des stacks concernent l’identité, la diffusion protégée, le backend d’IA et l’environnement d’exécution des workflows.
Cartographie des capacités
Plan de contenu
WordPress et Gutenberg
La couche d’édition habituelle reste la source de référence pour les pages, les articles, les blocs, le contenu des CPT, la mise en page, les métadonnées et la configuration des produits.
Plan de diffusion
Static Publisher, S3 et CloudFront
Les pages et ressources générées peuvent être servies depuis S3 et CloudFront afin que le trafic public ne dépende plus d’une capacité PHP/MySQL active.
Plan d’identité
Gatey et Amazon Cognito
L’authentification, l’inscription, la MFA, le SSO, les groupes, les JWT et les identifiants IAM facultatifs sont délégués à Cognito et utilisés directement dans le navigateur.
Plan statique protégé
Static Site Guardian
Des chemins statiques sélectionnés peuvent être protégés au niveau de CloudFront au moyen de cookies signés, d’un service de signature et de parcours de connexion intégrés à Cognito.
Environnement d’exécution applicatif
API Gateway et Lambda
Les comportements d’exécution tels que les actions de compte, les données protégées, les étapes de workflow et la logique d’intégration sont exposés sous forme d’API ciblées plutôt que de points de terminaison AJAX WordPress.
Environnement d’exécution de l’IA
AI-Kit, Bedrock et S3 Vectors
L’IA sur l’appareil peut traiter les tâches locales, tandis que le backend de secours et les workflows RAG s’exécutent, si nécessaire, dans un backend AWS appartenant au client.
Plan des workflows
Flow et services événementiels
Les formulaires et soumissions en plusieurs étapes peuvent déclencher des flux de traitement par e-mail, webhook, EventBridge, agent d’IA ou backend.
Plan de provisionnement
Deployment Wizard et CloudFormation
Les capacités AWS reproductibles sont déployées au moyen de modèles guidés, afin que les agences et les équipes puissent standardiser l’implémentation sans construire manuellement chaque stack.
Flux de requêtes canoniques
Flux 1
Requête de page statique publique
Un visiteur demande une page publique. CloudFront sert depuis S3 le HTML exporté et les ressources. WordPress ne se trouve pas dans le chemin de la requête : les pics de trafic sollicitent donc le CDN plutôt que les workers PHP et les connexions à la base de données.
Flux 2
État de l’utilisateur connecté
Gatey affiche l’interface de connexion Cognito dans la page. Le navigateur s’authentifie auprès de Cognito, reçoit des jetons et expose l’état d’identité aux blocs WP Suite sans stocker de secrets ni de jetons sur le serveur WordPress.
Flux 3
Appel d’API protégé
Un composant frontend appelle API Gateway avec une autorisation fondée sur JWT ou IAM. Lambda exécute la logique métier et renvoie uniquement les données que l’utilisateur authentifié est autorisé à consulter.
Flux 4
Chemin statique protégé
Un visiteur accède à une route protégée. CloudFront vérifie les cookies signés. S’ils sont absents ou expirés, l’utilisateur est redirigé vers la connexion ; après validation, le service de signature accorde l’accès à l’ensemble des chemins protégés.
Flux 5
Requête IA/RAG
AI-Kit tente d’utiliser l’IA locale du navigateur lorsque cela convient. Si un backend est nécessaire, le navigateur appelle le point de terminaison d’API configuré, qui achemine la requête via Lambda vers Bedrock, les documents S3, les métadonnées de la base de connaissances et les garde-fous.
Flux 6
Requête du formulaire vers le workflow
Un formulaire Flow capture l’interaction frontend, puis confie le traitement durable à des actions backend, à l’e-mail, à un webhook, à EventBridge ou à des étapes d’IA, au lieu de dépendre d’une seule requête PHP synchrone.
Familles d’architectures reposant sur CloudFormation
Deployment Wizard convertit un nombre limité de décisions produit en paramètres CloudFormation, ouvre le parcours de vérification « Create stack » d’AWS, puis utilise les sorties du stack — URL de base d’API, ARN de rôles, identifiants de User Pool ou paramètres de distribution — comme contrat de retour vers WordPress. Chaque famille de modèles doit correspondre à une responsabilité architecturale réelle.
| Famille de modèles | Responsabilité principale | Ressources AWS typiques | Angle de l’article |
|---|---|---|---|
| Identité Cognito à partir du deuxième jour | Transformer Cognito en socle d’identité WordPress réutilisable | User Pool, App Client, Identity Pool, rôles IAM, déclencheurs Lambda, modèles d’e-mail S3, Route53 facultatif | L’identité ne se limite pas à la connexion : elle couvre la conception des jetons, le mappage des groupes, l’envoi des e-mails et l’autorisation des API. |
| Static Site Guardian | Protéger des chemins statiques sélectionnés sans réintroduire un environnement d’exécution PHP | S3, CloudFront, Key Groups/Public Keys, Lambda de signature ou logique en périphérie, API Gateway, KMS/SSM, Route53 facultatif | L’export statique résout la diffusion, mais les contenus privés exigent une autorisation en périphérie et une gestion rigoureuse des cookies. |
| Backend AI-Kit | Fournir le backend de secours, le RAG et les API de chatbot dans le compte du client | API Gateway, Lambda, Bedrock, S3, S3 Vectors/Knowledge Base, DynamoDB, EventBridge, WAF, SSM/KMS | L’IA privée est un modèle d’infrastructure, pas seulement une fonctionnalité de LLM. |
| Backend Flow | Exécuter les workflows issus de formulaires en dehors du cycle de vie des requêtes WordPress | API Gateway, Lambda, tables DynamoDB pour formulaires/soumissions/événements/modèles/workflows/webhooks, buckets S3 pour les charges utiles et les modèles, EventBridge, SES, WAF et reCAPTCHA | Les formulaires deviennent des frontends applicatifs lorsque la validation, les brouillons, les téléversements, les e-mails, les webhooks et les événements de workflow sont pris en charge par un backend dédié. |
| Cible Static Publisher | Publier la sortie WordPress générée vers une cible de diffusion AWS | Utilise des cibles de déploiement S3/CloudFront, mais ne nécessite pas de stack dédié | Le pipeline de diffusion et l’architecture d’exécution sont liés, mais ne sont pas identiques. |
Frontières de sécurité et de confiance
La décision de conception la plus importante consiste à éviter que WordPress ne devienne le détenteur de tous les secrets, jetons et décisions d’exécution. Dans ce modèle, WordPress stocke la configuration et génère les blocs ; le navigateur, Cognito, CloudFront et API Gateway font respecter les frontières de sécurité.
Aucun secret client dans WordPress
Conception Cognito pour client public
Gatey est conçu autour des parcours Cognito côté navigateur. Le serveur WordPress n’a pas besoin de relayer les mots de passe, de conserver les jetons utilisateur ni de détenir un secret client Cognito.
Autorisation en périphérie
Chemins protégés au niveau de CloudFront
Le contenu statique peut rester privé lorsque CloudFront impose des cookies signés avant de servir les objets S3.
Autorisation des API
JWT ou IAM au niveau d’API Gateway
Les actions protégées doivent être autorisées au niveau de l’API, et non masquées au moyen de CSS frontend ou de règles de visibilité propres à WordPress.
Surfaces distinctes
Routes d’administration, frontend et publiques
La surface d’API pour l’administration et l’édition, celle destinée aux visiteurs du frontend et la surface statique publique doivent être limitées, authentifiées et journalisées indépendamment.
Backend appartenant au client
Infrastructure dans le compte AWS du client
L’architecture est la plus robuste lorsque les chemins sensibles d’exécution, d’identité et d’IA résident dans le compte du client plutôt que dans une boîte noire SaaS partagée.
Moindre privilège par stack
Périmètre d’impact IAM réduit
Chaque modèle doit provisionner uniquement les autorisations nécessaires à la capacité concernée et exposer des sorties permettant sa composition avec d’autres stacks.
Modèle de performances, de coûts et de mise à l’échelle
Les stacks WordPress dynamiques traditionnels sont souvent dimensionnés pour les pics de charge : capacité PHP, capacité de base de données, couches de cache et parfois clusters de bases de données prévus pour des événements rares. Cela se justifie pour certaines charges de travail, mais coûte cher lorsque la plupart des pages peuvent être mises en cache et que seules certaines interactions nécessitent un comportement à l’exécution.
Le modèle WP Suite sépare la surface toujours active de la surface à la demande. Le HTML public et les ressources sont diffusés en périphérie. Les fonctions d’exécution évoluent indépendamment et ne s’exécutent que lorsqu’un visiteur se connecte, envoie un formulaire, pose une question à l’IA ou appelle une API protégée.
| Dimension | WordPress dynamique traditionnel | Répartition WP Suite sur AWS | Pourquoi c’est important |
|---|---|---|---|
| Diffusion des pages publiques | PHP et la base de données restent associés à l’origine, même avec la mise en cache | S3 et CloudFront servent le HTML exporté et les ressources | Les pics de trafic n’impliquent pas automatiquement une mise à l’échelle de PHP ou de la base de données. |
| Identité | La logique des extensions s’exécute souvent dans WordPress et y stocke l’état de session | Cognito gère l’authentification, la MFA, le SSO et les jetons | L’authentification peut survivre à l’export statique et reste indépendante de l’hébergement WordPress. |
| Comportement dynamique | AJAX/admin-ajax ou points de terminaison PHP personnalisés | API Gateway et Lambda pour chaque capacité d’exécution | Chaque fonctionnalité peut évoluer, échouer et être sécurisée indépendamment. |
| IA | Appels d’API externes depuis PHP ou une extension SaaS tierce | D’abord sur l’appareil, avec backend de secours dans le compte AWS du client | Conserve les contenus, les prompts, les documents et les politiques au plus près de leur propriétaire. |
| Compromis opérationnel | Modèle mental plus simple, couplage d’exécution plus fort | Davantage d’architecture, moins de couplage | La séparation est rentable lorsque la sécurité, la mise à l’échelle, la confidentialité ou la reproductibilité comptent. |
Modèle opérationnel
L’architecture traite chaque stack comme un sous-système délimité, avec des sorties, des journaux, des autorisations et des exigences de retour arrière.
Stratégie d’environnements
Stacks de développement, de préproduction et de production
Utilisez si possible des stacks et des domaines distincts. Static Publisher peut publier le même résultat d’exploration vers plusieurs cibles de déploiement lorsque seuls le domaine et le bucket diffèrent.
Observabilité
Journaux à la bonne frontière
CloudFront, API Gateway, Lambda, les déclencheurs Cognito, WAF et les appels Bedrock doivent chacun avoir un responsable clairement identifié pour les journaux et un parcours de débogage défini.
Retour arrière
Restaurer séparément le contenu et l’environnement d’exécution
Le retour arrière d’un contenu ne doit pas nécessiter un nouveau déploiement de l’identité. La correction d’une fonction Lambda ne doit pas imposer de réexporter l’ensemble du site.
Contrôle de dérive
Des modèles plutôt que de l’archéologie dans la console
Le déploiement fondé sur CloudFormation rend l’architecture prévue visible et reproductible, au lieu de dépendre d’étapes de console recréées manuellement.
Isolation des défaillances
Structure statique en priorité
Si un point de terminaison d’IA est temporairement indisponible, le contenu public doit continuer à se charger. Si l’administration WordPress est hors service, le frontend statique peut rester disponible.
Revue de sécurité
Examiner les frontières de confiance, pas seulement les extensions
La revue pertinente porte sur les endroits où les jetons, cookies, clés, rôles et routes protégées sont effectivement contrôlés.
Parcours d’implémentation
- Identifiez les parties du site réservées au contenu, authentifiées, statiques protégées, enrichies par l’IA, pilotées par des formulaires ou par des API.
- Sélectionnez la première capacité AWS : identité, protection statique sécurisée, backend d’IA ou environnement d’exécution de workflows.
- Déployez le modèle correspondant par l’intermédiaire de Deployment Wizard ou du parcours CloudFormation, puis relevez les sorties du stack.
- Renseignez ces sorties dans la configuration de l’extension WP Suite concernée.
- Ajoutez un runbook couvrant les paramètres, les sorties, le DNS, les certificats, les journaux, le retour arrière et la responsabilité du compte AWS.
- Ne composez la capacité suivante que lorsque sa frontière est claire ; évitez de transformer le premier projet en migration globale de la plateforme.
Quand cette architecture convient
- Un site WordPress a besoin d’authentification, de contenu protégé, de fonctions d’IA, de formulaires ou d’API, tandis que les pages publiques doivent rester rapides et nécessiter peu de maintenance.
- Une agence souhaite une architecture AWS reproductible et appartenant au client plutôt que des stacks d’extensions ponctuels.
- Un CTO souhaite utiliser WordPress pour la productivité éditoriale sans confier chaque besoin d’exécution à PHP/MySQL.
- Un site de documentation, une base de connaissances ou un portail a besoin de contenu public, de sections privées et de recherche par IA dans une même expérience.
- Une équipe souhaite réduire l’exposition de l’origine sans reconstruire le site sous forme d’application entièrement headless.
Quand ne pas l’utiliser
- Un simple site vitrine ne comporte ni connexion, ni routes protégées, ni IA, ni workflow, ni besoin significatif d’exécution.
- L’équipe ne peut ni assumer ni déléguer la responsabilité d’un compte AWS, du DNS, des certificats et de la supervision opérationnelle.
- Pour des raisons organisationnelles ou contractuelles, tous les comportements dynamiques doivent rester dans les extensions WordPress existantes.
- Le projet privilégie la rapidité d’une implémentation ponctuelle plutôt qu’une architecture réutilisable.
Ressources associées
Analyse détaillée
Architecture d’identité Cognito à partir du deuxième jour
Analyse détaillée du socle d’identité Cognito déployé avec CloudFormation
Analyse détaillée
WordPress statique sécurisé avec des cookies signés
Analyse détaillée de la diffusion statique protégée, des cookies CloudFront et de la connexion Cognito
Produit
Flow
Couche d’automatisation des formulaires et des workflows pour des expériences WordPress proches d’une application
Famille de produits
WP Suite Platform
La cartographie générale de la plateforme qui sous-tend le groupe d’architectures
Guide d’implémentation
Documentation d’implémentation
Documentation pour les développeurs et références d’API
Agences
WP Suite pour les agences
Diffusion dans un environnement AWS appartenant au client et parcours de déploiement standardisé
FAQ
S’agit-il d’une architecture WordPress headless ?
Pas au sens habituel. WordPress reste le système d’édition et de contenu, et le frontend peut toujours être une sortie WordPress générée avec Gutenberg. L’environnement d’exécution est réparti afin de déplacer certaines capacités vers des services AWS.
Static Publisher nécessite-t-il un stack CloudFormation ?
Non. Static Publisher est le pipeline de publication. Il peut publier vers des cibles de diffusion AWS, mais n’a pas besoin de son propre stack CloudFormation dédié dans le modèle WP Suite.
Quelles parties reposent réellement sur des modèles ?
Les principales familles reposant sur des stacks sont l’identité, la diffusion statique protégée, le backend d’IA et l’environnement d’exécution des workflows. Elles peuvent être adoptées indépendamment et composées au moyen des sorties et de la configuration des extensions.
Pourquoi ne pas simplement utiliser un hébergement WordPress infogéré ?
L’hébergement infogéré reste un bon choix pour de nombreux sites. L’architecture répartie devient utile lorsque l’identité, les routes privées, l’IA, les workflows, l’infrastructure appartenant au client ou une isolation stricte de l’environnement d’exécution sont importants.
Cette architecture peut-elle être introduite progressivement ?
Oui. Commencez par la capacité dont la frontière est claire, comme la connexion Cognito ou une section statique protégée, puis n’ajoutez un environnement d’exécution pour l’IA ou les workflows que lorsque le cas d’usage le justifie.
Utilisez WordPress comme CMS et AWS comme environnement d’exécution
Utilisez cette page pilier comme point de départ : comprenez d’abord l’ensemble du système, puis approfondissez l’identité, la diffusion statique protégée, l’IA et les workflows.