Interopérabilité des robots de nettoyage : ascenseurs, API, VDA 5050, flottes et mises à jour, ce que 35 constructeurs publient sur 101 modèles

Un robot de nettoyage qui ne parle à rien d'autre qu'à sa propre application fait un étage, une zone, un bâtiment. Pour couvrir un immeuble, il doit prendre l'ascenseur ; pour couvrir un site, il doit coexister avec d'autres robots, parfois d'autres marques ; pour rester utile cinq ans, il doit se mettre à jour ; pour rendre compte, il doit remonter ses données là où le client les lit. C'est ce qu'on appelle l'interopérabilité, et c'est, après la sécurité, le critère le moins documenté du marché. Nous avons relevé, pour les 101 robots de 35 constructeurs de notre base, ce que la documentation publique dit sur six points : l'intégration des ascenseurs, l'existence d'une API, l'adoption du standard VDA 5050, la gestion de flotte multi-robots, les mises à jour à distance et la connectivité. Cet article donne les chiffres, par famille, nomme les constructeurs qui publient, explique ce que chaque brique change sur un site, décrit ce qu'exige une exploitation multi-robots, et termine par ce qu'un acheteur doit demander. Il sera actualisé chaque année, et enrichi de retours terrain au fur et à mesure. Cette étude est consolidée dans l'Observatoire du nettoyage robotisé 2026.

Les six briques de l'interopérabilité, et ce que chacune change

• L'intégration des ascenseurs. Le robot appelle la cabine, y entre, sélectionne l'étage, en sort. Elle suppose un module de communication avec l'ascenseur, installé par l'ascensoriste ou par un intégrateur, et un protocole que le constructeur du robot a implémenté. Sans elle, un robot par étage ; avec elle, un robot par immeuble. C'est la brique la plus demandée par les bureaux et les hôtels, et la plus opaque : la compatibilité dépend de la marque d'ascenseur, de son âge et du module.
• L'API. Une interface documentée qui permet à un logiciel tiers, une GMAO, une plateforme de facility management, un tableau de bord client, de lire les données du robot (passages, surfaces, alertes) et parfois de lui envoyer des ordres (lancer une tâche, changer de plan). Sans API, les données restent dans l'application du constructeur.
• Le VDA 5050. Standard d'interface, publié en 2019 par l'industrie automobile allemande et l'association des constructeurs de matériel de manutention, qui permet à un système de pilotage central de commander des robots mobiles de constructeurs différents. Il est devenu la référence dans la logistique ; dans le nettoyage, il reste marginal.
• La gestion de flotte multi-robots. Un planificateur qui répartit zones, horaires et stations entre plusieurs robots, évite les conflits et consolide les rapports. Chez presque tous les constructeurs, il est propriétaire : il gère leurs robots, pas ceux des autres.
• Les mises à jour à distance (OTA). La capacité du robot à recevoir de nouvelles fonctions et des correctifs sans intervention sur site. C'est ce qui a fait progresser la navigation et la détection des robots de 2022 à 2026, et ce qui distingue un robot de cinq ans encore performant d'un robot dépassé.
• La connectivité. Wi-Fi, 4G ou 5G intégrée, avec ou sans carte SIM incluse ; ce qui conditionne la supervision à distance, les rapports en temps réel et les mises à jour, et ce qui, sur un entrepôt sans Wi-Fi, décide de tout.

Méthodologie

Même base et même méthode que notre baromètre de transparence sécurité : 101 robots de 35 constructeurs, documentés sur 81 critères à partir de la documentation publique des constructeurs et de leurs distributeurs, vérifiés modèle par modèle en 2025-2026. Pour chacune des six briques, nous avons classé la documentation en « publié » (fonction annoncée, avec ou sans détail), « non » (fonction explicitement absente) et « non publié » (aucune mention). Nous mesurons ce que les constructeurs disent, pas ce que leurs robots font : une fonction annoncée peut être en option, payante, ou limitée à certains ascensoristes ; une fonction non publiée peut exister. Nous nommons les constructeurs qui publient, information positive et vérifiable ; nous ne listons pas nominativement les modèles « non publié ».

Les chiffres

Le contraste est parlant : la remontée de rapports en ligne est presque universelle (86 %), parce qu'elle sert le constructeur autant que le client ; l'API, qui permet au client de sortir ses données, est publiée pour un quart des modèles ; l'ascenseur, pour un sixième ; le standard ouvert, pour trois modèles d'un seul constructeur.

Les multifonctions compacts, conçus pour les immeubles de bureaux et les hôtels, sont ceux qui publient le plus l'intégration ascenseur ; les balayeuses, faites pour les entrepôts de plain-pied, presque jamais, ce qui est cohérent avec leur usage.

Les constructeurs qui publient

Intégration ascenseur publiée : Gausium (8), Pudu (7), Cleanfix (1), Yijiahe (1), OrionStar (1), Ecovacs (1). API publiée : Gausium (12), Pudu (7), Kärcher (3), Keenon (1), Kemaro (1), Cleanfix (1), Adlatus (1). Gestion de flotte publiée : Gausium (9), LionsBot (8), Pudu (7), Tennant (5), Kärcher (5), Avidbots (4), Nexaro (2), Ecovacs (2), SoftBank Robotics (1), ICE Cobotics (1), TASKI (1), Kemaro (1), Cleanfix (1), Wetrok (1), Minuteman (1), Hako (1), Fimap (1), Yijiahe (1), Tailos (1), Peppermint Robotics (1), Sveaverken (1). Standard VDA 5050 : Kärcher (KIRA B 50, KIRA BR 200, KIRA BD 200). Ces listes sont établies à partir de la documentation publique de chaque modèle ; un constructeur absent peut proposer la fonction sans la documenter.

Deux lectures. Les constructeurs chinois de la nouvelle génération (Gausium, Pudu, Keenon, OrionStar, Ecovacs, Yijiahe) publient volontiers l'intégration ascenseur et une plateforme cloud avec API, parce que leur marché d'origine est fait de tours et de centres commerciaux ; les constructeurs européens historiques publient moins sur l'ascenseur, davantage sur la sécurité et, pour Kärcher, sur le standard VDA 5050, hérité de la logistique. Aucun constructeur ne publie une interopérabilité avec les robots d'un concurrent.

Ce qu'exige un site multi-robots

Sur un site de plusieurs dizaines de milliers de mètres carrés, plusieurs robots travaillent ensemble : une balayeuse avant une autolaveuse dans les allées, un aspirateur sur la moquette des bureaux pendant qu'un multifonction lave les circulations, deux laveuses grand format sur deux halls. Cette coopération, que nous décrivons dans notre page sur la cobotique robot × robot, exige trois choses : que les robots ne se gênent pas (zones, créneaux, largeur des allées, priorité aux croisements), qu'ils partagent les ressources (stations, ascenseurs, eau, Wi-Fi), et que leurs rapports se consolident.

Aujourd'hui, cela se fait de deux façons. Avec une seule marque, le planificateur de flotte du constructeur fait le travail : il répartit zones et horaires, gère les stations et, quand l'intégration existe, l'ascenseur ; c'est le cas de nos sites équipés de plusieurs robots Pudu, coordonnés depuis une seule plateforme. Avec plusieurs marques, ce qui arrive quand un site a une balayeuse d'un constructeur et une autolaveuse d'un autre, la coordination se fait par l'organisation : des zones et des créneaux disjoints dans le plan de passage, des stations séparées, et deux tableaux de bord que l'agent consulte l'un après l'autre. Ce n'est pas de l'interopérabilité, c'est de la juxtaposition ; elle fonctionne, mais elle coûte du temps d'exploitation et interdit l'optimisation.

Nous décrivons ici des cas types, issus de notre pratique et de celle du marché ; nous publierons des retours chiffrés site par site à mesure que nos clients autoriseront leur publication. L'exemple le plus courant : une plateforme logistique où une balayeuse autonome passe entre 22 h et 1 h et une autolaveuse grand format entre 1 h et 5 h, avec des stations dans le même local technique, et un agent de jour qui lit les deux rapports et fait les reprises.

Ce que l'acheteur doit demander

• L'API et sa documentation, avec les données accessibles (passages, surfaces, durées, alertes, cartes) et les ordres possibles ; et la possibilité d'exporter l'historique complet en format ouvert (CSV, JSON) à tout moment.
• La liste des ascensoristes et des modules intégrés, les références de sites équipés, le coût et le délai d'une intégration, et qui la porte (constructeur, ascensoriste, intégrateur).
• La politique de mises à jour : fréquence, contenu, durée d'engagement (combien d'années de mises à jour garanties), coût, et ce qui se passe en fin de support.
• La gestion de flotte : nombre de robots par planificateur, gestion multi-sites, droits d'accès par client, et compatibilité avec d'autres marques (la réponse sera presque toujours non ; autant le savoir).
• La connectivité : Wi-Fi seul ou 4G intégrée, carte SIM incluse, fonctionnement dégradé sans réseau, données transmises et hébergement.
• La réversibilité : la portabilité des cartes du site et des rapports en cas de changement de robot ou de prestataire, écrite dans le contrat ; notre modèle de cahier des charges en comporte la clause.

Ce que nous faisons de cette donnée

Notre guide des robots de nettoyage professionnels compare les modèles sur des critères mesurables ; l'intégration ascenseur, l'API et la gestion de flotte y seront ajoutées modèle par modèle à la prochaine mise à jour, sous la forme « publiée / non / non publiée ». Sur nos propres sites, nous exploitons des flottes d'une même marque coordonnées par un planificateur unique, et nous intégrons l'ascenseur quand le bâtiment le permet ; nous remettons à nos clients les rapports dans leur format, avec l'export des données. Cette étude est libre de reprise avec mention de la source ; les agrégats sont dans le PDF.

L'étude en PDF (méthodologie et agrégats)

Fiche libre d'usage, sans inscription. Les six briques, la méthodologie, les agrégats par brique et par famille, les constructeurs qui publient et la check-list de l'acheteur, libres de reprise avec mention de la source. Télécharger (PDF) → Tous nos modèles sont regroupés sur la page modèles de nettoyage à télécharger.