CoAP, MQTT et HTTP sont trois langages que les objets connectés utilisent pour échanger leurs données avec un serveur. Chacun a sa façon de faire. HTTP travaille en requête/réponse (l’objet demande, le serveur répond) sur TCP, le mode de transport fiable du web. CoAP reprend ce même principe requête/réponse, mais en version allégée : il tourne sur UDP, un transport plus léger et sans garantie de livraison. MQTT, lui, change de logique. Il fonctionne en publication/abonnement via un broker (un serveur relais qui reçoit les messages et les redistribue) et garde une connexion ouverte en permanence. Voilà le fond du sujet. Le reste, c’est savoir lequel colle à votre objet, et ce choix vous le traînez pendant toute la vie du produit. Mal fait, il se paie longtemps : en autonomie d’abord, en volume de données ensuite, puis le jour où il faut intégrer l’objet au reste du système. Et le bon protocole n’est jamais le plus populaire.
Choisir entre MQTT, CoAP et HTTP, c’est arbitrer selon la fréquence des échanges et l’énergie de l’objet — jamais selon la réputation du protocole.
HTTP, on le prend par réflexe, et c’est souvent justifié. Tout le monde sait le debugger avec les outils du quotidien, et un objet qui envoie une mesure de temps en temps vers une API déjà déployée n’a besoin de rien d’autre : aucune infrastructure nouvelle à monter. Le défaut tient dans son poids. Chaque requête traîne des en-têtes verbeux et, le plus souvent, ouvre puis referme une connexion, poignée de main TLS comprise. Cette négociation de chiffrement sécurise l’échange, mais elle coûte plusieurs allers-retours. Sur un objet branché au secteur, on s’en moque éperdument. Sur une pile bouton censée tenir deux ans, chaque réveil radio se compte. J’ai vu un capteur dépenser son budget énergie à rejouer ces poignées de main au lieu de mesurer quoi que ce soit.
MQTT répond précisément à ça quand l’objet parle souvent. Il garde une connexion TCP ouverte, légère, et fonctionne en publication/abonnement : les objets publient sur des sujets, le broker distribue aux abonnés, et personne ne s’adresse directement à personne. Ce découplage est l’intérêt principal, parce qu’il vous laisse brancher un nouveau consommateur de données sans toucher au firmware embarqué (le logiciel qui tourne dans l’objet). En face, il y a un coût visible tout de suite : un broker, ça s’exploite, ça se supervise, ça se sécurise. Mosquitto pour démarrer, EMQX ou HiveMQ quand la flotte grossit. Pour quelques centaines d’objets qui remontent un état régulièrement, le calcul penche nettement du bon côté. Une alerte de terrain, au passage : surveillez le QoS, le niveau de garantie de livraison des messages. Le niveau 0 ne garantit aucune livraison (« j’envoie et tant pis »), le niveau 2 garantit que le message arrive une fois et une seule, au prix de plusieurs allers-retours. Beaucoup d’équipes le poussent à 2 partout par prudence, puis s’étonnent de la consommation radio.
Reste CoAP, pour les cas où MQTT lui-même pèse trop. Il descend un cran plus bas, pensé pour les objets les plus serrés en mémoire, en réseau et en énergie. Il tourne sur UDP et ressemble volontairement à HTTP : on y retrouve des GET, des POST, des codes de retour, mais dans une version beaucoup plus maigre. La contrepartie est réelle. L’écosystème reste moins fourni, et côté serveur vous tombez vite sur le besoin d’une passerelle CoAP↔HTTP pour rejoindre le reste de la chaîne, du temps d’intégration que les comparatifs oublient de chiffrer. CoAP se justifie quand le gain d’énergie est vital, jamais pour faire moderne.
En pratique, ma règle tient en trois cas. Un objet peu contraint qui parle rarement vers une API HTTP déjà en place : je reste sur HTTP, la simplicité gagne. Quand une flotte échange régulièrement, que plusieurs services veulent les mêmes mesures et qu’il y a de la supervision derrière, je passe à MQTT. Et pour un objet vraiment au bout de son budget, là où la connexion MQTT coûte déjà trop, CoAP s’impose, outillage plus rare assumé. Mais dans la vraie vie, ce qui pèse le plus lourd, c’est ce que vous avez déjà sous la main. Un broker en production ou une API REST bien rodée font souvent pencher la décision avant même qu’on regarde la fiche technique de l’objet.
Un exemple pour finir. Une PME m’appelle sur un parc de capteurs agricoles sur batterie, censés tenir une saison, qui se vidaient en quelques semaines. Le firmware faisait du MQTT propre, QoS 1, keepalive court pour « détecter vite les pannes » (le keepalive étant ce petit signal périodique qui dit au broker « je suis toujours là »). Sauf que ces capteurs n’envoyaient qu’une mesure toutes les quinze minutes : la connexion permanente et ses réveils de keepalive coûtaient plus cher que la mesure elle-même. On a basculé sur des envois CoAP ponctuels, l’objet se rendort entre deux. L’autonomie est repassée au-dessus de la cible, sans changer une ligne de la logique métier. Le protocole n’était pas mauvais, il était juste à contre-emploi du rythme de l’objet.