Brevet FR3138591A1 — publié le 20240202

La présente invention concerne un procédé de caractérisation d’au moins une partie d’un réseau (20, 21) comportant au moins un boîtier d’accès à internet (2), caractérisé en ce que le boîtier d’accès à internet (2) génère et transmet à intervalle régulier (E3), à destination d’au moins un serveur (3), des messages encapsulant (E2) des données de caractérisation mémorisées dans ledit boîtier (2), lesdites données comportant au moins un paramètre de performance calculé (E1) par ledit boitier (2). Figure pour l’abrégé : Fig. 1 Caractérisation d’au moins une partie d’un réseau internet DOMAINE DE L'INVENTION L’invention concerne de manière générale la fourniture d’accès à internet et plus précisément la caractérisation d’au moins une partie d’un réseau internet comportant au moins un boîtier d’accès à internet (ou IAD selon la terminologie anglosaxonne généralement utilisée). ETAT DE LA TECHNIQUE Il est souhaitable, pour vérifier les performances d’une connexion réseau, de pouvoir surveiller les connectivités ainsi que les performances entre un client et un serveur. Par exemple, il est courant qu’un utilisateur se plaigne de ne plus avoir un accès à Internet convenable et appelle le service client du fournisseur d’accès à internet. Ce dernier doit donc être en capacité de détecter et localiser l’origine du problème avant que le client le ressente et qu’il s’en plaigne. Une première façon de surveiller les connectivités ainsi que les performances entre un client et un serveur consiste à envoyer périodiquement un message de type « ping » depuis un serveur central, vers les boîtiers d’accès à internet, de façon à détecter une potentielle perte de connexion soudaine dénommée « perte franche ». En effet, il suffit au serveur d’observer que la réponse au ping n’est plus reçue sur plusieurs périodes pour constater cette « perte franche ». Cependant cette méthode permet uniquement de tester la joignabilité des boîtiers d’accès à internet depuis le serveur de test, elle ne permet pas de connaitre si le boitier à bien accès aux différences services auxquels le client a souscrit et ne permet pas de connaitre la performance bout en bout pour chacun de ces services. On connait par ailleurs, par exemple par le document FR3020537, un procédé d’évaluation de performances d’une connexion entre deux terminaux, avec au moins un terminal comprenant un équipement de mesure, comprenant au moins une étape d’acquisition de données contenues dans l’en-tête de paquets transmis sous un protocole TCP dans le cadre de sessions d’échanges. Ces données peuvent par exemple être la valeur des drapeaux SYN et SYN/ACK, la valeur du champ de marquage temporel, ou le numéro de paquet de la session. Grâce à ces données et à l’équipement de mesure, il est possible, après plusieurs étapes explicitées dans le document FR3020537, de déterminer le temps de boucle, la valeur de la latence, la quantité de données en transit ou encore le taux de congestion. Une telle méthode ne permet toutefois pas de détecter les pertes franches. De plus, l’évaluation des performances y est limitée et ne repose que sur des données protocolaires contenues dans les en-têtes des paquets TCP échangés. De plus, ce type de méthode ne permet de récupérer des informations centralisées sur l’ensemble d’un réseau qu’à l’occasion de sessions d’échanges entre des terminaux de celui-ci. Aucune évaluation n’intervient en l’absence de ces échanges. Une synthèse sur la qualité des différentes connexions d’un réseau donné suppose une connaissance préalable exhaustive des éléments qui composent le réseau. Elle implique également de tester toutes les connexions possibles à partir de chacun des différents boîtiers d’accès du réseau, ce qui est particulièrement complexe à mettre en œuvre à grande échelle. Un but de l’invention est de remédier aux inconvénients précités. Elle propose notamment une solution permettant de façon simple et déployable à grande échelle, d’évaluer, pratiquement en temps réel, des performances de connexion sur un réseau donné et de détecter des pannes ou coupures sur celui-ci, et ce sans connaissance préalable du parc de boitiers de ce réseau. Il est à cet effet proposé, selon un premier aspect de l’invention un procédé de caractérisation d’au moins une partie d’un réseau comportant au moins un boîtier d’accès à internet, caractérisé en ce que le boîtier d’accès à internet génère et transmet à intervalle régulier, à destination d’au moins un serveur, des messages encapsulant des données de caractérisation mémorisées dans ledit boîtier, lesdites données comportant au moins un paramètre de performance calculé par ledit boitier. Ainsi, il est possible de caractériser une partie du réseau sans une connaissance préalable de sa topologie. De plus, il permet de s’assurer que l’usager du boitier a bien accès aux services auxquels il a souscrit un abonnement. Le procédé de caractérisation selon l’invention pourra présenter en outre au moins l’une des caractéristiques suivantes : - les données de caractérisation sont extraites des messages reçus, lesdites données en provenance de différents boîtiers d’accès à internet étant centralisées et traitées pour en déduire au moins une information sur le fonctionnement de tout ou partie du réseau, - le serveur extrait les données de caractérisation des messages reçus et retransmet à un serveur de centralisation les données de caractérisation qu’il reçoit de différents boitiers, - le serveur ajoute aux données de caractérisation, des données de caractérisation complémentaires, lesdites données de caractérisation complémentaires étant mémorisées par le serveur et comprenant des informations sur l’environnement de connexion des boitiers d’accès à internet, - le (ou les) serveur(s) transmet(tent) les données de caractérisation à un serveur de centralisation distant, ledit serveur de centralisation traitant les données qu’il reçoit de différents serveurs et générant une alerte lorsqu’un ou plusieurs messages attendus par un serveur dont il reçoit les données, n’a pas été reçus en provenance d’un boîtier d’accès à internet ou lorsqu’un paramètre de performance contenu dans les données groupées diffère d’une condition de connexion mémorisée par le serveur de centralisation, - le serveur de centralisation regroupe les données en provenance de différents boitiers d’accès à internet et de différents serveurs et met en œuvre au moins un traitement statistique sur celles-ci pour en déduire au moins un indicateur de performance d’au moins une zone donnée sur le réseau et le cas échéant générer des alertes pour au moins un indicateur et au moins une zone, et - les données de caractérisation sont transmis au serveur de centralisation en flux tendu, les boitiers d’accès à internet transmettant les messages encapsulant les données de caractérisation selon une périodicité inférieure à une journée, avantageusement inférieure à 6 heures, avantageusement inférieure à 1h, avantageusement supérieure à 1 minutes, préférentiellement moins de 10 minutes. Ainsi, il est possible de dissocier un problème de connexion unitaire, c’est-à-dire sur un boitier isolé, et un problème régional, c’est-à-dire sur une pluralité de boitiers. De plus, une telle centralisation des données permet de traiter les données plus rapidement et de favoriser l’expérience client ainsi que l’efficacité des services de maintenance du réseau opérateur. Le procédé permet de caractériser une partie du réseau selon différentes échelles géographiques. Il favorise aussi la scalabilité. Enfin, il est possible d’ajuster les performances nominales des connexions de façon dynamique. On prévoit selon l’invention un boitier d’accès à internet d’une partie d’un réseau, le boitier d’accès à internet étant configuré pour : - calculer un paramètre de performance, - mémoriser des données de caractérisation comprenant le paramètre de performance, - encapsuler les données de caractérisation mémorisées dans un message, et - transmettre à intervalle régulier un message ainsi préparé à un serveur. On prévoit aussi selon l’invention un serveur de centralisation d’un réseau étant configuré pour ledit serveur de centralisation traitant les données qu’il reçoit de différents serveurs et générant une alerte lorsqu’un ou plusieurs messages attendus par un serveur dont il reçoit les données, n’a pas été reçus en provenance d’un boîtier d’accès à internet ou lorsqu’un paramètre de performance contenu dans les données groupées diffère d’une condition de connexion mémorisée par le serveur de centralisation. On peut prévoir un produit programme d’ordinateur comprenant des instructions de code, pour l’exécution du procédé selon l’invention lorsque ledit programme est exécuté par un ordinateur. On peut prévoir des moyens de stockage lisibles par un équipement informatique sur lesquels un produit programme d’ordinateur comprend des instructions de code pour l’exécution du procédé selon l’invention. DESCRIPTION DES FIGURES D’autres caractéristiques, buts et avantages de l’invention ressortiront de la description qui suit, qui est purement illustrative et non limitative, et qui doit être lue en regard des dessins annexés sur lesquels : La illustre de façon schématique un exemple de liaison d’un boîtier d’accès à internet avec des serveurs distants et des plateformes de services ; La détaille la liaison entre le boîtier d’accès à internet et le serveur distant connectés de la ; La est un algorigramme illustrant un mode de mise en œuvre du procédé de transmission de données d’au moins un boîtier d’accès à internet vers un serveur ; La est un algorigramme illustrant un mode de mise en œuvre du procédé de caractérisation d’une connexion par le serveur connecté à au moins boîtier d’accès à internet ; La schématise plusieurs types de liaisons entre des boîtiers d’accès à internet et un multiplexeur ; La schématise un type de liaison entre plusieurs multiplexeurs et un réseau opérateur ; La est un graphe représentant plusieurs messages envoyés par un boîtier d’accès à internet et l’évolution de la latence de la connexion avec le serveur en fonction du temps ; La est un graphe représentant l’évolution de la latence en fonction du temps au niveau de plusieurs multiplexeurs ; La est une cartographie obtenue selon le mode de mise en œuvre du procédé illustré en dans laquelle est représentée les zones ayant subi une perte franche ; La est une autre cartographie obtenue selon le mode de mise en œuvre du procédé illustré en dans laquelle les zones de connexion sont distinguées selon le nombre de défauts comptés ; La est une cartographie différente de la et la selon le mode de mise en œuvre du procédé illustré en dans laquelle les zones de connexion sont distinguées selon le niveau de latence ; La est un diagramme à barres selon le mode de mise en œuvre du procédé illustré en dans lequel le nombre d’anomalies de chaque connexion est classé dans l’ordre décroissant ; et La est un autre diagramme à barres selon le mode de mise en œuvre du procédé illustré en dans lequel la latence de chaque connexion est classée dans l’ordre décroissant. Sur l’ensemble des figures, les éléments similaires portent des références identiques. DESCRIPTION DETAILLEE DE L'INVENTION En référence à la , il est proposé un procédé de caractérisation de tout ou partie d’un réseau internet comportant au moins un boîtier d’accès à internet 2 et un ou plusieurs serveurs 3. Par « caractérisation », on entend a minima la capacité de détecter et signaler un problème dans la connexion entre un boitier et un service distant. Typiquement, une alerte sur des défaillances concernant une zone géographique doit pouvoir être remontée pratiquement en temps réel (par exemple en moins de 10 minutes) à un service clientèle susceptible d’être interrogé par des clients sur les défaillances qu’eux-mêmes constatent (par exemple, si l’utilisateur se plaint de son débit Wi-Fi). Architecture - Généralités Sur la , le boitier 2 est connecté au réseau internet 20 via un réseau opérateur 21. Des serveurs distants 3, typiquement des serveurs de l’opérateur du boîtier d’accès à internet 2, sont disposés dans le réseau opérateur 21. Les différentes données de caractérisation du réseau sont par ailleurs remontées sur un serveur central 300 de l’opérateur où elles sont traitées. Le boitier 2 peut également se connecter à plusieurs plateformes 30 assurant les services distants. Ces plateformes 30 peuvent se trouver dans le réseau internet 20 ou le réseau opérateur 21. Un exemple de liaison entre un serveur 3 et le dispositif 2, illustré en , présente d’amont en aval, - le boitier 2 (chez l’abonné), - un multiplexeur 4 adapté à une technologie DSL, FFTH ou FFTO, etc., situé sur le réseau de l’opérateur local permettant de transmettre les données en provenance ou à destination d’abonnés par regroupement sur un seul support, - un moyen d’agrégation et d’encapsulation 5 de type BRAS (« BNG » en anglais) afin d’entrer dans le réseau opérateur 21, et - un routeur internet 6 permettant d’entrer dans le réseau internet 20. De manière classique, le boîtier d’accès à internet 2 et le serveur 3 comprennent des moyens de traitement de données respectifs de type processeur, et le cas échéant des moyens de stockages de données (une mémoire), par exemple un disque dur. Le boitier 2 génère en outre généralement un réseau local (dit LAN pour Local Access Network) par exemple via une connexion filaire, typiquement en Ethernet. Il peut également être connecté à un ou plusieurs autres équipements 1a, 1b en sans-fil. (Wifi, Bluetooth ou tout autre protocole). Boîtier d’accès à internet Classiquement, un boîtier d’accès à internet 2 dispose d’un certain nombre de données de caractérisation le concernant. Ces données de caractérisation peuvent être des données relatives au fonctionnement dudit boitier et notamment des paramètres de performance calculés par celui-ci, par exemple le débit moyen du WIFI, la latence et plus généralement toute mesure de performance. Les données de caractérisation peuvent également être des données stockées dans le boîtier d’accès à internet 2 et relatives audit boitier : type de boitier, type de WIFI, et plus généralement toute information sur le boitier et son environnement. Le boitier 2 a la particularité d’être adapté pour générer et transmettre à intervalle régulier à destination d’un ou plusieurs serveurs 3 de proximité des messages encapsulant des données de caractérisation mémorisées par ledit boitier, et notamment une ou des valeurs de paramètres de performance. L’envoi des messages aux serveurs 3 par le ou les boitiers d’accès à internet 2 se fait de façon unidirectionnelle (message Unicast). Un serveur 3 auquel différents boitiers 2 envoient leurs messages de caractérisation, est lui-même configuré pour recevoir et traiter les messages qu’il reçoit à intervalle régulier, extraire les données de ces messages et renvoyer en flux tendu les données de caractérisation reçues de plusieurs boitiers sur un serveur central 300. Ces données de caractérisation sont le cas échéant enrichies par le serveur 3. Le serveur 3 est également configuré pour détecter les éventuelles absences de réception de messages attendus en provenance d’un boîtier d’accès à internet 2. L’information quant à une défaillance de réception de message par un boitier 2 fait partie des informations transmises dans le flux de données par le serveur 3 vers le serveur 300. Le serveur central 300 auquel les serveurs 3 sont connectés est configuré pour mémoriser les données de caractérisation qu’il reçoit de différents serveurs 3 de proximité et traiter ces données. Notamment, il les regroupe par catégorie et/ou par zone du réseau et détermine des valeurs pour des indicateurs de performance à partir de celles-ci. En particulier, il met en œuvre des traitements statistiques sur ces données pour déterminer des valeurs d’indicateurs de performance locaux ou à grande échelle sur le réseau. Le serveur central 300 traite également les valeurs d’indicateurs de performance pour générer des messages d’alerte. Par exemple, une alerte peut être générée lorsque la valeur d’un indicateur de performance diverge par rapport une valeur préalablement mémorisée pour une zone du réseau. En variante également, un traitement d’alerte peut prendre en compte l’évolution d’un indicateur de performance et générée une alerte en fonction de cette évolution dans le temps. Différents niveaux d’alerte peuvent être prévus selon l’évolution constatée. Exemple de caractérisation Comme indiqué précédemment, un boîtier d’accès à internet 2 génère et transmet à intervalle régulier à destination du serveur 3 des messages encapsulant des données et est configuré à cet effet. Les boitiers 2 peuvent à cet effet intégrer cette fonctionnalité dès leur déploiement. Cette fonctionnalité peut également être programmée à l’occasion d’une mise à niveau par téléchargement. Les grandes étapes de fonctionnement sont par exemple les suivantes. Au cours d’une étape E1, le boitier d’accès à internet 2 accède à différentes données de caractérisation à transmettre, et notamment à des paramètres de performance déterminés au fil du fonctionnement du boitier 2 ou encore à des données propres au boitier et à son environnement (type de boitier, type de WIFI). Un paramètre de performance peut par exemple être le débit d’une connexion à un service distant d’une plateforme 30, le temps de réponse d’un serveur web vers le boitier 2 ou encore le débit moyen du WiFi du boitier 2. Au cours d’une étape E2, le dispositif 2 encapsule les données dans un protocole de communication utilisant un mode de transmission sans connexion pour former un message. Enfin, au cours d’une étape E3, le message est envoyé par le boîtier d’accès à internet 2 à une ou plusieurs adresses IP @anycast, Le cas où plusieurs adresses sont utilisées permet en effet d’assurer la redondance de la transmission de l’information et la scalabilité. On entend par scalabilité la capacité à répartir la charge des données traitées, par exemple si la quantité de données à traiter augmente sur un ou plusieurs serveurs 3. Selon un mode de mise en œuvre du procédé, la périodicité de la transmission peut être inférieure à une journée, avantageusement inférieure à 6 heures, avantageusement inférieure à 1h, avantageusement supérieure à 1 minutes, préférentiellement moins de 10 minutes. Un serveur 3 destiné à recevoir les messages de caractérisation d’un boitier d’accès à internet 2 est configuré pour recevoir ces messages à intervalle régulier et détecter les éventuelles absences de réception des messages attendus. Un tel serveur 3 extrait en outre les données de caractérisation contenues dans ces messages (étape E11). Le cas échéant, il enrichit ces données par des données relatives à l’environnement du boitier 2 (ADSL, FTTH, opérateur de la ligne, etc.) (étape E12). Par exemple, les données relatives à l’environnement du boitier 2 peuvent être des informations commerciales concernant une résiliation d’un contrat par un client ou bien son déménagement mais aussi techniques comme la manière dont la box est raccordée au réseau. Il est également possible que ces informations proviennent d’un autre périphérique, par exemple un multiplexeur 4 communicant des informations sur la perte d’un boitier 2 sur le réseau 21. Le serveur 3 met ensuite en œuvre des calculs et les données enrichies issues de plusieurs boitiers 2 sont agrégées (étape E13) avant de transmettre en flux tendu à un serveur de centralisation 300 les données agrégées ainsi que les résultats des calculs (étape E14). Par exemple, un calcul réalisé par le serveur 3 peut consister à incrémenter un compteur à chaque perte de synchronisation avec les boitiers 2 afin de constater la perte de messages émis par les boitiers 2. L’agrégation peut consister à regrouper les données enrichies issues de plusieurs boitiers 2 selon plusieurs échelles : - au niveau du multiplexeur 4, où un ensemble 200 de dispositifs sont connectés, - au niveau des cartes 7a, 7b, 7c du multiplexeur 4. Où plusieurs sous-ensembles 201 contiennent une partie de tous les dispositifs 2 connectés au multiplexeur 4, et - au niveau des boucles 22, comprenant l’ensemble des multiplexeurs 4 connectés au routeur 6 d’accès à internet 21. Plusieurs exemples de regroupements sont illustrés en et en . Différents niveaux de caractérisation peuvent être ainsi envisagés afin de dissocier un problème de connexion unitaire, c’est-à-dire sur un boitier 2 isolé, et un problème régional, c’est-à-dire sur une pluralité de boitiers 2 connectés à un multiplexeur 4. Au cours d’une étape E15, les données reçues par le serveur central 300 en provenance de différents serveurs sont agrégées. Un niveau de caractérisation supplémentaire peut être ainsi envisagé. Typiquement par exemple, le serveur 300 met en œuvre des analyses statistiques par indicateur de performances : détermination de moyenne et de percentiles par serveur ou par multiplexeur. Dans un mode de mise en œuvre possible, le serveur 300 détecte des évolutions anormales, par exemple au moyen d’algorithmes à base de Machine Learning auxquels on soumet en entrée les évolutions des indicateurs de performance, en regroupant les messages issus de plusieurs boitiers selon les niveaux de caractérisation possibles. Le traitement des données ainsi groupées peut par exemple consister à faire une moyenne sur chacun des groupes, ou de façon plus globale, des opérations statistiques, puis de comparer les données traitées avec les conditions de connexions mémorisées par le serveur 300. La comparaison peut se faire par exemple par l’intermédiaire d’algorithmes d’intelligence artificielle. Cette comparaison permet d’obtenir un diagnostic de chaque connexion sur un territoire étendu et d’ajuster les performances nominales de ces connexions. Au cours d’une étape E16, le serveur 300 génère un message d’alerte lorsqu’au moins un problème de connexion est détecté : perte franche sur un boitier ; pertes franches sur un ensemble de boitiers d’une même partie d’un réseau ; ou encore pertes de performances sur une partie du réseau. Les messages d’alerte peuvent être à destination du service clientèle. Ils peuvent également être envoyés de façon automatique sur les clients eux-mêmes, le cas échéant en utilisant d’autres canaux de communication que le réseau testé (envoi de courriels et de SMS en parallèle). Au cours d’une étape E17, le serveur central 300 affiche le contenu de la base de données à destination de l’opérateur. Des affichages de cartographies à différentes échelles du réseau sont en outre possible, notamment dans le cadre d’un suivi quasi en temps réel de l’état d’un réseau. Par exemple, le contenu peut être affiché sur un graphe 50 présentant l’évolution d’une grandeur correspondant à un critère de la condition de connexion. La illustre un exemple de courbes pouvant être affichées par le serveur central 300. En abscisse se trouve le temps en minutes, et en ordonné la valeur de la latence « DNS », c’est-à-dire le temps de réponse entre un boitier d’accès à internet 2 et un serveur web, en ms. Dans cet exemple, le critère choisi dans la condition de connexion est une valeur nominale de la latence représentée par une droite horizontale 10 sur le graphe. Pour chaque intervalle de 10 minutes un pic 8 correspondant à la donnée reçu par le serveur 3 lorsque les données sont générées à intervalle régulier. La courbe 9 correspond à la valeur de la latence au cours du temps, la latence pouvant être une des informations contenues dans la donnée du message. Dans la zone 11, aucun message n’arrive au serveur, correspondant à une coupure franche. Dans les zones 12, 13 et 14, les messages sont bien reçus et les informations concernant la latence indiquent une augmentation de sa valeur car la courbe 9 est au-dessus de la valeur nominale de la latence 10, cette valeur nominale pouvant par exemple correspondre à un paramètre de performance. La illustre un autre exemple dans lequel plusieurs courbes 51, 52, 53 correspondent à la valeur de la latence de boucles 22 au cours du temps. Dans cet exemple, le critère choisi dans la condition de connexion est une valeur nominale de la latence. Chaque courbe 54, 55, 56 augmente de manière franche ce qui correspond à une hausse importante de la latence 57. L’augmentation anormale de la latence éloigne la courbe par rapport à la valeur nominale de la latence indiquant une perte de connexion. Le contenu de la base de données peut être affiché sur une carte 40 dans laquelle différents niveaux de criticité liés à un défaut sur le réseau peuvent être en évidence. Trois exemples de cartes sont donnés ci-dessous. La illustre la cartographie des pertes de connectivité détectées à un instant dans une zone à l’échelle d’une boucle 22. Les points 41 correspondent à toutes les boucles où une perte franche a été diagnostiquée dans la zone. La illustre la cartographie du nombre d’anomalies détectées suite à une saturation de l’échange de données entre plusieurs fournisseurs d’accès à l’échelle d’une boucle 22. Chaque motif 42, 43, 44, 45 correspond à un nombre d’anomalies différent. La illustre la cartographie de la latence au niveau national à l’échelle d’un multiplexeur 4. Chaque motif 46, 47, 48, correspond à un niveau de latence différent. Enfin, il est possible de visualiser les résultats sur un graphique à barres 60, les résultats pouvant être classés dans un ordre croissant ou décroissant. Deux exemples de graphiques à barres 60 sont illustrés ci-dessous. La illustre un graphique à barres comportant plusieurs entrées et classant à l’échelle d’une ville le nombre d’anomalies détectées suite à une saturation de l’échange de données entre plusieurs fournisseurs d’accès. Une première colonne 61 répertorie les multiplexeurs sélectionnés, une seconde colonne 62 fait l’inventaire des villes associées aux multiplexeurs sélectionnés et une dernière colonne affiche un nombre d’anomalies 63. La illustre un graphique à barres comportant plusieurs entrées et classant la valeur de la latence à l’échelle d’une région. Une première colonne 64 répertorie les multiplexeurs 4 sélectionnés, une seconde colonne 65 correspond à l’opérateur du multiplexeur 4, une troisième colonne 66 fait l’inventaire des régions associées aux multiplexeurs sélectionnés, et une dernière colonne associe un nombre d’anomalies 67. Le procédé peut être exécuté par un programme d’ordinateur comprenant des instructions de code, lorsque le programme est exécuté par un ordinateur. Le programme d’ordinateur est enregistré dans des moyens de stockage lisibles par un équipement informatique. Procédé de caractérisation d’au moins une partie d’un réseau (20, 21) comportant au moins un boîtier d’accès à internet (2), caractérisé en ce que le boîtier d’accès à internet (2) génère et transmet à intervalle régulier (E3), à destination d’au moins un serveur (3), des messages encapsulant (E2) des données de caractérisation mémorisées dans ledit boîtier (2), lesdites données comportant au moins un paramètre de performance calculé (E1) par ledit boitier (2). Procédé selon la revendication 1, dans lequel les données de caractérisation sont extraites des messages reçus, lesdites données en provenance de différents boîtiers d’accès à internet (2) étant centralisées et traitées pour en déduire au moins une information sur le fonctionnement de tout ou partie du réseau. Procédé selon la revendication précédente, dans lequel le serveur (3) extrait les données de caractérisation des messages reçus (E11) et retransmet à un serveur de centralisation (300) les données de caractérisation qu’il reçoit de différents boitiers. Procédé selon la revendication précédente, dans lequel le serveur (3) ajoute aux données de caractérisation, des données de caractérisation complémentaires (E12), lesdites données de caractérisation complémentaires étant mémorisées par le serveur (3) et comprenant des informations sur l’environnement de connexion des boitiers d’accès à internet (2). Procédé selon l’une des revendications précédentes, dans lequel le (ou les) serveur(s) (3) transmet(tent) les données de caractérisation (E13) à un serveur de centralisation (300) distant, ledit serveur de centralisation (300) traitant les données qu’il reçoit de différents serveurs et générant une alerte (E15) lorsqu’un ou plusieurs messages attendus par un serveur dont il reçoit les données, n’a pas été reçus en provenance d’un boîtier d’accès à internet (2) ou lorsqu’un paramètre de performance contenu dans les données groupées diffère d’une condition de connexion mémorisée par le serveur de centralisation (300). Procédé selon la revendication précédente, dans lequel le serveur de centralisation (300) regroupe les données (E14) en provenance de différents boitiers d’accès à internet (2) et de différents serveurs (3) et met en œuvre au moins un traitement statistique sur celles-ci pour en déduire au moins un indicateur de performance d’au moins une zone donnée sur le réseau et le cas échéant générer des alertes pour au moins un indicateur et au moins une zone. Procédé selon la revendication 5, dans les données de caractérisation sont transmis au serveur de centralisation (300) en flux tendu, les boitiers d’accès à internet (2) transmettant les messages encapsulant les données de caractérisation selon une périodicité inférieure à une journée, avantageusement inférieure à 6 heures, avantageusement inférieure à 1h, avantageusement supérieure à 1 minutes, préférentiellement moins de 10 minutes. Boitier d’accès à internet (2) d’une partie d’un réseau (20, 21), le boitier d’accès à internet (2) étant configuré pour : - calculer un paramètre de performance, - mémoriser des données de caractérisation comprenant le paramètre de performance, - encapsuler les données de caractérisation mémorisées dans un message, et - transmettre à intervalle régulier un message ainsi préparé à un serveur (3). Serveur de centralisation (300) d’un réseau (20, 21) étant configuré pour ledit serveur de centralisation (300) traitant les données qu’il reçoit de différents serveurs et générant une alerte (E15) lorsqu’un ou plusieurs messages attendus par un serveur dont il reçoit les données, n’a pas été reçus en provenance d’un boîtier d’accès à internet (2) ou lorsqu’un paramètre de performance contenu dans les données groupées diffère d’une condition de connexion mémorisée par le serveur de centralisation (300). Produit programme d’ordinateur comprenant des instructions de code, pour l’exécution d’un procédé selon l’une des revendications 1 à 7 lorsque ledit programme est exécuté par un ordinateur Moyens de stockage lisibles par un équipement informatique sur lesquels un produit programme d’ordinateur comprend des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 7.