http://www.interfacesriches.fr Toute l'actualité des interfaces riches (Flash, HTML5, 3D...) Mon, 22 Jul 2013 07:48:18 +0000 fr-FR hourly 1 http://wordpress.org/?v=3.5.3-alpha L’adoption de NativeClient passera par les jeux… et la bureautique http://www.interfacesriches.fr/2013/02/25/ladoption-de-nativeclient-passera-par-les-jeux-et-la-bureautique/ http://www.interfacesriches.fr/2013/02/25/ladoption-de-nativeclient-passera-par-les-jeux-et-la-bureautique/#comments Mon, 25 Feb 2013 12:04:46 +0000 Frédéric Cavazza http://www.interfacesriches.fr/?p=5356 Lancé à la fin de l’année 2008 en catimini, NativeClient évolue sous le radar depuis un certain nombre d’années. Plusieurs raisons expliquent le peu de moyens déployés par Google pour communiquer sur son produit : une technologie complexe à expliquer (donc des bénéfices difficiles à appréhender pour les non-initiés) et une crainte de voir se reproduire la déroute de Google Wave, qui était pour tant un produit exceptionnel. Bref, NativeClient est la technologie “révolutionnaire” de Google dont personne ne connaît l’existence, mais les choses pourraient bien changer par le biais d’une acquisition récente.

Si j’avais été très sceptique au lancement de NaCl (Native Client, la technologie RIA de Google qui risque de faire long feu), c’est que les conditions de marché n’étaient pas très favorables et que les équipes de Google n’ont pas non plus dévoilé une feuille de route parfaitement claire et cohérente. En résumé : l’intérêt de faire tourner du code natif dans le navigateur en 2008 était plutôt limité. Impression confirmée il y a deux ans lors d’un second lancement officiel (Pourquoi Google a deux ans de retard avec Native Client). Je vous rappelle qu’à cette époque nous étions en pleine montée en puissance des terminaux mobiles et que le gain de performance promît par NaCl pour les processeurs x86 n’était encore une fois pas très vendeur (HTML5 était nettement plus sexy).

Nous sommes maintenant en 2013 et les terminaux mobiles ont envahi le monde (smartphones, tablettes, ultrabook…). Quasiment la totalité des internautes est équipée de terminaux mobiles et les utilisateurs veulent accéder aux mêmes services qu’avec leur ordinateur, ils ont donc besoin de puissance et le récent portage de NaCl sur les processeurs de famille ARM prend tout son sens (Native Client support on ARM). Grâce à NativeClient, les développeurs ont donc la possibilité de créer des applications en code natif qui exploitent directement les ressources de la machine (processeur et puce graphique) sans déperdition de puissance. La promesse est belle, mais elle est difficile à tenir, car la puissance se fait au détriment de la simplicité. En d’autres termes, il faut être talentueux et motivé pour mettre en oeuvre la technologie et profiter de ses bénéfices. D’autres éditeurs ont fait la même promesse, mais il semble que NaCl soit mieux cadré et plus rigoureux (Google Chrome Native Client compared with plugin or extension).

La stratégie de Google a donc été dans un premier temps de mobiliser la communauté des développeurs de jeux pour démontrer l’intérêt de NaCl : Games, apps and runtimes come to Native Client. Un certain nombre de jeux et démonstrations techniques sont donc sortis ces derniers mois, avec des authentiques succès comme AirMech (cf. AirMech Review).

L'interface de AirMech sous Chrome
L’interface de AirMech sous Chrome

Il existe aujourd’hui une petite vingtaine d’applications disponibles dans la galerie et les avis semblent converger : NaCl ouvre de formidables opportunités, mais requiert de gros efforts (The Ins and Outs of Native Client et The trouble with Google Chrome’s Native Client). Qu’à cela ne tienne, ils ont tout prévu : Gaikai ported to Chrome Native Client, which is a bigger deal than it sounds.

Tout ceci est très intéressant, mais les jeux en ligne sont un marché limité, même si on l’étend aux terminaux mobiles. La seconde étape du plan de Google est maintenant de s’attaquer au marché des applications d’entreprise où il y a de bien plus grosses sommes d’argent en jeu : Google Ports Quickoffice To Chrome Using Native Client, Will Get Full Editing Features In About 3 Months. L’arme secrète de Google est donc de proposer un environnement “léger” de création et d’édition de documents bureautiques exploitant la puissance de NaCl et distribué sur iOS, Android et Chrome. Autant des réalisations comme AirMech permettent de crédibiliser NaCl auprès des développeurs d’application, donc une petite audience ; autant QuickOffice est la clé d’entrée ultime de Chrome dans le monde de l’entreprise.

L'interface de QuickOffice sous Android
L’interface de QuickOffice sous Android

J’ai toujours été sceptique quant au succès de NaCl, mais son portage sur les processeurs de famille ARM (qui équipent l’ensemble des terminaux mobiles) et cette future nouvelle version de QuickOffice changent carrément la donne. Je suis persuadé que la prochaine conférence Google I/O le mois prochain sera l’occasion de donner un second souffle à NativeClient et surtout de déployer un levier de différenciation imparable. L’enjeu étant bien plus important que des jeux en ligne plus rapides (un autre article en préparation sur ce sujet).

]]> http://www.interfacesriches.fr/2013/02/25/ladoption-de-nativeclient-passera-par-les-jeux-et-la-bureautique/feed/ 1 Pourquoi Google a deux ans de retard avec Native Client http://www.interfacesriches.fr/2011/02/22/pourquoi-google-a-deux-ans-de-retard-avec-native-client/ http://www.interfacesriches.fr/2011/02/22/pourquoi-google-a-deux-ans-de-retard-avec-native-client/#comments Tue, 22 Feb 2011 09:46:29 +0000 Frédéric Cavazza http://www.interfacesriches.fr/?p=1040 Annoncé de façon très discrète en 2009, Native Client fait à nouveau parlé de lui avec l’annonce d’un lancement imminent : Native Client: Getting Ready for Takeoff. Il a fallu visiblement 2 ans aux équipes de Google pour finaliser la technologie et surtout blinder les aspects sécurité. J’avais à l’époque de l’annonce exprimé mon scepticisme dans un article qui critiquait la façon dont cette technologie à été présentée : Native Client, la technologie RIA de Google qui risque de faire long feu.

NaCl n’est pas une technologie de RIA, donc n’est pas concurrent de Flash

Pour résumer une longue et laborieuse explication, Native Client est un module de Chrome qui permet d’exécuter du code natif. L’enjeu de cette technologie est d’améliorer les performances des applications en ligne. Quand une application traditionnelle sollicite le processeur de votre machine, il le fait au travers du système d’exploitation (1 intermédiaire). Quand une application en Flash sollicite le processeur, elle le fait au travers du plug-in, du navigateur et du système d’exploitation (3 intermédiaires). L’empilement de ces différentes couches logiciel pèse sur les performances de votre application. NaCl apporte dans ce contexte une solution en proposant un accès direct au processeur via des instructions en C ou C++.

Mais la promesse de NaCl ne s’arrête pas là, puisque ce module vous assure également une parfaite portabilité de vos applications : puisqu’elles sont écrites en C/C++ et sollicitent directement le processeur, elles fonctionnent indifféremment sous Windows, Mac ou Linux (des systèmes d’exploitation qui reposent tous sur l’architecture x86 d’Intel). Donc si l’on résume : meilleures performances, portabilité et souplesse sont les 3 atouts de NaCl. OK, mais tout ceci n’est pas sans vous rappeler les applets Java ou ActiveX ? Je  n’ai pas les compétences pour vous faire une comparaison formelle et argumentée, mais la promesse est très proche.

Ceci nous amène donc à une première observation : NaCl n’est résolument pas une technologie d’interface riche, plutôt un environnement d’exécution d’applications. Espérons que Google profitera de l’annonce officielle pour communiquer de façon moins ambiguë sur ce qu’est NaCl et surtout sur ce que cette technologie n’est pas (un concurrent de Flash ou Silverlight). Précisons au passage que l’idée n’est pas de créer des applications exclusivement avec NaCl, mais plutôt de créer des applications en ligne avec javascript ET des instructions en C/C++ qui seront directement exécutées par le processeur via NaCl.

Flash et Silverlight sont ainsi devenus au fil des évolutions bien plus que des environnements d’exécution, ce sont des canaux de distribution pour contenus à valeur ajoutée. Ces canaux s’appuient sur un écosystème très dense de producteurs, annonceurs, distributeurs… qui ne vont pas changer de technologie du jour au lendemain sous prétexte que les performances sont meilleures.

Pas de NaCl sans Chrome ou x86

NaCl se présente donc sous la forme d’un plug-in pour Chrome. OK, mais Chrome ne représente que 10% du marché. Certes, la progression du navigateur de Google sur l’année 2010 est spectaculaire, mais ces deux principaux concurrents (Microsoft et Mozila) vont faire un retour en force dans les prochaines semaines avec la sortie de Firefox 4 et Internet Explorer 9. Il y a ainsi très peu de chances pour que NaCl soit disponible pour ces derniers navigateurs avant leur sortie officielle.

Est-ce un problème pour Google ? Non pas réellement, car ils ont d’énormes ambitions à ce sujet. Par contre le marché risque d’être refroidi par cette limitation : Google’s Native Client updates to Pepper API, looks set to fragment the Web. D’autant plus que nous avons déjà connu ça avec les technologies citées plus haut (notamment ActiveX).

Autre limitation de taille : NaCl ne fonctionne qu’avec les processeurs à architecture x86. Ce qui veut dire que NaCl ne fonctionnera pour le moment pas sur les terminaux alternatifs qui sont tous basés sur l’architecture ARM. Cette limitation est due au fait que NaCl permet de solliciter directement le processeur, changez de processeur et il faut tout revoir. Une version compatible avec les processeurs de la famille ARM serait en cours d’étude, mais cela revient à reprendre le travail depuis le début (et donc à gérer deux projets avec deux cycles de développement / évolution).

De nombreuses alternatives pour les jeux 3D

Les gains de performances promis par NaCl seraient très appréciables pour les applications qui sollicitent le plus le processeur ou la puce graphique. Outre les logiciels de montage vidéo, les jeux seraient donc les premiers bénéficiaires de ces gains de performances. L’idée étant de pouvoir proposer des jeux 3D dans le navigateur avec le même rendu (résolution, taux de rafraichissement) que les jeux installés sur votre machine. OK, mais Google va être confronté à deux problèmes de taille :

  1. Les jeux récents sont gourmands en puissance de calcul mais également en stockage (ils dépassent tous le Go une fois installés). Il va donc falloir une sacrée bonne bande passante pour télécharger tout ça à la volée !
  2. Il existe de nombreuses alternatives très crédibles pour avoir de la 3D de bonne qualité dans le navigateur : Et on reparle des Rich Internet Games.

En deux ans (l’annonce initiale de NaCl remonte à 2009), les autres technologies de RIA ont ainsi fait des progrès considérables :

À ces technologies-là, il va également falloir rajouter la concurrence des offres de cloud gaming qui sont parfaitement au point : OnLive, Gaikai, Playcast… Donc pour résumer : Google arrive avec deux ans de retard sur le marché du jeu en ligne. Ou du moins : la promesse de performances accrues dans un contexte de jeu 3D n’est plus aussi pertinente qu’il y a deux ans.

L’architecture à 4 couches de Chrome

Malgré tout ce qui a été dit plus haut, NaCl n’en reste pas moins une petite révolution. Le fait de pouvoir exécuter du code natif n’est pas en soi une exclusivité propre à Google (il me semble que Flash permet également de faire ça, mais dans une moindre mesure), mais cette possibilité s’insère dans un contexte beaucoup plus large.

Pour simplifier, “l’architecture Chrome” est composée des couches suivantes :

NaCl est donc la touche finale d’un plan d’ensemble sacrément bien ficelé. Par “bien ficelé“, comprenez ”bien verrouillé“, car sous couvert de projects open source, l’objectif pour Google est de capter et sécuriser des parts de marché. Une fois qu’un utilisateur ou qu’une entreprise met le doigt dans l’engrenage Chrome, il est très difficile d’en sortir, surtout avec l’avantage compétitif que NaCl représente par rapport aux autres navigateurs.

Le marché a-t-il encore besoin de puissance ?

Nous venons donc de voir que NaCl est une technologie révolutionnaire, mais dont la portée est maintenant limitée par les progrès des technologies concurrentes et par ses restrictions intrinsèques. Reste maintenant à aborder une question de fond : les utilisateurs sont-ils réellement en demande de puissance ? Les ordinateurs reposant sur l’architecture x86 sont ainsi en fin de cycle, l’informatique de demain sera ainsi dominée par les terminaux alternatifs qui répondent mieux aux attentes du marché : mobilité et autonomie (cf. 2011, l’année du point de bascule).

Dans ce contexte-là, NaCl n’a pas sa place car le rythme d’innovation est très élevé (Hummingbird vs. Snapdragon vs. OMAP vs. Tegra 2: ARM Chips Explained) et car les préoccupations des industrielles et éditeurs sont ailleurs. Nous nous dirigeons ainsi vers une configuration de marché où les utilisateurs valoriseront avant tout la portabilité et la sociabilisation des contenus liés au divertissement (musique, film, jeux) et où les collaborateurs d’une entreprise seront à la recherche d’outils de travail légers, souples et surtout collaboratifs.

Encore une fois, Google a les compétences et les capacités techniques pour réussir là où d’autres ont échoué (Microsoft avec ActiveX, Sun avec les applets Java), mais le défi relevé par NaCl ne va pas réellement révolutionner l’industrie. Je serais par contre très curieux de savoir comment ils souhaitent intégrer NaCl à Android, là nous aurons potentiellement quelque chose de beaucoup plus disruptif. En attendant, voyons déjà s’ils réussissent à accoucher correctement d’une première version de NaCl. Réponse dans quelques semaines…

]]> http://www.interfacesriches.fr/2011/02/22/pourquoi-google-a-deux-ans-de-retard-avec-native-client/feed/ 4