Google a annoncé le retrait de Gemini 2.5 Flash, et les développeurs qui ont construit dessus demandent de garder le modèle en ligne plus longtemps. Une discussion sur le forum officiel de Google AI a reçu un soutien immédiat (120 points sur Hacker News, 80 commentaires) : ceux qui utilisent 2.5 Flash en production rapportent que les modèles plus récents de la famille ne font pas le poids sur leurs cas d’usage.

Les benchmarks internes des développeurs montrent que Gemini 3 Flash ne maintient pas les mêmes performances, même après avoir adapté les prompts aux nouvelles directives. Pour certains workflows, le modèle suivant coûte trois fois plus cher, pour d’autres il arrive trop tard (600-700ms contre les 300-400ms de 2.5 Flash en Australie, où 3.5 Flash n’a pas de déploiement local). La faible latence n’est pas un caprice : en dessous de 400ms, un agent vocal fonctionne, au-delà ça casse.

Pourquoi ça te concerne. Si tu construis sur des API tierces, cette histoire est le rappel qu’il te faut : les modèles que tu utilises aujourd’hui peuvent disparaître demain, et le remplaçant officiel peut ne pas faire ton travail. La communauté demande la continuité, mais la décision n’est pas la leur. Si une partie critique de ton système dépend d’un modèle spécifique, tu dois avoir un plan B testé prêt, pas juste l’espoir que le fournisseur change d’avis.

En détail

Ce qu’il y avait avant

Gemini 2.5 Flash a été pendant des mois le modèle de référence pour ceux qui cherchaient un équilibre entre qualité, latence et coût : assez capable pour les tâches complexes, assez rapide pour les agents vocaux, assez économique pour les gros volumes. Pas le plus puissant de la famille, mais le plus fiable pour les charges qui demandent de la cohérence plutôt que des pics d’intelligence.

Beaucoup de teams l’ont choisi pour ça : un modèle qui fait bien une chose et la fait toujours de la même manière est plus facile à orchestrer qu’un modèle brillant mais imprévisible. Ils l’ont mis en production, ont calibré les prompts, ont construit des pipelines qui dépendent de sa latence et de son coût.

Ce qui change

Google a annoncé le retrait sans proposer un remplaçant qui maintienne le même ratio qualité/latence/coût. Gemini 3 Flash ne suit pas dans les tests des utilisateurs, et 3.5 Flash coûte trois fois plus cher. Pour ceux qui travaillent dans des régions où le déploiement local compte (l’Australie en particulier), la latence double ou triple, rendant le modèle inutilisable pour les cas d’usage en temps réel.

La communauté demande à Google d’allonger la vie du modèle, au moins jusqu’à ce qu’un vrai remplaçant soit disponible. La demande est raisonnable, mais rien ne garantit qu’elle sera acceptée : les roadmaps des fournisseurs de modèles suivent des logiques internes qui coïncident rarement avec les calendriers de production des utilisateurs.

Implications pour ceux qui construisent

Cette histoire est un cas d’école sur un risque que beaucoup minimisent : la stabilité des modèles n’est pas garantie. Une API peut disparaître, un modèle peut être retiré, un prix peut changer. Si ton système dépend d’un modèle spécifique sans alternatives testées, tu as une dépendance critique non documentée.

Comme on l’a raconté quand Zuckerberg a admis que les agents vont plus lentement que prévu, le rythme de développement des fournisseurs ne coïncide pas toujours avec celui de ceux qui construisent des applications réelles. La pression pour livrer de nouveaux modèles peut mener à retirer les anciens avant que les remplaçants soient prêts pour tous les cas d’usage.

Quoi faire

Si tu utilises Gemini 2.5 Flash en production, tu as deux options :

1. Tester les alternatives tout de suite. Ne fais pas confiance aux benchmarks publics : prends tes vrais cas d’usage, ceux sur lesquels le modèle doit fonctionner chaque jour, et vérifie que le remplaçant proposé les gère. S’il ne les gère pas, c’est un problème à résoudre pour toi, pas pour Google.

2. Avoir un plan B avec un autre fournisseur. Pas par idéologie, mais parce que si un seul modèle est un point de rupture critique, tu dois savoir où aller s’il disparaît. Tester une alternative sur un autre provider (OpenAI, Anthropic, un modèle open-weight auto-hébergé) te donne une option réelle, pas juste du vœu pieux.

La leçon plus large : si tu construis sur des modèles tierces, évalue sans benchmarks tes cas d’usage spécifiques, et garde trace de quels modèles les gèrent vraiment. Il n’y a pas de substitut aux tests faits sur tes données.