Créer une API REST avec Claude Code : Node.js & Express (Guide 2026)

Créer une API REST avec Claude Code : de l'idée au endpoint en une session

Vous avez un projet — une application mobile, un tableau de bord, un SaaS — et il lui faut un backend : une API qui stocke les données, les expose proprement et gère l'authentification. Écrire tout cela à la main est long et répétitif : configurer Express, brancher la base, écrire chaque route, valider les entrées, gérer les erreurs… Bonne nouvelle : c'est exactement le genre de travail que Claude Code abat en quelques prompts bien cadrés.

Dans ce guide 2026, on construit ensemble une API REST complète en Node.js avec Express, connectée à une base de données, sécurisée par JWT et couverte par des tests — le tout en pilotant Claude Code plutôt qu'en tapant chaque ligne. Vous repartirez avec une méthode reproductible pour tous vos futurs backends.

Sommaire

API REST : les concepts en 2 minutes {#api-rest-concepts}

Avant de lancer l'agent, fixons le vocabulaire pour pouvoir relire ce que Claude Code produit — c'est la clé pour garder le contrôle.

Une API REST expose des *ressources* (des utilisateurs, des articles, des commandes) à travers des URL et des méthodes HTTP :

Chaque réponse porte un code de statut : 200 (succès), 201 (créé), 400 (requête invalide), 401 (non authentifié), 404 (introuvable), 500 (erreur serveur). Une bonne API respecte ces conventions — et Claude Code les connaît parfaitement, à condition de le lui demander explicitement.

Notre stack pour ce guide : Node.js + Express (le framework web le plus répandu), un ORM (Prisma) pour parler à la base sans écrire de SQL brut, et JWT pour l'authentification. Si vous préférez une solution clé en main avec base hébergée, notre article sur créer un backend fullstack avec Supabase et Claude Code couvre une approche complémentaire.

Préparer le projet avec Claude Code {#preparer-projet}

Ouvrez un dossier vide et lancez Claude Code. La première règle d'or : poser le contexte avant de générer quoi que ce soit. Créez (ou demandez à Claude de créer) un fichier CLAUDE.md décrivant votre projet :

# API Blog — contexte projet

Stack : Node.js 24, Express 5, Prisma, PostgreSQL, JWT.
Style : ES modules, async/await, pas de callbacks.
Conventions : routes dans src/routes, logique dans src/controllers,
validation Zod, réponses JSON { data, error }.
Sécurité : bcrypt pour les mots de passe, secrets via .env.

Ce fichier oriente toutes les générations suivantes. Si vous débutez avec l'outil, notre guide Claude Code pour débutants explique comment installer le CLI et lancer votre première session.

Ensuite, un prompt d'amorçage clair :

« Initialise un projet Node.js avec Express 5 en ES modules. Crée la structure src/routes, src/controllers, src/middlewares, src/lib. Ajoute un serveur de base qui écoute sur le port défini par process.env.PORT (3000 par défaut) avec une route GET /health qui renvoie { status: "ok" }. Configure aussi un .gitignore et un .env.example. »

Claude Code crée les fichiers, installe les dépendances et vous montre le résultat. Vérifiez toujours le package.json et lancez le serveur pour confirmer que /health répond.

Étape 1 : générer le squelette Express {#etape-1-squelette}

À ce stade, vous avez un serveur qui démarre. Demandez maintenant à Claude Code de structurer l'application proprement :

« Sépare la configuration du serveur (app.js) de son démarrage (server.js) pour faciliter les tests. Ajoute les middlewares essentiels : express.json() pour parser le corps des requêtes, Helmet pour les en-têtes de sécurité, et un middleware de logs simple. »

Le résultat typique ressemble à ceci — et vous devez être capable de le lire :

// src/app.js
import express from "express";
import helmet from "helmet";
import articlesRouter from "./routes/articles.js";

const app = express();
app.use(helmet());
app.use(express.json());

app.get("/health", (req, res) => res.json({ status: "ok" }));
app.use("/articles", articlesRouter);

export default app;

Astuce : demandez à Claude Code de committer à chaque étape stable. Il maîtrise Git de bout en bout — voyez notre guide commits, branches et pull requests avec Claude Code pour déléguer aussi le versioning.

Étape 2 : connecter la base de données {#etape-2-base}

Une API sans persistance ne sert à rien. Décrivez votre modèle de données en langage naturel :

« Configure Prisma avec PostgreSQL. Crée un modèle Article (id, titre, contenu, publié booléen, createdAt) et un modèle User (id, email unique, motDePasse haché, role). Un User a plusieurs Articles. Génère la migration initiale et un client Prisma réutilisable dans src/lib/prisma.js. »

Claude Code écrit le schema.prisma, lance prisma migrate, et crée le client. Point de vigilance : la chaîne de connexion doit vivre dans .env, jamais dans le code ni dans le chat. Un bon prompt de sécurité :

« Assure-toi que DATABASE_URL est lue depuis .env et documentée dans .env.example sans valeur réelle. »

Cette gestion propre des secrets est un réflexe à prendre dès le premier projet. C'est aussi ce qui distingue un prototype d'une API prête pour la production.

Étape 3 : créer les routes CRUD {#etape-3-crud}

Le cœur de l'API. Un seul prompt bien structuré suffit pour générer un CRUD complet :

« Crée les routes CRUD pour Article dans src/routes/articles.js et la logique dans src/controllers/articlesController.js :

- GET /articles (liste paginée, ?page & ?limit)

- GET /articles/:id (404 si absent)

- POST /articles (201 en cas de succès)

- PUT /articles/:id

- DELETE /articles/:id (204)

Utilise le client Prisma, gère les erreurs avec try/catch et renvoie toujours { data } ou { error }. »

Remarquez le niveau de détail : plus vous êtes précis sur les codes de statut, la pagination et le format de réponse, moins vous aurez de corrections à faire. C'est le principe du bon prompt appliqué au backend. Claude Code produit un contrôleur cohérent, avec la pagination et la gestion du cas « ressource introuvable » — deux détails que les débutants oublient souvent.

Testez immédiatement chaque route avec curl ou un client HTTP. Si une réponse ne colle pas, dites-le simplement à l'agent : « le POST renvoie 200 au lieu de 201, corrige ». L'itération est le vrai super-pouvoir de Claude Code.

Étape 4 : validation et gestion des erreurs {#etape-4-validation}

Une API qui accepte n'importe quelle entrée est une API cassée en puissance. Ajoutez une couche de validation :

« Ajoute la validation des entrées avec Zod. Crée un schéma pour la création et la mise à jour d'un Article (titre requis, 3-200 caractères ; contenu requis). Crée un middleware validate(schema) réutilisable qui renvoie 400 avec les détails d'erreur si la validation échoue. Applique-le aux routes POST et PUT. »

Puis un gestionnaire d'erreurs centralisé, indispensable en Express :

« Ajoute un middleware d'erreur global en fin de chaîne qui capture toutes les exceptions, journalise l'erreur côté serveur, et renvoie un message générique en production sans fuiter la stack trace. »

Cette double couche — validation en entrée, gestion d'erreur en sortie — transforme un script fragile en service robuste. C'est typiquement le genre de plomberie fastidieuse que l'on est ravi de déléguer.

**Vous voulez déléguer réellement la partie répétitive du développement backend à l'IA, au lieu d'écrire chaque route et chaque middleware à la main ?** Découvrez [comment vous faire remplacer par l'IA](https://go.saas-ia.io/se-faire-remplacer-par-lia) sur la plomberie de vos API — configuration, validation, tests, déploiement — et concentrez votre temps sur la conception produit.

Étape 5 : authentification JWT {#etape-5-auth}

Pour protéger vos routes, ajoutez l'authentification par JSON Web Token :

« Ajoute l'authentification JWT :

- POST /auth/register : crée un User, hache le mot de passe avec bcrypt (12 rounds), renvoie un token.

- POST /auth/login : vérifie les identifiants, renvoie un token signé avec JWT_SECRET (expiration 24h).

- Un middleware authRequired qui vérifie le token dans l'en-tête Authorization: Bearer et attache req.user.

Protège les routes POST, PUT et DELETE de /articles avec authRequired. »

Claude Code gère le hachage, la signature du token et le middleware de vérification. Vérifiez trois points sensibles : le JWT_SECRET provient bien de .env, les mots de passe ne sont jamais renvoyés dans les réponses, et le token expire. Pour une revue de sécurité approfondie, déléguez la relecture à un subagent de revue de code dédié : un agent en lecture seule qui traque les failles pendant que vous avancez.

À ce stade, si votre API doit consommer ou agréger des données externes — par exemple des annonces immobilières ou des données métier — des services spécialisés comme ImmoAPI montrent à quoi ressemble une API de données bien conçue, avec endpoints documentés et pagination : une bonne source d'inspiration pour structurer la vôtre.

Étape 6 : tester et documenter l'API {#etape-6-tests}

Une API sans tests est une dette technique déguisée. Demandez la couverture :

« Écris des tests d'intégration avec Vitest et Supertest pour toutes les routes /articles et /auth : cas nominal, erreurs de validation (400), accès non authentifié (401), ressource introuvable (404). Ajoute un script npm test et un jeu de données de test isolé. »

Claude Code excelle dans ce registre. Pour aller plus loin sur cette approche, notre guide tests automatisés et TDD avec Claude Code montre comment faire écrire les tests *avant* le code.

Côté documentation, une seule phrase suffit :

« Génère une spec OpenAPI 3.1 (openapi.yaml) documentant tous les endpoints, et expose une interface Swagger UI sur /docs. »

Vous obtenez une documentation interactive, à jour, que vos utilisateurs d'API pourront explorer. Si vous voulez pousser la documentation technique plus loin (README, guide d'architecture), voyez générer de la documentation technique avec Claude Code.

Déployer votre API {#deployer}

Votre API tourne en local, testée et documentée. Reste à la mettre en ligne :

« Crée un Dockerfile multi-étapes pour une image de production légère (node:24-alpine), un docker-compose.yml avec le service API et une base PostgreSQL, et un fichier de config pour un déploiement sur Railway. Documente les variables d'environnement nécessaires. »

Pour un hébergement sur votre propre serveur plutôt que sur une plateforme managée, la logique reste la même : conteneur Docker, reverse proxy (Nginx ou Caddy) et certificat HTTPS. Si l'auto-hébergement et la souveraineté de vos agents et services vous intéressent, la formation OpenClaw sur les agents IA auto-hébergés explore en détail comment garder le contrôle de votre infrastructure IA sans dépendre d'un fournisseur cloud.

Bonnes pratiques et pièges à éviter {#bonnes-pratiques}

Quelques réflexes qui font la différence entre une API jouet et une API sérieuse :

Ces principes ne sont pas propres aux API : ils valent pour tout projet piloté à l'IA. Pour les besoins de données côté client (récupérer et transformer des données depuis le web), notre article web scraping avec Claude Code complète bien ce backend.

L'API en action (vidéo) {#video}

Rien ne vaut une démonstration pour voir l'enchaînement complet — de l'initialisation du projet au premier endpoint qui répond. Cette vidéo de la chaîne Sophiène IA montre comment piloter Claude Code pour construire une application de bout en bout, une méthode directement transposable à la création d'une API :

Conclusion : votre prochain backend en une session

Créer une API REST n'a jamais été aussi rapide. En pilotant Claude Code couche par couche — squelette Express, base de données, CRUD, validation, authentification JWT, tests et déploiement — vous passez de l'idée à un service fonctionnel en une seule session de travail, avec une base propre, testée et documentée dès le départ.

Le vrai changement de posture : vous ne tapez plus chaque ligne, vous décrivez, relisez et validez. Votre valeur se déplace vers l'architecture, la sécurité et la qualité — pendant que l'IA gère la plomberie. Ouvrez un dossier vide, écrivez votre premier CLAUDE.md, et lancez votre première route dès aujourd'hui.

FAQ : créer une API REST avec Claude Code {#faq}