Distinguer disponibilité et résolution
Un taux de disponibilité agrégé ne dit pas combien de temps une panne particulière durera ni comment elle affecte votre site. Demandez la période de mesure, les exclusions, la méthode de calcul, les fenêtres de maintenance et la source des données. Faites préciser si le service critique de votre opération est couvert par la mesure annoncée.
Le délai de première réponse n’est pas un délai de résolution. Relevez séparément accusé de réception, prise en charge, contournement, correction, restauration et compte rendu. Vérifiez les plages horaires et les jours couverts, y compris les périodes où votre activité fonctionne en dehors du bureau.
Demandez les conséquences contractuelles d’un engagement manqué et les exceptions. Faites examiner les clauses par les achats ou le conseil juridique; une présentation commerciale ne modifie pas le contrat signé.
Classer les incidents par effet métier
Définissez des exemples concrets de priorité avec les responsables du site : arrêt de réception, blocage de préparation, erreur isolée ou demande d’accès. Indiquez les flux concernés, le nombre de personnes touchées et la procédure temporaire. La criticité d’un ticket doit refléter votre activité et être validée en interne.
Précisez les canaux de déclaration, les informations à joindre et les personnes autorisées. Demandez comment les équipes sont notifiées, qui peut escalader et comment un incident est clos. Évitez de transmettre des identifiants, des données personnelles ou des exports complets dans un ticket non protégé.
Faites démontrer la procédure de support sur un cas fictif. Regardez quelles informations restent accessibles au client et si un historique peut être exporté. Une adresse de support seule ne prouve pas qu’un problème sera traité dans le délai souhaité.
Vérifier les responsabilités croisées
Un incident peut impliquer WMS, réseau, terminal, ERP ou transporteur. Établissez qui coordonne le diagnostic et comment les fournisseurs se parlent. Si chacun renvoie vers un autre contrat, le délai opérationnel s’allonge. Demandez si le fournisseur accepte un contact technique avec un tiers et quelles autorisations sont requises.
Clarifiez qui surveille les interfaces, gère les certificats, teste les mises à jour et maintient les appareils. Une responsabilité non attribuée finit souvent au support de premier niveau. Inscrivez chaque propriétaire, son remplaçant et la preuve du passage de relais.
Examinez les limites du support inclus : versions, environnements, heures, langue, nombre de demandes ou assistance sur site. Les prestations optionnelles doivent apparaître dans le budget et les conditions. Évitez de conclure à une couverture complète d’après une brochure.
Rendre le service exploitable
Créez un registre des contacts et procédures avec les versions du contrat et du système. Testez les accès au portail avant la mise en service. Préparez un scénario d’escalade où l’administrateur habituel est absent.
Planifiez une revue de service qui examine incidents, causes, demandes répétées, changements à venir et actions. Demandez un compte rendu adapté à vos flux, pas uniquement des statistiques agrégées. Chaque action doit avoir un propriétaire et une échéance.
Les engagements varient selon les offres et évoluent dans le temps. Seuls vos documents contractuels datés permettent de déterminer ce qui s’applique. Cet article fournit une liste de questions, pas une interprétation juridique de votre SLA.
Sources et limites
Ces repères éclairent une méthode de préparation; ils ne valident ni votre configuration ni un fournisseur. Vérifiez les documents contractuels, les versions techniques et les règles applicables à votre activité avec les personnes responsables.