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 :
- 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 !
- 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 :
- Chrome OS, la couche d’abstraction matérielle qui permet de gérer les périphériques ;
- Chrome Browser, la couche de gestion des ressources, et accessoirement la couche de distribution des contenus, services et applications ;
- Native Client, l’environnement d’exécution (pour les processus les plus gourmands en ressource) ;
- Chrome Web Store, la place de marché d’applications.
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…