Mobile Marketing Webdesign — 24 octobre 2013 — 25 commentaires
Les 5 problèmes du Responsive Web Design

Face à l’explosion de la diversité des supports mobiles et de leur utilisation, le Responsive Web Design apparaît aujourd’hui comme l’une des grandes modes du web. Le Responsive Web Design (en français : Site Web Adaptatif) est une approche visant à adapter un site internet aux supports sur lesquels il est consulté, ce en redimensionnant l’organisation des contenus (basée sur une grille). Cette solution ne présente techniquement rien de révolutionnaire (elle existait déjà en 1999 ;) ), mais se répand de plus en plus, au point de devenir un véritable standard…

Le RWD serait-il donc LA solution parfaite aux problèmes liés à  la grande diversité des supports de lecture ? Ma réponse est claire : Non !

Problème 1 : Des besoins différents

Tout d’abord, il est inconcevable de proposer le même contenu pour des internautes dans des situations différentes, et avec des besoins radicalement différents.

Prenons un exemple : un groupe de grande distribution se sert de son site Internet pour  présenter sa marque via une vidéo et mettre en avant les possibilités de recrutement dans son groupe. L’utilité sera-t-elle la même sur mobile ? Pas sûr… Un store locator permettant de détecter les magasins les plus proches serait probablement plus pertinent sur ce support.

Au-delà de la facilité de lecture, c’est donc l’efficacité du RWD « brut » que je remets en cause. Un deuxième exemple pour l’illustrer : un formulaire sur mobile est souvent très contraignant. Est-il nécessaire de rendre obligatoire le champ « Adresse postale » pour ce support ? Est-ce vraiment utile de contraindre l’internaute à rentrer son adresse via son mobile ? Je pense qu’il est important de traiter différemment le formulaire, en réduisant par exemple le nombre de champs obligatoire sur mobile.

Bien sûr, il est possible d’adapter le site responsive en cachant certains contenus en fonction du support, mais… :

  • Afficher ou ne pas afficher du contenu ne résout pas le problème si le souhait est uniquement de mettre en retrait une information. Une très bonne remarque de interfacesriches.fr résume bien l’idée : « C’est un peu comme si vous me disiez qu’il suffit de réduire le nombre de rayons d’un hypermarché pour en faire une supérette de centre-ville. Réduire leur nombre ne suffit pas, il faut tout revoir : les zones de circulation, l’achalandage, la signalétique… »
  • De plus, l’objectif initial du RWD est de ne faire qu’un seul site ; or si tous les éléments affichés sont conditionnés par des règles en fonction des supports, il est clairement plus simple de créer différentes versions du site.

Problème 2 : Des contraintes techniques différentes

Les débits sont aujourd’hui extrêmement différents entre un ordinateur et un mobile. Et même si certains éléments sont « cachés » en fonction des supports, le RWD brut consiste à charger l’intégralité du site : toutes les images, tous les médias… D’où son problème, puisque le chargement d’un seul et même site pour différents supports entraîne forcément une importante concession :

  • Si le site est basé sur la version mobile, celle de ne pas proposer des médias de qualités sur la version desktop.
  • Si le site est basé sur la version ordinateur, celle d’avoir un temps de chargement considérable sur mobile (et autant dire un taux de rebond également important).

Techniquement, il est possible de contrer cela en utilisant le Responsive Server Side qui, pour faire simple, détecte le support et affiche, lui, uniquement les médias adaptés. Et pourtant, notre problème n’est toujours pas résolu… :

  • Que se passe-t’il si l’on souhaite redimensionner une fenêtre ou passer une tablette  verticale à horizontale?
  • Ce traitement serveur ne risque-t-il pas d’alourdir considérablement les traitements côté serveur, ainsi que celui côté client (et donc potentiellement ralentir le tout !) ?
  • Encore une fois, l’objectif initial du Responsive Web Design est de ne faire qu’un seul site, mais est-ce réellement plus simple de trouver une astuce technique pour gérer des cas particuliers que de créer différentes versions du site ?

Problème 3 : Une conception compliquée

Créer un site en Responsive Design est contraignant, car cela oblige à se baser sur une grille adaptable. Ce qui rend non seulement  la conception plus longue, mais de plus limite graphiquement et ergonomiquement les réflexions.

Certes, des templates existent déjà et sont disponibles à des prix raisonnables (sur themeforest.net par exemple). Cela peut effectivement correspondre à certains besoins, mais faire rentrer ses contenus dans un moule déjà existant nous ramène alors à la V0 de la conception web. Pour bien faire passer ses messages, la forme doit s’adapter au fond et non le contraire.

Problème 4 : Des limites techniques pour identifier les dimensions

Il est aujourd’hui possible d’identifier la résolution d’un écran, mais pas sa taille physique. Or, sur des écrans de tailles très différentes, la résolution peut être la même.

Un exemple illustrant parfaitement cette différence :

iPad Mini - Flipboard

« … la version Nexus 7 est juste une version agrandie de la version téléphone. Sur quelle version préféreriez-vous passer 20 minutes à lire ? » 

Problème 5 : L’affichage des publicités

Si la monétisation de votre site est votre priorité, le Responsive Design vous apportera des problèmes supplémentaires.

Exemple : si, sur un ordinateur, votre publicité s’affiche au-dessus de la ligne de flottaison, cela risque de ne pas être le cas sur une version mobile. Et peu de chances que cela plaise à vos annonceurs !…

Mais alors, quelle est la solution ?

Eh bien il n’en existe malheureusement pas de parfaite, cela dépend réellement des ambitions, des moyens, des problématiques et des secteurs. Le Responsive Web Design n’est pas une mauvaise solution, mais elle n’est pas la plus adaptée à toutes les situations.

La priorité reste de bien mettre l’utilisateur au centre de la conception !

La réalisation d’un site ne doit ni être basée sur une solution technique, ni sur un discours commercial. Le besoin des internautes n’est pas simplement d’avoir une version mobile d’un site, mais bien de trouver une réponse rapide aux attentes qu’ils ont (besoins qui pourront être différents d’un support à l’autre).

Pour concevoir les différentes versions d’un site, il est donc nécessaire de se demander en priorité quels sont les différents besoins et usages, pour ainsi définir la ou les solutions les plus adaptées.

Il n’y a donc pas de solution toute faite et valable pour tous les mondes, mais de mon côté je privilégie souvent de faire deux versions, une version tablette + ordinateur et une version mobile :

  • Deux versions connectées à la même base de données pour pouvoir actualiser facilement les deux sites ;
  • Deux versions adaptables en largeur pour répondre aux différentes tailles d’écrans (on se rend bien compte du fonctionnement en redimensionnant une fenêtre sur le centre d’aide de Google par exemple).

« Si le seul outil que vous avez est un marteau, vous tendez à voir tout problème comme un clou ». Abraham Maslow (The Psychology of Science, 1966).

Et vous, quelles solutions privilégiez-vous ?

Articles similaires

L'auteur

Valentin Quillier

Consultant en Webmarketing chez Georges Office, je visite en moyenne 535 pages internet par jour, clique 4394 fois sur ma souris, lance 19 logiciels, lis 73 mails, parcours 1,2 km d’écrans et utilise 27 applications iPhone. Mais en parallèle, toutes les semaines je parcours 18 km en trottinette, fais 57 000 pas, mange 2 fois dans un fast food, tente 74 services slicés, prends 57 photos, dors 50h et respire 161 000 fois.

 

25 Commentaires

  1. Drôle de coïncidence car je travail actuellement sur une site Responsive. Bah va falloir encore bien penser avant d’agir! Très intéressant l’article

  2. Très intéressant ! Merci pour cette article.

    Tu as soulevé les principaux problèmes que nous rencontrons aujourd’hui.

  3. le rwd n’est pas une solution marketing, mais technique.

    le problème avec la détection du support et un site mobile dédié, c’est qu’il rend parfois l’accès a certaines informations difficile lors d’une utilisation inter-plateforme : si j’ai vu une infos sur le desktop que je veux retrouver sur smartphone et que l’éditeur me propose une version mobile allégé sans possibilité d’accéder au contenu « normal » j’aurais une mauvaise expérience. Présupposer de ce que veux l’utilisateur sur mobile est dangereux

    A mon sens, le rwd est très important, pour tout le monde, mais cela ne dispense pas d’aller plus loin avec un site mobile dédié. Pour les clients qui en ont les moyens en tout cas.

  4. D’un point de vue purement utilisateur, je suis développeur iOS pas Web, j’apprécie beaucoup le responsive design pour la navigation sur tablette ou smartphone.

    Par contre, je déteste vraiment les sites dit « mobiles » qui sont souvent moches avec très peu d’informations, une navigation difficile… dans ce cas je préfère largement passer au site standard et naviguer en zoomant. Je sais que ce n’est pas le but recherché mais le résultat est souvent là.
    En plus le coup du lien qui ne fonctionne pas sur mobile et nous ramène sur la page d’accueil ça c’est vraiment énervant !

    Voilà c’est dit, je pense que le mieux c’est de faire du responsive design ou de ne rien faire du tout…

    Je suis également d’accord avec Avel, ne faîtes jamais de présuppositions sur les besoins d’un utilisateur mobile. En effet, aujourd’hui beaucoup de gens naviguent sur leur smartphone depuis chez eux, au calme, et non en courant dans le métro !

    • Merci Virginie de faire partager ton point de vue.
      En effet, il est préférable de proposer un site non adapté au mobile (mais au minimum sans flash), plutôt que de faire une version mobile au rabais supprimant la moitié des fonctionnalités. Cependant, c’est moins pire, mais pas forcément la meilleure solution ;).
      L’objet de la conclusion de mon article était surtout de montrer que l’utilisateur n’aime pas le « Responsive Design », il aime juste avoir un contenu adapté à son device et à sa situation. Il ne faut en effet pas se tromper : nous sommes les seuls à nous amuser à resizer nos fenêtres pour voir le comportement du site …

      L’étude des besoins utilisateurs doit donc être une vraie base de travail, mais comme tu le dis, elle ne doit pas être basée sur des préjugés (type mobile = métro), car les usages en fonction des secteurs sont vraiment très différents.

    • Tout à fait d’accord, les sites 100% mobiles sont pour la plupart totalement inutiles ou inutilisables. Le responsive design à, certes quelques défauts, mais c’est quand même beaucoup plus agréables. D’autant que les connexions mobiles sont de plus en plus performantes, mieux vaut privilégier la qualité à la vitesse de chargement :)

  5. Pour faire du développement en responsive design de façon très régulière, il est clair qu’en plus des contrainte techniques énoncés dans l’article, se rajoute celle de la difficulté des constructeurs à utiliser des standards (j’en veux pour exemple Apple et Android dont la détection portrait paysage est complètement inversée de l’un à l’autre).

    Il faut donc prévoir un budget conséquent lorsque l’on souhaite que son site soit adaptable aux supports dit mobile. Et quand bien même il y aura toujours quelques appareils sur lesquels le rendu ne sera pas bon ou optimal.

  6. travaillant dans une grand boîte IT , je peux vous affirmer que le RWD est beaucoup moins cher que de faire une version mobile à part. Cela sous-entend de doubler les déploiements en ACC/PROD à chaque fois de se familiariser avec des outils différents et donc des capacités différentes (sencha touch, jquerymobile, application restfull, config serveur, ouverture de flux, détection proxy pour les redirections ou que sais-je….) bref les coûts explosent alors qu’avec les RWD, une seule équipe est impactée. Je parle bien entendu pour une grosse boîte IT. dans une petite structure, les coûts seraient moindres.

    • Merci de nous faire partager votre point de vue au sein d’une grande boite d’IT. Dans de grosses structures, l’organisation est en effet différente et apporte de nouvelles problématiques. Il est difficile de faire autrement, mais c’est vraiment dommage qu’une contrainte organisationnelle prime face au bénéfice utilisateur.

  7. le point 1 est faux : comment présupposer qu’un utilisateur a des besoins différents selon l’appareil qu’il utilise? Comme Virginie, je pense exactement le contraire : un utilisateur est frustré de ne pas trouver les mêmes infos en consultant le même site sur différents appareils.

    les points 2, 3, 4, et 5 disent la même chose : il y a de plus en plus en plus d’appareil différents, et c’est compliqué (et ce n’est pas fini avec l’arrivée des lunettes et des montres). Oui c’est vrai que c’est plus compliqué de faire un site aujourd’hui qu’il y a quelques années. Mais il ne faut pas inverser les causes et les conséquences : cette complexité n’est pas due au RWD mais à l’environnement technologique. Le RWD s’efforce d’y apporter une solution globale (et donc plus économique que de faire des développements séparés comme le souligne pixelpreview).

    bref… pour l’instant c’est la meilleure voie et cela va s’améliorer avec l’arrivée de balises html spécifiques (picture par exemple).

    C’est tellement la solution que certains pensent même que les applis mobiles n’ont plus beaucoup d’avenir: http://jim-silverman.com/blog/native-apps-are-the-new-flash/

    Sinon, voici un point de vue documenté sur les problèmes liés au RWD (car il y en a) : http://mobile.smashingmagazine.com/2013/05/29/the-state-of-responsive-web-design/

    • L’idée n’est pas de présupposer les besoins utilisateurs, mais bien de faire une étude en amont des utilisations et besoins. Il est vrai que dans certains cas les utilisations sont les mêmes, mais globalement lorsque l’on compare les statistiques d’utilisation d’un site entre mobile et web, les comportements sont assez différents (temps passé, les rubriques de contenus les plus visitées …).

      Encore une fois le RWD n’est pour moi pas une mauvaise solution, elle n’est juste qu’une solution parmi d’autres avec des problèmes qu’il est important de prendre en compte lors de sa conception. De plus ce n’est qu’une solution et il est primordial de ne pas se dire «on va faire un site RWD» sans savoir pourquoi (tout comme il y a eu une mode de «tous sur Facebook» sans raison).

  8. Notre démarche est axée utilisateur ce qui nous a amené après l’utilisation de Responsive Web Design et la création de différents sites mobiles d’éviter de faire du RWD car je confirme ces 5 problèmes.

    Le budget est un point important mais rien n’empêche de proposer un produit adéquate et efficace aux visiteurs (en terme d’ergonomie)

    Un site mobile doit être travaillé spécifiquement pour mobile et spécifiquement pour tablette car les comportements ne sont pas les mêmes.

  9. Nous sommes aussi sur un projet de refonte en responsive.

    On a aujourd’hui 4 supports à prendre en compte :
    le mobile
    la tablette
    le desktop
    et… la télé

    Pour le mobile, tout dépend de la nature de votre site, mais pour un site e-commerce, un site simplifié permettant un achat rapide rend service aux internautes. Mais comme souligné par Virginie, certains utilisateurs préfèrent une navigation sur le site originel, d’où ma solution préférentielle : dès l’arrivée d’un mobilaute, lui proposer le choix de navigation : version mobile ou version classique et chacun y trouvera son bonheur.

    Pour le reste, ça se complique…

    Car fut un temps où identifier la résolution était suffisant pour proposer une version d’un site. Or désormais vous pouvez avoir (et ça va être le cas de plus en plus) des utilisateurs disposant d’une résolution > 2000 pixels sur des supports (tablette, pc, télé). La résolution est la même pourtant l’utilisateur est face à une expérience totalement différente : devant sa tablette 7/8 pouces, assis à son bureau derrière son ecran 22 pouces ou encore allongé sur son canapé à 3m de sa télé 102cm…

    Sans monter une usine à gaz, sans retomber dans les travers du passé et développer 36 versions de site, sans avoir un budget de 500K : nous devons désormais prendre en compte ces éléments dans notre développement, avec une problématique : les supports et résolution se sont multipliés plus vite que la technique RD et RESS n’ont évolué. Les développements actuels sont donc assez complexes car ne peuvent pas de baser sur beaucoup d’existant et parfois construits sur des techno nouvelles d’une fiabilité non confirmée.

  10. Bonjour et merci pour cet article qui a le mérite de ne pas prendre pour argent comptant la pratique du responsive design, et de prendre un peu de recul pour questionner sa pertinence ! Toujours intéressant de lire ce type de contenus.

    Pour m’être posé moi aussi ces questions (et avoir tranché en faveur du responsive design, ce qui va nécessairement orienter ce commentaire, je l’admet), je voudrais toutefois réagir sur deux remarques que vous faites :

    « Ce traitement serveur ne risque-t-il pas d’alourdir considérablement les traitements côté serveur, ainsi que celui côté client (et donc potentiellement ralentir le tout !) ? »

    => avez-vous des benchmarks pour corroborer ceci ? il me paraît hautement improbable qu’un traitement côté serveur de cette nature (sélectionner des médias en fonction des supports) puissent occasionner un quelconque ralentissement, car le surcoût en temps du traitement est logiquement ultra-marginal

    « Encore une fois, l’objectif initial du Responsive Web Design est de ne faire qu’un seul site, mais est-ce réellement plus simple de trouver une astuce technique pour gérer des cas particuliers que de créer différentes versions du site ? »

    => là encore, si vous avez des comparaisons à exhiber, je suis preneur : entre maintenir plusieurs versions d’un site, avec tout ce qui ça suppose en matière de gestion des mises à jour, d’organisations des développements, de risques d’erreur, et trouver des astuces techniques sur une seule base de code, j’ai du mal à trouver des scénarios d’usages où la 2e solution ne serait pas,, et de loin, la meilleure en termes de temps passé et in fine de coût, et pas seulement dans les grandes boites IT comme l’indique un commentaire précédent, mais à mon avis dans l’immense majorité des cas

    Je vous rejoins sur le point essentiel de votre article : la « grille » responsive design est un leurre ; le service compte avant tout et ces technologies ne sont qu’une base à hautement personnaliser avant de réaliser une véritable expérience multi-écran. Mais elles restent une base très « cost-effective »

  11. Bonjour,

    si je peux me permettre, je souhaiterai apporter une précision concernant le point #4.

    Il est tout à fait possible en CSS de déterminer un style conditionnel en fonction, non pas de la résolution simulé du device, mais de la taille/résolution réelle du terminal.

    Sans rentrer dans le technique, il s’agit d’une règle dans media query : device-height/width

    Au plaisir,

    Alex

  12. Woah,

    Super article. Eh moi comme un con qui pensait que Responsive c’était la meilleure chose qui pouvait exister.

    Cet article me donne des maux de têtes déjà. Il faut que je réfléchisse maintenant à cet aspect de mon blog. Merci quand même d’avoir écris cet excellent article.

    Maurel Archange

  13. Étant seulement utilisateur et pas technicien je trouve que le responsive est actuellement une solution qui peut convenir dans certains cas mais qui oblige à quelques concessions.J’ai fait ce choix pour mon site e commerce après réflexion et suis assez satisfait du résultat . Le responsive évite également les problèmes de duplicate content dans ce cas.
    Les technologies sont émergentes en ce qui concerne l’adaptation aux formats d’écrans , elles vont surement connaitre des développements rapides.
    Merci en tous cas pour cet article qui oblige à se poser le problème du choix en toute connaissance de cause.

  14. Je ne suis absolument pas d’accord avec cet article.
    1/ Des besoins différents : différentes études ont été faites (lire notamment la série « a book apart » ) qui démontre qu’aujourd’hui, lorsqu’un internaute consulte un site depuis un mobile, la seule chose que l’on sait, c’est qu’il a un mobile. Le déploiement des réseaux mobiles, l’explosion des usages mobiles et des devices, l’explosion des ventes de tablettes, ont fait qu’aujourd’hui, on consulte un site depuis son mobile ou sa tablette parce que l’on est dans un train, ou dans son canapé et qu’on a la flemme d’allumer l’ordi, ou même, que l’on ne dispose pas d’ordi. Oui, pour certains, le mobile ou la tablette sont les seuls accès au web dont ils disposent… Ils est donc indispensable de fournir un contenu intégral sur les mobiles.

    2/ les contraintes techniques
    Il existe aujourd’hui de nombreux scripts qui permettent de détecter les écrans et de fournir les médias correspondant.

    3/ Conception compliquée.
    « limite graphiquement et ergonomiquement les réflexions » Je vous conseille de faire un tour sur ZenGarden, histoire de voir les possibilités du css

    4/ Des limites techniques pour identifier les dimensions

    Là, j’avoue que je ne vous suis pas… Ouais, c’est vrai… Et alors? Avec un site mobile, c’est plus simple de concevoir aux bonne dimensions?

    5/ La pub
    Sur ce point, je pourrais vous rejoindre, bien que Google s’adapte parfaitement aux mobiles (et que c’est la régie n°1), et que, de toutes façons, les récentes études montrent bien que la pub, sur mobile, de toute façons, ça marche moins bien.

    Bref… Il n’existe pas de solutions parfaites, mais aujourd’hui, c’est bien le responsive qui est le mieux adapté. Et surtout, surtout, ne privez pas ceux pour qui l’accès au web se limite à leurs mobiles de l’intégralité des contenus… ça porte un nom, bien connu des acteurs du web : la neutralité du net !

  15. Le responsive coûte bien moins cher que de faire du natif ou des sites dédiés : il faut juste sortir du ciblage par résolution (pire : par périphérique), mais plutôt penser contenu d’abord : en concevant tout en fonction de la taille de fonte par exemple, le contenu est entièrement adaptable, et au final, le site pourra s’adapter sur une télé comme sur un smartphone.

    Après, certes, c’est pas toujours simple, mais c’est quand même bien efficace ! :)

  16. Super article et très pertinent….

    Apres j’ai été surpris de ne pas pouvoir ouvrir le site de l’agence George Office depuis mon smartphone parce que en flash;-)

    Au plaisie de faire ta connaissance.

    Bien cordialement,

    Gabriel
    http://Www.1min30.com

    • Merci.

      Malheureusement, ce sont toujours les cordonniers les plus mal chaussés …
      Il est toujours difficile de trouver le temps que nous consacrons à nos clients pour nous même :).

  17. Bonjour et merci,
    pour cet article pertinent et bien résumé.

    Je commence également à m’intéresser à tout cet univers du RWD et il est vrai que j’ai pu me confronter à de nombreuses contraintes qui sont énoncées dans l’article.

    C’est sûr qu’il y a autant de solutions différentes qu’il y a de projets différents.

    Pour ma part, on m’a demandé de rendre notre site web en RWD alors que son intégration initiale n’est pas du tout orientée RWD…en un mot : Galère !

    Dans mon cas, la complexité réside au niveau technique, certaines fonctions JS sur Desktop doivent agir autrement sur support mobile, des éléments du moteur de recherche (exemple : slider de sélection de valeur) doivent être remplacé sur version mobile (ex : liste déroulante) afin de facilité l’utilisation, etc.. Sans parler de la redéfinition complète de toute la CSS (largeur flexible en %, etc.)

    Je me demande donc si la solution la plus appropriée, pour mon cas, serait de faire 2 versions du site (une version desktop et une version mobile)…en gros retour à l’avant RWD :’)

    Peut-on dire que le RWD serait plus adapté pour des sites « leger » (ex : blog, site vitrine) et la solution du versioning pour les sites un poil plus « lourd » (ex : site e-commerce, proposant des biens, des services et des éditos…).

    Merci

    Abaze

  18. @Abaze : « Peut-on dire que le RWD serait plus adapté pour des sites « leger »

    on pourrait le penser et c’est vrai qu’il faudrait faire un distingo entre les différents types de sites ayant des objectifs distincts reposant sur une structure différente adaptée aux usages qui en sont fait, mais on voit de plus en plus de sites complexes et « fournis » passer en RWD : un exemple le site du journal US boston globe (bostonglobe.com). Les possibilités du RWD sont appelées à s’étoffer même si c’est une « vieille » techno son utilisation plus intensive est relativement récente. Faire un site spécial mobile me paraît un brin vieillot.
    – Concernant le terme mobile, il est trompeur, on devrait presque le remplacer par « portabilité » car on pourrait aussi parler de mobilité domestique dans la mesure où ces devices sont utilisés  » à la maison » et pas uniquement « en mouvement » , et de plus en plus car les tablettes vont éradiquer les pc à terme (le pc ne sera plus qu’un instrument pour les pros de l’informatique et du web comme le tracteur de l’agriculteur).

    ps/ le champ texte des commentaires est riquiqui

  19. bonjour,

    J’avais une question à propos du responsive design, c’est long à réaliser ? Par exemple pour une newsletter, ça demande beaucoup plus de travail ?

    Merci pour vos réponses.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>