Un client est arrivé avec un cahier des charges clair : « sans fil, basse latence ». Il développait un système de commande moteur à distance et était convaincu que le lien radio était l’obstacle entre lui et un produit qui fonctionne.
Trois semaines plus tard, on avait un lien de communication avec 15 ms de round-trip. Largement acceptable pour la plupart des applications. Le moteur restait lent à répondre. Pas à cause de la latence sans fil : parce que la constante de temps mécanique du moteur était autour de 300 millisecondes. On aurait commandé ce moteur par signaux de fumée et obtenu le même résultat.
Cette conversation revient souvent. « Basse latence » est une de ces spécifications qu’on écrit sans la mesurer.
Commence par ton système, pas par ton radio
Avant de choisir un protocole sans fil, mesure ce dont ton système a réellement besoin. Un moteur avec une constante de temps de 300 ms ne tire aucun bénéfice d’un lien radio à 1 ms. Une synchronisation de shutter vidéo a besoin d’une précision sous la milliseconde. Un contrôleur de vol pour drone se situe quelque part entre les deux.
Le chiffre à trouver, c’est le temps de réponse naturel de ton système : la constante de temps d’un actionneur physique, la cadence de ton pipeline d’imagerie, la période de ta boucle de contrôle embarquée. Ce chiffre te donne ton budget de latence. Tout lien sans fil plus rapide que ce budget représente des performances pour lesquelles tu paies sans jamais les utiliser.
Latence et gigue ne sont pas la même chose
La plupart des ingénieurs pensent à la latence moyenne. Les ingénieurs expérimentés pensent à la gigue (jitter).
La latence, c’est le délai moyen. La gigue, c’est la variation autour de cette moyenne. Pour les systèmes temps réel, c’est souvent la gigue qui est la contrainte qui compte.
Voilà pourquoi : si ta boucle de contrôle tourne à 100 Hz, tu as une fenêtre de 10 ms par cycle. Si ton lien sans fil a une latence moyenne de 5 ms mais une gigue de ±6 ms, ta boucle rate occasionnellement sa fenêtre d’une milliseconde, puis attend 11 ms pour le paquet suivant. Un système contrôlable en moyenne devient imprévisible en pratique.
La façon rigoureuse de spécifier la gigue, c’est d’utiliser les niveaux sigma. Le 3-sigma capture 99,73 % des événements : acceptable pour la plupart des applications. Le 6-sigma capture 99,9999998 % des événements : pertinent quand un seul paquet en retard provoque un incident de sécurité ou une coupe ratée. Si tu conçois un dispositif médical ou une machine à grande vitesse, tu dois savoir quel niveau sigma ton système exige, puis mesurer que ton hardware le respecte avant de livrer. La plupart des datasheets de stacks sans fil ne publient pas la gigue à 6-sigma. Tu dois la mesurer toi-même.
Les compromis technologiques
L’éventail des options sans fil est large, et « basse latence » signifie des choses très différentes selon les protocoles.
Le BLE (Bluetooth Low Energy) a des intervalles de connexion aussi courts que 7,5 ms, ce qui donne une latence de round-trip d’environ 15 ms minimum en pratique, souvent plus avec les surcharges de la stack. Bien adapté aux dispositifs sur batterie, gigue modérée, pas fait pour du contrôle temps réel déterministe.
Les liens propriétaires 2,4 GHz ou sub-GHz peuvent atteindre 1 à 5 ms de round-trip avec une faible gigue si tu contrôles toute la stack. Pas de garanties de coexistence dans les environnements RF encombrés, mais dans un cadre maîtrisé, ils performent bien.
Le Wi-Fi peut descendre à 1-5 ms sur un canal dégagé, mais le profil de gigue est mauvais. Le trafic de fond, la contention de canal et les modes économie d’énergie introduisent des pics. Ce n’est pas mon premier choix pour des boucles de contrôle serrées.
Le 5G URLLC promet une latence d’interface radio sous la milliseconde. Le problème, c’est la dépendance à l’infrastructure. Sauf si tu déploies une cellule 5G privée, tu es soumis à des conditions réseau hors de ton contrôle.
Les protocoles maillés (Zigbee, Thread, Matter) ajoutent une latence par saut. Chaque saut ajoute typiquement 5 à 30 ms. Si ton capteur est à trois sauts de la passerelle, prévois en conséquence.
La question que personne ne pose avant qu’il soit trop tard
Les liens sans fil tombent. Rarement, pas longtemps, mais ils tombent. Interférences, obstruction physique, bruit RF d’un variateur ou d’un chauffage à proximité : une coupure momentanée est une certitude statistique sur la durée.
La question à répondre à la conception : que se passe-t-il quand le lien est coupé ?
Un contrôleur moteur à distance qui perd son lien sans fil pendant 200 ms, est-ce qu’il arrête le moteur ? Garde la dernière commande ? Entre dans un état de sécurité ? Rentre à l’origine ? Ce sont des décisions d’ingénierie, pas des détails d’implémentation. Elles doivent être dans le cahier des charges avant de choisir un radio.
Dans tous les systèmes sans fil que j’ai construits, concevoir le mode dégradé représentait au moins autant de travail que le chemin nominal. Les projets qui se sont bien passés étaient ceux où le comportement en cas de défaillance était acté avant qu’une seule ligne de code soit écrite. Ceux qui ont dérapé étaient ceux où la question est arrivée à l’intégration.
Une note sur le délai de propagation
Une chose qui surprend souvent : les ondes électromagnétiques voyagent à environ 3×10⁸ m/s dans l’air, soit essentiellement la vitesse de la lumière dans le vide. Ça semble rapide jusqu’à ce qu’on fasse le calcul. Un lien de 300 mètres introduit environ 1 microseconde de délai de propagation. Pour la plupart des applications, c’est négligeable. Pour la synchronisation temporelle de précision ou les spécifications sous la milliseconde, ça vaut la peine de savoir que la physique impose un plancher, même avant que ta stack radio n’ajoute ses propres surcharges.
Le vrai travail
La prochaine fois qu’un cahier des charges dit « sans fil basse latence », demande un chiffre. Quelle est la constante de temps du système ? Quel niveau de gigue est acceptable, et à quel sigma ? Que se passe-t-il en cas de coupure ?
Ces trois questions t’apprendront plus sur quel radio choisir que n’importe quelle comparaison de datasheets.