La plupart des budgets IoT se construisent de la même façon. Quelqu’un compte les appareils, chiffre un capteur, ajoute un forfait SIM, multiplie par la taille de la flotte, puis gonfle le chiffre de vingt pour cent par sécurité. Le conseil d’administration voit un montant propre. Le projet est approuvé. Tout le monde est content.
Ce chiffre est presque toujours faux. Non pas parce que le prix du capteur est erroné, mais parce que le capteur est l’un des éléments les moins chers de l’ensemble.
Si vous êtes chef de projet responsable d’un résultat IoT, les coûts qui font exploser votre budget ne figurent pas sur la facture du matériel. Ce sont les coûts que personne ne vous annonce au départ, parce qu’ils se cachent dans les heures d’ingénierie, dans des frais de plateforme qui augmentent avec l’usage, et dans le lent goutte-à-goutte de la maintenance après le lancement. Cet article est une cartographie complète du coût total de possession. Je veux que vous puissiez défendre votre budget ligne par ligne, et savoir exactement où une plateforme gérée supprime des coûts et où elle ne le fait pas.
La partie que tout le monde budgète
Commençons par l’argent facile, la partie que vous maîtrisez déjà.
Le matériel est concret et visible. Un déploiement pour le marché intermédiaire peut compter de quelques centaines à quelques milliers d’appareils. Vous chiffrerez le capteur ou le gateway, vous chiffrerez la SIM ou le module de connectivité, et vous obtiendrez des devis raisonnablement précis auprès des fournisseurs. Il peut y avoir un surcoût pour des boîtiers renforcés ou des certifications spécifiques, mais le matériel est une quantité connue. Vous pouvez demander trois devis et en choisir un.
La connectivité par appareil paraît modeste à l’échelle unitaire. Quelques dollars par mois et par SIM, ou un forfait fixe pour un plan LoRaWAN ou NB-IoT. Les chefs de projet chiffrent cela correctement par appareil.
Ces deux lignes sont l’endroit où la plupart des budgets cessent d’être exacts. C’est la pointe visible. Sous la ligne de flottaison, c’est là que les projets coulent.
Les coûts dont personne ne vous prévient
Voici la liste inconfortable. Chacun de ces postes est réel, récurrent ou ponctuel, et systématiquement omis du premier budget.
Frais de plateforme et d’ingestion
Vos appareils envoient des données quelque part. Ce quelque part coûte de l’argent, et il évolue généralement avec le nombre de messages, pas avec le nombre d’appareils. Un appareil qui transmet toutes les quinze minutes envoie environ 2 880 messages par jour. Sur mille appareils, cela représente près de trois millions de messages par jour. Une tarification qui évolue par message ou par point de données peut croître plus vite que votre parc d’appareils, car dès que quelqu’un demande des « relevés plus fréquents », votre volume d’ingestion bondit sans qu’un seul nouvel appareil ne soit installé.
C’est un coût récurrent. Budgétez-le au mois, et budgétez-le sur votre intervalle de transmission réel, pas sur celui de la démo.
Décodage du payload et ingénierie d’intégration
C’est la ligne qui surprend le plus les gens. Votre appareil n’envoie pas des données propres et étiquetées. Il envoie un payload binaire compact, souvent en hexadécimal, conçu pour garder la transmission radio courte et la durée de vie de la batterie longue. Quelqu’un doit écrire du code qui transforme ce payload en « température : 4,2 degrés, batterie : 87 pour cent, porte : ouverte ».
Ce quelqu’un est un ingénieur, et chaque modèle d’appareil a une structure de payload différente. Changez de fournisseur, ajoutez un nouveau type de capteur, ou recevez une mise à jour de firmware qui modifie l’ordre des octets, et vous repayez ce travail. Vient ensuite l’intégration dans l’autre sens, qui consiste à pousser vos données dans les systèmes sur lesquels votre entreprise fonctionne réellement, l’ERP, la GMAO, le système de tickets, la plateforme de facturation. Chaque intégration est de l’ingénierie sur mesure, et le travail d’intégration est l’endroit où les délais glissent discrètement de plusieurs semaines.
Il s’agit surtout d’un coût ponctuel par type d’appareil et par intégration, avec une traîne de maintenance récurrente.
Construction du dashboard et de l’application
Les données doivent devenir quelque chose qu’un humain regarde et sur quoi il agit. Un dashboard, une règle d’alerte, un rapport, une vue mobile pour le technicien sur le terrain. C’est un vrai travail produit. C’est du design, c’est du frontend, ce sont les allers-retours du genre « peut-on aussi afficher la tendance de la semaine dernière ». Sous-budgéter ici est fréquent parce que cela ressemble à la partie facile. Ce n’en est pas une. L’application est la partie que vos utilisateurs touchent réellement, et c’est celle qu’ils vous demanderont de modifier chaque mois.
La connectivité à grande échelle
La connectivité est bon marché par appareil et coûteuse en cumul. Au-delà du coût par SIM, il y a la question de ce qui se passe quand mille appareils tentent tous de se reconnecter après une coupure réseau, ou quand votre volume de données franchit un palier et que votre tarif change. Les fournisseurs de connectivité ont des paliers et des frais de dépassement. À petite échelle, vous ne les voyez jamais. À l’échelle du marché intermédiaire, vous les verrez.
Transfert de données sortant
Celui-ci se cache bien. Sortir des données d’un cloud, les déplacer entre régions ou vers un système tiers entraîne souvent des frais de transfert sortant par gigaoctet. C’est invisible pendant un pilote avec dix appareils. Avec une flotte complète qui transmet en continu, le transfert sortant devient une ligne que vous remarquez vraiment sur la facture mensuelle.
Maintenance et support continus
Un logiciel n’est jamais terminé. Correctifs de sécurité, mises à jour de bibliothèques, changements d’API de votre fournisseur de connectivité, un nouveau modèle d’appareil à intégrer, une règle d’alerte à affiner. Si vous avez construit la stack vous-même, c’est le temps de votre équipe d’ingénierie, pour toujours. Si quelque chose casse à 2 heures du matin, quelqu’un est d’astreinte. La maintenance est le coût récurrent le plus sous-estimé de l’IoT, car au moment du budget le système n’existe pas encore et personne ne pense à l’année deux.
Le temps du personnel
Chaque heure que votre équipe passe sur la stack IoT est une heure qu’elle ne passe pas sur le produit que votre entreprise vend réellement. Un chef de projet qui coordonne, un ingénieur qui décode des payloads, un responsable des opérations qui surveille des dashboards. C’est un coût réel même quand il n’apparaît pas sous forme de facture, et c’est le coût sur lequel votre équipe financière vous interrogera quand elle verra les effectifs.
Les paliers de montée en charge
Les coûts dans l’IoT ne sont pas linéaires. Ils font des sauts. Vous ajoutez le centième appareil et rien ne change. Vous ajoutez le millième et soudain il vous faut un niveau de base de données plus important, un load balancer, une deuxième région, un contrat de support dédié. Ces paliers arrivent sans prévenir et généralement au pire moment, juste quand le projet réussit et que la direction veut l’étendre.
Ponctuel contre récurrent, en termes simples
Triez les coûts en deux catégories et le tableau devient plus clair.
Coûts ponctuels : matériel, décodage initial du payload par type d’appareil, première construction de chaque intégration, première construction du dashboard et de l’application, et la mise en place et la configuration de la plateforme.
Coûts récurrents : connectivité par appareil, frais de plateforme et d’ingestion, transfert de données sortant, maintenance et support continus, temps du personnel, et les paliers de montée en charge qui se transforment en nouveaux niveaux récurrents.
L’erreur qui tue les budgets est de traiter les coûts récurrents comme s’ils étaient ponctuels. La construction est un instant. L’exploitation, c’est pour toujours. Un projet qui paraît abordable en tant que construction ponctuelle peut devenir un problème quand l’année deux et l’année trois arrivent avec tout leur poids récurrent et aucune nouvelle valeur à montrer au conseil d’administration.
Le coût de l’échec
Il y a un dernier coût, et c’est le plus important de tous. C’est le coût d’un déploiement qui échoue ou qui s’enlise.
Un projet qui prend six mois de retard parce que l’ingénierie d’intégration a été sous-budgétée ne coûte pas seulement l’ingénierie supplémentaire. Il coûte la valeur retardée que le projet était censé livrer, la crédibilité de l’équipe qui l’avait promise, et parfois l’envie de l’entreprise de retenter l’IoT tout court. Le projet IoT le plus cher est celui que vous devez reconstruire parce que la première version ne pouvait pas monter en charge ou ne pouvait pas être maintenue.
C’est la vraie raison de cartographier les coûts honnêtement. Non pas pour rendre le chiffre plus petit, mais pour le rendre vrai, afin que le projet survive au contact de l’année deux.
Plateforme gérée contre solution maison sur AWS
Voici la comparaison qui décide vraiment du budget.
Si vous construisez directement sur une infrastructure cloud brute, vous assemblez les pièces vous-même. Un broker de messages, une base de données, un moteur de règles, des dashboards, la gestion des utilisateurs, et le code de liaison entre tout cela. Vous possédez chaque ligne. Vous possédez aussi chaque correctif, chaque palier de montée en charge, et chaque appel à 2 heures du matin. La facture d’infrastructure peut sembler basse, mais la masse salariale d’ingénierie est le coût réel, et il ne s’arrête jamais.
Une plateforme IoT gérée comme TagoIO supprime la plupart des coûts d’ingénierie cachés. L’ingestion, le stockage, la gestion des appareils, la gestion des utilisateurs et des tenants, les dashboards et les alertes sont déjà construits et déjà maintenus. Le décodage du payload est géré par une couche configurable plutôt que par un service sur mesure que vous maintenez pour toujours. Vous pouvez voir comment fonctionnent le décodage et la structure des données dans la documentation TagoIO. La tarification est prévisible et liée à un usage que vous pouvez modéliser à l’avance, que vous pouvez consulter sur la page de tarification TagoIO.
L’arbitrage est simple. Avec une plateforme gérée, vous payez des frais récurrents plus clairs et vous cessez de payer l’équipe d’ingénierie qui aurait sinon construit et maintenu la plomberie. Pour un projet de marché intermédiaire, où vous avez de quelques centaines à quelques milliers d’appareils et une petite équipe, cet arbitrage penche presque toujours en faveur de la plateforme gérée. Le coût d’ingénierie caché est ce qui allait faire exploser votre budget, et c’est exactement le coût qu’une plateforme gérée vous retire des épaules.
Quand TagoIO est le mauvais choix
Je ne vais pas prétendre que la plateforme gérée l’emporte à chaque fois, parce que ce n’est pas le cas.
Si vous disposez déjà d’une grande équipe d’ingénierie cloud en interne, que vous avez besoin d’un contrôle total de l’infrastructure et que vous opérez avec un très grand nombre d’appareils, construire directement sur AWS IoT Core peut être moins cher à grande échelle. À un volume suffisamment élevé, l’économie par message d’une infrastructure brute bat la tarification d’une plateforme gérée, et si vous employez déjà les ingénieurs qui la maintiendraient, vous n’ajoutez pas ce coût, vous le portez déjà. Dans cette situation, AWS IoT Core est le choix rationnel, et vous devriez le choisir avec la même budgétisation lucide que cet article défend.
La ligne de partage est honnête et simple. Si votre échelle est celle du marché intermédiaire et votre équipe petite, le coût d’ingénierie caché est votre ennemi et une plateforme gérée l’élimine. Si votre échelle est très grande et que vous possédez déjà une équipe d’ingénierie cloud, l’infrastructure brute peut gagner sur l’économie unitaire. La plupart des projets de marché intermédiaire sont fermement dans le premier camp, et c’est pour cela que les plateformes gérées existent.
Quoi faire de tout cela
Construisez votre budget en deux colonnes, ponctuel et récurrent, et placez chaque ligne de cet article dans l’une des deux. Utilisez votre intervalle de transmission réel, pas celui de la démo. Chiffrez la maintenance pour l’année deux et l’année trois, pas seulement la construction. Puis lancez la comparaison entre solution gérée et solution maison face à votre nombre réel d’appareils et à la taille réelle de votre équipe.
Si vous faites cela, vous entrerez dans la réunion budgétaire avec un chiffre que vous pourrez défendre ligne par ligne. Et quand l’année deux arrivera, le projet sera toujours debout.
