Dans une PME industrielle de 2026, l’inventaire technique ressemble rarement à une salle serveurs. On y trouve deux ou trois serveurs, certes, mais aussi un standard téléphonique IP, quelques automates, un cobot en fin de ligne, des bornes Wi-Fi, une passerelle de télérelève. Ces équipements sont indispensables au fonctionnement quotidien, et l’outil de supervision installé pour les serveurs ne sait presque rien en dire.
Le réflexe habituel consiste à ajouter leur adresse IP à la liste surveillée, à cocher « ping », et à considérer le sujet réglé quand la ligne passe au vert. Voici pourquoi ce vert-là ne prouve pas grand-chose, et ce que ces machines savent dire d’elles-mêmes quand on les interroge dans leur langue.
Le ping mesure une pile réseau, pas une fonction
Le test de disponibilité universel repose sur le message echo request / echo reply du protocole ICMP, spécifié par la RFC 792 — un texte de 1981, antérieur de plus de dix ans au premier automate connecté en Ethernet. Une réponse établit trois choses, et seulement trois : l’interface réseau est active, la pile IP tourne, une route existe entre le superviseur et l’équipement.
Tout le reste échappe à la mesure. Un cobot en arrêt de protection, immobile parce qu’un opérateur a franchi un scrutateur laser, répond au ping avec la même régularité qu’un cobot en production. Un standard téléphonique dont le faisceau SIP vers l’opérateur est tombé répond au ping alors qu’aucun appel externe ne passe plus : en interne, poste à poste, tout fonctionne. Dans les deux cas, la supervision affiche un parc en bonne santé pendant que la production ou l’accueil téléphonique sont à l’arrêt.
Le malentendu tient à une confusion de couches : on mesure la couche 3 pour en déduire l’état d’un service applicatif situé bien plus haut. C’est le même écart que celui décrit à propos de la convergence entre systèmes informatiques et robotique : les deux mondes partagent le câble, pas les indicateurs.
Ces équipements parlent — encore faut-il ouvrir le bon canal
La bonne nouvelle est que ces machines exposent leur état interne, souvent plus finement qu’un serveur ordinaire.
Le socle commun reste SNMP. Le protocole écoute par convention sur le port UDP 161 pour les requêtes et sur le port UDP 162 pour les notifications, deux valeurs fixées par la RFC 3417. La distinction entre les deux compte : le 161 est interrogé par le superviseur à son rythme, le 162 reçoit ce que l’équipement annonce de lui-même, à l’instant de l’événement. Côté données, la MIB des interfaces (RFC 2863) distingue l’état administratif de l’état opérationnel d’un lien : une interface peut être configurée comme active et se trouver hors service.
Un robot industriel en dit beaucoup plus. Sur les bras d’Universal Robots, l’interface temps réel RTDE produit des messages d’état à la cadence de la boucle de contrôle, soit 500 Hz sur les séries e-Series et UR. On y lit le mode de sécurité — normal, arrêt de protection, arrêt d’urgence —, les courants d’articulation convertis en couples, et la température de chaque axe en degrés Celsius. Plus simple, le serveur de supervision exposé sur le port TCP 29999 permet d’interroger l’état du programme en quelques octets. Côté normalisation, la spécification OPC UA for Robotics (référence OPC 40010-1, version 1.02 publiée par l’OPC Foundation) modélise ces états indépendamment du constructeur. Or la montée en température d’une articulation ou la dérive d’un courant moteur sont des signaux d’usure : ils précèdent la panne, quand la disponibilité réseau ne bouge qu’au moment de l’arrêt.
Un standard téléphonique aussi. Deux mécanismes normalisés couvrent l’essentiel. La supervision d’un faisceau repose sur l’envoi périodique de requêtes SIP hors dialogue, dont le principe de maintien de session est décrit par la RFC 5626 : l’absence de réponse signale un faisceau injoignable avant que le premier appelant ne le découvre. La qualité perçue, elle, se lit dans les rapports étendus de RTCP définis par la RFC 3611, dont le bloc VoIP Metrics transporte le taux de perte, le taux de rejet par le tampon de gigue, la durée moyenne des rafales de perte, le délai aller-retour, un facteur R coté de 0 à 100 et les scores MOS d’écoute et de conversation. Aucune de ces valeurs n’est déductible d’un test de disponibilité.
Les ordres de grandeur qui rendent ces indicateurs lisibles
Trois chiffres cadrent le problème. Un flux voix classique émet un paquet toutes les 20 millisecondes : c’est l’intervalle de paquetisation par défaut recommandé par la RFC 3551, soit cinquante paquets par seconde et par sens de conversation. Avec un codage G.711 à 8 000 échantillons par seconde sur 8 bits, la charge utile ne représente que 64 kbit/s hors en-têtes — négligeable sur un lien d’entreprise, ce qui explique qu’un graphe de bande passante ne montre jamais rien d’une conversation dégradée.
Côté délai, la recommandation ITU-T G.114 est explicite : en dessous de 150 ms de délai de bouche à oreille dans un sens, la plupart des applications, vocales ou non, conservent une interactivité essentiellement transparente ; au-delà de 400 ms, la limite ne devrait pas être dépassée pour la planification d’un réseau. Entre ces deux bornes se joue la différence entre un standard dont on se plaint et un standard dont on ne parle pas. Le texte est consultable chez l’UIT.
Le troisième chiffre est celui qu’on oublie : le pas d’interrogation du superviseur, souvent laissé à cinq minutes par défaut. Un robot décrit son état 500 fois par seconde, un flux voix produit 50 paquets par seconde, et un collecteur qui interroge toutes les 300 secondes travaille donc trois à quatre ordres de grandeur en dessous des phénomènes qu’il prétend observer. Une micro-coupure de trois secondes — de quoi couper une communication et faire tomber un cycle robot en défaut — disparaît intégralement dans une moyenne calculée sur cinq minutes. Ce n’est pas un défaut de l’outil mais d’échelle : sur ces machines, la mesure utile est événementielle, pas périodique. D’où l’intérêt du port 162, et de tout mécanisme qui laisse l’équipement parler au lieu de l’interroger.
Recenser avant de surveiller
Aucun de ces mécanismes ne sert si l’équipement n’est pas dans la liste. C’est la raison pour laquelle l’ANSSI place la cartographie du système d’information en amont de toute démarche de protection, avec une méthode d’élaboration en cinq étapes : on ne défend, et on ne surveille, que ce qu’on a recensé. Les machines les plus mal inventoriées sont précisément celles de cet article — installées par un intégrateur, raccordées à un VLAN dédié, jamais rattachées à l’inventaire informatique. Les questions à poser avant de raccorder un bras rejoignent d’ailleurs celles que nous détaillions à propos de ce que les petits ateliers peuvent réellement automatiser.
L’événement le plus révélateur est celui qui n’arrive pas
Dernier angle mort, le plus coûteux : la panne silencieuse. Une machine qui tombe déclenche une alerte ; une machine qui cesse simplement de produire n’en déclenche aucune. Un standard sans aucun appel entrant depuis trois heures un mardi matin est en panne même s’il répond parfaitement au réseau — la cause est souvent en amont, chez l’opérateur ou sur un renvoi laissé actif. Un poste de contrôle qui ne remonte plus de cycle robot depuis la veille n’est pas au repos, il est débranché.
Détecter ces situations suppose de superviser un débit d’événements métier et d’alerter sur son absence, ce que les outils d’infrastructure ne font pas nativement puisqu’ils raisonnent en disponibilité, pas en activité. Sur le versant téléphonique, cette distinction entre surveiller un équipement et surveiller ce qu’il produit est au cœur de ce qu’on attend d’un outil capable de conduire plusieurs standards depuis un seul point : détection d’un silence de trafic anormal, fenêtres de maintenance pour ne pas alerter à tort, traçabilité des modifications de configuration.
Trois questions à poser avant d’ajouter une machine au tableau de bord
- Quel canal natif expose son état ? SNMP, OPC UA, une interface constructeur, une API HTTP, un journal : si la réponse est « le ping », la surveillance est décorative.
- À quelle cadence le phénomène se produit-il ? Le pas de mesure doit rester inférieur à la durée de l’incident qu’on veut voir, faute de quoi la moyenne l’efface.
- Que déduit-on de l’absence de données ? Une machine muette n’est pas une machine saine — règle à écrire dans la configuration, pas dans la tête de celui qui regarde l’écran.
Superviser un parc hétérogène ne demande ni outil unique ni budget considérable, mais d’admettre qu’un serveur, un bras articulé et un autocommutateur ne se surveillent pas avec le même indicateur.