DEV Community

Cover image for Outils CLI Gratuits Open Source pour le Développement
Antoine Laurent
Antoine Laurent

Posted on • Originally published at apidog.com

Outils CLI Gratuits Open Source pour le Développement

La plupart des flux de travail backend passent encore par le terminal. Les outils qui restent utiles dans le temps partagent souvent les mêmes qualités : code inspectable, licences claires, exécution locale et absence de verrouillage par compte ou par siège. Lorsqu’un projet est sous licence MIT, Apache ou GPL et maintenu publiquement, vous pouvez auditer son code, l’intégrer à votre CI et le forker si nécessaire.

Essayez Apidog dès aujourd’hui

Cette sélection couvre des outils CLI gratuits et réellement open source pour le développement d’API et le backend. Chaque outil dispose d’une licence identifiable, d’un dépôt public et d’un cas d’usage concret : envoyer des requêtes, transformer du JSON, tester des endpoints, automatiser GitHub ou exposer un serveur local.

L’objectif n’est pas de comparer des performances ou des interfaces graphiques. Il s’agit de construire une boîte à outils fiable pour votre boucle quotidienne : requêtes HTTP, inspection de réponses, tests versionnés, automatisation et partage d’un environnement local.

Vérifier qu’un outil CLI est réellement open source

Un outil gratuit n’est pas nécessairement open source. Avant de le standardiser dans un projet, vérifiez ces trois points :

  1. La licence

    Cherchez une licence approuvée par l’OSI, par exemple MIT, Apache 2.0, BSD ou GPL. Elle détermine vos droits d’utilisation, de modification et de redistribution.

  2. Le code source public

    Le dépôt doit être accessible sur GitHub ou une forge équivalente. Vérifiez le fichier LICENSE, les releases et l’activité des commits.

  3. L’absence de verrouillage obligatoire

    Un compte, une télémétrie non désactivable ou un serveur propriétaire imposé sont des signaux à examiner. Pour un composant serveur, vous devez idéalement pouvoir l’exécuter vous-même.

Les étoiles GitHub et la fréquence des commits sont utiles, mais secondaires face à la licence. Un outil stable sous MIT reste souvent un meilleur choix qu’un projet populaire dont la licence restreint certains usages.

curl : la base portable pour les requêtes HTTP

curl est le client HTTP de référence dans les scripts, les conteneurs et les pipelines CI. Il prend en charge de nombreux protocoles, est généralement préinstallé et son code source est disponible sur github.com/curl/curl.

logo curl

Pour envoyer une requête authentifiée depuis un script :

curl -s -X POST https://api.github.com/repos/curl/curl/issues \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title":"Test issue","body":"Filed from curl"}'
Enter fullscreen mode Exit fullscreen mode

Quelques options à utiliser fréquemment :

# Afficher les en-têtes de réponse
curl -i https://api.example.com/health

# Échouer explicitement sur les statuts HTTP 4xx/5xx
curl --fail-with-body https://api.example.com/health

# Enregistrer la réponse dans un fichier
curl -o response.json https://api.example.com/data
Enter fullscreen mode Exit fullscreen mode

Idéal pour : les scripts portables et la CI.

Limite : la sortie brute est peu agréable à lire et le traitement du JSON nécessite généralement un outil complémentaire, comme jq.

HTTPie : des requêtes HTTP lisibles en terminal

HTTPie propose une syntaxe plus ergonomique pour l’exploration manuelle d’API. Le projet est sous licence BSD-3-Clause et disponible sur github.com/httpie/cli.

Installez-le, puis utilisez la commande http :

pip install httpie

http POST httpbin.org/post name=apidog role=platform
Enter fullscreen mode Exit fullscreen mode

Les paires clé=valeur sont envoyées comme données JSON. HTTPie formate également les en-têtes et le corps de réponse.

Ajoutez un jeton Bearer sans écrire manuellement l’en-tête complet :

http GET https://api.example.com/users \
  Authorization:"Bearer $TOKEN"
Enter fullscreen mode Exit fullscreen mode

Envoyez un fichier JSON existant :

http POST https://api.example.com/users \
  < payload.json
Enter fullscreen mode Exit fullscreen mode

Idéal pour : le débogage interactif et l’exploration rapide d’API.

Limite : c’est un paquet Python, donc plus lourd à installer que curl dans certaines images CI minimales.

jq : extraire et transformer du JSON

Les réponses d’API sont souvent volumineuses. jq, sous licence MIT et maintenu sur github.com/jqlang/jq, permet de filtrer, extraire et remodeler du JSON directement dans un pipeline shell.

Par exemple, récupérez uniquement les informations utiles d’un dépôt GitHub :

curl -s https://api.github.com/repos/jqlang/jq \
  | jq '{name: .name, stars: .stargazers_count, license: .license.spdx_id}'
Enter fullscreen mode Exit fullscreen mode

Résultat attendu :

{
  "name": "jq",
  "stars": 0,
  "license": "MIT"
}
Enter fullscreen mode Exit fullscreen mode

Filtrez une liste et ne gardez que certains champs :

curl -s https://api.github.com/users/octocat/repos \
  | jq '.[] | {name, html_url, private}'
Enter fullscreen mode Exit fullscreen mode

Utilisez -r pour produire une sortie texte exploitable dans un script :

curl -s https://api.github.com/repos/jqlang/jq \
  | jq -r '.default_branch'
Enter fullscreen mode Exit fullscreen mode

Idéal pour : convertir une réponse JSON bruyante en données directement exploitables.

Limite : sa syntaxe concise demande un peu de pratique, surtout pour les transformations imbriquées.

gh : automatiser GitHub depuis le terminal

gh est le CLI officiel de GitHub. Écrit en Go, sous licence MIT et disponible sur github.com/cli/cli, il couvre les pull requests, issues, releases, Actions et les appels API.

Commencez par vous authentifier :

gh auth login
Enter fullscreen mode Exit fullscreen mode

Puis utilisez gh api pour appeler l’API GitHub avec votre authentification existante :

gh api repos/cli/cli/releases --jq '.[0].tag_name'
Enter fullscreen mode Exit fullscreen mode

Créez une issue depuis un script :

gh issue create \
  --repo owner/repository \
  --title "Erreur détectée en CI" \
  --body "Le test d'intégration a échoué."
Enter fullscreen mode Exit fullscreen mode

Vérifiez l’état des workflows GitHub Actions :

gh run list --limit 10
Enter fullscreen mode Exit fullscreen mode

Idéal pour : automatiser les opérations GitHub dans des scripts locaux ou une CI.

Limite : il est spécifique à GitHub. Pour GitLab, Gitea ou une forge interne, utilisez leur CLI ou appelez directement leurs API avec curl.

Hurl : versionner des tests HTTP en texte brut

Hurl exécute des requêtes HTTP définies dans des fichiers texte et vérifie les statuts, en-têtes et corps de réponse. Écrit en Rust, sous licence Apache 2.0, il est disponible sur github.com/Orange-OpenSource/hurl.

Créez un fichier repo.hurl :

GET https://api.github.com/repos/Orange-OpenSource/hurl

HTTP 200
[Asserts]
jsonpath "$.name" == "hurl"
jsonpath "$.stargazers_count" > 1000
Enter fullscreen mode Exit fullscreen mode

Exécutez ensuite le test :

hurl --test repo.hurl
Enter fullscreen mode Exit fullscreen mode

Hurl retourne le code 0 si toutes les assertions passent et un code non nul en cas d’échec. Vous pouvez donc l’ajouter directement à une étape CI :

hurl --test tests/*.hurl
Enter fullscreen mode Exit fullscreen mode

Pour chaîner des requêtes, capturez une valeur puis réutilisez-la :

POST https://api.example.com/login
Content-Type: application/json

{
  "email": "dev@example.com",
  "password": "secret"
}

HTTP 200
[Captures]
token: jsonpath "$.token"

GET https://api.example.com/me
Authorization: Bearer {{token}}

HTTP 200
Enter fullscreen mode Exit fullscreen mode

Idéal pour : des tests d’intégration HTTP lisibles, versionnés et exécutables dans la CI.

Limite : Hurl cible les requêtes et réponses HTTP ; ce n’est pas un outil complet de test de charge ou de validation de contrats. Il complète bien une approche de développement d’API « spec-first » basée sur OpenAPI.

cloudflared : exposer rapidement un serveur local

Pour tester un webhook, montrer une démo ou connecter une application mobile à votre machine locale, vous avez besoin d’une URL publique. cloudflared est le client de tunnel de Cloudflare. Il est sous licence Apache 2.0 et son code est disponible sur github.com/cloudflare/cloudflared.

Exposez un serveur local exécuté sur le port 3000 :

cloudflared tunnel --url http://localhost:3000
Enter fullscreen mode Exit fullscreen mode

La commande affiche une URL HTTPS temporaire en *.trycloudflare.com qui redirige vers votre serveur local tant que le processus est actif.

Vérifiez rapidement votre endpoint via l’URL générée :

curl https://your-random-subdomain.trycloudflare.com/health
Enter fullscreen mode Exit fullscreen mode

Si vous préférez une solution basée sur npm, localtunnel, sous licence MIT, fournit une commande équivalente :

npx localtunnel --port 3000
Enter fullscreen mode Exit fullscreen mode

Idéal pour : les webhooks, les démos et les tests ad hoc depuis une machine locale.

Limite : les URLs de tunnel rapide sont aléatoires et temporaires. Des tunnels nommés et stables demandent une configuration Cloudflare.

git : versionner les spécifications et les tests

git est la fondation de cette boîte à outils. Sous licence GPLv2 et développé sur github.com/git/git, il versionne vos spécifications OpenAPI, scripts shell, fichiers Hurl et configurations CI.

Un usage simple mais efficace : exécuter vos tests Hurl avant chaque commit.

echo 'hurl --test *.hurl' > .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit
Enter fullscreen mode Exit fullscreen mode

Pour éviter de versionner ce hook manuellement dans .git/hooks, vous pouvez aussi centraliser vos hooks dans le dépôt :

mkdir -p .githooks

cat > .githooks/pre-commit <<'EOF'
#!/usr/bin/env bash
hurl --test tests/*.hurl
EOF

chmod +x .githooks/pre-commit
git config core.hooksPath .githooks
Enter fullscreen mode Exit fullscreen mode

Idéal pour : versionner et automatiser tout le reste.

Limite : git gère le versioning ; l’hébergement du projet reste un choix distinct entre GitHub, GitLab, Gitea ou une autre forge.

Un aparté honnête : où Apidog s’insère

Apidog n’est pas open source et ne fait donc pas partie de cette liste d’outils OSS. C’est un produit commercial avec un niveau gratuit. Il devient pertinent lorsque vous ne souhaitez pas assembler et maintenir séparément les requêtes, les tests, les mocks, la documentation et les variables d’environnement.

Apidog regroupe conception, tests, simulation et documentation dans un espace de travail. Son CLI apidog-cli apporte ces opérations au terminal.

npm install -g apidog-cli
Enter fullscreen mode Exit fullscreen mode

Le CLI peut exécuter des scénarios de test, gérer des endpoints et schémas, configurer des attentes de mock et importer ou exporter des définitions OpenAPI. Comme Hurl, apidog run retourne un code 0 en cas de succès et un code non nul en cas d’échec, ce qui permet son intégration dans la CI.

Le choix dépend donc de votre priorité :

  • utilisez les outils open source séparés si vous privilégiez le contrôle, le code source accessible et l’absence de verrouillage ;
  • utilisez une plateforme intégrée si vous préférez réduire la maintenance de cette chaîne d’outils.

Pour la voie CLI, le guide d’installation explique l’authentification et les premières commandes.

Choisir les bons outils pour votre workflow

Dans la pratique, vous utiliserez souvent plusieurs outils ensemble :

# Appeler une API, extraire des données et les exploiter dans un script
curl -s https://api.github.com/repos/jqlang/jq \
  | jq -r '.stargazers_count'
Enter fullscreen mode Exit fullscreen mode 
# Tester vos endpoints avant d'envoyer votre code
hurl --test tests/*.hurl && git commit -m "Ajoute les tests API"
Enter fullscreen mode Exit fullscreen mode
Outil Idéal pour Installation Open source ? Notes
curl Requêtes portables, scripting Préinstallé Oui (curl/style MIT) Disponible sur la plupart des systèmes
HTTPie Débogage interactif pip install httpie Oui (BSD-3-Clause) Sortie colorisée, JSON par défaut
jq Analyse des réponses JSON Gestionnaire de paquets ou binaire Oui (MIT) Excellent dans les pipelines
gh Scripting GitHub Gestionnaire de paquets ou binaire Oui (MIT) Spécifique à GitHub
Hurl Tests HTTP versionnés Binaire unique Oui (Apache 2.0) Code non nul en cas d’échec
cloudflared Tunnels publics Binaire unique Oui (Apache 2.0) Tunnel rapide sans compte
git Contrôle de version Préinstallé Oui (GPLv2) Base pour les spécifications et tests
apidog-cli Workflow API intégré npm i -g apidog-cli Non (niveau gratuit) Conception, tests, mocks et documentation

La règle est simple : choisissez un outil spécialisé open source quand vous voulez maîtriser chaque composant, puis passez à une solution intégrée si la maintenance de l’assemblage devient plus coûteuse que le gain de contrôle. Pour comparer cette approche intégrée, consultez l’analyse d’Apidog comme plateforme complète de développement d’API.

Conclusion

curl, HTTPie, jq, gh, Hurl, cloudflared et git couvrent une grande partie du travail quotidien en API et backend. Commencez avec une combinaison minimale :

  1. curl pour les requêtes automatisées ;
  2. jq pour lire les réponses JSON ;
  3. Hurl pour versionner vos tests HTTP ;
  4. git pour intégrer ces fichiers à votre workflow.

Ajoutez HTTPie pour le débogage manuel, gh pour l’automatisation GitHub et cloudflared lorsque vous devez recevoir des callbacks externes sur votre machine locale.

Si vous construisez des workflows pilotés par des agents, privilégiez également les sorties structurées et les commandes reproductibles. Le guide sur les assistants de codage IA pour le développement d’API approfondit ce sujet. Si la maintenance de plusieurs outils devient trop lourde, téléchargez Apidog et testez le CLI d’Apidog pour évaluer l’alternative intégrée.

Top comments (0)