Les Bases
du Web

En clair : Utiliser <div> partout, c'est comme ecrire un livre sans chapitres ni paragraphes. Le texte est la, mais personne ne s'y retrouve. Les balises semantiques (<header>, <nav>, <main>, <footer>) donnent un role a chaque zone. Google et les lecteurs d'ecran comprennent ta page sans la voir.

En clair : Un formulaire, c'est un dialogue entre ton site et le visiteur. Chaque champ (<input>) est une question, et le <label> est l'etiquette qui dit a quoi sert le champ. Sans label, c'est comme un formulaire papier sans intitule : le visiteur ne sait pas quoi ecrire ou. Le type du champ (email, tel) adapte meme le clavier sur mobile.

En clair : Un tableau HTML, c'est comme un tableur Excel. Tu as des lignes (<tr>), des cellules d'en-tete (<th>) et des cellules de donnees (<td>). Le <thead> et le <tbody> separent l'en-tete du contenu, comme la premiere ligne figee dans un tableur. Utilise les tableaux pour des donnees, jamais pour la mise en page.

En clair : Chaque media a sa balise dediee. <img> pour les images, <video> pour les videos, <audio> pour le son. C'est comme brancher le bon cable sur le bon appareil. L'attribut alt sur une image, c'est la description pour ceux qui ne la voient pas (mal-voyants, connexion lente). Et width/height reserve l'espace pour eviter que la page saute au chargement.

En clair : Les liens (<a>) sont les portes entre les pieces de ton site. Un lien interne mene a une autre page de ton site, un lien externe mene ailleurs sur le web. L'attribut href est l'adresse de destination. Et target="_blank" ouvre la porte dans un nouvel onglet, pour que le visiteur ne quitte pas ta page.

En clair : Chaque element HTML est comme un colis. Il y a le contenu (l'objet), le padding (le papier bulle autour de l'objet), la border (le carton) et le margin (l'espace entre les colis sur l'etagere). Par defaut, le navigateur ajoute padding et border en plus de la taille. Avec box-sizing: border-box, tout est inclus dans la taille que tu definis.

En clair : Imagine une etagere. Tu poses des objets dessus, et tu decides : les coller a gauche, les centrer, ou les espacer regulierement. Flexbox fait pareil avec tes elements HTML. Tu dis au parent "deviens une etagere" avec display: flex, puis tu choisis comment repartir les enfants avec justify-content (horizontal) et align-items (vertical).

En clair : Si Flexbox est une etagere (une dimension), Grid est un damier (deux dimensions). Tu definis des colonnes et des lignes, puis tu places tes elements dans les cases. C'est comme un plan d'architecte : tu dessines la grille d'abord, tu poses les meubles ensuite. Ideal pour les mises en page complexes avec header, sidebar, contenu et footer.

En clair : Imagine que tu peins un appartement. Si tu ecris la reference de couleur sur chaque mur, changer d'avis te force a tout repeindre. Mais si tu etiquettes un pot "couleur principale" et que tout le monde pioche dedans, il suffit de changer le pot. Les variables CSS (--nom) fonctionnent pareil : une valeur definie une fois, utilisee partout.

En clair : Sans transition, un changement de style est instantane : le bouton est bleu, puis d'un coup il est violet. Avec transition, tu ajoutes un fondu entre les deux etats. C'est comme un variateur de lumiere au lieu d'un interrupteur. Tu choisis ce qui change, en combien de temps, et avec quel rythme (lent au debut, rapide a la fin, etc.).

En clair : Ta page HTML est un arbre. Chaque branche est un element. Cet arbre s'appelle le DOM (Document Object Model, c'est la version en memoire de ta page). JavaScript peut secouer cet arbre : ajouter des branches, en couper, changer les feuilles. C'est ca, manipuler le DOM. Tu selectionnes un element avec querySelector, puis tu modifies son texte, son style ou ses attributs. Tout se passe en direct, sans recharger la page.

En clair : Un evenement, c'est quelque chose qui se passe : un clic, une touche pressee, un scroll. addEventListener dit a JavaScript : "quand ca arrive, execute cette action". C'est comme un detecteur de mouvement : tu le places, et il reagit tout seul quand quelqu'un passe. Sans evenements, ta page est une affiche figee.

En clair : fetch, c'est le facteur de ton site. Il va chercher des donnees sur un serveur via une API (un guichet de donnees sur un serveur) et te les rapporte. La reponse arrive au format JSON : un texte structure que JavaScript comprend nativement. C'est comme ca que ton site affiche la meteo, charge des articles ou envoie un formulaire sans recharger la page.

En clair : C'est un tiroir dans le navigateur. Tu y ranges des infos (theme sombre, panier, preferences). Elles restent meme apres avoir ferme le navigateur. Contrairement aux cookies, ces donnees ne partent jamais vers le serveur. C'est du stockage local, simple et gratuit. Parfait pour retenir les choix du visiteur sans base de donnees.

En clair : ES6, c'est la version moderne de JavaScript (sortie en 2015). Avant, le code etait verbeux et dur a lire. Les fleches (=>) raccourcissent les fonctions. Le destructuring extrait les valeurs d'un objet en une ligne. Les template literals (`...`) permettent d'inserer des variables dans du texte. C'est plus propre, plus court, plus lisible.

En clair : Mobile-first, c'est construire ta maison en commencant par le studio. Tu dessines d'abord pour le plus petit ecran (mobile), puis tu ajoutes de l'espace et des colonnes pour les grands ecrans. C'est plus simple que l'inverse : ajouter est facile, retirer est penible. Et 60% du trafic web est mobile aujourd'hui.

En clair : Un breakpoint, c'est la taille d'ecran ou ton design change de forme. Comme une porte pliante : a partir d'une certaine largeur, elle se deplie. Tu n'as pas besoin de 15 breakpoints. Trois suffisent : mobile, tablette, desktop. Choisis-les en fonction de ton contenu, pas d'un modele de telephone precis.

En clair : Envoyer une image 4K a un telephone, c'est comme livrer un canape par helicoptere. Ca marche, mais c'est du gaspillage. srcset donne au navigateur une liste de tailles. Il choisit la plus adaptee a l'ecran. Le format WebP est 30% plus leger que le JPEG. Resultat : des pages plus rapides, surtout sur la 4G.

En clair : Sur un telephone, tu tapes avec ton doigt, pas avec un curseur de souris precis au pixel. Un bouton de 20px, c'est trop petit : tu rates une fois sur deux. La regle : minimum 44x44 pixels pour chaque zone cliquable. C'est la taille d'un bout de doigt. Pense aussi a l'espacement entre les boutons pour eviter les clics accidentels.

En clair : Le mode responsive des DevTools, c'est une simulation. Pas la realite. Un vrai telephone a un ecran different, un navigateur different, un debit different. Si tu ne testes pas sur un vrai appareil, tu vas decouvrir les bugs en production. Teste au minimum sur un iPhone et un Android. Utilise le Wi-Fi de ton telephone pour voir ton site local.

En clair : ARIA, c'est un traducteur pour les lecteurs d'ecran. Quand le HTML seul ne suffit pas (un menu qui s'ouvre, un onglet actif, un spinner de chargement), ARIA ajoute des informations invisibles. aria-expanded dit si un menu est ouvert ou ferme. role="alert" annonce un message important. Mais la regle d'or : si une balise HTML native suffit, utilise-la. ARIA est un complement, pas un remplacement.

En clair : Imagine lire un texte gris clair sur fond blanc en plein soleil. Impossible. Le ratio 4.5:1, c'est la garantie que tout le monde peut lire, meme dans de mauvaises conditions. Ce ratio compare la luminosite du texte avec celle du fond. Les outils le calculent pour toi. Si c'est en dessous de 4.5, change ta couleur. C'est une regle legale dans beaucoup de pays.

En clair : Certaines personnes n'utilisent pas de souris. Elles naviguent avec Tab (element suivant), Shift+Tab (precedent) et Entree (activer). Si ton site ne fonctionne qu'a la souris, tu exclus ces utilisateurs. Le focus visible (le contour bleu) est essentiel : c'est la fleche du curseur version clavier. Ne le cache jamais. Si tu crees un element cliquable, il doit etre focusable.

En clair : Un lecteur d'ecran (VoiceOver, NVDA) lit ta page a voix haute. Il annonce les titres, les liens, les boutons, les images. Si une image n'a pas de alt, il dit "image" sans rien expliquer. Si un bouton n'a pas de texte, il dit "bouton" tout court. Chaque element interactif doit avoir un nom compréhensible a l'oral. Pense : "est-ce que ca a du sens si je l'entends sans le voir ?"

En clair : Ton visiteur a peut-etre active le mode sombre, reduit les animations ou agrandi le texte dans ses reglages systeme. CSS peut detecter ces preferences et s'adapter automatiquement. prefers-color-scheme detecte le mode sombre. prefers-reduced-motion detecte les gens sensibles aux animations. Respecter ces choix, c'est de la politesse numerique.

En clair : Les titres H1 a H6, c'est la table des matieres de ta page. Google la lit pour comprendre le sujet. Un seul H1 par page (le titre principal). Puis des H2 pour les sections, des H3 pour les sous-sections. Comme un livre : un seul titre de couverture, plusieurs chapitres, plusieurs paragraphes par chapitre. Ne saute jamais de niveau (pas de H1 puis H4).

En clair : Google mesure 3 choses sur ta page. LCP : combien de temps avant que le plus gros element s'affiche (ton image hero, par exemple). FID : combien de temps avant que le site reagisse au premier clic. CLS : est-ce que la page bouge toute seule pendant le chargement. C'est comme un restaurant : le plat arrive vite (LCP), le serveur repond vite (FID), et la table ne bouge pas (CLS).

En clair : Une image de 5 Mo, c'est comme envoyer un colis de 10 kg par la poste pour un objet de 200 g. Le format WebP compresse mieux que JPEG (30% plus leger). Le lazy loading dit au navigateur : "charge cette image seulement quand le visiteur arrive dessus". Moins de poids = page plus rapide = visiteurs plus contents = Google plus content.

En clair : Imagine que tu prepares un repas. Tu sors les ingredients du frigo avant de commencer a cuisiner, pas au dernier moment. preload dit au navigateur : "cette ressource est urgente, telecharge-la tout de suite". prefetch dit : "le visiteur ira probablement sur cette page ensuite, prepare-la en arriere-plan". Le bon timing fait toute la difference.

En clair : Ton code CSS et JS contient des espaces, des retours a la ligne, des commentaires. C'est utile pour toi, mais inutile pour le navigateur. La minification supprime tout ca. C'est comme compresser une valise : le contenu est le meme, mais il prend moins de place. Resultat : fichiers plus legers, telechargement plus rapide, visiteurs plus heureux.

En clair : Git, c'est un Ctrl+Z surpuissant pour ton projet. Chaque "commit", c'est une photo de ton code a un instant T. Tu peux revenir en arriere, comparer les versions, travailler a plusieurs sans ecraser le travail de l'autre. Sans Git, un fichier supprime par erreur est perdu pour toujours. Avec Git, tu remontes le temps en une commande.

En clair : Les DevTools, c'est une radio du corps humain pour ta page web. Tu vois les os (HTML), les vetements (CSS), les reflexes (JS). Tu cliques sur un element, tu vois son code, ses styles, ses marges. Tu modifies en direct pour tester. Rien n'est sauvegarde : c'est un bac a sable. Tous les navigateurs l'ont. Raccourci : F12 ou clic droit > Inspecter.

En clair : Ton site marche sur ton ordinateur. Super. Mais personne d'autre ne le voit. Le deploiement, c'est demenager ton site de ton PC vers un serveur accessible a tous. Des services gratuits comme Netlify ou Vercel le font en 2 minutes. Tu relies ton depot GitHub, et a chaque push, le site se met a jour automatiquement. Zero config, zero stress.

En clair : C'est la liste des invites a ta fete. Seuls les scripts autorises peuvent entrer. Les autres sont bloques a la porte. La CSP (Content Security Policy) dit au navigateur : "accepte les scripts de mon domaine et de Google Fonts, mais bloque tout le reste". Si un pirate injecte un script malveillant, le navigateur le refuse car il n'est pas sur la liste.

En clair : Imagine que quelqu'un colle un faux panneau sur ta vitrine. Les visiteurs le croient vrai. Le XSS, c'est pareil : du faux code injecte dans ta page. Un pirate ecrit du JavaScript dans un champ de formulaire. Si tu affiches ce texte tel quel, le code s'execute chez tous les visiteurs. Il peut voler des cookies, rediriger vers un faux site, ou afficher du contenu trompeur.

En clair : Imagine qu'un site piege envoie un formulaire a ta banque en ton nom, sans que tu le saches. Le CSRF (Cross-Site Request Forgery), c'est ca : un faux ordre envoye avec tes identifiants. La solution : un token unique et secret dans chaque formulaire. Le serveur verifie que le token est valide. Si quelqu'un envoie le formulaire depuis un autre site, il n'a pas le token. Requete refusee.

En clair : Chaque champ de formulaire est une porte d'entree. Un visiteur peut y ecrire n'importe quoi : du code, des commandes, des caracteres bizarres. La sanitization, c'est le vigile qui fouille les sacs a l'entree. Tu nettoies chaque donnee avant de l'utiliser. Tu supprimes les balises HTML, tu limites la longueur, tu verifies le format. Cote client ET cote serveur. Toujours les deux.

En clair : Les headers de securite sont des consignes que ton serveur donne au navigateur. "N'integre pas ma page dans une iframe" (clickjacking). "N'envoie pas le referrer complet" (vie privee). "Force le HTTPS pendant 1 an" (HSTS). C'est comme mettre une alarme, un verrou et une camera sur ta maison. Chaque header bloque un type d'attaque specifique.