Chaque projet IoT commence par un choix de plateforme qui semble réversible. Vous choisissez un fournisseur, vous connectez quelques appareils, vous construisez un dashboard, et vous livrez. Deux ans plus tard, vous avez dix mille appareils qui remontent des données, un firmware sur mesure lié à un seul cloud, et trois ans d’historique impossible à récupérer sous une forme exploitable. La décision n’a jamais été réversible. Elle en avait simplement l’air au départ, et c’est précisément dans cet écart entre la perception et la réalité que vit la dépendance fournisseur.
La dépendance n’est pas un piège unique. Il y en a quatre distincts, et la plupart des acheteurs n’en vérifient qu’un seul avant de signer. Cet article décortique chacun d’eux, vous donne la question concrète à poser à un fournisseur pour le tester, et reconnaît honnêtement que la seule façon d’atteindre une dépendance quasi nulle est d’assumer un travail dont vous ne voulez peut-être pas.
La dépendance aux données est la plus coûteuse
Votre historique de données est l’actif qui grossit chaque jour et la chose la plus difficile à déplacer. Si une plateforme stocke votre télémétrie dans un format propriétaire et ne vous laisse la relire qu’à travers son propre dashboard, vous ne possédez pas vraiment ces données. Vous pouvez les voir. Vous ne pouvez pas partir avec.
La question test : “Puis-je exporter l’intégralité de mes données brutes historiques, et dans quel format ?” Allez au-delà de la réponse marketing. Un vague “oui, vous pouvez exporter vos données” n’a rien à voir avec un export en masse documenté vers CSV, JSON, ou une lecture directe de la base de données. Demandez si l’export couvre les payloads bruts des appareils ou seulement les valeurs agrégées que le dashboard affiche. Demandez s’il y a une limite de lignes ou une fenêtre temporelle. Demandez combien coûte l’extraction de plusieurs années de données d’un coup, car pour de gros volumes le transfert et le temps d’ingénierie pour les remettre en forme peuvent devenir la vraie facture.
La dépendance aux données est celle contre laquelle il faut se battre le plus, car c’est la seule qui empire au fil du temps que vous restez.
La dépendance aux appareils et aux protocoles décide si votre matériel peut voyager
Si une plateforme exige son propre firmware, son propre SDK, ou un protocole de transport fermé pour mettre un appareil en ligne, votre matériel est marié à cette plateforme. Changez de cloud et vous reflashez chaque unité sur le terrain, ce qui, sur une flotte déployée, n’est pas une migration mais un rappel.
La question test : “Mon appareil se connecte-t-il via des standards ouverts, ou ai-je besoin de votre firmware ?” Les protocoles ouverts sont ce qui garde les appareils portables. MQTT est le plus courant pour la télémétrie : il est publié, largement implémenté, et votre appareil le parle de la même façon avec n’importe quel broker. Pour les réseaux de capteurs longue portée, LoRaWAN joue le même rôle, avec les couches réseau et serveur d’application définies par une spécification ouverte plutôt que par une seule entreprise. Un appareil qui parle du MQTT standard ou qui se trouve sur un réseau LoRaWAN standard peut être redirigé vers un nouveau endpoint par un simple changement de configuration au lieu d’une intervention sur le terrain. Un appareil qui ne parle que le protocole propriétaire d’un fournisseur ne le peut pas.
La dépendance à l’intégration concerne votre capacité à construire autour de la plateforme
Une plateforme que vous ne pouvez pas scripter est une plateforme que vous ne pouvez pas dépasser. Si la seule façon d’entrer ou de sortir des données passe par les écrans du fournisseur, chaque workflow dont vous aurez besoin doit déjà exister comme fonctionnalité, sinon vous restez à attendre une roadmap.
La question test : “Existe-t-il une API REST documentée qui couvre tout ce que fait le dashboard, ou seulement une partie ?” La version honnête de cette question compte. Beaucoup de plateformes ont une API qui lit les données mais ne peut pas provisionner un appareil, ou une qui gère les appareils mais pas les utilisateurs. Vous voulez une couverture complète : créer des appareils, pousser et tirer des données, gérer les utilisateurs, configurer ce que vous cliqueriez autrement. Si l’API n’est qu’un sous-ensemble du produit, le reste du produit est un mur.
La dépendance contractuelle est celle écrite en clair
La dernière n’a rien de technique. C’est la durée d’engagement, la clause de reconduction automatique, la tarification par appareil qui punit la croissance, et le niveau de support que vous devez acheter pour garder le service en marche. Rien de tout cela n’est caché. C’est dans le contrat, et c’est pour ça que c’est le plus facile à vérifier et le plus souvent oublié.
La question test : “Quel est le préavis pour partir, et mon accès à l’export survit-il à la fin du contrat ?” Une fonction d’export que vous perdez le jour où votre abonnement expire n’est pas de la portabilité. Lisez les conditions de sortie avant celles d’arrivée.
L’arbitrage honnête : l’open source que vous hébergez vous-même
Si la dépendance est l’ennemi, l’option qui en génère le moins est un logiciel open source que vous exécutez vous-même. ThingsBoard est le plus connu, et TagoCore est notre propre runtime edge open source. Vous détenez le code, la base de données et le déploiement. Personne ne peut modifier vos conditions, déprécier votre forfait, ni retenir vos données, car tout repose sur une infrastructure que vous contrôlez.
Cette liberté a un prix, et il ne se compte pas en dollars. Quand vous hébergez vous-même, vous possédez l’exploitation. Vous patchez les serveurs, vous faites évoluer la base de données 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 que vous avez supprimée est remplacée par une charge opérationnelle qui appartient désormais à votre équipe. Pour certaines organisations dotées de la profondeur d’ingénierie et de l’appétit nécessaires, c’est le bon arbitrage. Pour la plupart, ce ne l’est pas, et prétendre le contraire ne rend service à personne.
La vraie question n’est donc pas “géré ou open source”. C’est “quels types de dépendance suis-je prêt à accepter en échange du fait que quelqu’un d’autre exploite la plateforme”. Toute plateforme gérée comporte une part de dépendance. C’est la nature même d’un service géré. L’objectif est de minimiser les types coûteux, vos données et vos appareils, et d’accepter le reste comme le prix de ne pas exploiter d’infrastructure.
Où se situe TagoIO
TagoIO est une plateforme gérée. Cela signifie qu’il y a une part de dépendance, et nous préférons le dire clairement plutôt que de l’enjoliver. Ce que nous faisons, c’est ramener la dépendance vers les types qui font le moins mal.
Pour les données, TagoIO permet d’exporter vos données, pour que votre historique ne vive pas dans une boîte à sens unique. Pour les appareils, il parle MQTT et fonctionne avec les données d’appareils LoRaWAN standard, pour que votre matériel ne soit pas lié à un firmware propriétaire afin de communiquer avec nous. Pour l’intégration, il existe une API REST complète qui couvre ce que fait la plateforme, pour que vous puissiez construire, provisionner et automatiser autour d’elle au lieu d’attendre une demande de fonctionnalité. La plateforme est multi-tenant et fait tourner TagoRUN pour les déploiements en marque blanche, elle est certifiée ISO 27001 et alignée sur le GDPR, et la même approche par protocoles ouverts s’étend à l’edge via TagoCore, qui est open source si vous voulez exploiter cette partie vous-même.
Vous êtes toujours sur un service géré, et il y a toujours un coût de migration si vous partez. Ce qu’il n’y a pas, c’est un format de données fermé ou un verrou firmware qui transforme le départ en reconstruction.
Les prochaines étapes
Avant de vous engager sur une plateforme IoT, confrontez-la aux quatre questions test : format d’export, protocoles ouverts, API complète, conditions de sortie. Puis vérifiez 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 sur l’API et l’intégration dans la documentation TagoIO
- Comparez les forfaits et les coûts par appareil sur la tarification TagoIO
Une plateforme qui répond clairement aux quatre questions est une plateforme que vous pouvez quitter. C’est exactement pour ça que vous devriez vous sentir en sécurité d’y rester.
