NIS 2 et robotique de service : un guide pratique

Vous prévoyez des robots de service dans une clinique, un opérateur de services essentiels ou un autre établissement réglementé ? Vous ne décidez alors pas seulement d'un robot, mais de l'ajout d'un système informatique dans un environnement soumis à des obligations renforcées de sécurité et de signalement. La directive NIS 2 n'exige pas une marque de robot en particulier. Elle exige que vous sachiez où se trouvent les données, qui y a accès, et comment vous réagissez en cas d'incident.

Ce déplacement de perspective passe facilement inaperçu. Dans l'achat, c'est le robot qui occupe le premier plan : que peut-il transporter, avec quelle fiabilité roule-t-il, combien coûte-t-il ? D'un point de vue réglementaire, pourtant, le robot n'est qu'un point d'accès. Ce qui compte, c'est ce qui se trouve derrière lui : le logiciel de contrôle, les interfaces vers les portes et les ascenseurs, les flux de données vers les clouds des fabricants, et la question de savoir qui porte la responsabilité en cas d'incident grave. Qui y pense tôt évite des mises à niveau coûteuses par la suite.

Ce dont il s'agit avec la directive NIS 2

En Allemagne, le régime national dit KRITIS oblige les opérateurs d'infrastructures critiques à mettre en œuvre une sécurité conforme à l'état de l'art et à signaler les perturbations importantes. La directive européenne NIS 2 élargit le cercle des entités concernées et fixe des exigences en matière de gestion des risques, de sécurité de la chaîne d'approvisionnement, de signalement des incidents et de responsabilité de la direction. L'étendue exacte des obligations dépend de la transposition nationale et du fait que votre établissement entre ou non dans le champ d'application. Cette qualification est à clarifier avec vos responsables sécurité et juridique.

Pour le déploiement de robots, l'essentiel tient en peu de mots : un robot connecté fait partie de votre surface d'attaque et de votre traitement de données. Les mêmes principes de base s'appliquent donc, comme pour tout autre système dans un environnement réglementé.

Ce qui frappe surtout, c'est l'élargissement du champ d'application. NIS 2 couvre nettement plus d'entités que le régime précédent, et elle prend explicitement en compte la chaîne d'approvisionnement. Un robot exploité ou télémaintenu par un prestataire externe est précisément un tel maillon de la chaîne d'approvisionnement. S'y ajoute la responsabilité personnelle de la direction : les dirigeants peuvent être tenus responsables des manquements dans la gestion des risques. Cela fait remonter la question « ce système est-il vraiment sûr ? » du service informatique jusqu'au conseil de direction.

Quelles décisions d'architecture comptent maintenant

Quatre points décident, en pratique, si un projet de robotique complique vos obligations ou les soutient :

• Emplacement des données et modèle opérationnel. Si le contrôle s'exécute on-premise, voire hors ligne, les données d'exploitation restent dans votre environnement. Cela réduit la dépendance aux services externes et simplifie l'évaluation des flux de données.
• Accès et traçabilité. Les rôles, les autorisations et un journal traçable de qui a déclenché quoi constituent la base des audits et du traitement des incidents.
• Réseau et segmentation. Robots, portes et ascenseurs devraient être raccordés de façon contrôlée, et non connectés à plat dans chaque réseau. Une couche d'intégration commune rend ces limites visibles et pilotables.
• Indépendance vis-à-vis des fabricants. Si un fournisseur contrôle toute la chaîne, vous héritez de ses risques et de ses circuits de signalement. Une couche neutre entre les robots et votre informatique garde le contrôle entre vos mains.

Ces quatre points sont liés entre eux. Un contrôle lié au cloud complique non seulement l'évaluation des flux de données, il transfère aussi au fabricant le contrôle de la disponibilité et des mises à jour. Un raccordement réseau à plat facilite certes la mise en service, mais agrandit la surface d'attaque et rend la segmentation coûteuse à mettre en place après coup. L'ordre le plus avantageux, tant économiquement que sur le plan réglementaire, est donc presque toujours le même : clarifier d'abord l'architecture, acheter ensuite.

Pièges habituels en pratique

Dans les échanges avec les établissements, nous retrouvons sans cesse les mêmes schémas. Premièrement, la dépendance silencieuse au cloud : un robot ne fonctionne que tant qu'il reste connecté au cloud du fabricant. Si la connexion tombe, ou si le fournisseur change ses conditions, l'exploitation s'arrête – un risque qui pèse lourd dans les environnements réglementés. Deuxièmement, l'absence de journaux : sans enregistrement traçable de qui a déclenché quelle action, un incident est difficile à reconstituer après coup, et donc difficile à signaler. Troisièmement, le mélange des réseaux : des robots qui dialoguent directement avec des systèmes cliniques ou opérationnels critiques parce que c'était plus simple lors de la mise en service. Ce type de raccourci se paie cher au premier audit.

Aucun de ces points n'est exotique. C'est la variante robotique d'exigences qui vont depuis longtemps de soi dans tout autre achat informatique. La différence : chez les robots, les interfaces sont physiques – des portes s'ouvrent, des ascenseurs se déplacent – si bien que la question de sécurité est en même temps une question de sécurité d'exploitation.

Comment Axiona y contribue

Axiona est la couche neutre et indépendante des fabricants entre les robots et le monde extérieur. Elle est conçue pour une exploitation encapsulée et traçable, et peut fonctionner on-premise ou hors ligne, selon le modèle opérationnel. Vous raccordez robots, portes, ascenseurs et systèmes tiers via des adaptateurs, au lieu de les câbler en dur entre eux. Les accès passent par des rôles et des politiques.

L'approche par adaptateurs est ici plus qu'une commodité technique. Elle rend explicites les frontières entre les systèmes : chaque connexion est nommée, contrôlable et remplaçable. Un fabricant peut être remplacé sans reconstruire toute l'intégration, et un appareil compromis à lui seul reste confiné à son périmètre d'effet clairement délimité. C'est précisément cette visibilité qu'il faut pour documenter les flux de données et circonscrire les incidents.

Précision importante : un logiciel ne vous rend pas automatiquement conforme à NIS 2. La conformité est un processus organisationnel. Axiona est construit pour soutenir ce processus plutôt que pour lui faire obstacle, en gardant l'emplacement des données, l'accès et l'intégration sous votre contrôle. La responsabilité du champ d'application, des circuits de signalement et de l'évaluation des risques reste à votre organisation – l'architecture peut faciliter ce travail, mais ne peut pas le remplacer.

Preuve tirée de l'exploitation réelle

La technologie sous-jacente est issue du projet de recherche SMART FOREST 5G Clinics à la TH Deggendorf et fonctionne en exploitation réelle depuis 2023 dans deux cliniques, l'Arberlandklinik Viechtach et les Kliniken am Goldenen Steig à Freyung. Les robots de service y sont coordonnés avec une intégration aux portes et aux ascenseurs, exploitable on-premise. Nous avons publié, avec des chercheurs, l'évaluation au regard de la protection des données des systèmes à commande vocale en milieu hospitalier.

La différence entre une démonstration et une exploitation solide ne se révèle qu'avec le temps. Un système qui fonctionne depuis 2023 dans deux établissements, dans le quotidien clinique réel, a été confronté exactement aux frictions qui apparaissent rarement dans un projet pilote : exigences changeantes, fenêtres de maintenance, exceptions dans les opérations courantes. Cette expérience s'est intégrée à l'architecture – et c'est la raison pour laquelle nous misons aussi systématiquement sur la contrôlabilité de l'emplacement des données, de l'accès et de l'intégration.

Prochaine étape

Si vous prévoyez de la robotique dans un environnement réglementé, le regard architectural avant l'achat est rentable. Parlez-nous de votre projet, ou lisez-en davantage sur notre approche sous Souveraineté et sécurité.