Bonnes pratiques HTML/CSS dans un projet JS fullstack

Dans un projet JavaScript fullstack — typiquement React, Vue ou Next.js côté front, Node.js côté back — il est tentant de considérer HTML et CSS comme des détails que le framework gérera. C’est précisément l’erreur qui produit des interfaces lourdes, inaccessibles et pénibles à maintenir. Le framework rend le HTML, mais c’est vous qui décidez de sa qualité.

HTML : redonner du sens aux balises

Le réflexe <div> partout est le marqueur d’un projet front en dérive. HTML5 propose un vocabulaire riche : <header>, <nav>, <main>, <article>, <section>, <aside>, <footer>, <button>, <figure>. Chacune porte un sens que les navigateurs, les moteurs de recherche et les lecteurs d’écran exploitent.

La règle pratique : avant de poser une <div>, demandez-vous si une balise plus précise existe. Une zone cliquable qui déclenche une action est un <button>, pas une <div> avec un onClick. Un lien qui mène ailleurs est un <a>, pas un <span> stylé. Ce n’est pas du purisme : un <button> est focusable au clavier, déclenchable avec Entrée, annoncé comme bouton par les outils d’accessibilité. Vous n’avez rien à coder pour ça — à condition d’avoir choisi la bonne balise.

L’accessibilité, justement, n’est pas une couche qu’on ajoute à la fin. Quelques réflexes suffisent à 80 % du travail : un attribut alt sur chaque <img> significative, des <label> reliés à leurs champs de formulaire, une hiérarchie de titres <h1> à <h6> cohérente, un contraste suffisant entre texte et fond. Le reste s’apprend au fil des projets.

CSS : maîtriser le poids et l’éparpillement

Le problème classique d’un projet fullstack JS n’est pas l’écriture du CSS — c’est sa prolifération. Chaque composant tend à embarquer ses propres styles, et au bout de quelques mois, personne ne sait plus ce qui sert encore.

Trois principes limitent les dégâts.

Choisir une stratégie de scoping, et s’y tenir. Scoping signifie limiter la portée d’une règle CSS pour qu’elle n’affecte que son composant. Les options courantes sont les CSS Modules (un fichier .module.css par composant, classes localisées automatiquement), les styled-components ou équivalents (CSS écrit dans le JavaScript), et les frameworks utilitaires comme Tailwind (classes prédéfinies appliquées directement dans le HTML). Aucune n’est universellement meilleure ; la mauvaise décision est de les mélanger sans raison sur un même projet.

Séparer les variables des règles. Couleurs, espacements, tailles de police, rayons de bordure : tout ce qui se répète doit vivre dans des custom properties CSS (--couleur-primaire, --espace-md). Cela coûte une heure au démarrage et économise des semaines lors d’un changement de charte graphique. C’est aussi la base d’un mode sombre propre.

Penser mobile d’abord. Écrivez d’abord les styles pour le petit écran, puis ajoutez les ajustements pour les plus grands via des media queries. L’inverse — concevoir pour le bureau puis « adapter » — produit presque toujours une expérience mobile médiocre.

Les ponts entre back et front

Dans un projet fullstack, vous générez parfois du HTML côté serveur (rendu Express avec un moteur de templates, ou Server-Side Rendering avec Next.js) et parfois côté client. Deux pièges à garder en tête.

D’abord, ne jamais injecter du contenu utilisateur dans du HTML sans l’échapper. Une chaîne <script>alert('xss')</script> venue d’un formulaire et collée brute dans une page ouvre une faille XSS (Cross-Site Scripting, injection de scripts entre sites). Les moteurs de templates sérieux échappent par défaut ; encore faut-il ne pas désactiver cette protection sans raison forte.

Ensuite, rendre côté serveur ce qui doit être visible immédiatement et indexable. Un titre, une description, le contenu principal d’un article doivent apparaître dans le HTML initial — pas être ajoutés par JavaScript après le chargement. C’est essentiel pour le référencement et pour les utilisateurs aux connexions lentes.

Le test qui ne ment pas

Une bonne pratique se vérifie facilement : désactivez CSS dans votre navigateur, naviguez sur votre site. Si la structure reste lisible — titres clairs, ordre logique, formulaires utilisables — votre HTML fait son travail. Désactivez maintenant JavaScript. Si la page d’accueil et les contenus principaux restent accessibles, votre fullstack est bien architecturé.

Ces deux tests prennent trente secondes. Ils en disent plus long sur la santé d’un projet que beaucoup d’outils sophistiqués.