Développement web et programmation : le vocabulaire du métier

Ou : trente-cinq ans passés à empiler des couches sur un protocole conçu pour s’échanger des articles de physique.

Le développement web désigne la fabrication de programmes qui s’exécutent à travers un navigateur ou qui répondent à des requêtes venues d’un navigateur. C’est une définition courte, et elle est déjà trompeuse, parce qu’elle laisse croire que le navigateur est au centre. Il ne l’est pas. Ce qui est au centre, c’est le protocole HTTP, écrit en 1991 par un physicien du CERN pour que des chercheurs puissent s’envoyer des documents. Tout le reste s’est construit par-dessus, couche après couche, sans jamais avoir le droit de casser ce qui existait déjà.

C’est ce qui rend le domaine étrange à expliquer. Ce n’est pas une discipline qui a été conçue, c’est une discipline qui s’est sédimentée.

Ce que recouvre le développement web, du protocole jusqu’au déploiement

Le domaine tient entier dans une requête

Si on veut comprendre ce que ce métier recouvre vraiment, le plus simple est de suivre ce qui se passe quand quelqu’un tape une adresse et appuie sur entrée.

La machine doit d’abord traduire un nom lisible en une adresse numérique, et c’est le rôle du DNS, un annuaire distribué dont personne ne parle tant qu’il fonctionne. En octobre 2016, une attaque contre le fournisseur DNS Dyn a rendu Twitter, Netflix et Reddit inaccessibles pendant des heures, alors que les serveurs de ces trois services tournaient parfaitement. Les sites étaient debout, plus personne ne savait où les trouver.

Une fois l’adresse connue, le navigateur ouvre une connexion et envoie une requête HTTP. Le serveur répond. Cette réponse contient du texte que le navigateur va interpréter comme une structure de document, c’est-à-dire du HTML, puis habiller avec des règles de présentation, donc du CSS, puis animer avec un langage de programmation, JavaScript. Trois technologies, trois rôles, et un ordre d’exécution qui explique la moitié des bugs de la profession.

Le développement web, c’est tout ce qui se passe entre ces étapes. Le choix de ce que le serveur calcule et de ce qu’il délègue au navigateur. La façon dont deux programmes écrits par des équipes différentes se mettent d’accord sur un format d’échange. Ce qu’on met en cache et pendant combien de temps. Ce qu’on refuse de servir et pourquoi.

La frontière qui structure tout : ce qui tourne où

La distinction la plus importante du domaine n’est pas une question de langage, c’est une question d’emplacement. Le code qui s’exécute sur la machine du visiteur, le frontend, et le code qui s’exécute sur une machine que vous contrôlez, le backend, n’obéissent pas aux mêmes règles.

Le premier est public. Tout ce que vous y mettez est lisible, modifiable et contournable par n’importe qui sachant ouvrir les outils de développement de son navigateur. Une vérification faite uniquement côté navigateur n’est pas une vérification, c’est une suggestion polie. Le second est privé, mais il est aussi partagé entre tous les visiteurs simultanés, ce qui en fait le point où se concentrent les questions de performance, de concurrence et de coût.

Cette frontière a une conséquence directe sur la sécurité, et c’est là qu’intervient le mécanisme CORS. Par défaut, un navigateur interdit à une page servie par un domaine de lire la réponse d’un autre domaine. Ce n’est pas une restriction du serveur, c’est une restriction du navigateur, appliquée pour protéger l’utilisateur contre une page malveillante qui irait interroger sa banque en son nom. La plupart des développeurs découvrent CORS sous la forme d’un message d’erreur rouge, le contournent en copiant un réglage trouvé en ligne, et ne se demandent jamais contre quoi cette barrière les protégeait.

La communication entre les deux côtés passe le plus souvent par une API REST, un style d’architecture formalisé par Roy Fielding en 2000 dans sa thèse de doctorat à l’université de Californie à Irvine. REST n’est pas une technologie, c’est un ensemble de contraintes. Cette nuance explique pourquoi presque toutes les API qui se disent RESTful ne le sont pas vraiment, et pourquoi ça n’a le plus souvent aucune importance.

Quand le modèle requête-réponse ne suffit plus, parce que le serveur doit pouvoir parler en premier, on change de protocole. Les WebSockets, normalisées en 2011, ouvrent un canal qui reste ouvert dans les deux sens. Avant elles, le temps réel se simulait en interrogeant le serveur en boucle, ce qui fonctionnait à peu près et coûtait cher.

Les trois langages que personne n’avait prévus

Une particularité du domaine mérite qu’on s’y arrête, parce qu’elle explique beaucoup de sa complexité apparente : aucun des trois langages du navigateur n’a été conçu pour ce qu’il fait aujourd’hui.

Le HTML devait décrire des documents scientifiques reliés entre eux. Il décrit désormais des applications complètes avec des formulaires, des composants et des états. Le CSS devait mettre en forme du texte. Il gère aujourd’hui des mises en page bidimensionnelles et des animations, capacités arrivées tardivement avec Flexbox en 2012 puis Grid en 2017, ce qui signifie que pendant vingt ans centrer un élément verticalement était un problème réputé difficile. Et JavaScript a été écrit en dix jours par Brendan Eich chez Netscape en 1995, avec pour cahier des charges de ressembler à Java sans en être.

Ce dernier point a une conséquence durable. JavaScript porte des décisions de conception prises en une semaine et devenues impossibles à corriger, puisque des milliards de pages en dépendent. TypeScript, apparu en 2012, est la réponse la plus répandue à ce problème : un surensemble qui ajoute un système de types au-dessus, sans rien retirer. Tout code JavaScript valide est du TypeScript valide, ce qui permet une adoption progressive plutôt qu’une réécriture.

Ce que le métier recouvre en plus du code

Écrire le programme n’est qu’une partie du travail, et pas forcément la plus longue.

Le code doit avoir une histoire, ce qui est le rôle de Git, créé en 2005 par Linus Torvalds après que le projet Linux a perdu l’accès à l’outil propriétaire qu’il utilisait. Git n’est pas seulement un moyen de sauvegarder des versions, c’est ce qui rend possible le travail simultané de plusieurs personnes sur le même fichier sans coordination permanente.

Le code doit ensuite arriver en production, et c’est ce que recouvre la chaîne CI/CD : vérifier automatiquement que chaque modification compile et passe les tests, puis la déployer sans intervention manuelle. Une équipe sans cette chaîne ne déploie pas moins souvent, elle déploie avec plus d’appréhension.

Enfin, presque personne ne part d’une page blanche. Un framework fournit la structure, les conventions et les problèmes déjà résolus. React, publié par Facebook en 2013 comme une simple bibliothèque de rendu, est devenu l’exemple type de cette dynamique : un outil adopté si largement que le choisir n’est plus une décision technique mais une décision de recrutement.

Full stack, un mot qui veut dire ce que l’employeur a décidé

Reste un terme qui mérite un avertissement. Full stack désigne en principe quelqu’un capable de travailler des deux côtés de la frontière. En pratique, sa définition varie tellement d’une offre d’emploi à l’autre qu’elle ne dit plus rien d’utile sur les compétences attendues.

Chez certains, c’est un développeur backend qui sait modifier un formulaire. Chez d’autres, c’est une équipe entière compressée dans une seule personne, avec l’infrastructure et la base de données en supplément. Le terme est utile pour décrire une trajectoire personnelle, beaucoup moins pour décrire un poste.

Ce qui a changé, et ce qui n’a pas bougé

Il est tentant de présenter ce domaine comme un endroit où tout se renouvelle sans arrêt. C’est vrai en surface et faux en profondeur.

Les outils se remplacent vite. Les frameworks dominants d’il y a dix ans ne sont plus ceux d’aujourd’hui, et ceux d’aujourd’hui ne seront probablement plus ceux de la décennie suivante. Mais la couche du dessous ne bouge presque pas. Une requête HTTP de 2026 ressemble beaucoup à une requête HTTP de 1996, avec du chiffrement en plus, généralisé depuis que Let’s Encrypt a rendu les certificats gratuits et automatiques en 2015 et 2016. Le HTML reste un arbre de balises. Le DNS reste un annuaire.

C’est pour ça que le vocabulaire rassemblé ici garde sa valeur plus longtemps que les outils qu’il sert à comprendre. Apprendre un framework rapporte pendant quelques années. Comprendre pourquoi une requête échoue, où passe la frontière entre les deux côtés et ce qu’un navigateur accepte de faire rapporte pendant toute une carrière.

Récapitulatif

Le développement web est la fabrication de logiciels qui communiquent par HTTP. Sa structure est déterminée par une seule frontière, celle qui sépare ce qui s’exécute chez le visiteur de ce qui s’exécute chez vous, et la plupart de ses règles découlent de cette séparation.

Le domaine se lit en trois strates. Les protocoles au fond, HTTP et DNS, stables depuis trente ans. Les langages du navigateur au milieu, HTML, CSS et JavaScript, détournés de leur usage d’origine et accompagnés de TypeScript. Les pratiques par-dessus, avec Git pour l’historique, la chaîne CI/CD pour le déploiement et les frameworks pour ne pas tout réécrire.

Les quinze définitions de cette section détaillent chacun de ces éléments, dans l’ordre que vous voudrez.