Deux manieres de communiquer
HTTP fonctionne en requete/reponse. Le client demande, le serveur repond, et l’echange se termine. C’est parfait pour des APIs web. MQTT change la logique : les appareils maintiennent une connexion legere vers un broker, publient des evenements, et les abonnes les recoivent instantanement. Ce n’est pas qu’un transport, c’est une autre maniere de penser les flux.
Si votre systeme est declenche par des evenements (temperature, porte ouverte, statut d’un vehicule), MQTT evite le polling. On ne demande pas “as-tu change ?”, on recoit l’info quand cela arrive. Cela reduit la bande passante et rend l’experience plus reactive.
Latence et bande passante
Les en-tetes HTTP sont lourds par rapport aux trames MQTT. Chaque requete HTTP transporte des headers, cookies et negociations. MQTT conserve une session persistante et n’envoie que l’essentiel. Sur un reseau cellulaire ou contraint, la difference est nette.
La latence est aussi liee aux reconnections. HTTP peut etre rapide en bonne connexion, mais sur un reseau instable, les handshakes repetes coutent cher. MQTT garde un lien actif avec un keep-alive et se reconnecte plus proprement.
Fiabilite en conditions degradees
HTTP laisse au client la gestion des echec et des retries. MQTT propose des niveaux de QoS qui definissent le contrat de livraison. Si vous avez besoin de “au moins une fois” ou “exactement une fois”, MQTT l’integre nativement.
Cela ne supprime pas les erreurs, mais vous donne un cadre. Les traitements doivent rester idempotents, mais le transport est plus explicite sur la garantie de livraison.
Fan-out et many-to-many
Quand un evenement doit atteindre de multiples consommateurs, HTTP finit en webhooks ou polling. MQTT est concu pour le fan-out : le broker route le message a tous les abonnes sans complexite pour l’emetteur.
C’est ideal en IoT, ou un simple capteur alimente tableaux de bord, alertes et analyses. Une publication suffit pour tous les consommateurs.
Securite et gouvernance
HTTP beneficie d’outils matures (TLS, OAuth, passerelles). MQTT peut etre tout aussi securise, mais il faut le construire : TLS sur le broker, ACL par topic, credentials courts, monitoring des clients.
Une bonne regle : HTTP pour les workflows utilisateurs, MQTT pour les evenements appareils. Les deux coexistent tres bien via des passerelles.
Choisir rapidement
Si vos clients sont des apps web ou mobiles qui appellent une API, HTTP reste le standard. Si vos clients sont des objets ou vehicules qui poussent des evenements, MQTT est souvent mieux adapte.
Beaucoup d’architectures hybrides utilisent HTTP pour la configuration et MQTT pour la telemetrie. L’essentiel est d’eviter de transformer un systeme evenementiel en boucle de polling couteuse.
Pattern de migration
Commencez par un flux d’evenements actuellement recupere en HTTP polling. Ajoutez un topic MQTT, un broker, et un petit service abonne pour alimenter vos systemes existants. Mesurez les gains.
Ensuite, etendez progressivement. MQTT devient l’ossature des evenements, tandis que HTTP reste le plan de controle et de configuration.