Avant de parler de microservices, de cache ou de déploiement, il faut savoir de quoi une application web est faite. Derrière chaque page, on retrouve les mêmes briques : un client, un serveur, souvent une base de données, et un protocole commun, HTTP. Ce guide pose le vocabulaire de l’architecture web, en s’appuyant sur les cours de MDN, pour comprendre ce que chaque brique fait et ce qu’elle ne fait pas.
Pourquoi parler d’architecture web ?
L’architecture d’une application, c’est la manière dont ses parties sont découpées et communiquent. Elle ne se résume pas à un framework. Une bonne compréhension des briques de base permet de situer un bug (côté navigateur ou côté serveur ?), de choisir où placer une règle métier et de dialoguer avec une équipe back-end ou une agence.
Si vous débutez, commencez par notre guide pour créer un site internet de A à Z, puis revenez ici : nous détaillons ce qui se passe sous le capot.
Les briques de base
Le client : le navigateur et ses langages
D’après MDN, les clients sont les appareils connectés d’un utilisateur et les logiciels qui accèdent au web, généralement un navigateur. Le navigateur télécharge le code d’une page, le rend et l’affiche. Un site se compose principalement de HTML, CSS et JavaScript, ainsi que de ressources (images, vidéos, PDF…) appelées assets. Pour revoir les fondamentaux : qu’est-ce que le HTML et JavaScript dans le navigateur.
Le serveur : des fichiers ou du code
Les serveurs sont des ordinateurs qui stockent des pages, des sites ou des applications. Un serveur attend les requêtes des clients, les traite, puis répond par un message HTTP. Dans sa version la plus simple, il se contente de renvoyer des fichiers ; dans sa version applicative, il exécute du code.
La base de données : la mémoire de l’application
Un site dynamique stocke ses données dans une base plutôt que dans des fichiers HTML individuels. MDN en cite deux avantages : les informations sont stockées de façon efficace, facile à étendre, modifier et rechercher, et les templates permettent de changer la structure HTML en un seul endroit plutôt que dans des milliers de pages.
Site statique ou site dynamique
La documentation MDN distingue deux familles.
- Site statique : il renvoie le même contenu codé en dur pour une ressource donnée. Le serveur ne traite que des requêtes GET et ne change pas sa réponse selon les paramètres d’URL ou les cookies. C’est excellent pour un petit nombre de pages au contenu identique pour tous, mais la maintenance devient coûteuse quand les pages se multiplient.
- Site dynamique : il génère le contenu selon l’URL demandée et les données de la requête. Pour une page produit, le serveur identifie l’identifiant du produit, lit la base de données, puis insère les données dans un template HTML.
MDN précise que les deux types utilisent exactement le même protocole de communication, et que les sites dynamiques traitent les fichiers statiques (CSS, JavaScript, images) de la même manière que les sites statiques.
Navigateur et serveur communiquent avec HTTP. Une requête contient :
- une URL qui identifie la ressource visée ;
- une méthode qui définit l’action : GET pour récupérer une ressource, POST pour en créer une, PUT pour en mettre à jour une, DELETE pour la supprimer, HEAD pour obtenir uniquement les métadonnées ;
- éventuellement des données : paramètres d’URL, corps de requête (POST) ou cookies.
La réponse porte un code de statut : 200 OK en cas de succès, 404 Not Found si la ressource est introuvable, 403 Forbidden si l’accès est refusé. Le corps d’une réponse GET réussie contient la ressource demandée. Quand le navigateur reçoit une page HTML, il la rend, et découvre souvent d’autres ressources (CSS, JavaScript) qu’il télécharge par des requêtes HTTP séparées. Le format des messages est défini par une norme, la RFC 9110, citée par MDN.
Pour la partie sécurité du transport, voir comment fonctionne HTTPS.
Le cycle d’une requête dynamique
MDN décrit une requête dynamique en étapes. Appliqué à une page produit :
- Le navigateur envoie une requête GET vers l’application, avec l’identifiant du produit dans l’URL ou en paramètre.
- Le serveur web transmet la requête à l’application serveur.
- L’application lit les données nécessaires dans la base.
- Elle insère les données dans un template HTML.
- Elle renvoie une réponse HTTP contenant la page, avec le code 200 si tout s’est bien passé.
- Le navigateur rend la page et télécharge les ressources associées.
Cette séquence est la même, quel que soit le langage ou le framework choisi : MDN insiste sur le fait que le comportement décrit doit être implémenté par le code serveur, indépendamment de la technologie.
Où placer la logique ? Une règle de départ
Deux erreurs reviennent souvent :
- tout mettre côté client, y compris des règles qui doivent rester inviolables ;
- tout mettre côté serveur, y compris des interactions qui gagneraient à être instantanées.
Une règle simple : ce qui touche à la sécurité, aux données ou aux droits se décide côté serveur ; ce qui touche à la fluidité de l’interface peut vivre côté client. MDN rappelle d’ailleurs que les paramètres d’URL peuvent être modifiés par l’utilisateur : on ne s’en sert donc pas pour des requêtes qui modifient des données.
Ce que l’on ajoute ensuite
Les briques ci-dessus suffisent à comprendre une application simple. Les projets réels y ajoutent d’autres éléments, que nous traiterons dans cette série : cache, CDN, files de tâches, authentification, services externes, environnements de test. Chacun répond à un problème précis de performance, de sécurité ou de fiabilité. L’ordre compte : on comprend d’abord le cycle requête-réponse, puis on optimise.
Check-list pour lire l’architecture d’un projet
- Où s’exécute chaque morceau de code : navigateur, serveur, les deux ?
- Quelles données sont stockées, et où ?
- Quelles requêtes HTTP le client envoie-t-il, avec quelles méthodes ?
- Quels fichiers sont statiques, lesquels sont générés ?
- Que se passe-t-il si la base de données ou un service tiers ne répond pas ?
Si vous préférez déléguer cette lecture à des spécialistes, Yunt Agency accompagne la conception et la livraison d’applications web.
Conclusion
Une application web, c’est un client qui parle HTTP à un serveur, lequel s’appuie souvent sur une base de données et des templates. Savoir nommer ces briques et leur cycle de vie est le socle de toute décision d’architecture : sans lui, les mots « API », « cache » ou « microservice » restent abstraits.
FAQ
Quelle différence entre un site statique et un site dynamique ?
Un site statique renvoie toujours le même contenu pour une ressource donnée. Un site dynamique génère la réponse selon l’URL et les données de la requête, souvent à partir d’une base de données et de templates.
Faut-il toujours une base de données ?
Non. Un site statique de quelques pages n’en a pas besoin. Elle devient utile quand les données évoluent et doivent être stockées, recherchées et modifiées efficacement.
Que signifie le code 404 ?
Il indique que la ressource demandée est introuvable sur le serveur. Le code 200 signale un succès et 403 un accès refusé.
Le navigateur envoie-t-il une seule requête par page ?
Non. Après avoir reçu la page HTML, il envoie souvent d’autres requêtes pour télécharger les fichiers CSS, JavaScript et autres ressources référencés.
HTTP et HTTPS sont-ils la même chose ?
HTTPS est HTTP transporté de manière sécurisée. Notre article sur HTTPS détaille le fonctionnement du chiffrement.
