SLA de support logiciel : distinguer réponse et rétablissement

Définissez un SLA avec exemples de gravité, horaires, obligations de réponse, objectifs de restauration, exclusions et procédure d’escalade.

Un SLA doit aider les deux parties à agir lorsqu’un problème survient. Réponse rapide ou support complet reste invérifiable sans horloge, périmètre et action attendue. Séparez accusé de réception, investigation, rétablissement et résolution durable. Un prestataire peut répondre vite alors que le service reste indisponible. Ces résultats différents ne doivent pas être présentés comme une seule promesse.

Définir la gravité par les effets métier

Utilisez des exemples de parcours, utilisateurs et solutions de contournement. Une panne de paiement peut dépasser l’impact d’un défaut visuel sur une page très fréquentée. Précisez qui attribue ou change la gravité et comment résoudre un désaccord. Incluez sécurité et intégrité des données sans considérer chaque alerte comme incident confirmé. Gardez une matrice utilisable sous pression. Des cas limites concrets permettent de rapprocher les attentes avant la première situation difficile.

Rendre le chronomètre clair

Indiquez fuseau, jours, horaires, fêtes et couverture hors heures ouvrées. Définissez début d’une demande valide, canal surveillé et informations requises. Si le temps s’arrête en attendant le client, précisez conditions et notification. Distinguez cible contractuelle et estimation dépendant d’un fournisseur. Ne promettez pas la même résolution pour tout défaut inconnu sans frontière de support. Décrivez aussi la continuité d’une investigation lorsque la fenêtre de couverture se termine.

Répartir responsabilités et exclusions

• Nommez systèmes, environnements et intégrations, avec versions exclues ou défauts hérités.
• Attribuez accès, approbations et communication aux deux parties.
• Fixez contacts d’escalade, fréquence des nouvelles et procédure lorsqu’un engagement risque d’être dépassé.
• Précisez si changement urgent, analyse de cause et correction permanente sont inclus ou séparément chiffrés.

Éprouver l’accord par un scénario

Jouez une panne de checkout en fin de couverture. Qui reçoit l’alerte, peut déployer, informe les clients et agit si le prestataire de paiement est indisponible ? Réécrivez les clauses ambiguës avant une vraie panne. Évaluez les rapports avec l’horloge et les résultats convenus, pas uniquement le nombre de tickets. Les deux parties doivent comprendre promesse, preuve et conduite en cas d’échec. Conservez la même version actuelle et organisez les passages de relais : une demande reconnue mais sans propriétaire suivant peut rester involontairement immobile. Les exceptions doivent également avoir un propriétaire identifié.

• Maintenance et support →
• Checklist de maintenance des sites critiques →
• Forfait de maintenance ou intervention à la demande →