DEV Community

Cover image for Top outils CLI légers pour le développement
Antoine Laurent
Antoine Laurent

Posted on • Originally published at apidog.com

Top outils CLI légers pour le développement

La journée d’un développeur backend est souvent une boucle courte : appeler un endpoint, inspecter le JSON, ajuster le code, puis recommencer. Des outils CLI rapides réduisent cette boucle en évitant les interfaces lourdes, les écrans de configuration et les changements de contexte.

Essayez Apidog dès aujourd’hui

L’objectif n’est pas de remplacer tous les outils graphiques, mais de disposer d’un kit minimal dans votre PATH pour les tâches récurrentes : envoyer des requêtes HTTP, filtrer une réponse JSON, exposer un serveur local, relancer des tests et démarrer des dépendances jetables.

Ce guide présente 10 outils CLI utiles pour le développement backend. Pour replacer ces outils dans un workflow complet, consultez ce guide sur le développement d’API.

Qu’est-ce qu’un outil CLI léger ?

Un outil CLI est léger lorsqu’il réduit la friction entre son installation et son premier résultat utile. Évaluez-le selon quatre critères :

  • Installation simple : privilégiez un binaire unique ou un petit paquet npx plutôt qu’un outil qui impose un runtime, un projet ou un lockfile.
  • Démarrage rapide : un outil appelé dans une boucle de développement doit répondre presque instantanément.
  • Configuration minimale : vous devez pouvoir exécuter une commande utile sans créer de compte, de fichier de projet ou de tableau de bord.
  • Composabilité Unix : l’outil doit lire depuis stdin, écrire vers stdout et retourner des codes de sortie exploitables en script ou en CI.

Les outils ci-dessous sont complémentaires. curl est souvent déjà installé ; les autres s’ajoutent rapidement à votre environnement.

1. curl : le client HTTP universel

curl est la référence pour les requêtes HTTP scriptables. Utilisez-le pour tester un endpoint, automatiser une vérification de santé ou reproduire une requête dans un ticket.

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"}'
Enter fullscreen mode Exit fullscreen mode

Options utiles à mémoriser :

  • -s : masque la barre de progression.
  • -i : affiche les en-têtes HTTP.
  • -w '%{http_code}' : affiche le code de statut.
  • --fail : retourne un code non nul pour les réponses 4xx et 5xx, utile en CI.

Exemple de vérification CI :

curl --fail --silent --show-error https://api.example.com/health
Enter fullscreen mode Exit fullscreen mode

Idéal pour : les scripts shell, les health checks CI et les requêtes partageables.

Limite : la syntaxe devient verbeuse pour les corps JSON et les requêtes complexes.

2. HTTPie : des requêtes lisibles à la main

HTTPie fournit une interface plus ergonomique que curl pour l’exploration manuelle d’API. Le JSON est géré naturellement et la sortie est formatée.

http POST httpbin.org/post name=apidog role=api-tool active:=true
Enter fullscreen mode Exit fullscreen mode

Cette commande envoie :

{
  "name": "apidog",
  "role": "api-tool",
  "active": true
}
Enter fullscreen mode Exit fullscreen mode

Rappels de syntaxe :

  • clé=valeur définit une chaîne.
  • clé:=valeur définit une valeur JSON brute.
  • Header:valeur ajoute un en-tête HTTP.

Par exemple :

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

Idéal pour : explorer une API depuis le terminal avec une sortie lisible.

Limite : HTTPie est un paquet Python ; son démarrage est généralement moins rapide qu’un binaire natif.

3. xh : l’ergonomie d’HTTPie, en binaire Rust

xh reprend la syntaxe pratique d’HTTPie dans un binaire Rust autonome. Les expressions name=value et name:=value fonctionnent de la même manière.

xh POST httpbin.org/post name=apidog age:=24
Enter fullscreen mode Exit fullscreen mode

Vous obtenez une expérience similaire à HTTPie, avec une installation sans runtime Python et un démarrage rapide. xh prend également en charge HTTP/2 et HTTP/3.

Installez-le avec Cargo :

cargo install xh
Enter fullscreen mode Exit fullscreen mode

Des binaires précompilés sont aussi disponibles via le projet xh sur GitHub.

Idéal pour : les conteneurs, les images CI et les scripts qui nécessitent un client HTTP interactif mais léger.

Limite : il ne couvre pas nécessairement tous les plugins de l’écosystème HTTPie.

4. jq : extraire des données JSON sans écrire de code

jq transforme une réponse JSON en données directement exploitables dans un shell. C’est l’outil à associer à curl, xh ou HTTPie.

curl -s https://api.github.com/repos/stedolan/jq | jq '.stargazers_count'
Enter fullscreen mode Exit fullscreen mode

Pour extraire une liste de noms :

curl -s https://api.example.com/projects | jq '.items[] | .name'
Enter fullscreen mode Exit fullscreen mode

Pour filtrer les objets actifs :

curl -s https://api.example.com/projects | jq '.items[] | select(.active)'
Enter fullscreen mode Exit fullscreen mode

Utilisez -r lorsque vous avez besoin d’une valeur brute dans une variable shell :

API_URL=$(curl -s https://api.example.com/config | jq -r '.apiUrl')
Enter fullscreen mode Exit fullscreen mode

Idéal pour : filtrer, transformer et chaîner des réponses JSON dans des scripts ou pipelines CI.

Limite : les transformations JSON complexes peuvent devenir difficiles à lire. Gardez vos filtres courts ou placez-les dans un fichier.

5. gh : automatiser GitHub depuis le terminal

gh encapsule les opérations GitHub courantes : pull requests, issues, releases, workflows CI et appels API authentifiés.

Connectez-vous une fois :

gh auth login
Enter fullscreen mode Exit fullscreen mode

Créez ensuite une pull request depuis votre branche courante :

gh pr create \
  --title "Ajouter une limitation de débit" \
  --body "Ferme #42" \
  --base main
Enter fullscreen mode Exit fullscreen mode

Commandes utiles pour une boucle de livraison :

gh pr checks
gh run watch
gh api repos/{owner}/{repo}/issues
Enter fullscreen mode Exit fullscreen mode

gh api est particulièrement utile lorsque les sous-commandes intégrées ne couvrent pas un endpoint GitHub spécifique.

Idéal pour : automatiser les PR, suivre la CI, créer des releases et appeler l’API GitHub sans gérer manuellement les jetons.

Limite : il est spécifique à GitHub.

6. ngrok : exposer localhost pour les webhooks

ngrok crée un tunnel sécurisé entre un port local et une URL publique. C’est particulièrement utile pour recevoir des webhooks de services tiers pendant le développement.

ngrok http 8080
Enter fullscreen mode Exit fullscreen mode

Cette commande expose votre serveur local sur le port 8080 via une URL publique HTTPS.

Vous pouvez ensuite configurer cette URL dans un fournisseur de paiement, un service Git ou une application OAuth. ngrok fournit aussi un inspecteur de trafic local :

http://127.0.0.1:4040
Enter fullscreen mode Exit fullscreen mode

Utilisez-le pour inspecter et rejouer les requêtes reçues.

Idéal pour : le développement de webhooks, les démonstrations et les tests de callbacks tiers.

Limite : le niveau gratuit utilise une URL qui peut changer entre les sessions et applique des limites.

7. mkcert : du HTTPS local sans avertissement navigateur

mkcert génère des certificats locaux de confiance. Il évite les certificats auto-signés que le navigateur rejette ou signale comme non sûrs.

mkcert -install
mkcert localhost 127.0.0.1 myapp.local
Enter fullscreen mode Exit fullscreen mode

La première commande installe une autorité de certification locale. La seconde génère un certificat et une clé pour les noms indiqués.

Vous pouvez ensuite les transmettre à votre serveur de développement ou proxy inverse :

your-server \
  --tls-cert localhost+2.pem \
  --tls-key localhost+2-key.pem
Enter fullscreen mode Exit fullscreen mode

C’est utile pour tester localement :

  • les cookies Secure,
  • les redirections OAuth,
  • les Service Workers,
  • les comportements spécifiques à HTTPS.

Idéal pour : reproduire un environnement HTTPS réaliste en local.

Limite : n’utilisez jamais les certificats mkcert en production et protégez la clé de l’autorité de certification locale.

8. watchexec : relancer automatiquement tests et serveurs

watchexec surveille vos fichiers et relance une commande lorsqu’ils changent. Il fonctionne avec n’importe quel langage et respecte .gitignore par défaut.

Pour relancer les tests Python après chaque modification :

watchexec -e py -r 'pytest tests/'
Enter fullscreen mode Exit fullscreen mode

Pour redémarrer un serveur Go :

watchexec -r 'go run .'
Enter fullscreen mode Exit fullscreen mode

Pour relancer une suite JavaScript :

watchexec 'npm test'
Enter fullscreen mode Exit fullscreen mode

L’option -r redémarre les processus longs au lieu de les empiler.

Idéal pour : accélérer la boucle édition-exécution sans dépendre d’un mode watch propre à un framework.

Limite : watchexec redémarre les processus ; il ne fait pas de rechargement à chaud et ne conserve pas leur état.

9. Docker CLI : lancer des dépendances jetables

Docker est plus lourd que les autres outils de cette liste, mais sa CLI permet de démarrer rapidement des services locaux reproductibles : PostgreSQL, Redis, RabbitMQ ou toute autre dépendance conteneurisée.

docker run --rm \
  -e POSTGRES_PASSWORD=dev \
  -p 5432:5432 \
  postgres:16
Enter fullscreen mode Exit fullscreen mode

Votre application peut alors se connecter à :

postgresql://postgres:dev@localhost:5432/postgres
Enter fullscreen mode Exit fullscreen mode

Les options utilisées :

  • --rm supprime le conteneur lorsqu’il s’arrête.
  • -e définit une variable d’environnement.
  • -p expose un port du conteneur sur votre machine.

Même principe avec Redis :

docker run --rm -p 6379:6379 redis:7
Enter fullscreen mode Exit fullscreen mode

Idéal pour : lancer des dépendances locales et des environnements de test sans installer de services persistants sur votre machine.

Limite : Docker nécessite un démon, de la mémoire et de l’espace disque.

10. apidog-cli : exécuter les tests API depuis votre projet

Lorsque vos endpoints, schémas, environnements et scénarios de test sont déjà définis dans un projet API, vous pouvez les exécuter depuis le terminal avec apidog-cli.

Apidog fournit cette CLI sous forme de paquet npm :

npm install -g apidog-cli
apidog login --with-token <VOTRE_TOKEN>
apidog run -t <scenario_id> -e <env_id> -r cli
Enter fullscreen mode Exit fullscreen mode

La commande apidog run exécute un scénario enregistré contre un environnement donné et affiche les résultats dans le terminal. Elle retourne 0 si toutes les assertions réussissent et un code non nul en cas d’échec : vous pouvez donc l’ajouter directement à une étape CI.

Exemple :

apidog run \
  -t "$APIDOG_SCENARIO_ID" \
  -e "$APIDOG_ENV_ID" \
  -r cli
Enter fullscreen mode Exit fullscreen mode

La CLI couvre aussi plusieurs groupes de commandes :

  • endpoint et schema pour la conception ;
  • import et export pour les spécifications OpenAPI, Swagger ou Postman ;
  • mock pour les attentes de simulation ;
  • environment et variables pour la configuration.

La sortie est structurée en JSON avec agentHints.nextSteps, ce qui la rend exploitable par des assistants de codage IA pour le développement d’API.

Consultez le guide complet d’Apidog CLI pour les commandes disponibles, puis le guide d’installation d’Apidog CLI pour votre première exécution.

Idéal pour : exécuter des scénarios de test API en CI et gérer les ressources d’un projet dans des scripts, notamment dans une approche de développement d’API spec-first.

Note : Apidog est un produit commercial avec un niveau gratuit et n’est pas open source. La CLI apidog-cli est la partie légère ; la plateforme Apidog fournit l’interface graphique reposant sur le même projet.

Comment choisir votre kit

Ces outils ne s’excluent pas. Un workflow backend courant peut ressembler à ceci :

# 1. Démarrer une dépendance locale
docker run --rm -d -p 6379:6379 redis:7

# 2. Lancer l’application avec redémarrage automatique
watchexec -r 'go run .'

# 3. Exposer l’application pour recevoir un webhook
ngrok http 8080

# 4. Vérifier une réponse API et extraire une valeur
curl -s http://localhost:8080/health | jq '.status'

# 5. Exécuter les scénarios API du projet
apidog run -t "$APIDOG_SCENARIO_ID" -e "$APIDOG_ENV_ID" -r cli
Enter fullscreen mode Exit fullscreen mode
Outil Idéal pour Installation Open source ?
curl Requêtes scriptées, vérifications de santé CI Préinstallé Oui, licence curl
HTTPie Requêtes interactives lisibles pip install httpie Oui, BSD
xh Ergonomie HTTPie, vitesse native cargo install xh ou binaire Oui, MIT
jq Filtrer les réponses JSON brew install jq ou binaire Oui, MIT
gh Automatiser les PR et la CI GitHub brew install gh ou binaire Oui, MIT
ngrok Exposer localhost, tester les webhooks Télécharger le binaire Non, freemium
mkcert Certificats HTTPS locaux de confiance brew install mkcert ou binaire Oui, BSD
watchexec Réexécuter lors d’une modification de fichier cargo install watchexec-cli Oui, Apache-2.0
Docker CLI Services de support jetables Installation Docker Oui, Apache-2.0
apidog-cli Scénarios de test et gestion de projet API npm install -g apidog-cli Non, freemium

Choisissez selon la tâche :

  • Envoyer des requêtes : xh ou HTTPie en interactif ; curl dans les scripts.
  • Lire des réponses JSON : jq.
  • Exposer un port local : ngrok.
  • Utiliser HTTPS en local : mkcert.
  • Relancer à chaque sauvegarde : watchexec.
  • Démarrer des services de support : Docker.
  • Exécuter les tests API du projet : apidog-cli.

En résumé

Un bon kit CLI backend est composé de petits outils rapides et composables :

  • curl et xh envoient les requêtes ;
  • jq extrait les données utiles ;
  • ngrok et mkcert gèrent l’accès local ;
  • watchexec accélère la boucle édition-exécution ;
  • Docker fournit une infrastructure locale jetable ;
  • apidog-cli relie vos scripts aux scénarios et ressources de votre projet API.

Téléchargez Apidog pour configurer un projet, puis pilotez ses tests et environnements depuis la CLI dans votre pipeline CI.

Top comments (0)