Accord de niveau de service (Service Level Agreement)

Le présent accord (le « SLA ») fait partie intégrante du contrat d'abonnement au service ArrMesh régi par les Conditions Générales d'Abonnement. Il définit les engagements de qualité de service de Atyos SAS (« Atyos ») et les crédits de service accordés en cas de manquement.

1. Champ d'application

1.1. Le SLA s'applique aux Formules Starter, Business et Enterprise. La Formule Free n'en bénéficie pas.

1.2. Un Bon de Commande Enterprise peut prévoir des engagements différents, qui prévalent alors sur le présent SLA.

2. Définitions

• Requête valide : toute requête HTTP adressée au Service par le Client, ses Utilisateurs ou ses applications, dont la syntaxe et les paramètres sont conformes à la documentation.
• Erreur imputable au Service : toute réponse HTTP de code 5xx renvoyée par le Service à une Requête valide. Les réponses 4xx (authentification invalide, requête mal formée, ressource introuvable, limitation de débit 429 liée au dépassement des quotas du Client) ne sont jamais comptées comme des erreurs imputables au Service.
• Intervalle : fenêtre de cinq (5) minutes consécutives.
• Taux de disponibilité d'un Intervalle : pourcentage de Requêtes valides de l'Intervalle n'ayant pas donné lieu à une Erreur imputable au Service. Un Intervalle sans trafic est réputé disponible à 100 %.
• Disponibilité mensuelle : moyenne arithmétique des Taux de disponibilité de tous les Intervalles d'un mois civil.
• Périmètre : l'un des trois sous-ensembles fonctionnels du Service définis à l'article 3, chacun soumis à un engagement propre.
• Redevance mensuelle : le montant hors taxes de l'abonnement correspondant au mois concerné ; pour un abonnement annuel, un douzième (1/12) du montant annuel. Les frais à l'usage n'entrent pas dans cette base.
• Crédit de service : remise accordée sur une facture ultérieure en cas de manquement à un engagement de disponibilité.

3. Engagements de disponibilité

3.1. Périmètre Authentification — 99,9 %

Couverture : gestion des sessions, émission et renouvellement des jetons, configuration des flux d'authentification — routes POST /login, POST /logout, POST /refresh, GET /auth_config — ainsi que l'autorisateur de l'API, qui se trouve sur le chemin critique de toutes les requêtes protégées.

Disponibilité mensuelle	Durée cumulée d'indisponibilité (approx.)	Crédit
< 99,9 % et ≥ 99,0 %	45 min à 7 h 10	10 % de la Redevance mensuelle
< 99,0 % et ≥ 95,0 %	7 h 15 à 36 h	25 % de la Redevance mensuelle
< 95,0 %	> 36 h	50 % de la Redevance mensuelle

3.2. Périmètre Collecte d'usage — 99,9 %

Couverture : ingestion en temps réel des événements de consommation — route POST /consumption.

Le traitement aval des événements (agrégation, calcul des consommations) est asynchrone et n'entre pas dans cet engagement ; il fait l'objet de l'engagement de fraîcheur de l'article 9.

Disponibilité mensuelle	Durée cumulée d'indisponibilité (approx.)	Crédit
< 99,9 % et ≥ 99,0 %	45 min à 7 h 10	10 % de la Redevance mensuelle
< 99,0 % et ≥ 95,0 %	7 h 15 à 36 h	25 % de la Redevance mensuelle
< 95,0 %	> 36 h	50 % de la Redevance mensuelle

3.3. Périmètre Application — 99,0 %

Couverture : l'ensemble des autres fonctionnalités de pilotage accessibles par l'API et la console : organisations, solutions, utilisateurs, rôles, permissions, politiques, webhooks, wallets, clés d'API, tags, licences, applications et consultation des consommations.

Disponibilité mensuelle	Durée cumulée d'indisponibilité (approx.)	Crédit
< 99,0 % et ≥ 95,0 %	7 h 15 à 36 h	10 % de la Redevance mensuelle
< 95,0 % et ≥ 90,0 %	36 h à 72 h	25 % de la Redevance mensuelle
< 90,0 %	> 72 h	50 % de la Redevance mensuelle

Les durées indiquées sont données à titre d'illustration pour un trafic régulier ; seule la Disponibilité mensuelle calculée selon l'article 4 fait foi.

4. Mesure de la disponibilité

4.1. Pour chaque Périmètre et chaque Intervalle :

Taux de disponibilité (Intervalle) = (Requêtes valides − Erreurs imputables au Service) / Requêtes valides × 100

puis :

Disponibilité mensuelle = moyenne des Taux de disponibilité de tous les Intervalles du mois civil

4.2. La disponibilité est mesurée par Atyos à partir des métriques de la passerelle d'API et des fonctions du Service. Le rapport mensuel de disponibilité est communiqué au Client sur demande.

5. Exclusions

Les engagements de l'article 3 ne s'appliquent pas aux indisponibilités résultant :

• d'une maintenance planifiée réalisée conformément à l'article 8 ;
• d'un cas de force majeure au sens des Conditions Générales ;
• d'une défaillance des équipements, réseaux ou fournisseurs d'accès du Client ou de tiers agissant pour son compte ;
• d'une action ou omission du Client ou de ses Utilisateurs (configuration erronée, suppression de données, usage non conforme à la documentation ou dépassement des quotas) ;
• d'une panne générale d'un service AWS sous-jacent dans la région concernée, reconnue par AWS, à condition qu'Atyos ait mis en œuvre les mesures de continuité prévues à l'article 10 ;
• d'une attaque externe (notamment par déni de service) malgré la mise en œuvre de mesures de protection raisonnables ;
• d'une suspension du Service conforme aux Conditions Générales (notamment pour défaut de paiement).

6. Support et gestion des incidents

6.1. Toutes les demandes de support, y compris les incidents critiques (P1), sont déposées exclusivement sur le portail de support https://help.arrmesh.ai, en indiquant leur priorité. Le Client et ses Utilisateurs habilités disposent d'un accès à ce portail.

6.2. Délais de prise en charge et de résolution cibles :

Priorité	Description	Prise en charge	Résolution cible
P1 — Critique	Un Périmètre est indisponible (taux d'erreur > 50 % pendant 15 minutes consécutives)	1 heure	4 heures
P2 — Majeur	Dégradation significative d'un Périmètre (taux d'erreur > 5 % pendant 30 minutes)	4 heures ouvrées	24 heures ouvrées
P3 — Mineur	Dégradation partielle, contournement possible	1 jour ouvré	5 jours ouvrés
P4 — Information	Question ou demande d'évolution	2 jours ouvrés	Selon planification

6.3. Les heures et jours ouvrés s'entendent du lundi au vendredi, de 9 h à 18 h (heure de Paris), hors jours fériés en France. Pour les Formules Business et Enterprise (support 24×7), les incidents P1 sont pris en charge 24 heures sur 24, 7 jours sur 7. Pour la Formule Starter (support 9×5), tous les délais sont décomptés en heures ouvrées.

6.4. Les délais de résolution sont des objectifs et ne donnent pas lieu à crédit de service.

7. Crédits de service

7.1. Pour bénéficier d'un crédit, le Client dépose une demande sur le portail de support https://help.arrmesh.ai, avec pour objet « Demande de crédit SLA — [Périmètre] — [mois concerné] », dans les trente (30) jours calendaires suivant la fin du mois concerné, accompagnée des éléments dont il dispose (horodatages, messages d'erreur, identifiants de requête).

7.2. Atyos confirme ou conteste la demande dans un délai de quinze (15) jours ouvrés, sur la base de ses mesures. Le crédit accepté est imputé sur la prochaine facture ; il n'est pas remboursable en numéraire, sauf à la fin du contrat.

7.3. Lorsqu'un même incident affecte plusieurs Périmètres, seul le crédit le plus élevé est accordé. Le total des crédits accordés au titre d'un même mois ne peut excéder 50 % de la Redevance mensuelle.

7.4. Les crédits de service constituent l'unique indemnisation du Client au titre de l'indisponibilité du Service, sauf faute lourde ou dolosive d'Atyos. Ils s'imputent sur le plafond de responsabilité prévu aux Conditions Générales.

8. Maintenance

8.1. Atyos peut réaliser des opérations de maintenance planifiée dans la limite de quatre (4) heures par mois, de préférence entre 22 h et 6 h (heure de Paris), après en avoir informé le Client par e-mail au moins quarante-huit (48) heures à l'avance.

8.2. Les maintenances d'urgence nécessaires pour corriger une faille de sécurité critique peuvent être réalisées sans préavis ; le Client en est informé au plus tard dans les vingt-quatre (24) heures. Elles sont prises en compte dans le calcul de la disponibilité.

9. Fraîcheur des données de consommation

Atyos s'efforce de rendre les événements de consommation ingérés disponibles dans les agrégats horaires dans un délai de deux (2) heures en fonctionnement normal. En cas de retard supérieur à quatre (4) heures consécutives, Atyos en informe le Client. Cet engagement est un indicateur de qualité suivi mensuellement ; il ne donne pas lieu à crédit de service.

10. Sauvegarde et reprise après sinistre

10.1. Le Service est exploité dans la région principale eu-west-3 (Paris, France), sur plusieurs zones de disponibilité. Les données persistantes sont répliquées vers la région de secours eu-central-1 (Francfort, Allemagne), activée uniquement en cas d'incident majeur affectant la région principale. La décision de bascule est prise par l'équipe d'exploitation d'Atyos. Les régions sont indiquées à titre informatif et peuvent évoluer dans les conditions prévues à l'article 7.2 du DPA ; les objectifs de reprise ci-dessous s'appliquent quelle que soit la région de secours utilisée.

10.2. Objectifs de reprise en cas de bascule vers la région de secours :

Données	Mécanisme	RPO (perte maximale)	RTO (délai de reprise)
Base de données métier	Sauvegardes automatiques et réplication inter-régions	< 1 heure	< 4 heures
Événements de consommation	Restauration à un instant donné et sauvegarde inter-régions	< 5 minutes	< 2 heures
Données analytiques	Versionnement et réplication inter-régions	< 24 heures	< 4 heures

[Vérifier que les mécanismes de réplication effectivement déployés permettent de tenir ces RPO/RTO avant publication.]

11. Révision

Le SLA peut être modifié dans les conditions prévues aux Conditions Générales (article 21). Toute révision défavorable au Client ouvre à celui-ci un droit de résiliation sans frais.

12. Contacts

• Support, y compris les incidents P1 : https://help.arrmesh.ai
• Atyos SAS — 18a Route de Paris, 67117 Ittenheim, France