​

Google Vertex AI — Inférence sur votre compte

​

Ce qui s’exécute sur Vertex et ce qui ne s’y exécute pas

​

Combien de fournisseurs cloud vous pouvez utiliser

​

Prérequis

• Un projet Google Cloud avec la facturation activée.
• L’Agent Platform API (Vertex AI API) activée sur ce projet (le service aiplatform.googleapis.com).
• Un compte de service dans votre projet avec le rôle Agent Platform User (roles/aiplatform.user), et l’une de ces deux façons pour SecureAI d’agir en tant que ce compte :
  • Option A — une clé JSON pour ce compte de service.
  • Option B — sans clé (emprunt d’identité) : vous accordez au compte de service SecureAI affiché dans le panneau le rôle Service Account Token Creator (roles/iam.serviceAccountTokenCreator) sur votre compte de service, et aucune clé n’est stockée. Cette option n’est disponible que si votre déploiement SecureAI la propose ; sinon, le panneau l’affiche désactivée avec l’avis Keyless access is not enabled on this deployment.
• L’autorisation Admin sur la section Integrations de SecureAI. Avec l’autorisation de lecture, vous pouvez consulter la configuration mais pas la modifier.

​

Étape 1. Préparer le projet dans Google Cloud

gcloud config set project MY_PROJECT

# 1. Activer l'Agent Platform API (Vertex AI API)
gcloud services enable aiplatform.googleapis.com

# 2. Créer un compte de service dédié à SecureAI
gcloud iam service-accounts create secureai-vertex --display-name="SecureAI Vertex"

# 3. Lui accorder le rôle minimal pour invoquer des modèles
gcloud projects add-iam-policy-binding MY_PROJECT \
  --member="serviceAccount:secureai-vertex@MY_PROJECT.iam.gserviceaccount.com" \
  --role="roles/aiplatform.user"

# 4. Option A uniquement : générer la clé JSON
gcloud iam service-accounts keys create key.json \
  --iam-account=secureai-vertex@MY_PROJECT.iam.gserviceaccount.com

​

Option B : autoriser SecureAI sans clé

1. Dans SecureAI, ouvrez le panneau Vertex AI (voir l’étape 2), choisissez Keyless (impersonation) et saisissez l’adresse e-mail de votre compte de service dans Your service account to impersonate.
2. Le panneau affiche la commande à exécuter, déjà renseignée avec le compte de service SecureAI de votre déploiement. Copiez-la avec Copy et exécutez-la dans Cloud Shell. Elle ressemble à ceci :
   gcloud iam service-accounts add-iam-policy-binding secureai-vertex@MY_PROJECT.iam.gserviceaccount.com \
     --member="serviceAccount:SECUREAI_ACCOUNT" \
     --role="roles/iam.serviceAccountTokenCreator"
   
   Le rôle est accordé sur votre compte de service, et non sur le projet : SecureAI ne peut agir qu’en tant que ce compte, qui lui-même ne détient que roles/aiplatform.user.

​

Modèles ouverts (Llama, DeepSeek, Qwen, gpt-oss)

​

Étape 2. Connecter le projet dans SecureAI

1. Accédez à Admin → Integrations, ouvrez la catégorie AI providers et cliquez sur la carte Google Vertex AI — Inference on your account.
2. Sous Connection, renseignez :

   Champ	Quoi saisir
   Google Cloud project ID	L’ID du projet (par exemple my-project-123), et non son nom d’affichage.
   Vertex AI location	Pour commencer, laissez global : c’est là que se trouvent les modèles par défaut Gemini 3 en preview. Si vous avez besoin de résidence des données, saisissez une région (us-central1, europe-west4…) : SecureAI envoie chaque requête au point de terminaison régional que vous avez choisi, et le lieu où Google la traite dépend des engagements de Google en matière de résidence des données. Avec global, c’est Google qui choisit la région. Les modèles ouverts nécessitent une région.
   Authentication	Option A : laissez Service-account key (JSON) sélectionné et collez le contenu complet de key.json dans Service-account key JSON. Option B : choisissez Keyless (impersonation), saisissez l’adresse e-mail de votre compte de service dans Your service account to impersonate et exécutez la commande affichée par le panneau (voir Option B : autoriser SecureAI sans clé, ci-dessus).

   
3. Cliquez sur Save. Aucun trafic n’est encore routé : l’intégration est enregistrée désactivée pour que vous puissiez d’abord la tester.

​

Étape 3. Choisir ce qui s’exécute sur Vertex

• Only these model families — les familles que vous cochez (Gemini, gpt-oss, DeepSeek, Llama, Qwen) s’exécutent sur votre Vertex ; tous les autres modèles continuent de s’exécuter sur les fournisseurs de SecureAI. C’est la façon la plus prudente de commencer (par défaut : Gemini uniquement).
• Remap everything to Vertex — tous les appels LLM s’exécutent sur votre Vertex. Les modèles sans équivalent sur Vertex sont servis par un modèle par défaut.

​

Étape 4. Tester la connexion

1. Une fois l’intégration enregistrée, sous Connection test, cliquez sur Test connection.
2. SecureAI envoie une requête minimale à chaque modèle par défaut, par le même chemin que le trafic réel (passerelle, politiques et reçus compris), et affiche chaque résultat avec sa latence.
   
3. Si un modèle échoue, le panneau en affiche la raison. Consultez la section Dépannage à la fin de cette page.

​

Ce que l’identité peut faire d’autre

​

Étape 5. Vérifier le routage et l’activer

1. Ouvrez Routing preview → Show which lane serves each model. Pour chaque modèle du catalogue, l’aperçu indique s’il sera servi par votre Vertex (et avec quel modèle Vertex) ou par SecureAI, et lesquels seront masqués aux utilisateurs. L’aperçu simule l’intégration activée, ce qui vous permet d’examiner l’effet avant de l’activer.
2. Lorsque le test réussit, activez Route traffic to Vertex AI et cliquez de nouveau sur Save. Si vous n’enregistrez pas, l’interrupteur ne reste pas activé. Pour l’activer, un projet et un identifiant doivent être configurés. Si votre plan n’autorise pas un fournisseur cloud de plus ou si le routage en chevauche un autre, SecureAI le refuse et en explique la raison (voir Combien de fournisseurs cloud vous pouvez utiliser, ci-dessus).
   
3. La carte passe au vert : Routing to Vertex. Si elle est enregistrée mais désactivée, elle affiche en orange Configured · not routing to Vertex.

​

Étape 6. Vérifier dans le sélecteur de modèles

​

Ce qui est facturé, et à qui

• L’utilisation des LLM est facturée par Google sur votre compte, et non par SecureAI. Vous verrez le montant dans votre facturation Google Cloud, avec vos remises et vos CUD appliqués.
• SecureAI affiche le coût des tours servis sur Vertex sous forme d’estimation au prix catalogue, uniquement à des fins d’analyse. C’est une référence : elle n’inclut pas vos remises, donc le montant réel de Google peut être inférieur.
• Les tours servis sur votre Vertex ne sont pas décomptés du plafond de dépenses du siège de chaque utilisateur, sauf si vous activez Apply each seat’s spend cap to turns served in your account. Le niveau du siège continue de s’appliquer : un utilisateur ne peut utiliser que les modèles de son niveau ou d’un niveau inférieur, même lorsque votre Vertex les sert.
• Un siège Govern BYO ne peut utiliser que les modèles servis sur la propre infrastructure de votre organisation : ceux que sert votre Vertex (ou un autre fournisseur cloud connecté) et les modèles auto-hébergés sur vos serveurs. Tout autre modèle est refusé, et le sélecteur ne lui propose pas Auto.

​

Sécurité et conformité

• Identifiants chiffrés, ou aucun. Avec l’option A, la clé du compte de service est stockée chiffrée (AES-256-GCM) et n’est jamais renvoyée au navigateur, pas même à un administrateur ; l’écran n’affiche que l’adresse e-mail du compte. Avec l’option B, aucune clé n’est stockée : SecureAI demande à Google des jetons de courte durée qui agissent en tant que votre compte de service.
• Le chemin reste protégé. Chaque appel passe par la passerelle SMLTP de SecureAI : DLP, un jeton d’autorisation signé par requête et un reçu signé vérifiable.
• Résidence des données. Avec une région fixée (par exemple europe-west4), SecureAI envoie chaque requête au point de terminaison de cette région et applique les politiques de résidence de votre organisation. Le lieu où Google traite la requête dépend des engagements de Google en matière de résidence des données.
• Échec en mode fermé. Si la configuration ne peut pas être lue ou si le jeton de Google ne peut pas être obtenu, la requête est refusée ; elle n’est pas envoyée à un autre fournisseur, sauf si vous avez autorisé le repli.
• Audit. L’enregistrement, le test ou la déconnexion de l’intégration est consigné dans le journal d’activité, avec le nom des champs modifiés et jamais la clé.
• Moindre privilège visible. Le test de connexion vérifie ce que l’identité de la connexion peut faire d’autre dans le projet et avertit si elle détient des autorisations en dehors de l’IA (voir Ce que l’identité peut faire d’autre, à l’étape 4).
• Autorisations minimales. roles/aiplatform.user suffit pour l’inférence ; l’intégration n’a pas besoin de lire votre IAM ni votre facturation.

​

Déconnecter

• Option A : si vous n’utilisez plus la clé, révoquez-la (Comptes de service → Clés).
• Option B : retirez le rôle roles/iam.serviceAccountTokenCreator que vous avez accordé au compte de service SecureAI sur votre compte de service (Comptes de service → votre compte → Autorisations).

​

Dépannage

​

Limitations actuelles

• Claude et Mistral sur Vertex ne sont pas pris en charge (ils utilisent une API différente).
• Les embeddings, le reclassement, l’OCR, l’assistant d’administration, la génération d’images et la voix en temps réel restent sur les fournisseurs gérés par SecureAI.
• Un seul projet et un seul emplacement Vertex par organisation.
• Le nombre de fournisseurs d’inférence que vous pouvez activer en même temps dépend de votre plan (Scale : 1, Enterprise : jusqu’à 3). Voir Azure AI Foundry — Inference on your account et Amazon Bedrock — Inference on your account.
• Le proxy Claude Code utilise Anthropic directement et ne passe pas par Vertex.

​

Connexes

• Google Cloud — Discovery — inventaire des agents, des modèles, des identités et des coûts du projet.
• Azure AI Foundry — Inference on your account
• Amazon Bedrock — Inference on your account
• Présentation des fournisseurs Cloud AI
• Reçus signés