Brevet FR3099256A1 — publié le 20210129

Description Titre de l'invention : PASSERELLE CLOUD Domaine technique [0001] Ce document concerne le domaine des communications électroniques et plus particu- lièrement des passerelles pour accéder à des réseaux dans le contexte spécifique des hôtels. [0002] Contexte [0003] Le basculement vers le Cloud s'observe dans beaucoup d'industries, mais certains domaines techniques doivent s'accommoder des systèmes hérités (héritage de systèmes du passé pour lesquels aucune substitution n'est possible). Par conséquent, des adaptations substantielles doivent parfois être réalisées, laissant place à des perturbations. [0004] Dans l'industrie de l'hôtellerie, un hôtelier utilise un soi-disant « système de gestion de bien », dont l'acronyme est PMS (Property Management System) pour gérer ses activités journalières (enregistrements des arrivées, départs, etc.). Un tel système interagit en fait avec une variété de systèmes locaux existants, ci-après appelés systèmes hérités qui comprennent par exemple des cartes-clés magnétiques (lecture/écriture), des systèmes de téléphonie de points de vente, des systèmes de vidéo à la demande, etc. De nouveaux systèmes peuvent être ajoutés, y compris des systèmes propriétaires. [0005] Beaucoup de ces systèmes locaux sont anciens, mais les hôteliers (ou leurs four- nisseurs respectifs) n'ont pas projeté de les remplacer. Ces dispositifs ne sont généralement pas capables de communiquer sur Internet. En outre, le cas échéant, chacun de ces systèmes peut utiliser son propre protocole de communication, via des interfaces de connexions différentes. Par exemple, les interfaces sérielles RS232 peuvent toujours être (intensément) utilisées. Certains systèmes peuvent convertir les interfaces RS232 au TCP/IP, mais cela peut demander une quantité non négligeable de travail et de maintenance. D'autres systèmes sont limités. Par exemple, l'utilisation d'un dispositif sériel-à-IP permettant la virtualisation de connexions sérielles, peut impliquer l'usage en aval de machines virtuelles qui peuvent difficilement s'intégrer avec les APIs cloud prédéfinies offertes par des plateformes cloud. [0006] De plus, la plupart de ces systèmes hérités ne sont pas sécurisés (trafic de données en clair, etc.). [0007] De nos jours, les offres commerciales prêtes à l'emploi proposées par les fournisseurs de technologie hôtelière, tels que Digi ou Comtrol, qui visent à connecter les systèmes hérités existants à un PMS (quel que soit le type), s'avèrent limitées (quand elles existent). Par exemple, il est impossible de connecter directement des dispositifs 2 présentant des interfaces RS232 à des APIs existantes du Cloud. [0008] Résumé : [0009] Le document décrit des systèmes et des procédés pour gérer des dispositifs locaux (hérités). Une passerelle cloud locale comprend une pluralité de connecteurs d'interface de types différents pour connecter physiquement une pluralité de ces dispositifs hérités au cloud, comprenant une pluralité de serveurs distants. Les développements décrivent l'étape d'extraction de messages fonctionnels des messages émergeant de dispositifs locaux hérités (p. ex. des convertisseurs de protocole), des communications sécurisées, des représentations logiques de dispositifs hérités dans le cloud («jumeaux ») des options d'administration, diverses d'interfaces d'utilisateur (p. ex. un vibreur) pour une utilisation et une configuration transparentes, l'utilisation d'un ou de plusieurs actionneurs (rétroactions sur le monde physique), etc. Des modes de réalisation logiciels et/ou matériels sont décrits. [0010] Les modes de réalisation de l'invention présentent de nombreux avantages. [0011] La configuration de l'utilisateur est minimale et conviviale. Le déploiement est simple, réduit au maximum. Les intégrations sont transparentes. Les utilisateurs peuvent se concentrer sur leur coeur de métier. Par conséquent l'adoption par l'utilisateur peut être maximisée. [0012] Le trafic peut être sécurisé en aval du client de la passerelle cloud. Par exemple, un espionnage néfaste potentiel serait nécessairement local (c.-à-d. qu'il nécessiterait une intervention physique en aval de la passerelle cloud). [0013] De façon avantageuse, les services gérés dans le cloud sont par définition éche- lonnables. Les services peuvent être sous-traités, et surveillés et gérés à distance. En d'autres termes, l'intelligence de gestion est déportée dans le Cloud, permettant des mises à jour et des mises à niveau rapides et vérifiées. La mutualisation de la gestion des systèmes permet des économies d'échelle et permet en fin de compte que de meilleurs services soient délivrés localement. [0014] De façon avantageuse, dans certains modes de réalisation, le matériel du boîtier est configurable, par exemple extensible (il nécessiterait de nouveaux connecteurs d'interface, il est possible d'ajouter du nouveau matériel monté sur le boîtier initial). [0015] De façon avantageuse, l'infrastructure du Cloud peut être totalement agnostique sur le matériel du boîtier. [0016] De façon avantageuse, l'intégration du nouveau dispositif local (et de son protocole associé) peut se faire d'une manière transparente : le trafic de données est encapsulé et géré dans le cloud, c.-à-d. sans aucun impact sur les boîtiers déjà déployés. [0017] De façon avantageuse, le système global comprenant la partie boîtier et la partie cloud est simple à déployer, facile à gérer, transparent pour l'utilisateur et permet des communications avec tout type de dispositifs ou de protocoles (même dans le futur). 3 Par construction le système clans son ensemble est fiable. De façon générale, les modes de réalisation de l'invention peuvent être avantageux pour d'autres domaines techniques dans lesquels il existe un besoin de connecter des systèmes non sécurisés à des services gérés clans le cloud. Brève description des dessins [0018] Des modes de réalisation (le l'invention seront maintenant décrits à titre (l'exemple en faisant référence aux dessins qui accompagnent dans lesquels des références similaires dénotent des éléments similaires et dans lesquels : [0019] [fie.1] montre un exemple d'un mode (le réalisation d'un système conformément à l'invention (de la perspective côté client.); [0020] [fig.2] montre un exemple d'un mode de réalisation d'un système conformément à l'invention (de la perspective côté serveur); [0021] [fig.3] montre des exemples des étapes sur un mode de réalisation du procédé conformément à l'invention ; [0022] [fig.4] illustre l'étape d'extraction de messages fonctionnels des dispositifs hérités. Description détaillée [0023] Un « système de gestion de bien» (Property Management System) dont l'acronyme est PMS désigne généralement un dispositif autonome. Il peut être utilisé dans des hôtels, des motels, des stations balnéaires, des hôpitaux, des complexes d'appartements/maisons de ville, des restaurants, des maisons de retraite, des bateaux de croisières, des bus, des compagnies aériennes, des centres commerciaux, des trains de passagers, des casinos, etc. Un PMS présente un nombre limité d'interfaces de communication qui permettent à des dispositifs externes de services pour les clients, ci-après « systèmes hérités locaux » d'accéder à des informations stockées dans le PMS en envoyant et en recevant des messages vers et en provenance du PMS via lesdites interfaces de communication. Le PMS peut aussi envoyer des messages de notification à des dispositifs de services pour les clients via les interfaces de communication. Un port sériel est souvent inclus comme une des interfaces permettant l'interconnexion à un dispositif de services pour les clients tels qu'un contrôleur du système de téléphonie décrit ci-dessus. Une pluralité de ports sériels pour se connecter à de multiples dispositifs de services pour les clients peut être incluse, permettant par exemple des connexions simultanées à un contrôleur de système de téléphonie, à un contrôleur de portes à accès électronique, à un contrôleur d'accès à la porte d'un minibar, à un contrôleur de vidéo à la demande (YOD), un contrôleur d'internet à haut débit (HSIA), une télévision payante, etc. Un ou plusieurs ports de réseau peuvent aussi être inclus comme interfaces de communication afin de permettre au PMS de communiquer avec un nombre quelconque de dispositifs de services pour les clients via un réseau in- formatiquc. [0024] Plus généralement, un « système de gestion » peut être utilisé n'importe 0i:1/n'importe quand une pluralité de dispositifs locaux est présente et requiert une gestion centralisée (ou décentralisée). Le champ d'application de l'invention englobe donc des systèmes de gestion de toutes sortes, non limités aux soi-disant systèmes PMS décrits ci-dessus. Des modes de réalisation de l'invention peuvent être appliqués à la gestion de flotte de véhicules ou de drones, de places de parking, etc. [0025] Un «capteur » est un objet ou un dispositif dont le but est de détecter des événements ou des changements dans son environnement et de fournir ensuite un résultat correspondant. Un capteur présente des déviations. Si le capteur n'est pas idéal, plusieurs types de déviation peuvent être observées. En particulier, le bruit est une déviation aléatoire du signal qui varie dans le temps. Un capteur conformément à des modes de réalisation de l'invention peut être un ou plusieurs d'un capteur de pression, d'un capteur ultrasonique, d'un capteur d'humidité, d'un capteur de gaz, d'un capteur de mouvement, d'un capteur d'accélération ou accéléromètre, d'un capteur de déplacement, d'un capteur de mesure de force, d'un capteur gyroscopique ou gyroscope, d'un capteur de température, d'un capteur d'image, d'un capteur de vidéo, d'un capteur d'U.V., d'un capteur magnétique, d'un capteur d'image CMOS, d'un microphone en silicone, d'une unité de mesure d'inertie (IMU), d'un capteur de pression, d'un micromiroir, d'un capteur de radiofréquences, d'un capteur de champ magnétique, d'un compas numérique, d'un oscillateur, d'un luxmètre ou capteur de lumière, d'un capteur de proximité, d'un G. N. S. S. (p. ex. GPS), d'un capteur barométrique, d'un capteur Wifi, d'un capteur Bluetooth, d'un capteur NFC, d'un pédomètre, d'un capteur d'oxymétrie de pouls, d'un capteur de taux cardiaque, d'un capteur d'empreinte digitale... [0026] Un « actionneur » fait référence à un composant qui est responsable du mouvement et/ou du contrôle d'un mécanisme ou d'un système. Un actionneur nécessite un signal de contrôle et une source (l'énergie. Un actionneur peut aussi être une source de données (soit directe ou indirecte via un capteur couplé) qui peut être manipulée par des modes de réalisation de l'invention (comme des données émergeant d'un ou de plusieurs capteurs). Un actionneur est généralement utilisé avec au moins un capteur. En d'autres termes, un capteur peut être activé par un actionneur. Un « actionneur » selon l'invention peut être un des éléments sélectionnés dans le groupe consistant d'un moteur (p. ex. électrique, piézo-électrique, pas à pas), un actionneur autofocus, un microparleur, un micromiroir, un polymère électro-actif, un servomécanisme, un alliage à mémoire de forme, un composant haptique (p. ex. vibratile), etc. Notamment, les actionneurs placés à une extrémité de la chaîne de contrôle peuvent être contrôlés par la passerelle cloud et/ou par un ou plusieurs serveurs cloud. En d'autres termes, des coin- munications bilatérales entre l'actionneur(s), la passerelle(s) et le serveur(s) cloud peuvent survenir. [0027] Une «passerelle cloud» est un «dispositif client », ci-après dans la présente parfois désignée comme « boîtier» qui désigne du matériel et des logiciels conformément à des modes de réalisation de l'invention. Un hôtel peut comprendre un plusieurs boîtiers. [0028] Le ternie «Cloud » désigne une pluralité de serveurs (interconnectés, généralement coopérants). Un serveur cloud peut être une entité physique, c.-à-d. une machine réelle. Dans certains modes de réalisation, un serveur cloud peut correspondre à une ou plusieurs machines virtuelles (c.-à-d. un décuplement de matériels et de logiciels). L'expression « serveur cloud » peut être remplacée par « serveur accédé à distance ». [0029] Les termes « local » et «distant » font référence à des termes relatifs du point de vue du client (celui de la passerelle matérielle). Les termes peuvent être intervertis (pour obtenir la perspective du Cloud). L'utilisation des deux ternies dans tous les cas ne laisse aucune ambiguïté par rapport à (la séparation dans) l'espace. Par rapport aux horaires, le client(s) local et le serveur(s) distant fonctionnent durant la même fenêtre temporelle, c.-à-d. avec des délais de transmission et de traitement (presque dans une fourchette en temps réel). [0030] Les « messages fonctionnels » désignent la «charge utile» des messages qui sont utilisés dans le Cloud. En d'autres termes, les messages fonctionnels correspondent en substance bien que la forme puisse varier. Les messages fonctionnels sont interprétés (c.-à-d. convertis et exécutés) dans et/ou par le cloud qui est du côté serveur. [0031] Le traitement est donc pour la plupart, si ce n'est exclusivement, mis en oeuvre dans le Cloud (arrière-plan, orchestration des services). De façon avantageuse, aucune configuration n'est requise en particulier du côté client (moins de puissance de calcul est requise côté client). La gestion des protocoles et des messages peut être effectuée dans le cloud (p. ex. des serveurs distants). Localement la solution proposée est «prête à l'emploi » fournissant un « couteau suisse» (potentiellement reconfigurable) pour connecter physiquement des dispositifs hérités locaux et pour gérer des données et/ou des programmes dans le cloud. [0032] Il est divulgué un système pour la gestion de dispositifs locaux (hérités) (p. ex. un système de gestion de bien pour un hôtel), ledit système comprenant : un ou plusieurs serveurs cloud distants, un serveur cloud distant fournissant une pluralité de services cloud; une passerelle cloud locale faisant interface avec lesdits dispositifs hérités locaux, ladite passerelle cloud locale comprenant : une enceinte comprenant une pluralité de connecteurs d'interface de types différents, lesdits connecteurs d'interface étant configurés pour connectés physiquement un ou plusieurs dispositifs locaux hérités à un ou plusieurs serveurs cloud distants ; lesdits connecteurs d'interface 6 comprenant au moins un connecteur sériel RS232 ; des ressources de communication configurécs pour échanger des données vers et en provenance desdits dispositifs hérités en utilisant lesdits connecteurs d'interface avec ledit un ou plusieurs serveurs cloud distants, en utilisant des messages à une couche OSI inférieure ou égale au TCP/IP; le traitement des ressources configuré pour extraire un ou plusieurs messages fonctionnels à partir des données reçues de chacun desdits connecteurs d'interface, lesdits un ou plusieurs messages fonctionnels étant situés à une couche OSI inférieure ou égale au TCP/IP; dans lequel la passerelle cloud locale est configurée pour initier un canal de communication sécurisé afin de communiquer un plusieurs messages fonctionnels extraits vers un ou plusieurs serveurs cloud distants ; dans lequel un service de protocole de message exécuté dans un service cloud distant est configuré pour recevoir et décoder ledit un ou plusieurs messages fonctionnels extraits communiqués via le canal de communication sécurisé. [0033] Le terme « hérité » doit être interprété dans son sens le plus large. TI rappelle le fait que ces dispositifs hérités locaux sont fournis «tels quels » généralement avec une technologie et des ports anciens sinon obsolètes (problème technique initial). Le terme souligne aussi que beaucoup de dispositifs sont préexistants et ne sont pas modifiables. Les modes de réalisation de l'invention doivent s'accommoder de cette base de dispositifs installés (c.-à-d. faire interface avec eux). En effet, les dispositifs hérités locaux qui sont manipulés ne sont généralement pas modifiables. Et pourtant, dans certains modes de réalisation, certains (plus récents) dispositifs hérités peuvent être ajoutés au système entier et par conséquent la base gérée de dispositifs peut être « hybride», comprenant une large fraction de dispositifs hérités locaux qui restent non modifiables alors qu'au moins un dispositif local est modifiable (p. ex. configurable en partie). Dans ces situations, ledit dispositif local spécifique modifiable/configurable peut être modifié ou configuré. [0034] En d'autres termes, les communications entre les dispositifs hérités locaux et la passerelle sont généralement unilatérales (des dispositifs hérités vers la passerelle qui s'adapte au trafic reçu) ; mais dans d'autres situations, la communication avec la passerelle peut être bilatérale, au moins jusqu'à un certain point. Si le dispositif hérité local au bout s'avère être contrôlable à un moment donné, alors des modèles autres que ceux qui sont décrits dans la présente peuvent être dérivés. Par exemple, si la configuration du port est activée sur un dispositif hérité final, la passerelle peut interagir avec le dispositif hérité modifiable et modifier par exemple la configuration de port à la volée. Beaucoup d'autres paramètres peuvent ainsi être contrôlés ou autrement modifiés dans le dispositif hérité reconfigurable, via/par la passerelle, via/par le Cloud. Des développements autour de la détermination et de la gestion des fichiers de configuration peuvent aussi être sophistiqués avec des fichiers de configuration à plusieurs 7 niveaux. La présente description peut être modifiée pour prendre en charge «des dispositifs locaux non modifiables ou configurables » avec «des dispositifs locaux modifiables ou configurables » plutôt que de prendre en charge des dispositifs « hérités ». [0035] Dans un mode de réalisation, un serveur cloud distant est configuré pour fournir : un service de gestion de protocole de message pour gérer les communications de données vers et en provenance de ladite pluralité de dispositifs hérités locaux ; un service orchestrateur pour gérer une pluralité de dispositifs hérités locaux ou des représentations de ceux-ci ; dans lequel un dispositif hérité local parmi une pluralité est identifié par un service orchestrateur exécuté dans un serveur distant. [0036] Dans un mode de réalisation, le dispositif hérité identifié est configuré pour com- muniquer directement au service orchestrateur en utilisant des protocoles bas niveau. [0037] Dans un mode de réalisation, un service de protocole de message exécuté dans un serveur cloud distant est configure pour crypter et communiquer un ou plusieurs messages fonctionnels à la passerelle cloud locale. [0038] Dans un mode de réalisation, un ou plusieurs serveurs cloud distants sont configurés pour traiter lesdits un ou plusieurs messages fonctionnels reçus des dispositifs hérités locaux. [0039] Dans un mode de réalisation, un ou plusieurs serveurs cloud existants sont gérables via une interface d'administration accessible par Internet. [0040] Dans un mode de réalisation, une passerelle cloud locale est associée à une passerelle cloud distante correspondante, ou jumelle, hébergée dans un serveur cloud distant. [0041] Dans un mode de réalisation, la passerelle cloud locale comprend par ailleurs une mémoire pour antémémoriser des données reçues et/ou préextraites dans le cloud, dans lequel au moins un protocole bas niveau particulier nécessite une durée maximale pour fournir une réponse par ladite passerelle cloud locale. [0042] Dans un mode de réalisation, l'enceinte de la passerelle cloud locale est expansible par l'addition d'un module comprenant un connecteur d'interface d'un type différent. [0043] Dans un mode de réalisation, le système comprend par ailleurs un transducteur piézo- électrique, ledit vibreur étant configuré pour vibrer et émettre des codes sonores d'erreur en fonction de séquences correspondantes prédéfinies. [0044] Dans un mode de réalisation, le système comprend par ailleurs un serveur web configuré pour servir au moins une page web affichant l'état opérationnel respectif des services demandés ou dans lequel les divers états de services sont affichables sur une page web récupérée du réseau. [0045] Dans un mode de réalisation, un fichier de configuration en deux parties est déterminé à partir d'un catalogue expansible de convertisseurs de protocole bas niveau, dans lequel une première partie du fichier de configuration est communiqué à la passerelle cloud locale, ladite première partie comprenant une information de numéro 8 de port utilisé par le dispositif hérité local et une deuxième partie du fichier de configuration est communiquée à un service de protocole de message exécuté dans un serveur cloud distant. [0046] Le partitionnement (ou la division avec chevauchement) du fichier de configuration en plusieurs parties est avantageux : chaque partie de matériel le long de la chaîne reçoit les informations nécessaires et suffisantes pour coopérer avec les autres. Les calculs intensifs potentiels sont déportés dans le cloud, comprenant des ressources élastiques par construction pendant que la passerelle cloud locale amasse et gère des informations nécessaires et suffisantes sur le terrain. Il en résulte que les temps de réponse sont écourtés et que la réactivité du système global est améliorée. La flexibilité est apportée à un coût négligeable, car les dispositifs hérités locaux ont été unifiés et sont gérés à distance. [0047] Dans un mode de réalisation, le système comprend par ailleurs un ou plusieurs ac- tionneurs locaux. [0048] Dans un mode de réalisation, les dispositifs hérités locaux sont associés à un système de gestion de bien, dans un hôtel ou un bateau de croisière ou un hôpital. Dans un autre mode de réalisation, des dispositifs locaux sont associés à un système de gestion d'un type différent (la gestion de flottes de véhicules, d'une base installée de consoles, de flottes de drones, etc.). [0049] Il est décrit un procédé implémenté par ordinateur dans un dispositif client pour accéder à des services hébergé dans le cloud, comprenant les étapes suivantes : la connexion d'un ou de plusieurs dispositifs hérités locaux à un ou plusieurs connecteurs d'interface de types différents d'une passerelle cloud locale ; lesdits connecteurs d'interface comprenant un port TCP/IP comme sortie ; la réception de données en provenance de ladite pluralité de connecteurs d'interface de types différents ; l'extraction d'un ou de plusieurs messages fonctionnels à partir des données reçues desdits connecteurs d'interface ; la communication d'un ou de plusieurs messages fonctionnels à un ou plusieurs serveurs distants. Dans un mode de réalisation, lesdits connecteurs d'interface comprennent un connecteur sériel RS232 comme entrée. [0050] Dans un mode de réalisation, les messages fonctionnels sont extraits en utilisant un catalogue expansible de protocoles bas niveau. [0051] Dans un mode de réalisation, les communications sont cryptées. [0052] 11 est décrit un procédé implémenté par ordinateur dans un dispositif client pour accéder à des services cloud, comprenant les étapes de connexion d'un ou de plusieurs dispositifs hérités locaux à un ou plusieurs connecteurs d'interface de types différents d'une passerelle cloud locale ; de réception de données en provenance de ladite pluralité de connecteurs d'interface de types différents ; l'extraction d'un ou de plusieurs messages fonctionnels à partir des données reçues desdits connecteurs 9 d'interface ; et de communication d'un ou de plusieurs messages fonctionnels à un ou plusieurs serveurs distants. [0053] Dans un mode de réalisation, le procédé comprend par ailleurs l'étape d'extraction de messages fonctionnels en utilisant un catalogue expansible de protocoles bas niveau et comprenant l'étape de détermination d'au moins un fichier de configuration associé à un dispositif hérité local. [0054] Dans un mode de réalisation, le procédé comprend par ailleurs l'étape d'identification d'un dispositif hérité local et la communication d'une partie du fichier de configuration correspondant à une passerelle cloud locale, ladite partie comprenant une information de numéro de port utilisé par un dispositif hérité local. [0055] Dans un mode de réalisation, le procédé comprend par ailleurs l'étape de commu- nication d'une autre partie du fichier de configuration à un service de protocole de message exécuté dans un serveur cloud distant. [0056] Dans un mode de réalisation, le procédé comprend par ailleurs les étapes d'enregistrement d'un ou de plusieurs dispositifs hérités locaux auprès de la passerelle cloud locale, en mappant les dispositifs hérités locaux sur lesdits ports de passerelle cloud locale ; l'enregistrement desdits dispositifs hérités locaux auprès d'un ou de plusieurs serveurs cloud et l'initialisation de ladite passerelle. [0057] Dans un mode de réalisation, le procédé comprend par ailleurs les étapes de réception des données d'un ou de plusieurs serveurs cloud, lesdites données comprenant des instructions exécutables ; l'exécution desdites instructions exécutables sur un ou plusieurs dispositifs hérités locaux. [0058] Il est divulgué un programme informatique comprenant des instructions pour mettre en oeuvre une ou plusieurs des étapes du procédé lorsque ledit programme informatique est exécuté sur un dispositif informatique. [0059] [fig.1] montre un exemple d'un mode de réalisation d'un système conformément à l'invention (de la perspective côté client); [0060] Un «boîtier» (100) interagit avec le système de gestion cloud (130) dans le Cloud (131). Le boîtier peut être placé dans un bâtiment (101), par exemple un hôtel. Dans des variantes, le boîtier peut être placé dans un motel, une station balnéaire, un hôpital, un appartement, un restaurant, une maison de retraite, un bateau de croisière, un bus, un avion, un centre commercial, un train, un casino, etc. Le dispositif physique (100) comprend un gestionnaire de communication local (110) qui comprend une pluralité de connecteurs (11011, 1102 and 1103). [0061] Les données sont reçues des systèmes hérités (11011, 11021, 11031). Un système hérité peut être un téléphone, un actionneur de porte électronique, un actionneur de porte de millibar, un contrôleur d'accès, un contrôleur de vidéo à la demande, un contrôleur d'éclairage, etc. Plus généralement, un tel système peut être un quelconque dispositif électronique de consommateur (p. ex. un ordinateur portable, une montre connectée, un dispositif de réalité virtuelle ou de réalité augmentée, une console de jeux, une télévision, etc.) ou tout dispositif Internet d'objet (IoT) également (p. ex. des compteurs intelligents dans la domotique ; des composants mécatroniques dans l'automobile ; des dispositifs médicaux ou des composants dans le domaine de la santé ; des éléments pour l'infrastructure p. ex. une ville intelligente, le transport, logistique ; des dispositifs bancaires dans la finance ; etc. [0062] Lesdits systèmes hérités peuvent comprendre des capteurs et/des actionneurs. Par exemple un actionneur (11031) peut être connecté au connecteur d'interface 1103. Les connexions entre les connecteurs d'interface et les systèmes connectés peuvent être filaires, mais certains peuvent être sans fil p. ex. 11021. Par exemple un dispositif sériel-à-IP peut envoyer des données via Wifi. Bluetooth ou Li-Fi ou toute autre interface de communication de courte portée peuvent être utilisés. [0063] Le gestionnaire de protocoles bas niveau (111), configure dans, ou en association avec le boîtier 100 gère lesdites données reçues. Les messages ou les charges utiles sont ensuite extraits desdites données et communiqués au gestionnaire de communication local (110). [0064] Par la suite, les charges utiles extraites sont envoyées au gestionnaire de client cloud (120) qui à son tour interagit avec le gestionnaire de serveur cloud (non illustré, dessin suivant). [0065] Dans un mode de réalisation, les exigences en matière de matériel du boîtier sont réduites à la quantité minimale requise, c.-à-d. la connectivité de matériel et la gestion de protocoles bas niveau. [0066] Dans certains modes de réalisation, le boîtier (bord) est plus intelligent ou « smart». Par exemple, certaines contraintes de temps par rapport aux échanges d'accusés réception positifs et négatifs (ack-nack) peuvent avantageusement être gérées via une mémoire spécifique ou des unités tampons. D'autres modes de réalisation sont possibles (des modèles de transmission immédiate aux modèles de stockage et de retransmission, dans lesquelles les données peuvent être temporairement stockées dans un stockage local au cas où les communications entre la passerelle cloud et la plateforme cloud seraient perturbées). [0067] Dans un mode de réalisation, le boîtier ou l'enceinte de la passerelle cloud locale est expansible par l'addition d'un module comprenant un connecteur d'interface d'un type différent. Dans un mode de réalisation, le dispositif client comprend par ailleurs des lumières arrangées sur l'enceinte, configurées pour afficher l'état opérationnel respectif des services demandés. Par exemple, à côté de chaque interface, des LEDs verts ou rouges confirment ou infirment l'état opérationnel du service adressé par l'interface. Divers modes de réalisation sont possibles. Une lumière verte clignotante 11 peut signifier que la connexion au Cloud est opérationnelle, mais que le service correspondant n'est pas encore actif. [0068] Dans un mode de réalisation, le boîtier ou l'enceinte de la passerelle cloud locale comprend un transducteur piézo-électrique, ledit vibreur étant configure pour vibrer et émettre des codes sonores d'erreur en fonction de séquences correspondantes pré-définies. En effet, en l'absence d'un affichage, l'unité vibrante du boîtier peut être exploitée de façon opportune. Dans un mode de réalisation, l'enceinte du dispositif comprend par ailleurs un bouton d'aide, un déclenchement dudit bouton établissant un appel téléphonique pour obtenir une assistance. [0069] Dans un mode de réalisation, le boîtier comprend un serveur web configure pour servir au moins une page wcb affichant l'état opérationnel respectif des services demandés. [0070] Dans un mode de réalisation, les différents états des services sont affichables sur une page web récupérée du réseau. Par exemple, un téléphone mobile peut accéder à la page web en utilisant par exemple le même réseau Wifi. Dans des variantes, la page web est projetée sur un bureau ou sur un mur. Dans d'autres variantes, la page web est affichée par, ou dans une réalité augmentée et/ou une réalité virtuelle. Dans un mode de réalisation, le dispositif client est configure pour échanger des données d'un ou de plusieurs serveurs hébergés dans le Cloud, lesdits serveurs hébergeant un catalogue expansible de convertisseurs de protocoles bas niveau pour décoder/coder des données communiquées par le dispositif client. [0071] Dans un mode de réalisation, le boîtier (100), p. ex. un gestionnaire de client cloud (120) ou une entité (110) ou autre peut comprendre un catalogue expansible de convertisseurs de protocoles » pour crypter/ou décrypter des messages. [0072] Un ensemble fini de protocoles bas niveau peut être utilisé pour encapsuler des données de dispositifs (comme une «enveloppe»), permettant l'extraction et le transfert du message fonctionnel lui-même (la charge utile) vers le cloud pour conversion. Des exemples d'extraction de charges utiles sont fournis ci-après. [0073] [fig.2] montre un exemple d'un mode de réalisation d'un système conformément à l'invention (avec une perspective côté serveur); [0074] Le gestionnaire de serveur cloud (220) peut interagir avec une pluralité de «jumeaux » (210). Un «jumeau» p. ex. (201) est la représentation d'un boîtier dans le Cloud, comprenant des informations sur les propriétés physiques /ou logiques (état, conditions, activité, etc.). Il peut représenter une copie logique virtuelle d'un boîtier (100). Il englobe des informations technologiques (IT) de paramètres associés au boîtier (p. ex. l'état des services, les composants et les états associés, la température, les conditions environnementales, etc.). La représentation du «jumeau » est accessible et peut être manipulée même lorsque le boîtier correspondant est hors ligne. De façon 12 avantageuse, cela permet de simuler ou autrement d'anticiper des changements apportés au boîtier. Une collection de jumeaux correspondants à une pluralité de boîtiers peut ainsi être gérée à distance. [0075] Par rapport à la sécurité informatique, la plupart des dispositifs hérités utilisent des connexions non cryptécs/non authentifiées avec la passerelle (RS232, TCP-IP), conformément à leurs protocoles d'origine. Plusieurs de ces systèmes hérités sont obsolètes certains vendeurs n'existent même plus, mais des hôtels peuvent les conserver pendant des années. Par conséquent le réseau local est jugé non sécurisé. [0076] Dans certains modes de réalisation de le trafic sortant p. ex. du boîtier (100) est crypte (201). Le chiffrement peut par ailleurs être sophistiqué (p. ex. brouillage préalable, code durci, stéganographic dans des trames vidéo, etc.). Bien qu'un piratage local reste en théorie possible, le piratage à distance (c.-à-d.après que les données quittent l'hôtel) est entravé, ou plus ou moins ralenti. [0077] Dans un mode de réalisation, par exemple au commencement, le boîtier récupère une configuration (par exemple via le fichier de configuration) et établit un canal sécurisé qui peut être utilisé pour des communications bidirectionnelles. [0078] Côté serveur, une pluralité de boîtiers correspondants ou « jumeaux » 210 est maintenue ou hébergée. Un jumeau (200, 201...) est la représentation d'une passerelle (dans un hôtel) cloud, comprenant des informations (p. ex. des biens rapportés) concernant son état et son activité, avantageusement (même) occessiblelorsque le boîtier est hors-ligne. [0079] L'utilisation d'APIs (interfaces de programmation d'application) permet le dé- cuplement des services de l'architecture. Par exemple, l'existence d'APIs 230 permet au système décrit et au procédé d'être interopérables avec virtuellement tout type de PMS (240). Les APIs (250) exposent des procédés (210) pour gérer la pluralité de jumeaux, c.-à-d. des représentations virtuelles et toujours activées de la base installée de passerelles. Ceci peut permettre une gestion par un tiers, en partie ou entièrement. Les abstractions d'APIs permettent une intégration transparente, de meilleurs points de contrôle et des mises à jour indépendantes. [0080] Via ces APIs (230), un PMS donné peut être opéré par une logique (220), c.-à-d. un code logiciel qui comprend ou règle un orchestrateur (222) en association à un gestionnaire de protocoles bas niveaux (223). Une logique d'administration (210) identifie les règles et gère la pluralité des jumeaux. [0081] [fig.3] montre des exemples des étapes sur un mode de réalisation du procédé conformément à l'invention. [0082] Dans un mode de réalisation, le procédé conformément à l'invention comprend une étape d'enregistrement (300) d'un ou de plusieurs dispositifs locaux (p. ex. une carte-clé, un POS, un système de téléphonie). Un dispositif local est modelé en utilisant un 13 ensemble de capacités génériques c.-à-d. des opérations (gestion de carie-clé, facturation de frais sur le compte d'un client, récupération de l'info du client, etc.). La prise en charge d'un nouveau dispositif signifie la création d'un nouveau convertisseur en sélectionnant les capacités génériques qu'il offre et en écrivant seulement un code spécifique pour les commandes génériques avec des séquences de protocole spécifique et en configurant les protocoles bas niveau qui sont pris en charge par le dispositif pour encapsulcr (avec des réglages par défaut). [0083] Dans un mode de réalisation, le procédé comprend une étape d'enregistrement (310) d'un nouveau boîtier cloud. Par exemple, en utilisant un portail d'administration de boîtiers, un boîtier donné est affecté à un hôtel et des dispositifs locaux avec lesquels il faut travailler (sélectionnés dans un catalogue existant) sont [nappés sur un boîtier sériel ou sur des ports TCP-IP. Par exemple la carte-clé numéro 17 sur le Port 1 RS232, le POS numéro 59 sur le Port 6 TCP-IP, etc. [0084] Dans un mode de réalisation, le procédé comprend une étape d' initial isation (320) du nouveau boîtier enregistré. Le boîtier se connecte par exemple à un point d'extrémité de configuration, s'identifie pour récupérer son fichier de configuration qui a été construit au cours de l'étape précédente. Par exemple l'étape d'utilisation d'un protocole bas niveau ETX-STX sur le Port 1, et CRLF sur le Port 6. [0085] Divers modèles de sécurité sont envisagés. Dans un mode de réalisation, aucun au- thentifiant n'est requis (aucune adresse de point d'extrémité de pôle IoT) seul le point d'extrémité de configuration est nécessaire. Une fois connecté, le boîtier s'identifie en utilisant à la fois des clés publiques (adresse MAC) et privées (liées au matériel). Un fichier de configuration de boîtier crypté récupéré du Cloud comprend l'adresse de pôle IoT à utiliser (DEV, QA et PRD) et les authentifiants de connexion. Au cours du processus d'enregistrement initial (c.-à-d. lors de la configuration et de l'attribution d'un boîtier enregistré à un hôtel enregistré) le mot de passe du système d'exploitation sous-jacent peut être personnalisé. [0086] Dans un mode de réalisation, en mode de fonctionnement, lors de la réception de données via un port spécifique, le boîtier utilisera le protocole bas niveau configuré pour extraire (330) la charge utile de message à partir de données brutes. Dans un mode de réalisation, un en-tête peut être ajouté à la charge utile extraite permettant par exemple plus tard au moteur de conversion cloud de sélectionner le convertisseur adapté (ID de boitier, numéro de port). Par la suite, le message peut être envoyé au cloud pour conversion et action (p. ex. avec un cryptage TLS 1.2). [0087] Dans un mode de réalisation, les charges utiles extraites peuvent être encapsulées ainsi que les métadonnées supplémentaires (p. ex. ID de boîtier, ID de port, horodatage, etc.). [0088] Dans un mode de réalisation, un ou plusieurs boîtiers peuvent être gérés à distance 14 (340). Par exemple, un portail d'administration peut permettre l'administration à distance d'un ou de plusieurs boîtiers (p. ex. par activation, configuration et désactivation) et la surveillance (p. ex. des exceptions, un état). [0089] Dans un mode de réalisation, la passerelle cloud peut permettre une interface de messagerie (350), par exemple en temps réel, pour montrer des messages de communication de messages entre un boîtier donné et le cloud. L'interface de messagerie peut prendre la forme d'une interface de conversation, affichant les diverses étapes de communication. Ceci améliore de façon avantageuse le débogage. [0090] D'autres modes de réalisation sont décrits ci-après. Au départ, un boîtier se connecte au point d'extrémité de configuration (la seule URL connue). S'il n'est pas enregistré (p. ex. une première connexion), le boîtier envisagé envoie une demande d'enregistrement et attend qu'un opérateur a) passe en revue la liste de boîtiers en attente d'enregistrement, h) approuve ou rejette la demande du boîtier, et c) crée une configuration (hôtel affecté, dispositifs de système, ports, protocoles). S'il est déjà enregistré, le boîtier obtient une configuration cryptée contenant le point d'extrémité de pôle IoT et les clés de connexions (générées au cours de l'enregistrement à partir des identifiants de boîtier), génère un jeton de connexion valide pendant une durée limitée (p. ex. 24 h), se connecte au pôle IoT du Cloud (p. ex. Azure). [0091] Concernant le Cloud (pôle IoT), le point d'extrémité de configuration (en https) gère l'authentification en utilisant l'ID de boîtier, une version de micrologiciel, le hachage d'une clé privée HW. Une configuration cryptée AES renvoyée contient des informations de dispositifs de système et de protocoles, mais aussi le point d'extrémité de pôle IoT pour se connecter (Test, Prod...) ainsi que les authentifiants associés. Dans un mode de réalisation, aucun authentifiants/point d'extrémité de pôle IoT ne sont stockés dans le boîtier. [0092] Concernant la platefonne de pôle IoT, dans certains modes de réalisation, des connexions TLS 1.2 (et les versions suivantes) peuvent être utilisées. L'authentification peut utiliser un jeton valide pendant un temps limité. On peut assurer une traçabilité complète de tous les événements de connexions. [0093] Concernant le filtrage des messages devant être traités, au niveau du boîtier, un message arrivant sur un port de boîtier spécifique peut utiliser une séquence de protocole bas niveau valide pour le dispositif de système configuré pour ce port. Dans un mode de réalisation, toute exception peut être enregistrée et ignorée. Dans le Cloud, dans un mode de réalisation, seuls les messages de pôle IoT contenant des messages de dispositifs valides peuvent être acceptés. Dans un mode de réalisation, toute exception peut être enregistrée et ignorée. [0094] Les messages de dispositifs peuvent contenir seulement des messages fonctionnels (c.-à-d. des données codées de protocole de dispositif) liés au dispositif de système spécifique connecté à un port spécifique (selon la configuration du boîtier), restreignant le périmètre ou la surface d'attaque potentielle. Dans un mode de réalisation, toute exception peut être enregistrée et ignorée. [0095] Dans un mode de réalisation, le catalogue des dispositifs de système peut être agrandi. De multiples types de dispositifs peuvent être pris en charge (p. ex. carte-clé, Pay-Tv, POS, PBX, Encrgy, etc.). Les interactions de sous-systèmes (dispositifs de système, boîtier de passerelle, PMS) peuvent être effectuées à travers des points d'intégration bien définis. La séparation des données fonctionnelles (c.-à-d. les données de dispositifs) et la surveillance/flux de gestion, peut permettre la hiérarchisation du trafic. Un couplage souple des systèmes cloud, du matériel de boîtier et du PMS permet des cycles de vie différents : p. ex. la prise en charge de dispositifs de systèmes supplémentaires n'a pas d'impact sur le PMS (par exemple). [0096] Exemples de configuration d'un boitier de passerelle [0097] Pour se connecter, un boîtier peut d'abord être dimensionné et configure via un outil d'administration. Un micrologiciel de boitier de passerelle ne peut contenir que l'adresse de point d'extrémité de configuration (service HTTPS). Lorsque le boîtier envisagé démarre, il se connecte au point d'extrémité de configuration pour récupérer sa configuration en faisant passer des identifiants liés au matériel et à sa version de micrologiciel. S'il est déjà enregistré, le boîtier en question obtient une configuration cryptée contenant des clés de connexions et un point d'extrémité de pôle Ica (générés au cours de l'enregistrement à partir des identifiants de boîtier). Un jeton de connexion valide pour un temps limité (p. ex. 24 h) peut ensuite être généré en utilisant les clés de connexions et la connexion est établie avec le pôle IoT Azure. S'il n'est pas enregistré (e.g. première connexion), le boitier peut envoyer une demande d'enregistrement avec son identifiant et son code de hachage généré à partir d'une clé électronique interne unique. Dans un mode de réalisation, un opérateur humain peut passer en revue la liste des boîtiers en attente d'enregistrement afin de les approuver et de les configurer (p. ex. à quel hôtel le boîtier est-il affecté, à quel type de dispositifs de système est-il connecté, sur quel port et avec quel protocole). [0098] [fig.4] illustre l'étape d'extraction de messages fonctionnels des dispositifs hérités. [0099] L'illustration montre les divers messages initiaux (410) émergeant des dispositifs hérités. Ces messages arrivent dans des formes différentes (formats, syntaxe, avec des préfixes, suffixe, balises spécifiques, etc.). La « charge utile» (substance ou signification fonctionnelle) d'un message donné peut plus tard être identifiée et isolée ou extraite. [0100] [fig.4] illustre l'étape d'extraction d'un message fonctionnel d'un message de dispositif entrant. Les illustrations montrent la même opération (création d'une carte-clé dans un hôtel) représentée dans/par deux dispositifs différents hérités. 16 [0101] Première chainc de caractères : [0102] A \ u001ER101 \ u001ETGUEST \ u001EFEm tna \ u001ENZebar\ u001EUGUEST \ u001E1 7C1» [0103] Deuxième chainc de caractères : [0104] « 0399GIR101 INZebarlD201707200000102017072214001C1 I » [0105] Le boîtier de passerelle peut réencapsuler la charge utile par exemple dans un message 420 avec l'ID de port de connexion du dispositif. Les messages encapsulés peuvent être rassemblés dans le Cloud (430). [0106] Des formats de message différents peuvent impliquer des tailles de message dif- férentes, des champs de données, des authentifications, des techniques de cryptage, de la compression, de la segmentation de message, des accusés de réception, des sommes de contrôle, des balises de début/fin, etc. [0107] La gestion de protocoles bas niveau comprend donc des listes correspondantes de chaînes de caractères, de balises, de caractères spéciaux, des longueurs de message, etc. qui peuvent être utilisées pour normaliser les flux de données entrants qui extrait la substance d'un message reçu quelle que soit la forme du message. [0108] Les procédés divulgués peuvent prendre la forme d'un mode de réalisation en- tièrement matériel (p. ex. FPGÀ), d'un mode de réalisation entièrement logiciel ou d'un mode de réalisation contenant à la fois des éléments matériels et logiciels. Les modes de réalisation logiciels incluent, mais sans s'y limiter, des micrologiciels, des logiciels résidents, du microcode, etc. L'invention peut prendre la forme d'un produit-programme (l'ordinateur accessible à partir d'un support utilisable par ordinateur ou lisible par ordinateur fournissant un code de programme pour usage par, ou en association avec un ordinateur ou un quelconque système d'exécution d'instructions. Un utilisable par ordinateur ou lisible par ordinateur peut être un quelconque appareil qui peut contenir, communiquer, propager, ou transporter le programme pour un usage par, ou en association avec le système d'exécution d'instructions, l'appareil ou le dispositif. Le support peut être un système électronique, magnétique, optique, électromagnétique, infrarouge ou semi-conducteur (ou un appareil ou un dispositif) d'un support de propagation. 17 [Revendication 1] [Revendication 2] REVENDICATIONSUn système pour la gestion de dispositifs hérités locaux, ledit système comprenant : - un ou plusieurs serveurs cloud distants, un serveur cloud distant fournissant une pluralité de services cloud; - une passerelle locale cloud faisant interface avec lesdits dispositifs hérités locaux d'un système de gestion de bien, ladite passerelle locale cloud comprenant : - une enceinte comprenant une pluralité de connecteurs d'interface de types différents, lesdits connecteurs d'interface étant configurés pour connecter physiquement un ou plusieurs dispositifs locaux hérités à un ou plusieurs serveurs cloud distants ; - des ressources de communication configurées pour échanger des données vers et en provenance desdits dispositifs hérités, en utilisant lesdits connecteurs d'interface avec un ou plusieurs serveurs cloud distants des messages à une couche OSI inférieure ou égale au TCP/IP ; - le traitement des ressources configurées pour extraire un ou plusieurs messages fonctionnels à partir des données reçues de chacun desdits connecteurs d'interface, lesdits un ou plusieurs messages fonctionnels étant situés à une couche OSI inférieure ou égale au TCP/IP ; dans lequel la passerelle cloud locale est configurée pour initier un canal de communication sécurisé afin de communiquer un ou plusieurs messages fonctionnels extraits vers un ou plusieurs serveurs cloud distants ; dans lequel un service de protocole de message exécuté dans un service cloud distant est configuré pour recevoir et décrypter ledit un ou plusieurs messages fonctionnels extraits communiqués via le canal de communication sécurisé. Le système de la revendication 1 dans lequel un serveur cloud distant est configuré pour fournir : - un service de gestion de protocole de message pour gérer des communications de données vers et en provenance de ladite pluralité de dispositifs hérités locaux ; - un service orchestrateur pour gérer une pluralité de dispositifs hérités locaux ou des représentations de ceux-ci; dans lequel un dispositif hérité local parmi une pluralité est identifié par un service orchestrateur exécuté dans un serveur distant. 18 [Revendication 3] Le système de la revendication 2, dans lequel le dispositif hérité identifié est configure pour communiquer directement au service or- chestrateur en utilisant des protocoles bas niveau. [Revendication 4] Le système d'une quelconque des revendications précédentes, dans lequel un service de protocole de message exécuté dans un serveur cloud distant est configuré pour cryptcr et communiquer un ou plusieurs messages fonctionnels à la passerelle cloud locale. [Revendication 5] Le système de l'une quelconque des revendications précédentes, dans lequel un ou plusieurs serveurs cloud distants sont configurés pour traiter lesdits un ou plusieurs messages fonctionnels reçus des dispositifs hérités locaux. [Revendication 6] Le système de l'une quelconque des revendications précédentes, dans lequel un ou plusieurs serveurs cloud distants sont gérables via une interface d'administration accessible par Tnternet. [Revendication 7] Le système de l'une quelconque des revendications précédentes, dans lequel une passerelle cloud locale est associée à une passerelle cloud distante correspondante, ou jumelle, hébergée dans un serveur cloud distant. [Revendication 8] Le système de l'une quelconque des revendications précédentes, dans lequel la passerelle cloud locale comprend par ailleurs une mémoire pour antémémoriser des données reçues et/ou préextraites dans le Cloud, dans lequel au moins un protocole bas niveau particulier nécessite une durée maximale pour fournir une réponse par ladite passerelle cloud locale. [Revendication 9] Le système de l'une quelconque des revendications précédentes, dans lequel l'enceinte de la passerelle cloud locale est expansible par l'addition d'un module comprenant un connecteur d'interface d'un type différent. [Revendication 10] Le système de l'une quelconque des revendications précédentes, comprenant par ailleurs un transducteur piézo-électrique, ledit vibreur étant configuré pour vibrer et émettre des codes sonores d'erreur en fonction de séquences correspondantes prédéfinies. [Revendication 11] Le système de l'une quelconque des revendications précédentes, comprenant par ailleurs un serveur web configuré pour servir au moins une page web affichant l'état opérationnel respectif des services demandés ou dans lequel les divers états de services sont affichables sur une page web récupérée du réseau. [Revendication 12] Le système de l'une quelconque des revendications précédentes, dans 19 [Revendication 13] [Revendication 14] [Revendication 15] [Revendication 16] [Revendication 17] [Revendication 18] [Revendication 19] lequel un fichier de configuration à multiples parties est déterminé à partir d'un catalogue expansible de convertisseurs de protocole bas niveau. Le système de la revendication 12, dans lequel une partie du fichier de configuration est communiquée à la passerelle cloud locale, ladite partie comprenant une information de numéro de port utilisé par le dispositif hérité local. Le système de la revendication 12 ou 13, dans lequel une autre partie du fichier de configuration est communiquée à un service de protocole de message exécuté dans un serveur cloud distant. Le système de l'une quelconque des revendications précédentes, comprenant par ailleurs un ou plusieurs actionneurs locaux. Le système de l'une quelconque des revendications précédentes, lesdits connecteurs d'interface comprennent au moins un connecteur sériel RS232. Le système de l'une quelconque des revendications précédentes, dans lequel les dispositifs hérités locaux sont associés un système de gestion de bien, utilisé dans un ou plusieurs d'un hôtel, d'un motel, d'une station balnéaire, d'un hôpital, d'un complexe d'appartements/maisons de ville, d'un restaurant, d'une maison de retraite, d'un bateau de croisière, d'un bus, d'une compagnie aérienne, d'un centre commercial, d'un train de passagers ou d'un casino. Un procédé implémenté par ordinateur dans un dispositif client pour accéder à des services cloud, comprenant les étapes - de connexion d'un ou de plusieurs dispositifs hérités locaux à un ou plusieurs connecteurs d'interface de types différents d'une passerelle cloud locale ; - de réception de données en provenance de ladite pluralité de connecteurs d'interface de types différents ; - d'extraction d'un ou de plusieurs messages fonctionnels à partir des données reçues desdits connecteurs d'interface ; - de communication d'un ou de plusieurs messages fonctionnels à un plusieurs serveurs distants. Le procédé implémenté par ordinateur de la revendication 18 comprenant l'étape d'extraction de messages fonctionnels en utilisant un catalogue expansible de protocoles bas niveau et comprenant l'étape de détermination d'au moins un fichier de configuration associé à un dispositif hérité local. 20 [Revendication 20] [Revendication 21] [Revendication 22] [Revendication 23] [Revendication 24] [Revendication 25] Le procédé implémenté par ordinateur de la revendication 19 comprenant par ailleurs l'étape d'identification d'un dispositif hérité local et la communication d'une partie du fichier de configuration correspondant à une passerelle cloud locale, ladite partie comprenant une information de numéro de port utilisé par un dispositif hérité local. Le procédé implémenté par ordinateur de l'une quelconque des revendications 19 ou 20 comprenant l'étape de communication d'une autre partie du fichier de configuration à un service de protocole de message exécuté dans un serveur cloud distant. Le procédé implémenté par ordinateur de l'une quelconque des revendications 18 à 21, dans lequel les communications sont cryptées. Le procédé implémenté par ordinateur de l'une quelconque des revendications 18 à 22 comprenant les étapes - d'enregistrement (200) d'un ou de plusieurs dispositifs hérités locaux auprès de la passerelle cloud locale, en [nappant les dispositifs hérités locaux sur lesdits ports de passerelle cloud locale ; - d'enregistrement (210) desdits dispositifs hérités locaux auprès d'un ou de plusieurs serveurs cloud et l'initialisation (220) de ladite passerelle. Le procédé implémenté par ordinateur de l'une quelconque des revendications 18 à 23, comprenant par ailleurs les étapes -de réception de données d'un ou de plusieurs serveurs cloud, lesdites données comprenant des instructions exécutables ; - d'exécution desdites instructions exécutables sur un plusieurs dispositifs hérités locaux. Un programme d'ordinateur comprenant des instructions pour exécuter les étapes du procédé selon l'une quelconque des revendications 19 à 24 lorsque ledit programme fonctionne sur un ordinateur ou un système informatique.