« Peut-on l'exécuter sur nos propres serveurs ? » est l'une des premières questions que posent les acheteurs IoT sérieux — et l'une de celles auxquelles on répond le moins honnêtement. Auto-héberger une plateforme IoT est réellement le bon choix pour certains déploiements et un détour coûteux pour d'autres. Voici comment savoir dans quel cas vous êtes.

Ce que « auto-hébergé » signifie vraiment

Une plateforme IoT auto-hébergée tourne sur une infrastructure que vous contrôlez : vos propres serveurs, votre cloud privé ou un segment réseau isolé. Les données des appareils ne quittent jamais votre périmètre, l'authentification s'intègre à vos systèmes d'identité, et la disponibilité de la plateforme relève de la responsabilité de votre équipe — au sens valorisant du terme comme au sens « appel à 3 heures du matin ».

Ce dernier point est le cœur honnête de cet article : l'auto-hébergement n'est pas une fonctionnalité que l'on active, c'est une fonction opérationnelle que l'on assume.

Les bonnes raisons de s'auto-héberger

Souveraineté des données et conformité. Les secteurs réglementés, le secteur public et les infrastructures critiques ont souvent des exigences strictes imposant que la télémétrie reste sur site ou sur le territoire national. Si vos auditeurs disent que les données ne peuvent pas sortir, la discussion est close — il vous faut un déploiement on-premise.

Sites isolés (air-gapped) et à faible connectivité. Une usine, un navire ou un site distant avec une liaison réseau peu fiable peut avoir besoin de la plateforme à côté des machines, pas de l'autre côté d'un océan.

Latence et localité. Quand les décisions d'automatisation doivent se déclencher en quelques millisecondes sur des équipements locaux, une plateforme locale supprime l'aller-retour.

Contrôle à long terme. Certaines équipes veulent simplement la garantie qu'aucun changement de tarification ni aucun arrêt de produit chez un éditeur ne pourra bloquer leur déploiement.

Les coûts que personne n'affiche sur sa page d'accueil

Les plateformes open source que vous auto-hébergez — la Community Edition Apache 2.0 de ThingsBoard en est l'exemple le plus connu — sont gratuites en licence, pas en exploitation. Quelqu'un doit dimensionner et faire évoluer la base de données, appliquer les correctifs de sécurité, tester les mises à niveau, surveiller la supervision elle-même et porter l'astreinte. Des fonctionnalités que vous pensiez incluses peuvent se trouver dans les éditions payantes ; chez ThingsBoard, par exemple, la connectivité LoRaWAN passe par des intégrations de serveurs de réseau externes réservées aux offres payantes. Notre comparatif Kilo vs ThingsBoard expose ce compromis honnêtement, y compris là où ThingsBoard l'emporte réellement.

Une règle empirique utile : si vous ne pouvez pas nommer l'ingénieur qui aura la charge des mises à niveau de la plateforme dans dix-huit mois, vous ne choisissez pas l'auto-hébergement — vous choisissez la dette technique.

La voie médiane : une plateforme managée, déployée on-premise

Le choix ne se limite pas à « SaaS public » ou « open source brut ». La plateforme IoT de Kilo existe en SaaS cloud et en déploiement on-premise : la même plateforme — serveurs de réseau LoRaWAN et mioty intégrés, tableaux de bord avec jumeau numérique 3D du bâtiment, règles avec cycle construire-tester-déployer-rollback, chaînes d'escalade d'alarmes et assistant IA — installée à l'intérieur de votre périmètre, l'éditeur restant responsable du logiciel lui-même.

Cela coupe la poire en deux exactement là où la plupart des équipes le souhaitent : votre infrastructure et vos données, mais pas la charge de développer et de maintenir la plateforme.

Une courte checklist avant de décider

Posez cinq questions. Une réglementation exige-t-elle réellement l'on-premise, ou cela semble-t-il simplement plus sûr ? Qui exploite la plateforme la deuxième année ? L'édition auto-hébergée inclut-elle la connectivité dont vous avez besoin (serveur de réseau LoRaWAN, MQTT) ou s'agit-il d'options payantes ? Combien coûte le retour en arrière si vous vous trompez ? Et pouvez-vous d'abord piloter les deux modèles à moindre coût ?

Cette dernière question a une réponse simple : l'offre cloud de Kilo est gratuite pour 5 appareils — vous pouvez donc prouver la valeur applicative dans le cloud, puis passer à l'on-premise avec un modèle de déploiement déjà validé, au lieu de déboguer l'infrastructure et le cas d'usage en même temps.