Migration vers Gemini 3.6 Flash : cinq changements d'API et une panne silencieuse

En bref Migrer vers gemini-3.6-flash ou gemini-3.5-flash-lite implique cinq changements de requête. Quatre d'entre eux renvoient un HTTP 400, vous le découvrez donc immédiatement. Le cinquième, non : temperature, top_p et top_k sont désormais acceptés puis ignorés. Si votre pipeline repose sur temperature=0 pour obtenir une sortie stable, il continuera de renvoyer 200 OK alors que la garantie sur laquelle vous comptiez a disparu. Corrigez celui-là en premier, puis les quatre qui font du bruit.

Last verified: 2026-07-21

Si vous vous contentez de remplacer un identifiant de modèle dans un fichier de configuration en espérant que le reste continue de fonctionner, lisez la première section avant de déployer.

Les cinq changements, classés selon le moment où vous les découvrez

Quatre de ces cinq défaillances s'annoncent d'elles-mêmes. Vos tests d'intégration les détectent, votre outil de suivi d'erreurs vous alerte, vous les corrigez en une après-midi. La première est celle qui atteint la production.

La dangereuse : temperature, top_p et top_k sont désormais ignorés

Lisez cette séquence attentivement, car l'ordre a son importance pour vous. Aujourd'hui, le paramètre est une opération sans effet. Plus tard, il devient une erreur. Cela signifie que la période où vous risquez le plus de vous tromper sur votre propre système, c'est maintenant, alors que tout renvoie encore 200.

Quels pipelines cassent sans erreur

Une opération silencieuse sans effet n'est dangereuse que si vous dépendiez du paramètre. Quatre configurations courantes en dépendaient :

• Pipelines de déterminisme. Tout ce qui fixe temperature=0 pour que des appels répétés concordent entre eux : clés de cache construites à partir de la sortie du modèle, passes de déduplication, tâches de classification qui alimentent une machine à états en aval. Le réglage est désormais inerte, donc quelle que soit la stabilité de sortie qu'il vous achetait, vous ne l'achetez plus.
• Tests golden-file et snapshot. Des suites qui figeaient temperature=0 et comparent la sortie du modèle à une chaîne attendue stockée. Elles deviennent instables après le changement de modèle, et cette instabilité ressemble à une régression de qualité du modèle plutôt qu'à un problème de configuration, ce qui vous envoie déboguer dans la mauvaise direction.
• Sortie structurée tenue par une température basse. Des équipes qui n'ont jamais adopté les sorties structurées et ont plutôt gardé temperature proche de zéro plus un top_p serré pour que le modèle émette de façon fiable du JSON analysable. Les deux boutons sont désormais inertes en même temps.
• Configurations réglées par route. Des produits qui exposent un curseur de créativité, ou qui routent « résumer » à une température et « brainstormer » à une autre. Le curseur bouge encore dans votre interface. Il ne bouge plus rien dans le modèle.

Aucun de ces cas ne produit de trace de pile. Ils produisent une sortie légèrement différente de ce que vous avez validé, dans un système qui se déclare sain.

Votre passerelle ne vous préviendra pas non plus

C'est la partie qui piège même les équipes prudentes. Les passerelles de modèles publient des métadonnées lisibles par machine décrivant quels paramètres chaque modèle prend en charge, et l'outillage lit ces métadonnées pour décider quoi envoyer.

Ce qui remplace temperature

Le remplacement annoncé par Google n'est pas un autre paramètre. C'est l'instruction système : écrivez le comportement que vous voulez sous forme de règle que le modèle lit, plutôt que sous forme de constante d'échantillonnage.

C'est un vrai changement dans la façon d'exprimer votre intention, alors traduisez plutôt que de supprimer :

Comment trouver chaque point d'appel avant de déployer

Cherchez les noms de paramètres dans votre base de code plutôt que de faire confiance à la couche de configuration, car ces valeurs sont généralement définies à plusieurs endroits par différentes personnes :

# Orthographes natives Gemini et compatibles OpenAI, plus les objets de configuration qui les portent
grep -rn "temperature\|top_p\|topP\|top_k\|topK\|candidate_count\|candidateCount" \
  --include="*.py" --include="*.ts" --include="*.js" --include="*.go" --include="*.java" .

# Les wrappers qui les masquent
grep -rn "generation_config\|generationConfig\|GenerateContentConfig\|thinking_budget\|thinkingBudget" .

Vérifiez aussi les résultats en dehors du code applicatif : configuration YAML et JSON, outils de gestion de prompts, notebooks, harnais d'évaluation, et tout Terraform ou console d'administration qui stocke des réglages de modèle. Un bouton réglé dans un tableau de bord il y a six mois est exactement le genre de chose qui survit à une revue de code.

Les quatre qui échouent bruyamment

Celles-ci sont plus simples, parce que l'API vous le signale. Corrigez-les dans l'ordre où votre suite de tests les fait remonter.

thinking_budget et thinking_level ne peuvent pas être présents tous les deux

Deux valeurs par défaut à connaître au moment de choisir, car elles diffèrent entre les deux modèles :

• gemini-3.6-flash a medium par défaut.
• gemini-3.5-flash-lite a minimal par défaut, qui est optimisé pour le débit.

Vous ne pouvez plus préremplir un tour du modèle

Ces deux objectifs migrent vers les deux mêmes endroits que tout le reste : une instruction système qui énonce la règle, ou des sorties structurées quand vous avez besoin d'une forme analysable par machine. Cherchez dans votre code tout constructeur de requête qui ajoute un message assistant ou model final, en particulier la logique de réessai et de continuation, où les préremplissages tendent à être générés dynamiquement plutôt qu'écrits littéralement.

Chaque FunctionResponse a besoin de call_id et name

candidate_count a disparu

Avant et après : une requête qui migre proprement

Voici un appel natif Gemini portant tous les champs dépréciés, et la version qui survit au changement.

# AVANT : fonctionne sur les modèles de l'ère 2.5, casse ou se comporte mal silencieusement sur 3.6 Flash
config = {
    "temperature": 0,          # désormais ignoré, aucune erreur
    "top_p": 0.95,             # désormais ignoré, aucune erreur
    "top_k": 40,               # désormais ignoré, aucune erreur
    "candidate_count": 1,      # non pris en charge dans Gemini 3.x
    "thinking_budget": 8192,   # 400 s'il accompagne thinking_level
}

# APRÈS : l'intention est passée des constantes d'échantillonnage aux instructions
config = {
    "system_instruction": (
        "Réponds en trois phrases au maximum. Utilise des affirmations déclaratives simples. "
        "N'ajoute pas de préambule, ne reformule pas la question et ne propose pas de suivi. "
        "Si la réponse est incertaine, dis-le en une phrase."
    ),
    "thinking_level": "medium",
}

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["EVOLINK_API_KEY"],
    base_url="https://api.evolink.ai/v1"
)

response = client.chat.completions.create(
    model="gemini-3.6-flash",
    messages=[
        {"role": "system", "content": "Réponds en trois phrases au maximum. Pas de préambule."},
        {"role": "user", "content": "Résume ce rapport d'incident."}
    ]
    # pas de temperature, pas de top_p : ils seraient acceptés puis ignorés en aval
)

print(response.choices[0].message.content)

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env["EVOLINK_API_KEY"],
  baseURL: "https://api.evolink.ai/v1",
});

const response = await client.chat.completions.create({
  model: "gemini-3.6-flash",
  messages: [
    { role: "system", content: "Réponds en trois phrases au maximum. Pas de préambule." },
    { role: "user", content: "Résume ce rapport d'incident." },
  ],
  // pas de temperature, pas de top_p
});

console.log(response.choices[0].message.content);

Un ordre de migration qui attrape la panne silencieuse

L'ordre compte, car les erreurs bruyantes sont faciles et la silencieuse ne l'est pas. Procédez dans cet ordre :

1. Inventoriez d'abord. Exécutez les grep ci-dessus et listez chaque endroit où un paramètre d'échantillonnage est défini, y compris les stores de configuration et les tableaux de bord. Notez quel comportement chacun protégeait.
2. Traduisez l'intention, ne vous contentez pas de supprimer. Pour chaque temperature que vous trouvez, déterminez à quoi elle servait et écrivez l'instruction système équivalente. Supprimer sans traduire, c'est expédier une régression de qualité en production.
3. Corrigez les 400. Remplacez thinking_budget par thinking_level, supprimez candidate_count, retirez les tours de modèle préremplis, ajoutez call_id et name à chaque FunctionResponse.
4. Choisissez un niveau de réflexion à dessein, surtout sur Flash-Lite, où la valeur par défaut minimal ne convient pas à un travail autonome multi-étapes. C'est aussi le plus grand levier de coût de la migration : sur notre jeu de tâches, 3.6 Flash en minimal coûtait 73.6% de moins par passe que le même modèle sur le medium par défaut, et les tokens de réflexion représentaient 85% de la sortie facturée en medium. Ce qu'il faut tester, c'est si votre charge de travail survit à la baisse, pas si l'économie est réelle.
5. Régénérez la référence de vos tests de snapshot sur le nouveau modèle avant de comparer quoi que ce soit. Les anciens golden files ont été produits sous un paramètre qui ne s'applique plus, ils ne constituent donc pas un point de référence valide.
6. Exécutez vos évaluations sur les deux modèles avec le même jeu de tâches et comparez les distributions de sortie, pas seulement les taux de réussite. Les changements de comportement silencieux se manifestent par une dérive de format, de longueur et de verbosité avant de se manifester par des réponses fausses.
7. Déployez en canari sur du trafic réel et surveillez les parseurs en aval, pas seulement le taux d'erreur de l'API. Si quelque chose doit casser en silence, cela casse dans le code qui consomme la sortie du modèle, pas dans l'appel lui-même.

Laissez le skill de migration de Google faire la première passe

npx skills add google-gemini/gemini-skills --skill gemini-interactions-api --global

Ensuite, dans un agent de codage, pointez-le sur votre projet :

Cela vaut la peine de l'exécuter. Il gère le travail mécanique : trouver les champs dépréciés, réécrire la construction des requêtes, mettre à jour les points d'appel, ce qui couvre l'essentiel de l'étape 3 ci-dessus.

Calendrier de retrait : quand le choix cesse d'être le vôtre

Computer Use : quatre pages officielles, deux réponses

Une question de capacité ne peut pas être tranchée par la documentation en ce moment. Le fait que ces modèles prennent en charge Computer Use est énoncé de façon incohérente dans les propres documents de Google :

• La documentation des modèles de l'API Gemini marque Computer Use comme pris en charge (preview) pour 3.6 Flash, tandis que la page de la plateforme entreprise pour le même modèle l'indique comme non pris en charge.
• Pour 3.5 Flash-Lite, les pages du modèle disent qu'il n'est pas pris en charge, tandis que l'annonce de lancement et le guide développeur Gemini 3 affirment qu'il fonctionne.

Quatre pages officielles, deux réponses contradictoires, aucun moyen de trancher par la lecture. Si Computer Use est sur votre chemin critique, testez-le sur votre propre compte et votre propre endpoint avant de vous engager, et gardez un modèle de repli câblé. Cette section sera mise à jour avec une réponse testée et la date de son observation. Tout autre changement de ce guide est documenté de façon cohérente ; celui-ci ne l'est pas.

Ce que cela signifie si vous rechoisissez un fournisseur cette semaine

Une migration que vous n'aviez pas planifiée a atterri dans votre sprint, et le travail représente un jour ou deux de modifications soignées plutôt qu'une réécriture de week-end. Puisque vous touchez déjà à chaque point d'appel, c'est un moment naturel pour regarder comment le modèle vous parvient tout court.

Deux choses valent la peine d'être vérifiées pendant que vous y êtes :

• Pouvez-vous exécuter l'ancien et le nouveau modèle côte à côte pendant le basculement ? L'étape 6 ci-dessus l'exige. Si votre configuration rend malaisée l'exécution de gemini-3.5-flash et gemini-3.6-flash sur le même jeu de tâches, cette friction sera là aussi pour la prochaine migration, et il y en aura une : Google a indiqué que ces règles s'appliquent à tout modèle publié à partir de maintenant.
• À quelle vitesse un nouveau modèle devient-il appelable pour vous ? gemini-3.6-flash a atteint la disponibilité générale sans suffixe preview dès le premier jour. L'écart entre la sortie d'un modèle et le moment où votre code peut l'appeler est un coût que vous payez à chaque lancement.

FAQ

Sources

• Using the latest Gemini models (Google AI for Developers) : paramètres d'échantillonnage dépréciés, thinking_level, candidate_count, restriction de préremplissage, exigences de FunctionResponse, commande du skill de migration
• Gemini deprecations (Google AI for Developers) : dates d'arrêt et remplacements recommandés
• Gemini API models (Google AI for Developers) : identifiants de modèles, matrice de prise en charge des capacités
• guide développeur Gemini 3 (Google AI for Developers) : comportement des requêtes et capacités de Gemini 3
• Gemini 3.6 Flash sur Gemini Enterprise Agent Platform (Google Cloud) : liste des capacités entreprise et valeurs par défaut des paramètres affichées
• Introducing Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber (Google) : annonce de lancement et date de sortie
• google-gemini/gemini-skills (GitHub) : le skill de migration officiel
• endpoint models d'OpenRouter (OpenRouter) : métadonnées de passerelle listant temperature, top_p et seed comme paramètres pris en charge pour les deux modèles, observé le 2026-07-21
• Catalogue de modèles EvoLink, suivi de sortie de Gemini 3.6 Flash, Gemini 3.6 Flash contre Gemini 3.5 Flash, guide de migration Gemini 3.5 Flash contre Gemini 3 Flash Preview, guide de dépréciation de Gemini 3 Pro, URL de base de l'API EvoLink