Tout ce qu'on a fait jusqu'ici s'execute dans le navigateur de l'utilisateur. Quand quelqu'un envoie son email, il ne va nulle part — on affiche juste un faux message de succes. Dans cette lecon, on ajoute un backend pour que les donnees soient vraiment sauvegardees.
La vue d'ensemble
Concept
Chaque application web suit le meme flux de base :Navigateur de l'utilisateur (Frontend) → Route API (Backend) → Base de donnees → Reponse au navigateur
Le frontend collecte la saisie utilisateur. Le backend la traite. La base de donnees la stocke. La reponse la confirme. C'est ainsi que chaque application au monde fonctionne — de Google a un simple formulaire d'inscription.
Les routes API de Next.js
Voici la beaute de Next.js : il gere aussi la logique backend. Tu n'as pas besoin d'un serveur separe. Les routes API sont des fichiers speciaux dans ton dossier app/api/ qui gerent la logique cote serveur.
Une route API est simplement une URL sur ton serveur qui accepte des donnees et retourne une reponse. Par exemple : POST /api/signup — recoit un email, le stocke, retourne "success."
Essaie
Dans Claude Code, tape :"Create an API route at app/api/signup/route.ts that: - Accepts POST requests with a JSON body containing an email field - Validates the email format on the server side - Checks for duplicate emails - Stores the email with a timestamp in a local JSON file at data/signups.json - Returns a JSON response with success: true or an error message - Create the data directory if it doesn't exist"
Claude creera le fichier de route API. C'est ton premier code backend !
Commencer simple : stockage en fichier JSON
Pour apprendre, nous stockons les donnees dans un fichier JSON local. C'est la "base de donnees" la plus simple possible — un fichier qui contient une liste d'emails. Ca fonctionne parfaitement pour le developpement.
Apres que Claude ait cree la route API, ton fichier data/signups.json ressemblera a quelque chose comme ca :
[
{ "email": "user@example.com", "timestamp": "2026-04-11T10:30:00Z" }
]
Note honnete
Un fichier JSON n'est pas une vraie base de donnees. Ca fonctionne bien pour apprendre et tester a petite echelle, mais ca a de vraies limitations : pas de gestion d'acces concurrent, pas de requetes complexes, pas de sauvegarde, et ca vit sur une seule machine. Dans la Lecon 10, nous passerons a DynamoDB — une vraie base de donnees cloud. Mais pour l'instant, c'est l'outil d'apprentissage parfait.Connecter le frontend au backend
Maintenant, mettons a jour le formulaire d'inscription pour qu'il envoie vraiment les donnees a notre nouvelle route API :
Essaie
Dans Claude Code :"Update the signup form component to POST to /api/signup instead of simulating a delay. Send the email as JSON in the request body. Handle the response: - If the API returns success: true, show the success message - If the API returns an error (like duplicate email), show the error message from the API - Handle network errors with a generic 'Something went wrong. Please try again.' message"
Tester
- Assure-toi que ton serveur de developpement tourne (
npm run dev) - Va sur http://localhost:3000
- Entre un email et envoie le formulaire
- Verifie
data/signups.json— ton email devrait y etre ! - Essaie d'envoyer le meme email a nouveau — tu devrais voir une erreur "doublon"
Essaie
Envoie quelques emails differents via le formulaire. Puis ouvredata/signups.json dans VS Code pour verifier qu'ils sont tous la. Tu viens de construire une fonctionnalite full-stack !
Validation des donnees cote serveur
La validation cote client (dans le navigateur) est bien pour l'experience utilisateur, mais ce n'est pas suffisant. N'importe qui peut la contourner en envoyant des requetes directement a ton API.
Concept
Ne fais jamais confiance aux donnees du client. Valide toujours cote serveur aussi. La validation cote client est pour l'experience utilisateur (afficher des erreurs utiles). La validation cote serveur est pour la securite (rejeter les mauvaises donnees peu importe comment elles ont ete envoyees).Notre route API valide deja les emails cote serveur — Claude l'a inclus. Mais rendons-la plus robuste :
Add rate limiting to the signup API — maximum 5 signups per IP address
per hour. If exceeded, return a 429 status with a friendly message.
Tester ton API
En plus d'utiliser le formulaire dans le navigateur, tu peux tester ton API directement :
Avec l'onglet Network du navigateur :
- Ouvre les Outils de developpement (F12)
- Va dans l'onglet Network
- Envoie le formulaire
- Clique sur la requete
signuppour voir les details de la requete et de la reponse
Avec curl dans ton terminal (optionnel) :
curl -X POST http://localhost:3000/api/signup \
-H "Content-Type: application/json" \
-d '{"email": "test@example.com"}'
Note de securite
Note honnete
C'est un projet d'apprentissage, et c'est tres bien. Mais une application en production a besoin de plus :- Authentification — verifier qui fait les requetes - Rate limiting — prevenir les abus (nous avons ajoute un limiteur basique ci-dessus) - Assainissement des entrees — prevenir les attaques par injection - HTTPS — chiffrer les donnees en transit - Variables d'environnement — garder les secrets hors du code
Claude peut t'aider a ajouter tout ca, mais il est important de savoir que ca existe. La securite n'est pas optionnelle dans les vraies applications.
Checkpoint Git
git add .
git commit -m "backend API route with email storage and server-side validation"
Assure-toi d'ajouter data/signups.json a ton fichier .gitignore — tu ne veux pas commiter les donnees utilisateur :
echo "data/signups.json" >> .gitignore
git add .gitignore
git commit -m "ignore signup data file"
Point cle
Tu viens de construire une fonctionnalite full-stack. Les donnees circulent du navigateur de l'utilisateur, a travers ta route API, jusqu'a une base de donnees (fichier JSON pour l'instant). C'est le meme pattern utilise par chaque application au monde — tu l'as fait avec l'aide de l'IA.