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

Les tests d'API ont quitté l'interface graphique (GUI). Les tests 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.

Ce tour d'horizon classe les outils qui effectuent un véritable travail de test à partir d'une invite de commande (shell). « Basé sur le terminal » signifie ici que tout le processus s'exécute dans un shell : installation depuis un gestionnaire de paquets, exécution d'une seule commande, lecture d'un code de sortie. Le classement prend en compte les assertions intégrées, les flux multi-étapes, les rapports prêts pour la CI et l'état de maintenance. Les clients manuels comme curl conservent une place vers la fin, car chaque flux de travail basé sur le terminal s'appuie sur eux entre les exécutions de tests. Pour une enquête 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

Un client terminal envoie une requête et vous montre la réponse. Un outil de test terminal évalue la réponse et rapporte le verdict sous forme de code de sortie sur lequel votre pipeline peut se baser. Le second groupe est le cœur de cette liste, et quatre caractéristiques le définissent :

• Assertions intégrées. Les vérifications de statut, d'en-têtes et de corps de réponse appartiennent à l'outil, et non à un tas de code jq.
• Codes de sortie significatifs. Zéro en cas de succès, non-zéro en cas d'échec, afin que la CI échoue la build pour vous.
• Répétabilité. Les tests résident dans des fichiers ou des projets que vous pouvez versionner et réexécuter, pas dans votre historique de shell.
• Rapports. Une sortie qu'un humain peut lire dans le terminal et qu'un tableau de bord peut analyser en JSON, JUnit ou HTML.

Les critères étant définis, voici les dix outils qui méritent votre attention en 2026.

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

Apidog est une plateforme API tout-en-un couvrant la conception, le test, le mocking et la documentation. L'Apidog CLI (apidog-cli sur npm) est son bras terminal. Vous construisez des scénarios de test dans l'éditeur visuel, avec des requêtes enchaînées, des variables extraites et des assertions, puis apidog run les exécute depuis n'importe quel shell et fournit à votre pipeline un code de sortie clair.

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

# Copy the exact command from your scenario's CI/CD tab
apidog run -t <scenario_id> -e <env_id> -r cli

Vous ne devinez pas les identifiants. Ouvrez le scénario dans Apidog, allez à l'onglet CI/CD et copiez la commande générée. Les reporters couvrent cli, html, json et junit, écrits dans apidog-reports/, de sorte que la même exécution alimente un terminal, un tableau de bord et un magasin d'artefacts. Les exécutions basées sur les données extraient les itérations de fichiers CSV ou JSON. La sortie est un JSON structuré avec agentHints.nextSteps, ce qui permet à un agent de codage IA d'exécuter une suite et de décider de sa prochaine action sans 'screen-scraping'. Il nécessite Node.js 16 ou une version ultérieure.

Idéal pour : les équipes qui souhaitent des scénarios complexes et multi-étapes créés dans un éditeur et exécutés de manière identique sur un ordinateur portable, en CI et par des agents. Limite honnête : il n'est pas open source et ce n'est pas un émetteur ad hoc. Les scénarios vivent dans un projet Apidog, il s'agit donc d'une option de plateforme intégrée plutôt qu'un simple outil HTTP. Le guide complet d'Apidog CLI couvre l'ensemble des commandes.

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

Hurl exécute des requêtes HTTP écrites dans un format texte brut et effectue des assertions sur les réponses. Il est construit en Rust sur libcurl et est livré sous forme de binaire unique, il n'y a donc pas de runtime à installer. Les tests se lisent presque comme du HTTP brut, ce qui les rend faciles à revoir 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

hurl --test login.hurl   # sortie non-zéro si une assertion échoue

Idéal pour : les vérifications de style contrat et les tests de fumée que vous conservez en contrôle de version sous forme de texte lisible. L'option --test en fait une passerelle CI naturelle. Limite honnête : il est axé sur HTTP, il ne gérera donc pas gRPC ni ne générera de charge, et une logique complexe signifie plus de fichiers .hurl plutôt qu'un langage de script.

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

Newman est l'exécuteur en ligne de commande open source pour les collections Postman (Apache-2.0). Si votre équipe rédige déjà des requêtes et des tests dans Postman, Newman exécute cette collection exacte depuis un terminal sans interface graphique. Vous exportez la collection et l'environnement au format JSON et indiquez les fichiers à Newman.

npm install -g newman

newman run collection.json -e staging.json

Idéal pour : les équipes utilisant Postman qui souhaitent exécuter des collections existantes dans un pipeline sans sièges supplémentaires. Il sort avec un code non nul lorsqu'un test échoue, ce qui permet à la CI de bloquer proprement. Limite honnête : il n'exécute que les collections au format Postman, et la création se fait toujours dans l'interface graphique de Postman. Il exécute les tests ; il 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 par son ID, directement depuis l'espace de travail, avec des résultats rapportés au cloud de 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 des exécutions liées au cloud sans exporter de fichiers JSON. Limite honnête : il est propriétaire et lié à un compte Postman, et le fait d'avoir deux exécuteurs officiels crée une réelle confusion quant à celui à adopter. La comparaison Postman CLI vs Newman démêle quand chacun est pertinent.

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

Bruno stocke les collections sous forme de fichiers texte brut .bru dans des dossiers ordinaires, de sorte que les requêtes résident dans votre dépôt comme n'importe quel autre code. Son CLI, @usebruno/cli, exécute ces collections depuis le terminal avec la commande bru, sans compte cloud impliqué.

npm install -g @usebruno/cli

# Exécute toutes les requêtes du dossier de collection actuel
bru run --env staging

Idéal pour : les équipes qui souhaitent que les collections soient examinées dans les pull requests et exécutées hors ligne, avec des assertions et des scripts gérés dans les mêmes fichiers. Il génère des rapports JSON, JUnit et HTML pour la CI. Limite honnête : la création en texte brut convient mieux aux développeurs qu'aux équipes mixtes, et l'écosystème est plus jeune que celui de Postman. Voyez comment il se compare à l'exécuteur d'Apidog dans Bruno CLI vs Apidog CLI.

6. Schemathesis : votre schéma écrit les tests

Schemathesis adopte une approche différente : il lit votre schéma OpenAPI ou GraphQL et en génère des milliers de cas de test, en utilisant des tests basés sur les propriétés (property-based testing) construits sur Hypothesis de Python. Au lieu d'écrire chaque cas, vous le laissez 'fuzzer' les entrées pour trouver des erreurs 500, des violations de schéma et des réponses qui rompent le contrat promis par votre documentation.

pip install schemathesis

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

Idéal pour : attraper les bugs de cas limites que personne n'a pensé à tester, surtout avant une publication. C'est l'un des arguments les plus solides pour maintenir un schéma précis. Limite honnête : il a besoin d'un vrai schéma pour fonctionner, et une API importante peut produire du bruit que vous devrez filtrer avec des 'hooks' et des options.

7. Step CI : un fichier YAML par flux multi-étapes

Step CI décrit un flux de travail API dans un seul fichier YAML : étapes, valeurs capturées et vérifications. Il couvre REST, GraphQL, gRPC, tRPC et SOAP dans un seul flux de travail et valide par rapport à un schéma OpenAPI. Le même fichier s'exécute sur un ordinateur portable et dans un pipeline.

npm install -g stepci

stepci run workflow.yml

Idéal pour : les séquences de connexion-puis-utilisation-du-jeton décrites de manière déclarative, sans script. Limite honnête : il embarque un environnement d'exécution Node, et le rythme de publication a ralenti, alors vérifiez l'activité récente du dépôt avant de construire un pipeline dessus.

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

curl est fourni avec macOS, la plupart des distributions Linux et les versions actuelles de Windows, donc l'installation la plus légère est aucune installation. C'est le client de référence auquel tous les autres outils se mesurent, et avec -w et un peu de 'shell glue', il peut servir de banc d'essai minimal.

# 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ù rien de nouveau ne peut être installé. Limite honnête : les assertions sont entièrement à faire soi-même. Vous passez le résultat à jq, comparez les valeurs vous-même et gérez les codes de sortie manuellement. Il envoie et affiche ; il ne teste pas. Le guide des alternatives à curl pour les tests d'API REST couvre ce qu'il faut utiliser quand cela ne suffit plus.

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

HTTPie a rendu les requêtes terminales lisibles : la commande est http, les champs JSON sont des paires key=value, et les réponses sont colorisées et formatées. xh réimplémente cette même syntaxe en Rust sous forme de binaire statique unique, avec un démarrage plus rapide et un drapeau --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, un seul binaire

Idéal pour : explorer une API manuellement pendant que vous construisez les vrais tests ailleurs. Limite honnête : les deux sont des clients, pas des exécuteurs. HTTPie utilise un runtime Python ; xh échange un ensemble de fonctionnalités plus petit contre de la vitesse. Aucun des deux n'effectue d'assertions sur une réponse.

10. k6 : quand la question est la charge

k6 répond à une question différente : non pas « cette réponse est-elle correcte » mais « tient-elle le coup sous le trafic ». C'est un binaire Go unique de Grafana, scripté en JavaScript, avec des seuils qui transforment un test de charge en une passerelle de réussite/échec. Si un seuil est franchi, k6 sort avec un code non nul, que la CI interprète comme un échec.

brew install k6

k6 run load.js   # vus, durée et seuils définis dans le script

Idéal pour : les vérifications de performance qui résident dans le même dépôt que les tests fonctionnels et s'exécutent depuis un ordinateur portable ou un pipeline. Limite honnête : c'est un outil de charge sous licence AGPL-3.0, pas un client de test fonctionnel, et des scénarios significatifs impliquent d'apprendre son API JavaScript.

Préférez-vous quelque chose d'interactif ?

Si vous souhaitez une interface similaire à Postman sans quitter le shell, c'est une catégorie distincte : les clients TUI tels qu'atac et posting affichent des éditeurs de requêtes complets directement dans le terminal. Ils explorent les API ; ils ne bloquent pas les pipelines. Le tour d'horizon des meilleurs clients API REST en terminal et TUI couvre ce côté en profondeur.

Tableau comparatif

Comment choisir

Commencez par la tâche, pas par l'outil. Si les tests existent déjà dans Postman, Newman ou le Postman CLI les exécuteront demain. Si vous souhaitez des tests sous forme de texte révisable dans votre dépôt, Hurl et Bruno CLI sont les meilleurs choix. Si vous avez un schéma OpenAPI solide, ajoutez Schemathesis et laissez-le traquer les bugs que vous n'avez pas prévus. Gardez curl et xh pour la couche manuelle, et introduisez k6 le jour où la question passe de la correction à la capacité.

Choisissez l'Apidog CLI lorsque vous préférez créer des scénarios dans un éditeur visuel et les exécuter partout ailleurs. C'est la seule option ici où le même projet contient également votre conception d'API, vos données de mock et votre documentation, ce qui est l'avantage expliqué dans Apidog CLI : le client API qui vit dans votre terminal. Pour une vision plus large des tests derrière ces choix, le guide des stratégies de test API indique où chaque couche s'intègre.

Foire aux questions

Puis-je tester des API entièrement depuis le terminal ? Oui. Créez des tests sous forme de fichiers (Hurl, Bruno, Step CI) ou dans un éditeur visuel (Apidog, Postman), puis exécutez-les sans interface graphique avec le CLI correspondant. Chaque exécuteur de cette liste renvoie un code de sortie, ce qui est tout ce dont la CI a besoin.

Quelle est la différence entre un client API terminal et un outil de test ? Un client (curl, HTTPie, xh) envoie une requête et affiche la réponse. Un outil de test (Apidog CLI, Hurl, Newman) effectue des assertions sur la réponse et échoue avec un code de sortie non nul. Les clients explorent ; les outils de test bloquent.

Lesquels de ces outils s'exécutent dans les pipelines de CI ? Tous les exécuteurs : apidog run, hurl --test, newman run, postman collection run, bru run, schemathesis run, stepci run, et k6 run sortent tous avec un code non nul en cas d'échec. Pour un exemple de pipeline fonctionnel, voyez comment exécuter les tests Apidog CLI dans GitHub Actions.

Certains de ces outils gèrent-ils les tests de charge ? k6 est le spécialiste de la charge ici, avec des seuils comme portes de réussite/échec. Les autres vérifient la correction, pas la capacité, donc de nombreuses équipes associent un exécuteur fonctionnel à k6.

Ai-je besoin d'une spécification OpenAPI pour utiliser ces outils ? Seul Schemathesis en exige une, car il génère des tests à partir du schéma. Partout ailleurs, une spécification aide plutôt qu'elle ne bloque : Apidog importe les collections OpenAPI 3.x, Swagger 2.0 et Postman, et Step CI peut valider les réponses par rapport à un schéma.

Le schéma est le même pour les dix outils : la création veut du confort, l'exécution veut un shell. Choisissez où vous voulez écrire vos tests, puis assurez-vous que l'exécuteur transmette un code de sortie à votre pipeline. Si vous souhaitez les deux moitiés depuis une seule plateforme, téléchargez Apidog, construisez un scénario dans l'éditeur et insérez sa commande apidog run dans la CI pour boucler la boucle.