Pour mettre en place un outil de mesure des performances

Sachez que si cette démarche vous intéresse, il vous faudra effectuer un travail préliminaire afin d'implémenter avec succès ce type de produits.

Que vous soyez MOA ou MOE, il vous faudra constituer un cahier des charges qui balise le spectre des attentes et des contraintes techniques.

Vous devrez notamment étudier les transactions, organisées éventuellement en scénarios, qui devront être surveillées. Vous pouvez les choisir en fonction de leur criticité, leur fréquence d'utilisation ou encore pour faire écho à des remontées du Help Desk, signalant des incidents récurrents sur certaines.

Pour chacune d'elles, il faudra décrire le comportement utilisateur que le robot devra simuler et indiquer avec précision les points de mesure (affichage d'une information, d'une page, ou indication de mise à jour). Le dernier élément à renseigner concerne la plage horaire de fonctionnement du robot ainsi que la fréquence de rejeu du scénario utilisateur.

A côté de cette définition des transactions, il vous faudra également effectuer un travail sur les types d'alertes que vous souhaitez mettre en œuvre, avec pour chacune la détermination :

• De l'élément surveillé (transaction, scénario, localisation géographique)
• Du critère de déclenchement (temps de réponse, disponibilité, incohérence des informations affichées ...)
• Des personnes à prévenir
• Du degré de gravité (pour orientation des opérations curatives)

On pourra faire figurer dans ce cahier des charges, des informations relatives aux contrats de service qui lient ou lieraient la direction informatique ou services utilisateurs. Les besoins sont ici, à exprimer en termes de temps de réponse acceptables pour chaque transaction et de disponibilité des applications. L'outil permettant, ensuite au fil des relevés de mesure de comparer le réalisé avec le " budgété " (contrat de service).

En plus de l'expression fonctionnelle des besoins, vous devrez tenir compte et dresser un inventaire le plus exhaustif possible :

• Des architectures applicatives
• Des middlewares (surtout si votre choix s'oriente vers un outil fonctionnant en mode protocolaire)
• Des ERP (de nombreux patchs existent chez les éditeurs pour assurer un fonctionnement correct)

Cet exercice vous permettra de choisir l'outil qui répond le mieux à vos besoins et vous vous serez assuré qu'il puisse fonctionner dans votre environnement technique.

Enfin, quel que soit l'initiateur ou le promoteur du projet (MOA, MOE), il faut garder à l'esprit qu'une entité ne peut le porter efficacement sans le concours des autres. En effet, les utilisateurs, qui ne verraient dans ces produits que l'opportunité de démontrer, preuves à l'appui, la faiblesse des performances applicatives, se trompent. Ils se privent du volet " améliorations "  que seules peuvent porter les équipes de développement et d'exploitation. A contrario, une telle démarche engagée unilatéralement par les équipes techniques, n'est pas plus pertinente. Le risque résidant dans le choix de transactions pas forcément représentatif de la criticité et de la fréquence d'utilisation. Il s'agit alors d'une nouvelle brique dans le dispositif technique de supervision, qui pour intéressante est éloignée de l'esprit de cette solution qui est basée sur l'objectivation du ressenti utilisateur.