Côté serveur : ce qui se passe après votre clic

Dans le précédent article Le voyage d’une requête web, nous avons suivi le voyage d’une requête web depuis votre navigateur jusqu’au serveur. Vous avez découvert qu’en tapant une URL ou en cliquant sur un lien, une requête partait de votre appareil, traversait Internet, et atteignait une machine distante : le serveur web.

Mais une fois la requête arrivée à destination, que se passe-t-il exactement ?

Dans cet article, nous allons ouvrir la boîte noire côté serveur, c’est-à-dire comment :

1. Un serveur web interprète une requête,
2. Il décide ce qu’il faut faire,
3. Il récupère les données, applique les règles, et fabrique la réponse que le navigateur attend

Vous allez voir que derrière une simple page web, il y a souvent un petit orchestre bien coordonné.

Lorsque votre requête arrive à destination, elle est d’abord accueillie par un serveur web. C’est un logiciel spécialisé, comme Apache ou Nginx, qui écoute en permanence sur un port (souvent le 80 pour HTTP, ou le 443 pour HTTPS).

Son rôle ? Décoder cette requête HTTP et décider qui doit s’en occuper.

Deux cas de figure sont possibles :

• Si la requête concerne un fichier simple, comme une image, une feuille de style CSS ou un fichier PDF, le serveur peut le servir directement, sans plus d’effort.
• Si vous demandez une page dynamique, par exemple /blog/, le serveur transmet la requête à une application plus complexe, écrite avec un langage de programmation comme PHP, Python, Ruby, Node.js….

On pourrait dire que le serveur joue le rôle de portier d’hôtel : « Bonjour, vous venez pour une chambre ? Je vous dirige vers la réception. Vous cherchez le restaurant ? C’est au fond à gauche.  »

Une fois la requête transmise à l’application, une autre mécanique se met en route : le système de routes.

Imaginez une centrale de tri qui analyse l’adresse de la requête, le chemin d’URL, et décide quel morceau de code doit s’exécuter.

Derrière cette logique, on retrouve souvent une architecture logicielle en MVC (Modèle Vue Contrôleur), une structure très répandue dans le monde du développement web.

Voici les trois rôles principaux :

• Contrôleur est le chef d’orchestre : il reçoit la requête, détermine la partie du Modèle à exécuter, puis choisit la Vue qui va habiller les données récupérées.
• Modèle gère la logique et le lien avec les données : il s’occupe de récupérer les bonnes données depuis la base de données et de les préparer.
• Vue s’occupe de l’habillage graphique des données préparées : elle génère le code HTML (ou JSON) qui sera envoyé au navigateur.

Par exemple, dans notre illustration,

• Vous cliquez sur le lien Blog d’un site,
• L’URL demandée est : /blog
• Le système de routes appelle, dans le Contrôleur BlogController, sa méthode show()
• Ce contrôleur demande au Modèle Blog de retrouver les 10 derniers articles en base de données
• Il passe ces données à la Vue qui construit la page HTML du blog
• La page est renvoyée au navigateur

Tout cela prend une fraction de seconde.

Dans une base de données sont stockées les informations sur les articles, les utilisateurs, les pages…

C’est une sorte de grand classeur numérique dans lequel l’application va chercher, lire, enregistrer des infos à chaque requête.

Le Modèle est chargé d’interagir avec cette base, souvent via un langage appelé SQL. Il sait comment poser des questions précises :

• Donne moi les 10 derniers articles publiés
• Quels sont les articles commandés par l’utilisateur 17 ?

Métaphore simple : La base de données est une bibliothèque, et le Modèle est le bibliothécaire. Vous ne fouillez pas vous-même les rayons : vous demandez à quelqu’un qui sait où chercher.

Entre la réception de la requête et l’affichage de la réponse, il y a souvent des règles à respecter. On appelle cela la logique métier.

C’est elle qui dit :

• Si l’utilisateur n’est pas connecté, redirige-le vers la page de connexion
• Si le stock est vide, n’affiche pas le bouton Ajouter au panier
• Si le client a déjà commandé ce produit, propose-lui une réduction

La logique métier peut être simple ou très complexe, mais elle est au cœur du fonctionnement du site. C’est elle qui transforme des demandes en actions intelligentes (algorithmes).

Une fois que ;

1. Le contrôleur a reçu la requête,
2. La logique métier a été appliquée,
3. Les données ont été récupérées ou modifiées,

Il faut maintenant fabriquer la réponse :

• Du HTML : une page à afficher, le plus classique
• Du JSON : un format d’échange de données utilisé dans les applications modernes ou par AJAX
• Un fichier PDF, CSV, image…

En plus du contenu, l’application ajoute des en-têtes HTTP à la réponse afin de faciliter sa prise en compte par le navigateur (Type de contenu retourné, durée de validité…)

Une fois la réponse prête, elle remonte la chaîne :

• L’application la remet au serveur web
• Le serveur web la renvoie au navigateur
• Le navigateur la reçoit, l’interprète, et l’affiche

On boucle ainsi avec l’article précédent : le navigateur, qui avait envoyé la requête, obtient finalement sa réponse.

• Serveur : machine qui reçoit les requêtes et envoie les réponses
• Route : règle qui relie une URL à un morceau de code
• Contrôleur : chef d’orchestre qui gère la requête
• Modèle : pont entre le code et la base de données
• Vue : rendu visuel ou formaté de la réponse
• JSON : format léger de données, très utilisé pour les API
• Logique métier : ensemble des règles que le site doit respecter

Si une erreur 500 apparaît, cela signifie qu’une erreur s’est produite côté serveur.

Cela peut venir d’un bug dans la logique métier, d’une base de données inaccessible, ou d’un script mal exécuté.

Même WordPress, pourtant très simple d’apparence, suit cette même logique complexe :

• La requête passe par index.php
• Les routes sont gérées par le rewrite engine
• Le contrôleur est souvent wp-admin/admin-ajax.php ou un plugin
• Les données sont dans la base MySQL
• Les Vues sont générées par le thème (fichiers .php + HTML)

Vous voilà désormais dans les coulisses du serveur.

Vous savez comment une simple requête déclenche tout un enchaînement de traitements : depuis la réception de l’URL jusqu’à la construction d’une page, en passant par des règles métier et des accès à une base de données.

Dans le prochain article, nous verrons ce qui se passe côté client :

Comment le navigateur interprète le HTML, applique les styles CSS, exécute les scripts JavaScript, et construit l’interface visible.