Architecture · Analyse détaillée · Modèle de déploiement
Architecture d’AWS Deployment Wizard pour les équipes WordPress
Une architecture pratique qui transforme les choix produit de WP Suite en déploiements CloudFormation reproductibles dans le compte AWS du client.
Thèse architecturale : Deployment Wizard n’est pas un simple écran de configuration esthétique. Il fait le lien entre l’intention produit dans WordPress et la propriété de l’infrastructure AWS : il recueille quelques décisions importantes, ouvre le parcours de vérification « Create stack » de CloudFormation, déploie dans le bon compte, puis reconnecte les sorties obtenues à WordPress.
Pourquoi l’expérience de déploiement fait partie de l’architecture
La plupart des utilisateurs WordPress ne souhaitent pas concevoir manuellement API Gateway, Lambda, Cognito, DynamoDB, WAF ou Bedrock. La plupart des architectes AWS ne veulent pas qu’une extension crée une infrastructure critique tout en masquant ses actions. WP Suite doit rassurer les deux parties.
Deployment Wizard résout cette tension en restant volontairement léger. Il recueille les décisions au niveau du produit, génère un parcours CloudFormation prérempli et laisse AWS demeurer l’endroit où le stack est vérifié, créé et détenu.
C’est pourquoi ce sujet mérite son propre article d’architecture : le modèle de provisionnement fait partie de la relation de confiance. Il explique comment WP Suite peut proposer des modèles AWS avancés sans devenir une dépendance SaaS hébergée et opaque.
Frontière du système
WP Suite / réglages de l’extension
l’utilisateur choisit la fonctionnalité souhaitée et quelques options importantes
│
▼
Deployment Wizard
valide les choix et construit les paramètres CloudFormation
│
▼
AWS Console → CloudFormation → Create stack (vérification)
le client vérifie les ressources, les paramètres, IAM et les sorties
│
▼
Stack AWS appartenant au client
Cognito / backend d’IA / backend Flow / stack de diffusion protégée
│
▼
Sorties CloudFormation
ApiBaseUrl, UserPoolId, ARN de rôles, détails de distribution/domaine, noms de buckets
│
▼
Configuration de l’extension WordPress
Gatey, AI-Kit, Flow ou les composants de protection statique appellent le backend déployé
La frontière essentielle est celle de la propriété. WP Suite peut générer le parcours de déploiement, mais l’environnement d’exécution appartient au compte AWS dans lequel le stack est créé.
Le contrat du wizard
| Élément du contrat | Ce que gère le wizard | Ce que gèrent AWS et CloudFormation |
|---|---|---|
| Collecte des décisions | Ne demander que les quelques décisions produit qui modifient la forme du stack : fonctionnalités, mode d’authentification, protections facultatives, domaines et valeurs d’intégration. | Valider les paramètres, créer les ressources, suivre la dérive et les mises à jour, puis exposer les sorties. |
| Source du modèle | Pointer CloudFormation vers la bonne version de l’artefact de modèle hébergé dans S3. | Lire le modèle et créer les ressources déclarées dans le compte et la région cibles. |
| Étape de vérification | Diriger l’utilisateur vers la vérification « Create stack » avec les paramètres préremplis. | Afficher le contexte final des ressources, d’IAM et du change set avant le déploiement. |
| Connexion après déploiement | Indiquer à l’utilisateur quelles sorties doivent être copiées dans les réglages WordPress. | Produire des sorties telles que les URL de base d’API, les identifiants Cognito, les ARN de rôles, les noms de buckets ou les paramètres de distribution. |
| Gestion des versions | Exposer les décisions produit sans risque et exclure des choix utilisateur habituels les valeurs de version contrôlées par les développeurs. | Utiliser les versions des modèles afin de mettre à jour l’infrastructure déployée de manière prévisible. |
Pourquoi ne pas tout déployer directement depuis WordPress ?
Une extension WordPress peut offrir une interface conviviale, mais elle ne doit pas devenir silencieusement le plan de contrôle de l’infrastructure des comptes AWS de production. Pour les CTO et les agences, l’étape de vérification dans AWS n’est pas une friction : c’est le point de gouvernance où IAM, les régions, la facturation, le DNS et la responsabilité opérationnelle sont visibles.
| Provisionnement masqué par l’extension | Deployment Wizard + CloudFormation | Pourquoi WP Suite choisit la seconde approche |
|---|---|---|
| Premier clic simple, faible piste d’audit | L’utilisateur voit un stack CloudFormation dans le compte AWS | L’infrastructure reste identifiable par le client ou l’agence. |
| L’extension nécessite des identifiants AWS étendus | AWS Console gère les autorisations de création du stack | WP Suite n’a pas besoin de stocker des identifiants cloud client de longue durée. |
| Difficile à reproduire pour plusieurs clients | Les paramètres et les sorties forment un contrat reproductible | Les agences peuvent rédiger des runbooks et comparer les environnements. |
| Le compte du fournisseur peut détenir l’environnement d’exécution | Le compte du client détient les ressources d’exécution | Les données, les journaux, les coûts et les contrôles de sécurité restent au plus près du client. |
Conception des paramètres : poser moins de questions, sans masquer davantage
Un bon assistant de déploiement n’expose pas tous les paramètres CloudFormation. Il expose les décisions qui modifient l’architecture et masque celles qui relèvent du processus de publication ou de version. Par exemple, un assistant pour backend d’IA peut demander quelles fonctionnalités frontend et quelles protections sont nécessaires, tout en maintenant DeploymentVersion sous le contrôle des développeurs.
Commutateurs de fonctionnalités
N’activer que ce dont le site a besoin
Un site qui n’a besoin que de DocSearch ne doit pas déployer accidentellement toutes les routes publiques d’IA possibles.
Modes d’authentification
Séparer les surfaces frontend et d’administration
Les API d’administration peuvent appliquer par défaut Cognito et des contrôles de scopes, tandis que les routes publiques peuvent utiliser reCAPTCHA, WAF ou Cognito selon le cas d’usage.
Choix de domaine
Le DNS est facultatif, mais explicite
Les domaines personnalisés, les certificats et les enregistrements Route53 doivent être présentés comme des choix visibles, car ils influent sur la propriété et le dépannage.
Contrôles de sécurité
Les protections sont des choix d’architecture
WAF, les listes d’adresses IP autorisées, reCAPTCHA, KMS et les options de type GuardDuty modifient la manière dont le backend peut être exposé en toute sécurité.
Source de l’artefact
Les modèles doivent être lisibles par CloudFormation
Avec des liens directs vers les modèles, CloudFormation exige une URL de modèle S3 ; la politique du bucket d’artefacts doit autoriser le principal de service CloudFormation à le lire.
Transmission de l’intégration
Les sorties du stack relient les composants
Les valeurs telles que ApiBaseUrl doivent être copiées depuis CloudFormation et non déduites des conventions de nommage.
Familles de stacks dans le modèle WP Suite
| Famille de stacks | Objectif du wizard | Contrat de sortie type | Pourquoi c’est important |
|---|---|---|---|
| Identité Cognito / Gatey | Créer ou rattacher un socle d’identité Cognito réutilisable avec App Client, groupes, déclencheurs et domaine personnalisé facultatif. | User Pool ID, App Client ID, Identity Pool ID, ARN de rôles, valeurs de domaine. | La connexion devient une couche d’identité d’exécution réutilisable, et non un simple réglage d’extension au niveau d’une page. |
| Backend AI-Kit | Activer dans le compte du client le backend de secours, le chatbot, DocSearch/RAG ainsi que les routes protégées d’IA et d’administration. | ApiBaseUrl, paramètres de routes et d’authentification, et identifiants de base de connaissances ou de stockage le cas échéant. | L’IA privée devient une capacité backend déployable plutôt qu’une fonctionnalité d’extension uniquement disponible en SaaS. |
| Backend Flow | Déployer l’environnement d’exécution des formulaires, soumissions, brouillons, téléversements, modèles, workflows, e-mails et webhooks. | URL de base d’API ou domaine personnalisé, sorties de buckets, tables et fonctions, ainsi que choix de routes et d’authentification. | Les formulaires deviennent des workflows durables qui peuvent fonctionner avec la diffusion statique et les intégrations externes. |
| Diffusion statique protégée | Créer le modèle d’autorisation en périphérie pour les chemins statiques privés. | Distribution ou domaine CloudFront, points de terminaison de signature et d’API, paramètres de clés et de cookies. | La protection de WordPress statique privé peut être appliquée au niveau du CDN ou des objets. |
| Cible Static Publisher | Publier la sortie WordPress générée vers des cibles de diffusion AWS ; aucun stack dédié n’est requis pour le publisher lui-même. | Configuration de la cible de déploiement plutôt qu’un stack d’exécution distinct. | La publication et l’architecture d’exécution restent liées sans être confondues. |
Le contrat de sortie est le point de reconnexion avec WordPress
Le déploiement n’est utile que si WordPress peut l’utiliser. Cette connexion doit être simple et explicite : déployer le stack, copier les sorties, les coller dans les réglages de l’extension, puis tester la route. AI-Kit en est l’exemple le plus clair : après le déploiement, l’utilisateur copie ApiBaseUrl depuis les sorties CloudFormation vers AI-Kit Settings → API Settings.
| Type de sortie | Exemple de valeur | Utilisation dans WordPress |
|---|---|---|
| URL de base d’API | https://abc123.execute-api.region.amazonaws.com/prod ou domaine personnalisé | Les blocs AI-Kit et Flow ainsi que les écrans d’administration savent où envoyer les requêtes backend. |
| Identifiants Cognito | User Pool ID, App Client ID, Identity Pool ID | Gatey peut afficher l’Authenticator et obtenir des jetons pour les API protégées. |
| ARN de rôles / scopes | ARN de rôles IAM, scopes dérivés de groupes, scopes d’administration | Les API peuvent imposer l’autorisation au lieu de faire confiance à un état frontend masqué. |
| Valeurs de distribution et de domaine | Domaine de distribution CloudFront, point de terminaison émetteur de cookies signés | La protection statique et les cibles de publication peuvent être documentées et vérifiées. |
| Noms des buckets et des tables | Bucket de charges utiles, bucket de modèles, tables de données | Les runbooks et les diagnostics peuvent orienter les opérateurs vers les bonnes ressources AWS. |
Modèle de gouvernance pour les agences et les CTO
Propriété du client
L’environnement d’exécution est déployé dans le bon compte AWS
Les agences peuvent déployer dans leur propre compte ou dans celui du client selon le contrat, les exigences de conformité et le modèle de support.
IAM vérifiable
La vérification du stack expose les autorisations
Les architectes peuvent examiner IAM et la création des ressources avant le lancement, au lieu de faire confiance à un parcours d’extension opaque.
Support reproductible
Même modèle, paramètres différents
Les runbooks peuvent décrire une fois les paramètres, les sorties, le DNS, les certificats, les journaux et le retour arrière, puis réutiliser ce modèle pour plusieurs clients.
Visibilité des coûts
La facturation AWS suit le compte de déploiement
Le client ou l’agence peut consulter directement les coûts des API, de Lambda, des modèles, du stockage, de WAF et de la journalisation.
Contrôle des changements
Les mises à jour sont des modifications de stack
Une nouvelle fonctionnalité d’exécution peut être introduite en mettant à jour un stack ou une version, plutôt qu’en modifiant manuellement des ressources dans la console.
Parcours de sortie
Les ressources restent visibles
Même si l’extension WordPress change par la suite, les ressources AWS déployées ne sont pas masquées dans un compte fournisseur inaccessible.
Modes de défaillance que l’article doit expliciter
| Mode de défaillance | Ce qui se produit | Comment le documenter |
|---|---|---|
| Mauvaise région | Le stack est déployé, mais les ressources associées, comme les certificats ou la configuration Cognito, se trouvent dans une autre région. | Répertorier les régions requises pour chaque famille de stacks et signaler les contraintes liées aux certificats et aux domaines. |
| Sortie non copiée | L’extension WordPress pointe encore vers un point de terminaison ancien ou vide. | Faire de la copie des sorties un élément de la liste de contrôle du déploiement, et non une connaissance informelle de l’équipe. |
| Incompatibilité de l’authentification d’administration | Le backend attend des données Cognito, IAM ou des scopes que l’extension n’est pas configurée pour envoyer. | Documenter le mode d’authentification, les scopes et les appels de test immédiatement après le déploiement. |
| DNS ou certificat partiellement configuré | Le domaine personnalisé existe, mais le certificat, Route53 ou le mappage d’API est incomplet. | Distinguer dans le runbook « stack déployé » et « domaine personnalisé actif ». |
| Dérive de versions | Un site utilise d’anciennes ressources du stack avec les attentes d’une interface d’extension plus récente. | Suivre ensemble les versions du modèle et de l’extension dans le dossier client. |
Parcours d’implémentation
- Partez de la fonctionnalité produit : identité, backend d’IA, backend Flow, contenu statique protégé ou cible de diffusion.
- Définissez l’ensemble minimal de choix visibles nécessaires pour configurer ce stack.
- Générez une URL de vérification CloudFormation « Create stack » avec des paramètres préremplis.
- Après le déploiement, copiez les sorties pertinentes dans les réglages de l’extension WP Suite correspondante.
- Testez séparément les routes publiques, protégées et d’administration.
- Consignez dans le runbook du site les paramètres, les sorties, le DNS, les certificats, les modes d’authentification, les journaux et les consignes de retour arrière.
Ressources associées
Analyse détaillée
Architecture de référence WordPress sur AWS
L’article pilier qui réunit dans un même modèle le déploiement, l’identité, la diffusion statique, l’IA et l’environnement d’exécution des workflows.
Analyse détaillée
Backend privé d’IA et de RAG
L’article consacré au backend AI-Kit dans lequel la sortie ApiBaseUrl devient le contrat d’intégration avec WordPress.
Analyse détaillée
Backend événementiel pour formulaires et workflows
Le stack du backend Flow comme exemple concret de déploiement guidé pour les formulaires et les workflows.
Solution
WordPress pour les agences sur AWS
L’argument commercial et opérationnel en faveur d’une infrastructure reproductible appartenant au client.
FAQ
Deployment Wizard est-il un stack d’exécution distinct ?
Non. Il s’agit d’une couche de provisionnement guidé. Le stack d’exécution est celui qu’il aide à déployer, comme Cognito, le backend AI-Kit, le backend Flow ou la diffusion statique protégée.
Pourquoi utiliser CloudFormation plutôt qu’une API personnalisée qui crée les ressources AWS ?
CloudFormation fournit au client un stack vérifiable dans son propre compte, avec des paramètres, des sorties et une gestion du cycle de vie. Il évite également que WP Suite doive stocker des identifiants cloud étendus et de longue durée.
Que faut-il documenter après le déploiement ?
Au minimum : les paramètres sélectionnés, les sorties du stack, les réglages copiés dans l’extension, les choix de DNS et de certificats, les modes et scopes d’authentification, les groupes de journaux, les ressources sensibles aux coûts et les étapes de retour arrière.
Déployez les stacks d’exécution WP Suite sans masquer l’architecture AWS
Utilisez un déploiement CloudFormation guidé pour créer des backends AWS appartenant au client, puis reconnectez les sorties du stack à WordPress.