CPU ⬜ Carré Petit Utile

Extrait de l'émission CPU release Ex0250 : Et l'URL disparu.

Durant la décennie 2000, Nokia et un consortium de constructeurs réputés de téléphones portables s'appuient sur Symbian OS 9 pour leurs appareils très haut de gamme, le segment des assistants personnels connectés. Cela fait 10 ans que Palm OS gratouille le très haut du panier et que Microsoft essaie désespérément de transformer l'essai Windows CE. Arrivent deux nouveaux entrants : En 2006, Apple annonce son iPhone, forts de l'expérience du Newton et de l'iPod. Google rachète une petite boite, Android, dont ils ouvrent l'OS éponyme pour permettre à tous les fabricants de s'en servir.

Oui mais… Ces OS équipent le très haut de gamme en téléphonie mobile, un segment nommé smartphone. Une catégorie d'appareils qui s'installent dans les poches du public, certes, mais, quel public ? Ceux qui peuvent se payer un gizmo à un prix que tout le monde ne peut s'offrir, même en petites mensualités.

En 2011, Mozilla réfléchit à transformer son navigateur web comme surcouche graphique au kernel Linux, le projet B2G, Boot to Gecko, et développe FirefoxOS, un OS dont l'interface est entièrement basé sur les technologies HTML5 et donc complètement ouvert. Avec un device target (une plateforme utilisateur cible) au tarif bien précis : 100 $. Et là, y'aura pas de miracle : les performances hardware seront extrêmement réduites par rapport au monolithe d'Apple. C'est le motto du projet OLPC, One Laptop Per Children, lancé en 2005, mais en ayant le hardware qui était déjà en cours de développement, il fallait faire la couche logique au-dessus en faisant oublier les blobs binaires propriétaires dans le kernel.
Ce projet de surcouche d'OS web n'est pas une nouveauté, d'autres comme WebOS s'y essaient mais sur ordinateurs de bureau, pas sur téléphones moyen de gamme. Le projet de Mozilla est clair : construire les outils pour permettre au prochain milliard d'individus d'accéder à internet. Et un autre objectif : faire du smartphone non plus un simple terminal de consommation mais un système bricolable ; un écho à un article de TheFeature sorti en 2004 dont j'ai déjà parlé où Marko Ahtisaari [souhaitait] que l'industrie mobile considère ses utilisateurs comme s'ils étaient des développeurs.

Le défi technique est énorme, notamment en performances du langage javascript, en consommation mémoire, en moteur de rendu et en CPU. Les équipes développant Firefox et Chrome vont donc travailler sur les différents goulets d'étranglements, parfois de concert comme les événements asynchrones ou la gestion du garbage collector qui fige parfois les navigateurs. FirefoxOS et ChromeOS, ainsi que d'autres OS du même type comme Tizen, vont réfléchir ensemble à transformer un site web en applicatif, une application stand-alone, avec le même look & feel qu'une application native.

Il faut étendre les standards du web, rendre facilement transformable un site, non plus en Single Page Application, ce qu'on sait faire depuis 2004, mais en application réellement autonome, qui puisse fonctionner même en étant déconnecté du net et qui resynchronise les données en arrière-plan quand il le retrouve.
Et ceci en évitant l'écueil d'ElectronJS : un package qui fait tourner une appli native, un serveur web, une base de donnée locale lourde, une appli web et un moteur de rendu HTML par application package, ce qui donne un exécutable bloatware, une consommation disque et mémoire absolument dantesque et surtout des bibliothèques fondamentales qui ne sont pas automatiquement mis à jour.

Ainsi naquirent : Les WebApp

Une WebApp est définie d'abord par un simple document de manifeste posé à la base du site web, et qui précise le nom de l'app, l'icone, le point d'entrée du site, et ses éléments spécifiques. Ce manifeste comporte aussi les demandes d'autorisations d'usage pour certaines WebAPI. Une WebApp doit pouvoir tourner aussi bien sur Linux, Android, MacOS et Windows que sur les nouveaux FirefoxOS et ChromeOS.
En desktop aussi bien que sur smartphone, l'utilisateur trouve sur son bureau de base une icône de raccourci, qui lance son navigateur web habituel, mais totalement dépouillé et plein écran.

Les OS basés sur HTML5 seront de puissants laboratoires qui vont étendre d'abord ces navigateurs web qui tentent de s'alléger. Les ajouts qui y seront faits vont remonter chez les organismes de standardisation, à savoir ECMA pour le langage javascript et le WHATWG, plus rapide que le W3C pour le DOM, le HTML, les CSS et le reste. Une standardisation veut donc dire une relecture critique par les pairs et la validation par les autres membres de l'organisme, donc les autres éditeurs, des constructeurs, etc…

Un exemple des nouvelles API qui vont éclore en un temps très court ?
Les WebServices, une application javascript qui peut tourner en fond afin d'alimenter une petite base locale de données, localStorage, la géolocalisation même en lieu fermé, les tags de menus et de dialogues, le push d'un serveur vers des smartphones abonnés, les notifications sur la barre de statut, les WebComponents qui permettent de définir de nouveaux éléments applicatifs réutilisables. Et encore : je simplifie.
D'autres ajouts aux navigateurs web vont permettre de peindre librement dans un canevas, de faire de la 3D, de streamer de la vidéo vers un autre serveur, de bricoler l'historique du navigateur, d'exposer le système de fichier de l'appareil hôte, d'y enregistrer des documents et j'en passe.

Ces nouvelles technologies seront aussi l'occasion pour les autres éditeurs de navigateurs web, les équipementiers et les développeurs d'apps de marginaliser Microsoft et son Internet Explorer, qui reste un caillou dans la chaussure du web, malgré les progrès indéniables d'Internet Explorer 9. Si Windows continue à pousser l'usage d'IE à ses utilisateurs, ceux qui sont bien informés s'en servent pour charger un vrai navigateur alternatif. Le moteur de rendu de Microsoft étant très daté, ses parts de marché s'effondrent. Même Silverlight, la technologie propriétaire proposée par Microsoft pour remplacer les applets Java et le Flash de Macromédia semble être un effort vain face aux standards modernes du web.

Pour les WebApp, nous aurons quatre idées novatrices :

1. Rien, absolument rien ne doit se faire en appelant le kernel sous-jacent au navigateur web natif, même pas les fonctions Bluetooth et USB. Les constructeurs ne doivent ajouter que des API standardisées et ouvertes.
2. Le code des applications tourne en javascript SPA, Single Page Application, et construit des vues, discute avec le serveur originel, gère un cache des données dans l'appareil, changeant d'URL sans recharger toute la page.
3. Chaque vue est une URL. Et pour cela, on va non seulement utiliser le chemin, le path, mais on va aussi ré-utiliser les protocoles, comme mailto: pour envoyer un e-mail ou tel: pour passer un coup de fil, et aussi définir des protocoles privés à la volée. Une application peut lier profondément vers une vue d'une autre application. Idée que Google se hâtera de proposer au sein d'Android, et qu'Apple intègrera bien plus tard. L'URL est destinée à devenir universelle jusque dans la représentation de l'interface graphique d'un système d'exploitation.
4. Et une WebApp est une session d'un navigateur web qui se limite à la WebView. Là encore, pas de menus du navigateur hôte, pas de bouton de navigation, pas de barre d'URL : l'interface est la plus minimale possible pour que l'utilisateur aie la même illusion qu'une application compilée native.

Et pour l'adoption des WebApps, il faut qu'un développeur web puisse facilement construire une application totalement indépendante de l'OS, qui puisse tourner aussi bien sur un ordinateur de bureau que sur un téléphone portable, sans avoir à s'embêter à l'enregistrer dans des stores applicatifs.

Au-delà d'être un important accélérateur d'innovations pour le web, l'idée de Mozilla était aussi d'obtenir de nouvelles sources de financement, comme des constructeurs de téléphones ou des opérateurs mobiles, à côté de l'imposant Google qui construisait son propre navigateur web.

L'ambiance a été très stimulante au sein des équipes qui développent les navigateurs web, car en plus du chantier de créer de nouveaux outils, il y a un travail monstrueux d'optimisation à faire dans les navigateurs web. Ben oui, je vous rappelle qu'on parle d'en faire l'OS de téléphone mobiles à prix très modiques. De nouveaux projets labos vont apparaître : Mozilla va commencer une ré-écriture du moteur de Firefox en langage Rust, et Google teste Dartium, un navigateur web où à côté du javascript, on peut utiliser un nouveau langage front, Dart, qui accède aux mêmes API et objets DOM que javascript.

Le web va écrire son futur comme système d'exploitation pour téléphones à tout prix.

Ça sera un échec : les navigateurs de l'époque manquent encore d'un énorme travail d'épure dans leur code source. Chrome et Firefox auront chacun un chantier d'abstraction de leur interface graphique héritée des ordinateurs de bureau, ou encore sur les blocages du garbage collector de javascript. Le premier smartphone FirefoxOS à sortir en 2014 est lent, son système n'est pas toujours très fini, mais il arrive avec la promesse de faire entrer dans le monde de demain les clients de 28 pays. Y'aura une seconde version de FirefoxOS, mais tout le monde jettera l'éponge en 2017.

Le temps que le travail d'optimisation logiciel soit fait, les fondeurs de puces ARM auront suffisamment baissé les coûts pour proposer des smartphones sous les 100 $, le coût qu'espérait atteindre Mozilla, des Android low-cost capables de faire tourner des applications lourdes comme Youtube, Facebook, Instagram et des jeux.

La phrase de la CTO du projet OLPC s'applique là aussi :

Un seul miracle par produit est une très bonne règle pour créer un produit. Mais OLPC n'était pas un produit, mais un effort humanitaire global.

Dans le défi des OS web pour téléphones, l'effort commun a été d'universaliser le web.

Néanmoins, le rôle de laboratoire de ces OS web a été extrêmement puissant, et l'idée d'OS HTML5 n'a pas disparu : Samsung équipe toujours ses télés et frigos connectés de Tizen OS, et KaiOS a repris le flambeau de FirefoxOS depuis 2016. Tandis que React, qui était au départ un mock-up des fonctionnalités espérées, a vu arriver React Native, capable d'être compilé en application native Android et iOS, avec quasiment la même code base qu'un site en React pour le web.

Mais si les WebApps ont survécu aux OS HTML5, elles auront un ennemi puissant : Apple, qui a très longtemps tenu serré le frein à main d'iOS, souhaitant absolument garder le contrôle de tout applicatif pour iPhone et iPad. Hors de question pour Cupernito que les clients puissent si facilement installer des applications en dehors de leur app-store. Apple sortira tous les prétextes possibles comme le refus d'avoir un langage de programmation tourner dans un iPhone pour des raisons de sécurité. On comprend très bien Apple : garder leur plateforme fermée permet de garantir de très confortables revenus. Mais 15 ans après, la firme à la pomme a fini par relâcher le frein à main. Tout n'est pas encore totalement bien intégré, et Safari Mobile accuse toujours un certain retard sur des WebAPI pas si secondaires.

Mais c'est trop tard : le public préfère installer des applications natives sur les smartphones, voire, comme en Chine, d'utiliser une méga-application unique comme celles de Weibo ou d'Alibaba, ce qu'Elon Musk veut reproduire avec X. Une nouvelle manière de cadenasser l'utilisateur et d'oublier qu'une technologie se vit mieux quand elle est libre et bidouillable.

Texte : Da Scritch,
Illustration : cc-0 MaxPixel