La nouvelle est passée complètement inaperçue, mais figurez-vous que la semaine dernière, Yahoo a racheté l’environnement virtuel Cloud Party : Cloud Party Joins Yahoo. Pour votre information, Cloud Party est une plateforme permettant de créer de petits environnements virtuels directement dans la fenêtre de votre navigateur, donc sans passer par un logiciel ou plugin spécifique.

Autant dire que cette acquisition a de quoi surprendre, d’une part car la technologie WebGL manque encore un peu de maturité ; d’autre part, car ce n’est pas du tout sur ce créneau que Yahoo est attendu (euphémisme). Je pense ne pas me tromper en disant que le segment des univers virtuels s’est fortement contracté ces dernières années, et que Second Life reste la plateforme de référence. Même si Cloud Party s’était plutôt bien diversifié et proposait une richesse fonctionnelle tout à fait honorable (New Stores Opening in Cloud Party), vous êtes en droit de vous demander pourquoi ils rachètent cette startup, surtout si c’est pur la fermer : Yahoo Acquires Virtual World Gaming Startup Cloud Party, Will Shut It Down.

Le moins que l’on puisse dire, est que Yahoo a toujours été très timide dans son appropriation des univers virtuels (Yahoo se lance timidement sur le créneau des univers virtuels), contrairement à Google, par exemple, qui avait tenté l’aventure avec Lively. Ceci étant dit, Yahoo a récemment fait l’acquisition d’une autre startup l’année dernière, PlayerScale, qui permet de faciliter le déploiement de jeux multi-plateformes (Facebook et Yahoo renforcent leurs équipes pour les jeux mobiles).

L’hypothèse la plus probable est que Yahoo souhaite se renforcer sur le créneau des jeux sociaux multi-plateformes, notamment en capitalisant sur Yahoo Games. C’est de loin le scénario le plus logique, dans la mesure où le segment des univers virtuels n’offre finalement que peu d’opportunités de croissance (What Are Virtual Worlds & What Are Their Uses?), et que Google a jeté l’éponge (The End of Google+ Games). De ce point de vue là, la stratégie de Yahoo serait d’essayer de prendre de vitesse la nouvelle génération d’applications mobiles asiatiques qui tentent de s’imposer sur ce créneau (L’avenir des jeux sociaux passera par les plateformes sociales mobiles).

Une stratégie qui semble logique, mais particulièrement inspirée. L’avenir des jeux vidéo est en effet fortement lié aux terminaux mobiles, mais également aux environnements virtuels, notamment ceux avec un environnement de type sandbox comme Minecraft (Minecraft = Second Life + Lego universe – 24 bits), Roblox (Roblox is trying to foster the next generation of indie devs), ou encore Patterns (Linden Lab se réinvente et profite du succès de Minecraft).

Sans parler du fait que d’autres sont déjà passés à la vitesse supérieure avec de grandes ambitions autour de la réalité virtuelle : Google Glass Mini Games et EverQuest Next could be the first MMORPG to support the Oculus Rift.

Donc au final, Yahoo confirme sa posture de suiveur réactif. On peut difficilement leur en vouloir tant le marché est chaud en ce moment : les valorisations des startups les plus en vue atteignent des sommets que le conseil d’administration de Yahoo ne peut approuver. Ils sont logiquement obligés de se rabattre sur des « proies » plus faciles à avaler. Circulez, y’à rien à voir…

Les constructeurs automobiles ont toujours été très friands d’interfaces riches, vous trouverez de nombreux exemples en parcourant les archives de ce blog. Aujourd’hui, les mini-sites en flash ne sont plus trop à la mode, si ce n’est pour des réalisations très spectaculaires comme celles de Volvo Trucks ou le récent Race the Sun de Land Rover qui propose une série de mini-jeux synchronisés avec votre smartphone. Il ne reste que quelques irréductibles à proposer un site 100% Flash comme celui de la marque aux chevrons (un bel anachronisme).

Donc dans l’ensemble, les constructeurs automobiles font un usage beaucoup plus modéré de Flash, mais ce n’est pas pour autant qu’ils adressent de façon efficace les terminaux mobiles. Lexus propose ainsi un très beau magazine en ligne en Flash (Beyond Magazine) qui n’est absolument pas compatible avec les smartphones et tablettes.

Et quand bien même il n’était pas réalisé en Flash, il faudrait quand même un peu de travail d’optimisation pour qu’il puisse être consulté dans de bonnes conditions sur un terminal mobile (à l’image du BMW Magazine qui est malheureusement bloqué en Europe). Il en va de même pour les sites web, qui même s’ils sont réalisés en HTML restent difficilement consultables sur smartphone ou tablette. Pour pallier à ce déficit de compatibilité, les constructeurs ont adopté différentes approches.

La première tactique consiste à déployer des applications mobiles. C’est ce que font des constructeurs comme Ford, qui en propose un certain nombre sur Ford Mobile Showcase, ou Audi qui équipe ses concessions (Audi sees iPad app as major sales tool) et qui s’associe avec des éditeurs de services mobiles (Audi / INRIX Sources ParkMe for Live Parking Information).

La deuxième approche consiste à proposer une version mobile de son site, comme le font Renault ou Peugeot.

Vous conviendrez que dans le premier cas, c’est très austère (ça ne donne pas vraiment envie), alors que dans le deuxième cas, il y a trop de raffinements (on ne s’y retrouve pas vraiment). Il existe pourtant de très bons exemples comme Dodge qui propose un site mobile à la fois simple à manipuler et très réussi visuellement.

D’autres constructeurs proposent enfin des sites web hybrides qui fonctionnent aussi bien sur un ordinateur que sur un smartphone ou une tablette. C’est notamment le cas d’Audi USA :

C’est également le cas de VW en Norvège qui propose un site à part : Volskwagen Showroom.

Ces deux sites ont été conçus selon le principe du responsive design, une technique permet d’avoir une mise en page qui s’adapte à la largeur de l’écran, comme c’est le cas pour le site de Peugeot.

Est-ce réellement utile de propose à la fois un site web compatible, un site mobile ET des applications mobiles ? Oui j’en suis persuadé, car les terminaux alternatifs comme les tablettes sont de plus en plus utilisés à domicile : Retailers must have tablet-first Web experiences in post-PC world. À partir de ce constat, pourquoi se contenter d’une solution en demi-teinte comme le responsive design qui reste un compromis ?

Si les distributeurs indépendants peuvent se contenter d’une solution unique (cf. Responsive Dealer Website), une marque avec un minium d’ambition se doit de proposer un large éventail de solutions :

• Un site web avec une mise en page flexible pour les ordinateurs et tablettes ;
• Un site web mobile pour les smartphones ;
• Des applications mobiles pour des usages très spécifiques (ex : configurateur événementiel pour le lancement d’un nouveau modèle) ;
• Des mini-sites très spectaculaires (donc destinés aux ordinateurs) pour une opération limitée dans le temps ;
• Des mini-sites « plaquettes » avec une mise en page et une manipulation adaptée aux tablettes…

Vous l’aurez donc compris, il n’existe pas de solution miracle et il faut un minimum d’investissement pour pouvoir apporter de la satisfaction à des prospects et clients dont les usages se dispersent sur différents types de terminaux. Google a publié à ce sujet un certain nombre d’articles et études sur le Customer Journey to Online Purchase et le Zero Moment of Truth, et plus spécifiquement sur le Mobile Path to Purchase.

Vous pourriez me dire que tout ceci augmente considérablement le budget de développement et que le ROI est plus qu’incertain, et je vous répondrais que vous n’avez pourtant pas vraiment le choix, car cela correspond à un véritable changement de comportement et d’habitudes chez les prospects et clients. Ceci étant dit, nous commençons à avoir un minimum de recul sur la question et les premiers résultats de dispositifs mobiles sont plutôt encourageants : Responsive Design for the Automotive Industry.

La moralité de cet article est qu’il faut investir beaucoup de ressources et d’énergie pour avoir un dispositif en ligne performant, aussi bien en matière de séduction, de transformation, de référencement… Dans tous les cas de figure, simplifier son site web pour le rendre compatible avec les terminaux mobiles est forcément bénéfique pour l’expérience utilisateur. L’exemple d’Audi USA me semble particulièrement parlant, car le site est au final beaucoup plus percutant. Vous ne trouvez pas ?

À une époque pas si lointaine, un consensus s’était créé autour de l’affirmation que les marques, organisations et individus n’avaient plus besoin d’un site web puisqu’une page Facebook fonctionnait  mieux et permettait de toucher plus de monde. Avec le recul, j’espère que toutes celles et ceux qui affirmaient ça (j’ai une liste) ont changé d’avis, car en ce début d’année 2014 la baisse de la portée naturelle des publications (organic reach en anglais) est plutôt sévère : Studies show more than 40 percent decreased organic reach on Facebook et Facebook Admits Organic Reach Is Falling Short, Urges Marketers to Buy Ads.

Il existe de nombreux articles expliquant que cette baisse du taux moyen de reach est due à un changement d’algorithme, mais ne vous y trompez pas, elle est en fait directement lié au modèle économique de Facebook : en abaissant le taux d’affichage naturel des messages, Facebook augmente artificiellement la valeur de ses offres payantes de visibilité. Formulé autrement : plus le organic reach baisse et plus les revenus publicitaires augmentent. J’ai déjà publié de nombreux articles sur la façon dont Facebook a su imposer son modèle aux marques, mais je ne suis jamais réellement parvenu à m’exprimer de façon aussi limpide que Derek Muller, un podcaster qui a récemment publié une tribune d’exaspération : The Problem with Facebook.

Dans cette vidéo, l’auteur y explique que Facebook traite les producteurs de contenu comme des annonceurs. Comprenez par là que si vous avez du contenu, il faut payer pour le diffuser sur Facebook. Cette situation n’est pas nouvelle, car d’autres s’en étaient déjà plaints en 2012 : Facebook, I want my friends back. Si vous prenez un peu de recul, vous allez effectivement vous rendre compte que nous sommes dans une situation insensée : les éditeurs de sites web se sont donné beaucoup de mal pour faire grossir le trafic sur leur page, notamment en transférant leur audience naturelle, et ils sont maintenant contraints de devoir payer pour pouvoir diffuser du contenu à leurs propres fans. C’est comme si un centre commercial proposait un emplacement gratuit aux commerçants en leur demandant de rameuter leurs clients, puis leur facturait le nombre de visiteurs qui passent devant leur vitrine !

Certes, on ne peut pas reprocher à Facebook de monétiser son audience, car ça reste une société privée, mais les producteurs de contenu ont légitimement le droit de se sentir trahis. Autant il est normal de facturer la diffusion de publicités natives à des marques ou distributeurs, autant je trouve honteux de devoir payer pour diffuser du contenu, du vrai contenu, celui sans lequel Facebook n’existerait pas. Trouveriez-vous normal que Yahoo facture son trafic à ceux qui  fournissent les contenus des chaînes ? Et pourtant, c’est ce que Facebook fait depuis des années, la pigeonnade du siècle…

Autant sur YouTube ou Twitter les contenus sont diffusés librement, avec le risque qu’ils passent inaperçus dans un flot continu de nouveautés, autant sur Facebook seules les marques et les artistes les plus puissants peuvent sortir du lot (cf. Avec les nouvelles pages et formats publicitaires, Facebook privilégie les marques fortes). Et encore, je ne vous parle même pas des messages de vos amis…

Pour bien faire, il faudrait dissocier les publications des pages et des profils : d’un côté les marques et artistes, de l’autre, vos amis. Ça ne vous rappelle rien ? Peut-être la nouvelle mise en page présentée en début d’année dernière (Une nouvelle version de Facebook pour laisser plus de place aux contenus et aux publicités) ? Le moins que l’on puisse dire est que ce nouveau news feed se fait attendre : uniquement disponible aux États-Unis et pour certains utilisateurs anglophones, cette nouvelle mise en page est censée désencombrer le flux de messages et donner plus de place aux messages de vos amis. Il faut croire que la pression des actionnaires est plus forte que la volonté d’améliorer l’expérience des utilisateurs…

Dernièrement les équipes de Facebook ont communiqué sur une évolution de leur algorithme pour rééquilibrer les chances de publication des messages de vos amis : News Feed FYI, What Happens When You See More Updates from Friends. Ils temporisent en soufflant le chaud et le froid, mais force est de constater qu’ils ne parviennent pas à concilier la satisfaction des utilisateurs finaux et leurs impératifs de rentabilité (les promesses faites aux marchés financiers).

Aux dernières nouvelles, ils avaient un plan pour faire de Facebook votre journal personnalisé, votre seule et unique source d’information : With ‘trending’ feature, Facebook wants to be your personal news hub et Facebook Could Launch Its Flipboard-Like News Reader This Month. Je me demande quel va être le critère principal pour choisir la « bonne information ». Bon en fait j’ai une petite idée, mais je préfère ne pas l’exprimer, car vous allez dire que je radote…

Tout le monde est d’accord pour dire que les pratiques et outils sociaux sont un levier majeur de compétitivité pour les entreprises, notamment auprès des travailleurs du savoir. Le problème est que dans les faits, ces fameux social software ne sont pas très utilisés : Les employés français boudent la collaboration sociale. Une étude récente de Deloitte nous apprend ainsi que les collaborateurs français apprécient le portage de leurs emails ou fichiers dans les nuages, mais que les pratiques « sociales » sont en dessous de celles de nos voisins européens.

Nous pourrions penser que le problème est lié à la mentalité latine, et pourtant également chez IBM qu’imposer des modules sociaux auprès des collaborateurs ne suffit pas à les faire collaborer : Yes, the Social Intranet is a new reality. But… Ce n’est pas le première fois que j’aborde sur ce blog la laborieuse appropriation de ces nouveaux outils et pratiques. Pour résumer une longue explication : l’adoption est beaucoup plus lente que ce qui avait été prévu. Peut-être est maintenant temps de se dire que le problème ne vient pas des outils, mais de la façon dont ils ont été « vendus » aux collaborateurs.

De nombreux éditeurs, plus ou moins bien intentionnés, se sont ainsi lancés tête baissée dans une vaste campagne de médiatisation des RSE, les fameux Réseaux Sociaux d’Entreprise qui étaient censés décupler notre productivité. Maintenant que nous disposons du recul nécessaire, il apparait que cette promesse est bien creuse. Encore une fois, les RSE en eux-mêmes ne sont pas à remettre en cause, c’est plutôt le contexte dans lequel ils ont été déployés qui est problématique. Face au succès planétaire de Facebook, les entreprises se sont dit qu’en donnant accès aux collaborateurs à un « Facebook interne », tout irait pour le mieux. Sauf que Facebook n’est pas la plateforme sociale ultime, c’est initialement un réseau social qui repose sur le principe du social graph : un réseau constitué d’utilisateurs. Facebook vous met donc en relation avec d’autres personnes, des personnes qui vous ressemblent. À  ne pas confondre avec la notion d’Interst Graph, qui met en relation des individus et des informations par l’intermédiaire de centres d’intérêt. Twitter ou Pinterest reposent sur cette notion et se révèlent beaucoup plus efficaces pour vous faire découvrir de nouveaux contenus (cf. Des social graph aux interest graph).

 

Dans le monde de l’entreprise, c’est la même chose, chaque type d’outils correspond à un objectif précis :

• Les réseaux sociaux d’entreprise (RSE) servent à trouver la bonne personne ou compétence ;
• Les communautés internes servent à trouver la bonne information, connaissance ou donnée (De l’intérêt des wikis pour gérer les connaissances) ;
• Les plateformes collaboratives servent à travailler plus efficacement (Des RSE aux RCE).

Les limites des RSE sont particulièrement bien expliquées dans cet article publié chez Wired : The Way We Work Is Soul-Sucking, But Social Networks Are Not the Fix. L’auteur y explique qu’une bonne partie de nos journées n’est pas consacrée au travail en lui-même, mais à des tâches connexes : participer à des réunions, lire / envoyer des emails, prendre connaissance et demander aux autres de prendre connaissance de documents… Dans ce contexte, les RSE ne sont d’aucune utilité, car ils ne permettent pas de réduire le nombre de réunions et d’emails ou d’accélérer le partage des informations et connaissances. La raison principale est que le social graph n’est constitué que d’individus et d’interactions autour de ces individus (messages, événements…). L’auteur décrit ce que pourrait être le work graph : un réseau d’entités en rapport avec le quotidien professionnel (idées, tâches, objectifs, processus, clients…), d’informations à propos de ces unités de travail (documents, conversations, statuts, données…) ainsi que les interactions qui vont avec (alertes, commentaires, notifications…). L’objectif du work graph ne serait pas de vous mettre en relation avec la bonne personne, mais avec les bonnes entités pour vous faire travailler plus efficacement (Next generation work tech has to build on the work graph, not just social networks).

Autant vous dire que je suis parfaitement en phase avec cette définition. Par contre, cela ne nous dit pas comment ce work graph doit être concrètement implémenté. D’ailleurs, les éditeurs les plus à la pointe ont chacun leur interprétation :

• Traction Software avec son modèle contextuel (The Work Graph Model: TeamPage style) ;
• Podio avec son principe de workflows personnalisables par les utilisateurs (Podio introduces Workflows).

J’imagine que tout ceci vous parait très conceptuel, mais ce distinguo entre social graph et work graph est essentiel pour lever les ambiguïtés persistantes entre les différents types d’outils. RSE, communautés internes et plateformes collaboratives sont donc parfaitement complémentaires. J’espère que vous aurez également compris que reproduire ou se servir d’analogies avec les plateformes sociales grand public est très risqué et peut mener à une mécompréhension, voire à un rejet, chez les utilisateurs finaux. Moralité : le travail d’évangélisation est loin d’être terminé.

En 15 ans, le web a complètement modifié notre façon d’accéder et de consommer l’information. Le web est maintenant une composante essentielle de notre quotidien : biens dématérialisés, services en ligne, formation et éducation, jeux en ligne, objets connectés… Je pense ne pas me tromper en disant que le web a façonné la société dans laquelle nous vivons : transparence absolue, peur du micro-ennuie, hyper-individualisme avec la mode des selfies… 15 années très riches, et un nombre incalculable d’innovations technologiques. Je vous propose à travers cet article de faire le point sur l’évolution des technologies liées aux interfaces web.

Dans sa définition la plus stricte, une interface est la couche entre deux éléments par laquelle ont lieu des échanges et des interactions. Dans le cas de l’internet, les interfaces web sont donc la couche permettant aux utilisateurs de consommer et d’interagir avec les nombreux contenus et services en ligne. Nous allons donc passer en revue les différentes technologies d’interface web, étudier leur évolution et constater la façon dont les grands éditeurs essayent encore et toujours de ramener la couverture à eux.

Des sites web aux rich desktop applications

Aux origines du web, les contenus et services n’étaient disponibles qu’à travers les pages HTML : du texte, des tableaux, des images et des formulaires. Mais au fil du temps, les choses se sont compliquées : Panorama des IHM connectés.

Si le navigateur était l’interface de référence entre les contenus et les internautes, différentes technologies ont été successivement exploitées pour enrichir l’expérience :

• Les applets Java pour faire les premières applications en ligne ;
• Les plugins comme Flash et Silverlight pour faire des Rich Internet Applications ;
• Les moteurs de widget pour pouvoir diffuser du contenu directement sur le bureau ;
• Les machines virtuelles comme AIR pour faire tourner des Rich Desktop Applications.

Tout ceci peut vous sembler complètement superflu, mais souvenez-vous qu’à cette époque le W3C souffrait d’une crise interne et que les spécifications de HTML faisaient du sur-place. D’où l’émergence de nombreuses technologies d’interfaces riches pour pouvoir étendre les possibilités du HTML et proposer des modalités d’affichage et d’interaction plus sophistiquées (3D, drag&drop…).

Très clairement cette première décennie de l’histoire des interfaces web a été dominée par Adobe et ses deux technologies phares (Flash et AIR). Puis Apple a lancé son iPhone, et le marché s’est complètement retourné.

Des applications mobiles aux applications packagées

C’est en début d’année 2007 que Steve Jobs a présenté pour la première fois son iPhone. Nous étions très loin de nous douter à l’époque de la révolution que cela allait engendrer, d’autant plus que dans sa première version, il n’y avait pas d’App Store, d’ailleurs ils n’envisageaient pas à l’époque d’ouvrir leur smartphone à des éditeurs externes d’applications. Et pourtant… avec la version 2 et surtout la version 3 du système d’exploitation de l’iPhone, les applications mobiles vont connaitre un succès phénoménal : même si les contenus et les services étaient les mêmes, le fait de les consommer à travers une interface tactile en situation de mobilité a poussé les mobinautes à s’enfermer dans la logique des applications.

Loin de moi l’idée de refaire l’histoire, mais les applications mobiles sont à la fois la meilleure et la pire chose qui a pu arriver au web : la meilleure, car cela a permis de démocratiser les interfaces tactiles et de donner un second souffle créatif aux designers ; la pire, car cet écosystème fermé d’applications va à l’encontre du principe d’ouverture et d’universalité du web. C’est d’ailleurs pour protéger son monopole qu’Apple est entré en guerre avec Adobe pour empêcher aux applications Flash de détourner les revenus provenant de son app store. Mais dans une certaine mesure, la volonté d’Apple de diaboliser Flash pour protéger ses revenus a fortement contribué au succès d’HTML5. La montée en puissance de navigateurs alternatifs comme Chrome et Firefox, combinée à un fort enthousiasme autour du renouveau d’HTML a permis de viabiliser l’exploitation à très grande échelle d’applications web comme Gmail, Twitter ou encore SalesForce. Si aujourd’hui, il ne vous venait plus à l’idée d’installer un logiciel pour consulter vos emails ou pour interagir avec vos amis ou collègues, sachez qu’à une époque pas si lointaine le débat faisait rage.

Avec la montée en puissance d’Android, de Windows Phone, et plus généralement la fragmentation des terminaux mobiles, certains éditeurs de contenus et service se sont rapidement rendu compte qu’éditer des applications natives n’était pas forcément une stratégie rentable. Ils se sont tournés vers des frameworks de développement multi-plateforme comme Phonegap, Titanium ou Sencha pour faire des applications hybrides : des contenus et services HTML encapsulés dans une application native. Aujourd’hui le débat entre applications mobiles natives, hybrides ou HTML est toujours actif (Le choix se complique entre application mobile et application HTML5), d’autant plus que l’on a maintenant un minimum de recul sur les mises en page adaptatives (Le Responsive Web Design n’est pas une solution, c’est un compromis).

Personne ne peut nier le rôle primordial de l’iPhone et l’iPad dans l’évolution radicale des usages autour des interfaces. Mais pendant ce temps là, d’autres préparaient leur contre-attaque, à commencer par Adobe qui s’est repositionner en un temps record sur les technologies standards (cf. Adobe & HTML) et qui a même lancé une suite complète d’outils de développement HTML5.

De même, Google a patiemment conçu et perfectionné les différentes pièces d’un plan dont on commence seulement à deviner les contours : ils ont commencé par populariser le navigateur Chrome en utilisant des briques logicielles communes à d’autres produits, dont le moteur de rendu Webkit. Puis ils ont adopté leur propre moteur de rendu HTML (Blink) et ont implémenté la technologie NaCl pour pouvoir exécuter des applications C++ (L’adoption de NativeClient passera par les jeux… et la bureautique). Plus récemment, ils ont commencé à faire la promotion des Chrome Apps, des applications HTML pouvant tourner en mode déconnecté avec Chrome ou ChromeOS (Google transforme son navigateur en environnement d’exécution avec les Chrome Apps). Les choses se sont accélérées tout dernièrement avec l’annonce d’un environnement de développement dédié et le portage des Chrome Apps sur iOS (Google veut accélérer le développement des Chrome Apps). En quelques années, Google s’est imposé comme l’acteur principal du renouveau des interfaces web, aussi bien sur les ordinateurs (avec les applications packagées) que sur les terminaux mobiles (Google prépare la révolution des interfaces Android).

Nous sommes quasiment à la fin de cette seconde décennie et nous y voyons maintenant beaucoup plus clair dans les plans de Google : s’appuyer sur les technologies standards (HTML, javascript…) pour généraliser ses environnements d’exécution (Chrome, ChromeOs et Android). Tout ceci n’est pas sans rappeler les manoeuvres de Microsoft ou Adobe, mais force est de constater que nous allons tout de même vers plus de simplicité et de performance pour les utilisateurs finaux (le fait de pouvoir éditer des documents Office directement dans Chrome avec QuickOffice est quand même un grand plus).

Voilà où nous en sommes en ce début d’année 2014. Vous constaterez que malgré une domination écrasante de son système d’exploitation, Microsoft n’est jamais réellement parvenu à prendre le leadership sur les interfaces web et à imposer ses technologies (le flop de Silverlight est un bel exemple). Il est pour le moment très difficile de prédire l’avenir, mais je suis persuadé que les choses ne vont pas beaucoup bouger : la communauté des développeurs va se détourner des plugins et s’orienter à nouveau vers HTML, que ce soit pour scénariser du contenu, perfectionner des applications en ligne ou se réapproprier les terminaux mobiles. Ceci fera l’objet d’un prochain article…