diff --git a/docs/fr/channels/telegram.md b/docs/fr/channels/telegram.md index fa345a7dd..201e070a5 100644 --- a/docs/fr/channels/telegram.md +++ b/docs/fr/channels/telegram.md @@ -1,30 +1,30 @@ --- read_when: - - Travailler sur des fonctionnalités Telegram ou des webhooks -summary: Statut de la prise en charge du bot Telegram, capacités et configuration + - Travail sur les fonctionnalités Telegram ou les Webhooks +summary: Statut de prise en charge du bot Telegram, capacités et configuration title: Telegram x-i18n: - generated_at: "2026-04-05T12:38:30Z" + generated_at: "2026-04-20T07:05:24Z" model: gpt-5.4 provider: openai - source_hash: 39fbf328375fbc5d08ec2e3eed58b19ee0afa102010ecbc02e074a310ced157e + source_hash: b9903fae98bca0c345aa86d5c29015539c375442524a34d26bd28181470b8477 source_path: channels/telegram.md workflow: 15 --- -# Telegram (Bot API) +# Telegram (API Bot) -Statut : prêt pour la production pour les DM de bot + les groupes via grammY. Le long polling est le mode par défaut ; le mode webhook est facultatif. +Statut : prêt pour la production pour les DM de bot + groupes via grammY. Le long polling est le mode par défaut ; le mode Webhook est facultatif. - + La politique DM par défaut pour Telegram est l’appairage. - + Diagnostics inter-canaux et guides de réparation. - - Modèles de configuration complets des canaux et exemples. + + Modèles complets de configuration des canaux et exemples. @@ -32,7 +32,7 @@ Statut : prêt pour la production pour les DM de bot + les groupes via grammY. L - Ouvrez Telegram et discutez avec **@BotFather** (vérifiez que le handle est exactement `@BotFather`). + Ouvrez Telegram et discutez avec **@BotFather** (vérifiez que le pseudonyme est exactement `@BotFather`). Exécutez `/newbot`, suivez les invites et enregistrez le jeton. @@ -53,12 +53,12 @@ Statut : prêt pour la production pour les DM de bot + les groupes via grammY. L } ``` - Variable d’environnement de repli : `TELEGRAM_BOT_TOKEN=...` (compte par défaut uniquement). - Telegram n’utilise **pas** `openclaw channels login telegram` ; configurez le jeton dans la config/l’environnement, puis démarrez gateway. + Repli via variable d’environnement : `TELEGRAM_BOT_TOKEN=...` (compte par défaut uniquement). + Telegram n’utilise **pas** `openclaw channels login telegram` ; configurez le jeton dans la config/l’environnement, puis démarrez Gateway. - + ```bash openclaw gateway @@ -71,30 +71,30 @@ openclaw pairing approve telegram - Ajoutez le bot à votre groupe, puis définissez `channels.telegram.groups` et `groupPolicy` selon votre modèle d’accès. + Ajoutez le bot à votre groupe, puis définissez `channels.telegram.groups` et `groupPolicy` pour qu’ils correspondent à votre modèle d’accès. -L’ordre de résolution du jeton tient compte du compte. En pratique, les valeurs de config priment sur la variable d’environnement de repli, et `TELEGRAM_BOT_TOKEN` ne s’applique qu’au compte par défaut. +L’ordre de résolution du jeton tient compte du compte. En pratique, les valeurs de config priment sur le repli via l’environnement, et `TELEGRAM_BOT_TOKEN` s’applique uniquement au compte par défaut. ## Paramètres côté Telegram - - Les bots Telegram utilisent par défaut le **mode confidentialité**, ce qui limite les messages de groupe qu’ils reçoivent. + + Les bots Telegram sont en **mode confidentialité** par défaut, ce qui limite les messages de groupe qu’ils reçoivent. - Si le bot doit voir tous les messages du groupe, soit : + Si le bot doit voir tous les messages du groupe, vous pouvez soit : - - désactivez le mode confidentialité via `/setprivacy`, ou - - faites du bot un administrateur du groupe. + - désactiver le mode confidentialité via `/setprivacy`, ou + - faire du bot un administrateur du groupe. - Lorsque vous modifiez le mode confidentialité, supprimez puis réajoutez le bot dans chaque groupe afin que Telegram applique le changement. + Lors d’un changement du mode confidentialité, retirez puis rajoutez le bot dans chaque groupe afin que Telegram applique le changement. - + Le statut d’administrateur est contrôlé dans les paramètres du groupe Telegram. Les bots administrateurs reçoivent tous les messages du groupe, ce qui est utile pour un comportement de groupe toujours actif. @@ -113,7 +113,7 @@ L’ordre de résolution du jeton tient compte du compte. En pratique, les valeu - `channels.telegram.dmPolicy` contrôle l’accès aux messages directs : + `channels.telegram.dmPolicy` contrôle l’accès par message direct : - `pairing` (par défaut) - `allowlist` (nécessite au moins un ID d’expéditeur dans `allowFrom`) @@ -122,14 +122,14 @@ L’ordre de résolution du jeton tient compte du compte. En pratique, les valeu `channels.telegram.allowFrom` accepte des ID utilisateur Telegram numériques. Les préfixes `telegram:` / `tg:` sont acceptés et normalisés. `dmPolicy: "allowlist"` avec un `allowFrom` vide bloque tous les DM et est rejeté par la validation de configuration. - L’onboarding accepte une entrée `@username` et la résout en ID numériques. + La configuration demande uniquement des ID utilisateur numériques. Si vous avez effectué une mise à niveau et que votre configuration contient des entrées de liste d’autorisation `@username`, exécutez `openclaw doctor --fix` pour les résoudre (au mieux ; nécessite un jeton de bot Telegram). - Si vous vous appuyiez auparavant sur les fichiers de liste d’autorisation du magasin d’appairage, `openclaw doctor --fix` peut récupérer des entrées dans `channels.telegram.allowFrom` dans les flux de liste d’autorisation (par exemple lorsque `dmPolicy: "allowlist"` n’a pas encore d’ID explicites). + Si vous vous appuyiez auparavant sur des fichiers de liste d’autorisation du magasin d’appairage, `openclaw doctor --fix` peut récupérer les entrées dans `channels.telegram.allowFrom` dans les flux allowlist (par exemple lorsque `dmPolicy: "allowlist"` n’a encore aucun ID explicite). Pour les bots à propriétaire unique, préférez `dmPolicy: "allowlist"` avec des ID numériques explicites dans `allowFrom` afin de conserver une politique d’accès durable dans la configuration (au lieu de dépendre d’approbations d’appairage précédentes). - Confusion courante : l’approbation d’un appairage DM ne signifie pas « cet expéditeur est autorisé partout ». - L’appairage n’accorde qu’un accès DM. L’autorisation des expéditeurs dans les groupes provient toujours de listes d’autorisation explicites dans la configuration. + Confusion fréquente : l’approbation de l’appairage DM ne signifie pas « cet expéditeur est autorisé partout ». + L’appairage accorde un accès DM uniquement. L’autorisation des expéditeurs dans les groupes provient toujours de listes d’autorisation explicites dans la configuration. Si vous voulez « je suis autorisé une fois et les DM ainsi que les commandes de groupe fonctionnent », placez votre ID utilisateur Telegram numérique dans `channels.telegram.allowFrom`. ### Trouver votre ID utilisateur Telegram @@ -140,7 +140,7 @@ L’ordre de résolution du jeton tient compte du compte. En pratique, les valeu 2. Exécutez `openclaw logs --follow`. 3. Lisez `from.id`. - Méthode officielle Bot API : + Méthode officielle de l’API Bot : ```bash curl "https://api.telegram.org/bot/getUpdates" @@ -154,7 +154,7 @@ curl "https://api.telegram.org/bot/getUpdates" Deux contrôles s’appliquent ensemble : 1. **Quels groupes sont autorisés** (`channels.telegram.groups`) - - pas de configuration `groups` : + - aucune configuration `groups` : - avec `groupPolicy: "open"` : n’importe quel groupe peut passer les vérifications d’ID de groupe - avec `groupPolicy: "allowlist"` (par défaut) : les groupes sont bloqués jusqu’à ce que vous ajoutiez des entrées `groups` (ou `"*"`) - `groups` configuré : agit comme une liste d’autorisation (ID explicites ou `"*"`) @@ -164,15 +164,15 @@ curl "https://api.telegram.org/bot/getUpdates" - `allowlist` (par défaut) - `disabled` - `groupAllowFrom` est utilisé pour filtrer les expéditeurs de groupe. S’il n’est pas défini, Telegram retombe sur `allowFrom`. + `groupAllowFrom` est utilisé pour filtrer les expéditeurs dans les groupes. S’il n’est pas défini, Telegram se rabat sur `allowFrom`. Les entrées `groupAllowFrom` doivent être des ID utilisateur Telegram numériques (les préfixes `telegram:` / `tg:` sont normalisés). - Ne placez pas d’ID de chat de groupe ou de supergroupe Telegram dans `groupAllowFrom`. Les ID de chat négatifs doivent être placés sous `channels.telegram.groups`. - Les entrées non numériques sont ignorées pour l’autorisation de l’expéditeur. - Frontière de sécurité (`2026.2.25+`) : l’authentification des expéditeurs de groupe **n’hérite pas** des approbations du magasin d’appairage DM. + Ne mettez pas d’ID de chat de groupe ou de supergroupe Telegram dans `groupAllowFrom`. Les ID de chat négatifs doivent être placés sous `channels.telegram.groups`. + Les entrées non numériques sont ignorées pour l’autorisation des expéditeurs. + Limite de sécurité (`2026.2.25+`) : l’autorisation des expéditeurs dans les groupes n’hérite **pas** des approbations du magasin d’appairage DM. L’appairage reste réservé aux DM. Pour les groupes, définissez `groupAllowFrom` ou `allowFrom` par groupe/par sujet. - Si `groupAllowFrom` n’est pas défini, Telegram retombe sur `allowFrom` de la configuration, et non sur le magasin d’appairage. + Si `groupAllowFrom` n’est pas défini, Telegram se rabat sur `allowFrom` de la configuration, et non sur le magasin d’appairage. Modèle pratique pour les bots à propriétaire unique : définissez votre ID utilisateur dans `channels.telegram.allowFrom`, laissez `groupAllowFrom` non défini et autorisez les groupes cibles sous `channels.telegram.groups`. - Note du runtime : si `channels.telegram` est totalement absent, le runtime utilise par défaut `groupPolicy="allowlist"` en mode fail-closed, sauf si `channels.defaults.groupPolicy` est explicitement défini. + Note d’exécution : si `channels.telegram` est complètement absent, les valeurs d’exécution se replient par défaut sur `groupPolicy="allowlist"` en mode fermé, sauf si `channels.defaults.groupPolicy` est explicitement défini. Exemple : autoriser n’importe quel membre dans un groupe spécifique : @@ -209,17 +209,17 @@ curl "https://api.telegram.org/bot/getUpdates" ``` - Erreur courante : `groupAllowFrom` n’est pas une liste d’autorisation de groupes Telegram. + Erreur fréquente : `groupAllowFrom` n’est pas une liste d’autorisation de groupes Telegram. - - Placez les ID négatifs de groupe ou de supergroupe Telegram comme `-1001234567890` sous `channels.telegram.groups`. - - Placez les ID utilisateur Telegram comme `8734062810` sous `groupAllowFrom` lorsque vous voulez limiter les personnes à l’intérieur d’un groupe autorisé pouvant déclencher le bot. + - Placez les ID négatifs de groupes ou de supergroupes Telegram comme `-1001234567890` sous `channels.telegram.groups`. + - Placez les ID utilisateur Telegram comme `8734062810` sous `groupAllowFrom` lorsque vous voulez limiter quelles personnes dans un groupe autorisé peuvent déclencher le bot. - Utilisez `groupAllowFrom: ["*"]` uniquement lorsque vous voulez que n’importe quel membre d’un groupe autorisé puisse parler au bot. - Les réponses de groupe exigent une mention par défaut. + Les réponses dans les groupes nécessitent une mention par défaut. La mention peut provenir de : @@ -228,7 +228,7 @@ curl "https://api.telegram.org/bot/getUpdates" - `agents.list[].groupChat.mentionPatterns` - `messages.groupChat.mentionPatterns` - Commandes de bascule au niveau de la session : + Options de commande au niveau de la session : - `/activation always` - `/activation mention` @@ -251,27 +251,27 @@ curl "https://api.telegram.org/bot/getUpdates" Obtenir l’ID du chat de groupe : - - transférez un message de groupe à `@userinfobot` / `@getidsbot` - - ou lisez `chat.id` depuis `openclaw logs --follow` - - ou inspectez `getUpdates` de Bot API + - transférez un message du groupe à `@userinfobot` / `@getidsbot` + - ou lisez `chat.id` dans `openclaw logs --follow` + - ou inspectez `getUpdates` de l’API Bot -## Comportement du runtime +## Comportement à l’exécution -- Telegram est géré par le processus gateway. -- Le routage est déterministe : les réponses entrantes Telegram reviennent vers Telegram (le modèle ne choisit pas les canaux). -- Les messages entrants sont normalisés dans l’enveloppe de canal partagée avec métadonnées de réponse et espaces réservés aux médias. -- Les sessions de groupe sont isolées par ID de groupe. Les sujets de forum ajoutent `:topic:` pour maintenir l’isolation des sujets. -- Les messages DM peuvent transporter `message_thread_id` ; OpenClaw les route avec des clés de session conscientes des fils et préserve l’ID du fil pour les réponses. -- Le long polling utilise le runner grammY avec séquencement par chat/par fil. La concurrence globale du runner sink utilise `agents.defaults.maxConcurrent`. -- Telegram Bot API ne prend pas en charge les accusés de lecture (`sendReadReceipts` ne s’applique pas). +- Telegram est géré par le processus Gateway. +- Le routage est déterministe : les réponses entrantes depuis Telegram repartent vers Telegram (le modèle ne choisit pas les canaux). +- Les messages entrants sont normalisés dans l’enveloppe de canal partagée avec métadonnées de réponse et espaces réservés pour les médias. +- Les sessions de groupe sont isolées par ID de groupe. Les sujets de forum ajoutent `:topic:` pour garder les sujets isolés. +- Les messages DM peuvent transporter `message_thread_id` ; OpenClaw les route avec des clés de session tenant compte des fils et préserve l’ID de fil pour les réponses. +- Le long polling utilise grammY runner avec séquencement par chat/par fil. La concurrence globale du sink du runner utilise `agents.defaults.maxConcurrent`. +- L’API Bot Telegram ne prend pas en charge les accusés de lecture (`sendReadReceipts` ne s’applique pas). ## Référence des fonctionnalités - + OpenClaw peut diffuser des réponses partielles en temps réel : - chats directs : message d’aperçu + `editMessageText` @@ -280,32 +280,32 @@ curl "https://api.telegram.org/bot/getUpdates" Exigence : - `channels.telegram.streaming` vaut `off | partial | block | progress` (par défaut : `partial`) - - `progress` correspond à `partial` sur Telegram (compatibilité avec la dénomination inter-canaux) - - les anciennes valeurs booléennes de `channels.telegram.streamMode` et `streaming` sont mappées automatiquement + - `progress` est mappé vers `partial` sur Telegram (compatibilité avec la dénomination inter-canaux) + - les anciennes valeurs booléennes `channels.telegram.streamMode` et `streaming` sont automatiquement mappées Pour les réponses texte uniquement : - DM : OpenClaw conserve le même message d’aperçu et effectue une modification finale sur place (pas de second message) - groupe/sujet : OpenClaw conserve le même message d’aperçu et effectue une modification finale sur place (pas de second message) - Pour les réponses complexes (par exemple les charges utiles média), OpenClaw retombe sur la livraison finale normale puis nettoie le message d’aperçu. + Pour les réponses complexes (par exemple les charges utiles média), OpenClaw se rabat sur une livraison finale normale puis nettoie le message d’aperçu. Le flux d’aperçu est distinct du flux par blocs. Lorsque le flux par blocs est explicitement activé pour Telegram, OpenClaw ignore le flux d’aperçu pour éviter un double flux. - Si le transport de brouillon natif n’est pas disponible/rejeté, OpenClaw retombe automatiquement sur `sendMessage` + `editMessageText`. + Si le transport de brouillon natif est indisponible/rejeté, OpenClaw se rabat automatiquement sur `sendMessage` + `editMessageText`. - Flux de raisonnement réservé à Telegram : + Flux de raisonnement propre à Telegram : - `/reasoning stream` envoie le raisonnement vers l’aperçu en direct pendant la génération - la réponse finale est envoyée sans le texte de raisonnement - - Le texte sortant utilise le `parse_mode: "HTML"` de Telegram. + + Le texte sortant utilise Telegram `parse_mode: "HTML"`. - Le texte de type Markdown est rendu en HTML sûr pour Telegram. - - Le HTML brut du modèle est échappé pour réduire les échecs d’analyse de Telegram. + - Le HTML brut du modèle est échappé pour réduire les échecs d’analyse Telegram. - Si Telegram rejette le HTML analysé, OpenClaw réessaie en texte brut. Les aperçus de liens sont activés par défaut et peuvent être désactivés avec `channels.telegram.linkPreview: false`. @@ -319,15 +319,15 @@ curl "https://api.telegram.org/bot/getUpdates" - `commands.native: "auto"` active les commandes natives pour Telegram - Ajouter des entrées de menu de commandes personnalisées : + Ajouter des entrées personnalisées au menu de commandes : ```json5 { channels: { telegram: { customCommands: [ - { command: "backup", description: "Git backup" }, - { command: "generate", description: "Create an image" }, + { command: "backup", description: "Sauvegarde Git" }, + { command: "generate", description: "Créer une image" }, ], }, }, @@ -341,40 +341,40 @@ curl "https://api.telegram.org/bot/getUpdates" - les commandes personnalisées ne peuvent pas remplacer les commandes natives - les conflits/doublons sont ignorés et journalisés - Notes : + Remarques : - - les commandes personnalisées sont uniquement des entrées de menu ; elles n’implémentent pas automatiquement un comportement - - les commandes de plugin/Skills peuvent toujours fonctionner lorsqu’elles sont saisies, même si elles ne sont pas affichées dans le menu Telegram + - les commandes personnalisées sont uniquement des entrées de menu ; elles n’implémentent pas automatiquement de comportement + - les commandes de Plugin/Skills peuvent toujours fonctionner lorsqu’elles sont saisies même si elles ne sont pas affichées dans le menu Telegram - Si les commandes natives sont désactivées, les commandes intégrées sont supprimées. Les commandes personnalisées/de plugin peuvent toujours être enregistrées si elles sont configurées. + Si les commandes natives sont désactivées, les commandes intégrées sont supprimées. Les commandes personnalisées/de Plugin peuvent tout de même s’enregistrer si elles sont configurées. - Échecs de configuration courants : + Échecs de configuration fréquents : - - `setMyCommands failed` avec `BOT_COMMANDS_TOO_MUCH` signifie que le menu Telegram déborde toujours après réduction ; réduisez les commandes personnalisées/de plugin/de Skills ou désactivez `channels.telegram.commands.native`. + - `setMyCommands failed` avec `BOT_COMMANDS_TOO_MUCH` signifie que le menu Telegram débordait encore après réduction ; réduisez les commandes de Plugin/Skills/personnalisées ou désactivez `channels.telegram.commands.native`. - `setMyCommands failed` avec des erreurs réseau/fetch signifie généralement que le DNS/HTTPS sortant vers `api.telegram.org` est bloqué. - ### Commandes d’appairage d’appareil (plugin `device-pair`) + ### Commandes d’appairage d’appareil (Plugin `device-pair`) - Lorsque le plugin `device-pair` est installé : + Lorsque le Plugin `device-pair` est installé : 1. `/pair` génère un code de configuration - 2. collez le code dans l’application iOS - 3. `/pair pending` liste les demandes en attente (y compris rôle/portées) + 2. collez le code dans l’app iOS + 3. `/pair pending` liste les demandes en attente (y compris le rôle/les scopes) 4. approuvez la demande : - `/pair approve ` pour une approbation explicite - `/pair approve` lorsqu’il n’y a qu’une seule demande en attente - `/pair approve latest` pour la plus récente - Le code de configuration transporte un jeton bootstrap de courte durée. Le transfert bootstrap intégré conserve le jeton de nœud principal à `scopes: []` ; tout jeton operator transmis reste limité à `operator.approvals`, `operator.read`, `operator.talk.secrets` et `operator.write`. Les vérifications de portée bootstrap sont préfixées par rôle, de sorte que cette liste d’autorisation operator ne satisfait que les demandes operator ; les rôles non-operator ont toujours besoin de portées sous leur propre préfixe de rôle. + Le code de configuration transporte un jeton d’amorçage de courte durée. Le transfert d’amorçage intégré conserve le jeton du Node principal avec `scopes: []` ; tout jeton opérateur transféré reste limité à `operator.approvals`, `operator.read`, `operator.talk.secrets` et `operator.write`. Les vérifications de scope d’amorçage sont préfixées par le rôle ; cette liste d’autorisation opérateur ne satisfait donc que les demandes opérateur ; les rôles non opérateur ont toujours besoin de scopes sous leur propre préfixe de rôle. - Si un appareil réessaie avec des détails d’authentification modifiés (par exemple rôle/portées/clé publique), la demande en attente précédente est remplacée et la nouvelle demande utilise un autre `requestId`. Réexécutez `/pair pending` avant d’approuver. + Si un appareil réessaie avec des détails d’authentification modifiés (par exemple rôle/scopes/clé publique), la demande en attente précédente est remplacée et la nouvelle demande utilise un `requestId` différent. Relancez `/pair pending` avant d’approuver. - Plus de détails : [Appairage](/channels/pairing#pair-via-telegram-recommended-for-ios). + Plus de détails : [Appairage](/fr/channels/pairing#pair-via-telegram-recommended-for-ios). - - Configurez la portée du clavier intégré : + + Configurez la portée du clavier en ligne : ```json5 { @@ -423,13 +423,13 @@ curl "https://api.telegram.org/bot/getUpdates" action: "send", channel: "telegram", to: "123456789", - message: "Choose an option:", + message: "Choisissez une option :", buttons: [ [ - { text: "Yes", callback_data: "yes" }, - { text: "No", callback_data: "no" }, + { text: "Oui", callback_data: "yes" }, + { text: "Non", callback_data: "no" }, ], - [{ text: "Cancel", callback_data: "cancel" }], + [{ text: "Annuler", callback_data: "cancel" }], ], } ``` @@ -448,24 +448,24 @@ curl "https://api.telegram.org/bot/getUpdates" - `editMessage` (`chatId`, `messageId`, `content`) - `createForumTopic` (`chatId`, `name`, `iconColor`, `iconCustomEmojiId` facultatifs) - Les actions de message de canal exposent des alias ergonomiques (`send`, `react`, `delete`, `edit`, `sticker`, `sticker-search`, `topic-create`). + Les actions de message du canal exposent des alias ergonomiques (`send`, `react`, `delete`, `edit`, `sticker`, `sticker-search`, `topic-create`). - Contrôles de restriction : + Contrôles de limitation : - `channels.telegram.actions.sendMessage` - `channels.telegram.actions.deleteMessage` - `channels.telegram.actions.reactions` - - `channels.telegram.actions.sticker` (par défaut : désactivé) + - `channels.telegram.actions.sticker` (désactivé par défaut) Remarque : `edit` et `topic-create` sont actuellement activés par défaut et n’ont pas de bascules `channels.telegram.actions.*` séparées. - Les envois runtime utilisent l’instantané actif de la configuration/des secrets (démarrage/rechargement), donc les chemins d’action n’effectuent pas de nouvelle résolution ad hoc de SecretRef à chaque envoi. + Les envois à l’exécution utilisent l’instantané actif de config/secrets (démarrage/rechargement), donc les chemins d’action n’effectuent pas de rerésolution ad hoc de `SecretRef` à chaque envoi. - Sémantique de suppression de réaction : [/tools/reactions](/tools/reactions) + Sémantique de suppression de réaction : [/tools/reactions](/fr/tools/reactions) - Telegram prend en charge des balises explicites de fil de réponse dans la sortie générée : + Telegram prend en charge les balises explicites de fil de réponse dans la sortie générée : - `[[reply_to_current]]` répond au message déclencheur - `[[reply_to:]]` répond à un ID de message Telegram spécifique @@ -476,7 +476,7 @@ curl "https://api.telegram.org/bot/getUpdates" - `first` - `all` - Remarque : `off` désactive le fil de réponse implicite. Les balises explicites `[[reply_to_*]]` sont toujours honorées. + Remarque : `off` désactive le fil de réponse implicite. Les balises explicites `[[reply_to_*]]` sont toujours respectées. @@ -484,7 +484,7 @@ curl "https://api.telegram.org/bot/getUpdates" Supergroupes de forum : - les clés de session de sujet ajoutent `:topic:` - - les réponses et les indicateurs de saisie ciblent le fil du sujet + - les réponses et indicateurs de saisie ciblent le fil du sujet - chemin de configuration du sujet : `channels.telegram.groups..topics.` @@ -494,9 +494,9 @@ curl "https://api.telegram.org/bot/getUpdates" - les actions de saisie incluent toujours `message_thread_id` Héritage des sujets : les entrées de sujet héritent des paramètres du groupe sauf remplacement (`requireMention`, `allowFrom`, `skills`, `systemPrompt`, `enabled`, `groupPolicy`). - `agentId` est réservé au sujet et n’hérite pas des valeurs par défaut du groupe. + `agentId` est propre au sujet et n’hérite pas des valeurs par défaut du groupe. - **Routage d’agent par sujet** : chaque sujet peut être routé vers un agent différent en définissant `agentId` dans la configuration du sujet. Cela donne à chaque sujet son propre espace de travail, sa propre mémoire et sa propre session. Exemple : + **Routage d’agent par sujet** : chaque sujet peut router vers un agent différent en définissant `agentId` dans la configuration du sujet. Cela donne à chaque sujet son propre espace de travail, sa propre mémoire et sa propre session. Exemple : ```json5 { @@ -518,7 +518,7 @@ curl "https://api.telegram.org/bot/getUpdates" Chaque sujet a alors sa propre clé de session : `agent:zu:telegram:group:-1001234567890:topic:3` - **Liaison ACP persistante par sujet** : les sujets de forum peuvent épingler des sessions de harnais ACP via des liaisons ACP typées de niveau supérieur : + **Liaison persistante de sujet ACP** : les sujets de forum peuvent épingler des sessions de harness ACP via des liaisons ACP typées de niveau supérieur : - `bindings[]` avec `type: "acp"` et `match.channel: "telegram"` @@ -571,21 +571,21 @@ curl "https://api.telegram.org/bot/getUpdates" Cela est actuellement limité aux sujets de forum dans les groupes et supergroupes. - **Lancement ACP lié à un fil depuis le chat** : + **Lancement ACP lié au fil depuis le chat** : - `/acp spawn --thread here|auto` peut lier le sujet Telegram actuel à une nouvelle session ACP. - - Les messages suivants dans le sujet sont routés directement vers la session ACP liée (pas de `/acp steer` requis). - - OpenClaw épingle le message de confirmation du lancement dans le sujet après une liaison réussie. + - Les messages suivants du sujet sont routés directement vers la session ACP liée (pas de `/acp steer` requis). + - OpenClaw épingle le message de confirmation de lancement dans le sujet après une liaison réussie. - Nécessite `channels.telegram.threadBindings.spawnAcpSessions=true`. - Le contexte de modèle inclut : + Le contexte de template inclut : - `MessageThreadId` - `IsForum` - Comportement des fils DM : + Comportement des fils en DM : - - les chats privés avec `message_thread_id` conservent le routage DM mais utilisent des clés de session/cibles de réponse conscientes des fils. + - les chats privés avec `message_thread_id` conservent le routage DM mais utilisent des clés de session et des cibles de réponse tenant compte des fils. @@ -595,7 +595,7 @@ curl "https://api.telegram.org/bot/getUpdates" Telegram distingue les notes vocales des fichiers audio. - par défaut : comportement de fichier audio - - balise `[[audio_as_voice]]` dans la réponse de l’agent pour forcer l’envoi en note vocale + - balise `[[audio_as_voice]]` dans la réponse de l’agent pour forcer l’envoi comme note vocale Exemple d’action de message : @@ -635,7 +635,7 @@ curl "https://api.telegram.org/bot/getUpdates" - TGS animé : ignoré - WEBM vidéo : ignoré - Champs de contexte du sticker : + Champs de contexte de sticker : - `Sticker.emoji` - `Sticker.setName` @@ -643,13 +643,13 @@ curl "https://api.telegram.org/bot/getUpdates" - `Sticker.fileUniqueId` - `Sticker.cachedDescription` - Fichier de cache de stickers : + Fichier de cache des stickers : - `~/.openclaw/telegram/sticker-cache.json` - Les stickers sont décrits une seule fois (lorsque possible) puis mis en cache afin de réduire les appels de vision répétés. + Les stickers sont décrits une fois (quand c’est possible) puis mis en cache pour réduire les appels de vision répétés. - Activer les actions de stickers : + Activer les actions de sticker : ```json5 { @@ -674,13 +674,13 @@ curl "https://api.telegram.org/bot/getUpdates" } ``` - Rechercher dans les stickers mis en cache : + Rechercher dans les stickers en cache : ```json5 { action: "sticker-search", channel: "telegram", - query: "cat waving", + query: "chat qui fait signe", limit: 5, } ``` @@ -688,30 +688,30 @@ curl "https://api.telegram.org/bot/getUpdates" - Les réactions Telegram arrivent sous forme de mises à jour `message_reaction` (séparées des charges utiles des messages). + Les réactions Telegram arrivent sous forme de mises à jour `message_reaction` (séparées des payloads de message). Lorsqu’elles sont activées, OpenClaw met en file d’attente des événements système tels que : - - `Telegram reaction added: 👍 by Alice (@alice) on msg 42` + - `Réaction Telegram ajoutée : 👍 par Alice (@alice) sur le msg 42` Configuration : - `channels.telegram.reactionNotifications`: `off | own | all` (par défaut : `own`) - `channels.telegram.reactionLevel`: `off | ack | minimal | extensive` (par défaut : `minimal`) - Notes : + Remarques : - - `own` signifie uniquement les réactions des utilisateurs aux messages envoyés par le bot (au mieux via le cache des messages envoyés). + - `own` signifie uniquement les réactions utilisateur sur les messages envoyés par le bot (au mieux via le cache des messages envoyés). - Les événements de réaction respectent toujours les contrôles d’accès Telegram (`dmPolicy`, `allowFrom`, `groupPolicy`, `groupAllowFrom`) ; les expéditeurs non autorisés sont ignorés. - - Telegram ne fournit pas d’ID de fil dans les mises à jour de réaction. + - Telegram ne fournit pas les ID de fil dans les mises à jour de réaction. - les groupes non forum sont routés vers la session de chat de groupe - les groupes forum sont routés vers la session du sujet général du groupe (`:topic:1`), et non vers le sujet d’origine exact - `allowed_updates` pour le polling/webhook inclut automatiquement `message_reaction`. + `allowed_updates` pour polling/Webhook inclut automatiquement `message_reaction`. - + `ackReaction` envoie un emoji d’accusé de réception pendant qu’OpenClaw traite un message entrant. Ordre de résolution : @@ -719,22 +719,22 @@ curl "https://api.telegram.org/bot/getUpdates" - `channels.telegram.accounts..ackReaction` - `channels.telegram.ackReaction` - `messages.ackReaction` - - repli sur l’emoji d’identité de l’agent (`agents.list[].identity.emoji`, sinon "👀") + - repli vers l’emoji d’identité de l’agent (`agents.list[].identity.emoji`, sinon "👀") - Notes : + Remarques : - Telegram attend un emoji unicode (par exemple "👀"). - Utilisez `""` pour désactiver la réaction pour un canal ou un compte. - + Les écritures de configuration du canal sont activées par défaut (`configWrites !== false`). Les écritures déclenchées par Telegram incluent : - les événements de migration de groupe (`migrate_to_chat_id`) pour mettre à jour `channels.telegram.groups` - - `/config set` et `/config unset` (nécessite l’activation de la commande) + - `/config set` et `/config unset` (nécessite l’activation des commandes) Désactiver : @@ -750,36 +750,36 @@ curl "https://api.telegram.org/bot/getUpdates" - + Par défaut : long polling. - Mode webhook : + Mode Webhook : - définissez `channels.telegram.webhookUrl` - - définissez `channels.telegram.webhookSecret` (obligatoire lorsque l’URL webhook est définie) + - définissez `channels.telegram.webhookSecret` (obligatoire lorsque l’URL Webhook est définie) - `channels.telegram.webhookPath` facultatif (par défaut `/telegram-webhook`) - `channels.telegram.webhookHost` facultatif (par défaut `127.0.0.1`) - `channels.telegram.webhookPort` facultatif (par défaut `8787`) - L’écouteur local par défaut pour le mode webhook est lié à `127.0.0.1:8787`. + L’écouteur local par défaut pour le mode Webhook se lie à `127.0.0.1:8787`. - Si votre point de terminaison public diffère, placez un proxy inverse en amont et faites pointer `webhookUrl` vers l’URL publique. + Si votre point de terminaison public est différent, placez un proxy inverse devant et pointez `webhookUrl` vers l’URL publique. Définissez `webhookHost` (par exemple `0.0.0.0`) lorsque vous avez intentionnellement besoin d’une entrée externe. - - `channels.telegram.textChunkLimit` vaut 4000 par défaut. - - `channels.telegram.chunkMode="newline"` privilégie les frontières de paragraphe (lignes vides) avant la segmentation par longueur. - - `channels.telegram.mediaMaxMb` (par défaut 100) limite la taille des médias Telegram entrants et sortants. - - `channels.telegram.timeoutSeconds` remplace le délai d’expiration du client Telegram API (si non défini, la valeur par défaut de grammY s’applique). - - l’historique du contexte de groupe utilise `channels.telegram.historyLimit` ou `messages.groupChat.historyLimit` (par défaut 50) ; `0` le désactive. + - la valeur par défaut de `channels.telegram.textChunkLimit` est 4000. + - `channels.telegram.chunkMode="newline"` privilégie les limites de paragraphe (lignes vides) avant le découpage par longueur. + - `channels.telegram.mediaMaxMb` (100 par défaut) limite la taille des médias Telegram entrants et sortants. + - `channels.telegram.timeoutSeconds` remplace le délai d’expiration du client API Telegram (si non défini, la valeur par défaut de grammY s’applique). + - l’historique du contexte de groupe utilise `channels.telegram.historyLimit` ou `messages.groupChat.historyLimit` (50 par défaut) ; `0` désactive. - le contexte supplémentaire de réponse/citation/transfert est actuellement transmis tel que reçu. - - les listes d’autorisation Telegram servent principalement à contrôler qui peut déclencher l’agent, et non une frontière complète de caviardage du contexte supplémentaire. + - les listes d’autorisation Telegram contrôlent principalement qui peut déclencher l’agent, et non une limite complète de masquage du contexte supplémentaire. - contrôles d’historique DM : - `channels.telegram.dmHistoryLimit` - `channels.telegram.dms[""].historyLimit` - - la configuration `channels.telegram.retry` s’applique aux helpers d’envoi Telegram (CLI/outils/actions) pour les erreurs API sortantes récupérables. + - la configuration `channels.telegram.retry` s’applique aux helpers d’envoi Telegram (CLI/outils/actions) pour les erreurs récupérables de l’API sortante. La cible d’envoi CLI peut être un ID de chat numérique ou un nom d’utilisateur : @@ -798,19 +798,19 @@ openclaw message poll --channel telegram --target -1001234567890:topic:42 \ --poll-duration-seconds 300 --poll-public ``` - Drapeaux de sondage réservés à Telegram : + Indicateurs de sondage propres à Telegram : - `--poll-duration-seconds` (5-600) - `--poll-anonymous` - `--poll-public` - `--thread-id` pour les sujets de forum (ou utilisez une cible `:topic:`) - L’envoi Telegram prend également en charge : + L’envoi Telegram prend aussi en charge : - - `--buttons` pour les claviers intégrés lorsque `channels.telegram.capabilities.inlineButtons` l’autorise - - `--force-document` pour envoyer des images et GIF sortants comme documents au lieu de photos compressées ou de médias animés + - `--buttons` pour les claviers en ligne lorsque `channels.telegram.capabilities.inlineButtons` l’autorise + - `--force-document` pour envoyer les images et GIF sortants comme documents au lieu d’uploads photo compressés ou média animé - Restriction des actions : + Limitation des actions : - `channels.telegram.actions.sendMessage=false` désactive les messages Telegram sortants, y compris les sondages - `channels.telegram.actions.poll=false` désactive la création de sondages Telegram tout en laissant les envois classiques activés @@ -823,40 +823,40 @@ openclaw message poll --channel telegram --target -1001234567890:topic:42 \ Chemin de configuration : - `channels.telegram.execApprovals.enabled` - - `channels.telegram.execApprovals.approvers` (facultatif ; retombe sur les ID de propriétaire numériques déduits de `allowFrom` et de `defaultTo` direct lorsque possible) - - `channels.telegram.execApprovals.target` (`dm` | `channel` | `both`, par défaut : `dm`) + - `channels.telegram.execApprovals.approvers` (facultatif ; se rabat sur les ID propriétaires numériques déduits de `allowFrom` et du `defaultTo` direct lorsque c’est possible) + - `channels.telegram.execApprovals.target` (`dm` | `channel` | `both`, `dm` par défaut) - `agentFilter`, `sessionFilter` - Les approbateurs doivent être des ID utilisateur Telegram numériques. Telegram active automatiquement les approbations exec natives lorsque `enabled` n’est pas défini ou vaut `"auto"` et qu’au moins un approbateur peut être résolu, soit depuis `execApprovals.approvers`, soit depuis la configuration numérique du propriétaire du compte (`allowFrom` et `defaultTo` de message direct). Définissez `enabled: false` pour désactiver explicitement Telegram comme client d’approbation natif. Les demandes d’approbation retombent sinon sur d’autres routes d’approbation configurées ou sur la politique de repli des approbations exec. + Les approbateurs doivent être des ID utilisateur Telegram numériques. Telegram active automatiquement les approbations exec natives lorsque `enabled` n’est pas défini ou vaut `"auto"` et qu’au moins un approbateur peut être résolu, soit depuis `execApprovals.approvers`, soit depuis la configuration propriétaire numérique du compte (`allowFrom` et `defaultTo` en message direct). Définissez `enabled: false` pour désactiver explicitement Telegram comme client d’approbation natif. Les demandes d’approbation se rabattent sinon sur les autres routes d’approbation configurées ou sur la politique de repli des approbations exec. - Telegram affiche également les boutons d’approbation partagés utilisés par les autres canaux de chat. L’adaptateur Telegram natif ajoute principalement le routage DM des approbateurs, la diffusion vers le canal/sujet et les indications de saisie avant livraison. - Lorsque ces boutons sont présents, ils constituent l’UX principale d’approbation ; OpenClaw + Telegram affiche aussi les boutons d’approbation partagés utilisés par les autres canaux de chat. L’adaptateur Telegram natif ajoute principalement le routage DM des approbateurs, la diffusion vers le canal/sujet et les indications de saisie avant livraison. + Lorsque ces boutons sont présents, ils constituent l’UX d’approbation principale ; OpenClaw ne doit inclure une commande manuelle `/approve` que lorsque le résultat de l’outil indique - que les approbations de chat ne sont pas disponibles ou que l’approbation manuelle est la seule voie. + que les approbations par chat ne sont pas disponibles ou que l’approbation manuelle est la seule voie. Règles de livraison : - `target: "dm"` envoie les invites d’approbation uniquement aux DM des approbateurs résolus - - `target: "channel"` renvoie l’invite au chat/sujet Telegram d’origine + - `target: "channel"` renvoie l’invite vers le chat/sujet Telegram d’origine - `target: "both"` envoie aux DM des approbateurs et au chat/sujet d’origine Seuls les approbateurs résolus peuvent approuver ou refuser. Les non-approbateurs ne peuvent pas utiliser `/approve` ni les boutons d’approbation Telegram. Comportement de résolution des approbations : - - les ID préfixés par `plugin:` sont toujours résolus via les approbations de plugin. + - les ID préfixés par `plugin:` sont toujours résolus via les approbations du Plugin. - les autres ID essaient d’abord `exec.approval.resolve`. - - si Telegram est aussi autorisé pour les approbations de plugin et que gateway indique + - si Telegram est aussi autorisé pour les approbations du Plugin et que la Gateway indique que l’approbation exec est inconnue/expirée, Telegram réessaie une fois via `plugin.approval.resolve`. - - les refus/erreurs d’approbation exec réels ne retombent pas silencieusement sur la résolution - d’approbation de plugin. + - les refus/erreurs réels d’approbation exec ne basculent pas silencieusement vers la + résolution d’approbation du Plugin. - La livraison dans le canal affiche le texte de la commande dans le chat ; activez donc `channel` ou `both` uniquement dans des groupes/sujets de confiance. Lorsque l’invite arrive dans un sujet de forum, OpenClaw préserve le sujet à la fois pour l’invite d’approbation et pour le suivi après approbation. Les approbations exec expirent après 30 minutes par défaut. + La livraison dans le canal affiche le texte de la commande dans le chat ; n’activez donc `channel` ou `both` que dans des groupes/sujets de confiance. Lorsque l’invite arrive dans un sujet de forum, OpenClaw préserve le sujet à la fois pour l’invite d’approbation et pour le suivi post-approbation. Les approbations exec expirent au bout de 30 minutes par défaut. - Les boutons d’approbation intégrés dépendent aussi du fait que `channels.telegram.capabilities.inlineButtons` autorise la surface cible (`dm`, `group` ou `all`). + Les boutons d’approbation en ligne dépendent aussi du fait que `channels.telegram.capabilities.inlineButtons` autorise la surface cible (`dm`, `group` ou `all`). - Documentation associée : [Approbations exec](/tools/exec-approvals) + Documentation associée : [Approbations exec](/fr/tools/exec-approvals) @@ -865,10 +865,10 @@ openclaw message poll --channel telegram --target -1001234567890:topic:42 \ Lorsque l’agent rencontre une erreur de livraison ou de fournisseur, Telegram peut soit répondre avec le texte d’erreur, soit le supprimer. Deux clés de configuration contrôlent ce comportement : -| Clé | Valeurs | Par défaut | Description | -| ----------------------------------- | ----------------- | ---------- | ----------------------------------------------------------------------------------------------- | -| `channels.telegram.errorPolicy` | `reply`, `silent` | `reply` | `reply` envoie un message d’erreur convivial dans le chat. `silent` supprime entièrement les réponses d’erreur. | -| `channels.telegram.errorCooldownMs` | number (ms) | `60000` | Temps minimal entre deux réponses d’erreur au même chat. Empêche le spam d’erreurs pendant les pannes. | +| Key | Values | Default | Description | +| ----------------------------------- | ----------------- | ------- | ----------------------------------------------------------------------------------------------- | +| `channels.telegram.errorPolicy` | `reply`, `silent` | `reply` | `reply` envoie un message d’erreur convivial dans le chat. `silent` supprime entièrement les réponses d’erreur. | +| `channels.telegram.errorCooldownMs` | number (ms) | `60000` | Temps minimal entre les réponses d’erreur vers le même chat. Empêche le spam d’erreurs pendant les pannes. | Les remplacements par compte, par groupe et par sujet sont pris en charge (même héritage que pour les autres clés de configuration Telegram). @@ -880,7 +880,7 @@ Les remplacements par compte, par groupe et par sujet sont pris en charge (même errorCooldownMs: 120000, groups: { "-1001234567890": { - errorPolicy: "silent", // supprimer les erreurs dans ce groupe + errorPolicy: "silent", // supprime les erreurs dans ce groupe }, }, }, @@ -894,10 +894,10 @@ Les remplacements par compte, par groupe et par sujet sont pris en charge (même - Si `requireMention=false`, le mode confidentialité Telegram doit autoriser une visibilité complète. - - BotFather : `/setprivacy` -> Désactiver - - puis supprimer + réajouter le bot au groupe + - BotFather : `/setprivacy` -> Disable + - puis retirez + rajoutez le bot au groupe - `openclaw channels status` avertit lorsque la configuration attend des messages de groupe sans mention. - - `openclaw channels status --probe` peut vérifier des ID de groupe numériques explicites ; le joker `"*"` ne peut pas être sondé pour l’appartenance. + - `openclaw channels status --probe` peut vérifier des ID de groupe numériques explicites ; le joker `"*"` ne peut pas être vérifié pour l’appartenance. - test rapide de session : `/activation always`. @@ -912,19 +912,19 @@ Les remplacements par compte, par groupe et par sujet sont pris en charge (même - - autorisez votre identité d’expéditeur (appairage et/ou `allowFrom` numérique) + - autorisez l’identité de votre expéditeur (appairage et/ou `allowFrom` numérique) - l’autorisation des commandes s’applique toujours même lorsque la politique de groupe est `open` - - `setMyCommands failed` avec `BOT_COMMANDS_TOO_MUCH` signifie que le menu natif a trop d’entrées ; réduisez les commandes personnalisées/de plugin/de Skills ou désactivez les menus natifs + - `setMyCommands failed` avec `BOT_COMMANDS_TOO_MUCH` signifie que le menu natif comporte trop d’entrées ; réduisez les commandes de Plugin/Skills/personnalisées ou désactivez les menus natifs - `setMyCommands failed` avec des erreurs réseau/fetch indique généralement des problèmes d’accessibilité DNS/HTTPS vers `api.telegram.org` - + - - Node 22+ + fetch/proxy personnalisé peuvent déclencher un comportement d’abandon immédiat si les types AbortSignal ne correspondent pas. - - Certains hôtes résolvent `api.telegram.org` vers IPv6 en premier ; une sortie IPv6 défectueuse peut provoquer des échecs intermittents de Telegram API. + - Node 22+ + fetch/proxy personnalisé peut déclencher un comportement d’abandon immédiat si les types `AbortSignal` ne correspondent pas. + - Certains hôtes résolvent `api.telegram.org` d’abord en IPv6 ; une sortie IPv6 défaillante peut provoquer des pannes intermittentes de l’API Telegram. - Si les journaux incluent `TypeError: fetch failed` ou `Network request for 'getUpdates' failed!`, OpenClaw réessaie désormais ces cas comme des erreurs réseau récupérables. - - Sur des hôtes VPS avec sortie directe/TLS instable, faites passer les appels Telegram API via `channels.telegram.proxy` : + - Sur des hôtes VPS avec sortie directe/TLS instable, routez les appels API Telegram via `channels.telegram.proxy` : ```yaml channels: @@ -943,10 +943,10 @@ channels: ``` - Les réponses de plage de benchmark RFC 2544 (`198.18.0.0/15`) sont déjà autorisées - par défaut pour les téléchargements de médias Telegram. Si un faux IP ou un proxy - transparent de confiance réécrit `api.telegram.org` vers une autre - adresse privée/interne/spéciale lors des téléchargements de médias, vous pouvez activer - le contournement réservé à Telegram : + par défaut pour les téléchargements de médias Telegram. Si une fausse IP de confiance ou un + proxy transparent réécrit `api.telegram.org` vers une autre + adresse privée/interne/à usage spécial pendant les téléchargements de médias, vous pouvez + activer le contournement propre à Telegram : ```yaml channels: @@ -955,25 +955,25 @@ channels: dangerouslyAllowPrivateNetwork: true ``` - - Le même opt-in est disponible par compte dans + - La même option d’activation existe aussi par compte dans `channels.telegram.accounts..network.dangerouslyAllowPrivateNetwork`. - - Si votre proxy résout les hôtes média Telegram en `198.18.x.x`, laissez - d’abord le drapeau dangereux désactivé. Les médias Telegram autorisent déjà - la plage de benchmark RFC 2544 par défaut. + - Si votre proxy résout les hôtes média Telegram en `198.18.x.x`, laissez d’abord + cette option dangereuse désactivée. Les médias Telegram autorisent déjà par défaut + la plage de benchmark RFC 2544. - `channels.telegram.network.dangerouslyAllowPrivateNetwork` affaiblit les protections - SSRF des médias Telegram. Utilisez-le uniquement dans des environnements de proxy - de confiance contrôlés par l’opérateur, tels que le routage fake-IP de Clash, Mihomo ou Surge, - lorsqu’ils synthétisent des réponses privées ou spéciales en dehors de la - plage de benchmark RFC 2544. Laissez-le désactivé pour un accès Telegram Internet public normal. + `channels.telegram.network.dangerouslyAllowPrivateNetwork` affaiblit les protections SSRF + des médias Telegram. Utilisez-le uniquement dans des environnements proxy de confiance contrôlés par l’opérateur + tels que le routage fake-IP de Clash, Mihomo ou Surge lorsqu’ils synthétisent des réponses + privées ou à usage spécial en dehors de la plage de benchmark RFC 2544. + Laissez-le désactivé pour un accès Telegram normal sur l’internet public. - Remplacements via variables d’environnement (temporaires) : - `OPENCLAW_TELEGRAM_DISABLE_AUTO_SELECT_FAMILY=1` - `OPENCLAW_TELEGRAM_ENABLE_AUTO_SELECT_FAMILY=1` - `OPENCLAW_TELEGRAM_DNS_RESULT_ORDER=ipv4first` - - Validez les réponses DNS : + - Valider les réponses DNS : ```bash dig +short api.telegram.org A @@ -983,9 +983,9 @@ dig +short api.telegram.org AAAA -Plus d’aide : [Dépannage des canaux](/channels/troubleshooting). +Plus d’aide : [Dépannage du canal](/fr/channels/troubleshooting). -## Pointeurs de référence de configuration Telegram +## Pointeurs vers la référence de configuration Telegram Référence principale : @@ -993,69 +993,69 @@ Référence principale : - `channels.telegram.botToken` : jeton du bot (BotFather). - `channels.telegram.tokenFile` : lire le jeton depuis un chemin de fichier ordinaire. Les liens symboliques sont rejetés. - `channels.telegram.dmPolicy` : `pairing | allowlist | open | disabled` (par défaut : pairing). -- `channels.telegram.allowFrom` : liste d’autorisation DM (ID utilisateur Telegram numériques). `allowlist` exige au moins un ID d’expéditeur. `open` exige `"*"`. `openclaw doctor --fix` peut résoudre les anciennes entrées `@username` en ID et peut récupérer des entrées de liste d’autorisation à partir des fichiers du magasin d’appairage dans les flux de migration de liste d’autorisation. +- `channels.telegram.allowFrom` : liste d’autorisation DM (ID utilisateur Telegram numériques). `allowlist` nécessite au moins un ID d’expéditeur. `open` nécessite `"*"`. `openclaw doctor --fix` peut résoudre les anciennes entrées `@username` en ID et peut récupérer des entrées d’allowlist depuis des fichiers du magasin d’appairage dans les flux de migration allowlist. - `channels.telegram.actions.poll` : activer ou désactiver la création de sondages Telegram (activé par défaut ; nécessite toujours `sendMessage`). - `channels.telegram.defaultTo` : cible Telegram par défaut utilisée par le CLI `--deliver` lorsqu’aucun `--reply-to` explicite n’est fourni. - `channels.telegram.groupPolicy` : `open | allowlist | disabled` (par défaut : allowlist). -- `channels.telegram.groupAllowFrom` : liste d’autorisation des expéditeurs de groupe (ID utilisateur Telegram numériques). `openclaw doctor --fix` peut résoudre les anciennes entrées `@username` en ID. Les entrées non numériques sont ignorées au moment de l’authentification. L’authentification de groupe n’utilise pas de repli sur le magasin d’appairage DM (`2026.2.25+`). +- `channels.telegram.groupAllowFrom` : liste d’autorisation des expéditeurs de groupe (ID utilisateur Telegram numériques). `openclaw doctor --fix` peut résoudre les anciennes entrées `@username` en ID. Les entrées non numériques sont ignorées au moment de l’authentification. L’authentification de groupe n’utilise pas le repli du magasin d’appairage DM (`2026.2.25+`). - Priorité multi-comptes : - - Lorsque deux ID de compte ou plus sont configurés, définissez `channels.telegram.defaultAccount` (ou incluez `channels.telegram.accounts.default`) pour rendre le routage par défaut explicite. - - Si aucun n’est défini, OpenClaw retombe sur le premier ID de compte normalisé et `openclaw doctor` émet un avertissement. - - `channels.telegram.accounts.default.allowFrom` et `channels.telegram.accounts.default.groupAllowFrom` ne s’appliquent qu’au compte `default`. + - Lorsque deux ID de compte ou plus sont configurés, définissez `channels.telegram.defaultAccount` (ou incluez `channels.telegram.accounts.default`) pour expliciter le routage par défaut. + - Si aucun des deux n’est défini, OpenClaw se rabat sur le premier ID de compte normalisé et `openclaw doctor` affiche un avertissement. + - `channels.telegram.accounts.default.allowFrom` et `channels.telegram.accounts.default.groupAllowFrom` s’appliquent uniquement au compte `default`. - Les comptes nommés héritent de `channels.telegram.allowFrom` et `channels.telegram.groupAllowFrom` lorsque les valeurs au niveau du compte ne sont pas définies. - Les comptes nommés n’héritent pas de `channels.telegram.accounts.default.allowFrom` / `groupAllowFrom`. -- `channels.telegram.groups` : valeurs par défaut par groupe + liste d’autorisation (utilisez `"*"` pour des valeurs par défaut globales). +- `channels.telegram.groups` : valeurs par défaut par groupe + allowlist (utilisez `"*"` pour les valeurs par défaut globales). - `channels.telegram.groups..groupPolicy` : remplacement par groupe pour groupPolicy (`open | allowlist | disabled`). - - `channels.telegram.groups..requireMention` : valeur par défaut du contrôle par mention. - - `channels.telegram.groups..skills` : filtre Skills (omission = tous les Skills, vide = aucun). - - `channels.telegram.groups..allowFrom` : remplacement de la liste d’autorisation des expéditeurs par groupe. + - `channels.telegram.groups..requireMention` : valeur par défaut du filtrage par mention. + - `channels.telegram.groups..skills` : filtre de Skills (omis = toutes les Skills, vide = aucune). + - `channels.telegram.groups..allowFrom` : remplacement par groupe de la liste d’autorisation des expéditeurs. - `channels.telegram.groups..systemPrompt` : prompt système supplémentaire pour le groupe. - - `channels.telegram.groups..enabled` : désactive le groupe lorsque `false`. - - `channels.telegram.groups..topics..*` : remplacements par sujet (champs de groupe + `agentId` réservé au sujet). - - `channels.telegram.groups..topics..agentId` : route ce sujet vers un agent spécifique (remplace le routage au niveau du groupe et des liaisons). + - `channels.telegram.groups..enabled` : désactive le groupe lorsqu’il vaut `false`. + - `channels.telegram.groups..topics..*` : remplacements par sujet (champs de groupe + `agentId` propre au sujet). + - `channels.telegram.groups..topics..agentId` : route ce sujet vers un agent spécifique (remplace le routage au niveau du groupe et des bindings). - `channels.telegram.groups..topics..groupPolicy` : remplacement par sujet pour groupPolicy (`open | allowlist | disabled`). -- `channels.telegram.groups..topics..requireMention` : remplacement du contrôle par mention par sujet. -- `bindings[]` de niveau supérieur avec `type: "acp"` et ID de sujet canonique `chatId:topic:topicId` dans `match.peer.id` : champs de liaison ACP persistante par sujet (voir [Agents ACP](/tools/acp-agents#channel-specific-settings)). +- `channels.telegram.groups..topics..requireMention` : remplacement par sujet du filtrage par mention. +- `bindings[]` de niveau supérieur avec `type: "acp"` et ID de sujet canonique `chatId:topic:topicId` dans `match.peer.id` : champs de liaison persistante de sujet ACP (voir [Agents ACP](/fr/tools/acp-agents#channel-specific-settings)). - `channels.telegram.direct..topics..agentId` : route les sujets DM vers un agent spécifique (même comportement que les sujets de forum). - `channels.telegram.execApprovals.enabled` : active Telegram comme client d’approbation exec basé sur le chat pour ce compte. - `channels.telegram.execApprovals.approvers` : ID utilisateur Telegram autorisés à approuver ou refuser des demandes exec. Facultatif lorsque `channels.telegram.allowFrom` ou un `channels.telegram.defaultTo` direct identifie déjà le propriétaire. - `channels.telegram.execApprovals.target` : `dm | channel | both` (par défaut : `dm`). `channel` et `both` préservent le sujet Telegram d’origine lorsqu’il est présent. -- `channels.telegram.execApprovals.agentFilter` : filtre facultatif sur les ID d’agent pour les invites d’approbation transférées. -- `channels.telegram.execApprovals.sessionFilter` : filtre facultatif sur les clés de session (sous-chaîne ou regex) pour les invites d’approbation transférées. +- `channels.telegram.execApprovals.agentFilter` : filtre facultatif d’ID d’agent pour les invites d’approbation transférées. +- `channels.telegram.execApprovals.sessionFilter` : filtre facultatif de clé de session (sous-chaîne ou regex) pour les invites d’approbation transférées. - `channels.telegram.accounts..execApprovals` : remplacement par compte pour le routage des approbations exec Telegram et l’autorisation des approbateurs. - `channels.telegram.capabilities.inlineButtons` : `off | dm | group | all | allowlist` (par défaut : allowlist). - `channels.telegram.accounts..capabilities.inlineButtons` : remplacement par compte. -- `channels.telegram.commands.nativeSkills` : activer/désactiver les commandes natives de Skills Telegram. +- `channels.telegram.commands.nativeSkills` : activer/désactiver les commandes natives Skills de Telegram. - `channels.telegram.replyToMode` : `off | first | all` (par défaut : `off`). -- `channels.telegram.textChunkLimit` : taille de segmentation sortante (caractères). -- `channels.telegram.chunkMode` : `length` (par défaut) ou `newline` pour segmenter sur les lignes vides (frontières de paragraphe) avant la segmentation par longueur. -- `channels.telegram.linkPreview` : activer/désactiver les aperçus de liens pour les messages sortants (par défaut : true). -- `channels.telegram.streaming` : `off | partial | block | progress` (aperçu de flux en direct ; par défaut : `partial` ; `progress` correspond à `partial` ; `block` est une compatibilité héritée avec le mode d’aperçu). Le flux d’aperçu Telegram utilise un unique message d’aperçu modifié sur place. -- `channels.telegram.mediaMaxMb` : limite de médias Telegram entrants/sortants (MB, par défaut : 100). -- `channels.telegram.retry` : politique de nouvelle tentative pour les helpers d’envoi Telegram (CLI/outils/actions) sur les erreurs API sortantes récupérables (tentatives, minDelayMs, maxDelayMs, jitter). +- `channels.telegram.textChunkLimit` : taille de fragment sortant (caractères). +- `channels.telegram.chunkMode` : `length` (par défaut) ou `newline` pour découper sur les lignes vides (limites de paragraphe) avant le découpage par longueur. +- `channels.telegram.linkPreview` : active/désactive les aperçus de liens pour les messages sortants (par défaut : true). +- `channels.telegram.streaming` : `off | partial | block | progress` (aperçu du flux en direct ; par défaut : `partial` ; `progress` est mappé vers `partial` ; `block` est la compatibilité avec l’ancien mode d’aperçu). Le flux d’aperçu Telegram utilise un unique message d’aperçu modifié sur place. +- `channels.telegram.mediaMaxMb` : limite de médias Telegram entrants/sortants (Mo, 100 par défaut). +- `channels.telegram.retry` : politique de nouvelle tentative pour les helpers d’envoi Telegram (CLI/outils/actions) sur les erreurs récupérables de l’API sortante (tentatives, minDelayMs, maxDelayMs, jitter). - `channels.telegram.network.autoSelectFamily` : remplace Node autoSelectFamily (true=activer, false=désactiver). Activé par défaut sur Node 22+, avec WSL2 désactivé par défaut. -- `channels.telegram.network.dnsResultOrder` : remplace l’ordre des résultats DNS (`ipv4first` ou `verbatim`). `ipv4first` par défaut sur Node 22+. -- `channels.telegram.network.dangerouslyAllowPrivateNetwork` : opt-in dangereux pour les environnements de faux IP ou proxy transparent de confiance où les téléchargements de médias Telegram résolvent `api.telegram.org` vers des adresses privées/internes/spéciales en dehors de la plage de benchmark RFC 2544 autorisée par défaut. -- `channels.telegram.proxy` : URL du proxy pour les appels Bot API (SOCKS/HTTP). -- `channels.telegram.webhookUrl` : active le mode webhook (nécessite `channels.telegram.webhookSecret`). -- `channels.telegram.webhookSecret` : secret webhook (obligatoire lorsque `webhookUrl` est défini). -- `channels.telegram.webhookPath` : chemin webhook local (par défaut `/telegram-webhook`). -- `channels.telegram.webhookHost` : hôte de liaison du webhook local (par défaut `127.0.0.1`). -- `channels.telegram.webhookPort` : port de liaison du webhook local (par défaut `8787`). -- `channels.telegram.actions.reactions` : restreint les réactions d’outil Telegram. -- `channels.telegram.actions.sendMessage` : restreint les envois de message d’outil Telegram. -- `channels.telegram.actions.deleteMessage` : restreint les suppressions de message d’outil Telegram. -- `channels.telegram.actions.sticker` : restreint les actions de sticker Telegram — envoi et recherche (par défaut : false). -- `channels.telegram.reactionNotifications` : `off | own | all` — contrôle quelles réactions déclenchent des événements système (par défaut : `own` si non défini). -- `channels.telegram.reactionLevel` : `off | ack | minimal | extensive` — contrôle la capacité de réaction de l’agent (par défaut : `minimal` si non défini). +- `channels.telegram.network.dnsResultOrder` : remplace l’ordre de résultat DNS (`ipv4first` ou `verbatim`). `ipv4first` par défaut sur Node 22+. +- `channels.telegram.network.dangerouslyAllowPrivateNetwork` : option dangereuse pour les environnements de fake-IP ou de proxy transparent de confiance où les téléchargements de médias Telegram résolvent `api.telegram.org` vers des adresses privées/internes/à usage spécial en dehors de l’autorisation par défaut de la plage de benchmark RFC 2544. +- `channels.telegram.proxy` : URL de proxy pour les appels API Bot (SOCKS/HTTP). +- `channels.telegram.webhookUrl` : active le mode Webhook (nécessite `channels.telegram.webhookSecret`). +- `channels.telegram.webhookSecret` : secret Webhook (obligatoire lorsque webhookUrl est défini). +- `channels.telegram.webhookPath` : chemin Webhook local (par défaut `/telegram-webhook`). +- `channels.telegram.webhookHost` : hôte de liaison Webhook local (par défaut `127.0.0.1`). +- `channels.telegram.webhookPort` : port de liaison Webhook local (par défaut `8787`). +- `channels.telegram.actions.reactions` : limite les réactions des outils Telegram. +- `channels.telegram.actions.sendMessage` : limite les envois de messages des outils Telegram. +- `channels.telegram.actions.deleteMessage` : limite les suppressions de messages des outils Telegram. +- `channels.telegram.actions.sticker` : limite les actions de sticker Telegram — envoi et recherche (par défaut : false). +- `channels.telegram.reactionNotifications` : `off | own | all` — contrôle quelles réactions déclenchent des événements système (par défaut : `own` lorsqu’il n’est pas défini). +- `channels.telegram.reactionLevel` : `off | ack | minimal | extensive` — contrôle la capacité de réaction de l’agent (par défaut : `minimal` lorsqu’il n’est pas défini). - `channels.telegram.errorPolicy` : `reply | silent` — contrôle le comportement des réponses d’erreur (par défaut : `reply`). Remplacements par compte/groupe/sujet pris en charge. -- `channels.telegram.errorCooldownMs` : nombre minimal de ms entre deux réponses d’erreur au même chat (par défaut : `60000`). Empêche le spam d’erreurs pendant les pannes. +- `channels.telegram.errorCooldownMs` : nombre minimal de ms entre les réponses d’erreur vers le même chat (par défaut : `60000`). Empêche le spam d’erreurs pendant les pannes. -- [Référence de configuration - Telegram](/gateway/configuration-reference#telegram) +- [Référence de configuration - Telegram](/fr/gateway/configuration-reference#telegram) Champs Telegram spécifiques à fort signal : -- démarrage/authentification : `enabled`, `botToken`, `tokenFile`, `accounts.*` (`tokenFile` doit pointer vers un fichier ordinaire ; les liens symboliques sont rejetés) +- démarrage/auth : `enabled`, `botToken`, `tokenFile`, `accounts.*` (`tokenFile` doit pointer vers un fichier ordinaire ; les liens symboliques sont rejetés) - contrôle d’accès : `dmPolicy`, `allowFrom`, `groupPolicy`, `groupAllowFrom`, `groups`, `groups.*.topics.*`, `bindings[]` de niveau supérieur (`type: "acp"`) - approbations exec : `execApprovals`, `accounts.*.execApprovals` - commande/menu : `commands.native`, `commands.nativeSkills`, `customCommands` @@ -1063,17 +1063,17 @@ Champs Telegram spécifiques à fort signal : - streaming : `streaming` (aperçu), `blockStreaming` - formatage/livraison : `textChunkLimit`, `chunkMode`, `linkPreview`, `responsePrefix` - média/réseau : `mediaMaxMb`, `timeoutSeconds`, `retry`, `network.autoSelectFamily`, `network.dangerouslyAllowPrivateNetwork`, `proxy` -- webhook : `webhookUrl`, `webhookSecret`, `webhookPath`, `webhookHost` +- Webhook : `webhookUrl`, `webhookSecret`, `webhookPath`, `webhookHost` - actions/capacités : `capabilities.inlineButtons`, `actions.sendMessage|editMessage|deleteMessage|reactions|sticker` - réactions : `reactionNotifications`, `reactionLevel` - erreurs : `errorPolicy`, `errorCooldownMs` - écritures/historique : `configWrites`, `historyLimit`, `dmHistoryLimit`, `dms.*.historyLimit` -## Liens associés +## Associé -- [Appairage](/channels/pairing) -- [Groupes](/channels/groups) -- [Sécurité](/gateway/security) -- [Routage des canaux](/channels/channel-routing) -- [Routage multi-agent](/concepts/multi-agent) -- [Dépannage](/channels/troubleshooting) +- [Appairage](/fr/channels/pairing) +- [Groupes](/fr/channels/groups) +- [Sécurité](/fr/gateway/security) +- [Routage des canaux](/fr/channels/channel-routing) +- [Routage multi-agent](/fr/concepts/multi-agent) +- [Dépannage](/fr/channels/troubleshooting) diff --git a/docs/fr/channels/troubleshooting.md b/docs/fr/channels/troubleshooting.md index 49bba6811..ad266e3f5 100644 --- a/docs/fr/channels/troubleshooting.md +++ b/docs/fr/channels/troubleshooting.md @@ -1,25 +1,25 @@ --- read_when: - - Le transport du canal indique connecté, mais les réponses échouent - - Vous avez besoin de vérifications spécifiques au canal avant la documentation approfondie du fournisseur -summary: Dépannage rapide au niveau des canaux avec signatures de panne et correctifs par canal + - Le transport du canal indique qu’il est connecté, mais les réponses échouent + - Vous avez besoin de vérifications spécifiques au canal avant de consulter en détail la documentation du fournisseur. +summary: Dépannage rapide au niveau des canaux avec signatures d’échec et correctifs par canal title: Dépannage des canaux x-i18n: - generated_at: "2026-04-05T12:36:45Z" + generated_at: "2026-04-20T07:05:27Z" model: gpt-5.4 provider: openai - source_hash: d45d8220505ea420d970b20bc66e65216c2d7024b5736db1936421ffc0676e1f + source_hash: 0aef31742cd5cc4af3fa3d3ea1acba51875ad4a1423c0e8c87372c3df31b0528 source_path: channels/troubleshooting.md workflow: 15 --- # Dépannage des canaux -Utilisez cette page lorsqu’un canal se connecte, mais que son comportement est incorrect. +Utilisez cette page lorsqu’un canal se connecte, mais que le comportement est incorrect. ## Échelle de commandes -Exécutez d’abord celles-ci dans l’ordre : +Exécutez d’abord celles-ci dans cet ordre : ```bash openclaw status @@ -29,112 +29,113 @@ openclaw doctor openclaw channels status --probe ``` -Base de référence saine : +Référence saine : - `Runtime: running` -- `RPC probe: ok` -- La sonde du canal indique que le transport est connecté et, lorsque pris en charge, `works` ou `audit ok` +- `Connectivity probe: ok` +- `Capability: read-only`, `write-capable` ou `admin-capable` +- La sonde du canal indique que le transport est connecté et, lorsque c’est pris en charge, `works` ou `audit ok` ## WhatsApp -### Signatures de panne WhatsApp +### Signatures d’échec WhatsApp -| Symptôme | Vérification la plus rapide | Correctif | -| ------------------------------ | ---------------------------------------------------- | ------------------------------------------------------- | -| Connecté mais aucune réponse DM | `openclaw pairing list whatsapp` | Approuvez l’expéditeur ou changez la politique DM/la liste d’autorisation. | -| Messages de groupe ignorés | Vérifiez `requireMention` et les motifs de mention dans la configuration | Mentionnez le bot ou assouplissez la politique de mention pour ce groupe. | -| Boucles aléatoires de déconnexion/reconnexion | `openclaw channels status --probe` + journaux | Reconnectez-vous et vérifiez que le répertoire d’identifiants est sain. | +| Symptôme | Vérification la plus rapide | Correctif | +| -------------------------------- | --------------------------------------------------- | ------------------------------------------------------------- | +| Connecté mais aucune réponse en DM | `openclaw pairing list whatsapp` | Approuvez l’expéditeur ou modifiez la politique DM/la liste d’autorisation. | +| Messages de groupe ignorés | Vérifiez `requireMention` + les motifs de mention dans la configuration | Mentionnez le bot ou assouplissez la politique de mention pour ce groupe. | +| Déconnexions/boucles de reconnexion aléatoires | `openclaw channels status --probe` + journaux | Reconnectez-vous et vérifiez que le répertoire des identifiants est sain. | -Dépannage complet : [/channels/whatsapp#troubleshooting](/channels/whatsapp#troubleshooting) +Dépannage complet : [/channels/whatsapp#troubleshooting](/fr/channels/whatsapp#troubleshooting) ## Telegram -### Signatures de panne Telegram +### Signatures d’échec Telegram -| Symptôme | Vérification la plus rapide | Correctif | -| ----------------------------------- | --------------------------------------------- | -------------------------------------------------------------------------- | -| `/start` mais aucun flux de réponse exploitable | `openclaw pairing list telegram` | Approuvez l’appairage ou modifiez la politique DM. | -| Bot en ligne mais groupe silencieux | Vérifiez l’obligation de mention et le mode confidentialité du bot | Désactivez le mode confidentialité pour la visibilité en groupe ou mentionnez le bot. | -| Échecs d’envoi avec erreurs réseau | Inspectez les journaux pour les échecs d’appel à l’API Telegram | Corrigez le routage DNS/IPv6/proxy vers `api.telegram.org`. | -| `setMyCommands` rejeté au démarrage | Inspectez les journaux pour `BOT_COMMANDS_TOO_MUCH` | Réduisez les commandes Telegram de plugin/Skills/personnalisées ou désactivez les menus natifs. | -| Après mise à niveau, la liste d’autorisation vous bloque | `openclaw security audit` et les listes d’autorisation de la configuration | Exécutez `openclaw doctor --fix` ou remplacez `@username` par des identifiants numériques d’expéditeur. | +| Symptôme | Vérification la plus rapide | Correctif | +| ------------------------------------ | ----------------------------------------------- | --------------------------------------------------------------------------- | +| `/start` mais aucun flux de réponse exploitable | `openclaw pairing list telegram` | Approuvez l’association ou modifiez la politique DM. | +| Bot en ligne mais groupe silencieux | Vérifiez l’exigence de mention et le mode confidentialité du bot | Désactivez le mode confidentialité pour la visibilité du groupe ou mentionnez le bot. | +| Échecs d’envoi avec erreurs réseau | Inspectez les journaux pour les échecs d’appel à l’API Telegram | Corrigez le routage DNS/IPv6/proxy vers `api.telegram.org`. | +| `setMyCommands` rejeté au démarrage | Inspectez les journaux pour `BOT_COMMANDS_TOO_MUCH` | Réduisez les commandes Telegram de Plugin/Skills/personnalisées ou désactivez les menus natifs. | +| Mise à niveau effectuée et la liste d’autorisation vous bloque | `openclaw security audit` et les listes d’autorisation de la configuration | Exécutez `openclaw doctor --fix` ou remplacez `@username` par des identifiants numériques d’expéditeur. | -Dépannage complet : [/channels/telegram#troubleshooting](/channels/telegram#troubleshooting) +Dépannage complet : [/channels/telegram#troubleshooting](/fr/channels/telegram#troubleshooting) ## Discord -### Signatures de panne Discord +### Signatures d’échec Discord -| Symptôme | Vérification la plus rapide | Correctif | -| ------------------------------ | ------------------------------------ | -------------------------------------------------------- | -| Bot en ligne mais aucune réponse dans la guilde | `openclaw channels status --probe` | Autorisez la guilde/le canal et vérifiez l’intention de contenu des messages. | -| Messages de groupe ignorés | Vérifiez dans les journaux les rejets dus au filtrage par mention | Mentionnez le bot ou définissez `requireMention: false` pour la guilde/le canal. | -| Réponses DM manquantes | `openclaw pairing list discord` | Approuvez l’appairage DM ou ajustez la politique DM. | +| Symptôme | Vérification la plus rapide | Correctif | +| -------------------------------- | ----------------------------------- | ------------------------------------------------------------- | +| Bot en ligne mais aucune réponse sur le serveur | `openclaw channels status --probe` | Autorisez le serveur/le canal et vérifiez l’intent de contenu des messages. | +| Messages de groupe ignorés | Vérifiez dans les journaux les rejets par filtrage de mention | Mentionnez le bot ou définissez `requireMention: false` pour le serveur/le canal. | +| Réponses DM absentes | `openclaw pairing list discord` | Approuvez l’association DM ou ajustez la politique DM. | -Dépannage complet : [/channels/discord#troubleshooting](/channels/discord#troubleshooting) +Dépannage complet : [/channels/discord#troubleshooting](/fr/channels/discord#troubleshooting) ## Slack -### Signatures de panne Slack +### Signatures d’échec Slack -| Symptôme | Vérification la plus rapide | Correctif | -| -------------------------------------- | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Mode socket connecté mais aucune réponse | `openclaw channels status --probe` | Vérifiez le jeton d’application + le jeton de bot et les scopes requis ; surveillez `botTokenStatus` / `appTokenStatus = configured_unavailable` dans les configurations basées sur SecretRef. | -| DMs bloqués | `openclaw pairing list slack` | Approuvez l’appairage ou assouplissez la politique DM. | -| Message de canal ignoré | Vérifiez `groupPolicy` et la liste d’autorisation des canaux | Autorisez le canal ou changez la politique en `open`. | +| Symptôme | Vérification la plus rapide | Correctif | +| --------------------------------------- | ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | +| Socket mode connecté mais aucune réponse | `openclaw channels status --probe` | Vérifiez le jeton d’application + le jeton du bot et les permissions requises ; surveillez `botTokenStatus` / `appTokenStatus = configured_unavailable` dans les configurations basées sur SecretRef. | +| DMs bloqués | `openclaw pairing list slack` | Approuvez l’association ou assouplissez la politique DM. | +| Message de canal ignoré | Vérifiez `groupPolicy` et la liste d’autorisation des canaux | Autorisez le canal ou basculez la politique sur `open`. | -Dépannage complet : [/channels/slack#troubleshooting](/channels/slack#troubleshooting) +Dépannage complet : [/channels/slack#troubleshooting](/fr/channels/slack#troubleshooting) ## iMessage et BlueBubbles -### Signatures de panne iMessage et BlueBubbles +### Signatures d’échec iMessage et BlueBubbles -| Symptôme | Vérification la plus rapide | Correctif | -| -------------------------------- | ------------------------------------------------------ | ----------------------------------------------------- | -| Aucun événement entrant | Vérifiez l’accessibilité du webhook/serveur et les autorisations de l’application | Corrigez l’URL du webhook ou l’état du serveur BlueBubbles. | +| Symptôme | Vérification la plus rapide | Correctif | +| --------------------------------- | ------------------------------------------------------------- | ----------------------------------------------------- | +| Aucun événement entrant | Vérifiez l’accessibilité du Webhook/serveur et les autorisations de l’application | Corrigez l’URL du Webhook ou l’état du serveur BlueBubbles. | | Peut envoyer mais ne reçoit pas sur macOS | Vérifiez les autorisations de confidentialité macOS pour l’automatisation de Messages | Réaccordez les autorisations TCC et redémarrez le processus du canal. | -| Expéditeur DM bloqué | `openclaw pairing list imessage` ou `openclaw pairing list bluebubbles` | Approuvez l’appairage ou mettez à jour la liste d’autorisation. | +| Expéditeur DM bloqué | `openclaw pairing list imessage` ou `openclaw pairing list bluebubbles` | Approuvez l’association ou mettez à jour la liste d’autorisation. | -Dépannage complet : +Dépannage complet : -- [/channels/imessage#troubleshooting](/channels/imessage#troubleshooting) -- [/channels/bluebubbles#troubleshooting](/channels/bluebubbles#troubleshooting) +- [/channels/imessage#troubleshooting](/fr/channels/imessage#troubleshooting) +- [/channels/bluebubbles#troubleshooting](/fr/channels/bluebubbles#troubleshooting) ## Signal -### Signatures de panne Signal +### Signatures d’échec Signal -| Symptôme | Vérification la plus rapide | Correctif | -| ------------------------------ | --------------------------------------- | -------------------------------------------------------- | -| Daemon joignable mais bot silencieux | `openclaw channels status --probe` | Vérifiez l’URL/le compte du daemon `signal-cli` et le mode de réception. | -| DM bloqué | `openclaw pairing list signal` | Approuvez l’expéditeur ou ajustez la politique DM. | -| Les réponses de groupe ne se déclenchent pas | Vérifiez la liste d’autorisation des groupes et les motifs de mention | Ajoutez l’expéditeur/le groupe ou assouplissez le filtrage. | +| Symptôme | Vérification la plus rapide | Correctif | +| -------------------------------- | ----------------------------------------- | ------------------------------------------------------------ | +| Démon accessible mais bot silencieux | `openclaw channels status --probe` | Vérifiez l’URL/le compte du démon `signal-cli` et le mode de réception. | +| DM bloqué | `openclaw pairing list signal` | Approuvez l’expéditeur ou ajustez la politique DM. | +| Les réponses de groupe ne se déclenchent pas | Vérifiez la liste d’autorisation du groupe et les motifs de mention | Ajoutez l’expéditeur/le groupe ou assouplissez le filtrage. | -Dépannage complet : [/channels/signal#troubleshooting](/channels/signal#troubleshooting) +Dépannage complet : [/channels/signal#troubleshooting](/fr/channels/signal#troubleshooting) ## QQ Bot -### Signatures de panne QQ Bot +### Signatures d’échec QQ Bot -| Symptôme | Vérification la plus rapide | Correctif | -| ------------------------------ | ------------------------------------------ | -------------------------------------------------------------- | -| Le bot répond "gone to Mars" | Vérifiez `appId` et `clientSecret` dans la configuration | Définissez les identifiants ou redémarrez la gateway. | -| Aucun message entrant | `openclaw channels status --probe` | Vérifiez les identifiants sur la QQ Open Platform. | -| La voix n’est pas transcrite | Vérifiez la configuration du fournisseur STT | Configurez `channels.qqbot.stt` ou `tools.media.audio`. | +| Symptôme | Vérification la plus rapide | Correctif | +| -------------------------------- | ------------------------------------------- | ------------------------------------------------------------- | +| Le bot répond « gone to Mars » | Vérifiez `appId` et `clientSecret` dans la configuration | Définissez les identifiants ou redémarrez la Gateway. | +| Aucun message entrant | `openclaw channels status --probe` | Vérifiez les identifiants sur la QQ Open Platform. | +| La voix n’est pas transcrite | Vérifiez la configuration du fournisseur STT | Configurez `channels.qqbot.stt` ou `tools.media.audio`. | | Les messages proactifs n’arrivent pas | Vérifiez les exigences d’interaction de la plateforme QQ | QQ peut bloquer les messages initiés par le bot sans interaction récente. | -Dépannage complet : [/channels/qqbot#troubleshooting](/channels/qqbot#troubleshooting) +Dépannage complet : [/channels/qqbot#troubleshooting](/fr/channels/qqbot#troubleshooting) ## Matrix -### Signatures de panne Matrix +### Signatures d’échec Matrix -| Symptôme | Vérification la plus rapide | Correctif | -| ----------------------------------- | --------------------------------------- | -------------------------------------------------------------------------- | -| Connecté mais ignore les messages du salon | `openclaw channels status --probe` | Vérifiez `groupPolicy`, la liste d’autorisation des salons et le filtrage par mention. | -| Les DMs ne sont pas traités | `openclaw pairing list matrix` | Approuvez l’expéditeur ou ajustez la politique DM. | -| Les salons chiffrés échouent | `openclaw matrix verify status` | Revérifiez l’appareil, puis vérifiez `openclaw matrix verify backup status`. | -| La restauration de sauvegarde est en attente/cassée | `openclaw matrix verify backup status` | Exécutez `openclaw matrix verify backup restore` ou relancez avec une clé de récupération. | -| La signature croisée/bootstrap semble incorrecte | `openclaw matrix verify bootstrap` | Réparez le stockage des secrets, la signature croisée et l’état de sauvegarde en un seul passage. | +| Symptôme | Vérification la plus rapide | Correctif | +| ------------------------------------ | -------------------------------------- | ------------------------------------------------------------------------- | +| Connecté mais ignore les messages de salon | `openclaw channels status --probe` | Vérifiez `groupPolicy`, la liste d’autorisation des salons et le filtrage par mention. | +| Les DMs ne sont pas traités | `openclaw pairing list matrix` | Approuvez l’expéditeur ou ajustez la politique DM. | +| Échec des salons chiffrés | `openclaw matrix verify status` | Revérifiez l’appareil, puis consultez `openclaw matrix verify backup status`. | +| La restauration de sauvegarde est en attente/cassée | `openclaw matrix verify backup status` | Exécutez `openclaw matrix verify backup restore` ou relancez avec une clé de récupération. | +| L’apparence de la signature croisée/du bootstrap semble incorrecte | `openclaw matrix verify bootstrap` | Réparez en une seule passe le stockage des secrets, la signature croisée et l’état de la sauvegarde. | -Configuration et installation complètes : [Matrix](/channels/matrix) +Configuration et installation complètes : [Matrix](/fr/channels/matrix) diff --git a/docs/fr/concepts/qa-e2e-automation.md b/docs/fr/concepts/qa-e2e-automation.md index 38d95f991..da6548ab5 100644 --- a/docs/fr/concepts/qa-e2e-automation.md +++ b/docs/fr/concepts/qa-e2e-automation.md @@ -1,37 +1,37 @@ --- read_when: - - Extension de qa-lab ou de qa-channel + - Extension de qa-lab ou qa-channel - Ajout de scénarios QA adossés au dépôt - - Création d’une automatisation QA de plus grand réalisme autour du tableau de bord Gateway + - Création d’une automatisation QA plus réaliste autour du tableau de bord Gateway summary: Forme de l’automatisation QA privée pour qa-lab, qa-channel, les scénarios initialisés et les rapports de protocole title: Automatisation QA E2E x-i18n: - generated_at: "2026-04-18T06:43:38Z" + generated_at: "2026-04-20T07:05:28Z" model: gpt-5.4 provider: openai - source_hash: adf8c5f74e8fabdc8e9fd7ecd41afce8b60354c7dd24d92ac926d3c527927cd4 + source_hash: 34245ce871356caeab0d9e0eeeaa9fb4e408920a4a97ad27567fa365d8db17c7 source_path: concepts/qa-e2e-automation.md workflow: 15 --- # Automatisation QA E2E -La pile QA privée a pour objectif d’exercer OpenClaw d’une manière plus réaliste, -façonnée comme un canal, qu’un simple test unitaire ne peut le faire. +La pile QA privée est conçue pour exercer OpenClaw d’une manière plus réaliste, +calquée sur les canaux, qu’un simple test unitaire ne peut le faire. Éléments actuels : -- `extensions/qa-channel` : canal de messages synthétique avec des surfaces de MP, canal, fil, - réaction, modification et suppression. +- `extensions/qa-channel` : canal de messages synthétique avec des surfaces pour les DM, canaux, fils, + réactions, modifications et suppressions. - `extensions/qa-lab` : interface de débogage et bus QA pour observer la transcription, injecter des messages entrants et exporter un rapport Markdown. -- `qa/` : ressources initiales adossées au dépôt pour la tâche de lancement et les - scénarios QA de référence. +- `qa/` : ressources d’initialisation adossées au dépôt pour la tâche de démarrage et les + scénarios QA de base. -Le flux opérateur QA actuel est un site QA à deux volets : +Le flux opérateur QA actuel est un site QA en deux panneaux : - Gauche : tableau de bord Gateway (Control UI) avec l’agent. -- Droite : QA Lab, affichant une transcription de type Slack et le plan de scénario. +- Droite : QA Lab, affichant la transcription de type Slack et le plan du scénario. Exécutez-le avec : @@ -40,11 +40,11 @@ pnpm qa:lab:up ``` Cela construit le site QA, démarre la voie Gateway adossée à Docker et expose la -page QA Lab où un opérateur ou une boucle d’automatisation peut donner à l’agent une -mission QA, observer le comportement réel du canal et consigner ce qui a fonctionné, échoué -ou est resté bloqué. +page QA Lab où un opérateur ou une boucle d’automatisation peut confier à l’agent une mission QA, +observer le comportement réel du canal et consigner ce qui a fonctionné, échoué ou +est resté bloqué. -Pour une itération plus rapide sur l’interface de QA Lab sans reconstruire l’image Docker à chaque fois, +Pour une itération plus rapide sur l’interface QA Lab sans reconstruire l’image Docker à chaque fois, démarrez la pile avec un bundle QA Lab monté par liaison : ```bash @@ -57,50 +57,52 @@ pnpm qa:lab:watch `qa:lab:up:fast` conserve les services Docker sur une image préconstruite et monte par liaison `extensions/qa-lab/web/dist` dans le conteneur `qa-lab`. `qa:lab:watch` reconstruit ce bundle à chaque modification, et le navigateur se recharge automatiquement lorsque le hachage -des ressources de QA Lab change. +des ressources QA Lab change. -Pour une voie smoke Matrix avec transport réel, exécutez : +Pour une voie de smoke test Matrix sur transport réel, exécutez : ```bash pnpm openclaw qa matrix ``` -Cette voie provisionne un homeserver Tuwunel jetable dans Docker, enregistre -des utilisateurs temporaires de pilote, SUT et observateur, crée un salon privé, puis exécute -le vrai plugin Matrix dans un processus enfant QA Gateway. La voie de transport en direct conserve -la configuration enfant limitée au transport testé, afin que Matrix s’exécute sans +Cette voie provisionne un homeserver Tuwunel jetable dans Docker, enregistre des +utilisateurs temporaires driver, SUT et observateur, crée un salon privé, puis exécute +le véritable Plugin Matrix dans un enfant Gateway QA. La voie de transport réel garde +la configuration enfant limitée au transport testé, afin que Matrix fonctionne sans `qa-channel` dans la configuration enfant. Elle écrit les artefacts de rapport structurés et un journal combiné stdout/stderr dans le répertoire de sortie Matrix QA sélectionné. Pour -capturer également la sortie de construction/lancement externe de `scripts/run-node.mjs`, définissez +capturer également la sortie de build/lancement externe de `scripts/run-node.mjs`, définissez `OPENCLAW_RUN_NODE_OUTPUT_LOG=` vers un fichier journal local au dépôt. -Pour une voie smoke Telegram avec transport réel, exécutez : +Pour une voie de smoke test Telegram sur transport réel, exécutez : ```bash pnpm openclaw qa telegram ``` -Cette voie cible un vrai groupe Telegram privé au lieu de provisionner un -serveur jetable. Elle nécessite `OPENCLAW_QA_TELEGRAM_GROUP_ID`, +Cette voie cible un véritable groupe privé Telegram au lieu de provisionner un serveur +jetable. Elle nécessite `OPENCLAW_QA_TELEGRAM_GROUP_ID`, `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` et `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`, ainsi que deux bots distincts dans le même groupe privé. Le bot SUT doit avoir un nom d’utilisateur Telegram, et l’observation -bot à bot fonctionne au mieux lorsque les deux bots ont le mode de communication -bot à bot activé dans `@BotFather`. +bot à bot fonctionne mieux lorsque les deux bots ont le mode Bot-to-Bot Communication +activé dans `@BotFather`. +La commande se termine avec un code de sortie non nul lorsqu’un scénario échoue. Utilisez `--allow-failures` lorsque +vous voulez les artefacts sans code de sortie en échec. -Les voies de transport en direct partagent désormais un contrat plus restreint au lieu que chacune invente -sa propre forme de liste de scénarios. +Les voies de transport réel partagent désormais un contrat plus réduit au lieu d’inventer +chacune leur propre forme de liste de scénarios : -`qa-channel` reste la suite large de comportement produit synthétique et ne fait pas partie -de la matrice de couverture de transport en direct. +`qa-channel` reste la suite large de comportements produit synthétiques et ne fait pas partie +de la matrice de couverture des transports réels. -| Voie | Canary | Filtrage des mentions | Blocage de la liste d’autorisation | Réponse de niveau supérieur | Reprise après redémarrage | Suivi dans le fil | Isolation du fil | Observation des réactions | Commande help | -| -------- | ------ | --------------------- | ---------------------------------- | --------------------------- | ------------------------- | ----------------- | ---------------- | ------------------------- | ------------- | -| Matrix | x | x | x | x | x | x | x | x | | -| Telegram | x | | | | | | | | x | +| Voie | Canary | Contrôle des mentions | Blocage par liste d’autorisation | Réponse de premier niveau | Reprise après redémarrage | Suivi dans un fil | Isolation des fils | Observation des réactions | Commande d’aide | +| -------- | ------ | --------------------- | -------------------------------- | ------------------------- | ------------------------- | ----------------- | ------------------ | ------------------------- | --------------- | +| Matrix | x | x | x | x | x | x | x | x | | +| Telegram | x | | | | | | | | x | -Cela permet de conserver `qa-channel` comme suite large de comportement produit tandis que Matrix, -Telegram et les futurs transports en direct partagent une checklist explicite de contrat de transport. +Cela permet de conserver `qa-channel` comme la suite large de comportements produit, tandis que Matrix, +Telegram et les futurs transports réels partagent une liste de contrôle explicite de contrat de transport. Pour une voie VM Linux jetable sans faire entrer Docker dans le chemin QA, exécutez : @@ -108,27 +110,29 @@ Pour une voie VM Linux jetable sans faire entrer Docker dans le chemin QA, exéc pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline ``` -Cela démarre un invité Multipass neuf, installe les dépendances, construit OpenClaw -dans l’invité, exécute `qa suite`, puis copie le rapport QA et le -résumé habituels vers `.artifacts/qa-e2e/...` sur l’hôte. +Cela démarre un nouvel invité Multipass, installe les dépendances, construit OpenClaw +dans l’invité, exécute `qa suite`, puis copie le rapport QA normal et le résumé dans +`.artifacts/qa-e2e/...` sur l’hôte. Cela réutilise le même comportement de sélection de scénarios que `qa suite` sur l’hôte. -Les exécutions de suite sur hôte et Multipass exécutent plusieurs scénarios sélectionnés en parallèle -avec des workers Gateway isolés par défaut, jusqu’à 64 workers ou au nombre -de scénarios sélectionnés. Utilisez `--concurrency ` pour ajuster le nombre de workers, ou -`--concurrency 1` pour une exécution en série. -Les exécutions en direct transmettent les entrées d’auth QA prises en charge qui sont pratiques pour -l’invité : clés de fournisseur basées sur l’environnement, chemin de configuration du fournisseur QA en direct, et -`CODEX_HOME` lorsqu’il est présent. Gardez `--output-dir` sous la racine du dépôt afin que l’invité -puisse réécrire via l’espace de travail monté. +Les exécutions de suite sur l’hôte et sous Multipass exécutent plusieurs scénarios sélectionnés en parallèle +avec des workers Gateway isolés par défaut. `qa-channel` utilise par défaut une concurrence de +4, plafonnée par le nombre de scénarios sélectionnés. Utilisez `--concurrency ` pour ajuster +le nombre de workers, ou `--concurrency 1` pour une exécution en série. +La commande se termine avec un code de sortie non nul lorsqu’un scénario échoue. Utilisez `--allow-failures` lorsque +vous voulez les artefacts sans code de sortie en échec. +Les exécutions live transmettent les entrées d’auth QA prises en charge qui sont pratiques pour +l’invité : clés de fournisseur basées sur l’environnement, chemin de configuration du fournisseur live QA, et +`CODEX_HOME` lorsqu’il est présent. Conservez `--output-dir` sous la racine du dépôt afin que l’invité +puisse écrire en retour via l’espace de travail monté. -## Ressources initiales adossées au dépôt +## Amorces adossées au dépôt -Les ressources initiales se trouvent dans `qa/` : +Les ressources d’initialisation se trouvent dans `qa/` : - `qa/scenarios/index.md` - `qa/scenarios//*.md` -Elles sont volontairement dans git pour que le plan QA soit visible à la fois des humains et de +Elles sont intentionnellement versionnées dans git afin que le plan QA soit visible à la fois pour les humains et pour l’agent. `qa-lab` doit rester un exécuteur Markdown générique. Chaque fichier Markdown de scénario est @@ -136,76 +140,75 @@ la source de vérité pour une exécution de test et doit définir : - les métadonnées du scénario - des métadonnées facultatives de catégorie, capacité, voie et risque -- les références de documentation et de code -- des exigences de plugin facultatives -- un patch de configuration Gateway facultatif +- des références de documentation et de code +- des exigences facultatives de Plugin +- un correctif facultatif de configuration Gateway - le `qa-flow` exécutable -La surface d’exécution réutilisable qui sous-tend `qa-flow` peut rester générique -et transversale. Par exemple, les scénarios Markdown peuvent combiner des helpers côté -transport avec des helpers côté navigateur qui pilotent la Control UI intégrée via la -jointure Gateway `browser.request` sans ajouter d’exécuteur spécifique. +La surface d’exécution réutilisable qui sous-tend `qa-flow` est autorisée à rester générique +et transversale. Par exemple, les scénarios Markdown peuvent combiner des +helpers côté transport avec des helpers côté navigateur qui pilotent la Control UI embarquée via la +surface Gateway `browser.request` sans ajouter d’exécuteur à cas particulier. Les fichiers de scénario doivent être regroupés par capacité produit plutôt que par dossier -de l’arborescence source. Gardez les ID de scénario stables lorsque les fichiers sont déplacés ; utilisez -`docsRefs` et `codeRefs` pour la traçabilité de l’implémentation. +de l’arborescence source. Gardez les ID de scénario stables quand les fichiers changent d’emplacement ; utilisez `docsRefs` et `codeRefs` +pour la traçabilité d’implémentation. -La liste de référence doit rester suffisamment large pour couvrir : +La liste de base doit rester assez large pour couvrir : -- les MP et le chat en canal -- le comportement des fils -- le cycle de vie des actions sur les messages -- les rappels Cron -- le rappel mémoire -- le changement de modèle -- le transfert à un sous-agent -- la lecture du dépôt et de la documentation -- une petite tâche de build telle que Lobster Invaders +- chat DM et canal +- comportement des fils +- cycle de vie des actions sur les messages +- rappels Cron +- rappel de mémoire +- changement de modèle +- transfert à un sous-agent +- lecture du dépôt et de la documentation +- une petite tâche de build comme Lobster Invaders -## Voies mock de fournisseur +## Voies de mock de fournisseur -`qa suite` dispose de deux voies mock locales de fournisseur : +`qa suite` possède deux voies locales de mock de fournisseur : -- `mock-openai` est le mock OpenClaw conscient des scénarios. Il reste la - voie mock déterministe par défaut pour la QA adossée au dépôt et les contrôles de parité. -- `aimock` démarre un serveur de fournisseur adossé à AIMock pour une couverture expérimentale de protocole, - de fixtures, d’enregistrement/relecture et de chaos. Il est additionnel et ne remplace pas +- `mock-openai` est le mock OpenClaw sensible aux scénarios. Il reste la + voie de mock déterministe par défaut pour la QA adossée au dépôt et les portes de parité. +- `aimock` démarre un serveur de fournisseur adossé à AIMock pour une couverture expérimentale du protocole, + des fixtures, de l’enregistrement/relecture et du chaos. Il est additif et ne remplace pas le répartiteur de scénarios `mock-openai`. -L’implémentation des voies de fournisseur se trouve dans `extensions/qa-lab/src/providers/`. -Chaque fournisseur possède ses valeurs par défaut, le démarrage du serveur local, la configuration -du modèle Gateway, les besoins de préparation du profil d’authentification, et les drapeaux de capacité live/mock. -Le code partagé de suite et de Gateway doit passer par le registre des fournisseurs au lieu -de brancher sur les noms des fournisseurs. +L’implémentation des voies de fournisseur se trouve sous `extensions/qa-lab/src/providers/`. +Chaque fournisseur est propriétaire de ses valeurs par défaut, du démarrage du serveur local, de la configuration du modèle Gateway, +des besoins de préparation du profil d’authentification, et des indicateurs de capacité live/mock. Le code partagé +de suite et de Gateway doit passer par le registre des fournisseurs au lieu d’effectuer des branchements sur les noms de fournisseurs. ## Adaptateurs de transport -`qa-lab` possède une jointure de transport générique pour les scénarios QA Markdown. -`qa-channel` est le premier adaptateur sur cette jointure, mais l’objectif de conception est plus large : +`qa-lab` possède une interface de transport générique pour les scénarios QA Markdown. +`qa-channel` est le premier adaptateur sur cette interface, mais l’objectif de conception est plus large : les futurs canaux réels ou synthétiques doivent se brancher sur le même exécuteur de suite au lieu d’ajouter un exécuteur QA spécifique au transport. -Au niveau de l’architecture, la séparation est la suivante : +Au niveau de l’architecture, la répartition est la suivante : -- `qa-lab` possède l’exécution générique des scénarios, la concurrence des workers, l’écriture des artefacts et le reporting. -- l’adaptateur de transport possède la configuration Gateway, l’état prêt, l’observation entrante et sortante, les actions de transport et l’état de transport normalisé. -- les fichiers de scénario Markdown sous `qa/scenarios/` définissent l’exécution de test ; `qa-lab` fournit la surface d’exécution réutilisable qui les exécute. +- `qa-lab` est responsable de l’exécution générique des scénarios, de la concurrence des workers, de l’écriture des artefacts et du reporting. +- l’adaptateur de transport est responsable de la configuration Gateway, de la disponibilité, de l’observation entrante et sortante, des actions de transport et de l’état de transport normalisé. +- les fichiers de scénario Markdown sous `qa/scenarios/` définissent l’exécution du test ; `qa-lab` fournit la surface d’exécution réutilisable qui les exécute. Les consignes d’adoption destinées aux mainteneurs pour les nouveaux adaptateurs de canal se trouvent dans [Testing](/fr/help/testing#adding-a-channel-to-qa). -## Rapports +## Reporting `qa-lab` exporte un rapport de protocole Markdown à partir de la chronologie observée du bus. -Le rapport doit répondre à : +Le rapport doit répondre à ces questions : - Ce qui a fonctionné - Ce qui a échoué - Ce qui est resté bloqué - Quels scénarios de suivi valent la peine d’être ajoutés -Pour les vérifications de caractère et de style, exécutez le même scénario sur plusieurs références -de modèles live et écrivez un rapport Markdown évalué : +Pour les vérifications de caractère et de style, exécutez le même scénario sur plusieurs références de modèles live +et rédigez un rapport Markdown évalué : ```bash pnpm openclaw qa character-eval \ @@ -224,31 +227,31 @@ pnpm openclaw qa character-eval \ --judge-concurrency 16 ``` -La commande exécute des processus enfants QA Gateway locaux, pas Docker. Les -scénarios d’évaluation du caractère doivent définir le persona via `SOUL.md`, puis exécuter des tours -utilisateur ordinaires tels que le chat, l’aide sur l’espace de travail et de petites tâches sur des fichiers. Le modèle -candidat ne doit pas être informé qu’il est en cours d’évaluation. La commande préserve chaque transcription complète, -enregistre les statistiques d’exécution de base, puis demande aux modèles juges en mode fast avec +La commande exécute des processus enfants locaux QA Gateway, pas Docker. Les scénarios d’évaluation du caractère +doivent définir la persona via `SOUL.md`, puis exécuter des tours utilisateur ordinaires +comme du chat, de l’aide sur l’espace de travail et de petites tâches sur des fichiers. Le modèle candidat +ne doit pas être informé qu’il est en cours d’évaluation. La commande préserve chaque transcription complète, +enregistre des statistiques d’exécution de base, puis demande aux modèles juges en mode rapide avec un raisonnement `xhigh` de classer les exécutions selon le naturel, l’ambiance et l’humour. -Utilisez `--blind-judge-models` lors de la comparaison de fournisseurs : l’invite du juge reçoit toujours -chaque transcription et état d’exécution, mais les références candidates sont remplacées par des -étiquettes neutres telles que `candidate-01` ; le rapport remappe les classements aux vraies références après +Utilisez `--blind-judge-models` lorsque vous comparez des fournisseurs : l’invite du juge reçoit toujours +chaque transcription et statut d’exécution, mais les références candidates sont remplacées par des +étiquettes neutres comme `candidate-01` ; le rapport remappe les classements vers les références réelles après l’analyse. -Les exécutions candidates utilisent par défaut un niveau de réflexion `high`, avec `xhigh` pour les modèles OpenAI qui -le prennent en charge. Remplacez un candidat spécifique en ligne avec -`--model provider/model,thinking=`. `--thinking ` définit toujours une +Les exécutions candidates utilisent par défaut le niveau de réflexion `high`, avec `xhigh` pour les modèles OpenAI qui +le prennent en charge. Remplacez un candidat précis en ligne avec +`--model provider/model,thinking=`. `--thinking ` continue de définir une valeur de repli globale, et l’ancienne forme `--model-thinking ` est conservée pour compatibilité. -Les références candidates OpenAI utilisent par défaut le mode fast afin que le traitement prioritaire soit utilisé là où +Les références candidates OpenAI utilisent par défaut le mode rapide afin d’employer le traitement prioritaire lorsque le fournisseur le prend en charge. Ajoutez `,fast`, `,no-fast` ou `,fast=false` en ligne lorsqu’un -candidat ou juge donné a besoin d’une substitution. Passez `--fast` uniquement si vous souhaitez -forcer le mode fast pour tous les modèles candidats. Les durées des candidats et des juges sont -enregistrées dans le rapport pour l’analyse comparative, mais les invites des juges indiquent explicitement -de ne pas classer selon la vitesse. +candidat ou juge particulier a besoin d’une dérogation. Passez `--fast` uniquement si vous souhaitez +forcer le mode rapide pour tous les modèles candidats. Les durées des candidats et des juges sont +enregistrées dans le rapport pour l’analyse comparative, mais les invites des juges indiquent explicitement de +ne pas classer selon la vitesse. Les exécutions des modèles candidats et juges utilisent toutes deux par défaut une concurrence de 16. Réduisez -`--concurrency` ou `--judge-concurrency` lorsque les limites des fournisseurs ou la pression sur la Gateway locale +`--concurrency` ou `--judge-concurrency` lorsque les limites du fournisseur ou la pression sur la Gateway locale rendent une exécution trop bruyante. -Lorsqu’aucun `--model` candidat n’est transmis, l’évaluation du caractère utilise par défaut +Lorsqu’aucun candidat `--model` n’est transmis, l’évaluation du caractère utilise par défaut `openai/gpt-5.4`, `openai/gpt-5.2`, `openai/gpt-5`, `anthropic/claude-opus-4-6`, `anthropic/claude-sonnet-4-6`, `zai/glm-5.1`, `moonshot/kimi-k2.5`, et diff --git a/docs/fr/gateway/configuration-reference.md b/docs/fr/gateway/configuration-reference.md index 6c8462900..37adfcca1 100644 --- a/docs/fr/gateway/configuration-reference.md +++ b/docs/fr/gateway/configuration-reference.md @@ -1,14 +1,14 @@ --- read_when: - - Vous avez besoin de la sémantique exacte de la configuration au niveau des champs ou des valeurs par défaut. + - Vous avez besoin de la sémantique exacte des champs de configuration ou des valeurs par défaut. - Vous validez des blocs de configuration de canal, de modèle, de Gateway ou d’outil. -summary: Référence de configuration du Gateway pour les clés OpenClaw principales, les valeurs par défaut et les liens vers les références dédiées des sous-systèmes +summary: Référence de configuration de Gateway pour les clés principales d’OpenClaw, les valeurs par défaut et les liens vers les références dédiées des sous-systèmes title: Référence de configuration x-i18n: - generated_at: "2026-04-18T06:43:34Z" + generated_at: "2026-04-20T07:05:25Z" model: gpt-5.4 provider: openai - source_hash: 4b504c9c6b47d7a327a0acf6934561c9b2606c01cc8ebe5526ccde73033d759f + source_hash: 22b10f1f133374cd29ef4a5ec4fb9c9938eb51184ad82e1aa2e5f6f7af58585e source_path: gateway/configuration-reference.md workflow: 15 --- @@ -17,19 +17,19 @@ x-i18n: Référence de configuration principale pour `~/.openclaw/openclaw.json`. Pour une vue d’ensemble orientée tâches, voir [Configuration](/fr/gateway/configuration). -Cette page couvre les principales surfaces de configuration d’OpenClaw et renvoie ailleurs lorsqu’un sous-système dispose de sa propre référence plus détaillée. Elle **n’essaie pas** d’intégrer sur une seule page chaque catalogue de commandes propre à un canal/Plugin ni chaque réglage approfondi de mémoire/QMD. +Cette page couvre les principales surfaces de configuration d’OpenClaw et renvoie ailleurs lorsqu’un sous-système dispose de sa propre référence plus détaillée. Elle **n’essaie pas** d’intégrer sur une seule page chaque catalogue de commandes propre à un canal/Plugin, ni chaque paramètre avancé de mémoire/QMD. Source de vérité du code : -- `openclaw config schema` affiche le schéma JSON actif utilisé pour la validation et l’interface utilisateur Control, avec les métadonnées bundle/plugin/channel fusionnées lorsqu’elles sont disponibles -- `config.schema.lookup` renvoie un nœud de schéma circonscrit à un chemin pour les outils d’exploration détaillée -- `pnpm config:docs:check` / `pnpm config:docs:gen` valident le hachage de base des documents de configuration par rapport à la surface de schéma actuelle +- `openclaw config schema` affiche le JSON Schema en direct utilisé pour la validation et l’interface Control UI, avec les métadonnées des plugins/canaux/Plugins groupés fusionnées lorsqu’elles sont disponibles +- `config.schema.lookup` renvoie un nœud de schéma limité à un chemin pour les outils d’exploration détaillée +- `pnpm config:docs:check` / `pnpm config:docs:gen` valident le hachage de référence de la documentation de configuration par rapport à la surface de schéma actuelle Références détaillées dédiées : - [Référence de configuration de la mémoire](/fr/reference/memory-config) pour `agents.defaults.memorySearch.*`, `memory.qmd.*`, `memory.citations` et la configuration de Dreaming sous `plugins.entries.memory-core.config.dreaming` -- [Commandes slash](/fr/tools/slash-commands) pour le catalogue actuel des commandes intégrées + bundle -- les pages du canal/Plugin propriétaire pour les surfaces de commande propres au canal +- [Commandes slash](/fr/tools/slash-commands) pour le catalogue actuel des commandes intégrées + groupées +- pages du canal/Plugin propriétaire pour les surfaces de commandes spécifiques au canal Le format de configuration est **JSON5** (commentaires + virgules finales autorisés). Tous les champs sont facultatifs — OpenClaw utilise des valeurs par défaut sûres lorsqu’ils sont omis. @@ -39,32 +39,32 @@ Le format de configuration est **JSON5** (commentaires + virgules finales autori Chaque canal démarre automatiquement lorsque sa section de configuration existe (sauf si `enabled: false`). -### Accès DM et groupe +### Accès DM et groupes -Tous les canaux prennent en charge des politiques de DM et des politiques de groupe : +Tous les canaux prennent en charge les stratégies DM et les stratégies de groupe : -| Politique de DM | Comportement | -| ------------------- | --------------------------------------------------------------- | +| Stratégie DM | Comportement | +| ------------------- | ------------------------------------------------------------- | | `pairing` (par défaut) | Les expéditeurs inconnus reçoivent un code d’appairage à usage unique ; le propriétaire doit approuver | | `allowlist` | Uniquement les expéditeurs dans `allowFrom` (ou le stockage d’autorisation appairé) | -| `open` | Autoriser tous les DM entrants (nécessite `allowFrom: ["*"]`) | -| `disabled` | Ignorer tous les DM entrants | +| `open` | Autorise tous les DM entrants (nécessite `allowFrom: ["*"]`) | +| `disabled` | Ignore tous les DM entrants | -| Politique de groupe | Comportement | +| Stratégie de groupe | Comportement | | --------------------- | ----------------------------------------------------- | | `allowlist` (par défaut) | Uniquement les groupes correspondant à la liste d’autorisation configurée | -| `open` | Contourner les listes d’autorisation de groupe (le filtrage par mention s’applique toujours) | -| `disabled` | Bloquer tous les messages de groupe/salon | +| `open` | Ignore les listes d’autorisation de groupe (le filtrage par mention s’applique toujours) | +| `disabled` | Bloque tous les messages de groupe/salon | -`channels.defaults.groupPolicy` définit la valeur par défaut lorsque `groupPolicy` d’un fournisseur n’est pas défini. +`channels.defaults.groupPolicy` définit la valeur par défaut lorsque le `groupPolicy` d’un fournisseur n’est pas défini. Les codes d’appairage expirent après 1 heure. Les demandes d’appairage DM en attente sont limitées à **3 par canal**. -Si un bloc fournisseur est entièrement absent (`channels.` absent), la politique de groupe d’exécution revient à `allowlist` (échec en mode fermé) avec un avertissement au démarrage. +Si un bloc fournisseur est entièrement absent (`channels.` absent), la stratégie de groupe à l’exécution retombe sur `allowlist` (échec fermé) avec un avertissement au démarrage. ### Remplacements de modèle par canal -Utilisez `channels.modelByChannel` pour épingler des ID de canal spécifiques à un modèle. Les valeurs acceptent `provider/model` ou des alias de modèle configurés. Le mappage de canal s’applique lorsqu’une session n’a pas déjà un remplacement de modèle (par exemple, défini via `/model`). +Utilisez `channels.modelByChannel` pour épingler des identifiants de canal spécifiques à un modèle. Les valeurs acceptent `provider/model` ou des alias de modèle configurés. Le mappage de canal s’applique lorsqu’une session n’a pas déjà un remplacement de modèle (par exemple défini via `/model`). ```json5 { @@ -87,7 +87,7 @@ Utilisez `channels.modelByChannel` pour épingler des ID de canal spécifiques ### Valeurs par défaut des canaux et Heartbeat -Utilisez `channels.defaults` pour le comportement partagé de politique de groupe et de Heartbeat entre les fournisseurs : +Utilisez `channels.defaults` pour le comportement partagé de stratégie de groupe et de Heartbeat entre les fournisseurs : ```json5 { @@ -105,15 +105,15 @@ Utilisez `channels.defaults` pour le comportement partagé de politique de group } ``` -- `channels.defaults.groupPolicy` : politique de groupe de repli lorsqu’un `groupPolicy` au niveau fournisseur n’est pas défini. -- `channels.defaults.contextVisibility` : mode de visibilité du contexte supplémentaire par défaut pour tous les canaux. Valeurs : `all` (par défaut, inclure tout le contexte de citation/fil/historique), `allowlist` (inclure uniquement le contexte des expéditeurs autorisés), `allowlist_quote` (identique à allowlist mais conserve le contexte explicite de citation/réponse). Remplacement par canal : `channels..contextVisibility`. -- `channels.defaults.heartbeat.showOk` : inclure les statuts de canaux sains dans la sortie Heartbeat. -- `channels.defaults.heartbeat.showAlerts` : inclure les statuts dégradés/en erreur dans la sortie Heartbeat. +- `channels.defaults.groupPolicy` : stratégie de groupe de repli lorsqu’un `groupPolicy` au niveau du fournisseur n’est pas défini. +- `channels.defaults.contextVisibility` : mode de visibilité du contexte supplémentaire par défaut pour tous les canaux. Valeurs : `all` (par défaut, inclure tout le contexte cité/de fil/d’historique), `allowlist` (inclure uniquement le contexte provenant d’expéditeurs autorisés), `allowlist_quote` (identique à allowlist mais conserve le contexte explicite de citation/réponse). Remplacement par canal : `channels..contextVisibility`. +- `channels.defaults.heartbeat.showOk` : inclure les états de canal sains dans la sortie Heartbeat. +- `channels.defaults.heartbeat.showAlerts` : inclure les états dégradés/en erreur dans la sortie Heartbeat. - `channels.defaults.heartbeat.useIndicator` : afficher une sortie Heartbeat compacte de type indicateur. ### WhatsApp -WhatsApp fonctionne via le canal web du Gateway (Baileys Web). Il démarre automatiquement lorsqu’une session liée existe. +WhatsApp fonctionne via le canal web de la Gateway (Baileys Web). Il démarre automatiquement lorsqu’une session liée existe. ```json5 { @@ -124,7 +124,7 @@ WhatsApp fonctionne via le canal web du Gateway (Baileys Web). Il démarre autom textChunkLimit: 4000, chunkMode: "length", // length | newline mediaMaxMb: 50, - sendReadReceipts: true, // coches bleues (false en mode auto-discussion) + sendReadReceipts: true, // blue ticks (false in self-chat mode) groups: { "*": { requireMention: true }, }, @@ -164,9 +164,9 @@ WhatsApp fonctionne via le canal web du Gateway (Baileys Web). Il démarre autom } ``` -- Les commandes sortantes utilisent par défaut le compte `default` s’il est présent ; sinon, le premier ID de compte configuré (trié). -- `channels.whatsapp.defaultAccount` facultatif remplace cette sélection de compte par défaut de repli lorsqu’il correspond à un ID de compte configuré. -- L’ancien répertoire d’authentification Baileys mono-compte est migré par `openclaw doctor` vers `whatsapp/default`. +- Les commandes sortantes utilisent par défaut le compte `default` s’il est présent ; sinon, le premier identifiant de compte configuré (trié). +- `channels.whatsapp.defaultAccount` facultatif remplace cette sélection de compte par défaut de repli lorsqu’il correspond à un identifiant de compte configuré. +- L’ancien répertoire d’authentification Baileys à compte unique est migré par `openclaw doctor` vers `whatsapp/default`. - Remplacements par compte : `channels.whatsapp.accounts..sendReadReceipts`, `channels.whatsapp.accounts..dmPolicy`, `channels.whatsapp.accounts..allowFrom`. @@ -225,13 +225,13 @@ WhatsApp fonctionne via le canal web du Gateway (Baileys Web). Il démarre autom } ``` -- Jeton du bot : `channels.telegram.botToken` ou `channels.telegram.tokenFile` (fichier ordinaire uniquement ; les liens symboliques sont rejetés), avec `TELEGRAM_BOT_TOKEN` comme repli pour le compte par défaut. -- `channels.telegram.defaultAccount` facultatif remplace la sélection du compte par défaut lorsqu’il correspond à un ID de compte configuré. -- Dans les configurations multi-comptes (2 ID de compte ou plus), définissez une valeur par défaut explicite (`channels.telegram.defaultAccount` ou `channels.telegram.accounts.default`) pour éviter le routage de repli ; `openclaw doctor` avertit lorsque cela est absent ou invalide. -- `configWrites: false` bloque les écritures de configuration initiées par Telegram (migrations d’ID de supergroupe, `/config set|unset`). -- Les entrées `bindings[]` de niveau supérieur avec `type: "acp"` configurent des liaisons ACP persistantes pour les sujets de forum (utilisez le format canonique `chatId:topic:topicId` dans `match.peer.id`). La sémantique des champs est partagée dans [Agents ACP](/fr/tools/acp-agents#channel-specific-settings). +- Jeton du bot : `channels.telegram.botToken` ou `channels.telegram.tokenFile` (fichier classique uniquement ; liens symboliques rejetés), avec `TELEGRAM_BOT_TOKEN` comme solution de repli pour le compte par défaut. +- `channels.telegram.defaultAccount` facultatif remplace la sélection du compte par défaut lorsqu’il correspond à un identifiant de compte configuré. +- Dans les configurations multi-comptes (2 identifiants de compte ou plus), définissez une valeur par défaut explicite (`channels.telegram.defaultAccount` ou `channels.telegram.accounts.default`) pour éviter le routage de repli ; `openclaw doctor` avertit lorsque cela est absent ou invalide. +- `configWrites: false` bloque les écritures de configuration initiées depuis Telegram (migrations d’ID de supergroupe, `/config set|unset`). +- Les entrées `bindings[]` de premier niveau avec `type: "acp"` configurent des liaisons ACP persistantes pour les sujets de forum (utilisez le format canonique `chatId:topic:topicId` dans `match.peer.id`). La sémantique des champs est partagée dans [ACP Agents](/fr/tools/acp-agents#channel-specific-settings). - Les aperçus de flux Telegram utilisent `sendMessage` + `editMessageText` (fonctionne dans les discussions directes et de groupe). -- Politique de nouvelle tentative : voir [Politique de nouvelle tentative](/fr/concepts/retry). +- Stratégie de nouvelle tentative : voir [Stratégie de nouvelle tentative](/fr/concepts/retry). ### Discord @@ -333,34 +333,34 @@ WhatsApp fonctionne via le canal web du Gateway (Baileys Web). Il démarre autom } ``` -- Jeton : `channels.discord.token`, avec `DISCORD_BOT_TOKEN` comme repli pour le compte par défaut. -- Les appels sortants directs qui fournissent un `token` Discord explicite utilisent ce jeton pour l’appel ; les paramètres de nouvelle tentative/politique du compte proviennent toujours du compte sélectionné dans l’instantané d’exécution actif. -- `channels.discord.defaultAccount` facultatif remplace la sélection du compte par défaut lorsqu’il correspond à un ID de compte configuré. -- Utilisez `user:` (DM) ou `channel:` (canal de guilde) pour les cibles de livraison ; les ID numériques seuls sont rejetés. -- Les slugs de guilde sont en minuscules avec les espaces remplacés par `-` ; les clés de canal utilisent le nom transformé en slug (sans `#`). Préférez les ID de guilde. +- Jeton : `channels.discord.token`, avec `DISCORD_BOT_TOKEN` comme solution de repli pour le compte par défaut. +- Les appels sortants directs qui fournissent un `token` Discord explicite utilisent ce jeton pour l’appel ; les paramètres de nouvelle tentative/stratégie du compte proviennent toujours du compte sélectionné dans l’instantané d’exécution actif. +- `channels.discord.defaultAccount` facultatif remplace la sélection du compte par défaut lorsqu’il correspond à un identifiant de compte configuré. +- Utilisez `user:` (DM) ou `channel:` (canal de guilde) pour les cibles de livraison ; les identifiants numériques bruts sont rejetés. +- Les slugs de guilde sont en minuscules avec les espaces remplacés par `-` ; les clés de canal utilisent le nom slugifié (sans `#`). Préférez les identifiants de guilde. - Les messages rédigés par des bots sont ignorés par défaut. `allowBots: true` les active ; utilisez `allowBots: "mentions"` pour n’accepter que les messages de bots qui mentionnent le bot (les propres messages restent filtrés). - `channels.discord.guilds..ignoreOtherMentions` (et les remplacements au niveau du canal) ignore les messages qui mentionnent un autre utilisateur ou rôle mais pas le bot (à l’exclusion de @everyone/@here). -- `maxLinesPerMessage` (17 par défaut) scinde les messages hauts même lorsqu’ils restent sous 2000 caractères. +- `maxLinesPerMessage` (17 par défaut) découpe les messages longs même lorsqu’ils font moins de 2000 caractères. - `channels.discord.threadBindings` contrôle le routage lié aux fils Discord : - - `enabled` : remplacement Discord pour les fonctionnalités de session liées aux fils (`/focus`, `/unfocus`, `/agents`, `/session idle`, `/session max-age` et la livraison/le routage liés) - - `idleHours` : remplacement Discord pour la perte de focus automatique après inactivité en heures (`0` désactive) - - `maxAgeHours` : remplacement Discord pour l’âge maximal strict en heures (`0` désactive) - - `spawnSubagentSessions` : option d’activation pour la création/liaison automatique de fils avec `sessions_spawn({ thread: true })` -- Les entrées `bindings[]` de niveau supérieur avec `type: "acp"` configurent des liaisons ACP persistantes pour les canaux et les fils (utilisez l’ID de canal/fil dans `match.peer.id`). La sémantique des champs est partagée dans [Agents ACP](/fr/tools/acp-agents#channel-specific-settings). -- `channels.discord.ui.components.accentColor` définit la couleur d’accent pour les conteneurs Discord components v2. -- `channels.discord.voice` active les conversations dans les canaux vocaux Discord ainsi que les remplacements facultatifs d’auto-jonction + TTS. + - `enabled` : remplacement Discord pour les fonctionnalités de session liées aux fils (`/focus`, `/unfocus`, `/agents`, `/session idle`, `/session max-age`, et la livraison/le routage liés) + - `idleHours` : remplacement Discord pour le retrait automatique du focus après inactivité, en heures (`0` désactive) + - `maxAgeHours` : remplacement Discord pour l’âge maximal strict, en heures (`0` désactive) + - `spawnSubagentSessions` : option d’activation pour la création/la liaison automatiques de fils avec `sessions_spawn({ thread: true })` +- Les entrées `bindings[]` de premier niveau avec `type: "acp"` configurent des liaisons ACP persistantes pour les canaux et les fils (utilisez l’identifiant de canal/fil dans `match.peer.id`). La sémantique des champs est partagée dans [ACP Agents](/fr/tools/acp-agents#channel-specific-settings). +- `channels.discord.ui.components.accentColor` définit la couleur d’accentuation des conteneurs de composants Discord v2. +- `channels.discord.voice` active les conversations dans les canaux vocaux Discord ainsi que les remplacements facultatifs d’auto-rejoint + TTS. - `channels.discord.voice.daveEncryption` et `channels.discord.voice.decryptionFailureTolerance` sont transmis aux options DAVE de `@discordjs/voice` (`true` et `24` par défaut). -- OpenClaw tente également une récupération de réception vocale en quittant/rejoignant une session vocale après des échecs répétés de déchiffrement. +- OpenClaw tente également une récupération de la réception vocale en quittant/rejoignant une session vocale après des échecs répétés de déchiffrement. - `channels.discord.streaming` est la clé canonique du mode de flux. Les anciennes valeurs `streamMode` et booléennes `streaming` sont migrées automatiquement. -- `channels.discord.autoPresence` associe la disponibilité d’exécution à la présence du bot (sain => online, dégradé => idle, épuisé => dnd) et autorise des remplacements facultatifs du texte d’état. -- `channels.discord.dangerouslyAllowNameMatching` réactive la correspondance par nom/tag mutable (mode de compatibilité « break-glass »). -- `channels.discord.execApprovals` : livraison des approbations d’exécution native à Discord et autorisation des approbateurs. - - `enabled` : `true`, `false` ou `"auto"` (par défaut). En mode auto, les approbations d’exécution s’activent lorsque des approbateurs peuvent être résolus à partir de `approvers` ou `commands.ownerAllowFrom`. - - `approvers` : ID d’utilisateurs Discord autorisés à approuver les demandes d’exécution. Revient à `commands.ownerAllowFrom` lorsqu’il est omis. - - `agentFilter` : liste d’autorisation facultative des ID d’agents. Omettez-la pour transmettre les approbations pour tous les agents. +- `channels.discord.autoPresence` mappe la disponibilité d’exécution à la présence du bot (healthy => online, degraded => idle, exhausted => dnd) et autorise des remplacements facultatifs de texte d’état. +- `channels.discord.dangerouslyAllowNameMatching` réactive la correspondance mutable nom/tag (mode de compatibilité de dernier recours). +- `channels.discord.execApprovals` : livraison native Discord des approbations d’exécution et autorisation des approbateurs. + - `enabled` : `true`, `false` ou `"auto"` (par défaut). En mode auto, les approbations d’exécution s’activent lorsque les approbateurs peuvent être résolus à partir de `approvers` ou `commands.ownerAllowFrom`. + - `approvers` : identifiants utilisateur Discord autorisés à approuver les demandes d’exécution. Utilise `commands.ownerAllowFrom` comme solution de repli lorsqu’il est omis. + - `agentFilter` : liste d’autorisation facultative des identifiants d’agent. Omettez-la pour transférer les approbations pour tous les agents. - `sessionFilter` : motifs facultatifs de clé de session (sous-chaîne ou regex). - - `target` : où envoyer les invites d’approbation. `"dm"` (par défaut) envoie vers les DM des approbateurs, `"channel"` envoie vers le canal d’origine, `"both"` envoie vers les deux. Lorsque la cible inclut `"channel"`, les boutons ne sont utilisables que par les approbateurs résolus. - - `cleanupAfterResolve` : lorsqu’il vaut `true`, supprime les DM d’approbation après approbation, refus ou expiration. + - `target` : où envoyer les invites d’approbation. `"dm"` (par défaut) les envoie dans les DM des approbateurs, `"channel"` les envoie dans le canal d’origine, `"both"` les envoie aux deux. Lorsque la cible inclut `"channel"`, les boutons ne sont utilisables que par les approbateurs résolus. + - `cleanupAfterResolve` : lorsque `true`, supprime les DM d’approbation après approbation, refus ou expiration. **Modes de notification de réaction :** `off` (aucune), `own` (messages du bot, par défaut), `all` (tous les messages), `allowlist` (depuis `guilds..users` sur tous les messages). @@ -393,11 +393,11 @@ WhatsApp fonctionne via le canal web du Gateway (Baileys Web). Il démarre autom } ``` -- JSON du compte de service : intégré (`serviceAccount`) ou basé sur un fichier (`serviceAccountFile`). -- SecretRef du compte de service également pris en charge (`serviceAccountRef`). -- Variables d’environnement de repli : `GOOGLE_CHAT_SERVICE_ACCOUNT` ou `GOOGLE_CHAT_SERVICE_ACCOUNT_FILE`. +- JSON du compte de service : en ligne (`serviceAccount`) ou basé sur un fichier (`serviceAccountFile`). +- SecretRef pour le compte de service est également pris en charge (`serviceAccountRef`). +- Solutions de repli par variable d’environnement : `GOOGLE_CHAT_SERVICE_ACCOUNT` ou `GOOGLE_CHAT_SERVICE_ACCOUNT_FILE`. - Utilisez `spaces/` ou `users/` pour les cibles de livraison. -- `channels.googlechat.dangerouslyAllowNameMatching` réactive la correspondance mutable du principal d’e-mail (mode de compatibilité « break-glass »). +- `channels.googlechat.dangerouslyAllowNameMatching` réactive la correspondance mutable du principal d’e-mail (mode de compatibilité de dernier recours). ### Slack @@ -464,39 +464,34 @@ WhatsApp fonctionne via le canal web du Gateway (Baileys Web). Il démarre autom } ``` -- Le **mode socket** exige à la fois `botToken` et `appToken` (`SLACK_BOT_TOKEN` + `SLACK_APP_TOKEN` pour le repli d’environnement du compte par défaut). -- Le **mode HTTP** exige `botToken` plus `signingSecret` (à la racine ou par compte). -- `botToken`, `appToken`, `signingSecret` et `userToken` acceptent des chaînes en clair - ou des objets SecretRef. -- Les instantanés de compte Slack exposent des champs de source/statut par identifiant tels que - `botTokenSource`, `botTokenStatus`, `appTokenStatus` et, en mode HTTP, - `signingSecretStatus`. `configured_unavailable` signifie que le compte est - configuré via SecretRef mais que le chemin actuel de commande/d’exécution n’a pas pu - résoudre la valeur du secret. -- `configWrites: false` bloque les écritures de configuration initiées par Slack. -- `channels.slack.defaultAccount` facultatif remplace la sélection du compte par défaut lorsqu’il correspond à un ID de compte configuré. +- Le **mode Socket** nécessite à la fois `botToken` et `appToken` (`SLACK_BOT_TOKEN` + `SLACK_APP_TOKEN` pour la solution de repli par variable d’environnement du compte par défaut). +- Le **mode HTTP** nécessite `botToken` plus `signingSecret` (à la racine ou par compte). +- `botToken`, `appToken`, `signingSecret` et `userToken` acceptent des chaînes en texte brut ou des objets SecretRef. +- Les instantanés de compte Slack exposent des champs source/état par identifiant tels que `botTokenSource`, `botTokenStatus`, `appTokenStatus` et, en mode HTTP, `signingSecretStatus`. `configured_unavailable` signifie que le compte est configuré via SecretRef mais que le chemin actuel de commande/d’exécution n’a pas pu résoudre la valeur du secret. +- `configWrites: false` bloque les écritures de configuration initiées depuis Slack. +- `channels.slack.defaultAccount` facultatif remplace la sélection du compte par défaut lorsqu’il correspond à un identifiant de compte configuré. - `channels.slack.streaming.mode` est la clé canonique du mode de flux Slack. `channels.slack.streaming.nativeTransport` contrôle le transport de flux natif de Slack. Les anciennes valeurs `streamMode`, booléennes `streaming` et `nativeStreaming` sont migrées automatiquement. - Utilisez `user:` (DM) ou `channel:` pour les cibles de livraison. **Modes de notification de réaction :** `off`, `own` (par défaut), `all`, `allowlist` (depuis `reactionAllowlist`). -**Isolation des sessions de fil :** `thread.historyScope` est par fil (par défaut) ou partagé sur le canal. `thread.inheritParent` copie la transcription du canal parent vers les nouveaux fils. +**Isolation de session par fil :** `thread.historyScope` est par fil (par défaut) ou partagé à l’échelle du canal. `thread.inheritParent` copie la transcription du canal parent vers les nouveaux fils. -- Le flux natif Slack ainsi que le statut de fil « is typing... » de style assistant Slack exigent une cible de réponse dans un fil. Les DM de niveau supérieur restent hors fil par défaut, ils utilisent donc `typingReaction` ou la livraison normale au lieu de l’aperçu de style fil. -- `typingReaction` ajoute une réaction temporaire au message Slack entrant pendant le traitement d’une réponse, puis la retire à la fin. Utilisez un shortcode d’emoji Slack tel que `"hourglass_flowing_sand"`. -- `channels.slack.execApprovals` : livraison des approbations d’exécution native à Slack et autorisation des approbateurs. Même schéma que Discord : `enabled` (`true`/`false`/`"auto"`), `approvers` (ID d’utilisateurs Slack), `agentFilter`, `sessionFilter` et `target` (`"dm"`, `"channel"` ou `"both"`). +- Le flux natif Slack ainsi que le statut de fil Slack de type assistant « is typing... » nécessitent une cible de réponse dans un fil. Les DM de premier niveau restent hors fil par défaut ; ils utilisent donc `typingReaction` ou la livraison normale au lieu de l’aperçu de type fil. +- `typingReaction` ajoute une réaction temporaire au message Slack entrant pendant l’exécution d’une réponse, puis la supprime à la fin. Utilisez un shortcode d’emoji Slack tel que `"hourglass_flowing_sand"`. +- `channels.slack.execApprovals` : livraison native Slack des approbations d’exécution et autorisation des approbateurs. Même schéma que Discord : `enabled` (`true`/`false`/`"auto"`), `approvers` (identifiants utilisateur Slack), `agentFilter`, `sessionFilter` et `target` (`"dm"`, `"channel"` ou `"both"`). -| Groupe d’actions | Par défaut | Notes | -| ---------------- | ---------- | ---------------------- | +| Groupe d’actions | Par défaut | Remarques | +| ---------------- | ---------- | ----------------------- | | reactions | activé | Réagir + lister les réactions | | messages | activé | Lire/envoyer/modifier/supprimer | | pins | activé | Épingler/désépingler/lister | | memberInfo | activé | Informations sur les membres | -| emojiList | activé | Liste des emojis personnalisés | +| emojiList | activé | Liste des emoji personnalisés | ### Mattermost -Mattermost est fourni comme Plugin : `openclaw plugins install @openclaw/mattermost`. +Mattermost est distribué sous forme de Plugin : `openclaw plugins install @openclaw/mattermost`. ```json5 { @@ -526,23 +521,19 @@ Mattermost est fourni comme Plugin : `openclaw plugins install @openclaw/matter } ``` -Modes de chat : `oncall` (répond sur mention @, par défaut), `onmessage` (chaque message), `onchar` (messages commençant par un préfixe de déclenchement). +Modes de chat : `oncall` (répond sur @mention, par défaut), `onmessage` (chaque message), `onchar` (messages commençant par un préfixe de déclenchement). Lorsque les commandes natives Mattermost sont activées : -- `commands.callbackPath` doit être un chemin (par exemple `/api/channels/mattermost/command`), pas une URL complète. -- `commands.callbackUrl` doit pointer vers le point de terminaison Gateway OpenClaw et être accessible depuis le serveur Mattermost. -- Les rappels slash natifs sont authentifiés à l’aide des jetons par commande renvoyés - par Mattermost lors de l’enregistrement des commandes slash. Si l’enregistrement échoue ou si aucune - commande n’est activée, OpenClaw rejette les rappels avec - `Unauthorized: invalid command token.` -- Pour les hôtes de rappel privés/tailnet/internes, Mattermost peut exiger que - `ServiceSettings.AllowedUntrustedInternalConnections` inclue l’hôte/domaine de rappel. - Utilisez des valeurs d’hôte/domaine, pas des URL complètes. -- `channels.mattermost.configWrites` : autoriser ou refuser les écritures de configuration initiées par Mattermost. +- `commands.callbackPath` doit être un chemin (par exemple `/api/channels/mattermost/command`), et non une URL complète. +- `commands.callbackUrl` doit pointer vers le point de terminaison Gateway d’OpenClaw et être accessible depuis le serveur Mattermost. +- Les rappels slash natifs sont authentifiés avec les jetons par commande renvoyés par Mattermost lors de l’enregistrement des commandes slash. Si l’enregistrement échoue ou si aucune commande n’est activée, OpenClaw rejette les rappels avec `Unauthorized: invalid command token.` +- Pour les hôtes de rappel privés/tailnet/internes, Mattermost peut exiger que `ServiceSettings.AllowedUntrustedInternalConnections` inclue l’hôte/domaine de rappel. + Utilisez des valeurs d’hôte/domaine, et non des URL complètes. +- `channels.mattermost.configWrites` : autoriser ou refuser les écritures de configuration initiées depuis Mattermost. - `channels.mattermost.requireMention` : exiger une `@mention` avant de répondre dans les canaux. - `channels.mattermost.groups..requireMention` : remplacement du filtrage par mention au niveau du canal (`"*"` pour la valeur par défaut). -- `channels.mattermost.defaultAccount` facultatif remplace la sélection du compte par défaut lorsqu’il correspond à un ID de compte configuré. +- `channels.mattermost.defaultAccount` facultatif remplace la sélection du compte par défaut lorsqu’il correspond à un identifiant de compte configuré. ### Signal @@ -551,7 +542,7 @@ Lorsque les commandes natives Mattermost sont activées : channels: { signal: { enabled: true, - account: "+15555550123", // liaison de compte facultative + account: "+15555550123", // optional account binding dmPolicy: "pairing", allowFrom: ["+15551234567", "uuid:123e4567-e89b-12d3-a456-426614174000"], configWrites: true, @@ -565,9 +556,9 @@ Lorsque les commandes natives Mattermost sont activées : **Modes de notification de réaction :** `off`, `own` (par défaut), `all`, `allowlist` (depuis `reactionAllowlist`). -- `channels.signal.account` : épingle le démarrage du canal à une identité de compte Signal spécifique. -- `channels.signal.configWrites` : autorise ou refuse les écritures de configuration initiées par Signal. -- `channels.signal.defaultAccount` facultatif remplace la sélection du compte par défaut lorsqu’il correspond à un ID de compte configuré. +- `channels.signal.account` : épingler le démarrage du canal à une identité de compte Signal spécifique. +- `channels.signal.configWrites` : autoriser ou refuser les écritures de configuration initiées depuis Signal. +- `channels.signal.defaultAccount` facultatif remplace la sélection du compte par défaut lorsqu’il correspond à un identifiant de compte configuré. ### BlueBubbles @@ -586,9 +577,9 @@ BlueBubbles est le chemin recommandé pour iMessage (pris en charge par un Plugi } ``` -- Chemins de clés principaux couverts ici : `channels.bluebubbles`, `channels.bluebubbles.dmPolicy`. -- `channels.bluebubbles.defaultAccount` facultatif remplace la sélection du compte par défaut lorsqu’il correspond à un ID de compte configuré. -- Les entrées `bindings[]` de niveau supérieur avec `type: "acp"` peuvent lier des conversations BlueBubbles à des sessions ACP persistantes. Utilisez un handle BlueBubbles ou une chaîne cible (`chat_id:*`, `chat_guid:*`, `chat_identifier:*`) dans `match.peer.id`. Sémantique partagée des champs : [Agents ACP](/fr/tools/acp-agents#channel-specific-settings). +- Chemins de clés principales couverts ici : `channels.bluebubbles`, `channels.bluebubbles.dmPolicy`. +- `channels.bluebubbles.defaultAccount` facultatif remplace la sélection du compte par défaut lorsqu’il correspond à un identifiant de compte configuré. +- Les entrées `bindings[]` de premier niveau avec `type: "acp"` peuvent lier des conversations BlueBubbles à des sessions ACP persistantes. Utilisez un handle BlueBubbles ou une chaîne cible (`chat_id:*`, `chat_guid:*`, `chat_identifier:*`) dans `match.peer.id`. Sémantique de champ partagée : [ACP Agents](/fr/tools/acp-agents#channel-specific-settings). - La configuration complète du canal BlueBubbles est documentée dans [BlueBubbles](/fr/channels/bluebubbles). ### iMessage @@ -617,15 +608,15 @@ OpenClaw lance `imsg rpc` (JSON-RPC sur stdio). Aucun démon ni port n’est req } ``` -- `channels.imessage.defaultAccount` facultatif remplace la sélection du compte par défaut lorsqu’il correspond à un ID de compte configuré. +- `channels.imessage.defaultAccount` facultatif remplace la sélection du compte par défaut lorsqu’il correspond à un identifiant de compte configuré. -- Nécessite un accès complet au disque pour la base de données Messages. -- Préférez les cibles `chat_id:`. Utilisez `imsg chats --limit 20` pour lister les discussions. +- Nécessite un accès complet au disque à la base de données Messages. +- Préférez les cibles `chat_id:`. Utilisez `imsg chats --limit 20` pour lister les conversations. - `cliPath` peut pointer vers un wrapper SSH ; définissez `remoteHost` (`host` ou `user@host`) pour la récupération des pièces jointes via SCP. -- `attachmentRoots` et `remoteAttachmentRoots` restreignent les chemins des pièces jointes entrantes (par défaut : `/Users/*/Library/Messages/Attachments`). -- SCP utilise une vérification stricte de la clé d’hôte ; assurez-vous donc que la clé d’hôte du relais existe déjà dans `~/.ssh/known_hosts`. -- `channels.imessage.configWrites` : autorise ou refuse les écritures de configuration initiées par iMessage. -- Les entrées `bindings[]` de niveau supérieur avec `type: "acp"` peuvent lier des conversations iMessage à des sessions ACP persistantes. Utilisez un handle normalisé ou une cible de discussion explicite (`chat_id:*`, `chat_guid:*`, `chat_identifier:*`) dans `match.peer.id`. Sémantique partagée des champs : [Agents ACP](/fr/tools/acp-agents#channel-specific-settings). +- `attachmentRoots` et `remoteAttachmentRoots` limitent les chemins des pièces jointes entrantes (par défaut : `/Users/*/Library/Messages/Attachments`). +- SCP utilise une vérification stricte des clés d’hôte ; assurez-vous donc que la clé d’hôte du relais existe déjà dans `~/.ssh/known_hosts`. +- `channels.imessage.configWrites` : autoriser ou refuser les écritures de configuration initiées depuis iMessage. +- Les entrées `bindings[]` de premier niveau avec `type: "acp"` peuvent lier des conversations iMessage à des sessions ACP persistantes. Utilisez un handle normalisé ou une cible de conversation explicite (`chat_id:*`, `chat_guid:*`, `chat_identifier:*`) dans `match.peer.id`. Sémantique de champ partagée : [ACP Agents](/fr/tools/acp-agents#channel-specific-settings). @@ -670,18 +661,18 @@ Matrix est pris en charge par une extension et configuré sous `channels.matrix` - L’authentification par jeton utilise `accessToken` ; l’authentification par mot de passe utilise `userId` + `password`. - `channels.matrix.proxy` achemine le trafic HTTP Matrix via un proxy HTTP(S) explicite. Les comptes nommés peuvent le remplacer avec `channels.matrix.accounts..proxy`. -- `channels.matrix.network.dangerouslyAllowPrivateNetwork` autorise les homeservers privés/internes. `proxy` et cette option réseau sont des contrôles indépendants. +- `channels.matrix.network.dangerouslyAllowPrivateNetwork` autorise les homeservers privés/internes. `proxy` et cette activation réseau sont des contrôles indépendants. - `channels.matrix.defaultAccount` sélectionne le compte préféré dans les configurations multi-comptes. -- `channels.matrix.autoJoin` vaut par défaut `off`, les salons invités et les nouvelles invitations de type DM sont donc ignorés tant que vous ne définissez pas `autoJoin: "allowlist"` avec `autoJoinAllowlist` ou `autoJoin: "always"`. -- `channels.matrix.execApprovals` : livraison des approbations d’exécution native à Matrix et autorisation des approbateurs. - - `enabled` : `true`, `false` ou `"auto"` (par défaut). En mode auto, les approbations d’exécution s’activent lorsque des approbateurs peuvent être résolus à partir de `approvers` ou `commands.ownerAllowFrom`. - - `approvers` : ID d’utilisateurs Matrix (par ex. `@owner:example.org`) autorisés à approuver les demandes d’exécution. - - `agentFilter` : liste d’autorisation facultative des ID d’agents. Omettez-la pour transmettre les approbations pour tous les agents. +- `channels.matrix.autoJoin` vaut `off` par défaut, donc les salons invités et les nouvelles invitations de type DM sont ignorés jusqu’à ce que vous définissiez `autoJoin: "allowlist"` avec `autoJoinAllowlist` ou `autoJoin: "always"`. +- `channels.matrix.execApprovals` : livraison native Matrix des approbations d’exécution et autorisation des approbateurs. + - `enabled` : `true`, `false` ou `"auto"` (par défaut). En mode auto, les approbations d’exécution s’activent lorsque les approbateurs peuvent être résolus à partir de `approvers` ou `commands.ownerAllowFrom`. + - `approvers` : identifiants utilisateur Matrix (par ex. `@owner:example.org`) autorisés à approuver les demandes d’exécution. + - `agentFilter` : liste d’autorisation facultative des identifiants d’agent. Omettez-la pour transférer les approbations pour tous les agents. - `sessionFilter` : motifs facultatifs de clé de session (sous-chaîne ou regex). - `target` : où envoyer les invites d’approbation. `"dm"` (par défaut), `"channel"` (salon d’origine) ou `"both"`. - Remplacements par compte : `channels.matrix.accounts..execApprovals`. -- `channels.matrix.dm.sessionScope` contrôle la façon dont les DM Matrix sont groupés en sessions : `per-user` (par défaut) partage par pair acheminé, tandis que `per-room` isole chaque salon DM. -- Les sondes d’état Matrix et les recherches dans l’annuaire en direct utilisent la même politique de proxy que le trafic d’exécution. +- `channels.matrix.dm.sessionScope` contrôle la façon dont les DM Matrix sont regroupés en sessions : `per-user` (par défaut) partage par pair routé, tandis que `per-room` isole chaque salon DM. +- Les sondes d’état Matrix et les recherches en direct dans l’annuaire utilisent la même stratégie de proxy que le trafic d’exécution. - La configuration complète de Matrix, les règles de ciblage et les exemples de configuration sont documentés dans [Matrix](/fr/channels/matrix). ### Microsoft Teams @@ -701,8 +692,8 @@ Microsoft Teams est pris en charge par une extension et configuré sous `channel } ``` -- Chemins de clés principaux couverts ici : `channels.msteams`, `channels.msteams.configWrites`. -- La configuration complète de Teams (identifiants, webhook, politique DM/groupe, remplacements par équipe/par canal) est documentée dans [Microsoft Teams](/fr/channels/msteams). +- Chemins de clés principales couverts ici : `channels.msteams`, `channels.msteams.configWrites`. +- La configuration complète de Teams (identifiants, webhook, stratégie DM/groupe, remplacements par équipe/par canal) est documentée dans [Microsoft Teams](/fr/channels/msteams). ### IRC @@ -727,8 +718,8 @@ IRC est pris en charge par une extension et configuré sous `channels.irc`. } ``` -- Chemins de clés principaux couverts ici : `channels.irc`, `channels.irc.dmPolicy`, `channels.irc.configWrites`, `channels.irc.nickserv.*`. -- `channels.irc.defaultAccount` facultatif remplace la sélection du compte par défaut lorsqu’il correspond à un ID de compte configuré. +- Chemins de clés principales couverts ici : `channels.irc`, `channels.irc.dmPolicy`, `channels.irc.configWrites`, `channels.irc.nickserv.*`. +- `channels.irc.defaultAccount` facultatif remplace la sélection du compte par défaut lorsqu’il correspond à un identifiant de compte configuré. - La configuration complète du canal IRC (hôte/port/TLS/canaux/listes d’autorisation/filtrage par mention) est documentée dans [IRC](/fr/channels/irc). ### Multi-compte (tous les canaux) @@ -757,24 +748,24 @@ Exécutez plusieurs comptes par canal (chacun avec son propre `accountId`) : - `default` est utilisé lorsque `accountId` est omis (CLI + routage). - Les jetons d’environnement ne s’appliquent qu’au compte **default**. - Les paramètres de base du canal s’appliquent à tous les comptes sauf remplacement par compte. -- Utilisez `bindings[].match.accountId` pour acheminer chaque compte vers un agent différent. -- Si vous ajoutez un compte non par défaut via `openclaw channels add` (ou l’intégration du canal) alors que vous utilisez encore une configuration de canal de niveau supérieur mono-compte, OpenClaw promeut d’abord les valeurs mono-compte de niveau supérieur circonscrites au compte vers la map de comptes du canal afin que le compte d’origine continue de fonctionner. La plupart des canaux les déplacent vers `channels..accounts.default` ; Matrix peut à la place conserver une cible nommée/par défaut existante correspondante. -- Les liaisons existantes uniquement au niveau du canal (sans `accountId`) continuent à correspondre au compte par défaut ; les liaisons circonscrites au compte restent facultatives. -- `openclaw doctor --fix` répare également les formes mixtes en déplaçant les valeurs mono-compte de niveau supérieur circonscrites au compte vers le compte promu choisi pour ce canal. La plupart des canaux utilisent `accounts.default` ; Matrix peut à la place conserver une cible nommée/par défaut existante correspondante. +- Utilisez `bindings[].match.accountId` pour router chaque compte vers un agent différent. +- Si vous ajoutez un compte non par défaut via `openclaw channels add` (ou l’intégration du canal) alors que vous êtes encore sur une configuration de canal de premier niveau à compte unique, OpenClaw promeut d’abord les valeurs de compte unique de premier niveau limitées au compte dans le mappage de comptes du canal afin que le compte d’origine continue de fonctionner. La plupart des canaux les déplacent dans `channels..accounts.default` ; Matrix peut à la place conserver une cible nommée/par défaut existante correspondante. +- Les liaisons existantes uniquement au niveau du canal (sans `accountId`) continuent de correspondre au compte par défaut ; les liaisons limitées au compte restent facultatives. +- `openclaw doctor --fix` répare également les formes mixtes en déplaçant les valeurs de compte unique de premier niveau limitées au compte dans le compte promu choisi pour ce canal. La plupart des canaux utilisent `accounts.default` ; Matrix peut à la place conserver une cible nommée/par défaut existante correspondante. ### Autres canaux d’extension -De nombreux canaux d’extension sont configurés en tant que `channels.` et documentés dans leurs pages de canal dédiées (par exemple Feishu, Matrix, LINE, Nostr, Zalo, Nextcloud Talk, Synology Chat et Twitch). -Voir l’index complet des canaux : [Canaux](/fr/channels). +De nombreux canaux d’extension sont configurés sous la forme `channels.` et documentés dans leurs pages de canal dédiées (par exemple Feishu, Matrix, LINE, Nostr, Zalo, Nextcloud Talk et Twitch). +Voir l’index complet des canaux : [Channels](/fr/channels). ### Filtrage par mention dans les discussions de groupe -Les messages de groupe exigent par défaut **une mention obligatoire** (mention dans les métadonnées ou motifs regex sûrs). S’applique aux discussions de groupe WhatsApp, Telegram, Discord, Google Chat et iMessage. +Les messages de groupe exigent par défaut **une mention requise** (mention de métadonnées ou motifs regex sûrs). Cela s’applique aux discussions de groupe WhatsApp, Telegram, Discord, Google Chat et iMessage. **Types de mention :** -- **Mentions dans les métadonnées** : mentions @ natives de la plateforme. Ignorées en mode auto-discussion WhatsApp. -- **Motifs de texte** : motifs regex sûrs dans `agents.list[].groupChat.mentionPatterns`. Les motifs invalides et les répétitions imbriquées non sûres sont ignorés. +- **Mentions de métadonnées** : @mentions natives de la plateforme. Ignorées en mode discussion personnelle WhatsApp. +- **Motifs textuels** : motifs regex sûrs dans `agents.list[].groupChat.mentionPatterns`. Les motifs invalides et les répétitions imbriquées non sûres sont ignorés. - Le filtrage par mention n’est appliqué que lorsque la détection est possible (mentions natives ou au moins un motif). ```json5 @@ -788,7 +779,7 @@ Les messages de groupe exigent par défaut **une mention obligatoire** (mention } ``` -`messages.groupChat.historyLimit` définit la valeur globale par défaut. Les canaux peuvent la remplacer avec `channels..historyLimit` (ou par compte). Définissez `0` pour désactiver. +`messages.groupChat.historyLimit` définit la valeur par défaut globale. Les canaux peuvent la remplacer avec `channels..historyLimit` (ou par compte). Définissez `0` pour désactiver. #### Limites d’historique DM @@ -809,9 +800,9 @@ Résolution : remplacement par DM → valeur par défaut du fournisseur → auc Pris en charge : `telegram`, `whatsapp`, `discord`, `slack`, `signal`, `imessage`, `msteams`. -#### Mode auto-discussion +#### Mode discussion personnelle -Incluez votre propre numéro dans `allowFrom` pour activer le mode auto-discussion (ignore les mentions @ natives, répond uniquement aux motifs textuels) : +Incluez votre propre numéro dans `allowFrom` pour activer le mode discussion personnelle (ignore les @mentions natives, répond uniquement aux motifs textuels) : ```json5 { @@ -832,7 +823,7 @@ Incluez votre propre numéro dans `allowFrom` pour activer le mode auto-discussi } ``` -### Commandes (gestion des commandes de chat) +### Commands (gestion des commandes de discussion) ```json5 { @@ -861,30 +852,30 @@ Incluez votre propre numéro dans `allowFrom` pour activer le mode auto-discussi -- Ce bloc configure les surfaces de commande. Pour le catalogue actuel des commandes intégrées + bundle, voir [Commandes slash](/fr/tools/slash-commands). -- Cette page est une **référence des clés de configuration**, pas le catalogue complet des commandes. Les commandes propres à un canal/Plugin, comme QQ Bot `/bot-ping` `/bot-help` `/bot-logs`, LINE `/card`, device-pair `/pair`, memory `/dreaming`, phone-control `/phone` et Talk `/voice`, sont documentées dans leurs pages de canal/Plugin ainsi que dans [Commandes slash](/fr/tools/slash-commands). -- Les commandes textuelles doivent être des messages **autonomes** commençant par `/`. +- Ce bloc configure les surfaces de commandes. Pour le catalogue actuel des commandes intégrées + groupées, voir [Slash Commands](/fr/tools/slash-commands). +- Cette page est une **référence des clés de configuration**, et non le catalogue complet des commandes. Les commandes propres au canal/Plugin comme QQ Bot `/bot-ping` `/bot-help` `/bot-logs`, LINE `/card`, device-pair `/pair`, memory `/dreaming`, phone-control `/phone` et Talk `/voice` sont documentées dans leurs pages de canal/Plugin ainsi que dans [Slash Commands](/fr/tools/slash-commands). +- Les commandes textuelles doivent être des messages **autonomes** avec un `/` initial. - `native: "auto"` active les commandes natives pour Discord/Telegram, et laisse Slack désactivé. - `nativeSkills: "auto"` active les commandes natives de Skills pour Discord/Telegram, et laisse Slack désactivé. - Remplacement par canal : `channels.discord.commands.native` (booléen ou `"auto"`). `false` efface les commandes précédemment enregistrées. -- Remplacez l’enregistrement natif des commandes de Skills par canal avec `channels..commands.nativeSkills`. +- Remplacez l’enregistrement des Skills natives par canal avec `channels..commands.nativeSkills`. - `channels.telegram.customCommands` ajoute des entrées supplémentaires au menu du bot Telegram. - `bash: true` active `! ` pour le shell hôte. Nécessite `tools.elevated.enabled` et que l’expéditeur soit dans `tools.elevated.allowFrom.`. -- `config: true` active `/config` (lit/écrit `openclaw.json`). Pour les clients `chat.send` du Gateway, les écritures persistantes `/config set|unset` exigent également `operator.admin` ; `/config show` en lecture seule reste disponible pour les clients opérateur normaux avec portée d’écriture. -- `mcp: true` active `/mcp` pour la configuration du serveur MCP géré par OpenClaw sous `mcp.servers`. +- `config: true` active `/config` (lit/écrit `openclaw.json`). Pour les clients Gateway `chat.send`, les écritures persistantes `/config set|unset` nécessitent aussi `operator.admin` ; la commande en lecture seule `/config show` reste disponible pour les clients opérateur normaux avec portée d’écriture. +- `mcp: true` active `/mcp` pour la configuration des serveurs MCP gérés par OpenClaw sous `mcp.servers`. - `plugins: true` active `/plugins` pour la découverte, l’installation et les contrôles d’activation/désactivation des plugins. - `channels..configWrites` contrôle les mutations de configuration par canal (par défaut : true). - Pour les canaux multi-comptes, `channels..accounts..configWrites` contrôle également les écritures qui ciblent ce compte (par exemple `/allowlist --config --account ` ou `/config set channels..accounts....`). -- `restart: false` désactive `/restart` et les actions de l’outil de redémarrage du Gateway. Par défaut : `true`. +- `restart: false` désactive `/restart` et les actions de l’outil de redémarrage de Gateway. Par défaut : `true`. - `ownerAllowFrom` est la liste d’autorisation explicite du propriétaire pour les commandes/outils réservés au propriétaire. Elle est distincte de `allowFrom`. -- `ownerDisplay: "hash"` hache les ID du propriétaire dans le prompt système. Définissez `ownerDisplaySecret` pour contrôler le hachage. -- `allowFrom` est défini par fournisseur. Lorsqu’il est défini, c’est l’**unique** source d’autorisation (les listes d’autorisation/appairage du canal et `useAccessGroups` sont ignorés). -- `useAccessGroups: false` permet aux commandes de contourner les politiques de groupes d’accès lorsque `allowFrom` n’est pas défini. -- Cartographie de la documentation des commandes : - - catalogue intégré + bundle : [Commandes slash](/fr/tools/slash-commands) - - surfaces de commande propres aux canaux : [Canaux](/fr/channels) +- `ownerDisplay: "hash"` hache les identifiants du propriétaire dans l’invite système. Définissez `ownerDisplaySecret` pour contrôler le hachage. +- `allowFrom` est défini par fournisseur. Lorsqu’il est défini, c’est la **seule** source d’autorisation (les listes d’autorisation/appairages de canal et `useAccessGroups` sont ignorés). +- `useAccessGroups: false` permet aux commandes de contourner les stratégies de groupes d’accès lorsque `allowFrom` n’est pas défini. +- Carte de la documentation des commandes : + - catalogue intégré + groupé : [Slash Commands](/fr/tools/slash-commands) + - surfaces de commandes spécifiques au canal : [Channels](/fr/channels) - commandes QQ Bot : [QQ Bot](/fr/channels/qqbot) - - commandes d’appairage : [Appairage](/fr/channels/pairing) + - commandes d’appairage : [Pairing](/fr/channels/pairing) - commande de carte LINE : [LINE](/fr/channels/line) - Dreaming de la mémoire : [Dreaming](/fr/concepts/dreaming) @@ -906,7 +897,7 @@ Par défaut : `~/.openclaw/workspace`. ### `agents.defaults.repoRoot` -Racine de dépôt facultative affichée dans la ligne Runtime du prompt système. Si elle n’est pas définie, OpenClaw la détecte automatiquement en remontant depuis le workspace. +Racine de dépôt facultative affichée dans la ligne Runtime de l’invite système. Si elle n’est pas définie, OpenClaw la détecte automatiquement en remontant depuis l’espace de travail. ```json5 { @@ -916,7 +907,7 @@ Racine de dépôt facultative affichée dans la ligne Runtime du prompt système ### `agents.defaults.skills` -Liste d’autorisation de Skills par défaut facultative pour les agents qui ne définissent pas +Liste d’autorisation Skills facultative par défaut pour les agents qui ne définissent pas `agents.list[].skills`. ```json5 @@ -924,23 +915,23 @@ Liste d’autorisation de Skills par défaut facultative pour les agents qui ne agents: { defaults: { skills: ["github", "weather"] }, list: [ - { id: "writer" }, // hérite de github, weather - { id: "docs", skills: ["docs-search"] }, // remplace les valeurs par défaut - { id: "locked-down", skills: [] }, // aucun Skills + { id: "writer" }, // inherits github, weather + { id: "docs", skills: ["docs-search"] }, // replaces defaults + { id: "locked-down", skills: [] }, // no skills ], }, } ``` -- Omettez `agents.defaults.skills` pour autoriser tous les Skills par défaut. +- Omettez `agents.defaults.skills` pour des Skills non restreintes par défaut. - Omettez `agents.list[].skills` pour hériter des valeurs par défaut. -- Définissez `agents.list[].skills: []` pour n’avoir aucun Skills. +- Définissez `agents.list[].skills: []` pour n’avoir aucune Skills. - Une liste non vide `agents.list[].skills` est l’ensemble final pour cet agent ; elle - ne fusionne pas avec les valeurs par défaut. + n’est pas fusionnée avec les valeurs par défaut. ### `agents.defaults.skipBootstrap` -Désactive la création automatique des fichiers bootstrap du workspace (`AGENTS.md`, `SOUL.md`, `TOOLS.md`, `IDENTITY.md`, `USER.md`, `HEARTBEAT.md`, `BOOTSTRAP.md`). +Désactive la création automatique des fichiers d’initialisation de l’espace de travail (`AGENTS.md`, `SOUL.md`, `TOOLS.md`, `IDENTITY.md`, `USER.md`, `HEARTBEAT.md`, `BOOTSTRAP.md`). ```json5 { @@ -950,9 +941,9 @@ Désactive la création automatique des fichiers bootstrap du workspace (`AGENTS ### `agents.defaults.contextInjection` -Contrôle quand les fichiers bootstrap du workspace sont injectés dans le prompt système. Par défaut : `"always"`. +Contrôle quand les fichiers d’initialisation de l’espace de travail sont injectés dans l’invite système. Par défaut : `"always"`. -- `"continuation-skip"` : les tours de continuation sûrs (après une réponse complète de l’assistant) évitent la réinjection du bootstrap du workspace, réduisant la taille du prompt. Les exécutions Heartbeat et les nouvelles tentatives post-Compaction reconstruisent toujours le contexte. +- `"continuation-skip"` : les tours de continuation sûrs (après une réponse d’assistant terminée) ignorent la réinjection de l’initialisation de l’espace de travail, ce qui réduit la taille de l’invite. Les exécutions Heartbeat et les nouvelles tentatives après Compaction reconstruisent toujours le contexte. ```json5 { @@ -962,7 +953,7 @@ Contrôle quand les fichiers bootstrap du workspace sont injectés dans le promp ### `agents.defaults.bootstrapMaxChars` -Nombre maximal de caractères par fichier bootstrap du workspace avant troncature. Par défaut : `12000`. +Nombre maximal de caractères par fichier d’initialisation de l’espace de travail avant troncature. Par défaut : `12000`. ```json5 { @@ -972,7 +963,7 @@ Nombre maximal de caractères par fichier bootstrap du workspace avant troncatur ### `agents.defaults.bootstrapTotalMaxChars` -Nombre total maximal de caractères injectés dans l’ensemble des fichiers bootstrap du workspace. Par défaut : `60000`. +Nombre total maximal de caractères injectés dans l’ensemble des fichiers d’initialisation de l’espace de travail. Par défaut : `60000`. ```json5 { @@ -982,11 +973,11 @@ Nombre total maximal de caractères injectés dans l’ensemble des fichiers boo ### `agents.defaults.bootstrapPromptTruncationWarning` -Contrôle le texte d’avertissement visible par l’agent lorsque le contexte bootstrap est tronqué. +Contrôle le texte d’avertissement visible par l’agent lorsque le contexte d’initialisation est tronqué. Par défaut : `"once"`. -- `"off"` : n’injecte jamais de texte d’avertissement dans le prompt système. -- `"once"` : injecte l’avertissement une fois par signature unique de troncature (recommandé). +- `"off"` : n’injecte jamais de texte d’avertissement dans l’invite système. +- `"once"` : injecte l’avertissement une fois par signature de troncature unique (recommandé). - `"always"` : injecte l’avertissement à chaque exécution lorsqu’une troncature existe. ```json5 @@ -995,35 +986,35 @@ Par défaut : `"once"`. } ``` -### Cartographie de propriété du budget de contexte +### Carte de responsabilité des budgets de contexte -OpenClaw possède plusieurs budgets de prompt/contexte à fort volume, et ils sont -délibérément répartis par sous-système au lieu de tous passer par un unique -réglage générique. +OpenClaw dispose de plusieurs budgets d’invite/contexte à volume élevé, et ils sont +délibérément répartis par sous-système au lieu de tous passer par un seul +paramètre générique. - `agents.defaults.bootstrapMaxChars` / `agents.defaults.bootstrapTotalMaxChars` : - injection bootstrap normale du workspace. + injection normale de l’initialisation de l’espace de travail. - `agents.defaults.startupContext.*` : - préambule de démarrage à usage unique pour `/new` et `/reset`, y compris les fichiers + prélude de démarrage à usage unique pour `/new` et `/reset`, y compris les fichiers récents `memory/*.md` quotidiens. - `skills.limits.*` : - la liste compacte des Skills injectée dans le prompt système. + la liste compacte de Skills injectée dans l’invite système. - `agents.defaults.contextLimits.*` : - extraits d’exécution bornés et blocs injectés appartenant à l’exécution. + extraits bornés à l’exécution et blocs injectés appartenant à l’exécution. - `memory.qmd.limits.*` : - extraits de recherche mémoire indexés et dimensionnement d’injection. + taille des extraits de recherche mémoire indexée et de l’injection. -Utilisez le remplacement correspondant par agent uniquement lorsqu’un agent a besoin d’un -budget différent : +Utilisez le remplacement par agent correspondant uniquement lorsqu’un agent a besoin +d’un budget différent : - `agents.list[].skillsLimits.maxSkillsPromptChars` - `agents.list[].contextLimits.*` #### `agents.defaults.startupContext` -Contrôle le préambule de démarrage du premier tour injecté lors des exécutions -`/new` et `/reset` sans autre contenu. +Contrôle le prélude de démarrage injecté au premier tour lors des exécutions +nues de `/new` et `/reset`. ```json5 { @@ -1044,7 +1035,7 @@ Contrôle le préambule de démarrage du premier tour injecté lors des exécuti #### `agents.defaults.contextLimits` -Valeurs par défaut partagées pour les surfaces de contexte d’exécution bornées. +Valeurs par défaut partagées pour les surfaces de contexte bornées à l’exécution. ```json5 { @@ -1061,18 +1052,18 @@ Valeurs par défaut partagées pour les surfaces de contexte d’exécution born } ``` -- `memoryGetMaxChars` : plafond d’extrait `memory_get` par défaut avant l’ajout des - métadonnées de troncature et de l’avis de continuation. -- `memoryGetDefaultLines` : fenêtre de lignes `memory_get` par défaut lorsque `lines` est +- `memoryGetMaxChars` : plafond par défaut de l’extrait `memory_get` avant l’ajout + des métadonnées de troncature et de l’avis de continuation. +- `memoryGetDefaultLines` : fenêtre de lignes par défaut de `memory_get` lorsque `lines` est omis. -- `toolResultMaxChars` : plafond des résultats d’outil en direct utilisé pour les résultats persistés et la - récupération de débordement. -- `postCompactionMaxChars` : plafond d’extrait de `AGENTS.md` utilisé lors de l’injection de - rafraîchissement post-Compaction. +- `toolResultMaxChars` : plafond des résultats d’outil en direct utilisé pour les résultats persistés et + la récupération après débordement. +- `postCompactionMaxChars` : plafond d’extrait AGENTS.md utilisé lors de l’injection de + rafraîchissement après Compaction. #### `agents.list[].contextLimits` -Remplacement par agent pour les réglages partagés `contextLimits`. Les champs omis héritent +Remplacement par agent pour les paramètres partagés `contextLimits`. Les champs omis héritent de `agents.defaults.contextLimits`. ```json5 @@ -1099,7 +1090,7 @@ de `agents.defaults.contextLimits`. #### `skills.limits.maxSkillsPromptChars` -Plafond global pour la liste compacte des Skills injectée dans le prompt système. Cela +Plafond global pour la liste compacte de Skills injectée dans l’invite système. Cela n’affecte pas la lecture à la demande des fichiers `SKILL.md`. ```json5 @@ -1114,7 +1105,7 @@ n’affecte pas la lecture à la demande des fichiers `SKILL.md`. #### `agents.list[].skillsLimits.maxSkillsPromptChars` -Remplacement par agent pour le budget du prompt de Skills. +Remplacement par agent pour le budget d’invite des Skills. ```json5 { @@ -1133,11 +1124,11 @@ Remplacement par agent pour le budget du prompt de Skills. ### `agents.defaults.imageMaxDimensionPx` -Taille maximale en pixels du plus long côté d’une image dans les blocs image de transcription/outil avant les appels fournisseur. +Taille maximale en pixels du plus long côté d’une image dans les blocs image de transcription/outil avant les appels au fournisseur. Par défaut : `1200`. -Des valeurs plus faibles réduisent généralement l’usage des jetons de vision et la taille des charges utiles pour les exécutions riches en captures d’écran. -Des valeurs plus élevées préservent davantage de détails visuels. +Des valeurs plus faibles réduisent généralement l’utilisation des jetons de vision et la taille des charges utiles de requête pour les exécutions riches en captures d’écran. +Des valeurs plus élevées conservent davantage de détails visuels. ```json5 { @@ -1147,7 +1138,7 @@ Des valeurs plus élevées préservent davantage de détails visuels. ### `agents.defaults.userTimezone` -Fuseau horaire pour le contexte du prompt système (pas les horodatages des messages). Revient au fuseau horaire de l’hôte. +Fuseau horaire pour le contexte de l’invite système (pas les horodatages des messages). Utilise le fuseau horaire de l’hôte comme solution de repli. ```json5 { @@ -1157,7 +1148,7 @@ Fuseau horaire pour le contexte du prompt système (pas les horodatages des mess ### `agents.defaults.timeFormat` -Format de l’heure dans le prompt système. Par défaut : `auto` (préférence de l’OS). +Format de l’heure dans l’invite système. Par défaut : `auto` (préférence de l’OS). ```json5 { @@ -1195,7 +1186,7 @@ Format de l’heure dans le prompt système. Par défaut : `auto` (préférence primary: "anthropic/claude-opus-4-6", fallbacks: ["openai/gpt-5.4-mini"], }, - params: { cacheRetention: "long" }, // paramètres fournisseur globaux par défaut + params: { cacheRetention: "long" }, // global default provider params embeddedHarness: { runtime: "auto", // auto | pi | registered harness id, e.g. codex fallback: "pi", // pi | none @@ -1216,46 +1207,46 @@ Format de l’heure dans le prompt système. Par défaut : `auto` (préférence - `model` : accepte soit une chaîne (`"provider/model"`), soit un objet (`{ primary, fallbacks }`). - La forme chaîne définit uniquement le modèle principal. - - La forme objet définit le principal plus des modèles de bascule ordonnés. + - La forme objet définit le modèle principal ainsi que des modèles de bascule ordonnés. - `imageModel` : accepte soit une chaîne (`"provider/model"`), soit un objet (`{ primary, fallbacks }`). - Utilisé par le chemin de l’outil `image` comme configuration de modèle de vision. - - Également utilisé comme routage de repli lorsque le modèle sélectionné/par défaut ne peut pas accepter d’entrée image. + - Également utilisé comme routage de secours lorsque le modèle sélectionné/par défaut ne peut pas accepter d’entrée image. - `imageGenerationModel` : accepte soit une chaîne (`"provider/model"`), soit un objet (`{ primary, fallbacks }`). - Utilisé par la capacité partagée de génération d’images et toute future surface d’outil/Plugin qui génère des images. - Valeurs typiques : `google/gemini-3.1-flash-image-preview` pour la génération d’images Gemini native, `fal/fal-ai/flux/dev` pour fal, ou `openai/gpt-image-1` pour OpenAI Images. - - Si vous sélectionnez directement un fournisseur/modèle, configurez aussi l’authentification/la clé API du fournisseur correspondant (par exemple `GEMINI_API_KEY` ou `GOOGLE_API_KEY` pour `google/*`, `OPENAI_API_KEY` pour `openai/*`, `FAL_KEY` pour `fal/*`). - - Si omis, `image_generate` peut quand même déduire une valeur par défaut de fournisseur avec authentification. Il essaie d’abord le fournisseur par défaut actuel, puis les autres fournisseurs de génération d’images enregistrés dans l’ordre des ID de fournisseur. + - Si vous sélectionnez directement un provider/model, configurez également l’authentification/la clé API du fournisseur correspondante (par exemple `GEMINI_API_KEY` ou `GOOGLE_API_KEY` pour `google/*`, `OPENAI_API_KEY` pour `openai/*`, `FAL_KEY` pour `fal/*`). + - S’il est omis, `image_generate` peut tout de même inférer un fournisseur par défaut adossé à l’authentification. Il essaie d’abord le fournisseur par défaut actuel, puis les autres fournisseurs de génération d’images enregistrés dans l’ordre des identifiants de fournisseur. - `musicGenerationModel` : accepte soit une chaîne (`"provider/model"`), soit un objet (`{ primary, fallbacks }`). - Utilisé par la capacité partagée de génération musicale et l’outil intégré `music_generate`. - Valeurs typiques : `google/lyria-3-clip-preview`, `google/lyria-3-pro-preview` ou `minimax/music-2.5+`. - - Si omis, `music_generate` peut quand même déduire une valeur par défaut de fournisseur avec authentification. Il essaie d’abord le fournisseur par défaut actuel, puis les autres fournisseurs de génération musicale enregistrés dans l’ordre des ID de fournisseur. - - Si vous sélectionnez directement un fournisseur/modèle, configurez aussi l’authentification/la clé API du fournisseur correspondant. + - S’il est omis, `music_generate` peut tout de même inférer un fournisseur par défaut adossé à l’authentification. Il essaie d’abord le fournisseur par défaut actuel, puis les autres fournisseurs de génération musicale enregistrés dans l’ordre des identifiants de fournisseur. + - Si vous sélectionnez directement un provider/model, configurez également l’authentification/la clé API du fournisseur correspondante. - `videoGenerationModel` : accepte soit une chaîne (`"provider/model"`), soit un objet (`{ primary, fallbacks }`). - Utilisé par la capacité partagée de génération vidéo et l’outil intégré `video_generate`. - Valeurs typiques : `qwen/wan2.6-t2v`, `qwen/wan2.6-i2v`, `qwen/wan2.6-r2v`, `qwen/wan2.6-r2v-flash` ou `qwen/wan2.7-r2v`. - - Si omis, `video_generate` peut quand même déduire une valeur par défaut de fournisseur avec authentification. Il essaie d’abord le fournisseur par défaut actuel, puis les autres fournisseurs de génération vidéo enregistrés dans l’ordre des ID de fournisseur. - - Si vous sélectionnez directement un fournisseur/modèle, configurez aussi l’authentification/la clé API du fournisseur correspondant. - - Le fournisseur groupé de génération vidéo Qwen prend en charge jusqu’à 1 vidéo de sortie, 1 image d’entrée, 4 vidéos d’entrée, une durée de 10 secondes et les options de niveau fournisseur `size`, `aspectRatio`, `resolution`, `audio` et `watermark`. + - S’il est omis, `video_generate` peut tout de même inférer un fournisseur par défaut adossé à l’authentification. Il essaie d’abord le fournisseur par défaut actuel, puis les autres fournisseurs de génération vidéo enregistrés dans l’ordre des identifiants de fournisseur. + - Si vous sélectionnez directement un provider/model, configurez également l’authentification/la clé API du fournisseur correspondante. + - Le fournisseur groupé de génération vidéo Qwen prend en charge jusqu’à 1 vidéo de sortie, 1 image d’entrée, 4 vidéos d’entrée, une durée de 10 secondes, ainsi que les options au niveau du fournisseur `size`, `aspectRatio`, `resolution`, `audio` et `watermark`. - `pdfModel` : accepte soit une chaîne (`"provider/model"`), soit un objet (`{ primary, fallbacks }`). - Utilisé par l’outil `pdf` pour le routage du modèle. - - Si omis, l’outil PDF revient à `imageModel`, puis au modèle de session/par défaut résolu. + - S’il est omis, l’outil PDF se rabat sur `imageModel`, puis sur le modèle de session/par défaut résolu. - `pdfMaxBytesMb` : limite de taille PDF par défaut pour l’outil `pdf` lorsque `maxBytesMb` n’est pas transmis à l’appel. -- `pdfMaxPages` : nombre maximal de pages pris en compte par défaut par le mode de repli d’extraction dans l’outil `pdf`. -- `verboseDefault` : niveau détaillé par défaut pour les agents. Valeurs : `"off"`, `"on"`, `"full"`. Par défaut : `"off"`. +- `pdfMaxPages` : nombre maximal de pages par défaut pris en compte par le mode de secours d’extraction dans l’outil `pdf`. +- `verboseDefault` : niveau de verbosité par défaut pour les agents. Valeurs : `"off"`, `"on"`, `"full"`. Par défaut : `"off"`. - `elevatedDefault` : niveau de sortie élevée par défaut pour les agents. Valeurs : `"off"`, `"on"`, `"ask"`, `"full"`. Par défaut : `"on"`. -- `model.primary` : format `provider/model` (par ex. `openai/gpt-5.4`). Si vous omettez le fournisseur, OpenClaw essaie d’abord un alias, puis une correspondance unique de fournisseur configuré pour cet ID de modèle exact, et seulement ensuite revient au fournisseur par défaut configuré (comportement de compatibilité déprécié, donc préférez l’explicite `provider/model`). Si ce fournisseur n’expose plus le modèle par défaut configuré, OpenClaw revient au premier fournisseur/modèle configuré au lieu d’exposer un ancien défaut d’un fournisseur supprimé. -- `models` : le catalogue de modèles configuré et la liste d’autorisation pour `/model`. Chaque entrée peut inclure `alias` (raccourci) et `params` (spécifiques au fournisseur, par exemple `temperature`, `maxTokens`, `cacheRetention`, `context1m`). -- `params` : paramètres globaux de fournisseur par défaut appliqués à tous les modèles. À définir dans `agents.defaults.params` (par ex. `{ cacheRetention: "long" }`). -- Priorité de fusion de `params` (configuration) : `agents.defaults.params` (base globale) est remplacé par `agents.defaults.models["provider/model"].params` (par modèle), puis `agents.list[].params` (ID d’agent correspondant) remplace par clé. Voir [Prompt Caching](/fr/reference/prompt-caching) pour les détails. -- `embeddedHarness` : politique d’exécution embarquée bas niveau par défaut pour les agents. Utilisez `runtime: "auto"` pour laisser les harness de Plugin enregistrés revendiquer les modèles pris en charge, `runtime: "pi"` pour forcer le harness PI intégré, ou un ID de harness enregistré tel que `runtime: "codex"`. Définissez `fallback: "none"` pour désactiver le repli automatique vers PI. -- Les outils d’écriture de configuration qui modifient ces champs (par exemple `/models set`, `/models set-image` et les commandes d’ajout/suppression de repli) enregistrent la forme objet canonique et préservent les listes de repli existantes lorsque possible. -- `maxConcurrent` : nombre maximal d’exécutions parallèles d’agents entre les sessions (chaque session reste sérialisée). Par défaut : 4. +- `model.primary` : format `provider/model` (par ex. `openai/gpt-5.4`). Si vous omettez le fournisseur, OpenClaw essaie d’abord un alias, puis une correspondance unique de fournisseur configuré pour cet identifiant de modèle exact, et ce n’est qu’ensuite qu’il se rabat sur le fournisseur par défaut configuré (comportement de compatibilité obsolète ; préférez donc `provider/model` explicite). Si ce fournisseur n’expose plus le modèle par défaut configuré, OpenClaw se rabat sur le premier fournisseur/modèle configuré au lieu d’exposer une valeur par défaut obsolète d’un fournisseur supprimé. +- `models` : catalogue de modèles configuré et liste d’autorisation pour `/model`. Chaque entrée peut inclure `alias` (raccourci) et `params` (propres au fournisseur, par exemple `temperature`, `maxTokens`, `cacheRetention`, `context1m`). +- `params` : paramètres de fournisseur par défaut globaux appliqués à tous les modèles. À définir dans `agents.defaults.params` (par ex. `{ cacheRetention: "long" }`). +- Priorité de fusion de `params` (configuration) : `agents.defaults.params` (base globale) est remplacé par `agents.defaults.models["provider/model"].params` (par modèle), puis `agents.list[].params` (identifiant d’agent correspondant) remplace par clé. Voir [Prompt Caching](/fr/reference/prompt-caching) pour plus de détails. +- `embeddedHarness` : stratégie d’exécution intégrée bas niveau par défaut pour les agents. Utilisez `runtime: "auto"` pour laisser les harnais de Plugin enregistrés prendre en charge les modèles pris en charge, `runtime: "pi"` pour forcer le harnais PI intégré, ou un identifiant de harnais enregistré tel que `runtime: "codex"`. Définissez `fallback: "none"` pour désactiver le repli automatique vers PI. +- Les rédacteurs de configuration qui modifient ces champs (par exemple `/models set`, `/models set-image` et les commandes d’ajout/suppression de secours) enregistrent la forme objet canonique et préservent les listes de secours existantes lorsque c’est possible. +- `maxConcurrent` : nombre maximal d’exécutions parallèles d’agents entre les sessions (chaque session reste tout de même sérialisée). Par défaut : 4. ### `agents.defaults.embeddedHarness` -`embeddedHarness` contrôle quel exécuteur bas niveau traite les tours d’agent embarqués. +`embeddedHarness` contrôle quel exécuteur bas niveau exécute les tours d’agent intégrés. La plupart des déploiements devraient conserver la valeur par défaut `{ runtime: "auto", fallback: "pi" }`. -Utilisez-le lorsqu’un Plugin de confiance fournit un harness natif, comme le harness +Utilisez-le lorsqu’un Plugin de confiance fournit un harnais natif, comme le harnais groupé du serveur d’application Codex. ```json5 @@ -1272,34 +1263,34 @@ groupé du serveur d’application Codex. } ``` -- `runtime` : `"auto"`, `"pi"` ou un ID de harness de Plugin enregistré. Le Plugin Codex groupé enregistre `codex`. -- `fallback` : `"pi"` ou `"none"`. `"pi"` conserve le harness PI intégré comme repli de compatibilité. `"none"` fait échouer une sélection de harness de Plugin absente ou non prise en charge au lieu d’utiliser silencieusement PI. -- Remplacements d’environnement : `OPENCLAW_AGENT_RUNTIME=` remplace `runtime` ; `OPENCLAW_AGENT_HARNESS_FALLBACK=none` désactive le repli PI pour ce processus. +- `runtime` : `"auto"`, `"pi"` ou un identifiant de harnais de Plugin enregistré. Le Plugin Codex groupé enregistre `codex`. +- `fallback` : `"pi"` ou `"none"`. `"pi"` conserve le harnais PI intégré comme repli de compatibilité. `"none"` fait échouer la sélection d’un harnais de Plugin manquant ou non pris en charge au lieu d’utiliser silencieusement PI. +- Remplacements par environnement : `OPENCLAW_AGENT_RUNTIME=` remplace `runtime` ; `OPENCLAW_AGENT_HARNESS_FALLBACK=none` désactive le repli vers PI pour ce processus. - Pour les déploiements Codex uniquement, définissez `model: "codex/gpt-5.4"`, `embeddedHarness.runtime: "codex"` et `embeddedHarness.fallback: "none"`. -- Cela ne contrôle que le harness de chat embarqué. La génération de média, la vision, les PDF, la musique, la vidéo et le TTS utilisent toujours leurs paramètres fournisseur/modèle. +- Cela contrôle uniquement le harnais de discussion intégré. La génération de médias, la vision, le PDF, la musique, la vidéo et le TTS utilisent toujours leurs paramètres provider/model. -**Raccourcis d’alias intégrés** (s’appliquent uniquement lorsque le modèle figure dans `agents.defaults.models`) : +**Raccourcis d’alias intégrés** (s’appliquent uniquement lorsque le modèle se trouve dans `agents.defaults.models`) : -| Alias | Modèle | -| ------------------- | ------------------------------------- | -| `opus` | `anthropic/claude-opus-4-6` | -| `sonnet` | `anthropic/claude-sonnet-4-6` | -| `gpt` | `openai/gpt-5.4` | -| `gpt-mini` | `openai/gpt-5.4-mini` | -| `gpt-nano` | `openai/gpt-5.4-nano` | -| `gemini` | `google/gemini-3.1-pro-preview` | -| `gemini-flash` | `google/gemini-3-flash-preview` | +| Alias | Modèle | +| ------------------- | -------------------------------------- | +| `opus` | `anthropic/claude-opus-4-6` | +| `sonnet` | `anthropic/claude-sonnet-4-6` | +| `gpt` | `openai/gpt-5.4` | +| `gpt-mini` | `openai/gpt-5.4-mini` | +| `gpt-nano` | `openai/gpt-5.4-nano` | +| `gemini` | `google/gemini-3.1-pro-preview` | +| `gemini-flash` | `google/gemini-3-flash-preview` | | `gemini-flash-lite` | `google/gemini-3.1-flash-lite-preview` | Vos alias configurés ont toujours priorité sur les valeurs par défaut. -Les modèles Z.AI GLM-4.x activent automatiquement le mode thinking sauf si vous définissez `--thinking off` ou si vous définissez vous-même `agents.defaults.models["zai/"].params.thinking`. +Les modèles Z.AI GLM-4.x activent automatiquement le mode thinking sauf si vous définissez `--thinking off` ou définissez vous-même `agents.defaults.models["zai/"].params.thinking`. Les modèles Z.AI activent `tool_stream` par défaut pour le streaming des appels d’outils. Définissez `agents.defaults.models["zai/"].params.tool_stream` sur `false` pour le désactiver. -Les modèles Anthropic Claude 4.6 utilisent par défaut le mode thinking `adaptive` lorsqu’aucun niveau de thinking explicite n’est défini. +Les modèles Anthropic Claude 4.6 utilisent `adaptive` par défaut pour thinking lorsqu’aucun niveau explicite de thinking n’est défini. ### `agents.defaults.cliBackends` -Backends CLI facultatifs pour les exécutions de repli en texte seul (sans appels d’outil). Utile comme solution de secours lorsque les fournisseurs d’API échouent. +CLI backends facultatifs pour les exécutions de secours en texte seul (sans appels d’outils). Utile comme solution de secours lorsque les fournisseurs API échouent. ```json5 { @@ -1327,13 +1318,13 @@ Backends CLI facultatifs pour les exécutions de repli en texte seul (sans appel } ``` -- Les backends CLI sont orientés texte ; les outils sont toujours désactivés. +- Les CLI backends sont d’abord conçus pour le texte ; les outils sont toujours désactivés. - Les sessions sont prises en charge lorsque `sessionArg` est défini. -- Le passage d’images est pris en charge lorsque `imageArg` accepte des chemins de fichiers. +- Le passage direct d’images est pris en charge lorsque `imageArg` accepte des chemins de fichiers. ### `agents.defaults.systemPromptOverride` -Remplace l’intégralité du prompt système assemblé par OpenClaw par une chaîne fixe. À définir au niveau par défaut (`agents.defaults.systemPromptOverride`) ou par agent (`agents.list[].systemPromptOverride`). Les valeurs par agent ont priorité ; une valeur vide ou composée uniquement d’espaces est ignorée. Utile pour des expériences de prompt contrôlées. +Remplace l’intégralité de l’invite système assemblée par OpenClaw par une chaîne fixe. À définir au niveau par défaut (`agents.defaults.systemPromptOverride`) ou par agent (`agents.list[].systemPromptOverride`). Les valeurs par agent ont priorité ; une valeur vide ou composée uniquement d’espaces est ignorée. Utile pour des expériences contrôlées sur les invites. ```json5 { @@ -1347,7 +1338,7 @@ Remplace l’intégralité du prompt système assemblé par OpenClaw par une cha ### `agents.defaults.heartbeat` -Exécutions Heartbeat périodiques. +Exécutions périodiques de Heartbeat. ```json5 { @@ -1375,14 +1366,14 @@ Exécutions Heartbeat périodiques. ``` - `every` : chaîne de durée (ms/s/m/h). Par défaut : `30m` (authentification par clé API) ou `1h` (authentification OAuth). Définissez `0m` pour désactiver. -- `includeSystemPromptSection` : lorsqu’il vaut false, omet la section Heartbeat du prompt système et ignore l’injection de `HEARTBEAT.md` dans le contexte bootstrap. Par défaut : `true`. -- `suppressToolErrorWarnings` : lorsqu’il vaut true, supprime les charges utiles d’avertissement d’erreur d’outil pendant les exécutions Heartbeat. -- `timeoutSeconds` : durée maximale en secondes autorisée pour un tour d’agent Heartbeat avant interruption. Laissez non défini pour utiliser `agents.defaults.timeoutSeconds`. -- `directPolicy` : politique de livraison directe/DM. `allow` (par défaut) autorise la livraison à une cible directe. `block` supprime la livraison à une cible directe et émet `reason=dm-blocked`. -- `lightContext` : lorsqu’il vaut true, les exécutions Heartbeat utilisent un contexte bootstrap allégé et ne conservent que `HEARTBEAT.md` parmi les fichiers bootstrap du workspace. -- `isolatedSession` : lorsqu’il vaut true, chaque Heartbeat s’exécute dans une nouvelle session sans historique de conversation préalable. Même schéma d’isolation que le Cron `sessionTarget: "isolated"`. Réduit le coût en jetons par Heartbeat d’environ ~100K à ~2-5K jetons. -- Par agent : définissez `agents.list[].heartbeat`. Lorsqu’un agent quelconque définit `heartbeat`, **seuls ces agents** exécutent des Heartbeat. -- Les Heartbeat exécutent des tours d’agent complets — des intervalles plus courts consomment plus de jetons. +- `includeSystemPromptSection` : lorsque false, omet la section Heartbeat de l’invite système et ignore l’injection de `HEARTBEAT.md` dans le contexte d’initialisation. Par défaut : `true`. +- `suppressToolErrorWarnings` : lorsque true, supprime les charges utiles d’avertissement d’erreur d’outil pendant les exécutions Heartbeat. +- `timeoutSeconds` : durée maximale en secondes autorisée pour un tour d’agent Heartbeat avant son interruption. Laissez non défini pour utiliser `agents.defaults.timeoutSeconds`. +- `directPolicy` : stratégie de livraison directe/DM. `allow` (par défaut) autorise la livraison vers une cible directe. `block` supprime la livraison vers une cible directe et émet `reason=dm-blocked`. +- `lightContext` : lorsque true, les exécutions Heartbeat utilisent un contexte d’initialisation allégé et ne conservent que `HEARTBEAT.md` parmi les fichiers d’initialisation de l’espace de travail. +- `isolatedSession` : lorsque true, chaque exécution Heartbeat s’effectue dans une nouvelle session sans historique de conversation antérieur. Même modèle d’isolation que Cron `sessionTarget: "isolated"`. Réduit le coût en jetons par Heartbeat d’environ 100K à environ 2-5K jetons. +- Par agent : définissez `agents.list[].heartbeat`. Lorsqu’un agent définit `heartbeat`, **seuls ces agents** exécutent des Heartbeat. +- Les Heartbeat exécutent des tours d’agent complets — des intervalles plus courts consomment davantage de jetons. ### `agents.defaults.compaction` @@ -1412,19 +1403,19 @@ Exécutions Heartbeat périodiques. } ``` -- `mode` : `default` ou `safeguard` (résumé par blocs pour les longs historiques). Voir [Compaction](/fr/concepts/compaction). -- `provider` : ID d’un Plugin fournisseur de Compaction enregistré. Lorsqu’il est défini, le `summarize()` du fournisseur est appelé à la place du résumé LLM intégré. Revient à l’implémentation intégrée en cas d’échec. Définir un fournisseur force `mode: "safeguard"`. Voir [Compaction](/fr/concepts/compaction). -- `timeoutSeconds` : nombre maximal de secondes autorisé pour une opération unique de Compaction avant qu’OpenClaw ne l’interrompe. Par défaut : `900`. -- `identifierPolicy` : `strict` (par défaut), `off` ou `custom`. `strict` préfixe des consignes intégrées de conservation des identifiants opaques pendant le résumé de Compaction. -- `identifierInstructions` : texte personnalisé facultatif de conservation des identifiants utilisé lorsque `identifierPolicy=custom`. -- `postCompactionSections` : noms facultatifs de sections H2/H3 de `AGENTS.md` à réinjecter après Compaction. Par défaut : `["Session Startup", "Red Lines"]` ; définissez `[]` pour désactiver la réinjection. Lorsqu’il n’est pas défini ou qu’il est explicitement défini sur cette paire par défaut, les anciens en-têtes `Every Session`/`Safety` sont aussi acceptés comme repli hérité. -- `model` : remplacement facultatif `provider/model-id` pour le résumé de Compaction uniquement. Utilisez-le lorsque la session principale doit conserver un modèle mais que les résumés de Compaction doivent être exécutés sur un autre ; lorsqu’il n’est pas défini, la Compaction utilise le modèle principal de la session. -- `notifyUser` : lorsqu’il vaut `true`, envoie un bref avis à l’utilisateur au démarrage de la Compaction (par exemple, « Compactage du contexte... »). Désactivé par défaut afin que la Compaction reste silencieuse. -- `memoryFlush` : tour agentique silencieux avant la Compaction automatique pour stocker les mémoires durables. Ignoré lorsque le workspace est en lecture seule. +- `mode` : `default` ou `safeguard` (résumé par morceaux pour les historiques longs). Voir [Compaction](/fr/concepts/compaction). +- `provider` : identifiant d’un Plugin fournisseur de Compaction enregistré. Lorsqu’il est défini, la méthode `summarize()` du fournisseur est appelée à la place du résumé LLM intégré. Revient au comportement intégré en cas d’échec. Définir un fournisseur force `mode: "safeguard"`. Voir [Compaction](/fr/concepts/compaction). +- `timeoutSeconds` : nombre maximal de secondes autorisées pour une seule opération de Compaction avant qu’OpenClaw ne l’interrompe. Par défaut : `900`. +- `identifierPolicy` : `strict` (par défaut), `off` ou `custom`. `strict` préfixe des instructions intégrées de conservation des identifiants opaques pendant le résumé de Compaction. +- `identifierInstructions` : texte personnalisé facultatif de préservation des identifiants utilisé lorsque `identifierPolicy=custom`. +- `postCompactionSections` : noms facultatifs de sections H2/H3 d’AGENTS.md à réinjecter après Compaction. Par défaut : `["Session Startup", "Red Lines"]` ; définissez `[]` pour désactiver la réinjection. Lorsqu’il n’est pas défini ou est explicitement défini à cette paire par défaut, les anciens en-têtes `Every Session`/`Safety` sont également acceptés comme solution de repli héritée. +- `model` : remplacement facultatif `provider/model-id` pour le résumé de Compaction uniquement. Utilisez-le lorsque la session principale doit conserver un modèle mais que les résumés de Compaction doivent s’exécuter sur un autre ; lorsqu’il n’est pas défini, la Compaction utilise le modèle principal de la session. +- `notifyUser` : lorsque `true`, envoie une brève notification à l’utilisateur au démarrage de la Compaction (par exemple, « Compacting context... »). Désactivé par défaut pour garder la Compaction silencieuse. +- `memoryFlush` : tour agentique silencieux avant la Compaction automatique pour stocker des souvenirs durables. Ignoré lorsque l’espace de travail est en lecture seule. ### `agents.defaults.contextPruning` -Émonde les **anciens résultats d’outils** du contexte en mémoire avant l’envoi au LLM. **Ne modifie pas** l’historique de session sur le disque. +Élague les **anciens résultats d’outil** du contexte en mémoire avant l’envoi au LLM. Ne modifie **pas** l’historique de session sur disque. ```json5 { @@ -1448,23 +1439,23 @@ Exécutions Heartbeat périodiques. -- `mode: "cache-ttl"` active les passes d’émondage. -- `ttl` contrôle à quelle fréquence l’émondage peut être réexécuté (après le dernier accès au cache). -- L’émondage tronque d’abord partiellement les résultats d’outils surdimensionnés, puis efface complètement les anciens résultats d’outils si nécessaire. +- `mode: "cache-ttl"` active les passes d’élagage. +- `ttl` contrôle la fréquence à laquelle l’élagage peut être relancé (après le dernier accès au cache). +- L’élagage commence par tronquer légèrement les résultats d’outil surdimensionnés, puis efface complètement les résultats d’outil plus anciens si nécessaire. -**Le tronquage partiel** conserve le début + la fin et insère `...` au milieu. +**Soft-trim** conserve le début + la fin et insère `...` au milieu. -**L’effacement complet** remplace l’intégralité du résultat d’outil par le texte de remplacement. +**Hard-clear** remplace la totalité du résultat d’outil par l’espace réservé. Remarques : -- Les blocs d’image ne sont jamais tronqués/effacés. -- Les ratios sont basés sur les caractères (approximatifs), pas sur des comptes exacts de jetons. -- S’il existe moins de `keepLastAssistants` messages d’assistant, l’émondage est ignoré. +- Les blocs image ne sont jamais tronqués/effacés. +- Les ratios sont basés sur les caractères (approximatifs), pas sur un nombre exact de jetons. +- Si moins de `keepLastAssistants` messages d’assistant existent, l’élagage est ignoré. -Voir [Émondage de session](/fr/concepts/session-pruning) pour les détails de comportement. +Voir [Session Pruning](/fr/concepts/session-pruning) pour les détails du comportement. ### Streaming par blocs @@ -1482,13 +1473,13 @@ Voir [Émondage de session](/fr/concepts/session-pruning) pour les détails de c } ``` -- Les canaux autres que Telegram exigent `*.blockStreaming: true` explicite pour activer les réponses par blocs. +- Les canaux autres que Telegram nécessitent `*.blockStreaming: true` explicite pour activer les réponses par blocs. - Remplacements par canal : `channels..blockStreamingCoalesce` (et variantes par compte). Signal/Slack/Discord/Google Chat utilisent par défaut `minChars: 1500`. - `humanDelay` : pause aléatoire entre les réponses par blocs. `natural` = 800–2500ms. Remplacement par agent : `agents.list[].humanDelay`. -Voir [Streaming](/fr/concepts/streaming) pour le comportement et les détails de segmentation. +Voir [Streaming](/fr/concepts/streaming) pour le comportement et les détails de découpage. -### Indicateurs de frappe +### Indicateurs de saisie ```json5 { @@ -1504,13 +1495,13 @@ Voir [Streaming](/fr/concepts/streaming) pour le comportement et les détails de - Valeurs par défaut : `instant` pour les discussions directes/mentions, `message` pour les discussions de groupe sans mention. - Remplacements par session : `session.typingMode`, `session.typingIntervalSeconds`. -Voir [Indicateurs de frappe](/fr/concepts/typing-indicators). +Voir [Typing Indicators](/fr/concepts/typing-indicators). ### `agents.defaults.sandbox` -Sandboxing facultatif pour l’agent embarqué. Voir [Sandboxing](/fr/gateway/sandboxing) pour le guide complet. +Sandboxing facultatif pour l’agent intégré. Voir [Sandboxing](/fr/gateway/sandboxing) pour le guide complet. ```json5 { @@ -1605,52 +1596,52 @@ Sandboxing facultatif pour l’agent embarqué. Voir [Sandboxing](/fr/gateway/sa } ``` - + **Backend :** - `docker` : environnement d’exécution Docker local (par défaut) -- `ssh` : environnement d’exécution distant générique adossé à SSH +- `ssh` : environnement d’exécution distant générique basé sur SSH - `openshell` : environnement d’exécution OpenShell -Lorsque `backend: "openshell"` est sélectionné, les paramètres spécifiques à l’environnement d’exécution sont déplacés vers +Lorsque `backend: "openshell"` est sélectionné, les paramètres propres à l’exécution sont déplacés vers `plugins.entries.openshell.config`. **Configuration du backend SSH :** - `target` : cible SSH au format `user@host[:port]` - `command` : commande client SSH (par défaut : `ssh`) -- `workspaceRoot` : racine distante absolue utilisée pour les workspaces par portée +- `workspaceRoot` : racine distante absolue utilisée pour les espaces de travail par portée - `identityFile` / `certificateFile` / `knownHostsFile` : fichiers locaux existants transmis à OpenSSH -- `identityData` / `certificateData` / `knownHostsData` : contenus intégrés ou SecretRefs qu’OpenClaw matérialise dans des fichiers temporaires à l’exécution -- `strictHostKeyChecking` / `updateHostKeys` : réglages de politique de clé d’hôte OpenSSH +- `identityData` / `certificateData` / `knownHostsData` : contenus en ligne ou SecretRefs qu’OpenClaw matérialise dans des fichiers temporaires à l’exécution +- `strictHostKeyChecking` / `updateHostKeys` : paramètres de stratégie de clé d’hôte OpenSSH -**Priorité de l’authentification SSH :** +**Priorité d’authentification SSH :** - `identityData` a priorité sur `identityFile` - `certificateData` a priorité sur `certificateFile` - `knownHostsData` a priorité sur `knownHostsFile` -- Les valeurs `*Data` adossées à SecretRef sont résolues à partir de l’instantané actif du runtime des secrets avant le démarrage de la session sandbox +- Les valeurs `*Data` adossées à SecretRef sont résolues depuis l’instantané actif d’exécution des secrets avant le démarrage de la session sandbox **Comportement du backend SSH :** -- initialise le workspace distant une fois après création ou recréation -- puis conserve le workspace SSH distant comme canonique -- achemine `exec`, les outils de fichiers et les chemins média via SSH -- ne resynchronise pas automatiquement les modifications distantes vers l’hôte +- initialise l’espace de travail distant une fois après création ou recréation +- conserve ensuite l’espace de travail SSH distant comme canonique +- route `exec`, les outils de fichier et les chemins de médias via SSH +- ne resynchronise pas automatiquement vers l’hôte les modifications distantes - ne prend pas en charge les conteneurs de navigateur sandbox -**Accès au workspace :** +**Accès à l’espace de travail :** -- `none` : workspace sandbox par portée sous `~/.openclaw/sandboxes` -- `ro` : workspace sandbox à `/workspace`, workspace agent monté en lecture seule sur `/agent` -- `rw` : workspace agent monté en lecture/écriture sur `/workspace` +- `none` : espace de travail sandbox par portée sous `~/.openclaw/sandboxes` +- `ro` : espace de travail sandbox à `/workspace`, espace de travail agent monté en lecture seule à `/agent` +- `rw` : espace de travail agent monté en lecture/écriture à `/workspace` **Portée :** -- `session` : conteneur + workspace par session -- `agent` : un conteneur + workspace par agent (par défaut) -- `shared` : conteneur et workspace partagés (aucune isolation inter-sessions) +- `session` : conteneur + espace de travail par session +- `agent` : un conteneur + espace de travail par agent (par défaut) +- `shared` : conteneur et espace de travail partagés (pas d’isolation inter-sessions) **Configuration du Plugin OpenShell :** @@ -1680,30 +1671,30 @@ Lorsque `backend: "openshell"` est sélectionné, les paramètres spécifiques **Mode OpenShell :** -- `mirror` : initialise le distant à partir du local avant `exec`, resynchronise vers le local après `exec` ; le workspace local reste canonique -- `remote` : initialise le distant une fois lors de la création du sandbox, puis conserve le workspace distant comme canonique +- `mirror` : initialise le distant depuis le local avant `exec`, resynchronise après `exec` ; l’espace de travail local reste canonique +- `remote` : initialise le distant une fois lors de la création du sandbox, puis conserve l’espace de travail distant comme canonique -En mode `remote`, les modifications locales sur l’hôte effectuées en dehors d’OpenClaw ne sont pas automatiquement synchronisées dans le sandbox après l’étape d’initialisation. -Le transport s’effectue en SSH dans le sandbox OpenShell, mais le Plugin gère le cycle de vie du sandbox et la synchronisation miroir facultative. +En mode `remote`, les modifications locales sur l’hôte effectuées en dehors d’OpenClaw ne sont pas resynchronisées automatiquement dans le sandbox après l’étape d’initialisation. +Le transport utilise SSH vers le sandbox OpenShell, mais le Plugin gère le cycle de vie du sandbox et la synchronisation miroir facultative. -**`setupCommand`** s’exécute une fois après la création du conteneur (via `sh -lc`). Nécessite une sortie réseau, une racine accessible en écriture et l’utilisateur root. +**`setupCommand`** s’exécute une fois après la création du conteneur (via `sh -lc`). Nécessite une sortie réseau, une racine inscriptible et l’utilisateur root. **Les conteneurs utilisent par défaut `network: "none"`** — définissez `"bridge"` (ou un réseau bridge personnalisé) si l’agent a besoin d’un accès sortant. `"host"` est bloqué. `"container:"` est bloqué par défaut sauf si vous définissez explicitement -`sandbox.docker.dangerouslyAllowContainerNamespaceJoin: true` (mode « break-glass »). +`sandbox.docker.dangerouslyAllowContainerNamespaceJoin: true` (mode de dernier recours). -**Les pièces jointes entrantes** sont placées dans `media/inbound/*` dans le workspace actif. +**Les pièces jointes entrantes** sont placées dans `media/inbound/*` dans l’espace de travail actif. -**`docker.binds`** monte des répertoires hôte supplémentaires ; les montages globaux et par agent sont fusionnés. +**`docker.binds`** monte des répertoires hôtes supplémentaires ; les montages globaux et par agent sont fusionnés. -**Navigateur sandboxé** (`sandbox.browser.enabled`) : Chromium + CDP dans un conteneur. L’URL noVNC est injectée dans le prompt système. Ne nécessite pas `browser.enabled` dans `openclaw.json`. +**Navigateur sandboxé** (`sandbox.browser.enabled`) : Chromium + CDP dans un conteneur. L’URL noVNC est injectée dans l’invite système. Ne nécessite pas `browser.enabled` dans `openclaw.json`. L’accès observateur noVNC utilise l’authentification VNC par défaut et OpenClaw émet une URL à jeton de courte durée (au lieu d’exposer le mot de passe dans l’URL partagée). - `allowHostControl: false` (par défaut) empêche les sessions sandboxées de cibler le navigateur de l’hôte. -- `network` vaut par défaut `openclaw-sandbox-browser` (réseau bridge dédié). Définissez-le sur `bridge` uniquement si vous voulez explicitement une connectivité bridge globale. -- `cdpSourceRange` restreint éventuellement l’entrée CDP à la périphérie du conteneur à une plage CIDR (par exemple `172.21.0.1/32`). -- `sandbox.browser.binds` monte des répertoires hôte supplémentaires uniquement dans le conteneur du navigateur sandboxé. Lorsqu’il est défini (y compris `[]`), il remplace `docker.binds` pour le conteneur du navigateur. -- Les valeurs par défaut de lancement sont définies dans `scripts/sandbox-browser-entrypoint.sh` et réglées pour les hôtes de conteneurs : +- `network` vaut par défaut `openclaw-sandbox-browser` (réseau bridge dédié). Définissez `bridge` uniquement lorsque vous souhaitez explicitement une connectivité bridge globale. +- `cdpSourceRange` limite facultativement l’entrée CDP au bord du conteneur à une plage CIDR (par exemple `172.21.0.1/32`). +- `sandbox.browser.binds` monte des répertoires hôtes supplémentaires uniquement dans le conteneur du navigateur sandboxé. Lorsqu’il est défini (y compris `[]`), il remplace `docker.binds` pour le conteneur navigateur. +- Les valeurs de lancement par défaut sont définies dans `scripts/sandbox-browser-entrypoint.sh` et ajustées pour les hôtes de conteneur : - `--remote-debugging-address=127.0.0.1` - `--remote-debugging-port=` - `--user-data-dir=${HOME}/.chrome` @@ -1723,24 +1714,25 @@ L’accès observateur noVNC utilise l’authentification VNC par défaut et Ope - `--disable-extensions` (activé par défaut) - `--disable-3d-apis`, `--disable-software-rasterizer` et `--disable-gpu` sont activés par défaut et peuvent être désactivés avec - `OPENCLAW_BROWSER_DISABLE_GRAPHICS_FLAGS=0` si un usage WebGL/3D l’exige. + `OPENCLAW_BROWSER_DISABLE_GRAPHICS_FLAGS=0` si l’utilisation de WebGL/3D l’exige. - `OPENCLAW_BROWSER_DISABLE_EXTENSIONS=0` réactive les extensions si votre flux de travail en dépend. - `--renderer-process-limit=2` peut être modifié avec `OPENCLAW_BROWSER_RENDERER_PROCESS_LIMIT=` ; définissez `0` pour utiliser la limite de processus par défaut de Chromium. - plus `--no-sandbox` et `--disable-setuid-sandbox` lorsque `noSandbox` est activé. - - Les valeurs par défaut correspondent à la base de l’image du conteneur ; utilisez une image de navigateur personnalisée avec un point d’entrée personnalisé pour modifier les valeurs par défaut du conteneur. + - Les valeurs par défaut constituent la base de l’image conteneur ; utilisez une image de navigateur personnalisée avec un point + d’entrée personnalisé pour modifier les valeurs par défaut du conteneur. -Le sandboxing du navigateur et `sandbox.docker.binds` sont disponibles uniquement avec Docker. +Le sandboxing du navigateur et `sandbox.docker.binds` sont réservés à Docker. Construire les images : ```bash -scripts/sandbox-setup.sh # image sandbox principale -scripts/sandbox-browser-setup.sh # image de navigateur facultative +scripts/sandbox-setup.sh # main sandbox image +scripts/sandbox-browser-setup.sh # optional browser image ``` ### `agents.list` (remplacements par agent) @@ -1792,27 +1784,27 @@ scripts/sandbox-browser-setup.sh # image de navigateur facultative } ``` -- `id` : ID d’agent stable (obligatoire). -- `default` : lorsque plusieurs sont définis, le premier l’emporte (avertissement journalisé). Si aucun n’est défini, la première entrée de la liste est la valeur par défaut. -- `model` : la forme chaîne remplace uniquement `primary` ; la forme objet `{ primary, fallbacks }` remplace les deux (`[]` désactive les replis globaux). Les tâches Cron qui ne remplacent que `primary` héritent toujours des replis par défaut sauf si vous définissez `fallbacks: []`. -- `params` : paramètres de flux par agent fusionnés sur l’entrée de modèle sélectionnée dans `agents.defaults.models`. Utilisez cela pour des remplacements spécifiques à l’agent comme `cacheRetention`, `temperature` ou `maxTokens` sans dupliquer tout le catalogue de modèles. -- `skills` : liste d’autorisation de Skills facultative par agent. Si elle est omise, l’agent hérite de `agents.defaults.skills` lorsqu’elle est définie ; une liste explicite remplace les valeurs par défaut au lieu de les fusionner, et `[]` signifie aucun Skills. -- `thinkingDefault` : niveau de thinking par défaut facultatif par agent (`off | minimal | low | medium | high | xhigh | adaptive`). Remplace `agents.defaults.thinkingDefault` pour cet agent lorsqu’aucun remplacement par message ou session n’est défini. -- `reasoningDefault` : visibilité de reasoning par défaut facultative par agent (`on | off | stream`). S’applique lorsqu’aucun remplacement de reasoning par message ou session n’est défini. -- `fastModeDefault` : valeur par défaut facultative par agent pour le mode rapide (`true | false`). S’applique lorsqu’aucun remplacement de mode rapide par message ou session n’est défini. -- `embeddedHarness` : remplacement facultatif par agent de la politique de harness bas niveau. Utilisez `{ runtime: "codex", fallback: "none" }` pour rendre un agent réservé à Codex tandis que les autres agents conservent le repli PI par défaut. -- `runtime` : descripteur d’exécution facultatif par agent. Utilisez `type: "acp"` avec les valeurs par défaut `runtime.acp` (`agent`, `backend`, `mode`, `cwd`) lorsque l’agent doit utiliser par défaut des sessions harness ACP. -- `identity.avatar` : chemin relatif au workspace, URL `http(s)` ou URI `data:`. -- `identity` dérive des valeurs par défaut : `ackReaction` depuis `emoji`, `mentionPatterns` depuis `name`/`emoji`. -- `subagents.allowAgents` : liste d’autorisation des ID d’agents pour `sessions_spawn` (`["*"]` = n’importe lequel ; par défaut : même agent uniquement). -- Garde d’héritage du sandbox : si la session demandeuse est sandboxée, `sessions_spawn` rejette les cibles qui s’exécuteraient hors sandbox. -- `subagents.requireAgentId` : lorsqu’il vaut true, bloque les appels `sessions_spawn` qui omettent `agentId` (force une sélection explicite de profil ; par défaut : false). +- `id` : identifiant d’agent stable (obligatoire). +- `default` : lorsque plusieurs sont définis, le premier l’emporte (un avertissement est journalisé). Si aucun n’est défini, la première entrée de la liste est la valeur par défaut. +- `model` : la forme chaîne remplace uniquement `primary` ; la forme objet `{ primary, fallbacks }` remplace les deux (`[]` désactive les secours globaux). Les tâches Cron qui ne remplacent que `primary` héritent toujours des secours par défaut sauf si vous définissez `fallbacks: []`. +- `params` : paramètres de flux par agent fusionnés au-dessus de l’entrée de modèle sélectionnée dans `agents.defaults.models`. Utilisez ceci pour des remplacements spécifiques à l’agent comme `cacheRetention`, `temperature` ou `maxTokens` sans dupliquer tout le catalogue de modèles. +- `skills` : liste d’autorisation Skills facultative par agent. Si elle est omise, l’agent hérite de `agents.defaults.skills` lorsqu’elle est définie ; une liste explicite remplace les valeurs par défaut au lieu d’être fusionnée, et `[]` signifie aucune Skills. +- `thinkingDefault` : niveau de thinking facultatif par défaut par agent (`off | minimal | low | medium | high | xhigh | adaptive`). Remplace `agents.defaults.thinkingDefault` pour cet agent lorsqu’aucun remplacement par message ou par session n’est défini. +- `reasoningDefault` : visibilité du reasoning facultative par défaut par agent (`on | off | stream`). S’applique lorsqu’aucun remplacement de reasoning par message ou par session n’est défini. +- `fastModeDefault` : valeur par défaut facultative par agent pour le mode rapide (`true | false`). S’applique lorsqu’aucun remplacement de mode rapide par message ou par session n’est défini. +- `embeddedHarness` : remplacement facultatif par agent de la stratégie de harnais bas niveau. Utilisez `{ runtime: "codex", fallback: "none" }` pour rendre un agent exclusivement Codex tandis que d’autres agents conservent le repli PI par défaut. +- `runtime` : descripteur d’exécution facultatif par agent. Utilisez `type: "acp"` avec les valeurs par défaut `runtime.acp` (`agent`, `backend`, `mode`, `cwd`) lorsque l’agent doit utiliser par défaut des sessions de harnais ACP. +- `identity.avatar` : chemin relatif à l’espace de travail, URL `http(s)` ou URI `data:`. +- `identity` dérive les valeurs par défaut : `ackReaction` à partir de `emoji`, `mentionPatterns` à partir de `name`/`emoji`. +- `subagents.allowAgents` : liste d’autorisation des identifiants d’agent pour `sessions_spawn` (`["*"]` = n’importe lequel ; par défaut : le même agent uniquement). +- Garde-fou d’héritage du sandbox : si la session demandeuse est sandboxée, `sessions_spawn` rejette les cibles qui s’exécuteraient sans sandbox. +- `subagents.requireAgentId` : lorsque true, bloque les appels `sessions_spawn` qui omettent `agentId` (force une sélection explicite du profil ; par défaut : false). --- ## Routage multi-agent -Exécute plusieurs agents isolés dans un seul Gateway. Voir [Multi-Agent](/fr/concepts/multi-agent). +Exécutez plusieurs agents isolés dans une même Gateway. Voir [Multi-Agent](/fr/concepts/multi-agent). ```json5 { @@ -1829,14 +1821,14 @@ Exécute plusieurs agents isolés dans un seul Gateway. Voir [Multi-Agent](/fr/c } ``` -### Champs `match` des liaisons +### Champs de correspondance des liaisons -- `type` (facultatif) : `route` pour le routage normal (type manquant = route par défaut), `acp` pour les liaisons ACP persistantes de conversation. +- `type` (facultatif) : `route` pour le routage normal (si le type est absent, la valeur par défaut est route), `acp` pour les liaisons persistantes de conversation ACP. - `match.channel` (obligatoire) - `match.accountId` (facultatif ; `*` = n’importe quel compte ; omis = compte par défaut) - `match.peer` (facultatif ; `{ kind: direct|group|channel, id }`) - `match.guildId` / `match.teamId` (facultatif ; spécifique au canal) -- `acp` (facultatif ; uniquement pour `type: "acp"`) : `{ mode, label, cwd, backend }` +- `acp` (facultatif ; uniquement pour les entrées `type: "acp"`) : `{ mode, label, cwd, backend }` **Ordre de correspondance déterministe :** @@ -1847,9 +1839,9 @@ Exécute plusieurs agents isolés dans un seul Gateway. Voir [Multi-Agent](/fr/c 5. `match.accountId: "*"` (à l’échelle du canal) 6. Agent par défaut -À l’intérieur de chaque niveau, la première entrée `bindings` correspondante l’emporte. +Dans chaque niveau, la première entrée `bindings` correspondante l’emporte. -Pour les entrées `type: "acp"`, OpenClaw résout par identité exacte de conversation (`match.channel` + compte + `match.peer.id`) et n’utilise pas l’ordre par niveaux des liaisons de routage ci-dessus. +Pour les entrées `type: "acp"`, OpenClaw résout par identité exacte de conversation (`match.channel` + compte + `match.peer.id`) et n’utilise pas l’ordre de niveaux de liaisons de route ci-dessus. ### Profils d’accès par agent @@ -1871,7 +1863,7 @@ Pour les entrées `type: "acp"`, OpenClaw résout par identité exacte de conver - + ```json5 { @@ -1946,7 +1938,7 @@ Pour les entrées `type: "acp"`, OpenClaw résout par identité exacte de conver -Voir [Sandbox & outils multi-agent](/fr/tools/multi-agent-sandbox-tools) pour les détails de priorité. +Voir [Multi-Agent Sandbox & Tools](/fr/tools/multi-agent-sandbox-tools) pour les détails de priorité. --- @@ -1999,34 +1991,34 @@ Voir [Sandbox & outils multi-agent](/fr/tools/multi-agent-sandbox-tools) pour le -- **`scope`** : stratégie de base de regroupement des sessions pour les contextes de discussion de groupe. +- **`scope`** : stratégie de regroupement de session de base pour les contextes de discussion de groupe. - `per-sender` (par défaut) : chaque expéditeur obtient une session isolée dans un contexte de canal. - - `global` : tous les participants d’un contexte de canal partagent une seule session (à utiliser uniquement lorsqu’un contexte partagé est voulu). -- **`dmScope`** : façon dont les DM sont regroupés. + - `global` : tous les participants d’un contexte de canal partagent une seule session (à utiliser uniquement lorsqu’un contexte partagé est souhaité). +- **`dmScope`** : manière dont les DM sont regroupés. - `main` : tous les DM partagent la session principale. - - `per-peer` : isole par ID d’expéditeur entre les canaux. - - `per-channel-peer` : isole par canal + expéditeur (recommandé pour les boîtes de réception multi-utilisateurs). - - `per-account-channel-peer` : isole par compte + canal + expéditeur (recommandé pour le multi-compte). -- **`identityLinks`** : mappe les ID canoniques vers des pairs préfixés par fournisseur pour le partage de session inter-canaux. -- **`reset`** : politique de réinitialisation principale. `daily` réinitialise à `atHour` selon l’heure locale ; `idle` réinitialise après `idleMinutes`. Lorsque les deux sont configurés, la première échéance l’emporte. + - `per-peer` : isolation par identifiant d’expéditeur entre les canaux. + - `per-channel-peer` : isolation par canal + expéditeur (recommandé pour les boîtes de réception multi-utilisateurs). + - `per-account-channel-peer` : isolation par compte + canal + expéditeur (recommandé pour le multi-compte). +- **`identityLinks`** : mappe les identifiants canoniques aux pairs préfixés par fournisseur pour le partage de session entre canaux. +- **`reset`** : stratégie principale de réinitialisation. `daily` réinitialise à `atHour` heure locale ; `idle` réinitialise après `idleMinutes`. Lorsque les deux sont configurés, celui qui expire en premier l’emporte. - **`resetByType`** : remplacements par type (`direct`, `group`, `thread`). L’ancien `dm` est accepté comme alias de `direct`. -- **`parentForkMaxTokens`** : `totalTokens` maximal autorisé pour la session parente lors de la création d’une session de fil dérivée (par défaut `100000`). - - Si `totalTokens` de la parente dépasse cette valeur, OpenClaw démarre une nouvelle session de fil au lieu d’hériter de l’historique de transcription de la parente. - - Définissez `0` pour désactiver cette protection et toujours autoriser la dérivation depuis la parente. -- **`mainKey`** : champ hérité. L’exécution utilise toujours `"main"` pour le compartiment principal des discussions directes. -- **`agentToAgent.maxPingPongTurns`** : nombre maximal de tours de réponse aller-retour entre agents pendant les échanges agent-à-agent (entier, plage : `0`–`5`). `0` désactive l’enchaînement ping-pong. -- **`sendPolicy`** : correspondance par `channel`, `chatType` (`direct|group|channel`, avec l’alias hérité `dm`), `keyPrefix` ou `rawKeyPrefix`. Le premier refus l’emporte. -- **`maintenance`** : contrôles de nettoyage + rétention du stockage de session. +- **`parentForkMaxTokens`** : nombre maximal de `totalTokens` de session parent autorisé lors de la création d’une session de fil dérivée (par défaut `100000`). + - Si la valeur `totalTokens` du parent est supérieure à cette valeur, OpenClaw démarre une nouvelle session de fil au lieu d’hériter de l’historique de transcription du parent. + - Définissez `0` pour désactiver cette protection et toujours autoriser la dérivation depuis le parent. +- **`mainKey`** : champ hérité. L’exécution utilise toujours `"main"` pour le compartiment principal de discussion directe. +- **`agentToAgent.maxPingPongTurns`** : nombre maximal de tours de réponse réciproque entre agents lors des échanges agent à agent (entier, plage : `0`–`5`). `0` désactive l’enchaînement ping-pong. +- **`sendPolicy`** : correspondance par `channel`, `chatType` (`direct|group|channel`, avec l’ancien alias `dm`), `keyPrefix` ou `rawKeyPrefix`. Le premier refus l’emporte. +- **`maintenance`** : contrôles de nettoyage et de rétention du stockage de session. - `mode` : `warn` émet uniquement des avertissements ; `enforce` applique le nettoyage. - `pruneAfter` : seuil d’ancienneté pour les entrées obsolètes (par défaut `30d`). - `maxEntries` : nombre maximal d’entrées dans `sessions.json` (par défaut `500`). - - `rotateBytes` : fait pivoter `sessions.json` lorsqu’il dépasse cette taille (par défaut `10mb`). - - `resetArchiveRetention` : rétention pour les archives de transcription `*.reset.`. Par défaut, hérite de `pruneAfter` ; définissez `false` pour désactiver. + - `rotateBytes` : effectue une rotation de `sessions.json` lorsqu’il dépasse cette taille (par défaut `10mb`). + - `resetArchiveRetention` : rétention pour les archives de transcription `*.reset.`. Par défaut, utilise `pruneAfter` ; définissez `false` pour désactiver. - `maxDiskBytes` : budget disque facultatif pour le répertoire des sessions. En mode `warn`, journalise des avertissements ; en mode `enforce`, supprime d’abord les artefacts/sessions les plus anciens. - - `highWaterBytes` : cible facultative après nettoyage du budget. Par défaut : `80%` de `maxDiskBytes`. -- **`threadBindings`** : valeurs globales par défaut pour les fonctionnalités de session liées aux fils. + - `highWaterBytes` : cible facultative après nettoyage du budget. Par défaut, `80%` de `maxDiskBytes`. +- **`threadBindings`** : valeurs par défaut globales pour les fonctionnalités de session liées aux fils. - `enabled` : interrupteur maître par défaut (les fournisseurs peuvent le remplacer ; Discord utilise `channels.discord.threadBindings.enabled`) - - `idleHours` : perte de focus automatique par défaut après inactivité en heures (`0` désactive ; les fournisseurs peuvent remplacer) + - `idleHours` : retrait automatique du focus par défaut après inactivité, en heures (`0` désactive ; les fournisseurs peuvent remplacer) - `maxAgeHours` : âge maximal strict par défaut en heures (`0` désactive ; les fournisseurs peuvent remplacer) @@ -2071,30 +2063,30 @@ Résolution (le plus spécifique l’emporte) : compte → canal → global. `" **Variables de modèle :** -| Variable | Description | Exemple | -| ----------------- | ------------------------- | --------------------------- | -| `{model}` | Nom court du modèle | `claude-opus-4-6` | +| Variable | Description | Exemple | +| ----------------- | ---------------------- | --------------------------- | +| `{model}` | Nom court du modèle | `claude-opus-4-6` | | `{modelFull}` | Identifiant complet du modèle | `anthropic/claude-opus-4-6` | -| `{provider}` | Nom du fournisseur | `anthropic` | -| `{thinkingLevel}` | Niveau de thinking actuel | `high`, `low`, `off` | +| `{provider}` | Nom du fournisseur | `anthropic` | +| `{thinkingLevel}` | Niveau actuel de thinking | `high`, `low`, `off` | | `{identity.name}` | Nom d’identité de l’agent | (identique à `"auto"`) | -Les variables sont insensibles à la casse. `{think}` est un alias de `{thinkingLevel}`. +Les variables ne sont pas sensibles à la casse. `{think}` est un alias de `{thinkingLevel}`. -### Réaction d’accusé +### Réaction d’accusé de réception - Par défaut, utilise `identity.emoji` de l’agent actif, sinon `"👀"`. Définissez `""` pour désactiver. - Remplacements par canal : `channels..ackReaction`, `channels..accounts..ackReaction`. - Ordre de résolution : compte → canal → `messages.ackReaction` → repli d’identité. - Portée : `group-mentions` (par défaut), `group-all`, `direct`, `all`. -- `removeAckAfterReply` supprime l’accusé après la réponse sur Slack, Discord et Telegram. -- `messages.statusReactions.enabled` active les réactions d’état du cycle de vie sur Slack, Discord et Telegram. - Sur Slack et Discord, non défini conserve les réactions d’état actives lorsque les réactions d’accusé sont actives. +- `removeAckAfterReply` : supprime l’accusé de réception après la réponse sur Slack, Discord et Telegram. +- `messages.statusReactions.enabled` : active les réactions d’état du cycle de vie sur Slack, Discord et Telegram. + Sur Slack et Discord, si non défini, les réactions d’état restent activées lorsque les réactions d’accusé de réception sont actives. Sur Telegram, définissez-le explicitement sur `true` pour activer les réactions d’état du cycle de vie. -### Antirebond entrant +### Débounce entrant -Regroupe les messages texte rapides d’un même expéditeur en un seul tour d’agent. Les médias/pièces jointes déclenchent un vidage immédiat. Les commandes de contrôle contournent l’antirebond. +Regroupe les messages texte rapides du même expéditeur en un seul tour d’agent. Les médias/pièces jointes déclenchent immédiatement l’envoi. Les commandes de contrôle contournent le debounce. ### TTS (synthèse vocale) @@ -2137,18 +2129,18 @@ Regroupe les messages texte rapides d’un même expéditeur en un seul tour d } ``` -- `auto` contrôle le mode d’auto-TTS par défaut : `off`, `always`, `inbound` ou `tagged`. `/tts on|off` peut remplacer les préférences locales, et `/tts status` affiche l’état effectif. -- `summaryModel` remplace `agents.defaults.model.primary` pour l’auto-résumé. -- `modelOverrides` est activé par défaut ; `modelOverrides.allowProvider` vaut par défaut `false` (activation explicite requise). -- Les clés API reviennent à `ELEVENLABS_API_KEY`/`XI_API_KEY` et `OPENAI_API_KEY`. -- `openai.baseUrl` remplace le point de terminaison OpenAI TTS. L’ordre de résolution est : configuration, puis `OPENAI_TTS_BASE_URL`, puis `https://api.openai.com/v1`. +- `auto` contrôle le mode auto-TTS par défaut : `off`, `always`, `inbound` ou `tagged`. `/tts on|off` peut remplacer les préférences locales, et `/tts status` affiche l’état effectif. +- `summaryModel` remplace `agents.defaults.model.primary` pour le résumé automatique. +- `modelOverrides` est activé par défaut ; `modelOverrides.allowProvider` vaut `false` par défaut (activation explicite requise). +- Les clés API utilisent `ELEVENLABS_API_KEY`/`XI_API_KEY` et `OPENAI_API_KEY` comme solutions de repli. +- `openai.baseUrl` remplace le point de terminaison TTS OpenAI. L’ordre de résolution est : configuration, puis `OPENAI_TTS_BASE_URL`, puis `https://api.openai.com/v1`. - Lorsque `openai.baseUrl` pointe vers un point de terminaison non OpenAI, OpenClaw le traite comme un serveur TTS compatible OpenAI et assouplit la validation du modèle/de la voix. --- ## Talk -Valeurs par défaut du mode Talk (macOS/iOS/Android). +Valeurs par défaut pour le mode Talk (macOS/iOS/Android). ```json5 { @@ -2172,13 +2164,13 @@ Valeurs par défaut du mode Talk (macOS/iOS/Android). } ``` -- `talk.provider` doit correspondre à une clé de `talk.providers` lorsque plusieurs fournisseurs Talk sont configurés. -- Les anciennes clés Talk plates (`talk.voiceId`, `talk.voiceAliases`, `talk.modelId`, `talk.outputFormat`, `talk.apiKey`) sont compatibles uniquement et sont migrées automatiquement vers `talk.providers.`. -- Les ID de voix reviennent à `ELEVENLABS_VOICE_ID` ou `SAG_VOICE_ID`. -- `providers.*.apiKey` accepte des chaînes en clair ou des objets SecretRef. -- Le repli `ELEVENLABS_API_KEY` ne s’applique que lorsqu’aucune clé API Talk n’est configurée. +- `talk.provider` doit correspondre à une clé dans `talk.providers` lorsque plusieurs fournisseurs Talk sont configurés. +- Les anciennes clés Talk à plat (`talk.voiceId`, `talk.voiceAliases`, `talk.modelId`, `talk.outputFormat`, `talk.apiKey`) sont uniquement conservées pour compatibilité et sont migrées automatiquement vers `talk.providers.`. +- Les identifiants de voix utilisent `ELEVENLABS_VOICE_ID` ou `SAG_VOICE_ID` comme solution de repli. +- `providers.*.apiKey` accepte des chaînes en texte brut ou des objets SecretRef. +- La solution de repli `ELEVENLABS_API_KEY` s’applique uniquement lorsqu’aucune clé API Talk n’est configurée. - `providers.*.voiceAliases` permet aux directives Talk d’utiliser des noms conviviaux. -- `silenceTimeoutMs` contrôle combien de temps le mode Talk attend après le silence de l’utilisateur avant d’envoyer la transcription. Non défini conserve la fenêtre de pause par défaut de la plateforme (`700 ms sur macOS et Android, 900 ms sur iOS`). +- `silenceTimeoutMs` contrôle combien de temps le mode Talk attend après le silence de l’utilisateur avant d’envoyer la transcription. Si non défini, conserve la fenêtre de pause par défaut de la plateforme (`700 ms sur macOS et Android, 900 ms sur iOS`). --- @@ -2190,33 +2182,33 @@ Valeurs par défaut du mode Talk (macOS/iOS/Android). L’intégration locale définit par défaut les nouvelles configurations locales sur `tools.profile: "coding"` lorsqu’il n’est pas défini (les profils explicites existants sont conservés). -| Profil | Inclut | -| ----------- | ------------------------------------------------------------------------------------------------------------------------------ | -| `minimal` | `session_status` uniquement | +| Profil | Comprend | +| ----------- | -------------------------------------------------------------------------------------------------------------------------------- | +| `minimal` | `session_status` uniquement | | `coding` | `group:fs`, `group:runtime`, `group:web`, `group:sessions`, `group:memory`, `cron`, `image`, `image_generate`, `video_generate` | -| `messaging` | `group:messaging`, `sessions_list`, `sessions_history`, `sessions_send`, `session_status` | -| `full` | Aucune restriction (identique à non défini) | +| `messaging` | `group:messaging`, `sessions_list`, `sessions_history`, `sessions_send`, `session_status` | +| `full` | Aucune restriction (identique à non défini) | ### Groupes d’outils | Groupe | Outils | | ------------------ | ----------------------------------------------------------------------------------------------------------------------- | | `group:runtime` | `exec`, `process`, `code_execution` (`bash` est accepté comme alias de `exec`) | -| `group:fs` | `read`, `write`, `edit`, `apply_patch` | +| `group:fs` | `read`, `write`, `edit`, `apply_patch` | | `group:sessions` | `sessions_list`, `sessions_history`, `sessions_send`, `sessions_spawn`, `sessions_yield`, `subagents`, `session_status` | -| `group:memory` | `memory_search`, `memory_get` | -| `group:web` | `web_search`, `x_search`, `web_fetch` | -| `group:ui` | `browser`, `canvas` | -| `group:automation` | `cron`, `gateway` | -| `group:messaging` | `message` | -| `group:nodes` | `nodes` | -| `group:agents` | `agents_list` | -| `group:media` | `image`, `image_generate`, `video_generate`, `tts` | -| `group:openclaw` | Tous les outils intégrés (hors plugins fournisseurs) | +| `group:memory` | `memory_search`, `memory_get` | +| `group:web` | `web_search`, `x_search`, `web_fetch` | +| `group:ui` | `browser`, `canvas` | +| `group:automation` | `cron`, `gateway` | +| `group:messaging` | `message` | +| `group:nodes` | `nodes` | +| `group:agents` | `agents_list` | +| `group:media` | `image`, `image_generate`, `video_generate`, `tts` | +| `group:openclaw` | Tous les outils intégrés (hors plugins fournisseurs) | ### `tools.allow` / `tools.deny` -Politique globale d’autorisation/refus des outils (le refus l’emporte). Insensible à la casse, prend en charge les jokers `*`. S’applique même lorsque le sandbox Docker est désactivé. +Stratégie globale d’autorisation/refus des outils (le refus l’emporte). Insensible à la casse, prend en charge les jokers `*`. S’applique même lorsque le sandbox Docker est désactivé. ```json5 { @@ -2242,7 +2234,7 @@ Restreint davantage les outils pour des fournisseurs ou modèles spécifiques. O ### `tools.elevated` -Contrôle l’accès `exec` élevé hors du sandbox : +Contrôle l’accès `exec` élevé en dehors du sandbox : ```json5 { @@ -2260,7 +2252,7 @@ Contrôle l’accès `exec` élevé hors du sandbox : - Le remplacement par agent (`agents.list[].tools.elevated`) ne peut que restreindre davantage. - `/elevated on|off|ask|full` stocke l’état par session ; les directives en ligne s’appliquent à un seul message. -- L’`exec` élevé contourne le sandboxing et utilise le chemin d’échappement configuré (`gateway` par défaut, ou `node` lorsque la cible d’exécution est `node`). +- `exec` élevé contourne le sandboxing et utilise le chemin d’échappement configuré (`gateway` par défaut, ou `node` lorsque la cible `exec` est `node`). ### `tools.exec` @@ -2284,7 +2276,7 @@ Contrôle l’accès `exec` élevé hors du sandbox : ### `tools.loopDetection` -Les vérifications de sécurité contre les boucles d’outils sont **désactivées par défaut**. Définissez `enabled: true` pour activer la détection. +Les vérifications de sécurité de boucle d’outil sont **désactivées par défaut**. Définissez `enabled: true` pour activer la détection. Les paramètres peuvent être définis globalement dans `tools.loopDetection` et remplacés par agent dans `agents.list[].tools.loopDetection`. ```json5 @@ -2306,13 +2298,13 @@ Les paramètres peuvent être définis globalement dans `tools.loopDetection` et } ``` -- `historySize` : historique maximal des appels d’outils conservé pour l’analyse des boucles. -- `warningThreshold` : seuil de motif répétitif sans progression pour les avertissements. +- `historySize` : nombre maximal d’appels d’outil conservés pour l’analyse de boucle. +- `warningThreshold` : seuil d’avertissement pour les motifs répétitifs sans progression. - `criticalThreshold` : seuil répétitif plus élevé pour bloquer les boucles critiques. - `globalCircuitBreakerThreshold` : seuil d’arrêt strict pour toute exécution sans progression. -- `detectors.genericRepeat` : avertit en cas d’appels répétés au même outil avec les mêmes arguments. -- `detectors.knownPollNoProgress` : avertit/bloque pour les outils d’interrogation connus (`process.poll`, `command_status`, etc.). -- `detectors.pingPong` : avertit/bloque pour les motifs alternés de paires sans progression. +- `detectors.genericRepeat` : avertit en cas d’appels répétés du même outil/avec les mêmes arguments. +- `detectors.knownPollNoProgress` : avertit/bloque sur des outils de sondage connus (`process.poll`, `command_status`, etc.). +- `detectors.pingPong` : avertit/bloque sur les motifs alternés de paires sans progression. - Si `warningThreshold >= criticalThreshold` ou `criticalThreshold >= globalCircuitBreakerThreshold`, la validation échoue. ### `tools.web` @@ -2379,13 +2371,13 @@ Configure la compréhension des médias entrants (image/audio/vidéo) : } ``` - + **Entrée fournisseur** (`type: "provider"` ou omis) : -- `provider` : ID du fournisseur d’API (`openai`, `anthropic`, `google`/`gemini`, `groq`, etc.) -- `model` : remplacement de l’ID du modèle -- `profile` / `preferredProfile` : sélection de profil `auth-profiles.json` +- `provider` : identifiant du fournisseur API (`openai`, `anthropic`, `google`/`gemini`, `groq`, etc.) +- `model` : remplacement d’identifiant de modèle +- `profile` / `preferredProfile` : sélection du profil dans `auth-profiles.json` **Entrée CLI** (`type: "cli"`) : @@ -2396,15 +2388,15 @@ Configure la compréhension des médias entrants (image/audio/vidéo) : - `capabilities` : liste facultative (`image`, `audio`, `video`). Valeurs par défaut : `openai`/`anthropic`/`minimax` → image, `google` → image+audio+video, `groq` → audio. - `prompt`, `maxChars`, `maxBytes`, `timeoutSeconds`, `language` : remplacements par entrée. -- En cas d’échec, bascule vers l’entrée suivante. +- Les échecs se rabattent sur l’entrée suivante. L’authentification fournisseur suit l’ordre standard : `auth-profiles.json` → variables d’environnement → `models.providers.*.apiKey`. -**Champs de fin asynchrone :** +**Champs de complétion asynchrone :** -- `asyncCompletion.directSend` : lorsqu’il vaut `true`, les tâches asynchrones terminées `music_generate` - et `video_generate` tentent d’abord une livraison directe au canal. Par défaut : `false` - (ancien chemin de réveil de session demandeuse/livraison par modèle). +- `asyncCompletion.directSend` : lorsque `true`, les tâches asynchrones terminées `music_generate` + et `video_generate` essaient d’abord une livraison directe au canal. Par défaut : `false` + (ancien chemin de réveil de session du demandeur/livraison par modèle). @@ -2425,7 +2417,7 @@ L’authentification fournisseur suit l’ordre standard : `auth-profiles.json` Contrôle quelles sessions peuvent être ciblées par les outils de session (`sessions_list`, `sessions_history`, `sessions_send`). -Par défaut : `tree` (session actuelle + sessions engendrées par elle, comme les sous-agents). +Par défaut : `tree` (session actuelle + sessions engendrées par celle-ci, comme les sous-agents). ```json5 { @@ -2442,13 +2434,13 @@ Remarques : - `self` : uniquement la clé de session actuelle. - `tree` : session actuelle + sessions engendrées par la session actuelle (sous-agents). -- `agent` : toute session appartenant à l’ID d’agent actuel (peut inclure d’autres utilisateurs si vous utilisez des sessions par expéditeur sous le même ID d’agent). -- `all` : toute session. Le ciblage inter-agents exige toujours `tools.agentToAgent`. -- Restriction sandbox : lorsque la session actuelle est sandboxée et que `agents.defaults.sandbox.sessionToolsVisibility="spawned"`, la visibilité est forcée à `tree` même si `tools.sessions.visibility="all"`. +- `agent` : toute session appartenant à l’identifiant d’agent actuel (peut inclure d’autres utilisateurs si vous exécutez des sessions par expéditeur sous le même identifiant d’agent). +- `all` : n’importe quelle session. Le ciblage inter-agents nécessite toujours `tools.agentToAgent`. +- Restriction de sandbox : lorsque la session actuelle est sandboxée et que `agents.defaults.sandbox.sessionToolsVisibility="spawned"`, la visibilité est forcée à `tree` même si `tools.sessions.visibility="all"`. ### `tools.sessions_spawn` -Contrôle la prise en charge des pièces jointes intégrées pour `sessions_spawn`. +Contrôle la prise en charge des pièces jointes en ligne pour `sessions_spawn`. ```json5 { @@ -2468,16 +2460,16 @@ Contrôle la prise en charge des pièces jointes intégrées pour `sessions_spaw Remarques : -- Les pièces jointes ne sont prises en charge que pour `runtime: "subagent"`. Le runtime ACP les rejette. -- Les fichiers sont matérialisés dans le workspace enfant sous `.openclaw/attachments//` avec un `.manifest.json`. -- Le contenu des pièces jointes est automatiquement caviardé dans la persistance de transcription. -- Les entrées base64 sont validées avec des vérifications strictes d’alphabet/remplissage et une protection de taille avant décodage. -- Les permissions sont `0700` pour les répertoires et `0600` pour les fichiers. -- Le nettoyage suit la politique `cleanup` : `delete` supprime toujours les pièces jointes ; `keep` ne les conserve que lorsque `retainOnSessionKeep: true`. +- Les pièces jointes ne sont prises en charge que pour `runtime: "subagent"`. L’exécution ACP les rejette. +- Les fichiers sont matérialisés dans l’espace de travail enfant sous `.openclaw/attachments//` avec un `.manifest.json`. +- Le contenu des pièces jointes est automatiquement caviardé de la persistance de transcription. +- Les entrées Base64 sont validées avec des vérifications strictes de l’alphabet/du padding et une protection de taille avant décodage. +- Les permissions de fichiers sont `0700` pour les répertoires et `0600` pour les fichiers. +- Le nettoyage suit la stratégie `cleanup` : `delete` supprime toujours les pièces jointes ; `keep` ne les conserve que lorsque `retainOnSessionKeep: true`. ### `tools.experimental` -Indicateurs expérimentaux d’outils intégrés. Désactivés par défaut sauf lorsqu’une règle d’activation automatique stricte-agentique GPT-5 s’applique. +Indicateurs expérimentaux des outils intégrés. Désactivés par défaut sauf lorsqu’une règle d’activation automatique stricte agentique GPT-5 s’applique. ```json5 { @@ -2491,9 +2483,9 @@ Indicateurs expérimentaux d’outils intégrés. Désactivés par défaut sauf Remarques : -- `planTool` : active l’outil structuré expérimental `update_plan` pour le suivi de travaux non triviaux à plusieurs étapes. -- Par défaut : `false` sauf si `agents.defaults.embeddedPi.executionContract` (ou un remplacement par agent) est défini sur `"strict-agentic"` pour une exécution OpenAI ou OpenAI Codex de la famille GPT-5. Définissez `true` pour forcer l’activation hors de ce cadre, ou `false` pour le laisser désactivé même pour les exécutions GPT-5 strict-agentiques. -- Lorsqu’il est activé, le prompt système ajoute également des consignes d’utilisation afin que le modèle ne l’utilise que pour un travail substantiel et conserve au plus une étape `in_progress`. +- `planTool` : active l’outil structuré `update_plan` pour le suivi de travaux non triviaux à plusieurs étapes. +- Par défaut : `false` sauf si `agents.defaults.embeddedPi.executionContract` (ou un remplacement par agent) est défini sur `"strict-agentic"` pour une exécution OpenAI ou OpenAI Codex de la famille GPT-5. Définissez `true` pour forcer l’activation de l’outil hors de ce cadre, ou `false` pour le conserver désactivé même pour les exécutions GPT-5 strictement agentiques. +- Lorsqu’il est activé, l’invite système ajoute aussi des instructions d’utilisation afin que le modèle ne l’utilise que pour des travaux substantiels et conserve au plus une étape `in_progress`. ### `agents.defaults.subagents` @@ -2514,15 +2506,15 @@ Remarques : ``` - `model` : modèle par défaut pour les sous-agents engendrés. S’il est omis, les sous-agents héritent du modèle de l’appelant. -- `allowAgents` : liste d’autorisation par défaut des ID d’agents cibles pour `sessions_spawn` lorsque l’agent demandeur ne définit pas son propre `subagents.allowAgents` (`["*"]` = n’importe lequel ; par défaut : même agent uniquement). -- `runTimeoutSeconds` : délai d’expiration par défaut (en secondes) pour `sessions_spawn` lorsque l’appel d’outil omet `runTimeoutSeconds`. `0` signifie aucun délai. -- Politique d’outils par sous-agent : `tools.subagents.tools.allow` / `tools.subagents.tools.deny`. +- `allowAgents` : liste d’autorisation par défaut des identifiants d’agent cibles pour `sessions_spawn` lorsque l’agent demandeur ne définit pas son propre `subagents.allowAgents` (`["*"]` = n’importe lequel ; par défaut : le même agent uniquement). +- `runTimeoutSeconds` : délai d’expiration par défaut (secondes) pour `sessions_spawn` lorsque l’appel d’outil omet `runTimeoutSeconds`. `0` signifie aucune expiration. +- Stratégie d’outil par sous-agent : `tools.subagents.tools.allow` / `tools.subagents.tools.deny`. --- -## Fournisseurs personnalisés et URL de base +## Fournisseurs personnalisés et URLs de base -OpenClaw utilise le catalogue intégré de modèles. Ajoutez des fournisseurs personnalisés via `models.providers` dans la configuration ou `~/.openclaw/agents//agent/models.json`. +OpenClaw utilise le catalogue de modèles intégré. Ajoutez des fournisseurs personnalisés via `models.providers` dans la configuration ou `~/.openclaw/agents//agent/models.json`. ```json5 { @@ -2552,47 +2544,47 @@ OpenClaw utilise le catalogue intégré de modèles. Ajoutez des fournisseurs pe ``` - Utilisez `authHeader: true` + `headers` pour des besoins d’authentification personnalisés. -- Remplacez la racine de configuration agent avec `OPENCLAW_AGENT_DIR` (ou `PI_CODING_AGENT_DIR`, alias hérité de variable d’environnement). -- Priorité de fusion pour les ID de fournisseur correspondants : - - Les valeurs `baseUrl` d’agent `models.json` non vides l’emportent. - - Les valeurs `apiKey` d’agent non vides l’emportent uniquement lorsque ce fournisseur n’est pas géré par SecretRef dans le contexte actuel de configuration/profil d’authentification. - - Les valeurs `apiKey` de fournisseur gérées par SecretRef sont rafraîchies depuis les marqueurs de source (`ENV_VAR_NAME` pour les références d’environnement, `secretref-managed` pour les références fichier/exec) au lieu de persister les secrets résolus. - - Les valeurs d’en-tête de fournisseur gérées par SecretRef sont rafraîchies depuis les marqueurs de source (`secretref-env:ENV_VAR_NAME` pour les références d’environnement, `secretref-managed` pour les références fichier/exec). - - Les `apiKey`/`baseUrl` d’agent vides ou absents reviennent à `models.providers` dans la configuration. - - Les `contextWindow`/`maxTokens` des modèles correspondants utilisent la valeur la plus élevée entre la configuration explicite et les valeurs implicites du catalogue. - - Les `contextTokens` des modèles correspondants conservent un plafond d’exécution explicite lorsqu’il est présent ; utilisez-le pour limiter le contexte effectif sans modifier les métadonnées natives du modèle. - - Utilisez `models.mode: "replace"` lorsque vous voulez que la configuration réécrive entièrement `models.json`. - - La persistance des marqueurs est pilotée par la source : les marqueurs sont écrits à partir de l’instantané actif de la configuration source (avant résolution), et non à partir des valeurs secrètes d’exécution résolues. +- Remplacez la racine de configuration de l’agent avec `OPENCLAW_AGENT_DIR` (ou `PI_CODING_AGENT_DIR`, alias hérité de variable d’environnement). +- Priorité de fusion pour les identifiants de fournisseur correspondants : + - Les valeurs non vides `baseUrl` de `models.json` de l’agent l’emportent. + - Les valeurs non vides `apiKey` de l’agent l’emportent uniquement lorsque ce fournisseur n’est pas géré par SecretRef dans le contexte actuel de configuration/profil d’authentification. + - Les valeurs `apiKey` de fournisseur gérées par SecretRef sont actualisées à partir des marqueurs source (`ENV_VAR_NAME` pour les références d’environnement, `secretref-managed` pour les références fichier/exec) au lieu de persister les secrets résolus. + - Les valeurs d’en-tête de fournisseur gérées par SecretRef sont actualisées à partir des marqueurs source (`secretref-env:ENV_VAR_NAME` pour les références d’environnement, `secretref-managed` pour les références fichier/exec). + - Les valeurs `apiKey`/`baseUrl` d’agent vides ou absentes se rabattent sur `models.providers` dans la configuration. + - Les valeurs `contextWindow`/`maxTokens` du modèle correspondant utilisent la valeur la plus élevée entre la configuration explicite et les valeurs implicites du catalogue. + - Les valeurs `contextTokens` du modèle correspondant conservent une limite explicite d’exécution lorsqu’elle est présente ; utilisez-la pour limiter le contexte effectif sans modifier les métadonnées natives du modèle. + - Utilisez `models.mode: "replace"` lorsque vous voulez que la configuration réécrive complètement `models.json`. + - La persistance des marqueurs est pilotée par la source : les marqueurs sont écrits depuis l’instantané de configuration source active (avant résolution), et non depuis les valeurs secrètes résolues à l’exécution. -### Détails des champs fournisseur +### Détails des champs du fournisseur - `models.mode` : comportement du catalogue de fournisseurs (`merge` ou `replace`). -- `models.providers` : map de fournisseurs personnalisés indexée par ID de fournisseur. +- `models.providers` : mappe des fournisseurs personnalisés indexée par identifiant de fournisseur. - `models.providers.*.api` : adaptateur de requête (`openai-completions`, `openai-responses`, `anthropic-messages`, `google-generative-ai`, etc.). -- `models.providers.*.apiKey` : identifiant de fournisseur (préférez SecretRef / la substitution d’environnement). +- `models.providers.*.apiKey` : identifiant du fournisseur (préférez SecretRef/la substitution par variable d’environnement). - `models.providers.*.auth` : stratégie d’authentification (`api-key`, `token`, `oauth`, `aws-sdk`). - `models.providers.*.injectNumCtxForOpenAICompat` : pour Ollama + `openai-completions`, injecte `options.num_ctx` dans les requêtes (par défaut : `true`). -- `models.providers.*.authHeader` : force le transport de l’identifiant dans l’en-tête `Authorization` lorsque requis. -- `models.providers.*.baseUrl` : URL de base de l’API en amont. +- `models.providers.*.authHeader` : force le transport des identifiants dans l’en-tête `Authorization` lorsque requis. +- `models.providers.*.baseUrl` : URL de base de l’API amont. - `models.providers.*.headers` : en-têtes statiques supplémentaires pour le routage proxy/locataire. -- `models.providers.*.request` : remplacements de transport pour les requêtes HTTP du fournisseur de modèle. +- `models.providers.*.request` : remplacements de transport pour les requêtes HTTP du fournisseur de modèles. - `request.headers` : en-têtes supplémentaires (fusionnés avec les valeurs par défaut du fournisseur). Les valeurs acceptent SecretRef. - - `request.auth` : remplacement de stratégie d’authentification. Modes : `"provider-default"` (utilise l’authentification intégrée du fournisseur), `"authorization-bearer"` (avec `token`), `"header"` (avec `headerName`, `value`, `prefix` facultatif). - - `request.proxy` : remplacement de proxy HTTP. Modes : `"env-proxy"` (utilise les variables d’environnement `HTTP_PROXY`/`HTTPS_PROXY`), `"explicit-proxy"` (avec `url`). Les deux modes acceptent un sous-objet `tls` facultatif. - - `request.tls` : remplacement TLS pour les connexions directes. Champs : `ca`, `cert`, `key`, `passphrase` (acceptent tous SecretRef), `serverName`, `insecureSkipVerify`. - - `request.allowPrivateNetwork` : lorsqu’il vaut `true`, autorise HTTPS vers `baseUrl` lorsque DNS se résout vers des plages privées, CGNAT ou similaires, via la garde SSRF de récupération HTTP du fournisseur (activation explicite opérateur pour les points de terminaison OpenAI compatibles auto-hébergés de confiance). WebSocket utilise le même `request` pour les en-têtes/TLS, mais pas cette garde SSRF de récupération. Par défaut `false`. + - `request.auth` : remplacement de stratégie d’authentification. Modes : `"provider-default"` (utiliser l’authentification intégrée du fournisseur), `"authorization-bearer"` (avec `token`), `"header"` (avec `headerName`, `value`, `prefix` facultatif). + - `request.proxy` : remplacement de proxy HTTP. Modes : `"env-proxy"` (utiliser les variables d’environnement `HTTP_PROXY`/`HTTPS_PROXY`), `"explicit-proxy"` (avec `url`). Les deux modes acceptent un sous-objet facultatif `tls`. + - `request.tls` : remplacement TLS pour les connexions directes. Champs : `ca`, `cert`, `key`, `passphrase` (tous acceptent SecretRef), `serverName`, `insecureSkipVerify`. + - `request.allowPrivateNetwork` : lorsque `true`, autorise HTTPS vers `baseUrl` lorsque le DNS se résout vers des plages privées, CGNAT ou similaires, via la protection SSRF de récupération HTTP du fournisseur (activation explicite par l’opérateur pour des points de terminaison OpenAI compatibles auto-hébergés de confiance). WebSocket utilise le même `request` pour les en-têtes/TLS mais pas cette protection SSRF de récupération. Par défaut `false`. - `models.providers.*.models` : entrées explicites du catalogue de modèles du fournisseur. -- `models.providers.*.models.*.contextWindow` : métadonnées de fenêtre de contexte native du modèle. -- `models.providers.*.models.*.contextTokens` : plafond de contexte d’exécution facultatif. Utilisez-le lorsque vous voulez un budget de contexte effectif plus petit que `contextWindow` natif du modèle. -- `models.providers.*.models.*.compat.supportsDeveloperRole` : indice de compatibilité facultatif. Pour `api: "openai-completions"` avec un `baseUrl` non vide et non natif (hôte différent de `api.openai.com`), OpenClaw le force à `false` à l’exécution. Un `baseUrl` vide/omis conserve le comportement OpenAI par défaut. -- `models.providers.*.models.*.compat.requiresStringContent` : indice de compatibilité facultatif pour les points de terminaison de chat OpenAI compatibles qui n’acceptent que des chaînes. Lorsqu’il vaut `true`, OpenClaw aplatie les tableaux `messages[].content` purement textuels en chaînes simples avant d’envoyer la requête. +- `models.providers.*.models.*.contextWindow` : métadonnées natives de fenêtre de contexte du modèle. +- `models.providers.*.models.*.contextTokens` : plafond facultatif de contexte à l’exécution. Utilisez-le lorsque vous souhaitez un budget de contexte effectif plus petit que le `contextWindow` natif du modèle. +- `models.providers.*.models.*.compat.supportsDeveloperRole` : indication de compatibilité facultative. Pour `api: "openai-completions"` avec un `baseUrl` non natif non vide (hôte différent de `api.openai.com`), OpenClaw force cette valeur à `false` à l’exécution. Un `baseUrl` vide/omis conserve le comportement OpenAI par défaut. +- `models.providers.*.models.*.compat.requiresStringContent` : indication de compatibilité facultative pour les points de terminaison de discussion OpenAI compatibles n’acceptant que des chaînes. Lorsque `true`, OpenClaw aplatit les tableaux `messages[].content` contenant uniquement du texte en chaînes simples avant l’envoi de la requête. - `plugins.entries.amazon-bedrock.config.discovery` : racine des paramètres d’auto-détection Bedrock. - `plugins.entries.amazon-bedrock.config.discovery.enabled` : active/désactive la détection implicite. - `plugins.entries.amazon-bedrock.config.discovery.region` : région AWS pour la détection. -- `plugins.entries.amazon-bedrock.config.discovery.providerFilter` : filtre facultatif d’ID de fournisseur pour une détection ciblée. -- `plugins.entries.amazon-bedrock.config.discovery.refreshInterval` : intervalle d’interrogation pour le rafraîchissement de la détection. -- `plugins.entries.amazon-bedrock.config.discovery.defaultContextWindow` : fenêtre de contexte de repli pour les modèles détectés. -- `plugins.entries.amazon-bedrock.config.discovery.defaultMaxTokens` : nombre maximal de jetons de sortie de repli pour les modèles détectés. +- `plugins.entries.amazon-bedrock.config.discovery.providerFilter` : filtre facultatif d’identifiant de fournisseur pour une détection ciblée. +- `plugins.entries.amazon-bedrock.config.discovery.refreshInterval` : intervalle d’interrogation pour l’actualisation de la détection. +- `plugins.entries.amazon-bedrock.config.discovery.defaultContextWindow` : fenêtre de contexte de secours pour les modèles détectés. +- `plugins.entries.amazon-bedrock.config.discovery.defaultMaxTokens` : nombre maximal de jetons de sortie de secours pour les modèles détectés. ### Exemples de fournisseurs @@ -2630,7 +2622,7 @@ OpenClaw utilise le catalogue intégré de modèles. Ajoutez des fournisseurs pe } ``` -Utilisez `cerebras/zai-glm-4.7` pour Cerebras ; `zai/glm-4.7` pour Z.AI en direct. +Utilisez `cerebras/zai-glm-4.7` pour Cerebras ; `zai/glm-4.7` pour Z.AI direct. @@ -2668,7 +2660,7 @@ Définissez `ZAI_API_KEY`. `z.ai/*` et `z-ai/*` sont des alias acceptés. Raccou - Point de terminaison général : `https://api.z.ai/api/paas/v4` - Point de terminaison de code (par défaut) : `https://api.z.ai/api/coding/paas/v4` -- Pour le point de terminaison général, définissez un fournisseur personnalisé avec le remplacement de l’URL de base. +- Pour le point de terminaison général, définissez un fournisseur personnalisé avec le remplacement d’URL de base. @@ -2709,9 +2701,9 @@ Définissez `ZAI_API_KEY`. `z.ai/*` et `z-ai/*` sont des alias acceptés. Raccou Pour le point de terminaison Chine : `baseUrl: "https://api.moonshot.cn/v1"` ou `openclaw onboard --auth-choice moonshot-api-key-cn`. -Les points de terminaison Moonshot natifs annoncent la compatibilité d’usage du streaming sur le transport partagé -`openai-completions`, et OpenClaw s’appuie sur les capacités du point de terminaison -plutôt que sur le seul ID de fournisseur intégré. +Les points de terminaison Moonshot natifs annoncent une compatibilité d’usage du streaming sur le transport partagé +`openai-completions`, et OpenClaw se base sur les capacités du point de terminaison +plutôt que sur le seul identifiant de fournisseur intégré. @@ -2821,7 +2813,7 @@ par défaut sauf si vous définissez explicitement `thinking`. `/fast on` ou -Voir [Modèles locaux](/fr/gateway/local-models). En bref : exécutez un grand modèle local via l’API Responses de LM Studio sur du matériel sérieux ; conservez les modèles hébergés fusionnés pour le repli. +Voir [Local Models](/fr/gateway/local-models). En bref : exécutez un grand modèle local via l’API LM Studio Responses sur un matériel sérieux ; conservez des modèles hébergés fusionnés pour le repli. @@ -2852,14 +2844,14 @@ Voir [Modèles locaux](/fr/gateway/local-models). En bref : exécutez un grand } ``` -- `allowBundled` : liste d’autorisation facultative pour les Skills groupés uniquement (les Skills gérés/workspace ne sont pas affectés). -- `load.extraDirs` : racines supplémentaires de Skills partagés (priorité la plus faible). -- `install.preferBrew` : lorsqu’il vaut true, préfère les installateurs Homebrew lorsque `brew` est - disponible avant de revenir à d’autres types d’installateurs. -- `install.nodeManager` : préférence d’installateur Node pour les spécifications `metadata.openclaw.install` +- `allowBundled` : liste d’autorisation facultative pour les Skills groupées uniquement (les Skills gérées/de l’espace de travail ne sont pas affectées). +- `load.extraDirs` : racines partagées supplémentaires pour les Skills (priorité la plus faible). +- `install.preferBrew` : lorsque true, préfère les installateurs Homebrew lorsque `brew` est + disponible avant de se rabattre sur d’autres types d’installateurs. +- `install.nodeManager` : préférence de gestionnaire Node pour les spécifications `metadata.openclaw.install` (`npm` | `pnpm` | `yarn` | `bun`). -- `entries..enabled: false` désactive un Skills même s’il est groupé/installé. -- `entries..apiKey` : champ pratique pour les Skills déclarant une variable d’environnement principale (chaîne en clair ou objet SecretRef). +- `entries..enabled: false` désactive une Skills même si elle est groupée/installée. +- `entries..apiKey` : raccourci pour les Skills déclarant une variable d’environnement principale (chaîne en texte brut ou objet SecretRef). --- @@ -2887,38 +2879,38 @@ Voir [Modèles locaux](/fr/gateway/local-models). En bref : exécutez un grand } ``` -- Chargé depuis `~/.openclaw/extensions`, `/.openclaw/extensions`, ainsi que `plugins.load.paths`. -- La découverte accepte les plugins OpenClaw natifs ainsi que les bundles Codex et Claude compatibles, y compris les bundles Claude sans manifeste avec disposition par défaut. -- **Les modifications de configuration exigent un redémarrage du Gateway.** +- Chargés depuis `~/.openclaw/extensions`, `/.openclaw/extensions`, ainsi que `plugins.load.paths`. +- La découverte accepte les plugins OpenClaw natifs ainsi que les bundles Codex compatibles et les bundles Claude, y compris les bundles Claude sans manifeste avec disposition par défaut. +- **Les changements de configuration nécessitent un redémarrage de la Gateway.** - `allow` : liste d’autorisation facultative (seuls les plugins listés sont chargés). `deny` l’emporte. -- `plugins.entries..apiKey` : champ pratique de clé API au niveau du plugin (lorsqu’il est pris en charge par le plugin). -- `plugins.entries..env` : map de variables d’environnement circonscrite au plugin. -- `plugins.entries..hooks.allowPromptInjection` : lorsqu’il vaut `false`, le cœur bloque `before_prompt_build` et ignore les champs de mutation du prompt provenant de l’ancien `before_agent_start`, tout en conservant les anciens `modelOverride` et `providerOverride`. S’applique aux hooks de plugins natifs et aux répertoires de hooks fournis par bundle pris en charge. -- `plugins.entries..subagent.allowModelOverride` : fait explicitement confiance à ce plugin pour demander des remplacements `provider` et `model` par exécution pour les exécutions de sous-agent en arrière-plan. -- `plugins.entries..subagent.allowedModels` : liste d’autorisation facultative des cibles canoniques `provider/model` pour les remplacements de sous-agent de confiance. Utilisez `"*"` uniquement lorsque vous voulez délibérément autoriser n’importe quel modèle. +- `plugins.entries..apiKey` : champ pratique de clé API au niveau du plugin (lorsque pris en charge par le plugin). +- `plugins.entries..env` : mappe de variables d’environnement limitée au plugin. +- `plugins.entries..hooks.allowPromptInjection` : lorsque `false`, le noyau bloque `before_prompt_build` et ignore les champs hérités modifiant l’invite de `before_agent_start`, tout en préservant les anciens `modelOverride` et `providerOverride`. S’applique aux hooks de plugins natifs et aux répertoires de hooks fournis par bundle pris en charge. +- `plugins.entries..subagent.allowModelOverride` : faire explicitement confiance à ce plugin pour demander des remplacements `provider` et `model` par exécution pour des exécutions de sous-agents en arrière-plan. +- `plugins.entries..subagent.allowedModels` : liste d’autorisation facultative des cibles canoniques `provider/model` pour les remplacements de sous-agents de confiance. Utilisez `"*"` uniquement lorsque vous souhaitez intentionnellement autoriser n’importe quel modèle. - `plugins.entries..config` : objet de configuration défini par le plugin (validé par le schéma du plugin OpenClaw natif lorsqu’il est disponible). - `plugins.entries.firecrawl.config.webFetch` : paramètres du fournisseur de récupération web Firecrawl. - - `apiKey` : clé API Firecrawl (accepte SecretRef). Revient à `plugins.entries.firecrawl.config.webSearch.apiKey`, à l’ancien `tools.web.fetch.firecrawl.apiKey` ou à la variable d’environnement `FIRECRAWL_API_KEY`. + - `apiKey` : clé API Firecrawl (accepte SecretRef). Utilise comme solution de repli `plugins.entries.firecrawl.config.webSearch.apiKey`, l’ancien `tools.web.fetch.firecrawl.apiKey`, ou la variable d’environnement `FIRECRAWL_API_KEY`. - `baseUrl` : URL de base de l’API Firecrawl (par défaut : `https://api.firecrawl.dev`). - - `onlyMainContent` : extrait uniquement le contenu principal des pages (par défaut : `true`). - - `maxAgeMs` : âge maximal du cache en millisecondes (par défaut : `172800000` / 2 jours). + - `onlyMainContent` : extraire uniquement le contenu principal des pages (par défaut : `true`). + - `maxAgeMs` : ancienneté maximale du cache en millisecondes (par défaut : `172800000` / 2 jours). - `timeoutSeconds` : délai d’expiration de la requête de scraping en secondes (par défaut : `60`). - `plugins.entries.xai.config.xSearch` : paramètres xAI X Search (recherche web Grok). - `enabled` : active le fournisseur X Search. - - `model` : modèle Grok à utiliser pour la recherche (par ex. `"grok-4-1-fast"`). -- `plugins.entries.memory-core.config.dreaming` : paramètres de Dreaming de la mémoire. Voir [Dreaming](/fr/concepts/dreaming) pour les phases et les seuils. - - `enabled` : interrupteur maître de Dreaming (par défaut `false`). + - `model` : modèle Grok à utiliser pour la recherche (par exemple `"grok-4-1-fast"`). +- `plugins.entries.memory-core.config.dreaming` : paramètres de dreaming de la mémoire. Voir [Dreaming](/fr/concepts/dreaming) pour les phases et seuils. + - `enabled` : interrupteur principal de Dreaming (par défaut `false`). - `frequency` : cadence Cron pour chaque balayage complet de Dreaming (`"0 3 * * *"` par défaut). - - la politique de phase et les seuils sont des détails d’implémentation (pas des clés de configuration destinées à l’utilisateur). -- La configuration complète de la mémoire se trouve dans [Référence de configuration de la mémoire](/fr/reference/memory-config) : + - la stratégie de phase et les seuils sont des détails d’implémentation (pas des clés de configuration destinées aux utilisateurs). +- La configuration mémoire complète se trouve dans [Référence de configuration de la mémoire](/fr/reference/memory-config) : - `agents.defaults.memorySearch.*` - `memory.backend` - `memory.citations` - `memory.qmd.*` - `plugins.entries.memory-core.config.dreaming` -- Les plugins de bundle Claude activés peuvent également contribuer des valeurs par défaut Pi embarquées depuis `settings.json` ; OpenClaw les applique comme paramètres d’agent nettoyés, pas comme correctifs bruts de configuration OpenClaw. -- `plugins.slots.memory` : choisit l’ID du plugin mémoire actif, ou `"none"` pour désactiver les plugins mémoire. -- `plugins.slots.contextEngine` : choisit l’ID du plugin moteur de contexte actif ; par défaut `"legacy"` sauf si vous installez et sélectionnez un autre moteur. +- Les plugins bundle Claude activés peuvent également contribuer aux valeurs par défaut de Pi intégrées depuis `settings.json` ; OpenClaw les applique comme paramètres d’agent assainis, et non comme correctifs bruts de configuration OpenClaw. +- `plugins.slots.memory` : choisit l’identifiant du plugin mémoire actif, ou `"none"` pour désactiver les plugins mémoire. +- `plugins.slots.contextEngine` : choisit l’identifiant du plugin moteur de contexte actif ; par défaut `"legacy"` sauf si vous installez et sélectionnez un autre moteur. - `plugins.installs` : métadonnées d’installation gérées par la CLI utilisées par `openclaw plugins update`. - Inclut `source`, `spec`, `sourcePath`, `installPath`, `version`, `resolvedName`, `resolvedVersion`, `resolvedSpec`, `integrity`, `shasum`, `resolvedAt`, `installedAt`. - Traitez `plugins.installs.*` comme un état géré ; préférez les commandes CLI aux modifications manuelles. @@ -2927,7 +2919,7 @@ Voir [Plugins](/fr/tools/plugin). --- -## Navigateur +## Browser ```json5 { @@ -2964,24 +2956,25 @@ Voir [Plugins](/fr/tools/plugin). ``` - `evaluateEnabled: false` désactive `act:evaluate` et `wait --fn`. -- `ssrfPolicy.dangerouslyAllowPrivateNetwork` est désactivé lorsqu’il n’est pas défini, donc la navigation du navigateur reste stricte par défaut. -- Définissez `ssrfPolicy.dangerouslyAllowPrivateNetwork: true` uniquement lorsque vous faites délibérément confiance à la navigation du navigateur vers un réseau privé. -- En mode strict, les points de terminaison des profils CDP distants (`profiles.*.cdpUrl`) sont soumis au même blocage des réseaux privés lors des vérifications d’accessibilité/découverte. +- `ssrfPolicy.dangerouslyAllowPrivateNetwork` est désactivé lorsqu’il n’est pas défini, donc la navigation Browser reste stricte par défaut. +- Définissez `ssrfPolicy.dangerouslyAllowPrivateNetwork: true` uniquement lorsque vous faites intentionnellement confiance à la navigation Browser sur réseau privé. +- En mode strict, les points de terminaison de profil CDP distants (`profiles.*.cdpUrl`) sont soumis au même blocage réseau privé pendant les vérifications d’accessibilité/découverte. - `ssrfPolicy.allowPrivateNetwork` reste pris en charge comme alias hérité. - En mode strict, utilisez `ssrfPolicy.hostnameAllowlist` et `ssrfPolicy.allowedHostnames` pour des exceptions explicites. -- Les profils distants sont en attachement seul (démarrage/arrêt/réinitialisation désactivés). +- Les profils distants sont en mode attachement uniquement (démarrage/arrêt/réinitialisation désactivés). - `profiles.*.cdpUrl` accepte `http://`, `https://`, `ws://` et `wss://`. - Utilisez HTTP(S) lorsque vous voulez qu’OpenClaw découvre `/json/version` ; utilisez WS(S) + Utilisez HTTP(S) lorsque vous souhaitez qu’OpenClaw découvre `/json/version` ; utilisez WS(S) lorsque votre fournisseur vous donne une URL WebSocket DevTools directe. -- Les profils `existing-session` sont réservés à l’hôte et utilisent Chrome MCP au lieu de CDP. -- Les profils `existing-session` peuvent définir `userDataDir` pour cibler un profil spécifique - d’un navigateur basé sur Chromium comme Brave ou Edge. -- Les profils `existing-session` conservent les limites actuelles de la route Chrome MCP : - actions pilotées par instantané/référence au lieu d’un ciblage par sélecteur CSS, hooks d’envoi - d’un seul fichier, pas de remplacement du délai d’expiration des boîtes de dialogue, pas de `wait --load networkidle`, et pas de - `responsebody`, export PDF, interception de téléchargement ou actions par lots. -- Les profils locaux gérés `openclaw` assignent automatiquement `cdpPort` et `cdpUrl` ; ne définissez - `cdpUrl` explicitement que pour un CDP distant. +- Les profils `existing-session` utilisent Chrome MCP au lieu de CDP et peuvent s’attacher sur + l’hôte sélectionné ou via un nœud Browser connecté. +- Les profils `existing-session` peuvent définir `userDataDir` pour cibler un profil + spécifique de navigateur basé sur Chromium comme Brave ou Edge. +- Les profils `existing-session` conservent les limites actuelles de routage Chrome MCP : + actions pilotées par snapshot/réf au lieu d’un ciblage par sélecteur CSS, hooks de téléversement + d’un seul fichier, pas de remplacements de délai de dialogue, pas de `wait --load networkidle`, et aucun + `responsebody`, export PDF, interception de téléchargement ni actions par lot. +- Les profils `openclaw` locaux gérés attribuent automatiquement `cdpPort` et `cdpUrl` ; ne + définissez explicitement `cdpUrl` que pour un CDP distant. - Ordre d’auto-détection : navigateur par défaut s’il est basé sur Chromium → Chrome → Brave → Edge → Chromium → Chrome Canary. - Service de contrôle : loopback uniquement (port dérivé de `gateway.port`, par défaut `18791`). - `extraArgs` ajoute des indicateurs de lancement supplémentaires au démarrage local de Chromium (par exemple @@ -3003,8 +2996,8 @@ Voir [Plugins](/fr/tools/plugin). } ``` -- `seamColor` : couleur d’accent pour l’habillage de l’interface native de l’application (teinte de bulle du mode Talk, etc.). -- `assistant` : remplacement d’identité pour l’interface utilisateur Control. Revient à l’identité de l’agent actif. +- `seamColor` : couleur d’accentuation pour le chrome de l’interface native (teinte de la bulle du mode Talk, etc.). +- `assistant` : remplacement d’identité de l’interface Control UI. Utilise l’identité de l’agent actif comme solution de repli. --- @@ -3071,47 +3064,47 @@ Voir [Plugins](/fr/tools/plugin). } ``` - + -- `mode` : `local` (exécuter le Gateway) ou `remote` (se connecter à un Gateway distant). Le Gateway refuse de démarrer sauf en mode `local`. +- `mode` : `local` (exécuter la Gateway) ou `remote` (se connecter à une Gateway distante). La Gateway refuse de démarrer sauf si `local`. - `port` : port multiplexé unique pour WS + HTTP. Priorité : `--port` > `OPENCLAW_GATEWAY_PORT` > `gateway.port` > `18789`. - `bind` : `auto`, `loopback` (par défaut), `lan` (`0.0.0.0`), `tailnet` (IP Tailscale uniquement) ou `custom`. -- **Alias `bind` hérités** : utilisez les valeurs de mode bind dans `gateway.bind` (`auto`, `loopback`, `lan`, `tailnet`, `custom`), pas les alias d’hôte (`0.0.0.0`, `127.0.0.1`, `localhost`, `::`, `::1`). -- **Remarque Docker** : la liaison `loopback` par défaut écoute sur `127.0.0.1` à l’intérieur du conteneur. Avec le réseau bridge Docker (`-p 18789:18789`), le trafic arrive sur `eth0`, donc le Gateway est inaccessible. Utilisez `--network host`, ou définissez `bind: "lan"` (ou `bind: "custom"` avec `customBindHost: "0.0.0.0"`) pour écouter sur toutes les interfaces. -- **Auth** : requise par défaut. Les liaisons non loopback exigent l’authentification Gateway. En pratique, cela signifie un jeton/mot de passe partagé ou un proxy inverse à gestion d’identité avec `gateway.auth.mode: "trusted-proxy"`. L’assistant d’intégration génère un jeton par défaut. -- Si `gateway.auth.token` et `gateway.auth.password` sont tous deux configurés (y compris via SecretRef), définissez explicitement `gateway.auth.mode` sur `token` ou `password`. Le démarrage et les flux d’installation/réparation du service échouent lorsque les deux sont configurés et que le mode n’est pas défini. -- `gateway.auth.mode: "none"` : mode explicite sans authentification. À utiliser uniquement pour des configurations loopback locales de confiance ; ce mode n’est volontairement pas proposé dans les invites d’intégration. -- `gateway.auth.mode: "trusted-proxy"` : délègue l’authentification à un proxy inverse à gestion d’identité et fait confiance aux en-têtes d’identité provenant de `gateway.trustedProxies` (voir [Authentification par proxy de confiance](/fr/gateway/trusted-proxy-auth)). Ce mode attend une source de proxy **non loopback** ; les proxys inverses loopback sur la même machine ne satisfont pas l’authentification trusted-proxy. -- `gateway.auth.allowTailscale` : lorsqu’il vaut `true`, les en-têtes d’identité Tailscale Serve peuvent satisfaire l’authentification de l’interface utilisateur Control/WebSocket (vérifiés via `tailscale whois`). Les points de terminaison API HTTP n’utilisent **pas** cette authentification par en-tête Tailscale ; ils suivent à la place le mode d’authentification HTTP normal du Gateway. Ce flux sans jeton suppose que l’hôte Gateway est de confiance. Par défaut `true` lorsque `tailscale.mode = "serve"`. -- `gateway.auth.rateLimit` : limiteur facultatif des échecs d’authentification. S’applique par IP cliente et par portée d’authentification (secret partagé et jeton d’appareil sont suivis séparément). Les tentatives bloquées renvoient `429` + `Retry-After`. - - Sur le chemin asynchrone Tailscale Serve de l’interface utilisateur Control, les tentatives échouées pour un même `{scope, clientIp}` sont sérialisées avant l’écriture de l’échec. Des tentatives mauvaises concurrentes du même client peuvent donc déclencher le limiteur à la deuxième requête au lieu de laisser passer les deux comme de simples non-correspondances. - - `gateway.auth.rateLimit.exemptLoopback` vaut par défaut `true` ; définissez `false` lorsque vous voulez délibérément limiter aussi le trafic localhost (pour des configurations de test ou des déploiements de proxy stricts). -- Les tentatives d’authentification WS d’origine navigateur sont toujours limitées avec exemption loopback désactivée (défense en profondeur contre la force brute localhost depuis le navigateur). -- En loopback, ces verrouillages provenant d’origines navigateur sont isolés par valeur `Origin` +- **Alias hérités de bind** : utilisez les valeurs de mode bind dans `gateway.bind` (`auto`, `loopback`, `lan`, `tailnet`, `custom`), et non les alias d’hôte (`0.0.0.0`, `127.0.0.1`, `localhost`, `::`, `::1`). +- **Remarque Docker** : la liaison `loopback` par défaut écoute sur `127.0.0.1` à l’intérieur du conteneur. Avec la mise en réseau bridge Docker (`-p 18789:18789`), le trafic arrive sur `eth0`, donc la Gateway est inaccessible. Utilisez `--network host`, ou définissez `bind: "lan"` (ou `bind: "custom"` avec `customBindHost: "0.0.0.0"`) pour écouter sur toutes les interfaces. +- **Auth** : requise par défaut. Les liaisons non loopback exigent l’authentification Gateway. En pratique, cela signifie un jeton/mot de passe partagé ou un proxy inverse sensible à l’identité avec `gateway.auth.mode: "trusted-proxy"`. L’assistant d’intégration génère un jeton par défaut. +- Si `gateway.auth.token` et `gateway.auth.password` sont tous deux configurés (y compris via SecretRef), définissez explicitement `gateway.auth.mode` sur `token` ou `password`. Les flux de démarrage et d’installation/réparation du service échouent lorsque les deux sont configurés et que le mode n’est pas défini. +- `gateway.auth.mode: "none"` : mode sans authentification explicite. À utiliser uniquement pour des configurations loopback locales de confiance ; ce mode n’est volontairement pas proposé par les invites d’intégration. +- `gateway.auth.mode: "trusted-proxy"` : délègue l’authentification à un proxy inverse sensible à l’identité et fait confiance aux en-têtes d’identité provenant de `gateway.trustedProxies` (voir [Authentification par proxy de confiance](/fr/gateway/trusted-proxy-auth)). Ce mode attend une source proxy **non loopback** ; les proxies inverses loopback sur le même hôte ne satisfont pas l’authentification trusted-proxy. +- `gateway.auth.allowTailscale` : lorsque `true`, les en-têtes d’identité Tailscale Serve peuvent satisfaire l’authentification de Control UI/WebSocket (vérifiée via `tailscale whois`). Les points de terminaison HTTP API n’utilisent **pas** cette authentification par en-tête Tailscale ; ils suivent à la place le mode d’authentification HTTP normal de la Gateway. Ce flux sans jeton suppose que l’hôte Gateway est de confiance. Par défaut `true` lorsque `tailscale.mode = "serve"`. +- `gateway.auth.rateLimit` : limiteur facultatif d’échecs d’authentification. S’applique par IP client et par portée d’authentification (secret partagé et jeton d’appareil sont suivis indépendamment). Les tentatives bloquées renvoient `429` + `Retry-After`. + - Sur le chemin asynchrone Tailscale Serve de Control UI, les tentatives échouées pour le même `{scope, clientIp}` sont sérialisées avant l’écriture de l’échec. Des tentatives invalides concurrentes provenant du même client peuvent donc déclencher le limiteur à la deuxième requête au lieu de laisser les deux passer en parallèle comme de simples incompatibilités. + - `gateway.auth.rateLimit.exemptLoopback` vaut `true` par défaut ; définissez `false` lorsque vous souhaitez intentionnellement limiter aussi le trafic localhost (pour des configurations de test ou des déploiements proxy stricts). +- Les tentatives d’authentification WS d’origine navigateur sont toujours limitées avec exemption loopback désactivée (défense en profondeur contre la force brute localhost basée sur navigateur). +- En loopback, ces verrouillages d’origine navigateur sont isolés par valeur `Origin` normalisée, de sorte que des échecs répétés depuis une origine localhost n’entraînent pas automatiquement le verrouillage d’une autre origine. -- `tailscale.mode` : `serve` (tailnet uniquement, liaison loopback) ou `funnel` (public, nécessite une authentification). -- `controlUi.allowedOrigins` : liste d’autorisation explicite des origines navigateur pour les connexions WebSocket au Gateway. Requise lorsque des clients navigateur sont attendus depuis des origines non loopback. -- `controlUi.dangerouslyAllowHostHeaderOriginFallback` : mode dangereux qui active le repli d’origine basé sur l’en-tête Host pour les déploiements qui reposent volontairement sur une politique d’origine fondée sur Host. +- `tailscale.mode` : `serve` (tailnet uniquement, liaison loopback) ou `funnel` (public, nécessite auth). +- `controlUi.allowedOrigins` : liste d’autorisation explicite des origines navigateur pour les connexions WebSocket Gateway. Requise lorsque des clients navigateur sont attendus depuis des origines non loopback. +- `controlUi.dangerouslyAllowHostHeaderOriginFallback` : mode dangereux qui active le repli d’origine basé sur l’en-tête Host pour les déploiements qui reposent intentionnellement sur cette stratégie d’origine. - `remote.transport` : `ssh` (par défaut) ou `direct` (ws/wss). Pour `direct`, `remote.url` doit être `ws://` ou `wss://`. -- `OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1` : remplacement client « break-glass » qui autorise `ws://` en clair vers des IP réseau privé de confiance ; par défaut, le texte en clair reste limité au loopback. -- `gateway.remote.token` / `.password` sont des champs d’identifiants du client distant. Ils ne configurent pas à eux seuls l’authentification du Gateway. -- `gateway.push.apns.relay.baseUrl` : URL HTTPS de base du relais APNs externe utilisé par les builds iOS officiels/TestFlight après qu’ils ont publié des enregistrements adossés au relais vers le Gateway. Cette URL doit correspondre à l’URL du relais compilée dans le build iOS. -- `gateway.push.apns.relay.timeoutMs` : délai d’envoi Gateway-vers-relais en millisecondes. Par défaut `10000`. -- Les enregistrements adossés au relais sont délégués à une identité spécifique du Gateway. L’app iOS appairée récupère `gateway.identity.get`, inclut cette identité dans l’enregistrement du relais et transmet au Gateway une autorisation d’envoi circonscrite à l’enregistrement. Un autre Gateway ne peut pas réutiliser cet enregistrement stocké. -- `OPENCLAW_APNS_RELAY_BASE_URL` / `OPENCLAW_APNS_RELAY_TIMEOUT_MS` : remplacements d’environnement temporaires pour la configuration de relais ci-dessus. -- `OPENCLAW_APNS_RELAY_ALLOW_HTTP=true` : échappatoire réservée au développement pour les URL de relais HTTP loopback. Les URL de relais de production doivent rester en HTTPS. -- `gateway.channelHealthCheckMinutes` : intervalle du moniteur d’état des canaux en minutes. Définissez `0` pour désactiver globalement les redémarrages du moniteur d’état. Par défaut : `5`. -- `gateway.channelStaleEventThresholdMinutes` : seuil de socket obsolète en minutes. Conservez une valeur supérieure ou égale à `gateway.channelHealthCheckMinutes`. Par défaut : `30`. -- `gateway.channelMaxRestartsPerHour` : nombre maximal de redémarrages du moniteur d’état par canal/compte sur une heure glissante. Par défaut : `10`. -- `channels..healthMonitor.enabled` : désactivation par canal des redémarrages du moniteur d’état tout en conservant le moniteur global activé. +- `OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1` : remplacement de dernier recours côté client qui autorise `ws://` en clair vers des IP de réseau privé de confiance ; par défaut, le clair reste limité à loopback. +- `gateway.remote.token` / `.password` sont des champs d’identifiants du client distant. Ils ne configurent pas à eux seuls l’authentification Gateway. +- `gateway.push.apns.relay.baseUrl` : URL HTTPS de base pour le relais APNs externe utilisé par les builds iOS officiels/TestFlight après publication des inscriptions adossées au relais vers la Gateway. Cette URL doit correspondre à l’URL du relais compilée dans le build iOS. +- `gateway.push.apns.relay.timeoutMs` : délai d’expiration en millisecondes pour les envois de la Gateway vers le relais. Par défaut : `10000`. +- Les inscriptions adossées au relais sont déléguées à une identité Gateway spécifique. L’app iOS appairée récupère `gateway.identity.get`, inclut cette identité dans l’inscription du relais et transmet à la Gateway une autorisation d’envoi limitée à cette inscription. Une autre Gateway ne peut pas réutiliser cette inscription stockée. +- `OPENCLAW_APNS_RELAY_BASE_URL` / `OPENCLAW_APNS_RELAY_TIMEOUT_MS` : remplacements temporaires par variable d’environnement pour la configuration de relais ci-dessus. +- `OPENCLAW_APNS_RELAY_ALLOW_HTTP=true` : échappatoire réservée au développement pour les URLs de relais HTTP loopback. Les URLs de relais de production doivent rester en HTTPS. +- `gateway.channelHealthCheckMinutes` : intervalle du moniteur de santé des canaux en minutes. Définissez `0` pour désactiver globalement les redémarrages du moniteur de santé. Par défaut : `5`. +- `gateway.channelStaleEventThresholdMinutes` : seuil de socket obsolète en minutes. Gardez-le supérieur ou égal à `gateway.channelHealthCheckMinutes`. Par défaut : `30`. +- `gateway.channelMaxRestartsPerHour` : nombre maximal de redémarrages du moniteur de santé par canal/compte sur une heure glissante. Par défaut : `10`. +- `channels..healthMonitor.enabled` : désactivation facultative par canal des redémarrages du moniteur de santé tout en conservant le moniteur global activé. - `channels..accounts..healthMonitor.enabled` : remplacement par compte pour les canaux multi-comptes. Lorsqu’il est défini, il a priorité sur le remplacement au niveau du canal. -- Les chemins d’appel du Gateway local peuvent utiliser `gateway.remote.*` comme repli uniquement lorsque `gateway.auth.*` n’est pas défini. -- Si `gateway.auth.token` / `gateway.auth.password` est explicitement configuré via SecretRef et non résolu, la résolution échoue en mode fermé (aucun repli distant ne masque cela). -- `trustedProxies` : IP de proxy inverse qui terminent TLS ou injectent des en-têtes client transférés. Listez uniquement les proxys que vous contrôlez. Les entrées loopback restent valides pour les configurations de proxy sur le même hôte / détection locale (par exemple Tailscale Serve ou un proxy inverse local), mais elles ne rendent **pas** les requêtes loopback admissibles à `gateway.auth.mode: "trusted-proxy"`. -- `allowRealIpFallback` : lorsqu’il vaut `true`, le Gateway accepte `X-Real-IP` si `X-Forwarded-For` est absent. Par défaut `false` pour un comportement en mode fermé. -- `gateway.tools.deny` : noms d’outils supplémentaires bloqués pour `POST /tools/invoke` HTTP (étend la liste de refus par défaut). -- `gateway.tools.allow` : supprime des noms d’outils de la liste de refus HTTP par défaut. +- Les chemins d’appel de Gateway locale peuvent utiliser `gateway.remote.*` comme solution de repli uniquement lorsque `gateway.auth.*` n’est pas défini. +- Si `gateway.auth.token` / `gateway.auth.password` est explicitement configuré via SecretRef et non résolu, la résolution échoue en mode fermé (pas de repli distant masquant). +- `trustedProxies` : IP de proxy inverse qui terminent TLS ou injectent des en-têtes de client transféré. Ne listez que les proxies que vous contrôlez. Les entrées loopback restent valides pour les configurations de détection locale/proxy sur le même hôte (par exemple Tailscale Serve ou un proxy inverse local), mais elles ne rendent **pas** les requêtes loopback éligibles à `gateway.auth.mode: "trusted-proxy"`. +- `allowRealIpFallback` : lorsque `true`, la Gateway accepte `X-Real-IP` si `X-Forwarded-For` est absent. Par défaut `false` pour un comportement d’échec fermé. +- `gateway.tools.deny` : noms d’outils supplémentaires bloqués pour HTTP `POST /tools/invoke` (étend la liste de refus par défaut). +- `gateway.tools.allow` : retire des noms d’outils de la liste de refus HTTP par défaut. @@ -3125,12 +3118,12 @@ Voir [Plugins](/fr/tools/plugin). - `gateway.http.endpoints.responses.images.urlAllowlist` Les listes d’autorisation vides sont traitées comme non définies ; utilisez `gateway.http.endpoints.responses.files.allowUrl=false` et/ou `gateway.http.endpoints.responses.images.allowUrl=false` pour désactiver la récupération d’URL. -- En-tête facultatif de durcissement des réponses : - - `gateway.http.securityHeaders.strictTransportSecurity` (à définir uniquement pour des origines HTTPS que vous contrôlez ; voir [Authentification par proxy de confiance](/fr/gateway/trusted-proxy-auth#tls-termination-and-hsts)) +- En-tête facultatif de renforcement des réponses : + - `gateway.http.securityHeaders.strictTransportSecurity` (à définir uniquement pour les origines HTTPS que vous contrôlez ; voir [Authentification par proxy de confiance](/fr/gateway/trusted-proxy-auth#tls-termination-and-hsts)) ### Isolation multi-instance -Exécutez plusieurs Gateway sur un même hôte avec des ports et répertoires d’état uniques : +Exécutez plusieurs Gateways sur un même hôte avec des ports et répertoires d’état uniques : ```bash OPENCLAW_CONFIG_PATH=~/.openclaw/a.json \ @@ -3138,9 +3131,9 @@ OPENCLAW_STATE_DIR=~/.openclaw-a \ openclaw gateway --port 19001 ``` -Indicateurs pratiques : `--dev` (utilise `~/.openclaw-dev` + port `19001`), `--profile ` (utilise `~/.openclaw-`). +Indicateurs pratiques : `--dev` (utilise `~/.openclaw-dev` + le port `19001`), `--profile ` (utilise `~/.openclaw-`). -Voir [Plusieurs Gateway](/fr/gateway/multiple-gateways). +Voir [Passerelles multiples](/fr/gateway/multiple-gateways). ### `gateway.tls` @@ -3159,9 +3152,9 @@ Voir [Plusieurs Gateway](/fr/gateway/multiple-gateways). ``` - `enabled` : active la terminaison TLS au niveau de l’écouteur Gateway (HTTPS/WSS) (par défaut : `false`). -- `autoGenerate` : génère automatiquement une paire locale cert/key autosignée lorsqu’aucun fichier explicite n’est configuré ; pour usage local/dev uniquement. -- `certPath` : chemin du système de fichiers vers le fichier de certificat TLS. -- `keyPath` : chemin du système de fichiers vers la clé privée TLS ; gardez des permissions restrictives. +- `autoGenerate` : génère automatiquement une paire locale certificat/clé auto-signée lorsque des fichiers explicites ne sont pas configurés ; à utiliser uniquement en local/dev. +- `certPath` : chemin système vers le fichier de certificat TLS. +- `keyPath` : chemin système vers le fichier de clé privée TLS ; gardez des permissions restreintes. - `caPath` : chemin facultatif vers un bundle CA pour la vérification client ou des chaînes de confiance personnalisées. ### `gateway.reload` @@ -3181,9 +3174,9 @@ Voir [Plusieurs Gateway](/fr/gateway/multiple-gateways). - `mode` : contrôle la manière dont les modifications de configuration sont appliquées à l’exécution. - `"off"` : ignore les modifications en direct ; les changements nécessitent un redémarrage explicite. - `"restart"` : redémarre toujours le processus Gateway lors d’un changement de configuration. - - `"hot"` : applique les changements dans le processus sans redémarrage. - - `"hybrid"` (par défaut) : tente d’abord un rechargement à chaud ; revient à un redémarrage si nécessaire. -- `debounceMs` : fenêtre d’antirebond en ms avant l’application des changements de configuration (entier non négatif). + - `"hot"` : applique les changements en cours de processus sans redémarrer. + - `"hybrid"` (par défaut) : essaie d’abord le rechargement à chaud ; revient au redémarrage si nécessaire. +- `debounceMs` : fenêtre de debounce en ms avant l’application des changements de configuration (entier non négatif). - `deferralTimeoutMs` : durée maximale en ms d’attente des opérations en cours avant de forcer un redémarrage (par défaut : `300000` = 5 minutes). --- @@ -3226,32 +3219,32 @@ Les jetons de hook dans la chaîne de requête sont rejetés. Remarques de validation et de sécurité : -- `hooks.enabled=true` exige un `hooks.token` non vide. -- `hooks.token` doit être **distinct** de `gateway.auth.token` ; réutiliser le jeton Gateway est rejeté. -- `hooks.path` ne peut pas être `/` ; utilisez un sous-chemin dédié comme `/hooks`. -- Si `hooks.allowRequestSessionKey=true`, contraignez `hooks.allowedSessionKeyPrefixes` (par exemple `["hook:"]`). +- `hooks.enabled=true` nécessite un `hooks.token` non vide. +- `hooks.token` doit être **distinct** de `gateway.auth.token` ; la réutilisation du jeton Gateway est rejetée. +- `hooks.path` ne peut pas être `/` ; utilisez un sous-chemin dédié tel que `/hooks`. +- Si `hooks.allowRequestSessionKey=true`, limitez `hooks.allowedSessionKeyPrefixes` (par exemple `["hook:"]`). **Points de terminaison :** - `POST /hooks/wake` → `{ text, mode?: "now"|"next-heartbeat" }` - `POST /hooks/agent` → `{ message, name?, agentId?, sessionKey?, wakeMode?, deliver?, channel?, to?, model?, thinking?, timeoutSeconds? }` - - `sessionKey` provenant de la charge utile de requête n’est accepté que lorsque `hooks.allowRequestSessionKey=true` (par défaut : `false`). + - `sessionKey` issu de la charge utile de requête n’est accepté que lorsque `hooks.allowRequestSessionKey=true` (par défaut : `false`). - `POST /hooks/` → résolu via `hooks.mappings` - `match.path` correspond au sous-chemin après `/hooks` (par ex. `/hooks/gmail` → `gmail`). -- `match.source` correspond à un champ de la charge utile pour les chemins génériques. +- `match.source` correspond à un champ de charge utile pour les chemins génériques. - Les modèles comme `{{messages[0].subject}}` lisent depuis la charge utile. - `transform` peut pointer vers un module JS/TS renvoyant une action de hook. - `transform.module` doit être un chemin relatif et rester dans `hooks.transformsDir` (les chemins absolus et la traversée sont rejetés). -- `agentId` achemine vers un agent spécifique ; les ID inconnus reviennent à l’agent par défaut. +- `agentId` route vers un agent spécifique ; les identifiants inconnus se rabattent sur la valeur par défaut. - `allowedAgentIds` : restreint le routage explicite (`*` ou omis = tout autoriser, `[]` = tout refuser). - `defaultSessionKey` : clé de session fixe facultative pour les exécutions d’agent hook sans `sessionKey` explicite. - `allowRequestSessionKey` : autorise les appelants de `/hooks/agent` à définir `sessionKey` (par défaut : `false`). - `allowedSessionKeyPrefixes` : liste d’autorisation facultative de préfixes pour les valeurs explicites de `sessionKey` (requête + mapping), par ex. `["hook:"]`. -- `deliver: true` envoie la réponse finale vers un canal ; `channel` vaut `last` par défaut. -- `model` remplace le LLM pour cette exécution de hook (doit être autorisé si le catalogue de modèles est défini). +- `deliver: true` envoie la réponse finale à un canal ; `channel` vaut par défaut `last`. +- `model` remplace le LLM pour cette exécution de hook (doit être autorisé si un catalogue de modèles est défini). @@ -3278,8 +3271,8 @@ Remarques de validation et de sécurité : } ``` -- Le Gateway démarre automatiquement `gog gmail watch serve` au démarrage lorsqu’il est configuré. Définissez `OPENCLAW_SKIP_GMAIL_WATCHER=1` pour le désactiver. -- N’exécutez pas un `gog gmail watch serve` séparé en parallèle du Gateway. +- La Gateway démarre automatiquement `gog gmail watch serve` au démarrage lorsqu’il est configuré. Définissez `OPENCLAW_SKIP_GMAIL_WATCHER=1` pour le désactiver. +- N’exécutez pas un `gog gmail watch serve` séparé en parallèle de la Gateway. --- @@ -3295,18 +3288,18 @@ Remarques de validation et de sécurité : } ``` -- Sert du HTML/CSS/JS modifiable par l’agent et A2UI sur HTTP sous le port du Gateway : +- Sert du HTML/CSS/JS modifiable par agent et A2UI en HTTP sous le port Gateway : - `http://:/__openclaw__/canvas/` - `http://:/__openclaw__/a2ui/` - Local uniquement : conservez `gateway.bind: "loopback"` (par défaut). -- Liaisons non loopback : les routes canvas exigent l’authentification Gateway (token/password/trusted-proxy), comme les autres surfaces HTTP du Gateway. -- Les WebViews Node n’envoient généralement pas d’en-têtes d’authentification ; après appairage et connexion d’un Node, le Gateway annonce des URL de capacité circonscrites au Node pour l’accès à canvas/A2UI. -- Les URL de capacité sont liées à la session WS active du Node et expirent rapidement. Le repli basé sur l’IP n’est pas utilisé. -- Injecte un client de rechargement en direct dans le HTML servi. +- Liaisons non loopback : les routes canvas exigent l’authentification Gateway (token/password/trusted-proxy), comme les autres surfaces HTTP Gateway. +- Les Node WebViews n’envoient généralement pas d’en-têtes d’authentification ; après appairage et connexion d’un nœud, la Gateway annonce des URLs de capacité limitées au nœud pour l’accès à canvas/A2UI. +- Les URLs de capacité sont liées à la session WS active du nœud et expirent rapidement. Aucun repli basé sur IP n’est utilisé. +- Injecte un client de rechargement à chaud dans le HTML servi. - Crée automatiquement un `index.html` de départ lorsqu’il est vide. -- Sert aussi A2UI à `/__openclaw__/a2ui/`. -- Les changements exigent un redémarrage du Gateway. -- Désactivez le rechargement en direct pour les grands répertoires ou en cas d’erreurs `EMFILE`. +- Sert également A2UI à `/__openclaw__/a2ui/`. +- Les changements nécessitent un redémarrage de la Gateway. +- Désactivez le rechargement à chaud pour les grands répertoires ou en cas d’erreurs `EMFILE`. --- @@ -3328,7 +3321,7 @@ Remarques de validation et de sécurité : - `full` : inclut `cliPath` + `sshPort`. - Le nom d’hôte vaut par défaut `openclaw`. Remplacez-le avec `OPENCLAW_MDNS_HOSTNAME`. -### Zone étendue (DNS-SD) +### Étendue large (DNS-SD) ```json5 { @@ -3338,7 +3331,7 @@ Remarques de validation et de sécurité : } ``` -Écrit une zone DNS-SD unicast sous `~/.openclaw/dns/`. Pour une découverte inter-réseaux, associez-la à un serveur DNS (CoreDNS recommandé) + DNS scindé Tailscale. +Écrit une zone DNS-SD unicast sous `~/.openclaw/dns/`. Pour la découverte inter-réseaux, combinez avec un serveur DNS (CoreDNS recommandé) + DNS fractionné Tailscale. Configuration : `openclaw dns setup --apply`. @@ -3346,7 +3339,7 @@ Configuration : `openclaw dns setup --apply`. ## Environnement -### `env` (variables d’environnement intégrées) +### `env` (variables d’environnement en ligne) ```json5 { @@ -3363,9 +3356,9 @@ Configuration : `openclaw dns setup --apply`. } ``` -- Les variables d’environnement intégrées ne sont appliquées que si l’environnement du processus ne contient pas déjà la clé. +- Les variables d’environnement en ligne ne sont appliquées que si l’environnement du processus ne contient pas déjà la clé. - Fichiers `.env` : `.env` du répertoire courant + `~/.openclaw/.env` (aucun des deux ne remplace les variables existantes). -- `shellEnv` : importe les clés attendues manquantes depuis votre profil de shell de connexion. +- `shellEnv` : importe les clés attendues manquantes depuis le profil de votre shell de connexion. - Voir [Environnement](/fr/help/environment) pour l’ordre de priorité complet. ### Substitution de variables d’environnement @@ -3382,18 +3375,18 @@ Référencez des variables d’environnement dans n’importe quelle chaîne de - Seuls les noms en majuscules sont reconnus : `[A-Z_][A-Z0-9_]*`. - Les variables manquantes/vides provoquent une erreur au chargement de la configuration. -- Échappez avec `$${VAR}` pour obtenir un littéral `${VAR}`. +- Échappez avec `$${VAR}` pour un `${VAR}` littéral. - Fonctionne avec `$include`. --- ## Secrets -Les références de secret sont additives : les valeurs en clair continuent de fonctionner. +Les références de secrets sont additives : les valeurs en texte brut continuent de fonctionner. ### `SecretRef` -Utilisez une seule forme d’objet : +Utilisez une forme d’objet unique : ```json5 { source: "env" | "file" | "exec", provider: "default", id: "..." } @@ -3402,16 +3395,16 @@ Utilisez une seule forme d’objet : Validation : - motif `provider` : `^[a-z][a-z0-9_-]{0,63}$` -- motif `source: "env"` pour `id` : `^[A-Z][A-Z0-9_]{0,127}$` -- `source: "file"` pour `id` : pointeur JSON absolu (par exemple `"/providers/openai/apiKey"`) -- motif `source: "exec"` pour `id` : `^[A-Za-z0-9][A-Za-z0-9._:/-]{0,255}$` -- les `id` de `source: "exec"` ne doivent pas contenir de segments de chemin `/./` ou `/../` séparés par des slashs (par exemple `a/../b` est rejeté) +- motif `source: "env"` id : `^[A-Z][A-Z0-9_]{0,127}$` +- `source: "file"` id : pointeur JSON absolu (par exemple `"/providers/openai/apiKey"`) +- motif `source: "exec"` id : `^[A-Za-z0-9][A-Za-z0-9._:/-]{0,255}$` +- Les identifiants `source: "exec"` ne doivent pas contenir de segments de chemin délimités par `/` égaux à `.` ou `..` (par exemple `a/../b` est rejeté) ### Surface d’identifiants prise en charge - Matrice canonique : [Surface d’identifiants SecretRef](/fr/reference/secretref-credential-surface) - `secrets apply` cible les chemins d’identifiants pris en charge dans `openclaw.json`. -- Les références de `auth-profiles.json` sont incluses dans la résolution à l’exécution et dans la couverture d’audit. +- Les références `auth-profiles.json` sont incluses dans la résolution à l’exécution et dans la couverture d’audit. ### Configuration des fournisseurs de secrets @@ -3444,16 +3437,16 @@ Validation : Remarques : - Le fournisseur `file` prend en charge `mode: "json"` et `mode: "singleValue"` (`id` doit être `"value"` en mode singleValue). -- Le fournisseur `exec` exige un chemin `command` absolu et utilise des charges utiles de protocole sur stdin/stdout. -- Par défaut, les chemins de commande symboliques sont rejetés. Définissez `allowSymlinkCommand: true` pour autoriser les chemins symboliques tout en validant le chemin cible résolu. +- Le fournisseur `exec` nécessite un chemin `command` absolu et utilise des charges utiles de protocole sur stdin/stdout. +- Par défaut, les chemins de commande symlink sont rejetés. Définissez `allowSymlinkCommand: true` pour autoriser les chemins symlink tout en validant le chemin cible résolu. - Si `trustedDirs` est configuré, la vérification des répertoires de confiance s’applique au chemin cible résolu. -- L’environnement enfant de `exec` est minimal par défaut ; transmettez explicitement les variables requises avec `passEnv`. -- Les références de secret sont résolues au moment de l’activation dans un instantané en mémoire, puis les chemins de requête ne lisent que cet instantané. -- Le filtrage des surfaces actives s’applique pendant l’activation : les références non résolues sur des surfaces activées font échouer le démarrage/rechargement, tandis que les surfaces inactives sont ignorées avec diagnostics. +- L’environnement enfant `exec` est minimal par défaut ; transmettez explicitement les variables nécessaires avec `passEnv`. +- Les références de secrets sont résolues au moment de l’activation dans un instantané en mémoire, puis les chemins de requête lisent uniquement cet instantané. +- Le filtrage de surface active s’applique pendant l’activation : les références non résolues sur des surfaces activées font échouer le démarrage/rechargement, tandis que les surfaces inactives sont ignorées avec diagnostics. --- -## Stockage d’authentification +## Stockage de l’authentification ```json5 { @@ -3472,10 +3465,10 @@ Remarques : ``` - Les profils par agent sont stockés dans `/auth-profiles.json`. -- `auth-profiles.json` prend en charge les références au niveau valeur (`keyRef` pour `api_key`, `tokenRef` pour `token`) pour les modes d’identifiants statiques. +- `auth-profiles.json` prend en charge les références au niveau des valeurs (`keyRef` pour `api_key`, `tokenRef` pour `token`) pour les modes d’identifiants statiques. - Les profils en mode OAuth (`auth.profiles..mode = "oauth"`) ne prennent pas en charge les identifiants de profil d’authentification adossés à SecretRef. - Les identifiants statiques d’exécution proviennent d’instantanés résolus en mémoire ; les anciennes entrées statiques `auth.json` sont nettoyées lorsqu’elles sont découvertes. -- Les anciennes importations OAuth proviennent de `~/.openclaw/credentials/oauth.json`. +- Importations OAuth héritées depuis `~/.openclaw/credentials/oauth.json`. - Voir [OAuth](/fr/concepts/oauth). - Comportement d’exécution des secrets et outils `audit/configure/apply` : [Gestion des secrets](/fr/gateway/secrets). @@ -3499,21 +3492,20 @@ Remarques : } ``` -- `billingBackoffHours` : repli de base en heures lorsqu’un profil échoue à cause de vraies - erreurs de facturation / crédit insuffisant (par défaut : `5`). Un texte de facturation explicite peut - toujours aboutir ici même sur des réponses `401`/`403`, mais les correspondances de texte - spécifiques au fournisseur restent circonscrites au fournisseur qui les possède (par exemple OpenRouter - `Key limit exceeded`). Les messages `402` de fenêtre d’usage - réessayables ou de limite de dépenses d’organisation/espace de travail restent dans le chemin `rate_limit` - à la place. -- `billingBackoffHoursByProvider` : remplacements facultatifs par fournisseur pour les heures de repli de facturation. -- `billingMaxHours` : plafond en heures pour la croissance exponentielle du repli de facturation (par défaut : `24`). -- `authPermanentBackoffMinutes` : repli de base en minutes pour les échecs `auth_permanent` à forte confiance (par défaut : `10`). -- `authPermanentMaxMinutes` : plafond en minutes pour la croissance du repli `auth_permanent` (par défaut : `60`). -- `failureWindowHours` : fenêtre glissante en heures utilisée pour les compteurs de repli (par défaut : `24`). -- `overloadedProfileRotations` : nombre maximal de rotations de profil d’authentification pour un même fournisseur en cas de surcharge avant de basculer vers le modèle de repli (par défaut : `1`). Les formes de fournisseur occupé comme `ModelNotReadyException` aboutissent ici. -- `overloadedBackoffMs` : délai fixe avant de réessayer une rotation de fournisseur/profil surchargé (par défaut : `0`). -- `rateLimitedProfileRotations` : nombre maximal de rotations de profil d’authentification pour un même fournisseur en cas de limitation de débit avant de basculer vers le modèle de repli (par défaut : `1`). Ce compartiment de limitation de débit inclut du texte typé fournisseur tel que `Too many concurrent requests`, `ThrottlingException`, `concurrency limit reached`, `workers_ai ... quota limit exceeded` et `resource exhausted`. +- `billingBackoffHours` : délai de repli de base en heures lorsqu’un profil échoue à cause de véritables erreurs + de facturation/crédit insuffisant (par défaut : `5`). Un texte explicite lié à la facturation peut + toujours aboutir ici même sur des réponses `401`/`403`, mais les + correspondances textuelles spécifiques au fournisseur restent limitées au fournisseur qui les possède (par exemple OpenRouter + `Key limit exceeded`). Les messages HTTP `402` réessayables liés à une fenêtre d’usage ou + aux limites de dépense d’organisation/espace de travail restent à la place dans le chemin `rate_limit`. +- `billingBackoffHoursByProvider` : remplacements facultatifs par fournisseur pour le délai de repli de facturation en heures. +- `billingMaxHours` : plafond en heures pour la croissance exponentielle du délai de repli de facturation (par défaut : `24`). +- `authPermanentBackoffMinutes` : délai de repli de base en minutes pour les échecs `auth_permanent` à haute confiance (par défaut : `10`). +- `authPermanentMaxMinutes` : plafond en minutes pour la croissance du délai de repli `auth_permanent` (par défaut : `60`). +- `failureWindowHours` : fenêtre glissante en heures utilisée pour les compteurs de délai de repli (par défaut : `24`). +- `overloadedProfileRotations` : nombre maximal de rotations de profil d’authentification chez le même fournisseur pour les erreurs de surcharge avant de basculer vers le modèle de secours (par défaut : `1`). Les formes de fournisseur occupé comme `ModelNotReadyException` aboutissent ici. +- `overloadedBackoffMs` : délai fixe avant nouvelle tentative d’une rotation surcharge fournisseur/profil (par défaut : `0`). +- `rateLimitedProfileRotations` : nombre maximal de rotations de profil d’authentification chez le même fournisseur pour les erreurs de limitation de débit avant de basculer vers le modèle de secours (par défaut : `1`). Cette catégorie de limitation de débit inclut des textes propres au fournisseur tels que `Too many concurrent requests`, `ThrottlingException`, `concurrency limit reached`, `workers_ai ... quota limit exceeded` et `resource exhausted`. --- @@ -3572,9 +3564,9 @@ Remarques : } ``` -- `enabled` : interrupteur maître de sortie d’instrumentation (par défaut : `true`). -- `flags` : tableau de chaînes d’indicateurs activant une sortie de journal ciblée (prend en charge les jokers comme `"telegram.*"` ou `"*"`). -- `stuckSessionWarnMs` : seuil d’ancienneté en ms pour émettre des avertissements de session bloquée pendant qu’une session reste en état de traitement. +- `enabled` : interrupteur principal de sortie de l’instrumentation (par défaut : `true`). +- `flags` : tableau de chaînes d’indicateurs activant une sortie de journal ciblée (prend en charge des jokers comme `"telegram.*"` ou `"*"`). +- `stuckSessionWarnMs` : seuil d’ancienneté en ms pour l’émission d’avertissements de session bloquée tant qu’une session reste à l’état de traitement. - `otel.enabled` : active le pipeline d’export OpenTelemetry (par défaut : `false`). - `otel.endpoint` : URL du collecteur pour l’export OTel. - `otel.protocol` : `"http/protobuf"` (par défaut) ou `"grpc"`. @@ -3582,10 +3574,10 @@ Remarques : - `otel.serviceName` : nom du service pour les attributs de ressource. - `otel.traces` / `otel.metrics` / `otel.logs` : activent l’export des traces, métriques ou journaux. - `otel.sampleRate` : taux d’échantillonnage des traces `0`–`1`. -- `otel.flushIntervalMs` : intervalle périodique de vidage de télémétrie en ms. -- `cacheTrace.enabled` : journalise des instantanés de trace de cache pour les exécutions embarquées (par défaut : `false`). -- `cacheTrace.filePath` : chemin de sortie pour le JSONL de trace de cache (par défaut : `$OPENCLAW_STATE_DIR/logs/cache-trace.jsonl`). -- `cacheTrace.includeMessages` / `includePrompt` / `includeSystem` : contrôlent ce qui est inclus dans la sortie de trace de cache (tous par défaut : `true`). +- `otel.flushIntervalMs` : intervalle périodique de vidage de la télémétrie en ms. +- `cacheTrace.enabled` : journalise des instantanés de trace du cache pour les exécutions intégrées (par défaut : `false`). +- `cacheTrace.filePath` : chemin de sortie pour le JSONL de trace du cache (par défaut : `$OPENCLAW_STATE_DIR/logs/cache-trace.jsonl`). +- `cacheTrace.includeMessages` / `includePrompt` / `includeSystem` : contrôlent ce qui est inclus dans la sortie de trace du cache (tous par défaut : `true`). --- @@ -3608,11 +3600,11 @@ Remarques : ``` - `channel` : canal de publication pour les installations npm/git — `"stable"`, `"beta"` ou `"dev"`. -- `checkOnStart` : vérifie les mises à jour npm au démarrage du Gateway (par défaut : `true`). +- `checkOnStart` : vérifie les mises à jour npm au démarrage de la Gateway (par défaut : `true`). - `auto.enabled` : active la mise à jour automatique en arrière-plan pour les installations de paquets (par défaut : `false`). -- `auto.stableDelayHours` : délai minimal en heures avant application automatique sur le canal stable (par défaut : `6` ; max : `168`). +- `auto.stableDelayHours` : délai minimal en heures avant l’application automatique du canal stable (par défaut : `6` ; max : `168`). - `auto.stableJitterHours` : fenêtre supplémentaire d’étalement du déploiement du canal stable en heures (par défaut : `12` ; max : `168`). -- `auto.betaCheckIntervalHours` : fréquence des vérifications du canal bêta en heures (par défaut : `1` ; max : `24`). +- `auto.betaCheckIntervalHours` : fréquence d’exécution des vérifications du canal bêta en heures (par défaut : `1` ; max : `24`). --- @@ -3645,21 +3637,21 @@ Remarques : } ``` -- `enabled` : porte de fonctionnalité ACP globale (par défaut : `false`). -- `dispatch.enabled` : porte indépendante pour la répartition des tours de session ACP (par défaut : `true`). Définissez `false` pour conserver les commandes ACP disponibles tout en bloquant l’exécution. -- `backend` : ID par défaut du backend d’exécution ACP (doit correspondre à un Plugin d’exécution ACP enregistré). -- `defaultAgent` : ID d’agent ACP cible de repli lorsque les créations ne spécifient pas de cible explicite. -- `allowedAgents` : liste d’autorisation des ID d’agents autorisés pour les sessions d’exécution ACP ; vide signifie aucune restriction supplémentaire. +- `enabled` : barrière globale de fonctionnalité ACP (par défaut : `false`). +- `dispatch.enabled` : barrière indépendante pour la distribution des tours de session ACP (par défaut : `true`). Définissez `false` pour garder les commandes ACP disponibles tout en bloquant l’exécution. +- `backend` : identifiant par défaut du backend d’exécution ACP (doit correspondre à un Plugin d’exécution ACP enregistré). +- `defaultAgent` : identifiant d’agent cible ACP de repli lorsque les créations ne spécifient pas de cible explicite. +- `allowedAgents` : liste d’autorisation des identifiants d’agent autorisés pour les sessions d’exécution ACP ; vide signifie aucune restriction supplémentaire. - `maxConcurrentSessions` : nombre maximal de sessions ACP actives simultanément. -- `stream.coalesceIdleMs` : fenêtre de vidage inactif en ms pour le texte diffusé. -- `stream.maxChunkChars` : taille maximale de bloc avant découpage de la projection par blocs diffusés. -- `stream.repeatSuppression` : supprime les lignes d’état/d’outil répétées par tour (par défaut : `true`). -- `stream.deliveryMode` : `"live"` diffuse progressivement ; `"final_only"` met en tampon jusqu’aux événements terminaux du tour. -- `stream.hiddenBoundarySeparator` : séparateur avant le texte visible après des événements d’outil cachés (par défaut : `"paragraph"`). -- `stream.maxOutputChars` : nombre maximal de caractères de sortie assistant projetés par tour ACP. +- `stream.coalesceIdleMs` : fenêtre de vidage au repos en ms pour le texte diffusé en flux. +- `stream.maxChunkChars` : taille maximale d’un fragment avant découpage de la projection de bloc diffusé. +- `stream.repeatSuppression` : supprime les lignes répétées d’état/d’outil par tour (par défaut : `true`). +- `stream.deliveryMode` : `"live"` diffuse de façon incrémentale ; `"final_only"` met en mémoire tampon jusqu’aux événements terminaux du tour. +- `stream.hiddenBoundarySeparator` : séparateur avant le texte visible après des événements d’outil masqués (par défaut : `"paragraph"`). +- `stream.maxOutputChars` : nombre maximal de caractères de sortie d’assistant projetés par tour ACP. - `stream.maxSessionUpdateChars` : nombre maximal de caractères pour les lignes projetées d’état/mise à jour ACP. -- `stream.tagVisibility` : enregistrement des noms de balises vers des remplacements booléens de visibilité pour les événements diffusés. -- `runtime.ttlMinutes` : TTL d’inactivité en minutes pour les workers de session ACP avant nettoyage admissible. +- `stream.tagVisibility` : enregistrement des noms de balises vers des remplacements booléens de visibilité pour les événements diffusés en flux. +- `runtime.ttlMinutes` : TTL d’inactivité en minutes pour les workers de session ACP avant nettoyage possible. - `runtime.installCommand` : commande d’installation facultative à exécuter lors de l’amorçage d’un environnement d’exécution ACP. --- @@ -3680,13 +3672,13 @@ Remarques : - `"random"` (par défaut) : slogans tournants humoristiques/de saison. - `"default"` : slogan neutre fixe (`All your chats, one OpenClaw.`). - `"off"` : aucun texte de slogan (le titre/version de la bannière reste affiché). -- Pour masquer toute la bannière (pas seulement les slogans), définissez la variable d’environnement `OPENCLAW_HIDE_BANNER=1`. +- Pour masquer toute la bannière (et pas seulement les slogans), définissez la variable d’environnement `OPENCLAW_HIDE_BANNER=1`. --- ## Assistant -Métadonnées écrites par les flux CLI de configuration guidée (`onboard`, `configure`, `doctor`) : +Métadonnées écrites par les flux de configuration guidée de la CLI (`onboard`, `configure`, `doctor`) : ```json5 { @@ -3710,9 +3702,9 @@ Voir les champs d’identité de `agents.list` sous [Valeurs par défaut des age ## Bridge (hérité, supprimé) -Les builds actuels n’incluent plus le bridge TCP. Les Node se connectent via le WebSocket Gateway. Les clés `bridge.*` ne font plus partie du schéma de configuration (la validation échoue tant qu’elles ne sont pas supprimées ; `openclaw doctor --fix` peut retirer les clés inconnues). +Les builds actuels n’incluent plus le bridge TCP. Les nœuds se connectent via la WebSocket Gateway. Les clés `bridge.*` ne font plus partie du schéma de configuration (la validation échoue tant qu’elles ne sont pas supprimées ; `openclaw doctor --fix` peut retirer les clés inconnues). - + ```json { @@ -3750,11 +3742,11 @@ Les builds actuels n’incluent plus le bridge TCP. Les Node se connectent via l } ``` -- `sessionRetention` : durée de conservation des sessions d’exécution Cron isolées terminées avant émondage depuis `sessions.json`. Contrôle également le nettoyage des transcriptions Cron archivées supprimées. Par défaut : `24h` ; définissez `false` pour désactiver. -- `runLog.maxBytes` : taille maximale par fichier journal d’exécution (`cron/runs/.jsonl`) avant émondage. Par défaut : `2_000_000` octets. -- `runLog.keepLines` : lignes les plus récentes conservées lorsque l’émondage du journal d’exécution est déclenché. Par défaut : `2000`. -- `webhookToken` : jeton bearer utilisé pour la livraison POST Webhook Cron (`delivery.mode = "webhook"`), si omis aucun en-tête d’authentification n’est envoyé. -- `webhook` : URL Webhook de repli héritée obsolète (http/https) utilisée uniquement pour les tâches stockées qui ont encore `notify: true`. +- `sessionRetention` : durée de conservation des sessions terminées d’exécution Cron isolée avant élagage depuis `sessions.json`. Contrôle aussi le nettoyage des transcriptions Cron supprimées archivées. Par défaut : `24h` ; définissez `false` pour désactiver. +- `runLog.maxBytes` : taille maximale par fichier de journal d’exécution (`cron/runs/.jsonl`) avant élagage. Par défaut : `2_000_000` octets. +- `runLog.keepLines` : nombre de lignes les plus récentes conservées lorsque l’élagage du journal d’exécution est déclenché. Par défaut : `2000`. +- `webhookToken` : jeton bearer utilisé pour la livraison POST du Webhook Cron (`delivery.mode = "webhook"`) ; s’il est omis, aucun en-tête d’authentification n’est envoyé. +- `webhook` : URL de Webhook de repli héritée obsolète (http/https) utilisée uniquement pour les tâches enregistrées qui ont encore `notify: true`. ### `cron.retry` @@ -3771,10 +3763,10 @@ Les builds actuels n’incluent plus le bridge TCP. Les Node se connectent via l ``` - `maxAttempts` : nombre maximal de nouvelles tentatives pour les tâches ponctuelles en cas d’erreurs transitoires (par défaut : `3` ; plage : `0`–`10`). -- `backoffMs` : tableau des délais de repli en ms pour chaque tentative de nouvelle tentative (par défaut : `[30000, 60000, 300000]` ; 1 à 10 entrées). -- `retryOn` : types d’erreurs qui déclenchent de nouvelles tentatives — `"rate_limit"`, `"overloaded"`, `"network"`, `"timeout"`, `"server_error"`. Omettez pour réessayer tous les types transitoires. +- `backoffMs` : tableau de délais de repli en ms pour chaque nouvelle tentative (par défaut : `[30000, 60000, 300000]` ; 1 à 10 entrées). +- `retryOn` : types d’erreur qui déclenchent des nouvelles tentatives — `"rate_limit"`, `"overloaded"`, `"network"`, `"timeout"`, `"server_error"`. Omettez pour réessayer tous les types transitoires. -S’applique uniquement aux tâches Cron ponctuelles. Les tâches récurrentes utilisent une gestion distincte des échecs. +S’applique uniquement aux tâches Cron ponctuelles. Les tâches récurrentes utilisent une gestion des échecs distincte. ### `cron.failureAlert` @@ -3793,10 +3785,10 @@ S’applique uniquement aux tâches Cron ponctuelles. Les tâches récurrentes u ``` - `enabled` : active les alertes d’échec pour les tâches Cron (par défaut : `false`). -- `after` : nombre d’échecs consécutifs avant le déclenchement d’une alerte (entier positif, min : `1`). -- `cooldownMs` : nombre minimal de millisecondes entre des alertes répétées pour une même tâche (entier non négatif). -- `mode` : mode de livraison — `"announce"` envoie via un message de canal ; `"webhook"` publie sur le Webhook configuré. -- `accountId` : ID facultatif de compte ou de canal pour circonscrire la livraison de l’alerte. +- `after` : nombre d’échecs consécutifs avant déclenchement d’une alerte (entier positif, min : `1`). +- `cooldownMs` : nombre minimal de millisecondes entre alertes répétées pour une même tâche (entier non négatif). +- `mode` : mode de livraison — `"announce"` envoie via un message de canal ; `"webhook"` publie vers le Webhook configuré. +- `accountId` : identifiant facultatif de compte ou de canal pour limiter la livraison de l’alerte. ### `cron.failureDestination` @@ -3813,16 +3805,16 @@ S’applique uniquement aux tâches Cron ponctuelles. Les tâches récurrentes u } ``` -- Destination par défaut pour les notifications d’échec Cron sur l’ensemble des tâches. -- `mode` : `"announce"` ou `"webhook"` ; par défaut `"announce"` lorsque suffisamment de données cibles existent. -- `channel` : remplacement de canal pour la livraison par annonce. `"last"` réutilise le dernier canal de livraison connu. -- `to` : cible explicite d’annonce ou URL Webhook. Obligatoire en mode Webhook. -- `accountId` : remplacement facultatif du compte pour la livraison. -- `delivery.failureDestination` par tâche remplace cette valeur par défaut globale. -- Lorsqu’aucune destination d’échec globale ou par tâche n’est définie, les tâches qui livrent déjà via `announce` reviennent à cette cible principale d’annonce en cas d’échec. +- Destination par défaut pour les notifications d’échec Cron pour toutes les tâches. +- `mode` : `"announce"` ou `"webhook"` ; vaut par défaut `"announce"` lorsque suffisamment de données cibles existent. +- `channel` : remplacement de canal pour la livraison d’annonce. `"last"` réutilise le dernier canal de livraison connu. +- `to` : cible explicite d’annonce ou URL de Webhook. Requis pour le mode Webhook. +- `accountId` : remplacement facultatif de compte pour la livraison. +- `delivery.failureDestination` par tâche remplace cette valeur globale par défaut. +- Lorsqu’aucune destination d’échec globale ou par tâche n’est définie, les tâches qui livrent déjà via `announce` se rabattent en cas d’échec sur cette cible d’annonce principale. - `delivery.failureDestination` n’est pris en charge que pour les tâches `sessionTarget="isolated"` sauf si le `delivery.mode` principal de la tâche est `"webhook"`. -Voir [Tâches Cron](/fr/automation/cron-jobs). Les exécutions Cron isolées sont suivies comme [tâches d’arrière-plan](/fr/automation/tasks). +Voir [Tâches Cron](/fr/automation/cron-jobs). Les exécutions Cron isolées sont suivies comme [tâches en arrière-plan](/fr/automation/tasks). --- @@ -3833,31 +3825,31 @@ Espaces réservés de modèle développés dans `tools.media.models[].args` : | Variable | Description | | ------------------ | ------------------------------------------------- | | `{{Body}}` | Corps complet du message entrant | -| `{{RawBody}}` | Corps brut (sans wrappers d’historique/expéditeur) | +| `{{RawBody}}` | Corps brut (sans wrappers d’historique/d’expéditeur) | | `{{BodyStripped}}` | Corps avec les mentions de groupe supprimées | | `{{From}}` | Identifiant de l’expéditeur | | `{{To}}` | Identifiant de destination | -| `{{MessageSid}}` | ID du message du canal | +| `{{MessageSid}}` | Identifiant du message de canal | | `{{SessionId}}` | UUID de la session actuelle | | `{{IsNewSession}}` | `"true"` lorsqu’une nouvelle session est créée | | `{{MediaUrl}}` | pseudo-URL du média entrant | | `{{MediaPath}}` | chemin local du média | | `{{MediaType}}` | type de média (image/audio/document/…) | | `{{Transcript}}` | transcription audio | -| `{{Prompt}}` | prompt média résolu pour les entrées CLI | -| `{{MaxChars}}` | nombre maximal de caractères résolu pour les entrées CLI | +| `{{Prompt}}` | invite média résolue pour les entrées CLI | +| `{{MaxChars}}` | nombre maximal résolu de caractères de sortie pour les entrées CLI | | `{{ChatType}}` | `"direct"` ou `"group"` | -| `{{GroupSubject}}` | sujet du groupe (au mieux) | -| `{{GroupMembers}}` | aperçu des membres du groupe (au mieux) | -| `{{SenderName}}` | nom d’affichage de l’expéditeur (au mieux) | -| `{{SenderE164}}` | numéro de téléphone de l’expéditeur (au mieux) | -| `{{Provider}}` | indication du fournisseur (whatsapp, telegram, discord, etc.) | +| `{{GroupSubject}}` | sujet du groupe (dans la mesure du possible) | +| `{{GroupMembers}}` | aperçu des membres du groupe (dans la mesure du possible) | +| `{{SenderName}}` | nom d’affichage de l’expéditeur (dans la mesure du possible) | +| `{{SenderE164}}` | numéro de téléphone de l’expéditeur (dans la mesure du possible) | +| `{{Provider}}` | indication de fournisseur (whatsapp, telegram, discord, etc.) | --- ## Inclusions de configuration (`$include`) -Divisez la configuration en plusieurs fichiers : +Scindez la configuration en plusieurs fichiers : ```json5 // ~/.openclaw/openclaw.json @@ -3873,12 +3865,12 @@ Divisez la configuration en plusieurs fichiers : **Comportement de fusion :** - Fichier unique : remplace l’objet conteneur. -- Tableau de fichiers : fusion profonde dans l’ordre (les suivants remplacent les précédents). +- Tableau de fichiers : fusion profonde dans l’ordre (les derniers remplacent les précédents). - Clés sœurs : fusionnées après les inclusions (remplacent les valeurs incluses). - Inclusions imbriquées : jusqu’à 10 niveaux de profondeur. -- Chemins : résolus relativement au fichier incluant, mais doivent rester à l’intérieur du répertoire de configuration de niveau supérieur (`dirname` de `openclaw.json`). Les formes absolues/`../` sont autorisées uniquement si elles se résolvent toujours à l’intérieur de cette limite. +- Chemins : résolus relativement au fichier incluant, mais doivent rester à l’intérieur du répertoire de configuration de premier niveau (`dirname` de `openclaw.json`). Les formes absolues/`../` sont autorisées uniquement si elles se résolvent toujours à l’intérieur de cette limite. - Erreurs : messages clairs pour les fichiers manquants, les erreurs d’analyse et les inclusions circulaires. --- -_Related: [Configuration](/fr/gateway/configuration) · [Exemples de configuration](/fr/gateway/configuration-examples) · [Doctor](/fr/gateway/doctor)_ +_Related: [Configuration](/fr/gateway/configuration) · [Configuration Examples](/fr/gateway/configuration-examples) · [Doctor](/fr/gateway/doctor)_ diff --git a/docs/fr/gateway/doctor.md b/docs/fr/gateway/doctor.md index bc565aec7..59b91b939 100644 --- a/docs/fr/gateway/doctor.md +++ b/docs/fr/gateway/doctor.md @@ -1,14 +1,14 @@ --- read_when: - Ajouter ou modifier des migrations doctor - - Introduire des changements de configuration incompatibles -summary: 'Commande Doctor : vérifications d’état, migrations de configuration et étapes de réparation' -title: Doctor + - Introduire des modifications de configuration incompatibles +summary: 'Commande doctor : vérifications d’état, migrations de configuration et étapes de réparation' +title: Médecin x-i18n: - generated_at: "2026-04-09T01:29:22Z" + generated_at: "2026-04-20T07:05:38Z" model: gpt-5.4 provider: openai - source_hash: 75d321bd1ad0e16c29f2382e249c51edfc3a8d33b55bdceea39e7dbcd4901fce + source_hash: 61a5e01a306058c49be6095f7c8082d779a55d63cf3b5f4c4096173943faf51b source_path: gateway/doctor.md workflow: 15 --- @@ -16,7 +16,7 @@ x-i18n: # Doctor `openclaw doctor` est l’outil de réparation + migration pour OpenClaw. Il corrige les -configurations/états obsolètes, vérifie l’état du système et fournit des étapes de réparation exploitables. +configurations/états obsolètes, vérifie l’état de santé et fournit des étapes de réparation exploitables. ## Démarrage rapide @@ -24,19 +24,19 @@ configurations/états obsolètes, vérifie l’état du système et fournit des openclaw doctor ``` -### Sans interface / automatisation +### Mode headless / automatisation ```bash openclaw doctor --yes ``` -Accepte les valeurs par défaut sans demander de confirmation (y compris les étapes de réparation de redémarrage/service/sandbox lorsque c’est applicable). +Accepte les valeurs par défaut sans invite (y compris les étapes de réparation de redémarrage/service/sandbox lorsque cela s’applique). ```bash openclaw doctor --repair ``` -Applique les réparations recommandées sans demander de confirmation (réparations + redémarrages lorsque cela est sûr). +Applique les réparations recommandées sans invite (réparations + redémarrages lorsque c’est sûr). ```bash openclaw doctor --repair --force @@ -48,7 +48,7 @@ Applique aussi les réparations agressives (écrase les configurations de superv openclaw doctor --non-interactive ``` -S’exécute sans invites et applique uniquement les migrations sûres (normalisation de la configuration + déplacements d’état sur disque). Ignore les actions de redémarrage/service/sandbox qui nécessitent une confirmation humaine. +S’exécute sans invites et applique uniquement les migrations sûres (normalisation de configuration + déplacements d’état sur disque). Ignore les actions de redémarrage/service/sandbox qui nécessitent une confirmation humaine. Les migrations d’état héritées s’exécutent automatiquement lorsqu’elles sont détectées. ```bash @@ -57,126 +57,127 @@ openclaw doctor --deep Analyse les services système pour détecter des installations Gateway supplémentaires (launchd/systemd/schtasks). -Si vous voulez examiner les modifications avant l’écriture, ouvrez d’abord le fichier de configuration : +Si vous voulez examiner les changements avant l’écriture, ouvrez d’abord le fichier de configuration : ```bash cat ~/.openclaw/openclaw.json ``` -## Ce que fait la commande (résumé) +## Ce qu’il fait (résumé) -- Mise à jour préalable facultative pour les installations git (interactif uniquement). -- Vérification de fraîcheur du protocole UI (reconstruit la Control UI lorsque le schéma de protocole est plus récent). +- Mise à jour préalable optionnelle pour les installations git (mode interactif uniquement). +- Vérification de fraîcheur du protocole UI (reconstruit l’interface de contrôle si le schéma du protocole est plus récent). - Vérification d’état + invite de redémarrage. -- Résumé de l’état des Skills (éligibles/manquants/bloqués) et état des plugins. +- Résumé d’état des Skills (éligibles/manquantes/bloquées) et état des plugins. - Normalisation de la configuration pour les valeurs héritées. -- Migration de la configuration Talk depuis les champs plats hérités `talk.*` vers `talk.provider` + `talk.providers.`. -- Vérifications de migration du navigateur pour les anciennes configurations d’extension Chrome et de préparation Chrome MCP. +- Migration de la configuration Talk des champs plats hérités `talk.*` vers `talk.provider` + `talk.providers.`. +- Vérifications de migration du navigateur pour les configurations héritées de l’extension Chrome et la préparation de Chrome MCP. - Avertissements sur les remplacements de fournisseur OpenCode (`models.providers.opencode` / `models.providers.opencode-go`). -- Avertissements de masquage OAuth Codex (`models.providers.openai-codex`). +- Avertissements sur le masquage OAuth Codex (`models.providers.openai-codex`). - Vérification des prérequis TLS OAuth pour les profils OAuth OpenAI Codex. -- Migration d’état héritée sur disque (sessions/répertoire d’agent/authentification WhatsApp). -- Migration des anciennes clés de contrat de manifeste de plugin (`speechProviders`, `realtimeTranscriptionProviders`, `realtimeVoiceProviders`, `mediaUnderstandingProviders`, `imageGenerationProviders`, `videoGenerationProviders`, `webFetchProviders`, `webSearchProviders` → `contracts`). -- Migration de l’ancien magasin cron (`jobId`, `schedule.cron`, champs delivery/payload de niveau supérieur, `provider` dans payload, tâches de secours webhook simples `notify: true`). +- Migration de l’état hérité sur disque (sessions/répertoire agent/authentification WhatsApp). +- Migration de clé de contrat de manifeste Plugin héritée (`speechProviders`, `realtimeTranscriptionProviders`, `realtimeVoiceProviders`, `mediaUnderstandingProviders`, `imageGenerationProviders`, `videoGenerationProviders`, `webFetchProviders`, `webSearchProviders` → `contracts`). +- Migration héritée du stockage Cron (`jobId`, `schedule.cron`, champs delivery/payload de niveau supérieur, `provider` de payload, tâches de secours Webhook simples `notify: true`). - Inspection des fichiers de verrouillage de session et nettoyage des verrous obsolètes. - Vérifications d’intégrité et de permissions de l’état (sessions, transcriptions, répertoire d’état). - Vérifications des permissions du fichier de configuration (`chmod 600`) lors d’une exécution en local. -- État de l’authentification des modèles : vérifie l’expiration OAuth, peut rafraîchir les jetons proches de l’expiration et signale les états de délai d’attente/désactivation des profils d’authentification. -- Détection de répertoires d’espace de travail supplémentaires (`~/openclaw`). +- État de l’authentification des modèles : vérifie l’expiration OAuth, peut actualiser les jetons proches de l’expiration et signale les états de cooldown/désactivation des profils d’authentification. +- Détection d’un répertoire de workspace supplémentaire (`~/openclaw`). - Réparation de l’image sandbox lorsque le sandboxing est activé. -- Migration des anciens services et détection de passerelles supplémentaires. -- Migration de l’état hérité du canal Matrix (en mode `--fix` / `--repair`). -- Vérifications d’exécution Gateway (service installé mais non démarré ; libellé launchd mis en cache). -- Avertissements sur l’état des canaux (testés depuis la passerelle en cours d’exécution). -- Audit de la configuration du superviseur (launchd/systemd/schtasks) avec réparation facultative. -- Vérifications de bonnes pratiques d’exécution Gateway (Node vs Bun, chemins de gestionnaires de versions). -- Diagnostic de collision de port Gateway (par défaut `18789`). +- Migration de service héritée et détection de Gateway supplémentaires. +- Migration d’état hérité du canal Matrix (en mode `--fix` / `--repair`). +- Vérifications d’exécution Gateway (service installé mais non démarré ; étiquette launchd en cache). +- Avertissements d’état des canaux (testés à partir de la Gateway en cours d’exécution). +- Audit de configuration du superviseur (launchd/systemd/schtasks) avec réparation optionnelle. +- Vérifications des bonnes pratiques d’exécution Gateway (Node vs Bun, chemins du gestionnaire de versions). +- Diagnostics de collision de port Gateway (par défaut `18789`). - Avertissements de sécurité pour les politiques DM ouvertes. -- Vérifications d’authentification Gateway pour le mode jeton local (propose la génération d’un jeton lorsqu’aucune source de jeton n’existe ; n’écrase pas les configurations `SecretRef` de jeton). -- Vérification de persistance systemd sur Linux. -- Vérification de la taille des fichiers bootstrap de l’espace de travail (avertissements de troncature/proximité de limite pour les fichiers de contexte). -- Vérification de l’état des complétions shell et installation/mise à niveau automatiques. +- Vérifications d’authentification Gateway pour le mode jeton local (propose une génération de jeton lorsqu’aucune source de jeton n’existe ; n’écrase pas les configurations SecretRef de jeton). +- Détection des problèmes d’appairage d’appareil (premières demandes d’appairage en attente, mises à niveau de rôle/scope en attente, dérive obsolète du cache local de jeton d’appareil et dérive d’authentification des enregistrements appairés). +- Vérification de linger systemd sous Linux. +- Vérification de la taille du fichier bootstrap du workspace (avertissements de troncature/proche de la limite pour les fichiers de contexte). +- Vérification de l’état des complétions shell et auto-installation/mise à niveau. - Vérification de préparation du fournisseur d’embeddings pour la recherche mémoire (modèle local, clé API distante ou binaire QMD). -- Vérifications d’installation source (incohérence d’espace de travail pnpm, ressources UI manquantes, binaire tsx manquant). +- Vérifications des installations source (incohérence de workspace pnpm, ressources UI manquantes, binaire tsx manquant). - Écrit la configuration mise à jour + les métadonnées de l’assistant. -## Dreams UI : backfill et réinitialisation +## Complétion et réinitialisation de l’interface Dreams -La scène Dreams de la Control UI inclut des actions **Backfill**, **Reset** et **Clear Grounded** -pour le flux de travail de grounded dreaming. Ces actions utilisent des -méthodes RPC de style doctor de la passerelle, mais elles ne font **pas** partie de la réparation/migration CLI -de `openclaw doctor`. +La scène Dreams de l’interface de contrôle inclut les actions **Backfill**, **Reset** et **Clear Grounded** +pour le flux de travail de Dreaming fondé. Ces actions utilisent des méthodes RPC +de type doctor de Gateway, mais elles ne font **pas** partie de la +réparation/migration de la CLI `openclaw doctor`. -Ce qu’elles font : +Ce qu’elles font : -- **Backfill** analyse les fichiers historiques `memory/YYYY-MM-DD.md` dans l’espace de travail - actif, exécute le passage de journal REM grounded et écrit des entrées de backfill réversibles - dans `DREAMS.md`. -- **Reset** supprime uniquement ces entrées de journal de backfill marquées de `DREAMS.md`. -- **Clear Grounded** supprime uniquement les entrées à court terme staged, grounded-only, - issues de la relecture historique et qui n’ont pas encore accumulé de rappel en direct ni - de support quotidien. +- **Backfill** analyse les fichiers historiques `memory/YYYY-MM-DD.md` dans le + workspace actif, exécute le passage grounded REM diary et écrit des entrées de + complétion réversibles dans `DREAMS.md`. +- **Reset** supprime uniquement ces entrées de journal de complétion marquées de `DREAMS.md`. +- **Clear Grounded** supprime uniquement les entrées à court terme provisoires, uniquement fondées, + issues d’une relecture historique et qui n’ont pas encore accumulé de rappel en direct + ni de support quotidien. -Ce qu’elles ne font **pas** à elles seules : +Ce qu’elles ne font **pas** à elles seules : - elles ne modifient pas `MEMORY.md` - elles n’exécutent pas les migrations doctor complètes -- elles ne placent pas automatiquement les candidats grounded dans le magasin de promotion - actif à court terme sauf si vous exécutez explicitement d’abord le chemin CLI staged +- elles ne mettent pas automatiquement en préparation les candidats fondés dans le stockage + vivant de promotion à court terme sauf si vous exécutez explicitement d’abord le chemin CLI en préparation -Si vous voulez que la relecture historique grounded influence la voie normale de promotion profonde, -utilisez plutôt le flux CLI : +Si vous voulez que la relecture historique fondée influence le flux normal de promotion profonde, +utilisez plutôt le flux CLI : ```bash openclaw memory rem-backfill --path ./memory --stage-short-term ``` -Cela place des candidats durables grounded dans le magasin de dreaming à court terme tout en -conservant `DREAMS.md` comme surface de révision. +Cela met en préparation les candidats durables fondés dans le stockage Dreaming à court terme tout en +gardant `DREAMS.md` comme surface de révision. ## Comportement détaillé et justification -### 0) Mise à jour facultative (installations git) +### 0) Mise à jour optionnelle (installations git) -S’il s’agit d’un checkout git et que doctor s’exécute en mode interactif, il propose de -mettre à jour (fetch/rebase/build) avant d’exécuter doctor. +S’il s’agit d’un checkout git et que doctor s’exécute en mode interactif, il propose +de mettre à jour (fetch/rebase/build) avant d’exécuter doctor. ### 1) Normalisation de la configuration Si la configuration contient des formes de valeurs héritées (par exemple `messages.ackReaction` -sans remplacement spécifique à un canal), doctor les normalise selon le schéma -actuel. +sans remplacement spécifique à un canal), doctor les normalise vers le +schéma actuel. -Cela inclut les champs plats Talk hérités. La configuration Talk publique actuelle est +Cela inclut les champs plats hérités de Talk. La configuration publique actuelle de Talk est `talk.provider` + `talk.providers.`. Doctor réécrit les anciennes formes `talk.voiceId` / `talk.voiceAliases` / `talk.modelId` / `talk.outputFormat` / -`talk.apiKey` dans la map des fournisseurs. +`talk.apiKey` dans la table des fournisseurs. -### 2) Migrations des clés de configuration héritées +### 2) Migrations de clés de configuration héritées Lorsque la configuration contient des clés obsolètes, les autres commandes refusent de s’exécuter et demandent d’exécuter `openclaw doctor`. -Doctor va : +Doctor va : - Expliquer quelles clés héritées ont été trouvées. -- Afficher la migration qu’il a appliquée. +- Montrer la migration qu’il a appliquée. - Réécrire `~/.openclaw/openclaw.json` avec le schéma mis à jour. -La Gateway exécute aussi automatiquement les migrations doctor au démarrage lorsqu’elle détecte un -format de configuration hérité, afin que les configurations obsolètes soient réparées sans intervention manuelle. -Les migrations du magasin de tâches cron sont gérées par `openclaw doctor --fix`. +La Gateway exécute également automatiquement les migrations doctor au démarrage lorsqu’elle détecte un +format de configuration hérité, de sorte que les configurations obsolètes sont réparées sans intervention manuelle. +Les migrations du stockage des tâches Cron sont gérées par `openclaw doctor --fix`. -Migrations actuelles : +Migrations actuelles : - `routing.allowFrom` → `channels.whatsapp.allowFrom` - `routing.groupChat.requireMention` → `channels.whatsapp/telegram/imessage.groups."*".requireMention` - `routing.groupChat.historyLimit` → `messages.groupChat.historyLimit` - `routing.groupChat.mentionPatterns` → `messages.groupChat.mentionPatterns` - `routing.queue` → `messages.queue` -- `routing.bindings` → `bindings` au niveau supérieur +- `routing.bindings` → `bindings` de niveau supérieur - `routing.agents`/`routing.defaultAgentId` → `agents.list` + `agents.list[].default` -- ancien `talk.voiceId`/`talk.voiceAliases`/`talk.modelId`/`talk.outputFormat`/`talk.apiKey` → `talk.provider` + `talk.providers.` +- héritage `talk.voiceId`/`talk.voiceAliases`/`talk.modelId`/`talk.outputFormat`/`talk.apiKey` → `talk.provider` + `talk.providers.` - `routing.agentToAgent` → `tools.agentToAgent` - `routing.transcribeAudio` → `tools.media.audio.models` - `messages.tts.` (`openai`/`elevenlabs`/`microsoft`/`edge`) → `messages.tts.providers.` @@ -189,361 +190,389 @@ Migrations actuelles : - `plugins.entries.voice-call.config.streaming.openaiApiKey|sttModel|silenceDurationMs|vadThreshold` → `plugins.entries.voice-call.config.streaming.providers.openai.*` - `bindings[].match.accountID` → `bindings[].match.accountId` -- Pour les canaux avec des `accounts` nommés mais avec encore des valeurs de canal de niveau supérieur à compte unique, déplacer ces valeurs liées au compte dans le compte promu choisi pour ce canal (`accounts.default` pour la plupart des canaux ; Matrix peut conserver une cible nommée/par défaut existante correspondante) +- Pour les canaux avec des `accounts` nommés mais encore des valeurs de canal de niveau supérieur en mode compte unique, déplacer ces valeurs liées au compte dans le compte promu choisi pour ce canal (`accounts.default` pour la plupart des canaux ; Matrix peut conserver une cible nommée/par défaut correspondante existante) - `identity` → `agents.list[].identity` - `agent.*` → `agents.defaults` + `tools.*` (tools/elevated/exec/sandbox/subagents) - `agent.model`/`allowedModels`/`modelAliases`/`modelFallbacks`/`imageModelFallbacks` → `agents.defaults.models` + `agents.defaults.model.primary/fallbacks` + `agents.defaults.imageModel.primary/fallbacks` - `browser.ssrfPolicy.allowPrivateNetwork` → `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork` - `browser.profiles.*.driver: "extension"` → `"existing-session"` -- supprimer `browser.relayBindHost` (ancien paramètre de relais d’extension) +- supprimer `browser.relayBindHost` (paramètre hérité du relais d’extension) -Les avertissements doctor incluent aussi des recommandations sur les comptes par défaut pour les canaux multi-comptes : +Les avertissements doctor incluent aussi des conseils sur le compte par défaut pour les canaux multi-comptes : - Si deux entrées ou plus sont configurées dans `channels..accounts` sans `channels..defaultAccount` ni `accounts.default`, doctor avertit que le routage de secours peut choisir un compte inattendu. -- Si `channels..defaultAccount` est défini sur un identifiant de compte inconnu, doctor avertit et liste les identifiants de compte configurés. +- Si `channels..defaultAccount` est défini sur un ID de compte inconnu, doctor avertit et liste les ID de compte configurés. ### 2b) Remplacements de fournisseur OpenCode -Si vous avez ajouté `models.providers.opencode`, `opencode-zen` ou `opencode-go` -manuellement, cela remplace le catalogue OpenCode intégré issu de `@mariozechner/pi-ai`. -Cela peut forcer des modèles vers la mauvaise API ou remettre les coûts à zéro. Doctor avertit afin que vous -puissiez supprimer ce remplacement et restaurer le routage API + les coûts par modèle. +Si vous avez ajouté manuellement `models.providers.opencode`, `opencode-zen` ou `opencode-go`, +cela remplace le catalogue OpenCode intégré de `@mariozechner/pi-ai`. +Cela peut forcer les modèles à utiliser la mauvaise API ou remettre les coûts à zéro. Doctor avertit afin que vous +puissiez supprimer ce remplacement et restaurer le routage API par modèle + les coûts. -### 2c) Migration du navigateur et préparation Chrome MCP +### 2c) Migration du navigateur et préparation de Chrome MCP -Si la configuration de votre navigateur pointe encore vers le chemin supprimé de l’extension Chrome, doctor -la normalise vers le modèle d’attachement Chrome MCP local à l’hôte actuel : +Si votre configuration de navigateur pointe encore vers le chemin supprimé de l’extension Chrome, doctor +la normalise vers le modèle actuel d’attachement Chrome MCP local à l’hôte : - `browser.profiles.*.driver: "extension"` devient `"existing-session"` - `browser.relayBindHost` est supprimé -Doctor audite aussi le chemin Chrome MCP local à l’hôte lorsque vous utilisez `defaultProfile: -"user"` ou un profil `existing-session` configuré : +Doctor audite également le chemin Chrome MCP local à l’hôte lorsque vous utilisez `defaultProfile: +"user"` ou un profil `existing-session` configuré : -- vérifie si Google Chrome est installé sur le même hôte pour les profils - d’auto-connexion par défaut -- vérifie la version Chrome détectée et avertit lorsqu’elle est inférieure à Chrome 144 -- rappelle d’activer le débogage distant dans la page inspect du navigateur (par +- vérifie si Google Chrome est installé sur le même hôte pour les profils de + connexion automatique par défaut +- vérifie la version détectée de Chrome et avertit lorsqu’elle est inférieure à Chrome 144 +- rappelle d’activer le débogage à distance dans la page d’inspection du navigateur (par exemple `chrome://inspect/#remote-debugging`, `brave://inspect/#remote-debugging`, ou `edge://inspect/#remote-debugging`) Doctor ne peut pas activer ce paramètre côté Chrome à votre place. Le Chrome MCP local à l’hôte -requiert toujours : +requiert toujours : -- un navigateur basé sur Chromium 144+ sur l’hôte gateway/node -- l’exécution locale du navigateur -- le débogage distant activé dans ce navigateur +- un navigateur basé sur Chromium 144+ sur l’hôte Gateway/Node +- le navigateur exécuté localement +- le débogage à distance activé dans ce navigateur - l’approbation de la première invite de consentement d’attachement dans le navigateur La préparation ici concerne uniquement les prérequis d’attachement local. Existing-session conserve -les limites actuelles des routes Chrome MCP ; les routes avancées comme `responsebody`, l’export PDF, -l’interception des téléchargements et les actions par lots requièrent toujours un +les limites de routage actuelles de Chrome MCP ; des routes avancées comme `responsebody`, l’export PDF, +l’interception des téléchargements et les actions par lot nécessitent toujours un navigateur géré ou un profil CDP brut. -Cette vérification ne s’applique **pas** à Docker, sandbox, remote-browser ni aux autres -flux headless. Ceux-ci continuent d’utiliser CDP brut. +Cette vérification ne s’applique **pas** à Docker, au sandbox, au navigateur distant ni aux autres +flux headless. Ceux-ci continuent d’utiliser du CDP brut. ### 2d) Prérequis TLS OAuth -Lorsqu’un profil OAuth OpenAI Codex est configuré, doctor sonde le point de terminaison d’autorisation OpenAI -pour vérifier que la pile TLS locale Node/OpenSSL peut +Lorsqu’un profil OAuth OpenAI Codex est configuré, doctor sonde le point de terminaison +d’autorisation OpenAI pour vérifier que la pile TLS locale Node/OpenSSL peut valider la chaîne de certificats. Si la sonde échoue avec une erreur de certificat (par exemple `UNABLE_TO_GET_ISSUER_CERT_LOCALLY`, certificat expiré ou certificat autosigné), -doctor affiche des indications de correction spécifiques à la plateforme. Sur macOS avec un Node Homebrew, la +doctor affiche des conseils de correction spécifiques à la plateforme. Sur macOS avec un Node Homebrew, la correction est généralement `brew postinstall ca-certificates`. Avec `--deep`, la sonde s’exécute -même si la passerelle est saine. +même si la Gateway est en bon état. ### 2c) Remplacements de fournisseur OAuth Codex -Si vous avez précédemment ajouté d’anciens paramètres de transport OpenAI sous -`models.providers.openai-codex`, ils peuvent masquer le chemin de fournisseur -OAuth Codex intégré que les versions récentes utilisent automatiquement. Doctor avertit lorsqu’il voit -ces anciens paramètres de transport en même temps que Codex OAuth afin que vous puissiez supprimer ou réécrire -le remplacement de transport obsolète et retrouver le comportement intégré de routage/secours. -Les proxies personnalisés et les remplacements uniquement par en-têtes restent pris en charge et ne +Si vous avez précédemment ajouté des paramètres hérités de transport OpenAI sous +`models.providers.openai-codex`, ils peuvent masquer le chemin du fournisseur +OAuth Codex intégré que les versions plus récentes utilisent automatiquement. Doctor avertit lorsqu’il voit +ces anciens paramètres de transport en même temps que Codex OAuth afin que vous puissiez supprimer +ou réécrire le remplacement de transport obsolète et retrouver le comportement +intégré de routage/secours. Les proxys personnalisés et les remplacements limités aux en-têtes restent pris en charge et ne déclenchent pas cet avertissement. -### 3) Migrations d’état héritées (organisation sur disque) +### 3) Migrations d’état héritées (disposition sur disque) -Doctor peut migrer d’anciennes organisations sur disque vers la structure actuelle : +Doctor peut migrer d’anciennes dispositions sur disque vers la structure actuelle : -- Magasin de sessions + transcriptions : +- Stockage des sessions + transcriptions : - de `~/.openclaw/sessions/` vers `~/.openclaw/agents//sessions/` -- Répertoire d’agent : +- Répertoire agent : - de `~/.openclaw/agent/` vers `~/.openclaw/agents//agent/` -- État d’authentification WhatsApp (Baileys) : - - depuis les anciens `~/.openclaw/credentials/*.json` (sauf `oauth.json`) - - vers `~/.openclaw/credentials/whatsapp//...` (identifiant de compte par défaut : `default`) +- État d’authentification WhatsApp (Baileys) : + - de l’héritage `~/.openclaw/credentials/*.json` (sauf `oauth.json`) + - vers `~/.openclaw/credentials/whatsapp//...` (ID de compte par défaut : `default`) -Ces migrations sont réalisées au mieux et sont idempotentes ; doctor émet des avertissements lorsqu’il +Ces migrations sont en mode meilleur effort et idempotentes ; doctor émettra des avertissements lorsqu’il laisse des dossiers hérités en place comme sauvegardes. La Gateway/CLI migre aussi automatiquement -au démarrage les anciennes sessions + le répertoire d’agent afin que l’historique/l’authentification/les modèles aboutissent dans le chemin -par agent sans exécution manuelle de doctor. L’authentification WhatsApp est volontairement migrée uniquement -via `openclaw doctor`. La normalisation du fournisseur Talk/de la map de fournisseurs compare désormais -par égalité structurelle ; ainsi, les différences d’ordre des clés ne déclenchent plus de -modifications répétées et sans effet avec `doctor --fix`. +les sessions héritées + le répertoire agent au démarrage afin que l’historique/l’authentification/les modèles aboutissent dans le +chemin par agent sans exécution manuelle de doctor. L’authentification WhatsApp est intentionnellement +migrée uniquement via `openclaw doctor`. La normalisation du fournisseur/de la table des fournisseurs Talk +compare désormais selon l’égalité structurelle, donc les différences de seul ordre des clés ne déclenchent plus +de changements no-op répétés de `doctor --fix`. -### 3a) Migrations héritées de manifeste de plugin +### 3a) Migrations héritées de manifeste Plugin -Doctor analyse tous les manifestes de plugins installés pour détecter les clés de capacité de niveau supérieur -obsolètes (`speechProviders`, `realtimeTranscriptionProviders`, +Doctor analyse tous les manifestes de plugins installés à la recherche de clés de capacité +obsolètes de niveau supérieur (`speechProviders`, `realtimeTranscriptionProviders`, `realtimeVoiceProviders`, `mediaUnderstandingProviders`, `imageGenerationProviders`, `videoGenerationProviders`, `webFetchProviders`, `webSearchProviders`). Lorsqu’elles sont trouvées, il propose de les déplacer dans l’objet `contracts` -et de réécrire le fichier manifeste en place. Cette migration est idempotente ; +et de réécrire le fichier manifeste sur place. Cette migration est idempotente ; si la clé `contracts` contient déjà les mêmes valeurs, la clé héritée est supprimée sans dupliquer les données. -### 3b) Migrations héritées du magasin cron +### 3b) Migrations héritées du stockage Cron -Doctor vérifie aussi le magasin de tâches cron (`~/.openclaw/cron/jobs.json` par défaut, -ou `cron.store` en cas de remplacement) pour détecter d’anciennes formes de tâches que l’ordonnanceur accepte encore -pour compatibilité. +Doctor vérifie également le stockage des tâches Cron (`~/.openclaw/cron/jobs.json` par défaut, +ou `cron.store` si remplacé) à la recherche d’anciennes formes de tâches que le planificateur +accepte encore pour compatibilité. -Nettoyages cron actuels : +Les nettoyages Cron actuels incluent : - `jobId` → `id` - `schedule.cron` → `schedule.expr` - champs payload de niveau supérieur (`message`, `model`, `thinking`, ...) → `payload` - champs delivery de niveau supérieur (`deliver`, `channel`, `to`, `provider`, ...) → `delivery` - alias de delivery `provider` dans payload → `delivery.channel` explicite -- tâches de secours webhook héritées simples `notify: true` → `delivery.mode="webhook"` explicite avec `delivery.to=cron.webhook` +- tâches de secours Webhook héritées simples `notify: true` → `delivery.mode="webhook"` explicite avec `delivery.to=cron.webhook` Doctor ne migre automatiquement les tâches `notify: true` que lorsqu’il peut le faire sans -modifier le comportement. Si une tâche combine le secours notify hérité avec un mode de -delivery existant non-webhook, doctor avertit et laisse cette tâche pour révision manuelle. +changer le comportement. Si une tâche combine un secours notify hérité avec un mode +delivery non-Webhook existant, doctor avertit et laisse cette tâche pour révision manuelle. ### 3c) Nettoyage des verrous de session -Doctor analyse chaque répertoire de session d’agent à la recherche de fichiers de verrouillage d’écriture obsolètes — des fichiers laissés -derrière lorsqu’une session s’est terminée anormalement. Pour chaque fichier de verrouillage trouvé, il signale : +Doctor analyse chaque répertoire de session d’agent à la recherche de fichiers de verrouillage d’écriture obsolètes — fichiers laissés +derrière lorsqu’une session s’est terminée anormalement. Pour chaque fichier de verrouillage trouvé, il signale : le chemin, le PID, si le PID est encore actif, l’âge du verrou et s’il est -considéré comme obsolète (PID mort ou plus ancien que 30 minutes). En mode `--fix` / `--repair`, -il supprime automatiquement les fichiers de verrouillage obsolètes ; sinon, il affiche une note et +considéré comme obsolète (PID mort ou plus de 30 minutes). En mode `--fix` / `--repair`, +il supprime automatiquement les fichiers de verrouillage obsolètes ; sinon il affiche une note et vous demande de relancer avec `--fix`. ### 4) Vérifications d’intégrité de l’état (persistance des sessions, routage et sécurité) Le répertoire d’état est le tronc cérébral opérationnel. S’il disparaît, vous perdez -les sessions, les identifiants, les journaux et la configuration (sauf si vous avez des sauvegardes ailleurs). +les sessions, identifiants, journaux et la configuration (sauf si vous avez des sauvegardes ailleurs). -Doctor vérifie : +Doctor vérifie : -- **Répertoire d’état manquant** : avertit d’une perte d’état catastrophique, propose de recréer +- **Répertoire d’état manquant** : avertit d’une perte d’état catastrophique, propose de recréer le répertoire et rappelle qu’il ne peut pas récupérer les données manquantes. -- **Permissions du répertoire d’état** : vérifie l’inscriptibilité ; propose de réparer les permissions - (et affiche une indication `chown` lorsqu’une incohérence propriétaire/groupe est détectée). -- **Répertoire d’état macOS synchronisé par le cloud** : avertit lorsque l’état se résout sous iCloud Drive +- **Permissions du répertoire d’état** : vérifie l’écriture ; propose de réparer les permissions + (et affiche une indication `chown` lorsqu’une discordance propriétaire/groupe est détectée). +- **Répertoire d’état macOS synchronisé dans le cloud** : avertit lorsque l’état se résout sous iCloud Drive (`~/Library/Mobile Documents/com~apple~CloudDocs/...`) ou - `~/Library/CloudStorage/...` car les chemins adossés à la synchronisation peuvent causer des E/S plus lentes + `~/Library/CloudStorage/...` parce que les chemins adossés à la synchronisation peuvent provoquer des E/S plus lentes et des courses de verrouillage/synchronisation. -- **Répertoire d’état Linux sur SD ou eMMC** : avertit lorsque l’état se résout vers une source de montage `mmcblk*`, - car les E/S aléatoires adossées à une carte SD ou à eMMC peuvent être plus lentes et s’user - plus vite sous les écritures de session et d’identifiants. -- **Répertoires de session manquants** : `sessions/` et le répertoire de stockage des sessions sont - requis pour persister l’historique et éviter les plantages `ENOENT`. -- **Incohérence de transcription** : avertit lorsque des entrées de session récentes ont des +- **Répertoire d’état Linux sur SD ou eMMC** : avertit lorsque l’état se résout vers une source de montage `mmcblk*`, + car les E/S aléatoires sur SD ou eMMC peuvent être plus lentes et user + plus vite avec les écritures de sessions et d’identifiants. +- **Répertoires de session manquants** : `sessions/` et le répertoire de stockage des sessions sont + nécessaires pour persister l’historique et éviter les crashs `ENOENT`. +- **Incohérence de transcription** : avertit lorsque des entrées de session récentes ont des fichiers de transcription manquants. -- **Session principale “JSONL sur 1 ligne”** : signale lorsque la transcription principale n’a qu’une seule - ligne (l’historique ne s’accumule pas). -- **Répertoires d’état multiples** : avertit lorsque plusieurs dossiers `~/.openclaw` existent entre - des répertoires personnels ou lorsque `OPENCLAW_STATE_DIR` pointe ailleurs (l’historique peut - se fragmenter entre les installations). -- **Rappel du mode distant** : si `gateway.mode=remote`, doctor rappelle de l’exécuter - sur l’hôte distant (l’état s’y trouve). -- **Permissions du fichier de configuration** : avertit si `~/.openclaw/openclaw.json` est - lisible par le groupe ou le monde et propose de le restreindre à `600`. +- **Session principale « JSONL sur 1 ligne »** : signale lorsque la transcription principale n’a qu’une + seule ligne (l’historique ne s’accumule pas). +- **Multiples répertoires d’état** : avertit lorsque plusieurs dossiers `~/.openclaw` existent entre + différents répertoires personnels ou lorsque `OPENCLAW_STATE_DIR` pointe ailleurs (l’historique peut + se répartir entre plusieurs installations). +- **Rappel mode distant** : si `gateway.mode=remote`, doctor rappelle de l’exécuter + sur l’hôte distant (l’état y réside). +- **Permissions du fichier de configuration** : avertit si `~/.openclaw/openclaw.json` est + lisible par le groupe/le monde et propose de le restreindre à `600`. ### 5) État de l’authentification des modèles (expiration OAuth) -Doctor inspecte les profils OAuth dans le magasin d’authentification, avertit lorsque les jetons sont -proches de l’expiration ou expirés, et peut les rafraîchir lorsque c’est sûr. Si le profil +Doctor inspecte les profils OAuth dans le magasin d’authentification, avertit lorsque les jetons +expirent ou ont expiré et peut les actualiser lorsque c’est sûr. Si le profil OAuth/jeton Anthropic est obsolète, il suggère une clé API Anthropic ou le -chemin de setup-token Anthropic. -Les invites de rafraîchissement n’apparaissent qu’en mode interactif (TTY) ; `--non-interactive` -ignore les tentatives de rafraîchissement. +chemin setup-token Anthropic. +Les invites d’actualisation n’apparaissent qu’en mode interactif (TTY) ; `--non-interactive` +ignore les tentatives d’actualisation. -Lorsqu’un rafraîchissement OAuth échoue de manière permanente (par exemple `refresh_token_reused`, -`invalid_grant`, ou lorsqu’un fournisseur vous indique de vous reconnecter), doctor signale +Lorsqu’une actualisation OAuth échoue de manière permanente (par exemple `refresh_token_reused`, +`invalid_grant`, ou lorsqu’un fournisseur vous dit de vous reconnecter), doctor signale qu’une réauthentification est requise et affiche la commande exacte `openclaw models auth login --provider ...` à exécuter. -Doctor signale aussi les profils d’authentification temporairement inutilisables à cause de : +Doctor signale aussi les profils d’authentification temporairement inutilisables à cause de : -- courts délais d’attente (limites de débit/timeouts/échecs d’authentification) +- courtes périodes de cooldown (limites de débit/timeouts/échecs d’authentification) - désactivations plus longues (échecs de facturation/crédit) ### 6) Validation du modèle Hooks Si `hooks.gmail.model` est défini, doctor valide la référence de modèle par rapport au -catalogue et à la liste d’autorisation et avertit lorsqu’elle ne se résout pas ou n’est pas autorisée. +catalogue et à la liste d’autorisation et avertit lorsqu’elle ne se résoudra pas ou n’est pas autorisée. ### 7) Réparation de l’image sandbox -Lorsque le sandboxing est activé, doctor vérifie les images Docker et propose de construire ou -de basculer vers d’anciens noms si l’image actuelle est absente. +Lorsque le sandboxing est activé, doctor vérifie les images Docker et propose de les construire ou +de basculer vers les noms hérités si l’image actuelle est manquante. ### 7b) Dépendances d’exécution des plugins intégrés Doctor vérifie que les dépendances d’exécution des plugins intégrés (par exemple les -packages d’exécution du plugin Discord) sont présentes dans la racine d’installation OpenClaw. -Si certaines sont manquantes, doctor signale les packages et les installe en -mode `openclaw doctor --fix` / `openclaw doctor --repair`. +packages d’exécution du plugin Discord) sont présentes à la racine d’installation d’OpenClaw. +S’il en manque, doctor signale les packages et les installe en mode +`openclaw doctor --fix` / `openclaw doctor --repair`. ### 8) Migrations des services Gateway et indications de nettoyage -Doctor détecte les anciens services Gateway (launchd/systemd/schtasks) et -propose de les supprimer puis d’installer le service OpenClaw avec le port de passerelle -actuel. Il peut aussi rechercher des services supplémentaires de type passerelle et afficher des indications de nettoyage. -Les services de passerelle OpenClaw nommés par profil sont considérés comme de première classe et ne sont pas -signalés comme « supplémentaires ». +Doctor détecte les services Gateway hérités (launchd/systemd/schtasks) et +propose de les supprimer et d’installer le service OpenClaw en utilisant le port Gateway +actuel. Il peut également analyser les services supplémentaires de type Gateway et afficher des indications de nettoyage. +Les services Gateway OpenClaw nommés par profil sont considérés comme de première classe et ne sont pas +signalés comme « supplémentaires ». ### 8b) Migration Matrix au démarrage Lorsqu’un compte de canal Matrix a une migration d’état héritée en attente ou exploitable, doctor (en mode `--fix` / `--repair`) crée un instantané avant migration puis -exécute les étapes de migration au mieux : migration de l’état Matrix hérité et préparation héritée -de l’état chiffré. Les deux étapes ne sont pas fatales ; les erreurs sont journalisées et -le démarrage se poursuit. En mode lecture seule (`openclaw doctor` sans `--fix`), cette vérification +exécute les étapes de migration en mode meilleur effort : migration de l’état Matrix hérité et préparation héritée +de l’état chiffré. Les deux étapes sont non fatales ; les erreurs sont journalisées et +le démarrage continue. En mode lecture seule (`openclaw doctor` sans `--fix`), cette vérification est entièrement ignorée. +### 8c) Dérive d’appairage d’appareil et d’authentification + +Doctor inspecte désormais l’état d’appairage des appareils dans le cadre du passage normal de vérification d’état. + +Ce qu’il signale : + +- premières demandes d’appairage en attente +- mises à niveau de rôle en attente pour des appareils déjà appairés +- mises à niveau de scope en attente pour des appareils déjà appairés +- réparations de discordance de clé publique lorsque l’ID d’appareil correspond toujours mais que l’identité + de l’appareil ne correspond plus à l’enregistrement approuvé +- enregistrements appairés sans jeton actif pour un rôle approuvé +- jetons appairés dont les scopes dérivent hors de la base de référence d’appairage approuvée +- entrées locales en cache de jeton d’appareil pour la machine actuelle qui sont antérieures à une + rotation de jeton côté Gateway ou portent des métadonnées de scope obsolètes + +Doctor n’approuve pas automatiquement les demandes d’appairage et ne fait pas non plus pivoter automatiquement les jetons d’appareil. Il +affiche à la place les étapes suivantes exactes : + +- inspecter les demandes en attente avec `openclaw devices list` +- approuver la demande exacte avec `openclaw devices approve ` +- faire pivoter un nouveau jeton avec `openclaw devices rotate --device --role ` +- supprimer et réapprouver un enregistrement obsolète avec `openclaw devices remove ` + +Cela ferme le cas courant « déjà appairé mais reçoit toujours pairing required » : +doctor distingue désormais le premier appairage des mises à niveau de rôle/scope +en attente et de la dérive d’identité d’appareil/jeton obsolète. + ### 9) Avertissements de sécurité Doctor émet des avertissements lorsqu’un fournisseur est ouvert aux DM sans liste d’autorisation, ou -lorsqu’une politique est configurée de manière dangereuse. +lorsqu’une politique est configurée d’une manière dangereuse. -### 10) Persistance systemd (Linux) +### 10) systemd linger (Linux) -En cas d’exécution comme service utilisateur systemd, doctor s’assure que la persistance est activée afin que la -passerelle reste active après la déconnexion. +En cas d’exécution comme service utilisateur systemd, doctor s’assure que le mode lingering est activé afin que la +Gateway reste active après la déconnexion. -### 11) État de l’espace de travail (Skills, plugins et répertoires hérités) +### 11) État du workspace (Skills, plugins et répertoires hérités) -Doctor affiche un résumé de l’état de l’espace de travail pour l’agent par défaut : +Doctor affiche un résumé de l’état du workspace pour l’agent par défaut : -- **État des Skills** : compte les Skills éligibles, à prérequis manquants et bloqués par la liste d’autorisation. -- **Répertoires d’espace de travail hérités** : avertit lorsque `~/openclaw` ou d’autres anciens répertoires d’espace de travail - existent à côté de l’espace de travail actuel. -- **État des plugins** : compte les plugins chargés/désactivés/en erreur ; liste les identifiants de plugin pour les - erreurs ; signale les capacités des plugins bundle. -- **Avertissements de compatibilité de plugins** : signale les plugins qui ont des problèmes de compatibilité avec +- **État des Skills** : compte les Skills éligibles, à exigences manquantes et bloquées par la liste d’autorisation. +- **Répertoires de workspace hérités** : avertit lorsque `~/openclaw` ou d’autres répertoires de workspace hérités + existent à côté du workspace actuel. +- **État des plugins** : compte les plugins chargés/désactivés/en erreur ; liste les ID des plugins pour les + erreurs ; signale les capacités des plugins intégrés. +- **Avertissements de compatibilité des plugins** : signale les plugins ayant des problèmes de compatibilité avec l’exécution actuelle. -- **Diagnostics des plugins** : met en avant tous les avertissements ou erreurs de chargement émis par le - registre des plugins. +- **Diagnostics des plugins** : expose les avertissements ou erreurs au chargement émis par le + registre de plugins. ### 11b) Taille du fichier bootstrap -Doctor vérifie si les fichiers bootstrap de l’espace de travail (par exemple `AGENTS.md`, -`CLAUDE.md` ou d’autres fichiers de contexte injectés) sont proches ou au-delà du budget -de caractères configuré. Il signale, fichier par fichier, le nombre brut de caractères vs. injectés, le pourcentage -de troncature, la cause de la troncature (`max/file` ou `max/total`) et le total des caractères injectés -en fraction du budget total. Lorsque des fichiers sont tronqués ou proches de la limite, doctor affiche des conseils pour ajuster `agents.defaults.bootstrapMaxChars` +Doctor vérifie si les fichiers bootstrap du workspace (par exemple `AGENTS.md`, +`CLAUDE.md` ou d’autres fichiers de contexte injectés) sont proches ou au-dessus du +budget de caractères configuré. Il signale, par fichier, le nombre brut de caractères par rapport au nombre injecté, le +pourcentage de troncature, la cause de la troncature (`max/file` ou `max/total`) et le total des +caractères injectés en fraction du budget total. Lorsque des fichiers sont tronqués ou proches +de la limite, doctor affiche des conseils pour ajuster `agents.defaults.bootstrapMaxChars` et `agents.defaults.bootstrapTotalMaxChars`. ### 11c) Complétion shell Doctor vérifie si la complétion par tabulation est installée pour le shell actuel -(zsh, bash, fish ou PowerShell) : +(zsh, bash, fish ou PowerShell) : -- Si le profil shell utilise un modèle de complétion dynamique lent - (`source <(openclaw completion ...)`), doctor le met à niveau vers la variante - plus rapide par fichier en cache. +- Si le profil shell utilise un modèle lent de complétion dynamique + (`source <(openclaw completion ...)`), doctor le met à niveau vers la + variante plus rapide avec fichier en cache. - Si la complétion est configurée dans le profil mais que le fichier de cache est manquant, doctor régénère automatiquement le cache. - Si aucune complétion n’est configurée, doctor propose de l’installer - (mode interactif uniquement ; ignoré avec `--non-interactive`). + (mode interactif uniquement ; ignoré avec `--non-interactive`). -Exécutez `openclaw completion --write-state` pour régénérer le cache manuellement. +Exécutez `openclaw completion --write-state` pour régénérer manuellement le cache. ### 12) Vérifications d’authentification Gateway (jeton local) -Doctor vérifie l’état de préparation de l’authentification par jeton de la passerelle locale. +Doctor vérifie la préparation de l’authentification par jeton de la Gateway locale. -- Si le mode jeton nécessite un jeton et qu’aucune source de jeton n’existe, doctor propose d’en générer un. -- Si `gateway.auth.token` est géré par `SecretRef` mais indisponible, doctor avertit et ne l’écrase pas avec du texte brut. -- `openclaw doctor --generate-gateway-token` force la génération uniquement lorsqu’aucun `SecretRef` de jeton n’est configuré. +- Si le mode jeton a besoin d’un jeton et qu’aucune source de jeton n’existe, doctor propose d’en générer un. +- Si `gateway.auth.token` est géré par SecretRef mais indisponible, doctor avertit et ne l’écrase pas avec du texte brut. +- `openclaw doctor --generate-gateway-token` force la génération uniquement lorsqu’aucun SecretRef de jeton n’est configuré. -### 12b) Réparations en lecture seule conscientes de SecretRef +### 12b) Réparations en lecture seule compatibles SecretRef -Certains flux de réparation doivent inspecter les identifiants configurés sans affaiblir le comportement fail-fast à l’exécution. +Certains flux de réparation doivent inspecter les identifiants configurés sans affaiblir le comportement d’échec rapide à l’exécution. -- `openclaw doctor --fix` utilise désormais le même modèle de résumé `SecretRef` en lecture seule que les commandes de la famille status pour les réparations ciblées de configuration. -- Exemple : la réparation Telegram `allowFrom` / `groupAllowFrom` avec `@username` essaie d’utiliser les identifiants du bot configurés lorsqu’ils sont disponibles. -- Si le jeton du bot Telegram est configuré via `SecretRef` mais indisponible dans le chemin de commande actuel, doctor signale que l’identifiant est configuré mais indisponible et ignore la résolution automatique au lieu de planter ou d’indiquer à tort que le jeton est manquant. +- `openclaw doctor --fix` utilise désormais le même modèle récapitulatif SecretRef en lecture seule que les commandes de la famille status pour les réparations ciblées de configuration. +- Exemple : la réparation Telegram `allowFrom` / `groupAllowFrom` `@username` essaie d’utiliser les identifiants du bot configurés lorsqu’ils sont disponibles. +- Si le jeton du bot Telegram est configuré via SecretRef mais indisponible dans le chemin de commande actuel, doctor signale que l’identifiant est configuré-mais-indisponible et ignore la résolution automatique au lieu de planter ou de signaler à tort que le jeton est manquant. ### 13) Vérification d’état Gateway + redémarrage -Doctor exécute une vérification d’état et propose de redémarrer la passerelle lorsqu’elle semble -défaillante. +Doctor exécute une vérification d’état et propose de redémarrer la Gateway lorsqu’elle semble +en mauvais état. ### 13b) Préparation de la recherche mémoire Doctor vérifie si le fournisseur d’embeddings configuré pour la recherche mémoire est prêt -pour l’agent par défaut. Le comportement dépend du backend et du fournisseur configurés : +pour l’agent par défaut. Le comportement dépend du backend et du fournisseur configurés : -- **Backend QMD** : vérifie si le binaire `qmd` est disponible et peut démarrer. - Sinon, affiche des indications de correction, y compris le package npm et une option de chemin binaire manuel. -- **Fournisseur local explicite** : vérifie la présence d’un fichier de modèle local ou d’une URL de modèle distante/téléchargeable reconnue. S’il manque, suggère de passer à un fournisseur distant. -- **Fournisseur distant explicite** (`openai`, `voyage`, etc.) : vérifie qu’une clé API est - présente dans l’environnement ou dans le magasin d’authentification. Affiche des indications de correction exploitables si elle manque. -- **Fournisseur automatique** : vérifie d’abord la disponibilité du modèle local, puis essaie chaque - fournisseur distant dans l’ordre de sélection automatique. +- **Backend QMD** : sonde si le binaire `qmd` est disponible et peut être démarré. + Sinon, affiche des conseils de correction, y compris le package npm et une option manuelle de chemin du binaire. +- **Fournisseur local explicite** : vérifie la présence d’un fichier de modèle local ou d’une URL de modèle distante/téléchargeable reconnue. Si absent, suggère de basculer vers un fournisseur distant. +- **Fournisseur distant explicite** (`openai`, `voyage`, etc.) : vérifie qu’une clé API est + présente dans l’environnement ou le magasin d’authentification. Affiche des indications de correction exploitables si elle est absente. +- **Fournisseur auto** : vérifie d’abord la disponibilité d’un modèle local, puis essaie chaque fournisseur distant dans l’ordre de sélection automatique. -Lorsqu’un résultat de sonde de passerelle est disponible (la passerelle était saine au moment de la -vérification), doctor le recoupe avec la configuration visible côté CLI et note +Lorsqu’un résultat de sonde Gateway est disponible (la Gateway était en bon état au moment de la +vérification), doctor le recoupe avec la configuration visible par la CLI et signale toute divergence. Utilisez `openclaw memory status --deep` pour vérifier la préparation des embeddings à l’exécution. -### 14) Avertissements sur l’état des canaux +### 14) Avertissements d’état des canaux -Si la passerelle est saine, doctor exécute une sonde d’état des canaux et signale +Si la Gateway est en bon état, doctor exécute une sonde d’état des canaux et signale les avertissements avec des corrections suggérées. -### 15) Audit de configuration du superviseur + réparation +### 15) Audit + réparation de la configuration du superviseur -Doctor vérifie la configuration de superviseur installée (launchd/systemd/schtasks) pour détecter -les valeurs par défaut manquantes ou obsolètes (par ex. dépendances systemd network-online et -délai de redémarrage). Lorsqu’il détecte une incohérence, il recommande une mise à jour et peut -réécrire le fichier service/tâche selon les valeurs par défaut actuelles. +Doctor vérifie la configuration installée du superviseur (launchd/systemd/schtasks) pour détecter +des valeurs par défaut manquantes ou obsolètes (par ex. dépendances systemd network-online et +délai de redémarrage). Lorsqu’il trouve une différence, il recommande une mise à jour et peut +réécrire le fichier de service/la tâche vers les valeurs par défaut actuelles. -Remarques : +Remarques : -- `openclaw doctor` demande une confirmation avant de réécrire la configuration du superviseur. +- `openclaw doctor` demande confirmation avant de réécrire la configuration du superviseur. - `openclaw doctor --yes` accepte les invites de réparation par défaut. -- `openclaw doctor --repair` applique les corrections recommandées sans invite. +- `openclaw doctor --repair` applique les corrections recommandées sans invites. - `openclaw doctor --repair --force` écrase les configurations de superviseur personnalisées. -- Si l’authentification par jeton exige un jeton et que `gateway.auth.token` est géré par `SecretRef`, la validation d’installation/réparation du service vérifie le `SecretRef` mais ne persiste pas les valeurs de jeton en texte brut résolues dans les métadonnées d’environnement du service superviseur. -- Si l’authentification par jeton exige un jeton et que le `SecretRef` de jeton configuré n’est pas résolu, doctor bloque le chemin d’installation/réparation avec des indications exploitables. -- Si `gateway.auth.token` et `gateway.auth.password` sont tous deux configurés et que `gateway.auth.mode` n’est pas défini, doctor bloque l’installation/réparation jusqu’à ce que le mode soit explicitement défini. -- Pour les unités user-systemd Linux, les vérifications d’écart de jeton de doctor incluent désormais à la fois les sources `Environment=` et `EnvironmentFile=` lors de la comparaison des métadonnées d’authentification du service. +- Si l’authentification par jeton exige un jeton et que `gateway.auth.token` est géré par SecretRef, la voie d’installation/réparation du service doctor valide le SecretRef mais ne persiste pas les valeurs résolues de jeton en texte brut dans les métadonnées d’environnement du service superviseur. +- Si l’authentification par jeton exige un jeton et que le SecretRef de jeton configuré n’est pas résolu, doctor bloque la voie d’installation/réparation avec des conseils exploitables. +- Si `gateway.auth.token` et `gateway.auth.password` sont tous deux configurés et que `gateway.auth.mode` n’est pas défini, doctor bloque l’installation/réparation jusqu’à ce que le mode soit défini explicitement. +- Pour les unités user-systemd Linux, les vérifications de dérive de jeton doctor incluent désormais à la fois les sources `Environment=` et `EnvironmentFile=` lors de la comparaison des métadonnées d’authentification du service. - Vous pouvez toujours forcer une réécriture complète via `openclaw gateway install --force`. -### 16) Diagnostics d’exécution Gateway + port +### 16) Diagnostics d’exécution Gateway + de port Doctor inspecte l’exécution du service (PID, dernier statut de sortie) et avertit lorsque le -service est installé mais n’est pas réellement en cours d’exécution. Il vérifie aussi les collisions de port -sur le port Gateway (par défaut `18789`) et signale les causes probables (passerelle déjà +service est installé mais n’est pas réellement en cours d’exécution. Il vérifie également les collisions de port +sur le port Gateway (par défaut `18789`) et signale les causes probables (Gateway déjà en cours d’exécution, tunnel SSH). ### 17) Bonnes pratiques d’exécution Gateway Doctor avertit lorsque le service Gateway s’exécute sur Bun ou sur un chemin Node géré par un gestionnaire de versions -(`nvm`, `fnm`, `volta`, `asdf`, etc.). Les canaux WhatsApp + Telegram requièrent Node, -et les chemins de gestionnaire de versions peuvent casser après des mises à niveau car le service ne -charge pas l’initialisation de votre shell. Doctor propose de migrer vers une installation Node système lorsqu’elle -est disponible (Homebrew/apt/choco). +(`nvm`, `fnm`, `volta`, `asdf`, etc.). Les canaux WhatsApp + Telegram nécessitent Node, +et les chemins de gestionnaire de versions peuvent se casser après les mises à niveau parce que le service ne +charge pas l’initialisation de votre shell. Doctor propose de migrer vers une installation système de Node lorsqu’elle est +disponible (Homebrew/apt/choco). ### 18) Écriture de la configuration + métadonnées de l’assistant -Doctor persiste toutes les modifications de configuration et marque les métadonnées de l’assistant pour enregistrer l’exécution +Doctor persiste toutes les modifications de configuration et appose des métadonnées de l’assistant pour enregistrer l’exécution de doctor. -### 19) Conseils pour l’espace de travail (sauvegarde + système mémoire) +### 19) Conseils pour le workspace (sauvegarde + système mémoire) -Doctor suggère un système de mémoire d’espace de travail lorsqu’il est absent et affiche un conseil de sauvegarde -si l’espace de travail n’est pas déjà sous git. +Doctor suggère un système mémoire du workspace lorsqu’il est absent et affiche un conseil de sauvegarde +si le workspace n’est pas déjà sous git. -Voir [/concepts/agent-workspace](/fr/concepts/agent-workspace) pour un guide complet sur la -structure de l’espace de travail et la sauvegarde git (GitHub ou GitLab privé recommandé). +Voir [/concepts/agent-workspace](/fr/concepts/agent-workspace) pour un guide complet de la +structure du workspace et de la sauvegarde git (GitHub ou GitLab privés recommandés). diff --git a/docs/fr/gateway/index.md b/docs/fr/gateway/index.md index 9e15c8f16..b23eba024 100644 --- a/docs/fr/gateway/index.md +++ b/docs/fr/gateway/index.md @@ -1,46 +1,46 @@ --- read_when: - - Exécution ou débogage du processus gateway + - Exécution ou débogage du processus Gateway summary: Runbook pour le service Gateway, son cycle de vie et ses opérations -title: Runbook Gateway +title: Runbook du Gateway x-i18n: - generated_at: "2026-04-07T06:50:17Z" + generated_at: "2026-04-20T07:05:23Z" model: gpt-5.4 provider: openai - source_hash: fd2c21036e88612861ef2195b8ff7205aca31386bb11558614ade8d1a54fdebd + source_hash: e1004cdd43b1db6794f3ca83da38dbdb231a1976329d9d6d851e2b02405278d8 source_path: gateway/index.md workflow: 15 --- -# Runbook Gateway +# Runbook du Gateway -Utilisez cette page pour le démarrage au jour 1 et les opérations au jour 2 du service Gateway. +Utilisez cette page pour le démarrage du premier jour et les opérations du deuxième jour du service Gateway. Diagnostics orientés symptômes avec des séquences de commandes exactes et des signatures de journaux. - Guide de configuration orienté tâches + référence de configuration complète. + Guide de configuration orienté tâches + référence complète de configuration. Contrat SecretRef, comportement des instantanés d’exécution, et opérations de migration/rechargement. - - Règles exactes de cible/chemin pour `secrets apply` et comportement des profils d’authentification en mode ref-only. + + Règles exactes des cibles/chemins de `secrets apply` et comportement des profils d’authentification en mode ref-only. ## Démarrage local en 5 minutes - + ```bash openclaw gateway --port 18789 -# debug/trace mirrored to stdio +# débogage/trace recopiés vers stdio openclaw gateway --port 18789 --verbose -# force-kill listener on selected port, then start +# force l’arrêt de l’écouteur sur le port sélectionné, puis démarre openclaw gateway --force ``` @@ -54,7 +54,7 @@ openclaw status openclaw logs --follow ``` -Référence saine : `Runtime: running` et `RPC probe: ok`. +Référence saine : `Runtime: running`, `Connectivity probe: ok`, et `Capability: ...` qui correspond à ce que vous attendez. Utilisez `openclaw gateway status --require-rpc` lorsque vous avez besoin d’une preuve RPC en portée lecture, et pas seulement d’une joignabilité. @@ -64,35 +64,35 @@ Référence saine : `Runtime: running` et `RPC probe: ok`. openclaw channels status --probe ``` -Avec une Gateway joignable, cette commande exécute des sondes de canal en direct par compte ainsi que des audits facultatifs. -Si la Gateway est inaccessible, la CLI revient à des résumés de canaux basés uniquement sur la configuration -au lieu d’une sortie de sonde en direct. +Avec un gateway joignable, cela exécute des sondes de canaux en direct par compte ainsi que des audits facultatifs. +Si le gateway est inaccessible, la CLI bascule vers des résumés de canaux basés uniquement sur la configuration +au lieu de la sortie des sondes en direct. -Le rechargement de configuration de la Gateway surveille le chemin du fichier de configuration actif (résolu à partir des valeurs par défaut du profil/de l’état, ou `OPENCLAW_CONFIG_PATH` s’il est défini). +Le rechargement de la configuration du Gateway surveille le chemin du fichier de configuration actif (résolu à partir des valeurs par défaut du profil/de l’état, ou de `OPENCLAW_CONFIG_PATH` lorsqu’il est défini). Le mode par défaut est `gateway.reload.mode="hybrid"`. Après le premier chargement réussi, le processus en cours d’exécution sert l’instantané de configuration actif en mémoire ; un rechargement réussi remplace cet instantané de manière atomique. ## Modèle d’exécution -- Un processus toujours actif pour le routage, le plan de contrôle et les connexions aux canaux. +- Un processus toujours actif pour le routage, le plan de contrôle et les connexions de canaux. - Un port multiplexé unique pour : - le contrôle/RPC WebSocket - les API HTTP, compatibles OpenAI (`/v1/models`, `/v1/embeddings`, `/v1/chat/completions`, `/v1/responses`, `/tools/invoke`) - - l’interface de contrôle et les hooks + - l’interface utilisateur de contrôle et les hooks - Mode de liaison par défaut : `loopback`. - L’authentification est requise par défaut. Les configurations à secret partagé utilisent `gateway.auth.token` / `gateway.auth.password` (ou `OPENCLAW_GATEWAY_TOKEN` / `OPENCLAW_GATEWAY_PASSWORD`), et les configurations - avec proxy inverse hors loopback peuvent utiliser `gateway.auth.mode: "trusted-proxy"`. + de proxy inverse non-loopback peuvent utiliser `gateway.auth.mode: "trusted-proxy"`. ## Endpoints compatibles OpenAI -La surface de compatibilité à plus fort impact d’OpenClaw est désormais : +La surface de compatibilité la plus utile d’OpenClaw est désormais : - `GET /v1/models` - `GET /v1/models/{id}` @@ -102,39 +102,39 @@ La surface de compatibilité à plus fort impact d’OpenClaw est désormais : Pourquoi cet ensemble est important : -- La plupart des intégrations Open WebUI, LobeChat et LibreChat sondent d’abord `/v1/models`. +- La plupart des intégrations Open WebUI, LobeChat et LibreChat interrogent d’abord `/v1/models`. - De nombreux pipelines RAG et de mémoire attendent `/v1/embeddings`. - Les clients natifs pour agents préfèrent de plus en plus `/v1/responses`. Note de planification : -- `/v1/models` est orienté agent en priorité : il renvoie `openclaw`, `openclaw/default` et `openclaw/`. +- `/v1/models` est orienté agent : il renvoie `openclaw`, `openclaw/default` et `openclaw/`. - `openclaw/default` est l’alias stable qui pointe toujours vers l’agent par défaut configuré. -- Utilisez `x-openclaw-model` lorsque vous souhaitez un remplacement du fournisseur/modèle backend ; sinon, le modèle normal et la configuration d’embeddings de l’agent sélectionné gardent le contrôle. +- Utilisez `x-openclaw-model` lorsque vous souhaitez un remplacement du fournisseur/modèle backend ; sinon, la configuration normale du modèle et des embeddings de l’agent sélectionné reste maîtresse. -Tous ces endpoints s’exécutent sur le port principal de la Gateway et utilisent la même frontière d’authentification d’opérateur de confiance que le reste de l’API HTTP Gateway. +Tous ceux-ci s’exécutent sur le port principal du Gateway et utilisent la même limite d’authentification d’opérateur de confiance que le reste de l’API HTTP du Gateway. ### Priorité du port et du mode de liaison -| Paramètre | Ordre de résolution | -| ------------ | ------------------------------------------------------------ | -| Port Gateway | `--port` → `OPENCLAW_GATEWAY_PORT` → `gateway.port` → `18789` | -| Mode de liaison | CLI/override → `gateway.bind` → `loopback` | +| Paramètre | Ordre de résolution | +| ------------- | -------------------------------------------------------------- | +| Port Gateway | `--port` → `OPENCLAW_GATEWAY_PORT` → `gateway.port` → `18789` | +| Mode de liaison | CLI/override → `gateway.bind` → `loopback` | ### Modes de rechargement à chaud -| `gateway.reload.mode` | Comportement | -| --------------------- | ---------------------------------------------- | -| `off` | Aucun rechargement de configuration | -| `hot` | Applique uniquement les modifications sûres à chaud | -| `restart` | Redémarre lors de modifications nécessitant un rechargement | -| `hybrid` (par défaut) | Applique à chaud quand c’est sûr, redémarre si nécessaire | +| `gateway.reload.mode` | Comportement | +| --------------------- | ---------------------------------------- | +| `off` | Aucun rechargement de configuration | +| `hot` | Applique uniquement les changements sûrs à chaud | +| `restart` | Redémarre sur les changements nécessitant un rechargement | +| `hybrid` (par défaut) | Applique à chaud quand c’est sûr, redémarre quand c’est nécessaire | -## Ensemble de commandes opérateur +## Jeu de commandes opérateur ```bash openclaw gateway status -openclaw gateway status --deep # adds a system-level service scan +openclaw gateway status --deep # ajoute une analyse du service au niveau système openclaw gateway status --json openclaw gateway install openclaw gateway restart @@ -144,15 +144,15 @@ openclaw logs --follow openclaw doctor ``` -`gateway status --deep` sert à la découverte supplémentaire de services (unités système -LaunchDaemons/systemd/schtasks), pas à une sonde de santé RPC plus approfondie. +`gateway status --deep` sert à une découverte de services supplémentaire (LaunchDaemons/unités systemd système +/schtasks), pas à une sonde d’état de santé RPC plus approfondie. -## Gateways multiples (même hôte) +## Plusieurs gateways (même hôte) -La plupart des installations doivent exécuter une gateway par machine. Une seule gateway peut héberger plusieurs +La plupart des installations doivent exécuter un gateway par machine. Un seul gateway peut héberger plusieurs agents et canaux. -Vous n’avez besoin de plusieurs gateways que si vous souhaitez délibérément une isolation ou un bot de secours. +Vous n’avez besoin de plusieurs gateways que si vous voulez délibérément de l’isolation ou un bot de secours. Vérifications utiles : @@ -165,15 +165,15 @@ Ce à quoi s’attendre : - `gateway status --deep` peut signaler `Other gateway-like services detected (best effort)` et afficher des conseils de nettoyage lorsque d’anciennes installations launchd/systemd/schtasks sont encore présentes. -- `gateway probe` peut avertir avec `multiple reachable gateways` lorsque plus d’une cible +- `gateway probe` peut avertir de `multiple reachable gateways` lorsque plus d’une cible répond. -- Si c’est intentionnel, isolez les ports, la configuration/l’état et les racines d’espace de travail par gateway. +- Si cela est intentionnel, isolez les ports, la configuration/l’état et les racines d’espace de travail pour chaque gateway. Configuration détaillée : [/gateway/multiple-gateways](/fr/gateway/multiple-gateways). -## Accès à distance +## Accès distant -Méthode préférée : Tailscale/VPN. +Préféré : Tailscale/VPN. Solution de repli : tunnel SSH. ```bash @@ -183,16 +183,16 @@ ssh -N -L 18789:127.0.0.1:18789 user@host Connectez ensuite les clients localement à `ws://127.0.0.1:18789`. -Les tunnels SSH ne contournent pas l’authentification de la gateway. Avec une authentification à secret partagé, les clients -doivent toujours envoyer `token`/`password`, même via le tunnel. Pour les modes avec identité, +Les tunnels SSH ne contournent pas l’authentification du gateway. Pour une authentification à secret partagé, les clients doivent toujours +envoyer `token`/`password` même via le tunnel. Pour les modes porteurs d’identité, la requête doit toujours satisfaire ce chemin d’authentification. -Voir : [Gateway distante](/fr/gateway/remote), [Authentification](/fr/gateway/authentication), [Tailscale](/fr/gateway/tailscale). +Voir : [Gateway distant](/fr/gateway/remote), [Authentification](/fr/gateway/authentication), [Tailscale](/fr/gateway/tailscale). ## Supervision et cycle de vie du service -Utilisez des exécutions supervisées pour une fiabilité proche de la production. +Utilisez des exécutions supervisées pour une fiabilité de niveau production. @@ -204,11 +204,11 @@ openclaw gateway restart openclaw gateway stop ``` -Les labels LaunchAgent sont `ai.openclaw.gateway` (par défaut) ou `ai.openclaw.` (profil nommé). `openclaw doctor` audite et répare la dérive de configuration du service. +Les libellés LaunchAgent sont `ai.openclaw.gateway` (par défaut) ou `ai.openclaw.` (profil nommé). `openclaw doctor` audite et répare les dérives de configuration du service. - + ```bash openclaw gateway install @@ -255,8 +255,8 @@ openclaw gateway stop ``` Le démarrage géré natif sous Windows utilise une tâche planifiée nommée `OpenClaw Gateway` -(ou `OpenClaw Gateway ()` pour les profils nommés). Si la création de tâche planifiée -est refusée, OpenClaw revient à un lanceur par utilisateur dans le dossier de démarrage +(ou `OpenClaw Gateway ()` pour les profils nommés). Si la création de la tâche planifiée +est refusée, OpenClaw revient à un lanceur par utilisateur dans le dossier Startup qui pointe vers `gateway.cmd` dans le répertoire d’état. @@ -277,10 +277,10 @@ Utilisez le même corps de service que pour l’unité utilisateur, mais install -## Gateways multiples sur un même hôte +## Plusieurs gateways sur un même hôte -La plupart des configurations doivent exécuter **une seule** Gateway. -N’en utilisez plusieurs que pour une isolation/redondance stricte (par exemple un profil de secours). +La plupart des configurations doivent exécuter **un** Gateway. +N’utilisez plusieurs gateways que pour une isolation/redondance stricte (par exemple un profil de secours). Liste de contrôle par instance : @@ -296,9 +296,9 @@ OPENCLAW_CONFIG_PATH=~/.openclaw/a.json OPENCLAW_STATE_DIR=~/.openclaw-a opencla OPENCLAW_CONFIG_PATH=~/.openclaw/b.json OPENCLAW_STATE_DIR=~/.openclaw-b openclaw gateway --port 19002 ``` -Voir : [Gateways multiples](/fr/gateway/multiple-gateways). +Voir : [Plusieurs gateways](/fr/gateway/multiple-gateways). -### Chemin rapide pour le profil de développement +### Chemin rapide du profil dev ```bash openclaw --dev setup @@ -306,23 +306,23 @@ openclaw --dev gateway --allow-unconfigured openclaw --dev status ``` -Les valeurs par défaut incluent un état/une configuration isolés et un port de base de gateway `19001`. +Les valeurs par défaut incluent un état/une configuration isolés et un port Gateway de base `19001`. ## Référence rapide du protocole (vue opérateur) -- La première trame client doit être `connect`. -- La Gateway renvoie un instantané `hello-ok` (`presence`, `health`, `stateVersion`, `uptimeMs`, limites/politique). -- `hello-ok.features.methods` / `events` est une liste de découverte prudente, et non - un dump généré de chaque route d’assistance appelable. +- La première trame cliente doit être `connect`. +- Le Gateway renvoie un instantané `hello-ok` (`presence`, `health`, `stateVersion`, `uptimeMs`, limits/policy). +- `hello-ok.features.methods` / `events` sont une liste de découverte prudente, et non + un dump généré de toutes les routes d’assistance appelables. - Requêtes : `req(method, params)` → `res(ok/payload|error)`. - Les événements courants incluent `connect.challenge`, `agent`, `chat`, `session.message`, `session.tool`, `sessions.changed`, `presence`, `tick`, - `health`, `heartbeat`, les événements du cycle de vie d’appairage/d’approbation, et `shutdown`. + `health`, `heartbeat`, les événements du cycle de vie d’appairage/approbation, et `shutdown`. -Les exécutions d’agent comportent deux étapes : +Les exécutions d’agent se déroulent en deux étapes : -1. Accusé de réception immédiat (`status:"accepted"`) -2. Réponse finale d’achèvement (`status:"ok"|"error"`), avec des événements `agent` diffusés entre les deux. +1. Accusé de réception immédiat accepté (`status:"accepted"`) +2. Réponse finale de fin (`status:"ok"|"error"`), avec des événements `agent` diffusés entre les deux. Voir la documentation complète du protocole : [Protocole Gateway](/fr/gateway/protocol). @@ -330,7 +330,7 @@ Voir la documentation complète du protocole : [Protocole Gateway](/fr/gateway/p ### Disponibilité -- Ouvrez une connexion WS et envoyez `connect`. +- Ouvrez un WS et envoyez `connect`. - Attendez une réponse `hello-ok` avec instantané. ### État de préparation @@ -341,30 +341,30 @@ openclaw channels status --probe openclaw health ``` -### Récupération après interruption +### Récupération après rupture -Les événements ne sont pas rejoués. En cas de trou dans la séquence, actualisez l’état (`health`, `system-presence`) avant de continuer. +Les événements ne sont pas rejoués. En cas de trou de séquence, actualisez l’état (`health`, `system-presence`) avant de continuer. ## Signatures d’échec courantes -| Signature | Problème probable | -| -------------------------------------------------------------- | --------------------------------------------------------------------------------- | -| `refusing to bind gateway ... without auth` | Liaison hors loopback sans chemin d’authentification gateway valide | -| `another gateway instance is already listening` / `EADDRINUSE` | Conflit de port | -| `Gateway start blocked: set gateway.mode=local` | Configuration définie en mode distant, ou estampille du mode local absente d’une configuration endommagée | -| `unauthorized` during connect | Incompatibilité d’authentification entre le client et la gateway | +| Signature | Problème probable | +| -------------------------------------------------------------- | -------------------------------------------------------------------------------- | +| `refusing to bind gateway ... without auth` | Liaison non-loopback sans chemin d’authentification gateway valide | +| `another gateway instance is already listening` / `EADDRINUSE` | Conflit de port | +| `Gateway start blocked: set gateway.mode=local` | Configuration définie en mode distant, ou tampon de mode local manquant dans une configuration endommagée | +| `unauthorized` during connect | Incompatibilité d’authentification entre le client et le gateway | -Pour les séquences complètes de diagnostic, utilisez [Dépannage Gateway](/fr/gateway/troubleshooting). +Pour des séquences complètes de diagnostic, utilisez [Dépannage Gateway](/fr/gateway/troubleshooting). ## Garanties de sécurité -- Les clients du protocole Gateway échouent rapidement lorsque la Gateway n’est pas disponible (pas de repli implicite vers un canal direct). -- Les premières trames invalides/non `connect` sont rejetées et la connexion est fermée. -- Un arrêt gracieux émet un événement `shutdown` avant la fermeture du socket. +- Les clients du protocole Gateway échouent rapidement lorsque le Gateway n’est pas disponible (pas de bascule implicite directe vers le canal). +- Les premières trames invalides/non-`connect` sont rejetées et la connexion est fermée. +- L’arrêt propre émet un événement `shutdown` avant la fermeture du socket. --- -Voir aussi : +Associé : - [Dépannage](/fr/gateway/troubleshooting) - [Processus en arrière-plan](/fr/gateway/background-process) diff --git a/docs/fr/gateway/troubleshooting.md b/docs/fr/gateway/troubleshooting.md index 517f5d08a..b2408f8fe 100644 --- a/docs/fr/gateway/troubleshooting.md +++ b/docs/fr/gateway/troubleshooting.md @@ -1,26 +1,26 @@ --- read_when: - Le centre de dépannage vous a orienté ici pour un diagnostic plus approfondi - - Vous avez besoin de sections de guide basées sur les symptômes, stables, avec des commandes exactes -summary: Guide de dépannage approfondi pour la gateway, les canaux, l’automatisation, les nœuds et le navigateur + - Vous avez besoin de sections de guide de dépannage stables, basées sur les symptômes, avec des commandes exactes +summary: Guide de dépannage approfondi pour Gateway, les canaux, l’automatisation, les Nodes et le navigateur title: Dépannage x-i18n: - generated_at: "2026-04-11T02:45:02Z" + generated_at: "2026-04-20T07:05:27Z" model: gpt-5.4 provider: openai - source_hash: 7ef2faccba26ede307861504043a6415bc1f12dc64407771106f63ddc5b107f5 + source_hash: d93a82407dbb1314b91a809ff9433114e1e9a3b56d46547ef53a8196bac06260 source_path: gateway/troubleshooting.md workflow: 15 --- -# Dépannage de la gateway +# Dépannage de Gateway -Cette page est le guide approfondi. +Cette page est le guide de dépannage approfondi. Commencez par [/help/troubleshooting](/fr/help/troubleshooting) si vous voulez d’abord le flux de triage rapide. ## Échelle de commandes -Exécutez-les d’abord, dans cet ordre : +Exécutez-les d’abord, dans cet ordre : ```bash openclaw status @@ -30,16 +30,15 @@ openclaw doctor openclaw channels status --probe ``` -Signaux attendus d’un état sain : +Signaux attendus lorsque tout fonctionne correctement : -- `openclaw gateway status` affiche `Runtime: running` et `RPC probe: ok`. +- `openclaw gateway status` affiche `Runtime: running`, `Connectivity probe: ok` et une ligne `Capability: ...`. - `openclaw doctor` ne signale aucun problème bloquant de configuration/service. -- `openclaw channels status --probe` affiche l’état de transport en direct par compte et, - lorsque c’est pris en charge, des résultats de sonde/audit tels que `works` ou `audit ok`. +- `openclaw channels status --probe` affiche l’état de transport en direct par compte et, lorsqu’ils sont pris en charge, les résultats de sonde/audit comme `works` ou `audit ok`. -## Anthropic 429 : usage supplémentaire requis pour un long contexte +## Anthropic 429 : usage supplémentaire requis pour le contexte long -Utilisez cette section lorsque les journaux/erreurs incluent : +Utilisez ceci lorsque les journaux/erreurs contiennent : `HTTP 429: rate_limit_error: Extra usage is required for long context requests`. ```bash @@ -48,19 +47,19 @@ openclaw models status openclaw config get agents.defaults.models ``` -Recherchez : +À rechercher : - Le modèle Anthropic Opus/Sonnet sélectionné a `params.context1m: true`. -- L’identifiant Anthropic actuel n’est pas éligible à l’usage en long contexte. -- Les requêtes échouent uniquement sur les longues sessions/exécutions de modèle qui nécessitent la voie bêta 1M. +- Les identifiants Anthropic actuels ne sont pas éligibles à l’usage du contexte long. +- Les requêtes échouent uniquement sur les longues sessions/exécutions de modèle qui nécessitent le chemin bêta 1M. -Options de correction : +Options de correction : 1. Désactivez `context1m` pour ce modèle afin de revenir à la fenêtre de contexte normale. -2. Utilisez un identifiant Anthropic éligible aux requêtes en long contexte, ou passez à une clé API Anthropic. -3. Configurez des modèles de secours afin que les exécutions continuent lorsque les requêtes Anthropic en long contexte sont rejetées. +2. Utilisez des identifiants Anthropic éligibles aux requêtes à contexte long, ou passez à une clé API Anthropic. +3. Configurez des modèles de secours afin que les exécutions continuent lorsque les requêtes Anthropic à contexte long sont rejetées. -Voir aussi : +Voir aussi : - [/providers/anthropic](/fr/providers/anthropic) - [/reference/token-use](/fr/reference/token-use) @@ -68,11 +67,11 @@ Voir aussi : ## Un backend local compatible OpenAI réussit les sondes directes, mais les exécutions d’agent échouent -Utilisez cette section lorsque : +Utilisez ceci lorsque : - `curl ... /v1/models` fonctionne -- de petits appels directs à `/v1/chat/completions` fonctionnent -- les exécutions de modèle OpenClaw échouent uniquement sur des tours d’agent normaux +- les petits appels directs à `/v1/chat/completions` fonctionnent +- les exécutions de modèles OpenClaw échouent uniquement lors des tours d’agent normaux ```bash curl http://127.0.0.1:1234/v1/models @@ -83,32 +82,26 @@ openclaw infer model run --model --prompt "hi" --json openclaw logs --follow ``` -Recherchez : +À rechercher : -- les petits appels directs réussissent, mais les exécutions OpenClaw échouent uniquement avec des prompts plus volumineux +- les petits appels directs réussissent, mais les exécutions OpenClaw échouent uniquement sur des prompts plus volumineux - des erreurs du backend indiquant que `messages[].content` attend une chaîne -- des plantages du backend qui n’apparaissent qu’avec un plus grand nombre de jetons de prompt ou avec les prompts complets du runtime d’agent +- des plantages du backend qui n’apparaissent qu’avec des nombres de tokens de prompt plus élevés ou avec les prompts complets du runtime d’agent -Signatures courantes : +Signatures courantes : -- `messages[...].content: invalid type: sequence, expected a string` → le backend - rejette des parties de contenu structurées de Chat Completions. Correctif : définissez - `models.providers..models[].compat.requiresStringContent: true`. -- les petites requêtes directes réussissent, mais les exécutions d’agent OpenClaw échouent avec des plantages de backend/modèle - (par exemple Gemma sur certaines versions de `inferrs`) → le transport OpenClaw est - probablement déjà correct ; le backend échoue sur la forme plus volumineuse du prompt du runtime d’agent. -- les échecs diminuent après avoir désactivé les outils mais ne disparaissent pas → les schémas d’outils faisaient - partie de la pression, mais le problème restant relève toujours de la capacité du modèle/serveur en amont ou d’un bug backend. +- `messages[...].content: invalid type: sequence, expected a string` → le backend rejette les parties de contenu structurées de Chat Completions. Correctif : définissez `models.providers..models[].compat.requiresStringContent: true`. +- les petites requêtes directes réussissent, mais les exécutions d’agent OpenClaw échouent avec des plantages du backend/modèle (par exemple Gemma sur certaines versions de `inferrs`) → le transport OpenClaw est probablement déjà correct ; c’est le backend qui échoue sur la forme plus volumineuse des prompts du runtime d’agent. +- les échecs diminuent après la désactivation des outils, mais ne disparaissent pas → les schémas d’outils faisaient partie de la pression, mais le problème restant vient toujours en amont de la capacité du modèle/serveur ou d’un bogue du backend. -Options de correction : +Options de correction : 1. Définissez `compat.requiresStringContent: true` pour les backends Chat Completions qui n’acceptent que des chaînes. -2. Définissez `compat.supportsTools: false` pour les modèles/backends qui ne peuvent pas gérer - de manière fiable la surface de schéma d’outils d’OpenClaw. -3. Réduisez la pression sur le prompt lorsque c’est possible : bootstrap d’espace de travail plus petit, historique de session plus court, modèle local plus léger, ou backend avec un meilleur support du long contexte. -4. Si les petites requêtes directes continuent de réussir alors que les tours d’agent OpenClaw plantent toujours dans le backend, traitez cela comme une limitation du serveur/modèle en amont et ouvrez-y un rapport avec une reproduction incluant la forme de payload acceptée. +2. Définissez `compat.supportsTools: false` pour les modèles/backends qui ne peuvent pas gérer de manière fiable la surface de schéma d’outils d’OpenClaw. +3. Réduisez la pression sur les prompts lorsque c’est possible : initialisation d’espace de travail plus petite, historique de session plus court, modèle local plus léger ou backend avec une meilleure prise en charge du contexte long. +4. Si les petites requêtes directes continuent de réussir alors que les tours d’agent OpenClaw plantent toujours dans le backend, traitez cela comme une limitation du serveur/modèle en amont et signalez-y un cas de reproduction avec la forme de payload acceptée. -Voir aussi : +Voir aussi : - [/gateway/local-models](/fr/gateway/local-models) - [/gateway/configuration](/fr/gateway/configuration) @@ -116,7 +109,7 @@ Voir aussi : ## Aucune réponse -Si les canaux sont actifs mais que rien ne répond, vérifiez le routage et la politique avant de reconnecter quoi que ce soit. +Si les canaux sont actifs mais que rien ne répond, vérifiez le routage et la stratégie avant de reconnecter quoi que ce soit. ```bash openclaw status @@ -126,27 +119,27 @@ openclaw config get channels openclaw logs --follow ``` -Recherchez : +À rechercher : -- Appairage en attente pour les expéditeurs de messages privés. +- Appairage en attente pour les expéditeurs de messages directs. - Contrôle des mentions de groupe (`requireMention`, `mentionPatterns`). - Incohérences de liste d’autorisation de canal/groupe. -Signatures courantes : +Signatures courantes : - `drop guild message (mention required` → message de groupe ignoré jusqu’à mention. - `pairing request` → l’expéditeur a besoin d’une approbation. -- `blocked` / `allowlist` → expéditeur/canal filtré par la politique. +- `blocked` / `allowlist` → l’expéditeur/canal a été filtré par la stratégie. -Voir aussi : +Voir aussi : - [/channels/troubleshooting](/fr/channels/troubleshooting) - [/channels/pairing](/fr/channels/pairing) - [/channels/groups](/fr/channels/groups) -## Connectivité de l’interface de contrôle du tableau de bord +## Connectivité de l’interface Dashboard / Control UI -Lorsque le tableau de bord/l’interface de contrôle ne se connecte pas, validez l’URL, le mode d’authentification et les hypothèses de contexte sécurisé. +Lorsque le tableau de bord / la Control UI ne se connecte pas, validez l’URL, le mode d’authentification et les hypothèses de contexte sécurisé. ```bash openclaw gateway status @@ -156,49 +149,38 @@ openclaw doctor openclaw gateway status --json ``` -Recherchez : +À rechercher : -- URL de sonde et URL du tableau de bord correctes. -- Incohérence de mode d’authentification/jeton entre le client et la gateway. +- URL de sonde et URL de tableau de bord correctes. +- Incohérence de mode d’authentification / jeton entre le client et Gateway. - Utilisation de HTTP là où une identité d’appareil est requise. -Signatures courantes : +Signatures courantes : - `device identity required` → contexte non sécurisé ou authentification d’appareil manquante. -- `origin not allowed` → l’`Origin` du navigateur n’est pas dans `gateway.controlUi.allowedOrigins` - (ou vous vous connectez depuis une origine de navigateur non-loopback sans - liste d’autorisation explicite). -- `device nonce required` / `device nonce mismatch` → le client n’achève pas le - flux d’authentification d’appareil basé sur challenge (`connect.challenge` + `device.nonce`). -- `device signature invalid` / `device signature expired` → le client a signé le mauvais - payload (ou un horodatage périmé) pour le handshake actuel. -- `AUTH_TOKEN_MISMATCH` avec `canRetryWithDeviceToken=true` → le client peut faire une nouvelle tentative de confiance avec un jeton d’appareil en cache. -- Cette nouvelle tentative avec jeton en cache réutilise l’ensemble de portées en cache stocké avec le - jeton d’appareil appairé. Les appelants avec `deviceToken` explicite / `scopes` explicites conservent leur - ensemble de portées demandé. -- En dehors de cette voie de nouvelle tentative, la priorité d’authentification à la connexion est d’abord - le jeton/mot de passe partagé explicite, puis le `deviceToken` explicite, puis le jeton d’appareil stocké, - puis le jeton de bootstrap. -- Sur la voie asynchrone Tailscale Serve Control UI, les tentatives échouées pour le même - `{scope, ip}` sont sérialisées avant que le limiteur n’enregistre l’échec. Deux mauvaises nouvelles tentatives concurrentes depuis le même client peuvent donc faire apparaître `retry later` - à la deuxième tentative au lieu de deux simples incohérences. -- `too many failed authentication attempts (retry later)` depuis un client loopback d’origine navigateur - → les échecs répétés depuis cette même `Origin` normalisée sont temporairement bloqués ; une autre origine localhost utilise un compartiment distinct. -- `unauthorized` répété après cette nouvelle tentative → dérive du jeton partagé/du jeton d’appareil ; actualisez la configuration du jeton et réapprouvez/faites tourner le jeton d’appareil si nécessaire. -- `gateway connect failed:` → cible hôte/port/url incorrecte. +- `origin not allowed` → l’`Origin` du navigateur n’est pas dans `gateway.controlUi.allowedOrigins` (ou vous vous connectez depuis une origine de navigateur non loopback sans liste d’autorisation explicite). +- `device nonce required` / `device nonce mismatch` → le client ne termine pas le flux d’authentification d’appareil basé sur défi (`connect.challenge` + `device.nonce`). +- `device signature invalid` / `device signature expired` → le client a signé le mauvais payload (ou un horodatage périmé) pour la poignée de main en cours. +- `AUTH_TOKEN_MISMATCH` avec `canRetryWithDeviceToken=true` → le client peut effectuer une nouvelle tentative approuvée avec le jeton d’appareil mis en cache. +- Cette nouvelle tentative avec jeton en cache réutilise l’ensemble de portées mis en cache stocké avec le jeton d’appareil appairé. Les appelants avec `deviceToken` explicite / `scopes` explicites conservent à la place l’ensemble de portées demandé. +- En dehors de ce chemin de nouvelle tentative, la priorité d’authentification de connexion est d’abord le jeton/mot de passe partagé explicite, puis le `deviceToken` explicite, puis le jeton d’appareil stocké, puis le jeton d’amorçage. +- Sur le chemin asynchrone de la Control UI via Tailscale Serve, les tentatives échouées pour le même `{scope, ip}` sont sérialisées avant que le limiteur n’enregistre l’échec. Deux mauvaises nouvelles tentatives concurrentes provenant du même client peuvent donc faire apparaître `retry later` lors de la seconde tentative au lieu de deux simples incohérences. +- `too many failed authentication attempts (retry later)` depuis un client loopback d’origine navigateur → les échecs répétés depuis cette même `Origin` normalisée sont temporairement bloqués ; une autre origine localhost utilise un compartiment séparé. +- `unauthorized` répété après cette nouvelle tentative → dérive du jeton partagé/du jeton d’appareil ; actualisez la configuration du jeton et réapprouvez/faites tourner le jeton d’appareil si nécessaire. +- `gateway connect failed:` → mauvaise cible d’hôte/port/URL. -### Carte rapide des codes de détail d’authentification +### Résumé rapide des codes de détail d’authentification -Utilisez `error.details.code` de la réponse `connect` échouée pour choisir l’action suivante : +Utilisez `error.details.code` dans la réponse `connect` échouée pour choisir l’action suivante : -| Code de détail | Signification | Action recommandée | -| ---------------------------- | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| `AUTH_TOKEN_MISSING` | Le client n’a pas envoyé un jeton partagé requis. | Collez/définissez le jeton dans le client et réessayez. Pour les chemins du tableau de bord : `openclaw config get gateway.auth.token` puis collez-le dans les paramètres de l’interface de contrôle. | -| `AUTH_TOKEN_MISMATCH` | Le jeton partagé ne correspond pas au jeton d’authentification de la gateway. | Si `canRetryWithDeviceToken=true`, autorisez une nouvelle tentative de confiance. Les nouvelles tentatives avec jeton en cache réutilisent les portées approuvées stockées ; les appelants avec `deviceToken` / `scopes` explicites conservent les portées demandées. Si cela échoue encore, exécutez la [checklist de récupération après dérive de jeton](/cli/devices#token-drift-recovery-checklist). | -| `AUTH_DEVICE_TOKEN_MISMATCH` | Le jeton par appareil en cache est périmé ou révoqué. | Faites tourner/réapprouvez le jeton d’appareil via le [CLI devices](/cli/devices), puis reconnectez-vous. | -| `PAIRING_REQUIRED` | L’identité de l’appareil est connue mais non approuvée pour ce rôle. | Approuvez la demande en attente : `openclaw devices list` puis `openclaw devices approve `. | +| Code de détail | Signification | Action recommandée | +| ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `AUTH_TOKEN_MISSING` | Le client n’a pas envoyé un jeton partagé requis. | Collez/définissez le jeton dans le client et réessayez. Pour les chemins du tableau de bord : `openclaw config get gateway.auth.token` puis collez-le dans les paramètres de la Control UI. | +| `AUTH_TOKEN_MISMATCH` | Le jeton partagé ne correspond pas au jeton d’authentification de Gateway. | Si `canRetryWithDeviceToken=true`, autorisez une nouvelle tentative approuvée. Les nouvelles tentatives avec jeton en cache réutilisent les portées approuvées stockées ; les appelants avec `deviceToken` / `scopes` explicites conservent les portées demandées. Si l’échec persiste, exécutez la [check-list de récupération de dérive de jeton](/cli/devices#token-drift-recovery-checklist). | +| `AUTH_DEVICE_TOKEN_MISMATCH` | Le jeton par appareil en cache est périmé ou révoqué. | Faites tourner/réapprouvez le jeton d’appareil à l’aide de la [CLI des appareils](/cli/devices), puis reconnectez-vous. | +| `PAIRING_REQUIRED` | L’identité de l’appareil doit être approuvée. Vérifiez `error.details.reason` pour `not-paired`, `scope-upgrade`, `role-upgrade` ou `metadata-upgrade`, et utilisez `requestId` / `remediationHint` lorsqu’ils sont présents. | Approuvez la demande en attente : `openclaw devices list` puis `openclaw devices approve `. Les mises à niveau de portée/rôle utilisent le même flux après examen de l’accès demandé. | -Vérification de migration vers l’authentification d’appareil v2 : +Vérification de migration vers l’authentification d’appareil v2 : ```bash openclaw --version @@ -206,63 +188,61 @@ openclaw doctor openclaw gateway status ``` -Si les journaux affichent des erreurs de nonce/signature, mettez à jour le client qui se connecte et vérifiez qu’il : +Si les journaux affichent des erreurs de nonce/signature, mettez à jour le client qui se connecte et vérifiez qu’il : 1. attend `connect.challenge` -2. signe le payload lié au challenge -3. envoie `connect.params.device.nonce` avec le même nonce de challenge +2. signe le payload lié au défi +3. envoie `connect.params.device.nonce` avec le même nonce du défi -Si `openclaw devices rotate` / `revoke` / `remove` est refusé de manière inattendue : +Si `openclaw devices rotate` / `revoke` / `remove` est refusé de manière inattendue : -- les sessions à jeton d’appareil appairé peuvent gérer uniquement **leur propre** - appareil, sauf si l’appelant a aussi `operator.admin` -- `openclaw devices rotate --scope ...` ne peut demander que des portées opérateur que - la session appelante détient déjà +- les sessions avec jeton d’appareil appairé ne peuvent gérer que **leur propre** appareil, sauf si l’appelant possède aussi `operator.admin` +- `openclaw devices rotate --scope ...` ne peut demander que des portées opérateur que la session appelante détient déjà -Voir aussi : +Voir aussi : - [/web/control-ui](/web/control-ui) -- [/gateway/configuration](/fr/gateway/configuration) (modes d’authentification de la gateway) +- [/gateway/configuration](/fr/gateway/configuration) (modes d’authentification de Gateway) - [/gateway/trusted-proxy-auth](/fr/gateway/trusted-proxy-auth) - [/gateway/remote](/fr/gateway/remote) - [/cli/devices](/cli/devices) -## Le service gateway n’est pas en cours d’exécution +## Le service Gateway ne s’exécute pas -Utilisez cette section lorsque le service est installé mais que le processus ne reste pas actif. +Utilisez ceci lorsque le service est installé mais que le processus ne reste pas actif. ```bash openclaw gateway status openclaw status openclaw logs --follow openclaw doctor -openclaw gateway status --deep # analyse aussi les services au niveau système +openclaw gateway status --deep # also scan system-level services ``` -Recherchez : +À rechercher : -- `Runtime: stopped` avec indices de sortie. -- Incohérence de configuration de service (`Config (cli)` vs `Config (service)`). +- `Runtime: stopped` avec des indications de sortie. +- Incohérence de configuration du service (`Config (cli)` vs `Config (service)`). - Conflits de port/écoute. - Installations launchd/systemd/schtasks supplémentaires lorsque `--deep` est utilisé. -- Indices de nettoyage `Other gateway-like services detected (best effort)`. +- Indications de nettoyage `Other gateway-like services detected (best effort)`. -Signatures courantes : +Signatures courantes : -- `Gateway start blocked: set gateway.mode=local` ou `existing config is missing gateway.mode` → le mode gateway local n’est pas activé, ou le fichier de configuration a été écrasé et a perdu `gateway.mode`. Correctif : définissez `gateway.mode="local"` dans votre configuration, ou relancez `openclaw onboard --mode local` / `openclaw setup` pour réappliquer la configuration attendue du mode local. Si vous exécutez OpenClaw via Podman, le chemin de configuration par défaut est `~/.openclaw/openclaw.json`. -- `refusing to bind gateway ... without auth` → liaison non-loopback sans chemin d’authentification gateway valide (jeton/mot de passe, ou trusted-proxy lorsque configuré). +- `Gateway start blocked: set gateway.mode=local` ou `existing config is missing gateway.mode` → le mode Gateway local n’est pas activé, ou le fichier de configuration a été écrasé et a perdu `gateway.mode`. Correctif : définissez `gateway.mode="local"` dans votre configuration, ou relancez `openclaw onboard --mode local` / `openclaw setup` pour réappliquer la configuration attendue du mode local. Si vous exécutez OpenClaw via Podman, le chemin de configuration par défaut est `~/.openclaw/openclaw.json`. +- `refusing to bind gateway ... without auth` → liaison non loopback sans chemin d’authentification Gateway valide (jeton/mot de passe, ou trusted-proxy lorsque configuré). - `another gateway instance is already listening` / `EADDRINUSE` → conflit de port. -- `Other gateway-like services detected (best effort)` → il existe des unités launchd/systemd/schtasks obsolètes ou parallèles. La plupart des configurations doivent conserver une seule gateway par machine ; si vous en avez réellement besoin de plusieurs, isolez les ports + la configuration/l’état/l’espace de travail. Voir [/gateway#multiple-gateways-same-host](/fr/gateway#multiple-gateways-same-host). +- `Other gateway-like services detected (best effort)` → des unités launchd/systemd/schtasks obsolètes ou parallèles existent. La plupart des installations devraient conserver une seule Gateway par machine ; si vous en avez vraiment besoin de plusieurs, isolez les ports + la configuration/l’état/l’espace de travail. Voir [/gateway#multiple-gateways-same-host](/fr/gateway#multiple-gateways-same-host). -Voir aussi : +Voir aussi : - [/gateway/background-process](/fr/gateway/background-process) - [/gateway/configuration](/fr/gateway/configuration) - [/gateway/doctor](/fr/gateway/doctor) -## Avertissements de sonde de la gateway +## Avertissements de sonde Gateway -Utilisez cette section lorsque `openclaw gateway probe` atteint bien quelque chose, mais affiche quand même un bloc d’avertissement. +Utilisez ceci lorsque `openclaw gateway probe` atteint bien quelque chose, mais affiche quand même un bloc d’avertissement. ```bash openclaw gateway probe @@ -270,27 +250,28 @@ openclaw gateway probe --json openclaw gateway probe --ssh user@gateway-host ``` -Recherchez : +À rechercher : - `warnings[].code` et `primaryTargetId` dans la sortie JSON. -- Si l’avertissement concerne le fallback SSH, plusieurs gateways, des portées manquantes, ou des références d’authentification non résolues. +- Si l’avertissement concerne le repli SSH, plusieurs Gateways, des portées manquantes ou des références d’authentification non résolues. -Signatures courantes : +Signatures courantes : -- `SSH tunnel failed to start; falling back to direct probes.` → la configuration SSH a échoué, mais la commande a quand même essayé les cibles directes configurées/en loopback. -- `multiple reachable gateways detected` → plus d’une cible a répondu. En général, cela indique une configuration multi-gateway intentionnelle ou des écouteurs obsolètes/dupliqués. -- `Probe diagnostics are limited by gateway scopes (missing operator.read)` → la connexion a réussi, mais le RPC détaillé est limité par les portées ; appairez une identité d’appareil ou utilisez des identifiants avec `operator.read`. -- texte d’avertissement de SecretRef non résolu pour `gateway.auth.*` / `gateway.remote.*` → le matériel d’authentification n’était pas disponible dans ce chemin de commande pour la cible en échec. +- `SSH tunnel failed to start; falling back to direct probes.` → la configuration SSH a échoué, mais la commande a quand même essayé les cibles directes configurées/loopback. +- `multiple reachable gateways detected` → plus d’une cible a répondu. En général, cela signifie une configuration multi-Gateway intentionnelle ou des écouteurs obsolètes/dupliqués. +- `Read-probe diagnostics are limited by gateway scopes (missing operator.read)` → la connexion a fonctionné, mais le RPC détaillé est limité par les portées ; appairez l’identité de l’appareil ou utilisez des identifiants avec `operator.read`. +- `Capability: pairing-pending` ou `gateway closed (1008): pairing required` → la Gateway a répondu, mais ce client a encore besoin d’un appairage/d’une approbation avant un accès opérateur normal. +- texte d’avertissement `gateway.auth.*` / `gateway.remote.*` SecretRef non résolu → le matériel d’authentification n’était pas disponible dans ce chemin de commande pour la cible en échec. -Voir aussi : +Voir aussi : - [/cli/gateway](/cli/gateway) - [/gateway#multiple-gateways-same-host](/fr/gateway#multiple-gateways-same-host) - [/gateway/remote](/fr/gateway/remote) -## Canal connecté mais messages qui ne circulent pas +## Canal connecté mais messages non transmis -Si l’état du canal est connecté mais que le flux de messages est interrompu, concentrez-vous sur la politique, les autorisations et les règles de livraison spécifiques au canal. +Si l’état du canal est connecté mais que le flux de messages est interrompu, concentrez-vous sur la stratégie, les autorisations et les règles de livraison propres au canal. ```bash openclaw channels status --probe @@ -300,28 +281,28 @@ openclaw logs --follow openclaw config get channels ``` -Recherchez : +À rechercher : -- Politique DM (`pairing`, `allowlist`, `open`, `disabled`). -- Liste d’autorisation de groupe et exigences de mention. -- Permissions/portées API du canal manquantes. +- Stratégie de message direct (`pairing`, `allowlist`, `open`, `disabled`). +- Liste d’autorisation des groupes et exigences de mention. +- Autorisations/portées API du canal manquantes. -Signatures courantes : +Signatures courantes : -- `mention required` → message ignoré par la politique de mention de groupe. -- traces `pairing` / d’approbation en attente → l’expéditeur n’est pas approuvé. +- `mention required` → message ignoré par la stratégie de mention de groupe. +- traces `pairing` / approbation en attente → l’expéditeur n’est pas approuvé. - `missing_scope`, `not_in_channel`, `Forbidden`, `401/403` → problème d’authentification/autorisations du canal. -Voir aussi : +Voir aussi : - [/channels/troubleshooting](/fr/channels/troubleshooting) - [/channels/whatsapp](/fr/channels/whatsapp) - [/channels/telegram](/fr/channels/telegram) - [/channels/discord](/fr/channels/discord) -## Livraison cron et heartbeat +## Livraison Cron et Heartbeat -Si cron ou heartbeat ne s’est pas exécuté ou n’a pas été livré, vérifiez d’abord l’état du planificateur, puis la cible de livraison. +Si Cron ou Heartbeat ne s’est pas exécuté ou n’a pas été livré, vérifiez d’abord l’état du planificateur, puis la cible de livraison. ```bash openclaw cron status @@ -331,31 +312,31 @@ openclaw system heartbeat last openclaw logs --follow ``` -Recherchez : +À rechercher : -- Cron activé et prochaine activation présente. -- État de l’historique d’exécution des jobs (`ok`, `skipped`, `error`). -- Raisons de saut de heartbeat (`quiet-hours`, `requests-in-flight`, `alerts-disabled`, `empty-heartbeat-file`, `no-tasks-due`). +- Cron activé et prochain réveil présent. +- État de l’historique des exécutions de tâche (`ok`, `skipped`, `error`). +- Raisons d’omission de Heartbeat (`quiet-hours`, `requests-in-flight`, `alerts-disabled`, `empty-heartbeat-file`, `no-tasks-due`). -Signatures courantes : +Signatures courantes : -- `cron: scheduler disabled; jobs will not run automatically` → cron désactivé. -- `cron: timer tick failed` → l’impulsion du planificateur a échoué ; vérifiez les erreurs de fichiers/journaux/runtime. -- `heartbeat skipped` avec `reason=quiet-hours` → hors de la fenêtre d’heures actives. -- `heartbeat skipped` avec `reason=empty-heartbeat-file` → `HEARTBEAT.md` existe mais ne contient que des lignes vides / en-têtes markdown, donc OpenClaw ignore l’appel au modèle. +- `cron: scheduler disabled; jobs will not run automatically` → Cron est désactivé. +- `cron: timer tick failed` → l’impulsion du planificateur a échoué ; vérifiez les erreurs de fichier/journal/runtime. +- `heartbeat skipped` avec `reason=quiet-hours` → en dehors de la plage d’heures actives. +- `heartbeat skipped` avec `reason=empty-heartbeat-file` → `HEARTBEAT.md` existe mais ne contient que des lignes vides / en-têtes Markdown ; OpenClaw ignore donc l’appel du modèle. - `heartbeat skipped` avec `reason=no-tasks-due` → `HEARTBEAT.md` contient un bloc `tasks:`, mais aucune tâche n’est due à cette impulsion. -- `heartbeat: unknown accountId` → id de compte invalide pour la cible de livraison heartbeat. -- `heartbeat skipped` avec `reason=dm-blocked` → la cible heartbeat a été résolue en destination de type DM alors que `agents.defaults.heartbeat.directPolicy` (ou la surcharge par agent) est défini sur `block`. +- `heartbeat: unknown accountId` → identifiant de compte invalide pour la cible de livraison de Heartbeat. +- `heartbeat skipped` avec `reason=dm-blocked` → la cible de Heartbeat a été résolue vers une destination de type message direct alors que `agents.defaults.heartbeat.directPolicy` (ou une surcharge par agent) est défini sur `block`. -Voir aussi : +Voir aussi : - [/automation/cron-jobs#troubleshooting](/fr/automation/cron-jobs#troubleshooting) - [/automation/cron-jobs](/fr/automation/cron-jobs) - [/gateway/heartbeat](/fr/gateway/heartbeat) -## Échec d’un outil de nœud appairé +## Échec d’un outil Node appairé -Si un nœud est appairé mais que les outils échouent, isolez l’état de premier plan, les permissions et l’état d’approbation. +Si un Node est appairé mais que les outils échouent, isolez l’état de premier plan, les autorisations et l’état d’approbation. ```bash openclaw nodes status @@ -365,20 +346,20 @@ openclaw logs --follow openclaw status ``` -Recherchez : +À rechercher : -- Nœud en ligne avec les capacités attendues. -- Autorisations système accordées pour caméra/micro/localisation/écran. +- Node en ligne avec les capacités attendues. +- Autorisations du système d’exploitation pour la caméra/le micro/la localisation/l’écran. - État des approbations d’exécution et de la liste d’autorisation. -Signatures courantes : +Signatures courantes : -- `NODE_BACKGROUND_UNAVAILABLE` → l’app du nœud doit être au premier plan. -- `*_PERMISSION_REQUIRED` / `LOCATION_PERMISSION_REQUIRED` → autorisation système manquante. +- `NODE_BACKGROUND_UNAVAILABLE` → l’application Node doit être au premier plan. +- `*_PERMISSION_REQUIRED` / `LOCATION_PERMISSION_REQUIRED` → autorisation du système d’exploitation manquante. - `SYSTEM_RUN_DENIED: approval required` → approbation d’exécution en attente. - `SYSTEM_RUN_DENIED: allowlist miss` → commande bloquée par la liste d’autorisation. -Voir aussi : +Voir aussi : - [/nodes/troubleshooting](/fr/nodes/troubleshooting) - [/nodes/index](/fr/nodes/index) @@ -386,7 +367,7 @@ Voir aussi : ## Échec de l’outil navigateur -Utilisez cette section lorsque les actions de l’outil navigateur échouent alors que la gateway elle-même est saine. +Utilisez ceci lorsque les actions de l’outil navigateur échouent même si la Gateway elle-même est saine. ```bash openclaw browser status @@ -396,41 +377,41 @@ openclaw logs --follow openclaw doctor ``` -Recherchez : +À rechercher : - Si `plugins.allow` est défini et inclut `browser`. -- Un chemin d’exécutable du navigateur valide. +- Un chemin d’exécutable de navigateur valide. - L’accessibilité du profil CDP. - La disponibilité de Chrome local pour les profils `existing-session` / `user`. -Signatures courantes : +Signatures courantes : -- `unknown command "browser"` ou `unknown command 'browser'` → le plugin navigateur intégré est exclu par `plugins.allow`. -- outil navigateur manquant / indisponible alors que `browser.enabled=true` → `plugins.allow` exclut `browser`, donc le plugin n’a jamais été chargé. -- `Failed to start Chrome CDP on port` → le processus du navigateur n’a pas pu être lancé. +- `unknown command "browser"` ou `unknown command 'browser'` → le Plugin navigateur fourni est exclu par `plugins.allow`. +- outil navigateur manquant / indisponible alors que `browser.enabled=true` → `plugins.allow` exclut `browser`, donc le Plugin ne s’est jamais chargé. +- `Failed to start Chrome CDP on port` → le processus du navigateur n’a pas pu démarrer. - `browser.executablePath not found` → le chemin configuré est invalide. - `browser.cdpUrl must be http(s) or ws(s)` → l’URL CDP configurée utilise un schéma non pris en charge tel que `file:` ou `ftp:`. -- `browser.cdpUrl has invalid port` → l’URL CDP configurée contient un port invalide ou hors plage. +- `browser.cdpUrl has invalid port` → l’URL CDP configurée a un port incorrect ou hors plage. - `No Chrome tabs found for profile="user"` → le profil d’attachement Chrome MCP n’a aucun onglet Chrome local ouvert. -- `Remote CDP for profile "" is not reachable` → le point de terminaison CDP distant configuré n’est pas accessible depuis l’hôte gateway. -- `Browser attachOnly is enabled ... not reachable` ou `Browser attachOnly is enabled and CDP websocket ... is not reachable` → le profil en attachement seul n’a aucune cible accessible, ou le point de terminaison HTTP a répondu mais le WebSocket CDP n’a toujours pas pu être ouvert. -- `Playwright is not available in this gateway build; '' is unsupported.` → l’installation actuelle de la gateway n’inclut pas le package Playwright complet ; les instantanés ARIA et les captures d’écran de page de base peuvent toujours fonctionner, mais la navigation, les instantanés IA, les captures d’écran d’élément par sélecteur CSS et l’export PDF restent indisponibles. -- `fullPage is not supported for element screenshots` → la requête de capture d’écran a mélangé `--full-page` avec `--ref` ou `--element`. -- `element screenshots are not supported for existing-session profiles; use ref from snapshot.` → les appels de capture d’écran Chrome MCP / `existing-session` doivent utiliser une capture de page ou un `--ref` d’instantané, pas un `--element` CSS. -- `existing-session file uploads do not support element selectors; use ref/inputRef.` → les hooks d’envoi de fichiers Chrome MCP nécessitent des refs d’instantané, pas des sélecteurs CSS. +- `Remote CDP for profile "" is not reachable` → le point de terminaison CDP distant configuré n’est pas accessible depuis l’hôte Gateway. +- `Browser attachOnly is enabled ... not reachable` ou `Browser attachOnly is enabled and CDP websocket ... is not reachable` → le profil attach-only n’a pas de cible accessible, ou le point de terminaison HTTP a répondu mais le WebSocket CDP n’a toujours pas pu être ouvert. +- `Playwright is not available in this gateway build; '' is unsupported.` → l’installation actuelle de Gateway n’inclut pas le paquet Playwright complet ; les instantanés ARIA et les captures d’écran de page de base peuvent toujours fonctionner, mais la navigation, les instantanés IA, les captures d’écran d’éléments via sélecteur CSS et l’export PDF restent indisponibles. +- `fullPage is not supported for element screenshots` → la requête de capture d’écran mélange `--full-page` avec `--ref` ou `--element`. +- `element screenshots are not supported for existing-session profiles; use ref from snapshot.` → les appels de capture d’écran Chrome MCP / `existing-session` doivent utiliser une capture de page ou un `--ref` d’instantané, et non un `--element` CSS. +- `existing-session file uploads do not support element selectors; use ref/inputRef.` → les hooks de téléversement Chrome MCP nécessitent des références d’instantané, pas des sélecteurs CSS. - `existing-session file uploads currently support one file at a time.` → envoyez un seul téléversement par appel sur les profils Chrome MCP. -- `existing-session dialog handling does not support timeoutMs.` → les hooks de dialogue sur les profils Chrome MCP ne prennent pas en charge les surcharges de délai. +- `existing-session dialog handling does not support timeoutMs.` → les hooks de boîte de dialogue sur les profils Chrome MCP ne prennent pas en charge les surcharges de délai d’attente. - `response body is not supported for existing-session profiles yet.` → `responsebody` nécessite encore un navigateur géré ou un profil CDP brut. -- surcharges persistantes de viewport / mode sombre / langue / hors ligne sur des profils en attachement seul ou CDP distant → exécutez `openclaw browser stop --browser-profile ` pour fermer la session de contrôle active et libérer l’état d’émulation Playwright/CDP sans redémarrer toute la gateway. +- remplacements persistants de viewport / mode sombre / langue / hors ligne sur les profils attach-only ou CDP distants → exécutez `openclaw browser stop --browser-profile ` pour fermer la session de contrôle active et libérer l’état d’émulation Playwright/CDP sans redémarrer toute la Gateway. -Voir aussi : +Voir aussi : - [/tools/browser-linux-troubleshooting](/fr/tools/browser-linux-troubleshooting) - [/tools/browser](/fr/tools/browser) ## Si vous avez effectué une mise à niveau et que quelque chose s’est soudainement cassé -La plupart des cassures après mise à niveau sont dues à une dérive de configuration ou à des valeurs par défaut plus strictes désormais appliquées. +La plupart des problèmes après mise à niveau proviennent d’une dérive de configuration ou de valeurs par défaut plus strictes désormais appliquées. ### 1) Le comportement d’authentification et de surcharge d’URL a changé @@ -441,17 +422,17 @@ openclaw config get gateway.remote.url openclaw config get gateway.auth.mode ``` -À vérifier : +Ce qu’il faut vérifier : -- Si `gateway.mode=remote`, les appels CLI peuvent cibler le remote alors que votre service local fonctionne bien. +- Si `gateway.mode=remote`, les appels CLI peuvent cibler le distant alors que votre service local fonctionne bien. - Les appels explicites avec `--url` ne reviennent pas aux identifiants stockés. -Signatures courantes : +Signatures courantes : -- `gateway connect failed:` → mauvaise URL cible. +- `gateway connect failed:` → mauvaise cible d’URL. - `unauthorized` → point de terminaison accessible mais mauvaise authentification. -### 2) Les garde-fous de bind et d’authentification sont plus stricts +### 2) Les garde-fous de liaison et d’authentification sont plus stricts ```bash openclaw config get gateway.bind @@ -461,17 +442,17 @@ openclaw gateway status openclaw logs --follow ``` -À vérifier : +Ce qu’il faut vérifier : -- Les binds non-loopback (`lan`, `tailnet`, `custom`) nécessitent un chemin d’authentification gateway valide : authentification par jeton/mot de passe partagé, ou déploiement `trusted-proxy` non-loopback correctement configuré. +- Les liaisons non loopback (`lan`, `tailnet`, `custom`) nécessitent un chemin d’authentification Gateway valide : authentification par jeton/mot de passe partagé, ou déploiement `trusted-proxy` non loopback correctement configuré. - Les anciennes clés comme `gateway.token` ne remplacent pas `gateway.auth.token`. -Signatures courantes : +Signatures courantes : -- `refusing to bind gateway ... without auth` → bind non-loopback sans chemin d’authentification gateway valide. -- `RPC probe: failed` alors que le runtime est en cours d’exécution → gateway active mais inaccessible avec l’authentification/l’URL actuelles. +- `refusing to bind gateway ... without auth` → liaison non loopback sans chemin d’authentification Gateway valide. +- `Connectivity probe: failed` alors que le runtime est en cours d’exécution → la Gateway est active mais inaccessible avec l’authentification/l’URL actuelles. -### 3) L’état d’appairage et d’identité d’appareil a changé +### 3) L’état d’appairage et d’identité de l’appareil a changé ```bash openclaw devices list @@ -480,24 +461,24 @@ openclaw logs --follow openclaw doctor ``` -À vérifier : +Ce qu’il faut vérifier : -- Approbations d’appareil en attente pour tableau de bord/nœuds. -- Approbations d’appairage DM en attente après des changements de politique ou d’identité. +- Approbations d’appareil en attente pour le tableau de bord/les Nodes. +- Approbations d’appairage DM en attente après des changements de stratégie ou d’identité. -Signatures courantes : +Signatures courantes : -- `device identity required` → authentification d’appareil non satisfaite. -- `pairing required` → expéditeur/appareil doit être approuvé. +- `device identity required` → l’authentification de l’appareil n’est pas satisfaite. +- `pairing required` → l’expéditeur/l’appareil doit être approuvé. -Si la configuration du service et le runtime ne concordent toujours pas après ces vérifications, réinstallez les métadonnées du service à partir du même répertoire de profil/d’état : +Si la configuration du service et le runtime sont toujours en désaccord après ces vérifications, réinstallez les métadonnées du service depuis le même répertoire de profil/d’état : ```bash openclaw gateway install --force openclaw gateway restart ``` -Voir aussi : +Voir aussi : - [/gateway/pairing](/fr/gateway/pairing) - [/gateway/authentication](/fr/gateway/authentication) diff --git a/docs/fr/help/faq.md b/docs/fr/help/faq.md index c49817f2e..963afc5a1 100644 --- a/docs/fr/help/faq.md +++ b/docs/fr/help/faq.md @@ -1,21 +1,21 @@ --- read_when: - - Réponses aux questions fréquentes sur la configuration, l’installation, l’intégration ou le support d’exécution - - Triage des problèmes signalés par les utilisateurs avant un débogage plus approfondi + - Répondre aux questions courantes sur la configuration, l’installation, l’intégration ou l’assistance d’exécution + - Trier les problèmes signalés par les utilisateurs avant un débogage plus approfondi summary: Questions fréquentes sur la configuration, les paramètres et l’utilisation d’OpenClaw title: FAQ x-i18n: - generated_at: "2026-04-19T06:52:37Z" + generated_at: "2026-04-20T07:05:26Z" model: gpt-5.4 provider: openai - source_hash: f569fb0412797314a11c41a1bbfa14f5892d2d368544fa67800823a6457000e6 + source_hash: ae8efda399e34f59f22f6ea8ce218eaf7b872e4117d8596ec19c09891d70813b source_path: help/faq.md workflow: 15 --- # FAQ -Réponses rapides ainsi qu’un dépannage plus approfondi pour des configurations réelles (développement local, VPS, multi-agent, clés OAuth/API, basculement de modèle). Pour les diagnostics d’exécution, voir [Dépannage](/fr/gateway/troubleshooting). Pour la référence complète de configuration, voir [Configuration](/fr/gateway/configuration). +Réponses rapides, avec un dépannage plus approfondi pour des configurations réelles (développement local, VPS, multi-agent, clés OAuth/API, basculement de modèle). Pour les diagnostics d’exécution, voir [Dépannage](/fr/gateway/troubleshooting). Pour la référence complète de configuration, voir [Configuration](/fr/gateway/configuration). ## Les 60 premières secondes si quelque chose est cassé @@ -25,23 +25,23 @@ Réponses rapides ainsi qu’un dépannage plus approfondi pour des configuratio openclaw status ``` - Résumé local rapide : OS + mise à jour, accessibilité du Gateway/service, agents/sessions, configuration du fournisseur + problèmes d’exécution (lorsque le Gateway est accessible). + Résumé local rapide : OS + mise à jour, accessibilité de la gateway/du service, agents/sessions, configuration du fournisseur + problèmes d’exécution (lorsque la gateway est joignable). -2. **Rapport partageable (sans risque à partager)** +2. **Rapport partageable (sans risque)** ```bash openclaw status --all ``` - Diagnostic en lecture seule avec fin des journaux (tokens masqués). + Diagnostic en lecture seule avec fin de journal (tokens masqués). -3. **État du démon + du port** +3. **État du daemon + du port** ```bash openclaw gateway status ``` - Affiche l’exécution du superviseur par rapport à l’accessibilité RPC, l’URL cible de la sonde, et la configuration probablement utilisée par le service. + Affiche l’exécution du superviseur par rapport à l’accessibilité RPC, l’URL cible de la sonde et la configuration que le service a probablement utilisée. 4. **Sondes approfondies** @@ -49,10 +49,10 @@ Réponses rapides ainsi qu’un dépannage plus approfondi pour des configuratio openclaw status --deep ``` - Exécute une sonde de santé Gateway en direct, y compris des sondes de canal lorsqu’elles sont prises en charge - (nécessite un Gateway accessible). Voir [Health](/fr/gateway/health). + Exécute une sonde d’état de santé live de la gateway, y compris des sondes de canal lorsque c’est pris en charge + (nécessite une gateway joignable). Voir [Health](/fr/gateway/health). -5. **Suivre le dernier journal** +5. **Suivre le journal le plus récent** ```bash openclaw logs --follow @@ -64,56 +64,56 @@ Réponses rapides ainsi qu’un dépannage plus approfondi pour des configuratio tail -f "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)" ``` - Les journaux de fichier sont distincts des journaux de service ; voir [Logging](/fr/logging) et [Dépannage](/fr/gateway/troubleshooting). + Les journaux de fichier sont distincts des journaux du service ; voir [Logging](/fr/logging) et [Dépannage](/fr/gateway/troubleshooting). -6. **Exécuter Doctor (réparations)** +6. **Exécuter le doctor (réparations)** ```bash openclaw doctor ``` - Répare/migre la configuration et l’état + exécute des contrôles d’intégrité. Voir [Doctor](/fr/gateway/doctor). + Répare/migre la configuration et l’état + exécute des vérifications d’état de santé. Voir [Doctor](/fr/gateway/doctor). -7. **Instantané du Gateway** +7. **Instantané de la gateway** ```bash openclaw health --json - openclaw health --verbose # shows the target URL + config path on errors + openclaw health --verbose # affiche l’URL cible + le chemin de configuration en cas d’erreur ``` - Demande au Gateway en cours d’exécution un instantané complet (WS uniquement). Voir [Health](/fr/gateway/health). + Demande à la gateway en cours d’exécution un instantané complet (WS uniquement). Voir [Health](/fr/gateway/health). -## Démarrage rapide et configuration au premier lancement +## Démarrage rapide et configuration initiale Utilisez un agent IA local qui peut **voir votre machine**. C’est bien plus efficace que de demander - sur Discord, car la plupart des cas de type « je suis bloqué » sont des **problèmes de configuration locale ou d’environnement** que - les personnes qui vous aident à distance ne peuvent pas inspecter. + sur Discord, car la plupart des cas de « je suis bloqué » sont des **problèmes de configuration locale ou d’environnement** + que les personnes aidant à distance ne peuvent pas inspecter. - **Claude Code** : [https://www.anthropic.com/claude-code/](https://www.anthropic.com/claude-code/) - **OpenAI Codex** : [https://openai.com/codex/](https://openai.com/codex/) - Ces outils peuvent lire le dépôt, exécuter des commandes, inspecter les journaux et aider à corriger votre configuration - au niveau de la machine (PATH, services, permissions, fichiers d’authentification). Donnez-leur le **checkout complet des sources** via - l’installation hackable (git) : + Ces outils peuvent lire le dépôt, exécuter des commandes, inspecter les journaux et aider à corriger + la configuration de votre machine (PATH, services, permissions, fichiers d’authentification). Donnez-leur la **copie complète des sources** + via l’installation modifiable (git) : ```bash curl -fsSL https://openclaw.ai/install.sh | bash -s -- --install-method git ``` - Cela installe OpenClaw **depuis un checkout git**, afin que l’agent puisse lire le code + la documentation et - raisonner sur la version exacte que vous utilisez. Vous pourrez toujours revenir ensuite à la version stable + Cela installe OpenClaw **depuis une copie git**, afin que l’agent puisse lire le code + la documentation + et raisonner sur la version exacte que vous utilisez. Vous pourrez toujours revenir ensuite à la version stable en relançant l’installateur sans `--install-method git`. Conseil : demandez à l’agent de **planifier et superviser** la correction (étape par étape), puis d’exécuter uniquement les - commandes nécessaires. Cela limite les changements et facilite leur audit. + commandes nécessaires. Cela limite les changements et les rend plus faciles à auditer. - Si vous découvrez un véritable bug ou correctif, veuillez ouvrir une issue GitHub ou envoyer une PR : + Si vous découvrez un vrai bug ou un correctif, merci d’ouvrir une issue GitHub ou d’envoyer une PR : [https://github.com/openclaw/openclaw/issues](https://github.com/openclaw/openclaw/issues) [https://github.com/openclaw/openclaw/pulls](https://github.com/openclaw/openclaw/pulls) - Commencez par ces commandes (partagez les sorties lorsque vous demandez de l’aide) : + Commencez avec ces commandes (partagez les sorties si vous demandez de l’aide) : ```bash openclaw status @@ -123,43 +123,42 @@ Réponses rapides ainsi qu’un dépannage plus approfondi pour des configuratio Ce qu’elles font : - - `openclaw status` : instantané rapide de la santé du Gateway/de l’agent + configuration de base. + - `openclaw status` : instantané rapide de l’état de santé de la gateway/de l’agent + configuration de base. - `openclaw models status` : vérifie l’authentification du fournisseur + la disponibilité des modèles. - `openclaw doctor` : valide et répare les problèmes courants de configuration/d’état. Autres vérifications CLI utiles : `openclaw status --all`, `openclaw logs --follow`, `openclaw gateway status`, `openclaw health --verbose`. - Boucle de débogage rapide : [Les 60 premières secondes si quelque chose est cassé](#first-60-seconds-if-something-is-broken). - Documentation d’installation : [Install](/fr/install), [Paramètres de l’installateur](/fr/install/installer), [Mise à jour](/fr/install/updating). + Boucle de débogage rapide : [Les 60 premières secondes si quelque chose est cassé](#les-60-premières-secondes-si-quelque-chose-est-cassé). + Documentation d’installation : [Installation](/fr/install), [Options de l’installateur](/fr/install/installer), [Mise à jour](/fr/install/updating). - + Raisons courantes pour lesquelles Heartbeat est ignoré : - - `quiet-hours` : en dehors de la fenêtre active-hours configurée - - `empty-heartbeat-file` : `HEARTBEAT.md` existe mais ne contient qu’une structure vide ou uniquement des en-têtes - - `no-tasks-due` : le mode tâche de `HEARTBEAT.md` est actif mais aucun des intervalles de tâche n’est encore dû + - `quiet-hours` : en dehors de la plage `active-hours` configurée + - `empty-heartbeat-file` : `HEARTBEAT.md` existe mais ne contient qu’une structure vide ou seulement des en-têtes + - `no-tasks-due` : le mode tâche de `HEARTBEAT.md` est actif mais aucun des intervalles de tâche n’est encore arrivé à échéance - `alerts-disabled` : toute la visibilité Heartbeat est désactivée (`showOk`, `showAlerts` et `useIndicator` sont tous désactivés) En mode tâche, les horodatages d’échéance ne sont avancés qu’après la fin - d’une véritable exécution de Heartbeat. - Les exécutions ignorées ne marquent pas les tâches comme terminées. + d’une vraie exécution Heartbeat. Les exécutions ignorées ne marquent pas les tâches comme terminées. - Documentation : [Heartbeat](/fr/gateway/heartbeat), [Automatisation & tâches](/fr/automation). + Documentation : [Heartbeat](/fr/gateway/heartbeat), [Automatisation et tâches](/fr/automation). - Le dépôt recommande de l’exécuter depuis les sources et d’utiliser l’onboarding : + Le dépôt recommande d’exécuter depuis les sources et d’utiliser l’intégration : ```bash curl -fsSL https://openclaw.ai/install.sh | bash openclaw onboard --install-daemon ``` - L’assistant peut aussi construire automatiquement les ressources de l’interface utilisateur. Après l’onboarding, vous exécutez généralement le Gateway sur le port **18789**. + L’assistant peut aussi construire automatiquement les ressources UI. Après l’intégration, vous exécutez généralement la Gateway sur le port **18789**. Depuis les sources (contributeurs/dev) : @@ -176,88 +175,88 @@ Réponses rapides ainsi qu’un dépannage plus approfondi pour des configuratio - - L’assistant ouvre votre navigateur avec une URL de tableau de bord propre (sans token) juste après l’onboarding et imprime aussi le lien dans le récapitulatif. Gardez cet onglet ouvert ; s’il ne s’est pas lancé, copiez/collez l’URL affichée sur la même machine. + + L’assistant ouvre votre navigateur avec une URL propre (sans token) du tableau de bord juste après l’intégration et affiche aussi le lien dans le résumé. Gardez cet onglet ouvert ; s’il ne s’est pas lancé, copiez/collez l’URL affichée sur la même machine. **Localhost (même machine) :** - Ouvrez `http://127.0.0.1:18789/`. - - S’il demande une authentification par secret partagé, collez le token ou le mot de passe configuré dans les paramètres de Control UI. + - S’il demande une authentification par secret partagé, collez le token ou le mot de passe configuré dans les paramètres du Control UI. - Source du token : `gateway.auth.token` (ou `OPENCLAW_GATEWAY_TOKEN`). - Source du mot de passe : `gateway.auth.password` (ou `OPENCLAW_GATEWAY_PASSWORD`). - Si aucun secret partagé n’est encore configuré, générez un token avec `openclaw doctor --generate-gateway-token`. **Pas sur localhost :** - - **Tailscale Serve** (recommandé) : gardez bind loopback, exécutez `openclaw gateway --tailscale serve`, ouvrez `https:///`. Si `gateway.auth.allowTailscale` vaut `true`, les en-têtes d’identité satisfont l’authentification de Control UI/WebSocket (sans coller de secret partagé, en supposant un hôte Gateway de confiance) ; les API HTTP exigent toujours une authentification par secret partagé, sauf si vous utilisez délibérément `none` pour l’entrée privée ou l’authentification HTTP trusted-proxy. - Les mauvaises tentatives d’authentification simultanées via Serve depuis le même client sont sérialisées avant que le limiteur d’échecs d’authentification les enregistre ; ainsi, la deuxième mauvaise tentative peut déjà afficher `retry later`. - - **Bind tailnet** : exécutez `openclaw gateway --bind tailnet --token ""` (ou configurez une authentification par mot de passe), ouvrez `http://:18789/`, puis collez le secret partagé correspondant dans les paramètres du tableau de bord. - - **Proxy inverse avec gestion d’identité** : gardez le Gateway derrière un proxy de confiance non loopback, configurez `gateway.auth.mode: "trusted-proxy"`, puis ouvrez l’URL du proxy. - - **Tunnel SSH** : `ssh -N -L 18789:127.0.0.1:18789 user@host` puis ouvrez `http://127.0.0.1:18789/`. L’authentification par secret partagé s’applique toujours via le tunnel ; collez le token ou le mot de passe configuré si cela vous est demandé. + - **Tailscale Serve** (recommandé) : conservez la liaison loopback, exécutez `openclaw gateway --tailscale serve`, ouvrez `https:///`. Si `gateway.auth.allowTailscale` vaut `true`, les en-têtes d’identité satisfont l’authentification du Control UI/WebSocket (sans coller de secret partagé, en supposant un hôte de gateway de confiance) ; les API HTTP exigent toujours une authentification par secret partagé, sauf si vous utilisez délibérément `none` sur une entrée privée ou l’authentification HTTP par proxy de confiance. + Les mauvaises tentatives d’authentification Serve simultanées provenant du même client sont sérialisées avant que le limiteur d’échec d’authentification ne les enregistre ; ainsi, le deuxième mauvais essai peut déjà afficher `retry later`. + - **Liaison tailnet** : exécutez `openclaw gateway --bind tailnet --token ""` (ou configurez une authentification par mot de passe), ouvrez `http://:18789/`, puis collez le secret partagé correspondant dans les paramètres du tableau de bord. + - **Proxy inverse avec gestion d’identité** : gardez la Gateway derrière un proxy de confiance non loopback, configurez `gateway.auth.mode: "trusted-proxy"`, puis ouvrez l’URL du proxy. + - **Tunnel SSH** : `ssh -N -L 18789:127.0.0.1:18789 user@host` puis ouvrez `http://127.0.0.1:18789/`. L’authentification par secret partagé s’applique toujours via le tunnel ; collez le token ou le mot de passe configuré si demandé. - Voir [Dashboard](/web/dashboard) et [Surfaces Web](/web) pour les modes de bind et les détails d’authentification. + Voir [Dashboard](/web/dashboard) et [Surfaces Web](/web) pour les modes de liaison et les détails d’authentification. - + Elles contrôlent des couches différentes : - - `approvals.exec` : transfère les invites d’approbation vers des destinations de chat - - `channels..execApprovals` : fait agir ce canal comme client d’approbation natif pour les approbations exec + - `approvals.exec` : transfère les invites d’approbation vers les destinations de chat + - `channels..execApprovals` : fait de ce canal un client d’approbation natif pour les approbations exec - La politique exec de l’hôte reste la véritable porte d’approbation. La configuration du chat ne contrôle que l’endroit où les invites d’approbation - apparaissent et la manière dont les personnes peuvent y répondre. + La politique exec de l’hôte reste le véritable garde-fou d’approbation. La configuration du chat ne contrôle que l’endroit + où apparaissent les invites d’approbation et la manière dont les personnes peuvent y répondre. Dans la plupart des configurations, vous n’avez **pas** besoin des deux : - Si le chat prend déjà en charge les commandes et les réponses, `/approve` dans le même chat fonctionne via le chemin partagé. - - Si un canal natif pris en charge peut déduire les approbateurs de manière sûre, OpenClaw active désormais automatiquement les approbations natives DM-first lorsque `channels..execApprovals.enabled` n’est pas défini ou vaut `"auto"`. - - Lorsque des cartes/boutons d’approbation natifs sont disponibles, cette interface native est le chemin principal ; l’agent ne doit inclure une commande manuelle `/approve` que si le résultat de l’outil indique que les approbations par chat ne sont pas disponibles ou que l’approbation manuelle est le seul chemin possible. - - Utilisez `approvals.exec` uniquement si les invites doivent aussi être transférées vers d’autres chats ou des salons d’exploitation explicites. - - Utilisez `channels..execApprovals.target: "channel"` ou `"both"` uniquement si vous souhaitez explicitement que les invites d’approbation soient publiées dans le salon/sujet d’origine. - - Les approbations de Plugin sont encore séparées : elles utilisent par défaut `/approve` dans le même chat, un transfert optionnel via `approvals.plugin`, et seuls certains canaux natifs conservent une gestion native des approbations de Plugin par-dessus. + - Si un canal natif pris en charge peut déduire les approbateurs en toute sécurité, OpenClaw active désormais automatiquement les approbations natives DM-first lorsque `channels..execApprovals.enabled` n’est pas défini ou vaut `"auto"`. + - Lorsque des cartes/boutons d’approbation natifs sont disponibles, cette UI native est le chemin principal ; l’agent ne doit inclure une commande manuelle `/approve` que si le résultat de l’outil indique que les approbations par chat ne sont pas disponibles ou que l’approbation manuelle est le seul chemin possible. + - Utilisez `approvals.exec` uniquement lorsque les invites doivent aussi être transférées vers d’autres chats ou des salons ops explicites. + - Utilisez `channels..execApprovals.target: "channel"` ou `"both"` uniquement lorsque vous voulez explicitement que les invites d’approbation soient republiées dans la salle/le sujet d’origine. + - Les approbations de Plugin sont encore séparées : elles utilisent par défaut `/approve` dans le même chat, un transfert optionnel via `approvals.plugin`, et seuls certains canaux natifs conservent en plus une gestion native des approbations de plugin. - En bref : le transfert sert au routage, la configuration du client natif sert à une UX de canal plus riche et spécifique. + Version courte : le transfert sert au routage, la configuration du client natif sert à une UX plus riche et spécifique au canal. Voir [Exec Approvals](/fr/tools/exec-approvals). - Node **>= 22** est requis. `pnpm` est recommandé. Bun est **non recommandé** pour le Gateway. + Node **>= 22** est requis. `pnpm` est recommandé. Bun n’est **pas recommandé** pour la Gateway. - - Oui. Le Gateway est léger — la documentation indique que **512MB-1GB de RAM**, **1 cœur** et environ **500MB** - d’espace disque suffisent pour un usage personnel, et précise qu’un **Raspberry Pi 4 peut l’exécuter**. + + Oui. La Gateway est légère — la documentation indique que **512 Mo à 1 Go de RAM**, **1 cœur** et environ **500 Mo** + de disque suffisent pour un usage personnel, et précise qu’un **Raspberry Pi 4 peut l’exécuter**. - Si vous voulez plus de marge (journaux, médias, autres services), **2GB sont recommandés**, mais ce + Si vous voulez plus de marge (journaux, médias, autres services), **2 Go sont recommandés**, mais ce n’est pas un minimum strict. - Conseil : un petit Pi/VPS peut héberger le Gateway, et vous pouvez associer des **Node** sur votre ordinateur portable/téléphone pour - l’écran, la caméra, le canevas ou l’exécution de commandes en local. Voir [Nodes](/fr/nodes). + Conseil : un petit Pi/VPS peut héberger la Gateway, et vous pouvez associer des **nodes** sur votre ordinateur portable/téléphone pour + l’écran, la caméra, le canvas ou l’exécution de commandes en local. Voir [Nodes](/fr/nodes). - En bref : cela fonctionne, mais attendez-vous à quelques aspérités. + Version courte : ça fonctionne, mais attendez-vous à quelques difficultés. - - Utilisez un OS **64 bits** et gardez Node >= 22. - - Préférez l’**installation hackable (git)** afin de pouvoir voir les journaux et mettre à jour rapidement. + - Utilisez un OS **64 bits** et conservez Node >= 22. + - Préférez l’**installation modifiable (git)** afin de pouvoir voir les journaux et mettre à jour rapidement. - Commencez sans canaux/Skills, puis ajoutez-les un par un. - - Si vous rencontrez d’étranges problèmes binaires, il s’agit généralement d’un problème de **compatibilité ARM**. + - Si vous rencontrez des problèmes binaires étranges, il s’agit généralement d’un problème de **compatibilité ARM**. - Documentation : [Linux](/fr/platforms/linux), [Install](/fr/install). + Documentation : [Linux](/fr/platforms/linux), [Installation](/fr/install). - - Cet écran dépend du fait que le Gateway soit accessible et authentifié. Le TUI envoie aussi + + Cet écran dépend de l’accessibilité et de l’authentification de la Gateway. Le TUI envoie aussi automatiquement « Wake up, my friend! » lors de la première initialisation. Si vous voyez cette ligne **sans réponse** et que les tokens restent à 0, l’agent ne s’est jamais exécuté. - 1. Redémarrez le Gateway : + 1. Redémarrez la Gateway : ```bash openclaw gateway restart @@ -271,35 +270,35 @@ Réponses rapides ainsi qu’un dépannage plus approfondi pour des configuratio openclaw logs --follow ``` - 3. Si cela bloque encore, exécutez : + 3. Si cela bloque toujours, exécutez : ```bash openclaw doctor ``` - Si le Gateway est distant, assurez-vous que la connexion tunnel/Tailscale est active et que l’interface utilisateur - pointe vers le bon Gateway. Voir [Accès distant](/fr/gateway/remote). + Si la Gateway est distante, assurez-vous que le tunnel/la connexion Tailscale fonctionne et que l’UI + pointe vers la bonne Gateway. Voir [Accès distant](/fr/gateway/remote). - + Oui. Copiez le **répertoire d’état** et l’**espace de travail**, puis exécutez Doctor une fois. Cela - permet de conserver votre bot « exactement à l’identique » (mémoire, historique de session, authentification et - état des canaux) tant que vous copiez **les deux** emplacements : + permet de conserver votre bot « exactement identique » (mémoire, historique de session, authentification et + état des canaux) à condition de copier **les deux** emplacements : 1. Installez OpenClaw sur la nouvelle machine. 2. Copiez `$OPENCLAW_STATE_DIR` (par défaut : `~/.openclaw`) depuis l’ancienne machine. 3. Copiez votre espace de travail (par défaut : `~/.openclaw/workspace`). - 4. Exécutez `openclaw doctor` puis redémarrez le service Gateway. + 4. Exécutez `openclaw doctor` et redémarrez le service Gateway. Cela préserve la configuration, les profils d’authentification, les identifiants WhatsApp, les sessions et la mémoire. Si vous êtes en - mode distant, souvenez-vous que l’hôte Gateway possède le magasin de sessions et l’espace de travail. + mode distant, n’oubliez pas que l’hôte de la gateway possède le magasin de sessions et l’espace de travail. - **Important :** si vous ne faites que commit/push votre espace de travail sur GitHub, vous sauvegardez + **Important :** si vous ne faites que valider/pousser votre espace de travail sur GitHub, vous sauvegardez **la mémoire + les fichiers d’amorçage**, mais **pas** l’historique des sessions ni l’authentification. Ceux-ci se trouvent sous `~/.openclaw/` (par exemple `~/.openclaw/agents//sessions/`). - Voir aussi : [Migration](/fr/install/migrating), [Où les éléments sont stockés sur le disque](#where-things-live-on-disk), + Liens associés : [Migration](/fr/install/migrating), [Où les éléments sont stockés sur le disque](#où-les-éléments-sont-stockés-sur-le-disque), [Espace de travail de l’agent](/fr/concepts/agent-workspace), [Doctor](/fr/gateway/doctor), [Mode distant](/fr/gateway/remote). @@ -310,8 +309,8 @@ Réponses rapides ainsi qu’un dépannage plus approfondi pour des configuratio [https://github.com/openclaw/openclaw/blob/main/CHANGELOG.md](https://github.com/openclaw/openclaw/blob/main/CHANGELOG.md) Les entrées les plus récentes sont en haut. Si la section du haut est marquée **Unreleased**, la section datée suivante - correspond à la dernière version publiée. Les entrées sont regroupées par **Highlights**, **Changes** et - **Fixes** (ainsi que documentation/autres sections si nécessaire). + correspond à la dernière version publiée. Les entrées sont regroupées en **Highlights**, **Changes** et + **Fixes** (avec des sections docs/autres si nécessaire). @@ -320,32 +319,32 @@ Réponses rapides ainsi qu’un dépannage plus approfondi pour des configuratio Advanced Security. Désactivez-la ou ajoutez `docs.openclaw.ai` à la liste d’autorisation, puis réessayez. Merci de nous aider à le débloquer en le signalant ici : [https://spa.xfinity.com/check_url_status](https://spa.xfinity.com/check_url_status). - Si vous ne pouvez toujours pas accéder au site, la documentation est aussi disponible en miroir sur GitHub : + Si vous ne parvenez toujours pas à accéder au site, la documentation est reflétée sur GitHub : [https://github.com/openclaw/openclaw/tree/main/docs](https://github.com/openclaw/openclaw/tree/main/docs) - - **Stable** et **beta** sont des **dist-tags npm**, pas des lignes de code distinctes : + + **Stable** et **bêta** sont des **npm dist-tags**, pas des lignes de code distinctes : - `latest` = stable - - `beta` = build anticipée pour les tests + - `beta` = version précoce pour les tests En général, une version stable arrive d’abord sur **beta**, puis une étape explicite de promotion déplace cette même version vers `latest`. Les mainteneurs peuvent aussi - publier directement sur `latest` si nécessaire. C’est pourquoi beta et stable peuvent + publier directement vers `latest` si nécessaire. C’est pourquoi bêta et stable peuvent pointer vers la **même version** après promotion. - Pour voir ce qui a changé : + Voir ce qui a changé : [https://github.com/openclaw/openclaw/blob/main/CHANGELOG.md](https://github.com/openclaw/openclaw/blob/main/CHANGELOG.md) - Pour les commandes d’installation en une ligne et la différence entre beta et dev, voir l’accordéon ci-dessous. + Pour les commandes d’installation en une ligne et la différence entre bêta et dev, voir l’accordéon ci-dessous. - - **Beta** est le dist-tag npm `beta` (peut correspondre à `latest` après promotion). - **Dev** est la tête mobile de `main` (git) ; lorsqu’elle est publiée, elle utilise le dist-tag npm `dev`. + + **Bêta** est le npm dist-tag `beta` (peut correspondre à `latest` après promotion). + **Dev** est la tête mobile de `main` (git) ; lorsqu’elle est publiée, elle utilise le npm dist-tag `dev`. Commandes en une ligne (macOS/Linux) : @@ -360,22 +359,22 @@ Réponses rapides ainsi qu’un dépannage plus approfondi pour des configuratio Installateur Windows (PowerShell) : [https://openclaw.ai/install.ps1](https://openclaw.ai/install.ps1) - Plus de détails : [Canaux de développement](/fr/install/development-channels) et [Paramètres de l’installateur](/fr/install/installer). + Plus de détails : [Canaux de développement](/fr/install/development-channels) et [Options de l’installateur](/fr/install/installer). Deux options : - 1. **Canal dev (checkout git) :** + 1. **Canal dev (copie git) :** ```bash openclaw update --channel dev ``` - Cela bascule sur la branche `main` et met à jour depuis les sources. + Cela bascule sur la branche `main` et effectue une mise à jour depuis les sources. - 2. **Installation hackable (depuis le site de l’installateur) :** + 2. **Installation modifiable (depuis le site de l’installateur) :** ```bash curl -fsSL https://openclaw.ai/install.sh | bash -s -- --install-method git @@ -383,7 +382,7 @@ Réponses rapides ainsi qu’un dépannage plus approfondi pour des configuratio Cela vous donne un dépôt local que vous pouvez modifier, puis mettre à jour via git. - Si vous préférez faire manuellement un clone propre, utilisez : + Si vous préférez cloner proprement manuellement, utilisez : ```bash git clone https://github.com/openclaw/openclaw.git @@ -392,36 +391,36 @@ Réponses rapides ainsi qu’un dépannage plus approfondi pour des configuratio pnpm build ``` - Documentation : [Update](/cli/update), [Canaux de développement](/fr/install/development-channels), - [Install](/fr/install). + Documentation : [Mise à jour](/cli/update), [Canaux de développement](/fr/install/development-channels), + [Installation](/fr/install). - + Estimation approximative : - **Installation :** 2 à 5 minutes - - **Onboarding :** 5 à 15 minutes selon le nombre de canaux/modèles que vous configurez + - **Intégration :** 5 à 15 minutes selon le nombre de canaux/modèles que vous configurez Si cela se bloque, utilisez [Installateur bloqué](#quick-start-and-first-run-setup) et la boucle de débogage rapide dans [Je suis bloqué](#quick-start-and-first-run-setup). - - Relancez l’installateur avec une **sortie verbeuse** : + + Relancez l’installateur avec une **sortie détaillée** : ```bash curl -fsSL https://openclaw.ai/install.sh | bash -s -- --verbose ``` - Installation beta avec sortie verbeuse : + Installation bêta avec sortie détaillée : ```bash curl -fsSL https://openclaw.ai/install.sh | bash -s -- --beta --verbose ``` - Pour une installation hackable (git) : + Pour une installation modifiable (git) : ```bash curl -fsSL https://openclaw.ai/install.sh | bash -s -- --install-method git --verbose @@ -430,17 +429,17 @@ Réponses rapides ainsi qu’un dépannage plus approfondi pour des configuratio Équivalent Windows (PowerShell) : ```powershell - # install.ps1 n’a pas encore de paramètre -Verbose dédié. + # install.ps1 n’a pas encore d’option -Verbose dédiée. Set-PSDebug -Trace 1 & ([scriptblock]::Create((iwr -useb https://openclaw.ai/install.ps1))) -NoOnboard Set-PSDebug -Trace 0 ``` - Plus d’options : [Paramètres de l’installateur](/fr/install/installer). + Plus d’options : [Options de l’installateur](/fr/install/installer). - + Deux problèmes Windows courants : **1) erreur npm spawn git / git introuvable** @@ -450,30 +449,30 @@ Réponses rapides ainsi qu’un dépannage plus approfondi pour des configuratio **2) openclaw n’est pas reconnu après l’installation** - - Votre dossier global bin npm n’est pas dans le PATH. + - Votre dossier global npm bin n’est pas dans le PATH. - Vérifiez le chemin : ```powershell npm config get prefix ``` - - Ajoutez ce répertoire à votre PATH utilisateur (pas besoin du suffixe `\bin` sous Windows ; sur la plupart des systèmes, c’est `%AppData%\npm`). - - Fermez puis rouvrez PowerShell après avoir mis à jour le PATH. + - Ajoutez ce répertoire à votre PATH utilisateur (aucun suffixe `\bin` n’est nécessaire sous Windows ; sur la plupart des systèmes, c’est `%AppData%\npm`). + - Fermez puis rouvrez PowerShell après la mise à jour du PATH. - Si vous voulez la configuration Windows la plus fluide, utilisez **WSL2** au lieu de Windows natif. + Si vous voulez la configuration Windows la plus fluide, utilisez **WSL2** plutôt que Windows natif. Documentation : [Windows](/fr/platforms/windows). - - Cela est généralement dû à une incompatibilité de page de code de console dans les shells Windows natifs. + + Il s’agit généralement d’un décalage d’encodage de la page de code de la console dans les shells Windows natifs. Symptômes : - - la sortie `system.run`/`exec` affiche le chinois sous forme de mojibake + - la sortie `system.run`/`exec` affiche le chinois de manière illisible - la même commande s’affiche correctement dans un autre profil de terminal - Solution de contournement rapide dans PowerShell : + Solution rapide dans PowerShell : ```powershell chcp 65001 @@ -482,71 +481,71 @@ Réponses rapides ainsi qu’un dépannage plus approfondi pour des configuratio $OutputEncoding = [System.Text.UTF8Encoding]::new($false) ``` - Ensuite, redémarrez le Gateway et réessayez votre commande : + Redémarrez ensuite la Gateway et réessayez votre commande : ```powershell openclaw gateway restart ``` - Si vous reproduisez encore ce problème avec la dernière version d’OpenClaw, suivez/signalez-le ici : + Si vous reproduisez toujours cela avec la dernière version d’OpenClaw, suivez/signal ez-le ici : - [Issue #30640](https://github.com/openclaw/openclaw/issues/30640) - - Utilisez l’**installation hackable (git)** afin d’avoir localement le code source et la documentation complets, puis posez la question + + Utilisez l’**installation modifiable (git)** pour avoir localement l’intégralité des sources et de la documentation, puis posez la question à votre bot (ou à Claude/Codex) _depuis ce dossier_ afin qu’il puisse lire le dépôt et répondre précisément. ```bash curl -fsSL https://openclaw.ai/install.sh | bash -s -- --install-method git ``` - Plus de détails : [Install](/fr/install) et [Paramètres de l’installateur](/fr/install/installer). + Plus de détails : [Installation](/fr/install) et [Options de l’installateur](/fr/install/installer). - Réponse courte : suivez le guide Linux, puis lancez l’onboarding. + Réponse courte : suivez le guide Linux, puis exécutez l’intégration. - - Parcours rapide Linux + installation du service : [Linux](/fr/platforms/linux). + - Parcours Linux rapide + installation du service : [Linux](/fr/platforms/linux). - Guide complet : [Premiers pas](/fr/start/getting-started). - Installateur + mises à jour : [Installation et mises à jour](/fr/install/updating). - N’importe quel VPS Linux convient. Installez-le sur le serveur, puis utilisez SSH/Tailscale pour accéder au Gateway. + N’importe quel VPS Linux fonctionne. Installez-le sur le serveur, puis utilisez SSH/Tailscale pour atteindre la Gateway. Guides : [exe.dev](/fr/install/exe-dev), [Hetzner](/fr/install/hetzner), [Fly.io](/fr/install/fly). - Accès distant : [Gateway remote](/fr/gateway/remote). + Accès distant : [Gateway distante](/fr/gateway/remote). - - Nous conservons un **hub d’hébergement** avec les fournisseurs les plus courants. Choisissez-en un et suivez le guide : + + Nous maintenons un **hub d’hébergement** avec les fournisseurs les plus courants. Choisissez-en un et suivez le guide : - [Hébergement VPS](/fr/vps) (tous les fournisseurs au même endroit) - [Fly.io](/fr/install/fly) - [Hetzner](/fr/install/hetzner) - [exe.dev](/fr/install/exe-dev) - Fonctionnement dans le cloud : le **Gateway s’exécute sur le serveur**, et vous y accédez - depuis votre ordinateur portable/téléphone via la Control UI (ou Tailscale/SSH). Votre état + votre espace de travail - se trouvent sur le serveur ; traitez donc l’hôte comme la source de vérité et sauvegardez-le. + Fonctionnement dans le cloud : la **Gateway s’exécute sur le serveur**, et vous y accédez + depuis votre ordinateur portable/téléphone via le Control UI (ou Tailscale/SSH). Votre état + espace de travail + vivent sur le serveur ; considérez donc l’hôte comme la source de vérité et sauvegardez-le. - Vous pouvez associer des **Node** (Mac/iOS/Android/headless) à ce Gateway cloud pour accéder - à l’écran, à la caméra, au canevas locaux ou exécuter des commandes sur votre ordinateur portable tout en gardant le + Vous pouvez associer des **nodes** (Mac/iOS/Android/headless) à cette Gateway cloud pour accéder + à l’écran/la caméra/le canvas en local ou exécuter des commandes sur votre ordinateur portable tout en gardant la Gateway dans le cloud. - Hub : [Platforms](/fr/platforms). Accès distant : [Gateway remote](/fr/gateway/remote). - Nodes : [Nodes](/fr/nodes), [Nodes CLI](/cli/nodes). + Hub : [Plateformes](/fr/platforms). Accès distant : [Gateway distante](/fr/gateway/remote). + Nodes : [Nodes](/fr/nodes), [CLI des Nodes](/cli/nodes). - Réponse courte : **c’est possible, mais non recommandé**. Le flux de mise à jour peut redémarrer le - Gateway (ce qui interrompt la session active), peut nécessiter un checkout git propre, et + Réponse courte : **c’est possible, mais déconseillé**. Le flux de mise à jour peut redémarrer la + Gateway (ce qui coupe la session active), peut nécessiter une copie git propre, et peut demander une confirmation. Plus sûr : exécuter les mises à jour depuis un shell en tant qu’opérateur. Utilisez la CLI : @@ -566,58 +565,58 @@ Réponses rapides ainsi qu’un dépannage plus approfondi pour des configuratio openclaw gateway restart ``` - Documentation : [Update](/cli/update), [Updating](/fr/install/updating). + Documentation : [Mise à jour](/cli/update), [Mise à jour](/fr/install/updating). - + `openclaw onboard` est le parcours de configuration recommandé. En **mode local**, il vous guide à travers : - - **Configuration des modèles/de l’authentification** (OAuth fournisseur, clés API, setup-token Anthropic, ainsi que les options de modèles locaux telles que LM Studio) - - Emplacement de l’**espace de travail** + fichiers d’amorçage - - **Paramètres Gateway** (bind/port/auth/tailscale) - - **Canaux** (WhatsApp, Telegram, Discord, Mattermost, Signal, iMessage, ainsi que les plugins de canal intégrés comme QQ Bot) - - **Installation du démon** (LaunchAgent sur macOS ; unité utilisateur systemd sur Linux/WSL2) - - **Contrôles d’intégrité** et sélection des **Skills** + - **Configuration du modèle/de l’authentification** (OAuth fournisseur, clés API, setup-token Anthropic, ainsi que des options de modèle local comme LM Studio) + - emplacement de l’**espace de travail** + fichiers d’amorçage + - **paramètres de Gateway** (liaison/port/authentification/tailscale) + - **canaux** (WhatsApp, Telegram, Discord, Mattermost, Signal, iMessage, plus les plugins de canal fournis comme QQ Bot) + - **installation du daemon** (LaunchAgent sur macOS ; unité utilisateur systemd sur Linux/WSL2) + - **vérifications d’état de santé** et sélection des **Skills** - Il avertit également si votre modèle configuré est inconnu ou si l’authentification est absente. + Il avertit aussi si votre modèle configuré est inconnu ou si l’authentification est manquante. - Non. Vous pouvez exécuter OpenClaw avec des **clés API** (Anthropic/OpenAI/autres) ou avec des - **modèles uniquement locaux** afin que vos données restent sur votre appareil. Les abonnements (Claude + Non. Vous pouvez utiliser OpenClaw avec des **clés API** (Anthropic/OpenAI/autres) ou avec + des **modèles uniquement locaux** afin que vos données restent sur votre appareil. Les abonnements (Claude Pro/Max ou OpenAI Codex) sont des moyens facultatifs d’authentifier ces fournisseurs. Pour Anthropic dans OpenClaw, la distinction pratique est la suivante : - - **Clé API Anthropic** : facturation normale de l’API Anthropic - - **Authentification Claude CLI / abonnement Claude dans OpenClaw** : l’équipe Anthropic - nous a indiqué que cet usage est à nouveau autorisé, et OpenClaw traite l’usage de `claude -p` - comme autorisé pour cette intégration, sauf si Anthropic publie une nouvelle + - **clé API Anthropic** : facturation normale de l’API Anthropic + - **authentification Claude CLI / abonnement Claude dans OpenClaw** : le personnel Anthropic + nous a indiqué que cet usage est de nouveau autorisé, et OpenClaw traite l’usage de `claude -p` + comme approuvé pour cette intégration, sauf si Anthropic publie une nouvelle politique - Pour les hôtes Gateway de longue durée, les clés API Anthropic restent la - configuration la plus prévisible. OpenAI Codex OAuth est explicitement pris en charge pour les outils - externes comme OpenClaw. + Pour les hôtes de gateway de longue durée, les clés API Anthropic restent néanmoins la solution la + plus prévisible. OAuth OpenAI Codex est explicitement pris en charge pour les outils externes + comme OpenClaw. OpenClaw prend aussi en charge d’autres options hébergées de type abonnement, notamment - **Qwen Cloud Coding Plan**, **MiniMax Coding Plan**, et + **Qwen Cloud Coding Plan**, **MiniMax Coding Plan** et **Z.AI / GLM Coding Plan**. Documentation : [Anthropic](/fr/providers/anthropic), [OpenAI](/fr/providers/openai), [Qwen Cloud](/fr/providers/qwen), - [MiniMax](/fr/providers/minimax), [GLM Models](/fr/providers/glm), - [Modèles locaux](/fr/gateway/local-models), [Models](/fr/concepts/models). + [MiniMax](/fr/providers/minimax), [Modèles GLM](/fr/providers/glm), + [Modèles locaux](/fr/gateway/local-models), [Modèles](/fr/concepts/models). - + Oui. - L’équipe Anthropic nous a indiqué que l’usage de Claude CLI dans le style OpenClaw est à nouveau autorisé ; OpenClaw considère donc - l’authentification par abonnement Claude et l’usage de `claude -p` comme approuvés - pour cette intégration, sauf si Anthropic publie une nouvelle politique. Si vous souhaitez + Le personnel d’Anthropic nous a indiqué que l’usage de Claude CLI de type OpenClaw est de nouveau autorisé, donc + OpenClaw considère l’authentification par abonnement Claude et l’usage de `claude -p` comme approuvés + pour cette intégration, sauf si Anthropic publie une nouvelle politique. Si vous voulez la configuration côté serveur la plus prévisible, utilisez plutôt une clé API Anthropic. @@ -625,47 +624,47 @@ Réponses rapides ainsi qu’un dépannage plus approfondi pour des configuratio Oui. - L’équipe Anthropic nous a indiqué que cet usage est à nouveau autorisé, donc OpenClaw considère - la réutilisation de Claude CLI et l’usage de `claude -p` comme approuvés pour cette intégration, + Le personnel d’Anthropic nous a indiqué que cet usage est de nouveau autorisé, donc OpenClaw considère + la réutilisation de Claude CLI et l’usage de `claude -p` comme approuvés pour cette intégration sauf si Anthropic publie une nouvelle politique. - Le setup-token Anthropic reste disponible comme chemin de jeton OpenClaw pris en charge, mais OpenClaw préfère désormais la réutilisation de Claude CLI et `claude -p` lorsqu’ils sont disponibles. - Pour les charges de travail de production ou multi-utilisateurs, l’authentification par clé API Anthropic reste le - choix le plus sûr et le plus prévisible. Si vous souhaitez d’autres options hébergées de type abonnement + Le setup-token Anthropic reste disponible comme chemin de token pris en charge par OpenClaw, mais OpenClaw privilégie désormais la réutilisation de Claude CLI et `claude -p` lorsqu’ils sont disponibles. + Pour les charges de travail de production ou multi-utilisateur, l’authentification par clé API Anthropic reste le + choix le plus sûr et le plus prévisible. Si vous voulez d’autres options hébergées de type abonnement dans OpenClaw, voir [OpenAI](/fr/providers/openai), [Qwen / Model - Cloud](/fr/providers/qwen), [MiniMax](/fr/providers/minimax) et [GLM - Models](/fr/providers/glm). + Cloud](/fr/providers/qwen), [MiniMax](/fr/providers/minimax) et [Modèles + GLM](/fr/providers/glm). - -Cela signifie que votre **quota/limite de débit Anthropic** est épuisé pour la fenêtre actuelle. Si vous + +Cela signifie que votre **quota/limite de débit Anthropic** est épuisé pour la fenêtre en cours. Si vous utilisez **Claude CLI**, attendez la réinitialisation de la fenêtre ou passez à une offre supérieure. Si vous -utilisez une **clé API Anthropic**, consultez la console Anthropic -pour l’utilisation/la facturation et augmentez les limites si nécessaire. +utilisez une **clé API Anthropic**, vérifiez la console Anthropic +pour l’usage/la facturation et augmentez les limites si nécessaire. Si le message est précisément : - `Extra usage is required for long context requests`, cela signifie que la requête essaie d’utiliser - la bêta de contexte 1M d’Anthropic (`context1m: true`). Cela ne fonctionne que si vos - identifiants sont éligibles à la facturation long contexte (facturation par clé API ou + `Extra usage is required for long context requests`, la requête essaie d’utiliser + la bêta de contexte 1M d’Anthropic (`context1m: true`). Cela ne fonctionne que si votre + identifiant est éligible à la facturation long contexte (facturation par clé API ou chemin de connexion Claude OpenClaw avec Extra Usage activé). - Conseil : définissez un **modèle de secours** afin qu’OpenClaw puisse continuer à répondre pendant qu’un fournisseur est limité par son débit. - Voir [Models](/cli/models), [OAuth](/fr/concepts/oauth), et + Conseil : définissez un **modèle de secours** afin qu’OpenClaw puisse continuer à répondre pendant qu’un fournisseur est limité. + Voir [Modèles](/cli/models), [OAuth](/fr/concepts/oauth) et [/gateway/troubleshooting#anthropic-429-extra-usage-required-for-long-context](/fr/gateway/troubleshooting#anthropic-429-extra-usage-required-for-long-context). - Oui. OpenClaw inclut un fournisseur intégré **Amazon Bedrock (Converse)**. Si les marqueurs d’environnement AWS sont présents, OpenClaw peut découvrir automatiquement le catalogue Bedrock streaming/texte et le fusionner comme fournisseur implicite `amazon-bedrock` ; sinon, vous pouvez activer explicitement `plugins.entries.amazon-bedrock.config.discovery.enabled` ou ajouter une entrée de fournisseur manuellement. Voir [Amazon Bedrock](/fr/providers/bedrock) et [Model providers](/fr/providers/models). Si vous préférez un flux de clé géré, un proxy compatible OpenAI devant Bedrock reste une option valide. + Oui. OpenClaw inclut un fournisseur **Amazon Bedrock (Converse)**. Lorsque les marqueurs d’environnement AWS sont présents, OpenClaw peut découvrir automatiquement le catalogue Bedrock streaming/texte et le fusionner comme fournisseur implicite `amazon-bedrock` ; sinon, vous pouvez activer explicitement `plugins.entries.amazon-bedrock.config.discovery.enabled` ou ajouter une entrée de fournisseur manuelle. Voir [Amazon Bedrock](/fr/providers/bedrock) et [Fournisseurs de modèles](/fr/providers/models). Si vous préférez un flux de clé géré, un proxy compatible OpenAI devant Bedrock reste une option valide. - OpenClaw prend en charge **OpenAI Code (Codex)** via OAuth (connexion ChatGPT). L’onboarding peut exécuter le flux OAuth et définira le modèle par défaut sur `openai-codex/gpt-5.4` lorsque c’est approprié. Voir [Model providers](/fr/concepts/model-providers) et [Onboarding (CLI)](/fr/start/wizard). + OpenClaw prend en charge **OpenAI Code (Codex)** via OAuth (connexion ChatGPT). L’intégration peut exécuter le flux OAuth et définira le modèle par défaut sur `openai-codex/gpt-5.4` lorsque c’est approprié. Voir [Fournisseurs de modèles](/fr/concepts/model-providers) et [Intégration (CLI)](/fr/start/wizard). - + OpenClaw traite les deux chemins séparément : - `openai-codex/gpt-5.4` = OAuth ChatGPT/Codex @@ -678,70 +677,69 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. - + `openai-codex/*` utilise le chemin OAuth Codex, et ses fenêtres de quota utilisables sont gérées par OpenAI et dépendent de l’offre. En pratique, ces limites peuvent différer de - l’expérience du site/de l’application ChatGPT, même si les deux sont liés au même compte. + l’expérience du site/de l’application ChatGPT, même lorsque les deux sont liées au même compte. - OpenClaw peut afficher les fenêtres d’utilisation/quota actuellement visibles du fournisseur dans + OpenClaw peut afficher les fenêtres de quota/d’usage actuellement visibles du fournisseur dans `openclaw models status`, mais il n’invente ni ne normalise les - droits du web ChatGPT en accès API direct. Si vous voulez le chemin direct de facturation/limite OpenAI Platform, - utilisez `openai/*` avec une clé API. + droits ChatGPT web en accès direct à l’API. Si vous voulez le chemin direct de facturation/limitation OpenAI Platform, utilisez `openai/*` avec une clé API. - - Oui. OpenClaw prend entièrement en charge **l’OAuth d’abonnement OpenAI Code (Codex)**. - OpenAI autorise explicitement l’usage de l’OAuth d’abonnement dans des outils/flux de travail externes - comme OpenClaw. L’onboarding peut exécuter le flux OAuth pour vous. + + Oui. OpenClaw prend entièrement en charge **l’OAuth par abonnement OpenAI Code (Codex)**. + OpenAI autorise explicitement l’usage d’OAuth par abonnement dans des outils/flux externes + comme OpenClaw. L’intégration peut exécuter le flux OAuth pour vous. - Voir [OAuth](/fr/concepts/oauth), [Model providers](/fr/concepts/model-providers), et [Onboarding (CLI)](/fr/start/wizard). + Voir [OAuth](/fr/concepts/oauth), [Fournisseurs de modèles](/fr/concepts/model-providers) et [Intégration (CLI)](/fr/start/wizard). - Gemini CLI utilise un **flux d’authentification de Plugin**, pas un client id ni un secret dans `openclaw.json`. + Gemini CLI utilise un **flux d’authentification de Plugin**, et non un identifiant client ou un secret dans `openclaw.json`. Étapes : 1. Installez Gemini CLI localement afin que `gemini` soit dans le `PATH` - Homebrew : `brew install gemini-cli` - npm : `npm install -g @google/gemini-cli` - 2. Activez le Plugin : `openclaw plugins enable google` + 2. Activez le plugin : `openclaw plugins enable google` 3. Connectez-vous : `openclaw models auth login --provider google-gemini-cli --set-default` 4. Modèle par défaut après connexion : `google-gemini-cli/gemini-3-flash-preview` - 5. Si les requêtes échouent, définissez `GOOGLE_CLOUD_PROJECT` ou `GOOGLE_CLOUD_PROJECT_ID` sur l’hôte Gateway + 5. Si les requêtes échouent, définissez `GOOGLE_CLOUD_PROJECT` ou `GOOGLE_CLOUD_PROJECT_ID` sur l’hôte de la gateway - Cela stocke les tokens OAuth dans les profils d’authentification sur l’hôte Gateway. Détails : [Model providers](/fr/concepts/model-providers). + Cela stocke les tokens OAuth dans les profils d’authentification sur l’hôte de la gateway. Détails : [Fournisseurs de modèles](/fr/concepts/model-providers). - - En général, non. OpenClaw a besoin d’un grand contexte et d’une sécurité forte ; les petits modèles tronquent et laissent fuiter. Si vous devez vraiment en utiliser un, exécutez localement la **plus grosse** version du modèle possible (LM Studio) et consultez [/gateway/local-models](/fr/gateway/local-models). Les modèles plus petits/quantifiés augmentent le risque d’injection de prompt — voir [Security](/fr/gateway/security). + + En général non. OpenClaw a besoin d’un grand contexte et d’une sécurité forte ; les petites cartes tronquent et laissent fuiter. Si vous y êtes obligé, exécutez localement la version de modèle **la plus grande** possible (LM Studio) et consultez [/gateway/local-models](/fr/gateway/local-models). Les modèles plus petits/quantifiés augmentent le risque d’injection de prompt — voir [Sécurité](/fr/gateway/security). - - Choisissez des endpoints épinglés à une région. OpenRouter expose des options hébergées aux États-Unis pour MiniMax, Kimi et GLM ; choisissez la variante hébergée aux États-Unis pour garder les données dans la région. Vous pouvez toujours lister Anthropic/OpenAI à côté en utilisant `models.mode: "merge"` afin que les modèles de secours restent disponibles tout en respectant le fournisseur régional que vous sélectionnez. + + Choisissez des endpoints épinglés à une région. OpenRouter expose des options hébergées aux États-Unis pour MiniMax, Kimi et GLM ; choisissez la variante hébergée aux États-Unis pour conserver les données dans cette région. Vous pouvez toujours lister Anthropic/OpenAI à côté de ceux-ci en utilisant `models.mode: "merge"` afin que les secours restent disponibles tout en respectant le fournisseur régional que vous sélectionnez. - + Non. OpenClaw fonctionne sur macOS ou Linux (Windows via WSL2). Un Mac mini est facultatif — certaines personnes - en achètent un comme hôte toujours actif, mais un petit VPS, un serveur domestique ou une machine de type Raspberry Pi convient aussi. + en achètent un comme hôte toujours allumé, mais un petit VPS, un serveur domestique ou une machine de classe Raspberry Pi convient aussi. - Vous n’avez besoin d’un Mac **que pour les outils réservés à macOS**. Pour iMessage, utilisez [BlueBubbles](/fr/channels/bluebubbles) (recommandé) — le serveur BlueBubbles s’exécute sur n’importe quel Mac, et le Gateway peut s’exécuter sur Linux ou ailleurs. Si vous voulez d’autres outils réservés à macOS, exécutez le Gateway sur un Mac ou associez un Node macOS. + Vous n’avez besoin d’un Mac **que pour les outils réservés à macOS**. Pour iMessage, utilisez [BlueBubbles](/fr/channels/bluebubbles) (recommandé) — le serveur BlueBubbles fonctionne sur n’importe quel Mac, et la Gateway peut fonctionner sur Linux ou ailleurs. Si vous voulez d’autres outils réservés à macOS, exécutez la Gateway sur un Mac ou associez un node macOS. Documentation : [BlueBubbles](/fr/channels/bluebubbles), [Nodes](/fr/nodes), [Mode distant Mac](/fr/platforms/mac/remote). - Vous avez besoin d’**un appareil macOS** connecté à Messages. Il ne s’agit **pas forcément d’un Mac mini** — - n’importe quel Mac convient. **Utilisez [BlueBubbles](/fr/channels/bluebubbles)** (recommandé) pour iMessage — le serveur BlueBubbles s’exécute sur macOS, tandis que le Gateway peut s’exécuter sur Linux ou ailleurs. + Vous avez besoin d’**un appareil macOS** connecté à Messages. Ce n’est **pas nécessairement** un Mac mini — + n’importe quel Mac convient. **Utilisez [BlueBubbles](/fr/channels/bluebubbles)** (recommandé) pour iMessage — le serveur BlueBubbles fonctionne sur macOS, tandis que la Gateway peut fonctionner sur Linux ou ailleurs. Configurations courantes : - - Exécuter le Gateway sur Linux/VPS, et exécuter le serveur BlueBubbles sur n’importe quel Mac connecté à Messages. - - Tout exécuter sur le Mac si vous voulez la configuration la plus simple sur une seule machine. + - Exécutez la Gateway sur Linux/VPS et le serveur BlueBubbles sur n’importe quel Mac connecté à Messages. + - Exécutez tout sur le Mac si vous voulez la configuration sur une seule machine la plus simple. Documentation : [BlueBubbles](/fr/channels/bluebubbles), [Nodes](/fr/nodes), [Mode distant Mac](/fr/platforms/mac/remote). @@ -749,33 +747,33 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. - Oui. Le **Mac mini peut exécuter le Gateway**, et votre MacBook Pro peut s’y connecter comme - **Node** (appareil compagnon). Les Nodes n’exécutent pas le Gateway — ils fournissent des - capacités supplémentaires comme l’écran/la caméra/le canevas et `system.run` sur cet appareil. + Oui. Le **Mac mini peut exécuter la Gateway**, et votre MacBook Pro peut se connecter comme + **node** (appareil compagnon). Les nodes n’exécutent pas la Gateway — ils fournissent des + capacités supplémentaires comme l’écran/la caméra/le canvas et `system.run` sur cet appareil. - Modèle courant : + Schéma courant : - - Gateway sur le Mac mini (toujours actif). - - Le MacBook Pro exécute l’application macOS ou un hôte Node et s’associe au Gateway. + - Gateway sur le Mac mini (toujours allumé). + - Le MacBook Pro exécute l’application macOS ou un hôte node et s’associe à la Gateway. - Utilisez `openclaw nodes status` / `openclaw nodes list` pour le voir. - Documentation : [Nodes](/fr/nodes), [Nodes CLI](/cli/nodes). + Documentation : [Nodes](/fr/nodes), [CLI des Nodes](/cli/nodes). - Bun est **non recommandé**. Nous observons des bogues d’exécution, surtout avec WhatsApp et Telegram. - Utilisez **Node** pour des Gateways stables. + Bun n’est **pas recommandé**. Nous constatons des bugs d’exécution, surtout avec WhatsApp et Telegram. + Utilisez **Node** pour des gateways stables. - Si vous voulez malgré tout expérimenter avec Bun, faites-le sur un Gateway hors production + Si vous voulez tout de même expérimenter avec Bun, faites-le sur une gateway non destinée à la production sans WhatsApp/Telegram. - `channels.telegram.allowFrom` correspond à **l’identifiant utilisateur Telegram de l’expéditeur humain** (numérique). Ce n’est pas le nom d’utilisateur du bot. + `channels.telegram.allowFrom` correspond à **l’ID utilisateur Telegram de l’expéditeur humain** (numérique). Ce n’est pas le nom d’utilisateur du bot. - L’onboarding accepte une entrée `@username` et la résout en identifiant numérique, mais l’autorisation OpenClaw utilise uniquement des identifiants numériques. + La configuration demande uniquement des ID utilisateur numériques. Si vous avez déjà des entrées héritées `@username` dans la configuration, `openclaw doctor --fix` peut essayer de les résoudre. Plus sûr (sans bot tiers) : @@ -794,11 +792,11 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. - Oui, via le **routage multi-agent**. Associez le **DM** WhatsApp de chaque expéditeur (pair `kind: "direct"`, expéditeur E.164 comme `+15551234567`) à un `agentId` différent, afin que chaque personne dispose de son propre espace de travail et de son propre magasin de sessions. Les réponses proviennent toujours du **même compte WhatsApp**, et le contrôle d’accès DM (`channels.whatsapp.dmPolicy` / `channels.whatsapp.allowFrom`) est global par compte WhatsApp. Voir [Routage multi-agent](/fr/concepts/multi-agent) et [WhatsApp](/fr/channels/whatsapp). + Oui, via le **routage multi-agent**. Associez le **DM** WhatsApp de chaque expéditeur (pair `kind: "direct"`, expéditeur E.164 comme `+15551234567`) à un `agentId` différent, afin que chaque personne dispose de son propre espace de travail et magasin de sessions. Les réponses proviennent toujours du **même compte WhatsApp**, et le contrôle d’accès DM (`channels.whatsapp.dmPolicy` / `channels.whatsapp.allowFrom`) est global par compte WhatsApp. Voir [Routage multi-agent](/fr/concepts/multi-agent) et [WhatsApp](/fr/channels/whatsapp). - - Oui. Utilisez le routage multi-agent : donnez à chaque agent son propre modèle par défaut, puis associez les routes entrantes (compte fournisseur ou pairs spécifiques) à chaque agent. Un exemple de configuration se trouve dans [Routage multi-agent](/fr/concepts/multi-agent). Voir aussi [Models](/fr/concepts/models) et [Configuration](/fr/gateway/configuration). + + Oui. Utilisez le routage multi-agent : donnez à chaque agent son propre modèle par défaut, puis associez les routes entrantes (compte fournisseur ou pairs spécifiques) à chaque agent. Un exemple de configuration se trouve dans [Routage multi-agent](/fr/concepts/multi-agent). Voir aussi [Modèles](/fr/concepts/models) et [Configuration](/fr/gateway/configuration). @@ -811,23 +809,23 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. brew install ``` - Si vous exécutez OpenClaw via systemd, assurez-vous que le PATH du service inclut `/home/linuxbrew/.linuxbrew/bin` (ou votre préfixe brew) afin que les outils installés avec `brew` soient résolus dans les shells non connectés. - Les builds récentes ajoutent aussi en préfixe les répertoires bin utilisateur courants sur les services Linux systemd (par exemple `~/.local/bin`, `~/.npm-global/bin`, `~/.local/share/pnpm`, `~/.bun/bin`) et respectent `PNPM_HOME`, `NPM_CONFIG_PREFIX`, `BUN_INSTALL`, `VOLTA_HOME`, `ASDF_DATA_DIR`, `NVM_DIR` et `FNM_DIR` lorsqu’ils sont définis. + Si vous exécutez OpenClaw via systemd, assurez-vous que le PATH du service inclut `/home/linuxbrew/.linuxbrew/bin` (ou votre préfixe brew) afin que les outils installés via `brew` soient résolus dans les shells non interactifs. + Les versions récentes ajoutent aussi en préfixe les répertoires bin utilisateur courants sur les services Linux systemd (par exemple `~/.local/bin`, `~/.npm-global/bin`, `~/.local/share/pnpm`, `~/.bun/bin`) et respectent `PNPM_HOME`, `NPM_CONFIG_PREFIX`, `BUN_INSTALL`, `VOLTA_HOME`, `ASDF_DATA_DIR`, `NVM_DIR` et `FNM_DIR` lorsqu’ils sont définis. - - - **Installation hackable (git) :** checkout complet des sources, modifiable, idéal pour les contributeurs. + + - **Installation modifiable (git) :** copie complète des sources, modifiable, idéale pour les contributeurs. Vous exécutez les builds localement et pouvez corriger le code/la documentation. - - **Installation npm :** installation globale de la CLI, sans dépôt, idéale pour « l’exécuter simplement ». - Les mises à jour proviennent des dist-tags npm. + - **npm install :** installation globale de la CLI, sans dépôt, idéale pour « l’exécuter simplement ». + Les mises à jour proviennent des npm dist-tags. Documentation : [Premiers pas](/fr/start/getting-started), [Mise à jour](/fr/install/updating). - - Oui. Installez l’autre variante, puis exécutez Doctor afin que le service Gateway pointe vers le nouveau point d’entrée. + + Oui. Installez l’autre variante, puis exécutez Doctor afin que le service gateway pointe vers le nouvel entrypoint. Cela **ne supprime pas vos données** — cela change uniquement l’installation du code OpenClaw. Votre état (`~/.openclaw`) et votre espace de travail (`~/.openclaw/workspace`) restent intacts. @@ -850,48 +848,48 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. openclaw gateway restart ``` - Doctor détecte une incohérence entre le point d’entrée du service Gateway et l’installation actuelle, et propose de réécrire la configuration du service pour qu’elle corresponde à l’installation en cours (utilisez `--repair` dans l’automatisation). + Doctor détecte un décalage entre l’entrypoint du service gateway et l’installation actuelle, et propose de réécrire la configuration du service pour qu’elle corresponde à l’installation en cours (utilisez `--repair` en automatisation). - Pour les conseils de sauvegarde, voir [Stratégie de sauvegarde](#where-things-live-on-disk). + Conseils de sauvegarde : voir [Stratégie de sauvegarde](#where-things-live-on-disk). - + Réponse courte : **si vous voulez une fiabilité 24 h/24 et 7 j/7, utilisez un VPS**. Si vous voulez le - moins de friction possible et que les mises en veille/redémarrages ne vous dérangent pas, exécutez-le en local. + moins de friction possible et que les mises en veille/redémarrages ne vous dérangent pas, exécutez-la en local. - **Ordinateur portable (Gateway local)** + **Ordinateur portable (Gateway locale)** - - **Avantages :** pas de coût serveur, accès direct aux fichiers locaux, fenêtre de navigateur visible en direct. - - **Inconvénients :** mise en veille/pertes réseau = déconnexions, mises à jour/redémarrages de l’OS interrompent le service, la machine doit rester éveillée. + - **Avantages :** pas de coût serveur, accès direct aux fichiers locaux, fenêtre de navigateur visible. + - **Inconvénients :** veille/pertes réseau = déconnexions, mises à jour/redémarrages de l’OS interrompent, la machine doit rester éveillée. **VPS / cloud** - - **Avantages :** toujours actif, réseau stable, pas de problème de mise en veille de l’ordinateur portable, plus simple à maintenir en fonctionnement. - - **Inconvénients :** souvent exécuté en mode headless (utilisez des captures d’écran), accès uniquement distant aux fichiers, vous devez utiliser SSH pour les mises à jour. + - **Avantages :** toujours actif, réseau stable, pas de problème de veille d’ordinateur portable, plus facile à maintenir en fonctionnement. + - **Inconvénients :** souvent headless (utilisez des captures d’écran), accès aux fichiers uniquement à distance, vous devez utiliser SSH pour les mises à jour. - **Remarque spécifique à OpenClaw :** WhatsApp, Telegram, Slack, Mattermost et Discord fonctionnent tous très bien depuis un VPS. Le seul vrai compromis est **navigateur headless** contre fenêtre visible. Voir [Browser](/fr/tools/browser). + **Remarque spécifique à OpenClaw :** WhatsApp/Telegram/Slack/Mattermost/Discord fonctionnent tous très bien depuis un VPS. Le seul véritable compromis est **navigateur headless** contre fenêtre visible. Voir [Navigateur](/fr/tools/browser). - **Choix recommandé par défaut :** un VPS si vous avez déjà eu des déconnexions de Gateway. Le local est idéal lorsque vous utilisez activement le Mac et voulez un accès aux fichiers locaux ou une automatisation d’interface avec un navigateur visible. + **Recommandation par défaut :** VPS si vous avez déjà eu des déconnexions de gateway. Le local est idéal lorsque vous utilisez activement le Mac et souhaitez un accès aux fichiers locaux ou de l’automatisation UI avec un navigateur visible. Ce n’est pas obligatoire, mais **recommandé pour la fiabilité et l’isolation**. - - **Hôte dédié (VPS/Mac mini/Pi) :** toujours actif, moins d’interruptions dues aux mises en veille/redémarrages, permissions plus propres, plus simple à maintenir en fonctionnement. + - **Hôte dédié (VPS/Mac mini/Pi) :** toujours actif, moins d’interruptions dues à la veille/aux redémarrages, permissions plus propres, plus facile à maintenir en fonctionnement. - **Ordinateur portable/de bureau partagé :** tout à fait acceptable pour les tests et l’usage actif, mais attendez-vous à des pauses lorsque la machine se met en veille ou se met à jour. - Si vous voulez le meilleur des deux mondes, gardez le Gateway sur un hôte dédié et associez votre ordinateur portable comme **Node** pour les outils locaux d’écran/caméra/exec. Voir [Nodes](/fr/nodes). - Pour les recommandations de sécurité, lisez [Security](/fr/gateway/security). + Si vous voulez le meilleur des deux mondes, gardez la Gateway sur un hôte dédié et associez votre ordinateur portable comme **node** pour les outils locaux d’écran/caméra/exec. Voir [Nodes](/fr/nodes). + Pour les conseils de sécurité, lisez [Sécurité](/fr/gateway/security). - OpenClaw est léger. Pour un Gateway de base + un canal de chat : + OpenClaw est léger. Pour une Gateway de base + un canal de chat : - - **Minimum absolu :** 1 vCPU, 1GB de RAM, ~500MB de disque. - - **Recommandé :** 1-2 vCPU, 2GB de RAM ou plus pour avoir de la marge (journaux, médias, canaux multiples). Les outils Node et l’automatisation navigateur peuvent être gourmands en ressources. + - **Minimum absolu :** 1 vCPU, 1 Go de RAM, ~500 Mo de disque. + - **Recommandé :** 1 à 2 vCPU, 2 Go de RAM ou plus pour de la marge (journaux, médias, plusieurs canaux). Les outils Node et l’automatisation du navigateur peuvent être gourmands en ressources. OS : utilisez **Ubuntu LTS** (ou tout Debian/Ubuntu moderne). Le parcours d’installation Linux y est le mieux testé. @@ -900,13 +898,13 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. - Oui. Traitez une VM comme un VPS : elle doit être toujours active, accessible, et disposer de suffisamment de - RAM pour le Gateway et tous les canaux que vous activez. + Oui. Traitez une VM comme un VPS : elle doit être toujours allumée, joignable et disposer de suffisamment de + RAM pour la Gateway et tous les canaux que vous activez. Recommandations de base : - - **Minimum absolu :** 1 vCPU, 1GB de RAM. - - **Recommandé :** 2GB de RAM ou plus si vous exécutez plusieurs canaux, de l’automatisation navigateur ou des outils média. + - **Minimum absolu :** 1 vCPU, 1 Go de RAM. + - **Recommandé :** 2 Go de RAM ou plus si vous exécutez plusieurs canaux, l’automatisation du navigateur ou des outils multimédias. - **OS :** Ubuntu LTS ou un autre Debian/Ubuntu moderne. Si vous êtes sous Windows, **WSL2 est la configuration de type VM la plus simple** et offre la meilleure @@ -920,83 +918,82 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. - OpenClaw est un assistant IA personnel que vous exécutez sur vos propres appareils. Il répond sur les surfaces de messagerie que vous utilisez déjà (WhatsApp, Telegram, Slack, Mattermost, Discord, Google Chat, Signal, iMessage, WebChat, ainsi que des plugins de canal intégrés comme QQ Bot) et peut aussi gérer la voix + un Canvas en direct sur les plateformes prises en charge. Le **Gateway** est le plan de contrôle toujours actif ; l’assistant est le produit. + OpenClaw est un assistant IA personnel que vous exécutez sur vos propres appareils. Il répond sur les surfaces de messagerie que vous utilisez déjà (WhatsApp, Telegram, Slack, Mattermost, Discord, Google Chat, Signal, iMessage, WebChat, ainsi que des plugins de canal fournis comme QQ Bot) et peut aussi offrir la voix + un Canvas live sur les plateformes prises en charge. La **Gateway** est le plan de contrôle toujours actif ; l’assistant est le produit. OpenClaw n’est pas « juste un wrapper Claude ». C’est un **plan de contrôle local-first** qui vous permet d’exécuter un - assistant performant sur **votre propre matériel**, accessible depuis les applications de chat que vous utilisez déjà, avec - des sessions avec état, de la mémoire et des outils — sans céder le contrôle de vos flux de travail à un + assistant puissant sur **votre propre matériel**, joignable depuis les applications de chat que vous utilisez déjà, avec + des sessions avec état, de la mémoire et des outils — sans céder le contrôle de vos workflows à un SaaS hébergé. Points forts : - - **Vos appareils, vos données :** exécutez le Gateway où vous voulez (Mac, Linux, VPS) et gardez l’ - espace de travail + l’historique des sessions en local. + - **Vos appareils, vos données :** exécutez la Gateway où vous voulez (Mac, Linux, VPS) et conservez l’espace de travail + l’historique des sessions en local. - **De vrais canaux, pas un bac à sable web :** WhatsApp/Telegram/Slack/Discord/Signal/iMessage/etc., - ainsi que la voix mobile et Canvas sur les plateformes prises en charge. - - **Indépendant du modèle :** utilisez Anthropic, OpenAI, MiniMax, OpenRouter, etc., avec routage + plus la voix mobile et Canvas sur les plateformes prises en charge. + - **Agnostique vis-à-vis des modèles :** utilisez Anthropic, OpenAI, MiniMax, OpenRouter, etc., avec routage par agent et basculement. - - **Option 100 % locale :** exécutez des modèles locaux afin que **toutes les données puissent rester sur votre appareil** si vous le souhaitez. - - **Routage multi-agent :** séparez les agents par canal, compte ou tâche, chacun avec son propre - espace de travail et ses valeurs par défaut. - - **Open source et hackable :** inspectez, étendez et auto-hébergez sans verrouillage fournisseur. + - **Option 100 % locale :** exécutez des modèles locaux pour que **toutes les données puissent rester sur votre appareil** si vous le souhaitez. + - **Routage multi-agent :** agents séparés par canal, compte ou tâche, chacun avec son propre + espace de travail et ses propres valeurs par défaut. + - **Open source et modifiable :** inspectez, étendez et auto-hébergez sans verrouillage fournisseur. Documentation : [Gateway](/fr/gateway), [Canaux](/fr/channels), [Multi-agent](/fr/concepts/multi-agent), - [Memory](/fr/concepts/memory). + [Mémoire](/fr/concepts/memory). - - Bonnes premières idées de projet : + + Bons premiers projets : - Créer un site web (WordPress, Shopify ou un simple site statique). - Prototyper une application mobile (plan, écrans, plan API). - - Organiser fichiers et dossiers (nettoyage, nommage, étiquetage). - - Connecter Gmail et automatiser les résumés ou relances. + - Organiser les fichiers et dossiers (nettoyage, nommage, étiquetage). + - Connecter Gmail et automatiser les résumés ou les suivis. - Il peut gérer de grosses tâches, mais il fonctionne mieux lorsque vous les divisez en phases et + Il peut gérer de grosses tâches, mais fonctionne mieux lorsque vous les découpez en phases et utilisez des sous-agents pour le travail en parallèle. - Les gains quotidiens ressemblent généralement à ceci : + Les bénéfices au quotidien ressemblent généralement à ceci : - **Briefings personnels :** résumés de la boîte de réception, du calendrier et des actualités qui vous intéressent. - - **Recherche et rédaction :** recherche rapide, résumés et premières versions pour des e-mails ou des documents. - - **Rappels et relances :** nudges et checklists pilotés par Cron ou Heartbeat. - - **Automatisation du navigateur :** remplissage de formulaires, collecte de données et répétition de tâches web. - - **Coordination inter-appareils :** envoyez une tâche depuis votre téléphone, laissez le Gateway l’exécuter sur un serveur, puis récupérez le résultat dans le chat. + - **Recherche et rédaction :** recherche rapide, résumés et premières versions d’e-mails ou de documents. + - **Rappels et suivis :** relances et checklists pilotées par cron ou Heartbeat. + - **Automatisation du navigateur :** remplir des formulaires, collecter des données et répéter des tâches web. + - **Coordination inter-appareils :** envoyez une tâche depuis votre téléphone, laissez la Gateway l’exécuter sur un serveur et récupérez le résultat dans le chat. - Oui pour la **recherche, la qualification et la rédaction**. Il peut analyser des sites, constituer des shortlists, - résumer des prospects et rédiger des brouillons de messages de prospection ou de texte publicitaire. + Oui pour la **recherche, la qualification et la rédaction**. Il peut analyser des sites, créer des listes restreintes, + résumer des prospects et rédiger des brouillons de messages de prospection ou de publicités. - Pour la **prospection ou les campagnes publicitaires**, gardez un humain dans la boucle. Évitez le spam, respectez les lois locales et - les politiques des plateformes, et relisez tout avant envoi. Le schéma le plus sûr consiste à laisser - OpenClaw rédiger, puis à valider vous-même. + Pour la **prospection ou les campagnes publicitaires**, gardez un humain dans la boucle. Évitez + le spam, respectez les lois locales et les politiques des plateformes, et relisez tout avant envoi. Le schéma + le plus sûr consiste à laisser OpenClaw rédiger puis à faire approuver. - Documentation : [Security](/fr/gateway/security). + Documentation : [Sécurité](/fr/gateway/security). - OpenClaw est un **assistant personnel** et une couche de coordination, pas un remplaçant d’IDE. Utilisez - Claude Code ou Codex pour la boucle de codage direct la plus rapide dans un dépôt. Utilisez OpenClaw lorsque vous + OpenClaw est un **assistant personnel** et une couche de coordination, pas un remplacement d’IDE. Utilisez + Claude Code ou Codex pour la boucle de développement direct la plus rapide dans un dépôt. Utilisez OpenClaw lorsque vous voulez une mémoire durable, un accès inter-appareils et une orchestration d’outils. Avantages : - - **Mémoire + espace de travail persistants** entre les sessions - - **Accès multi-plateforme** (WhatsApp, Telegram, TUI, WebChat) + - **Mémoire persistante + espace de travail** entre les sessions + - **Accès multiplateforme** (WhatsApp, Telegram, TUI, WebChat) - **Orchestration d’outils** (navigateur, fichiers, planification, hooks) - - **Gateway toujours actif** (exécution sur un VPS, interaction depuis n’importe où) + - **Gateway toujours active** (exécution sur un VPS, interaction depuis n’importe où) - **Nodes** pour navigateur/écran/caméra/exec en local - Démonstration : [https://openclaw.ai/showcase](https://openclaw.ai/showcase) + Présentation : [https://openclaw.ai/showcase](https://openclaw.ai/showcase) @@ -1005,68 +1002,68 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. - Utilisez des remplacements gérés au lieu de modifier la copie du dépôt. Placez vos changements dans `~/.openclaw/skills//SKILL.md` (ou ajoutez un dossier via `skills.load.extraDirs` dans `~/.openclaw/openclaw.json`). L’ordre de priorité est `/skills` → `/.agents/skills` → `~/.agents/skills` → `~/.openclaw/skills` → intégré → `skills.load.extraDirs`, donc les remplacements gérés prennent toujours le dessus sur les Skills intégrées sans toucher à git. Si vous avez besoin que la Skill soit installée globalement mais visible seulement pour certains agents, conservez la copie partagée dans `~/.openclaw/skills` et contrôlez la visibilité avec `agents.defaults.skills` et `agents.list[].skills`. Seules les modifications dignes d’être intégrées en amont doivent vivre dans le dépôt et être proposées en PR. + Utilisez des surcharges gérées au lieu de modifier la copie du dépôt. Placez vos changements dans `~/.openclaw/skills//SKILL.md` (ou ajoutez un dossier via `skills.load.extraDirs` dans `~/.openclaw/openclaw.json`). L’ordre de priorité est `/skills` → `/.agents/skills` → `~/.agents/skills` → `~/.openclaw/skills` → intégré → `skills.load.extraDirs`, donc les surcharges gérées restent prioritaires sur les Skills intégrés sans toucher à git. Si vous avez besoin que le skill soit installé globalement mais visible uniquement pour certains agents, gardez la copie partagée dans `~/.openclaw/skills` et contrôlez la visibilité avec `agents.defaults.skills` et `agents.list[].skills`. Seules les modifications qui méritent d’être remontées devraient vivre dans le dépôt et être envoyées en PR. - Oui. Ajoutez des répertoires supplémentaires via `skills.load.extraDirs` dans `~/.openclaw/openclaw.json` (priorité la plus basse). L’ordre de priorité par défaut est `/skills` → `/.agents/skills` → `~/.agents/skills` → `~/.openclaw/skills` → intégré → `skills.load.extraDirs`. `clawhub` installe dans `./skills` par défaut, que OpenClaw traite comme `/skills` à la session suivante. Si la Skill ne doit être visible que pour certains agents, combinez cela avec `agents.defaults.skills` ou `agents.list[].skills`. + Oui. Ajoutez des répertoires supplémentaires via `skills.load.extraDirs` dans `~/.openclaw/openclaw.json` (priorité la plus basse). L’ordre de priorité par défaut est `/skills` → `/.agents/skills` → `~/.agents/skills` → `~/.openclaw/skills` → intégré → `skills.load.extraDirs`. `clawhub` s’installe dans `./skills` par défaut, qu’OpenClaw traite comme `/skills` à la session suivante. Si le skill ne doit être visible que pour certains agents, combinez cela avec `agents.defaults.skills` ou `agents.list[].skills`. Aujourd’hui, les schémas pris en charge sont : - **Tâches Cron** : les tâches isolées peuvent définir une surcharge `model` par tâche. - - **Sous-agents** : routez les tâches vers des agents séparés ayant différents modèles par défaut. + - **Sous-agents** : routez les tâches vers des agents séparés avec différents modèles par défaut. - **Changement à la demande** : utilisez `/model` pour changer le modèle de la session en cours à tout moment. - Voir [Tâches Cron](/fr/automation/cron-jobs), [Routage multi-agent](/fr/concepts/multi-agent), et [Commandes slash](/fr/tools/slash-commands). + Voir [Tâches Cron](/fr/automation/cron-jobs), [Routage multi-agent](/fr/concepts/multi-agent) et [Commandes slash](/fr/tools/slash-commands). - + Utilisez des **sous-agents** pour les tâches longues ou parallèles. Les sous-agents s’exécutent dans leur propre session, renvoient un résumé et gardent votre chat principal réactif. - Demandez à votre bot de « créer un sous-agent pour cette tâche » ou utilisez `/subagents`. - Utilisez `/status` dans le chat pour voir ce que fait le Gateway en ce moment (et s’il est occupé). + Demandez à votre bot de « lancer un sous-agent pour cette tâche » ou utilisez `/subagents`. + Utilisez `/status` dans le chat pour voir ce que la Gateway est en train de faire en ce moment (et si elle est occupée). - Conseil sur les tokens : les longues tâches et les sous-agents consomment tous deux des tokens. Si le coût vous préoccupe, définissez un + Conseil sur les tokens : les tâches longues et les sous-agents consomment tous deux des tokens. Si le coût vous préoccupe, définissez un modèle moins cher pour les sous-agents via `agents.defaults.subagents.model`. - Documentation : [Sous-agents](/fr/tools/subagents), [Tâches d’arrière-plan](/fr/automation/tasks). + Documentation : [Sous-agents](/fr/tools/subagents), [Tâches en arrière-plan](/fr/automation/tasks). - Utilisez des liaisons de fil. Vous pouvez lier un fil Discord à un sous-agent ou à une cible de session afin que les messages de suivi dans ce fil restent sur cette session liée. + Utilisez les liaisons de fil. Vous pouvez lier un fil Discord à un sous-agent ou à une cible de session afin que les messages de suivi dans ce fil restent sur cette session liée. Flux de base : - - Créez avec `sessions_spawn` en utilisant `thread: true` (et éventuellement `mode: "session"` pour un suivi persistant). + - Lancez avec `sessions_spawn` en utilisant `thread: true` (et éventuellement `mode: "session"` pour un suivi persistant). - Ou liez manuellement avec `/focus `. - Utilisez `/agents` pour inspecter l’état de la liaison. - - Utilisez `/session idle ` et `/session max-age ` pour contrôler le retrait automatique du focus. + - Utilisez `/session idle ` et `/session max-age ` pour contrôler la perte automatique du focus. - Utilisez `/unfocus` pour détacher le fil. Configuration requise : - - Valeurs globales par défaut : `session.threadBindings.enabled`, `session.threadBindings.idleHours`, `session.threadBindings.maxAgeHours`. + - Valeurs par défaut globales : `session.threadBindings.enabled`, `session.threadBindings.idleHours`, `session.threadBindings.maxAgeHours`. - Surcharges Discord : `channels.discord.threadBindings.enabled`, `channels.discord.threadBindings.idleHours`, `channels.discord.threadBindings.maxAgeHours`. - - Liaison automatique à la création : définissez `channels.discord.threadBindings.spawnSubagentSessions: true`. + - Liaison automatique au lancement : définissez `channels.discord.threadBindings.spawnSubagentSessions: true`. Documentation : [Sous-agents](/fr/tools/subagents), [Discord](/fr/channels/discord), [Référence de configuration](/fr/gateway/configuration-reference), [Commandes slash](/fr/tools/slash-commands). - + Vérifiez d’abord la route du demandeur résolue : - - La distribution du sous-agent en mode completion préfère tout fil ou route de conversation lié lorsqu’il en existe un. - - Si l’origine de fin ne contient qu’un canal, OpenClaw se rabat sur la route stockée de la session du demandeur (`lastChannel` / `lastTo` / `lastAccountId`) afin que la livraison directe puisse quand même réussir. - - Si ni une route liée ni une route stockée exploitable n’existent, la livraison directe peut échouer et le résultat retombe alors sur une livraison en file d’attente de session au lieu d’être immédiatement publié dans le chat. - - Des cibles invalides ou obsolètes peuvent encore forcer le retour à la file d’attente ou l’échec final de la livraison. - - Si la dernière réponse d’assistant visible de l’enfant est exactement le token silencieux `NO_REPLY` / `no_reply`, ou exactement `ANNOUNCE_SKIP`, OpenClaw supprime intentionnellement l’annonce au lieu de publier une progression antérieure devenue obsolète. - - Si l’enfant a expiré après seulement des appels d’outils, l’annonce peut condenser cela en un court résumé de progression partielle au lieu de rejouer la sortie brute des outils. + - La livraison de sous-agent en mode completion privilégie tout fil ou toute route de conversation liée lorsqu’il en existe un. + - Si l’origine de completion ne contient qu’un canal, OpenClaw revient à la route stockée de la session du demandeur (`lastChannel` / `lastTo` / `lastAccountId`) afin que la livraison directe puisse tout de même réussir. + - S’il n’existe ni route liée ni route stockée exploitable, la livraison directe peut échouer et le résultat revient alors à une livraison en file d’attente de session au lieu d’être publié immédiatement dans le chat. + - Des cibles invalides ou obsolètes peuvent encore forcer un retour à la file d’attente ou un échec final de livraison. + - Si la dernière réponse visible de l’assistant enfant est exactement le token silencieux `NO_REPLY` / `no_reply`, ou exactement `ANNOUNCE_SKIP`, OpenClaw supprime intentionnellement l’annonce au lieu de publier une progression antérieure devenue obsolète. + - Si l’enfant a expiré après seulement des appels d’outils, l’annonce peut réduire cela à un court résumé de progression partielle au lieu de rejouer la sortie brute des outils. Débogage : @@ -1074,19 +1071,19 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. openclaw tasks show ``` - Documentation : [Sous-agents](/fr/tools/subagents), [Tâches d’arrière-plan](/fr/automation/tasks), [Outil de session](/fr/concepts/session-tool). + Documentation : [Sous-agents](/fr/tools/subagents), [Tâches en arrière-plan](/fr/automation/tasks), [Outil de session](/fr/concepts/session-tool). - Cron s’exécute dans le processus Gateway. Si le Gateway ne fonctionne pas en continu, + Cron s’exécute à l’intérieur du processus Gateway. Si la Gateway ne fonctionne pas en continu, les tâches planifiées ne s’exécuteront pas. Liste de vérification : - - Vérifiez que cron est activé (`cron.enabled`) et que `OPENCLAW_SKIP_CRON` n’est pas défini. - - Vérifiez que le Gateway fonctionne 24 h/24 et 7 j/7 (sans mise en veille/redémarrages). - - Vérifiez les paramètres de fuseau horaire pour la tâche (`--tz` par rapport au fuseau horaire de l’hôte). + - Confirmez que Cron est activé (`cron.enabled`) et que `OPENCLAW_SKIP_CRON` n’est pas défini. + - Vérifiez que la Gateway fonctionne 24 h/24 et 7 j/7 (pas de veille/redémarrage). + - Vérifiez les paramètres de fuseau horaire pour la tâche (`--tz` vs fuseau horaire de l’hôte). Débogage : @@ -1095,22 +1092,22 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. openclaw cron runs --id --limit 50 ``` - Documentation : [Tâches Cron](/fr/automation/cron-jobs), [Automatisation & tâches](/fr/automation). + Documentation : [Tâches Cron](/fr/automation/cron-jobs), [Automatisation et tâches](/fr/automation). - Vérifiez d’abord le mode de distribution : + Vérifiez d’abord le mode de livraison : - `--no-deliver` / `delivery.mode: "none"` signifie qu’aucun message externe n’est attendu. - - Une cible d’annonce absente ou invalide (`channel` / `to`) signifie que l’exécuteur a ignoré la distribution sortante. - - Des échecs d’authentification du canal (`unauthorized`, `Forbidden`) signifient que l’exécuteur a essayé de distribuer, mais que les identifiants l’en ont empêché. - - Un résultat isolé silencieux (`NO_REPLY` / `no_reply` uniquement) est traité comme intentionnellement non distribuable ; l’exécuteur supprime donc aussi la distribution de secours en file d’attente. + - Une cible d’annonce manquante ou invalide (`channel` / `to`) signifie que le runner a ignoré la livraison sortante. + - Des échecs d’authentification de canal (`unauthorized`, `Forbidden`) signifient que le runner a tenté de livrer, mais que les identifiants l’ont empêché. + - Un résultat isolé silencieux (`NO_REPLY` / `no_reply` uniquement) est traité comme intentionnellement non livrable, donc le runner supprime également la livraison de secours en file d’attente. - Pour les tâches Cron isolées, l’exécuteur prend en charge la distribution finale. L’agent est censé - renvoyer un résumé en texte brut que l’exécuteur enverra. `--no-deliver` conserve - ce résultat en interne ; cela ne permet pas à l’agent d’envoyer directement avec - l’outil de message à la place. + Pour les tâches Cron isolées, le runner gère la livraison finale. L’agent est censé + renvoyer un résumé en texte brut que le runner pourra envoyer. `--no-deliver` conserve + ce résultat en interne ; cela ne permet pas à l’agent d’envoyer directement à la place avec l’outil + de message. Débogage : @@ -1119,27 +1116,27 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. openclaw tasks show ``` - Documentation : [Tâches Cron](/fr/automation/cron-jobs), [Tâches d’arrière-plan](/fr/automation/tasks). + Documentation : [Tâches Cron](/fr/automation/cron-jobs), [Tâches en arrière-plan](/fr/automation/tasks). - Il s’agit généralement du chemin de changement de modèle en direct, pas d’une planification en double. + Il s’agit généralement du chemin live de changement de modèle, et non d’une planification en double. - Cron isolé peut persister un basculement de modèle d’exécution et réessayer lorsque l’exécution active - lève `LiveSessionModelSwitchError`. Le nouvel essai conserve le - fournisseur/modèle basculé, et si le basculement comportait une nouvelle surcharge de profil d’authentification, cron - la persiste aussi avant de réessayer. + Cron isolé peut persister un basculement de modèle à l’exécution et réessayer lorsque l’exécution + active déclenche `LiveSessionModelSwitchError`. Le nouvel essai conserve le + fournisseur/modèle basculé, et si le basculement comportait une nouvelle surcharge de profil d’authentification, Cron + la persiste également avant de réessayer. Règles de sélection associées : - - La surcharge de modèle du hook Gmail l’emporte en premier lorsqu’elle s’applique. + - La surcharge de modèle du hook Gmail l’emporte d’abord lorsqu’elle s’applique. - Ensuite, le `model` par tâche. - - Ensuite, toute surcharge de modèle de session cron stockée. - - Ensuite, la sélection normale du modèle de l’agent/par défaut. + - Ensuite, toute surcharge de modèle de session Cron stockée. + - Ensuite, la sélection normale du modèle d’agent/par défaut. - La boucle de réessai est bornée. Après la tentative initiale plus 2 réessais de basculement, - cron abandonne au lieu de boucler indéfiniment. + La boucle de nouvel essai est bornée. Après la tentative initiale plus 2 nouveaux essais de changement, + Cron abandonne au lieu de boucler indéfiniment. Débogage : @@ -1153,7 +1150,7 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. - Utilisez les commandes natives `openclaw skills` ou déposez des Skills dans votre espace de travail. L’interface Skills de macOS n’est pas disponible sur Linux. + Utilisez les commandes natives `openclaw skills` ou déposez des Skills dans votre espace de travail. L’UI Skills macOS n’est pas disponible sur Linux. Parcourez les Skills sur [https://clawhub.ai](https://clawhub.ai). ```bash @@ -1167,39 +1164,39 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. openclaw skills check ``` - L’installation native `openclaw skills install` écrit dans le répertoire actif `skills/` - de l’espace de travail. N’installez la CLI `clawhub` séparée que si vous voulez publier ou - synchroniser vos propres Skills. Pour des installations partagées entre agents, placez la Skill sous + `openclaw skills install` natif écrit dans le répertoire `skills/` + de l’espace de travail actif. Installez la CLI séparée `clawhub` uniquement si vous voulez publier ou + synchroniser vos propres Skills. Pour des installations partagées entre agents, placez le skill sous `~/.openclaw/skills` et utilisez `agents.defaults.skills` ou - `agents.list[].skills` si vous voulez limiter quels agents peuvent la voir. + `agents.list[].skills` si vous voulez limiter quels agents peuvent le voir. - Oui. Utilisez le planificateur du Gateway : + Oui. Utilisez le planificateur Gateway : - - **Tâches Cron** pour les tâches planifiées ou récurrentes (persistantes après redémarrage). + - **Tâches Cron** pour les tâches planifiées ou récurrentes (persistent après les redémarrages). - **Heartbeat** pour des vérifications périodiques de la « session principale ». - - **Tâches isolées** pour des agents autonomes qui publient des résumés ou livrent dans les chats. + - **Tâches isolées** pour des agents autonomes qui publient des résumés ou livrent vers des chats. - Documentation : [Tâches Cron](/fr/automation/cron-jobs), [Automatisation & tâches](/fr/automation), + Documentation : [Tâches Cron](/fr/automation/cron-jobs), [Automatisation et tâches](/fr/automation), [Heartbeat](/fr/gateway/heartbeat). - - Pas directement. Les Skills macOS sont conditionnées par `metadata.openclaw.os` ainsi que par les binaires requis, et les Skills n’apparaissent dans le prompt système que lorsqu’elles sont éligibles sur l’**hôte Gateway**. Sous Linux, les Skills réservées à `darwin` (comme `apple-notes`, `apple-reminders`, `things-mac`) ne se chargeront pas, sauf si vous contournez cette condition. + + Pas directement. Les Skills macOS sont contrôlés par `metadata.openclaw.os` ainsi que par les binaires requis, et les skills n’apparaissent dans le prompt système que lorsqu’ils sont éligibles sur l’**hôte Gateway**. Sur Linux, les skills réservés à `darwin` (comme `apple-notes`, `apple-reminders`, `things-mac`) ne se chargeront pas sauf si vous contournez ce filtrage. - Trois schémas pris en charge sont possibles : + Vous disposez de trois schémas pris en charge : - **Option A — exécuter le Gateway sur un Mac (le plus simple).** - Exécutez le Gateway là où les binaires macOS existent, puis connectez-vous depuis Linux en [mode distant](#gateway-ports-already-running-and-remote-mode) ou via Tailscale. Les Skills se chargent normalement puisque l’hôte Gateway est macOS. + **Option A - exécuter la Gateway sur un Mac (le plus simple).** + Exécutez la Gateway là où les binaires macOS existent, puis connectez-vous depuis Linux en [mode distant](#gateway-ports-already-running-and-remote-mode) ou via Tailscale. Les skills se chargent normalement parce que l’hôte Gateway est macOS. - **Option B — utiliser un Node macOS (sans SSH).** - Exécutez le Gateway sur Linux, associez un Node macOS (application de barre de menus), et définissez **Node Run Commands** sur « Always Ask » ou « Always Allow » sur le Mac. OpenClaw peut traiter les Skills réservées à macOS comme éligibles lorsque les binaires requis existent sur le Node. L’agent exécute alors ces Skills via l’outil `nodes`. Si vous choisissez « Always Ask », approuver « Always Allow » dans l’invite ajoute cette commande à la liste d’autorisation. + **Option B - utiliser un node macOS (sans SSH).** + Exécutez la Gateway sur Linux, associez un node macOS (application de barre de menus) et réglez **Node Run Commands** sur « Always Ask » ou « Always Allow » sur le Mac. OpenClaw peut traiter les Skills réservés à macOS comme éligibles lorsque les binaires requis existent sur le node. L’agent exécute ces skills via l’outil `nodes`. Si vous choisissez « Always Ask », approuver « Always Allow » dans l’invite ajoute cette commande à la liste d’autorisation. - **Option C — proxifier des binaires macOS via SSH (avancé).** - Gardez le Gateway sur Linux, mais faites en sorte que les binaires CLI requis se résolvent vers des wrappers SSH qui s’exécutent sur un Mac. Ensuite, surchargez la Skill pour autoriser Linux afin qu’elle reste éligible. + **Option C - proxifier les binaires macOS via SSH (avancé).** + Gardez la Gateway sur Linux, mais faites en sorte que les binaires CLI requis se résolvent vers des wrappers SSH qui s’exécutent sur un Mac. Remplacez ensuite le skill pour autoriser Linux afin qu’il reste éligible. 1. Créez un wrapper SSH pour le binaire (exemple : `memo` pour Apple Notes) : @@ -1210,7 +1207,7 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. ``` 2. Placez le wrapper dans le `PATH` sur l’hôte Linux (par exemple `~/bin/memo`). - 3. Surchargez les métadonnées de la Skill (espace de travail ou `~/.openclaw/skills`) pour autoriser Linux : + 3. Remplacez les métadonnées du skill (espace de travail ou `~/.openclaw/skills`) pour autoriser Linux : ```markdown --- @@ -1220,7 +1217,7 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. --- ``` - 4. Démarrez une nouvelle session afin de rafraîchir l’instantané des Skills. + 4. Démarrez une nouvelle session afin que l’instantané des Skills soit actualisé. @@ -1229,15 +1226,15 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. Options : - - **Skill / Plugin personnalisé :** idéal pour un accès API fiable (Notion et HeyGen ont tous deux des API). - - **Automatisation du navigateur :** fonctionne sans code, mais c’est plus lent et plus fragile. + - **Skill / Plugin personnalisé :** la meilleure solution pour un accès API fiable (Notion/HeyGen ont tous deux des API). + - **Automatisation du navigateur :** fonctionne sans code mais est plus lente et plus fragile. - Si vous voulez conserver le contexte par client (flux de travail d’agence), un schéma simple est : + Si vous voulez conserver le contexte par client (workflows d’agence), un schéma simple est le suivant : - - Une page Notion par client (contexte + préférences + travail en cours). + - Une page Notion par client (contexte + préférences + travail actif). - Demander à l’agent de récupérer cette page au début d’une session. - Si vous voulez une intégration native, ouvrez une demande de fonctionnalité ou créez une Skill + Si vous voulez une intégration native, ouvrez une demande de fonctionnalité ou créez un skill ciblant ces API. Installer des Skills : @@ -1247,12 +1244,12 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. openclaw skills update --all ``` - Les installations natives arrivent dans le répertoire `skills/` de l’espace de travail actif. Pour des Skills partagées entre agents, placez-les dans `~/.openclaw/skills//SKILL.md`. Si seules certaines agents doivent voir une installation partagée, configurez `agents.defaults.skills` ou `agents.list[].skills`. Certaines Skills attendent des binaires installés via Homebrew ; sous Linux, cela signifie Linuxbrew (voir l’entrée FAQ Homebrew Linux ci-dessus). Voir [Skills](/fr/tools/skills), [Configuration des Skills](/fr/tools/skills-config), et [ClawHub](/fr/tools/clawhub). + Les installations natives arrivent dans le répertoire `skills/` de l’espace de travail actif. Pour des Skills partagés entre agents, placez-les dans `~/.openclaw/skills//SKILL.md`. Si seule une partie des agents doit voir une installation partagée, configurez `agents.defaults.skills` ou `agents.list[].skills`. Certains Skills attendent des binaires installés via Homebrew ; sur Linux, cela signifie Linuxbrew (voir l’entrée FAQ Homebrew Linux ci-dessus). Voir [Skills](/fr/tools/skills), [Config Skills](/fr/tools/skills-config) et [ClawHub](/fr/tools/clawhub). - Utilisez le profil de navigateur intégré `user`, qui s’attache via Chrome DevTools MCP : + Utilisez le profil de navigateur intégré `user`, qui se rattache via Chrome DevTools MCP : ```bash openclaw browser --browser-profile user tabs @@ -1266,103 +1263,103 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. openclaw browser --browser-profile chrome-live tabs ``` - Ce chemin est local à l’hôte. Si le Gateway s’exécute ailleurs, exécutez soit un hôte Node sur la machine du navigateur, soit utilisez un CDP distant. + Ce chemin peut utiliser le navigateur de l’hôte local ou un node de navigateur connecté. Si la Gateway s’exécute ailleurs, exécutez soit un hôte node sur la machine du navigateur, soit utilisez un profil CDP distant. - Limites actuelles de `existing-session` / `user` : + Limites actuelles sur `existing-session` / `user` : - - les actions sont pilotées par `ref`, pas par sélecteur CSS + - les actions sont pilotées par ref, pas par sélecteur CSS - les téléversements exigent `ref` / `inputRef` et ne prennent actuellement en charge qu’un seul fichier à la fois - - `responsebody`, l’export PDF, l’interception des téléchargements et les actions par lot nécessitent encore un navigateur géré ou un profil CDP brut + - `responsebody`, l’export PDF, l’interception des téléchargements et les actions par lot exigent encore un navigateur géré ou un profil CDP brut -## Sandbox et mémoire +## Sandboxing et mémoire - Oui. Voir [Sandboxing](/fr/gateway/sandboxing). Pour la configuration spécifique à Docker (Gateway complet dans Docker ou images de sandbox), voir [Docker](/fr/install/docker). + Oui. Voir [Sandboxing](/fr/gateway/sandboxing). Pour la configuration spécifique à Docker (gateway complète dans Docker ou images sandbox), voir [Docker](/fr/install/docker). - L’image par défaut privilégie la sécurité et s’exécute sous l’utilisateur `node`, elle ne - comprend donc ni paquets système, ni Homebrew, ni navigateurs intégrés. Pour une configuration plus complète : + L’image par défaut privilégie la sécurité et s’exécute en tant qu’utilisateur `node`, elle + n’inclut donc ni paquets système, ni Homebrew, ni navigateurs intégrés. Pour une configuration plus complète : - Persistez `/home/node` avec `OPENCLAW_HOME_VOLUME` afin que les caches survivent. - - Intégrez les dépendances système à l’image avec `OPENCLAW_DOCKER_APT_PACKAGES`. - - Installez les navigateurs Playwright via la CLI intégrée : + - Intégrez les dépendances système dans l’image avec `OPENCLAW_DOCKER_APT_PACKAGES`. + - Installez les navigateurs Playwright via la CLI fournie : `node /app/node_modules/playwright-core/cli.js install chromium` - - Définissez `PLAYWRIGHT_BROWSERS_PATH` et assurez-vous que le chemin est persistant. + - Définissez `PLAYWRIGHT_BROWSERS_PATH` et assurez-vous que le chemin est persisté. - Documentation : [Docker](/fr/install/docker), [Browser](/fr/tools/browser). + Documentation : [Docker](/fr/install/docker), [Navigateur](/fr/tools/browser). - Oui — si votre trafic privé est constitué de **DM** et votre trafic public de **groupes**. + Oui — si votre trafic privé correspond aux **DM** et votre trafic public aux **groupes**. - Utilisez `agents.defaults.sandbox.mode: "non-main"` afin que les sessions de groupe/canal (clés non principales) s’exécutent dans Docker, tandis que la session DM principale reste sur l’hôte. Ensuite, limitez les outils disponibles dans les sessions sandboxées via `tools.sandbox.tools`. + Utilisez `agents.defaults.sandbox.mode: "non-main"` afin que les sessions de groupe/canal (clés non principales) s’exécutent dans Docker, tandis que la session DM principale reste sur l’hôte. Limitez ensuite les outils disponibles dans les sessions sandboxées via `tools.sandbox.tools`. - Guide de configuration + exemple : [Groupes : DM privés + groupes publics](/fr/channels/groups#pattern-personal-dms-public-groups-single-agent) + Procédure + exemple de configuration : [Groupes : DM privés + groupes publics](/fr/channels/groups#pattern-personal-dms-public-groups-single-agent) Référence de configuration clé : [Configuration Gateway](/fr/gateway/configuration-reference#agentsdefaultssandbox) - Définissez `agents.defaults.sandbox.docker.binds` sur `["host:path:mode"]` (par exemple `"/home/user/src:/src:ro"`). Les liaisons globales et par agent sont fusionnées ; les liaisons par agent sont ignorées quand `scope: "shared"`. Utilisez `:ro` pour tout ce qui est sensible et souvenez-vous que les liaisons contournent les barrières du système de fichiers du sandbox. + Définissez `agents.defaults.sandbox.docker.binds` sur `["host:path:mode"]` (par ex. `"/home/user/src:/src:ro"`). Les liaisons globales et par agent sont fusionnées ; les liaisons par agent sont ignorées lorsque `scope: "shared"`. Utilisez `:ro` pour tout ce qui est sensible et gardez à l’esprit que les liaisons contournent les barrières du système de fichiers du sandbox. - OpenClaw valide les sources de liaison à la fois par rapport au chemin normalisé et au chemin canonique résolu via l’ancêtre existant le plus profond. Cela signifie que les échappements via parent symlink échouent toujours en mode fail closed même lorsque le dernier segment du chemin n’existe pas encore, et les vérifications de racine autorisée s’appliquent toujours après résolution des symlinks. + OpenClaw valide les sources de liaison à la fois par rapport au chemin normalisé et au chemin canonique résolu via l’ancêtre existant le plus profond. Cela signifie que les échappements via parent symlink échouent toujours en mode fermé même lorsque le dernier segment du chemin n’existe pas encore, et que les vérifications de racine autorisée s’appliquent toujours après la résolution des symlinks. Voir [Sandboxing](/fr/gateway/sandboxing#custom-bind-mounts) et [Sandbox vs Tool Policy vs Elevated](/fr/gateway/sandbox-vs-tool-policy-vs-elevated#bind-mounts-security-quick-check) pour des exemples et des notes de sécurité. - La mémoire d’OpenClaw n’est constituée que de fichiers Markdown dans l’espace de travail de l’agent : + La mémoire OpenClaw n’est rien d’autre que des fichiers Markdown dans l’espace de travail de l’agent : - Notes quotidiennes dans `memory/YYYY-MM-DD.md` - - Notes long terme organisées dans `MEMORY.md` (sessions principales/privées uniquement) + - Notes de long terme organisées dans `MEMORY.md` (sessions principales/privées uniquement) - OpenClaw exécute aussi une **vidange silencieuse de la mémoire avant Compaction** afin de rappeler au modèle - d’écrire des notes durables avant la Compaction automatique. Cela ne s’exécute que lorsque l’espace de travail - est accessible en écriture (les sandboxes en lecture seule l’ignorent). Voir [Memory](/fr/concepts/memory). + OpenClaw exécute aussi un **vidage mémoire silencieux avant Compaction** pour rappeler au modèle + d’écrire des notes durables avant l’auto-Compaction. Cela ne s’exécute que lorsque l’espace de travail + est accessible en écriture (les sandboxes en lecture seule l’ignorent). Voir [Mémoire](/fr/concepts/memory). - - Demandez au bot d’**écrire le fait dans la mémoire**. Les notes de long terme vont dans `MEMORY.md`, + + Demandez au bot d’**écrire l’information dans la mémoire**. Les notes de long terme vont dans `MEMORY.md`, le contexte de court terme va dans `memory/YYYY-MM-DD.md`. - C’est encore un domaine que nous améliorons. Il est utile de rappeler au modèle de stocker des souvenirs ; - il saura quoi faire. S’il continue à oublier, vérifiez que le Gateway utilise le même + C’est encore un domaine que nous continuons d’améliorer. Il est utile de rappeler au modèle de stocker des souvenirs ; + il saura quoi faire. S’il continue d’oublier, vérifiez que la Gateway utilise le même espace de travail à chaque exécution. - Documentation : [Memory](/fr/concepts/memory), [Espace de travail de l’agent](/fr/concepts/agent-workspace). + Documentation : [Mémoire](/fr/concepts/memory), [Espace de travail de l’agent](/fr/concepts/agent-workspace). Les fichiers mémoire vivent sur le disque et persistent jusqu’à ce que vous les supprimiez. La limite est votre - stockage, pas le modèle. Le **contexte de session** reste toutefois limité par la fenêtre de contexte du modèle, - donc les longues conversations peuvent être compactées ou tronquées. C’est pour cela que - la recherche mémoire existe : elle ne ramène dans le contexte que les parties pertinentes. + stockage, pas le modèle. Le **contexte de session** reste toutefois limité par la fenêtre de contexte + du modèle, donc les longues conversations peuvent être compactées ou tronquées. C’est pour cela que la + recherche mémoire existe : elle ne réinjecte dans le contexte que les parties pertinentes. - Documentation : [Memory](/fr/concepts/memory), [Contexte](/fr/concepts/context). + Documentation : [Mémoire](/fr/concepts/memory), [Contexte](/fr/concepts/context). - Uniquement si vous utilisez les **embeddings OpenAI**. L’OAuth Codex couvre le chat/les complétions et - **n’accorde pas** l’accès aux embeddings, donc **se connecter avec Codex (OAuth ou la + Uniquement si vous utilisez les **embeddings OpenAI**. OAuth Codex couvre le chat/les complétions et + n’accorde **pas** d’accès aux embeddings, donc **se connecter avec Codex (OAuth ou la connexion Codex CLI)** n’aide pas pour la recherche mémoire sémantique. Les embeddings OpenAI nécessitent toujours une vraie clé API (`OPENAI_API_KEY` ou `models.providers.openai.apiKey`). - Si vous ne définissez pas explicitement un fournisseur, OpenClaw en sélectionne automatiquement un lorsqu’il - peut résoudre une clé API (profils d’authentification, `models.providers.*.apiKey`, ou variables d’environnement). + Si vous ne définissez pas explicitement de fournisseur, OpenClaw sélectionne automatiquement un fournisseur lorsqu’il + peut résoudre une clé API (profils d’authentification, `models.providers.*.apiKey` ou variables d’environnement). Il préfère OpenAI si une clé OpenAI est résolue, sinon Gemini si une clé Gemini - est résolue, puis Voyage, puis Mistral. Si aucune clé distante n’est disponible, la recherche - mémoire reste désactivée jusqu’à ce que vous la configuriez. Si vous avez un chemin de modèle local + est résolue, puis Voyage, puis Mistral. Si aucune clé distante n’est disponible, la + recherche mémoire reste désactivée jusqu’à ce que vous la configuriez. Si vous avez un chemin de modèle local configuré et présent, OpenClaw préfère `local`. Ollama est pris en charge lorsque vous définissez explicitement `memorySearch.provider = "ollama"`. @@ -1371,7 +1368,7 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. `memorySearch.fallback = "none"`). Si vous voulez des embeddings Gemini, définissez `memorySearch.provider = "gemini"` et fournissez `GEMINI_API_KEY` (ou `memorySearch.remote.apiKey`). Nous prenons en charge les modèles d’embedding **OpenAI, Gemini, Voyage, Mistral, Ollama ou local** - — voir [Memory](/fr/concepts/memory) pour les détails de configuration. + — voir [Mémoire](/fr/concepts/memory) pour les détails de configuration. @@ -1380,49 +1377,49 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. - Non — **l’état d’OpenClaw est local**, mais **les services externes voient quand même ce que vous leur envoyez**. + Non — **l’état d’OpenClaw est local**, mais **les services externes voient toujours ce que vous leur envoyez**. - - **Local par défaut :** les sessions, fichiers mémoire, la configuration et l’espace de travail vivent sur l’hôte Gateway + - **Local par défaut :** sessions, fichiers mémoire, configuration et espace de travail vivent sur l’hôte Gateway (`~/.openclaw` + votre répertoire d’espace de travail). - **Distant par nécessité :** les messages que vous envoyez aux fournisseurs de modèles (Anthropic/OpenAI/etc.) vont vers - leurs API, et les plateformes de chat (WhatsApp/Telegram/Slack/etc.) stockent les données de messages sur leurs + leurs API, et les plateformes de chat (WhatsApp/Telegram/Slack/etc.) stockent les données de message sur leurs serveurs. - **Vous contrôlez l’empreinte :** utiliser des modèles locaux garde les prompts sur votre machine, mais le trafic des canaux passe toujours par les serveurs du canal. - Voir aussi : [Espace de travail de l’agent](/fr/concepts/agent-workspace), [Memory](/fr/concepts/memory). + Liens associés : [Espace de travail de l’agent](/fr/concepts/agent-workspace), [Mémoire](/fr/concepts/memory). - Tout se trouve sous `$OPENCLAW_STATE_DIR` (par défaut : `~/.openclaw`) : + Tout vit sous `$OPENCLAW_STATE_DIR` (par défaut : `~/.openclaw`) : - | Path | Purpose | + | Path | Usage | | --------------------------------------------------------------- | ------------------------------------------------------------------ | | `$OPENCLAW_STATE_DIR/openclaw.json` | Configuration principale (JSON5) | - | `$OPENCLAW_STATE_DIR/credentials/oauth.json` | Import OAuth historique (copié dans les profils d’authentification au premier usage) | - | `$OPENCLAW_STATE_DIR/agents//agent/auth-profiles.json` | Profils d’authentification (OAuth, clés API, et `keyRef`/`tokenRef` facultatifs) | - | `$OPENCLAW_STATE_DIR/secrets.json` | Charge utile de secret optionnelle basée sur fichier pour les fournisseurs `file` de SecretRef | - | `$OPENCLAW_STATE_DIR/agents//agent/auth.json` | Fichier de compatibilité historique (entrées statiques `api_key` nettoyées) | + | `$OPENCLAW_STATE_DIR/credentials/oauth.json` | Import OAuth hérité (copié dans les profils d’authentification au premier usage) | + | `$OPENCLAW_STATE_DIR/agents//agent/auth-profiles.json` | Profils d’authentification (OAuth, clés API et `keyRef`/`tokenRef` facultatifs) | + | `$OPENCLAW_STATE_DIR/secrets.json` | Charge utile secrète facultative sauvegardée dans un fichier pour les fournisseurs `file` SecretRef | + | `$OPENCLAW_STATE_DIR/agents//agent/auth.json` | Fichier de compatibilité hérité (les entrées statiques `api_key` sont nettoyées) | | `$OPENCLAW_STATE_DIR/credentials/` | État du fournisseur (par ex. `whatsapp//creds.json`) | | `$OPENCLAW_STATE_DIR/agents/` | État par agent (agentDir + sessions) | | `$OPENCLAW_STATE_DIR/agents//sessions/` | Historique et état des conversations (par agent) | | `$OPENCLAW_STATE_DIR/agents//sessions/sessions.json` | Métadonnées de session (par agent) | - Chemin historique à agent unique : `~/.openclaw/agent/*` (migré par `openclaw doctor`). + Chemin hérité mono-agent : `~/.openclaw/agent/*` (migré par `openclaw doctor`). Votre **espace de travail** (`AGENTS.md`, fichiers mémoire, Skills, etc.) est séparé et configuré via `agents.defaults.workspace` (par défaut : `~/.openclaw/workspace`). - Ces fichiers se trouvent dans l’**espace de travail de l’agent**, pas dans `~/.openclaw`. + Ces fichiers vivent dans l’**espace de travail de l’agent**, pas dans `~/.openclaw`. - **Espace de travail (par agent)** : `AGENTS.md`, `SOUL.md`, `IDENTITY.md`, `USER.md`, - `MEMORY.md` (ou le repli historique `memory.md` lorsque `MEMORY.md` est absent), - `memory/YYYY-MM-DD.md`, `HEARTBEAT.md` facultatif. + `MEMORY.md` (ou le fallback hérité `memory.md` lorsque `MEMORY.md` est absent), + `memory/YYYY-MM-DD.md`, et éventuellement `HEARTBEAT.md`. - **Répertoire d’état (`~/.openclaw`)** : configuration, état des canaux/fournisseurs, profils d’authentification, sessions, journaux, - et Skills partagées (`~/.openclaw/skills`). + et Skills partagés (`~/.openclaw/skills`). L’espace de travail par défaut est `~/.openclaw/workspace`, configurable via : @@ -1432,25 +1429,25 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. } ``` - Si le bot « oublie » après un redémarrage, vérifiez que le Gateway utilise le même - espace de travail à chaque lancement (et souvenez-vous : le mode distant utilise l’espace de travail de l’**hôte Gateway**, - pas celui de votre ordinateur portable local). + Si le bot « oublie » après un redémarrage, confirmez que la Gateway utilise le même + espace de travail à chaque lancement (et souvenez-vous : le mode distant utilise l’espace de travail + de **l’hôte gateway**, pas celui de votre ordinateur portable local). Conseil : si vous voulez un comportement ou une préférence durable, demandez au bot de **l’écrire dans AGENTS.md ou MEMORY.md** plutôt que de vous appuyer sur l’historique du chat. - Voir [Espace de travail de l’agent](/fr/concepts/agent-workspace) et [Memory](/fr/concepts/memory). + Voir [Espace de travail de l’agent](/fr/concepts/agent-workspace) et [Mémoire](/fr/concepts/memory). - Mettez votre **espace de travail de l’agent** dans un dépôt git **privé** et sauvegardez-le dans un endroit + Placez votre **espace de travail d’agent** dans un dépôt git **privé** et sauvegardez-le dans un endroit privé (par exemple GitHub privé). Cela capture la mémoire + les fichiers AGENTS/SOUL/USER et vous permet de restaurer plus tard « l’esprit » de l’assistant. - Ne faites **pas** de commit de quoi que ce soit sous `~/.openclaw` (identifiants, sessions, tokens ou charges utiles de secrets chiffrés). - Si vous avez besoin d’une restauration complète, sauvegardez séparément à la fois l’espace de travail et le répertoire d’état - (voir la question sur la migration ci-dessus). + Ne validez **pas** tout ce qui se trouve sous `~/.openclaw` (identifiants, sessions, tokens ou charges utiles secrètes chiffrées). + Si vous avez besoin d’une restauration complète, sauvegardez séparément l’espace de travail et le répertoire d’état + (voir la question de migration ci-dessus). Documentation : [Espace de travail de l’agent](/fr/concepts/agent-workspace). @@ -1461,13 +1458,13 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. - Oui. L’espace de travail est le **cwd par défaut** et l’ancre mémoire, pas un sandbox strict. + Oui. L’espace de travail est le **cwd par défaut** et l’ancre mémoire, pas un sandbox rigide. Les chemins relatifs se résolvent dans l’espace de travail, mais les chemins absolus peuvent accéder à d’autres emplacements de l’hôte sauf si le sandboxing est activé. Si vous avez besoin d’isolation, utilisez - [`agents.defaults.sandbox`](/fr/gateway/sandboxing) ou des paramètres de sandbox par agent. Si vous - voulez qu’un dépôt soit le répertoire de travail par défaut, pointez le - `workspace` de cet agent vers la racine du dépôt. Le dépôt OpenClaw n’est que du code source ; gardez l’ - espace de travail séparé sauf si vous voulez intentionnellement que l’agent travaille dedans. + [`agents.defaults.sandbox`](/fr/gateway/sandboxing) ou les paramètres de sandbox par agent. Si vous + voulez qu’un dépôt soit le répertoire de travail par défaut, pointez le `workspace` + de cet agent vers la racine du dépôt. Le dépôt OpenClaw n’est que du code source ; gardez l’espace de + travail séparé sauf si vous voulez intentionnellement que l’agent travaille à l’intérieur. Exemple (dépôt comme cwd par défaut) : @@ -1484,7 +1481,7 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. - L’état de session appartient à l’**hôte Gateway**. Si vous êtes en mode distant, le magasin de sessions qui vous intéresse se trouve sur la machine distante, pas sur votre ordinateur portable local. Voir [Gestion des sessions](/fr/concepts/session). + L’état des sessions appartient à l’**hôte gateway**. Si vous êtes en mode distant, le magasin de sessions qui vous intéresse se trouve sur la machine distante, pas sur votre ordinateur portable local. Voir [Gestion des sessions](/fr/concepts/session). @@ -1498,15 +1495,15 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. $OPENCLAW_CONFIG_PATH ``` - Si le fichier est absent, il utilise des valeurs par défaut raisonnablement sûres (y compris un espace de travail par défaut `~/.openclaw/workspace`). + Si le fichier est absent, il utilise des valeurs par défaut raisonnablement sûres (y compris un espace de travail par défaut de `~/.openclaw/workspace`). - - Les bind non-loopback **exigent un chemin d’authentification Gateway valide**. En pratique, cela signifie : + + Les liaisons non-loopback **nécessitent un chemin d’authentification gateway valide**. En pratique, cela signifie : - authentification par secret partagé : token ou mot de passe - - `gateway.auth.mode: "trusted-proxy"` derrière un proxy inverse conscient de l’identité correctement configuré et non-loopback + - `gateway.auth.mode: "trusted-proxy"` derrière un proxy inverse avec gestion d’identité non-loopback correctement configuré ```json5 { @@ -1522,24 +1519,24 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. Remarques : - - `gateway.remote.token` / `.password` **n’activent pas** à eux seuls l’authentification du Gateway local. - - Les chemins d’appel locaux peuvent utiliser `gateway.remote.*` comme repli uniquement lorsque `gateway.auth.*` n’est pas défini. - - Pour l’authentification par mot de passe, définissez à la place `gateway.auth.mode: "password"` plus `gateway.auth.password` (ou `OPENCLAW_GATEWAY_PASSWORD`). - - Si `gateway.auth.token` / `gateway.auth.password` est explicitement configuré via SecretRef et non résolu, la résolution échoue en mode fail closed (aucun repli distant ne masque cela). - - Les configurations Control UI à secret partagé s’authentifient via `connect.params.auth.token` ou `connect.params.auth.password` (stockés dans les paramètres de l’app/UI). Les modes portant une identité comme Tailscale Serve ou `trusted-proxy` utilisent à la place des en-têtes de requête. Évitez de mettre des secrets partagés dans les URL. + - `gateway.remote.token` / `.password` **n’activent pas** à eux seuls l’authentification locale de la gateway. + - Les chemins d’appel locaux peuvent utiliser `gateway.remote.*` comme fallback uniquement lorsque `gateway.auth.*` n’est pas défini. + - Pour l’authentification par mot de passe, définissez plutôt `gateway.auth.mode: "password"` plus `gateway.auth.password` (ou `OPENCLAW_GATEWAY_PASSWORD`). + - Si `gateway.auth.token` / `gateway.auth.password` est explicitement configuré via SecretRef mais non résolu, la résolution échoue en mode fermé (aucun fallback distant ne masque cela). + - Les configurations Control UI avec secret partagé s’authentifient via `connect.params.auth.token` ou `connect.params.auth.password` (stockés dans les paramètres de l’application/de l’UI). Les modes porteurs d’identité tels que Tailscale Serve ou `trusted-proxy` utilisent à la place les en-têtes de requête. Évitez de mettre des secrets partagés dans les URL. - Avec `gateway.auth.mode: "trusted-proxy"`, les proxies inverses loopback sur le même hôte **ne satisfont toujours pas** l’authentification trusted-proxy. Le proxy de confiance doit être une source non-loopback configurée. - - OpenClaw impose par défaut l’authentification Gateway, y compris sur loopback. Dans le chemin par défaut normal, cela signifie une authentification par token : si aucun chemin d’authentification explicite n’est configuré, le démarrage du Gateway se résout en mode token et en génère automatiquement un, qui est enregistré dans `gateway.auth.token`, donc **les clients WS locaux doivent s’authentifier**. Cela empêche d’autres processus locaux d’appeler le Gateway. + + OpenClaw applique désormais par défaut une authentification gateway, y compris sur loopback. Dans le chemin par défaut normal, cela signifie une authentification par token : si aucun chemin d’authentification explicite n’est configuré, le démarrage de la gateway se résout en mode token et en génère automatiquement un, en l’enregistrant dans `gateway.auth.token`, donc **les clients WS locaux doivent s’authentifier**. Cela empêche les autres processus locaux d’appeler la Gateway. - Si vous préférez un autre chemin d’authentification, vous pouvez choisir explicitement le mode mot de passe (ou, pour des proxies inverses non-loopback conscients de l’identité, `trusted-proxy`). Si vous **voulez vraiment** un loopback ouvert, définissez explicitement `gateway.auth.mode: "none"` dans votre configuration. Doctor peut générer un token pour vous à tout moment : `openclaw doctor --generate-gateway-token`. + Si vous préférez un autre chemin d’authentification, vous pouvez choisir explicitement le mode mot de passe (ou, pour des proxies inverses non-loopback avec gestion d’identité, `trusted-proxy`). Si vous **voulez vraiment** un loopback ouvert, définissez explicitement `gateway.auth.mode: "none"` dans votre configuration. Doctor peut vous générer un token à tout moment : `openclaw doctor --generate-gateway-token`. - Le Gateway surveille la configuration et prend en charge le hot-reload : + La Gateway surveille la configuration et prend en charge le rechargement à chaud : - `gateway.reload.mode: "hybrid"` (par défaut) : applique à chaud les changements sûrs, redémarre pour les changements critiques - `hot`, `restart`, `off` sont également pris en charge @@ -1559,21 +1556,21 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. } ``` - - `off` : masque le texte du slogan, mais conserve la ligne titre/version de la bannière. + - `off` : masque le texte du slogan mais conserve la ligne de titre/version de la bannière. - `default` : utilise `All your chats, one OpenClaw.` à chaque fois. - `random` : slogans amusants/de saison en rotation (comportement par défaut). - - Si vous ne voulez aucune bannière, définissez la variable d’environnement `OPENCLAW_HIDE_BANNER=1`. + - Si vous ne voulez aucune bannière du tout, définissez la variable d’environnement `OPENCLAW_HIDE_BANNER=1`. - `web_fetch` fonctionne sans clé API. `web_search` dépend du - fournisseur que vous avez sélectionné : + `web_fetch` fonctionne sans clé API. `web_search` dépend de votre + fournisseur sélectionné : - - Les fournisseurs basés sur API tels que Brave, Exa, Firecrawl, Gemini, Grok, Kimi, MiniMax Search, Perplexity et Tavily nécessitent leur configuration habituelle de clé API. + - Les fournisseurs reposant sur une API tels que Brave, Exa, Firecrawl, Gemini, Grok, Kimi, MiniMax Search, Perplexity et Tavily nécessitent leur configuration normale de clé API. - Ollama Web Search ne nécessite pas de clé, mais utilise votre hôte Ollama configuré et exige `ollama signin`. - DuckDuckGo ne nécessite pas de clé, mais il s’agit d’une intégration non officielle basée sur HTML. - - SearXNG ne nécessite pas de clé/peut être auto-hébergé ; configurez `SEARXNG_BASE_URL` ou `plugins.entries.searxng.config.webSearch.baseUrl`. + - SearXNG ne nécessite pas de clé / est auto-hébergé ; configurez `SEARXNG_BASE_URL` ou `plugins.entries.searxng.config.webSearch.baseUrl`. **Recommandé :** exécutez `openclaw configure --section web` et choisissez un fournisseur. Alternatives par variable d’environnement : @@ -1584,7 +1581,7 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. - Gemini : `GEMINI_API_KEY` - Grok : `XAI_API_KEY` - Kimi : `KIMI_API_KEY` ou `MOONSHOT_API_KEY` - - MiniMax Search : `MINIMAX_CODE_PLAN_KEY`, `MINIMAX_CODING_API_KEY`, ou `MINIMAX_API_KEY` + - MiniMax Search : `MINIMAX_CODE_PLAN_KEY`, `MINIMAX_CODING_API_KEY` ou `MINIMAX_API_KEY` - Perplexity : `PERPLEXITY_API_KEY` ou `OPENROUTER_API_KEY` - SearXNG : `SEARXNG_BASE_URL` - Tavily : `TAVILY_API_KEY` @@ -1611,25 +1608,25 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. }, fetch: { enabled: true, - provider: "firecrawl", // optional; omit for auto-detect + provider: "firecrawl", // facultatif ; omettez pour l’auto-détection }, }, }, } ``` - La configuration de recherche web spécifique au fournisseur se trouve désormais sous `plugins.entries..config.webSearch.*`. + La configuration de recherche web spécifique au fournisseur se trouve maintenant sous `plugins.entries..config.webSearch.*`. Les anciens chemins de fournisseur `tools.web.search.*` sont encore chargés temporairement pour compatibilité, mais ils ne doivent pas être utilisés pour les nouvelles configurations. - La configuration de repli Firecrawl pour la récupération web se trouve sous `plugins.entries.firecrawl.config.webFetch.*`. + La configuration de secours Firecrawl pour la récupération web se trouve sous `plugins.entries.firecrawl.config.webFetch.*`. Remarques : - Si vous utilisez des listes d’autorisation, ajoutez `web_search`/`web_fetch`/`x_search` ou `group:web`. - `web_fetch` est activé par défaut (sauf s’il est explicitement désactivé). - - Si `tools.web.fetch.provider` est omis, OpenClaw détecte automatiquement le premier fournisseur de repli de récupération prêt à partir des identifiants disponibles. Aujourd’hui, le fournisseur intégré est Firecrawl. - - Les démons lisent les variables d’environnement depuis `~/.openclaw/.env` (ou l’environnement du service). + - Si `tools.web.fetch.provider` est omis, OpenClaw détecte automatiquement le premier fournisseur de secours de récupération prêt à partir des identifiants disponibles. Aujourd’hui, le fournisseur intégré est Firecrawl. + - Les daemons lisent les variables d’environnement depuis `~/.openclaw/.env` (ou l’environnement du service). - Documentation : [Outils Web](/fr/tools/web). + Documentation : [Outils web](/fr/tools/web). @@ -1641,35 +1638,35 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. - Restaurez depuis une sauvegarde (git ou une copie de `~/.openclaw/openclaw.json`). - Si vous n’avez pas de sauvegarde, relancez `openclaw doctor` et reconfigurez les canaux/modèles. - - Si c’était inattendu, ouvrez un bug et incluez votre dernière configuration connue ou toute sauvegarde. + - Si cela était inattendu, ouvrez un bug et incluez votre dernière configuration connue ou toute sauvegarde. - Un agent de codage local peut souvent reconstruire une configuration fonctionnelle à partir des journaux ou de l’historique. Pour éviter cela : - Utilisez `openclaw config set` pour les petits changements. - Utilisez `openclaw configure` pour les modifications interactives. - - Utilisez d’abord `config.schema.lookup` lorsque vous n’êtes pas sûr d’un chemin exact ou de la forme d’un champ ; cela renvoie un nœud de schéma superficiel ainsi que des résumés immédiats des enfants pour approfondir. - - Utilisez `config.patch` pour des modifications RPC partielles ; réservez `config.apply` au remplacement complet de la configuration. - - Si vous utilisez l’outil `gateway`, réservé au propriétaire, depuis une exécution d’agent, il rejettera toujours les écritures vers `tools.exec.ask` / `tools.exec.security` (y compris les anciens alias `tools.bash.*` qui se normalisent vers les mêmes chemins exec protégés). + - Utilisez d’abord `config.schema.lookup` lorsque vous n’êtes pas sûr d’un chemin exact ou de la forme d’un champ ; il renvoie un nœud de schéma peu profond plus des résumés immédiats des enfants pour approfondir. + - Utilisez `config.patch` pour les modifications RPC partielles ; gardez `config.apply` pour le remplacement complet de la configuration uniquement. + - Si vous utilisez l’outil `gateway` réservé au propriétaire depuis une exécution d’agent, il rejettera toujours les écritures vers `tools.exec.ask` / `tools.exec.security` (y compris les anciens alias `tools.bash.*` qui se normalisent vers les mêmes chemins exec protégés). - Documentation : [Config](/cli/config), [Configure](/cli/configure), [Doctor](/fr/gateway/doctor). + Documentation : [Configuration](/cli/config), [Configurer](/cli/configure), [Doctor](/fr/gateway/doctor). - - Le schéma courant consiste à avoir **un Gateway** (par ex. Raspberry Pi) plus des **Nodes** et des **agents** : + + Le schéma courant est **une Gateway** (par ex. Raspberry Pi) plus des **nodes** et des **agents** : - - **Gateway (central) :** possède les canaux (Signal/WhatsApp), le routage et les sessions. - - **Nodes (appareils) :** les Mac/iOS/Android se connectent comme périphériques et exposent des outils locaux (`system.run`, `canvas`, `camera`). - - **Agents (workers) :** cerveaux/espaces de travail séparés pour des rôles spécialisés (par ex. « opérations Hetzner », « données personnelles »). + - **Gateway (centrale) :** possède les canaux (Signal/WhatsApp), le routage et les sessions. + - **Nodes (appareils) :** les Macs/iOS/Android se connectent comme périphériques et exposent des outils locaux (`system.run`, `canvas`, `camera`). + - **Agents (workers) :** cerveaux/espaces de travail distincts pour des rôles spécialisés (par ex. « ops Hetzner », « données personnelles »). - **Sous-agents :** lancent du travail en arrière-plan depuis un agent principal lorsque vous voulez du parallélisme. - - **TUI :** se connecte au Gateway et permet de changer d’agent/de session. + - **TUI :** se connecte à la Gateway et permet de changer d’agent/de session. Documentation : [Nodes](/fr/nodes), [Accès distant](/fr/gateway/remote), [Routage multi-agent](/fr/concepts/multi-agent), [Sous-agents](/fr/tools/subagents), [TUI](/web/tui). - + Oui. C’est une option de configuration : ```json5 @@ -1683,7 +1680,7 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. } ``` - La valeur par défaut est `false` (avec interface). Le mode headless est plus susceptible de déclencher des vérifications anti-bot sur certains sites. Voir [Browser](/fr/tools/browser). + La valeur par défaut est `false` (avec interface). Le mode headless est plus susceptible de déclencher des vérifications anti-bot sur certains sites. Voir [Navigateur](/fr/tools/browser). Le mode headless utilise le **même moteur Chromium** et fonctionne pour la plupart des automatisations (formulaires, clics, scraping, connexions). Les principales différences : @@ -1694,138 +1691,138 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. - Définissez `browser.executablePath` vers votre binaire Brave (ou tout navigateur basé sur Chromium), puis redémarrez le Gateway. - Voir les exemples complets de configuration dans [Browser](/fr/tools/browser#use-brave-or-another-chromium-based-browser). + Définissez `browser.executablePath` vers votre binaire Brave (ou tout autre navigateur basé sur Chromium) et redémarrez la Gateway. + Voir les exemples complets de configuration dans [Navigateur](/fr/tools/browser#use-brave-or-another-chromium-based-browser). -## Gateways distants et Nodes +## Gateways distantes et nodes - - Les messages Telegram sont gérés par le **Gateway**. Le Gateway exécute l’agent puis - appelle seulement ensuite les Nodes via le **WebSocket Gateway** lorsqu’un outil Node est nécessaire : + + Les messages Telegram sont gérés par la **gateway**. La gateway exécute l’agent et + n’appelle les nodes via la **WebSocket Gateway** que lorsqu’un outil node est nécessaire : Telegram → Gateway → Agent → `node.*` → Node → Gateway → Telegram - Les Nodes ne voient pas le trafic fournisseur entrant ; ils ne reçoivent que des appels RPC Node. + Les nodes ne voient pas le trafic entrant du fournisseur ; ils ne reçoivent que des appels RPC node. - - Réponse courte : **associez votre ordinateur comme Node**. Le Gateway s’exécute ailleurs, mais il peut - appeler des outils `node.*` (écran, caméra, système) sur votre machine locale via le WebSocket Gateway. + + Réponse courte : **associez votre ordinateur comme node**. La Gateway s’exécute ailleurs, mais elle peut + appeler des outils `node.*` (écran, caméra, système) sur votre machine locale via la WebSocket Gateway. Configuration typique : - 1. Exécutez le Gateway sur l’hôte toujours actif (VPS/serveur domestique). - 2. Placez l’hôte Gateway et votre ordinateur sur le même tailnet. - 3. Assurez-vous que le WS Gateway est accessible (bind tailnet ou tunnel SSH). + 1. Exécutez la Gateway sur l’hôte toujours actif (VPS/serveur domestique). + 2. Placez l’hôte Gateway + votre ordinateur sur le même tailnet. + 3. Assurez-vous que la WS Gateway est joignable (liaison tailnet ou tunnel SSH). 4. Ouvrez l’application macOS localement et connectez-vous en mode **Remote over SSH** (ou tailnet direct) - afin qu’elle puisse s’enregistrer comme Node. - 5. Approuvez le Node sur le Gateway : + afin qu’elle puisse s’enregistrer comme node. + 5. Approuvez le node sur la Gateway : ```bash openclaw devices list openclaw devices approve ``` - Aucun pont TCP séparé n’est nécessaire ; les Nodes se connectent via le WebSocket Gateway. + Aucun pont TCP séparé n’est requis ; les nodes se connectent via la WebSocket Gateway. - Rappel de sécurité : associer un Node macOS permet `system.run` sur cette machine. N’associez - que des appareils de confiance et consultez [Security](/fr/gateway/security). + Rappel de sécurité : associer un node macOS autorise `system.run` sur cette machine. N’associez + que des appareils auxquels vous faites confiance et consultez [Sécurité](/fr/gateway/security). - Documentation : [Nodes](/fr/nodes), [Protocole Gateway](/fr/gateway/protocol), [mode distant macOS](/fr/platforms/mac/remote), [Security](/fr/gateway/security). + Documentation : [Nodes](/fr/nodes), [Protocole Gateway](/fr/gateway/protocol), [mode distant macOS](/fr/platforms/mac/remote), [Sécurité](/fr/gateway/security). - Vérifiez l’essentiel : + Vérifiez les bases : - - Le Gateway est en cours d’exécution : `openclaw gateway status` - - Santé du Gateway : `openclaw status` - - Santé des canaux : `openclaw channels status` + - la Gateway fonctionne : `openclaw gateway status` + - état de santé de la Gateway : `openclaw status` + - état de santé des canaux : `openclaw channels status` Vérifiez ensuite l’authentification et le routage : - Si vous utilisez Tailscale Serve, assurez-vous que `gateway.auth.allowTailscale` est correctement défini. - Si vous vous connectez via un tunnel SSH, confirmez que le tunnel local est actif et pointe vers le bon port. - - Vérifiez que vos listes d’autorisation (DM ou groupe) incluent votre compte. + - Confirmez que vos listes d’autorisation (DM ou groupe) incluent votre compte. Documentation : [Tailscale](/fr/gateway/tailscale), [Accès distant](/fr/gateway/remote), [Canaux](/fr/channels). - Oui. Il n’existe pas de pont intégré « bot-à-bot », mais vous pouvez le mettre en place de plusieurs + Oui. Il n’existe pas de pont « bot-à-bot » intégré, mais vous pouvez le mettre en place de plusieurs façons fiables : - **Le plus simple :** utiliser un canal de chat normal auquel les deux bots peuvent accéder (Telegram/Slack/WhatsApp). - Faites envoyer un message par le bot A au bot B, puis laissez le bot B répondre comme d’habitude. + **Le plus simple :** utilisez un canal de chat normal auquel les deux bots peuvent accéder (Telegram/Slack/WhatsApp). + Faites envoyer un message par le bot A au bot B, puis laissez le bot B répondre normalement. **Pont CLI (générique) :** exécutez un script qui appelle l’autre Gateway avec `openclaw agent --message ... --deliver`, en ciblant un chat où l’autre bot - écoute. Si l’un des bots est sur un VPS distant, pointez votre CLI vers ce Gateway distant + écoute. Si un bot se trouve sur un VPS distant, pointez votre CLI vers cette Gateway distante via SSH/Tailscale (voir [Accès distant](/fr/gateway/remote)). - Exemple de schéma (à exécuter depuis une machine qui peut atteindre le Gateway cible) : + Exemple de schéma (à exécuter depuis une machine pouvant atteindre la Gateway cible) : ```bash openclaw agent --message "Hello from local bot" --deliver --channel telegram --reply-to ``` - Conseil : ajoutez une protection pour éviter que les deux bots ne bouclent à l’infini (réponse uniquement en cas de mention, listes d’autorisation de canal, + Conseil : ajoutez un garde-fou pour éviter que les deux bots ne bouclent indéfiniment (réponse sur mention uniquement, listes d’autorisation de canaux, ou règle « ne pas répondre aux messages de bot »). - Documentation : [Accès distant](/fr/gateway/remote), [CLI agent](/cli/agent), [Envoi d’agent](/fr/tools/agent-send). + Documentation : [Accès distant](/fr/gateway/remote), [CLI agent](/cli/agent), [Envoi agent](/fr/tools/agent-send). - Non. Un Gateway peut héberger plusieurs agents, chacun avec son propre espace de travail, ses modèles par défaut - et son routage. C’est la configuration normale, et c’est bien moins cher et plus simple que d’exécuter + Non. Une Gateway peut héberger plusieurs agents, chacun avec son propre espace de travail, ses valeurs par défaut de modèle + et son routage. C’est la configuration normale, et elle est bien moins coûteuse et plus simple que d’exécuter un VPS par agent. - N’utilisez des VPS séparés que si vous avez besoin d’une isolation forte (frontières de sécurité) ou de - configurations très différentes que vous ne voulez pas partager. Sinon, conservez un seul Gateway et + Utilisez des VPS séparés uniquement lorsque vous avez besoin d’une isolation forte (frontières de sécurité) ou de + configurations très différentes que vous ne voulez pas partager. Sinon, conservez une seule Gateway et utilisez plusieurs agents ou sous-agents. - - Oui — les Nodes sont le moyen de premier ordre pour atteindre votre ordinateur portable depuis un Gateway distant, et elles - permettent bien plus qu’un simple accès shell. Le Gateway fonctionne sur macOS/Linux (Windows via WSL2) et est - léger (un petit VPS ou une machine de type Raspberry Pi convient ; 4 GB de RAM suffisent largement), donc une configuration - courante consiste en un hôte toujours actif plus votre ordinateur portable comme Node. + + Oui — les nodes sont la solution de premier ordre pour atteindre votre ordinateur portable depuis une Gateway distante, et ils + offrent plus qu’un simple accès shell. La Gateway fonctionne sur macOS/Linux (Windows via WSL2) et est + légère (un petit VPS ou une machine de classe Raspberry Pi suffit ; 4 Go de RAM sont largement suffisants), donc une configuration + courante consiste en un hôte toujours actif plus votre ordinateur portable comme node. - - **Aucun SSH entrant nécessaire.** Les Nodes se connectent en sortie au WebSocket Gateway et utilisent l’association d’appareil. - - **Contrôles d’exécution plus sûrs.** `system.run` est protégé par les listes d’autorisation/approbations du Node sur cet ordinateur portable. - - **Davantage d’outils appareil.** Les Nodes exposent `canvas`, `camera` et `screen` en plus de `system.run`. - - **Automatisation locale du navigateur.** Gardez le Gateway sur un VPS, mais exécutez Chrome localement via un hôte Node sur l’ordinateur portable, ou attachez-vous à Chrome local sur l’hôte via Chrome MCP. + - **Aucun SSH entrant requis.** Les nodes se connectent en sortie à la WebSocket Gateway et utilisent l’appairage des appareils. + - **Contrôles d’exécution plus sûrs.** `system.run` est contrôlé par les listes d’autorisation/approbations du node sur cet ordinateur portable. + - **Davantage d’outils appareil.** Les nodes exposent `canvas`, `camera` et `screen` en plus de `system.run`. + - **Automatisation locale du navigateur.** Gardez la Gateway sur un VPS, mais exécutez Chrome localement via un hôte node sur l’ordinateur portable, ou rattachez-vous à Chrome local sur l’hôte via Chrome MCP. - SSH convient pour un accès shell ponctuel, mais les Nodes sont plus simples pour les flux de travail d’agent continus et + SSH convient pour un accès shell ponctuel, mais les nodes sont plus simples pour les workflows d’agent continus et l’automatisation des appareils. - Documentation : [Nodes](/fr/nodes), [Nodes CLI](/cli/nodes), [Browser](/fr/tools/browser). + Documentation : [Nodes](/fr/nodes), [CLI des Nodes](/cli/nodes), [Navigateur](/fr/tools/browser). - - Non. Un seul **Gateway** doit s’exécuter par hôte, sauf si vous exécutez intentionnellement des profils isolés (voir [Gateways multiples](/fr/gateway/multiple-gateways)). Les Nodes sont des périphériques qui se connectent - au Gateway (Nodes iOS/Android, ou « mode node » macOS dans l’application de barre de menus). Pour les hôtes Node headless - et le contrôle par CLI, voir [CLI Node host](/cli/node). + + Non. Une seule **gateway** doit s’exécuter par hôte, sauf si vous exécutez intentionnellement des profils isolés (voir [Gateways multiples](/fr/gateway/multiple-gateways)). Les nodes sont des périphériques qui se connectent + à la gateway (nodes iOS/Android, ou « mode node » macOS dans l’application de barre de menus). Pour les + hôtes node headless et le contrôle via CLI, voir [CLI hôte node](/cli/node). - Un redémarrage complet est requis pour les changements `gateway`, `discovery` et `canvasHost`. + Un redémarrage complet est requis pour les changements de `gateway`, `discovery` et `canvasHost`. Oui. - - `config.schema.lookup` : inspecter un sous-arbre de configuration avec son nœud de schéma superficiel, l’indice UI correspondant et les résumés immédiats des enfants avant d’écrire - - `config.get` : récupérer l’instantané courant + le hash - - `config.patch` : mise à jour partielle sûre (préférée pour la plupart des modifications RPC) ; recharge à chaud lorsque possible et redémarre lorsque nécessaire - - `config.apply` : valider + remplacer la configuration complète ; recharge à chaud lorsque possible et redémarre lorsque nécessaire + - `config.schema.lookup` : inspecte un sous-arbre de configuration avec son nœud de schéma peu profond, l’indice UI correspondant et des résumés immédiats des enfants avant l’écriture + - `config.get` : récupère l’instantané actuel + le hash + - `config.patch` : mise à jour partielle sûre (préférée pour la plupart des modifications RPC) ; recharge à chaud si possible et redémarre si nécessaire + - `config.apply` : valide + remplace la configuration complète ; recharge à chaud si possible et redémarre si nécessaire - L’outil d’exécution `gateway`, réservé au propriétaire, refuse toujours de réécrire `tools.exec.ask` / `tools.exec.security` ; les anciens alias `tools.bash.*` se normalisent vers les mêmes chemins exec protégés @@ -1838,7 +1835,7 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. } ``` - Cela définit votre espace de travail et restreint les personnes pouvant déclencher le bot. + Cela définit votre espace de travail et limite qui peut déclencher le bot. @@ -1858,27 +1855,27 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. - Dans la console d’administration Tailscale, activez MagicDNS afin que le VPS ait un nom stable. 4. **Utiliser le nom d’hôte tailnet** - SSH : `ssh user@your-vps.tailnet-xxxx.ts.net` - - Gateway WS : `ws://your-vps.tailnet-xxxx.ts.net:18789` + - WS Gateway : `ws://your-vps.tailnet-xxxx.ts.net:18789` - Si vous voulez la Control UI sans SSH, utilisez Tailscale Serve sur le VPS : + Si vous voulez le Control UI sans SSH, utilisez Tailscale Serve sur le VPS : ```bash openclaw gateway --tailscale serve ``` - Cela garde le Gateway lié à loopback et expose HTTPS via Tailscale. Voir [Tailscale](/fr/gateway/tailscale). + Cela maintient la gateway liée à loopback et expose HTTPS via Tailscale. Voir [Tailscale](/fr/gateway/tailscale). - - Serve expose la **Control UI + le WS Gateway**. Les Nodes se connectent via le même endpoint WS Gateway. + + Serve expose le **Control UI + WS de la Gateway**. Les nodes se connectent via le même endpoint WS Gateway. Configuration recommandée : - 1. **Assurez-vous que le VPS et le Mac sont sur le même tailnet**. + 1. **Assurez-vous que le VPS + le Mac sont sur le même tailnet**. 2. **Utilisez l’application macOS en mode Remote** (la cible SSH peut être le nom d’hôte tailnet). - L’application tunnelisera le port Gateway et se connectera comme Node. - 3. **Approuvez le Node** sur le Gateway : + L’application tunnellera le port Gateway et se connectera comme node. + 3. **Approuvez le node** sur la gateway : ```bash openclaw devices list @@ -1889,14 +1886,14 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. - - Si vous avez seulement besoin d’**outils locaux** (écran/caméra/exec) sur le deuxième ordinateur portable, ajoutez-le comme - **Node**. Cela conserve un seul Gateway et évite la duplication de configuration. Les outils Node locaux sont + + Si vous n’avez besoin que d’**outils locaux** (écran/caméra/exec) sur le second ordinateur portable, ajoutez-le comme + **node**. Cela conserve une seule Gateway et évite la duplication de configuration. Les outils node locaux sont actuellement réservés à macOS, mais nous prévoyons de les étendre à d’autres OS. - N’installez un deuxième Gateway que si vous avez besoin d’une **isolation forte** ou de deux bots totalement séparés. + N’installez une seconde Gateway que lorsque vous avez besoin d’une **isolation forte** ou de deux bots totalement séparés. - Documentation : [Nodes](/fr/nodes), [Nodes CLI](/cli/nodes), [Gateways multiples](/fr/gateway/multiple-gateways). + Documentation : [Nodes](/fr/nodes), [CLI des Nodes](/cli/nodes), [Gateways multiples](/fr/gateway/multiple-gateways). @@ -1905,14 +1902,14 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. - OpenClaw lit les variables d’environnement depuis le processus parent (shell, launchd/systemd, CI, etc.) et charge en plus : + OpenClaw lit les variables d’environnement à partir du processus parent (shell, launchd/systemd, CI, etc.) et charge en plus : - `.env` depuis le répertoire de travail courant - un `.env` global de secours depuis `~/.openclaw/.env` (alias `$OPENCLAW_STATE_DIR/.env`) Aucun des fichiers `.env` ne remplace les variables d’environnement existantes. - Vous pouvez également définir des variables d’environnement inline dans la configuration (appliquées uniquement si elles sont absentes de l’environnement du processus) : + Vous pouvez également définir des variables d’environnement inline dans la configuration (appliquées uniquement si elles manquent dans l’environnement du processus) : ```json5 { @@ -1923,15 +1920,15 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. } ``` - Voir [/environment](/fr/help/environment) pour l’ordre de priorité complet et les sources. + Voir [/environment](/fr/help/environment) pour la priorité complète et les sources. - + Deux correctifs courants : - 1. Placez les clés manquantes dans `~/.openclaw/.env` afin qu’elles soient prises en compte même lorsque le service n’hérite pas de l’environnement de votre shell. - 2. Activez l’import du shell (fonction pratique opt-in) : + 1. Placez les clés manquantes dans `~/.openclaw/.env` afin qu’elles soient récupérées même lorsque le service n’hérite pas de l’environnement de votre shell. + 2. Activez l’import du shell (confort facultatif) : ```json5 { @@ -1944,17 +1941,17 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. } ``` - Cela exécute votre shell de connexion et importe uniquement les clés attendues manquantes (sans jamais remplacer). Équivalents en variables d’environnement : + Cela exécute votre shell de connexion et importe uniquement les clés attendues manquantes (ne remplace jamais). Équivalents en variables d’environnement : `OPENCLAW_LOAD_SHELL_ENV=1`, `OPENCLAW_SHELL_ENV_TIMEOUT_MS=15000`. - + `openclaw models status` indique si **l’import de l’environnement du shell** est activé. « Shell env: off » - ne signifie **pas** que vos variables d’environnement sont absentes — cela signifie seulement qu’OpenClaw ne chargera pas - automatiquement votre shell de connexion. + ne signifie **pas** que vos variables d’environnement sont absentes — cela signifie simplement qu’OpenClaw ne chargera + pas automatiquement votre shell de connexion. - Si le Gateway s’exécute comme service (launchd/systemd), il n’héritera pas de l’environnement + Si la Gateway s’exécute comme service (launchd/systemd), elle n’héritera pas de l’environnement de votre shell. Corrigez cela de l’une des façons suivantes : 1. Placez le token dans `~/.openclaw/.env` : @@ -1964,15 +1961,15 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. ``` 2. Ou activez l’import du shell (`env.shellEnv.enabled: true`). - 3. Ou ajoutez-le à votre bloc `env` de configuration (appliqué uniquement s’il est absent). + 3. Ou ajoutez-le au bloc `env` de votre configuration (s’applique uniquement s’il manque). - Ensuite, redémarrez le gateway et revérifiez : + Redémarrez ensuite la gateway et revérifiez : ```bash openclaw models status ``` - Les tokens Copilot sont lus depuis `COPILOT_GITHUB_TOKEN` (également `GH_TOKEN` / `GITHUB_TOKEN`). + Les tokens Copilot sont lus depuis `COPILOT_GITHUB_TOKEN` (ainsi que `GH_TOKEN` / `GITHUB_TOKEN`). Voir [/concepts/model-providers](/fr/concepts/model-providers) et [/environment](/fr/help/environment). @@ -1986,9 +1983,9 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. - Les sessions peuvent expirer après `session.idleMinutes`, mais c’est **désactivé par défaut** (valeur par défaut **0**). + Les sessions peuvent expirer après `session.idleMinutes`, mais cela est **désactivé par défaut** (valeur par défaut **0**). Définissez une valeur positive pour activer l’expiration par inactivité. Une fois activée, le **message suivant** - après la période d’inactivité démarre un nouvel ID de session pour cette clé de chat. + après la période d’inactivité démarre un nouvel identifiant de session pour cette clé de chat. Cela ne supprime pas les transcriptions — cela démarre simplement une nouvelle session. ```json5 @@ -2001,29 +1998,29 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. - - Oui, via le **routage multi-agent** et les **sous-agents**. Vous pouvez créer un agent - coordinateur et plusieurs agents workers avec leurs propres espaces de travail et modèles. + + Oui, via le **routage multi-agent** et les **sous-agents**. Vous pouvez créer un agent coordinateur + et plusieurs agents workers avec leurs propres espaces de travail et modèles. - Cela dit, il vaut mieux voir cela comme une **expérience amusante**. Cela consomme beaucoup de tokens et est souvent + Cela dit, il vaut mieux voir cela comme une **expérience amusante**. C’est gourmand en tokens et souvent moins efficace que d’utiliser un seul bot avec des sessions séparées. Le modèle typique que nous - envisageons est un seul bot avec lequel vous échangez, avec différentes sessions pour le travail parallèle. Ce - bot peut aussi lancer des sous-agents lorsque c’est nécessaire. + envisageons est un seul bot avec lequel vous discutez, avec différentes sessions pour le travail parallèle. Ce + bot peut aussi lancer des sous-agents lorsque nécessaire. - Documentation : [Routage multi-agent](/fr/concepts/multi-agent), [Sous-agents](/fr/tools/subagents), [CLI agents](/cli/agents). + Documentation : [Routage multi-agent](/fr/concepts/multi-agent), [Sous-agents](/fr/tools/subagents), [CLI des agents](/cli/agents). - - Le contexte de session est limité par la fenêtre du modèle. Les chats longs, les sorties d’outils volumineuses ou de nombreux + + Le contexte de session est limité par la fenêtre du modèle. Les longs chats, les sorties d’outils importantes ou un grand nombre de fichiers peuvent déclencher une Compaction ou une troncature. Ce qui aide : - Demandez au bot de résumer l’état actuel et de l’écrire dans un fichier. - - Utilisez `/compact` avant les tâches longues, et `/new` lorsque vous changez de sujet. + - Utilisez `/compact` avant les longues tâches, et `/new` lorsque vous changez de sujet. - Conservez le contexte important dans l’espace de travail et demandez au bot de le relire. - - Utilisez des sous-agents pour le travail long ou parallèle afin que le chat principal reste plus petit. + - Utilisez des sous-agents pour les travaux longs ou parallèles afin que le chat principal reste plus petit. - Choisissez un modèle avec une fenêtre de contexte plus grande si cela arrive souvent. @@ -2049,16 +2046,16 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. Remarques : - - L’onboarding propose aussi **Reset** s’il détecte une configuration existante. Voir [Onboarding (CLI)](/fr/start/wizard). + - L’intégration propose aussi **Reset** si elle détecte une configuration existante. Voir [Intégration (CLI)](/fr/start/wizard). - Si vous avez utilisé des profils (`--profile` / `OPENCLAW_PROFILE`), réinitialisez chaque répertoire d’état (les valeurs par défaut sont `~/.openclaw-`). - - Réinitialisation dev : `openclaw gateway --dev --reset` (réservé au développement ; efface la configuration dev + identifiants + sessions + espace de travail). + - Réinitialisation dev : `openclaw gateway --dev --reset` (dev uniquement ; efface la configuration dev + identifiants + sessions + espace de travail). - - Utilisez l’une de ces options : + + Utilisez l’une des options suivantes : - - **Compacter** (conserve la conversation mais résume les anciens tours) : + - **Compacter** (conserve la conversation mais résume les tours plus anciens) : ``` /compact @@ -2075,40 +2072,40 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. Si cela continue : - - Activez ou ajustez le **session pruning** (`agents.defaults.contextPruning`) pour réduire les anciennes sorties d’outils. + - Activez ou ajustez **l’élagage de session** (`agents.defaults.contextPruning`) pour couper les anciennes sorties d’outils. - Utilisez un modèle avec une fenêtre de contexte plus grande. - Documentation : [Compaction](/fr/concepts/compaction), [Session pruning](/fr/concepts/session-pruning), [Gestion des sessions](/fr/concepts/session). + Documentation : [Compaction](/fr/concepts/compaction), [Élagage de session](/fr/concepts/session-pruning), [Gestion des sessions](/fr/concepts/session). - - Il s’agit d’une erreur de validation du fournisseur : le modèle a émis un bloc `tool_use` sans - le `input` requis. Cela signifie généralement que l’historique de session est obsolète ou corrompu (souvent après de longs fils + + Il s’agit d’une erreur de validation du fournisseur : le modèle a émis un bloc `tool_use` sans le + `input` requis. Cela signifie généralement que l’historique de session est obsolète ou corrompu (souvent après de longs fils ou un changement d’outil/de schéma). Correctif : démarrez une nouvelle session avec `/new` (message autonome). - - Les Heartbeat s’exécutent toutes les **30 min** par défaut (**1 h** lors de l’utilisation d’une authentification OAuth). Ajustez-les ou désactivez-les : + + Les Heartbeats s’exécutent toutes les **30 min** par défaut (**1 h** en cas d’authentification OAuth). Ajustez-les ou désactivez-les : ```json5 { agents: { defaults: { heartbeat: { - every: "2h", // or "0m" to disable + every: "2h", // ou "0m" pour désactiver }, }, }, } ``` - Si `HEARTBEAT.md` existe mais est en pratique vide (seulement des lignes vides et des - en-têtes markdown comme `# Heading`), OpenClaw ignore l’exécution Heartbeat afin d’économiser des appels API. - Si le fichier est absent, le Heartbeat s’exécute quand même et le modèle décide quoi faire. + Si `HEARTBEAT.md` existe mais est effectivement vide (uniquement des lignes vides et des en-têtes + Markdown comme `# Heading`), OpenClaw ignore l’exécution Heartbeat pour économiser les appels API. + Si le fichier est absent, Heartbeat s’exécute quand même et le modèle décide quoi faire. Les surcharges par agent utilisent `agents.list[].heartbeat`. Documentation : [Heartbeat](/fr/gateway/heartbeat). @@ -2140,65 +2137,65 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. openclaw logs --follow --json ``` - Recherchez `chatId` (ou `from`) se terminant par `@g.us`, comme : + Recherchez `chatId` (ou `from`) se terminant par `@g.us`, par exemple : `1234567890-1234567890@g.us`. - Option 2 (si déjà configuré/sur liste d’autorisation) : lister les groupes depuis la configuration : + Option 2 (si déjà configuré / sur liste d’autorisation) : lister les groupes depuis la configuration : ```bash openclaw directory groups list --channel whatsapp ``` - Documentation : [WhatsApp](/fr/channels/whatsapp), [Directory](/cli/directory), [Logs](/cli/logs). + Documentation : [WhatsApp](/fr/channels/whatsapp), [Répertoire](/cli/directory), [Journaux](/cli/logs). - Deux causes courantes : + Deux causes fréquentes : - Le filtrage par mention est activé (par défaut). Vous devez @mentionner le bot (ou correspondre à `mentionPatterns`). - Vous avez configuré `channels.whatsapp.groups` sans `"*"` et le groupe n’est pas sur la liste d’autorisation. - Voir [Groups](/fr/channels/groups) et [Messages de groupe](/fr/channels/group-messages). + Voir [Groupes](/fr/channels/groups) et [Messages de groupe](/fr/channels/group-messages). - Les chats directs sont regroupés dans la session principale par défaut. Les groupes/canaux ont leurs propres clés de session, et les sujets Telegram / fils Discord sont des sessions séparées. Voir [Groups](/fr/channels/groups) et [Messages de groupe](/fr/channels/group-messages). + Les chats directs sont regroupés dans la session principale par défaut. Les groupes/canaux ont leurs propres clés de session, et les topics Telegram / fils Discord sont des sessions séparées. Voir [Groupes](/fr/channels/groups) et [Messages de groupe](/fr/channels/group-messages). - Aucune limite stricte. Des dizaines (voire des centaines) conviennent, mais faites attention à : + Il n’y a pas de limite stricte. Des dizaines (voire des centaines) conviennent, mais surveillez : - - **Croissance du disque :** les sessions + transcriptions se trouvent sous `~/.openclaw/agents//sessions/`. - - **Coût en tokens :** plus d’agents signifie plus d’utilisation simultanée des modèles. + - **Croissance du disque :** les sessions + transcriptions vivent sous `~/.openclaw/agents//sessions/`. + - **Coût en tokens :** plus d’agents signifie plus d’utilisation concurrente des modèles. - **Surcharge opérationnelle :** profils d’authentification, espaces de travail et routage des canaux par agent. Conseils : - - Gardez un espace de travail **actif** par agent (`agents.defaults.workspace`). - - Épurez les anciennes sessions (supprimez les JSONL ou les entrées de stockage) si le disque grossit. - - Utilisez `openclaw doctor` pour repérer les espaces de travail orphelins et les incohérences de profils. + - Conservez un espace de travail **actif** par agent (`agents.defaults.workspace`). + - Élaguez les anciennes sessions (supprimez les entrées JSONL ou du magasin) si le disque grossit. + - Utilisez `openclaw doctor` pour repérer les espaces de travail errants et les incohérences de profil. - + Oui. Utilisez le **routage multi-agent** pour exécuter plusieurs agents isolés et router les messages entrants par canal/compte/pair. Slack est pris en charge comme canal et peut être lié à des agents spécifiques. - L’accès navigateur est puissant, mais ce n’est pas « faire tout ce qu’un humain peut faire » — l’anti-bot, les CAPTCHA et la MFA peuvent - encore bloquer l’automatisation. Pour le contrôle navigateur le plus fiable, utilisez Chrome MCP local sur l’hôte, + L’accès au navigateur est puissant, mais ce n’est pas « faire tout ce qu’un humain peut faire » — l’anti-bot, les CAPTCHA et la MFA peuvent + encore bloquer l’automatisation. Pour le contrôle de navigateur le plus fiable, utilisez Chrome MCP local sur l’hôte, ou utilisez CDP sur la machine qui exécute réellement le navigateur. Configuration recommandée : - Hôte Gateway toujours actif (VPS/Mac mini). - Un agent par rôle (liaisons). - - Canal/canaux Slack liés à ces agents. - - Navigateur local via Chrome MCP ou un Node si nécessaire. + - Canal(aux) Slack liés à ces agents. + - Navigateur local via Chrome MCP ou un node si nécessaire. Documentation : [Routage multi-agent](/fr/concepts/multi-agent), [Slack](/fr/channels/slack), - [Browser](/fr/tools/browser), [Nodes](/fr/nodes). + [Navigateur](/fr/tools/browser), [Nodes](/fr/nodes). @@ -2206,34 +2203,34 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. ## Modèles : valeurs par défaut, sélection, alias, changement - + Le modèle par défaut d’OpenClaw est celui que vous définissez comme : ``` agents.defaults.model.primary ``` - Les modèles sont référencés comme `provider/model` (exemple : `openai/gpt-5.4`). Si vous omettez le fournisseur, OpenClaw essaie d’abord un alias, puis une correspondance unique de fournisseur configuré pour cet identifiant de modèle exact, et seulement ensuite utilise le fournisseur par défaut configuré comme chemin de compatibilité obsolète. Si ce fournisseur n’expose plus le modèle par défaut configuré, OpenClaw se rabat sur le premier fournisseur/modèle configuré au lieu d’exposer une valeur par défaut obsolète d’un fournisseur supprimé. Vous devriez tout de même définir **explicitement** `provider/model`. + Les modèles sont référencés sous la forme `provider/model` (exemple : `openai/gpt-5.4`). Si vous omettez le fournisseur, OpenClaw essaie d’abord un alias, puis une correspondance unique de fournisseur configuré pour cet identifiant exact de modèle, et ce n’est qu’ensuite qu’il revient au fournisseur par défaut configuré comme chemin de compatibilité obsolète. Si ce fournisseur n’expose plus le modèle par défaut configuré, OpenClaw revient au premier fournisseur/modèle configuré au lieu d’exposer une valeur par défaut obsolète supprimée. Vous devriez néanmoins **définir explicitement** `provider/model`. - **Valeur par défaut recommandée :** utilisez le meilleur modèle de dernière génération disponible dans votre pile de fournisseurs. - **Pour les agents avec outils activés ou à entrée non fiable :** privilégiez la force du modèle plutôt que le coût. - **Pour le chat courant/à faible enjeu :** utilisez des modèles de secours moins chers et routez par rôle d’agent. + **Valeur par défaut recommandée :** utilisez le modèle de dernière génération le plus puissant disponible dans votre pile de fournisseurs. + **Pour les agents avec outils activés ou recevant des entrées non fiables :** privilégiez la qualité du modèle au coût. + **Pour le chat courant / à faible enjeu :** utilisez des modèles de secours moins chers et routez par rôle d’agent. MiniMax a sa propre documentation : [MiniMax](/fr/providers/minimax) et [Modèles locaux](/fr/gateway/local-models). - Règle générale : utilisez le **meilleur modèle que vous pouvez vous permettre** pour le travail à enjeu élevé, et un modèle moins cher + Règle générale : utilisez le **meilleur modèle que vous pouvez vous permettre** pour les tâches à fort enjeu, et un modèle moins cher pour le chat courant ou les résumés. Vous pouvez router les modèles par agent et utiliser des sous-agents pour - paralléliser les tâches longues (chaque sous-agent consomme des tokens). Voir [Models](/fr/concepts/models) et + paralléliser les longues tâches (chaque sous-agent consomme des tokens). Voir [Modèles](/fr/concepts/models) et [Sous-agents](/fr/tools/subagents). - Avertissement important : les modèles plus faibles ou trop quantifiés sont plus vulnérables à l’injection de prompt - et aux comportements dangereux. Voir [Security](/fr/gateway/security). + Avertissement important : les modèles plus faibles / trop quantifiés sont plus vulnérables à l’injection + de prompt et aux comportements dangereux. Voir [Sécurité](/fr/gateway/security). - Plus de contexte : [Models](/fr/concepts/models). + Plus de contexte : [Modèles](/fr/concepts/models). @@ -2248,45 +2245,45 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. - modifiez `agents.defaults.model` dans `~/.openclaw/openclaw.json` Évitez `config.apply` avec un objet partiel sauf si vous avez l’intention de remplacer toute la configuration. - Pour les modifications RPC, inspectez d’abord avec `config.schema.lookup` et préférez `config.patch`. La charge utile de lookup vous donne le chemin normalisé, la documentation/les contraintes du schéma superficiel, et les résumés immédiats des enfants. + Pour les modifications RPC, inspectez d’abord avec `config.schema.lookup` et privilégiez `config.patch`. La charge utile de lookup vous donne le chemin normalisé, la documentation/les contraintes du schéma peu profond et des résumés immédiats des enfants. pour les mises à jour partielles. - Si vous avez écrasé la configuration, restaurez-la depuis une sauvegarde ou relancez `openclaw doctor` pour réparer. + Si vous avez écrasé la configuration, restaurez depuis une sauvegarde ou relancez `openclaw doctor` pour réparer. - Documentation : [Models](/fr/concepts/models), [Configure](/cli/configure), [Config](/cli/config), [Doctor](/fr/gateway/doctor). + Documentation : [Modèles](/fr/concepts/models), [Configurer](/cli/configure), [Configuration](/cli/config), [Doctor](/fr/gateway/doctor). - Oui. Ollama est la voie la plus simple pour les modèles locaux. + Oui. Ollama est la solution la plus simple pour les modèles locaux. Configuration la plus rapide : 1. Installez Ollama depuis `https://ollama.com/download` - 2. Récupérez un modèle local tel que `ollama pull gemma4` + 2. Téléchargez un modèle local tel que `ollama pull gemma4` 3. Si vous voulez aussi des modèles cloud, exécutez `ollama signin` 4. Exécutez `openclaw onboard` et choisissez `Ollama` 5. Choisissez `Local` ou `Cloud + Local` Remarques : - - `Cloud + Local` vous donne les modèles cloud ainsi que vos modèles Ollama locaux - - les modèles cloud tels que `kimi-k2.5:cloud` n’ont pas besoin d’un téléchargement local + - `Cloud + Local` vous donne des modèles cloud ainsi que vos modèles Ollama locaux + - les modèles cloud tels que `kimi-k2.5:cloud` ne nécessitent pas de téléchargement local - pour un changement manuel, utilisez `openclaw models list` et `openclaw models set ollama/` - Note de sécurité : les modèles plus petits ou fortement quantifiés sont plus vulnérables à l’injection de prompt. - Nous recommandons fortement les **grands modèles** pour tout bot pouvant utiliser des outils. - Si vous voulez tout de même de petits modèles, activez le sandboxing et des listes d’autorisation d’outils strictes. + Remarque de sécurité : les modèles plus petits ou fortement quantifiés sont plus vulnérables à l’injection + de prompt. Nous recommandons fortement les **grands modèles** pour tout bot pouvant utiliser des outils. + Si vous voulez malgré tout de petits modèles, activez le sandboxing et des listes d’autorisation strictes pour les outils. Documentation : [Ollama](/fr/providers/ollama), [Modèles locaux](/fr/gateway/local-models), - [Fournisseurs de modèles](/fr/concepts/model-providers), [Security](/fr/gateway/security), + [Fournisseurs de modèles](/fr/concepts/model-providers), [Sécurité](/fr/gateway/security), [Sandboxing](/fr/gateway/sandboxing). - - Ces déploiements peuvent différer et changer avec le temps ; il n’existe pas de recommandation fixe de fournisseur. + - Ces déploiements peuvent différer et changer au fil du temps ; il n’existe pas de recommandation fixe de fournisseur. - Vérifiez le paramètre d’exécution actuel sur chaque gateway avec `openclaw models status`. - - Pour les agents sensibles à la sécurité/avec outils activés, utilisez le meilleur modèle de dernière génération disponible. + - Pour les agents sensibles à la sécurité / avec outils activés, utilisez le modèle de dernière génération le plus puissant disponible. @@ -2304,7 +2301,7 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. Ce sont les alias intégrés. Des alias personnalisés peuvent être ajoutés via `agents.defaults.models`. - Vous pouvez lister les modèles disponibles avec `/model`, `/model list`, ou `/model status`. + Vous pouvez lister les modèles disponibles avec `/model`, `/model list` ou `/model status`. `/model` (et `/model list`) affiche un sélecteur compact numéroté. Sélectionnez par numéro : @@ -2312,17 +2309,17 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. /model 3 ``` - Vous pouvez aussi forcer un profil d’authentification spécifique pour le fournisseur (par session) : + Vous pouvez également forcer un profil d’authentification spécifique pour le fournisseur (par session) : ``` /model opus@anthropic:default /model opus@anthropic:work ``` - Conseil : `/model status` montre quel agent est actif, quel fichier `auth-profiles.json` est utilisé, et quel profil d’authentification sera essayé ensuite. - Il montre aussi le endpoint fournisseur configuré (`baseUrl`) et le mode API (`api`) lorsqu’ils sont disponibles. + Conseil : `/model status` affiche quel agent est actif, quel fichier `auth-profiles.json` est utilisé et quel profil d’authentification sera essayé ensuite. + Il affiche également l’endpoint du fournisseur configuré (`baseUrl`) et le mode API (`api`) lorsqu’ils sont disponibles. - **Comment désépingler un profil défini avec @profile ?** + **Comment désépingler un profil que j’ai défini avec @profile ?** Relancez `/model` **sans** le suffixe `@profile` : @@ -2330,28 +2327,28 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. /model anthropic/claude-opus-4-6 ``` - Si vous voulez revenir à la valeur par défaut, choisissez-la depuis `/model` (ou envoyez `/model `). + Si vous voulez revenir au modèle par défaut, choisissez-le depuis `/model` (ou envoyez `/model `). Utilisez `/model status` pour confirmer quel profil d’authentification est actif. - + Oui. Définissez-en un comme valeur par défaut et changez selon le besoin : - - **Changement rapide (par session) :** `/model gpt-5.4` pour les tâches quotidiennes, `/model openai-codex/gpt-5.4` pour coder avec Codex OAuth. + - **Changement rapide (par session) :** `/model gpt-5.4` pour les tâches quotidiennes, `/model openai-codex/gpt-5.4` pour le code avec OAuth Codex. - **Valeur par défaut + changement :** définissez `agents.defaults.model.primary` sur `openai/gpt-5.4`, puis passez à `openai-codex/gpt-5.4` pour coder (ou l’inverse). - - **Sous-agents :** routez les tâches de codage vers des sous-agents avec un modèle par défaut différent. + - **Sous-agents :** routez les tâches de code vers des sous-agents avec un modèle par défaut différent. - Voir [Models](/fr/concepts/models) et [Commandes slash](/fr/tools/slash-commands). + Voir [Modèles](/fr/concepts/models) et [Commandes slash](/fr/tools/slash-commands). - Utilisez soit un basculement de session, soit une valeur par défaut de configuration : + Utilisez soit un basculement de session, soit une valeur par défaut dans la configuration : - **Par session :** envoyez `/fast on` pendant que la session utilise `openai/gpt-5.4` ou `openai-codex/gpt-5.4`. - **Valeur par défaut par modèle :** définissez `agents.defaults.models["openai/gpt-5.4"].params.fastMode` sur `true`. - - **Codex OAuth aussi :** si vous utilisez aussi `openai-codex/gpt-5.4`, définissez-y le même indicateur. + - **OAuth Codex aussi :** si vous utilisez aussi `openai-codex/gpt-5.4`, définissez le même drapeau là aussi. Exemple : @@ -2376,56 +2373,55 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. } ``` - Pour OpenAI, le mode rapide correspond à `service_tier = "priority"` sur les requêtes Responses natives prises en charge. Les surcharges de session `/fast` priment sur les valeurs par défaut de configuration. + Pour OpenAI, le mode rapide correspond à `service_tier = "priority"` sur les requêtes Responses natives prises en charge. Les surcharges de session `/fast` l’emportent sur les valeurs par défaut de la configuration. - Voir [Thinking and fast mode](/fr/tools/thinking) et [Mode rapide OpenAI](/fr/providers/openai#openai-fast-mode). + Voir [Thinking et mode rapide](/fr/tools/thinking) et [Mode rapide OpenAI](/fr/providers/openai#openai-fast-mode). - - Si `agents.defaults.models` est défini, il devient la **liste d’autorisation** pour `/model` et toutes les - surcharges de session. Choisir un modèle qui n’est pas dans cette liste renvoie : + + Si `agents.defaults.models` est défini, il devient la **liste d’autorisation** pour `/model` et toute + surcharge de session. Choisir un modèle qui n’est pas dans cette liste renvoie : ``` Model "provider/model" is not allowed. Use /model to list available models. ``` Cette erreur est renvoyée **à la place** d’une réponse normale. Correctif : ajoutez le modèle à - `agents.defaults.models`, supprimez la liste d’autorisation, ou choisissez un modèle depuis `/model list`. + `agents.defaults.models`, supprimez la liste d’autorisation, ou choisissez un modèle dans `/model list`. - - Cela signifie que le **fournisseur n’est pas configuré** (aucune configuration de fournisseur MiniMax ni aucun + + Cela signifie que le **fournisseur n’est pas configuré** (aucune configuration fournisseur MiniMax ou aucun profil d’authentification n’a été trouvé), donc le modèle ne peut pas être résolu. - Liste de vérification : + Liste de vérification pour corriger : - 1. Mettez à niveau vers une version actuelle d’OpenClaw (ou exécutez depuis la source `main`), puis redémarrez le gateway. - 2. Assurez-vous que MiniMax est configuré (assistant ou JSON), ou que l’authentification MiniMax + 1. Mettez à niveau vers une version actuelle d’OpenClaw (ou exécutez depuis les sources `main`), puis redémarrez la gateway. + 2. Assurez-vous que MiniMax est configuré (assistant ou JSON), ou qu’une authentification MiniMax existe dans l’environnement/les profils d’authentification afin que le fournisseur correspondant puisse être injecté - (`MINIMAX_API_KEY` pour `minimax`, `MINIMAX_OAUTH_TOKEN` ou OAuth MiniMax - stocké pour `minimax-portal`). - 3. Utilisez l’identifiant de modèle exact (sensible à la casse) pour votre chemin d’authentification : + (`MINIMAX_API_KEY` pour `minimax`, `MINIMAX_OAUTH_TOKEN` ou une authentification MiniMax + OAuth stockée pour `minimax-portal`). + 3. Utilisez l’identifiant exact du modèle (sensible à la casse) pour votre chemin d’authentification : `minimax/MiniMax-M2.7` ou `minimax/MiniMax-M2.7-highspeed` pour une configuration par clé API, ou `minimax-portal/MiniMax-M2.7` / - `minimax-portal/MiniMax-M2.7-highspeed` pour une configuration - OAuth. + `minimax-portal/MiniMax-M2.7-highspeed` pour une configuration OAuth. 4. Exécutez : ```bash openclaw models list ``` - puis choisissez dans la liste (ou `/model list` dans le chat). + et choisissez dans la liste (ou `/model list` dans le chat). - Voir [MiniMax](/fr/providers/minimax) et [Models](/fr/concepts/models). + Voir [MiniMax](/fr/providers/minimax) et [Modèles](/fr/concepts/models). - Oui. Utilisez **MiniMax comme valeur par défaut** et changez de modèle **par session** lorsque nécessaire. - Les modèles de secours servent aux **erreurs**, pas aux « tâches difficiles », donc utilisez `/model` ou un agent séparé. + Oui. Utilisez **MiniMax par défaut** et changez de modèle **par session** lorsque nécessaire. + Les secours sont destinés aux **erreurs**, pas aux « tâches difficiles », donc utilisez `/model` ou un agent séparé. **Option A : changement par session** @@ -2444,7 +2440,7 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. } ``` - Ensuite : + Puis : ``` /model gpt @@ -2456,11 +2452,11 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. - Valeur par défaut de l’agent B : OpenAI - Routez par agent ou utilisez `/agent` pour changer - Documentation : [Models](/fr/concepts/models), [Routage multi-agent](/fr/concepts/multi-agent), [MiniMax](/fr/providers/minimax), [OpenAI](/fr/providers/openai). + Documentation : [Modèles](/fr/concepts/models), [Routage multi-agent](/fr/concepts/multi-agent), [MiniMax](/fr/providers/minimax), [OpenAI](/fr/providers/openai). - + Oui. OpenClaw fournit quelques raccourcis par défaut (appliqués uniquement lorsque le modèle existe dans `agents.defaults.models`) : - `opus` → `anthropic/claude-opus-4-6` @@ -2476,7 +2472,7 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. - + Les alias proviennent de `agents.defaults.models..alias`. Exemple : ```json5 @@ -2494,12 +2490,12 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. } ``` - Ensuite, `/model sonnet` (ou `/` lorsque pris en charge) se résout vers cet identifiant de modèle. + Ensuite, `/model sonnet` (ou `/` lorsque c’est pris en charge) se résout vers cet identifiant de modèle. - OpenRouter (paiement au token ; nombreux modèles) : + OpenRouter (paiement au token ; de nombreux modèles) : ```json5 { @@ -2527,12 +2523,12 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. } ``` - Si vous référencez un fournisseur/modèle alors que la clé du fournisseur requise est absente, vous obtiendrez une erreur d’authentification à l’exécution (par ex. `No API key found for provider "zai"`). + Si vous référencez un fournisseur/modèle mais que la clé de fournisseur requise est absente, vous obtiendrez une erreur d’authentification à l’exécution (par ex. `No API key found for provider "zai"`). **Aucune clé API trouvée pour le fournisseur après l’ajout d’un nouvel agent** - Cela signifie généralement que le **nouvel agent** possède un magasin d’authentification vide. L’authentification est par agent et - stockée dans : + Cela signifie généralement que le **nouvel agent** a un magasin d’authentification vide. L’authentification est par agent et + est stockée dans : ``` ~/.openclaw/agents//agent/auth-profiles.json @@ -2543,84 +2539,84 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. - Exécutez `openclaw agents add ` et configurez l’authentification pendant l’assistant. - Ou copiez `auth-profiles.json` depuis le `agentDir` de l’agent principal vers le `agentDir` du nouvel agent. - Ne réutilisez **pas** `agentDir` entre plusieurs agents ; cela provoque des collisions d’authentification/session. + Ne réutilisez **pas** `agentDir` entre agents ; cela provoque des collisions d’authentification/session. -## Basculement de modèle et « Tous les modèles ont échoué » +## Basculement de modèle et « All models failed » Le basculement se produit en deux étapes : - 1. **Rotation de profil d’authentification** au sein du même fournisseur. - 2. **Modèle de secours** vers le modèle suivant dans `agents.defaults.model.fallbacks`. + 1. **Rotation des profils d’authentification** au sein du même fournisseur. + 2. **Repli de modèle** vers le modèle suivant dans `agents.defaults.model.fallbacks`. - Des cooldowns s’appliquent aux profils en échec (backoff exponentiel), afin qu’OpenClaw puisse continuer à répondre même lorsqu’un fournisseur est limité par son débit ou temporairement en panne. + Des temps de refroidissement s’appliquent aux profils en échec (backoff exponentiel), de sorte qu’OpenClaw peut continuer à répondre même lorsqu’un fournisseur est limité en débit ou temporairement en échec. Le compartiment de limitation de débit inclut plus que les simples réponses `429`. OpenClaw - traite également des messages comme `Too many concurrent requests`, + traite aussi des messages comme `Too many concurrent requests`, `ThrottlingException`, `concurrency limit reached`, - `workers_ai ... quota limit exceeded`, `resource exhausted`, et les limites - périodiques de fenêtre d’utilisation (`weekly/monthly limit reached`) comme des - limitations de débit justifiant un basculement. + `workers_ai ... quota limit exceeded`, `resource exhausted` et les limites + périodiques de fenêtre d’usage (`weekly/monthly limit reached`) comme des limitations + justifiant un basculement. Certaines réponses qui ressemblent à de la facturation ne sont pas des `402`, et certaines réponses HTTP `402` restent également dans ce compartiment transitoire. Si un fournisseur renvoie - un texte explicite de facturation sur `401` ou `403`, OpenClaw peut encore le garder dans - la voie facturation, mais les correspondances textuelles spécifiques au fournisseur restent limitées au - fournisseur qui les possède (par exemple OpenRouter `Key limit exceeded`). Si un message `402` - ressemble plutôt à une fenêtre d’utilisation réessayable ou - à une limite de dépenses d’organisation/espace de travail (`daily limit reached, resets tomorrow`, + un texte explicite de facturation sur `401` ou `403`, OpenClaw peut quand même le conserver dans + la voie facturation, mais les matchers de texte spécifiques à un fournisseur restent limités au + fournisseur auquel ils appartiennent (par exemple OpenRouter `Key limit exceeded`). Si un message `402` + ressemble plutôt à une fenêtre d’usage réessayable ou à une + limite de dépense d’organisation/espace de travail (`daily limit reached, resets tomorrow`, `organization spending limit exceeded`), OpenClaw le traite comme - `rate_limit`, pas comme une longue désactivation de facturation. + `rate_limit`, et non comme une désactivation longue liée à la facturation. - Les erreurs de dépassement de contexte sont différentes : des signatures telles que + Les erreurs de dépassement de contexte sont différentes : des signatures comme `request_too_large`, `input exceeds the maximum number of tokens`, `input token count exceeds the maximum number of input tokens`, `input is too long for the model`, ou `ollama error: context length - exceeded` restent sur le chemin Compaction/réessai au lieu de faire avancer le - modèle de secours. + exceeded` restent sur le chemin Compaction/réessai au lieu d’avancer vers le + repli de modèle. - Le texte générique d’erreur serveur est volontairement plus restreint que « tout ce qui contient - unknown/error ». OpenClaw traite bien des formes transitoires délimitées par fournisseur + Le texte générique d’erreur serveur est volontairement plus étroit que « n’importe quoi contenant + unknown/error ». OpenClaw traite bien des formes transitoires limitées à un fournisseur telles que le simple `An unknown error occurred` d’Anthropic, le simple - `Provider returned error` d’OpenRouter, les erreurs de raison d’arrêt comme `Unhandled stop reason: - error`, les charges utiles JSON `api_error` avec un texte serveur transitoire + `Provider returned error` d’OpenRouter, les erreurs de stop-reason comme `Unhandled stop reason: + error`, les charges utiles JSON `api_error` avec du texte serveur transitoire (`internal server error`, `unknown error, 520`, `upstream error`, `backend - error`), et les erreurs de fournisseur occupé telles que `ModelNotReadyException` comme - des signaux de timeout/surcharge justifiant un basculement lorsque le contexte fournisseur + error`), et les erreurs de fournisseur occupé comme `ModelNotReadyException` comme des + signaux de timeout/surcharge justifiant un basculement lorsque le contexte du fournisseur correspond. - Le texte de repli interne générique comme `LLM request failed with an unknown - error.` reste prudent et ne déclenche pas à lui seul le modèle de secours. + Le texte de secours interne générique comme `LLM request failed with an unknown + error.` reste conservateur et ne déclenche pas à lui seul le repli de modèle. - Cela signifie que le système a tenté d’utiliser l’identifiant de profil d’authentification `anthropic:default`, mais n’a pas pu trouver les identifiants correspondants dans le magasin d’authentification attendu. + Cela signifie que le système a tenté d’utiliser l’identifiant de profil d’authentification `anthropic:default`, mais n’a pas pu trouver d’identifiants pour celui-ci dans le magasin d’authentification attendu. - **Liste de vérification :** + **Liste de vérification pour corriger :** - - **Confirmez où vivent les profils d’authentification** (nouveaux chemins vs chemins historiques) + - **Confirmez où vivent les profils d’authentification** (nouveaux vs anciens chemins) - Actuel : `~/.openclaw/agents//agent/auth-profiles.json` - - Historique : `~/.openclaw/agent/*` (migré par `openclaw doctor`) - - **Confirmez que votre variable d’environnement est chargée par le Gateway** - - Si vous avez défini `ANTHROPIC_API_KEY` dans votre shell mais exécutez le Gateway via systemd/launchd, il peut ne pas l’hériter. Placez-la dans `~/.openclaw/.env` ou activez `env.shellEnv`. + - Hérité : `~/.openclaw/agent/*` (migré par `openclaw doctor`) + - **Confirmez que votre variable d’environnement est chargée par la Gateway** + - Si vous définissez `ANTHROPIC_API_KEY` dans votre shell mais exécutez la Gateway via systemd/launchd, elle peut ne pas en hériter. Placez-la dans `~/.openclaw/.env` ou activez `env.shellEnv`. - **Assurez-vous de modifier le bon agent** - Les configurations multi-agent signifient qu’il peut y avoir plusieurs fichiers `auth-profiles.json`. - - **Vérifiez rapidement l’état du modèle/de l’authentification** + - **Vérifiez l’état modèle/authentification** - Utilisez `openclaw models status` pour voir les modèles configurés et si les fournisseurs sont authentifiés. - **Liste de vérification pour "No credentials found for profile anthropic"** + **Liste de vérification pour corriger "No credentials found for profile anthropic"** - Cela signifie que l’exécution est épinglée à un profil d’authentification Anthropic, mais que le Gateway + Cela signifie que l’exécution est épinglée à un profil d’authentification Anthropic, mais que la Gateway ne parvient pas à le trouver dans son magasin d’authentification. - **Utiliser Claude CLI** - Exécutez `openclaw models auth login --provider anthropic --method cli --set-default` sur l’hôte gateway. - - **Si vous voulez plutôt utiliser une clé API** - - Placez `ANTHROPIC_API_KEY` dans `~/.openclaw/.env` sur l’**hôte gateway**. + - **Si vous voulez utiliser une clé API à la place** + - Placez `ANTHROPIC_API_KEY` dans `~/.openclaw/.env` sur **l’hôte gateway**. - Effacez tout ordre épinglé qui force un profil manquant : ```bash @@ -2632,24 +2628,24 @@ pour l’utilisation/la facturation et augmentez les limites si nécessaire. - - Si votre configuration de modèle inclut Google Gemini comme modèle de secours (ou si vous êtes passé à un raccourci Gemini), OpenClaw l’essaiera lors du basculement de modèle. Si vous n’avez pas configuré d’identifiants Google, vous verrez `No API key found for provider "google"`. + + Si votre configuration de modèle inclut Google Gemini comme repli (ou si vous êtes passé à un raccourci Gemini), OpenClaw l’essaiera pendant le repli de modèle. Si vous n’avez pas configuré les identifiants Google, vous verrez `No API key found for provider "google"`. - Correctif : fournissez une authentification Google, ou retirez/évitez les modèles Google dans `agents.defaults.model.fallbacks` / alias afin que le basculement ne route pas vers eux. + Correctif : fournissez soit une authentification Google, soit supprimez/évitez les modèles Google dans `agents.defaults.model.fallbacks` / alias afin que le repli ne route pas vers eux. **LLM request rejected: thinking signature required (Google Antigravity)** - Cause : l’historique de session contient des **blocs de réflexion sans signatures** (souvent issus + Cause : l’historique de session contient des **blocs de réflexion sans signature** (souvent issus d’un flux interrompu/partiel). Google Antigravity exige des signatures pour les blocs de réflexion. - Correctif : OpenClaw supprime désormais les blocs de réflexion non signés pour Google Antigravity Claude. Si cela apparaît encore, démarrez une **nouvelle session** ou définissez `/thinking off` pour cet agent. + Correctif : OpenClaw retire désormais les blocs de réflexion non signés pour Google Antigravity Claude. Si cela apparaît encore, démarrez une **nouvelle session** ou définissez `/thinking off` pour cet agent. ## Profils d’authentification : ce qu’ils sont et comment les gérer -Voir aussi : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tokens, schémas multi-comptes) +Liens associés : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tokens, schémas multi-comptes) @@ -2662,27 +2658,27 @@ Voir aussi : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tok - OpenClaw utilise des identifiants préfixés par fournisseur comme : + OpenClaw utilise des identifiants préfixés par le fournisseur comme : - - `anthropic:default` (courant lorsqu’aucune identité e-mail n’existe) + - `anthropic:default` (courant lorsqu’il n’existe pas d’identité e-mail) - `anthropic:` pour les identités OAuth - - des identifiants personnalisés que vous choisissez (par ex. `anthropic:work`) + - identifiants personnalisés que vous choisissez (par ex. `anthropic:work`) - Oui. La configuration prend en charge des métadonnées facultatives pour les profils ainsi qu’un ordre par fournisseur (`auth.order.`). Cela **ne stocke pas** de secrets ; cela mappe les identifiants au fournisseur/mode et définit l’ordre de rotation. + Oui. La configuration prend en charge des métadonnées facultatives pour les profils et un ordre par fournisseur (`auth.order.`). Cela ne stocke **pas** de secrets ; cela associe les identifiants au fournisseur/mode et définit l’ordre de rotation. - OpenClaw peut temporairement ignorer un profil s’il est dans un court **cooldown** (limitations de débit/timeouts/échecs d’authentification) ou dans un état **désactivé** plus long (facturation/crédits insuffisants). Pour inspecter cela, exécutez `openclaw models status --json` et vérifiez `auth.unusableProfiles`. Réglage : `auth.cooldowns.billingBackoffHours*`. + OpenClaw peut temporairement ignorer un profil s’il est dans un court **cooldown** (limitations de débit/timeouts/échecs d’authentification) ou dans un état **désactivé** plus long (facturation/crédits insuffisants). Pour l’inspecter, exécutez `openclaw models status --json` et regardez `auth.unusableProfiles`. Réglage : `auth.cooldowns.billingBackoffHours*`. Les cooldowns de limitation de débit peuvent être limités à un modèle. Un profil qui est en cooldown - pour un modèle peut encore être utilisable pour un modèle frère chez le même fournisseur, - tandis que les fenêtres de facturation/désactivation bloquent toujours tout le profil. + pour un modèle peut rester utilisable pour un modèle voisin chez le même fournisseur, + tandis que les fenêtres de facturation/désactivation bloquent toujours le profil entier. - Vous pouvez aussi définir une surcharge d’ordre **par agent** (stockée dans le `auth-state.json` de cet agent) via la CLI : + Vous pouvez également définir une surcharge d’ordre **par agent** (stockée dans `auth-state.json` de cet agent) via la CLI : ```bash - # Prend par défaut l’agent par défaut configuré (omettez --agent) + # Utilise par défaut l’agent par défaut configuré (omettez --agent) openclaw models auth order get --provider anthropic # Verrouiller la rotation sur un seul profil (n’essayer que celui-ci) @@ -2712,10 +2708,10 @@ Voir aussi : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tok - + OpenClaw prend en charge les deux : - - **OAuth** exploite souvent un accès par abonnement (lorsqu’applicable). + - **OAuth** exploite souvent un accès par abonnement (lorsque applicable). - **Les clés API** utilisent une facturation au token. L’assistant prend explicitement en charge Anthropic Claude CLI, OpenAI Codex OAuth et les clés API. @@ -2723,11 +2719,11 @@ Voir aussi : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tok -## Gateway : ports, « déjà en cours d’exécution » et mode distant +## Gateway : ports, « already running » et mode distant - - `gateway.port` contrôle le port multiplexé unique pour WebSocket + HTTP (Control UI, hooks, etc.). + + `gateway.port` contrôle l’unique port multiplexé pour WebSocket + HTTP (Control UI, hooks, etc.). Ordre de priorité : @@ -2737,19 +2733,19 @@ Voir aussi : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tok - - Parce que « running » est la vue du **superviseur** (launchd/systemd/schtasks). La sonde RPC correspond à la CLI qui se connecte réellement au WebSocket gateway et appelle `status`. + + Parce que « running » est la vue du **superviseur** (launchd/systemd/schtasks). La sonde de connectivité correspond au moment où la CLI se connecte réellement à la WebSocket gateway. Utilisez `openclaw gateway status` et faites confiance à ces lignes : - - `Probe target:` (l’URL réellement utilisée par la sonde) + - `Probe target:` (l’URL que la sonde a réellement utilisée) - `Listening:` (ce qui est réellement lié au port) - - `Last gateway error:` (cause racine courante lorsque le processus est vivant mais que le port n’écoute pas) + - `Last gateway error:` (cause profonde fréquente lorsque le processus est vivant mais que le port n’écoute pas) - - Vous modifiez un fichier de configuration alors que le service en exécute un autre (souvent à cause d’un décalage `--profile` / `OPENCLAW_STATE_DIR`). + + Vous modifiez un fichier de configuration alors que le service en exécute un autre (souvent un décalage `--profile` / `OPENCLAW_STATE_DIR`). Correctif : @@ -2757,18 +2753,18 @@ Voir aussi : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tok openclaw gateway install --force ``` - Exécutez cela depuis le même `--profile` / environnement que celui que vous voulez voir utilisé par le service. + Exécutez cela depuis le même `--profile` / environnement que celui que vous voulez faire utiliser au service. - OpenClaw impose un verrou d’exécution en liant immédiatement le listener WebSocket au démarrage (par défaut `ws://127.0.0.1:18789`). Si la liaison échoue avec `EADDRINUSE`, il lève `GatewayLockError`, indiquant qu’une autre instance écoute déjà. + OpenClaw applique un verrou d’exécution en liant immédiatement l’écouteur WebSocket au démarrage (par défaut `ws://127.0.0.1:18789`). Si la liaison échoue avec `EADDRINUSE`, il déclenche `GatewayLockError`, indiquant qu’une autre instance écoute déjà. - Correctif : arrêtez l’autre instance, libérez le port, ou exécutez avec `openclaw gateway --port `. + Correctif : arrêtez l’autre instance, libérez le port ou exécutez avec `openclaw gateway --port `. - + Définissez `gateway.mode: "remote"` et pointez vers une URL WebSocket distante, éventuellement avec des identifiants distants à secret partagé : ```json5 @@ -2788,53 +2784,53 @@ Voir aussi : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tok - `openclaw gateway` ne démarre que lorsque `gateway.mode` est `local` (ou si vous passez le drapeau de surcharge). - L’application macOS surveille le fichier de configuration et change de mode en direct lorsque ces valeurs changent. - - `gateway.remote.token` / `.password` sont uniquement des identifiants distants côté client ; ils n’activent pas à eux seuls l’authentification du gateway local. + - `gateway.remote.token` / `.password` ne sont que des identifiants distants côté client ; ils n’activent pas à eux seuls l’authentification locale de la gateway. - + Le chemin d’authentification de votre gateway et la méthode d’authentification de l’UI ne correspondent pas. - Faits (d’après le code) : + Faits (issus du code) : - - La Control UI conserve le token dans `sessionStorage` pour la session de l’onglet du navigateur courant et l’URL gateway sélectionnée, donc les actualisations dans le même onglet continuent de fonctionner sans rétablir une persistance longue durée du token dans localStorage. - - Sur `AUTH_TOKEN_MISMATCH`, les clients de confiance peuvent tenter un unique nouvel essai borné avec un token d’appareil mis en cache lorsque le gateway renvoie des indications de nouvel essai (`canRetryWithDeviceToken=true`, `recommendedNextStep=retry_with_device_token`). - - Ce nouvel essai avec token mis en cache réutilise désormais les scopes approuvés mis en cache et stockés avec le token d’appareil. Les appelants explicites `deviceToken` / `scopes` explicites conservent toujours leur ensemble de scopes demandé au lieu d’hériter des scopes mis en cache. - - En dehors de ce chemin de nouvel essai, l’ordre de priorité de l’authentification de connexion est : token/mot de passe partagé explicite d’abord, puis `deviceToken` explicite, puis token d’appareil stocké, puis token bootstrap. - - Les vérifications de scope du token bootstrap sont préfixées par rôle. La liste d’autorisation intégrée de l’opérateur bootstrap ne satisfait que les requêtes opérateur ; les rôles node ou d’autres rôles non opérateur nécessitent toujours des scopes sous leur propre préfixe de rôle. + - Le Control UI conserve le token dans `sessionStorage` pour la session actuelle de l’onglet navigateur et l’URL de gateway sélectionnée, de sorte que les actualisations dans le même onglet continuent de fonctionner sans restaurer une persistance longue durée du token dans localStorage. + - Sur `AUTH_TOKEN_MISMATCH`, les clients de confiance peuvent tenter un nouvel essai borné avec un token d’appareil en cache lorsque la gateway renvoie des indications de réessai (`canRetryWithDeviceToken=true`, `recommendedNextStep=retry_with_device_token`). + - Ce nouvel essai avec token en cache réutilise désormais les scopes approuvés en cache stockés avec le token d’appareil. Les appelants explicites `deviceToken` / `scopes` explicites conservent toujours l’ensemble de scopes demandé au lieu d’hériter des scopes en cache. + - En dehors de ce chemin de réessai, la priorité d’authentification de connexion est : token/mot de passe partagé explicite d’abord, puis `deviceToken` explicite, puis token d’appareil stocké, puis token bootstrap. + - Les vérifications de portée des tokens bootstrap sont préfixées par rôle. La liste d’autorisation intégrée de l’opérateur bootstrap ne satisfait que les requêtes opérateur ; les rôles node ou autres rôles non opérateur nécessitent toujours des scopes sous leur propre préfixe de rôle. Correctif : - - Le plus rapide : `openclaw dashboard` (affiche + copie l’URL du tableau de bord, tente de l’ouvrir ; affiche une indication SSH si headless). + - Le plus rapide : `openclaw dashboard` (affiche + copie l’URL du tableau de bord, essaie de l’ouvrir ; montre une indication SSH si headless). - Si vous n’avez pas encore de token : `openclaw doctor --generate-gateway-token`. - - Si c’est distant, tunnelisez d’abord : `ssh -N -L 18789:127.0.0.1:18789 user@host` puis ouvrez `http://127.0.0.1:18789/`. - - Mode secret partagé : définissez `gateway.auth.token` / `OPENCLAW_GATEWAY_TOKEN` ou `gateway.auth.password` / `OPENCLAW_GATEWAY_PASSWORD`, puis collez le secret correspondant dans les paramètres de la Control UI. + - Si vous êtes à distance, créez d’abord un tunnel : `ssh -N -L 18789:127.0.0.1:18789 user@host` puis ouvrez `http://127.0.0.1:18789/`. + - Mode secret partagé : définissez `gateway.auth.token` / `OPENCLAW_GATEWAY_TOKEN` ou `gateway.auth.password` / `OPENCLAW_GATEWAY_PASSWORD`, puis collez le secret correspondant dans les paramètres du Control UI. - Mode Tailscale Serve : assurez-vous que `gateway.auth.allowTailscale` est activé et que vous ouvrez l’URL Serve, pas une URL loopback/tailnet brute qui contourne les en-têtes d’identité Tailscale. - - Mode trusted-proxy : assurez-vous de passer par le proxy conscient de l’identité non-loopback configuré, et non par un proxy loopback sur le même hôte ni une URL gateway brute. - - Si le décalage persiste après l’unique nouvel essai, faites tourner/réapprouvez le token de l’appareil appairé : + - Mode trusted-proxy : assurez-vous de passer par le proxy avec gestion d’identité non-loopback configuré, et non par un proxy loopback sur le même hôte ou une URL gateway brute. + - Si le décalage persiste après l’unique nouvel essai, faites tourner / réapprouvez le token d’appareil appairé : - `openclaw devices list` - `openclaw devices rotate --device --role operator` - - Si cet appel de rotation indique qu’il a été refusé, vérifiez deux choses : - - les sessions d’appareil appairé ne peuvent faire tourner que **leur propre** appareil, sauf si elles disposent aussi de `operator.admin` - - les valeurs `--scope` explicites ne peuvent pas dépasser les scopes opérateur actuels de l’appelant - - Toujours bloqué ? Exécutez `openclaw status --all` et suivez [Troubleshooting](/fr/gateway/troubleshooting). Voir [Dashboard](/web/dashboard) pour les détails d’authentification. + - Si cet appel rotate indique qu’il a été refusé, vérifiez deux points : + - les sessions d’appareil appairé ne peuvent faire tourner que **leur propre** appareil à moins d’avoir également `operator.admin` + - les valeurs explicites `--scope` ne peuvent pas dépasser les scopes opérateur actuels de l’appelant + - Toujours bloqué ? Exécutez `openclaw status --all` et suivez [Dépannage](/fr/gateway/troubleshooting). Voir [Dashboard](/web/dashboard) pour les détails d’authentification. - Le bind `tailnet` choisit une IP Tailscale depuis vos interfaces réseau (100.64.0.0/10). Si la machine n’est pas sur Tailscale (ou si l’interface est inactive), il n’y a rien sur quoi se lier. + La liaison `tailnet` choisit une IP Tailscale parmi vos interfaces réseau (100.64.0.0/10). Si la machine n’est pas sur Tailscale (ou si l’interface est hors service), il n’y a rien à lier. Correctif : - - Démarrez Tailscale sur cet hôte (afin qu’il possède une adresse 100.x), ou + - Démarrez Tailscale sur cet hôte (afin qu’il ait une adresse 100.x), ou - Passez à `gateway.bind: "loopback"` / `"lan"`. - Remarque : `tailnet` est explicite. `auto` préfère loopback ; utilisez `gateway.bind: "tailnet"` lorsque vous voulez une liaison réservée au tailnet. + Remarque : `tailnet` est explicite. `auto` préfère loopback ; utilisez `gateway.bind: "tailnet"` lorsque vous voulez une liaison uniquement tailnet. - En général, non — un seul Gateway peut exécuter plusieurs canaux de messagerie et agents. N’utilisez plusieurs Gateways que lorsque vous avez besoin de redondance (par ex. bot de secours) ou d’une isolation forte. + En général non — une seule Gateway peut exécuter plusieurs canaux de messagerie et agents. Utilisez plusieurs Gateways uniquement lorsque vous avez besoin de redondance (par ex. bot de secours) ou d’une isolation forte. Oui, mais vous devez isoler : @@ -2846,7 +2842,7 @@ Voir aussi : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tok Configuration rapide (recommandée) : - Utilisez `openclaw --profile ...` par instance (crée automatiquement `~/.openclaw-`). - - Définissez un `gateway.port` unique dans chaque configuration de profil (ou passez `--port` pour les exécutions manuelles). + - Définissez un `gateway.port` unique dans la configuration de chaque profil (ou passez `--port` pour les exécutions manuelles). - Installez un service par profil : `openclaw --profile gateway install`. Les profils suffixent aussi les noms de service (`ai.openclaw.` ; anciens `com.openclaw.*`, `openclaw-gateway-.service`, `OpenClaw Gateway ()`). @@ -2855,20 +2851,20 @@ Voir aussi : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tok - Le Gateway est un **serveur WebSocket**, et il s’attend à ce que le tout premier message soit - une trame `connect`. S’il reçoit autre chose, il ferme la connexion + La Gateway est un **serveur WebSocket**, et elle s’attend à ce que le tout premier message soit + une trame `connect`. Si elle reçoit autre chose, elle ferme la connexion avec le **code 1008** (violation de politique). - Causes courantes : + Causes fréquentes : - Vous avez ouvert l’URL **HTTP** dans un navigateur (`http://...`) au lieu d’un client WS. - Vous avez utilisé le mauvais port ou le mauvais chemin. - - Un proxy ou tunnel a supprimé les en-têtes d’authentification ou envoyé une requête non Gateway. + - Un proxy ou un tunnel a supprimé les en-têtes d’authentification ou envoyé une requête non Gateway. Correctifs rapides : 1. Utilisez l’URL WS : `ws://:18789` (ou `wss://...` si HTTPS). - 2. N’ouvrez pas le port WS dans un onglet normal du navigateur. + 2. N’ouvrez pas le port WS dans un onglet de navigateur normal. 3. Si l’authentification est activée, incluez le token/mot de passe dans la trame `connect`. Si vous utilisez la CLI ou le TUI, l’URL doit ressembler à : @@ -2882,7 +2878,7 @@ Voir aussi : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tok -## Journalisation et débogage +## Journaux et débogage @@ -2892,7 +2888,7 @@ Voir aussi : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tok /tmp/openclaw/openclaw-YYYY-MM-DD.log ``` - Vous pouvez définir un chemin stable via `logging.file`. Le niveau du journal fichier est contrôlé par `logging.level`. La verbosité console est contrôlée par `--verbose` et `logging.consoleLevel`. + Vous pouvez définir un chemin stable via `logging.file`. Le niveau de journal fichier est contrôlé par `logging.level`. La verbosité console est contrôlée par `--verbose` et `logging.consoleLevel`. Suivi de journal le plus rapide : @@ -2900,32 +2896,32 @@ Voir aussi : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tok openclaw logs --follow ``` - Journaux de service/superviseur (lorsque le gateway s’exécute via launchd/systemd) : + Journaux du service/superviseur (lorsque la gateway s’exécute via launchd/systemd) : - macOS : `$OPENCLAW_STATE_DIR/logs/gateway.log` et `gateway.err.log` (par défaut : `~/.openclaw/logs/...` ; les profils utilisent `~/.openclaw-/logs/...`) - Linux : `journalctl --user -u openclaw-gateway[-].service -n 200 --no-pager` - Windows : `schtasks /Query /TN "OpenClaw Gateway ()" /V /FO LIST` - Voir [Troubleshooting](/fr/gateway/troubleshooting) pour plus d’informations. + Voir [Dépannage](/fr/gateway/troubleshooting) pour plus d’informations. - Utilisez les assistants gateway : + Utilisez les helpers gateway : ```bash openclaw gateway status openclaw gateway restart ``` - Si vous exécutez le gateway manuellement, `openclaw gateway --force` peut récupérer le port. Voir [Gateway](/fr/gateway). + Si vous exécutez la gateway manuellement, `openclaw gateway --force` peut récupérer le port. Voir [Gateway](/fr/gateway). Il existe **deux modes d’installation Windows** : - **1) WSL2 (recommandé) :** le Gateway s’exécute dans Linux. + **1) WSL2 (recommandé) :** la Gateway s’exécute dans Linux. Ouvrez PowerShell, entrez dans WSL, puis redémarrez : @@ -2941,7 +2937,7 @@ Voir aussi : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tok openclaw gateway run ``` - **2) Windows natif (non recommandé) :** le Gateway s’exécute directement dans Windows. + **2) Windows natif (non recommandé) :** la Gateway s’exécute directement dans Windows. Ouvrez PowerShell et exécutez : @@ -2960,8 +2956,8 @@ Voir aussi : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tok - - Commencez par un contrôle rapide de santé : + + Commencez par un balayage rapide de l’état de santé : ```bash openclaw status @@ -2970,26 +2966,26 @@ Voir aussi : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tok openclaw logs --follow ``` - Causes courantes : + Causes fréquentes : - - L’authentification du modèle n’est pas chargée sur l’**hôte gateway** (vérifiez `models status`). - - L’appairage/la liste d’autorisation du canal bloque les réponses (vérifiez la configuration du canal + les journaux). + - l’authentification du modèle n’est pas chargée sur **l’hôte gateway** (vérifiez `models status`). + - l’appairage/la liste d’autorisation du canal bloque les réponses (vérifiez la configuration du canal + les journaux). - WebChat/Dashboard est ouvert sans le bon token. - Si vous êtes en distant, confirmez que le tunnel/la connexion Tailscale est actif/active et que le - WebSocket Gateway est accessible. + Si vous êtes à distance, confirmez que le tunnel/la connexion Tailscale fonctionne et que la + WebSocket Gateway est joignable. - Documentation : [Canaux](/fr/channels), [Troubleshooting](/fr/gateway/troubleshooting), [Accès distant](/fr/gateway/remote). + Documentation : [Canaux](/fr/channels), [Dépannage](/fr/gateway/troubleshooting), [Accès distant](/fr/gateway/remote). Cela signifie généralement que l’UI a perdu la connexion WebSocket. Vérifiez : - 1. Le Gateway est-il en cours d’exécution ? `openclaw gateway status` - 2. Le Gateway est-il sain ? `openclaw status` + 1. La Gateway fonctionne-t-elle ? `openclaw gateway status` + 2. La Gateway est-elle saine ? `openclaw status` 3. L’UI a-t-elle le bon token ? `openclaw dashboard` - 4. En distant, le lien tunnel/Tailscale est-il actif ? + 4. Si vous êtes à distance, le tunnel/la liaison Tailscale fonctionne-t-il ? Puis suivez les journaux : @@ -2997,31 +2993,31 @@ Voir aussi : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tok openclaw logs --follow ``` - Documentation : [Dashboard](/web/dashboard), [Accès distant](/fr/gateway/remote), [Troubleshooting](/fr/gateway/troubleshooting). + Documentation : [Dashboard](/web/dashboard), [Accès distant](/fr/gateway/remote), [Dépannage](/fr/gateway/troubleshooting). - Commencez par les journaux et le statut du canal : + Commencez par les journaux et l’état du canal : ```bash openclaw channels status openclaw channels logs --channel telegram ``` - Puis faites correspondre l’erreur : + Faites ensuite correspondre l’erreur : - - `BOT_COMMANDS_TOO_MUCH` : le menu Telegram contient trop d’entrées. OpenClaw réduit déjà jusqu’à la limite Telegram et réessaie avec moins de commandes, mais certaines entrées du menu doivent encore être supprimées. Réduisez les commandes de plugin/Skill/personnalisées, ou désactivez `channels.telegram.commands.native` si vous n’avez pas besoin du menu. + - `BOT_COMMANDS_TOO_MUCH` : le menu Telegram contient trop d’entrées. OpenClaw le réduit déjà à la limite Telegram et réessaie avec moins de commandes, mais certaines entrées du menu doivent encore être supprimées. Réduisez les commandes de plugin/skill/personnalisées, ou désactivez `channels.telegram.commands.native` si vous n’avez pas besoin du menu. - `TypeError: fetch failed`, `Network request for 'setMyCommands' failed!`, ou erreurs réseau similaires : si vous êtes sur un VPS ou derrière un proxy, confirmez que le HTTPS sortant est autorisé et que le DNS fonctionne pour `api.telegram.org`. - Si le Gateway est distant, assurez-vous de consulter les journaux sur l’hôte Gateway. + Si la Gateway est distante, assurez-vous de consulter les journaux sur l’hôte Gateway. Documentation : [Telegram](/fr/channels/telegram), [Dépannage des canaux](/fr/channels/troubleshooting). - Confirmez d’abord que le Gateway est accessible et que l’agent peut s’exécuter : + Confirmez d’abord que la Gateway est joignable et que l’agent peut s’exécuter : ```bash openclaw status @@ -3029,14 +3025,14 @@ Voir aussi : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tok openclaw logs --follow ``` - Dans le TUI, utilisez `/status` pour voir l’état actuel. Si vous attendez des réponses dans un canal - de chat, assurez-vous que la distribution est activée (`/deliver on`). + Dans le TUI, utilisez `/status` pour voir l’état actuel. Si vous attendez des réponses dans un + canal de chat, assurez-vous que la livraison est activée (`/deliver on`). Documentation : [TUI](/web/tui), [Commandes slash](/fr/tools/slash-commands). - + Si vous avez installé le service : ```bash @@ -3045,7 +3041,7 @@ Voir aussi : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tok ``` Cela arrête/démarre le **service supervisé** (launchd sur macOS, systemd sur Linux). - Utilisez ceci lorsque le Gateway s’exécute en arrière-plan comme démon. + Utilisez cela lorsque la Gateway s’exécute en arrière-plan comme daemon. Si vous l’exécutez au premier plan, arrêtez-le avec Ctrl-C, puis : @@ -3059,36 +3055,36 @@ Voir aussi : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tok - `openclaw gateway restart` : redémarre le **service en arrière-plan** (launchd/systemd). - - `openclaw gateway` : exécute le gateway **au premier plan** pour cette session de terminal. + - `openclaw gateway` : exécute la gateway **au premier plan** pour cette session de terminal. Si vous avez installé le service, utilisez les commandes gateway. Utilisez `openclaw gateway` lorsque vous voulez une exécution ponctuelle au premier plan. - - Démarrez le Gateway avec `--verbose` pour obtenir plus de détails dans la console. Puis inspectez le fichier journal pour l’authentification des canaux, le routage des modèles et les erreurs RPC. + + Démarrez la Gateway avec `--verbose` pour obtenir plus de détails dans la console. Examinez ensuite le fichier journal pour l’authentification des canaux, le routage des modèles et les erreurs RPC. ## Médias et pièces jointes - - Les pièces jointes sortantes de l’agent doivent inclure une ligne `MEDIA:` (sur sa propre ligne). Voir [Configuration de l’assistant OpenClaw](/fr/start/openclaw) et [Envoi d’agent](/fr/tools/agent-send). + + Les pièces jointes sortantes de l’agent doivent inclure une ligne `MEDIA:` (sur sa propre ligne). Voir [Configuration de l’assistant OpenClaw](/fr/start/openclaw) et [Envoi agent](/fr/tools/agent-send). - Envoi via CLI : + Envoi CLI : ```bash openclaw message send --target +15555550123 --message "Here you go" --media /path/to/file.png ``` - Vérifiez aussi : + Vérifiez également : - Le canal cible prend en charge les médias sortants et n’est pas bloqué par des listes d’autorisation. - - Le fichier respecte les limites de taille du fournisseur (les images sont redimensionnées à un maximum de 2048 px). - - `tools.fs.workspaceOnly=true` limite les envois par chemin local à l’espace de travail, temp/media-store et aux fichiers validés par sandbox. - - `tools.fs.workspaceOnly=false` permet à `MEDIA:` d’envoyer des fichiers locaux de l’hôte que l’agent peut déjà lire, mais uniquement pour les médias plus les types de documents sûrs (images, audio, vidéo, PDF et documents Office). Les fichiers texte brut et assimilables à des secrets restent bloqués. + - Le fichier respecte les limites de taille du fournisseur (les images sont redimensionnées à 2048 px max). + - `tools.fs.workspaceOnly=true` limite les envois de chemin local à l’espace de travail, au store temp/media et aux fichiers validés par sandbox. + - `tools.fs.workspaceOnly=false` permet à `MEDIA:` d’envoyer des fichiers locaux de l’hôte que l’agent peut déjà lire, mais uniquement pour les médias plus les types de documents sûrs (images, audio, vidéo, PDF et documents Office). Les fichiers texte brut et de type secret restent bloqués. Voir [Images](/fr/nodes/images). @@ -3098,113 +3094,113 @@ Voir aussi : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tok ## Sécurité et contrôle d’accès - + Traitez les DM entrants comme des entrées non fiables. Les valeurs par défaut sont conçues pour réduire le risque : - - Le comportement par défaut sur les canaux compatibles DM est l’**association** : - - Les expéditeurs inconnus reçoivent un code d’association ; le bot ne traite pas leur message. + - Le comportement par défaut sur les canaux compatibles DM est l’**appairage** : + - Les expéditeurs inconnus reçoivent un code d’appairage ; le bot ne traite pas leur message. - Approuvez avec : `openclaw pairing approve --channel [--account ] ` - - Les demandes en attente sont limitées à **3 par canal** ; vérifiez `openclaw pairing list --channel [--account ]` si un code n’est pas arrivé. - - Ouvrir publiquement les DM nécessite un opt-in explicite (`dmPolicy: "open"` et liste d’autorisation `"*"`). + - Les requêtes en attente sont limitées à **3 par canal** ; vérifiez `openclaw pairing list --channel [--account ]` si un code n’est pas arrivé. + - Ouvrir publiquement les DM exige une activation explicite (`dmPolicy: "open"` et liste d’autorisation `"*"`). Exécutez `openclaw doctor` pour faire remonter les politiques DM risquées. - - Non. L’injection de prompt concerne le **contenu non fiable**, pas seulement le fait de savoir qui peut envoyer un DM au bot. - Si votre assistant lit du contenu externe (recherche/récupération web, pages navigateur, e-mails, - documents, pièces jointes, journaux collés), ce contenu peut inclure des instructions qui tentent + + Non. L’injection de prompt concerne le **contenu non fiable**, pas seulement qui peut envoyer un DM au bot. + Si votre assistant lit du contenu externe (recherche/récupération web, pages de navigateur, e-mails, + documents, pièces jointes, journaux collés), ce contenu peut inclure des instructions qui essaient de détourner le modèle. Cela peut arriver même si **vous êtes le seul expéditeur**. - Le risque le plus important apparaît lorsque les outils sont activés : le modèle peut être amené à + Le plus grand risque apparaît lorsque les outils sont activés : le modèle peut être amené à exfiltrer du contexte ou à appeler des outils en votre nom. Réduisez le rayon d’impact en : - utilisant un agent « lecteur » en lecture seule ou sans outils pour résumer le contenu non fiable - gardant `web_search` / `web_fetch` / `browser` désactivés pour les agents avec outils activés - traitant aussi comme non fiable le texte décodé des fichiers/documents : OpenResponses - `input_file` et l’extraction des pièces jointes média encapsulent tous deux le texte extrait dans + `input_file` et l’extraction de pièces jointes multimédias encapsulent tous deux le texte extrait dans des marqueurs explicites de frontière de contenu externe au lieu de transmettre le texte brut du fichier - - utilisant le sandboxing et des listes d’autorisation d’outils strictes + - appliquant le sandboxing et des listes d’autorisation strictes pour les outils - Détails : [Security](/fr/gateway/security). + Détails : [Sécurité](/fr/gateway/security). - - Oui, pour la plupart des configurations. Isoler le bot avec des comptes et numéros de téléphone distincts - réduit le rayon d’impact en cas de problème. Cela facilite aussi la rotation - des identifiants ou la révocation d’accès sans impacter vos comptes personnels. + + Oui, pour la plupart des configurations. Isoler le bot avec des comptes et numéros de téléphone séparés + réduit le rayon d’impact si quelque chose tourne mal. Cela facilite aussi la rotation + des identifiants ou la révocation d’accès sans affecter vos comptes personnels. - Commencez petit. Donnez accès uniquement aux outils et comptes dont vous avez réellement besoin, puis élargissez + Commencez petit. Donnez accès uniquement aux outils et comptes dont vous avez réellement besoin, puis étendez plus tard si nécessaire. - Documentation : [Security](/fr/gateway/security), [Association](/fr/channels/pairing). + Documentation : [Sécurité](/fr/gateway/security), [Appairage](/fr/channels/pairing). - - Nous **ne** recommandons **pas** une autonomie totale sur vos messages personnels. Le schéma le plus sûr est : + + Nous **ne recommandons pas** une autonomie totale sur vos messages personnels. Le schéma le plus sûr est : - - Garder les DM en **mode association** ou avec une liste d’autorisation stricte. - - Utiliser un **numéro ou compte séparé** si vous voulez qu’il envoie des messages en votre nom. - - Le laisser rédiger, puis **approuver avant envoi**. + - Gardez les DM en mode **appairage** ou avec une liste d’autorisation stricte. + - Utilisez un **numéro ou compte séparé** si vous voulez qu’il envoie des messages en votre nom. + - Laissez-le rédiger, puis **approuvez avant l’envoi**. Si vous voulez expérimenter, faites-le sur un compte dédié et gardez-le isolé. Voir - [Security](/fr/gateway/security). + [Sécurité](/fr/gateway/security). - - Oui, **si** l’agent est limité au chat et que l’entrée est fiable. Les petits modèles sont - plus susceptibles de subir des détournements d’instructions, donc évitez-les pour les agents avec outils activés - ou lorsqu’ils lisent du contenu non fiable. Si vous devez utiliser un plus petit modèle, verrouillez les - outils et exécutez-le dans un sandbox. Voir [Security](/fr/gateway/security). + + Oui, **si** l’agent est uniquement destiné au chat et que l’entrée est fiable. Les plus petits niveaux sont + plus sensibles au détournement d’instructions, donc évitez-les pour les agents avec outils activés + ou lorsqu’ils lisent du contenu non fiable. Si vous devez utiliser un modèle plus petit, verrouillez + les outils et exécutez dans un sandbox. Voir [Sécurité](/fr/gateway/security). - - Les codes d’association sont envoyés **uniquement** lorsqu’un expéditeur inconnu envoie un message au bot et que + + Les codes d’appairage ne sont envoyés **que** lorsqu’un expéditeur inconnu envoie un message au bot et que `dmPolicy: "pairing"` est activé. `/start` à lui seul ne génère pas de code. - Vérifiez les demandes en attente : + Vérifiez les requêtes en attente : ```bash openclaw pairing list telegram ``` - Si vous voulez un accès immédiat, mettez votre identifiant d’expéditeur sur liste d’autorisation ou définissez `dmPolicy: "open"` + Si vous voulez un accès immédiat, ajoutez votre ID expéditeur à la liste d’autorisation ou définissez `dmPolicy: "open"` pour ce compte. - - Non. La politique DM WhatsApp par défaut est l’**association**. Les expéditeurs inconnus ne reçoivent qu’un code d’association et leur message **n’est pas traité**. OpenClaw ne répond qu’aux chats qu’il reçoit ou aux envois explicites que vous déclenchez. + + Non. La politique DM WhatsApp par défaut est l’**appairage**. Les expéditeurs inconnus ne reçoivent qu’un code d’appairage et leur message **n’est pas traité**. OpenClaw ne répond qu’aux chats qu’il reçoit ou aux envois explicites que vous déclenchez. - Approuvez l’association avec : + Approuvez l’appairage avec : ```bash openclaw pairing approve whatsapp ``` - Lister les demandes en attente : + Lister les requêtes en attente : ```bash openclaw pairing list whatsapp ``` - Invite du numéro de téléphone dans l’assistant : il est utilisé pour définir votre **liste d’autorisation/propriétaire** afin que vos propres DM soient autorisés. Il n’est pas utilisé pour l’envoi automatique. Si vous utilisez votre numéro WhatsApp personnel, utilisez ce numéro et activez `channels.whatsapp.selfChatMode`. + Invite de numéro de téléphone de l’assistant : elle sert à définir votre **liste d’autorisation/propriétaire** afin que vos propres DM soient autorisés. Elle n’est pas utilisée pour l’envoi automatique. Si vous exécutez cela sur votre numéro WhatsApp personnel, utilisez ce numéro et activez `channels.whatsapp.selfChatMode`. -## Commandes de chat, annulation de tâches, et « il ne veut pas s’arrêter » +## Commandes de chat, interruption de tâches et « il ne s’arrête pas » - - La plupart des messages internes ou d’outils n’apparaissent que lorsque **verbose**, **trace** ou **reasoning** est activé + + La plupart des messages internes ou d’outils n’apparaissent que lorsque **verbose**, **trace** ou **reasoning** sont activés pour cette session. - Correctif dans le chat où vous le voyez : + Correctif dans le chat où vous les voyez : ``` /verbose off @@ -3212,16 +3208,16 @@ Voir aussi : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tok /reasoning off ``` - Si cela reste bruyant, vérifiez les paramètres de session dans la Control UI et définissez verbose - sur **inherit**. Vérifiez aussi que vous n’utilisez pas un profil de bot avec `verboseDefault` défini + Si cela reste bruyant, vérifiez les paramètres de session dans le Control UI et définissez verbose + sur **inherit**. Vérifiez également que vous n’utilisez pas un profil de bot avec `verboseDefault` défini sur `on` dans la configuration. - Documentation : [Thinking and verbose](/fr/tools/thinking), [Security](/fr/gateway/security#reasoning-verbose-output-in-groups). + Documentation : [Thinking et verbose](/fr/tools/thinking), [Sécurité](/fr/gateway/security#reasoning-verbose-output-in-groups). - Envoyez l’un de ces messages **comme message autonome** (sans slash) : + Envoyez l’un de ces éléments **comme message autonome** (sans slash) : ``` stop @@ -3245,9 +3241,9 @@ Voir aussi : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tok interrupt ``` - Ce sont des déclencheurs d’annulation (pas des commandes slash). + Ce sont des déclencheurs d’abandon (pas des commandes slash). - Pour les processus en arrière-plan (provenant de l’outil exec), vous pouvez demander à l’agent d’exécuter : + Pour les processus en arrière-plan (issus de l’outil exec), vous pouvez demander à l’agent d’exécuter : ``` process action:kill sessionId:XXX @@ -3255,15 +3251,15 @@ Voir aussi : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tok Vue d’ensemble des commandes slash : voir [Commandes slash](/fr/tools/slash-commands). - La plupart des commandes doivent être envoyées comme message **autonome** commençant par `/`, mais quelques raccourcis (comme `/status`) fonctionnent aussi inline pour les expéditeurs sur liste d’autorisation. + La plupart des commandes doivent être envoyées comme **message autonome** commençant par `/`, mais quelques raccourcis (comme `/status`) fonctionnent aussi inline pour les expéditeurs figurant sur liste d’autorisation. - OpenClaw bloque par défaut la messagerie **inter-fournisseur**. Si un appel d’outil est lié + OpenClaw bloque par défaut la messagerie **inter-fournisseurs**. Si un appel d’outil est lié à Telegram, il n’enverra pas vers Discord sauf si vous l’autorisez explicitement. - Activez la messagerie inter-fournisseur pour l’agent : + Activez la messagerie inter-fournisseurs pour l’agent : ```json5 { @@ -3278,18 +3274,18 @@ Voir aussi : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tok } ``` - Redémarrez le gateway après avoir modifié la configuration. + Redémarrez la gateway après avoir modifié la configuration. - - Le mode file d’attente contrôle la façon dont les nouveaux messages interagissent avec une exécution en cours. Utilisez `/queue` pour changer de mode : + + Le mode de file contrôle la manière dont les nouveaux messages interagissent avec une exécution en cours. Utilisez `/queue` pour changer de mode : - `steer` - les nouveaux messages redirigent la tâche en cours - `followup` - exécute les messages un par un - `collect` - regroupe les messages et répond une seule fois (par défaut) - - `steer-backlog` - redirige maintenant, puis traite l’arriéré - - `interrupt` - interrompt l’exécution en cours et redémarre à neuf + - `steer-backlog` - redirige maintenant, puis traite le backlog + - `interrupt` - abandonne l’exécution en cours et redémarre à neuf Vous pouvez ajouter des options comme `debounce:2s cap:25 drop:summarize` pour les modes followup. @@ -3300,10 +3296,10 @@ Voir aussi : [/concepts/oauth](/fr/concepts/oauth) (flux OAuth, stockage des tok - Dans OpenClaw, les identifiants et la sélection du modèle sont séparés. Définir `ANTHROPIC_API_KEY` (ou stocker une clé API Anthropic dans les profils d’authentification) active l’authentification, mais le modèle par défaut réel est celui que vous configurez dans `agents.defaults.model.primary` (par exemple `anthropic/claude-sonnet-4-6` ou `anthropic/claude-opus-4-6`). Si vous voyez `No credentials found for profile "anthropic:default"`, cela signifie que le Gateway n’a pas pu trouver d’identifiants Anthropic dans le `auth-profiles.json` attendu pour l’agent en cours d’exécution. + Dans OpenClaw, les identifiants et la sélection du modèle sont séparés. Définir `ANTHROPIC_API_KEY` (ou stocker une clé API Anthropic dans les profils d’authentification) active l’authentification, mais le modèle par défaut réel est celui que vous configurez dans `agents.defaults.model.primary` (par exemple, `anthropic/claude-sonnet-4-6` ou `anthropic/claude-opus-4-6`). Si vous voyez `No credentials found for profile "anthropic:default"`, cela signifie que la Gateway n’a pas pu trouver les identifiants Anthropic dans le `auth-profiles.json` attendu pour l’agent en cours d’exécution. --- -Toujours bloqué ? Demandez dans [Discord](https://discord.com/invite/clawd) ou ouvrez une [discussion GitHub](https://github.com/openclaw/openclaw/discussions). +Toujours bloqué ? Demandez de l’aide sur [Discord](https://discord.com/invite/clawd) ou ouvrez une [discussion GitHub](https://github.com/openclaw/openclaw/discussions). diff --git a/docs/fr/help/testing.md b/docs/fr/help/testing.md index 3658b2946..658227829 100644 --- a/docs/fr/help/testing.md +++ b/docs/fr/help/testing.md @@ -1,137 +1,139 @@ --- read_when: - - Exécuter les tests en local ou en CI - - Ajouter des tests de régression pour les bugs de modèle/fournisseur - - Déboguer le comportement du Gateway + de l’agent -summary: 'Kit de test : suites unitaires/e2e/en direct, exécuteurs Docker, et ce que couvre chaque test' -title: Test + - Exécution des tests en local ou dans la CI + - Ajout de régressions pour les bugs de modèle/fournisseur + - Débogage du comportement de la Gateway + de l’agent +summary: 'Kit de test : suites unitaires/e2e/live, exécuteurs Docker et ce que couvre chaque test' +title: Tests x-i18n: - generated_at: "2026-04-18T06:43:37Z" + generated_at: "2026-04-20T07:05:58Z" model: gpt-5.4 provider: openai - source_hash: 7cdd2048ba58e606fd68703977c2b33000abdb1826b6589ce25a35c53468726a + source_hash: 88457038e2e2c7940d0348762d0ece187111a8c61fa9bad54b39eade4217ddbc source_path: help/testing.md workflow: 15 --- # Tests -OpenClaw comporte trois suites Vitest (unit/integration, e2e, live) et un petit ensemble d’exécuteurs Docker. +OpenClaw dispose de trois suites Vitest (unitaires/intégration, e2e, live) et d’un petit ensemble d’exécuteurs Docker. -Ce document est un guide « comment nous testons » : +Cette documentation est un guide « comment nous testons » : - Ce que couvre chaque suite (et ce qu’elle ne couvre délibérément _pas_) - Quelles commandes exécuter pour les workflows courants (local, avant push, débogage) - Comment les tests live découvrent les identifiants et sélectionnent les modèles/fournisseurs -- Comment ajouter des tests de régression pour des problèmes réels de modèle/fournisseur +- Comment ajouter des régressions pour des problèmes réels de modèle/fournisseur ## Démarrage rapide -La plupart du temps : +La plupart du temps : -- Barrière complète (attendue avant push) : `pnpm build && pnpm check && pnpm test` -- Exécution locale plus rapide de la suite complète sur une machine bien dimensionnée : `pnpm test:max` -- Boucle de surveillance Vitest directe : `pnpm test:watch` -- Le ciblage direct de fichiers route désormais aussi les chemins d’extension/canal : `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` -- Préférez d’abord les exécutions ciblées lorsque vous itérez sur un seul échec. -- Site QA adossé à Docker : `pnpm qa:lab:up` -- Voie QA adossée à une VM Linux : `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` +- Barrière complète (attendue avant push) : `pnpm build && pnpm check && pnpm test` +- Exécution locale plus rapide de la suite complète sur une machine bien dimensionnée : `pnpm test:max` +- Boucle directe Vitest en mode watch : `pnpm test:watch` +- Le ciblage direct de fichiers prend maintenant aussi en charge les chemins d’extension/canal : `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` +- Préférez d’abord les exécutions ciblées lorsque vous itérez sur une seule défaillance. +- Site QA adossé à Docker : `pnpm qa:lab:up` +- Voie QA adossée à une VM Linux : `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` -Quand vous modifiez des tests ou souhaitez davantage de confiance : +Lorsque vous modifiez des tests ou souhaitez davantage de confiance : -- Barrière de couverture : `pnpm test:coverage` -- Suite E2E : `pnpm test:e2e` +- Barrière de couverture : `pnpm test:coverage` +- Suite E2E : `pnpm test:e2e` -Lors du débogage de vrais fournisseurs/modèles (nécessite de vrais identifiants) : +Lors du débogage de vrais fournisseurs/modèles (nécessite de vrais identifiants) : -- Suite live (modèles + sondes Gateway outil/image) : `pnpm test:live` -- Cibler silencieusement un fichier live : `pnpm test:live -- src/agents/models.profiles.live.test.ts` +- Suite live (modèles + sondes d’outils/images Gateway) : `pnpm test:live` +- Cibler silencieusement un seul fichier live : `pnpm test:live -- src/agents/models.profiles.live.test.ts` -Astuce : lorsque vous n’avez besoin que d’un seul cas en échec, préférez restreindre les tests live via les variables d’environnement de liste d’autorisation décrites ci-dessous. +Astuce : lorsque vous n’avez besoin que d’un seul cas défaillant, préférez restreindre les tests live via les variables d’environnement de liste d’autorisation décrites ci-dessous. ## Exécuteurs spécifiques à la QA -Ces commandes se trouvent à côté des suites de test principales lorsque vous avez besoin du réalisme de QA-lab : +Ces commandes se trouvent à côté des suites de test principales lorsque vous avez besoin du réalisme de QA-lab : - `pnpm openclaw qa suite` - - Exécute directement sur l’hôte des scénarios QA adossés au dépôt. - - Exécute en parallèle plusieurs scénarios sélectionnés par défaut avec des workers Gateway isolés, jusqu’à 64 workers ou le nombre de scénarios sélectionnés. Utilisez `--concurrency ` pour ajuster le nombre de workers, ou `--concurrency 1` pour l’ancienne voie sérielle. + - Exécute directement sur l’hôte les scénarios QA adossés au dépôt. + - Exécute par défaut plusieurs scénarios sélectionnés en parallèle avec des workers Gateway isolés. `qa-channel` utilise par défaut une concurrence de 4 (bornée par le nombre de scénarios sélectionnés). Utilisez `--concurrency ` pour ajuster le nombre de workers, ou `--concurrency 1` pour retrouver l’ancienne voie sérielle. + - Se termine avec un code non nul si un scénario échoue. Utilisez `--allow-failures` si vous voulez les artefacts sans code de sortie en échec. - Prend en charge les modes fournisseur `live-frontier`, `mock-openai` et `aimock`. - `aimock` démarre un serveur fournisseur local adossé à AIMock pour une couverture expérimentale des fixtures et des simulations de protocole sans remplacer la voie `mock-openai` orientée scénario. + `aimock` démarre un serveur fournisseur local adossé à AIMock pour la couverture expérimentale des fixtures et des mocks de protocole, sans remplacer la voie `mock-openai` orientée scénarios. - `pnpm openclaw qa suite --runner multipass` - Exécute la même suite QA dans une VM Linux Multipass jetable. - Conserve le même comportement de sélection de scénarios que `qa suite` sur l’hôte. - - Réutilise les mêmes drapeaux de sélection fournisseur/modèle que `qa suite`. - - Les exécutions live transmettent les entrées d’authentification QA prises en charge et pratiques pour l’invité : - clés de fournisseur basées sur l’environnement, chemin de configuration du fournisseur live QA et `CODEX_HOME` lorsqu’il est présent. + - Réutilise les mêmes options de sélection fournisseur/modèle que `qa suite`. + - Les exécutions live transfèrent les entrées d’authentification QA prises en charge et pratiques pour l’invité : + clés fournisseur basées sur l’environnement, chemin de configuration du fournisseur live QA et `CODEX_HOME` lorsqu’il est présent. - Les répertoires de sortie doivent rester sous la racine du dépôt afin que l’invité puisse réécrire via l’espace de travail monté. - - Écrit le rapport QA + résumé habituels ainsi que les journaux Multipass sous + - Écrit le rapport + résumé QA habituels ainsi que les journaux Multipass sous `.artifacts/qa-e2e/...`. - `pnpm qa:lab:up` - Démarre le site QA adossé à Docker pour le travail QA de type opérateur. - `pnpm openclaw qa aimock` - - Démarre uniquement le serveur fournisseur AIMock local pour des tests de fumée directs du protocole. + - Démarre uniquement le serveur fournisseur local AIMock pour des tests smoke directs du protocole. - `pnpm openclaw qa matrix` - Exécute la voie QA live Matrix contre un homeserver Tuwunel jetable adossé à Docker. - - Cet hôte QA est aujourd’hui réservé au dépôt/développement. Les installations OpenClaw empaquetées n’embarquent pas `qa-lab`, donc elles n’exposent pas `openclaw qa`. - - Les clones du dépôt chargent directement l’exécuteur intégré ; aucune étape d’installation de Plugin distincte n’est nécessaire. - - Provisionne trois utilisateurs Matrix temporaires (`driver`, `sut`, `observer`) plus une salle privée, puis démarre un processus enfant Gateway QA avec le vrai Plugin Matrix comme transport SUT. - - Utilise par défaut l’image stable Tuwunel épinglée `ghcr.io/matrix-construct/tuwunel:v1.5.1`. Remplacez-la avec `OPENCLAW_QA_MATRIX_TUWUNEL_IMAGE` lorsque vous devez tester une autre image. - - Matrix n’expose pas de drapeaux partagés de source d’identifiants, car la voie provisionne localement des utilisateurs jetables. - - Écrit sous `.artifacts/qa-e2e/...` un rapport QA Matrix, un résumé, un artefact des événements observés et un journal combiné stdout/stderr. + - Cet hôte QA est aujourd’hui réservé au dépôt/au développement. Les installations OpenClaw packagées n’embarquent pas `qa-lab` et n’exposent donc pas `openclaw qa`. + - Les clones du dépôt chargent directement l’exécuteur intégré ; aucune étape d’installation de Plugin séparée n’est nécessaire. + - Provisionne trois utilisateurs Matrix temporaires (`driver`, `sut`, `observer`) ainsi qu’un salon privé, puis démarre un processus enfant Gateway QA avec le vrai Plugin Matrix comme transport SUT. + - Utilise par défaut l’image Tuwunel stable épinglée `ghcr.io/matrix-construct/tuwunel:v1.5.1`. Remplacez-la avec `OPENCLAW_QA_MATRIX_TUWUNEL_IMAGE` si vous devez tester une autre image. + - Matrix n’expose pas d’options partagées de source d’identifiants, car cette voie provisionne localement des utilisateurs jetables. + - Écrit un rapport QA Matrix, un résumé, un artefact d’événements observés et un journal combiné stdout/stderr sous `.artifacts/qa-e2e/...`. - `pnpm openclaw qa telegram` - - Exécute la voie QA live Telegram contre un vrai groupe privé à l’aide des jetons de bot driver et SUT fournis par l’environnement. + - Exécute la voie QA live Telegram contre un vrai groupe privé à l’aide des jetons du bot driver et du bot SUT depuis l’environnement. - Nécessite `OPENCLAW_QA_TELEGRAM_GROUP_ID`, `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` et `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`. L’identifiant du groupe doit être l’identifiant numérique du chat Telegram. - - Prend en charge `--credential-source convex` pour les identifiants mutualisés en pool. Utilisez par défaut le mode env, ou définissez `OPENCLAW_QA_CREDENTIAL_SOURCE=convex` pour activer les baux mutualisés. - - Nécessite deux bots distincts dans le même groupe privé, le bot SUT exposant un nom d’utilisateur Telegram. - - Pour une observation stable bot-à-bot, activez le mode Bot-to-Bot Communication dans `@BotFather` pour les deux bots et assurez-vous que le bot driver peut observer le trafic des bots du groupe. - - Écrit sous `.artifacts/qa-e2e/...` un rapport QA Telegram, un résumé et un artefact des messages observés. + - Prend en charge `--credential-source convex` pour des identifiants partagés mutualisés. Utilisez le mode env par défaut, ou définissez `OPENCLAW_QA_CREDENTIAL_SOURCE=convex` pour activer les baux mutualisés. + - Se termine avec un code non nul si un scénario échoue. Utilisez `--allow-failures` si vous voulez les artefacts sans code de sortie en échec. + - Nécessite deux bots distincts dans le même groupe privé, avec un nom d’utilisateur Telegram exposé pour le bot SUT. + - Pour une observation stable entre bots, activez le Bot-to-Bot Communication Mode dans `@BotFather` pour les deux bots et assurez-vous que le bot driver peut observer le trafic de bot dans le groupe. + - Écrit un rapport QA Telegram, un résumé et un artefact de messages observés sous `.artifacts/qa-e2e/...`. -Les voies de transport live partagent un contrat standard unique afin que les nouveaux transports ne divergent pas : +Les voies de transport live partagent un contrat standard unique afin que les nouveaux transports ne divergent pas : -`qa-channel` reste la large suite QA synthétique et ne fait pas partie de la matrice de couverture des transports live. +`qa-channel` reste la suite QA synthétique large et ne fait pas partie de la matrice de couverture des transports live. -| Voie | Canary | Filtrage des mentions | Blocage par liste d’autorisation | Réponse de premier niveau | Reprise après redémarrage | Suivi de fil | Isolation de fil | Observation des réactions | Commande d’aide | -| -------- | ------ | --------------------- | -------------------------------- | ------------------------- | ------------------------- | ------------ | ---------------- | ------------------------- | --------------- | -| Matrix | x | x | x | x | x | x | x | x | | -| Telegram | x | | | | | | | | x | +| Voie | Canary | Filtrage par mention | Blocage par liste d’autorisation | Réponse de premier niveau | Reprise après redémarrage | Suivi de fil | Isolation des fils | Observation des réactions | Commande d’aide | +| -------- | ------ | -------------------- | -------------------------------- | ------------------------- | ------------------------- | ------------ | ------------------ | ------------------------- | --------------- | +| Matrix | x | x | x | x | x | x | x | x | | +| Telegram | x | | | | | | | | x | ### Identifiants Telegram partagés via Convex (v1) Lorsque `--credential-source convex` (ou `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`) est activé pour -`openclaw qa telegram`, QA lab acquiert un bail exclusif depuis un pool adossé à Convex, envoie des Heartbeat -pendant l’exécution de la voie, puis libère le bail à l’arrêt. +`openclaw qa telegram`, QA lab acquiert un bail exclusif à partir d’un pool adossé à Convex, envoie des Heartbeat +pour ce bail pendant l’exécution de la voie, puis libère le bail à l’arrêt. -Référence de structure de projet Convex : +Structure de projet Convex de référence : - `qa/convex-credential-broker/` -Variables d’environnement requises : +Variables d’environnement requises : - `OPENCLAW_QA_CONVEX_SITE_URL` (par exemple `https://your-deployment.convex.site`) -- Un secret pour le rôle sélectionné : +- Un secret pour le rôle sélectionné : - `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER` pour `maintainer` - `OPENCLAW_QA_CONVEX_SECRET_CI` pour `ci` -- Sélection du rôle d’identifiant : - - CLI : `--credential-role maintainer|ci` - - Valeur par défaut de l’environnement : `OPENCLAW_QA_CREDENTIAL_ROLE` (par défaut `maintainer`) +- Sélection du rôle d’identifiant : + - CLI : `--credential-role maintainer|ci` + - Valeur par défaut de l’environnement : `OPENCLAW_QA_CREDENTIAL_ROLE` (vaut `ci` par défaut dans la CI, `maintainer` sinon) -Variables d’environnement facultatives : +Variables d’environnement facultatives : - `OPENCLAW_QA_CREDENTIAL_LEASE_TTL_MS` (par défaut `1200000`) - `OPENCLAW_QA_CREDENTIAL_HEARTBEAT_INTERVAL_MS` (par défaut `30000`) - `OPENCLAW_QA_CREDENTIAL_ACQUIRE_TIMEOUT_MS` (par défaut `90000`) - `OPENCLAW_QA_CREDENTIAL_HTTP_TIMEOUT_MS` (par défaut `15000`) - `OPENCLAW_QA_CONVEX_ENDPOINT_PREFIX` (par défaut `/qa-credentials/v1`) -- `OPENCLAW_QA_CREDENTIAL_OWNER_ID` (identifiant de trace facultatif) +- `OPENCLAW_QA_CREDENTIAL_OWNER_ID` (identifiant de traçabilité facultatif) - `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` autorise les URL Convex `http://` en loopback pour le développement local uniquement. `OPENCLAW_QA_CONVEX_SITE_URL` doit utiliser `https://` en fonctionnement normal. -Les commandes d’administration maintainer (ajout/suppression/liste de pool) nécessitent +Les commandes d’administration mainteneur (ajout/suppression/liste du pool) nécessitent spécifiquement `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER`. -Aides CLI pour les maintainers : +Assistants CLI pour les mainteneurs : ```bash pnpm openclaw qa credentials add --kind telegram --payload-file qa/telegram-credential.json @@ -141,86 +143,86 @@ pnpm openclaw qa credentials remove --credential-id Utilisez `--json` pour une sortie lisible par machine dans les scripts et utilitaires CI. -Contrat de point de terminaison par défaut (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`) : +Contrat de point de terminaison par défaut (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`) : - `POST /acquire` - - Requête : `{ kind, ownerId, actorRole, leaseTtlMs, heartbeatIntervalMs }` - - Succès : `{ status: "ok", credentialId, leaseToken, payload, leaseTtlMs?, heartbeatIntervalMs? }` - - Épuisé/réessayable : `{ status: "error", code: "POOL_EXHAUSTED" | "NO_CREDENTIAL_AVAILABLE", ... }` + - Requête : `{ kind, ownerId, actorRole, leaseTtlMs, heartbeatIntervalMs }` + - Succès : `{ status: "ok", credentialId, leaseToken, payload, leaseTtlMs?, heartbeatIntervalMs? }` + - Épuisé/réessayable : `{ status: "error", code: "POOL_EXHAUSTED" | "NO_CREDENTIAL_AVAILABLE", ... }` - `POST /heartbeat` - - Requête : `{ kind, ownerId, actorRole, credentialId, leaseToken, leaseTtlMs }` - - Succès : `{ status: "ok" }` (ou `2xx` vide) + - Requête : `{ kind, ownerId, actorRole, credentialId, leaseToken, leaseTtlMs }` + - Succès : `{ status: "ok" }` (ou `2xx` vide) - `POST /release` - - Requête : `{ kind, ownerId, actorRole, credentialId, leaseToken }` - - Succès : `{ status: "ok" }` (ou `2xx` vide) -- `POST /admin/add` (secret maintainer uniquement) - - Requête : `{ kind, actorId, payload, note?, status? }` - - Succès : `{ status: "ok", credential }` -- `POST /admin/remove` (secret maintainer uniquement) - - Requête : `{ credentialId, actorId }` - - Succès : `{ status: "ok", changed, credential }` - - Garde sur bail actif : `{ status: "error", code: "LEASE_ACTIVE", ... }` -- `POST /admin/list` (secret maintainer uniquement) - - Requête : `{ kind?, status?, includePayload?, limit? }` - - Succès : `{ status: "ok", credentials, count }` + - Requête : `{ kind, ownerId, actorRole, credentialId, leaseToken }` + - Succès : `{ status: "ok" }` (ou `2xx` vide) +- `POST /admin/add` (secret mainteneur uniquement) + - Requête : `{ kind, actorId, payload, note?, status? }` + - Succès : `{ status: "ok", credential }` +- `POST /admin/remove` (secret mainteneur uniquement) + - Requête : `{ credentialId, actorId }` + - Succès : `{ status: "ok", changed, credential }` + - Garde sur bail actif : `{ status: "error", code: "LEASE_ACTIVE", ... }` +- `POST /admin/list` (secret mainteneur uniquement) + - Requête : `{ kind?, status?, includePayload?, limit? }` + - Succès : `{ status: "ok", credentials, count }` -Forme du payload pour le type Telegram : +Forme de payload pour le type Telegram : - `{ groupId: string, driverToken: string, sutToken: string }` -- `groupId` doit être une chaîne contenant un identifiant numérique de chat Telegram. +- `groupId` doit être une chaîne correspondant à un identifiant numérique de chat Telegram. - `admin/add` valide cette forme pour `kind: "telegram"` et rejette les payloads mal formés. ### Ajouter un canal à la QA -L’ajout d’un canal au système QA markdown nécessite exactement deux éléments : +Ajouter un canal au système QA Markdown requiert exactement deux éléments : 1. Un adaptateur de transport pour le canal. 2. Un pack de scénarios qui exerce le contrat du canal. N’ajoutez pas une nouvelle racine de commande QA de premier niveau lorsque l’hôte partagé `qa-lab` peut -prendre en charge ce flux. +prendre en charge le flux. -`qa-lab` prend en charge les mécanismes hôtes partagés : +`qa-lab` prend en charge les mécanismes hôtes partagés : - la racine de commande `openclaw qa` - le démarrage et l’arrêt de la suite - la concurrence des workers - l’écriture des artefacts -- la génération des rapports +- la génération de rapports - l’exécution des scénarios - les alias de compatibilité pour les anciens scénarios `qa-channel` -Les Plugins d’exécuteur prennent en charge le contrat de transport : +Les Plugins d’exécuteur prennent en charge le contrat de transport : -- comment `openclaw qa ` est monté sous la racine partagée `qa` -- comment le Gateway est configuré pour ce transport -- comment l’état prêt est vérifié -- comment les événements entrants sont injectés -- comment les messages sortants sont observés -- comment les transcriptions et l’état de transport normalisé sont exposés -- comment les actions adossées au transport sont exécutées -- comment la réinitialisation ou le nettoyage propres au transport sont gérés +- la manière dont `openclaw qa ` est monté sous la racine partagée `qa` +- la manière dont la Gateway est configurée pour ce transport +- la manière dont l’état de préparation est vérifié +- la manière dont les événements entrants sont injectés +- la manière dont les messages sortants sont observés +- la manière dont les transcriptions et l’état de transport normalisé sont exposés +- la manière dont les actions adossées au transport sont exécutées +- la manière dont la réinitialisation ou le nettoyage spécifiques au transport sont gérés -Le seuil minimal d’adoption pour un nouveau canal est : +Le seuil minimal d’adoption pour un nouveau canal est le suivant : 1. Conserver `qa-lab` comme propriétaire de la racine partagée `qa`. -2. Implémenter l’exécuteur de transport sur la couture hôte partagée `qa-lab`. +2. Implémenter l’exécuteur de transport sur le point d’extension hôte partagé `qa-lab`. 3. Conserver les mécanismes spécifiques au transport dans le Plugin d’exécuteur ou le harnais du canal. -4. Monter l’exécuteur comme `openclaw qa ` au lieu d’enregistrer une commande racine concurrente. +4. Monter l’exécuteur sous la forme `openclaw qa ` au lieu d’enregistrer une racine de commande concurrente. Les Plugins d’exécuteur doivent déclarer `qaRunners` dans `openclaw.plugin.json` et exporter un tableau `qaRunnerCliRegistrations` correspondant depuis `runtime-api.ts`. - Gardez `runtime-api.ts` léger ; le chargement paresseux de la CLI et l’exécution de l’exécuteur doivent rester derrière des points d’entrée distincts. -5. Rédiger ou adapter les scénarios markdown sous les répertoires thématiques `qa/scenarios/`. -6. Utiliser les aides de scénario génériques pour les nouveaux scénarios. -7. Conserver les alias de compatibilité existants sauf si le dépôt effectue une migration intentionnelle. + Gardez `runtime-api.ts` léger ; la CLI paresseuse et l’exécution des exécuteurs doivent rester derrière des points d’entrée séparés. +5. Rédiger ou adapter des scénarios Markdown sous les répertoires thématiques `qa/scenarios/`. +6. Utiliser les assistants de scénarios génériques pour les nouveaux scénarios. +7. Conserver les alias de compatibilité existants en fonctionnement, sauf si le dépôt effectue une migration intentionnelle. -La règle de décision est stricte : +La règle de décision est stricte : - Si un comportement peut être exprimé une seule fois dans `qa-lab`, placez-le dans `qa-lab`. - Si un comportement dépend d’un seul transport de canal, conservez-le dans ce Plugin d’exécuteur ou harnais de Plugin. -- Si un scénario a besoin d’une nouvelle capacité que plus d’un canal peut utiliser, ajoutez une aide générique au lieu d’une branche spécifique à un canal dans `suite.ts`. -- Si un comportement n’a de sens que pour un seul transport, gardez le scénario spécifique au transport et rendez cela explicite dans le contrat du scénario. +- Si un scénario a besoin d’une nouvelle capacité utilisable par plus d’un canal, ajoutez un assistant générique plutôt qu’une branche spécifique à un canal dans `suite.ts`. +- Si un comportement n’a de sens que pour un seul transport, gardez le scénario spécifique à ce transport et rendez cela explicite dans le contrat du scénario. -Les noms d’aides génériques préférés pour les nouveaux scénarios sont : +Les noms d’assistants génériques préférés pour les nouveaux scénarios sont : - `waitForTransportReady` - `waitForChannelReady` @@ -235,7 +237,7 @@ Les noms d’aides génériques préférés pour les nouveaux scénarios sont : - `formatTransportTranscript` - `resetTransport` -Les alias de compatibilité restent disponibles pour les scénarios existants, notamment : +Les alias de compatibilité restent disponibles pour les scénarios existants, notamment : - `waitForQaChannelReady` - `waitForOutboundMessage` @@ -243,247 +245,247 @@ Les alias de compatibilité restent disponibles pour les scénarios existants, n - `formatConversationTranscript` - `resetBus` -Les nouveaux travaux sur les canaux doivent utiliser les noms d’aides génériques. -Les alias de compatibilité existent pour éviter une migration en une journée, pas comme modèle -pour la rédaction de nouveaux scénarios. +Les nouveaux travaux sur les canaux doivent utiliser les noms d’assistants génériques. +Les alias de compatibilité existent pour éviter une migration imposée en une seule fois, et non comme modèle pour +la rédaction de nouveaux scénarios. ## Suites de test (ce qui s’exécute où) -Considérez les suites comme ayant un « réalisme croissant » (et une instabilité/un coût croissants) : +Considérez les suites comme offrant un « réalisme croissant » (et une fragilité/un coût croissants) : ### Unitaire / intégration (par défaut) -- Commande : `pnpm test` -- Config : dix exécutions de fragments séquentielles (`vitest.full-*.config.ts`) sur les projets Vitest ciblés existants -- Fichiers : inventaires core/unit sous `src/**/*.test.ts`, `packages/**/*.test.ts`, `test/**/*.test.ts`, ainsi que les tests Node `ui` autorisés couverts par `vitest.unit.config.ts` -- Portée : +- Commande : `pnpm test` +- Configuration : dix exécutions de fragments séquentiels (`vitest.full-*.config.ts`) sur les projets Vitest ciblés existants +- Fichiers : inventaires core/unit sous `src/**/*.test.ts`, `packages/**/*.test.ts`, `test/**/*.test.ts`, ainsi que les tests Node `ui` autorisés couverts par `vitest.unit.config.ts` +- Portée : - Tests unitaires purs - - Tests d’intégration en processus (authentification Gateway, routage, outils, analyse, configuration) - - Régressions déterministes pour des bugs connus -- Attentes : - - S’exécute en CI + - Tests d’intégration en processus (authentification Gateway, routage, outillage, analyse, configuration) + - Régressions déterministes pour les bugs connus +- Attentes : + - S’exécute dans la CI - Aucune vraie clé requise - Doit être rapide et stable -- Note sur les projets : - - `pnpm test` sans ciblage exécute désormais onze configurations de fragments plus petites (`core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) au lieu d’un seul processus géant natif de projet racine. Cela réduit le pic de RSS sur les machines chargées et évite que le travail `auto-reply`/extension n’affame les suites non liées. - - `pnpm test --watch` utilise toujours le graphe de projets racine natif `vitest.config.ts`, parce qu’une boucle de surveillance multi-fragments n’est pas pratique. - - `pnpm test`, `pnpm test:watch` et `pnpm test:perf:imports` acheminent d’abord les cibles explicites de fichier/répertoire via des voies ciblées, de sorte que `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` évite de payer le coût complet de démarrage du projet racine. - - `pnpm test:changed` étend les chemins git modifiés vers ces mêmes voies ciblées lorsque le diff ne touche que des fichiers source/test routables ; les modifications de config/setup reviennent toujours à une relance large du projet racine. - - Les tests unitaires légers à l’import depuis les agents, commandes, plugins, aides `auto-reply`, `plugin-sdk` et zones utilitaires pures similaires passent par la voie `unit-fast`, qui ignore `test/setup-openclaw-runtime.ts` ; les fichiers avec état/runtime lourd restent sur les voies existantes. - - Certains fichiers source d’aide `plugin-sdk` et `commands` font aussi correspondre les exécutions en mode changed à des tests frères explicites dans ces voies légères, afin que les modifications d’aides évitent de relancer toute la suite lourde de ce répertoire. - - `auto-reply` dispose désormais de trois compartiments dédiés : aides core de premier niveau, tests d’intégration `reply.*` de premier niveau et sous-arborescence `src/auto-reply/reply/**`. Cela garde le travail du harnais de réponse le plus lourd à l’écart des tests bon marché de statut/chunk/token. -- Note sur l’exécuteur embarqué : - - Lorsque vous modifiez les entrées de découverte d’outils de message ou le contexte runtime de Compaction, +- Note sur les projets : + - `pnpm test` sans ciblage exécute désormais onze configurations de fragments plus petites (`core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) au lieu d’un seul énorme processus racine natif. Cela réduit le pic de RSS sur les machines chargées et évite que le travail `auto-reply`/extensions ne prive les autres suites de ressources. + - `pnpm test --watch` utilise toujours le graphe de projets racine natif `vitest.config.ts`, car une boucle watch multi-fragments n’est pas pratique. + - `pnpm test`, `pnpm test:watch` et `pnpm test:perf:imports` font passer d’abord les cibles de fichier/répertoire explicites par des voies ciblées, de sorte que `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` évite le coût de démarrage complet du projet racine. + - `pnpm test:changed` étend les chemins git modifiés vers les mêmes voies ciblées lorsque le diff ne touche que des fichiers source/test routables ; les modifications de configuration/setup reviennent toujours à une réexécution large du projet racine. + - Les tests unitaires légers à l’importation provenant des agents, commandes, Plugins, assistants `auto-reply`, `plugin-sdk` et zones utilitaires pures similaires passent par la voie `unit-fast`, qui ignore `test/setup-openclaw-runtime.ts` ; les fichiers lourds en état/runtime restent sur les voies existantes. + - Certains fichiers source assistants de `plugin-sdk` et `commands` font également correspondre les exécutions en mode modifié à des tests voisins explicites dans ces voies légères, afin que les modifications d’assistants évitent de relancer toute la suite lourde de ce répertoire. + - `auto-reply` dispose désormais de trois groupes dédiés : assistants core de premier niveau, tests d’intégration `reply.*` de premier niveau, et sous-arborescence `src/auto-reply/reply/**`. Cela maintient le travail du harnais de réponse le plus lourd hors des tests bon marché de statut/chunk/token. +- Note sur l’exécuteur embarqué : + - Lorsque vous modifiez les entrées de découverte des outils de message ou le contexte d’exécution de Compaction, conservez les deux niveaux de couverture. - - Ajoutez des régressions d’aide ciblées pour les limites pures de routage/normalisation. - - Gardez aussi saines les suites d’intégration de l’exécuteur embarqué : + - Ajoutez des régressions d’assistant ciblées pour les limites pures de routage/normalisation. + - Gardez aussi en bon état les suites d’intégration de l’exécuteur embarqué : `src/agents/pi-embedded-runner/compact.hooks.test.ts`, - `src/agents/pi-embedded-runner/run.overflow-compaction.test.ts`, et + `src/agents/pi-embedded-runner/run.overflow-compaction.test.ts` et `src/agents/pi-embedded-runner/run.overflow-compaction.loop.test.ts`. - Ces suites vérifient que les identifiants ciblés et le comportement de Compaction passent toujours - par les vrais chemins `run.ts` / `compact.ts` ; les tests d’aide seuls ne constituent pas + par les véritables chemins `run.ts` / `compact.ts` ; les tests d’assistant seuls ne constituent pas un substitut suffisant à ces chemins d’intégration. -- Note sur le pool : - - La config Vitest de base utilise désormais `threads` par défaut. - - La config Vitest partagée fixe aussi `isolate: false` et utilise l’exécuteur non isolé sur les projets racine, les configs e2e et live. - - La voie UI racine conserve sa configuration `jsdom` et son optimiseur, mais s’exécute maintenant elle aussi sur l’exécuteur partagé non isolé. - - Chaque fragment `pnpm test` hérite des mêmes valeurs par défaut `threads` + `isolate: false` depuis la config Vitest partagée. - - Le lanceur partagé `scripts/run-vitest.mjs` ajoute désormais aussi `--no-maglev` par défaut pour les processus Node enfants de Vitest afin de réduire la charge de compilation V8 pendant les grosses exécutions locales. Définissez `OPENCLAW_VITEST_ENABLE_MAGLEV=1` si vous devez comparer avec le comportement V8 standard. -- Note sur l’itération locale rapide : +- Note sur le pool : + - La configuration Vitest de base utilise désormais `threads` par défaut. + - La configuration Vitest partagée fixe aussi `isolate: false` et utilise l’exécuteur non isolé sur les projets racine, e2e et live. + - La voie UI racine conserve sa configuration `jsdom` et son optimiseur, mais s’exécute maintenant aussi sur l’exécuteur partagé non isolé. + - Chaque fragment `pnpm test` hérite des mêmes valeurs par défaut `threads` + `isolate: false` à partir de la configuration Vitest partagée. + - Le lanceur partagé `scripts/run-vitest.mjs` ajoute désormais aussi `--no-maglev` par défaut pour les processus Node enfants de Vitest afin de réduire l’agitation de compilation V8 lors des grosses exécutions locales. Définissez `OPENCLAW_VITEST_ENABLE_MAGLEV=1` si vous devez comparer avec le comportement V8 standard. +- Note sur l’itération locale rapide : - `pnpm test:changed` passe par des voies ciblées lorsque les chemins modifiés correspondent proprement à une suite plus petite. - `pnpm test:max` et `pnpm test:changed:max` conservent le même comportement de routage, simplement avec une limite de workers plus élevée. - - L’auto-dimensionnement local des workers est désormais volontairement conservateur et recule aussi lorsque la moyenne de charge de l’hôte est déjà élevée, de sorte que plusieurs exécutions Vitest concurrentes fassent moins de dégâts par défaut. - - La config Vitest de base marque les projets/fichiers de config comme `forceRerunTriggers` afin que les relances en mode changed restent correctes lorsque le câblage des tests change. - - La config maintient `OPENCLAW_VITEST_FS_MODULE_CACHE` activé sur les hôtes pris en charge ; définissez `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path` si vous voulez un emplacement de cache explicite pour un profilage direct. -- Note sur le débogage des performances : - - `pnpm test:perf:imports` active le rapport de durée d’import de Vitest ainsi qu’une sortie de ventilation des imports. - - `pnpm test:perf:imports:changed` limite cette même vue de profilage aux fichiers modifiés depuis `origin/main`. -- `pnpm test:perf:changed:bench -- --ref ` compare `test:changed` routé avec le chemin natif du projet racine pour ce diff validé et affiche le temps mur ainsi que le RSS max macOS. -- `pnpm test:perf:changed:bench -- --worktree` mesure l’arbre sale actuel en routant la liste des fichiers modifiés via `scripts/test-projects.mjs` et la config Vitest racine. - - `pnpm test:perf:profile:main` écrit un profil CPU du thread principal pour la surcharge de démarrage et de transformation de Vitest/Vite. - - `pnpm test:perf:profile:runner` écrit des profils CPU+tas de l’exécuteur pour la suite unitaire avec le parallélisme par fichier désactivé. + - L’auto-dimensionnement local des workers est désormais volontairement conservateur et ralentit aussi lorsque la moyenne de charge de l’hôte est déjà élevée, afin que plusieurs exécutions Vitest simultanées causent moins de dégâts par défaut. + - La configuration Vitest de base marque les projets/fichiers de configuration comme `forceRerunTriggers` pour que les réexécutions en mode modifié restent correctes lorsque le câblage des tests change. + - La configuration garde `OPENCLAW_VITEST_FS_MODULE_CACHE` activé sur les hôtes pris en charge ; définissez `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path` si vous voulez un emplacement de cache explicite pour le profilage direct. +- Note sur le débogage des performances : + - `pnpm test:perf:imports` active les rapports de durée d’importation de Vitest ainsi que la sortie détaillée des importations. + - `pnpm test:perf:imports:changed` limite la même vue de profilage aux fichiers modifiés depuis `origin/main`. +- `pnpm test:perf:changed:bench -- --ref ` compare le `test:changed` routé au chemin natif du projet racine pour ce diff validé et affiche le temps total ainsi que la RSS maximale macOS. +- `pnpm test:perf:changed:bench -- --worktree` mesure l’arbre de travail sale actuel en faisant passer la liste des fichiers modifiés par `scripts/test-projects.mjs` et la configuration Vitest racine. + - `pnpm test:perf:profile:main` écrit un profil CPU du thread principal pour les coûts de démarrage et de transformation Vitest/Vite. + - `pnpm test:perf:profile:runner` écrit des profils CPU+tas de l’exécuteur pour la suite unitaire avec le parallélisme des fichiers désactivé. -### E2E (test de fumée Gateway) +### E2E (smoke Gateway) -- Commande : `pnpm test:e2e` -- Config : `vitest.e2e.config.ts` -- Fichiers : `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` -- Valeurs par défaut du runtime : +- Commande : `pnpm test:e2e` +- Configuration : `vitest.e2e.config.ts` +- Fichiers : `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` +- Valeurs par défaut du runtime : - Utilise Vitest `threads` avec `isolate: false`, comme le reste du dépôt. - - Utilise des workers adaptatifs (CI : jusqu’à 2, local : 1 par défaut). + - Utilise des workers adaptatifs (CI : jusqu’à 2, local : 1 par défaut). - S’exécute en mode silencieux par défaut pour réduire la surcharge d’E/S console. -- Remplacements utiles : - - `OPENCLAW_E2E_WORKERS=` pour forcer le nombre de workers (limité à 16). +- Remplacements utiles : + - `OPENCLAW_E2E_WORKERS=` pour forcer le nombre de workers (plafonné à 16). - `OPENCLAW_E2E_VERBOSE=1` pour réactiver la sortie console détaillée. -- Portée : +- Portée : - Comportement end-to-end Gateway multi-instance - - Surfaces WebSocket/HTTP, appairage de Node et réseau plus lourd -- Attentes : - - S’exécute en CI (lorsqu’activé dans le pipeline) + - Surfaces WebSocket/HTTP, appairage de nœuds et réseau plus lourd +- Attentes : + - S’exécute dans la CI (lorsqu’activé dans le pipeline) - Aucune vraie clé requise - - Plus de composants mobiles que les tests unitaires (peut être plus lent) + - Plus de composants mobiles que dans les tests unitaires (peut être plus lent) -### E2E : test de fumée du backend OpenShell +### E2E : smoke du backend OpenShell -- Commande : `pnpm test:e2e:openshell` -- Fichier : `test/openshell-sandbox.e2e.test.ts` -- Portée : - - Démarre sur l’hôte un Gateway OpenShell isolé via Docker - - Crée un sandbox à partir d’un Dockerfile local temporaire - - Exerce le backend OpenShell d’OpenClaw via un vrai `sandbox ssh-config` + exécution SSH - - Vérifie le comportement du système de fichiers canonique distant via le pont fs du sandbox -- Attentes : - - Opt-in uniquement ; ne fait pas partie de l’exécution `pnpm test:e2e` par défaut - - Nécessite une CLI `openshell` locale ainsi qu’un démon Docker fonctionnel - - Utilise des `HOME` / `XDG_CONFIG_HOME` isolés, puis détruit le Gateway de test et le sandbox -- Remplacements utiles : - - `OPENCLAW_E2E_OPENSHELL=1` pour activer le test lors d’une exécution manuelle de la suite e2e plus large +- Commande : `pnpm test:e2e:openshell` +- Fichier : `test/openshell-sandbox.e2e.test.ts` +- Portée : + - Démarre une Gateway OpenShell isolée sur l’hôte via Docker + - Crée un bac à sable à partir d’un Dockerfile local temporaire + - Exerce le backend OpenShell d’OpenClaw via de vrais `sandbox ssh-config` + exécution SSH + - Vérifie le comportement canonique du système de fichiers distant via le pont fs du bac à sable +- Attentes : + - Activation facultative uniquement ; ne fait pas partie de l’exécution par défaut `pnpm test:e2e` + - Nécessite un CLI `openshell` local ainsi qu’un démon Docker fonctionnel + - Utilise `HOME` / `XDG_CONFIG_HOME` isolés, puis détruit la Gateway et le bac à sable de test +- Remplacements utiles : + - `OPENCLAW_E2E_OPENSHELL=1` pour activer le test lors de l’exécution manuelle de la suite e2e plus large - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell` pour pointer vers un binaire CLI non par défaut ou un script wrapper ### Live (vrais fournisseurs + vrais modèles) -- Commande : `pnpm test:live` -- Config : `vitest.live.config.ts` -- Fichiers : `src/**/*.live.test.ts` -- Par défaut : **activé** par `pnpm test:live` (définit `OPENCLAW_LIVE_TEST=1`) -- Portée : - - « Ce fournisseur/modèle fonctionne-t-il réellement _aujourd’hui_ avec de vrais identifiants ? » - - Détecter les changements de format fournisseur, les particularités d’appel d’outil, les problèmes d’authentification et le comportement face aux limites de débit -- Attentes : - - Non stable en CI par conception (vrais réseaux, vraies politiques fournisseur, quotas, pannes) +- Commande : `pnpm test:live` +- Configuration : `vitest.live.config.ts` +- Fichiers : `src/**/*.live.test.ts` +- Par défaut : **activé** par `pnpm test:live` (définit `OPENCLAW_LIVE_TEST=1`) +- Portée : + - « Ce fournisseur/modèle fonctionne-t-il vraiment _aujourd’hui_ avec de vrais identifiants ? » + - Détecter les changements de format fournisseur, particularités d’appel d’outil, problèmes d’authentification et comportement de limitation de débit +- Attentes : + - Non stable dans la CI par conception (vrais réseaux, vraies politiques fournisseur, quotas, pannes) - Coûte de l’argent / consomme des limites de débit - Préférez exécuter des sous-ensembles restreints plutôt que « tout » -- Les exécutions live chargent `~/.profile` pour récupérer les clés d’API manquantes. -- Par défaut, les exécutions live isolent toujours `HOME` et copient le matériel de config/authentification dans un répertoire personnel de test temporaire afin que les fixtures unitaires ne puissent pas modifier votre vrai `~/.openclaw`. -- Définissez `OPENCLAW_LIVE_USE_REAL_HOME=1` uniquement lorsque vous voulez volontairement que les tests live utilisent votre vrai répertoire personnel. -- `pnpm test:live` utilise désormais par défaut un mode plus silencieux : il conserve la sortie de progression `[live] ...`, mais supprime l’avis supplémentaire sur `~/.profile` et coupe les journaux de démarrage Gateway / le bruit Bonjour. Définissez `OPENCLAW_LIVE_TEST_QUIET=0` si vous voulez récupérer les journaux de démarrage complets. -- Rotation des clés d’API (spécifique au fournisseur) : définissez `*_API_KEYS` au format virgule/point-virgule ou `*_API_KEY_1`, `*_API_KEY_2` (par exemple `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) ou utilisez le remplacement propre au live via `OPENCLAW_LIVE_*_KEY` ; les tests réessaient sur les réponses de limite de débit. -- Sortie de progression/Heartbeat : - - Les suites live émettent désormais les lignes de progression vers stderr afin que les longs appels fournisseur restent visiblement actifs même lorsque la capture de console Vitest est silencieuse. - - `vitest.live.config.ts` désactive l’interception de console de Vitest afin que les lignes de progression fournisseur/Gateway soient diffusées immédiatement pendant les exécutions live. - - Ajustez les Heartbeat des modèles directs avec `OPENCLAW_LIVE_HEARTBEAT_MS`. - - Ajustez les Heartbeat Gateway/sondes avec `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. +- Les exécutions live chargent `~/.profile` pour récupérer les clés API manquantes. +- Par défaut, les exécutions live isolent toujours `HOME` et copient les éléments config/auth dans un home de test temporaire afin que les fixtures unitaires ne puissent pas modifier votre vrai `~/.openclaw`. +- Définissez `OPENCLAW_LIVE_USE_REAL_HOME=1` uniquement lorsque vous avez intentionnellement besoin que les tests live utilisent votre vrai répertoire home. +- `pnpm test:live` utilise désormais un mode plus silencieux par défaut : il conserve la sortie de progression `[live] ...`, mais masque l’avis supplémentaire sur `~/.profile` et coupe les journaux de bootstrap Gateway/Bonjour. Définissez `OPENCLAW_LIVE_TEST_QUIET=0` si vous voulez récupérer les journaux de démarrage complets. +- Rotation des clés API (spécifique au fournisseur) : définissez `*_API_KEYS` avec un format virgule/point-virgule ou `*_API_KEY_1`, `*_API_KEY_2` (par exemple `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) ou un remplacement par live via `OPENCLAW_LIVE_*_KEY` ; les tests réessaient sur les réponses de limitation de débit. +- Sortie de progression/Heartbeat : + - Les suites live émettent désormais des lignes de progression sur stderr afin que les longs appels fournisseur restent visiblement actifs même lorsque la capture de console Vitest est silencieuse. + - `vitest.live.config.ts` désactive l’interception de console Vitest afin que les lignes de progression fournisseur/Gateway soient diffusées immédiatement pendant les exécutions live. + - Ajustez les Heartbeat du modèle direct avec `OPENCLAW_LIVE_HEARTBEAT_MS`. + - Ajustez les Heartbeat Gateway/sonde avec `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. -## Quelle suite dois-je exécuter ? +## Quelle suite dois-je exécuter ? -Utilisez ce tableau de décision : +Utilisez ce tableau de décision : -- Modification de logique/tests : exécutez `pnpm test` (et `pnpm test:coverage` si vous avez beaucoup modifié) -- Si vous touchez au réseau Gateway / protocole WS / appairage : ajoutez `pnpm test:e2e` -- Débogage de « mon bot est hors service » / échecs spécifiques à un fournisseur / appel d’outil : exécutez un `pnpm test:live` restreint +- Modification de logique/tests : exécutez `pnpm test` (et `pnpm test:coverage` si vous avez beaucoup changé) +- Modification du réseau Gateway / protocole WS / appairage : ajoutez `pnpm test:e2e` +- Débogage de « mon bot est hors service » / défaillances spécifiques au fournisseur / appel d’outil : exécutez un `pnpm test:live` restreint -## Live : balayage des capacités du Node Android +## 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 Node Android connecté et vérifier le comportement du contrat de commande. -- Portée : - - Préconfiguration/configuration manuelle requise (la suite n’installe ni n’exécute ni n’appaire l’application). - - Validation `node.invoke` Gateway commande par commande pour le Node Android sélectionné. -- Préconfiguration requise : - - Application Android déjà connectée et appairée au Gateway. - - Application gardée au premier plan. - - Permissions/consentement de capture accordés pour les capacités que vous attendez comme réussies. -- Remplacements facultatifs de cible : +- 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 valider le comportement du contrat de commande. +- Portée : + - Préconditions/configuration manuelle (la suite n’installe pas, n’exécute pas et n’apparie pas 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 + appariée à la Gateway. + - Application maintenue au premier plan. + - Autorisations/consentement de capture accordés pour les capacités que vous attendez comme réussies. +- 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 : [Android App](/fr/platforms/android) +- Détails complets de configuration Android : [Android App](/fr/platforms/android) -## Live : test de fumée de modèle (clés de profil) +## Live : smoke modèle (clés de profil) -Les tests live sont divisés en deux couches afin de pouvoir isoler les échecs : +Les tests live sont divisés en deux couches afin que nous puissions isoler les défaillances : - Le « modèle direct » nous indique si le fournisseur/modèle peut répondre tout court avec la clé donnée. -- Le « test de fumée Gateway » nous indique si tout le pipeline gateway+agent fonctionne pour ce modèle (sessions, historique, outils, politique de sandbox, etc.). +- Le « smoke Gateway » nous indique si le pipeline complet Gateway+agent fonctionne pour ce modèle (sessions, historique, outils, politique de bac à sable, etc.). -### Couche 1 : complétion directe du modèle (sans Gateway) +### Couche 1 : complétion de modèle directe (sans Gateway) -- Test : `src/agents/models.profiles.live.test.ts` -- Objectif : - - Énumérer les modèles découverts +- Test : `src/agents/models.profiles.live.test.ts` +- Objectif : + - Énumérer les modèles détectés - 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) -- Comment l’activer : +- Comment l’activer : - `pnpm test:live` (ou `OPENCLAW_LIVE_TEST=1` si vous invoquez Vitest directement) -- Définissez `OPENCLAW_LIVE_MODELS=modern` (ou `all`, alias de modern) pour exécuter réellement cette suite ; sinon elle est ignorée afin de garder `pnpm test:live` concentré sur le test de fumée Gateway -- Comment sélectionner les modèles : +- Définissez `OPENCLAW_LIVE_MODELS=modern` (ou `all`, alias de modern) pour réellement exécuter cette suite ; sinon elle est ignorée afin que `pnpm test:live` reste centré sur le smoke Gateway +- Comment sélectionner les modèles : - `OPENCLAW_LIVE_MODELS=modern` pour exécuter la liste d’autorisation moderne (Opus/Sonnet 4.6+, GPT-5.x + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4) - `OPENCLAW_LIVE_MODELS=all` est un alias de la liste d’autorisation moderne - ou `OPENCLAW_LIVE_MODELS="openai/gpt-5.4,anthropic/claude-opus-4-6,..."` (liste d’autorisation séparée par des virgules) - - Les balayages modern/all utilisent par défaut un plafond sélectionné à fort signal ; définissez `OPENCLAW_LIVE_MAX_MODELS=0` pour un balayage moderne exhaustif ou un nombre positif pour un plafond plus réduit. -- Comment sélectionner les fournisseurs : + - Les balayages modern/all utilisent par défaut une limite organisée à fort signal ; définissez `OPENCLAW_LIVE_MAX_MODELS=0` pour un balayage moderne exhaustif ou une valeur positive pour une limite plus petite. +- Comment sélectionner les fournisseurs : - `OPENCLAW_LIVE_PROVIDERS="google,google-antigravity,google-gemini-cli"` (liste d’autorisation séparée par des virgules) -- D’où viennent les clés : - - Par défaut : magasin de profils et replis vers l’environnement - - Définissez `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour imposer **uniquement le magasin de profils** -- Pourquoi cela existe : - - Sépare « l’API du fournisseur est cassée / la clé est invalide » de « le pipeline d’agent Gateway est cassé » - - Contient de petites régressions isolées (exemple : rejouage du raisonnement OpenAI Responses/Codex Responses + flux d’appel d’outil) +- D’où proviennent les clés : + - Par défaut : magasin de profils et solutions de repli via l’environnement + - Définissez `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour imposer le **magasin de profils** uniquement +- Pourquoi cela existe : + - Sépare « l’API du fournisseur est cassée / la clé est invalide » de « le pipeline de l’agent Gateway est cassé » + - Contient de petites régressions isolées (exemple : rejouage du raisonnement OpenAI Responses/Codex Responses + flux d’appel d’outils) -### Couche 2 : test de fumée Gateway + agent de développement (ce que fait réellement "@openclaw") +### Couche 2 : smoke Gateway + agent de développement (ce que fait réellement « @openclaw ») -- Test : `src/gateway/gateway-models.profiles.live.test.ts` -- Objectif : - - Démarrer un Gateway en processus - - Créer/modifier une session `agent:dev:*` (remplacement du modèle à chaque exécution) - - Itérer sur les modèles-avec-clés et vérifier : - - une réponse « significative » (sans outils) - - qu’un véritable appel d’outil fonctionne (sonde de lecture) - - des sondes d’outil supplémentaires facultatives (sonde exec+read) - - que les chemins de régression OpenAI (appel-d’outil-seulement → suivi) continuent de fonctionner -- Détails des sondes (pour pouvoir 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 la nonce. - - sonde `exec+read` : le test demande à l’agent d’écrire une nonce via `exec` dans un fichier temporaire, puis de la relire via `read`. - - sonde d’image : le test joint un PNG généré (chat + code aléatoire) et attend que le modèle renvoie `cat `. - - Référence d’implémentation : `src/gateway/gateway-models.profiles.live.test.ts` et `src/gateway/live-image-probe.ts`. -- Comment l’activer : +- Test : `src/gateway/gateway-models.profiles.live.test.ts` +- Objectif : + - Démarrer une Gateway en processus + - Créer/modifier une session `agent:dev:*` (avec remplacement de modèle à chaque exécution) + - Itérer sur les modèles-avec-clés et vérifier : + - réponse « utile » (sans outils) + - qu’une vraie invocation d’outil fonctionne (sonde de lecture) + - sondes d’outils supplémentaires facultatives (sonde exec+read) + - que les chemins de régression OpenAI (tool-call-only → suivi) continuent de fonctionner +- Détails des sondes (afin que vous puissiez 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 un nonce dans un fichier temporaire via `exec`, puis de le relire via `read`. + - sonde d’image : le test joint un PNG généré (chat + code aléatoire) et attend que le modèle renvoie `cat `. + - Référence d’implémentation : `src/gateway/gateway-models.profiles.live.test.ts` et `src/gateway/live-image-probe.ts`. +- Comment l’activer : - `pnpm test:live` (ou `OPENCLAW_LIVE_TEST=1` si vous invoquez Vitest directement) -- Comment sélectionner les modèles : - - Par défaut : liste d’autorisation moderne (Opus/Sonnet 4.6+, GPT-5.x + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4) +- Comment sélectionner les modèles : + - Par défaut : liste d’autorisation moderne (Opus/Sonnet 4.6+, GPT-5.x + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4) - `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 utilisent par défaut un plafond sélectionné à fort signal ; définissez `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0` pour un balayage moderne exhaustif ou un nombre positif pour un plafond plus réduit. -- Comment sélectionner les fournisseurs (éviter « OpenRouter tout ») : + - Les balayages Gateway modern/all utilisent par défaut une limite organisée à fort signal ; définissez `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0` pour un balayage moderne exhaustif ou une valeur positive pour une limite plus petite. +- Comment sélectionner les fournisseurs (éviter « OpenRouter tout ») : - `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 + d’image sont toujours activées dans ce test live : - - sonde `read` + sonde `exec+read` (stress sur les outils) - - la sonde d’image s’exécute lorsque le modèle annonce la prise en charge de l’entrée d’image - - Flux (vue d’ensemble) : +- Les sondes d’outils + d’image sont toujours activées dans ce test live : + - sonde `read` + sonde `exec+read` (stress d’outil) + - la sonde d’image s’exécute lorsque le modèle annonce la prise en charge des entrées image + - Flux (haut niveau) : - Le test génère un petit PNG avec « CAT » + un code aléatoire (`src/gateway/live-image-probe.ts`) - L’envoie via `agent` `attachments: [{ mimeType: "image/png", content: "" }]` - - Le Gateway analyse les pièces jointes en `images[]` (`src/gateway/server-methods/agent.ts` + `src/gateway/chat-attachments.ts`) - - L’agent embarqué transmet au modèle un message utilisateur multimodal - - Vérification : la réponse contient `cat` + le code (tolérance OCR : erreurs mineures autorisées) + - La 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 : petites erreurs autorisées) -Astuce : pour voir ce que vous pouvez tester sur votre machine (et les identifiants exacts `provider/model`), exécutez : +Astuce : pour voir ce que vous pouvez tester sur votre machine (et les identifiants exacts `provider/model`), exécutez : ```bash openclaw models list openclaw models list --json ``` -## Live : test de fumée du backend CLI (Claude, Codex, Gemini ou autres CLI locales) +## Live : smoke du backend CLI (Claude, Codex, Gemini ou autres CLI locaux) -- 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 spécifiques aux tests de fumée du backend vivent avec la définition `cli-backend.ts` de l’extension propriétaire. -- Activer : +- 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 spécifiques au backend se trouvent dans la définition `cli-backend.ts` de l’extension propriétaire. +- Activer : - `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` +- 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 backend CLI propriétaire. -- Remplacements facultatifs : +- Remplacements facultatifs : - `OPENCLAW_LIVE_CLI_BACKEND_MODEL="codex-cli/gpt-5.4"` - `OPENCLAW_LIVE_CLI_BACKEND_COMMAND="/full/path/to/codex"` - `OPENCLAW_LIVE_CLI_BACKEND_ARGS='["exec","--json","--color","never","--sandbox","read-only","--skip-git-repo-check"]'` - - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_PROBE=1` pour envoyer une véritable pièce jointe image (les chemins sont injectés dans le prompt). - - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image"` pour transmettre 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 façon dont les arguments image sont transmis lorsque `IMAGE_ARG` est défini. + - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_PROBE=1` pour envoyer une vraie pièce jointe image (les chemins sont injectés dans l’invite). + - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image"` pour passer les chemins de fichiers image comme arguments CLI au lieu de les injecter dans l’invite. + - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat"` (ou `"list"`) pour contrôler la manière dont les arguments 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=0` pour désactiver la sonde de continuité de session par défaut Claude Sonnet -> Opus sur une même session (définissez `1` pour la forcer lorsque le modèle sélectionné prend en charge une cible de changement). + - `OPENCLAW_LIVE_CLI_BACKEND_MODEL_SWITCH_PROBE=0` pour désactiver la sonde par défaut de continuité de même session Claude Sonnet -> Opus (définissez `1` pour la forcer lorsque le modèle sélectionné prend en charge une cible de changement). -Exemple : +Exemple : ```bash OPENCLAW_LIVE_CLI_BACKEND=1 \ @@ -491,13 +493,13 @@ OPENCLAW_LIVE_CLI_BACKEND=1 \ pnpm test:live src/gateway/gateway-cli-backend.live.test.ts ``` -Recette Docker : +Recette Docker : ```bash pnpm test:docker:live-cli-backend ``` -Recettes Docker mono-fournisseur : +Recettes Docker à fournisseur unique : ```bash pnpm test:docker:live-cli-backend:claude @@ -506,42 +508,42 @@ pnpm test:docker:live-cli-backend:codex pnpm test:docker:live-cli-backend:gemini ``` -Remarques : +Remarques : - L’exécuteur Docker se trouve dans `scripts/test-live-cli-backend-docker.sh`. -- Il exécute le test de fumée live du backend CLI à l’intérieur de l’image Docker du dépôt en tant qu’utilisateur non root `node`. -- Il résout les métadonnées de test de fumée CLI depuis l’extension propriétaire, puis installe le package CLI Linux correspondant (`@anthropic-ai/claude-code`, `@openai/codex` ou `@google/gemini-cli`) dans un préfixe inscriptible 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 une 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 le `claude -p` direct dans Docker, puis exécute deux tours Gateway backend CLI sans conserver les variables d’environnement de clé d’API Anthropic. Cette voie d’abonnement désactive par défaut les sondes Claude MCP/outils et image, car Claude achemine actuellement l’usage des applications tierces via une facturation d’usage supplémentaire plutôt que par les limites normales du plan d’abonnement. -- Le test de fumée live du backend CLI exerce désormais le même flux end-to-end pour Claude, Codex et Gemini : tour texte, tour de classification d’image, puis appel d’outil MCP `cron` vérifié via la CLI Gateway. -- Le test de fumée par défaut de Claude modifie aussi la session de Sonnet vers Opus et vérifie que la session reprise se souvient toujours d’une note antérieure. +- Il exécute le smoke live du backend CLI dans l’image Docker du dépôt en tant qu’utilisateur non root `node`. +- Il résout les métadonnées de smoke CLI à partir de l’extension propriétaire, puis installe le paquet CLI Linux correspondant (`@anthropic-ai/claude-code`, `@openai/codex` ou `@google/gemini-cli`) dans un préfixe inscriptible 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 une authentification OAuth portable Claude Code subscription via soit `~/.claude/.credentials.json` avec `claudeAiOauth.subscriptionType`, soit `CLAUDE_CODE_OAUTH_TOKEN` provenant de `claude setup-token`. Il vérifie d’abord `claude -p` directement dans Docker, puis exécute deux tours Gateway backend CLI sans conserver les variables d’environnement de clé API Anthropic. Cette voie subscription désactive par défaut les sondes Claude MCP/tool et image, car Claude route actuellement l’utilisation d’applications tierces via une facturation d’usage supplémentaire au lieu des limites normales du plan d’abonnement. +- Le smoke live du backend CLI exerce désormais le même flux end-to-end pour Claude, Codex 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 modifie aussi la session de Sonnet vers Opus et vérifie que la session reprise se souvient encore d’une note antérieure. -## Live : test de fumée de liaison ACP (`/acp spawn ... --bind here`) +## Live : smoke ACP bind (`/acp spawn ... --bind here`) -- Test : `src/gateway/gateway-acp-bind.live.test.ts` -- Objectif : valider le véritable flux de liaison de conversation ACP avec un agent ACP live : +- Test : `src/gateway/gateway-acp-bind.live.test.ts` +- Objectif : valider le vrai flux d’association de conversation ACP avec un agent ACP live : - envoyer `/acp spawn --bind here` - - lier sur place une conversation synthétique de canal de messages + - associer en place une conversation synthétique de canal de messages - envoyer un suivi normal sur cette même conversation - - vérifier que le suivi atterrit dans la transcription de session ACP liée -- Activer : + - vérifier que le suivi arrive dans la transcription de la session ACP associé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 message privé Slack - - Backend ACP : `acpx` -- Remplacements : +- 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` +- Remplacements : - `OPENCLAW_LIVE_ACP_BIND_AGENT=claude` - `OPENCLAW_LIVE_ACP_BIND_AGENT=codex` - `OPENCLAW_LIVE_ACP_BIND_AGENT=gemini` - `OPENCLAW_LIVE_ACP_BIND_AGENTS=claude,codex,gemini` - `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND='npx -y @agentclientprotocol/claude-agent-acp@'` -- Remarques : - - Cette voie utilise la surface Gateway `chat.send` avec des champs synthétiques d’itinéraire d’origine réservés à l’administration afin que les tests puissent attacher un contexte de canal de messages sans prétendre livrer de messages en externe. +- Remarques : + - Cette voie utilise la surface Gateway `chat.send` avec des champs synthétiques de route d’origine réservés aux administrateurs afin que les tests puissent attacher un contexte de canal de messages sans prétendre livrer quoi que ce soit à l’extérieur. - 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é. -Exemple : +Exemple : ```bash OPENCLAW_LIVE_ACP_BIND=1 \ @@ -549,13 +551,13 @@ OPENCLAW_LIVE_ACP_BIND=1 \ pnpm test:live src/gateway/gateway-acp-bind.live.test.ts ``` -Recette Docker : +Recette Docker : ```bash pnpm test:docker:live-acp-bind ``` -Recettes Docker mono-agent : +Recettes Docker à agent unique : ```bash pnpm test:docker:live-acp-bind:claude @@ -563,36 +565,36 @@ pnpm test:docker:live-acp-bind:codex pnpm test:docker:live-acp-bind:gemini ``` -Remarques Docker : +Remarques Docker : - L’exécuteur Docker se trouve dans `scripts/test-live-acp-bind-docker.sh`. -- Par défaut, il exécute le test de fumée de liaison ACP sur tous les agents CLI live pris en charge, en séquence : `claude`, `codex`, puis `gemini`. +- Par défaut, il exécute le smoke d’association ACP contre tous les agents CLI live pris en charge en séquence : `claude`, `codex`, puis `gemini`. - Utilisez `OPENCLAW_LIVE_ACP_BIND_AGENTS=claude`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=codex` ou `OPENCLAW_LIVE_ACP_BIND_AGENTS=gemini` pour restreindre la matrice. -- Il charge `~/.profile`, prépare dans le conteneur le matériel d’authentification CLI correspondant, installe `acpx` dans un préfixe npm inscriptible, puis installe la CLI live demandée (`@anthropic-ai/claude-code`, `@openai/codex` ou `@google/gemini-cli`) si elle est absente. -- À l’intérieur de Docker, l’exécuteur définit `OPENCLAW_LIVE_ACP_BIND_ACPX_COMMAND=$HOME/.npm-global/bin/acpx` afin que acpx conserve pour la CLI de harnais enfant les variables d’environnement fournisseur issues du profil chargé. +- Il charge `~/.profile`, prépare dans le conteneur les éléments d’authentification CLI correspondants, installe `acpx` dans un préfixe npm inscriptible, puis installe le CLI live demandé (`@anthropic-ai/claude-code`, `@openai/codex` ou `@google/gemini-cli`) s’il est absent. +- Dans Docker, l’exécuteur définit `OPENCLAW_LIVE_ACP_BIND_ACPX_COMMAND=$HOME/.npm-global/bin/acpx` afin que acpx conserve les variables d’environnement fournisseur issues du profil chargé et les rende disponibles au CLI harnais enfant. -## Live : test de fumée du harnais app-server Codex +## Live : smoke du harnais app-server Codex -- Objectif : valider le harnais Codex appartenant au Plugin via la méthode Gateway - `agent` normale : +- Objectif : valider le harnais Codex appartenant au Plugin via la méthode Gateway + `agent` normale : - charger le Plugin `codex` intégré - sélectionner `OPENCLAW_AGENT_RUNTIME=codex` - envoyer un premier tour d’agent Gateway à `codex/gpt-5.4` - - envoyer un second tour à la même session OpenClaw et vérifier que le thread + - envoyer un second tour à la même session OpenClaw et vérifier que le fil app-server peut reprendre - exécuter `/codex status` et `/codex models` via le même chemin de commande Gateway -- Test : `src/gateway/gateway-codex-harness.live.test.ts` -- Activer : `OPENCLAW_LIVE_CODEX_HARNESS=1` -- Modèle par défaut : `codex/gpt-5.4` -- Sonde d’image facultative : `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=1` -- Sonde MCP/outil facultative : `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=1` -- Le test de fumée définit `OPENCLAW_AGENT_HARNESS_FALLBACK=none` afin qu’un harnais Codex cassé - ne puisse pas réussir en se rabattant silencieusement sur Pi. -- Authentification : `OPENAI_API_KEY` depuis le shell/profil, plus copie facultative de +- Test : `src/gateway/gateway-codex-harness.live.test.ts` +- Activer : `OPENCLAW_LIVE_CODEX_HARNESS=1` +- Modèle par défaut : `codex/gpt-5.4` +- Sonde d’image facultative : `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=1` +- Sonde MCP/tool facultative : `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=1` +- Le smoke définit `OPENCLAW_AGENT_HARNESS_FALLBACK=none` afin qu’un harnais Codex + cassé ne puisse pas réussir en basculant silencieusement vers PI. +- Authentification : `OPENAI_API_KEY` depuis le shell/profil, plus copie facultative de `~/.codex/auth.json` et `~/.codex/config.toml` -Recette locale : +Recette locale : ```bash source ~/.profile @@ -603,240 +605,243 @@ OPENCLAW_LIVE_CODEX_HARNESS=1 \ pnpm test:live -- src/gateway/gateway-codex-harness.live.test.ts ``` -Recette Docker : +Recette Docker : ```bash source ~/.profile pnpm test:docker:live-codex-harness ``` -Remarques Docker : +Remarques Docker : - L’exécuteur Docker se trouve dans `scripts/test-live-codex-harness-docker.sh`. -- Il charge le `~/.profile` monté, transmet `OPENAI_API_KEY`, copie les fichiers d’authentification de la CLI Codex lorsqu’ils sont présents, installe `@openai/codex` dans un préfixe npm monté et inscriptible, prépare l’arborescence source, puis n’exécute que le test live du harnais Codex. -- Docker active par défaut les sondes d’image et MCP/outil. Définissez +- Il charge le `~/.profile` monté, transmet `OPENAI_API_KEY`, copie les fichiers + d’authentification de la CLI Codex lorsqu’ils sont présents, installe `@openai/codex` dans un préfixe npm + monté, inscriptible, prépare l’arborescence source, puis exécute uniquement le test live du harnais Codex. +- Docker active par défaut les sondes d’image et MCP/tool. Définissez `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0` ou `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0` lorsque vous avez besoin d’une exécution de débogage plus restreinte. -- Docker exporte aussi `OPENCLAW_AGENT_HARNESS_FALLBACK=none`, conformément à la configuration du test live afin qu’un repli sur `openai-codex/*` ou Pi ne puisse pas masquer une régression du harnais Codex. +- Docker exporte aussi `OPENCLAW_AGENT_HARNESS_FALLBACK=none`, conformément à la configuration du + test live, afin qu’un repli `openai-codex/*` ou PI ne puisse pas masquer une régression du harnais Codex. ### Recettes live recommandées -Les listes d’autorisation étroites et explicites sont les plus rapides et les moins instables : +Des listes d’autorisation étroites et explicites sont les plus rapides et les moins fragiles : -- Modèle unique, direct (sans Gateway) : +- Modèle unique, direct (sans Gateway) : - `OPENCLAW_LIVE_MODELS="openai/gpt-5.4" pnpm test:live src/agents/models.profiles.live.test.ts` -- Modèle unique, test de fumée Gateway : +- Modèle unique, smoke Gateway : - `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.4" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` -- Appel d’outil sur plusieurs fournisseurs : +- Appel d’outils sur plusieurs fournisseurs : - `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.4,anthropic/claude-opus-4-6,google/gemini-3-flash-preview,zai/glm-4.7,minimax/MiniMax-M2.7" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` -- Focus Google (clé d’API Gemini + Antigravity) : - - Gemini (clé d’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` +- 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` -Remarques : +Remarques : -- `google/...` utilise l’API Gemini (clé d’API). +- `google/...` utilise l’API Gemini (clé API). - `google-antigravity/...` utilise le pont OAuth Antigravity (point de terminaison d’agent de type Cloud Code Assist). -- `google-gemini-cli/...` utilise la CLI Gemini locale 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 de Google via HTTP (clé d’API / authentification de profil) ; c’est ce que la plupart des utilisateurs entendent par « Gemini ». - - CLI : OpenClaw exécute un binaire `gemini` local ; il possède sa propre authentification et peut se comporter différemment (streaming/prise en charge des outils/décalage de version). +- `google-gemini-cli/...` utilise la CLI Gemini locale sur votre machine (authentification distincte + particularités des outils). +- API Gemini vs CLI Gemini : + - API : OpenClaw appelle l’API Gemini hébergée par Google via HTTP (clé API / authentification par profil) ; c’est ce que la plupart des utilisateurs entendent par « Gemini ». + - CLI : OpenClaw exécute un binaire local `gemini` ; il a sa propre authentification et peut se comporter différemment (streaming/prise en charge des outils/décalage de version). -## Live : matrice de modèles (ce que nous couvrons) +## Live : matrice de modèles (ce que nous couvrons) -Il n’existe pas de « liste de modèles CI » fixe (le live est opt-in), mais voici les modèles **recommandés** à couvrir régulièrement sur une machine de développement disposant des clés. +Il n’existe pas de « liste de modèles CI » fixe (live est activé à la demande), mais voici les modèles **recommandés** à couvrir régulièrement sur une machine de développement disposant des clés. -### Ensemble de test de fumée moderne (appel d’outil + image) +### Ensemble smoke moderne (appel d’outils + image) -Il s’agit de l’exécution « modèles courants » que nous nous attendons à voir continuer à fonctionner : +Il s’agit de l’exécution des « modèles courants » que nous nous attendons à maintenir fonctionnelle : -- OpenAI (hors Codex) : `openai/gpt-5.4` (facultatif : `openai/gpt-5.4-mini`) -- OpenAI Codex : `openai-codex/gpt-5.4` -- 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` (évitez les anciens modèles Gemini 2.x) -- Google (Antigravity) : `google-antigravity/claude-opus-4-6-thinking` et `google-antigravity/gemini-3-flash` -- Z.AI (GLM) : `zai/glm-4.7` -- MiniMax : `minimax/MiniMax-M2.7` +- OpenAI (hors Codex) : `openai/gpt-5.4` (facultatif : `openai/gpt-5.4-mini`) +- OpenAI Codex : `openai-codex/gpt-5.4` +- 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` (évitez les anciens modèles Gemini 2.x) +- Google (Antigravity) : `google-antigravity/claude-opus-4-6-thinking` et `google-antigravity/gemini-3-flash` +- Z.AI (GLM) : `zai/glm-4.7` +- MiniMax : `minimax/MiniMax-M2.7` -Exécuter le test de fumée Gateway avec outils + image : +Exécuter le smoke Gateway avec outils + image : `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.4,openai-codex/gpt-5.4,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,zai/glm-4.7,minimax/MiniMax-M2.7" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` -### Référence de base : appel d’outil (Read + Exec facultatif) +### Référence : appel d’outils (Read + Exec facultatif) -Choisissez au moins un modèle par famille de fournisseurs : +Choisissez-en au moins un par famille de fournisseurs : -- OpenAI : `openai/gpt-5.4` (ou `openai/gpt-5.4-mini`) -- 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`) -- Z.AI (GLM) : `zai/glm-4.7` -- MiniMax : `minimax/MiniMax-M2.7` +- OpenAI : `openai/gpt-5.4` (ou `openai/gpt-5.4-mini`) +- 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`) +- Z.AI (GLM) : `zai/glm-4.7` +- MiniMax : `minimax/MiniMax-M2.7` -Couverture supplémentaire facultative (utile à avoir) : +Couverture supplémentaire facultative (agréable à avoir) : -- xAI : `xai/grok-4` (ou la dernière version disponible) -- Mistral : `mistral/`… (choisissez un modèle compatible « tools » que vous avez activé) -- Cerebras : `cerebras/`… (si vous y avez accès) -- LM Studio : `lmstudio/`… (local ; l’appel d’outil dépend du mode API) +- xAI : `xai/grok-4` (ou la dernière version disponible) +- Mistral : `mistral/`… (choisissez un modèle compatible « tools » 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) +### Vision : envoi d’image (pièce jointe → message multimodal) -Incluez au moins un modèle compatible image dans `OPENCLAW_LIVE_GATEWAY_MODELS` (variants Claude/Gemini/OpenAI compatibles vision, etc.) afin d’exercer la sonde d’image. +Incluez au moins un modèle compatible image dans `OPENCLAW_LIVE_GATEWAY_MODELS` (Claude/Gemini/variantes OpenAI compatibles vision, etc.) afin d’exercer la sonde d’image. -### Agrégateurs / passerelles alternatives +### Agrégateurs / Gateway alternatifs -Si vous avez les clés activées, nous prenons aussi en charge les tests via : +Si vous avez activé les clés, nous prenons aussi 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`) +- 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 live (si vous avez les identifiants/la configuration) : +Autres fournisseurs que vous pouvez inclure dans la matrice live (si vous avez les identifiants/la configuration) : -- Intégrés : `openai`, `openai-codex`, `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.) +- Intégrés : `openai`, `openai-codex`, `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.) -Astuce : n’essayez pas de coder en dur « tous les modèles » dans la documentation. La liste de référence est celle que renvoie `discoverModels(...)` sur votre machine + les clés disponibles. +Astuce : n’essayez pas de coder en dur « tous les modèles » dans la documentation. La liste faisant autorité est ce que `discoverModels(...)` renvoie sur votre machine + les clés disponibles. -## Identifiants (ne jamais valider) +## Identifiants (ne jamais commit) -Les tests live découvrent les identifiants de la même manière que la CLI. Implications pratiques : +Les tests live découvrent les identifiants de la même manière que la CLI. Implications pratiques : - Si la CLI fonctionne, les tests live devraient trouver les mêmes clés. -- Si un test live indique « aucun identifiant », déboguez-le comme vous le feriez pour `openclaw models list` / la sélection du modèle. +- Si un test live indique « pas d’identifiants », déboguez-le de la même manière que `openclaw models list` / la sélection de modèle. -- Profils d’authentification par agent : `~/.openclaw/agents//agent/auth-profiles.json` (c’est ce que signifient les « clés de profil » dans les tests live) -- Configuration : `~/.openclaw/openclaw.json` (ou `OPENCLAW_CONFIG_PATH`) -- Répertoire d’état hérité : `~/.openclaw/credentials/` (copié dans le HOME live préparé lorsqu’il est présent, mais pas dans le magasin principal des clés de profil) -- Les exécutions live locales copient par défaut la configuration active, les fichiers `auth-profiles.json` par agent, l’ancien répertoire `credentials/` et les répertoires d’authentification CLI externes pris en charge dans un HOME de test temporaire ; les HOME live préparés ignorent `workspace/` et `sandboxes/`, et les remplacements de chemin `agents.*.workspace` / `agentDir` sont supprimés afin que les sondes restent hors de votre véritable espace de travail hôte. +- Profils d’authentification par agent : `~/.openclaw/agents//agent/auth-profiles.json` (c’est ce que signifie « clés de profil » dans les tests live) +- Configuration : `~/.openclaw/openclaw.json` (ou `OPENCLAW_CONFIG_PATH`) +- Ancien répertoire d’état : `~/.openclaw/credentials/` (copié dans le home live préparé lorsqu’il est présent, mais pas dans le magasin principal de clés de profil) +- Les exécutions live locales copient par défaut la configuration active, les fichiers `auth-profiles.json` par agent, l’ancien `credentials/` et les répertoires d’authentification CLI externes pris en charge dans un home de test temporaire ; les homes live préparés ignorent `workspace/` et `sandboxes/`, et les remplacements de chemin `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 (par exemple exportées dans votre `~/.profile`), exécutez les tests locaux après `source ~/.profile`, ou utilisez les exécuteurs Docker ci-dessous (ils peuvent monter `~/.profile` dans le conteneur). +Si vous souhaitez vous appuyer sur des clés d’environnement (par exemple exportées dans votre `~/.profile`), exécutez les tests locaux après `source ~/.profile`, ou utilisez les exécuteurs Docker ci-dessous (ils peuvent monter `~/.profile` dans le conteneur). -## Live Deepgram (transcription audio) +## Deepgram live (transcription audio) -- Test : `src/media-understanding/providers/deepgram/audio.live.test.ts` -- Activer : `DEEPGRAM_API_KEY=... DEEPGRAM_LIVE_TEST=1 pnpm test:live src/media-understanding/providers/deepgram/audio.live.test.ts` +- Test : `src/media-understanding/providers/deepgram/audio.live.test.ts` +- Activer : `DEEPGRAM_API_KEY=... DEEPGRAM_LIVE_TEST=1 pnpm test:live src/media-understanding/providers/deepgram/audio.live.test.ts` -## Live BytePlus coding plan +## BytePlus coding plan live -- Test : `src/agents/byteplus.live.test.ts` -- Activer : `BYTEPLUS_API_KEY=... BYTEPLUS_LIVE_TEST=1 pnpm test:live src/agents/byteplus.live.test.ts` -- Remplacement facultatif de modèle : `BYTEPLUS_CODING_MODEL=ark-code-latest` +- Test : `src/agents/byteplus.live.test.ts` +- Activer : `BYTEPLUS_API_KEY=... BYTEPLUS_LIVE_TEST=1 pnpm test:live src/agents/byteplus.live.test.ts` +- Remplacement de modèle facultatif : `BYTEPLUS_CODING_MODEL=ark-code-latest` -## Live médias de workflow ComfyUI +## ComfyUI workflow media live -- Test : `extensions/comfy/comfy.live.test.ts` -- Activer : `OPENCLAW_LIVE_TEST=1 COMFY_LIVE_TEST=1 pnpm test:live -- extensions/comfy/comfy.live.test.ts` -- Portée : - - Exerce les chemins image, vidéo et `music_generate` du comfy intégré +- Test : `extensions/comfy/comfy.live.test.ts` +- Activer : `OPENCLAW_LIVE_TEST=1 COMFY_LIVE_TEST=1 pnpm test:live -- extensions/comfy/comfy.live.test.ts` +- Portée : + - Exerce les chemins intégrés d’image, de vidéo et `music_generate` de comfy - Ignore chaque capacité sauf si `models.providers.comfy.` est configuré - - Utile après une modification de l’envoi de workflow comfy, du polling, des téléchargements ou de l’enregistrement du Plugin + - Utile après avoir modifié la soumission de workflow comfy, le polling, les téléchargements ou l’enregistrement du Plugin -## Live génération d’image +## Génération d’images live -- Test : `src/image-generation/runtime.live.test.ts` -- Commande : `pnpm test:live src/image-generation/runtime.live.test.ts` -- Harnais : `pnpm test:live:media image` -- Portée : - - Énumère chaque Plugin fournisseur de génération d’image enregistré - - Charge les variables d’environnement fournisseur manquantes depuis votre shell de connexion (`~/.profile`) avant les sondes - - Utilise par défaut les clés d’API live/env 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 +- Test : `src/image-generation/runtime.live.test.ts` +- Commande : `pnpm test:live src/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é + - Charge les variables d’environnement fournisseur manquantes à partir de votre shell de connexion (`~/.profile`) avant la sonde + - Utilise par défaut les clés API live/env avant les profils d’authentification stockés, afin que des clés de test périmées 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 variantes standard de génération d’image via la capacité runtime partagée : + - Exécute les variantes standards de génération d’images via la capacité runtime partagée : - `google:flash-generate` - `google:pro-generate` - `google:pro-edit` - `openai:default-generate` -- Fournisseurs intégrés actuellement couverts : +- Fournisseurs intégrés actuellement couverts : - `openai` - `google` -- Restriction facultative : +- Restriction facultative : - `OPENCLAW_LIVE_IMAGE_GENERATION_PROVIDERS="openai,google"` - `OPENCLAW_LIVE_IMAGE_GENERATION_MODELS="openai/gpt-image-1,google/gemini-3.1-flash-image-preview"` - `OPENCLAW_LIVE_IMAGE_GENERATION_CASES="google:flash-generate,google:pro-edit"` -- Comportement d’authentification facultatif : - - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour forcer l’authentification par magasin de profils et ignorer les remplacements uniquement fournis par l’environnement +- Comportement d’authentification facultatif : + - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour imposer l’authentification par magasin de profils et ignorer les remplacements via env uniquement -## Live génération musicale +## Génération de musique live -- Test : `extensions/music-generation-providers.live.test.ts` -- Activer : `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é intégré des fournisseurs de génération musicale +- Test : `extensions/music-generation-providers.live.test.ts` +- Activer : `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é intégré des fournisseurs de génération de musique - Couvre actuellement Google et MiniMax - - Charge les variables d’environnement fournisseur depuis votre shell de connexion (`~/.profile`) avant les sondes - - Utilise par défaut les clés d’API live/env 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 + - Charge les variables d’environnement fournisseur à partir de votre shell de connexion (`~/.profile`) avant la sonde + - Utilise par défaut les clés API live/env avant les profils d’authentification stockés, afin que des clés de test périmées 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 uniquement sous forme de prompt + - Exécute les deux modes runtime déclarés lorsqu’ils sont disponibles : + - `generate` avec entrée basée uniquement sur 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 live Comfy séparé, pas ce balayage partagé -- Restriction facultative : + - Couverture actuelle de la voie partagée : + - `google` : `generate`, `edit` + - `minimax` : `generate` + - `comfy` : fichier live 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.5+"` -- Comportement d’authentification facultatif : - - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour forcer l’authentification par magasin de profils et ignorer les remplacements uniquement fournis par l’environnement +- Comportement d’authentification facultatif : + - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour imposer l’authentification par magasin de profils et ignorer les remplacements via env uniquement -## Live génération vidéo +## Génération de vidéo live -- Test : `extensions/video-generation-providers.live.test.ts` -- Activer : `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é intégré des fournisseurs de génération vidéo - - Utilise par défaut le chemin de test de fumée sûr pour la release : fournisseurs autres que FAL, une requête text-to-video par fournisseur, prompt lobster d’une seconde, et un plafond d’opération par fournisseur issu de `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS` (`180000` par défaut) - - Ignore FAL par défaut, car la latence de file d’attente côté fournisseur peut dominer le temps de release ; passez `--video-providers fal` ou `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="fal"` pour l’exécuter explicitement - - Charge les variables d’environnement fournisseur depuis votre shell de connexion (`~/.profile`) avant les sondes - - Utilise par défaut les clés d’API live/env 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 +- Test : `extensions/video-generation-providers.live.test.ts` +- Activer : `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é intégré des fournisseurs de génération de vidéo + - Utilise par défaut le chemin smoke sûr pour les versions : fournisseurs hors FAL, une requête text-to-video par fournisseur, invite lobster d’une seconde, et une limite d’opération par fournisseur définie par `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS` (`180000` par défaut) + - Ignore FAL par défaut, car la latence de 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 + - Charge les variables d’environnement fournisseur à partir de votre shell de connexion (`~/.profile`) avant la sonde + - Utilise par défaut les clés API live/env avant les profils d’authentification stockés, afin que des clés de test périmées dans `auth-profiles.json` ne masquent pas les véritables identifiants du shell - Ignore les fournisseurs sans authentification/profil/modèle utilisable - - N’exécute que `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 image locale adossée à un buffer 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 adossée à un buffer dans le balayage partagé - - Fournisseurs `imageToVideo` actuellement déclarés mais ignorés dans le balayage partagé : - - `vydra`, car le `veo3` intégré est uniquement texte et le `kling` intégré exige une URL d’image distante - - Couverture Vydra spécifique au fournisseur : + - 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 des entrées d’image locales basées sur buffer dans le balayage partagé + - `videoToVideo` lorsque le fournisseur déclare `capabilities.videoToVideo.enabled` et que le fournisseur/modèle sélectionné accepte des entrées vidéo locales basées sur buffer dans le balayage partagé + - Fournisseurs `imageToVideo` actuellement déclarés mais ignorés dans le balayage partagé : + - `vydra`, car le `veo3` intégré est uniquement textuel et le `kling` intégré exige une URL d’image distante + - Couverture spécifique au fournisseur Vydra : - `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_VYDRA_VIDEO=1 pnpm test:live -- extensions/vydra/vydra.live.test.ts` - ce fichier exécute `veo3` text-to-video ainsi qu’une voie `kling` qui utilise par défaut une fixture d’URL d’image distante - - Couverture live `videoToVideo` actuelle : + - Couverture live actuelle `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é : + - Fournisseurs `videoToVideo` actuellement déclarés mais ignorés dans le balayage partagé : - `alibaba`, `qwen`, `xai`, car ces chemins exigent actuellement des URL de référence distantes `http(s)` / MP4 - - `google`, car la voie partagée Gemini/Veo actuelle utilise une entrée locale adossée à un buffer, et ce chemin n’est pas accepté dans le balayage partagé - - `openai`, car la voie partagée actuelle ne garantit pas l’accès spécifique à l’organisation pour l’inpainting/remix vidéo -- Restriction facultative : + - `google`, car la voie Gemini/Veo partagée actuelle utilise une entrée locale basée sur buffer, et ce chemin n’est pas accepté dans le balayage partagé + - `openai`, car la voie partagée actuelle ne garantit pas l’accès spécifique à l’organisation à l’inpaint/remix vidéo +- Restriction facultative : - `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="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 tous les fournisseurs 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 dans un test de fumée agressif -- Comportement d’authentification facultatif : - - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour forcer l’authentification par magasin de profils et ignorer les remplacements uniquement fournis par l’environnement + - `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 la limite d’opération de chaque fournisseur lors d’une exécution smoke agressive +- Comportement d’authentification facultatif : + - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour imposer l’authentification par magasin de profils et ignorer les remplacements via env uniquement ## Harnais live média -- Commande : `pnpm test:live:media` -- Objectif : - - Exécute les suites live partagées image, musique et vidéo via un point d’entrée natif du dépôt unique - - Charge automatiquement les variables d’environnement fournisseur manquantes depuis `~/.profile` - - 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 de mode silencieux reste cohérent -- Exemples : +- Commande : `pnpm test:live:media` +- Objectif : + - Exécute les suites live partagées d’image, de musique et de vidéo via un point d’entrée natif au dépôt unique + - Charge automatiquement les variables d’environnement fournisseur manquantes à partir de `~/.profile` + - Restreint automatiquement chaque suite, par défaut, aux fournisseurs qui disposent actuellement d’une authentification utilisable + - 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` -## Exécuteurs Docker (vérifications facultatives « fonctionne sous Linux ») +## Exécuteurs Docker (vérifications facultatives « fonctionne sous Linux ») -Ces exécuteurs Docker se répartissent en deux catégories : +Ces exécuteurs Docker se divisent en deux groupes : -- Exécuteurs live-model : `test:docker:live-models` et `test:docker:live-gateway` n’exécutent que leur fichier live à clés de profil correspondant dans l’image Docker du dépôt (`src/agents/models.profiles.live.test.ts` et `src/gateway/gateway-models.profiles.live.test.ts`), en montant votre répertoire de config local et votre espace de travail (et en chargeant `~/.profile` s’il est monté). Les points d’entrée locaux correspondants sont `test:live:models-profiles` et `test:live:gateway-profiles`. -- Les exécuteurs Docker live utilisent par défaut un plafond de test de fumée plus petit afin qu’un balayage Docker complet reste praticable : +- Exécuteurs de modèles live : `test:docker:live-models` et `test:docker:live-gateway` n’exécutent que leur fichier live à clés de profil correspondant dans l’image Docker du dépôt (`src/agents/models.profiles.live.test.ts` et `src/gateway/gateway-models.profiles.live.test.ts`), en montant votre répertoire de configuration local et votre espace de travail (et en chargeant `~/.profile` s’il est monté). Les points d’entrée locaux correspondants sont `test:live:models-profiles` et `test:live:gateway-profiles`. +- Les exécuteurs Docker live utilisent par défaut une limite smoke plus petite afin qu’un balayage Docker complet reste praticable : `test:docker:live-models` utilise par défaut `OPENCLAW_LIVE_MAX_MODELS=12`, et `test:docker:live-gateway` utilise par défaut `OPENCLAW_LIVE_GATEWAY_SMOKE=1`, `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=8`, @@ -844,174 +849,172 @@ Ces exécuteurs Docker se répartissent en deux catégories : `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Remplacez ces variables d’environnement lorsque vous voulez explicitement le balayage exhaustif plus large. - `test:docker:all` construit une fois l’image Docker live via `test:docker:live-build`, puis la réutilise pour les deux voies Docker live. -- Exécuteurs de test de fumée de conteneur : `test:docker:openwebui`, `test:docker:onboard`, `test:docker:gateway-network`, `test:docker:mcp-channels`, et `test:docker:plugins` démarrent un ou plusieurs vrais conteneurs et vérifient des chemins d’intégration de plus haut niveau. +- Exécuteurs smoke de conteneur : `test:docker:openwebui`, `test:docker:onboard`, `test:docker:gateway-network`, `test:docker:mcp-channels` et `test:docker:plugins` démarrent un ou plusieurs conteneurs réels et vérifient des chemins d’intégration de niveau supérieur. -Les exécuteurs Docker live-model montent aussi en bind uniquement les HOME d’authentification CLI nécessaires (ou tous ceux pris en charge lorsque l’exécution n’est pas restreinte), puis les copient dans le HOME du conteneur avant l’exécution afin que l’OAuth CLI externe puisse rafraîchir les jetons sans modifier le magasin d’authentification de l’hôte : +Les exécuteurs Docker de modèles live montent également en bind uniquement les homes d’authentification CLI nécessaires (ou tous ceux pris en charge lorsque l’exécution n’est pas restreinte), puis les copient dans le home du conteneur avant l’exécution afin que l’OAuth de CLI externe puisse actualiser les jetons sans modifier le magasin d’authentification de l’hôte : -- Modèles directs : `pnpm test:docker:live-models` (script : `scripts/test-live-models-docker.sh`) -- Test de fumée de liaison ACP : `pnpm test:docker:live-acp-bind` (script : `scripts/test-live-acp-bind-docker.sh`) -- Test de fumée du backend CLI : `pnpm test:docker:live-cli-backend` (script : `scripts/test-live-cli-backend-docker.sh`) -- Test de fumée du harnais app-server Codex : `pnpm test:docker:live-codex-harness` (script : `scripts/test-live-codex-harness-docker.sh`) -- Gateway + agent de développement : `pnpm test:docker:live-gateway` (script : `scripts/test-live-gateway-models-docker.sh`) -- Test de fumée live Open WebUI : `pnpm test:docker:openwebui` (script : `scripts/e2e/openwebui-docker.sh`) -- Assistant d’onboarding (TTY, scaffolding complet) : `pnpm test:docker:onboard` (script : `scripts/e2e/onboard-docker.sh`) -- Réseau Gateway (deux conteneurs, authentification WS + état de santé) : `pnpm test:docker:gateway-network` (script : `scripts/e2e/gateway-network-docker.sh`) -- Pont de canal MCP (Gateway initialisé + pont stdio + test de fumée brut de trame de notification Claude) : `pnpm test:docker:mcp-channels` (script : `scripts/e2e/mcp-channels-docker.sh`) -- Plugins (test de fumée d’installation + alias `/plugin` + sémantique de redémarrage du bundle Claude) : `pnpm test:docker:plugins` (script : `scripts/e2e/plugins-docker.sh`) +- Modèles directs : `pnpm test:docker:live-models` (script : `scripts/test-live-models-docker.sh`) +- Smoke ACP bind : `pnpm test:docker:live-acp-bind` (script : `scripts/test-live-acp-bind-docker.sh`) +- Smoke backend CLI : `pnpm test:docker:live-cli-backend` (script : `scripts/test-live-cli-backend-docker.sh`) +- Smoke du harnais app-server Codex : `pnpm test:docker:live-codex-harness` (script : `scripts/test-live-codex-harness-docker.sh`) +- Gateway + agent de développement : `pnpm test:docker:live-gateway` (script : `scripts/test-live-gateway-models-docker.sh`) +- Smoke live Open WebUI : `pnpm test:docker:openwebui` (script : `scripts/e2e/openwebui-docker.sh`) +- Assistant d’onboarding (TTY, échafaudage complet) : `pnpm test:docker:onboard` (script : `scripts/e2e/onboard-docker.sh`) +- Réseau Gateway (deux conteneurs, auth WS + santé) : `pnpm test:docker:gateway-network` (script : `scripts/e2e/gateway-network-docker.sh`) +- Pont de canal MCP (Gateway initialisée + pont stdio + smoke brut de trame de notification Claude) : `pnpm test:docker:mcp-channels` (script : `scripts/e2e/mcp-channels-docker.sh`) +- Plugins (smoke d’installation + alias `/plugin` + sémantique de redémarrage du bundle Claude) : `pnpm test:docker:plugins` (script : `scripts/e2e/plugins-docker.sh`) -Les exécuteurs Docker live-model montent aussi en bind le clone courant en lecture seule et -le préparent dans un répertoire de travail temporaire à l’intérieur du conteneur. Cela garde l’image runtime -légère tout en exécutant Vitest sur votre source/config locale exacte. -L’étape de préparation ignore les gros caches uniquement locaux et les sorties de build d’app comme -`.pnpm-store`, `.worktrees`, `__openclaw_vitest__`, ainsi que les répertoires `.build` locaux à l’app ou les sorties -Gradle, afin que les exécutions Docker live ne passent pas des minutes à copier +Les exécuteurs Docker de modèles live montent également en bind la copie de travail courante en lecture seule et +la préparent dans un répertoire de travail temporaire à l’intérieur du conteneur. Cela garde l’image runtime +légère tout en exécutant Vitest contre votre source/configuration locale exacte. +L’étape de préparation ignore les gros caches locaux uniquement et les sorties de build d’application telles que +`.pnpm-store`, `.worktrees`, `__openclaw_vitest__`, ainsi que les répertoires `.build` locaux à l’application ou +les répertoires de sortie Gradle, afin que les exécutions live Docker ne passent pas des minutes à copier des artefacts propres à la machine. Ils définissent aussi `OPENCLAW_SKIP_CHANNELS=1` afin que les sondes live Gateway ne démarrent pas de vrais workers de canal Telegram/Discord/etc. à l’intérieur du conteneur. -`test:docker:live-models` exécute toujours `pnpm test:live`, alors transmettez aussi -`OPENCLAW_LIVE_GATEWAY_*` lorsque vous devez restreindre ou exclure la couverture live -Gateway de cette voie Docker. -`test:docker:openwebui` est un test de fumée de compatibilité de plus haut niveau : il démarre un +`test:docker:live-models` exécute toujours `pnpm test:live`, donc transmettez aussi +`OPENCLAW_LIVE_GATEWAY_*` lorsque vous devez restreindre ou exclure la couverture +live Gateway de cette voie Docker. +`test:docker:openwebui` est un smoke de compatibilité de niveau supérieur : il démarre un conteneur Gateway OpenClaw avec les points de terminaison HTTP compatibles OpenAI activés, -démarre un conteneur Open WebUI épinglé contre ce Gateway, se connecte via +démarre un conteneur Open WebUI épinglé contre cette Gateway, se connecte via Open WebUI, vérifie que `/api/models` expose `openclaw/default`, puis envoie une vraie requête de chat via le proxy `/api/chat/completions` d’Open WebUI. -La première exécution peut être sensiblement plus lente, car Docker peut devoir extraire -l’image Open WebUI et Open WebUI peut devoir terminer sa propre configuration de démarrage à froid. +La première exécution peut être sensiblement plus lente, car Docker peut devoir récupérer l’image +Open WebUI et Open WebUI peut devoir terminer sa propre configuration de démarrage à froid. Cette voie attend une clé de modèle live utilisable, et `OPENCLAW_PROFILE_FILE` -(`~/.profile` par défaut) est le principal moyen de la fournir dans les exécutions sous Docker. -Les exécutions réussies affichent une petite charge utile JSON comme `{ "ok": true, "model": +(`~/.profile` par défaut) est la principale façon de la fournir dans les exécutions Dockerisées. +Les exécutions réussies affichent une petite charge utile JSON du type `{ "ok": true, "model": "openclaw/default", ... }`. `test:docker:mcp-channels` est volontairement déterministe et n’a pas besoin d’un -véritable compte Telegram, Discord ou iMessage. Il démarre un conteneur Gateway -initialisé, lance un second conteneur qui démarre `openclaw mcp serve`, puis -vérifie la découverte de conversation routée, les lectures de transcriptions, les métadonnées de pièces jointes, -le comportement de la file d’événements live, le routage des envois sortants, et les notifications de canal + -permissions de style Claude via le véritable pont stdio MCP. La vérification des notifications -inspecte directement les trames MCP stdio brutes afin que le test de fumée valide ce que le -pont émet réellement, et pas seulement ce qu’un SDK client particulier choisit d’exposer. +vrai compte Telegram, Discord ou iMessage. Il démarre un conteneur Gateway +initialisé, lance un second conteneur qui exécute `openclaw mcp serve`, puis +vérifie la découverte de conversation routée, la lecture des transcriptions, les métadonnées de pièces jointes, +le comportement de la file d’événements live, le routage d’envoi sortant, ainsi que les notifications de canal + +de permissions de type Claude sur le véritable pont stdio MCP. La vérification des notifications +inspecte directement les trames MCP stdio brutes afin que le smoke valide ce que le +pont émet réellement, et non seulement ce qu’un SDK client particulier choisit d’exposer. -Test manuel ACP de thread en langage naturel (hors CI) : +Smoke manuel ACP pour les fils en langage naturel (hors CI) : - `bun scripts/dev/discord-acp-plain-language-smoke.ts --channel ...` -- Conservez ce script pour les workflows de régression/débogage. Il pourra être de nouveau nécessaire pour la validation du routage des threads ACP, donc ne le supprimez pas. +- Conservez ce script pour les workflows de régression/de débogage. Il pourra être à nouveau nécessaire pour la validation du routage des fils ACP, donc ne le supprimez pas. -Variables d’environnement utiles : +Variables d’environnement utiles : -- `OPENCLAW_CONFIG_DIR=...` (par défaut : `~/.openclaw`) monté sur `/home/node/.openclaw` -- `OPENCLAW_WORKSPACE_DIR=...` (par défaut : `~/.openclaw/workspace`) monté sur `/home/node/.openclaw/workspace` -- `OPENCLAW_PROFILE_FILE=...` (par défaut : `~/.profile`) monté sur `/home/node/.profile` et chargé avant l’exécution des tests -- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1` pour vérifier uniquement les variables d’environnement chargées depuis `OPENCLAW_PROFILE_FILE`, avec des répertoires config/workspace temporaires et sans montage d’authentification CLI externe -- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (par défaut : `~/.cache/openclaw/docker-cli-tools`) monté sur `/home/node/.npm-global` pour les installations CLI mises en cache dans Docker -- Les répertoires/fichiers d’authentification CLI externes sous `$HOME` sont montés en lecture seule sous `/host-auth...`, puis copiés dans `/home/node/...` avant le démarrage des tests - - Répertoires par défaut : `.minimax` - - Fichiers par défaut : `~/.codex/auth.json`, `~/.codex/config.toml`, `.claude.json`, `~/.claude/.credentials.json`, `~/.claude/settings.json`, `~/.claude/settings.local.json` +- `OPENCLAW_CONFIG_DIR=...` (par défaut : `~/.openclaw`) monté vers `/home/node/.openclaw` +- `OPENCLAW_WORKSPACE_DIR=...` (par défaut : `~/.openclaw/workspace`) monté vers `/home/node/.openclaw/workspace` +- `OPENCLAW_PROFILE_FILE=...` (par défaut : `~/.profile`) monté vers `/home/node/.profile` et chargé avant l’exécution des tests +- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1` pour vérifier uniquement les variables d’environnement chargées depuis `OPENCLAW_PROFILE_FILE`, en utilisant des répertoires temporaires de configuration/espace de travail et sans montage d’authentification CLI externe +- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (par défaut : `~/.cache/openclaw/docker-cli-tools`) monté vers `/home/node/.npm-global` pour les installations CLI mises en cache dans Docker +- Les répertoires/fichiers d’authentification CLI externes sous `$HOME` sont montés en lecture seule sous `/host-auth...`, puis copiés vers `/home/node/...` avant le démarrage des tests + - Répertoires par défaut : `.minimax` + - Fichiers par défaut : `~/.codex/auth.json`, `~/.codex/config.toml`, `.claude.json`, `~/.claude/.credentials.json`, `~/.claude/settings.json`, `~/.claude/settings.local.json` - Les exécutions restreintes par fournisseur ne montent que les répertoires/fichiers nécessaires déduits de `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` - - Remplacez manuellement avec `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none`, ou une liste séparée par des virgules comme `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex` + - Remplacement manuel avec `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none`, ou une liste séparée par des virgules comme `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex` - `OPENCLAW_LIVE_GATEWAY_MODELS=...` / `OPENCLAW_LIVE_MODELS=...` pour restreindre l’exécution - `OPENCLAW_LIVE_GATEWAY_PROVIDERS=...` / `OPENCLAW_LIVE_PROVIDERS=...` pour filtrer les fournisseurs dans le conteneur -- `OPENCLAW_SKIP_DOCKER_BUILD=1` pour réutiliser une image `openclaw:local-live` existante lors de relances ne nécessitant pas de reconstruction +- `OPENCLAW_SKIP_DOCKER_BUILD=1` pour réutiliser une image `openclaw:local-live` existante lors de réexécutions qui ne nécessitent pas de reconstruction - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour garantir que les identifiants proviennent du magasin de profils (et non de l’environnement) -- `OPENCLAW_OPENWEBUI_MODEL=...` pour choisir le modèle exposé par le Gateway pour le test de fumée Open WebUI -- `OPENCLAW_OPENWEBUI_PROMPT=...` pour remplacer le prompt de vérification de nonce utilisé par le test de fumée Open WebUI +- `OPENCLAW_OPENWEBUI_MODEL=...` pour choisir le modèle exposé par la Gateway pour le smoke Open WebUI +- `OPENCLAW_OPENWEBUI_PROMPT=...` pour remplacer l’invite de vérification par nonce utilisée par le smoke Open WebUI - `OPENWEBUI_IMAGE=...` pour remplacer le tag d’image Open WebUI épinglé -## Vérification de cohérence de la documentation +## Vérification de la documentation -Exécutez les vérifications de documentation après des modifications de docs : `pnpm check:docs`. -Exécutez la validation complète des ancres Mintlify lorsque vous avez aussi besoin des vérifications d’en-têtes dans la page : `pnpm docs:check-links:anchors`. +Exécutez les vérifications de documentation après des modifications de documentation : `pnpm check:docs`. +Exécutez la validation complète des ancres Mintlify lorsque vous avez aussi besoin de vérifier les titres dans la page : `pnpm docs:check-links:anchors`. -## Régression hors ligne (compatible CI) +## Régression hors ligne (sûre pour la CI) -Voici des régressions de « pipeline réel » sans vrais fournisseurs : +Voici des régressions de « vrai pipeline » sans vrais fournisseurs : -- Appel d’outil Gateway (mock OpenAI, vraie boucle Gateway + agent) : `src/gateway/gateway.test.ts` (cas : "runs a mock OpenAI tool call end-to-end via gateway agent loop") -- Assistant Gateway (WS `wizard.start`/`wizard.next`, écrit config + auth imposées) : `src/gateway/gateway.test.ts` (cas : "runs wizard over ws and writes auth token config") +- Appel d’outil Gateway (mock OpenAI, vraie boucle Gateway + agent) : `src/gateway/gateway.test.ts` (cas : "runs a mock OpenAI tool call end-to-end via gateway agent loop") +- Assistant Gateway (WS `wizard.start`/`wizard.next`, écriture de configuration + auth appliquée) : `src/gateway/gateway.test.ts` (cas : "runs wizard over ws and writes auth token config") -## Évaluations de fiabilité d’agent (Skills) +## Évaluations de fiabilité de l’agent (Skills) -Nous avons déjà quelques tests compatibles CI qui se comportent comme des « évaluations de fiabilité d’agent » : +Nous avons déjà quelques tests sûrs pour la CI qui se comportent comme des « évaluations de fiabilité de l’agent » : - Appel d’outil simulé via la vraie boucle Gateway + agent (`src/gateway/gateway.test.ts`). - Flux d’assistant end-to-end qui valident le câblage de session et les effets de configuration (`src/gateway/gateway.test.ts`). -Ce qui manque encore pour les Skills (voir [Skills](/fr/tools/skills)) : +Ce qui manque encore pour les Skills (voir [Skills](/fr/tools/skills)) : -- **Décision :** lorsque des Skills sont listées dans le prompt, l’agent choisit-il la bonne Skill (ou évite-t-il celles qui ne sont pas pertinentes) ? -- **Conformité :** l’agent lit-il `SKILL.md` avant usage et suit-il les étapes/arguments requis ? -- **Contrats de workflow :** scénarios multi-tours qui vérifient l’ordre des outils, la conservation de l’historique de session et les limites du sandbox. +- **Décision** : lorsque des Skills sont listées dans l’invite, l’agent choisit-il la bonne Skill (ou évite-t-il celles qui ne sont pas pertinentes) ? +- **Conformité** : l’agent lit-il `SKILL.md` avant utilisation et suit-il les étapes/arguments requis ? +- **Contrats de workflow** : scénarios multi-tours qui vérifient l’ordre des outils, la conservation de l’historique de session et les limites du bac à sable. -Les futures évaluations doivent d’abord rester déterministes : +Les futures évaluations doivent d’abord rester déterministes : -- Un exécuteur de scénarios utilisant des fournisseurs simulés pour vérifier les appels d’outils + leur ordre, la lecture des fichiers de Skills et le câblage de session. -- Une petite suite de scénarios centrés sur les Skills (utiliser vs éviter, contrôles, injection de prompt). -- Des évaluations live facultatives (opt-in, contrôlées par l’environnement) uniquement après la mise en place de la suite compatible CI. +- Un exécuteur de scénarios utilisant des fournisseurs simulés pour vérifier les appels d’outils + leur ordre, les lectures de fichiers de Skill et le câblage de session. +- Une petite suite de scénarios centrés sur les Skills (utiliser vs éviter, barrières, injection d’invite). +- Des évaluations live facultatives (activation à la demande, protégées par variables d’environnement) seulement après la mise en place de la suite sûre pour la CI. -## Tests de contrat (forme des plugins et des canaux) +## Tests de contrat (forme des Plugins et des canaux) -Les tests de contrat vérifient que chaque Plugin et canal enregistré respecte son -contrat d’interface. Ils parcourent tous les Plugins découverts et exécutent une suite de -vérifications de forme et de comportement. La voie unitaire `pnpm test` par défaut -ignore volontairement ces fichiers de couture partagée et de tests de fumée ; exécutez les commandes de contrat explicitement -lorsque vous touchez à des surfaces partagées de canal ou de fournisseur. +Les tests de contrat vérifient que chaque Plugin et canal enregistrés respectent leur +contrat d’interface. Ils itèrent sur tous les Plugins détectés et exécutent une suite d’assertions de forme et de comportement. La voie unitaire par défaut `pnpm test` ignore volontairement ces fichiers partagés de point d’extension et de smoke ; exécutez explicitement les commandes de contrat +lorsque vous touchez des surfaces partagées de canal ou de fournisseur. ### Commandes -- Tous les contrats : `pnpm test:contracts` -- Contrats de canaux uniquement : `pnpm test:contracts:channels` -- Contrats de fournisseurs uniquement : `pnpm test:contracts:plugins` +- Tous les contrats : `pnpm test:contracts` +- Contrats de canaux uniquement : `pnpm test:contracts:channels` +- Contrats de fournisseurs uniquement : `pnpm test:contracts:plugins` ### Contrats de canaux -Situés dans `src/channels/plugins/contracts/*.contract.test.ts` : +Situés dans `src/channels/plugins/contracts/*.contract.test.ts` : - **plugin** - Forme de base du Plugin (id, nom, capacités) - **setup** - Contrat de l’assistant de configuration -- **session-binding** - Comportement de liaison de session -- **outbound-payload** - Structure de charge utile des messages +- **session-binding** - Comportement d’association de session +- **outbound-payload** - Structure de la charge utile du message - **inbound** - Gestion des messages entrants -- **actions** - Gestionnaires d’actions du canal -- **threading** - Gestion de l’identifiant de fil -- **directory** - API de répertoire/liste des membres +- **actions** - Gestionnaires d’actions de canal +- **threading** - Gestion des identifiants de fil +- **directory** - API d’annuaire/de liste - **group-policy** - Application de la politique de groupe -### Contrats d’état des fournisseurs +### Contrats de statut des fournisseurs Situés dans `src/plugins/contracts/*.contract.test.ts`. -- **status** - Sondes d’état du canal +- **status** - Sondes de statut de canal - **registry** - Forme du registre de Plugins ### Contrats de fournisseurs -Situés dans `src/plugins/contracts/*.contract.test.ts` : +Situés dans `src/plugins/contracts/*.contract.test.ts` : - **auth** - Contrat du flux d’authentification - **auth-choice** - Choix/sélection d’authentification -- **catalog** - API du catalogue de modèles -- **discovery** - Découverte de Plugins -- **loader** - Chargement de Plugins +- **catalog** - API de catalogue de modèles +- **discovery** - Découverte des Plugins +- **loader** - Chargement des Plugins - **runtime** - Runtime du fournisseur - **shape** - Forme/interface du Plugin - **wizard** - Assistant de configuration ### Quand les exécuter -- Après avoir modifié des exportations ou sous-chemins de `plugin-sdk` +- Après avoir modifié les exportations ou sous-chemins de plugin-sdk - Après avoir ajouté ou modifié un Plugin de canal ou de fournisseur -- Après avoir refactorisé l’enregistrement ou la découverte de Plugins +- Après avoir refactorisé l’enregistrement ou la découverte des Plugins -Les tests de contrat s’exécutent en CI et ne nécessitent pas de vraies clés d’API. +Les tests de contrat s’exécutent dans la CI et ne nécessitent pas de vraies clés API. ## Ajouter des régressions (recommandations) -Lorsque vous corrigez un problème de fournisseur/modèle découvert en live : +Lorsque vous corrigez un problème de fournisseur/modèle découvert en live : -- Ajoutez si possible une régression compatible CI (fournisseur simulé/stub, ou capture exacte de la transformation de forme de requête) -- Si le problème est intrinsèquement limité au live (limites de débit, politiques d’authentification), gardez le test live étroit et opt-in via des variables d’environnement -- Préférez cibler la plus petite couche qui détecte le bug : +- Ajoutez si possible une régression sûre pour la CI (fournisseur simulé/factice, ou capture de la transformation exacte de la forme de requête) +- Si le problème est intrinsèquement propre au live (limitations de débit, politiques d’authentification), gardez le test live étroit et activable à la demande via des variables d’environnement +- Préférez cibler la couche la plus petite qui détecte le bug : - bug de conversion/rejeu de requête fournisseur → test direct des modèles - - bug du pipeline de session/historique/outils Gateway → test de fumée Gateway live ou test simulé Gateway compatible CI -- Garde-fou de parcours SecretRef : - - `src/secrets/exec-secret-ref-id-parity.test.ts` dérive une cible échantillonnée par classe SecretRef à partir des métadonnées du registre (`listSecretTargetRegistryEntries()`), puis vérifie que les identifiants exec de segment de parcours sont rejetés. - - Si vous ajoutez une nouvelle famille de cibles SecretRef `includeInPlan` dans `src/secrets/target-registry-data.ts`, mettez à jour `classifyTargetClass` dans ce test. Le test échoue volontairement sur les identifiants de cible non classés afin que de nouvelles classes ne puissent pas être ignorées silencieusement. + - bug de pipeline de session/historique/outils Gateway → smoke Gateway live ou test mock Gateway sûr pour la CI +- Garde-fou de traversée SecretRef : + - `src/secrets/exec-secret-ref-id-parity.test.ts` dérive une cible échantillonnée par classe SecretRef à partir des métadonnées du registre (`listSecretTargetRegistryEntries()`), puis vérifie que les identifiants exec de segment de traversée sont rejetés. + - Si vous ajoutez une nouvelle famille cible SecretRef `includeInPlan` dans `src/secrets/target-registry-data.ts`, mettez à jour `classifyTargetClass` dans ce test. Le test échoue volontairement sur les identifiants de cible non classés afin que les nouvelles classes ne puissent pas être ignorées silencieusement. diff --git a/docs/fr/help/troubleshooting.md b/docs/fr/help/troubleshooting.md index b5a277393..aa37841ea 100644 --- a/docs/fr/help/troubleshooting.md +++ b/docs/fr/help/troubleshooting.md @@ -1,14 +1,14 @@ --- read_when: - OpenClaw ne fonctionne pas et vous avez besoin du chemin le plus rapide vers une correction - - Vous voulez un flux de triage avant de vous plonger dans des guides détaillés -summary: Centre de dépannage d’OpenClaw orienté symptômes + - Vous voulez un flux de triage avant de vous plonger dans des runbooks détaillés +summary: Centre de dépannage orienté symptômes pour OpenClaw title: Dépannage général x-i18n: - generated_at: "2026-04-11T02:45:09Z" + generated_at: "2026-04-20T07:06:13Z" model: gpt-5.4 provider: openai - source_hash: 16b38920dbfdc8d4a79bbb5d6fab2c67c9f218a97c36bb4695310d7db9c4614a + source_hash: cc5d8c9f804084985c672c5a003ce866e8142ab99fe81abb7a0d38e22aea4b88 source_path: help/troubleshooting.md workflow: 15 --- @@ -17,9 +17,9 @@ x-i18n: Si vous n’avez que 2 minutes, utilisez cette page comme point d’entrée de triage. -## Les 60 premières secondes +## 60 premières secondes -Exécutez exactement cette séquence dans l’ordre : +Exécutez exactement cette séquence dans cet ordre : ```bash openclaw status @@ -35,41 +35,45 @@ Bon résultat en une ligne : - `openclaw status` → affiche les canaux configurés et aucune erreur d’authentification évidente. - `openclaw status --all` → le rapport complet est présent et partageable. -- `openclaw gateway probe` → la cible gateway attendue est accessible (`Reachable: yes`). `RPC: limited - missing scope: operator.read` indique des diagnostics dégradés, pas un échec de connexion. -- `openclaw gateway status` → `Runtime: running` et `RPC probe: ok`. +- `openclaw gateway probe` → la cible Gateway attendue est joignable (`Reachable: yes`). `Capability: ...` indique quel niveau d’authentification la sonde a pu prouver, et `Read probe: limited - missing scope: operator.read` correspond à un diagnostic dégradé, pas à un échec de connexion. +- `openclaw gateway status` → `Runtime: running`, `Connectivity probe: ok`, et une ligne `Capability: ...` plausible. Utilisez `--require-rpc` si vous avez aussi besoin d’une preuve RPC à portée lecture. - `openclaw doctor` → aucune erreur bloquante de configuration/service. -- `openclaw channels status --probe` → si le gateway est accessible, renvoie l’état de transport en direct par compte ainsi que les résultats de sonde/audit comme `works` ou `audit ok` ; si le gateway est inaccessible, la commande revient à des résumés basés uniquement sur la configuration. -- `openclaw logs --follow` → activité régulière, aucune erreur fatale répétée. +- `openclaw channels status --probe` → un gateway joignable renvoie l’état de transport en direct par compte + ainsi que les résultats des sondes/audits tels que `works` ou `audit ok` ; si le + gateway est inaccessible, la commande revient à des résumés basés uniquement sur la configuration. +- `openclaw logs --follow` → activité régulière, sans erreurs fatales répétées. -## 429 Anthropic sur contexte long +## 429 Anthropic sur un long contexte Si vous voyez : `HTTP 429: rate_limit_error: Extra usage is required for long context requests`, allez à [/gateway/troubleshooting#anthropic-429-extra-usage-required-for-long-context](/fr/gateway/troubleshooting#anthropic-429-extra-usage-required-for-long-context). -## Le backend local compatible OpenAI fonctionne directement mais échoue dans OpenClaw +## Le backend local compatible OpenAI fonctionne en direct mais échoue dans OpenClaw Si votre backend local ou auto-hébergé `/v1` répond à de petites sondes directes -`/v1/chat/completions` mais échoue sur `openclaw infer model run` ou sur des +`/v1/chat/completions` mais échoue avec `openclaw infer model run` ou pendant des tours d’agent normaux : -1. Si l’erreur mentionne `messages[].content` qui attend une chaîne, définissez +1. Si l’erreur mentionne que `messages[].content` attend une chaîne, définissez `models.providers..models[].compat.requiresStringContent: true`. -2. Si le backend échoue toujours uniquement sur les tours d’agent OpenClaw, définissez - `models.providers..models[].compat.supportsTools: false` et réessayez. -3. Si de minuscules appels directs fonctionnent toujours mais que des prompts OpenClaw plus volumineux font planter le backend, traitez le problème restant comme une limitation amont du modèle/serveur et poursuivez dans le guide détaillé : +2. Si le backend échoue toujours uniquement pendant les tours d’agent OpenClaw, définissez + `models.providers..models[].compat.supportsTools: false` puis réessayez. +3. Si de minuscules appels directs fonctionnent toujours mais que des prompts OpenClaw plus volumineux font planter le + backend, considérez le problème restant comme une limitation du modèle/serveur amont et + poursuivez dans le runbook détaillé : [/gateway/troubleshooting#local-openai-compatible-backend-passes-direct-probes-but-agent-runs-fail](/fr/gateway/troubleshooting#local-openai-compatible-backend-passes-direct-probes-but-agent-runs-fail) -## L’installation du plugin échoue avec des extensions openclaw manquantes +## L’installation du Plugin échoue avec des extensions openclaw manquantes -Si l’installation échoue avec `package.json missing openclaw.extensions`, le package du plugin -utilise une ancienne forme qu’OpenClaw n’accepte plus. +Si l’installation échoue avec `package.json missing openclaw.extensions`, le package du Plugin +utilise une ancienne structure qu’OpenClaw n’accepte plus. -Corrigez dans le package du plugin : +Correction dans le package du Plugin : 1. Ajoutez `openclaw.extensions` à `package.json`. -2. Faites pointer les entrées vers les fichiers runtime compilés (généralement `./dist/index.js`). -3. Republiez le plugin et exécutez de nouveau `openclaw plugins install `. +2. Faites pointer les entrées vers les fichiers d’exécution compilés (généralement `./dist/index.js`). +3. Republiez le Plugin et exécutez à nouveau `openclaw plugins install `. Exemple : @@ -91,20 +95,20 @@ Référence : [Architecture des plugins](/fr/plugins/architecture) flowchart TD A[OpenClaw ne fonctionne pas] --> B{Qu’est-ce qui casse en premier} B --> C[Pas de réponses] - B --> D[Le tableau de bord ou la Control UI ne se connecte pas] - B --> E[Le Gateway ne démarre pas ou le service ne fonctionne pas] + B --> D[Le tableau de bord ou l’interface utilisateur de contrôle ne se connecte pas] + B --> E[Le Gateway ne démarre pas ou le service n’est pas en cours d’exécution] B --> F[Le canal se connecte mais les messages ne circulent pas] - B --> G[Cron ou heartbeat ne s’est pas déclenché ou n’a rien livré] - B --> H[Le nœud est appairé mais l’exécution screen exec du canvas caméra échoue] - B --> I[L’outil navigateur échoue] + B --> G[Cron ou Heartbeat ne s’est pas déclenché ou n’a pas livré] + B --> H[Le Node est appairé mais l’exécution camera canvas screen échoue] + B --> I[L’outil browser échoue] C --> C1[/Section Pas de réponses/] - D --> D1[/Section Control UI/] + D --> D1[/Section Interface utilisateur de contrôle/] E --> E1[/Section Gateway/] - F --> F1[/Section Flux du canal/] + F --> F1[/Section Flux des canaux/] G --> G1[/Section Automatisation/] - H --> H1[/Section Outils du nœud/] - I --> I1[/Section Navigateur/] + H --> H1[/Section Outils Node/] + I --> I1[/Section Browser/] ``` @@ -120,15 +124,16 @@ flowchart TD Un bon résultat ressemble à ceci : - `Runtime: running` - - `RPC probe: ok` - - Votre canal affiche un transport connecté et, là où c’est pris en charge, `works` ou `audit ok` dans `channels status --probe` - - L’expéditeur apparaît comme approuvé (ou la politique de DM est ouverte / en allowlist) + - `Connectivity probe: ok` + - `Capability: read-only`, `write-capable`, ou `admin-capable` + - Votre canal affiche le transport connecté et, lorsque c’est pris en charge, `works` ou `audit ok` dans `channels status --probe` + - L’expéditeur apparaît comme approuvé (ou la politique DM est ouverte/avec liste d’autorisation) - Signatures de logs courantes : + Signatures de journaux courantes : - - `drop guild message (mention required` → le filtrage par mention a bloqué le message dans Discord. - - `pairing request` → l’expéditeur n’est pas approuvé et attend l’approbation de l’appairage DM. - - `blocked` / `allowlist` dans les logs du canal → l’expéditeur, le salon ou le groupe est filtré. + - `drop guild message (mention required` → la contrainte de mention a bloqué le message dans Discord. + - `pairing request` → l’expéditeur n’est pas approuvé et attend une approbation d’appairage DM. + - `blocked` / `allowlist` dans les journaux du canal → l’expéditeur, le salon ou le groupe est filtré. Pages détaillées : @@ -138,7 +143,7 @@ flowchart TD - + ```bash openclaw status openclaw gateway status @@ -150,19 +155,26 @@ flowchart TD Un bon résultat ressemble à ceci : - `Dashboard: http://...` est affiché dans `openclaw gateway status` - - `RPC probe: ok` - - Aucune boucle d’authentification dans les logs + - `Connectivity probe: ok` + - `Capability: read-only`, `write-capable`, ou `admin-capable` + - Aucune boucle d’authentification dans les journaux - Signatures de logs courantes : + Signatures de journaux courantes : - - `device identity required` → le contexte HTTP / non sécurisé ne peut pas terminer l’authentification de l’appareil. - - `origin not allowed` → l’`Origin` du navigateur n’est pas autorisé pour la cible gateway de la Control UI. - - `AUTH_TOKEN_MISMATCH` avec des indications de nouvelle tentative (`canRetryWithDeviceToken=true`) → une nouvelle tentative avec un device token approuvé peut avoir lieu automatiquement. - - Cette nouvelle tentative avec token en cache réutilise l’ensemble de scopes mis en cache, stocké avec le device token appairé. Les appelants `deviceToken` explicites / `scopes` explicites conservent à la place l’ensemble de scopes demandé. - - Sur le chemin async Tailscale Serve de la Control UI, les tentatives échouées pour le même `{scope, ip}` sont sérialisées avant que le limiteur n’enregistre l’échec, donc une deuxième mauvaise tentative concurrente peut déjà afficher `retry later`. - - `too many failed authentication attempts (retry later)` depuis une origine de navigateur localhost → les échecs répétés depuis cette même `Origin` sont temporairement bloqués ; une autre origine localhost utilise un compartiment distinct. - - `unauthorized` répété après cette nouvelle tentative → mauvais token/mot de passe, incompatibilité de mode d’authentification ou device token appairé obsolète. - - `gateway connect failed:` → l’UI cible la mauvaise URL/le mauvais port ou un gateway inaccessible. + - `device identity required` → le contexte HTTP/non sécurisé ne peut pas terminer l’authentification de l’appareil. + - `origin not allowed` → l’`Origin` du navigateur n’est pas autorisé pour la + cible Gateway de l’interface utilisateur de contrôle. + - `AUTH_TOKEN_MISMATCH` avec des indications de nouvelle tentative (`canRetryWithDeviceToken=true`) → une nouvelle tentative avec un device token de confiance peut se produire automatiquement. + - Cette nouvelle tentative avec jeton en cache réutilise l’ensemble des portées en cache stocké avec le + device token appairé. Les appelants avec `deviceToken` explicite / `scopes` explicites conservent + plutôt l’ensemble de portées demandé. + - Sur le chemin asynchrone de l’interface utilisateur de contrôle Tailscale Serve, les tentatives échouées pour le même + `{scope, ip}` sont sérialisées avant que le limiteur n’enregistre l’échec ; ainsi, une + deuxième mauvaise tentative concurrente peut déjà afficher `retry later`. + - `too many failed authentication attempts (retry later)` depuis une origine de navigateur localhost + → des échecs répétés depuis cette même `Origin` sont temporairement bloqués ; une autre origine localhost utilise un compartiment distinct. + - `repeated unauthorized` après cette nouvelle tentative → mauvais token/mot de passe, incompatibilité de mode d’authentification ou device token appairé obsolète. + - `gateway connect failed:` → l’interface cible la mauvaise URL/le mauvais port ou un gateway inaccessible. Pages détaillées : @@ -172,7 +184,7 @@ flowchart TD - + ```bash openclaw status openclaw gateway status @@ -185,13 +197,14 @@ flowchart TD - `Service: ... (loaded)` - `Runtime: running` - - `RPC probe: ok` + - `Connectivity probe: ok` + - `Capability: read-only`, `write-capable`, ou `admin-capable` - Signatures de logs courantes : + Signatures de journaux courantes : - - `Gateway start blocked: set gateway.mode=local` ou `existing config is missing gateway.mode` → le mode gateway est distant, ou le fichier de configuration n’a pas l’indication de mode local et doit être réparé. - - `refusing to bind gateway ... without auth` → liaison hors loopback sans chemin d’authentification gateway valide (token/mot de passe, ou trusted-proxy si configuré). - - `another gateway instance is already listening` ou `EADDRINUSE` → le port est déjà pris. + - `Gateway start blocked: set gateway.mode=local` ou `existing config is missing gateway.mode` → le mode gateway est distant, ou il manque le tampon de mode local dans le fichier de configuration et celui-ci doit être réparé. + - `refusing to bind gateway ... without auth` → liaison non-loopback sans chemin d’authentification gateway valide (token/mot de passe, ou trusted-proxy lorsque configuré). + - `another gateway instance is already listening` ou `EADDRINUSE` → port déjà utilisé. Pages détaillées : @@ -213,14 +226,14 @@ flowchart TD Un bon résultat ressemble à ceci : - Le transport du canal est connecté. - - Les vérifications d’appairage / d’allowlist réussissent. - - Les mentions sont détectées lorsque nécessaire. + - Les vérifications d’appairage/liste d’autorisation réussissent. + - Les mentions sont détectées lorsque requis. - Signatures de logs courantes : + Signatures de journaux courantes : - - `mention required` → le filtrage par mention dans le groupe a bloqué le traitement. + - `mention required` → la contrainte de mention de groupe a bloqué le traitement. - `pairing` / `pending` → l’expéditeur du DM n’est pas encore approuvé. - - `not_in_channel`, `missing_scope`, `Forbidden`, `401/403` → problème de permissions du canal ou du token. + - `not_in_channel`, `missing_scope`, `Forbidden`, `401/403` → problème de jeton d’autorisation du canal. Pages détaillées : @@ -229,7 +242,7 @@ flowchart TD - + ```bash openclaw status openclaw gateway status @@ -241,19 +254,19 @@ flowchart TD Un bon résultat ressemble à ceci : - - `cron.status` indique qu’il est activé avec un prochain réveil. - - `cron runs` montre des entrées récentes `ok`. - - Heartbeat est activé et n’est pas en dehors des heures actives. + - `cron.status` indique activé avec un prochain réveil. + - `cron runs` affiche des entrées récentes `ok`. + - Heartbeat est activé et n’est pas hors des heures actives. - Signatures de logs courantes : + Signatures de journaux courantes : - - `cron: scheduler disabled; jobs will not run automatically` → cron est désactivé. + - `cron: scheduler disabled; jobs will not run automatically` → Cron est désactivé. - `heartbeat skipped` avec `reason=quiet-hours` → en dehors des heures actives configurées. - - `heartbeat skipped` avec `reason=empty-heartbeat-file` → `HEARTBEAT.md` existe mais ne contient qu’une structure vide ou uniquement des en-têtes. + - `heartbeat skipped` avec `reason=empty-heartbeat-file` → `HEARTBEAT.md` existe mais ne contient qu’une structure vide/ou seulement des en-têtes. - `heartbeat skipped` avec `reason=no-tasks-due` → le mode tâche de `HEARTBEAT.md` est actif mais aucun intervalle de tâche n’est encore arrivé à échéance. - - `heartbeat skipped` avec `reason=alerts-disabled` → toute la visibilité heartbeat est désactivée (`showOk`, `showAlerts` et `useIndicator` sont tous désactivés). - - `requests-in-flight` → la voie principale est occupée ; le réveil heartbeat a été différé. - - `unknown accountId` → le compte cible de livraison heartbeat n’existe pas. + - `heartbeat skipped` avec `reason=alerts-disabled` → toute la visibilité Heartbeat est désactivée (`showOk`, `showAlerts` et `useIndicator` sont tous désactivés). + - `requests-in-flight` → voie principale occupée ; le réveil Heartbeat a été différé. + - `unknown accountId` → le compte cible de livraison Heartbeat n’existe pas. Pages détaillées : @@ -263,7 +276,7 @@ flowchart TD - + ```bash openclaw status openclaw gateway status @@ -274,16 +287,16 @@ flowchart TD Un bon résultat ressemble à ceci : - - Le nœud apparaît comme connecté et appairé pour le rôle `node`. + - Le Node est répertorié comme connecté et appairé pour le rôle `node`. - La capacité existe pour la commande que vous invoquez. - - L’état de permission est accordé pour l’outil. + - L’état d’autorisation est accordé pour l’outil. - Signatures de logs courantes : + Signatures de journaux courantes : - - `NODE_BACKGROUND_UNAVAILABLE` → amenez l’application du nœud au premier plan. - - `*_PERMISSION_REQUIRED` → la permission du système d’exploitation a été refusée ou est manquante. + - `NODE_BACKGROUND_UNAVAILABLE` → faites passer l’application node au premier plan. + - `*_PERMISSION_REQUIRED` → l’autorisation OS a été refusée/manque. - `SYSTEM_RUN_DENIED: approval required` → l’approbation d’exécution est en attente. - - `SYSTEM_RUN_DENIED: allowlist miss` → la commande n’est pas dans l’allowlist d’exécution. + - `SYSTEM_RUN_DENIED: allowlist miss` → la commande n’est pas dans la liste d’autorisation d’exécution. Pages détaillées : @@ -304,11 +317,11 @@ flowchart TD Ce qui a changé : - Si `tools.exec.host` n’est pas défini, la valeur par défaut est `auto`. - - `host=auto` se résout en `sandbox` lorsqu’un runtime sandbox est actif, sinon en `gateway`. - - `host=auto` ne gère que le routage ; le comportement sans invite « YOLO » vient de `security=full` plus `ask=off` sur gateway/node. - - Sur `gateway` et `node`, si `tools.exec.security` n’est pas défini, la valeur par défaut est `full`. - - Si `tools.exec.ask` n’est pas défini, la valeur par défaut est `off`. - - Résultat : si vous voyez des approbations, une politique locale à l’hôte ou propre à la session a renforcé exec par rapport aux valeurs par défaut actuelles. + - `host=auto` se résout vers `sandbox` lorsqu’un environnement d’exécution sandbox est actif, sinon vers `gateway`. + - `host=auto` ne concerne que le routage ; le comportement sans invite « YOLO » vient de `security=full` plus `ask=off` sur gateway/node. + - Sur `gateway` et `node`, `tools.exec.security` non défini vaut par défaut `full`. + - `tools.exec.ask` non défini vaut par défaut `off`. + - Résultat : si vous voyez des demandes d’approbation, une politique locale à l’hôte ou propre à la session a durci exec par rapport aux valeurs par défaut actuelles. Restaurer le comportement actuel par défaut sans approbation : @@ -321,15 +334,15 @@ flowchart TD Alternatives plus sûres : - - Définissez uniquement `tools.exec.host=gateway` si vous voulez seulement un routage hôte stable. - - Utilisez `security=allowlist` avec `ask=on-miss` si vous voulez l’exécution sur l’hôte tout en conservant une revue lors des absences dans l’allowlist. + - Définissez uniquement `tools.exec.host=gateway` si vous voulez simplement un routage hôte stable. + - Utilisez `security=allowlist` avec `ask=on-miss` si vous voulez l’exécution sur l’hôte tout en conservant une revue en cas d’absence dans la liste d’autorisation. - Activez le mode sandbox si vous voulez que `host=auto` se résolve de nouveau vers `sandbox`. - Signatures de logs courantes : + Signatures de journaux courantes : - `Approval required.` → la commande attend `/approve ...`. - - `SYSTEM_RUN_DENIED: approval required` → l’approbation de l’exécution exec sur l’hôte du nœud est en attente. - - `exec host=sandbox requires a sandbox runtime for this session` → sélection implicite/explicite du sandbox alors que le mode sandbox est désactivé. + - `SYSTEM_RUN_DENIED: approval required` → l’approbation de l’exécution sur l’hôte node est en attente. + - `exec host=sandbox requires a sandbox runtime for this session` → sélection sandbox implicite/explicite alors que le mode sandbox est désactivé. Pages détaillées : @@ -339,7 +352,7 @@ flowchart TD - + ```bash openclaw status openclaw gateway status @@ -350,10 +363,10 @@ flowchart TD Un bon résultat ressemble à ceci : - - L’état du navigateur affiche `running: true` et un navigateur/profil choisi. + - L’état du browser affiche `running: true` ainsi qu’un navigateur/profil sélectionné. - `openclaw` démarre, ou `user` peut voir les onglets Chrome locaux. - Signatures de logs courantes : + Signatures de journaux courantes : - `unknown command "browser"` ou `unknown command 'browser'` → `plugins.allow` est défini et n’inclut pas `browser`. - `Failed to start Chrome CDP on port` → le lancement du navigateur local a échoué. @@ -361,9 +374,9 @@ flowchart TD - `browser.cdpUrl must be http(s) or ws(s)` → l’URL CDP configurée utilise un schéma non pris en charge. - `browser.cdpUrl has invalid port` → l’URL CDP configurée a un port incorrect ou hors plage. - `No Chrome tabs found for profile="user"` → le profil d’attachement Chrome MCP n’a aucun onglet Chrome local ouvert. - - `Remote CDP for profile "" is not reachable` → l’endpoint CDP distant configuré n’est pas accessible depuis cet hôte. - - `Browser attachOnly is enabled ... not reachable` ou `Browser attachOnly is enabled and CDP websocket ... is not reachable` → le profil attach-only n’a pas de cible CDP active. - - remplacements obsolètes de viewport / mode sombre / langue / hors ligne sur des profils attach-only ou CDP distants → exécutez `openclaw browser stop --browser-profile ` pour fermer la session de contrôle active et libérer l’état d’émulation sans redémarrer le gateway. + - `Remote CDP for profile "" is not reachable` → l’endpoint CDP distant configuré n’est pas joignable depuis cet hôte. + - `Browser attachOnly is enabled ... not reachable` ou `Browser attachOnly is enabled and CDP websocket ... is not reachable` → le profil attach-only n’a aucune cible CDP active. + - remplacements obsolètes de viewport / mode sombre / paramètres régionaux / hors ligne sur les profils attach-only ou CDP distants → exécutez `openclaw browser stop --browser-profile ` pour fermer la session de contrôle active et libérer l’état d’émulation sans redémarrer le gateway. Pages détaillées : @@ -376,10 +389,10 @@ flowchart TD -## Liens associés +## Associé - [FAQ](/fr/help/faq) — questions fréquemment posées -- [Dépannage du Gateway](/fr/gateway/troubleshooting) — problèmes spécifiques au gateway -- [Doctor](/fr/gateway/doctor) — vérifications automatiques de l’état et réparations +- [Dépannage Gateway](/fr/gateway/troubleshooting) — problèmes spécifiques au Gateway +- [Doctor](/fr/gateway/doctor) — vérifications automatiques de l’état de santé et réparations - [Dépannage des canaux](/fr/channels/troubleshooting) — problèmes de connectivité des canaux -- [Dépannage de l’automatisation](/fr/automation/cron-jobs#troubleshooting) — problèmes de cron et heartbeat +- [Dépannage de l’automatisation](/fr/automation/cron-jobs#troubleshooting) — problèmes de Cron et Heartbeat diff --git a/docs/fr/tools/browser.md b/docs/fr/tools/browser.md index 383ecc146..4a03e866a 100644 --- a/docs/fr/tools/browser.md +++ b/docs/fr/tools/browser.md @@ -1,15 +1,15 @@ --- read_when: - Ajout de l’automatisation du navigateur contrôlée par l’agent - - Déboguer pourquoi openclaw interfère avec votre propre Chrome - - Implémentation des paramètres du navigateur + du cycle de vie dans l’app macOS -summary: Service de contrôle de navigateur intégré + commandes d’action + - Débogage pour comprendre pourquoi openclaw interfère avec votre propre Chrome + - Implémentation des paramètres et du cycle de vie du navigateur dans l’app macOS +summary: Service de contrôle intégré du navigateur + commandes d’action title: Navigateur (géré par OpenClaw) x-i18n: - generated_at: "2026-04-14T13:04:20Z" + generated_at: "2026-04-20T07:06:21Z" model: gpt-5.4 provider: openai - source_hash: ae9ef725f544d4236d229f498c7187871c69bd18d31069b30a7e67fac53166a2 + source_hash: 3f7d37b34ba48dc7c38f8c2e77f8bb97af987eac6a874ebfc921f950fb59de4b source_path: tools/browser.md workflow: 15 --- @@ -17,24 +17,24 @@ x-i18n: # Navigateur (géré par openclaw) OpenClaw peut exécuter un **profil Chrome/Brave/Edge/Chromium dédié** que l’agent contrôle. -Il est isolé de votre navigateur personnel et géré via un petit -service de contrôle local à l’intérieur du Gateway (loopback uniquement). +Il est isolé de votre navigateur personnel et géré via un petit service local de +contrôle à l’intérieur de Gateway (loopback uniquement). Vue débutant : -- Voyez-le comme un **navigateur séparé, réservé à l’agent**. -- Le profil `openclaw` ne **modifie pas** le profil de votre navigateur personnel. -- L’agent peut **ouvrir des onglets, lire des pages, cliquer et saisir du texte** dans un environnement sûr. -- Le profil intégré `user` se rattache à votre vraie session Chrome connectée via Chrome MCP. +- Considérez-le comme un **navigateur distinct, réservé à l’agent**. +- Le profil `openclaw` ne **touche pas** au profil de votre navigateur personnel. +- L’agent peut **ouvrir des onglets, lire des pages, cliquer et saisir du texte** dans une voie sûre. +- Le profil intégré `user` se rattache à votre véritable session Chrome connectée via Chrome MCP. ## Ce que vous obtenez - Un profil de navigateur distinct nommé **openclaw** (accent orange par défaut). - Un contrôle déterministe des onglets (lister/ouvrir/focaliser/fermer). -- Actions de l’agent (cliquer/saisir/faire glisser/sélectionner), instantanés, captures d’écran, PDF. +- Actions de l’agent (cliquer/saisir/glisser/sélectionner), instantanés, captures d’écran, PDF. - Prise en charge facultative de plusieurs profils (`openclaw`, `work`, `remote`, ...). -Ce navigateur n’est **pas** votre navigateur quotidien. C’est une surface sûre et isolée pour +Ce navigateur **n’est pas** votre navigateur principal au quotidien. C’est une surface sûre et isolée pour l’automatisation et la vérification par l’agent. ## Démarrage rapide @@ -46,17 +46,17 @@ openclaw browser --browser-profile openclaw open https://example.com openclaw browser --browser-profile openclaw snapshot ``` -Si vous obtenez « Browser disabled », activez-le dans la config (voir ci-dessous) et redémarrez le +Si vous obtenez « Browser disabled », activez-le dans la configuration (voir ci-dessous) puis redémarrez Gateway. Si `openclaw browser` est totalement absent, ou si l’agent indique que l’outil de navigateur -est indisponible, allez à [Commande ou outil navigateur manquant](/fr/tools/browser#missing-browser-command-or-tool). +n’est pas disponible, passez à [Commande ou outil navigateur manquant](/fr/tools/browser#missing-browser-command-or-tool). ## Contrôle du Plugin -L’outil `browser` par défaut est maintenant un Plugin intégré livré activé par -défaut. Cela signifie que vous pouvez le désactiver ou le remplacer sans supprimer le reste du -système de plugins d’OpenClaw : +L’outil `browser` par défaut est maintenant un Plugin groupé livré activé par +défaut. Cela signifie que vous pouvez le désactiver ou le remplacer sans retirer le reste du +système de Plugin d’OpenClaw : ```json5 { @@ -70,24 +70,24 @@ système de plugins d’OpenClaw : } ``` -Désactivez le Plugin intégré avant d’installer un autre Plugin qui fournit le +Désactivez le Plugin groupé avant d’installer un autre Plugin qui fournit le même nom d’outil `browser`. L’expérience de navigateur par défaut nécessite les deux éléments suivants : - `plugins.entries.browser.enabled` non désactivé - `browser.enabled=true` -Si vous désactivez uniquement le Plugin, la CLI de navigateur intégrée (`openclaw browser`), -la méthode gateway (`browser.request`), l’outil agent et le service de contrôle de navigateur par défaut -disparaissent tous ensemble. Votre config `browser.*` reste intacte pour qu’un -Plugin de remplacement puisse la réutiliser. +Si vous désactivez uniquement le Plugin, la CLI de navigateur groupée (`openclaw browser`), +la méthode Gateway (`browser.request`), l’outil de l’agent et le service de contrôle +du navigateur par défaut disparaissent tous ensemble. Votre configuration `browser.*` reste intacte pour +qu’un Plugin de remplacement puisse la réutiliser. -Le Plugin de navigateur intégré possède maintenant aussi l’implémentation d’exécution du navigateur. -Le cœur ne conserve que les assistants partagés du Plugin SDK ainsi que des réexportations de compatibilité pour -les anciens chemins d’import internes. En pratique, supprimer ou remplacer le package du Plugin navigateur -supprime l’ensemble des fonctionnalités du navigateur au lieu de laisser derrière lui une seconde -implémentation d’exécution gérée par le cœur. +Le Plugin de navigateur groupé est aussi désormais propriétaire de l’implémentation d’exécution du navigateur. +Le cœur ne conserve que les helpers partagés du Plugin SDK ainsi que des réexportations de compatibilité pour +les anciens chemins d’import internes. En pratique, retirer ou remplacer le package du Plugin de navigateur +supprime l’ensemble des fonctionnalités navigateur au lieu de laisser derrière lui une seconde exécution +gérée par le cœur. -Les changements de configuration du navigateur nécessitent toujours un redémarrage du Gateway afin que le Plugin intégré +Les changements de configuration du navigateur nécessitent toujours un redémarrage de Gateway afin que le Plugin groupé puisse réenregistrer son service de navigateur avec les nouveaux paramètres. ## Commande ou outil navigateur manquant @@ -96,7 +96,7 @@ Si `openclaw browser` devient soudainement une commande inconnue après une mise si l’agent signale que l’outil navigateur est manquant, la cause la plus fréquente est une liste `plugins.allow` restrictive qui n’inclut pas `browser`. -Exemple de configuration défaillante : +Exemple de configuration cassée : ```json5 { @@ -116,12 +116,12 @@ Corrigez-la en ajoutant `browser` à la liste d’autorisation des plugins : } ``` -Remarques importantes : +Notes importantes : - `browser.enabled=true` ne suffit pas à lui seul lorsque `plugins.allow` est défini. - `plugins.entries.browser.enabled=true` ne suffit pas non plus à lui seul lorsque `plugins.allow` est défini. -- `tools.alsoAllow: ["browser"]` ne charge **pas** le Plugin navigateur intégré. Cela ajuste seulement la politique des outils une fois le Plugin déjà chargé. -- Si vous n’avez pas besoin d’une liste d’autorisation de plugins restrictive, supprimer `plugins.allow` rétablit également le comportement par défaut du navigateur intégré. +- `tools.alsoAllow: ["browser"]` ne charge **pas** le Plugin de navigateur groupé. Cela ajuste seulement la politique des outils une fois le Plugin déjà chargé. +- Si vous n’avez pas besoin d’une liste d’autorisation de plugins restrictive, supprimer `plugins.allow` rétablit aussi le comportement groupé par défaut du navigateur. Symptômes typiques : @@ -132,14 +132,14 @@ Symptômes typiques : ## Profils : `openclaw` vs `user` - `openclaw` : navigateur géré et isolé (aucune extension requise). -- `user` : profil intégré de rattachement Chrome MCP à votre **vraie session Chrome connectée**. +- `user` : profil intégré de rattachement Chrome MCP pour votre **véritable session Chrome connectée**. -Pour les appels d’outil navigateur de l’agent : +Pour les appels à l’outil navigateur de l’agent : -- Par défaut : utiliser le navigateur isolé `openclaw`. -- Préférez `profile="user"` lorsque des sessions déjà connectées importent et que l’utilisateur - est devant l’ordinateur pour cliquer/approuver toute invite de rattachement. -- `profile` est la surcharge explicite lorsque vous voulez un mode de navigateur spécifique. +- Par défaut : utilisez le navigateur isolé `openclaw`. +- Préférez `profile="user"` lorsque les sessions déjà connectées sont importantes et que l’utilisateur + est à l’ordinateur pour cliquer/approuver toute invite de rattachement. +- `profile` est la dérogation explicite lorsque vous souhaitez un mode de navigateur précis. Définissez `browser.defaultProfile: "openclaw"` si vous voulez le mode géré par défaut. @@ -150,16 +150,16 @@ Les paramètres du navigateur se trouvent dans `~/.openclaw/openclaw.json`. ```json5 { browser: { - enabled: true, // défaut : true + enabled: true, // default: true ssrfPolicy: { - // dangerouslyAllowPrivateNetwork: true, // activez uniquement pour un accès réseau privé de confiance - // allowPrivateNetwork: true, // alias historique + // dangerouslyAllowPrivateNetwork: true, // opt in only for trusted private-network access + // allowPrivateNetwork: true, // legacy alias // hostnameAllowlist: ["*.example.com", "example.com"], // allowedHostnames: ["localhost"], }, - // cdpUrl: "http://127.0.0.1:18792", // surcharge historique à profil unique - remoteCdpTimeoutMs: 1500, // délai d’expiration HTTP CDP distant (ms) - remoteCdpHandshakeTimeoutMs: 3000, // délai d’expiration de la poignée de main WebSocket CDP distante (ms) + // cdpUrl: "http://127.0.0.1:18792", // legacy single-profile override + remoteCdpTimeoutMs: 1500, // remote CDP HTTP timeout (ms) + remoteCdpHandshakeTimeoutMs: 3000, // remote CDP WebSocket handshake timeout (ms) defaultProfile: "openclaw", color: "#FF4500", headless: false, @@ -186,33 +186,33 @@ Les paramètres du navigateur se trouvent dans `~/.openclaw/openclaw.json`. } ``` -Remarques : +Notes : -- Le service de contrôle du navigateur se lie au loopback sur un port dérivé de `gateway.port` +- Le service de contrôle du navigateur se lie à loopback sur un port dérivé de `gateway.port` (par défaut : `18791`, soit gateway + 2). -- Si vous surchargez le port du Gateway (`gateway.port` ou `OPENCLAW_GATEWAY_PORT`), - les ports du navigateur dérivés se décalent pour rester dans la même « famille ». +- Si vous redéfinissez le port Gateway (`gateway.port` ou `OPENCLAW_GATEWAY_PORT`), + les ports de navigateur dérivés se décalent pour rester dans la même « famille ». - `cdpUrl` utilise par défaut le port CDP local géré lorsqu’il n’est pas défini. -- `remoteCdpTimeoutMs` s’applique aux vérifications d’accessibilité CDP distantes (hors loopback). -- `remoteCdpHandshakeTimeoutMs` s’applique aux vérifications d’accessibilité WebSocket CDP distantes. -- La navigation/ouverture d’onglet du navigateur est protégée contre la SSRF avant la navigation et revérifiée au mieux sur l’URL finale `http(s)` après navigation. -- En mode SSRF strict, la découverte/les sondes de points de terminaison CDP distants (`cdpUrl`, y compris les recherches `/json/version`) sont également vérifiées. -- `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork` est désactivé par défaut. Définissez-le sur `true` uniquement lorsque vous faites intentionnellement confiance à l’accès navigateur au réseau privé. -- `browser.ssrfPolicy.allowPrivateNetwork` reste pris en charge comme alias historique pour compatibilité. -- `attachOnly: true` signifie « ne jamais lancer un navigateur local ; se rattacher uniquement s’il est déjà en cours d’exécution ». -- `color` + `color` par profil teintent l’interface du navigateur afin que vous puissiez voir quel profil est actif. -- Le profil par défaut est `openclaw` (navigateur autonome géré par OpenClaw). Utilisez `defaultProfile: "user"` pour opter pour le navigateur utilisateur connecté. +- `remoteCdpTimeoutMs` s’applique aux vérifications de joignabilité CDP distantes (hors loopback). +- `remoteCdpHandshakeTimeoutMs` s’applique aux vérifications de joignabilité de handshake WebSocket CDP distantes. +- La navigation du navigateur et l’ouverture d’onglet sont protégées contre la SSRF avant la navigation et revérifiées au mieux sur l’URL finale `http(s)` après navigation. +- En mode SSRF strict, la découverte et les sondes des points de terminaison CDP distants (`cdpUrl`, y compris les recherches `/json/version`) sont aussi vérifiées. +- `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork` est désactivé par défaut. Définissez-le sur `true` uniquement lorsque vous faites délibérément confiance à l’accès navigateur sur réseau privé. +- `browser.ssrfPolicy.allowPrivateNetwork` reste pris en charge comme alias hérité pour compatibilité. +- `attachOnly: true` signifie « ne jamais lancer un navigateur local ; s’y rattacher uniquement s’il est déjà en cours d’exécution ». +- `color` + la `color` par profil teintent l’interface du navigateur afin que vous puissiez voir quel profil est actif. +- Le profil par défaut est `openclaw` (navigateur autonome géré par OpenClaw). Utilisez `defaultProfile: "user"` pour choisir le navigateur connecté de l’utilisateur. - Ordre d’auto-détection : navigateur système par défaut s’il est basé sur Chromium ; sinon Chrome → Brave → Edge → Chromium → Chrome Canary. -- Les profils `openclaw` locaux assignent automatiquement `cdpPort`/`cdpUrl` — définissez-les uniquement pour le CDP distant. -- `driver: "existing-session"` utilise Chrome DevTools MCP au lieu du CDP brut. Ne +- Les profils `openclaw` locaux attribuent automatiquement `cdpPort`/`cdpUrl` — définissez-les uniquement pour CDP distant. +- `driver: "existing-session"` utilise Chrome DevTools MCP au lieu de CDP brut. Ne définissez pas `cdpUrl` pour ce driver. - Définissez `browser.profiles..userDataDir` lorsqu’un profil existing-session - doit se rattacher à un profil utilisateur Chromium non par défaut comme Brave ou Edge. + doit se rattacher à un profil utilisateur Chromium non par défaut, comme Brave ou Edge. ## Utiliser Brave (ou un autre navigateur basé sur Chromium) -Si votre navigateur **par défaut du système** est basé sur Chromium (Chrome/Brave/Edge/etc), -OpenClaw l’utilise automatiquement. Définissez `browser.executablePath` pour surcharger +Si votre navigateur **système par défaut** est basé sur Chromium (Chrome/Brave/Edge/etc), +OpenClaw l’utilise automatiquement. Définissez `browser.executablePath` pour redéfinir l’auto-détection : Exemple CLI : @@ -246,51 +246,51 @@ openclaw config set browser.executablePath "/usr/bin/google-chrome" ## Contrôle local vs distant -- **Contrôle local (par défaut) :** le Gateway démarre le service de contrôle loopback et peut lancer un navigateur local. -- **Contrôle distant (hôte node) :** exécutez un hôte node sur la machine qui possède le navigateur ; le Gateway y relaie les actions du navigateur. +- **Contrôle local (par défaut) :** Gateway démarre le service de contrôle loopback et peut lancer un navigateur local. +- **Contrôle distant (hôte node) :** exécutez un hôte node sur la machine qui possède le navigateur ; Gateway y relaie les actions du navigateur. - **CDP distant :** définissez `browser.profiles..cdpUrl` (ou `browser.cdpUrl`) pour vous rattacher à un navigateur distant basé sur Chromium. Dans ce cas, OpenClaw ne lancera pas de navigateur local. -Le comportement à l’arrêt diffère selon le mode du profil : +Le comportement d’arrêt diffère selon le mode du profil : - profils gérés locaux : `openclaw browser stop` arrête le processus de navigateur que OpenClaw a lancé -- profils attach-only et CDP distants : `openclaw browser stop` ferme la session de contrôle - active et libère les surcharges d’émulation Playwright/CDP (viewport, - schéma de couleurs, langue, fuseau horaire, mode hors ligne et état similaire), même +- profils attach-only et CDP distants : `openclaw browser stop` ferme la session de + contrôle active et libère les dérogations d’émulation Playwright/CDP (viewport, + schéma de couleurs, locale, fuseau horaire, mode hors ligne et états similaires), même si aucun processus de navigateur n’a été lancé par OpenClaw Les URL CDP distantes peuvent inclure une authentification : -- Jetons de requête (par ex., `https://provider.example?token=`) -- Auth HTTP Basic (par ex., `https://user:pass@provider.example`) +- Jetons de requête (par ex. `https://provider.example?token=`) +- Authentification HTTP Basic (par ex. `https://user:pass@provider.example`) OpenClaw préserve l’authentification lors des appels aux points de terminaison `/json/*` et lors de la connexion au WebSocket CDP. Préférez les variables d’environnement ou les gestionnaires de secrets pour les -jetons plutôt que de les valider dans des fichiers de configuration. +jetons au lieu de les versionner dans les fichiers de configuration. -## Proxy navigateur node (par défaut sans configuration) +## Proxy de navigateur node (valeur par défaut sans configuration) Si vous exécutez un **hôte node** sur la machine qui possède votre navigateur, OpenClaw peut -acheminer automatiquement les appels d’outil navigateur vers ce node sans configuration de navigateur supplémentaire. -C’est le chemin par défaut pour les gateways distants. +rediriger automatiquement les appels à l’outil navigateur vers ce node sans configuration de navigateur supplémentaire. +C’est le chemin par défaut pour les Gateway distants. -Remarques : +Notes : - L’hôte node expose son serveur local de contrôle du navigateur via une **commande proxy**. -- Les profils proviennent de la propre config `browser.profiles` du node (identique au mode local). -- `nodeHost.browserProxy.allowProfiles` est facultatif. Laissez-le vide pour le comportement historique/par défaut : tous les profils configurés restent accessibles via le proxy, y compris les routes de création/suppression de profil. -- Si vous définissez `nodeHost.browserProxy.allowProfiles`, OpenClaw le traite comme une limite de moindre privilège : seuls les profils autorisés peuvent être ciblés, et les routes persistantes de création/suppression de profil sont bloquées sur la surface du proxy. -- Désactivez-le si vous n’en voulez pas : +- Les profils proviennent de la propre configuration `browser.profiles` du node (comme en local). +- `nodeHost.browserProxy.allowProfiles` est facultatif. Laissez-le vide pour le comportement hérité/par défaut : tous les profils configurés restent accessibles via le proxy, y compris les routes de création/suppression de profils. +- Si vous définissez `nodeHost.browserProxy.allowProfiles`, OpenClaw le traite comme une frontière de moindre privilège : seuls les profils autorisés peuvent être ciblés, et les routes persistantes de création/suppression de profils sont bloquées sur la surface du proxy. +- Désactivez-le si vous ne le voulez pas : - Sur le node : `nodeHost.browserProxy.enabled=false` - Sur la gateway : `gateway.nodes.browser.mode="off"` ## Browserless (CDP distant hébergé) -[Browserless](https://browserless.io) est un service Chromium hébergé qui expose -des URL de connexion CDP via HTTPS et WebSocket. OpenClaw peut utiliser les deux formes, mais +[Browserless](https://browserless.io) est un service Chromium hébergé qui expose des +URL de connexion CDP en HTTPS et WebSocket. OpenClaw peut utiliser l’une ou l’autre forme, mais pour un profil de navigateur distant, l’option la plus simple est l’URL WebSocket directe -issue de la documentation de connexion de Browserless. +figurant dans la documentation de connexion de Browserless. Exemple : @@ -311,9 +311,9 @@ Exemple : } ``` -Remarques : +Notes : -- Remplacez `` par votre vrai jeton Browserless. +- Remplacez `` par votre véritable jeton Browserless. - Choisissez le point de terminaison régional correspondant à votre compte Browserless (voir leur documentation). - Si Browserless vous fournit une URL de base HTTPS, vous pouvez soit la convertir en `wss://` pour une connexion CDP directe, soit conserver l’URL HTTPS et laisser OpenClaw @@ -322,18 +322,34 @@ Remarques : ## Fournisseurs CDP WebSocket directs Certains services de navigateur hébergés exposent un point de terminaison **WebSocket direct** plutôt que -la découverte CDP standard basée sur HTTP (`/json/version`). OpenClaw prend en charge les deux : +la découverte CDP standard basée sur HTTP (`/json/version`). OpenClaw accepte trois formes +d’URL CDP et choisit automatiquement la bonne stratégie de connexion : -- **Points de terminaison HTTP(S)** — OpenClaw appelle `/json/version` pour découvrir l’URL WebSocket du débogueur, puis s’y connecte. -- **Points de terminaison WebSocket** (`ws://` / `wss://`) — OpenClaw se connecte directement, en ignorant `/json/version`. Utilisez cette option pour des services comme - [Browserless](https://browserless.io), - [Browserbase](https://www.browserbase.com), ou tout fournisseur qui vous fournit une - URL WebSocket. +- **Découverte HTTP(S)** — `http://host[:port]` ou `https://host[:port]`. + OpenClaw appelle `/json/version` pour découvrir l’URL WebSocket du débogueur, puis + se connecte. Aucun repli WebSocket. +- **Points de terminaison WebSocket directs** — `ws://host[:port]/devtools//` ou + `wss://...` avec un chemin `/devtools/browser|page|worker|shared_worker|service_worker/`. + OpenClaw se connecte directement via un handshake WebSocket et ignore + entièrement `/json/version`. +- **Racines WebSocket nues** — `ws://host[:port]` ou `wss://host[:port]` sans + chemin `/devtools/...` (par ex. [Browserless](https://browserless.io), + [Browserbase](https://www.browserbase.com)). OpenClaw tente d’abord une découverte HTTP + `/json/version` (en normalisant le schéma en `http`/`https`) ; + si la découverte renvoie un `webSocketDebuggerUrl`, il est utilisé, sinon OpenClaw + se replie sur un handshake WebSocket direct à la racine nue. Cela couvre + à la fois les ports de débogage distant de type Chrome et les fournisseurs uniquement WebSocket. + +Le format simple `ws://host:port` / `wss://host:port` sans chemin `/devtools/...` +pointant vers une instance locale de Chrome est pris en charge via le repli +avec découverte d’abord — Chrome n’accepte les upgrades WebSocket que sur le chemin spécifique +par navigateur ou par cible renvoyé par `/json/version`, donc un simple handshake à la racine +échouerait. ### Browserbase -[Browserbase](https://www.browserbase.com) est une plateforme cloud permettant d’exécuter -des navigateurs headless avec résolution CAPTCHA intégrée, mode furtif et proxys +[Browserbase](https://www.browserbase.com) est une plateforme cloud permettant d’exécuter des +navigateurs headless avec résolution CAPTCHA intégrée, mode furtif et proxys résidentiels. ```json5 @@ -353,38 +369,38 @@ résidentiels. } ``` -Remarques : +Notes : -- [Inscrivez-vous](https://www.browserbase.com/sign-up) puis copiez votre **API Key** +- [Inscrivez-vous](https://www.browserbase.com/sign-up) et copiez votre **clé API** depuis le [tableau de bord Overview](https://www.browserbase.com/overview). -- Remplacez `` par votre vraie clé API Browserbase. +- Remplacez `` par votre véritable clé API Browserbase. - Browserbase crée automatiquement une session de navigateur lors de la connexion WebSocket, donc aucune étape manuelle de création de session n’est nécessaire. -- L’offre gratuite autorise une session simultanée et une heure de navigateur par mois. +- L’offre gratuite autorise une session concurrente et une heure de navigateur par mois. Consultez les [tarifs](https://www.browserbase.com/pricing) pour les limites des offres payantes. - Consultez la [documentation Browserbase](https://docs.browserbase.com) pour la référence API - complète, les guides SDK et les exemples d’intégration. + complète, les guides SDK et des exemples d’intégration. ## Sécurité Idées clés : -- Le contrôle du navigateur est limité au loopback ; l’accès passe par l’authentification du Gateway ou l’appairage du node. +- Le contrôle du navigateur est limité au loopback ; l’accès passe par l’authentification Gateway ou l’appairage node. - L’API HTTP autonome du navigateur en loopback utilise **uniquement une authentification par secret partagé** : - auth bearer par jeton gateway, `x-openclaw-password`, ou authentification HTTP Basic avec le - mot de passe gateway configuré. -- Les en-têtes d’identité Tailscale Serve et `gateway.auth.mode: "trusted-proxy"` ne - **n’authentifient pas** cette API autonome du navigateur en loopback. + authentification bearer par jeton Gateway, `x-openclaw-password`, ou authentification HTTP Basic avec le + mot de passe Gateway configuré. +- Les en-têtes d’identité Tailscale Serve et `gateway.auth.mode: "trusted-proxy"` n’authentifient + **pas** cette API autonome du navigateur en loopback. - Si le contrôle du navigateur est activé et qu’aucune authentification par secret partagé n’est configurée, OpenClaw - génère automatiquement `gateway.auth.token` au démarrage et le persiste dans la config. -- OpenClaw ne **génère pas automatiquement** ce jeton lorsque `gateway.auth.mode` vaut déjà - `password`, `none`, ou `trusted-proxy`. -- Conservez le Gateway et tous les hôtes node sur un réseau privé (Tailscale) ; évitez toute exposition publique. -- Traitez les URL/jetons CDP distants comme des secrets ; préférez des variables d’environnement ou un gestionnaire de secrets. + génère automatiquement `gateway.auth.token` au démarrage et le persiste dans la configuration. +- OpenClaw ne génère **pas** automatiquement ce jeton lorsque `gateway.auth.mode` est + déjà `password`, `none` ou `trusted-proxy`. +- Conservez Gateway et tout hôte node sur un réseau privé (Tailscale) ; évitez toute exposition publique. +- Traitez les URL/jetons CDP distants comme des secrets ; préférez les variables d’environnement ou un gestionnaire de secrets. -Conseils CDP distants : +Conseils pour CDP distant : -- Préférez des points de terminaison chiffrés (HTTPS ou WSS) et des jetons de courte durée lorsque c’est possible. +- Préférez des points de terminaison chiffrés (HTTPS ou WSS) et des jetons de courte durée quand c’est possible. - Évitez d’intégrer directement des jetons de longue durée dans les fichiers de configuration. ## Profils (multi-navigateur) @@ -392,26 +408,26 @@ Conseils CDP distants : OpenClaw prend en charge plusieurs profils nommés (configurations de routage). Les profils peuvent être : - **gérés par openclaw** : une instance de navigateur dédiée basée sur Chromium avec son propre répertoire de données utilisateur + port CDP -- **distants** : une URL CDP explicite (navigateur basé sur Chromium exécuté ailleurs) -- **session existante** : votre profil Chrome existant via connexion automatique Chrome DevTools MCP +- **distant** : une URL CDP explicite (navigateur basé sur Chromium exécuté ailleurs) +- **session existante** : votre profil Chrome existant via l’auto-connexion Chrome DevTools MCP Valeurs par défaut : -- Le profil `openclaw` est créé automatiquement s’il est absent. -- Le profil `user` est intégré pour le rattachement existing-session Chrome MCP. -- Les profils existing-session sont optionnels au-delà de `user` ; créez-les avec `--driver existing-session`. -- Les ports CDP locaux sont alloués dans la plage **18800–18899** par défaut. -- Supprimer un profil déplace son répertoire local de données vers la corbeille. +- Le profil `openclaw` est créé automatiquement s’il manque. +- Le profil `user` est intégré pour le rattachement à une session existante via Chrome MCP. +- Les profils de session existante sont facultatifs au-delà de `user` ; créez-les avec `--driver existing-session`. +- Les ports CDP locaux sont alloués par défaut dans la plage **18800–18899**. +- La suppression d’un profil déplace son répertoire de données local vers la corbeille. Tous les points de terminaison de contrôle acceptent `?profile=` ; la CLI utilise `--browser-profile`. -## Existing-session via Chrome DevTools MCP +## Session existante via Chrome DevTools MCP -OpenClaw peut également se rattacher à un profil de navigateur basé sur Chromium déjà en cours d’exécution via le +OpenClaw peut aussi se rattacher à un profil de navigateur déjà en cours d’exécution basé sur Chromium via le serveur officiel Chrome DevTools MCP. Cela réutilise les onglets et l’état de connexion déjà ouverts dans ce profil de navigateur. -Références officielles de contexte et de configuration : +Références officielles pour le contexte et l’installation : - [Chrome for Developers: Use Chrome DevTools MCP with your browser session](https://developer.chrome.com/blog/chrome-devtools-mcp-debug-your-browser-session) - [Chrome DevTools MCP README](https://github.com/ChromeDevTools/chrome-devtools-mcp) @@ -420,12 +436,12 @@ Profil intégré : - `user` -Facultatif : créez votre propre profil existing-session personnalisé si vous souhaitez un -nom, une couleur ou un répertoire de données de navigateur différent. +Facultatif : créez votre propre profil de session existante si vous souhaitez un +nom, une couleur ou un répertoire de données du navigateur différents. Comportement par défaut : -- Le profil intégré `user` utilise la connexion automatique Chrome MCP, qui cible le +- Le profil intégré `user` utilise l’auto-connexion Chrome MCP, qui cible le profil Google Chrome local par défaut. Utilisez `userDataDir` pour Brave, Edge, Chromium ou un profil Chrome non par défaut : @@ -445,11 +461,11 @@ Utilisez `userDataDir` pour Brave, Edge, Chromium ou un profil Chrome non par d } ``` -Puis, dans le navigateur correspondant : +Ensuite, dans le navigateur correspondant : -1. Ouvrez la page d’inspection de ce navigateur pour le débogage à distance. -2. Activez le débogage à distance. -3. Laissez le navigateur en cours d’exécution et approuvez l’invite de connexion quand OpenClaw se rattache. +1. Ouvrez la page d’inspection de ce navigateur pour le débogage distant. +2. Activez le débogage distant. +3. Gardez le navigateur en cours d’exécution et approuvez l’invite de connexion lorsque OpenClaw s’y rattache. Pages d’inspection courantes : @@ -457,7 +473,7 @@ Pages d’inspection courantes : - Brave : `brave://inspect/#remote-debugging` - Edge : `edge://inspect/#remote-debugging` -Test rapide de rattachement en direct : +Smoke test d’attachement live : ```bash openclaw browser --browser-profile user start @@ -466,73 +482,75 @@ openclaw browser --browser-profile user tabs openclaw browser --browser-profile user snapshot --format ai ``` -À quoi ressemble un succès : +À quoi ressemble un rattachement réussi : - `status` affiche `driver: existing-session` - `status` affiche `transport: chrome-mcp` - `status` affiche `running: true` -- `tabs` liste vos onglets de navigateur déjà ouverts -- `snapshot` renvoie des refs depuis l’onglet actif sélectionné +- `tabs` liste les onglets déjà ouverts dans votre navigateur +- `snapshot` renvoie des références depuis l’onglet live sélectionné -Que vérifier si le rattachement ne fonctionne pas : +Points à vérifier si le rattachement ne fonctionne pas : - le navigateur cible basé sur Chromium est en version `144+` -- le débogage à distance est activé dans la page d’inspection de ce navigateur +- le débogage distant est activé dans la page d’inspection de ce navigateur - le navigateur a affiché l’invite de consentement au rattachement et vous l’avez acceptée - `openclaw doctor` migre l’ancienne configuration de navigateur basée sur une extension et vérifie que - Chrome est installé localement pour les profils de connexion automatique par défaut, mais il ne peut - pas activer le débogage à distance côté navigateur à votre place + Chrome est installé localement pour les profils d’auto-connexion par défaut, mais il ne peut pas + activer pour vous le débogage distant côté navigateur Utilisation par l’agent : -- Utilisez `profile="user"` lorsque vous avez besoin de l’état du navigateur connecté de l’utilisateur. -- Si vous utilisez un profil existing-session personnalisé, passez ce nom de profil explicite. -- Choisissez ce mode uniquement lorsque l’utilisateur est devant l’ordinateur pour approuver l’invite +- Utilisez `profile="user"` lorsque vous avez besoin de l’état connecté du navigateur de l’utilisateur. +- Si vous utilisez un profil de session existante personnalisé, transmettez ce nom de profil explicite. +- Choisissez ce mode uniquement lorsque l’utilisateur est à l’ordinateur pour approuver l’invite de rattachement. -- le Gateway ou l’hôte node peut lancer `npx chrome-devtools-mcp@latest --autoConnect` +- Gateway ou l’hôte node peut lancer `npx chrome-devtools-mcp@latest --autoConnect` -Remarques : +Notes : -- Cette voie présente plus de risques que le profil isolé `openclaw` parce qu’elle peut +- Ce chemin est plus risqué que le profil isolé `openclaw` car il peut agir dans votre session de navigateur connectée. - OpenClaw ne lance pas le navigateur pour ce driver ; il se rattache uniquement à une session existante. -- OpenClaw utilise ici le flux officiel Chrome DevTools MCP `--autoConnect`. Si +- OpenClaw utilise ici le flux officiel `--autoConnect` de Chrome DevTools MCP. Si `userDataDir` est défini, OpenClaw le transmet pour cibler explicitement ce répertoire de données utilisateur Chromium. -- Les captures d’écran existing-session prennent en charge les captures de page et les captures d’élément `--ref` - issues de la sortie de snapshot, mais pas les sélecteurs CSS `--element`. -- Les captures d’écran de page existing-session fonctionnent sans Playwright via Chrome MCP. - Les captures d’élément par ref (`--ref`) y fonctionnent aussi, mais `--full-page` +- Les captures d’écran en session existante prennent en charge les captures de page et les captures d’élément `--ref` + depuis les instantanés, mais pas les sélecteurs CSS `--element`. +- Les captures d’écran de page en session existante fonctionnent sans Playwright via Chrome MCP. + Les captures d’élément basées sur une référence (`--ref`) y fonctionnent aussi, mais `--full-page` ne peut pas être combiné avec `--ref` ou `--element`. -- Les actions existing-session restent plus limitées que le chemin du navigateur - géré : - - `click`, `type`, `hover`, `scrollIntoView`, `drag`, et `select` exigent - des refs de snapshot plutôt que des sélecteurs CSS - - `click` est limité au bouton gauche (pas de surcharge du bouton ni de modificateurs) +- Les actions en session existante restent plus limitées que dans le + chemin du navigateur géré : + - `click`, `type`, `hover`, `scrollIntoView`, `drag` et `select` exigent + des références d’instantané au lieu de sélecteurs CSS + - `click` fonctionne uniquement avec le bouton gauche (pas de redéfinition de bouton ni de modificateurs) - `type` ne prend pas en charge `slowly=true` ; utilisez `fill` ou `press` - `press` ne prend pas en charge `delayMs` - - `hover`, `scrollIntoView`, `drag`, `select`, `fill`, et `evaluate` ne - prennent pas en charge les surcharges de délai d’expiration par appel + - `hover`, `scrollIntoView`, `drag`, `select`, `fill` et `evaluate` ne + prennent pas en charge les redéfinitions de délai d’attente par appel - `select` ne prend actuellement en charge qu’une seule valeur -- Existing-session `wait --url` prend en charge les motifs exacts, par sous-chaîne et glob +- `wait --url` en session existante prend en charge les motifs exacts, sous-chaîne et glob comme les autres drivers de navigateur. `wait --load networkidle` n’est pas encore pris en charge. -- Les hooks de téléversement existing-session exigent `ref` ou `inputRef`, prennent en charge un seul fichier à la fois et ne prennent pas en charge le ciblage CSS `element`. -- Les hooks de boîte de dialogue existing-session ne prennent pas en charge les surcharges de délai d’expiration. -- Certaines fonctionnalités nécessitent encore le chemin du navigateur géré, notamment les - actions par lot, l’export PDF, l’interception des téléchargements et `responsebody`. -- Existing-session est local à l’hôte. Si Chrome se trouve sur une autre machine ou dans un - autre espace de noms réseau, utilisez plutôt le CDP distant ou un hôte node. +- Les hooks d’upload en session existante exigent `ref` ou `inputRef`, prennent en charge un seul fichier + à la fois et ne prennent pas en charge le ciblage CSS `element`. +- Les hooks de boîte de dialogue en session existante ne prennent pas en charge les redéfinitions de délai d’attente. +- Certaines fonctionnalités exigent encore le chemin du navigateur géré, notamment les actions par lot, + l’export PDF, l’interception des téléchargements et `responsebody`. +- La session existante peut se rattacher sur l’hôte sélectionné ou via un node + de navigateur connecté. Si Chrome se trouve ailleurs et qu’aucun node de navigateur n’est connecté, utilisez + plutôt CDP distant ou un hôte node. ## Garanties d’isolation -- **Répertoire de données utilisateur dédié** : ne touche jamais à votre profil de navigateur personnel. -- **Ports dédiés** : évite `9222` pour prévenir les collisions avec les workflows de développement. -- **Contrôle déterministe des onglets** : ciblez les onglets par `targetId`, pas par « dernier onglet ». +- **Répertoire de données utilisateur dédié** : ne touche jamais au profil de votre navigateur personnel. +- **Ports dédiés** : évite `9222` pour prévenir les collisions avec les flux de développement. +- **Contrôle déterministe des onglets** : cible les onglets par `targetId`, et non par « dernier onglet ». ## Sélection du navigateur -Lors du lancement local, OpenClaw choisit le premier disponible : +Lors d’un lancement local, OpenClaw choisit le premier disponible : 1. Chrome 2. Brave @@ -540,7 +558,7 @@ Lors du lancement local, OpenClaw choisit le premier disponible : 4. Chromium 5. Chrome Canary -Vous pouvez surcharger cela avec `browser.executablePath`. +Vous pouvez redéfinir ce comportement avec `browser.executablePath`. Plateformes : @@ -550,11 +568,11 @@ Plateformes : ## API de contrôle (facultative) -Pour les intégrations locales uniquement, le Gateway expose une petite API HTTP en loopback : +Pour les intégrations locales uniquement, Gateway expose une petite API HTTP loopback : - Statut/démarrage/arrêt : `GET /`, `POST /start`, `POST /stop` - Onglets : `GET /tabs`, `POST /tabs/open`, `POST /tabs/focus`, `DELETE /tabs/:targetId` -- Snapshot/capture d’écran : `GET /snapshot`, `POST /screenshot` +- Instantané/capture d’écran : `GET /snapshot`, `POST /screenshot` - Actions : `POST /navigate`, `POST /act` - Hooks : `POST /hooks/file-chooser`, `POST /hooks/dialog` - Téléchargements : `POST /download`, `POST /wait/download` @@ -567,16 +585,17 @@ Pour les intégrations locales uniquement, le Gateway expose une petite API HTTP Tous les points de terminaison acceptent `?profile=`. -Si une authentification gateway par secret partagé est configurée, les routes HTTP du navigateur exigent aussi une authentification : +Si une authentification Gateway par secret partagé est configurée, les routes HTTP du navigateur exigent aussi une authentification : - `Authorization: Bearer ` - `x-openclaw-password: ` ou authentification HTTP Basic avec ce mot de passe -Remarques : +Notes : -- Cette API autonome du navigateur en loopback ne consomme **pas** les en-têtes d’identité trusted-proxy ni Tailscale Serve. -- Si `gateway.auth.mode` vaut `none` ou `trusted-proxy`, ces routes de navigateur en loopback - n’héritent pas de ces modes porteurs d’identité ; conservez-les en loopback uniquement. +- Cette API autonome du navigateur en loopback ne consomme **pas** les en-têtes d’identité trusted-proxy ou + Tailscale Serve. +- Si `gateway.auth.mode` vaut `none` ou `trusted-proxy`, ces routes navigateur en loopback + n’héritent pas de ces modes porteurs d’identité ; gardez-les limitées au loopback. ### Contrat d’erreur `/act` @@ -589,37 +608,37 @@ de politique : Valeurs actuelles de `code` : -- `ACT_KIND_REQUIRED` (HTTP 400) : `kind` est absent ou non reconnu. +- `ACT_KIND_REQUIRED` (HTTP 400) : `kind` est manquant ou non reconnu. - `ACT_INVALID_REQUEST` (HTTP 400) : la charge utile de l’action a échoué à la normalisation ou à la validation. - `ACT_SELECTOR_UNSUPPORTED` (HTTP 400) : `selector` a été utilisé avec un type d’action non pris en charge. -- `ACT_EVALUATE_DISABLED` (HTTP 403) : `evaluate` (ou `wait --fn`) est désactivé par la config. -- `ACT_TARGET_ID_MISMATCH` (HTTP 403) : `targetId` de niveau supérieur ou en lot est en conflit avec la cible de la requête. -- `ACT_EXISTING_SESSION_UNSUPPORTED` (HTTP 501) : l’action n’est pas prise en charge pour les profils existing-session. +- `ACT_EVALUATE_DISABLED` (HTTP 403) : `evaluate` (ou `wait --fn`) est désactivé par la configuration. +- `ACT_TARGET_ID_MISMATCH` (HTTP 403) : le `targetId` de niveau supérieur ou en lot est en conflit avec la cible de la requête. +- `ACT_EXISTING_SESSION_UNSUPPORTED` (HTTP 501) : l’action n’est pas prise en charge pour les profils de session existante. -D’autres échecs d’exécution peuvent toujours renvoyer `{ "error": "" }` sans champ -`code`. +D’autres erreurs d’exécution peuvent toujours renvoyer `{ "error": "" }` sans +champ `code`. ### Exigence Playwright -Certaines fonctionnalités (navigate/act/snapshot IA/snapshot de rôle, captures d’écran d’élément, -PDF) nécessitent Playwright. Si Playwright n’est pas installé, ces points de terminaison renvoient +Certaines fonctionnalités (`navigate`/`act`/instantané AI/instantané de rôle, captures d’écran d’élément, +PDF) exigent Playwright. Si Playwright n’est pas installé, ces points de terminaison renvoient une erreur 501 claire. Ce qui fonctionne encore sans Playwright : -- Snapshots ARIA -- Captures d’écran de page pour le navigateur `openclaw` géré lorsqu’un WebSocket - CDP par onglet est disponible -- Captures d’écran de page pour les profils `existing-session` / Chrome MCP -- Captures d’écran existing-session basées sur ref (`--ref`) à partir de la sortie de snapshot +- instantanés ARIA +- captures d’écran de page pour le navigateur géré `openclaw` lorsqu’un WebSocket CDP + par onglet est disponible +- captures d’écran de page pour les profils `existing-session` / Chrome MCP +- captures d’écran basées sur une référence `existing-session` (`--ref`) à partir de la sortie d’instantané -Ce qui nécessite toujours Playwright : +Ce qui exige encore Playwright : - `navigate` - `act` -- Snapshots IA / snapshots de rôle -- Captures d’écran d’élément par sélecteur CSS (`--element`) -- Export PDF complet du navigateur +- instantanés AI / instantanés de rôle +- captures d’écran d’élément par sélecteur CSS (`--element`) +- export PDF complet du navigateur Les captures d’écran d’élément rejettent aussi `--full-page` ; la route renvoie `fullPage is not supported for element screenshots`. @@ -630,16 +649,16 @@ OpenClaw avec la prise en charge du navigateur. #### Installation de Playwright dans Docker -Si votre Gateway s’exécute dans Docker, évitez `npx playwright` (conflits de surcharge npm). -Utilisez plutôt la CLI intégrée : +Si votre Gateway s’exécute dans Docker, évitez `npx playwright` (conflits d’override npm). +Utilisez plutôt la CLI groupée : ```bash docker compose run --rm openclaw-cli \ node /app/node_modules/playwright-core/cli.js install chromium ``` -Pour conserver les téléchargements du navigateur, définissez `PLAYWRIGHT_BROWSERS_PATH` (par exemple, -`/home/node/.cache/ms-playwright`) et assurez-vous que `/home/node` est conservé via +Pour rendre persistants les téléchargements du navigateur, définissez `PLAYWRIGHT_BROWSERS_PATH` (par exemple, +`/home/node/.cache/ms-playwright`) et assurez-vous que `/home/node` est persistant via `OPENCLAW_HOME_VOLUME` ou un montage bind. Voir [Docker](/fr/install/docker). ## Fonctionnement (interne) @@ -648,17 +667,17 @@ Flux de haut niveau : - Un petit **serveur de contrôle** accepte les requêtes HTTP. - Il se connecte aux navigateurs basés sur Chromium (Chrome/Brave/Edge/Chromium) via **CDP**. -- Pour les actions avancées (clic/saisie/snapshot/PDF), il utilise **Playwright** par-dessus +- Pour les actions avancées (clic/saisie/instantané/PDF), il utilise **Playwright** par-dessus CDP. -- Lorsque Playwright est absent, seules les opérations ne dépendant pas de Playwright sont disponibles. +- Lorsque Playwright est absent, seules les opérations sans Playwright sont disponibles. -Cette conception maintient l’agent sur une interface stable et déterministe tout en vous permettant -de changer de navigateurs et de profils locaux/distants. +Cette conception maintient une interface stable et déterministe pour l’agent tout en vous permettant +de permuter les navigateurs et profils locaux/distants. ## Référence rapide CLI -Toutes les commandes acceptent `--browser-profile ` pour cibler un profil spécifique. -Toutes les commandes acceptent également `--json` pour une sortie lisible par machine (charges utiles stables). +Toutes les commandes acceptent `--browser-profile ` pour cibler un profil précis. +Toutes les commandes acceptent aussi `--json` pour une sortie lisible par machine (charges utiles stables). Bases : @@ -689,11 +708,11 @@ Inspection : - `openclaw browser snapshot --frame "iframe#main" --interactive` - `openclaw browser console --level error` -Remarque sur le cycle de vie : +Note sur le cycle de vie : - Pour les profils attach-only et CDP distants, `openclaw browser stop` reste la bonne commande de nettoyage après les tests. Elle ferme la session de contrôle active et - efface les surcharges d’émulation temporaires au lieu de tuer le navigateur + efface les redéfinitions temporaires d’émulation au lieu de tuer le navigateur sous-jacent. - `openclaw browser errors --clear` - `openclaw browser requests --filter api --clear` @@ -743,51 +762,51 @@ Actions : - `openclaw browser set locale en-US` - `openclaw browser set device "iPhone 14"` -Remarques : +Notes : - `upload` et `dialog` sont des appels d’**armement** ; exécutez-les avant le clic/la pression qui déclenche le sélecteur/la boîte de dialogue. -- Les chemins de sortie de téléchargement et de trace sont limités aux racines temporaires d’OpenClaw : +- Les chemins de sortie de téléchargement et de trace sont limités aux racines temporaires OpenClaw : - traces : `/tmp/openclaw` (repli : `${os.tmpdir()}/openclaw`) - téléchargements : `/tmp/openclaw/downloads` (repli : `${os.tmpdir()}/openclaw/downloads`) - Les chemins d’upload sont limités à une racine temporaire d’uploads OpenClaw : - uploads : `/tmp/openclaw/uploads` (repli : `${os.tmpdir()}/openclaw/uploads`) - `upload` peut aussi définir directement des entrées de fichier via `--input-ref` ou `--element`. - `snapshot` : - - `--format ai` (par défaut quand Playwright est installé) : renvoie un snapshot IA avec des refs numériques (`aria-ref=""`). - - `--format aria` : renvoie l’arbre d’accessibilité (sans refs ; inspection uniquement). - - `--efficient` (ou `--mode efficient`) : préréglage de snapshot de rôle compact (interactive + compact + depth + maxChars réduit). - - Valeur par défaut de config (outil/CLI uniquement) : définissez `browser.snapshotDefaults.mode: "efficient"` pour utiliser des snapshots efficaces lorsque l’appelant ne passe pas de mode (voir [Configuration de la Gateway](/fr/gateway/configuration-reference#browser)). - - Les options de snapshot de rôle (`--interactive`, `--compact`, `--depth`, `--selector`) forcent un snapshot basé sur les rôles avec des refs comme `ref=e12`. - - `--frame "