AWS IoT Core vous donne un ensemble sérieux de briques de base : un broker MQTT géré, un registre d’appareils, des device shadows, et un moteur de règles qui achemine les messages vers le reste d’AWS. Et la tarification est honnête sur ce qu’elle couvre : vous payez par million de messages, par million d’opérations de registre, par million de règles déclenchées, sans frais minimum. Mais rien de tout cela n’est ce que vos utilisateurs ouvrent réellement chaque matin. Le dashboard, l’écran de connexion, l’alerte qui réveille quelqu’un à 3 heures du matin, l’application mobile, le fait qu’un client ne puisse pas voir les données d’un autre client, tout cela se situe au-dessus d’IoT Core et rien de tout cela ne vient avec. La vraie question n’est donc pas de savoir quel produit est meilleur. C’est de savoir si vous voulez construire et exploiter la couche applicative vous-même, ou en acheter une qui la possède déjà.
Ce qu’AWS IoT Core vous donne réellement
AWS décrit IoT Core comme un moyen de connecter des appareils et d’acheminer des messages vers des services AWS sans gérer l’infrastructure de connexion. Cette description est juste, et c’est tout l’intérêt. IoT Core prend en charge les parties qui sont vraiment difficiles à exploiter à grande échelle : un broker qui maintient des millions de connexions MQTT simultanées, l’identité des appareils et les certificats, le stockage du dernier état connu via les device shadows, et un moteur de règles qui transfère ou transforme les messages en route vers Lambda, S3, DynamoDB, Kinesis, ou toute autre destination.
C’est la couche de connectivité et d’ingestion. Elle est solide, et pour beaucoup d’équipes c’est exactement la bonne fondation. Ce qu’elle n’est pas, c’est une application sur laquelle vos clients se connectent.
Ce qu’il vous reste à construire par-dessus
Une fois les messages arrivés, le travail qui intéresse les utilisateurs commence à peine. Avec IoT Core comme socle, votre équipe est responsable de :
- Les dashboards. Aucune visualisation n’est fournie. Les équipes branchent généralement Amazon Managed Grafana avec OpenSearch comme source de données, ou assemblent Lambda, API Gateway, RDS et S3 dans un frontend sur mesure. Dans les deux cas, c’est à vous de le construire et de le styliser.
- Un modèle multi-tenant. Si vous servez plusieurs clients, vous concevez la façon dont leurs données restent séparées, dont les comptes correspondent aux appareils, et dont rien ne fuit d’une frontière à l’autre. IoT Core n’a pas de notion de tenant.
- La gestion des utilisateurs. Rôles, permissions, invitations et contrôle d’accès viennent d’IAM et de Cognito que vous configurez et maintenez, pas d’un système d’utilisateurs prêt à l’emploi.
- Les alertes et leur interface. Le moteur de règles peut déclencher une action. L’écran sur lequel un utilisateur non technique définit un seuil, choisit qui est notifié et passe en revue ce qui s’est déclenché, c’est vous qui le construisez.
- Une application mobile. Aucune application en marque blanche n’est fournie. Si vos clients en attendent une, c’est un projet à part.
Rien de tout cela n’est impossible. Beaucoup d’équipes le font bien. La partie honnête, c’est la deuxième facture : chacune de ces pièces devient ensuite quelque chose que vous possédez pour toujours. Vous la patchez, vous la faites monter en charge, vous restez d’astreinte pour elle, et vous payez les ingénieurs qui la maintiennent. La facture AWS est le petit chiffre. Les salaires, c’est le grand.
Quand AWS IoT Core est le bon choix
Cela mérite d’être dit clairement, parce que la réponse n’est pas toujours une plateforme gérée.
Choisissez AWS IoT Core quand vous avez une équipe d’ingénierie cloud capable de concevoir, construire et exploiter des systèmes distribués, et que vous voulez la voir passer son temps précisément là-dessus. Si votre organisation vit déjà dans la stack AWS, que votre data lake est sur S3, votre auth dans Cognito, votre compute sur Lambda et ECS, alors garder l’IoT dans ce même compte supprime des frictions et le travail d’intégration est réel mais contenu.
Choisissez-le quand vos besoins sont assez spécifiques pour qu’une plateforme sur étagère se mette en travers de votre chemin. Protocoles inhabituels, pipelines de données sur mesure, contraintes réglementaires qui exigent un contrôle précis de l’endroit et de la façon dont chaque octet circule, ou une échelle si grande que vous devez régler l’infrastructure directement. Tout en haut du spectre, le contrôle total vaut le coût d’ingénierie.
Et choisissez-le sans hésiter quand la plateforme elle-même est votre produit. Si vous construisez une plateforme IoT pour la vendre, vous ne devriez pas louer la couche qui définit votre différenciation. Vous la construisez, sur IoT Core ou ailleurs, parce que cette couche, c’est l’entreprise.
Si une ou plusieurs de ces situations vous décrivent, AWS IoT Core est une bonne réponse et une plateforme gérée vous gênerait. Soyez honnête avec vous-même sur le groupe auquel vous appartenez avant de décider.
Quand une plateforme gérée l’emporte
Pour la plupart des équipes dont le produit n’est pas la plateforme, le calcul penche dans l’autre sens. Vous avez des appareils, vous avez des clients, et vous avez besoin que ces clients regardent des données claires, reçoivent des alertes et gèrent leurs propres comptes, bientôt, sans recruter une équipe cloud pour construire une stack frontend à partir de pièces détachées.
Une plateforme gérée livre la couche applicative comme produit. Dashboards, séparation multi-tenant, gestion des utilisateurs et des permissions, interface d’alerte et portail prêt pour le mobile sont là dès le premier jour. Vos ingénieurs connectent les appareils et écrivent la logique propre à votre métier, au lieu de reconstruire la même couche applicative que reconstruit chaque entreprise IoT. Vous échangez un peu de contrôle bas niveau contre du temps, et pour la plupart des équipes le temps est la ressource la plus rare.
La place de TagoIO
TagoIO est la réponse “plateforme gérée” à cette décision. Elle prend en charge la connectivité et les données des appareils, et elle livre la couche que vous construiriez sinon par-dessus IoT Core. Les comptes multi-tenant font partie du modèle, pas une chose que vous architecturez. Dashboards, gestion des utilisateurs et alertes sont intégrés. TagoRUN vous donne des portails en marque blanche pour que vos clients voient votre marque, pas la nôtre. Les scripts Serverless Analysis permettent à votre équipe d’écrire une logique sur mesure sans monter et maintenir du compute. Et TagoCore, notre runtime edge open source, gère le traitement plus près de l’appareil quand vous en avez besoin.
Sur les points que les acheteurs soulèvent : TagoIO est certifié ISO 27001 et aligné GDPR, et propose plus de 500 intégrations d’appareils, de sorte que la plupart du matériel se connecte sans adaptateur sur mesure.
L’arbitrage est le même que celui nommé plus haut. Avec TagoIO, vous renoncez au contrôle direct de l’infrastructure sous-jacente en échange de ne pas construire ni exploiter la couche applicative. Si votre produit est la plateforme, cet arbitrage n’est pas le bon pour vous. Si votre produit est ce qui tourne par-dessus la plateforme, il est généralement le bon.
Étapes suivantes
Si vous voulez voir la couche applicative plutôt que la construire, commencez ici :
- Explorez la plateforme : tago.io
- Consultez le modèle de tarification : tago.io/pricing
- Lisez la documentation technique : docs.tago.io
La décision se résume à une question à laquelle vous pouvez répondre dès aujourd’hui : exploiter la couche applicative est-il le meilleur usage de votre équipe d’ingénierie, ou est-ce la partie que vous préféreriez acheter pour passer à la suite. Les deux réponses se défendent. Choisissez celle qui correspond à la vraie raison d’être de votre équipe.
