La première question n'est pas de savoir quel robot vous achetez

Les fabricants de robots de service veulent entrer sur le marché européen, et ils veulent entrer dans le secteur de la santé. La demande est là : les hôpitaux cherchent à soulager les transports, le guidage des visiteurs et les renseignements. Le matériel en est capable. Navigation, charge utile, autonomie et qualité de fabrication ont atteint un niveau qui soutient le quotidien clinique. Ce qui freine le déploiement ne tient presque jamais à l'appareil.

Il se situe structurellement en dehors de lui. L'architecture et le modèle opérationnel des solutions robotiques actuelles sont nés de marchés où un appareil fonctionne largement seul et où ses données sont gérées dans le cloud du fabricant. C'est, là-bas, un bon choix. L'hôpital européen fonctionne différemment : un robot y est un système informatique dans un environnement sensible, connecté aux ascenseurs, aux portes, aux systèmes de contrôle d'accès et à l'informatique clinique, avec des flux de données traçables et des droits documentés. Cet écart ne se situe pas dans la robotique. Il se situe dans la couche qui la surplombe.

Lorsque nous parlons avec des établissements et avec des intégrateurs, les deux mêmes questions reviennent presque à chaque fois. Premièrement : pourquoi faudrait-il une couche logicielle supplémentaire entre le robot et le bâtiment ? Deuxièmement : pourquoi ne pas simplement utiliser la solution que le fabricant du robot fournit avec l'appareil ? Les deux questions sont légitimes, et cet article y répond séparément pour les deux groupes qui les posent. Athegus est un spin-off de la TH Deggendorf (THD), né du projet de recherche SMART FOREST 5G Clinics ; notre plateforme Axiona, en exploitation clinique depuis 2023, est documentée dans six publications évaluées par des pairs de manière indépendante.

Pour les établissements

La première question dans un projet de robotique n'est pas quel robot vous achetez. C'est à quoi l'exploitation doit ressembler : quelle tâche un robot doit-il assumer, quels systèmes doit-il pouvoir atteindre pour cela, qui est habilité à le mandater, et que devez-vous pouvoir prouver ensuite ? Une fois ce point clarifié, le choix de l'appareil reste une question technique de tâche, de dimensions et d'adéquation. Si l'on inverse cet ordre, c'est le premier appareil acheté qui détermine durablement votre exploitation.

Là où naît le bénéfice

Un robot qui parcourt un couloir n'est pas encore un soulagement. Celui-ci naît là où robots / bâtiments / informatique se rencontrent : le transport démarre parce qu'une commande arrive du système métier. Le robot atteint le troisième étage parce qu'il est autorisé à appeler l'ascenseur. Il franchit la porte coupe-feu parce que la commande la libère. Il est admis dans la zone de laboratoire parce que le système de contrôle d'accès le reconnaît. Et l'échantillon reste traçable parce que la remise a été consignée. Chacun de ces points se situe en dehors de l'appareil.

C'est pourquoi la couche supplémentaire n'est pas une fin en soi, mais l'endroit où ces connexions se créent une fois pour toutes et s'appliquent ensuite à chaque nouvel appareil. Vous raccordez une seule fois l'ascenseur, les portes, le contrôle d'accès, les systèmes HIS et LIS, les rôles et les droits, la journalisation et le reporting, sans repartir de zéro pour chaque modèle de robot. Vous obtenez ainsi ce dont une flotte mixte a besoin au quotidien : un seul pilotage des commandes, une seule gestion des droits et un seul système de reporting, quel que soit l'appareil qui circule à un instant donné.

Que cette approche tienne la route, l'exploitation réelle de hospOS le montre : un robot y assure 80,68 % des transports d'échantillons de laboratoire. Cette part ne vient pas seulement de la performance de l'appareil, mais du fait que la commande, l'ascenseur, le trajet et la remise s'enchaînent sans étape manuelle intermédiaire.

La souveraineté est une question d'architecture

La seconde partie de la réponse concerne les données. Un robot de service posté dans un couloir d'unité de soins porte avec lui une caméra et un microphone. La sensibilité découle déjà du lieu : chambres de patients, accueil, laboratoire, salles d'attente. Nul besoin d'une liste de noms pour qu'un enregistrement réalisé dans un couloir d'unité de soins constitue une donnée à caractère personnel. C'est pourquoi, dans les hôpitaux, la question du flux de données se pose plus tôt que dans d'autres secteurs, et pourquoi elle détermine souvent si un projet démarre ou non.

La réponse solide à cela n'est pas un ensemble contractuel supplémentaire, mais une architecture qui réduit la portée de la question.

« Ce qui ne quitte jamais l'établissement n'a besoin d'aucune base de transfert. »

Ce n'est pas un artifice juridique, mais la conséquence de la manière dont les données sont conservées. Si la coordination s'exécute localement, cartes, commandes, télémétrie et enregistrements restent dans votre environnement, et l'examen se déplace de « sur quelle base transférons-nous ceci ? » à « qu'est-ce qui quitte réellement le bâtiment ? ». Axiona est conçu pour cela : trois modes opérationnels – cloud, on-premise et entièrement hors ligne – portent la même logique fonctionnelle. Le mode reste ainsi une décision opérationnelle de votre établissement, et non une contrainte imposée par le produit. Nous détaillons ce fonctionnement technique dans Robotique de service sans fuite de données.

Cela replace aussi l'origine d'une solution à sa juste place. Pour certains pays d'origine de la robotique de service, une décision d'adéquation de la Commission européenne existe – par exemple pour le Japon et la République de Corée – pour d'autres non. Il s'agit d'un constat sur la situation juridique, non d'un jugement porté sur un pays. Une architecture encapsulable vous rend indépendant de cette distinction, car vous n'avez pas à répondre à nouveau à la question pour chaque fabricant.

Une distinction importante se perd souvent dans les discussions d'achat : le lieu de stockage et la possibilité d'accès sont deux choses différentes. Un serveur installé dans vos locaux ne dit rien de qui peut le consulter à distance. Le Comité européen de la protection des données (CEPD) l'a précisé dans ses Lignes directrices 05/2021 (version 2.0, adoptées le 14 février 2023) : le point 9 énonce trois critères cumulatifs pour qu'un traitement soit qualifié de transfert. Le point 16 indique qu'un accès à distance depuis un pays tiers peut lui aussi constituer un transfert, même lorsque les données y sont simplement affichées à l'écran, par exemple lors d'une assistance, d'un dépannage ou d'une administration, à condition que les trois critères du point 9 soient réunis. À l'inverse, le point 17 précise qu'un traitement purement interne, dans lequel les données ne sont divulguées à aucun autre responsable du traitement ou sous-traitant, ne constitue pas un transfert au sens du chapitre V. C'est le fondement architectural de la phrase ci-dessus. C'est à votre fonction protection des données et à votre conseil juridique qu'il revient d'apprécier, au cas par cas, si ces critères sont réunis. L'architecture détermine la fréquence à laquelle cette question se pose.

Nous en tirons un principe de conception, pas un vote de défiance : pas d'accès distant permanent. Il n'existe aucun canal ouvert en continu depuis l'extérieur vers l'installation. Le support à distance s'exécute sous forme de session – activée par l'établissement, limitée dans le temps, journalisée. Pour les fabricants et les intégrateurs, ce n'est pas une perte de capacité de service, mais la forme sous laquelle un support à distance peut être convenu de façon solide dans un environnement réglementé, et présentée comme telle dans un appel d'offres.

Prouver ce qui s'est réellement passé

Quiconque déploie de la robotique dans un environnement réglementé doit non seulement garantir l'exploitation, mais aussi pouvoir le prouver : qui a déclenché une commande, quel rôle y était habilité, quel trajet a eu lieu et quand, quels systèmes étaient impliqués ? De telles preuves ne se reconstituent pas a posteriori à partir des données d'exploitation d'appareils isolés ; elles se constituent dans la couche qui voit l'ensemble des commandes. Les rôles et les droits, les journaux et les rapports ont donc leur place à cet endroit.

Un détail que nous avons délibérément conçu ainsi : une lacune de données est signalée comme une lacune, pas comme un zéro. Si la saisie fait défaut sur une période donnée, c'est exactement ce qui figure dans le rapport. Un indicateur qui lisse une lacune en valeur nulle paraît meilleur et ne vaut rien en audit. La manière dont cela s'articule avec les obligations de documentation issues de NIS 2 fait l'objet de notre guide pratique sur NIS 2 et la robotique de service ; les principes qui les sous-tendent sont exposés sous Souveraineté et sécurité. Journaux et rapports ne remplacent pas une organisation de conformité, mais ils réduisent la charge de documentation. Ce qui ne quitte jamais l'établissement rend la question de la base de transfert sans objet dans de nombreux cas.

Si vous préparez un projet, la voie la plus rapide est la plus concrète : montrez-nous l'un de vos processus, et nous vous montrerons comment il transite par une couche neutre, dans le mode opérationnel qu'exige votre établissement. Demander une démo.

Pour les intégrateurs et les sociétés de services

Pour les intégrateurs et les sociétés de services, la question de la couche supplémentaire se pose différemment. Il ne s'agit pas de savoir si une telle couche est nécessaire, mais qui la construit et la maintient. Un logiciel robotique développé en interne est rarement l'option la plus économique. L'effort ne se situe pas dans la première intégration, mais dans la dixième, et dans tout ce qui doit fonctionner durablement : protocoles d'ascenseur, commandes de portes, systèmes de contrôle d'accès, modèles de rôles, chemins de mise à jour et modes opérationnels.

La répartition des tâches

La répartition qui fonctionne dans la pratique suit ce que chaque partie possède réellement. Vous avez la relation client, le savoir-faire sur l'installation sur site, la réception et la mise en service. C'est un capital qui ne s'achète pas. La plateforme fournit l'orchestration, la connexion au bâtiment, le modèle opérationnel et les preuves. Vous travaillez via l'interface graphique ou en mode headless via l'API REST. Vous construisez ainsi votre propre solution commerciale, sous votre marque et selon votre relation contractuelle, sans avoir à monter votre propre équipe de robotique.

Le levier réside dans la bibliothèque d'intégration commune. Chaque nouvelle intégration – un type d'ascenseur, un système de contrôle d'accès, un modèle de robot – devient ensuite disponible pour toutes les solutions sectorielles sur Axiona : pour hospOS comme pour shoppiOS. Votre travail sur un projet clinique profite ainsi aussi au prochain projet commercial.

Flotte mixte, changement d'appareil, modèle opérationnel

Venons-en à la seconde question : pourquoi le logiciel livré avec un appareil ne suffit-il généralement pas, à lui seul, à assurer l'exploitation ? Non pas parce qu'il serait faible, mais parce qu'il est conçu pour un seul appareil, alors que l'exploitation réelle en implique plusieurs. Trois observations tirées de la pratique :

La flotte mixte est le cas normal, pas l'exception. Aux Kliniken am Goldenen Steig, à Freyung, plusieurs types d'appareils fonctionnent sur la même plateforme, notamment des Keenon T3, Keenon W3 et temi v2, via une intégration à l'ascenseur KONE mise en place une seule fois. Au Technologie Campus Grafenau, la même base sert d'environnement de test pour de nouveaux modèles et de nouvelles commandes d'ascenseur. Presque aucun établissement ne choisit un seul appareil pour toutes les tâches : un robot de transport pour les échantillons de laboratoire, un robot d'accompagnement pour l'accueil et un appareil de nettoyage sont trois machines différentes, souvent de trois fabricants distincts. Un logiciel propre à un appareil connaît, à juste titre, très précisément son appareil. Il ne peut pas fournir une vue d'ensemble d'une flotte mixte, car ce n'est pas sa mission. Les installations sont documentées sous Références.

Le matériel est remplacé, les processus restent. Un modèle de robot a un cycle de vie plus court qu'un processus clinique. Si la logique du processus réside dans l'appareil, chaque changement d'appareil devient un projet d'intégration. Si elle réside dans la couche qui le surplombe, il s'agit d'un simple achat. Pour vous, c'est la différence entre un projet que vous vendez une fois et une installation qui se développe sur plusieurs années. Nous y consacrons un article détaillé : Plus de choix de robots sans changer de système.

Le modèle opérationnel est un prérequis, pas une option supplémentaire. Dans les hôpitaux, chez les opérateurs de services essentiels et dans d'autres environnements réglementés, la conservation des données, l'accès à distance et la traçabilité des preuves n'arrivent pas à la fin de la clarification technique, mais dès le début. Qui n'y répond qu'à la réception les négocie sous la pression du temps. Qui les apporte d'emblée a déjà accompli une partie du travail d'appel d'offres.

« Avec une couche encapsulable et capable de fonctionner hors ligne, le modèle opérationnel devient l'argument de vente de l'intégrateur, et non plus un risque de projet. »

Vous entrez dans la discussion avec une réponse démontrable, plutôt qu'avec une promesse que vous devrez tenir plus tard. Cela fait passer la discussion avec la protection des données, l'IT et la technique de « est-ce seulement autorisé ? » à « quel processus prenons-nous en premier ? ». L'examen au cas par cas par la fonction protection des données et le conseil juridique de l'établissement n'en est pas affecté.

Si vous souhaitez intégrer la robotique à votre portefeuille ou donner à un projet en cours une base solide, parlons de la répartition des tâches. Devenir partenaire.

L'écosystème reste ouvert

Les nouveaux modèles de robots sont raccordés via des adaptateurs, et non via une solution spécifique par projet, et chaque nouvelle intégration profite à toutes les solutions sectorielles sur Axiona. Quiconque veut faire entrer un bon matériel sur le marché européen de la santé n'a besoin ni de restructurer son architecture, ni de reconstruire son propre modèle opérationnel européen : le chemin le plus court passe par une couche qui existe déjà, qui est en exploitation clinique depuis 2023 et qui prend en charge l'intégration et la traçabilité des preuves. Vos appareils entrent alors en ligne de compte pour davantage d'appels d'offres, pas moins. Devenir partenaire.