Accueil Services Magazine Contact

La fragmentation du web est un grand défi pour les entreprises présentes sur le web

Publié par Chris le Samedi, 26 Mars 2016

Avec l’arrivée des montres connectées, ce qui était une contrainte est maintenant devenu un vrai souci : le web est fragmenté en plusieurs formats très distincts. Sites web, présences sociales, newsletters, applications iOS, Android, Windows, TV connectée et maintenant, smartwatchs.

Ne nous y trompons pas, les smartwatchs ont un format particulièrement intéressant grâce à leur faculté à toucher directement l’utilisateur par micro vibrations (ou taptic engine). Probablement, la solution la plus intéressante en terme de push marketing, mais les applications pour montres connectées demandent également de repenser le contenu et l’interaction avec l’utilisateur. Plus intime, la notification au poignet est également plus efficace, mais plus difficile à appréhender. Quel type de notification mérite d’être reçu au poignet? Comment permettre de réagir sans clavier?

La montre et la TV connectée sont probablement les formats les plus intéressants, à première vue, mais d’autres objets connectés méritent qu’on s’y attarde comme les Google Glass qui pourraient refaire une belle entrée et imaginez une balance connectée qui disposant d’une API ouverte? Quelle belle opportunité pour Weight Watchers ou Danio de toucher le client potentiel au bon moment?

Et quoi de mieux qu’un réfrigérateur connecté pour Aldi ou votre livreur de pizza? Imaginons même de nouveaux business, un frigidaire connecté sponsorisé. En partant du principe que de plus en plus de personnes vont acheter leurs courses en ligne dans les prochaines années pour se faire livrer chez elles le soir après le travail, acheter un frigo connecté moins cher chez Carrefour, mais avec leur « store » intégré n’est pas quelque chose d’insensé.

Mais voilà, être présent sur tous ces formats aurait un coût de développement et de maintenance que seul les multinationales peuvent se permettre il est donc temps de remettre de l’ordre dans la cacophonie produite par ces multiples langages et formats de données, disposer de hubs qui regroupent toutes ces plateformes, à l’image de l’email qui est compatible entre tous les fournisseurs et tous les périphériques.

Repenser la façon dont on conçoit les apps:

Windows a longtemps dominé la sphère informatique, si bien que programmer s’est limité souvent à coder pour Windows même si dans le milieu du libre, on préfère coder en multiplateforme.

Mais la plateforme n’est plus un problème sur le web où les sites tournent sur un serveur. Les développeurs web choisissent la plateforme sur laquelle ils vont coder (IIS, Apache, NodeJS,ColdFusion…) et ils se sont habitués à concevoir des webapps à leur propre sauce. Ainsi, certains seront plus à l’aise en flash, en JS, en HTML5, en .Net, en PHP, en Ruby, en Python, en … soit, s’il existe autant de langages et de façon d’arriver au même résultat sur le web, c’est avant tout par ce que sur un site web, il faut tout coder, du player audio au drag&drop, et l’HTML5 commence à peine à offrir des solutions intégrées dans le navigateur pour quelques fonctions récurrentes.

Développée à sa sauce pour une seule plateforme est une mauvaise habitude, que Google, Microsoft, Adobe ont déjà essayé de corriger avec leurs solutions propres.

Si les logiciels et les sites sont développés pour une seule plateforme, il ne faut pas s’étonner si les apps suivent le même chemin. C’est une erreur, il faudrait normaliser tout ça.

L’app peut être divisée en trois parties distinctes : Les datas, les fonctions et l’interface (UIX). Les datas peuvent être les mêmes sur toutes les apps d’un fournisseur grâce au cloud, mais on peut créer des standards d’échanges de données comme le RSS en Json par exemple. Avec des standards fixés, on pourra plus facilement gérer la seconde partie, les fonctions. On peut standardiser cette partie, partir du principe que 95% des fonctions d’une app sont présentes sur de nombreuses autres apps. Reprenons l’exemple du RSS, parser un tel flux ne devrait plus demander de travail de développement. Enregistrer un fichier en MP3, éditer une photo, c’est pareil, il faudrait pouvoir profiter plus facilement des outils présents dans le device.

On devrait pouvoir coder sur toutes les plateformes avec un Framework unique et créer des plug-ins pour les fonctions non fournies. Ainsi, on pourrait sous-traiter le développement de plug-ins dans des langages spécifiques (Cocoa,c++,Js,Java,…) sans pour autant externaliser tout le développement de l’app.

La dernière partie, l’interface ne serait finalement que des thèmes qui ne nécessiteraient que des connaissances réduites en programmation comme c’est le cas dans le Web avec le CSS3.

Je ne vais pas vous le cacher, il existe des plateformes qui tentent de permettre ce genre de chose entre Android et iOS. Cordova (PhoneGap), par exemple, permet de développer des apps iOS et Android en HTML/JS, mais ce n’est pas la norme, probablement par ce que ce n’est pas optimal pour les performances, que c’est un peu bricolé et qu’un développeur va généralement considérer ces plateformes comme du gadget. Sans oublier que le développeur a son ego, il n’aime pas les plateformes qui génèrent le code à sa place.

Mais c’est une nécessité, il ne faudra plus penser à développer une app iPhone ou Android, mais développer pour un parc de devices, c’est comme ça qu’on arrivera à optimiser les coûts de développement et maintenance, et c’est ainsi que l’on pourra développer pour la multitude d’objets connectés qui débarquent.

L’idée n’est pas neuve du tout, cela fait longtemps que le secteur du jeu vidéo développe de cette façon. Unreal Engine, Unity Engine, Jade Engine, MT Frameworks, Rage, pour ne citer que les plus connus, sont des frameworks multiplateformes, l’industrie du web et apps ferait bien de s’en inspirer.


A propos de Chris Project Manager Digital. Ex Digital Developer et UIX designer, Ex SEO et Social Media Coordinator pour les medias.
Partagez cette page sur les médias sociaux !