Blokby

Quand tu vas sur un site web, deux machines travaillent en même temps sans que tu t'en rendes compte : ton navigateur, et un serveur quelque part sur internet. Le premier s'appelle le frontend (côté client), le second le backend (côté serveur). Comprendre qui fait quoi entre ces deux acteurs est le fondement de tout le reste : sans ce modèle en tête, l'authentification, les bases de données et les variables d'environnement restent des recettes magiques.

Le côté client : ton navigateur

Le navigateur (Chrome, Firefox, Safari, peu importe) est le premier acteur. Son rôle est de :

télécharger les fichiers que le serveur lui envoie (HTML, CSS, JavaScript, images),
transformer ce HTML brut en une page visible à l'écran (c'est ce qu'on appelle le rendu),
exécuter le JavaScript pour rendre la page interactive (menus, formulaires, animations),
stocker des données localement via localStorage ou des cookies.

Exemple concret : tu tapes https://blokby.fr dans la barre d'adresse. Ton navigateur part chercher un fichier HTML. Il le reçoit, le lit, voit que ce fichier demande un fichier CSS et une police de caractères, les télécharge à leur tour, puis assemble le tout pour afficher la page.

Le navigateur ne sait rien de ta base de données, de tes utilisateurs ou de ta logique métier. Il affiche ce qu'on lui donne.

Le côté serveur : une machine qui écoute

Le serveur est un ordinateur connecté à internet qui tourne 24h/24. Il est différent de ton PC perso sur trois points :

il écoute en permanence les connexions entrantes sur un port réseau (généralement le port 80 pour HTTP ou 443 pour HTTPS),
il est accessible publiquement via une adresse IP ou un nom de domaine,
il n'a pas d'utilisateur connecté devant un écran : il reçoit des requêtes, les traite, renvoie des réponses.

Ce serveur peut tourner sous Node.js, Python, Go, Ruby ou n'importe quel autre langage. Il peut aussi être un backend as a service comme Supabase ou Firebase : quelqu'un d'autre gère la machine pour toi, tu accèdes au service via une API.

Je peux citer deux différences entre mon PC et un serveur web : accessibilité publique et fonctionnement 24h/24.

Le cycle requête / réponse

Toute communication entre le navigateur et le serveur suit le même schéma : une requête (envoyée par le navigateur) et une réponse (renvoyée par le serveur). C'est le protocole HTTP, et tu verras ce mot partout.

Voici ce qui se passe quand tu consultes un article sur un blog :

Le cycle requête/réponse pour la consultation d'un article.

Chaque flèche en détail :

GET /article/123 - ton navigateur dit au serveur "donne-moi la page de l'article numéro 123".
SELECT * FROM posts WHERE id=123 - le serveur interroge la base de données pour trouver l'article.
Réponse de la DB - la base renvoie les données brutes (un objet JSON ou une ligne SQL).
HTML rendu - le serveur assemble un fichier HTML avec les données et le renvoie au navigateur.
Affichage - le navigateur transforme ce HTML en page visible.

Je peux dessiner le cycle requête/réponse de mémoire avec ses cinq étapes.

Qui fait quoi : le partage des responsabilités

Responsabilité	Navigateur (frontend)	Serveur (backend)
Rendu visuel	oui	non
Interactions utilisateur	oui	non
Animations, CSS	oui	non
Stockage local (localStorage)	oui	non
Authentification	non	oui
Logique métier	non	oui
Accès à la base de données	non	oui
Envoi d'emails, paiements	non	oui
Files de traitement	non	oui

Pourquoi ce partage ? Trois raisons concrètes :

Sécurité : la base de données ne doit jamais être directement accessible depuis le navigateur. Quelqu'un pourrait lire ou modifier toutes les données de tous les utilisateurs.
Partage d'état : plusieurs utilisateurs consultent le même article, laissent des commentaires, voient les mêmes données. Seul un serveur central peut synchroniser tout ça.
Calculs lourds : générer un PDF, redimensionner une image, envoyer 10 000 emails ne doit pas bloquer le navigateur de l'utilisateur.

L'anti-pattern à ne jamais reproduire

Voici une erreur que font beaucoup de débutants :

// FAUX. Ne jamais faire ça.
localStorage.setItem("isLoggedIn", "true");

// Puis dans le code :
if (localStorage.getItem("isLoggedIn") === "true") {
  // afficher le contenu privé
}

Je comprends pourquoi stocker isLoggedIn dans localStorage est une faille de sécurité, et je peux l'expliquer en une phrase.

Où vivent le frontend et le backend aujourd'hui

Ce modèle client/serveur reste vrai même quand les outils modernes brouillent les frontières :

Frontend pur : HTML statique, React, Vue, Svelte. Tout tourne dans le navigateur.
Backend pur : Node.js, Python/FastAPI, Go. Tourne sur un serveur, répond à des requêtes HTTP.
Next.js : mélange les deux dans le même projet. Les Server Components et les API Routes s'exécutent côté serveur ; les Client Components s'exécutent côté navigateur. Les deux couches coexistent dans le même repo.
Backends as a service : Supabase, Firebase. Quelqu'un d'autre gère le serveur. Tu interagis avec via une API. C'est du backend, même si tu n'as pas de serveur à toi.

Dans les prochaines leçons, tu verras comment le navigateur et le serveur communiquent précisément (HTTP et les APIs), et comment tes fichiers arrivent du serveur jusqu'au navigateur (DNS et déploiement).

Le split frontend / backend