FR 3082080 A1 20191206 FR 1854682 A 20180531 Gestion de notification d'événement au sein d'un réseau d'équipements de type maillé. 1. Domaine de l'invention Le domaine de l'invention est celui des communications numériques, et notamment de la notification d'événement sur les équipements de communication, tels que des terminaux personnels mobiles ou des objets connectés. Plus précisément, l'invention concerne la gestion de telles notifications par les équipements d'un réseau de communication de type maillé, notamment, mais non exclusivement, dans un réseau personnel d'équipements (en anglais PAN pour « Personal Area Network »). 2. Art antérieur et ses inconvénients On constate de nos jours une tendance à la multiplication des équipements personnels ou professionnels connectés, tels qu'ordinateur personnel, tablette, téléphones intelligents (en anglais « smartphones »), montres connectées, ou tout autre objet connecté. Cette multiplicité d'équipements permet à l'utilisateur d'être toujours connecté et de recevoir n'importe où et à tout moment des notifications d'événements, pour le prévenir de la réception d'un message ou encore d'un événement à venir par exemple. Toutefois, la multiplication de ces équipements personnels, s'accompagne également de la multiplication intempestive de ces notifications d'événements. Par exemple, lors de la réception d'un nouveau message électronique, une notification correspondante va s'afficher sur tous les terminaux de l'utilisateur qui utilisent le logiciel de messagerie, soit par exemple son ordinateur personnel, sa tablette, son téléphone intelligent de type smartphone et sa montre connectée. Cette notification peut être sonore, visuelle, tactile ou encore simultanément sonore, visuelle et tactile, ce qui peut conduire à un joyeux vacarme. Ainsi, la nuisance générée par ces notifications dépasse souvent l'intérêt de ces notifications elles-mêmes, notamment lorsque le message reçu n'est finalement qu'un message publicitaire par exemple. Pour réduire ces nuisances, l'utilisateur peut bien sûr paramétrer ses équipements de communication, pour choisir par exemple de ne pas afficher les notifications d'événements sur tous, et privilégier au contraire l'un seulement de ses appareils de communication, comme par exemple son téléphone intelligent. Cependant, une telle solution peut s'avérer mal pratique, et empêcher l'accès rapide de l'utilisateur à la notification, dans le cas où elle ne s'affiche pas sur l'appareil de communication qu'il est en train d'utiliser, ou qu'il a à portée de main à un instant donné. Il existe donc un besoin d'une technique de gestion optimisée des notifications d'événement au sein d'un réseau d'équipements de communication. Notamment, il existe un besoin d'une telle technique qui permette de limiter les nuisances générées par l'affichage des 2 notifications sur les différents équipements, tout en conservant à l'utilisateur le bénéfice de ces notifications. Il existe également un besoin d'une telle technique qui permette d'augmenter l'efficacité de la gestion de telles notifications d'événements au sein d'un réseau d'équipements de 5 communications, par rapport aux solutions de l'art antérieur. 3. Exposé de l'invention L'invention répond à ce besoin en proposant un procédé de gestion de notification d'événement par un équipement appartenant à un réseau d'équipements de type maillé. Selon l'invention, sur réception d'un message associé à l'événement, un tel procédé met en oeuvre : 10 - une détermination d'une liste d'au moins un équipement appartenant au réseau d'équipements de type maillé ; - une évaluation d'un niveau de priorité associé à l'équipement au sein du réseau maillé ; - si le niveau de priorité évalué est le niveau de priorité le plus élevé de la liste, une 15 gestion de la notification d'événement par l'équipement. Ainsi, l'invention repose sur une approche tout à fait nouvelle et inventive de la gestion de notification d'événement au sein d'un réseau d'équipements de communication, tel qu'un réseau personnel d'équipements de type PAN, ou un réseau d'objets connectés de type loT (pour l'anglais « Internet of Things », internet des objets) par exemple. 20 En effet, l'invention propose de ne plus considérer les terminaux ou équipements de communication de manière individuelle, avec leur propre système interne de gestion des notifications, mais de les fédérer en réseau d'équipement de type maillé (d'une portée de quelques mètres par exemple). Au sein de ce réseau, il est possible d'affecter à chaque équipement une importance, ou un niveau de priorité, et de faire en sorte que seul le terminal de 25 niveau de priorité le plus élevé soit en charge de la notification d'événement. On réduit ainsi sensiblement les nuisances générées par le traitement simultané des notifications par tous les terminaux personnels de l'utilisateur, tout en conservant à ce dernier le bénéfice de la notification, et l'accès rapide et efficace à l'information qu'elle contient. Une telle solution est modulable et adaptable, en fonction du nombre d'équipements de 30 communication présents et actifs dans l'entourage de l'utilisateur, grâce à la mise à jour de la liste des équipements du réseau. Selon un premier aspect de l'invention, l'évaluation d'un niveau de priorité associé à l'équipement met en oeuvre une comparaison d'un poids associé à l'équipement et d'une information relative à un poids associé à au moins un autre équipement du réseau maillé, et le 3 niveau de priorité le plus élevé est associé à l'équipement du réseau maillé associé au poids le plus fort. Ainsi, avant de décider de prendre en charge une notification d'événement, chaque équipement du réseau compare son poids à celui de ses voisins, et ne traite la notification, pour la 5 restituer à l'utilisateur, que s'il détermine qu'il est l'équipement de poids le plus fort au sein du réseau maillé. Un tel poids associé à l'équipement est paramétrable par un utilisateur et/ou en fonction d'un horaire et/ou en fonction d'une information contextuelle associée à l'utilisateur. Ainsi, l'utilisateur peut paramétrer manuellement, via l'interface utilisateur de 10 l'équipement, le poids associé à chacun de ses terminaux de communication, et ainsi affecter par exemple à sa montre connectée, qu'il a toujours avec lui, le poids le plus fort pour recevoir toutes les notifications sur cet équipement. Il peut également affecter des poids identiques à plusieurs équipements par exemple son téléphone intelligent et son ordinateur professionnel, pour toujours recevoir les notifications d'événement sur ces deux équipements. 15 Le poids associé aux différents équipements peut également varier en fonction d'un horaire, pour s'adapter à l'organisation de l'utilisateur. Ainsi, l'ordinateur professionnel de l'utilisateur peut recevoir le poids le plus fort pendant les horaires de travail, mais un poids plus faible le reste du temps, tandis que le poids le plus fort est affecté au téléphone mobile de l'utilisateur en soirée ou pendant les week-ends. 20 Le poids des équipements peut encore varier en fonction d'une information contextuelle associée à l'utilisateur, du type « je suis en réunion » ou « je suis à la maison ». Cette information contextuelle peut être déduite d'une information de géolocalisation de l'utilisateur, ou d'un état de présence sur un logiciel de messagerie instantanée, ou par toute autre technique connue de l'art antérieur, et ne sera donc pas décrite ici plus en détail. 25 Enfin, le poids associé aux différents équipements du réseau de l'utilisateur peut également être fondé sur la mise en oeuvre d'une technique d'apprentissage par intelligence artificielle, par exemple par observation, sur une période donnée, des habitudes de l'utilisateur, et détection de l'équipement préférentiel sur lequel il consulte et acquitte les notifications d'événement, afin d'en déduire le poids idéal à associer à chacun. 30 Selon une autre caractéristique, l'information relative à un poids associé à au moins un autre équipement du réseau maillé est extraite d'un message reçu de cet équipement et/ou déduite d'une absence de réception de message en provenance de cet équipement. En effet, le poids peut être communiqué en clair, dans un message transmis à l'équipement. En variante, afin de réduire le nombre de messages échangés au sein du réseau, et ainsi éviter la consommation inutile de ressources, on peut également imaginer que seuls les 4 équipements de poids le plus fort répondent à leurs voisins : l'absence de réception de message en provenance d'un équipement voisin permet donc de déduire que ce dernier est de poids inférieur. Selon un aspect, lorsque le message associé à l'événement est la notification 5 d'événement, un tel procédé met en oeuvre une émission, vers les équipements du réseau maillé, d'une requête de notification comprenant : - un identifiant de l'équipement ; - un identifiant de la notification d'événement ; - un poids de l'équipement. 10 Ainsi, sur réception de la notification d'événement, l'équipement initie sa prise en charge au sein du réseau en adressant à tous ses voisins une requête de notification, par laquelle il les informe de son identifiant, de son poids, et d'un identifiant de la notification d'événement. Lorsque le message associé à l'événement est une requête de notification reçue d'un autre équipement du réseau maillé, un tel procédé met en oeuvre : 15 - une comparaison du poids de l'autre équipement ayant émis la requête de notification reçue et du poids de l'équipement ; - si le poids de l'équipement est supérieur au poids de l'autre équipement ayant émis la requête de notification reçue, une émission d'une réponse à notification comprenant : - un identifiant de l'équipement ; 20 - un identifiant de la notification d'événement ; - un poids de l'équipement. Ainsi, tous les équipements qui reçoivent une requête de notification renvoient une réponse à notification qui comprend leur identifiant, l'identifiant de la notification, et leur poids, mais seulement si leur poids est supérieur à celui de l'équipement ayant émis la requête de 25 notification, de façon à limiter le nombre de messages échangés au sein du réseau. Les équipements de poids inférieur déduisent quant à eux que l'équipement ayant émis la requête de notification présente un niveau de priorité plus élevé au sein du réseau, et qu'ils n'ont donc pas à gérer la notification d'événement pour la restituer à l'utilisateur. Selon un autre aspect, si, après émission de la requête de notification, l'équipement ne 30 reçoit aucune réponse à notification en provenance d'un des équipements du réseau maillé, il détermine qu'il est associé au niveau de priorité le plus élevé et met en oeuvre la gestion de ladite notification d'événement. En effet, il déduit de cette absence de réponse, que les autres équipements de poids inférieur se sont tus pour le laisser prendre en charge la notification d'événement. 5 Selon encore un autre aspect, lorsque le message associé à l'événement est une réponse à notification reçue d'un autre équipement du réseau maillé, un tel procédé met en oeuvre une vérification de réception d'un message d'acquittement de la notification et, en l'absence de réception du message d'acquittement à l'issue d'une période d'attente de durée déterminée, une 5 mise à jour de la liste par suppression de l'équipement associé au poids le plus fort. Il est en effet possible que l'équipement qui était sensé restituer la notification d'événement à l'utilisateur ait été défaillant (plus de batterie par exemple, ou passage en mode inactif). Il est alors important de supprimer cet équipement de la liste, et de reprendre le processus en réémettant le message associé à l'événement aux autres équipements du réseau, 10 pour assurer une restitution optimale à l'utilisateur. L'invention concerne également un produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en oeuvre d'un procédé tel que décrit précédemment, lorsqu'il est exécuté par un processeur. L'invention vise également un support d'enregistrement lisible par un ordinateur sur 15 lequel est enregistré un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé de gestion de notification d'événement selon l'invention tel que décrit ci-dessus. Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une 20 ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une clé USB ou un disque dur. D'autre part, un tel support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens, de sorte que le programme d'ordinateur qu'il contient est exécutable à 25 distance. Le programme selon l'invention peut être en particulier téléchargé sur un réseau par exemple le réseau Internet. Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé de contrôle d'affichage précité. 30 L'invention concerne également un équipement de communication et un système de communication comprenant un ensemble de tels équipements présentant en combinaison tout ou partie des caractéristiques exposées dans l'ensemble de ce document. Notamment, un tel équipement de communication, qui appartient à un réseau d'équipements de type maillé, comprend des moyens de gestion de notification d'événement, qui 35 comprennent : 6 - une unité de réception d'un message associé à l'événement ; - un module de détermination d'une liste d'au moins un équipement appartenant au réseau d'équipements de type maillé ; - un module d'évaluation d'un niveau de priorité associé à l'équipement au sein du 5 réseau maillé ; - un module de gestion de la notification d'événement par l'équipement, apte à être activé si le niveau de priorité évalué par le module d'évaluation est le niveau de priorité le plus élevé de la liste. L'équipement de communication, le système de communication et le programme 10 d'ordinateur correspondants précités présentent au moins les mêmes avantages que ceux conférés par le procédé de gestion de notification d'événement selon la présente invention. 4. Liste des figures D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, 15 en relation avec les figures, parmi lesquelles : - la figure 1 présente la structure générale d'un réseau d'équipements maillé de six terminaux avec leur poids respectifs; - la figure 2 illustre un premier exemple de réseau personnel d'équipements, dit réseau initial, selon un mode de réalisation de l'invention; 20 - la figure 3 illustre un exemple d'une scission du réseau initial de la figure 2 selon un mode de réalisation de l'invention ; - les figures 4A et 4B présentent les étapes successives de traitement d'une notification d'événement, selon un mode de réalisation de l'invention, dans le réseau de la figure 2; - la figure 5 présente un schéma synoptique général du procédé de gestion de notification 25 d'événement selon un mode de réalisation de l'invention ; - la figure 6 propose un schéma synoptique détaillant l'étape 100 du schéma de la figure 5, relative à la réception d'une notification d'événement ; - la figure 7 propose un schéma synoptique détaillant l'étape 200 du schéma de la figure 5, relative à la réception d'une requête de notification ; 30 - la figure 8 propose un schéma synoptique détaillant l'étape 300 du schéma de la figure 5, relative à la réception d'une réponse à notification ; - la figure 9 propose un schéma synoptique détaillant l'étape 400 du schéma de la figure 5, relative à la réception d'un acquittement de notification ; 7 - la figure 10 propose un schéma synoptique détaillant l'étape 500 du schéma de la figure 5, relative à la gestion d'un acquittement de la notification d'événement par l'utilisateur de l'équipement, - la figure 11 illustre la structure matérielle d'un équipement de communication du réseau 5 de la figure 2, selon un mode de réalisation de l'invention. 5. Description détaillée de modes de réalisation de l'invention Le principe général de l'invention repose sur l'affectation de poids aux équipements de communication d'un réseau d'équipements de type maillé, permettant d'affecter un niveau de priorité à ces équipements, de façon que seul l'équipement, ou terminal, de niveau de priorité le 10 plus élevé prenne en charge la gestion d'une notification d'événement, pour sa restitution à l'utilisateur. Ainsi, cette restitution sélective de la notification à l'utilisateur permet de limiter les nuisances sonores et/ou visuelles associées à ces notifications, tout en gardant le bénéfice de la notification pour l'utilisateur. On présente désormais, en relation avec la figure 1, la structure générale d'un réseau 15 d'équipements de communication de type maillé, dans le contexte duquel peut être mise en oeuvre l'invention, dans un mode de réalisation. Sur cette figure, six terminaux de communication référencés de 1 à 6 sont schématiquement représentés, ainsi que les différentes routes de communication entre ces derniers. Par souci de simplification, on assimile ici la référence numérique associée à un équipement de communication et le poids qui lui est associé dans le 20 réseau. D'autres configurations sont bien sûr également possibles, notamment une configuration dans laquelle plusieurs équipements de communication distincts se verraient affecter le même poids. Ainsi, dans l'exemple de la figure 1, les terminaux référencés 1 à 6 ne sont plus considérés individuellement avec leur propre système de notification, mais plutôt comme un réseau 25 personnel d'équipements (PAN) au sein duquel un ou plusieurs équipements prioritaires sont en charge de la restitution, par exemple sous forme d'affichage ou de signal sonore, d'une notification d'événement. Une telle notification d'événement peut consister en une notification visant à informer l'utilisateur de l'arrivée d'un nouveau message dans le système de messagerie électronique, ou dans le système de communication instantanée, ou en un rappel d'événement 30 mémorisé dans le calendrier de l'utilisateur, ou en tout autre message d'alerte ou d'information destiné à l'utilisateur. Dans un mode particulier de réalisation, le réseau de la figure 1 est un réseau de type maillé, avec une portée de quelques mètres, correspondant à la distance courante entre les différents équipements de communication d'un utilisateur lorsqu'il est sur son lieu de travail ou à 35 son domicile. 8 La figure 2 présente un exemple particulier de réseau personnel d'équipements présentant la structure générale de la figure 1, dans lequel le réseau personnel d'équipements est constitué de cinq terminaux de poids différents. Dans cet exemple de configuration, appelé par la suite réseau initial, l'utilisateur dispose de cinq équipements de communication : 5 - Un téléphone intelligent personnel de type smartphone référencé 1, - Une montre connectée référencée 2, - Un téléphone intelligent professionnel référencé 3, - Une tablette référencée 4, - Un ordinateur portable référencé 5. 10 A nouveau, par souci de simplification, on assimile ici la référence numérique de l'équipement de communication, et le poids qui lui est associé dans le réseau maillé d'équipements. Ainsi, l'ordinateur portable se voit affecter un poids de 5, correspondant au poids le plus élevé du réseau maillé, et le téléphone intelligent personnel se voit affecter le poids le plus faible de 1. 15 Selon un mode de réalisation de l'invention, l'utilisateur peut affecter les poids des différents terminaux référencés 1 à 5 manuellement, via l'interface homme/machine de ces équipements terminaux, en fonction de ses préférences d'utilisation. Le paramétrage du réseau, et notamment des poids de chaque terminal n'est cependant pas limité à ce mode de réalisation particulier. En effet, le réseau, et notamment les poids affectés aux différents équipements, 20 peuvent être paramétrés et modifiés de différentes manières : - En fonction d'un planning établi : par exemple, un premier ensemble de poids peut être associé aux terminaux référencés 1 à 5, pendant les horaires de travail de l'utilisateur (privilégiant par exemple l'ordinateur portable), tandis qu'un deuxième ensemble de poids leur est associé sur le temps du déjeuner, quand l'utilisateur fait du 25 sport (privilégiant par exemple la montre connectée), et un troisième ensemble de poids leur est associé en dehors de ces horaires de travail ou d'activité sportive (privilégiant par exemple le téléphone intelligent personnel); - En fonction d'un contexte associé à l'utilisateur, comme par exemple «Je suis en réunion », « je suis à la maison », qui peut être établi en prenant en compte divers 30 paramètres tels que la géolocalisation, la proximité par rapport à une borne WiFi®, l'état de présence du logiciel de messagerie instantanée, ... - en mettant en oeuvre une intelligence artificielle capable de réaliser un apprentissage des routines de l'utilisateur et proposer ainsi les poids les plus adaptés aux différents équipements de communication référencés 1 à 5, en fonction de ces routines. 9 L'exemple de la figure 2 correspond par exemple au cas où l'utilisateur se trouve à son bureau, en train de rédiger un document sur son ordinateur portable 5. Dans cet exemple, si une notification d'événement survient, il est souhaitable qu'elle soit signalée à l'utilisateur par l'ordinateur portable 5, sur lequel il est en train de travailler. Pour cette raison, le poids le plus 5 fort est affecté à cet équipement et ce dernier prendra seul en charge la gestion et la restitution à l'utilisateur de cette notification d'événement. Dans ce contexte, il est également possible que l'utilisateur s'absente temporairement de son bureau, emportant avec lui avec son téléphone intelligent personnel 1 et sa montre connectée 2, par exemple pour passer un appel personnel. Le téléphone intelligent personnel 1 et 10 la montre connectée 2 sont alors hors de portée de communication des autres équipements référencés 3 à 5. Le réseau initial de la figure 2 peut alors être scindé en deux réseaux personnels d'équipements distincts, tels qu'illustrés sur la figure 3. Dans cette configuration, il est souhaitable qu'une notification d'événement soit traitée indépendamment sur les deux nouveaux réseaux personnels d'équipements (PAN), par les 15 terminaux de poids le plus important de chacun des deux sous-réseaux. Dans cet exemple, la notification sera prise en charge et restituée par l'ordinateur portable 5 et la montre connectée 2. Au retour de l'utilisateur dans son bureau, l'ensemble des équipements référencés 1 à 5 sont à nouveau à portée de communication (par exemple en WiFi® ou en Bluetooth®, selon les canaux de communication disponibles sur les équipements), et le réseau personnel 20 d'équipements revient à l'état initial de la figure 2. On présente désormais plus en détail, en relation avec les figures 4 et suivantes, les différentes étapes du procédé de gestion de notification d'événement selon un mode de réalisation de l'invention, permettant d'atteindre un tel résultat d'efficacité, et de s'assurer que la restitution d'une notification d'événement à l'utilisateur soit toujours prise en charge par le 25 terminal adéquat. A titre préliminaire, une liste des équipements qui sont autorisés dans le réseau personnel d'équipements est définie manuellement. Cette étape peut être effectuée par l'utilisateur, qui peut configurer son réseau personnel d'équipements comme comprenant l'ensemble des terminaux référencés 1 à 5 de la figure 2, ou seulement certains de ceux-ci s'il le préfère. 30 Chaque terminal au sein de ce réseau PAN est caractérisé par un identifiant unique (pour la technologie réseau sous-jacente utilisée, par exemple un protocole IP), noté IdEQi, et a connaissance de la liste des équipements qui peuvent constituer le réseau personnel d'équipements {IdEQ1, IdEQ2, IdEQ3, IdEQn}). Dans un mode de réalisation particulier, un protocole du type « Ad-hoc On-demand 35 Distance Vector » (AODV - tel que défini dans le document RFC 3561 publié par l'IETF (Internet 10 Engineering Task Force)) peut être utilisé pour la constitution des tables de routages entre les différents terminaux référencés 1 à 5. Pour cela, lorsqu'un équipement source veut établir une route vers une destination pour laquelle il ne possède pas encore de chemin, il diffuse un paquet ROUTE_REQ. Si une réponse 5 ROUTE_REP est reçue, alors l'opération de découverte de route est terminée. Dans le cas contraire, au bout d'un délai d'attente, il rediffuse le message ROUTE_REQ et attend une période supérieure à la première. En l'absence de réponse ROUTE_REP, ce processus peut être répété jusqu'à ROUTE_REQ_RETRIES fois. S'il n'y a toujours pas de réponse au bout d'un nombre de tentatives égal à ROUTE_REQ_RETRIES + 1, le processus de recherche de route est abandonné (i.e 10 l'équipement n'est pas joignable). Un équipement recevant un paquet ROUTE_REQ émettra alors un paquet ROUTE_REP s'il est la destination ou s'il possède une route vers la destination avec un numéro de séquence supérieur (une version plus récente de la route) ou égal à celui du paquet ROUTE_REQ sinon il rediffuse le paquet ROUTE_REQ. Les équipements conservent chacun une trace des adresses 15 sources et des identifiants de diffusion des paquets ROUTE_REQ. Dans le cas où ils reçoivent un paquet ROUTE_REQ qu'ils ont déjà traité, ils le suppriment. Une fois que la source a reçu les paquets ROUTE_REP, elle peut commencer à émettre des paquets de données vers la destination. Si, ultérieurement, la source reçoit un ROUTE_REP contenant un numéro de séquence supérieur ou égal, mais avec un nombre de sauts plus petits, 20 elle mettra à jour son information de routage vers cette destination et commencera à utiliser la meilleure route. Une route est maintenue aussi longtemps qu'elle continue à être active, c'est-à-dire tant que des données transitent entre la source et la destination. Le lien expire quand il n'y a plus de données en transit sur le lien et au bout d'un délai appelé ACTIVE_ROUTE_TIMEOUT. En cas de 25 coupure du lien, l'équipement d'extrémité émet un paquet ROUTE_ERR vers l'équipement source pour le prévenir que la destination est désormais injoignable. Si le l'équipement source veut toujours obtenir une route vers cette destination, il doit recommencer le processus de découverte de route. Ce type de protocole permet non seulement la constitution d'un réseau personnel 30 d'équipements, mais aussi la vérification de la consistance de ce réseau personnel d'équipements car ce protocole est à même de détecter les coupures de liens. Ainsi, la mise en oeuvre d'un tel protocole de découverte de routes permet aisément de passer de la configuration de réseau de la figure 2 à la configuration de réseaux de la figure 3, lorsque certains équipements de communication sont hors de portée de leurs voisins. 11 Une fois que le réseau personnel d'équipements a été constitué, la survenance d'une notification d'événement peut être astucieusement gérée au sein de ce dernier, selon un mode de réalisation de l'invention, illustré par les figures 4A et 4B. Ainsi, la figure 4A illustre plus particulièrement les actions du téléphone mobile 5 professionnel 3, à réception d'une notification d'événement. De manière générale, lorsqu'une notification est reçue par les équipements du réseau, ceux-ci envoient une requête de notification, notée NOTIF_REQ, visant à informer l'ensemble des autres équipements du réseau de la réception de cette notification. Cette requête de notification NOTIF_REQ spécifie leur identifiant, leur poids et un identifiant de la notification à traiter (par 10 exemple un numéro. La figure 4A illustre le point de vue du téléphone mobile professionnel 3, qui adresse donc à chacun des équipements référencés 1, 2, 4 et 5 une même requête de notification , où : NOTIF_REQ identifie le type de message envoyé, à savoir une requête de 15 notification ; IdEQ3 correspond à l'identifiant du terminal mobile professionnel 3; Notif# correspond à l'identifiant de la notification d'événement reçue ; le chiffre 3 correspond au poids du terminal mobile professionnel 3. Selon un mode de réalisation de l'invention, tous les équipements du réseau PAN qui 20 reçoivent un message de type NOTIF_REQ renvoient, à l'équipement expéditeur de la requête de notification NOTIF_REQ, une réponse de notification NOTIF_REP, à condition que leur poids soit supérieur à celui de l'équipement expéditeur. Une telle réponse NOTIF_REP comprend l'identifiant de l'équipement, le numéro de la notification et le poids de l'équipement. Ainsi, comme illustré sur la figure 4B, la tablette référencée 4 et l'ordinateur portable 25 référencé 5 adressent chacun au téléphone intelligent professionnel 3 une réponse de notification, à savoir : pour la tablette ; pour l'ordinateur portable. En revanche, le téléphone intelligent personnel 1 et la montre connectée 2, de poids 30 inférieurs à celui du téléphone intelligent professionnel 3, n'adressent aucune réponse à la requête de notification de ce dernier. A réception de ces réponses de notification NOTIF_REP, le téléphone intelligent professionnel 3 constate que la tablette référencée 4 et l'ordinateur portable référencé 5 présentent un poids plus élevé que le sien : il en déduit qu'il n'est pas en charge de la gestion de 35 la notification d'événement d'identifiant notif#. 12 En adoptant le point de vue du téléphone intelligent personnel 1, de la montre connectée 2 et de la tablette 4, ces derniers pourront dresser le même constat, à savoir qu'ils n'ont pas le poids le plus élevé du réseau PAN. En revanche, l'ordinateur personnel 5 ne recevra aucune réponse de notification NOTIF_REP aux requêtes de notification NOTIF_REQ qu'il adressera aux 5 autres équipements du réseau PAN, et en déduira qu'il est l'équipement présentant le poids le plus élevé, et qu'il doit donc prendre en charge la restitution à l'utilisateur de la notification d'événement d'identifiant note. Cette dernière n'aura donc pas été traitée par tous les terminaux du réseau PAN, mais uniquement par le terminal de poids le plus fort. On notera que plusieurs équipements peuvent 10 présenter un même poids maximum dans le réseau : dans ce cas, la notification d'événement est restituée à l'utilisateur par cette pluralité d'équipements de poids le plus élevé. On notera également que, selon ce principe, dans la configuration particulière de deux sous-réseaux PAN de la figure 3, la gestion de la notification d'événement d'identifiant note serait assurée concomitamment par l'ordinateur portable 5 et par la montre connectée 2, qui 15 sont les équipements de poids le plus fort de leurs sous-réseaux respectifs. On présente désormais, en relation avec la figure 5, la succession plus précise des états et des traitements effectués par un équipement de communication du réseau de la figure 2, dans un mode de réalisation de l'invention. Les différents terminaux du réseau s'activent sur réception d'un message MSG associé à 20 l'événement à notifier. Ce message peut être : - la notification elle-même, d'identifiant notif#, qui déclenche un traitement référencé 100 par l'équipement, illustré plus en détail en figure 6; - une requête de notification NOTIF_REQ, dont le traitement référencé 200 est illustré en figure 7; 25 - une réponse à notification NOTIF_REP, dont le traitement référencé 300 est illustré en figure 8; - un acquittement de notification NOTIF_ACK, dont le traitement 400 est illustré en figure 9. La figure 6 illustre le comportement 100 d'un terminal X après réception 000 d'une 30 notification d'événement d'identifiant notif#. Dans une première étape 103, la liste des équipements, IstEQ, avec l'ensemble des équipements appartenant au réseau est initialisée. Puis, à l'étape 105, le terminal X teste s'il a reçu un acquittement de notification NOTIF_ACK pour cette notification d'identifiant notif#. Dans l'affirmative, le traitement par l'équipement de communication X prend fin à l'étape 140, car la notification a déjà été acquittée (par exemple, un 13 équipement prioritaire a déjà pris en charge la notification plus rapidement). Dans le cas contraire, le terminal X passe à l'étape 110. Dans cette étape 110, le terminal X teste s'il a reçu une requête de notification NOTIF_REQ de la part d'un autre terminal noté Y : dans l'affirmative, il passe à l'étape 130, au 5 cours de laquelle il détermine si le poids du terminal Y est supérieur au poids du terminal X; sinon il passe à l'étape 120. En effet, afin de limiter le nombre d'envoi de messages de type NOTIF_REQ sur le réseau, l'équipement qui reçoit la notification n'émet systématiquement de NOTIF_REQ que s'il n'en a pas lui-même reçu. Si, au cours du test de l'étape 130, on détermine que le poids du terminal Y est supérieur 10 au poids du terminal X, alors le terminal X n'est pas prioritaire pour la prise en charge de la notification : un autre équipement prioritaire (par exemple le terminal Y, mais pas nécessairement) traite la notification, et le traitement mis en eouvre par le terminal X prend fin à l'étape 140. Si, au contraire, le poids du terminal X est supérieur au poids du terminal Y, alors il passe à l'étape 120. Cette condition, testée à l'étape 130, permet de vérifier si un équipement 15 prioritaire (i.e. de poids plus élevé) a déjà reçu la notification. Lors de l'étape 120, mise en oeuvre lorsque les conditions 110 ou 130 ne sont pas remplies, le terminal X envoie un message de type requête de notification contenant son identifiant IdEQx, le numéro note de la notification en cours de traitement, ainsi que son poids Px à tous les autres équipements du réseau. 20 A l'étape 150, il teste ensuite la réception d'une réponse de notification NOTIF_REP de la part des autres terminaux du réseau. Si le terminal ne reçoit pas de réponse NOTIF_REP au message envoyé à l'étape 120 à la fin du délai prévu à l'étape 160 pour traiter la notification, alors c'est qu'aucun des autres équipements du réseau n'est à même d'afficher la notification et le terminal X sera donc en charge de la gestion de la notification note et l'affichera au cours d'une 25 étape référencée 190. Si au contraire le terminal X reçoit une réponse de notification NOTIF_REP, c'est qu'un équipement de poids plus élevé va traiter la notification d'événement note. Dans ce cas, à l'étape 180, le terminal X attend de recevoir un acquittement de notification NOTIF_ACK qui confirme que la notification a bien été prise en compte par l'utilisateur. Dans ce cas, le traitement par l'équipement X prend fin au cours de l'étape 140. 30 Si l'équipement X ne reçoit pas d'acquittement NOTIF_ACK à la requête de notification NOTIF_REQ envoyé à l'étape référencée 120, il attend, soit de recevoir finalement l'acquittement, soit la fin du délai prévu à l'étape 170 pour réémettre une requête de notification NOTIF_REQ. Si, à l'issue du temps d'attente prévu à l'étape 170, l'équipement X n'a pas reçu d'acquittement de notification NOTIF_ACK au message envoyé à l'étape 120, alors le traitement 35 reprend à l'étape 120, avec un nouvel envoi de requête de notification NOTIF_REQ à tous les 14 équipements de la liste IstEQ après suppression à l'étape 199 de l'équipement Y le plus fort de cette liste IstEQ (basé sur les poids Py reçus dans les messages NOTIF_REQ, NOTIF_REP). On notera qu'en jouant sur les temps d'attente (paramétrables de la seconde à la minute environ) des étapes référencées 160 et 170, le procédé de gestion selon un mode de réalisation 5 de l'invention permet la notification de manière séquentielle depuis les équipements prioritaires vers les moins importants dans l'hypothèse d'une défaillance de ceux-ci ou bien dans l'impossibilité de l'utilisateur d'acquitter les notifications sur certains terminaux, tout en maximisant les chances que la notification soit traitée. La figure 7 présente le comportement d'un terminal X après réception 000 d'un message 10 de type requête de notification NOTIF_REQ envoyé par un autre terminal Y: . Dans une étape 210, le message reçu du terminal Y est mémorisé par l'équipement X, dans une unité mémoire, de façon à pouvoir permettre la vérification de l'étape 110 illustrée dans la figure 6. Après réception et mémorisation du message , les poids des terminaux X et Y sont comparés au cours d'une 15 étape 220. Cette étape 220 permet de vérifier si l'équipement qui a émis la requête en premier est prioritaire ou non. Si la condition Px>Py de l'étape 220 est remplie (le terminal X a un poids supérieur à celui du terminal Y), alors l'équipement Y qui a émis la requête de notification NOTIF_REQ n'est pas prioritaire, et le terminal X envoie donc en réponse à cette requête une réponse de notification 20 au terminal Y, au cours de l'étape 240. Cette étape de traitement 200 prend alors fin à l'étape 230. Dans le cas contraire, le terminal X ayant reçu la requête NOTIF_REQ a un poids inférieur au terminal Y ayant émis cette requête NOTIF_REQ: le terminal X n'est donc pas prioritaire, et ne va donc pas prendre en charge la notification d'événement note. Cette étape de traitement 200 25 prend alors fin à l'étape 230. La figure 8 présente le comportement 300 d'un terminal X après réception 000 d'un message de type réponse de notification NOTIF_REP envoyé par un autre terminal Y : . Au cours d'une étape 310, le terminal X mémorise le message NOTIF_REP reçu, de façon à permettre la vérification de l'étape 150 illustrée en figure 6. Cette 30 étape de traitement 300 prend ensuite fin à l'étape 320. En effet, si le terminal X reçoit un message NOTIF_REP, c'est que ce n'est pas un équipement prioritaire, puisqu'un autre équipement Y lui a adressé une réponse de notification : il ne va donc pas prendre en charge la gestion de la notification d'événement. La figure 9 présente le comportement 400 d'un terminal X après réception 000 d'un 35 message d'acquittement de notification en provenance d'un 15 terminal Y. Dans une étape 410, le message reçu est mémorisé, dans une unité de mémorisation de l'équipement X, de façon à permettre la vérification de l'étape 180 de la figure 6. L'algorithme prend fin dans une étape 420, puisqu'un équipement prioritaire, ou un équipement ayant reçu en premier la notification dont l'utilisateur a pris connaissance immédiatement, a déjà pris en charge 5 la notification d'événement note. On notera enfin qu'un équipement X du réseau PAN peut également être activé, et donc interagir avec les autres équipements de son environnement, quand l'utilisateur acquitte à l'étape 510 une notification d'événement via l'interface utilisateur de l'équipement X, comme illustré en figure 10. C'est le cas par exemple lorsqu'un terminal reçoit une notification d'événement et que 10 l'utilisateur en prend connaissance et l'acquitte avant que le terminal n'ait eu le temps d'envoyer une requête de notification NOTIF_REQ aux autres terminaux du réseau. Dans une étape 520, l'équipement X envoie alors un acquittement de notification à tous les équipements du réseau PAN, afin de leur faire savoir que la notification a déjà été prise en compte et acquittée par l'utilisateur, puis l'algorithme prend 15 fin au cours d'une étape 530. On présente désormais, en relation avec la figure 11, la structure matérielle d'un équipement de communication du réseau de la figure 2, selon un mode de réalisation de l'invention. Il comprend, classiquement, des mémoires M associées à un processeur CPU. Les 20 mémoires peuvent être de type ROM (de l'anglais « Read Only Memory ») ou RAM (de l'anglais « Random Access Memory ») ou encore Flash. L'équipement de communication 10 communique via le module de communication local COM (selon la technologie WiFi® ou Bluetooth® par exemple) avec les autres équipements de communication du réseau PAN de la figure 2. Ce module de communication local COM forme notamment unité de réception des messages MSG 25 associés aux événements. L'équipement de communication 10 comprend en outre un module de détermination DET d'une liste des équipements appartenant au réseau d'équipement PAN qui peut utiliser le protocole AODV dans un mode de réalisation de l'invention. Cette liste IstEQ peut être enregistrée par exemple dans les mémoires M de l'équipement 10. L'équipement de communication 10 comprend également un module d'évaluation [VAL 30 d'un niveau de priorité associé à l'équipement au sein du réseau PAN, qui opère notamment une comparaison du poids de l'équipement, et du poids des autres équipements du réseau. Ce module d'évaluation [VAL pilote le module GEST de gestion de la notification d'événement, de façon que l'équipement ne prenne en charge les notifications que lorsque le module d'évaluation [VAL a déterminé que l'équipement était associé au niveau de priorité le plus élevé au sein du 35 réseau. 16 L'équipement 10 selon l'invention peut aussi contenir d'autres modules liés à ses fonctionnalités d'équipement de communication, qui ne seront pas décrits ici plus en détails, et notamment un module d'interface E/S, pour interactions avec l'utilisateur et affichage de la notification d'événement lorsqu'elle est prise en charge par l'équipement. 5 On notera que le terme module, ou unité, peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en oeuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. 10 De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.). Plus généralement, un tel équipement de communication 10 comprend une mémoire vive (par exemple une mémoire RAM), une unité de traitement équipée par exemple d'un processeur 15 CPU, et pilotée par un programme d'ordinateur, représentatif du module de gestion de notification d'événement, stocké dans une mémoire morte (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive avant d'être exécutées par le processeur CPU de l'unité de traitement. La mémoire vive contient notamment la liste des équipements du réseau PAN et 20 les poids de l'ensemble des équipements. Le processeur de l'unité de traitement pilote la réception de messages et l'émission de messages vers les autres équipements du réseau, l'évaluation du niveau de priorité de l'équipement, et plus généralement l'ensemble des traitements illustrés dans les figures 5 à 10. La figure 11 illustre seulement une manière particulière, parmi plusieurs possibles, de 25 réaliser l'équipement de communication 10, afin qu'il effectue les étapes du procédé détaillé ci- avant, en relation avec les figures 5 à 10 (dans l'un quelconque des différents modes de réalisation, ou dans une combinaison de ces modes de réalisation). En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence 30 d'instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel). La technique de gestion de notification d'événement présentée ci-avant en relation avec les figures 1 à 11 présente de nombreux avantages en termes de réduction des nuisances occasionnées par la multiplicité des notifications au sein d'un même réseau personnel 35 d'équipements de communication, tout en offrant une efficacité d'accès aux notifications pour 17 l'utilisateur. En outre, elle offre une solution fonctionnelle, même si certains équipements du réseau PAN n'implémentent pas une telle technique de gestion. En effet un équipement du réseau non compatible avec la technique de gestion selon un mode de réalisation de l'invention affichera la notification dès sa réception et ne traitera pas les requêtes de type NOTIF_REQ : il se 5 comportera donc comme un autre équipement prioritaire. Le déploiement de la solution peut donc se faire de façon progressive. Le nombre d'équipements au sein du réseau, ainsi que leur poids peut changer en fonction des besoins de l'utilisateur. Dans l'hypothèse, où l'utilisateur souhaite afficher la notification sur plusieurs équipements, il lui suffit de positionner le poids maximal sur ces 10 derniers. On notera que la technique de gestion de notification d'événement selon un mode de réalisation de l'invention trouve également application, en dehors des réseaux personnels d"équipements, dans les réseaux d'objets connectés ou loT, REVENDICATIONS1. Procédé de gestion de notification d'événement par un équipement appartenant à un réseau d'équipements de type maillé, caractérisé en ce que, sur réception (000) d'un message (MSG) associé audit événement, il met en oeuvre: - une détermination (103) d'une liste (IstEQ) d'au moins un équipement appartenant audit réseau d'équipements de type maillé ; - une évaluation d'un niveau de priorité associé audit équipement au sein dudit réseau maillé ; - si le niveau de priorité évalué est le niveau de priorité le plus élevé de ladite liste, une gestion (190) de ladite notification d'événement par ledit équipement. 2. Procédé de gestion selon la revendication 1, caractérisé en ce que ladite évaluation d'un niveau de priorité associé audit équipement met en oeuvre une comparaison d'un poids (Px) associé audit équipement et d'une information relative à un poids (Py) associé à au moins un autre équipement dudit réseau maillé, et en ce que ledit niveau de priorité le plus élevé est associé à l'équipement dudit réseau maillé associé au poids le plus fort. 3. Procédé de gestion selon la revendication 2, caractérisé en ce que ledit poids (Px) associé audit équipement est paramétrable par un utilisateur et/ou en fonction d'un horaire et/ou en fonction d'une information contextuelle associée à l'utilisateur. 4. Procédé de gestion selon la revendication 2, caractérisé en ce que ladite information relative à un poids (Py) associé à au moins un autre équipement dudit réseau maillé est extraite d'un message (NOTIF_REP, NOTIF_REQ) reçu dudit au moins un autre équipement et/ou déduite d'une absence de réception de message en provenance dudit au moins un autre équipement. 5. Procédé de gestion selon l'une quelconque des revendications 1 à 4, caractérisé en ce que, lorsque ledit message associé audit événement est ladite notification d'événement, il met en oeuvre une émission (120), vers lesdits équipements dudit réseau maillé, d'une requête de notification (NOTIF_REQ) comprenant : - un identifiant (IdEQ) dudit équipement ; - un identifiant (notif#) de ladite notification d'événement ; - un poids dudit équipement. 6. Procédé de gestion selon la revendication 5, caractérisé en ce que, lorsque ledit message associé audit événement est une requête de notification (NOTIF_REQ) reçue d'un autre équipement dudit réseau maillé, il met en oeuvre : 19 - une comparaison (220) du poids (Py) dudit autre équipement ayant émis ladite requête de notification reçue et du poids (Px) dudit équipement ; - si le poids dudit équipement est supérieur au poids dudit autre équipement ayant émis ladite requête de notification reçue, une émission d'une réponse à notification 5 (NOTIF_REP) comprenant : - un identifiant (IdEQx) dudit équipement ; - un identifiant (note) de ladite notification d'événement ; - un poids (Px) dudit équipement. 7. Procédé de gestion selon les revendications 5 et 6, caractérisé en ce que, si, après 10 émission de ladite requête de notification, ledit équipement ne reçoit aucune réponse à notification en provenance d'un desdits équipements dudit réseau maillé, il détermine qu'il est associé audit niveau de priorité le plus élevé et met en oeuvre ladite gestion (190) de ladite notification d'événement. 8. Procédé de gestion selon la revendication 6, caractérisé en ce que, lorsque ledit message 15 associé audit événement est une réponse à notification (NOTIF_REP) reçue d'un autre équipement dudit réseau maillé, il met en oeuvre une vérification de réception d'un message d'acquittement de ladite notification (NOTIF_ACK) et, en l'absence de réception dudit message d'acquittement à l'issue d'une période d'attente (170) de durée déterminée, une mise à jour (199) de ladite liste par suppression dudit équipement associé au poids le plus fort. 20 9. Produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en oeuvre d'un procédé selon l'une quelconque des revendications 1 à 8, lorsqu'il est exécuté par un processeur. 10. Equipement de communication appartenant à un réseau d'équipements de type maillé, comprenant des moyens de gestion de notification d'événement, 25 caractérisé en ce que lesdits moyens de gestion de notification d'événement comprennent : - une unité (COM) de réception d'un message associé audit événement ; - un module (DET) de détermination d'une liste d'au moins un équipement appartenant audit réseau d'équipements de type maillé ; - un module ([VAL) d'évaluation d'un niveau de priorité associé audit équipement au 30 sein dudit réseau maillé ; - un module (GEST) de gestion de ladite notification d'événement par ledit équipement, apte à être activé si le niveau de priorité évalué par ledit module d'évaluation est le niveau de priorité le plus élevé de ladite liste.