L’Après Web sur le plan technique

L'Après Web

Alain Lefebvre
Une contribution d’Alain Lefebvre*

Le renouveau du web à partir de 2002, déclenché par ce qu’on a ensuite appelé le Web2, avait aussi une dimension technique.
La face visible de cette évolution technique, c’est bien entendu AJAX qui a étendu les capacité de l’interface web là où elle en avait le plus besoin. La face moins visible, c’est la généralisation de l’ensemble LAMP : Linux, Apache, MySQL et PHP (au détriment des offres Microsoft et Java).

L’ensemble LAMP a fait la preuve sur le terrain de sa facilité de mise en oeuvre tout en alliant souplesse, performances et capacité de montée en charge. Aujourd’hui, le front s’est déplacé sur le terrain des frameworks PHP sensés offrir encore plus de facilité (et donc de rapidité) de développement tout en apportant plus de rigueur dans le cycle de développement/déploiement.

On en est là mais que peut-on espérer pour la suite ?

L’avenir n’est écrit nul part et les prévisionistes sont voués au ridicule… Cependant, on peut toujours identifier quelques pistes qui sont porteuses de sens, suivez le guide !

On peut facilement imaginer que LAMP va rester l’environnement de développement/exploitation privilégié mais que les évolutions (voire les changements de cap) vont faire rage autour et au-dessus de cet ensemble.
Voyons d’abord ce qui va se passer au-dessus, c’est-à-dire au niveau de l’interface utilisateur… Il apparait difficile de faire vraiment beaucoup mieux qu’AJAX pour étendre encore l’enveloppe HMTL/CSS et ce progrès n’est pas arrivé gratuitement.
En effet, on constate que beaucoup de sites ont du mal à maintenir correctement leur fonctionnement à ce niveau… à cause des navigateurs Web !
C’est vraiment au niveau du client Web que les choses se gâtent : MS Internet Explorer est encore -trop- dominant alors que sa capacité à rendre correctement les sites qui repose intensivement sur AJAX est pour le moins mauvaise. C’est dans cette perspective qu’il faut comprendre l’initiative de Google de proposer « Chrome » sur le terrain des navigateurs web : pas pour relancer la « guerre des browsers »mais plutôt pour redynamiser ce secteur et l’orienter techniquement.

Donc, il n’est pas impossible qu’on assiste là à une « bifurcation »…Et dans ce cadre, la proposition d’ Adobe est bien placée !
L’interface d’un hypothètique web3 pourrait être basé sur Air/Flex car celle-ci offre vraiment une indépendance par rapport au navigateur qui l’exécute (et dans de bien meilleures conditions que Java qui n’a jamais pris sur le poste client et pour de bonnes raisons).
Voilà pour l’interface utilisateur, voyons maintenant les interfaces de programmation.

Au début des années 2000, on mettait beaucoup d’espoirs dans un « web des machines » où les serveurs parleraient entre eux via des protocoles standards. SOAP était le candidat N°1 pour ce rôle mais force est de reconnaitre que bien des années après, SOAP a beaucoup déçu !
SOAP a fini par tomber dans les mêmes travers que CORBA : compliqué et jamais terminé… à oublier. REST est LA bonne alternative standard à SOAP mais je constate qu’il reste encore (sans jeu de mots…) relativement peu utilisé.

En revanche, ce qui est de plus en plus utilisé, c’est l’approche « mashup » : utiliser les ressources d’un (ou plusieurs) site(s) au sein du sien. L’exemple classique, c’est le site d’annonce immobilières qui s’appuie sur Google Maps pour montrer la localisation des biens en vente. Je ne serais pas surpris de voir cette tendance au mashup croitre et multiplier au point de devenir une des principes de base du web3.
On voit déjà que les services de réseaux sociaux offrent des APIs permettant d’aller dans ce sens. On connait déjà les mini-apps de Facebook et, avec Open Social, cette tendance va se généraliser au-delà de Facebook.

Le schéma idéal du service du futur pourrait ressembler à cela :

  • gestion de la connexion par un tiers standard (comme OpenID),
  • interface utilisateur basée sur Air/Flex,
  • récupération des données et des contenus utilisateurs via APIs vers les blogs et réseaux sociaux de ces utilisateurs,
  • utilisation intensive de services externes (approche mashup) pour valorisation de ces données et contenus.

Bien entendu, tous ces points mériteraient bien plus de place que ne le permet ce modeste article et je ne prétend pas que ma vision des choses va forcément se réaliser mais je crois que ces quelques pistes ont une -bonne- chance de se concrétiser… Wait and see!

Alain Lefebvre

*Alain Lefebvre fût co-fondateur de SQLI,  il est aussi le fondateur du réseau social 6nergies , consultant en TIC et auteurs de plusieurs ouvrages dont notamment Les réseaux sociaux (Seconde édition,  M21 Editions – 2008)

Denis Henri Failly

QR Code - Take this post Mobile!

Use this unique QR (Quick Response) code with your smart device. The code will save the url of this webpage to the device for mobile sharing and storage.

facebooktwittergoogle_pluslinkedin

Laisser un commentaire

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

HTML Snippets Powered By : XYZScripts.com