Développeur web : comprendre les briques pour construire
L’idée de cet article est de raconter une histoire. L’histoire de ce qu’est un développeur web, de ce qu’il fait, de ce qu’il doit connaitre, apprendre, gérer, maitriser, pour développer des sites ou des applications web.
En fait on connait tous, ou du moins avons-nous tous entendu parler, des langages du web, des technologies qui le définissent, des concepts qui le composent. Mais il n’est pas rare d’avoir du mal à les situer, à les assembler, à les articuler entre elles, à les orchestrer. Face à ce constat, pour mieux appréhender et comprendre cet univers, nous pouvons changer l’angle d’approche et partir de ce que nous connaissons le mieux, de ce que nous utilisons tous les jours, afin de l’observer et de le décrypter. Partir simplement du Web, partir du Web lui-même, de son usage.
Que l’on soit jeune ou plus âgé, informaticien ou néophyte, nous l’utilisons tous. Son ergonomie est telle que nul n’a besoin de réelle formation pour cela. Tout y est tellement intuitif que cela parait inné, cela parait naturel. On l’utilise sans se poser de question… ou presque !
L’âge de pierre du numérique : des usages analogiques
Culturellement parlant, il ne faut pas oublier, surtout pour nous en France, que nous sommes partis de loin… de très loin… de l’analogique… Nous avions certes pour certains le téléphone, mais attention, on parle d’un téléphone à cadran, d’un téléphone ancré sur une prise, et pas d’un téléphone que l’on met dans sa poche, qui nous sert à tout et qui sait tout de notre vie… non, nous parlons d’un téléphone qui, en fait, ne servait uniquement qu’à téléphoner.
Puis il y avait aussi le minitel, la vidéo VHS, les plaquettes papier, les brochures… et l’industrie, elle, s’était emparait de tout cela et en avait fait son unique, bien que multiple, moyen de communication… Digitaliser et unifier l’ensemble a été, pour nous français, une tâche qui, aujourd’hui, peut sembler naturelle, presque évidente, mais dont la simplicité apparente est trompeuse, et qui, en réalité, n’a pas été une simple affaire…
D’ailleurs à ses débuts, le slogan de Macromedia, société pionnière en matière de transmission d’outils et de savoir-faire, était : « Create once, publish everywhere », ce qui démontre bien le changement radical de paradigme. Alors pour le comprendre, pour mieux comprendre la révolution du Web et reprendre la main sur ses usages, il nous faut maintenant distinguer les couches, séparer ce qui relève du réseau de ce qui relève de ses usages … posons-nous cette question, « c’est quoi au juste le web ? ».
Aujourd’hui encore, beaucoup confondent, l’Internet et le Web… Internet… le web… c’est du pareil au même. Quelque part, ce n’est pas faux… mais au fond, ce n’est pas tout à fait cela.
Aux origines de l’informatique
Alors recommençons au début. Au début de l’ordinateur. Lorsque la manière de sauvegarder et de transmettre l’information d’un ordinateur à un autre, ou simplement de conserver des données, se faisait en perforant des bandes cartonnées, sur une matrice à peine dissimulée, faite de lignes, de colonnes et de chiffres. Les fameuses cartes Hollerith.
Les écrans, eux, étaient toujours noirs, même lorsqu’ils étaient allumés. On y écrivait en vert, parfois en blanc, en utilisant une typographie monospace de 80 caractères par ligne pour occuper la largeur de l’écran. Seuls des caractères pouvaient être affichés ; les couleurs, comme le dessin, ne serait-ce que sous forme d’icônes, étaient choses impensables. De même, les premières imprimantes perforaient le papier plus qu’elles ne l’imprimaient. Les impressions se faisaient, dans un bruit strident, sur des feuilles se déroulant au kilomètre, et sur trois épaisseurs… l’ordinateur n’était encore réservé qu’à un usage professionnel, dans le monde de l’entreprise.
À cette époque, le matériel occupait alors une place centrale. Des pannes pouvaient même être causées par des insectes attirés par la chaleur des circuits, à l’origine du terme bug, encore utilisé aujourd’hui pour désigner une anomalie. Le clavier était le seul outil qui nous permettait d’entrer de l’information… l’écran, l’impression et la bande cartonnée étaient les seuls moyens d’en sortir. De là, penser à relier un ordinateur à un autre ordinateur devenait une gymnastique qui n’a pu se démocratiser que bien plus tard…
De l’internet au Web : rendre le réseau praticable
Et justement… Ce… bien plus tard… a, paradoxalement, débuté avec les prémisses de l’internet, sous l’appellation d’ARPANET : mais au lieu de relier simplement des ordinateurs entre eux, on a d’abord relié un ordinateur à un réseau central, et ce bien avant de pouvoir généraliser des connexions locales entre machines. Sous l’œil de la DARPA, les universitaires et la recherche poussaient la technologie à transmettre, à communiquer, à échanger, à évoluer.
L’internet naissait, mais seules des machines étaient capables de l’utiliser, sous le contrôle de spécialistes initiés à cet univers qui mêlaient analogique, digital et protocoles obscurs… On parlait aussi de Modem, pour MOdulation, DÉModulation, afin de transformer le signal analogique en numérique et vice versa.
Il fallait donc standardiser, démocratiser, et surtout rendre cela accessible à l’humain, à des non-initiés, à tout un chacun, non pas en modifiant le réseau lui-même, mais en lui ajoutant une couche supplémentaire, pensée pour l’usage. C’est alors que, longtemps après la naissance des premiers réseaux, le Web est apparu en apportant cette couche applicative et multimédia à l’Internet, rendant possible des usages concrets comme cliquer sur un lien, naviguer entre des documents ou accéder à des contenus médias, sans avoir à se soucier de ce qui se passe en arrière-plan.
Le Web apportait ainsi à l’Internet sa dimension applicative et multimédia.
Il faut dire qu’entre temps, les ordinateurs avaient adopté la couleur, le son, l’image, la souris, et même tout une panoplie de périphériques allant de la disquette, au disque dur externe, en passant par les cartouches mémoire qui allaient petit à petit devenir des clés USB.
Internet : un socle de protocoles durables
L’Internet n’a jamais été pensé uniquement pour le Web, et c’est précisément ce que nous allons observer ici, en regardant ce qui circule sous le Web, au-delà de ce que nous voyons à l’écran. Il constitue avant tout un socle commun, sur lequel se sont greffés, au fil du temps, de nombreux services. Le Web en fait partie, mais il cohabite avec d’autres usages invisibles : distributeurs bancaires, téléphonie, messagerie électronique, transferts de fichiers, chaînes de télévision, connexions sécurisées…
Pour que cette diversité puisse fonctionner ensemble, l’Internet a dû se doter d’une langue commune. Cette étape clé a été franchie avec TCP/IP, qui permet, sur un même réseau, aussi bien de consulter une page Web que d’envoyer un courriel ou de transférer un fichier, qui a permis de relier des réseaux différents sans en figer les usages. TCP/IP est ainsi devenu la clé de voûte de l’Internet, lui permettant d’accueillir durablement une pluralité de services, dont le Web n’est qu’un élément parmi d’autres.
En une ou deux décennies, nous sommes passés d’une époque encore balbutiante, aux usages fragiles et contraints, à une utilisation continue et généralisée de l’Internet et du Web. Ce chemin parcouru en si peu de temps est aujourd’hui difficile à imaginer, et cette transparence apparente repose justement sur des briques que nous allons maintenant examiner plus finement, tant l’informatique et les réseaux se sont rendus transparents dans nos usages quotidiens…
Comprendre le Web pour rester autonome
Revenons à l’essentiel. Depuis le début de cet article, nous avons pris le temps d’observer d’où vient le Web et comment il a évolué. Une question se pose alors naturellement : pourquoi chercher à comprendre, alors que l’IA, les templates et les services clés en main permettent aujourd’hui de créer sans trop se poser de questions.
Il serait illusoire de le nier. Les générateurs assistés par IA, les solutions DIY et les thèmes prêts à l’emploi, comme ceux évoqués dans l’article Créer un site avec un template : une solution rapide et fiable, ont rendu la création web largement accessible. Créer un site n’a plus rien d’obscur, et les profils capables de tout faire seuls ont peu à peu laissé place à des outils spécialisés et des services dédiés.
Dans ce contexte, on pourrait conclure que comprendre le Web n’est plus indispensable. Que l’enjeu se limite désormais à produire, publier et avancer vite. Et, en apparence, c’est vrai : on peut faire sans comprendre. Mais c’est précisément là que se joue l’essentiel. Comprendre le Web n’est plus une contrainte technique, c’est un choix. Un choix qui permet de savoir ce que les outils font pour nous, ce qu’ils automatisent, et jusqu’où ils orientent nos décisions.
Revenir aux briques que nous aborderons plus loin dans l’article, requêtes, échanges client-serveur, structuration des données, ce n’est pas revenir en arrière. C’est reprendre la main, passer de l’exécution à la capacité de choix, et décider quand un outil aide… ou quand il enferme. À l’ère de l’IA et des solutions clés en main, apprendre le Web ne sert donc pas seulement à produire plus. Cela permet de rester autonome, lucide, et libre dans la manière de concevoir, de faire évoluer et de maintenir un projet numérique.
Pour mieux décrypter le web, parcourons-le
Si vous continuez de lire, c’est que cette idée vous intéresse. Alors, poursuivons, démystifions… naviguons sur le Web et décryptons au fur et à mesure en observant ce qui se passe derrière l’écran.
En pratique, le Web n’impose que peu de prérequis : une connexion à Internet pour y accéder, et un navigateur pour l’explorer, afin par exemple de saisir une requête ou de valider une adresse. Peu importe le navigateur utilisé. Les plus connus sont Chrome, Firefox, Edge, Safari, Opera… pour ne citer qu’eux.
Mais ils ne sont pas les seuls. Certains sont directement embarqués, par exemple dans les écrans de smart TV ou dans certains appareils du quotidien. D’autres sont purement textuels, comme Lynx ou w3m. Il existe aussi des navigateurs orientés protection et anonymat, comme Tor, qui s’appuie sur son propre réseau, ou encore des versions allégées de toute télémétrie, comme LibreWolf, Mullvad, Brave, Chromium ou SRWare. On trouve également des navigateurs conçus pour des usages spécifiques, notamment pour des personnes en situation de handicap, comme WebVisum.
Sans chercher à être exhaustif, la liste est donc longue, ce qui explique en partie certaines confusions courantes autour des navigateurs et de leurs usages. J’ajouterais simplement une précision, qui permet déjà de distinguer outil, acteur et couche technique. Lorsqu’on pose la question « Quel navigateur utilisez-vous ? », beaucoup répondent « Google ». La réponse est compréhensible, mais incorrecte : Google n’est pas un navigateur.
Du navigateur à la requête
Dès qu’un appareil permet d’afficher des pages, de se connecter à l’internet et d’utiliser un navigateur, l’utilisateur accomplit un premier geste technique, souvent sans en avoir conscience : saisir une adresse ou un mot dans la barre du navigateur, ce qui déclenche l’envoi d’une requête vers une URL. Cette barre unique, souvent appelée barre d’adresse, remplit pourtant deux fonctions distinctes. Lorsqu’on y saisit une URL, le navigateur tente d’accéder directement à une ressource précise.
Mais lorsqu’on y entre un mot, une phrase ou une question en langage naturel, la saisie est généralement transmise au moteur de recherche configuré par défaut. Cette confusion apparente masque une différence fondamentale entre naviguer vers une ressource et interroger un service de recherche, deux usages quotidiens qui reposent sur des mécanismes bien distincts. L’un sert à indiquer une destination précise, en ciblant directement un serveur et une ressource précise, l’autre sert à formuler une demande, en confiant la demande à un service chargé d’explorer et de classer le Web à notre place.
Dès que nous validons une URL, la requête ne part pas directement vers le site visé. Elle passe d’abord par un serveur de DNS, chargé de faire le lien entre une adresse lisible par l’humain et une destination technique exploitable par le réseau. Lorsque nous saisissons une adresse dans la barre du navigateur, qu’elle prenne la forme de http://domaine.fr, de https://domaine.fr ou d’un nom plus court comme domaine.fr, nous utilisons toujours un nom de domaine pensé pour être compris, mémorisé et transmis facilement. Des adresses comme ymct.eu, google.fr, impots.gouv.fr, adobe.com ou help.adobe.com illustrent cette couche de traduction, discrète mais essentielle.
En revanche Internet, lui, utilise des adresses qui sont numéraires, les fameuses adresses IP. Ces adresses se présentent sous la forme de 23.205.220.88 en IPv4 ou 2600:1407:7400::1730:3f2b en IPv6, ce dernier ayant été introduit pour répondre à la saturation progressive des adresses IPv4 et permettre à l’Internet de continuer à se développer. On comprend alors pourquoi ces adresses sont peu adaptées à l’usage humain : elles sont difficiles à mémoriser, à transmettre, et peu pratiques à employer telles quelles. C’est pour cela que les requêtes passent au préalable au travers d’un serveur de DNS, une étape invisible parmi d’autres, que nous allons continuer à suivre pas à pas qui aura la tâche de transformer une requête lisible en adresse IP. Il agit un peu comme un opérateur d’orientation, un annuaire. Si vous souhaitez aller plus loin sur ce point, rapprochez-vous de l’article URI, URL, URN : Comprendre les bases des identifiants sur le web.
HTTP : un langage commun pour le Web
Dès lors que des échanges ont lieu sur le Web, ceux-ci sont encadrés par un protocole commun, qui pose un cadre clair et partagé. Ce rôle est assuré par HTTP, le standard qui définit la manière dont le Web communique sur Internet, voir Statuts et Gestion HTTP : Comprendre les Codes de Statut et Leur Utilisation Efficace. Dans la pratique, ce protocole est aujourd’hui le plus souvent utilisé dans sa version sécurisée, HTTPS, qui ajoute une couche de chiffrement aux échanges, comme détaillé dans l’article Migrer son site de HTTP vers HTTPS.
Ci-dessous, la capture de l’onglet Headers des outils de développement du navigateur illustre concrètement ce cadre. Pour y accéder, il faut d’abord ouvrir les outils de développement du navigateur (touche F12), puis se rendre dans l’onglet Network, recharger la page, sélectionner la requête initiale, par exemple celle correspondant à ymct.eu, et enfin afficher l’onglet Headers.
On y retrouve d’abord les informations générales de la requête, telles que la méthode utilisée, l’URL appelée, le code de réponse ou encore la version du protocole. Ces éléments permettent de comprendre, en un coup d’œil, ce qui a été demandé et ce que le serveur a répondu. Plus bas, les en-têtes HTTP détaillent le contexte de l’échange. Certains décrivent la requête envoyée par le navigateur, d’autres la réponse produite par le serveur. On y trouve notamment des indications sur le type de contenu transmis, la gestion du cache, la sécurité ou les politiques d’échange entre domaines. Cette lecture rend visible une réalité souvent ignorée : avant même d’afficher une page, le Web commence par un dialogue structuré entre client et serveur.
Pour prolonger cette exploration en dehors du navigateur, il est possible d’observer ces mêmes échanges via la ligne de commande, notamment avec des outils comme cURL ou HTTPie, présentés plus en détail dans l’article Installer des Outils pour la Console : cURL et HTTPie, qui permettent d’interroger directement un serveur et d’analyser ses réponses.
Rappelons également que le Web n’est qu’un usage parmi d’autres. Internet constitue un socle commun sur lequel reposent de nombreuses applications, chacune s’appuyant sur un protocole adapté à sa fonction. Ce que nous venons d’observer avec HTTP se retrouve, selon la même logique, à travers les autres couches et protocoles du réseau. Ainsi, FTP est utilisé pour le transfert de fichiers, SMTP pour l’envoi de courriels, POP ou IMAP pour leur réception, Telnet ou SSH pour l’accès à distance, Usenet pour la distribution de forums, et bien d’autres encore.
Ce que nous venons de mettre en lumière, c’est le langage même de l’Internet, un ensemble de règles, de protocoles et d’échanges qui permettent aux machines de se comprendre, bien avant toute interface ou tout affichage.
Bref, après avoir été orientée par le serveur de DNS, la requête arrive enfin sur le serveur de destination.
Les serveurs : là où les requêtes aboutissent
À partir de cet instant, nous quittons le chemin de la requête pour observer l’endroit où elle est reçue, interprétée et traitée : le serveur. Son rôle est simple en apparence, recevoir une demande et renvoyer un contenu. C’est dans ce cadre que s’inscrit la relation client serveur, le client étant ici le navigateur. Sur le Web, les serveurs les plus courants sont Nginx, Apache, IIS… auxquels s’ajoutent d’autres environnements comme Node.js, Tomcat, LiteSpeed ou Gunicorn. Les fichiers d’un site sont généralement déposés sur l’un de ces serveurs, le plus souvent via FTP, voir Gestion et client FTP.
Mais un serveur ne se contente pas de recevoir et servir des fichiers. Il dispose de son propre langage de configuration, qui lui permet d’interpréter les requêtes, de rediriger, de sécuriser ou d’adapter les échanges. Dans la majorité des offres d’hébergement mutualisé, chez OVHcloud, Haisoft, ionos, Lrob ou Planethoster pour ne cite qu’eux, on trouve encore très souvent Apache, parfois seul, parfois associé à Nginx.
Apache s’appuie historiquement sur des mécanismes proches du shell, exposés via des fichiers de configuration comme les .htaccess. Ces fichiers permettent d’agir directement sur le comportement du serveur, redirections, types MIME, sécurité ou cache, sans modifier le code applicatif. De nombreux dispositifs de protection sous WordPress reposent sur ce principe, comme le montre l’article Mettre en place une protection minimale. La documentation rapide disponible sur htaccess-guide.com propose un aperçu clair de ces règles et de leurs effets.
En aparté, on dira, qu’afin de procéder à des tests en local, il est toujours intéressant que le développeur installe un serveur local sur sa propre machine. Il ne s’agit pas d’un serveur accessible sur Internet, mais d’un outil de travail, destiné à simuler le comportement d’un serveur distant pour développer et vérifier les fonctionnalités en cours de développement. Cela passe le plus souvent par l’installation d’un stack Apache ou Node.js, voir Installer et configurer un serveur web en local ou Prendre en main Node.js.
HTML : structurer le sens avant l’affichage
Après avoir traité la demande du client, le serveur renvoie une réponse. Nous l’observons ici du point de vue de ce que reçoit le navigateur, avant toute mise en forme ou affichage à l’écran. Dans le cas d’une page web classique, cette réponse est constituée de HTML, généralement transmis sous la forme d’un document complet.
Ce HTML arrive en premier. Il constitue la base textuelle et structurante de la page. Les autres ressources, feuilles de style, images, typographies ou scripts, ne sont pas encore appliquées. L’onglet Network des outils de développement du navigateur permet d’ailleurs de visualiser clairement cet ordre d’arrivée des ressources.
Le HTML est un format lisible par l’humain, mais surtout structuré, pensé pour organiser le contenu du plus global au plus fin. Il s’appuie sur des balises qui définissent des niveaux successifs : en‑tête, corps de page, navigation, pied de page, puis sections, articles, blocs, titres, paragraphes et liens. À cette structuration s’ajoutent des informations sémantiques, qui ne visent pas l’affichage mais l’interprétation : accessibilité, indexation, compréhension du contenu par des outils automatisés. À ce titre, le HTML constitue un socle essentiel pour les moteurs de recherche, les lecteurs d’écran et les systèmes d’analyse. Voir à ce sujet Les bases du langage HTML et Métadonnées : parler aux humains et aux intelligences artificielles.
Le HTML est parfois perçu comme un langage d’entrée, simple ou secondaire. Cette vision est trompeuse. Il constitue l’un des piliers du Web, celui sur lequel le sens s’organise, et sur lequel toutes les autres couches viennent s’appuyer. Héritier du SGML, tel que l’a conçu Tim Berners‑Lee, il reste aujourd’hui au cœur des usages du Web.
Le Web sans habillage : du DOM au HTML nu
Dès la réception du document HTML, le navigateur commence par produire un premier rendu brut. Il affiche le contenu de manière linéaire, en suivant l’ordre du document, sans styles avancés ni comportements interactifs. Ce rendu correspond à un HTML sans habillage, qui ne porte encore aucune information graphique.
On parle parfois de pages en Naked CSS pour désigner cet état volontairement dépouillé, où seule la structure du contenu est visible, voir ymct.eu en Naked CSS.
Mais ce que fait réellement le navigateur va plus loin qu’un simple affichage. Lorsqu’il reçoit le fichier HTML, il le lit intégralement et le transforme en une structure interne : le DOM (Document Object Model). Chaque balise devient un nœud, chaque relation est explicitée, et le document prend la forme d’un arbre logique exploitable.
C’est à partir de ce DOM que tout va ensuite s’organiser. Le navigateur peut identifier les ressources associées au document HTML et les demander au serveur : feuilles de style, images, typographies, scripts, médias. Ces ressources sont chargées séparément et appliquées au fur et à mesure de leur disponibilité. Ce mécanisme de chargement progressif explique pourquoi une page apparaît rapidement, puis s’enrichit progressivement. Le contenu est là, lisible, avant même que l’apparence et les interactions ne soient complètement en place.
Ce découplage n’a pas toujours existé. Aux débuts du Web, contenu, mise en forme et interactions étaient souvent mêlés dans les mêmes fichiers, rendant les pages difficiles à maintenir. Progressivement, avec la reconnaissance des standards et l’impulsion de figures comme Jeffrey Zeldman et avec la reconnaissance des standards du web, une séparation plus claire s’est imposée.
Ce principe structure encore le Web moderne : distinguer ce qui est dit, comment c’est affiché et comment cela réagit. Autrement dit, répartir clairement les rôles entre HTML, CSS et JavaScript.
CSS : organiser et mettre en forme
CSS et JavaScript apparaissent naturellement après le HTML. Ils viennent compléter ce dernier en prenant en charge des aspects qu’il ne couvre volontairement pas.
Commençons par les CSS. Une page web étant constituée de texte et d’images, il est nécessaire d’organiser ces contenus pour leur lecture visuelle. Avec le temps, le Web a adopté des conventions d’affichage : avec par exemple, un en‑tête et son logo, une navigation, un contenu central occupant l’essentiel de l’espace, puis enfin, un pied de page en bas d’une page déroulante qui peut parfois être très longue.
Cette organisation visuelle est décrite par les feuilles de style, les Cascading Style Sheets. Pour une prise en main progressive de cette couche de présentation, l’article Prendre en main les CSS propose une approche concrète et accessible. Les CSS définissent la disposition générale des blocs, mais elles vont bien au‑delà. Elles interviennent aussi dans la mise en forme fine : choix typographiques, icônes, couleurs, contrastes, espacements et détails graphiques.
Elles permettent également d’adapter l’affichage selon les périphériques utilisés ou les préférences des utilisateurs, afin que le contenu reste lisible et cohérent dans des contextes très différents. À l’instar du HTML, les CSS constituent un langage vivant, qui évolue en permanence pour accompagner les usages et les technologies de diffusion, voir la page ymct.eu.
Rendre la page interactive
Une interaction fondatrice : le formulaire. Avant que la page ne devienne réactive au sens moderne, le Web propose déjà une interaction essentielle : le formulaire. Remplir un champ, cliquer sur un bouton, envoyer une information. Ce geste simple constitue le premier dialogue entre un utilisateur et un site.
Un formulaire n’est pas seulement un ensemble de champs. Il exprime une intention, s’inscrire, contacter, transmettre un résultat, et déclenche un échange structuré. Cette mécanique, détaillée dans l’article La gestion des formulaires, repose sur un échange clair entre le navigateur et le serveur. Les données sont collectées, associées à une méthode HTTP, GET ou POST, puis transmises au serveur, qui les traite et répond, voir un exemple de page Contactez-nous.
Ce modèle d’échange pourrait suffire si l’usage se limitait à envoyer et recevoir des données. Mais dès que l’on observe les comportements réels, navigation, sélection, filtrage, réactions immédiates, une autre couche devient nécessaire. C’est à ce moment précis qu’intervient le troisième langage côté client : le JavaScript.
Longtemps décrié, souvent confondu avec Java, parfois boudé au profit de langages jugés plus nobles comme C, C++ ou Java, le JavaScript s’est pourtant imposé progressivement comme un pilier du Web. Cette évolution ne s’est pas faite sans transformations. Sa standardisation par ECMAScript, son adoption par les navigateurs, sa reconnaissance à travers le format JSON et son intégration aussi bien côté client que côté serveur ont contribué à en faire un langage central et inter‑plateforme. Mais revenons plus concrètement à ce qu’est le JavaScript.
Prenons un exemple, sur une page listant les compétitions, le JavaScript permet d’afficher ou de masquer dynamiquement les catégories, de filtrer les tournois par âge ou par date, ou encore de réagir immédiatement lorsqu’un utilisateur sélectionne une discipline, sans recharger l’ensemble de la page.
JavaScript : donner du comportement et prolonger l’échange
Le JavaScript est donc le troisième langage interprété nativement par les navigateurs. On l’associe souvent aux interactions visibles, clics, sélections, filtrages, réactions immédiates de l’interface. Mais son rôle ne se limite pas à ces effets perceptibles. Une fois la page chargée, JavaScript peut aussi maintenir un dialogue avec le serveur, de manière autonome et asynchrone, sans bloquer l’affichage ni imposer un rechargement complet. Cette évolution est présentée dans l’article L’Évolution des Requêtes HTTP et des Opérations Asynchrones et sera reprise plus loin dans le chapitre Échanger des données entre client et serveur.
Depuis le début de cet article, nous avons volontairement posé un cadre clair : le chargement des pages repose d’abord sur le HTML transmis par le serveur. Le navigateur sollicite une ressource, le serveur renvoie du HTML, et ce HTML constitue le contenu de référence de la page. Quel que soit le navigateur, le périphérique ou le contexte, le serveur ne renvoie pas « une page différente », mais toujours un HTML identique dans sa nature.
Cela ne signifie pas pour autant que le contenu soit figé. Ce HTML est produit par le serveur au moment de la requête. Il peut donc être ajusté avant l’envoi, en fonction de paramètres précis : l’identifiant d’un tournoi, la phase d’une compétition, le rôle d’un utilisateur ou l’état d’une session. En opérant ce travail en amont de la requête, le navigateur reçoit toujours du HTML, mais un HTML composé spécifiquement en fonction de la demande.
Une fois ce contenu pré-adapté à la demande, reçu et interprété par le navigateur, JavaScript peut intervenir après coup. Il n’a pas vocation à produire le cœur des pages, puisque l’essentiel du contenu a déjà été composé côté serveur. Son rôle est plutôt d’affiner, compléter et ajuster ce qui a été livré, en fonction des interactions de l’utilisateur, de l’état de la page ou du contexte d’usage. Cette articulation clarifie une frontière essentielle : le serveur prépare et assemble le contenu, tandis que le navigateur gère l’expérience et les réactions à partir de ce contenu.
C’est cette articulation qui conduit naturellement au chapitre suivant. Pour comprendre comment le serveur est capable de produire ces pages adaptées, il faut désormais s’intéresser aux langages côté serveur, chargés de générer du contenu dynamique avant même qu’il ne soit transmis au navigateur.
Côté serveur : produire du contenu dynamique
C’est à ce moment qu’apparaît un acteur essentiel : le langage serveur. Nous avons vu que le navigateur est capable d’interpréter plusieurs langages côté client. Il en va de même côté serveur. Celui-ci ne se contente pas de gérer des protocoles comme HTTP ; selon les services installés et l’environnement en place, il peut aussi interpréter différents langages destinés à produire des réponses adaptées.
Historiquement, on trouve des langages comme Perl ou Python, auxquels se sont ajoutés, sans les remplacer mais en les complétant, PHP, ASP.NET, Java ou encore JavaScript côté serveur. Ces langages permettent au serveur de composer ses réponses en fonction de ce qui est demandé, du contexte d’utilisation ou du profil de l’utilisateur. Utilisés seuls, ils atteindraient cependant rapidement leurs limites. C’est pourquoi ils sont presque toujours associés à une ou plusieurs bases de données.
Les données qui constituent le cœur du contenu ne sont pas écrites directement dans les pages. Elles sont stockées et organisées dans une ou plusieurs bases de données, sous une forme structurée. Lorsqu’un client sollicite une information, le langage serveur va alors interroger ces données, sélectionner celles qui correspondent à la demande, puis recomposer la page HTML à partir de ces éléments. C’est ainsi, par exemple, que le serveur peut produire une page dédiée à un tournoi particulier, en y intégrant dynamiquement les équipes concernées, les matchs associés ou les résultats correspondants.
Stocker et organiser l’information
Les bases de données, ou plus précisément les serveurs de données, doivent eux aussi être installés et configurés pour être pleinement opérationnels. Là encore, le choix est vaste : SQL Server, Oracle, PostgreSQL, MySQL, MariaDB, et, selon les besoins, des modèles différents comme les bases relationnelles, NoSQL ou orientées documents.
À ce stade, il n’est ni nécessaire ni utile d’entrer dans les détails. Il suffit de constater qu’aujourd’hui, dans la majorité des cas, les projets web historiques ou classiques reposent sur le couple PHP / MariaDB, tandis que des approches plus récentes s’appuient souvent sur Node.js / MongoDB. Pour mieux situer ces choix, l’article MySQL, MySQL… vous avez dit MariaDB ? revient sur l’évolution et les différences entre ces deux systèmes. Il peut être également utile de le compléter par Utiliser PDO pour gérer plusieurs types de bases de données en PHP, qui montre comment PHP dialogue concrètement avec ces serveurs de données.
Concrètement, l’information n’est pas stockée sous forme de pages prêtes à l’emploi, mais répartie dans plusieurs tables liées entre elles. Une base de données relationnelle distingue par exemple les événements, les équipes, les rencontres ou les catégories, chacun de ces éléments étant stocké séparément. Pour une introduction pas à pas à la création et à la structuration d’une base de données avec phpMyAdmin, vous pouvez consulter l’article Démarrer avec PHPMyAdmin : Création de votre Première Base de Données. L’organisation de ces tables et leurs relations sont détaillées dans Relier nos tables dans PHPMyAdmin : organiser des données cohérentes. Lorsqu’un visiteur consulte le calendrier d’un événement, le serveur ne fait que recomposer le contenu à partir de ces briques d’information, en rassemblant uniquement les données pertinentes pour produire la page demandée.
L’exemple qui suit illustre cette logique à travers une table dédiée aux événements. Les champs présentés (identifiant, type, libellé, période, niveau, code, catégories) montrent comment l’information est décomposée et reliée à d’autres tables via des clés étrangères. La structure est volontairement tronquée afin de se concentrer sur le principe de stockage relationnel, indépendamment des détails d’implémentation.
En résumé, la panoplie du développeur web s’enrichit ici principalement de PHP et de SQL, qui permettent de dépasser les limites du HTML strictement statique.
Échanger des données entre client et serveur
Le PHP est au serveur ce que le JavaScript est au client : un langage adapté au traitement des demandes reçues et à la génération des contenus en retour. Quelle que soit la logique mise en œuvre côté serveur, la réponse envoyée au navigateur reste le plus souvent formattée en HTML ou en JSON. Voici un exemple simple du même contenu, structuré cette fois pour l’affichage, tel qu’il pourrait être renvoyé par le serveur, après avoir été assemblé par PHP, sous forme de HTML :
<h1>YMCT</h1>
<h2>Youngsters Memorable Championships & Tournaments</h2>
<p>
YMCT vous aide à organiser vos tournois et vos compétitions de water-polo.
</p>
<p>
Une plateforme dédiée aux minipolos et polonats, pensée pour simplifier la gestion
des compétitions grâce à une interface intuitive.
</p>
<p>
Gérez vos compétitions en toute simplicité et optimisez votre organisation au quotidien.
</p>Le HTML, nous l’avons vu, sert à structurer le contenu pour l’affichage. Le JSON, lui, ne sert pas à afficher, mais à organiser et transporter des informations qualifiées. Voici le même contenu, structuré cette fois sous forme de données, tel qu’il pourrait être échangé entre le serveur et le navigateur au format JSON :
{
"titre": "YMCT",
"slogan": "Youngsters Memorable Championships & Tournaments",
"accroche": "YMCT vous aide à organiser vos tournois et vos compétitions de water-polo.",
"description": "Une plateforme dédiée aux minipolos et polonats, pensée pour simplifier la gestion des compétitions grâce à une interface intuitive.",
"promesse": "Gérez vos compétitions en toute simplicité et optimisez votre organisation au quotidien."
}Il s’agit d’un format de données simple et lisible, utilisé pour décrire des informations de manière structurée afin qu’elles puissent être échangées et comprises aussi bien par le client que par le serveur, indépendamment du langage employé.
Une fois la page chargée, cet échange ne s’arrête pas pour autant. Le Web moderne repose sur un dialogue continu entre le navigateur et le serveur. La page est affichée une première fois, puis elle envoie et reçoit des données au fil des actions de l’utilisateur : autocomplétion d’un champ de recherche, mise à jour d’un score, chargement progressif d’une liste, validation d’un formulaire, rafraîchissement partiel d’une zone. Ces échanges se font sans rechargement complet, de manière asynchrone, et permettent à l’interface d’évoluer en temps réel, souvent sans que l’utilisateur en ait pleinement conscience.
Cette logique, souvent associée au terme AJAX, n’est pas une technologie isolée mais une façon de concevoir l’échange. Lorsqu’un utilisateur saisit quelques lettres dans un champ, ouvre un filtre, ou déclenche une action ponctuelle, le navigateur envoie une requête ciblée, le serveur répond avec des données, et seule la partie concernée de la page est mise à jour. Pour aller plus loin sur ce mécanisme, l’article Comprendre XMLHttpRequest détaille les bases de ces échanges côté navigateur.
SQL : interroger les données
Et le SQL dans tout cela ? Le SQL n’est pas un langage de génération de pages ni un langage applicatif au sens classique. Il joue un rôle bien distinct : celui de faire le lien entre le serveur et les données.
Conçu spécifiquement pour interroger, organiser et modifier le contenu des bases de données, le SQL permet au serveur de sélectionner précisément les informations dont il a besoin, au moment où il en a besoin. Pour approfondir ces deux dimensions complémentaires, vous pouvez consulter MySQL : index, recherches et performance, qui éclaire les enjeux de recherche et d’optimisation, ainsi que MySQL : vues, usages et bonnes pratiques, qui montre comment structurer et exposer les données de manière plus lisible et réutilisable. Il ne décide ni de l’affichage, ni du comportement de la page, mais fournit la matière première à partir de laquelle le serveur pourra construire sa réponse.
Prenons un cas simple. Une application sportive doit afficher les compétitions à venir pour une catégorie donnée. Ces informations ne sont pas stockées dans des pages, mais réparties dans une base de données relationnelle. Une table contient les compétitions, une autre les équipes, une troisième les joueurs. Le rôle du SQL consiste précisément à aller chercher ces informations dans les différentes tables, à les mettre en relation, puis à les rassembler : quelles compétitions correspondent à cette catégorie, à quelles dates, avec quelles équipes impliquées ? Le résultat n’est pas une page, mais un ensemble de données brutes, issues de plusieurs tables, regroupées sous forme de tableau récapitulatif, sans mise en forme ni exploitation, que le serveur pourra ensuite transformer selon le contexte.
C’est cette combinaison qui permet de dépasser les limites du HTML statique. Le serveur s’appuie sur le SQL pour récupérer ou mettre à jour des données, puis utilise un langage serveur pour produire une réponse adaptée, comme nous avons vu, le plus souvent en HTML ou en JSON, en fonction du contexte et de l’usage.
Structurer les échanges avec des API RESTful
À mesure qu’une application évolue, les interactions se multiplient. Au départ, une page charge quelques données. Puis viennent les filtres, les tris, les mises à jour partielles, les tableaux qui se rafraîchissent, les formulaires qui dialoguent en arrière-plan. Le JavaScript côté client sollicite alors le serveur de plus en plus fréquemment, parfois pour des besoins très proches les uns des autres.
Côté serveur, le langage applicatif, comme PHP, se retrouve à jouer un rôle central. À chaque demande, il doit comprendre ce qui est attendu, interpréter les paramètres reçus, interroger la base de données via SQL, rassembler les informations pertinentes, puis produire une réponse exploitable. Tant que ces échanges restent rares, ce fonctionnement peut sembler naturel. Mais lorsque les sollicitations s’accumulent, la logique devient rapidement difficile à suivre.
Sans cadre clair, chaque nouvelle fonctionnalité ajoute sa propre façon de dialoguer avec le serveur. Les traitements se dupliquent, les règles se dispersent, et la maintenance devient délicate. On ne sait plus vraiment qui demande quoi, à quelle adresse, ni sous quelle forme la réponse est attendue. Il devient alors nécessaire de poser une structure commune, lisible et documentée, qui dépasse le simple cas par cas.
C’est précisément à ce moment qu’interviennent les API et l’architecture REST. Elles ne sont pas une technologie supplémentaire, mais une manière d’organiser les échanges existants. Chaque ressource dispose d’un point d’accès clair, chaque action correspond à une méthode HTTP explicite, et chaque réponse suit un format prévisible. Pour approfondir cette logique, voir Comprendre le concept de REST pour le développement d’applications web efficaces ainsi que Les Méthodes HTTP dans REST : Une approche pratique.
Dans une application concrète, cette organisation change profondément la manière de travailler. Une page publique, un tableau de bord d’administration ou une application mobile peuvent avoir besoin des mêmes données, sans pour autant les exploiter de la même façon. Plutôt que de multiplier les traitements spécifiques, le serveur expose un point d’accès unique, clairement défini, par exemple sous la forme d’une URL explicite comme ymct.eu/competition/match/14/12. Quel que soit le client qui formule la demande, la règle reste la même, et la réponse suit un contrat connu à l’avance.
Ce découpage prépare naturellement la suite. Une fois les échanges structurés, il devient possible de raisonner non plus en pages isolées, mais en actions sur les données. C’est cette logique, entre lecture, création, mise à jour et suppression, qui nous conduit directement vers la notion de CRUD, au croisement des API REST et des applications métier.
CRUD comme grammaire des actions.
Dès que l’on commence à manipuler des données, une logique simple s’impose, souvent sans que l’on mette de mot dessus : le CRUD (Créer, lire, mettre à jour, supprimer). Ce ne sont pas des termes techniques, mais des gestes concrets. Ajouter un résultat, consulter une fiche, corriger une information, retirer un élément devenu inutile. C’est exactement ce que l’on fait, au quotidien, dès qu’un site devient un peu plus qu’une page statique.
Le CRUD agit alors comme une grille de lecture commune. Derrière un bouton, un formulaire ou un clic, on retrouve toujours la même question implicite : qu’est‑ce que l’on fait avec les données ? Cette logique relie naturellement les requêtes HTTP d’une API REST, les formulaires côté client, les opérations SQL en base de données et la logique métier qui décide si l’action est possible, autorisée ou cohérente.
Dans une API RESTful, cette grammaire devient visible. Une requête n’est plus seulement là pour afficher une page, mais pour exprimer une intention claire : créer une ressource, consulter un état, modifier une information, supprimer un élément. Les articles Mise en place d’une API RESTful CRUD côté client et Mise en place d’une API RESTful CRUD côté serveur montrent comment cette logique se met en place concrètement, des deux côtés de l’échange.
Mais le CRUD ne s’arrête pas à l’écran. Une action peut déclencher d’autres traitements côté serveur. Par exemple, créer ou mettre à jour une donnée peut entraîner l’envoi d’un e‑mail, une notification ou une alerte, sans que l’utilisateur n’en fasse explicitement la demande. L’article Maîtriser l’envoi de mails avec PHPMailer illustre bien ce rôle du serveur comme maître d’œuvre, capable de transformer une requête HTTP en un échange SMTP.
À ce stade, le Web ne se résume plus à afficher des pages. On entre dans une logique applicative, où chaque action modifie un état, déclenche des traitements et s’inscrit dans un ensemble cohérent. C’est ce glissement progressif, du site vers l’application, qui explique pourquoi le CRUD devient une brique structurante de tout projet web dès qu’il commence à gagner en complexité.
Du site web à l’application
En prenant un peu de recul et en revenant au point de départ de cet article, nous avons parcouru un long chemin de mise à plat et de compréhension. Nous ne sommes déjà plus tout à fait dans le seul domaine du site web : une frontière a été franchie, et nous avons mis un pied dans le monde applicatif.
Pour affirmer cette transition, cette distinction entre site web et application, il reste encore un concept clé à aborder : celui des PWA. Développer une application implique souvent de multiplier les chantiers, une version pour Android, une autre pour iOS, sans oublier le site web, qui demeure incontournable. Les PWA offrent une autre voie, en allant dans le sens d’un « create once, publish everywhere », où une même application Web peut être utilisée comme site ou comme application, quel que soit l’environnement. Un même service de gestion, de réservation ou de suivi peut ainsi être décliné sur ordinateur, mobile ou tablette, sans multiplier les développements spécifiques. Voir à ce sujet Une PWA, c’est quoi au juste ?.
Lorsque nous avons évoqué les prises de position de Jeffrey Zeldman autour de la reconnaissance et de l’adoption des standards du Web, nous avons volontairement laissé de côté le contexte plus stratégique qui se jouait alors, au-delà de cette démarcation et de ce virage… Le Web Applicatif.
Quand le Web devient applicatif
Jusqu’alors, le Web était principalement encadré par le W3C et restait largement centré sur la représentation de contenus, statiques ou partiellement dynamiques. En formalisant l’expression Web 2.0, Tim O’Reilly souhaitait surtout mettre en lumière un travail de fond déjà engagé, notamment par les acteurs défendant les standards, en faveur d’un Web plus interactif et véritablement applicatif, une dynamique déjà analysée et documentée à l’époque, par exemple dans l’essai Qu’est ce que le Web 2.0 ?.
Dans ce contexte, le WHATWG s’est constitué comme un contrepoids au W3C en prenant en main l’évolution du HTML. Avec HTML5, le Web a clairement changé de cap. Les éditeurs de navigateurs ont été amenés à intégrer nativement des fonctionnalités jusqu’alors absentes ou dépendantes de solutions propriétaires.
Cela a commencé par la prise en charge directe de la vidéo et de l’audio, autrefois tributaires de plugins, puis s’est étendu à des besoins plus larges : gestion de la mémoire, chargements asynchrones, stockage local, exécution en arrière-plan, communication temps réel, accès à la caméra et au micro, et plus largement à l’environnement du périphérique utilisé. L’ensemble de ces capacités est aujourd’hui regroupé sous la forme d’API Web standardisées, directement accessibles depuis le navigateur, dont une vue d’ensemble est disponible sur la documentation Web API – MDN.
Le navigateur comme plateforme applicative
Le Web pouvait alors devenir pleinement applicatif. Les PWA en sont aujourd’hui l’illustration la plus aboutie, en permettant de transformer le navigateur en véritable moteur de distribution. Dans le cas d’une PWA, il disparaît le plus souvent, voire systématiquement, visuellement pour l’utilisateur.
Cette approche concrétise l’adage « Create once, publish everywhere » : les applications ainsi conçues peuvent être utilisées aussi bien sur ordinateur que sur Android ou iOS, tout en reposant sur des standards ouverts. Le Web est ainsi devenu applicatif, tout en conservant ce qui fait sa force : l’universalité et l’interopérabilité.
Avec tous ces langages, avec la compréhension des échanges entre client et serveur orchestrés par un HTTP régulateur, avec une vision globale et transversale des technologies, ouvertes, à disposition et un apprentissage vertical de chaque brique, de chaque élément qui le compose, l’apprenti web développeur a en main tous les outils qui vont lui permettre d’œuvrer et composer aussi bien des sites web que des applications adaptées sur mesure aux besoins des utilisateurs internautes.
Conclusion
Sans prétendre à l’exhaustivité, ce parcours permet de mieux cerner ce qu’est réellement le métier de développeur web : une activité à la fois technique, intellectuelle et en constante évolution. En quelques décennies, des outils réservés à des initiés sont devenus des usages quotidiens, si intuitifs qu’ils en paraissent presque naturels.
Si nous avons traversé ces couches, ces langages et ces mécanismes, ce n’était pas pour en faire un catalogue, mais pour raconter une histoire. Celle d’un métier qui consiste à comprendre, assembler et maîtriser ce qui se cache derrière l’usage du Web, en partant volontairement de ce que nous connaissons tous : son utilisation la plus simple.
Derrière cette apparente évidence se cache pourtant une mécanique riche, faite de choix et de responsabilités. Comprendre les fondations du Web permet de dépasser la surface, de reprendre la main sur les outils et de redonner du sens à ce que l’on construit, là où les solutions « clé en main » montrent vite leurs limites.
Cette démarche passe par le fait de dessiner avant de coder, pour structurer sa pensée et ses intentions, comme évoqué dans Dessiner avant de coder : méthode analogique pour penser une application, puis par le fait de tracer des solutions en reliant le code aux usages réels, comme développé dans Tracer des solutions : du code à l’usage, et enfin par un ancrage dans le terrain, au plus près des besoins concrets, tel que présenté dans Concevoir nos applications depuis le terrain : écouter les besoins, construire par le code.
Ainsi, cette exploration ne se ferme pas sur une conclusion définitive, mais sur une continuité : observer l’usage du Web, en comprendre les mécanismes, puis apprendre à les assembler consciemment. C’est dans ce mouvement que se dessine, très concrètement, le métier de développeur web.