WYSIWYG ou éditeur de code pour modifier du HTML

Le petit « ou » dans cette question fait déjà fausse route. Il installe un ring, et il n'y a pas de combat. Ni l'éditeur visuel ni l'éditeur de code ne l'emporte pour de bon — ça se décide sur le changement que tu es en train de faire. Corriger un titre, un lien, une photo ? L'éditeur visuel va plus vite. Remanier la structure, poser un attribut précis, comprendre comment les balises s'emboîtent ? C'est du code. Et l'outil vers lequel je tends vraiment la main te donne les deux, côte à côte, et les garde synchronisés.

Alors arrêtons de les traiter en adversaires, et rangeons ça par le travail à faire.

deux outils qui répondent à deux questions différentes

Un éditeur WYSIWYG — « what you see is what you get », ce que tu vois est ce que tu obtiens — te montre la page rendue et te laisse cliquer et taper dessus. Tu changes les mots, tu déposes une image, tu reteintes un bouton, et le balisage se met à jour dessous sans que tu lises une seule balise. Tu édites le résultat.

Un éditeur de code te montre la source. Chaque <div>, chaque classe, chaque attribut, posé là en clair, à changer à la main. Tu édites les instructions qui produisent le résultat.

C'est toute la ligne de partage. L'un te laisse toucher la page ; l'autre, le code qui fabrique la page. Demander « lequel est meilleur », c'est demander si une page vaut mieux que le code derrière — ça n'a pas de sens. Il te faut celui qui colle au changement que tu as en tête, là, maintenant.

Si tu veux la carte plus large des façons d'ouvrir et de changer un fichier, je l'ai dépliée dans comment modifier un fichier HTML. Ici, on ne prend qu'un embranchement de cette route : visuel contre code.

à chaque changement son outil

Voici comment je trierais les tâches courantes — pas selon l'outil « le plus puissant », mais selon celui qui t'y amène avec le moins de friction.

Le changement que tu fais	Prends	Pourquoi
Corriger un mot, un lien ou une image	Visuel / WYSIWYG	Tu vois le résultat à l'instant où tu le fais, sans chasse aux balises
Remanier la structure — imbriquer, réordonner, ajouter des sections	Éditeur de code	Il faut voir et déplacer les balises elles-mêmes
Poser un attribut précis (un aria-label, une valeur data-, une largeur exacte)	Éditeur de code	Un clic ne peut pas attraper ce qui n'a aucune prise visible sur la page
Apprendre comment le HTML fonctionne vraiment	Éditeur de code	Le but, c'est de lire et d'écrire les balises, pas de les cacher
Confier la page à quelqu'un qui ne code pas pour changer le texte	Mode visuel texte seul	Il verrouille la mise en page pour qu'un changement de mots ne casse pas le design
Retrouver le code derrière ce que tu vois	Éditeur synchronisé, deux sens	Clique l'élément, il te saute à la ligne correspondante

La plupart des disputes visuel-contre-code, ce sont en fait deux personnes qui pensent à deux lignes différentes de ce tableau et se parlent à côté.

rendons justice à l'éditeur de code

Je fabrique un outil visuel, alors autant être honnête avec l'autre camp, parce qu'il le mérite.

Pour tout ce qui est structurel, le code gagne, et pas de peu. Faire passer une section au-dessus d'une autre, envelopper trois éléments dans un nouveau conteneur, remettre l'indentation d'aplomb pour enfin lire le truc — tu veux les balises sous les yeux. Un éditeur visuel peut te résister là-dessus. Tu cliques, et tu n'es jamais tout à fait sûr de l'élément que tu as attrapé.

Les attributs précis, même histoire. Il n'y a aucun bouton sur la page pour un aria-label ou un data-id, donc rien à cliquer. En code, tu le tapes, point.

Et si le but, c'est d'apprendre le HTML, l'éditeur visuel est la mauvaise salle de classe. Il est fait pour cacher les balises. Apprendre, c'est les voir, les casser, les réparer. Un bac à sable de code comme ceux que j'ai parcourus dans les meilleurs éditeurs HTML gratuits bat n'importe quel pointer-cliquer pour ça.

Alors non, je ne suis pas là pour te dire que les éditeurs de code ont fait leur temps. Ils sont le bon outil pour une grosse part du vrai travail.

tu voudras souvent changer de crémerie en cours de route

Voilà ce que le « ou » cache. La plupart des vraies retouches ne sont ni l'un ni l'autre. Elles sont les deux, dans les mêmes cinq minutes.

Disons que tu finalises une page pondue par une IA. Tu retapes le titre — visuel, réglé en deux secondes. Puis tu repères que le bouton pointe au mauvais endroit, et le lien n'est pas du texte visible, c'est un href enfoui dans la balise, alors là tu veux du code. Puis tu veux regarder la page à nouveau pour vérifier qu'elle tient encore. Visuel, code, visuel, le tout dans une seule petite tâche.

Si tes deux outils sont séparés — un navigateur pour regarder, un éditeur de texte pour la source — tu passes la retouche à enregistrer, alt-tabber, rafraîchir. Ce coût de bascule est minuscule à chaque fois, et énorme sur un après-midi. C'est la vraie raison pour laquelle « lequel est meilleur » est la mauvaise question. Tu n'en veux pas un des deux. Tu veux arrêter de payer le péage pour passer de l'un à l'autre.

la version où tu n'as pas à choisir

C'est le manque pour lequel j'ai construit HTML Tweak. Il pose la page visuelle et le code l'un à côté de l'autre, synchronisés — change la page, le code se met à jour ; change le code, la page se met à jour. Clique une chose que tu vois, il te localise le code correspondant, ce qui tue l'essentiel de la chasse aux balises.

Pour le cas du non-codeur, il y a un mode texte seul qui verrouille structure et styles, pour qu'un collègue réécrive la copie sans pouvoir, physiquement, déplacer la mise en page. Les modes « demander d'abord » et complet sont là pour quand, justement, tu veux aller plus loin.

Et les bords. Il ouvre un seul fichier .html — pas un gestionnaire pour un projet React ou Next à plusieurs fichiers. Il tourne gratuitement dans le navigateur, et aussi comme un fichier hors ligne unique que tu gardes ; le premier chargement demande internet, ensuite il se met en cache et marche sans. Sous Chrome ou Edge, il enregistre droit dans ton fichier ; les autres navigateurs te tendent une copie téléchargée. Pas d'inscription, dans les deux cas.

Il ne remplace pas un éditeur de code pour bâtir un site entier. Il remplace l'alt-tab quand tu finis une page.

les erreurs que je vois le plus

Le gâchis remonte presque toujours à un seul réflexe — traiter « visuel ou code » comme un choix qu'on fait une fois, pour tout le boulot, au lieu de le refaire à neuf pour chaque changement. Ça sort de trois façons.

Choisir un couloir pour toute la tâche. Tu décides « c'est un boulot de code » et tu fais passer un changement de texte de cinq secondes à travers des balises brutes, ou tu décides « c'est un boulot visuel » et ensuite tu ne peux pas poser le seul attribut qui n'a pas de prise. La tâche n'a pas de couloir. Chaque changement, si.

Lancer du WYSIWYG sur une page dont la mise en page compte, et la regarder dériver. Certains éditeurs visuels réécrivent le balisage au fil de l'eau, et une retouche de texte pousse l'espacement d'un cran. Si préserver le design est le but, tu veux une édition à structure verrouillée, pas une foire d'empoigne.

Attraper le mauvais outil pour apprendre. Si tu cherches à comprendre le HTML, ne l'enterre pas sous un éditeur visuel — lis les balises. Et l'inverse compte aussi. Broyer du code pour un boulot qu'un clic finirait gaspille tout autant ta journée, dans l'autre sens.

Alors voici un petit défi. La prochaine fois que tu te surprends à peser le visuel contre le code, refuse la question. Ouvre le fichier dans HTML Tweak, garde le code à côté de la page, et bascule de l'un à l'autre au gré de chaque changement.