Frontend : l'interface entre l'utilisateur et le chaos organisé du backend

Ou : Pourquoi faire qu’un bouton soit joli, cliquable et accessible sur 47 tailles d’écran est plus difficile qu’il n’y paraît

Vous êtes au restaurant. Vous voyez une salle : des tables, un menu, un serveur qui prend votre commande, une assiette qui arrive. Vous ne voyez pas la cuisine : les frigos, les commis, le chef qui crie, la plonge. Pourtant, votre soirée dépend des deux. Une cuisine parfaite servie dans une salle glaciale, avec un menu illisible et un serveur qui vous ignore, donne un mauvais restaurant.

Un site web fonctionne exactement de la même façon. Il y a la salle, ce que vous voyez et touchez dans votre navigateur : c’est le frontend. Et il y a la cuisine, les serveurs et les bases de données qui travaillent en coulisse : c’est le backend. Le backend peut être rapide, sécurisé et élégamment conçu. Si l’interface est un mur de texte avec un formulaire cassé, l’utilisateur s’en fiche. Il voit le frontend, il juge le frontend, il part à cause du frontend.

Cette page part de zéro. Pas besoin de savoir programmer pour la suivre, seulement d’avoir déjà ouvert un site web, ce qui, vu que vous êtes en train de lire ceci, semble acquis.

Qu’est-ce que le frontend : la partie visible d’un site web, expliquée pas à pas

D’accord, mais concrètement ?

Le frontend (on dit aussi « front », « front-end » ou, en bon français, « interface utilisateur ») désigne tout ce qui s’affiche et se passe dans votre navigateur. Le navigateur, c’est le logiciel qui vous sert à aller sur Internet : Chrome, Firefox, Safari, Edge.

Tout ce que vous pouvez voir ou manipuler sur une page appartient au frontend :

• le texte, les titres, les images ;
• les couleurs, les polices, la disposition des blocs ;
• les boutons, les menus qui s’ouvrent, les formulaires ;
• les animations, les messages d’erreur, la petite roue qui tourne pendant un chargement.

Ce qui n’en fait pas partie : vérifier votre mot de passe, enregistrer votre commande, calculer vos frais de port, envoyer l’e-mail de confirmation. Tout ça se passe dans la cuisine, sur un ordinateur distant qu’on appelle un serveur, et c’est le travail du backend.

La distinction la plus simple à retenir tient en une question : où tourne le code ? Sur votre appareil, dans le navigateur ? C’est du frontend. Sur un serveur, loin de vous ? C’est du backend.

Ce qui se passe quand vous ouvrez une page

Reprenons la scène au restaurant, au moment où vous vous asseyez. Quand vous tapez une adresse dans votre navigateur et appuyez sur Entrée, voici ce qui se passe, simplifié :

1. Votre navigateur demande la page au serveur. Cette demande voyage selon les règles du protocole HTTP, le « langage » que parlent navigateurs et serveurs.
2. Le serveur renvoie un fichier HTML : la liste de ce qui doit apparaître sur la page.
3. Le navigateur lit ce fichier et découvre qu’il a besoin d’autres choses : une feuille de style CSS, des scripts JavaScript, des images. Il les demande à leur tour.
4. Il construit une représentation de la page en mémoire, une sorte d’arbre généalogique de tous les éléments, qu’on appelle le DOM¹.
5. Il applique les styles, calcule où placer chaque bloc, puis « peint » le résultat à l’écran.
6. Les scripts JavaScript se lancent et rendent la page interactive : ils attendent vos clics, vos saisies, vos défilements.

Tout ça prend en général moins d’une seconde. Le frontend, c’est l’ensemble des fichiers envoyés aux étapes 2 et 3, et la façon dont le navigateur les transforme en quelque chose d’utilisable aux étapes 4 à 6.

C’est d’ailleurs une particularité qui surprend les débutants : le code frontend est envoyé chez vous. Il s’exécute sur votre ordinateur ou votre téléphone. Vous pouvez donc le lire, ce qu’on va faire dans un instant. Et c’est pour ça qu’on ne met jamais de secret dans le frontend : ce qui est dans la salle, tout le monde peut le regarder.

Les trois langages du frontend, avec un bouton pour exemple

Tout le web repose sur trois technologies complémentaires. Le plus simple pour les comprendre est de fabriquer ensemble un seul objet : un bouton « Ajouter au panier ».

Le HTML, pour la structure. Il dit ce qu’il y a sur la page : un titre, un paragraphe, une image, un bouton. C’est le squelette, ou si vous préférez, le plan de la salle : ici une table, là une chaise.

1
2
3

<!-- Le HTML dit : il y a un bouton, et voici son texte -->
<button id="ajouter">Ajouter au panier</button>
<p id="message"></p>

Sans rien d’autre, ce bouton existe et s’affiche. Il est gris, un peu triste, et il ne fait rien quand on clique dessus. Mais il est là.

Le CSS, pour l’apparence. Il dit à quoi ça ressemble : couleurs, tailles, marges, polices, disposition. C’est la décoration de la salle, les nappes et l’éclairage.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

/* Le CSS dit : ce bouton est vert, arrondi, avec un texte blanc */
#ajouter {
  background-color: #2e7d32;
  color: white;
  padding: 12px 24px;
  border: none;
  border-radius: 8px;
  font-size: 1rem;
  cursor: pointer; /* la souris devient une petite main */
}

Le bouton est maintenant vert et donne envie de cliquer. Il ne fait toujours rien.

Le JavaScript, pour le comportement. Il dit ce qui se passe quand on interagit : un clic, une saisie, un défilement. C’est le serveur de la salle, celui qui réagit quand vous levez la main.

1
2
3
4
5
6
7

// Le JavaScript dit : quand on clique sur le bouton, affiche un message
const bouton = document.getElementById("ajouter");
const message = document.getElementById("message");

bouton.addEventListener("click", () => {
  message.textContent = "Article ajouté au panier !";
});

Cette fois, le clic affiche un message. Trois langages, trois rôles, et aucun ne peut remplacer les autres. Le HTML sans CSS est moche, le CSS sans HTML n’a rien à décorer, et le JavaScript sans HTML n’a rien sur quoi agir.

Dans un vrai site, ce clic enverrait aussi une demande au backend pour enregistrer l’article dans votre panier, souvent via une API REST. C’est le moment où le serveur de la salle part en cuisine avec votre commande.

JavaScript a une place à part dans ce trio : c’est le seul langage de programmation classique que tous les navigateurs savent exécuter directement². Si vous voulez qu’une page réagisse à quelque chose, vous passerez par lui, d’une façon ou d’une autre.

Essayez vous-même : ouvrez les coulisses de cette page

Le frontend a une propriété rare dans l’informatique : vous pouvez regarder le code de n’importe quel site, tout de suite, sans rien installer. Tous les navigateurs modernes intègrent des outils de développement.

Pour les ouvrir :

• Windows ou Linux : touche F12, ou Ctrl + Maj + I ;
• Mac : Cmd + Option + I ;
• Partout : clic droit sur un élément de la page, puis « Inspecter ».

Faites l’essai sur cette page. Un panneau s’ouvre, avec un onglet « Éléments » qui montre le HTML. Survolez les lignes : la partie correspondante de la page s’illumine. À droite, vous voyez le CSS appliqué à l’élément sélectionné. Vous pouvez même modifier une couleur ou un texte, et le changement apparaît instantanément à l’écran.

Rassurez-vous : vous ne cassez rien. Vos modifications n’existent que dans votre navigateur, et elles disparaissent dès que vous rechargez la page. Le site réel, celui que voient les autres visiteurs, n’est pas touché. C’est exactement comme réarranger les couverts sur votre table au restaurant : la salle des autres clients ne change pas.

C’est probablement le meilleur outil d’apprentissage du frontend qui existe, et il est déjà installé sur votre ordinateur.

Les frameworks : pourquoi React, Vue ou Angular existent

Pour une page simple, HTML, CSS et un peu de JavaScript suffisent. On parle alors de JavaScript « vanilla », c’est-à-dire nature, sans ajout. Mais imaginez une application comme une messagerie ou un tableau de bord : des centaines de boutons, des listes qui se mettent à jour toutes les secondes, des dizaines d’écrans. Écrire tout ça à la main devient vite ingérable.

C’est là qu’interviennent les frameworks frontend. Un framework est une boîte à outils avec un mode d’emploi imposé : il fournit une façon standard de découper l’interface en composants, des blocs réutilisables comme un bouton, une carte produit ou un menu. Vous écrivez le composant une fois, vous l’utilisez partout.

Au restaurant, c’est la différence entre dresser chaque table à la main selon l’humeur du jour et avoir une méthode de mise en place que toute l’équipe connaît : chaque table est dressée pareil, vite, et un nouveau serveur s’y retrouve dès le premier soir.

Le choix entre eux déclenche des débats presque religieux entre développeurs. La vérité pragmatique : ils résolvent tous le même problème, avec des styles différents. Pour un projet d’équipe, prenez celui que l’équipe connaît³.

Et un conseil si vous débutez : n’apprenez pas un framework en premier. Un framework, c’est du JavaScript organisé d’une certaine façon. Sans les bases, vous apprendrez des recettes sans comprendre la cuisine, et la première erreur un peu originale vous laissera sans ressource.

Un site, mille écrans : le responsive design

La même page doit s’afficher correctement sur un téléphone d’environ 375 pixels de large, une tablette, un ordinateur portable et un grand écran de 2 560 pixels. Adapter l’interface à la taille de l’écran s’appelle le responsive design, ou design adaptatif. Ce n’est plus une option : sur beaucoup de sites, la majorité des visites viennent d’un téléphone.

L’outil principal est la « media query » CSS, une règle qui ne s’applique qu’à partir ou en dessous d’une certaine largeur d’écran.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

/* Par défaut (téléphone) : les cartes produit s'empilent sur une colonne */
.produits {
  display: grid;
  grid-template-columns: 1fr;
  gap: 16px;
}

/* À partir de 768 pixels de large (tablette et plus) : trois colonnes */
@media (min-width: 768px) {
  .produits {
    grid-template-columns: repeat(3, 1fr);
  }
}

C’est comme une salle de restaurant modulable : en semaine, des petites tables pour deux ; le samedi, on les rapproche pour les grandes tablées. Même salle, même mobilier, disposition adaptée au besoin.

Un bon réflexe : dans les outils de développement, cliquez sur l’icône représentant un téléphone et une tablette. Le navigateur simule alors différents écrans, et vous voyez la page se réorganiser.

L’accessibilité : une salle où tout le monde peut entrer

Un restaurant avec trois marches à l’entrée et aucune rampe n’est pas fermé aux personnes en fauteuil roulant. Il leur est seulement inutilisable. Le web a le même problème, sous le nom d’accessibilité : faire en sorte qu’un site fonctionne pour tout le monde, y compris les personnes malvoyantes, daltoniennes, ou qui naviguent sans souris.

Quelques gestes de base, tous du ressort du frontend :

• donner un texte alternatif aux images (l’attribut alt), que les lecteurs d’écran lisent à voix haute ;
• garder un contraste suffisant entre le texte et le fond ;
• utiliser de vrais boutons et de vrais liens, pour qu’on puisse naviguer avec la touche Tabulation ;
• ne jamais transmettre une information uniquement par la couleur (« les champs en rouge sont obligatoires »).

Ce n’est pas un bonus pour les gros sites. Dans l’Union européenne, l’Acte européen sur l’accessibilité impose depuis juin 2025 des exigences d’accessibilité à de nombreux services en ligne, dont le commerce électronique⁴.

Le dialogue de la fonctionnalité frontend

DevOps Dave : Le client veut un mode sombre.

Security Sarah : C’est du CSS, non ? Une demi-journée ?

DevOps Dave : C’est du CSS, plus la préférence du système de l’utilisateur, plus la mémorisation de son choix, plus la compatibilité avec notre charte graphique, plus les images qui doivent changer de teinte, plus les e-mails qui n’ont pas de mode sombre, plus les factures PDF qui sont toujours blanches. Deux semaines.

Security Sarah : Pour changer des couleurs ?

DevOps Dave : Bienvenue dans le frontend.

Ce dialogue résume une vérité du métier : en frontend, les demandes paraissent simples parce qu’on les voit. Tout le monde peut imaginer un bouton sombre. Presque personne n’imagine les quarante endroits où ce bouton doit aussi exister.

Frontend, backend, full-stack : qui fait quoi

Dans une équipe, ces mots désignent aussi des métiers.

Le développeur frontend construit la salle : il transforme une maquette graphique en pages qui fonctionnent, sur tous les écrans, pour tous les utilisateurs. Il travaille avec des designers d’un côté et des développeurs backend de l’autre.

Le développeur backend tient la cuisine : bases de données, logique métier, sécurité, performances du serveur.

Le développeur full-stack fait les deux. Comme le patron d’un petit bistrot qui cuisine et sert en salle, il est précieux par sa polyvalence, avec le risque de ne maîtriser ni l’un ni l’autre aussi finement qu’un spécialiste.

Si vous vous demandez par où commencer, l’ordre classique pour apprendre le frontend est le suivant :

1. HTML : quelques jours suffisent pour les bases.
2. CSS : plus long qu’il n’y paraît, surtout la mise en page.
3. JavaScript : le vrai morceau, celui qui demande de la pratique.
4. Un framework, une fois les trois premiers à l’aise.

Pour la documentation de référence, en français pour une bonne partie, la ressource de base est MDN Web Docs, la documentation de Mozilla. Elle est gratuite, à jour, et utilisée aussi bien par les débutants que par les développeurs expérimentés.

Le petit lexique du frontend

Le mot de la fin

Le frontend est le domaine où la perfection technique est invisible. L’utilisateur ne sait pas que le menu est un composant React chargé à la demande, avec une animation CSS calculée à soixante images par seconde. Il sait que le menu est fluide. Ou qu’il rame.

C’est aussi le domaine le plus exposé aux avis, parce que tout le monde a une opinion sur les couleurs, les polices et la taille des boutons. Personne n’est allé en cuisine donner son avis sur l’organisation des frigos. Tout le monde a déjà trouvé que la nappe était moche. Ce qui rend le métier à la fois créatif et, certains jours, épuisant.