Dans un entrepôt, le robot mobile n’est plus une curiosité. L’IFR (Fédération internationale de la robotique) indique, dans son communiqué du 30 septembre 2026, que le transport et la logistique restent la première application des robots de service professionnels, avec 117 500 unités vendues en 2025, soit +21 % et 47 % du marché de ces robots. Le communiqué précise qu’il s’agit principalement de transport et d’automatisation des flux de matières.
Dès que l’on dépasse une machine unique, la question change de nature. Il ne s’agit plus de savoir si un robot sait rouler, mais comment dix, cinquante ou deux cents robots, souvent de fabricants différents, reçoivent leurs missions, rendent compte de leur état et s’évitent. C’est l’objet d’une spécification encore peu connue hors du métier : la VDA 5050.
Deux familles de robots, une même question
La spécification reprend la définition de la norme ISO 3691-4 : un robot mobile est un système de transport de charges sans conducteur, quel que soit son niveau d’autonomie. Elle distingue ensuite deux familles. Les robots guidés par ligne suivent des trajectoires prédéfinies, envoyées par le gestionnaire de flotte ou connues du robot. Les robots à navigation libre planifient eux-mêmes leur trajectoire ; si le gestionnaire en impose une dans l’ordre, ils la suivent.
Cette frontière recoupe celle que le vocabulaire commercial appelle AGV (véhicule guidé) et AMR (robot mobile autonome), mais le texte n’emploie pas ces sigles : ce qui compte pour l’interface, c’est qui calcule le chemin. Dans les deux cas, un « gestionnaire de flotte » central répartit les missions et la circulation, et il lui faut un canal de communication.
Ce que fixe la VDA 5050
La VDA 5050 est développée conjointement par l’association de l’industrie automobile allemande (VDA) et par la VDMA (constructeurs de machines), sous la direction de l’institut de manutention et de logistique (IFL) du KIT de Karlsruhe, qui gère aussi le dépôt public de la spécification. La version 3.0.0 est celle publiée sur le dépôt GitHub officiel. Son usage est facultatif et non contraignant.
Son objectif est précis : réduire la complexité de raccordement d’un robot à un gestionnaire de flotte, et permettre l’exploitation coordonnée de flottes hétérogènes dans un même espace. Elle ne définit pas, en revanche, les exigences de sécurité (le texte précise qu’il ne doit pas être appliqué comme une norme de sécurité) ni la logique de gestion du trafic : routage, priorités, résolution des blocages restent le domaine du gestionnaire de flotte.
Techniquement, tout repose sur deux briques banales. Le transport est assuré par MQTT, dans sa version 3.1.1 au minimum, et les messages sont au format JSON, ce qui permet de les valider par des schémas. MQTT organise les échanges en « sujets » (topics) auxquels chaque participant s’abonne. La spécification en impose plusieurs, parmi lesquels :
- order : l’ordre de transport, du gestionnaire vers le robot ;
- instantActions : les actions à exécuter immédiatement ;
- state : l’état du robot, du robot vers le gestionnaire ;
- connection : la présence du robot sur le réseau ;
- visualization et factsheet : position en quasi-temps réel et fiche descriptive du modèle de robot.
Pour limiter la charge de communication, le niveau de qualité de service MQTT 0 (« au plus une fois », sans accusé de réception) est imposé pour les sujets order, instantActions, state, factsheet et visualization, tandis que le niveau 1 (« au moins une fois ») est réservé à connection. Le Wi-Fi d’un entrepôt perdant des paquets, le protocole est donc construit pour tolérer les pertes plutôt que pour les empêcher.
Le mécanisme le plus ingénieux : la base et l’horizon
Comment guider un robot sur un réseau qui perd des messages, sans qu’il s’arrête à chaque trou de couverture ? La spécification découpe l’itinéraire en deux parties. La base est l’ensemble des nœuds et des arêtes « libérés » : le robot a l’autorisation de les parcourir. L’horizon est la suite, non libérée, que le gestionnaire peut encore modifier. Un ordre est identifié par un orderId et mis à jour par un orderUpdateId, et les nœuds et arêtes partagent un même sequenceId continu : le premier nœud porte le numéro 0, la première arête le numéro 1, le deuxième nœud le numéro 2, et ainsi de suite.
L’intérêt est double. D’abord, le gestionnaire ne libère que le tronçon dont il est sûr qu’il est libre, ce qui sert directement la gestion du trafic. Ensuite, si le robot perd la connexion, il conserve les informations de son ordre et l’exécute jusqu’au dernier nœud libéré, puis s’arrête. Le robot ne roule donc jamais vers une zone dont personne ne lui a garanti l’accès, même en cas de coupure.
Détecter la panne de communication
Une flotte n’est supervisable que si l’on sait qui est en ligne. La spécification utilise pour cela le mécanisme MQTT du last will : à la connexion, le robot enregistre auprès du courtier un message qui sera diffusé en son nom s’il disparaît sans prévenir. Le robot publie d’abord l’état « ONLINE » ; en cas de coupure brutale, le courtier publie « CONNECTION_BROKEN » ; en cas d’arrêt volontaire, le robot publie lui-même « OFFLINE ». Tous ces messages sont envoyés avec l’indicateur retained, de sorte qu’un gestionnaire qui se connecte en retard lit immédiatement le dernier état connu.
L’état du robot, lui, tient dans un seul message : il est publié à chaque événement pertinent (réception d’un ordre, changement de charge, d’erreur, de mode, d’alimentation, de position sur le graphe…) et au moins toutes les 30 secondes. Regrouper position, batterie et erreurs en un seul sujet allège le courtier et garde les informations synchronisées. L’intervalle minimal entre deux messages d’état est, lui, déclaré dans la fiche descriptive du modèle de robot.
Quatre niveaux d’erreur, quatre comportements
La spécification normalise la gravité des défauts remontés par le robot : WARNING (le robot continue et peut accepter de nouvelles missions ; exemple cité : un scanner laser encrassé), URGENT (attention immédiate requise, par exemple une batterie faible ; le robot poursuit sa mission), CRITICAL (par exemple une prise de charge sur un objet absent : le robot ne continue pas à rouler mais peut accepter de nouveaux ordres) et FATAL (intervention humaine nécessaire, par exemple une localisation perdue : le robot ne peut ni poursuivre sa mission ni en accepter une autre). Le message d’état porte aussi un objet de sécurité, avec le type d’arrêt d’urgence actif (manuel, distant ou aucun) et l’indicateur de violation du champ de protection, par laser ou pare-chocs. Ces informations remontent au gestionnaire ; elles ne remplacent pas la chaîne de sécurité du robot, qui reste régie par ses propres normes.
Une autre approche : l’interopérabilité par l’information partagée
La VDA 5050 n’est pas la seule voie. Le standard d’interopérabilité AMR de MassRobotics vise lui aussi le déploiement de robots de plusieurs fabricants dans un même entrepôt, mais par un autre angle : les robots partagent leur position, leur vitesse, leur direction, leur état de santé et leur disponibilité avec les autres robots, et des opérateurs humains peuvent y figurer via des appareils mobiles. Le dépôt fournit un schéma JSON et des exemples d’émetteur et de récepteur. Les deux approches sont complémentaires plutôt que concurrentes : l’une orchestre depuis un centre, l’autre informe les voisins.
Ce qu’il faut retenir avant d’acheter
Pour un exploitant qui envisage une flotte mixte, quelques vérifications concrètes découlent de ce qui précède :
- Demander la fiche descriptive (factsheet) de chaque modèle : elle sert à comparer, dimensionner et simuler avant d’acheter.
- Vérifier la version de la spécification prise en charge : une version majeure introduit des changements incompatibles.
- Ne pas confondre interface et sécurité : la VDA 5050 dit elle-même qu’elle n’est pas une norme de sécurité ; la conformité de chaque robot à ISO 3691-4 reste à vérifier à part.
- Clarifier qui gère le trafic : la spécification ne l’impose pas, donc le comportement aux croisements dépend du gestionnaire de flotte choisi.
- Tester la couverture radio : avec une qualité de service sans accusé de réception, un réseau sans zones d’ombre reste la meilleure assurance.
Côté marché, l’IFR note aussi que le modèle de location « robot en tant que service » continue de progresser et qu’il est déjà dominant aux États-Unis : une raison de plus pour exiger une interface ouverte, qui laisse la possibilité de changer de fournisseur. Pour aller plus loin sur les robots dans l’atelier ou l’entrepôt, voir nos articles sur les cobots dans les petits ateliers et sur les humanoïdes en entrepôt.