Brevet FR3116979A1 — publié le 20220603

L’invention porte sur un procédé de gestion d’un système dans un réseau de communication local. Des métadonnées sont extraites d’un groupe de paquets dont la source ou le destinataire est un dispositif communicant donné dans un réseau local. Un score de reconstruction est déterminé. Ce score est indicatif d’un degré de ressemblance entre les métadonnées extraites et des métadonnées de référence issues d’un modèle prédictif dédié représentatif de prédictions de fonctionnement dudit dispositif communicant à l’instant courant. Une anomalie de fonctionnement du dispositif communicant à l’instant courant est détectée sur la base d’un résultat d’une comparaison du score de reconstruction avec un seuil prédéterminé. Figure de l’abrégé : Figure 2 Assistance pour l’aide à l’identification de dispositifs dysfonctionnels La présente divulgation relève du domaine des services de gestion de dispositifs communicants ou connectés. Plus particulièrement, la présente divulgation porte sur un procédé de gestion d’un dispositif communicant dans un réseau de communication local, sur un procédé d’assistance et sur des systèmes, dispositifs, programmes informatiques et supports d’enregistrement correspondants. Historiquement, les services de gestion à distance de dispositifs connectés reposent sur deux types d’entités : un serveur de gestion et des clients de gestion. Le serveur de gestion est présent dans le réseau d’un fournisseur de service et est chargé d’exécuter à distance des opérations de maintenance, configuration et diagnostic sur les dispositifs présents dans le réseau du client, également appelé réseau local. Un client de gestion est présent sur chaque dispositif géré et assure une communication sécurisée avec le serveur de gestion. Dans de tels services de gestion à distance, connus, une expérience client transparente (« seamless » en anglais) peut être assurée pour l’ensemble des services s’exécutant sur des dispositifs gérés par le fournisseur de service. Avec le développement de l’internet des objets, un nouveau paradigme survient : de multiples dispositifs connectés d’un client, administrés par des acteurs différents, participent à la construction de services complexes. Ainsi, un service de contrôle de lampes peut s’appuyer par exemple sur un assistant vocal et une passerelle gérés par un fournisseur ainsi que sur un répéteur de réseau sans-fil géré par un fournisseur différent. Lors de dysfonctionnements d’un service tel que celui du contrôle de lampes, il n’est pas possible à un seul acteur de communiquer avec tous les dispositifs impliqués. Aujourd’hui, lors d’un dysfonctionnement constaté, le client contacte le service d’assistance à distance de son fournisseur de service qui déclenche manuellement un ensemble de diagnostics sur les dispositifs qu’il gère pour tenter d’identifier la source du dysfonctionnement. Il est souhaitable, dans une telle situation, de pouvoir fournir une information satisfaisante au client qui souhaite une aide pour remédier au dysfonctionnement. Pour cette raison, il existe un besoin pour un outil de diagnostic généralisé au sein d’un réseau local permettant de fluidifier le parcours client lors d’une demande d’assistance. Un tel outil de diagnostic permettrait, idéalement, de donner au client des indications sur les potentiels dispositifs à la source du dysfonctionnement constaté, indépendamment du nombre ou des fonctions des dispositifs en présence ou encore du fait que chacun de ces dispositifs soit géré ou non par un même fournisseur de service. Résumé La présente divulgation vient améliorer la situation. Il est proposé un procédé de gestion de dispositifs communicants dans un réseau de communication local, le procédé étant mis en œuvre par au moins un circuit de traitement de données et comprenant : - pour au moins un dispositif communicant : o une obtention d’un groupe de paquets de données transitant sur ledit réseau, un paquet de données du groupe comprenant un en-tête indiquant que ledit dispositif communicant donné dans le réseau est la source dudit paquet ou que ledit dispositif est le destinataire dudit paquet, o une extraction, à partir d’au moins un groupe de paquets auquel ledit dispositif communicant est associé, de métadonnées représentatives d’un fonctionnement du dispositif communicant à l’instant courant ; o une détermination d’un score de reconstruction indicatif d’un degré de ressemblance entre les métadonnées extraites et des métadonnées de référence issues d’un modèle prédictif dédié associé audit dispositif communicant et représentatives de prédictions de fonctionnement dudit dispositif communicant à l’instant courant ; et o une détection d’une anomalie de fonctionnement du dispositif communicant à l’instant courant sur la base d’un résultat d’une comparaison du score de reconstruction avec une valeur seuil. Ainsi, il est possible de détecter des anomalies de fonctionnement pour l’ensemble des dispositifs communicants dans un réseau local, indépendamment de l’entité en charge de leur gestion, et de déterminer de manière agnostique si à un instant donné un dispositif communicant donné présente ou non une anomalie de fonctionnement. Le procédé proposé n’a aucun impact sur le fonctionnement du dispositif communicant lui-même. Ce procédé peut être mis en œuvre de manière continue par un fournisseur de service afin d’enregistrer les anomalies détectées pour chaque dispositif communicant dans le réseau local. Ainsi le fournisseur de service est en mesure, quelle que soit la complexité de l’écosystème de dispositifs connectés d’un client, d’aider au dépannage du client en lui fournissant une liste de dispositifs probablement à l’origine de son problème, malgré le fait que ces dispositifs ne sont pas forcément gérés par le fournisseur de service en question. Ce procédé peut également être interfacé à d’autres outils de diagnostic plus poussés lorsque les dispositifs posant problème sont effectivement administrés par le fournisseur de service. Ce procédé peut alors servir de premier filtrage accélérant la procédure de débogage. La mise en œuvre de ce procédé permet aussi de diminuer la durée des appels au service d’assistance, qui représentent un coût non négligeable pour tout opérateur ou fournisseur de service. Il est également proposé un programme informatique comportant des instructions pour la mise en œuvre du procédé ci-avant lorsque ce programme est exécuté par un processeur. Il est également proposé un support d’enregistrement non transitoire lisible par un ordinateur sur lequel est enregistré un programme pour la mise en œuvre du procédé ci-avant lorsque ce programme est exécuté par un processeur. Il est également proposé un circuit de traitement de données comprenant un processeur connecté au support d’enregistrement non transitoire ci-avant. Il est également proposé un système comprenant une pluralité de dispositifs communicants dans un réseau de communication local, au moins un des dispositifs communicants comprenant le circuit de traitement de données ci-avant. Il est également proposé un procédé d’assistance d’un utilisateur du système ci-avant, le procédé comprenant : - une commande à distance d’au moins un dispositif réseau comprenant le circuit de traitement de données ci-avant pour obtenir au moins une alerte indicative d’une anomalie de fonctionnement d’un dispositif communicant, et - une assistance à distance de l’utilisateur sur la base de l’au moins une alerte obtenue. Le procédé de gestion ci-avant peut comprendre optionnellement certaines fonctions supplémentaires telles que définies ci-après. Dans certains exemples : - un premier et un deuxième groupe de métadonnées de référence sont issues du modèle prédictif dédié, le premier groupe de métadonnées de référence étant représentatif d’une prédiction de fonctionnement normal dudit dispositif communicant à l’instant courant, le deuxième groupe de métadonnées de référence étant représentatif d’une prédiction de fonctionnement anormal dudit dispositif communicant à l’instant courant, et - le score de reconstruction est indicatif : o d’une part, d’un premier degré de ressemblance des métadonnées extraites relativement au premier groupe de métadonnées de référence, et o d’autre part, d’un deuxième degré de ressemblance des métadonnées extraites relativement au deuxième groupe de métadonnées de référence. Ainsi, les anomalies sont détectées en tant que déviations par rapport à un trafic réseau récurrent considéré comme normal et non pas, par exemple, en tant que telles par comparaison avec une liste d’anomalies prédéfinies. Un avantage est de pouvoir détecter tout type d’anomalie sans aucune supervision. Dans certains exemples, le procédé comprend en outre, préalablement à l’obtention, pour au moins un dispositif communicant, d’un groupe de paquets de données, au moins une des étapes suivantes afin d’obtenir ledit groupe de paquets de données : - une séparation d’un flux de paquets de données transitant sur ledit réseau en une pluralité de groupes de paquets de données, de sorte que pour chaque groupe issu de la séparation, un paquet de données dudit groupe comprend un en-tête indiquant qu’un dispositif communicant particulier dans le réseau est la source dudit paquet ou que ledit dispositif est le destinataire dudit paquet, et - un filtrage d’un flux de paquets de données transitant sur le réseau local afin de conserver uniquement les paquets de données comprenant un en-tête indiquant que la source dudit paquet ou le destinataire dudit paquet appartient à une liste de dispositifs communicants prédéfinie. Ainsi, les ressources nécessaires à la mise en œuvre du procédé peuvent être minimisées en traitant le trafic réseau de ou vers chaque dispositif réseau de manière séparée ou découplée, et, optionnellement, en excluant l’analyse d’un trafic réseau complexe, de ou vers un micro-ordinateur par exemple. A l’inverse, un éclairage connecté ou une balance connectée par exemple ont un trafic réseau à la fois modéré et reproductible dans le temps. Il est plus facile de prédire correctement un trafic réseau normal de ou vers de tels dispositifs et de détecter correctement une anomalie de fonctionnement de tels dispositifs. Dans certains exemples, le modèle prédictif dédié est issu d’un apprentissage automatique alimenté par des métadonnées historiques représentatives de fonctionnements dudit dispositif communicant à des instants précédents. Dans certains exemples, le procédé comprend en outre une utilisation des métadonnées extraites pour alimenter l’apprentissage automatique du modèle prédictif dédié associé à ladite source en vue d’affiner des métadonnées de référence ultérieurement obtenues. Ainsi, l’apprentissage automatique est effectué au sein du réseau local, sur la base des caractéristiques du trafic réseau effectivement observé. L’apprentissage automatique permet donc de prédire les caractéristiques d’un trafic réseau représentatif de l’écosystème réel au sein du réseau local. Par ailleurs, effectuer un tel apprentissage automatique directement au sein du réseau local, et non de manière externe au réseau local, est un atout en termes de cybersécurité et de protection des données personnelles. Dans certains exemples, un identifiant du dispositif communicant présentant l’anomalie de fonctionnement à l’instant courant est mémorisé. Ainsi, il est possible d’identifier le dispositif communicant en cause. Dans certains exemples, un horodatage de la détection d’anomalie est mémorisé. Ainsi, il est possible de déterminer, par exemple, un instant à partir duquel un dispositif communicant ou un canal de communication a commencé à présenter des signes de dysfonctionnement. Dans certains exemples, le procédé comprend un stockage de l’anomalie dans un historique d’anomalies en vue d’une consultation par un service d’assistance. Dans certains exemples, le procédé comprend une émission, par un service d’assistance, d’une commande à destination d’un dispositif communicant, la commande étant destinée à piloter ledit dispositif communicant en vue d’en faciliter l’identification par un utilisateur du dispositif communicant présentant l’anomalie de fonctionnement à l’instant courant. Ainsi, il est possible d’obtenir des indices permettant à un service d’assistance, ou à un client en contact avec le service d’assistance, d’identifier le dispositif communicant à la source d’un dysfonctionnement constaté. D’autres caractéristiques, détails et avantages apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels : Fig. 1 illustre un système comprenant une pluralité de dispositifs communicants dans un réseau de communication local dans un exemple de réalisation. Fig. 2 illustre un algorithme général d’un programme informatique pour la mise en œuvre, lorsque ce programme est exécuté par un processeur, d’un procédé de gestion du système de la dans un exemple de réalisation. Fig. 3 illustre un diagramme d’activité d’une session d’assistance impliquant le procédé de gestion de la . Fig. 4 illustre un histogramme de scores cosinus après une première phase d’apprentissage d’un modèle prédictif du fonctionnement d’un dispositif communicant, dans un exemple de réalisation. Fig. 5 illustre un histogramme de scores cosinus après une deuxième phase d’apprentissage d’un modèle prédictif du fonctionnement d’un dispositif communicant, dans un exemple de réalisation. Fig. 6 illustre une évolution des seuils triangulaires de deux ensembles de scores de reconstruction issus d’un modèle prédictif du fonctionnement d’un dispositif communicant, au cours des itérations d’apprentissages du modèle, dans un exemple de réalisation. Fig. 7 illustre un circuit de traitement de données dans un exemple de réalisation. Le principe général de l'invention repose sur l’exploitation de métadonnées extraites d’un trafic transitant dans un réseau local afin de prédire les caractéristiques de ce trafic. Lorsque la prédiction de ces caractéristiques pour un dispositif communicant est imparfaite, une anomalie est relevée, car cela signifie que le trafic actuel associé à ce dispositif présente des caractéristiques non observées auparavant. La technique proposée trouve de nombreuses applications en particulier dans le contexte d’un service d’assistance à distance proposé par un fournisseur de services réseau. Ainsi, le service d’assistance peut par exemple relever à distance les anomalies de fonctionnement enregistrées au sein d’un réseau local d’un utilisateur, identifier sur cette base, toujours à distance, le dispositif concerné au sein de ce réseau local et aider l’utilisateur à identifier physiquement ce dispositif. D’autres applications sont possibles dans le contexte d’opérations de maintenance automatique, en détectant immédiatement les dispositifs présentant des caractéristiques anormales pour déclencher des diagnostics avancés, identifier l’origine du problème, et permettre une réparation automatique avant toute demande d’assistance de la part du client. Dans la suite de la description, on s’attache à décrire en détails un exemple de mise en œuvre de la technique proposée en se référant aux figures 1 à 7. La illustre un système comprenant une pluralité de dispositifs communicants (10, 11, 12, 13, 14, 15, 100) dans un réseau de communication local LAN/WLAN (1). L’un des dispositifs communicants est une passerelle d’accès à un réseau GW (10) interfaçant le réseau de communication local (1) avec un réseau de communication étendu WAN (2) et permettant aux dispositifs communicants d’accéder au réseau étendu. Les dispositifs communicants peuvent aussi comprendre différents types de dispositifs à l’usage d’un utilisateur, tel qu’un ordinateur, un téléphone mobile, une tablette tactile, une enceinte connectée, une console de jeux, un objet connecté dans le domaine de l’éclairage, de la santé, de la sécurité, du chauffage, de la qualité de l’air, etc. Par ailleurs, les dispositifs communicants peuvent comprendre un ou plusieurs dispositifs réseau autres que la passerelle d’accès, tels qu’un commutateur, un concentrateur, un routeur, un répéteur, etc. Sur la , la topologie du réseau local (1) est représentée en arbre. Certains dispositifs communicants EQ1 (11), EQ2 (12) communiquent directement avec la passerelle réseau (10), tandis que d’autres dispositifs utilisateurs EQ3 (13), EQ4 (14) communiquent quant à eux avec un répéteur RPT (15) dont le rôle principal est d’étendre la couverture de la passerelle réseau (10). Pour autant, la technique proposée n’est pas limitée à une quelconque topologie particulière du réseau local (1) et est applicable à toute installation par exemple domestique ou bien au sein d’une entreprise, quels que soient les dispositifs réseau en présence et quels que soient par ailleurs le nombre et la nature des dispositifs utilisateurs. L’un quelconque des dispositifs communicants du réseau local comprend un circuit de traitement CT (100) configuré pour la mise en œuvre du procédé proposé. Dans l’exemple de la , le circuit de traitement CT (100) est intégré à la passerelle d’accès au réseau (10), ce qui permet au circuit de traitement (100) d’avoir directement accès à la totalité du trafic transitant dans le réseau local. La décrit spécifiquement la structure d’un tel circuit de traitement (100). Celui-ci comprend au moins un processeur CPU (101) raccordé à au moins une mémoire non transitoire MEM (102) et à une interface de communication COM (103) avec le réseau local (1). La mémoire non transitoire (102) stocke une ou plusieurs instructions d’un programme informatique pour la mise en œuvre d’un procédé de gestion du système de la lorsque ce programme est exécuté par un processeur. Le fonctionnement du programme peut également requérir la présence d’une mémoire transitoire au sein du circuit de traitement. Fonctionnellement, au cours de l’exécution du programme, le circuit de traitement (100) peut être vu comme un groupe de modules fonctionnels respectivement dédiés à des tâches spécifiques, parmi lesquels un module de collecte de trafic réseau, un module de modélisation, un module de détection d’anomalies, un module d’enregistrement d’anomalies et un module d’identification de dispositifs communicants. Le module de collecte de trafic réseau n’est pas obligatoirement regroupé avec les autres modules et peut alternativement appartenir à un circuit de traitement distinct. Un dispositif EXT (20), extérieur au système et au réseau local (1), est également représenté sur la et désigne un dispositif apte à communiquer avec le circuit de traitement (100). En fonction de la topologie du réseau local et de la nature du dispositif communicant comprenant le circuit de traitement (100), cette communication s’effectue soit directement via le réseau étendu (2), soit indirectement à travers à la fois le réseau étendu (2) et le réseau local (1). On se réfère à présent à la qui illustre un exemple de procédé de gestion du système de la . Ce procédé met notamment en œuvre un algorithme de détection d’anomalie pouvant être exécuté par le circuit de traitement (100). Au bloc 31, un dispositif réseau donné, hébergeant un module de collecte de trafic réseau, redirige COL TFC, ou duplique, l’ensemble du trafic réseau local transitant par ce dispositif réseau donné vers un module de modélisation. On considère que le trafic réseau local correspond à un flux de paquets de données transitant via le réseau local. Un paquet de données inclut un en-tête (en anglais, « header »), comprenant les informations nécessaires pour acheminer ce paquet, et encapsule un contenu. L’en-tête de chaque paquet comprend au moins une adresse « source » et au moins une adresse « de destination ». Dans le cas où un paquet est émis par un dispositif communicant au sein du réseau local, l’adresse source du paquet est un marqueur identifiant ce dispositif communicant. Dans le cas où un paquet a été émis par une quelconque source, au sein du réseau local ou en dehors, et est destiné spécifiquement à un dispositif communicant au sein du réseau local, l’adresse de destination du paquet est un marqueur identifiant ce dispositif communicant vers lequel ce paquet doit être acheminé. Il est également possible qu’un paquet ait une adresse de destination ne correspondant pas à un destinataire spécifique mais soit une adresse dite « de diffusion », correspondant à désigner comme destinataires l’ensemble des dispositifs communicants au sein du réseau local. Les adresses source ou de destination sont indispensables à l’acheminement des paquets et peuvent par exemple désigner des adresses IP et/ou des adresses MAC, selon le type de paquets, IP ou MAC collectés. La redirection ou duplication du trafic réseau local n’a pas d’impact sur le trafic acheminé dans le réseau local lorsque le module de collecte de trafic réseau et le module de modélisation sont hébergés sur le même dispositif réseau. Plus généralement, l’analyse du trafic réseau local, qu’il soit redirigé ou dupliqué, n’a pas d’impact sur le fonctionnement des dispositifs communicants mêmes. En effet, l’analyse proposée ne prévoit aucune interaction directe avec ces dispositifs communicants, qui conservent donc leur fonctionnement nominal tel qu’en l’absence de toute analyse du trafic réseau local. Par ailleurs, on peut envisager des règles de filtrage à ce niveau afin de ne rediriger ou dupliquer qu’une partie, et non l’ensemble, du trafic réseau local. Par exemple, il est possible d’exclure des paquets de données en fonction de leur source ou de leur destination, par exemple du trafic issu ou à destination de dispositif trop complexes et demandeurs en bande passante tels que des ordinateurs ou téléphones multifonctions. Il est ici souligné que le contenu des paquets de données peut être chiffré ou non. Le procédé s’exécutant uniquement à partir des caractéristiques extraites des paquets de données n’est pas impacté par cet éventuel chiffrement. Au bloc 32, le module de modélisation sépare SEP TFC l’ensemble du trafic reçu en fonction des marqueurs disponibles dans les en-têtes des paquets, de manière à former des groupes de paquets ayant un même dispositif pour source ou pour destinataire. Ainsi, chaque groupe de paquets peut être associé à un dispositif communicant respectif du réseau local et représenter, pour ce dispositif communicant, l’ensemble du trafic réseau entrant et/ou sortant. Dans la suite de la description, on se place dans un exemple de réalisation où chaque dispositif communicant est associé à un seul groupe de paquets, qui représente, pour ce dispositif communicant, l’ensemble du trafic réseau entrant et sortant. Selon un autre exemple de réalisation, au bloc 31, le dispositif réseau ne redirige pas, ou ne duplique pas, l’ensemble du trafic réseau local en vue de le séparer en une pluralité de groupes de paquets, mais extrait du trafic réseau local uniquement les paquets de données émis ou reçus par un ou plusieurs dispositifs communicants donnés. Pour chaque groupe de paquets, donc dans ce mode de réalisation pour chaque dispositif communicant dans le réseau local, le module de modélisation extrait des métadonnées du groupe de paquets associé à ce dispositif communicant. Les métadonnées sont des données descriptives d’un paquet indépendamment du contenu du paquet. Les métadonnées peuvent comprendre diverses informations, binaires ou non, en fonction du protocole de communication utilisé. Un exemple de type de métadonnée est le moment d’émission du paquet. Un tel type de métadonnée peut être prévu par exemple aux fins d’une estimation de qualité de service au niveau du destinataire. Un autre exemple de type de métadonnée est la taille du contenu du paquet. Ces métadonnées sont représentatives d’un fonctionnement du dispositif communicant à un instant courant. On considère le groupe de paquets associé au dispositif communicant donné comme un ensemble de paquets reçus chacun à un instant respectif. Le groupe de paquets peut être subdivisé en sous-groupes de paquets sur la base par exemple d’intervalles temporels, de sorte que chaque sous-groupe est associé à un intervalle temporel respectif et comprend le ou les paquets reçus au cours de cet intervalle temporel. D’autres critères de subdivision peuvent être appliqués, par exemple on peut considérer chaque paquet reçu individuellement. Pour chaque sous-groupe de paquets, ou pour chaque paquet considéré individuellement, on obtient un ensemble de métadonnées qui peuvent être organisées ou rassemblées sous la forme d’un vecteur de caractéristiques observé. Pour chaque groupe de paquets, donc dans ce mode de réalisation pour chaque dispositif communicant dans le réseau local, le module de modélisation peut créer un modèle dédié appris à partir de vecteurs de caractéristiques précédemment observés. Au bloc 33, le module de modélisation détermine DET MOD si, pour un dispositif communicant donné, un modèle dédié est ou non disponible et en mesure de prédire les caractéristiques courantes du trafic réseau associé à ce dispositif communicant, c’est-à-dire le vecteur de caractéristiques couramment observé, sur la base des vecteurs de caractéristiques précédemment observés. On fait l’hypothèse qu’à un instant courant, une phase d’apprentissage d’un modèle dédié associé à un dispositif communicant donné est en cours et que les vecteurs de caractéristiques précédemment observés sont stockés en mémoire et accessibles au module de modélisation. En suivant cette hypothèse, au bloc 34, le module de modélisation exploite le vecteur de caractéristiques couramment observé pour poursuivre TRN MOD l’apprentissage du modèle dédié. Un exemple de principe d’apprentissage d’un tel modèle dédié est à présent détaillé en référence avec les figures 4 à 6. Dans cet exemple, le modèle dédié suit une architecture de réseau de neurones du type d’un auto-encodeur. L’apprentissage est réalisé en plusieurs itérations. Lors de chaque itération, des paramètres du modèle dédié sont ajustés. Ces itérations sont destinées à diminuer progressivement la valeur d’une fonction d’erreur. Lors d’une première itération du processus d’apprentissage, le module de modélisation initialise le modèle dédié en établissant une fonction de lien par défaut reliant l’ensemble des vecteurs de caractéristiques précédemment observés à un vecteur de caractéristiques prédit. En d’autres termes, le modèle dédié prédit les caractéristiques du trafic réseau à venir en s’appuyant sur les caractéristiques du trafic réseau obtenues jusqu’à présent. Le module de modélisation peut alors déterminer un vecteur de caractéristiques prédit Cp pour chaque subdivision du groupe de paquets à l’aide des vecteurs de caractéristiques précédemment observés et à l’aide de la fonction de lien par défaut. Ainsi, après le traitement par le module de modélisation de n subdivisions du groupe de paquets, on dispose de n paires de vecteurs formées chacune d’un vecteur de caractéristiques observé Cobs et d’un vecteur de caractéristiques prédit Cp. Chaque paire de vecteurs est dénommée ci-après « échantillon ». Chaque échantillon est associé à un score de reconstruction respectif. On définit le score de reconstruction ou « score cosinus » à l’aide de la formule mathématique suivante : Pour un échantillon donné, le score cosinus prend une valeur normalisée entre 0 et 1 indicative d’un degré de ressemblance entre le vecteur de caractéristiques prédit et le vecteur de caractéristiques observé. La valeur maximale de 1 est atteinte lorsque le vecteur de caractéristiques prédit est identique au vecteur de caractéristiques observé, cela signifie que le modèle prédit correctement le trafic, donc que le trafic présente des caractéristiques déjà observées. A l’inverse, lorsque le modèle n’arrive pas à prédire correctement le trafic, cela signifie que ce trafic présente des caractéristiques particulières, encore jamais observées. Le module de modélisation modifie la fonction de lien, par exemple par un ajustement de coefficients, de manière à maximiser la moyenne des scores cosinus pour l’ensemble des échantillons. Ainsi, les vecteurs de caractéristiques observés les plus normaux, correspondant à des fonctionnements normaux du dispositif communicant considéré, sont naturellement plus représentés au sein de la base d’apprentissage. Les caractéristiques dites normales sont donc mieux apprises et la reconstruction est plus exacte. A l’inverse, les caractéristiques correspondant à des anomalies et déjà présentes dans la base d’apprentissage sont moins bien reconstruites. Nous pouvons alors définir un seuil sur la distance entre les caractéristiques prédites et les caractéristiques réellement observées. Lorsque ce seuil est franchi, le trafic est considéré comme une « anomalie ». Dans un exemple de réalisation, lors d’une première itération du processus d’apprentissage, cent vecteurs de caractéristiques observés ont été successivement obtenus et la fonction de lien a été optimisée pour calculer cent vecteurs de caractéristiques prédits de telle sorte que les cent échantillons ainsi obtenus, ou paires formées d’un vecteur de caractéristiques observé et d’un vecteur de caractéristiques prédit, présentent un score cosinus moyen le plus proche possible de 1. La est un histogramme représentant la répartition, entre 0 et 1, des scores cosinus (50) des échantillons obtenus à l’issue de la première itération. Cet histogramme prend la forme d’une pluralité de colonnes verticales s’étendant sur l’axe des abscisses le long d’un intervalle de score. On peut noter que certains intervalles de score sont vides, ce qui indique qu’aucun des échantillons obtenus n’a son score cosinus situé dans l’un de ces intervalles. La hauteur de chaque colonne verticale est proportionnelle au nombre de scores cosinus situés dans l’intervalle de score correspondant. Les intervalles de scores ont tous la même largeur, ainsi les colonnes verticales ont toutes la même largeur. Le module de modélisation détermine une valeur limite (51) sur le score cosinus. Les échantillons dont le score cosinus est supérieur ou égal à la valeur limite sont considérés comme normaux tandis que les échantillons dont le score cosinus est inférieur à la valeur limite sont considérés comme des anomalies. La valeur limite sur le score cosinus peut être déterminée par exemple à l’aide d’un seuillage triangulaire dont le principe est décrit ci-après. On trace, sur l’histogramme, un segment reliant, d’une part, le pic de l’intervalle de score le plus représenté à, d’autre part, l’axe des abscisses au niveau du centre de l’intervalle de score précédant le dernier intervalle de score non vide. Parmi les colonnes dont le pic est situé en dessous du segment ainsi tracé, on identifie quelle colonne a le pic le plus éloigné géométriquement du segment. La valeur du centre de l’intervalle de score correspondant à cette colonne est retenue comme résultat du seuillage triangulaire, c’est-à-dire comme valeur limite (51) sur le score cosinus. Lors d’une deuxième itération du processus d’apprentissage, de nouveaux vecteurs de caractéristiques observés sont obtenus et de nouveaux vecteurs de caractéristiques prédits sont déterminés à l’aide de la fonction de lien. A cet effet, le module de modélisation modifie la fonction de lien de manière à non seulement maximiser la moyenne des scores cosinus des échantillons normaux, mais également minimiser la moyenne des scores cosinus des échantillons considérés comme des anomalies. La est un histogramme représentant la répartition, entre 0 et 1, des scores cosinus (50) des échantillons obtenus à l’issue de la seconde itération. On constate qu’il n’existe aucun intervalle non vide. Le module de modélisation opère deux seuillages triangulaires en utilisant comme point de repère une valeur de score égale à 0,5. Ces deux seuillages triangulaires sont décrits ci-après. On trace, sur l’histogramme, deux segments. Le premier segment relie d’une part, le pic de l’intervalle de score le plus représenté dans la moitié gauche de l’histogramme à, d’autre part, l’axe des abscisses à la valeur de score égale à 0,5. Le deuxième segment relie d’une part, le pic de l’intervalle de score le plus représenté dans la moitié droite de l’histogramme à, d’autre part, l’axe des abscisses à la valeur de score égale à 0,5. Pour chaque segment ainsi tracé, parmi les colonnes dont le pic est situé en dessous du segment, on cherche quelle colonne a le pic le plus éloigné géométriquement du segment. La valeur du centre de l’intervalle de score correspondant à cette colonne est retenue comme résultat du seuillage triangulaire. On obtient ainsi, comme résultats des deux seuillages triangulaires, une valeur limite basse (60) et une valeur limite haute (61) sur le score cosinus. Ces deux seuillages définissent trois catégories d’échantillons : - celle des échantillons présentant les scores les plus faibles (62), qui seront réutilisés lors de la suite de l’apprentissage pour consolider leur statut d’anomalie ; - celle des échantillons présentant les scores les plus élevés (63), également réutilisés pour consolider leur statut d’échantillon normal ; et - celle des échantillons présentant des scores intermédiaires entre la valeur limite haute et la valeur limite basse, qui sont abandonnés car peu caractéristiques. Chaque nouvelle itération du processus d’apprentissage est mise en œuvre de la même manière que la seconde itération. La montre l’évolution de la valeur limite haute (61) et de la valeur limite basse (60) au cours d’itérations d’apprentissage successives. On voit que la valeur limite haute tend à se stabiliser autour d’une valeur proche de 1 et que la valeur limite basse tend à se stabiliser autour d’une valeur proche de 0. L’apprentissage s’achève sur la base d’un critère prédéterminé, par exemple après un nombre d’itérations prédéfini, ou lorsque le nombre d’échantillons abandonnés dépasse un seuil prédéfini. Il ressort de ce qui précède que l’outil de diagnostic est basé sur un modèle dédié à chaque dispositif qui, dans certains modes de réalisation, est basé sur un apprentissage automatique différenciant un mode de fonctionnement normal d’un mode de fonctionnement anormal. Une particularité d’un tel apprentissage automatique est que l’activité anormale peut être identifiée a priori, de manière générique, par un critère automatique de seuillage. Un comportement anormal est alors défini de manière générique comme une déviation à un comportement normal, à l’inverse d’autres outils de diagnostic connus qui caractérisent de manière supervisée les anomalies connues à l’avance. Ceci permet en particulier de détecter un ensemble d’anomalies non connues au moment de l’apprentissage du modèle. On se réfère à présent à nouveau à la , en considérant un dispositif communicant donné, et en faisant l’hypothèse que pour un groupe de paquets associé à ce dispositif communicant donné, un modèle dédié est disponible et en mesure de prédire les caractéristiques courantes du trafic réseau associé à ce dispositif communicant, c’est-à-dire le vecteur de caractéristiques couramment observé, sur la base des vecteurs de caractéristiques précédemment observés. Au bloc 35, le module de modélisation génère PRED VECT, à l’aide du modèle dédié, un vecteur de caractéristiques, prédit, du trafic réseau associé au dispositif communicant donné. Au bloc 36, le module de détection d’anomalies obtient le vecteur de caractéristiques couramment observé et le vecteur de caractéristiques couramment prédit. Le module de détection d’anomalies calcule CPT SC alors le score de reconstruction de l’échantillon constitué de ces deux vecteurs. Comme expliqué ci-avant, le score de reconstruction permet d’identifier ou de détecter si l’échantillon est normal ou présente une anomalie. On peut considérer qu’un échantillon normal caractérise un fonctionnement normal du dispositif communicant donné. A l’inverse, un échantillon présentant une anomalie caractérise une anomalie de fonctionnement du dispositif communicant donné. Au bloc 37, le module de détection d’anomalies compare CMP SC le score de reconstruction à un seuil prédéfini. Dans l’exemple de réalisation des figures 4 à 6, le seuil prédéfini peut être fixé égal à 0,5, ou à toute autre valeur comprise entre la valeur limite haute (61) et la valeur limite basse (60) du modèle dédié. Si le résultat de la comparaison indique que l’échantillon présente une anomalie, c’est-à-dire qu’une anomalie a été détectée, le module d’enregistrement d’anomalies stocke LOG ANOM, au bloc 38, une ou plusieurs informations relatives à cette anomalie détectée dans une mémoire non transitoire. Par exemple, lorsqu’une anomalie est détectée par le module de détection d’anomalies, le module d’enregistrement d’anomalies peut stocker, dans un journal d’anomalies, ou historique de l’ensemble des anomalies : - un identifiant du dispositif communicant donné, tel qu’une adresse IP ou MAC issue des marqueurs extraits des en-têtes des paquets associés au dispositif donné, et/ou - un horodatage de la détection de l’anomalie. Il peut être prévu que le module d’enregistrement d’anomalies permette de consulter l’historique de l’ensemble des anomalies et de générer une liste ordonnée des anomalies triée par ordre croissant ou décroissant de score. Il a été considéré jusqu’à présent qu’un modèle dédié est associé à un dispositif communicant donné. Dans un mode de réalisation particulier, plusieurs modèles sont associés à ce dispositif communicant donné. Un premier modèle peut par exemple correspondre à une modélisation par protocole en prenant en compte le type de protocole extrait des entêtes de paquet. Un deuxième modèle peut par exemple être différent en fonction d’une règle temporelle : en fonction de l’instant courant, un modèle différent est utilisé. Ainsi, lorsque plusieurs modèles sont associés au dispositif communicant, le procédé est mis en œuvre pour chacun des modèles. Lorsque l’utilisation d’un des modèles détermine que le fonctionnement est normal alors qu’un autre détermine l’identification d’une anomalie, alors le procédé considère qu’il n’y a pas de dysfonctionnement. Dans un mode de réalisation particulier, le module d’enregistrement d’anomalies stocke une ou plusieurs informations relatives à cette anomalie détectée en association avec un identifiant du modèle correspondant. Dans un mode de réalisation particulier, la phase d’apprentissage est de nouveau mise en œuvre en utilisant les groupes de paquet associés aux anomalies relevées en tant que groupes de paquet représentatifs d’un fonctionnement normal. A titre d’exemple illustratif, il s’agit par exemple d’une notification relative à une mise à jour du micrologiciel d’un dispositif communicant. On se réfère à présent à la , qui illustre un diagramme d’activité d’une session d’assistance impliquant le procédé de gestion de la . Au bloc 41, un client émet CUST CALL une demande d’assistance qui est reçue par le service d’assistance. Il se peut que le client soit en mesure d’identifier a priori le dispositif communicant à l’origine de son problème. Au bloc 42, le service d’assistance interroge INT CUST le client à cet effet. Si la source de l’anomalie reste inconnue, et si notamment aucun dispositif particulier n’est identifié a priori comme présentant une anomalie, alors le service d’assistance peut conduire une série de diagnostics et peut notamment s’appuyer sur les anomalies détectées par l’exécution préalable du procédé illustré dans la . Au bloc 43, le service d’assistance peut notamment accéder OBT LIST à un journal d’anomalies stocké en mémoire par le module d’enregistrement d’anomalies. Le service d’assistance peut ainsi consulter les informations relatives aux anomalies récemment détectées pour déterminer si des anomalies ont été effectivement détectées et si un ou plusieurs dispositifs communicants sont impliqués. Au bloc 44, le service d’assistance peut interroger OBT ID MN un module d’identification de dispositifs afin de déterminer l’ensemble des moyens d’identification d’un dispositif communicant présentant une anomalie de fonctionnement. Ces moyens d’identification ont pour but de générer un ou plusieurs indices pour que le client puisse identifier le dispositif communicant physique à l’origine d’une anomalie détectée. Le ou les dispositifs communicants présentant une anomalie de fonctionnement peuvent dans certains cas être identifiés sur la seule base d’une consultation des informations présentes dans le journal d’anomalies. En effet, il est parfois possible, par exemple, de déterminer le constructeur d’un dispositif communicant à partir d’un marqueur tel que l’adresse MAC du dispositif. La topologie du réseau local, c’est-à-dire la hiérarchie de connexion des dispositifs communicants, peut aussi être susceptible de fournir des indices permettant d’identifier le ou les dispositifs communicants présentant une anomalie de fonctionnement. Par exemple, il est possible de connaître les dispositifs réseau via lesquels transitent les paquets émis, ou reçus, par un dispositif communicant donné. Par exemple, en présence d’un répéteur sans-fil ou d’un extendeur, il est possible de savoir si le dispositif est connecté directement à la passerelle réseau ou raccordé à un répéteur ou routeur particulier. Ceci permet de déduire par exemple dans quelle zone d’un logement se trouve le dispositif concerné. Certains moyens d’identification sont basés sur la mise en œuvre de moyens d’action sur un des dispositifs communicants. Ces moyens d’action ont eux aussi pour but de générer un ou plusieurs indices pour que le client puisse identifier le dispositif communicant physique à l’origine d’une anomalie de fonctionnement détectée. Le module d’identification de dispositifs peut être configuré pour émettre un signal de commande entraînant une action directe ou indirecte au niveau du dispositif communicant concerné. Un exemple d’action directe, en cas d’interopérabilité, est de directement piloter à distance un fonctionnement de certains dispositifs communicants, comme allumer une lumière, générer un son, etc… Des exemples d’actions indirectes incluent une commande de la passerelle réseau pour imposer une règle de pare-feu sur l’adresse MAC du dispositif concerné, ou en révoquer le bail IP. En effet, de nombreux dispositifs communicants sont configurés pour générer une alerte en cas de perte de connexion. Déconnecter du réseau un dispositif présentant une anomalie de fonctionnement peut entraîner, indirectement, une telle génération d’alerte, ce qui permet au client d’identifier rapidement le dispositif physique en cause. Après identification au bloc 44 des moyens d’action disponibles, le service d’assistance peut commander COM EQ au bloc 46 la mise en œuvre de tout ou partie de ces moyens d’action disponibles, directs ou indirects. Au bloc 45, le service d’assistance peut également fournir les indices obtenus au client afin d’obtenir FDBK CUST un retour du client, permettant de conclure sur l’identification du dispositif communicant présentant une anomalie de fonctionnement. Ainsi, lorsqu’un client constate une anomalie au sein d’un réseau local, le service d’assistance d’un fournisseur de service est en mesure de proposer des diagnostics sur l’ensemble des dispositifs communicants en présence, que ceux-ci aient été ou non fournis par le fournisseur de service. Le service d’assistance d’un fournisseur de service peut alors rediriger le client vers d’autres systèmes d’assistance qui seront plus à même de l’aider suite au dysfonctionnement d’un service ou dispositif à la charge d’un fournisseur de service tiers. Procédé de gestion de dispositifs communicants dans un réseau de communication local, le procédé étant mis en œuvre par au moins un circuit de traitement de données et comprenant : - pour au moins un dispositif communicant : une obtention (31) d’un groupe de paquets de données transitant sur ledit réseau, un paquet de données du groupe comprenant un en-tête indiquant que ledit dispositif communicant donné dans le réseau est la source dudit paquet ou que ledit dispositif est le destinataire dudit paquet, une extraction, à partir d’au moins un groupe de paquets auquel ledit dispositif communicant est associé, de métadonnées représentatives d’un fonctionnement du dispositif communicant à l’instant courant ; une détermination (36) d’un score de reconstruction indicatif d’un degré de ressemblance entre les métadonnées extraites et des métadonnées de référence issues d’un modèle prédictif dédié associé audit dispositif communicant et représentatives de prédictions de fonctionnement dudit dispositif communicant à l’instant courant ; et une détection d’une anomalie de fonctionnement du dispositif communicant à l’instant courant sur la base d’un résultat d’une comparaison (37) du score de reconstruction avec une valeur seuil. Procédé selon la revendication 1, dans lequel : - un premier et un deuxième groupe de métadonnées de référence sont issues du modèle prédictif dédié, le premier groupe de métadonnées de référence étant représentatif d’une prédiction de fonctionnement normal dudit dispositif communicant à l’instant courant, le deuxième groupe de métadonnées de référence étant représentatif d’une prédiction de fonctionnement anormal dudit dispositif communicant à l’instant courant, et - le score de reconstruction est indicatif : d’une part, d’un premier degré de ressemblance des métadonnées extraites relativement au premier groupe de métadonnées de référence, et d’autre part, d’un deuxième degré de ressemblance des métadonnées extraites relativement au deuxième groupe de métadonnées de référence. Procédé selon l’une des revendications précédentes, comprenant en outre, préalablement à l’obtention, pour au moins un dispositif communicant, d’un groupe de paquets de données, au moins une des étapes suivantes afin d’obtenir ledit groupe de paquets de données : - une séparation (32) d’un flux de paquets de données transitant sur ledit réseau en une pluralité de groupes de paquets de données, de sorte que pour chaque groupe issu de la séparation, un paquet de données dudit groupe comprend un en-tête indiquant qu’un dispositif communicant particulier dans le réseau est la source dudit paquet ou que ledit dispositif est le destinataire dudit paquet, et - un filtrage d’un flux de paquets de données transitant sur le réseau local afin de conserver uniquement les paquets de données comprenant un en-tête indiquant que la source dudit paquet ou le destinataire dudit paquet appartient à une liste de dispositifs communicants prédéfinie. Procédé selon l’une des revendications précédentes, le modèle prédictif dédié étant issu d’un apprentissage automatique alimenté par des métadonnées historiques représentatives de fonctionnements dudit dispositif communicant à des instants précédents. Procédé selon la revendication précédente, comprenant en outre une utilisation (34) des métadonnées extraites pour alimenter l’apprentissage automatique du modèle prédictif dédié associé à ladite source en vue d’affiner des métadonnées de référence ultérieurement obtenues. Procédé selon l’une des revendications précédentes, comprenant une émission (46), par un service d’assistance, d’une commande à destination d’un dispositif communicant, la commande étant destinée à piloter ledit dispositif communicant en vue d’en faciliter l’identification par un utilisateur du dispositif communicant présentant l’anomalie de fonctionnement à l’instant courant. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications 1 à 6 lorsque ce programme est exécuté par un processeur. Support d’enregistrement non transitoire (102) lisible par un ordinateur sur lequel est enregistré un programme pour la mise en œuvre du procédé selon l’une des revendications 1 à 6 lorsque ce programme est exécuté par un processeur. Circuit de traitement de données (100) comprenant un processeur (101) connecté à un support d’enregistrement non transitoire (102) selon la revendication précédente. Système comprenant une pluralité de dispositifs communicants dans un réseau de communication local, au moins un des dispositifs communicants comprenant un circuit de traitement selon la revendication 9.