Top outils de test d'API en ligne de commande 2026

Les 10 meilleurs outils de test d’API en ligne de commande en 2026

Les tests d’API ont quitté l’interface graphique (GUI). Ils s’exécutent désormais dans des conteneurs CI sans affichage, sur des environnements de staging accessibles uniquement via SSH et sous des agents IA qui ne comprennent que le shell. Dans ces trois cas, le terminal est l’endroit où un test réussit ou échoue sans surveillance humaine.

Essayez Apidog dès aujourd’hui

Ce tour d’horizon classe les outils qui effectuent un véritable travail de test depuis une invite de commande. Ici, « basé sur le terminal » signifie que tout le processus s’exécute dans un shell : installation depuis un gestionnaire de paquets, exécution d’une commande et lecture d’un code de sortie.

Le classement prend en compte :

• les assertions intégrées ;
• les flux multi-étapes ;
• les rapports compatibles avec la CI ;
• l’état de maintenance du projet.

Les clients manuels comme curl apparaissent plus bas, car les workflows basés sur le terminal s’appuient souvent sur eux entre deux exécutions de tests.

Pour une vue plus large incluant les outils GUI et hébergés, consultez le tour d’horizon des meilleurs outils de test d’API gratuits.

Qu’est-ce qui sépare un outil de test d’un client API ?

Un client terminal envoie une requête et affiche la réponse. Un outil de test terminal évalue cette réponse et renvoie un verdict sous forme de code de sortie, que votre pipeline peut utiliser.

Quatre caractéristiques permettent de les distinguer :

• Assertions intégrées : vérification du statut HTTP, des en-têtes et du corps de réponse sans multiplier les scripts jq.
• Codes de sortie significatifs : zéro en cas de succès, non-zéro en cas d’échec.
• Répétabilité : tests stockés dans des fichiers ou des projets versionnables.
• Rapports : sortie lisible dans le terminal et formats exploitables par la CI, comme JSON, JUnit ou HTML.

Voici les dix outils qui méritent votre attention en 2026.

1. Apidog CLI : création visuelle, exécution sans interface

Apidog est une plateforme API couvrant la conception, le test, le mocking et la documentation.

L’Apidog CLI, disponible sous la forme du paquet npm apidog-cli, permet d’exécuter dans un shell les scénarios créés dans l’éditeur visuel. Ces scénarios peuvent contenir des requêtes enchaînées, des variables extraites et des assertions.

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>

# Copiez la commande exacte depuis l’onglet CI/CD du scénario
apidog run -t <scenario_id> -e <env_id> -r cli

Vous n’avez pas besoin de deviner les identifiants. Ouvrez le scénario dans Apidog, accédez à l’onglet CI/CD, puis copiez la commande générée.

Les reporters disponibles couvrent cli, html, json et junit. Les fichiers sont écrits dans apidog-reports/, ce qui permet d’utiliser la même exécution dans un terminal, un tableau de bord ou un magasin d’artefacts.

Les exécutions basées sur les données peuvent utiliser des fichiers CSV ou JSON. La sortie JSON contient notamment agentHints.nextSteps, afin qu’un agent de codage IA puisse exécuter une suite et déterminer l’étape suivante sans analyser l’écran.

Apidog CLI nécessite Node.js 16 ou une version ultérieure.

Idéal pour : les équipes qui veulent créer des scénarios complexes et multi-étapes dans un éditeur, puis les exécuter de manière identique sur un poste local, en CI ou via des agents.

Limite : Apidog CLI n’est pas open source et n’est pas conçu comme un émetteur HTTP ad hoc. Les scénarios vivent dans un projet Apidog : il s’agit donc d’une plateforme intégrée plutôt que d’un simple outil HTTP.

Consultez le guide complet d’Apidog CLI pour découvrir les commandes disponibles.

2. Hurl : tests en texte brut dans un binaire Rust

Hurl exécute des requêtes HTTP écrites dans un format texte brut et vérifie les réponses. Construit en Rust sur libcurl, il est distribué sous forme de binaire unique : aucun runtime supplémentaire n’est nécessaire.

Les tests sont proches du HTTP brut et restent faciles à relire dans une pull request.

brew install hurl
# Ou :
cargo install --locked hurl

cat > login.hurl <<'EOF'
POST https://api.example.com/login
{ "user": "acme", "pass": "s3cret" }

HTTP 200
[Asserts]
jsonpath "$.token" exists
EOF

# Code de sortie non nul si une assertion échoue
hurl --test login.hurl

Idéal pour : les tests de fumée et les vérifications de contrat stockés dans Git sous forme de texte lisible.

L’option --test en fait un outil adapté à la CI.

Limite : Hurl est centré sur HTTP. Il ne gère donc pas gRPC et ne génère pas de charge. Une logique complexe peut aussi entraîner une multiplication des fichiers .hurl.

3. Newman : exécuter des collections Postman sans interface

Newman est l’exécuteur open source en ligne de commande des collections Postman, sous licence Apache-2.0.

Si votre équipe crée déjà ses requêtes et ses tests dans Postman, vous pouvez exporter la collection et l’environnement au format JSON, puis les exécuter depuis un terminal.

npm install -g newman

newman run collection.json -e staging.json

Idéal pour : les équipes qui utilisent déjà Postman et veulent exécuter leurs collections dans un pipeline sans interface graphique ni sièges supplémentaires.

Newman renvoie un code non nul lorsqu’un test échoue, ce qui permet à la CI de bloquer la build.

Limite : Newman ne fonctionne qu’avec les collections Postman. La création des tests se fait toujours dans l’interface Postman : Newman les exécute, mais ne vous aide pas à les écrire.

4. Postman CLI : l’alternative officielle à Newman

Le Postman CLI est l’exécuteur propriétaire de Postman.

Contrairement à Newman, il se connecte à votre compte Postman et peut exécuter une collection à partir de son identifiant, directement depuis un espace de travail. Les résultats peuvent ensuite être associés au cloud Postman.

postman login --with-api-key <YOUR_API_KEY>

postman collection run <collection_id> -e <environment_id>

Idéal pour : les équipes Postman qui souhaitent lancer des collections liées au cloud sans exporter de fichiers JSON.

Limite : le CLI est propriétaire et dépend d’un compte Postman. La coexistence de Newman et du Postman CLI peut aussi compliquer le choix de l’exécuteur officiel.

La comparaison Postman CLI vs Newman détaille les cas d’utilisation de chacun.

5. Bruno CLI : des collections natives Git exécutées avec bru

Bruno stocke les collections sous forme de fichiers texte .bru dans des répertoires ordinaires. Les requêtes peuvent donc être versionnées et revues comme du code.

Son CLI, @usebruno/cli, exécute les collections depuis le terminal avec la commande bru, sans compte cloud.

npm install -g @usebruno/cli

# Exécute toutes les requêtes de la collection courante
bru run --env staging

Idéal pour : les équipes qui veulent revoir les collections dans les pull requests et les exécuter hors ligne. Les assertions et les scripts sont gérés dans les mêmes fichiers.

Bruno génère des rapports JSON, JUnit et HTML pour la CI.

Limite : l’écriture en texte brut convient davantage aux développeurs qu’aux équipes mixtes. Son écosystème est également plus jeune que celui de Postman.

Découvrez la comparaison Bruno CLI vs Apidog CLI.

6. Schemathesis : laisser le schéma générer les tests

Schemathesis lit un schéma OpenAPI ou GraphQL et génère des milliers de cas de test. Il s’appuie sur le property-based testing de la bibliothèque Python Hypothesis.

Au lieu d’écrire chaque cas manuellement, Schemathesis explore les entrées pour trouver :

• des erreurs 500 ;
• des violations de schéma ;
• des réponses incompatibles avec le contrat documenté ;
• des cas limites non couverts.

pip install schemathesis

schemathesis run https://api.example.com/openapi.json

Idéal pour : détecter des bugs difficiles à anticiper, en particulier avant une mise en production.

Limite : l’outil nécessite un schéma exploitable. Une API importante peut aussi générer suffisamment de cas pour produire du bruit. Il faut alors utiliser des hooks et des options de filtrage.

7. Step CI : un fichier YAML pour les workflows multi-étapes

Step CI décrit un workflow API dans un fichier YAML unique : étapes, valeurs capturées et vérifications.

Il couvre REST, GraphQL, gRPC, tRPC et SOAP dans un même workflow, et peut valider les réponses par rapport à un schéma OpenAPI.

npm install -g stepci

stepci run workflow.yml

Idéal pour : les séquences déclaratives comme « se connecter, récupérer un jeton, puis appeler une ressource protégée ».

Limite : Step CI embarque un environnement Node.js. Son rythme de publication ayant ralenti, vérifiez l’activité récente du dépôt avant de l’intégrer à un nouveau pipeline.

8. curl : la référence déjà installée

curl est fourni avec macOS, la plupart des distributions Linux et les versions récentes de Windows. Dans de nombreux environnements, aucune installation n’est donc nécessaire.

C’est le client de référence pour les requêtes HTTP. Avec -w et quelques scripts shell, il peut aussi servir de banc d’essai minimal.

# Envoie un POST JSON et affiche uniquement le statut HTTP
curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST https://api.example.com/orders \
  -H "Content-Type: application/json" \
  -d '{"sku":"A-102","qty":2}'

Idéal pour : les requêtes ponctuelles, les scripts et les environnements verrouillés où aucun nouveau paquet ne peut être installé.

Limite : les assertions sont à votre charge. Vous devez transmettre la réponse à jq, comparer les valeurs et gérer les codes de sortie manuellement.

curl envoie et affiche des données ; il ne constitue pas à lui seul un exécuteur de tests.

Le guide des alternatives à curl pour les tests d’API REST présente les options adaptées lorsque curl ne suffit plus.

9. HTTPie et xh : des requêtes lisibles à la main

HTTPie rend les requêtes terminales plus lisibles. La commande est http, les champs JSON s’écrivent sous forme de paires key=value, et les réponses sont colorisées et formatées.

xh reprend une syntaxe similaire en Rust sous la forme d’un binaire statique unique. Il propose également l’option --curl, qui affiche la commande curl équivalente.

http POST api.example.com/users name=acme plan=pro
# HTTPie

xh POST api.example.com/users name=acme plan=pro
# Même syntaxe, binaire unique

Idéal pour : explorer une API manuellement pendant que les tests automatisés sont construits ailleurs.

Limite : HTTPie et xh sont des clients, pas des exécuteurs de tests. HTTPie utilise un runtime Python, tandis que xh propose un ensemble de fonctionnalités plus réduit en échange d’un démarrage rapide. Aucun des deux n’effectue d’assertions sur une réponse.

10. k6 : lorsque le problème concerne la charge

k6 répond à une autre question : non pas « cette réponse est-elle correcte ? », mais « l’API tient-elle sous la charge ? ».

k6 est un binaire Go de Grafana, scripté en JavaScript. Ses seuils permettent de transformer un test de charge en porte de réussite ou d’échec. Si un seuil est dépassé, k6 renvoie un code non nul que la CI peut interpréter comme un échec.

brew install k6

k6 run load.js
# Les VUs, la durée et les seuils sont définis dans le script

Idéal pour : les tests de performance versionnés dans le même dépôt que les tests fonctionnels.

Limite : k6 est un outil de charge sous licence AGPL-3.0, pas un client de test fonctionnel. Les scénarios significatifs nécessitent également d’apprendre son API JavaScript.

Préférez-vous une interface interactive ?

Si vous voulez une expérience proche de Postman sans quitter le shell, les clients TUI constituent une catégorie distincte.

Des outils comme atac et posting affichent des éditeurs de requêtes complets directement dans le terminal. Ils sont utiles pour explorer une API, mais ne bloquent pas les pipelines.

Consultez le tour d’horizon des meilleurs clients API REST en terminal et TUI.

Tableau comparatif

Outil	Tâche	Assertions intégrées	Installation	Open source
Apidog CLI	Exécuter des scénarios créés visuellement en CI	Oui	npm i -g apidog-cli	Non, offre gratuite
Hurl	Tests HTTP en texte brut	Oui	brew install hurl	Apache-2.0
Newman	Collections Postman sans interface graphique	Oui	npm i -g newman	Apache-2.0
Postman CLI	Exécutions Postman liées au cloud	Oui	Installateur Postman	Non
Bruno CLI	Collections .bru natives Git	Oui	npm i -g @usebruno/cli	MIT
Schemathesis	Fuzzing à partir d’un schéma	Générées	pip install schemathesis	MIT
Step CI	Workflows multi-étapes YAML	Oui	npm i -g stepci	MPL-2.0
curl	Requêtes brutes et scripts	À faire soi-même	Préinstallé	Oui
HTTPie / xh	Requêtes manuelles lisibles	Non	brew install httpie / xh	Oui
k6	Tests de charge avec seuils	Seuils	brew install k6	AGPL-3.0

Comment choisir le bon outil ?

Commencez par la tâche, pas par l’outil.

• Tests déjà présents dans Postman : utilisez Newman ou le Postman CLI.
• Tests textuels révisables dans Git : choisissez Hurl ou Bruno CLI.
• Schéma OpenAPI solide : ajoutez Schemathesis pour générer des cas et trouver des bugs imprévus.
• Exploration manuelle : gardez curl, HTTPie ou xh.
• Tests de capacité : introduisez k6 lorsque la question passe de la correction à la performance.

Choisissez l’Apidog CLI lorsque vous préférez créer les scénarios dans un éditeur visuel et les exécuter partout ailleurs. C’est la seule option de cette liste où le même projet contient également la conception d’API, les données de mock et la documentation.

Cet avantage est détaillé dans Apidog CLI : le client API qui vit dans votre terminal.

Pour une vue plus large des méthodes utilisées derrière ces choix, consultez le guide des stratégies de test API.

Foire aux questions

Puis-je tester des API entièrement depuis le terminal ?

Oui. Créez les tests sous forme de fichiers avec Hurl, Bruno ou Step CI, ou utilisez un éditeur visuel comme Apidog ou Postman. Vous pouvez ensuite les exécuter sans interface graphique avec le CLI correspondant.

Chaque exécuteur de cette liste renvoie un code de sortie que la CI peut utiliser.

Quelle est la différence entre un client API terminal et un outil de test ?

Un client comme curl, HTTPie ou xh envoie une requête et affiche la réponse.

Un outil de test comme Apidog CLI, Hurl ou Newman effectue des assertions et renvoie un code de sortie non nul en cas d’échec.

Les clients servent à explorer ; les outils de test servent à bloquer un pipeline.

Lesquels de ces outils fonctionnent dans une pipeline CI ?

Tous les exécuteurs suivants peuvent être utilisés dans une CI :

• apidog run
• hurl --test
• newman run
• postman collection run
• bru run
• schemathesis run
• stepci run
• k6 run

Ils renvoient un code non nul en cas d’échec.

Pour un exemple concret, consultez le guide sur l’exécution des tests Apidog CLI dans GitHub Actions.

Certains de ces outils gèrent-ils les tests de charge ?

Oui. k6 est l’outil spécialisé dans la charge et propose des seuils utilisables comme portes de réussite ou d’échec.

Les autres outils vérifient principalement la correction fonctionnelle. De nombreuses équipes associent donc un exécuteur de tests fonctionnels à k6.

Ai-je besoin d’une spécification OpenAPI ?

Seul Schemathesis en exige une, car il génère ses tests à partir du schéma.

Pour les autres outils, une spécification peut faciliter le travail sans être obligatoire. Apidog importe les collections OpenAPI 3.x, Swagger 2.0 et Postman. Step CI peut également valider les réponses par rapport à un schéma.

Conclusion

Le principe est le même pour les dix outils : la création des tests demande du confort, tandis que leur exécution doit fonctionner dans un shell.

Choisissez d’abord l’endroit où vous voulez écrire vos tests, puis vérifiez que l’exécuteur renvoie un code de sortie exploitable par votre pipeline.

Si vous souhaitez réunir ces deux aspects dans une seule plateforme, téléchargez Apidog, construisez un scénario dans l’éditeur et insérez sa commande apidog run dans votre CI.