Performance des applications SaaS, complexité de la mesure
	Par William RANG, Directeur R&D
	Le modèle SaaS (Software as a Service) est un modèle révolutionnaire dans l’industrie logicielle. Outre la sécurisation de ces applications, critiques pour l’entreprise, la qualité perçue est un des facteurs clés du succès du modèle. Comment mettre en place des outils de pilotage de la performance technique de ces applications qui, de plus, ne sont plus hébergées dans l’entreprise ?

A la différence du modèle ASP (Application Service Provider), le SaaS ouvre la voie à la personnalisation de l’application et à l’intégration avec des composants tiers. Outre la sécurisation de telles applications, critiques pour l’entreprise, la qualité perçue est un des facteurs clés du succès du modèle.

Ces applications, souvent accessibles avec un navigateur en mode Web, font une utilisation massive des technologies interactives telle que l’AJAX (Asynchronous Javascript and Xml) pour reproduire un environnement auquel l’utilisateur s'est habitué avec un client lourd.

A titre d’exemple, nous pouvons citer les applications de CRM (Oracle : Siebel CRM On Demand, SAP : SAP CRM 2007, Selligent : SelligentX@), les applications d’ERP (Cegid : Cegid Business On Demand) ou de business intelligence (Cognos : Cognos Now !, Hyperion : Hyperion 9I).

Comment mettre en place des outils de pilotage de la performance technique de ces applications qui, de plus, ne sont plus hébergées dans l’entreprise ? D’où vient la complexité de la mise en œuvre d’outils de monitoring/supervision ?

Nous avons déjà évoqué les faiblesses des outils de mesure passive (programmes espions installés sur les postes utilisateurs, analyseur de trafic réseau…) pour donner une vision cohérente de la QoE (qualité d’expérience) de ces applications.

Les outils de mesures actifs fonctionnant par injection de flux (requêtes http) trouvent aussi leurs limites. Quelle en est la raison ?

Tout d’abord, l’interactivité amenée par l’utilisation de l’AJAX rend extrêmement difficile la construction d’un scénario de test basé uniquement sur une succession de requêtes (méthode d’injection de flux). Les applications s’appuient bien souvent sur des centaines de fonctions javascript stockées dans un ensemble de bibliothèques, qui vont générer dynamiquement des URL très complexes à reformer. De plus la reconstruction dynamique de la structure de la page, ce que l’on appelle le DOM (Document Object Model) rend la tâche encore plus difficile.

Une des solutions consiste à se placer au niveau de « l’utilisateur » et de reproduire des actions élémentaires, telles que les clics de souris, les frappes de clavier, les déplacements de souris… Souvent, l’appel d’une fonction déclenchant une navigation va être porté sur un objet de la page (par exemple une image), activé uniquement lorsque la souris est positionnée dessus (roll-over). Le scénario, s’il veut pouvoir reproduire les actions d’un utilisateur virtuel, doit prendre en compte ces spécificités. Il en va de même par exemple pour les menus contextuels qui apparaissent au passage de la souris.

Le diagnostic en cas de problème ou de bug devient encore plus compliqué. En effet, l’environnement d’utilisation de l’application est géré localement (sur le poste de l’utilisateur), avec des morceaux de code générés dynamiquement. Les outils de monitoring doivent alors nécessairement fournir ces informations si l’on veut comprendre et analyser les problèmes.