Google et Mozilla cherchent-ils à tuer les plugins ?

Depuis l’arrivée de Google sur le marché des navigateurs et la course à la performance des machines virtuelles javascript, les technologies reposant sur des plugins se font beaucoup plus discrètes. Dans l’absolu, nous ne pouvons que nous féliciter de la disparition progressive de technologies propriétaires dans nos navigateurs (Flash, Silverlight, Java…) au profit de technologies standards (javascript, WebGL…). Mais dans la pratique, ce n’est pas si simple, car il n’y a pas de bonnes ou mauvaises technologies. Nous avons cependant pu constater ces dernières années une authentique chasse aux sorcières contre Flash, menée de main de maître par Apple. Une manoeuvre logique dans la mesure où ce plugin représentait un danger pour l’intégrité de son écosystème si fermé. Vous noterez cependant que ce n’est pour autant qu’ils ont cherché à faire disparaître ou évoluer Quicktime, autre plugin et technologie propriétaire, mais c’est un autre débat…

Bref, tout ça pour dire que, à un jour d’intervalle, Google et Mozilla viennent d’annoncer l’abandon prochain d’une brique essentielle pour les pluginsGoogle looks to drop Netscape Plugin API support in Chrome, starting with blocking most plugins in January 2014 et Plugin Activation in Firefox. Pour vous la faire simple, le Netscape Plugin Application Programming Interface est la brique logicielle permettant aux plugins de dialoguer avec les couches basses du système. Le problème est que cette brique a été conçue il y très longtemps et que les éditeurs de navigateurs aimeraient s’en passer.

Un certain nombre de plugins seront touchés par cette restriction, mais rassurez-vous, le Flash Player et le PDF Viewer n’utilisent pas NPAI, ils ne seront donc pas affectés. Parmi tous les plugins l’exploitant, les équipes de Google ont identifié 6 plugins utilisés le mois dernier par plus de 5% des utilisateurs : Silverlight, Unity, Google Earth, Java, Google Talk et Facebook Video. L’argument avancé par Google est tout à fait légitime (pourquoi continuer à supporter une API datant du siècle dernier), mais je ne peux m’empêcher de penser qu’il s’agit plutôt d’un message fort envoyé aux éditeurs de plugins : « Vous êtes sur mes terres, alors pliez-vous à mes règles« . Il n’aura échappé à personne que Google ne gagne rien à accepter la prolifération des plugins venant se greffer sur son navigateur. D’autant plus que les équipes ont fait des progrès décisifs sur NaCl, l’environnement d’exécution « maison » : Google’s Bet On Native Client Brings Chrome And Google+ Photos Closer Together.

De même, Mozilla n’a pas grand-chose à gagner à laisser des éditeurs tiers greffer leur technologie sur Firefox. Hasard du calendrier, ils ont également annoncé la semaine dernière la disponibilité d’une version HTML5 du Flash Player : Shumway, Mozilla’s HTML5-Based Flash Player Replacement, Lands In Firefox Nightly. Pour mémoire, ce projet de réécriture avait été initié il y a presque 7 ans (Vers un flash player en open source pour la fondation Mozilla ?). Autant les équipes de Google s’essayent à des technologies propriétaires, autant la fondation Mozilla mise tout sur javascript, et ils le font visiblement avec brio : Surprise! Mozilla can produce near-native performance on the Web. Mozilla est-il en train de réinventer la roue ? Non, ils sont simplement en train d’accomplir leur mission : oeuvrer pour un web plus ouvert.

Peut-on en conclure que la fin des plugins est programmée ? Non, et ce n’est pas l’objectif. Je pense ne pas me tromper en disant que les technologies propriétaires des années 2000 se sont développées en profitant de l’immobilisme du W3C qui n’a pas su faire évoluer HTML suffisamment rapidement. Les choses ont maintenant changé et les éditeurs de navigateurs web essayent simplement de remettre de l’ordre dans cette pagaille en limitant le nombre et l’usage de technologies propriétaires.

Dans l’absolu, les plugins ne sont pas un problème, à partir du moment où leur utilité est restreinte à un domaine d’application bien précis : l’animation vectorielle pour Flash, la vidéo pour Quicktime, les jeux 3D pour Unity. Mais il ne faut pas jeter le bébé avec l’eau du bain, n’oubliez pas que les plugins ne sont que la partie visible de l’iceberg : Adobe n’a jamais gagné de l’argent avec le Flash Player, tout comme Unity ne gagne rien avec son Unity Web Player. Par contre, ces éditeurs se rémunèrent sur les environnements de développement qui, eux, proposent une réelle valeur ajoutée. Ce n’est ainsi pas un hasard si Google vient de lancer son propre outil de développement : Google launches public beta of Web Designer, a free design tool for creating HTML5 ads and campaigns. Le but de la manoeuvre pour Google est de se positionner plus en amont sur la chaîne de valeur et de dégager les intermédiaires. Jusqu’à présent, les belles bannières animées qui pullulent sur le web étaient réalisées en Flash, mais avec ce nouvel outil, Google tente de proposer un service intégré de bout en bout : de la création (Web Designer), à la distribution (DoubleClick), à mesure de la performance (Google Analytics).

Dans le cas particulier de Unity, la valeur ajoutée ne provient pas des capacités du player à afficher le plus grand nombre de polygones, mais dans la simplicité et la sophistication de l’environnement de développement. Si je suis admiratif devant la fluidité d’un HexGL, force est de constater que le développement d’un jeu multiplateforme sous Unity est beaucoup plus rapide, surtout si vous souhaitez le distribuer sur les terminaux mobiles (avez-vous essayé Superhot ?). D’où mon assertion du début d’article : il n’y a pas de bonnes ou mauvaises technologies. Certes, Unity est un éditeur privé qui vend des licences, mais du moment que leur technologie, même propriétaire, vous permet de concevoir / réaliser / déployer une application ou un jeu en ligne plus facilement et rapidement, pourquoi s’en priver ? Ceci justifie mon ambivalence autour des standards du web ET des technologies propriétaires comme Flash ou Unity. Et je pense ne pas être le seul (cf. Occupy HTML).

Conclusion : inutile d’annoncer la mort des plugins, car ce n’est pas demain la veille. La très grande majorité des internautes ne s’intéresse pas à ce débat sur les standards web, tout ce qui l’intéresse, c’est d’avoir accès à des contenus et services de qualité. Et les éditeurs de navigateur ne se risqueront pas à donner l’impression à leurs utilisateurs qu’ils sont bridés (il n’y a qu’Apple pour faire ça). Mais il est par contre tout à fait légitime que ces derniers cherchent à optimiser leur code source, notamment en faisant un petit nettoyage. Et c’est le but de cette opération, ni plus, ni moins.

3 commentaires sur “Google et Mozilla cherchent-ils à tuer les plugins ?

  1. Si on se réfère au précédent post sur les chrome apps, Google n’embarque-t-il pas sans le nommer un « plugin natif » (oui, on est dans l’oxymore ^^) d’exécution pour ses apps ? On comprend mieux alors son désamour pour les plugins concurrents, ajoutant lourdeurs, bugs, et aucune possibilité de profit.

    1. Hum… effectivement NaCl n’est pas intégré dans le moteur de rendu HTML, donc on peut le classer par élimination dans la catégorie des plugins. C’est subtile, mais ça méritait d’être dit.

Laisser un commentaire