C'est quoi curl (et comment ça marche) ?

Publié le 13 octobre 2026

Dans une documentation d'API, il y a presque toujours un bloc qui commence par curl. On le copie, on le colle dans un terminal, parfois ça marche, parfois ça renvoie une erreur qui ne veut rien dire. Voici ce que cet outil fait réellement, et comment lire une commande sans la copier aveuglément.

Client URL, mais pas seulement

curl est l'abréviation de Client URL. L'outil a été créé en 1996 par Daniel Stenberg, à une époque où récupérer le contenu d'une URL depuis un terminal n'avait rien d'évident. Le nom est resté, même si l'outil fait aujourd'hui bien plus que ça.

Il envoie des requêtes POST, PUT, DELETE. Il gère des cookies, des certificats, des proxys, de l'authentification, des uploads, du FTP, du SMTP. La liste des protocoles supportés est longue. Le nom n'a pas suivi, et ce n'est pas très grave.

Un client HTTP sans interface

La définition la plus simple : curl est un client HTTP en ligne de commande. Il envoie des requêtes réseau et affiche la réponse, sans interface graphique.

Quand un navigateur ouvre une page, il fait une requête HTTP, reçoit une réponse, et l'affiche. curl fait la même chose, mais dans le terminal. La différence, c'est qu'il ne rend pas le HTML, il ne charge pas les images, il n'exécute pas le JavaScript. Il montre la réponse brute.

C'est ce qui en fait un outil utile pour déboguer. Quand une API renvoie une erreur incompréhensible à travers un framework, curl permet de voir ce que le serveur a réellement répondu, sans la couche de magie au-dessus.

            # La requête la plus simple possible :

            curl https://example.com

            # Affiche le HTML brut de la page dans le terminal.

Les options qui reviennent tout le temps

curl a des centaines d'options. Dans la pratique, une dizaine suffit pour la grande majorité des usages.

Option	Ce qu'elle fait	Exemple
`-X`	Choisir la méthode HTTP (GET, POST, PUT, DELETE…)	`-X POST`
`-H`	Ajouter un en-tête HTTP	`-H "Content-Type: application/json"`
`-d`	Envoyer des données dans le corps	`-d '{"nom":"Alice"}'`
`-i`	Afficher les en-têtes de réponse en plus du corps	`-i`
`-I`	Afficher seulement les en-têtes (requête HEAD)	`-I`
`-o`	Écrire la sortie dans un fichier	`-o page.html`
`-O`	Télécharger un fichier en gardant son nom d'origine	`-O`
`-L`	Suivre les redirections	`-L`
`-s`	Mode silencieux (pas de barre de progression)	`-s`
`-v`	Mode verbeux (affiche toute la conversation HTTP)	`-v`

Un exemple concret

Un appel à une API météo publique ressemble à ça :

            curl -s
            "https://api.open-meteo.com/v1/forecast?latitude=48.85&longitude=2.35¤t_weather=true"
          

La commande envoie une requête GET à l'API d'Open-Meteo, avec des coordonnées géographiques (Paris ici), et demande la météo actuelle. Le -s évite l'affichage de la barre de progression. La réponse arrive en JSON, directement dans le terminal.

Pour un appel POST avec des données :

            curl -X POST https://httpbin.org/post \

              -H "Content-Type: application/json" \

              -d '{"nom":"Alice","ville":"Lyon"}'

httpbin.org est un service qui renvoie simplement ce qu'on lui envoie. Pratique pour tester une requête sans dépendre d'une vraie API.

libcurl, ce qui tourne derrière

curl le programme n'est qu'une interface. Derrière, il y a libcurl, une bibliothèque écrite en C qui fait tout le travail réseau. C'est cette bibliothèque qui est intégrée dans des milliers d'applications : des jeux, des navigateurs, des outils de CI/CD, des frameworks, des objets connectés.

Quand un logiciel envoie une requête HTTP, il y a de bonnes chances que ce soit libcurl qui soit derrière. C'est probablement l'une des bibliothèques les plus déployées au monde, parce qu'elle est stable, portable, et qu'elle gère une quantité impressionnante de protocoles.

curl, navigateur, Postman

Ces trois outils font des choses similaires, mais dans des contextes différents.

	curl	Navigateur	Postman
Interface	Ligne de commande	Graphique	Graphique
Exécute le JavaScript	Non	Oui	Non
Scriptable	Oui, nativement	Non	Partiellement
Installé par défaut	Oui (Linux, macOS, Windows 10+)	Oui	Non
Idéal pour	Déboguer, automatiser, tester une API	Utiliser le web au quotidien	Organiser des collections de requêtes

Le navigateur est conçu pour afficher des pages, pas pour inspecter des réponses d'API. Postman est pratique pour organiser des collections, mais il faut l'installer et il ajoute une couche d'interface. curl est déjà là, il fait une seule chose et il la fait bien.

Les pièges classiques

Les guillemets qui changent tout

Sur Windows, PowerShell et l'invite de commandes ne gèrent pas les guillemets de la même façon que Bash ou Zsh. Une commande curl copiée depuis une documentation Unix peut échouer sur Windows, non pas parce que curl est différent, mais parce que le shell interprète mal les apostrophes et les guillemets.

⚠ Sur Windows, curl est un alias de Invoke-WebRequest dans PowerShell. La commande existe, mais ce n'est pas le vrai curl. Pour utiliser le vrai binaire, il faut taper curl.exe explicitement. Sinon, les options ne sont pas les mêmes et les messages d'erreur n'ont rien à voir.

Oublier `-X POST`

Par défaut, curl fait une requête GET. Si des données sont envoyées avec -d sans préciser -X POST, curl bascule normalement en POST automatiquement. Mais ce n'est pas toujours le cas selon les versions et les configurations. Préciser la méthode évite les surprises.

Ne pas voir les erreurs

Par défaut, curl n'affiche pas les erreurs HTTP (404, 500…). Il affiche la réponse, même si elle est vide. Pour voir le code de statut, il faut ajouter -i ou -w "%{http_code}". Sans ça, une requête qui échoue peut passer inaperçue.

            # Afficher seulement le code de statut HTTP :

            curl -s -o /dev/null -w
            "%{http_code}" https://example.com

            # 200 si tout va bien, 404, 500… sinon.

Les redirections non suivies

Si une URL redirige vers une autre (http vers https, par exemple), curl ne suit pas la redirection par défaut. Il affiche la réponse de la première requête, qui est souvent une page vide ou un message du serveur. L'option -L règle le problème.

Pourquoi il est utilisé partout dans les documentations

Il y a plusieurs raisons, et elles expliquent pourquoi curl reste incontournable près de trente ans après sa création.

Il est installé par défaut. Sur Linux et macOS, curl est présent depuis des années. Sur Windows 10 et 11, il est inclus nativement. Une documentation qui utilise curl fonctionne partout, sans installation préalable.

Il est scriptable. Une commande curl peut être mise dans un script shell, un fichier de CI/CD, un cron, un Makefile. C'est un outil qui s'intègre naturellement dans des chaînes d'automatisation.

Il ne cache rien. Là où un navigateur ou un framework ajoute des couches (cookies, cache, JavaScript, en-têtes automatiques), curl envoie exactement ce qui est demandé et affiche exactement ce qui est reçu. C'est ce qui en fait un outil de débogage fiable.

Il gère énormément de protocoles. HTTP, HTTPS, FTP, FTPS, SFTP, SMTP, IMAP, POP3, LDAP, WebSocket. La liste est longue. C'est rare d'avoir un outil qui couvre autant de terrain avec une interface aussi simple.

✓ Lire une commande curl avant de la coller. Quelle méthode HTTP ? Quels en-têtes ? Quelles données ? Est-ce que la réponse est affichée ou enregistrée dans un fichier ? Dix secondes de lecture évitent bien des surprises, surtout quand la commande vient d'une documentation écrite pour un autre système d'exploitation.

Pour résumer

curl est un client HTTP en ligne de commande. Il envoie des requêtes réseau et affiche la réponse, sans interface graphique et sans exécuter de JavaScript. Il est installé par défaut sur la plupart des systèmes, il est scriptable, et il gère une quantité impressionnante de protocoles.

C'est pour ça qu'il apparaît dans presque toutes les documentations d'API : c'est le plus petit dénominateur commun entre tous les environnements de développement. Une commande curl fonctionne sur Linux, macOS et Windows, sans dépendance, sans installation, sans configuration.