Google a fait passer deux modèles en disponibilité générale : gemini-3.6-flash et gemini-3.5-flash-lite. Les deux sont désormais des points d'accès stables, et non plus des versions preview.

Ce qui change

Gemini 3.6 Flash apporte une meilleure efficacité en tokens ainsi que des capacités renforcées en code et en planification agentique, à un prix inférieur à celui du modèle qu'il remplace. Cette amélioration de l'efficacité en tokens compte plus qu'il n'y paraît : sur des exécutions agentiques longues, la facture dépend du nombre de tokens que le modèle consacre à « réfléchir », et non du prix affiché par million de tokens.

Gemini 3.5 Flash-Lite se positionne comme une option de sous-agent à faible latence et économique — le modèle que l'on appelle des milliers de fois au sein d'un système plus large, plutôt que celui auquel un utilisateur s'adresse directement.

Le changement majeur

Cette disponibilité générale s'accompagne d'un changement susceptible de casser du code existant : les paramètres d'échantillonnage temperature, top_p et top_k sont dépréciés pour les deux modèles. Tout code qui les utilise doit être révisé. Il s'agit d'un véritable changement de posture — ces trois réglages sont des standards des API génératives depuis leurs débuts, et leur suppression signifie que le modèle décide désormais lui-même de son comportement d'échantillonnage.

Pourquoi c'est important

Déprécier les contrôles d'échantillonnage revient à échanger la personnalisation utilisateur contre un contrôle accru du fournisseur. Pour la plupart des applications, les réglages par défaut convenaient déjà, et moins de réglages signifie moins de façons de mal configurer un déploiement. Pour les équipes qui avaient consacré un réel effort à ajuster la temperature selon leurs cas d'usage, ce travail est désormais obsolète.

Notable absent de cette sortie : Gemini 3.5 Pro, dont l'arrivée a maintenant dépassé plusieurs fenêtres attendues. Google a livré le niveau rapide et économique, laissant le modèle phare pour plus tard.

Que faire

Auditez tout chemin de code définissant temperature, top_p ou top_k pour ces deux modèles et prévoyez de le supprimer. Une dépréciation n'est pas une suppression immédiate, mais elle constitue un engagement, et des paramètres ignorés silencieusement sont pires que des erreurs explicites — la sortie change sans qu'aucune indication n'explique pourquoi.

Là où le déterminisme compte réellement, la solution de remplacement est structurelle plutôt que paramétrique : contraindre le format de sortie, valider ce qui est renvoyé, et relancer en cas d'échec. Cette approche résiste aux montées de version des modèles, contrairement à une valeur de temperature ajustée manuellement.

Une tendance commune aux fournisseurs

Google n'est pas seul dans cette démarche. Le secteur supprime progressivement les contrôles de bas niveau au profit de modèles qui gèrent eux-mêmes leur comportement d'inférence, et les modèles de raisonnement ont de toute façon rendu la plupart des ajustements d'échantillonnage sans grand effet. Il faut s'attendre à ce que la surface fonctionnelle de ces API continue de se réduire.