Le prompt complet que j'utilise pour que Claude Code trouve une API gratuite dans Public APIs, la teste et la branche sur ton projet. Plus le tri qui évite les API mortes, et 10 API que j'ai testées une par une.
Public APIs est un dépôt GitHub (public-apis/public-apis), sous licence MIT. C'est un annuaire : une longue page qui recense des API publiques, rangées par thème. Le 16 octobre 2026, il avait 489 360 étoiles, et j'y ai compté 2 135 API dans 51 thèmes : météo, sport, finance, cryptos, actualité, transports, livres, administrations…
Une API, c'est une adresse que ton app appelle pour recevoir des données à jour : la température de Paris, le cours du bitcoin, les résultats de la dernière course. C'est ce qui permet à ton app d'afficher de vraies données au lieu de chiffres inventés.
Chaque ligne du tableau a trois colonnes à connaître :
No veut dire sans clé, sans compte. Sinon apiKey (une clé à créer sur le site de l'API), OAuth (une connexion à un compte) ou un autre en-tête.Yes.Yes veut dire que la page de ton site peut appeler l'API directement depuis le navigateur. No ou Unknown : il faut passer par ton serveur (Claude sait le faire, le prompt plus bas le lui demande).Avant la liste, le README affiche une section sponsorisée (APILayer, 26 entrées) et quelques entrées sponsorisées dans les thèmes. Elles demandent toutes une clé. Si tu veux du sans clé, Claude doit les ignorer : le prompt le précise.
Dans la vidéo, je dis que près de la moitié des API marchent sans clé. Le compte exact du 16 octobre :
La règle : Auth = No, HTTPS = Yes, et CORS = Yes si l'appel part du navigateur. Ça ne garantit pas que l'API répond encore (voir plus bas), mais ça élimine déjà la moitié des mauvaises surprises.
Dans la vidéo, tu ouvres Claude Code dans ton projet et tu lui dis :
Va dans Public APIs,
trouve-moi une API météo
gratuite, sans clé, teste-la
et branche-la directement
dans mon application.Ça marche pour un premier essai. Voici le prompt complet que j'utilise, qui couvre les pièges de ce guide. Remplace les crochets :
Tu travailles sur mon projet.
J'ai besoin de vraies données
pour [ce que je veux afficher :
la météo de ma ville, les
résultats de F1, le cours du
bitcoin…].
1. Cherche dans Public APIs
(github.com/public-apis/
public-apis) les API qui
correspondent. Garde d'abord
Auth = No et HTTPS = Yes.
Ignore les entrées
sponsorisées.
2. Propose-moi les 3
meilleures avec, pour chacune :
ce qu'elle renvoie, si elle
demande une clé, ses limites
d'appels, et si l'usage
commercial est autorisé. Mon
projet est [perso /
commercial].
3. Quand j'ai choisi, fais un
vrai appel de test et
montre-moi la réponse avant
d'écrire le moindre code. Si
l'API ne répond pas, dis-le
et passe à la suivante.
4. Branche-la dans le projet.
Si l'API n'accepte pas les
appels depuis le navigateur
(CORS), passe par une route
côté serveur. Ajoute un cache
pour rester sous les limites.
5. Si une clé est nécessaire,
mets-la dans un fichier .env,
ajoute .env au .gitignore, et
ne l'écris jamais dans le
code envoyé au navigateur.
6. Si l'API ne répond pas,
affiche un message propre.
N'invente jamais de données
de remplacement.
Termine par un récapitulatif :
l'API choisie, ses conditions
d'usage, et ce que je dois
surveiller.Pourquoi le point 6 compte : quand un appel échoue, Claude a tendance à mettre une valeur « en attendant » pour que la page ait l'air de marcher. C'est exactement le faux chiffre qu'on veut éviter. Mieux vaut un message « météo indisponible » qu'une température inventée.
Dans la vidéo, je dis qu'il va choisir, tester l'appel et l'afficher. Le 16 octobre à 16 h 30, j'ai fait le vrai appel à Open-Meteo pour Paris : le voici (clique, la réponse s'affiche dans ton navigateur). Ce qu'il a répondu (extrait) :
"current": {
"time": "2026-10-16T16:30",
"temperature_2m": 21.0
}21 °C à Paris, à cet instant. C'est ce chiffre que la page de démo de la vidéo affiche, en le redemandant à chaque visite. Si tu cliques sur le lien aujourd'hui, tu auras la température du moment : c'est tout l'intérêt.
Quand une API demande une clé, Claude la range dans un fichier à part. Concrètement :
À la racine du projet, une ligne par clé : WEATHER_API_KEY=ta-clé. Ton code la lit avec process.env.WEATHER_API_KEY.
Sinon ta clé part sur GitHub au premier envoi, et des robots scannent GitHub en permanence pour les récupérer.
Tout ce qui est envoyé au navigateur est lisible par n'importe qui (clic droit, « Inspecter »). Une clé secrète ne vit que côté serveur : la page appelle ton serveur, qui appelle l'API avec la clé.
Le fichier .env reste sur ton ordinateur. Sur Vercel, Netlify ou autre, tu recopies la clé dans les « variables d'environnement » du projet.
Vérifie qu'aucune clé n'est
écrite en dur dans le projet,
que .env est dans le
.gitignore, et qu'aucune clé
secrète n'est envoyée au
navigateur.C'est ce que personne ne dit dans les vidéos sur ce dépôt : la liste n'est pas un label de qualité. N'importe qui peut y ajouter une API, et personne ne revérifie les anciennes. Le 16 octobre, j'ai testé une vingtaine d'API de la liste. Ce que j'ai trouvé :
api.jolpi.ca/ergast/f1/…), répond avec exactement le même format, mais il n'est pas dans la liste.No dans la colonne Auth, mais elle répond « Unauthorized ». Elle demande une clé aujourd'hui.api.frankfurter.dev. L'ancienne adresse redirige encore, pour combien de temps ?D'où le point 3 du prompt : un vrai appel de test avant d'écrire la moindre ligne de code. Si l'API ne répond pas, Claude passe à la suivante au lieu de construire sur du vide.
Les limites d'appels. Gratuit ne veut pas dire illimité. La plupart des API coupent au-delà d'un certain nombre d'appels par minute ou par jour. Le jour où ton site a du monde, chaque visiteur déclenche un appel, et tu te fais couper. La parade : un cache. Ton serveur garde la réponse quelques minutes (la météo ne change pas toutes les secondes) et la sert à tout le monde.
Ajoute un cache de 10 minutes
sur l'appel à l'API, côté
serveur, pour que tous les
visiteurs partagent la même
réponse.L'usage commercial. Chaque API a ses conditions. Exemple : Open-Meteo, l'API météo de la vidéo, est gratuite et sans clé, mais la liste la décrit « for non-commercial use ». Pour un site qui vend quelque chose, il faut leur offre payante. Avant de mettre en ligne, lis la page « Terms » ou « Pricing » de l'API, ou demande à Claude :
Lis les conditions d'usage de
cette API et dis-moi si je
peux l'utiliser sur un site
commercial, et ce que je dois
afficher (mention, lien).Toutes dans la liste, toutes sans clé, toutes en HTTPS, et toutes ont répondu à un vrai appel le jour où j'ai écrit ce guide :
Température, pluie, vent, prévisions, partout dans le monde. Usage non commercial gratuit. Appelable depuis le navigateur.
Sessions, tours, positions, en direct et en historique. Appelable depuis le navigateur.
Cours du bitcoin et des autres cryptos (72 660 € le 16 octobre). Limites d'appels basses sans compte : mets un cache.
Taux officiels de la Banque centrale européenne (1 € = 1,1253 $ le 16 octobre). Adresse à jour : api.frankfurter.dev.
Les articles d'actualité spatiale de dizaines de sites, à jour. Appelable depuis le navigateur.
Les jours fériés de plus de 90 pays. Pas de CORS : passe par ton serveur.
Transforme une adresse en coordonnées, et l'inverse (données OpenStreetMap). Règles strictes : un appel par seconde au maximum, et ton app doit s'identifier.
Titres, auteurs, couvertures, des millions de livres. Pas de CORS : passe par ton serveur.
Les prochains lancements de fusées, avec date et lieu. Appelable depuis le navigateur.
Pour t'entraîner sans risque : tout sur les Pokémon, sans limite gênante. Idéale pour un premier test.