Conditions proposées pour le lancement, pas encore en vigueur. L’identité de l’entreprise et les engagements propres aux services doivent être confirmés avant toute commande réelle. Les sections suivantes présentent le projet complet.
Sur cette page
1. Périmètre de l’accord
Ce cadre décrit l’évaluation de la disponibilité d’un serveur cloud Starcloud éligible et le traitement d’une réclamation d’incident. Un objectif contraignant, un délai de réclamation et un barème d’avoirs ne s’appliquent que s’ils sont expressément inclus dans la commande acceptée.
Le périmètre concerne le service de calcul fourni et son accès réseau associé. Il ne s’étend pas automatiquement à votre application, système, connexion internet ou logiciel tiers. Les services de démonstration sont exclus car ils ne créent pas d’infrastructure en production.
2. Disponibilité et indisponibilité éligible
Une indisponibilité éligible est une période vérifiée durant laquelle la fonction couverte du serveur ne peut pas être assurée en raison d’un problème relevant du service, après application des exclusions du barème accepté. Un échec de site web ou de connexion doit être examiné ; il ne prouve pas seul l’indisponibilité du serveur entier.
L’incident débute au premier instant étayé de la défaillance et se termine au rétablissement de la fonction couverte. Plusieurs observations d’une même interruption continue constituent un seul intervalle. Une même minute ne doit pas être comptée plusieurs fois lors d’incidents simultanés.
Un serveur arrêté, une IP bloquée ou une application refusant une connexion ne s’évaluent pas comme un hôte ou un chemin réseau indisponible. La cause et le composant touché doivent être documentés dans le résultat.
3. Calcul de la disponibilité mensuelle
Pour un mois de facturation couvert, la disponibilité est calculée ainsi : 100 × (minutes éligibles − minutes d’indisponibilité éligible) ÷ minutes éligibles. Les minutes éligibles correspondent au temps où le service était actif et couvert pendant le mois, en retirant uniquement les périodes expressément exclues de la mesure.
Utilisez un fuseau cohérent et distinguez les périodes partielles, doublons et interruptions simultanées. En l’absence de minute éligible, le pourcentage mensuel est sans objet. L’arrondi ne doit pas masquer le franchissement d’un seuil contractuel.
Les enregistrements de service, observations réseau et journaux du client doivent être examinés ensemble. Une sonde externe peut aider à établir la chronologie, mais un échec depuis un seul lieu peut provenir d’un problème hors périmètre. L’évaluation doit expliquer les divergences importantes.
4. Événements hors périmètre
Sous réserve du barème accepté et de la loi, les causes exclues peuvent comprendre votre instruction d’arrêt, une modification du système, une règle de pare-feu incorrecte, la perte d’identifiants, un logiciel malveillant dans votre application ou l’épuisement des ressources sélectionnées.
Une panne hors du réseau couvert, un logiciel tiers ou une restriction de service correctement autorisée peuvent aussi être hors périmètre. Une exclusion doit être liée à la cause et à la durée réelles, et non servir de motif général de rejet.
La maintenance, les attaques externes et les événements exceptionnels ne sont pas automatiquement des exclusions illimitées. Leur traitement doit figurer dans le barème applicable. Le fait qu’une dépendance soit exploitée par un autre fournisseur ne détermine pas, à lui seul, la couverture d’une panne.
5. Maintenance et information sur les incidents
Les travaux prévus susceptibles d’affecter le service doivent être annoncés par le canal disponible lorsque cela est possible. L’avis doit préciser le service concerné, la plage prévue et les actions éventuellement nécessaires de votre part.
Une intervention urgente peut être nécessaire sans préavis pour corriger un problème de sécurité actif ou éviter un dommage supérieur. Les mises à jour doivent distinguer estimation et rétablissement confirmé. Les délais de réponse et garanties de résolution sont des engagements distincts, applicables uniquement s’ils sont expressément inclus.
Le suivi public des incidents n’est pas encore disponible dans cette prévisualisation. Utilisez le portail d’assistance ; l’absence d’avis public ne prouve pas la disponibilité.
6. Signaler une interruption
Ouvrez un ticket dès que possible. Indiquez l’identifiant du service, le début et la fin avec fuseau horaire, la fonction touchée, les erreurs et les modifications récentes. Précisez si toutes les connexions sont concernées ou seulement un réseau ou une application.
Fournissez des journaux ou mesures concis que vous pouvez légalement partager. Retirez mots de passe, jetons, clés privées et données personnelles sans rapport. Conservez les originaux pour vérifier la chronologie. N’effectuez pas de test perturbateur sur une infrastructure partagée ou tierce.
7. Éligibilité et calcul des avoirs
Un avoir est dû lorsque la disponibilité vérifiée passe sous un objectif du barème accepté et que ses conditions de réclamation sont remplies. Le barème doit préciser les seuils, la base récurrente éligible, le maximum et le délai de dépôt avant de régir la commande. Ce projet ne fixe aucune garantie chiffrée ni tranche d’avoir.
La base doit se limiter au service couvert et à la période affectée, sans inclure des serveurs ou options sans rapport. Une même interruption ne doit pas donner lieu à des avoirs en double pour la même perte. Toute retenue ou limite doit respecter le barème et la loi.
Les avoirs s’appliquent aux frais futurs éligibles sauf disposition contraire des conditions acceptées. Ils ne suppriment aucun remboursement légal ni recours impératif. Un geste commercial ponctuel ne crée pas un nouvel engagement permanent de disponibilité.
8. Examen et résultat de la réclamation
Pour demander un avoir, identifiez le ticket d’incident et la période de facturation, décrivez l’interruption et joignez les éléments disponibles. L’examen doit confirmer le service couvert, les minutes éligibles, l’indisponibilité vérifiée, les exclusions et le calcul.
La décision doit expliquer l’éligibilité et le montant éventuel. Si un élément semble omis, répondez au même ticket en précisant l’écart. Les délais de réponse et de traitement sont ceux expressément inclus ou imposés par la loi ; ce projet ne promet pas de délai non vérifié.
9. Récupération et résilience des applications
La disponibilité diffère de la durabilité des données, de la rétention des sauvegardes et du délai de récupération applicatif. Un avoir ne promet pas la restauration d’un fichier ou d’un point de récupération précis. Les engagements de sauvegarde ou de reprise managée doivent être décrits séparément.
Conservez des sauvegardes indépendantes et un plan de récupération adapté aux usages importants. Un serveur unique n’est pas une architecture applicative redondante. Choisissez vos mesures de résilience selon l’impact d’une interruption et vérifiez la répartition des responsabilités.
Une question sur cette politique ?
Si vous disposez d’un compte, ouvrez un ticket avec la référence du service ou de la facture. Sinon, consultez les moyens disponibles sur la page Contact.