Google Cloud Run : Déployer en 11 Étapes [2026]

Déployer un conteneur sur Google Cloud Run n’a jamais été aussi rapide, mais la plateforme a beaucoup changé en 2026. Nouvelle version du CLI, tarification revue à la baisse, GPU disponibles en Europe, mode CPU toujours allouée : les tutoriels qui traînent encore sur le web datent souvent d’avant ces changements. Ce guide couvre le déploiement complet d’une application conteneurisée sur Cloud Run, de la création du projet GCP jusqu’au pipeline CI/CD, avec les chiffres et commandes à jour au 21 août 2026.

Le mot-clé “google cloud run” affiche un volume de recherche solide en France, porté par la migration progressive d’équipes qui quittaient App Engine ou qui cherchaient une alternative moins verbeuse à Kubernetes pour des charges HTTP. Ce tutoriel vise justement ce public : développeurs et équipes DevOps qui veulent un service en production en moins d’une heure, sans sacrifier la sécurité ni la maîtrise des coûts.

Nous allons suivre onze étapes concrètes, de la création du projet jusqu’à l’automatisation complète du déploiement, puis construire un mini-projet fonctionnel que vous pourrez copier tel quel. Chaque commande a été vérifiée avec la version actuelle du CLI, et chaque chiffre de tarification provient de la documentation officielle Google Cloud. Comptez environ 40 à 45 minutes si vous suivez le guide de bout en bout sans interruption.

Pourquoi Cloud Run reste le choix serverless numéro 1 en 2026

Cloud Run occupe une position particulière dans l’offre Google Cloud. Contrairement à Cloud Functions, qui impose une structure de code assez rigide, Cloud Run accepte n’importe quel conteneur capable d’écouter sur un port HTTP. Contrairement à App Engine, il facture au vCPU-seconde et à la requête, pas à l’instance fixe. Et contrairement à Kubernetes, il ne demande aucune gestion de cluster.

2026 a apporté plusieurs changements structurants. En avril, lors de Next ’26, Google a annoncé la disponibilité générale des Worker Pools pour les traitements en arrière-plan longue durée, ainsi que le support des GPU NVIDIA RTX PRO 6000 Blackwell, capables de faire tourner des modèles de plus de 70 milliards de paramètres sans gestion d’infrastructure. La tarification a aussi bougé : le calcul du vCPU-seconde et du GiB-seconde a été revu au premier trimestre, et le mode CPU toujours allouée est désormais une option de configuration standard plutôt qu’une fonctionnalité de niche.

Pour une équipe basée en France ou ailleurs en Europe, la question de la résidence des données compte aussi. Cloud Run tourne aujourd’hui dans treize régions européennes, dont europe-west9 à Paris et europe-west3 à Francfort, ce qui simplifie les arbitrages RGPD par rapport à un déploiement forcé aux États-Unis.

Autre changement notable : le modèle de remise à l’usage (spend-based CUD) a été étendu à Cloud Run mi-2026, ce qui rapproche encore un peu plus son économie de celle d’une VM réservée pour les charges à fort volume constant. On y reviendra en détail plus loin, avec un calcul chiffré face à une petite instance de calcul classique.

Ce guide ne couvre volontairement pas les scénarios les plus exotiques (multi-région active-active, service mesh complet, migration massive depuis un cluster Kubernetes existant). L’objectif est de vous amener d’un projet GCP vide à un service en production, sécurisé et automatisé, avec juste assez d’options avancées pour éviter les pièges classiques des premiers déploiements.

Prérequis : outils, comptes et versions nécessaires

Avant de commencer, réunissez les éléments suivants. Le tutoriel part du principe que vous avez un compte Google Cloud actif avec la facturation activée (un compte avec crédits d’essai suffit pour suivre les étapes).

Google Cloud CLI (gcloud) 580.0.0 ou plus récent, publié le 11 août 2026
Docker Engine 27.x ou Podman équivalent, pour construire l’image en local si besoin
Node.js 22 LTS pour le projet d’exemple (Python 3.13 ou Go 1.23 fonctionnent aussi)
Un compte Google Cloud avec la facturation activée et un projet créé
Git pour le pipeline CI/CD via Cloud Build
Environ 40 à 45 minutes pour suivre l’ensemble des étapes

Vous n’avez pas besoin de connaître Kubernetes pour suivre ce guide. C’est justement l’un des arguments de vente de Cloud Run : il masque toute la complexité d’orchestration derrière une poignée de commandes gcloud.

Un dernier prérequis, plus organisationnel que technique : sachez à l’avance qui, dans votre équipe, détient les droits de propriétaire du projet GCP. Certaines commandes de cet article (liaison de la facturation, création de comptes de service, ajout de règles IAM) exigent des permissions élevées que tous les développeurs n’ont pas par défaut, surtout dans une organisation qui applique déjà une politique de moindre privilège au niveau de la console Google Cloud.

Étape 1 : Créer le projet GCP et activer la facturation

Commencez par créer un projet dédié. Séparer chaque service dans son propre projet (ou au moins par environnement) simplifie la facturation et les permissions IAM par la suite.

gcloud projects create mon-projet-cloud-run --name="Mon Projet Cloud Run"
gcloud config set project mon-projet-cloud-run
gcloud billing projects link mon-projet-cloud-run \
  --billing-account=XXXXXX-XXXXXX-XXXXXX

Remplacez l’identifiant de compte de facturation par le vôtre, récupérable via gcloud billing accounts list. Sans cette liaison, aucune API payante ne pourra être activée, et le déploiement échouera dès l’étape suivante.

Étape 2 : Installer et authentifier gcloud CLI 580.0.0

Si le CLI est déjà installé, vérifiez la version et mettez-la à jour. Les versions antérieures à 570 n’exposent pas certains flags utilisés plus loin, notamment ceux liés au CPU toujours allouée.

gcloud version
gcloud components update
gcloud auth login
gcloud auth application-default login

Exemple de sortie attendue pour la première commande :

Google Cloud SDK 580.0.0
bq 2.1.35
core 2026.08.11
gcloud-crc32c 1.0.0
gsutil 5.35

La documentation officielle du gcloud CLI liste les changements de chaque version. Gardez l’habitude de lancer gcloud components update une fois par mois : Google publie une nouvelle révision presque chaque mois depuis le début de l’année.

Étape 3 : Activer les API et créer un dépôt Artifact Registry

Trois API sont indispensables : Cloud Run, Artifact Registry (pour stocker l’image de conteneur) et Cloud Build (pour la construire côté serveur sans Docker local).

gcloud services enable run.googleapis.com \
  artifactregistry.googleapis.com \
  cloudbuild.googleapis.com

gcloud artifacts repositories create mon-depot \
  --repository-format=docker \
  --location=europe-west9 \
  --description="Images de conteneurs pour Cloud Run"

Le choix de europe-west9 (Paris) n’est pas anodin : c’est l’une des treize régions européennes listées dans la documentation des emplacements Cloud Run, avec un profil carbone faible. Gardez la même région pour Artifact Registry et pour le service Cloud Run afin d’éviter des frais de transfert réseau inter-régions.

D’autres régions européennes courantes incluent europe-west1 (Belgique), europe-west4 (Pays-Bas), europe-west3 (Francfort), europe-west2 (Londres), europe-southwest1 (Madrid) et europe-north1 (Finlande). Le choix dépend surtout de la localisation de vos utilisateurs et, le cas échéant, de contraintes réglementaires sectorielles imposant une région précise plutôt qu’une autre au sein de l’UE.

Étape 4 : Écrire un Dockerfile optimisé pour le cold start

Cloud Run facture le temps de démarrage du conteneur, donc un Dockerfile mal construit coûte de l’argent et de la latence à chaque montée en charge. Trois règles priment : une image de base légère, un utilisateur non-root, et une écoute sur la variable d’environnement PORT plutôt qu’un port codé en dur.

FROM node:22-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev

FROM node:22-alpine
WORKDIR /app
RUN addgroup -S app && adduser -S app -G app
COPY --from=build /app/node_modules ./node_modules
COPY . .
USER app
ENV PORT=8080
EXPOSE 8080
CMD ["node", "server.js"]

Ce build multi-étapes garde l’image finale petite en excluant les outils de compilation. Le serveur applicatif doit rester au premier plan (PID 1) : Cloud Run attend un signal SIGTERM propre pour arrêter l’instance, et un process daemonisé casse ce mécanisme d’arrêt propre.

Étape 5 : Construire l’image avec Cloud Build

Plutôt que de construire l’image en local puis de la pousser à la main, Cloud Build fait le travail côté serveur en une seule commande. C’est aussi la méthode la plus simple à automatiser plus tard dans un pipeline CI/CD.

gcloud builds submit \
  --tag europe-west9-docker.pkg.dev/mon-projet-cloud-run/mon-depot/mon-service:v1

Pour les projets plus complexes, remplacez l’option --tag par un fichier cloudbuild.yaml décrivant plusieurs étapes (tests, scan de vulnérabilités, build, push). C’est la base du pipeline présenté à l’étape 10.

Étape 6 : Premier déploiement avec gcloud run deploy

C’est ici que la magie opère : une seule commande transforme l’image en service HTTPS public, avec certificat TLS géré automatiquement.

gcloud run deploy mon-service \
  --image europe-west9-docker.pkg.dev/mon-projet-cloud-run/mon-depot/mon-service:v1 \
  --region europe-west9 \
  --platform managed \
  --allow-unauthenticated

Sortie attendue :

Deploying container to Cloud Run service [mon-service] in project [mon-projet-cloud-run] region [europe-west9]
✓ Deploying new service... Done.
Service [mon-service] revision [mon-service-00001-abc] has been deployed
and is serving 100 percent of traffic.
Service URL: https://mon-service-xxxxxxxxxx-ew.a.run.app

Notez que --allow-unauthenticated expose le service publiquement. C’est pratique pour un test rapide, mais l’étape 9 explique comment restreindre l’accès via IAM pour un service en production interne.

Étape 7 : Gérer les variables d’environnement et les secrets

Les variables non sensibles passent directement en ligne de commande. Les secrets (clés API, mots de passe de base de données) doivent transiter par Secret Manager, jamais en clair dans une variable d’environnement classique.

gcloud secrets create db-password --data-file=./password.txt

gcloud run services update mon-service \
  --region europe-west9 \
  --set-env-vars ENVIRONMENT=production,LOG_LEVEL=info \
  --set-secrets DB_PASSWORD=db-password:latest

Le secret est monté au runtime et n’apparaît jamais dans les journaux de déploiement ni dans la configuration visible via gcloud run services describe. Supprimez le fichier password.txt local dès que le secret est créé.

Étape 8 : Régler CPU, concurrence et autoscaling

Le comportement par défaut de Cloud Run alloue le CPU uniquement pendant le traitement d’une requête. Pour les workers en arrière-plan, les WebSockets ou les connexions longues, il faut activer le mode CPU toujours allouée.

gcloud run services update mon-service \
  --region europe-west9 \
  --no-cpu-throttling \
  --min-instances=1 \
  --max-instances=100 \
  --concurrency=80

Selon le billet de blog de Google sur le CPU toujours allouée, ce mode facture l’instance pour toute sa durée de vie (pas seulement pendant les requêtes), mais supprime les frais par requête et applique une remise sur le tarif du CPU et de la mémoire. Le tableau suivant résume les limites par défaut à connaître.

Paramètre	Valeur par défaut	Limite maximale
Instances maximum par révision	100	Ajustable par quota régional
Concurrence (CLI/Terraform)	80 × nombre de vCPU	1 000 requêtes/instance
Concurrence (console)	80	1 000 requêtes/instance
Instances minimum	0 (scale-to-zero)	Configurable, ex. 1 ou 2
Facturation	Arrondie à la tranche de 100 ms	N/A

Le passage à zéro instance (scale-to-zero) explique le cold start classique : dès qu’aucune requête n’arrive pendant un moment, Cloud Run termine les instances. La première requête suivante en démarre une nouvelle, ce qui ajoute une latence allant de quelques centaines de millisecondes à plusieurs secondes selon le langage et la taille de l’image. Fixer --min-instances=1 élimine ce délai au prix d’une facturation continue.

Le réglage de la concurrence mérite un arbitrage propre à chaque service. Une valeur haute (500-1000) convient à une API légère qui fait surtout de l’entrée-sortie réseau, comme un appel à une base de données distante, puisque le processus attend la réponse sans consommer beaucoup de CPU. Une valeur basse (1-10) convient mieux à un traitement gourmand en calcul, comme du redimensionnement d’image ou du parsing lourd, où plusieurs requêtes simultanées sur la même instance se marcheraient dessus et dégraderaient le temps de réponse de toutes les requêtes en cours.

Étape 9 : Domaine personnalisé et sécurisation IAM

Pour un service public destiné aux utilisateurs finaux, mappez un domaine personnalisé plutôt que de garder l’URL générée en *.run.app.

gcloud run domain-mappings create \
  --service mon-service \
  --domain app.mondomaine.fr \
  --region europe-west9

Pour un service interne (API appelée par un autre service GCP, jamais par un navigateur public), faites l’inverse : retirez l’accès anonyme et n’autorisez que des comptes de service précis.

gcloud run services remove-iam-policy-binding mon-service \
  --region europe-west9 \
  --member="allUsers" \
  --role="roles/run.invoker"

gcloud run services add-iam-policy-binding mon-service \
  --region europe-west9 \
  --member="serviceAccount:[email protected]" \
  --role="roles/run.invoker"

Créez toujours un compte de service dédié par application plutôt que d’utiliser le compte de calcul par défaut, et n’accordez que les rôles strictement nécessaires (par exemple roles/storage.objectViewer plutôt que roles/editor).

Étape 10 : Automatiser avec un pipeline CI/CD Cloud Build

Une fois le déploiement manuel validé, automatisez-le. Créez un fichier cloudbuild.yaml à la racine du dépôt Git, puis reliez-le à un déclencheur Cloud Build sur chaque push.

steps:
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'europe-west9-docker.pkg.dev/$PROJECT_ID/mon-depot/mon-service:$SHORT_SHA', '.']
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'europe-west9-docker.pkg.dev/$PROJECT_ID/mon-depot/mon-service:$SHORT_SHA']
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: gcloud
    args:
      - run
      - deploy
      - mon-service
      - --image=europe-west9-docker.pkg.dev/$PROJECT_ID/mon-depot/mon-service:$SHORT_SHA
      - --region=europe-west9

gcloud builds triggers create github \
  --repo-name=mon-repo \
  --repo-owner=mon-org \
  --branch-pattern="^main$" \
  --build-config=cloudbuild.yaml

Chaque fusion sur la branche main déclenche désormais un build, un push et un déploiement automatique, avec un tag d’image basé sur le hash de commit pour garder un historique exploitable en cas de rollback.

Revenir en arrière en cas de déploiement défaillant

Chaque déploiement crée une nouvelle révision sans supprimer les précédentes. Si une régression passe le pipeline sans être détectée par les tests, vous pouvez rediriger tout le trafic vers la révision précédente en quelques secondes, sans reconstruire d’image.

gcloud run revisions list --service mon-service --region europe-west9

gcloud run services update-traffic mon-service \
  --region europe-west9 \
  --to-revisions mon-service-00003-xyz=100

Cette bascule de trafic sert aussi pour des déploiements progressifs : envoyer 10 % du trafic vers une nouvelle révision, surveiller les métriques d’erreur pendant quelques minutes, puis monter à 100 % seulement si rien d’anormal n’apparaît dans Cloud Logging.

gcloud run services update-traffic mon-service \
  --region europe-west9 \
  --to-revisions mon-service-00004-def=10,mon-service-00003-xyz=90

Cette approche de déploiement canari coûte une commande de plus que le tout-ou-rien, mais elle évite qu’une régression touche 100 % des utilisateurs avant qu’un humain n’ait eu le temps de regarder un tableau de bord.

Étape 11 : Surveiller et déboguer avec Cloud Logging

Cloud Run redirige automatiquement la sortie standard et d’erreur du conteneur vers Cloud Logging, sans configuration supplémentaire. Pour suivre les déploiements en direct :

gcloud run services logs read mon-service \
  --region europe-west9 \
  --limit=50

Ajoutez un point de terminaison léger de type /healthz qui vérifie les dépendances critiques (base de données, cache) et répond en moins de 200 ms. Cloud Run ne propose pas de sondes façon Kubernetes, mais considère une instance saine tant qu’elle répond aux requêtes HTTP. Un endpoint de santé rapide limite les faux positifs lors des pics de charge.

Pour une observabilité plus fine que les journaux bruts, instrumentez le service avec OpenTelemetry : les traces de requêtes exportées vers Cloud Trace permettent de repérer précisément quel appel externe (base de données, API tierce) ralentit une requête donnée, plutôt que de deviner à partir de la seule latence globale mesurée côté client.

Projet complet : une API de sondage Node.js déployée de bout en bout

Pour valider l’ensemble des étapes précédentes, voici un mini-projet fonctionnel : une API Express qui expose un endpoint de santé et un endpoint de sondage stocké en mémoire.

// server.js
const express = require('express');
const app = express();
app.use(express.json());

let votes = { oui: 0, non: 0 };

app.get('/healthz', (req, res) => res.status(200).send('ok'));

app.get('/sondage', (req, res) => res.json(votes));

app.post('/sondage', (req, res) => {
  const { choix } = req.body;
  if (choix !== 'oui' && choix !== 'non') {
    return res.status(400).json({ erreur: 'choix invalide' });
  }
  votes[choix]++;
  res.json(votes);
});

const port = process.env.PORT || 8080;
app.listen(port, () => console.log(`Service actif sur le port ${port}`));

Avec le package.json minimal (dépendance unique : express) et le Dockerfile de l’étape 4, ce projet se déploie avec les mêmes trois commandes vues plus haut :

gcloud builds submit --tag europe-west9-docker.pkg.dev/mon-projet-cloud-run/mon-depot/sondage:v1
gcloud run deploy sondage \
  --image europe-west9-docker.pkg.dev/mon-projet-cloud-run/mon-depot/sondage:v1 \
  --region europe-west9 --allow-unauthenticated
curl -X POST https://sondage-xxxxxxxxxx-ew.a.run.app/sondage -d '{"choix":"oui"}' -H "Content-Type: application/json"

La dernière commande doit renvoyer {"oui":1,"non":0}. Si vous obtenez une erreur 403, l’accès non authentifié n’a probablement pas été activé au déploiement, revoyez l’étape 9 dans ce cas.

Tester le service en local avant de déployer

Il est rarement judicieux de valider un changement directement en le poussant sur Cloud Run. Construisez et lancez le conteneur en local avec Docker pour reproduire fidèlement l’environnement d’exécution, variable PORT comprise.

docker build -t sondage-local .
docker run -p 8080:8080 -e PORT=8080 sondage-local
curl http://localhost:8080/healthz

Si le comportement local diffère du comportement une fois déployé, la cause est presque toujours liée à une variable d’environnement absente en local, ou à une dépendance réseau (base de données, API tierce) accessible uniquement depuis le VPC de production. Ce test local reste la meilleure façon de valider rapidement le Dockerfile de l’étape 4 sans consommer de quota de build Cloud Build.

Cloud Run face à Cloud Functions, App Engine et GKE

Le choix entre ces quatre options dépend surtout de la forme de la charge de travail plutôt que d’un jugement de valeur sur la qualité du service.

Service	Unité de déploiement	Scale-to-zero	Cas d’usage typique
Cloud Run	Conteneur (n’importe quel langage)	Oui	API HTTP/gRPC, microservices, jobs
Cloud Functions (2e gén.)	Fonction événementielle	Oui	Petits déclencheurs, webhooks, glue code
App Engine	Application complète (runtime managé)	Partiel	Applications monolithiques historiques
GKE (Kubernetes managé)	Pods sur cluster	Non (nécessite Karpenter/HPA)	Charges complexes multi-services, contrôle fin

Si votre équipe gère déjà des clusters Kubernetes pour d’autres raisons, notre tutoriel Minikube pour tester Kubernetes en local reste pertinent pour prototyper avant de basculer certaines charges vers Cloud Run.

Un point souvent sous-estimé : la portabilité. Un conteneur Cloud Run reste un conteneur OCI standard, exécutable tel quel sur GKE, sur un autre cloud, ou en local. Ce n’est pas le cas d’une fonction Cloud Functions, écrite contre une signature d’invocation propriétaire, ni d’une application App Engine dépendante du runtime managé choisi. Pour une équipe qui veut garder une porte de sortie face au risque de dépendance à un fournisseur unique, Cloud Run offre donc une marge de manœuvre supérieure à coût d’entrée équivalent.

Cloud Run face à une petite VM : le calcul des coûts

La tarification Cloud Run repose sur trois axes : le CPU actif (0,000024 $ par vCPU-seconde), la mémoire (0,0000025 $ par GiB-seconde) et les requêtes au-delà du palier gratuit (0,40 $ par million), selon la page de tarification officielle. Le palier gratuit mensuel inclut environ 180 000 vCPU-secondes, 360 000 GiB-secondes et 2 millions de requêtes.

Scénario	Cloud Run (estimation)	Petite VM 24/7
Trafic irrégulier (pics + creux nocturnes)	Souvent moins cher : facturation au réel	Coût fixe même la nuit sans trafic
10 M requêtes/mois, 1 vCPU / 0,5 GiB, 200 ms	≈ 35-40 $/mois hors palier gratuit	≈ 20-40 $/mois pour une e2-small équivalente
Trafic constant et élevé 24/7	Peut dépasser le coût d’une VM avec remise CUD	Souvent plus économique avec engagement 1-3 ans

La règle empirique : Cloud Run gagne sur les charges à trafic variable, une VM avec remise d’engagement gagne sur les charges constantes à haute utilisation. Pour un projet FinOps plus large incluant plusieurs services AWS et GCP, notre guide FinOps AWS contre le gaspillage cloud détaille la méthodologie de suivi des coûts applicable ici aussi.

Un piège de calcul fréquent consiste à comparer uniquement le tarif horaire affiché d’une VM à la facture Cloud Run sans intégrer le temps d’administration. Une VM demande des correctifs de sécurité réguliers, une surveillance de la charge disque, une gestion des mises à jour du système d’exploitation. Cloud Run retire entièrement cette charge opérationnelle puisque Google gère le système hôte. Pour une petite équipe sans ingénieur infrastructure dédié, ce delta de temps humain pèse souvent plus lourd dans la décision que l’écart de quelques dollars par mois entre les deux options.

Pièges courants à éviter

Écouter sur un port codé en dur. Cloud Run injecte le port via la variable PORT, qui change potentiellement d’une révision à l’autre. Un serveur qui écoute en dur sur le port 3000 alors que Cloud Run attend une réponse sur le port qu’il a assigné rend le service “unhealthy” dès le déploiement, sans message d’erreur explicite dans le code applicatif lui-même.
Oublier le mode CPU toujours allouée pour les workers. Un thread d’arrière-plan sous allocation par défaut se fait throttler dès que la requête HTTP se termine. Les files de messages, les tâches planifiées en mémoire ou les connexions WebSocket qui doivent continuer à tourner entre deux requêtes semblent alors “geler” de façon aléatoire, ce qui est difficile à diagnostiquer sans connaître ce comportement.
Laisser --allow-unauthenticated sur un service interne. C’est l’erreur de sécurité la plus fréquente relevée dans les audits de configuration Cloud Run. Un service pensé pour n’être appelé que par un autre service GCP se retrouve accessible publiquement, souvent sans que personne ne s’en rende compte avant un scan externe ou un incident.
Construire une image trop lourde. Une image de plusieurs gigaoctets ralentit chaque cold start et augmente le temps de build à chaque déploiement. Viser une image de moins de 200 Mo pour les services HTTP classiques, en excluant systématiquement les dépendances de développement et les fichiers de test du build final.
Utiliser le compte de service par défaut en production. Il hérite souvent de permissions trop larges au niveau du projet, à l’opposé du principe de moindre privilège. En cas de compromission du conteneur, un attaquant héritant de ces droits peut accéder à bien plus que ce que le service devrait légitimement toucher.
Ignorer le quota d’instances maximum. Une valeur par défaut de 100 peut suffire en test mais provoquer un throttling brutal en cas de pic viral non anticipé, avec des requêtes mises en attente puis abandonnées côté client plutôt qu’un simple ralentissement progressif.

Dépannage : problèmes fréquents et solutions

Erreur “Container failed to start” : vérifiez que l’application écoute bien sur 0.0.0.0:$PORT et pas uniquement sur localhost. C’est la cause numéro un des échecs de premier déploiement, en particulier avec des frameworks qui écoutent par défaut sur 127.0.0.1.
Erreur 403 Forbidden à l’appel : le compte appelant n’a pas le rôle roles/run.invoker. Ajoutez-le via add-iam-policy-binding et vérifiez aussi que le jeton d’identité transmis dans l’en-tête Authorization correspond bien au bon compte de service.
Latence anormale sur la première requête : cold start classique après scale-to-zero. Fixez --min-instances=1 si la latence est inacceptable pour l’usage, ou optimisez le temps d’initialisation de l’application (connexions à la base de données paresseuses plutôt qu’au démarrage, par exemple).
Throttling de la concurrence / files d’attente : le nombre de requêtes simultanées dépasse la concurrence configurée. Augmentez --concurrency ou --max-instances, ou répartissez la charge sur davantage d’instances avec une concurrence par instance plus basse si le service consomme beaucoup de mémoire par requête.
Erreur “API not enabled” : une des trois API (Cloud Run, Artifact Registry, Cloud Build) n’a pas été activée. Relancez la commande gcloud services enable de l’étape 3, sachant que l’activation peut prendre jusqu’à une minute avant de se propager.
Le secret n’est pas visible dans le conteneur : vérifiez que le secret est bien monté via --set-secrets et non simplement créé dans Secret Manager sans liaison au service. Un secret créé mais jamais référencé dans la configuration du service n’apparaîtra jamais dans l’environnement d’exécution.
Erreur de quota régional lors d’une montée en charge : certaines régions imposent des quotas par défaut sur le nombre d’instances actives ou de vCPU simultanés. Demandez une augmentation de quota dans la console GCP, en général traitée sous 24 à 48 heures pour un compte de facturation vérifié.
Déploiement bloqué sur “Deploying revision” : souvent lié à une image incompatible avec l’architecture attendue, par exemple une image construite en ARM localement sur Apple Silicon sans cross-compilation vers amd64. Reconstruisez avec Cloud Build plutôt qu’en local : la plateforme cible est alors toujours cohérente.

Astuces avancées : GPU, worker pools et CPU toujours allouée

Pour des charges d’inférence IA, Cloud Run propose désormais des GPU NVIDIA L4 et RTX PRO 6000 Blackwell directement attachables aux instances, avec scale-to-zero conservé même pour les charges GPU. D’après la documentation GPU de Cloud Run, les régions europe-west1 (Belgique) et europe-west4 (Pays-Bas) font partie des premières zones européennes à héberger ces instances.

gcloud run services update mon-service-ia \
  --region europe-west4 \
  --gpu=1 \
  --gpu-type=nvidia-l4

Pour les traitements longue durée sans endpoint HTTP (traitement de file de messages, tâches batch), les Worker Pools passés en disponibilité générale en avril 2026 évitent de détourner un service HTTP classique pour un usage qui n’en est pas un. Si votre organisation a aussi besoin d’isoler l’exécution de code non fiable (agents IA générant du code à la volée, par exemple), la fonctionnalité Sandboxes de Cloud Run répond à un besoin différent : consultez notre tutoriel dédié aux Cloud Run Sandboxes pour ce cas précis.

Autre astuce peu documentée : combiner un --min-instances faible (1 ou 2) avec le CPU toujours allouée sur les services critiques, plutôt que d’appliquer l’un ou l’autre isolément. Cela élimine à la fois le cold start et les micro-throttlings sur les traitements asynchrones déclenchés en fin de requête, au prix d’un coût de base fixe qui reste généralement modeste face au bénéfice en fiabilité perçue par les utilisateurs finaux. Pour les équipes qui exposent aussi des workloads via des workers Cloudflare en périphérie de réseau, il est possible de combiner les deux approches : Cloud Run pour la logique métier centrale, edge computing pour la mise en cache et la réduction de latence géographique.

Souveraineté des données et conformité RGPD en Europe

Choisir une région comme europe-west9 (Paris) ou europe-west3 (Francfort) ne suffit pas à garantir à lui seul la conformité RGPD d’un service Cloud Run, mais c’est une étape structurante. Le traitement des données reste soumis à l’emplacement de la région choisie pour le calcul, tandis que certains services annexes (facturation, support, journaux d’audit globaux) peuvent transiter par des infrastructures situées hors de l’Union européenne selon la configuration du projet.

Pour les organisations soumises à des exigences de souveraineté renforcées (secteur public, santé, finance), il faut vérifier au cas par cas quelles API Google Cloud respectent les engagements de résidence des données annoncés par le fournisseur, et documenter cette analyse dans le registre de traitement RGPD. Notre article sur le cloud souverain européen d’AWS détaille les enjeux similaires côté AWS, utiles en miroir pour comparer les engagements des deux fournisseurs.

Sur le plan technique, activez le chiffrement au repos (activé par défaut sur Cloud Run) et forcez le chiffrement en transit en refusant tout trafic HTTP non chiffré au niveau du load balancer si vous placez Cloud Run derrière une passerelle personnalisée. Documentez également la durée de rétention des journaux Cloud Logging : la valeur par défaut peut dépasser ce qu’exige votre politique interne de minimisation des données.

Foire aux questions

Cloud Run est-il gratuit pour démarrer ?
Oui, le palier gratuit mensuel couvre environ 180 000 vCPU-secondes, 360 000 GiB-secondes et 2 millions de requêtes, suffisant pour un prototype ou un petit service à faible trafic. Ce palier se renouvelle chaque mois et ne nécessite aucune carte de crédit supplémentaire une fois le compte de facturation actif.

Faut-il obligatoirement utiliser Docker ?
Non. La commande gcloud run deploy --source peut construire l’image depuis le code source directement via des buildpacks, sans Dockerfile explicite, pour les langages courants comme Node.js, Python ou Go.

Quelle est la différence entre Cloud Run et Cloud Run Sandboxes ?
Cloud Run classique déploie un service HTTP standard. Sandboxes ajoute une couche d’isolation renforcée pensée pour exécuter du code non fiable, par exemple généré par un agent IA en temps réel.

Peut-on utiliser un domaine .fr personnalisé ?
Oui, via gcloud run domain-mappings create, à condition de vérifier la propriété du domaine dans Search Console au préalable.

Cloud Run convient-il à une base de données ?
Non directement : Cloud Run est conçu pour des charges sans état persistant, et chaque instance peut être détruite à tout moment sans préavis. Pour une base de données, utilisez Cloud SQL ou AlloyDB et connectez-vous depuis Cloud Run via le connecteur Cloud SQL Auth Proxy, qui gère l’authentification IAM et le chiffrement de la connexion sans exposer d’adresse IP publique sur la base.

Comment limiter les coûts d’un service peu utilisé ?
Laissez --min-instances=0 pour profiter du scale-to-zero, et surveillez la consommation via le tableau de bord de facturation pour repérer un service oublié qui tourne encore.

Cloud Run gère-t-il le HTTPS automatiquement ?
Oui, chaque service reçoit un certificat TLS géré automatiquement, aussi bien sur l’URL *.run.app que sur un domaine personnalisé mappé.

Peut-on migrer un service Cloud Run d’une région à une autre ?
Pas de migration automatique : il faut redéployer l’image dans la nouvelle région, remapper le domaine si besoin, puis supprimer l’ancien service une fois le trafic basculé.

Google Cloud Run : Déployez en 11 Étapes, 40 Min [2026]