"Un site web adapt au mobile, un site web mobile donc, proposera forcment la mme er gonomie quel que

soit le terminal cible (poste de travail, smartphone, tablette, TV connect, etc.) ce qui est souvent dcri par les utilisateurs qui attendent maint enant que l ergonomie soit adapte leur smartphone ou leur tablette." Il faut peut-tre dfinir ce que signifie ergonomie pour vous : vous parlez probable ment d'un style d'interface commun sur toutes les plateformes opposer un style i OS, un style Android, etc. Ecrire que l'ergonomie est identique quel que soit le terminal cible en citant TV, desktop, tablette et smartphone est curieux : un s ite en responsive design va s'adapter aux diffrentes tailles d'crans et son ergono mie varie. "Une application hybride encapsule des composants web, cependant, l ergonomie de l a pplication peut tre compltement adapte au terminal cible." Utiliser du contenu web dans un webview ne va pas le rendre adapt la plateforme s ur laquelle l'application s'excute. Seule la partie native de cette application h ybride adhrera facilement aux codes ergonomiques de l'OS. Concernant l'intgration de contenu web dans les apps, a a un sens pour les FAQ, l' aide et du contenu priphrique. Mais afficher des news ou un formulaire avec un web view relve du point ci-dessus : on s'attend une exprience native ou pas ? Avez-vou s dj compar la ralisation et l'ergonomie finale d'un formulaire complexe multi-plate formes en HTML5 d'un ct et avec des dclinaisons natives par plateforme de l'autre ? Si oui, il serait intressant que vous laboriez dessus. Quand vous parlez des "cots d'implmentation", on parle de quelle conomie rellement : dveloppement, maintenance ? Si vous ne pouvez pas la quantifier ou donner un ord re de grandeur... Graldine : "L usage du HTML5 se cantonne aux fonctionnalits encore non couvertes par la partie native" Des "fonctionnalits" non couvertes par la partie native ? Je pense qu'on parle pl utt ici de la possibilit de modifier de la logique applicative et l'UI en utilisan t du HTML5 en l'opposant la ncessit de mettre jour une application utilisant exclu sivement du code natif. Ce sont deux paradigmes diffrents qui ne se rejoindront p robablement jamais (aucun code natif ne peut tre charg la vole sur une plateforme c omme iOS selon les rgles d'Apple). Il reste possible possible de rendre paramtrabl e la structure d'une application, mais on s'loigne trs rapidement de la maintenabi lit et de la simplicit. J'estime que c'est une spcificit de Facebook qui aime faire des modifications incrm entielles comme sur le web. Et l'utilisation du natif va de facto fixer la struc ture et l'apparence d'une grande partie de leur application. Je trouve dommage que votre billet argumente peu et n'illustre pas par des exemp les. Invoquer Facebook est un peu facile, un article ralis 1 an plus tt aurait tout aussi bien pu faire l'apologie de leur stratgie hybride.