DEV Community: TechTown

Cloud Run instances : héberger un agent IA qui tourne en continu

Nicolas BOURON — Fri, 02 Oct 2026 15:23:48 +0000

Les agents IA ne se contentent plus de répondre à une question. Certains travaillent en fond: un digest de veille au réveil, le programme de la journée en podcast, les alertes de la nuit déjà triées, les issues Dependabot suivies dépôt par dépôt. Puis ils attendent la tâche suivante.

C’est très pratique. Mais au moment de les héberger, une question arrive vite : où faire tourner un programme qui ne s’arrête jamais, sans administrer de serveur ?

Dans cet article, je pars d’un cas concret : un agent open source que j’ai déployé sur Google Cloud. Je présente les trois besoins d’un agent permanent, puis les trois options d’hébergement possibles. J’ai testé la troisième, Cloud Run instances , en Preview depuis fin août 2026.

📌 Les trois besoins d’un agent permanent

A. Tourner en continu. L’agent planifie lui-même ses tâches et se réveille tout seul, sans planificateur externe.

B. Se souvenir. Sa mémoire, son historique et son planning doivent survivre à une mise à jour ou à un redémarrage.

C. Rester simple. Une adresse web qui ne change pas, et aucun serveur à maintenir.

Pris un par un, ces besoins sont bien outillés. Les trois ensemble, c’est le vrai problème.

1️⃣ Option 1 : un service Cloud Run

Première idée : déployer l’agent comme une application web classique. L’adresse, la sécurité et les logs sont fournis, sans rien administrer. Le besoin C est couvert.

Pourquoi ça coince : un service Cloud Run s’éteint quand personne ne l’appelle. C’est son grand intérêt pour un site web, et le défaut rédhibitoire pour un agent : sa boucle de travail et sa mémoire disparaissent avec lui.

2️⃣ Option 2 : une machine virtuelle

Deuxième idée : une VM. Elle tourne en continu et garde tout en mémoire. Les besoins A et B sont couverts.

Pourquoi ça coince : on récupère tout le travail d’administration (mises à jour, pare-feu, supervision, certificats). C’est beaucoup pour un programme qui passe l’essentiel de son temps à attendre.

3️⃣ Option 3 : une instance Cloud Run

Troisième voie : Cloud Run instances , un nouveau type de ressource. Un conteneur unique, toujours allumé, avec une adresse fixe et un espace de stockage qui survit à tout. On le démarre, on l’arrête, on le met à jour, et c’est tout. Le tout pour 5,70 $ par mois dans sa plus petite taille.

J’ai testé cette approche avec Hermes Agent, un agent open source. Il s’appuie sur un modèle Gemma 4 hébergé à côté, sur un service Cloud Run équipé d’un GPU.

⚡️ Voici ce que j’ai constaté pendant le test :

La mémoire tient. Ce que l’agent écrit sur son stockage survit aux mises à jour, aux arrêts et aux redémarrages.
L’adresse ne bouge pas , quoi qu’il arrive.
Tout reste privé. L’agent parle à son modèle sans passer par Internet.
Une instance arrêtée ne coûte rien. Ma première session de tests complète m’a coûté deux centimes.
Le redémarrage hebdomadaire a bien lieu, et l’agent s’en remet seul. Après une semaine pile sans interruption, Google a redémarré l’instance pour maintenance. Elle était de retour en une vingtaine de secondes, et l’agent avait repris son travail une minute et demie plus tard.

Pourquoi le prix est si bas

L’instance ne réserve qu’une petite fraction de processeur en continu, mais elle peut accélérer à pleine puissance pendant quelques minutes quand elle en a besoin. En test, le plein régime tient environ trois minutes et demie, et deux minutes de calme suffisent à le retrouver.

Un agent réfléchit, appelle un outil, attend, reprend. Il travaille par à-coups, et c’est exactement ce profil que ce modèle de prix récompense.

Les limites de l’instance

C’est une Preview. Certaines régions ne la proposent pas encore.
Pas de GPU sur l’instance. Le modèle d’IA se place à côté, sur un service Cloud Run avec GPU. En Europe, une seule région propose aujourd’hui les deux.
Le stockage n’est pas un vrai disque. Il convient très bien à des fichiers écrits d’un coup par un seul programme, moins à une base de données.
Un redémarrage par semaine. L’agent doit savoir reprendre son planning au réveil, d’où l’intérêt de garder son état sur le stockage plutôt qu’en mémoire.
Une mise à jour coupe le service pendant près de deux minutes.

💪 ProTip : gardez la configuration qui change souvent hors du conteneur, dans un gestionnaire de secrets ou un fichier du stockage. Vous n’aurez presque plus de mises à jour, donc presque plus de coupures.

🧪 Bonus : des bacs à sable pour le code généré

Un agent qui écrit du code doit pouvoir l’exécuter sans risquer de casser son propre environnement. L’instance peut lancer ce code dans des bacs à sable isolés, en quelques dixièmes de seconde. Par défaut, ils n’ont accès ni à Internet, ni aux identifiants de l’agent, ni à sa mémoire : une ligne de code hallucinée ne peut rien abîmer.

⚖️ Comparatif des trois options

	1. Service Cloud Run	2. Machine virtuelle	3. Instance Cloud Run
Tourne en continu (A)	non	oui	oui
Garde sa mémoire (B)	non	oui	oui
Adresse web fournie (C)	oui	à construire	oui, et fixe
Serveur à maintenir (C)	non	oui	non
Coût	nul quand rien n’arrive	non mesuré	5,70 $ par mois allumée, 0 arrêtée

🎯 Conclusion : le serverless apprend à garder son état

Pendant des années, il fallait choisir entre la simplicité du serverless et un serveur qui ne s’éteint jamais. L’instance Cloud Run est la seule des trois options qui couvre A, B et C à la fois : je pousse un conteneur, il tourne, il se souvient, et il coûte le prix d’un abonnement de streaming.

Elle ne remplace pas tout : un traitement massif en parallèle, une API publique très sollicitée ou un modèle d’IA à servir ont chacun leur propre brique Cloud Run. Mais pour un agent qui travaille en fond, c’est exactement la brique qui manquait.

C’est encore une Preview : pas de production dessus demain. Pour mes propres agents, en revanche, je continue à tester et explorer de nouveaux cas d’usage.

Et surprise, prochainement, un nouveau service Cloud Run qui va plaire à beaucoup de monde ! 🤫😁

📚 Références

🎓 Aller plus loin avec les agents IA

Vous voulez construire votre propre agent ? En une journée, la formation Développer son propre agent de TechTown couvre :

les cas d’usage ;
l’architecture d’un agent ;
trois ateliers pratiques, dont la construction d’un agent IA avec un serveur MCP sur Cloud Run.

Agents CLI : l'outil de Google pour piloter vos agents IA de bout en bout

Benjamin Bourgeois — Mon, 04 May 2026 07:08:32 +0000

Construire un agent IA est devenu accessible avec des frameworks agentiques comme Agent Development Kit (ADK) de Google. En revanche, tout ce qui l'entoure (l'évaluation, l'infrastructure, le déploiement, la publication) reste encore un processus artisanal, pas industrialisé. C'est précisément le problème que Google cherche à résoudre avec Agents CLI.

TL;DR : Agents CLI est un outil officiel Google qui orchestre l'ensemble du cycle de vie d'un agent ADK : création, test, évaluation, déploiement et publication. Il est conçu pour fonctionner aussi bien en terminal qu'en mode agent (Gemini CLI, Claude Code, Cursor).

🤖 Qu'est-ce qu'Agents CLI ?

Agents CLI est l'outillage officiel de Google pour le cycle de développement des agents construits avec Agent Development Kit (ADK). L'idée centrale : vous ne devriez pas avoir à reconstruire l'outillage de zéro à chaque projet. L'outil injecte sept "skills" directement dans votre environnement de développement (ou dans votre assistant IA) pour couvrir chaque étape, du scaffolding initial jusqu'au déploiement en production.

Il fonctionne en deux modes complémentaires :

Human mode : vous tapez les commandes directement dans votre terminal, comme n'importe quel CLI
Agent mode : votre assistant IA (Gemini CLI, Claude Code, Cursor…) exécute les commandes de façon autonome

Ce deuxième mode est le pari le plus intéressant de l'outil. Agents CLI expose des skills structurées pour que les agents puissent comprendre le contexte de votre projet sans se noyer dans la documentation. Moins de context overhead, plus d'autonomie réelle.

💻 Installation et prérequis

Prérequis : Python 3, Node.js et uv (le gestionnaire de packages Python rapide).

# Installer et configurer Agents CLI
uvx google-agents-cli setup

L'authentification se fait automatiquement via vos credentials gcloud. Si vous travaillez sans projet GCP, une variable d'environnement GEMINI_API_KEY suffit pour démarrer en local.

🔄 Le cycle de vie en commandes

Voici le flow complet, de la création à la mise en production :

# 1. Scaffolding du projet
agents-cli create mon-agent --deployment-target agent_runtime

# 2. Installer les dépendances
agents-cli install

# 3. Lancer le playground local (interface web de test)
agents-cli playground

# 4. Évaluer les performances de l'agent
agents-cli eval run

# 5. Comparer deux runs d'évaluation
agents-cli eval compare run1.json run2.json

# 6. Provisionner l'infrastructure GCP (IaC automatisé)
agents-cli infra single-project

# 7. Déployer sur Cloud Run ou Agent Runtime
agents-cli deploy

# 8. Publier dans Gemini Enterprise
agents-cli publish gemini-enterprise

On note la cohérence du flow : chaque commande s'enchaîne naturellement dans la continuité de la précédente, sans jongler entre plusieurs outils ou consoles GCP.

💡 Un exemple concret : agent de support client multi-agents

Pour illustrer ce qu'Agents CLI permet de mettre en production rapidement, voici la structure d'un système multi-agents de support client. Deux agents spécialisés, chacun avec un rôle précis :

from google.adk.agents import LlmAgent
from google.adk.tools import FunctionTool

# Agent de tri : classe l'intention et route vers le bon spécialiste
concierge = LlmAgent(
    name="concierge",
    model="gemini-2.0-flash",
    instruction="Analyse la demande entrante et route vers l'agent approprié.",
    tools=[FunctionTool(route_to_specialist)],
)

# Agent logistique : gère commandes et stocks
logistician = LlmAgent(
    name="logistician",
    model="gemini-2.0-flash",
    instruction="Réponds aux questions sur les commandes, livraisons et inventaires.",
    tools=[FunctionTool(get_order_status), FunctionTool(check_inventory)],
)

Agents CLI prend ensuite en charge la containerisation, le push vers Artifact Registry et la configuration IAM. Vous restez concentré sur la logique métier.

🤔 Les avantages et les améliorations d'Agents CLI

Les points forts :

Un seul outil pour tout le cycle de vie, fini les scripts de déploiement maison
Playground intégré : une interface web locale pour tester sans infrastructure
Évaluation native : eval run et eval compare donnent une vraie mesure de la qualité
Pensé pour les agents : les skills réduisent le context overhead de Gemini CLI, Claude Code, etc.
IaC automatisé : l'infra GCP se provisionne sans toucher à Terraform ou à la console

Les limites à connaître :

Pas de support Windows natif : WSL 2 obligatoire
Couplé à GCP : déploiement impossible sans projet Google Cloud avec facturation activée
Encore en preview : l'API des commandes peut évoluer, à éviter sur des projets critiques en prod
Abstraction opaque : si infra ou deploy plante, le debugging peut être difficile sans connaître les couches sous-jacentes (Cloud Run, IAM, Artifact Registry)

🤝 À retenir

Agents CLI répond à un vrai manque : un cycle de développement unifié pour les agents ADK, de la création au déploiement sur Google Cloud. Pour les équipes qui gèrent plusieurs agents, c'est une standardisation bienvenue. Pour les profils solo, c'est surtout du temps récupéré sur tout ce qui n'est pas de la logique métier.

L'outil étant encore en preview, c'est le bon moment pour l'expérimenter sur un projet non-critique et se positionner avant que ça devienne le standard de facto sur GCP. Si vous avez déjà des agents ADK qui tournent, la migration vers ce workflow devrait être naturelle.

🤖 Comment structurer la mémoire de vos agents avec Google ADK

Benjamin Bourgeois — Fri, 03 Apr 2026 13:09:58 +0000

Le plus gros défi avec les LLMs, c'est qu'ils sont fondamentalement « stateless ». Sans une couche de gestion de session et de mémoire, chaque requête est une page blanche. Pour un développeur, la difficulté est de savoir quoi stocker, où le stocker et combien de temps le garder.

Pour transformer un simple chatbot en un agent intelligent, il faut mettre en place une architecture de contexte. Agent Development Kit (ADK) de Google répond à ce besoin en structurant la persistance autour de trois piliers : la Session, le State et la Memory.

En maîtrisant ces concepts, vous permettez à votre agent d'apprendre de ses interactions et de devenir plus pertinent au fil du temps, tout en gérant intelligemment la fenêtre de contexte limitée des modèles.

🏗️ Architecture du contexte dans ADK

🚦 Session, State et Memory

Il est crucial de différencier ces trois piliers pour ne pas surcharger la mémoire de travail de l'agent :

« Session » : Le conteneur de la discussion actuelle (le « thread »). Elle contient la liste chronologique des événements.
« State » : Le « bloc-notes » temporaire. On y stocke des données de travail (ex: un panier d'achat) qui disparaissent ou s'archivent à la fin de la discussion.
« Memory » : La bibliothèque d'archives inter-sessions. Elle est consultable via une recherche sémantique pour ramener du contexte passé dans le présent.

🧠 Mémoire court-terme vs long-terme

Pour concevoir un agent performant, il faut séparer les flux comme le fait le cerveau humain :

Short-Term Memory (Sessions & State) : Mémoire de travail active uniquement durant la conversation en cours . Elle sert à suivre la progression ou stocker des calculs intermédiaires. Une fois la session fermée, cette mémoire disparaît (ou est envoyée vers l'archivage).
Long-Term Memory (Memory Bank) : Elle ne contient pas le texte brut, mais des faits consolidés (ex: « L'utilisateur préfère Python »). L'agent consulte cette archive au début de chaque nouvelle session pour ne pas repartir de zéro.

🔄 SessionService : Garantir la continuité

L'objet Session est le composant fondamental du suivi. Sans lui, chaque interaction repartirait de zéro.

Une session se définit par plusieurs propriétés clés :

Identification : Elle lie un identifiant unique (id), un nom d'application (app_name) et un identifiant utilisateur (userId).
Historique (events) : Une séquence chronologique de tous les objets Event (messages utilisateur, réponses de l'agent, appels d'outils) survenue dans ce thread.
État (state) : Un dictionnaire de données temporaires servant de « bloc-notes » à l'agent durant l'interaction.
Suivi d'activité (lastUpdateTime) : Un horodatage indiquant la dernière interaction dans la session.

Le choix du service dépend de votre besoin de persistance et de contrôle :

Service	Persistance	Usage recommandé
InMemorySessionService	Nulle	Développement local et tests unitaires.
VertexAiSessionService	Élevée	Production managée sur Google Cloud.
DatabaseSessionService	Élevée	Contrôle total sur votre propre base (PostgreSQL, SQLite).

💡 Le Rewind : Annuler et corriger

Le Rewind permet de faire revenir une session à un état précédent via un invocation_id. Cela restaure le State tel qu'il était avant une erreur de l'agent, permettant de repartir sur une base saine sans perdre tout l'historique.

📝 State : Le bloc-notes dynamique de l'agent

Dans ADK, l'attribut state d'une session est un dictionnaire clé-valeur servant de mémoire de travail. Contrairement à l'historique complet des événements, il stocke des détails structurés nécessaires au tour de conversation actuel (ex: statut d'authentification, étape d'un formulaire).

💡 Gestion de la portée via les préfixes

ADK utilise des préfixes pour définir automatiquement la visibilité et la durée de vie des données:

Préfixe	Portée (Scope)	Persistance	Cas d'usage
Aucun	Session actuelle	Liée au service de session	Étape d'un tunnel d'achat.
user:	Identité utilisateur	Partagée entre toutes ses sessions	Préférences, nom.
app:	Application globale	Partagée entre tous les utilisateurs	Version API, code promo.
temp:	Invocation en cours	Éphémère (effacée après la réponse)	Calculs intermédiaires.

Exemple d'utilisation

# The ADK automatically replaces {user:name} with the value found in state
agent = adk.LlmAgent(
    instruction="Greet the user by saying: Hello {user:name}!"
)

# Updating state within a tool safely
@adk.tool
async def set_preference(color: str, context: adk.ToolContext):
    context.state["user:fav_color"] = color # Captured and persisted automatically
    return f"Preference saved."

🧠 MemoryService : Choisir son moteur de connaissances

Dans ADK, le MemoryService est l'interface qui gère l'archivage et la récupération des connaissances à long terme. Sa mission est double : ingérer les informations pertinentes d'une session terminée (add_session_to_memory) et permettre à l'agent de les retrouver via une recherche (search_memory).

Il existe deux implémentations principales selon vos besoins en persistance et en intelligence :

Caractéristique	InMemoryMemoryService	VertexAiMemoryBankService
Persistance	Nulle (perdue au redémarrage)	Élevée (Managée par Vertex AI)
Extraction	Stocke l'historique brut	Intelligente (extraite et consolidée par LLM)
Type de recherche	Mots-clés basiques	Sémantique avancée (Embeddings)
Usage idéal	Prototypage et tests rapides	Production et apprentissage continu

🚀 Le workflow complet

Pour bien comprendre comment ces composants interagissent, voici le cycle de vie d'une information, de sa captation à sa réutilisation:

Interaction : L'utilisateur échange avec l'agent via une Session. Chaque message et action est enregistré comme un Event, et le State gère les données de travail immédiates.
Archivage : Lorsqu'une session est jugée riche en informations, l'application appelle add_session_to_memory(session). Le système extrait les faits marquants de l'historique et les consolide dans le MemoryService.
Mémoire : Dans une session future, l'agent utilise un outil dédié (LoadMemoryTool ou PreloadMemoryTool) s'il détecte un besoin de contexte passé.
Recherche Sémantique : L'outil interroge le service de mémoire (search_memory). S'il s'agit de la Memory Bank, une recherche par similarité vectorielle est effectuée pour trouver les souvenirs les plus proches du sens de la requête.
Restitution & Réponse : Le service renvoie les souvenirs pertinents (MemoryResult). L'agent les intègre alors dans ses instructions système pour formuler une réponse personnalisée et historiquement cohérente.

🤖 Vers une IA qui apprend vraiment

En maîtrisant ce trio, Session, State et Memory, vous sortez enfin du mode "stateless" des LLM. Cette architecture, propulsée par ADK et Google Cloud, garantit que vos agents ne se contentent pas de répondre, mais s'adaptent et valorisent chaque interaction sur le long terme.

AWS Summit Paris 2026 : le grand saut dans l'ère de l'IA agentique

Benjamin Bourgeois — Thu, 02 Apr 2026 00:00:00 +0000

Le 1er avril 2026, le Palais des Congrès de Paris accueillait l’édition 2026 de l’AWS Summit. Si les années précédentes étaient marquées par l’expérimentation autour de l’IA générative, cette édition a acté un changement de paradigme : nous quittons l’ère du simple « chat » pour entrer dans celle des agents autonomes et industrialisés.

Une keynote sous le signe de la puissance et du « Why Not »

La matinée a débuté avec Amélie Clugnet, qui a rappelé l’ancrage massif d’AWS en France, fort de 1 000 salariés et d’une disponibilité exemplaire de sa région cloud. Ensuite, la keynote a donné une impulsion claire à travers le concept du « Why Not ». L’idée centrale que je retiens est la mutation profonde de notre rôle : il ne s’agit plus seulement d’assister le développeur dans ses tâches quotidiennes, mais de lui fournir les leviers pour piloter de véritables flottes d’agents. Ces derniers sont désormais capables de transformer des « insights » théoriques en actions concrètes au sein de l’infrastructure.

Le témoignage du Groupe Canal+ a parfaitement illustré cette ambition. Pour supporter son expansion internationale, le groupe a structuré une plateforme capable d’orchestrer plusieurs modèles via Amazon Bedrock. Cette architecture « agnostique » leur permet aujourd’hui d’absorber des pics de charge colossaux, allant jusqu’à 3 millions d’utilisateurs simultanés lors de grands événements sportifs, tout en personnalisant l’expérience à l’échelle mondiale.

La montée en puissance de l’écosystème agentique

En parcourant l’Innovation Corner, l’omniprésence d’AgentCore a confirmé que la gestion de la mémoire à long terme et l’auditabilité des décisions des agents sont devenues les nouvelles priorités. C’est une brique qui s’impose désormais comme un standard pour déployer des agents en production avec un haut niveau de confiance.

Parallèlement, les annonces autour de Strands Agents, le nouveau SDK open source d’AWS, simplifient nettement le développement. Ce framework s’appuie sur les capacités de raisonnement natives des modèles de dernière génération pour planifier et exécuter des tâches dynamiquement, évitant ainsi aux développeurs de s’enfermer dans des workflows manuels trop rigides.

Kiro : replacer le développeur au centre de l’architecture

Le moment fort de notre présence au Summit a été notre conférence dédiée à Kiro, que j’ai présentée avec Julien Landuré dans la Developer Community Zone. Julien raconte la session en détail dans son article.

Officiellement adopté comme l’IDE standard d’AWS, cet outil impose une structure inédite au développement « IA-native » via le Spec-Driven Development (SDD). En s’appuyant sur la syntaxe EARS, cette méthodologie garantit que le développeur ne subit plus la génération de code, mais la dirige. En incluant toutes les parties prenantes dès le design, on réduit drastiquement les coûts tout en gardant une maîtrise totale sur l’architecture.

Au-delà de la conception, Kiro outille l’agent de bout en bout pour le rendre opérationnel jusqu’au déploiement grâce aux « powers », des capacités d’action réelles sur les services externes. Mais la véritable rupture réside dans la transition du « Prompt » au « Context Engineering ».

Là où le « prompt engineering » classique s’essouffle face à la complexité des projets, Kiro apporte une réponse systémique via le « steering ». L’écosystème technique est segmenté en fichiers spécialisés (produit, structure, technique) et un « matching » intelligent ne charge que les données critiques pour la tâche en cours. L’agent ne devine plus : il intègre nativement vos standards et l’historique du projet pour une exécution focalisée et de haute précision.

Ce que nous en retirons pour la suite : l’évolution vers l’orchestrateur

L’enseignement principal de ce Summit est la transformation radicale de notre métier. Nous sortons de l’ère de l’artisanat du code pour entrer dans celle de l’orchestration. Le développeur de 2026 ne produit plus chaque ligne manuellement ; il gère des capacités, valide des trajectoires et garantit la cohérence des systèmes.

Dans ce nouveau paradigme, la barrière entre la technique pure et les besoins métiers s’efface au profit d’une compréhension globale du contexte. Il est plus crucial que jamais de bien s’équiper (soi et son IA) pour maintenir des standards de qualité élevés tout en codant à la vitesse de sa pensée. Avec des socles comme l’AWS European Sovereign Cloud et des outils comme Kiro, nous disposons enfin des moyens pour piloter cette complexité avec sérénité.

🚀 Le tips Kiro : Pour ceux qui veulent passer à la pratique, connectez-vous dès maintenant avec votre AWS Builder ID sur Kiro pour bénéficier de 500 crédits bonus et tester vos premières boucles de développement agentique.