Le Raspberry PI et la chaudière... WTF ? (épisode 2)

Sécurité des applications
Le Raspberry PI et la chaudière... WTF ? (épisode 2)

Suite du 1er épisode où je vous parlais de mon choix entre application native ou HTML pour développer le système de pilotage à distance de ma chaudière à gaz…

Revenons un peu sur les critères déterminants pour mon projet.

La « Sexytude » (Expérience utilisateur ou « UX » pour les puristes) :

Tant qu’on ne pourra pas jouer à GTA5 en Javascript, on partira du principe que les applications mobiles auront toujours une longueur d’avance sur le HTML5 et autres technologies « Web ».

Dans un contexte de développement d’applications professionnelles « généralistes », l’avantage de l’application native n’est pas si évident que ça. Disons en tout cas que ce sera très dépendant de la finalité de l’application : Pour une consultation de compte en ligne, le HTML5 me semble parfaitement adapté – pour une application « marketing » ou embarquant du contenu multimédia à outrance, le natif sera bien plus approprié.

Pour les applications grand public nécessitant des accès aux API systèmes (appareil photo, lecteur d’empreintes, …) le natif aura toujours une longueur d’avance (que le HTML5 finira peut-être par rattraper un jour, exemple de la localisation GPS accessible aux WebApp).

Avantage donc aux applications natives, mais tout dépend de l’usage.

La Performance :

Ca sent le Troll et ce n’est pas important pour mon sujet, donc je passe rapidement. On notera quand même le choix de LinkedIn de quitter le HTML5 au profit d’une application native, comme Facebook l’avait déjà fait.

Les motifs invoqués sont

  • Le problème de consommation de mémoire côté serveur ; augmentation consécutive à l’explosion du nombre d’utilisateurs
  • La nécessité de disposer d’animations graphiques plus fluides (cf. le point précédent).
  • Le fait que les outils de développement / débogages sont plus aboutis sur les plateformes natives, ce qui est essentiel dans la recherche de performance (et de sécurité accessoirement).

Voilà un argument intéressant : effectivement, les environnements de développement intégrés pour les applications natives sont bien plus avancés et offrent de nombreux outils indispensables pour le développeur – ces outils ne sont pas aussi aboutis pour du développement Web « classique » - que ce soit HTML5 ou autre (Pour être précis, les outils existent, mais ne sont pas nativement intégrés aux IDE et sont parfois très complexes de prise en main).

Le déport de certaines fonctionnalités sur le terminal est donc un choix judicieux.

Le coût de développement / déploiement (éventuellement multiplateformes) :

Je pars du postulat qu’il est beaucoup plus facile d’apprendre HTML5 comparé à l’apprentissage des SDK natifs. Je fais une exception pour le SDK Microsoft qui est particulièrement facile de prise en main (Windows 8).

Quoi qu’il en soit, ça coûtera à priori toujours plus cher de développer x applications pour x systèmes d’exploitation que de développer une application HTML5 qui sera, par définition, cross-platform (même s’il existe 15 browser différents, le support des 5 premiers sont suffisants pour couvrir la quasi-totalité des utilisateurs). Cet à-priori n’est plus si l’on utilise les environnements de Cross compilation présentés ci-dessus, mais leur prise en main nécessite un apprentissage certain (le Framework en général et la maitrise des SDK natifs en particulier).

Si la plateforme cible est unique (Android pour moi), idem : Le coût de prise en main du SDK Android ou de tout autre SDK nécessite une montée en compétence. La différence de coût restera toutefois moins importante et sera identique au HTML5 une fois la montée en compétence réalisée… sauf si le SDK monte brutalement de version – personne ne maitrise cela (à part les fabricants…).

Côté HTML, les évolutions existent également, mais la transition est beaucoup moins « violente ». Rappelons également que HTML5 est en passe de devenir un standard : les applications HTML5 seront donc par définition plus ouvertes et plus interopérables que leur concurrentes natives. Reste que l’interopérabilité peut se faire parfois dans la douleur (certains navigateurs étant plus susceptibles que d’autres).

Avantage probable au HTML5, en tout cas dans ma vision court-terme.

Contrôle du parc applicatif / des mises à jour de logiciel :

Poursuivons la réflexion et partons du principe que je mette mon application à disposition de la communauté…

En cas de découverte d’une faille de sécurité au sein de l’application HTML, la WebApp pourra être immédiatement mise à jour – et tous mes périphériques clients bénéficieront immédiatement de la protection. Les applications natives quant à elles, doivent attendre la validation d’Apple, de Samsung et des autres avant d’être publiée – et vous n’avez aucune garantie sur le fait que les utilisateurs vont effectivement appliquer la mise à jour.

Pour des raisons que j’ignore (en tout cas pas pour des raisons de sécurité), certains ne souhaitent pas passer par les stores (pour Android) – mon argument ci-dessus ne tient donc partiellement plus : ils peuvent mettre de nouvelles versions en ligne quand ils le souhaitent et proposer aux utilisateurs une mise à jour lorsque nécessaire (sans garantie que l’utilisateur ne l’applique).

Sauf que, voici ce que nous proposent certains pour installer leurs applications « en dehors des stores » :

  1. Merci de modifier les paramètres de votre téléphone
  2. Aller dans "Paramètres"
  3. Aller ensuite dans "Applications / Sécurité"
  4. Autoriser votre téléphone à installer des logiciels en provenance de sources inconnues
  5. Installer l'application...STOP !

Dites-moi que je rêve ! On me demande de désactiver le peu de protection nativement présente dans mon téléphone pour installer l’application ? Et je devrais payer pour l’utiliser ? Et qui me dit que j’installe bien leur application et pas une version malveillante ? Bref…

Sauf à équiper les périphériques de vos utilisateurs (donc exit l’internaute lambda) de solutions MDM (Mobile Device Management) et/ou MAM (Mobile Application Management), le contrôle est impossible.

Avantage incontesté au HTML5 et aux applications hybrides où le contenu est en ligne et dont on peut en contrôler les accès.

Et qu’en est-il des volets monétisation et sécurité pure ? La suite au prochain épisode.

Pour (re)lire l'épisode 1, cliquez ici.

Jérémie Jourdin, Responsable R&D, Advens