Dépréciation de Gemini 2.5 : la checklist à suivre avant le routage automatique du 1er décembre

La dépréciation de Gemini 2.5 prend effet le 1er décembre 2026. À cette date, les appels à gemini-2.5-pro et gemini-2.5-flash commencent à être routés automatiquement vers d'autres modèles. La plupart des requêtes continueront d'aboutir, et c'est précisément pour cela qu'il faut s'y intéresser dès maintenant.

Ce guide présente ce que Google a annoncé, l'impact sur la facture, les paramètres à réécrire et la manière de décider, charge de travail par charge de travail, s'il faut accepter la redirection ou épingler un modèle de façon délibérée. Si vous utilisez Gemini sur Vertex AI, lisez d'abord la section qui lui est consacrée. Sa date de retrait est déjà passée.

Ce que Google a annoncé et ce qui change réellement le 1er décembre

Les notes de version de l'API Gemini, publiées le 2 novembre 2026, indiquent que les appels à gemini-2.5-pro seront routés automatiquement vers gemini-3.8-flash, et les appels à gemini-2.5-flash vers gemini-3.5-flash-lite. Ces notes fixent au 1er décembre 2026 le début de ce routage. À partir de cette date, toute requête API qui nomme encore l'un de ces modèles recevra une réponse d'un autre modèle, plus récent, et sera facturée au tarif de ce dernier.

Le périmètre est plus étroit que le titre ne le laisse penser. La page des dépréciations de Gemini précise que gemini-2.5-flash-lite n'est pas déprécié et reste disponible jusqu'à nouvel ordre. Seuls deux identifiants de modèle sont concernés.

Le problème pratique, c'est qu'en général rien ne renvoie d'erreur. Un autre modèle qui répond discrètement à la place du vôtre peut passer inaperçu.

Pourquoi une redirection silencieuse est plus risquée qu'une erreur

Du point de vue de Google, la redirection est un choix par défaut raisonnable, car les équipes qui n'ont pas vu l'annonce restent en ligne. Cela signifie aussi que la qualité des sorties, la latence, la consommation de tokens et le coût peuvent changer alors que personne n'a touché au code côté client.

Les mainteneurs de la bibliothèque open source llm-exe ont soulevé ce point dans une issue GitHub : les appels continuent d'aboutir, mais les utilisateurs de gemini-2.5-pro obtiennent un modèle de niveau Flash sans le moindre avertissement. Ils y voient une véritable perte de capacités et estiment que c'est « pire qu'une 404, car personne ne s'en rendra compte ».

Google laisse certaines questions en suspens. Son annonce n'explique pas pourquoi 2.5 Pro est associé à un modèle Flash plutôt qu'à un niveau supérieur, et ne dit pas si les clients peuvent refuser le routage automatique.

Nous suggérons de traiter la bascule comme un changement de modèle que votre équipe n'a pas choisi, et de l'examiner comme une mise à niveau planifiée, avec une passe d'évaluation, une vérification des coûts et la validation d'un responsable.

Les coûts : moins chers en décembre, différents à partir de janvier 2027

L'article de lancement de Gemini 3.8 Flash par Google annonce un prix de lancement de $0.75 par 1M de tokens en entrée et de $3.75 par 1M de tokens en sortie jusqu'au 31 décembre 2026. Gemini 2.5 Pro coûte $1.25 et $10.00 pour les prompts jusqu'à 200,000 tokens. À partir du 1er janvier 2027, les tarifs de 3.8 Flash doublent pour atteindre $1.50 et $7.50. À ces tarifs, l'entrée coûte plus cher que sur 2.5 Pro, même si la sortie reste moins chère.

Deux charges de travail à titre d'illustration

Une analyse tierce de Data Studios détaille deux exemples de charges de travail. Il ne s'agit ni de benchmarks ni de mesures d'Optijara.

Dans l'exemple de l'assistant de support, la facture mensuelle passe de $9,300 à $4,500 en décembre, puis remonte à $9,000 à partir de janvier 2027. Les volumes de tokens qui sous-tendent ces totaux figurent dans l'analyse de Data Studios : vérifiez-les à la source avant de les comparer à votre propre trafic.

La ligne des documents longs indique ses hypothèses, ce qui permet de la recalculer à partir du tableau des prix. Elle atteint $810 sur 2.5 Pro, car chaque prompt tombe dans la tranche plus chère des contextes longs. Sur 3.8 Flash, elle coûte $240 en décembre et $480 à partir de janvier, car 3.8 Flash n'applique aucun supplément pour les contextes longs.

Le nombre de tokens compte plus que leur prix

L'article de lancement de Google indique que 3.8 Flash peut consommer davantage de tokens pour maximiser ses performances, en particulier aux niveaux d'effort élevés. Un volume plus important peut absorber tout ou partie de la baisse du prix par token. Mesurez le nombre réel de tokens sur votre propre trafic avant de vous fier à un tableur, y compris aux exemples ci-dessus.

Les changements de paramètres qui cassent ou modifient silencieusement le comportement

thinking_budget devient thinking_level

Les modèles Gemini 3.x utilisent thinking_level au lieu de thinking_budget. Gemini 3.8 Flash accepte les niveaux low, medium et high, et la documentation de Google sur le modèle 3.8 Flash indique que minimal renvoie une erreur. Vérifiez la formulation actuelle dans le changelog de l'API Gemini et sur la page du modèle.

C'est l'un des rares cas où une requête redirigée peut échouer purement et simplement : contrôlez donc tout code, toute configuration ou tout wrapper qui définit minimal ou s'y rattache. Nous suggérons aussi de tester le comportement d'une valeur thinking_budget restée en place sur une requête redirigée.

Les paramètres d'échantillonnage sont en voie de disparition

Les consignes de migration de Google demandent aux développeurs de supprimer temperature, top_p et top_k. Ces paramètres sont dépréciés, ignorés aujourd'hui, et renverront une erreur HTTP 400 dans les générations futures. Supprimez aussi candidate_count, que Gemini 3 et les versions ultérieures ne prennent pas en charge. Consultez le changelog de l'API Gemini et la page des dépréciations avant de modifier le code.

Le sujet ne se limite pas à la redirection. La documentation de l'API Gemini confirme que ces paramètres d'échantillonnage sont ignorés sur Gemini 3.6 Flash, Gemini 3.5 Flash-Lite et Gemini 3.5 Flash Cyber. Si vous appelez ces modèles, certains de vos réglages n'ont peut-être déjà plus aucun effet. Un workflow qui comptait sur une température basse pour obtenir des sorties régulières a perdu ce levier : testez donc directement la régularité des résultats.

Le passage de 2.5 Flash à 3.5 Flash-Lite

Nous suggérons de distinguer ce qui est documenté sur ce chemin de ce que votre équipe doit encore tester ou vérifier.

• Connu : limites de sortie. Gemini 3.5 Flash-Lite, le remplaçant de 2.5 Flash, dispose d'une fenêtre de contexte de 1M de tokens et prend en charge jusqu'à 64,000 tokens de sortie. Vérifiez que vos réglages de sortie maximale et votre logique de découpage sont compatibles.
• Connu : paramètres d'échantillonnage. Déjà ignorés sur 3.5 Flash-Lite, comme indiqué plus haut.
• À tester : niveaux de réflexion. Nous suggérons de tester chaque valeur de thinking_level que vous comptez envoyer, minimal compris.
• À vérifier : coût. Nous suggérons de chiffrer ce chemin à partir des tarifs actuels publiés par Google.

Appel d'outils et de fonctions

L'appel d'outils mérite sa propre passe de tests. Nous suggérons de retester de bout en bout chaque flux d'appel d'outils sur le modèle cible, en couvrant la sélection des outils, le formatage des arguments, l'état sur plusieurs tours et la gestion des erreurs. Les équipes jugeront peut-être plus prudent de considérer le comportement antérieur comme non vérifié tant que ces tests ne sont pas passés.

Plan d'action : une checklist de migration Gemini 2.5 en sept étapes

Nous suggérons d'attribuer à chaque étape un responsable et une date cible en amont de la bascule.

• [ ] Étape 1, inventaire. Recherchez gemini-2.5-pro et gemini-2.5-flash dans le code, la configuration, les variables d'environnement, les modèles d'infrastructure et les wrappers de SDK, y compris dans les valeurs par défaut des bibliothèques tierces et des frameworks d'agents. Excluez gemini-2.5-flash-lite.
• [ ] Étape 2, classification. Étiquetez chaque appel selon son risque métier (exposé aux clients, fort en raisonnement, appel d'outils, batch, contexte long) et désignez un responsable.
• [ ] Étape 3, réécriture des paramètres. Remplacez thinking_budget par thinking_level (low, medium ou high ; pas de minimal sur 3.8 Flash). Testez chaque niveau sur 3.5 Flash-Lite. Supprimez temperature, top_p, top_k et candidate_count.
• [ ] Étape 4, nouveaux tests. Exécutez un jeu d'évaluation fixe et vos flux d'appel d'outils sur le modèle cible, en comparant la qualité, la latence et la consommation de tokens à une référence établie sur le modèle actuel.
• [ ] Étape 5, modèle de coûts. Chiffrez la consommation de tokens mesurée pour chaque chemin.
• [ ] Charges de travail 2.5 Pro : aux tarifs 3.8 Flash de décembre 2026, puis aux tarifs de janvier 2027.
• [ ] Anciennes charges de travail Flash : nous suggérons de les chiffrer à partir des tarifs actuels publiés par Google pour le modèle cible.
• [ ] Étape 6, décision. Épinglez chaque charge de travail sur un identifiant de modèle explicite, ou consignez par écrit que vous acceptez la cible de la redirection.
• [ ] Étape 7, supervision après le 1er décembre. Journalisez l'identifiant de modèle demandé ainsi que toute métadonnée de modèle ou de version renvoyée par la réponse, et déclenchez une alerte en cas d'écart. L'identifiant demandé ne suffit pas à révéler une redirection. Suivez les tokens et les dépenses, et surveillez la mise en cache, car Google n'a pas documenté le comportement des réponses ou des caches en cas de redirection.

Pour l'étape 7, des traces par requête qui enregistrent le modèle demandé, le modèle signalé, le nombre de tokens et la latence font rapidement apparaître toute dérive. Notre playbook de traçage OpenTelemetry GenAI peut constituer un point de départ utile pour ce type de traçage.

Épingler à dessein ou accepter la redirection : la revue à trois curseurs

Nous appelons Revue à trois curseurs notre cadre pour cette décision. Attribuez à chaque charge de travail une note faible, moyenne ou élevée sur chaque curseur.

• Risque. Qui voit la sortie, et que se passe-t-il en cas d'erreur ? Les réponses destinées aux clients, les contenus réglementés et les appels d'outils qui modifient des données obtiennent une note élevée.
• Dépendance au raisonnement. Avez-vous choisi 2.5 Pro pour son raisonnement en plusieurs étapes, ou est-il simplement devenu le choix par défaut ?
• Sensibilité au coût. Quelle part de vos dépenses Gemini cette charge de travail représente-t-elle, et à quelle vitesse augmente-t-elle ?

Si le risque ou la dépendance au raisonnement est élevé, nous suggérons de tester d'abord, puis d'épingler explicitement le modèle qui réussit les tests. Si les deux sont faibles et que la sensibilité au coût est élevée, accepter la cible de la redirection est raisonnable, mais épinglez-la tout de même explicitement. Les notes mitigées passent par une évaluation, les tarifs de janvier servant à départager. Les charges de travail à contexte long méritent un examen attentif, puisque l'exemple ci-dessus montre encore des économies après le changement de janvier.

L'article de lancement de Google précise également que, lorsque l'efficacité de calcul est la principale contrainte, les développeurs peuvent utiliser des niveaux d'effort plus bas ou continuer à utiliser Gemini 3.7 Flash, qui reste entièrement pris en charge pour les charges de travail axées sur l'efficacité. Si l'efficacité est votre principale contrainte, nous suggérons d'inclure ce modèle dans votre évaluation comme option d'épinglage.

Google annonce un score de 54.9% pour 3.8 Flash sur HLE-Verified. C'est un élément de contexte communiqué par le fournisseur, pas la preuve que le modèle convient à votre tâche. Nous suggérons de laisser votre propre jeu d'évaluation trancher, et notre article expliquant pourquoi les scores de benchmark ont besoin de protocoles propose d'aller plus loin sur la manière d'interpréter les chiffres mis en avant.

Nous suggérons d'épingler explicitement, même lorsque vous choisissez le modèle que la redirection aurait retenu. Un épinglage transforme un choix par défaut du fournisseur en décision documentée, que l'équipe peut réexaminer à mesure que les prix évoluent. Si votre trafic passe par une passerelle, envisagez d'imposer des épinglages de modèle explicites au niveau de la passerelle afin qu'une valeur par défaut oubliée dans un service ne puisse pas les contourner.

Vertex AI : la date de retrait est déjà passée

Le tableau du cycle de vie de Vertex indique le 20 octobre 2026 comme date de retrait de gemini-2.5-pro et de gemini-2.5-flash. Cette date est derrière nous. Les appels Vertex AI qui nomment encore l'un de ces modèles échouent peut-être déjà ou sont peut-être servis par un autre modèle : vérifiez donc les journaux et les taux d'erreur de cette semaine pour ces identifiants avant de passer à l'API Developer.

Vertex AI documente le cycle de vie de ses modèles séparément de l'API Gemini Developer. Google indique que, lorsqu'il programme le retrait d'un modèle sur cette plateforme, il publie une date fixe qui vous laisse au moins 45 jours pour migrer. Les remplaçants suggérés diffèrent également : gemini-3.8-flash ou gemini-3.5-flash pour Pro, et gemini-3.8-flash ou gemini-3.5-flash-lite pour Flash. L'annonce de redirection de Google ne précise pas comment le changement du 1er décembre s'applique à Vertex AI. Si vous utilisez les deux environnements, examinez chacun selon ses propres règles.

Les erreurs courantes des équipes pendant cette migration

• Établir la référence trop tard. Après le 1er décembre, un appel à gemini-2.5-pro via l'API Gemini n'atteint plus 2.5 Pro.
• Oublier les valeurs par défaut dans la CI et les fixtures de test. Nous suggérons de vérifier les fixtures, les mocks, les smoke tests et les configurations de préproduction à la recherche d'identifiants de modèle codés en dur.
• Laisser les caches et les évaluations indexés sur les anciens identifiants. Tout ce qui est indexé sur la chaîne du modèle risque de mélanger d'anciens résultats et des résultats redirigés sous un même libellé. Réindexez ces éléments, ou marquez la date de bascule.
• Calibrer les alertes budgétaires pendant le mois de décembre. Des seuils fixés sur les dépenses de décembre sous-estimeront celles de janvier, lorsque les tarifs de 3.8 Flash doubleront.
• Migrer les mauvais appels, ou passer à côté des appels cachés. gemini-2.5-flash-lite n'est pas déprécié, et les identifiants concernés peuvent se cacher dans des wrappers tiers que la recherche dans votre dépôt ne trouvera pas.

Réserves et questions ouvertes

Google n'a pas indiqué si les réponses signaleront qu'une requête redirigée a été servie par le modèle de remplacement. Google n'a pas non plus précisé ce qu'il adviendra des caches de contexte explicites créés sur les modèles Gemini 2.5, et aucune option de refus n'est annoncée.

Les scénarios de coûts présentés ici proviennent d'une analyse tierce fondée sur des charges de travail illustratives. Votre répartition de trafic, la longueur de vos prompts et vos réglages d'effort produiront des chiffres différents. Les résultats de benchmark sont communiqués par le fournisseur. Les prix et la documentation peuvent évoluer : nous suggérons donc de revérifier le changelog officiel et les pages de dépréciation avant d'agir.

Si un regard extérieur peut vous être utile, Optijara peut réaliser un audit de migration de vos appels Gemini ou vous aider à construire la référence d'évaluation qui servira de point de comparaison.