Google lance une API de choix d'actions avec une latence de 150 à 250 ms

Au support, une file de demandes s'est accumulée, et le LLM doit décider où envoyer chacune : vers le paiement, le service technique ou un responsable. Pour un simple choix, l'équipe configure la génération de JSON, vérifie le format et gère les réponses ratées. Google propose une API distincte pour ce type de tâches : le développeur définit les options autorisées, et le modèle renvoie leurs probabilités. C'est un candidat utile pour une expérimentation là où le produit a besoin de choisir rapidement la prochaine action.

Dans l'annonce de Google, le nouveau service s'appelle Gemini Decisions API et le modèle Gemini Decision 1. Il évalue les réponses proposées en une seule passe. La latence annoncée est de 150 à 250 ms, mais il y a une réserve importante : les mesures présentées concernent un contexte allant jusqu'à 16 000 jetons. Ce serait une erreur de transposer cette vitesse à n'importe quel document long.

À quoi cela ressemble dans un produit

Imaginons un service qui traite les demandes des clients. En entrée arrive un e-mail accompagné d'une capture d'écran d'un débit. Le développeur définit trois catégories : question de paiement, problème technique, autre. On peut aussi demander si la demande nécessite une réaction urgente. Ces vérifications portent sur un même contenu, il est donc pratique de les regrouper dans une seule requête.

Vient ensuite la logique produit habituelle. Si le score de la catégorie choisie dépasse le seuil fixé, la demande est automatiquement placée dans la bonne file. Si la confiance est insuffisante, elle est confiée à un opérateur. Par exemple, l'équipe peut commencer avec un seuil de 95 %, puis le modifier selon les résultats des vérifications. Il s'agit d'un exemple de réglage fictif, non d'une valeur recommandée par Google.

L'API prend en charge les questions « oui ou non », le choix dans une liste et l'évaluation sur une échelle donnée. Parmi les formats d'entrée figurent le texte, les images, l'audio, la vidéo et les PDF. L'intérêt pratique du multimodal est clair : l'e-mail et la capture d'écran jointe peuvent être examinés ensemble, en conservant les détails importants pour la décision.

Le développeur devra malgré tout décrire les options avec suffisamment de clarté. Si deux catégories se recoupent, la seule présence de probabilités ne corrigera pas la classification. Il faut d'abord déterminer ce qui distingue une question de remboursement d'une contestation de débit, et seulement ensuite automatiser la répartition.

Ce qu'il faut vérifier derrière les promesses de vitesse et de prix

Google indique un prix de 0,10 $ par million de jetons d'entrée et l'absence de facturation des jetons de sortie. Le contenu commun est facturé une seule fois par requête, tandis que les questions ajoutent leurs propres instructions et critères. Le service permet de poser jusqu'à 1000 questions sur une même entrée ; le contexte maximal est de 256 000 jetons.

Pour une équipe, c'est une raison de calculer le coût de son opération précise. Quelle place prend l'instruction ? Combien de questions sont réellement nécessaires ? À quelle fréquence faudra-t-il faire revérifier le résultat par un humain ? Un appel bon marché peut n'apporter qu'une faible économie si une grande file manuelle subsiste ensuite.

L'affirmation d'une réduction des coûts par cinq nécessite elle aussi du contexte. Dans la source d'origine, Google compare le service à Gemini 3.5 Flash-Lite sur un ensemble de tests général. Ce n'est pas la promesse de réduire par cinq les dépenses de n'importe quelle application. Pour votre propre calcul, il faut le modèle actuel, des documents réels et des exigences de qualité identiques.

La probabilité doit être vérifiée sur vos propres données

La partie la plus intéressante d'une telle interface est la possibilité de piloter l'automatisation par un seuil. Mais le chiffre de 95 % dans la réponse reste à confronter à la proportion réelle de décisions correctes sur vos demandes. Il est particulièrement utile de vérifier séparément les catégories rares et les cas ambigus : ce sont souvent eux qui provoquent des erreurs coûteuses.

Je commencerais par une opération étroite, par exemple la répartition des demandes entre services. Je constituerais un échantillon annoté, comparerais l'API à la solution actuelle et examinerais trois indicateurs : erreurs de routage, temps de réponse et part des demandes restant à l'opérateur. Après cela, on peut choisir un seuil de production.

Pour un product manager, le résultat d'un tel test est bien plus utile qu'un tableau général de benchmarks. Il montrera combien de demandes peuvent être traitées automatiquement pour un nombre d'erreurs acceptable. Et il donnera au développeur une base concrète pour décider s'il faut ajouter ce nouveau service au système de production.