Brevet FR3157047A1 — publié le 20250620

Procédés de supervision, de gestion d’un service, de gestion d’un accès à une tranche réseau et d’accès à un service, et dispositifs configurés pour mettre en œuvre ces procédés Le procédé de supervision par un contrôleur réseau (2) d’un réseau (NW) comprend : une étape d’estimation d’au moins un indicateur représentatif d’un impact environnemental et/ou énergétique imputé à un service fourni via ledit réseau ; et si ledit au moins un indicateur ne respecte pas un critère de conformité donné, une étape de notification d’un serveur d’application (4) associé au service du non-respect par ledit indicateur dudit critère de conformité. Figure pour l’abrégé : Fig. 1. Procédés de supervision, de gestion d’un service, de gestion d’un accès à une tranche réseau et d’accès à un service, et dispositifs configurés pour mettre en œuvre ces procédés L’invention appartient au domaine général des télécommunications. Elle concerne plus particulièrement un mécanisme de gestion des engagements environnementaux et énergétiques d’un réseau de communication. Les services de communication en général, et ceux accessibles via des infrastructures de réseaux fixes ou mobiles en particulier, présentent une empreinte carbone importante et largement documentée depuis des années, notamment pour les réseaux de communication reposant sur des infrastructures cloud. Avec le réchauffement climatique, la plupart des entreprises et notamment les opérateurs de réseaux et les fournisseurs de service, sont aujourd’hui sensibles aux problématiques de responsabilité sociale d’entreprise (ou RSE), et certaines entreprises se sont d’ores et déjà fixé des objectifs de neutralité carbone et/ou de diminution de leur consommation d’énergie. Cette sensibilité à l’impact du déploiement de services de communication sur l’empreinte carbone et/ou la consommation énergétique s’est récemment accentuée avec l’émergence de nouvelles infrastructures réseau telles que les réseaux mobiles 5G, mais également avec la maturité atteinte par certaines techniques telles que les techniques favorisant l’adoption de services dits « immersifs » comme des techniques de réalités virtuelle ou augmentée. Le déploiement d’infrastructures cloud dans un contexte de transformation des réseaux vers l’intégration de techniques logicielles de virtualisation voire d’automatisation participe également à l’augmentation de l’empreinte carbone et les coûts énergétiques liés à l’évolution globale de l’écosystème des télécommunications et des services de communications numériques. Minimiser voire neutraliser l’empreinte carbone et/ou ses coûts énergétiques est donc devenu un enjeu majeur dans la plupart des secteurs de l’industrie, et plus particulièrement pour les opérateurs de réseaux et les fournisseurs de service. L’invention propose un mécanisme visant à faciliter l’atteinte de cet objectif par les opérateurs de réseaux et les fournisseurs de service. L’invention propose plus particulièrement une approche disruptive prônant une collaboration entre tout ou partie des acteurs impliqués lors de la fourniture d’un service via un réseau, à savoir entre le ou les dispositif(s) de communication accédant au service, l’infrastructure de service et le réseau. Autrement dit, en lieu et place d’actions individuelles mises en œuvre de façon indépendante par chacun de ces acteurs, l’invention introduit une coordination entre réseau, infrastructure de service et dispositifs de communication pour contribuer conjointement à une maîtrise voire à une réduction de l’impact environnemental et/ou énergétique imputé à un service. A cet effet, selon un premier aspect, l’invention propose un procédé de supervision par un contrôleur réseau d’un réseau comprenant : une étape d’estimation d’au moins un indicateur représentatif d’un impact environnemental et/ou énergétique imputé à un service fourni via le réseau ; si ledit au moins un indicateur estimé ne respecte pas un critère de conformité donné, une étape de notification d’un serveur d’application associé au service de ce non-respect dudit critère de conformité par ledit au moins un indicateur. Corrélativement, l’invention vise un contrôleur réseau d’un réseau comprenant : un module d’estimation, configuré pour estimer au moins un indicateur représentatif d’un impact environnemental et/ou énergétique imputé à un service fourni via le réseau ; et un module de notification, activé si ledit au moins un indicateur estimé ne respecte pas un critère de conformité donné, et configuré pour notifier un serveur d’application associé au service du non-respect dudit critère de conformité par ledit au moins un indicateur. L’invention s’applique à tout type d’indicateur dès lors qu’il est en mesure de fournir des informations sur l’impact environnemental et/ou énergétique imputé à un service. Il peut s’agir par exemple d’une empreinte carbone, d’un indicateur de flux telle qu’une mesure d’une contribution à l’effet de serre, d’une consommation d’énergie, d’un coût d’approvisionnement de l’énergie, etc. Selon un deuxième aspect, l’invention propose un procédé de gestion d’un service fourni via au moins un réseau par un serveur d’application associé audit service, ce procédé comprenant : une étape de réception, en provenance d’un contrôleur réseau dudit réseau, d’une notification d’un non-respect d’un critère de conformité donné par au moins un indicateur, estimé par le contrôleur réseau, représentatif d’un impact environnemental et/ou énergétique imputé audit service ; et une étape de déclenchement d’au moins une mesure de gestion dudit impact environnemental et/ou énergétique, ladite mesure de gestion portant sur tout ou partie du trafic relatif audit service. Corrélativement, l’invention concerne un serveur d’application configuré pour gérer un service fourni via au moins un réseau, ledit serveur d’application comprenant : un module de réception, configuré pour recevoir en provenance d’un contrôleur réseau dudit réseau, une notification d’un non-respect d’un critère de conformité donné par au moins un indicateur, estimé par le contrôleur réseau, représentatif d’un impact environnemental et/ou énergétique imputé audit service ; et un module de déclenchement, configuré pour déclencher au moins une mesure de gestion dudit impact environnemental et/ou énergétique, ladite mesure de gestion portant sur tout ou partie du trafic relatif audit service. Selon un troisième aspect, l’invention vise un procédé d’accès, par un dispositif de communication, à un service fourni via un réseau, ce procédé comprenant : une étape d’envoi d’une demande d’accès au service à un serveur d’application associé audit service ; et une étape de réception d’une notification en provenance du serveur d’application informant ledit dispositif de communication d’une application au trafic relatif audit service en provenance ou à destination dudit dispositif de communication d’au moins une mesure de gestion d’un impact environnemental et/ou énergétique imputé au service, suite à une notification, reçue par ledit serveur d’application d’un contrôleur réseau du réseau, d’un non-respect d’un critère de conformité donné par au moins un indicateur représentatif dudit impact environnemental et/ou énergétique estimé par le contrôleur réseau. Corrélativement, l’invention concerne un dispositif de communication comprenant : un module d’envoi, configuré pour envoyer à un serveur d’application associé à un service fourni via un réseau, une demande d’accès audit service ; et un module de réception, configuré pour recevoir une notification en provenance du serveur d’application informant ledit dispositif de communication d’une application au trafic relatif audit service en provenance ou à destination dudit dispositif de communication d’au moins une mesure de gestion d’un impact environnemental et/ou énergétique imputé au service, suite à une notification, reçue par ledit serveur d’application d’un contrôleur réseau du réseau, d’un non-respect d’un critère de conformité donné par au moins un indicateur, estimé par le contrôleur réseau, représentatif dudit impact environnemental et/ou énergétique. Selon un quatrième aspect, l’invention concerne un procédé de gestion, par une entité d’un réseau, d’un accès à une tranche réseau supportée par le réseau, ledit procédé comprenant : une étape de réception, en provenance d’un dispositif de communication, d’une demande d’accès à une tranche réseau donnée supportée par le réseau, ladite tranche réseau étant mutualisée entre plusieurs dispositifs de communication accédant à un service fourni via le réseau, suite à une notification reçue par un serveur d’application associé audit service d’un contrôleur réseau du réseau d’un non-respect d’un critère de conformité donné par au moins un indicateur, estimé par le contrôleur réseau, représentatif d’un impact environnemental et/ou énergétique imputé au service; une étape de vérification, auprès du serveur d’application associé audit service, que ledit dispositif de communication est autorisé à accéder à ladite tranche réseau donnée mutualisée ; et le cas échéant, une étape de déclenchement d’un raccordement dudit dispositif de communication à ladite tranche réseau donnée mutualisée. Corrélativement, l’invention vise une entité d’un réseau, configurée pour gérer un accès à une tranche réseau supportée par le réseau, ladite entité comprenant : un module de réception, configuré pour recevoir en provenance d’un dispositif de communication, une demande d’accès à une tranche réseau donnée supportée par le réseau, cette tranche réseau étant mutualisée entre plusieurs dispositifs de communication accédant à un service fourni via le réseau , suite à une notification, reçue par un serveur d’application associé audit service d’un contrôleur réseau du réseau, d’un non-respect d’un critère de conformité donné par au moins un indicateur, estimé par le contrôleur réseau, représentatif dudit impact environnemental et/ou énergétique imputé au service ; un module de vérification, configuré pour vérifier auprès du serveur d’application associé audit service, que ledit dispositif de communication est autorisé à accéder à ladite tranche réseau donnée mutualisée ; et un module de déclenchement activé le cas échéant et configuré pour déclencher un raccordement dudit dispositif de communication à ladite tranche réseau donnée mutualisée. L’invention vise aussi un système comprenant au moins un contrôleur réseau et une entité d’un réseau, un serveur d’application associé à un service fourni via ce réseau, et au moins un dispositif de communication, conformes à l’invention. Conformément au mécanisme de collaboration proposé par l’invention, un contrôleur réseau d’un réseau via lequel est fourni un service surveille au moins un indicateur représentatif de l’impact environnemental et/ou énergétique imputé(s) au service, par exemple l’empreinte carbone imputée à ce service. Si le ou les indicateurs en question ne respectent pas un critère de conformité donné (par exemple, ils ne sont pas conformes à des valeurs de référence définies pour ce service, typiquement des valeurs attendues, souhaitées ou autorisées pour ce service), un serveur d’application associé au service en est informé pour qu’une ou des actions d’ajustement soi(en)t déclenchée(s). De telles actions d’ajustement constituent des mesures de gestion de l’impact environnemental et/ou énergétique imputé au service ; elles visent, par exemple, à limiter, voire à neutraliser, cet impact environnemental et/ou énergétique imputé au service. La notification du serveur d’application peut résulter par exemple d’une souscription du serveur d’application auprès du contrôleur réseau pour que le serveur d’application soit informé par le contrôleur réseau de divers événements relatifs à l’impact environnement/énergétique du service (par exemple, l’empreinte carbone imputée au service dépasse un seuil donné). La ou les mesures de gestion peuvent être déclenchées par exemple par le serveur d’application ou par le contrôleur réseau lui-même de façon coordonnée avec le serveur d’application. Aucune hypothèse n’est faite quant à la fréquence ou sur la façon dont est réalisée l’estimation du ou des indicateurs. Une telle estimation peut être réalisée ponctuellement, de façon continue ou quasi-continue (par exemple, sur une fenêtre glissante), à une fréquence régulière (par exemple, quotidienne, hebdomadaire, mensuelle), etc. Elle peut s’appuyer sur la mise en place de filtres dans le réseau et/ou sur des remontées faites par des sondes déployées à divers endroits du réseau et qui permettent de collecter des informations sur les diverses communications associées à un ou plusieurs services. Le réseau peut notamment utiliser les protocoles NETCONF ou IPFIX, connus en soi, à cet effet. Ainsi, par exemple, dans un mode particulier de réalisation, l’étape d’estimation du procédé de supervision comprend une réception en provenance d’au moins une sonde déployée dans le réseau d’au moins une information reflétant un impact environnemental et/ou énergétique d’au moins une communication relative audit service établie depuis ou vers un serveur impliqué dans une fourniture dudit service. Par ailleurs, le(s) critère(s) de conformité auxquels sont comparés les indicateurs estimés peuvent prendre différentes formes selon les indicateurs considérés et le but recherché (mesure préventive ou curative suite à une dégradation du service). Par exemple, un tel critère de conformité peut être le franchissement d’un seuil critique (minimum ou maximum selon l’indicateur considéré) à ne pas dépasser ou d’un seuil intermédiaire (par exemple un pourcentage du seuil critique) avant d’atteindre un tel seuil critique afin de déclencher une ou plusieurs actions préventives permettant d’anticiper une dégradation du service. Un autre critère peut être l’évolution de l’indicateur dans le temps. Aucune limitation n’est attachée à la nature des mesures de gestion pouvant être déclenchées en réponse à la non-conformité détectée. Ces mesures de gestion visent par exemple à mettre en place une collaboration entre le réseau, l’infrastructure de service et/ou les dispositifs de communication afin de limiter ou de neutraliser l’impact environnemental et/ou énergétique imputé au service et ainsi s’assurer que le trafic en provenance et/ou à destination des dispositifs de communication puisse être acheminé dans les meilleures conditions de sobriété numérique. On peut également envisager une mesure de gestion conduisant à une agglomération de plusieurs plateformes de service (notamment pour en réduire le nombre) et résultant en une modification du critère de conformité considéré pour le service (par exemple en une augmentation du quota autorisé pour l’empreinte carbone du service, ou un report de ce quota). Ainsi, dans un mode particulier de réalisation, ladite au moins une mesure de gestion peut être choisie parmi au moins : une utilisation d’un encodage des données relatives audit service ayant une contribution à l’impact environnemental et/ou énergétique imputé audit service plus faible qu’un encodage courant ; une restriction d’un accès audit service via ledit réseau ; un ordonnancement (temporel) d’un accès audit service par plusieurs dispositifs de communication ; une utilisation mutualisée d’au moins une ressource donnée du réseau par plusieurs dispositifs de communication lors d’un accès audit service par lesdits dispositifs de communication ; et un marquage d’un trafic relatif audit service pour le stocker dans au moins une file d’attente. Bien entendu, d’autres mesures de gestion peuvent être envisagées en variante. Avantageusement, ces mesures de gestion peuvent être choisies et/ou paramétrées en fonction des valeurs estimées des indicateurs considérés, ce qui permet d’agir de façon dynamique, ciblée et adaptée. Elles peuvent être appliquées à tout ou partie du trafic associé au service. Ainsi, dans un mode particulier de réalisation, le procédé de gestion mis en œuvre par le serveur d’application comprend : une étape de réception d’une demande d’accès au service en provenance d’un dispositif de communication ; si ledit dispositif de communication est concerné par une dite mesure de gestion, une étape d’application de cette mesure de gestion au trafic relatif au service en provenance ou à destination dudit dispositif de communication. L’une des mesures de gestion pouvant être envisagée est un ordonnancement programmable (ou « programmable scheduling » en anglais) permettant d’organiser dans le temps l’accès au service par une pluralité de dispositifs de communication. Ainsi, dans un mode particulier de réalisation, lorsque ladite au moins une mesure de gestion comprend un ordonnancement d’un accès audit service par une pluralité de dispositifs de communication, le procédé de gestion mis en œuvre par le serveur d’application comprend suite à une demande d’accès au service par au moins un dispositif de communication, une étape de sélection pour ledit au moins un dispositif de communication, d’un créneau temporel alloué à ladite pluralité de dispositifs de communication pour l’accès au service. En d’autres termes, le serveur d’application détermine à quel moment chaque dispositif de communication demandant à accéder au service va effectivement accéder au service, et ainsi pouvoir émettre ou recevoir des données relatives à ce service. Plusieurs dispositifs de communication ayant demandé à accéder au service dans un intervalle de temps donné peuvent se voir allouer le même créneau temporel pour accéder au service. Ainsi, un dispositif de communication peut voir son accès au service retardé en fonction de la programmation qui a été faite de l’utilisation d’une ressource pour fournir le service, c’est-à-dire des créneaux temporels qui ont été alloués pour cette fourniture de service. On note qu’on s’intéresse ici à l’organisation de l’accès au service par les utilisateurs des dispositifs de communication (par exemple l’accès à un contenu vidéo diffusé en streaming), et non à proprement parler à l’ordonnancement des paquets de données associés à un utilisateur sur les ressources du réseau. Un tel ordonnancement programmable de l’accès au service a une application privilégiée lorsque les dispositifs de communication se partagent une même ressource pour accéder à un service, c’est-à-dire dans un contexte où au lieu de fournir le service à un dispositif de communication via une ressource dédiée, cette ressource est mutualisée pour fournir le service à plusieurs dispositifs de communication. L’utilisation mutualisée de ressources par plusieurs dispositifs de communication combinée à un ordonnancement programmable contribue non seulement à mieux gérer l’impact environnemental et/ou énergétique du réseau, mais également à améliorer l’usage des ressources du réseau ainsi que l’efficacité de la politique d’acheminement de trafic mise en œuvre dans le réseau. Une telle approche permet de tenir compte des budgets énergétiques et environnementaux par service et par utilisateur. Cette approche prometteuse peut en outre s’appliquer dans différents contextes : communications entre centres de données (ou « data centers » en anglais), gestion dynamique des flux (ou « workflows » en anglais) d’une entreprise, ajustement des ressources permettant l’accès à des services et contenus événementiels avec un niveau de qualité adéquat, etc. Une utilisation mutualisée des ressources peut être aisément mise en place en s’appuyant sur le contrôleur réseau du réseau. Ainsi, dans un mode particulier de réalisation, le procédé de supervision comprend en outre : une étape de réception, en provenance du serveur d’application, d’une notification d’une utilisation mutualisée par plusieurs dispositifs de communication d’au moins une ressource donnée du réseau lors d’un accès audit service par les dispositifs de communication ; et une étape de configuration d’au moins une entité du réseau pour permettre cette utilisation mutualisée. Une telle entité du réseau est par exemple un nœud de périphérie du réseau que l’on vient configurer avec de nouvelles règles de classification pour tenir compte de l’utilisation mutualisée de ressources. Différentes ressources du réseau peuvent être mutualisées dans le contexte de l’invention. Par exemple, dans le contexte d’un service de vidéo en flux (ou « streaming video » en anglais), on peut envisager d’utiliser une arborescence multicast déployée dans le réseau (voire dans une tranche supportée par le réseau) pour envoyer un même contenu vidéo à plusieurs dispositifs de communication via le réseau. Selon un autre exemple, on peut envisager que plusieurs dispositifs de communication utilisent une même tranche réseau supportée par le réseau pour accéder au service, typiquement une tranche réseau dédiée à une telle utilisation mutualisée. Ainsi, dans un mode particulier de réalisation, ladite au moins une ressource mutualisée comprend une tranche réseau donnée supportée par le réseau et ladite notification reçue du serveur d’application comprend une information représentative d’un ordonnancement d’un accès au service par des dispositifs de communication via ladite tranche réseau. Ce mode de réalisation propose donc, pour limiter l’impact environnemental et/ou énergétique du service, d’utiliser de façon partagée par une pluralité de dispositifs de communication une (ou plusieurs) tranche(s) réseau supportée(s) par le réseau pour l’accès au service, l’accès à la tranche réseau en question étant organisé selon un ordonnancement particulier dûment choisi par le serveur d’application. L’invention a ainsi une application privilégiée mais non limitative dans le contexte des réseaux supportant des tranches réseau (ou « network slices » en anglais), tels qu’un réseau 5G. De façon connue en soi, une tranche réseau peut être définie comme un réseau privé virtuel (RPV ou VPN pour « Virtual Private Network » en anglais) déployé sur une infrastructure réseau fixe ou mobile ou les deux, et visant à assurer un ensemble de performances spécifiques. Elle peut être vue comme un réseau logique offrant une connectivité à ses utilisateurs et ayant ses propres caractéristiques en termes de capacité (bande passante), de qualité de service (latence, débit, temps de transit unidirectionnel, gigue (ou variation du délai inter-paquets, « inter-packet delay variation » en anglais, etc.) et de sécurité (par exemple, préservation de la confidentialité des informations transmises au sein d’un réseau privé virtuel moyennant l’utilisation de techniques de chiffrement). Ce mode de réalisation peut être aisément mis en œuvre via une collaboration avec le contrôleur réseau et/ou les dispositifs de communication. Ainsi, dans un mode particulier de réalisation, le procédé de gestion mis en œuvre par le serveur d’application peut comprendre au moins une étape parmi : une étape de notification dudit contrôleur réseau de l’utilisation mutualisée de ladite tranche réseau donnée par lesdits dispositifs de communication selon ledit ordonnancement déterminé ; et une étape de notification desdits dispositifs de communication de ladite tranche réseau donnée à utiliser de façon mutualisée par lesdits dispositifs de communication lors d’un accès au service et dudit ordonnancement déterminé qui doit être appliqué. Corrélativement, pour un dispositif de communication, dans un mode de réalisation dans lequel ladite au moins une mesure de gestion comprend une utilisation mutualisée selon un ordonnancement déterminé, lors d’un accès audit service, d’une tranche réseau donnée supportée par ledit réseau par plusieurs dispositifs de communication dont ledit dispositif de communication en question, le procédé peut comprendre : une étape d’envoi à une entité du réseau, d’une demande d’accès à ladite tranche réseau donnée mutualisée ; et suite au raccordement dudit dispositif de communication à ladite tranche réseau donnée mutualisée, une étape d’accès audit service via ladite tranche réseau donnée mutualisée. En outre, préalablement à l’utilisation d’une tranche réseau mutualisée par un dispositif de communication, un contrôle peut être mis en place auprès du serveur d’application par l’entité du réseau chargée de gérer l’accès à cette tranche réseau. Ainsi, dans un mode particulier de réalisation, le procédé de gestion mis en œuvre par le serveur d’application peut comprendre une étape de réception en provenance d’une entité du réseau d’une demande de vérification qu’un dispositif de communication est autorisé à accéder à ladite tranche réseau donnée. Dans un mode de réalisation particulier de l’invention, si après avoir notifié le serveur d’application, le contrôleur réseau détecte qu’aucune mesure de gestion de l’impact environnemental et/ou énergétique imputé au service n’a été mise en œuvre par le serveur d’application, il peut déclencher lui-même de telles mesures de gestion. Par exemple, dans un mode de réalisation, le procédé de supervision comprend en l’absence à l’issue d’une période déterminée d’un déclenchement d’au moins une mesure de gestion de l’impact environnemental et/ou énergétique par le serveur d’application suite à sa notification, une étape d’activation dans ledit réseau, pour tout ou partie du trafic relatif audit service, d’au moins un traitement en réponse au non-respect du critère de conformité par l’indicateur représentatif de l’impact environnemental et/ou énergétique imputé audit service. Un tel traitement peut comprendre par exemple un basculement de tout ou partie du trafic relatif audit service transitant via le réseau vers une tranche réseau fournissant un niveau de service dégradé par rapport à un niveau de service attendu pour ledit service, par exemple un niveau de qualité adapté au mieux aux conditions d’accès au service, aussi appelé « Best effort » en anglais. Dans un mode particulier de réalisation, les procédés de supervision, de gestion et d’accès sont mis en œuvre par un ordinateur. L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans un contrôleur réseau d’un réseau conforme à l’invention et comportant des instructions adaptées à la mise en œuvre d’un procédé de supervision tel que décrit ci-dessus. L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans un serveur d’application conforme à l’invention et comportant des instructions adaptées à la mise en œuvre d’un procédé de gestion d’un service tel que décrit ci-dessus. L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans une entité d’un réseau conforme à l’invention et comportant des instructions adaptées à la mise en œuvre d’un procédé de gestion d’un accès à une tranche réseau tel que décrit ci-dessus. L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans un dispositif de communication conforme à l’invention et comportant des instructions adaptées à la mise en œuvre d’un procédé d’accès à un service tel que décrit ci-dessus. Chacun de ces programmes peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. L’invention vise aussi un support d'information ou un support d’enregistrement lisibles par un ordinateur, et comportant des instructions d’un programme d'ordinateur tel que mentionné ci-dessus. Le support d'information ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. 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 un disque dur, ou une mémoire flash. D'autre part, le support d'information ou 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 lien radio, par lien optique sans fil ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'information ou d’enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés de gestion d’un accès, de gestion d’un service, d’un accès et de supervision selon l’invention. On peut également envisager, dans d'autres modes de réalisation, que les procédés de supervision, de gestion d’un service, de gestion d’un accès à une tranche réseau et d’accès à un service, le contrôleur réseau, le serveur d’application, l’entité du réseau et le dispositif de communication et le système selon l’invention présentent en combinaison tout ou partie des caractéristiques précitées. Brève description des figures D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux figures annexées qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : FIG. 1 la FIG. 1 représente, dans son environnement, un système conforme à l’invention, dans un mode particulier de réalisation ; FIG. 2 la FIG. 2 représente schématiquement l’architecture matérielle d’un ordinateur pouvant héberger un contrôleur réseau, un serveur d’application, une entité de gestion ou un dispositif de communication selon l’invention appartenant au système de la FIG. 1 ; FIG. 3 la FIG. 3 représente sous forme d’ordinogramme, les principales étapes d’un procédé de supervision selon l’invention tel qu’il est mis en œuvre par le contrôleur réseau du système de la FIG. 1 , dans un mode particulier de réalisation ; FIG. 4 la FIG. 4 représente sous forme d’ordinogramme, les principales étapes d’un procédé de gestion de l’accès à un service selon l’invention tel qu’il est mis en œuvre par le serveur d’application du système de la FIG. 1 , dans un mode particulier de réalisation ; FIG. 5 la FIG. 5 représente sous forme d’ordinogramme, les principales étapes d’un procédé de gestion de tranches réseau selon l’invention tel qu’il est mis en œuvre par l’entité de gestion du système de la FIG. 1 , dans un mode particulier de réalisation ; FIG. 6 la FIG. 6 représente sous forme d’ordinogramme, les principales étapes d’un procédé d’accès à un service selon l’invention tel qu’il est mis en œuvre par un dispositif de communication du système de la FIG. 1 dans un mode particulier de réalisation ; et FIG. 7 la FIG. 7 représente un exemple de format d’une option COSINUS_OP pouvant être utilisée dans le cadre de l’invention. Description de l’invention La FIG. 1 représente, dans son environnement, un système 1 conforme à l’invention, dans un mode particulier de réalisation, le système 1 étant configuré pour mettre en œuvre un mécanisme collaboratif visant à maîtriser (gérer), et éventuellement réduire (voire neutraliser), l’impact environnemental et/ou énergétique d’un service S fourni via un réseau NW de communication. Dans le mode de réalisation envisagé ici, le réseau NW de communication supporte une pluralité de tranches réseau SL1, SL2,…, SLK, où K désigne un entier supérieur à 1, pouvant être utilisées pour agréger le trafic relatif à un ou plusieurs services (c’est-à-dire émis à destination ou reçu en provenance d’un ou de plusieurs services). Chaque tranche réseau peut impliquer une ou plusieurs fonctions service (ou « Service Functions » en anglais), aussi appelées fonctions réseau (ou « Network Functions » en anglais). De telles fonctions service/réseau sont par exemple des fonctions stations de base ou gNB (pour « gNodeB » en anglais), des fonctions du plan utilisateur ou UPF (pour « User Plane Function » en anglais), des fonctions de marquage, de classification et d’ordonnancement du trafic, etc. Une même fonction service/réseau peut être fournie par une ou plusieurs instances de service (ou « Service Function Instances » en anglais) ou instances de fonctions réseau. Des chaînes de service ou SFC (pour « Service Function Chains » en anglais) peuvent être mises en place afin de faciliter l’acheminement de trafics de différentes natures et présentant des profils différents pour les besoins de la réalisation (c’est-à-dire l’ingénierie et le déploiement) d’une tranche réseau ou au sein d’une tranche réseau. Le réseau NW est par exemple un réseau mobile 5G tel que défini par les standards 3GPP. Il peut être segmenté en plusieurs (sous-)réseaux distincts (on parle également de « segments de réseau ») composant autant de domaines distincts. Par exemple, le réseau NW peut être composé d’un réseau d’accès radio (ou RAN pour « Radio Access Network » en anglais), d’un réseau cœur (ou CN pour « Core Network » en anglais) et d’un réseau de transport (ou TN pour « Transport Network » en anglais) assurant la connectivité au sein et entre le réseau cœur et le réseau d’accès radio. Chacun des domaines supporte des tranches réseau dont l’ingénierie et l’exploitation sont caractéristiques du domaine. Par exemple, une tranche déployée sur un réseau cœur mobile 5G fait appel à des fonctions de traitement de trafic et d’exploitation caractéristiques d’un réseau cœur mobile 5G. Aucune hypothèse n’est faite ici quant à la nature ou le nombre de tranches réseau supportées par le réseau NW. Ces tranches réseau peuvent s’étendre sur un ou plusieurs domaines (et être ainsi constituées de plusieurs tranches réseau « locales » déployées dans les différents domaines ; on parle alors de tranches réseau « multi-domaines » ou « stitched slices » ou encore « hierarchical slices » en anglais). La façon de concevoir et de déployer des tranches réseau pour offrir des services est connue en soi et n’est pas décrite en détail ici. Il convient de noter que ces hypothèses ne sont pas limitatives en soi et l’invention s’applique dans d’autres contextes et notamment à d’autres réseaux (supportant ou non des tranches réseau), tels qu’un réseau reposant sur une architecture SD-WAN (pour « Software-Defined Wide Area Network » en anglais) ou SDN (pour « Software-Defined Network » en anglais) ou encore sur l’utilisation de techniques NFV (pour « Network Functions Virtualization » en anglais) de virtualisation de fonctions réseau, etc. Comme évoqué précédemment, le système 1 est configuré pour maîtriser l’impact environnemental et/ou énergétique d’un service S fourni via le réseau NW. A cet effet, il comprend, dans le mode de réalisation décrit ici, au moins : un contrôleur réseau 2 du réseau NW et une entité de gestion de tranches réseau 3 du réseau NW, conformes à l’invention ; un serveur d’application 4 (ou AS pour « Application Server » en anglais), associé au service S, conforme à l’invention ; et au moins un dispositif de communication 5, conforme à l’invention, connecté au réseau NW et susceptible d’accéder au service S via le réseau NW. L’invention s’applique à tout type de service S (vidéo en streaming, réalité virtuelle ou augmentée, visio-conférence, etc.). Dans l’exemple de la FIG. 1 , le service S est un service de vidéo en streaming fourni par un fournisseur de services distinct de l’opérateur du réseau NW, et le serveur d’application 4 est un serveur distant localisé en dehors du réseau NW. Toutefois cette hypothèse n’est pas limitative en soi, et l’invention s’applique quelle que soit la localisation du service. Il convient par ailleurs de noter que le serveur d’application 4 associé au service S n’est pas nécessairement le serveur qui fournit à proprement parler le service S ; il peut s’agir de n’importe quel serveur d’application ou instance de service appartenant à l’infrastructure de service fournissant le service S. Dans l’exemple envisagé ici, le fournisseur du service S est un fournisseur de services reposant sur des tranches réseau ou SSP (pour « Slice Service Provider » en anglais). On suppose que le dispositif de communication 5 a négocié lors de sa souscription au service S auprès du SSP la ou les tranches réseau qu’il est susceptible d’utiliser pour envoyer ou recevoir du trafic associé au service S via le réseau NW. Le type de chaque tranche réseau a par ailleurs été négocié entre le dispositif de communication 5 et le réseau NW, de façon connue en soi. Dans l’exemple envisagé ici, le dispositif de communication 5 est un équipement utilisateur (ou UE pour « User Equipment » en anglais) tel qu’un téléphone intelligent (plus communément appelé « smartphone »), un ordinateur portable, une tablette numérique, etc. L’invention s’applique toutefois aisément à d’autres dispositifs de communication 5, fixes ou mobiles, logiciels ou matériels, etc., comme par exemple à une instance de service, une passerelle domestique ou CPE (pour « Customer Premises Equipment » en anglais). Dans le mode de réalisation décrit ici, le contrôleur réseau 2, l’entité de gestion 3, le serveur d’application 4 et le dispositif de communication 5 ont chacun l’architecture matérielle d’un ordinateur 6 telle qu’illustrée par la FIG. 2 . Cette architecture matérielle comprend notamment un processeur PROC, une mémoire vive MEM, une mémoire morte ROM, une mémoire non volatile NVM, et des moyens COM de communication. La mémoire non volatile NVM constitue un support d’enregistrement conforme à l’invention, lisible par le processeur PROC et sur lequel est enregistré un programme conforme à l’invention. Ce programme, noté PROG-2 lorsque l’architecture matérielle de l’ordinateur 6 est celle d’un contrôleur réseau conforme à l’invention tel que le contrôleur réseau 2, est enregistré dans la mémoire non volatile NVM et comporte des instructions définissant les principales étapes d’un procédé de supervision selon l’invention. Il définit plus spécifiquement les modules fonctionnels du contrôleur réseau 2 (représentés sur la FIG. 1 ), qui s’appuient et/ou commandent tout ou partie des éléments PROC, MEM, ROM, NVM, et COM de l’ordinateur 6 évoqués précédemment. Ces modules fonctionnels comprennent dans l’exemple du service S : un module 2A d’estimation, configuré pour estimer au moins un indicateur IND représentatif d’un impact environnemental et/ou énergétique imputé au service S fourni via le réseau NW ; et un module 2B de notification, activé si ledit au moins indicateur IND estimé si ledit au moins indicateur estimé ne respecte pas un critère CRIT de conformité donné (on peut envisager des critères différents selon les indicateurs considérés), et configuré pour notifier le serveur d’application 4 associé au service S de ce non-respect. Dans le mode de réalisation décrit ici, le contrôleur réseau 2 comprend également les modules fonctionnels suivants, définis par le programme d’ordinateur PROG-2 : un module 2C de déclenchement, configuré ici pour déclencher lui-même une mesure de gestion de l’impact environnemental et/ou énergétique imputé au service (aussi appelée « action d’ajustement »), et plus précisément une action d’ajustement par défaut ACT-DEF, en l’absence de déclenchement par le serveur d’application 4 d’une telle mesure de gestion suite à la notification reçue du module 2B de notification indiquant le non-respect par l’indicateur IND du critère CRIT. Cette action d’ajustement par défaut ACT-DEF est un traitement déclenché en réponse au non-respect du critère CRIT et qui vise par exemple à réduire ou à neutraliser l’impact environnemental et/ou énergétique imputé au service. Un exemple d’action d’ajustement par défaut ACT-DEF est donné à titre illustratif ultérieurement ; et un module 2D de configuration d’entités du réseau NW pour permettre la mise en œuvre de mesures de gestion (par défaut ou déclenchées par le serveur d’application 4) de l’impact environnemental et/ou énergétique du service S dans le réseau. Les fonctions des modules 2A à 2D du contrôleur réseau 2 sont décrites plus en détail ultérieurement en référence à la FIG. 3 décrivant les principales étapes d’un procédé de supervision selon l’invention. Lorsque l’architecture matérielle de l’ordinateur 6 est celle d’un serveur d’application conforme à l’invention tel que le serveur d’application 4, le programme conforme à l’invention enregistré dans la mémoire non volatile NVM de l’ordinateur 6 est le programme PROG-4 qui comporte des instructions définissant les principales étapes d’un procédé de gestion d’un service selon l’invention. Ce programme PROG-4 définit les modules fonctionnels du serveur d’application 4 (représentés sur la FIG. 1 ), qui s’appuient et/ou commandent tout ou partie des éléments PROC, MEM, ROM, NVM, et COM de l’ordinateur 6 évoqués précédemment. Ces modules fonctionnels comprennent, dans l’exemple du service S : un module 4A de réception, configuré pour recevoir le cas échéant en provenance du contrôleur réseau 2, une notification d’un non-respect du critère CRIT de conformité par ledit au moins un indicateur IND ; et un module 4B de déclenchement, configuré pour déclencher au moins une mesure de gestion ACT de l’impact environnemental et/ou énergétique imputé au service S, cette mesure de gestion ACT portant sur tout ou partie du trafic relatif au service S. Des exemples de mesures de gestion ACT pouvant être déclenchées sont notamment : une utilisation d’un encodage des données relatives au service S ayant une contribution à l’impact environnemental et/ou énergétique imputé au service S plus faible qu’un encodage couramment utilisé par les dispositifs de communication accédant à ce service S et/ou par le serveur d’application fournissant le service S ; une restriction d’un accès au service S via le réseau NW ; un ordonnancement d’un accès au service S par plusieurs dispositifs de communication ; une utilisation mutualisée d’au moins une ressource donnée du réseau NW par plusieurs dispositifs de communication lors d’un accès au service S par ces dispositifs de communication ; un marquage d’un trafic relatif au service pour le stocker dans au moins une file d’attente ; etc. Par « utilisation mutualisée d’une ressource », il est fait référence ici à un mode dans lequel cette ressource n’est pas exclusivement dédiée à la fourniture du service à un dispositif de communication mais elle est utilisée pour fournir ce service simultanément à plusieurs dispositifs de communication qui souhaitent accéder au service dans un intervalle donné. On s’oppose ainsi ici à un mode dans lequel la ressource en question est utilisée, suite à une demande d’accès au service par un dispositif de communication, exclusivement pour l’écoulement du trafic de ce service vers ce dispositif de communication (la ressource est dédiée à ce dispositif de communication), indépendamment des autres dispositifs de communication souhaitant accéder au même service. Par exemple, un mode de transmission multicast illustre une utilisation mutualisée d’une ressource pour transmettre un flux de données, par opposition à un mode de transmission unicast dédié à un utilisateur donné. D’autres mesures de gestion (ou actions d’ajustement) peuvent bien entendu être envisagées en variante, typiquement des mesures de limitation ou de neutralisation de l’impact environnemental et/ou énergétique imputé au service S. Par exemple, une mesure de gestion peut consister à modifier le critère CRIT de conformité considéré (si ce critère est un quota à respecter, on peut par exemple augmenter ce quota ou le reporter). Par ailleurs, le module 4B de déclenchement peut déclencher une combinaison des mesures de gestion précitées, comme décrit plus en détail ultérieurement. Typiquement, dans le mode de réalisation décrit ici, on considère une utilisation mutualisée d’une tranche réseau supportée par le réseau NW combinée à un mécanisme d’ordonnancement (dit programmable) organisant cette utilisation mutualisée entre les dispositifs de communication concernés. Dans le mode de réalisation décrit ici, le serveur d’application 4 comprend également les modules fonctionnels suivants, définis par le programme d’ordinateur PROG-4 : un module 4C de notification, configuré pour notifier (c’est-à-dire informer) le contrôleur réseau 2 et/ou les dispositifs de communication accédant au service de la ou des mesures de gestion déclenchées par son module 4B de déclenchement ; un module 4D de vérification, configuré pour effectuer divers contrôles sur demande d’une entité du réseau NW (par exemple de l’entité de gestion 3) ; et un module 4E de fourniture, configuré pour fournir le service S via le réseau NW aux dispositifs de communication (dont le dispositif de communication 5) connectés à ce réseau NW. Aucune hypothèse n’est faite quant à la façon dont sont organisés les modules 4A à 4E qui viennent d’être décrits. Ces modules peuvent être intégrés dans des instances de service distinctes ou dans une unique instance de service. Ainsi, par exemple, dans le mode de réalisation décrit ici, on suppose que le serveur d’application 4 expose un serveur PCP (pour « Port Control Protocol ») pour interagir avec les dispositifs de communication (dont le dispositif de communication 5) souhaitant accéder au service S, avec le contrôleur réseau 2 et avec les entités du réseau NW et notamment l’entité de gestion 3. De façon connue en soi, le protocole PCP, qui est décrit notamment dans le document RFC 6887 de D. Wing et al, édité par l’IETF et intitulé « Port Control Protocol (PCP) », avril 2013, est particulièrement avantageux car il contribue à économiser la consommation énergétiques des dispositifs qui l’utilisent en leur permettant de s’affranchir de l’envoi de messages « keep-alive » (par exemple la consommation des batteries de tels dispositifs le cas échéant), et évite de solliciter inutilement les ressources du réseau. Typiquement, les modules 4A, 4C et 4D du serveur d’application 4 s’appuient sur ou peuvent être intégrés dans ce serveur PCP. Les fonctions des modules 4A à 4E du serveur d’application 4 sont décrites plus en détail ultérieurement en référence à la FIG. 4 décrivant les principales étapes d’un procédé de gestion d’un service selon l’invention. Dans le mode de réalisation décrit ici, la mise en œuvre par le serveur d’application 4 de certaines mesures de gestion de l’impact environnemental et/ou énergétique imputé au service S, comme notamment l’utilisation d’une ressource mutualisée du réseau NW telle qu’une tranche réseau par plusieurs dispositifs de communication et l’ordonnancement de l’accès au service par ces dispositifs de communications, s’appuie sur l’entité de gestion 3 du réseau NW. Lorsque l’architecture matérielle de l’ordinateur 6 est celle d’une entité de gestion conforme à l’invention telle que l’entité de gestion 3, le programme conforme à l’invention enregistré dans la mémoire non volatile NVM de l’ordinateur 6 est le programme PROG-3 qui comporte des instructions définissant les principales étapes d’un procédé de gestion d’un accès à une tranche réseau selon l’invention. Ce programme PROG-3 définit les modules fonctionnels de l’entité de gestion 3 (représentés sur la FIG. 1 ), qui s’appuient et/ou commandent tout ou partie des éléments PROC, MEM, ROM, NVM, et COM de l’ordinateur 6 évoqués précédemment. Ces modules fonctionnels comprennent, dans l’exemple du service S : un module 3A de réception, configuré pour recevoir en provenance d’un dispositif de communication tel que le dispositif de communication 5, une demande d’accès à une tranche réseau donnée parmi les tranches réseau SL1, …, SLK supportées par le réseau NW, cette tranche réseau notée SLopt étant mutualisée entre plusieurs dispositifs de communication accédant au service S fourni via le réseau NW en vue d’ajuster l’impact environnemental et/ou énergétique imputé au service S suite à une notification, reçue par le serveur d’application 4 du contrôleur réseau 2, d’un non-respect du critère de conformité CRIT par ledit au moins un indicateur IND représentatif de l’impact environnemental et/ou énergétique imputé au service S ; un module 3B de vérification, configuré pour vérifier auprès du serveur d’application 4 associé au service S, que ledit dispositif de communication en question est autorisé à accéder à la tranche réseau SLopt mutualisée ; et un module 3C de déclenchement activé le cas échéant et configuré pour déclencher un raccordement du dispositif de communication à la tranche réseau SLopt mutualisée. Les fonctions des modules 3A à 3C de l’entité de gestion 3 sont décrites plus en détail ultérieurement en référence à la FIG. 5 décrivant les principales étapes d’un procédé de gestion d’un accès à une tranche réseau selon l’invention. Enfin, lorsque l’architecture matérielle de l’ordinateur 6 est celle d’un dispositif de communication conforme à l’invention tel que le dispositif de communication 5, le programme conforme à l’invention enregistré dans la mémoire non volatile NVM de l’ordinateur 6 est le programme PROG-5 qui comporte des instructions définissant les principales étapes d’un procédé d’accès à un service selon l’invention. Ce programme PROG-5 définit les modules fonctionnels du dispositif de communication 5 (représentés sur la FIG. 1 ), qui s’appuient et/ou commandent tout ou partie des éléments PROC, MEM, ROM, NVM, et COM de l’ordinateur 6 évoqués précédemment. Ces modules fonctionnels comprennent, dans l’exemple du service S : un module 5A d’envoi, configuré pour envoyer au serveur d’application 4 une demande d’accès au service S ; et un module 5B de réception, configuré pour recevoir une notification en provenance du serveur d’application 4 informant le dispositif de communication 5 d’une application au trafic relatif au service S en provenance ou à destination du dispositif de communication 5 d’au moins une mesure de gestion d’un impact environnemental et/ou énergétique imputé au service S, cette mesure de gestion faisant suite à une notification reçue par le serveur d’application 4 du contrôleur réseau 2 lui indiquant le non-respect par ledit au moins un indicateur IND du critère de conformité CRIT. Les fonctions des modules 5A et 5B du dispositif de communication 5 sont décrites plus en détail ultérieurement en référence à la FIG. 6 décrivant les principales étapes d’un procédé d’accès à un service selon l’invention. Nous allons maintenant décrire, en référence aux figures 3 à 6 , les principales étapes mises en œuvre par les éléments du système 1 (contrôleur réseau 2, serveur d’application 4, entité de gestion 3 et dispositif de communication 5) lors de leur participation au mécanisme de collaboration proposé par l’invention pour maîtriser/gérer l’impact environnemental et/ou énergétique imputé au service S. Plus particulièrement, la FIG. 3 représente les principales étapes d’un procédé de supervision selon l’invention telles qu’elles sont mises en œuvre par le contrôleur réseau 2, la FIG. 4 représente les principales étapes d’un procédé de gestion d’un service selon l’invention telles qu’elles sont mises en œuvre par le serveur d’application 4, la FIG. 5 représente les principales étapes d’un procédé de gestion d’un accès à une tranche réseau selon l’invention telles qu’elles sont mises en œuvre par l’entité de gestion 3, et la FIG. 6 représente les principales étapes d’un procédé d’accès à un service selon l’invention telles qu’elles sont mises en œuvre par le dispositif de communication 5, dans un mode particulier de réalisation. Dans le mode particulier de réalisation décrit ici, on s’intéresse plus particulièrement à l’impact environnemental imputé au service S et notamment à son empreinte carbone (indicateur représentatif de l’impact environnemental imputé au service S au sens de l’invention), lorsque ce service S est fourni via le réseau NW qui supporte une pluralité de tranches réseau. Dans ce contexte, le mécanisme de collaboration proposé par l’invention est appelé ci-après procédure ou service COSINUS (pour « Carbon Optimized SlIced Networks with schedUled Service Continuity » en anglais). L’invention peut bien entendu être envisagée dans d’autres contextes, comme évoqué précédemment, et peut s’appliquer pour maîtriser l’impact énergétique du service S, ou son impact environnemental et son impact énergétique. Aucune limitation n’est attachée à la nature ou au nombre d’indicateurs permettant de mesurer cet impact. Ainsi, outre l’empreinte carbone, on peut considérer comme indicateurs, une consommation d’énergie, un coût d’approvisionnement de l’énergie, un indicateur de volumétrie de trafic, un indicateur environnemental (par exemple la température d’un équipement du réseau), une description d’une ou de plusieurs sources d’énergie utilisées (par exemple, des piles, une centrale nucléaire, un onduleur), un facteur de durabilité d’un déploiement (ou DSF pour « Deployment Sustainability Factor » en anglais), etc. Dans le mode de réalisation décrit ici, on suppose que lors d’une phase préliminaire (correspondant aux étapes E10 de la FIG. 3 et F10 de la FIG. 4 ), le contrôleur réseau 2 et le serveur d’application 4 négocient dynamiquement la mise en œuvre de la procédure COSINUS pour le service S et le réseau NW, par exemple via une interface de programmation applicative ou API (pour « Application Programming Interface » en anglais) dédiée, appelée ici API COSINUS. Pour exposer et utiliser l’API COSINUS, le contrôleur réseau 2 et le serveur d’application 4 utilisent par exemple le protocole de négociation dynamique CPNP (pour « Connectivity Provisioning Negotiation Protocol »), décrit dans le document RFC 8921 de M. Boucadair et al., édité par l’IETF, et intitulé « Dynamic Service Negotiation: The Connectivity Provisioning Negotiation Protocol (CPNP) », octobre 2020. En variante, d’autres protocoles que CPNP peuvent être utilisés, comme par exemple le protocole RESTCONF décrit dans le document IETF RFC 8040 de A. Bierman et al. intitulé « RESTCONF Protocol », janvier 2017. Lors de cette phase de négociation, le serveur d’application 4 envoie notamment au contrôleur réseau 2, via l’API COSINUS, un message de souscription pour pouvoir bénéficier de la procédure COSINUS pour le service S. Ce message de souscription contient au moins une adresse IP (et éventuellement un numéro de port, un nom de domaine, etc.) permettant de contacter (et ainsi de notifier) le serveur d’application 4. Dans l’exemple du serveur PCP exposé par le serveur d’application 4, cette adresse IP (et le cas échéant le numéro de port) peut être codée dans un champ « Contact_Locator » d’un message de souscription PCP. Le contrôleur réseau 2 accepte la souscription du serveur d’application 4 et lui envoie via l’API COSINUS un identifiant, par exemple noté AS4_id, alloué par le réseau NW (par exemple par le contrôleur réseau 2) permettant d’identifier de façon non ambiguë (c’est-à-dire univoque) au niveau du réseau NW le serveur d’application 4 durant la procédure COSINUS. Le contrôleur réseau 2 fournit également ici au serveur d’application 4 une plage d’adresses IP (IPv4 et/ou IPv6) ou de préfixes du réseau NW destiné(e)s à être utilisé(e)s par les dispositifs de communication lorsqu’ils accèdent au service S. Dans une variante de réalisation, l’identifiant AS4_id est généré par le serveur d’application 4 lui-même et fourni au contrôleur réseau 2 dans son message de souscription. Dans cette variante, il convient au serveur d’application 4 de mettre en œuvre une procédure pour s’assurer que l’identifiant AS4_id est globalement unique sur la pluralité de réseaux (dont le réseau NW) via lesquels le service S est susceptible d’être fourni. Dans une autre variante encore, l’identifiant AS4_id peut être généré par une entité tierce (par exemple, l’IANA ou « Internet Assigned Numbers Authority ») et fourni par cette entité tierce au contrôleur réseau 2 et/ou au serveur d’application AS 4. Les informations échangées entre le contrôleur réseau 2 et le serveur d’application 4 lors de la phase de négociation/souscription sont enregistrées par ces derniers, par exemple pour le contrôleur réseau 2 dans une table nommée AS_COSINUS_SUBSCRIBERS stockée dans le réseau NW (de sorte à être accessible par des entités du réseau participant à la procédure COSINUS telle que notamment l’entité de gestion 3), et pour le serveur d’application 4 dans une table nommée NTW_COSINUS_SUBSCRIPTIONS, stockée localement dans sa mémoire NVM. On note que cette phase de négociation/souscription entre le contrôleur réseau 2 et le serveur d’application 4 peut être répétée entre le contrôleur réseau 2 et d’autres serveurs d’application associés par exemple à d’autres services que le service S, et/ou entre le serveur d’application 4 et d’autres contrôleur réseau d’autres réseaux que le réseau NW via lesquels le service S est susceptible d’être fourni. Ainsi la table AS_COSINUS_SUBSCRIBERS maintenue par le contrôleur réseau 2 regroupe l’ensemble des informations échangées avec les serveurs d’application (dont le serveur d’application 4) ayant souscrit auprès du contrôleur réseau 2 à la procédure COSINUS pour les services auxquels ils sont associés et qui sont fournis via le réseau NW, et la table NTW_COSINUS_SUBSCRIPTIONS maintenue par le serveur d’application 4 regroupe l’ensemble des informations échangées avec les contrôleur réseau des réseaux (dont le contrôleur réseau 2 du réseau NW) auprès desquels le serveur d’application 4 a souscrit à la procédure COSINUS pour le service S. Pour chaque serveur d’application 4 référencé dans la table AS_COSINUS_SUBSCRIBERS, l’opérateur du réseau NW (par l’intermédiaire du contrôleur réseau 2 ou d’une autre entité du réseau) met en place ou configure des filtres (permettant d’identifier le trafic associé au service S) et des sondes déployées dans le réseau NW pour collecter des informations reflétant l’impact environnemental et/ou énergétique du service S. Les filtres portent par exemple sur des adresses IP des différentes instances de service du serveur d’application 4 impliquées dans la fourniture du service S ; ces adresses IP sont par exemple communiquées par le serveur d’application 4 au contrôleur réseau 2 lors de la phase de négociation/souscription. Dans le mode de réalisation décrit ici, les informations collectées par les sondes déployées dans le réseau NW reflètent la consommation carbonée de l’ensemble des communications établies depuis ou vers les instances de service du ou des serveurs d’application impliquées dans la fourniture du service S. On note que le serveur d’application 4, bien qu’étant associé au service S, n’est pas nécessairement directement impliqué dans la fourniture de celui-ci. Toutefois, par souci de simplification ici, on suppose que le serveur d’application 4 non seulement gère l’accès au service S mais également fournit celui-ci et est le seul service d’application impliqué dans cette fourniture. Dans une variante de réalisation, on peut envisager de collecter des informations reflétant l’impact environnemental et/ou énergétique du service S associé uniquement à certaines communications, par exemple à certains types de trafic, à un groupe d’utilisateurs particuliers, etc. Les informations reflétant l’impact environnemental et/ou énergétique du service S collectées notamment par les sondes et en application des filtres fournis sont communiquées au contrôleur réseau 2 (étape E20), qui les agrège ensuite pour estimer au moins un indicateur IND représentatif de l’impact environnemental et/ou énergétique du service S (étape E30). Le contrôleur réseau 2 peut utiliser par exemple, pour obtenir ces informations auprès des sondes, un protocole connu comme NETCONF ou IPFIX. L’obtention et l’agrégation par le contrôleur réseau 2 (via son module 2A d’estimation) des informations collectées par les sondes reflétant l’impact environnemental et/ou énergétique du service S peuvent avoir lieu de façon continue ou quasi-continue, ou à fréquence régulière, etc. Dans l’exemple envisagé ici, comme évoqué précédemment, le contrôleur réseau 2 estime comme indicateur IND l’empreinte carbone imputée au service S. Le contrôleur réseau 2 utilise par exemple à cet effet la méthode connue dite LCA (pour « Life-Cycle Assessment » en anglais) ou une méthode LCA simplifiée telle que décrite par exemple dans l’article de M. Ficher et al. intitulé « Assessing the carbon footprint of the data transmission on a backbone network », 24th Conference on Innovation in Clouds, Internet and Networks (ICIN 2021), 2021. Bien entendu, d’autres indicateurs et d’autres méthodes pour estimer ces indicateurs peuvent être envisagés pour estimer l’impact environnemental et/ou énergétique du service S, comme par exemple une consommation d’énergie dans le réseau NW imputée au service S, un état de batterie, etc. Des exemples de tels indicateurs (ou métriques) sont décrits notamment dans le document de A. Clemm et al. édité par l’IETF et intitulé « Green Networking Metrics », 16 juin 2023. Diverses méthodes pour estimer de tels indicateurs sont décrites notamment dans le document IETF RFC 7577 de J. Quittek et al, intitulé « Definition of Managed objects for Batterty Monitoring », juillet 2015, dans le document IETF RFC 7460 de M. Chandramouli et al, intitulé « Monitoring and Control MIB for Power and Energy », octobre 2015, ou dans le document de l’Opsa Working Group, J. Lindblad et al., intitulé « Power and Energy Efficiency », 20 octobre 2023. Par ailleurs, dans une variante de réalisation, le contrôleur réseau 2 peut estimer une pluralité d’indicateurs IND reflétant dans leur ensemble l’impact environnemental et/ou énergétique du service S (par exemple un indicateur IND(1) représentant l’empreinte carbone du service S et un indicateur IND(2) représentant sa consommation d’énergie). Le contrôleur réseau 2 (par exemple ici via son module 2A d’estimation) détermine ensuite si l’indicateur IND estimé respecte un critère de conformité donné (critère CRIT ici), c’est-à-dire prédéterminé ou prédéfini (étape test E40). Par exemple, le contrôleur réseau 2 compare l’indicateur IND avec une valeur seuil définie pour cet indicateur IND et pour le service S et examine si l’indicateur IND a franchi ou non cette valeur seuil. Typiquement, dans l’exemple de l’empreinte carbone, le contrôleur réseau 2 examine si celle-ci a dépassé un certain seuil correspondant à la valeur maximale que le réseau NW (c’est-à-dire l’opérateur du réseau) accepte (ou souhaite ou encore autorise) pour cette empreinte carbone pour le service S. Cette valeur maximale peut correspondre notamment à un quota de l’empreinte carbone du réseau que celui-ci a alloué au service S et que le service S ne doit pas dépasser. Ainsi, dans cet exemple illustratif, le critère de conformité CRIT est le dépassement par l’empreinte carbone du seuil/quota en question. Bien entendu, ceci n’est qu’un exemple illustratif et d’autres critères de conformité peuvent être envisagés en fonction des indicateurs considérés (par exemple, le franchissement d’un seuil minimal, une évolution particulière de l’indicateur, etc.). Si l’indicateur IND respecte le critère de conformité CRIT (réponse oui à l’étape test E40), les étapes d’obtention E20, d’estimation E30 et de comparaison E40 au critère de conformité CRIT sont réitérées par le contrôleur réseau 2. Si l’indicateur IND (ou l’un des indicateurs IND) ne respecte pas le critère de conformité CRIT (réponse non à l’étape test E40), le contrôleur réseau 2, via son module 2B de notification, notifie le serveur d’application 4 (et plus particulièrement son serveur PCP) du non-respect du critère de conformité par l’indicateur IND, autrement dit dans l’exemple de l’empreinte carbone, du dépassement par l’empreinte carbone du quota alloué par le réseau NW au service S (étape E50). Le contrôleur réseau 2 obtient les informations pour joindre le serveur d’application 4 (et plus particulièrement son serveur PCP) en consultant la table AS_COSINUS_SUBSCRIBERS. La notification envoyée par le contrôleur réseau 2 au serveur d’application 4 indique par ailleurs ici au serveur d’application 4 qu’une mesure de gestion de l’impact environnemental et/ou énergétique du service S (c’est-à-dire de son empreinte carbone ici) est requise. Dans une variante de réalisation, on peut envisager que le contrôleur réseau 2 envoie également des notifications intermédiaires au serveur d’application 4 à chaque fois que l’indicateur IND franchit divers seuils intermédiaires (par exemple 50% du quota alloué au service S, puis 75% de ce quota). En référence à la FIG. 4 , suite à la réception de la notification du contrôleur réseau 2 par le module 4A de réception du serveur d’application 4 (étape F20), le serveur d’application 4 déclenche, par l’intermédiaire de son module 4B de déclenchement, au moins une mesure de gestion ACT de l’impact environnement et/ou énergétique imputé au service S (c’est-à-dire ici de son empreinte carbone) (étape F30). La ou les mesures de gestion peuvent porter sur tout ou partie du trafic relatif au service S échangé via le réseau NW. Il peut s’agir notamment d’une mesure de limitation ou d’une mesure de neutralisation de l’impact environnemental et/ou énergétique imputé au service S, ou de toute autre mesure de gestion visant à maîtriser l’impact environnemental et/ou énergétique imputé au service S. Dans le mode de réalisation décrit ici, la mesure de gestion ACT déclenchée par le serveur d’application 4 est un mécanisme d’ordonnancement programmable. Ce mécanisme s’appuie sur une utilisation mutualisée d’une (ou de plusieurs) ressource(s) donnée(s) du réseau NW par plusieurs dispositifs de communication lors d’un accès au service S par ces dispositifs de communication et sur un ordonnancement temporel des dispositifs de communication en question pour accéder à la (ou les) ressource(s) mutualisée(s). D’autres exemples de mesures de gestion pouvant être envisagées ont été décrits précédemment. Plus spécifiquement, dans l’exemple du service S de vidéo en streaming considéré ici à titre illustratif, la ressource qui est mutualisée est une tranche réseau dédiée SLopt supportée par le réseau NW, au sein de laquelle les flux vidéo sont diffusés selon un mode de transmission multicast en vertu de créneaux temporels déterminés (on parle de diffusion multicast programmée ou « slot-based multicast » en anglais). Un tel mode de transmission permet avantageusement d’envoyer un même contenu vidéo à plusieurs dispositifs de communication simultanément durant des créneaux de temps déterminés, par exemple des créneaux fixes de 1mn, 5mn, 15mn, etc. Ce mode de diffusion programmée multicast de données est plus efficace en matière d’impact environnemental et/ou énergétique qu’un mode de transmission immédiate unicast des données au sein duquel un même contenu est dupliqué pour chaque dispositif de communication. Pour mettre en place ce mode de diffusion programmée, le serveur d’application 4, par le biais de son module 4B de déclenchement, sélectionne ainsi pour chaque contenu vidéo à diffuser offert par le service S, identifié par un identifiant appelé content_id ici, un ou plusieurs créneaux temporels ou slots (chacun étant identifié par un identifiant appelé slot_id ici) qu’il alloue à la transmission des données relatives à ce contenu vidéo sur la tranche réseau mutualisée SLopt. Ce ou ces créneaux temporels slot_id associés à un contenu vidéo content_id sont ensuite alloués aux (répartis entre les) dispositifs de communication qui souhaitent accéder via le service S au contenu vidéo en question, plusieurs dispositifs de communication demandant à accéder au contenu vidéo au cours d’un intervalle de temps donné pouvant se voir allouer le même créneau temporel slot_id pour accéder au contenu, et ainsi accéder au contenu de façon simultanée. La mutualisation de la tranche réseau SLopt se traduit donc ici par une utilisation simultanée de cette tranche réseau par plusieurs dispositifs de communication. Ceci revient à déterminer l’ordonnancement temporel selon lequel les dispositifs de communication en question vont accéder au service S et plus particulièrement au contenu vidéo content_id en utilisant la tranche réseau SLopt. Puis, le serveur d’application 4 notifie le contrôleur réseau 2, par l’intermédiaire de son module 4C de notification (et via éventuellement une API prévue à cet effet), de la ou des mesures de gestion ACT qu’il a déclenchées pour maîtriser (pour réduire par exemple) l’impact environnemental et/ou énergétique imputé au service S (étape F40). Dans l’exemple envisagé ici, le serveur d’application 4 informe ainsi le contrôleur réseau 2 de l’utilisation mutualisée de la tranche réseau SLopt par une pluralité de dispositifs de communication accédant au service S et de l’ordonnancement décidé pour cette utilisation mutualisée en lui envoyant un message ACTIVATE(SLopt, SCHEDULE), SCHEDULE désignant une information représentative dudit ordonnancement et plus particulièrement des associations entre content_id et slot_id. Une durée de validité peut être associée à la mesure de gestion et transmise dans le message ACTIVATE, par exemple, le temps que l’indicateur IND imputé au service S devienne conforme ou soit réinitialisé pour le serveur d’application 4 et/ou le service S). Dans le mode de réalisation décrit ici, suite à la réception de la notification ACTIVATE l’informant du déclenchement d’une mesure (ou de mesures) de gestion par le serveur d’application 4 (réponse oui à l’étape test E60), le contrôleur réseau 2 configure au moins une entité du réseau en support de cette mesure de gestion (étape E70). Plus particulièrement, dans l’exemple envisagé ici, lors de l’étape E70, le module 2D de configuration du contrôleur réseau 2 configure les nœuds de périphérie (ou BR pour « Border Routers » en anglais) du réseau NW avec des règles de classification du trafic mises à jour pour que les paquets de données relatifs au service S et reçus du serveur d’application 4 ou destinés au serveur d’application 4 soient associés à la tranche réseau SLopt. L’identifiant content_id associé à chaque flux de données (flux de contenu vidéo dans l’exemple envisagé ici) transportant des paquets de données relatifs au service S reçus du serveur d’application 4 émis selon un mode de transmission multicast sur la tranche réseau SLopt est partagé avec le contrôleur réseau 2 et les nœuds de périphérie BR configurés par ce dernier pour qu’ils soient en mesure d’identifier les flux concernés. Le contrôleur réseau 2 confirme la prise en compte de la mesure de gestion notifiée par le serveur d’application 4, et la configuration des nœuds de périphérie BR du réseau NW pour permettre la mise en œuvre de cette mesure de gestion (étape E80). Dès lors, suite à la réception de cette confirmation (étape F50), le serveur d’application 4 peut procéder à la fourniture du service S via son module 4E de fourniture, et plus particulièrement, dans l’exemple envisagé ici, à la diffusion programmée du ou des flux d’un contenu vidéo content_id en mode multicast vers la tranche réseau SLopt, selon l’ordonnancement SCHEDULE décidé par le serveur d’application 4 lors de l’étape F30 (étape F60). Un arbre de distribution multicast déployé dans la tranche réseau SLopt pour chaque association entre un identifiant content_id et un ou plusieurs identifiants slot_id dans l’ordonnancement SCHEDULE est alors utilisé dans le réseau NW pour acheminer les données jusqu’aux dispositifs de communication connectés au réseau NW ayant souscrit au(x) groupe(s) multicast correspondant(s). En variante, on peut envisager un arbre de diffusion pour plusieurs contenus différents (c’est-à-dire plusieurs identifiants content_id). Dans le mode de réalisation décrit ici, si à l’issue d’une période de temps déterminée, notée ici Tmax, le contrôleur réseau 2 n’est pas notifié (c’est-à-dire informé) par le serveur d’application 4 du déclenchement d’une mesure de gestion de l’impact environnemental et/ou énergétique imputé au service S (réponse non à l’étape test E60), il active dans le réseau NW un traitement pour tout ou partie du trafic relatif au service S en réponse au non-respect du critère de conformité CRIT par l’indicateur IND(étape E90). Ce traitement vise par exemple à réduire ou à neutraliser l’impact environnemental et/ou énergétique imputé au service S. Dans le mode de réalisation décrit ici, le module 2D de déclenchement embarqué dans le contrôleur réseau 2 déclenche à cet effet une mesure de gestion par défaut ACT-DEF consistant à basculer tout ou partie du trafic relatif au service S et transitant via le réseau NW vers une tranche réseau notée SL-LBE déterminée parmi les tranches réseau SL1, …, SLK supportées par le réseau NW, la tranche réseau SL-LBE fournissant un niveau de service dégradé par rapport à un niveau de service attendu pour le service S. Un tel niveau de service dégradé est par exemple un niveau de qualité de service adapté au mieux aux conditions d’accès au service aussi plus couramment désigné par « Best effort » en anglais ou un niveau de service inférieur à ce niveau de service « Best Effort » aussi désigné LBE pour « Lower than Best Effort » en anglais. Bien entendu, d’autres alternatives peuvent être envisagées. L’étape d’activation E90 s’accompagne d’une configuration par le contrôleur réseau 2, via son module 2D de configuration, des nœuds de périphérie BR du réseau NW (et plus particulièrement du réseau d’accès) avec des règles de classification du trafic mises à jour pour que le trafic relatif au service S soit associé à cette tranche réseau SL-LBE (étape E100). Cette configuration des nœuds de périphérie BR peut se faire directement ou indirectement via un contrôleur. Les règles de classification mises à jour sont également communiquées aux dispositifs de communication accédant au service S. Le contrôleur réseau 2 peut par ailleurs, via son module 2C de notification, informer le serveur d’application 4 que le trafic relatif au service S sera dès lors reclassé à l’entrée du réseau NW pour être dirigé (acheminé) vers la tranche réseau SL-LBE (étape E110). En outre, dans le mode de réalisation décrit ici, dès que le contrôleur réseau 2 détecte que l’indicateur IND représentatif de l’impact environnemental et/ou énergétique respecte le critère de conformité CRIT (par exemple, suite au déclenchement de la mesure de gestion ACT-DEF, l’impact environnemental et/ou énergétique imputé au service S a diminué, ou l’indicateur IND a été réinitialisé), le contrôleur réseau 2 annule le traitement activé par défaut par son module 2D lors de l’étape E90 (autrement dit, la mesure de gestion par défaut ACT-DEF). Dans l’exemple envisagé ici, cela se traduit par la réinstallation des tranches réseau utilisées habituellement pour accéder au service S (et la configuration des nœuds de périphérie BR en conséquence). En variante, d’autres traitements peuvent être activés par le contrôleur réseau 2 en l’absence de mesure de gestion de l’impact environnemental et/ou énergétique imputé au service S déclenchée par le serveur d’application 4. Par exemple, le contrôleur réseau peut activer un re-marquage du trafic relatif au service S pour le stocker dans une autre file d’attente, un écrêtage (« rate limit » en anglais) ou un rejet de tout ou partie des paquets de données relatifs au service S, une redirection des paquets de données relatifs au service S vers un portail captif, etc. Nous allons maintenant, en référence aux figures 4, 5 et 6, illustrer comment le déclenchement d’une ou de plusieurs mesures de gestion ACT de l’impact environnemental et/ou énergétique imputé au service S se traduit au niveau d’un dispositif de communication accédant au service S, et plus particulièrement du dispositif de communication 5. Dans le mode de réalisation décrit ici, en référence à la FIG. 6 , on suppose en préliminaire que le dispositif de communication 5 procède à la découverte (étape G10) d’au moins une entité de gestion 3 de tranches de réseau supportées par le réseau NW susceptible d’être impliquée dans la procédure COSINUS et notamment dans certaines mesures de gestion prises pour réduire (voire neutraliser) l’impact environnemental et/ou énergétique imputé au service S, typiquement ici son empreinte carbone. Une ou plusieurs entités de gestion 3 peuvent être présentes dans le réseau NW pour la mise en œuvre de la procédure COSINUS (aussi appelées ici « relais COSINUS »). Par souci de simplification, on considère toutefois ici une seule entité de gestion 3 de tranches réseau conforme à l’invention dans le réseau NW, c’est-à-dire un seul relais COSINUS. L’étape G10 de découverte peut être mise en œuvre de différentes façons. Ainsi, dans une première variante de réalisation, l’entité de gestion 3 peut être configurée au niveau du dispositif de communication 5 par le réseau NW (c’est-à-dire par son opérateur). Par exemple, le réseau NW fournit au dispositif de communication 5 au moins une adresse IP et un numéro de port associés à l’entité de gestion 3 de tranches réseau et permettant de la joindre. En variante, le réseau peut également fournir au dispositif de communication 5 un identifiant d’authentification (ou ADN pour « Authentication Domain Name » en anglais) associé à l’entité de gestion 3 pour lui permettre de s’authentifier auprès de cette dernière. Cette configuration par le réseau NW peut se faire en utilisant un protocole dédié, tel que par exemple le protocole DHCP (pour « Dynamic Host Configuration Protocol » en anglais), ou via un message d’annonce de routeur ou RA (pour « Router Advertisement » en anglais), etc. Dans une deuxième variante, le dispositif de communication 5 peut utiliser une adresse anycast ou multicast pour envoyer un message de découverte des entités de gestion de tranches réseau 3 opérant dans le réseau NW. L’entité de gestion 3 répond alors au message de découverte en envoyant par exemple une adresse IP et un numéro de port (et le cas échéant, un identifiant d’authentification) tels que décrits dans la première variante. Dans une troisième variante, le dispositif de communication 5 peut utiliser un nom de domaine réservé pour une utilisation spéciale ou SUDN (pour « Special-Use Domain Names), tel que décrit dans le document RFC 6761 de S. Cheshire et al. édité par l’IETF et intitulé « Special-Use Domain Names », février 2013, et requérir des résolutions de nom de domaine associées à ce nom de domaine réservé en vue d’obtenir des enregistrements de ressources (ou RR pour « Ressource Record » en anglais) de type SVBC des entités de gestion 3, comme décrit dans le document IETF RFC 9460 édité par B. Schwartz et al. intitulé « Service binding and parameter specification via the DNS (DNS SVCB and HTTPSSVC) », novembre 2023. On suppose par exemple que l’enregistrement RR SVCB d’une entité de gestion 3 conforme à l’invention comprend un paramètre « SvcParam » défini pour les besoins de l’invention et nommé ici COSINUS, indiquant le support de la procédure COSINUS par l’entité de gestion 3 en question. Le RR SVCB peut également comprendre une liste de types et/ou d’identifiants de tranches réseau gérées par l’entité de gestion 3. Suite au déclenchement de la mesure de gestion ACT par le serveur d’application 4 lors de l’étape F30 décrite précédemment, le serveur d’application 4 procède comme décrit ci-après pour les dispositifs de communication connectés au réseau NW et accédant au service S via le réseau NW. On suppose ainsi que le dispositif de communication 5 envoie, via son module 5A d’envoi, une demande d’accès REQ-S au service S au serveur d’application 4 (étape G20), et plus particulièrement dans l’exemple illustratif d’un service S de vidéo en streaming envisagé ici, une demande d’accès en streaming à un contenu vidéo CONT. La demande REQ-S est envoyée par le dispositif de communication 5 via une tranche réseau à laquelle il est connecté, par exemple ici la tranche réseau SL1. La demande d’accès REQ-S comprend une adresse IP source fournie au dispositif de communication 5 par le réseau NW et qui se trouve dans la plage d’adresses IP fournie par le contrôleur réseau 2 lors de la souscription du serveur d’application 4 à la procédure COSINUS (étape E10/F10 décrites précédemment). Suite à la réception de cette demande d’accès REQ-S (étape F61, FIG. 4 ), le serveur d’application 4 extrait l’adresse IP source de la demande d’accès REQ-S et vérifie si cette adresse IP correspond à une plage d’adresses IP consignée dans la table NTW_COSINUS_SUBSCRIPTIONS maintenue par le serveur d’application 4. Il vérifie par ailleurs si une notification de non-conformité d’un indicateur représentatif de l’impact environnemental et/ou énergétique imputé au service S a été reçue du contrôleur réseau 2 du réseau NW (étape test F62). Si le serveur d’application 4 ne trouve aucune entrée dans la table NTW_COSINUS_SUBSCRIPTIONS ou si aucune notification n’a été reçue du contrôleur 2 du réseau NW pour le service S (réponse non à l’étape test F62), alors la demande d’accès REQ-S au service S, puis les paquets de données échangés dans le cadre de l’accès au service S (à destination ou en provenance du dispositif de communication 5), sont traités par le réseau NW et par le serveur d’application 4 de façon conventionnelle, c’est-à-dire en utilisant une tranche réseau parmi les tranches réseau SL1, …, SLK supportées par le réseau NW à laquelle le dispositif de communication 5 est connecté et qui est adaptée au service S de façon connue en soi, par exemple la tranche réseau SL1 (étape F63). Dans l’exemple envisagé ici, une notification a été reçue lors de l’étape F20 du contrôleur réseau 2 du réseau NW et une mesure de gestion ACT de l’impact environnemental et/ou énergétique imputé au service S a été déclenchée par le serveur d’application 4 à l’étape F30, en réponse à cette notification. Si le serveur d’application 4 trouve une entrée dans la table NTW_COSINUS_SUBSCRIPTIONS et une notification de non-conformité de l’impact environnemental et/ou énergétique a été reçue (réponse oui à l’étape test F62), ce qui est le cas dans l’exemple envisagé ici, alors la mesure de gestion ACT déclenchée par le serveur d’application 4 est appliquée au trafic relatif au service S échangé avec ce dispositif de communication 5 (c’est-à-dire au trafic émis par le dispositif de communication 5 et au trafic destiné au dispositif de communication 5 dans le cadre de son accès au service S). Plus particulièrement, dans l’exemple illustratif envisagé ici, le trafic relatif au service S associé au dispositif de communication 5 et notamment le contenu vidéo CONT est véhiculé via la tranche réseau mutualisée SLopt et sa fourniture aux dispositifs de communication utilisant de façon mutualisée la tranche réseau SLopt est organisée selon l’ordonnancement SCHEDULE déterminé par le serveur d’application 4, c’est-à-dire pendant le créneau temporel identifié par slot_id associé à l’identifiant content_id correspondant au contenu vidéo CONT (étape F64). Le serveur d’application 4 sélectionne donc pour le dispositif de communication 5 le créneau temporel identifié par slot_id pour lui permettre d’accéder au contenu CONT. Puis, dans le mode de réalisation décrit ici, le serveur d’application 4 notifie (c’est-à-dire informe) via son module 4C de notification le dispositif de communication 5 de la mesure de gestion ACT déclenchée et appliquée au trafic relatif au service S le concernant, c’est-à-dire émis à destination du dispositif de communication 5 ou provenant de celui-ci. Dans l’exemple envisagé ici, le module 4C de notification envoie un message de notification au dispositif de communication 5 l’informant de l’utilisation de la tranche réseau mutualisée SLopt lors de l’accès par le dispositif de communication 5 au service S et du créneau temporel slot_id alloué pour la transmission du contenu content_id sur la tranche réseau SLopt (étape F65). Ce message de notification comprend ici, outre un identifiant de la tranche réseau mutualisée SLopt, une indication selon laquelle le contenu vidéo CONT auquel le dispositif de communication 5 souhaite accéder en streaming n’est par exemple pas immédiatement diffusé sur la tranche réseau mutualisée SLopt en réponse à la demande d’accès REQ-S au service S, mais à une échéance donnée correspondant à l’identifiant slot_id (par exemple, 30s, 1mn, 3mn). On note que dans le mode de réalisation décrit ici, on a envisagé un ordonnancement statique SCHEDULE déterminé par le serveur d’application 4 et notifié au contrôleur 2 lors de l’étape F40 en amont de l’accès à proprement parler au service S. Toutefois, cela n’exclut pas que cet ordonnancement évolue dans le temps (et donc que le serveur d’application 4 envoie au contrôleur 2 plusieurs messages reflétant cette évolution), notamment en fonction des demandes d’accès reçues par le serveur d’application 4 de dispositifs de communication. Par ailleurs, en variante, on peut envisager que le serveur d’application 4 détermine dynamiquement, en fonction des demandes d’accès au service S reçues de dispositifs de communication au cours par exemple d’un intervalle de temps déterminé, l’ordonnancement SCHEDULE qu’il envisage d’appliquer pour l’accès au service S par les dispositifs de communication en question, via la tranche réseau SLopt. Le dispositif de communication 5 confirme la réception (étape G30) et la prise en compte du message de notification (étape G40). Sur réception de cette confirmation, le serveur d’application 4 ajoute, dans un cache local se trouvant par exemple dans sa mémoire non volatile NVM, le dispositif de communication 5 à une liste des dispositifs de communication destinataires du contenu vidéo CONT diffusé sur la tranche réseau mutualisée SLopt, et obtient un identifiant noté ID5 pour le dispositif de communication 5. Par exemple, cet identifiant ID5 est généré pour le dispositif de communication 5 par le serveur d’application 4 aléatoirement, par exemple par un module (ou une instance de service) responsable de la gestion des connexions de l’ensemble des dispositifs de communication au serveur d’application 4. En variante, on peut envisager un identifiant généré par connexion ou par session de service pour le dispositif de communication 5 ; cette variante peut être adoptée en fonction de la nature du service, par exemple s’il s’agit d’un service de type transactionnel. Le serveur d’application 4 envoie au dispositif de communication 5 son propre identifiant AS4_id, l’identifiant ID5 généré pour le dispositif de communication 5 ainsi que l’identifiant slot_id indiquant le créneau temporel alloué au dispositif de communication 5 pour la transmission selon un mode de transmission multicast du trafic relatif au service S le concernant et l’identifiant content_id associé au contenu vidéo CONT (étape F66). Le serveur d’application 4 crée par ailleurs un contexte associé au dispositif de communication 5 dans son cache local, dans lequel il mémorise les identifiants ID5, slot_id et content_id. Le serveur d’application 4 procède de façon identique avec les autres dispositifs de communication souhaitant accéder au même contenu CONT que le dispositif de communication 5 et concernés par la mesure de gestion ACT. Suite à la réception de ces identifiants par le dispositif de communication 5 (étape G50), celui-ci envoie une demande d’accès REQ-SLopt à la tranche réseau mutualisée SLopt à l’entité de gestion 3 (relais COSINUS) des tranches réseau supportées par le réseau NW (et en particulier de la tranche réseau SLopt), découverte lors de l’étape de découverte G10 (étape G60). En variante, l’étape G10 de découverte peut être mise en œuvre par le dispositif de communication 5 suite à l’étape G50 de réception des identifiants fournis par le serveur d’application 4 ou à tout moment avant cette étape de réception. Dans le mode de réalisation décrit ici, la demande d’accès REQ-SLopt à la tranche réseau mutualisée SLopt prend la forme d’une demande de souscription au groupe multicast dont l’arbre de distribution multicast est associé aux identifiants slot_id et content_id et déployé au sein de cette tranche réseau. On suppose que l’adresse de groupe multicast correspondant au déploiement de l’arbre de distribution a été diffusée précédemment par l’entité de gestion 3. Dans le mode de réalisation décrit, la demande d’accès envoyée par le dispositif de communication 5 comprend les différents identifiants fournis par le serveur d’application 4 au dispositif de communication 5 (ID5, AS4_id, slot_id et content_id). Dans un mode de réalisation, la demande de souscription envoyée est un message « MLD Report » du protocole MLD (pour « Multicast Listener Group » en anglais), modifié pour les besoins de l’invention pour inclure notamment les identifiants précités, lorsque le réseau NW utilise le protocole IPv6. Lorsque le réseau NW utilise le protocole IPv4, il peut s’agir d’un message IGMP (pour « Internet Group Management Protocol » en anglais). Dans un autre mode de réalisation, la demande d’accès à la tranche réseau mutualisée SLopt prend la forme d’une demande de souscription « MLD Report » classique à l’arbre de distribution multicast et est accompagnée d’un message conforme au protocole ICMPv6 (pour « Internet Control Message Protocol version 6 » en anglais), véhiculant les différents identifiants fournis par le serveur d’application 4 au dispositif de communication 5 (ID5, AS4_id, slot_id et content_id). Le message ICMPv6 a pour but de déclencher l’envoi d’un message « MLD Query » par l’entité de gestion 3. Ce message MLD est envoyé typiquement par le routeur auquel est connecté le dispositif sous contrôle de l’entité de gestion 3. En référence à la FIG. 5 , l’entité de gestion 3 reçoit la demande REQ-SLopt du dispositif de communication 5 via son module 3A de réception (étape H10). L’entité de gestion 3 extrait les identifiants ID5, AS4_id, slot_id et content_id contenus dans la demande REQ-SLopt et procède à diverses vérifications sur la base de ces identifiants (étape H20). Plus particulièrement, dans le mode de réalisation décrit ici, l’entité de gestion 3 consulte la table AS_COSINUS_SUBSCRIBERS stockée dans le réseau NW et détermine si une entrée de la table est associée à l’identifiant AS4_id. Le cas échéant, l’entité de gestion 3 récupère dans la table AS_COSINUS_SUBSCRIBERS les informations permettant de joindre le serveur d’application 4 (adresse IP et le cas échéant numéro de port notamment du serveur PCP utilisé par le serveur d’application 4, fournis par ce dernier dans le champ « Contact_Locator » lors de la phase préliminaire de négociation/souscription avec le contrôleur réseau 2). Puis l’entité de gestion 3 vérifie, via son module 3B de vérification, auprès du serveur PCP du serveur d’application 4 en utilisant les informations obtenues, que le dispositif de communication 5 est bien autorisé (habilité) à accéder à la tranche réseau SLopt. Dans le mode de réalisation décrit ici, le module 3B de vérification de l’entité de gestion 3 envoie à cet effet une requête PCP au serveur PCP du serveur d’application 4 incluant une option appelée ici COSINUS_OP, définie pour les besoins de l’invention, contenant ici les identifiants ID5, AS4_id, slot_id et content_id. La FIG. 7 illustre un exemple de format pour une telle option, le code d’option (TBA pour « To Be Assigned » en anglais) étant fourni par l’IANA dans un contexte de standardisation. En référence à la FIG. 4 , sur réception de la requête PCP de l’entité de gestion 3, le serveur PCP du serveur d’application 4 (et plus particulièrement le module 4D de vérification intégré dans le serveur PCP) vérifie si un contexte correspondant aux identifiants ID5, slot_id et content_id reçus dans la requête PCP est maintenu dans le cache local du serveur d’application 4 (étape F67). Si aucun contexte correspondant aux identifiants ID5, slot_id et content_id n’est maintenu par le serveur d’application 4, alors un message d’erreur est envoyé par le module 4D de vérification du serveur d’application 4 à l’entité de gestion 3 lui indiquant que le dispositif de communication 5 n’est pas autorisé à utiliser la tranche réseau mutualisée SLopt. L’entité de gestion 3, par le biais de son module 3B de vérification, rejette la demande REQ-SLopt du dispositif de communication 5. Elle peut éventuellement informer également une plateforme dédiée. Au contraire, si un contexte correspondant aux identifiants ID5, slot_id et content_id est maintenu par le serveur d’application 4, alors une réponse positive confirmant que le dispositif de communication 5 est autorisé à accéder à la tranche réseau mutualisée SLopt est envoyée par le module 4D de vérification à l’entité de gestion 3. Sur réception de cette réponse positive, l’entité de gestion 3 accepte la demande REQ-SLopt (et ainsi la demande de souscription à l’arbre de distribution multicast associé à la tranche réseau mutualisée SLopt) (étape H30), et déclenche, via son module 3C de déclenchement, le raccordement du dispositif de communication 5 à la tranche réseau mutualisée SLopt (étape H40). Dans ce mode de réalisation, le raccordement du dispositif de communication 5 à la tranche réseau mutualisée SLopt est déclenché par l’entité de gestion 3, c’est-à-dire à l’initiative du réseau NW. En variante, on peut envisager que ce soit le dispositif de communication 5 qui soit à l’initiative de son raccordement à la tranche réseau mutualisée SLopt, la demande de raccordement du dispositif de communication 5 pouvant être faite auprès de l’entité idoine du réseau NW gérant la tranche réseau SLopt (par exemple l’entité de gestion 3 ou une autre entité de gestion de la tranche réseau SLopt) avant ou simultanément à l’envoi de sa demande de souscription à l’arbre de distribution multicast associé à la tranche réseau mutualisée SLopt. Suite au raccordement du dispositif de communication 5 à la tranche réseau mutualisée SLopt (étape G70), le dispositif de communication 5 accède au service S via la tranche réseau mutualisée SLopt (étape G90). Plus spécifiquement dans l’exemple d’un service de streaming vidéo envisagé ici, le contenu vidéo identifié par l’identifiant content_id est transmis au dispositif de communication 5 par le module 4E de fourniture du serveur d’application 4 via la tranche réseau mutualisée SLopt lors du créneau temporel identifié par l’identifiant slot_id (étape F68 sur la FIG. 5 ). Le créneau temporel identifié par slot_id est ainsi utilisé pour délivrer simultanément le contenu vidéo CONT à plusieurs dispositifs de communication (incluant le dispositif de communication 5) via la tranche réseau SLopt. La mesure de gestion ACT peut être mise en œuvre de façon durable ou être désactivée suite à la détection par le contrôleur 2 que l’indicateur IND représentatif de l’impact environnemental et/ou énergétique imputé au service S est devenu conforme au critère CRIT. Procédé de supervision par un contrôleur réseau (2) d’un réseau, ledit procédé comprenant : une étape (E30) d’estimation d’au moins un indicateur (IND) représentatif d’un impact environnemental et/ou énergétique imputé à un service fourni via ledit réseau ; et si ledit au moins un indicateur ne respecte pas un critère (CRIT) de conformité donné, une étape (E50) de notification d’un serveur d’application associé au service du non-respect par ledit indicateur dudit critère de conformité. Procédé de supervision selon la revendication 1 comprenant en outre en l’absence à l’issue d’une période déterminée d’un déclenchement d’au moins une mesure de gestion de l’impact environnemental et/ou énergétique par le serveur d’application suite à sa notification, une étape (E90) d’activation dans ledit réseau, pour tout ou partie du trafic relatif audit service, d’au moins un traitement (ACT-DEF) en réponse au non-respect du critère de conformité. Procédé de supervision selon la revendication 2 dans lequel ledit au moins un traitement (ACT-DEF) comprend un basculement de tout ou partie du trafic relatif audit service transitant via ledit réseau vers une tranche réseau (SL-LBE) fournissant un niveau de service dégradé par rapport à un niveau de service attendu pour ledit service. Procédé de supervision selon l’une quelconque des revendications 1 à 3, dans lequel l’étape (E30) d’estimation comprend une réception (E20) en provenance d’au moins une sonde déployée dans le réseau d’au moins une information reflétant un impact environnemental et/ou énergétique d’au moins une communication relative audit service établie depuis ou vers un serveur impliqué dans une fourniture dudit service. Procédé de supervision selon l’une quelconque des revendications 1 à 4 comprenant en outre : une étape de réception, en provenance du serveur d’application, d’une notification d’une utilisation mutualisée par plusieurs dispositifs de communication d’au moins une ressource donnée (SLopt) du réseau lors d’un accès audit service par lesdits dispositifs de communication ; et une étape (E70) de configuration d’au moins une entité du réseau pour permettre cette utilisation mutualisée. Procédé de supervision selon la revendication 5 dans lequel ladite au moins une ressource donnée comprend une tranche réseau donnée (SLopt) supportée par ledit réseau et ladite notification reçue du serveur d’application comprend une information représentative d’un ordonnancement (SCHEDULE) d’un accès au service par des dispositifs de communication via ladite tranche réseau. Procédé de gestion par un serveur d’application (4) d’un service fourni via au moins un réseau, ledit procédé comprenant : une étape (F20) de réception, en provenance d’un contrôleur réseau (2) dudit réseau, d’une notification d’un non-respect d’un critère de conformité donné par au moins un indicateur, estimé par le contrôleur réseau, représentatif d’un impact environnemental et/ou énergétique imputé audit service ; et une étape (F30) de déclenchement d’au moins une mesure (ACT) de gestion dudit impact environnemental et/ou énergétique, ladite mesure de gestion portant sur tout ou partie du trafic relatif audit service. Procédé de gestion selon la revendication 7 dans laquelle ladite au moins une mesure de gestion est choisie parmi au moins : une utilisation d’un encodage des données relatives audit service ayant une contribution à l’impact environnemental et/ou énergétique imputé audit service plus faible qu’un encodage courant ; une restriction d’un accès audit service via ledit réseau ; un ordonnancement d’un accès audit service par une pluralité de dispositifs de communication ; une utilisation mutualisée d’au moins une ressource donnée du réseau par plusieurs dispositifs de communication lors d’un accès audit service par lesdits dispositifs de communication ; un marquage d’un trafic relatif audit service pour le stocker dans au moins une file d’attente. Procédé de gestion selon la revendication 7 ou 8 comprenant, lorsque ladite au moins une mesure de gestion (ACT) comprend un ordonnancement (SCHEDULE) d’un accès audit service par une pluralité de dispositifs de communication, suite à une demande d’accès au service par au moins un dispositif de communication, une étape de sélection pour ledit au moins un dispositif de communication d’un créneau temporel (slot_id) alloué à ladite pluralité de dispositifs de communication pour l’accès audit service. Procédé de gestion selon l’une quelconque des revendications 7 à 9 dans lequel ladite au moins une mesure de gestion comprend une utilisation mutualisée par plusieurs dispositifs de communication lors d’un accès audit service, selon un ordonnancement déterminé, d’une tranche réseau (SLopt) donnée supportée par ledit réseau. Procédé de gestion selon la revendication 10 comprenant au moins une étape parmi : une étape (F40) de notification dudit contrôleur réseau de l’utilisation mutualisée de ladite tranche réseau donnée par lesdits dispositifs de communication selon ledit ordonnancement déterminé ; et une étape (F65) de notification desdits dispositifs de communication de ladite tranche réseau donnée à utiliser de façon mutualisée par lesdits dispositifs de communication lors d’un accès au service et dudit ordonnancement déterminé qui doit être appliqué. Procédé de gestion selon la revendication 10 ou 11 comprenant en outre une étape (F67) de réception en provenance d’une entité (3) du réseau d’une demande de vérification qu’un dispositif de communication (5) est autorisé à accéder à ladite tranche réseau donnée (SLopt). Procédé de gestion selon l’une quelconque des revendications 7 à 12 comprenant : une étape (F61) de réception d’une demande d’accès au service en provenance d’un dispositif de communication (5) ; si ledit dispositif de communication est concerné par une dite mesure de gestion, une étape d’application (F64) de cette mesure de gestion au trafic relatif au service en provenance ou à destination dudit dispositif de communication. Procédé de gestion, par une entité (3) d’un réseau, d’un accès à une tranche réseau supportée par le réseau, ledit procédé comprenant : une étape (H10) de réception, en provenance d’un dispositif de communication (5), d’une demande d’accès à une tranche réseau donnée (SLopt) supportée par le réseau, ladite tranche réseau étant mutualisée entre plusieurs dispositifs de communication accédant à un service fourni via le réseau, suite à une notification reçue par un serveur d’application associé audit service d’un contrôleur réseau du réseau d’un non-respect d’un critère de conformité donné par au moins un indicateur, estimé par le contrôleur réseau, représentatif d’un impact environnemental et/ou énergétique imputé audit service ; une étape (H20) de vérification, auprès du serveur d’application associé audit service, que ledit dispositif de communication est autorisé à accéder à ladite tranche réseau donnée mutualisée ; et le cas échéant, une étape (H40) de déclenchement d’un raccordement dudit dispositif de communication à ladite tranche réseau donnée mutualisée. Procédé d’accès, par un dispositif de communication (5), à un service (S) fourni via un réseau, ledit procédé comprenant : une étape (G20) d’envoi d’une demande d’accès au service à un serveur d’application (4) associé audit service ; une étape (G30) de réception d’une notification en provenance du serveur d’application informant ledit dispositif de communication d’une application au trafic relatif audit service en provenance ou à destination dudit dispositif de communication d’au moins une mesure de gestion d’un impact environnemental et/ou énergétique imputé au service, suite à une notification, reçue par ledit serveur d’application d’un contrôleur réseau du réseau, d’un non-respect d’un critère de conformité donné par au moins un indicateur, estimé par le contrôleur réseau, représentatif dudit impact environnemental et/ou énergétique. Procédé d’accès selon la revendication 15 dans lequel ladite au moins une mesure de gestion comprend une utilisation mutualisée selon un ordonnancement déterminé, lors d’un accès audit service, d’une tranche réseau donnée supportée par ledit réseau par plusieurs dispositifs de communication dont ledit dispositif de communication, et ledit procédé comprend : une étape (G60) d’envoi à une entité du réseau, d’une demande d’accès à ladite tranche réseau (SLopt) donnée mutualisée ; et suite au raccordement (G80) dudit dispositif de communication à ladite tranche réseau donnée mutualisée, une étape (G90) d’accès audit service via ladite tranche réseau donnée mutualisée. Contrôleur réseau (2) d’un réseau comprenant : un module (2A) d’estimation, configuré pour estimer au moins un indicateur représentatif d’un impact environnemental et/ou énergétique imputé à un service fourni via ledit réseau ; et un module (2B) de notification, activé si ledit au moins indicateur estimé ne respecte pas un critère de conformité donné, et configuré pour notifier un serveur d’application associé au service de ce non-respect dudit critère de conformité par ledit au moins un indicateur. Serveur d’application (4) configuré pour gérer un service fourni via au moins un réseau, ledit serveur d’application comprenant : un module (4A) de réception, configuré pour recevoir en provenance d’un contrôleur réseau dudit réseau, une notification d’un non-respect d’un critère de conformité donné par au moins un indicateur, estimé par le contrôleur réseau, représentatif d’un impact environnemental et/ou énergétique imputé audit service ; et un module (4B) de déclenchement, configuré pour déclencher au moins une mesure de gestion dudit impact environnemental et/ou énergétique, ladite mesure de gestion portant sur tout ou partie du trafic relatif audit service. Entité (3) d’un réseau, configurée pour gérer un accès à une tranche réseau supportée par le réseau, ladite entité comprenant : un module (3A) de réception, configuré pour recevoir en provenance d’un dispositif de communication, une demande d’accès à une tranche réseau donnée supportée par le réseau, cette tranche réseau étant mutualisée entre plusieurs dispositifs de communication accédant à un service fourni via le réseau, suite à une notification, reçue par un serveur d’application associé audit service d’un contrôleur réseau du réseau, d’un non-respect d’un critère de conformité donné par au moins un indicateur, estimé par le contrôleur réseau, représentatif d’un impact environnemental et/ou énergétique imputé audit service ; un module (3B) de vérification, configuré pour vérifier auprès du serveur d’application associé audit service, que ledit dispositif de communication est autorisé à accéder à ladite tranche réseau donnée mutualisée ; et un module (3C) de déclenchement activé le cas échéant et configuré pour déclencher un raccordement dudit dispositif de communication à ladite tranche réseau donnée mutualisée. Dispositif (5) de communication comprenant : un module (5A) d’envoi, configuré pour envoyer à un serveur d’application associé à un service fourni via un réseau, une demande d’accès audit service ; et un module (5B) de réception, configuré pour recevoir une notification en provenance du serveur d’application informant ledit dispositif de communication d’une application au trafic relatif audit service en provenance ou à destination dudit dispositif de communication d’au moins une mesure de gestion d’un impact environnemental et/ou énergétique imputé au service, suite à une notification, reçue par ledit serveur d’application d’un contrôleur réseau du réseau, d’un non-respect d’un critère de conformité donné par au moins un indicateur, estimé par le contrôleur réseau, représentatif dudit impact environnemental et/ou énergétique.