Google rend disponible la journalisation des métadonnées d’inférence sans enregistrer les invites ni les réponses

Dans ses notes du 30 octobre 2026, Google Cloud a déclaré disponible de façon générale la journalisation des métadonnées des requêtes d’inférence pour Gemini Enterprise Agent Platform. Une fois activée, elle peut écrire dans Cloud Logging une entrée structurée par requête prise en charge, avec le modèle, la région, les nombres de jetons, l’usage du Provisioned Throughput, la latence et le code d’erreur, sans conserver le texte des invites ni des réponses. Cette disponibilité décrit le stade de la fonction; elle ne signifie ni activation automatique pour chaque projet ni couverture de tous les modèles et méthodes. Notre édition paraît le 2 novembre.

Il faut commencer par le périmètre des appels. L’annonce cite `generateContent` et `streamGenerateContent` pour Gemini, ainsi que `rawPredict` et `streamRawPredict` pour Claude. La documentation précise que les autres modèles partenaires ne sont pas consignés par ce mécanisme. La facturation à l’usage et le Provisioned Throughput peuvent être couverts, mais l’exploitant doit vérifier les méthodes réellement utilisées par son application. Dans un rapport réunissant des appels non pris en charge, une absence de journal pourrait être interprétée à tort comme une absence de trafic. Les entrées décrivent l’utilisation et le fonctionnement; elles ne sont pas une archive complète des entrées et sorties. Google renvoie à une fonction distincte de journalisation des requêtes et réponses si leur contenu est nécessaire.

L’activation est possible depuis la page Provisioned Throughput de la console ou par l’API REST, pour tout un projet ou pour un modèle dans une région donnée. La configuration peut prendre plusieurs minutes à se propager. Il faut donc consigner l’heure du changement et envoyer ensuite une requête de contrôle identifiable. Le guide énumère les autorisations IAM nécessaires pour modifier la configuration du modèle et gérer le compartiment de journaux. Il indique aussi qu’interroger les entrées en SQL dans Observability Analytics ou afficher des métriques détaillées dans la console suppose une mise à niveau du compartiment `_Default`. Cette mise à niveau est irréversible et les entrées antérieures ne deviennent pas interrogeables en SQL après coup. Activer la collecte, mettre à niveau le stockage et donner accès aux analystes sont trois décisions distinctes.

Le coût et la conservation font partie du déploiement. L’ingestion et le stockage sont facturés par Cloud Logging, tandis que les requêtes Observability Analytics relèvent de la consommation Cloud Monitoring. La durée de conservation par défaut est de 30 jours. Des étiquettes personnalisées nombreuses peuvent grossir chaque entrée; dans une application d’agents à fort trafic, le montant des journaux peut devenir important. Google recommande de mesurer une journée représentative puis d’estimer le volume mensuel. L’absence de texte de prompt et de réponse réduit les données collectées, mais une étiquette mal choisie peut toujours contenir un identifiant sensible. La nomenclature, les droits d’accès, la conservation et les alertes doivent donc être examinés.

L’un des usages est l’attribution de la consommation à une équipe, une application ou un locataire. Le client peut joindre des en-têtes commençant par `x-goog-agent-platform-observability-label-`, puis interroger les étiquettes dans Observability Analytics. Les entrées permettent aussi d’étudier les jetons par modèle et région, les erreurs, les délais et l’utilisation ou le débordement du débit réservé. L’attribution métier n’apparaît toutefois pas spontanément: si un client omet l’en-tête ou si les services n’emploient pas la même convention, le résultat ne couvre pas tous les appels. Une comparaison avec la facture doit distinguer les types de jetons, le cache et la consommation mesurée du montant facturé.

Un essai limité commence dans un projet de test: vérifier les permissions et le compartiment, activer explicitement l’option, attendre son effet, puis envoyer des requêtes reconnaissables par une méthode Gemini et une méthode Claude prises en charge. Les entrées dans Logs Explorer ou un environnement analytique préparé doivent confirmer le modèle, la région, les jetons et les erreurs. Une méthode non prise en charge sert aussi à démontrer qu’«aucune entrée» n’équivaut pas toujours à «aucune requête». Il faut prévoir le retour de la configuration et le traitement des journaux déjà écrits. Comme la fonction modifie les coûts et les possibilités d’accès aux données, cet article ne constitue pas une autorisation de l’activer en production.

Une entrée présente ne prouve pas non plus qu’une opération métier a réussi: les requêtes échouées peuvent être consignées. Inversement, un trou dans les journaux peut provenir de la propagation du réglage, d’une méthode exclue ou de droits de recherche insuffisants. Conserver les compteurs et les fenêtres temporelles côté client aide à distinguer un incident de collecte d’un vrai changement de trafic.

Cette mise à jour offre une preuve plus fine des opérations et de l’attribution des coûts d’inférence, à condition de maîtriser la couverture, l’activation, les droits et la qualité des entrées. Il faut comparer les journaux aux appels réels avant de s’appuyer sur un tableau de bord et ne pas présenter des métadonnées comme un audit complet des prompts.