> ## Documentation Index
> Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Tests : suites en direct

Pour le démarrage rapide, les exécuteurs QA, les suites unitaires/d’intégration et les flux Docker, consultez
[Tests](/fr/help/testing). Cette page couvre les suites de tests **live** (qui touchent au réseau) :
matrice de modèles, backends CLI, ACP et tests live de fournisseurs de médias, ainsi que
la gestion des identifiants.

## Live : commandes smoke locales

Exportez la clé fournisseur requise dans l’environnement du processus avant les
vérifications live ponctuelles.

Smoke média sûr :

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
pnpm openclaw infer tts convert --local --json \
  --text "OpenClaw live smoke." \
  --output /tmp/openclaw-live-smoke.mp3
```

Smoke sûr de préparation aux appels vocaux :

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
pnpm openclaw voicecall setup --json
pnpm openclaw voicecall smoke --to "+15555550123"
```

`voicecall smoke` est un essai à blanc sauf si `--yes` est également présent. Utilisez `--yes` uniquement
lorsque vous voulez intentionnellement passer un véritable appel de notification. Pour Twilio, Telnyx et
Plivo, une vérification de préparation réussie nécessite une URL de Webhook publique ; les solutions de repli
locales uniquement en loopback/privées sont rejetées par conception.

## Live : balayage des capacités du nœud Android

* Test : `src/gateway/android-node.capabilities.live.test.ts`
* Script : `pnpm android:test:integration`
* Objectif : invoquer **chaque commande actuellement annoncée** par un nœud Android connecté et vérifier le comportement du contrat de commande.
* Portée :
  * Configuration préalable/manuelle (la suite n’installe, n’exécute ni n’appaire l’application).
  * Validation `node.invoke` Gateway commande par commande pour le nœud Android sélectionné.
* Préconfiguration requise :
  * Application Android déjà connectée et appairée au Gateway.
  * Application maintenue au premier plan.
  * Autorisations/consentement de capture accordés pour les capacités que vous vous attendez à voir réussir.
* Remplacements de cible facultatifs :
  * `OPENCLAW_ANDROID_NODE_ID` ou `OPENCLAW_ANDROID_NODE_NAME`.
  * `OPENCLAW_ANDROID_GATEWAY_URL` / `OPENCLAW_ANDROID_GATEWAY_TOKEN` / `OPENCLAW_ANDROID_GATEWAY_PASSWORD`.
* Détails complets de configuration Android : [Application Android](/fr/platforms/android)

## Live : smoke des modèles (clés de profil)

Les tests live sont divisés en deux couches afin d’isoler les défaillances :

* « Modèle direct » nous indique que le fournisseur/modèle peut tout simplement répondre avec la clé donnée.
* « Gateway smoke » nous indique que le pipeline complet gateway+agent fonctionne pour ce modèle (sessions, historique, outils, stratégie de sandbox, etc.).

### Couche 1 : complétion directe de modèle (sans gateway)

* Test : `src/agents/models.profiles.live.test.ts`
* Objectif :
  * Énumérer les modèles découverts
  * Utiliser `getApiKeyForModel` pour sélectionner les modèles pour lesquels vous avez des identifiants
  * Exécuter une petite complétion par modèle (et des régressions ciblées si nécessaire)
* Activation :
  * `pnpm test:live` (ou `OPENCLAW_LIVE_TEST=1` si vous invoquez Vitest directement)
* Définissez `OPENCLAW_LIVE_MODELS=modern`, `small` ou `all` (alias de modern) pour réellement exécuter cette suite ; sinon elle est ignorée afin de garder `pnpm test:live` concentré sur le smoke gateway
* Sélection des modèles :
  * `OPENCLAW_LIVE_MODELS=modern` pour exécuter la liste d’autorisation moderne (Opus/Sonnet 4.6+, GPT-5.2 + Codex, Gemini 3, DeepSeek V4, GLM 5.1, MiniMax M3, Grok 4.3)
  * `OPENCLAW_LIVE_MODELS=small` pour exécuter la liste d’autorisation contrainte de petits modèles (routes Qwen 8B/9B compatibles locales, Ollama Gemma, OpenRouter Qwen/GLM et Z.AI GLM)
  * `OPENCLAW_LIVE_MODELS=all` est un alias de la liste d’autorisation moderne
  * ou `OPENCLAW_LIVE_MODELS="openai/gpt-5.5,anthropic/claude-opus-4-6,..."` (liste d’autorisation séparée par des virgules)
  * Les exécutions locales de petits modèles Ollama utilisent par défaut `http://127.0.0.1:11434` ; définissez `OPENCLAW_LIVE_OLLAMA_BASE_URL` uniquement pour les points de terminaison LAN, personnalisés ou Ollama Cloud.
  * Les balayages modern/all et small utilisent par défaut leurs plafonds organisés ; définissez `OPENCLAW_LIVE_MAX_MODELS=0` pour un balayage exhaustif des profils sélectionnés ou un nombre positif pour un plafond plus petit.
  * Les balayages exhaustifs utilisent `OPENCLAW_LIVE_TEST_TIMEOUT_MS` comme délai d’expiration pour l’ensemble du test de modèle direct. Valeur par défaut : 60 minutes.
  * Les sondes de modèle direct s’exécutent par défaut avec un parallélisme de 20 ; définissez `OPENCLAW_LIVE_MODEL_CONCURRENCY` pour le remplacer.
* Sélection des fournisseurs :
  * `OPENCLAW_LIVE_PROVIDERS="google,google-antigravity,google-gemini-cli"` (liste d’autorisation séparée par des virgules)
* Origine des clés :
  * Par défaut : magasin de profils et solutions de repli env
  * Définissez `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour imposer le **magasin de profils** uniquement
* Raison d’être :
  * Sépare « l’API fournisseur est cassée / la clé est invalide » de « le pipeline d’agent gateway est cassé »
  * Contient de petites régressions isolées (exemple : rejeu de raisonnement OpenAI Responses/Codex Responses + flux d’appels d’outils)

### Couche 2 : Gateway + smoke de l’agent dev (ce que fait réellement « @openclaw »)

* Test : `src/gateway/gateway-models.profiles.live.test.ts`
* Objectif :
  * Démarrer un gateway dans le processus
  * Créer/corriger une session `agent:dev:*` (remplacement du modèle par exécution)
  * Parcourir les modèles disposant de clés et vérifier :
    * réponse « significative » (sans outils)
    * une invocation réelle d’outil fonctionne (sonde de lecture)
    * sondes d’outils supplémentaires facultatives (sonde exec+lecture)
    * les chemins de régression OpenAI (appel d’outil uniquement → suivi) continuent de fonctionner
* Détails des sondes (pour expliquer rapidement les échecs) :
  * sonde `read` : le test écrit un fichier nonce dans l’espace de travail et demande à l’agent de le `read` puis de renvoyer le nonce.
  * sonde `exec+read` : le test demande à l’agent d’écrire avec `exec` un nonce dans un fichier temporaire, puis de le relire avec `read`.
  * sonde image : le test joint un PNG généré (chat + code aléatoire) et s’attend à ce que le modèle renvoie `cat <CODE>`.
  * Référence d’implémentation : `src/gateway/gateway-models.profiles.live.test.ts` et `test/helpers/live-image-probe.ts`.
* Activation :
  * `pnpm test:live` (ou `OPENCLAW_LIVE_TEST=1` si vous invoquez Vitest directement)
* Sélection des modèles :
  * Par défaut : liste d’autorisation moderne (Opus/Sonnet 4.6+, GPT-5.2 + Codex, Gemini 3, DeepSeek V4, GLM 4.7, MiniMax M3, Grok 4.3)
  * `OPENCLAW_LIVE_GATEWAY_MODELS=small` pour exécuter la même liste d’autorisation contrainte de petits modèles via le pipeline complet gateway+agent
  * `OPENCLAW_LIVE_GATEWAY_MODELS=all` est un alias de la liste d’autorisation moderne
  * Ou définissez `OPENCLAW_LIVE_GATEWAY_MODELS="provider/model"` (ou une liste séparée par des virgules) pour restreindre
  * Les balayages gateway modern/all et small utilisent par défaut leurs plafonds organisés ; définissez `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0` pour un balayage sélectionné exhaustif ou un nombre positif pour un plafond plus petit.
* Sélection des fournisseurs (éviter « tout OpenRouter ») :
  * `OPENCLAW_LIVE_GATEWAY_PROVIDERS="google,google-antigravity,google-gemini-cli,openai,anthropic,zai,minimax"` (liste d’autorisation séparée par des virgules)
* Les sondes d’outil + image sont toujours activées dans ce test live :
  * sonde `read` + sonde `exec+read` (stress des outils)
  * la sonde image s’exécute lorsque le modèle annonce la prise en charge de l’entrée image
  * Flux (vue d’ensemble) :
    * Le test génère un petit PNG avec « CAT » + code aléatoire (`test/helpers/live-image-probe.ts`)
    * L’envoie via `agent` `attachments: [{ mimeType: "image/png", content: "<base64>" }]`
    * Gateway analyse les pièces jointes en `images[]` (`src/gateway/server-methods/agent.ts` + `src/gateway/chat-attachments.ts`)
    * L’agent embarqué transmet un message utilisateur multimodal au modèle
    * Assertion : la réponse contient `cat` + le code (tolérance OCR : erreurs mineures autorisées)

<Tip>
  Pour voir ce que vous pouvez tester sur votre machine (et les identifiants `provider/model` exacts), exécutez :

  ```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
  openclaw models list
  openclaw models list --json
  ```
</Tip>

## Live : smoke de backend CLI (Claude, Gemini ou autres CLI locales)

* Test : `src/gateway/gateway-cli-backend.live.test.ts`
* Objectif : valider le pipeline Gateway + agent à l’aide d’un backend CLI local, sans toucher à votre configuration par défaut.
* Les valeurs par défaut de smoke propres au backend résident avec la définition `cli-backend.ts` de l’extension propriétaire.
* Activation :
  * `pnpm test:live` (ou `OPENCLAW_LIVE_TEST=1` si vous invoquez Vitest directement)
  * `OPENCLAW_LIVE_CLI_BACKEND=1`
* Valeurs par défaut :
  * Fournisseur/modèle par défaut : `claude-cli/claude-sonnet-4-6`
  * Le comportement commande/arguments/image provient des métadonnées du plugin de backend CLI propriétaire.
* Remplacements (facultatifs) :
  * `OPENCLAW_LIVE_CLI_BACKEND_MODEL="claude-cli/claude-sonnet-4-6"`
  * `OPENCLAW_LIVE_CLI_BACKEND_COMMAND="/full/path/to/claude"`
  * `OPENCLAW_LIVE_CLI_BACKEND_ARGS='["-p","--output-format","json"]'`
  * `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_PROBE=1` pour envoyer une vraie pièce jointe image (les chemins sont injectés dans le prompt). Les recettes Docker désactivent cela par défaut sauf demande explicite.
  * `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image"` pour passer les chemins de fichiers image comme arguments CLI au lieu d’une injection dans le prompt.
  * `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat"` (ou `"list"`) pour contrôler la manière dont les arguments d’image sont passés lorsque `IMAGE_ARG` est défini.
  * `OPENCLAW_LIVE_CLI_BACKEND_RESUME_PROBE=1` pour envoyer un second tour et valider le flux de reprise.
  * `OPENCLAW_LIVE_CLI_BACKEND_MODEL_SWITCH_PROBE=1` pour opter pour la sonde de continuité même session Claude Sonnet -> Opus lorsque le modèle sélectionné prend en charge une cible de bascule. Les recettes Docker la désactivent par défaut pour la fiabilité agrégée.
  * `OPENCLAW_LIVE_CLI_BACKEND_MCP_PROBE=1` pour opter pour la sonde MCP/outil loopback. Les recettes Docker la désactivent par défaut sauf demande explicite.

Exemple :

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
  OPENCLAW_LIVE_CLI_BACKEND=1 \
  OPENCLAW_LIVE_CLI_BACKEND_MODEL="claude-cli/claude-sonnet-4-6" \
  pnpm test:live src/gateway/gateway-cli-backend.live.test.ts
```

Smoke bon marché de configuration MCP Gemini :

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
OPENCLAW_LIVE_TEST=1 \
  pnpm test:live src/agents/cli-runner/bundle-mcp.gemini.live.test.ts
```

Cela ne demande pas à Gemini de générer une réponse. Il écrit les mêmes
paramètres système qu’OpenClaw fournit à Gemini, puis exécute `gemini --debug mcp list` pour prouver qu’un
serveur `transport: "streamable-http"` enregistré est normalisé vers la forme MCP HTTP de Gemini
et peut se connecter à un serveur MCP HTTP diffusable local.

Recette Docker :

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
pnpm test:docker:live-cli-backend
```

Recettes Docker à fournisseur unique :

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
pnpm test:docker:live-cli-backend:claude
pnpm test:docker:live-cli-backend:claude-subscription
pnpm test:docker:live-cli-backend:gemini
```

Notes :

* L’exécuteur Docker se trouve dans `scripts/test-live-cli-backend-docker.sh`.
* Il exécute le smoke live du backend CLI dans l’image Docker du dépôt en tant qu’utilisateur `node` non root.
* Il résout les métadonnées de smoke CLI depuis l’extension propriétaire, puis installe le paquet CLI Linux correspondant (`@anthropic-ai/claude-code` ou `@google/gemini-cli`) dans un préfixe accessible en écriture et mis en cache à `OPENCLAW_DOCKER_CLI_TOOLS_DIR` (par défaut : `~/.cache/openclaw/docker-cli-tools`).
* `pnpm test:docker:live-cli-backend:claude-subscription` nécessite OAuth portable d’abonnement Claude Code via soit `~/.claude/.credentials.json` avec `claudeAiOauth.subscriptionType`, soit `CLAUDE_CODE_OAUTH_TOKEN` depuis `claude setup-token`. Il prouve d’abord `claude -p` direct dans Docker, puis exécute deux tours de backend CLI Gateway sans conserver les variables d’environnement de clé API Anthropic. Cette voie d’abonnement désactive par défaut les sondes MCP/outil et image Claude, car elle consomme les limites d’utilisation de l’abonnement connecté et Anthropic peut modifier le comportement de facturation et de limitation de débit de Claude Agent SDK / `claude -p` sans publication OpenClaw.
* Le smoke live de backend CLI exerce désormais le même flux de bout en bout pour Claude et Gemini : tour texte, tour de classification d’image, puis appel d’outil MCP `cron` vérifié via la CLI gateway.
* Le smoke par défaut de Claude corrige également la session de Sonnet vers Opus et vérifie que la session reprise se souvient encore d’une note antérieure.

## Live : accessibilité du proxy HTTP/2 APNs

* Test : `src/infra/push-apns-http2.live.test.ts`
* Objectif : passer par un proxy HTTP CONNECT local vers le point de terminaison APNs sandbox d’Apple, envoyer la requête de validation HTTP/2 APNs et vérifier que la véritable réponse `403 InvalidProviderToken` d’Apple revient par le chemin du proxy.
* Activation :
  * `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_APNS_REACHABILITY=1 pnpm test:live src/infra/push-apns-http2.live.test.ts`
* Délai d’expiration facultatif :
  * `OPENCLAW_LIVE_APNS_TIMEOUT_MS=30000`

## Live : smoke de liaison ACP (`/acp spawn ... --bind here`)

* Test : `src/gateway/gateway-acp-bind.live.test.ts`
* Objectif : valider le flux réel de liaison de conversation ACP avec un agent ACP en direct :
  * envoyer `/acp spawn <agent> --bind here`
  * lier sur place une conversation synthétique de canal de messages
  * envoyer un suivi normal dans cette même conversation
  * vérifier que le suivi arrive dans la transcription de la session ACP liée
* Activer :
  * `pnpm test:live src/gateway/gateway-acp-bind.live.test.ts`
  * `OPENCLAW_LIVE_ACP_BIND=1`
* Valeurs par défaut :
  * Agents ACP dans Docker : `claude,codex,gemini`
  * Agent ACP pour `pnpm test:live ...` direct : `claude`
  * Canal synthétique : contexte de conversation de type DM Slack
  * Backend ACP : `acpx`
* Surcharges :
  * `OPENCLAW_LIVE_ACP_BIND_AGENT=claude`
  * `OPENCLAW_LIVE_ACP_BIND_AGENT=codex`
  * `OPENCLAW_LIVE_ACP_BIND_AGENT=droid`
  * `OPENCLAW_LIVE_ACP_BIND_AGENT=gemini`
  * `OPENCLAW_LIVE_ACP_BIND_AGENT=opencode`
  * `OPENCLAW_LIVE_ACP_BIND_AGENTS=claude,codex,gemini`
  * `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND='npx -y @agentclientprotocol/claude-agent-acp@<version>'`
  * `OPENCLAW_LIVE_ACP_BIND_CODEX_MODEL=gpt-5.5`
  * `OPENCLAW_LIVE_ACP_BIND_OPENCODE_MODEL=opencode/kimi-k2.6`
  * `OPENCLAW_LIVE_ACP_BIND_REQUIRE_TRANSCRIPT=1`
  * `OPENCLAW_LIVE_ACP_BIND_REQUIRE_CRON=1`
  * `OPENCLAW_LIVE_ACP_BIND_PARENT_MODEL=openai/gpt-5.5`
* Notes :
  * Cette voie utilise la surface Gateway `chat.send` avec des champs d’itinéraire d’origine synthétique réservés à l’administrateur, afin que les tests puissent attacher un contexte de canal de messages sans prétendre effectuer une livraison externe.
  * Lorsque `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND` n’est pas défini, le test utilise le registre d’agents intégré du Plugin `acpx` embarqué pour l’agent de harnais ACP sélectionné.
  * La création MCP Cron de session liée est effectuée au mieux par défaut, car les harnais ACP externes peuvent annuler les appels MCP après la réussite de la preuve de liaison/image ; définissez `OPENCLAW_LIVE_ACP_BIND_REQUIRE_CRON=1` pour rendre cette sonde Cron post-liaison stricte.

Exemple :

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
OPENCLAW_LIVE_ACP_BIND=1 \
  OPENCLAW_LIVE_ACP_BIND_AGENT=claude \
  pnpm test:live src/gateway/gateway-acp-bind.live.test.ts
```

Recette Docker :

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
pnpm test:docker:live-acp-bind
```

Recettes Docker à agent unique :

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
pnpm test:docker:live-acp-bind:claude
pnpm test:docker:live-acp-bind:codex
pnpm test:docker:live-acp-bind:droid
pnpm test:docker:live-acp-bind:gemini
pnpm test:docker:live-acp-bind:opencode
```

Notes Docker :

* Le lanceur Docker se trouve dans `scripts/test-live-acp-bind-docker.sh`.
* Par défaut, il exécute le smoke de liaison ACP contre les agents CLI en direct agrégés, dans l’ordre : `claude`, `codex`, puis `gemini`.
* Utilisez `OPENCLAW_LIVE_ACP_BIND_AGENTS=claude`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=codex`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=droid`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=gemini` ou `OPENCLAW_LIVE_ACP_BIND_AGENTS=opencode` pour restreindre la matrice.
* Il prépare le matériel d’authentification CLI correspondant dans le conteneur, puis installe le CLI en direct demandé (`@anthropic-ai/claude-code`, `@openai/codex`, Factory Droid via `https://app.factory.ai/cli`, `@google/gemini-cli` ou `opencode-ai`) s’il est absent. Le backend ACP lui-même est le package `acpx/runtime` embarqué provenant du Plugin officiel `acpx`.
* La variante Docker Droid prépare `~/.factory` pour les paramètres, transmet `FACTORY_API_KEY` et exige cette clé d’API, car l’authentification locale Factory OAuth/keyring n’est pas portable dans le conteneur. Elle utilise l’entrée de registre intégrée d’ACPX `droid exec --output-format acp`.
* La variante Docker OpenCode est une voie de régression stricte à agent unique. Elle écrit un modèle par défaut temporaire `OPENCODE_CONFIG_CONTENT` depuis `OPENCLAW_LIVE_ACP_BIND_OPENCODE_MODEL` (par défaut `opencode/kimi-k2.6`), et `pnpm test:docker:live-acp-bind:opencode` exige une transcription d’assistant liée au lieu d’accepter le saut post-liaison générique.
* Les appels CLI `acpx` directs ne sont qu’un chemin manuel/de contournement pour comparer le comportement en dehors du Gateway. Le smoke Docker de liaison ACP exerce le backend d’exécution `acpx` embarqué d’OpenClaw.

## En direct : smoke du harnais app-server Codex

* Objectif : valider le harnais Codex détenu par le Plugin via la méthode Gateway
  `agent` normale :
  * charger le Plugin `codex` groupé
  * sélectionner `openai/gpt-5.5`, qui achemine par défaut les tours d’agent OpenAI via Codex
  * envoyer un premier tour d’agent Gateway vers `openai/gpt-5.5` avec le harnais Codex sélectionné
  * envoyer un second tour à la même session OpenClaw et vérifier que le thread
    app-server peut reprendre
  * exécuter `/codex status` et `/codex models` via le même chemin de commande
    Gateway
  * exécuter éventuellement deux sondes shell avec élévation examinées par Guardian : une commande
    bénigne qui doit être approuvée et un faux téléversement de secret qui doit être
    refusé afin que l’agent redemande
* Test : `src/gateway/gateway-codex-harness.live.test.ts`
* Activer : `OPENCLAW_LIVE_CODEX_HARNESS=1`
* Modèle par défaut : `openai/gpt-5.5`
* Sonde d’image facultative : `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=1`
* Sonde MCP/outil facultative : `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=1`
* Sonde Guardian facultative : `OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=1`
* Le smoke force le fournisseur/modèle `agentRuntime.id: "codex"` afin qu’un harnais Codex
  cassé ne puisse pas réussir en retombant silencieusement sur OpenClaw.
* Authentification : authentification app-server Codex depuis la connexion à l’abonnement Codex local. Les smokes Docker
  peuvent aussi fournir `OPENAI_API_KEY` pour les sondes non-Codex le cas échéant,
  ainsi que les fichiers copiés facultatifs `~/.codex/auth.json` et `~/.codex/config.toml`.

Recette locale :

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
OPENCLAW_LIVE_CODEX_HARNESS=1 \
  OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=1 \
  OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=1 \
  OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=1 \
  OPENCLAW_LIVE_CODEX_HARNESS_MODEL=openai/gpt-5.5 \
  pnpm test:live -- src/gateway/gateway-codex-harness.live.test.ts
```

Recette Docker :

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
pnpm test:docker:live-codex-harness
```

Notes Docker :

* Le lanceur Docker se trouve dans `scripts/test-live-codex-harness-docker.sh`.
* Il transmet `OPENAI_API_KEY`, copie les fichiers d’authentification CLI Codex lorsqu’ils sont présents, installe
  `@openai/codex` dans un préfixe npm monté accessible en écriture,
  prépare l’arborescence source, puis exécute uniquement le test en direct du harnais Codex.
* Docker active par défaut les sondes image, MCP/outil et Guardian. Définissez
  `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0` ou
  `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0` ou
  `OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=0` lorsque vous avez besoin d’une exécution de débogage
  plus restreinte.
* Docker utilise la même configuration d’exécution Codex explicite ; les alias hérités ou le
  repli OpenClaw ne peuvent donc pas masquer une régression du harnais Codex.

### Recettes en direct recommandées

Les listes d’autorisation étroites et explicites sont les plus rapides et les moins instables :

* Modèle unique, direct (sans Gateway) :
  * `OPENCLAW_LIVE_MODELS="openai/gpt-5.5" pnpm test:live src/agents/models.profiles.live.test.ts`

* Profil direct petit modèle :
  * `OPENCLAW_LIVE_MODELS=small pnpm test:live src/agents/models.profiles.live.test.ts`

* Profil Gateway petit modèle :
  * `OPENCLAW_LIVE_GATEWAY_MODELS=small pnpm test:live src/gateway/gateway-models.profiles.live.test.ts`

* Smoke API Ollama Cloud :
  * `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_OLLAMA=1 OPENCLAW_LIVE_OLLAMA_BASE_URL=https://ollama.com OPENCLAW_LIVE_OLLAMA_MODEL=glm-5.1:cloud OPENCLAW_LIVE_OLLAMA_WEB_SEARCH=0 pnpm test:live -- extensions/ollama/ollama.live.test.ts`

* Modèle unique, smoke Gateway :
  * `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.5" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts`

* Appel d’outils sur plusieurs fournisseurs :
  * `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.5,anthropic/claude-opus-4-6,google/gemini-3-flash-preview,deepseek/deepseek-v4-flash,zai/glm-5.1,minimax/MiniMax-M3" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts`

* Smoke direct Z.AI Coding Plan GLM-5.2 :
  * `ZAI_CODING_LIVE_TEST=1 pnpm test:live src/agents/zai.live.test.ts`

* Ciblage Google (clé API Gemini + Antigravity) :
  * Gemini (clé API) : `OPENCLAW_LIVE_GATEWAY_MODELS="google/gemini-3-flash-preview" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts`
  * Antigravity (OAuth) : `OPENCLAW_LIVE_GATEWAY_MODELS="google-antigravity/claude-opus-4-6-thinking,google-antigravity/gemini-3-pro-high" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts`

* Smoke de raisonnement adaptatif Google :
  * Valeur par défaut dynamique Gemini 3 : `pnpm openclaw qa manual --provider-mode live-frontier --model google/gemini-3.1-pro-preview --alt-model google/gemini-3.1-pro-preview --message '/think adaptive Reply exactly: GEMINI_ADAPTIVE_OK' --timeout-ms 180000`
  * Budget dynamique Gemini 2.5 : `pnpm openclaw qa manual --provider-mode live-frontier --model google/gemini-2.5-flash --alt-model google/gemini-2.5-flash --message '/think adaptive Reply exactly: GEMINI25_ADAPTIVE_OK' --timeout-ms 180000`

Notes :

* `google/...` utilise l’API Gemini (clé API).
* `google-antigravity/...` utilise le pont OAuth Antigravity (point de terminaison d’agent de style Cloud Code Assist).
* `google-gemini-cli/...` utilise le CLI Gemini local sur votre machine (authentification séparée + particularités d’outillage).
* API Gemini vs CLI Gemini :
  * API : OpenClaw appelle l’API Gemini hébergée par Google via HTTP (clé API / authentification de profil) ; c’est ce que la plupart des utilisateurs entendent par « Gemini ».
  * CLI : OpenClaw appelle un binaire local `gemini` via le shell ; il possède sa propre authentification et peut se comporter différemment (prise en charge du streaming/des outils/décalage de version).

## En direct : matrice de modèles (ce que nous couvrons)

Il n’existe pas de « liste de modèles CI » fixe (le direct est à activation explicite), mais voici les modèles **recommandés** à couvrir régulièrement sur une machine de développement avec des clés.

### Ensemble de smoke moderne (appel d’outils + image)

Voici l’exécution des « modèles courants » que nous nous attendons à maintenir fonctionnelle :

* OpenAI (non-Codex) : `openai/gpt-5.5`
* OpenAI ChatGPT/Codex OAuth : `openai/gpt-5.5`
* Anthropic : `anthropic/claude-opus-4-6` (ou `anthropic/claude-sonnet-4-6`)
* Google (API Gemini) : `google/gemini-3.1-pro-preview` et `google/gemini-3-flash-preview` (éviter les anciens modèles Gemini 2.x)
* Google (Antigravity) : `google-antigravity/claude-opus-4-6-thinking` et `google-antigravity/gemini-3-flash`
* DeepSeek : `deepseek/deepseek-v4-flash` et `deepseek/deepseek-v4-pro`
* Z.AI (GLM) : `zai/glm-5.1` (API générale) ou `zai/glm-5.2` (Coding Plan)
* MiniMax : `minimax/MiniMax-M3`

Exécuter le smoke Gateway avec outils + image :
`OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.5,anthropic/claude-opus-4-6,google/gemini-3.1-pro-preview,google/gemini-3-flash-preview,google-antigravity/claude-opus-4-6-thinking,google-antigravity/gemini-3-flash,deepseek/deepseek-v4-flash,zai/glm-5.1,minimax/MiniMax-M3" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts`

### Référence : appel d’outils (Read + Exec facultatif)

Choisissez au moins un modèle par famille de fournisseurs :

* OpenAI : `openai/gpt-5.5`
* Anthropic : `anthropic/claude-opus-4-6` (ou `anthropic/claude-sonnet-4-6`)
* Google : `google/gemini-3-flash-preview` (ou `google/gemini-3.1-pro-preview`)
* DeepSeek : `deepseek/deepseek-v4-flash`
* Z.AI (GLM) : `zai/glm-5.1` (API générale) ou `zai/glm-5.2` (Coding Plan)
* MiniMax : `minimax/MiniMax-M3`

Couverture supplémentaire facultative (utile à avoir) :

* xAI : `xai/grok-4.3` (ou le dernier disponible)
* Mistral : `mistral/`… (choisissez un modèle compatible « outils » que vous avez activé)
* Cerebras : `cerebras/`… (si vous y avez accès)
* LM Studio : `lmstudio/`… (local ; l’appel d’outils dépend du mode API)

### Vision : envoi d’image (pièce jointe → message multimodal)

Incluez au moins un modèle compatible image dans `OPENCLAW_LIVE_GATEWAY_MODELS` (variantes Claude/Gemini/OpenAI compatibles vision, etc.) pour exercer la sonde d’image.

### Agrégateurs / passerelles alternatives

Si vous avez des clés activées, nous prenons également en charge les tests via :

* OpenRouter : `openrouter/...` (des centaines de modèles ; utilisez `openclaw models scan` pour trouver des candidats compatibles outils+image)
* OpenCode : `opencode/...` pour Zen et `opencode-go/...` pour Go (authentification via `OPENCODE_API_KEY` / `OPENCODE_ZEN_API_KEY`)

Autres fournisseurs que vous pouvez inclure dans la matrice en direct (si vous avez les identifiants/la configuration) :

* Intégré : `openai`, `anthropic`, `google`, `google-vertex`, `google-antigravity`, `google-gemini-cli`, `zai`, `openrouter`, `opencode`, `opencode-go`, `xai`, `groq`, `cerebras`, `mistral`, `github-copilot`
* Via `models.providers` (points de terminaison personnalisés) : `minimax` (cloud/API), plus tout proxy compatible OpenAI/Anthropic (LM Studio, vLLM, LiteLLM, etc.)

<Tip>
  Ne codez pas en dur « tous les modèles » dans la documentation. La liste faisant autorité est celle que `discoverModels(...)` renvoie sur votre machine, plus les clés disponibles.
</Tip>

## Identifiants (ne jamais valider)

Les tests en direct découvrent les identifiants de la même façon que la CLI. Conséquences pratiques :

* Si la CLI fonctionne, les tests en direct devraient trouver les mêmes clés.

* Si un test en direct indique « aucun identifiant », déboguez comme vous débogueriez `openclaw models list` / la sélection de modèle.

* Profils d’authentification par agent : `~/.openclaw/agents/<agentId>/agent/auth-profiles.json` (c’est ce que « clés de profil » signifie dans les tests en direct)

* Configuration : `~/.openclaw/openclaw.json` (ou `OPENCLAW_CONFIG_PATH`)

* Répertoire d’état hérité : `~/.openclaw/credentials/` (copié dans le répertoire personnel de test en direct préparé lorsqu’il est présent, mais ce n’est pas le magasin principal des clés de profil)

* Les exécutions locales en direct copient par défaut la configuration active, les fichiers `auth-profiles.json` par agent, le répertoire `credentials/` hérité et les répertoires d’authentification de CLI externes pris en charge dans un répertoire personnel de test temporaire ; les répertoires personnels en direct préparés ignorent `workspace/` et `sandboxes/`, et les remplacements de chemins `agents.*.workspace` / `agentDir` sont supprimés afin que les sondes restent hors de votre véritable espace de travail hôte.

Si vous voulez vous appuyer sur des clés d’environnement, exportez-les avant les tests locaux ou utilisez les
exécuteurs Docker ci-dessous avec un `OPENCLAW_PROFILE_FILE` explicite.

## Deepgram en direct (transcription audio)

* Test : `extensions/deepgram/audio.live.test.ts`
* Activation : `DEEPGRAM_API_KEY=... DEEPGRAM_LIVE_TEST=1 pnpm test:live extensions/deepgram/audio.live.test.ts`

## Plan de codage BytePlus en direct

* Test : `extensions/byteplus/live.test.ts`
* Activation : `BYTEPLUS_API_KEY=... BYTEPLUS_LIVE_TEST=1 pnpm test:live extensions/byteplus/live.test.ts`
* Remplacement facultatif du modèle : `BYTEPLUS_CODING_MODEL=ark-code-latest`

## Médias de workflow ComfyUI en direct

* Test : `extensions/comfy/comfy.live.test.ts`
* Activation : `OPENCLAW_LIVE_TEST=1 COMFY_LIVE_TEST=1 pnpm test:live -- extensions/comfy/comfy.live.test.ts`
* Portée :
  * Exerce les chemins groupés comfy pour l’image, la vidéo et `music_generate`
  * Ignore chaque capacité sauf si `plugins.entries.comfy.config.<capability>` est configuré
  * Utile après des changements touchant la soumission de workflows comfy, l’interrogation, les téléchargements ou l’enregistrement du Plugin

## Génération d’images en direct

* Test : `test/image-generation.runtime.live.test.ts`
* Commande : `pnpm test:live test/image-generation.runtime.live.test.ts`
* Harnais : `pnpm test:live:media image`
* Portée :
  * Énumère chaque Plugin fournisseur de génération d’images enregistré
  * Utilise les variables d’environnement de fournisseur déjà exportées avant les sondes
  * Utilise par défaut les clés API en direct/d’environnement avant les profils d’authentification stockés, afin que des clés de test obsolètes dans `auth-profiles.json` ne masquent pas les véritables identifiants du shell
  * Ignore les fournisseurs sans authentification/profil/modèle utilisable
  * Exécute chaque fournisseur configuré via le runtime partagé de génération d’images :
    * `<provider>:generate`
    * `<provider>:edit` lorsque le fournisseur déclare la prise en charge de l’édition
* Fournisseurs groupés actuellement couverts :
  * `deepinfra`
  * `fal`
  * `google`
  * `minimax`
  * `openai`
  * `openrouter`
  * `vydra`
  * `xai`
* Restriction facultative :
  * `OPENCLAW_LIVE_IMAGE_GENERATION_PROVIDERS="openai,google,openrouter,xai"`
  * `OPENCLAW_LIVE_IMAGE_GENERATION_PROVIDERS="deepinfra"`
  * `OPENCLAW_LIVE_IMAGE_GENERATION_MODELS="openai/gpt-image-2,google/gemini-3.1-flash-image-preview,openrouter/google/gemini-3.1-flash-image-preview,xai/grok-imagine-image"`
  * `OPENCLAW_LIVE_IMAGE_GENERATION_CASES="google:flash-generate,google:pro-edit,openrouter:generate,xai:default-generate,xai:default-edit"`
* Comportement d’authentification facultatif :
  * `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour forcer l’authentification par magasin de profils et ignorer les remplacements uniquement par environnement

Pour le chemin CLI livré, ajoutez un smoke `infer` une fois que le test en direct du fournisseur/runtime
réussit :

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_INFER_CLI_TEST=1 pnpm test:live -- test/image-generation.infer-cli.live.test.ts
openclaw infer image providers --json
openclaw infer image generate \
  --model google/gemini-3.1-flash-image-preview \
  --prompt "Minimal flat test image: one blue square on a white background, no text." \
  --output ./openclaw-infer-image-smoke.png \
  --json
```

Cela couvre l’analyse des arguments de CLI, la résolution de la configuration/de l’agent par défaut, l’activation des
Plugins groupés, le runtime partagé de génération d’images et la requête du fournisseur en direct.
Les dépendances du Plugin doivent être présentes avant le chargement du runtime.

## Génération de musique en direct

* Test : `extensions/music-generation-providers.live.test.ts`
* Activation : `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/music-generation-providers.live.test.ts`
* Harnais : `pnpm test:live:media music`
* Portée :
  * Exerce le chemin partagé du fournisseur groupé de génération de musique
  * Couvre actuellement Google et MiniMax
  * Utilise les variables d’environnement de fournisseur déjà exportées avant les sondes
  * Utilise par défaut les clés API en direct/d’environnement avant les profils d’authentification stockés, afin que des clés de test obsolètes dans `auth-profiles.json` ne masquent pas les véritables identifiants du shell
  * Ignore les fournisseurs sans authentification/profil/modèle utilisable
  * Exécute les deux modes runtime déclarés lorsqu’ils sont disponibles :
    * `generate` avec une entrée contenant uniquement une invite
    * `edit` lorsque le fournisseur déclare `capabilities.edit.enabled`
  * Couverture actuelle de la voie partagée :
    * `google` : `generate`, `edit`
    * `minimax` : `generate`
    * `comfy` : fichier en direct Comfy séparé, pas ce balayage partagé
* Restriction facultative :
  * `OPENCLAW_LIVE_MUSIC_GENERATION_PROVIDERS="google,minimax"`
  * `OPENCLAW_LIVE_MUSIC_GENERATION_MODELS="google/lyria-3-clip-preview,minimax/music-2.6"`
* Comportement d’authentification facultatif :
  * `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour forcer l’authentification par magasin de profils et ignorer les remplacements uniquement par environnement

## Génération de vidéos en direct

* Test : `extensions/video-generation-providers.live.test.ts`
* Activation : `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/video-generation-providers.live.test.ts`
* Harnais : `pnpm test:live:media video`
* Portée :
  * Exerce le chemin partagé du fournisseur groupé de génération de vidéos
  * Utilise par défaut le chemin smoke sûr pour la version : fournisseurs non FAL, une requête texte-vers-vidéo par fournisseur, invite d’une seconde avec un homard et plafond d’opération par fournisseur provenant de `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS` (`180000` par défaut)
  * Ignore FAL par défaut, car la latence de la file d’attente côté fournisseur peut dominer le temps de publication ; passez `--video-providers fal` ou `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="fal"` pour l’exécuter explicitement
  * Utilise les variables d’environnement de fournisseur déjà exportées avant les sondes
  * Utilise par défaut les clés API en direct/d’environnement avant les profils d’authentification stockés, afin que des clés de test obsolètes dans `auth-profiles.json` ne masquent pas les véritables identifiants du shell
  * Ignore les fournisseurs sans authentification/profil/modèle utilisable
  * Exécute uniquement `generate` par défaut
  * Définissez `OPENCLAW_LIVE_VIDEO_GENERATION_FULL_MODES=1` pour exécuter aussi les modes de transformation déclarés lorsqu’ils sont disponibles :
    * `imageToVideo` lorsque le fournisseur déclare `capabilities.imageToVideo.enabled` et que le fournisseur/modèle sélectionné accepte une entrée d’image locale basée sur un tampon dans le balayage partagé
    * `videoToVideo` lorsque le fournisseur déclare `capabilities.videoToVideo.enabled` et que le fournisseur/modèle sélectionné accepte une entrée vidéo locale basée sur un tampon dans le balayage partagé
  * Fournisseurs `imageToVideo` actuellement déclarés mais ignorés dans le balayage partagé :
    * `vydra`, car `veo3` groupé est uniquement texte et `kling` groupé nécessite une URL d’image distante
  * Couverture Vydra spécifique au fournisseur :
    * `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_VYDRA_VIDEO=1 pnpm test:live -- extensions/vydra/vydra.live.test.ts`
    * ce fichier exécute `veo3` texte-vers-vidéo plus une voie `kling` qui utilise par défaut un dispositif de test avec URL d’image distante
  * Couverture en direct actuelle de `videoToVideo` :
    * `runway` uniquement lorsque le modèle sélectionné est `runway/gen4_aleph`
  * Fournisseurs `videoToVideo` actuellement déclarés mais ignorés dans le balayage partagé :
    * `alibaba`, `qwen`, `xai`, car ces chemins nécessitent actuellement des URL de référence distantes `http(s)` / MP4
    * `google`, car la voie Gemini/Veo partagée actuelle utilise une entrée locale basée sur un tampon, et ce chemin n’est pas accepté dans le balayage partagé
    * `openai`, car la voie partagée actuelle ne dispose pas de garanties d’accès à l’édition vidéo propres à l’organisation
* Restriction facultative :
  * `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="deepinfra,google,openai,runway"`
  * `OPENCLAW_LIVE_VIDEO_GENERATION_MODELS="google/veo-3.1-fast-generate-preview,openai/sora-2,runway/gen4_aleph"`
  * `OPENCLAW_LIVE_VIDEO_GENERATION_SKIP_PROVIDERS=""` pour inclure chaque fournisseur dans le balayage par défaut, y compris FAL
  * `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS=60000` pour réduire le plafond d’opération de chaque fournisseur lors d’une exécution smoke agressive
* Comportement d’authentification facultatif :
  * `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour forcer l’authentification par magasin de profils et ignorer les remplacements uniquement par environnement

## Harnais média en direct

* Commande : `pnpm test:live:media`
* Objectif :
  * Exécute les suites en direct partagées d’image, de musique et de vidéo via un point d’entrée natif au dépôt
  * Utilise les variables d’environnement de fournisseur déjà exportées
  * Restreint automatiquement chaque suite aux fournisseurs qui disposent actuellement d’une authentification utilisable par défaut
  * Réutilise `scripts/test-live.mjs`, afin que le comportement de Heartbeat et du mode silencieux reste cohérent
* Exemples :
  * `pnpm test:live:media`
  * `pnpm test:live:media image video --providers openai,google,minimax`
  * `pnpm test:live:media video --video-providers openai,runway --all-providers`
  * `pnpm test:live:media music --quiet`

## Connexe

* [Tests](/fr/help/testing) - suites unitaires, d’intégration, QA et Docker