Une plateforme multi-stack pour une entreprise américaine d'esthétique et de traitements — un ERP Odoo 18, un site Next.js sur AWS, des Lambdas pour le suivi des expéditions UPS et la vérification de liens, des services GCP Cloud Run pour des pipelines de vérification OpenAI. Nous tenons les coutures : l'estate Terraform AWS, les intégrations serverless, et le QA load testing.
Procell Therapies est une entreprise américaine d'esthétique et de traitements cosmétiques. La plateforme derrière l'entreprise est une constellation — un ERP Odoo 18 avec plus de cent dix modules personnalisés (ventes, treatment packs, workshops, academy) ; un site Next.js qui sert aussi de front e-commerce ; des AWS Lambdas pour le suivi des expéditions UPS et la vérification de liens entrants ; des services Google Cloud Run pour la vérification OpenAI des tentatives de contact et des stake claims. Plusieurs équipes contribuent. Nous en tenons des pièces précises.
Sur AWS, nous tenons l'estate Terraform — ECS / Fargate pour le site avec déploiements blue / green via CodeDeploy, RDS Postgres par environnement, ALB avec redirection HTTP→HTTPS, CloudFront pour les assets statiques, bastion pour l'accès DB, EventBridge → Lambda → Slack à chaque succès ou échec de déploiement. Côté serverless, nous maintenons quatre services GCP Cloud Run (deux pipelines de vérification OpenAI, un batcheur de webhooks SendGrid, un proxy de webhooks Zoom) et quatre AWS Lambdas (UPS tracking, UPS webhook relay, link-checker, et le notifier de déploiement du site).
Sur le site Next.js spécifiquement, nous tenons un siège plus étroit : Hasina mène le QA et la batterie de load testing, exerçant les chemins e-commerce avant les moments à fort trafic. Dan est l'ingénieur DevOps derrière ces déploiements — infrastructure gérée par Terraform, CodePipeline (Source → CodeBuild → CodeDeployToECS), et les notifications Slack qui disent à l'équipe quand un déploiement atterrit.
La plateforme de Procell n'allait jamais tenir sur une seule stack. L'ERP vit dans Odoo parce que c'est là que la forme métier — treatment packs, workshops, academy — vivait déjà. Le site vit dans Next.js parce que c'est ce que son équipe écrit bien. Les pipelines de vérification OpenAI vivent dans Cloud Run parce qu'ils sont event-shaped, pas request-shaped. Notre siège, ce sont les coutures entre les trois.
Estate AWS géré par Terraform : ECS / Fargate pour le site (blue / green via CodeDeploy), RDS Postgres par env, ALB, CloudFront, bastion, multi-environnement depuis un seul module.
Pipeline en deux étapes via l'OpenAI Responses API pour vérifier qu'un contact a réellement eu lieu sur un lead.
Pipeline OpenAI en trois étapes pour vérifier la documentation des stake claims.
Événements SendGrid mis en tampon dans GCS et batchés vers Odoo toutes les 15 min ; événements Zoom proxyfiés vers Odoo via Cloud Tasks.
Puller d'expéditions adossé à DynamoDB (GSI `CodeIndex`), push de statut vers Odoo, conscient des rate limits, tourne uniquement 9 h – 17 h EST et saute les dimanches.
Callbacks transporteur entrants routés vers Odoo.
Vérification de backlinks via navigateur headless — packagé en image Docker pour que le binaire navigateur voyage avec la fonction.
EventBridge → Lambda → Slack à chaque SUCCESS / FAILURE de CodeDeploy, URL du webhook stockée en SSM SecureString.
Le même module Terraform `procell_website/` instancié deux fois — `_production` (branche=main) et `_staging` (branche=staging). Tous les noms de ressources dérivés de `var.branch`.
La batterie pré-lancement de Hasina sur les chemins e-commerce du site Next.js — suites de load et de régression jouées avant que le trafic ne bouge.
Contributions ciblées de modules personnalisés dans l'ERP de 110 modules, aux côtés de l'équipe d'ingénierie côté client.
La plateforme de Procell s'étend sur Odoo 18, un site Next.js, des AWS Lambdas, et des services GCP Cloud Run. Plusieurs équipes contribuent. Nous tenons les coutures : l'infra AWS qui héberge le site, les services GCP qui parlent à Odoo en REST, les Lambdas qui ponteent UPS et Odoo, et la passe QA qui dit qu'on peut déployer.
Le chemin du site vers la production est déclaratif. Source → CodeBuild → CodeDeployToECS, blue / green target groups, EventBridge → Lambda → Slack en cas de succès ou d'échec. Deux environnements, c'est le même module instancié deux fois — production (branche=main) et staging (branche=staging) — noms et bases diffèrent, la forme non.
Les pipelines de vérification OpenAI ne rentrent pas dans la forme request-response. Le contact-made checker est en deux étapes ; le stake-claim checker en trois. Les deux tournent sur Cloud Run, verrouillés par IAM GCP, avec un handler SendGrid qui tamponne les événements vers GCS et un handler Zoom qui proxyfie via Cloud Tasks. Le CI teste chaque étape en isolation avec OpenAI mocké — les runs de tests coûtent zéro token.
Hasina tient le siège QA côté Next.js — elle exerce les chemins e-commerce avant les lancements qui font bouger le trafic. Une batterie de load, une batterie de régression, et une liste d'endroits connus comme tendres qui reçoivent une attention en plus avant chaque release. Le notifier Slack dit à tout le monde quand le feu vert passe.
Les déploiements du site passent par CodePipeline (Source → CodeBuild → CodeDeployToECS) vers des target groups blue / green sur Fargate. EventBridge écoute les événements SUCCESS et FAILURE de CodeDeploy, frappe une petite Lambda (`procell_website/lambda/slack_notify.py`), et Slack porte le résultat. L'URL du webhook vit dans SSM SecureString à `/procell-website/${branch}/slack-webhook-url` — scopée par branche, jamais dans le code.
`procell_website/` est un module réutilisable instancié deux fois depuis la racine — `procell_website_production` (branche=main) et `procell_website_staging` (branche=staging). La variable `branch` pilote chaque nom de ressource : `procell-website-${var.branch}`. Ajouter un environnement, c'est un bloc tf de plus.
La Lambda UPS pull les expéditions actives depuis DynamoDB (requêtées par `Code` via un GSI `CodeIndex`), appelle l'API UPS pour chacune, et pousse les changements de statut vers Odoo en HTTP. L'état du run (`SUCCESS` / `RATE_LIMIT`) vit dans une table `${TABLE}-result` sous un id statique — c'est ce qui gate les re-runs. Le run saute les dimanches et ne tourne qu'entre 9 h et 17 h EST. Le code rate-limit UPS 10429 arrête le run pour quatre heures.
Le contact-made checker, c'est deux appels OpenAI en série — d'abord une extraction structurée, puis une vérification — branchés ensemble sur Cloud Run via l'OpenAI Responses API. Le stake-claim checker est en trois étapes. Les deux déploient depuis `procell_cloud_functions/functions/<name>/`, tournent depuis un env conda partagé `procell_cloud_env`, et embarquent une suite Pytest qui mocke le côté OpenAI — les runs de tests coûtent zéro token.
Donnés `{url, imageUrl, backlinkUrl}`, la Lambda link-checker lance un navigateur headless et vérifie que la page à `url` contient un `<a href=backlinkUrl>` enveloppant un `<img src=imageUrl>` — retourne `{found: true|false}`. Packagée en image Docker pour que le binaire navigateur voyage avec la Lambda. Adossée à une suite Pytest avec fixture de mock-serveur.
Tout l'estate vit sous le profil `procelltherapies` — chaque commande Terraform a besoin de `AWS_PROFILE=procelltherapies` ou échoue ou tape le mauvais compte. L'état vit dans S3 (`terraform-procell-therapies-bucket`) clé `procell-therapies/terrafo.tfstate`. Un bastion `t3.micro` devant RDS garde l'accès DB hors Internet public.