Accord de niveau de service

1. Portée

Le présent accord de niveau de service (« SLA ») est incorporé par référence aux Conditions de service et régit les engagements de niveau de service que nous prenons envers les clients utilisant les Services décrits ci-dessous.

1.1 Services couverts

Le présent SLA s'applique aux catégories de Services suivantes :

• Serveurs privés virtuels (VPS), y compris tous les niveaux Linux KVM
• Serveurs de protocole de bureau à distance (RDP)
• Serveurs dédiés (DS)
• Serveurs GPU (GPU)
• Serveurs de stockage et de sauvegarde
• Serveurs de streaming
• Serveurs de jeux

1.2 Services avec engagements ajustés

Les hébergements mutualisés et cPanel sont soumis aux engagements de disponibilité de la section 2, mais avec une mesure ajustée pour l'architecture mutualisée (la cible de mesure pertinente est la disponibilité de l'hôte mutualisé plutôt que la disponibilité du conteneur par client).

1.3 Services non couverts

Les services d'e-mail et d'hébergement SMTP sont soumis à des engagements de disponibilité distincts publiés sur leurs pages produit respectives. Les services bêta et d'aperçu explicitement étiquetés comme tels ne sont pas couverts par le présent SLA.

2. Engagement de disponibilité

2.1 Formules standard

Les formules standard — VPS-1 à VPS-8, RDP-Basic et RDP-Pro, tous les niveaux de stockage, Game-S et Game-M, Streaming-1 — sont soumises à un engagement de disponibilité mensuel de 99,9 %.

Une disponibilité mensuelle de 99,9 % correspond à un maximum de 43 minutes 50 secondes d'indisponibilité dans un mois civil de 30 jours, ou 44 minutes 38 secondes dans un mois de 31 jours.

2.2 Formules Pro, Premium, Dédiées, GPU

Les formules de niveau supérieur — VPS-16, RDP-Power, tous les niveaux dédiés (DS-Lite à DS-Beast), tous les niveaux GPU (GPU-Lite à GPU-Beast), Game-L, Streaming-2 — sont soumises à un engagement de disponibilité mensuel de 99,99 %.

Une disponibilité mensuelle de 99,99 % correspond à un maximum de 4 minutes 23 secondes d'indisponibilité dans un mois civil de 30 jours, ou 4 minutes 28 secondes dans un mois de 31 jours.

3. Méthodologie de mesure

3.1 Surveillance externe

La disponibilité est mesurée par des nœuds de surveillance externes exploités par des fournisseurs de disponibilité tiers (UptimeRobot, Better Uptime, ou équivalent). Nous maintenons actuellement trois (3) nœuds de surveillance indépendants situés dans des régions géographiquement distinctes afin d'éviter une mesure à point de défaillance unique.

3.2 Intervalle de sonde

Chaque nœud de surveillance sonde le point de terminaison principal de chaque Service toutes les cinq (5) minutes.

3.3 Détection à la majorité

Une indisponibilité est enregistrée lorsqu'au moins deux des trois nœuds de surveillance signalent le Service comme injoignable dans la même fenêtre de sonde. Cela évite d'attribuer les pannes de réseau locales au niveau du nœud de surveillance à un incident MurmurHost.

3.4 Accumulation d'indisponibilité

Une « minute d'indisponibilité » est toute minute entière pendant laquelle la détection à la majorité est dans l'état injoignable. Les minutes partielles sont arrondies à la minute entière supérieure pour le calcul des crédits.

3.5 Mesure côté client

Les clients peuvent utiliser leur propre infrastructure de surveillance pour corroborer les réclamations d'indisponibilité. Lorsque la mesure côté client diverge considérablement de notre surveillance, nous partagerons nos données de mesure et travaillerons à un accord sur la période d'indisponibilité réelle.

4. Crédits de service

4.1 Niveaux de crédit

Si un Service couvert tombe en dessous de son engagement de disponibilité mensuel, le client a droit à un crédit de service calculé en pourcentage des frais mensuels du Service concerné :

4.2 Application

Les crédits de service sont appliqués à la prochaine facture du Service concerné. Si le client résilie le Service concerné avant la prochaine facture, le crédit est versé sous forme de remboursement selon le mode de paiement d'origine, sous réserve des conditions de traitement de la Politique de remboursement.

4.3 Plafond

Le crédit total pour tout Service concerné au cours d'un mois donné ne peut pas dépasser 100 % des frais mensuels de ce Service. Les crédits de service sont le recours unique et exclusif du client pour tout manquement aux engagements de disponibilité au titre du présent SLA.

5. Exclusions

Les éléments suivants ne comptent pas comme indisponibilité aux fins de la section 2 :

5.1 Maintenance planifiée

Maintenance annoncée au moins quarante-huit (48) heures à l'avance via le panneau client et la page de statut sur /status. Les fenêtres de maintenance de routine sont généralement planifiées en dehors des heures de pointe pour la juridiction concernée.

5.2 Force majeure

Actes de Dieu, catastrophes naturelles, guerre, troubles civils, action gouvernementale, terrorisme, ou événements comparables hors de notre contrôle raisonnable.

5.3 Faute du client

Indisponibilité causée par une mauvaise configuration du client, des bogues logiciels contrôlés par le client, un dépassement des allocations de ressources du plan, ou des opérations effectuées par le client (comme un redémarrage volontaire, une réinstallation du système d'exploitation, ou un changement de configuration qui désactive l'accès à distance).

5.4 Pannes de réseau tierces

Indisponibilité causée par des pannes de réseau tierces hors de notre réseau et hors de nos accords de peering, y compris les pannes du FAI du client, du fournisseur de transit ou du réseau de dernier kilomètre.

5.5 Action liée à la AUP

La suspension en vertu de la AUP ne compte pas comme indisponibilité. Les suspensions contestées de la AUP annulées en appel ne sont pas rétroactivement comptées comme indisponibilité ; le recours du client dans ce cas est documenté dans la AUP.

6. Performance du réseau

6.1 Objectifs de latence

Nous nous engageons à des objectifs de latence médiane entre notre réseau périphérique et les principaux points d'échange Internet régionaux, mesurés mensuellement :

6.2 Perte de paquets

Nous nous engageons à moins de 0,1 % de perte de paquets sur le trafic intra-datacenter mesuré sur toute fenêtre glissante de 5 minutes, à l'exclusion des intervalles affectés par un nettoyage DDoS actif.

6.3 Débit

Nous nous engageons à un débit à la vitesse du port configuré sur le Service, moins les frais généraux d'encapsulation et de transit typiques. Un débit soutenu nettement inférieur à la vitesse du port (après exclusion de la congestion de transit hors de notre réseau) est traité comme un manquement à la performance du réseau.

7. Délais de mitigation DDoS

7.1 Attaques volumétriques

Les attaques DDoS volumétriques ciblant les Services des clients sont détectées et étiquetées par notre périphérie de nettoyage anycast dans les soixante (60) secondes suivant le début de l'attaque. La mitigation est automatique et ne nécessite aucune action du client.

7.2 Attaques au niveau applicatif

Les attaques au niveau applicatif (L7) nécessitent des règles spécifiques à l'application. Nous fournissons des règles standard à la périphérie pour les modèles courants ; les règles adaptées à l'application spécifique du client (chemins d'URL, signatures de requêtes) sont de la responsabilité du client, éventuellement configurables via Cloudflare ou BunnyCDN à la périphérie de l'application.

7.3 Capacité par niveau de formule

La capacité de nettoyage volumétrique évolue avec le niveau de la formule et est documentée sur /features/ddos-protection. Les attaques soutenues au-dessus de la capacité de nettoyage de la formule peuvent déclencher une conversation de mise à niveau plutôt qu'un crédit de service.

8. SLA de provisionnement

8.1 Services basés sur KVM

Les plans VPS KVM, RDP, mutualisés et cPanel terminent le provisionnement dans les cinq (5) minutes suivant la confirmation du paiement. La confirmation est le moment où le paiement en cryptomonnaie atteint les confirmations de seuil décrites sur la page des méthodes de paiement ; pour les paiements par carte où cela est pris en charge, la confirmation est le règlement chez le processeur.

8.2 Dédié et GPU

Les plans dédiés et GPU en stock terminent le provisionnement dans les vingt-quatre (24) heures suivant la confirmation du paiement. Les constructions dédiées personnalisées (multi-GPU, configurations RAID exotiques, modèles de NIC spécifiques) sont signalées lors de la passation de commande et peuvent prendre 1 à 3 jours ouvrables.

8.3 Commandes groupées

Les commandes groupées (plus de cinq Services dans une seule transaction) nécessitent une coordination avec l'équipe commerciale. Les délais sont convenus lors de la passation de commande et font partie du SLA spécifique à la commande.

8.4 Crédits pour manquement au provisionnement

Si le provisionnement dépasse l'objectif pertinent de plus de 25 %, le client a droit à un crédit de service d'un mois sur le Service concerné. Cela s'ajoute à tout crédit lié à la disponibilité accumulé en vertu de la section 4.

9. Délais de réponse du support

9.1 Définitions des gravités

• Critique : serveur en panne, données inaccessibles, incident de sécurité en cours
• Élevée : performance dégradée, panne partielle, injoignabilité intermittente
• Normale : question de configuration, demande de fonctionnalité, clarification de facturation n'affectant pas le fonctionnement du service
• Faible : retour sur documentation, question de processus, demande non urgente

9.2 Objectifs de réponse

9.3 Canaux de support

Les tickets sont acceptés via le panneau client et par e-mail à [email protected]. Le chat 24/7 (lorsqu'il est disponible, chargé paresseusement selon la documentation dans /features) est destiné aux demandes générales ; les problèmes de gravité Critique doivent toujours également être ouverts comme tickets pour assurer le suivi.

10. Comment demander des crédits

10.1 Fenêtre de demande

Les crédits de service doivent être demandés dans les trente (30) jours suivant l'incident donnant lieu au crédit. Les crédits non demandés dans cette fenêtre sont perdus.

10.2 Procédure de demande

Pour demander un crédit, envoyez un e-mail à [email protected] avec les informations suivantes :

• E-mail du compte et identifiant du Service concerné
• Date et heure de l'incident en UTC
• Motif de la demande (manquement à la disponibilité, manquement au provisionnement, manquement à la performance du réseau)
• Toutes données de surveillance externes que le client a corroborant l'incident

10.3 Traitement

Nous accusons réception des demandes dans les quarante-huit (48) heures. La résolution substantielle se termine généralement dans les sept (7) jours ouvrables. Les crédits approuvés sont appliqués à la prochaine facture ou, à la demande du client, versés sous forme de remboursement conformément à la section 4.2.

11. Fenêtres de maintenance

Les avis de maintenance sont publiés sur la page de statut sur /status et envoyés par e-mail à tous les clients concernés. La fenêtre d'avis standard est de quarante-huit (48) heures. La maintenance d'urgence — requise pour traiter un problème actif de sécurité ou de stabilité — peut être effectuée sans avis préalable ; dans ce cas, un post-mortem est publié sur la page de statut dans les cinq (5) jours ouvrables.

12. Modifications du présent SLA

Nous pouvons mettre à jour le présent SLA périodiquement. Les modifications importantes qui réduisent le niveau de service garanti au titre du présent SLA nécessitent un préavis de trente (30) jours selon la procédure de la section 15 des Conditions de service. Les modifications qui améliorent les engagements ou clarifient le langage prennent effet immédiatement à la publication. La date de « Dernière mise à jour » en haut de ce document reflète le changement le plus récent.