Alors que la barre des 500.000 unités vendues vient d’être franchie par l’iPad, je m’interroge sur l’impact que cette machine pourrait bien avoir sur le marché, ou plutôt sur les éditeurs de sites web.
Tout à commencé avec l’iPhone : Belle machine, système d’exploitation robuste et certainement la meilleure expérience de surf sur le web en situation de mobilité (du moins à la date de sa sortie). Résumons une longue argumentation en disant que pour un usage d’appoint, l’iPhone et son Safari remplit largement sa promesse. Bien évidemment vous ne passeriez pas des heures à surfer sur le web avec votre iPhone car ce smartphone n’a pas été conçu pour ça. D’autant plus qu’il existe une myriade d’applications proposant une expérience plus riche et plus immersive. OK, jusque là tout va bien.
Prenons maintenant le cas de l’iPad : Belle machine, même système d’exploitation, même navigateur. Surfer sur le net avec un iPad veut donc dire être soumis aux mêmes limitations (pas de Flash, pas de survol avec la souris). Là c’est tout de suite un peu plus gênant dans la mesure où l’iPad est vendu comme l’avenir de l’informatique domestique, le remplaçant de votre ordinateur (avec son clavier et sa souris).
Passée la première prise en main (où l’impression générale est très bonne), l’iPad se révèle au final un peu décevant pour surfer le web, pour les limitations que nous lui connaissons. Réponse d’Apple : « C’est la faute des éditeurs de sites qui ne sont même pas foutus de sortir des version iPad-ready« .
Exemple de site optimisé pour l’iPad
Nous avons mis une dizaine d’année à nous débarrasser de la logique du « Site optimisé pour XYZ« et Apple voudrait nous faire replonger dedans ? Oui et non. Oui parce qu’une compatibilité HTML5 suffit pour être « iPad-ready » (ils se cachent donc derrière l’argument des standards web). Non car les éditeurs ont aussi la possibilité de sortir une application (en fait un widget).
La tentation est grande de se lancer dans la confection d’une application pour plusieurs raisons :
- L’expérience utilisateur est parfaitement maîtrisée ;
- L’attention de l’utilisateur est concentrée ;
- Elle est disponible en mode déconnecté.
Par contre il y a des contreparties à ne pas négliger :
- Vous devez soit apprendre le bon langage (Objective C), soit sous-traiter la réalisation à un spécialiste ;
- Vous devez faire approuver votre application pour qu’elle intègre l’App Store d’iTunes ;
- Vous devez vous plier au mécanisme de mises à jour imposé par Apple ;
- Vous devez vous assurer que l’application est compatible avec le format iPad ;
- Vous devez développer autant de version de l’application que vous ciblez de smartphones.
Autant vous dire qu’il faut y réfléchir à deux fois avant de lancer votre application iPhone / iPad car il y a des coûts cachés. C’est effectivement une très bonne chose que d’être présent sur l’un des panneaux de l’écran d’accueil de l’iPhone / iPad (qui fonctionne comme des bookmarks), mais le ROI est loin d’être probant.
Autant le développement de widgets et autres micro-applications a été grandement simplifié / viabilisé par des technologies comme AIR, autant pour les applications mobiles tout reste à faire. D’autant plus que le marché des smartphones évolue vite (iPhone OS still dominates mobile web; Android on the way up) et que celui des touchbooks devraient aussi être amené à bouger avec l’arrivée de machines propulsées par Android.
Je suis intimement persuadé que ce phénomène de widgetisation du web (« développez une application pour mes machines et tout se passera bien« ) est néfaste car elle disperse les ressources et donc les budgets des annonceurs. Je suis beaucoup plus partisan d’une approche raisonnée qui consiste à développer une version smartphone d’un site web plutôt que de se lancer dans le développement de x versions d’une application mobile (pour iPhone, Android, Symbian, BlackBerry…).
Cette solution permet de bien mieux maîtriser les coûts de développement, de s’affranchir des contraintes de déploiement / mises à jour, de cibler un panel bien plus large de smartphones, de capitaliser de l’expérience sur une technologie pérenne (HTML 5). Illustration avec la version mobile de Twitter :
La version mobile de Twitter
Même si les possibilités par rapport à une application sont restreintes, le ROI est imbattable. Peut-être que la combinaison gagnante est de proposer une version mobile de votre site web ou service en ligne et de proposer une application payante avec des services à valeur ajoutée (la grande question étant : « Qu’est-ce qu’un service à valeur ajoutée« ).
Donc au final, je trouve cette idée de sites web « iPad-ready » complètement rétrograde. Mais transposée en « Smartphone-ready » ou en « Touchbook-ready« , là ça devient beaucoup plus intéressant (surtout avec une redirection automatique vers la bonne version).
Bon en fait la combinaison réellement gagnante serait d’avoir un site web avec des versions smartphone / touchbook et une application mobile payante mais reposant sur un code-source unique. C’est en quelque sorte ce que promet Adobe avec son Open Screen Project et la possibilité dans CS5 de compiler une application Flash en une application iPhone. Le nirvana des Rich Mobile Applications, nous y sommes presque !
À moins que tout ceci ne soit remis en cause avec le lancement ce soir de la V.4 de l’iPhone OS…
Mise à jour (9 avril 2010) : Voilà c’est fait, Apple vient d’inclure une close dans sa licence pour interdire l’utilisation du compilateur Flash de CS5. D’un côté je me dis qu’il faut des mesures extrêmes comme celle-là pour garantir une expérience utilisateur cohérente sur l’iPhone, d’un autre je pense que celà complique la tâche des annonceurs et des éditeurs d’applications. Les produits d’Apple et d’Adobe font partie de mon quotidien professionnel depuis des années et je m’attriste de voir ce conflit s’envenimé…
Voir les 19 commentaires