AWS IoT Core vous fournit un ensemble propre de briques de base. L’ingestion des appareils, un moteur de règles, un registre d’appareils, et le reste du catalogue AWS juste à côté. Pour un intégrateur de systèmes ou une petite équipe produit, la première preuve de concept est vraiment rapide. Vous branchez quelques appareils, vous faites passer des messages, vous les routez avec une règle, et vous avez de quoi faire une démonstration avant la fin de la semaine. On a l’impression d’avoir économisé le coût d’une plateforme gérée.
Puis la démonstration fonctionne, le client est content, et vous signez le contrat.
Mais la facture que personne n’avait mise sur la diapositive commence à arriver le mois suivant. Pas la facture AWS. Cette partie reste en général gérable. La facture, ce sont les années de travail d’exploitation que vous venez d’accepter. Authentification, dashboards, alertes, gestion des appareils, mises à jour de firmware, multi-locataire, mise à l’échelle, correctifs, supervision, astreinte, réponse aux incidents, et les preuves de sécurité et de conformité que vos clients finiront par réclamer. AWS vous a donné les pièces. Il ne vous a pas donné le produit, et il ne s’est pas engagé à faire tourner le produit à votre place.
Le geste honnête, avant de vous engager, consiste donc à chiffrer la vraie charge d’exploitation. Pas le coût de la démonstration de la première semaine. Le coût sur trois ans, en rôles, en heures et en responsabilité continue. Ensuite, vous décidez de construire ou d’acheter en connaissance de cause.
Ce que vous donne réellement AWS IoT Core
Il vaut mieux être précis sur l’endroit où s’arrête le service géré. AWS IoT Core couvre l’ingestion, un moteur de règles et un registre d’appareils. Ce sont des éléments réels et utiles. Ce sont aussi des briques brutes.
Un produit, ce ne sont pas des briques brutes. Un produit, c’est ce sur quoi votre client se connecte, ce en quoi il a confiance et ce qu’il paie chaque mois. Entre Core et ce produit s’intercale une longue liste de choses que vous construisez désormais et, surtout, que vous faites tourner.
Ce que vous maintenez quand vous construisez sur AWS
C’est la partie qui n’apparaît pas dans la preuve de concept. Chacun des éléments ci-dessous est quelque chose que vous assemblez une fois, puis que vous possédez pour toujours.
La couche applicative que vous devez construire
- Authentification et contrôle d’accès. Comptes utilisateurs, rôles, réinitialisation des mots de passe, gestion des sessions, et la piste d’audit derrière tout cela.
- Stockage des données. Choisir les magasins de données, modéliser les données, gérer la rétention, et surveiller le coût à mesure que le volume augmente.
- Dashboards. La couche visuelle que vos clients utilisent réellement. Ce n’est presque jamais un développement ponctuel. Cela change chaque fois qu’un client demande une nouvelle vue.
- Alertes et automatisation. Seuils, notifications, logique d’escalade, et les règles qui transforment des données brutes en action.
- Interface de gestion des appareils. Un moyen, pour des non-ingénieurs, de voir, de provisionner et de dépanner les appareils sur le terrain.
- Firmware et mises à jour OTA. Pousser des mises à jour vers les appareils en toute sécurité, avec un retour arrière quand une mise à jour tourne mal, parce qu’il y en aura une un jour.
- Multi-locataire. Maintenir les données et les utilisateurs d’un client proprement séparés de ceux d’un autre. C’est difficile à ajouter après coup et facile à rater de façon subtile.
Les opérations que vous devez faire tourner, tous les jours, pendant des années
- Mise à l’échelle. Quand un client ajoute dix mille appareils en un week-end, le système tient sans que vous ayez à le surveiller en permanence.
- Correctifs. Dépendances, images de base et bibliothèques qui ont besoin de mises à jour dès qu’une vulnérabilité est divulguée.
- Supervision. Savoir que quelque chose ne va pas avant que le client n’appelle.
- Astreinte et réponse aux incidents. Quelqu’un porte le bipeur. Quand l’ingestion se bloque à 2 h du matin, quelqu’un se réveille et corrige.
- Preuves de sécurité et de conformité. Quand un client grand compte envoie un questionnaire de sécurité, ou demande si vous êtes certifié, il vous faut des réponses et des preuves, pas des promesses.
Relisez cette liste en vous mettant à la place d’un intégrateur de systèmes avec une petite équipe. Chaque heure passée sur la plomberie de la plateforme est une heure non passée sur un client. La plateforme n’est pas ce pour quoi vos clients vous paient. C’est le plancher que vous devez bâtir et rebâtir sans cesse pour pouvoir faire le travail qu’ils veulent vraiment.
La réalité sur trois ans, mesurée en personnes
La façon honnête de dimensionner cela n’est pas en euros que vous ne pouvez pas encore connaître. C’est en rôles et en heures sur la durée du contrat.
Construire la couche applicative est un projet. La faire tourner est un travail qui ne s’arrête jamais. Sur un horizon de trois ans, c’est l’exploitation qui domine. Il vous faut des personnes capables d’assurer l’astreinte. Il vous faut quelqu’un qui prend en charge les correctifs et reste à jour sur les avis de sécurité. Il vous faut quelqu’un capable de répondre à un questionnaire de conformité sans une semaine d’improvisation. Dans une petite équipe, ce ne sont pas trois personnes. Ce sont les mêmes une ou deux personnes dont vous avez aussi besoin pour développer des fonctionnalités et servir les clients.
C’est là le piège. La plateforme ne tombe pas en panne bruyamment. Elle défaille comme un impôt lent sur l’équipe que vous avez déjà. La vitesse sur le travail client chute parce que les mêmes ingénieurs sont désormais aussi l’équipe d’exploitation, l’équipe de sécurité, et la première ligne de support quand le dashboard est lent.
Quand construire reste judicieux
Construire sur AWS n’est pas une erreur. Pour certaines équipes, c’est clairement le bon choix, et prétendre le contraire serait malhonnête.
Construisez quand la plateforme est votre produit principal et votre facteur de différenciation. Si ce que vous vendez est la plateforme, et si la manière dont vous ingérez, stockez et présentez les données est ce qui vous fait gagner face à vos concurrents, alors posséder chaque couche est précisément le but. L’externaliser reviendrait à externaliser votre avantage.
Construisez quand vous disposez d’une équipe d’ingénierie plateforme dédiée. Si vous pouvez constituer une équipe dont le seul travail est de faire tourner la plateforme, distincte des personnes qui servent les clients, la charge d’exploitation a un foyer. Elle cesse d’être un impôt sur le travail client.
Construisez quand vous avez des exigences strictes qu’aucun fournisseur géré ne satisfait. Des règles précises de résidence des données, un protocole inhabituel, un environnement isolé du réseau, une contrainte réglementaire qui exclut toute option clé en main. Si vous avez vraiment vérifié et que rien ne convient, construire est la réponse honnête.
Si aucun de ces cas ne vous décrit, la charge est réelle et elle est la vôtre.
Comment une plateforme gérée change le calcul
Pour une petite équipe qui ne correspond pas au cas de la construction, une couche applicative gérée change qui possède la longue liste ci-dessus.
C’est là que TagoIO trouve sa place. Elle s’installe comme une couche applicative gérée par-dessus l’ingestion et la connectivité des appareils, de sorte qu’une petite équipe livre des dashboards, des alertes, de la gestion des appareils et des API sans exploiter la pile sous-jacente. L’astreinte, les correctifs, la mise à l’échelle et la supervision passent à quelqu’un dont le travail à plein temps est de faire tourner cette plateforme. TagoIO est certifié ISO 27001 et aligné sur le RGPD, ce qui décharge aussi une partie des preuves de conformité que vous auriez sinon dû rassembler vous-même, dont certaines des réponses à ces questionnaires de sécurité des grands comptes.
Pour les intégrateurs en particulier, il y a un second angle. Grâce à TagoRUN, vous pouvez revendre ou proposer la plateforme en marque blanche, ce qui transforme la couche applicative : d’un centre de coûts que vous devez exploiter, elle devient une source de revenus récurrents sous votre propre marque. Cela renverse la question : non plus “comment se permettre de faire tourner ceci”, mais “comment vendre ceci”.
Rien de tout cela ne rend le cas de la construction faux. Cela signifie simplement que si votre avantage tient à vos clients plutôt qu’à votre infrastructure, acheter vous permet de consacrer vos heures là où se trouve l’argent.
Le résumé, sans détour
AWS IoT Core vous donne toutes les briques de base, et la première preuve de concept tient en une semaine. Mais la facture que personne ne budgète, ce sont les années d’astreinte, de correctifs, de mise à l’échelle, de multi-locataire et de support client que vous possédez désormais, payées avec le temps d’une équipe dont vous ne pouvez pas vous passer. Alors avant de vous engager, chiffrez la vraie charge d’exploitation en rôles et en heures sur trois ans, soyez honnête sur le fait de relever ou non du cas de la construction, et choisissez de construire ou d’acheter en connaissance de cause.
