Les deux principaux fournisseurs de services dans ce domaine sont ThingLink et Stipple. Kiosked et Luminate proposent également des solutions similaires, mais ils ont un positionnement différent. Le principe est de vous fourni un service qui superpose une couche d’interactivité à vos images pour pouvoir y incruster des liens, des photos, des vidéos… En fiat il n’y a pas de limites aux éléments qui vous pouvez lier, certains s’intègrent mieux que d’autres.

Si mes sources sont exactes, ThingLink est le premier à avoir proposé ce genre de service pour les particuliers et les professionnels. Le service se présente sous la forme d’un éditeur qui vous permet d’insérer des rich media tags à vos photos et de les partager en y insérant un petit bout de javascript : ThingLink Rich Media Tags, An overview. Dans la pratique, ça ressemble à ça :

En passant votre souris au-dessus de l’image, vous allez voir apparaître des petits pictos menant à des contenus supplémentaires : photos, vidéos, musiques, profils de réseaux sociaux, mais aussi pages produit sur Amazon, Best Buy ou Etsy. Des liens particulièrement intéressant dans le cadre d’une activité marchande, regardez par exemple cette expérience menée par Ikea :

L’interface du service permet également d’avoir de comptabiliser le nombre de clics sur les images ou certains pictos.

Le plus intéressant dans ce service, est qu’il fonctionne aussi sur Facebook, Twitter et Tumblr. Dans le même genre, Stipple propose également de rajouter une couche d’interactivité aux images. Le fonctionnement est à peu près le même, avec un petit bout de code javascript à rajouter. Exemple avec Lexus (qui fonctionne aussi sur Twitter) :

Mais ils vont aussi plus loin avec leur offre Stipple Shopping qui ambitionne de transformer une image en mini-boutique intégrée :

L’ambition de ce service est donc nettement plus forte. Je ne saurais vous dire si les boutiques encapsulées dans une image sont viables, mais toujours est-il que celà ouvre d’innombrables possibilités pour étendre les possibilités d’interaction au sein même des flux de messages des plateformes sociales. Malheureusement ces deux solutions passent par Flash pour ajouter une couche d’interactivité au sein de la timeline de Facebook : Stipple allows Facebook pages to share interactive images and drive e-commerce et ThingLink Adds Interactive Image Sharing to Facebook Timeline.

(via Blog Ergo Sum)

Cette extension permet d’ouvrir tous les documents Office récents (.doc, .docx, .xls, .xlsx, .ppt, .pptx) et fonctionne plutôt bien. Certes, il n’est pas (encore) possible d’éditer les fichiers, mais vous économiserez potentiellement de nombreuses minutes avec cette extension dans vos phases de recherche de documents, d’autant plus qu’elle est visiblement parfaitement sécurisée pour éviter la propagation de virus.

C’est donc une nouvelle étape franchie dans la reconquête de l’informatique bureautique de Google auprès de Microsoft, le rival historique. Mais Google n’est pas seul dans cette quête, car il existe d’autres éditeurs indépendants qui font de même : LucidChart debuts Chrome extension, Firefox add-on for viewing and editing Microsoft Visio files. L’extension LucidChart permet également d’ouvrir et même d’éditer des fichiers Visio directement dans Google Drive (ou Google Apps).

Là encore, c’est un énorme gain de temps et surtout d’argent pour les nombreux destinataires et contributeurs occasionnels qui n’auraient plus besoin d’acquérir une licence. Autant vous dire que ça doit grincer des dents à Redmond.

Peut-on envisager de se passer définitivement du Pack Office ? Pas réellement, car il existe une masse considérable de fichiers Office dans les entreprises. Il faudra certainement 10 à 20 ans pour basculer sur un format plus ouvert et surtout pour déplacer les connaissances vers le cloud. Même si Microsoft est en train de finaliser son offre Office 365, ce type d’extension risque de leur faire une sacrée concurrence.

La prochaine étape logique devrait être de proposer un éditeur en ligne. J’anticipe une annonce ou au moins une démo lors du Google I/O du mois prochain.

L’année dernière, l’éditeur Epic avait annoncé en grande pompe le portage de son moteur 3D dans Flash. Capitalisant sur ce travail, ils se sont associés avec les équipes de Mozilla pour réaliser un portage similaire en HTML5 et javascript (asm.js pour être plus précis). Le résultat sera disponible d’ici quelques semaines.

Ce ne sont pas tant les performances ou le rendu qui sont impressionnants, mais plutôt le fait qu’ils ont réalisé ça en seulement 4 jours. Quatre jours pour adapter du code C et C++ en javascript (plus d’1 million de lignes de code). Autre annonce marquante de ces dernières semaines, l’annonce de l’utilisation d’HTM5 et WebGL pour réaliser la prochaine version de RuneScape, un MMO en ligne : Jagex turns to HTML5 for RuneScape 3.

Les précédentes versions avaient été réalisées avec Java, mais il semblerait que l’éditeur privilégie une solution plus universelle, comme expliqué ici :

HTML5 serait-il donc LA solution universelle pour les rich internet games ? Comme toujours, je me dois de vous apporter une réponse mesurée. Bon en fait ce n’est pas moi, mais les équipes de Waste Creative qui apporte une réponse parfaitement argumentée dans ce très beau site : Flash v. HTML. Leur argumentation repose sur le jeu Waste Invaders qui a dans un premier temps été réalisé en Flash, puis proposé sur iPhone avec Adobe Air, puis porté en HTML5.

Le rendu du jeu est le même, mais ils reconnaissent que Flash est pour le moment largement mieux déployé que les navigateurs modernes sachant exploiter HTML5… sauf sur les terminaux mobiles. Leur conclusion est que les deux technologies sont très bien et qu’ils les apprécient toutes les deux. Cela rejoint l’avis que je vous ai toujours donné : ces deux technologies ont leurs avantages et inconvénients et ne devraient pas être opposées.

Il y a certes l’argument de la technologie propriétaire, mais il faut bien reconnaitre que les plugins nous rendent quand même de fiers services, ne serait-ce que sur YouTube ou sur Facebook, qui d’ailleurs vient de nouer un partenariat avec Unity (Facebook and Unity are now in a Relationship … and it’s Awesome!). Je vous propose donc de relativiser cette fronde anti-plugins et de privilégier le libre choix à une posture trop rigide.

Son arrivée prochaine chez Apple en tant que directeur technique a fait naître de nombreuses spéculations autour du portage prochain de Flash sur les terminaux mobiles d’Apple. De bien étranges spéculations dans la mesure où Flash est présent sur iOS depuis de nombreuses années, non pas dans le navigateur mais au travers de AIR. Un des plus grands succès de l’iPad (Machinarium) a par exemple été développé sous Flash. Précisons au passage que Flash n’est pas la seule technologie tierce présente sur iOS, je pense notamment à Unity utilisé entre autres pour The Room ou Temple Run 2.

Bref, tout ça pour dire que si Kevin Lynch a naturellement été un grand défenseur de Flash, son départ de Adobe ne signe pas l’arrêt de mort de cette technologie. L’essentiel de l’action de Kevin Lynch ces dernières années a ainsi porté sur la transformation des offres de l’éditeur qui sont passées d’un modèle de licence à un modèle SaaS. Cette tâche titanesque étant achevée, les offres Creative Cloud et Marketing Cloud sont disponibles sur de nombreux marchés, il va s’occuper du cloud d’Apple qui en a bien besoin.

Le départ de Kevin Lynch va en attrister plus d’un(e), mais Adobe est une grosse société qui emploie de nombreux autres talents, dont Ben Forta et notre Thibault national. Dans tous les cas, le départ d’une figure, aussi emblématique soit-elle, ne remet pas en cause la roap map d’un éditeur (Microsoft a également connu le départ de son CRO, Ray Ozzie). Flash va donc logiquement continuer son évolution : Adobe Flash Player 11.6 and AIR 3.6 now available et Google declares Flash is now ‘fully sandboxed’ in Chrome for Windows, Mac, Linux and Chrome OS.

Comma j’avais déjà eu l’occasion de l’expliquer, Flash est et aurait toujours dû être un produit de niche. Le fait est qu’avec la stagnation des spécifications HTML, la communauté s’est rabattu sur cette technologie pour proposer des expériences toujours plus différenciantes. Maintenant que HTML5 est là, Flash retrouve la place qu’il aurait dû avoir, notamment en se recentrant sur les jeux et la vidéo. Cela n’empêche bien évidemment pas Adobe de le valoriser en tant que support de créativité, comme c’est le cas au travers des Cutting Edge Projects : Adobe partners with FWA to highlight new, cutting edge Web designs every week.

Moralité : Flash continuera d’exister, au même titre que d’autres technologies propriétaires comme Quicktime, Unity ou 3DVia.

Le Responsive Web Design est donc un terme générique qui désigne une façon de coder une page web pour qu’elle s’adapte à tous les écrans. Cette technique à largement été popularisée par des sites de journaux prestigieux comme le précurseur Boston Globe ou dernièrement le Time Magazine.

Le problème du Responsive Web Design est que c’est une technique permettant d’optimiser l’affichage d’un site web conçu pour ordinateurs sur des terminaux mobiles, mais pas de répondre aux besoins spécifiques des utilisateurs en situation de mobilité. Le passage d’un ordinateur avec un grand écran, une souris et clavier à un petit écran tactile n’est pas une mince affaire. Il ne suffit pas de masquer des éléments sur le page ou d’en revoir l’ordre pour satisfaire les mobinautes. C’est un peu comme si vous me disiez qu’il suffit de réduire le nombre de rayons d’un hypermarché pour en faire une supérette de centre-ville. Réduire leur nombre ne suffit pas, il faut tout revoir : les zones de circulation, l’achalandage, la signalétique… Pour un site web, c’est la même chose : si le RWD fonctionne très bien pour un blog et plutôt bien pour un site éditorial, cette technique est par contre perfectible pour un site institutionnel ou une boutique en ligne. La version mobile du site du Vertbaudet est pour moi un très bon exemple : ils ont créé deux versions séparées pour maximiser l’expérience.

Plusieurs voix commencent à s’élever pour remettre en question la pertinence de certaines implémentations du RWD : Not All Responsive Web Design Is Created Equal. Pour résumer les propos de cet article : l’étroitisation de la mise en page pose de gros problèmes ergonomiques que des astuces de code ne peuvent pas forcément gérer (cf. Des mises en page adaptives aux systèmes de navigation adaptatifs).

Outre les problèmes ergonomiques, le RWD pose également quelques soucis en terme de référencement : When Responsive Web Design Is Bad For SEO. Le point de départ de cet article est l’outil mis à disposition récemment par Google pour consolider les URLs de version mobiles. Cet outil met un terme à la pénalisation de l’éparpillement des versions d’un site par rapport à l’utilisation d’une URL unique. Plusieurs arguments particulièrement pertinents sont avancés par l’auteur de cet article pour remettre en cause le choix du RWD :

• Les internautes en situation de mobilité utilisent des termes et équations de recherche très différentes de celles utilisées depuis un ordinateur fixe ;
• Les mises en page adaptives ne permettent pas de diminuer les temps de chargement (les éléments de la page sont chargés, mais pas affichés) ;
• La mise en page ne s’adapte qu’aux smartphones, les utilisateurs de feature phones sont donc mis de côté ;
• Cela limite la créativité et les possibilités offertes par le rich media.

En résumé : le Responsive Web Design est un compromis très intéressant pour toucher un maximum de mobinautes en limitant les coûts de développement, mais ce n’est pas une solution universelle, loin de là. Vous noterez d’ailleurs que les grands acteurs ne se limitent pas à un site en RWD (Amazon, Ebay…), ils éditent différentes versions pour maximiser l’expérience. Les investissements sont certes plus élevés, mais l’excellence à un prix.

J’ai publié récemment un article sur la façon de remédier aux problèmes de temps de chargement (Améliorez la performance de vos interfaces mobiles avec RESS), aussi je vous propose une piste de réflexion pour maximiser le référencement : utiliser des landing pages mobiles pour répondre aux besoins des internautes en situation de mobilité. Ces landing pages  mobiles seraient spécifiquement référencées en fonction des recherches utilisées en situation de mobile, et proposeraient les contenus et/ou fonctionnalités les plus pertinentes pour les mobinautes.

Tout ceci renforce le besoin des marques avec un minimum d’ambitions de nommer un Chief Mobile Officer pour bien appréhender les besoins des mobinautes et définir une feuille de route cohérente (cf. Pourquoi lancer une application mobile ne sert à rien).

Si j’avais été très sceptique au lancement de NaCl (Native Client, la technologie RIA de Google qui risque de faire long feu), c’est que les conditions de marché n’étaient pas très favorables et que les équipes de Google n’ont pas non plus dévoilé une feuille de route parfaitement claire et cohérente. En résumé : l’intérêt de faire tourner du code natif dans le navigateur en 2008 était plutôt limité. Impression confirmée il y a deux ans lors d’un second lancement officiel (Pourquoi Google a deux ans de retard avec Native Client). Je vous rappelle qu’à cette époque nous étions en pleine montée en puissance des terminaux mobiles et que le gain de performance promît par NaCl pour les processeurs x86 n’était encore une fois pas très vendeur (HTML5 était nettement plus sexy).

Nous sommes maintenant en 2013 et les terminaux mobiles ont envahi le monde (smartphones, tablettes, ultrabook…). Quasiment la totalité des internautes est équipée de terminaux mobiles et les utilisateurs veulent accéder aux mêmes services qu’avec leur ordinateur, ils ont donc besoin de puissance et le récent portage de NaCl sur les processeurs de famille ARM prend tout son sens (Native Client support on ARM). Grâce à NativeClient, les développeurs ont donc la possibilité de créer des applications en code natif qui exploitent directement les ressources de la machine (processeur et puce graphique) sans déperdition de puissance. La promesse est belle, mais elle est difficile à tenir, car la puissance se fait au détriment de la simplicité. En d’autres termes, il faut être talentueux et motivé pour mettre en oeuvre la technologie et profiter de ses bénéfices. D’autres éditeurs ont fait la même promesse, mais il semble que NaCl soit mieux cadré et plus rigoureux (Google Chrome Native Client compared with plugin or extension).

La stratégie de Google a donc été dans un premier temps de mobiliser la communauté des développeurs de jeux pour démontrer l’intérêt de NaCl : Games, apps and runtimes come to Native Client. Un certain nombre de jeux et démonstrations techniques sont donc sortis ces derniers mois, avec des authentiques succès comme AirMech (cf. AirMech Review).

Il existe aujourd’hui une petite vingtaine d’applications disponibles dans la galerie et les avis semblent converger : NaCl ouvre de formidables opportunités, mais requiert de gros efforts (The Ins and Outs of Native Client et The trouble with Google Chrome’s Native Client). Qu’à cela ne tienne, ils ont tout prévu : Gaikai ported to Chrome Native Client, which is a bigger deal than it sounds.

Tout ceci est très intéressant, mais les jeux en ligne sont un marché limité, même si on l’étend aux terminaux mobiles. La seconde étape du plan de Google est maintenant de s’attaquer au marché des applications d’entreprise où il y a de bien plus grosses sommes d’argent en jeu : Google Ports Quickoffice To Chrome Using Native Client, Will Get Full Editing Features In About 3 Months. L’arme secrète de Google est donc de proposer un environnement “léger” de création et d’édition de documents bureautiques exploitant la puissance de NaCl et distribué sur iOS, Android et Chrome. Autant des réalisations comme AirMech permettent de crédibiliser NaCl auprès des développeurs d’application, donc une petite audience ; autant QuickOffice est la clé d’entrée ultime de Chrome dans le monde de l’entreprise.

J’ai toujours été sceptique quant au succès de NaCl, mais son portage sur les processeurs de famille ARM (qui équipent l’ensemble des terminaux mobiles) et cette future nouvelle version de QuickOffice changent carrément la donne. Je suis persuadé que la prochaine conférence Google I/O le mois prochain sera l’occasion de donner un second souffle à NativeClient et surtout de déployer un levier de différenciation imparable. L’enjeu étant bien plus important que des jeux en ligne plus rapides (un autre article en préparation sur ce sujet).

Pour vous la faire simple, les discussions tournaient encore et toujours autour des mêmes arguments : les applications natives coûtent plus cher, mais sont plus performantes que leur équivalent en HTML5 qui facilite le déploiement, mais proposent une expérience bien moins riche. La performance et l’expérience utilisateur étaient donc au coeur de ce débat qui semblait pencher en faveur des très exigeants adorateurs de la marque à la pomme. Pourtant, les dernières statistiques ne donnent pas raison aux ayatollahs des applications natives (Android régnera sur le marché des smartphones en 2013, mais ne sera pas seul). D’autant plus que, comme le fait très justement remarqué Ryan Stewart, “it never pays to bet against the web” (Don’t Settle for a Mediocre HTML5 App Experience).

Nous en étions là dans ce débat complexe à appréhender, quand les équipes de Sencha nous ont livré un argument mettant définitivement fin aux discussions : une application HTML5 parfaitement optimisée peut être plus performante qu’une application native et délivrer une expérience similaire (The Making of Fastbook: An HTML5 Love Story). Le résultat est une application HTML5 disponible en ligne ici : Fastbook.

Les explications sont assez techniques (l’astuce consiste à filtrer le flux pour éviter de gâcher la bande passante), mais le résultat est très convainquant comme en témoigne la vidéo ci-dessous :

À partir du moment où l’adoption de HTML5 pour les applications mobile ne se fait pas au détriment de la performance, le choix est beaucoup plus simple à faire, d’autant plus avec les frameworks hybrides : How Hybrid Apps Are Accelerating HTML5 Adoption. Entendons-nous bien : le choix de HTML5 n’est pertinent que si vous devez étendre la présence d’une marque ou d’un service sur les terminaux mobiles. Si votre objectif est de lancer un service uniquement accessible sur smartphones Apple (comme l’était Instagram à l’époque), le contexte est très différent. Dans tous les cas de figure, le débat est enfin apaisé et nous sommes revenus à un niveau de discussion beaucoup plus sain où les arguments rationnels l’emportent : Why HTML5 Should Replace Native Apps for Ecommerce.

Moralité : Si nous sommes tous d’accord pour dire que l’idéal est que tous vos clients soient verrouillés au travers d’une application mobile native, il faut savoir revenir à la réalité du marché et reconnaitre que toutes les marques ou services en ligne ne peuvent imposer l’installation d’une application, car le temps, la motivation, les connaissances et la capacité de stockage des smartphones des utilisateurs sont limités. À partir de là, la meilleure approche est de commencer par servir le plus grand nombre d’utilisateurs avec une solution hybride qui comblera aisément les usages ponctuels. C’est votre priorité, car le développement et le déploiement de x applications mobiles natives vont devenir des tâches de plus en plus complexes et coûteuses.

Oui je sais, “article multimédia” fait résonner en vous les bons vieux CD-Rom des années 90. Même si le terme est un peu désuet (euphémisme), il reste néanmoins parfaitement valide pour décrire l’objet éditorial publié par le journal : un mélange de textes, images, vidéos et animations interactives. Le résultat final est un modèle d’élégance et de storytelling, il a d’ailleurs remporté un franc succès : More than 3.5 Million Page Views for New Yorl Times’ ‘Snow Fall’ Feature.

Ce sont ainsi près de 3 millions de visiteurs qui sont venus s’immerger dans ce récit passionnant et dans les nombreuses vidéos et infographies :

Le succès remporté par cet article soulève néanmoins de nombreux questionnements au sein de la profession. Si certains journalistes sont très enthousiastes (What the New York Times’s ‘Snow Fall’ Means to Online Journalism’s Future), d’autres sont plus mitigés (The good — and the bad — about the NYT’s Snow Fall feature et Avec “Snow Fall”, le New York Times cristallise les défis de la presse en ligne). Sont en cause dans cette histoire les coûts de production (visiblement très élevés) et les leviers de monétisation (de vulgaires bannières insérées à l’arrache dans l’article qui défigurent la mise ne page).

Je ne suis pas un expert de la production multimédia, loin de là, mais je constate que les outils à disposition pour produire et distribuer ce type d’article enrichi (notamment HTML5) permettent de limiter les investissements. La grande question est ensuite de savoir si vous vous positionnez comme un média qui produit de l’information brute (de l’information chaude au format texte) ou une expérience de lecture différenciante (des contenus tièdes ou froids avec une mise en page valorisante).

Mais le responsive design n’est pas la solution parfaite, car cette technique repose sur l’affichage ou non de certains éléments dans la page. Le problème est que tous les éléments chargés sont les mêmes, les images et fichiers javascript sont ainsi chargés, mais complètement sous-exploités par les smartphones. De même, les éléments tiers (bannières publicitaires ou plugins sociaux) sont chargés inutilement ou intégrés à l’arrache. Vous l’aurez compris, la performance de ces interfaces est donc un gros problème. Or, le temps d’affichage est un facteur-clé de succès de premier ordre.

Heureusement pour améliorer les performances il est possible de ne charger que les éléments dont vous avez besoin, voire de charger des éléments spécifiquement adaptés à un type de terminal. Cette technique a un nom, et c’est Luke Wroblewski qui l’a trouvé le premier : RESS = Responsive Design + Server Side Components. L’astuce consiste donc à détecter le type de terminal et à charger les éléments qui lui correspondent (images, fichiers HTML et javascript…). Dans l’exemple ci-dessous, il existe deux versions du header et du footer sur le serveur (pour desktop et pour mobiles), seule la version correspondant au terminal utilisé est chargée :

Cette technique est donc l’évolution logique du responsive design, car elle permet d’optimiser les temps de chargement, aussi bien pour les fichiers HTML et javascript que pour les images. Des explications plus détaillées sont disponibles ici : RESS, Server-Side Feature-Detection and the Evolution of Responsive Web Design.

Il existe également de nombreuses présentations didactiques sur le sujet, notamment ici :

Et ici :

Je vous invite à consulter également cette étude de cas sur le très beau site de l’université de Notre-Dame : Reinventing the Wheel, the Innovation Behind Notre Dame’s Unique New Homepage. Des sites à fort volume comme CNN ou WordPress ont déjà adopté RESS.

RESS est-il donc la solution ultime pour avoir des sites optimisés en fonction du terminal ? Oui, à condition que la détection fonctionne correctement. La détection du type de terminal est donc le talon d’Achille de cette technique. Pour en savoir plus, je vous recommande Server-Side Device Detection: History, Benefits And How-To.

Nous nous retrouvons donc avec trois options pour déployer du contenu ou un service en ligne :

• Un site unique en responsive design (qui n’utilise pas la détection, mais qui ne règle pas le problème de performances) ;
• Un site en RESS (bien optimisé, mais qui repose la détection) ;
• Une version mobile du site (très bien optimisé, mais qui repose également sur la détection).

Comme toujours, il n’y a pas de bon ou mauvais choix, uniquement des compromis à faire en fonction de vos ressources et compétences. Pour vous aider, je vous propose enfin ces deux articles qui étudient les avantages et inconvénients de ces trois solutions : Responsive Design, Device Experiences, or RESS? et A Comparison of Methods for Building Mobile-Optimized Websites.

Si vous avez des retours d’expérience, n’hésitez pas à les partager dans les commentaires.

La question que l’on est en droit de se poser est alors la suivante : le HTML5 va-t-il populariser le storytelling à grand renfort de mini-sites narratifs ? C’est bien possible, car les exemples ne manquent pas. Je vous propose d’en étudier trois qui me semblent représentatifs.

Dans le registre institutionnel, il y a tout d’abord Nutella Parlons-en, un mini-site dédié à apaiser les interrogations du grand public sur la composition de la célébrissime pâte à tartiner et notamment l’utilisation d’huile de palme. Ce mini-site propose une dizaine de pages au sein desquelles on navigue à l’aide de la molette de la souris. L’idée est manifestement d’égayer et de dynamiser un contenu plutôt rébarbatif.

Les pages s’enchainent facilement avec de très beaux effets de transition. On passe ainsi d’un panneau à un autre, on survole les titres, on s’attarde sur les images, et l’air de rien, on consulte bien plus de pages que si le site proposait un système de navigation traditionnel. L’objectif est donc atteint.

Deuxième exemple avec Le Hybrid 4 Graphic Novel de Peugeot. Le but de ce mini-site n’est pas de faire passer des messages institutionnels, mais de s’appuyer sur une BD pour mettre en situation les bénéfices du produit. Le mode de lecture est ici plus limité que dans l’exemple précédent, car il n’est possible que de scroller vers le bas, mais avec le défilement automatique activé, c’est presque comme un dessin animé.

La réalisation est soignée, et les transitions et animations apportent un vrai plus à la narration, à mi-chemin entre Ben the Bodyguard et Soul Reaper. Là encore, la cosmétique est un prétexte à vous faire rester plus longtemps sur le site, et ça marche.

Dernier exemple avec le livret blanc Au-delà du cloud produit par SFR. Nous sommes ici dans le domaine BtoB, mais le fait de proposer un format web pour ce livret blanc apporte une vraie valeur ajoutée, car le contenu est plus riche (vidéos…) et peut-être facilement mis à jour pour prolonger la durée de vie, contrairement à un fichier qui est figé dans le temps. De plus, ce livret blanc donne la possibilité de commenter certains articles ou paragraphes.

Comme pour les deux exemples précédents, le format permet de prolonger la visite et même d’en augmenter la portée grâce aux fonctions de partage intégrées nativement. Je vous confirme également qu’il s’affiche parfaitement sur mes trois tablettes (iPad, Nexus et Windows 8).

La conclusion que je peux logiquement livrer est la suivante : oui, HTML5 est bien LA technologie idéale pour faire de la narration interactive (digital storytelling comme disent les anglais). Idéalement, il ne manque plus que la possibilité de “télécharger” ces mini-sites pour pouvoir les consulter hors-ligne, une chose qu’il est pourtant très simple de réaliser en HTML5…