Personne ne choisit une plateforme IoT en prévoyant de la quitter. On la choisit pour livrer quelque chose et, plus elle permet de construire vite, plus elle s’installe profondément dans la pile : décodeurs d’appareils, dashboards, scripts d’automatisation, règles d’alerte, gestion des utilisateurs. Chaque pièce fait gagner des semaines. Mais chaque pièce est aussi un fil de dépendance, et ces fils forment un chiffre que personne ne vous annonce à la signature : le coût de la sortie.
Ce coût, c’est la dépendance fournisseur, et il reste invisible jusqu’à ce qu’une hausse de prix, un rachat ou une feuille de route à l’arrêt vous oblige à demander ce qu’une migration exigerait. La réponse se trouve sur quatre surfaces précises, et toutes les quatre se testent avant de signer quoi que ce soit.
Surface une : vos données et la façon dont elles sortent
Les données sont la surface évidente et pourtant la plus mal traitée, parce qu’elle se scinde en deux questions que l’on traite souvent comme une seule.
La première porte sur la propriété : le contrat dit-il clairement que les données sont les vôtres et que l’éditeur est un sous-traitant qui les traite pour votre compte ? La seconde porte sur la mécanique : pouvez-vous tout exporter, dans un format documenté, via une API qui ne bride pas les lectures en masse jusqu’à les rendre inutilisables ?
Un éditeur peut vous accorder la propriété sur le papier et retenir votre historique en pratique, car cinq ans de séries temporelles derrière un endpoint limité en débit, c’est une prise d’otage avec des étapes en plus. Dépassez la réponse marketing. Un vague “oui, vous pouvez exporter vos données” n’est pas la même chose qu’un export de masse documenté en CSV, JSON ou par lecture directe. Demandez si l’export couvre les payloads bruts des appareils ou seulement les valeurs agrégées que le dashboard affiche. Demandez les limites de lignes, les fenêtres temporelles, et le coût d’extraire des années de données d’un coup.
Nous avons traité la moitié contractuelle dans à qui appartiennent vos données IoT. La moitié mécanique se vérifie dans un compte d’essai, pas dans un rendez-vous commercial. C’est la surface à défendre le plus fermement, car c’est la seule qui empire à mesure que vous restez.
Surface deux : provisionnement des appareils et décodage des payloads
Vos appareils parlent binaire. Quelque part, du code transforme ces payloads en relevés de température et en états de porte, et l’endroit où vit ce code décide de la portabilité de votre parc.
Si les décodeurs sont une boîte noire dans la plateforme, chaque nouveau type d’appareil approfondit la dépendance, car migrer signifie réécrire une logique de décodage que vous ne voyez pas, modèle par modèle. Le provisionnement fonctionne pareil : si ajouter un appareil exige un outillage propriétaire sans équivalent par API, réenregistrer des milliers d’unités sur une autre plateforme devient un chantier manuel au lieu d’un script.
La couche transport compte autant. MQTT est le protocole ouvert courant pour la télémétrie : publié, largement implémenté, et votre appareil le parle de la même façon à n’importe quel courtier. Pour les réseaux de capteurs longue portée, LoRaWAN joue le même rôle, avec les couches network et application server définies par une spécification ouverte plutôt que par une entreprise. Un appareil qui parle MQTT nu, ou qui vit sur un réseau LoRaWAN standard, se repointe vers un nouvel endpoint par une simple configuration au lieu d’une visite sur site. Un appareil qui ne parle que le protocole propriétaire d’un éditeur, non, et reflasher un parc déployé n’est pas une migration, c’est un rappel produit.
Cherchez des décodeurs que vous pouvez lire et recopier, écrits dans un langage standard, et un provisionnement qui fonctionne de bout en bout via une API documentée.
Surface trois : logique applicative liée à des services propriétaires
C’est la surface que les équipes techniques sous-estiment. Les dashboards se reconstruisent en une semaine ; la logique derrière est le véritable investissement.
Les règles d’alerte, les tâches planifiées, les transformations de données et les intégrations tierces s’accumulent pendant des années et, si elles ont été écrites contre des abstractions propriétaires sans équivalent standard, elles constituent la part de la migration que vous réécrivez de zéro.
Vous ne pouvez pas supprimer cette surface, et vous ne devriez pas essayer, car une plateforme sans services natifs n’offre pas grand-chose. Ce que vous pouvez faire, c’est privilégier les plateformes où la couche logique est du code ordinaire, du JavaScript ou du Python que vous copiez dans un dépôt, plutôt qu’un comportement enfermé dans un constructeur visuel qui n’exporte rien. La question voisine est la couverture de l’API : si le seul moyen de faire entrer ou sortir des données passe par les écrans de l’éditeur, tout flux dont vous aurez besoin doit déjà exister comme fonctionnalité, sinon vous attendez une feuille de route.
Surface quatre : des conditions commerciales qui taxent la sortie
Les trois premières surfaces sont techniques. La quatrième est inscrite au contrat, et c’est souvent la plus tranchante.
Des frais de sortie facturant l’export au gigaoctet transforment votre propre historique en demande de rançon. Des durées pluriannuelles avec reconduction automatique et une fenêtre de résiliation de 90 jours signifient que la porte de sortie n’est ouverte que quelques semaines par an. Des remises conditionnées à l’exclusivité renchérissent le fait de faire tourner une seconde plateforme en parallèle, ce qui est précisément ainsi que se déroulent les migrations soignées. Une tarification par appareil qui punit la croissance appartient aussi à cette catégorie.
Rien de tout cela n’est caché. Cela figure dans le bon de commande et le contrat cadre, et l’erreur est de lire ces documents comme un achat et jamais comme une sortie. Demandez le délai de préavis, et si votre accès à l’export survit à la fin du contrat. Une fonction d’export que vous perdez le jour où l’abonnement expire n’est pas de la portabilité. Si vous revendez la plateforme, la même discipline s’applique un niveau plus bas, et c’est ce qu’un SLA de revente doit réussir.
Testez la sortie avant de signer
Toute démonstration de plateforme vous montre le chemin d’entrée. Votre travail pendant l’évaluation est de parcourir celui de la sortie, tant que votre position de négociation est la plus forte et votre volume de données le plus faible.
Ouvrez un compte d’essai, chargez quelques semaines de données réelles, puis menez un véritable exercice de sortie : exportez toutes les mesures via l’API publique, récupérez le décodeur d’un type d’appareil, et recréez une règle d’alerte en dehors de la plateforme. Chronométrez chaque étape, puis multipliez par la taille de votre parc de production. Si l’éditeur ne peut pas soutenir cet exercice à l’échelle d’un essai, vous avez votre réponse au prix le plus bas possible.
Profitez-en pour demander par écrit la tarification de sortie des données et les conditions de résiliation, car un chiffre annoncé au téléphone n’est pas une clause.
L’arbitrage honnête : de l’open source que vous hébergez
Si la dépendance est l’ennemi, l’option la moins captive est un logiciel open source que vous exploitez vous-même. ThingsBoard est le plus connu, et TagoCore est notre propre exécution open source en périphérie. Vous détenez le code, la base de données et le déploiement. Personne ne change vos conditions, ne retire votre offre ni ne retient vos données, puisque tout repose sur une infrastructure que vous maîtrisez.
Cette liberté a un prix, et il n’est pas en euros. Quand vous hébergez, vous possédez l’exploitation. Vous appliquez les correctifs, vous mettez la base à l’échelle quand le nombre d’appareils grimpe, vous gérez la panne de 3 heures du matin, vous portez la posture de sécurité. La dépendance supprimée est remplacée par une charge d’exploitation qui appartient désormais à votre équipe. Pour certaines organisations dotées de la profondeur technique et de l’appétit, c’est le bon arbitrage. Pour la plupart, non, et prétendre le contraire ne rend service à personne. La comparaison complète des coûts mérite d’être menée avant de trancher.
La vraie question n’est donc pas “géré ou open source”. Elle est : “quels types de dépendance j’accepte en échange du fait que quelqu’un d’autre exploite la plateforme”. Toute plateforme gérée porte une part de dépendance. L’objectif est de réduire les types coûteux, vos données et vos appareils, et d’accepter le reste comme le prix de ne pas exploiter d’infrastructure.
À quoi ressemble une portabilité honnête
Aucune plateforme ne peut promettre une sortie gratuite, et tout éditeur qui affirme un coût de changement nul vend quelque chose. Ce qu’une plateforme honnête peut faire, c’est garder ce coût proportionné, et la forme de cette honnêteté est reconnaissable :
- Des API à couverture complète, c’est-à-dire tout ce que fait l’interface disponible par programmation, de sorte qu’une sortie se scripte au lieu de se cliquer.
- Des protocoles standard aux extrémités, MQTT pour le trafic des appareils et LoRaWAN via des network servers ouverts, de sorte que les appareils se repointent plutôt qu’ils ne se reflashent.
- Des décodeurs sous forme de code visible et exportable.
- Un engagement écrit que les données sont les vôtres, avec un export sans frais punitifs.
Ce sont les positions sur lesquelles TagoIO se construit. TagoIO est une plateforme gérée, ce qui veut dire qu’elle n’a pas une dépendance nulle, et nous préférons le dire clairement que de l’enjoliver. Ce que nous faisons, c’est pousser la dépendance vers les types qui font le moins mal : la plateforme est entièrement accessible par API, les appareils se connectent via des protocoles standard dont MQTT et LoRaWAN, les payload parsers sont du JavaScript ordinaire que vous pouvez lire et copier, et la position sur la propriété des données est publiée plutôt que négociée contrat par contrat. La plateforme est multi-locataire et fait tourner TagoRUN pour les déploiements en marque blanche, elle est certifiée ISO 27001 et alignée sur le RGPD, et la même approche de protocoles ouverts s’étend à la périphérie via TagoCore, qui est open source si vous voulez exploiter cette partie vous-même.
Vous restez sur un service géré, et il subsiste un coût de changement si vous partez. Ce qui n’existe pas, c’est un format de données fermé ou un verrou de firmware qui transforme la sortie en reconstruction. Nous préférons être choisis de nouveau à chaque renouvellement plutôt que de retenir qui que ce soit.
Prochaines étapes
Avant de vous engager sur une plateforme IoT, passez-lui les quatre surfaces : format d’export et limites de débit, décodeurs et provisionnement, où vit la logique, conditions de sortie. Vérifiez ensuite les réponses sur la plateforme elle-même.
- Voyez comment fonctionnent la connectivité des appareils et les données sur TagoIO
- Lisez les détails d’API et d’intégration dans la documentation TagoIO
- Comparez les offres et les coûts par appareil sur les tarifs TagoIO
La dépendance n’est pas une raison d’éviter les plateformes. Tout construire soi-même ne fait que déplacer la dépendance vers son propre backlog. C’est une raison de chiffrer la sortie tant que poser la question reste bon marché. Réservez une démo ou commencez gratuitement et menez l’exercice de sortie sur nous.
