Journalisme et temps réel : technique et perspective

Cet article introduit en douceur l’une des idées que je voudrais développer dans ce blog : la technologie se met au service du journalisme et de fait, en empruntant certains chemins, l’innovation peut précéder le média. Nombreux sont ceux déjà convaincus par ce point de vue, c’est pour cette raison que j’essaie d’avantage d’en donner des cas pratiques plutôt que d’en dépeindre une vision académique qui dépasserait de loin mes compétences.

~

La vitesse étant l’une des grandes notions du XXIème siècle, il est captivant d’observer comment l’apparition d’un nouveau protocole d’échange peut adhérer aux problématiques du journalisme moderne. De Twitter aux médias pure players, jamais le lien entre journaliste et lecteurs n’aura été aussi proche de l’instantané.

L’une des dimensions nouvelles qui ponctue de près l’adoption du HTML5, est celle du Web en temps réel, mise en place par le protocole WebSocket. Pour les néophytes, WebSocket est un protocole standardisé qui vise à établir des connexions bi-directionnelles entre un serveur et un navigateur Web. Vulgairement, cela signifie que les navigateurs compatibles avec cette technologie peuvent « se mettre à l’écoute » de nouveaux messages, et mettre à jour le contenu d’une page en conséquence…

À ce jour il y a peu de solutions côté client pour mettre en place une telle architecture. Les dernières versions de Chrome (9.+) et Firefox (4.+)1 embarquent bel et bien le support de WebSocket mais leur diffusion étant pour l’heure assez réduite, son usage ne peut se faire qu’à titre expérimental.

Node.js, qui nous sert d’exemple ici, n’apporte aucune solution à ce cruel problème de compatibilité. Sa tâche à lui, c’est d’agir comme serveur d’applications réseau, d’offrir un service en se basant sur un concept élémentaire : l’écriture des applications serveurs et clientes dans un langage commun, ici, le Javascript.

Du Javascript sans faire du Javascript

Node.js n’offre pas seulement un environnement d’exécution pour Javascript, il lui fournit également un ensemble de fonctions et de classes. En effet, Javascript ne supporte pas nativement l’ouverture de connexion HTTP ou encore l’écoute sur certains ports et la gestion du protocole TCP. C’est donc pour offrir un support complet de ces différents protocoles d’échange, que Node.js intervient auprès de Javascript. Outre ces besoins élémentaires, l’outil qui est véritablement un Framework, apporte également des solutions aux développeurs pour accéder au système de fichiers, simuler des événements et enfin, créer des modules qui étendent ses capacités.

C’est en outre grâce à ce dernier point qu’il est déjà possible d’implémenter des serveurs utilisant le protocole WebSocket, encore au banc d’essai mais de plus en plus populaire (retrouver le module WebSocket pour Node.js).

Ce constat m’a encouragé dans un premier temps à me poser certaines questions. Si le support de WebSocket reste pour l’instant limité, l’intérêt d’une solution comme Node.js ne s’en trouve-t-elle pas diminuée ? En effet, ces fonctionnalités sont toutes déjà supportées par des langages comme Java ou C++ et s’il n’en demeure pas moins que Node.js est très facile à utiliser, ses performances sont difficilement comparables à celles des langages compilés. La position adoptée par Node.js mérite d’être défendue car elle offre un compromis entre la programmation web et la programmation côté serveur. Il serait toutefois dommage de nier que parmi ses fonctionnalités, aucune n’est nouvelle et par conséquent, sans substitut.

Coup d’œil du développeur

Alors donc, que diable peut-il bien apporter que les autres n’ont pas ? La réponse est simple car au cœur de la stratégie adoptée par le framework : le Javascript. Oui le Javascript ici, c’est la clef ! Ce langage est bien souvent une plaie, il a mal vieilli et se traîne depuis longtemps un grand nombre d’aberrations conceptuelles. Pourtant il demeure très facile à apprendre, à utiliser, il est très souple et offre un support totale du DOM. Mais ce n’est pas tant pour ses qualités que le choix de ce langage est judicieux. En proposant le paradigme d’une programmation événementielle côté serveur et en partageant sa syntaxe avec celle du client, Node.js initie une certaine forme d’interopérabilité entre les composantes d’une architecture qui, sur le Web, nous a habitués à travailler avec des langages souvent antinomiques.

En y réfléchissant, cela parait être l’évidence même : pourquoi confondre des méthodes aux fonctionnements radicalement opposés quand le besoin est somme toute celui d’un usage interactif et asynchrone ? L’adoption large et unanime d’une technologie comme AJAX est révélatrice d’une évolution des besoins de l’utilisateur final et pendant que les interfaces gagnent en richesse, les serveurs eux, continuent de fonctionner sur des dynamiques synchrones. À moyen terme, ça n’a aucun sens.

Bien que son usage pour WebSocket soit limité, il est envisageable d’utiliser Node.js pour mettre en place des solutions temps réel. Sans ce protocole, il est impossible d’établir une connexion longue entre un navigateur et un serveur. Toutefois des techniques existent pour simuler un tel comportement… Ces techniques dites de polling et/ou de long polling consistent pour le client à établir à intervalles réguliers des connexions HTTP, plus ou moins longues, vers le serveur pour en extraire les informations nouvelles. Ces procédés sont pour la plupart gourmands en bande passante, mais il est important de préciser que grâce à Node.js, leur consommation de ressources sur le serveur s’en trouve considérablement réduite.

Coup d’œil du (data-)journaliste

Vous l’aurez compris, Node.js et WebSocket, ce n’est pas encore pour demain. Néanmoins, comme il est facile d’anticiper leur démocratisation dans un futur proche, partons du principe que cette technologie est déjà pleinement fonctionnelle pour en dessiner les applications (journalistiques, s’il en est).

Je pense tout d’abord au crowdsourcing2, où puiser des mises à jour en temps réel peut s’avérer d’une efficacité redoutable. Mettons par exemple que la saisie se fasse directement sur Twitter à l’aide d’un #hashtag, au cours d’un évènement bien précis (meeting, conférence, manifestations, etc). Dès l’instant où le système détecte un nouveau Tweet, il peut le transmettre à tous les utilisateurs et modifier les différents graphiques, listing et cartes qui seraient associés à l’opération.

D’autres opérations sont envisageables, comme la création d’un Serious Game3 où les joueurs pourraient interagir entre eux – de ce coté là, rien de nouveau, mais l’aubaine technologique (aubaine car accessible) est telle qu’elle tend à encourager ce type d’expérience.

Aussi l’échange de document à la demande et/ou dès leur mise à disposition peut lui aussi s’avérer intéressant lors d’un liveblogging… Récemment, OWNI.fr à mis sur pied une “Nuit Sujet” au cours de laquelle, les journalistes se sont succédés à l’antenne de Radio Nova pendant 6 heures sur le thème “Dégage !”. Pour accompagner cette émission en direct, une web app était disponible sur le site de owni.fr où un Storify faisait office de liveblogging. D’autre outils comme une timeline sur le hashtag #nuitSujet ainsi  que des sondages étaient également présents avec une constante pour chacun d’eux : leur mise à jour en temps réel4 – Storify y compris. Dans ce cas précis, celui du direct, la recherche d’une proximité avec les auditeurs ainsi que leur implication dans l’émission ne pouvait se faire sans l’apport d’une telle technologie…

Cet exemple comme les opportunités offertes par l’instantanéité nous laissent présager de nouveaux usages dans le journalisme de données. En filigrane, son idéal cherchera à placer l’interactivité au cœur de l’article lui même, posant les premières pierres d’un journalisme évolutif et augmenté d’une intelligence technique.

~

Le parallèle entre Node.js pour les techniciens, et le temps réel (au sens large) pour les journalistes est intéressant car ils ont tous deux une caractéristique commune. D’un coté il permet au journaliste de fluidifier la diffusion de l’information, d’un autre coté il permet au développeur de fluidifier ça mise en œuvre. Node.js, en nous mettant sur les rails de la programmation Client/Serveur, force de véritables paradoxes dans le métier de développeur web. Aussi, le temps réel conditionne notre manière de modéliser, d’implémenter et d’ordonnancer les processus de nos travaux. Technologiquement, le temps réel est un défi car nous sommes en terre inconnue mais c’est peut-être l’intérêt majeur de Node.js : mettre en œuvre des techniques dans un environnement nouveau à l’aide d’un outil déjà maîtrisé.

Pour aller plus loin

Des tutoriels pour installer Node.js existent sur     Mac     OSX, sur Linux et     sur Windows. Enfin, je vous conseille d’aller jeter un oeil à la documentation de Node.js

  1. Firefox a récemment suspendu le support de WebSocket car certaines analyses soutiennent que le protocole présente encore de trop importantes failles de sécurité. []
  2. Selon Wikipedia, le crowdsourcing consiste à « utiliser la créativité, l’intelligence et le savoir-faire d’un grand nombre de personnes (des internautes en général), en sous-traitance, pour réaliser certaines tâches traditionnellement effectuées par un employé ou un entrepreneur. » []
  3. Selon Wikipedia, un Serious Game est « un logiciel qui combine une intention sérieuse, de type pédagogique, informative, marketing, idéologique ou d’entraînement avec des ressorts ludiques issus du jeu vidéo » []
  4. Mise à jour en temps réel ou presque puisque comme je le souligne plus haut, WebSocket n’est pas encore disponible sur tous les navigateurs. Il nous a donc fallu utiliser quelques artifices… []

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>