La plupart des évaluations de plateforme se déroulent de la même façon. Un tableur avec une ligne par fonctionnalité, une ligne par limite, une ligne pour le prix, et quelque part en bas une ligne intitulée “support” remplie de valeurs comme “e-mail” ou “24/7” recopiées du tableau des plans. Les fonctionnalités et le prix méritent cette attention : les questions du guide d’achat les couvrent bien.
Le support n’a droit qu’à une ligne parce que personne ne sait l’évaluer de l’extérieur, et parce que pendant l’essai rien n’a encore cassé.
Puis les appareils partent sur le terrain. Huit mois plus tard, une mise à jour du firmware d’un gateway change un format de payload et 300 capteurs se mettent à écrire n’importe quoi, un samedi à 2 heures du matin. À cet instant, la liste des fonctionnalités ne sert à rien. Ce que vous achetez, c’est la personne qui répond, sa rapidité, et sa capacité à comprendre la couche appareil et pas seulement la plateforme. Le support dont vous disposez à cette heure-là a été décidé par des éléments que la page de tarifs ne vous a jamais montrés : qui assure la permanence du support, ce que “réponse” veut dire selon le niveau de gravité, et si vous pouvez vous débrouiller seul quand personne n’est réveillé.
Cet article porte sur la manière de découvrir tout cela pendant l’essai, quand vous avez encore du temps et le choix.
Qui répond, et que sait cette personne
Un “support 24/7” décrit un horaire, pas une compétence. La vraie question, c’est ce que sait la personne qui lit votre ticket. Il y a un monde entre un niveau de tri qui classe les tickets et réclame des captures d’écran, et un ingénieur qui a lui-même construit sur la plateforme et sait lire votre code de Payload Parser.
Le test : pendant l’essai, ouvrez un vrai ticket sur un vrai problème technique. Une question de décodeur fonctionne bien. Envoyez un payload brut, votre code de parser et la sortie erronée. Puis observez. Une première réponse qui vous demande quel navigateur vous utilisez vous apprend une chose. Une première réponse qui repère l’erreur d’offset d’octet vous en apprend une autre. Chronométrez la première réponse et le délai jusqu’à une réponse utile : ce sont deux chiffres différents, et c’est le second que vous subirez au quotidien.
Demandez sans détour si le support est assuré par les ingénieurs du fournisseur ou par un prestataire externe, et si les personnes qui répondent peuvent joindre celles qui écrivent la plateforme. Il vous faut un oui sur le second point, même si le premier est nuancé.
Des engagements de réponse par niveau de gravité, par écrit
La plupart des tableaux de plans annoncent un seul temps de réponse, quand ils en annoncent un. Les incidents n’ont pas tous la même taille. Un widget de dashboard qui s’affiche mal n’a rien à voir avec une ingestion de données en panne pour tous les appareils d’un site client, et un modèle de support qui les traite de la même façon promet trop sur les petits incidents, ou n’en fait pas assez sur les gros.
Ce qu’il faut, c’est une échelle de gravité : la définition de chaque niveau, l’engagement de réponse associé, les plages horaires concernées et le canal à utiliser. Demandez la procédure d’escalade par écrit : qui intervient quand le premier interlocuteur est bloqué, et comment vous déclenchez cette bascule. Un fournisseur incapable de décrire son escalade n’en a pas ; il a une file d’attente.
N’acceptez pas un “en général, nous répondons en moins d’une heure”. Un “en général” n’est pas un engagement, et l’incident qui vous coûte un client n’a, par définition, rien de général.
Aide sur la plateforme ou aide sur l’appareil
C’est là que la plupart des supports IoT déçoivent. Le fournisseur de la plateforme prend en charge la plateforme. Votre problème, lui, se situe dans l’appareil : un uplink LoRaWAN sur un port inattendu, une table de registres Modbus décalée d’une position, un décodeur qui marchait en firmware 2.1 et casse en 2.3. Les fournisseurs tracent la frontière du support à la limite de l’API, et tout ce qui se trouve en dessous devient “le problème de votre fabricant d’appareils”.
Repérez cette frontière avant d’en avoir besoin. Sur TagoIO, la couche appareil fait partie du produit : les Connectors et Networks décodent les payloads des modèles de capteurs publiés, et le Payload Parser est un endroit prévu pour corriger le décodage : une question de décodeur reste donc dans le périmètre au lieu d’en sortir. Quelle que soit la plateforme que vous évaluez, posez la question franchement : “Si mon parser produit de mauvaises valeurs, allez-vous regarder le parser ?”
Pouvez-vous vous débrouiller seul à minuit
Les tickets de support sont la voie lente. La voie rapide, c’est la documentation (TagoIO publie la sienne sur docs.tago.io), et sa qualité décide du nombre de tickets que vous aurez à ouvrir. Pendant l’essai, sautez le guide de démarrage. Lisez la documentation de votre cas d’usage précis : le type d’Action que vous prévoyez, le déclencheur d’Analysis dont vous avez besoin, la forme de la politique d’Access Management pour vos clients. Si la documentation répond à la question que vous vous posez vraiment, avec un exemple qui fonctionne, vous passerez la plupart de vos nuits sans ouvrir de ticket.
Autres vérifications en autonomie :
- Une page de statut publique avec un historique. Un point vert ne suffit pas : il vous faut le relevé des incidents passés, la façon dont ils ont été communiqués et leur durée. TagoIO en publie une sur status.tago.io.
- Une communauté où d’autres intégrateurs répondent. Celle de TagoIO est sur community.tago.io. Lisez les questions sans réponse avec autant d’attention que les autres : le rapport entre les deux vous dit si elle est vivante.
Ce qui change quand vous revendez
Si vous êtes intégrateur système et que vous hébergez vos propres clients sur un portail TagoRUN, la question du support est double. Vos clients vous appellent, vous, pas la plateforme. Vous êtes le premier niveau, que vous l’ayez prévu ou non, et le fournisseur de la plateforme est votre second niveau. Cela change ce que vous devez exiger de lui.
Demandez : puis-je ouvrir un ticket sur le problème d’un client et obtenir qu’il soit traité comme le mien ? Les Profiles que j’exploite pour mes clients ont-ils le même statut de support que les miens ? Quand je promets un temps de réponse à mon client, quel temps de réponse m’accordez-vous pour le tenir ? L’écart entre ces deux chiffres est votre risque, et la bonne volonté ne le comblera pas. L’article sur le SLA de revente explique comment structurer la promesse ; ici, le but est d’obtenir le chiffre en amont avant d’écrire celui en aval.
Vérifiez ce que votre plan comprend vraiment
Les niveaux de support suivent souvent les niveaux de plan, et l’essai tourne sur celui que le fournisseur a retenu pour les essais. Avant de signer, nommez le plan que vous allez réellement acheter et demandez par écrit le support qui va avec : canaux, plages horaires, engagements par niveau de gravité, et si l’escalade existe à ce niveau ou seulement au-dessus. Pour TagoIO, les conditions en vigueur figurent sur la page de tarifs et dans la documentation des plans de compte : lisez la version en ligne au moment où vous signez, pas un résumé issu d’un appel commercial.
Le plan de test pendant l’essai
À faire pendant l’évaluation, pas après :
- Ouvrez un vrai ticket sur un vrai problème de payload parser. Notez le délai de première réponse et le délai jusqu’à une réponse utile.
- Lisez la documentation de votre cas d’usage précis, pas le tutoriel. Notez ce qui manque.
- Lisez l’historique de la page de statut sur la dernière année.
- Cherchez dans la communauté votre modèle d’appareil et les fonctionnalités dont vous allez dépendre.
- Demandez par écrit les définitions des niveaux de gravité et la procédure d’escalade.
- Demandez ce que comprend le plan que vous allez acheter, et si le niveau utilisé pendant l’essai correspondait.
- Si vous revendez, demandez comment les tickets fonctionnent pour les problèmes de vos clients et quel temps de réponse vous pouvez répercuter.
Deux jours de ce travail vous en apprennent plus sur les trois prochaines années que n’importe quel comparatif de fonctionnalités. La plateforme qui gagne le tableur et perd le ticket de 2 heures du matin, c’est celle qui coûte cher, quoi qu’en dise la ligne du prix.
