Forem: Antoine Laurent

Gemini 3.5 Flash contre GPT-5.5 contre Opus 4.7: Le modèle rapide peut-il battre les modèles phares?

Antoine Laurent — Wed, 20 May 2026 02:48:55 +0000

Trois versions de pointe ont été lancées en 33 jours : Claude Opus 4.7 d’Anthropic le 16 avril, GPT-5.5 d’OpenAI le 23 avril, puis Gemini 3.5 Flash de Google le 19 mai, avec une version Pro prévue en juin.

Essayez Apidog aujourd'hui

La comparaison n’est pas parfaitement symétrique : Opus 4.7 et GPT-5.5 sont des modèles phares, tandis que Gemini 3.5 Flash est une variante rapide et économique. La vraie question pour une équipe de dev n’est donc pas “quel modèle est le meilleur ?”, mais : quel modèle donne le meilleur ratio qualité / coût / latence pour votre workload ?

Réponse courte : Gemini 3.5 Flash gagne sur le coût, la vitesse, le contexte long et plusieurs workloads agentiques. Opus 4.7 reste plus sûr pour les refactorisations complexes et le suivi d’instructions exigeant. GPT-5.5 est très fort pour les agents CLI et l’efficacité en jetons.

La réponse en 30 secondes

Question	Meilleur choix
Boucle d’agent de production la moins chère	Gemini 3.5 Flash
Meilleur score SWE-Bench Verified	Opus 4.7
Meilleure efficacité en jetons à l’échelle	GPT-5.5
Meilleure récupération de contexte long 1M tokens	Gemini 3.5 Flash
Meilleure compréhension de graphiques et documents	Gemini 3.5 Flash
Meilleur agent CLI long terme	GPT-5.5
Meilleur suivi d’instructions multi-étapes	Opus 4.7
Sortie de jetons la plus rapide	Gemini 3.5 Flash
Meilleure refonte de code à l’échelle d’un dépôt	Opus 4.7

Il n’y a pas de gagnant unique. Le bon choix dépend du type de tâche, du budget par requête et du niveau de risque acceptable.

Chronologie des versions

Les trois modèles ont été publiés avec des objectifs différents :

Opus 4.7, 16 avril 2026 : modèle phare d’Anthropic, orienté raisonnement, code et tâches multi-étapes longues.
GPT-5.5, 23 avril 2026 : modèle de base entièrement ré-entraîné d’OpenAI depuis GPT-4.5, orienté efficacité agentique et réduction des coûts de sortie.
Gemini 3.5 Flash, 19 mai 2026 : variante rapide de Google, orientée coût bas, latence faible et exécution agentique. Gemini 3.5 Pro est prévu pour juin 2026.

Pour le contexte côté outils de codage, voir aussi Cursor Composer 2.5 vs Opus 4.7 vs GPT-5.5 et Gemini 3.1 Pro vs Opus 4.6 vs GPT-5.3.

Comparaison des prix

C’est ici que l’écart de catégorie est le plus visible.

Modèle	Entrée USD / 1M tokens	Sortie USD / 1M tokens	Notes
Gemini 3.5 Flash	~$1.50	~$9.00	Tier gratuit disponible
GPT-5.5	~$10	~$30	Entrée en cache moins chère
Claude Opus 4.7	~$15	~$75	Prix catalogue le plus élevé

Gemini 3.5 Flash est environ 6 à 10 fois moins cher en entrée et 3 à 8 fois moins cher en sortie. Pour les détails, consultez la répartition des prix de Gemini 3.5 Flash et les prix de GPT-5.5.

Pour un agent qui exécute des centaines de tours par tâche, le coût par million de tokens devient rapidement secondaire : ce qui compte est le coût complet par tâche réussie.

Une évaluation utile doit donc suivre au minimum :

coût_total = coût_input + coût_output
coût_par_tâche_réussie = coût_total / nombre_de_tâches_réussies

GPT-5.5 réduit partiellement l’écart grâce à une sortie plus courte : il produit parfois beaucoup moins de jetons qu’Opus 4.7 pour une tâche équivalente. Mais Flash garde l’avantage brut sur le prix.

Benchmarks de codage

Le codage est le terrain où Opus 4.7, GPT-5.5 et Gemini 3.5 Flash se différencient le plus.

SWE-Bench Verified : corrections de bugs isolées

Modèle	Score
Opus 4.7	87.6%
GPT-5.5	~85%
Gemini 3.5 Flash	Non rapporté séparément

Opus 4.7 reste en tête sur les corrections de bugs isolées. GPT-5.5 est proche. Flash n’a pas de score publié comparable, mais il est attendu qu’un modèle rapide soit moins performant que deux modèles phares sur ce benchmark précis.

À utiliser ainsi :

bug isolé, patch court, risque élevé : Opus 4.7 ou GPT-5.5 ;
bug routinier à gros volume : Gemini 3.5 Flash peut être plus rentable ;
pipeline de validation automatique : testez les trois et gardez celui qui maximise les patches acceptés par CI.

SWE-Bench Pro : corrections complexes multi-fichiers

Modèle	Score
Opus 4.7	64.3%
GPT-5.5	58.6%
Gemini 3.5 Flash	Non rapporté séparément

Les refactorisations multi-fichiers restent le point fort d’Opus 4.7. Si votre workflow ressemble à Cursor Composer ou Claude Code, Opus est le choix le plus sûr pour les changements profonds à l’échelle d’un dépôt.

Pour réduire le coût, un pattern efficace consiste à router les tâches :

si changement <= 1 fichier et faible risque:
    utiliser Gemini 3.5 Flash
sinon si refactorisation multi-fichiers:
    utiliser Opus 4.7
sinon:
    utiliser GPT-5.5 ou Opus selon coût/latence

Terminal-Bench 2.0 / 2.1 : agents CLI

Modèle	Score	Benchmark
GPT-5.5	82.7%	Terminal-Bench 2.0
Gemini 3.5 Flash	76.2%	Terminal-Bench 2.1
Opus 4.7	69.4%	Terminal-Bench 2.0

Les versions 2.0 et 2.1 ne sont pas strictement identiques, mais la tendance est claire : GPT-5.5 et Gemini 3.5 Flash sont solides pour les boucles d’agents CLI longues. GPT-5.5 garde l’avantage, tandis que Flash se rapproche avec un coût bien inférieur.

MCP Atlas : coordination multi-outils

Gemini 3.5 Flash obtient 83,6 % sur MCP Atlas, le benchmark utilisé par Google pour mesurer l’usage d’outils agentiques. OpenAI et Anthropic n’ont pas publié de chiffres directement comparables sur ce même benchmark.

En pratique, pour un agent multi-outils, testez surtout :

stabilité du format JSON ;
respect des arguments de fonction ;
capacité à corriger une erreur d’outil ;
nombre de tours nécessaires avant succès ;
coût total par tâche.

Travail agentique et tâches longues

Pour les tâches qui tournent plusieurs dizaines de minutes sans supervision :

Gemini 3.5 Flash : meilleur choix pour le coût par tâche, la vitesse de sortie et les workflows agentiques à gros volume.
GPT-5.5 : meilleur choix pour les agents CLI efficaces en tokens.
Opus 4.7 : meilleur choix quand la qualité de chaque tour compte plus que la latence ou le prix.

Si vous utilisez un modèle d’agent du type commande /goal avec Codex et Claude Code, le budget devient vite critique.

Un routeur simple peut suffire :

type TaskType = "cli_agent" | "repo_refactor" | "document_qa" | "visual_analysis" | "routine";

function selectModel(task: TaskType) {
  switch (task) {
    case "repo_refactor":
      return "claude-opus-4.7";
    case "cli_agent":
      return "gpt-5.5";
    case "document_qa":
    case "visual_analysis":
      return "gemini-3.5-flash";
    case "routine":
    default:
      return "gemini-3.5-flash";
  }
}

Fenêtre contextuelle et récupération de contexte long

Modèle	Entrée max	Sortie max
Gemini 3.5 Flash	1 million de tokens	64 000 tokens
GPT-5.5	400 000 tokens	128 000 tokens
Opus 4.7	1 million de tokens, bêta	64 000 tokens

Gemini 3.5 Flash est en tête du tableau publié par Google sur MRCR v2 à 1 million de tokens. Il devient donc un choix pratique pour :

questions-réponses sur longs PDF ;
analyse multi-documents ;
revue de contrats ;
exploration de bases de code ;
extraction d’informations dans de gros rapports.

Pour ces cas, Flash permet souvent d’éviter une étape de chunking complexe. Ce n’est pas toujours optimal, mais c’est simple à implémenter.

Exemple de stratégie :

1. Envoyer le document complet à Gemini 3.5 Flash.
2. Demander les passages pertinents + citations.
3. Si une décision critique est requise, faire relire uniquement les extraits par Opus 4.7 ou GPT-5.5.

Multimodal

Gemini 3.5 Flash est particulièrement fort sur les documents visuels et les graphiques :

CharXiv Reasoning : 84,2 %
MMMU-Pro : 83,6 %

OpenAI et Anthropic prennent aussi en charge les images sur leurs modèles phares, mais Flash ressort très compétitif au lancement pour les workflows qui combinent texte, captures d’écran, PDF et graphiques.

Cas d’usage typiques :

extraire des données depuis des captures d’écran ;
lire des graphiques dans un rapport ;
analyser un PDF scanné ;
comparer texte et image dans un même prompt ;
automatiser une revue de documents avec tableaux.

Si votre pipeline inclut aussi la génération d’images, voir Gemini 3 Pro Image vs Seedream.

Vitesse de sortie

La vitesse de streaming compte beaucoup pour les interfaces utilisateur.

Modèle	Vitesse de sortie relative
Gemini 3.5 Flash	~4× référence
GPT-5.5	référence
Opus 4.7	~0.7× référence

Les chiffres varient selon la région et la charge, mais la tendance est stable : Gemini 3.5 Flash diffuse beaucoup plus vite.

Pour un assistant de dev, cela change l’expérience :

autocomplétion plus réactive ;
feedback plus rapide dans le chat ;
meilleure perception de qualité ;
moins d’attente pendant les boucles d’agent.

Raisonnement, mathématiques et sciences

Benchmark	Flash	GPT-5.5	Opus 4.7
GPQA Diamond	Fort selon Google	Élevé	Élevé
Raisonnement mathématique	Fort	Fort	Fort
Écriture longue	Bon	Bon	Meilleur

Les trois modèles sont compétitifs en raisonnement. La différence la plus visible est qualitative : Opus 4.7 produit souvent une sortie plus narrative et mieux structurée pour les textes longs.

Pour les tâches scientifiques ou mathématiques, ne vous fiez pas seulement au benchmark. Ajoutez des tests de vérification :

- réponse finale correcte ;
- étapes de raisonnement cohérentes ;
- unités respectées ;
- calculs vérifiables ;
- absence d’invention de références.

Écosystème d’outils et intégrations

Opus 4.7 : Claude Code, MCP, API Anthropic, écosystème mature, Bitwarden Agent, support IDE large.
GPT-5.5 : OpenAI Codex, API Responses, intégration ChatGPT, function calling très établi.
Gemini 3.5 Flash : Antigravity, Gemini Enterprise Agent Platform, Gemini CLI, Android Studio, écosystème en croissance rapide.

Anthropic a un écosystème tiers très profond pour les agents de code. OpenAI garde une adoption développeur massive. Google rattrape rapidement avec Antigravity et Agent Platform.

Quand choisir quel modèle

Choisissez Gemini 3.5 Flash lorsque

vous avez un budget strict par tâche ;
la latence de streaming est importante ;
vous traitez de longs documents ;
vous analysez des PDF, graphiques ou captures d’écran ;
vous voulez une boucle d’agent crédible au coût le plus bas ;
vous êtes déjà sur Google Cloud ou Workspace ;
le volume est élevé et “suffisamment bon” vaut mieux que “parfait”.

Choisissez GPT-5.5 lorsque

l’efficacité en tokens est prioritaire ;
la tâche est un agent CLI long ;
vous voulez un écosystème d’outils tiers très large ;
ChatGPT est déjà dans le workflow de votre équipe ;
vous voulez suivre une configuration API complète : Comment utiliser l’API GPT-5.5.

Choisissez Opus 4.7 lorsque

la tâche est une refactorisation multi-fichiers ;
la qualité du code est plus importante que le coût ;
le suivi d’instructions multi-étapes est critique ;
vous produisez une écriture longue ou très soignée ;
vous utilisez déjà Claude Code avec le plan Claude.

Choisissez un mix lorsque

En production, le meilleur choix est souvent un routeur multi-modèles :

Flash pour la récupération et la préparation, Opus pour la décision finale ;
GPT-5.5 pour les agents CLI, Flash pour les documents et graphiques ;
Flash pour 80 % du trafic, Opus ou GPT-5.5 pour les 20 % complexes ;
les trois derrière un routeur qui choisit selon le type de tâche.

Exemple de routage par complexité :

interface ModelDecisionInput {
  tokenCount: number;
  hasImages: boolean;
  touchesMultipleFiles: boolean;
  requiresCliLoop: boolean;
  risk: "low" | "medium" | "high";
}

function routeModel(input: ModelDecisionInput) {
  if (input.hasImages || input.tokenCount > 300_000) {
    return "gemini-3.5-flash";
  }

  if (input.touchesMultipleFiles || input.risk === "high") {
    return "claude-opus-4.7";
  }

  if (input.requiresCliLoop) {
    return "gpt-5.5";
  }

  return "gemini-3.5-flash";
}

Comparaison des offres gratuites

Les trois modèles ont une voie d’accès gratuite ou limitée :

Gemini 3.5 Flash : clé API AI Studio, environ 1 500 requêtes par jour. Voir le guide gratuit Flash.
GPT-5.5 : requêtes gratuites limitées dans ChatGPT et passerelles décrites dans le guide gratuit GPT-5.5.
Opus 4.7 : limite quotidienne sur Claude.ai, plus les options du guide gratuit Opus 4.7.

Pour un développeur qui veut tester vite via API, Flash est le plus simple grâce à AI Studio et à ses quotas gratuits.

Comment tester ces modèles avec votre propre workload

Les benchmarks donnent une moyenne. Votre workload décide.

Construisez un petit harnais d’évaluation avec 20 tâches réelles :

Sélectionnez des prompts représentatifs.
Exécutez les trois modèles sur chaque prompt.
Mesurez réussite, coût, latence et nombre de tokens.
Notez les erreurs : JSON invalide, appel d’outil incorrect, refus, hallucination, sortie trop longue.
Relancez le test chaque semaine pour détecter la dérive.

Exemple de format de résultat :

{
  "task_id": "bugfix-014",
  "model": "gemini-3.5-flash",
  "success": true,
  "latency_ms": 2840,
  "input_tokens": 18200,
  "output_tokens": 940,
  "estimated_cost_usd": 0.035,
  "notes": "Patch accepté par la CI"
}

C’est là qu’Apidog est utile. Vous pouvez enregistrer les trois endpoints API — Gemini, OpenAI, Anthropic — comme requêtes paramétrées, stocker les clés en variables d’environnement, puis exécuter la même invite sur les trois modèles.

Configuration pratique :

Téléchargez Apidog.
Créez un espace de travail nommé Évaluation de modèles de pointe.

Créez trois requêtes : Flash, GPT-5.5, Opus 4.7.
Définissez les clés API comme variables d’environnement.
Créez un scénario de test qui exécute le même prompt sur les trois.
Ajoutez des assertions : JSON valide, champs obligatoires, latence maximale, chaînes attendues.
Exportez ou comparez les réponses côte à côte.

Deux jours de configuration valent mieux que trois mois de débat subjectif sur le modèle qui “semble” le meilleur.

Exemple de structure de test API

Vous pouvez standardiser vos requêtes avec un schéma commun côté application :

interface LlmRequest {
  model: string;
  system: string;
  prompt: string;
  temperature?: number;
  maxOutputTokens?: number;
}

interface LlmResult {
  model: string;
  output: string;
  latencyMs: number;
  inputTokens?: number;
  outputTokens?: number;
  costUsd?: number;
  success: boolean;
}

Puis connecter chaque fournisseur derrière un adaptateur :

interface LlmAdapter {
  run(request: LlmRequest): Promise<LlmResult>;
}

class GeminiAdapter implements LlmAdapter {
  async run(request: LlmRequest): Promise<LlmResult> {
    // Appel Gemini 3.5 Flash
    throw new Error("À implémenter");
  }
}

class OpenAIAdapter implements LlmAdapter {
  async run(request: LlmRequest): Promise<LlmResult> {
    // Appel GPT-5.5
    throw new Error("À implémenter");
  }
}

class AnthropicAdapter implements LlmAdapter {
  async run(request: LlmRequest): Promise<LlmResult> {
    // Appel Claude Opus 4.7
    throw new Error("À implémenter");
  }
}

L’objectif est de pouvoir changer de modèle sans réécrire votre application.

Ce qui change ensuite

Trois points à surveiller dans les 90 prochains jours :

Disponibilité générale de Gemini 3.5 Pro : la comparaison changera quand Google aura un modèle phare direct face à Opus 4.7 et GPT-5.5.
Réponse d’OpenAI : GPT-5.5 pourrait recevoir une mise à jour de mi-cycle ou une variante.
Prochain mouvement d’Anthropic : une actualisation de Sonnet ou Opus 4.8 serait cohérente avec le rythme du marché.

La bonne stratégie n’est pas de choisir un fournisseur pour toujours. C’est de garder votre harnais d’évaluation actif et de router les tâches selon les résultats réels.

FAQ

Gemini 3.5 Flash est-il vraiment compétitif avec Opus 4.7 et GPT-5.5 ?

Oui, dans sa catégorie. Il domine sur le coût, la vitesse, le contexte long et certains workloads agentiques. Pour les refactorisations complexes et l’écriture longue très soignée, les modèles phares restent meilleurs.

Pourquoi comparer un modèle rapide à des modèles phares ?

Parce que l’écart de coût est suffisamment important pour changer les décisions de production. La bonne question est : “Flash est-il suffisant pour cette tâche ?”

Opus 4.7 vaut-il son prix plus élevé ?

Oui si la qualité du code, la précision du suivi d’instructions ou l’écriture longue sont critiques. Non si vous exécutez des milliers de tours à faible risque.

Puis-je utiliser les trois via une seule API ?

Pas directement. Chaque fournisseur a ses endpoints et ses identifiants. Le plus propre est de créer une abstraction légère dans votre code ou d’utiliser un outil de test API pour comparer les appels.

Quand Gemini 3.5 Pro sera-t-il lancé ?

Juin 2026. Ce sera la comparaison plus directe avec Opus 4.7 et GPT-5.5.

Comment suivre les coûts avec trois fournisseurs ?

Suivez les tokens, la latence et le coût estimé par modèle. Dans Apidog, vous pouvez comparer l’historique des requêtes et compléter avec les tableaux de bord fournisseurs.

En résumé

Gemini 3.5 Flash : meilleur choix pour le coût, la vitesse, les documents longs, le multimodal et beaucoup de workloads agentiques.
GPT-5.5 : meilleur choix pour les agents CLI et l’efficacité en tokens.
Opus 4.7 : meilleur choix pour les refactorisations complexes, le suivi d’instructions exigeant et l’écriture longue.

Ne choisissez pas uniquement à partir des benchmarks publics. Construisez votre évaluation, testez vos vrais prompts, mesurez coût et latence, puis routez chaque tâche vers le modèle le plus rentable. Juin changera probablement encore la donne avec Gemini 3.5 Pro.

Comment utiliser Gemini 3.5 Flash gratuitement ?

Antoine Laurent — Wed, 20 May 2026 02:27:21 +0000

Gemini 3.5 Flash a été lancé le 19 mai 2026, et Google a conservé un niveau d’accès gratuit. Flash est disponible dès maintenant avec une clé API gratuite ; Pro arrive en juin. Si vous voulez utiliser Flash sans payer, voici les voies réellement exploitables côté développeur.

Essayez Apidog aujourd’hui

Ce guide se concentre sur la mise en place pratique : obtenir une clé, tester des appels API, comprendre les quotas et choisir le bon chemin selon votre usage.

Résumé rapide

Voie	Ce que vous obtenez	Limite
Application Gemini	Chat complet + saisie d’images avec Flash	Plafond quotidien de messages sur le niveau gratuit
Google AI Studio	Aire de jeux web avec contrôle des paramètres	Pas de quota strict dans l’interface
Clé API AI Studio	Accès REST/SDK à `gemini-3.5-flash`	~1 500 requêtes/jour
Crédits nouveau compte Vertex AI	Accès Flash orienté production	300 $ de crédit, 90 jours
CLI Gemini	Accès terminal à Flash via connexion Google	1 000 requêtes quotidiennes

Chaque voie répond à un besoin différent : discuter, prototyper une invite, intégrer Flash dans une application ou exécuter des scripts.

Voie 1 : Application Gemini, sans configuration

Utilisez cette voie si vous voulez simplement tester Flash dans une interface de chat.

Ouvrez gemini.google.com
Connectez-vous avec un compte Google
Dans le sélecteur de modèle, choisissez 3.5 Flash
Lancez une conversation

L’application prend en charge le texte, les images, les fichiers et l’édition de documents de type Canvas. Sur le niveau gratuit, vous disposez d’un plafond quotidien de messages qui se réinitialise chaque jour.

À utiliser pour :

rédaction et recherche sans script ;
analyse d’images sans API ;
comparaison avec d’autres modèles de chat gratuits.

À éviter pour :

une intégration logicielle ;
le traitement par lots ;
tout flux nécessitant une réponse programmable.

Voie 2 : Google AI Studio, l’aire de jeux navigateur

Google AI Studio est l’interface web pour prototyper avec Flash avant d’écrire du code.

Ouvrez aistudio.google.com
Connectez-vous
Cliquez sur Créer une nouvelle invite ou choisissez un modèle
Sélectionnez gemini-3.5-flash
Saisissez votre invite, puis cliquez sur Exécuter

AI Studio permet de tester rapidement :

température, top-K, top-P ;
instructions système ;
sortie structurée en JSON ;
invites multimodales avec plusieurs images ;
génération de code Python ou Node.js équivalent ;
export vers un appel d’API Flash.

AI Studio ne facture pas l’usage depuis le navigateur. C’est le meilleur point de départ pour valider vos invites avant une intégration API.

Voie 3 : Clé API gratuite Gemini 3.5 Flash

C’est la voie la plus utile pour les développeurs. Le même compte AI Studio peut générer une clé API gratuite compatible avec gemini-3.5-flash.

Obtenir la clé

Dans AI Studio, cliquez sur Obtenir une clé API
Choisissez ou créez un projet
Cliquez sur Créer une clé API
Copiez la clé et stockez-la dans un endroit sûr

Aucune carte de crédit n’est requise. La clé fonctionne immédiatement avec Flash. Pour le détail étape par étape, consultez le guide de la clé API Gemini gratuite.

Quotas du niveau gratuit

En mai 2026, le niveau gratuit pour gemini-3.5-flash est approximativement :

1 500 requêtes par jour
1 million de tokens par minute
15 requêtes par minute

Ces limites peuvent changer. Vérifiez toujours la page des tarifs Google avant de baser une application de production dessus. Pour le calcul détaillé des coûts au-delà du gratuit, consultez la répartition des tarifs Flash.

Tester la clé avec Python

import os
from google import genai

client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])

response = client.models.generate_content(
    model="gemini-3.5-flash",
    contents="Give me three startup ideas for API tooling in 2026."
)

print(response.text)

Tester la clé avec Node.js

import { GoogleGenAI } from "@google/genai";

const ai = new GoogleGenAI({
  apiKey: process.env.GEMINI_API_KEY,
});

const response = await ai.models.generateContent({
  model: "gemini-3.5-flash",
  contents: "Give me three startup ideas for API tooling in 2026.",
});

console.log(response.text);

Tester la clé avec curl

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.5-flash:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [
      {
        "parts": [
          {
            "text": "Hello Gemini 3.5 Flash"
          }
        ]
      }
    ]
  }'

Pour une configuration plus complète, incluant streaming et appels d’outils, consultez le guide de l’API Gemini 3.5 Flash.

Tester les requêtes Flash dans Apidog

Si vous avez 1 500 requêtes gratuites par jour, évitez de les gaspiller en relançant manuellement des appels mal formés. Apidog permet d’enregistrer votre endpoint Flash, de stocker la clé comme variable d’environnement et de rejouer les requêtes sans réécrire curl.

Flux recommandé :

Téléchargez Apidog
Créez une requête et collez le curl ci-dessus
Déplacez la clé API dans les variables d’environnement
Enregistrez la requête
Ajoutez des assertions sur la réponse
Rejouez-la après chaque modification d’invite

L’intérêt : vous gardez un historique des réponses et vous réduisez les appels inutiles pendant le débogage.

Voie 4 : Crédits Vertex AI pour nouveau compte Google Cloud

Si vous créez un nouveau compte Google Cloud, vous pouvez obtenir 300 $ de crédits valables 90 jours. Ces crédits couvrent Gemini 3.5 Flash via Vertex AI, avec des contrôles plus adaptés aux organisations.

Étapes :

Inscrivez-vous sur cloud.google.com
Confirmez le crédit de 300 $
Activez l’API Vertex AI
Créez un compte de service
Donnez-lui le rôle aiplatform.user
Téléchargez les identifiants JSON
Appelez Flash via le SDK Vertex AI

Exemple Python :

import vertexai
from vertexai.generative_models import GenerativeModel

vertexai.init(
    project="your-project-id",
    location="us-central1"
)

model = GenerativeModel("gemini-3.5-flash")
response = model.generate_content("Explain CAP theorem.")

print(response.text)

Vertex AI n’utilise pas le même plafond de requêtes par jour que le niveau gratuit d’AI Studio. Vous êtes limité par le crédit en dollars. Au tarif indicatif d’environ 1,50 $ / 9 $ par million de tokens, 300 $ peuvent couvrir plusieurs semaines d’usage modéré.

Points à surveiller :

le crédit expire après 90 jours ;
le crédit inutilisé est perdu ;
désactivez la conversion automatique vers un compte payant si vous ne voulez pas de facturation surprise ;
Vertex demande plus de configuration qu’AI Studio.

Voie 5 : CLI Gemini depuis le terminal

La CLI Gemini est le client terminal open source de Google. Elle s’authentifie avec votre compte Google et donne accès à un quota quotidien de 1 000 requêtes sur le niveau gratuit, sans clé API.

Installation :

npm install -g @google/gemini-cli

Lancement :

gemini

Dans la CLI, choisissez ensuite gemini-3.5-flash.

Cette voie convient bien pour :

scripts ponctuels ;
résumé de fichiers ou de bases de code ;
usage terminal sans manipuler de clé API ;
quota séparé de celui de votre clé API.

Elle est aussi une alternative gratuite à Claude Code pour certains workflows de développement, car elle peut lire des fichiers et exécuter des outils.

Évitez-la pour :

intégrations de production ;
contrôle HTTP bas niveau ;
workloads nécessitant un streaming API spécifique.

Voie 6 bonus : OpenRouter et passerelles tierces

Certaines passerelles agrègent plusieurs modèles d’IA et proposent un accès gratuit ou quasi gratuit à Flash. Ce modèle est détaillé dans l’article Obtenir une API Gemini gratuite illimitée.

À garder en tête :

la qualité varie ;
certaines passerelles ralentissent fortement les appels ;
vos prompts transitent par un tiers ;
n’envoyez pas de données sensibles ;
certaines plateformes utilisent des moyens de paiement ou contournements non standards.

Considérez cette option comme une solution de secours, pas comme une architecture principale. Pour construire sérieusement, privilégiez AI Studio ou Vertex AI.

Quelle voie choisir ?

Utilisez ce raccourci :

Vous voulez discuter ? Application Gemini
Vous voulez travailler vos prompts ? AI Studio
Vous construisez une application ? Clé API AI Studio
Vous voulez un quota plus large avec un compte GCP neuf ? Vertex AI
Vous préférez le terminal ? CLI Gemini
Vous acceptez les risques tiers ? OpenRouter ou passerelles similaires

Dans la pratique, beaucoup de développeurs combinent deux voies : clé AI Studio pour le développement quotidien, crédits Vertex AI pour des tests plus proches de la production.

Flash gratuit vs payant : quand passer au payant

Le niveau gratuit suffit à beaucoup de projets secondaires. Passez au payant si :

Vous atteignez 1 500 requêtes/jour plusieurs jours de suite.

Le temps passé à contourner les quotas coûtera plus cher que le passage au payant.
Vous avez besoin d’un débit plus élevé.

Le niveau gratuit est limité à 15 requêtes/minute.
Vous avez besoin de résidence des données ou de journaux d’audit.

Dans ce cas, utilisez Vertex AI avec un compte facturé.

Pour estimer le coût réel par token, les remises batch et différents scénarios d’usage, consultez le guide des tarifs Gemini 3.5 Flash.

Comparez aussi avec d’autres fournisseurs. GPT-5.5 et Claude Opus 4.7 ont leurs propres accès gratuits et limites. La comparaison Gemini 3.5 vs GPT-5.5 vs Opus 4.7 aide à choisir selon le workload.

Conseils pour économiser le quota gratuit

Quelques habitudes simples permettent de faire durer les 1 500 requêtes/jour :

Cachez les réponses idempotentes. Une même entrée ne doit pas appeler l’API plusieurs fois.
Utilisez le mode batch pour le volume. Le mode batch de l’API Gemini offre une réduction de 50 % sur les tâches non temps réel et utilise un quota séparé.
Forcez une sortie structurée. Un schéma JSON évite plusieurs appels de parsing ou de correction.
Pré-validez les entrées. Les assertions dans Apidog détectent les requêtes mal formées avant de consommer du quota.
Utilisez Flash par défaut. Quand Pro sera disponible, gardez-le pour les tâches qui justifient ses quotas plus stricts.

FAQ

Gemini 3.5 Flash est-il vraiment gratuit ?

Oui, avec des plafonds. L’application Gemini, AI Studio et la clé API AI Studio donnent un accès gratuit à Flash avec des quotas quotidiens.

Faut-il une carte de crédit pour obtenir une clé API gratuite ?

Non. Le niveau gratuit d’AI Studio ne demande pas de carte. Vertex AI demande une carte pour activer le crédit de 300 $, mais la facturation dépend de la mise à niveau.

Peut-on utiliser la clé gratuite en production ?

Techniquement oui, mais le plafond de 1 500 requêtes/jour peut être vite atteint. Pour une vraie production, utilisez un compte facturé ou Vertex AI.

Gemini 3.5 Pro sera-t-il aussi gratuit ?

Google a historiquement proposé un accès gratuit aux modèles Pro en disponibilité générale. Pro devrait arriver dans AI Studio avec des quotas plus stricts.

Peut-on utiliser Flash gratuit dans Cursor ou VS Code ?

Oui, si l’outil accepte des clés API personnalisées. Le principe est le même que dans le tutoriel Gemini 3.0 Pro avec Cursor : remplacez simplement le modèle par gemini-3.5-flash.

Existe-t-il des journaux d’utilisation ?

Oui. Dans AI Studio, ouvrez votre projet et consultez l’onglet Activité.

Quel est le piège ?

Deux points :

Le niveau gratuit peut utiliser vos prompts pour améliorer les modèles Google, avec une option de désactivation dans les paramètres d’AI Studio.
Les limites du niveau gratuit peuvent changer sans préavis.

Projet de démarrage : résumer une URL avec Flash

Pour valider le flux complet, construisez une petite API qui reçoit une URL, récupère la page et demande à Flash de la résumer.

Exemple minimal :

import os
import requests
from google import genai

client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])

def summarize_url(url):
    html = requests.get(url).text

    response = client.models.generate_content(
        model="gemini-3.5-flash",
        contents=f"Summarize this webpage in 3 bullets:\n\n{html[:50000]}"
    )

    return response.text

print(summarize_url("https://blog.google/"))

Connectez ensuite cette API dans Apidog pour tester la requête et la réponse, puis déployez-la sur Cloud Run ou votre plateforme d’hébergement. Si ce flux fonctionne, vous maîtrisez le parcours Flash gratuit de bout en bout.

Comment utiliser l'API Gemini 3.5 Flash ?

Antoine Laurent — Wed, 20 May 2026 02:18:39 +0000

L'API Gemini 3.5 Flash a été mise en ligne avec le lancement du modèle le 19 mai 2026. Flash est la seule variante de la famille 3.5 disponible aujourd'hui ; Pro sera disponible en juin. Ce guide vous montre comment configurer Flash côté développeur : obtenir une clé, effectuer un premier appel, gérer le multimodal, le streaming, les outils, la sortie JSON et tester l’intégration avec Apidog.

Essayez Apidog aujourd’hui

Si vous avez déjà utilisé l'API Gemini, le changement principal est le nom du modèle : gemini-3.5-flash. Si vous démarrez de zéro, vous pouvez envoyer une requête Flash fonctionnelle en quelques minutes.

Ce que vous obtenez avec l'API Gemini 3.5 Flash

À retenir avant d’intégrer le modèle :

gemini-3.5-flash : disponible maintenant, rapide, économique et multimodal
Même point d'accès de style OpenAPI : remplacement direct pour les projets qui utilisent déjà Gemini 3 ou 3.1
Niveau gratuit sur AI Studio : environ 1 500 requêtes/jour sans carte de crédit

Capacités exposées via l'API Flash :

Contexte d'entrée de 1M de tokens, 64K tokens de sortie
Entrée texte + image, sortie texte + structurée
Appel de fonction natif et utilisation d'outils
Réponses en streaming
Récupération sur contexte long
Raisonnement sur graphiques et documents

Pour les détails de tarification, y compris les tarifs par token et les remises en mode batch, consultez le guide de tarification de Gemini 3.5 Flash.

Étape 1 : obtenir une clé API Gemini 3.5 Flash

Vous avez deux options selon votre usage : AI Studio pour démarrer rapidement, Vertex AI pour la production.

Option A : Google AI Studio

Ouvrez aistudio.google.com
Connectez-vous avec un compte Google
Cliquez sur Obtenir une clé API
Sélectionnez un projet existant ou créez-en un
Cliquez sur Créer une clé API
Copiez la clé et stockez-la dans une variable d’environnement

Exemple :

export GEMINI_API_KEY="votre-cle-api"

Le processus est le même que dans le guide de la clé API Gemini gratuite. La clé fonctionne immédiatement avec gemini-3.5-flash.

Option B : Vertex AI pour la production

Utilisez Vertex AI si vous avez besoin de facturation centralisée, IAM, journaux d’audit et contrôles organisationnels.

Activez l’API Vertex AI dans la Google Cloud Console
Créez un compte de service avec le rôle aiplatform.user
Téléchargez les identifiants JSON
Authentifiez-vous avec :

gcloud auth application-default login

ou configurez le fichier JSON comme identifiant d’application.

La plupart des équipes commencent avec AI Studio, puis migrent vers Vertex AI lorsque les contraintes de production l’exigent.

Étape 2 : installer le SDK

Le SDK officiel Google GenAI est disponible pour Python, Node.js, Go et Java.

# Python
pip install -U google-genai

# Node.js
npm install @google/genai

# Go
go get google.golang.org/genai

Vous pouvez aussi appeler directement l’API REST avec curl, sans SDK.

Étape 3 : effectuer un premier appel Flash

Python

import os
from google import genai

client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])

response = client.models.generate_content(
    model="gemini-3.5-flash",
    contents="Explain how OAuth 2.0 PKCE flow works in 3 short paragraphs."
)

print(response.text)

Node.js

import { GoogleGenAI } from "@google/genai";

const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });

const response = await ai.models.generateContent({
  model: "gemini-3.5-flash",
  contents: "Explain how OAuth 2.0 PKCE flow works in 3 short paragraphs.",
});

console.log(response.text);

curl

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.5-flash:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [{
      "parts": [{"text": "Explain how OAuth 2.0 PKCE flow works in 3 short paragraphs."}]
    }]
  }'

À ce stade, l’intégration minimale fonctionne. Vous pouvez ensuite ajouter le streaming, les entrées multimodales, les outils ou la validation JSON.

Réponses en streaming

Le streaming est utile si votre interface doit afficher la réponse progressivement au lieu d’attendre la sortie complète.

Python

stream = client.models.generate_content_stream(
    model="gemini-3.5-flash",
    contents="Write a 5-step tutorial on writing a REST API client in Go."
)

for chunk in stream:
    print(chunk.text, end="", flush=True)

Node.js

const stream = await ai.models.generateContentStream({
  model: "gemini-3.5-flash",
  contents: "Write a 5-step tutorial on writing a REST API client in Go.",
});

for await (const chunk of stream) {
  process.stdout.write(chunk.text);
}

En REST brut, remplacez le suffixe :

:generateContent

par :

:streamGenerateContent

Entrée multimodale avec Flash

Gemini 3.5 Flash accepte les images en plus du texte. C’est utile pour extraire des données depuis des tableaux de bord, graphiques, captures d’écran ou documents visuels.

Python : image depuis le disque

import os
from google import genai
from google.genai import types

client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])

with open("dashboard.png", "rb") as f:
    image_bytes = f.read()

response = client.models.generate_content(
    model="gemini-3.5-flash",
    contents=[
        types.Part.from_bytes(data=image_bytes, mime_type="image/png"),
        "Extract every metric in this dashboard as a JSON object."
    ]
)

print(response.text)

Types MIME pris en charge :

image/png
image/jpeg
image/webp
image/heic
image/heif

Les PDF et les vidéos peuvent également être utilisés via types.Part.from_uri().

Appel de fonction et utilisation d’outils avec Flash

L’appel d’outils permet au modèle de demander l’exécution d’une fonction externe au lieu de tout générer en texte libre.

Exemple : déclarer un outil météo.

from google.genai import types

weather_tool = types.Tool(
    function_declarations=[{
        "name": "get_current_weather",
        "description": "Get the current weather for a city.",
        "parameters": {
            "type": "object",
            "properties": {
                "city": {"type": "string", "description": "City name"},
                "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}
            },
            "required": ["city"]
        }
    }]
)

response = client.models.generate_content(
    model="gemini-3.5-flash",
    contents="What's the weather in Singapore right now?",
    config=types.GenerateContentConfig(tools=[weather_tool])
)

for part in response.candidates[0].content.parts:
    if part.function_call:
        print(f"Call: {part.function_call.name}")
        print(f"Args: {dict(part.function_call.args)}")

Le modèle renvoie un objet function_call avec :

le nom de la fonction
les arguments à transmettre

Ensuite, votre application exécute la fonction localement, renvoie le résultat au modèle et continue la conversation. Ce modèle correspond à celui déjà utilisé avec l’API Gemini 3 Flash.

Sortie structurée en JSON

Pour éviter de parser du texte libre, forcez une sortie JSON avec un type MIME et un schéma.

response = client.models.generate_content(
    model="gemini-3.5-flash",
    contents="List 3 popular API testing tools with their pricing.",
    config=types.GenerateContentConfig(
        response_mime_type="application/json",
        response_schema={
            "type": "array",
            "items": {
                "type": "object",
                "properties": {
                    "name": {"type": "string"},
                    "price_per_month": {"type": "number"},
                    "free_tier": {"type": "boolean"}
                },
                "required": ["name", "free_tier"]
            }
        }
    )
)

import json
data = json.loads(response.text)

Cette approche réduit les erreurs côté application : pas de regex, moins de retries, validation plus simple.

Tarification à partir de mai 2026

Tarifs à la consommation pour gemini-3.5-flash :

Niveau	Entrée	Sortie
Standard	~1,50 $ / 1M de tokens	~9,00 $ / 1M de tokens
Entrée mise en cache	tarif réduit	s.o.
Mode batch	~50% de réduction	~50% de réduction

Pour les charges de travail par lots, le mode batch de l'API Gemini offre une réduction de 50 % sur les tâches qui ne nécessitent pas une latence en temps réel.

Pour le calcul complet de la tarification, y compris les scénarios de coûts pour SaaS et boucles d’agents, consultez la ventilation de la tarification Flash. Pour la référence officielle, consultez la tarification de l'API Gemini Developer.

Tester votre intégration Gemini 3.5 Flash avec Apidog

Un appel SDK fonctionnel ne suffit pas pour une intégration de production. Vous devez aussi tester :

les fragments de streaming
la validation des appels d’outils
les charges utiles multimodales
les retries
les erreurs HTTP
les limites de débit
la forme des réponses JSON

Apidog permet de tester toute la surface de l’API Gemini Flash dans un seul espace de travail :

Enregistrer le point d'accès Flash comme requête : collez l’URL complète, ajoutez x-goog-api-key, puis envoyez la requête
Comparer plusieurs versions de modèle : remplacez gemini-3.5-flash par gemini-3-flash dans la même requête
Streamer les réponses : visualisez les fragments au fur et à mesure de leur arrivée
Valider le JSON : ajoutez des assertions pour détecter les dérives de schéma
Simuler le point d'accès Flash : testez votre code aval sans consommer de quota
Construire des scénarios d’agents : enchaînez plusieurs appels Flash et validez les appels d’outils entre chaque étape

Pour démarrer :

Téléchargez Apidog
Créez une nouvelle requête
Collez l’URL REST de Flash
Ajoutez l’en-tête x-goog-api-key
Importez l’extrait curl de cet article
Envoyez la requête et inspectez la réponse

Gestion des erreurs et limites de débit

Les codes HTTP importants :

400 : requête invalide, souvent un tableau contents mal formé ou un type MIME non pris en charge
401 : clé API invalide
403 : quota épuisé ou modèle non activé
429 : limite de débit atteinte
500/503 : erreur côté serveur, à réessayer avec temporisation exponentielle

Ajoutez une boucle de retry autour de vos appels :

import time
from google import genai

def call_with_retry(client, model, prompt, max_retries=3):
    for attempt in range(max_retries):
        try:
            return client.models.generate_content(
                model=model,
                contents=prompt
            )
        except Exception:
            if attempt == max_retries - 1:
                raise
            time.sleep(2 ** attempt)

Les quotas du niveau gratuit sont réinitialisés quotidiennement : environ 15 requêtes par minute et 1 500 par jour sur Flash. Les quotas de production sont réinitialisés par minute et par jour.

Pour les tâches à haut débit, évaluez le mode batch ou prévoyez une solution de repli vers Gemini 3 Flash lorsque les limites sont atteintes.

Migration de Gemini 3.1 vers 3.5 Flash

Dans la plupart des projets, la migration consiste à changer le nom du modèle.

# Avant
model="gemini-3.1-pro"  # ou gemini-3.1-flash

# Après
model="gemini-3.5-flash"

Après le changement, vérifiez :

Schémas d’outils : réexécutez vos tests de function calling
Streaming UI : adaptez l’interface si les fragments arrivent plus vite
Budgets de tokens : conservez vos limites, mais surveillez les sorties
Refus et garde-fous : comparez les réponses sur vos cas limites

Pour un guide plus détaillé, le guide de l'API Gemini 3.1 Pro couvre le modèle SDK et reste transférable.

Modèles d’implémentation courants

Analyse de documents à contexte long

with open("large_report.pdf", "rb") as f:
    pdf_bytes = f.read()

response = client.models.generate_content(
    model="gemini-3.5-flash",
    contents=[
        types.Part.from_bytes(data=pdf_bytes, mime_type="application/pdf"),
        "Summarize the financial outlook from this report in 5 bullet points."
    ]
)

Le contexte de 1M de tokens de Flash permet de traiter des PDF volumineux sans découpage manuel dans de nombreux cas.

Boucle d’agent avec appels d’outils

conversation = [
    {
        "role": "user",
        "parts": [{"text": "Book me a flight to Tokyo"}]
    }
]

while True:
    response = client.models.generate_content(
        model="gemini-3.5-flash",
        contents=conversation,
        config=types.GenerateContentConfig(
            tools=[flight_search_tool, booking_tool]
        )
    )

    part = response.candidates[0].content.parts[0]

    if not part.function_call:
        print(part.text)
        break

    result = execute_tool(part.function_call)

    conversation.append({
        "role": "model",
        "parts": [part]
    })

    conversation.append({
        "role": "user",
        "parts": [{"function_response": result}]
    })

Ce modèle est utile pour les agents qui doivent sélectionner un outil, exécuter une action externe, puis continuer la conversation avec le résultat.

FAQ

Existe-t-il un niveau gratuit pour l'API Gemini 3.5 Flash ?

Oui, via Google AI Studio, avec des quotas quotidiens d’environ 1 500 requêtes/jour. Aucune carte de crédit requise.

Flash prend-il en charge les points d'accès compatibles OpenAI ?

Oui. Google expose un adaptateur compatible OpenAI à l’adresse /v1beta/openai/. Vous pouvez configurer base_url dans un SDK OpenAI et utiliser votre clé Gemini. Le nom du modèle reste gemini-3.5-flash.

Puis-je utiliser Flash avec LangChain ou LlamaIndex ?

Oui. Les deux disposent d’intégrations Gemini natives. Passez model="gemini-3.5-flash" dans leurs wrappers respectifs.

Quand Gemini 3.5 Pro sera-t-il disponible ?

Juin 2026 selon l’annonce de lancement de Google. D’ici là, Flash est la seule variante 3.5 disponible.

Quelle est la taille d'image maximale pour Flash ?

La recommandation est 3072×3072. Les images plus grandes sont rééchantillonnées. Pour les workflows OCR, consultez le flux de travail OCR de Gemini 2.0 Flash.

Comment tester les points d'accès de streaming dans Apidog ?

Ouvrez la requête, utilisez :streamGenerateContent comme suffixe du point d’accès, puis envoyez la requête. Apidog affiche les fragments SSE au fur et à mesure.

Où consulter les journaux de l'API ?

Dans AI Studio sous Activité, ou dans Vertex AI sous Explorateur de journaux pour les déploiements de production.

Quoi construire en premier

Projets simples à lancer avec Flash :

Robot Q&A PDF : injectez un PDF dans le contexte, posez des questions, retournez des réponses citées
Pipeline graphique-vers-JSON : envoyez une capture de tableau de bord, extrayez des métriques structurées
Agent de support client : connectez l’appel de fonction à votre CRM
Assistant de révision de code : analysez des diffs multi-fichiers avec sortie structurée
Agent de recherche interne : combinez le contexte long avec des appels vers vos API internes

Le workflow reste le même : écrivez l’invite, appelez le SDK, validez la réponse avec Apidog, puis déployez.

Gemini 3.5 Flash : Le Nouveau Modèle Rapide de Google Expliqué

Antoine Laurent — Wed, 20 May 2026 02:18:02 +0000

Google a lancé Gemini 3.5 Flash le 19 mai 2026. C’est la variante rapide et économique de la famille Gemini 3.5, et le seul modèle 3.5 utilisable dès maintenant. Gemini 3.5 Pro est annoncé pour juin 2026, mais Flash est déjà le modèle à tester pour les charges de travail de production : agents, automatisation, codage, multimodal et streaming.

Essayez Apidog aujourd’hui

Gemini 3.5 Flash vise les workloads qui tournent réellement en 2026 : boucles d’agents longues, automatisation de terminaux, codage multifichier, analyse de documents multimodaux et chat en continu. D’après Google, il génère environ 4 fois plus vite que les autres modèles de pointe côté jetons de sortie, avec un coût par tâche inférieur à la moitié.

Ce guide résume ce qui change, comment l’appeler, comment l’évaluer, et comment l’intégrer dans une pile de test API avec Apidog.

Faits saillants sur Gemini 3.5 Flash

Date de sortie : 19 mai 2026
Variante disponible : Gemini 3.5 Flash
Gemini 3.5 Pro : annoncé pour juin 2026
Fenêtre contextuelle : 1M de jetons en entrée, 64K en sortie
Modalités : texte, images, code, génération graphique
Benchmarks clés :
- 76,2 % sur Terminal-Bench 2.1
- 84,2 % sur CharXiv Reasoning
- 83,6 % sur MCP Atlas
- 1656 Elo sur GDPval-AA
Vitesse : environ 4 fois plus rapide en jetons de sortie/seconde que les autres modèles de pointe
Coût : moins de la moitié du coût de modèles comparables pour les tâches d’agent
Nom API : gemini-3.5-flash
Accès : application Gemini, mode IA dans la recherche, Google Antigravity, API Gemini, AI Studio, Android Studio, Gemini Enterprise

Pour les détails de prix, les limites gratuites et les scénarios de coûts réels, consultez le guide de tarification Gemini 3.5 Flash.

Ce qui change par rapport à Gemini 3 et 3.1

Gemini 3.5 Flash s’appuie sur Gemini 3 Flash et Gemini 3.1 Pro, avec cinq améliorations concrètes.

1. Les agents tiennent mieux sur la durée

Flash gère mieux les chaînes de tâches longues :

meilleur suivi d’état ;
appels d’outils dans le bon ordre ;
dispatch de sous-agents plus robuste ;
moins de boucles inutiles sur une même étape.

C’est important si vous construisez un agent qui doit exécuter plusieurs appels API, lire des fichiers, corriger une erreur, puis reprendre le workflow.

2. Le code généré est plus exploitable

Flash progresse surtout sur :

les refactorisations multifichiers ;
les tâches longues via CLI ;
les modifications progressives dans une base de code ;
les assistants de développement intégrés dans des outils.

3. La génération graphique devient directement utile

Le modèle peut produire des interfaces web, des SVG et des diagrammes intégrés sans passer systématiquement par un modèle image séparé.

Exemples de prompts utiles :

Génère un dashboard HTML/CSS/JS pour visualiser la latence moyenne, le taux d’erreur et le coût par requête d’une API LLM.

Crée un diagramme SVG expliquant le flux entre client, API Gateway, service d’agent, outil externe et base de données.

4. La sortie est plus rapide

Google annonce environ 4 fois plus de jetons/seconde en sortie que les autres modèles de pointe. Pour les développeurs, cela change surtout les UX de streaming :

réponses visibles plus tôt ;
chat plus fluide ;
génération de code plus rapide ;
agents moins coûteux en temps d’attente.

5. Les garde-fous sont élargis

Google mentionne des mesures de sécurité cybernétiques et CBRN renforcées, ainsi que des outils d’interprétabilité pour expliquer certains refus ou redirections.

Le mouvement est clair : Google optimise Flash pour les workloads d’agents en production, pas uniquement pour le chat. C’est la même direction que celle prise par OpenAI et Anthropic avec GPT-5.5 et Claude Opus 4.7.

Benchmarks de Gemini 3.5 Flash

Chiffres publiés par Google :

Benchmark	Ce qu’il teste	Gemini 3.5 Flash
Terminal-Bench 2.1	Flux de travail CLI à long terme	76,2 %
MCP Atlas	Coordination multi-outils	83,6 %
CharXiv Reasoning	Interprétation de graphiques et diagrammes	84,2 %
GDPval-AA	Valeur agentique générale	1656 Elo
MRCR v2, contexte 1M	Récupération de contexte long	En tête du tableau de Google

Flash ressort particulièrement bien sur :

le raisonnement sur graphiques ;
les agents multi-outils ;
la récupération d’information dans un contexte long.

Il ne domine pas partout. Sur SWE-Bench Verified pur, la compétition reste serrée entre Opus 4.7 et GPT-5.5. Si votre seul KPI est la correction de bugs en un seul passage, ces modèles restent très compétitifs. Si votre KPI est une longue exécution d’agent à coût réduit, Flash devient intéressant.

Pour une comparaison plus détaillée, consultez Gemini 3.5 Flash vs GPT-5.5 vs Opus 4.7.

La famille Gemini 3.5

Gemini 3.5 Flash

Flash est disponible via :

AI Studio ;
API Gemini ;
application Gemini ;
mode IA dans la recherche ;
Antigravity ;
Android Studio ;
Gemini Enterprise.

Les prix annoncés au lancement sont d’environ :

1,50 $ / 1M jetons d’entrée ;
9,00 $ / 1M jetons de sortie.

C’est plus élevé que 3.1 Flash-Lite, mais toujours nettement inférieur aux modèles concurrents de niveau Pro. Pour le batch, l’entrée en cache et les tarifs Vertex, consultez le guide de tarification complet.

Flash est particulièrement adapté à :

boucles d’agents à haut débit ;
compréhension de graphiques et documents ;
scripts de test avec Apidog quand la latence compte ;
interfaces de chat en streaming ;
analyse de documents jusqu’à 1M de jetons sans découpage manuel.

Gemini 3.5 Pro

Gemini 3.5 Pro est annoncé, mais pas encore livré. Google le positionne comme la variante agentique haut de gamme : tâches autonomes longues, recherches approfondies, meilleurs scores de classement.

Tant que Pro n’est pas disponible, Flash est la variante à tester et intégrer.

Et Gemini 3.5 Nano ?

Google n’a pas lancé de variante 3.5 Nano. L’inférence sur appareil repose encore sur 3.1 Flash-Lite. Une annonce 3.5 Nano pourrait arriver plus près d’un prochain cycle Pixel.

Où utiliser Gemini 3.5 Flash

Six surfaces ont été livrées au lancement :

Application Gemini : accès mondial, niveaux gratuit et payant.
Mode IA dans la recherche Google : réponses et suivis.
Google Antigravity : plateforme d’agents pour automatisation utilisateur.
API Gemini : point d’entrée développeur via AI Studio.
Android Studio : assistance au codage pour les développeurs Android.
Gemini Enterprise + plateforme d’agents : runtime d’agents géré pour les organisations.

La nouvelle surface la plus notable est Gemini Spark, un agent personnel qui fonctionne 24h/24 et 7j/7 sur votre compte. Spark utilise Flash en coulisses et se connecte au contexte Gmail, Agenda et Drive.

Les agents d’information dans la recherche sont aussi nouveaux : ils suivent des sujets et regroupent des mises à jour sans que vous relanciez manuellement les requêtes.

Démarrer avec Gemini 3.5 Flash

Vous avez quatre chemins principaux.

1. Utiliser l’application Gemini

Allez sur gemini.google.com, choisissez 3.5 Flash dans le sélecteur de modèle, puis testez vos cas d’usage :

recherche ;
rédaction ;
génération de code ;
analyse d’image ;
résumé de document.

C’est le chemin le plus simple pour valider rapidement la qualité du modèle.

2. Utiliser Google AI Studio

Allez sur ai.google.dev, connectez-vous, puis générez une clé API. Flash est disponible sur le niveau gratuit avec environ 1 500 requêtes par jour au lancement.

Si vous avez déjà utilisé l’API Google Gemini, le schéma reste similaire :

créer une clé API ;
définir GEMINI_API_KEY ;
utiliser le modèle gemini-3.5-flash ;
envoyer la requête.

Exemple d’environnement :

export GEMINI_API_KEY="votre_cle_api"

Consultez aussi le guide de clé API Gemini gratuite ou le guide gratuit spécifique à Flash.

3. Utiliser l’API Gemini en production

En production, utilisez le même modèle avec un compte facturé. Le nom du modèle est :

gemini-3.5-flash

Exemple de structure de test avec curl :

curl -X POST "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.5-flash:generateContent?key=$GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [
      {
        "parts": [
          {
            "text": "Explique comment migrer une API REST vers un workflow agentique testé automatiquement."
          }
        ]
      }
    ]
  }'

Pour des exemples complets en Python, Node et curl, ainsi que les modèles de streaming, d’appel d’outils et de multimodal, consultez Comment utiliser l’API Gemini 3.5 Flash.

Lorsque vous intégrez Flash dans votre pile, testez le point de terminaison comme n’importe quelle API critique. Apidog permet de gérer les requêtes, réponses, scénarios de streaming et charges utiles multimodales dans un même espace de travail.

4. Utiliser Gemini Enterprise

Pour les organisations, Gemini Enterprise ajoute :

journaux d’audit ;
résidence des données ;
runtime de plateforme d’agents ;
intégration gérée pour les équipes.

C’est généralement le chemin à considérer après un prototype validé via l’API développeur.

Cas d’usage où Gemini 3.5 Flash est solide

Boucles d’agents longues à faible coût

Le score MCP Atlas de 83,6 % suggère une meilleure coordination multi-outils. En pratique, cela aide pour des workflows comme :

lire une demande utilisateur ;
appeler une API ;
analyser la réponse ;
corriger une erreur ;
appeler un autre outil ;
produire une sortie finale structurée.

Raisonnement sur graphiques et documents

Avec CharXiv à 84,2 %, Flash devient pertinent pour :

rapports PDF ;
documents avec graphiques ;
tableaux de bord exportés ;
schémas techniques ;
analyse d’images contenant du texte ou des diagrammes.

Génération d’interfaces interactives

Vous pouvez demander directement :

Génère une page HTML avec un graphique de coût par requête, un tableau des erreurs API et un filtre par modèle LLM.

Le bond de qualité graphique par rapport à 3.1 Flash-Lite est l’une des améliorations les plus visibles.

Workloads sensibles au coût

Google présente Flash comme coûtant moins de la moitié des autres modèles de pointe pour les tâches d’agent. Même avec prudence, le coût par tâche devient intéressant pour des agents longs comparés à Opus 4.7 ou GPT-5.5.

Les détails sont dans l’analyse des prix.

Limites à connaître

Gemini 3.5 Flash n’est pas une solution universelle.

SWE-Bench Verified pur : Opus 4.7 reste devant avec 87,6 % sur les benchmarks de correction de bugs isolés.
Voix : la pile vocale Gemini est séparée. Pour ce cas, comparez avec Grok Voice vs GPT-Realtime.
Écosystème d’outils : OpenAI et Anthropic ont encore une avance sur certains adaptateurs tiers. Google rattrape avec Antigravity, mais l’écosystème reste plus jeune.

Tester correctement Gemini 3.5 Flash

Avant de router du trafic production vers Flash, construisez un petit banc d’évaluation.

Étape 1 : définir un jeu de prompts représentatifs

Incluez les vrais cas de votre application :

- prompts courts ;
- prompts longs ;
- appels d’outils ;
- entrées multimodales ;
- erreurs attendues ;
- sorties JSON strictes ;
- scénarios de streaming.

Étape 2 : comparer avec votre modèle actuel

Exécutez les mêmes prompts sur :

gemini-3.5-flash ;
votre modèle actuel ;
éventuellement un modèle de référence.

Étape 3 : mesurer ce qui compte

Mesurez au minimum :

latence ;
coût en jetons ;
succès de la tâche aval ;
stabilité du schéma de réponse ;
exactitude des appels d’outils ;
taux de refus ;
dérives entre versions mineures.

Étape 4 : automatiser les tests API

Avec Apidog, vous pouvez enregistrer une suite de tests pour les points de terminaison Gemini Flash, y compris le streaming. Cela permet de rejouer les mêmes prompts, comparer les réponses et vérifier les charges utiles de bout en bout.

Vous pouvez télécharger Apidog pour configurer ces tests localement.

Conseils de migration de Gemini 3.1 vers 3.5 Flash

Si vous utilisez déjà Gemini 3.1, la migration ressemble souvent à un simple changement de nom de modèle.

Avant :

gemini-3.1-flash

Après :

gemini-3.5-flash

Points à vérifier :

Budgets de jetons : 1M en entrée / 64K en sortie reste stable.
Schémas d’outils : les définitions de fonctions existantes doivent être retestées, mais le modèle reste compatible.
Streaming : la sortie étant plus rapide, vérifiez que votre UI peut suivre.
Coûts : recalculez vos projections avec le guide de tarification Flash.
Sécurité : les réponses de refus peuvent changer ; relancez vos tests red team.

Pour plus de détails SDK, consultez le guide de l’API Google Gemini 3.

FAQ

Quand Gemini 3.5 Pro sera-t-il disponible ?

Google a annoncé « un déploiement le mois prochain » le 19 mai 2026. Il faut donc s’attendre à une disponibilité en juin 2026 via AI Studio, l’API Gemini et Gemini Enterprise. D’ici là, Flash est la seule variante 3.5 appelable.

Gemini 3.5 Flash est-il gratuit ?

Oui, avec quotas quotidiens. L’application Gemini et AI Studio permettent d’utiliser Flash sans paiement initial. Consultez le guide gratuit Flash et Obtenir l’API Gemini illimitée gratuite.

Gemini 3.5 Flash prend-il en charge l’appel de fonctions ?

Oui. L’appel d’outils et le dispatch de sous-agents sont des cas d’usage clés. Le score MCP Atlas de 83,6 % est l’indicateur principal cité.

Comment Flash se compare-t-il à Opus 4.7 et GPT-5.5 ?

Flash est fort sur :

coût ;
vitesse de sortie ;
raisonnement sur graphiques ;
agents multi-outils.

Opus 4.7 reste très fort sur SWE-Bench Pro et l’écriture longue. GPT-5.5 reste compétitif sur l’efficacité en jetons. Consultez la comparaison à trois.

Peut-on exécuter Gemini 3.5 Flash localement ?

Non. Il n’existe pas de version open-weights. Pour l’inférence locale, consultez plutôt les meilleurs LLM locaux de 2026.

Gemini 3.5 Flash fonctionne-t-il avec Cursor ?

Oui, via l’API Gemini standard. Le schéma est similaire à Gemini 3.0 Pro avec Cursor.

Quel est le nom du modèle API ?

Utilisez :

gemini-3.5-flash

Ce que cela implique pour votre pile

Si vous avez déjà une fonctionnalité IA en production :

Vous utilisez 3.1 Flash : testez 3.5 Flash en parallèle. Le gain de vitesse en streaming peut justifier la migration.
Vous utilisez Opus 4.7 ou GPT-5.5 : comparez coût, latence et qualité sur vos propres prompts. Pour les agents longs, Flash peut réduire le coût.
Vous construisez une nouvelle boucle d’agents : commencez par Flash, puis comparez avec un modèle plus coûteux uniquement si nécessaire.
Vous avez une charge multimodale lourde : testez Flash sur vos propres documents et graphiques.

Dans tous les cas, traitez le modèle comme un composant de pipeline. Testez les prompts, les appels d’outils, les sorties JSON, le streaming et les erreurs. Apidog couvre la partie test API pour Gemini ; la conception des prompts, le câblage des outils et l’évaluation métier restent à votre charge.

Qu'est-ce que Gemini Omni ? Le Modèle Vidéo Raisonnement d'Abord de Google

Antoine Laurent — Wed, 20 May 2026 02:10:02 +0000

Le blog de Google vient d’annoncer Gemini Omni, un nouveau modèle qui combine la pile de raisonnement de Gemini avec de la génération multimodale. La première variante, Gemini Omni Flash, accepte du texte, des images, de l’audio ou de la vidéo en entrée, puis génère une vidéo. Le modèle est déjà disponible dans l’application Gemini, Google Flow, YouTube Shorts et YouTube Create. L’accès API pour les développeurs est annoncé pour les prochaines semaines.

Essayez Apidog aujourd'hui

Si vous développez avec Apidog, vous avez probablement déjà testé des modèles texte, des générateurs d’images comme Nano Banana 2, ou des modèles vidéo comme Veo 3.1. Gemini Omni est le prochain endpoint à préparer. Sa logique est différente : le modèle raisonne avant de générer. Cet article explique ce que vous pouvez anticiper côté API, comment le comparer à Gemini 3 Pro et Veo, et comment préparer votre workspace Apidog avant la disponibilité des clés.

TL;DR

Gemini Omni est une nouvelle famille de modèles Google qui combine le raisonnement Gemini avec une génération multimodale native. Gemini Omni Flash accepte du texte, des images, de l’audio et de la vidéo en entrée, puis produit une vidéo. Les sorties image et audio sont prévues plus tard.

Disponibilité actuelle :

Application Gemini
Google Flow
YouTube Shorts
YouTube Create

L’API développeur et l’API entreprise doivent arriver dans les prochaines semaines.

Qu’est-ce que Gemini Omni ?

Gemini Omni est un modèle génératif orienté raisonnement. Un générateur vidéo classique prend une invite et produit une séquence d’images. Omni interprète d’abord la scène, raisonne sur ce qui devrait se passer, puis génère la sortie.

Google DeepMind décrit Omni comme un modèle capable d’utiliser les connaissances de Gemini et une compréhension intuitive de concepts physiques comme :

la gravité ;
l’énergie cinétique ;
les collisions ;
les fluides ;
les trajectoires.

Exemple concret : si vous demandez une balle qui rebondit dans un escalier, Omni ne se limite pas à interpoler des images plausibles. Il essaie de modéliser implicitement la perte de vitesse, les impacts successifs et la trajectoire attendue. C’est la différence mise en avant par Google : génération basée sur le raisonnement plutôt que simple génération image-par-image.

Gemini Omni Flash suit la logique de nommage de Google :

Gemini 3 Pro : raisonnement plus lourd ;
Gemini 3 Flash : vitesse et coût ;
Gemini Omni Flash : génération multimodale avec faible latence attendue.

Google n’a pas encore annoncé de variantes Omni plus grandes.

Ce qui distingue Omni des modèles vidéo précédents

Les points clés pour les développeurs :

Entrée multimodale native

Vous pouvez combiner texte, image, audio et vidéo dans une même requête.
Fusion de références

Vous pouvez fournir plusieurs images de référence, une direction artistique, une couleur de marque et un script.
Édition multi-tours

Vous pouvez générer un clip, puis demander : « rends l’arrière-plan plus enneigé » ou « remplace le chat par un renard ». Le modèle tente de conserver les parties non modifiées.
Raisonnement appliqué à la génération

Le modèle planifie implicitement la scène avant de produire la vidéo.

Gemini Omni vs Veo 3.1 vs Gemini 3 Pro

Si vous utilisez déjà les modèles Google, la séparation devient la suivante :

Modèle	Usage	Entrée	Sortie	Raisonnement
Gemini 3 Pro	Texte, code, raisonnement multimodal	Texte, image, audio, vidéo, code	Texte, code	Fort
Veo 3.1	Génération vidéo dédiée	Texte, image	Vidéo	Limité
Gemini Omni Flash	Raisonnement + génération créative	Texte, image, audio, vidéo	Vidéo	Natif

Veo 3 et Veo 3.1 restent adaptés si vous avez besoin d’une génération vidéo directe, avec une invite bien définie.

Gemini 3 Pro reste le bon choix pour les tâches de texte, code et raisonnement sans sortie vidéo.

Omni devient intéressant lorsque :

l’utilisateur décrit une scène complexe ;
la vidéo doit tenir compte de références multiples ;
vous avez besoin de modifications conversationnelles ;
le contexte audio, image ou vidéo influence la sortie.

Disponibilité actuelle

Gemini Omni Flash est disponible dans quatre produits :

Application Gemini

Génération conversationnelle de clips vidéo.
Google Flow

Outil de création de séquences vidéo multi-plans.
YouTube Shorts

Accès gratuit pour les créateurs.
YouTube Create

Génération orientée mobile.

Les abonnements Google AI Plus, Pro et Ultra incluent l’accès via Gemini et Flow. Les créateurs YouTube y accèdent gratuitement via Shorts et YouTube Create.

Chaque vidéo générée avec Omni contient un filigrane SynthID. Il est invisible pour les spectateurs mais vérifiable via les outils Google compatibles.

Pour les applications de conformité, de modération ou de vérification de contenu, prévoyez déjà un champ de provenance dans votre modèle de données.

Comprendre « raisonnement + génération »

Prenons cette invite :

Montre un verre d’eau tombant du bord d’une table et atterrissant sur un parquet.

Un modèle purement génératif tente de produire des images qui ressemblent à cette scène. Un modèle orienté raisonnement doit implicitement répondre à plusieurs questions :

le verre est-il plein ou à moitié plein ?
l’eau sort-elle avant ou après l’impact ?
le verre rebondit-il, se brise-t-il ou glisse-t-il ?
quelle trajectoire suit l’eau ?
comment le bois réagit-il à l’impact ?

Omni ne lance pas une simulation physique réelle. Il prédit un résultat plausible à partir de son entraînement, puis génère une vidéo cohérente avec cette prédiction.

Vous devriez voir la différence surtout sur :

les trajectoires ;
les collisions ;
les éclaboussures ;
la fumée ;
les tissus ;
les interactions entre objets.

Limite importante : Omni ne remplace pas un moteur physique ni un pipeline VFX. Sur des prises longues ou complexes, des erreurs de continuité peuvent toujours apparaître.

Tableau de disponibilité

Plateforme	Coût	Accès
YouTube Shorts	Gratuit	Tout créateur
YouTube Create	Gratuit	Créateurs mobiles
Application Gemini	Payant	AI Plus / Pro / Ultra
Google Flow	Payant	AI Plus / Pro / Ultra
API développeur	À déterminer	Prochaines semaines
API entreprise	À déterminer	Prochaines semaines

Google n’a pas encore donné de date exacte pour l’API. Le déploiement devrait probablement passer par Google AI Studio et Vertex AI, comme pour Gemini 3.

En attendant, vous pouvez préparer votre environnement. Téléchargez Apidog, importez les schémas Gemini ou Veo que vous utilisez déjà, puis ajoutez une version simulée du futur endpoint Omni.

Ce que l’on sait côté API

Google a confirmé les éléments suivants :

Premier modèle API attendu : Gemini Omni Flash.
Entrées : texte, image, audio, vidéo.
Sortie au lancement : vidéo.
Sorties futures : image et audio.
Tarification : non annoncée.
Rate limits : non annoncés.
Disponibilité régionale : non annoncée.
Endpoints probables : Google AI Studio et Vertex AI.

Le plus prudent consiste à ne pas coupler directement votre application à un fournisseur ou à un nom de modèle. Créez une interface interne unique :

interface VideoGenerationProvider {
  generateVideo(input: VideoGenerationInput): Promise<VideoGenerationResult>;
}

Puis implémentez plusieurs providers :

class VeoProvider implements VideoGenerationProvider {
  async generateVideo(input: VideoGenerationInput) {
    // Appel Veo 3.1
  }
}

class OmniProvider implements VideoGenerationProvider {
  async generateVideo(input: VideoGenerationInput) {
    // Appel Gemini Omni lorsque l'API sera disponible
  }
}

Cette approche vous permet de basculer entre Veo, Omni ou un autre modèle sans réécrire votre frontend.

Vous pouvez tester ce pattern avec Apidog en simulant le futur endpoint et en validant les réponses attendues. Le même principe est détaillé dans notre guide de l’API texte-vers-vidéo.

Préparer Omni dans Apidog

Quand l’API sera disponible, votre workspace Apidog devra couvrir trois éléments.

1. Authentification

Préparez deux environnements :

Google AI Studio avec x-goog-api-key ;
Vertex AI avec OAuth ou compte de service.

Dans Apidog, stockez les valeurs dans des variables d’environnement :

GEMINI_API_KEY=...
GOOGLE_PROJECT_ID=...
GOOGLE_LOCATION=...
GOOGLE_ACCESS_TOKEN=...

Cela évite de modifier les headers manuellement pour chaque requête.

2. Schéma de requête

Dès que Google publie la spécification OpenAPI, importez-la dans Apidog.

Si elle n’est pas disponible immédiatement, créez un endpoint temporaire basé sur la structure Gemini existante. Cette méthode a déjà été utile lors du lancement de Gemini 3.

3. Réponses simulées

La génération vidéo est coûteuse et lente. Utilisez des mocks pour développer sans appeler le vrai modèle.

Exemples de réponses simulées :

{
  "id": "video_gen_123",
  "status": "completed",
  "model": "gemini-omni-flash",
  "output": {
    "mimeType": "video/mp4",
    "url": "https://example.com/mock-video.mp4",
    "durationSeconds": 6
  },
  "metadata": {
    "synthId": true
  }
}

Ou, pour un workflow asynchrone :

{
  "id": "video_gen_123",
  "status": "processing",
  "pollUrl": "/v1/video-generations/video_gen_123"
}

Exemple de requête projetée

La forme finale peut changer, mais une requête Omni pourrait ressembler à ceci si Google reprend la structure multimodale Gemini :

curl -X POST https://generativelanguage.googleapis.com/v1beta/models/gemini-omni-flash:generateContent \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [{
      "parts": [
        {
          "text": "Generate a 6s product shot of the attached phone rotating on a white background"
        },
        {
          "inline_data": {
            "mime_type": "image/jpeg",
            "data": "<base64-image>"
          }
        }
      ]
    }],
    "generationConfig": {
      "responseMimeType": "video/mp4",
      "durationSeconds": 6
    }
  }'

Cette structure est une projection à partir de l’API Gemini existante. Les noms de champs peuvent changer au lancement.

Dans Apidog :

Créez une requête POST.
Ajoutez le header x-goog-api-key.
Définissez le body JSON.
Ajoutez un exemple de réponse mockée.
Ajoutez des tests sur :
- le code HTTP ;
- la présence de l’URL vidéo ;
- le statut de génération ;
- la présence du champ SynthID si exposé.

Exemple d’assertions côté test :

pm.test("La génération retourne un identifiant", function () {
  pm.expect(pm.response.json().id).to.exist;
});

pm.test("La réponse contient une vidéo", function () {
  const body = pm.response.json();
  pm.expect(body.output.mimeType).to.eql("video/mp4");
});

pm.test("SynthID est indiqué", function () {
  const body = pm.response.json();
  pm.expect(body.metadata.synthId).to.eql(true);
});

Comparaison avec Sora 2, Veo 3.1 et Nano Banana 2

Modèle	Fournisseur	Raisonnement	Entrée multimodale	Édition	Filigrane
Gemini Omni Flash	Google	Natif	Texte, image, audio, vidéo	Multi-tours	SynthID
Veo 3.1	Google	Limité	Texte, image	Ré-invite	SynthID
Sora 2	OpenAI	Partiel	Texte, image	Ré-invite	C2PA
Nano Banana 2	Google	Partiel	Texte, image	Limité	SynthID

Veo 3.1 reste pertinent pour les vidéos cinématiques en un seul plan. Sora 2 est positionné par OpenAI comme un modèle fort en simulation du monde ; nous l’avons couvert dans notre analyse de Sora 2.

L’intérêt principal d’Omni est ailleurs :

édition conversationnelle ;
entrées plus riches ;
raisonnement intégré ;
cohérence entre plusieurs références ;
génération vidéo à partir d’audio ou d’éléments mixtes.

Pour une comparaison plus large, consultez aussi notre comparaison des modèles vidéo.

Cas d’utilisation à préparer

Marketing produit

Générez des démonstrations courtes à partir :

d’un script ;
d’une image produit ;
d’une charte graphique ;
d’une voix off.

Omni peut être utile si l’équipe marketing veut modifier le résultat en langage naturel.

Formation et éducation

Exemple :

Explique la conservation de l’énergie avec une balle qui descend une rampe.

Le raisonnement est important ici : une vidéo visuellement propre mais physiquement fausse peut induire l’apprenant en erreur.

Customer success

La fonction Avatars peut servir à produire des vidéos d’onboarding personnalisées. Google n’a pas encore détaillé le flux de consentement et de vérification côté API, mais la version grand public nécessite une configuration explicite.

Modération et vérification

Si vous republiez des vidéos générées, ajoutez SynthID à votre pipeline de confiance et sécurité.

Prototypage d’applications et de jeux

Omni peut aider à créer des prévisualisations de cinématiques, de tutoriels ou de séquences utilisateur avant de mobiliser une équipe 3D.

Bonnes pratiques d’implémentation

Ne codez pas le nom du modèle en dur

Utilisez une variable :

VIDEO_MODEL=gemini-omni-flash

Puis lisez-la côté application :

const model = process.env.VIDEO_MODEL ?? "veo-3.1";

Les noms de modèles peuvent changer entre preview et disponibilité générale.

Traitez la génération comme asynchrone

Une génération vidéo peut prendre plusieurs dizaines de secondes. Ne bloquez pas le thread principal.

Préférez ce modèle :

création d’un job ;
polling ou webhook ;
récupération de l’URL finale ;
mise en cache.

Exemple :

type GenerationStatus = "queued" | "processing" | "completed" | "failed";

interface VideoJob {
  id: string;
  status: GenerationStatus;
  outputUrl?: string;
  error?: string;
}

Mettez en cache les résultats

Si l’entrée est identique, évitez de repayer la génération.

Clé de cache possible :

import crypto from "crypto";

function buildCacheKey(input: unknown) {
  return crypto
    .createHash("sha256")
    .update(JSON.stringify(input))
    .digest("hex");
}

Prévoyez les erreurs de politique de contenu

Les modèles Google peuvent refuser certaines générations, notamment autour :

de personnes réelles ;
de contenu sensible ;
de personnages protégés ;
de demandes violentes ou explicites.

Ne retournez pas une page d’erreur brute. Proposez une invite alternative ou un fallback.

if (error.code === "CONTENT_POLICY_VIOLATION") {
  return {
    status: "failed",
    userMessage: "La demande ne peut pas être générée telle quelle. Essayez une description plus générale."
  };
}

Simulez avant d’appeler l’API réelle

Avec Apidog, créez des mocks pour :

génération réussie ;
génération en cours ;
génération refusée ;
timeout ;
quota dépassé.

Cela permet de tester le frontend, les états de chargement et les erreurs avant de consommer du quota réel.

Ajoutez SynthID à votre modèle de données

Exemple :

interface GeneratedVideo {
  id: string;
  provider: "google";
  model: string;
  url: string;
  synthIdDetected?: boolean;
  createdAt: string;
}

Même si l’API ne retourne pas immédiatement tous ces champs, votre application sera prête pour les besoins de conformité.

Pièges à éviter

Ne partez pas du principe qu’Omni remplacera un éditeur vidéo.
Ne bloquez pas une requête HTTP pendant toute la génération.
Ne stockez pas les clés API côté client.
Ne désactivez pas les contrôles de contenu.
Ne supposez pas que les noms de champs de l’API projetée seront définitifs.
Ne migrez pas tout depuis Veo sans mesurer coût, latence et qualité.

Omni est un modèle de génération, pas un outil de montage non linéaire. Vous aurez toujours besoin d’une passe finale dans DaVinci, Premiere ou Google Flow pour les coupes, la couleur et le mixage audio.

Questions fréquentes

Qu’est-ce que Gemini Omni ?

Gemini Omni est une famille de modèles Google qui combine le raisonnement Gemini avec une génération multimodale native. Gemini Omni Flash accepte texte, image, audio et vidéo en entrée, puis génère une vidéo.

Gemini Omni est-il identique à Veo 3 ?

Non. Veo est un modèle dédié à la génération vidéo. Omni est un modèle de raisonnement capable de générer de la vidéo, d’interpréter des invites complexes et de fonctionner sur plusieurs tours. Consultez notre guide de l’API Veo 3 pour comparer les usages.

Quand l’API Gemini Omni sera-t-elle disponible ?

Google indique un lancement dans les prochaines semaines après l’annonce de mai 2026. Aucune date ferme n’a été publiée.

Combien coûte Gemini Omni ?

Pour les utilisateurs grand public, Omni est gratuit dans YouTube Shorts et YouTube Create, et inclus dans Google AI Plus, Pro et Ultra. La tarification API n’a pas encore été annoncée.

Gemini Omni peut-il générer de l’audio ?

Pas au lancement. La sortie initiale est vidéo uniquement. Google indique que les sorties image et audio arriveront plus tard.

Gemini Omni utilise-t-il un filigrane ?

Oui. Les vidéos générées par Omni contiennent un filigrane SynthID, vérifiable via les outils Google compatibles.

Apidog prendra-t-il en charge Gemini Omni ?

Oui. Comme pour Gemini 3, Veo 3 et Nano Banana, vous pourrez importer la spécification OpenAPI dès sa publication. En attendant, vous pouvez déjà créer un schéma temporaire, simuler les réponses et préparer votre client avec Apidog.

Gemini Omni est-il un moteur physique ?

Non. Omni n’exécute pas une simulation physique. Il prédit des résultats plausibles grâce à son entraînement, puis génère une vidéo cohérente avec cette prédiction.

Plan d’action pour les développeurs

Si vous utilisez déjà des modèles vidéo, faites ces cinq choses maintenant :

Surveillez Google AI Studio pour l’apparition de Gemini Omni Flash.
Configurez vos variables d’environnement dans Apidog.
Créez un endpoint mocké pour la génération Omni.
Implémentez une abstraction interne pour basculer entre Veo, Omni et d’autres modèles.
Ajoutez la provenance SynthID à votre modèle de données.

Quand l’API sera disponible, les équipes qui auront préparé leurs schémas, mocks et tests pourront intégrer Omni rapidement. Les autres devront commencer par structurer leur pipeline.

Claude Agents Managés vs Agent SDK (2026) : Lequel Choisir

Antoine Laurent — Tue, 19 May 2026 10:33:42 +0000

Vous déployez un agent IA de production sur Claude. Le premier choix d’architecture est simple à formuler, mais coûteux à corriger plus tard : laisser Anthropic héberger la boucle d’agent et le bac à sable avec les Claude Managed Agents, ou exécuter cette boucle dans votre propre service avec le SDK Claude Agent. Les deux peuvent produire une démo similaire ; en production, ils changent votre résidence des données, votre modèle de coût, votre observabilité et votre astreinte.

Essayez Apidog aujourd’hui

En bref

Choisissez Claude Managed Agents si vous voulez qu’Anthropic héberge la boucle d’agent, le bac à sable et l’état de session pour des tâches longues ou asynchrones.

Choisissez SDK Claude Agent si vous voulez exécuter la boucle dans votre propre processus, garder le contrôle des outils, des permissions, de la résidence des données et de l’infrastructure.

Dans les deux cas, votre agent dépendra surtout des API et serveurs MCP qu’il appelle. Testez-les avant la mise en production.

Introduction

Construire un agent IA en production ne consiste plus à mettre une boucle while autour d’une complétion de chat. Avec Claude, vous avez aujourd’hui deux modèles d’exécution :

Claude Managed Agents : Anthropic exécute la boucle d’agent, le bac à sable et l’état de session via une API REST.
SDK Claude Agent : vous importez une bibliothèque Python ou TypeScript, et la boucle s’exécute dans votre propre service.

Même modèle Claude, mais contrat opérationnel différent.

Un agent de production appelle presque toujours des API : rembourser un paiement, créer un ticket Zendesk, lire un inventaire, interroger une API interne, déclencher une tâche ETL. Sa fiabilité dépend donc directement de la fiabilité de ces dépendances.

Avant de choisir le modèle d’hébergement, préparez un environnement de test pour ces API. Avec Apidog, vous pouvez :

mocker les services appelés par l’agent ;
définir les schémas attendus ;
exécuter des tests de contrat ;
tester un serveur MCP comme l’agent le fera.

Pour un focus sur la partie hébergée, consultez aussi le guide sur les Claude Managed Agents.

Ce que sont réellement les Claude Managed Agents

Les Claude Managed Agents sont un harnais d’agent hébergé par Anthropic. Vous ne codez pas la boucle d’agent, le stockage de session ou le bac à sable : vous décrivez l’agent, puis vous envoyez des événements.

La fonctionnalité a été lancée en bêta publique en avril 2026 et nécessite actuellement l’en-tête bêta suivant sur chaque requête :

anthropic-beta: managed-agents-2026-04-01

Le SDK peut configurer cet en-tête pour vous.

Les 4 concepts principaux

Concept	Rôle
Agent	Modèle, invite système, outils, serveurs MCP et compétences. Vous le créez une fois et le référencez par ID.
Environnement	Modèle de conteneur avec packages préinstallés et règles réseau.
Session	Instance d’agent en cours d’exécution, avec système de fichiers persistant et historique de conversation.
Événements	Messages entre votre application et l’agent : tours utilisateur, résultats d’outils, statuts, réponses streamées.

Flux d’exécution

Le flux typique ressemble à ceci :

Créer un agent.
Configurer un environnement.
Démarrer une session.
Envoyer des messages utilisateur sous forme d’événements.
Streamer les réponses.
Récupérer l’historique d’événements pour audit ou débogage.

Les Managed Agents fournissent des outils intégrés comme :

Bash ;
lecture, écriture et édition de fichiers ;
glob et grep ;
recherche et récupération web ;
connexions à des serveurs MCP.

Ils sont adaptés aux charges de travail longues ou asynchrones : tâches qui durent plusieurs minutes ou heures, nombreux appels d’outils, besoin d’un état persistant et volonté de réduire l’infrastructure opérée côté application.

Point important : les outils personnalisés

Avec les Managed Agents, Claude peut décider d’appeler un outil personnalisé, mais votre application exécute réellement cet outil et renvoie le résultat via le flux d’événements.

Autrement dit :

la boucle d’agent est hébergée ;
le bac à sable est hébergé ;
mais l’exécution de vos outils métier reste dans votre environnement.

Certaines fonctionnalités comme les résultats et le multi-agent sont limitées en aperçu de recherche et nécessitent une demande d’accès distincte. Ne partez pas du principe que tout est disponible par défaut.

Pour replacer ces composants dans un modèle plus large, voir l’article sur l’architecture IA agentique.

Ce qu’est réellement le SDK Claude Agent

Le SDK Claude Agent est une bibliothèque Python ou TypeScript. Il expose la boucle d’agent, les outils intégrés et la gestion du contexte utilisés par Claude Code.

Il s’appelait auparavant SDK Claude Code. Le changement de nom reflète une portée plus large que les seuls cas de génération ou modification de code.

Installation :

pip install claude-agent-sdk

ou :

npm install @anthropic-ai/claude-agent-sdk

Avec le SDK, la boucle s’exécute dans votre propre processus. Vous contrôlez donc :

l’environnement d’exécution ;
les permissions ;
les hooks ;
les logs ;
les outils ;
l’état de session ;
la proximité avec vos bases de données ou services internes.

Exemple mental : pourquoi ce n’est pas juste un Client SDK

Avec un simple Client SDK, vous implémentez vous-même une boucle du type :

while response.stop_reason == "tool_use":
    tool_call = response.content
    result = execute_tool(tool_call)
    response = client.messages.create(...)

Avec le SDK Claude Agent, cette boucle est fournie. Vous configurez les outils, les permissions et les callbacks, puis vous consommez les messages streamés.

Ce que fournit le SDK

Fonction	Utilité
Outils intégrés	Lecture, écriture, édition, Bash, Glob, Grep, WebSearch, WebFetch, Monitor, AskUserQuestion.
Hooks	Points de contrôle comme `PreToolUse`, `PostToolUse`, `Stop`, `SessionStart`, `SessionEnd`, `UserPromptSubmit`.
Sous-agents	Agents spécialisés pour des sous-tâches, traçables via `parent_tool_use_id`.
MCP	Connexion à des bases de données, navigateurs et API via Model Context Protocol.
Permissions	Autoriser, bloquer ou demander validation selon l’outil ou l’action.
Sessions	Capturer un ID de session, reprendre plus tard, forker une session, stocker l’état en JSONL.

Exemple de politique utile : avant un remboursement, intercepter l’appel d’outil avec PreToolUse, vérifier le montant, puis exiger une approbation humaine au-delà d’un seuil.

Le SDK lit aussi la configuration de l’écosystème Claude Code :

compétences dans .claude/skills/ ;
commandes slash ;
fichier CLAUDE.md ;
plugins.

Côté authentification, il prend en charge l’API Anthropic directe, Amazon Bedrock, Claude Platform sur AWS, Google Vertex AI et Azure AI Foundry.

Pour démarrer avec une boucle fonctionnelle, voir le guide de configuration du SDK Claude Agent avec un plan Claude et la procédure pas à pas pour créer votre propre Claude Code.

Facturation à surveiller

À partir du 15 juin 2026, l’utilisation du SDK Agent et de claude -p sur les plans d’abonnement sera déduite d’un crédit mensuel distinct pour le SDK Agent, séparé des limites d’utilisation interactive.

Ne basez pas votre budget sur une hypothèse ancienne. Vérifiez toujours les conditions actuelles directement chez Anthropic.

Comparatif : Managed Agents vs SDK Agent

Considérez la ligne de coût comme indicative. Confirmez les chiffres actuels sur la page de tarification d’Anthropic et dans la documentation des Managed Agents.

Dimension	Claude Managed Agents	SDK Claude Agent
Où s’exécute la boucle	Infrastructure gérée par Anthropic	Votre processus, votre infrastructure
Interface	API REST + flux d’événements SSE	Bibliothèque Python ou TypeScript
Contrôle de la boucle	Configuré, non codé ; pilotage via événements	Complet : hooks, permissions, logique in-process
Modèle de coût	Tokens Claude + frais d’exécution par heure de session active	Tokens Claude + calcul et infrastructure que vous opérez
Charge opérationnelle	Faible : pas de bac à sable ni stockage de session à maintenir	Plus élevée : service, scaling, sandboxing et monitoring à gérer
Observabilité	Journal d’événements hébergé et récupérable	Hooks, logs et tracing que vous instrumentez
Latence	Saut réseau vers l’exécution hébergée ; adapté aux tâches longues	Boucle in-process ; proximité contrôlée avec vos données et outils
Résidence des données	Bac à sable et état de session dans l’infrastructure Anthropic ou AWS selon option	Fichiers, état et exécution d’outils dans votre infrastructure
Outils personnalisés	Claude demande ; votre application exécute et renvoie le résultat	Fonctions Python ou TypeScript in-process
Meilleure adéquation	Agents longs, asynchrones, avec faible charge infra côté équipe	Agents proches de vos fichiers, services internes et contraintes de données

Comment décider

1. Regardez d’abord la résidence des données

Si l’état de session, les fichiers temporaires ou les logs ne peuvent pas sortir de votre infrastructure, choisissez le SDK.

Avec le SDK :

les outils s’exécutent chez vous ;
l’état de session reste chez vous ;
les hooks peuvent alimenter votre audit interne ;
seule l’inférence part vers Claude selon votre configuration.

Avec les Managed Agents, le bac à sable et le journal d’événements résident dans l’environnement d’Anthropic ou dans l’option AWS disponible, avec ses limites spécifiques.

2. Évaluez la charge opérationnelle

Les Managed Agents retirent de votre backlog :

le stockage de session ;
le sandboxing ;
le scaling de workers ;
une partie de l’observabilité ;
la gestion de tâches longues.

Le SDK vous rend responsable de ces éléments, mais vous donne plus de contrôle.

C’est souvent le vrai arbitrage : moins d’infrastructure à opérer contre plus de contrôle sur l’exécution.

3. Ne comparez pas seulement les prix affichés

Les Managed Agents ajoutent des frais d’exécution par heure de session active.

Le SDK n’a pas ces frais horaires côté Anthropic, mais vous payez :

les machines ;
l’autoscaling ;
le monitoring ;
le sandboxing ;
les ingénieurs ;
l’astreinte.

Une option moins chère sur la facture API peut coûter plus cher en exploitation.

4. Décidez comment vous allez observer l’agent

Avec les Managed Agents, vous récupérez un journal d’événements hébergé.

Avec le SDK, vous devez instrumenter explicitement :

PreToolUse pour tracer les intentions ;
PostToolUse pour tracer les résultats ;
Stop pour analyser les fins de session ;
SessionStart et SessionEnd pour corréler les runs.

Exemple de structure de log utile :

{
  "session_id": "sess_123",
  "tool": "refund_payment",
  "phase": "PreToolUse",
  "amount": 129.99,
  "currency": "EUR",
  "requires_human_approval": true,
  "ticket_id": "SUP-4512"
}

Test et débogage des API appelées par vos agents

Quel que soit le modèle choisi, votre agent sera aussi fiable que les API et serveurs MCP qu’il appelle.

Un agent de remboursement peut parfaitement raisonner, mais s’il appelle deux fois une API de paiement après un timeout ambigu, vous avez un incident.

Testez donc les dépendances avant de connecter l’agent à un client réel.

Couche 1 : contrats d’API

Chaque outil appelé par l’agent est une API avec :

une requête attendue ;
une réponse attendue ;
des erreurs possibles ;
des timeouts ;
des comportements de retry.

Avec Apidog, vous pouvez mocker un service de paiement ou de tickets, définir le schéma attendu, puis exécuter des tests de contrat régulièrement.

Exemple de contrat minimal pour un outil de remboursement :

{
  "transaction_id": "txn_123",
  "amount": 49.99,
  "currency": "EUR",
  "reason": "duplicate_charge",
  "idempotency_key": "refund_SUP-4512_txn_123"
}

Points à tester :

champs obligatoires ;
devise ;
montant maximum ;
clé d’idempotence ;
erreurs 4xx ;
erreurs 5xx ;
timeout après exécution réussie côté serveur.

Pour une approche structurée, voir le guide sur comment tester les agents IA qui appellent des API.

Couche 2 : serveurs MCP

Les Managed Agents et le SDK peuvent utiliser MCP. Un serveur MCP expose des outils, des entrées et des sorties. C’est donc aussi une surface de test.

Défaillances fréquentes :

payload de sortie modifié ;
timeout non géré ;
erreur renvoyée en texte libre au lieu d’un format structuré ;
outil renommé ;
argument facultatif devenu obligatoire ;
pagination oubliée.

Testez chaque outil MCP isolément avant de le connecter à un agent.

Le guide sur le test de serveur MCP avec Apidog explique comment énumérer les outils exposés et les exercer un par un.

Apidog inclut aussi un agent IA et un débogueur A2A pour observer le trafic généré par un agent au lieu de le deviner.

Couche 3 : comportement réel de requête de l’agent

Les agents n’appellent pas les API comme les humains.

Ils peuvent produire :

des rafales de retries ;
des lectures partielles ;
plusieurs appels identiques pendant le raisonnement ;
des boucles sur un même endpoint ;
des séquences inattendues après une erreur.

Rejouez du trafic réaliste contre vos mocks et inspectez les requêtes réellement envoyées.

Objectif : découvrir les comportements dangereux en staging, pas pendant l’incident.

Dans tous les cas, téléchargez Apidog et testez les dépendances de l’agent avant qu’il n’approche un client réel.

Cadre de décision

Répondez aux questions dans l’ordre. Le premier « oui » fort oriente généralement le choix.

Choisissez Claude Managed Agents si :

votre agent s’exécute longtemps ou de manière asynchrone ;
vous ne voulez pas gérer workers, sandboxing et stockage de session ;
votre équipe est petite et l’exploitation est la contrainte principale ;
vous voulez un journal d’événements hébergé et récupérable ;
vos règles de conformité autorisent le bac à sable et l’état de session dans l’environnement Anthropic ou AWS ;
vous acceptez le statut bêta et les fonctionnalités limitées derrière demande d’accès.

Choisissez le SDK Claude Agent si :

l’agent doit s’exécuter dans votre VPC ;
il doit accéder à des bases de données ou services internes ;
l’état de session ne doit pas être détenu par un tiers ;
vous avez besoin de hooks d’audit et de permissions précises ;
vous voulez exécuter les outils personnalisés in-process ;
vous voulez utiliser Bedrock, Vertex ou Azure tout en gardant la boucle chez vous ;
vous prototypez localement sur votre système de fichiers.

Chemin fréquent

Un chemin raisonnable :

Prototyper localement avec le SDK Agent.
Tester les API et serveurs MCP avec des mocks.
Mesurer la durée des sessions et le nombre d’appels d’outils.
Décider si la production doit rester en SDK ou migrer vers Managed Agents.
Traiter la migration comme un vrai projet, pas comme un simple changement de configuration.

Si vous comparez aussi des modèles ou agents de codage, voir la comparaison Claude vs Codex pour 2026.

Cas d’utilisation concrets

Agent de remboursement de paiements

Une équipe support fintech veut traiter les remboursements de bout en bout :

Lire le ticket.
Rechercher la transaction.
Vérifier la politique de remboursement.
Appeler l’API de paiement.
Écrire un résumé dans le ticket.

Ici, l’agent manipule de l’argent. Il faut donc :

un contrat testé pour chaque API ;
une clé d’idempotence ;
une piste d’audit ;
une approbation humaine au-delà d’un seuil.

Le SDK est souvent le choix naturel :

exécution dans le VPC ;
proximité avec le service de paiement ;
état de session conservé en interne ;
hooks PreToolUse pour bloquer ou demander validation.

Exemple de règle :

def pre_tool_use(tool_name, args):
    if tool_name == "refund_payment" and args["amount"] > 100:
        return {
            "action": "require_approval",
            "reason": "Remboursement supérieur au seuil autorisé"
        }

    return {"action": "allow"}

Avant le lancement, l’équipe peut mocker les endpoints de paiement et de grand livre dans Apidog, écrire des tests de contrat, puis rejouer des tickets historiques contre les mocks.

Bug typique à détecter : après une erreur 504, l’agent réessaie un remboursement qui avait en réalité réussi côté prestataire. Sans idempotence et tests de retry, c’est un incident financier.

Agent de triage de tickets support asynchrone

Une entreprise SaaS reçoit des milliers de tickets par jour. Elle veut un agent qui :

Classe le ticket.
Extrait les logs associés.
Rédige une réponse.
Résout ou escalade.

Les tickets arrivent en continu, chaque tâche prend plusieurs minutes et les données sont peu sensibles.

Les Managed Agents conviennent bien :

tâche longue et asynchrone ;
équipe réduite ;
pas besoin de gérer une flotte de workers ;
journal d’événements hébergé par ticket.

Mais l’équipe doit quand même tester les dépendances :

API de logs ;
serveur MCP du système de tickets ;
schémas de réponses ;
timeouts ;
erreurs.

L’hébergement est géré. La qualité des API reste votre responsabilité.

Agent interne de gestion de données derrière le pare-feu

Une équipe plateforme veut un agent capable de répondre à :

« Relance les partitions ETL échouées hier. »

L’agent doit :

Interroger une API interne.
Identifier les partitions échouées.
Exécuter un script de remédiation.
Rapporter le statut.

Les API ne sont pas exposées publiquement et les données sont sensibles.

Le SDK s’impose généralement :

exécution dans le réseau interne ;
accès aux services privés ;
état de session conservé en interne ;
hooks pour journaliser chaque commande ;
intégration avec l’audit existant.

Ici, « s’exécute dans votre processus » n’est pas une préférence. C’est une exigence.

Pour comprendre pourquoi les agents deviennent des consommateurs d’API majeurs, lire l’article sur les agents IA comme nouveaux consommateurs d’API.

Checklist de mise en production

Avant de connecter un agent à des systèmes réels :

[ ] Lister tous les outils appelés par l’agent.
[ ] Identifier les API derrière chaque outil.
[ ] Définir les schémas de requête et réponse.
[ ] Mocker les dépendances critiques.
[ ] Tester les erreurs 4xx, 5xx et timeouts.
[ ] Tester les retries et l’idempotence.
[ ] Ajouter des hooks ou journaux d’audit.
[ ] Définir les seuils nécessitant validation humaine.
[ ] Tester les serveurs MCP isolément.
[ ] Rejouer du trafic réaliste.
[ ] Vérifier résidence des données et contraintes de conformité.
[ ] Confirmer les prix et le statut bêta à la source.

Conclusion

Le choix entre Managed Agents et SDK Agent est surtout une décision d’exploitation et de gouvernance des données.

À retenir :

Managed Agents héberge la boucle et le bac à sable ; le SDK les exécute dans votre processus.
Le coût dépend de la forme de charge : frais d’exécution côté Managed Agents, infrastructure et astreinte côté SDK.
La résidence des données tranche souvent : VPC et données réglementées orientent vers le SDK.
Les petites équipes bénéficient du runtime géré si les contraintes de données le permettent.
Les dépendances doivent être testées dans les deux cas : API, serveurs MCP, retries, timeouts et contrats.
Prototyper avec le SDK puis migrer vers Managed Agents est possible, mais la migration doit être planifiée.
Vérifiez les prix et le statut bêta chez Anthropic avant de vous engager.

Étape suivante : avant de brancher un agent sur une API client ou interne critique, testez ses dépendances. Téléchargez Apidog pour mocker les endpoints, exécuter des tests de contrat et déboguer le trafic réel de l’agent.

FAQ

Quelle est la principale différence entre Claude Managed Agents et le SDK Claude Agent ?

Les Managed Agents sont une API REST hébergée où Anthropic exécute la boucle d’agent et un bac à sable par session. Vous envoyez des événements et recevez des résultats en streaming.

Le SDK Agent est une bibliothèque Python ou TypeScript qui exécute la boucle dans votre propre processus et infrastructure.

Même modèle Claude, propriété opérationnelle différente.

Le SDK Claude Agent est-il le même que l’ancien SDK Claude Code ?

Oui. Le SDK Claude Code a été renommé SDK Claude Agent pour refléter une portée plus large que les tâches de codage. Il expose la boucle d’agent, les outils intégrés et la gestion du contexte utilisés par Claude Code.

Quelle option est la moins chère ?

Cela dépend de la charge de travail.

Les Managed Agents facturent les tokens Claude plus des frais d’exécution pour le temps de session actif.

Le SDK n’ajoute pas ces frais horaires côté Anthropic, mais vous payez et opérez l’infrastructure.

Confirmez les tarifs actuels sur la page de tarification d’Anthropic avant de budgéter.

Puis-je utiliser des serveurs MCP avec les deux options ?

Oui. Les deux peuvent utiliser le Model Context Protocol.

C’est pourquoi il faut tester vos serveurs MCP avant de les connecter à l’agent. Le guide sur le test de serveur MCP avec Apidog montre comment exercer chaque outil exposé.

Comment empêcher les données client de quitter mon infrastructure ?

Utilisez le SDK Agent et exécutez la boucle dans votre propre environnement.

Avec le SDK :

l’exécution des outils reste chez vous ;
l’état de session reste chez vous ;
les fichiers restent chez vous.

Avec les Managed Agents, le bac à sable et le journal d’événements résident dans l’environnement Anthropic ou AWS selon l’option disponible.

Les Claude Managed Agents sont-ils prêts pour la production ?

Ils ont été lancés en bêta publique en avril 2026 et nécessitent l’en-tête bêta :

anthropic-beta: managed-agents-2026-04-01

Certaines fonctionnalités comme les résultats et le multi-agent sont limitées derrière une demande d’aperçu de recherche. Traitez-les comme une bêta et vérifiez la documentation actuelle.

Comment tester un agent avant qu’il n’interagisse avec de vraies API ?

Procédez en trois étapes :

Mockez chaque API et serveur MCP.
Écrivez des tests de contrat sur les requêtes et réponses.
Rejouez un trafic réaliste pour voir ce que l’agent envoie réellement.

Apidog couvre ces cas, avec un agent IA et un débogueur A2A pour inspecter le trafic. Le guide sur comment tester les agents IA qui appellent des API détaille les modes de défaillance.

Puis-je commencer avec une option et passer à l’autre plus tard ?

Oui, mais ce n’est pas un simple changement de configuration.

Les interfaces diffèrent :

SDK : bibliothèque Python ou TypeScript ;
Managed Agents : REST + événements SSE.

L’exécution des outils personnalisés et la gestion de session diffèrent aussi. Planifiez la migration comme un vrai projet.

Cursor Composer 2.5 vs Opus 4.7 vs GPT-5.5: Quel modèle de codage choisir ?

Antoine Laurent — Tue, 19 May 2026 02:29:59 +0000

L’affirmation de Cursor sur Composer 2.5 est simple : obtenir une qualité de codage proche des meilleurs modèles pour environ un dixième du prix. Pour un développeur, la vraie question est opérationnelle : faut-il l’utiliser par défaut face à Claude Opus 4.7 et GPT-5.5 dans une base de code réelle ?

Essayez Apidog aujourd’hui

Si vous voulez le contexte complet du modèle, commencez par le guide Cursor Composer 2.5. Ici, l’objectif est plus pratique : comparer les trois modèles sur les benchmarks, le coût, la vitesse et le choix à faire dans un workflow de développement quotidien.

La réponse courte

Composer 2.5 n’est pas le meilleur modèle absolu dans toutes les situations. Son intérêt est ailleurs : il se rapproche à un ou deux points d’Opus 4.7 sur des tâches logicielles réelles, tout en coûtant moins d’un dollar par tâche au lieu de plusieurs.

Pour la plupart des équipes qui livrent du code tous les jours, ce compromis est décisif. Opus 4.7 reste plus fort sur les tâches de raisonnement les plus difficiles. GPT-5.5 garde un avantage net sur les workflows lourds en terminal.

Comparaison des benchmarks

Cursor met en avant trois suites de tests. Voici les résultats côte à côte, avec Composer 2 comme référence historique.

Benchmark	Composer 2.5	Opus 4.7	GPT-5.5	Composer 2
SWE-bench Multilingual	79,8 %	80,5 %	77,8 %	73,7 %
Terminal-bench 2.0	69,3 %	69,4 %	82,7 %	n/a
CursorBench v3.1	63,2 %	64,8 % max / 61,6 % par défaut	59,2 % par défaut	n/a

Ce qu’il faut retenir

1. Sur SWE-bench Multilingual, Composer 2.5 est presque au niveau d’Opus 4.7.

Cette suite teste la résolution de vrais problèmes GitHub dans plusieurs langages. Composer 2.5 atteint 79,8 %, contre 80,5 % pour Opus 4.7 et 77,8 % pour GPT-5.5.

Le saut le plus important est par rapport à Composer 2, qui était à 73,7 %. Le guide Composer 2 montre d’où partait le modèle précédent.

2. Sur CursorBench avec les paramètres par défaut, Composer 2.5 est très compétitif.

Composer 2.5 atteint 63,2 %. Il dépasse Opus 4.7 en configuration par défaut, à 61,6 %, et GPT-5.5, à 59,2 %. Opus 4.7 ne reprend l’avantage qu’en réglage maximal, avec un coût et une latence plus élevés.

3. Sur Terminal-bench, GPT-5.5 est clairement devant.

GPT-5.5 atteint 82,7 %, contre 69,3 % pour Composer 2.5. Si votre travail repose fortement sur des chaînes de commandes shell, des scripts ou de l’automatisation terminal, ce résultat doit peser dans votre choix.

Pour vérifier les chiffres côté sources externes, consultez la couverture de The Decoder et l’annonce officielle de Cursor Composer 2.5.

Coût : le vrai différenciateur

Quand l’écart de benchmark est d’un ou deux points, le coût par tâche devient souvent plus important que le score brut.

Modèle	Entrée / M tokens	Sortie / M tokens	Coût approx. par tâche
Composer 2.5 standard	0,50 $	2,50 $	Moins de 1 $
Composer 2.5 rapide	3,00 $	15,00 $	Quelques dollars
Opus 4.7 / GPT-5.5	De niveau avancé	De niveau avancé	Plusieurs dollars, jusqu’à ~11 $

Cursor indique environ 63 % sur CursorBench pour un coût moyen inférieur à 1 $ par tâche avec Composer 2.5. Opus 4.7 et GPT-5.5 coûtent plusieurs dollars par tâche pour des résultats similaires ou inférieurs selon les cas, avec certaines comparaisons allant jusqu’à environ 11 $ pour le même type de travail.

Exemple simple :

2 000 tâches d’agent par mois à 1 $ : environ 2 000 $
2 000 tâches à 5 $ : environ 10 000 $
2 000 tâches à 11 $ : environ 22 000 $

À volume élevé, la différence n’est plus marginale. Elle devient une décision d’architecture et de budget.

Pour aller plus loin, consultez le guide de tarification de Cursor Composer, l’article sur la tarification de GPT-5.5 et le guide Claude Opus 4.7.

Vitesse et comportement en pratique

Les scores ne suffisent pas. Le comportement du modèle dans l’éditeur compte autant.

Composer 2.5

À utiliser quand vous voulez :

un agent capable de suivre une tâche multi-fichiers ;
un bon rapport qualité/prix ;
un modèle optimisé pour la boucle Cursor ;
une exécution répétée sur de nombreuses tâches quotidiennes.

Composer 2.5 est basé sur le point de contrôle open source Moonshot Kimi K2.5, puis post-entraîné par Cursor. Il est donc spécialement orienté vers les tâches d’agent dans l’éditeur.

Opus 4.7

À utiliser quand vous voulez :

maximiser la qualité sur un problème difficile ;
accepter une latence et un coût plus élevés ;
traiter des tâches où le raisonnement prime sur le volume.

Opus 4.7 reste le bon choix pour les cas où le coût est secondaire et où vous voulez pousser la qualité au maximum.

GPT-5.5

À utiliser quand vous voulez :

automatiser des workflows terminal ;
enchaîner des commandes shell complexes ;
disposer d’un modèle généraliste solide aussi utilisable pour le code.

Son avantage sur Terminal-bench 2.0 est le signal principal à retenir.

Quel modèle choisir ?

Utilisez cette grille comme point de départ.

Choisissez Composer 2.5 si :

vous livrez du code tous les jours ;
le coût par tâche compte à grande échelle ;
vous travaillez principalement dans Cursor ;
vos tâches impliquent plusieurs fichiers, des corrections de bugs, des refactorings ou de petites fonctionnalités ;
vous voulez une qualité proche des meilleurs modèles pour une fraction du prix.

Choisissez Opus 4.7 si :

vous avez besoin du meilleur score possible sur des tâches de raisonnement difficiles ;
votre budget modèle est moins contraint ;
vous utilisez déjà un workflow centré sur Claude.

La comparaison Claude Code vs Cursor détaille cette approche.

Choisissez GPT-5.5 si :

votre travail dépend fortement du terminal ;
vous automatisez beaucoup via shell ;
vous voulez un modèle généraliste qui reste performant pour le code.

Dans beaucoup d’équipes, la stratégie la plus efficace est hybride :

Composer 2.5 par défaut ;
Opus 4.7 pour les problèmes complexes ;
GPT-5.5 pour les workflows terminal lourds.

Le comparatif Codex vs Claude Code vs Cursor vs Copilot donne une vue plus large si vous comparez encore les outils.

Testez les modèles sur votre propre code

Les benchmarks publics donnent une moyenne. Votre base de code n’est pas une moyenne. Le test le plus utile consiste à comparer les modèles sur une tâche réelle.

Procédure de test rapide

Choisissez une tâche représentative :
- correction de bug avec reproduction ;
- petite fonctionnalité ;
- refactoring avec tests ;
- modification d’un endpoint API ;
- migration ou nettoyage multi-fichiers.
Préparez une invite identique pour les trois modèles.

Exemple :

   Corrige le bug décrit ci-dessous sans modifier le comportement public existant.
   Ajoute ou mets à jour les tests nécessaires.
   Explique brièvement les fichiers modifiés.

   Bug :
   [description]

   Reproduction :
   [étapes]

   Résultat attendu :
   [comportement attendu]

Exécutez la tâche dans Cursor avec :
- composer-2.5
- Opus 4.7
- GPT-5.5
Mesurez chaque exécution sur trois critères :
- les tests passent-ils ?
- combien de temps l’exécution a-t-elle pris ?
- quel est le coût affiché dans Cursor ?
Si la tâche touche une API, envoyez les requêtes générées via Apidog. Ne vous contentez pas de tests unitaires verts : vérifiez aussi les codes d’état, les payloads, les headers et l’authentification.

Vous verrez généralement le même schéma que dans les benchmarks : Composer 2.5 est très proche en qualité, mais nettement plus économique. Les modèles de pointe restent utiles pour les cas difficiles.

Le benchmark que les benchmarks oublient

Un problème fréquent n’apparaît pas dans les classements : le modèle peut écrire du code API propre, cohérent et faux.

Exemple typique :

const response = await fetch("/api/users/profile", {
  method: "GET",
  headers: {
    Authorization: `Bearer ${token}`,
  },
});

Le code semble valide. Mais si votre vraie route est /api/v1/me, ou si l’authentification attend un cookie plutôt qu’un header Bearer, le modèle a produit une intégration incorrecte.

Composer 2.5, Opus 4.7 et GPT-5.5 peuvent tous faire cette erreur lorsqu’ils n’ont pas accès à votre contrat API réel.

La solution est indépendante du modèle :

fournissez la spécification API réelle au modèle ;
faites générer le code à partir de cette source ;
exécutez les requêtes générées ;
vérifiez les réponses réelles avant de merger.

Vous pouvez connecter vos spécifications API à Cursor via un serveur MCP, puis valider les requêtes dans Apidog. Le guide pas à pas des spécifications API dans Cursor montre la configuration.

Le modèle choisi influence votre vitesse et votre facture. La boucle de vérification évite que cette vitesse se transforme en dette de débogage.

Foire aux questions

Composer 2.5 est-il meilleur qu’Opus 4.7 ?

Pas dans tous les cas. Sur SWE-bench Multilingual, Composer 2.5 est très proche : 79,8 % contre 80,5 %. Sur CursorBench avec les paramètres par défaut, il est légèrement devant Opus 4.7. Opus 4.7 reprend l’avantage en réglage maximal, avec un coût et une latence plus élevés.

Pour la majorité des tâches de développement quotidiennes, Composer 2.5 gagne surtout sur le rapport qualité/prix.

Composer 2.5 est-il meilleur que GPT-5.5 ?

Composer 2.5 dépasse GPT-5.5 sur SWE-bench Multilingual et CursorBench. GPT-5.5 est clairement meilleur sur Terminal-bench 2.0.

Si votre travail est principalement du code applicatif dans l’éditeur, Composer 2.5 est souvent le meilleur choix par défaut. Si vous automatisez beaucoup via terminal, GPT-5.5 mérite d’être testé en priorité.

Pourquoi Composer 2.5 est-il moins cher ?

Composer 2.5 est basé sur Kimi K2.5 et optimisé pour la boucle d’agent de Cursor. Cursor contrôle donc mieux son économie d’usage. Les modèles généralistes de pointe comme Opus 4.7 et GPT-5.5 sont facturés à des niveaux plus élevés.

Peut-on utiliser les trois dans Cursor ?

Oui. Le sélecteur de modèle de Cursor permet de changer de modèle par tâche. Cela rend une stratégie hybride très pratique : Composer 2.5 par défaut, puis Opus 4.7 ou GPT-5.5 quand le contexte l’exige.

Consultez le guide Cursor Composer 2.5 pour la configuration.

En résumé

Si vous regardez uniquement les pics de benchmark, Opus 4.7 et GPT-5.5 ont chacun des cas où ils brillent. Si vous regardez la qualité par dollar sur des tâches logicielles réelles, Composer 2.5 est le meilleur choix par défaut pour beaucoup d’équipes.

La stratégie la plus pragmatique :

Composer 2.5 pour la majorité des tâches ;
Opus 4.7 pour les problèmes de raisonnement difficiles ;
GPT-5.5 pour les workflows terminal ;
vérification systématique des intégrations API avec votre contrat réel.

Quel que soit le modèle choisi, ancrez-le dans votre spécification API et testez les sorties. Téléchargez Apidog pour envoyer des requêtes en direct aux endpoints générés et intégrer les appels fonctionnels dans vos tests automatisés.

Créer des APIs avec Cursor Composer 2.5

Antoine Laurent — Tue, 19 May 2026 02:28:50 +0000

Cursor Composer 2.5 est assez rapide et abordable pour laisser un agent générer des clients API complets et des gestionnaires de routage. Le risque apparaît quand ce code touche un service réel : le modèle écrit une requête propre vers /v2/orders, alors que votre service expose /orders et attend une charge utile différente. Le code compile, mais il échoue à l’exécution.

Essayez Apidog aujourd’hui

Ce guide montre un flux de travail plus fiable : connecter Composer 2.5 à votre spécification API réelle via MCP, générer du code aligné sur le contrat, puis vérifier les appels dans Apidog avant de les partager avec l’équipe. Si vous découvrez le modèle, le guide de Cursor Composer 2.5 explique ce que c’est et comment y accéder.

Pourquoi les modèles agentiques devinent les formes d’API

Composer 2.5 est conçu pour des tâches longues et multi-étapes. Par exemple :

Ajoute un client pour notre service de facturation et intègre-le au processus de paiement.

Le modèle peut planifier, modifier plusieurs fichiers, exécuter des tests et corriger jusqu’à obtenir un résultat cohérent. C’est l’amélioration par rapport à Composer 2, et c’est utile pour du vrai travail d’implémentation.

La limite est structurelle : si le modèle n’a pas votre contrat API en contexte, il complète les blancs avec ce qui semble statistiquement probable :

conventions REST courantes ;
noms de champs fréquents ;
préfixes comme /api ou /v1 ;
schémas d’authentification génériques.

Résultat : le code semble correct, passe parfois les tests unitaires locaux, mais échoue contre le serveur réel.

Symptômes fréquents :

endpoints presque corrects : /api/users/{id} au lieu de /users/{userId} ;
champs inventés ou mal nommés dans les bodies ;
authentification implémentée de façon générique au lieu du schéma réel ;
gestion d’erreurs incomplète ou alignée sur des statuts inexistants.

Coller une spécification OpenAPI complète dans le chat peut dépanner, mais ce n’est pas robuste : le contexte devient lourd, se périme vite et peut être ignoré partiellement. La meilleure approche consiste à fournir au modèle un accès structuré à la spécification.

La solution : ancrer Composer 2.5 dans votre spécification API réelle via MCP

Le Model Context Protocol, ou MCP, permet d’exposer des outils et des données aux modèles d’IA. Cursor prend en charge les serveurs MCP, et le serveur MCP Apidog expose votre spécification API Apidog comme source structurée consultable par le modèle pendant qu’il code.

En pratique, Composer 2.5 ne devine plus les endpoints, paramètres, schémas et réponses. Il les lit depuis votre contrat API, puis génère du code aligné dessus. C’est le même principe que le "vibe coding" avec le serveur MCP Apidog, appliqué à un modèle capable de gérer une tâche complète.

Étape 1 : préparez votre spécification API dans Apidog

Avant de connecter Cursor, vérifiez que votre contrat API est exploitable par le modèle.

À faire dans Apidog :

Concevez ou importez votre API.
Vérifiez que les endpoints sont à jour.
Renseignez les paramètres requis.
Documentez les schémas de requête et de réponse.
Ajoutez des exemples réalistes.
Confirmez les codes d’erreur importants, par exemple 400, 401, 409, 422 ou 500.

Si vous avez déjà une source existante, Apidog peut importer des spécifications OpenAPI et des collections Postman. L’objectif est simple : votre spécification doit devenir la source de vérité que Composer 2.5 consultera.

Étape 2 : connectez le serveur MCP Apidog à Cursor

Cursor lit les serveurs MCP depuis un fichier de configuration dans votre projet, généralement :

.cursor/mcp.json

Une configuration typique ressemble à ceci :

{
  "mcpServers": {
    "apidog-api-spec": {
      "command": "npx",
      "args": ["-y", "apidog-mcp-server@latest", "--project=<your-project-id>"],
      "env": {
        "APIDOG_ACCESS_TOKEN": "<your-access-token>"
      }
    }
  }
}

Remplacez :

<your-project-id> par l’ID de votre projet Apidog ;
<your-access-token> par votre jeton d’accès Apidog.

Utilisez la commande exacte indiquée dans le guide de configuration MCP Apidog, car les valeurs dépendent de votre compte et de la version du serveur.

Après avoir enregistré le fichier :

redémarrez Cursor ;
ouvrez votre projet ;
vérifiez que le serveur MCP est disponible dans l’environnement agent.

Étape 3 : confirmez que Composer 2.5 voit la spécification

Avant de lui demander de modifier du code, commencez par une requête en lecture seule.

Sélectionnez composer-2.5 dans Cursor, puis demandez :

En utilisant le serveur MCP apidog-api-spec, liste les endpoints de la ressource commandes et les champs requis pour créer une commande.

Si la réponse contient vos vrais endpoints et vos vrais champs, la connexion fonctionne.

Si Composer répond avec des routes génériques comme /api/orders ou /v1/orders alors qu’elles ne correspondent pas à votre spécification :

vérifiez .cursor/mcp.json ;
confirmez le jeton Apidog ;
vérifiez l’ID du projet ;
redémarrez Cursor ;
relancez la question de vérification.

Ne passez pas à l’implémentation tant que cette étape n’est pas validée.

Étape 4 : générez le client en imposant la source de vérité

Une fois le serveur MCP disponible, donnez une consigne explicite à Composer 2.5.

Exemple de prompt :

En utilisant le serveur apidog-api-spec comme source de vérité, écris un client TypeScript typé pour l’API des commandes, incluant les appels createOrder et getOrder. Fais correspondre exactement les schémas de requête et de réponse. Ajoute la gestion des erreurs pour la réponse de validation 422 définie dans la spécification.

Ce type de prompt force trois choses :

le modèle doit consulter la spécification ;
les types doivent refléter les vrais schémas ;
les erreurs doivent suivre le contrat documenté.

Un client généré peut par exemple prendre cette forme :

type CreateOrderRequest = {
  customerId: string;
  items: Array<{
    productId: string;
    quantity: number;
  }>;
};

type OrderResponse = {
  id: string;
  status: string;
  createdAt: string;
};

type ValidationError = {
  message: string;
  errors?: Record<string, string[]>;
};

export async function createOrder(
  payload: CreateOrderRequest,
  token: string
): Promise<OrderResponse> {
  const response = await fetch("/orders", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${token}`
    },
    body: JSON.stringify(payload)
  });

  if (response.status === 422) {
    const error = (await response.json()) as ValidationError;
    throw new Error(error.message);
  }

  if (!response.ok) {
    throw new Error(`Order creation failed: ${response.status}`);
  }

  return response.json() as Promise<OrderResponse>;
}

Le code exact doit venir de votre spécification, pas de cet exemple. L’intérêt du MCP est justement d’éviter que le modèle invente /orders, les champs ou le format d’erreur.

Vérifiez avant de faire confiance : la boucle de test Apidog

Ancrer Composer 2.5 dans une spécification réduit fortement les hallucinations, mais ne remplace pas la vérification. Une spécification peut être légèrement en retard sur le service réel, et un modèle peut mal gérer un cas limite.

Utilisez cette boucle :

Exécutez les appels générés comme de vraies requêtes.

Prenez les endpoints et payloads générés par Composer 2.5, puis exécutez-les dans Apidog contre un environnement réel ou simulé.
Comparez les hypothèses du code avec les réponses réelles.

Vérifiez les codes HTTP, les bodies, les headers, l’authentification et les erreurs.
Transformez les appels valides en tests.

Enregistrez les requêtes validées comme scénarios automatisés afin que les régressions soient détectées par la CI plutôt que par un utilisateur.
Simulez les endpoints non livrés.

Si le backend n’est pas encore disponible, utilisez le serveur de mock d’Apidog pour renvoyer des réponses réalistes. Ce workflow complète les modèles décrits dans Agents IA et tests d’API.

Le modèle produit une première implémentation alignée sur le contrat. Vous confirmez ensuite que cette implémentation fonctionne contre un serveur réel ou simulé.

Exemple de workflow de bout en bout

Prenons une fonctionnalité de remboursement dans un service de paiement.

1. Le contrat existe dans Apidog

Votre projet Apidog contient déjà :

l’endpoint de création de remboursement ;
le schéma de requête ;
le schéma de réponse ;
l’en-tête idempotency-key requis ;
les erreurs possibles, par exemple 409 en cas de doublon.

2. Cursor est connecté au serveur MCP Apidog

Votre projet contient .cursor/mcp.json, Cursor a été redémarré, et Composer 2.5 peut lire la spécification.

3. Vous donnez une tâche précise

Prompt :

En utilisant apidog-api-spec, construis le client de remboursement et un hook React qui l’appelle. Suis exactement le schéma, y compris l’en-tête idempotency-key requis par la spécification.

4. Composer 2.5 génère l’implémentation

Il peut créer ou modifier :

un client API ;
des types TypeScript ;
un hook React ;
des tests existants ou nouveaux.

Exemple de structure attendue :

src/
  api/
    refundsClient.ts
  hooks/
    useCreateRefund.ts
  types/
    refunds.ts

5. Vous vérifiez dans Apidog

Dans Apidog :

envoyez une requête de création de remboursement ;
confirmez que l’en-tête idempotency-key est requis ;
renvoyez la même requête pour vérifier le comportement en doublon ;
confirmez le 409 si la spécification le prévoit ;
enregistrez les deux requêtes comme scénarios de test.

Ce que vous évitez : un client généré qui oublie l’en-tête d’idempotence, passe en revue de code, puis déclenche deux remboursements en staging.

Foire aux questions

Composer 2.5 prend-il en charge MCP ?

Oui. Composer 2.5 a accès aux outils agent de Cursor, y compris les serveurs MCP. Sélectionnez-le dans le sélecteur de modèle et configurez le serveur dans votre projet. Le guide de Composer 2.5 couvre la sélection du modèle.

Ai-je besoin d’Apidog pour utiliser MCP avec Composer 2.5 ?

Vous avez besoin d’une source de spécification structurée. Le serveur MCP Apidog est l’option utilisée ici, car il combine spécification, test et mock dans le même outil. D’autres options sont présentées dans le récapitulatif des meilleurs serveurs MCP pour Cursor.

L’ancrage dans une spécification supprime-t-il toutes les hallucinations ?

Non. Il élimine surtout les erreurs de endpoints, paramètres et schémas, car le modèle lit le contrat réel au lieu de deviner. Mais vous devez toujours tester : une spécification peut diverger du service en cours d’exécution.

Est-ce utile pour un petit projet ?

Oui, dès qu’un modèle génère du code qui appelle une API réelle. La configuration tient dans un fichier, et le bénéfice est immédiat : chaque appel généré est basé sur votre contrat plutôt que sur une supposition plausible.

L’essentiel

Composer 2.5 peut accélérer le développement API, mais seulement s’il code contre votre contrat réel. Connectez votre spécification via le serveur MCP Apidog, demandez explicitement au modèle de l’utiliser comme source de vérité, puis vérifiez les appels dans Apidog.

Pour fermer la boucle, téléchargez Apidog, envoyez les requêtes générées, confirmez les réponses et transformez les appels valides en tests automatisés ou en mocks. La combinaison gagnante est simple : génération ancrée dans la spécification, puis vérification contre le comportement réel.

Cursor Composer 2.5 : Qu'est-ce que c'est, comment l'utiliser et comment y accéder

Antoine Laurent — Tue, 19 May 2026 02:27:35 +0000

Cursor a lancé Composer 2.5 le 18 mai 2026. Le point important pour les développeurs : un modèle de codage qui se rapproche d’Opus 4.7 et GPT-5.5 sur de vrais benchmarks logiciels, avec un coût inférieur à un dollar par tâche.

Essayez Apidog aujourd’hui

Ce guide explique comment utiliser Composer 2.5 dans Cursor : ce que c’est, comment l’activer, quand choisir la variante standard ou rapide, et comment l’intégrer à un workflow API avec Apidog pour éviter de générer du code basé sur des suppositions.

Qu’est-ce que Cursor Composer 2.5 ?

Composer 2.5 est le modèle de codage agentique de Cursor. Il peut planifier une tâche, modifier des fichiers, exécuter des commandes de terminal et vérifier son travail directement dans l’éditeur Cursor.

Il succède à Composer 2. La différence pratique : Composer 2 était surtout un partenaire rapide pour l’autocomplétion et les petites tâches, tandis que Composer 2.5 vise les tâches longues multi-fichiers.

Points clés :

Il est construit sur le checkpoint open-source Moonshot Kimi K2.5, une base d’environ un billion de paramètres.
Cursor indique avoir consacré environ 85 % du budget de calcul d’entraînement à la post-formation et à l’apprentissage par renforcement.
Le modèle a été entraîné sur 25 fois plus de tâches synthétiques que Composer 2, notamment des exercices où une fonctionnalité est supprimée puis reconstruite jusqu’à ce que les tests passent.

En pratique, Composer 2.5 maintient mieux le contexte sur les longues sessions. Il suit plus correctement les instructions complexes et évalue mieux la quantité de travail nécessaire, sans s’arrêter trop tôt ni sur-implémenter.

Pour le contexte sur la génération précédente, consultez le guide Composer 2.

Ce qui a changé sous le capot

Trois changements expliquent l’amélioration :

RL ciblée avec feedback textuel

Cursor ne se limite pas à une récompense finale. Il ajoute un court indice textuel décrivant la correction attendue, l’insère dans le contexte local, puis distille ce comportement dans le modèle. Cela aide notamment le modèle à éviter d’appeler des outils indisponibles.
Données synthétiques à grande échelle

L’augmentation de 25x des tâches synthétiques donne au modèle plus d’exemples réalistes de travail sur dépôt, validés par des tests.
Optimiseur Muon sharded avec HSDP dual-mesh

C’est une partie infrastructure, pas une fonctionnalité utilisateur. Elle a permis à Cursor d’entraîner un modèle de 1T de paramètres avec une étape d’optimisation de 0,2 seconde, donc d’itérer plus vite sur la qualité.

Vous n’avez pas besoin de mémoriser ces détails pour l’utiliser, mais ils expliquent pourquoi Composer 2.5 est plus stable sur les tâches longues que les agents précédents.

Benchmarks de Composer 2.5

Cursor compare Composer 2.5 à Opus 4.7 et GPT-5.5 sur trois suites :

Benchmark	Composer 2.5	Opus 4.7	GPT-5.5
SWE-bench Multilingual	79,8 %	80,5 %	77,8 %
Terminal-Bench 2.0	69,3 %	69,4 %	82,7 %
CursorBench v3.1	63,2 %	64,8 % max / 61,6 % default	59,2 % default

Sur SWE-bench Multilingual, Composer 2.5 atteint 79,8 %, à moins d’un point d’Opus 4.7 et devant GPT-5.5. C’est aussi une progression nette par rapport aux 73,7 % de Composer 2.

Sur CursorBench, la suite de tâches interne de Cursor, Composer 2.5 dépasse les paramètres par défaut d’Opus 4.7.

Le point faible reste Terminal-Bench 2.0, où GPT-5.5 mène avec 82,7 %. Si votre workflow dépend surtout de longues séquences terminal, ce benchmark mérite d’être pris en compte.

Le facteur décisif est le coût par tâche. Cursor indique environ 63 % sur CursorBench pour un coût moyen inférieur à un dollar par tâche, alors qu’Opus 4.7 et GPT-5.5 coûtent plusieurs dollars par tâche pour des résultats similaires ou inférieurs. Une analyse de The Decoder arrive à la même conclusion : une qualité proche des meilleurs modèles à une fraction du prix.

Conclusion : Composer 2.5 n’est pas premier sur tous les benchmarks, mais il offre un compromis qualité/prix très intéressant pour les tâches de développement quotidiennes.

Combien coûte Composer 2.5 ?

Cursor propose deux variantes :

Variante	Entrée	Sortie	Quand l’utiliser
Standard	0,50 $ / M de jetons	2,50 $ / M de jetons	Tâches agentiques courantes, meilleure efficacité coût
Rapide	3,00 $ / M de jetons	15,00 $ / M de jetons	Itération en direct, latence plus faible

La variante rapide fournit la même qualité de modèle avec une latence réduite. Elle est généralement sélectionnée par défaut.

Côté facturation :

Les abonnements individuels comme Pro incluent un pool d’utilisation Composer.
Les abonnements Équipe et Entreprise sont facturés au tarif API.
Pendant la semaine de lancement, Cursor a doublé l’utilisation de Composer 2.5 pour faciliter les premiers tests.

Pour plus de détails sur la tarification, consultez le guide de tarification Cursor Composer. Pour tester sans payer immédiatement, le guide Composer gratuit couvre l’utilisation incluse.

Comment accéder à Cursor Composer 2.5

Voici le chemin le plus direct :

Mettez Cursor à jour

Ouvrez Cursor, vérifiez les mises à jour, puis redémarrez l’application si nécessaire.
Connectez-vous avec un abonnement compatible

Les abonnements Pro et Business incluent l’utilisation de Composer. Un compte gratuit peut tester le modèle via les allocations incluses, mais un usage intensif nécessite un abonnement payant.
Ouvrez le sélecteur de modèle

Lancez une conversation ou une session agent, puis ouvrez le menu de sélection du modèle.
Choisissez composer-2.5

La variante rapide est souvent sélectionnée par défaut.
Utilisez le mode Agent

Composer 2.5 est conçu pour modifier des fichiers, lancer des commandes et utiliser des outils. Utilisez donc le mode Agent plutôt qu’une simple discussion.

Le modèle peut lire et modifier des fichiers, exécuter des commandes terminal et appeler les outils exposés par Cursor. Les documents officiels de Composer 2.5 listent les paramètres actuels.

Si vous débutez avec l’agent Cursor, la vue d’ensemble de Cursor 2.0 explique le fonctionnement de l’interface.

Comment utiliser Composer 2.5 efficacement

L’accès est simple. La qualité du résultat dépend surtout de la façon dont vous formulez la tâche.

Donnez-lui une vraie tâche de bout en bout

Composer 2.5 est plus utile sur des tâches multi-étapes que sur des micro-demandes ligne par ligne.

Exemple :

Ajoute la pagination au endpoint GET /orders.

Contraintes :
- paramètres query : page et pageSize
- page commence à 1
- pageSize max = 100
- retourne 422 si page ou pageSize est invalide
- mets à jour les tests existants
- ajoute des tests pour les cas invalides
- tous les tests doivent passer

Ce type d’invite donne au modèle un objectif clair, des contraintes et une condition de validation.

Définissez la condition de succès

Composer 2.5 a été entraîné à travailler contre des vérifications. Indiquez donc comment vous validerez la tâche.

Exemple :

La tâche est terminée uniquement si :
1. tous les tests existants passent ;
2. les nouveaux tests couvrent les cas valides et invalides ;
3. le endpoint retourne 422 pour une entrée invalide ;
4. aucun changement non lié à la pagination n’est introduit.

Cela réduit les implémentations trop larges et aide le modèle à s’auto-corriger.

Choisissez la bonne variante

Utilisez :

Standard pour les tâches longues, batch ou sensibles au coût.
Rapide quand vous itérez en direct et attendez chaque réponse.

L’intelligence est la même. Vous échangez surtout latence contre coût.

Gardez le contexte fiable

Les agents savent modifier beaucoup de code, mais ils peuvent toujours deviner lorsqu’ils ne connaissent pas la forme exacte d’une API, d’un schéma ou d’un contrat métier.

C’est particulièrement important pour le code API.

Composer 2.5 et votre workflow API

Beaucoup de tâches réelles touchent une API : clients HTTP, SDK internes, tests d’intégration, mocks, validation de payloads, gestion d’erreurs.

Si vous demandez simplement :

Écris un client TypeScript pour notre service de paiement.

Composer 2.5 peut générer un code propre, mais il risque d’inventer :

des endpoints ;
des champs ;
des codes d’erreur ;
des headers d’authentification ;
des formats de réponse.

Le bon workflow consiste à connecter le modèle à votre spécification réelle, puis à tester les appels générés.

Étape 1 : fournir la vraie spécification API

Le serveur MCP Apidog permet de connecter votre spécification API Apidog à Cursor.

Objectif : faire générer à Composer 2.5 du code de requête, des types et des tests contre votre vrai schéma, pas contre une estimation.

Si vous utilisez plusieurs agents, le guide des meilleurs serveurs MCP pour Cursor présente aussi des options complémentaires.

Étape 2 : vérifier les appels générés

Une fois le code généré, validez-le dans Apidog :

copiez ou importez les endpoints concernés ;
envoyez de vraies requêtes ;
vérifiez les codes de statut ;
confirmez la forme des réponses ;
transformez les appels corrects en tests automatisés ou en serveurs simulés.

Le modèle produit le premier brouillon. Apidog vérifie que ce brouillon correspond au comportement réel de l’API.

Cette boucle est la plus importante :

spécification réelle → génération par Composer 2.5 → test dans Apidog → automatisation

Elle évite de convertir la vitesse de génération en dette de débogage.

Composer 2.5 vs la concurrence

Résumé pratique :

vs Opus 4.7

Composer 2.5 est proche sur SWE-bench Multilingual et CursorBench, avec un coût par tâche beaucoup plus bas. Opus reste devant sur le score maximal de CursorBench.
vs GPT-5.5

Composer 2.5 gagne sur SWE-bench Multilingual et CursorBench. GPT-5.5 mène nettement sur Terminal-Bench 2.0.
vs Claude Code

Ce ne sont pas les mêmes workflows. Composer 2.5 vit dans l’éditeur Cursor ; Claude Code est un agent de terminal. La comparaison Claude Code vs Cursor détaille les cas d’usage.
vs GitHub Copilot

Copilot est surtout puissant pour l’autocomplétion inline. Composer 2.5 est pensé pour les tâches agentiques multi-fichiers. Le guide Cursor vs GitHub Copilot approfondit la comparaison.

Cursor a aussi indiqué entraîner un modèle beaucoup plus grand avec xAI, avec environ dix fois plus de puissance de calcul. Composer 2.5 semble donc être une étape intermédiaire, pas un plafond.

Questions fréquentes

Composer 2.5 est-il gratuit ?

Il n’existe pas de niveau entièrement gratuit dédié à Composer 2.5. Les abonnements individuels incluent toutefois un pool d’utilisation Composer, et Cursor a doublé l’utilisation pendant la semaine de lancement.

Le guide Composer gratuit explique l’allocation incluse.

Composer 2.5 est-il meilleur que Composer 2 ?

Oui. SWE-bench Multilingual passe de 73,7 % à 79,8 %, et Composer 2.5 maintient mieux le contexte sur les tâches longues.

Le guide Composer 2 donne le point de comparaison.

Sur quel modèle Composer 2.5 est-il basé ?

Composer 2.5 est construit sur le checkpoint open-source Kimi K2.5 de Moonshot, puis fortement post-entraîné par Cursor avec apprentissage par renforcement et tâches synthétiques.

Quelle variante choisir : standard ou rapide ?

Même intelligence, latence différente.

Choisissez standard pour réduire les coûts.
Choisissez rapide quand vous travaillez en interaction directe avec l’agent.

Composer 2.5 fonctionne-t-il avec MCP ?

Oui. Il prend en charge les outils agentiques de Cursor, dont MCP. Vous pouvez connecter votre spécification API via le serveur MCP Apidog pour générer du code aligné sur votre schéma réel.

En résumé

Composer 2.5 rend le codage agentique plus intéressant économiquement : des performances proches d’Opus 4.7 sur de vraies tâches logicielles, avec un coût par tâche beaucoup plus bas.

Pour l’utiliser :

mettez Cursor à jour ;
sélectionnez composer-2.5 dans le menu des modèles ;
utilisez le mode Agent ;
donnez-lui des tâches complètes avec critères de succès ;
vérifiez systématiquement le code généré.

Pour les APIs, ne laissez pas le modèle deviner. Générez le code contre votre spécification réelle, puis téléchargez Apidog pour envoyer des requêtes, confirmer les réponses et convertir les appels valides en tests ou en mocks.

Accès Sécurisé Agent Bitwarden : Partage de Mots de Passe Coffre-fort avec Agents IA

Antoine Laurent — Fri, 15 May 2026 08:15:39 +0000

Si vous utilisez Claude Code, Codex ou Cursor avec une API réelle, le problème arrive vite : l’agent a besoin d’identifiants, mais votre gestionnaire de mots de passe doit les protéger. Coller une clé API dans un chat l’inscrit dans le contexte du modèle. Mettre des secrets dans un fichier .env les rend lisibles par les commandes que l’agent peut exécuter. La bonne approche consiste à fournir uniquement le secret nécessaire, au bon processus, au bon moment.

Essayez Apidog aujourd’hui

Le projet open source de Bitwarden, Agent Access, propose une réponse concrète : un protocole de partage d’identifiants, un CLI (aac) et un SDK Rust + Python pour créer un tunnel chiffré entre un gestionnaire de mots de passe et un processus distant — agent IA, runner CI ou script local.

L’objectif : permettre à l’agent d’obtenir uniquement les secrets nécessaires, limités à un domaine ou à un élément de coffre-fort, sans jamais exposer l’intégralité du coffre-fort.

Ce guide montre comment installer Agent Access, utiliser aac connect et aac run, l’intégrer à Claude Code, Codex et Cursor, puis appliquer ce modèle aux workflows API décrits dans Comment sécuriser les identifiants API des agents IA.

Ce qu’est Agent Access

Agent Access est un protocole ouvert et une implémentation de référence créés par Bitwarden, mais pensés pour être adoptés par d’autres gestionnaires de mots de passe.

Le CLI aac établit un tunnel chiffré de bout en bout avec le protocole Noise.

Le modèle repose sur deux rôles :

Fournisseur : le processus qui a accès au coffre-fort et répond aux demandes.
Consommateur : l’agent, le script ou le runner CI qui demande un identifiant précis.

Le consommateur demande un identifiant par :

domaine ;
ou ID d’élément de coffre-fort.

Le fournisseur décide quoi renvoyer. Le consommateur ne peut pas parcourir le coffre-fort. Des journaux d’audit existent des deux côtés.

Agent Access est actuellement en préversion. Le README indique que les API et protocoles peuvent changer, et rappelle qu’il ne faut pas entrer directement des identifiants sensibles dans les LLM ou agents IA.

Le modèle recommandé est donc l’injection d’environnement via aac run : le secret est transmis au sous-processus qui en a besoin, sans passer par la fenêtre de contexte du modèle.

Pourquoi c’est important

Les agents de codage IA ne se limitent plus à suggérer du code. Claude Code, Codex, Cursor et d’autres outils peuvent :

lire un dépôt ;
exécuter des tests ;
appeler des API ;
lancer des scripts ;
déclencher des déploiements.

Chaque étape peut nécessiter des identifiants. L’incident Postman des clés API exposées a montré à quel point l’hygiène des secrets peut se dégrader dans les workflows humains. Avec des agents capables d’exécuter des commandes, le risque augmente.

La réponse n’est pas de faire davantage confiance à l’agent. C’est de lui donner moins.

Agent Access applique ce principe au niveau du protocole :

secrets limités à une portée précise ;
chiffrement en transit ;
récupération à l’exécution ;
disparition à la fin du processus.

Par rapport aux pratiques existantes listées dans API Key Management Tools, Agent Access cible spécifiquement les workflows agentiques.

Installation

Choisissez le binaire adapté à votre plateforme.

macOS Apple Silicon

curl -L https://github.com/bitwarden/agent-access/releases/latest/download/aac-macos-aarch64.tar.gz | tar xz
sudo mv aac /usr/local/bin/

macOS Intel

curl -L https://github.com/bitwarden/agent-access/releases/latest/download/aac-macos-x86_64.tar.gz | tar xz
sudo mv aac /usr/local/bin/

Linux x86_64

curl -L https://github.com/bitwarden/agent-access/releases/latest/download/aac-linux-x86_64.tar.gz | tar xz
sudo mv aac /usr/local/bin/

Windows x86_64

Téléchargez aac-windows-x86_64.zip depuis la page des releases, puis extrayez le binaire dans un répertoire présent dans votre PATH.

Vérifiez l’installation :

aac --help

Si le CLI Bitwarden (bw) est disponible dans votre PATH, aac l’utilise comme fournisseur par défaut.

Pour tester sans Bitwarden, utilisez le fournisseur de démonstration :

aac connect --provider example --domain test.com --output json

Démarrage rapide : coupler puis récupérer un identifiant

Le flux minimal utilise deux terminaux.

Dans le premier terminal, lancez l’écouteur sur la machine qui contient le coffre-fort :

aac listen

La commande affiche un jeton de couplage.

Dans un second terminal, côté consommateur, connectez-vous avec ce jeton et demandez un identifiant pour un domaine :

aac connect --token <jeton-de-couplage> --domain github.com --output json

Réponse typique :

{
  "credential": {
    "notes": null,
    "password": "alligator5",
    "totp": null,
    "uri": "https://github.com",
    "username": "example"
  },
  "domain": "github.com",
  "success": true
}

Votre script peut ensuite analyser ce JSON et utiliser les champs nécessaires.

Pour récupérer un identifiant par ID d’élément de coffre-fort :

aac connect --id <id-element-coffre-fort> --output json

--id et --domain sont mutuellement exclusifs. Choisissez l’un des deux.

Les champs TOTP sont inclus dans la même charge utile si l’élément de coffre-fort en contient un.

Utiliser `aac run` pour injecter des secrets

aac connect est utile si votre script sait gérer du JSON.

Pour les workflows d’agents IA, aac run est souvent plus sûr et plus simple : il récupère un identifiant, puis exécute un processus enfant avec les secrets injectés comme variables d’environnement.

Les secrets ne sont pas :

écrits sur disque ;
imprimés sur stdout ;
visibles dans l’historique shell ;
exposés dans le contexte du modèle.

Injecter des champs spécifiques

aac run \
  --domain example.com \
  --env DB_PASSWORD=motdepasse \
  --env DB_USER=nomutilisateur \
  -- psql

Injecter tous les champs avec un préfixe `AAC_`

aac run --domain example.com --env-all -- ./deploy.sh

Combiner valeurs par défaut et remplacements

aac run \
  --domain example.com \
  --env-all \
  --env CUSTOM_PW=motdepasse \
  -- ./deploy.sh

Champs disponibles :

username
password
totp
uri
notes
domain
credential_id

Exemple de modèle recommandé avec un agent :

aac run --domain api.stripe.com --env-all -- ./deploy.sh

L’agent voit la commande, mais pas la valeur du secret. Le secret est uniquement disponible pour le sous-processus deploy.sh.

C’est le même principe d’isolation que dans Comment sécuriser les identifiants API des agents IA, appliqué avec un outil concret.

SDK Python et Rust

Si l’invocation CLI ne suffit pas, Agent Access fournit aussi des SDK.

Python

from agent_access import RemoteClient

client = RemoteClient("python-remote")
client.connect(token="ABC-DEF-GHI")

cred = client.request_credential("example.com")
print(cred.username, cred.password)

client.close()

Le module Python repose sur PyO3. L’implémentation principale reste en Rust, avec le même protocole Noise sous le capot.

Rust

Le SDK Rust expose également RemoteClient.

Les exemples de référence se trouvent dans le dépôt, sous :

examples/rust-remote/

Utilisez le SDK Rust si vous développez :

un CLI ;
un runner de build ;
un service distribué sous forme de binaire compilé ;
un consommateur Agent Access intégré à votre propre outil.

Pour les équipes qui utilisent déjà des outils de gestion de secrets, ce modèle complète les intégrations comme HashiCorp Vault ou Azure Key Vault. Agent Access ne remplace pas nécessairement ces solutions d’entreprise, mais il s’adapte bien aux postes développeur et aux runners CI.

Intégration avec les agents de codage IA

Claude Code

Créez un script que Claude Code peut appeler, puis encapsulez l’accès au secret avec aac run.

Exemple :

# deploy.sh
#!/usr/bin/env bash
aac run --domain prod.example.com --env-all -- ./run-deploy.sh

Rendez le script exécutable :

chmod +x deploy.sh

Puis demandez à Claude Code d’exécuter :

./deploy.sh

L’agent ne reçoit aucun identifiant dans l’invite. Le secret est uniquement transmis à run-deploy.sh.

Pour la CI, le même modèle peut être appliqué avec l’intégration Claude Code GitHub Actions :

installez aac dans le runner ;
couplez le runner avec le fournisseur ;
exécutez vos scripts via aac run.

OpenAI Codex

Le même modèle fonctionne avec le CLI Codex.

Exposez au modèle une commande ou un script contrôlé :

./test-api.sh

Puis encapsulez les secrets dans ce script :

# test-api.sh
#!/usr/bin/env bash
aac run --domain staging.example.com --env-all -- ./run-api-tests.sh

La couche d’appel d’outils de Codex voit la commande, pas la valeur du secret.

L’article Codex depuis votre téléphone couvre la surface plus large de Codex ; Agent Access ajoute ici la couche de protection des identifiants.

Cursor

Pour Cursor, utilisez le même pattern avec les commandes de terminal et les workflows Composer.

Exemple :

# local-check.sh
#!/usr/bin/env bash
aac run --domain dev.example.com --env-all -- npm test

Cursor peut appeler ./local-check.sh, mais les secrets restent limités au sous-processus.

Comme Cursor travaille souvent localement, l’écouteur aac listen s’exécute généralement sur la même machine que le consommateur.

OpenClaw

Agent Access fournit une compétence OpenClaw officielle prête à l’emploi. Le dépôt contient un fichier SKILL.md.

Pour les équipes utilisant des compétences de style OpenClaw, cette intégration permet à la compétence de :

connaître la forme du protocole ;
récupérer l’identifiant ;
le transmettre à l’outil aval exposé par la compétence.

Le guide des clés API OpenClaw couvre le sujet plus large de la gestion des identifiants dans cet écosystème.

Modèle de sécurité

Agent Access repose sur trois garanties principales.

1. Chiffrement de bout en bout

Le trafic entre consommateur et fournisseur est chiffré avec le framework Noise, la même famille de protocoles utilisée par des outils comme WireGuard et Signal.

2. Identifiants à portée limitée

Le consommateur demande un domaine ou un ID d’élément précis. Il ne peut pas énumérer tout le coffre-fort.

3. Pas de secret sur disque par défaut

Avec aac run, les secrets sont injectés comme variables d’environnement dans un sous-processus. Ils ne sont pas écrits dans un fichier et ne sont pas affichés dans la sortie standard.

Ce qu’Agent Access ne résout pas

Agent Access réduit la surface d’exposition, mais ne supprime pas tous les risques.

Il ne protège pas contre :

un processus consommateur compromis : si le script ou l’agent est malveillant, il peut toujours exfiltrer les secrets auxquels il a accès ;
un fournisseur compromis : si le coffre-fort lui-même est compromis, le protocole ne suffit plus ;
les secrets collés dans une invite LLM : si vous copiez une clé dans un chat, Agent Access ne peut pas l’effacer du contexte.

La défense principale reste la portée minimale : donnez au processus uniquement ce dont il a besoin.

Workflow API courant : agent, CI et Apidog

Un workflow pratique pour une équipe API ressemble à ceci :

L’agent écrit le code

Claude Code, Codex ou Cursor modifie un endpoint et ouvre une PR.
La CI exécute les tests

Le runner appelle aac run pour récupérer une clé API à portée limitée, puis lance les tests sur un environnement de préproduction.
Apidog vérifie le contrat

Apidog exécute les tests de contrat OpenAPI comme étape CI séparée, également via aac run.

Exemple de script CI :

#!/usr/bin/env bash
set -euo pipefail

aac run \
  --domain staging.example.com \
  --env-all \
  -- ./run-contract-tests.sh

Résultat :

l’agent peut déclencher le workflow ;
la CI peut tester l’API ;
Apidog peut valider le contrat ;
le secret reste hors du contexte du modèle.

Le guide Comment tester les agents IA qui appellent vos API détaille cette approche côté test.

Limitations

Avant de l’adopter, gardez ces points en tête.

Préversion : les API et protocoles peuvent changer. Évitez de verrouiller un workflow critique sans prévoir de maintenance.
CLI Bitwarden requis par défaut : le fournisseur par défaut repose sur bw. Installez le CLI Bitwarden ou utilisez --provider example pour tester.
Pas encore de fichier de configuration : les invocations reposent principalement sur des flags. Utilisez des scripts pour standardiser les commandes.
Aucun outil ne protège un secret collé dans une invite : ne copiez jamais d’identifiants dans un chat LLM.

FAQ

Agent Access est-il gratuit ?

Oui. Le CLI, les SDK et le protocole sont open source dans l’organisation Bitwarden sur GitHub. Si vous utilisez Bitwarden comme coffre-fort, votre usage de Bitwarden reste soumis à son modèle habituel.

Fonctionne-t-il avec d’autres gestionnaires de mots de passe ?

Le protocole est conçu pour être neutre vis-à-vis des fournisseurs. L’implémentation de référence prend en charge Bitwarden et un fournisseur d’exemple. D’autres fournisseurs pourront implémenter leurs propres intégrations.

Puis-je l’utiliser sans gestionnaire de mots de passe ?

Pour tester, oui :

aac connect --provider example --domain test.com --output json

Pour un usage réel, utilisez un fournisseur de secrets adapté, comme Bitwarden aujourd’hui.

Le processus consommateur a-t-il besoin du réseau ?

Oui, il doit pouvoir atteindre l’écouteur du fournisseur. Un usage local fonctionne si l’écouteur et le consommateur sont sur la même machine.

En quoi est-ce différent d’un fichier `.env` ?

Un fichier .env est stocké sur disque, peut être commité par erreur et peut être lu par tout processus que l’agent peut lancer.

Avec aac run, le secret est injecté uniquement dans le sous-processus ciblé et disparaît à la fin de son exécution.

Agent Access remplace-t-il HashiCorp Vault ou AWS Secrets Manager ?

Non. Les coffres-forts d’entreprise restent adaptés aux secrets service-à-service à grande échelle. Agent Access couvre surtout les workflows de développeurs, d’agents et de runners CI où il faut transmettre un secret limité à un processus spécifique.

Anthropic, OpenAI ou d’autres fournisseurs l’intègrent-ils directement ?

Aucune intégration directe n’est annoncée. Le modèle actuel consiste à envelopper vos scripts avec aac run.

Où signaler des bugs ou contribuer ?

Sur le dépôt GitHub Agent Access. Les issues, PR et discussions de protocole y sont centralisées.

Essayez-le maintenant

Testez la boucle minimale :

aac listen

Puis, dans un autre terminal :

aac connect --provider example --domain test.com --output json

Ensuite :

remplacez le fournisseur d’exemple par Bitwarden ;
enveloppez un script réel avec aac run ;
retirez les clés API des prompts, fichiers .env et historiques shell.

Associez Agent Access à Apidog pour la partie test API : le coffre-fort garde le secret, Apidog teste le contrat, l’agent exécute le workflow, et aucun identifiant n’est exposé en clair.

7 Meilleurs Outils de Gestion d'API en 2026, Classés par G2

Antoine Laurent — Fri, 15 May 2026 07:42:43 +0000

La grille G2 Printemps 2026 pour la gestion des API est publiée : deux Leaders (Apidog, viaSocket), trois High Performers (Traefik Labs, Rasayel, Backendless) et deux acteurs de niche (Moesif/WSO2, Thunder Client). Voici comment lire cette grille côté implémentation : quel outil choisir, pour quel workflow API, et comment l’intégrer dans votre pile.

Essayez Apidog aujourd’hui

En bref

Apidog et viaSocket sont en tête de la grille G2 Printemps 2026 de gestion des API. Apidog est adapté aux équipes qui veulent concevoir, tester, simuler et documenter leurs API dans un seul espace de travail. viaSocket cible plutôt l’automatisation de workflows sans code avec des hooks d’API.

Les cinq autres outils — Traefik Labs, Rasayel, Backendless, Moesif (WSO2) et Thunder Client — résolvent des problèmes plus spécifiques. Le bon choix dépend donc de ce que “gestion des API” signifie concrètement dans votre architecture.

Ce que signale la grille G2 Printemps 2026

Les rapports G2 Printemps 2026 ont été publiés le 17 mars 2026, avec 27 019 rapports, soit une augmentation trimestrielle de 1,72 %. Selon Palmer Houchins, VP Marketing, seuls 3 % des produits sur G2 reçoivent un badge “Leader” toutes catégories confondues.

La grille utilise deux axes :

Satisfaction client : basée sur les avis.
Présence sur le marché : taille, portée, volume d’avis.

Dans la catégorie gestion des API, Apidog et viaSocket sont classés Leaders. Traefik Labs, Rasayel et Backendless sont High Performers. Moesif, désormais une entreprise WSO2, et Thunder Client sont classés Niche.

Le quadrant est utile, mais il ne suffit pas. Un outil de niche peut être le bon choix si son périmètre correspond exactement à votre besoin. À l’inverse, un Leader peut être inadapté s’il résout un problème que vous n’avez pas.

Si vous voulez tester un workflow complet conception → test → mock → documentation, vous pouvez télécharger Apidog.

Les sept outils en un coup d’œil

Outil	Quadrant G2	Meilleure adéquation	Open source ?	Modèle de tarification
Apidog	Leader	Conception, test, simulation, documentation API tout-en-un	Niveau gratuit + payant	SaaS par utilisateur
viaSocket	Leader	Automatisation de workflows sans code avec des hooks d’API	Non	Plan d’entrée à 50 $/mois
Traefik Labs	High Performer	Passerelle API cloud-native + gouvernance GitOps	Oui, Proxy OSS	OSS gratuit, Hub payant
Rasayel	High Performer	Messagerie WhatsApp Business + API REST	Non	SaaS par siège
Backendless	High Performer	BaaS avec REST et GraphQL auto-générés	Non	Niveau gratuit + payant
Moesif (WSO2)	Niche	Analyse, observabilité, monétisation API	Non	Basé sur l’utilisation
Thunder Client	Niche	Client REST VS Code pour test individuel	Non	Gratuit + Pro payant

La catégorie G2 mélange plusieurs familles d’outils :

plateformes de cycle de vie API ;
iPaaS et automatisation ;
passerelles API ;
observabilité et analytics ;
extensions d’IDE.

Lire le classement sans ce contexte peut conduire à comparer des outils qui ne résolvent pas le même problème.

Apidog : le leader des workflows API de bout en bout

Apidog regroupe quatre phases dans un même espace de travail :

conception ;
test ;
simulation ;
documentation.

C’est son principal intérêt pour les équipes qui veulent éviter de maintenir une chaîne d’outils séparés pour les specs, les collections de tests, les mocks et la documentation.

Ce que vous obtenez :

Conception d’API visuelle : éditeur OpenAPI 3.0/3.1 axé sur le schéma avec prise en charge des branches.
Tests automatisés : constructeur de tests visuel, intégration CI/CD, sans script dans la plupart des cas.
Simulation intelligente : réponses dynamiques générées depuis le schéma.
Documentation auto-générée : URL publique ou privée, avec prise en charge de domaine personnalisé.
Collaboration d’équipe : synchronisation en temps réel, contrôle de version, accès basé sur les rôles.

Workflow recommandé avec Apidog

Pour une équipe backend/frontend/QA, le workflow peut être :

1. Créer ou importer la spécification OpenAPI.
2. Définir les endpoints, paramètres, schémas et réponses.
3. Générer un mock server pour débloquer le frontend.
4. Créer des scénarios de test sur les mêmes endpoints.
5. Publier la documentation API.
6. Brancher les tests dans la CI/CD.

Exemple de validation côté équipe :

Backend       → définit le contrat API
Frontend      → consomme le mock dès que le schéma est prêt
QA            → écrit les scénarios de test
Tech lead     → relit les changements via branches
Documentation → générée depuis la source de vérité

Ses points forts concernent surtout les équipes jusqu’à environ 100 ingénieurs qui veulent une source unique de vérité pour leurs spécifications API. Les commentateurs G2 Printemps 2026 soulignent aussi la revue de conception basée sur les branches et l’éditeur OpenAPI 3.1 comme différenciateurs par rapport à Stoplight et SwaggerHub.

Vous pouvez télécharger Apidog et importer une collection Postman en un clic. Le niveau gratuit couvre la plupart des petites équipes.

viaSocket : leader pour les équipes d’intégration sans code

viaSocket est l’autre Leader, mais son cas d’usage est différent. C’est une plateforme d’automatisation de workflow basée sur l’IA, plus proche de Zapier ou Make que d’une passerelle API classique.

Son rôle : connecter des applications SaaS avec des webhooks, de la logique conditionnelle et du JavaScript personnalisé, sans dépendre d’une équipe d’ingénierie.

À utiliser si

vos équipes opérations, marketing ou revenus veulent connecter des outils SaaS ;
vous avez besoin de workflows basés sur des webhooks ;
vos intégrations portent sur des applications externes déjà cataloguées ;
vous voulez limiter le développement custom.

À éviter si

vous cherchez une passerelle API ;
vous avez besoin de limitation de débit ;
vous devez gérer des flux OAuth complexes ;
vous faites du contract testing ;
vos API sont surtout des microservices internes.

Le prix commence à 50 $/mois pour les comptes créés après septembre 2025, ce qui peut être trop élevé pour des expérimentations individuelles.

Traefik Labs : passerelle open source avec gestion des API en sus

Traefik Proxy est un proxy d’application cloud-native open source. Traefik Hub ajoute une couche de gestion des API : portails développeurs, contrôles de cycle de vie et gouvernance GitOps.

Cette combinaison explique son classement High Performer : forte satisfaction, mais présence marché G2 impactée par le fait qu’une grande partie de l’usage se fait via l’open source.

Ce que Traefik fait bien

Kubernetes Ingress ;
découverte de services ;
configuration dynamique ;
certificats Let’s Encrypt automatiques ;
gouvernance GitOps ;
gestion des routes et politiques via Git ;
fonctionnalités de passerelle IA ajoutées en 2026, dont la prise en charge de l’API OpenAI Responses comme endpoint géré.

Exemple de logique d’implémentation GitOps :

repo-infra/
  apis/
    users-api.yaml
    billing-api.yaml
  routes/
    users-route.yaml
    billing-route.yaml
  policies/
    auth-policy.yaml
    rate-limit-policy.yaml

Limites

Traefik n’est pas un outil de conception ni de test API. Il est donc souvent utilisé en aval d’un outil comme Apidog :

Apidog      → conception, tests, mocks, documentation
Traefik Hub → exposition, routage, politiques, gouvernance

Les fonctionnalités d’entreprise comme LDAP, portails avancés ou RBAC se trouvent dans Hub, pas dans Traefik Proxy OSS.

Pour approfondir, consultez le récapitulatif des outils de gestion d’API open source et des meilleures plateformes de gestion d’API pour les équipes d’entreprise.

Rasayel : plateforme API WhatsApp Business avec une touche d’originalité

Rasayel est d’abord une plateforme WhatsApp Business avec boîte de réception d’équipe, chatbots et messagerie de masse.

Son classement dans la catégorie API vient de ses API REST et GraphQL, limitées à 200 req/min sur REST, et de son interface de gestion des clés API avec autorisation de lecture/écriture limitée.

À choisir si

votre support client ou vos ventes passent par WhatsApp ;
vous avez besoin d’un accès programmatique à WhatsApp Business ;
vous voulez connecter WhatsApp à HubSpot ou Pipedrive ;
vous préférez utiliser des webhooks plutôt que Twilio directement.

À éviter si

vous gérez des microservices internes ;
vous cherchez une passerelle Edge ;
WhatsApp n’est pas dans votre pile ;
vous avez besoin d’une plateforme générale de gestion du cycle de vie API.

Rasayel est solide dans son périmètre, mais ce n’est pas le point de départ pour la plupart des décisions de plateforme API.

Backendless : BaaS avec API auto-générées

Backendless est une plateforme backend-as-a-service. Elle génère automatiquement des endpoints REST et GraphQL depuis votre modèle de données.

Le modèle est simple :

Créer une table  → obtenir une API
Créer un service → obtenir des invocations suivies
Définir un rôle  → contrôler l’accès par opération

Points forts

backend low-code ;
SDK Android, iOS, JavaScript et .NET ;
rôles de sécurité par opération ;
suivi au niveau du service ;
logs d’appels API par méthode, type de client et succès/erreur.

Mauvaise adéquation

Backendless est moins adapté si :

vous avez déjà une pile backend ;
vous voulez gérer des API existantes ;
vous avez besoin d’une conception contract-first ;
vous voulez éviter le couplage fournisseur ;
vous cherchez une passerelle API.

Backendless convient surtout aux startups et petites équipes qui veulent éviter de construire un backend complet dès le départ.

Moesif (une entreprise WSO2) : analyse et monétisation des API

Moesif est un outil d’observabilité et de monétisation pour les API déjà déployées. Ce n’est ni une passerelle ni un outil de conception.

WSO2 a acquis Moesif en mai 2025 et l’intègre comme couche analytique pour la plateforme Choreo de WSO2. Moesif continue toutefois de fonctionner comme filiale indépendante avec sa propre feuille de route.

Ce que Moesif apporte

analyse d’utilisation des API ;
répartition par utilisateur, endpoint et région ;
détection d’anomalies de trafic ;
monétisation basée sur l’usage ;
gestion des plans ;
tableaux de bord clients ;
analyse de l’entonnoir et de la rétention des consommateurs d’API.

À utiliser si

vous avez une API publique déjà déployée ;
vous voulez comprendre qui utilise quoi ;
vous préparez une tarification usage-based ;
vous avez besoin de facturation au compteur ;
vous voulez donner de la visibilité aux clients API.

À éviter si

vous n’avez pas encore d’API publique ;
vous cherchez une passerelle ;
vous êtes développeur solo ;
votre problème principal est la conception ou le test.

Thunder Client : l’extension client REST de VS Code

Thunder Client est une extension VS Code pour envoyer des requêtes HTTP. Son cas d’usage est proche de Postman ou Insomnia, mais directement dans l’éditeur.

Son classement Niche reflète un périmètre réduit, mais utile : test REST rapide pour développeur individuel.

Points forts

pas besoin de quitter VS Code ;
léger et rapide ;
collections stockées en JSON dans le dépôt ;
compatible Git ;
variables d’environnement ;
scripting et assertions de test de base.

Exemple d’usage typique :

1. Coder un endpoint.
2. Lancer l’API en local.
3. Envoyer une requête HTTP depuis VS Code.
4. Vérifier le statut, le body et les headers.
5. Committer la collection JSON avec le code.

Points faibles

Thunder Client n’est pas :

une plateforme de collaboration d’équipe ;
un outil de conception API ;
une passerelle ;
un serveur de simulation ;
un générateur de documentation.

Les limites de collaboration sont détaillées dans Thunder Client pour les équipes : limitations de collaboration.

Thunder Client convient si votre définition de la gestion API est : “tester mes endpoints pendant que je code”. Pour une équipe, Apidog couvre ce même workflow de test avec collaboration, conception, simulation et documentation.

Comment choisir le bon outil pour votre équipe

Commencez par identifier votre problème principal.

1. Vous devez concevoir, tester, simuler et documenter

Choisissez Apidog.

Besoin :
- OpenAPI
- tests automatisés
- mock server
- documentation
- collaboration

Outil :
Apidog

2. Vous devez exposer et gouverner des services

Choisissez Traefik Hub ou une passerelle équivalente.

Besoin :
- routage
- auth
- rate limiting
- politiques
- GitOps
- Kubernetes

Outil :
Traefik

3. Vous devez analyser une API déjà en production

Choisissez Moesif.

Besoin :
- analytics
- usage par client
- anomalies
- monétisation
- billing usage-based

Outil :
Moesif

4. Vous devez connecter des applications SaaS

Choisissez viaSocket.

Besoin :
- webhooks
- automatisations no-code
- connecteurs SaaS
- logique conditionnelle

Outil :
viaSocket

5. Vous devez créer un backend rapidement

Choisissez Backendless.

Besoin :
- BaaS
- REST auto-généré
- GraphQL auto-généré
- SDK mobiles/web
- rôles de sécurité

Outil :
Backendless

6. Vous devez intégrer WhatsApp Business

Choisissez Rasayel.

Besoin :
- WhatsApp Business
- boîte de réception partagée
- API REST/GraphQL
- webhooks
- intégration CRM

Outil :
Rasayel

7. Vous testez seul depuis VS Code

Choisissez Thunder Client.

Besoin :
- requêtes HTTP
- collections locales
- environnement VS Code
- tests simples

Outil :
Thunder Client

Matrice de décision rapide

Si votre priorité est…	Commencez par…
Conception + tests + mocks + docs	Apidog
Passerelle API cloud-native	Traefik
Automatisation SaaS no-code	viaSocket
WhatsApp Business	Rasayel
Backend sans construire l’infra	Backendless
Analytics et monétisation API	Moesif
Test REST solo dans VS Code	Thunder Client

Pour aller plus loin, consultez l’outil de test API pour une équipe de 50 ingénieurs et la comparaison de plateformes API axées sur la conception entre Apidog, Stoplight et SwaggerHub.

Ce que vous apprend la grille Printemps 2026

Les sept outils de la grille G2 Printemps 2026 de gestion des API ne se concurrencent pas tous directement. Ils ciblent des couches différentes de la pile API.

À retenir :

Apidog et viaSocket sont Leaders, mais ne résolvent pas le même problème.
Apidog couvre le cycle de vie API : conception, test, simulation, documentation.
viaSocket cible l’intégration no-code entre applications SaaS.
Traefik est pertinent pour les passerelles et la gouvernance GitOps.
Rasayel est spécialisé WhatsApp Business.
Backendless est utile si vous voulez générer un backend et ses API.
Moesif est fort sur l’analytics, l’observabilité et la monétisation.
Thunder Client reste efficace pour tester des endpoints seul dans VS Code.

Une pile API pragmatique peut ressembler à ceci :

Apidog        → design-first, tests, mocks, documentation
Traefik       → gateway, routage, politiques
Moesif        → analytics, usage, monétisation

Si votre équipe passe du temps sur la conception, les tests, la simulation et la documentation, commencez par Apidog. Vous pouvez télécharger Apidog et importer une API depuis Postman en quelques minutes.

Pour le côté passerelle, consultez aussi le top 10 des passerelles API pour les développeurs en 2026.

Comment Déboguer le Protocole Agent-to-Agent (A2A) avec le Débogueur A2A d'Apidog

Antoine Laurent — Fri, 15 May 2026 04:26:57 +0000

Si vous construisez des agents IA qui communiquent avec d'autres agents IA, le premier blocage est souvent l'observabilité : difficile de voir exactement ce qu'un agent envoie, reçoit et interprète. Les journaux de console sont incomplets, les onglets réseau masquent souvent les champs structurés, et les scripts de test maison deviennent vite fragiles. Le Débogueur A2A d'Apidog fournit une boucle de test directe pour le protocole Agent2Agent (A2A) : collez une URL de Carte d'Agent, cliquez sur Connecter, envoyez un message, puis inspectez la réponse dans trois vues.

Essayez Apidog aujourd’hui

Ce guide montre comment utiliser le Débogueur A2A, connecter un premier agent, envoyer une requête de test, lire la réponse brute, gérer l'authentification et l'intégrer à vos tests MCP existants dans Apidog. Si vous avez besoin du contexte protocolaire, commencez par le guide MCP vs A2A d'Apidog, puis revenez à cette procédure.

Ce qu'est l'A2A en bref

A2A, pour Agent2Agent, est un protocole ouvert pour la communication entre agents. Il définit comment un agent publie ses capacités via une Carte d'Agent, comment un autre agent s'y connecte, comment les messages et pièces jointes sont échangés, et comment l'état des tâches est rapporté.

Vous pouvez le voir comme une couche de transport standardisée pour les échanges agent-à-agent. Par exemple, un agent LangGraph dans un pipeline de données peut appeler un agent CrewAI géré par une autre équipe sans connaître son implémentation interne.

A2A est différent du MCP, ou Model Context Protocol. Le MCP sert à connecter un agent à des outils, ressources ou prompts. L'A2A sert à connecter des agents entre eux. Pour comparer les deux usages, consultez le comparatif MCP vs A2A.

Ce que permet le Débogueur A2A

Le Débogueur A2A est intégré à Apidog. Il sert à tester un point d'accès A2A avant de l'intégrer dans un workflow multi-agent.

Fonctionnalités principales :

Connexion via Carte d'Agent : collez l'URL de la carte, connectez-vous, puis vérifiez le nom, la description, les capacités, les compétences déclarées et la version du protocole.
Validation rapide du manifeste : si la Carte d'Agent est mal formée, la connexion échoue explicitement, ce qui permet de corriger le manifeste plutôt que de déboguer un faux problème réseau.
Envoi de messages : saisissez du texte, ajoutez des fichiers si l'agent les accepte, et transmettez des métadonnées personnalisées.
Trois vues de réponse : utilisez l'aperçu structuré, le contenu lisible et les données brutes JSON-RPC.
Authentification intégrée : configurez un jeton Bearer, une authentification basique ou une clé API via en-tête personnalisé.
En-têtes personnalisés : ajoutez des valeurs attendues par une passerelle, un proxy ou un middleware.
Historique de session : revenez sur les messages envoyés pendant la session de test.

Vous n'avez pas besoin d'écrire de commande curl. Apidog gère l'enveloppe JSON-RPC, le streaming SSE lorsque l'agent le prend en charge, et l'analyse de la réponse.

Étape 1 : connectez-vous à votre premier agent A2A

Avant d'ouvrir le débogueur, préparez ces éléments :

Un client Apidog à jour

Les versions anciennes ne contiennent pas le Débogueur A2A. Si nécessaire, téléchargez Apidog.
Une URL de Carte d'Agent

C'est le point d'entrée standard d'un agent compatible A2A. En local, elle ressemble souvent à ceci :

   http://localhost:3000/.well-known/agent.json

Pour un agent hébergé, utilisez l'URL fournie par votre plateforme ou votre équipe d'infrastructure.

Des identifiants si l'agent est protégé Préparez le jeton Bearer, la clé API ou les identifiants d'authentification basique.

Ensuite :

Ouvrez Apidog.
Accédez au Débogueur A2A.
Collez l'URL de la Carte d'Agent.
Configurez l'authentification si nécessaire.
Cliquez sur Connecter.

Si l'agent répond avec une Carte d'Agent valide, le statut passe à Connecté. Le panneau affiche alors les métadonnées de l'agent : nom, description, capacités, compétences déclarées et version du protocole.

Dépanner une connexion échouée

Si la connexion échoue, vérifiez d'abord ces points :

URL incorrecte ou agent arrêté

Ouvrez l'URL dans un navigateur ou testez-la avec un client HTTP. Vous devez recevoir une charge utile JSON.
Carte d'Agent invalide

Comparez votre manifeste à la spécification A2A sur GitHub.
Authentification requise sur le point de découverte

Certains agents protègent aussi l'URL de la Carte d'Agent. Configurez l'authentification dans Apidog avant de cliquer sur Connecter.

Étape 2 : envoyez un message de test

Une fois connecté, ouvrez l'onglet Messages et envoyez une requête minimale. Commencez simple afin de valider le transport avant de tester la logique métier.

Exemple de message :

Summarize the last three customer feedback notes in our shared knowledge base, then draft a one-paragraph reply for the support team.

Avant de cliquer sur Envoyer, vous pouvez ajouter :

Une pièce jointe

Cliquez sur l'icône de trombone et sélectionnez un fichier. Le débogueur vérifie les types d'entrée déclarés par l'agent et bloque les fichiers non pris en charge avant l'envoi.
Des métadonnées personnalisées

Ajoutez des paires clé-valeur comme :

  priority: high
  tenant: acme-corp
  locale: fr-FR

Ces métadonnées sont intégrées à l'enveloppe de requête A2A. Elles seront visibles par l'agent si son gestionnaire les lit.

Cliquez ensuite sur Envoyer. Apidog construit la structure du message A2A, l'envoie à l'agent et attend la réponse.

Étape 3 : inspectez la réponse

Une réponse A2A peut contenir du texte, du JSON structuré, des références de fichiers, des artefacts ou un mélange de plusieurs formats. Le débogueur expose trois vues complémentaires.

Vue Aperçu

La vue Aperçu affiche les champs structurés sous forme d'arbre. Utilisez-la pour vérifier rapidement :

l'ID de tâche ;
le statut ;
les artefacts ;
les messages intermédiaires ;
l'historique ;
les champs imbriqués.

Vue Contenu

La vue Contenu affiche la partie lisible par un humain. Si l'agent renvoie du texte, c'est généralement cette sortie que vous pourriez afficher dans une interface utilisateur.

Si la réponse contient un artefact structuré avec une partie text/plain, Apidog affiche le texte extrait.

Vue Données brutes

La vue Données brutes affiche la charge utile JSON-RPC complète. C'est la vue à utiliser pour :

vérifier les noms exacts des champs ;
comparer la réponse à la spécification ;
repérer les erreurs d'échappement ;
copier une réponse dans un rapport de bug ;
confirmer si le problème vient du transport ou de la logique de l'agent.

Exemple de réflexe utile : lors du premier test, commencez par les Données brutes, pas par l'aperçu. Vous voyez ainsi exactement ce que l'agent a émis.

Si l'aperçu semble correct mais que le contenu est vide, l'agent renvoie probablement un artefact typé qu'Apidog peut afficher sous forme structurée, mais pas aplatir en texte.

Si les données brutes contiennent une erreur, commencez par le champ :

{
  "error": {
    "message": "..."
  }
}

L'historique de session se trouve dans le panneau de gauche. Chaque message envoyé devient un tour consultable. Cliquez sur Effacer quand vous démarrez un nouveau test afin d'éviter que du contexte obsolète influence l'agent.

Authentification : trois schémas courants

La plupart des points d'accès A2A en production sont protégés. Le débogueur prend en charge les schémas suivants.

Jeton Bearer

Utilisez ce mode pour les agents hébergés ou les environnements protégés par un token.

Dans le panneau d'authentification :

Sélectionnez Jeton Bearer.
Collez le jeton.
Envoyez la requête.

Apidog ajoute l'en-tête suivant à chaque requête :

Authorization: Bearer sk-agent-7f3e9a...

Authentification basique

Utilisez ce mode pour des agents internes ou des systèmes hérités protégés par nom d'utilisateur et mot de passe.

Dans Apidog :

Sélectionnez Authentification basique.
Saisissez le nom d'utilisateur.
Saisissez le mot de passe.

Apidog calcule automatiquement l'en-tête Authorization: Basic ... encodé en base64.

Clé API via en-tête personnalisé

Certains agents attendent un en-tête non standard, par exemple :

X-Agent-Key: your-api-key

Dans ce cas :

Ouvrez la section En-têtes.
Ajoutez le nom de l'en-tête.
Ajoutez sa valeur.
Relancez la connexion ou le message.

Le même mécanisme fonctionne pour des en-têtes de passerelle, des identifiants de locataire, des jetons CSRF ou des signatures de requête.

Pour aller plus loin sur la gestion des secrets côté agents, consultez le guide des identifiants d'agent IA d'Apidog.

En-têtes personnalisés ou métadonnées : lequel utiliser ?

Deux mécanismes permettent d'ajouter du contexte à une requête A2A, mais ils ne se situent pas au même niveau.

Canal	Où cela réside	Utilisation
En-têtes personnalisés	En-têtes HTTP	Authentification de passerelle, observabilité, `X-Request-Id`, feature flags
Métadonnées	Charge utile du message A2A	Contexte lu par l'agent : priorité, locataire, locale

Règle pratique :

si un proxy inverse, une passerelle API ou un middleware doit lire la valeur, utilisez un en-tête ;
si le gestionnaire de tâche de l'agent doit lire la valeur, utilisez les métadonnées.

Beaucoup de bugs du type “l'agent ignore mon indice” viennent d'une confusion entre ces deux couches.

Débogueur A2A vs test de serveur MCP dans Apidog

Apidog propose à la fois un débogueur A2A et un flux de test MCP. Les deux outils ciblent des protocoles différents.

Outil	Protocole	Ce que vous testez	Quand l'utiliser
Débogueur A2A	Agent2Agent	Connectivité, échange de messages, statut de tâche	Quand des agents appellent d'autres agents
Test de serveur MCP	Model Context Protocol	Appels d'outils, accès aux ressources, modèles de prompts	Quand un serveur MCP expose des outils ou ressources à un agent

En résumé :

le MCP permet à un agent d'accéder à des systèmes externes ;
l'A2A permet à un agent de parler à un autre agent.

Si vous hésitez entre les deux, le guide MCP vs A2A clarifie les cas d'usage.

Pour la partie MCP du workflow, le manuel de test de serveur MCP couvre les tests manuels et automatisés dans Apidog. Dans la pratique, de nombreuses équipes utilisent les deux : A2A pour la coordination entre agents, MCP pour l'accès aux outils.

Boucle de débogage recommandée

Quand un agent “ne répond pas comme prévu”, évitez de tout déboguer en même temps. Isolez d'abord le transport, puis la logique.

Procédure :

Ouvrez le Débogueur A2A.
Connectez-vous à l'agent.
Vérifiez que la Carte d'Agent expose bien la compétence attendue.
Envoyez le message le plus simple possible qui devrait déclencher cette compétence.
Commencez avec du texte brut uniquement.
Ajoutez les fichiers et les métadonnées seulement après validation du chemin texte.
Lisez d'abord les Données brutes.
Vérifiez si la réponse contient les champs attendus.
Si un champ manque, cherchez côté code de l'agent.
Si la réponse est bien formée mais incorrecte, cherchez côté prompt, modèle ou logique métier.

Cette approche reprend le même principe que dans l'article Comment tester les agents IA qui appellent vos API : valider le câblage avant de déboguer le raisonnement.

Où l'intégrer dans votre workflow IA

Les systèmes multi-agents rendent le trafic agent-à-agent aussi important que le trafic API classique. L'article Les agents IA sont les nouveaux consommateurs d'API explique pourquoi il faut traiter ce trafic comme un cas d'usage de premier niveau.

Le guide Concevoir des API pour les agents IA détaille aussi ce qui change quand le consommateur d'une API est un agent piloté par LLM plutôt qu'un développeur humain.

Le Débogueur A2A se place au même niveau que le débogueur visuel client MCP d'Apidog. Dans les deux cas, l'objectif est de rendre visible un trafic souvent caché dans les SDK d'agents.

Le workflow devient :

connecter l'agent ;
envoyer une requête minimale ;
inspecter la réponse brute ;
corriger le contrat, les métadonnées ou le code ;
répéter avant la mise en production.

Apidog est gratuit à télécharger, et le Débogueur A2A est inclus dans le client standard.

Questions fréquentes

Le Débogueur A2A est-il gratuit ?

Oui. Il est fourni avec le client Apidog standard. Téléchargez Apidog, puis ouvrez le panneau latéral dans une version récente du client.

Fonctionne-t-il avec des agents écrits dans n'importe quel framework ?

Oui, tant que l'agent expose une Carte d'Agent A2A valide. Le protocole est agnostique au framework. Des agents LangGraph, CrewAI, AutoGen, Python ou Go personnalisés peuvent donc être testés s'ils respectent la spécification A2A.

Puis-je enregistrer les sessions pour les rejouer plus tard ?

Les sessions persistent tant que le débogueur est ouvert. Pour une conservation longue durée, copiez la sortie Données brutes et enregistrez-la dans vos artefacts de test. L'exportation complète des sessions est prévue sur la feuille de route.

Comment le débogueur gère-t-il les réponses en streaming ?

Lorsque l'agent prend en charge le streaming SSE selon la spécification A2A, le débogueur lit les morceaux au fur et à mesure de leur arrivée et met à jour les vues Aperçu et Contenu en temps réel. Les Données brutes affichent la réponse assemblée lorsque le flux se ferme.

Quelle est la différence entre les métadonnées et les en-têtes ?

Les en-têtes sont au niveau HTTP. Les métadonnées sont au niveau du message A2A.

Les en-têtes sont lus par la passerelle, le proxy ou le middleware.
Les métadonnées sont lues par le gestionnaire de tâche de l'agent.

Apidog enregistre-t-il les réponses de l'agent sur ses serveurs ?

Non. Apidog fonctionne comme un client local. Le trafic entre votre machine et l'agent ne transite pas par l'infrastructure Apidog.

Puis-je tester un agent hébergé sur un autre réseau ?

Oui, si le chemin réseau est ouvert. Le débogueur effectue des requêtes HTTPS sortantes comme un client HTTP classique. Si votre agent est derrière un VPN, activez ce VPN avant de tester.

Où signaler des bugs ou demander des fonctionnalités ?

Utilisez le canal de feedback d'Apidog pour les demandes liées au produit. Pour les sujets de spécification, le référentiel GitHub du protocole A2A est l'endroit où suivre l'évolution du protocole.

Essayez maintenant

Prenez l'agent A2A le plus simple auquel vous avez accès. Si vous n'en avez pas encore, les implémentations de référence A2A incluent un serveur d'exemple que vous pouvez exécuter localement en quelques minutes.

Ensuite :

lancez l'agent ;
ouvrez sa Carte d'Agent ;
copiez l'URL dans le Débogueur A2A d'Apidog ;
envoyez un message bonjour ;
inspectez les vues Aperçu, Contenu et Données brutes.

C'est la plus petite boucle A2A de bout en bout. Une fois cette boucle validée, ajoutez progressivement des prompts réels, des pièces jointes, des métadonnées et des workflows multi-agents.

Associez le Débogueur A2A à Apidog pour le reste de vos tests API et MCP, et vous obtenez une interface unique pour les trois couches utilisées par de nombreux systèmes d'agents : HTTP, MCP et A2A.