Gemmes, pipes, poires, et les autres

J’ai récemment gazouillé qu’après avoir jeté un œil à Zurb Foundation (une structure permettant de créer des sites Web réactifs), je n’allais probablement pas l’essayer, car les développeurs indiquent qu’ils vont utiliser de plus en plus Ruby. Une dépendance certes facultative, mais qui deviendra sans doute nécessaire pour tirer le meilleur parti de l’outil. Or j’essaie de me libérer de ma dépendance à Ruby. Mon gazouillis a suscité quelques réponses, et comme je suis un bavard qui a du mal à dire quoi que ce soit en cent quarante octets, je vais développer ici un brin.

C’était plus simple avant. Il y a une dizaine d’années, trois technologies serveur étaient prédominantes sur le Web : PHP, Java et .Net. Chacune avait sa philosophie et sa pile de composants. On était d’un camp et on utilisait les outils de ce camp. J’étais développeur PHP et avais donc installé sur mon serveur tous les outils pour exécuter des applications PHP, les bibliothèques, les gestionnaires de paquets, les modules Apache, tout le nécessaire pour compiler des modules, etc.

Aujourd’hui, j’ai l’impression que le secteur est beaucoup plus fragmenté. De nouveaux environnements se sont imposés, ou sont en train de le faire. Python, Ruby, JavaScript via Node.js. Avant, si l’on excluait les technologies propriétaires et/ou obèses, on n’avait guère d’autre choix que des applications en PHP. Aujourd’hui, pour quasiment chaque application, on peut choisir entre des solutions en PHP, Python, Ruby, JavaScript (bientôt). Ce choix est une bonne chose, mais avec son mauvais côté : chaque technologie a sa propre pile de composants, bibliothèques, gestionnaire de paquets, serveur applicatif recommandé, etc. Et l’on se retrouve à installer et gérer des paquets PEAR/PECL pour PHP, des PIP pour Python, des Gems pour Ruby, des Npm pour Node… Des dépendances pas forcément empaquetées pour ma distribution (ou dont les paquets ne sont pas à jour), et qu’il faut donc gérer à la main. Se battre avec les gestionnaires de paquets aux options incompatibles. Régler les conflits, vérifier régulièrement les mises à jour de sécurité. Ce qui était hier routinier pour mon langage de prédilection représente, s’il faut le faire pour quatre environnements différents, tant une charge de travail non négligeable qu’un risque du fait de mon amateurisme.

Pour diminuer la charge de maintenance de mon serveur, et minimiser les risques d’avoir des composants présentant des failles de sécurité connues, j’essaie donc désormais de limiter ma dépendance à des composants que je ne maîtrise pas. À moyen terme, je voudrais ne conserver que JavaScript (parce que c’est mon langage de choix pour les prochaines années) et Python (parce qu’il est très lié à Debian, et que je peux donc difficilement envisager de m’en passer). Il va falloir que je trouve des alternatives aux applications PHP (mon instance de Status.net va dégager) et Ruby (je vais essayer de remplacer Jekyll par DocPad pour ce journal) que j’utilise encore.

Je n’ai donc rien contre Ruby, ni même PHP. Chacun de ces environnements est aujourd’hui mature et offre tous les outils qu’il faut. Mais désormais dans mes choix de composants et d’applications, la dépendance à certaines piles technologiques sera un critère important.

Penser global, agir…

Je réalise ce soir que depuis des années je me trompe en présentant Mozilla. J’explique que c’est une organisation de gentils hippies dont le but est de rendre le Web meilleur. Affreux contresens, le but de Mozilla n’est pas de rendre le Web meilleur, mais de rendre la vie des gens meilleure. Le Web n’est que le moyen qu’utilise la Fondation pour aller dans ce sens.

Le Web est une vaste terre en friche, et Mozilla veut nous aider à mieux y vivre. En nous donnant des outils pour cultiver la terre, en nous apprenant à utiliser ces outils, en réfléchissant à de nouveaux usages. Le but de la Fondation, ses valeurs, sont assez universelles, et quelle que soit sa culture on peut je pense se retrouver dans ces valeurs, les partager et choisir d’œuvrer ensemble pour les faire progresser. Mais si le but est universel, s’accorder sur le choix des routes pour y parvenir est beaucoup plus compliqué.

Pendant ses premières années, Mozilla a choisi une route essentiellement technique. Créer des outils. C’est un domaine où les référentiels culturels interfèrent peu. On peut débattre pour savoir s’il vaut mieux forger une pelle et une bêche, ou une pelle-bêche. Mais les choix en la matière sont davantage personnels que le fruit d’une histoire collective.

À présent que nous disposons de quelques outils, il est temps de passer à une nouvelle étape : apprendre à s’en servir, et leur inventer de nouveaux usages. C’est ici que les choses se compliquent. On sort du domaine essentiellement technique pour aborder celui des interactions sociales. On quitte le relativement universel pour la multiplication des points de vue en fonction des sociétés et des milieux dans lesquels ont évolué les membres de la communauté. Il est beaucoup plus difficile en ces domaines de s’adresser à tous en utilisant les mêmes mots.

J’ai relevé ces derniers mois deux exemples qui illustrent cette difficulté. Deux cas où, bien que comprenant le but poursuivi, j’ai du mal à suivre le chemin proposé.

Le premier est l’influence de la variante nord américaine du scoutisme sur Mozilla1. Mitchell Baker a récemment évoqué l’influence qu’a eu sur son parcours son passage aux Girl Scouts of the United States of America. Mark Surman, un autre responsable de la Fondation, vient de proposer que Mozilla participe à la création d’un mouvement de scouts du Web. Et il ne s’agit pas là que de paroles. OpenBadges, une des pièces maîtresses de l’investissement de la Fondation dans le secteur éducatif, s’inspire directement des badges certifiant l’acquisition d’une compétence dans certains mouvements scouts. Malheureusement, ce concept de badges et son lien avec l’éducation me semblent plus difficile à expliquer aux francophones avec lesquels je discute. Les éléments de la culture scoute sont sans doute moins partagés dans l’ensemble de la société française. S’en inspirer n’est peut-être pas pertinent.

C’est Mark Surman, encore, qui m’a fait penser au deuxième cas en évoquant la possibilité d’utiliser l’appellation générique de WebMakers pour désigner le programme de soutien à la création sur le Web. C’est un concept que Mark a introduit l’an dernier et qui s’inspire directement du mouvement « make » très actif aux USA depuis fort longtemps. Mark fait aussi référence à l’éthique particulière des adeptes de ce mouvement, souhaitant la transposer au Web. Problème, ce mouvement est encore quasi-inexistant en France, ou n’a du moins ni la forme ni l’ampleur de celui des USA. Quand à l’éthique des makers… Comment dès lors expliquer ce que veut faire Mozilla en promouvant les WebMakers ? Il n’y a même pas de mots français pour désigner le concept, comment expliquer quelque chose que l’on ne sait pas nommer ?

Tout cela m’amène à me demander si Mozilla ne devrait pas introduire un peu de relativisme dans ses plans. Oui, éduquer au Web est important, oui, encourager la création sur le Web est important, je pense que tout le monde au sein de la communauté s’accorde sur ces points. Mais les moyens de le faire ne sont peut-être pas les mêmes partout. Les analogies qui ici éclaireront la démarche l’obscurciront peut-être ailleurs. Je n’aime guère les révolutions culturelles imposées par en haut. Peut-être chaque communauté locale devrait-elle essayer, avec le soutien de la fondation, de s’emparer des questions de l’éducation au Web et de la création sur le Web, et essayer d’y répondre en fonction de son contexte. Ne serait-ce pas finalement l’application de la fameuse formule de René Dubos, « Penser global, agir local » ? Qu’en pensez-vous ?

Comme il n’y a toujours pas de commentaires ici, si vous avez une réflexion sur le sujet à partager, n’hésitez pas à la publier quelque part et à me pinguer, je rajouterai un lien à cette note.

  1. suite à quelques échanges sur Twitter j’avais promis un billet ici sur le sujet. Je l’ai écrit dans ma tête mais n’ai jamais trouvé le temps de le vider sur le clavier, et l’ai à présent oublié. Rajouté à la longue liste des choses que j’espère faire un jour;

Mozilla propose une API sociale

Mozilla, qui suit un peu ce qui se passe en ligne, a remarqué qu’un certain nombre d’internautes utilisent de plus en plus le Web pour interagir entre eux via des sites dits de réseaux sociaux. La Fondation s’interroge naturellement sur les moyens d’améliorer l’expérience des internautes sur ces réseaux, améliorer signifiant pour elle leur donner davantage de contrôle sur ce qu’ils font, leurs données, etc, mais aussi rendre les interactions plus simples et plus riches. Les réponses en la matière avaient pour l’instant été timides. Les laboratoires ont lancé il y a quelques années F1, une extension pour partager des liens. Elle devrait bientôt être intégrée nativement à Firefox sous le nom de Share, mais force est de reconnaître qu’elle ne va pas très loin.

Michael Hanson a annoncé aujourd’hui une initiative autrement plus ambitieuse : une proposition d’« API sociale » permettant au navigateur et à des réseaux sociaux d’interagir. La proposition est longue et encore à l’état de brouillon, je ne vais donc pas la traduire mais essayer d’en résumer certains points.

Configurer des fournisseurs de services à intégrer dans le navigateur

Chaque site désirant utiliser l’API décrirait ses fonctionnalités via un fichier similaire au manifeste des application Web. Ce manifeste contiendrait la description du service et les URLs permettant de communiquer avec ses fonctionnalités. Lorsque l’internaute installera un fournisseur de service dans son navigateur, celui-ci considérera que ces URLs sont dignes de confiance. Le navigateur les autorisera à faire davantage de choses, comme par exemple envoyer des notifications qui s’afficheront dans l’interface. Selon la philosophie Mozilla, l’ajout de nouveaux fournisseurs de services, leur activation et leur désactivation, devrait être simple. La liste des services pourrait être affichée en permanence, si l’interface le permet (ie dans les versions de bureau des navigateurs).

Pour chaque service actif, le navigateur maintiendra une connexion permanente dans un espace sécurisé (sandbox) (techniquement, cela pourra utiliser les shared workers en cours de définition dans HTML5). Outre la connexion au service, le processus dédié à chaque fournisseur pourra également stocker des données localement et interagir avec certaines partie de l’interface du navigateur (pour afficher des notifications par exemple).

Si l’écran le permet (navigateurs de bureau ou tablettes), une barre latérale permettra aux fournisseurs d’afficher du contenu à leur guise. Ils pourront également ouvrir des espaces épinglables dans l’interface — pensez à une fenêtre de discussions flottant en permanence dans un coin de votre navigateur.

Partager des mises à jour

C’est le suite de Firefox Share : un moyen simple de recommander un contenu. Dans son manifeste, chaque fournisseur indique s’il fournit ce service. Le navigateur propose alors des moyens (boutons, menu contextuel) de partager un contenu, avec la liste des fournisseurs disponibles.

Envoyer et recevoir des notifications d’activités

Les services pourront envoyer des notifications que le navigateur affichera à l’internaute. La façon d’afficher ces notifications devra être contrôlable de façon fine.

Afficher le statut des contacts et permettre de dialoguer avec eux

Les fournisseurs pourront également indiquer qu’ils disposent d’une API de gestion de contacts. On pourra ainsi gérer ses contacts sur les différents réseaux sociaux directement depuis son navigateur — je me souviens que des Labs avaient déjà mené une expérience en ce sens il y a des années, hélas abandonnée comme tant d’autres.

Interactions avec le reste du Web

Chaque fournisseur sera cantonné à un bac à sable, d’où il ne saura pas ce que fait l’utilisateur. Les pages Web consultées pourront cependant indiquer qu’elles souhaitent interagir avec un réseau social. L’internaute indiquera alors au cas par cas ce que chaque page / site peut faire. Ça part d’une bonne volonté, mais je pense que c’est une protection illusoire. La majorité des gens sera vite lassée des demandes d’autorisations et autorisera par défaut tous les sites à dialoguer avec tous les réseaux activés.

Interface

Tout comme pour les fonctionnalités, la réflexion sur l’interface commence juste. Le navigateur intégrera sans doute une zone permanente pour les notifications provenant des réseaux, et des composants comme les popups épinglables ou une barre latérale ou autre, pour afficher des contenus spécifiques, flux de nouvelles ou statut des contacts.

Enfin le temps perdu qu’on ne rattrape plus

Pour l’instant, cette API sociale reste une annonce des Labs. Elle reprend, au moins en partie, nombre de précédents projets lancés en fanfare et rapidement tombés dans l’oubli. J’ai été suffisamment échaudé pour ne pas m’enthousiasmer trop vite. Cependant, avec la monté en puissance du groupe de travail sur l’identité et les rapports sociaux, et la déferlante d’APIs auxquelles travaille Mozilla en ce moment, peut-être que cette fois-ci sera la bonne et que Firefox se dotera de moyen d’améliorer les interactions avec les réseaux sociaux. Stallman seul le sait.

Comme d’habitude chez Mozilla, la suite des réflexions et de la conception va se faire de façon relativement ouverte. Si le sujet vous intéresse, n’hésitez pas à vous abonner à la liste ad hoc, dont je ne donnerai pas l’adresse, c’est un Google Group, il faut donc un compte Google pour s’y inscrire. Grrrr.

Les gens ne lisent pas de flux XML

Les gens ne lisent pas de flux XML. Ce sont les machines qui lisent des flux XML. Les gens eux lisent leur courrier.

Il y a 15 ans, lorsqu’on tombait sur un site intéressant, il n’était pas compliqué d’être informé de ses mises à jours. Il suffisait de laisser son adresse de courrier électronique, on s’abonnait à une lettre d’information et on recevait les mises à jour dans sa boîte aux lettres. Puis, sans doute à cause de l’augmentation du nombre de pourriels, les utilisateurs les plus avertis ont commencé à rechigner à laisser leur adresse n’importe où, et à chercher d’autres moyens d’être avertis des mises à jour.

À la même époque naissait RSS. Dans mon souvenir, c’était d’abord un moyen d’échanger des informations entre sites, d’indiquer sur un site les publications des sites amis. Donc un moyen d’échange entre machines. Je ne me souviens plus trop à partir de quand on s’est dit que ça serait un bon moyen de remplacer les newsletters. Puisque les sites mettaient à la disposition des autres sites des flux XML, pourquoi ne pas nous aussi utiliser ces flux. Et nous sommes devenus accrocs à RSS et ATOM, compagnons indispensables de l’aventure des blogs.

En 2011, Mozilla a provoqué un coup de tonnerre en supprimant de l’interface par défaut de Firefox le bouton indiquant qu’un flux était disponible et permettant de s’y abonner. Comme beaucoup d’autres geeks, j’ai crié à la trahison. Comment promouvoir ce format d’échange qu’est ATOM si les utilisateurs n’ont aucun moyen de connaître son existence ?

La vieillesse aidant, je me dis aujourd’hui que cette décision de Mozilla était la bonne. Ce bouton ne promouvait pas RSS/ATOM. Même si un utilisateur, découvrant cette icône étrange au milieu d’autres aussi peu compréhensibles, avait la curiosité de cliquer dessus, que pouvait-il faire ensuite ? Il arrivait sur un écran présentant de manière spartiate les derniers articles et lui proposant d’ajouter le site à son lecteur de flux. Un « lecteur de flux » ? WTF se serait dit monsieur Michu — enfin l’équivalent en Michu, fichtre, palsembleu ou skoastruk — et il serait retourné regarder des vidéos de chat. Intérêt pédagogique nul. Ce bouton était donc bien inutile, n’offrant à la majorité des utilisateurs ni un service utile, ni l’opportunité de découvrir un nouvel usage. Quant aux utilisateurs de flux, ils n’ont pas été lésés, car ils ont pour la plupart le niveau de compétences pour refaire apparaître le bouton chéri.

Et j’en reviens à mon hypothèse initiale. Les gens ne lisent pas de flux RSS, mais ils lisent leurs mails. Il faudrait donc trouver un moyen de fournir un service équivalent aux lettres d’informations, mais sans les problèmes liés à la diffusion de son adresse électronique aux sites. Il faudrait en fait que le navigateur gère tout cela de façon transparente. Et, ça tombe bien, une des évolutions en cours de Firefox permet d’aller dans cette direction, avec BrowserID et le chantier sur la gestion de l’identité. Firefox sait lire des flux XML. Firefox connait notre adresse. Pourquoi ne pas lui demander de créer lui-même des lettres d’information à partir des flux. En arrivant sur un site proposant un flux, on aurait non l’icône orange, mais une enveloppe proposant de recevoir les nouveautés par mail. Cliquer dessus dirait à Firefox de s’abonner au flux et de nous envoyer un mail à chaque mise à jour. Et on pourrait consulter les dernières nouvelles de ses sites préférés directement dans son client de messagerie habituel.

Techniquement, cela ne me semble guère compliqué à réaliser, une extension pourrait probablement faire le boulot dès aujourd’hui. La seule difficulté que je vois est de se connecter à un SMTP pour l’envoi des mails. Mais je me rappelle que Mozilla fut jadis une suite complète intégrant un courrielleur, ils devrait donc bien rester quelques développeurs capables de résoudre ce souci.

Cela ne signifie bien sûr pas la mort d’ATOM. Il a je pense encore un bel avenir comme protocole de communication et format d’échange entre machines. Mais il est temps que les navigateurs proposent aux utilisateurs d’autres moyens de recevoir des nouvelles des sites. Alors qui a cinq minutes pour coder cette extension ?

Le Web est la plateforme

B2G, le projet le projet de Mozilla de créer un système d’exploitation basé sur Firefox, a fait aujourd’hui un grand pas en avant. Plusieurs partenariats ont été annoncés qui vont aider le rêve à devenir réalité. Parmi les différents articles détaillant cette annonce, j’ai traduit à l’arrache celui, synthétique, publié par Robert Nyman.

Boot to Gecko, par Mozilla — Le Web est la plateforme

Le projet Boot to Gecko (B2G) de Mozilla vise à créer un système d’exploitation complet et autonome pour le Web ouvert. Son but est de faire des technologies Web le choix numéro un pour créer des application aussi bien sur les ordinateurs de bureau que sur les téléphones portables, et nous croyons qu’il peut supplanter les environnements propriétaires et contrôlés par une seule société pour le développement d’applications. Nous avons fait quelques progrès excitant que nous voudrions partager avec vous !

Le projet Boot to Gecko

Commençons par jeter un œil aux composants du projet :

Les buts

Boot to Gecko est le système d’exploitation libre et basé sur le Web de Mozilla pour les terminaux mobiles. C’est la base du terminal pour le Web libre qui a été présenté au Mobile World Congress en février 2012.

Les technologies

L’architecture de Boot to Gecko élimine la nécessité de bâtir des application en utilisant des API natives à chaque plateforme. En utilisant HTML5, les développeurs écrivent directement leurs applications pour le Web; ils peuvent créer de fantastiques expériences utilisateur, et des applications débarrassées des règles et des restrictions des plateformes fortement contrôlées.

Des standards ouverts et accessibles

Comme tous les projets Mozilla, le code source de B2G est ouvert et accessible, et le projet est entièrement basé sur des standards ouverts. Pour les fonctions pour lesquelles des standards ouverts n’existent pas encore (en particuliers la téléphonie, l’envoi de SMS, l’accès à l’appareil photo, au Bluetooth, à l’USB, au NFC), Mozilla travaille avec les autorités de certification et les autres éditeurs pour créer des standards. Pour en savoir plus vous pouvez lire l’article « Mozilla et l’évolution de l’API Web mobile »

Voici en vidéo des interviews, dans une grande variété de langues, avec les développeurs du projet Boot to Gecko

Les terminaux pour le Web libre

Les terminaux pour le Web libre (Open Web Devices) ont été annoncés aujourd’hui au Mobile World Congress ! Nous allons travailler avec l’opérateur de téléphonie Telefónica. Voici nos buts, tels que détaillés dans le communiqué de presse :

  • créer des terminaux HTML5 utilisant le Web libre pour offrir les fonctionnalités des smartphones sur des téléphones à bas coûts;
  • soumettre ces fonctionnalités au W3C pour en faire des standards et les rendre librement disponibles;
  • créer de nouvelles opportunités pour les développeurs d’applications et tirer en avant HTML5 en tant que standard inter-plateformes.

Mozilla, Telefónica et Qualcomm vont travailler ensemble pour proposer un prototype de plateforme avec de nombreuses fonctionnalités, basé sur une puce développée par Qualcomm. Le navigateur a déjà un score de 315 points à un test d’implémentation de HTML5, et le résultat devrait être très abordable, puisque d’après Carlos Domingo de Telefónica, les téléphones basés sur Boot to Gecko seront dix fois moins cher qu’un iPhone.

En partenariat avec Deutsche Telekom

Nous sommes également heureux d’annoncer que le laboratoire pour l’innovation de Deutsche Telekom va rejoindre le projet pour développer Boot to Gecko avec Mozilla.

Une démonstration de Boot to Gecko

Voici une démonstration de Boot to Gecko en action  Elle montre comment passer un coup de fil à un contact, naviguer sur le Web et passer un test d’implémentation de HTML5 (où Firefox mobile a le score le plus élevé de tous les navigateurs mobiles). Elle montre ensuite comment utiliser un client Twitter, jouer à un jeu, consulter Google Maps, regarder une vidéo sur YouTube, lire une livre, et fini avec la lecture d’une vidéo locale.

Le Web est la plateforme

Comme nous l’avons toujours cru chez Mozilla, le Web est la plateforme, et les technologies ouvertes sont le moyen d’y créer. Développons pour le Web et pour le futur !

[Mozillas Boot to Gecko – The Web is the Platform](http://hacks.mozilla.org/2012/02/mozillas-boot-to-gecko-the-web-is-the-platform/) par Robert Nyman
Fork me on GitHub