Topologie réseau d'un laboratoire robotique et calcul IA

Un laboratoire de robotique n'est ni un bureau, ni un centre de données, ni un labo maison. C'est un réseau réduit mais exceptionnellement exigeant : une poignée d'appareils aux profils de trafic très différents partagent le même câble. Un humanoïde diffuse de la vidéo stéréo vers un serveur d'inférence. Une station de travail de développement télécharge un checkpoint de modèle de 70 GB. Un quadrupède fait les cent pas à la recherche de sa station d'accueil. Un port IPMI rapporte tranquillement la vitesse d'un ventilateur.

Si la topologie est mauvaise, les symptômes sont pénibles et indirects : un robot saccade dès qu'un collègue pousse une image Docker ; la latence de queue du serveur d'inférence double quand quelqu'un rejoint le Wi-Fi ; la synchronisation de gradients vers votre machine de fine-tuning connaît mystérieusement des pics de 200 ms à l'heure du déjeuner. Si elle est bonne, le réseau reste invisible — et c'est la seule chose que vous lui demandez.

Cet article porte sur la bonne forme à donner à ce réseau en 2026. Public visé : les intégrateurs et les constructeurs de laboratoires qui montent le « labo clé en main » — un à quatre robots, un ou deux serveurs d'inférence Kentino AI, quelques stations de travail de développement, plus le stockage et l'administration qui relient le tout. Ni architecture de référence d'hyperscaler, ni montage de labo maison à petit budget. Exactement l'entre-deux.

La cible : le « labo clé en main »

Le déploiement de référence retenu pour cet article :

• 1 à 4 robots — humanoïdes, quadrupèdes ou un mélange des deux. Wi-Fi 6E en principal, liaison filaire optionnelle pendant le développement.
• 1 à 2 serveurs d'inférence Kentino AI — 4 ou 8 GPU (5090 / RTX Pro 6000 Blackwell), sous vLLM / SGLang pour les VLM et les LLM.
• 1 à 2 baies de stockage / NAS — jeux de données, checkpoints, journaux de capteurs enregistrés. En général une machine ZFS avec cache NVMe.
• 2 à 6 stations de travail de développement — des ingénieurs sous ROS 2 et Isaac Sim, qui entraînent des fine-tunes et déplacent des données.
• Plan d'administration — IPMI/BMC sur chaque serveur, switchs, points d'accès, un hôte DNS/DHCP local.

Au total : 15 à 40 équipements réseau actifs. Un seul switch suffirait électriquement. Si la conception ci-dessous en compte deux, ce n'est pas une question de capacité — c'est une question de domaine de panne, de budget PoE et de volonté de séparer physiquement le trafic des robots de celui des GPU, pour qu'aucun des deux n'affame l'autre.

Topologie physique

Deux switchs physiques, un pare-feu, un ou deux points d'accès. Les serveurs Kentino AI arrivent sur le cœur en 25 GbE ; le switch d'accès agrège les stations de travail et les points d'accès ; les robots se connectent via un SSID 6 GHz dédié.

Deux switchs physiques, un pare-feu, un ou deux points d'accès. Les serveurs Kentino AI et la baie de stockage arrivent sur le switch cœur en 25 GbE. Le switch d'accès récupère les équipements filaires mais plus lents — stations de travail, points d'accès, IPMI, caméras — et remonte vers le cœur en 10 GbE. Les robots arrivent en Wi-Fi 6E sur un SSID dédié.

Pourquoi du 25 GbE entre le cœur et le Kentino AI ? Parce que la carte ConnectX-6 Lx double port SFP28 est la carte crédible la moins chère en 2026 (700 à 900 € sur le marché, parfois moins en occasion) et que le 25 GbE suffit largement à l'agrégation d'inférence d'un serveur unique. Un modèle 70B en Q4 qui diffuse des tokens vers quatre robots à la fois se compte en dizaines de Mbit/s. Un transfert de checkpoint est l'événement de bande passante de la journée, et le 25 GbE avale 100 GB en ~35 secondes. Les clients qui font de l'entraînement multi-nœuds ont besoin de 100 GbE — le sujet est traité dans N01 et N08 — mais c'est un autre réseau que celui de cet article.

Dimensionnement des débits

Deux choses à intégrer :

• Vous n'avez pas besoin de 100 GbE dans un labo à serveur unique. On le spécifie parce que la fiche technique fait impression. Le débit réseau réellement soutenu par le serveur Kentino AI, ce sont les « tokens sortants » (Mbit/s) plus quelques transferts de checkpoints (quelques Gb/s). Le câble n'est jamais le goulet d'étranglement dans un labo dédié à l'inférence.
• Le Wi-Fi est toujours le maillon le plus lent. Concevez en conséquence. Une bonne liaison 6 GHz vers un client Wi-Fi 6E atteint 1,2 à 1,8 Gb/s de débit réel à 10 m en vue directe, avec 3 à 8 ms de latence et une gigue de ±2 ms dans des conditions correctes. Les flux de capteurs d'un robot (une ou deux caméras RGB-D en 1080p30 chacune) demandent ~150 à 300 Mb/s en continu ; la marge est confortable — jusqu'à ce que quelqu'un d'autre rejoigne le SSID.

Segmentation en VLAN

Si ce réseau compte six VLAN, ce n'est pas par hygiène d'entreprise. C'est pour qu'un équipement qui dysfonctionne ne gâche pas la journée d'un autre.

La séparation qui surprend : les robots et les Kentino AI sont sur des VLAN différents alors même qu'ils communiquent en permanence. Le routage inter-VLAN est l'affaire du pare-feu/routeur, et c'est là qu'on impose qui a le droit de parler à qui. Si robots et Kentino AI partageaient un VLAN, un robot compromis (et les humanoïdes grand public arrivent avec leur lot de surface d'attaque) disposerait d'un accès L2 à plat au serveur GPU. C'est un « non » catégorique dans tout déploiement un tant soit peu sérieux.

L'autre séparation à défendre : le plan d'administration a son propre VLAN, point final. Les interfaces IPMI/BMC sont livrées avec des portes dérobées constructeur depuis vingt ans, et il faut partir du principe que ce sera toujours le cas. Elles ont leur sous-réseau, leurs règles d'accès, et personne ne les route sauf un portable d'administration sur le VLAN d'administration.

Règles de pare-feu

Refus par défaut entre VLAN. Puis les exceptions :

Deux règles tranchées qui méritent d'être soulignées :

• Les robots n'ont aucune sortie internet. On y résiste, parce que cela casse la télémétrie et les mises à jour de firmware du constructeur. Tant mieux. Mettez le serveur de mise à jour du constructeur en liste blanche le temps d'une fenêtre de maintenance, puis refermez. L'état par défaut est : « ce robot ne peut pas téléphoner à la maison ».
• La sortie WAN des Kentino AI se fait à la demande. Le temps d'un téléchargement de modèle ou d'une récupération de conteneur, ouvrez le 443. Le reste du temps, laissez-le fermé. Le serveur d'inférence n'a rien à faire sur le web, et vous ne voulez pas que le script curl d'un développeur curieux serve de porte d'entrée à un ver qui exfiltrera votre jeu de données.

Configuration Wi-Fi

L'erreur la plus courante dans un déploiement Wi-Fi de labo de robotique, c'est « mettons simplement les robots sur le SSID du bureau ». Ce SSID est partagé avec des téléphones, des portables, des imprimantes, un frigo connecté et trois personnes en visioconférence Teams. La variance de latence est brutale et le comportement réactif du robot s'effondre.

La bonne réponse :

• Un SSID par VLAN. « lab-robots » sur le VLAN 10, « lab-dev » sur le VLAN 30, « lab-guest » sur le VLAN 99. Le VLAN d'administration n'a aucune présence sans fil.
• Le SSID robotique est exclusivement en 6 GHz. Pas de 2.4 GHz, pas de repli en 5 GHz. Oui, cela veut dire que les appareils anciens ne peuvent pas s'y connecter — c'est précisément le but. Le 6 GHz souffre de bien moins de contention, car la population d'appareils hérités y est quasi nulle en 2026.
• Largeur de canal de 80 MHz, pas 160. Le 160 MHz fait mieux sur la fiche technique, mais deux points d'accès en 160 MHz dans le même bâtiment se marchent dessus. Le 80 MHz en 6 GHz vous laisse quatre à six canaux propres et une latence prévisible.
• Un point d'accès par tranche de ~60 à 80 m² de zone de travail du robot, en vue directe si possible. Si le labo a des cloisons, ajoutez un point d'accès. L'itinérance fonctionne bien en Wi-Fi 6E avec le 802.11r/k/v activé, mais un robot en pleine tâche n'apprécie guère un événement de roaming.
• Désactivez l'équité de temps d'antenne sur le SSID robotique. Le réglage par défaut favorise les clients lents ; vous voulez que le robot, seul utilisateur de ce SSID, obtienne chaque créneau d'antenne.

Côté matériel 2026 : les UniFi U6 Enterprise (Wi-Fi 6E, ~450 €) ou les plus récents U7 Pro / E7 (Wi-Fi 7, 189 € / 499 € et plus) sont les choix les plus rentables. Les Aruba série 650 et les Cisco Meraki série MR sont les alternatives de classe entreprise, à deux ou trois fois le prix ; le plan d'administration est plus agréable et les radios se comportent mieux à forte densité de clients, deux atouts dont un labo unique équipé de deux robots n'a tout simplement pas besoin.

Synchronisation du temps — PTP et NTP

La dérive d'horloge entre le robot et le serveur casse la fusion de capteurs de façon subtile et embarrassante. Un écart de 20 ms fait produire des objets fantômes à une chaîne de profondeur stéréo. Un écart de 100 ms fait croire au planificateur de manipulation que la pince se trouve là où elle n'est pas.

Deux niveaux de solution :

• NTP avec chronyd contre un serveur de strate 1 local (un Raspberry Pi avec un chapeau GPS, ~80 € tout compris, ou le pare-feu en strate 2). Atteint ~1 ms de précision sur un LAN filaire, ~5 à 20 ms en Wi-Fi. Suffisant pour la plupart des travaux de robotique.
• PTP (IEEE 1588v2) avec horodatage matériel sur des switchs qui le gèrent. Les séries MikroTik CRS3xx/CRS5xx prennent en charge l'horloge de frontière PTP avec une synchronisation de l'ordre de la nanoseconde ; les Aruba CX 6300 et les Cisco Catalyst le font également. Atteint la sous-microseconde sur les chemins filaires, la sous-milliseconde en Wi-Fi.

Pour 1 à 2 robots, le NTP suffit. Faites tourner chronyd sur chaque nœud, pointez-le vers le maître local, surveillez l'écart et alarmez au-delà de >5 ms de dérive. Pour quatre robots ou plus, ou tout déploiement faisant de la fusion multi-capteurs entre machines, utilisez PTP côté filaire et NTP en secours. Dans tous les cas, surveillez la dérive. Les labos qui « ont la synchronisation du temps » parce qu'ils ont lancé apt install ntp une fois il y a deux ans sont nombreux.

DNS, DHCP et IPAM

Un résolveur local sur le plan d'administration, point. Pi-hole ou Unbound sur une petite VM fait l'affaire. Les raisons :

1. Les robots et les serveurs d'inférence doivent résoudre vllm.lab.local, nas.lab.local, etc. sans aller-retour vers le WAN.
2. Vous voulez un seul endroit où ajouter une entrée d'hôte quand vous montez un nouveau point de terminaison Kentino AI.
3. Pi-hole vous offre gratuitement un blocage publicité/télémétrie à l'échelle du réseau, qui tient le trafic de « phone home » des constructeurs à l'écart de vos câbles.

Un DHCP par VLAN, configuré sur le pare-feu/routeur (UDM Pro Max, OPNsense et pfSense s'en acquittent tous très bien). Des réservations pour tout ce qui compte — robots, serveurs, points d'accès, IPMI, switchs, NAS. Les plages dynamiques sont réservées aux visiteurs et aux stations de travail éphémères. Un robot qui reçoit une adresse IP différente à chaque redémarrage est un robot dont les fichiers de lancement ROS 2 cassent tous les mardis.

Supervision

Un labo sans supervision est un labo où l'on diagnostique les problèmes par leurs conséquences. Déployez la pile standard sur le plan d'administration :

• Prometheus qui collecte le SNMPv3 des switchs, les compteurs des cartes réseau (node_exporter), les métriques GPU (dcgm_exporter) et celles du serveur d'inférence (vLLM expose nativement du Prometheus).
• Grafana et ses tableaux de bord : utilisation par port, débit par VLAN, température et utilisation des GPU, dérive PTP/NTP, disponibilité de la connectivité des robots.
• Des alertes qui se déclenchent vraiment : compteur de pauses PFC > 0 sur un port (signe que quelqu'un congestionne du RDMA, que vous ne devriez pas avoir sur ce réseau, mais vérifiez quand même), température GPU > 80 °C, dérive temporelle > 5 ms, anomalie du nombre de clients sur un point d'accès.

Du SNMPv3, pas du v2c. Le labo est assez petit pour que le surcroît de configuration tienne en quinze minutes, et le gain de sécurité est réel.

Nomenclature concrète — 1 serveur, 2 robots, 4 stations de travail

Une liste d'achats réaliste et honnêtement chiffrée pour le déploiement de référence, en EUR HT, mi-2026 :

À titre de comparaison : le serveur Kentino AI à 8 GPU coûte à lui seul 40 à 70 k€, et chacun des deux humanoïdes 30 à 80 k€. Le réseau représente 5 à 10 % de la dépense totale, et c'est la partie la plus susceptible de faire la différence entre un labo qui fonctionne et un labo qui ne fonctionne pas.

Si le budget est serré, les coupes crédibles : passer le switch cœur à un MikroTik CRS504-4XQ-IN (4× QSFP28, éclatés en 16× 25 GbE, ~700 €) en acceptant moins de ports ; un seul point d'accès si la zone de travail fait <60 m² ; renoncer à la source NTP GPS et se contenter de chrony via le WAN.

Erreurs classiques

Classées en gros par fréquence :

• Mélanger le trafic robotique et le Wi-Fi bureautique. La variance de latence tue le comportement réactif. Le premier correctif, à chaque appel « mon robot a des à-coups », c'est « donnez-lui son propre SSID en 6 GHz ».
• Des buffers sous-dimensionnés sur des switchs bon marché. Un switch 10G 8 ports à 200 € gère deux appareils sans problème et s'effondre quand quatre nœuds tapent sur le même uplink. Le trafic IA est en rafales ; les buffers du switch absorbent la rafale. Le switch à buffers profonds le moins cher et crédible de cet article est l'Aruba CX 6300 (8/16/32 MB de buffer partagé) ; le MikroTik CRS5xx est plus juste, mais suffisant pour un labo à serveur unique.
• Pas de maître PTP, pas d'audit NTP. La synchronisation du temps « marche » jusqu'au jour où elle ne marche plus, et entre-temps la fusion de capteurs échoue en silence. Surveillez l'écart et alarmez.
• Un budget PoE mal calculé. Un switch annonce du « PoE++ » et vous découvrez que son budget total est de 200 W, dont la moitié est consommée par les caméras dont personne ne vous avait parlé, et le point d'accès décroche au démarrage. Additionnez les puissances et gardez 30 % de marge.
• Un robot autorisé à téléphoner à la maison. Mise à jour de firmware du constructeur un mardi matin, qui télécharge un nouveau modèle, qui change la latence d'inférence embarquée, qui casse le timing de la pince. À chaque fois. Filtrez la sortie WAN du robot ; pilotez les mises à jour à la main.
• Aucune supervision avant la panne. Le labo tourne bien pendant six mois. Puis le point d'accès se met à lâcher des clients deux fois par jour et personne ne s'en aperçoit pendant une semaine, faute de tableaux de bord. Quand quelqu'un finit par creuser, quatre autres choses ont changé et plus personne ne sait ce qui a lâché en premier.

Notre avis sans détour

La plupart des labos de robotique sur-dimensionnent leur réseau et sous-dimensionnent ce qui compte vraiment. On spécifie des dorsales 100 GbE pour des labos d'inférence à serveur unique, puis on met le robot sur le Wi-Fi du bureau. On achète un Cisco Catalyst 9300X à buffers profonds, puis on exploite un L2 à plat sans la moindre segmentation en VLAN.

La conception 80/20 pour un labo 2026 à serveur unique et 1 à 4 robots est modeste et peu spectaculaire :

• Du 25 GbE entre le switch cœur et le serveur Kentino AI. Une carte réseau, un DAC, terminé.
• Du 10 GbE entre le cœur et l'accès. Deux DAC.
• Un switch cœur, un switch d'accès, un pare-feu, un ou deux points d'accès.
• Six VLAN, un pare-feu en refus par défaut, des SSID distincts par usage.
• Du NTP depuis une source locale, supervisé.
• Prometheus + Grafana sur une petite VM.

Dépense réseau totale : moins de 7 k€. Temps de mise en service : environ une semaine si le câblage est prêt. Cela porte un vrai labo de production ; l'étage au-dessus — dorsale 100 GbE, Clos routé, switchs IA à buffers profonds — relève de l'entraînement multi-serveurs, le territoire de N04, N08 et K02.

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.