FR 3117289 A1 20220610 FR 2012908 A 20201209 La présente invention concerne un procédé et un dispositif de détection d’incidents dans un réseau local par un dispositif de détection d’incidents, le dispositif de détection d’incidents étant relié au réseau local par l’intermédiaire d’un réseau étendu, un agent de collecte de données collectant des données descriptives du réseau local. L’invention est apte à détecter différents types d’anomalies et : - réceptionne (E50) des messages de l’agent de collecte, valide et agrège des données comprises dans chaque message reçu en groupes de données, - calcule (E51) un score de sévérité pour chaque groupe de données, pour chaque type d’anomalies et calcule un score de sévérité totale pour chaque groupe de données, - calcule (E53) sur l’ensemble des scores de sévérité totale un score de criticité totale, - génère (E54) des messages de recommandations ou d’actions correctives au moins à partir du score de criticité totale. Fig. 5 PROCEDE ET SYSTEME DE DETECTION D’INCIDENTS DANS AU MOINS UN RESEAU LOCAL DE COMMUNICATION ETAT DE LA TECHNIQUE ANTERIEURE Les réseaux locaux à l’origine principalement implantés dans des entreprises se sont développés de manière très importante dans les habitations. Ces réseaux locaux, qu’ils soient filaires et/ou sans fils permettent à des usagers d’accéder aux services proposés par des réseaux étendus tels que par exemple le réseau internet. Les services sont par exemple proposés par des fournisseurs d’accès internet qui en outre fournissent au moins en partie les différents éléments qui permettent la constitution du réseau local. Lorsqu’un incident survient dans un réseau local, les usagers de ce réseau local font appel aux services techniques de l’opérateur afin que l’incident soit solutionné. Pour se différencier et capter plus de valeur dans ce marché hautement concurrentiel, les fournisseurs d’accès internet doivent offrir la meilleure expérience numérique à domicile en étant capables de rapidement diagnostiquer un incident et de pouvoir résoudre celui-ci le plus rapidement possible. Le diagnostic et la résolution d’un incident à distance offrent cette rapidité. A cette fin, selon un premier aspect, l’invention propose un procédé de détection d’incidents dans un réseau local par un dispositif de détection d’incidents, le dispositif de détection d’incidents étant relié au réseau local par l’intermédiaire d’un réseau étendu, le réseau local comportant un agent de collecte de données collectant des données descriptives des connexions entre des stations et des nœuds du réseau local et des données descriptives des connexions entre les nœuds, caractérisé en ce que le dispositif de détection d’incidents est apte à détecter différents types d’anomalies et en ce que le procédé comporte les étapes effectuées par le dispositif de détection d’incidents de : - réception de messages de l’agent de collecte, validation et agrégation des données caractéristiques de liens du réseau local comprises dans chaque message reçu en groupes de données, - calcul d’un score de sévérité pour chaque groupe de données, pour chaque type d’anomalie et calcul d’un score de sévérité totale pour chaque groupe de données, - calcul sur l’ensemble des scores de sévérité totale des groupes de données agrégés pendant une durée prédéterminée d’un score de criticité totale, la durée prédéterminée étant telle qu’une pluralité de groupes de données sont agrégés pendant la durée prédéterminée, - génération de messages de recommandations ou d’actions correctives au moins à partir du score de criticité totale. L’invention concerne aussi un dispositif de détection d’incidents dans un réseau local, le dispositif de détection d’incidents étant relié au réseau local par l’intermédiaire d’un réseau étendu, le réseau local comportant un agent de collecte de données collectant des données descriptives des connexions entre des stations et des nœuds du réseau local et des données descriptives des connexions entre les nœuds, caractérisé en ce que le dispositif de détection d’incidents est apte à détecter différents types d’anomalies et en ce que le dispositif de détection d’incidents comporte : - des moyens de réception de messages de l’agent de collecte, validation et agrégation des données caractéristiques de liens du réseau local comprises dans chaque message reçu en groupes de données, - des moyens de calcul d’un score de sévérité pour chaque groupe de données, pour chaque type d’anomalie et calcul d’un score de sévérité totale pour chaque groupe de données, - des moyens de calcul sur l’ensemble des scores de sévérité totale des groupes de données agrégés pendant une durée prédéterminée d’un score de criticité totale, la durée prédéterminée étant telle qu’une pluralité de groupes de données sont agrégés pendant la durée prédéterminée, - des moyens de génération de messages de recommandations ou d’actions correctives au moins à partir du score de criticité totale. Ainsi, la présente invention permet de diagnostiquer rapidement un incident et de pouvoir résoudre celui-ci le plus rapidement possible à distance. Selon un mode particulier de l’invention, le procédé comporte en outre une étape de calcul de la moyenne des scores de sévérités totales pondérés par la durée des groupes des données pour obtenir un score de santé du réseau local. Selon un mode particulier de l’invention, les recommandations ou actions correctives sont en outre générées à partir du score de santé totale. Selon un mode particulier de l’invention, le réseau local est composé d’éléments et des scores de sévérités, des scores de sévérité totale, des scores de criticité totale et des scores de santé sont calculés pour au moins une partie des éléments du réseau local. Selon un mode particulier de l’invention, les recommandations ou actions correctives sont en outre générées à partir des scores calculés pour la au moins une partie du réseau local. Selon un mode particulier de l’invention, les données sont agrégées en partitionnant les données selon une périodicité prédéterminée, si, dans une partition, aucun changement de caractéristique de fonctionnement d’un lien n’apparaît, un groupe de données est formé, le groupe de données comprenant l’ensemble des données de la partition et dans chaque partition, à chaque changement d’au moins une caractéristique de fonctionnement d’un lien, un groupe de données est formé, qui comprend les données de la partition correspondant à la caractéristique de fonctionnement du lien. Selon un mode particulier de l’invention, la caractéristique de fonctionnement du lien est une bande de fréquence, un canal, un protocole de communication. Selon un mode particulier de l’invention, la valeur du score de sévérité est bornée par la valeur 0 et la valeur 1. Ainsi la présente invention permet de combiner aisément différents scores de sévérité. Selon un mode particulier de l’invention, chaque score de sévérité totale est borné par la valeur 0 et la valeur 1 et est égale à la valeur 1 dès qu’un score de sévérité est égal à 1. Ainsi, le score de sévérité totale reflète une anomalie sévère. Selon un mode particulier de l’invention, chaque score de criticité totale est calculé à partir de la somme des scores de sévérités totales pondérés par la durée des groupes des données. Selon un mode particulier de l’invention, les recommandations sont des invitations à rapprocher une station d’un nœud du réseau local ou à ajouter un nœud dans le réseau local ou à déplacer un nœud du réseau local ou de modifier un canal à utiliser de modifier des seuils d’algorithmes locaux qui engendrent les changements de canaux ou à supprimer des sources de bruit ou à restaurer une configuration du protocole de communication et les actions correctives sont des modification de canaux ou des modifications de seuils d’algorithmes locaux qui engendrent les changements de canaux. La présente invention concerne aussi un produit programme d’ordinateur. Il comprend des instructions pour implémenter, par un dispositif nœud, le procédé selon l’un des modes de réalisation précédents, lorsque ledit programme est exécuté par un processeur du dispositif nœud. La présente invention concerne aussi un support de stockage. Il stocke un programme d’ordinateur comprenant des instructions pour implémenter, par un dispositif nœud, le procédé selon l’un des modes de réalisation précédents, lorsque ledit programme est exécuté par un processeur du dispositif nœud. Les caractéristiques de l'invention mentionnées ci-dessus, ainsi que d'autres, apparaîtront plus clairement à la lecture de la description suivante d'un exemple de réalisation, ladite description étant faite en relation avec les dessins joints, parmi lesquels : illustre schématiquement un système de télécommunication dans lequel la présente invention est implémentée ; illustre schématiquement un exemple d’architecture matérielle d’un dispositif de détection d’incidents dans au moins un réseau local ; illustre schématiquement un exemple d’agrégation de données selon la présente invention ; illustre le principe de calcul de la criticité d’un incident par un module de détection d’incidents et de calcul de scores de criticité ; illustre schématiquement un procédé de détection d’incidents selon la présente invention. EXPOSE DETAILLE DE MODES DE REALISATION La Fig. 1 illustre schématiquement un système de télécommunication dans lequel la présente invention est implémentée. Dans la , un dispositif de détection d’incidents 10 est relié par l’intermédiaire d’un réseau étendu 20 (Wide Area Network en anglais) à des réseaux locaux 40 (LAN en anglais). Par exemple les réseaux locaux 40 sont des réseaux domestiques filaire et/ou sans fils. Seulement deux réseaux domestiques 40a et 40b sont représentés en par souci de simplification. Dans un exemple particulier, les réseaux locaux 40a et 40b sont des réseaux sans fils de type Wi-Fi. Dans l’exemple de la , un seul dispositif de détection d’incidents 10 est représenté. Le dispositif de détection d’incidents est dans un nuage informatique appelé CLOUD en anglais. Les différents éléments constitutifs du dispositif de détection d’incidents 10 peuvent être répartis dans différents dispositifs informatiques compris dans le nuage informatique. Le réseau étendu 20 est par exemple un réseau de type internet. Dans l’exemple de la , le réseau local 40a comporte deux stations 42a, 42b et un point d’accès ou nœud relié au réseau étendu qui fait office d’agent de collecte 41de données dans le réseau local 40a. Le réseau local 40b comporte deux stations 42a’, 42b’ et un point d’accès relié au réseau étendu qui fait office d’agent 41’ de collecte de données dans le réseau local 40b. Les points d’accès sont par exemple des passerelles entre le réseau étendu 20 et les réseaux locaux 40a ou 40b. Il est à remarquer ici que chaque nœud peut collecter des données dans le réseau local 40. L’implantation du point d’accès, et des stations dans un logement peut être génératrice d’incidents, comme la taille, la constitution du logement, et le nombre de stations. De même, dans un réseau local sans fil de type Wi-Fi, des interférences avec des réseaux adjacents ou des dispositifs émettant des ondes radio électriques dans une même bande de fréquence peuvent apparaître. L’utilisation dans un même réseau local de plusieurs services tels que la lecture en continu (streaming en anglais), la domotique, la télévision sur internet, les jeux en ligne, l’internet des objets, etc. peut aussi perturber certains de ces services. Le ou chaque agent de collecte obtient des données descriptives des connexions entre des stations et des nœuds du réseau local et des données descriptives des connexions entre les nœuds liées à la qualité et à l’usage du réseau local. Ces données sont collectées à intervalles réguliers et sont stockées localement au niveau de chaque nœud. Ces données sont ensuite envoyées, à intervalles réguliers, par chaque nœud à l’agent de collecte qui groupe celles-ci en un seul message qui est transmis vers le dispositif de détection d’incidents 10 par l’intermédiaire du réseau étendu. En variante, les données peuvent être collectées au niveau d’un nœud central, tel qu’une passerelle internet comprenant l’agent de collecte, groupées en un seul message qui est envoyé au dispositif de détection d’incidents 10. Les données collectées sont par exemple mais non limitativement, la liste des nœuds du réseau local et leur fonction, par exemple, passerelle internet, répéteur Wi-Fi, boîtier décodeur ainsi que leurs données descriptives, par exemple la version logicielle, l’adresse IP, l’adresse MAC, le ou les standards Wi-Fi supportés, la bande Wi-Fi utilisée. Les données collectées sont par exemple mais non limitativement la liste des connexions ou liens entre les stations et les nœuds, la liste des connexions entre les nœuds ainsi que leurs données descriptives, par exemple un horodatage, une puissance du signal ou RSSI (acronyme du terme en anglais Received Signal Strength Indicator), un niveau du bruit, un volume d’octets envoyés et/ou reçus, l’utilisation du ou des canaux radio, la bande de fréquence, le nombre de paquets transmis et/ou reçus et/ou perdus et/ou retransmis. D’autres métriques représentatives du fonctionnement nominal de chacun des équipements, tels que les nœuds ou les stations dans le réseau local, peuvent être également envisagées. Par ailleurs, ces équipements peuvent être connectés via la technologie sans fil de type Wi-Fi, mais aussi une technologie de type BlueTooth, ou une technologie d’accès filaire telle que Ethernet ou par courant porteur de ligne. Dans un exemple, une métrique représentative de la consommation en énergie d’un équipement peut être collectée. Dans un autre exemple, une métrique de vitesse de lien Ethernet 10 Mbps / 100 Mbps / 1000 Mbps peut également être collectée. Les données collectées sont agrégées en un message et sont envoyées par exemple dans un format JSON (acronyme de JavaScript Object Notation en utilisant un protocole de communication, tel que par exemple, le protocole HTTP (Hypertext Transfer Protocol) ou MQTT (Message Queuing Telemetry Transport). Il est à remarquer ici qu’en variante, le message est envoyé à des instants prédéterminés et/ou à la demande du dispositif de détection d’incidents 10. Le dispositif de détection d’incidents 10 comporte un module de réception, validation et d’agrégation des données 11 qui reçoit et traite chaque message reçu. Le module de réception, validation et d’agrégation des données 11 valide le contenu de chaque message reçu par exemple en vérifiant si le format du message reçu est conforme, si les valeurs des informations comprises dans le message reçu sont dans une plage de valeur cohérente et si le réseau local dont est issu le message fait partie de l’ensemble des réseaux locaux géré par le dispositif de détection d’incidents 10. Dans l’affirmative, le module de réception, validation et d’agrégation des données 11 agrège en groupes de données les données descriptives des connexions entre les stations et les nœuds et les données descriptives des connexions entre les nœuds. Par exemple, les données sont partitionnées selon une périodicité prédéterminée, par exemple égale à 10mn. Si, dans une partition, aucun changement de caractéristique de fonctionnement d’un lien n’apparaît, un groupe de données est formé, le groupe de données comprenant l’ensemble des données de la partition. Dans chaque partition, à chaque changement d’au moins une caractéristique de fonctionnement d’un lien, un groupe de données est formé, qui comprend les données de la partition correspondant à la bande de fréquence, au canal et au protocole de communication. Une caractéristique de fonctionnement d’un lien est par exemple et non limitativement, la bande de fréquence, le canal et le protocole de communication tel que par exemple le protocole Wi-Fi Plus précisément, un groupe de données comporte des données, pendant une durée de 10 mn, obtenues pour la bande de fréquence et le canal et le protocole de communication utilisés pendant ladite période prédéterminée. Un groupe de données comporte, pendant une durée d’utilisation de la même bande de fréquence, du même canal et du même protocole de communication utilisé, les données obtenues pour la bande de fréquence et le canal et le protocole de communication utilisés. Un exemple d’agrégation est donné en référence à la . La illustre schématiquement un exemple d’agrégation de données selon la présente invention. Dans l’exemple de la , les données reçues pendant les dix premières minutes notées 0 à 9 ne sont pas obtenues pour la même bande de fréquence, pour le même canal et pour le même protocole de communication utilisé, deux groupes notés G1 et G2 sont formés. Le groupe G1 comporte les données obtenues sur la bande de fréquence 2,4 GHz, le canal 1 et le protocole 802.11g. Le groupe G2 comporte les données obtenues sur la bande de fréquence 2,4 GHz, le canal 6 et le protocole 802.11g. Les données reçues pendant les dix minutes suivantes notées 10 à 19 sont obtenues pour la même bande de fréquence, pour le même canal et pour le même protocole de communication utilisé. Le groupe G3 est formé. Le groupe G3 comporte les données obtenues sur la bande de fréquence 2,4 GHz, le canal 6 et le protocole 802.11g. Les groupes servent ainsi à lisser les données envoyées par les nœuds en les agrégeant. Pour chaque groupe de données, on calcule la variation des compteurs de volumes d’octets et de paquets au sein du groupe, ainsi que le minimum, le maximum et la moyenne d’un certain nombre de métriques telles que par exemple le RSSI, le bruit… Le dispositif de détection d’incidents 10 comporte un module de détection d’anomalies et de calcul de scores de sévérité 12. Le module de détection d’anomalies et de calcul de scores de sévérité 12 détecte pour chaque groupe de données et chaque type d’anomalies calcule un score borné entre 0 et 1 appelé sévérité pour les différentes métriques. Le score de sévérité permet d’évaluer l’écart de ces métriques à des valeurs prédéterminées représentatives d’un fonctionnement ou comportement normal. Un score de sévérité de 0 signifie qu’il n’y a pas d’anomalie, un score de sévérité de 1 signifie une perturbation importante sur le lien Wi-Fi pour le groupe. Par exemple, le score de sévérité de l’anomalie de type « couverture Wi-Fi » vaut 0 pour un RSSI supérieur ou égal à -60 dBm et croît linéairement jusqu’à 1 pour un RSSI de -80 dBm et au-delà. En effet, un niveau de RSSI à -60 dBm peut être représentatif d’une bonne qualité de réception de signal par l’une des stations dont les données relatives au RSSI sont incorporées dans l’un des groupes. Un niveau de RSSI perçu à -80 dBm est représentatif d’une réception de signal bruitée par rapport à un niveau de -60 dBm, ce qui peut induire ou dénoter d’une dégradation des transmissions au sein du réseau local 40 Par exemple, le score de sévérité de l’anomalie de type « niveau de bruit » pour un nœud vaut 0 pour un bruit inférieur ou égal à -80 dBm et croît linéairement jusqu’à 1 pour un bruit de -60 dBm et au-delà. Par exemple, le score de sévérité de l’anomalie de type « changement de canal » pour un nœud vaut 0 pour un nombre de changement de canal inférieur ou égal à 2 et croît linéairement jusqu’à 1 pour un nombre de changement de canal supérieur ou égal à 5 pendant une période de temps égale à 30 minutes. Par exemple, le score de sévérité de l’anomalie de type « changement de nœud » pour une station vaut 0 pour un nombre de changement de nœud inférieur ou égal à 2 et croît linéairement jusqu’à 1 pour un nombre de changement de nœud supérieur ou égal à 5 pendant une période de temps égale à 30 minutes. Dans les exemples ci-dessus, les scores de sévérité respectifs sont obtenus par une croissance ou interpolation linéaire présentant l’avantage de la simplicité des calculs pour un volume des données important, les comparaisons de scores de sévérités sont ainsi facilitées. Dans d’autres exemples, les scores de sévérité respectifs sont obtenus conformément à d’autres méthodes ou modes de calcul. Par exemple, le score de sévérité de l’anomalie de type « couverture Wi-Fi » est obtenu selon une table de type « lookup table » dans laquelle pour certaines valeurs de RSSI ou certaines plages de valeurs de RSSI, un score est assigné. Cette table peut être obtenue par exemple en définissant des plages de RSSI de 3 dBm, représentatif d’un niveau de signal perçu divisé par 2 : le score 0 est assigné à la plage [-60 dBm ; -63 dBm[, le score 0,25 est assigné à la plage [-63 dBm ; -66 dBm[, le score 0.5 est assigné à la plage [-66 dBm ; - 69 dBm[, le score 0,75 est assigné à la plage [-69 dBm ; -72 dBm[, le score 0,99 est assigné à la plage [-72 dBm ; -80 dBm]. Sur cette dernière plage, le score de sévérité de 0,99 pour une couverture Wi-Fi dont le RSSI est compris dans cette plage est indicateur que le niveau de réception est trop bruité pour que les transmissions à destination ou à réception de la station soient effectives. Des scores de sévérité sont calculés pour chaque élément du réseau local. Le module de détection d’anomalies et de calcul de scores de sévérité 12 calcule ainsi, pour chaque groupe de données, un score de sévérité pour chaque type d’anomalies. Le module de détection d’anomalies et de calcul de scores de sévérité 12 calcule aussi des scores de sévérité pour un ou plusieurs éléments du réseau local en ne considérant que les données relatives à l’élément du réseau local. Le module de détection d’anomalies et de calcul de scores de sévérité 12 calcule, pour chaque groupe de données, un score de sévérité total à partir des scores de sévérité calculés pour le groupe de données. Pour cela, des lois de composition des scores sont définies : Une première loi d’addition : Avec , , , et est l’opérateur somme directe. où s 1 est par exemple le score de sévérité pour l’anomalie de type « couverture Wi-Fi » et s 2 est par exemple le score de sévérité pour l’anomalie de type « volume d’octets ». Une seconde loi de multiplication , avec et . Le score de sévérité total s’ i est donné par , où n est le nombre d’anomalies s i est le score de sévérité pour l’anomalie de type indexée par l’indice i. L’ensemble et les lois possèdent la plupart des propriétés d’une structure de corps, à l’exception du fait que la loi n’est pas inversible. Les fonctions f - et f + réalisent alors des homéomorphismes respectivement vers et depuis (ℝ, +, x) garantissant les propriétés suivantes : 0* s =0 1* s =1 m *1=1 f - (m * s) =m x f - (s) s m 1 *(m 2 * s)= (m 1 *m 2 )*s m*(s 1 s 2 ) = (m*s 1 ) (m*s 2 ) s 1 s 2 = s 2 s 1 s 1 (s 2 s 3 )= (s 2 s 1 ) s 3 Ce score de sévérité totale est aussi entre 0 et 1, augmente avec les autres scores de sévérité, et est égal à un dès lors qu’un des scores de sévérité est égal à un. Le module de détection d’anomalies et de calcul de scores de sévérité 12 calcule aussi des scores de sévérité totale pour un ou plusieurs éléments du réseau local en ne considérant que les données relatives à l’élément du réseau local. Chaque score de sévérité et de sévérité totale est mémorisé dans une base de données 13. Le dispositif de détection d’incidents 10 comporte un module d’évaluation du fonctionnement des éléments du réseau local 15. Le module d’évaluation du fonctionnement des éléments du réseau local 15 calcule au moins un indicateur de la santé du réseau local et/ou calcule un score de santé respectivement sur un ou plusieurs éléments sur une journée. Un élément est par exemple et non limitativement un nœud, un lien, etc…. Le but de l’indicateur de santé est de construire un score borné pour pouvoir comparer différents réseaux locaux et/ou différents éléments ou différentes plages temporelles sans considérations d’échelle : la santé d’un grand réseau n’a pas à être pénalisée par sa taille, il est normal d’y trouver plus d’anomalies que dans un petit réseau. Le module d’évaluation du fonctionnement des éléments du réseau local 15 utilise avantageusement le score de sévérité total d’un groupe pour calculer un indicateur représentatif de la santé d’un élément en prenant le complémentaire à 1 du score d’anomalies total. Pour un ensemble de groupes, le module d’évaluation du fonctionnement des éléments du réseau local 15 calcule la moyenne des scores de santé pondérés par la durée des groupes. Un score de santé peut être attribué à tout ensemble de groupes de données : un réseau local sur une journée. Ce score de santé est borné entre 0 et 1, et peut donc être transformé vers n’importe quelle échelle d’indicateur de santé (ex. pourcentage, indice entre 1 et 5, etc.). Le score de santé est calculé selon la formule suivante : où t i est la durée de connexion du groupe i , s ’ i le score de sévérité totale du groupe de données. Le module d’évaluation du fonctionnement des éléments du réseau local 15 calcule aussi des scores de santé pour un ou plusieurs éléments du réseau local en ne considérant que les score de sévérité totale relatifs à l’élément du réseau local. Le score de santé permet de représenter/synthétiser visuellement le niveau de santé d’un réseau local et de pouvoir le comparer à d’autres réseaux locaux. Il est par exemple utilisé par l’opérateur qui est en charge d’analyser les performances et le niveau de santé des réseaux locaux à l’échelle d’un parc d’abonnés. Les scores de santé calculés pour des éléments du réseau local permettent de représenter/synthétiser visuellement le niveau de santé d’un élément du réseau local et de pouvoir le comparer à d’autres éléments du réseau local et/ou à des éléments d’autres réseaux locaux. Les données calculées par le module d’évaluation du fonctionnement des éléments du réseau local 15 sont mémorisées dans la base de données 13. Le dispositif de détection d’incidents 10 comporte un module de détection d’incidents et de calcul de scores de criticité 16. Le module de détection d’incidents et de calcul de scores de criticité 16 effectue une analyse journalière afin de détecter des incidents du réseau local et de proposer des recommandations adaptées. Un incident, contrairement aux anomalies, se produit à l’échelle de la journée. En fonction du type d’incident, il peut concerner une station, par exemple lié à une utilisation par la station d’un standard vétuste, un lien Wi-Fi, par exemple une mauvaise transmission de paquets, ou un point d’accès, par exemple un niveau élevé de bruit. Chaque type d’incident est lié à un type d’anomalie. Pour déterminer s’il y a un incident, le module de détection d’incidents et de calcul de scores de criticité 16 calcule sur l’ensemble des groupes concernés la durée de connexion pondérée par la sévérité totale associée. Ce score de criticité, qui s’exprime en secondes, est appelé score de criticité totale : où t i est la durée de connexion du groupe i , s ’ i est le score de sévérité totale de l’anomalie et la sommation est effectuée sur tous les groupes de données affectés par l’incident. Un incident permet ainsi de voir si la criticité liée à une anomalie est problématique sur une journée : celle-ci s’étale dans le temps, avec une sévérité non nulle. On considère qu’il y a effectivement un incident si le score de criticité calculé dépasse une durée de référence, par exemple 600 secondes, soit 10 minutes d’anomalie avec sévérité maximale. La criticité totale est la métrique privilégiée pour mesurer l’impact d’un incident sur le réseau local. Les incidents les plus graves sont ceux qui impactent le plus de liens du réseau local, le plus longtemps, le plus sévèrement. Il est parfois intéressant de considérer le temps d’incidence à la place, c’est-à-dire la durée cumulée de tous les groupes affectés par l’incident. Par construction, la criticité totale 402 est inférieure ou égale au temps d’incidence 401, elle-même inférieure au temps total de connexion sur la journée 400, comme illustré dans la . Par exemple, si le score de criticité totale est supérieur à 40% de la durée totale des connexions, des actions correctives peuvent être effectuées selon le type d’incident. Si l’utilisateur a été impacté plus de 4 heures sur un total de 10 heures de connexions, l’incident est, par exemple considéré comme relativement grave et des actions correctives peuvent être effectuées. Le module de détection d’incidents et de calcul de scores de criticité 16 calcule aussi des scores de criticité totale pour un ou plusieurs éléments du réseau local en ne considérant que les score de sévérité totale relatifs à l’élément du réseau local. Le dispositif de détection d’incidents 10 comporte un module de génération d’actions correctives 14. Le module de génération d’actions correctives 14 génère des recommandations ou des actions correctives pour améliorer le fonctionnement d’un ou plusieurs réseaux locaux. Les recommandations sont par exemple transférées au fournisseur d’accès internet du réseau local et/ou aux utilisateurs du réseau local. Par exemple, le module de génération d’actions correctives 14 identifie le ou les réseaux locaux pour lequel ou lesquels le score de criticité totale est supérieur ou égal à un seuil prédéterminé par exemple égal à 0.4. Les actions correctives peuvent être générées en analysant le score de santé et/ou le score de criticité totale du réseau local et/ou en analysant le score de santé et/ou le score de criticité totale d’un ou plusieurs éléments du réseau local. Les actions correctives représentent des actions qui peuvent être automatisées sur les équipements concernés. Ainsi, le dispositif de détection d’incidents 10 identifie, à partir des scores de criticité totale, par exemple à la fin d’une journée les équipements nécessitant des optimisations et/ou changements de configuration. Le module de génération d’actions correctives 14 ayant identifié le ou les réseaux dont le score de criticité totale et/ou le score de santé est supérieur ou égal au seuil prédéterminé génère des actions correctives en analysant les scores de sévérités mémorisés dans la journée. La liste des actions correctives est envoyée vers ces équipements en utilisant, par exemple, le protocole HTTP (Hypertext Transfer Protocol) ou MQTT (Message Queuing Telemetry Transport). Si un incident de type couverture est détecté, par exemple, en analysant le score de santé et/ou le score de criticité totale du réseau local et/ou en analysant le score de santé et/ou le score de criticité totale d’un ou plusieurs éléments du réseau local et en analysant les scores de sévérité relatifs aux anomalies de type « faible niveau de puissance en réception d'un signal » (RSSI Par exemple, si un problème de mauvais positionnement d’un nœud est détecté, par exemple en analysant les scores de sévérité relatifs au changement de nœud ou de canal, le module de génération d’actions correctives 14 transfère au fournisseur d’accès internet du réseau local et/ou aux utilisateurs du réseau local un message invitant à déplacer un nœud, par exemple un nœud répéteur d’une passerelle internet du réseau local. Si un incident de type changement fréquent de canal au niveau d’un nœud est détecté, par exemple, en analysant le score de santé et/ou le score de criticité totale du réseau local et/ou en analysant le score de santé et/ou le score de criticité totale d’un ou plusieurs éléments du réseau local et en analysant les scores de sévérité relatifs aux anomalies de type « changements fréquents de canal », le module de génération d’actions correctives 14 transfère au fournisseur d’accès internet du réseau local et/ou aux utilisateurs du réseau local un message suggérant aux utilisateurs et/ou aux nœuds de fixer le canal à utiliser et/ou de modifier les seuils des algorithmes locaux qui engendrent les changements de canaux. Par exemple, si un problème de bruit est détecté, par exemple en analysant les scores de sévérité relatifs au niveau du bruit, le module de génération d’actions correctives 14 transfère au fournisseur d’accès internet du réseau local et/ou aux utilisateurs du réseau local un message invitant à déplacer voire supprimer des sources de bruit et/ou, en action corrective, un message notifiant un nœud de changer de bande de fréquence. Si un incident de type bruit est détecté, par exemple, en analysant le score de santé et/ou le score de criticité totale du réseau local et/ou en analysant le score de santé et/ou le score de criticité totale d’un ou plusieurs éléments du réseau local et en analysant les scores de sévérité relatifs aux anomalies de type « niveau de bruit très élevé autour d’un nœud ou stations », le module de génération d’actions correctives 14 transfère au fournisseur d’accès internet du réseau local et/ou aux utilisateurs du réseau local un message suggérant aux utilisateurs et/ou aux nœuds de basculer vers un autre canal et/ou bande wifi où le niveau de bruit est moins élevé. Par exemple, si un incident de type configuration wifi non standard est détecté, par exemple, en analysant le score de santé et/ou le score de criticité totale du réseau local et/ou en analysant le score de santé et/ou le score de criticité totale d’un ou plusieurs éléments du réseau local et en analysant les scores de sévérité relative aux anomalies de type « standards vétustes utilisés », le module de génération d’actions correctives 14 transfère au fournisseur d’accès internet du réseau local et/ou aux utilisateurs du réseau local un message suggérant aux utilisateurs et/ou aux nœuds de restaurer la configuration wifi par défaut. La illustre schématiquement un exemple d’architecture matérielle d’un dispositif de détection d’incidents dans au moins un réseau local. Selon l’exemple d’architecture matérielle représenté à la , le dispositif de détection d’incidents 10 comprend, reliés par un bus de communication 200 : un processeur ou CPU (« Central Processing Unit » en anglais) 201 ; une mémoire vive RAM (« Random Access Memory » en anglais) 202 ; une mémoire morte ROM (« Read Only Memory » en anglais) 203 ; une unité de stockage telle qu’un disque dur (ou un lecteur de support de stockage, tel qu’un lecteur de cartes SD (« Secure Digital » en anglais) 204 ; au moins une interface de communication 505 permettant au dispositif de détection d’incidents 10 de communiquer par l’intermédiaire du réseau étendu 20. Le processeur 201 est capable d’exécuter des instructions chargées dans la RAM 202 à partir de la ROM 203, d’une mémoire externe (non représentée), d’un support de stockage (tel qu’une carte SD), ou d’un réseau de communication. Lorsque le dispositif de détection d’incident 10 est mis sous tension, le processeur 201 est capable de lire de la RAM 202 des instructions et de les exécuter. Ces instructions forment un programme d’ordinateur causant la mise en œuvre, par le processeur 201, de tout ou partie du procédé décrit en relation avec la . Le procédé décrit ci-après en relation avec la peut être implémenté sous forme logicielle par exécution d’un ensemble d’instructions par une machine programmable, par exemple un DSP (« Digital Signal Processor » en anglais) ou un microcontrôleur, ou être implémenté sous forme matérielle par une machine ou un composant dédié, par exemple un FPGA (« Field-Programmable Gate Array » en anglais) ou un ASIC (« Application-Specific Integrated Circuit » en anglais). En général, le dispositif de détection d’incidents 10 comprend de la circuiterie électronique configurée pour mettre en œuvre le procédé décrit en relation avec la . Il est à remarquer ici que la représente une architecture matérielle d’un unique dispositif de détection d’incidents 10. Les différents éléments constitutifs du dispositif de détection d’incidents 10 peuvent être répartis dans différents dispositifs informatiques compris dans le nuage informatique. La illustre schématiquement un procédé de détection d’incidents selon la présente invention. A l’étape E50, le dispositif de détection d’incidents 10 reçoit, valide et agrège chaque message reçu d’un agent de collecte 41. Le dispositif de détection d’incidents 10 valide le contenu de chaque message reçu par exemple en vérifiant si le format du message reçu est conforme, si les valeurs des informations comprises dans le message reçu sont dans une plage de valeur cohérente et si le réseau local dont est issu le message fait partie de l’ensemble des réseaux locaux géré par le dispositif de détection d’incidents 10. Dans l’affirmative, le dispositif de détection d’incidents 10 agrège en groupes de données les données descriptives des connexions entre les stations et les nœuds et les données descriptives des connexions entre les nœuds. Par exemple, les données sont partitionnées selon une périodicité prédéterminée, par exemple égale à 10mn. Si, dans une partition, aucun changement de caractéristique de fonctionnement d’un lien n’apparaît, un groupe de données est formé, le groupe de données comprenant l’ensemble des données de la partition. Dans chaque partition, à chaque changement d’au moins une caractéristique de fonctionnement d’un lien, un groupe de données est formé, qui comprend les données de la partition correspondant à la bande de fréquence, au canal et au protocole de communication. Une caractéristique de fonctionnement d’un lien est par exemple et non limitativement, la bande de fréquence, le canal et le protocole de communication tel que par exemple le protocole Wi-Fi A l’étape E51, le dispositif de détection d’incidents 10 détecte pour chaque groupe, des anomalies en calculant le score borné entre 0 et 1 appelé sévérité pour les différentes métriques. Le score de sévérité permet d’évaluer l’écart de ces métriques à des valeurs prédéterminées représentatives d’un fonctionnement ou comportement normal. Un score de sévérité de 0 signifie qu’il n’y a pas d’anomalie, un score de sévérité de 1 signifie une perturbation importante sur le lien Wi-Fi pour le groupe. Le dispositif de détection d’incidents 10 calcule ainsi, pour chaque groupe de données, un score de sévérité pour chaque type d’anomalies. Le dispositif de détection d’incidents 10 calcule aussi des scores de sévérité pour un ou plusieurs éléments du réseau local en ne considérant que les données relatives à l’élément du réseau local. Le dispositif de détection d’incidents 10 calcule, pour chaque groupe de données, un score de sévérité total à partir des scores de sévérité calculés pour le groupe de données. Ce score de sévérité totale est aussi entre 0 et 1, augmente avec les autres scores de sévérité, et est égal à un dès lors qu’un des scores de sévérité est égal à un. Le dispositif de détection d’incidents 10 calcule aussi des scores de sévérité totale pour un ou plusieurs éléments du réseau local en ne considérant que les données relatives à l’élément du réseau local. Chaque score de sévérité et de sévérité totale est mémorisé dans une base de données 13. A l’étape E52, le dispositif de détection d’incidents 10 calcule au moins un indicateur de la santé du réseau local et/ou calcule un score de santé respectivement sur un ou plusieurs éléments sur une journée. Un élément est par exemple et non limitativement un nœud, un lien, etc…. Le but de l’indicateur de santé est de construire un score borné pour pouvoir comparer différents réseaux locaux et/ou différents éléments ou différentes plages temporelles sans considérations d’échelle : la santé d’un grand réseau n’a pas à être pénalisée par sa taille, il est normal d’y trouver plus d’anomalies que dans un petit réseau. Le dispositif de détection d’incidents 10 utilise avantageusement le score de sévérité totale d’un groupe pour calculer un indicateur représentatif de la santé d’un élément en prenant le complémentaire à 1 du score de sévérité totale. Pour un ensemble de groupes, le dispositif de détection d’incidents 10 calcule la moyenne des scores de santé pondérés par la durée des groupes. Un score de santé peut être attribué à tout ensemble de groupes de données : un réseau local sur une journée. Ce score de santé est borné entre 0 et 1, et peut donc être transformé vers n’importe quelle échelle d’indicateur de santé (ex. pourcentage, indice entre 1 et 5, etc.). Le score de santé est calculé selon la formule suivante : où t i est la durée de connexion du groupe i , s’ i le score de sévérité totale du groupe de données. Le dispositif de détection d’incidents 10 calcule aussi des scores de santé pour un ou plusieurs éléments du réseau local en ne considérant que les scores de sévérité totale relatifs à l’élément du réseau local. Le score de santé permet de représenter/synthétiser visuellement le niveau de santé d’un réseau local et de pouvoir le comparer à d’autres réseaux locaux. Il est par exemple utilisé par l’opérateur qui est en charge d’analyser les performances et le niveau de santé des réseaux locaux à l’échelle d’un parc d’abonnés. Les scores de santé calculés pour des éléments du réseau local permettent de représenter/synthétiser visuellement le niveau de santé d’un élément du réseau local et de pouvoir le comparer à d’autres éléments du réseau local et/ou à des éléments d’autres réseaux locaux. A l’étape E53, le dispositif de détection d’incidents 10 calcule des scores de criticité. Le dispositif de détection d’incidents 10 effectue une analyse journalière afin de détecter des incidents du réseau local et de proposer des recommandations adaptées. Un incident, contrairement aux anomalies, se produit à l’échelle de la journée. En fonction du type d’incident, il peut concerner une station, par exemple lié à une utilisation par la station d’un standard vétuste, un lien Wi-Fi, par exemple une mauvaise transmission de paquets, ou un point d’accès, par exemple un niveau élevé de bruit. Chaque type d’incident est lié à un type d’anomalie. Pour déterminer s’il y a un incident, le module de détection d’incidents et de calcul de scores de criticité 16 calcule sur l’ensemble des groupes concernés la durée de connexion pondérée par la sévérité totale associée. Ce score de criticité, qui s’exprime en secondes, est appelé score de criticité totale : où t i est la durée de connexion du groupe i , s’ i est le score de sévérité totale de l’anomalie et la sommation est effectuée sur tous les groupes de données affectés par l’incident. Un incident permet ainsi de voir si la criticité liée à une anomalie est problématique sur une journée : celle-ci s’étale dans le temps, avec une sévérité non nulle. On considère qu’il y a effectivement un incident si le score de criticité calculé dépasse une durée de référence, par exemple 600 secondes, soit 10 minutes d’anomalie avec sévérité maximale. La criticité totale est la métrique privilégiée pour mesurer l’impact d’un incident sur le réseau local. Les incidents les plus graves sont ceux qui impactent le plus de liens du réseau local, le plus longtemps, le plus sévèrement. Il est parfois intéressant de considérer le temps d’incidence à la place, c’est-à-dire la durée cumulée de tous les groupes affectés par l’incident. Par construction, la criticité totale 402 est inférieure ou égale au temps d’incidence 401, elle-même inférieure au temps total de connexion sur la journée 400, comme illustré dans la . Par exemple, si le score de criticité totale est supérieur à 40% de la durée totale des connexions, des actions correctives peuvent être effectuées selon le type d’incident. Si l’utilisateur a été impacté plus de 4 heures sur un total de 10 heures de connexions, l’incident est, par exemple considéré comme relativement grave et des actions correctives peuvent être effectuées. Le module de détection d’incidents et de calcul de scores de criticité 16 calcule aussi des scores de criticité totale pour un ou plusieurs éléments du réseau local en ne considérant que les scores de sévérité totale relatifs à l’élément du réseau local. A l’étape E54, le dispositif de détection d’incidents 10 génère des recommandations ou des actions correctives pour améliorer le fonctionnement d’un ou plusieurs réseaux locaux. Les recommandations sont par exemple transférées au fournisseur d’accès internet du réseau local et/ou aux utilisateurs du réseau local. Par exemple, le dispositif de détection d’incidents 10 identifie le ou les réseaux locaux pour lequel ou lesquels le score de criticité totale est supérieur ou égal à un seuil prédéterminé par exemple égal à 0.4. Les actions correctives peuvent être générées en analysant le score de santé et/ou le score de criticité totale du réseau local et/ou en analysant le score de santé et/ou le score de criticité totale d’un ou plusieurs éléments du réseau local. Les actions correctives représentent des actions qui peuvent être automatisées sur les équipements concernés. Ainsi, le dispositif de détection d’incidents 10 identifie, à partir des scores de criticité totale, par exemple à la fin d’une journée les équipements nécessitant des optimisations et/ou changements de configuration. Le dispositif de détection d’incidents 10 ayant identifié le ou les réseaux dont le score de criticité totale et/ou le score de santé est supérieur ou égal au seuil prédéterminé génère des actions correctives en analysant les scores de sévérités mémorisés dans la journée. La liste des actions correctives est envoyée vers ces équipements en utilisant, par exemple, le protocole HTTP (Hypertext Transfer Protocol) ou MQTT (Message Queuing Telemetry Transport). Par exemple, si un problème de couverture est détecté, par exemple en analysant les scores de sévérité relatifs au niveau du changement de nœud ou de canal, le dispositif de détection d’incidents 10 transfère au fournisseur d’accès internet du réseau local et/ou aux utilisateurs du réseau local un message invitant à rapprocher une station d’un nœud ou à ajouter un nœud dans le réseau local. Si un incident de type couverture est détecté, par exemple, en analysant le score de santé et/ou le score de criticité totale du réseau local et/ou en analysant le score de santé et/ou le score de criticité totale d’un ou plusieurs éléments du réseau local et en analysant les scores de sévérité relatifs aux anomalies de type « faible niveau de puissance en réception d'un signal » (RSSI Par exemple, si un problème de mauvais positionnement d’un nœud est détecté, par exemple en analysant les scores de sévérité relatifs au changement de nœud ou de canal, le dispositif de détection d’incidents 10 transfère au fournisseur d’accès internet du réseau local et/ou aux utilisateurs du réseau local un message invitant à déplacer un nœud, par exemple un nœud répéteur d’une passerelle internet du réseau local. Si un incident de type changement fréquent de canal au niveau d’un nœud est détecté, par exemple, en analysant le score de santé et/ou le score de criticité totale du réseau local et/ou en analysant le score de santé et/ou le score de criticité totale d’un ou plusieurs éléments du réseau local et en analysant les scores de sévérité relatifs aux anomalies de type « changements fréquents de canal », le dispositif de détection d’incidents 10 transfère au fournisseur d’accès internet du réseau local et/ou aux utilisateurs du réseau local un message suggérant aux utilisateurs et/ou aux nœuds de fixer le canal à utiliser et/ou de modifier les seuils des algorithmes locaux qui engendrent les changements de canaux. Par exemple, si un problème de bruit est détecté, par exemple en analysant les scores de sévérité relatifs au niveau du bruit, le dispositif de détection d’incidents 10 transfère au fournisseur d’accès internet du réseau local et/ou aux utilisateurs du réseau local un message invitant à déplacer voire supprimer des sources de bruit et/ou, en action corrective, un message notifiant un nœud de changer de bande de fréquence. Si un incident de type bruit est détecté, par exemple, en analysant le score de santé et/ou le score de criticité totale du réseau local et/ou en analysant le score de santé et/ou le score de criticité totale d’un ou plusieurs éléments du réseau local et en analysant les scores de sévérité relatifs aux anomalies de type « niveau de bruit très élevé autour d’un nœud ou stations », le dispositif de détection d’incidents 10 transfère au fournisseur d’accès internet du réseau local et/ou aux utilisateurs du réseau local un message suggérant aux utilisateurs et/ou aux nœuds de basculer vers un autre canal et/ou bande wifi où le niveau de bruit est moins élevé. Par exemple, si un incident de type configuration wifi non standard est détecté, par exemple, en analysant le score de santé et/ou le score de criticité totale du réseau local et/ou en analysant le score de santé et/ou le score de criticité totale d’un ou plusieurs éléments du réseau local et en analysant les scores de sévérité relatifs aux anomalies de type « standards vétustes utilisés », le dispositif de détection d’incidents 10 transfère au fournisseur d’accès internet du réseau local et/ou aux utilisateurs du réseau local un message suggérant aux utilisateurs et/ou aux nœuds de restaurer la configuration wifi par défaut. Procédé de détection d’incidents dans un réseau local par un dispositif de détection d’incidents, le dispositif de détection d’incidents étant relié au réseau local par l’intermédiaire d’un réseau étendu, le réseau local comportant un agent de collecte de données collectant des données descriptives des connexions entre des stations et des nœuds du réseau local et des données descriptives des connexions entre les nœuds, caractérisé en ce que le dispositif de détection d’incidents est apte à détecter différents types d’anomalies et en ce que le procédé comporte les étapes effectuées par le dispositif de détection d’incidents de : - réception (E50) de messages de l’agent de collecte, validation et agrégation des données caractéristiques de liens du réseau local comprises dans chaque message reçu en groupes de données, - calcul (E51) d’un score de sévérité pour chaque groupe de données, pour chaque type d’anomalies et calcul d’un score de sévérité totale pour chaque groupe de données, - calcul (E53) sur l’ensemble des scores de sévérité totale des groupes de données agrégés pendant une durée prédéterminée d’un score de criticité totale, la durée prédéterminée étant telle qu’une pluralité de groupes de données sont agrégés pendant la durée prédéterminée, - génération (E54) de messages de recommandations ou d’actions correctives au moins à partir du score de criticité totale. Procédé selon la revendication 1, caractérisé en ce que le procédé comporte en outre une étape (E52) de calcul de la moyenne des scores de sévérités totales pondérés par la durée des groupes des données pour obtenir un score de santé du réseau local. Procédé selon la revendication 2, caractérisé en ce que les recommandations ou actions correctives sont en outre générées à partir du score de santé totale. Procédé selon l’une quelconque des revendications 1 à 3, caractérisé en ce que le réseau local est composé d’éléments et en ce que des scores de sévérités, des scores de sévérité totale, des scores de criticité totale et des scores de santé sont calculés pour au moins une partie des éléments du réseau local. Procédé selon la revendication 4, caractérisé en ce que les recommandations ou actions correctives sont en outre générées à partir des scores calculés pour la au moins une partie du réseau local. Procédé selon l’une quelconque des revendications 1 à 5, caractérisé en ce que les données sont agrégées en partitionnant les données selon une périodicité prédéterminée, si, dans une partition, aucun changement de caractéristique de fonctionnement d’un lien n’apparaît, un groupe de données est formé, le groupe de données comprenant l’ensemble des données de la partition et dans chaque partition, à chaque changement d’au moins une caractéristique de fonctionnement d’un lien , un groupe de données est formé, qui comprend les données de la partition correspondant à la caractéristique de fonctionnement du lien. Procédé selon la revendication 6, caractérisé en ce que la caractéristique de fonctionnement du lien est une bande de fréquence, un canal, un protocole de communication. Procédé selon l’une quelconque des revendications 1 à 7, caractérisé en ce que la valeur du score de sévérité est bornée par la valeur 0 et la valeur 1. Procédé selon l’une quelconque des revendications 1 à 8, caractérisé en ce que chaque score de sévérité totale est borné par la valeur 0 et la valeur 1 et est égale à la valeur 1 dès qu’un score de sévérité est égal à 1. Procédé selon la revendication 9, caractérisé en ce que chaque score de criticité totale est calculé à partir de la somme des scores de sévérités totales pondérés par la durée des groupes des données. Procédé selon l’une quelconque des revendications 1 à 10, caractérisé en ce que les recommandations sont des invitations à rapprocher une station d’un nœud du réseau local ou à ajouter un nœud dans le réseau local ou à déplacer un nœud du réseau local ou à modifier un canal à utiliser ou à modifier des seuils d’algorithmes locaux qui engendrent les changements de canaux ou à supprimer des sources de bruit ou à restaurer une configuration du protocole de communication et les actions correctives sont des modification de canaux ou des modifications de seuils d’algorithmes locaux qui engendrent les changements de canaux. Dispositif de détection d’incidents dans un réseau local, le dispositif de détection d’incidents étant relié au réseau local par l’intermédiaire d’un réseau étendu, le réseau local comportant un agent de collecte de données collectant des données descriptives des connexions entre des stations et des nœuds du réseau local et des données descriptives des connexions entre les nœuds, caractérisé en ce que le dispositif de détection d’incidents est apte à détecter différents types d’anomalies et en ce que le dispositif de détection d’incidents comporte : - des moyens de réception de messages de l’agent de collecte, validation et agrégation des données caractéristiques de liens du réseau local comprises dans chaque message reçu en groupes de données, - des moyens de calcul d’un score de sévérité pour chaque groupe de données, pour chaque type d’anomalie et calcul d’un score de sévérité totale pour chaque groupe de données, - des moyens de calcul sur l’ensemble des scores de sévérité totale des groupes de données agrégés pendant une durée prédéterminée d’un score de criticité totale, la durée prédéterminée étant telle qu’une pluralité de groupes de données sont agrégés pendant la durée prédéterminée, - des moyens de génération de messages de recommandations ou d’actions correctives au moins à partir du score de criticité totale. Un produit programme d’ordinateur caractérisé en ce qu’il comprend des instructions pour implémenter, par un dispositif nœud, le procédé selon l’une quelconque des revendications 1 à 11, lorsque ledit programme est exécuté par un processeur du dispositif nœud. Un support de stockage caractérisé en ce qu’il stocke un programme d’ordinateur comprenant des instructions pour implémenter, par un dispositif nœud, le procédé selon l’une quelconque des revendications 1 à 11, lorsque ledit programme est exécuté par un processeur du dispositif nœud.