Basée sur des technologies standards telles que HTML et JavaScript, l’architecture Ajax (Asynchronous JavaScript and XML) améliore l’ergonomie des applications Web en la portant presque au même niveau que celle des applications Windows traditionnelles. Elle propose en outre un modèle de programmation événementielle très proche de langages largement maîtrisés comme Visual Basic.

Enfin, Ajax améliore les temps de réponse des applications Web en isolant le comportement de chaque composant graphique : seuls ceux qui nécessitent une mise à jour sont rechargés.

Malgré sa jeunesse, cette architecture possède donc de sérieux atouts pour séduire les entreprises. Nombre d’entre elles combinent ainsi le meilleur du Web - pas de déploiement, mise à jour automatique de l’application... - et de l’architecture client-serveur traditionnelle : ergonomie de l’interface, temps de réponse, etc.

Ajax représente également une alternative attrayante aux clients riches. « Pour développer notre application de présentation et de consultation des dossiers médicaux des patients, nous n’avons pas hésité face à une architecture client riche », explique François Lion, chef de projet à l’Institut Gustave Roussy, premier centre européen de lutte contre le cancer. « A l’époque [2002, NDLR], XUL était la seule alternative viable, mais elle imposait un navigateur, Firefox ou Mozilla », détaille-t-il.

En revanche, Ajax n’est pas toujours adaptée au développement de certaines applications de bureau. « Contrairement aux promesses du client riche, le client léger Ajax ne dialogue pas facilement avec les ressources locales du poste de travail - logiciels, système d’exploitation, etc. - et ne peut pas non plus stocker d’importantes quantités de données en local », met-il en garde. Des restrictions qui sont essentiellement liées à la politique de sécurité des navigateurs.

L’utilisation : plus de confort pour l’utilisateur

Dans ce contexte, les entreprises cherchent surtout à apporter davantage de confort aux utilisateurs d’applications Web. Ce confort ne se traduit pas simplement par la possibilité d’effectuer des glisser-déplacer ou des copier-coller au sein des pages Web. Il s’agit également d’optimiser les temps de réponse du logiciel en s’appuyant sur les échanges asynchrones de cette nouvelle architecture.

Le Centre d’information et de documentation de la jeunesse (CIDJ) édite, par exemple, un corpus de 360 fiches sur divers sujets susceptibles d’intéresser les jeunes : métier, formation, emploi, mobilité internationale, etc. « Pour publier ces fiches sur le Web, nous avons choisi Ajax afin d’offrir un meilleur confort de navigation à nos utilisateurs en leur permettant d’interagir avec notre serveur sans rechargement de pages », illustre Marc-André Grosy, responsable informatique du CIDJ.

« Pour faciliter la saisie des mots-clés qui permettent d’accéder aux fiches, nous avions besoin de fonctions de complétion [remplissage automatique des champs, NDLR] basées sur une liste de plusieurs milliers de mots-clés. La transmission de la totalité de cette liste impliquait un important flux de données, et donc un temps de chargement et de traitement trop long côté client. Ajax nous a permis de filtrer les données à transmettre, et donc d’accélérer la navigation », explique Victor Spanneut, responsable du projet au CIDJ.

Le réseau social 6nergie.com et le gestionnaire de patrimoine Richelieu Finance utilisent, de leur côté, l’architecture Ajax pour permettre, entre autres, l’édition de pages Web directement depuis le navigateur en mode Wysiwyg. « Chaque membre peut ainsi mettre à jour sa fiche directement, sans passer par un formulaire spécifique », explique Alain Lefebvre, fondateur de 6nergie.com.

L’interface d’administration du site Web de Richelieu Finance repose sur le même principe. « C’est une approche bien plus efficace que celle proposée par le back office des outils de gestion de contenu traditionnels », constate Hervé Schmitt, responsable e-business à Richelieu Finance. Son entreprise s’est également appuyée sur Ajax pour développer un simulateur de fonds en ligne. « Il s’agit davantage d’une application interactive que d’une simple page Web. Dans ce cadre, la programmation événementielle proposée par l’architecture Ajax était bien plus appropriée qu’une approche Web traditionnelle », explique Hervé Schmitt.

La mise en oeuvre : les frameworks accélèrent les développements

L’Institut Gustave Roussy a développé son propre framework Ajax entre 2002 et 2004. « A l’époque, on ne parlait pas encore d’Ajax, et aucun framework n’était disponible », indique François Lion. Le développement a nécessité deux personnes à mi-temps pendant deux ans et demi, et a donné naissance à Rialto, un framework open source qui rencontre un certain succès en France depuis qu’il est promu et diffusé par la SSII Improve.

Contrairement à l’IGR qui a lancé très tôt son projet, la plupart des entreprises font aujourd’hui appel à un prestataire pour les accompagner - ’est le cas du CIDJ, de 6nergie.com et de Richelieu Finance - et s’appuient sur des frameworks Ajax prédéveloppés. Richelieu Finance a, par exemple, exploité Symphony, dont la partie serveur est écrite en PHP.

La mise en oeuvre d’Ajax nécessite cependant des développeurs expérimentés, qui sont encore rares. Mais, grâce aux frameworks, un développement Ajax ne prend pas tellement plus de temps qu’une application Web traditionnelle. « Il ne nous a fallu que cinquante jours pour développer notre application », illustre Victor Spanneut au CIDJ. Le projet de 6nergie.com a, lui, en revanche, mobilisé quatre personnes à plein temps pendant douze mois, car il est assez complexe, et celui de Richelieu Finance a été réalisé en trois mois.

Grâce à l’approche par composants, « il ne nous a fallu qu’un week-end pour développer le prototype de notre simulateur de gestion de portefeuilles de fonds en interne », complète Hervé Schmitt. Ajax influe également peu sur la charge de maintenance de l’application. « Il s’agit d’une mise en oeuvre Java/JSP, somme toute assez classique. Ajax ne représente que quelques bibliothèques JavaScript supplémentaires dans ce déploiement », précise Victor Spanneut.

Les écueils : les navigateurs ne respectent pas les standards

Ce sont surtout les différentes versions des navigateurs cibles et l’absence de débogueur JavaScript de qualité qui posent aujourd’hui des problèmes. « Aucun navigateur ne gère exactement de la même façon l’utilisation conjointe de JavaScript, CSS, HTML, XML, etc. », constate Alain Lefebvre de 6nergie.com. « Par exemple, Internet Explorer 5.5 et 6.0 de Microsoft ne se comportent pas de la même façon face à un code identique », illustre-t-il.

Même si les frameworks clients (Prototype, etc.) prennent en partie en charge ces incompatibilités, la mise au point de l’interface utilisateur est parfois pénible et fastidieuse. C’est pourquoi, « nous développons d’abord pour notre plate-forme cible principale qui est Internet Explorer. Puis, nous adaptons ensuite notre code pour le rendre compatible avec les autres navigateurs », explique Hervé Schmitt de Richelieu Finance. « Nous proposons aussi des écrans HTML alternatifs lorsque cela se révèle nécessaire », ajoute-t-il. L’absence de débogueur et d’outil de développement graphique rend également le travail de mise au point de l’interface plus complexe.

Heureusement, de nombreux outils sont en préparation chez les principaux éditeurs. Dans le monde Java, Sun vient, par exemple, de présenter le plug-in jMaki qui complète son atelier de développement Net-Beans, et JBoss proposera bientôt le framework Seam qui facilite l’intégration des modèles de pages JavaServer Faces (JSF) avec les Enterprise Java Beans (EJB). Tibco propose également un atelier de développement Ajax relativement abouti.

En attendant leur sortie, « l’absence d’outils Wysiwyg n’est pas un réel handicap, car les bons développeurs Web ne recourent que rarement à ce type d’atelier RAD », estime Frédéric Bon, fondateur de Clever Age, le prestataire qui conseille Richelieu Finance. « De plus, le look’n’feel des composants graphiques fournis avec les frameworks Ajax peut être adapté à l’aide de simple feuilles de styles », précise-t-il.

En revanche, comme les applications Ajax reposent sur le motif de conception Single Page Interface (SPI), certaines adaptations ergonomiques doivent impérativement être réalisées. « L’absence de bouton précédent/suivant oblige, par exemple, à mieux concevoir son interface en s’inspirant des applications client-serveur traditionnelles », note Hervé Schmitt. « Le fait que l’utilisateur ne puisse pas ajouter une page à ses favoris demande également un effort supplémentaire de conception », complète Victor Spanneut.

Les gains : une ergonomie qui motive les utilisateurs

Au final, ces contraintes sont largement compensées par l’accueil des utilisateurs, généralement unanimes sur l’apport de ces interfaces en termes de confort d’utilisation et de productivité. « Les médecins étaient assez réticents à utiliser l’émulation en mode terminal de l’application VMS permettant d’accéder aux dossiers des patients », illustre François Lion à l’IGR. « Quand nous leur avons proposé l’interface Ajax, ils ont très vite adhéré au projet. Au point que nous avons dû étendre la portée de notre application à des utilisateurs que nous n’avions pas prévus au départ, les infirmières anesthésistes, par exemple », se réjouit-il.

Du point de vue du service informatique, le surcoût de développement lié à la nouveauté d’Ajax est largement compensé par l’absence des coûts de déploiement liés aux clients lourds et/ou riches. Plus le nombre d’utilisateurs est important et plus l’intérêt d’Ajax pour remplacer certains clients lourds devient donc intéressant. De plus, « comme Ajax ne transmet que les données utiles à l’utilisateur, cette architecture diminue aussi la bande passante exploitée par l’application ainsi que le volume de données à traiter sur le serveur », complète Victor Spanneut.

Lire l’article en ligne