Architecture · Formulaires, validation et exécution des workflows
Backend événementiel de formulaires et de workflows pour WordPress sur AWS
Conservez la création et le placement des formulaires dans WordPress, tandis que les brouillons persistants, envois, échanges, états de validation, notifications et actions en aval s’exécutent derrière une frontière explicite d’API et d’événements.
WordPress / frontend statique
↓
Exécution Flow
API frontend
↓
État des envois et brouillons
├→ fichiers
├→ échanges / état de validation
└→ événements de workflow
↓
e-mails / webhooks / actions
Frontière d’exécution
Un formulaire devient un workflow lorsque son état doit survivre à la requête de page
Les formulaires longs, les validations et les processus de revue nécessitent un état persistant. Flow sépare l’expérience du navigateur de la persistance du backend et de l’exécution en aval. La page publique peut ainsi rester statique tandis que le processus continue indépendamment.
Interface de formulaire / revue dans WordPress
↓ navigateur
API /frontend/*
├→ enregistrer / charger / finaliser le brouillon
├→ envoyer l’enregistrement
├→ contrat d’envoi de fichier
└→ échanges / évaluations
↓
état persistant + événements
/admin/* → gestion protégée
↓
distribution du workflow → e-mail / webhook / action
Frontière de sécurité Les routes publiques des formulaires et les routes administratives privilégiées présentent des profils de risque différents. Les contrôles des envois anonymes, l’accès authentifié des réviseurs et la configuration administrative ne doivent pas partager une surface d’autorisation trop large.
Ce que crée la pile Flow
Le backend Flow sépare API, calcul, état, charges utiles, événements, sécurité et exploitation. Cet inventaire associe chaque rôle architectural aux ressources AWS correspondantes.
| Couche | Ressources AWS | Rôle architectural |
|---|---|---|
| Couche API | API REST API Gateway régionale, domaine personnalisé facultatif, enregistrements Route53 facultatifs | Expose séparément les routes frontend et admin sans lier l’exécution des formulaires à l’hébergement WordPress. |
| Couche de calcul | Lambda d’API Forms, Lambda Workflow Dispatcher, Lambda Email Sender, Lambda Webhook Dispatcher et Lambda Custom Resource de déploiement | Sépare traitement synchrone, workflows asynchrones, envoi d’e-mails et webhooks sortants. |
| Couche d’état | Tables DynamoDB pour envois, événements, modèles, définitions de workflows et formulaires, endpoints webhook et cartes de processus | Stocke définitions, enregistrements et état dans des tables dédiées avec TTL/rétention plutôt que dans la base WordPress. |
| Couche des charges utiles | Bucket S3 de charges utiles et bucket de modèles, avec buckets existants facultatifs | Transfère fichiers volumineux et ressources réutilisables d’e-mails ou de modèles vers le stockage objet. |
| Couche événementielle | Règles EventBridge et événements : envoi créé/mis à jour, état/action, agent IA terminé/échoué | Transforme le travail des formulaires en événements observables capables de déclencher des workflows sans bloquer le visiteur. |
| Couche de sécurité | Autoriseur Cognito pour routes admin, modes IAM/NONE facultatifs, WAF, reCAPTCHA, listes IP, SSM/KMS | Applique des protections distinctes aux envois publics et aux API de gestion privilégiées. |
| Couche d’exploitation | Groupes de logs CloudWatch, file SQS de lettres mortes, rétention configurable, protection GuardDuty facultative | Fournit logs, surface de reprise/échec et analyse facultative des charges utiles. |
API frontend et API d’administration
Les deux familles de routes servent des appelants différents et ne doivent pas partager les mêmes hypothèses de confiance. Le tableau rend cette séparation visible avant de configurer comportement ou autorisations.
| Famille de routes | Exemples | Appelant type | Posture de sécurité |
|---|---|---|---|
| Envoi frontend | /frontend/forms/{formId}/submit | Formulaire Flow rendu sur une page publique ou protégée | Peut fonctionner sans authentification, mais le trafic anonyme doit utiliser reCAPTCHA, WAF et limitation de débit. |
| Brouillons frontend | /frontend/forms/{formId}/drafts, /drafts/load, /drafts/delete, /drafts/{submissionId}/submit | Visiteur enregistrant, reprenant ou finalisant un long formulaire | Les identifiants du brouillon et la validation finale sont séparés afin qu’un enregistrement ne déclenche pas les workflows finaux. |
| Préparation de fichier frontend | /frontend/forms/{formId}/upload-url | Composant préparant une pièce jointe volumineuse | Renvoie un contrat d’envoi S3 présigné ; la charge utile ne doit pas traverser WordPress. |
| Formulaires/envois admin | /admin/forms, /admin/forms/{formId}/submissions | WP Admin ou interface de gestion | À protéger avec Cognito/IAM et, facultativement, une liste d’adresses IP autorisées. |
| Modèles/workflows/webhooks admin | /admin/templates, /admin/workflows, /admin/webhook-endpoints | Administrateurs configurant le comportement métier | Ces routes modifient l’exécution et ne doivent jamais être traitées comme des endpoints publics. |
Modèle de données : pourquoi plusieurs tables sont utiles
Le backend sépare définitions, enregistrements courants, historique des événements et configuration des intégrations, car leurs cycles de vie diffèrent. Une ligne générique unique ne suffit pas aux workflows durables.
| Famille de tables | Représentation | Raison de la séparation |
|---|---|---|
| Définitions des formulaires | Structure et versions des formulaires utilisés par le frontend | Un formulaire peut évoluer alors que les anciens envois doivent rester compréhensibles. |
| Envois | État courant, statut brouillon/final et données principales | C’est l’enregistrement opérationnel interrogé par les vues admin et les étapes de workflow. |
| Événements d’envoi | Historique cumulatif : créé, mis à jour, état modifié, action invoquée | Audit et reprises ne doivent pas écraser l’enregistrement courant. |
| Modèles | Métadonnées réutilisables d’e-mails et de modèles | Le contenu des e-mails doit être géré indépendamment des envois. |
| Définitions de workflows | Règles, actions et routage | La logique possède son propre cycle de vie et doit être versionnée et gérée explicitement. |
| Endpoints webhook | Cibles d’intégration sortantes et paramètres de signature | Les systèmes externes sont des dépendances d’exploitation, pas de simples champs. |
| Cartes de processus | Corrélation à l’exécution entre processus, envois et actions | Les workflows complexes exigent un état de corrélation au-delà d’un seul enregistrement. |
Contrôles de sécurité et d’abus
Les routes publiques et les routes administratives privilégiées ne doivent pas partager un modèle de protection. Le tableau situe contrôles antirobots, WAF, identité et stockage des secrets dans Flow.
| Contrôle | Application | Raison |
|---|---|---|
| reCAPTCHA | Endpoints publics des formulaires | Réduit les envois automatisés avant qu’ils ne deviennent enregistrements, e-mails, webhooks ou coûts de modèles/workflows. |
| Limites WAF | Préfixes de routes frontend et admin | Limite différemment les abus sur les routes visiteurs et administrateurs. |
| Autoriseur Cognito admin | Routes /admin/* | Maintient formulaires, envois, modèles, workflows et webhooks derrière une véritable frontière d’identité. |
| Secrets SSM/KMS | Secrets reCAPTCHA et de signature des webhooks | Conserve les secrets partagés hors des réglages WordPress et des sources de modèles. |
| Protection GuardDuty | Bucket de charges utiles si activée | Ajoute une analyse facultative avant que les traitements en aval fassent confiance aux fichiers. |
Paramètres de déploiement qui modifient l’architecture
Ces paramètres ne sont pas cosmétiques. Ils changent authentification, protection contre les abus, propriété du stockage, secrets, domaines et exploitation ; ils doivent être examinés comme décisions d’architecture.
| Domaine | Exemples | Effet architectural |
|---|---|---|
| Modes d’authentification | FrontendApiAuthMode, AdminApiAuthMode, AdminCognitoUserPoolId, scopes | Détermine si les surfaces frontend et admin sont publiques ou protégées par IAM ou Cognito. |
| Protection contre les abus | EnableRecaptcha, mode/clé/seuil reCAPTCHA, EnableWAF, listes IP | Détermine la quantité de trafic anonyme atteignant le backend et les chemins limités ou autorisés. |
| Propriété du stockage | TemplatesBucketName, PayloadBucketName, préfixes | Permet d’utiliser des buckets créés ou des conventions de stockage existantes. |
| Secrets | EnableKmsForSecrets, secret de signature webhook, secret reCAPTCHA | Contrôle le stockage des secrets avec une clé KMS dédiée et des paramètres SSM. |
| Domaine/DNS | ApiCustomDomainName, ARN de certificat, paramètres Route53 | Fait passer l’API d’une URL execute-api à un domaine propre lorsque DNS et certificat sont prêts. |
| Exploitation | Rétention des données/logs, mémoire/délai/niveau de log Lambda | Contrôle coûts, observabilité et marge d’exécution sans modifier les pages WordPress. |
Parcours de mise en œuvre
Modélisez le processus avant de relier les actions
Le même backend peut prendre en charge des formulaires simples et des processus plus structurés si les états de brouillon, d’envoi, de revue et d’action restent explicites.
- Définissez l’enregistrement et son cycle de vie — Décidez ce qui constitue un brouillon, ce qui devient un enregistrement envoyé, quels états de revue existent et quels champs ou fichiers doivent persister entre les sessions.
- Séparez les opérations des visiteurs et des réviseurs — Maintenez les actions publiques ou authentifiées du frontend sur une surface d’exécution étroite et protégez séparément la gestion administrative des formulaires, envois et workflows.
- Émettez les événements après les changements d’état persistants — Déclenchez les e-mails, webhooks ou autres actions uniquement après l’acceptation de l’enregistrement ou du changement d’état concerné, afin qu’un échec en aval n’efface pas l’envoi initial.
- Testez les nouvelles tentatives et les transmissions — Vérifiez séparément la reprise des brouillons, l’envoi final, les décisions de revue, les modifications des échanges ou évaluations, les notifications en échec et les erreurs des webhooks externes.
Quand la séparation apportée par un backend Flow événementiel est pertinente
Bonne adéquation
Des formulaires qui sont de véritables processus métier
- Les utilisateurs doivent pouvoir enregistrer et reprendre un formulaire long d’une session à l’autre.
- Après la première étape, les envois entrent dans des workflows de revue, validation, échange, évaluation ou changement d’état.
- Le frontend public peut être statique, tandis que l’état et les actions en aval doivent rester actifs et exploitables indépendamment.
Rester plus simple
Un parcours de formulaire classique peut suffire lorsque
- le formulaire est court et le processus se termine par un envoi et une notification simple.
- le site est entièrement dynamique et une extension de formulaires existante couvre déjà le workflow sans difficulté opérationnelle.
- aucun brouillon persistant, état de revue du backend, historique d’événements ni action externe n’est nécessaire.
Guides par problème
Problèmes d’acheteurs couverts par cette architecture
Comment remplacer les validations par e-mail et tableur par un workflow WordPress ?
Commencez par Remplacez les validations par e-mail et tableur par un workflow WordPress. Ce guide pose le problème opérationnel ; cette architecture explique où résident les enregistrements, l’état de revue et les actions.
Comment enregistrer un long formulaire WordPress et le reprendre plus tard ?
Consultez Permettez aux utilisateurs d’enregistrer un long formulaire WordPress et de le reprendre plus tard. L’état persistant du brouillon doit se trouver derrière l’exécution du navigateur, pas dans une seule requête PHP.
Comment combiner formulaires, échanges et évaluations dans un même workflow de revue ?
Consultez Créez un workflow de révision WordPress avec formulaires, échanges et évaluations pour le cas de revue, et Ajoutez des échanges, réponses et évaluations à un frontend WordPress statique lorsque la collaboration doit rester active après la publication statique.
Cela fonctionne-t-il avec un WordPress publié statiquement ?
Oui. La page peut être servie depuis un hébergement statique tandis que Flow appelle le backend configuré depuis le navigateur. Rendez WordPress statique sans perdre les fonctions dynamiques présente le modèle plus large associant page statique et exécution dynamique.
Commencez par le problème du workflow
Sortez le processus des boîtes de réception avant d’ajouter davantage d’automatisation
Choisissez d’abord le problème de l’acheteur — validation, enregistrement et reprise ou revue structurée — puis utilisez cette architecture pour définir les frontières de persistance, d’autorisation et d’événements.