Réseaux pour robots : Wi-Fi, liaisons filaires, 5G et pourquoi la latence compte

Un humanoïde est un nœud mobile sur un réseau qui a presque certainement été conçu pour des ordinateurs portables immobiles. Ce décalage est à l'origine d'environ 95% des tickets « le robot est bizarre aujourd'hui » que vous ouvrirez un jour. Les contrôleurs moteurs vont bien. Le Jetson va bien. Le modèle sur le serveur IA Kentino va bien. C'est le Wi-Fi qui ne va pas.

Cet article porte sur la seconde moitié du schéma à deux boîtes de I01 — plus précisément sur le lien au milieu. Le robot que vous avez acheté ne vaut que ce que vaut le réseau sur lequel vous le placez, et ce réseau a probablement besoin d'être refait avant de mériter le mot « correct ».

Public visé : intégrateurs, responsables de laboratoire et équipes informatiques à qui l'on a annoncé l'arrivée d'un humanoïde le mois prochain et qui n'ont pas encore réalisé que le Wi-Fi d'entreprise existant va mettre tout le monde dans l'embarras.

Pourquoi le réseau des robots est un problème à part

La plupart des réseaux Wi-Fi d'entreprise sont dimensionnés pour des usages humains : téléchargements par à-coups, visioconférences occasionnelles, longues périodes d'inactivité. Un humanoïde ne fait rien de tout cela. Il génère un flux duplex continu de messages de commande à faible débit, des rafales intermittentes de données d'image à destination du serveur d'inférence et un filet régulier de télémétrie. Le flux de commande est léger (quelques kilo-octets par seconde) mais pathologiquement sensible à la gigue. Les rafales d'images sont lourdes (des dizaines à des centaines de mégaoctets par seconde en brut) et exigent un chemin large. La télémétrie est tolérante et n'intéresse personne.

Ce qui rend ce problème unique :

• Le nœud se déplace. Le robot franchit la frontière entre deux cellules d'AP, et l'événement de roaming fait perdre des paquets pendant 50 à 500 ms selon la configuration du réseau. L'utilisateur d'un ordinateur portable ne le remarque pas. Le contrôleur d'équilibre d'un robot, si.
• L'environnement RF est hostile. Un laboratoire de 30 m² avec deux ingénieurs, trois ordinateurs portables, une machine à café connectée en Wi-Fi et un four à micro-ondes constitue un environnement RF parfaitement banal, qui massacrera sans pitié une liaison robot à 5 GHz. L'ombre portée par le corps du robot lui-même bloque le signal dans des directions imprévisibles lorsqu'il pivote.
• Les interférences entre robots s'additionnent. Deux G1 dans la même pièce sur le même canal ne coopéreront pas gracieusement. Trois, c'est un problème. Une flotte de huit exige une vraie planification.
• Les protocoles au-dessus de la radio sont eux aussi fragiles. La configuration DDS par défaut de ROS 2 repose sur le multicast IP pour la découverte. Le Wi-Fi gère mal le multicast. La combinaison produit des tickets « les nœuds ne se voient pas » qui ressemblent à des bugs du robot.

Tout cela se résout. Rien n'est résolu par défaut.

Wi-Fi 6E : le socle actuel

Le point de départ honnête, en 2026, pour un déploiement Wi-Fi de robotique, c'est le Wi-Fi 6E avec un SSID 6 GHz dédié aux seuls robots. Pas du Wi-Fi 6. Pas du 5 GHz « on corrigera plus tard ». 6E, 6 GHz, SSID séparé, VLAN isolé.

La raison tient à la propreté du spectre, pas au débit affiché. La bande 6 GHz est assez récente pour que la camelote grand public ne l'ait pas encore envahie. Pas de Bluetooth sur 6 GHz, pas d'harmonique de four à micro-ondes, pas d'imprimante vieille de quinze ans qui diffuse ses balises. La radio de votre robot dispose d'un canal propre. Ce canal propre vaut plus que n'importe quelle amélioration sur fiche technique.

Voici le RTT réel d'un robot en Wi-Fi 6E, mesuré du CPU du robot jusqu'au serveur d'inférence, côté filaire de l'AP :

Une liaison 6 GHz propre offre un RTT de l'ordre de quelques millisecondes, assez régulièrement pour que les nœuds ROS 2, les clients gRPC vers vLLM et la téléopération paraissent réactifs. Le même robot basculé sur un SSID 5 GHz partagé semblera « lent » d'une façon que personne ne saura chiffrer avant de l'avoir mesurée.

Wi-Fi 7 en 2026 : prise en charge limitée, promesse réelle

La fonction phare du Wi-Fi 7 est le Multi-Link Operation (MLO) — la radio agrège deux ou trois bandes (2.4/5/6 GHz) simultanément et, soit cumule le débit, soit réplique les paquets sur plusieurs liens pour la fiabilité. La réduction de latence du Wi-Fi 7 par rapport au 6E est réelle là où le MLO est activé : les fabricants annoncent 50 à 75% de latence en moins, et les mesures en conditions contrôlées situent le RTT Wi-Fi 7 MLO entre 1.5 et 4 ms, contre 3 à 6 ms en Wi-Fi 6E. Le marketing évoque parfois la sous-milliseconde, ce qui n'a pas été reproduit sur du matériel robotique.

Le hic, c'est la radio du robot. À la mi-2026, les plateformes humanoïdes courantes (Unitree G1/H1, Booster T1, EngineAI PM01/SE01) sont livrées en Wi-Fi 6 ou 6E. Aucune n'annonce le Wi-Fi 7 sur sa version de base. Placer un AP Wi-Fi 7 devant un robot Wi-Fi 6E vous donne un backhaul Wi-Fi 7 et une liaison robot en 6E — c'est très bien, mais vous payez une capacité que vous ne pouvez pas encore exploiter.

Quand le Wi-Fi 7 commencera à compter pour les robots :

• Quand le robot sera livré d'origine avec un module Wi-Fi 7 (attendu sur les plateformes de 2027).
• Quand le MLO pourra répliquer le flux de paquets du plan de commande simultanément sur 5 GHz et 6 GHz, supprimant les évanouissements mono-bande.
• Quand vous déploierez une flotte assez grande pour que la congestion d'une seule bande devienne le goulot d'étranglement, indépendamment de la latence.

Pour un laboratoire à un seul robot en 2026 : le 6E suffit. Pour une flotte prévue à partir de 2027 : spécifiez dès aujourd'hui des AP Wi-Fi 7, afin de ne pas racheter le réseau dans dix-huit mois.

Placement et densité des points d'accès

Le réflexe est de monter un AP au plafond, dans un coin de la pièce. Résultat : une zone morte d'un demi-mètre derrière la paillasse, précisément là où le robot perd le signal pendant la démo que vous aviez programmée.

Des règles empiriques qui fonctionnent :

La vue directe l'emporte sur la puissance. Un AP de 30 dBm derrière un rack métallique délivre un signal moins bon qu'un AP de 20 dBm fixé au plafond au milieu de la pièce. Les robots sont petits : une antenne placée sur le torse à 1.2 m ne voit pas le même environnement RF qu'un ordinateur portable posé sur un bureau à 0.7 m, et le voit moins bien qu'un téléphone à 1.5 m. Les AP au-dessus de 2.5 m, les robots en dessous de 1.5 m, et aucun obstacle de la taille d'une personne sur le trajet dominant.

SSID de robotique dédié. Non négociable. Le SSID des robots a son propre VLAN, son propre profil de QoS, sa propre plage DHCP et aucun trafic grand public. Mettre le robot sur le Wi-Fi du personnel fonctionne une semaine en développement, après quoi un stagiaire du marketing rejoint une visioconférence et le robot tombe.

L'ombre du corps — le problème de l'antenne

Le torse d'un humanoïde est une boîte d'acier et de plastique d'environ 30 cm de large. L'antenne radio se loge généralement quelque part dans la plaque de poitrine, souvent à l'arrière ou sur un côté. Lorsque le robot se détourne de l'AP, son corps devient une cage de Faraday partielle.

La perte de signal est généralement de 6 à 15 dB selon l'emplacement de l'antenne et la quantité de métal du torse. Cela suffit à faire passer une liaison limite de « fonctionne très bien » à « coupe toutes les quelques secondes » par simple rotation. Les quadrupèdes en souffrent moins, car ils sont plus bas, plus plats, et leur antenne se trouve généralement sur un bord de châssis avec une vue dégagée vers le ciel.

Ce qui aide :

• Antenne sur la tête ou les épaules, pas sur le torse. Certains humanoïdes de niveau recherche permettent de déplacer l'antenne ou d'en ajouter une externe. La plupart des modèles grand public, non. Renseignez-vous avant l'achat si la fiabilité RF est une exigence du déploiement.
• Deux AP en diversité. Avec des AP sur des murs opposés, le robot est « face » à l'un d'eux quelle que soit son orientation. Le roaming entre AP gère la bascule — mal, mais mieux que l'absence de signal.
• Des antennes plus basses côté AP. Si vos AP sont au plafond à 3 m et l'antenne du robot à 1.0 m, l'angle d'élévation est assez prononcé pour que le torse bloque une bonne partie du trajet. Des AP muraux à 2 m offrent un trajet plus plat et plus facile.

Le câble de liaison : comment travaillent les équipes sérieuses

Toute équipe de robotique sérieuse a un câble de liaison. La plupart n'en parlent jamais, parce que cela gâche l'esthétique « regardez, sans fil » de la démo. Quiconque fait un vrai travail d'intégration branche le robot.

Ce lien est un câble USB-C, un câble Ethernet M12 X-code ou, sur les unités de niveau recherche, un ombilical spiralé transportant à la fois l'alimentation et les données. La bande passante est de 1 Gbps ou plus ; la latence est inférieure à la milliseconde en aller-retour, souvent sous les 200 µs. C'est deux ordres de grandeur de mieux que la meilleure liaison Wi-Fi.

La raison pour laquelle on câble pendant le développement n'est pas la bande passante : c'est l'élimination de la variable. Quand le Wi-Fi est capricieux, impossible de savoir si c'est votre nœud ROS 2 qui est lent, le modèle qui est lent, ou l'air qui est mauvais. Branchez-vous, et il n'y a plus d'air. Tout le reste devient plus simple à déboguer.

L'Unitree G1 EDU et le Booster T1 proposent tous deux des solutions de câblage crédibles. Le H1 est malcommode à câbler. Les PM01 et SE01 prennent en charge le câblage de développement via USB-C ou Ethernet standard. Les quadrupèdes (Go2) sont rarement câblés, leur cas d'usage étant l'extérieur ; si vous faites de l'apprentissage par renforcement sérieux en intérieur sur l'un d'eux, vous pourriez quand même y avoir intérêt.

Réseaux 5G privés : quand cela vaut le coût

La 5G privée — votre propre réseau cellulaire sur site, sous licence ou en spectre partagé — est devenue un « vrai produit » en 2025 et se déploie à grande échelle en 2026. La technologie fonctionne.

Quand la 5G privée a du sens :

• Les grands sites extérieurs. Installations de plusieurs hectares, mines, grandes exploitations agricoles, ports. Les cellules Wi-Fi ne passent pas à l'échelle ici : le nombre d'AP et l'effort d'étude dépassent le coût d'un seul réseau 5G à petites cellules.
• Les campus multi-bâtiments. Lorsque le robot doit passer de l'intérieur à l'extérieur et inversement, ou d'un bâtiment à l'autre, le roaming Wi-Fi devient pénible. La 5G gère la mobilité nativement.
• Les déploiements orientés mobilité. Robots d'inspection parcourant des kilomètres, robots mobiles autonomes dans de grands entrepôts, tout cas où la liaison radio doit suivre l'unité à travers le territoire.
• Une flotte mixte avec d'autres équipements 5G. Si le site dispose déjà d'une 5G privée pour des chariots élévateurs, des AGV ou des réseaux de capteurs, y ajouter des robots représente un coût marginal, pas un nouveau projet.

Quand c'est surdimensionné :

• Un seul laboratoire, un seul bâtiment, un à quatre robots. Le Wi-Fi 6E fait le travail pour 3–8 k€ d'AP. La 5G privée le fait pour 60–200 k€ de petites cellules, d'EPC/5GC, de licences de spectre et de relation fournisseur. Le rapport n'y est pas.
• Les environnements purement de développement. Le câble plus le Wi-Fi vous donnent tout ce qu'apporterait la 5G, sans rien de plus à administrer.
• Vous n'avez pas d'équipe réseau. La 5G privée, ce n'est pas « on installe et on oublie ». C'est un système de production supplémentaire à exploiter, superviser et mettre à jour.

Le budget de latence : quelles charges de travail supportent quoi

Le schéma est clair : le travail en boucle fermée reste local ou câblé, la perception avec réflexion peut passer par le Wi-Fi, la conversation peut passer par un WAN. L'erreur d'architecture consiste à placer du code proche de la boucle moteur sur un chemin exposé à la gigue réseau. L'autre erreur est de payer pour un transport à 5 ms quand la latence du modèle est de 400 ms — vous avez gagné 30 ms sur un total de 430 ms. Optimisez le terme dominant.

Le schéma « toujours un pied dans le cloud »

Même dans un déploiement strictement sur site, le robot est rarement totalement isolé du réseau. Ce qui justifie légitimement un accès WAN :

• La télémétrie vers votre propre pile de supervision (Prometheus / Grafana / Datadog). Utile, peu gourmande en bande passante, supporte n'importe quel RTT.
• Les mises à jour de modèles et de firmware. Récupération de nouveaux poids de VLM, d'images de conteneurs, de correctifs système. Par rafales, réalisables de nuit.
• Les données de carte et d'environnement. Plan du bâtiment, synchronisation de nuages de points, sauvegarde de la mémoire de scène.
• La téléopération de secours à distance. Parfois ; sous réserve d'une revue de sécurité.

Le principe est le suivant : le sur-site d'abord pour le chemin critique, une sortie WAN filtrée par pare-feu pour le reste. Le robot n'a jamais besoin d'une adresse WAN entrante. Le serveur non plus. Sortant uniquement, destinations sur liste blanche, TLS, sans exception.

Multicast, mDNS, DDS — et pourquoi le Wi-Fi les rend douloureux

ROS 2 est livré avec DDS comme middleware par défaut. DDS utilise le multicast IP pour la découverte des participants. Le Wi-Fi gère le multicast en émettant au débit le plus bas commun à tous les clients du BSSID, ce qui :

1. Gaspille du temps d'antenne.
2. Ressemble à une inondation pour le firmware de l'AP.
3. Se fait souvent rejeter par les AP d'entreprise dont la suppression du multicast est activée.

Le résultat, c'est « mes nœuds ROS 2 se voient en Ethernet mais pas en Wi-Fi » — une défaillance bien documentée et parfaitement évitable. Les pertes de paquets Wi-Fi mesurées sur du trafic ROS 2 multicast atteignent 1 à 3% même sur des liaisons saines ; en Ethernet, c'est zéro. Deux robots ROS 2 sur le même Wi-Fi peuvent déclencher des tempêtes de découverte qui déstabilisent l'AP.

Les correctifs, par ordre de préférence :

1. Utilisez le Fast-DDS Discovery Server. Faites tourner un serveur de découverte (généralement sur le serveur d'inférence ou sur une VM dédiée), pointez tous les nœuds ROS 2 vers lui en unicast, et la découverte devient un échange client-serveur classique que le Wi-Fi gère très bien.
2. Configuration statique des pairs via un profil XML. Codez en dur l'IP de l'autre extrémité. Fragile, mais efficace pour une paire fixe.
3. Activez l'IGMP snooping et la conversion multicast vers unicast sur l'AP. Aruba, Ruckus, Cisco Meraki et les firmwares UniFi récents le prennent tous en charge. Dites-le à l'ingénieur réseau : ce sont deux cases à cocher.
4. Changez d'implémentation RMW. Certains passent de Cyclone DDS à Fast-DDS ou au pont Zenoh précisément pour échapper à la sémantique de découverte multicast. En dernier recours ; cela représente un coût d'intégration.

QoS, DSCP et obtenir la priorité

Le SSID des robots a son propre VLAN ; le VLAN a son propre profil de QoS. La couche suivante consiste à s'assurer que le réseau reconnaît que le trafic des robots est plus important que la synchronisation Dropbox de l'équipe marketing.

Schéma standard :

• Marquez le trafic de commande des robots en EF (Expedited Forwarding, DSCP 46). Le flux du plan de commande est léger et critique en latence ; EF est la classe de référence pour cela.
• Marquez les flux d'images en AF41 (DSCP 34). Vidéo en temps réel, débit élevé, priorité inférieure à la commande.
• Marquez la télémétrie et les téléchargements de modèles en classe par défaut (DSCP 0). Aucun traitement particulier.
• La correspondance WMM de l'AP doit respecter ces marquages. La plupart des AP d'entreprise (Aruba, Cisco Meraki, Ruckus) le font automatiquement quand la confiance DSCP est activée. UniFi exige une configuration explicite dans les firmwares récents.

Architecture réseau concrète pour un laboratoire de robotique

Une configuration fonctionnelle pour un laboratoire de 1 à 4 robots, calibrée sur la réalité matérielle de I01 :

Réseau de laboratoire de référence : robots → AP 6 GHz dédiés → commutateur 10 GbE → serveur IA Kentino. Sortie filtrée par pare-feu, en sortant uniquement.

Pour 1 à 4 robots dans une seule pièce, cette configuration revient à 4–12 k€ de matériel réseau selon la gamme du fournisseur. Ruckus et Aruba sont les meilleurs en RF dans les environnements denses ou hostiles. Cisco Meraki l'emporte sur la simplicité, au prix d'un coût récurrent. UniFi l'emporte sur le prix et convient très bien à un laboratoire unique.

Modes de défaillance, à peu près dans l'ordre où ils vous frapperont

• Le roaming entre AP tue un flux. Le robot franchit la limite de cellule, l'association tombe pendant 100 à 400 ms, le socket ROS 2 récupère, mais un trou apparaît dans le flux de commande des journaux. À atténuer par un recouvrement des cellules, le roaming rapide 802.11k/v/r, et surtout en ne confiant pas la commande en boucle fermée au réseau.
• Interférences entre robots sur des canaux partagés. Trois G1 sur le même canal 6 GHz se marchent sur le temps d'antenne. Prévoyez des canaux 80 MHz non recouvrants en 6 GHz (il y en a sept dans l'UE, davantage aux États-Unis).
• La structure du bâtiment. Les murs en béton armé font perdre 20 à 30 dB. Les portes métalliques de salle serveur, 40 dB. Faites une étude RF du site avant de fixer les AP, à chaque fois.
• Expiration du bail DHCP en pleine tâche. Session robot longue, le renouvellement DHCP échoue, l'IP change, les sockets se rompent. Réservations DHCP statiques pour le robot. Toujours.
• Modes d'économie d'énergie. L'économie d'énergie Wi-Fi sur la radio du robot ajoute de la latence au profit de l'autonomie. Désactivez-la explicitement. L'autonomie est un problème de batterie ; ne le payez pas en gigue.
• Incohérence de MTU. Le SDK du fabricant du robot utilise 1500, votre infrastructure 9000, la fragmentation s'installe et les performances s'effondrent en silence. Alignez le MTU de bout en bout.

L'avis franc

La phrase la plus utile de cet article : 95% des « problèmes de robot » signalés le premier mois d'un déploiement sont des problèmes de configuration Wi-Fi. Le robot va bien. Le modèle va bien. C'est le Wi-Fi qui ne va pas : le SSID est partagé avec le bureau, il n'y a pas de VLAN dédié, le multicast se déchaîne, les AP sont au mauvais endroit, et l'intégrateur débogue la mauvaise couche pendant trois semaines.

Recrutez la personne réseau tôt. Payez-la plus que vous ne le pensez. L'ingénieur réseau senior capable de concevoir un plan Wi-Fi 6E, de configurer la QoS de bout en bout et de régler la découverte DDS vaut autant qu'un robôticien senior sur ce projet, et il est bien plus difficile à trouver.

---

Cet article fait partie du Kentino Wiki, une série de référence sur le calcul IA, la robotique et les systèmes qui les relient. Commentaires et corrections bienvenus à info@kentino.com.