Guide du développeur pour Gemini 3.6 Flash

Gemini 3.6 Flash est un modèle puissant, rapide et économique de la famille Gemini 3. Conçu pour offrir des fonctionnalités agentiques équivalentes à Pro sans compromettre les performances ni la valeur, le modèle est désormais disponible pour tous les développeurs qui utilisent l'API Gemini et pour les entreprises qui utilisent Gemini Enterprise Agent Platform.

Ce document présente les nouveautés de 3.6 Flash, son positionnement dans la famille de modèles Gemini, comment migrer vers 3.6 Flash et un guide de démarrage rapide pour l'utiliser.

Comment s'intègre-t-il dans la famille Gemini ?

Gemini 3.6 Flash est le principal modèle agentique de la famille Gemini 3. Il fait le lien entre les modèles Pro à raisonnement approfondi et les modèles Flash-Lite à haut débit. Par rapport à Gemini 3.5 Flash, 3.6 Flash offre une qualité nettement supérieure en termes d'orchestration d'outils en plusieurs étapes, de refactorisation de code full-stack et de raisonnement visuel, tout en utilisant moins de jetons et de tours de raisonnement. Il offre des fonctionnalités de niveau Pro à la vitesse et au prix de Flash.

Spécifications et comparaisons des modèles

Le tableau suivant compare certaines spécifications de 3.6 Flash, 3.5 Flash et 3.1 Pro :

Consultez la page du modèle 3.6 Flash pour obtenir la liste complète des fonctionnalités, des outils et des options de consommation compatibles.

Nouveautés de Gemini 3.6 Flash

3.6 Flash est optimisé pour l'orchestration en plusieurs étapes, la refactorisation de code full-stack et le raisonnement général, avec une efficacité des jetons nettement supérieure à celle de ses prédécesseurs.

Mises à jour des fonctionnalités et des performances

Voici la liste des modifications apportées aux fonctionnalités et aux performances de 3.6 Flash par rapport aux modèles précédents :

• Réduction des jetons et des tours : consomme moins de jetons et effectue des workflows en plusieurs étapes en moins d'étapes de raisonnement et de tours de conversation que 3.5 Flash.
• Amélioration de la génération de code : produit un code plus propre avec des taux d'échec de compilation et de révision plus faibles dans les environnements de création d'applications, de prototypage et d'agent IDE.
• Réduction du biais d'action : résout les tâches de diagnostic en lecture seule sans apporter de modifications non sollicitées à l'espace de travail ni modifier l'état prématurément.
• Raisonnement multimodal et spatial : améliore les performances en matière d'interprétation de graphiques , de conversion de plans visuels et de génération de mises en page Web multi-éléments.
• Compatibilité avec l'utilisation de l'ordinateur : compatible en tant qu'outil intégré pour l'automatisation de l'interface utilisateur agentique.
• Préférence de style d'interface utilisateur : améliore la création de code fonctionnel, bien que les évaluateurs humains aient noté une préférence pour les modèles précédents en termes de présentation frontend et de mise en page visuelle. Vous pouvez atténuer ce problème en fournissant des consignes de conception explicites.

Modifications des paramètres comportementaux et d'API

Voici la liste des modifications apportées aux paramètres comportementaux et d'API de 3.6 Flash par rapport aux modèles précédents :

• Concision des étapes : utilise moins d'étapes de raisonnement que 3.5 Flash. Bien que cela réduise la latence et le coût de la refactorisation de code et des workflows d'outils, cela peut entraîner des sorties anticipées lors de suivis conversationnels prolongés en plusieurs tours où des chaînes d'itération plus longues sont nécessaires.
• Inspection programmatique anticipée : préfère exécuter des scripts de code de diagnostic (execute_code) pour inspecter les problèmes avant de modifier l'état plus fréquemment que 3.5 Flash. Bien que cela améliore la précision du diagnostic lors de la refactorisation complexe du backend, cela peut parfois entraîner l'exécution d'étapes d'inspection exploratoire supplémentaires sur des tâches Web et de script frontend simples, où la version précédente générait directement du code.
• Effort par défaut : conserve le niveau d'effort par défaut moyen introduit dans 3.5 Flash.
• Aucune substitution d'échantillonnage : les valeurs personnalisées pour les paramètres temperature, top-k ou top-p ne sont plus acceptées. La définition de valeurs personnalisées sera ignorée dans la surface de l'API. Utilisez plutôt thinking_level ou des schémas JSON structurés pour contrôler le déterminisme de la sortie.
• Restrictions concernant les pénalités de fréquence et de présence : les valeurs personnalisées pour ces paramètres ne sont plus acceptées. Leur définition générera désormais une erreur d'API active.
• Les requêtes d'API où le dernier tour d'entrée a le rôle "Modèle" ne sont pas acceptées.
• Les tours vides de l'historique des conversations sont supprimés.
• Les signatures de pensée non valides génèrent désormais des erreurs.
• Appel de fonction strict : FunctionResponse doit correspondre exactement à l'id, au name et au nombre d'exécutions du FunctionCall précédent. Ajoutez des instructions intégrées directement dans le texte de réponse de la fonction, séparées par deux sauts de ligne (\n\n).

Guide de démarrage rapide

Avant de commencer, vous devez vous authentifier auprès d'Agent Platform à l'aide des Identifiants par défaut de l'application (ADC) ou d'une clé API. Pour en savoir plus, consultez Premiers pas avec Gemini Enterprise Agent Platform.

Dans les blocs de code suivants, remplacez PROJECT_ID par l'ID de votre projet.

Installation

Assurez-vous d'utiliser la dernière version du SDK google-genai :

pip install --upgrade google-genai

Requête de base

from google import genai

client = genai.Client(enterprise=True, project="PROJECT_ID", location="global")

response = client.models.generate_content(
  model="gemini-3.6-flash",
  contents="How does AI work?",
)
print(response.text)

curl -X POST \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/global/publishers/google/models/gemini-3.6-flash:generateContent \
-d '{
  "contents": {
    "role": "USER",
    "parts": { "text": "Why is the sky blue?" },
  },
}'

Migrer vers 3.6 Flash depuis 3.5 Flash ou 3.1 Pro

Pour migrer vers 3.6 Flash depuis 3.5 Flash ou 3.1 Pro, procédez comme suit :

1. Mettez à jour l'ID du modèle : remplacez la chaîne de modèle dans vos appels d'API par gemini-3.6-flash.
2. Adaptez votre code aux nouvelles règles de l'API de la famille Gemini 3: Gemini 3.6 Flash applique strictement les règles de paramètres et les conventions d'API établies pour la famille Gemini 3:
   • Supprimez la température, le top-K et le top-P : supprimez ces paramètres personnalisés de votre charge utile. Bien qu'ils ne génèrent pas d'erreur, le modèle les ignorera complètement. Utilisez plutôt le paramètre thinking_level ou les sorties structurées json_schema pour contrôler le déterminisme de la sortie.
   • Supprimez les pénalités de fréquence et de présence : supprimez toutes les configurations personnalisées pour les pénalités de fréquence ou de présence afin d'éviter que vos appels d'API ne génèrent des erreurs d'exécution.
   • Assurez-vous que votre intégration de chat ne tente pas de préremplir le modèle : examinez vos tableaux d'historique des messages pour vous assurer que votre charge utile d'API ne se termine pas par un tour d'utilisateur ou de modèle vide. Si le dernier objet de votre tableau d'historique est un rôle "model" (API GenerateContent) ou un type "model_output" (API Interactions), restructurez la séquence pour éviter de déclencher une erreur de validation stricte.
   • Utilisez thinking_level : supprimez les instances du paramètre obsolète thinking_budget et utilisez plutôt thinking_level.
   • Appliquez des conventions strictes d'appel de fonction : FunctionResponse doit correspondre exactement à l'id, au name et au nombre d'exécutions du précédent FunctionCall. Si vous devez ajouter des instructions intégrées, placez-les directement dans le texte de réponse de la fonction, séparées par deux sauts de ligne (\n\n).
3. Tenez compte des changements de workflow:
   • Si votre application repose sur des boucles conversationnelles en plusieurs tours, testez vos workflows pour vous assurer que la nouvelle concision des étapes du modèle ne déclenche pas de sorties prématurées.
   • Si vous créez des agents de script frontend ou de base, surveillez les appels execute_code exploratoires inutiles en raison du nouveau biais du modèle en faveur de l'inspection programmatique anticipée.

Solutions de contournement pour les exigences de texte pré-outil

Si votre requête exige que le modèle génère du texte structuré (XLM, YAML, JSON, etc.) (par exemple, <UPDATE>...</UPDATE>) immédiatement avant d'effectuer un appel d'outil, l'appel d'outil peut parfois échouer avec une Malformed_Function_Call erreur. Pour résoudre ce problème, vous pouvez utiliser l'une des solutions de contournement suivantes :

• (Recommandé) Demandez au modèle de placer ses notes pré-outil dans un appel de fonction update() dédié au lieu de texte brut. Pour obtenir des instructions d'implémentation détaillées, consultez la section suivante.
• Demandez au modèle d'écrire des notes sous forme d'en-têtes Markdown (par exemple, # UPDATE, ## PLAN) au lieu de texte structuré.
• N'exigez pas que le modèle génère du texte avant les appels d'outils.

Solution recommandée : encapsuler les notes de travail dans un appel de fonction dédié

Au lieu de l'instruction d'origine :

Before calling a tool, in every response you MUST first output a single
`<UPDATE>` part as specified, don't skip this part or any of required sub-tags
within `<UPDATE>`.

Utilisez cette instruction mise à jour :

Before calling any other tool, in every response you MUST first call `update`
with all required parameters (previous_step, plan, next_step, external).

Mettez à jour toutes les références à l'ancien format XML <UPDATE> dans la demande du client. Ajoutez ensuite la déclaration de fonction correspondante pour la fonction de mise à jour :

{
  "name": "update",
  "description": "Update working notes (previous step analysis, plan, next step, external note).",
  "parameters": {
    "type": "OBJECT",
    "properties": {
      "previous_step": {
        "type": "STRING",
        "description": "Key findings and outcomes since the previous step."
      },
      "plan": {
        "type": "STRING",
        "description": "The current status of the plan."
      },
      "next_step": {
        "type": "STRING",
        "description": "Brief explanation of the immediate next action according to the plan."
      },
      "external": {
        "type": "STRING",
        "description": "A short, plain-language note shown to the User about what you are ABOUT TO DO next."
      }
    },
    "required": [
      "previous_step",
      "plan",
      "next_step",
      "external"
    ]
  }
}

Le modèle effectuera deux appels à la même étape : l'appel update() qui remplace le XML structuré et l'appel de fonction réel qu'il souhaite effectuer.

Autres ressources

• Page du modèle Gemini 3.6 Flash
• Notebook d'introduction