FR 3117293 A1 20220610 FR 2012732 A 20201204 L’invention concerne un traitement d’une demande d’activation d’un service opéré par un réseau de communications local géré par une passerelle d’accès à un réseau de communication distant. Ledit procédé est mis en œuvre par la passerelle et comprend : - la réception d’une demande d’activation d’un service en provenance d’un terminal utilisateur connecté à ladite passerelle, ladite demande comprenant au moins un identifiant de l’utilisateur; - l’obtention, à partir d’un identifiant du service, d’au moins un identifiant d’une ressource du réseau local à invoquer pour exécuter le service et - la vérification d’un état d’activation de ladite au moins une ressource et, - lorsque ladite au moins une ressource est dans un état de veille, la transmission d’un message de réveil à ladite au moins une ressource. FIGURE 3 Procédé d’activation d’un service opéré dans un réseau de communication local, procédé de traitement d’une demande de réveil d’un équipement connecté au réseau local et configuré pour mettre en œuvre ledit service, procédé de demande d’activation d’un service, dispositifs, passerelle, équipement, terminal utilisateur, système et programmes d’ordinateur correspondants. Domaine technique de l'invention Le domaine de l’invention est celui d’un réseau de communication local, domestique ou professionnel, auxquels sont connectés des équipements électroniques configurés pour se mettre en veille en cas de non utilisation. En particulier, l’invention concerne le réveil de ces équipements lorsqu’ils sont nécessaires pour l’exécution d’un service demandé par un terminal d’utilisateur. Art antérieur Si l’internet des objets tend à impacter tous les aspects de la vie quotidienne et professionnelle, le citoyen est de plus en plus soucieux de l’avenir de la planète. Ce souci l’amène à diminuer le gaspillage des ressources énergétiques. Dans la maison ou l’entreprise connectée, la baisse de la consommation énergétique passe par l’arrêt ou la mise en veille des équipements non utilisés ou au moins certains de leurs composants, applications ou interfaces. C’est le cas par exemple quand les habitants d’une maison s’absentent pour une période de vacances. Aujourd’hui, on sait arrêter et redémarrer à distance un groupe d‘équipements à l’aide d’une prise électrique commune dotée d’une interface de commande 3G/4G. Néanmoins, il reste difficile d’obtenir par ce biais une gestion et une utilisation flexibles de ces équipements. En tout état de cause, cette gestion ne peut pas être automatisée. Pour permettre à des équipements de rester en veille, mais d’être réveillés à tout moment, que ce soit à la demande d’un utilisateur ou automatiquement, on connaît aussi, sur les réseaux Ethernet, l’envoi d’un paquet de réveil à l’adresse IP de la passerelle qui gère le réseau de communication local, ce paquet mentionnant l’adresse MAC de l’équipement à réveiller. Or, certains services opérés dans un réseau de communication local sont composés d’éléments de service fournis par des équipements distincts. Par exemple, au niveau applicatif, un service de simulation de présence dans une maison peut s’appuyer sur la diffusion par un assistant vocal d’un fichier sonore choisi aléatoirement parmi les fichiers stockés dans un espace de stockage externe, de type NAS. La combinaison de ces éléments de services est gérée par un tel orchestrateur de services. Un problème survient lorsqu’un utilisateur demande à accéder à distance à un service de ce type alors qu’un ou plusieurs équipements qui fournissent des éléments de ce service dans le réseau local sont en veille. En effet, l’orchestrateur de services n’en a pas forcément connaissance. On comprend qu’il est compliqué pour l’utilisateur d’identifier à distance les équipements à réveiller et d’envoyer des paquets de réveil à la passerelle pour chacun d’eux. L’invention vient améliorer la situation. Présentation de l'invention L’invention répond à ce besoin en proposant un procédé de traitement d’une demande d’activation d’un service opéré par au moins un équipement connecté à un réseau de communication local géré par une passerelle d’accès à un réseau de communication distant. Ledit procédé est mis en œuvre par la passerelle et comprend : - la réception d’une demande d’activation d’un service en provenance d’un terminal utilisateur connecté à ladite passerelle, ladite demande comprenant au moins un identifiant de l’utilisateur; - l’obtention, à partir d’un identifiant du service, d’au moins un identifiant d’une ressource du réseau local à invoquer pour exécuter le service et - la vérification d’un état d’activation de ladite au moins une ressource et, - lorsque ladite au moins une ressource est dans un état de veille, la transmission d’un message de réveil à ladite au moins une ressource. L’invention propose une approche tout-à-fait nouvelle et inventive pour résoudre le problème de l’accès à un service proposé par un réseau de communication local dont au moins une partie des ressources ou équipements est dans un état de veille. Elle consiste à orchestrer au niveau de la passerelle la gestion de l’accès distant à ce service par un utilisateur avec celle de l’activation des ressources nécessaires pour exécuter ce service dans le réseau de communication local. Le terminal utilisateur peut être connecté à la passerelle par l’intermédiaire du réseau de communication distant ou du réseau de communication local. Ainsi, il suffit à l’utilisateur d’émettre une requête applicative d’accès au service pour déclencher au niveau de cette passerelle une vérification de ses droits d’accès et une vérification de la disponibilité des ressources du réseau local invoquées lors de l’exécution du service demandé. Si l’une de ces ressources est présumée ou connue comme étant dans un état de veille, la passerelle lui adresse un message de réveil. De la sorte, l’activation à distance d’un service mis en œuvre par le réseau local est facilitée pour l’utilisateur qui n’a pas à connaître les ressources nécessaires à l’exécution du service, ni à les réveiller individuellement. En outre, du fait que l’utilisateur n’a plus à envoyer, en plus de la requête applicative d’accès au service, aucune requête réseau pour réveiller les ressources réseau en question, il n’a plus besoin de connaître des ressources du réseau local qui mettent en œuvre le service. Le risque de fuites d’informations techniques est donc réduit et la sécurité du réseau local de ce fait accrue. Selon un aspect de l’invention, le procédé comprend la vérification d’une autorisation de l’utilisateur d’activer ledit au moins un service dudit réseau à partir de droits d’accès stockés en mémoire en association avec ledit identifiant de l’utilisateur. Un avantage est que le réveil des ressources est déclenché seulement quand l’utilisateur est autorisé à accéder au service demandé. Selon un autre aspect de l’invention, lorsque ladite au moins une ressource est un équipement dudit réseau local, distinct de la passerelle, configuré pour gérer ledit service, le procédé comprend, suite au réveil de l’équipement, la réception d’informations de connexion du terminal utilisateur audit équipement et la transmission desdites informations à destination du terminal utilisateur desdites informations de connexion. Une fois réveillé, l’équipement se connecte à la passerelle et lui transmet les informations nécessaires à la connexion de l’utilisateur. A réception de ces informations de connexion, le terminal utilisateur peut se connecter à l’équipement et accéder au service demandé. Avantageusement, il accède à un portail de services orchestrés par l’équipement lui-même. Selon encore un autre aspect de l’invention, lorsque plusieurs identifiants de ressources sont associés à l’identifiant de service, le procédé comprend en outre l’obtention d’un script de configuration du service définissant une séquence temporelle d’actions à exécuter par lesdites ressources et, suite au réveil desdites ressources et leur connexion à la passerelle, la commande d’exécution des actions auxdites ressources conformément audit script. Un avantage est que la passerelle orchestre de bout en bout la mise en œuvre du service demandé par l’utilisateur. Selon encore un autre aspect de l’invention, le procédé comprend l’émission à destination du terminal utilisateur d’une demande de sélection d’un identifiant de service parmi une pluralité d’identifiants de services fournis par le réseau local et autorisés par les droits d’accès associés à l’identifiant de l’utilisateur. Par exemple, la passerelle comprend un portail de services, c’est-à-dire une interface homme/machine permettant à l’utilisateur de choisir facilement le service auquel il veut accéder. Un avantage est que l’utilisateur n’a pas besoin de fournir l’identifiant du service auquel il souhaite accéder dans sa requête auprès de la passerelle. L’invention concerne également un produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé de traitement selon l’invention, tel que décrit précédemment, lorsqu’il est exécuté par un processeur. L’invention vise également un support d’enregistrement lisible par un ordinateur sur lequel sont enregistrés les programmes d’ordinateur tels que décrits ci-dessus. Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une clé USB ou un disque dur. D'autre part, un tel support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens, de sorte que le programme d’ordinateur qu’il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargés sur un réseau par exemple le réseau Internet. Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé de traitement précité. L’invention concerne aussi un dispositif de traitement d’une demande d’activation d’un service opéré par un réseau de communications local géré par une passerelle d’accès à un réseau de communication distant. Ledit dispositif est configuré pour mettre en œuvre au niveau de la passerelle: - la réception d’une demande d’activation d’un service en provenance d’un terminal utilisateur connecté à ladite passerelle par l’intermédiaire du réseau de communication distant, ladite demande comprenant au moins un identifiant de l’utilisateur; - la vérification d’une autorisation de l’utilisateur d’activer ledit au moins un service dudit réseau à partir de droits d’accès stockés en mémoire en association avec ledit identifiant de l’utilisateur, - l’obtention, à partir d’un identifiant du service, d’au moins un identifiant d’une ressource du réseau local à invoquer pour exécuter le service ; et - la vérification d’un état d’activation de ladite au moins une ressource et, - lorsque ladite au moins une ressource est dans un état inactif, la transmission d’un message de réveil à ladite au moins une ressource. Avantageusement, ledit dispositif est configuré pour mettre en œuvre le procédé de traitement précité, selon ses différents modes de réalisation. Avantageusement, ledit dispositif est intégré dans une passerelle d’accès à un réseau de communication distant, configurée pour gérer un réseau de communication local. La passerelle, le dispositif de traitement et le programme d'ordinateur correspondants précités présentent au moins les mêmes avantages que ceux conférés par le procédé de traitement précité selon les différents modes de réalisation de la présente invention. Corrélativement, l’invention concerne aussi un procédé de traitement d’une demande de réveil en provenance d’une passerelle d’accès à un réseau distant, ladite passerelle étant configurée pour gérer un réseau local. Ledit procédé est mis en œuvre par un équipement connecté audit réseau local et comprend : sur réception d’un message de réveil en provenance de la passerelle, l’activation d’au moins une interface homme/machine de gestion de services opéré par ledit équipement ; sur réception d’un message de réveil en provenance de la passerelle, l’activation (41) d’au moins une interface homme/machine de gestion de services opéré par ledit équipement ; la réception d’une commande en provenance de la passerelle d’au moins une action d’activation d’un service demandé par un terminal utilisateur ; et l’exécution de ladite au moins une action. Selon l’invention, la passerelle orchestre l’exécution du service. Sur instructions de la passerelle, l’équipement se réveille et exécute les actions qu’elle lui commande. Selon un aspect de l’invention, lorsque l’action commandée est d’activer pour l’utilisateur un service mis en œuvre par ledit équipement, l’exécution de ladite au moins une action comprend : - la transmission d’informations de connexion à ladite interface à destination de la passerelle ; sur réception d’une requête de connexion sur ladite interface en provenance d’un terminal utilisateur connecté à ladite passerelle: - la vérification que l’utilisateur est autorisé à accéder audit au moins un service à partir de droits d’accès stockés en mémoire en association avec ledit identifiant de l’utilisateur, - l’obtention, à partir d’un identifiant du service, d’au moins un identifiant d’une ressource du réseau local à invoquer pour exécuter le service, et -la vérification d’un état d’activation de ladite au moins une ressource et, - lorsque ladite au moins une ressource est dans un état inactif, la transmission d’un message de réveil à ladite au moins une ressource. A son tour l’équipement du réseau local, peut, une fois réveillé par la passerelle, orchestrer l’exécution du service demandé par le terminal utilisateur et pour ce faire induire le réveil d’autres ressources du réseau. Il commande ensuite l’exécution du service demandé, en orchestrant les actions des différentes ressources mises en jeu au sein de l’équipement lui-même ou dans le réseau local. Selon ce mode de réalisation de l’invention, l’orchestrateur de l’équipement est donc invoqué en cascade de celui de la passerelle. L’invention concerne également un produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé de traitement d’une demande de réveil selon l’invention, tel que décrit précédemment, lorsqu’il est exécuté par un processeur. L’invention vise également un support d’enregistrement lisible par un ordinateur sur lequel sont enregistrés les programmes d’ordinateur tels que décrits ci-dessus. Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une clé USB ou un disque dur. D'autre part, un tel support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens, de sorte que le programme d’ordinateur qu’il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargés sur un réseau par exemple le réseau Internet. Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé de traitement précité. L’invention concerne aussi un dispositif de traitement d’une demande de réveil en provenance d’une passerelle d’accès à un réseau distant, ladite passerelle étant configurée pour gérer un réseau local. Ledit dispositif est configuré pour mettre en œuvre au niveau d’un équipement connecté audit réseau local : sur réception d’un message de réveil en provenance de la passerelle, l’activation d’au moins une interface homme/machine de gestion de services opéré par ledit équipement ; la réception d’une commande en provenance de la passerelle d’au moins une action à exécuter pour activer un service demandé par un terminal utilisateur ; et l’exécution de ladite au moins une action. Avantageusement, ledit dispositif est configuré pour mettre en œuvre le procédé de traitement précité, selon ses différents modes de réalisation. Avantageusement, ledit dispositif est intégré dans un équipement du réseau de communication local. L’équipement, le dispositif de traitement et le programme d'ordinateur correspondants précités présentent au moins les mêmes avantages que ceux conférés par le procédé de traitement précité selon les différents modes de réalisation de la présente invention. Corrélativement, l’invention concerne également un procédé de demande d’activation d’un service opéré par un réseau de communication local géré par une passerelle d’accès à un réseau de communication distant. Ledit procédé est mis en œuvre par un terminal utilisateur connecté à la passerelle et comprend : - la transmission de la demande d’activation d’un service à la passerelle ; et - la réception d’une confirmation d’exécution du service. Selon un aspect de l’invention, il comprend en outre la réception d’informations de connexion à un équipement connecté au réseau local et configuré pour mettre en œuvre le service, l’émission d’une requête de connexion audit équipement comprenant lesdites informations de connexion et la confirmation d’exécution du service est reçue dudit équipement. Un avantage est que l’utilisateur n’a pas besoin de savoir quel(s) équipement(s) mette(nt) en œuvre le service. C’est la passerelle qui joue le rôle d’intermédiaire et d’orchestrateur du service demandé par l’utilisateur Selon un autre aspect de l’invention, le procédé comprend une sélection d’un service parmi une pluralité de services autorisés pour ledit terminal utilisateur. Un avantage est que l’interface homme/machine installée sur le terminal utilisateur stocke les services mis en œuvre par le réseau local et autorisés pour l’utilisateur et les propose à l’utilisateur. L’accès à ces services est donc facilité pour cet utilisateur. L’invention concerne également un produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé de demande d’activation d’un service selon l’invention, tel que décrit précédemment, lorsqu’il est exécuté par un processeur. L’invention vise également un support d’enregistrement lisible par un ordinateur sur lequel sont enregistrés les programmes d’ordinateur tels que décrits ci-dessus. Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une clé USB ou un disque dur. D'autre part, un tel support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens, de sorte que le programme d’ordinateur qu’il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargés sur un réseau par exemple le réseau Internet. Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé de demande d’activation précité. L’invention concerne aussi un dispositif de demande d’activation d’un service opéré par un réseau de communication local géré par une passerelle d’accès à un réseau de communication distant. Ledit dispositif est configuré pour mettre en œuvre au niveau du terminal utilisateur : - la transmission de la demande d’activation d’un service à la passerelle ; et - la réception d’une confirmation d’exécution du service. Avantageusement, ledit dispositif est configuré pour mettre en œuvre le procédé de demande d’activation précité, selon ses différents modes de réalisation. Avantageusement, ledit dispositif est intégré dans un terminal utilisateur. Le terminal utilisateur, le dispositif de demande d’activation et le programme d'ordinateur correspondants précités présentent au moins les mêmes avantages que ceux conférés par le procédé de demande d’activation d’un service précité selon les différents modes de réalisation de la présente invention. L’invention concerne enfin un système de gestion d’une demande d’activation d’un service fourni par un réseau de communication local reçue en provenance d’un terminal utilisateur connecté à ladite passerelle. Un tel système comprend la passerelle, le terminal utilisateur et l’équipement précités. Brève description des figures D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles : : présente un exemple d’architecture d’un système de gestion d’une demande d’activation d’un service opéré par un réseau de communications local selon l’invention ; et : illustrent de façon schématique des exemples d’architectures d’une passerelle d’accès à un réseau distant et configurée pour gérer un réseau local, intégrant un dispositif d’activation d’un service opéré par ledit réseau local selon un mode de réalisation de l’invention, d’un équipement connecté au réseau local et configuré mettre en œuvre ledit service, intégrant un dispositif de traitement d’une demande de réveil et d’un terminal utilisateur connecté à la passerelle par l’intermédiaire du réseau distant, intégrant un dispositif de demande d’accès audit service selon deux modes de réalisation de l’invention ; : décrit sous forme d’un logigramme les étapes d’un procédé d’activation d’un service opéré par un réseau de communication local, selon un exemple de réalisation de l’invention ; et : décrivent sous forme d’un logigramme les étapes d’un procédé de traitement d’une demande d’activation d’un service mis en œuvre par un équipement connecté au réseau de communication local, selon deux exemples de réalisation de l’invention ; : décrit sous forme d’un logigramme les étapes d’un procédé de demande d’activation d’un service opéré par un réseau de communication local, selon un exemple de réalisation de l’invention ; : décrit sous forme d’un diagramme de flux les échanges entre le terminal utilisateur, la passerelle de gestion du réseau de communication local et l’équipement du réseau local, selon un premier exemple de réalisation de l’invention ; : décrit sous forme d’un diagramme de flux les échanges entre le terminal utilisateur, la passerelle de gestion du réseau de communication local et l’équipement du réseau local, selon un deuxième exemple de réalisation de l’invention ; : décrit un exemple de structure matérielle d’un dispositif d’activation d’un service opéré par un réseau de communication local selon l’invention ; : décrit un exemple de structure matérielle d’un dispositif de réveil d’un équipement du réseau local, configuré pour mettre en œuvre le service selon l’invention ; et : décrit un exemple de structure matérielle d’un dispositif de demande d’accès à un réseau de communication local selon l’invention. Description détaillée de l’invention Le principe général de l’invention repose sur la mise en œuvre dans une passerelle d’accès à un réseau de communication distant et configurée pour gérer un réseau de communication local, d’une gestion combinée de l’accès à un service opéré au sein de ce réseau local et de l’activation des ressources du réseau à invoquer pour exécuter ce service. Sur réception d’une demande d’accès à un service en provenance d’un terminal utilisateur connecté à cette passerelle, l’invention propose de vérifier que ce terminal est autorisé à y accéder, obtenir les identifiants des ressources ou équipements du réseau local à invoquer pour la mise en œuvre de ce service ainsi que leur état d’activation, et, s’ils sont dans un état inactif, de leur transmettre un message de réveil. Cette invention trouve de nombreuses applications aussi bien dans la vie quotidienne que professionnelle, pour tout type de terminal utilisateur, tel qu’un téléphone intelligent, une tablette, un ordinateur portable, etc, qui est connecté à un réseau de télécommunications WAN (« Wide Access Network », en anglais) qui souhaite accéder à distance à des services d’un réseau de communication local LAN (« Local Access Network », en anglais) de son environnement personnel ou professionnel, lorsque ce réseau est dans un état de veille. Elle est particulièrement intéressante lorsque le terminal utilisateur est connecté à la passerelle par l’intermédiaire du réseau distant. Dans la suite de la description, on désigne au sens large par service opéré dans le réseau de communication local, une ou plusieurs fonctions exécutées par un ou plusieurs équipements ou connectés à ce réseau. Il s’agit par exemple de l’accès distant à un album photo stocké dans un serveur de stockage en réseau NAS connecté au réseau domestique d’un utilisateur. Un service peut aussi comprendre un enchaînement complexe de fonctions défini par un programme ou script, et nécessiter une coopération entre différentes ressources ou équipements. Par exemple, un service de simulation de présence fait intervenir plusieurs équipements du réseau local, comme d’obtenir un fichier sonore dans un serveur de stockage en réseau NAS, le transmettre à un assistant vocal et lui commander de le jouer. On présente désormais, en relation avec la , un exemple d’architecture d’un système 10 d’activation d’un service opéré dans un réseau de communication LAN en réponse à une demande d’activation d’un service reçue d’un terminal utilisateur TU connecté à un réseau de communication distant WAN d’un opérateur selon un exemple de réalisation de l’invention. Le réseau de communication LAN est géré par une passerelle GW d’accès au réseau distant WAN fournie par l’opérateur à un utilisateur qui a souscrit un abonnement auprès de cet opérateur. Dans l’exemple considéré, la passerelle est connectée au réseau distant WAN par une liaison ADSL ou fibre. Bien sûr, elle peut aussi se connecter au réseau cellulaire de l’opérateur par une liaison de type 2G à 5G. Dans cet exemple, le réseau LAN est un réseau domestique, auxquels sont connectés plusieurs équipements tels qu’une caméra CAM, un assistant vocal AV, un serveur de stockage en réseau ou NAS (« Network Attached Storage », en anglais), un décodeur TV STB (« Set Top Box », en anglais) ou encore une prise connectée PLG, une lampe connectée LGT et un ordinateur personnel PC. Ces équipements sont connectés à la passerelle GW. Par exemple, le serveur de stockage NAS, la lampe connectée LGT et la prise connectée PLG sont connectés à la passerelle GW par une liaison filaire, par exemple de type Ethernet, USB ou CPL sur câblage électrique, le décodeur STB, la caméra CAM et l’assistant vocal AV sont connectés par une liaison sans fil radio, par exemple Wi-Fi et l’ordinateur personnel PC est connecté via la lampe connectée LTG par une liaison sans fil optique de type LiFi. Bien sûr d’autres types de liaison sans fil peuvent être utilisés comme Bluetooth, Bluetooth Low Energy, z-wave, zigbee, DECT-ULE etc. On considère aussi des terminaux tels que le téléphone intelligent (smartphone », en anglais) TU ou l’ordinateur portable (« labtop », en anglais) LTP d’au moins un utilisateur autorisé à se connecter au réseau local LAN mais qui sont, dans l’exemple de la , absents de la maison et connectés au réseau distant WAN. On suppose par exemple que l’utilisateur s’est absenté de son domicile et a rejoint pour plusieurs jours un lieu de villégiature. On suppose également que l’utilisateur administrateur de la passerelle et du réseau local LAN de la maison, qui peut être ou non l’utilisateur, a placé au moins une partie des équipements de ce réseau en état de veille. Par exemple, il a activé la situation d’usage « Absence prolongée » sur un portail d’administration des services de sa passerelle domestique GW proposé par son opérateur. Par exemple, ce portail est accessible depuis une application mobile installée sur son téléphone TU ou une application web accessible depuis un navigateur web de son ordinateur portable LTP. Le passage explicite dans cette situation d’usage induit par exemple : - l’envoi de commandes de coupure de l’alimentation électrique aux prises électriques connectées qui desservent les équipements considérés comme non indispensables, prédéfinis explicitement ou par défaut, - l’envoi de commandes de mise en veille (paquet Ethernet ad hoc) aux équipements susceptibles d’être réveillés pendant cette période, que ce soit à la demande ou par programmation fixe ou semi-aléatoire (simulation de présence), comme par exemple les STB, les téléviseurs, les lampes connectées, - la sauvegarde sur sa passerelle en mémoire non volatile des identifiants réseau, adresses IP et mac des équipements mis en veille, - l’envoi de commandes d’activation des équipements dédié à la détection de présence et aux alarmes comme une centrale d’alarme (non représentée) et certaines caméras autonomes, - l’arrêt sur la passerelle des interfaces non indispensables et énergivores, comme par exemple, le cas échéant, le Wi-Fi ou la 4G/5G, et maintien d’autres, comme par exemple le BLE et l’Ethernet, - l’arrêt sur la passerelle domestique des applications non indispensables et énergivores, - l’activation sur la passerelle d’un programme gérant un calendrier de simulation de présence avec communication de sa programmation à la centrale d’alarme, afin que son système de détection de lumière ou de bruits suspects ne soit pas perturbé, - l’activation sur la passerelle d’un programme gérant un calendrier de mise en veille et de réveil de certaines interfaces de la passerelle, comme par exemple son interface Wi-Fi (paquet Ethernet ad hoc). Le passage de certains équipements en mode veille ou surveillance (par exemple , la caméra autonome) induit chez ceux-ci : - le maintien en fonction des interfaces Bluetooth Low Energy (BLE) sur les équipements qui en sont dotés, - le maintien en fonction des interfaces Ethernet sur les équipements qui en sont dotés, - la mise en veille ou l’arrêt des interfaces Wi-Fi des équipements dotés par ailleurs d’interface Bluetooth Low Energy (BLE) ou Ethernet, - l’arrêt de certaines de leurs composants et applications embarquées, - la surveillance par ceux-ci de messages de réveil sur leurs interfaces BLE et Ethernet. Dans l’exemple de la , on suppose donc que l’utilisateur du réseau local LAN veut accéder à distance à un service de ce réseau local LAN, depuis son terminal TU connecté au réseau distant WAN, alors que la passerelle GW qui gère ce réseau LAN et au moins une partie des ressources de ce réseau sont dans un état de veille. Par exemple, il souhaite accéder au réseau LAN pour visualiser sur son terminal TU un album photo stocké dans le serveur de stockage NAS ou bien il souhaite activer un service de simulation de présence dans son domicile. Bien sûr, l’invention n’est pas limitée à cet exemple et s’applique également lorsque le terminal utilisateur est connecté à la passerelle via le réseau local LAN. Comme illustré par la , le système 10 selon l’invention comprend la passerelle GW configurée pour gérer le réseau local LAN et pour router les communications des terminaux utilisateurs connectés au réseau LAN vers le réseau distant WAN ou inversement. Le système 10 comprend aussi des équipements ou ressources du réseau local LAN, qui sont par exemple les équipements précédemment évoqués comme le serveur NAS, la caméra CAM, le décodeur STB, l’assistant vocal AV etc. Il comprend enfin le terminal utilisateur TU connecté au réseau distant WAN. La présente un premier exemple d’architecture de la passerelle GW selon un mode de réalisation de l’invention. Selon ce premier exemple, la passerelle GW comprend un dispositif 100 d’activation d’un service fourni par le réseau de communications local qu’elle gère. Ce dispositif est configuré pour recevoir une demande d’accès à au moins un service par un terminal utilisateur connecté à ladite passerelle par l’intermédiaire d’une interface avec le réseau de communication distant, ladite demande comprenant au moins un identifiant de l’utilisateur; vérifier une autorisation de l’utilisateur audit au moins un service dudit réseau à partir de droits d’accès stockés en mémoire en association avec ledit identifiant de l’utilisateur, obtenir, à partir d’un identifiant du service, au moins un identifiant d’un équipement du réseau local associé audit identifiant de service, ledit équipement étant invoqué pour l’exécution du service, vérifier un état d’activation dudit équipement et, lorsque ledit équipement est dans un état inactif, lui transmettre un message de réveil. Alternativement, le dispositif 100 peut être indépendant de la passerelle GW, mais connecté à celle-ci par une liaison quelconque filaire ou non. En particulier, le dispositif de traitement 100 comprend un module de réception REC. RS de la demande d’accès au service en provenance du terminal utilisateur, un module de vérification VER. DA d’une autorisation ou de droits d’accès de l’utilisateur, un module d’obtention OBT. EQ d’au moins un équipement à invoquer pour l’exécution du service et d’un état d’activation de cet équipement et un module de transmission TRNS WOL à l’équipement EQ d’un message de réveil configuré pour lui transmettre un message de réveil lorsqu’il est dans un état inactif. Avantageusement, le dispositif 100 comprend aussi un module de demande de sélection RSEL. S d’un service au terminal utilisateur, un module d’obtention OBT. SCPT d’un script de configuration du service et un module de commande d’exécution EXC. SCPT du service conformément au script obtenu. Avantageusement, des commandes d’exécution de tâches décrites dans le script sont transmises à l’équipement EQ. Comme illustré par la , plusieurs équipements AV, NAS peuvent être réveillés puis invoqués pour l’exécution du service. Par exemple, pour exécuter un service de simulation de présence, le dispositif 100 réveille le NAS pour activer un service de consultation de fichiers sonores ainsi que l’assistant vocal pour lui commander d’aller chercher un fichier sonore sur le NAS puis de le jouer. Une fois les équipements AV, NAS réveillés, l’orchestration par le dispositif 100 se fait au niveau applicatif, par des commandes en ligne, pour obtenir du NAS un accès à ses fichiers avec par exemple un filtrage par nom et par type et demander à l’assistant vocal AB de jouer/diffuser un fichier son. Avantageusement, le dispositif 100 comprend enfin un module TX/RX de réception et de transmission d’informations via une interface avec le réseau distant WAN et une autre interface avec le réseau de communication local LAN. Alternativement il utilise le module de transmission/réception de la passerelle GW dans lequel il est intégré. La mémoire non volatile MEM1 comprend avantageusement une table TDA associant à un identifiant de l’utilisateur des droits d’accès aux services du réseau local LAN, une table TS associant à un identifiant du service les identifiants de ressources à invoquer pour exécuter le service et une table TEA associant à un identifiant de ressource un état d’activation. Alternativement, les tables TS et TEA peuvent être regroupées en une seule. Le dispositif 100 met ainsi en œuvre le procédé d’activation d’un service opéré dans un réseau local selon l’invention qui sera détaillé ci-après en relation avec la . La présente enfin un premier exemple d’architecture d’un terminal utilisateur TU selon un mode de réalisation de l’invention. Selon ce premier, le terminal utilisateur TU comprend un dispositif 300 de demande d’activation d’un service opéré dans le réseau local LAN, configuré pour émettre une demande d’accès à ce service à destination de la passerelle GW, recevoir des informations de connexion à un équipement du réseau local en provenance de la passerelle, ledit équipement étant configuré pour exécuter le service demandé. Alternativement, le dispositif 300 peut être indépendant du terminal utilisateur TU, mais connecté à celui-ci par une liaison quelconque, filaire ou non. En particulier, le dispositif de demande d’accès 300 comprend un module d’émission TRNS RS d’une demande d’activation d’un service à destination de la passerelle GW et un module de réception d’une confirmation d’exécution du service demandé en provenance de la passerelle. Avantageusement, le dispositif 300 comprend aussi un module de sélection SEL. S d’un service parmi une pluralité de services autorisés par la passerelle pour le terminal utilisateur. Avantageusement, le dispositif 300 comprend enfin un module TX/RX de réception et de transmission d’informations via une interface avec le réseau distant WAN et une autre interface avec le réseau de communication local LAN. Alternativement il utilise le module de transmission/réception du terminal utilisateur TU dans lequel il est intégré. Le dispositif 300 met ainsi en œuvre le procédé de demande d’activation à distance d’un service selon l’invention qui sera détaillé ci-après en relation avec la . La présente aussi un deuxième exemple d’architecture de la passerelle GW selon un autre mode de réalisation de l’invention. Selon ce deuxième exemple, le dispositif 100 d’activation d’un service fourni par un réseau de communications local géré par la passerelle d’accès comprend le module de réception REC. RS de la demande d’accès au service en provenance du terminal utilisateur, le module de vérification VER. DA d’une autorisation ou de droits d’accès de l’utilisateur, le module d’obtention OBT. EQ d’au moins un équipement à invoquer pour l’exécution du service et d’un état d’activation de cet équipement et le module de transmission TRNS WOL à l’équipement EQ d’un message de réveil configuré pour lui transmettre un message de réveil lorsqu’il est dans un état inactif. Avantageusement, le dispositif 100 comprend aussi un module de demande de sélection RSEL. S d’un service au terminal utilisateur, un module de transmission TRNS. CMD d’une commande d’au moins une action d’activation du service demandé par le client, et un module de transmission d’informations de connexion à l’équipement TRNS. ICNX à destination du terminal utilisateur. Ainsi, pour accéder au service, le terminal utilisateur TU se connecte directement à l’équipement EQ. La présente aussi un exemple d’architecture de l’équipement EQ mettant en œuvre le service demandé par le terminal utilisateur TU. Selon cet exemple de réalisation de l’invention, l’équipement EQ comprend un dispositif 200 de traitement d’une demande de réveil reçue de la passerelle GW selon l’invention, configuré pour recevoir REC. WOL un message de réveil en provenance de la passerelle, réveiller WAK. IHM au moins une interface homme/machine de gestion des services proposés par l’équipement. Avantageusement, le dispositif 200 comprend un module de réception REC. CMD d’une commande d’au moins une action d’activation du service demandé par le client et un module d’exécution de la au moins une action. Ce module comprend avantageusement un module TRNS. ICNX de transmission d’informations de connexion à la passerelle, un module CNX de traitement d’une demande de connexion à ladite interface reçue du terminal utilisateur. Il comprend aussi un module de vérification VER. DA que l’utilisateur est autorisé à accéder audit au moins un service à partir de droits d’accès stockés en mémoire en association avec ledit identifiant de l’utilisateur, un module d’obtention OBT. RS à partir d’un identifiant du service, d’au moins une ressource du réseau local à invoquer pour exécuter le service, et d’un état d’activation de ladite au moins une ressource et, lorsque ladite au moins une ressource est dans un état inactif et un module de transmission d’un message de réveil à ladite au moins une ressource. Autrement dit, selon ce mode de réalisation de l’invention, l’équipement EQ combine lui aussi les fonctions d’orchestration d’un service et d’activation des ressources impliquées lors de la mise en œuvre de ce service. Alternativement, le dispositif 200 peut être indépendant de l’équipement, mais connecté à celui-ci par une liaison quelconque filaire ou non. Avantageusement, le dispositif 200 comprend enfin un module TX/RX de réception et de transmission d’informations dans le réseau LAN. Alternativement il utilise le module de transmission/réception de l’équipement EQ dans lequel il est intégré. La mémoire non volatile MEM2 comprend avantageusement une table TDA2 associant à un identifiant de l’utilisateur des droits d’accès aux services gérés par l’équipement et une table T@ associant à un identifiant du service des ressources invoquées pour l’exécution de ce service. Elle comprend enfin une table TEA2 associant aux ressources un état d’activation. Le dispositif 200 met ainsi en œuvre le procédé de traitement d’une demande de réveil selon l’invention qui sera détaillé ci-après en relation avec les figures 4A et 4B. La présente enfin un deuxième exemple d’architecture d’un terminal utilisateur TU selon cet autre mode de réalisation de l’invention. Selon ce deuxième exemple, le dispositif 300 est configuré pour émettre une demande d’accès à ce service à destination de la passerelle GW, recevoir des informations de connexion à un équipement du réseau local en provenance de la passerelle, ledit équipement étant configuré pour exécuter le service demandé, se connecter à l’équipement à l’aide des informations reçues et recevoir une confirmation de l’exécution du service en provenance de l’équipement. Alternativement, le dispositif 300 peut être indépendant du terminal utilisateur TU, mais connecté à celui-ci par une liaison quelconque, filaire ou non. En particulier, le dispositif de demande d’accès 300 comprend un module d’émission d’une demande d’activation d’un service à destination de la passerelle GW, un module de réception d’information de connexion à un équipement du réseau local, configuré pour exécuter le service demandé en provenance de la passerelle, un module de connexion audit équipement et un module de réception. d’une confirmation d’exécution du service en provenance dudit équipement. Avantageusement, le dispositif 300 comprend aussi un module de sélection d’un service parmi une pluralité de services autorisés par la passerelle pour le terminal utilisateur. Avantageusement, le dispositif 300 comprend enfin un module de réception et de transmission d’informations via une interface avec le réseau distant WAN et une autre interface avec le réseau de communication local LAN. Alternativement il utilise le module de transmission/réception du terminal utilisateur TU dans lequel il est intégré. Le dispositif 300 met ainsi en œuvre le procédé de demande d’activation à distance d’un service selon l’invention qui sera détaillé ci-après en relation avec la . On présente désormais, en relation avec la , sous une forme de logigramme, un exemple de mise en œuvre d’un procédé de traitement d’une demande d’activation d’un service fourni par un réseau de communications local géré par une passerelle d’accès à un réseau de communication distant selon un mode de réalisation de l’invention. - la vérification d’un état d’activation de ladite au moins une ressource et, - lorsque ladite au moins une ressource est dans un état inactif, la transmission d’un message de réveil à ladite au moins une ressource. Au cours d’une étape 30, la passerelle GW, connectée au réseau distant WAN, reçoit la demande RS d’activation d’un service opéré par le réseau local LAN en provenance du terminal utilisateur TU. Du fait que le terminal utilisateur est connecté au réseau distant WAN, cette demande RS est reçue via une interface de la passerelle avec le réseau distant WAN. La demande RS comprend au moins un identifiant IDU de l’utilisateur du terminal TU. Optionnellement, elle comprend aussi un identifiant du service demandé. On suppose ici que le terminal utilisateur s’est préalablement connecté à la passerelle GW. Par exemple, l’utilisateur est abonné à un service de gestion des accès distants au réseau de communication local géré par sa passerelle domestique, proposé par l’opérateur du réseau distant. Il accède à ce service via une application logicielle installée sur son terminal ou une application web ou encore une page web, dont l’interface homme/machine lui permet de formuler ses demandes d’accès à un réseau local, puis d’activation d’un service fourni par ce réseau. On comprend que la quantité d’informations contenue dans cette demande d’activation d’un service RS dépend notamment d’un niveau d’intelligence de l’interface homme/machine et des informations relatives aux services fournis par le réseau local et aux droits d’accès de l’utilisateur dont elle dispose. A minima, elle dispose de l’adresse IP d’une interface homme/machine de gestion des services, ou portail de services, mis en œuvre par la passerelle GW. Avantageusement, si son interface est plus évoluée, elle peut proposer à l’utilisateur de choisir un service parmi une pluralité de services opérés par le réseau local qu’elle gère. On rappelle que le terme service désigne ici au sens large toute fonctionnalité mise à la disposition d’un utilisateur par une ou plusieurs ressources/équipement d’un réseau de communication local. Il s’agit par exemple de l’interface Wi-Fi de la passerelle ou d’un service de simulation de présence qui fait intervenir plusieurs ressources du réseau local (caméra, serveur de stockage NAS, interface wifi etc). Des exemples de réalisation seront détaillés ci-après en relation avec les figures 6 et 7. En 31, le dispositif 100 obtient des informations DA relatives aux droits d’accès de l’utilisateur, par exemple associées dans une mémoire MEM1 à l’identifiant IDU de l’utilisateur contenu dans sa demande RS et vérifie que l’utilisateur est autorisé à accéder aux services proposés par la passerelle GW. Par exemple, il interroge une base de données TDA1 sur la base de l’identifiant IDU et obtient en retour un ou plusieurs identifiants, aussi appelés étiquettes, de services que l’utilisateur est autorisé à activer. Optionnellement, en 32, si la demande d’accès ne comprend pas d’identifiant de service et si plusieurs identifiants de service autorisés sont associés à l’identifiant de l’utilisateur IDU dans la table TA2, alors, une demande RSEL(S) de sélection d’un service S est transmise au terminal utilisateur, comprenant les identifiants des réseaux locaux autorisés. On suppose que le dispositif 100 reçoit une réponse du terminal utilisateur TU, comprenant l’identifiant d’un service IDS. En 33, le dispositif 100 obtient, à partir d’un identifiant du service, au moins un identifiant d’au moins une ressource du réseau local associé audit identifiant de service, ladite ressource étant invoquée pour l’exécution du service. Par exemple, il consulte une table TS1 stockée en mémoire et associant les identifiants de ces ressources à l’identifiant du service demandé. On entend ici par ressource au sens large aussi bien un composant matériel ou logiciel de la passerelle ou de tout autre équipement utilisateur connecté au réseau local géré par la passerelle. Cette ressource peut donc être interne ou externe à la passerelle. Par exemple, il s’agit d’une interface de communication de la passerelle avec le réseau local, comme par exemple son interface Wi-Fi, ou un équipement à part entière, comme le serveur de stockage en réseau NAS ou l’assistant vocal AC. Par exemple, pour le service de simulation de présence, les ressources associées à l’identifiant de ce service IDS sont le serveur de stockage en réseau NAS et l’assistant vocal AV. En revanche, la lecture d’un fichier sur une clé USB connectée à la passerelle, la lecture d’un fichier log interne ou l’activation d’une interface WAN radio de type 4G ou 5G, les ressources à solliciter sont internes à la passerelle. Avantageusement, le dispositif 100 obtient aussi un état d’activation EA de chacune des ressources impliquées dans la mise en œuvre du service demandé, par exemple à partir d’une table TEA1 associant à l’identifiant de ressource IDRS son état d’activation EA. Par exemple cet état peut prendre la valeur « actif » ou « inactif ». En 34, le dispositif 100 émet un message de réveil à destination de chaque ressource identifiée comme dans un état inactif. Pour une ressource externe à la passerelle GW, par exemple un équipement EQ, connecté en Ethernet ou dont l’interface Wi-Fi est restée active, le dispositif 100 obtient l’adresse IP de cet équipement dans une table de routage qu’elle a maintenu pendant l’état de veille du réseau local, cette adresse IP étant associée à un identifiant réseau comme par exemple l’adresse MAC de l’équipement. Il émet à destination de cette adresse IP un message de réveil de type « Wake on Lan », connu de l’homme de métier. Pour réveiller une ressource interne, la passerelle envoie une requête de type « appel de fonction » via une interface interne de programmation applicative ou API (pour « Application Programming Interface », en anglais). Ce message de réveil est par exemple un message de type réseau qui est initié au niveau applicatif. Il peut comprendre une simple commande ON/OFF. Dans ce cas, une fois réveillé, l’équipement EQ prend l’initiative de se connecter à la passerelle et, selon sa configuration, il peut soit exécuter une séquence d’actions prédéfinies, soit se mettre en situation de recevoir des messages applicatifs de type commandes en ligne de la part de la passerelle GW lui commandant l’exécution d’une séquence d’actions particulière. Le cas échéant, les messages applicatifs en question comprennent les autorisations (« credentials », en anglais) ad-hoc. Elles peuvent comprendre aussi un identifiant de session. Cet identifiant sera noté dans les journaux de connexion (pour « logs », en anglais) et pourra ensuite être exploité pour gérer des accès concurrents et éviter d’éventuelles boucle d’invocation. A ce stade, deux options sont envisagées. Selon une première option, le service S demandé est géré par un équipement EQ du réseau local, distinct de la passerelle, par exemple le serveur de stockage en réseau NAS. Dans ce cas, le dispositif 100, après avoir réveillé l’équipement EQ lui transmet en 351 une commande d’activation du service. En retour, il obtient de lui en 352 des informations de connexion ICNX qu’il transmet en 353 au terminal utilisateur TU. Par exemple, le NAS peut demander la fourniture d’un couple identifiant/mot de passe utilisateur ou administrateur pour exécuter certains services. Selon une deuxième option, le dispositif 100 orchestre lui-même le service S demandé par le client. Une fois qu’il a réveillé toutes les ressources RES à invoquer pour l’exécution de ce service, il obtient en 361 un script définissant un enchaînement des actions à commander pour l’exécution de ce service et il exécute en 362 ce script en commandant à chaque ressource RES l’action ou élément de service à exécuter conformément à l’enchaînement et à la configuration définis dans le script. En 363, il confirme au terminal que le service a bien été activé ou lui transmet un rapport d’exécution. En 37, une fois que l’exécution du service est totalement terminée, il désactive les ressources en leur envoyant le cas échéant un message de désactivation. Ce message peut par exemple prendre la forme d’une commande de déconnexion, qui sera suivie d’une mise en veille de l’équipement sur minuterie, ou encore d’une commande d’arrêt. On présente maintenant, en relation avec la , sous une forme de logigramme, un exemple de mise en œuvre d’un procédé de traitement d’une demande d’activation d’un service par un équipement EQ du réseau de communication local LAN géré par la passerelle GW, selon un mode de réalisation de l’invention. En 40, le dispositif 200 reçoit un message de réveil WOL en provenance de la passerelle GW, sur une interface de communication du réseau de communication local LAN. Par exemple, le message est un paquet de réveil « Wake On Lan » reçu sur l’interface Ethernet de l’équipement EQ qui est restée active malgré l’état de veille de l’équipement EQ. Par exemple, l’équipement EQ est un ordinateur personnel, un serveur, un serveur de stockage NAS. Optionnellement, il vérifie que le réveil de l’équipement EQ est autorisé. Par exemple, le dispositif 200 obtient des informations relatives à des contraintes de réveil stockées en mémoire. Il s’agit par exemple de contraintes horaires qui sont consignées dans une table de type calendrier, qui associe à une période particulière une autorisation ou une interdiction de réveil. Dans ce cas, la période peut être exprimée en heures ou en jour. La vérification consiste dans ce cas à vérifier que le jour/la date/l’heure courant(e) appartient à une période autorisée. Si le réveil de l’équipement EQ est interdit pendant la période courante, le dispositif 200 transmet une réponse négative à la passerelle GW. On suppose maintenant que le réveil de l’équipement EQ est autorisé. Le dispositif 200 commande en 41 l’exécution d’un réveil de cet équipement. A ce stade, on considère deux cas distincts. Selon un premier cas, le service demandé par le terminal utilisateur est d’accéder à l’équipement EQ. L’équipement exécute la requête de réveil en activant une interface homme/machine, ou portail de services. Il se connecte ensuite à la passerelle GW qui lui envoie des informations sur les actions qu’il doit effectuer, à l’aide de messages applicatifs de type commande en ligne. Dans cette exemple, l’action requise est de permettre à l’utilisateur du terminal TU d’accéder aux services proposés par l’équipement. L’équipement EQ reçoit en 42 une commande d’une action d’activation du service demandé par le client. Il transmet en 431 des informations ICNX de connexion à la passerelle GWV. Sur réception d’une requête de connexion à son portail reçue du terminal utilisateur TU, ladite requête comprenant un identifiant de l’utilisateur IDU et les informations de connexion, il connecte l’utilisateur. On peut aussi envisager qu’avant d’autoriser l’utilisateur à utiliser certains de ses services qui nécessitent plus de privilèges, l’équipement EQ mette en œuvre une identification/authentification supplémentaire, par exemple pour un passage d’un accès utilisateur à un accès administrateur. En 432, le dispositif 200 obtient des droits d’accès de l’utilisateur stockés en mémoire en association avec son identifiant et lui demande en 433 de sélectionner un service parmi les services auxquels il est autorisé à accéder. Sur réception d’une réponse du terminal utilisateur comprenant un identifiant de service sélectionné, il obtient en 434 la ou les ressources RES à invoquer pour exécuter ce service, par exemple dans une table TS2 stockée en mémoire ainsi qu’un état d’activation EA de chacune de ces ressources. Cet état d’activation peut être stockée dans la table TS2 ou dans une autre table TEA2, par exemple dédiée à la gestion des états d’activation. Avantageusement, il obtient aussi un script de configuration du service qui définit un enchaînement des actions à exécuter par les ressources impliquées pour rendre le service. On note aussi que ces ressources peuvent être internes à l’équipement ou externes, et dans ce cas, accessibles dans le réseau local. Le dispositif 200 identifie les ressources à activer, c’est-à-dire celle qui sont dans un état « inactif » ou de veille et leur transmet en 435 un message de réveil. Pour les ressources externes, il s’agit par exemple d’un paquet de réveil de type « Wake on LAN » adressé à l’adresse IP de la ressource concernée. Le dispositif 200 a donc maintenu en mémoire les entrées d’une table de routage associant l’adresse IP de cette ressource à son adresse MAC. Pour les ressources internes, il s’agit d’une requête de type appel de fonctions via une interface de programmation API interne. En 436, le dispositif 200 exécute le service conformément au script, en envoyant le cas échéant les commandes d’exécution idoines aux ressources RES impliquées. En 447, une fois le service exécuté, il envoie une confirmation CNF d’activation ou, le cas échéant d’exécution du service au terminal utilisateur TU. En 49, il désactive les ressources RES qui étaient en veille et met à jour leur état d’activation en mémoire. Selon le deuxième cas de figure qui va maintenant être décrit en relation avec la , on suppose que le terminal utilisateur TU a sélectionné au niveau d’un portail de services de la passerelle GW un service géré par celle-ci. L’équipement EQ est donc une ressource ou un élément de service que la passerelle va invoquer lors de l’exécution du service demandé par l’utilisateur. En relation avec la , l’équipement EQ reçoit en 40 un message de réveil et en 41 il exécute la requête de réveil en activant les ressources internes spécifiées dans le message de réveil. Par exemple, le message de réveil comprend des données applicatives de sélection d’un service avec des paramètres implicites ou explicites, ou de façon alternative il est banalisé, mais son exécution diffère en fonction du port (IP) auquel il est adressé. Alternativement, le message de réveil est une simple instruction de type ON/OFF et, une fois réveillé, l’équipement EQ se connecte à la passerelle qui lui envoie des messages applicatifs de type commandes en lignes pour spécifier les ressources internes qu’il doit activer et les éléments de service qu’il doit exécuter. En 42’, sur réception d’une commande d’exécution du service en provenance de la passerelle GW, il exécute l’élément de service dont il a la charge, puis en rend compte à la passerelle GW dans un message de confirmation en 44’. En 45’, le dispositif 200 désactive les ressources internes activées pour l’exécution du service, sur requête de la passerelle ou à l’expiration d’un délai prédéterminé. On présente désormais, en relation avec la figure 5, sous une forme de logigramme, un exemple de mise en œuvre d’un procédé de demande d’activation d’un service opéré par un réseau de communication local par un terminal utilisateur, selon un mode de réalisation de l’invention. Dans cet exemple, le procédé est mis en œuvre par le dispositif 300. Au cours d’une étape 50 le dispositif 300 émet une demande RS d’activation d’un service d’un réseau de communication local, par exemple le réseau local LAN géré par la passerelle GW de la . On suppose ici que le terminal utilisateur s’est préalablement connecté à distance à la passerelle GW. Cette demande RS comprend au moins un identifiant IDU de l’utilisateur du terminal TU. Comme évoqué précédemment, l’utilisateur formule cette demande par l’intermédiaire d’une interface homme/machine de son terminal, par exemple une application mise en œuvre par le terminal ou une application web. Cette application peut disposer d’informations relatives à des services du réseau local LAN auxquels l’utilisateur a déjà accédés ou bien est autorisé à accéder et lui proposer de sélectionner facilement parmi eux le service qui l’intéresse. Dans ce cas, la requête RS précise un identifiant IDS du service demandé. De façon alternative, cette application peut aussi disposer d’une quantité d’informations limitée à l’adresse IP d’une interface homme/machine de gestion des services du réseau local LAN, ou portail de services, mise en œuvre par la passerelle GW. Dans ce cas, la demande RS est une simple demande de connexion à ce portail. Optionnellement, en 51, le dispositif 300 reçoit une demande de sélection d’un service parmi une pluralité de services auxquels la passerelle GW l’autorise à accéder. Il sélectionne l’identifiant du service IDS qui l’intéresse et le renvoie à la passerelle. A ce stade, on distingue deux cas de figure. Selon un premier cas, le service S demandé est l’accès à un équipement EQ, tel que le serveur de stockage en réseau NAS du réseau local LAN décrit en relation avec la . Cet équipement fournit différents services qu’il gère lui-même. Il dispose notamment d’une interface homme/machine ou portail de services pour communiquer directement avec le terminal utilisateur. Dans ce cas, il reçoit en 52 des informations de connexion au portail de services de l’équipement EQ. Elles comprennent notamment l’adresse IP de cet équipement et optionnellement l’adresse d’un port ou un couple identifiant/mot de passe. En 53, il lui envoie une requête RCNX de connexion. Une fois connecté, il sélectionne en 54, sur requête de l’équipement EQ, un service S’ parmi une pluralité de services auxquels est autorisé à accéder. En 55, il reçoit une confirmation d’activation du service demandé. Pour un service qui s’exécute sans interaction de l’utilisateur, comme par exemple un service de simulation de présence, il s’agit d’une confirmation d’exécution. Pour un service qui nécessite une interaction de l’utilisateur, comme la consultation de fichiers multimédia stockés dans un espace mémoire de l’équipement EQ, il s’agit d’une confirmation d’accès. Selon un deuxième cas de figure, le service demandé est géré par la passerelle GW. Une fois que l’utilisateur a sélectionné en 51 le service qu’il souhaite sur le portail de services de la passerelle, la passerelle fait le nécessaire pour activer le service, comme précédemment décrit. Par exemple, si le service sélectionné est un service de simulation de présence, la passerelle active les ressources invoquées par ce service qui étaient en veille, puis commande l’exécution du service. Une fois l’exécution terminée, elle en rend compte au terminal utilisateur TU. Le dispositif 300 reçoit donc en 55 une confirmation d’exécution du service. Si le service demandé nécessite une interaction de l’utilisateur, le dispositif reçoit en 55 un accès au service, qu’il peut donc utiliser. On présente désormais, en relation avec la , sous une forme de diagramme de flux, les échanges de messages entre le terminal utilisateur TU, la passerelle GW de gestion du réseau local LAN et deux équipements EQ1, EQ2 du réseau local, selon un premier exemple de réalisation de l’invention. On suppose ici que le terminal utilisateur TU s’est préalablement connecté à la passerelle GW. Du fait qu’elle était en veille, il a fallu la réveiller. On suppose par exemple que l’utilisateur a préalablement souscrit auprès de son opérateur à un service d’accès à distance au réseau local de la passerelle GW et qu’il y accède via une application web ou une application mobile qu’il a installée sur son terminal. Par exemple, il se connecte à une interface ou portail d’une plateforme distante gérée par l’opérateur et connectée au réseau WAN, à l’aide d’un identifiant et d’un mot de passe fournis par l’opérateur. Cette plateforme se charge de vérifier que l’utilisateur est autorisé à accéder au réseau local de la passerelle, le cas échéant la réveille, puis met en relation la passerelle et le terminal. De façon alternative, le terminal utilisateur est configuré pour réveiller lui-même la passerelle à distance, par exemple en lui transmettant un paquet de réveil de type « Wake on Wan », puis pour se connecter à elle, sans intervention extérieure. Une fois connecté à la passerelle GW, le terminal TU lui envoie en 50 une demande RS d’accès à un service d’un réseau de communication local. La passerelle la reçoit en 30. Elle vérifie en 31, à partir d’un identifiant utilisateur IDU contenue dans la demande RS, qu’il est autorisé au service demandé si la requête le précise et à au moins un service sinon. Le cas échéant, elle lui demande en 32 de sélectionner un service parmi une pluralité de services auxquels il est autorisé. Cette requête RSEL est reçue en 51 par le terminal utilisateur TU qui choisit un service S. A réception de la réponse, la passerelle GW obtient en 33 les ressources du réseau local à invoquer pour mettre en œuvre le service S sélectionné. Ces ressources peuvent être internes à la passerelle ou bien externes. Il peut s’agir notamment des équipements EQ1 et EQ2. Elle obtient pour chacune des ressources associées à l’identifiant IDS du service S sélectionné un état EA d’activation de la ressource. Il s’agit d’un indicateur qui peut prendre au moins deux valeurs représentatives d’un état actif et d’un état inactif. Dans ce premier exemple, le service S demandé est l’accès à des fichiers stockés dans le serveur de stockage en réseau NAS du réseau local LAN. La ressource concernée est donc le serveur NAS actuellement en veille. La passerelle GW lui envoie un message de réveil en 34. Il s’agit par exemple d’un message de type « Wake On Lan » qu’elle adresse à l’adresse IP du serveur NAS. Comme précédemment évoqué, ce message peut être une simple commande ON/OFF ou bien une commande en ligne enrichie de paramètres de configuration. Par exemple, un de ces paramètres est un identifiant de session qui pourra être exploité par la suite par l’équipement NAS et/ou la passerelle GW. Le serveur NAS le reçoit en 40 et on suppose qu’il est configuré en 41, pour activer, en réponse à ce message, au moins son interface d’accueil ou portail de services. Il se connecte à la passerelle, qui lui envoie en 351 une commande d’action d’activation du service demandé par le client. Il la reçoit de la passerelle en 42. Dans cet exemple, l’action à effectuer est de permettre à l’utilisateur de se connecter à l’équipement, en vue d’accéder aux services proposés par ce dernier. L’équipement répond en 431 à la passerelle en lui transmettant des informations de connexion ICNX à ce portail. Elle les reçoit en 352 et les retransmet au terminal utilisateur TU en 353. A réception en 52, le terminal utilisateur envoie en 53 une requête de connexion à l’adresse IP de l’interface portail de service du serveur NAS, cette adresse IP ayant été reçue dans les informations de connexion. Sa requête est reçue en 432 par le serveur NAS qui le connecte. On suppose ici que le portail de services du serveur NAS propose plusieurs services. Il s’agit par exemple d’un accès en lecture/écriture à des photos, vidéos, logs et/ou fichiers divers, d’un service de gestion de serveurs web, d’un service de gestion des utilisateurs autorisés, de l’exploitation de caméras de vidéosurveillance, de la réception TV, etc. En 433, le serveur NAS vérifie à quels services l’utilisateur est autorisé à accéder à partir de droits d’accès stockés en mémoire en association avec l’identifiant IDU de l’utilisateur et lui demande d’en sélectionner un. En 54, le terminal utilisateur sélectionne le service S’. Il s’agit par exemple de consulter des fichiers multimedia stockés dans le NAS. A réception, le serveur NAS obtient en 434 les ressources à invoquer pour l’exécution du service S’, par exemple en consultant une table TRES1 associant à un identifiant IDS’ du service les identifiants des ressources qui lui sont associées. Il obtient aussi leur état d’activation EA. On suppose ici que les ressources à invoquer sont internes au serveur NAS. Il s’agit par exemple de ressources de stockage interne, susceptible d’être accessibles dès une sortie de veille, et de ressources de stockage externes, accessibles sur commande. En 435, il réveille les ressources qui sont dans un état de veille et met à jour leur état d’activation en mémoire (à la valeur « actif »). En 436, il exécute le service. Dans le cas d’un service de consultation de fichiers multimédia, il s’agit de donner au terminal utilisateur l’accès à l’espace mémoire du serveur NAS qui stocke les photos. En 437, le serveur NAS confirme au terminal utilisateur qu’il lui a bien donné l’accès. Par exemple, le NAS renvoie au terminal utilisateur une page web montrant le contenu d’un album photo sous forme de vignettes. Le terminal utilisateur TU reçoit cette confirmation en 55 et se met à utiliser le service S’. Lorsque le serveur NAS détecte que le terminal utilisateur a terminé d’utiliser le service S’ ou à l’expiration d’un délai prédéterminé, il désactive en 438 les ressources et met à jour leur état d’activation en mémoire (à la valeur « inactif »). De même, la passerelle GW, lorsqu’elle détecte que le terminal utilisateur s’est déconnecté du portail du serveur NAS, désactive le serveur NAS en 37 et met à jour son état d’activation en mémoire. On présente désormais, en relation avec la , sous une forme de diagramme de flux, les échanges de messages entre le terminal utilisateur TU, la passerelle GW de gestion du réseau local LAN et deux équipements EQ1, EQ2 du réseau local LAN selon un deuxième exemple de réalisation de l’invention. Dans ce deuxième exemple, on suppose que le terminal utilisateur TU sélectionne un service S qui est géré par la passerelle GW. Par exemple, il a sélectionné en 51 ce service S parmi une pluralité de services autorisés que la passerelle lui a proposé en 32. De façon alternative, il peut aussi avoir spécifié un identifiant IDS de ce service dans sa demande RS d’accès initiale. En particulier, c’est le cas lorsqu’il dispose d’une application sur son terminal qui est suffisamment évoluée pour lui proposer directement les services auxquels il peut accéder dans le réseau local LAN. En 33, la passerelle obtient les ressources à invoquer pour exécuter le service sélectionné et leur état d’activation. On suppose que le service S est un service de simulation de présence et qu’il met en jeu des ressources externes à la passerelle, par exemple l’équipement EQ1 est le serveur NAS et l’équipement EQ2 est l’assistant vocal AV. La passerelle les réveille en 34, par exemple en leur envoyant un message de réveil de type « Wake on Lan ». Sur réception du message de réveil envoyé par la passerelle en 40’1 et 40’2, chaque équipement se réveille en 41’1 et 41’2. On suppose ici que l’équipement réveille la ou les ressources internes nécessaires à l’exécution du service demandé. Ces ressources à réveiller peuvent être ou non spécifiées dans le message de réveil. En effet, la structure d’un paquet de réveil de type « Wake On LAN » comprend un champ de données de quelques octets, prévu pour transmettre un mot de passe. Ce champ pourrait être utilisé pour transporter une information représentative d’un index d’une table associant à cet index une séquence d’actions à réaliser. En 361, la passerelle obtient un script de configuration du service, qui décrit un enchaînement d’actions à déclencher et de ressources à solliciter pour exécuter le service. En 362, elle exécute le script en commandant à l’équipement EQ1/NAS en 362 1 le téléchargement d’un fichier sonore stocké dans un de ses espaces mémoire. Le NAS reçoit la commande en 42’1 l’exécute en 43’1 et transmet le fichier demandé la passerelle en 44‘1, ce qui vaut confirmation de l’exécution de la commande. Une fois qu’elle a obtenu le fichier sonore demandé, la passerelle le transmet en 362 2 à l’assistant vocal AV en lui commandant de le jouer ou de le diffuser. En effet, l’assistant vocal AV peut être instancié sous la forme d’un terminal intégré ou bien dématérialisé sous la forme d’une unité centrale UC, dotée soit d’un applicatif autonome soit d’un client pour une application distante dotée d’interfaces sonores en entrée et en sortie (microphone et hauts parleurs, amplis) et d’interfaces réseaux. Dans ce deuxième cas, l’unité centrale diffuse le fichier vers l’application distance pour qu’elle le joue. L’assistant vocal AV reçoit la commande 42’2 et l’exécute en 43’2. Il confirme la bonne exécution de la commande en 44’ 2 . Une fois que la passerelle a obtenu la confirmation que le service s’est exécuté, elle envoie à son tour en 363 une confirmation au terminal TU qui la reçoit en 55. Ensuite, elle désactive les équipements NAS et AV en 37 1 et 37 2 et met à jour leur état d’activation en mémoire (état « inactif »). On comprend qu’un service de simulation de présence peut nécessiter pour être efficace d’être mis en œuvre plusieurs fois pendant la période d’absence des utilisateurs du réseau local LAN. Dans ce cas, on peut envisager que le service soit activé une fois par l’utilisateur mais que le script associé prévoie plusieurs exécutions, par exemple à différents horaires de la journée ou jours de la semaine. Dans ce cas, la passerelle commande à chaque fois le réveil des ressources à invoquer pour exécuter ces actions, l’exécution des actions puis la désactivation des ressources. De la sorte, le service est exécuté tout en maîtrisant la consommation énergétique du réseau local. On présente maintenant, en relation avec la , un autre exemple de structure matérielle d’un dispositif 100 de traitement d’une demande d’activation d’un service opéré dans un réseau de communication local selon l’invention, comprenant, comme illustré par les premiers exemples des figures 2A et 2B, au moins un module de réception d’une demande d’accès à ce service en provenance d’un terminal utilisateur TU, la demande comprenant au moins un identifiant de l’utilisateur IDU, un module de vérification d’une autorisation de l’utilisateur à accéder au service demandé, un module d’obtention de ressources à invoquer pour exécuter le service et d’un état d’activation de ces ressources, un module de réveil des ressources configurés pour transmettre un message de réveil aux ressources associées au service lorsqu’elles sont dans un état inactif et un message de transmission d’un confirmation d’exécution du service au terminal utilisateur. Avantageusement, le dispositif 100 comprend en outre un module de demande de sélection d’un service au terminal utilisateur. Il peut comprendre aussi un module de transmission d’une commande aux ressources d’au moins une action à exécuter, un module de transmission au terminal utilisateur d’informations de connexion à une ressource configurée pour mettre en œuvre le service. Il peut enfin obtenir et exécuter un script de configuration du service. Le terme « module » peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions. Plus généralement, un tel dispositif 100 comprend une mémoire vive 103 (par exemple une mémoire RAM), une unité de traitement 102 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur Pg, représentatif des modules de réception, vérification, obtention, sélection, exécution et transmission, stocké dans une mémoire morte 101 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 103 avant d'être exécutées par le processeur de l'unité de traitement 102. La mémoire vive 103 peut aussi contenir une table comprenant une entrée associant des droits d’accès à des services du réseau local à l’identifiant de l’utilisateur. Elle peut contenir également une table TRES associant à un identifiant du service les identifiants des ressources à invoquer pour son exécution. Elle peut aussi stocker dans la table TRES ou dans une autre table TEA un état d’activation de chacune de ces ressources. La illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le dispositif 100 afin qu’il effectue les étapes du procédé de traitement d’une demande d’activation d’un service opéré dans un réseau de communication local tel que détaillé ci-dessus, en relation avec les figures 3, 6 et 7 dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel). Dans le cas où le dispositif 100 est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d’instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une carte SD, une clé USB, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur. Les différents modes de réalisation ont été décrits ci-avant en relation avec un dispositif 100 intégré dans une passerelle GW d’accès à un réseau de communications distant WAN et configurée pour gérer le réseau de communication local LAN, mais il peut aussi être indépendant de la passerelle et connecté à elle par une interface du réseau local LAN. On présente aussi, en relation avec la , un autre exemple de structure matérielle d’un dispositif 200 de traitement d’une demande de réveil reçu par un équipement EQ connecté à un réseau de communication local LAN selon l’invention, comprenant, comme illustré par les exemples des figures 2A et 2B, au moins un module de réception d’un message de réveil en provenance de la passerelle, un module de réception d’une commande d’au moins une action à exécuter en provenance de la passerelle GW, un module de réveil de l’équipement EQ, un module d’exécution du service ou d’un élément du service demandé, un module de confirmation de l’exécution à la passerelle. Avantageusement, le dispositif 200 comprend aussi, selon le mode de réalisation de la , un module de connexion du terminal utilisateur, un module de demande de sélection d’un service S’ géré par l’équipement EQ, un module de vérification d’une autorisation de l’utilisateur à accéder au service demandé, un module d’obtention de ressources à invoquer pour mettre en œuvre le service S’ et d’un état d’activation de ces ressources, un module de réveil des ressources dont l’état d’activation est « inactif » et un module de commande d’exécution du service S’ à ces ressources. Le terme « module » peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions. Plus généralement, un tel dispositif 200 comprend une mémoire vive 203 (par exemple une mémoire RAM), une unité de traitement 202 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur Pg2, représentatif des modules de réception, d’activation, de connexion, de vérification, de sélection, d’obtention, de réveil et d’exécution, stocké dans une mémoire morte 201 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 203 avant d'être exécutées par le processeur de l'unité de traitement 202. La mémoire vive 203 peut aussi contenir une table comprenant une entrée associant à l’identifiant de l’utilisateur IDU un droit d’accès aux services gérés par l’équipement. Elle peut contenir aussi une table TS2 associant à un identifiant du service demandé les ressources à invoquer pour exécuter le service. Elle peut stocker enfin un état d’activation de chacune de ces ressources dans la table TS2 ou dans une autre table dédié TEA2. La illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le dispositif 200 afin qu’il effectue les étapes du procédé de traitement d’une demande de réveil tel que détaillé ci-dessus, en relation avec les figures 4A, 4B, 6 et 7 dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel). Dans le cas où le dispositif 200 est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d’instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une carte SD, une clé USB, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur. On présente enfin, en relation avec la , un exemple de structure matérielle d’un dispositif 300 de demande d’activation d’un service opéré dans un réseau de communication local selon l’invention, comprenant au moins un module d’émission d’une demande d’activation d’un service à destination de la passerelle GW et un module de réception d’une confirmation d’activation du service demandé. Avantageusement, le dispositif 300 comprend aussi un module de sélection d’un service parmi une pluralité de services autorisés par la passerelle pour le terminal utilisateur, un module de réception d’informations de connexion à un équipement du réseau local configuré pour gérer le service demandé, un module de connexion audit équipement et un module de sélection d’un service parmi une pluralité de services S’ autorisés par l’équipement. Le terme « module » peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions. Plus généralement, un tel dispositif 300 comprend une mémoire vive 303 (par exemple une mémoire RAM), une unité de traitement 302 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur Pg, représentatif des modules de transmission, sélection, réception et connexion, stocké dans une mémoire morte 301 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 303 avant d'être exécutées par le processeur de l'unité de traitement 302. La mémoire vive 303 peut aussi contenir une table comprenant une entrée associant à l’identifiant de l’utilisateur IDU les identifiants de services qu’il a déjà activés. La illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le dispositif 300 afin qu’il effectue les étapes du procédé de demande d’activation d’un service tel que détaillé ci-dessus, en relation avec les figures 5, 6 et 7 dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel). Dans le cas où le dispositif 300 est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d’instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une carte SD, une clé USB, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur. L’invention qui vient d’être décrite dans ses différents modes de réalisation présente de nombreux avantages. En particulier, elle facilite la tâche d’un utilisateur qui souhaite activer à distance un service opéré dans un réseau de communication local placé dans un état de veille, tout en garantissant la sécurité des équipements de ce réseau. En effet, grâce à l’invention, il suffit à l’utilisateur de demander l’activation du service à la passerelle, sans se préoccuper du fait que certaines ressources du réseau local puissent être en veille ou non. C’est la passerelle qui orchestre de bout en bout le réveil de ces ressources et l’exécution du service demandé. En favorisant un accès distant simple et sécurisé aux services du réseau local, l’invention encourage donc les utilisateurs à mettre en veille leurs équipements lorsqu’ils s’absentent, et donc contribue à une économie des ressources énergétiques. Procédé de traitement d’une demande d’activation d’un service opéré par un réseau de communications local géré par une passerelle d’accès à un réseau de communication distant, caractérisé en ce que ledit procédé est mis en œuvre par la passerelle et comprend : - la réception (30) d’une demande d’activation d’un service en provenance d’un terminal utilisateur connecté à ladite passerelle, ladite demande comprenant au moins un identifiant de l’utilisateur; - l’obtention (33), à partir d’un identifiant du service, d’au moins un identifiant d’une ressource du réseau local à invoquer pour exécuter le service et - la vérification d’un état d’activation de ladite au moins une ressource et, - lorsque ladite au moins une ressource est dans un état de veille, la transmission (34) d’un message de réveil à ladite au moins une ressource. Procédé de traitement d’une demande d’activation d’un service selon la revendication 1, caractérisé en ce qu’ il comprend la vérification (31) d’une autorisation de l’utilisateur d’activer ledit au moins un service dudit réseau à partir de droits d’accès stockés en mémoire en association avec ledit identifiant de l’utilisateur. Procédé de traitement d’une demande d’activation d’un service selon l’une quelconque des revendications 1 et 2, caractérisé en ce que , lorsque ladite au moins une ressource est un équipement dudit réseau local, distinct de la passerelle, configuré pour gérer ledit service, le procédé comprend, suite au réveil de l’équipement, la transmission (351) d’une commande d’exécution d’au moins une action d’activation du service, la réception (352) d’informations de connexion du terminal utilisateur audit équipement et la transmission (353) desdites informations à destination du terminal utilisateur desdites informations de connexion. Procédé de traitement d’une demande d’activation d’un service selon l’une des revendications 1 à 3, caractérisé en ce que , lorsque plusieurs identifiants de ressources sont associés à l’identifiant de service, le procédé comprend en outre l’obtention (361) d’un script de configuration du service définissant une séquence temporelle d’actions à exécuter par lesdites ressources et, suite au réveil desdites ressources et leur connexion à la passerelle, la commande (362) d’exécution des actions auxdites ressources conformément audit script. Procédé de traitement d’une demande d’activation d’un service selon l’une des revendications précédentes, caractérisé en ce qu’il comprend l’émission (32) à destination du terminal utilisateur d’une demande de sélection d’un identifiant de service parmi une pluralité d’identifiants de services fournis par le réseau local et autorisés par les droits d’accès associés à l’identifiant de l’utilisateur. Procédé de traitement d’une demande de réveil en provenance d’une passerelle d’accès à un réseau distant, ladite passerelle étant configurée pour gérer un réseau local, caractérisé en ce que ledit procédé est mis en œuvre par un équipement connecté audit réseau local et comprend : sur réception (40) d’un message de réveil en provenance de la passerelle, l’activation (41) d’au moins une interface homme/machine de gestion de services opéré par ledit équipement ; la réception (42) d’une commande en provenance de la passerelle d’au moins une action à exécuter pour activer un service demandé par un terminal utilisateur ; et l’exécution (43) de ladite au moins une action. Procédé de traitement d’une demande de réveil selon la revendication 6, caractérisé en ce que, lorsque l’action commandée est d’activer pour l’utilisateur un service mis en œuvre par ledit équipement, l’exécution de ladite au moins une action comprend : la transmission (431) d’informations de connexion à ladite interface à destination de la passerelle ; sur réception (432) d’une requête de connexion sur ladite interface en provenance d’un terminal utilisateur connecté à ladite passerelle: - la vérification que l’utilisateur est autorisé à accéder audit au moins un service à partir de droits d’accès stockés en mémoire en association avec ledit identifiant de l’utilisateur, - l’obtention (434) , à partir d’un identifiant du service, d’au moins un identifiant d’une ressource du réseau local à invoquer pour exécuter le service, et - la vérification d’un état d’activation de ladite au moins une ressource et, - lorsque ladite au moins une ressource est dans un état inactif, la transmission (435) d’un message de réveil à ladite au moins une ressource. Procédé de demande d’activation d’un service opéré par un réseau de communication local (LAN) géré par une passerelle (GW) d’accès à un réseau de communication distant (WAN), caractérisé en ce qu’il est mis en œuvre par un terminal utilisateur (TU) connecté à la passerelle et comprend : - la transmission (50) de la demande d’activation d’un service à la passerelle ; et - la réception (55) d’une confirmation d’exécution du service. Procédé de demande d’activation selon la revendication 8, caractérisé en ce qu’il comprend en outre la réception (52) d’information de connexion à un équipement connecté au réseau local et configuré pour mettre en œuvre le service, l’émission (53) d’une requête de connexion audit équipement comprenant lesdites informations de connexion et en ce que la confirmation d’exécution du service est reçue dudit équipement. Procédé de demande d’activation d’un service selon l’une des revendications 8 et 9, caractérisé en ce qu’il comprend une sélection (51) d’un service parmi une pluralité de services autorisés pour ledit terminal utilisateur. Produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé selon l'une quelconque des revendications 1 à 10, lorsqu’il est exécuté par un processeur. Dispositif (100) de traitement d’une demande d’activation d’un service opéré par un réseau de communications local géré par une passerelle d’accès à un réseau de communication distant, caractérisé en ce que ledit dispositif est configuré pour mettre en œuvre au niveau de la passerelle: - la réception d’une demande d’activation d’un service en provenance d’un terminal utilisateur connecté à ladite passerelle par l’intermédiaire du réseau de communication distant, ladite demande comprenant au moins un identifiant de l’utilisateur; - la vérification d’une autorisation de l’utilisateur d’activer ledit au moins un service dudit réseau à partir de droits d’accès stockés en mémoire en association avec ledit identifiant de l’utilisateur, - l’obtention, à partir d’un identifiant du service, d’au moins un identifiant d’une ressource du réseau local à invoquer pour exécuter le service et - la vérification d’un état d’activation de ladite au moins une ressource et, - lorsque ladite au moins une ressource est dans un état inactif, la transmission d’un message de réveil à ladite au moins une ressource. Dispositif (200) de traitement d’une demande de réveil en provenance d’une passerelle d’accès à un réseau distant, ladite passerelle étant configurée pour gérer un réseau local, caractérisé en ce que ledit dispositif est configuré pour mettre en œuvre au niveau d’un équipement connecté audit réseau local : sur réception d’un message de réveil en provenance de la passerelle, l’activation d’au moins une interface homme/machine de gestion de services opéré par ledit équipement ; la réception d’une commande en provenance de la passerelle d’au moins une action à exécuter pour activer un service demandé par un terminal utilisateur ; et l’exécution de ladite au moins une action. Dispositif (300) de demande d’activation d’un service opéré par un réseau de communication local géré par une passerelle d’accès à un réseau de communication distant, caractérisé en ce qu’il est mis en œuvre par un terminal utilisateur connecté à la passerelle et comprend : - la transmission de la demande d’activation d’un service à la passerelle ; et - la réception d’une confirmation d’exécution du service. Passerelle (GW) d’accès à un réseau de communication distant, configurée pour gérer un réseau de communication local, caractérisée en ce qu’elle comprend un dispositif de traitement d’une demande d’activation d’un service opéré par ledit réseau local selon la revendication 12. Equipement (EQ) connecté à un réseau de communication local géré par une passerelle d’accès à un réseau de communication distant, caractérisé en ce qu’ il comprend un dispositif (200) de traitement d’une demande de réveil selon la revendication 13 . Terminal utilisateur (TU) connecté à une passerelle d’accès à un réseau de communication distant, ladite passerelle étant configurée pour gérer un réseau de communication local, caractérisé en ce qu’il comprend un dispositif (300) de demande d’activation d’un service opéré par le réseau de communication local géré par la passerelle selon la revendication 14. Système de gestion (10) d’une demande d’activation d’un service fourni par un réseau de communication local reçue en provenance d’un terminal utilisateur connecté à ladite passerelle, caractérisé en ce qu’i l comprend une passerelle d’accès au réseau distant et configurée pour gérer ledit réseau local selon la revendication 15, un terminal utilisateur selon la revendication 17, ledit terminal étant configuré pour émettre la demande d’activation dudit service et un équipement connecté au réseau local selon la revendication 16.