Du Service Level Agreement au Business Level Agreement

Les engagements de services, souvent très techniques, ne reflètent pas toujours la réalité de la performance d’une application, telle qu’elle est perçue par les utilisateurs et les clients. Intégrer une composante métier et une mesure de bout en bout permet de mieux appréhender la réalité de l’expérience utilisateur.

Les engagements de services (SLA : Service Level Agreements) sont aujourd’hui largement utilisés par les DSI dans le cadre de l’évaluation de la qualité du système d’information, vers les clients internes, ou avec les fournisseurs, pour vérifier la qualité des prestations délivrées. Les engagements de services présentent plusieurs atouts : davantage de formalisme, de rigueur, donc de qualité, dans le service rendu, la possibilité d’identifier les leviers de réduction de coûts, d’optimiser les coûts unitaires, et l’élaboration plus aisée d’une vision à long terme.

Cela permet notamment de définir des standards, des objectifs réalistes de performances, de mettre en place des alertes et de simuler des changements dans le système d’information.

Mais, très souvent, les SLA ne sont plus suffisants, au moins pour quatre raisons :

  • Les SLA souffrent de quelques limitations, par exemple lorsque les données collectées sont trop nombreuses, les processus de reporting trop lourds, les indicateurs mal définis, trop simples ou au contraire trop complexes à analyser, avec, dans certains cas, la tentation de développer des « usines à gaz » qui, à terme, n’intéressent plus personne…
  • La tendance à recourir à des services en mode SaaS, y compris pour des applications métier très stratégiques, entraîne une multiplication des relations avec des prestataires qui doivent s’engager sur une qualité de service, qu’ils revendiquent, pour la plupart.
  • Dans les entreprises, les clients internes sont de plus en plus sensibles à tout ce qui peut altérer la qualité des services rendus par la DSI. Ainsi, une requête applicative peut être lente, alors que tous les indicateurs techniques sont au vert.
  • De plus en plus d’applications sont utilisées par les clients externes, par exemple pour le e-commerce, et il faut pouvoir maîtriser la qualité de service de manière beaucoup plus large qu’avec une batterie d’indicateurs techniques.

Éliminer les zones grises

« Un tableau de bord avec des SLA pertinents ne signifie pas que le service est optimum pour le client », explique Xavier Precigout, directeur de la practice infrastructures chez Wipro. Face aux métiers, il est préférable de mettre en œuvre des BLA (Business Level Agreements), beaucoup plus représentatifs de la qualité réelle des services délivrés par la DSI et de la perception des utilisateurs. « C’est la qualité d’un processus métier qu’il faut mesurer de bout en bout », conseille Xavier Precigout. L’approche consiste à identifier les processus et sous-processus métier clés et à cartographier les applications, ainsi que les infrastructures et les couches de middleware. « Cela permet d’éliminer les zones grises, même s’il n’est pas toujours aisé d’aboutir à un consensus entre les équipes de la DSI et les métiers », précise Xavier Precigout. En particulier parce que les niveaux de maturité des métiers et de la DSI ne sont pas systématiquement alignés.

 

Principales caractéristiques des SLA et des BLA
SLA (Service Level Agreements) BLA (Business Level Agreements)
Périmètre Le système d’information L’entreprise
Champ d’analyse Les infrastructures Les processus et les applications
Objectif Analyser Optimiser
Focus Sur les volumes d’informations Sur la pertinence des informations
Destinataire La DSI, la production Les métiers
Définition des indicateurs Entre la DSI et le fournisseur Entre la DSI et les métiers
Indicateurs Techniques Métiers
Principe de mesure En silos De bout en bout
Exemple d’indicateurs Disponibilité des serveurs Temps de réponse d’une commande client
Tableau de bord Exhaustif Synthétique/graphique
Difficulté de mise en œuvre Faible Élevée
Source : Digitalonomics.