Que sont devenues les frames et les framesets ?

À l’époque du HTML 4, les frames et les framesets étaient une solution populaire pour découper une page web en plusieurs zones indépendantes : un menu à gauche, un contenu à droite, parfois un en-tête fixe. Cette technique donnait l’impression de « mini-fenêtres » imbriquées dans une même page, chacune chargeant son propre document.

Mais le web a évolué : navigation, accessibilité, SEO, sécurité et usages mobiles ont progressivement rendu ce modèle problématique. Dans cet article, on fait le point sur ce que sont devenues les frames et les framesets, pourquoi elles ont disparu des standards modernes, et quelles approches les remplacent aujourd’hui.

Comprendre les frames et les framesets

Les frames permettaient d’afficher plusieurs documents HTML simultanément dans la fenêtre du navigateur. Au lieu d’un document unique, on avait un conteneur qui répartissait l’espace en zones et chargeait un document dans chaque zone.

Le rôle de <frameset> était de définir la grille de découpage (lignes ou colonnes) via des attributs comme rows et cols. On décrivait ainsi une mise en page à base de documents séparés, chacun ayant sa propre URL et son propre contexte.

On utilisait souvent <frame> pour chaque zone et un <noframes> pour fournir une alternative aux navigateurs ne supportant pas les frames. Cette architecture était avant tout une solution de “layout” avant l’arrivée de CSS moderne.

Pourquoi les frames ont perdu la bataille

Le principal problème historique des frames concernait la navigation : l’URL visible ne reflétait pas toujours l’état réel de l’interface (quel contenu est chargé dans quelle frame). Résultat : un lien partagé ou un favori pouvait rouvrir la structure sans le bon contenu, ou ouvrir seulement une frame isolée.

Les boutons “Précédent/Suivant” du navigateur se comportaient parfois de manière inattendue. Selon la façon dont les frames étaient mises à jour, l’historique devenait confus, ce qui dégradait fortement l’expérience utilisateur.

Enfin, les frames posaient des difficultés d’impression, de responsive design et de cohérence visuelle. La mise en page était rigide, et l’approche “plusieurs documents pour une seule page” entrait en conflit avec les pratiques modernes centrées sur des interfaces adaptatives.

Impact sur le SEO et l’indexation

Les moteurs de recherche ont longtemps eu du mal à interpréter correctement un site en frames. Ils pouvaient indexer la page de contenu chargée dans une frame sans le menu ni le contexte, ce qui amenait des pages “orphelines” dans les résultats.

La structure fragmentée compliquait aussi la distribution de la popularité (liens entrants). Selon l’architecture, les liens pouvaient pointer vers des documents internes plutôt que vers une page “composée”, rendant le maillage moins maîtrisable.

De plus, la sémantique globale d’une page (titre, métadonnées, hiérarchie de contenu) se retrouvait dispersée. Or, les stratégies SEO modernes privilégient des pages cohérentes, accessibles et clairement structurées.

Accessibilité et ergonomie : un héritage délicat

Les technologies d’assistance (lecteurs d’écran, navigation clavier) pouvaient rencontrer des obstacles : changement de focus entre frames, annonces confuses, difficulté à comprendre la relation entre les zones. Une page fragmentée en plusieurs documents est plus complexe à parcourir.

La gestion des titres de pages, des repères et des rôles ARIA devenait aussi plus difficile. Chaque frame étant un document distinct, l’expérience dépendait fortement de la qualité d’implémentation dans chaque partie.

Les bonnes pratiques actuelles insistent sur une structure unique et sémantique (er, nav, main, footer) et une navigation stable. Les frames allaient à l’encontre de cette simplification bénéfique à l’accessibilité.

Statut dans HTML5 : obsolescence et suppression

Avec HTML5, <frameset> et <frame> ont été rendus obsolètes et retirés des spécifications modernes. Concrètement, ils ne font plus partie du langage HTML standard tel qu’il est recommandé de l’utiliser aujourd’hui.

Les navigateurs peuvent encore afficher certains anciens sites par compatibilité, mais ce support n’est pas un encouragement à les utiliser. Dans un projet actuel, choisir les frames revient à s’écarter volontairement des standards et à accumuler de la dette technique.

À noter qu’il existe toujours <iframe>, qui est différent : il permet d’intégrer une page dans une autre, mais sans l’ancienne logique de découpage structurel de l’écran par framesets. Son usage moderne est plus encadré (sécurité, sandbox, politiques cross-origin).

Les remplaçants modernes côté mise en page (CSS3)

La grande bascule s’est faite vers CSS : la mise en page ne dépend plus de documents séparés, mais d’un seul document structuré. On remplace les anciennes grilles de framesets par des conteneurs sémantiques et des règles CSS.

Flexbox a simplifié la création de colonnes et de barres latérales adaptatives. Un menu à gauche et un contenu à droite se font désormais sans hack, avec un alignement et une réactivité excellents sur mobile.

CSS Grid est l’équivalent moderne le plus proche du “découpage” des framesets, mais de manière standard, responsive et accessible. On définit des zones de grille (er, nav, main, aside) sans multiplier les documents ni casser la navigation.

Les remplaçants modernes côté architecture (templating et composants)

Ce que beaucoup cherchaient avec les frames (menu constant + contenu changeant) est aujourd’hui géré par des templates côté serveur (PHP, Symfony, Laravel, Django, etc.) ou par des systèmes de rendu (CMS). On réutilise un layout commun sans séparer l’interface en documents indépendants.

Côté front-end, les frameworks et bibliothèques (React, Vue, Svelte, Angular) proposent des composants. Le menu, l’en-tête et le contenu sont assemblés dans une application unique, avec un routage propre et une URL qui reflète l’état.

Les SPA (single-page applications) et les approches hybrides (SSR/SSG) reproduisent l’idée de contenu qui se met à jour sans recharger toute la page, mais avec une gestion correcte de l’historique, du SEO (selon la stratégie) et de l’accessibilité.

Cas où l’iframe reste utile (sans retomber dans les framesets)

Contrairement aux framesets, l’iframe est encore utilisé pour intégrer du contenu externe : vidéos, cartes, formulaires tiers, widgets, ou encore prévisualisation de documents. Il répond à un besoin d’intégration, pas de structuration globale de site.

On doit toutefois prendre en compte la sécurité (attribut sandbox, permissions, politiques d’origine) et la performance. Une iframe charge une page complète, ce qui peut être coûteux si on en abuse.

Pour des interfaces internes, on privilégie généralement des composants et du CSS. L’iframe devient un outil ponctuel, utile surtout quand l’isolation est recherchée (contenu tiers, contraintes d’hébergement, séparation stricte).

En résumé, les frames et framesets n’ont pas “disparu” par effet de mode, mais parce qu’ils contredisaient des besoins devenus essentiels : URLs fiables, navigation cohérente, accessibilité, SEO et adaptabilité mobile. HTML5 a acté cette évolution en les rendant obsolètes.

Le web moderne propose mieux : CSS Grid et Flexbox pour la mise en page, des templates et des composants pour la réutilisation, et un routage propre pour l’état et l’URL. Si l’on retient une leçon, c’est que la structure et la présentation doivent rester standards, sémantiques et maintenables, plutôt que fragmentées en cadres indépendants.