HTML structure le contenu d'un site web, CSS gère son apparence visuelle et JavaScript ajoute son interactivité : ce sont les trois langages fondamentaux et complémentaires du web, chacun avec un rôle distinct, comme le maçon, le décorateur et l'électricien d'une maison.
Construire une maison pas à pas
Imaginez que vous construisez une maison. Trois corps de métier interviennent, chacun avec un domaine d'expertise distinct :
HTML : la structure — c'est le maçon
HTML (HyperText Markup Language) est le maçon de la maison web. Il positionne les murs, les pièces, les portes et les fenêtres. Il définit où chaque élément se trouve et de quoi il s'agit.
Un titre est un <h1>, un paragraphe un <p>, un bouton un <button>. Cette sémantique — comme les plans d'une maison — permet aux moteurs de recherche, aux lecteurs d'écran et aux outils d'indexation de comprendre votre contenu.
CSS : l'habillage — c'est le peintre et le décorateur
CSS (Cascading Style Sheets) est le peintre. Une fois les murs levés par le maçon, c'est lui qui choisit les couleurs, les papiers peints, les pompes, les éclairages. Il gère la présentation visuelle : couleurs, polices, espacements, grilles, animations.
C'est également le décorateur : il décide que tel encadré prendra 40 % de la largeur sur desktop mais 100 % sur mobile. Le design réactif (responsive) repose entièrement sur les media queries CSS — comme adapter un intérieur à différentes tailles de pièces.
JavaScript : la plomberie et l'électricité — c'est l'électricien
JavaScript est l'électricien et le plombier. Une fois la maison construite et décorée, c'est lui qui fait fonctionner les prises, les interrupteurs, les robinets. Il apporte la logique et l'interactivité.
Pas de prise = pas de courant. Pas de JavaScript = un site immobile. Mais une maison sans plomberie fonctionne toujours — elle est juste statique. C'est exactement le principe du web : un site sans JS est accessible à tous, un site sans JS mal codé l'est encore plus.
Pourquoi ces trois langages restent séparés
On ne mélange pas le maçon, le peintre et l'électricien. De la même façon, HTML, CSS et JS restent dans des fichiers séparés :
- Maintenance
- Modifier le style graphique (CSS) n'impacte pas la structure (HTML) ni la logique (JS). Le décorateur peut changer les couleurs sans démolir les murs.
- Réutilisabilité
- Un seul fichier CSS ou JS peut s'appliquer à plusieurs pages HTML d'un même site. Même palette de couleurs, même installation électrique, mais des maisons différentes.
- Performance
- Les navigateurs mettent en cache les fichiers CSS et JS lors de la première visite, accélérant le chargement des pages suivantes. Comme un électricien qui installe un tableau une fois pour toutes.
Les frameworks : des briques de construction pré-fabriquées
Les frameworks et bibliothèques (Tailwind, Bootstrap, React, Next.js) sont comme des modules pré-fabriqués. Au lieu de construire chaque mur à la main, vous utilisez des briques standardisées.
Frameworks CSS : Bootstrap et Tailwind
Bootstrap fournit des composants graphiques prêts à l'emploi (boutons, cartes, barres de navigation) et un système de grille — comme des kits de mobilier de cuisine toute équipée.
Tailwind CSS adopte une approche « utility-first » : des classes directement dans le HTML (flex, pt-4, text-center) pour concevoir des interfaces sur mesure — comme des peintures données par lot, sans passer par un décorateur.
Frameworks JavaScript : React, Vue.js, Next.js
React et Vue.js découpent l'interface en composants réutilisables — comme des modules électriques standardisés (un interrupteur, un variateur) qu'on combine.
Next.js ajoute l'infrastructure : rendu côté serveur (SSR), génération statique (SSG), gestion des routes et SEO avancé. C'est le plan d'architecture du bâtiment.
HTML5 n'est pas un framework
HTML5 est la version actuelle de la norme HTML — comme le code de la construction. Il intègre des balises sémantiques (<article>, <header>, <nav>) et la gestion native de la vidéo et de l'audio. Aucune couche d'abstraction ; c'est la matière première.
Pourquoi le développement Vanilla bat WordPress
Le développement en HTML, CSS et JavaScript purs — sans frameworks ni bibliothèques — présente des avantages techniques mesurables.
Performances et légèreté
- Taille minimale. Absence de dépendances lourdes à télécharger. Les fichiers restent légers.
- Vitesse d'exécution. Pas de surcouche d'abstraction ni d'outils intermédiaires (comme le DOM virtuel de React). Le navigateur exécute directement le code natif.
- Temps de chargement (FCP/LCP). Amélioration du premier affichage, critère favorisé par les moteurs de recherche.
Pérennité et stabilité
- Aucun risque d'obsolescence. Les standards du Web (W3C) évoluent en assurant la rétrocompatibilité. Un code Vanilla écrit aujourd'hui fonctionnera encore dans dix ans.
- Indépendance écosystémique. Pas de ruptures de compatibilité lors du passage d'une version à l'autre.
- Sécurité réduite. Moins de dépendances externes diminue la surface d'attaque liée aux vulnérabilités de la chaîne d'approvisionnement (supply chain attacks).
Simplicité de déploiement
- Soutien natif des navigateurs : Flexbox, CSS Grid, variables CSS, API fetch, modules ES6 sont intégrés nativement.
- Aucune compilation : pas de bundler (Webpack, Vite) ni transpileur (Babel). Le déploiement se résume au transfert des fichiers sur un serveur web.
- Débogage direct : le code inspecté dans le navigateur est exactement le code écrit.
WordPress vs Vanilla : le match sur le statique
Pour des sites purement statiques (vitrines, pages d'atterrissage, portfolios), l'approche Vanilla est supérieure à WordPress sur la plupart des critères techniques.
| Critère | Vanilla | WordPress |
|---|---|---|
| Temps de chargement | Instantané | 1 à 3 secondes |
| Surface d'attaque | Quasi nulle | Plugins, PHP, MySQL |
| Coût d'hébergement | 0 € | 5 à 50 €/mois |
| Mises à jour | Aucune | Hebdomadaires |
Le vrai dilemme : l'autonomie du client
Le choix entre Vanilla et WordPress se résume à une question : votre client doit-il modifier son contenu lui-même ?
- Le client ne touche à rien (ou rarement) : Vanilla est la meilleure option. Une modification par an passe par vous via un contrat de maintenance.
- Le client veut modifier ses textes seul au quotidien : la limite du Vanilla pur. Modifier du code HTML directement est irréaliste pour un non-technicien.
La solution hybride : Vanilla + Decap CMS
Si votre client exige de modifier son contenu en autonomie tout en gardant les avantages du Vanilla, la réponse moderne est le CMS Statique / Headless (Decap CMS) couplé à votre code HTML/CSS/JS.
Le client dispose d'un panneau d'administration visuel pour éditer ses textes, et l'outil regénère automatiquement les fichiers HTML statiques en arrière-plan. Le meilleur des deux mondes.
Et le PHP dans tout ça ?
PHP (PHP: Hypertext Preprocessor) est un langage exécuté côté serveur (backend). Contrairement à HTML, CSS et JS qui s'exécutent dans le navigateur, PHP tourne sur le serveur avant d'envoyer le résultat au client.
Rôles principaux
- Génération dynamique
- PHP assemble du contenu à la volée. Deux utilisateurs venant la même URL peuvent voir des données différentes.
- Base de données
- Communication avec MySQL ou PostgreSQL pour lire, insérer, modifier des informations.
- Logique métier
- Authentification, paiement, traitement sensible invisible par l'utilisateur.
Mais pour un site statique, PHP est inutile : le fichier HTML est servi tel quel, sans calcul serveur, sans base de données, sans exécution de script.
Conclusion : choisir la bonne couche
Construire un site web, c'est assembler trois spécialistes :
- HTML : le maçon, qui pose les fondations et les murs.
- CSS : le décorateur, qui peint et aménage l'intérieur.
- JavaScript : l'électricien, qui rend tout ça fonctionnel.
Les frameworks sont des briques pré-fabriquées — utiles pour les gros projets, mais ils ajoutent du poids. Le Vanilla (HTML, CSS, JS purs) reste la solution idéale pour les sites vitrines : léger, sûr, rapide, et sans obsolescence.
Associé à un CMS headless comme Decap CMS, vous obtenez l'autonomie du client sans renoncer aux performances. C'est la stack que j'emploie pour tous les sites que je crée — vérifiée par les moteurs de recherche, testée par les clients.