Un logiciel de gestion de flotte de robots permet à une seule équipe de voir et de piloter de nombreux robots à la fois : où se trouve chacun, combien de batterie il lui reste, sur quelle tâche il travaille et ce qui a mal tourné quand il s’est arrêté. Un robot isolé arrive avec sa propre application. Une douzaine de robots de trois fabricants arrivent avec trois applications, trois cartes et trois boîtes d’alertes, et c’est généralement à ce moment que les exploitants se mettent à chercher une plateforme de gestion de flotte de robots.

Ce que les acheteurs remarquent souvent plus tard, c’est que les robots ne sont pas les seuls éléments qui comptent sur le site. Portes, quais de chargement, détecteurs de fuite et systèmes d’alarme détiennent des informations que les robots ne voient jamais, et la capacité de la flotte à exploiter ces informations pèse lourd dans son utilité réelle.

L’essentiel

  • Un logiciel de gestion de flotte de robots suit l’état, la batterie, la position, les tâches et les incidents de nombreux robots, et décide quel robot fait quel travail.
  • La plupart des fabricants livrent un logiciel de flotte pour leur propre marque. Les flottes mixtes ont besoin d’une couche qui dialogue avec toutes les marques via des API, MQTT ou une norme d’interface comme VDA 5050.
  • Le vrai saut consiste à donner à la flotte le même contexte que le bâtiment, pour qu’un événement remonté par un capteur devienne une tâche pour un robot.
  • Les commandes traversent plusieurs fabricants et protocoles : chaque scénario est donc testé avec des réponses simulées avant de tourner sur de vrais robots.

Comment fonctionne la gestion de flotte de robots mobiles ?

Les robots mobiles se répartissent en deux grandes familles. Les véhicules à guidage automatique (AGV) suivent des itinéraires fixes définis par des fils, des bandes magnétiques ou des repères. Les robots mobiles autonomes (AMR) construisent une carte et planifient eux-mêmes leur trajet autour des obstacles. Les deux envoient en continu leur état à un serveur de flotte : position sur une carte, niveau de batterie, tâche en cours, vitesse, codes d’erreur, et s’ils roulent, chargent, attendent ou sont bloqués. Le serveur de flotte transforme ce flux en trois missions : la visibilité, l’attribution du travail, et la gestion du trafic et de la recharge.

La visibilité, c’est une carte avec la position de chaque robot, la liste des robots en activité, en charge ou en panne, et l’historique de ce que chacun a fait pendant le poste.

Pour l’attribution du travail, les tâches arrivent d’un système de gestion d’entrepôt, d’un système de commandes hospitalier, d’un bouton d’appel mural ou d’une personne munie d’une tablette, et le logiciel de flotte décide quel robot prend chacune d’elles. Les systèmes simples choisissent le robot libre le plus proche. Les plus évolués tiennent compte du niveau de batterie, de la charge utile et de la longueur de la file d’attente à destination.

Le trafic et la recharge deviennent un sujet dès que les robots partagent l’espace. Deux robots qui se dirigent vers la même allée étroite ont besoin d’une règle de priorité, et une flotte dont toutes les batteries faiblissent à la même heure a besoin d’un plan de recharge qui garde assez de robots en activité.

La planification de trajectoire et l’évitement d’obstacles restent sur le robot. Le serveur de flotte dit où aller et quand ; le logiciel du robot détermine comment y arriver sans rien heurter. Cette répartition compte quand vous comparez des produits : chez un fabricant, la « gestion de flotte » peut désigner un contrôle approfondi de ses propres robots, chez un autre une supervision plus légère de plusieurs marques.

La recharge se comprend mieux avec des chiffres. Imaginons un entrepôt qui fait tourner 12 AMR 16 heures par jour, chaque robot ayant besoin d’environ une heure de charge pour quatre heures de roulage. Cela représente 20 % du temps de chaque robot : en moyenne, environ 2,4 des 12 robots sont en charge à tout moment, ce qui en laisse environ 9,6 disponibles. Si le pic du soir exige 11 robots en mouvement, la flotte ne peut l’absorber que si le logiciel recharge les batteries pendant les heures creuses qui précèdent le pic.

Gestion de flotte de robots multimarque

La plupart des fabricants de robots fournissent un logiciel de flotte avec leurs machines, et pour une seule marque il fait généralement bien son travail. Les difficultés commencent quand un site ajoute une deuxième marque : un robot tracteur d’une entreprise, un robot de patrouille d’une autre, quelques AMR d’une troisième. Chacun a son propre format de carte, ses propres codes d’état et sa propre idée de ce qui constitue une erreur.

Il existe trois façons courantes de réunir une flotte mixte :

  1. API des fabricants. La plupart des robots commerciaux exposent une API REST ou WebSocket, et certains publient via MQTT, pour l’état et les tâches. Une couche multimarque interroge chacune d’elles et traduit les résultats dans un modèle commun. C’est la voie la plus répandue aujourd’hui, et l’essentiel de l’effort passe dans cette traduction.
  2. Normes d’interface. VDA 5050, publiée par l’association allemande de l’industrie automobile VDA avec la fédération des constructeurs de machines VDMA, définit comment un système de pilotage central envoie des ordres aux véhicules sans conducteur et comment ceux-ci remontent leur état, au moyen de messages JSON qui transitent par un broker MQTT. Les véhicules qui l’implémentent peuvent partager un même contrôleur sans adaptateur sur mesure. La norme couvre les messages, pas la façon dont un véhicule planifie son trajet.
  3. Middleware sur le robot. Les équipes qui construisent leurs propres robots y font souvent tourner ROS 2 et relient les données du robot à la couche de flotte par une passerelle.

Les trois voies aboutissent à un modèle commun : une seule définition de la batterie, de la position, de l’état des tâches et des défauts, vers laquelle chaque marque est convertie. Le travail d’intégration de chaque nouveau robot porte sur cette correspondance.

Les cartes demandent le même traitement. Chaque marque construit sa carte dans son propre repère, avec sa propre origine, sa propre orientation et parfois sa propre échelle. Pour afficher tous les robots sur un même plan du site, les coordonnées de chaque fabricant doivent être transformées dans un repère commun, généralement en faisant correspondre quelques points de référence présents sur toutes les cartes, comme une porte ou un poteau. Un décalage d’un mètre dans cet alignement, et les robots semblent traverser les murs sur la vue commune, alors que chacun se trouve exactement là où son propre logiciel le situe.

Cherchez des éditeurs de logiciels de gestion de flotte de robots et vous trouverez deux catégories de fournisseurs. Les fabricants de robots livrent un gestionnaire de flotte avec leurs propres machines, souvent la solution la moins chère quand la flotte est d’une seule marque. Les éditeurs indépendants de logiciels de gestion de flotte multi-robots vendent une couche qui se place au-dessus de plusieurs marques. Les classements du type « top 10 des logiciels de gestion de flotte de robots 2025 » mélangent les deux catégories, et y ajoutent aussi des logiciels de gestion de flotte pour robots industriels, bras fixes et cellules de production, qui répondent à un autre problème. Quand vous comparez les principaux éditeurs, demandez à chacun quels modèles de robots il intègre déjà, quelles données il récupère de chacun, et qui maintient l’intégration quand le firmware d’un robot change.

Que doit afficher un tableau de bord de gestion de flotte de robots ?

Un bon tableau de bord de gestion de flotte répond aux questions d’un chef d’équipe sans qu’il ait à ouvrir une seconde application.

Question Ce qu’affiche le tableau de bord Pourquoi c’est important
Où est chaque robot ? Position en direct sur le plan du site, heure de la dernière mise à jour Un robot dont la dernière mise à jour est ancienne est peut-être bloqué ou hors ligne
Peut-il continuer à travailler ? Niveau de batterie, état de charge, temps restant avant la prochaine recharge Indique si le travail de l’heure suivante est couvert
Que fait-il ? Tâche en cours, longueur de la file, temps passé sur la tâche Des tâches qui s’éternisent signalent des itinéraires bloqués ou de mauvaises attributions
Qu’est-ce qui ne va pas ? Défauts actifs, arrêts d’urgence, perte de localisation, échec d’accostage à la station Indique où se rendre et quoi réparer
Comment se porte la flotte dans son ensemble ? Tâches par heure, taux d’utilisation, interventions par poste Montre s’il vaut mieux ajouter des robots ou corriger les processus

Commencez par les interventions par poste. Une intervention, c’est chaque fois qu’une personne doit agir : dégager une allée bloquée, pousser un robot qui a perdu sa position, le replacer correctement sur son chargeur. Rapportées à chaque robot et à chaque zone, les interventions révèlent où se situe le vrai problème. Si la plupart ont lieu dans un même couloir, c’est ce couloir qu’il faut traiter, et acheter plus de robots ne ferait qu’allonger la file d’attente à cet endroit.

Les incidents robotiques se disputent aussi l’attention avec toutes les autres alertes du site. Un chef d’équipe qui reçoit les défauts de la flotte dans une boîte et les alarmes du bâtiment dans une autre finit par passer à côté de l’une des deux : mieux vaut décider tôt quels incidents vont aux mêmes personnes que les alarmes du bâtiment.

C’est cette vue partagée que nous construisons avec Kilo, en complément du gestionnaire de flotte fourni par le fabricant du robot. Si un robot accepte des commandes via MQTT, directement ou par une petite passerelle branchée sur son API, vous pouvez le relier aux capteurs LoRaWAN, mioty et MQTT du bâtiment et écrire une règle qui transforme un événement de capteur en tâche pour le robot. Un détecteur de fuite sous un rayonnage signale de l’eau pendant la nuit, et une seule règle déclenche une alarme pour les services techniques tout en envoyant dans cette allée un robot équipé d’une caméra. Avant que la règle ne fasse bouger un vrai robot, vous la parcourez pas à pas dans le débogueur de Kilo, avec la réponse du robot simulée. Des capteurs, des portes, des machines et des robots qui partagent ainsi un même contexte : c’est ce que nous appelons l’IA physique pour les sites connectés.

Comment mettre en place la gestion de flotte de robots ?

Les déploiements qui se passent bien suivent en général à peu près cet ordre, quel que soit l’outil choisi :

  1. Recensez la flotte et ses interfaces. Pour chaque modèle de robot, notez ce qu’il expose (API REST, MQTT, VDA 5050, ROS 2), les données que vous pouvez lire (position, batterie, tâche, défauts) et les commandes qu’il accepte, comme se rendre à un endroit, rejoindre sa station ou se mettre en pause.
  2. Définissez un modèle de données unique. Mettez-vous d’accord sur les noms de champs, les unités et les états, puis convertissez les codes de chaque fabricant dans ce modèle.
  3. Décidez qui attribue les tâches. Souvent, le gestionnaire de flotte du fabricant continue de gérer le trafic au sein de sa marque, tandis que votre couche lui confie les missions et récupère les résultats.
  4. Lancez un pilote sur une zone, le temps d’un poste. Mesurez les tâches par heure et les interventions avant de passer à l’échelle, pour disposer d’une base de comparaison.
  5. Connectez le bâtiment. Portes, quais, capteurs et alarmes ont leur place dans la même vue que les robots.
  6. Répétez chaque scénario hors exploitation. Faites tourner toute nouvelle logique de tâches dans une zone de test ou sur un simulateur avant qu’elle n’atteigne un robot en production : une tâche qui traverse plusieurs fabricants et protocoles passe par davantage de systèmes qu’une tâche interne à une seule marque.

Questions fréquentes sur la gestion de flotte de robots

Combien coûte un logiciel de gestion de flotte de robots ?

Les modèles de tarification varient. Les fabricants incluent souvent leur logiciel de flotte dans l’achat ou la location des robots, tandis que les plateformes indépendantes facturent généralement un abonnement par robot ou par site. Le travail d’intégration de chaque nouveau modèle de robot est souvent facturé à part : demandez ce montant en même temps que le prix de la licence.

Gestion de flotte d’AGV et gestion de flotte de robots mobiles, est-ce la même chose ?

Elles se recoupent, mais l’accent diffère. Un logiciel de flotte d’AGV gère des segments d’itinéraire fixes et bloque l’accès à un segment tant qu’un véhicule l’occupe. Un logiciel de flotte d’AMR consacre plus d’efforts aux zones, à l’attribution des tâches et à la congestion, puisque chaque robot choisit son propre itinéraire.

Un logiciel de gestion de flotte de robots fonctionne-t-il dans le cloud ou sur site ?

Les deux existent. La gestion du trafic des robots qui partagent des allées tourne souvent sur un serveur sur site, car elle ne peut pas dépendre d’une connexion internet, tandis que le reporting et les vues multisites tournent souvent dans le cloud. En général, si le réseau tombe, les robots terminent leur mouvement en cours, puis attendent de nouvelles instructions une fois la connexion rétablie.

Un seul robot qui publie déjà son état via MQTT suffit pour tester la vue partagée. Enregistrez son niveau de batterie et l’état de sa tâche comme un appareil dans Kilo, ajoutez un contact sur la porte de quai qu’il franchit le plus souvent, et affichez les deux dans un même tableau de bord. Écrivez ensuite une règle qui alerte le chef d’équipe quand le robot signale un arrêt d’urgence. Deux appareils et cette seule règle tiennent dans l’offre gratuite, et une semaine de données montre à quelle fréquence les arrêts du robot coïncident avec l’activité de la porte.