Une même pièce de contexte, 1 000 questions indépendantes et un résultat en quelques centaines de millisecondes : Google positionne Gemini Decisions comme une brique d’automatisation plutôt que comme un chatbot supplémentaire. L’API accepte du texte, des images, de l’audio, de la vidéo et des PDF, puis renvoie des options sélectionnées, des probabilités et des scores de confiance.
Le changement intéresse directement les entreprises qui évaluent en masse des documents, des dossiers ou des flux multimédias. Il ne supprime toutefois pas le besoin de règles métier, de contrôles humains et de mesures de fiabilité. Une décision probabiliste n’est pas une responsabilité déléguée au modèle.
Gemini Decisions transforme un contexte unique en 1 000 évaluations
L’idée centrale de Gemini Decisions consiste à séparer l’analyse d’un contenu de la génération d’une réponse longue. L’entreprise transmet une entrée commune, puis associe jusqu’à 1 000 questions indépendantes à ce même contexte. Gemini Decision 1 évalue les options candidates en un seul passage et renvoie des probabilités ainsi qu’un niveau de confiance.
Le service prend en charge plusieurs formats : texte, images, audio, vidéo et PDF. La taille maximale annoncée pour l’entrée multimodale atteint 256 000 tokens, tandis que les mesures de latence publiées concernent des contextes allant jusqu’à 16 000 tokens.
Les questions peuvent prendre plusieurs formes :
- une évaluation binaire, par exemple déterminer si une clause est présente ;
- un choix multiple entre 2 et 255 options ;
- une notation fondée sur une grille ordonnée ;
- une série de critères appliqués au même document ou au même fichier multimédia.
Cette architecture change le coût et la logique d’un traitement en lot. Au lieu de lancer une requête complète pour chaque critère, une application peut regrouper les critères liés à une même entrée. Le modèle ne produit pas un texte explicatif pour chaque question : il attribue un score aux options prévues par le développeur.
À retenir : Gemini Decisions est conçu pour évaluer des décisions bornées et répétitives. Il ne remplace pas un agent conversationnel chargé de construire une réponse libre ou de piloter seul un processus complexe.
Le prix de 0,10 dollar favorise les traitements en volume
Google facture Gemini Decision 1 0,10 dollar par million de tokens d’entrée et n’applique pas de frais sur les tokens de sortie. Le contexte partagé est facturé une seule fois par requête, quel que soit le nombre de questions évaluées ; chaque question ajoute toutefois ses propres instructions et critères au volume traité.
Le modèle ne générant pas de texte de sortie classique, la structure tarifaire diffère de celle des API conversationnelles traditionnelles. Elle devient particulièrement intéressante lorsque plusieurs contrôles portent sur le même contenu : une facture, un contrat, une vidéo d’inspection ou un dossier client.
| Élément | Gemini Decisions | Conséquence pour l’entreprise |
|---|---|---|
| Questions par requête | Jusqu’à 1 000 | Regroupement de nombreux critères sur un même contenu |
| Prix d’entrée | 0,10 $ par million de tokens | Coût prévisible pour les volumes textuels importants |
| Prix de sortie | 0 $ | Pas de facturation de tokens générés |
| Latence de bout en bout | 150 à 250 ms | Adapté aux contrôles nécessitant une réponse rapide |
| Formats acceptés | Texte, image, audio, vidéo, PDF | Utilisable sur des données multimodales |
| Offre concurrente OpenAI | Jusqu’à 400 questions par requête | Capacité de regroupement inférieure sur ce critère |
Le prix facial ne suffit cependant pas à estimer une facture complète. Le volume de tokens du contexte, la répétition des requêtes, le stockage des contenus, les systèmes d’orchestration et les contrôles humains entrent aussi dans le coût total d’exploitation.
La mutualisation du contexte constitue le principal levier économique. Une entreprise qui pose 200 questions sur un même contrat peut transmettre une seule fois le document, puis formuler les critères associés. Le bénéfice dépend donc moins du nombre brut de questions que de la capacité à regrouper des évaluations réellement liées.
Une latence de 150 à 250 millisecondes, avec des limites de périmètre
Google annonce une latence de bout en bout comprise entre 150 et 250 millisecondes dans des tests réalisés avec des contextes allant jusqu’à 16 000 tokens. Le temps de calcul du modèle représente environ 50 à 100 millisecondes. Les performances restent presque stables entre une et 100 questions par requête dans les conditions annoncées.
Cette caractéristique rend le service pertinent pour des applications qui doivent filtrer ou classer un flux sans attendre la génération d’une longue justification. Un système de contrôle documentaire peut, par exemple, évaluer simultanément la présence de plusieurs clauses, la conformité d’un format et la nécessité d’une revue humaine.
Il faut distinguer ces résultats du cas maximal annoncé par l’API. Une requête comprenant 256 000 tokens et 1 000 questions constitue une charge différente d’un contexte de 16 000 tokens avec quelques dizaines de critères. Les chiffres de latence publiés ne permettent pas d’assimiler ces deux scénarios.
Cette distinction doit apparaître dans les tests de préproduction. Les équipes techniques devraient mesurer séparément :
- la latence avec un petit contexte et peu de questions ;
- la latence avec 100 questions, seuil utilisé dans les mesures publiées ;
- le comportement avec des documents longs ;
- le temps total incluant l’envoi, le traitement et la réception ;
- le taux d’erreur et les délais de reprise.
Une réponse rapide ne garantit pas une bonne décision. Pour une entreprise, la performance utile combine la vitesse, la stabilité du service, la qualité des scores et la capacité à expliquer pourquoi un dossier a été orienté vers une action donnée.
Les cas d’usage les plus solides reposent sur des critères bornés
Gemini Decisions semble surtout adapté aux situations où l’entreprise connaît à l’avance les options possibles et les règles d’escalade. Le modèle évalue alors une question définie par le développeur au lieu de devoir inventer la structure de la décision.
Contrats et conformité documentaire
Un service juridique peut analyser un contrat selon une grille comportant plusieurs centaines de critères : présence d’une clause de résiliation, limitation de responsabilité, obligation d’assurance ou exigence de conservation. Chaque critère peut renvoyer une option, une probabilité et un score de confiance.
La sortie peut ensuite alimenter un circuit de revue. Les dossiers présentant un score élevé et une confiance suffisante peuvent être classés automatiquement, tandis que les cas ambigus sont transmis à un juriste. La décision finale reste alors inscrite dans un processus gouverné plutôt que confiée à une sortie textuelle isolée.
Assurance et gestion des sinistres
Des images, des vidéos et des pièces justificatives peuvent être évaluées avec une même série de questions. L’application peut rechercher des éléments visuels, vérifier la présence de documents et estimer si un dossier respecte des critères de traitement automatique.
Ce cas d’usage exige une attention particulière aux erreurs asymétriques. Refuser à tort un sinistre et accepter à tort une demande ne produisent pas les mêmes conséquences financières ou réglementaires. Les seuils de confiance doivent donc être calibrés séparément selon le type de décision.
Contrôle qualité industriel
Une entreprise industrielle peut appliquer plusieurs contrôles à une image ou à une séquence vidéo : défaut visible, pièce manquante, position incorrecte ou anomalie de surface. Le regroupement des questions réduit la multiplication des appels lorsque les critères portent sur la même capture.
L’intégration doit néanmoins tenir compte de la qualité des capteurs, de l’éclairage, de l’angle de prise de vue et de la dérive des équipements. Le modèle ne peut pas corriger une donnée d’entrée systématiquement dégradée sans risque de baisse de fiabilité.
Service client et opérations
Une interaction peut être classée selon le motif, le niveau d’urgence, la présence d’informations sensibles et l’éligibilité à une procédure automatisée. L’entreprise peut ainsi orienter le dossier vers la bonne équipe sans demander au modèle de rédiger immédiatement une réponse complète.
Cette séparation entre classification et génération permet de limiter le rôle du modèle. La génération d’un message client peut rester soumise à un autre contrôle, à des modèles approuvés et à des règles de conformité.
Les scores de confiance ne valent pas une preuve de fiabilité
Gemini Decisions renvoie des probabilités et des scores de confiance, mais ces indicateurs ne constituent pas automatiquement une mesure fiable de la probabilité d’erreur. Une confiance élevée peut accompagner une mauvaise classification si le contenu sort du périmètre couvert par les données de test.
La calibration doit donc être mesurée sur des exemples représentatifs de la production. Une entreprise doit comparer les scores annoncés avec les résultats réellement vérifiés par des experts, puis déterminer quels seuils déclenchent une automatisation, une vérification supplémentaire ou un refus de décision automatique.
Un programme d’évaluation robuste inclut plusieurs dimensions :
- précision globale sur un échantillon représentatif ;
- taux de faux positifs et de faux négatifs ;
- performance par catégorie de client ou de document ;
- stabilité selon la langue, la qualité du fichier et le format ;
- évolution des résultats après modification des questions et des critères.
Les questions elles-mêmes influencent fortement le résultat. Une formulation ambiguë, des options qui se recouvrent ou une grille mal ordonnée peuvent dégrader la décision sans que le problème vienne du modèle. La conception des critères devient ainsi une compétence métier à part entière.
À retenir : la confiance affichée par une API doit être comparée à des décisions vérifiées sur le terrain. Sans calibration, elle ne suffit pas à autoriser une automatisation complète.
Gemini Decisions et OpenAI ne jouent pas exactement sur le même volume
OpenAI propose une offre concurrente qui accepte jusqu’à 400 questions par requête. Gemini Decisions porte cette limite à 1 000 questions, soit 2,5 fois plus de critères regroupés dans un appel lorsque les deux services sont comparés sur ce seul paramètre.
| Critère | Gemini Decisions | API Decisions d’OpenAI |
|---|---|---|
| Questions maximales par requête | 1 000 | 400 |
| Entrée commune multimodale | Oui | Oui |
| Images dans les instructions | Oui | Oui |
| Résultat principal | Options, probabilités et confiance | Évaluation des questions |
| Positionnement | Décisions multimodales à grande échelle | Décisions groupées à grande échelle |
Cette différence ne suffit pas à désigner un gagnant pour tous les projets. Le choix dépend aussi des modèles déjà utilisés, des outils de supervision, des exigences de localisation des données, des mécanismes de journalisation et des performances observées sur les données de l’entreprise.
La capacité maximale est surtout utile lorsque les critères sont nombreux et que le contexte est partagé. Une équipe qui pose dix questions par document n’exploitera pas pleinement l’écart entre 400 et 1 000. À l’inverse, un programme de conformité comportant plusieurs centaines de contrôles peut bénéficier d’un regroupement plus large.
Les tests doivent porter sur un jeu de données identique et sur des critères identiques. Comparer uniquement le prix affiché ou le nombre maximal de questions risque de masquer des différences de précision, de calibration, de latence et de qualité des intégrations.
L’architecture d’entreprise doit encadrer chaque décision automatisée
L’arrivée d’une API spécialisée ne réduit pas les obligations de gouvernance. Elle peut au contraire accélérer la propagation d’une erreur si une même règle mal définie est appliquée à des milliers de dossiers.
Le premier contrôle concerne la traçabilité. Chaque décision devrait conserver le contenu évalué, la version des questions, les options proposées, les scores retournés, le seuil appliqué et l’action déclenchée. Sans ces éléments, une équipe aura du mal à expliquer ou à corriger un classement contesté.
Le deuxième concerne l’accès aux données. Les PDF, images, enregistrements audio et vidéos peuvent contenir des informations personnelles ou confidentielles. Les entreprises doivent limiter les données transmises, définir des durées de conservation et séparer les environnements de test, de préproduction et de production.
Le troisième concerne l’escalade humaine. Une faible confiance, une contradiction entre critères ou une catégorie sensible doivent pouvoir interrompre l’automatisation. Le système doit prévoir une file de revue, et non simplement enregistrer un score sans action corrective.
Un déploiement responsable peut suivre ce circuit :
- définir les décisions autorisées et celles qui restent humaines ;
- créer un jeu de référence annoté par des spécialistes ;
- mesurer la précision et les erreurs par catégorie ;
- fixer des seuils distincts selon le risque ;
- journaliser les entrées, les critères et les sorties ;
- surveiller la dérive après la mise en production ;
- réévaluer le modèle lorsque les documents ou les règles métier changent.
Cette discipline est particulièrement importante dans les secteurs réglementés. Une API peut fournir une évaluation technique, mais elle ne détermine pas à elle seule si l’entreprise est autorisée à prendre une décision entièrement automatisée.
Notre avis : Gemini Decisions mérite un pilote, pas un blanc-seing
Gemini Decisions apporte une proposition claire : traiter jusqu’à 1 000 questions sur un même contexte multimodal, avec une facturation d’entrée de 0,10 dollar par million de tokens et une latence annoncée de 150 à 250 millisecondes sur des contextes allant jusqu’à 16 000 tokens. Pour les opérations de tri, de conformité et de contrôle qualité, le regroupement des critères peut simplifier l’architecture et réduire les appels répétitifs.
Notre recommandation est nette : les entreprises devraient tester Gemini Decisions sur un périmètre borné, avec des décisions réversibles et un échantillonnage humain systématique. L’API ne doit pas être introduite directement dans un processus à fort impact simplement parce qu’elle est rapide ou peu coûteuse.
Au cours des six prochains mois, l’enjeu principal sera la qualité des évaluations en conditions réelles : documents longs, entrées multimodales imparfaites, critères ambigus et variations entre populations. Les équipes qui construiront dès maintenant un jeu de référence, une journalisation complète et des seuils d’escalade disposeront d’un avantage concret lorsque ces modèles entreront dans des workflows plus sensibles.
La question décisive ne sera donc pas le nombre maximal de questions par requête, mais la capacité de chaque entreprise à prouver qu’une décision automatisée reste exacte, contrôlable et contestable.