Contrairement à une croyance largement répandue les problèmes de performance sont beaucoup plus attribuables à des anomalies dans l’analyse, le design et la programmation des applications qu’à des insuffisances et/ou des dysfonctionnements au niveau des infrastructures matérielles [12] qui permettent de les mettre en réseau de les héberger et de les exécuter. Paradoxalement, les entreprises ont tendance à privilégier les solutions d’optimisation matérielles [13] dès qu’elles sont confrontées à des problèmes de performance. Un rapport du Gartner Group [14] confirme, à ce sujet, qu’elles font appel auxdites solutions pour améliorer les performances de 75% des applications J2EE nouvellement déployées. Paradoxalement:

* 40% des problèmes de performance sont dus à des erreurs commises par les opérateurs des applications (erreurs d’origine humaine).
* Seulement 20% des problèmes de performance sont dus à la défaillance du matériel et/ou l’inéquation de son environnement [15].
* Par contre 40% des problèmes de performance sont imputables à des anomalies persistantes dans le design et le code des applications.

Si les deux premières causes préalablement citées découlent respectivement d’une formation insuffisante du personnel et d’un mauvais dimensionnement des infrastructures matérielles, la troisième cause trouve plutôt son origine dans la non intégration du management des performances à l’ensemble des phases du cycle de développement. En effet comme en témoignent plusieurs rapports sur la toile, les analystes, les architectes et les programmeurs des applications de commerce électronique ne tiennent pas toujours compte des benchmarks de performance dans les phases d’analyse, de design et de codage. Ils attendent que le code soit entièrement écrit pour tester sa capacité à performer dans un environnement où les contraintes d’utilisation [16] sont équivalentes à celles de l’environnement réel de production.

Le report du management des performances à la fin du cycle de développement amène les évaluateurs à constater d’importants dépassements par rapport aux échéanciers et aux budgets prévisionnels surtout lorsque la méthodologie de développement utilisée permet peu ou pas d’itérations entre les phases de test, d’analyse, de design et de codage.

A en croire une présentation de la Borland Software Corporation [17], les ajustements apportés aux livrables desdites phases entraîneraient un retrait de 50% des applications déjà mises en service et des dépassements budgétaires évalués à 30% du coût total des projets [18]. L’importance de ces dépassements justifie la nécessité de concevoir les applications de commerce électronique dans une perspective d’optimisation, et ce, dès les premières phases du cycle de développement.

Figure 1: Dépassements budgétaires dus au report du management des performances à la fin du cycle de développement [19]

Notes de bas de page

[12] Indisponibilité du réseau, serveur avec une mémoire ou un processeur sous- dimensionnés par rapport à la charge de travail, panne du serveur, sinistres dus à des aléas climatiques…
[13] Cela n’est pas sans liens avec la baisse continue des prix du matériel informatique.
[14] Teresa Lanowitz, Tearing Down the Wall, Gartner, 2002
[15] Température excessive, rupture du courant électrique…
[16] Utilisation intensive des données et des traitements, accès concurrentiels…
[17] Jon Ha Building Quality into developement, Borland softwares.
[18] Ces dépassements sont particulièrement importants dans les méthodologies dites séquentielles parce qu’elles contiennent peu ou pas d’itérations.
[19] Source : ACCELERATE YOUR PERFORMANCE, Borland softwares, http://www.borland.com/optimizeit/pdf/opt6_datasheet.pdf