Un logiciel d’orchestration multi-robots décide quel robot fait quel travail, dans quel ordre, et comment plusieurs robots partagent allées, portes, ascenseurs et chargeurs sans se bloquer mutuellement. S’il fallait le définir en une phrase : c’est le répartiteur d’un groupe de robots, qui transforme une liste de tâches en un plan que de nombreuses machines peuvent exécuter en même temps.

Cela ressemble à de la gestion de flotte, et les deux sont souvent confondues. Un outil de flotte vous dit ce que font vos robots. L’orchestration décide ce qu’ils doivent faire ensuite, et pour cela elle a besoin d’en savoir bien plus que la position des robots.

L’essentiel

  • L’orchestration recouvre trois missions : attribuer les tâches, réserver les espaces et ressources partagés, et synchroniser les passages de relais entre robots.
  • Le contrôle centralisé trouve de meilleurs plans ; le contrôle décentralisé résiste mieux aux coupures réseau. La plupart des sites réels combinent les deux.
  • Superviser une flotte et l’orchestrer sont deux problèmes différents, et bien des sites ont besoin des deux.
  • Les robots ont aussi besoin du contexte fourni par les portes, les ascenseurs et les capteurs du site, et chaque commande qui traverse plusieurs fabricants et protocoles est testée avec des réponses simulées avant sa mise en service.

Comment fonctionne la coordination multi-robots ?

La coordination multi-robots se décompose en trois problèmes que le logiciel d’orchestration résout en continu, souvent plusieurs fois par seconde.

L’attribution des tâches décide quel robot prend quel travail. La méthode la plus simple envoie chaque nouvelle tâche au robot libre le plus proche. C’est rapide à calculer et souvent suffisant, mais cela peut mener à de mauvais choix quand plusieurs tâches arrivent ensemble. Prenons deux robots libres et deux tâches qui arrivent au même instant, avec ces temps de trajet jusqu’à chaque point de prise en charge :

Tâche 1 Tâche 2
Robot A 3 min 2 min
Robot B 4 min 9 min

Si l’on traite d’abord la tâche 1, la règle du robot le plus proche la confie au robot A (3 minutes) et laisse la tâche 2 au robot B (9 minutes) : 12 minutes de trajet à vide, et la tâche 2 attend son robot pendant 9 minutes. En considérant les deux tâches ensemble, la tâche 1 va à B (4 minutes) et la tâche 2 à A (2 minutes) : 6 minutes de trajet à vide, soit deux fois moins. Un logiciel d’orchestration qui attribue les tâches par lots, plutôt qu’une par une, trouve le second plan. Avec des dizaines de robots et de tâches, ces économies de trajets à vide s’accumulent sur tout un poste.

La réservation des ressources empêche les robots de revendiquer le même espace. Le logiciel traite les allées étroites, les intersections, les cabines d’ascenseur, les emplacements de recharge et les stations d’amarrage comme des ressources qu’un seul robot occupe à la fois. Un robot demande la zone suivante sur son itinéraire, l’obtient ou attend, puis la libère une fois sorti. Le cas à anticiper est l’interblocage : le robot A attend une zone que détient le robot B, tandis que B attend la zone que détient A. Aucun des deux ne bougera plus jamais. Le logiciel d’orchestration surveille ces cycles d’attente et les rompt, par exemple en renvoyant un robot vers un point d’évitement.

La synchronisation gère le travail qui dépend d’un autre robot. Si un robot dépose un chariot à une station et qu’un second robot doit l’emporter plus loin, ce dernier ne doit pas partir vers la station avant que le premier ait signalé le dépôt comme terminé. Si la synchronisation est mauvaise, des robots attendent sans rien faire aux stations, ou arrivent à une station vide.

Ces trois problèmes évoluent à chaque nouvel événement, c’est pourquoi l’orchestration tourne en continu et non une fois par poste. Une tâche urgente peut arriver alors que tous les robots sont occupés, et le logiciel doit décider s’il retire un robot d’un travail moins prioritaire ou s’il fait attendre la tâche urgente. Replanifier trop volontiers crée ses propres problèmes : si les attributions changent à quelques secondes d’intervalle, les robots font des allers-retours entre destinations et accomplissent moins de travail au total. Un bon logiciel d’orchestration vous permet de fixer des priorités par type de tâche et un seuil à partir duquel un meilleur plan vaut la peine de bousculer le travail en cours.

Contrôle multi-robots : centralisé ou décentralisé ?

Il existe deux grandes manières d’organiser le contrôle multi-robots.

Dans une architecture centralisée, un planificateur unique voit tous les robots, toutes les tâches et toutes les réservations, et envoie ses instructions à chaque robot. Il produit de meilleurs plans, comme l’attribution par lots ci-dessus, et son comportement est plus facile à prévoir et à vérifier, puisque toutes les décisions se prennent au même endroit. La contrepartie, c’est la dépendance : si le planificateur ou le réseau tombe, les robots terminent leur mouvement en cours puis attendent. Le temps de planification augmente aussi avec la taille de la flotte, si bien que les très grandes flottes demandent une ingénierie soignée.

Dans une architecture décentralisée, les robots se coordonnent entre eux. Ils peuvent se disputer les tâches lors de petites enchères, où chaque robot propose son coût estimé et où l’offre la plus basse l’emporte, ou suivre des règles de priorité communes aux intersections. Cette approche résiste aux pannes et passe bien à l’échelle, mais le résultat global est plus difficile à prévoir, et démontrer qu’un groupe de robots indépendants ne tombera jamais en interblocage est un problème ardu. Une petite enchère illustre les deux aspects. Une nouvelle tâche apparaît et trois robots proposent 4, 6 et 11 minutes. Le robot qui a proposé 4 minutes l’emporte, ce qui est un choix raisonnable ; mais si ce robot était sur le point de devenir le seul capable d’atteindre une tâche plus urgente, personne dans l’enchère ne le savait.

La plupart des sites en exploitation finissent par adopter un modèle hybride. Le gestionnaire de flotte de chaque fabricant coordonne finement ses propres robots, et une couche d’orchestration placée au-dessus répartit le travail entre les marques et gère les ressources qu’elles partagent. Des groupements industriels ont publié des interfaces pour faciliter cela : la norme d’interopérabilité MassRobotics, publiée en 2021, définit des messages JSON par lesquels des robots mobiles de fabricants différents partagent leur position et leur destination, afin que le système d’un robot puisse au moins voir les autres.

À quoi servent les systèmes multi-robots ?

Un système multi-robots désigne tout groupe de robots qui poursuivent des objectifs communs, et ses usages dépassent largement les entrepôts.

  • Dans les entrepôts, des groupes de robots apportent les étagères aux préparateurs, déplacent des palettes entre les zones et font l’inventaire la nuit.
  • Dans les hôpitaux, des robots transportent linge, repas, fournitures et échantillons de laboratoire entre les services, souvent en partageant couloirs et ascenseurs avec les patients et le personnel.
  • Dans l’industrie, des robots approvisionnent la ligne en pièces, évacuent les produits finis et déplacent des kits entre les postes de travail.
  • Dans les grands bâtiments et les campus, des robots de nettoyage et de patrouille couvrent les étages selon des plannings qui doivent leur éviter de se croiser et de gêner les personnes présentes.
  • En agriculture, plusieurs robots de terrain se partagent un champ en bandes pour que le travail soit terminé pendant la fenêtre météo.

Les chercheurs font une distinction utile entre coordination et collaboration multi-robots. Des robots coordonnés partagent l’espace et se répartissent le travail, mais chacun fait sa propre tâche. Des robots qui collaborent agissent physiquement ensemble, par exemple deux robots qui soulèvent une charge trop longue pour un seul. Les logiciels d’orchestration commerciaux traitent aujourd’hui surtout de coordination ; la collaboration physique étroite se trouve généralement au sein du système d’un seul fabricant, où les robots partagent logiciel et cadencement.

Comment simuler un système multi-robots ?

Les problèmes d’orchestration se manifestent rarement avec deux robots par un après-midi calme. Ils surgissent en pleine charge, dans un couloir étroit, ou quand un ascenseur est hors service à une heure d’affluence. C’est pourquoi les équipes simulent généralement un système multi-robots avant l’arrivée des robots ou avant d’en ajouter. Des simulateurs robotiques comme Gazebo, en open source, ou les outils de simulation que proposent de nombreux fabricants modélisent le plan des lieux, la vitesse des robots et le rythme d’arrivée des tâches, puis font tourner un poste entier en quelques minutes.

Les bonnes questions à poser à une simulation sont concrètes. Combien de robots faut-il à l’heure de pointe avant que les temps d’attente des tâches cessent de baisser ? Où les réservations s’accumulent-elles, et une seule intersection concentre-t-elle l’essentiel de l’attente ? Qu’arrive-t-il à la file d’attente quand un ascenseur est indisponible pendant une heure ? Le plan se rétablit-il seul après une coupure réseau de trente secondes, ou les robots restent-ils immobilisés jusqu’à ce que quelqu’un intervienne ?

Simuler les robots couvre leurs déplacements. Les liaisons avec les portes, les ascenseurs, les alarmes et les autres systèmes du site doivent être testées à part, car c’est justement ce qu’un simulateur robotique ne modélise généralement pas.

Orchestration multi-robots ou gestion de flotte : quelle différence ?

La différence se voit le mieux en les comparant côte à côte :

Gestion de flotte Orchestration multi-robots
Question principale Que font mes robots ? Que doit faire chaque robot ensuite ?
Résultats typiques État, batterie, défauts, historique, rapports Attribution des tâches, réservations, synchronisation des passages de relais
Périmètre habituel Souvent les robots d’un seul fabricant Plusieurs fabricants, et souvent les systèmes du site
En son absence Les problèmes sont découverts tard Les robots attendent, se télescopent dans les files ou font le même travail en double

L’orchestration a aussi besoin de faits venus de l’extérieur de la flotte. Une porte coupe-feu se ferme quand le système d’alarme l’ordonne. Un ascenseur est hors service. Un capteur de station signale un chariot en attente d’enlèvement. Une porte de quai s’ouvre et un camion est prêt. Rien de tout cela ne vient des robots, et pourtant chacun de ces faits modifie le choix du robot à envoyer et de sa destination.

Ce contexte partagé, c’est la couche que fournit Kilo. Il relie aux mêmes règles les capteurs du site et les robots qui acceptent des commandes via MQTT : la mesure d’un capteur de station peut ainsi déclencher une règle qui envoie à un robot une commande configurée « aller à la station », tandis que Kilo enregistre si la commande a été livrée, confirmée ou a échoué. Les robots gardent leur propre navigation et leur propre sécurité. Avant de choisir vos outils, listez les portes, ascenseurs et capteurs de station dont votre orchestration aurait besoin de recevoir les informations, et repérez ceux qui transmettent déjà leurs données quelque part : ce sont ces appareils qui feraient entrer l’état du site dans l’IA physique, où capteurs, machines et robots partagent leur contexte.

Comme ces commandes traversent plusieurs fabricants et protocoles, chaque règle peut être parcourue pas à pas dans le débogueur de Kilo, avec la réponse du robot simulée, avant d’être déployée.

Questions fréquentes sur l’orchestration multi-robots

Comment comparer les éditeurs de logiciels d’orchestration multi-robots ?

Partez de vos propres robots : demandez à chaque éditeur lesquels de vos modèles il intègre déjà, et via quelle interface, par exemple une API constructeur, VDA 5050 ou la norme MassRobotics. Demandez-lui ensuite comment il gère les interblocages, les coupures réseau, les portes et les ascenseurs. Une liste d’éditeurs de logiciels d’orchestration multi-robots, ou un classement des meilleures plateformes d’orchestration multi-robots pour 2025, peut vous donner des noms à contacter, mais seul un pilote sur votre propre site montre si les plans tiennent la route.

Orchestration multi-robots et WMS, est-ce la même chose ?

Non. Un système de gestion d’entrepôt (WMS) suit les stocks et les commandes, et décide de ce qui doit être déplacé. Un logiciel d’orchestration de robots décide quel robot le déplace, et quand. Les deux échangent tâches et confirmations, et de nombreux sites utilisent les deux.

Combien de robots un logiciel d’orchestration multi-robots peut-il gérer ?

Les éditeurs annoncent des tailles de flotte, mais le nombre compte moins que la densité du trafic. Cinquante robots répartis dans un grand entrepôt peuvent être plus faciles à orchestrer que quinze qui partagent deux couloirs étroits et un ascenseur, car c’est le nombre de robots qui se disputent les mêmes zones au même moment qui détermine la charge de planification. Les résultats obtenus sur un site à l’agencement proche du vôtre vous en disent plus que la plus grande flotte qu’un éditeur ait jamais fait tourner.

Les systèmes multi-robots ont-ils besoin du Wi-Fi ou de la 5G ?

Ils ont besoin d’un réseau sans fil fiable dans toutes les zones où circulent les robots, et le Wi-Fi est le choix le plus courant. Le passage d’un point d’accès à l’autre (roaming) compte, car un robot qui perd sa connexion au milieu d’une allée peut s’arrêter et attendre. Certaines grandes usines utilisent la 5G privée pour une couverture plus prévisible.

Un appareil émulé qui accepte une commande « aller à la station » peut tenir le rôle d’un robot avant qu’aucun robot ne soit connecté. Associez-le à un capteur de station émulé et créez une règle qui envoie ce robot de substitution à la station quand le capteur signale un chariot en attente ; deux appareils et une règle tiennent dans l’offre gratuite de Kilo. Envoyez une seule mesure à la demande pour la déclencher, puis ouvrez l’historique des commandes pour voir comment le robot de substitution a répondu. Quand un vrai capteur de station est installé, il prend la place du capteur émulé et la règle continue de fonctionner sans modification.