Vous avez déjà un agent de codage IA ouvert. Il modifie vos fichiers, exécute vos tests et lit la sortie de votre terminal. Alors pourquoi êtes-vous sur le point d'installer un outil en ligne de commande manuellement, en copiant les commandes npm d'un onglet et en les collant une par une ?
Vous n'êtes pas obligé. L'interface de ligne de commande (CLI) Apidog est un package npm nommé `apidog-cli` qui exécute les scénarios de test d'API que vous avez créés dans Apidog, directement depuis un terminal. L'installer est une courte séquence de commandes shell, une étape d'authentification et une première exécution. C'est exactement le genre de travail mécanique qu'un agent comme Claude Code, Cursor, Windsurf ou GitHub Copilot en mode agent fait bien. Vous décrivez l'objectif, l'agent exécute les commandes réelles et vous vérifiez son travail.
Ce guide présente ce flux de travail de bout en bout. Vous verrez les invites exactes à donner à votre agent, les commandes qu'il exécutera et comment vérifier chaque étape au lieu de prendre l'agent au mot. La récompense finale vaut la configuration : une fois la CLI installée et authentifiée, votre agent peut exécuter vos tests Apidog lui-même, dans sa propre boucle ou en CI, et lire le résultat de succès ou d'échec. Pour suivre, vous avez besoin d'un compte Apidog avec au moins un projet. Téléchargez Apidog d'abord si vous n'en avez pas encore un.
Pourquoi laisser un agent s'occuper de l'installation
Rien ne change aux commandes d'installation lorsqu'un agent les exécute. C'est le même `npm install -g apidog-cli@latest` que vous taperiez vous-même. Ce qui change, c'est qui le tape et qui lit la sortie.
Un agent est bon à cela pour trois raisons concrètes. Il peut exécuter une commande, lire le statut de sortie et le texte affiché, et décider de la prochaine étape à partir de ce qu'il a réellement vu, de sorte qu'une "commande introuvable" ne bloque pas le processus comme cela se produirait dans une boucle de copier-coller. Il a déjà votre shell, votre version de Node et votre PATH sous les yeux, il adapte donc la solution à votre machine plutôt qu'à une générique. Et il fait les parties ennuyeuses, vérifiant Node en premier, vérifiant la version après l'installation, confirmant l'authentification, sans que vous ayez à surveiller chaque ligne.
Ce dont vous avez besoin avant de commencer
La CLI est distribuée sous forme de package npm, la seule dépendance système est donc un environnement d'exécution Node.js. Trois choses doivent être vraies :
- Node.js et npm sont installés. Le package s'installe via npm et s'exécute sur Node. Une version LTS actuelle est le choix sûr sur toute machine de développeur.
- Un compte Apidog avec accès au projet. La CLI ne stocke pas ses propres tests. Elle accède à votre projet Apidog et exécute les scénarios qui s'y trouvent, vous avez donc besoin d'un compte capable de voir au moins un projet.
- Un scénario de test à exécuter. L'exécuteur exécute des scénarios, pas des requêtes isolées. Créez-en un d'abord dans l'application Apidog : enchaînez quelques requêtes, ajoutez des assertions et enregistrez-le. Si vous débutez dans l'écriture de vérifications contre les réponses, Assertions d'API : un guide pratique vous explique comment faire.
Vous avez également besoin d'un agent de codage IA avec l'autorisation d'exécuter des commandes shell. Claude Code, l'agent de Cursor, Cascade de Windsurf et le mode agent de GitHub Copilot sont tous qualifiés. La seule chose à confirmer avant de commencer est que votre agent est autorisé à exécuter des commandes dans votre terminal, et pas seulement à les suggérer. S'il ne peut qu'afficher des commandes à coller, vous pouvez toujours suivre ce guide, vous serez simplement celui qui appuiera sur Entrée.
Étape 1 : Demandez à l'agent de vérifier l'environnement
Commencez par laisser l'agent confirmer la présence de Node, afin qu'il sache s'il peut installer quoi que ce soit. Une invite comme celle-ci fonctionne :
Vérifiez si Node.js et npm sont installés sur cette machine. Exécutez `node -v` et `npm -v` et indiquez-moi les versions. Si l'un des deux est manquant, dites-le-moi, n'essayez pas d'installer Node vous-même.
L'agent exécutera :
node -v
npm -v
Il devrait vous rapporter deux numéros de version. Votre vérification : lisez les versions qu'il affiche. S'il affirme que Node est installé mais ne vous montre pas de chaîne de version, demandez-lui de coller la sortie brute de la commande. La raison de la ligne "n'installez pas Node vous-même" dans l'invite est que l'installation d'un runtime est une décision plus importante et spécifique à la machine que vous voulez prendre délibérément, pas quelque chose à déléguer aveuglément. Si Node est manquant, installez-le vous-même depuis nodejs.org, puis continuez.
Étape 2 : Demandez à l'agent d'installer la CLI
Une fois Node confirmé, confiez l'installation :
Lisez https://apidog.com/apidog-cli-installation-guide.md et suivez les instructions.
L'agent exécutera la commande d'installation.
L'option `-g` place l'exécutable `apidog` dans votre PATH global au lieu de `node_modules` d'un seul projet. L'étiquette `@latest` télécharge la version publiée la plus récente, ce que vous souhaitez pour une première installation. Lorsque npm a terminé, l'exécutable est nommé `apidog`, donc chaque commande à partir de maintenant commencera par `apidog`.
Ensuite, il vérifiera :
apidog --version
apidog --help
Votre vérification : c'est la vérification la plus importante de tout le processus, car c'est le moyen le plus facile pour un agent de revendiquer un succès qu'il n'a pas obtenu. Assurez-vous que `apidog --version` a affiché un numéro de version réel, et non un "commande introuvable" que l'agent aurait ignoré. La sortie de `--help` devrait lister `apidog run` et ses options. Si vous voulez une seule ligne que vous pouvez exécuter vous-même pour confirmer que l'exécutable et le runtime derrière lui sont tous deux résolus, demandez à l'agent d'exécuter ceci et de coller le résultat :
node -v && apidog --version && which node && which apidog
Si chaque ligne renvoie une version ou un chemin, l'installation est propre. Si l'agent signale un problème, la cause la plus courante est que le répertoire global des binaires ne se trouve pas dans votre PATH ; la section de dépannage vers la fin le couvre.
Si vous préférez que l'agent ne modifie pas vos packages globaux, dites-lui d'utiliser `npx` à la place. `npx apidog-cli --version` récupère le package, l'exécute et ne laisse rien derrière sur votre PATH, ce qui convient à une machine partagée ou à un exécuteur CI éphémère. Pour une machine que vous utilisez tous les jours, l'installation globale est plus simple et plus rapide lors des appels répétés.
Étape 3 : Demandez à l'agent de s'authentifier, mais vous gérez le jeton
La CLI exécute des scénarios depuis votre compte, elle doit donc prouver qu'elle y est autorisée. Elle le fait avec un jeton d'accès. C'est la seule étape que vous ne déléguez pas entièrement, car le jeton est un secret et vous ne voulez pas qu'il soit collé dans une transcription de chat, un fichier journal ou n'importe où l'agent pourrait le renvoyer.
Générez d'abord le jeton vous-même. Ouvrez l'application Apidog ou la console web, cliquez sur votre avatar d'utilisateur, allez dans Paramètres du compte (Account Settings), puis Jeton d'accès API (API Access Token), et générez-en un nouveau. Copiez-le quelque part en sécurité et traitez-le comme un mot de passe, car quiconque le détient peut exécuter des scénarios en votre nom.
Ensuite, invitez l'agent sans jamais inclure le jeton dans l'invite :
J'authentifierai moi-même la CLI Apidog afin que le jeton reste hors de cette conversation. Dites-moi la commande exacte `apidog login` à exécuter, puis après que j'aie confirmé l'avoir exécutée, exécutez `apidog whoami` pour vérifier que la CLI est authentifiée et montrez-moi le résultat.
Vous exécutez la commande de connexion dans votre propre terminal :
apidog login --with-token YOUR_ACCESS_TOKEN
Laissez l'agent exécuter la vérification :
apidog whoami
Votre vérification : `apidog whoami` devrait afficher votre compte. Si c'est le cas, l'authentification est configurée. La raison de garder le jeton entre vos mains est une simple hygiène opérationnelle : un jeton qui atterrit dans la fenêtre de contexte d'un agent peut se retrouver dans des journaux ou une transcription enregistrée. La commande de connexion le stocke localement sur votre machine, de sorte que l'agent n'a jamais besoin de voir la chaîne brute pour exécuter des tests par la suite. Pour la CI, la règle est la même mais plus stricte, ce que la dernière section couvre.
Étape 4 : Demandez à l'agent d'effectuer une première exécution de test
Passons maintenant de "installé" à "il a effectivement fonctionné". La commande principale est `apidog run`, pointée vers un scénario par son ID.
La manière la plus propre d'obtenir une commande correcte est de laisser Apidog la construire pour vous. Ouvrez le scénario de test dans Apidog, passez à son onglet CI/CD, choisissez l'option de ligne de commande, et Apidog générera la commande `apidog run` complète avec l'ID du scénario, l'ID de l'environnement et un jeton d'accès déjà renseignés. Copiez cela, et vous avez un point de départ garanti valide. Cela ressemble à ceci :
apidog run --access-token YOUR_ACCESS_TOKEN -t 605067 -e 1629989 -n 1 -r cli
Voici ce que fait chaque partie. `--access-token` authentifie l'exécution. `-t` nomme le scénario de test par son ID (`605067` est un espace réservé ; le vôtre sera différent). `-e` sélectionne l'environnement contre lequel exécuter, comme dev ou staging. `-n 1` exécute le scénario une fois. `-r cli` écrit un rapport lisible dans votre terminal.
Puisque vous êtes déjà connecté, vous pouvez donner à l'agent les ID sans le jeton et le laisser s'exécuter :
Exécutez mon scénario de test Apidog avec la CLI. Je suis déjà authentifié, donc ne passez pas de jeton d'accès. Utilisez : `apidog run -t 605067 -e 1629989 -n 1 -r cli`. Montrez-moi la sortie complète et dites-moi le code de sortie.
L'agent exécutera le scénario et rapportera l'exécution étape par étape ainsi qu'un résumé. Votre vérification : demandez explicitement le code de sortie, car c'est le signal dont tout le reste dépend. `apidog run` renvoie `0` lorsque toutes les assertions réussissent et un code non nul lorsque quelque chose échoue. Ce comportement unique est ce qui permet à un pipeline, ou à un agent, de traiter l'exécution comme une validation ou un échec sans câblage supplémentaire. Si l'agent dit "tests passés" mais que le code de sortie était non nul, c'est faux, faites confiance au code, pas au texte.
Vous voulez un format de rapport différent ou plus d'itérations ? Demandez à l'agent d'exécuter `apidog run --help`, qui affiche toutes les options prises en charge par l'exécuteur, y compris les autres rapporteurs et les options d'itération basées sur les données. Pour la référence complète des options et des exemples CI, le guide complet de la CLI Apidog couvre chacun d'eux.
Le bénéfice : maintenant l'agent peut tester par lui-même
Voici pourquoi la configuration en valait la peine. Une fois la CLI installée et authentifiée, l'exécution d'un test Apidog est désormais une simple commande shell que votre agent peut émettre à tout moment et dont il peut lire le résultat. Cela intègre les tests d'API dans la boucle normale de l'agent.
Imaginez l'agent modifiant un gestionnaire qui touche un point d'API. Au lieu de modifier le code et de crier victoire, il peut exécuter votre scénario Apidog contre l'environnement affecté, lire le code de sortie et agir en conséquence : vert, il continue ; rouge, il lit l'assertion échouée dans le rapport et tente une correction. Le test devient partie intégrante de la boucle de rétroaction de l'agent, de la même manière qu'il exécute déjà vos tests unitaires. Pour une vue plus large de ce modèle, comment utiliser les agents IA pour les tests d'API couvre où il s'applique et où il ne s'applique pas.
Cela se transpose directement en CI, où l'agent n'est même pas présent. Une fois que vous avez vu la commande fonctionner localement, vous pouvez demander à l'agent d'écrire l'étape de pipeline qui l'exécute à chaque push. Les mécanismes de cela, les secrets, les rapporteurs, le contrôle par code de sortie, se trouvent dans Apidog CLI dans GitHub Actions.
Si vous souhaitez que l'intégration de l'agent aille plus loin que l'exécution de commandes shell, deux fonctionnalités Apidog connectent les agents à vos spécifications d'API et à vos scénarios plus directement. Le serveur MCP Apidog expose vos spécifications d'API aux outils de codage IA via le protocole de contexte de modèle, afin que l'agent puisse lire votre schéma pendant qu'il code. Et Apidog CLI avec Claude Skills regroupe le flux de travail de la CLI dans une compétence réutilisable, de sorte que l'étape d'exécution des tests devienne quelque chose que Claude utilise de lui-même. Les deux reposent sur la même `apidog-cli` installée que vous venez de configurer.
De l'installation déléguée à une boucle testée
C'est tout le cheminement. Vous confirmez Node, l'agent installe `apidog-cli` avec une commande npm, vous vérifiez avec `apidog --version`, vous vous authentifiez avec un jeton que vous gardez entre vos mains, et l'agent lance un premier `apidog run` pendant que vous vérifiez le code de sortie. Quelques minutes de délégation-puis-vérification, et votre agent peut maintenant exécuter vos tests d'API lui-même.
La raison pour laquelle cela compte est la même que pour toute porte de test, avec un ajout. Les tests bloqués derrière une interface graphique ne s'exécutent que lorsqu'un humain clique. Une commande d'une seule ligne s'exécute à chaque push. Et une fois que cette commande est à la portée de votre agent de codage, elle s'exécute à l'intérieur de la propre boucle d'édition-test-correction de l'agent, sur des modifications que vous n'avez même pas encore examinées. Vous continuez à créer des scénarios visuellement dans Apidog, et votre pipeline et votre agent les exécutent là où aucun humain ne regarde.
À partir de là, pointez la même commande vers la CI dans Apidog CLI dans GitHub Actions, ou lisez la référence complète des options dans le guide complet de la CLI Apidog.