| |
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 paiement 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).
|
