Article 4/4 — Parcours débutant : du navigateur au serveur

Nous avons posé les bases du langage, puis découvert Node.js et son catalogue de briques réutilisables. Il est temps de tout assembler pour construire ce qui se cache derrière n’importe quel site : un serveur web.

Que fait un serveur, au juste ?

Un serveur web passe sa journée à attendre des questions et à y répondre. Lorsque vous saisissez une adresse dans votre navigateur, celui-ci envoie une requête via le protocole HTTP (HyperText Transfer Protocol, le protocole de transfert hypertexte) — le langage commun grâce auquel navigateurs et serveurs se comprennent. Le serveur reçoit la requête, détermine quoi renvoyer, et expédie une réponse.

Notre objectif : écrire le programme qui tient ce rôle.

Express, pour se simplifier la vie

Node.js sait gérer le réseau tout seul, mais le faire « à la main » est verbeux. La communauté s’appuie donc sur Express, une brique installable via npm qui simplifie énormément la création d’un serveur. On l’ajoute au projet ainsi :

npm install express

Un serveur en quelques lignes

Voici un serveur complet et fonctionnel. Prenez le temps de le lire ligne à ligne plutôt que de le copier mécaniquement : c’est en comprenant chaque morceau qu’il devient le vôtre.

const express = require("express");
const app = express();

app.get("/", (req, res) => {
  res.send("Bonjour le monde !");
});

app.listen(3000, () => {
  console.log("Serveur démarré sur http://localhost:3000");
});

Décortiquons. La première ligne importe la brique Express installée précédemment. La deuxième crée notre application.

Le cœur de l’affaire est app.get. Il définit une route : « lorsqu’un visiteur demande l’adresse /, voici la réponse à lui renvoyer ». La fonction reçoit deux objets par convention : req (la requête, ce que demande le visiteur) et res (la réponse, ce qu’on lui renvoie). Ici, on répond simplement par un texte.

Enfin, app.listen(3000, ...) met le serveur à l’écoute sur le port 3000. C’est l’équivalent d’ouvrir la boutique et d’allumer l’enseigne : à partir de cet instant, le serveur attend les visiteurs.

Lancez le tout avec node puis ouvrez http://localhost:3000 dans votre navigateur : votre message s’affiche. Vous venez de servir une page depuis un programme que vous avez écrit de bout en bout.

La suite logique

À partir de cette base, tout devient une variation. Ajouter une route /contact, renvoyer non plus du texte mais des données structurées pour alimenter une API (Application Programming Interface, interface de programmation applicative), brancher une base de données : chaque besoin réel correspond à une brique que vous saurez désormais chercher et intégrer.

Et c’est là le vrai message de cette série : on n’apprend pas le développement web en accumulant de la théorie, mais en faisant tourner de petits projets, puis en les complexifiant. Vous avez maintenant fait le chemin du bouton qui s’anime jusqu’au serveur qui répond. La meilleure étape suivante n’est pas un nouveau cours — c’est votre prochain projet.

Article 3/4 — Parcours débutant : du navigateur au serveur

Jusqu’ici, JavaScript vivait dans le navigateur. Mais nous avons évoqué dans le premier article sa capacité à tourner ailleurs. C’est exactement ce que permet Node.js : exécuter du JavaScript directement sur votre ordinateur ou sur un serveur, sans navigateur.

Pourquoi est-ce une si bonne nouvelle ?

Concrètement, un site web a deux faces. Le front-end est tout ce qui s’affiche dans le navigateur de l’utilisateur. Le back-end est la partie cachée : la base de données, la logique métier, l’envoi des e-mails. Traditionnellement, ces deux faces réclamaient deux langages différents.

Avec Node.js, on écrit les deux en JavaScript. Vous apprenez un langage, et vous couvrez l’ensemble de la chaîne. C’est ce qu’on appelle le développement fullstack, et c’est l’une des grandes raisons de la popularité de Node.

Sous le capot

Node.js repose sur le moteur V8, la même mécanique qui exécute JavaScript dans le navigateur Chrome. Les ingénieurs ont en quelque sorte extrait ce moteur du navigateur pour le faire fonctionner de façon autonome. Ajoutez-y des outils pour lire des fichiers, écouter le réseau ou parler à une base de données, et vous obtenez une plateforme complète pour bâtir des applications côté serveur.

Votre premier script

Une fois Node.js installé, créez un fichier bonjour.js contenant une seule ligne :

console.log("Bonjour depuis Node.js !");

Puis, dans un terminal, lancez-le :

node bonjour.js

Le message s’affiche dans le terminal, et non dans une page web. Vous venez d’exécuter du JavaScript hors du navigateur : un cap symbolique.

npm, la bibliothèque géante

Le second atout de Node tient en trois lettres : npm (Node Package Manager, le gestionnaire de paquets de Node). C’est un immense catalogue de code déjà écrit par d’autres développeurs, que vous pouvez ajouter à vos projets en une commande.

Besoin de gérer des dates, de générer un mot de passe, de créer un serveur web ? Quelqu’un a probablement déjà résolu le problème et publié sa solution. Plutôt que de tout réinventer, vous assemblez des briques éprouvées — un réflexe professionnel essentiel.

Un projet Node démarre généralement ainsi :

npm init -y

Cette commande crée un fichier package.json, sorte de carte d’identité du projet : son nom, sa version, et la liste des briques externes qu’il utilise.

Vous avez désormais les deux ingrédients clés : un JavaScript qui tourne côté serveur, et un moyen d’y greffer du code existant. Dans le dernier article, nous les combinerons pour fabriquer quelque chose de concret : un véritable serveur web.

Article 2/4 — Parcours débutant : du navigateur au serveur

Dans le premier article, nous avons situé JavaScript comme le langage du comportement d’une page web. Place maintenant aux deux outils que vous utiliserez dans absolument tous vos programmes : les variables et les fonctions.

Ranger une information : la variable

Une variable est une étiquette posée sur une information pour pouvoir la retrouver plus tard. On en déclare une avec le mot-clé const ou let :

const prenom = "Laurent";
let age = 30;

La différence tient en une règle de bon sens. On utilise const (pour constante) quand l’information ne changera pas, et let quand elle est appelée à évoluer. Le réflexe sain consiste à choisir const par défaut, et à ne passer à let que si l’on a une raison de modifier la valeur. Cela rend le code plus lisible : un lecteur sait, d’un coup d’œil, ce qui bouge et ce qui est figé.

Quelques types de données

Une variable peut contenir différentes natures d’information. Les plus courantes au départ sont le texte (la chaîne de caractères, entre guillemets), les nombres, et les booléens — c’est-à-dire les valeurs true (vrai) ou false (faux), pratiques pour répondre à une question par oui ou non.

const nom = "Dupont";    // texte
const score = 42;         // nombre
const estConnecte = true; // booléen

Écrire une action réutilisable : la fonction

Une fonction est un bloc d’instructions auquel on donne un nom, pour pouvoir le rejouer à volonté sans le réécrire. Pensez-y comme à une recette : on la définit une fois, puis on l’exécute autant de fois qu’on le souhaite, éventuellement avec des ingrédients différents.

function saluer(nom) {
  return "Bonjour " + nom;
}

saluer("Laurent"); // renvoie "Bonjour Laurent"
saluer("Marie");   // renvoie "Bonjour Marie"

Le mot nom entre parenthèses est un paramètre : une information que l’on fournit à la fonction au moment de l’appeler. Le mot return indique le résultat que la fonction renvoie.

JavaScript moderne propose une écriture plus compacte, la fonction fléchée, que vous rencontrerez partout :

const saluer = (nom) => "Bonjour " + nom;

C’est exactement la même recette, présentée plus brièvement. Inutile de chercher à mémoriser cette syntaxe par cœur dès aujourd’hui : elle deviendra naturelle à force de l’écrire.

Avec ces deux notions — stocker une information, exécuter une action — vous tenez déjà l’ossature de la quasi-totalité des programmes. Dans le prochain article, nous ferons sortir JavaScript du navigateur pour découvrir Node.js.

Article 1/4 — Parcours débutant : du navigateur au serveur

Si vous avez déjà cliqué sur un bouton qui déroule un menu, vu un formulaire signaler une erreur sans recharger la page, ou fait glisser une carte sous votre souris, vous avez croisé JavaScript. C’est le langage qui rend les pages web vivantes.

Trois piliers, trois rôles

Pour situer JavaScript, il faut le replacer auprès de ses deux compagnons. Une page web repose sur trois technologies aux rôles bien distincts.

Le HTML (HyperText Markup Language, langage de balisage hypertexte) fournit la structure : les titres, les paragraphes, les images, les liens. C’est le squelette de la page.

Le CSS (Cascading Style Sheets, feuilles de style en cascade) gère l’apparence : couleurs, polices, espacements, disposition. C’est le vêtement posé sur le squelette.

JavaScript, lui, apporte le comportement : ce qui réagit, calcule, change, communique avec un serveur. C’est, si l’on file la métaphore, le système nerveux. Sans lui, une page reste un document que l’on lit ; avec lui, elle devient une application avec laquelle on dialogue.

Un langage qui a débordé de son cadre

JavaScript est né en 1995 pour animer les pages dans le navigateur, et rien d’autre. C’était sa seule maison. Mais le langage a tellement gagné en maturité qu’il s’est mis à tourner ailleurs : sur les serveurs, dans les applications mobiles, jusque dans les objets connectés.

Cette expansion explique pourquoi JavaScript est aujourd’hui l’une des compétences les plus recherchées : un seul langage permet de travailler à la fois sur ce que voit l’utilisateur (le front-end) et sur la machinerie cachée derrière (le back-end). Nous y reviendrons dans les articles suivants.

Faut-il être informaticien pour s’y mettre ?

Non. JavaScript a la rare qualité de produire un résultat visible presque immédiatement : quelques lignes suffisent pour qu’un bouton réagisse. Cette gratification rapide en fait un excellent premier langage, à condition d’accepter une règle simple : on progresse en construisant de petites choses qui fonctionnent, pas en cherchant à tout mémoriser d’avance.

C’est précisément l’esprit de cette série. Dans le prochain article, nous poserons les briques de base du langage : comment stocker une information, et comment écrire une instruction réutilisable.

Le pair programming (programmation en binôme) est une vieille pratique : deux développeurs, un clavier, un dialogue permanent qui muscle la qualité du code. L’arrivée des assistants IA (Claude, ChatGPT, Copilot) en propose une variante asynchrone et toujours disponible. Encore faut-il s’en servir comme d’un coéquipier, pas comme d’un distributeur de solutions.

Choisir son rôle dans le binôme

La règle d’or tient en une question : qui tient le clavier ?

Quand vous tenez le clavier, l’IA joue le rôle du navigator — elle commente, propose, alerte, mais c’est vous qui écrivez. Vous restez le pilote, vous gardez la mécanique en main. C’est la configuration la plus formatrice.

Quand l’IA tient le clavier — c’est-à-dire quand vous copiez son code tel quel — vous devenez navigateur. C’est utile pour les tâches répétitives ou un terrain que vous maîtrisez déjà, dangereux sur un sujet que vous découvrez. Coller un bloc de 80 lignes que vous ne pourriez pas réécrire seul, c’est creuser une dette de compréhension qui vous tombera dessus au premier bug.

Alternez les deux rôles consciemment, en sachant lequel vous jouez à chaque instant.

Bien formuler ses demandes

Une IA n’a pas accès à votre contexte : ni votre projet, ni vos conventions, ni l’erreur exacte que vous avez en tête. Quatre éléments font passer une demande médiocre à une demande utile :

• Le contexte : « projet Node.js / Express, base PostgreSQL », pas « j’ai un site ».
• L’intention : ce que vous cherchez à faire, et pourquoi.
• Ce que vous avez déjà tenté : ça évite les suggestions que vous avez déjà éliminées.
• Le format attendu : explication courte, code commenté, comparaison de deux approches.

Plus la question est précise, plus la réponse est exploitable. Une question floue produit une réponse générique — exactement comme avec un collègue humain.

Les bons usages

Certains usages tirent vraiment parti de l’IA. Débloquer une situation : vous tournez en rond sur un message d’erreur, l’IA propose trois pistes, l’une d’elles relance la machine. Explorer une API inconnue : plutôt que d’éplucher la documentation seul, vous demandez un exemple minimal et vous lisez le code obtenu. Relire son propre code : « voici ma fonction, qu’est-ce qui peut mal tourner ? » donne souvent des retours pertinents. Traduire une intention en code de départ : utile pour amorcer, à condition de retravailler ce qui sort.

Les pièges à éviter

Le premier piège est la confiance aveugle. Une IA produit du code plausible, pas nécessairement correct. Elle peut inventer une fonction qui n’existe pas, utiliser une syntaxe obsolète, ou résoudre un problème voisin du vôtre sans le dire. Testez tout ce qu’elle propose.

Le second est la dilution de la compréhension. Si à la fin d’une session vous avez un code qui fonctionne mais que vous ne sauriez pas expliquer ligne à ligne, vous avez livré du code et perdu l’apprentissage. Sur un sujet que vous voulez maîtriser, imposez-vous de tout retaper à la main.

Le troisième est la perte d’initiative. Réflexe à entretenir : essayer de résoudre seul pendant 15 minutes avant d’appeler le binôme. Sinon, on perd l’habitude de penser, et c’est précisément ce que les années pratiquent.

Un coéquipier, pas un oracle

La meilleure manière de se positionner : traiter l’IA comme un collègue compétent mais qui ne connaît pas votre projet. Vous ne lui livreriez pas votre code en aveugle, vous ne croiriez pas chacune de ses affirmations sans vérification, vous ne lui délègueriez pas vos décisions d’architecture. La même prudence professionnelle s’applique. À cette condition, c’est un binôme remarquable.

Dans un projet JavaScript fullstack — typiquement React, Vue ou Next.js côté front, Node.js côté back — il est tentant de considérer HTML et CSS comme des détails que le framework gérera. C’est précisément l’erreur qui produit des interfaces lourdes, inaccessibles et pénibles à maintenir. Le framework rend le HTML, mais c’est vous qui décidez de sa qualité.

HTML : redonner du sens aux balises

Le réflexe <div> partout est le marqueur d’un projet front en dérive. HTML5 propose un vocabulaire riche : <header>, <nav>, <main>, <article>, <section>, <aside>, <footer>, <button>, <figure>. Chacune porte un sens que les navigateurs, les moteurs de recherche et les lecteurs d’écran exploitent.

La règle pratique : avant de poser une <div>, demandez-vous si une balise plus précise existe. Une zone cliquable qui déclenche une action est un <button>, pas une <div> avec un onClick. Un lien qui mène ailleurs est un <a>, pas un <span> stylé. Ce n’est pas du purisme : un <button> est focusable au clavier, déclenchable avec Entrée, annoncé comme bouton par les outils d’accessibilité. Vous n’avez rien à coder pour ça — à condition d’avoir choisi la bonne balise.

L’accessibilité, justement, n’est pas une couche qu’on ajoute à la fin. Quelques réflexes suffisent à 80 % du travail : un attribut alt sur chaque <img> significative, des <label> reliés à leurs champs de formulaire, une hiérarchie de titres <h1> à <h6> cohérente, un contraste suffisant entre texte et fond. Le reste s’apprend au fil des projets.

CSS : maîtriser le poids et l’éparpillement

Le problème classique d’un projet fullstack JS n’est pas l’écriture du CSS — c’est sa prolifération. Chaque composant tend à embarquer ses propres styles, et au bout de quelques mois, personne ne sait plus ce qui sert encore.

Trois principes limitent les dégâts.

Choisir une stratégie de scoping, et s’y tenir. Scoping signifie limiter la portée d’une règle CSS pour qu’elle n’affecte que son composant. Les options courantes sont les CSS Modules (un fichier .module.css par composant, classes localisées automatiquement), les styled-components ou équivalents (CSS écrit dans le JavaScript), et les frameworks utilitaires comme Tailwind (classes prédéfinies appliquées directement dans le HTML). Aucune n’est universellement meilleure ; la mauvaise décision est de les mélanger sans raison sur un même projet.

Séparer les variables des règles. Couleurs, espacements, tailles de police, rayons de bordure : tout ce qui se répète doit vivre dans des custom properties CSS (--couleur-primaire, --espace-md). Cela coûte une heure au démarrage et économise des semaines lors d’un changement de charte graphique. C’est aussi la base d’un mode sombre propre.

Penser mobile d’abord. Écrivez d’abord les styles pour le petit écran, puis ajoutez les ajustements pour les plus grands via des media queries. L’inverse — concevoir pour le bureau puis « adapter » — produit presque toujours une expérience mobile médiocre.

Les ponts entre back et front

Dans un projet fullstack, vous générez parfois du HTML côté serveur (rendu Express avec un moteur de templates, ou Server-Side Rendering avec Next.js) et parfois côté client. Deux pièges à garder en tête.

D’abord, ne jamais injecter du contenu utilisateur dans du HTML sans l’échapper. Une chaîne <script>alert('xss')</script> venue d’un formulaire et collée brute dans une page ouvre une faille XSS (Cross-Site Scripting, injection de scripts entre sites). Les moteurs de templates sérieux échappent par défaut ; encore faut-il ne pas désactiver cette protection sans raison forte.

Ensuite, rendre côté serveur ce qui doit être visible immédiatement et indexable. Un titre, une description, le contenu principal d’un article doivent apparaître dans le HTML initial — pas être ajoutés par JavaScript après le chargement. C’est essentiel pour le référencement et pour les utilisateurs aux connexions lentes.

Le test qui ne ment pas

Une bonne pratique se vérifie facilement : désactivez CSS dans votre navigateur, naviguez sur votre site. Si la structure reste lisible — titres clairs, ordre logique, formulaires utilisables — votre HTML fait son travail. Désactivez maintenant JavaScript. Si la page d’accueil et les contenus principaux restent accessibles, votre fullstack est bien architecturé.

Ces deux tests prennent trente secondes. Ils en disent plus long sur la santé d’un projet que beaucoup d’outils sophistiqués.