Examen niveau 4 — Node.js

Examen — questions inédites

12 questions pour valider le niveau : API REST et CRUD, authentification et sécurité, temps réel Socket.IO, validation, erreurs et tests.
Répondez à tout, puis cliquez sur Corriger : score et explications s'affichent.

4.1 · Rappel

1. Dans une API REST, qui porte l'action (créer, lire, supprimer) ?

L'URL, avec un verbe (/getProduits, /supprimerProduit) Le code de statut renvoyé par le serveur Un commentaire dans le code source La méthode HTTP (GET, POST, PUT, DELETE) sur une URL de ressource

URL = ressource au pluriel ; l'action vient de la méthode HTTP.

4.2 · Rappel

2. Comment stocker correctement un mot de passe utilisateur ?

En le hachant avec bcrypt (sens unique, salé), sans jamais le stocker en clair Dans un fichier texte à côté du code En clair dans la base, pour le retrouver facilement Avec un chiffrement réversible maison

On compare à la connexion sans jamais déchiffrer ; jamais de maison.

4.3 · Rappel

3. Que permet un WebSocket par rapport à HTTP classique ?

Une connexion persistante bidirectionnelle où le serveur pousse instantanément Des pages HTML plus jolies Un stockage de fichiers plus rapide Des requêtes plus longues à écrire

Connexion ouverte en continu, messages dans les deux sens.

4.1 · Application

4. Salim crée un produit via POST /api/v1/produits. Quels codes attend le front ?

Aucun code, le corps suffit 201 si créé, 400 si le corps est invalide 200 dans tous les cas, y compris en erreur 302 puis 418 dans tous les cas

201 après création, 400 si invalide, 404 si ressource absente.

4.1 · Application

5. L'API de Salim grossit : où placer la logique de création d'un produit ?

Dans la réponse JSON elle-même Dans le fichier HTML du front Dans le contrôleur, la route déléguant via express.Router() En vrac dans app.js avec tout le reste

Routes (URL) → contrôleurs (logique) → modèles (données).

4.2 · Application

6. Une requête arrive sans jeton sur /mon-compte (route protégée de Salim). Réponse ?

Redirection vers une vidéo 401 (jeton manquant/invalide), via le middleware de vérification 200 avec les données quand même 500 sans explication

401 = non authentifié ; 403 = authentifié mais pas le droit.

4.3 · Application

7. Salim veut un chat par boutique. Comment isoler les conversations ?

Envoyer les messages par e-mail Poller l'API toutes les 100 ms depuis chaque client Diffuser chaque message à tous les connectés sans distinction Créer une room par boutique (socket.join) et diffuser avec io.to(boutique)

Rooms : qui rejoint quoi, diffusion au bon périmètre.

4.4 · Application

8. Un client envoie { prix: -5 } sans nom à l'API de Salim. Que faire ?

Valider avec le schéma (Zod/Joi) et rejeter en 400 avec un message clair Renvoyer la stack trace complète au client Stocker tel quel, on verra plus tard Planter le serveur pour alerter

Valider avant de traiter ; 400 clair, jamais de fuite sensible.

4.4 · Application

9. Où placer le middleware de gestion d'erreurs Express de Salim ?

Dans le navigateur du client Il n'en faut aucun, try/catch suffit partout En dernier, après les routes, avec 4 paramètres (err, req, res, next) En premier, avant express.json()

Centralisé en dernier : un seul format d'erreur pour toute l'API.

4.2 · Arbitrage

10. Salim découvre son secret JWT écrit en dur dans un commit poussé sur Git. Premier réflexe ?

Le copier aussi dans le README pour le retrouver Supprimer Helmet pour compenser Le laisser, personne ne regarde les dépôts Le déplacer en variable d'environnement (.env ignoré), régénérer le secret et révoquer l'ancien

Secret hors du code et hors Git ; rotation immédiate après exposition.

4.3 · Arbitrage

11. 40 vendeurs pollent l'API « du nouveau ? » chaque seconde et le serveur sature. Arbitrage de Salim ?

Poller encore plus souvent pour être plus temps réel Ouvrir des WebSockets (Socket.IO) : le serveur pousse quand il y a du nouveau Arrêter toute fonctionnalité temps réel définitivement Renvoyer 200 vide pour soulager le serveur

Pousser via connexion ouverte au lieu de redemander en boucle.

4.4 · Arbitrage

12. À la veille d'une livraison, Salim hésite à écrire des tests (« ça marche déjà »). Que décider ?

Ne rien tester et livrer vite, on testera après l'incident Tester à la main une fois, sans rien automatiser Écrire au minimum des tests sur les routes critiques (400 + succès) et les relancer à chaque changement Supprimer la validation pour gagner du temps

Non-régression : la suite verte avant chaque merge libère les évolutions.

Et après ?

Score ≥ 80 % : passez au Niveau 5 — Node.js professionnel (TypeScript, performance, Docker, déploiement) et industrialisez vos APIs.
Score 50-79 % : reprenez les sections ratées (CRUD 4.1, auth 4.2, temps réel 4.3, fiabilisation 4.4), relisez les explications ci-dessus, puis refaites le test.
Score < 50 % : recommencez le niveau depuis 4.1 en codant chaque modèle (routeur, auth, chat, tests), puis retentez l'examen à tête reposée.