Parcours 0 — Avant de commencer · leçon gratuite · 14 min

API et base de données

Deux mots qui font peur et qui désignent des choses simples : une porte pour discuter entre programmes, et un placard bien rangé.

Objectifs

• Expliquer ce qu’est une API avec un exemple concret
• Expliquer ce qu’est une base de données et pourquoi un fichier ne suffit pas
• Lire une adresse d’API et un code de statut HTTP

Une API (Application Programming Interface) est une porte d'entrée prévue pour les programmes, pas pour les humains. Un site web a une interface pour toi (des pages, des boutons) ; une API est l'interface pour d'autres logiciels : « envoie-moi une demande à cette adresse, dans ce format, et je te réponds dans ce format ».

Exemple : l'API d'un service de météo. Ton programme demande GET https://api.meteo.exemple/v1/previsions?ville=Lyon et reçoit une réponse en JSON, un format texte structuré que les programmes lisent facilement :

{
  "ville": "Lyon",
  "temperature": 21,
  "ciel": "nuageux"
}

Ton propre backend expose lui aussi une API à ton frontend : POST /reservations pour créer une réservation, GET /reservations/42 pour en lire une. Les services que tu brancheras (paiement, e-mails, cartes) ont tous une API, et la plupart demandent une clé d'API pour t'identifier — d'où l'importance des variables d'environnement.

Une base de données est un programme spécialisé dans le rangement et la recherche de données : comptes utilisateurs, commandes, réservations. Pourquoi pas un simple fichier ? Parce qu'un fichier ne sait pas répondre vite à « toutes les réservations de mardi entre 19 h et 21 h », ne gère pas deux écritures simultanées, et ne garantit rien si le courant coupe au milieu. Une base fait tout ça. Les plus courantes pour le web : PostgreSQL, MySQL, SQLite (une base dans un seul fichier, parfaite pour débuter).

La plupart des API web suivent le style REST : une adresse (URL) désigne une ressource, un verbe HTTP dit ce qu'on veut en faire, et un code de statut résume la réponse.

Côté base de données, les données sont rangées en tables (comme des feuilles de calcul : une ligne par réservation, une colonne par information) et on les interroge en SQL :

SELECT nom, heure FROM reservations WHERE date = '2026-09-16' ORDER BY heure;

Tu n'as pas besoin de savoir écrire ça aujourd'hui. Tu as besoin de reconnaître que c'est une question posée à la base, et de comprendre la réponse quand Claude Code te la montre.

Le trajet complet d'un clic sur « Réserver », vu avec les bons mots :

1. Le frontend envoie une requête POST /api/reservations avec un corps JSON { "date": "2026-09-16", "personnes": 4 }.
2. Le backend reçoit la requête, vérifie les données (400 si invalides), interroge la base de données en SQL pour la disponibilité.
3. La base répond ; le backend écrit la réservation, appelle l'API du service d'e-mails pour envoyer la confirmation (avec sa clé d'API lue dans une variable d'environnement).
4. Le backend répond 201 Created avec le JSON de la réservation ; le frontend affiche « Réservé ! ».

Claude Code sait écrire une API, une requête SQL, un appel vers un service externe. Ce que tu apportes, c'est le cadrage : quelles données, quelles règles (« pas plus de 12 personnes »), quels cas d'erreur. Et la vérification : tester l'API avec de vraies requêtes plutôt que croire le message « c'est fait ». Les parcours 17 et 18 sont consacrés à ça.

À retenir

• API = une porte pour les programmes : une adresse, un verbe (GET, POST…), une réponse souvent en JSON.
• Base de données = rangement et recherche fiables des données ; tables + SQL.
• Les codes HTTP disent où est le problème : 4xx = ta demande, 5xx = le serveur.
• Une clé d’API s’utilise depuis le backend, via une variable d’environnement.