Claude Code est une boucle : il modifie des fichiers, exécute des commandes dans votre terminal, lit la sortie et décide quoi faire ensuite. Alors, pourquoi vos tests d'API ne font-ils pas partie de cette boucle ? Ils sont dans Apidog, derrière une interface graphique, et ne s'exécutent que lorsque quelqu'un pense à 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 que Claude Code 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 : il lance la commande, lit le code de sortie, corrige le code s'il est en échec (rouge).
Ce guide couvre la partie spécifique à Claude Code que le guide d'installation générique ignore : la ligne exacte pour votre CLAUDE.md, comment Claude Code exécute apidog run sous son modèle de permissions, et comment lire le résultat à l'intérieur de sa propre boucle d'édition-test-correction.
Si vous n'avez pas encore installé la CLI, faites-le d'abord. Comment installer la CLI Apidog avec un agent de codage IA détaille l'installation npm et la première exécution, l'agent effectuant la saisie. Cet article suppose que apidog --version affiche un numéro et que votre compte Apidog est authentifié.
De quel Claude Code s'agit-il ?
Il s'agit de la CLI Claude Code, l'agent de codage d'Anthropic qui s'exécute dans votre terminal (ou application de bureau). Il lit votre dépôt, modifie des fichiers et exécute des commandes shell, demandant une approbation en fonction de votre mode de permission. Il ne s'agit pas de l'application de chat Claude ni d'un simple appel d'API. Si vous exécutez claude dans un dépôt et obtenez un agent interactif qui propose des modifications et l'exécution de commandes, vous êtes au bon endroit. Les commandes que vous écrivez pour le terminal résident dans vos commandes slash de Claude Code et son fichier de règles, et ce fichier de règles est l'endroit où la CLI Apidog doit être placée.
La distinction est importante car Claude Code a sa propre façon d'apprendre les règles du projet, et ce mécanisme transforme un « exécute mes tests » ponctuel en quelque chose que Claude utilise de lui-même. Ce mécanisme est CLAUDE.md.
Étape 1 : Ajoutez le bloc Apidog à CLAUDE.md
Claude Code lit les fichiers CLAUDE.md au début de chaque session. C'est l'équivalent direct de AGENTS.md pour Codex ; en fait, la documentation d'Anthropic note que Claude Code lit CLAUDE.md, et non AGENTS.md, et suggère d'importer un AGENTS.md existant avec @AGENTS.md si vous en conservez un pour un autre agent. Si vous avez déjà configuré la CLI Apidog dans Codex, c'est la même idée avec un nom de fichier différent.
Placez un fichier CLAUDE.md à la racine de votre dépôt (Claude Code accepte également ./.claude/CLAUDE.md, et un fichier global ~/.claude/CLAUDE.md pour les réglages personnels par défaut). Claude Code remonte l'arborescence des répertoires à partir de l'endroit où vous l'avez lancé et charge chaque CLAUDE.md qu'il trouve, de sorte qu'un seul fichier à la racine du dépôt s'applique à chaque session. Ajoutez un court bloc comme celui-ci :
## Tests d'API avec la CLI Apidog
Ce projet contient des scénarios de test Apidog. Pour vérifier l'API, exécutez :
`apidog run -t <scenario_id> -e <env_id> -r cli`
- Un code de sortie 0 signifie que toutes les assertions sont passées. Non-zéro signifie qu'un problème est survenu ; ouvrez le rapport et corrigez-le avant de continuer.
- La machine est déjà authentifiée via `apidog login`. N'ajoutez jamais d'option `--access-token` et ne mettez jamais de jeton dans ce fichier.
- Si une option est inconnue, exécutez `apidog run --help` et utilisez l'option exacte qui s'y trouve.
C'est pourquoi vous écrivez la CLI dans CLAUDE.md au lieu de la mentionner dans le chat. Un ID de scénario tapé dans une session disparaît à la fin de celle-ci. Un ID dans CLAUDE.md est là pour chaque membre de l'équipe et chaque exécution de Claude Code à partir de maintenant. Le fichier est chargé entièrement au lancement et survit à un /compact, de sorte que l'instruction reste active pendant toute la session.
Étape 2 : Obtenez la commande depuis Apidog
Les valeurs <scenario_id> et <env_id> dans ce bloc ne sont pas à deviner. Ouvrez votre scénario de test dans Apidog, accédez à l'onglet CI/CD et copiez la commande apidog run ... générée. Elle contient déjà l'ID réel du scénario, l'ID de l'environnement et le reporter -r cli renseignés. Collez ces ID exacts dans votre bloc CLAUDE.md.
Le reporter -r cli affiche un résultat étape par étape et un résumé directement dans le terminal, ce qui est exactement la sortie que Claude Code lit pour décider de sa prochaine étape. Pour une explication complète de chaque option, consultez le guide complet de la CLI Apidog et la référence de la commande apidog run.
Étape 3 : Demandez à Claude Code d'exécuter le test
Une fois le bloc en place, démarrez Claude Code dans votre dépôt :
claude
Claude Code charge CLAUDE.md au démarrage, il sait donc déjà que la CLI est présente. Apportez une modification qui touche votre API, ou demandez-lui simplement d'exécuter la vérification. Claude Code émet la commande apidog run à partir de votre CLAUDE.md.
Ici, le modèle de permissions est important. Dans son mode par défaut, Claude Code demande avant d'exécuter une commande shell qu'il n'a pas vue approuvée. Approuvez la commande apidog run lorsqu'il vous le demande. Pour ne plus être interrogé pour une commande que vous approuvez, ajoutez une règle de permission afin que la CLI s'exécute sans invite : exécutez /permissions dans la session, ou ajoutez une règle d'autorisation pour Bash(apidog run *) dans .claude/settings.json. Un scénario de test en lecture seule contre l'environnement de staging est une commande sûre à ajouter à la liste blanche. Pour les exécutions sans surveillance, il existe --dangerously-skip-permissions, qui ignore complètement les invites ; réservez cela pour l'intégration continue (CI), pas pour votre utilisation quotidienne.
Vous voulez voir l'exécution en cours et Claude Code vous rapporter le résumé et le code de sortie, et pas seulement une phrase affirmant le succès.
Étape 4 : Lisez le rapport dans Claude Code
Quand une exécution échoue (devient rouge), le rapport contient la réponse. Avec -r cli, Claude Code obtient une ventilation lisible dans le terminal : chaque requête, chaque assertion, et laquelle a échoué avec la valeur attendue versus la valeur réelle. L'assertion en échec nomme le champ exact ou le code d'état, ce qui est généralement suffisant pour que Claude Code trouve la correction.
Pour un rapport que vous pouvez ouvrir dans un navigateur ou donner à un coéquipier, ajoutez le reporter HTML :
apidog run -t <scenario_id> -e <env_id> -r cli,html
Le reporter html écrit un fichier autonome dans ./apidog-reports. Conservez cli dans la liste afin que Claude Code reçoive toujours la sortie en ligne qu'il lit pour décider de sa prochaine étape. Pour le format JUnit que les tableaux de bord de CI analysent et les autres reporters, consultez les rapports de test de la CLI Apidog.
Tests de Claude Code à l'intérieur de sa propre boucle
Le but est de voir ce qui se passe lorsque vous arrêtez de demander et que Claude Code exécute le scénario de lui-même parce que CLAUDE.md le lui a dit.
Imaginez Claude Code modifiant un gestionnaire qui construit une réponse de commande. Sa boucle change : il édite le code, puis, au lieu de déclarer victoire, il exécute votre scénario Apidog contre l'environnement de staging, lit le code de sortie et agit en conséquence. Si c'est vert, il continue. Si c'est rouge, il ouvre le rapport, lit quelle assertion a échoué (le code d'état, le champ manquant, la mauvaise valeur), essaie une correction et relance le test. Le test d'API fait partie de la même boucle d'édition-test-correction que Claude Code utilise déjà pour vos tests unitaires. Vous avez écrit une seule instruction et Claude a intégré la commande à son fonctionnement habituel.
C'est le modèle « déléguer-puis-vérifier » qui sécurise tout flux de travail d'agent. Claude Code exécute la commande et lit le résultat ; vous continuez à créer des scénarios visuellement dans Apidog et à vérifier 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 d'API et le harnais de test IA d'Apidog.
Vérifiez que Claude Code exécute réellement la CLI
Les agents signalent des succès qu'ils n'ont pas mérités, et Claude Code ne fait pas exception. Voici trois vérifications, dans l'ordre de la fréquence à laquelle elles détectent des problèmes.
Premièrement, confirmez que la commande a bien été exécutée. Claude Code affiche les commandes qu'il a exécutées et leur sortie en ligne. Recherchez la ligne littérale apidog run ... et un résultat en dessous. Si Claude 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-lui directement : « Quel était le code de sortie de cette commande apidog run ? » apidog run retourne 0 lorsque toutes les assertions sont passées et une valeur non nulle en cas d'échec. Ce comportement unique permet à Claude Code, ou à un pipeline, de considérer l'exécution comme une porte propre. Lorsque le texte de Claude dit « tests réussis » mais que le code de sortie est non nul, c'est le code de sortie qui a raison.
Troisièmement, confirmez qu'il a utilisé le vrai scénario. Si une exécution échoue avec « scénario introuvable », Claude a peut-être inventé ou mal mémorisé un ID. Vérifiez à nouveau les valeurs -t et -e par rapport à CLAUDE.md et à la commande générée par Apidog dans l'onglet CI/CD. Les ID dans CLAUDE.md sont la vérité.
Facultatif : Connectez le serveur MCP d'Apidog
L'exécution de apidog run depuis CLAUDE.md couvre la plupart de vos besoins. Pour aller plus loin, connectez un serveur MCP afin que Claude Code puisse lire votre spécification d'API pendant qu'il écrit du code, et pas seulement tester après coup.
Claude Code prend en charge le protocole Model Context (MCP). Vous ajoutez un serveur avec claude mcp add ... ou en validant un fichier .mcp.json à la racine de votre projet et en choisissant --scope project pour que toute l'équipe en bénéficie. Le serveur MCP Apidog expose vos spécifications d'API via MCP, de sorte que Claude lit votre schéma pendant qu'il code. Considérez cela comme une division du travail : la CLI exécute les tests, le MCP fournit la spécification à l'agent.
Quand Claude Code se trompe
Quelques échecs apparaissent souvent lors de la configuration.
Il ignore le bloc CLAUDE.md. Si Claude exécute une commande générique ou aucune, le bloc peut ne pas être chargé. Confirmez que le fichier est nommé exactement CLAUDE.md et qu'il se trouve à la racine de votre dépôt ou dans un répertoire parent de votre répertoire actuel. Exécutez /memory dans la session pour lister les fichiers que Claude a réellement chargés ; si le vôtre n'y est pas, Claude ne peut pas le voir. Le redémarrage de la session force une nouvelle lecture.
Il transmet tout de même un jeton d'accès. Si Claude tente d'ajouter --access-token, il devine à partir d'exemples publics. Le bloc lui dit déjà de ne pas le faire, puisque la machine est authentifiée via apidog login. Insistez sur cette ligne, et ne mettez jamais de vrai jeton dans CLAUDE.md. Pour savoir comment la machine s'authentifie une fois, consultez l'authentification de la CLI Apidog.
Il invente une option. Une erreur « option inconnue » signifie que Claude 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 qui a échoué. C'est l'erreur la plus coûteuse, et la raison pour laquelle la règle du code de sortie se trouve dans votre CLAUDE.md et votre étape de vérification. Lorsque le résumé et le code de sortie ne concordent pas, le code de sortie l'emporte.
D'un agent quotidien à une boucle testée
Voilà la configuration. Installez apidog-cli une fois en suivant le guide d'installation, ajoutez un court bloc Apidog au CLAUDE.md de votre dépôt, et Claude Code saura comment exécuter vos tests d'API et lire le résultat dans la même boucle qu'il utilise déjà pour éditer le code. Un point de terminaison cassé est détecté pendant que Claude travaille encore sur la modification, et non après son déploiement.
Un test derrière une interface graphique s'exécute quand un humain clique ; une commande d'une ligne s'exécute chaque fois que Claude 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 CLAUDE.md, et regardez Claude l'utiliser lors du prochain changement. Lorsque vous êtes prêt à exécuter la même commande dans un pipeline sans que Claude soit présent, la CLI Apidog dans GitHub Actions couvre les secrets, les reporters et la gestion des codes de sortie.