Pourquoi le design des topics est crucial
Dans MQTT, les topics sont l’API. Une structure propre rend le systeme decouvrable et facilite les abonnes. Une structure confuse cree du couplage et complique les permissions.
Traitez le design des topics comme une architecture d’information. Vous nommez le systeme pour les humains et pour les machines.
Choisir une hierarchie stable
Un pattern courant : `/domaine/entite/id/metric`. Exemple : `devices/thermostat/42/temperature`. C’est lisible et scalable.
Evitez de placer des valeurs volatiles au milieu de la hierarchie, car cela casse les subscriptions wildcard.
Profondeur vs lisibilite
Plus de niveaux ajoute de la clarté mais augmente la complexite. Trouvez la profondeur minimale qui capture la propriete et le type d’entite.
Utilisez des conventions coherentes. Hyphen-case ou snake_case, peu importe, mais restez consistant.
Strategie des wildcards
Le wildcard `+` correspond a un niveau, `#` correspond a tout en dessous. Conceptionnez vos topics pour que ces wildcards correspondent a des regroupements logiques.
Si vous voulez s’abonner a “tous les appareils d’un batiment”, le batiment doit etre un niveau stable.
Permissions et securite
Les ACL suivent souvent des patterns de topics. Une bonne hierarchie facilite le principe du moindre privilege.
Evitez de melanger des donnees non liees sous le meme prefixe, sinon l’audit devient complexe.
Versionner la structure
Si la structure change, versionnez au plus haut niveau : `v2/devices/...`. Cela permet de migrer sans casser les clients existants.
Maintenez l’ancienne structure pendant la transition et utilisez un bridge si besoin.
Documenter les topics
Fournissez un catalogue simple : objectif, schema payload, QoS, retained, exemples. Cela rend la plateforme auto-serve.
Une doc claire transforme un systeme complexe en produit utilisable.