# Que mettre dans un SLA quand vous revendez une plateforme IoT

> Ce dont un SLA de revente a réellement besoin : la règle de répercussion, une définition de disponibilité qui tient, la durabilité séparée de la disponibilité, des niveaux de support tenables, des conditions de sortie et des modèles de clause à confier à votre juriste.

Quand vous revendez une plateforme IoT sous votre propre marque, le client signe l'accord de niveau de service avec vous et avec personne d'autre. Votre logo est sur les dashboards, votre nom est sur la facture, et c'est votre téléphone qui sonne quand les données s'arrêtent à 2 heures du matin. Mais ce n'est pas vous qui exploitez l'infrastructure, et ce seul fait impose la règle à laquelle chaque clause de votre SLA doit obéir : vous ne pouvez pas promettre à votre client plus que ce que la plateforme vous promet.

Chaque engagement que vous écrivez est soit couvert par un engagement en amont, soit absorbé par vous comme un risque non facturé. La plupart des SLA de revente échouent parce qu'ils ont été copiés de modèles rédigés pour des entreprises qui possèdent leurs serveurs. Le vôtre doit se construire dans l'autre sens, à partir du document que votre fournisseur vous remet.

![SLA en miroir : en haut le SLA de la plateforme, au milieu l'écart de risque qui vous appartient et qu'il faut chiffrer, en bas votre SLA envers le client](/images/blog/sla-reselling-iot-platform/sla-back-to-back-stack.svg)

## Le problème de la répercussion

Posez le SLA du fournisseur sur le bureau avant d'écrire un mot du vôtre. Si la plateforme s'engage sur 99,9 pour cent de disponibilité et que vous promettez 99,95 à un client, vous avez personnellement pris la différence à votre charge : environ 21 minutes d'exposition chaque mois, sans infrastructure à réparer et sans aucun avoir en amont quand cela casse.

Assumer cet écart volontairement, en le chiffrant dans votre tarif, peut être une décision commerciale légitime, et [la façon dont vous tarifez le service géré](https://tago.io/blog/how-to-price-an-iot-managed-service) est le lieu où cette décision se tranche. L'assumer parce que personne n'a fait la soustraction, c'est ainsi que des revendeurs finissent par payer des avoirs de service sur leur propre marge.

C'est aussi pour cela que le SLA du fournisseur appartient à votre grille de choix de plateforme. TagoIO publie son SLA sur [tago.io/sla](https://tago.io/sla) et détient la [certification ISO 27001](https://tago.io/blog/tagoio-iso-27001-certification), ce qui donne au revendeur une base auditée sur laquelle bâtir plutôt qu'une assurance verbale. Si vous choisissez encore votre socle, les [plateformes que les intégrateurs revendent réellement](https://tago.io/blog/best-iot-platforms-system-integrators-resell) sont celles qui publient leurs chiffres.

## Définissez la disponibilité avant de la promettre

Un pourcentage de disponibilité sans définition est un ornement. Trois paramètres lui donnent un sens.

La fenêtre de mesure d'abord. 99,9 pour cent mesuré mensuellement autorise environ 43 minutes d'indisponibilité par mois, alors que le même chiffre mesuré annuellement laisse une seule panne brutale de huit heures se dissoudre dans onze mois tranquilles. Le mois est la fenêtre honnête.

Deuxièmement, ce qui compte comme panne : la coupure totale seulement, ou aussi le service dégradé ? Si l'API répond en 30 secondes au lieu de 300 millisecondes, votre client vit une panne, que votre définition l'admette ou non.

Troisièmement, qui mesure et comment cela remonte. Un engagement que le client ne peut pas vérifier nourrit les litiges : nommez donc la source de supervision et engagez-vous à signaler les incidents plutôt qu'à attendre la question. La détection indépendante est aussi ce qui permet de [gérer une panne de plateforme en tant que prestataire de service géré](https://tago.io/blog/handle-iot-platform-downtime-managed-service) au lieu de l'apprendre de votre propre client.

## La durabilité des données n'est pas la disponibilité

Ces deux notions sont sans cesse confondues, et ce sont des promesses différentes aux enjeux différents. La disponibilité, c'est si le service répond maintenant. La durabilité, c'est si les données survivent.

Une plateforme peut être indisponible une heure sans rien perdre, et votre client reçoit des excuses et un avoir. Une donnée perdue est une autre catégorie de défaillance, souvent irrécupérable et parfois un manquement à la conformité.

Votre SLA doit porter un texte distinct pour chacune : un pourcentage de disponibilité avec les définitions ci-dessus, et une clause de durabilité couvrant la durée de conservation, la fréquence des sauvegardes et le sort des données mises en tampon pendant une panne. Posez directement la question du tampon à votre fournisseur, car le comportement de l'ingestion pendant une indisponibilité est l'endroit où la durabilité devient discrètement un problème de disponibilité.

## Niveaux de support : engagez-vous sur la réponse, visez la résolution

Le délai de réponse, c'est la vitesse à laquelle une personne qualifiée prend le dossier. Cela se pilote par les effectifs, alors engagez-vous fermement. Le délai de résolution dépend de l'endroit où se situe la panne, et quand elle est dans la plateforme, la correction se fait dans une infrastructure que vous n'exploitez pas. Gardez la résolution comme objectif annoncé.

Rattachez les deux à la gravité. Un incident de gravité 1, service coupé pour tous les utilisateurs, peut porter une réponse en une heure 24 heures sur 24 et un objectif de rétablissement de quatre heures. La gravité 2, dégradé mais fonctionnel, obtient une réponse en quatre heures ouvrées. La gravité 3 couvre les questions et défauts mineurs en un jour ouvré.

Fixez des chiffres que votre équipe tient pendant une mauvaise semaine, car un engagement manqué chaque mois coûte plus de confiance qu'un engagement jamais pris. Écrire les limites est aussi ce qui rend le support tenable quand vous [dépassez dix clients](https://tago.io/blog/scale-iot-integrator-business-beyond-10-customers).

## Fenêtres de maintenance et conditions de sortie

La maintenance planifiée annoncée à l'avance sort du calcul de disponibilité, et vos fenêtres annoncées doivent tenir à l'intérieur de celles de votre fournisseur, pour que sa maintenance ne compte jamais contre vous. Engagez-vous sur 72 heures de préavis ou plus.

Les conditions de sortie sont les clauses dont les acheteurs se souviennent. Indiquez que le client peut exporter ses données dans un format documenté et lisible par machine pendant le contrat et à sa fin, fixez le délai et fixez le coût, idéalement nul. Sur une plateforme dotée d'API complètes, cette clause ne coûte presque rien à honorer, et elle emporte des affaires face à des concurrents dont le silence sur la sortie dit tout. Ignorer le coût de sortie jusqu'à la sortie fait partie des [erreurs les plus chères commises par les intégrateurs](https://tago.io/blog/biggest-mistakes-system-integrators-iot-platforms), et la même question est au centre de la [dépendance au fournisseur](https://tago.io/blog/vendor-lock-in-in-iot-platforms).

## Modèles de clause à adapter

Ce sont des tournures à confier à votre juriste, pas un conseil juridique. Quelques formes qui fonctionnent :

"Le Pourcentage Mensuel de Disponibilité désigne le total des minutes du mois civil, moins les minutes d'Indisponibilité, divisé par le total des minutes du mois. La Maintenance Planifiée annoncée au moins 72 heures à l'avance est exclue de l'Indisponibilité."

"Les incidents de gravité 1 reçoivent une réponse d'un intervenant qualifié dans l'heure suivant le signalement, 24 heures par jour, sept jours par semaine. Les objectifs de rétablissement sont des cibles, non des garanties."

"Les données du Client restent la propriété du Client. Dans les 30 jours suivant la résiliation, le Prestataire met l'ensemble des données du Client à disposition pour export dans un format documenté et lisible par machine, sans frais supplémentaires."

"Les avoirs de service sont calculés en pourcentage de la redevance mensuelle, plafonnés à 100 pour cent d'une mensualité, et constituent le seul recours en cas de défaut de disponibilité."

## Construisez-le en miroir

La méthode est mécanique. Placez le SLA du fournisseur et votre brouillon côte à côte et, pour chacune de vos clauses, inscrivez le nom de la clause amont qui la couvre ou la marge qui la chiffre. Ce qui n'a ni l'une ni l'autre est un cadeau à votre client.

Reprenez cet appariement chaque année, car les conditions de votre fournisseur, vos effectifs et la taille de votre parc bougent tous. C'est aussi le document qui change quand vous passez [de projets ponctuels à des services récurrents](https://tago.io/blog/from-one-time-iot-projects-to-recurring-services), puisqu'un abonnement est une promesse qui se renouvelle chaque mois.

L'écart entre ce que vous recevez et ce que vous promettez ne disparaît jamais. Un bon SLA le réduit, le chiffre, et ne met votre nom que sur ce que vous maîtrisez. Partez d'une base publiée : le SLA de TagoIO est sur [tago.io/sla](https://tago.io/sla). [Réservez une démo](https://tago.io/request-demo) ou [commencez gratuitement](https://admin.tago.io).