Google lance Gemini Decision 1 : des décisions via API à 0,10 $ le million de tokens

Un acheteur écrit : « La commande est arrivée cassée, je veux être remboursé. » L'application doit déterminer le sujet de la demande et l'envoyer au bon collaborateur. Google a lancé Gemini Decision 1 pour ce type d'embranchements : le modèle renvoie des scores, à partir desquels le code choisit l'action suivante. Il y a une raison concrète de s'y intéresser : l'automatisation du tri des demandes, de la vérification de contenu et d'autres décisions répétitives au sein d'un produit.

Sur Telegram, cette nouveauté a été présentée comme un concurrent de Jev. C'est un point de départ parlant pour la discussion, mais il est trop tôt pour choisir un outil sur la base d'une telle comparaison : l'équipe devra de toute façon vérifier la qualité sur ses propres demandes et calculer le coût du processus de travail.

Ce que reçoit le développeur

La documentation de l'API Decisions décrit trois modes : vérification d'une condition, choix parmi des options données et évaluation sur une échelle. La réponse contient des valeurs exploitables par un programme, notamment des probabilités et le niveau de confiance du modèle. Aucun token de texte n'est généré en sortie.

Pour une boutique fictive, on peut formuler des vérifications distinctes : le client signale-t-il un dommage, demande-t-il un remboursement, dispose-t-on de suffisamment d'informations pour traiter la demande ? Un code ordinaire combine ensuite les résultats. Admettons que la demande soit clairement liée à un dommage, mais sans numéro de commande. L'action suivante peut alors être de réclamer les données manquantes.

Il est utile ici de séparer la compréhension du message et les pouvoirs du système. Déterminer le sujet d'une demande est une chose. Autoriser un remboursement en est une autre, avec ses propres règles. Dans le schéma proposé, le modèle aide à trier le flux entrant, tandis que les conditions des opérations financières sont définies séparément par l'équipe. Il est ainsi plus simple de comprendre à quelle étape l'erreur est survenue et de corriger la règle concernée.

Combien coûte un tel embranchement

La grille tarifaire officielle de Google indique 0,10 $ par million de tokens en entrée. Le texte, les images, l'audio, la vidéo et les PDF sont pris en charge. Les données d'entrée communes au sein d'une requête sont facturées une seule fois, quel que soit le nombre de questions. En revanche, les instructions et les critères de chaque question ajoutent leurs propres tokens.

C'est pourquoi la formule « sans frais supplémentaires » du post d'origine doit être lue avec prudence : l'absence de tokens en sortie ne rend pas gratuites les instructions supplémentaires. Si l'équipe envoie de longs critères pour chaque vérification, leur volume doit aussi entrer dans le calcul.

Prenons un volume fictif : dix millions de tokens d'entrée facturables coûteraient un dollar à ce tarif. Il s'agit d'un exemple arithmétique du coût de l'API. Le budget complet d'un produit comprendra le développement de l'intégration, le stockage des résultats, la gestion des défaillances et le travail des collaborateurs sur les demandes litigieuses. Pour un product manager, il est utile de calculer le coût d'une demande correctement traitée : cette métrique relie le prix du modèle au résultat pour l'entreprise.

Une offre gratuite existe. Le tableau de Google précise que ses données peuvent être utilisées pour améliorer les produits ; pour l'offre payante, c'est l'inverse. C'est une différence importante lors du choix des données d'un pilote.

Comment vérifier l'utilité avant le déploiement

Il vaut mieux commencer par un seul processus clair, par exemple la répartition des demandes entre services. Rassemblez des demandes historiques accompagnées des réponses validées par les collaborateurs et passez-les dans le modèle. Repérez à l'avance les messages ambigus : plusieurs problèmes dans un même courriel, sarcasme, informations incomplètes, demandes ne correspondant à aucun service.

Mesurez séparément les affectations erronées et la part des demandes qu'il a fallu transmettre à un humain. Un niveau de confiance élevé du modèle ne prouve pas à lui seul la qualité sur votre échantillon. Pour le choix parmi des catégories, la documentation avertit aussi que les probabilités sont réparties entre les options proposées, même lorsqu'aucune ne convient. Prévoyez donc une catégorie « autre » et un parcours de vérification manuelle.

L'étape suivante consiste à lancer le traitement en parallèle des collaborateurs, en conservant le mode de travail habituel. Cela permet de repérer les écarts avant d'activer des actions automatiques. On peut ensuite confier progressivement au système les cas les plus clairs et suivre le temps qu'il fait réellement gagner.

Gemini Decision 1 mérite un tel pilote si le produit gère déjà un flux de décisions répétitives. Un déploiement ne se justifiera que si la vérification montre un taux d'erreur acceptable et une baisse des coûts de traitement.