Google ajoute les modes Flex et Priority à l'API Gemini pour concilier prix et fiabilité

Le 2 avril 2026, Google a ajouté deux nouveaux modes de service à l'API Gemini, Flex et Priority, afin que les développeurs puissent piloter plus finement le prix, la latence et la fiabilité sans compliquer leur architecture. L'idée : les requêtes de fond et les requêtes critiques côté utilisateur peuvent désormais être réparties sur différents niveaux de service via la même interface synchrone, plutôt que de bâtir des circuits distincts pour l'API Standard et l'API Batch.

L'entreprise décrit le problème de manière assez terre à terre. À mesure que les usages de l'IA passent des simples chatbots aux agents et aux workflows composites, les équipes se retrouvent généralement avec deux classes de charge. La première regroupe les tâches de fond : enrichissement massif de données, longs raisonnements du modèle, campagnes de recherche, mises à jour de CRM et autres processus pour lesquels quelques secondes de plus importent peu. La seconde concerne les requêtes interactives : chats utilisateurs, copilotes, modération en temps réel, bots de support et autres fonctions qui demandent une réponse stable et une latence prévisible.

Jusqu'ici, cette séparation obligeait souvent à combiner des requêtes synchrones classiques côté produit avec l'API Batch pour un traitement de fond peu coûteux. Cela faisait économiser de l'argent, mais ajoutait de la charge : il fallait gérer des tâches asynchrones, des fichiers d'entrée et de sortie, ainsi que l'interrogation régulière de l'état d'exécution. Google affirme que Flex et Priority comblent cet écart : les deux options passent par des endpoints synchrones standard, et la bascule se fait via le paramètre `service_tier` de la requête.

Flex est un nouveau mode économique pour les tâches qui tolèrent le délai et une priorité d'exécution plus basse. Google promet jusqu'à 50 % d'économies par rapport à l'API Standard, si le développeur accepte de sacrifier une part de fiabilité et de vitesse de réponse au profit du coût. Le point clé : Flex ne transforme pas le travail en processus batch distinct, il reste une requête synchrone avec le schéma d'intégration habituel.

L'entreprise suggère de l'utiliser pour des mises à jour de CRM en arrière-plan, des simulations de recherche à grande échelle et des scénarios d'agents où le modèle peut « réfléchir » ou « parcourir » des informations en tâche de fond. Selon Google, Flex sera disponible sur tous les forfaits payants et pris en charge dans les requêtes GenerateContent et Interactions API.

Priority, à l'inverse, vise le trafic le plus sensible. C'est un mode premium offrant le plus haut niveau de garantie, censé aider les applications à traverser les pics de charge sans que les requêtes critiques soient évincées. Google affirme sans détour que ces requêtes reçoivent le plus haut niveau de criticité, ce qui augmente les chances de maintenir un fonctionnement stable même quand la plateforme est chargée.

Autre détail important : un mécanisme de dégradation en douceur. Si l'application dépasse les limites de Priority, les requêtes excédentaires n'échouent pas avec une erreur, mais sont automatiquement servies au niveau Standard. En production, cela peut compter davantage que le SLA lui-même, car cela réduit le risque de dégradation totale d'une fonction lors d'un afflux d'utilisateurs.

Google rend en outre Priority plus transparent pour l'exploitation et la facturation. La réponse de l'API indiquera quel niveau a réellement traité chaque requête, ce qui permettra à l'équipe d'analyser le comportement du système, de calculer les coûts et de suivre les scénarios réels de dégradation. Parmi les cas d'usage typiques, l'entreprise cite les bots de support en temps réel, les pipelines de modération en direct et toute requête sensible au temps. Au lancement, Priority sera disponible pour les projets payants de niveaux Tier 2 et Tier 3 dans la GenerateContent API et l'Interactions API.

Pour les développeurs, cette mise à jour importe pour d'autres raisons que les tarifs. Google tente en pratique de simplifier le choix d'ingénierie entre « pas cher » et « fiable », sans obliger les équipes produit à construire deux modèles d'intégration différents. Si Flex tient réellement ses 50 % d'économies sur les tâches de fond sans passer à une architecture batch, il pourrait rendre moins coûteux les scénarios d'agents et les pipelines massifs. Et si Priority parvient à tenir durablement le trafic critique aux heures de pointe, l'API Gemini disposera d'un argument plus solide pour les produits grand public où les pannes affectent directement les revenus et l'expérience utilisateur.

L'essentiel tient en peu de mots : Google fait de l'API Gemini, jusqu'ici un canal standard unique, un système plus souple de classes de service. Pour les équipes, cela signifie pouvoir séparer délibérément la charge de fond et la charge critique sur une même API, mieux calculer l'économie unitaire et traverser plus sereinement les périodes de pointe. Si l'approche s'impose, la concurrence entre plateformes d'IA se jouera de plus en plus non seulement sur la qualité des modèles, mais aussi sur la finesse avec laquelle le fournisseur sait vendre performance, fiabilité et coût selon les scénarios produit.