De passage lors de la conférence SemWeb Pro, Clubic a pu rencontre M. Daoust pour revenir sur les avancées et les enjeux du web mobile.
Sauriez-vous me dire la part des sites Internet disposant d'une version réellement optimisée pour mobile ?
François Daoust : Non je n'ai pas de chiffres. Nous avons fait un peu de recherche sur les sites classiques tels que la FNAC et je suis agréablement surpris de voir qu'ils disposent d'une version mobile. Après, à savoir si les versions sont réellement optimisées, c'est sujet à débats et cela dépendra de l'individu. Mais la plupart de ceux qui forment le top 100 des sites majeurs du web ont un pendant mobile qui est plus ou moins caché, plus ou moins accessible, qui est plus ou moins bien fait, plus ou moins optimisé pour tous les mobiles ou ciblera un type de smartphone donné par exemple l'iPhone ou Android. Souvent, c'est la plateforme de l'iPhone et son succès qui leur fait passer le pas. On a des chiffres sur la part des navigateurs mobiles ou de l'utilisation du web mobile. La source classique est StatCounter, elle n'est pas parfaite, car subjective, mais au moins elle existe. Selon eux il y a 3 ou 4% de l'utilisation du web qui est mobile. Selon la manière dont on regarde ces chiffres c'est soit beaucoup, soit très peu. Ca monte progressivement mais cela reste marginal.
Ne serait-il pas possible d'obtenir des statistiques à partir de l'analyse du code des pages présentant un DOCTYPE particulier dans le code HTML spécifiant les versions mobiles des sites ?
F.D : Non parce que nous n'essayons pas de mettre en avant l'utilisation d'un DOCTYPE. Il y a deux DOCTYPE spécifiques pour le web mobile avec une convergence entre les deux. Ces derniers étaient nécessaires par le passé pour que le navigateur affiche la page. Aujourd'hui c'est obsolète. Pour nous cela sert uniquement dans un souci de validation. Il est possible d'utiliser les DOCTYPE si jamais vous voulez valider une page via un validateur de markup. En dehors de ce cadre-là cela n'a pas trop d'intérêt et d'ailleurs nous préférons le nouveau DOCTYPE mis en avant par le HTML5 qui au moins a l'avantage d'être simple à écrire et fonctionne très bien.
Par ailleurs, pour nous le web mobile inclut également les applications qui sont programmées avec les technologies du web comme XHTML, CSS, JavaScript avec un enrobage qui leur donne un aspect natif. On peut faire cela avec des petits frameworks comme PhoneGap sans avoir à faire de l'Objective-C ou du Java.
Justement, les kits de développement spécifiques pour le web mobile comme celui d'Apple ou toutes ces applications mobiles, n'est-ce pas un frein pour imposer des standards ?
F.D : Oui et non. Il y a une part de compétition. Nous, ce qui nous inquiète c'est l'aspect fermé. Ce n'est pas le problème d'utiliser Objective-C, Java, C++ ou C# mais le fait de se retrouver bloquer par une plateforme et devoir refaire une autre version pour cibler une seconde plateforme. Le marché des OS évolue très vite et nous observons des disparités géographiques.
L'avantage de ces standards c'est d'offrir une base commune à toutes ces plateformes quitte à l'adapter avec des petites interfaces natives. C'est relativement simple et c'est d'ailleurs ce que PhoneGap fait. A terme nous espérons rajouter un ensemble d'API qui permettront d'enrichir l'offre disponible depuis un navigateur web.
Phonegap : Simulateur Android - Crédit : Mobile Tuts
A ce sujet, en avril 2010, Dominique Hazaël-Massieux présentait ces interfaces. Qu'en est-il de leur avancement ?
F.D : Ca avance doucement mais sûrement. Cela dépend vraiment de l'API en question. Typiquement la géo-localisation a très bien avancé. C'est déjà présent dans beaucoup de navigateurs mobiles. Pour d'autres cela met un peu plus de temps. Je ne connais pas les statuts exacts de chacune de ces interfaces mais pour tout ce qui est d'accéder aux contacts ou à la galerie médias... ça suit son cours sans avancer trop vite, cela dépend des priorités. En tout cas cela avance.
Les éditeurs d'OS mobiles devront-il se plier à ces interfaces pour autoriser ou non la communication avec les élements du système ?
F.D : Non ca ne sera pas eux mais plutôt ceux qui font le navigateur de l'OS en question. Ces interfaces existent justement déjà sur les OS. Le but du jeu est donc de faire remonter ces dernières via l'application native qu'est le navigateur tout en conservant un maximum de sécurité.
Par exemple pour la caméra il y a plusieurs manières d'envisager la chose. Dans le HTML5 c'est considéré comme un input. Cela peut être un fichier audio ou vidéo avec une prise en direct par la caméra. Mais il n'y pas besoin de spécifier une interface spéciale, c'est juste le navigateur qui propose de prendre une photo ou une vidéo. L'utilisateur est protégé car c'est lui qui prend la décision de ce qu'il envoie.
Et quid du streaming en direct ?
F.D : Pour le moment cela n'est pas possible. En revanche il y a des discussions en cours pour lancer ces travaux. Je ne sais pas si cela va être fait. Cela intéresse beaucoup de gens. Il y a de grandes chances pour que cela voit le jour mais pour le moment c'est encore trop tôt.
Traditionnellement le contenu d'un site Internet conforme aux standards doit pouvoir être accessible sur n'importe quel écran. Pourtant beaucoup de sites proposent une version spécifique généralement localisée sur une adresse de type m.domaine.com. Qu'en pensez-vous ?
F.D : Il y a une version idyllique et la réalité. De facto, les standards doivent imposer une façon de faire les choses. La pratique est différente dans la mesure où il y a des spécificités par plateformes qu'il faut bien prendre en compte. Je ne reviendrai pas sur les bugs des navigateurs. Tant qu'ils ne sont pas corrigés on ne peut pas utiliser les standards même si on essaie de faire en sorte que ces derniers soient préalablement testés.
Aussi ce qui nous paraît important c'est de faire une base commune qui va fonctionner à peu près partout et à partir de là nous mettons en avant le fait de l'améliorer progressivement pour cibler certaines classes de terminaux plus spécifiquement et donc optimiser l'expérience utilisateur. Donc ca me paraît tout à fait logique d'optimiser mon site pour l'iPhone si 80% des visiteurs arrivent depuis ce terminal ; je ne peux pas les ignorer.
D'accord et sans cette base commune on reviendrait à la problématique d'Internet Explorer et des sites spécifiquement conçus pour ce dernier...
F.D : Oui c'est bien pour cela que la base commune nous est très importante car elle prévoit les choses trans-plateforme dès le début tout en offrant de la flexibilité. Mais il y aura toujours besoin d'ajuster certains aspects, ne serait-ce que parce que web mobile est très vertical et c'est plutôt le contraire sur un ordinateur.
Nous savons qu'il existe des disparités au sein des navigateurs classiques. Observez-vous un phénomènes similaire sur les navigateurs mobiles ?
F.D : Oui. Alors il n'y a pas de différences fondamentales sur les balises HTML standards. Par contre si l'on veut implementer les balises audio ou video, tous ne les prennent pas en charge. Après il y a surtout des différences au niveau du CSS, il y a un profil standard baptisé CSS Profile Mobile spécifiant les propriétés basiques s'affichant sur tous les navigateurs mobiles. Seulement si l'on veut aller plus loin il faut donc savoir que certaines applications ne seront pas compatibles.
Parfois sur un navigateur classique, pour forcer les compatibilités certains utilisent du JavaScript. J'imagine que cette pratique est proscrite sur mobile ?
F.D : Oui. Ce n'est pas proscrit parce que c'est possible mais il faut faire attention. Les téléphones supportent le JavaScript mais il sera beacoup plus lent même s'il y a déjà eu beaucoup de progrès. Mais ca fait des données à télécharger en plus, ça consomme plus de batterie, de mémoire et des choses comme ça. Ce n'est pas proscrit parce que ca serait trop violent. Si vous prenez la bibliothèque JQuery, moi j'aurais du mal à m'en passer parce qu'en tant que développeur c'est quand même super agréable de pouvoir cibler des éléments facilement . Cependant je crois que la librairie zippée fait 34Ko et si la page ne présente qu'un petit appel à JQuery, cela ne justifiera peut-être pas cette charge supplémentaire. Là encore il faut faire la part des choses et essayer d'être réaliste.
Selon vous les éditeurs sont-ils autant impliqués dans le développement de leurs navigateurs mobiles que de leurs versions classiques ?
F.D : Tous les navigateurs classiques de bureau ont un pendant mobile. Mozilla s'y est mis récemment. Ils essaient vraiment d'avoir la même chose sur les deux écrans. Chez Microsoft, la version mobile est toujours celle d'avant, c'est un peu agaçant. Ca serait bien s'il pouvait y avoir une synchronisation entre la version mobile et la version de bureau. Actuellement l'édition mobile est Internet Explorer 7 avec quelques fonctionnalités d'IE8. Apple a aussi quelque chose d'à peu près commun entre les deux, Android est également basé sur WebKit.
Maintenant les éditeurs se rendent vraiment compte que la plateforme mobile est très importante et ils mettent tous l'accent dessus.
Enfin quid des fournisseurs de sites web ou de blogs comme Wordpress. Travaillent-ils avec vous sur les versions mobiles proposées par défaut aux utilisateurs ?
F.D : Non on ne peut pas dire qu'ils travaillent avec nous. J'avais essayé de faire un plugin pour Wordpress, Joomla et Moodle, il y en a quelques-uns. L'un des principaux défaut est que le thème est déployé de manière standard et diffère de la version classique. Ces services n'ont pas été conçus avec le mobile en tête au départ. Donc c'est de l'ajustement après coup, et cela fonctionne jusqu'à un certain point. Wordpress est l'une des plateformes les plus faciles à ajuster.
J'adorerais pouvoir travailler sur des outils spécifiques déployés aux internautes mais je n'ai juste pas le temps. Personne au W3C n'a vraiment le temps de travailler dessus. Il faut pouvoir s'investir mais nous n'avons pas les ressources matérielles.
Je vous remercie