concevoir un cms multi-domaines sans serveur piloté par l'ia sur google cloud

le conflit fondamental auquel j'ai été confronté était la nature de la génération de contenu par rapport à la consommation de contenu. la génération d'articles pilotée par l'ia implique une séquence complexe d'opérations : recherche web en temps réel, rédaction avec des modèles de langage volumineux, création d'images avec des modèles de diffusion et traduction multilingue. tout ce processus est intrinsèquement lié aux e/s et gourmand en cpu, prenant souvent plusieurs minutes. ma conception devait complètement séparer ce 'travail intensif' de l'expérience utilisateur finale. les lecteurs s'attendent à ce que les pages web statiques se chargent en quelques millisecondes, servies à partir d'un emplacement périphérique proche d'eux.

cela m'a amené à implémenter un modèle hybride : génération dynamique pour les auteurs et les éditeurs, et livraison statique, mise en cache en périphérie pour les lecteurs. le pipeline ia est asynchrone et découplé, poussant le contenu finalisé vers une couche de livraison rapide. cela garantit que le travail ia coûteux en calcul n'a jamais d'impact sur la latence côté utilisateur.

mon choix pour la couche de calcul était google cloud run. j'ai trouvé que c'était une plateforme sans serveur puissante et entièrement gérée qui me permettait de déployer des applications conteneurisées qui s'adaptent automatiquement de zéro à des milliers d'instances. cela signifiait que je ne payais que pour le calcul utilisé, ce qui correspondait parfaitement à nos objectifs finops. pour moi, la beauté de cloud run est sa simplicité à déployer des microservices sans gérer l'infrastructure sous-jacente.

le cms lui-même s'exécute sous la forme de plusieurs services cloud run distincts, chacun gérant une partie spécifique du système :

• backend (backend-svc-prod) : un service d'api rest fastapi qui gère les pipelines de contenu principaux, ingère les webhooks et gère l'exécution des tâches asynchrones. c'est là que réside la logique d'orchestration de l'ia.
• frontend (frontend-admin-svc-prod) : une interface administrative basée sur nicegui. cela permet à mon équipe de surveiller, de réviser et de déclencher manuellement la génération de contenu ia, nous donnant un contrôle précis sur le processus éditorial.
• serveur de documentation (mcp-docs-svc-prod) : un serveur de protocole de contexte de modèle (mcp). je l'ai construit pour fournir une récupération de contexte pour le backend, agissant essentiellement comme un service de génération augmentée de récupération (rag) pour nos modèles ia, leur fournissant des informations de marché à jour et pertinentes.

en empaquetant ces composants sous forme de microservices conteneurisés à partir d'une seule image docker, j'ai assuré la cohérence entre les environnements et simplifié considérablement nos flux de travail de déploiement.

le principal défi d'ingénierie que j'ai rencontré était la gestion des délais d'exécution. un pipeline complet de génération d'articles peut facilement dépasser le délai d'attente de requête synchrone typique d'un service web (par exemple, cloud run a un délai d'attente de requête maximum de 900 secondes). pour contourner cela, j'ai implémenté un pipeline asynchrone et événementiel utilisant cloud scheduler et google cloud pub/sub.

ce modèle m'a permis de diviser la charge de travail en un déclencheur rapide et synchrone et une phase de traitement asynchrone et découplée. cloud scheduler agit comme un déclencheur basé sur le temps, envoyant une requête authentifiée à notre backend à des intervalles prédéfinis. le backend initie rapidement le processus de rédaction de contenu, persiste son état, puis publie un message vers une rubrique pub/sub. cela permet à la requête initiale de se terminer rapidement, libérant le frontend ou le planificateur.

pub/sub livre ensuite de manière fiable ce message à une autre instance de notre service backend (configurée comme un abonnement push), qui gère les tâches de longue durée telles que la récupération de la recherche, la génération d'images et la traduction de contenu. cela résout non seulement le problème des délais d'attente, mais fournit également un moyen résilient et évolutif de traiter nos tâches de génération de contenu.

pour la livraison de contenu public, le html, le css et les images statiques générés par le pipeline ia sont écrits directement dans les buckets google cloud storage (gcs). j'ai configuré un global external application load balancer pour acheminer le trafic public (/*) directement vers ce backend gcs. de manière cruciale, cloud cdn met ce contenu en cache globalement, garantissant une latence de l'ordre de la milliseconde pour les utilisateurs finaux, quelle que soit leur position géographique. cette conception découple complètement le traitement ia dynamique de la livraison de contenu, répondant efficacement à notre exigence de faible latence.

pour l'accès administratif au cms, j'ai implémenté un modèle zéro confiance à l'aide d'identity-aware proxy (iap). les points de terminaison administratifs (par exemple, admin.thecloudarchitect.io) partagent le même équilibreur de charge mais acheminent le trafic vers les groupes de points de terminaison réseau (neg) sans serveur cloud run. avant qu'une requête n'atteigne le service cloud run, iap l'intercepte, appliquant l'authentification du compte google et des stratégies iam granulaires. cela fournit un périmètre de sécurité robuste, réduisant considérablement la surface d'attaque. pour protéger les informations d'identification sensibles, telles que les clés api pour gemini ou tavily, je les stocke en toute sécurité dans secret manager et les injecte dans les services cloud run au moment de l'exécution, renforçant ainsi notre posture de sécurité.

aperçu architectural

j'ai construit le cms pour traiter l'ia non pas simplement comme un simple appel d'api, mais comme un flux de travail multi-étapes sophistiqué, le tout orchestré au sein du service cloudrunbackend. cela m'a permis de décomposer la génération d'articles complexes en étapes gérables et observables :

1. ingestion et ancrage des données : tout d'abord, j'injecte des données de marché pertinentes (par exemple, les plus fortes hausses/baisses, les données ochlv) dans la fenêtre contextuelle de l'invite. ces données proviennent généralement de notre api ta interne ou d'un service de données de marché dédié, fournissant des informations en temps réel et précises avec lesquelles l'ia peut travailler.
2. recherche (tavily) : selon le type d'article, j'ai configuré le système pour effectuer 1 à 10 appels api tavily. pour un « focus sectoriel » par exemple, cela permet de récupérer des catalyseurs en temps réel, des nouvelles du jour au lendemain ou des annonces d'entreprise spécifiques, garantissant que les modèles ia disposent des informations externes les plus récentes.
3. rédacteur (gemini 2.5 flash) : j'utilise un modèle d'invite initial (généralement basé sur jinja2) pour diriger gemini 2.5 flash afin de rédiger la charge utile json brute de l'article. gemini 2.5 flash offre un excellent équilibre entre performances et rentabilité, ce qui le rend idéal pour générer des brouillons initiaux rapidement et à moindre coût.
4. éditeur (gemini 2.5 pro) : une fois le brouillon terminé, un modèle plus puissant et plus performant, gemini 2.5 pro, le révise. cette étape critique vérifie le ton, l'exactitude, la cohérence factuelle et le formatage approprié. cette approche multi-modèles me permet de tirer parti des forces spécifiques de chaque modèle tout en optimisant les coûts globaux.
5. visuels (imagen 3) : pendant le processus de rédaction, gemini 2.5 flash génère également des invites distinctes et descriptives pour les éléments visuels — généralement une image d'en-tête 16:9 et une image de support 1:1. ces invites sont ensuite transmises à imagen 3, le modèle de diffusion texte-image avancé de google, pour générer des visuels de haute qualité pour l'article.
6. traduction : enfin, le texte anglais est repassé à gemini (flash ou pro, selon le compromis qualité-coût requis pour la traduction) pour la localisation dans des langues cibles telles que l'allemand (de), l'espagnol (es), le français (fr), l'italien (it) et le néerlandais (nl). ces versions traduites font également partie du contenu statique livré via cloud cdn.

l'exécution de grands modèles linguistiques et d'infrastructures cloud mondiales peut rapidement devenir prohibitive si elle n'est pas gérée avec soin. mon architecture utilise des contrôles finops stricts pour maintenir l'efficacité, garantissant que nous obtenons une valeur maximale pour nos dépenses.

6.1. l'économie unitaire d'un article ia

en sélectionnant soigneusement les modèles et en optimisant les appels api, j'ai réussi à maintenir le coût par article exceptionnellement bas. l'utilisation de gemini 2.5 flash pour la rédaction à grand volume et l'ingénierie rapide, et la réservation de gemini 2.5 pro uniquement pour la passe éditoriale critique, a un impact significatif sur le coût total. voici une ventilation basée sur les prix actuels (environ 1 $ ≈ 0,92 €) :

• tavily (recherche) : généralement ~0,02 € – 0,07 € (~0,02 $ – 0,08 $) par article, selon le nombre de recherches.
• gemini (rédacteur/éditeur/invites/traductions) : environ ~0,05 € (~0,055 $) pour toutes les interactions gemini.
• imagen (2 images) : la génération de deux images haute résolution coûte ~0,05 € – 0,07 € (~0,06 $ – 0,08 $).
• coût total par article entièrement publié et multilingue : ~0,13 € – 0,15 € (~0,14 $ – 0,16 $).

cela démontre la puissance d'un pipeline ia finement réglé pour atteindre une efficacité économique remarquable.

6.2. mise à l'échelle à zéro et atténuation du démarrage à froid

la capacité de cloud run à se mettre à l'échelle à zéro instance lorsqu'il est inactif est une énorme victoire finops, réduisant considérablement les coûts de calcul en dehors des périodes de pointe. cependant, cela introduit le potentiel de démarrages à froid (généralement 5 à 15 secondes de latence) pour les services destinés aux utilisateurs, en particulier notre interface d'administration ou les déclencheurs d'api intraday. pour atténuer cela sans encourir de coûts continus liés à des instances toujours actives, j'ai déployé une tâche « keep-warm » dédiée de cloud scheduler.

cette tâche interroge à la fois le backend (/health?deep=true) et le frontend (/health) toutes les 14 minutes, strictement pendant les heures de bureau européennes (06:00 – 22:00 cet). cela garantit que pendant nos heures d'ouverture, les services critiques sont chauds et réactifs, tout en leur permettant de se mettre à l'échelle à zéro pendant la nuit et les week-ends, maximisant ainsi les économies de coûts.