1. Isolation du réseau : Contourner complètement l'internet public pour le trafic d'inférence est non négociable pour les charges de travail sensibles. Cela prévient les attaques réseau courantes et l'interception de données.
2. Sécurité périmétrique (VPC-SC) : Établir des garde-fous contre l'exfiltration de données et l'accès inter-projets non autorisé. Cela agit comme un fossé logique.
3. Protection des données : Garantir que les modèles et les données sont chiffrés au repos et en transit à l'aide de clés gérées par le client. Cela me donne un contrôle direct sur mon matériel cryptographique.
4. Accès au moindre privilège : Implémenter des rôles IAM granulaires, séparant les préoccupations du déploiement de modèles de l'invocation de modèles. Cela minimise le rayon d'impact de toute compromission de crédentiels.
5. Gouvernance des modèles : Implémenter des pratiques telles que la signature de modèles (par exemple, en utilisant Sigstore/Cosign), l'analyse des vulnérabilités des dépendances de modèles et une journalisation d'audit complète pour tous les événements du cycle de vie des modèles. Cela renforce la confiance et la traçabilité dans la chaîne d'approvisionnement de l'IA.
6. Conformité à la souveraineté : S'aligner sur les cadres réglementaires en tirant parti d'offres cloud et de partenariats spécifiques, garantissant que le contrôle juridique et opérationnel réside dans des juridictions conformes.

Voici comment ces composants s'assemblent pour un déploiement Vertex AI hautement sécurisé :

En matière d'isolation du réseau, je choisis généralement Private Service Connect (PSC) plutôt que le peering VPC pour la connexion aux services gérés comme Vertex AI. Bien que le peering VPC fonctionne, PSC offre une séparation plus nette. Avec PSC, les services Vertex AI se présentent comme des points d'extrémité directement au sein de mon VPC, consommant une adresse IP interne. Cela élimine le besoin de routage transitif ou de gestion de réseaux appairés, simplifiant mon architecture réseau et réduisant la surface d'attaque. C'est une connexion réseau dédiée et interne, contournant complètement l'internet public.

VPC Service Controls (VPC-SC) est mon mur numérique de Fort Knox. Il me permet de définir des périmètres de sécurité autour de mes projets GCP et des services qu'ils contiennent, comme Vertex AI et Cloud Storage. Toute tentative de déplacement de données ou d'accès à des ressources depuis l'extérieur de ce périmètre est bloquée, quelles que soient les autorisations IAM. C'est une ligne de défense critique contre l'exfiltration de données, garantissant que même si un attaquant compromet un compte de service, il ne peut pas extraire de données en dehors de mon périmètre défini. Cela crée efficacement un fossé logique basé sur des politiques pour mes services sensibles.

Pour les Données au repos et en transit, les clés de chiffrement gérées par le client (CMEK) sont primordiales. Bien que Google chiffre les données par défaut, CMEK me donne un contrôle cryptographique sur les clés qui protègent mes modèles dans le registre de modèles Vertex AI et leurs artefacts associés dans Cloud Storage. C'est une exigence courante dans les industries réglementées. Pour les données en transit, les points d'extrémité privés Vertex AI utilisent intrinsèquement TLS (Transport Layer Security), garantissant que toutes les communications entre mon VPC et le service Vertex AI sont chiffrées et sécurisées.

Enfin, la Gestion des identités et des accès (IAM) doit être chirurgicale. Je préconise toujours des comptes de service distincts pour des actions distinctes. L'identité qui déploie un modèle doit être différente du compte de service qui invoque le point d'extrémité pour l'inférence. Cela adhère au principe du moindre privilège, minimisant le rayon d'impact de toute compromission de crédentiel. Par exemple, un compte de service model-deployer pourrait avoir aiplatform.admin sur les modèles, tandis qu'un compte de service inference-invoker n'aurait que aiplatform.user sur des points d'extrémité spécifiques.

En Europe, la conversation autour de la souveraineté des données et de la confiance numérique s'intensifie. Le concept de « cloud de confiance » gagne du terrain, en particulier en France avec sa certification SecNumCloud. Mais pour vraiment comprendre ce que ces exigences signifient pour les charges de travail d'IA sur GCP, il est utile d'aller au-delà des noms et d'examiner les mécanismes expliquant pourquoi les contrôles de sécurité cloud standard — même les plus renforcés comme ceux couverts dans ce guide — ne sont pas suffisants pour les organisations opérant sous des mandats du secteur public français ou des exigences strictes de souveraineté de l'UE.

Le problème fondamental : la loi extraterritoriale

Avant de parler de S3NS, nous devons comprendre pourquoi elle existe. Le US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) signifie qu'une entreprise américaine — y compris Google — peut être contrainte de remettre des données qu'elle contrôle, même si ces données sont physiquement stockées en Europe. Les contrôles de sécurité cloud standard (VPC Service Controls, CMEK, Private Service Connect) vous protègent contre les menaces externes et les mauvaises configurations, mais ils ne modifient pas la réalité juridictionnelle fondamentale : Google est une entité américaine, et son personnel opérationnel peut théoriquement être contraint d'agir en vertu du droit américain. C'est ce que SecNumCloud et S3NS abordent de front.

Qu'est-ce que SecNumCloud ?

SecNumCloud est un cadre de qualification publié par l'ANSSI (Agence nationale de la sécurité des systèmes d'information), l'agence nationale française de cybersécurité. La version 3.2 — la version actuelle et opérationnellement significative — comprend 276 exigences réparties dans 15 domaines de sécurité : sécurité opérationnelle, cryptologie, contrôle d'accès, sécurité réseau, continuité des activités, gestion des incidents et, de manière critique, protection contre les lois extraterritoriales. Ce dernier domaine est ce qui distingue SecNumCloud des autres certifications de sécurité européennes comme ISO 27001 ou BSI C5. Ce n'est pas purement une norme de cybersécurité ; c'est simultanément un cadre de contrôle juridictionnel. Un fournisseur ne peut obtenir la qualification SecNumCloud que s'il peut démontrer que les gouvernements étrangers n'ont aucun mécanisme juridique ou technique pour contraindre l'accès aux données des clients.

S3NS : Structure et conception de l'entreprise

S3NS (prononcé sens) est une coentreprise structurée pour être légalement immunisée contre la pression extraterritoriale américaine dès sa création. Faits clés :

• Participation majoritaire : Thales détient la majorité des parts ; Google Cloud détient environ 20 %.
• Juridiction légale : S3NS est une société par actions simplifiée (SAS) française, légalement obligée exclusivement en vertu du droit européen.
• Conséquence : Toute demande de données du gouvernement américain adressée à S3NS peut être — et serait — rejetée ; il n'existe aucun mécanisme juridique par lequel Google peut contraindre unilatéralement S3NS à agir.

La structure de l'entreprise est une ingénierie de souveraineté intentionnelle : Google apporte la technologie, Thales et S3NS apportent l'enveloppe juridique européenne et le contrôle opérationnel.

Deux niveaux : CRYPT3NS vs. PREMI3NS

S3NS propose deux niveaux de service distincts, et les confondre est une erreur courante :

Pour la plupart des organisations européennes du secteur privé, CRYPT3NS offre une protection significative via des contrôles de résidence des données et une juridiction légale. Pour les organisations soumises aux règles strictes des marchés publics français, aux chaînes d'approvisionnement de la défense ou aux secteurs nécessitant explicitement la qualification SecNumCloud, seule PREMI3NS répond aux exigences.

Comment PREMI3NS réalise l'isolation technique

C'est la question centrale : comment les services GCP peuvent-ils fonctionner dans un centre de données sur lequel Google n'a aucun contrôle ?

La réponse est Google Cloud Dedicated — une architecture où Google licencie sa pile technologique (logiciels de calcul, de stockage, de réseau) à S3NS, qui la déploie et l'exploite entièrement sur sa propre infrastructure physique. Plusieurs mécanismes de contrôle délibérés rendent cela possible :

1. Infrastructure physiquement isolée : PREMI3NS fonctionne sur son propre matériel de calcul, de stockage et de réseau dans des centres de données français. Ces systèmes sont entièrement séparés du cloud public mondial de Google — il n'y a pas de tissu partagé et pas de plan de contrôle commun accessible aux employés de Google.

2. Zéro accès Google : Le personnel de Google n'a aucun accès physique ou logique à l'environnement PREMI3NS. Les opérations, l'administration et le support sont effectués exclusivement par des employés de S3NS situés au sein de l'UE. Les escalades qui atteindraient normalement l'ingénierie de Google sont gérées en interne par S3NS.

3. Modèle de quarantaine des mises à jour : Lorsque Google publie une mise à jour logicielle — correctifs de noyau, mises à jour de services, nouvelles fonctionnalités — S3NS l'intercepte dans un environnement de quarantaine. Les ingénieurs de S3NS effectuent une rétro-ingénierie automatisée et une analyse de sécurité sur les binaires avant de décider de les déployer en production. S3NS n'exécute pas passivement le code de Google ; c'est un gardien actif de chaque changement logiciel qui atteint son infrastructure.

4. Contrôle cryptographique souverain : S3NS gère les racines cryptographiques de confiance pour l'environnement PREMI3NS. Contrairement à CMEK sur GCP standard, où vous gérez les clés mais Google exploite toujours l'infrastructure, sur PREMI3NS, toute la hiérarchie de gestion des clés se trouve sous le contrôle de S3NS et du client — et non de Google.

5. Modèle SOC double : S3NS exploite son propre centre d'opérations de sécurité en coordination avec le SOC P10 certifié ANSSI de Thales, offrant une double surveillance des comportements anormaux, y compris toute tentative d'introduire un chemin d'accès accessible à Google.

Catalogue de services actuel et feuille de route Vertex AI

À la date de la qualification de décembre 2025, PREMI3NS couvre l'infrastructure de base pour la plupart des charges de travail réglementées : Compute Engine, Cloud GPUs (NVIDIA H100s), Cloud Storage, réseau (DNS, VPN, équilibrage de charge, Cloud Armor, Interconnect), BigQuery Enterprise, Pub/Sub, GKE Autopilot, Cloud SQL Enterprise Plus et outils d'exploitation (surveillance, journalisation). Une deuxième vague — Cloud Run, Cloud Build, Cloud Spanner, Cloud Bigtable, Secret Manager, Confidential VMs et Admin Access Transparency — est en attente de qualification pour le premier semestre 2026.

Pour Vertex AI spécifiquement, les fondations principales (Model Garden pour les modèles à poids ouverts, Model Registry, Workbench et Online Inference) sont sur la feuille de route pour le second semestre 2026. Gemini ne fera pas partie du Model Garden initial — seuls les modèles open-source et à poids ouverts sont inclus initialement, ce qui est une considération matérielle pour la conception de l'inférence d'IA souveraine aujourd'hui. Si vous avez besoin d'une inférence qualifiée SecNumCloud dès maintenant, la voie pratique consiste à déployer vos propres modèles sur GKE Autopilot avec des GPU H100 sur PREMI3NS. Vertex AI géré sur PREMI3NS est imminent, mais pas encore livré.

Quand utiliser S3NS vs. le durcissement GCP standard

Les contrôles couverts dans le reste de ce guide (PSC, VPC-SC, CMEK) sont très efficaces pour la grande majorité des charges de travail réglementées de l'UE. L'heuristique suivante aide à décider quel niveau est approprié :

• GCP standard renforcé (ce guide) : suffisant pour le RGPD, NIS2, ISO 27001, les cadres bancaires/d'assurance, et toute organisation où l'isolation opérationnelle du droit américain n'est pas une exigence explicite d'approvisionnement.
• CRYPT3NS : approprié lorsque la juridiction légale française et les garanties de résidence des données sont nécessaires, mais qu'une isolation complète de l'infrastructure n'est pas obligatoire.
• PREMI3NS : obligatoire lorsque la qualification SecNumCloud est requise — OIV français (Opérateurs d'Importance Vitale), chaîne d'approvisionnement de la défense, données gouvernementales sensibles ou toute spécification d'approvisionnement qui fait explicitement référence à SecNumCloud.

L'attribution du contrat de cloud souverain de 180 millions d'euros de l'UE impliquant S3NS, et l'adoption par Thales de SAP RISE sur PREMI3NS, signalent que ce modèle est passé du pilote à la production à grande échelle.

Tout d'abord, j'établis une connexion privée à Vertex AI. Cela implique la création d'un point d'extrémité Private Service Connect dans mon VPC qui se connecte au réseau du producteur de services Vertex AI. Notez que Vertex AI provisionne en interne son propre rattachement de service ; je n'ai qu'à configurer le côté consommateur dans mon projet.

# main.tf
# Define variables for your project and region
variable "gcp_project_id" {
  description = "The ID of your GCP project."
  type        = string
}

variable "gcp_region" {
  description = "The GCP region for resources (e.g., europe-west1)"
  type        = string
  default     = "europe-west1" # Always prefer European regions
}

variable "vpc_network_name" {
  description = "The name of your existing VPC network."
  type        = string
  default     = "vertex-ai-inference-vpc" # Example VPC name
}

# Configure the GCP provider
provider "google" {
  project = var.gcp_project_id
  region  = var.gcp_region
}

# Create a Private Service Connect endpoint for Vertex AI
# This service attachment name is specific to Vertex AI Prediction
# and is a Google-managed producer endpoint.
resource "google_compute_network_attachment" "vertex_ai_psc_endpoint" {
  name        = "vertex-ai-psc-endpoint"
  project     = var.gcp_project_id
  region      = var.gcp_region
  description = "PSC endpoint for Vertex AI Prediction service."
  network     = "projects/${var.gcp_project_id}/global/networks/${var.vpc_network_name}"

  # The service_attachment_names array must reference the Google-managed producer attachment.
  # For Vertex AI Prediction, the format is 'projects/REGION-aiplatform/regions/REGION/serviceAttachments/aiplatform-producer-REGION'
  # Replace REGION with the specific region you are deploying to (e.g., europe-west1).
  service_attachment_names = ["projects/${var.gcp_region}-aiplatform/regions/${var.gcp_region}/serviceAttachments/aiplatform-producer-${var.gcp_region}"]
}

output "psc_endpoint_link" {
  description = "The self_link of the Private Service Connect network attachment."
  value       = google_compute_network_attachment.vertex_ai_psc_endpoint.self_link
}

# Note: For managed services like Vertex AI, you typically interact via DNS names
# that resolve to the private IP behind the scenes. This PSC endpoint enables that private resolution.

Cette configuration Terraform configure le côté consommateur de PSC. La clé est d'identifier correctement les service_attachment_names pour Vertex AI Prediction dans votre région choisie. Une fois déployé, tout le trafic de votre vertex-ai-inference-vpc vers ce point d'extrémité sera acheminé en privé vers Vertex AI. Bien que la sortie psc_endpoint_link fournisse le lien de la ressource, pour les services gérés comme Vertex AI, vous interagissez généralement via des noms DNS qui se résolvent en cette IP privée en arrière-plan. Consultez la documentation officielle de Private Service Connect pour les noms de rattachement de service les plus récents.

Ensuite, je définis un périmètre de sécurité autour de mes projets et de mes services critiques. Cet exemple suppose que vous avez une organisation définie dans GCP, ce qui est une condition préalable à VPC-SC.

# vpc_sc.tf
resource "google_access_context_manager_service_perimeter" "vertex_ai_perimeter" {
  parent = "organizations/YOUR_ORGANIZATION_ID" # IMPORTANT: Replace with your actual organization ID
  name   = "accessPolicies/YOUR_ACCESS_POLICY_ID/servicePerimeters/vertex_ai_sec_perimeter" # IMPORTANT: Replace with your actual Access Policy ID
  title  = "vertex-ai-sec-perimeter"

  perimeter_type = "REGULAR"

  status {
    restricted_services = [
      "aiplatform.googleapis.com",
      "storage.googleapis.com" # Critical for models and artifacts in Cloud Storage
    ]

    # If you have specific access levels defined (e.g., trusted IP ranges or device policies),
    # you would list them here. For this example, we assume basic project inclusion.
    # For creating an access policy and level, refer to Google Cloud's Access Context Manager docs.
    # access_levels = [
    #   "accessPolicies/YOUR_ACCESS_POLICY_ID/accessLevels/trusted_networks_and_devices" # Example access level
    # ]

    resources = [
      "projects/${var.gcp_project_id}" # Your project where Vertex AI is deployed
    ]
  }

  description = "VPC-SC perimeter for Vertex AI and associated storage."
}

Ce bloc Terraform crée un périmètre VPC-SC. J'inclus aiplatform.googleapis.com et storage.googleapis.com dans restricted_services car mes modèles et ensembles de données résident souvent dans Cloud Storage. Le champ resources spécifie les projets protégés par ce périmètre. N'oubliez pas que les politiques VPC-SC sont évaluées après IAM, donc même si une identité dispose des autorisations storage.admin, si elle se trouve en dehors du périmètre ou viole un niveau d'accès, sa demande sera refusée. Cela fournit une couche robuste de prévention de l'exfiltration de données.

Remarque : La configuration des access_levels et des access_policies nécessite une planification minutieuse au niveau de l'organisation. Pour un guide détaillé, reportez-vous à la documentation des contrôles de services VPC.

Prendre le contrôle de vos clés de chiffrement est une étape vitale pour la conformité réglementaire. Je vais créer un trousseau de clés Cloud KMS et une clé, puis accorder les autorisations nécessaires à Vertex AI pour l'utiliser.

# Step 3a: Create a KMS Key Ring and Key
# Key rings organize keys; keys perform encryption/decryption.
KMS_KEYRING_NAME="vertex-ai-model-keyring"
KMS_KEY_NAME="vertex-ai-model-key"
KMS_LOCATION="europe-west1" # Match your Vertex AI region for optimal latency
PROJECT_ID="my-gcp-project-id" # Replace with your actual project ID

gcloud kms keyrings create "${KMS_KEYRING_NAME}" \n       --location="${KMS_LOCATION}" \n       --project="${PROJECT_ID}"

gcloud kms keys create "${KMS_KEY_NAME}" \n       --keyring="${KMS_KEYRING_NAME}" \n       --location="${KMS_LOCATION}" \n       --purpose="encryption" \n       --project="${PROJECT_ID}"

# Step 3b: Grant Vertex AI Service Agent permissions to use the KMS Key
# The Vertex AI Service Agent is specific to your project and region.
# Format: service-<PROJECT_NUMBER>@gcp-sa-aiplatform.iam.gserviceaccount.com
# Get your project number:
PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
VERTEX_AI_SERVICE_AGENT="service-${PROJECT_NUMBER}@gcp-sa-aiplatform.iam.gserviceaccount.com"

KMS_KEY_RESOURCE="projects/${PROJECT_ID}/locations/${KMS_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME}"

gcloud kms keys add-iam-policy-binding "${KMS_KEY_NAME}" \n       --location="${KMS_LOCATION}" \n       --keyring="${KMS_KEYRING_NAME}" \n       --member="serviceAccount:${VERTEX_AI_SERVICE_AGENT}" \n       --role="roles/cloudkms.cryptoKeyEncrypterDecrypter" \n       --project="${PROJECT_ID}"

echo "KMS Key Resource Name: ${KMS_KEY_RESOURCE}"

Sortie attendue (exemple pour la création de clé) :

Created keyring [vertex-ai-model-keyring].
Created key [vertex-ai-model-key].
Updated IAM policy for key [vertex-ai-model-key].
KMS Key Resource Name: projects/my-gcp-project-id/locations/europe-west1/keyRings/vertex-ai-model-keyring/cryptoKeys/vertex-ai-model-key

Maintenant, lorsque je télécharge ou enregistre un modèle avec Vertex AI, je spécifie cette KMS_KEY_RESOURCE pour garantir que mes artefacts de modèle sont chiffrés avec ma CMEK. Cela se fait généralement lors de l'opération Model.upload() dans le SDK Vertex AI ou via l'API REST :

# Python 3.13+ example for uploading a model with CMEK
from google.cloud import aiplatform

PROJECT_ID = "my-gcp-project-id" # Replace with your actual project ID
REGION = "europe-west1"
MODEL_DISPLAY_NAME = "my-secure-model"
MODEL_ARTIFACT_URI = "gs://my-secure-model-bucket/path/to/model/artifacts/" # Replace with your GCS bucket for model artifacts
SERVING_CONTAINER_IMAGE_URI = "europe-west1-docker.pkg.dev/cloud-aiplatform/prediction/tf2-cpu.2-11:latest"
KMS_KEY_RESOURCE = f"projects/{PROJECT_ID}/locations/{REGION}/keyRings/{KMS_KEYRING_NAME}/cryptoKeys/{KMS_KEY_NAME}"

# Initialize the Vertex AI SDK
aiplatform.init(project=PROJECT_ID, location=REGION)

# Upload the model with CMEK
model = aiplatform.Model.upload(
    display_name=MODEL_DISPLAY_NAME,
    artifact_uri=MODEL_ARTIFACT_URI,
    serving_container_image_uri=SERVING_CONTAINER_IMAGE_URI,
    encryption_spec_key_name=KMS_KEY_RESOURCE,
    sync=True
)

print(f"Model uploaded and encrypted with CMEK: {model.resource_name}")

Cela garantit que votre modèle, lorsqu'il est stocké dans le registre et les buckets Cloud Storage associés, est protégé par vos clés cryptographiques, répondant ainsi à une exigence critique de souveraineté.

L'implémentation du moindre privilège est cruciale. Je sépare les autorisations de déploiement de modèles de celles d'invocation de modèles. Voici comment je crée un compte de service dédié à l'inférence et lui accorde uniquement les autorisations nécessaires.

# Step 4a: Create a dedicated service account for inference
PROJECT_ID="my-gcp-project-id" # Replace with your actual project ID
INFERENCE_SA_NAME="vertex-inference-sa"
INFERENCE_SA_DESCRIPTION="Service account for invoking Vertex AI endpoints."

gcloud iam service-accounts create "${INFERENCE_SA_NAME}" \n       --display-name="${INFERENCE_SA_DESCRIPTION}" \n       --project="${PROJECT_ID}"

INFERENCE_SA_EMAIL="${INFERENCE_SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"

# Step 4b: Grant necessary roles for endpoint invocation
# aiplatform.user allows invoking predictions on endpoints.
# aiplatform.endpointViewer might also be needed to view endpoint details.

gcloud projects add-iam-policy-binding "${PROJECT_ID}" \n       --member="serviceAccount:${INFERENCE_SA_EMAIL}" \n       --role="roles/aiplatform.user" \n       --project="${PROJECT_ID}"

gcloud projects add-iam-policy-binding "${PROJECT_ID}" \n       --member="serviceAccount:${INFERENCE_SA_EMAIL}" \n       --role="roles/aiplatform.endpointViewer" \n       --project="${PROJECT_ID}"

echo "Inference Service Account: ${INFERENCE_SA_EMAIL}"

Sortie attendue (exemple) :

Created service account [vertex-inference-sa].
Updated policy for project [my-gcp-project-id].
Updated policy for project [my-gcp-project-id].
Inference Service Account: vertex-inference-sa@my-gcp-project-id.iam.gserviceaccount.com

Lorsque votre application cliente ou d'autres services doivent appeler le point d'extrémité Vertex AI, ils doivent usurper l'identité de ce compte de service vertex-inference-sa ou utiliser ses identifiants. Cela minimise les risques : si ce compte de service est compromis, il ne peut qu'invoquer des prédictions et ne peut pas, par exemple, supprimer des modèles ou modifier votre configuration Vertex AI.

Enfin, je déploie le modèle chiffré CMEK sur un point d'extrémité qui utilise notre configuration de réseau privé. Je vais définir une ressource de point d'extrémité et déployer le modèle que nous avons téléchargé précédemment.

# Python 3.13+ example for deploying to a private endpoint
from google.cloud import aiplatform

PROJECT_ID = "my-gcp-project-id" # Replace with your actual project ID
REGION = "europe-west1"
MODEL_RESOURCE_NAME = model.resource_name # From previous step's model upload
ENDPOINT_DISPLAY_NAME = "my-secure-inference-endpoint"

# Initialize the Vertex AI SDK
aiplatform.init(project=PROJECT_ID, location=REGION)

# Define the endpoint configuration
endpoint = aiplatform.Endpoint.create(
    display_name=ENDPOINT_DISPLAY_NAME,
    project=PROJECT_ID,
    location=REGION,
    # network and enable_private_service_connect are key for private endpoint
    # The network must be in the same region as the endpoint. This refers to your VPC.
    network=f"projects/{PROJECT_ID}/global/networks/vertex-ai-inference-vpc", # Use your defined VPC network name
    enable_private_service_connect=True,
    sync=True
)

# Deploy the model to the endpoint
# You might specify machine type and other scaling settings here.
# This example assumes a simple deployment.
endpoint.deploy(
    model=model,
    deployed_model_display_name=f"{MODEL_DISPLAY_NAME}-deployed",
    machine_type="n1-standard-4", # Example machine type
    min_replica_count=1,
    max_replica_count=2,
    sync=True
)

print(f"Model {MODEL_DISPLAY_NAME} deployed to private endpoint: {endpoint.resource_name}")

Ce déploiement garantit que votre modèle est hébergé sur un point d'extrémité accessible uniquement via votre lien Private Service Connect configuré, fonctionnant au sein du périmètre VPC Service Controls et utilisant vos clés de chiffrement gérées par le client.

Exemple de référentiel complet : Vous pouvez trouver plus d'exemples officiels de modèles Vertex AI sécurisés sur github.com/GoogleCloudPlatform/vertex-ai-samples/tree/main/community-content/vertex_security_examples.

Exemples de code supplémentaires : Pour les modèles de déploiement avancés et l'intégration CI/CD pour Vertex AI, un référentiel avec mes implémentations plus complexes réside généralement dans mon flux de travail privé.

Pour vérifier que votre point d'extrémité est privé et sécurisé, vous devriez essayer de l'invoquer depuis votre réseau VPC, en utilisant le compte de service avec des autorisations restreintes.

# Python 3.13+ example for invoking the private endpoint
from google.cloud import aiplatform
from google.oauth2 import service_account

PROJECT_ID = "my-gcp-project-id" # Replace with your actual project ID
REGION = "europe-west1"
# Replace with your endpoint's full resource name (e.g., projects/PROJECT_NUMBER/locations/europe-west1/endpoints/ENDPOINT_ID)
ENDPOINT_RESOURCE_NAME = "projects/123456789012/locations/europe-west1/endpoints/1234567890"
INFERENCE_SA_KEY_PATH = "/path/to/your/vertex-inference-sa-key.json" # Path to the downloaded service account key file

# Initialize the AI Platform client with the service account credentials
credentials = service_account.Credentials.from_service_account_file(INFERENCE_SA_KEY_PATH)

aiplatform.init(project=PROJECT_ID, location=REGION, credentials=credentials)

# Prepare sample data for prediction (replace with actual model input format)
# This is illustrative pseudocode for data; adapt for your model's expected input.
instances = [
    {"feature_1": 1.0, "feature_2": "value"},
    {"feature_1": 2.5, "feature_2": "another_value"}
]

# Get the endpoint instance by its resource name
endpoint = aiplatform.Endpoint(ENDPOINT_RESOURCE_NAME)

try:
    prediction = endpoint.predict(instances=instances)
    print("Prediction successful:")
    print(prediction.predictions)
except Exception as e:
    print(f"Prediction failed: {e}")
    print("Verify network, IAM, and VPC-SC configurations.")

Sortie attendue :

Prediction successful:
[model output data]

Si vous tentez d'appeler ce point d'extrémité depuis l'extérieur de votre VPC (par exemple, depuis votre machine locale sans VPN/Cloud Interconnect vers votre VPC), ou sans utiliser les identifiants vertex-inference-sa, vous devriez vous attendre à une erreur de connexion ou un message d'autorisation refusée, ce qui confirme que vos contrôles de sécurité sont actifs.

1. Erreur : Violation des contrôles de service VPC

La requête est interdite par la politique de l'organisation.

**Solution :** Cela signifie généralement qu'une requête (par exemple, une tentative d'accès à un bucket en dehors du périmètre ou depuis une IP non conforme) est bloquée par VPC-SC. Vérifiez à nouveau votre configuration `google_access_context_manager_service_perimeter`. Assurez-vous que la plage IP de votre client ou le niveau d'accès est correctement défini dans la politique d'accès si la requête est légitime. Vérifiez également que tous les services sur lesquels votre opération repose (comme Cloud Storage pour les artefacts de modèle) sont inclus dans `restricted_services` et que le projet est répertorié dans `resources` au sein du périmètre. Pour plus de détails sur les niveaux d'accès, reportez-vous à la [documentation de Google Cloud Access Context Manager](https://cloud.google.com/access-context-manager/docs/overview).

1. Erreur : Autorisation IAM refusée

403 Autorisation refusée sur la ressource projects/PROJECT_NUMBER/locations/REGION/endpoints/ENDPOINT_ID

**Solution :** Le compte de service ou l'utilisateur effectuant la requête ne dispose pas du rôle `aiplatform.user` nécessaire (ou `aiplatform.endpointViewer` si vous essayez simplement de consulter les détails du point d'extrémité) sur le point d'extrémité ou le projet Vertex AI. Vérifiez les liaisons de politique IAM pour votre compte de service d'inférence à l'aide de `gcloud iam service-accounts get-iam-policy INFERENCE_SA_EMAIL` et `gcloud projects get-iam-policy my-gcp-project-id`. Assurez-vous que les rôles corrects sont accordés à la portée appropriée.

1. Erreur : Problème de connectivité Private Service Connect

Impossible de se connecter au point d'extrémité. Vérifiez la configuration du réseau.

**Solution :** Cela implique un problème avec le chemin réseau privé. Vérifiez que votre `google_compute_network_attachment` est provisionné correctement et que son statut est `ACCEPTED`. Vérifiez les règles de pare-feu dans votre VPC pour vous assurer que le trafic de votre client vers la plage IP du point d'extrémité PSC est autorisé. Confirmez également que la résolution DNS pour le point d'extrémité Vertex AI se résout en une IP interne au sein de votre VPC, et non en une IP publique. Si vous utilisez `gcloud`, assurez-vous que votre client s'exécute à partir d'une VM au sein du même VPC ou est connecté via VPN/Interconnect.