Pour se passer de Powerpoint, il y a Impress de LibreOffice bien sûr.

Mais il existe aussi de nombreuses solutions web issues du trio gagnant : JavaScript, HTML5 et CSS3).

Nous avons choisi avec cette traduction de mettre en valeur Reveal.js, avec une méthode de geek pour assurer l’archivage et retrouver facilement les différentes versions de vos présentations.

Enseigner avec l’application de présentation libre Reveal.js

Teaching with open source presentation service Reveal.js

Luis Ibanez – 30 octobre 2013 – OpenSource.com
(Traduction : Penguin, Genma, audionuma, cyrille, Omegax, Garburst)

OpenSource.com a un programme pour les modérateurs de communautés, et je suis fier d’en faire partie. Nous nous sommes récemment réunis dans le centre ville de Raleigh (en Caroline du Nord). L’une de nos discussions portait sur les logiciels open source pour l’éducation, et Ruth Suehle, qui dirige l’équipe marketing de Fedora tout en conseillant et en écrivant pour Opensource.com, a attiré notre attention sur les merveilles de Reveal.js, un nouvel outil de préparation de diapositives pour les présentations.

« C’est ce que les gens cool utilisent »dit-elle. Et dieu sait qu’elle avait raison !

Un rapide détour par la page d’exemples et de présentations permet de convaincre les plus sceptiques.

Les principales caractéristiques qui sortent du lot sont :

• Les diapositives sont créées en écrivant du simple code HTML
• Les présentations…
  • sont des pages HTML + Javascript
  • peuvent être vues sur n’importe quel appareil : téléphones, tablettes, ordinateurs.
• Le contenu peut être mis dans un système de contrôle de version (par exemple Git/Github).
  • Ne vous est-il jamais arrivé de regarder une présentation d’une année passée et de vous demander s’il s’agit bien de la version que vous souhaitez utiliser ? Vous êtes vous jamais demandé quelles étaient les dernières modifications ?
• L’hébergement Git permet la collaboration de plusieurs auteurs.
  • Tout comme avec n’importe quel projet collaboratif, différents auteurs peuvent ajouter du contenu, faire des commentaires, corriger les erreurs.
  • Et en cas de désaccord, ils peuvent toujours faire une branche dérivée, un fork, de ces présentations.

Voici quelques-unes des présentations qui ont été faites lors de notre cours « Pratiques des logiciels open-source » à l’École polytechnique Rensselaer et à l’université de l’État de New-York à Albany :

• Raspberry Pi – Un serveur web en Python (sur GitHub)
• Introduction à Git Partie I (sur GitHub)
• Introduction à Git Partie II (sur GitHub)
• L’évolution de la coopération (sur GitHub)

Pour ceux qui ne sont pas à l’aise avec l’écriture de code HTML, il y a un éditeur interactif : Slid.es, au sein duquel vous pouvez créer vos diapositives en utilisant une interface simple. Les présentations sont également hébergées, ainsi vous n’avez pas besoin de vous préoccuper de trouver un serveur web.

Pour ceux à qui écrire du code HTML plaît, la façon la plus facile de commencer est la suivante :

• Consultez les nombreux exemples
  • Copiez ou forkez vos (exemples) favoris
  • Modifiez et créez le votre

La façon de faire pour du long terme est la suivante :

• Créer un nouveau dépot :
  • git init
• Utiliser le dépôt Reveal.js comme un sous-module de git
  • La commande est : git submodule add https://github.com/hakimel/reveal.js revealjs
  • Ajouter le fichier index.html dans ce répertoire
    • Regarder cet exemple de présentation
    • Voir comment le sous-répertoire « revealjs » a été ajouté aux liens vers les css et répertoires lib.

Enfin, le partager en retour !

Vous pouvez ajouter vos présentations en guise d’exemple pour les autres, en modifiant simplement les exemples de la page de présentation.

Remarquez que l’usage de Git (ou GitHub) n’est pas une nécessité, vous pouvez profitez de la joie d’utiliser Reveal.js comme un simple framework web. C’est juste qu’ajouter les fonctionnalités de Github tel que le contrôle de version, l’hébergement, le partage, donne une nouvelle dimension à la facilité d’usage de ce merveilleux outil.

Remarquez qu’il n’est pas nécessaire d’héberger vos présentations sur un serveur web. Vous pouvez toujours faire la présentation depuis votre pc portable en indiquant à votre navigateur web où se trouvent les fichiers HTML sur votre disque dur. Ce qui peut s’avérer très pratique quand on arrive en retard en classe, ou lorsque l’on a des changements à faire en dernière minute sur la présentation (ce qui bien sûr n’arrive jamais…:)).

La question de l’implémentation des DRM à même le HTML5 fait couler beaucoup d’encre actuellement. Nous l’avions évoqué dans nos colonnes : Mobilisons-nous ! Pas de DRM dans le HTML5 et les standards W3C et DRM dans HTML5 : la réponse de Cory Doctorow à Tim Berners-Lee (le Geektionnerd n’étant pas en reste non plus : DRM et HTML5 et DRM HTML5, c’est fait).

Il faut dire que la simple évocation de ces 3 majuscules fait hérisser le poil de bon nombre d’entre nous. Alors vous imaginez, les DRM validés et implémentés par le W3C ! Ce serait crime de haute trahison…

Pour en quelque sorte éteindre l’incendie, Sir Tim Berners-Lee himself répond ici à ses détracteurs en voulant se montrer rassurant quant à sa préoccupation constante et prioritaire qui demeure un Web libre et ouvert pour ses utilisateurs. Il rappelle que pour le moment nous n’en sommes qu’à la phase de discussion et que celle-ci s’annonce d’autant plus longue qu’il y a de nombreuses parties à tenter de concilier.

Convaincant et convaincu ?

À propos de la protection vidéo et du Web ouvert

On Encrypted Video and the Open Web

Tim Berbers-Lee – 9 octobre 2013 – W3 Blog
(Traduction : Paul, Penguin, Garburst, Alexis, Norore, ZeHiro, Armos, genma + anonymes)

Il y a eu beaucoup de réactions suite au message annonçant que le W3C considère que le sujet de la protection des vidéos devait être abordé au sein de son Groupe de Travail HTML. Dans cet article, je voudrais donner quelques arguments pour expliquer cela.

Nous entendons l’explosion de critiques (et quelques soutiens) concernant les récents changements d’orientation du W3C qui ouvrent la discussion à l’intégration de la protection du contenu vidéo au sein du Groupe de Travail HTML. Nous entendons cette critique comme un signal : que de nombreuses personnes attachent de l’importance aux choix du W3C, et se sentent trahies par cette décision. Je veux qu’il soit clair que toute l’équipe du W3C et moi-même sommes plus passionnés que jamais au sujet de l’ouverture du Web. De plus, aucun d’entre nous, en tant qu’utilisateur, n’apprécie certaines formes de protection des contenus telles que les DRM. Ni les contraintes qu’ils imposent aux utilisateurs et aux développeurs, ni la législation bien trop sévère que cela entraîne dans des pays comme les États-Unis.

Nous avons tous envie d’un Web ouvert, riche et fiable. Nous voulons un Web ouvert aux innovateurs et aux bidouilleurs, aux créateurs de ressources et aux explorateurs de culture. Nous voulons un Web qui soit riche en contenu, à prendre dans le double sens de la lecture mais aussi de l’écriture. Nous voulons un Web qui soit universel, dans le sens qu’il puisse tout contenir. Comme Michael Dertouzos, un ancien responsable du Laboratoire de sciences informatiques ici au MIT, avait l’habitude de le dire : un marché de l’information, où les gens peuvent acheter, vendre ou échanger librement de l’information. Pour être universel, le Web doit être ouvert à toutes sortes d’entreprises et de modèles d’entreprise.

Les principes de conception d’HTML donnent une aide précieuse sur les priorités des parties concernées : « en cas de conflit, prenez d’abord en compte les utilisateurs puis les auteurs, ensuite les développeurs, puis ceux qui élaborent les spécifications et enfin l’aspect purement théorique. En d’autres termes, le coût (ou les difficultés) supporté par l’utilisateur doit avoir la priorité sur celui supporté par les auteurs, qui aura à son tour la priorité sur celui associé à l’implémentation, lequel aura la priorité sur le coût pour les rédacteurs de spécifications, lui-même devant avoir plus de poids que les propositions de modification fondées sur de seules considérations théoriques. Il va de soi que les améliorations qui apportent satisfaction à plusieurs parties simultanément sont préférables.

Ainsi mettons-nous l’utilisateur au premier plan. Mais des utilisateurs différents ont des préférences différentes voire parfois incompatibles : certains utilisateurs du Web aiment regarder des films à succès, d’autres aiment jouer avec le code. La meilleure solution sera celle qui satisfera tout le monde, et nous la cherchons encore. Si nous ne pouvons pas la trouver, nous recherchons au moins la solution qui portera le moins préjudice aux besoins exprimés, qu’il s’agisse des utilisateurs, auteurs, développeurs, et tout autre partie de l’écosystème.

Les débats à propos de l’intégration de la protection des contenus vidéos en général et d’EME en particulier, à la standardisation du W3C sont nombreux et variés. Lorsque nous avons discuté du problème au sein du Groupe Architecture Technique du W3C plus tôt cette année, j’ai noté sur le tableau une liste des différents arguments, qui était déjà relativement longue, et cette liste ne s’est pas réduite avec le temps. Ces réflexions s’appuient sur le comportement supposé des utilisateurs, concepteurs de navigateur, distributeurs de contenu multimédia, etc. selon différents scénarios qui ne peuvent être que des hypothèses. De plus elles impliquent de comparer des choses très différentes : la fluidité d’une interface utilisateur et le danger que les programmeurs puissent être emprisonnés. Il n’y aura donc pas d’issue pour nombre de ces discussions avant un long moment. Je voudrais remercier ici tout ceux qui, avec écoute et considération, se sont investis dans cette discussion et j’espère que vous continuerez ainsi.

Permettez-moi de prendre quelques éléments, en aucun cas une liste exhaustive.

Le W3C est un lieu où l’on discute des évolutions potentielles de la technologie. Et c’est la charte du Groupe de travail HTML qui cadre le champ de la discussion. Le W3C n’a ni l’intention ni le pouvoir de dicter ce que les navigateurs ou les distributeurs de contenu peuvent faire. Exclure cette question de la discussion n’a pas pour effet qu’elle cesse de se poser pour les systèmes de tout un chacun.

Certains arguments en faveur de l’inclusion peuvent se résumer comme suit : si protection du contenu des vidéos il doit y avoir, mieux vaut que cette protection soit discutée de manière ouverte au sein du W3C, que chacun utilise autant que possible un standard ouvert et interopérable, qu’elle soit intégrée dans un navigateur dont le code source soit ouvert, et disponible dans un ordinateur classique plutôt que dans un appareil spécialisé. Ce sont là des arguments clés en faveur de l’inclusion de ce sujet aux discussions.

En tant qu’utilisateur, personne n’aime les DRM, quel que soit l’endroit où ils surgissent. Toutefois, ça vaut le coup de réfléchir à ce que nous n’aimons pas dans les systèmes de DRM existants, et comment l’on pourrait construire un système plus ouvert et plus juste. Si nous, les programmeurs qui concevons et construisons les systèmes Web, devons étudier quelque chose qui sera très coûteux à de nombreux niveaux, que pouvons-nous demander en échange ?

Le débat vient à peine de commencer. Le Restricted Media Community Group est un forum pour discuter de cela. La liste de diffusion www-tag@w3.org est un bon moyen de parler de l’architecture du Web en général, et il y a aussi le HTML Working Group et le Web Copyright Community Group. Et puis il y a également tous ces commentaires au message de Jeff ou à cet article, bien que je ne puisse pas être en mesure de répondre à tout le monde.

Continuons tous à participer à la création d’une plateforme Web puissante, reposant sur des standards ouverts. Le cas de l’utilisation d’un contenu vidéo protégé est un défi à relever. Nous pensons que cette discussion nous aidera à atteindre ce but, même s’il reste encore beaucoup à faire pour arriver au niveau d’ouverture que j’ai personnellement tenté d’atteindre depuis 25 ans et que le W3C poursuit depuis sa création.

Timbl

Source :

• Le W3C entérine les DRM (SebSauvage)
• Voir aussi sur le Framablog : Geektionnerd – DRM et HTML5

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)

Source : Levée de boucliers contre l’arrivée des DRM au sein du HTML5 (Numerama)

Voir aussi la réponse de Cory Doctorow à Berners-Lee, traduite sur le Framablog : la guerre du copyright menace la santé d’Internet

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)

La question de savoir si oui ou non il y a aura des DRM dans le HTML5 est absolument fondamentale pour le Web de demain. Ce n’est pas une question tehnique, c’est une question de partage (ou pas).

C’est pourquoi nous vous avions proposé la cinglante réponse de Cory Doctorow à Tim Berners-Lee. C’est pourquoi aussi nous avons traduit cet article très clair de l’Electronic Frontier Foundation qui en appelle à se mobiliser, par exemple en signant la pétition lancée par la Free Software Foundation.

Défense du web ouvert : pas de DRM dans les standards W3C

Defend the Open Web: Keep DRM Out of W3C Standards

Peter Eckersley et Seth Schoen – 20 mars 2013 – EFF.org
(Traduction : tcit, ZeHiro, audionuma, goofy, audionuma, Asta)

Un nouveau front est ouvert dans la bataille contre les DRM. Ces technologies, qui sont censées permettre le respect du copyright, n’ont jamais permis de rémunérer les créateurs. Par contre, que ce soit volontairement ou par accident, leur véritable effet est d’interférer avec l’innovation, l’usage légitime, la concurrence, l’interopérabilité et notre droit légitime à posséder nos biens.

C’est pourquoi nous avons été consternés d’apprendre qu’une proposition est actuellement à l’étude au sein du groupe de travail HTML5 du World Wide Web Consortium (W3C) pour intégrer les DRM dans la prochaine génération de standards fondamentaux du Web. Cette proposition est dénommée Encrypted Media Extensions (Extensions pour les médias chiffrés, EME). Son adoption représenterait une évolution catastrophique et doit être stoppée.

Durant les deux dernières décennies, il y a eu un combat continu entre deux visions de la manière dont les technologies d’Internet doivent fonctionner. L’une des philosophies est que le Web doit être un écosystème universel basé sur des standards ouverts et que quiconque peut implémenter sur un pied d’égalité, n’importe où, n’importe quand, sans permissions ni négociations. C’est cette tradition technologique qui a produit HTML et HTTP pour commencer, et des innovations qui ont marqué leur époque comme les wikis, les moteurs de recherche, les blogs, les messageries sur le Web, les applications écrites en JavaScript, les cartes en ligne réutilisables, et une centaine de millions de sites Web que ce paragraphe serait trop court pour énumérer.

L’autre vision est incarnée par les entreprises qui ont essayé de s’approprier le contrôle du Web avec leurs propres extensions propriétaires. Cela s’est manifesté avec des technologies comme Flash d’Adobe, Silverlight de Microsoft, et des pressions venant d’Apple, des fabricants de téléphonie, et d’autres, en faveur de plateformes hautement restrictives. Ces technologies sont conçues pour n’être disponibles qu’auprès d’une seule source ou nécessiter une autorisation pour toute nouvelle implémentation. À chaque fois que ces techniques sont devenues populaires, elles ont infligé des dommages aux écosystèmes ouverts qui les entourent. Les sites Web qui utilisent Flash ou Silverlight ne peuvent en général pas être référencés correctement, ne peuvent pas être indexés, ne peuvent être traduits automatiquement, ne peuvent être consultés par les personnes en situation de handicap, ne fonctionnent pas sur tous les terminaux de consultation, et posent des problèmes de sécurité et de protection de la vie privée à leurs utilisateurs. Les plateformes et les équipements qui restreignent la liberté de l’utilisateur freinent inévitablement des innovations importantes et entravent les compétitions sur le marché.

La proposition EME est entachée par plusieurs de ces problèmes car elle abandonne explicitement la responsabilité de la question de l’interopérabilité et permet aux sites Web de requérir des logiciels propriétaires de tierces-parties, voire du matériel ou un système d’exploitation spécifiques (tout cela mentionné sous le nom générique de « content decryption modules » (« modules de déchiffrage du contenu », CDM), dont aucun n’est spécifié par EME). Les auteurs d’EME soutiennent que les CDM, ce qu’ils font et d’où ils viennent, est totalement hors du champ d’EME, et qu’EME ne peut être considéré comme un DRM puisque tous les CDM ne sont pas des DRM. Néanmoins, si l’application client ne peut prouver qu’elle exécute le module propriétaire spécifique que le site réclame, et n’a donc pas de CDM qualifié, elle ne peut afficher le contenu du site. De manière perverse, c’est exactement à l’opposé des raisons qui font que le W3C existe. Le W3C est là pour créer des standards lisibles, qui soient implémentables par le public et qui garantissent l’interopérabilité, et non pas pour favoriser une explosion de nouveaux logiciels mutuellement incompatibles et de sites et services qui ne sont accessibles qu’à certains équipements ou applications. Mais la proposition EME va justement apporter cette dynamique anti-fonctionelle dans HTML5, risquant même un retour au « bon vieux temps d’avant le Web » où l’interopérabilité était volontairement restreinte.

Étant donné l’extrême méfiance de la communauté des standards ouverts à l’encontre des DRM et de leurs conséquences sur l’interopérabilité, la proposition de Google, Microsoft et Netflix affirme que « aucun DRM n’est ajouté à la spécification HTML5 » par EME. C’est un peu comme dire « nous ne sommes pas des vampires, mais nous allons les inviter chez vous ».

Les promoteurs d’EME semblent affirmer que ce n’est pas un modèle de DRM. Mais l’auteur de la spécification Mark Watson a admis que « effectivement, nous nous intéressons aux cas d’utilisation que la plupart des gens appellent DRM » et que les implémentations nécessiteront par nature des aspects secrets qui sont hors du champ de la spécification. Il est difficile de soutenir que EME n’a rien à voir avec les DRM.

Les propositions sur les DRM au W3C sont là pour une raison simple : il s’agit d’une tentative d’apaiser Hollywood, qui est irrité par Internet au moins depuis que le Web existe, et a toujours réclamé qu’une infrastructure technique avancée permette de contrôler ce qui se passe sur l’ordinateur du public. Le sentiment est que Hollywood ne permettra jamais la distribution des films sur le Web s’il n’est pas possible de les accompagner de DRM. Mais la crainte que Hollywood puisse récupérer ses billes et quitter le Web est illusoire. Chaque film que Hollywood distribue est déjà disponible pour ceux qui veulent réellement pirater une copie. Une énorme quantité de musique est vendue par iTunes, Amazon, Magnatunes et des dizaines d’autres sites sans qu’il n’y ait besoin de DRM. Les services de streaming comme Netflix et Spotify ont réussi parce qu’ils proposent une expérience plus pratique que le piratage, pas parce que les DRM favorisent leur modèle économique. La seule explication raisonnable pour que Hollywood réclame des DRM est que les producteurs de films veulent contrôler comment les technologies grand public sont conçues. Les producteurs de films ont utilisé les DRM pour faire respecter des restrictions arbitraires sur leurs produits, comme l’interdiction de l’avance rapide ou des restrictions géographiques, et ont créé un système complexe et onéreux de « mise en conformité » pour les entreprises technologiques qui donnent à un petit groupe de producteurs de contenu et aux grandes sociétés du secteur des technologies un droit de veto sur l’innovation.

Trop souvent, les entreprises technologiques se sont lancées dans une course l’une contre l’autre pour bâtir un fouillis logiciel qui corresponde aux caprices de Hollywood, abandonnant leurs utilisateurs dans cette course. Mais les standards ouverts du Web sont un antidote à cette dynamique, et ce serait une terrible erreur pour la communauté du Web de laisser la porte ouverte à la gangrène anti-technologique de Hollywood dans les standards W3C. Cela minerait l’objectif principal de HTML5 : créer un éco-système ouvert alternatif à toutes les fonctionalités qui manquaient dans les standards Web précédents, sans les problèmes de limitations des équipements, d’incompatibilité entre plateformes et l’absence de transparence qui fut créée par des plateformes comme Flash. HTML5 était censé être mieux que Flash, et en exclure les DRM est exactement ce qui le rendrait meilleur.

Lors du tout récent SXSW, Sir Tim Berners-Lee, répondant à une question, s’est montré favorable à l’introduction de DRM dans le HTML5, c’est-à-dire directement dans le code des pages Web.

Ceci a déçu beaucoup de monde, à commencer par Cory Doctorow qui lui a répondu dans les colonnes du Guardian, traduit ci-dessous pour nos soins.

Ce que j’aurais souhaité que Tim Berners-Lee comprenne au sujet des DRM

What I wish Tim Berners-Lee understood about DRM

Cory Doctorow – 12 mars 2013 – The Guardian (Blog Tchnology)
(Traduction Framalang : catalaburro, Alpha, Alpha, lum’, Tito, goofy, peupleLà, lamessen, penguin + anonymes)

Ajouter des DRM au standard HTML aura des répercussions importantes qui seront incompatibles avec les règles fondamentales du W3C.

À la suite de son discours d’introduction au récent SXSW, l’inventeur du Web Tim Berners-Lee a répondu à une question concernant le projet controversé d’ajouter des DRM à la prochaine version du HTML. Le standard HTML5, qui est en ce moment en débat au W3C (World Wide Web Consortium), est le dernier en date des champs de bataille dans la longue guerre pour la conception des ordinateurs personnels. Berners-Lee a soutenu ce projet en prétendant que, sans les DRM, une part croissante du Web serait verrouillée dans des formats comme le Flash, impossibles à lier et à soumettre à la recherche.

Certains membres de l’industrie du divertissement ont longtemps entretenu le doux rêve d’ ordinateurs conçus pour désobéir à leurs propriétaires, dans une stratégie globale de maximisation des profits qui s’appuie sur la possibilité de vous faire payer pièce après pièce pour avoir le droit d’utiliser les fichiers stockés sur vos disques durs.

Il est notoire que l’industrie a réussi à convaincre les fabricants de lecteurs de DVD d’ajouter une limitation au lecteur pour vous empêcher de lire un DVD sur un continent si vous l’avez acheté dans un autre. Pour que cela fonctionne, les lecteurs de DVD ont dû être conçus pour cacher les programmes qui les faisaient tourner. Ainsi les propriétaires de lecteurs de DVD ne pouvaient tout simplement pas arrêter la fonction de « vérification de zone ». Les lecteurs devaient aussi être conçus pour cacher des fichiers à leurs propriétaires, de telle manière que les utilisateurs ne puissent pas trouver le fichier contenant la clé de déchiffrement afin de l’utiliser pour déverrouiller le DVD sur d’autres lecteurs, ceux qui ne vérifieraient pas la compatibilité de zone du DVD.

Deux questions importantes découlent de cet exemple historique. Tout d’abord, cela a-t-il fonctionné ? et deuxièmement, pourquoi diable les fabricants ont ils été d’accord avec ces limitations ? Ces deux questions sont importantes à poser ici.

Est-ce que le zonage géographique a fonctionné ? Pas du tout. Après tout, cacher des fichiers et des processus dans l’ordinateur que le « méchant » peut tout à fait embarquer avec lui dans un labo ou au bureau est complètement vain. Si Berners-Lee pense qu’ajouter des secrets aux navigateurs web auxquels les possesseurs d’ordinateurs ne pourront accéder permettra d’une quelconque manière de créer les marchés dont l’industrie du divertissement a soi-disant besoin pour créer de nouveaux modèles économiques, il se trompe.

Plus important encore : pourquoi les fabricants sont-ils d’accord pour ajouter des restrictions à leurs matériels ? Le zonage est le contraire d’une fonctionnalité, un « produit » qui n’a pas pour but d’être vendu. Vous ne pouvez pas vendre plus de lecteurs DVD en ajoutant un autocollant qui dit : « Nouvelle version, avec des restrictions par zones géographiques ! »

Les pièges du brevet

En clair, c’est l’industrie qui a établi un besoin légal pour l’établissement des DRM sur les lecteurs DVD. Lorsque les organismes à l’origine des DRM se rassemblent, ils cherchent à identifier un « lien de propriété intellectuelle », bien souvent un brevet. Si un brevet entre en jeu lors du décodage d’un format de fichier, alors le brevet peut être lié à l’application des termes de la licence, ce qui peut être utilisé pour contraindre les fabricants.

En d’autres termes, si un brevet (ou des brevets) peut être inclus dans le système de décodage des DVD, il est possible de menacer les fabricants d’un procès pour violation de brevet,à moins qu’ils n’achètent une licence d’utilisation. Les licences de brevet sont gérées par la Licensing Authority (LA) (NdT : Consortium regroupant les détenteurs de brevets sur la technologie en question, ici la MPEG-LA) qui crée des normes de contrat de licence. Ces termes incluent toujours une liste de fonctionnalités que les fabricants ne doivent pas implémenter (par exemple il ne leur est pas possible d’ajouter une fonctionnalité « sauvegarder sur un disque dur » à un lecteur DVD); et une liste de fonctionnalités négatives que les fabricants doivent implémenter (par exemple l’ajout obligatoire d’une fonction : « vérifier la zone » au lecteur).

Par ailleurs, tous les accords de licence de DRM s’accompagnent d’un ensemble de règles de « robustesse » qui incite les fabricants à concevoir leur produit de façon à ce que leur propriétaire ne puisse ni voir ce que font ces DRM ni les modifier. Cela a pour but d’empêcher que le possesseur d’un dispositif n’en reconfigure les propriétés pour faire des choses interdites (« sauvegarder sur le disque ») ou pour ignorer des choses obligatoires (« vérifier la région »).

Ajouter les DRM au standard HTML aura des répercussions étendues qui sont incompatibles avec les règles les plus importantes du W3C et avec les principes qui tiennent particulièrement à cœur à Berners-Lee.

Par exemple, le W3C a fait avancer les organismes de normalisation en insistant sur le fait que les standards ne devaient pas être gênés par les brevets. Lorsque des membres du W3C détiennent des brevets sur une partie d’un standard, ils doivent promettre à tous les utilisateurs de fournir une licence qui ne possède pas de conditions trop contraignantes. Cependant, les DRM nécessitent des brevets ou des éléments sous licence dont le seul objectif est d’ajouter des conditions contraignantes aux navigateurs.

La première de ces conditions – la « robustesse » contre les modifications de l’utilisateur final – est une exclusion totale de tous les logiciels libres (ces logiciels qui, par définition, peuvent être modifiés par leurs utilisateurs). Cela signifie que les deux technologies de navigateurs web les plus populaires, WebKit (utilisé avec Chrome et Safari) et Gecko (utilisé avec Firefox et ses navigateurs apparentés), pourraient légalement se voir interdire d’être intégré dans l’une de ces « normes » qui sortiraient du W3C.

Copie moi si tu peux

Plus encore, les DRM sont parfaitement inefficaces pour empêcher la copie. Je suspecte Berners-Lee d’en être parfaitement conscient. Quand les geeks minimisent les craintes autour des DRM, ils disent souvent des choses telles que : « He bien, je peux les contourner et de toute façon ils reviendront à la raison tôt ou tard vu que cela ne fonctionne pas, non ? ». Chaque fois que Berners-Lee raconte l’histoire des débuts du Web, il insiste sur le fait qu’il a pu inventer le Web sans demander la moindre permission. Il utilise cela comme une parabole pour expliquer l’importance d’un Internet ouvert et neutre. Mais il échoue à comprendre que la raison d’être des DRM est d’obliger à demander une permission pour innover.

Car limiter la copie n’est qu’une raison superficielle à l’ajout de DRM à une technologie. Les DRM échouent complètement lorsqu’il s’agit d’empêcher la copie, mais sont remarquablement efficaces pour éviter toute innovation. En effet les DRM sont couverts par les lois anti-contournement telles que la célèbre DMCA de 1998 (US Digital Millennium Copyright Act) et l’EUCD de 2002 (EU Copyright Directive) ; chacune d’elle fait du contournement de DRM un crime, même si vous n’enfreignez aucune autre loi. Concrètement, cela signifie que vous devez demander la permission à une autorité de licence de DRM pour ajouter ou modifier n’importe quelle fonctionnalité, ce que les termes de la licence vous interdisent de faire.

Comparons les DVD aux CD. Les CD n’avaient pas de DRM, il était donc légal d’inventer des technologies comme l’iPod ou iTunes qui extrayaient, encodaient et copiaient la musique pour un usage privé. Les DVD avaient des DRM, il était donc illégal d’en faire quoi que ce soit de plus et depuis presque 20 ans qu’ils sont apparus, aucune technologie légale n’a vu le jour sur le marché pour faire ce que iTunes et l’iPod font depuis 2001. Une entreprise a essayé de lancer un jukebox primitif à DVD combiné à un disque dur et fut poursuivie pour cette activité commerciale. 20 ans de DVD, zéro innovation. Bon, les DRM n’ont pas empêché les gens de créer des copies illégales de DVD (bien entendu !), mais elles ont complètement empêché l’émergence sur le marché de tout produit légal et innovant, et nous ne sommes pas près d’en voir la fin.

Prêts à vous faire les poches

C’est ce vers quoi le W3C essaie de faire tendre le Web. Et Berners-Lee, avec ses remarques, en prend la responsabilité. Un état où chaque amélioration est vue comme une occasion d’instaurer un péage. Un Web construit sur le modèle économique de l’infection urinaire : plutôt que d’innover dans un flot sain, chaque nouvelle fonctionnalité doit venir d’une petite goutte contractée et douloureuse : quelques centimes si vous voulez la lier à un temps spécifique de la vidéo, encore quelques centimes si vous souhaitez intégrer un lien provenant de la vidéo dans une page web, encore plus si vous souhaitez mettre la vidéo sur un autre appareil ou la décaler dans le temps, et ainsi de suite.

Le W3C étant l’organisme principal qui normalise le Web, son action repose sur une confiance énorme à la fois sacrée et significative. Le futur du Web est le futur du monde, car tout ce que nous faisons aujourd’hui implique le net et ce sera tout aussi nécessaire pour tout ce que nous ferons demain. À présent, il souhaite brader cette confiance, uniquement parce que les principaux fournisseurs de contenu verrouilleront leur « contenu » en utilisant Flash s’ils ne parviennent pas à obtenir de veto sur l’innovation issue du Web. Cette menace n’est pas nouvelle : les grands studios avaient promis de boycotter la télévision numérique américaine si elle ne rendait pas les DRM obligatoires. Les tribunaux américains ont refusé de leur accorder cette aubaine, et pour autant, la télévision numérique continue de fonctionner (si seulement Otcom et la BBC avaient tenu compte de cet exemple avant de vendre la télévision britannique aux studios américains en ce qui concerne nos propres normes de télévision numérique HD).

Flash est déjà hors course. Comme Berners-Lee vous le dira lui-même, la présence de plate-formes ouvertes, où l’innovation n’a pas besoin d’autorisation, est la meilleure façon d’inciter le monde à se connecter à vous. Un Web ouvert crée et distribue tant de valeur que chacun s’est mis à l’utiliser, délaissant ainsi les écosystèmes contrôlés semblables à Flash, entouré d’AOL et autres systèmes défaillants. Les gros studios ont plus besoin du Web que le Web n’a besoin d’eux.

Le W3C a le devoir d’envoyer au diable les colporteurs de DRM, tout comme les tribunaux américains l’ont fait lors de l’affaire de la TV numérique. Il n’y a pas de marché pour les DRM, pas de cause d’utilité publique qui justifie l’octroi d’un droit de veto à d’obscurs géants des médias qui ne voient pas plus loin que le bout de leur nez et qui rêvent d’un monde où chaque fois que vous cliquez, vous passez à la caisse et où la difficulté d’utilisation est quelque chose qui arrivent aux autres et pas à eux.

Crédit photo : Etech (Creative Commons By)

Vous avez peut-être remarqué dans les derniers articles publiés sur le framablog que quelques illustrations à l’humour approximatif étaient signées Gégé, le générateur de Geektionnerd. Ce petit jeu graphique vous est aujourd’hui offert en libre-service par Framasoft.

D’où vient-il ?

C’est une conception des Mozilla Labs dont on peut trouver toute la petite histoire et les caractéristiques techniques sur ce blog de Mozilla hacks. Pour simplifier, Willian Carvalho a voulu réaliser avec Canvas (traitement de l’image en JavaScript) ce qui existait seulement en Flash. C’est une chouette et amusante démonstration de ce qu’on peut faire désormais avec le HTML5, que Mozilla défend et promeut comme le langage du Web, plateforme ouverte de développement…

La version Framalab

C’est Cyrille (avec l’aide de Quentin pour la mise en ligne) qui a réalisé une adaptation francophone, avec la complicité de Simon “Gee” Giraudot qui a fourni les images. Vous pouvez trouver les sources librement disponibles sur le github, n’hésitez pas à le forker, à vous installer votre propre version avec vos images et à fabriquer vous-mêmes des bandes dessinées libres.

Comment ça marche ?

C’est vraiment simple et intuitif. Rendez-vous sur la page du générateur de Geektionnerd, choisissez et déplacez les éléments graphiques, saisissez du texte pour vos “bulles”, redimensionnez les éléments avec les flèches haut/bas du clavier et inversez-les avec les flèches droite/gauche. Vous pouvez enregistrer facilement vos créations ensuite.

…d’ailleurs n’hésitez pas à en faire profiter tout le monde, peut-être publierons-nous vos meilleures réalisations ici, qui sait ?

Et Simon Giraudot, le voilà piraté ? Qu’en dit-il ?

Eh bien nous lui avons posé la question…

Quelle a été ta première réaction quand tu as découvert ce générateur ?

Très bonne ! Lorsque Cyrille a partagé la première version du générateur sur la liste de l’association Framasoft, tout le monde a commencé à jouer avec et à partager ses créations sur la liste. C’est assez marrant de voir mes personnages avec des mots qui ne sont pas les miens dans leur bouche !

D’une certaine façon c’est la continuité logique des créations libres que tu as réalisées avec la série des Geektionnerds ?

À priori c’est pareil. D’ailleurs, les dessins du générateur ne sont pas des dessins « exclusifs », ils sont en fait issus d’articles du blog (donc ils sont déjà sous CC-By-Sa !). Mais oui, c’est l’exacte continuité de ce que je propose dans le Geektionnerd. J’ai placé mes œuvres sous licence libre par conviction, parce que c’est comme ça que je vois « l’art » de manière générale. Le fait que les dessins soient librement modifiables n’est qu’une liberté, mais ça ne veut pas dire que vous allez forcément l’utiliser : grâce à ce générateur, on vous propose d’expérimenter cette liberté et de créer vos propres BD dérivées du Geektionnerd !

Tout le monde peut s’amuser avec ce petit générateur que nous te remercions d’avoir alimenté de tes dessins. Penses-tu que c’est juste un gadget sympathique ou que ça peut déclencher des vocations ?

L’un n’empêche pas l’autre, non ? 😉 Blague à part, c’est surtout un outil de loisir, à mon sens. Ça reste du bidouillage de dessins et de textes, je ne me verrais pas réaliser une histoire complète avec ça, par exemple. Mais après, qui sait ? Avec les licences libres, les possibilités sont infinies : imaginez une personne qui a une idée géniale de scénario pour une BD, mais ne sait absolument pas dessiner. Grâce aux contributions que l’on met dans le pot commun de l’art libre (et je ne parle pas que de moi ici mais de tous les artistes libres), il pourrait tout à fait récupérer une énorme base de données de dessins et les arranger comme il le veut pour correspondre à son scénario. Sympa, non ?

Si l’on va un peu plus loin, ce genre de pratiques implique la fin de l’œuvre unique, puisque chacun peut utiliser, copier, remixer, re-créer et diffuser des comic strips ? l’analogie avec les 4 libertés du logiciel libre est frappante, non ?

Oui, c’est exactement ça. Pour autant, il ne faut pas voir ça comme une trahison de l’œuvre ou un manque de respect de l’auteur (ce genre d’argument revient souvent lorsqu’on parle de modifier les œuvres sans l’autorisation de l’auteur – un des principes d’une licence libre). L’œuvre originale, le Geektionnerd, reste une « œuvre unique », si l’on veut. La différence avec une œuvre sous régime de droit d’auteur classique, ce n’est pas que vous allez vous l’approprier et en faire ce que vous voulez : ça, honnêtement, vous le faites aussi avec des œuvres protégées.

La différence, c’est que là, non seulement personne ne viendra vous demander des comptes et vous traiter de voleur, mais en plus, on vous y encourage ! Tu parles de l’analogie avec les 4 libertés du logiciel libre : je pense aussi, personnellement, aux deux modèles que propose Florent Latrive dans son livre Du bon usage de la piraterie. Il explique que, classiquement, on aimait considérer les artistes comme des  « génies romantiques » qui avaient une inspiration naturelle et quasi-divine. Mais l’artiste est en fait plus proche du « hacker », qui s’approprie toutes les informations qui l’entourent pour créer quelque chose de nouveau. Tous les artistes passent leur temps à reprendre, copier, réutiliser les œuvres du passé. La licence libre ne fait que se mettre en accord avec cette réalité qui est pourtant loin d’être spécifique à l’art libre ! On connait la fameuse citation de Picasso, « Les bons artistes copient, les grands artistes volent ». Aurait-il mis ses œuvres sous licence libre si cela avait existé à son époque ? C’est une autre question 😉

Le système d’exploitation Firefox OS peut libérer nos smartphones et autres tablettes en apportant une alternative à Apple et Android, un peu comme l’a fait le navigateur Firefox avec le Web en son temps.

Nous vous proposons ci-dessous le témoignage passionné (et passionnant) d’un de ses développeurs.

Il y a quelque chose de magique dans Firefox OS

There is something magical about Firefox OS

Rob Hawkes – 12 septembre 2012 – Blog personnel
(Traduction : Un gros collectif de bénévoles nocturnes issus de Framalang, Identi.ca et Twiiter)

Dans ce billet, je parle du projet Firefox OS, ce qu’il signifie, ce que réserve le futur, et ce qu’il a d’un peu magique.

Au cours des quinze derniers mois, j’ai passé de plus en plus de temps à travailler sur le dernier projet de Mozilla : Firefox OS. Rapidement, je suis tombé amoureux de ce projet et de ses valeurs, à un point que je n’avais jamais connu pour une nouvelle plateforme.

Soyons clairs ; Firefox OS est le début de quelque chose d’énorme. C’est une révolution en marche. Une bouffée d’air frais. Un point culminant de la technologie. C’est magique, et ça va tout changer.

Qu’est-ce-que Firefox OS ?

Pour ceux qui seraient un peu perdus, voici l’essentiel en deux mots :

Firefox OS est un nouveau système d’exploitation pour mobile développé par le projet de Mozilla : Boot to Gecko (B2G). Il utilise un noyau Linux et boote sur un environnement basé sur Gecko, ce qui permet aux utilisateurs de lancer des applications entièrement développées en HTML, JavaScript, et d’autres API Web ouvertes.

Mozilla Developer Network

En bref, Firefox OS consiste à récupérer les technologies dans les coulisses du Web, telles que JavaScript, et à les utiliser pour produire un système d’exploitation entier. Prenons quelques instants pour y réfléchir… un système d’exploitation pour mobile basé sur JavaScript !

Pour ce faire, une version légèrement modifiée de Gecko (le moteur derrière Firefox) a été créée dans le but d’y intégrer les différentes API JavaScript relatives à la téléphonie, comme WebTelephony pour faire des appels, WebSMS pour envoyer des messages, et la Vibration API pour… faire vibrer le téléphone.

Mais tout génial qu’il soit, Firefox OS représente plus qu’un ensemble de technologies Web dernier cris utilisées de façon démente. C’est aussi l’association de nombreux autres projets de Mozilla autour d’un concept unique — le Web en tant que plateforme. Certains de ces projets intègrent nos initiatives Open Web Apps et Persona, notre solution d’authentification sur le web (anciennement BrowserID). C’est absolument fascinant de voir tous ces différents projets de Mozilla s’unir de façon cohérente en partageant une seule et même vision.

Je n’irai pas plus loin dans la description du projet vu que le but de cet article n’est pas de le faire dans le détail, même si de plus amples informations peuvent être trouvées sur les pages de Firefox OS sur MDN. Je vous invite vivement à les lire.

Pourquoi Firefox OS ?

Vous pouvez vous dire « Ça a l’air bien, mais pourquoi utiliser JavaScript pour faire un téléphone ? » Et vous avez raison, c’est une question réellement importante. La bonne nouvelle est qu’il y a de nombreuses raisons à cela, autres que de faire la joie des développeurs Web.

Les deux principales raisons sont que Firefox OS répond à un manque dans le marché du téléphone, et qu’il constitue une alternative au paysage privativeur, restreint et contraignant du marché actuel.

Combler un manque dans le marché du téléphone

Ce n’est un secret pour personne : les smartphones sont ridiculement chers, même dans les régions du monde dont le niveau de vie est considéré comme élevé. Mais si vous les trouvez chers dans les pays qui ont les moyens de se les offrir, alors pensez un peu à ce que représente un iPhone 4S 16 Go qui vaut 615 £ dans un pays émergent comme le Brésil. C’est 100 £ plus cher que le même téléphone en Angleterre !

En fait, ces prix plus élevés au Brésil sont principalement dus aux fortes taxes d’importation. Apple semble vouloir éviter ceci dans le futur en construisant des usines dans le pays. Quoi qu’il en soit, cela montre bien que les appareils haut de gamme et hors de prix ne sont pas toujours une solution pour tous les pays. Laissons de côté le fait que dans certaines sociétés vous n’avez pas forcement l’envie d’exhiber publiquement un téléphone qui a le même prix qu’une petite voiture.

A l’heure actuelle, que faites-vous si vous souhaitez acheter un smartphone sans débourser une somme astronomique ? Vous pouvez vous tourner vers des terminaux Android d’entrée de gamme, mais ils sont souvent bien trop lents.

Heureusement, c’est là que Firefox OS intervient.

Le but de Firefox OS n’est pas de rivaliser avec des appareils haut de gamme mais d’offrir des smartphones milieu de gamme au prix de l’entrée de gamme. Ce n’est pas une plaisanterie.

Bonnie Cha

Firefox OS répond parfaitement aux attentes du marché : il offre la même expérience d’utilisation sur un matériel d’entrée de gamme que le fait Android sur du matériel plus performant. Et ce n’est pas une blague.

Par exemple, je teste en ce moment même des jeux écrits en JavaScript sur un terminal fonctionnant sous Firefox OS et qui coûte une soixantaine d’euros (clairement, un appareil très bas de gamme). On pourrait donc s’attendre à ce qu’ils fonctionnent très mal, mais non seulement ils tournent bien plus rapidement que les mêmes jeux s’exécutant dans un navigateur internet Android (Firefox ou Chrome) sur le même appareil, mais ils tournent même aussi vite, si ce n’est plus, que les mêmes jeux sous un navigateur Android sur une machine bien plus performante qui coûte 4 ou 5 fois plus cher.

Pourquoi de telles améliorations de performance par rapport aux navigateurs sur Android pour des appareils identiques ? Grâce à l’absence de couche intermédiaire entre Gecko et le hardware, permettant à des choses comme le JavaScript de tourner à plein potentiel, et en finir avec le mythe du JavaScript lent !

De telles performances de JavaScript sur un matériel aussi abordable est une des raisons qui me font penser que Firefox OS annonce le début de quelque chose d’énorme.

Je dois cependant préciser que Mozilla n’est pas forcément sur le point de lancer un appareil à 60 € : il s’agit seulement d’un terminal en particulier que nous utilisons pour le développement et les tests.

Fournir une alternative : une plateforme ouverte

La seconde réponse à la question « Pourquoi Firefox OS ? » est qu’il s’agit non seulement de créer une plateforme mobile alternative et ouverte, mais également d’essayer d’agir pour influencer les grands acteurs du mobile à changer les choses.

La mission de Mozilla depuis ses débuts en 1998, d’abord en tant que projet autour d’un logiciel, puis en tant que fondation et entreprise, a consisté à fournir des technologies ouvertes capables de rivaliser avec les produits des entreprises dominantes.

Steve Lohr

Firefox a bouleversé le marché du navigateur et montré aux utilisateurs qu’il existe une alternative. Et c’est ce que Mozilla s’efforce de reproduire avec Firefox OS, en permettant à chacun de pouvoir choisir sa façon d’utiliser le Web.

Cette fois-ci, c’est le Web mobile qui est menacé. Pas par Microsoft, mais par Apple et Google, qui sont les plateformes dominantes pour smartphones. Avec leurs applications natives, leurs catalogues d’applications propriétaires, et leurs règles imposées aux développeurs, Apple et Google relèguent le Web à l’arrière-plan.

Thomas Claburn

Sur les téléphones, le domaine qui nécessite le plus de travail est la portabilité des applications…

Avec l’excitation autour des applications mobiles, ils donnent l’impression d’être en retard sur un point : ils restreignent leurs utilisateurs à un système d’exploitation particulier, et aux appareils qui le supportent. Le Web, au contraire, a évolué de façon à ce que le contenu soit ressenti de la même façon, quel que soit le matériel. Mozilla, créateur du navigateur Web Firefox, est déterminé à rendre cela vrai également pour les smartphones.

Don Clark

Ce que Firefox OS cherche à faire, c’est utiliser l’omniprésence du Web pour créer une plateforme qui permet aux applications d’être utilisées aussi bien sur un téléphone portable, un ordinateur, une tablette, ou depuis n’importe quel appareil possédant un navigateur. Ne serait-ce pas génial de pouvoir reprendre sur votre ordinateur la partie d’Angry Birds à laquelle vous étiez en train de jouer sur votre téléphone ? Moi, j’adorerais !

Un rêve à portée de bidouille pour les développeurs

Une dernière raison pour laquelle Firefox OS est nécessaire, c’est que nous n’avons pour le moment aucune plateforme mobile aussi bidouillable (NdT hackable) (il est plus ou moins possible de personnaliser Android, mais ce n’est pas si facile).

Comme Firefox OS est construit avec HTML, JavaScript et CSS, vous n’avez besoin que de connaissances élémentaires en développement Web pour changer complètement l’expérience offerte par l’appareil. En éditant une simple ligne de CSS, vous pouvez totalement modifier l’apparence des icônes de l’écran d’accueil ; ou encore, vous pouvez ré-écrire les fichiers internes JavaScript qui gèrent les appels téléphoniques.

Il s’agit réellement d’une plateforme pour les développeurs et je suis impatient de voir jusqu’à quel point elle sera amenée au-delà de la vision de Mozilla.

Un timing parfait

S’il y a quelque chose dont je suis conscient depuis mon arrivée chez Mozilla il y a un an et demi, c’est à quel point je suis chanceux d’être ici pour le démarrage du projet Firefox OS. Si je me souviens bien, le projet a été annoncé (sous le nom Boot to Gecko) pendant mes premières semaines de travail.

C’était déjà passionnant à l’époque, mais ça l’est encore plus aujourd’hui. Firefox OS est littéralement la chose numéro 1 sur laquelle je travaille actuellement et honnêtement j’adore ça. En réalité, je me sens privilégié d’y participer.

Je me suis demandé de nombreuses fois ce que l’on pouvait ressentir en travaillant chez Mozilla durant le lancement initial de Firefox : l’excitation, la passion, la nervosité, l’incapacité d’expliquer à quel point c’est impressionnant et à quel point on devrait s’en préoccuper.

Pour être honnête, je ne pense pas que beaucoup de monde comprenne réellement ce qui se passe avec Firefox OS, ni à quel point son lancement est important. Un peu comme pour Firefox, j’imagine. Pour le moment, je suis heureux d’être chez Mozilla à un instant clef de son histoire.

À couper le souffle

Les personnes qui le comprennent sont les développeurs qui ont essayé le terminal de démonstration qui est montré occasionnellement, lors d’événements avec des Mozilliens. Il n’y a rien que j’apprécie d’avantage que de voir les différentes phases de leurs émotions lorsqu’ils jouent avec les appareils :

1. D’abord, il y a une légère confusion, quelque chose comme « Pourquoi tu me passes un téléphone Android ? » ;
2. La confusion est suivie par la réalisation soudaine qu’il ne s’agit pas d’Android mais d’un système en JavaScript ;
3. Après un court moment, l’excitation leur fait lancer des « oh putain ! » ;
4. Un instant plus tard, les voilà absorbés à explorer tous les recoins de l’appareil en posant plein de questions ;
5. Le moment où je leur demande de me rendre l’appareil est accompagné d’une légère réticence et finalement d’un « C’était pas mal du tout, je suis impressionné ! ».

Vous devez penser que j’ai tendance à enjoliver les choses, mais je peux vous assurer que c’est réellement le genre de réaction qu’ont pu avoir les gens auxquels j’ai présenté l’appareil. C’est réellement jouissif.

Ce dont j’ai commencé à me rendre compte, c’est que plus je regarde d’autres personnes s’amuser avec un appareil sous Firefox OS, plus je suis convaincu de sa capacité à changer la donne. C’est comme s’ils s’éclataient avec, sans que j’aie besoin d’intervenir.

Des défis à relever

Il ne serait pas juste de parler de la grandeur de Firefox OS et des points sur lesquels je travaille sans détailler les principaux défis que nous devons relever.

Il y a bien sûr les problèmes classiques : comment gérer un écosystème d’applications qui est libre et sans restrictions ; ou anticiper les problèmes d’interopérabilité des appareils, comme ceux que peut connaître Android.. Ces problèmes sont importants, mais ne m’intéressent pas.

Ce qui m’intéresse le plus, c’est le défi de développer des jeux en HTML5 ; tant pour les performances apparentes que pour les véritables, sur lesquelles les développeurs se plaignent. C’est indéniablement l’un des défis spécifiques à Firefox OS (Android et iOS sont aussi mauvais l’un que l’autre), mais pour le moment, je suis entièrement consacré à Firefox OS et les façons d’améliorer ces points.

Aujourd’hui, la majorité des jeux HTML5 préexistants sur téléphone tournent soit de manière saccadée (0 à 20 images par seconde), ou tout juste fluide (20 à 30 images par secondes). La plupart du temps, ces jeux ne tournent pas à un rythme d’images stable, ce qui rend l’expérience peu plaisante.

Ce qui est intéressant, c’est qu’une grande partie de ces soucis ne semblent pas venir du terminal ou de JavaScript. Il y a quelques jeux intenses, comme Biolab Disaster, qui tournent de manière incroyable, même sur le terminal bas de gamme avec lequel j’effectue les tests (nous parlons ici d’un taux d’images par seconde entre 40 et 60FPS).

Pour moi, il est clair que si les mobiles et les plateformes sont parfois à blames (pas aussi souvent que certains le voudraient), il y a cependant beaucoup de choses que nous apprenons des jeux qui fonctionnent convenablement sur des terminaux bas de gamme, pour voir quelles techniques ils utilisent et comment éduquer au mieux les autres développeurs souhaitant utiliser HTML5 sur téléphone mobile.

Je crois vraiment que des jeux HTML5 gourmands peuvent très bien tourner sur des appareils mobiles, même sur ceux bon marché. Pourquoi suis-je si confiant à propos de ça ? Parce que les gens font déjà des jeux comme ça. Il y a deux choses dans ma vie que je crois sans douter… mes yeux.

Nous en sommes là.

Au-delà du téléphone mobile

Ce qui m’excite le plus à propos de Firefox OS n’a rien à voir avec l’appareil mobile que nous sortons l’année prochaine mais plutôt avec le futur qui nous tend les bras. J’ai abordé ce point auparavant lorsque j’ai parlé de Firefox OS comme un rêve de bidouilleurs, et comment les autres pourraient le récupérer et le développer au delà de la vision qu’en a Mozilla.

La bonne nouvelle est que c’est déjà prêt aujourd’hui. Nous avons déjà un port de Firefox OS sur le Raspberry Pi, ainsi que pour la Pandaboard. Ils ne sont pas parfaits, mais ce qui est génial c’est qu’ils existaient déjà bien avant que Firefox OS voie sa première version sortir.

Vous avez aussi la possibilité de lancer Firefox OS depuis un ordinateur sous Mac, Windows et Linux. Alors qu’il n’est pas possible d’acceder au même matériel qu’avec un appareil mobile, la version pour PC vous permet de bénéficier des autres fonctionnalités (telles que les applications qui tournent dans des processus séparés). En plus, c’est vraiment simple à mettre en place.

Je peux imaginer un futur proche où l’API Gamepad aura été implémentée dans Gecko et pourra être accessible à travers le client PC Firefox OS. Qu’y a t-il d’extraordinaire ? Il y a qu’il n’est pas difficile d’imaginer voir ce client PC être lancé depuis un appareil connecté à un téléviseur, avec un système d’exploitation personnalisé pour utiliser un gamepad plutôt qu’une souris ou un touchpad (ce n’est que du JavaScript).

Ce que vous aurez ici sera le début des consoles de jeux vidéo HTML5, et c’est en fait une chose que je suis impatient d’explorer durant mon temps libre en dehors de Mozilla.

Ce que je veux dire, c’est que nous arrivons à un moment de l’histoire où les ordinateurs peuvent à présent fonctionner avec les technologies que l’on utilise pour créer des sites Web. Que pourrions-nous faire dans un monde rempli de terminaux fonctionnant avec ces technologies, qui pourront tous communiquer en se connectant via les mêmes API ?

J’ai hâte de voir à quoi ce monde ressemblera !

Crédit photo : Rob Hawkes (Creative Commons By-Sa)