Bonjour,
 
Je vois souvent parler de respect de SLA mais je n'ai aucune idée de ce que c'est...
Ya bien ça :
http://fr.wikipedia.org/wiki/Service_Level_Agreement
 
Mais quand on est fait parti de l'équipe informatique d'une entreprise en interne, comment ça se passe ??
 
Merci

En interne aussi, tu peux mettre en place au niveau des interventions des procédures de saisine, des délais de prises en charge/résolution, des niveaux de support, etc.

Exact, en interne lors de ma précédente mission, une équipe SI interne qui faisait de l'exploitation avait mis en place une "Offre de Service" à la destination des Maîtrises d'Oeuvre, autrement dit des chefs de projets applicatifs.  
 
L'objectif était de pouvoir afficher à tous un engagement sur le niveau de service :
 
- % disponibilité applicative mensuelle
- % disponibilité point de vue utilisateur
- supervision
- sauvegardes
- maintenances
- nombre d'incidents max (hors fonctionnels)
 
Il s'agissait d'un SI industriel "critique" pour l'entreprise.  
 
Inutile de dire que les maîtrises d'oeuvre se comportaient en "client", même si c'était de l'interne.

ok merci pour toutes ces infos, mais ça sert à quoi ???  
Je me pose la question par rapport à un incident qui est ouvert sur un outil de helpdesk ? C'est quoi la différence entre un SLA et un incident normal ?

Un incident, c'est un incident.
Un SLA, c'est définir les engagements pour résoudre l'incident. En soi, ça ne sert à rien, sauf si les moyens sont mis en face des engagements. Au final, c'est surtout une question de prix et de responsabilité. En interne, ça sera de responsabilité.
 
Exemple: sur mon lien d'accés, le SLA prévoit une GTR 4h et une dispo de 99,9%. Lors de la coupure de 72h du lien, je me retourne contre l'opérateur, et demande des pénalités conformément au contrat (je demande 72xCA horaire, j'obtiens 30% de réduc sur le mois prochain).
 
Autre exemple: en interne, un chef de projet zélé met en place des sla pour les applis métiers (hahaha). Mon erp, en déplacement, plante et je ne peux pas saisir la commande du siècle. J'appelle mon boss, et Bébert, qui devait superviser l'erp au lieu de glander sur Meetic reçoit la fessée.

 
Ca sert dans les boites où on fait pas les trucs à l'arrache au ptit bonheur la chance où tu peux dire que tu as mis les moyens nécessaire pour définir un niveau de service.

Ok merci de m'avoir expliquer, j'ai compris.
Mon responsable informatique m'a posé la question si je savais ce que c'était car lui ne savait pas.... C'est bien les BAC+5 en informatique qui connaissent pas ça et qui sont passés dans un nombre de boite incalculable
Ca prouve aussi peut être que les SLA, il n'y a pas beaucoup de boites qui dejà savent ce que c'est et d'autre part utilisent le système.
En tout cas, j'me sens un peu plus intelligent maintenant
 
Merci Merci

Salut,
 
Je me permets d'apporter ma pierre à ton édifice et corriger, je pense, un peu ce qui a été écrit par les divers intervenants.  
 
Dans une DSI qui a mis en place des bonnes pratiques (CMMI, ITIL ou whatever), tu peux parler de SLA (Servicee Level Agreement) en français dans le texte accord de niveau de service. C'est un accord signé entre le service informatique et ses clients sur le niveau de service. C'est donc un document qui décrit les cibles de niveau de service et spécifie les responsabilités de DSI et du client. Il existe plusieurs type de SLA :  
 
- Centré client : Un SLA pour l'ensemble des services consommés par ce client.
- Centré service : Un SLA concernant un service et peu importe le client.
- Multi centré : mixte + organisation.
 
Généralement, tu définis un SLR qui vient avec ton SLA. Service Level Requirement. Ce sont les exigences et les besoins sur les services consommés
 
Ensuite la DSI, afin de pouvoir garantir les SLA qu'elle a signé avec les métiers (clients des SI), va devoir faire signé des accords opérationnels entre ses propres parties de son organisation. Ce sont les OLA (operationnal Level Agreement). On y définit les biens, les services et les responsabilités de chacune des parties. Par ex. le centre de service signera un accord avec l'équipe réseau ou avec les équipes infra stockage.
 
Enfin, lorsqu'un service est rendu par un prestataire externe tu ne parleras plus de SLA ou OLA mais de UC (Underpinning Contract). Par exemple, le mainteneur de tes serveurs. L'UC définira ses responsabilités, les tiennes, les moyens qu'il fournira, ...
 
Dans le cadre ITIL, tout ceci est implanté via le processus de gestion des niveaux de services qui se situe dans me cycle conception des services.
 
Souvent dans les outils de helpdesk (ex. HP Service Center, GS, ...), il y a des SLA lié aux incidents. Ces SLA_outils outils sont généralement issus des OLA elles mêmes issus des exigences qualité du service. Par ex. et sans rentrer dans le détail. Un incident se produit, sa sévérité implique un rétablissement du service optimal sous 24h. Les outils de helpdesk définissent plusieurs métriques sur ce SLA_outils : SLA 50, SLA 75, SLA 100, hors délai ... qui aideront à calibrer les réponses fassent à ce genre d’événement.
 
Contrairement a ce qui a été noté plus haut, un SLA n'est pas qu'un engagement mais c'est aussi les moyens et les responsabilités.

Ouch, et y a des boites ou c'est implémenté en vrai pour de vrai ?
Je trouve que le système à l'air super carré, super centré, super clean, bref pro.
Le truc que je me pose, c'est est-ce que ça fait beaucoup de documents "fonctionnels" au total ?

Quand j'ai quitté Renault avec Atos ils venaient d'obtenir la certif. CMMI level 3 où tout est procéduré mais pas encore optimisé.

Quand tu fais le gouvernance de SI, tu n'as plus le choix. Tu es obligé de passer par des processus comme tu dis super carré, super centré, super clean. Les DSI y viennent très doucement mais elles y viennent.

En fait, pour justifier une dépense un DSI à besoin de donner de la valeur au service au près des direction. Le processus c'est une façon d'y arriver.

C'est comme cela que fonctionne l'industrie avec 30 ans d'avances sur les DSI.

Après, c'est difficile de fonctionner comme cela dans une TPE/PME car ce modèle n'est pas forcement adapter mais tu peux t'en inspirer. Mais après c'est du stratégique et c'est tout l'art des ces personnes tout en haut des organigrammes

Sinon effectivement cela fait une très grosse liasse documentaire dont tu dois gérer le cycle de vie. La GED a de beaux jours devant elle.

Pour l’anecdote, il fût un temps chez Smith Group, où j'expédiais des cartons avec plus de poids en liasse documentaire qu'en "output" de production.

Et oui, ce genre d'organisation est en place dans certaines entreprises, très souvent dans l'industrie, c'est un moyen de garantir que par ex. des avions se crashent pas tous les jours.

C'est lourd à mettre en place, ce n'est pas forcement toujours souple mais c'est capitale pour des entreprises d'une certaine taille.