Google a rendu obsolète deux slugs Gemini Flash API et achemine automatiquement le trafic de chaque ancien nom vers un remplacement plus récent, créant ainsi une légère modification du catalogue de modèles avec des conséquences plus importantes sur les passerelles, les analyses et les rapports clients.
Selon les notes de version Gemini API de Google datées du 8 octobre 2026, gemini-3.7-flash est obsolète et remplacé par gemini-3.8-flash. Les requêtes envoyées au slug Flash 3.7 obsolète sont automatiquement acheminées vers Flash 3.8. Google a également obsolète gemini-3.5-flash, en le remplaçant par gemini-3.6-flash et le même comportement de reroutage automatique.
La société a également abandonné deep-research-pro-preview-12-2025 et indique que l'agent Deep Research sera fermé le 23 octobre 2026, avec des chemins de migration vers des agents Deep Research plus récents. Cela donne aux équipes une courte fenêtre pour identifier l'utilisation en production, modifier les ID épinglés et vérifier le comportement de sortie avant que l'ancien point de terminaison d'aperçu ne disparaisse.
Ce qui a changé dans le Gemini API
Le changement opérationnel immédiat est simple : une requête peut nommer un modèle tandis que Google en sert un autre. Ce n'est pas la même chose qu'un développeur modifiant délibérément une application de gemini-3.7-flash à gemini-3.8-flash. Il s'agit d'une substitution côté fournisseur.
Pour les candidatures simples, la différence peut être invisible si les réponses restent acceptables. Pour les équipes qui effectuent des évaluations, des analyses orientées client, des flux de travail réglementés ou l'attribution des coûts, cela est important. Une entrée de journal qui enregistre uniquement le modèle demandé peut donner l’impression qu’un modèle obsolète gère toujours le trafic. Un tableau de bord qui enregistre uniquement le modèle servi peut masquer le fait que les clients continuent de traiter de vieux slug. Les deux vues sont incomplètes.
C'est là que les alias de modèles d'IA deviennent plus que de simples commodités pour les développeurs. Les passerelles doivent distinguer au moins trois cas : un alias de client stable créé par la plate-forme, un alias de fournisseur qui flotte intentionnellement et un itinéraire de dépréciation de fournisseur qui mappe silencieusement un ancien identifiant de modèle public à un nouveau. Traiter les trois comme le même champ crée des analyses ambiguës.
Pourquoi le réacheminement automatique est utile mais risqué
Le réacheminement automatique réduit la casse immédiate. Si un client a codé en dur gemini-3.7-flash, la route de remplacement de Google peut maintenir les requêtes en cours d'exécution pendant que l'équipe met à jour la configuration. Il s'agit d'un choix pratique de continuité de service, en particulier pour les applications dans lesquelles les ID de modèle sont répartis entre des scripts, des intégrations de partenaires, des invites ou des paramètres client.
Le compromis est la perte de contrôle explicite. Un remplacement de modèle peut modifier la latence, le style de sortie, le comportement de sécurité, les modèles d'utilisation des outils ou la fiabilité des cas extrêmes, même si l'appel API réussit toujours. Les développeurs peuvent ne pas remarquer le changement jusqu'à ce qu'une évaluation dérive, qu'une invite se comporte différemment ou qu'un client demande pourquoi l'utilisation signalée ne correspond plus à la documentation.
Le risque est plus élevé pour les plates-formes qui exposent Google modèles via une passerelle multimodèle API pour les équipes. Ces produits se situent entre le fournisseur et l’utilisateur final, ils doivent donc décider dans quelle mesure le comportement de routage du fournisseur doit être mis en évidence. Une passerelle qui transmet simplement l'ancien slug et facture l'appel résultant comme d'habitude peut préserver la compatibilité, mais elle laisse aux équipes d'assistance et financières une piste d'audit faible.
Quelles passerelles et plateformes de revendeurs doivent enregistrer
Le modèle le plus propre consiste à stocker le modèle demandé, le modèle de fournisseur résolu et la règle d'alias qui a provoqué la résolution. Pour le changement Gemini Flash, cela signifie qu'un enregistrement d'utilisation doit pouvoir montrer que le client a demandé gemini-3.7-flash, Google a servi gemini-3.8-flash, et que la raison était la redirection obsolète de Google plutôt qu'une règle de secours définie par le client.
Cette distinction affecte la prise en charge de la facturation, la planification de la migration et la confiance dans les produits. Si un client demande si son application utilise toujours un modèle obsolète, la réponse ne devrait pas nécessiter une archéologie manuelle des journaux. Si un revendeur doit notifier les comptes en aval, il doit pouvoir segmenter par slug hérité demandé. Si une suite d'évaluation interne commence à échouer, les ingénieurs devraient être en mesure de comparer les résultats avant et après le changement de modèle servi sans deviner à quel moment le trafic s'est déplacé.
Pour les produits de style Model Gate, le travail pratique concerne l'analyse de l'utilisation et les rapports clients. Un tableau de bord d'analyse de l'utilisation doit éviter de regrouper les modèles demandés et servis en une seule étiquette. Cela devrait également rendre les identifiants obsolètes suffisamment visibles pour que les propriétaires de comptes puissent pousser les migrations avant la fin du support du fournisseur.
L'arrêt de l'agent Deep Research ajoute un deuxième type de délai. Contrairement à une redirection Flash, Google indique que deep-research-pro-preview-12-2025 s'arrêtera le 23 octobre 2026. Les équipes utilisant cet agent en version préliminaire doivent migrer plutôt que de s'appuyer sur un routage de compatibilité indéfini. Étant donné que les workflows Deep Research peuvent être intégrés dans des pipelines de recherche ou d'automatisation de plus longue durée, la vérification de la migration doit inclure des invites, des hypothèses sur les outils, des formats de sortie et toutes les listes autorisées de modèles stockés.
Ce qui reste incertain
Les notes de version deGoogle identifient les slugs, les remplacements et le comportement de reroutage obsolètes, mais elles ne règlent pas toutes les questions opérationnelles pour les plates-formes en aval. Les notes ne fournissent pas de comparaison comportementale générale entre les anciens modèles Flash et les modèles Flash de remplacement dans l'entrée du journal des modifications citée. Ils n'indiquent pas non plus de date d'arrêt pour les slugs Flash obsolètes de la même manière qu'ils le font pour l'agent de préversion Deep Research.
Cela laisse les équipes avec un API problème de gestion familier : la compatibilité peut continuer pour le moment, mais l'état stable est toujours la migration. Les développeurs doivent mettre à jour les sélections de modèles explicites, réexécuter les évaluations critiques par rapport aux ID de remplacement et s'assurer que les journaux conservent suffisamment de détails pour expliquer ce qui s'est passé pendant la transition.
La leçon plus large est que les identifiants de modèle ne sont plus de simples noms de produits. Il peut s'agir de versions stables, d'alias mobiles, de cales de compatibilité ou de pièges de dépréciation. Les passerelles qui souhaitent offrir aux clients un contrôle fiable ont besoin d'un modèle de données capable de représenter directement ces différences.