Google Cloud intègre l’inférence IA directement dans Pub/Sub et supprime le microservice intermédiaire
Le transformateur AI Inference SMT de Pub/Sub passe en disponibilité générale : il applique un modèle de Gemini Enterprise Agent Platform à chaque message en transit. Pour l’enrichissement temps réel, vous n’avez plus besoin d’un service d’inférence séparé.
Début septembre 2026. La page « What’s new » de Google Cloud annonce la disponibilité générale du transformateur AI Inference SMT de Pub/Sub. SMT pour Single Method Transform. Septembre 2026. Le bus de messagerie, historiquement un simple tuyau, devient un point d’inférence. Pourquoi c’est important : pour enrichir un flux d’événements avec une prédiction, une classification ou une détection d’anomalie, vous n’avez plus besoin de déployer et d’opérer un microservice d’inférence intermédiaire — le bus s’en charge.
Ce que fait le AI Inference SMT
Un transformateur SMT est une fonction que Pub/Sub exécute sur un topic ou une subscription. Le AI Inference SMT applique cette logique à l’inférence : il envoie le message à un modèle hébergé sur Gemini Enterprise Agent Platform, puis ajoute la prédiction au message avant de le livrer en aval — vers BigQuery, Bigtable ou un autre consommateur.
Les modèles utilisables couvrent deux cas. Les modèles auto-déployés : des modèles ouverts, partenaires ou personnalisés, déployés sur un endpoint Agent Platform partagé ou dédié. Les modèles en MaaS (Model-as-a-Service) via Model Garden — Gemini, Claude, ou les modèles Anthropic, Mistral AI et AI21, sans gérer le déploiement. Concrètement, le message doit être une requête JSON à destination du modèle ; le transformateur fusionne les paramètres supplémentaires (par exemple {"temperature": 0.2}) avec les données du message, appelle l’endpoint, et renvoie un message enrichi structuré en {"original_message": …, "model_output": …}.
L’argument : trois maillons en moins
L’intérêt architectural se résume à ce que l’on n’a plus à construire. Sans ce transformateur, un pipeline d’enrichissement temps réel impose un service intermédiaire : un consommateur qui lit le topic, appelle le modèle, puis republie le résultat. C’est un service à déployer, à scaler, à surveiller, et un saut réseau supplémentaire à chaque événement.
Le AI Inference SMT élimine ces trois maillons. Moins de services : le bus appelle le modèle lui-même. Moins de latence : la suppression des sauts réseau intermédiaires raccourcit le trajet de bout en bout. Moins de risque de surcharge : Pub/Sub optimise le rythme des requêtes vers l’endpoint pour ne pas le saturer — un contrôle de flux que vous n’avez plus à écrire.
Pour la détection d’anomalies, cas mis en avant par Google Cloud, c’est un changement de posture : la prédiction d’un modèle est jointe à l’événement dès son passage dans le bus, disponible pour le traitement aval sans service dédié.
Topic ou subscription : le choix compte
Le transformateur se configure à deux endroits, et la différence n’est pas cosmétique. Sur un topic, l’inférence a lieu avant le stockage du message : en cas d’échec, c’est la requête de publication qui échoue, et la disponibilité de votre application émettrice est directement touchée. Sur une subscription, l’inférence a lieu avant la livraison au consommateur : en cas d’échec, Pub/Sub réessaie selon la politique de retry de la subscription, et peut renvoyer le message d’origine vers une dead-letter topic.
Google Cloud recommande la subscription. La raison est opérationnelle : si l’endpoint du modèle est saturé, subit des pics de latence ou tombe, l’impact sur le pipeline est bien plus contenu côté subscription, où la ré-ingestion reste disponible et où une dead-letter préserve les données. Sur un topic, l’indisponibilité du modèle devient l’indisponibilité de l’ingestion. Dans tous les cas, une dead-letter topic est recommandée : si l’inférence échoue, le message d’origine est transmis à la dead-letter avec un attribut CloudPubSubDeadLetterSourceSMTErrorMessage — aucune donnée n’est perdue.
La même semaine, la couche streaming mûrit
Le AI Inference SMT n’arrive pas seul. Dans la même fenêtre de septembre, Google Cloud a généralisé plusieurs briques de sa couche de données en continu : le connecteur source PostgreSQL de Managed Service for Apache Kafka est désormais en disponibilité générale (capture des changements vers Cloud SQL, AlloyDB ou PostgreSQL auto-géré), le pause-on-failure de Dataflow est en GA (geler un job batch avant l’échec pour le reprendre sans perdre le travail accompli), et l’API d’insertion insertAll de BigQuery est rebaptisée Storage Write API (REST), avec une compatibilité rétroactive totale.
Le motif commun est lisible : la couche streaming cesse d’être un simple transport pour devenir le lieu où l’on transforme, où l’on infère et où l’on résiste aux pannes — sans sortir du flux.
Chaîner, pré-traiter, et surveiller le coût
Le AI Inference SMT se combine avec d’autres transformateurs. Un JavaScript UDF placé en amont peut reformater le message pour l’adapter au format attendu par le modèle — par exemple un appel Chat Completions —, et un second en aval peut retraiter la sortie avant livraison. C’est la solution quand votre application émettrice ne produit pas nativement la structure JSON requise.
Reste la question du coût. Chaque message enrichi déclenche un appel de modèle, facturé selon le modèle choisi : sur un flux à fort volume, l’inférence systématique peut coûter plus cher que le pipeline qu’elle simplifie. Le contrôle de flux de Pub/Sub limite les appels pour ne pas saturer l’endpoint, mais il n’en réduit pas le nombre — il les étale. La comparaison n’est donc pas « transformateur ou service dédié », mais « transformateur managé ou Cloud Functions/Dataflow » : pour une inférence à chaque événement, le transformateur gagne en simplicité ; pour une inférence sélective, déclenchée par une condition métier, une fonction séparée reste plus économique.
Les limites à connaître avant de l’activer
Le transformateur a des bornes documentées qu’il vaut mieux intégrer au cahier des charges. La taille du message : le message transformé, enrichi de la sortie du modèle, doit rester sous la limite de taille de Pub/Sub, sinon la transformation échoue. La contrainte régionale : pour une subscription en pull, la requête doit être adressée depuis la région de l’endpoint, sous peine de rejet — la documentation recommande un endpoint locational. Le pull unaire : le contrôle de flux n’est pas supporté avec l’API de pull unaire. Et les quotas : le transformateur est soumis aux quotas de l’endpoint Agent Platform ; le contrôle de flux ajuste le rythme, mais ne peut pas dépasser le quota du modèle.
Ces limites dessinent le bon usage. Le transformateur excelle sur l’enrichissement uniforme — chaque événement reçoit une prédiction — et sur la détection d’anomalies en continu. Il convient mal à l’inférence conditionnelle, où seuls quelques événements méritent un appel de modèle : dans ce cas, une fonction dédiée qui filtre d’abord reste plus économe, et le transformateur devient un coût fixe plutôt qu’un gain.
Verdict
Le AI Inference SMT de Pub/Sub est une évolution discrète mais structurante : elle déplace l’inférence du service dédié vers le bus, et supprime la partie la plus coûteuse d’un pipeline d’enrichissement temps réel.
Si vous êtes déjà sur Pub/Sub et que vous enrichissez des événements avec un modèle, adoptez-le : vous supprimez un service, un saut réseau et du code de contrôle de flux. Si votre endpoint modèle est fragile ou saturé, configurez-le sur une subscription, jamais sur un topic, et attachez systématiquement une dead-letter topic. Si vous n’avez pas encore d’inférence temps réel, ce n’est pas une raison pour l’ajouter : le transformateur n’a de valeur que là où une prédiction jointe à chaque événement a un consommateur en aval — sinon, vous payez des appels de modèle pour rien.