Ce que nous vous devons quand nous vous facturons.
SLA en langage clair. Objectifs d'uptime réels par plan, temps de réponse par sévérité, politique de crédit en cas d'échec, et les exclusions.
Voir le statut en direct →Uptime, réponse, crédit en cas d'échec.
| Plan | Uptime | Première réponse | Réponse S1 | Crédits en cas d'échec |
|---|---|---|---|---|
| Builder | 99,5% best-effort | ≤ 2 jours ouvrés | Best-effort | — |
| Pro | 99,9% objectif | ≤ 1 jour ouvré | ≤ 4 heures | 10% de crédit sur le mois en échec |
| Max | 99,9% garanti | ≤ 4 heures en horaires de bureau | ≤ 2 heures | 25% de crédit sur le mois en échec |
| Team | 99,9% objectif | ≤ 1 jour ouvré | ≤ 4 heures | 10% de crédit sur le mois en échec |
| Business | 99,95% garanti | ≤ 2 heures en horaires de bureau | ≤ 1 heure 24×7 | Jusqu'à 50% de crédit + DPA / SLA sur mesure |
Comment nous triajeons les incidents.
- S1 — Critique
La production est down pour la majorité des utilisateurs. Pas de workaround. Login cassé, génération en échec pour tous, ou intégrité des données à risque.
Immédiat, 24×7 sur Business - S2 — Majeur
Dégradation significative. Certains utilisateurs touchés, workaround existant, données saines.
Même jour ouvré sur Pro+ - S3 — Mineur
Cosmétique, isolé, ou touchant un petit sous-ensemble.
Jour ouvré suivant - S4 — Question / demande de fonctionnalité
Pas un défaut. Routé à l'équipe concernée.
Sous 1 semaine
Fenêtre de maintenance
La maintenance planifiée a lieu le dimanche 02:00–05:00 UTC, au plus une fois par trimestre hors urgence. Les notifications partent vers status.vulk.dev au moins 48 heures à l'avance, ainsi qu'aux abonnés e-mail.
Politique de crédit
Quand nous manquons l'objectif d'uptime sur un mois calendaire, les plans éligibles reçoivent automatiquement un crédit sur la facture suivante — pas besoin d'ouvrir un ticket. Les crédits ne sont pas remboursables en cash mais peuvent être appliqués à toute facture actuelle ou future sur le même compte.
Ce qui n'est pas couvert.
Le SLA ne s'applique pas à :
- ▸Force majeure (pannes régionales de cloud provider, action réglementaire, etc.).
- ▸Incidents induits par le client (mauvaise configuration, crédits de plan épuisés, limites de débit dépassées).
- ▸Maintenance planifiée annoncée ≥ 48h à l'avance via status.vulk.dev.
- ▸Problèmes causés par des providers IA tiers que nous routons, lorsque le provider est la cause racine.
- ▸Fonctionnalités beta clairement marquées comme telles dans l'UI / les docs.