Le Service Level Agreement dans les contrats informatiques

Publié le 11/11/2003 par Thibault Verbiest

Le Service Level Agreement ou SLA est une expression anglaise qui peut être traduite par « Accord de Niveau de Service » ou par « Engagement de Service », ou encore plus simplement « Convention de Service ». Le SLA est le contrat ou la partie du contrat spécifiant l’ensemble des niveaux de services à fournir par le prestataire informatique au(x)…

Le Service Level Agreement ou SLA est une expression anglaise qui peut être traduite par « Accord de Niveau de Service » ou par « Engagement de Service », ou encore plus simplement « Convention de Service ».

Le SLA est le contrat ou la partie du contrat spécifiant l’ensemble des niveaux de services à fournir par le prestataire informatique au(x) client(s). Il s’agit d’un engagement formel et contraignant, établi entre un prestataire et son (ses) client(s).

Le SLA est utilisé dans la plupart des contrats d’outsourcing et permet de :

• identifier et définir les besoins du client ;

• fournir un cadre général de compréhension des deux parties ;

• simplifier les problèmes complexes ;

• encourager les dialogues en cas de conflit ;

• éliminer les attentes irréalistes ;

• être utilisé comme un instrument de marketing par les services commerciaux et techniques des ASP;

• transformer une obligation de moyen en obligation de résultat.

L’ASP (Application Service Provider), traduit en français par « Fournisseur d’Applications Hébergées » (FAH), est une société qui fournit, sur abonnement, un accès à des applications ainsi que de l’infrastructure et la maintenance nécessaires.

Contrairement à l’outsourcing classique, l’ASP ne reprend pas l’infrastructure IT existante du client pour gérer ses ressources informatiques, mais fournit au client un accès à sa propre infrastructure IT.

Dans la mesure où l’ASP doit combiner des compétences dans le service, la technologie des réseaux et leur gestion mais aussi dans l’administration, l’intégration, la gestion et le support des applications, il sera amené à s’octroyer plusieurs partenaires.

Toutefois, sur la base du contrat ainsi que du SLA, l’ASP restera le seul responsable, à l’égard du client, de la livraison du service. Il maintiendra donc de nombreuses relations avec des sociétés telles que des fournisseurs de système d’exploitation, des fournisseurs de hardware, des fournisseurs d’équipement de réseaux, des fournisseurs de réseaux, d’applications, et d’autres fournisseurs d’infrastructure, etc…

Il s’agira notamment des prestataires suivants :

• ISV (Independent Software Vendor – vendeur indépendant de logiciels),

• AIP (Application Infrastructure Provider – fournisseur d’infrastructure d’applications),

• NSP (Network Service Provider – fournisseur de services réseaux),

• VAR (Value Added Reseller – revendeur à valeur ajoutée),

• SI (Systems Integrator – intégrateur de systèmes), …

La rédaction du SLA

Le SLA fait partie intégrante du contrat entre l’ASP et son client. Il fait souvent l’objet d’une annexe à ce contrat.

L’office Mondial de la Propriété Intellectuelle (OMPI) et l’ASPIC ont mis au point des Best Practices, afin de prévenir certains litiges fréquents entre l’ASP et son client. Celles-ci portent sur l’identification de l’infrastructure, la connectivité, la sécurité, l’application, l’implémentation et la maintenance des services.

Le SLA en lui-même doit prévoir un maximum de situations pour concentrer les obligations et le niveau de service à fournir.

On y retrouvera le temps imparti dans lequel les services seront fournis, la description et l’étendue des services qui seront fournis, ceux qui ne devront pas être fournis, un calendrier des implémentations, les utilisateurs du service et leur localisation.

Le cœur du SLA réside dans les clauses fixant le niveau des services attendus, à savoir le taux de disponibilité et de fiabilité du service (par exemple : les heures et les jours pendant lesquels le service sera disponible).

Sera également précisé le temps de réponse qui devra être octroyé au fournisseur en cas de plainte pour dysfonctionnement (par exemple, prévoir que 95% des problèmes seront résolus après une heure à compter de la plainte).

Les conditions de payement devront être également très précises ainsi que les procédures qui en découlent. Il faudra de même prévoir les modalités des licences de logiciels, les titulaires des droits y attenant, et leurs conditions financières, la propriété des données, leur protection, leur confidentialité ainsi que leur récupération (dans quelles circonstances, suivant quelle procédure et conditions).

Un autre point crucial concerne la détermination des obligations du client, comme l’ « updating » de son infrastructure pour assurer la compatibilité avec les services de l’ASP, la formation de son personnel, la fourniture d’informations correctes à ses utilisateurs…

S’ensuit la phase de « reporting ». Le SLA doit examiner concrètement comment les services seront contrôlés, avec quels outils, suivant quelle procédure d’audit, par qui, à quelle fréquence etc., pour pouvoir éventuellement engager ensuite la procédure de plainte qui sera très précisément décrite (la personne à contacter, la manière de formuler les plaintes, les procédures d’urgence, les temps maximum dans lesquels l’ASP devra réagir etc.). Des outils de support à toute ces procédures doivent également être pointés, leur niveau et nature (helpdesk, combien d’opérateurs y sont disponibles, de quelle heure à quelle heure, quel jour, qui sont les personnes payées pour répondre à toute question, qui est responsable pour le « service clientèle » au sein de l’ASP, …).

Par ailleurs, il sera fait expressément mention des crédits de service, compensations financières, pénalités ou autres conséquences de la fourniture défectueuse des services.

Les clauses de sécurité revêtent également une importance capitale au sein d’un SLA. Comment prévoir que la sécurité d’accès au système est valablement assurée ? Il sera donc nécessaire de prévoir une procédure de recouvrement de données et des copies de sauvegarde.

L’étendue de la responsabilité, de l’indemnisation de l’ASP vis-à-vis des tiers, et des autres intervenants dans le projet (ISV, VAR, …) doit être définie. En particulier, seront visées les limitations de sa responsabilité et la prévision des cas de force majeure applicables.

Enfin, des modes de résiliation précis devront être stipulés, ainsi que d’éventuels modes de résolution des litiges (tels que prévus par les recommandations de l’ASPIC par exemple).

Pourquoi un SLA peut-il échouer ?

La cause principale de litiges réside dans le processus de négociation. En effet, dans son appel d’offres, le client définira ses besoins et ses objectifs. Le fournisseur de services IT, quant à lui, devra délimiter son périmètre de services, et de maintenance éventuelle, qu’il pourra fournir au client. Ce processus de rapprochement n’est pas aisé, et devra parfois nécessiter l’intervention de tiers.

Le Service Level Management, n’est pas toujours bien mis en place. Vu la complexité du secteur de l’IT et du marché de l’ASP, un contrôle est très difficile mais s’avère, pour la même raison, essentiel. Le client se doit donc de mettre en place un système spécialement conçu (logiciel par exemple) pour effectuer le suivi des niveaux de service se trouvant dans le SLA , ainsi que le contrôle des procédures de rapport, de modifications des services ou de la gestion des conflits.

Les spécifications sont souvent lacunaires : soit qu’elles ne sont pas claires, soit qu’elles sont incomplètes.

Le manque de clarté se retrouve en effet souvent dans la délimitation du paramètre « disponibilité ». La disponibilité d’un réseau, par exemple, est souvent spécifiée par une figure de pourcentage de disponibilité. Cependant, on oublie souvent de spécifier l’effectivité d’un service au sein du plan commercial du client. Si on stipule une disponibilité de 98%, comment la mesurer, à quoi correspondent-elle et quels sont les 2% restants ?

Quant aux services en tant que tels, leur description est souvent incomplète. Par exemple, des clauses à propos de la sécurité et des dégâts qui peuvent être causés doivent être définis de manière exhaustive. Trop souvent, ces derniers ne sont pas bien classifiés ou quantifiés, ce qui entraîne des confusions et incompréhensions à propos des responsabilités de chacun, et donc parfois … de longues procédures judiciaires.

Par ailleurs, la plupart des SLA se concentrent trop sur les efforts et moyens déployés par un prestataire de service dans le cadre de tel ou tel problème, en oubliant qu’il y a un résultat à atteindre. Au lieu de prévoir « le service X fournira à votre société le résultat Y », l’on prévoit «  dans le cas où le système se bloque, le prestataire X apportera son service à concurrence du temps Y ».

Le prix est souvent mal défini. Si l’on rentre dans une logique de forfait, il est alors très difficile pour le client de déterminer un rapport prix/exécution.

Enfin, au vu de tous les éléments précités, le SLA sera souvent considéré et rédigé comme un document hautement technique, dont la compréhension est réservée à des initiés…

Les défis du SLA sont donc de dépasser ce cadre technique de la fourniture d’un service pour parvenir à une compréhension des besoins de chacun…