Pourquoi tes modifications HTML ne s'affichent pas dans le navigateur

Une fois, ça m'a occupé dix bonnes minutes. J'enregistrais un fichier dans mon dossier Téléchargements et je rafraîchissais un onglet qui affichait la même page — ouverte, elle, depuis mon Bureau. Même nom, même contenu, deux fichiers différents, et je modifiais consciencieusement la copie que personne ne regardait. C'est l'histoire classique. Quand une modification HTML refuse de s'afficher, le code n'est presque jamais en cause — c'est un cache périmé, un fichier que tu n'as pas vraiment enregistré, une extension .html.txt, une retouche coincée dans les DevTools, ou le navigateur qui lit une autre copie que celle que tu as changée. Voici la checklist que je déroule, du plus rapide à attraper au reste.

la checklist en soixante secondes

Avant de toucher à quoi que ce soit, lis cette liste de haut en bas. La plupart du temps, la réponse y est déjà.

• Tu n'as pas enregistré. La modif est encore dans l'éditeur, jamais écrite sur le disque.
• Tu regardes une autre copie. L'onglet pointe vers un autre dossier, ou vers une version en ligne — pas le fichier que tu as édité.
• Le navigateur l'a mis en cache. Il te sert l'ancienne page ou l'ancien CSS depuis sa mémoire au lieu de relire le fichier.
• Le fichier a la mauvaise extension. index.html.txt a l'air correct et se comporte comme du texte brut.
• Tu ne l'as changé que dans les DevTools. Ces retouches vivent dans l'onglet et disparaissent au rechargement.
• Une autre règle CSS écrase la tienne. Ta modif est bien là — elle perd juste la cascade.

Maintenant les correctifs, dans l'ordre où je les vérifierais vraiment.

tu n'as pas vraiment enregistré

Commence par la possibilité la plus bête, parce que c'est la plus fréquente. Regarde l'onglet de ton éditeur — s'il porte un point ou un astérisque, c'est la marque « non enregistré », et tu as rafraîchi le navigateur avant que la modif atteigne le disque. Ctrl+S. Voilà.

Une version plus discrète du même problème, c'est d'enregistrer au mauvais endroit. Ton éditeur a « enregistré une copie » là où tu ne l'attendais pas, ou le fichier est ouvert deux fois, et le navigateur lit l'original que tu n'as jamais changé. Ce qui mène droit au point suivant.

tu édites un fichier et tu en regardes un autre

C'est le jumeau du précédent, et il se cache encore mieux. Le fichier est ouvert à deux endroits — deux dossiers différents, disons, ou une copie locale et une version en ligne — et tu édites soigneusement l'un pendant que le navigateur t'affiche l'autre.

Regarde la barre d'adresse. Un fichier local montre un chemin file:/// avec l'emplacement complet, et il doit correspondre au fichier que tu viens d'éditer, caractère pour caractère. Si tu travailles sur un site réellement servi — qui tourne sur localhost, ou déjà déployé quelque part — c'est encore une couche en plus. Rafraîchir le fichier local ne montrera pas les changements côté serveur, et rafraîchir l'URL en ligne ne montrera pas ceux d'en local. Détermine quelle copie tu es en train de changer, puis pointe le navigateur exactement sur cette copie-là.

le navigateur te montre la page d'hier

Les navigateurs gardent une copie locale des pages, des images et surtout du CSS, pour ne pas tout retélécharger à chaque visite. La plupart du temps, c'est un service. Pendant que tu édites, c'est ce qui te ment en pleine face — un simple rafraîchissement peut te refiler la version en cache au lieu de relire le fichier.

Le correctif, c'est le rechargement forcé, qui dit au navigateur de jeter sa copie et de tout rechercher. Ctrl+Maj+R sous Windows et Linux, Cmd+Maj+R sur Mac. Ctrl+F5 marche aussi sous Windows. Le CSS, c'est le piège vicieux ici — ton texte HTML se met à jour mais pas le style, parce que la feuille de style liée a été mise en cache de son côté. Un rechargement forcé nettoie les deux. Et s'il ne veut toujours pas lâcher, ouvre les DevTools, et une fois ouverts, fais un clic droit sur le bouton de rechargement et choisis « Vider le cache et effectuer une actualisation forcée ». Il ne reste plus rien de stocké pour la page.

ton fichier est devenu un .txt sans prévenir

Le correctif d'abord, le pourquoi ensuite. Règle le « Type » sur « Tous les fichiers » avant d'enregistrer, ou mets le nom entre guillemets — "index.html" — et active l'affichage des extensions pour voir la vraie terminaison. Ce qui te piège, c'est le réglage par défaut du Bloc-notes. Tu édites index.html, tu fais Enregistrer sous, et la boîte de dialogue suppose un document texte brut, donc elle colle .txt au bout et tu repars avec index.html.txt — que le navigateur lit comme du texte, pendant que le vrai .html juste à côté n'a pas bougé. Ça attrape plus de monde que tout le reste de cette liste, et je creuse le sujet dans comment modifier un fichier HTML.

tu ne l'as changé que dans les DevTools

Si tu passes ton temps à faire un clic droit sur la page, à choisir Inspecter, et à taper tes changements dans le panneau Éléments ou Styles — ces changements ne sont pas réels, pas dans le sens qui compte. Les retouches faites dans les DevTools vivent dans la mémoire de l'onglet. Elles sont parfaites pour essayer un truc sur la page en direct, mais elles ne touchent jamais le fichier sur le disque, et à la seconde où tu rafraîchis, elles s'envolent.

Alors bien sûr que la modif disparaît. Rafraîchir, c'est précisément ce qui la jette. Pour qu'elle tienne, copie ce qui a marché hors des DevTools et colle-le dans ton vrai fichier, puis enregistre. Les DevTools, c'est un brouillon sur lequel tu gribouilles pour voir le rendu. Le fichier, c'est le document. Un seul des deux garde ce que tu écris.

une autre règle gagne le bras de fer

Parfois la modif est vraiment dans le fichier, enregistrée, hors cache — et rien ne bouge quand même. Neuf fois sur dix, c'est du CSS qui écrase du CSS. Tu poses une couleur sur un paragraphe, mais un sélecteur plus spécifique plus bas dans la feuille de style, ou un style inline posé directement sur l'élément, ou un !important égaré de quelqu'un, te bat. La spécificité passe en premier — un sélecteur plus ciblé gagne peu importe où il se trouve dans le fichier, et ce n'est que lorsque deux règles sont aussi spécifiques l'une que l'autre que la plus tardive l'emporte. C'est la cascade qui fait son travail — juste pas celui que tu avais en tête.

Les DevTools rendent ça évident. Inspecte l'élément, ouvre le panneau Styles, et la règle qui a perdu est là, barrée d'un trait. Ce qui raye ta règle, c'est ce que tu dois changer, ou battre en écrivant plus spécifique. Ça vaut mieux que de deviner, à chaque fois.

comment un éditeur en direct évite presque tout ça

Reprends cette liste et regarde ce que la plupart des points ont en commun. L'enregistrement, le passage au navigateur, le rafraîchissement — ce petit écart entre éditer et voir, c'est là que le cache se glisse, que le mauvais fichier s'immisce, qu'un .txt se cache. Ferme l'écart et la plupart de ces galères ne peuvent tout simplement plus arriver.

C'est l'idée derrière l'outil que j'ai construit, HTML Tweak. Tu ouvres ton fichier .html et tu l'édites avec la page rendue et le code côte à côte et synchronisés — change l'un, l'autre suit, sans la danse enregistrer-rafraîchir au milieu. Aucune copie en cache à combattre, parce que tu regardes le fichier lui-même, et rien de ce que tu tapes ne reste coincé dans un panneau qui l'oublie au rechargement. Sous Chrome ou Edge, il enregistre directement dans le fichier ; les autres navigateurs téléchargent la copie modifiée. Il ne fera pas tourner un projet React ou Next multi-fichiers — il est fait pour finir une seule page — mais pour ça, toute la question du « pourquoi ça ne s'affiche pas » cesse à peu près de se poser.

Alors la prochaine fois que la page refuse de bouger, déroule la checklist depuis le début — c'est presque toujours le cache, et presque jamais tes yeux. Et si tu préfères ne pas jouer à la roulette enregistrer-rafraîchir du tout, HTML Tweak te montre simplement le fichier changer à mesure que tu tapes.