On se croirait revenu en 1999 : le Web est en pleine effervescence. Des start up se créent chaque jour, et les capital risqueurs sont à l'affût. On reparle même de révolution internet, la seconde celle du Web version 2.0.

Dans ce nouveau monde, l'internaute ne se contente plus de cliquer sur des liens hypertextes. Il organise, manipule et produit de l'information, exactement comme avec une application bureautique. Ce fameux Web 2.0 a déjà ses pionniers, ses hérauts et ses icônes. Il suffit de jeter un oeil sur Zimbra, Flikr, Goowy ou 24 Sevenoffice pour mesurer l'écart avec le Web tel qu'on le connaît. Jusqu'ici, chaque clic effaçait la page et provoquait un aller-retour avec le serveur. Maintenant, l'affichage est instantané. On profite du glisser/déplacer, des menus déroulants, des raccourcis clavier, et même du clic droit.

L'ergonomie n'a rien à envier aux applications locales. Et pourtant, il s'agit toujours de pures applications Web. Il n'y a rien à installer au préalable : ni plug in ni machine virtuelle. Tout fonctionne à l'identique quels que soient le navigateur et la plate-forme. Pour le directeur informatique, c'est le rêve. S'il pouvait appliquer ces techniques aux applications client-serveur, il réglerait d'un coup ses problèmes de déploiement. Les mises à jour seraient automatiques, sans procédure d'installation ni la nécessité de gérer des droits particuliers pour installer tel ou tel composant.

Nul besoin non plus d'avoir des PC de compétition. Un navigateur suffit. Qu'il soit sous Linux, Mac OS ou Windows, l'application fonctionnera de la même façon. Aurait-on trouvé le chaînon manquant des applications Web riches ?

Avant de répondre, tâchons de comprendre comment font Zimbra et consorts pour développer ces applications en ligne. Ils utilisent une technique simple, vieille de sept ans : le transfert asynchrone. Plutôt que de charger des pages entières à chaque clic, ils ne récupèrent en tâche de fond que les paquets de données nécessaires, décrits en XML (XMLHTTPRequest). Ils s'appuient ensuite sur le langage Javascript du navigateur pour modifier tel ou tel élément de la page grâce au langage HTML dynamique.

C'est aussi Javascript qui gère les menus déroulants, le glisser/déplacer ou l'affichage des boîtes de dialogue. Et comme XMLHTTPRequest et Javascript existent dans tous les navigateurs modernes, l'application est, de facto, multiplate-forme. En réalité, le développeur doit néanmoins composer avec les différences d'implémentation de Javascript.

La technologie a l'avantage de n'appartenir à personne. Comme Linux, elle a évolué hors du sillage des fournisseurs. Outlook Web Access l'a inaugurée le premier en 1998, mais c'est Google qui l'a rendue célèbre avec Google Maps au début de l'année. Puis tout s'est accéléré au mois de mars, quand un consultant du cabinet Adaptive Path a formalisé l'ensemble et lui a donné le nom ronflant d' Ajax. Depuis, le terme s'est diffusé comme une traînée de poudre. Provoquant un battage sans précédent chez les développeurs.

Seulement voilà. Ajax est encore loin d'être mûr. Rappelons que ces techniques, quoique anciennes, ne sont formalisées que depuis quelques mois. Elles ont démontré leur intérêt pour de petites applications en ligne. Mais qu'en est-il pour les grosses applications d'entreprise, celles écrites en Powerbuilder, Visual Studio, Delphi et autres Windev ? Là, les avis sont partagés.

Il y a ceux qui n'y croient pas du tout. Leurs plus grands reproches concernent Javascript. Pour eux, ce n'est même pas un langage, mais un bricolage inventé pour effectuer quelques traitements locaux sur le navigateur. Il n'est pas orienté objet, ses variables ne sont pas typées, et il lui manque des notions de haut niveau. Résultat : le développeur peut écrire n'importe quoi, n'importe comment, car le langage offre une trop grande liberté.

Développer en Ajax peut aussi devenir très compliqué. Pour s'en convaincre, un coup d'oeil sur le code de Google Maps suffit. Tout y est codé à la main : la transaction HTTP avec le serveur, la manipulation des données XML, les différences entre les navigateurs. Ici, pas de développement visuel.

Les programmeurs débutants peuvent s'abstenir. Pire : comme les outils d'aide au développement, au test, à la maintenance ou à la documentation manquent encore, les délais deviennent totalement flous. Difficile, dans ces conditions, d'industrialiser le développement. Bâtir des applications professionnelles dans un tel contexte est perçu au mieux comme une solution à courte vue, au pire comme une hérésie. Sans compter que le concept multiplate-forme relève souvent du rêve. Même la référence Google Maps rencontre encore des problèmes avec Safari, le navigateur des Mac.

Pour ces sceptiques, Ajax est avant tout une lubie, qui autorise les développeurs frustrés par HTML à s'exprimer à nouveau avec un outil qui ressemble au client-serveur. Tant que les outils ne seront pas au niveau des ateliers de développement du marché - et cela prendra du temps - « toute autre solution sera toujours plus efficace qu'Ajax ».

En attendant, le seul intérêt qu'ils lui reconnaissent est d'éviter de recharger plusieurs fois les mêmes éléments d'une page. Ajax est donc parfait pour économiser de la bande passante. Mais pour le client-serveur, il repassera.

Faux ! rétorquent les enthousiastes. Ajax à beau être jeune, son écosystème s'étend à une vitesse phénoménale. L'intérêt est tel que, depuis cet été, il ne se passe pas une semaine sans l'annonce de nouvelles bibliothèques de développement. Le niveau de connaissance augmente, et la plupart des problèmes de jeunesse sont réglés ou en passe de l'être. Des différences existent entre les navigateurs ? Des bibliothèques viennent masquer cette complexité. XML est trop verbeux pour certains transferts de données ? Préférez-lui JSON. Ses objets Javascript binaires plus compacts réduisent les traitements côté client. C'est la méthode adoptée par Google Maps.

Mais quid des outils de test et des ateliers de développement visuel ? Ils arrivent doucement chez Tibco (General Interface) et Backbase. Quant à JSUnit, HTTPUnit et Selenium, ils assurent le débogage et JSDoc la documentation. On attend aussi beaucoup de Microsoft, qui vient de présenter Atlas, son framework Ajax pour Visual Studio.

Bien sûr, ces outils ne sont pas encore au niveau de ceux que l'on trouve dans d'autres environnements. Mais ils progressent vite. L'idéal serait de standardiser les bibliothèques pour ne pas avoir à réapprendre une interface de programmation à chaque fois que l'on change de fournisseur.

Se pose aussi le problème du multimédia. Sans extension, le navigateur ne sait produire ni son ni animation. Un sérieux handicap face au client-serveur. Alors certains ont eu l'idée d'utiliser Flash. Il est quasiment installé sur tous les navigateurs, et rien n'empêche de le piloter avec Javascript au lieu de l'Actionscript de Macromedia. C'est d'ailleurs la technique qu'a retenue Goowy pour son bureau virtuel. Le résultat est saisissant : on se croirait sous Mac OS X !

A voir certaines réalisations, cloner une application client-serveur en Ajax ne poserait aucun problème. Jackbe a ainsi reproduit à l'identique une application de gestion Visual Basic. Multifenêtrage, boutons avec icônes, raccourcis clavier, tout y est. Ajax laisse tout de même une grande liberté de mise en oeuvre. Certains choisissent d'effectuer un maximum de traitements sur le serveur, n'abandonnant au navigateur que la partie présentation. D'autres optent pour un maximum de traitements sur le client. Mais attention à l'overdose de Javascript dans les pages. Les temps de chargement s'allongent, et l'application est ralentie. Tout réside dans un savant dosage.

La guéguerre entre partisans et réfractaires à Ajax risque finalement d'être arbitrée par les utilisateurs. Quand ils auront goûté à des applications Web 2.0 comme Gmail, ils auront du mal à revenir en arrière. Ils ne comprendront pas pourquoi leur application Web d'entreprise est si lente et si peu ergonomique. Ce sont eux qui pousseront à adopter Ajax.

Restera tout de même un problème insoluble : le travail hors ligne, sur un portable, quand il n'y a pas de connexion internet. Car même si elle a l'air d'une application locale, une application Web restera toujours une application Web.