Google lance Gemini Decision 1 : des décisions sur vidéo à 0,10 $ le million de tokens

Une demande arrive au support avec la photo d'un produit endommagé. L'application doit déterminer le type de problème, choisir le service compétent et décider si une vérification manuelle est nécessaire. Générer plusieurs paragraphes d'explications n'a généralement aucun intérêt ici. Google a lancé l'API Gemini Decisions : le développeur fournit le contenu et les réponses admissibles, et le modèle Gemini Decision 1 renvoie des scores que le code exploite ensuite.

L'intérêt pratique est de pouvoir isoler les vérifications répétitives dans un appel dédié. Par exemple, trier d'abord les demandes, puis confier les cas complexes à un humain ou à un modèle qui préparera la réponse au client. Pour une équipe, c'est une occasion de mesurer combien de temps et d'argent sont aujourd'hui consacrés à générer du texte pour une simple décision de service.

Ce que reçoit l'application

Selon l'annonce de Google, l'API accepte le texte, les images, l'audio, la vidéo et les PDF. Trois types de questions sont pris en charge : oui/non, choix parmi des options prédéfinies et évaluation sur une échelle décrite. Le prix est de 0,10 $ par million de tokens en entrée ; il n'y a pas de frais pour les tokens en sortie.

Imaginons un service de réception de logements. L'utilisateur envoie une vidéo d'une pièce avec ce commentaire : « Après la pluie, de l'eau est apparue près de la fenêtre. » L'équipe peut formuler plusieurs questions indépendantes : des traces de fuite sont-elles visibles, à quel spécialiste adresser la demande, quelle est l'urgence de l'inspection. Il s'agit d'un exemple d'usage possible, et non d'un résultat de test publié pour le produit.

La qualité d'un tel scénario commence par la formulation. La question « Tout est-il normal ici ? » laisse trop de place à l'interprétation. Il vaut mieux énumérer des signes observables et décrire des catégories : eau au sol, taches sur le mur, dégradation des finitions. Pour l'évaluation de l'urgence, il faut aussi des critères clairs, faute de quoi le chiffre sera difficile à relier à une action.

Pourquoi 92 % ne sont pas une garantie

Simon Willison a testé l'API sur une vidéo contenant un robot. Il a demandé s'il y avait un dragon ou un robot dans le cadre, et si l'action se déroulait en France ou aux États-Unis. Dans la réponse citée, la probabilité de la présence d'un robot est d'environ 92,3 %, celle d'un dragon d'environ 5 %. Pour les États-Unis, le modèle a renvoyé environ 92,3 %, pour la France 8,3 %.

Cet essai montre le format de réponse et la capacité à traiter une vidéo précise. Il n'établit pas la précision du modèle sur des vidéos quelconques. Surtout, un score de 92 % ne signifie pas, à lui seul, que sur cent décisions similaires exactement 92 seront correctes. Cette correspondance doit être vérifiée sur des exemples annotés issus de votre propre tâche.

La géographie ajoute un piège. Reconnaître un objet avec assurance et déterminer le pays de tournage sont deux tâches différentes. L'image peut contenir assez d'indices pour identifier un robot, mais pas assez pour situer le lieu. Si l'erreur touche à l'argent ou à l'accès d'un utilisateur à un service, il est utile de prévoir l'issue « données insuffisantes » ainsi qu'un chemin vers la vérification manuelle.

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

Je commencerais par une seule opération que le produit effectue déjà régulièrement : le tri des demandes, la vérification de la complétude d'un document ou le choix du prochain outil pour un agent. Pour une première comparaison, il faut des exemples réels dont la bonne réponse est connue, y compris les cas gênants : photos de mauvaise qualité, commentaires contradictoires, plusieurs problèmes simultanés.

Il faut ensuite mesurer trois choses : la part de décisions erronées, le temps de traitement et le coût d'une demande dans son ensemble. Le prix du million de tokens aide à comparer les tarifs, mais le produit paie pour le contenu traité. Une longue vidéo et une courte demande textuelle peuvent avoir une économie très différente. Les appels répétés et la vérification manuelle entrent aussi dans le calcul.

Le seuil d'automatisation se choisit mieux en fonction du coût de l'erreur. Une étiquette mal attribuée se corrige généralement facilement. Une réclamation rejetée à tort crée déjà un conflit avec le client. Ainsi, un même score du modèle peut autoriser une action automatique dans un processus et exiger une vérification dans un autre.

L'API Gemini Decisions mérite un test là où les options d'action sont connues à l'avance. On peut commencer par un mode d'observation : enregistrer les décisions du modèle à côté de celles des employés, analyser les écarts, et ne l'activer en traitement automatique qu'ensuite. L'équipe obtiendra ainsi la réponse à la question essentielle : la nouvelle API aide-t-elle réellement son produit ?