OpenClaw est une boucle : il lit votre espace de travail, exécute des commandes shell via son outil d'exécution, lit la sortie et décide quoi faire ensuite. Alors pourquoi vos tests API ne sont-ils pas inclus dans cette boucle ? Ils se trouvent dans Apidog, derrière une interface graphique, et ne sont exécutés que lorsque quelqu'un se souvient de cliquer. Votre agent ne les touche jamais.
La solution est un seul bloc de configuration. L'interface de ligne de commande (CLI) d'Apidog est un package npm, apidog-cli, qui exécute les scénarios de test que vous avez créés dans Apidog directement depuis un terminal. Une fois la CLI installée et qu'OpenClaw sait qu'elle existe, votre agent exécute un scénario Apidog de la même manière qu'il exécute vos tests unitaires : lancez la commande, lisez le code de sortie, corrigez le code s'il est rouge.
Ce guide couvre la partie spécifique à OpenClaw que le guide d'installation générique ignore : où placer les règles Apidog pour que l'agent les conserve, comment l'outil d'exécution d'OpenClaw exécute réellement apidog run et comment lire le résultat.
Si vous n'avez pas encore installé la CLI, faites-le d'abord. Comment installer la CLI Apidog avec un agent de codage IA explique l'installation npm, l'authentification et la première exécution. Cet article suppose que apidog --version affiche un numéro et que votre compte Apidog est connecté.
De quel OpenClaw il s'agit
OpenClaw est l'agent IA open-source, local-first, qui s'exécute sur votre propre machine. Il possède un espace de travail, un ensemble de compétences et un outil d'exécution qui exécute de véritables commandes shell. Ce n'est pas un plugin de complétion de code ni un chatbot hébergé. Si vous avez exécuté openclaw localement et l'avez vu modifier des fichiers et exécuter des commandes, vous êtes au bon endroit. Pour une configuration plus large, consultez l'automatisation du flux de travail de développement OpenClaw et le guide d'une installation sécurisée d'OpenClaw avant de lui confier des commandes.
Cette distinction est importante car OpenClaw apprend les règles du projet à partir des fichiers de l'espace de travail, et ce mécanisme transforme un "exécute mes tests" ponctuel en quelque chose qu'OpenClaw recherche de lui-même. Ce mécanisme est AGENTS.md.
Étape 1 : Ajoutez les règles Apidog à AGENTS.md
OpenClaw lit les fichiers de l'espace de travail comme des instructions permanentes et les injecte dans le contexte de l'agent. Celui que vous voulez est AGENTS.md, le manuel de règles procédurales qui indique à l'agent quoi faire et comment. Considérez-le comme CLAUDE.md pour Claude Code ; OpenClaw livre même un modèle par défaut que vous copiez dans votre espace de travail, et il traite un lien symbolique CLAUDE.md jumeau comme le même fichier. L'espace de travail par défaut est ~/.openclaw/workspace, mais vous pouvez pointer un agent vers votre répertoire de projet avec agents.list[].workspace, et OpenClaw prend en charge les fichiers AGENTS.md scellés par sous-répertoire (voir la référence AGENTS.md d'OpenClaw).
Ajoutez un court bloc à votre fichier AGENTS.md :
## Test d'API avec Apidog
- Pour exécuter les tests API, utilisez la CLI Apidog : `apidog run -t <scenario_id> -e <env_id> -r cli`.
- Un code de sortie 0 signifie que toutes les assertions ont réussi. Un code non nul signifie qu'un élément a échoué. Traitez-le comme la porte de réussite/échec.
- La machine est déjà authentifiée avec `apidog login`. N'ajoutez jamais d'option --access-token et ne placez jamais de jeton dans ce fichier.
- Si un indicateur semble inconnu, exécutez `apidog run --help` au lieu de deviner.
C'est pourquoi vous écrivez la CLI dans AGENTS.md au lieu de la mentionner dans le chat. Un ID de scénario tapé dans une session disparaît lorsque la session se termine. Un ID dans AGENTS.md est là pour chaque coéquipier et chaque exécution d'OpenClaw à partir de maintenant.
Étape 2 : Obtenez la commande d'Apidog
Vous n'avez pas besoin d'écrire l'ID du scénario à la main. Ouvrez le scénario de test dans Apidog, allez dans son onglet CI/CD et copiez la commande générée. Elle ressemble à ceci :
apidog run -t 1234567 -e 890123 -r cli
L'option -t désigne le scénario de test, -e l'environnement, et -r cli le rapporteur. Collez les vrais ID dans le bloc AGENTS.md de l'étape 1 afin qu'OpenClaw appelle toujours le bon scénario contre le bon environnement. Le guide complet de la CLI Apidog et la référence des commandes apidog run couvrent toutes les options si vous souhaitez l'ajuster.
Étape 3 : Demandez à l'agent d'exécuter le test
Une fois le bloc en place, démarrez OpenClaw sur votre projet et effectuez une modification qui touche votre API, ou demandez-lui simplement d'exécuter la vérification. Étant donné que AGENTS.md est déjà en contexte, l'agent sait que la CLI existe et émet la commande apidog run via son outil d'exécution.
L'outil d'exécution exécute les commandes shell dans l'espace de travail, et OpenClaw le protège avec un mode de permission. Les modes sont deny (refuser), allowlist (liste blanche), ask (demander), auto (automatique) et full (complet) (documentés sur la page des modes de permission d'OpenClaw). Pour un agent de codage, auto est le paramètre judicieux : les commandes figurant sur la liste blanche s'exécutent sans invite, et tout le reste passe par une révision avant de vous demander. Si votre mode est ask, OpenClaw fait une pause et demande l'approbation avant d'exécuter apidog run ; approuvez-le une fois, ou ajoutez la commande à votre liste blanche afin qu'un test en lecture seule sur l'environnement de staging s'exécute automatiquement. Définissez le mode sous tools.exec dans openclaw.json.
Étape 4 : Lisez le rapport dans OpenClaw
Le rapporteur -r cli affiche un résultat étape par étape dans le terminal : chaque requête, chaque assertion, et laquelle a échoué avec la valeur attendue par rapport à la valeur réelle. Cette décomposition en ligne est ce qu'OpenClaw lit pour décider de sa prochaine étape, alors gardez cli dans la liste.
Lorsque vous souhaitez un rapport que vous pouvez ouvrir dans un navigateur ou remettre à un coéquipier, ajoutez le rapporteur HTML :
apidog run -t 1234567 -e 890123 -r cli,html
Le rapporteur html écrit un fichier autonome dans ./apidog-reports. Gardez cli à côté pour qu'OpenClaw reçoive toujours la sortie en ligne. Pour le format JUnit que les tableaux de bord CI analysent et tous les autres rapporteurs, consultez le guide des rapports de test de la CLI Apidog.
Les tests OpenClaw dans sa propre boucle
L'important est ce qui se passe lorsque vous arrêtez de demander et qu'OpenClaw exécute le scénario de lui-même parce que AGENTS.md le lui a indiqué.
Imaginez OpenClaw modifiant un gestionnaire qui construit une réponse de paiement. Sa boucle change : il modifie le code, puis, au lieu de crier victoire, exécute votre scénario Apidog sur l'environnement de staging, lit le code de sortie et agit en conséquence. Vert, il passe à la suite. Rouge, il ouvre le rapport, lit quelle assertion a échoué (le code de statut, le champ manquant, la mauvaise valeur), essaie une correction et relance. Le test API devient partie intégrante de la même boucle d'édition-test-correction qu'OpenClaw utilise déjà pour vos tests unitaires. Vous avez écrit une seule instruction et l'agent a intégré la commande à son fonctionnement existant.
C'est le modèle « déléguer puis vérifier » qui sécurise tout flux de travail d'agent. OpenClaw exécute la commande et lit le résultat ; vous continuez à créer des scénarios visuellement dans Apidog et vérifiez ponctuellement que l'agent lit les codes de sortie honnêtement. Pour le modèle plus large, consultez comment utiliser les agents IA pour les tests API et le harnais de test IA Apidog.
Vérifier qu'OpenClaw exécute réellement la CLI
Les agents signalent des succès qu'ils n'ont pas mérités, et OpenClaw ne fait pas exception. Voici trois vérifications, par ordre de fréquence à laquelle elles détectent des problèmes.
Premièrement, vérifiez que la commande a bien été exécutée. Le transcript d'OpenClaw affiche les commandes d'exécution qu'il a exécutées et leur sortie. Recherchez la ligne littérale apidog run ... et un résultat en dessous. Si OpenClaw dit qu'il a exécuté les tests mais que vous ne voyez pas la commande, il a résumé quelque chose qu'il n'a jamais fait. Demandez-lui de l'exécuter à nouveau et de montrer la sortie brute.
Deuxièmement, confirmez le code de sortie, celui qui compte. Demandez-le directement :
Quel était le code de sortie de cette commande apidog run ?
apidog run se termine avec 0 lorsque toutes les assertions réussissent et avec une valeur non nulle si quelque chose échoue. Ce comportement unique permet à OpenClaw, ou à un pipeline, de traiter l'exécution comme une porte claire. Si le texte dit "tests réussis" mais que le code de sortie est non nul, le code de sortie est le bon.
Troisièmement, confirmez qu'il a utilisé le vrai scénario. Si une exécution échoue avec "scénario introuvable", OpenClaw a peut-être inventé ou mal mémorisé un ID. Vérifiez à nouveau les valeurs -t et -e par rapport à AGENTS.md et à la commande Apidog générée dans l'onglet CI/CD. Les ID dans AGENTS.md sont la vérité.
Facultatif : connectez le serveur MCP Apidog
L'exécution de apidog run via l'outil d'exécution couvre la plupart de vos besoins. Une autre voie va plus loin : le Protocole de Contexte de Modèle (Model Context Protocol).
OpenClaw prend en charge les serveurs MCP. Vous en ajoutez un avec openclaw mcp add <name>, ce qui écrit la définition du serveur dans ~/.openclaw/openclaw.json sous mcp.servers et accepte les options stdio comme --command et --arg (voir la documentation MCP d'OpenClaw). Le serveur MCP Apidog expose vos spécifications API via MCP, afin qu'OpenClaw puisse lire votre schéma pendant qu'il écrit du code, et non seulement après coup. La division du travail est claire : la CLI exécute les tests, et MCP fournit la spécification à l'agent.
Quand OpenClaw se trompe
Quelques échecs apparaissent souvent lors de la configuration.
Il ignore le bloc AGENTS.md. Si OpenClaw exécute une commande générique ou aucune, le fichier peut ne pas être chargé dans le contexte. Confirmez que le bloc se trouve dans le fichier AGENTS.md qui appartient à l'espace de travail actif de l'agent, et n'oubliez pas qu'OpenClaw parcourt les fichiers AGENTS.md scellés par répertoire, donc une règle enfouie dans le mauvais sous-arbre est ignorée. Redémarrer la session force une nouvelle lecture.
Il n'exécute jamais rien car l'outil d'exécution est bloqué. Étant donné que la politique par défaut d'OpenClaw s'est renforcée, l'exécution peut être refusée ou soumise à une liste blanche. Si apidog run est ignoré silencieusement, vérifiez votre mode de permission sous tools.exec et passez en mode auto ou ajoutez apidog à la liste blanche. Consultez le guide d'installation sécurisée d'OpenClaw pour savoir comment ouvrir uniquement cette commande sans tout ouvrir.
Il transmet quand même un jeton d'accès. Si OpenClaw essaie d'ajouter --access-token, il devine à partir d'exemples publics. Le bloc lui indique déjà de ne pas le faire, puisque la machine est authentifiée via apidog login. Renforcez cette ligne, et ne mettez jamais un vrai jeton dans AGENTS.md ; pour le modèle correct, consultez l'authentification de la CLI Apidog.
Il invente une option. Une erreur "unknown option" (option inconnue) signifie qu'OpenClaw a deviné une option que votre version ne possède pas. Dites-lui d'exécuter apidog run --help et de copier l'option exacte à partir de là, ce qui est toujours correct pour votre version installée.
Il signale un succès pour une exécution échouée. C'est le plus coûteux, et la raison pour laquelle la règle du code de sortie se trouve dans votre AGENTS.md et votre étape de vérification. Lorsque le résumé et le code de sortie ne correspondent pas, le code de sortie l'emporte. Si vous avez utilisé un autre agent pour cela, la même règle s'applique ; l'approche reflète ce que nous couvrons dans La CLI Apidog dans Codex et les différences dans Claude Code vs OpenClaw.
D'un agent quotidien à une boucle testée
Voilà la configuration. Installez apidog-cli une seule fois en suivant le guide d'installation, ajoutez un court bloc Apidog à votre fichier AGENTS.md de l'espace de travail, définissez le mode de permission d'exécution pour que la commande puisse s'exécuter, et OpenClaw saura comment exécuter vos tests API et lire le résultat au sein de la même boucle qu'il utilise déjà pour éditer le code. Un point de terminaison défectueux est détecté pendant qu'OpenClaw travaille encore sur la modification, et non après son déploiement.
Un test derrière une interface graphique s'exécute lorsqu'un humain clique ; une commande d'une ligne s'exécute chaque fois qu'OpenClaw le décide. Vous continuez à construire des scénarios visuellement dans Apidog, et votre agent les exécute là où vous ne regardez pas. Téléchargez Apidog, construisez un scénario, insérez sa commande apidog run dans AGENTS.md, et regardez OpenClaw la prendre en compte lors de la prochaine modification. Lorsque vous souhaitez la même porte de contrôle dans un pipeline sans la présence de l'agent, la CLI Apidog dans GitHub Actions couvre les secrets, les rapporteurs et le filtrage par code de sortie.