Un capteur de porte qui met trois secondes à allumer une ampoule, ça n'a l'air de rien. Sauf que dans mon salon, quand je rentre les bras chargés de courses, ces trois secondes se transforment en une conversation absurde avec un interrupteur qui ne répond pas. J'ai commencé à mesurer ce délai par curiosité, puis par agacement. Et j'ai découvert que mon installation domotique cumulait près de 800 ms de latence sur un simple aller-retour local, avant même de sortir de chez moi.
Voilà le vrai sujet quand on parle de réduire la latence des objets connectés sur le réseau : ce n'est presque jamais un problème de débit. Un capteur qui envoie 40 octets toutes les dix minutes n'a pas besoin de fibre. Il a besoin que son message arrive vite. Ce sont deux choses totalement différentes, et c'est là que la plupart des tutos vous égarent.
Points clés à retenir
- La latence mesure un temps (en millisecondes), le débit mesure un volume : optimiser l'un ne règle rien sur l'autre.
- Sur un objet connecté, le goulot d'étranglement se trouve souvent dans le protocole et le chemin réseau, pas dans la box.
- La gigue (variation du délai) casse plus d'usages que la latence moyenne elle-même.
- Rapprocher le traitement des données (edge) élimine l'aller-retour vers le cloud, souvent le plus coûteux.
- Un seuil de latence « acceptable » dépend entièrement de l'usage : une serrure et un thermomètre ne jouent pas dans la même catégorie.
Réduire la latence de vos objets connectés : d'abord comprendre où le temps se perd
La latence décrit le temps qu'il faut à deux appareils pour communiquer, exprimé en millisecondes. Jusque-là, tout le monde est d'accord. Le problème, c'est que cette définition ne dit rien de l'endroit où ce temps s'accumule.
Sur un objet connecté, chaque échange traverse une chaîne de maillons : le capteur, la passerelle, votre routeur, le fournisseur d'accès, puis éventuellement un serveur distant. Un maillon lent contamine tout le reste. Dans mon cas, le coupable n'était ni la box ni la fibre : c'était une passerelle Zigbee bon marché qui mettait 300 ms à router un simple ordre vers l'ampoule.
Les trois zones où le temps se perd
- Le chemin radio local : un signal faible ou un canal encombré, et chaque trame repart en retransmission.
- Le chemin réseau : distance physique jusqu'au serveur, qualité de l'interconnexion, congestion aux heures de pointe.
- Le traitement : un serveur cloud qui réveille une fonction endormie avant de répondre peut à lui seul ajouter plusieurs centaines de millisecondes.
Franchement, quand j'ai commencé à instrumenter tout ça, j'avais une intuition fausse : je pensais que le fournisseur d'accès était le coupable. Il ne l'était pas. La majorité de mon délai se jouait à moins de dix mètres de mon canapé.
Comment faire baisser la latence, concrètement
La méthode qui marche tient en une phrase : mesurez d'abord, corrigez ensuite. Sans mesure, vous réglez au hasard et vous finissez par changer de box pour rien.
Mesurer proprement, du capteur au serveur
Un ping classique depuis votre ordinateur ne dit rien de la latence vécue par un capteur. Il faut mesurer au plus près du maillon suspect. Ce que j'ai fini par faire, assez empiriquement je l'admets :
- Horodater l'émission d'un ordre côté application.
- Horodater sa réception côté objet.
- Soustraire, et répéter une trentaine de fois pour voir la dispersion.
C'est artisanal, mais ça m'a immédiatement désigné la passerelle comme responsable. Après remplacement par un modèle qui route en local sans repasser par un serveur, mes 800 ms sont tombées sous 150 ms. Même réseau, même box, même fibre.
Choisir un protocole adapté, pas un protocole à la mode
Un objet qui parle HTTP pour signaler « porte ouverte » transporte des en-têtes démesurés par rapport à l'information utile. Les protocoles légers de type MQTT ou CoAP réduisent ce poids, et surtout permettent de maintenir une connexion ouverte plutôt que de la renégocier à chaque message. Renégocier, c'est du temps perdu, à chaque fois.
Sur les objets sur batterie, il faut arbitrer autrement. Un module LoRaWAN porte loin et consomme peu, mais ne descend pas sous la seconde. Un lien Zigbee ou Bluetooth local sera plus réactif, sur une portée bien plus courte. Il n'y a pas de bon choix dans l'absolu, seulement un bon compromis pour votre usage.
Rapprocher le traitement des données
L'aller-retour vers le cloud est souvent le poste le plus lourd. Une serrure qui doit vérifier un badge auprès d'un serveur à l'autre bout du continent ajoute, à la vitesse de la lumière dans la fibre, tout le temps de traitement du service distant. Traiter la décision en local, sur une passerelle ou un hub, supprime ce trajet.
Dans mon installation, déplacer la logique d'allumage sur un petit serveur local m'a fait gagner environ 40 % de latence globale sur les scènes domotiques. Ça ne coûte rien de plus qu'un peu de configuration.
Quelles sont les solutions pour éviter la saturation du réseau Internet ?
Votre réseau domestique peut être saturé sans que votre connexion soit en cause. Le phénomène porte un nom : le bufferbloat, ou gonflement de tampon. Quand un routeur accumule les paquets dans sa file d'attente au lieu de les transmettre ou de les jeter, tous les échanges voient leur délai exploser, y compris ceux des objets connectés.
Prioriser le trafic des objets critiques
La qualité de service (QoS) sur un routeur permet de donner la priorité à certains flux. Concrètement, marquer les trames de vos objets critiques comme prioritaires évite qu'elles attendent derrière un téléchargement de plusieurs gigaoctets lancé par un autre appareil du foyer. Ça se configure en quelques minutes sur un routeur un tant soit peu sérieux.
- Isoler les objets sur un réseau Wi-Fi séparé, pour limiter la concurrence.
- Limiter le nombre d'objets qui dialoguent simultanément avec l'extérieur.
- Éviter de concentrer tous les échanges sur un même créneau horaire.
Alléger la charge inutile
Une bonne partie de la latence vient de messages qui ne servent à rien. Un capteur de température qui remonte sa valeur toutes les secondes alors que l'usage n'exige qu'une lecture par minute sature inutilement le canal radio. Et là, ce n'est pas une question de matériel : c'est une question de réglage.
Le jitter, ou gigue, complique encore les choses. Deux échanges peuvent avoir une latence moyenne correcte tout en variant fortement. Sur une commande de lumière, ça se traduit par des réactions imprévisibles : tantôt instantanées, tantôt paresseuses. C'est souvent ce qui énerve le plus, bien plus que le délai moyen.
Quelle est la latence Internet considérée comme bonne ?
Il n'y a pas de seuil universel, mais des ordres de grandeur par usage. Voici ce que j'ai fini par retenir après avoir confronté mes mesures à différents types d'objets :
| Usage | Seuil de latence raisonnable | Ce qui compte vraiment |
|---|---|---|
| Domotique simple (éclairage, prise) | Moins de 300 ms ressenti | La régularité plus que la valeur |
| Capteurs de reporting (température, humidité) | Quelques secondes tolérées | La fiabilité de l'envoi |
| Serrures et contrôle d'accès | Sous la seconde | La cohérence de la décision |
| Automatisation industrielle | Dizaines de millisecondes | La gigue et la perte de trames |
Pour un usage domestique, on considère généralement qu'une latence sous les 100 ms passe pour instantanée, et qu'au-delà de 300 ms l'utilisateur commence à percevoir un délai. Pour un thermostat, en revanche, plusieurs secondes ne dérangent personne. Le seuil « bon » est donc celui qui ne se remarque pas dans votre contexte.
Pourquoi ai-je des variations de latence ?
Vous avez testé une fois, c'était rapide, et le lendemain c'est lent. Ce n'est pas une illusion. Trois causes expliquent l'essentiel de mes propres variations.
Congestion et retransmissions
Aux heures de pointe, le réseau local et les interconnexions se chargent. Une trame qui se perd en chemin est renvoyée, et ce renvoi ajoute un délai complet. Sur un lien radio, c'est encore plus marqué : un canal encombré multiplie les collisions.
Le réveil des services distants
Un serveur qui met son service en veille pour économiser ses ressources le réveille à la première requête. Ce réveil peut prendre plusieurs centaines de millisecondes. Le premier appel de la journée est souvent le plus lent, tout simplement parce que le service s'endormait.
L'environnement radio
Un four à micro-ondes allumé, un voisin qui installe un nouvel appareil sur le même canal : le spectre change, et votre objet le ressent. J'ai eu des variations inexpliquées pendant une semaine avant de réaliser qu'un routeur voisin occupait mon canal Wi-Fi.
Bref : une latence qui varie n'est pas forcément un défaut de conception, c'est le signe d'un système vivant, chargé, en mouvement. Ce qui compte, c'est de mesurer sa dispersion, pas seulement sa moyenne.
Ce qu'il faut retenir, en une idée
La latence d'un objet connecté n'est presque jamais un problème de débit, et rarement un problème de fournisseur. Dans mon expérience, elle se cache dans le dernier mètre de votre logement, dans un protocole mal choisi, ou dans un aller-retour vers un serveur qui n'avait rien à faire là.
On passe beaucoup de temps à chercher la bande passante qu'on n'utilise pas. Alors qu'un aller-retour à travers le cloud coûte, en temps, bien plus que la fibre ne vous volera jamais.