HTML et CSS : ce que vous regardez quand vous ouvrez le code de votre site

Ce texte ne vous apprendra pas à écrire des sites. Il existe pour qu’un mot qui apparaît dans un devis ou dans une conversation avec votre prestataire cesse d’être un slogan et redevienne une chose que l’on peut interroger.

HTML, CSS, sémantique, code source, structure des titres : chacun de ces mots désigne quelque chose de précis, et une partie d’entre eux se traduit directement en ce que vous paierez pour une modification dans un an.

Les trois couches dont tout site est fait

Tout site web — quelle que soit la technologie qui le porte — se compose de trois couches qui font trois choses différentes.

HTML, c’est le contenu et sa structure. Il dit ce qui est un titre, ce qui est un paragraphe, ce qui est une liste, ce qui est un lien. Il ne dit pas de quoi cela doit avoir l’air : il dit ce que c’est. C’est la couche que lit le moteur de recherche, et c’est la couche que lit le lecteur d’écran d’une personne aveugle.

CSS, c’est l’apparence. Couleurs, espacements, polices, grille, comportement sur un écran étroit. Le même contenu HTML peut avoir une allure radicalement différente selon le CSS — et c’est précisément l’intérêt de séparer les deux.

JavaScript, c’est le comportement. Tout ce qui se produit après le chargement de la page : la réaction à un clic, un filtre, un calculateur, un formulaire envoyé sans rechargement. Nous le traitons séparément, au moment du choix d’une technologie côté navigateur.

Cette séparation a une conséquence pratique : chacune de ces couches est une conversation différente avec votre prestataire, et la première relève en grande partie de vous, pas de lui.

Ouvrir le code de son propre site : deux vérifications en deux minutes

Il n’est pas nécessaire de savoir lire du code pour y vérifier deux choses qui décident de la visibilité du site dans un moteur de recherche.

Ouvrez le code source. Dans votre navigateur, sur votre propre site : clic droit puis « Afficher le code source de la page », ou le raccourci Ctrl+U (Option+Cmd+U sur Mac). Un onglet s’ouvre avec du texte : c’est exactement ce que le serveur a envoyé au navigateur, et exactement ce que récupère le robot d’indexation. Ne le confondez pas avec « Inspecter », qui montre l’état de la page après exécution des scripts — une image que le robot ne voit pas nécessairement au premier passage.

Première vérification : votre contenu s’y trouve-t-il ? Appuyez sur Ctrl+F et cherchez n’importe quelle phrase de votre page. Si elle apparaît, le contenu est dans la première réponse du serveur et le moteur a de quoi indexer immédiatement. Si le fichier fait une quinzaine de lignes et ne contient que des appels à des scripts, le contenu n’existe qu’une fois le navigateur passé par là — ce qui retarde l’indexation de plusieurs jours, parfois de plusieurs semaines. Le mécanisme est détaillé dans notre texte sur Next.js et React.

Deuxième vérification : la page a-t-elle des descriptions pour le moteur de recherche ? Dans la même vue, cherchez <title> et meta name="description". Le premier est le titre affiché dans les résultats ; la seconde est la ligne en dessous. Si le title est identique sur toutes les pages, s’il dit « Accueil », ou s’il est absent, vous payez pour un site qui se présente n’importe comment là où on le découvre. C’est cinq secondes de travail et l’un des défauts les plus fréquents que nous trouvons en audit.

Faites ces deux vérifications sur plusieurs pages, pas seulement sur l’accueil : le problème commence en général à la deuxième. Et si votre site existe en plusieurs langues, refaites-les sur chaque version — nous y revenons plus bas, parce que c’est précisément là que les défauts se cachent.

Pourquoi un titre n’est pas une question de taille de caractères

C’est le malentendu le plus fréquent à la frontière entre les couches, et le plus coûteux dans ses effets.

Les titres — H1, H2, H3 — ne sont pas des styles de texte. Ils forment le squelette du document. H1 est le titre du livre, H2 les titres de chapitres, H3 les sous-chapitres à l’intérieur. Le moteur de recherche lit cette hiérarchie pour comprendre de quoi parle la page et quelle partie répond à quelle question.

Ce qui casse quand on s’en sert pour l’apparence. Quelqu’un veut qu’un passage soit plus petit et en gras, alors il le saisit comme un H3. Du point de vue de la structure, il vient d’annoncer le début d’un sous-chapitre — qui n’existe pas. Répétez l’opération une douzaine de fois et le site possède un squelette qui ne correspond à rien.

Qui y perd le plus. Pas Google : la personne qui utilise un lecteur d’écran. Ces personnes naviguent en sautant d’un titre à l’autre, exactement comme vous parcourez une page des yeux. La liste des titres leur tient lieu de sommaire. Si ce sommaire contient des entrées qui n’ouvrent aucune section, se déplacer dans la page devient une devinette.

La règle est simple et mérite d’être transmise à la personne qui rédige : un titre dit ce qu’est ce texte. Si votre intention est qu’il soit plus petit ou en gras, c’est une affaire de CSS, pas de balise. Le même principe gouverne les exigences d’accessibilité numérique, que nous traitons à part dans le texte consacré aux WCAG.

La sémantique, c’est-à-dire tout le reste de ce qui dit « ce que c’est »

Les titres en sont l’exemple le plus visible, mais le même principe s’applique à plusieurs autres endroits — et l’erreur y coûte la même chose.

La liste qui n’en est pas une. Des points séparés par des tirets à l’intérieur d’un paragraphe ressemblent à une liste sans en être une. Le lecteur d’écran ne dira pas « liste, cinq éléments » : il lira un long paragraphe avec des tirets dedans. Le moteur de recherche, lui aussi, voit un texte continu et non une énumération.

Le bouton qui est un lien, et le lien qui est un bouton. La différence n’est pas cosmétique : un lien emmène ailleurs, un bouton exécute quelque chose. Un élément construit « de travers » est souvent inatteignable au clavier, ce qui signifie, pour une partie de vos visiteurs, qu’il ne fonctionne tout simplement pas.

La description alternative d’une image. C’est un champ, à côté de la photo, qui décrit ce qu’elle montre. Le lecteur d’écran le lit, la recherche d’images le lit, et toute personne dont l’image ne s’est pas chargée le voit. C’est un champ que votre prestataire ne peut pas remplir à votre place : vous seul savez si la photo montre « une équipe » ou « l’équipe de montage devant notre nouvelle ligne d’assemblage ».

La langue de la page. Une information, dans le code, qui déclare dans quelle langue le texte est écrit. Sans elle, une synthèse vocale peut lire un texte français avec une prononciation anglaise — le résultat est exactement aussi mauvais que vous l’imaginez. Dans un pays où un site d’entreprise existe rarement en une seule langue, ce point mérite sa propre section, et il l’a plus bas.

Ces quatre choses ont un dénominateur commun : elles coûtent zéro si on les fait tout de suite, et elles deviennent une correction fastidieuse s’il faut les reporter sur un site terminé. Mieux vaut les avoir dans le cahier des charges que dans une liste de réclamations après la réception.

Ce que vous pouvez changer vous-même, et ce que vous ne pouvez pas

C’est la question qui suit immédiatement la première ouverture du code, et personne n’y répond franchement : jusqu’où peut-on toucher sans appeler quelqu’un ?

Ce qui est sans danger, toujours. Les textes, dans l’éditeur de votre système de gestion de contenu. Le titre et la description pour le moteur de recherche, quand votre système les expose — ce sont des messages commerciaux, pas des réglages techniques. Les descriptions alternatives des images. L’ordre des éléments d’un menu. Le remplacement d’une photo par une autre du même format : même proportion, même orientation. Ajouter un paragraphe, une liste, un lien. Rien de tout cela ne sort de la couche contenu, et c’est votre couche.

Ce qui est sans danger à une condition. Remplacer une image par une autre de proportions différentes : la mise en page va s’adapter, mais peut-être pas comme vous l’espérez, alors regardez le résultat sur un téléphone avant de partir. Changer un texte de bouton : vérifiez qu’il tient encore sur la largeur prévue. Modifier le niveau d’un titre : légitime si la structure change réellement, à éviter si le but est visuel.

Ce qui casse les choses, et le fait discrètement. Trois habitudes, par ordre de fréquence dans ce que nous récupérons en audit.

• Coller depuis un traitement de texte. Un texte copié depuis un document bureautique n’arrive jamais seul : il apporte avec lui une police, une taille et parfois une couleur, écrites directement sur le paragraphe. Or un style écrit directement sur l’élément l’emporte sur la feuille de style du site. Ce paragraphe cesse donc de suivre la charte, et personne ne le remarque — jusqu’au jour où vous changez la charte et où quatorze paragraphes, sur tout le site, refusent de changer avec elle. Le geste correct tient en une commande : coller sans mise en forme, puis remettre le gras et les liens dans l’éditeur.
• Coller un fragment venu d’un autre site. Le fragment emporte les noms de classes de ce site-là, qui ne veulent rien dire chez vous, et parfois des balises que votre gabarit ne prévoit pas. Cela passe le plus souvent inaperçu à l’écran et se remarque sur un téléphone.
• Ouvrir la vue « code source » de l’éditeur et y écrire du HTML à la main. Le bouton existe et il est parfois utile. Mais à l’instant où vous l’utilisez, vous devenez propriétaire de ce que vous écrivez : une balise ouverte et jamais fermée y déforme la page entière et non le seul paragraphe concerné.

Ce qui ne relève pas de vous, et pourquoi. Le gabarit, la feuille de style, tout ce qui vit dans le thème. Et surtout : coller le code d’un outil tiers — une étiquette de mesure, un module de discussion, une bannière — sans prévenir personne. Ce code s’exécute sur chaque page, il peut ralentir le site, il peut en modifier la mise en page, et c’est la première chose qu’il faudra soupçonner quand quelque chose ira mal dans six mois. Ce n’est pas interdit ; cela demande simplement d’être su de la personne qui maintient le site.

Une règle qui couvre les cas non prévus : si votre modification concerne ce que dit le site, elle est à vous ; si elle concerne la manière dont il le dit, elle est à lui.

Comment une deuxième langue apparaît dans le balisage

Ici, un site d’entreprise est rarement monolingue. Français et allemand, souvent l’anglais en troisième, parfois l’italien. Ce n’est pas une option en fin de devis : c’est le cas normal, et cela change ce qu’il faut regarder dans le code.

Premier point, et c’est le plus mal compris : une deuxième langue n’est pas un texte alternatif rangé dans la même page. C’est une page de plus, avec sa propre adresse. Trois formes existent : un sous-répertoire (votreentreprise.ch/fr/, votreentreprise.ch/de/), un sous-domaine, ou un domaine distinct par marché. Le sous-répertoire est le plus courant et le plus simple à exploiter. Ce qui compte, quelle que soit la forme retenue : chaque version doit pouvoir être ouverte, partagée et indexée par son adresse propre. Un site où le changement de langue se fait sans que l’adresse bouge est un site dont une seule version existe pour le moteur de recherche.

Deuxième point : l’attribut de langue doit suivre la page. Sur la version française, le code déclare le français ; sur la version allemande, l’allemand. Le défaut le plus banal est un gabarit qui inscrit une valeur en dur, si bien que les trois versions se déclarent dans la même langue. Vous le vérifiez en deux secondes : Ctrl+U sur la version allemande, tout en haut du fichier, la balise <html> porte la langue déclarée. Si elle dit fr sur une page en allemand, c’est faux, et la synthèse vocale le fera entendre.

Troisième point : les versions doivent se déclarer les unes les autres. C’est le rôle des lignes hreflang. Chaque version énumère toutes les autres, y compris elle-même — c’est la partie que l’on oublie —, et les déclarations doivent être réciproques : si la page française désigne la page allemande, la page allemande doit désigner la page française. Une déclaration à sens unique n’est pas prise en compte, et les deux pages redeviennent aux yeux du moteur deux documents sans rapport, ou pire, deux documents concurrents. On ajoute en général une entrée x-default, qui désigne la version à servir quand aucune langue ne correspond au visiteur. Là encore, la vérification est à votre portée : Ctrl+U, Ctrl+F, hreflang, et comptez les lignes — il doit y en avoir autant que de versions.

Quatrième point, celui qui se voit à l’usage : le sélecteur de langue doit mener à l’équivalent de la page en cours, pas à l’accueil. Un visiteur qui lit votre page « Services » en français et bascule en allemand attend la page « Services » en allemand. S’il atterrit sur l’accueil, il recommence sa navigation, et une partie de ces visiteurs ne recommence pas. Ce n’est pas un détail d’interface : pour que le lien existe, le système doit savoir quel document est la traduction de quel autre — c’est une décision de modélisation, prise au moment de construire le site, et beaucoup plus coûteuse à rattraper après.

Ce qui se duplique avec la deuxième langue, et ce qui ne se duplique pas. Ne se duplique pas : la feuille de style. Les couleurs, les espacements, la grille sont les mêmes pour toutes les langues, et c’est une bonne nouvelle pour le budget. Se duplique, en revanche : chaque texte, chaque titre et description pour le moteur de recherche, chaque description alternative d’image — et, point que l’on découvre tard, chaque mot écrit à l’intérieur d’une image. Un schéma dont les légendes sont dans le fichier graphique doit être refait dans chaque langue ; un schéma dont les légendes sont du texte posé par-dessus ne se traduit qu’une fois. Cela ne change rien sur un site d’une seule langue et cela change tout sur trois.

Un piège de mise en page, propre au multilinguisme et invisible sur maquette. Le même bouton porte « Envoyer » en français et « Absenden » en allemand ; le même menu porte « À propos » et « Über uns ». Une largeur fixée sur le mot le plus court casse sur l’autre langue. La règle de travail est simple : rien dans la mise en page ne doit dépendre de la longueur d’un mot particulier, et la vérification se fait en ouvrant chaque version sur un téléphone, pas en la relisant dans l’éditeur.

Nous parlons ici d’expérience directe : ce site existe en quatre versions linguistiques, chaque document portant ses propres titre, description et textes alternatifs, pour une seule et même feuille de style. La partie coûteuse n’a jamais été technique : c’est le contenu, et c’est presque toujours le cas.

Pourquoi changer la couleur d’un bouton coûte cinq minutes, ou bien une semaine

Ici, le CSS cesse d’être un sujet technique pour devenir une ligne de votre budget.

La version bon marché. Un CSS bien écrit range les décisions visuelles à un seul endroit, sous forme de valeurs nommées : couleur principale, couleur d’accent, taille de texte, espacement. Tous les boutons, titres et encadrés font référence à ces noms au lieu de répéter une valeur. Changer la couleur de la marque, c’est alors une modification, dans un fichier.

La version chère. La couleur écrite « en dur » partout où elle apparaît : à cent endroits dans le code, plus dans une douzaine d’extensions, plus dans des textes saisis par la rédaction. La modification suppose de trouver toutes les occurrences, de corriger chacune et de vérifier qu’aucune n’a été oubliée. Les semaines ne viennent pas de la complexité : elles viennent du nombre d’endroits.

Ce que cela donne chez nous. Ce site compte 164 valeurs nommées — couleurs, tailles de texte, espacements, variantes claire et sombre — définies dans un seul fichier, à travers 315 déclarations couvrant les différents thèmes (comptées le 11 septembre 2026). Changer la couleur d’accent sur l’ensemble du site, mode sombre compris, tient en une ligne.

La question à poser à la réception du site : « où sont définies les couleurs et les polices, et combien d’endroits faut-il modifier pour changer la couleur de la marque ? » La réponse « dans un fichier, sous forme de variables » signifie que vous payez pour du code que l’on peut entretenir. Une réponse évasive signifie en général que chaque modification future fera l’objet d’un nouveau devis.

Le même raisonnement vaut pour les polices, les espacements et les largeurs auxquelles la mise en page bascule sur téléphone. La qualité du CSS ne se voit pas à l’écran : elle se voit sur la facture de la deuxième modification.

Ce qui se passe quand le site arrive sur un téléphone

L’adaptation aux petits écrans figure souvent dans les devis comme un point unique, comme s’il s’agissait d’un interrupteur. Ce n’en est pas un : c’est un ensemble de décisions sur ce qu’il advient de la mise en page quand l’écran rétrécit, et une partie de ces décisions vous appartient.

Sur un grand écran, trois colonnes se tiennent côte à côte. Sur un téléphone, elles doivent se ranger l’une sous l’autre — et la question devient : dans quel ordre ? Ce n’est pas une question technique : sur téléphone, le visiteur verra d’abord ce que vous aurez placé en haut, et il ne lira peut-être pas le reste. La même remarque vaut pour les tableaux, qui sur un écran étroit se replient, défilent latéralement, ou cessent d’être lisibles.

Trois choses à vérifier vous-même, sur votre propre téléphone, avant de réceptionner un site :

• L’action la plus importante se fait-elle d’un seul pouce : trouver l’offre, ouvrir le formulaire, envoyer.
• Quelque chose déborde-t-il sur le côté ? Si la page se déplace latéralement, un élément est plus large que l’écran ; c’est un défaut, pas une caractéristique.
• Le texte est-il lisible sans zoomer, et les boutons atteignables avec un doigt et non seulement avec un curseur ?

Ce sont exactement les vérifications que nous faisons en audit — et elles se passent moins bien que tout le monde ne le suppose, parce qu’un site se conçoit sur un écran d’ordinateur et se consulte sur un téléphone.

Ce qui relève de vous, et ce qui relève du prestataire

Le partage que nous proposons à nos clients et que nous appliquons chez nous :

À vous : les textes et ce qu’ils sont — ce qui est le titre de la page, ce qui est un intertitre, ce qui est un paragraphe ordinaire. Les descriptions alternatives des images, puisque vous seul savez ce que montre la photo et pourquoi elle est là. Les titres et descriptions destinés au moteur de recherche, parce que ce sont des messages commerciaux et non des réglages. Et, sur un site multilingue, la décision de ce qui existe dans quelle langue : tout n’a pas à être traduit, mais quelqu’un doit décider, et ce quelqu’un n’est pas le prestataire.

En commun : la hiérarchie du contenu et le choix des informations les plus importantes — le prestataire indique comment l’exprimer, mais l’ordre découle de ce que vous vendez.

À lui : tout ce qui se trouve en dessous — l’organisation du code, l’endroit où vivent les variables, le comportement du site sur une connexion lente, le fonctionnement des scripts.

La frontière tient en une phrase : si la décision porte sur le sens du contenu, elle est à vous ; si elle porte sur la manière de le réaliser, elle est à lui. La plupart des désaccords à la réception d’un site viennent de ce que quelqu’un a franchi cette ligne dans un sens ou dans l’autre.

Ce que vous n’avez pas besoin de savoir

Vous n’avez pas besoin de savoir écrire du HTML pour commander un bon site, pas plus que vous ne coulez vous-même les fondations de vos bureaux. Vous avez besoin de savoir poser quatre questions et de vérifier deux choses dans le code source, ce qui prend quelques minutes en tout.

Si malgré cela vous voulez essayer vous-même — parce que vous testez une idée, parce que vous aimez comprendre les choses de l’intérieur, ou parce que le site doit rester un loisir — nous avons un texte séparé pour cela : un site en HTML, quand cela suffit. C’est une autre voie et nous ne faisons pas semblant qu’elle n’existe pas.

Cinq mots des devis, traduits

HTML sémantique — du code dans lequel les balises décrivent ce qu’est le contenu et non de quoi il a l’air. C’est le sujet de tout ce texte.

Validation — la vérification que le code est formellement correct. Utile, mais ne dit rien en soi de la qualité du site : on peut avoir un code irréprochable sur la forme et inutilisable en pratique.

Point de rupture (breakpoint) — la largeur d’écran à laquelle la mise en page change. Moins il y en a et mieux ils sont choisis, moins il existe d’endroits où le site a l’air bizarre.

Système de design — l’ensemble des décisions visuelles nommées dont il est question plus haut : couleurs, espacements, polices au même endroit. Dans un devis, cela signifie que le prestataire compte écrire du code que l’on pourra entretenir.

Minification — le retrait, dans les fichiers, de tout ce qui s’y trouve pour l’humain et non pour le navigateur. Un standard, pas un avantage ; si quelqu’un l’inscrit comme un bénéfice distinct, il vaut la peine de demander ce qu’il y a d’autre, dans cette offre, qui relève du standard.

Quatre questions à poser à votre prestataire

1. Le contenu se trouve-t-il dans le code de la page dès la première réponse du serveur ? Vous vérifierez la réponse vous-même, Ctrl+U.
2. Chaque page a-t-elle son propre titre et sa propre description pour le moteur de recherche — dans chaque langue ? Même endroit, Ctrl+F.
3. Les titres décrivent-ils la structure du contenu, ou seulement la taille des caractères ? La question épargne à la personne qui rédige une reprise générale plus tard.
4. Où sont définies les couleurs et les polices ? Un seul endroit ou cent : c’est le prix de chacune de vos modifications visuelles futures.

Et, sur un site en plusieurs langues, une cinquième : le sélecteur de langue mène-t-il à l’équivalent de la page en cours ? Testez-le depuis une page intérieure, jamais depuis l’accueil — depuis l’accueil, toutes les réponses ont l’air bonnes.

D’où viennent ces chiffres

• 164 valeurs nommées dans 315 déclarations — comptées dans la feuille de style globale de ce site le 11 septembre 2026.
• Volumes de recherche — Keyword Planner, Suisse, langue française : html css 260 par mois, apprendre html 10. Ce sont de petits volumes, et nous préférons l’écrire que le maquiller : le marché francophone suisse est mince sur ce sujet.
• Ce qui ne figure volontairement pas ici — la liste des balises HTML. Cette demande existe, mais c’est un aide-mémoire pour qui écrit du code, pas pour une entreprise qui commande un site ; y répondre reviendrait à réécrire une documentation qui existe déjà et qui est meilleure.