Alternative à Google Cloud IoT Core : options et migration après l'arrêt du service

Si vous cherchez une alternative à Google Cloud IoT Core, soit vous migrez une flotte laissée en plan par l'arrêt du service, soit vous concevez un nouveau projet sur Google Cloud sans passerelle d'appareils native. Ce guide explique ce que faisait IoT Core, compare honnêtement les options de remplacement réalistes, fait correspondre les concepts d'IoT Core à du MQTT standard et détaille la migration des appareils vers un broker MQTT managé, tandis que vos données continuent d'alimenter les services Google Cloud.

Qu'est-il arrivé à Google Cloud IoT Core ?

Google a annoncé en 2022 l'abandon de Cloud IoT Core, et le service a été retiré le 16 août 2023. Depuis cette date, les appareils ne peuvent plus se connecter à ses bridges MQTT et HTTP. Google n'a pas lancé de successeur direct ; l'entreprise a plutôt orienté ses clients vers des solutions partenaires et vers les services généralistes de Google Cloud. Les autres produits Google Cloud, comme Pub/Sub, Dataflow et BigQuery, n'ont pas été affectés et restent des destinations courantes pour les données IoT.

IoT Core réunissait trois fonctions, et chacune doit être remplacée :

1. Connectivité des appareils : un endpoint MQTT sur mqtt.googleapis.com, port 8883 (et 443).
2. Registre et authentification des appareils : des appareils identifiés par de longs client ID de la forme projects/PROJECT/locations/REGION/registries/REGISTRY/devices/DEVICE, authentifiés par un JWT signé avec une clé privée propre à chaque appareil et envoyé comme mot de passe MQTT.
3. Routage des données : la télémétrie publiée sur /devices/DEVICE_ID/events était relayée vers des topics Pub/Sub ; la configuration et les commandes descendaient sur /devices/DEVICE_ID/config et /devices/DEVICE_ID/commands/#, et l'état des appareils remontait sur /devices/DEVICE_ID/state.

Les alternatives à Google Cloud IoT Core comparées

Il n'existe pas de réponse unique. Le meilleur remplacement dépend de votre degré d'utilisation des fonctionnalités d'IoT Core et de l'endroit où vous voulez héberger vos données.

Chaque option est légitime. Les services IoT des hyperscalers offrent des moteurs de règles riches et une forte intégration ; les plateformes partenaires peuvent limiter les modifications de firmware ; l'auto-hébergement donne un contrôle maximal. Un broker MQTT managé se situe entre les deux : protocole standard, dépendance minimale et aucun serveur à exploiter, au prix d'un relais à construire vers Google Cloud. Pour une comparaison plus large des services des hyperscalers, consultez notre guide alternative à AWS IoT Core.

Faire correspondre les concepts d'IoT Core à du MQTT standard

Passer à un broker standard est avant tout un exercice de traduction :

C'est désormais à vous de concevoir l'arborescence des topics. Abandonnez la barre oblique initiale utilisée par IoT Core, qui ajoute un premier niveau vide, et envisagez une hiérarchie de type ISA-95 si vous travaillez dans l'industrie manufacturière.

Étape par étape : migrer les appareils vers un broker MQTT managé

1. Préparer le broker

Inscrivez-vous sur app.connectmq.com, choisissez une offre dimensionnée pour votre pic de connexions, créez un broker et émettez des identifiants. L'offre Serverless gratuite (jusqu'à 25 connexions, QoS jusqu'à 1) suffit pour valider le firmware et le service de relais ; Serverless Paid prend en charge jusqu'à 1 000 connexions et la QoS 2.

2. Mettre à jour le firmware des appareils

Remplacez la génération de JWT et le client ID d'IoT Core par le nom d'utilisateur, le mot de passe et le client ID émis, changez l'hôte et mettez à jour les noms de topic. Conservez le TLS sur le port 8883 ; ConnectMQ utilise un certificat Let's Encrypt, votre magasin de confiance doit donc inclure le certificat ISRG Root X1 au lieu des racines de Google. Supprimez la logique de renouvellement des JWT, souvent à l'origine de bugs de reconnexion sur les appareils IoT Core. Si vos appareils sont basés sur l'ESP32, le tutoriel MQTT pour ESP32 présente un client TLS complet.

3. Relayer la télémétrie vers Pub/Sub

ConnectMQ n'inclut pas de bridges de données vers le cloud : les données atteignent donc Pub/Sub via un petit service de relais qui se connecte comme un client MQTT ordinaire. Exécutez-le sur Cloud Run, GKE ou une VM, avec un compte de service autorisé à publier sur le topic. Installez les dépendances avec pip install "paho-mqtt>=2.0" google-cloud-pubsub.

import os
import ssl

import paho.mqtt.client as mqtt
from google.cloud import pubsub_v1

PROJECT = os.environ["GCP_PROJECT"]
PUBSUB_TOPIC = os.environ.get("PUBSUB_TOPIC", "device-telemetry")
MQTT_FILTER = os.environ.get("MQTT_FILTER", "fleet/+/+/telemetry")

publisher = pubsub_v1.PublisherClient()
topic_path = publisher.topic_path(PROJECT, PUBSUB_TOPIC)


def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code)
    client.subscribe(MQTT_FILTER, qos=1)


def on_message(client, userdata, msg):
    device_id = msg.topic.split("/")[2]
    future = publisher.publish(
        topic_path,
        msg.payload,
        mqtt_topic=msg.topic,
        device_id=device_id,
    )
    future.add_done_callback(
        lambda f: f.exception() and print("Pub/Sub publish failed:", f.exception())
    )


client = mqtt.Client(
    mqtt.CallbackAPIVersion.VERSION2,
    client_id=os.environ["MQTT_CLIENT_ID"],
    protocol=mqtt.MQTTv5,
)
client.username_pw_set(os.environ["MQTT_USERNAME"], os.environ["MQTT_PASSWORD"])
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_message = on_message
client.reconnect_delay_set(min_delay=1, max_delay=60)
client.connect("broker.connectmq.com", 8883, keepalive=60)
client.loop_forever()

Renseignez MQTT_USERNAME, MQTT_PASSWORD et MQTT_CLIENT_ID avec les valeurs du portail (YOUR_USERNAME, YOUR_PASSWORD, YOUR_CLIENT_ID), idéalement depuis Secret Manager. Des attributs comme device_id permettent aux abonnés en aval et aux jobs Dataflow de filtrer sans analyser les payloads, à la manière des attributs d'appareil ajoutés par IoT Core. La documentation officielle de la bibliothèque cliente Pub/Sub couvre le batching et le contrôle de flux pour les gros volumes. Pour monter en charge, exécutez plusieurs instances avec un abonnement partagé MQTT 5 tel que $share/forwarders/fleet/+/+/telemetry, disponible à partir de Serverless Paid.

4. Remplacer la configuration et les commandes

Les messages de configuration d'IoT Core se transposent naturellement en messages MQTT retenus : publiez la configuration de chaque appareil en mode retenu sur son topic de configuration, et l'appareil la reçoit à chaque connexion. Les commandes se transposent en un topic de commande en QoS 1. Rendez les commandes idempotentes avec un identifiant unique et une date d'expiration, comme décrit dans notre guide pour surmonter une panne de broker MQTT.

5. Déployer par vagues

Migrez d'abord un groupe pilote, surveillez l'état des connexions sur $SYS/broker/connection/{clientId}/state et dans l'explorateur de topics du portail, puis migrez le reste par région ou par gamme de produits. Si certains appareils ne peuvent pas être mis à jour rapidement, une passerelle locale peut traduire leurs anciens topics et les republier dans la nouvelle hiérarchie.

Checklist avant la bascule

1. Inventaire des appareils, des versions de firmware et des fonctionnalités IoT Core utilisées.
2. Nouvelle hiérarchie de topics conçue et documentée.
3. Offre de broker dimensionnée pour le pic de connexions, la QoS et la taille des messages.
4. Identifiants émis par appareil et stockés de façon sécurisée.
5. Firmware mis à jour pour le nouvel hôte, le magasin de confiance, les identifiants et les topics.
6. Service de relais en fonctionnement et vérifié dans Pub/Sub.
7. Flux de configuration et de commandes testés de bout en bout.
8. Plan de déploiement avec groupe pilote et étapes de retour arrière.

Si une partie de votre flotte tourne déjà sur un broker local, le guide pour migrer Mosquitto vers MQTT cloud détaille le bridging et la bascule par vagues.

Migrez votre flotte vers ConnectMQ

Créez un broker gratuit sur app.connectmq.com avec l'offre Serverless, sans carte bancaire, et validez votre firmware et votre service de relais avant de migrer la flotte. ConnectMQ est un broker MQTT managé avec MQTT 3.1.1 et 5.0 standard, TLS, WebSockets et un portail doté d'un explorateur de topics en direct. Lisez le guide sur le broker MQTT cloud pour les options de déploiement, ou essayez le serveur MQTT public gratuit pour un premier test, avec des données factices uniquement.

Questions fréquentes

Quand Google Cloud IoT Core a-t-il été arrêté ?

Google a retiré Cloud IoT Core le 16 août 2023, après avoir annoncé son abandon en 2022. Les appareils ne peuvent plus se connecter à ses endpoints.

Puis-je continuer à utiliser Pub/Sub et BigQuery après être passé à un autre broker ?

Oui. Ces services n'ont pas été affectés. Un petit service abonné relaie les messages MQTT du broker vers Pub/Sub, et les pipelines existants prennent le relais à partir de là.

Ai-je besoin d'une authentification JWT sur un nouveau broker MQTT ?

Pas nécessairement. La plupart des brokers MQTT managés, dont ConnectMQ, utilisent un nom d'utilisateur et un mot de passe par appareil sur TLS, ce qui supprime la logique de renouvellement des JWT dans le firmware.

Quel est le remplacement le plus proche de la configuration des appareils d'IoT Core ?

Les messages MQTT retenus. Publiez la configuration de chaque appareil en mode retenu sur son propre topic de configuration, et l'appareil reçoit la dernière version à chaque connexion.