Tutoriel API Gemini 3.8 Flash : niveaux de raisonnement, extraction PDF et function calling en Python

Qu’est‑ce que Gemini 3.8 Flash ?

Gemini 3.8 Flash est le modèle polyvalent de Google, disponible en disponibilité générale depuis le 2 septembre 2026 sous l’ID gemini-3.8-flash. Il est arrivé 3 semaines après 3.7 Flash, et Google le positionne pour le code à long horizon, les workflows agentiques et le raisonnement multi‑étapes dans des domaines spécialisés comme la finance et le juridique.

Les spécifications importantes pour les appels d’API restent inchangées depuis 3.7 : 

• fenêtre de contexte de 1 million de tokens
• 64 k tokens de sortie maximum
• entrée multimodale (texte, images, vidéo, audio, PDF) avec sortie texte
• les mêmes tarifs de lancement de 0,75 $ par 1 M de tokens en entrée et 3,75 $ par 1 M de tokens en sortie jusqu’au 31 décembre 2026 (puis 1,50 $ et 7,50 $ à partir du 1er janvier 2027)

Ce qui change, c’est le comportement, pas l’interface : Google indique que 3.8 travaille davantage sur les tâches complexes, en prenant des étapes de raisonnement supplémentaires et en appelant les outils de manière itérative, ce qui peut augmenter l’usage de tokens aux niveaux d’effort plus élevés. 3.7 Flash reste pleinement pris en charge pour les charges où l’efficacité prime sur la profondeur.

Pour les benchmarks et le détail des tarifs, consultez notre guide Gemini 3.8 Flash, ou lisez le guide What is Google Gemini? pour une vue d’ensemble de la plateforme.

Gemini 3.8 Flash vs 3.8 Flash Cyber

Le lancement inclut 2 variantes, et une seule possède un ID de modèle que vous pouvez saisir. 

• Gemini 3.8 Flash est le modèle généraliste, disponible dès aujourd’hui dans Google AI Studio et l’API Gemini. 
• Gemini 3.8 Flash Cyber est une variante cybersécurité, optimisée pour la découverte de vulnérabilités et la correction automatisée.

La variante Cyber n’est pas disponible sur l’API publique : l’accès passe par le Fairwind Program de Google, limité aux autorités publiques approuvées, opérateurs d’infrastructures critiques et mainteneurs de logiciels.

Si vous suivez ce tutoriel, votre ID de modèle est gemini-3.8-flash. Rien ci‑dessous ne nécessite ni n’utilise la variante Cyber.

Interactions API vs generateContent

Pour appeler Gemini 3.8 Flash, utilisez client.interactions.create() dans le SDK google-genai. Google a rendu l’Interactions API GA en juin 2026 et la recommande pour tous les nouveaux projets. Bien que generateContent fonctionne encore, c’est désormais hérité. Les nouvelles fonctionnalités comme l’historique côté serveur, l’exécution en arrière‑plan et les étapes d’exécution observables arrivent d’abord sur Interactions.

Le plus grand changement en pratique concerne la gestion d’état. Les échanges multi‑tours utilisent maintenant un previous_interaction_id côté serveur : vous passez l’ID de la dernière interaction, et le serveur restaure l’état. Vous n’avez plus à concaténer ni à renvoyer manuellement tout l’historique de chat depuis votre client. Évitez aussi de préremplir des tours du modèle ; c’est un schéma hérité de generateContent et cela cassera sur Gemini 3.x.

Un point piège revient souvent, et il réapparaît dans la section PDF : previous_interaction_id restaure l’historique de conversation et rien d’autre. tools, system_instruction, generation_config et response_format sont portés par interaction ; tout tour qui en a besoin doit les repasser.

thinking_level remplace les réglages d’échantillonnage

Sur les anciens modèles Gemini, on utilisait temperature, top_p et top_k pour contrôler l’aléa de sortie. Gemini 3.x supprime ces réglages d’échantillonnage et les remplace par thinking_level, désormais l’unique commande.

Trois valeurs sont acceptées :

• low : le moins de tokens de raisonnement, le plus rapide et le moins coûteux. Idéal pour l’extraction, la classification et tout ce que vous validerez vous‑même.

• medium : la valeur par défaut, recommandée par Google pour le code et les agents.

• high : le budget de raisonnement maximal, pour la logique multi‑étapes difficile et les tâches très outillées.

N’envoyez pas minimal. C’est invalide depuis Gemini Flash 3.7 et renvoie une erreur de validation 400. 

Autre règle héritée de 3.7 : frequency_penalty, presence_penalty et candidate_count déclenchent désormais une erreur d’API active, donc supprimez‑les aussi des anciennes configs.

Comment configurer l’API Gemini 3.8 Flash ?

La mise en place de l’environnement prend environ 2 minutes. Il vous faut une clé d’API depuis Google AI Studio et la bibliothèque Python google-genai à jour.

Obtenir une clé d’API dans Google AI Studio

Rendez‑vous sur Google AI Studio dans votre navigateur et connectez‑vous avec votre compte Google. Cliquez sur Create API Key, choisissez ou créez un projet Google Cloud, puis copiez la clé secrète.

Ouvrez votre terminal et enregistrez la clé comme variable d’environnement avec export GEMINI_API_KEY=<your-key>.

Ne passez jamais la clé en paramètre d’URL ?key= ; les chaînes de requête finissent dans les journaux serveur, l’historique du navigateur et les caches proxy. Si vous voulez explorer le modèle dans un bac à sable avant d’écrire du code, le tutoriel Google AI Studio couvre les modes Chat, Build et Stream ; cet article reste focalisé sur l’API.

En production, l’authentification change : Vertex AI (désormais intégré à la Gemini Enterprise Agent Platform) vous apporte OAuth, des rôles IAM et des endpoints régionaux à la place d’une clé brute. Tout ce tutoriel utilise des clés AI Studio car c’est le plus rapide pour apprendre, mais planifiez la migration vers Vertex avant que quoi que ce soit ne touche des données utilisateur réelles.

Installer google-genai et créer un client

Beaucoup de tutoriels recommandent encore d’installer google-generativeai. C’est l’ancien SDK, et il n’a pas l’Interactions API. Installez google-genai (version 2.3.0 ou ultérieure) :

pip install -U google-genai

Une fois installé, vérifiez que Python charge bien la bibliothèque et initialise votre client sans erreur :

from google import genai # reads GEMINI_API_KEY from the environment
client = genai.Client() 
print("Client initialized successfully.")

Effectuer votre premier appel Interactions API

Chaque requête à l’Interactions API crée une ressource Interaction, qui enregistre tout le tour : votre entrée, les réflexions du modèle, les appels d’outils et la sortie finale. Le SDK expose le texte final via la propriété pratique output_text, vous n’avez donc que rarement besoin de parcourir manuellement les étapes.

from google import genai
client = genai.Client()
interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input=(
        "Write a pandas one-liner that adds a 7-day rolling average "
        "revenue column per store_id to a DataFrame with columns "
        "date, store_id, revenue. Reply with only the code, no explanation."
    ),
    generation_config={"thinking_level": "medium"},
)
print(interaction.output_text)
usage = interaction.usage
print(
    f"input={usage.total_input_tokens} | output={usage.total_output_tokens} | "
    f"thinking={usage.total_thought_tokens} | total={usage.total_tokens}"
)

Sur ma machine, le modèle a répondu par une unique ligne pandas chaînée, et cette ligne d’usage :

Ces chiffres masquent la première vraie différence avec 3.7. J’ai relancé la même tâche avec un prompt plus long et sans contrainte sur la sortie, et 3.8 a dépensé 1 436 tokens de raisonnement pour 870 tokens de sortie. Avec la contrainte, 1 515 contre 42. Le budget de raisonnement a à peine bougé, à l’inverse de 3.7 où les 2 prompts faisaient passer le raisonnement de 838 à 1 530.

Autrement dit, 3.8 décide de l’effort de réflexion selon la tâche, pas selon la manière dont vous la formulez, ce qui colle à l’affirmation de Google que le modèle raisonne et vérifie davantage. Les tokens de raisonnement sont facturés au tarif des sorties, donc sur l’appel contraint, environ 97 % des tokens facturés étaient du raisonnement que je n’ai jamais vu. C’est la raison de la section suivante. 

Diffuser la réponse en streaming

Pour une interface de chat ou toute expérience suivie par une personne, attendre plusieurs secondes la réponse complète paraît lent. Passez stream=True à client.interactions.create() et affichez les fragments à l’arrivée :

	from google import genai

	client = genai.Client()

	stream = client.interactions.create(
	   model="gemini-3.8-flash",
	   input="Explain the difference between a JOIN and a correlated subquery in SQL.",
	   generation_config={"thinking_level": "low"},
	   stream=True,
	)

	for event in stream:
	   if event.event_type == "step.delta" and event.delta.type == "text":
	       print(event.delta.text, end="", flush=True)
	print() 

Lors de mon test, le modèle a renvoyé une réponse longue et bien structurée avec thinking_level: "low" : une comparaison conceptuelle, un tableau récapitulatif et 2 exemples SQL pour trouver la commande la plus récente de chaque client, l’un avec une jointure sur table dérivée, l’autre avec une sous‑requête corrélée dans la liste SELECT. Les premiers mots sont apparus presque immédiatement, ce qui est l’objectif.

Le print() final est là pour une bonne raison. Sans lui, le dernier fragment se termine en milieu de ligne et zsh affiche un % parasite avant votre invite, car le flux s’arrête exactement là où le texte du modèle s’arrête. Par ailleurs, si vous journalisez les comptes de tokens par requête, lisez‑les à partir de l’événement de complétion final plutôt que de sommer les fragments.

Comment thinking_level influe sur le coût et la qualité ?

thinking_level détermine combien de raisonnement Gemini 3.8 Flash effectue avant d’écrire la réponse. Les tokens de raisonnement sont facturés au tarif sortie de 3,75 $ par 1 M ; le niveau choisi influe donc directement sur le coût et la latence. Google indique que 3.8 s’appuie délibérément là‑dessus : il ajoute des étapes de raisonnement sur les tâches complexes et peut dépenser plus de tokens aux niveaux d’effort élevés qu’en 3.7.

Exécuter un même prompt en low, medium et high

Le test est une condition de concurrence dans une fonction de relance de paiement, envoyée avec le même prompt aux 3 niveaux. Les bugs de concurrence punissent la lecture en diagonale ; si les niveaux diffèrent, c’est ici que cela se voit. Si vous ne lancez qu’un seul bloc de code de cet article, prenez celui‑ci : les chiffres parlent mieux que n’importe quel texte.

import time

from google import genai

client = genai.Client()

BUGGY_CODE = '''
import threading

payment_attempts = {}

def retry_payment(order_id, charge_fn, max_retries=3):
    """Retry a failed payment up to max_retries times."""
    if order_id not in payment_attempts:
        payment_attempts[order_id] = 0

    while payment_attempts[order_id] < max_retries:
        success = charge_fn(order_id)
        if success:
            del payment_attempts[order_id]
            return True
        payment_attempts[order_id] += 1
    return False
'''

PROMPT = (
    "Two worker threads can call retry_payment() with the same order_id "
    "at the same time. Identify the concurrency bug that can double-charge "
    "a customer, and rewrite the function to fix it.\n\n" + BUGGY_CODE
)

for level in ["low", "medium", "high"]:
    start = time.perf_counter()
    interaction = client.interactions.create(
        model="gemini-3.8-flash",
        input=PROMPT,
        generation_config={"thinking_level": level},
    )
    elapsed = time.perf_counter() - start
    usage = interaction.usage
    print(f"\n=== thinking_level: {level} | {elapsed:.1f}s ===")
    print(interaction.output_text)
    print(
        f"input={usage.total_input_tokens} | output={usage.total_output_tokens} | "
        f"thinking={usage.total_thought_tokens}"
    )

Pour contexte, la vulnérabilité est un check‑then‑act non atomique sur payment_attempts[order_id]. En concurrence, 2 threads peuvent tous deux passer la condition while et appeler charge_fn() avant que l’un des deux n’incrémente le compteur. La correction consiste à protéger l’enchaînement lecture‑vérification‑débit‑incrément dans un verrou par commande, ou à utiliser une clé d’idempotence côté passerelle.

Comparer les résultats

Résultats de mes exécutions :

Les 3 niveaux ont trouvé la double facturation, et tous ont livré un verrouillage par commande, pour que des commandes sans lien s’exécutent en parallèle. Ce 2e point est la une si vous comparez à 3.7 : là, low enrobait tout dans un verrou global unique tenu pendant l’appel réseau, et les verrous par commande n’apparaissaient qu’en medium. En 3.8, low propose ce meilleur design avec 0 token de raisonnement, en 7,8 secondes, pour moins d’un tiers de centime.

Alors, qu’achètent les niveaux aujourd’hui ? La profondeur d’audit. Ce code a 4 modes d’échec distincts (la double facturation, un KeyError sur suppression concurrente, une refacturation après que le chemin de succès supprime l’état, et des incréments non atomiques), et high est le seul niveau à en citer les 4 ; low a manqué le cas de refacturation, et medium a manqué l’incrément du compteur. 

high est aussi le seul à expliciter la sémantique du chemin d’échec de son correctif : une fois les relances épuisées, les appels ultérieurs reçoivent False plutôt que de refacturer.

La colonne « thinking » est la preuve concrète de « 3.8 travaille plus » : sur le même prompt en 3.7, medium est passé de 2 343 à 3 158 tokens de raisonnement, et high de 2 217 à 4 512, environ le double, et ces tokens supplémentaires ont acheté une analyse plus complète sans changer le verdict. La latence a monté de concert sur cette série (7,8 s, 16,6 s, 25,5 s), mais les timings isolés varient ; comparez les tokens plutôt que les secondes.

Choisir une valeur par défaut et quand monter d’un cran

Voici ma règle d’or pour les niveaux de raisonnement :

• En 3.8, low mérite un rôle plus large que ne le suggère le défaut « medium » de Google : il a produit un correctif juste et bien conçu avec 0 token de raisonnement, donc démarrez ici pour tout ce qu’un humain lira avant de compter (tri, brouillons, synthèses, code que vous relirez). 

• Gardez medium là où la sortie part en production sans relecture, car l’effort supplémentaire a apporté une analyse plus complète des modes d’échec — exactement ce qu’il faut pour un pipeline non relu.

• Réservez high aux sorties où le chemin d’échec fait partie du produit, comme les flux de paiement, migrations, ou tout ce qu’un reviewer auditerait ligne par ligne. Dans mon test, c’est le seul niveau à repérer les 4 bugs et documenter le comportement après épuisement des relances.

Avec un coût 6.6 fois supérieur à low pour high, l’arbitrage se lit très différemment à 3,75 $ par 1 M de tokens sortie aujourd’hui vs 7,50 $ après le 31 décembre 2026 ; montez d’un cran à la requête, pas globalement.

À noter : Google précise que 3.7 Flash reste pleinement pris en charge pour les charges « efficacité d’abord ». Si l’application de 3.8 coûte plus cher que nécessaire pour votre tâche, rester sur gemini-3.7-flash pour cette charge est une option supportée, pas un contournement.

Comment extraire des données structurées d’un PDF ?

Gemini 3.8 Flash lit directement les PDF en entrée ; vous pouvez donc envoyer une facture ou un rapport et poser des questions dessus. J’ai utilisé une facture fournisseur d’une page avec numéro, dates, 4 lignes et un total.

Joindre un PDF au prompt

Téléversons une facture PDF locale avec l’API Files. L’API Files gère le stockage et le cache des fichiers sur l’infrastructure de Google :

	from google import genai
	client = genai.Client()
	print("Uploading invoice...")
	doc = client.files.upload(file="invoice_aug_2026.pdf")
	print(f"File uploaded: {doc.uri}\n")

	interaction = client.interactions.create(
	   model="gemini-3.8-flash",
	   input=[
	       {
	           "type": "text",
	           "text": "Extract the invoice number, total amount due, and due date.",
	       },
	       {"type": "document", "uri": doc.uri, "mime_type": doc.mime_type},
	   ],
	)
	print(interaction.output_text)

La sortie de ma facture :

Les 3 valeurs sont correctes. L’upload est unique, et le fichier reste disponible pour les requêtes suivantes, ce qui compte dès que vous posez plus d’une question sur le même document. La réponse revient en puces markdown, parfait pour la lecture mais pas pour un pipeline.

Forcer du JSON avec un schéma de réponse

Pour obtenir du JSON au lieu d’un texte libre, passez un schéma dans response_format. Sur l’Interactions API, c’est un paramètre de haut niveau ; le réglage responseMimeType à l’intérieur de generationConfig que vous verrez dans d’anciens tutoriels appartient à l’endpoint hérité generateContent.

import json

from google import genai
from pydantic import BaseModel

client = genai.Client()


class Invoice(BaseModel):
    invoice_number: str
    total_due_usd: float
    due_date: str  # ISO 8601


doc = client.files.upload(file="invoice_aug_2026.pdf")

interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input=[
        {
            "type": "text",
            "text": "Extract the invoice number, total amount due in USD, and due date.",
        },
        {"type": "document", "uri": doc.uri, "mime_type": doc.mime_type},
    ],
    response_format={
        "type": "text",
        "mime_type": "application/json",
        "schema": Invoice.model_json_schema(),
    },
)

invoice = json.loads(interaction.output_text)
print(invoice)

Voici la sortie que j’ai reçue :

Votre classe Pydantic définit les champs requis et leurs types, tandis que model_json_schema() génère le schéma JSON requis par l’API Gemini. Une fois traité, json.loads() convertit la sortie du modèle en dictionnaire Python standard. À partir de là, les données structurées peuvent être transformées en ligne de DataFrame, insérées en base ou ajoutées à une Google Sheet.

Poser une relance avec previous_interaction_id

Pour une 2e question sur le même document, passez l’id de la 1re interaction dans previous_interaction_id. Le serveur a déjà le PDF et le 1er échange ; vous ne renvoyez ni l’un ni l’autre :

follow_up = client.interactions.create(
    model="gemini-3.8-flash",
    previous_interaction_id=interaction.id,
    input="List each line item on the invoice with its amount.",
)

print(follow_up.output_text)

Le modèle a renvoyé les 4 lignes dans l’ordre, y compris la ligne compute répétée, sans commentaire. C’est le bon comportement pour la question posée ; si vous voulez un signalement d’anomalies, demandez‑le.

Pour ce que ça vaut, 3.7 s’est comporté de façon identique ici ; l’assiduité supplémentaire de 3.8 s’applique à son propre raisonnement, pas à des audits non demandés.

Deux points à savoir sur cet appel : 

• response_format n’a pas été reconduit, car il est propre à l’interaction ; ce tour est donc revenu en prose. 

• Les interactions sont stockées par défaut (store=True) pendant 55 jours sur l’offre payante et 1 jour sur l’offre gratuite ; store=False rend l’appel sans état, mais vous ne pourrez alors pas enchaîner un previous_interaction_id dessus.

Comment ajouter du function calling à Gemini 3.8 Flash ?

Le function calling sur Gemini 3.8 Flash est une boucle : le modèle demande un outil, votre code l’exécute, vous renvoyez le résultat, et le modèle rédige la réponse finale. Cette section construit la boucle à la main.

Si vous préférez que Google exécute la boucle avec des agents hébergés multi‑outils, lisez ensuite notre tutoriel sur  « Managed Agents » dans l’API Gemini. Et si votre cap est l’agentisation, le cours Building AI Agents with Google ADK bâtit un assistant support client complet sur les mêmes primitives.

Définir un outil et exécuter la boucle d’interaction

L’outil est lookup_exchange_rate(currency, date), adossé à un petit dict en mémoire, pour que l’exemple tourne sans API externe. La déclaration est un schéma JSON. Le modèle n’exécute jamais la fonction ; il renvoie une étape function_call demandant à votre code de :

import json

from google import genai

client = genai.Client()

# Local "data source" standing in for a real FX API
RATES = {
    ("USD", "2026-08-03"): 87.42,
    ("USD", "2026-08-10"): 87.15,
    ("EUR", "2026-08-03"): 95.08,
}


def lookup_exchange_rate(currency: str, date: str) -> dict:
    rate = RATES.get((currency.upper(), date))
    if rate is None:
        return {"error": f"No rate for {currency} on {date}"}
    return {"currency": currency.upper(), "date": date, "inr_rate": rate}


rate_tool = {
    "type": "function",
    "name": "lookup_exchange_rate",
    "description": "Look up the INR exchange rate for a currency on a date (YYYY-MM-DD).",
    "parameters": {
        "type": "object",
        "properties": {
            "currency": {"type": "string", "description": "ISO code, e.g. USD"},
            "date": {"type": "string", "description": "YYYY-MM-DD"},
        },
        "required": ["currency", "date"],
    },
}

# Turn 1: the model decides to call the tool
interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input="What was the USD to INR exchange rate on 2026-08-03?",
    tools=[rate_tool],
)

fc_step = next(s for s in interaction.steps if s.type == "function_call")
print(f"Model requested: {fc_step.name}({fc_step.arguments})")

# Your code executes the function locally
result = lookup_exchange_rate(**fc_step.arguments)

# Turn 2: send the result back; tools must be re-specified (interaction-scoped)
final = client.interactions.create(
    model="gemini-3.8-flash",
    previous_interaction_id=interaction.id,
    input=[
        {
            "type": "function_result",
            "name": fc_step.name,
            "call_id": fc_step.id,
            "result": [{"type": "text", "text": json.dumps(result)}],
        }
    ],
    tools=[rate_tool],
)

print(final.output_text)

La sortie :

Trois choses se sont passées :  

1. Le tour 1 a renvoyé une étape function_call avec un nom, des arguments structurés et un id.

2. Votre code Python a exécuté la recherche.

3. Le tour 2 a envoyé un bloc function_result référant cet appel. 

Le paramètre tools est repassé au tour 2 pour la même raison que response_format a dû être repassé dans la section PDF : previous_interaction_id transporte l’historique, pas la configuration.

Erreurs fréquentes de function calling sur Gemini 3.x

Si une boucle d’outil casse, c’est presque toujours l’un de ces 2 points. 

Premièrement, chaque résultat doit se rattacher à son appel. Sur l’Interactions API, cela passe par call_id et name dans le bloc function_result ; sur l’API héritée generateContent, le FunctionResponse doit correspondre à l’id et au name du FunctionCall précédent. Rien de tout cela n’est optionnel en Gemini 3.x.

Deuxièmement, une erreur Malformed_Function_Call survient généralement lorsque le modèle émet un commentaire avant l’appel d’outil. Le guide développeur 3.8 de Google recommande de nettoyer tout texte précédent, de formater les instructions en ligne avec \n\n, et d’envelopper les notes de travail dans un appel de fonction dédié plutôt qu’en texte brut. Serrez l’instruction système ; ne relancez pas à l’aveugle.

Qu’est‑ce qui casse en passant à Gemini 3.8 Flash ?

Cela dépend de votre point de départ. 

• Depuis Gemini 3.7 Flash : rien. Changez la chaîne du modèle en gemini-3.8-flash, et chaque extrait de cet article tourne tel quel, l’API étant identique. 

• Depuis Gemini 3.6 Flash ou antérieur, la configuration du modèle nécessite le même audit de 15 minutes qu’auparavant.

Checklist de migration (depuis 3.6 Flash ou antérieur)

Traitez ces points dans l’ordre. Les éléments 1 à 3 provoquent des 400 immédiats ; les éléments 4 et 5 créent des problèmes de qualité silencieux.

1. Changez l’ID du modèle en gemini-3.8-flash.

2. Supprimez les paramètres d’échantillonnage obsolètes : temperature, top_p et top_k sont ignorés ou rejetés sur Gemini 3.x, et frequency_penalty, presence_penalty et candidate_count déclenchent une erreur d’API active. Retirez ces 6 champs des anciennes configs.

3. Remplacez thinking_budget par thinking_level : utilisez uniquement low, medium ou high. L’ancienne valeur minimal renvoie une erreur de validation. Envoyer à la fois thinking_budget et thinking_level dans une même requête renvoie un 400.

4. Supprimez les tours de modèle préremplis : enlevez‑les de toute conversation construite, et assurez‑vous que le dernier tour utilisateur contient du texte non vide. Les historiques ne peuvent pas se terminer par un tour du modèle.

5. Standardisez les flux multi‑tours : appuyez‑vous sur previous_interaction_id au lieu de rejouer l’historique côté client. Vous devez repasser vos outils, system_instruction et generation_config à chaque tour où ils comptent.

Google publie la version de référence dans la documentation des modèles de l’API Gemini, avec un chemin automatisé si votre agent de code gère les « skills ». Lisez‑la vous‑même au moins une fois ; une migration automatisée ne vous dira pas pourquoi votre temperature=0.2 était là à l’origine.

Erreurs que vous verrez en production

Voici les 4 codes d’état pour lesquels prévoir des handlers, et leur signification concrète sur cette API :

Deux autres points :

• Définissez des timeouts explicites côté client lorsque vous combinez thinking_level: "high" avec de longues boucles d’outils, car une requête bloquée est pire qu’un échec, et l’assiduité accrue de 3.8 rend plus probables les raisonnements longs, pas moins. 

• Journalisez interaction.id avec chaque requête ; c’est votre poignée pour retrouver, déboguer ou supprimer les interactions stockées plus tard.

Dernières réflexions

Tout dans cet article remonte à 3 évolutions. L’Interactions API a changé la convention d’appel, thinking_level a remplacé tous les réglages d’échantillonnage que vous utilisiez, et l’état côté serveur via previous_interaction_id a rendu la relance PDF et la boucle d’outil des tours « en une ligne » plutôt que des relectures d’historique. Gemini 3.8 Flash n’a rien changé à cette interface ; il a changé l’effort que le modèle fournit en interne, d’où des mesures fraîches en 3.8 plutôt que reprises de 3.7.

Avant de prendre mes recommandations de niveaux pour argent comptant, pointez le script de comparaison sur une tâche de votre propre backlog ; le niveau qui gagne sur une course de relance de paiement peut perdre sur votre génération SQL. 

Quand un simple appel d’API ne suffit plus et que vous visez des systèmes d’IA en production, notre Associate AI Engineer for Developers track couvre tout le parcours, et l’ Associate AI Engineer for Data Scientists track fait de même côté data.