Le Webdesign res­pon­sive désigne une approche con­sis­tant à concevoir un site Web réactif capable de s’adapter au­to­ma­ti­que­ment à dif­fé­rents terminaux. Le terme design responsif est apparu avec le dé­ve­lop­pe­ment de l’Internet sur mobile et s’est depuis imposé comme une méthode standard en design Web.

Résumé

{“message”: “Le Res­pon­sive Web Design permet à un site de s’adapter au­to­ma­ti­que­ment à la diversité des terminaux.

  • Utilise CSS Grid, Flexbox et les Media Queries pour des mises en page flexibles.
  • Optimise les images via srcset et <picture> pour améliorer les per­for­mances.
  • Garantit une na­vi­ga­tion tactile et une ty­po­gra­phie fluide avec clamp().
  • Améliore l’ex­pé­rience uti­li­sa­teur (UX) et le SEO via les Core Web Vitals.“}

Qu’est-ce que le Webdesign res­pon­sive et comment a-t-il évolué ?

Avant l’essor du Web mobile, le paysage des terminaux connectés à Internet était re­la­ti­ve­ment homogène : il existait prin­ci­pa­le­ment des or­di­na­teurs de bureau ou portables, avec des dis­po­si­tifs d’entrée et de sortie si­mi­laires. Ces appareils étaient équipés d’un clavier et d’une souris ou d’un trackpad, ainsi que d’un écran d’une largeur d’environ 1 000 à 2 000 pixels.

À cette époque, concevoir un site Web réactif qui s’affichait cor­rec­te­ment sur la majorité des appareils ne demandait que peu d’efforts. Une solution simple con­sis­tait à limiter la largeur des pages au plus petit dé­no­mi­na­teur commun. Une pratique répandue était de proposer des pages larges de 800 pixels, centrées ou alignées à gauche. Sur des écrans plus grands, cela créait davantage d’espace blanc, mais ga­ran­tis­sait une bonne li­si­bi­lité sur tous les appareils.

Avec le dé­ve­lop­pe­ment des appareils mobiles, le paysage des terminaux connectés à Internet s’est fortement di­ver­si­fié. Alors que les écrans étaient au­pa­ra­vant assez si­mi­laires, ceux des tech­no­lo­gies actuelles comme les smart­phones ou les tablettes pré­sen­tent des ca­rac­té­ris­tiques très variées. Les appareils modernes couvrent désormais des largeurs d’écran allant de 320 pixels à bien plus de 4 000 pixels.

Au-delà des di­men­sions en pixels, d’autres facteurs entrent en jeu, comme la ré­so­lu­tion physique des écrans (Pixels Per Inch, PPI), les écrans haute densité comme les écrans Retina, ainsi que le Device Pixel Ratio (DPR). Par ailleurs, la na­vi­ga­tion ne se fait plus uni­que­ment à la souris, mais aussi via des in­ter­faces tactiles.

Plus petit écran Plus grand écran Facteur
Avant le Web mobile env. 1 000 pixels env. 2 000 pixels env. 2
Après le Web mobile env. 320 pixels > 4 000 pixels > 10

Un site Web réactif s’adapte à l’espace dis­po­nible à l’écran, souvent appelé « screen real estate ». L’objectif est de garantir une apparence es­thé­tique sur tous les appareils tout en offrant une User Ex­pe­rience (UX) optimale.

Le Webdesign res­pon­sive regroupe un ensemble de tech­niques et d’approches per­met­tant de créer un site Web en­tiè­re­ment adaptatif. Il s’agit notamment de :

Au-delà des smart­phones et tablettes clas­siques, de nouveaux formats d’appareils, comme les modèles pliables ou à double écran, gagnent en im­por­tance. Ces dis­po­si­tifs peuvent modifier dy­na­mi­que­ment leur surface d’affichage, par exemple lors du dépliage ou du passage à une vue scindée.

Pour le design responsif, cela implique que les mises en page doivent non seulement s’adapter à dif­fé­rentes tailles d’écran, mais aussi réagir à des chan­ge­ments dy­na­miques pendant l’uti­li­sa­tion. Un site Web réactif moderne doit donc être suf­fi­sam­ment flexible pour garantir une ex­pé­rience cohérente et con­vi­viale, même lorsque le format d’affichage évolue.

Créer un site Internet
Votre site en un éclair grâce à l'in­tel­li­gence ar­ti­fi­cielle
  • Éditeur de site intuitif avec fonctions d'IA
  • Gé­né­ra­teur d'images et de textes avec op­ti­mi­sa­tion SEO
  • Domaine, SSL et boîte email inclus

Pourquoi un site Web doit-il adopter un design responsif ?

Le dé­ve­lop­pe­ment d’un site Web réactif présente de nombreux avantages. La User Ex­pe­rience est au cœur de cette approche. Il est certes possible d’offrir une bonne ex­pé­rience uti­li­sa­teur sans design responsif, mais cela implique de créer une version mobile distincte ou d’utiliser Ja­vaS­cript. Ces solutions sont gé­né­ra­le­ment plus complexes et né­ces­si­tent davantage de main­te­nance que le Webdesign res­pon­sive basé sur le CSS.

Webdesign res­pon­sive pour un design optimal

Le design d’un site Web influence fortement la manière dont les visiteurs per­çoi­vent les contenus. Un design réussi reflète l’identité de l’or­ga­ni­sa­tion derrière le site Web et contribue à fidéliser les uti­li­sa­teurs. L’objectif est de proposer une ex­pé­rience agréable et cohérente sur tous les appareils. Voici deux exemples concrets :

  • Un titre peut occuper toute la largeur sur un smart­phone, mais paraître trop discret sur un écran desktop. Sur les grands écrans, le titre doit être affiché plus grand pour capter l’attention.
  • Sur un blog, une barre latérale affiche des liens vers d’autres contenus. Sur desktop, elle améliore la li­si­bi­lité en struc­tu­rant la page. Sur mobile, elle occupe trop d’espace. La mise en page (layout) doit donc être adaptée pour afficher ces éléments sous l’article.

Webdesign res­pon­sive pour une User Ex­pe­rience (UX) optimale

Sans design responsif, un site Web s’affiche sur mobile comme sur desktop, mais en version réduite. Les uti­li­sa­teurs doivent alors zoomer et naviguer ma­nuel­le­ment, ce qui nuit à l’ex­pé­rience. Une adap­ta­tion est donc in­dis­pen­sable :

  • Un bouton cliqué à la souris sur desktop doit être fa­ci­le­ment uti­li­sable au doigt sur mobile. Il doit donc être plus grand et mieux espacé.
  • Un for­mu­laire avec des es­pa­ce­ments im­por­tants peut être lisible sur grand écran, mais poser problème sur mobile. Sur un écran de 320 pixels, des marges et paddings trop im­por­tants réduisent fortement l’espace dis­po­nible. Les es­pa­ce­ments doivent donc être ajustés pour optimiser l’affichage sur les petits écrans.

Le design responsif permet ainsi d’adapter au­to­ma­ti­que­ment chaque élément à l’appareil utilisé et de garantir une ex­pé­rience fluide sur tout type de site Web réactif.

Site Web non responsif : quelles peuvent être les con­sé­quences ?

Une part im­por­tante des uti­li­sa­teurs accède aujourd’hui aux contenus du Web via des appareils mobiles. Lorsqu’un site Web n’est pas conçu avec un design responsif, cela peut entraîner plusieurs in­con­vé­nients majeurs :

  • Mauvais taux de con­ver­sion et taux de rebond élevé, liés à un design inadapté et à une User Ex­pe­rience dégradée
  • Mauvais clas­se­ment dans les moteurs de recherche, car Google prend en compte la com­pa­ti­bi­lité mobile, les Core Web Vitals et la taille des zones tactiles
  • Per­for­mances dégradées, dues au char­ge­ment de res­sources non op­ti­mi­sées, me­su­rables notamment avec des in­di­ca­teurs comme le Largest Con­tent­ful Paint (LCP) et l’In­te­rac­tion to Next Paint (INP)
Conseil

Utilisez des outils de test de Webdesign res­pon­sive pour vérifier la com­pa­ti­bi­lité mobile de votre site Web.

Core Web Vitals : in­di­ca­teurs de l’User Ex­pe­rience

Pour évaluer de manière objective l’ex­pé­rience réelle des uti­li­sa­teurs, Google s’appuie sur les Core Web Vitals. Il s’agit de mesures de per­for­mance stan­dar­di­sées qui analysent la vitesse de char­ge­ment, la stabilité du layout et la réac­ti­vité d’un site Web face aux in­te­rac­tions. Les prin­ci­paux in­di­ca­teurs sont les suivants :

  • Largest Con­tent­ful Paint (LCP) : mesure le temps né­ces­saire pour afficher le plus grand élément visible à l’écran (valeur cible ≤ 2,5 s)
  • In­te­rac­tion to Next Paint (INP) : évalue la réac­ti­vité d’une page lors des in­te­rac­tions des uti­li­sa­teurs (valeur cible ≤ 200 ms)
  • Cu­mu­la­tive Layout Shift (CLS) : mesure la stabilité visuelle en détectant les dé­pla­ce­ments inat­ten­dus de contenu pendant le char­ge­ment (valeur cible ≤ 0,1)

Un site Web réactif conçu avec un Webdesign res­pon­sive obtient gé­né­ra­le­ment de meilleurs résultats pour ces in­di­ca­teurs. À l’inverse, un design responsif mal im­plé­menté ou absent peut entraîner des per­for­mances dégradées, notamment en raison d’images trop lourdes, de contenus chargés tar­di­ve­ment ou de mises en page mal adaptées aux appareils mobiles.

Outils pour analyser les Core Web Vitals

Les Core Web Vitals peuvent être mesurées à l’aide de dif­fé­rents outils. Les suivants sont par­ti­cu­liè­re­ment répandus :

  • Google PageSpeed Insights : analyse des pages in­di­vi­duelles et com­bi­nai­son de données réelles d’uti­li­sa­teurs avec des données de la­bo­ra­toire
  • Google Ligh­thouse : intégré aux outils de dé­ve­lop­pe­ment de Chrome, adapté aux analyses dé­tail­lées des per­for­mances
  • Google Search Console : fournit des données agrégées pour l’ensemble d’un site Web et identifie les URL pro­blé­ma­tiques

Ces outils per­met­tent d’iden­ti­fier pré­ci­sé­ment les points faibles et de mesurer con­crè­te­ment l’impact du design responsif sur l’ex­pé­rience uti­li­sa­teur d’un site Web réactif.

Quels aspects du dé­ve­lop­pe­ment Web sont in­fluen­cés par le design responsif ?

Le design responsif repose sur dif­fé­rentes approches et tech­no­lo­gies. En pratique, il existe plusieurs solutions pour un même scénario, et les méthodes évoluent en per­ma­nence avec les standards du Web.

Mise en page res­pon­sive

La con­cep­tion de layouts pour les sites Web est un enjeu central depuis les débuts du World Wide Web. HTML propose dif­fé­rents types d’éléments : block, inline et inline-block. Les éléments de type block occupent toute la largeur dis­po­nible et s’empilent ver­ti­ca­le­ment. Les éléments inline, quant à eux, n’occupent que l’espace né­ces­saire à leur contenu et s’affichent sur une même ligne.

Voici un aperçu des types d’éléments les plus im­por­tants pour le Webdesign res­pon­sive :

Type d’élément Largeur Flux d’éléments
block Largeur totale dis­po­nible ou largeur attribuée Colonne
inline Largeur des éléments contenus Ligne
inline-block Largeur des éléments contenus ou largeur attribuée Ligne
flex Largeur totale dis­po­nible Ligne ou colonne
grid Largeur totale dis­po­nible Layout complexe

Pour disposer des contenus côte à côte, on utilisait autrefois des mises en page basées sur des tableaux ou sur des flottants (float). Ces approches sont aujourd’hui con­si­dé­rées comme obsolètes. Les layouts modernes en design responsif reposent presque ex­clu­si­ve­ment sur CSS Flexbox et CSS Grid. Flexbox est par­ti­cu­liè­re­ment adapté aux layouts uni­di­men­sion­nels, comme les listes ho­ri­zon­tales ou ver­ti­cales, tandis que CSS Grid est utilisé pour des struc­tures de page complexes et bi­di­men­sion­nelles.

Un exemple concret : prenons l’exemple d’une page avec quatre éléments d’aperçu pour des articles de blog. Chaque élément contient une image, un titre, un teaser et un bouton « Lire la suite ». Avec Flexbox, il est facile de créer une mise en page res­pon­sive adaptée à chaque écran :

  • Affichage sur grand écran : les éléments sont affichés côte à côte sur une seule ligne. Chacun occupe 25 % de l’espace dis­po­nible.
  • Affichage sur écran moyen : deux éléments sont affichés par ligne. Chacun occupe 50 % de l’espace dis­po­nible.
  • Affichage sur petit écran : les éléments sont affichés les uns sous les autres sur une seule colonne. Chacun occupe 100 % de l’espace dis­po­nible.

Comment créer un layout responsif avec CSS Grid et Media Queries ?

Les mises en page modernes en design responsif peuvent aujourd’hui être mises en œuvre, dans de nombreux cas, sans recourir à un framework CSS sup­plé­men­taire. Des modules natifs comme CSS Grid et Flexbox sont largement pris en charge et per­met­tent de créer des struc­tures flexibles et faciles à maintenir. Un élément central dans ce contexte est l’uti­li­sa­tion des CSS Media Queries. Elles per­met­tent d’appliquer des règles CSS en fonction des ca­rac­té­ris­tiques du pé­ri­phé­rique, notamment la largeur du viewport. Les Media Queries dé­fi­nis­sent ainsi dans quelles con­di­tions un layout spé­ci­fique doit s’appliquer, par exemple à partir d’une certaine taille d’écran ou selon l’orien­ta­tion de l’appareil.

Prenons l’exemple d’une page avec quatre éléments d’aperçu pour des articles de blog. Chaque élément comprend une image, un titre, un court texte et un lien vers l’article complet. L’objectif est d’adapter le nombre d’éléments affichés côte à côte en fonction de la largeur d’écran dis­po­nible.

Structure HTML :

<div class="blog-grid">
    <article class="blog-preview">…</article>
    <article class="blog-preview">…</article>
    <article class="blog-preview">…</article>
    <article class="blog-preview">…</article>
</div>
html

Im­plé­men­ta­tion CSS avec CSS Grid :

.blog-grid {
    display: grid;
    grid-template-columns: 1fr;
    gap: 1.5rem;
}
/ *écrans moyens* /
@media screen and (min-width: 600px) {
    .blog-grid {
        grid-template-columns: repeat(2, 1fr);
    }
}
/ *grands écrans* /
@media screen and (min-width: 1024px) {
    .blog-grid {
        grid-template-columns: repeat(4, 1fr);
    }
}
css

Sans Media Queries, une mise en page simple pour les petits écrans est d’abord définie. À partir d’une largeur de 600 pixels, deux colonnes sont affichées, et à partir de 1 024 pixels, quatre. Cette approche suit le principe mobile first et garantit que les contenus restent lisibles sur les petits écrans tout en étant optimisés pour les écrans plus grands. Les Media Queries réa­gis­sent au viewport, c’est-à-dire à la taille de la fenêtre du na­vi­ga­teur ou de l’écran.

Que sont les Container Queries en design responsif ?

Alors que les Media Queries réa­gis­sent à la taille du viewport, les CSS Container Queries in­ter­vien­nent à un autre niveau. Elles per­met­tent d’appliquer des styles en fonction de la taille d’un conteneur parent, in­dé­pen­dam­ment de la taille réelle de l’écran. Les éléments ne réa­gis­sent donc plus à l’ensemble de la fenêtre du na­vi­ga­teur, mais à l’espace qui leur est ef­fec­ti­ve­ment alloué dans le layout.

Cela est par­ti­cu­liè­re­ment utile pour un Webdesign res­pon­sive modulaire, dans lequel des com­po­sants sont utilisés plusieurs fois dans des contextes dif­fé­rents, par exemple à la fois dans une barre latérale étroite et dans une zone prin­ci­pale plus large. Avec les seules Media Queries, ce type de scénario reste limité.

Un exemple typique est un élément d’aperçu d’article. Dans une sidebar étroite, l’image et le texte doivent être affichés l’un sous l’autre. Dans la zone prin­ci­pale, où l’espace est plus important, ils peuvent être placés côte à côte. Les Container Queries per­met­tent pré­ci­sé­ment cette adap­ta­tion con­tex­tuelle, sans avoir à définir de break­points sup­plé­men­taires pour chaque variante de layout. Le conteneur parent est d’abord défini comme « Query Container » :

.preview-container {
    container-type: inline-size;
}
css

Le composant d’aperçu elle-même reçoit une mise en page de base simple, optimisée pour un espace réduit :

.article-preview {
    display: flex;
    flex-direction: column;
    gap: 1rem;
}
css

Ensuite, une Container Query définit que la mise en page change dès que le conteneur dépasse une certaine largeur :

@container (min-width: 500px) {
    .article-preview {
        flex-direction: row;
    }
}
css

La com­po­sante s’adapte ainsi au­to­ma­ti­que­ment à l’espace dis­po­nible dans son conteneur. Qu’elle se trouve dans une sidebar ou dans la zone prin­ci­pale n’a plus d’im­por­tance. Seule compte la largeur du conteneur, et non celle du viewport. Les Container Queries sou­tien­nent ainsi une approche orientée com­po­sants en design responsif et com­plè­tent ef­fi­ca­ce­ment les Media Queries clas­siques. Dans les projets modernes, les deux tech­niques sont souvent combinées, afin de gérer à la fois les chan­ge­ments de layout globaux et les ajus­te­ments précis de com­po­sants pour un Webdesign res­pon­sive per­for­mant.

Ty­po­gra­phie res­pon­sive et contenus textuels

Pour garantir une UX optimale, la taille de police des contenus textuels d’un site Web doit s’adapter à la surface d’affichage dis­po­nible et aux dif­fé­rents contextes d’uti­li­sa­tion. Outre la li­si­bi­lité, des critères comme la sca­la­bi­lité, l’ac­ces­si­bi­lité et la stabilité du layout jouent un rôle essentiel. Dans ce cadre, dif­fé­rentes tech­niques ty­po­gra­phiques sont utilisées dans le Webdesign res­pon­sive.

Comme base, on utilise l’unité CSS rem (« root element »), qui permet de définir la taille de police d’un élément par rapport à l’élément racine HTML. En ajustant ensuite la taille de police de cet élément racine via des break­points CSS, il devient possible de mettre à l’échelle l’ensemble des polices de manière cohérente sur un site Web réactif.

html {
    font-size: 16px;
}
h1 {
    font-size: 3rem;
}
css

Cette approche peut être ju­di­cieu­se­ment combinée avec des Media Queries dans une stratégie mobile first, afin d’augmenter mo­dé­ré­ment la taille de police de base sur les écrans plus grands :

@media screen and (min-width: 30em) {
    html {
        font-size: 18px;
    }
}
css

Dans les mises en page modernes, on utilise de plus en plus une ty­po­gra­phie fluide qui s’adapte de manière continue à l’espace dis­po­nible. On pri­vi­lé­gie aujourd’hui pour cela la fonction CSS clamp(). Elle permet de définir une taille de police minimale, préférée et maximale, sans recourir à des break­points sup­plé­men­taires.

h1 {
    font-size: clamp(2rem, 4vw, 3.5rem);
}
css

Ainsi, la police reste bien lisible sur les petits écrans, augmente de manière dynamique sur les écrans plus grands et ne dépasse jamais les valeurs limites définies. clamp() est aujourd’hui con­si­dé­rée comme optimale pour la ty­po­gra­phie res­pon­sive dans un design responsif per­for­mant.

Images res­pon­sives

Outre la mise en page et la ty­po­gra­phie, l’affichage optimisé des images constitue un élément clé du design responsif. Il est peu pertinent de charger une image de 1 920 pixels de large sur un smart­phone dont l’écran ne dépasse pas 400 pixels. D’une part, l’image doit être re­di­men­sion­née par le na­vi­ga­teur, ce qui consomme des res­sources. D’autre part, plus une image contient de pixels, plus son poids est élevé.

Une image de 1 920 x 1 080 pixels nécessite environ quatre fois plus d’espace de stockage qu’une image de 960 x 540 pixels. Son té­lé­char­ge­ment sur un appareil mobile est donc nettement plus lent. Au final, cela a un impact très négatif sur les per­for­mances et l’ergonomie d’un site Web, si les images ne sont pas op­ti­mi­sées dans une logique de Webdesign res­pon­sive.

Di­men­sions de l’image Surface d’écran Effet
Petite image Grand écran L’image se charge ra­pi­de­ment, mais apparaît pixelisée
Grande image Petit écran L’image se charge lentement, apparaît nette, mais entraîne de mauvaises per­for­mances de la page
Grande image Grand écran L’image se charge lentement, apparaît nette, mais entraîne de mauvaises per­for­mances de la page
Petite image Petit écran L’image se charge ra­pi­de­ment, apparaît nette, per­for­mances optimales

Pour les images res­pon­sives, les attributs srcset et sizes se sont imposés, car ils per­met­tent aux na­vi­ga­teurs de sé­lec­tion­ner au­to­ma­ti­que­ment la ressource la plus adaptée en fonction du contexte. On parle également d’« assets ». Chaque fichier est associé à une condition définie via des règles proches des Media Queries. Le na­vi­ga­teur peut ainsi choisir, parmi les dif­fé­rentes versions dis­po­nibles, celle qui cor­res­pond le mieux à l’appareil utilisé.

Prenons un exemple simple. Le code HTML suivant définit une image pour laquelle deux assets sont spécifiés via srcset : l’un avec une largeur de 480 pixels et l’autre de 800 pixels. L’attribut sizes indique que l’image de 480 pixels doit être utilisée jusqu’à une largeur d’écran de 600 pixels. Au-delà, le na­vi­ga­teur charge au­to­ma­ti­que­ment l’image de 800 pixels :

<img
    src="bild-800w.jpg"
    srcset="bild-480w.jpg 480w,
                    bild-800w.jpg 800w"
    sizes="(max-width: 600px) 480px,
                 800px"
    alt="Description de l’image">
html

L’avantage décisif de cette approche réside dans le fait que le na­vi­ga­teur décide lui-même quelle variante d’image doit être chargée. Les dé­ve­lop­peurs doivent seulement fournir des tailles d’images per­ti­nentes, sans avoir à gérer ma­nuel­le­ment la sélection.

Tra­di­tion­nel­le­ment, les écrans étaient orientés en mode paysage ; les écrans de smart­phones sont toutefois en mode portrait. Une image au format paysage apparaît donc très petite sur un appareil en orien­ta­tion portrait. Pour un meilleur résultat, il est pré­fé­rable d’utiliser une image spé­ci­fi­que­ment recadrée au format carré ou portrait. Le choix de dif­fé­rents re­ca­drages d’une image est appelé « direction ar­tis­tique » (Art Direction). Cela peut être réalisé avec l’élément <picture>. L’élément <picture> permet de définir de manière complexe plusieurs images équi­va­lentes pour dif­fé­rents cas d’usage.

Examinons l’exemple suivant. Le code HTML suivant définit un élément <picture> qui spécifie dif­fé­rents assets pour le mode paysage et le mode portrait. Pour les deux cas, il existe plusieurs versions op­ti­mi­sées pour dif­fé­rentes tailles d’écran :

<picture>
<source
media="(orientation: landscape)"
srcset="image-petite-paysage.png 320w,
image-grande-paysage.png 1200w"
sizes="(min-width: 60rem) 80vw,
(min-width: 40rem) 90vw,
100vw">
<source
media="(orientation: portrait)"
srcset="image-petite-portrait.png 160w,
image-grande-portrait.png 600w"
sizes="(min-width: 60rem) 80vw,
(min-width: 40rem) 90vw,
100vw">
<img src="image-petite.png" alt="Description de l’image">
</picture>
html

Cela permet de garantir qu’un visuel conserve le même impact sur les petits écrans en mode portrait que sur les grands écrans.

Note

Outre la ré­so­lu­tion, le format d’image joue aujourd’hui un rôle essentiel. Les formats clas­siques comme JPEG ou PNG sont de plus en plus complétés ou remplacés par des formats modernes plus per­for­mants :

  • WebP : bonne com­pres­sion avec une large com­pa­ti­bi­lité na­vi­ga­teurs
  • AVIF : taux de com­pres­sion très élevé avec une ex­cel­lente qualité d’image

Ces formats réduisent sig­ni­fi­ca­ti­ve­ment la taille des fichiers et amé­lio­rent les temps de char­ge­ment.

Na­vi­ga­tion res­pon­sive

La na­vi­ga­tion fait partie des éléments centraux d’un site Web et re­pré­sente un défi par­ti­cu­lier dans le cadre du design responsif. Sur les grands écrans, elle est gé­né­ra­le­ment affichée dans l’en-tête avec des sous-menus ac­ces­sibles au survol de la souris. Cette approche n’est pas adaptée aux appareils mobiles. D’une part, l’espace est limité, d’autre part, l’in­te­rac­tion se fait au toucher et non à la souris.

Pour les appareils mobiles, plusieurs solutions existent. Elles sont compactes et adaptées à une uti­li­sa­tion tactile. L’ouverture du menu est souvent ac­com­pag­née d’une animation pour améliorer la com­pré­hen­sion et l’ex­pé­rience uti­li­sa­teur. Parmi les approches les plus courantes de la na­vi­ga­tion res­pon­sive :

  • L’icône de « menu hamburger » (trois lignes ho­ri­zon­tales), utilisée comme dé­clen­cheur principal du menu
  • La na­vi­ga­tion « off canvas », dans laquelle le menu apparaît depuis le bord de l’écran et déplace le contenu principal

D’autres modèles sont également utilisés selon le contexte. La Bottom Na­vi­ga­tion place les éléments prin­ci­paux en bas de l’écran, ce qui facilite leur uti­li­sa­tion avec le pouce. Les menus « Priority+ » hié­rar­chi­sent les éléments im­por­tants et déplacent les entrées se­con­daires dans un sous-menu. Pour les sites plus complexes, des méga-menus adaptés au tactile per­met­tent de struc­tu­rer ef­fi­ca­ce­ment de grandes quantités de contenu, notamment sur tablettes et appareils hybrides.

Service de con­cep­tion de site Web
Nous créons pour vous votre site sur mesure
  • Votre site Web créé par des experts
  • Domaine et email per­son­na­li­sés pour renforcer votre marque
  • Mise à jour et main­te­nance de votre site après sa mise en ligne
Aller au menu principal