J’ai passé un nombre absurde de nuits à déboguer des scripts censés juste « récupérer un fichier et passer à autre chose ». Dans neuf cas sur dix, le problème venait de cURL : il faisait exactement ce que je lui avais demandé, pas ce que je voulais vraiment. En réalité, il y a un vrai fossé entre « curl -O fonctionne » et « curl -O fonctionne de manière fiable en production ».
C’est précisément ce que ce guide va combler. cURL est préinstallé sur macOS, la plupart des distributions Linux et Windows 10 et versions ultérieures, ce qui signifie que tu l’as très probablement déjà sur ta machine. Mais entre les redirections qui passent à la trappe, les mystérieux 403 et le passage de « télécharger un fichier » à « en télécharger 500 sans faire exploser le terminal », il y a largement de quoi se retrouver bloqué. Je vais passer en revue les options qui comptent, les commandes pas à pas que j’utilise réellement, les erreurs qui piègent le plus souvent, et le moment où cURL ne peut vraiment plus aider — ainsi que les outils à utiliser à la place.
Qu’est-ce que cURL et pourquoi s’y intéresser ?
cURL est un outil libre et open source en ligne de commande qui permet de transférer des données vers ou depuis un serveur via une URL. Il parle HTTP, HTTPS, FTP, SFTP et bien d’autres protocoles, ce qui explique pourquoi on le retrouve partout : scripts bash, Dockerfiles, pipelines CI, etc. En interne, la commande curl que tu tapes dans ton terminal s’appuie sur libcurl, la bibliothèque C de transfert que de nombreuses applications et liaisons de langage intègrent. L’extension cURL de PHP en est un exemple ; la populaire bibliothèque Requests de Python est, elle, un client HTTP distinct basé sur urllib3, et non sur libcurl.
La version stable actuelle au moment d’écrire ces lignes est curl 8.21.0, publiée en juin 2026 — mais ne pars pas du principe que ton système fournit exactement cette build. Les versions paquetées par les distributions prennent souvent du retard sur le projet amont de plusieurs mois, parfois plus, donc mieux vaut lancer curl --version avant d’imaginer qu’une option comme --parallel est disponible.
Pourquoi télécharger des fichiers avec cURL ? Cas d’usage principaux
On me demande souvent pourquoi quelqu’un utiliserait un outil en ligne de commande alors que les navigateurs téléchargent très bien les fichiers. La réponse honnête : les navigateurs sont parfaits… jusqu’au moment où il faut automatiser quoi que ce soit.
| Cas d’usage | Pourquoi cURL est excellent |
|---|---|
| Télécharger des binaires dans des pipelines CI/CD | Scriptable, sans interface graphique |
| Récupérer des réponses d’API ou des exports de données | Gère les en-têtes personnalisés, l’authentification et le chaînage vers d’autres commandes |
| Reprendre de gros téléchargements via SSH | Reprise intégrée (-C -) |
| Automatiser des téléchargements récurrents (cron) | Léger, facile à combiner avec des scripts shell |
| Récupérer des fichiers protégés | Options d’authentification flexibles (basic, token, cookies, .netrc) |
Un téléchargement via navigateur, c’est une action ponctuelle, manuelle. cURL transforme cette même action en quelque chose que tu peux planifier, enchaîner dans un pipeline, relancer en cas d’échec et exécuter à l’identique sur cent serveurs à la fois. C’est tout l’intérêt : ce n’est pas plus « sophistiqué », c’est simplement reproductible.
Les options cURL essentielles pour télécharger des fichiers
Je reviens sans cesse à une douzaine d’options pour 90 % de ce que je fais. Voici la fiche mémo que j’aurais aimé qu’on me donne il y a des années, classée selon leur utilité réelle.
Options de sortie et d’enregistrement
-O(--remote-name) enregistre le fichier avec la dernière partie de l’URL comme nom de fichier. Pratique, mais cela peut écraser silencieusement un fichier existant du même nom.-o <filename>(--output) te permet de choisir exactement le nom local :curl -o report.pdf https://example.com/downloads/file.pdf.-J(--remote-header-name) utilise le nom de fichier fourni dans l’en-têteContent-Dispositiondu serveur, au lieu de celui de l’URL. Très pratique pour les téléchargements via API, mais considère les noms envoyés par le serveur comme non fiables — télécharge dans un dossier dédié plutôt que dans ton dossier personnel, conformément aux consignes de sécurité de curl.
Options de comportement indispensables pour tout téléchargement
-L(--location) demande à curl de suivre les redirections HTTP. Sans cela, une réponse 3xx peut être enregistrée comme une petite page HTML de redirection au lieu du vrai fichier — c’est l’erreur « pourquoi mon téléchargement est cassé » la plus fréquente que je vois.-C -(--continue-at -) reprend un téléchargement interrompu là où il s’est arrêté.-s/-Sexécutent en mode silencieux tout en affichant les erreurs — idéal pour les scripts où tu ne veux pas polluer les logs avec une barre de progression.--limit-rate 1Mlimite la bande passante (utile sur une connexion partagée ou si tu ne veux pas monopoliser un réseau mesuré).--connect-timeout 10et--max-time 300empêchent une connexion bloquée de figer ton script indéfiniment.--retry 3et--retry-delay 5relancent automatiquement en cas d’échec temporaire — selon la page de manuel de curl, associe cela à--retry-all-errorsuniquement si répéter strictement la même requête est réellement sans risque.
Options de progression et de débogage
-#affiche une barre de progression simple au lieu du tableau de statistiques par défaut.-vaffiche une sortie verbeuse, y compris tous les en-têtes de requête/réponse — mon réflexe quand quelque chose se comporte mal.-I(--head) récupère uniquement les en-têtes de réponse, ce qui constitue un excellent contrôle préalable avant de lancer un gros téléchargement.-wpermet d’afficher une sortie personnalisée après le transfert, par exemplecurl -o /dev/null -s -w "%{http_code}\n" <url>pour vérifier seulement un code de statut.
Avant de commencer
- Niveau : Débutant à intermédiaire (les sections sur les téléchargements en lot et l’authentification sont un peu plus avancées)
- Temps nécessaire : Environ 15 à 20 minutes pour parcourir les commandes essentielles
- Ce qu’il vous faut : Un terminal (Terminal macOS, shell Linux ou PowerShell/WSL sous Windows), curl installé (vérifie avec
curl --version), et une URL de test — j’utiliserai un asset public d’une release GitHub comme exemple, car il est stable et librement accessible
Comment télécharger des fichiers avec cURL : étape par étape
Étape 1 : télécharger un fichier unique
Les bases absolues : curl -O <url> enregistre le fichier sous son nom d’origine, tandis que curl -o myfile.zip <url> te permet de le renommer au passage.
curl -LO https://github.com/curl/curl/releases/download/curl-8_21_0/curl-8.21.0.tar.gz
J’ajoute désormais systématiquement -L, sans exception — je me suis trop souvent fait piéger par une redirection qui transformait en silence mon « téléchargement » en fichier HTML de 400 octets. Tu devrais voir un indicateur de progression monter dans le terminal, puis le fichier apparaître dans le répertoire courant.
Quand la commande réussit, l’indicateur atteint 100 % et curl-8.21.0.tar.gz apparaît dans le dossier actuel. Vérifie le fichier avant de l’utiliser :
ls -lh curl-8.21.0.tar.gz
Étape 2 : télécharger et renommer le fichier
Utilise -o quand tu veux un nom local précis au lieu de celui qui se trouve à la fin de l’URL :
curl -L -o curl-latest.tar.gz -S https://github.com/curl/curl/releases/download/curl-8_21_0/curl-8.21.0.tar.gz
Le -S réactive l’affichage des erreurs au cas où tu aurais aussi passé -s ailleurs dans un script. Cette combinaison — -L -o <nom> -S — est en gros ma commande par défaut pour télécharger un seul fichier.
Étape 3 : reprendre un téléchargement interrompu
Si un gros téléchargement s’arrête à mi-parcours (wifi instable, VPN qui décroche, peu importe), ne recommence pas depuis zéro. Lance :
curl -C - -LO https://example.com/large-file.iso
Point important : cela ne fonctionne que si le serveur accepte les requêtes par plages d’octets. Accept-Ranges: bytes est un bon signal positif, mais son absence ne prouve pas que les plages ne sont pas supportées. Le vrai test fiable est la réponse du serveur à une requête réelle de plage : une reprise correcte renvoie normalement 206 Partial Content avec un Content-Range valide. Lance la commande de reprise et inspecte le statut avec -v ou -D - ; si le serveur ignore la plage ou rejette l’offset, recommence proprement plutôt que de supposer que le fichier partiel est exploitable.
Étape 4 : télécharger avec une barre de progression ou en mode silencieux
Pour un affichage plus propre dans un terminal interactif : curl -# -LO <url>. Pour les scripts et les tâches cron, quand tu veux uniquement les erreurs et pas le reste : curl -sS -LO <url>. J’utilise presque partout la version silencieuse, sauf quand je débogue à la main.
Étape 5 : limiter la vitesse de téléchargement
Sur une connexion de bureau partagée — ou quand je ne veux pas être « cette personne » qui sature la bande passante pendant un appel vidéo — je limite ainsi :
curl --limit-rate 1M -LO https://example.com/big-dataset.zip
Les unités sont K, M et G pour kilooctets, mégaoctets et gigaoctets par seconde, respectivement.
Étape 6 : enregistrer les en-têtes de réponse en même temps que le fichier
Parfois, j’ai besoin de savoir exactement ce que le serveur a renvoyé — type de contenu, en-têtes de cache, etc. — sans encombrer le terminal :
curl -L -D headers.txt -o file.zip https://example.com/file.zip
Cela écrit les en-têtes de réponse dans headers.txt tandis que le fichier lui-même est enregistré dans file.zip. Très utile pour déboguer des incohérences de type MIME ou vérifier qu’un CDN met bien en cache ce qu’il est censé mettre en cache.
Conseils et pièges courants
- Conseil : Utilise
-Lpar défaut. Je n’arrive sincèrement pas à voir un inconvénient à l’inclure, et j’ai perdu des heures à l’oublier. - Conseil : Dans un script, combine
--failavec ta commande de téléchargement pour qu’une réponse non 2xx fasse réellement échouer le script au lieu d’enregistrer silencieusement une page d’erreur comme si c’était le bon fichier. - Piège : N’associe pas
-C -avec--remove-on-error— curl documente ces options comme incompatibles, car la reprise a besoin que le fichier partiel soit toujours présent. - Piège :
-Opeut écraser des fichiers sans prévenir. Si tu télécharges en lot dans un dossier partagé, utilise--output-dirpour garder les choses bien rangées.
Comment télécharger plusieurs fichiers et gérer des téléchargements en lot avec cURL
Les exemples à fichier unique sont la partie facile. Les vrais workflows que j’ai construits — récupération d’exports de données nocturnes, synchronisation de binaires entre serveurs de build — exigeaient de la concurrence, et c’est là que la plupart des tutoriels s’arrêtent… Trois approches valent vraiment la peine d’être connues, chacune un cran plus complexe que la précédente.
Approche 1 : plusieurs URL dans une seule commande cURL
L’option la plus simple consiste à lister les URL :
curl -LO https://example.com/a.zip -LO https://example.com/b.zip -LO https://example.com/c.zip
Ça fonctionne, mais c’est séquentiel : curl termine entièrement un fichier avant de commencer le suivant. Parfait pour trois fichiers, pénible pour trois cents.
Approche 2 : téléchargements parallèles avec --parallel (curl 7.66+)
Depuis curl 7.66, tu peux ajouter --parallel (ou -Z) pour récupérer plusieurs URL simultanément :
curl --parallel --parallel-max 5 --remote-name-all \
https://example.com/a.zip https://example.com/b.zip https://example.com/c.zip
À noter : la limite parallèle par défaut est en réalité de 50, ce qui représente beaucoup plus de connexions simultanées que la plupart des serveurs — ou ton réseau — ne te remercieront d’utiliser. Je préfère préciser --parallel-max de façon explicite et prudente — généralement entre 4 et 8 — plutôt que de faire confiance au réglage par défaut.
Approche 3 : xargs et boucles Bash pour obtenir de la concurrence à partir d’une liste d’URL
Pour une longue liste d’URL dans un fichier texte, j’utilise souvent xargs :
cat urls.txt | xargs -n1 -P 8 curl -O -L
Ou, si je veux plus de contrôle sur chaque tâche, une boucle Bash avec processus en arrière-plan :
while read -r url; do
curl -O -L "$url" &
done < urls.txt
wait
Le wait à la fin est essentiel — sans lui, le script se termine avant que les téléchargements en arrière-plan soient finis.
Quand utiliser plutôt wget ou aria2
Soyons clairs : cURL n’est pas toujours le bon outil. Si tu dois refléter toute l’arborescence d’un site web, wget -r fait du crawl récursif nativement, d’une manière que cURL n’a tout simplement pas été conçu pour faire. Si tu as besoin de téléchargements multi-sources et segmentés pour maximiser le débit sur un très gros fichier, aria2c est réellement plus rapide.
| Outil | Idéal pour |
|---|---|
| cURL | Précision, scripts, téléchargements d’un seul fichier ou en petit lot, interaction avec des API |
| wget | Téléchargements récursifs/miroirs de sites, récupération simple de fichiers statiques en volume |
| aria2 | Téléchargements multi-sources/segmentés, débit maximal sur de gros fichiers |
La force de cURL a toujours été la précision et la composabilité — le piping, les scripts, la flexibilité des protocoles — pas le crawling à force brute.
Comment télécharger des fichiers protégés avec cURL : modèles d’authentification
La plupart des tutoriels cURL s’arrêtent à -u user:pass et considèrent que c’est suffisant. C’est un héritage d’un web plus ancien. En 2026, les fichiers que je télécharge vraiment proviennent d’API REST, de tableaux de bord basés sur des sessions et de systèmes CI — et chacun demande un type d’identifiant différent.
Authentification basique
curl -u username:password -O https://legacy-server.example.com/file.zip
Correct pour d’anciens serveurs FTP ou des points d’accès HTTP simples. Sache juste que le mot de passe apparaît dans l’historique de ton shell et dans la liste des processus si tu n’es pas prudent — pas ce que j’utiliserais pour quelque chose de sensible.
Authentification par jeton Bearer / OAuth
C’est celle qui est étonnamment peu couverte dans la plupart des guides, et pourtant celle que j’utilise le plus souvent aujourd’hui :
curl -H "Authorization: Bearer $GITHUB_TOKEN" \
-LO https://api.github.com/repos/curl/curl/releases/assets/12345
C’est un vrai modèle pour récupérer un asset privé de release GitHub — remplace simplement le jeton et l’ID de l’asset. Les API REST et les ressources protégées par OAuth2 parlent désormais quasiment toutes ce langage.
Authentification de session basée sur les cookies
Pour les applications web où la connexion crée une session, enregistre le cookie jar à la connexion puis réutilise-le pour le téléchargement :
curl -c cookies.txt -d "user=me&pass=secret" https://example.com/login
curl -b cookies.txt -O https://example.com/protected/file.zip
Fichier .netrc pour les scripts et les environnements CI
Ma méthode préférée pour tout ce qui s’exécute sans surveillance. Crée un fichier ~/.netrc (ou _netrc sous Windows) :
machine example.com
login myusername
password mypassword
Sécurise-le avec chmod 600 ~/.netrc, puis utilise :
curl --netrc -LO https://example.com/protected-file.zip
L’avantage, c’est que les identifiants ne passent jamais par l’historique du shell ni par le code source du script — un point réellement important en CI/CD, où les scripts sont souvent journalisés intégralement.
| Méthode d’authentification | Option / option de ligne de commande | Idéal pour |
|---|---|---|
| Auth basique | -u user:pass | FTP ancien, HTTP simple |
| Jeton Bearer | -H "Authorization: Bearer <token>" | API REST, OAuth2 |
| Auth par cookies | -b cookies.txt (+ -c pour enregistrer) | Applications web avec session |
Fichier .netrc | --netrc ou --netrc-file | CI/CD, environnements scriptés |
Dépannage des échecs courants de téléchargement avec cURL
C’est la section que j’aurais vraiment aimé trouver à mes débuts, parce que presque personne ne la couvre. « Pourquoi mon téléchargement curl ne fonctionne pas » est une vraie recherche fréquente et frustrante — et les correctifs tiennent souvent en une ligne une fois la cause identifiée.
| Symptôme | Cause probable | Correctif |
|---|---|---|
curl: (60) SSL certificate problem | Certificat auto-signé ou expiré | --cacert <file> ou -k (uniquement en dev) |
403 Forbidden / fichier vide | Le serveur bloque l’User-Agent par défaut de curl | -A "Mozilla/5.0..." ou -H "User-Agent: ..." |
Le téléchargement repart de 0 avec -C - | Le serveur ne prend pas en charge Range | Vérifie avec curl -I <url> et cherche Accept-Ranges: bytes |
| Fichier de 0 octet enregistré | Redirection non suivie | Ajoute l’option -L |
curl: (28) Operation timed out | Serveur lent ou problème réseau | --connect-timeout 10 --max-time 300 + --retry 3 |
| Page HTML enregistrée à la place du fichier | La page nécessite un rendu JavaScript | curl n’exécute pas JavaScript — voir la section ci-dessous |
Erreurs de certificat SSL : ce qu’elles signifient et comment les corriger
L’erreur 60 signifie que curl n’a pas pu vérifier le certificat SSL du serveur — généralement parce qu’il est auto-signé, expiré ou émis par une autorité de certification que curl ne reconnaît pas. Si tu contrôles le serveur, indique à curl le bon bundle CA avec --cacert /chemin/vers/ca.pem. L’option -k (--insecure) désactive complètement la vérification, ce qui peut se tolérer dans un environnement de développement local, mais est une très mauvaise idée dès qu’il s’agit de production ou de données réelles d’utilisateurs.
Erreurs 403 Forbidden et téléchargements vides
Un nombre surprenant de serveurs bloquent les requêtes qui s’identifient comme curl/8.21.0 (la chaîne User-Agent par défaut de curl), en les prenant pour des bots ou des scrapers. La solution consiste souvent à se faire passer pour un navigateur :
curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" -LO https://example.com/file.zip
Pour vérifier ce qui revient réellement avant de lancer un vrai téléchargement, j’utilise : curl -o /dev/null -s -w "%{http_code}\n" <url>.
Timeouts, retries et connexions instables
C’est la commande que je me ferais tatouer sur le bras si j’étais plus courageux face aux tatouages.
Ma commande de téléchargement de référence, celle que j’utilise réellement dans des scripts de production, regroupe toutes les options de fiabilité :
curl -L -C - --retry 5 --retry-delay 3 --connect-timeout 10 --max-time 600 --fail -O <url>
Cela inclut le suivi des redirections, la reprise, cinq tentatives avec un délai de 3 secondes, un délai de connexion de 10 secondes, une limite globale de 10 minutes, et un échec franc en cas de mauvais statut HTTP — en gros tout ce que j’ai appris à inclure à la dure.
cURL dans l’automatisation réelle : pipelines CI/CD, piping et sécurité des scripts
Envoyer la sortie de cURL vers d’autres outils
curl n’a même pas besoin d’écrire un fichier sur le disque — le piping direct vers une autre commande est l’une de ses fonctionnalités les plus sous-estimées :
curl -sL https://example.com/archive.tar.gz | tar xz
curl -s https://api.example.com/data | jq '.results'
Télécharger puis extraire, ou télécharger puis analyser, en une seule ligne. C’est un modèle que j’utilise constamment pour des récupérations ponctuelles de données.
Utiliser cURL dans GitHub Actions et les pipelines CI/CD
Un exemple minimal d’étape GitHub Actions qui télécharge un binaire avec logique de retry et échoue bruyamment en cas d’erreur :
- name: Download binary
run: |
curl -L --fail --retry 3 --retry-delay 5 \
-o app-binary "https://example.com/releases/app-binary"
Stocke les jetons comme secrets CI et référence-les via des variables d’environnement — ne les écris jamais en dur dans le script. Et utilise --fail (ou --fail-with-body si tu dois voir le corps de l’erreur pour le débogage) pour qu’un téléchargement cassé fasse réellement échouer la build au lieu de réussir silencieusement avec des données inutilisables.
La question de sécurité autour de curl | sh
Le sujet revient dans presque tous les forums développeur que j’ai lus, et pour de bonnes raisons : envoyer curl directement vers sh revient à exécuter du code distant que tu n’as pas examiné, en faisant entièrement confiance au fait que le serveur n’a pas été compromis et que la connexion n’a pas été altérée. Voilà le vrai risque — pas de la paranoïa, mais un problème très concret de chaîne d’approvisionnement.
La méthode la plus sûre consiste à télécharger d’abord, inspecter le script, vérifier une somme de contrôle ou une signature GPG si elle est fournie, puis seulement exécuter :
curl -sL https://example.com/install.sh -o install.sh
cat install.sh # lire réellement le contenu
sha256sum install.sh # comparer avec la somme publiée si elle existe
bash install.sh
Des installateurs connus comme rustup et Homebrew utilisent encore le schéma curl | sh, et il est généralement admis pour ces cas précis parce que les mainteneurs et le canal de distribution sont bien établis. Je préfère quand même passer dix secondes de plus à inspecter un script plutôt que d’apprendre à mes dépens que je n’aurais pas dû lui faire confiance.
Quand cURL ne suffit plus : pages rendues en JavaScript, sites anti-bot et données structurées
Voici un mode d’échec qui piège beaucoup de monde, et ce n’est rarement de leur faute : tu lances curl -O sur ce qui ressemble à une page normale, et au lieu du contenu attendu tu obtiens un squelette HTML vide, ou une page de challenge Cloudflare, ou quelque chose d’inutile. curl a pourtant fait exactement ce pour quoi il a été conçu — récupérer la réponse HTTP brute — mais il ne peut pas exécuter JavaScript, résoudre un CAPTCHA ou contourner un système de détection anti-bot. Ce ne sont pas des bugs de curl ; c’est simplement en dehors de son champ d’action.
Pourquoi cURL échoue sur les pages web modernes
Les applications web mono-page renvoient souvent un squelette HTML presque vide, le contenu réel étant ensuite rendu côté client par JavaScript après chargement — chose que curl n’exécute jamais. En plus de cela, des systèmes comme Cloudflare et Akamai servent activement des pages de challenge à tout ce qui ne ressemble pas à un vrai navigateur, et des requêtes curl répétées depuis la même IP peuvent être très vite limitées ou identifiées comme du trafic de bot.
L’étape suivante : des API de scraping IA pour les développeurs
Je dirais que curl est l’outil adapté à environ 80 % des téléchargements de fichiers et de données : ressources statiques, réponses d’API, tout ce qui est servi comme ressource HTTP simple. C’est sur les 20 % restants — pages lourdes en JavaScript ou protégées contre les bots — que j’ai vu des développeurs perdre des heures à se battre avec les en-têtes et les User-Agent avant de finalement changer complètement de couche.
C’est précisément ce fossé que mon équipe a voulu combler avec Thunderbit, en complément de l’extension Chrome que beaucoup connaissent déjà. Côté développeur, l’Open API de Thunderbit propose POST /distill, qui renvoie depuis une URL un Markdown propre, prêt pour les LLM — le rendu de la page étant géré par le service — et POST /extract, qui renvoie du JSON structuré correspondant à un schéma lorsque tu as besoin de vraies données champ par champ plutôt que d’un texte lisible. Il existe aussi un serveur MCP pour que des agents dans Claude ou Cursor puissent appeler thunderbit_distill et thunderbit_extract pendant une tâche, ainsi qu’un CLI (npx @thunderbit/thunderbit-cli distill <url>) qui se comporte beaucoup comme curl dans le terminal. Tu peux, par exemple, envoyer la sortie JSON vers jq : thunderbit distill <url> --format json | jq -r '.data.markdown' ; ou envoyer la sortie --format markdown vers un outil texte ou vers un fichier.
La différence saute aux yeux. Une requête curl sur une page produit rendue en JavaScript peut renvoyer un <div id="root"></div> quasi vide. La commande équivalente thunderbit distill renvoie le contenu de la page rendue sous forme de Markdown propre. Distill consomme 1 crédit par URL et Extract 20 crédits par URL. Les limites actuelles varient selon l’endpoint : Batch Distill prend en charge jusqu’à 100 URL par tâche, tandis que Batch Extract accepte jusqu’à 50 URL avec un schéma partagé. Vérifie la documentation API à jour avant de dimensionner une file de production.
Si tu découvres le sujet, notre propre explication sur ce qu’implique réellement le web scraping constitue un bon point de départ, et le guide de scraping sans code couvre l’autre versant du problème pour les membres de ton équipe qui n’ouvriront jamais un terminal. Pour une comparaison plus large des outils du secteur, nous avons aussi préparé un tour d’horizon des meilleurs web scrapers IA à connaître.
Référence rapide : mémo cURL pour les téléchargements
| Tâche | Commande |
|---|---|
| Téléchargement de base | curl -LO <url> |
| Nom de fichier personnalisé | curl -L -o myfile.zip <url> |
| Reprendre un téléchargement | curl -C - -LO <url> |
| Mode silencieux avec erreurs affichées | curl -sSL -O <url> |
| Téléchargements parallèles | curl --parallel --parallel-max 5 -O <url1> -O <url2> |
| Authentification par jeton Bearer | curl -H "Authorization: Bearer <token>" -LO <url> |
| Commande scriptée recommandée | curl -LO --retry 5 --retry-delay 3 --max-time 600 --fail <url> |
| Envoyer vers un outil d’extraction | curl -sL <url> | tar xz |
Conclusion et points clés à retenir
Télécharger un fichier avec curl commence simplement — curl -O et c’est presque fini — mais la vraie compétence se cache dans les couches en dessous : savoir quand ajouter -L, quand reprendre plutôt que relancer, quelle méthode d’authentification correspond vraiment à ton flux de travail, et quoi faire dès qu’un 403 ou un squelette HTML vide apparaît à la place du fichier attendu. J’ai utilisé chacun de ces schémas à un moment ou à un autre, généralement juste après avoir appris à mes dépens pourquoi c’était important.
curl reste, sans conteste, mon outil par défaut pour les téléchargements simples et les opérations HTTP scriptables : il est rapide, disponible partout et se marie parfaitement avec le reste d’un pipeline shell. Mais quand tu tombes sur une page rendue en JavaScript ou un mur anti-bot, ce n’est pas un problème à résoudre avec davantage d’options curl ; c’est le signe qu’il te faut une autre couche, et c’est exactement là qu’une API comme celle de Thunderbit prend le relais sans te faire quitter ton terminal.
Garde le mémo sous la main, teste la commande de reprise et de retry lors de ton prochain téléchargement instable, et si tu tombes sur ce mur où curl ne renvoie que des données inutiles, tu sais déjà à quoi ressemble l’étape suivante — la page de tarification de Thunderbit indique la répartition actuelle des crédits si tu veux voir ce que coûte réellement cette montée en puissance, et notre chaîne YouTube propose des tutoriels si tu préfères regarder plutôt que lire.
FAQ sur le téléchargement de fichiers avec cURL
Comment télécharger un fichier avec cURL et l’enregistrer sous un nom précis ?
Utilise -o suivi du nom voulu : curl -L -o votre_nom.ext <url>. Ajoute -L pour éviter qu’une redirection ne casse le téléchargement.
Comment reprendre un téléchargement cURL échoué ?
Lance curl -C - -LO <url>. Cela ne fonctionne que si le serveur prend en charge les requêtes par plage — vérifie d’abord avec curl -I <url> et cherche Accept-Ranges: bytes dans la réponse.
cURL peut-il télécharger des fichiers qui nécessitent une connexion ?
Oui, de quatre façons principales : authentification basique (-u user:pass), jetons Bearer (-H "Authorization: Bearer <token>"), sessions basées sur les cookies (-b cookies.txt) ou fichier .netrc pour les environnements scriptés. Voir la section d’authentification plus haut pour le détail complet et le cas d’usage de chaque méthode.
Quelle est la différence entre cURL et wget pour télécharger des fichiers ?
cURL prend en charge davantage de protocoles et est généralement meilleur pour les scripts, le piping et les téléchargements précis d’un seul fichier ou en petit lot. wget est conçu pour le crawl récursif et le miroir complet de répertoires de sites, ce qui en fait un meilleur choix pour récupérer en masse des fichiers statiques.
Pourquoi cURL télécharge-t-il une page HTML au lieu du vrai fichier ?
Deux suspects habituels : tu as oublié l’option -L et le serveur t’a redirigé ailleurs, ou la page nécessite JavaScript pour afficher son vrai contenu — ce que curl ne peut tout simplement pas exécuter. Dans le second cas, il te faudra un outil capable de rendre les pages, pas davantage d’options curl.
