Le débat prend chaque jour un peu plus d’ampleur chez les développeurs entre les partisans des applications natives et les aficionados des Web Apps : ces sites internet qui s’adaptent à tel ou tel terminal mobile et auxquels on accède via un navigateur.
La question du développement de véritables Web Apps se posait encore assez peu il y a quelques années : les Smartphones n’étaient pas encore légions, HTML5 en était encore à ces balbutiements et il était difficile d’offrir une expérience utilisateur probante via un navigateur mobile première génération. Souvenez-vous des premières versions du monde.fr par exemple dans lesquelles il était fort peu aisée de naviguer. La lecture des articles s’apparentait, elle, à un doux calvaire. On parlait alors de sites optimisés, ou l’art de concentrer l’affichage d’un site prévu pour un 17 pouces sur un écran de 4 cm.
Toujours ces dernières années, l’AppStore a offert une nouvelle façon d’accéder et de consommer des contenus multimédia : une icône sur un bureau, on clique et c’est parti. Ca à l’air tout bête dit comme cela mais ça change tout. Si je prends mon cas, j’observe que je fais une utilisation extrêmement réduite de Safari mobile qui est pourtant bien pensé, à la différence d’autres navigateurs sur Smartphones. Accéder à un site, même optimisé pour mon iPhone ne me vient pas immédiatement à l’esprit alors qu’il est si simple de télécharger une application sur l’Appstore, d’y accéder en un clic et de jouir d’une expérience utilisateur pensée en fonction de cet appareil. Je ne souhaite pas faire de mon cas une généralité mais je pense que peu de personnes utilisent intensivement Safari sur leur iPhone. Il y a bien sur une manipulation qui permet de faire glisser sur son bureau une icône correspondant à un site mobile, mais qui s’en sert ?
Donc voilà globalement comment se déroulaient les choses jusqu’à présent : on se servait d’un navigateur depuis son PC ou son Mac et d’applications natives depuis son téléphone.
Seulement, la donne change, les acteurs et les terminaux se multiplient. RIM a fait une belle percée sur le secteur du grand public, Android progresse fortement et Apple se maintient très bien. De petits « anciens-nouveaux » arrivent sur le marché comme Samsung avec Bada, sans même parler de Nokia et Microsoft. Ajoutons à cela l’arrivée de produits hybrides comme l’iPad, à mi-chemin entre téléphone et ordinateur, capables de faire tourner des applications natives mais qui offrent également une expérience du web « traditionnel » tout à fait convaincante.
Le langage HTML 5, quant à lui, s’enrichit de jours en jours laissant entrevoir de belles perspectives même si, à l’heure actuelle, il est toujours en gestation et qu’il n’est pas « officialisé » (le sera t’il un jour d’ailleurs ?)
Confrontés à ce panorama épars, les producteurs de contenus sont naturellement tentés de se tourner vers le développement de Web Apps: un code unifié, modifiable à foison, accepté par toutes les plate-formes. Notons également que des frameworks open source source orientés mobile commencent à montrer le bout de leur nez, comme iWebKit ou JQTouch. Sur le papier, les Web Apps présent donc des avantages : c’est moins cher, plus rapide et plus facile à coder.
Dit comme cela, tout paraît simple et évident mais il nous semble néanmoins que les Web Apps sont, pour l’instant, à réserver à des projets simples (affichage de news, mini-sites événementiels…) et qu’il faudra encore s’orienter vers des applications pour proposer des services ciblés offrant à l’utilisateur une expérience riche. La technologie HTML 5, même si elle permet de plus en plus de développements, n’est ni finalisée, ni standardisée et ne s’approche pas encore des fonctionnalités offertes par un SDK.
Ajoutons à cela qu’il n’est pas évident de coder et de concevoir une Web App qui offre la même expérience utilisateur sur une multitude de terminaux. C’est pourquoi nous nous efforçons de conseiller à nos clients souhaitant mettre en place des services ambitieux mobiles de se concentrer d’abord sur des applications iPhone parfaitement réalisées plutôt que sur des Web App cross-systèmes qui décevront peut-être, quitte à adapter par la suite la solution à d’autres systèmes. Mieux vaut une application iPhone téléchargée 5000 fois et qui serve plutôt qu’une Web App consultée 100 000 fois mais rapidement boudée. Encore une fois, il faut se concentrer sur les usages et mener des études en amont plutôt que de céder à une facilité de surface qui aboutira possiblement à un échec.
Le débat n’est bien sur pas figé : les technologies, les marchés évoluent vite. Le développeur de contenus doit faire preuve de pragmatisme et s’adapter en permanence, en fonction de la maturité des outils existants et des projets à mener.
iSeeds Software propose des services et solutions dédiés aux plateformes mobiles d'Apple (iPhone, iPad...), avec un double positionnement de société de services et d'éditeur.
Bonne analyse.
Il y a aussi le problème de l’accès au web qui n’est pas toujours assuré.
La loi de Murphy étant toujours régulièrement vérifiée, c’est au moment où on en a le plus besoin que ça ne marche pas.
Une application autonome est toujours et partout opérationnelle. C’est agréable pour des applications de loisir, c’est indispensable pour une utilisation professionnelle.
Il faut penser aussi qu’il y a derrière tout cela un débat d’idée sur l’usage des réseaux. Les premiers ordinateurs personnels, dont le tout premier Apple, lutaient contre l’hégémonie d’IBM et des systèmes centralisés. Google rêve-t-il de revenir 40 ans en arrière ?
Bonjour,
J’apprécie également votre analyse, et je tenais à insister sur les points suivants :
- Dans l’univers de la télématique, que ce soit le Minitel de l’époque des années 90, l’audiotel, le Web ou le SMS de l’an 2000, pour arriver jusqu’a l’iPhone et l’iPad, dans toute ces technologies demeure un point essentiel pour la réussite d’un projet c’est qu’on a en général qu’une seule chance : C’est du « one-shot gun ». Si l’on réalise un site ou une application au rabais, bien buggée, avec une ergonomie discutable voir difficilement appréhensible, un design decevant, alors on se grille sur le marché : Non seulement un utilisateur de perdu l’est presque définitivement, mais en plus il vous fera une mauvaise publicité auprès de ses proches.
C’est encore plus vrai sur des terminaux comme l’iPhone et l’iPad. De nombreuses sociétés veulent a tout prix « faire une application iPhone » juste pour « faire bien » et faire plaisir a leur directeur général pour lui démontrer qu’ils sont bien présents sur les nouveaux médias émergents. Jusque là, pas de problème…. C’est en général après que ca se gâte:
Le patron leur donne un budget fixe et faut se débrouiller avec ca. En fait, on commence par la fin « le budget » pour arriver au départ : « L’application ».
Mettre la charrue avant les boeufs n’a jamais donné de bons résultats :
- Avec cette méthode indéfendable et totalement illogique, on obtient des applications au rabais, buggées, à l’ergonomie généralement décevante. Les utilisateurs sont souvent déçus, la désinstallent, et en parleront a leur entourage en disant « T’as vu l’appli de cette boite, je m’attendais a une truc super et ils nous ont pondu une grosse merde qui sert à rien. »
Sur iPhone, iPAd et autres terminaux mobiles, ce sont les utilisateurs qui sont les juges. Vous avez beaux investir des millions en publicité, cela boostera peut etre vos téléchargements, mais les gens bouderont l’application et tout votre investissement publicitaire sera rapidement perdu pour se retourner finalement contre vous !!! comble du comble : il y a un effet boomerang : Les millions de gens incités par une campagne de pub a prendre votre application parceque vous l’avez vendue comme révolutionnaire et géniale seront demain autant de gens décus, voir pire, si l’application était payante, qui auront l’impression de s’être fait volé et là ils ne vous le pardonneront pas : La sanction tombera sur les commentaires dans l’app store et votre application terminera comme certaines sociétés bidons que l’on voit parfois trainer en bourse et qui n’ont rien a y faire et que l’on appelle les « Peny stocks ». Bref, la réputation de votre application, et de la marque sous-jascente seront sérieusement endommagées et pour longtemps, et reconquerir la clientèle pour « corriger le tir » de votre erreur de stratégie vous coutera 10 ou 100 fois plus que d’avoir procédé dès le départ de façon logique.
En tant que développeur iPhone / iPad, je considère qu’on ne peut pas réussir dans ce domaine si l’on met la charrue avant les boeufs.
Tous ceux qui ne pensent qu’a faire une application avec le budget fixe qu’on leur a donné se fourvoient.
Non seulement il y a une guerre sans merci entre certains prestataires de service qui réalisent des applications iPhone et qui ont eu tendance a faire casser les prix : Résultat, on vous promet une application performante, réalisée en un temps record, et on sait très bien que ce n’est pas possible à la sortie. Bref, ceux qui s’amusent à casser les prix sur le marché de la prestation de service de développement d’applications mobiles encouragent ceux qui sont déjà « adeptes de la stratégie qui consiste faire une application à partir d’un budget » à poursuivre dans leur erreur. Quand vous additionnez ces deux phénomènes, les résultats sont catastrophiques.
Serait-ce la faute à une sorte de course au productivisme effrénée ? Si tel est le cas, on tombe vraiment dans le domaine de l’absurde car c’est scier la branche sur laquelle on était assise.
Si j’ai un conseil, un bon conseil a donner à tous ceux qui veulent être visible sur mobile :
1) Ne pensez surtout pas votre application en fonction d’un budget, vous vous planterez.
2) Revenez aux fondamentaux : Posez vous d’abord la question de savoir ce que les utilisateurs veulent : Ils veulent qu’on leur rende service dans les meilleurs conditions possibles. Et les utilisateurs de mobiles ont un profil bien particulier, surtout les adeptes d’Apple : Ils sont particulièrement exigeants sur la qualité, et ils veulent une ergonomie irréprochable, intuitive, originale, ils veulent être surpris, mais en bien !
3) Ne travaillez plus avec des sociétés ou des prestataires ou Freelance qui cassent les prix : Ce n’est pas la donne stratégie de sélection. Sélectionnez plutôt des développeurs d’expérience, passionnés par la télématique et les télécom, qui s’engageront sur la qualité de votre application et qui la feront avec amour et passion, et qui vous guideront pour penser avec vous le meilleur service que vous pourriez offrir a vos utilisateurs, et la meilleur façon de le faire. (Et qui proposeront en plus des garanties en terme de maintenance corrective, préventive, curative).
4) Travaillez plutôt avec des indépendants, et en mode régie, car la relation sera beaucoup plus facile, et le forfait n’est pas vraiment adapté à ce type de développements.
5) Considérez qu’il n’y a pas que la programmation en tant que tel, il y a aussi toute l’expérience du monde de la télématique a prendre en compte. J’ai vu beaucoup de clients qui voulaient une application iPhone et qui m’ont proposé un cahier des charges qui aurait abouti a une application inutile, même si elle avait été bien programmée dans les règles de l’art. Bien au delà de la programmation, il y a donc une prestation de conseil auprès de votre développeur qui ne doit pas seulement vous programmer votre application, mais aussi réaliser, avec vous et les informations que vous lui communiquerez, ainsi que votre stratégie, toute une analyse de vos véritables besoins en terme d’application mobile. Il me parait indispensable d’inclure un développeur d’expérience, passionné et créatif dans la phase de spécification de votre application : Il connait bien mieux que vous les tendances, les erreurs à ne pas faire, les bons réflexes, il connait aussi parfaitement toutes les limites de la machine, et tout son potentiel… et ses défauts.
6) Il faut impérativement des créatifs dans votre équipe de brain storming pour la définition des spécifications et du cahier. Il faut également inclure un graphiste / dessinateur créatif et passionné.
7) Cette activité de brainstorming, de spécification, et de définition du cahier des charges est essentielle. Je vous conseil vraiment de la faire tel que je vous l’ai décrit. Et elle doit être facturée par le graphiste et le prestataire qui fera l’application car cela correspond vraiment à une activité de conseil indispensable à la réussite de votre projet.
A partir de là vous pourrez commencer a calculer un budget, et éventuellement renoncer à certaines options si vous le souhaitez.
L’important est de savoir ce que l’on veut, et pourquoi, pour ensuite se donner les moyens d’atteindre ce but.
Il faut vraiment considérer une application iPhone / iPad comme un investissement.
Et comme dans tout dans la vie, on en a toujours pour son argent.
Et mieux vaut payer plus cher au départ, et bien prendre son temps de bien faire les choses… Plutot que de s’imaginer qu’avec trois francs et si sous en 15 jours vous arriverez à faire mieux que ceux qui auront dépensé deux ou trois fois plus d’argent et de temps pour faire un « bon » produit dès le départ…
Frédéric JOUVIN.
@Philippe : la partie dépendance au réseau est effectivement à prendre en ligne de compte dans la réflexion. Vous parlez de débat d’idées sur l’usage des réseaux et je pense que l’on peut même parler de guerre ouverte à l’heure actuelle
.
En sortant un tout petit peu du sujet : j’ai vu passer quelques articles sur des constructeurs de téléphones qui poussent à fond derrière les web apps, ce qui est somme toute logique car ils ont raté le train des applications.
@Frédéric : merci de rappeler les bonnes pratiques et les fondamentaux.
A propos des utilisateurs déçus par des applications, je viens d’acquérir un iPad et je crois que les commentaires sur certaines applications sont encore pire que pour l’iPhone. Certains sont peut être aller un peu vite en besogne pour sortir des programmes dès la sortie de l’appareil et c’est parfois raté. Comme vous le dites : les conséquences vont être à coup sur être néfastes.
Pascal
Bonjour,
Le choix n’est pas binaire ! Il est ternaire : native, webApp ou hybride !
Je vous fait part de mon expérience récente sur ce sujet.
Il y a quelques mois, bien que cela ne soit pas mon métier, je me suis lancé dans le développement d’applications pour iPhone.
Assez rapidement j’ai fait le choix de développer des applications dites hybrides : c’est à dire une webApp emballée dans une application « native ».
En résumé : vous faites une webApp, avec du html, du css, du javascript, de l’ajax, et au choix du jQuery et du jQtouch et vous mettez le tout derrière 4 lignes de code en Objectif C pour obtenir finalement une application « vendable » sur l’appStore.
Les avantages de ce mode de développement sont :
- vous bénéficiez de toutes les ressources internet autour du javascript, html et css et autres framework associés.
- vous pouvez bénéficier de la puissance maximale du terminal et diminuer les temps de réponse en mettant le maximum de fichiers ou de bases de données en local,
- vous pouvez tirer partie des remarquables fonctionnalités du webkit et faire des animations d’excellentes qualité,
- vous pouvez réutiliser une bonne partie du code pour l’adapter à d’autres plateformes, pour un usage offline ou online,
- la mise en oeuvre immédiate des fonctions GPS.
Les inconvénients sont :
- une intégration moins aisée avec les fonctions natives du terminal qui nécessitent le recours à des frameworks tels que Quickconnect, PhoneGap ou autre (vibreur, accès aux contacts, et autres ressources partagées).
- des optimisations de codage html, css et javascript indispensables pour obtenir des vitesses d’affichage et des temps de réponse acceptable.
- une mise au point et un debug délicats nécessitant de multiples outils : inspecteur web Safari, dashcode, firebug, … Xcode, l’outil de développement des applications natives étant inexploitable pour le debug javascript.
- des temps de réponse et des possibilités non adaptés à des jeux massivement graphiques.
Finalement,
Personnellement, j’ai pris beaucoup de plaisir a utiliser ce mode de développement, car il rassure sur sa réutilisation et son extension à d’autres plateformes mobiles.
C’est un mode de développement qui me semble très bien adapté au monde de l’entreprise.
Si vous voulez avoir une idée sur ce qu’on peut faire dans le style « webApp embarquée dans une applicaion native », vous pouvez jettez un coup d’oeil à mon application « Secourir » sur l’aapStore.
Tout en réalisant une action « citoyenne », l’objectif était ici de voir si il était possible de :
- faire rentrer 90 pages A4 dans un format iPhone avec un enrichissement dans la navigation,
- d’apporter plusieurs modes de lecture possibles,
- de coder un « savoir faire métier » utilisant un système de questions/réponses avec la possibilité d’accéder à un référenciel documentaire complet,
- le tout OFFLINE.
NB : cette application utilise jQuery, jQtouch, 260 fichiers html, 930 fichiers graphiques, et quelques milliers de lignes javascript.
A quelques optimisations près, je pense aujourd’hui avoir atteint mon objectif principal.
Thierry Gaillot