La plupart des tutoriels de test d’API vous orientent vers une interface graphique. Mais si vous travaillez dans le terminal, exécutez des tests en intégration continue (CI) ou devez auditer le code de vos outils, une CLI est souvent plus adaptée. Les outils open source vous donnent un binaire auto-hébergeable, une licence vérifiable et des fichiers de configuration versionnés à côté de votre code.
Essayez Apidog dès aujourd’hui
Le critère n’est pas seulement la vitesse ou la taille du binaire : il s’agit de contrôle. Pouvez-vous exécuter l’outil dans votre réseau sans créer de compte ? Son code source est-il publié sous une licence approuvée par l’OSI ? Restera-t-il utilisable si son fournisseur change de tarification ?
Voici huit outils CLI gratuits et open source pour tester des API REST, GraphQL et HTTP, avec leur licence, une commande d’installation et un exemple d’exécution. Pour une sélection plus large incluant des services hébergés, consultez les meilleurs outils de test d’API gratuits. Pour tester des endpoints manuellement depuis le terminal, voyez aussi les alternatives à curl pour les tests d’API REST.
Qu’est-ce qu’un outil CLI open source de test d’API ?
Un outil gratuit n’est pas nécessairement open source. Pour cette sélection, chaque outil doit répondre aux critères suivants :
- Licence open source réelle : code publié sous une licence approuvée par l’OSI, telle que MIT, Apache-2.0, MPL-2.0, AGPL-3.0 ou BSD.
- Exécution locale sans compte : utilisable sur votre poste ou dans un runner CI, sans inscription obligatoire ni dépendance à un serveur externe.
- Projet inspectable : dépôt GitHub public, historique de commits et tickets accessibles pour évaluer l’activité du projet.
Tous les outils listés respectent les deux premiers critères. Dredd ne respecte plus le troisième, car son dépôt est archivé.
La licence est un critère d’implémentation important :
- MIT et Apache-2.0 sont permissives.
- MPL-2.0 applique un copyleft faible aux fichiers modifiés.
- AGPL-3.0 peut imposer des obligations si vous construisez et distribuez un service autour du logiciel.
Lisez toujours la licence avant d’intégrer un outil dans un produit.
Hurl : tests HTTP en texte brut dans Git
Hurl exécute des requêtes HTTP écrites dans des fichiers texte et valide les réponses avec des assertions. Écrit en Rust et basé sur libcurl, il est distribué sous forme d’un binaire unique.
Licence : Apache-2.0
Installation et premier test
brew install hurl
# ou :
cargo install --locked hurl
Créez un fichier login.hurl :
POST https://api.example.com/login
{ "user": "acme", "pass": "s3cret" }
HTTP 200
[Asserts]
jsonpath "$.token" exists
Exécutez-le :
hurl --test login.hurl
Quand l’utiliser
Utilisez Hurl pour les smoke tests et les vérifications de contrat simples, surtout si vous voulez relire les tests facilement dans une pull request.
Limite : Hurl est centré sur HTTP. Il ne couvre pas gRPC et ne sert pas à générer de charge.
Step CI : workflows d’API déclaratifs en YAML
Step CI exécute des workflows YAML conçus pour la CI. Il prend en charge REST, GraphQL, gRPC, tRPC et SOAP, avec validation OpenAPI et tests de charge.
Licence : MPL-2.0
Installation et exécution
npm install -g stepci
Placez vos étapes, validations et captures dans workflow.yml, puis lancez :
stepci run workflow.yml
Quand l’utiliser
Choisissez Step CI lorsque vous voulez décrire un parcours API multi-étapes dans un seul fichier YAML et l’exécuter de façon identique en local et dans votre pipeline.
Limite : MPL-2.0 est une licence à copyleft faible. Modifier les fichiers de Step CI implique de partager ces modifications ; utiliser Step CI pour tester votre application ne crée pas cette obligation.
Schemathesis : tests basés sur les propriétés depuis un schéma
Schemathesis lit un schéma OpenAPI ou GraphQL et génère automatiquement des cas de test. Basé sur Hypothesis pour Python, il fuzz les entrées afin de détecter des erreurs 500, des violations de schéma et des réponses incompatibles avec la documentation.
Licence : MIT
Installation et exécution
uv pip install schemathesis
# ou :
pip install schemathesis
Lancez les tests depuis votre schéma OpenAPI :
schemathesis run https://api.example.com/openapi.json
Quand l’utiliser
Utilisez Schemathesis avant une mise en production pour trouver des cas limites que vous n’auriez pas pensé à écrire à la main.
Limite : l’outil nécessite un schéma fiable. Sur une API volumineuse, vous devrez souvent filtrer les résultats avec ses hooks et ses options.
Dredd : vérifier le contrat entre documentation et API
Dredd vérifie qu’une API en cours d’exécution correspond à sa description OpenAPI ou API Blueprint. Il rejoue les requêtes documentées contre votre backend et compare les réponses à la spécification.
Licence : MIT
Installation et exécution
npm install -g dredd
Exécutez Dredd avec une description API Blueprint et un backend local :
dredd apiary.apib http://127.0.0.1:3000
Quand l’utiliser
Dredd est utile pour détecter les divergences entre votre documentation et votre implémentation.
Limite importante : le dépôt Dredd a été archivé en novembre 2024 et est en lecture seule. Il reste utilisable, mais n’est plus maintenu. Pour un outil basé sur schéma activement maintenu, Schemathesis est un choix plus sûr.
k6 : tests de charge scriptés en JavaScript
k6 est l’outil de test de charge et de performance de Grafana. Vous écrivez des scénarios en JavaScript ou TypeScript, puis son moteur Go les exécute à grande échelle.
Licence : AGPL-3.0
Installation et exécution
brew install k6
Générez un script de départ :
k6 new script.js
k6 run script.js
Quand l’utiliser
Choisissez k6 lorsque votre question est : « Que se passe-t-il avec des centaines ou milliers d’utilisateurs virtuels ? »
Limite : k6 est orienté charge et performance, pas validation détaillée de contrats API. Sa licence AGPL-3.0 implique aussi des obligations à étudier si vous construisez et distribuez un service autour de son code.
Newman : exécuter des collections Postman en CI
Newman est l’exécuteur CLI des collections Postman. Il permet de lancer les mêmes requêtes et scripts de test depuis le terminal ou un pipeline CI, sans interface de bureau.
Licence : Apache-2.0
Installation et exécution
npm install -g newman
Exécutez une collection avec un environnement de staging :
newman run my-collection.json -e staging-environment.json
Quand l’utiliser
Newman est un bon choix si votre équipe possède déjà des collections Postman et veut les intégrer à la CI sans changer de format.
Limite : les tests restent liés au format de collection Postman. Newman exécute les collections ; il ne conçoit pas et ne simule pas les API.
Tavern : tests d’API dans pytest
Tavern est une bibliothèque Python, une CLI et un plugin pytest. Les tests sont décrits en YAML et bénéficient de l’écosystème pytest : fixtures, rapports, exécution parallèle et intégrations CI.
Il prend en charge REST, MQTT et gRPC.
Licence : MIT
Installation et exécution
pip install tavern
Exécutez un test Tavern avec pytest :
pytest test_login.tavern.yaml
Quand l’utiliser
Adoptez Tavern si votre projet utilise déjà Python et pytest, et que vous voulez conserver tests unitaires et tests API dans la même suite.
Limite : pytest est une dépendance structurante. Si votre stack n’est pas Python, cela devient une contrainte.
Venom : suites d’intégration multi-exécuteurs
Venom, développé par OVHcloud, exécute des tests d’intégration avec plusieurs types d’exécuteurs : HTTP, scripts shell, IMAP, web, bases de données, etc. Il utilise des suites YAML et génère des résultats xUnit lisibles par les outils CI.
Licence : BSD modifiée
Installation et exécution
Téléchargez le binaire depuis les versions GitHub, puis lancez une suite :
venom run testsuite.yml
Quand l’utiliser
Venom convient aux scénarios de bout en bout qui combinent, par exemple, un appel API, une vérification de base de données et une commande shell.
Limite : avec de nombreux exécuteurs disponibles, les suites YAML peuvent devenir verbeuses. La documentation suppose souvent que vous composerez votre solution à partir des exemples du dépôt.
Où Apidog s’insère
Apidog n’est pas open source : c’est un produit commercial avec un niveau gratuit. Il ne fait donc pas partie des huit outils précédents.
En revanche, il peut être pertinent si vous préférez un workflow intégré plutôt que maintenir plusieurs outils spécialisés. Apidog réunit conception, tests, mocking et documentation, tandis que apidog-cli permet d’exécuter les tests depuis le terminal et la CI.
npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run --access-token <TOKEN>
La commande retourne 0 en cas de succès et une valeur non nulle en cas d’échec. Sa sortie JSON structurée inclut agentHints.nextSteps, ce qui facilite son traitement dans des scripts ou par un agent IA.
Le guide complet d’apidog-cli détaille les commandes disponibles.
Le compromis est simple :
- Choisissez l’un des outils open source ci-dessus si une licence auditable est une exigence.
- Choisissez une plateforme intégrée si vous voulez limiter le nombre d’outils à assembler et maintenir.
Comment choisir
| Outil | Idéal pour | Installation | Open source ? | Licence |
|---|---|---|---|---|
| Hurl | Assertions HTTP lisibles dans Git | brew install hurl |
Oui | Apache-2.0 |
| Step CI | Workflows CI déclaratifs | npm i -g stepci |
Oui | MPL-2.0 |
| Schemathesis | Fuzzing basé sur les propriétés depuis un schéma | pip install schemathesis |
Oui | MIT |
| Dredd | Tests de contrat documentation vs implémentation | npm i -g dredd |
Oui, archivé | MIT |
| k6 | Charge et performance | brew install k6 |
Oui | AGPL-3.0 |
| Newman | Collections Postman en CI | npm i -g newman |
Oui | Apache-2.0 |
| Tavern | Tests API dans pytest | pip install tavern |
Oui | MIT |
| Venom | Suites d’intégration multi-exécuteurs | Versions GitHub | Oui | BSD |
| apidog-cli | Workflow intégré de la conception au test | npm i -g apidog-cli |
Non, niveau gratuit | Commercial |
Faites correspondre l’outil au besoin :
- Hurl ou Newman pour des vérifications de requêtes rapides et lisibles.
- Schemathesis si vous avez un schéma et voulez générer automatiquement des cas limites.
- k6 pour mesurer la charge et la performance.
- Tavern ou Venom si les tests API doivent s’intégrer à une suite de tests plus large.
- Step CI pour décrire des workflows d’API multi-étapes en YAML.
Pour positionner ces outils dans une stratégie plus large, consultez les stratégies de test d’API et les outils de test d’API sans interface graphique.
En résumé
Les outils CLI open source permettent de lire, versionner, forker et exécuter vos tests d’API selon vos propres contraintes.
- Hurl et Newman couvrent les vérifications de requêtes courantes.
- Schemathesis et Dredd vérifient le contrat API.
- k6 traite la performance.
- Tavern et Venom intègrent les tests API dans des suites plus larges.
Choisissez selon la licence, votre stack et le type de test à automatiser. Il est aussi courant de combiner plusieurs outils dans le même pipeline.
Si vous préférez concevoir, tester, simuler et documenter au même endroit, Apidog couvre l’ensemble du cycle de vie et fournit apidog-cli pour la CI. Téléchargez Apidog pour tester le CLI en parallèle des outils ci-dessus et choisir la combinaison adaptée à votre pipeline.
Top comments (0)