DEV Community

Cover image for Top alternatives à Postman CLI pour l'automatisation des tests API en intégration continue
Antoine Laurent
Antoine Laurent

Posted on • Originally published at apidog.com

Top alternatives à Postman CLI pour l'automatisation des tests API en intégration continue

L'interface de ligne de commande (CLI) de Postman permet d'exécuter des collections dans un pipeline, mais elle rattache vos tests à un compte Postman et au cloud Postman. Si votre équipe veut exécuter ses tests d'API en CI sans dépendance cloud, sans verrouillage de format ou avec plus de contrôle sur les artefacts, voici cinq alternatives pratiques, avec leurs cas d'usage et des exemples d'intégration. L'Apidog CLI est le choix recommandé si vous voulez concevoir, simuler, tester et documenter vos API dans un même flux. Pour le contexte officiel, consultez aussi la comparaison de Postman entre la Postman CLI et Newman.

Essayez Apidog aujourd’hui

Pourquoi éviter la Postman CLI dans certains pipelines

La Postman CLI est l'outil actuellement recommandé par Postman pour le CI/CD. Elle exécute des collections, remonte les résultats et affiche les exécutions dans l'application Postman.

Ce modèle fonctionne bien si tout votre cycle API est déjà dans Postman. Il devient moins adapté si vous avez des contraintes de conformité, de réseau ou de coût.

Points de friction fréquents :

  • Dépendance au cloud : l'exécution utilise une clé API Postman et les résultats remontent dans l'application Postman.
  • Licences : les collections, environnements et fonctionnalités d'équipe dépendent des niveaux de forfait.
  • Verrouillage : la collection Postman reste la source de vérité. Changer d'outil implique souvent export, conversion et réécriture partielle des tests.

L'objectif n'est donc pas de remplacer Postman partout, mais de choisir un exécuteur CI qui correspond à votre mode de travail : fichier versionné, plateforme API complète, outil open source ou runner minimaliste.

Comparaison rapide

Outil Format de test Compte requis pour l'exécution Licence Idéal pour
Apidog CLI Scénarios/suites de tests Apidog, ou fichiers exportés Non pour l'exécution locale ; jeton pour la synchronisation de projet Commercial, version gratuite Équipes qui conçoivent, simulent, testent et documentent en un seul endroit
Newman JSON de collection Postman Non Open source, Apache-2.0 Utilisateurs Postman existants souhaitant des exécutions hors ligne
Hoppscotch CLI JSON de collection Hoppscotch Non avec export JSON Open source Utilisateurs Hoppscotch et équipes auto-hébergées
inso, Insomnia CLI Suites de tests Insomnia via synchronisation Git Non Open source Équipes Insomnia avec workflow Git
Hurl Fichiers .hurl en texte brut Non Open source Ingénieurs qui veulent des tests HTTP simples et versionnés

1. Apidog CLI

L'Apidog CLI est l'exécuteur en ligne de commande d'Apidog. Il sert à lancer vos scénarios et suites de tests depuis un terminal ou un pipeline CI/CD avec apidog run.

Son intérêt principal est l'alignement avec une source de vérité unique : contrat OpenAPI, scénarios de test, serveur de simulation et documentation vivent dans le même projet. Le test exécuté en CI vérifie donc la même API que celle conçue et documentée.

Exemple d'utilisation en CI

Une commande Apidog CLI suit généralement ce modèle :

apidog run \
  --project-id "$APIDOG_PROJECT_ID" \
  --token "$APIDOG_TOKEN" \
  -r cli,json,junit
Enter fullscreen mode Exit fullscreen mode

Dans GitHub Actions, vous pouvez l'intégrer ainsi :

name: API tests

on:
  push:
    branches: [main]
  pull_request:

jobs:
  api-tests:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Install Apidog CLI
        run: npm install -g apidog-cli

      - name: Run API tests
        env:
          APIDOG_TOKEN: ${{ secrets.APIDOG_TOKEN }}
          APIDOG_PROJECT_ID: ${{ secrets.APIDOG_PROJECT_ID }}
        run: |
          apidog run \
            --project-id "$APIDOG_PROJECT_ID" \
            --token "$APIDOG_TOKEN" \
            -r cli,json,junit
Enter fullscreen mode Exit fullscreen mode

Adaptez la commande exacte à celle générée dans le panneau CI/CD d'Apidog. Le tutoriel CLI étape par étape montre le flux complet.

Cas pratiques

  • Tests basés sur les données : utilisez -d avec un fichier CSV ou JSON pour itérer le même scénario sur plusieurs jeux de données.
  • Rapports CI : utilisez -r cli, -r html, -r json ou -r junit selon votre système de reporting.
  • Simulation d'API : exécutez un serveur de mock basé sur votre schéma pour débloquer les tests frontend ou d'intégration. Le guide de la simulation d'API détaille cette approche.
  • Interopérabilité avec les agents IA : le serveur MCP d'Apidog permet à des outils comme Cursor, Claude ou VS Code d'accéder aux spécifications API.

Apidog propose une version gratuite et une application de bureau Apidog. Pour une comparaison directe, consultez Apidog CLI vs Postman CLI.

2. Newman

Newman est l'exécuteur open source historique des collections Postman. Il lit un fichier JSON de collection Postman et l'exécute depuis la ligne de commande sans lancer l'application Postman.

Exemple d'exécution locale 

npm install -g newman

newman run collection.json \
  -e environment.json \
  --reporters cli,junit \
  --reporter-junit-export reports/newman.xml
Enter fullscreen mode Exit fullscreen mode

Exemple GitHub Actions 

name: Newman tests

on:
  push:
    branches: [main]

jobs:
  newman:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Install Newman
        run: npm install -g newman

      - name: Run collection
        run: |
          mkdir -p reports
          newman run collection.json \
            -e environment.json \
            --reporters cli,junit \
            --reporter-junit-export reports/newman.xml
Enter fullscreen mode Exit fullscreen mode

Quand choisir Newman

Newman est pertinent si :

  • vos tests existent déjà sous forme de collections Postman ;
  • vous voulez exécuter ces collections hors ligne ;
  • vous avez besoin d'un outil open source sous licence Apache-2.0 ;
  • vous voulez bénéficier d'un grand écosystème de reporters et d'exemples CI.

Le compromis : Newman conserve la collection Postman comme artefact central. Si votre objectif est de sortir du modèle collection-first, il ne règle pas ce point. Pour comparer les deux approches, consultez Apidog CLI vs Newman.

3. Hoppscotch CLI

Hoppscotch est un client API open source et auto-hébergeable. Sa CLI, @hoppscotch/cli, permet d'exécuter les tests associés à une collection avec la commande hopp test.

Installation et exécution 

npm install -g @hoppscotch/cli

hopp test collection.json \
  --env environment.json \
  --reporter-junit reports/hoppscotch.xml
Enter fullscreen mode Exit fullscreen mode

Exemple GitHub Actions 

name: Hoppscotch tests

on:
  push:
    branches: [main]

jobs:
  hoppscotch:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Install Hoppscotch CLI
        run: npm install -g @hoppscotch/cli

      - name: Run tests
        run: |
          mkdir -p reports
          hopp test collection.json \
            --env environment.json \
            --reporter-junit reports/hoppscotch.xml
Enter fullscreen mode Exit fullscreen mode

Quand choisir Hoppscotch CLI

Hoppscotch CLI convient si :

  • votre équipe utilise déjà Hoppscotch ;
  • vous préférez un outil open source ;
  • vous avez besoin d'un mode auto-hébergé ;
  • vous voulez exporter vos collections et environnements en JSON pour le CI ;
  • vous voulez produire du JUnit pour vos pipelines.

Si vous comparez aussi l'interface graphique et l'écosystème, consultez le tour d'horizon des alternatives à Hoppscotch.

4. inso, Insomnia CLI

inso est l'outil de ligne de commande de Kong Insomnia. Il exécute les suites de tests créées dans Insomnia et fonctionne bien avec la synchronisation Git d'Insomnia.

Quand cette synchronisation est configurée, vos données Insomnia sont disponibles dans un répertoire .insomnia versionné avec votre code. Vos spécifications, collections et suites de tests deviennent donc des fichiers commités dans le dépôt.

Exemple d'exécution 

inso run test "My API Test Suite"
Enter fullscreen mode Exit fullscreen mode

Vous pouvez l'utiliser dans un pipeline comme ceci :

name: Insomnia tests

on:
  push:
    branches: [main]

jobs:
  inso:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Install inso
        run: npm install -g insomnia-inso

      - name: Run test suite
        run: inso run test "My API Test Suite"
Enter fullscreen mode Exit fullscreen mode

Quand choisir inso

inso est adapté si :

  • votre équipe conçoit déjà ses API dans Insomnia ;
  • vous voulez versionner vos tests avec Git ;
  • vous préférez éviter une dépendance à un cloud fournisseur pour l'exécution ;
  • vous utilisez GitHub Actions, GitLab CI ou Jenkins.

Pour une comparaison ciblée, consultez Apidog CLI vs inso.

5. Hurl

Hurl est un outil CLI qui exécute des requêtes HTTP écrites dans des fichiers .hurl. Le format est en texte brut, proche d'un curl annoté. Hurl est un binaire Rust basé sur libcurl, sans runtime Node ni application graphique à installer.

Exemple de fichier .hurl 

GET https://api.example.com/health
HTTP 200
[Asserts]
jsonpath "$.status" == "ok"
Enter fullscreen mode Exit fullscreen mode

Exécution :

hurl tests/health.hurl
Enter fullscreen mode Exit fullscreen mode

Avec plusieurs fichiers et un rapport JUnit :

hurl tests/*.hurl \
  --test \
  --report-junit reports/hurl.xml
Enter fullscreen mode Exit fullscreen mode

Exemple GitHub Actions 

name: Hurl tests

on:
  push:
    branches: [main]

jobs:
  hurl:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Install Hurl
        run: |
          curl --location --remote-name https://github.com/Orange-OpenSource/hurl/releases/latest/download/hurl_amd64.deb
          sudo apt install ./hurl_amd64.deb

      - name: Run Hurl tests
        run: |
          mkdir -p reports
          hurl tests/*.hurl --test --report-junit reports/hurl.xml
Enter fullscreen mode Exit fullscreen mode

Quand choisir Hurl

Hurl est idéal si :

  • vous voulez des tests HTTP lisibles et versionnés ;
  • vous ne voulez pas de plateforme API complète ;
  • vous préférez un binaire rapide et simple ;
  • vos assertions portent sur les statuts, en-têtes et corps de réponse ;
  • vous voulez une intégration CI triviale via codes de sortie standard.

Hurl ne fournit pas de conception d'API, de serveur de simulation ni de génération de documentation. C'est volontaire : il fait une seule chose, l'exécution de tests HTTP en texte brut. Consultez la documentation officielle de Hurl pour le format complet.

Comment choisir

Choisissez selon l'endroit où votre workflow API existe déjà :

  • Vous avez déjà beaucoup de collections Postman et voulez les exécuter hors ligne : Newman.
  • Vous utilisez Hoppscotch ou avez besoin d'un client auto-hébergeable : Hoppscotch CLI.
  • Vous utilisez Insomnia et voulez un workflow Git-native : inso.
  • Vous voulez des tests HTTP minimalistes, en texte brut, sans plateforme : Hurl.
  • Vous voulez concevoir, simuler, tester et documenter dans un même espace avec un exécuteur CI aligné sur votre contrat API : Apidog CLI.

Si vous traitez votre API comme un produit, la dernière option est souvent la plus durable. Cette approche est détaillée dans API as a product. Le guide des bonnes pratiques CI/CD pour les tests d'API explique aussi comment structurer vos tests dans un pipeline.

Checklist d'intégration CI

Avant de choisir un outil, vérifiez ces points :

  1. Format versionnable

    Vos tests doivent pouvoir vivre dans Git ou être générés de manière reproductible.

  2. Secrets externalisés

    Stockez les jetons, clés API et URLs sensibles dans les secrets CI.

  3. Rapports exploitables

    Privilégiez un export JUnit, JSON ou HTML selon votre plateforme CI.

  4. Codes de sortie fiables

    Le pipeline doit échouer automatiquement si une assertion échoue.

  5. Données de test contrôlées

    Utilisez des fichiers CSV, JSON ou environnements dédiés pour éviter les tests fragiles.

  6. Séparation des environnements

    Ne mélangez pas les endpoints de dev, staging et production dans le même fichier sans variables explicites.

Exemple de structure simple :

api-tests/
  collections/
  environments/
  data/
  reports/
.github/
  workflows/
    api-tests.yml
Enter fullscreen mode Exit fullscreen mode

Foire aux questions

Existe-t-il une alternative gratuite à la Postman CLI ?

Oui. Newman, Hoppscotch CLI, inso et Hurl sont open source et gratuits à utiliser. L'Apidog CLI propose aussi une version gratuite et utilise la même commande apidog run que dans un pipeline payant. Aucun de ces outils ne facture par exécution de pipeline.

Puis-je exécuter mes collections Postman existantes sans la Postman CLI ?

Oui. Newman lit directement le JSON de collection Postman. Apidog peut aussi importer une collection Postman, puis l'exécuter sans interface graphique. Le chemin de migration est expliqué dans comment exécuter des collections Postman en CI sans Newman.

Quelle est la différence entre la Postman CLI et Newman ?

Les deux exécutent des collections Postman depuis la ligne de commande. La Postman CLI se connecte avec une clé API Postman et remonte les exécutions à l'application Postman. Newman est un exécuteur open source autonome qui ne remonte pas les résultats au cloud Postman. Postman a déclaré ne pas prévoir de déprécier Newman.

Quelle alternative est la meilleure pour le CI/CD ?

Cela dépend de votre stack. Pour une plateforme qui couvre conception, simulation, tests et documentation avec un exécuteur prêt pour le CI, l'Apidog CLI est le choix recommandé. Pour un runner textuel minimaliste, Hurl est excellent. Newman, Hoppscotch CLI et inso sont de bons choix si vous utilisez déjà Postman, Hoppscotch ou Insomnia.

En résumé

La Postman CLI fonctionne, mais son intégration au cloud Postman et son modèle de compte ne conviennent pas à toutes les équipes. Newman, Hoppscotch CLI, inso et Hurl couvrent chacun un besoin précis. Si vous voulez un exécuteur relié à une source de vérité unique pour tout le cycle de vie de votre API, essayez l'Apidog CLI. Téléchargez Apidog pour lancer votre premier test en ligne de commande, ou découvrez la plateforme sur Apidog.

Top comments (0)