SLA support : définir des engagements tenables

Un SLA support mal rédigé transforme une promesse commerciale en engagement intenable dès le premier incident. Voici comment définir des engagements précis, mesurables et réellement tenables.

Ce qu’est un SLA et ce qu’il n’est pas

Un Service Level Agreement, ou accord de niveau de service, est un document contractuel qui formalise des engagements chiffrés et vérifiables sur la qualité d’un service de support. Il répond à une question simple : que s’engage-t-on concrètement à faire, dans quel délai, selon quelles conditions, et avec quelles conséquences si l’on n’y parvient pas ? Le Code civil, en son article 1103, pose que les contrats légalement formés tiennent lieu de loi à ceux qui les ont faits. Cette force obligatoire confère au SLA une valeur juridique réelle, à condition qu’il soit suffisamment précis pour être exécutable. Un SLA vague est, par construction, un SLA inapplicable.

La première confusion à dissiper est celle entre le SLA et l’obligation de moyens. Un prestataire soumis à une obligation de moyens s’engage à déployer des efforts raisonnables pour atteindre un résultat, sans garantir ce résultat. Un SLA est d’une autre nature : il s’apparente à une obligation de résultat ciblée, sur laquelle la défaillance du prestataire est objectivement constatable sans que le client ait à prouver une faute. La deuxième confusion concerne la garantie légale ou commerciale, qui porte sur la conformité d’un produit et non sur la réactivité d’une équipe humaine. La troisième confusion, la plus fréquente dans les contrats de petites structures, consiste à prendre une promesse verbale de « répondre vite » pour un engagement contractuel opposable. Ces deux notions n’ont ni le même régime, ni les mêmes effets juridiques.

Le tableau suivant distingue ces quatre notions pour éviter tout amalgame dans la rédaction contractuelle.

L’article 1104 du Code civil impose que les conventions soient négociées, formées et exécutées de bonne foi. Un prestataire qui propose un SLA qu’il sait inatteignable au regard de ses ressources réelles viole cette exigence dès la formation du contrat. Ce point est fondamental : un SLA tenable n’est pas avant tout un argument commercial, c’est une analyse honnête de ce que l’organisation est réellement capable de produire, de façon répétée et vérifiable, sur toute la durée du contrat.

Les trois familles d’engagement

La confusion entre les trois délais fondamentaux d’un SLA est l’erreur la plus coûteuse en pratique. Elle génère des litiges, des impayés et des ruptures de contrat parce que le prestataire et le client ne parlent pas du même moment. Chacun de ces trois délais a un point de départ précis et différent des deux autres. Les confondre, c’est rendre impossible toute mesure sérieuse de la performance.

Le délai de prise en compte

Le délai de prise en compte est le temps qui s’écoule entre la réception de la demande et l’accusé de réception formel du prestataire. Il ne signifie pas qu’un technicien a commencé à travailler sur le problème. Il signifie que la demande a été enregistrée, qu’elle a reçu un identifiant unique, une priorité et une affectation. Son point de départ est la date et l’heure d’entrée de la demande dans le système du prestataire.

Si le client envoie un courriel un dimanche à 23 heures et que le prestataire ne travaille qu’en heures ouvrées, le point de départ du délai de prise en compte peut légitimement être fixé à l’ouverture des bureaux le lundi matin, à condition que cette règle soit explicitement écrite dans le SLA. Ce point, souvent omis, est une source classique de tension au démarrage. Le client pense que le délai a commencé à courir au moment de l’envoi de son message. Le prestataire considère que le délai court à partir de l’ouverture de ses équipes. Sans clause écrite, aucun des deux n’a tort, et le désaccord est structurel.

Ce délai est le plus facile à tenir, mais aussi celui dont les clients surestiment souvent la portée. Un délai de prise en compte de trente minutes ne signifie pas que le problème sera résolu en trente minutes. Il signifie que quelqu’un aura lu, qualifié et accusé réception de la demande en trente minutes. La confusion entre prise en compte et rétablissement est une source quasi systématique de déception chez les clients non avertis.

Le délai d’intervention

Le délai d’intervention est le temps qui s’écoule entre la prise en compte de la demande et le début effectif du traitement technique. Son point de départ est donc la fin du délai de prise en compte, et non l’ouverture du ticket. Un technicien doit avoir commencé à analyser le problème, à le reproduire sur un environnement de test, ou à accéder à l’environnement concerné. Ce n’est pas encore la résolution, mais c’est la preuve tangible qu’une ressource humaine est mobilisée sur le sujet et que le traitement a effectivement démarré.

L’erreur classique est de promettre un délai d’intervention identique pour tous les incidents, quelle que soit leur complexité ou leur priorité. Un incident qui bloque l’ensemble des utilisateurs d’une plateforme ne peut pas recevoir le même délai d’intervention qu’une demande de correction d’un libellé ambigu dans un menu secondaire. Différencier les délais par niveau de criticité n’est pas un luxe contractuel : c’est une nécessité opérationnelle pour que les engagements restent tenables et pour que l’équipe de support puisse prioriser son travail de façon cohérente.

Le délai de rétablissement

Le délai de rétablissement est le temps maximal accordé au prestataire pour remettre le service dans un état fonctionnel acceptable. Son point de départ peut être défini de deux façons : soit à partir de l’ouverture du ticket, soit à partir du début de l’intervention. Les deux approches sont défendables, mais elles donnent des résultats très différents en cas de litige et de calcul de pénalités. Si le SLA ne précise pas lequel des deux points de départ est retenu, un juge pourra interpréter le contrat selon l’interprétation la plus favorable au client, créancier de l’obligation.

Le délai de rétablissement est le plus difficile à tenir parce qu’il dépend de facteurs que le prestataire ne maîtrise pas toujours : complexité du dysfonctionnement, disponibilité d’un environnement de test conforme à la production, dépendance vis-à-vis d’un fournisseur tiers ou nécessité d’une intervention physique sur site. C’est précisément pour cette raison que les exclusions du périmètre du SLA sont fondamentales. Elles ne sont pas des clauses d’esquive, elles sont la condition pour que les délais de rétablissement restent honnêtes et tenables.

Il faut également définir ce que l’on entend par « rétablissement ». S’agit-il d’un retour à l’état fonctionnel complet d’avant l’incident, ou d’une solution de contournement acceptable permettant de reprendre l’activité ? Cette distinction change radicalement la nature de l’engagement et le délai réaliste pour y parvenir. La solution de contournement peut être acceptable pour interrompre le décompte du délai, à condition que ce mécanisme soit écrit dans le SLA et que les parties s’accordent sur la définition de « solution de contournement acceptable ».

Les plages de service

Une plage de service définit les périodes durant lesquelles les engagements de délai sont actifs et opposables. C’est l’une des variables les plus déterminantes d’un SLA, et pourtant elle est souvent rédigée de façon beaucoup trop vague. On distingue généralement trois types de couverture.

Les heures ouvrées correspondent aux horaires habituels de bureau, typiquement de 9h à 18h du lundi au vendredi, jours fériés légaux exclus. Les plages étendues prolongent cette couverture, par exemple de 8h à 20h en semaine avec une demi-journée le samedi matin. La couverture continue, dite 24 heures sur 24 et 7 jours sur 7, impose une organisation d’astreinte permanente qui génère des coûts opérationnels structurellement élevés et qui doit donc être facturée en conséquence.

Prenons un exemple concret posé comme hypothèse de rédaction contractuelle. Un SLA prévoit un délai de rétablissement de quatre heures pour un incident critique. Si la plage de service est en heures ouvrées et que l’incident survient un vendredi à 17h30, ces quatre heures ne commencent à courir que le lundi suivant à 9h. Le service peut donc rester indisponible tout le week-end sans que le prestataire soit en faute contractuellement. Si la plage de service est continue, ces mêmes quatre heures commencent à courir immédiatement, et le service doit être rétabli avant 21h30 le vendredi soir.

Ces deux situations recouvrent des niveaux de service radicalement différents, des coûts radicalement différents et des attentes client radicalement différentes. Un SLA qui mentionne « délai de rétablissement : 4 heures » sans préciser la plage de service applicable est un SLA incomplet, potentiellement conflictuel et certainement défavorable à l’une des deux parties selon l’interprétation retenue.

Il faut aussi préciser comment les délais se décomptent lorsqu’un ticket est ouvert en toute fin de plage horaire. Si le délai de prise en compte est de deux heures ouvrées et que la demande arrive à 17h50 pour une plage ouvrée se terminant à 18h, le délai continue-t-il à courir le lendemain matin à partir de 9h, avec dix minutes déjà consommées ? Ou repart-il de zéro le lendemain ? Ces précisions peuvent sembler fastidieuses à la rédaction, mais elles évitent des discussions interminables lors de l’instruction d’un litige ou du calcul d’une pénalité.

La plage de service doit figurer dans le corps du SLA, clairement identifiée, et non reléguée dans une annexe technique que personne ne consulte avant d’avoir un problème. Elle doit également préciser le traitement des jours fériés : s’agit-il des jours fériés légaux nationaux uniquement, ou inclut-on des jours de pont ou des périodes de fermeture estivale ? Chaque ambiguïté non résolue à la rédaction se transformera en désaccord au moment où elle sera confrontée à un incident réel.

Les niveaux de criticité

Un SLA sans niveaux de criticité traite de façon identique un dysfonctionnement qui empêche l’ensemble des utilisateurs de se connecter et une faute de frappe dans un libellé d’interface secondaire. C’est une erreur de conception qui rend le SLA soit trop contraignant, soit trop permissif, selon le type d’incident rencontré. La bonne pratique consiste à définir entre trois et quatre niveaux de criticité, caractérisés non par des qualificatifs vagues mais par leur effet concret et mesurable sur l’activité du client.

Le tableau suivant présente une grille à quatre niveaux posée comme hypothèse de rédaction contractuelle. Les délais indiqués sont des exemples et ne constituent en aucun cas des normes sectorielles ou des références de marché.

La qualification du niveau de criticité doit appartenir au prestataire lors du traitement de la demande, et non être laissée à la seule appréciation du client. Si chaque client peut qualifier unilatéralement sa demande comme critique, tous les tickets basculent en P1 et le niveau de criticité maximum perd toute signification opérationnelle. Le SLA doit préciser qui qualifie, selon quels critères objectifs et quelle est la procédure si le client conteste la qualification retenue par l’équipe de support.

Il est également utile de prévoir une procédure d’escalade automatique. Si un incident P2 n’est pas rétabli au bout d’une demi-journée ouvrée, il peut être automatiquement reclassifié en P1 avec les délais et les ressources correspondants. Cette escalade automatique permet de gérer les incidents qui s’aggravent avec le temps sans avoir à rouvrir une négociation contractuelle en urgence, au moment précis où les deux parties sont le plus sous pression.

Le taux de disponibilité

Le taux de disponibilité exprime le rapport entre le temps pendant lequel un service est accessible et le temps total de la période considérée. Il est exprimé en pourcentage sur une base mensuelle ou annuelle. Plus ce taux est élevé, plus la durée d’indisponibilité tolérable est courte, et plus les contraintes opérationnelles pour le tenir sont lourdes et coûteuses.

Le tableau suivant convertit quatre taux de disponibilité en durées d’interruption admissibles par mois et par an. Les calculs sont fondés sur une base de 730 heures par mois, obtenue en divisant 8 760 heures annuelles (365 jours de 24 heures) par 12. Ces chiffres sont posés comme résultats arithmétiques et ne constituent en aucun cas des normes sectorielles.

La lecture de ce tableau appelle plusieurs remarques essentielles. Chaque « neuf » supplémentaire dans le taux de disponibilité ne représente pas une amélioration linéaire du service : il représente une réduction d’un facteur dix du temps d’indisponibilité tolérée, et une augmentation correspondante des exigences infrastructurelles, humaines et organisationnelles. Passer de 99 % à 99,9 % divise par dix le temps d’arrêt toléré par mois, le faisant passer de plus de sept heures à moins de quarante-quatre minutes. Passer de 99,9 % à 99,99 % le divise à nouveau par dix, le ramenant à un peu plus de quatre minutes par mois.

Ces quatre minutes représentent le budget total d’indisponibilité mensuelle pour tenir un engagement à 99,99 %. Si une seule mise à jour de routine prend cinq minutes et demie sur un mois donné, l’engagement est déjà dépassé, avant même de comptabiliser la moindre panne imprévue. Une structure qui s’engage à 99,99 % de disponibilité sans astreinte nocturne permanente, sans redondance matérielle des composants critiques, sans bascule automatique et sans équipe dédiée disponible à tout instant signe un engagement intenable. Elle le signera peut-être pour emporter une signature commerciale, mais elle ne pourra pas le tenir dans la durée.

Un engagement à 99 % de disponibilité est structurellement beaucoup plus accessible, mais il autorise presque quatre jours complets d’indisponibilité cumulée par an. Selon la nature du service concerné, c’est parfaitement acceptable pour un outil de gestion interne dont l’usage est concentré sur les heures ouvrées, et totalement rédhibitoire pour une plateforme de traitement de commandes ou de paiements en temps réel. Le bon taux de disponibilité n’est pas le plus élevé possible : c’est celui qui correspond à l’usage réel du client et que le prestataire peut réellement garantir, en ayant mis en place les ressources pour ce faire.

Ce qui est exclu du calcul

Un SLA sans exclusions précises est un engagement ouvert sur des événements que le prestataire ne maîtrise pas. Les exclusions ne sont pas des clauses d’échappatoire destinées à vider le SLA de tout contenu : elles sont la condition nécessaire pour que les engagements retenus soient réellement tenables et pour que le prestataire puisse les assumer avec honnêteté. Mais pour être opposables, ces exclusions doivent être écrites, précises et bornées dans le temps et dans leur périmètre.

• La maintenance planifiée. Toute intervention programmée à l’avance sur l’infrastructure ou le service, notifiée au client dans un délai raisonnable précisé dans le SLA (par exemple quarante-huit heures avant), peut être exclue du calcul du taux de disponibilité. Le SLA doit préciser la durée maximale de maintenance planifiée autorisée par mois et les plages horaires pendant lesquelles elle peut avoir lieu, idéalement en dehors des heures d’activité principale du client.
• La force majeure au sens de l’article 1218 du Code civil. Cet article dispose qu’il y a force majeure en matière contractuelle lorsqu’un événement échappe au contrôle du débiteur, ne pouvait raisonnablement pas être prévu lors de la conclusion du contrat, et dont les effets ne peuvent être évités par des mesures appropriées. Une panne électrique nationale généralisée ou une cyberattaque massive et inédite peuvent constituer des cas de force majeure. Cette qualification doit être invoquée avec rigueur et ne peut pas couvrir les défaillances prévisibles d’un sous-traitant habituel dont le prestataire répond.
• Le fait d’un tiers non maîtrisé. Si l’indisponibilité est causée par la défaillance d’un opérateur réseau tiers, d’un prestataire d’hébergement externe ou d’un service tiers intégré sur lequel le prestataire n’exerce aucun contrôle, cette période peut être exclue. Mais l’exclusion doit nommer les catégories de tiers concernés avec suffisamment de précision, et ne peut pas couvrir les sous-traitants que le prestataire a lui-même sélectionnés et dont il est contractuellement responsable envers son client.
• La faute du client. Si l’indisponibilité résulte d’une mauvaise manipulation du client, d’une modification non autorisée de son environnement, d’un accès révoqué sans préavis ou d’une information erronée transmise à l’équipe support, cette période peut être exclue du calcul. Le SLA doit définir avec précision ce que l’on entend par « faute du client » pour éviter que cette exclusion ne soit invoquée de façon abusive pour couvrir des dysfonctionnements relevant en réalité du prestataire.
• Les services non maîtrisés. Un prestataire de support applicatif ne maîtrise pas l’infrastructure réseau du client, ni son matériel, ni les applications tierces installées sur ses postes de travail. Si une indisponibilité est causée par l’un de ces éléments extérieurs au périmètre contractuel, la période concernée peut être exclue, à condition que le périmètre de responsabilité du prestataire soit clairement délimité dans le contrat principal.

Ces exclusions doivent figurer dans le SLA lui-même, et non reléguées dans des conditions générales rédigées en corps huit que personne ne consulte avant un litige. Un tribunal aura des difficultés à les opposer au client si elles n’ont pas été portées à son attention de façon suffisamment apparente lors de la conclusion du contrat, dans l’esprit des protections instituées par l’article 1171 du Code civil relatif aux clauses créant un déséquilibre significatif dans les contrats d’adhésion.

Comment mesurer, qui mesure et à partir de quelle source

Un SLA sans méthode de mesure définie est un engagement sans arbitre. La question « qui mesure et comment ? » est aussi importante que la question « que s’engage-t-on à faire ? ». Dans la très grande majorité des litiges portant sur des SLA, le désaccord ne porte pas sur le délai contractuel lui-même mais sur la durée réelle de l’indisponibilité ou sur le moment précis à partir duquel le délai a commencé à courir. C’est une dispute sur les faits, pas sur le droit.

La première règle est de définir une source de référence unique pour toutes les mesures. Cela peut être le journal d’événements du système de tickets, les journaux du serveur de supervision ou un outil de monitoring tiers auquel les deux parties ont accès en lecture. Quelle que soit la source choisie, elle doit être explicitement nommée dans le SLA. « Le délai de prise en compte est mesuré à partir de l’horodatage d’ouverture du ticket dans le système de gestion de demandes du prestataire » est une formulation acceptable et vérifiable. « Le prestataire mesure ses propres délais selon ses outils internes » est une formulation invérifiable par le client et potentiellement inopposable.

La deuxième règle est que le client doit pouvoir vérifier les mesures de façon indépendante. Un SLA mesuré exclusivement par le prestataire, sans que le client puisse accéder aux données brutes de mesure, est structurellement invérifiable. Même dans l’hypothèse où le prestataire est parfaitement honnête dans son reporting, le client se trouve dans l’impossibilité de contrôler les engagements pour lesquels il paie. Une clause de transparence minimale, permettant au client de consulter les données de disponibilité et les temps de traitement des tickets sur une période donnée, renforce la confiance commerciale et réduit substantiellement le risque de litige.

La troisième règle concerne la procédure de contestation des mesures. Si le client estime que les données fournies sont inexactes ou incomplètes, quelle est la procédure ? Qui tranche et dans quel délai ? En l’absence de procédure définie, chaque contestation devient un conflit ouvert dont la résolution dépend du rapport de force entre les parties. Une clause simple peut prévoir qu’en cas de désaccord sur les données de mesure, les deux parties disposent d’un délai de dix jours ouvrés pour soumettre leurs éléments contradictoires, et qu’un accord amiable doit être recherché dans ce délai avant toute action contentieuse.

Il faut enfin décider de la granularité temporelle de la mesure. Le taux de disponibilité est-il calculé sur le mois calendaire strict, sur des tranches de trente jours glissants ou sur l’année complète ? La méthode de calcul choisie change significativement le résultat en cas d’incident long. Une indisponibilité de quarante heures consécutives peut, selon la méthode retenue et le moment du mois où elle survient, être absorbée par le quota mensuel ou franchement dépasser le quota annuel. Cette décision doit être prise à la rédaction du SLA, pas lors de l’incident.

Les pénalités

Un SLA sans pénalité est une liste de voeux. La pénalité est le mécanisme qui transforme un engagement de service en obligation contractuelle assortie de conséquences réelles et prévisibles. Mais une pénalité mal calibrée est aussi problématique qu’une absence de pénalité : trop faible, elle n’incite à rien ; trop élevée, elle expose le prestataire à une déstabilisation financière disproportionnée par rapport à un incident de quelques heures.

La pénalité prévue dans un SLA est une clause pénale au sens du droit civil. Elle permet aux parties de convenir à l’avance du montant forfaitaire dû par le prestataire en cas de manquement à ses engagements, sans que le client ait à démontrer l’étendue précise de son préjudice. L’article 1231-5 du Code civil dispose cependant que le juge peut modérer la pénalité qui a été convenue si elle est manifestement excessive, ou l’augmenter si elle est manifestement dérisoire. Cette possibilité de modération judiciaire est souvent ignorée lors de la rédaction des SLA, ce qui conduit à deux comportements également problématiques.

Le premier problème est la pénalité symbolique. Une pénalité de quelques euros par heure de dépassement dans un contrat à plusieurs milliers d’euros par mois n’incite à rien et n’indemnise pas réellement le client pour le préjudice subi. Elle risque d’être considérée comme dérisoire au sens de l’article 1231-5 et augmentée par un juge, mais surtout, elle ne constitue pas une véritable incitation pour le prestataire à tenir ses engagements.

Le second problème est la pénalité disproportionnée. Une clause qui prévoit une pénalité équivalente à plusieurs mois de redevance pour un seul dépassement de délai expose le prestataire à une déstabilisation contractuelle pour un incident dont la durée réelle est peut-être de quelques heures seulement. Ce type de clause sera vraisemblablement modéré par un juge, mais le litige aura déjà consommé des ressources considérables des deux côtés.

La forme de la pénalité doit être précisée dans le SLA. Les options les plus courantes sont les suivantes.

• L’avoir sur facture. La pénalité prend la forme d’un crédit déduit de la prochaine échéance de facturation. C’est la forme la plus simple à administrer et la moins conflictuelle dans une relation commerciale durable, mais elle suppose que le contrat se poursuive.
• La réduction de redevance. Une réduction proportionnelle est appliquée automatiquement sur la période de facturation concernée. Cette forme est plus transparente pour le client mais nécessite un calcul rigoureux et une traçabilité des mesures.
• Le remboursement partiel. Une partie de la redevance déjà réglée est remboursée. Cette option reste rare dans les contrats de service récurrents mais peut être pertinente dans des contrats à durée déterminée avec paiement d’avance.

Le SLA doit aussi prévoir un plafond de pénalités par période. Sans plafond, l’accumulation de pénalités sur plusieurs mois de mauvaise performance peut dépasser la valeur totale du contrat, créant une situation financièrement inextricable. Un plafond mensuel exprimé en pourcentage de la redevance mensuelle est la solution la plus répandue. Au-delà de ce plafond, le client peut se voir accorder d’autres recours, comme le droit de résiliation sans frais ni préavis.

Il faut également définir si les pénalités se déclenchent automatiquement à chaque cycle de facturation ou si elles nécessitent une demande explicite du client. La première option est plus protectrice pour le client, mais elle impose au prestataire un suivi rigoureux de ses propres performances à chaque période. La seconde option protège moins bien le client mais est plus simple à administrer. Quelle que soit l’option choisie, le mécanisme doit être décrit avec précision dans le SLA pour éviter tout désaccord sur son application.

Les limites de la limitation de responsabilité

La quasi-totalité des contrats de service informatique et de support contient une clause de limitation de responsabilité qui plafonne les indemnités susceptibles d’être dues par le prestataire en cas de manquement, toutes causes confondues. Ces clauses sont légitimes et courantes, mais elles ont des limites juridiques précises que les prestataires oublient parfois de prendre en compte lors de la rédaction.

L’article 1170 du Code civil dispose que toute clause qui prive de sa substance l’obligation essentielle du débiteur est réputée non écrite. Si la limitation de responsabilité est tellement basse qu’elle vide pratiquement de tout sens l’obligation de support promis au client, elle peut être réputée non écrite par un juge, sans que le reste du contrat soit affecté. Une clause qui limiterait la responsabilité du prestataire à un euro symbolique pour tout manquement au SLA, quelle que soit la gravité ou la durée de l’incident, risque d’être écartée sur ce fondement.

L’article 1171 du Code civil, applicable aux contrats d’adhésion, c’est-à-dire aux contrats dont les conditions générales sont unilatéralement fixées par l’une des parties sans négociation réelle possible, dispose que toute clause créant un déséquilibre significatif entre les droits et obligations des parties est réputée non écrite. Un SLA proposé sous forme de conditions générales non négociables, qui combine des engagements de service présentés comme élevés avec une limitation de responsabilité quasi totale, peut être partiellement anéanti sur ce fondement. La combinaison de ces deux articles impose une cohérence interne entre l’engagement pris dans le SLA et la responsabilité assumée en cas de manquement.

La solution pratique est de calibrer la limitation de responsabilité en fonction du niveau de service promis et du tarif effectivement payé. Plus le service est premium et plus les engagements sont stricts, plus la responsabilité assumée en cas de défaillance doit être proportionnée au risque réel que le client encourt. Cette logique de proportionnalité est à la fois juridiquement solide au regard des articles 1170 et 1171, et commercialement cohérente : un client qui paie pour un service critique doit bénéficier d’une responsabilité contractuelle à la hauteur de ce qu’il risque en cas de défaillance.

Calibrer un SLA tenable en cinq étapes

Un SLA tenable n’est pas un document que l’on copie depuis un modèle trouvé en ligne et que l’on adapte superficiellement. C’est le résultat d’une analyse honnête des capacités réelles de l’organisation au moment où elle s’engage. Voici les cinq étapes de cette démarche, dans l’ordre dans lequel elles doivent être conduites.

• Étape 1 : mesurer ce que l’on fait réellement avant de promettre. Avant de rédiger un seul délai, il faut analyser les données historiques du support sur une période représentative. Quel est le délai médian de prise en compte réel sur les six derniers mois ? Quel est le délai de rétablissement moyen par type d’incident et par niveau de complexité ? Ces données existent dans le système de tickets si ce dernier est utilisé de façon rigoureuse et continue. Si elles n’existent pas encore, la première étape est de mettre en place l’outil de mesure et d’attendre plusieurs semaines de données avant de s’engager sur des délais contractuels.
• Étape 2 : identifier les contraintes opérationnelles réelles. Combien de personnes sont disponibles pour le support et pendant quelles plages horaires exactement ? Y a-t-il une astreinte nocturne ou le week-end, et si oui, combien de personnes ? L’infrastructure dispose-t-elle d’une redondance effective ? Quelle est la procédure en cas d’absence simultanée de plusieurs membres de l’équipe ? Les engagements de service ne peuvent en aucun cas dépasser les capacités humaines et techniques disponibles au quotidien.
• Étape 3 : définir les niveaux de criticité avec les clients représentatifs. Cette définition ne doit pas être rédigée en chambre : elle doit être construite avec des clients réels pour comprendre ce qu’ils considèrent comme un incident bloquant dans leur contexte métier. Un incident que le prestataire juge modéré peut être absolument critique pour le client s’il survient en période de clôture comptable, lors d’un audit ou en période de forte activité commerciale.
• Étape 4 : ajouter une marge de sécurité aux délais mesurés. Si le délai médian de rétablissement d’un incident de niveau P2 est de six heures sur l’historique, s’engager sur six heures revient à accepter que la moitié des incidents P2 futurs dépasseront l’engagement. Une marge raisonnable, par exemple s’engager sur douze heures lorsque la médiane observée est à six, permet d’absorber les incidents plus complexes ou les périodes de pic sans violer systématiquement le SLA.
• Étape 5 : faire valider les engagements par l’équipe opérationnelle avant toute signature. C’est l’étape la plus souvent omise. La personne chargée de la vente du contrat a tendance à promettre des délais ambitieux pour emporter la signature. L’équipe technique qui devra les tenir ne découvre parfois ces engagements qu’après la signature. La validation interne, par les personnes qui exécuteront le SLA au quotidien, est une condition essentielle de la crédibilité et de la viabilité de tout engagement de niveau de service.

Le coût d’un niveau de service

Un niveau de service élevé n’est pas gratuit. C’est un principe économique fondamental que les SLA de nombreuses petites et moyennes structures ignorent, parfois parce que le SLA est perçu comme un argument commercial à offrir plutôt que comme un service à facturer. Or, offrir un niveau de service sans le facturer est une stratégie qui mène à l’épuisement de l’équipe, à la dégradation progressive de la qualité et, à terme, à l’impossibilité de tenir les engagements pris.

Le coût d’un niveau de service se décompose en quatre grandes familles.

• L’astreinte. Un engagement de support en dehors des heures ouvrées implique une organisation d’astreinte formalisée : un ou plusieurs membres de l’équipe sont joignables en permanence en dehors de leurs horaires normaux de travail et peuvent intervenir dans les délais prévus. L’astreinte a un coût direct (rémunération spécifique, récupération ou compensations prévues par la réglementation) et un coût indirect important lié à la fatigue, au turnover accru si elle est trop fréquente et à la difficulté à recruter sur des postes imposant des astreintes régulières.
• La redondance. Un taux de disponibilité élevé suppose une infrastructure redondante : serveurs en miroir, capacité de bascule automatique en cas de défaillance d’un composant, connexions réseau doubles, alimentation électrique sécurisée. Chaque composant redondant représente un coût d’achat ou d’abonnement et un coût de maintenance et de test régulier. La redondance complète sur l’ensemble de la chaîne technique peut doubler ou tripler le coût total d’infrastructure selon les environnements.
• La documentation des procédures. Pour que n’importe quel membre de l’équipe puisse intervenir sur n’importe quel type d’incident, à n’importe quelle heure, les procédures de diagnostic et de résolution doivent être documentées de façon précise et maintenues à jour. Cette documentation a un coût de création initial et un coût de mise à jour régulière à chaque évolution du service. Sans documentation à jour, le temps de résolution dépend entièrement de la disponibilité des rares personnes qui « savent » comment traiter un incident donné.
• L’effectif minimum. Un niveau de service fiable dans la durée suppose un effectif de support suffisant pour absorber les absences, les congés et les arrêts maladie sans dégradation du service. Si l’équipe de support ne comprend qu’une ou deux personnes, la première absence la rend structurellement inopérante sur une partie des engagements. Le coût du niveau de service inclut donc le coût de la polyvalence, de la formation croisée ou de la sous-traitance de secours.

La bonne pratique consiste à calculer le coût annuel total de ces quatre composantes, à le répartir sur l’ensemble des contrats bénéficiant du niveau de service correspondant, et à l’intégrer dans la tarification. Ce calcul révèle souvent qu’un niveau de service perçu comme une « option naturellement incluse » coûte en réalité un montant significatif à l’organisation. Ce coût doit être visible dans la proposition commerciale, sous la forme d’un forfait de support explicitement identifié ou d’une majoration tarifaire pour les clients bénéficiant d’engagements plus stricts.

La revue périodique et l’évolution du SLA

Un SLA signé une fois pour toutes n’est pas un bon SLA. Les capacités du prestataire évoluent avec la croissance de l’équipe ou l’amélioration de l’infrastructure. Les usages du client évoluent avec le développement de son activité. Les incidents rencontrés au cours des premiers mois de vie d’un contrat révèlent systématiquement des angles morts que la rédaction initiale n’avait pas anticipés. La revue périodique du SLA est le mécanisme qui permet d’adapter les engagements à la réalité sans avoir à renégocier l’intégralité du contrat principal.

La revue peut être trimestrielle ou semestrielle selon la fréquence des incidents et la maturité de la relation. Elle porte sur plusieurs sujets : l’analyse des données de performance réelles sur la période écoulée, la comparaison entre les engagements contractuels et les performances effectives, l’identification des incidents récurrents qui révèlent un problème structurel non résolu, et la mise à jour éventuelle des définitions de criticité si de nouveaux types d’incidents sont apparus depuis la dernière version du SLA.

Pour que la revue puisse déboucher sur une mise à jour du SLA sans renégocier le contrat principal, il faut prévoir cette possibilité dès la rédaction initiale. Une clause d’évolution peut stipuler que les annexes SLA peuvent être mises à jour par avenant signé des deux parties, sans modification des conditions générales du contrat. Cette clause permet de maintenir le SLA en phase avec la réalité opérationnelle, sans les délais et les coûts d’une renégociation contractuelle complète à chaque ajustement.

La revue est aussi l’occasion de vérifier que le mécanisme de pénalités est opérationnel. Si des pénalités ont été prévues mais n’ont jamais été calculées ni appliquées, le SLA n’est plus qu’un document de façade. Si les pénalités ont été appliquées mais ont conduit à des tensions commerciales disproportionnées, c’est peut-être que leur montant ou leur seuil de déclenchement mérite d’être réajusté. La revue périodique est le bon moment pour faire ces ajustements de façon concertée, dans un contexte serein et non sous la pression d’un incident en cours.

Erreurs fréquentes

Les erreurs suivantes sont les plus couramment rencontrées dans les SLA de petites et moyennes structures. Chacune d’elles peut transformer un SLA bien intentionné en source de litiges coûteux et de détérioration de la relation client.

• Des délais sans point de départ précis. Écrire « délai de réponse : deux heures » sans préciser à partir de quel moment ce délai commence à courir est l’erreur la plus fréquente et la plus coûteuse. Ouverture du ticket, réception d’un courriel, premier appel téléphonique enregistré : le point de départ doit être défini sans ambiguïté.
• Une plage de service non mentionnée. « Délai de rétablissement : quatre heures » sans mention de la plage de service applicable est un engagement qui peut signifier n’importe quoi selon le moment de l’incident. La plage doit figurer explicitement dans le SLA.
• Un taux de disponibilité copié depuis un modèle. Reprendre un taux de disponibilité depuis un modèle de contrat trouvé sur un moteur de recherche sans vérifier si l’infrastructure et l’équipe permettent réellement de le tenir est une faute de conception. Le taux doit résulter d’une analyse interne documentée.
• Des exclusions non écrites. S’appuyer sur des exclusions que tout le monde comprend implicitement mais que personne n’a prises la peine d’écrire dans le contrat. En cas de litige, seul ce qui est écrit et signé compte.
• Une mesure exclusivement unilatérale. Ne laisser qu’au prestataire la capacité de mesurer ses propres performances, sans possibilité de vérification par le client. Cette configuration est peu crédible commercialement et potentiellement problématique lors d’un contentieux.
• Des pénalités inscrites mais jamais appliquées. Prévoir des pénalités dans le SLA mais ne jamais les calculer ni les appliquer. Au bout de quelques mois, le SLA devient un document de décor. Les pénalités doivent être calculées à chaque période de facturation, même si leur montant est nul, pour maintenir la crédibilité du mécanisme.
• Un engagement identique quel que soit le prix payé. Proposer les mêmes délais et le même taux de disponibilité à tous les clients sans distinction de tarif est une erreur économique. Les clients dont l’usage est le plus critique et le plus exigeant ne paient pas nécessairement les tarifs les plus élevés. Un système de niveaux de service différenciés est plus juste et plus viable.
• L’absence de procédure d’escalade. Ne pas définir ce qui se passe lorsqu’un incident dépasse son délai de rétablissement sans être résolu laisse prestataire et client sans cadre pour gérer les situations les plus critiques, c’est-à-dire précisément celles où un cadre est le plus nécessaire.
• Des définitions de criticité trop vagues. Écrire « incident critique : tout problème grave affectant le service » ne définit rien de mesurable. La criticité doit être définie par l’effet observable et objectif sur l’activité du client, pas par un qualificatif subjectif.
• L’oubli de la revue périodique. Rédiger un SLA et ne jamais le revisiter conduit inévitablement à un décalage croissant entre les engagements contractuels et la réalité opérationnelle, jusqu’à ce que ce décalage devienne un sujet de conflit ouvert.

Un engagement de délai suppose de dater chaque étape

Un SLA ne peut être tenu et vérifié que si chaque étape du traitement d’une demande est datée de façon fiable, automatique et traçable dans le temps. Cela suppose un outil dans lequel la date d’ouverture de la demande et la date de chaque action ultérieure sont enregistrées de façon non modifiable et consultable par les deux parties concernées.

Djaboo dispose d’un module de tickets qui permet d’enregistrer une demande avec son objet, son message, le client et le contact associés. Chaque ticket peut se voir attribuer une priorité, un statut, un département et un service, et peut être assigné à un membre précis de l’équipe. Il est possible d’y ajouter des réponses visibles par le client, des notes internes réservées à l’équipe, et des pièces jointes. La date d’ouverture du ticket et la date de la dernière réponse y sont conservées, ce qui permet de reconstituer la chronologie complète d’une demande à tout moment, pour toute vérification ou tout arbitrage utile.

Questions fréquentes

Quelle est la différence entre un SLA et un contrat de service ?

Un contrat de service définit l’ensemble de la relation commerciale entre un prestataire et un client : périmètre de la prestation, tarification, durée, conditions de résiliation et de renouvellement. Un SLA est une annexe ou une composante de ce contrat qui se concentre spécifiquement sur les niveaux de performance et de réactivité attendus. Le SLA n’a de force juridique que s’il est intégré ou formellement référencé dans le contrat principal. Un document intitulé « SLA » non rattaché à un contrat est une déclaration d’intention sans valeur obligatoire.

Un SLA peut-il s’appliquer à une prestation de conseil ou de service intellectuel ?

Oui, mais la nature des engagements sera différente d’un SLA de support informatique. Pour une prestation de conseil, le SLA portera sur des délais de réponse à des demandes d’avis, des délais de remise de livrables ou des délais de correction de documents. La structure reste identique : points de départ précis, plages de service définies, niveaux de priorité selon la nature de la demande, pénalités proportionnées et exclusions bornées.

Peut-on modifier un SLA en cours de contrat sans l’accord du client ?

Non, si le SLA est intégré au contrat ou à une annexe contractuelle formellement acceptée. Une modification unilatérale d’un élément contractuel est contraire au principe posé par l’article 1103 du Code civil, selon lequel les conventions tiennent lieu de loi entre les parties. Une évolution du SLA nécessite un accord formalisé des deux parties, le plus souvent par avenant. C’est précisément pour faciliter ces évolutions que la clause d’avenant simplifié sur les seules annexes SLA est utile et doit être prévue dès la rédaction initiale du contrat.

Une grève interne peut-elle constituer un cas de force majeure justifiant un manquement au SLA ?

Généralement non. Une grève interne n’est pas qualifiable de force majeure au sens de l’article 1218 du Code civil, car elle n’est pas imprévisible dans le cadre d’une relation employeur-employé et ses effets peuvent souvent être atténués par des mesures appropriées comme le recours à des prestataires externes ou l’activation d’une organisation de secours. Le prestataire demeurera en principe responsable des manquements causés par une grève interne, sauf si le contrat prévoit explicitement et précisément cette exclusion dans ses conditions.

Comment gérer le cas où un client qualifie abusivement tous ses incidents en priorité critique ?

La qualification du niveau de criticité doit appartenir au prestataire lors du traitement de la demande, selon les critères objectifs définis dans la grille de criticité du SLA. Le client peut signaler l’urgence qu’il perçoit, mais il ne peut pas imposer unilatéralement la priorité de son ticket. Si le client conteste la qualification retenue, le SLA doit prévoir une procédure d’escalade interne rapide, par exemple une décision du responsable support du prestataire dans un délai court défini, avec traçabilité de la décision dans le ticket.

Faut-il rédiger un SLA différent pour chaque client ?

Ce n’est généralement pas nécessaire. La bonne pratique consiste à définir deux ou trois niveaux de SLA standardisés, par exemple Standard, Avancé et Prioritaire, et à permettre à chaque client de choisir le niveau adapté à ses besoins et à son budget. Cela simplifie considérablement la gestion opérationnelle pour le prestataire et assure une différenciation tarifaire cohérente et explicable. Un SLA entièrement sur mesure pour chaque client est possible mais complexe à gérer à l’échelle et difficile à maintenir à jour de façon homogène.

Les pénalités prévues dans un SLA s’appliquent-elles automatiquement sans formalité ?

Une clause pénale est exécutoire entre les parties dès lors qu’elle est valablement formée et que le manquement est constaté. Toutefois, l’article 1231-5 du Code civil confère au juge le pouvoir de la modérer si elle est manifestement excessive ou de l’augmenter si elle est manifestement dérisoire. Cela signifie qu’une pénalité inscrite dans un SLA ne sera pas nécessairement appliquée intégralement si elle est soumise à un tribunal. C’est un argument supplémentaire pour calibrer les pénalités de façon proportionnée dès la rédaction initiale, et non sous le coup d’une ambition commerciale.

Comment distinguer contractuellement une maintenance planifiée d’une indisponibilité non planifiée ?

La distinction repose sur deux critères cumulatifs : l’anticipation et la notification préalable. Une maintenance planifiée est une intervention programmée à l’avance et notifiée au client dans le délai prévu par le SLA, par exemple quarante-huit heures avant l’intervention. Toute interruption survenant en dehors de ce cadre formalisé est une indisponibilité non planifiée, quelles qu’en soient les causes. Pour éviter les abus, le SLA doit plafonner la durée totale de maintenance planifiée autorisée par mois et restreindre les plages horaires dans lesquelles elle peut avoir lieu.

Un SLA peut-il prévoir des engagements modulés selon les périodes de l’année ?

Oui, et c’est même une pratique judicieuse pour les secteurs à forte saisonnalité ou pour les clients dont l’activité présente des pics prévisibles. Un prestataire qui sait que ses clients ont une activité critique en fin d’année ou en période de clôture peut prévoir des engagements renforcés pendant ces périodes, avec une facturation correspondante, et des engagements allégés pendant les périodes creuses. Cette modulation saisonnière doit être écrite dans le SLA avec les dates précises de chaque période et les engagements spécifiques qui s’y appliquent.

Que faire lorsqu’un incident dépasse le délai de rétablissement prévu sans être résolu ?

Le SLA doit impérativement prévoir une procédure d’escalade pour ce cas précis. Elle peut inclure la notification automatique au responsable du prestataire, la reclassification de l’incident au niveau de criticité supérieur, la mobilisation d’une équipe de crise, ou l’activation d’un droit de résiliation sans frais au-delà d’un seuil cumulé de dépassements sur une période donnée. Sans cette procédure, un incident bloquant qui s’éternise laisse le client sans recours défini pendant toute la durée de la crise, ce qui aggrave son préjudice réel et le risque de contentieux ultérieur.