Robotique de service sans fuite de données : fonctionner on-premise et hors ligne

Un robot qui vous décharge des trajets doit soulager votre quotidien, pas exporter vos données. Dans les cliniques, chez les opérateurs de services publics et dans d'autres environnements sensibles, la question de savoir où vont les données d'exploitation décide souvent si un projet démarre ou non. La bonne nouvelle : la robotique de service peut fonctionner de façon à ce que les données restent dans votre environnement. Mais cette décision se prend au stade de l'architecture, pas au moment de la mise en service. Qui la repousse hérite des réglages par défaut du fabricant.

Le problème des robots liés au cloud

De nombreux robots sont conçus pour le cloud de leur fabricant. Cartes, tâches, télémétrie et parfois des données d'environnement sensibles transitent par des services externes. Pour un usage privé, cela peut suffire. Dans les environnements réglementés, il en résulte trois problèmes : vous perdez le contrôle des flux de données, vous dépendez de la disponibilité d'un service externe, et vous vous liez à un fournisseur unique.

Ces trois points sont liés. Qui ne sait pas quelles données un appareil envoie vers l'extérieur ne peut ni les consigner dans un registre des traitements, ni les expliquer à un délégué à la protection des données. Qui dépend d'un service externe importe dans sa propre exploitation les fenêtres de maintenance, les hausses de prix et les engagements de disponibilité d'un tiers. Et qui couple un robot à un cloud unique peut difficilement, plus tard, le remplacer par un modèle moins cher ou mieux adapté sans reconstruire toute l'intégration. Un détail en apparence anodin lors de l'achat devient ainsi une dépendance de long terme.

Ce que signifient concrètement on-premise et hors ligne

On-premise signifie que le contrôle s'exécute dans votre environnement, sur votre infrastructure. Hors ligne signifie que l'exploitation fonctionne même sans connexion internet continue, par exemple dans des zones où aucun trafic de données externe n'est souhaité. En pratique, c'est rarement tout blanc ou tout noir. Souvent, la coordination critique en temps s'exécute localement, tandis que certaines fonctions non critiques, choisies délibérément, sont ouvertes vers l'extérieur. Ce qui compte, c'est que ce soit vous qui fixiez cette limite, pas le fabricant du robot.

Concrètement, cela suppose une séparation délibérée : le pilotage des tâches, le routage et la connexion aux portes ou aux ascenseurs sont critiques en temps et doivent rester à l'intérieur. Un tableau de bord optionnel pour les analyses, ou une mise à jour logicielle, peut en revanche sortir de façon contrôlée vers l'extérieur, si vous le souhaitez. La différence avec une architecture purement liée au cloud n'est pas seulement technique. Elle déplace la charge de la preuve : au lieu d'espérer qu'un fabricant ne capte pas de données sensibles, vous définissez activement ce qui a le droit de quitter votre établissement, et vous pouvez également le démontrer.

Comment Axiona rend cela possible

Axiona est la couche entre les robots et le monde extérieur, conçue pour une exploitation encapsulée et traçable. La coordination des tâches, l'intégration aux portes et aux ascenseurs, et la connexion aux systèmes tiers passent par une couche d'intégration commune, que vous exploitez on-premise ou hors ligne. Vous raccordez les robots via des adaptateurs, au lieu de les coupler à un cloud tiers. Vous décidez ainsi quelles données restent locales, et lesquelles sortent réellement vers l'extérieur.

Le modèle d'adaptateurs a un effet secondaire pratique : il découple le matériel de la logique de contrôle. Vous pouvez remplacer un robot ou en ajouter un second type sans reconstruire les processus qui reposent dessus. C'est précisément ce point qui décide souvent si un projet pilote passe à l'échelle ou reste bloqué dans une solution isolée.

Une précision réaliste : les modes opérationnels possibles dépendent du produit, de l'exigence de conformité et du modèle de robot concerné. Nous évaluons cela projet par projet, plutôt que de faire des promesses générales. Et tout aussi honnêtement : un logiciel ne rend personne automatiquement conforme à NIS 2. Un système exploité on-premise est un socle nécessaire pour la souveraineté des données, mais il ne remplace ni une organisation d'exploitation rigoureuse, ni la qualification juridique de votre établissement. Nous vous disons ce que la technique apporte, et ce que vous devez compléter sur le plan organisationnel.

Preuve tirée de l'exploitation réelle

La technologie est issue du projet de recherche SMART FOREST 5G Clinics à la TH Deggendorf et fonctionne en exploitation réelle depuis 2023 dans deux cliniques. La plateforme y pilote notamment des intégrations d'ascenseurs on-premise, par exemple une connexion GWH LiSA10 pour un Keenon W3. Vous pouvez consulter les modèles compatibles hors ligne et avec les ascenseurs dans notre comparatif des robots de service.

La différence entre une démonstration et une exploitation réelle est considérable, en particulier sur la question du flux de données. En exploitation continue, on voit si une intégration locale à l'ascenseur fonctionne encore de façon fiable lorsque la connexion internet se coupe brièvement, et si l'exploitation se poursuit sans recours constant à un cloud externe. Une affirmation « on-premise » n'est solide que lorsqu'elle a rempli ces conditions pendant des mois, pas dans un environnement de salon contrôlé.

Ce à quoi vous devez veiller lors de l'achat

Qui prend la souveraineté des données au sérieux la vérifie avant l'achat, pas après. Trois questions aident à séparer le marketing de la substance. Premièrement, quelles données quittent l'établissement en fonctionnement normal, et ce trafic peut-il être entièrement désactivé sans que la fonction principale ne tombe en panne ? Deuxièmement, le contrôle critique en temps s'exécute-t-il de façon démontrable en local, ou dépend-il d'un service externe ? Troisièmement, les robots sont-ils raccordés via des adaptateurs ouverts, de sorte que vous puissiez changer de modèle plus tard sans perdre l'intégration ?

Ces points ont leur place dans le cahier des charges et dans les contrats, pas dans une conversation après coup. Une souveraineté des données qui n'apparaît qu'à l'audit coûte en général plus cher à rattraper qu'à planifier dès le départ. Vous en saurez plus sur notre approche et les principes qui la sous-tendent sous Souveraineté et sécurité.

Prochaine étape

Si l'emplacement de vos données est un critère, vous devriez définir tôt le modèle opérationnel. Parlez-nous de vos exigences, ou approfondissez notre approche sous Souveraineté et sécurité.