Cependant, malgr´e toutes ces APIs prometteuses et les progr`es accomplis ces derni`eres ann´ees, l’impl´ementation de toutes ces fonctionnalit´es dans tous les navigateurs est loin d’ˆetre compl`etement r´ealis´ee6. Le travail du d´eveloppeur web reste donc compliqu´e pour assurer le fonctionnement des applications sur les navigateurs les plus utilis´es. Si les principaux navi-gateurs tendent `a ˆetre de plus en plus compatibles, l’arriv´ee des navigateurs pour les appareils mobiles (par exemple iOS Safari, Opera Mini, Android Browser) complique de nouveau la donne.
L’´evolution des contenus, dont la partie suivante donne un aper¸cu, apporte d’autres contraintes et probl`emes de compatibilit´e pour le d´eveloppeur.
1.3 Evolution des contenus ´
Le≪site web≫form´e de pages HTML reli´ees entre elles fait d´esormais partie de la pr´ehistoire du d´eveloppement web. Aujourd’hui, un site web est un ensemble d’informations interconnect´ees avec le reste du monde. En effet, l’architecture du web change en proportion de la recomposition des≪pages web≫ comme un ensemble de services. Quand le sch´ema du premier web sugg´erait la logique de reproduction des m´edias, avec un ´emetteur (le serveur) qui composait une page qui serait servie `a un lecteur (le client) et remise en forme par son agent utilisateur (le naviga-teur) au moyen des feuilles de style, le nouveau web vise au contraire `a juxtaposer des parties documentaires et des parties interactives ou des≪services≫. Le d´eveloppement des widgets est un symptˆome de cette ´evolution des pratiques.
A l’origine du web, les pages ´etaient≪statiques≫, c’est-`a-dire qu’une page web correspondait
`
a un document dont le contenu ´etait fig´e. Chaque lecture d’une page se traduisait par le mˆeme observable. Puis l’int´egration de langages de programmation permettant une interaction entre un serveur web et une base de donn´ees a permis la cr´eation de pages dites≪ dynamiques≫. Le contenu est alors extrait d’une base de donn´ees, permettant ainsi des affichages diff´erents selon les situations, par exemple selon la date, les derni`eres donn´ees entr´ees dans la base de donn´ees, les pr´ef´erences de l’utilisateur, la g´eolocalisation, etc.
Avec l’arriv´ee du web dit ≪ 2.0 ≫, ce sch´ema a ´evolu´e. Les donn´ees servant `a constituer le contenu des pages web ne sont plus uniquement sur le serveur et la base de donn´ees du site web consult´e. Les contenus sont obtenus sur le web via une architecture orient´ee services en collectant des informations venant de flux RSS ou en interrogeant des services web. Le mod`ele de base de diffusion du Web et l’architecture du Web dit 2.0 sont r´esum´es sur la figure1.1.
Il est important de noter que les informations collect´ees sur le web transitent toujours, dans ce mod`ele, par le serveur interrog´e par l’usager. Mˆeme dans le cadre d’une interrogation de type
6. Voir par exemplehttp://caniuse.com/ ouhttp://html5test.com/ pour visualiser les fonctionnalit´es de chaque navigateur.
Figure1.1 – Mod`eles de diffusion du Web de base et du Web 2.0, architecture orient´ee services Ajax o`u seulement une partie de la page est recalcul´ee et rafraˆıchie, le serveur reste respon-sable du contenu envoy´e `a l’usager. Le programme du serveur peut soit choisir de reproduire int´egralement ce qui aurait ´et´e fourni par un tiers (mod`ele d’agence, ou de marque blanche), soit de traiter l’information du tiers pour y apporter diverses valeurs ajout´ees (mise en contexte, tri des informations. . . ou insertion de la publicit´e pour les webm´edias, etc).
Deux techniques peuvent ˆetre utilis´ees pour interroger des services web. La premi`ere, soutenue par le W3C, est bas´ee sur les technologies XML et doit permettre une automatisation totale : de la recherche du service web `a utiliser (UDDI7) `a l’interrogation du service via le proto-cole SOAP [Mitra & Lafon 07] en passant par la description du service propos´e sp´ecifi´e en WSDL [Christensen et al. 01].
Au vu de la complexit´e de mise en œuvre de ces technologies, l’enthousiasme n’est pas de mise chez les d´eveloppeurs web. Seules les structures disposant de comp´etences avanc´ees en XML investissent r´eellement dans l’utilisation des services web avec SOAP et WSDL.
D’autant plus qu’une nouvelle technique, bas´ee sur l’architecture REST [Fielding 00] ap-paraˆıt. Soutenue au d´epart par Yahoo ! et ses filiales, cette technique est vite devenue la plus utilis´ee par les web designers. Le service web est accessible via un URI et les informations n´ecessaires pour l’interroger sont transmises directement via une requˆete HTTP (en m´ethode GET pour les plus simples). Par exemple, une recherche sur le web service REST de Flickr pour
7. Universal Description Discovery and Integration, `a l’origine un projet de recommandation du W3C, aujour-d’hui un mod`ele de recherche de web services soutenu par quelques grands industriels, mais en perte de vitesse.
Voirhttp://en.wikipedia.org/wiki/UDDI.
1.3. ´Evolution des contenus 19 des images de l’utilisateurx32b s’effectue avec l’URL :
http://api.flickr.com/services/?api_key=1234&user_id=x32b&method=flickr.people.getPhotos.
Le service web r´epond alors en envoyant des donn´ees XML (ou sous d’autres formats, comme le populaire JSON8) contenant les r´eponses.
La principale raison du succ`es de cette m´ethode est son extrˆeme simplicit´e de mise en œuvre.
En particulier, elle ne n´ecessite pas de connaissances avanc´ees en XML, comp´etence assez peu d´evelopp´ee chez les web designers. Une autre raison du succ`es de la m´ethode REST r´eside dans le fait que XML n’est plus le seul format d’´echange possible, contrairement `a l’utilisation de SOAP.
Par exemple, le service web de Flickr propose ses r´esultats en XML, PHP s´erialis´e, JSON ou JSON avec appel de fonction callback (technique appel´ee JSONP9).
Avec le format JSON, les informations re¸cues peuvent ˆetre imm´ediatement trait´ees par le programme Javascript qui met `a jour la page web. De plus, si un appel de fonctioncallback est ajout´e `a la r´eponse du serveur (JSONP), alors les ´echanges peuvent se faire directement entre le client et le serveur tiers en utilisant uniquement Javascript. La contrainte li´ee `a l’utilisation d’Ajax qui limite les ´echanges au mˆeme domaine, se trouve alors lev´ee. Les d´eveloppeurs peu-vent dans ce cas utiliser directement dans leurs pages les APIs propos´ees par les fournisseurs de service. Cette technique permet de d´evelopper tr`es rapidement diverses fonctionnalit´es, de l’affichage des derni`eres photos publi´ees sur Flickr aux cartes interactives de Google maps par exemple.
On retrouve ici l’opposition entre l’objectif de p´erennit´e et d’ind´ependance repr´esent´e par XML, qui n´ecessite des op´erations de traitement lourdes, et l’objectif de rapidit´e et simplicit´e de d´eveloppement demand´e par les web designers. Cependant, les informations transmises dans les donn´ees JSON ne sont justement que des donn´ees. L’affichage est renvoy´e au programme Javascript qui devient le point nodal de reconstruction du document. Or, un document est plus qu’un simple ensemble de donn´ees, il est associ´e `a une pr´esentation et un processus ´editorial. Nous montrerons `a la section 1.4 que d’autres possibilit´es existent pour les ´echanges de documents, et non simplement de donn´ees.
L’utilisation de JSON et JSONP, coupl´ee aux fonctionnalit´es DOM et Javascript des nav-igateurs, permet donc d’interroger directement des services tiers, sans transiter par le serveur du site web qui a d´elivr´e la page web. Cette architecture, qui ne change apparemment rien du point de vue de l’internaute lecteur, est fondamentalement diff´erente. En effet, les informations ne transitent plus via le serveur du site web qui distribue le contenu et en est responsable, mais les communications se font directement entre le client et le serveur tiers. La figure1.2montre les deux modes de fonctionnement pr´esent´es ci-dessus. Pour fonctionner, un programme Javascript ex´ecut´e sur le navigateur est n´ecessaire. Celui qui fournit ce programme poss`ede la maˆıtrise de
8. Javascript Object Notation :http://json.org/
9. JSON with Padding :http://en.wikipedia.org/wiki/JSONP
Figure 1.2 – Comparaison entre interrogation de services web par un programme ex´ecut´e sur la machine client et interrogation de service web via unwidget
la pr´esentation de l’information. Il importe donc de savoir s’il est fournit par le distributeur ou par le fournisseur de l’information tierce, ce qui a un impact imm´ediat sur la publicit´e associ´ee.
Google maps est l’exemple le plus r´epandu de cette contradiction. On parle de widgets pour d´esigner des packages complets fournis par le producteur de l’information tierce. C’est par ex-emple le choix de Google pour l’usage de toutes ses APIs, que ce soit Google maps, les APIs de visualisation et de recherche documentaire ou de diffusion de vid´eo par YouTube... et bien
´evidemment les APIs de publicit´e AdSense.
L’architecture de web services, telle qu’elle existait au d´epart, est une forme de relation B2B (≪ business to business ≫) entre serveurs, assimilable `a la relation entre la presse et les agences. Elle est cependant en train de se voir supplanter par une architecture dans laquelle une page pr´esent´ee par un distributeur (i.e. un ≪ m´edia-web ≫) contient non pas des informations produites par un tiers, qui auraient ´et´e ´eventuellement retrait´ees (architecture de web services) mais incorpore une application (en langage de script) qui interagit directement avec le prestataire de cette information tierce.