La question device shadow vs jumeau numérique se pose dans presque tous les projets IoT, car les deux conservent côté cloud une copie de l'état d'un appareil. Cet article explique précisément en quoi ils diffèrent par leur périmètre, leurs données et leur finalité, montre quand un shadow suffit et quand il faut un jumeau complet, et détaille un pattern de device shadow portable construit sur des topics MQTT retained.
Pour approfondir le volet jumeau, consultez le guide de la technologie du jumeau numérique.
Qu'est-ce qu'un device shadow ?
Un device shadow est un document d'état persistant pour un seul appareil, conservé dans le cloud. Il comporte généralement trois parties :
- Reported : le dernier état rapporté par l'appareil.
- Desired : l'état qu'une application souhaite pour l'appareil.
- Delta : la différence, sur laquelle l'appareil doit agir.
Les plateformes IoT cloud ont introduit les shadows (appelés device twins sur certaines plateformes) pour résoudre un problème précis : les applications doivent lire et modifier l'état d'un appareil même lorsqu'il est en veille ou hors ligne. Le shadow est toujours disponible ; l'appareil se synchronise avec lui lorsqu'il se connecte.
Un shadow est volontairement simple. Il connaît un seul appareil, conserve l'état actuel et un numéro de version, et ne fait guère plus.
Qu'est-ce qu'un jumeau numérique ?
Un jumeau numérique est un concept plus large : une représentation virtuelle en temps réel d'un actif, d'un procédé ou d'un système physique, qui combine l'état actuel avec du contexte et du comportement. En plus de l'état que détient un shadow, un jumeau ajoute généralement :
- Un modèle : ce qu'est l'actif, ses propriétés, ses unités et sa sémantique, souvent exprimés en DTDL ou sous forme d'Asset Administration Shell.
- Des relations : cette pompe appartient à cette station, qui alimente ce réservoir.
- Un historique : des séries temporelles utilisées pour les tendances, le diagnostic et la prédiction.
- De l'analytique ou de la simulation : valeurs dérivées, détection d'anomalies, scénarios de simulation.
- Une visualisation : tableaux de bord ou scènes 3D montrant de nombreux actifs ensemble.
Un jumeau peut représenter des choses qui ne sont pas du tout un appareil unique : une ligne de production, un étage de bâtiment, une usine entière.
Device shadow vs jumeau numérique : comparaison côte à côte
| Aspect | Device shadow | Jumeau numérique |
|---|---|---|
| Périmètre | Un appareil | Actif, système ou procédé, souvent de nombreux appareils |
| Données principales | État rapporté et désiré actuel | État plus historique, modèle et contexte |
| Modèle | JSON libre | Schéma, sémantique et unités explicites |
| Relations | Aucune | Hiérarchies et liens entre actifs |
| Temps | Dernière valeur uniquement | Actuel et historique |
| Logique | Calcul du delta | Analytique, simulation, prédiction |
| Consommateurs typiques | Applications mobiles, gestion des appareils | Ingénieurs, opérateurs, planificateurs |
| Visualisation | Généralement aucune | Tableaux de bord et vues 3D courants |
| Effort de construction | Faible | Moyen à élevé |
La relation est cumulative : la plupart des jumeaux numériques contiennent un équivalent de shadow pour chaque appareil, alors qu'un shadow seul n'est pas un jumeau complet. Notre article jumeau numérique vs ombre numérique traite d'une distinction voisine mais différente, issue de la littérature scientifique, où l'ombre numérique (digital shadow) désigne un flux de données à sens unique de l'actif vers le modèle.
Quand un device shadow suffit
Choisissez un shadow lorsque :
- Vous gérez de nombreux appareils similaires, comme des prises connectées, des traceurs ou des compteurs.
- Le besoin principal est « afficher l'état actuel et me laisser modifier les réglages ».
- Les appareils se mettent en veille ou se connectent par intermittence et doivent rattraper leur configuration.
- Vous n'avez pas besoin de relations entre appareils ni d'analytique par-dessus.
L'IoT grand public, la configuration de flottes et les réglages à distance sont le terrain classique du shadow.
Quand il vous faut un jumeau numérique complet
Choisissez un jumeau lorsque :
- La valeur vient de la vision des actifs dans leur contexte : une ligne, un bâtiment, un réseau.
- Vous devez corréler l'état avec l'historique pour diagnostiquer des problèmes.
- Plusieurs sources de données décrivent un même actif (automate, capteur de vibrations, MES).
- Les utilisateurs veulent des vues spatiales ou 3D.
- Vous prévoyez de la maintenance prédictive ou de la simulation.
Les usines, les systèmes énergétiques et les bâtiments aboutissent presque toujours ici. L'article sur l'architecture du jumeau numérique présente les couches supplémentaires dont vous aurez besoin.
Construire un device shadow portable avec des topics MQTT retained
Les services de shadow cloud sont liés à leur plateforme. Vous pouvez obtenir le même comportement sur n'importe quel broker MQTT conforme aux standards grâce aux retained messages, ce qui garde la conception portable. La structure de topics :
connectmq/demo/<id>/shadows/<device>/reported retained, device writes
connectmq/demo/<id>/shadows/<device>/desired retained, apps write
connectmq/demo/<id>/shadows/<device>/delta not retained, computed by a shadow service
connectmq/demo/<id>/shadows/<device>/status retained, last will
Les retained messages vous offrent gratuitement la propriété la plus importante d'un shadow : quiconque s'abonne, quel que soit le moment, reçoit les derniers documents reported et desired. Un petit service calcule les deltas :
import json
import paho.mqtt.client as mqtt
BASE = "connectmq/demo/4d2a/shadows"
shadows = {}
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(f"{BASE}/+/reported", qos=1)
client.subscribe(f"{BASE}/+/desired", qos=1)
def on_message(client, userdata, msg):
_, _, _, _, device, kind = msg.topic.split("/")
doc = json.loads(msg.payload) if msg.payload else {}
shadow = shadows.setdefault(device, {"reported": {}, "desired": {}})
shadow[kind] = doc
delta = {
key: value
for key, value in shadow["desired"].items()
if key not in ("version", "ts") and shadow["reported"].get(key) != value
}
if delta:
client.publish(f"{BASE}/{device}/delta", json.dumps(delta), qos=1)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="shadow-service-4d2a")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883)
client.loop_forever()
Essayez-le avec le serveur MQTT public gratuit, réservé aux tests et aux prototypes :
mosquitto_pub -h broker.connectmq.com -p 1883 -i lamp1-4d2a -q 1 -r \
-t "connectmq/demo/4d2a/shadows/lamp1/reported" -m '{"on": false, "brightness": 40}'
mosquitto_pub -h broker.connectmq.com -p 1883 -i app-4d2a -q 1 -r \
-t "connectmq/demo/4d2a/shadows/lamp1/desired" -m '{"version": 1, "on": true, "brightness": 80}'
mosquitto_sub -h broker.connectmq.com -p 1883 -i watch-4d2a \
-t "connectmq/demo/4d2a/shadows/lamp1/#" -v
Le service publie {"on": true, "brightness": 80} sur le topic delta. Un appareil peut aussi se passer entièrement du service : il s'abonne à son topic desired retained et calcule le delta localement, ce qui est souvent plus simple pour les petites flottes. Les règles de reconnexion et de versionnage décrites dans la synchronisation d'état du jumeau numérique s'appliquent telles quelles.
Les limites du shadow sur topics retained
Soyons honnêtes sur ce que ce pattern ne vous apporte pas. Il n'y a pas d'API de requête (« trouver toutes les lampes allumées »), pas de contrôle d'accès par document au-delà de ce que permettent les identifiants de votre broker, et les retained messages résident dans le broker plutôt que dans une base de données. Si vous en avez besoin, ajoutez un service de jumeau ou un abonné base de données à côté du broker. Pour beaucoup de flottes, cependant, les topics retained suffisent et évitent tout un niveau de services.
Erreurs courantes dans le choix entre les deux
Les équipes commettent généralement l'une de deux erreurs opposées. La première consiste à appeler un shadow un jumeau, puis à s'étonner que les parties prenantes attendent un historique, du contexte et de l'analytique qu'un simple document d'état ne peut fournir. Si le directeur d'usine demande « pourquoi la ligne 3 a-t-elle ralenti mardi dernier ? », un shadow n'a pas de réponse.
La seconde erreur consiste à démarrer avec une plateforme de jumeau lourde alors que le besoin réel est « laisser l'application mobile modifier la consigne du thermostat pendant que l'appareil est en veille ». Ce projet a besoin d'un shadow, et ajouter modélisation, bases de données orientées graphe et scènes 3D ne fait que retarder la livraison.
Un test utile consiste à noter les trois questions auxquelles les utilisateurs veulent le plus une réponse. Si toutes trois portent sur l'état actuel ou la configuration d'un seul appareil, construisez un shadow. Si l'une d'elles implique le temps, les relations entre actifs ou la comparaison entre comportement attendu et réel, prévoyez un jumeau, mais commencez quand même par les topics d'état de type shadow décrits ci-dessus, car le jumeau sera construit par-dessus.
Du shadow au jumeau : un parcours pratique
- Commencez par un topic reported et un topic desired retained par appareil.
- Ajoutez un topic de statut avec Last Will pour la présence.
- Ajoutez un abonné d'historique qui écrit dans une base de séries temporelles.
- Introduisez un modèle d'actifs avec hiérarchie et unités.
- Ajoutez un tableau de bord ou une vue 3D qui s'abonne à des branches entières.
- Superposez de l'analytique à l'historique et à l'état en temps réel.
Chaque étape réutilise les mêmes topics : les appareils n'ont jamais besoin de changer.
Construisez shadows et jumeaux sur ConnectMQ
ConnectMQ vous fournit la fondation de messagerie pour les deux : un broker MQTT managé avec retained messages, Last Will, MQTT 3.1.1 et 5.0, TLS sur le port 8883 et WSS sur le 8084 pour les tableaux de bord dans le navigateur. Votre logique de shadow et vos services de jumeau se connectent comme des clients MQTT ordinaires : rien n'est verrouillé sur un cloud. Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, et migrez-y votre premier device shadow.
Questions fréquentes
Un device shadow est-il un jumeau numérique ?
Un device shadow est une forme simple d'état de type jumeau pour un seul appareil. Un jumeau numérique ajoute un modèle, des relations, un historique et de l'analytique, souvent sur de nombreux appareils.
Peut-on construire un device shadow sans plateforme IoT cloud ?
Oui. Des topics MQTT retained pour l'état rapporté et désiré, plus un service de delta optionnel, reproduisent le comportement d'un shadow sur n'importe quel broker MQTT conforme aux standards.
Quelle est la différence entre un device twin et un device shadow ?
Il s'agit essentiellement du même concept sous des noms différents selon les plateformes : un document côté cloud avec des propriétés reported et desired pour un appareil.
Faut-il une base de données pour un device shadow ?
Pas nécessairement. Les retained messages conservent le dernier état. Ajoutez une base de données lorsque vous avez besoin de requêtes sur plusieurs appareils, d'un historique ou de pistes d'audit.
