L’avènement des plateformes de contenu et la revanche de la syndication

Assez régulièrement, notamment dans mes prédictions, je vous répète que le web est un média en perpétuelle évolution, avec une tendance à l’accélération de cette évolution. Pour vous en convaincre, je vous invite à (re)lire mes articles sur la publicité en ligne, TV ou les applications mobiles (ce qui était valable il y a deux ans ne l’est plus). Dernière illustration en date de cette évolution à marche forcée : les contenus. En moins de 6 mois, les grands acteurs du numérique (Snapchat, Facebook, Apple, Twitter, Google…) ont fait complètement évoluer les rapports de force et posé les bases d’une nouvelle ère : celle des plateformes.

Des portails web aux plateformes mobiles

À une époque pas si lointaine (15 ans), le web était dominé par des grands portails (Yahoo, MSN, AOL, Spray…). Ces portails se faisaient la guerre pour être la page de démarrage des internautes qui y trouvaient tous les contenus et services dont ils avaient besoin (météo, actus, sports, emails…).

Ces portails proposaient des chaines au sein desquelles un certain nombre de gros éditeurs étaient agrégés. Le problème est que cette agrégation était loin d’être exhaustive. Les internautes avaient faim, ils se sont logiquement tournés vers Google pour avoir accès complet à la richesse qu’offrait le web. Le célèbre moteur de recherche est devenu logiquement la page de démarrage de centaines de millions d’internautes.

Ensuite sont apparus les médias sociaux : d’abord les blogs, puis Facebook et Twitter. Face à la surabondance de contenus, les internautes ont dû faire des choix et accorder leur confiance à une poignée d’éditeurs. Nous sommes alors passés de l’ère de la recherche à celui de l’abonnement : flux RSS pour les blogs, follow pour Twitter et fans pour Facebook. Ce principe a bien fonctionné un temps, mais nous avons vite atteint un seuil de saturation (remarquez comme l’histoire se répète).

Non seulement les internautes étaient noyés sous un raz-de-marée de contenus de plus ou moins bonne qualité (avec tout le respect que j’ai pour les chats), mais ils étaient en plus abreuvés de messages et autres notifications. Ils se sont alors repliés vers des supports plus confortables où ils pouvaient savourer des contenus de qualité sur le web ou sur leurs terminaux mobiles. Flipboard est pour moi l’exemple le plus représentatif de ces services.

Séduits par l’idée d’une “oasis éditoriale”, d’autres se sont engouffrés dans la brèche, à commencer par Snapchat qui a lancé sa rubrique Discover en début d’année.

Assez rapidement, il a été rejoint par Facebook avec ses Instant Articles, qui sont toujours en phase de déploiement.

Dernier entrant dans la course : Apple, qui compte bien s’imposer sur le créneau de l’actualité avec sa plateforme Apple News associée à iOS 9.

“Plateforme” ? Oui tout à fait, une plateforme au sein de laquelle les utilisateurs peuvent découvrir, consulter et s’abonner à des contenus dans un environnement contrôlé (du moins en termes de mise en page) où tout est fait pour privilégier le confort de lecture, surtout sur un smartphone.

Avantages et inconvénients des plateformes de contenu

Appelons un chat un chat : par “plateformes”, je fais référence en réalité à des plateformes fermées, des sous-ensembles du web qui ne sont pas accessibles librement et où tout le monde (utilisateurs et annonceurs) doit se plier aux règles de l’éditeur. Certains s’offusquent de la balkanisation du web, à juste titre (Le web est mort, vive le web) ; d’autres mettent en avant la puissance de frappe de ces plateformes et leur capacité à démultiplier la visibilité des contenus, à juste titre également. Le débat n’est pas simple, car il y a plusieurs éléments à prendre en compte, notamment de solides arguments en faveur des plateformes :

une excellente expérience de lecture (bien supérieure à ce que peuvent proposer des sites web saturés de bannières et contenus additionnels) ;
une distribution très puissante (les messages sponsorisés sur Facebook permettent de rapidement toucher une large audience) ;
une monétisation simplifiée (Snapchat et Facebook proposent un système de partage des revenus publicitaires).

Les plateformes de contenu, en revanche, présentent un certain nombre d’inconvénients :

Les contributeurs sont terriblement dépendants de l’éditeur de la plateforme et de ses CGU (certains tentent néanmoins de clarifier les choses et de proposer des contrats équitables à l’image de Dailymotion ou YouTube) ;
La concentration des contenus pousse les contributeurs à utiliser des titres et des photos toujours plus sensationnels pour sortir du lot (BuzzFeed est ainsi le spécialiste du racolage numérique) ;
Les contenus publiés ne sont pas exportables, ils sont liés à la plateforme (les vidéos publiées sur YouTube et republiées sur Facebook sont pénalisées vis-à-vis des vidéos natives).

Au final, après plus de 12 ans de blog, je serais incapable de vous dire quelle est la meilleure solution entre publier sois-même ou passer par une plateforme (surtout avec la nouvelle version de Medium). Il y a en revanche un signe qui ne trompe pas : l’engouement des internautes. Flipboard revendique ainsi 80 M d’utilisateurs, essayez d’extrapoler ça au milliard d’utilisateurs journaliers de Facebook pour bien appréhender le potentiel des Instant Articles.

C’est pour éviter de se faire distancer que Twitter a présenté cette semaine ses Moments : une forme d’éditorialisation de l’actualité (Twitter Debuts Moments). En l’état, cette nouvelle fonctionnalité ne permet “que” de lire des tweets et de consulter des photos / vidéos, mais je suis prêt à parier que l’on pourra bientôt lire directement l’article dans Twitter (sans passer par une “web view”).

Nous en étions arrivés là (découverte et lecture des articles dans un environnement fermé), quand Google est venu mettre son grain de sel et proposer une solution intermédiaire avec ses Accelerated Mobile Pages.

Google à la rescousse avec Accelerated Mobile Pages

Ebruitée le mois dernier, Google a officialisé hier sa “solution” au problème de la distribution de contenus sur terminaux mobiles. De quel problème parlons-nous au juste ? À la fois d’une expérience de lecture médiocre (les sites éditoriaux sont lents à charger, le responsive design n’y changeant rien), une mécanique de monétisation qui devient caduque avec l’arrivée des bloqueurs de bannières sur smartphone (ex : Adblock Plus sur Android, Crystal sur iOS), et un très gros risque de cloisonnement du web (d’emprisonnement des utilisateurs au sein d’applications mobiles). Pour remédier à ces problèmes, Google propose de reformater les pages d’article en utilisant une version épurée de HTML : Introducing the Accelerated Mobile Pages Project, for a faster, open mobile web.

L’argumentation des équipes de Google pour nous vendre les AMP (Accelerated Mobile Page) est indiscutable : si l’évolution du langage HTML permet de faire des choses formidables (applications en ligne, animations, transitions…), l’utilisation abusive du javascript a considérablement alourdit les pages web et ne se justifie pas pour des pages de texte. L’idée de proposer une version propriétaire de HTML est une pure hérésie, car personne n’envisage de réécrire son site web. En revanche, alléger la mise en page et le code source des articles est une idée séduisante, surtout pour les lecteurs.

Nous arrivons ici au coeur du problème : nous sommes tous d’accord pour dire que tout bon contenu mérite monétisation. Mais est-ce une raison pour placer 4 à 5 bannières et jusqu’à 15 codes de tracking différents sur une même page ? Sans nous en rendre compte, nous sommes petit à petit arrivé dans une situation intenable avec d’un côté les éditeurs qui veulent légitimement gagner un peu d’argent avec leurs contenus, et de l’autre des internautes qui se sentent agressés par les bannières et surveillés (notamment à cause des pratiques de retargeting). Longtemps ignorée, la montée en puissance des bloqueurs de bannières est la résultante logique de cette fuite en avant des éditeurs (cf. Les ad-blockers accélèrent la transformation de la publicité en ligne).

Le pari de Google est donc de proposer aux éditeurs de publier une version allégée de leurs articles en n’incluant que des publicités “utiles” et un seul code de tracking. En suivant ces recommandations, les éditeurs auront le droit d’utiliser les serveurs de cache de Google pour accélérer de façon spectaculaire le temps de chargement des pages. Les premiers tests sont très encourageants puisque les temps de chargement seraient divisés par 4 (Get AMP’d: Here’s what publishers need to know about Google’s new plan to speed up your website). Un gain de temps et de bande passante précieux pour les smartphones.

L’autre gros avantage des Accelerated Mobile Page est de proposer aux mobinautes de lire un article directement sur la page de résultat de recherche. Dans l’exemple suivant, une recherche sur “Mars” fait apparaitre 5 articles dans un carrousel ainsi qu’un lecteur intégré.

La promesse des AMP est donc triple : améliorer le confort de lecture, fluidifier la distribution et proposer une mécanique de monétisation raisonnée. Ce dernier point est encore sujet à discussion dans la mesure où pour le moment seuls 5 réseaux publicitaires sont partenaires (nous ne connaissons pas les conditions pour rejoindre le club des élus) et où les ad-blockers continuent de bloquer les bannières des AMP. J’imagine que d’ici au lancement officiel, programmé pour le début de l’année prochaine, les équipes de Google auront trouvé un moyen de contourner les ad-blockers (notamment grâce au système de caching).

Au final, ce que propose Google n’est ni plus ni moins que de revenir aux sources du HTML avec des articles uniquement composés de texte et d’images (il est explicitement dit : “pas besoin de javascript pour du contenu statique”). Certaines mauvaises langues pourraient penser que c’est un moyen pour Google de camoufler les piètres performances des smartphones Android pour exécuter du code javascript (The State of JavaScript on Android in 2015 is… poor). J’aurais plutôt tendance à penser que c’est un moyen de protéger les internautes de la dérive induite par les ad tech, à laquelle Google participe largement, c’est toute l’ambiguïté de la situation.

Comme toujours, les équipes de Google ont une approche prudente et commencent par soumettre l’idée à la communauté pour valider leur approche et bénéficier d’un feedback des développeurs. N’oublions pas qu’il est ici question d’abandonner les balises standards du HTML pour utiliser les balises propriétaires de Google (, …). Certes, ils proposent de le faire dans les règles en utilisant les web components (cf. Comment les composants web ambitionnent de révolutionner les applications en ligne), mais c’est quand même une contrainte qui n’est pas négligeable. La bonne nouvelle est que ces spécifications ne demandent pas nécessairement de gros changements de la part des éditeurs. Après tout, cela va surtout impacter les outils de gestion de contenu : ces derniers proposent déjà d’exporter le contenu vers des flux RSS et Atom, AMP ne serait qu’un format alternatif supplémentaire. Vous noterez au passage que WordPress, le CMS le plus populaire du web, est partenaire de cette initiative.

Encore une fois, j’insiste sur le fait qu’il serait complètement aberrant de publier un site en AMP. L’idée de Google est de proposer aux éditeurs de publier une version allégée de leurs articles pour en faciliter la distribution et la lecture sur les smartphones. Quelque part, nous sommes en train d’assister à la revanche de la syndication (cf. RSS n’est pas un produit grand public, c’est un outil pour les professionnels). Qui sait si un jour nous n’allons pas également assister au retour de Google Reader ?

…

En voilà une bonne idée : proposer une version mobile de Google Reader pour concurrencer Apple News. Ha mince, on me signale dans l’oreillette que ça existe déjà (Google Play Kiosque). C’est ballot, parce que là nous retournons dans une logique de morcèlement du web au sein d’applications mobiles. Un retour à la case départ en quelque sorte…

Bref, tout ça n’est pas simple, mais Google a au moins le mérite de proposer une solution pour sortir de cette terrifiante logique de silotage du web qu’Apple et Facebook semblent tant apprécier, et Snapchat, et WeChat, et LinkedIn, et Flipboard, et tous les éditeurs de contenus qui proposent leur propre application mobile. Bon tout le monde en fait ! Difficile de lutter dans ces conditions…

HTML 5 + CSS 3 = une révolution pour les interfaces web

Voilà 20 ans que le web existe et presque 10 ans que le HTML n’a pas évolué et propose toujours la même structure et les mêmes balises. 10 ans c’est beaucoup, c’est la moitié de la “vie” du web. 10 ans c’est beaucoup, surtout lorsque l’on constate les révolutions qui ont eu lieu dans les usages du web ces 5 dernières années (partage de vidéos, réseaux sociaux, infos en temps réel…). Pas étonnant que des technologies propriétaires (Flash) se soient imposées (notamment sur la vidéo et les RIA) et que d’autres s’installent tranquillement pour combler un manque (notamment Google Gears pour l’accès hors ligne).

Bref, il était temps que le marché se réveille et c’est (presque) chose faite avec l’arrivée à maturation de HTML 5 et CSS 3. Pour faire simple, disons que nous avons franchi le point de bascule et que la route qui mène à une adoption de ces nouveaux standards n’est plus si longue. Pourquoi est-ce important de se soucier de ça ? Tout simplement parce que ces nouvelles spécifications vont changer beaucoup de choses dans la façon de concevoir et d’exploiter les interfaces web, des changements qui vont fortement impacter les différents métiers de la profession.

Autant vous prévenir tout de suite : les explications qui vont suivre sont une tentative de l’auteur de résumer et vulgariser un foutoir pas possible (qui provoquent d’innombrables querelles d’experts depuis des années : HTML 5 is a mess. Now what?) sans pour autant prendre partie car de toute façon les choses semblent visiblement s’améliorer. Je ne donne que mon interprétation, vous êtes libre de proposer la votre.

Commençons donc par nous intéresser à cette nouvelle version de HTML et pourquoi s’est-elle imposée face à XHTML (pour une explication plus détaillée c’est ici : XHTML 2 vs. HTML 5, et là : Misunderstanding Markup: XHTML 2/HTML 5 Comic Strip).

HTML vs. XHTML

Au commencement il y avait donc le HTML 4 dont les spécifications ont été publiées en 1997. Une légère évolution a été publiée en 1999 avec le HTML 4.01. Puis le W3C a décidé de miser sur le langage XML (plus sophistiqué et surtout extensible) en proposant une reformulation du HTML avec les balises du XML, à savoir le XHTML 1.0. Tout l’intérêt de cette reformulation est de pouvoir marier la simplicité du HTML avec la puissance du XML (et ses nombreuses possibilités d’évolution).

Sur cette lancée, le W3C a alors lancé le chantier XHTML 2 pour faire une réécriture complète des spécifications et poser de nouvelles bases pour un langage plus puissant, plus robuste, plus évolutif… bref, un langage qui propulserait le web dans une autre dimension sans toutefois assurer de rétro-compatibilité. Hé oui… car il faut bien faire table rase pour pouvoir redémarrer sur des bases saines. Et c’est bien là le problème : ne pas assurer la rétro-compatibilité était inacceptable pour l’industrie (et notamment les éditeurs de navigateurs) qui ont alors décidé de lancer des travaux indépendant sous l’aile du WHATWG (Web Hypertext Application Technology Working Group). Ce groupe de travail a commencé à travailler sur les spécifications des Web Applications.

Après un bras de fer de plusieurs années (et un constat d’échec pour l’équipe de travail sur les spécifications XHTML 2), le W3C a fini par réintroduire les spécifications du WHATWG et de créer un groupe de travail officiel sur le HTML 5 tout en abandonnant l’autre chantier (RIP XHTML 2).

Par élimination il ne reste donc plus qu’un seul prétendant au titre de remplaçant du HTML 4, d’autant plus qu’il a reçu le soutien de qui vous savez (Google Bets Big on HTML 5). Nous sommes donc semble-t-il arriver à un consensus de l’industrie sur des spécifications qui ne sont pas aussi ambitieuses que celles d’XHTML 2 mais qui ont l’énorme mérite de faire avancer les choses (souvenez vous qu’il n’y a pas eu d’évolution en 12 ans).

Qu’est-ce qui va changer avec HTML 5 ?

Pour faire simple disons qu’avec HTML 5 nous allons quitter l’ère du web des documents pour enter dans celle du web des applications. L’ambition de cette nouvelle itération est donc de supprimer les balises obsolètes, d’en remplacer certaines et d’en introduire de nouvelles afin de donner une structure sémantique plus cohérente aux pages web.

De nouvelles API vont ainsi standardiser un certain nombre d’interactions :

L’accès hors ligne et le stockage sur le disque dur (pour une exploitation en mode déconnecté) ;
L’édition en ligne, le drag&drop ;
L’accès à l’historique de navigation…

Bref, tout ce qui nécessitait le recours à javascript ou à des technologies propriétaires sera désormais “livré d’origine”.

La grosse nouveauté est donc de proposer un nouveau schéma de structuration des données qui va venir remplacer les éléments en bloc et en ligne (cf. HTML5 se dévoile) :

Les spécifications manquent de précisions pour se faire une idée de ce nouveau schéma, d’autant plus que de nouvelles balises structurantes comme <template> et <datatemplate> ont été introduites.

Gros changement également avec un jeu de nouvelles balises permettant de mieux définir le contenu : <header>, <nav>, <article>, <aside> et <footer> :

C’est donc une petite révolution puisque ces nouvelles balises vont permettre une structuration beaucoup plus propre des pages, surtout pour les sites avec beaucoup de contenus (blogs, portails…). Plus d’infos ici : HTML5 and The Future of the Web.

Notons enfin l’apparition de balises très intéressantes comme <audio> et <video> pour les éléments multimédias, <canvas> pour les dessins vectoriels ou encore <datagrid> pour les tableaux de données. Ces nouvelles balises permettront de réduire la dépendance à des technologies propriétaires comme Flash. Juste un dernier mot sur les formulaires qui vont avoir de nouveau types de champs <input> comme date, time, number, range, email, url, search, color…

Je pense qu’il n’est pas faux de dire qu’avec HTML 5 la séparation entre contenu, structure et présentation sera encore plus facilement gérable.

Quelles nouvelles possibilités pour CSS 3 ?

Précisions que du côté des feuilles de styles, les travaux autour des nouvelles spécifications CSS 3 sont beaucoup moins perturbés. Cela permet donc d’avancer plus vite. Quoi que… j’ai dans mes archives des articles sur le sujet datant de 2004 et 2005 : Des formulaires standardisés, CSS 3 : des templates pour structurer vos pages web et Formulaires : quand les CSS 3 vous changent la vie.

L’essentiel des travaux autour des CSS 3 a été de standardiser des propriétés pour réaliser des traitements graphiques qui nécessitaient auparavant des astuces :

Border-radius pour les coins arrondis ;
Text-shadow pour les ombres portées ;
Transparency et Opacity pour la transparance ;
Animation et Transition pour les animations (cf. Nicer Navigation with CSS Transitions, à regarder avec les dernières versions de Safari ou Chrome)…

Bref, il y a beaucoup de nouveautés à découvrir ici : 7 New Essential CSS 3 Techniques Revealed. Tout l’intérêt étant de pouvoir se passer d’images ou d’astuces pour pouvoir réaliser ce que l’on souhaite. Illustration avec ces jolis boutons :

Encore plus intéressant, toutes les propriétés concernant la mise en page et le positionnement : Presentation Levels, Template Layout, Multi-column Layout, Grid Positioning et Flexible Box Layout.

Le changement va être aussi spectaculaire que radical : là où il fallait tout un tas de <div> imbriqués, d’images, de tableaux… pour arriver à la mise en page et au traitement graphique souhaité (donc en alourdissant le code source), nous aurons bientôt une syntaxe bien plus lisible grâce à ces nouvelles propriétés.

Quels bénéfices et pour quand ?

Je vous propose de récapituler ce que nous venons de voir : un contenu mieux structuré et défini, une syntaxe allégée, des traitements graphiques standardisés… tout ceci va permettre d’avoir un code source beaucoup plus propre. Ceci est particulièrement important dans la mesure où les pages ne sont plus faites à la main pour des utilisateurs humains, mais générées par des systèmes de gestion de contenu et exploitées à la fois par des humains et des agents intelligents (via les balises descriptives ou microformats).

C’est donc une authentique révolution à laquelle nous allons assister… dans quelques années ! Hé oui, car même si les spécifications sont là, leur implémentation est fonction du bon vouloir des éditeurs de navigateurs et du taux de renouvellement par les utilisateurs.

Aujourd’hui le marché est encore dominé par un IE qui risque d’aggraver encore son retard avec ces nouvelles spécifications. Vient ensuite Firefox qui évolue vite (grâce à une communauté très active) mais qui est tout de même fortement ralenti par l’inertie des utilisateurs (surtout lorsque les parts de marché dépassent les 30 %).

Il est certain que les choses sont beaucoup plus simples pour Safari, Opera ou encore Chrome qui peuvent avancer à leur rythme (lire à ce sujet : Opera 10, Chrome 4, Firefox 4 : Vers des plateformes sociales et applicatives).

Donc au final, l’impact ne se fera pas ressentir avant quelques années. Sauf si un éditeur trouve le moyen de faire avancer les choses au forcing (au hasard Google avec son futur Wave qui tournera bien mieux sur Chrome).

Par contre, une fois que le parc de navigateurs aura été renouvelé, j’anticipe un gros changement au niveau de l’industrie du web avec une montée en puissance de profils comme les architectes front office (l’équivalent des DBA ou des architectes systèmes) chargés de concevoir des interfaces web cohérentes et surtout performantes (notamment dans la gestion des styles).

De même, j’anticipe une véritable révolution pour les outils de prototypage rapide dont l’intérêt était limité du fait du format de sortie (du HTML de base que ne pouvaient pas exploiter les équipes de production) et qui vont fortement bénéficier de cette épuration du code source et de la séparation structure / contenu /présentation.

Bref, j’ai l’impression de me répéter, le web a de très beaux jours devant lui avec ces nouvelles spécifications qui vont tranquillement nous amener vers des contenus mieux structurés (sémantisés) et des applications en ligne plus performantes et simples à créer / maintenir.

L’accessibilité est un processus continu

C’est en substance ce que nous enseigne cette intervention de Matthieu Faure : Henry Ford, le web et l’accessibilité. Il y est question de la chaîne de production d’un site web (qui est schématiquement découpée en deux “lignes” : la création des gabarits de pages et la création des contenus), du rôle centrale de l’outil de gestion de contenu dans l’intégration de ces deux lignes et de l’intérêt de prendre en compte les critères d’accessibilités à toutes les étapes de cette chaîne de production.

Il est en effet beaucoup plus complexe de rendre accessible un site quasi-finalisé que de le “penser” accessible à l’origine. Il existe ainsi un très grand nombre de raisons de repousser à plus tard le “chantier accessibilité” : trop de contraintes, manque de temps, manque d’argent, manque de ressources, des priorités plus urgentes… Grave erreur, puisque le coût d’intégration des contraintes d’accessibilité en tout début de projet (et tout au long du processus) est quasi-négligeable. Par contre, la complexité (et donc le coût) grandit avec le temps : plus vous attendez et plus cela sera complexe de “corriger le tir”.

Mais j’espère ne rien vous apprendre… sinon je vous recommande vivement la lecture du billet précité (et même du blog en entier).

Vers un flash player en open source pour la fondation Mozilla ?

La nouvelle vient de tomber , et elle a de quoi surprendre : Adobe vient de livrer à la fondation Mozilla le code source de sa machine virtuelle ActionScript (voir le communiqué de presse ici : Adobe and Mozilla Foundation to Open Source Flash Player Scripting Engine).

Quand on y regarde de plus près, et surtout entre les lignes, on se demande si Adobe ne serait pas en train d’abandonner la maintenance de son Flash Player au profit d’une dynamique open source.

Plusieurs facteurs sont à l’origine de cette décision :

La stratégie d’Adobe n’est pas le même que celle de feu Macromedia, comprenez par là que la gamme de produits d’Adobe est bien plus large et que ses centres de revenus (les vaches à laits) ne sont pas forcément liés à Flash ;
Les équipes d’Adobe ont bien du mal à assurer la maintenance du Flash Player (rappelons qu’il n’existe toujours pas d’adaptation de la version 9 pour linux) ;
Le marché des interfaces riches est en pleine croissance et l’offre d’Adobe (Flash / Flex) doit faire face à la concurrence d’autres approches technologiques comme Ajax, OpenLaszlo, Java Web Start, .Net , XUL… ;
Adobe concentre sa R&D sur Apollo, son logiciel hybride capable de lire du Flash, du PDF et du HTML.

Toujours est-il qu’Adobe vient probablement de montrer le premier signe d’une stratégie de retrait. La suite logique serait de livrer le code source du Flash Player, tout comme l’a déjà fait Netscape à l’époque avec son navigateur.

Si l’on rapproche cette stratégie de celle faite par IBM (de baser son environnement de développement Java sur Eclipse), la question que je me pose est la suivante : Quelle va être la capacité de la communauté des développeurs à absorber cette charge de travail ? Car il faut bien appeler un chat un chat : Adobe n’est pas une organisation philanthropique et son seul souhait est de faire supporter une partie des frais de R&D et de maintenance à la communauté du libre.

Quand on y réfléchi, ça commence à faire beaucoup de boulot tout ça : Firefox, Thundberbird, PHP, MySQL, Java, Eclipse… J’en oublie certainement une grande partie, mais il ne faut pas oublier que les bénévoles ne sont pas non plus de pigeons. Pour vivre, une communauté à besoin d’une dynamique, de leaders, d’animateurs… et tout le monde n’a pas un Tristan Nitot dans sa manche !

Bref tout ça pour dire que je suis très content pour la fondation Mozilla. C’est un très bon choix de la part de ~~Macromedia~~Adobe que de “confier” son bébé à une organisation qui a fait ses preuves et qui dispose déjà de l’infrastructure nécessaire.

Dans cette histoire, le seul perdant pourrait être le format SVG soutenu par le W3C. Cependant, au vu des dernières évolutions du format Flash (qui en est à sa 9ème itération), on est en droit de se demander si l’animation vectorielle est encore au cœur de ce dernier… C’est sûr que comparé à Flash 9, SVG c’est comme un playmobil dans Prison Break (hé hé hé, elle n’était pas facile à placer celle là !).

Et vous, feriez-vous confiance à la fondation Mozilla pour reprendre le travail sur le Flash Player ?

MAJ (08/11/2006) : Les explications complètes sur le blog de Tristan Nitot : Adobe et Mozilla s’allient pour lancer le projet Tamarin. Heu… pourquoi avoir choisi ce nom de Tamarin ?

IE 7 est disponible… et Firefox 2 très bientôt

Aujourd’hui est un grand jour, non pas parce que IE 7 vient de sortir en version définitive, mais plutôt parce qu’après 3 Release Candidate, Firefox 2 est également sur le point de sortir.

Pourquoi est-ce si important ? Pour plusieurs raisons :

ces deux nouvelles moutures intègrent de façon native l’abonnement et la gestion des flux RSS, ce qui va faire sortir de l’ombre la syndication et la faire connaitre aux yeux du grand public) ;
les moteurs de rendu ont évolué, ce qui veut dire une meilleur prise en charge des CSS ;
deux modèles d’organisation (la multi-nationale privée et la fondation) nous ont démontré leur réactivité et leur puissance de feu (l’une fondée sur la capitalisation et des milliers de salariés, l’autre basée sur la passion et des millions de bénévoles).

Bref tout ça pour dire que je serai bien allé à la soirée de lancement de Firefox 2 la semaine prochaine, mais visiblement je ne suis pas le seul comme le précise ce billet de Tristan. Comme je suis convaincu du bienfondé des standards web et un inconditionnel de Firefox, je suis prêt à laisser ma place à cette soirée. Je préfère en effet utiliser Firefox au quotidien et faire bénéficier de cet évènement quelqu’un d’autre (même si cette soirée aurait été une bonne occasion de revoir des gens que j’apprécie).