Vertex AI : passer Gemini en production

Vertex AI, c'est le moment où votre prototype Gemini cesse d'être une démo astucieuse pour devenir un système auquel votre entreprise peut confier de vrais utilisateurs, de vraies données et de vrai argent. Jusqu'ici, vous appeliez Gemini via l'APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → Gemini et Google AI Studio. Ce chemin est parfait pour construire et itérer vite. Mais dès que votre projet exige une sécurité de niveau entreprise, un contrôle régional des données, des pistes d'audit ou une montée en charge prévisible, vous passez à Vertex AI, la plateforme managée de Google Cloud pour livrer de l'IA.

Cette leçon porte sur ce passage : quand migrer, ce qui change vraiment, et comment décider sans se compliquer la vie.

Deux portes vers les mêmes modèles

Vous connaissez déjà l'API Gemini sur ai.google.dev. Elle vous donne une clé d'API, un free tier généreux et la boucle la plus rapide possible entre l'idée et l'appel qui fonctionne. On l'appelle parfois la Gemini Developer API.

Vertex AI est la seconde porte vers les *mêmes* modèles Gemini (Pro, Flash, et les autres), mais enveloppés dans la machinerie Google Cloud : IAM (Identity and Access Management), réseau VPC, endpoints régionaux, logging et gestion des quotas. Même intelligence de modèle, surface opérationnelle très différente.

Voici le modèle mental clé : vous ne changez pas de modèle, vous changez le bâtiment dans lequel le modèle habite. AI Studio est un atelier. Vertex AI est une usine sous réglementation.

La différence de code est plus petite que vous ne le craignez. Même SDK, configuration différente :

from google import genai

# Developer API: just a key
dev = genai.Client(api_key="YOUR_API_KEY")

# Vertex AI: project + region, no key (uses Google Cloud auth)
prod = genai.Client(
    vertexai=True,
    project="my-gcp-project",
    location="us-central1",
)

response = prod.models.generate_content(
    model="gemini-2.5-flash",
    contents="Summarize this support ticket in one sentence.",
)
print(response.text)

Remarquez ce qui a disparu : la clé d'API. Sur Vertex, l'identité vient des credentials Google Cloud (un compte de service ou votre propre login gcloud), pas d'une chaîne de caractères collée dans le code. Ce seul changement est au cœur des raisons qui poussent les entreprises à migrer.

Ce qui change vraiment quand vous migrez

1. Authentification et contrôle d'accès

Sur la Developer API, une clé d'API est un bearer tokentokenUn token est l'unité de base de texte que traitent les modèles de langage : le plus souvent un fragment de mot, un mot entier ou un signe de ponctuation, plutôt qu'un simple caractère.Voir la définition complète → : quiconque la détient peut l'utiliser. C'est acceptable pour un prototype, dangereux en production.

Vertex utilise IAM. Vous accordez à un compte de service (une identité non humaine pour votre application) un rôle précis comme roles/aiplatform.user. L'accès est délimité, révocable et journalisé par identité. Vous pouvez répondre à « qui a appelé Gemini, quand, et depuis où » parce que chaque requête passe par Cloud Audit Logs.

# Grant a service account permission to call Vertex AI models
gcloud projects add-iam-policy-binding my-gcp-project \
  --member="serviceAccount:app@my-gcp-project.iam.gserviceaccount.com" \
  --role="roles/aiplatform.user"

2. Résidence des donnéesRésidence des donnéesL'exigence de stocker et traiter les données physiquement dans un pays ou une région précise, souvent pour des raisons légales ou contractuelles.Voir la définition complète → et contrat de gouvernance

C'est la raison pour laquelle les secteurs régulés (santé, finance, secteur public) ne peuvent souvent pas utiliser la Developer API du tout. Vertex vous permet de fixer le traitement à une région (le location dans le code ci-dessus), pour que les données restent, par exemple, dans l'UE. Il vous donne aussi les conditions de gouvernance des données que réclament la plupart des équipes juridiques : vos prompts et vos sorties ne servent pas à entraîner les modèles de Google, et vous obtenez des engagements contractuels là-dessus. Voir cloud.google.com/vertex-ai pour les détails de gouvernance à jour.

3. Réseau et isolation

Les endpoints Vertex AI peuvent se situer à l'intérieur de votre VPC (Virtual Private Cloud) via Private Service Connect, de sorte que le trafic vers Gemini ne traverse jamais l'internet public. Combiné à VPC Service Controls, vous construisez un périmètre qui empêche les données de fuir même si un credential est compromis.

4. Quotas, montée en charge et provisioned throughput

Le free tier et les limites en pay-as-you-go de la Developer API sont conçus pour construire. Vertex vous donne une vraie gestion des quotas et une option appelée Provisioned Throughput : vous réservez une capacité dédiée pour qu'un pic de trafic ne vous fasse pas rate-limiter au pire moment. Vous échangez un peu de flexibilité contre une performance garantie et prévisible. Pour une application grand public à l'échelle, cette prévisibilité *est* le produit.

5. Grounding et RAGRAGMéthode qui permet à un modèle d'IA de répondre à partir de vos propres documents, en récupérant les passages pertinents avant de générer une réponse.Voir la définition complète → d'entreprise

Vous comprenez déjà le RAG sur le plan conceptuel. Vertex l'opérationnalise. Le grounding avec Google Search est disponible sur les deux portes, mais Vertex ajoute Vertex AI Search et le grounding sur *vos propres* data stores : vous connectez un corpus de documents internes et Gemini répond à partir d'eux avec des citations, en mode managé plutôt qu'en plomberie que vous maintenez. C'est la version production du RAG que vous avez prototypé plus tôt dans ce parcours.

Quand migrer (et quand ne pas le faire)

Ne migrez pas simplement parce que « production » sonne sérieux. La Developer API fait tourner de vraies charges de travail sans problème. Migrez quand l'un de ces points est vrai :

• Une exigence de conformité ou juridique impose la résidence des données, des audit logs ou des conditions contractuelles sur les données.
• Vous avez besoin d'un contrôle d'accès de niveau IAM plutôt que de clés d'API partagées.
• Vous exigez une montée en charge prévisible (provisioned throughput, SLASLAEngagement formel définissant le niveau de service qu'un fournisseur garantit à un client, avec des objectifs mesurables et des conséquences en cas de manquement.Voir la définition complète → formels, garanties de quota).
• Vous êtes déjà sur Google Cloud et voulez une facturation, un monitoring et un réseau unifiés.
• Vous avez besoin de RAG managé ou de MLOps (évaluation de modèles, pipelines de déploiement, monitoring de la dérive qualité).

Restez sur la Developer API quand vous êtes en prototypage, que vous construisez un outil interne à faible enjeu, que vous livrez un side project ou que vous avancez vite et que la charge de gouvernance ne ferait que vous ralentir.

Un exemple de décision concret

Un assureur santé de taille moyenne construit un assistant interne qui répond aux questions des employés sur la politique de gestion des sinistres. L'équipe le prototype dans AI Studio en un après-midi : coller les PDF de la politique, brancher le grounding, livrer un Gem à quelques collègues. Ça marche très bien.

Puis ils décident de le déployer auprès de 4 000 collaborateurs et de le connecter aux données de sinistres en direct. Les questions changent :

• Les données de sinistres contiennent des informations de santé des adhérents. Peuvent-elles quitter l'UE ? Non. → Vertex avec une région UE.
• Qui peut interroger le système, et pouvons-nous le prouver ? → Rôles IAM plus Cloud Audit Logs.
• Que se passe-t-il pendant le pic du lundi matin ? → Provisioned Throughput pour que l'assistant ne soit pas rate-limité pendant la ruée.
• Où vit le corpus de politique ? → Vertex AI Search, managé, avec citations, au lieu d'un vector storevector storeUne vector database stocke les données sous forme de vecteurs numériques à haute dimension (embeddings) et retrouve les éléments par similarité plutôt que par correspondance exacte, ce qui rend possible la recherche sémantique et les applications d'IA.Voir la définition complète → artisanal que quelqu'un doit surveiller.

Aucun de ces besoins n'était visible pendant le prototype. Tous sont non négociables au déploiement. **Voilà le déclencheur de migration : pas le modèle, mais les *obligations* autour du modèle.** Le prototype d'un après-midi et le système de production font tourner le *même* gemini-2.5-flash. Seul le bâtiment a changé.

Comment cela s'articule avec le reste de la stack Gemini

Vertex n'est pas un univers à part. C'est le niveau production sous les outils que vous avez déjà rencontrés :

• Agent Development Kit (ADK) : les agents que vous construisez avec ADK peuvent être développés en local puis déployés sur Vertex AI Agent Engine, un runtime managé qui gère les sessions, la montée en charge et l'état pour vous. Même code d'agent, hébergement de production.
• Gemini Code Assist et le Gemini CLI restent dans votre workflow de développeur quelle que soit la porte par laquelle vous livrez. Ils vous aident à écrire le code de déploiement ; ils ne font pas partie du runtime.
• Apps Script et Gemini dans Workspace sont une couche entièrement différente : ils vivent dans Docs, Gmail et Sheets pour la productivité de l'utilisateur final. Ce n'est pas là que vous hébergez une application à l'échelle. Ne confondez pas « Gemini m'aide à écrire un e-mail » avec « Gemini sert 4 000 employés via un endpoint gouverné ».

Une façon nette de le retenir : AI Studio et la Developer API servent à construire. Workspace et les Gems servent à utiliser. Vertex AI sert à opérer à l'échelle sous contraintes.

La migration est surtout de la configuration, pas une réécriture

Comme le SDK est partagé, porter un prototype fonctionnel est généralement léger. Le vrai travail, c'est le setup Cloud autour, pas la logique IA.

Une configuration minimale de forme production ressemble à ceci :

# app config: same model, production posture
model: gemini-2.5-flash
vertex:
  project: my-gcp-project
  location: europe-west4        # EU data residency
  use_provisioned_throughput: true
grounding:
  datastore: claims-policy-corpus   # Vertex AI Search
  include_citations: true
auth:
  service_account: app@my-gcp-project.iam.gserviceaccount.com

Votre prompt engineeringprompt engineeringLe prompt engineering consiste à concevoir et affiner des instructions textuelles pour guider les grands modèles de langage vers des réponses justes, pertinentes et fiables.Voir la définition complète →, vos définitions d'outils, votre choix de modèle : tout est repris. Ce que vous ajoutez, c'est l'identité, la région, la capacité et la gouvernance. Cette asymétrie est une bonne nouvelle. Le temps passé à rendre votre prototype excellent n'est pas perdu lors de la migration ; l'intelligence se transfère intacte.

Une réserve honnête

Vertex AI ajoute du poids opérationnel : projets Google Cloud, IAM, mise en place de la facturation, décisions réseau. Pour un professionnel moyennement technique, c'est un vrai saut de complexité, et c'est réellement surdimensionné pour beaucoup de projets. L'erreur est de migrer trop tôt « par prudence » et de se noyer dans la configuration cloud avant d'avoir validé que quelqu'un veut le produit. Validez sur la Developer API. Migrez quand une obligation, et non une ambition, vous force la main.

Points clés à retenir

• Mêmes modèles, bâtiment différent. Vertex AI sert les modèles Gemini identiques à ceux de la Developer API ; vous changez la config du SDK (vertexai=True, plus project et location), pas vos prompts ni votre logique.
• Migrez pour des obligations, pas par intuition. Le déclencheur est un besoin concret : résidence des données, contrôle d'accès IAM, audit logs, montée en charge prévisible ou RAG managé. Si rien ne s'applique, restez sur la Developer API et continuez d'avancer vite.
• L'identité remplace la clé d'API. Sur Vertex, l'accès passe par des comptes de service et des rôles IAM, ce qui rend le « qui a fait quoi » auditable et révocable, exactement ce qu'exigent les équipes en environnement régulé.
• La région est une décision de premier plan. Fixez location pour garder le traitement dans une juridiction, et associez-la à VPC Service Controls et Provisioned Throughput pour une vraie posture de production.
• Votre prototype n'est pas jetable. Comme l'intelligence se transfère intacte, investissez d'abord dans la justesse des prompts, du grounding et de la logique d'agent sur l'API simple, puis migrez quand les règles l'exigent.