Et si le meilleur responsive, c’était pas de responsive ?

par Romain Boyer - Il y a 11 mois

On voit de plus en plus de discussions au sujet du responsive, en faveur ou contre, tout simplement parce que le mobile prend une place incroyable dans le trafic.

Lors d’une opération sur RoseDeal, Menlook.com a ainsi pu accueillir jusqu’à 25% de trafic en provenance des mobiles dernièrement.

D’où l’importance d’avoir un site adapté au mobile (tablette ou smartphone), tout le monde se rejoint là-dessus.

Le débat se porte principalement sur la question : faut-il avoir un site responsive ou créer un site dédié aux mobiles, voire pourquoi pas une appli dédiée.

Une application dédiée ?

semble une mauvaise idée :

  • d’abord à cause des coûts (une App pour smartphone + tablette pour chaque OS),
  • ensuite parce que la majorité des fonctionnalités qui font l’intérêt de l’application (slide, touch, pinch, etc.) peuvent être créés avec les frameworks Web

Un site dédié aux mobiles ?

pourquoi pas.

Les sites d’aujourd’hui sont souvent créés sur le modèle MVC, Modèle / Vue / Contrôleur, le modèle étant la couche qui accède aux données, le contrôleur celui qui s’occupe de servir les fonctionnalités, et la vue ce qui sert à présenter tout cela sous forme d’interface homme/machine.

Quand on crée une appli ou un site dédié, on crée donc simplement la partie vue. Créer une autre vue web est beaucoup moins complexe que créer une vue dans une application à part, ça peut donc être intéressant et relativement facile à mettre en oeuvre.

Par contre, il faut ensuite dupliquer chaque évolution. Ou pas d’ailleurs car toutes les fonctionnalités du site Web n’ont pas forcément d’intérêt dans une application mobile, c’est ce qui fait le charme de l’application mobile, être efficace. Voyages-SNCF par exemple ne vous proposera pas de spécifier deux cartes de réduction différentes sur l’appli, ce qui simplifie l’affichage.

Un site responsive ?

Le site responsive, c’est celui qui s’adapte en fonction du media utilisé (tablette/smartphone) et de sa résolution. L’idée de base est qu’à partir du même code source HTML, on n’ait à qu’à détecter la configuration du navigateur pour utiliser telle ou telle mise en forme.

Cela force souvent à créer des absurdités, comme mettre dans le code source une partie de code HTML pour les mobiles, et une autre pour les non-mobiles, ce qui peut alourdir considérablement le code source chargé par les mobiles.

Cela oblige encore et toujours à tester chaque développement réalisé sur différentes plateformes pour être sûr qu’on n’a rien cassé.

Ils sont malins chez Amazon, la seule chose qui diffère quand on redimensionne l'écran et l'apparition par défaut ou non des différentes boutiques, le (pré-)déroulé du menu en somme.

Ils sont malins chez Amazon, la seule chose qui diffère quand on redimensionne l’écran est l’apparition par défaut ou non des différentes boutiques, le (pré-)déroulé du menu en somme.

Et pourquoi pas « pas de responsive » ?

Désolé, j’avoue, c’était un titre un peu racoleur… il n’y a pas de solution miracle, les smartphones ont réellement besoin d’une interface dédiée. Une page Web, si simple soit-elle, ne peut pas être présentée de la même façon sur un navigateur qui fait 400px de large ou 1000px, c’est mathématique. Cette réflexion n’est donc pas pour les smartphones.

Par contre, pour les tablettes, il en va autrement.

Je pense qu’il y aurait un vrai intérêt à avoir le même site pour les tablettes et pour les ordinateurs de bureau. 

Simplement parce que simplifier l’interface pour les tablettes reviendrait à rendre les choses plus évidentes pour les navigateurs des ordinateurs de bureau. On travaille beaucoup sur la simplification du toucher parce qu’on le considère complexe, on devrait aussi beaucoup travailler sur la simplification du clic.

Seraient ainsi travaillés :

  • Les boutons d’action, plus gros, plus évident, au dessus de la ligne de flottaison (effort souvent fait pour les tablettes, et assez peu pour le reste)
  • La simplification des menus, avec moins d’éléments, et une navigation plus progressive (ce qui ne déservirait souvent pas le SEO d’ailleurs)
  • le nombre de visuels, en moindre nombre mais plus impactants

Ces actions sont des best practises en terme d’ergonomie, nul doute que des tests A/B montreraient l’intérêt en terme de taux de rebond, de nombre de pages vues et de performances (rapidité et conversion).

Pour conclure, mon conseil ?

parce qu’il faut bien se mouiller à un moment donné.

A mon avis, il vaut mieux :

  • pour les smartphones, avoir une application Web (pas d’application par OS de smartphone donc), avec une vue (template) à part, avec une CSS à part. Ainsi, les développements peuvent être effectués séparément, et le mobile ne ralentira pas systématiquement les développements effectués pour les grandes résolutions. Cela permet aussi d’alléger considérablement le code source pour les mobiles ; et cela permet de sélectionner quelles fonctionnalités sont vraiment utiles aux smartphones ;
  • pour les tablettes et les ordinateurs de bureau, une même vue, simplifiée, avec moins d’éléments, pas trop de colonnes. On prévoit juste de pouvoir détecter si le slide est rendue possible par l’interface, ce qui permettrait aussi une compatibilité avec les ordinateurs de bureau tactiles, de plus en plus nombreux.

Evidemment et comme toujours, cela s’étudie au cas par cas. Mais je serais curieux de vos avis, s’ils sont aussi tranchés.

Romain Boyer

Romain est un consultant eCommerce, spécialisé dans la création de valeur et l'optimisation du taux de conversion, ainsi que sur les pratiques cross-canal > Suivre Romain sur Twitter : @RomainBOYER > Profil sur Google > sur son blog eCommerce

13 Commentaires

13 réponses à “Et si le meilleur responsive, c’était pas de responsive ?”

  1. Mark Le Net dit :

    Et si la solution était plutôt du responsive mais à bon escient ?

    Parce que je je sais pas combien tu as codé de sites tel que tu décris le responsive, mais vu comment tu le décris je serais d’accord avec toi!

    Sauf que le bon responsive, ce n’est pas côté client (l’écran, i.e. smartphone, tablette ou terminal type PC) mais côté serveur (ton site web) que ça se code.
    Et dans ce cas on n’envoie au smartphone que le bon code html (généré ou sélectionné par du code en PHP et/ou des requêtes en BdD) avec la CSS qui lui convient.
    Et si ton codeur (chez moi ça veut dire un ingénieur qui a 10 ans d’expérience au moins) a bien fait son boulot, y a pas besoin de revérifier toutes tes pages sur tout type d’écran ; d’une part il y a des outils pour ça, mais surtout il y a des méthodes et méthodologies à appliquer.

    Mais comme j’en discutais hier avec un « incident manager » d’une grande boîte internationale, le bon sens (qui s’appelle ITIL dans l’industrie) est bien rare…

    Donc, responsive, absolument, mais bien conçu !

    M.

  2. Nicolas dit :

    Le responsive coté serveur ? LOLILOL

    Le responsive doit aussi s’adapter à la taille du navigateur (OK c’est fixe sur une tablette ou un smartphone que tu auras pu identifier en PHP), et ça tu es obligé de le gérer directement en HTML/CSS pour les navigateurs web.

  3. Prestarocket dit :

    Hello,
    Je ne pense pas que le code source html caché va considérablement alourdir une page « responsive ».
    Le problème avec le responsive, c’est qu’on utilise des images surdimensionnées pour la version mobile, du coup ça alourdit énormément la page…c’est là qu’intervient le RESS : responsive design avec composants côté serveur (pour les images par exemple, on charge les images de taille différente en fonction du user agent).
    Autre outil, Modernizr pour détecter les capacités du navigateur et faire du chargement conditionnel de scripts.
    Ce qui m’embête avec les appli dédiées, c’est qu’elles ne sont pas présentes dans les résultats de recherche;

  4. Romain Boyer dit :

    @Mark plutôt d’accord pour le « bon responsive », ça va dans mon sens je trouve :-)

    pour le coup du codeur qui est ingénieur et a 10 ans d’expérience, et qui est toujours quoi qu’il en soit sujet à risque, ça marche aussi avec un bon CDP (toujours nécessaire) + dév lambda ;-)

    @Nicolas je crois qu’on parle de la détection et de l’action faite en fonction, qui peut se faire au niveau serveur ou au niveau des media queries en CSS. Je pense que c’est préférable de le faire au niveau serveur pour les raisons que j’ai évoquées

    @Prestarocket à propos de la taille du code source : c’est que tu n’as jamais vu de code source de 40.000 lignes…
    je suis d’accord sur le RESS, c’est le sens de mon propos effectivement.
    Je vais aller regarder Modernizr que je ne connais pas ! mais dans l’idée ça se code facilement tout de même ?
    Pour les applis dédiées, tu peux toujours rediriger en fonction du navigateur dessus, il y a toujours un équivalent à une page non dédiée qui peut rediriger vers la page dédiée sans trop de souci !

  5. Michel-Ange Masdongar dit :

    « Cela force souvent à créer des absurdités, comme mettre dans le code source une partie de code HTML pour les mobiles, et une autre pour les non-mobiles, ce qui peut alourdir considérablement le code source chargé par les mobiles. »

    Si l’on travaille en dynamique avec des conditions, le code n’est chargé que si l’on est sur le bon device, pas de display:none. Personnellement je travaille avec le CMS Drupal, le module Context permet de travailler de cette façon.

  6. Le responsive ça peut aussi etre :

    Mobile
    Tablette/Desktop
    Ultra HD (1080p et +)

    Après tu dois bien avoir des sélecteurs pour ne charger que la partie utile en responsive non ? C’est rare quand on change de résolution d’une minute à l’autre.

  7. Rien n’empêche d’avoir du responsive pour s’adapter aux multitudes de résolutions. C’est déjà une étape importante.

    Après, pour la mobilité, c’est clair que ce n’est pas la solution ultime et qu’un travail plus conséquent est nécessaire.

  8. Sébastien dit :

    Effectivement, assez tranché votre avis ^^

    Je ne serais pas aussi catégorique. Comme d’autres que j’ai pu voir dans les commentaires, je pense qu’il faut savoir gérer. Pas du responsive partout, pas de non responsive nulle part… En clair, un peu de responsive par endroit, sur les boutons de call action ect pour regérer l’interface sans pour autant changer tout le site.

  9. Webbax dit :

    Hello,

    Assez d’accord avec ce que tu racontes ;)

    Mais un truc qui me frappe c’est qu’au travers de ce genre de questions, on travaille pas trop la question autour de ce problème.

    Si c’est du responsive / mobile pour un blog ou pour un ecommerce, les difficultés sont par exemple très différentes.

    La partie qui me concerne c’est essentiellement le e-commerce, franchement… je pense qu’il faut attaquer le marché du mobile quand vraiment le site classique tient bien la route et qu’on en tire un réel profit.

    Pour faire bien les choses il faut avoir le temps et l’argent… Trop souvent je vois des clients se lancer sur le marché du mobile alors qu’ils ne font même pas le principal correctement.

    Et puis… un site classique restera toujours consultable sur tous les supports, à condition de faire un peu de gymnastique.

    On revoit ça dans 1 ou 2 ans ?

  10. Romain BOYER dit :

    Là tu touches un point sensible !! et tu as oh combien raison..

    le point sensible, c’est qu’on commence très souvent quelque chose avant d’avoir bien terminé les étapes précédentes, on croit qu’attaquer plein de projets avant-gardistes est rentable. Mais est-ce plus rentable que d’optimiser à fond ce qu’on a déjà.

    Je pense que tu as la réponse, et j’aurais tendance à rejoindre ton avis.

    Il faut clairement passer plus de temps à étudier la rentabilité des actions que l’on a menées plutôt que de multiplier les projets.

    Merci

  11. Jérôme dit :

    Bonjour, je crois que cela dépend aussi de la taille du projet. Aujourd’hui, Un site vitrine ou un blog ont besoin d’être consultables sur mobile ou tablette, tout comme un site d’e-commerce peut le nécessiter, seulement les problématiques sont tout de même très différentes. Difficile d’utiliser les media queries pour une usine à gaz mais pour un portfolio, par exemple, je ne vois pas vraiment de contre indication.

  12. Alexeo dit :

    Bonjour,
    Le titre m’a tout simplement interpelé !
    Comme dit Jérôme juste au dessus, les gros sites se doivent désormais d’avoir une version mobile.
    Je pense que le mieux est de dédier une partie du site au mobile via un sous domaine. Ça évite de surcharger le code du site standard.

  13. Romain BOYER dit :

    Un article de GetElastic sur le remplacement des applications natives par des applis Web HTML5 http://www.getelastic.com/why-html5-should-replace-native-apps-for-ecommerce/

Laisser un commentaire