Parcours d’apprentissage web – Part V : Relation client serveur, déploiement et infrastructure web
Ce parcours s’inscrit dans une progression continue : après avoir posé les bases du web avec Part I (environnement et méthode), Part II (structure HTML), Part III (mise en forme CSS) et Part IV (interactions JavaScript), nous abordons ici une nouvelle dimension du projet. Cette cinquième partie ne se concentre plus uniquement sur ce que nous voyons dans le navigateur, mais sur ce qui permet à un projet d’exister réellement en dehors de notre machine.
L’objectif est de donner une vision d’ensemble : comprendre comment un site devient accessible, comment il s’organise sur un serveur, et comment les différents éléments techniques s’articulent entre eux, avant d’entrer plus concrètement dans le code côté serveur dans la suite du parcours.
Sommaire, relier le client, le serveur et le déploiement
Ce sommaire suit le chemin d’une requête web, depuis l’environnement local jusqu’au serveur distant, puis vers les aspects concrets de déploiement. Chaque chapitre met en relation les éléments techniques pour comprendre le flux complet, du nom de domaine jusqu’au contenu servi.
- Du local au serveur puis au distant : situer les différents environnements et comprendre le passage d’un contexte à l’autre.
- Le modèle client serveur : le dialogue fondamental du web : comprendre l’échange entre navigateur et serveur.
- Langages et bases de données côté serveur : identifier les technologies qui traitent et stockent les données.
- Serveur web et moteur d’exécution : qui fait quoi ? : distinguer les rôles entre serveur et interpréteur.
- Les environnements d’un projet web : local, test et production : organiser le cycle de vie d’un projet.
- Travailler avec un serveur local : reproduire un environnement serveur sur sa machine.
- Les différentes formes d’hébergement web : choisir une solution adaptée à ses besoins.
- Du nom de domaine à la machine : comprendre le rôle du DNS : relier un nom lisible à une machine cible.
- URL, URI et structure des adresses sur le web : analyser la composition d’une adresse web.
- Le protocole HTTP et HTTPS : comment les navigateurs dialoguent avec les serveurs : comprendre le protocole d’échange.
- Les réponses HTTP et les codes de statut : interpréter les réponses du serveur.
- Les outils réseau : observer ce qui circule réellement : analyser les échanges en conditions réelles.
- Permissions et chmod : gérer les droits d’accès aux fichiers.
- Le rôle du fichier .htaccess : configurer le comportement du serveur.
- FTP et le transfert de fichiers : transférer des fichiers vers un serveur.
- Accéder à un serveur avec SSH : administrer un serveur à distance.
- Git et le déploiement des projets : versionner et publier son code.
- FTP, Git… ou les deux ? Organiser le déploiement d’un projet web : choisir une stratégie de déploiement.
- De la requête au déploiement : relier les éléments : comprendre la chaîne complète.
- Conclusion et ouverture vers la suite : synthétiser et préparer la suite du parcours.
Du local au serveur puis au distant
Depuis le début de ce parcours, nous avons travaillé en local, en manipulant des fichiers HTML, CSS et JavaScript directement dans le navigateur, sans véritable infrastructure serveur. Cette approche est volontaire : elle permet de comprendre les bases du web sans ajouter trop tôt des couches techniques supplémentaires.
Mais un projet web réel ne reste jamais uniquement local. Il finit toujours par être exécuté sur une machine distante, accessible depuis d’autres ordinateurs, d’autres navigateurs et d’autres réseaux. Deux notions deviennent alors centrales : celle de serveur, qui reçoit et traite les requêtes, et celle de machine distante (souvent appelée remote), c’est‑à‑dire un système situé ailleurs que notre propre ordinateur. Ces éléments introduisent une mécanique essentielle du web, que nous allons détailler dans le chapitre suivant : la relation entre le client et le serveur.
Les chapitres qui suivent vont éclairer progressivement cette organisation. Nous allons voir comment une requête circule, comment un serveur la reçoit, comment il produit une réponse, et comment un projet passe du local à une infrastructure réellement accessible sur le réseau.
Le modèle client serveur : le dialogue fondamental du web
Pour entrer dans cette logique, il est utile de se concentrer sur un principe simple : la relation entre un client et un serveur, qui constitue le fonctionnement fondamental du web.
Pour le comprendre, prenons une situation concrète, lorsque nous saisissons une adresse dans le navigateur, par exemple une page précise de notre site :
- Le navigateur ne possède pas cette page. Il doit la demander.
- Une requête est alors envoyée.
- Elle traverse le réseau et atteint un serveur, qui reste en attente permanente de ce type de demande.
- Lorsqu’il reçoit la requête, il recherche la ressource correspondante.
- Si la page est un fichier HTML simple, elle est renvoyée telle quelle.
- Si elle contient du PHP, le serveur exécute le code, produit un résultat, puis renvoie uniquement ce résultat.
- La réponse est ensuite interprétée par le navigateur.
- La page se construit, les styles s’appliquent, les scripts s’exécutent, et le contenu devient visible.
- Ce dialogue se produit à chaque page, à chaque clic, et à chaque interaction.
Comprendre cette séquence change profondément notre perception. Nous ne travaillons plus sur des fichiers isolés, mais sur des réponses destinées à être demandées, transmises et interprétées. Dans ce dialogue, chaque technologie trouve sa place : HTML structure la réponse, CSS la présente, JavaScript agit côté client, PHP côté serveur, et la base de données fournit les informations. Le web apparaît alors comme un échange permanent entre deux acteurs : le client et le serveur.
Langages et bases de données côté serveur
Dans les chapitres précédents, nous avons surtout travaillé avec des technologies exécutées directement dans le navigateur : HTML pour structurer les pages, CSS pour les présenter et JavaScript pour ajouter des interactions côté client. Mais dès qu’un projet doit produire des pages dynamiques, traiter des formulaires ou manipuler des données persistantes, une autre catégorie d’outils intervient : les langages côté serveur et les bases de données.
Un langage serveur s’exécute sur la machine qui héberge le site. Lorsque le navigateur envoie une requête, le serveur peut exécuter ce code afin de produire une réponse adaptée. Cette réponse peut être une page HTML générée dynamiquement, des données JSON destinées à une application JavaScript, ou encore le résultat d’une opération réalisée dans une base de données.
Dans l’écosystème web, plusieurs technologies coexistent : PHP, très présent dans les CMS et de nombreux sites, Node.js, qui permet d’utiliser JavaScript côté serveur, mais aussi Python, Ruby ou Java selon les contextes. On rencontre également des environnements comme ASP / ASP.NET, JSP / servlets Java ou ColdFusion. Tous reposent sur la même logique : exécuter du code côté serveur pour produire une réponse, avec des outils et des écosystèmes différents.
Ces langages travaillent souvent en relation avec une base de données, qui permet de stocker et d’organiser les informations utilisées par l’application : comptes utilisateurs, articles, commentaires, produits, ou toute autre donnée nécessaire au fonctionnement du site. Dans de nombreux projets, on utilise des bases relationnelles comme MySQL, MariaDB ou PostgreSQL, organisées en tables liées entre elles. D’autres approches existent, dites NoSQL (comme MongoDB), qui manipulent des données plus souples, souvent sous forme de documents. Enfin, dans certains cas plus simples ou spécifiques, les données peuvent aussi être échangées ou stockées directement sous forme de JSON, notamment dans le cadre d’API ou de configurations légères.
Dans ce parcours, nous découvrirons plus en détail PHP dans la prochaine partie, puis le fonctionnement des bases de données MySQL dans la suivante. L’objectif de ce chapitre est simplement de situer leur rôle dans l’architecture générale d’un projet web.
Cette distinction introduit une idée importante : celle de site statique et de site dynamique.
- Un site statique se compose essentiellement de fichiers HTML, CSS et JavaScript envoyés tels quels au navigateur. Chaque page existe déjà sur le serveur et est simplement transmise lorsqu’elle est demandée.
- À l’inverse, un site dynamique génère tout ou partie de ses réponses au moment de la requête. Le serveur peut exécuter du code, interroger une base de données, assembler des contenus, puis produire la page finale avant de l’envoyer au navigateur.
Un site web ne se limite donc plus à un ensemble de fichiers. Il devient une application capable de générer des réponses à partir de données, de règles et de traitements exécutés sur le serveur.
Serveur web et moteur d’exécution : qui fait quoi ?
Dans le chapitre précédent, nous avons vu comment le navigateur et le serveur dialoguent, et comment les langages côté serveur produisent une réponse. Nous allons maintenant préciser qui intervient réellement dans ce processus, et comment les rôles se répartissent. Concrètement, lorsqu’un navigateur appelle une page, une réponse lui est renvoyée. Ce geste paraît anodin, presque invisible. Pourtant, entre ces deux points, une mécanique précise se met en place, avec des rôles distincts et des outils qui coopèrent.
Deux rôles à distinguer
Pour éviter toute confusion, il faut d’abord séparer deux responsabilités fondamentales.
- D’un côté, recevoir la requête. C’est le rôle des serveurs web comme Apache ou Nginx. Ils écoutent sur un port, acceptent la connexion, analysent la demande, puis décident vers quel traitement l’orienter.
- De l’autre, produire la réponse. C’est le rôle d’un moteur d’exécution. Il peut s’agir de PHP, de Node.js, de Java via Tomcat, de ColdFusion ou encore d’ASP.NET. Ces environnements exécutent du code, manipulent des données, puis construisent une réponse exploitable par le navigateur.
Le cas de référence : PHP et MySQL
Dans cette série, nous nous appuyons volontairement sur une approche classique, car elle reste très répandue et particulièrement lisible. Le serveur web reçoit la requête. Il identifie qu’un traitement est nécessaire, puis transmet cette requête à PHP. PHP exécute la logique, interroge éventuellement une base de données MySQL, assemble une réponse, puis la renvoie au serveur web, qui la transmet au navigateur. La chaîne devient alors plus explicite :
Des architectures qui évoluent selon les besoins
Une fois ce modèle compris, il devient plus facile d’ouvrir vers d’autres configurations sans se perdre. Dans de nombreux projets, les rôles restent séparés. Un serveur comme Apache ou Nginx reçoit les requêtes, puis les transmet à un moteur d’exécution dédié. Cette séparation apporte de la souplesse, permet de faire évoluer chaque brique indépendamment, et facilite la maintenance.
Dans d’autres contextes, les rôles sont regroupés. Node.js en est un bon exemple, voir Créer un serveur Node rapide pour servir des fichiers statiques. Il peut à la fois recevoir la requête et produire la réponse dans un même processus, sans passer par un serveur web intermédiaire. Cette approche simplifie certaines architectures, notamment pour des applications temps réel ou des API.
Du côté des environnements Java, des serveurs comme Tomcat assurent directement l’exécution des applications. ColdFusion ou ASP.NET suivent une logique similaire, avec leur propre écosystème et leurs conventions. Les outils changent, les combinaisons varient, mais la logique de fond reste la même.
Ports et services
Pour fonctionner, un serveur ne se contente pas d’exister. Il écoute sur un port réseau. C’est ce port qui permet d’établir la communication. Certains ports sont associés à des usages connus, par exemple HTTP, HTTPS ou SSH. Ces conventions sont largement utilisées, mais un service peut tout à fait écouter sur un autre port si nécessaire.
Autrement dit, une même machine, parfois une même adresse, peut exposer plusieurs services différents. On peut accéder à un site web en HTTP (port 80) ou en version sécurisée HTTPS (port 443), déposer des fichiers en FTP (port 21) ou via des variantes sécurisées comme FTPS (port 990) ou SFTP (basé sur SSH, port 22), ou encore se connecter en SSH (port 22), sans changer de serveur, simplement en changeant de port. C’est ce qui explique des adresses comme localhost:3000 ou localhost:8080. On ne désigne pas uniquement une machine, mais un service précis en cours d’exécution, avec son propre rôle et son propre point d’entrée.
Comprendre cela permet de mieux saisir comment plusieurs usages coexistent sur un même serveur, sans se mélanger, chacun ayant sa porte d’accès dédiée.
Derrière les versions sécurisées comme HTTPS, FTPS ou SFTP, on retrouve une couche de chiffrement. Pour le web, HTTPS repose sur TLS et l’usage d’un certificat. Nous détaillons ce fonctionnement dans le chapitre dédié au protocole HTTP et aux réponses HTTP. Retenons ici simplement que le passage en HTTPS ne change pas la logique des échanges, mais sécurise le canal entre le navigateur et le serveur.
Reverse proxy
Après avoir distingué les rôles entre serveur web et moteur d’exécution, voyons comment ces briques peuvent être orchestrées dans une architecture plus avancée. Dans certaines architectures, le serveur qui reçoit la requête n’est pas celui qui la traite réellement. On introduit alors un reverse proxy. Son rôle est de recevoir les connexions, puis de les rediriger vers le bon service.
Un outil comme Nginx peut ainsi servir de point d’entrée unique, puis distribuer les requêtes vers Apache, vers une application Node.js, ou vers un autre service interne. NGINX Reverse Proxy. Cette organisation permet de centraliser les accès, de mieux contrôler les flux, et d’optimiser les performances.
Le reverse proxy devient alors une pièce d’orchestration plutôt qu’un simple serveur.
Ouverture vers d’autres environnements
D’autres environnements existent, avec des approches parfois différentes. Node.js, tout comme Tomcat (Java), ColdFusion ou ASP.NET, propose sa propre manière d’organiser la réception des requêtes et leur traitement. Certains regroupent plusieurs rôles dans un même outil, d’autres s’appuient sur des architectures plus segmentées.
Dans ce chapitre, nous ne détaillons pas ces environnements afin de ne pas disperser la compréhension. Nous les situons simplement pour montrer que plusieurs modèles coexistent, tout en reposant sur une même logique : recevoir une requête, la traiter, puis produire une réponse. Ces alternatives pourront être explorées séparément, selon les besoins du projet ou les choix techniques retenus.
Une grille de lecture simple
Quel que soit l’outil utilisé, on retrouve toujours la même mécanique. Recevoir une requête, la traiter, puis renvoyer une réponse. C’est cette grille de lecture qui permettra d’aborder la suite avec plus de recul et de cohérence. Cette organisation des rôles se retrouvera dans les différents environnements que nous allons maintenant explorer.
Les environnements d’un projet web : local, test et production
Un projet web existe rarement en un seul exemplaire. Il traverse plusieurs étapes, qui correspondent à différents environnements.
- L’environnement local constitue notre espace de travail. Il est installé sur notre ordinateur. Nous y expérimentons, nous testons, et nous corrigeons. Cet environnement nous appartient entièrement. Il peut contenir des erreurs, sans conséquence extérieure.
- L’environnement de test, parfois appelé préproduction, constitue une étape intermédiaire. Il permet de vérifier le comportement du site dans des conditions proches de la réalité, sans exposer les visiteurs à des dysfonctionnements.
- Enfin, l’environnement de production correspond à la version publique. C’est celui que les visiteurs consultent.
Cette distinction explique une situation très courante : un site peut fonctionner en local et rencontrer des difficultés en production. Les chemins peuvent différer. La configuration peut changer. Certaines fonctions peuvent être désactivées. Dans la majorité des cas, cela provient d’une différence d’environnement : configuration serveur, permissions, chemins ou versions des outils.
Dans ce contexte, les outils d’observation prennent tout leur sens. Les DevTools permettent d’identifier une requête en erreur, un fichier non chargé ou un code HTTP inattendu. Les logs serveur, de leur côté, apportent un éclairage complémentaire sur ce qui se passe réellement côté serveur. Ce croisement d’informations permet souvent de comprendre rapidement ce qui différencie un environnement local d’un environnement de production, et donc de corriger plus efficacement les problèmes rencontrés.
Comprendre ces environnements permet d’adopter une méthode plus rigoureuse. Nous développons en local. Nous validons en test. Nous publions en production. Le projet cesse d’être un simple dossier. Il devient un système vivant, qui évolue progressivement.
Travailler avec un serveur local
Comme nous l’avons vu précédemment, dès qu’un fichier est placé sur un serveur et qu’une requête est envoyée, une relation s’installe. Le navigateur joue le rôle de client. Il formule la demande, et un serveur distant lui répond en renvoyant les fichiers ou les données nécessaires. Ce dialogue constitue le fondement du web et rend un projet accessible depuis l’extérieur.
Au début de ce parcours, notre ordinateur suffit pour écrire, tester et corriger toute la partie qui explore les langages côté client. Le navigateur interprète directement les fichiers et nous pouvons observer immédiatement le résultat de nos modifications. Mais dès que notre travail nécessite des technologies serveur, comme PHP ou une base de données, notre environnement doit évoluer pour être capable de les exécuter.
Dans un premier temps, nous pouvons Installer et configurer un serveur web en local. Cette étape nous permet d’étendre les capacités de notre machine et de reproduire, chez nous, le fonctionnement réel d’un serveur. Nous continuons à travailler dans un cadre maîtrisé, tout en découvrant de nouvelles mécaniques liées au traitement des requêtes, à la génération dynamique des pages, et aux échanges avec d’autres ressources.
Mais rapidement, les besoins d’un véritable serveur distant vont apparaître. Par exemple, nous pouvons souhaiter partager notre travail, le rendre accessible depuis différents appareils ou vérifier son comportement dans des conditions réelles. Ce passage vers un serveur en ligne ne marque pas la fin de l’apprentissage, il en constitue une étape naturelle : relier notre environnement local à un environnement accessible, afin de confronter le projet à son usage réel.
Utiliser Node.js en local
Lorsque l’objectif est de tester rapidement des pages HTML, des styles CSS ou des scripts JavaScript, il n’est pas toujours nécessaire de mettre en place toute une pile PHP. Un serveur Node.js peut alors être utilisé pour servir des fichiers statiques en quelques secondes, avec une configuration minimale. Cette approche devient également intéressante dès que l’on souhaite exposer des données au format JSON ou construire une API légère. Les articles suivants permettent d’explorer concrètement cette mise en place :
- Créer un serveur Node rapide pour servir des fichiers statiques
- Connecter Node.js à une base MySQL pour fournir des données JSON
- Node.js : de la requête simple à une API plus souple, jointures, paramètres et affichage dynamique
Il est toutefois important de lever une ambiguïté fréquente : si Node.js peut suffire pour servir des fichiers ou exposer des données, l’usage d’une base MySQL nécessite toujours l’installation d’un serveur de base de données. En local, cela passe souvent par des outils comme XAMPP, WAMP ou MAMP, qui fournissent MySQL indépendamment de Node.
Autrement dit, Node.js peut alléger la mise en place côté serveur pour certains usages, mais il ne remplace pas à lui seul l’ensemble des briques nécessaires dès que l’on travaille avec des bases de données relationnelles.
Les différentes formes d’hébergement web
Lorsque nous quittons l’environnement local pour envisager une mise en ligne, une question concrète apparaît : sur quel type de serveur allons nous héberger notre projet, et dans quelles conditions ? Les prestataires proposent plusieurs formes d’hébergement, chacune correspondant à un niveau de contrôle, de complexité et de responsabilité différent. Encore faut il comprendre ce dont nous avons réellement besoin pour faire un choix cohérent avec le projet.
- Hébergement mutualisé : Plusieurs sites partagent la même machine. Les configurations générales sont communes et les ressources sont réparties entre les différents projets présents sur le serveur. Cette solution reste peu coûteuse et simple à mettre en place, ce qui la rend adaptée aux projets d’apprentissage, sites personnels ou applications de petite taille.
- Serveur VPS (Virtual Private Server) : La machine physique reste partagée, mais chaque projet dispose d’un environnement isolé. Chaque instance possède ses propres ressources et ses propres réglages. Cette autonomie offre davantage de liberté pour adapter l’infrastructure, tout en conservant un coût généralement accessible.
- Serveur dédié : La machine entière est réservée à un seul projet ou à une seule organisation. Toutes les ressources sont disponibles et la configuration peut être entièrement maîtrisée. Cette solution offre le contrôle maximal, mais implique aussi **des coûts plus élevés et une gestion technique plus exigeante.
- Cloud (IaaS / PaaS) : Les ressources sont provisionnées à la demande sur des infrastructures distribuées. Des plateformes comme AWS, Microsoft Azure ou Google Cloud permettent de créer des serveurs, des bases de données ou des services managés en quelques minutes. Cette approche offre élasticité et haute disponibilité, avec une facturation souvent à l’usage, mais demande une bonne compréhension de l’architecture pour être maîtrisée.
Il est important de distinguer ces solutions distantes du serveur local que nous installons sur notre propre machine. Le serveur local reste un outil d’apprentissage et de préparation. Il permet de comprendre, tester et construire dans un cadre maîtrisé. Mais il ne remplace pas un hébergement en ligne, qui seul permet de confronter un projet à des conditions réelles d’accès et d’usage.
Le choix d’un hébergeur devient alors une question concrète, qui accompagne naturellement la mise en place de notre environnement. Pour approfondir ces aspects, l’article Choisir son hébergeur propose un éclairage complémentaire.
Comprendre cette articulation entre développement local et publication distante permet de situer notre travail dans son contexte réel. Nous ne préparons pas seulement des fichiers. Nous préparons des applications destinées à être exécutées ailleurs, sur des serveurs, et accessibles depuis d’autres navigateurs que le nôtre.
Interfaces d’administration
Avant d’entrer dans les outils eux-mêmes, il peut être utile de voir un aperçu concret de ces interfaces, pour comprendre à quoi ressemble réellement l’administration d’un serveur au quotidien. Lorsque l’on arrive sur un serveur pour la première fois, on se retrouve souvent face à une question très concrète : comment le piloter sans tout faire en ligne de commande ? C’est précisément le rôle des panneaux d’administration.
Dans de nombreux environnements d’hébergement, l’administration passe par des interfaces graphiques comme cPanel, Plesk, ou d’autres solutions équivalentes. On rencontre fréquemment DirectAdmin, ISPConfig, Webmin / Virtualmin, HestiaCP, CyberPanel ou encore CentOS Web Panel (CWP).
Ces outils agissent comme un tableau de bord du serveur. Ils permettent, depuis une interface claire, de créer un domaine, configurer une base de données, gérer des comptes FTP, installer un certificat HTTPS ou ajuster certains services. Autrement dit, ils traduisent des opérations techniques parfois complexes en actions accessibles, sans avoir à modifier directement les fichiers de configuration du système.
Ils ne remplacent pas la compréhension du serveur, mais ils en facilitent grandement l’usage au quotidien, en particulier dans les premières phases d’un projet. La majorité des hébergeurs s’appuient sur des panneaux comme cPanel ou Plesk pour administrer les serveurs. Pour situer leurs différences, leurs avantages et leurs limites, l’article suivant propose une comparaison détaillée : Plesk ou cPanel ? Lequel choisir en 2026 ? Guide complet
Du nom de domaine à la machine : comprendre le rôle du DNS
Lorsque nous saisissons une adresse dans le navigateur, nous utilisons un nom lisible, par exemple puce-et-media.com. Un nom de domaine se décompose en plusieurs parties. Dans www.puce-et-media.com, puce-et-media est le nom choisi, .com l’extension, appelée domaine de premier niveau (TLD), et www un sous-domaine facultatif. Pour nous, cela forme une adresse claire. Pour les machines, il faut une adresse numérique, une adresse IP qui se présente généralement sous la forme de 192.0.2.1. Le DNS assure cette traduction en associant le nom à une adresse IP, ce qui permet d’atteindre la machine qui héberge le service.
Ce principe ne concerne pas uniquement les pages web. Il s’applique à l’ensemble des services accessibles via un domaine, messagerie, transferts de fichiers, accès distants, API ou bases de données. Dans tous les cas, une même logique s’applique, passer d’un nom compréhensible à une adresse exploitable par les machines.
Enregistrer et gérer un nom de domaine
Pour utiliser un nom de domaine, il faut passer par un registrar. Il s’agit d’un acteur habilité à enregistrer des noms auprès des autorités compétentes. En France, l’AFNIC gère par exemple le .fr. Pour d’autres extensions comme .com, .net ou .org, la gestion relève d’organismes internationaux (registries), et des sociétés comme Gandi, OVHcloud, Hostinger ou Namecheap proposent l’enregistrement et la gestion de ces domaines. Dans la pratique, les hébergeurs intègrent souvent cette étape, ce qui donne l’impression d’un achat direct, voir haisoft.net/reserver-un-domaine. En réalité, un nom de domaine est loué pour une durée limitée et doit être renouvelé régulièrement.
Chaque domaine possède également des informations publiques accessibles via le WHOIS. Ce service permet d’identifier plusieurs rôles : le titulaire du domaine, le contact administratif et le contact technique. Selon les configurations, ces informations peuvent être partiellement masquées pour des raisons de confidentialité. Dans la pratique, de nombreux outils en ligne comme Whois.com, Who.is ou DomainTools proposent un accès rapide à ces informations. Il s’agit d’agrégateurs qui interrogent différentes sources. Pour une consultation directe, il est aussi possible de passer par les registres officiels, comme l’AFNIC pour les domaines en .fr ou les services liés à l’ICANN pour les extensions génériques.
DNS, enregistrements et configuration
Le fonctionnement du DNS repose sur les serveurs de noms, souvent appelés DNS1 et DNS2. Ils indiquent où sont stockées les informations de résolution du domaine. Une fois cette base définie, différents enregistrements peuvent être utilisés, A, AAAA, CNAME, MX ou TXT, afin de diriger précisément les services associés au domaine. Leur détail relève davantage de l’administration réseau et pourra être approfondi séparément.
Cette correspondance doit également exister côté serveur. Le domaine pointé par le DNS doit être reconnu par le serveur web qui héberge le site, via une configuration locale appelée hôte virtuel. En pratique, des interfaces comme Plesk ou cPanel permettent d’associer un nom de domaine à un espace, un dossier et des paramètres d’exécution. Sans cette correspondance, le domaine peut bien pointer vers une machine, mais ne saura pas quel contenu servir.
Vérifier et propager les modifications
Pour vérifier qu’un domaine est correctement configuré, des outils en ligne permettent de contrôler la propagation des enregistrements et d’identifier d’éventuelles erreurs. Par exemple, un service comme DNS Checker permet de visualiser la résolution d’un domaine depuis différents points du réseau. Cette étape est souvent nécessaire après une modification, le temps que les informations se diffusent sur l’ensemble du réseau.
Externaliser la gestion du DNS
Enfin, il est possible de confier la gestion du DNS à un service spécialisé, on parle alors de DNS cloud. L’idée est simple, au lieu de gérer soi-même ses serveurs DNS chez son hébergeur, on utilise une infrastructure déjà en place, répartie sur plusieurs serveurs dans différents endroits. Des services comme ClouDNS, DNS Cloudflare ou Google Cloud DNS proposent ce type d’infrastructure. Concrètement, cela rend la résolution plus fiable, si un serveur tombe, un autre prend le relais, et facilite la gestion, notamment lorsque l’on a plusieurs domaines ou des configurations plus complexes.
Revenir à la requête
Une fois le nom résolu en adresse IP, la requête peut réellement commencer : le navigateur sait désormais où envoyer sa demande. Nous pouvons alors revenir à la structure des adresses et observer comment une URL guide la requête, depuis le protocole jusqu’à la ressource cible, et comment elle est interprétée par le navigateur.
URL, URI et structure des adresses sur le web
Chaque ressource sur le web possède une adresse. Cette adresse permet au navigateur de localiser et de demander un contenu précis. Une URL se compose généralement de plusieurs éléments : le protocole, le nom de domaine, le chemin vers la ressource et parfois des paramètres supplémentaires.
Comprendre la structure d’une URL permet de mieux saisir comment les informations circulent entre le navigateur et le serveur, et comment une application web organise ses pages et ses ressources.
Lorsqu’un utilisateur saisit une adresse comme www.exemple.com, le navigateur ne connaît pas directement l’emplacement du serveur. Le DNS (Domain Name System) intervient alors pour traduire ce nom de domaine en adresse IP, c’est‑à‑dire la machine qui héberge réellement le site. Sans ce mécanisme, aucune adresse web ne fonctionnerait.
Pour approfondir ces notions et clarifier les différences entre URI, URL et URN, les deux articles suivants permettent de poser des repères plus précis et de comprendre comment ces identifiants sont utilisés concrètement dans une application web, URI, URL, URN : Comprendre les bases des identifiants sur le web et Comprendre l’Utilisation des URN dans une Application Web .
Le protocole HTTP et HTTPS : comment les navigateurs dialoguent avec les serveurs
Le protocole HTTP définit les règles de communication entre le client et le serveur. Il organise l’ensemble du dialogue qui permet à un navigateur de demander une ressource et à un serveur d’y répondre. Ce protocole ne se limite pas à quelques méthodes comme GET ou POST. Il décrit une structure complète de requête et de réponse : les méthodes utilisées, les en-têtes envoyés par le client, les informations retournées par le serveur, ainsi que les codes de statut qui indiquent le résultat de l’opération, voir Les Méthodes HTTP dans REST : Une approche pratique.
Chaque chargement de page, chaque appel d’API, chaque téléchargement d’image ou de feuille de style repose sur ce mécanisme. HTTP devient ainsi le langage commun qui permet aux navigateurs, aux serveurs et aux applications de dialoguer. HTTP devient ainsi le langage commun qui permet aux navigateurs, aux serveurs et aux applications de dialoguer. Ce dialogue n’est toutefois pas totalement libre. Lorsque JavaScript tente d’interroger une ressource située sur un autre domaine, certaines règles de sécurité viennent encadrer ces échanges. Ce mécanisme, appelé CORS (Cross-Origin Resource Sharing), ne bloque pas le chargement de ressources comme des images ou des feuilles de style, mais il contrôle l’accès aux données lorsque celles-ci sont manipulées par le script. Nous y reviendrons plus en détail dans l’article « CORS ou la gestion des requêtes Cross-Origin ».
HTTPS reprend exactement ce fonctionnement mais ajoute une couche de chiffrement afin de sécuriser les échanges entre le client et le serveur, voir Migrer son site de HTTP vers HTTPs. Ce chiffrement repose sur des certificats SSL/TLS. Ils permettent au navigateur non seulement de chiffrer les données, mais aussi de vérifier l’identité du serveur auquel il se connecte. Aujourd’hui, ces certificats sont très souvent générés automatiquement via des services comme Let’s Encrypt ou fournis par des plateformes comme Cloudflare. Il existe également des certificats payants proposés par différentes autorités de certification, Les 7 meilleurs fournisseurs de certificats SSL pour 2025.
Il est important de comprendre un point souvent mal interprété : le niveau de chiffrement est le même entre un certificat gratuit et un certificat payant. La différence ne se situe pas dans la sécurité du transport, mais dans les services associés. Les certificats payants peuvent inclure des garanties supplémentaires, notamment des assurances en cas de faille ou d’usurpation, ainsi que des niveaux de validation plus poussés (validation d’entreprise, identité visible, etc.).
Dans la pratique, pour la grande majorité des projets web, les solutions gratuites comme Let’s Encrypt ou Cloudflare sont largement suffisantes pour assurer un niveau de sécurité élevé et conforme aux standards actuels.
Les réponses HTTP et les codes de statut
Lorsque le serveur reçoit une requête, il ne renvoie pas simplement un fichier : il construit une réponse structurée. Cette réponse constitue la seconde partie du dialogue HTTP entre le navigateur et le serveur. Dans le cas le plus simple, le serveur renvoie un document HTML. Le navigateur l’interprète, reconstruit la page, télécharge les feuilles de style, les images et les scripts nécessaires, puis affiche le résultat.
Mais les réponses peuvent prendre d’autres formes. Un serveur peut renvoyer des données JSON utilisées par JavaScript pour mettre à jour l’interface sans recharger la page. Mais les réponses peuvent prendre d’autres formes. Un serveur peut renvoyer des données JSON utilisées par JavaScript pour mettre à jour l’interface sans recharger la page. Ces échanges prennent souvent la forme d’API structurées selon des principes comme REST, qui organisent les routes, les méthodes HTTP et les réponses de manière cohérente. Pour approfondir cette approche, voir l’article « Comprendre le concept de REST pour le développement d’applications web efficaces ».
Il peut aussi envoyer une redirection qui indique au navigateur de charger une autre adresse. Chaque réponse contient également un code de statut. Ce code indique comment la requête s’est déroulée, voir Statuts et Gestion HTTP : Comprendre les Codes de Statut et Leur Utilisation Efficace. Un code 200 signifie que la ressource a été trouvée et renvoyée correctement. Un 404 indique que la ressource demandée n’existe pas. Un 500 signale qu’une erreur s’est produite côté serveur, pour aller plus loin voir Statuts et Gestion HTTP : Comprendre les Codes de Statut et Leur Utilisation Efficace.
Ces informations restent généralement invisibles pour l’utilisateur, mais elles apparaissent clairement dans les outils réseau du navigateur. Les observer permet de comprendre ce qui se passe réellement derrière l’affichage d’une page.
Un site web cesse alors d’être perçu comme un ensemble de pages statiques. Il devient une succession d’échanges entre un navigateur qui pose des questions et un serveur qui renvoie des réponses structurées.
Les outils réseau : observer ce qui circule réellement
Lorsque nous développons un site web, une grande partie de ce qui se passe entre le navigateur et le serveur reste invisible. Les requêtes circulent, les réponses reviennent, des ressources sont téléchargées, des erreurs peuvent apparaître, et tout cela se produit sans que l’utilisateur ne voie réellement ces échanges. Pour comprendre ce qui se passe derrière l’affichage d’une page, les développeurs disposent de plusieurs outils d’observation. Certains sont intégrés directement dans le navigateur, d’autres se trouvent du côté du serveur. Ensemble, ils permettent d’analyser le dialogue complet entre le client et le serveur.
Les DevTools du navigateur
Les navigateurs modernes intègrent des outils de développement très complets, souvent appelés DevTools, Chrome DevTools – Chrome for Developers. Ils permettent d’observer et d’analyser le comportement d’un site directement depuis le navigateur. Ces outils deviennent rapidement indispensables pour comprendre ce qui se passe réellement lorsqu’une page se charge. Plusieurs onglets sont particulièrement utiles.
- Elements / Inspector — cet onglet permet d’examiner la structure réelle du document HTML (le DOM) et les styles CSS appliqués aux éléments. Il devient très utile pour comprendre comment une page est construite et pour tester rapidement des modifications de style ou de structure directement dans le navigateur.
- Console — elle affiche les messages JavaScript, les erreurs et les avertissements. Elle permet aussi d’exécuter du code directement dans la page afin de tester un comportement ou inspecter une variable.
- Network — cet onglet montre toutes les requêtes effectuées par la page : fichiers HTML, CSS, scripts, images, appels API. On peut y observer les méthodes HTTP, les codes de statut, la taille des ressources et le temps de réponse du serveur.
- Application / Storage — ces sections permettent d’examiner les données stockées dans le navigateur : cookies, localStorage, sessionStorage ou encore certaines bases de données locales utilisées par des applications web.
- Performance — certains outils permettent également d’analyser le temps de chargement d’une page, l’exécution des scripts ou encore les différentes étapes du rendu. Cela aide à identifier les ressources trop lourdes ou les scripts qui ralentissent l’affichage.
- Lighthouse — intégré à de nombreux navigateurs, cet outil génère un rapport d’audit complet sur un site : performance, accessibilité, bonnes pratiques et référencement. Il permet d’obtenir une vision globale de la qualité technique d’une page.
Ces outils offrent une vision très concrète du dialogue entre le navigateur et le serveur. Ils permettent d’identifier une erreur JavaScript, une ressource manquante ou une requête qui prend trop de temps.
Logs serveur
Au-delà des outils du navigateur, les logs serveur constituent une autre source d’information essentielle. Les serveurs comme Apache ou Nginx enregistrent les requêtes reçues, les erreurs rencontrées et différents événements techniques. Consulter ces journaux permet souvent de comprendre l’origine d’un problème qui ne serait pas visible uniquement depuis le navigateur.
Ces journaux complètent donc l’analyse réalisée dans les DevTools : là où le navigateur montre la requête et la réponse du point de vue du client, les logs permettent d’observer ce qui s’est réellement produit du côté du serveur. Observer ces deux sources d’information transforme notre manière de travailler. Nous ne regardons plus seulement le résultat affiché dans le navigateur : nous analysons la conversation complète entre le client et le serveur.
Outils de test d’API
Lorsqu’un projet utilise des API, il devient souvent nécessaire d’envoyer des requêtes HTTP manuellement afin de tester un service, vérifier une réponse JSON ou reproduire un appel spécifique. Des outils comme Postman ou Insomnia permettent de construire ces requêtes, d’ajouter des en-têtes, d’envoyer des données et d’examiner précisément la réponse du serveur, voir Postman et Insomnia : deux outils incontournables pour tester vos APIs.
Outils réseau système
En dehors du navigateur, certains outils réseau classiques peuvent aussi aider à diagnostiquer un problème d’accès à un serveur.
- ping permet de vérifier si une machine répond sur le réseau.
- traceroute (ou
tracertselon les systèmes) permet d’observer le chemin parcouru par les paquets jusqu’au serveur.
La commande tracert permet d’observer le chemin parcouru par une requête jusqu’au serveur, chaque ligne correspondant à une étape :
- 1 →
192.168.1.254, le routeur local avec une latence quasi nulle ; - 2 → premier relais du fournisseur d’accès (
isdnet.net), avec un temps cohérent autour de 12 ms ; - 3 → routeur intermédiaire silencieux, qui ne répond pas mais laisse passer les paquets ;
- 4 → infrastructure de transit (
online.net) ; - 5 → nouvel équipement non répondant ;
- 6 → passage par un point d’échange (
franceix.net), nœud clé d’interconnexion ; - 7 → routeur invisible ;
- 8 → serveur final (
haisoft.net), atteint en ~17 ms ; ce parcours montre que la requête traverse plusieurs couches du réseau, certaines visibles, d’autres non, avant d’atteindre sa destination.
Ces outils ne remplacent pas les DevTools du navigateur, mais ils apportent un éclairage complémentaire lorsque l’on cherche à comprendre un problème de connexion ou de réseau. Pour aller plus loin et tester directement des requêtes HTTP depuis la ligne de commande, nous pouvons également utiliser des outils dédiés comme cURL ou HTTPie. L’article suivant présente leur installation et leur usage de base, Installer des Outils pour la Console : cURL et HTTPie.
Permissions et chmod
Sur un serveur, chaque fichier et chaque dossier possède des permissions qui définissent qui peut lire, modifier ou exécuter une ressource. Trois profils sont concernés : le propriétaire (vous), le groupe (souvent l’utilisateur du serveur web) et les autres, Modifier le chmod, vous avez dit chmod ?.
Les droits se résument à lecture (r), écriture (w) et exécution (x). La notation numérique de chmod est additive : 4 = lecture, 2 = écriture, 1 = exécution. On combine ces valeurs pour former un chiffre : 7 (4+2+1) = tous les droits, 6 (4+2) = lecture + écriture, 5 (4+1) = lecture + exécution, 4 = lecture seule. Les permissions s’écrivent ensuite sur trois chiffres, par exemple 755 ou 644 (propriétaire / groupe / autres).
Concrètement, un dossier en 755 permet au serveur d’y accéder (lecture/exécution) tout en réservant la modification au propriétaire. Un fichier en 644 est lisible par tous mais modifiable uniquement par son propriétaire. Ce duo (755 pour les dossiers, 644 pour les fichiers) couvre la majorité des cas. Des valeurs plus ouvertes comme 777 (tout le monde peut tout faire) doivent rester exceptionnelles, car elles exposent le projet. À l’inverse, 700 limite l’accès au seul propriétaire pour des éléments sensibles.
Comprendre cette logique permet de résoudre des problèmes très concrets : script qui ne s’exécute pas, fichier inaccessible ou upload qui échoue.
Le rôle du fichier .htaccess
Dans les environnements utilisant Apache, le fichier .htaccess permet de modifier certains comportements du serveur directement depuis le projet. Ces règles s’appliquent directement au niveau du serveur Apache. Il agit comme une couche de configuration locale, sans avoir à toucher aux fichiers globaux du serveur.
Plutôt que de rester théorique, regardons quelques usages très courants.
# Désactiver l'affichage du contenu d'un dossier (sécurité minimale)
# Sans cela, Apache peut afficher la liste des fichiers si aucun index n'est présent
Options -Indexes
# Redirection simple (ex : ancienne page vers nouvelle)
# 301 = redirection permanente (SEO)
Redirect 301 /ancienne-page.html /nouvelle-page.html
# Forcer HTTPS
# Si la requête n'est pas en HTTPS, on redirige vers la version sécurisée
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
# Réécriture d'URL (URL propre)
# /article/mon-titre → article.php?slug=mon-titre
RewriteRule ^article/([a-zA-Z0-9-]+)$ article.php?slug=$1 [L]Un autre usage très fréquent concerne la protection d’un dossier à l’aide d’un couple .htaccess / .htpasswd.
# Fichier .htaccess
# Active une authentification basique sur un dossier
AuthType Basic
AuthName "Accès restreint"
# Chemin vers le fichier contenant les identifiants
AuthUserFile /chemin/absolu/.htpasswd
# Seuls les utilisateurs déclarés peuvent accéder
Require valid-userLe fichier .htpasswd contient alors les identifiants (généralement chiffrés) :
# fichier .htpasswd
# format : utilisateur:mot_de_passe_chiffré
admin:$apr1$abcd1234$xyz...Enfin, .htaccess permet aussi de gérer certaines erreurs HTTP.
# Personnaliser les pages d'erreur
ErrorDocument 404 /404.html # page non trouvée
ErrorDocument 403 /403.html # accès interdit
ErrorDocument 500 /500.html # erreur serveurCes quelques exemples couvrent une grande partie des besoins du quotidien : sécuriser un accès, rediriger des pages, améliorer les URL, ou gérer des erreurs. Même sans maîtriser toute la syntaxe, comprendre ces mécanismes permet déjà d’agir concrètement sur le comportement d’un site une fois en ligne.
L’exemple présenté dans l’article Mettre en place une protection minimale propose une protection minimale appliquée à un site WordPress. Cependant, il est important de noter que les règles .htaccess restent totalement polyvalentes et peuvent être utilisées dans de nombreux contextes, bien au-delà d’un CMS spécifique.
FTP et le transfert de fichiers
Une fois un projet prêt à être publié, il doit être transféré vers le serveur distant. Historiquement, ce transfert s’effectue grâce au protocole FTP. FTP permet d’envoyer des fichiers depuis notre machine vers un serveur, mais aussi de consulter les fichiers présents sur ce serveur, de les modifier ou de les supprimer.
De nombreux outils existent pour effectuer ces transferts : clients FTP dédiés comme FileZilla, Cyberduck, UltraFTP, extensions d’éditeurs de code comme SFTP pour VSC ou SFTP pour SublimeText, ou outils intégrés à certains environnements de développement comme l’illustration ci-dessous de l’environnement FTP de Dreamweaver.
Même si d’autres méthodes de déploiement existent aujourd’hui, comprendre FTP reste utile pour saisir la logique du transfert de fichiers entre un environnement local et un serveur distant, voir Gestion et client FTP.
Un point de vigilance fréquent concerne les chemins de fichiers.
Un chemin qui fonctionne en local ne fonctionne pas forcément une fois le projet envoyé sur le serveur, car le point de départ peut changer. En local, nous travaillons souvent dans un dossier de projet assez lisible. Sur un hébergement, le site peut au contraire être publié dans un répertoire spécifique comme public_html, www, htdocs ou httpdocs.
# Exemple local
C:/xampp/htdocs/mon-site/images/logo.png
# Exemple distant
/home/compte/public_html/images/logo.png
# Le fichier est le même,
# mais son emplacement de départ n'est plus du tout identique.Cette différence devient encore plus visible dès que l’on manipule des chemins absolus dans le code.
<?php
// Cas fréquent : chemin écrit en dur pour l'environnement local
$image = 'C:/xampp/htdocs/mon-site/images/logo.png';
// Ce chemin fonctionne sur l'ordinateur du développeur,
// mais devient invalide une fois le projet transféré sur le serveur.Il est donc souvent préférable de s’appuyer sur des chemins relatifs, ou sur des constantes construites à partir du projet lui-même.
<?php
// __DIR__ représente le dossier du fichier courant
// On construit ensuite un chemin adaptable à l'environnement
$image = __DIR__ . '/images/logo.png';
// Cette approche reste beaucoup plus portable
// entre local, test et production.Le même type de différence peut apparaître avec les URLs si un projet n’est pas installé à la racine du serveur.
<?php
// En local, le projet peut être accessible ici :
// http://localhost/mon-site/
// En production, il peut être accessible directement à la racine :
// https://www.exemple.com/
// Une URL écrite en dur peut donc casser des liens,
// des images ou des redirections.Comprendre cette différence entre arborescence locale et arborescence distante évite une situation très fréquente : un projet qui fonctionne parfaitement sur l’ordinateur du développeur, mais plus une fois envoyé sur le serveur. Cela concerne aussi bien les fichiers, les uploads, les images que certaines inclusions PHP.
Accéder à un serveur avec SSH
Au-delà du transfert de fichiers, il est souvent nécessaire d’accéder directement au serveur pour administrer un projet. C’est le rôle du protocole SSH (Secure Shell). SSH permet d’ouvrir une session distante sur une machine à partir d’un terminal. Une fois connecté, il devient possible de consulter les fichiers du serveur, d’exécuter des commandes, de vérifier les logs, de modifier des permissions ou encore de lancer certains scripts de déploiement. Une connexion SSH ressemble généralement à ceci :
ssh utilisateur@serveur
Sur certains systèmes, notamment sous Windows, il est aussi possible d’utiliser un client graphique comme PuTTY. Cet outil permet d’établir facilement une connexion SSH vers un serveur distant sans passer directement par la ligne de commande. PuTTY reste l’un des clients SSH les plus connus et les plus utilisés dans l’écosystème Windows.
Contrairement à FTP, qui se concentre principalement sur le transfert de fichiers, SSH offre un accès complet à l’environnement du serveur. Il est donc très utilisé pour administrer une machine, installer des dépendances ou intervenir rapidement lorsqu’un problème survient.
Dans de nombreux projets modernes, SSH joue également un rôle dans le déploiement du code. Les dépôts Git peuvent être synchronisés avec un serveur via des clés SSH, ce qui permet d’effectuer des mises à jour sécurisées sans passer par un transfert manuel de fichiers. Comprendre le rôle de SSH permet ainsi de relier plusieurs notions vues dans ce chapitre : les permissions, les logs serveur, l’accès distant et les mécanismes de déploiement.
Git et le déploiement des projets
Au fur et à mesure qu’un projet évolue, la gestion des versions devient indispensable. Git offre une manière fiable de garder une trace précise des modifications apportées au code. Chaque changement peut être enregistré sous la forme d’un commit, c’est‑à‑dire une étape dans l’histoire du projet. Si une erreur apparaît, il devient alors possible de revenir à un état précédent du code.
Il devient également possible de travailler sur plusieurs pistes de développement grâce aux branches. Une branche peut servir à expérimenter une nouvelle fonctionnalité, corriger un bug ou tester une idée sans perturber la version principale du projet. Une fois le travail validé, la branche peut être fusionnée avec la version principale. Concrètement, cela permet de travailler sans crainte de casser le projet.
Dans de nombreux projets modernes, Git s’impose aussi comme point central pour le déploiement. Le code est enregistré dans un dépôt, puis synchronisé vers un serveur ou une plateforme d’hébergement. Cette approche remplace progressivement les transferts manuels de fichiers et sécurise l’évolution d’un projet sur le long terme. Pour aller plus loin sur Git, voici une série d’articles complémentaires :
• Démystifier Git : à quoi ça sert vraiment ? – Puce et Média
• Préparer Git côté local : démarrer dans de bonnes conditions – Puce et Média
• Premiers pas avec Git : suivre l’évolution d’un site simple – Puce et Média
• Explorer, tester, corriger : aller plus loin avec Git en solo – Puce et Média
• GitHub : explorer l’interface avant de connecter un projet – Puce et Média
• GitHub : travailler seul ou à plusieurs depuis un dépôt distant – Puce et Média
FTP, Git… ou les deux ? Organiser le déploiement d’un projet web
Après avoir découvert les différents outils liés au serveur, une question apparaît naturellement : comment organiser concrètement le travail dans un projet réel ?
Dans la pratique, plusieurs méthodes coexistent. Certains projets reposent encore sur un transfert direct des fichiers par FTP. D’autres utilisent Git pour suivre les modifications et synchroniser le code entre plusieurs machines. Dans de nombreux cas, les deux approches peuvent même cohabiter. L’important n’est pas seulement l’outil utilisé, mais la manière dont l’équipe organise son travail et la circulation du code entre les différents environnements.
Dans un premier temps, il est utile de prendre du recul et d’analyser la situation :
- quel est le contexte du projet
- combien de personnes travaillent sur le code
- existe t il plusieurs environnements comme un serveur local, un serveur de test et un serveur de production
- le projet nécessite t il un suivi précis des modifications
Cette réflexion permet d’éviter une confusion fréquente : Git n’est pas GitHub. Git est un outil de gestion de versions installé sur notre machine. GitHub, GitLab ou Bitbucket sont des plateformes qui permettent d’héberger des dépôts et de collaborer plus facilement.
Un projet web peut alors s’organiser de différentes manières.
- Dans une configuration simple, un développeur travaille sur un serveur local, valide son travail, puis transfère les fichiers vers un serveur distant par FTP.
- Dans une organisation plus structurée, Git devient le point central. Les modifications sont enregistrées sous forme de commits, envoyées vers un dépôt distant, puis déployées sur un serveur de test ou un serveur de production.
Il est également possible d’automatiser certaines étapes. Des scripts ou des outils d’intégration continue peuvent déclencher automatiquement un déploiement après un commit validé. Le code circule alors de manière plus sécurisée entre les différents environnements.
Une organisation typique peut ressembler à ceci :
Chaque projet adopte sa propre méthode. Certains privilégient la simplicité avec FTP. D’autres s’appuient sur Git pour sécuriser les évolutions. L’essentiel est de comprendre comment ces outils peuvent s’articuler pour accompagner le cycle de vie d’un projet web.
De la requête au déploiement : relier les éléments
À ce stade du parcours, il devient utile de prendre du recul et de relier les différentes notions abordées :
- URL, DNS, serveur, HTTP, réponse, outils d’observation, et enfin déploiement. Chacune a été présentée séparément. Pourtant, dans la réalité, tout cela se produit en une seule et même séquence.
- Un utilisateur saisit une adresse dans son navigateur. Cette adresse, une URL, est transmise au DNS, qui permet de retrouver l’adresse réelle du serveur. Une fois cette correspondance établie, le navigateur envoie une requête HTTP à la machine distante.
- Le serveur reçoit cette demande. Selon le projet, il peut simplement renvoyer un fichier, ou bien exécuter du code, interroger une base de données, assembler des données, puis produire une réponse adaptée.
- Cette réponse est ensuite renvoyée au navigateur, qui l’interprète, affiche la page, exécute les scripts et construit l’interface visible par l’utilisateur.
- Pendant tout ce processus, différents outils permettent d’observer ce qui se passe : les DevTools côté navigateur, les logs côté serveur, ou encore des outils réseau plus bas niveau. Ils révèlent un dialogue qui reste sinon invisible.
- Enfin, pour que ce cycle existe, il faut que le code soit présent sur le serveur. C’est le rôle du déploiement, qu’il soit réalisé via FTP, via Git, ou à l’aide de processus automatisés.
Le web apparaît alors pour ce qu’il est réellement : non pas une suite de pages isolées, mais un enchaînement d’échanges, où chaque requête déclenche une réponse, et où chaque projet doit s’inscrire dans cette circulation continue entre le client et le serveur.
Conclusion et ouverture vers la suite
À ce stade du parcours, nous avons posé les bases essentielles pour comprendre comment un projet web devient accessible : relation client / serveur, rôle des protocoles, organisation des environnements, outils d’observation, et mécanismes de déploiement.
Nous avons progressivement quitté le simple cadre du navigateur pour entrer dans une vision plus globale : celle d’un système où plusieurs éléments coopèrent pour produire une réponse à chaque requête. Dans la suite de ce parcours, nous allons franchir une nouvelle étape en nous concentrant sur le traitement côté serveur. Parmi les différents langages possibles, nous avons choisi d’explorer PHP. Ce choix s’inscrit dans une logique pragmatique : PHP est largement utilisé, bien documenté, et particulièrement adapté à la construction d’applications web dynamiques, notamment en lien avec des bases de données.
La Part VI sera donc consacrée à la découverte de PHP : sa syntaxe, son fonctionnement, et son rôle dans la génération de pages dynamiques. Nous verrons comment ce langage s’intègre concrètement dans la mécanique que nous venons de mettre en place, et comment il permet de produire des réponses adaptées à chaque requête.