Récemment, j’ai travaillé sur un projet de scraping visant à centraliser des offres d’alternance. Pour cela, j’ai analysé le code HTML de plusieurs sites d’emploi… et j’ai fait quelques découvertes surprenantes.

Même sur des plateformes réputées, les bonnes pratiques HTML sont parfois mises de côté. Peut-être y a-t-il une raison qui m’échappe encore en tant qu’apprenti développeur, mais voici quelques perles que j’ai rencontrées 👀 :

1️⃣ Un enchaînement sans fin de div, au détriment des balises sémantiques comme main ou section.

❌ Pourquoi c’est une mauvaise pratique ?

L’utilisation de balises sémantiques améliore le référencement naturel (SEO), facilite l’accessibilité pour les lecteurs d’écran et permet une meilleure compréhension du document par les développeurs et navigateurs. Un HTML bien structuré est aussi plus facile à maintenir.

⚖️ Mais alors, pourquoi autant de div ?

Il se peut que le projet ait été conçu avec un framework front-end où la sémantique est sacrifiée au profit de composants génériques (coucou React et Vue ! 👀). Parfois, l’usage massif des div vient aussi de systèmes de design complexes où les styles et animations sont priorisés sur la structure HTML.

2️⃣ Des p encapsulés dans des h1, une aberration pour l’accessibilité et le SEO.

❌ Pourquoi c’est une mauvaise pratique ?

Les balises h1 sont censées représenter les titres principaux d’une page. Y mettre un paragraphe à l’intérieur casse la hiérarchie du document et perturbe les lecteurs d’écran, ce qui nuit à l’accessibilité. De plus, cela envoie de mauvais signaux aux moteurs de recherche, impactant négativement le SEO.

⚖️ Quelle pourrait être la justification ?

Cela pourrait être un oubli ou une mauvaise habitude. Mais parfois, certains CMS ou éditeurs WYSIWYG (comme WordPress) génèrent ce type d’erreurs automatiquement, et les développeurs n’ont pas toujours la main pour les corriger facilement.

3️⃣ Une div (qui aurait pu être un article) contenant deux headers, l’un avec uniquement une image, l’autre avec un titre.

❌ Pourquoi c’est une mauvaise pratique ?

Un document structuré devrait avoir un seul header par bloc logique (page ou article). Ici, deux headers créent une confusion sémantique. L’image seule dans un header n’a pas vraiment de sens, et cela complique la compréhension pour les moteurs de recherche et outils d’accessibilité.

⚖️ Pourquoi pourrait-on faire ce choix ?

Cela pourrait être lié à une logique CSS : peut-être que le design impose un découpage précis et qu’il était plus simple d’utiliser un deuxième header plutôt que de jouer avec des classes et des styles complexes. Une autre possibilité est que l’outil utilisé pour générer le HTML force cette structure.

4️⃣ Un festival de div imbriquées pour créer… une simple carte ! 🤯

❌ Pourquoi c’est une mauvaise pratique ?

Trop de div imbriquées compliquent la lisibilité du code, alourdissent le DOM et impactent potentiellement les performances du navigateur. Un balisage plus propre avec article, header, footer, et des classes bien pensées suffirait souvent à obtenir le même rendu.

⚖️ Pourquoi autant de div alors ?

Là encore, un framework front-end ou un constructeur visuel pourrait être responsable. Certains systèmes génèrent automatiquement des conteneurs superflus pour gérer les marges, paddings et alignements sans nécessiter de CSS personnalisé. Et puis, il faut l’admettre : certains devs ont juste pris l’habitude de tout mettre en div sans se poser de questions. 😅

Et un mystérieux turbo-frame, ça vous parle ?

L’ensemble du code était encapsulé dans un turbo-frame. Si vous ne connaissez pas, Turbo (de Hotwire) est une technologie qui permet d’accélérer le rendu des pages en ne mettant à jour que certaines parties du DOM côté client.

🔹 Pourquoi c’est intéressant ? Cela évite des rechargements complets et améliore la rapidité de l’application.

🔹 Pourquoi c’est perturbant ? Quand on scrape du HTML, on s’attend à une structure classique… et tomber sur du Turbo peut rendre l’analyse plus complexe, car ce n’est pas du simple HTML mais une couche d’interactivité supplémentaire.

Conclusion : maladresse ou choix technique ?

Si ces structures paraissent aberrantes du point de vue des bonnes pratiques, elles ne sont pas forcément dues à l’incompétence des développeurs. Entre frameworks, CMS, générateurs automatiques et exigences de design, il y a souvent des raisons derrière ces choix… même si, parfois, un bon refactoring ne ferait pas de mal.

📌 Petit point sur les WYSIWYG

Un WYSIWYG (What You See Is What You Get, soit "ce que vous voyez est ce que vous obtenez") est un éditeur qui permet de créer et de modifier du contenu (texte, pages web, emails, etc.) en affichant directement le rendu final, sans avoir besoin d’écrire du code.

👉 Exemples d'éditeurs WYSIWYG :

  • TinyMCE et CKEditor : souvent utilisés pour les éditeurs de texte enrichi sur les CMS.
  • WordPress (Gutenberg) : permet de créer des pages en glissant-déposant des blocs sans toucher au code HTML.
  • Webflow, Wix, Squarespace : des outils permettant de créer des sites sans coder.

🔹 Et vous, avez-vous déjà rencontré des aberrations HTML en analysant un site ?

Partagez vos expériences en commentaire ! 😊