Éviter le Vendor Lock-In dans l'IoT industriel

Le lock-in arrive rarement d'une seule décision. Il s'accumule. Un fournisseur de passerelles livre une image firmware fermée, si bien que vos données ne quittent l'appareil que par son cloud. Ce cloud facture d'abord par actif connecté, puis par message, puis par appel d'API. Deux ans plus tard, le protocole sur le fil n'est documenté nulle part, les certificats des appareils sont émis par le fournisseur et le modèle de données est celui que son portail veut bien exporter. Changer signifie désormais réinstrumenter chaque machine sur le terrain.

Le coût apparaît là où les achats ne l'avaient pas prévu : des redevances par appareil qui suivent la taille de votre flotte, pas votre marge. Un firmware que vous ne pouvez pas corriger lorsqu'une faille est publiée. Une feuille de route que vous ne pilotez pas. Lorsque le fournisseur abandonne une gamme ou se fait racheter, votre parc installé hérite de la décision. Rien de tout cela n'est hypothétique. C'est la conséquence prévisible d'avoir confié à un tiers la couche entre vos machines et vos systèmes métier.

Le geste le plus décisif consiste à posséder le logiciel qui tourne sur l'appareil edge. Une passerelle bâtie sur Linux embarqué (une image Yocto que vous pouvez reconstruire depuis les sources) place la logique d'acquisition, les analyseurs de protocole et la chaîne d'envoi sous votre contrôle. Vous détenez les identifiants root. Vous signez votre propre firmware. Lorsqu'un bus de terrain évolue ou qu'un client demande un nouveau signal, vous modifiez le code et déployez une mise à jour OTA, au lieu de déposer une demande d'évolution et d'attendre une version du fournisseur.

Il ne s'agit pas de tout développer de zéro. Les briques sont matures et ouvertes : le noyau Linux, une pile CAN via SocketCAN, libmodbus pour le Modbus série et TCP, un client MQTT comme Eclipse Mosquitto pour la liaison montante. L'essentiel est que l'intégration vous appartienne, versionnée dans votre propre dépôt et reproductible sans aucun appel à un tiers. Un système que vous pouvez reconstruire est un système que vous pouvez déplacer.

L'interopérabilité se joue à la frontière des protocoles. Côté machine, les bus de terrain sont déjà des standards : J1939 sur CAN pour une transmission ou un circuit hydraulique, Modbus RTU sur une pompe auxiliaire ou un variateur de vitesse, OPC-UA là où un automate moderne expose un espace d'adressage structuré. Lisez-les directement. Dès que vous acceptez entre les deux un protocole binaire propriétaire, vous avez cédé la couche de traduction, et la couche de traduction est le verrou.

La liaison montante mérite la même rigueur. MQTT avec mise en mémoire tampon store-and-forward achemine la télémétrie vers n'importe quel broker qui parle le protocole : aujourd'hui votre propre cluster Mosquitto, demain un broker managé, sans que l'appareil n'en sache rien. Conservez la charge utile dans un schéma ouvert et documenté (JSON ou une définition Protobuf publiée) afin qu'un second consommateur puisse la lire sans rétro-ingénierie. Quand chaque interface du chemin est un standard publié, remplacer un composant devient un changement de configuration, pas un projet.

L'ouverture technique ne sert à rien si le contrat attribue le travail réalisé au fournisseur. Pour un OEM qui livre des équipements connectés, le logiciel embarqué fait partie du produit, et le contrat doit le dire : code source, scripts de build, schémas matériels et clés de signature vous sont remis, avec une licence qui vous autorise à les modifier et à les redistribuer dans votre produit. En deçà, il subsiste une dépendance qu'aucun schéma d'architecture n'efface.

La propriété change aussi l'économie du projet. Lorsque le code de la passerelle vous appartient, il n'y a pas de licence par actif qui grossit avec la flotte, ni de barrière payante par fonction entre vous et votre propre feuille de route. Vous pouvez forker le code pour une nouvelle gamme, le confier à un autre intégrateur ou l'internaliser entièrement. L'actif inscrit à votre bilan, c'est le système, pas un droit d'usage révocable sur le bien d'autrui.

Une architecture indépendante du fournisseur est modulaire par construction, avec des jointures nettes entre acquisition, transport, stockage et présentation. La passerelle ne devrait pas avoir à savoir à quel broker elle parle. Le broker ne devrait pas avoir à savoir quelle base de données s'abonne. La base de données ne devrait pas avoir à savoir quel tableau de bord l'interroge. Chaque frontière est une interface publiée, de sorte qu'un changement d'un côté ne se propage pas dans le reste.

Cette séparation rend la migration soutenable. Remplacez la base de données de séries temporelles, les passerelles continuent de publier. Passez d'un cloud à un autre, les appareils de terrain ne le remarquent jamais, parce qu'ils visent un nom d'hôte et un topic, pas un point d'accès propriétaire. Cette rigueur coûte un peu plus d'effort de conception au départ. Elle vous offre la possibilité de changer d'avis sur toute la durée de vie du déploiement, qui sur du matériel industriel se mesure en décennies, pas en cycles de version.

Une fois les pièces assemblées, le résultat est sans surprise, et c'est tout l'intérêt : des passerelles Linux ouvertes que vous contrôlez, des protocoles de terrain standard lus directement, MQTT vers un broker ouvert, une base de données de séries temporelles ouverte et une couche de tableaux de bord qui dialogue avec des API documentées. Aucun composant n'est irremplaçable, et le modèle de données vous appartient, du capteur à la requête. C'est un système que vous pouvez exploiter, étendre et migrer selon vos propres conditions.

C'est précisément l'approche que construit Melqart Systems. Nous livrons des systèmes ouverts, pas des boîtes noires propriétaires, et chaque mission s'achève avec le code source, les schémas et les identifiants entre vos mains. Voir routeurs & passerelles neutres et accès distant sécurisé OT.