Brevet FR3136912A1 — publié le 20231222

Procédés de surveillance et de gestion d’objets communicants, équipement de confiance, serveur et objets communicants L’invention propose un procédé de surveillance d’objets communicants par un équipement de confiance associé à un utilisateur, ce procédé de surveillance comprenant : une étape (E40) de détection d’une utilisation par au moins un objet communicant (OBJj) d’au moins un identifiant persistant (P-IDj) ; et une étape (E70,E90) de déclenchement d’au moins une action de brouillage de ladite utilisation par ledit au moins un objet communicant dudit au moins un identifiant persistant. Figure de l’abrégé : Figure 3 Procédés de surveillance et de gestion d’objets communicants, équipement de confiance, serveur et objets communicants L’invention appartient au domaine général des télécommunications. Elle concerne plus particulièrement la gestion d’objets communicants aptes à échanger des données avec une autre entité via une interface de communication. Aucune limitation n’est attachée à la nature d’une telle interface de communication (interface radio telle qu’une interface Bluetooth, Wi-Fi ou une interface d’un réseau mobile, interface réseau telle qu’une interface IP (pour « Internet Protocol » en anglais), etc.) ni à la nature des objets communicants considérés (par exemple montre connectée, capteur, détecteur de mouvement, terminal tel que téléphone mobile ou smartphone, écouteurs sans fil, etc.). L’invention s’applique ainsi par exemple de façon privilégiée mais non limitative aux objets connectés utilisés dans un contexte d’Internet des objets (ou IoT pour « Internet of Things » en anglais). Comme évoqué dans le document RFC 8386 édité par l’IETF de R. Winter et al, intitulé « Privacy Considerations for Protocols Relying on IP Broadcast or Multicast », mai 2018, certains protocoles de communication sont connus pour utiliser des identifiants de façon persistante dans le temps et pour transmettre ces identifiants à d’autres entités, par exemple dans des messages diffusés selon des techniques de type broadcast ou multicast. De tels identifiants, qualifiés de « persistants », peuvent être de différentes natures : adresse MAC (pour « Medium Access Control » en anglais) de l’objet communicant mettant en œuvre le protocole en question, identifiant unique universel (ou UUID pour « Universally Unique IDentifier » en anglais), préfixe ou adresse IP, etc. Ils sont connus pour identifier de façon unique le dispositif communicant auquel ils sont attachés, de sorte que leur utilisation de façon prolongée (autrement dit, de façon persistante) offre la possibilité à des tiers d’obtenir des informations sur, y compris de tracer, le comportement et/ou les habitudes de l’utilisateur du dispositif communicant en question. Un exemple d’un tel traçage, à partir de signaux émis par des écouteurs sans fil possédant une interface Bluetooth ou par un smartphone équipé d’une interface Wi-Fi, est décrit dans l’article de R. Lea publié dans Newsweek et intitulé « How your Bluetooth headphones could be used to track you: ‘Extremely Concerning’ », 6 septembre 2021. L’écoute et l’analyse de ces signaux, qui véhiculent de façon persistante une adresse MAC, permettent d’obtenir des informations sur les déplacements des utilisateurs des dispositifs émettant ces signaux. De telles techniques peuvent être aisément généralisées pour créer des outils collaboratifs qui permettent la collecte à large échelle d’informations qui, une fois corrélées, peuvent porter atteinte à la vie privée des utilisateurs. Par ailleurs, les services caractéristiques de l’Internet des objets (services de télémédecine, de surveillance domestique, etc.) peuvent être fragilisés dans la mesure où les objets connectés supportant ces services sont exposés à des risques de piratage reposant sur le traçage de leurs adresses MAC. A ce titre, on peut signaler certaines attaques par déni de service (ou « Denial of service (DoS) », en anglais) conduites récemment et qui ont exploité cette fragilité en utilisant des objets connectés comme des relais du trafic d’attaque, ce qui a eu pour effet de considérablement amplifier la volumétrie du trafic d’attaque. Une telle attaque a été menée notamment en 2016 contre l’un des hébergeurs de contenus les plus importants d’Europe à partir d’un botnet constitué de près de 150 000 caméras de surveillance IP non protégées qui ont été capables de lancer une attaque par déni de service de plus de 1.5 Tbit/s. Il s’en est suivi une longue indisponibilité d’une partie des serveurs de contenus de l’hébergeur en question. Pour minimiser de tels risques, certains systèmes d’exploitation (ou OS pour « Operating System » en anglais) activent une procédure de randomisation des adresses MAC, c’est-à-dire que ces systèmes d’exploitation ou les objets qui les embarquent (par exemple des terminaux mobiles) utilisent des adresses MAC générées de façon aléatoire pour communiquer avec d’autres objets connectés au même réseau local. Cette procédure n’est toutefois pas supportée par la plupart des technologies mises en œuvre par les objets communicants, et notamment par les objets IoT tels que des détecteurs de mouvement ou des capteurs de température. Enfin, il convient de noter que les utilisateurs ne sont pas forcément informés de la capacité de différents objets communicants à divulguer des identifiants persistants, par exemple lorsqu’ils sont sollicités par un contrôleur pour exécuter une commande de collecte de données ou lorsqu’ils sont exploités pour relayer un trafic d’attaque. On note que bien que décrits en référence à des identifiants persistants tels que des adresses MAC, les inconvénients précités restent valables pour d’autres types d’identifiants persistants, comme des adresses ou des préfixes IP, UUID, etc. L’invention propose un mécanisme permettant notamment de remédier à ces inconvénients, et pouvant avantageusement s’appliquer à tout type d’identifiant persistant (adresse MAC, adresse ou préfixe IP, UUID, etc.). Plus spécifiquement, l’invention concerne un procédé de surveillance d’objets communicants par un équipement de confiance associé à un utilisateur, ce procédé de surveillance comprenant : une étape de détection d’une utilisation par au moins un objet communicant d’au moins un identifiant persistant ; et une étape de déclenchement d’au moins une action de brouillage de ladite utilisation par ledit au moins un objet communicant dudit au moins un identifiant persistant. Corrélativement, l’invention vise également un équipement de confiance associé à un utilisateur, configuré pour surveiller des objets communicants, cet équipement de confiance comprenant : un module de détection, configuré pour détecter une utilisation par au moins un objet communicant d’au moins un identifiant persistant ; et un module de déclenchement, configuré pour déclencher au moins une action de brouillage de ladite utilisation par ledit au moins un objet connecté dudit au moins un identifiant persistant. Aucune hypothèse n’est faite quant à la nature des équipements impliqués dans l’invention, qu’il s’agisse des objets communicants (qui peuvent être par exemple, comme évoqué précédemment, des capteurs, des terminaux, des montres connectées, des écouteurs sans fil, des caméras de type webcam, etc.) ou de l’équipement de confiance (qui peut être notamment un terminal tel qu’un smartphone, une set top box, un équipement de type CPE (pour « Customer Premises Equipment » en anglais), etc.), ni quant à la nature des interfaces de communication utilisées par les objets communicants (par exemple, une interface de communication radio telle qu’une interface Bluetooth ou Wi-Fi, une interface de réseau IP, etc.). Par ailleurs, un équipement de confiance peut être associé à un ou plusieurs utilisateurs. Ainsi, l’invention propose un mécanisme s’appuyant sur la détection de l’utilisation d’identifiants persistants par des objets communicants situés « à proximité » d’un équipement de confiance pour l’utilisateur (c’est-à-dire visibles par celui-ci) et sur le contrôle de cette utilisation via une action de brouillage déclenchée par l’équipement de confiance. L’équipement de confiance est avantageusement associé à l’utilisateur, autrement dit, c’est un équipement de confiance pour ce dernier, mandaté par celui-ci ou avec son accord, pour surveiller une zone donnée (il peut par exemple avoir été désigné ou choisi par celui-ci pour surveiller une zone particulière). Cette confiance peut être accordée par l’utilisateur à l’équipement en question par exemple parce qu’il lui appartient, le gère ou en assume la responsabilité d’utilisation. Par exemple, un CPE est souvent la propriété du fournisseur du service de connectivité ; dans ce cas, le client (utilisateur au sens de l’invention) peut alors signifier son accord au fournisseur du service de connectivité, par exemple lors de sa souscription au service de connectivité, pour que le CPE joue le rôle d’un équipement de confiance au sens de l’invention. Un utilisateur peut aussi utiliser l’interface de gestion du CPE ou un portail dédié de l’opérateur pour indiquer son consentement. Elle peut en outre être renforcée par des moyens matériels, informatiques, logiciels ou de sécurité informatique, etc. La zone surveillée par l’équipement de confiance associé à l’utilisateur n’est pas nécessairement géographique, elle peut être liée à un réseau, à une adresse ou un préfixe IP, etc. En outre, différentes configurations peuvent être envisagées : une même zone peut être surveillée par un ou plusieurs équipements de confiance associés à un même utilisateur, ou des équipements de confiance distincts peuvent être configurés pour surveiller des zones distinctes, par exemple en fonction de la nature des services associés à l’utilisation des objets communicants surveillés (par exemple une zone « IoT » pour les objets connectés en réseau, une zone « professionnelle » pour les objets communicants utilisés à des fins strictement professionnelles (par exemple un réseau d’entreprise), une zone « personnelle » pour les objets communicants utilisés à des fins strictement personnelles, etc.). Il convient de noter que les objets communicants surveillés par l’équipement de confiance n’appartiennent pas nécessairement à l’utilisateur. Il se peut toutefois que le contexte dans lequel ces objets opèrent, et/ou la corrélation des identifiants persistants qu’ils utilisent, révèlent des informations d’identification de l’utilisateur. L’utilisateur peut ainsi choisir et/ou configurer un équipement de confiance pour qu’il surveille tous les objets communicants qu’il est susceptible de détecter dans le périmètre d’une zone dans laquelle l’utilisateur se trouve ou désire se rendre (ou plus généralement, les zones où l’utilisateur est susceptible d’être présent). L’équipement de confiance peut d’ailleurs être fixe ou mobile. Par ailleurs, aucune hypothèse n’est faite quant à la manière dont l’équipement de confiance peut détecter de tels objets communicants. Cette détection peut ainsi être effectuée selon plusieurs méthodes : elle peut par exemple s’appuyer sur l’existence d’une connexion réseau (via un réseau câblé ou sans fil ou les deux) avec les objets en question, sur un mécanisme de balayage des signaux émis au travers d’une ou plusieurs interfaces radio (par exemple Bluetooth, Wi-Fi), sur les informations reçues d’une entité tierce ou des objets communicants eux-mêmes, sur l’écoute de signaux diffusés par les objets communicants (par exemple diffusés en mode broadcast ou multicast), etc., voire une combinaison de tout ou partie de ces méthodes. En tout état de cause, ces objets communicants se trouvent dans une zone de détection gérée par l’équipement de confiance et où leur présence est visible de ce dernier. En brouillant l’utilisation d’un identifiant persistant par un objet communicant détecté par l’équipement de confiance associé à un utilisateur, l’invention rend avantageusement caduques les informations d’identification relatives à l’utilisateur que cette utilisation est susceptible de divulguer. Ces actions de brouillage viennent en effet ajouter un bruit par rapport à l’utilisation de l’identifiant persistant, contrôlable par l’équipement de confiance (notamment en ce qui concerne son niveau, sa localisation, etc.), de sorte qu’un tiers mal intentionné n’est plus en mesure d’exploiter un identifiant persistant pour en déduire des informations d’identification non-ambigües d’un utilisateur. En raison de la pluralité et de la diversité des actions de brouillage pouvant être exécutées, l’invention permet en outre de s’adapter aux contraintes des objets communicants, par exemple selon qu’ils sont capables ou non d’exécuter de telles actions, selon le contexte dans lequel ils et/ou l’utilisateur se trouvent, et/ou selon le niveau de sécurisation des données caractéristiques de l’utilisateur. D’autres facteurs peuvent bien entendu être pris en compte pour sélectionner la ou les actions de brouillage à déclencher. Ainsi, dans un mode particulier de réalisation, le procédé de surveillance comprend en outre pour au moins un dit objet communicant identifié lors de l’étape de détection et au moins un identifiant persistant utilisé par cet objet communicant, une étape de détermination si ledit objet communicant est apte à exécuter une dite action de brouillage de l’utilisation de cet identifiant persistant, l’étape de déclenchement comprenant le cas échéant l’envoi d’une commande à cet objet communicant pour qu’il exécute ladite action de brouillage. L’équipement de confiance peut en outre vérifier si l’objet communicant est sous le contrôle de l’utilisateur, typiquement s’il lui appartient ou si l’utilisateur le gère. Le contrôle de l’objet communicant par l’utilisateur facilite en effet la commande de l’objet communicant pour déclencher l’exécution d’une action de brouillage localement le cas échéant (si l’objet en est capable). Une telle action de brouillage comprend par exemple une utilisation par l’objet communicant en question d’un autre identifiant de même nature que ledit identifiant persistant à la place de celui-ci, cet autre identifiant pouvant être choisi par l’objet communicant ou par l’équipement de confiance ou encore par une entité tierce de confiance. Ainsi à titre illustratif, lorsque l’identifiant persistant considéré est une adresse MAC, l’action de brouillage peut consister en l’activation d’une action de randomisation d’adresses MAC par l’objet communiquant, dès lors que celui-ci est apte à mettre en œuvre une telle technique. Lorsqu’une telle action de brouillage consistant à remplacer l’identifiant persistant par un autre identifiant de même nature est exécutée par l’objet communicant et déclenchée par l’équipement de confiance, le procédé de surveillance peut en outre comprendre une étape de mise à jour d’au moins une règle d’acheminement et/ou de filtrage de trafic relative à l’objet communicant avec ledit autre identifiant. Cette mise à jour permet d’éviter que le service fourni ou observé par l’objet communicant soit impacté ou dégradé par le changement d’identifiant. Autrement dit, la mise à jour vise à faire en sorte que les services rendus ou accessibles par l’objet communicant ne soient pas pénalisés lorsqu’il va utiliser l’autre identifiant en remplacement de l’identifiant persistant, et que ce remplacement soit transparent pour le service fourni ou observé par l’objet communicant. Dans un mode de réalisation, pour au moins un dit objet communicant identifié lors de l’étape de détection et au moins un identifiant persistant utilisé par cet objet communicant, l’étape de déclenchement comprend un envoi à au moins un serveur distant d’une instruction pour déclencher une utilisation de cet identifiant persistant par au moins un autre objet communicant sélectionné par ledit au moins un serveur distant. L’équipement de confiance et le serveur distant entretiennent eux-mêmes une relation de confiance de façon privilégiée ; cette relation de confiance peut être établie par exemple via un mécanisme d’authentification mutuelle préalable mis en œuvre lors de l’établissement d’une connexion entre l’équipement de confiance et le serveur distant. On note qu’une ou plusieurs connexions peuvent être établies entre un équipement de confiance et ledit serveur, notamment lorsque ledit équipement de confiance est associé à plusieurs utilisateurs. Ce mode de réalisation peut être utilisé en complément ou en remplacement du mode de réalisation précédent, en fonction du contexte. Par exemple, il peut être mis en œuvre lorsque l’objet communicant n’appartient pas à l’utilisateur ou plus généralement n’est pas sous le contrôle de l’utilisateur (et ne peut donc pas être contrôlé aisément par l’équipement de confiance), et/ou lorsque l’objet communicant n’est pas capable d’exécuter une action de brouillage. Dans ce cas, grâce à ce mode de réalisation, l’équipement de confiance peut s’adresser à un serveur distant gérant d’autres objets communicants pour qu’une ou des actions de brouillage soient déclenchées et exécutées par tout ou partie de ces autres objets communicants. Les actions de brouillage déclenchées auprès de ces autres objets communicants incluent par exemple une utilisation de l’identifiant persistant par ces autres objets communicants. Cette utilisation peut être réelle, c’est-à-dire que l’identifiant persistant est effectivement utilisé par l’objet communicant pour communiquer avec d’autres entités, ou fictive, simulée, c’est-à-dire que l’utilisation est feinte, l’objet simule une utilisation de l’identifiant persistant mais il ne s’en sert pas pour ses besoins propres. On désigne ici par « émulation d’un identifiant persistant » une telle utilisation fictive. Ainsi, un exemple d’émulation d’un identifiant persistant par un objet communicant consiste à affecter l’identifiant persistant à une interface de l’objet communicant (cette affectation pouvant être choisie par le serveur ou par l’objet communicant lui-même) et à annoncer cet identifiant de sorte qu’il soit visible des équipements situés dans le voisinage immédiat de l’objet communicant (de tels équipements scannent par exemple les signaux émis par l’objet communicant ou analysent les messages qu’il envoie) ; toutefois, l’identifiant persistant n’est pas, dans le cadre de cette émulation, utilisé par l’objet communicant pour ses besoins propres, par exemple lorsqu’il envoie un rapport d’activité à la demande d’un contrôleur externe. En outre, l’objet communicant peut aussi être configuré pour rejeter toute tentative et/ou demande d’établissement de connexion associée à l’identifiant persistant qui lui a été affecté. On note qu’un même objet communicant peut être configuré pour émuler plusieurs identifiants distincts. De la sorte, on brouille les informations d’identification susceptibles d’être révélées sur l’utilisateur par l’utilisation de ce ou ces identifiants persistants, puisque ce ou ces identifiants persistants sont utilisés par plusieurs objets communicants (celui détecté par l’équipement de confiance et celui ou ceux mandatés par le serveur distant). En effet, grâce à ce mode de réalisation, on élargit la zone dans laquelle se trouvent les objets communicants qui peuvent, en utilisant le ou les identifiants persistants détectés par l’équipement de confiance, participer au brouillage des informations susceptibles d’être révélées par l’utilisation de ces identifiants. Dans un mode particulier de réalisation, l’instruction envoyée au serveur distant peut comprendre en outre d’autres indications, comme par exemple une indication d’une durée d’utilisation dudit identifiant persistant par ledit au moins un autre objet communicant et/ou une indication d’une zone à laquelle doit être rattaché ledit au moins un autre objet communicant auquel il est demandé d’utiliser l’identifiant persistant. Bien entendu ces exemples ne sont donnés qu’à titre illustratif, et d’autres indications peuvent être envisagées. Dans une variante de réalisation, les indications précitées ou d’autres indications (ex. nombre maximum d’identifiants persistants associés à un utilisateur, niveau de brouillage souhaité, type d’identifiants persistants concernés, identités des équipements de confiance associés à l’utilisateur, etc.) peuvent être disponibles dans un profil associé à l’utilisateur, accessible par le serveur distant. Ce profil peut avoir été fourni au serveur distant ou avoir été identifié auprès du serveur distant par l’équipement de confiance, par exemple lors de l’authentification mutuelle de l’équipement de confiance et du serveur distant, ou encore être rendu accessible par le serveur distant dans une base de données, etc. Dans le cas évoqué précédemment où un équipement de confiance est associé à plusieurs utilisateurs et une seule connexion est établie entre l’équipement de confiance et le serveur, on peut envisager de renseigner l’identifiant de l’un desdits utilisateurs lors de la sollicitation du serveur pour déclencher une action de brouillage afin que le serveur puisse associer cette sollicitation au profil de l’utilisateur concerné. Ainsi, comme il apparaît au vu de ce qui vient d’être décrit, l’invention s’appuie sur un ou plusieurs équipements de confiance associés à l’utilisateur mais également sur les objets communicants surveillés par ces équipements de confiance et aptes à exécuter des actions de brouillage, sur un ou plusieurs serveurs distants qui peuvent être mandatés par le ou les équipements de confiance pour mettre en œuvre des actions de brouillage des utilisations d’identifiants persistants détectées le cas échéant par ledit ou lesdits équipements de confiance, ainsi que sur les objets communicants commandés par ce ou ces serveurs distants pour exécuter ces actions de brouillage. Selon un autre aspect, l’invention vise donc également un procédé de gestion d’objets communicants par un serveur, ce procédé de gestion comprenant : une étape de réception, en provenance d’un équipement de confiance associé à un utilisateur, d’une instruction pour déclencher une utilisation d’au moins un identifiant persistant donné par au moins un objet communicant géré par ledit serveur ; une étape de sélection, pour ledit au moins un identifiant persistant désigné dans ladite instruction et pour ledit utilisateur, d’au moins un objet communicant parmi une pluralité d’objets communicants gérés par le serveur, apte à utiliser ledit au moins un identifiant persistant ; et une étape d’envoi d’une commande audit au moins un objet communicant sélectionné pour qu’il utilise ledit au moins un identifiant persistant. Corrélativement, l’invention concerne aussi un serveur configuré pour gérer des objets communicants, ce serveur comprenant : un module de réception, configuré pour recevoir en provenance d’au moins un équipement de confiance associé à un utilisateur, au moins une instruction pour déclencher une utilisation d’au moins un identifiant persistant donné par au moins un objet communicant géré par ledit serveur ; un module de sélection, configuré pour sélectionner pour ledit au moins un identifiant persistant désigné dans ladite au moins une instruction et pour ledit utilisateur, d’au moins un objet communicant parmi une pluralité d’objets communicants gérés par le serveur apte à utiliser ledit au moins un identifiant persistant ; et un module de contrôle, configuré pour envoyer une commande audit au moins un objet communicant sélectionné pour qu’il utilise ledit au moins un identifiant persistant. Le procédé de gestion et le serveur selon l’invention participent aux mêmes avantages cités précédemment que le procédé de surveillance et l’équipement de confiance selon l’invention. Dans un mode particulier de réalisation, le procédé de gestion comprend en outre avant d’exécuter l’étape de sélection et l’étape de configuration, une étape d’authentification de l’équipement de confiance associé à l’utilisateur. Comme mentionné précédemment, cette étape permet d’assurer une relation de confiance entre l’équipement de confiance et le serveur distant. Elle peut s’accompagner par ailleurs d’une étape consistant à vérifier que l’équipement de confiance est bien autorisé à envoyer une telle instruction au serveur distant pour ledit utilisateur. Dans un mode particulier de réalisation, ledit au moins un objet communicant auquel est envoyée la commande pour utiliser ledit au moins un identifiant persistant est sélectionné par le serveur parmi une pluralité d’objets communicants gérés par celui-ci et rattachés à une zone définie pour ou par l’utilisateur. Dans un mode de réalisation, au moins un dit objet communicant auquel est envoyée la commande pour utiliser ledit au moins un identifiant persistant est sélectionné aléatoirement par le serveur ou en fonction d’au moins une contrainte définie pour ou par l’utilisateur. Dans un mode particulier de réalisation, le procédé de gestion comprend en outre pour au moins un dit objet communicant sélectionné pour l’utilisateur, une étape d’annulation ou une étape de renouvellement de ladite commande d’utilisation dudit au moins un identifiant persistant pour lequel ledit objet communicant a été sélectionné. Ces modes de réalisation offrent une grande flexibilité pour la sélection des objets communicants utilisant le ou les identifiants persistants et/ou leur configuration, et permet d’adapter cette sélection et/ou cette configuration au contexte, ainsi qu’aux besoins de l’utilisateur et/ou à ses préférences. Selon un autre aspect encore, l’invention vise également un procédé d’utilisation d’un identifiant par un objet communicant, ledit procédé comprenant : - une étape de réception, en provenance d’un serveur, d’une commande pour utiliser un identifiant persistant déjà utilisé par un autre objet communicant, ladite commande fournissant audit objet communicant une indication d’au moins un comportement à adopter par ledit objet communicant en cas de tentative et/ou de demande d’établissement d’une connexion par un dispositif tiers avec l’objet communicant au moyen dudit identifiant persistant ; - une étape d’utilisation dudit identifiant persistant et de mise en œuvre dudit au moins un comportement. Corrélativement, l’invention concerne aussi un objet communicant comprenant : - un module de réception configuré pour recevoir, en provenance d’un serveur, une commande pour utiliser un identifiant persistant déjà utilisé par un autre objet communicant, ladite commande fournissant audit objet communicant une indication d’au moins un comportement à adopter par ledit objet communicant en cas de tentative et/ou de demande d’établissement d’une connexion par un dispositif tiers avec l’objet communicant au moyen dudit identifiant persistant ; - un module d’exécution configuré pour utiliser ledit identifiant persistant et mettre en œuvre ledit au moins un comportement. Un comportement à adopter par l’objet communicant en cas de tentative et/ou de demande d’établissement d’une connexion est typiquement le rejet de la tentative et/ou de la demande d’établissement de connexion, le traçage des tentatives et/ou des demandes d’établissement de connexion, l’établissement de la connexion, etc. Cette indication fournie par le serveur permet de définir un mode d’utilisation de l’identifiant persistant par l’objet communicant, à savoir s’il doit émuler l’identifiant persistant (autrement dit l’utiliser de façon fictive, et l’annoncer sans établir de connexion associée à cet identifiant persistant ni s’en servir pour ses propres besoins), ou au contraire l’utiliser de façon réelle. Ce mode d’utilisation peut différer en fonction du contexte, ou des objets communicants mandatés par le serveur pour utiliser l’identifiant persistant. En effet, si un tiers malveillant parvient à détecter que plusieurs objets communicants sont configurés pour émuler un identifiant persistant et pour rejeter systématiquement toute tentative et/ou demande d’établissement de connexion sur la base de cet identifiant persistant, cela peut éveiller des soupçons auprès de ce tiers et réduire l’efficacité du brouillage mis en œuvre par l’invention. Les avantages associés à l’objet communicant et au procédé d’utilisation selon l’invention sont les mêmes que ceux cités précédemment pour l’équipement de confiance et pour le serveur ainsi que pour les procédés de surveillance et de gestion mis en œuvre respectivement par ces derniers. Selon un autre aspect encore, l’invention vise un procédé d’exécution d’une action de brouillage par un objet communicant, ce procédé comprenant : - une étape d’utilisation d’un identifiant persistant ; - une étape de réception d’une commande en provenance d’un équipement de confiance associé à un utilisateur pour que l’objet communicant exécute une action de brouillage de l’utilisation dudit identifiant persistant ; et - une étape d’exécution de ladite action de brouillage. Corrélativement, l’invention vise aussi un objet communicant comprenant : - un module de communication, configuré pour utiliser un identifiant persistant ; - un module de réception, configuré pour recevoir en provenance d’un équipement de confiance associé à un utilisateur (U) une commande pour que l’objet communicant exécute une action de brouillage de l’utilisation dudit identifiant persistant par ledit module de communication ; et - un module d’exécution configuré pour exécuter ladite action de brouillage. Comme évoqué précédemment, une telle action de brouillage commandée par l’équipement de confiance est par exemple la génération et l’utilisation par l’objet communicant d’un autre identifiant de même nature que l’identifiant persistant à la place de ce dernier. Elle s’applique de façon privilégiée à l’ensemble des connexions en cours de l’objet communicant qui utilisaient l’identifiant persistant. Les avantages associés à l’objet communicant et au procédé d’exécution selon l’invention sont les mêmes que ceux cités précédemment pour l’équipement de confiance, pour le serveur, et pour l’objet communicant selon l’invention ainsi que pour les procédés de surveillance, de gestion et d’utilisation selon l’invention mis en œuvre respectivement par ces derniers. Dans un mode particulier de réalisation, les procédés de surveillance, de gestion, d’utilisation et d’exécution sont mis en œuvre par un ordinateur. L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans un équipement de confiance conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé de surveillance tel que décrit ci-dessus. L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans un serveur conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé de gestion tel que décrit ci-dessus. L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans un objet communicant conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé d’utilisation tel que décrit ci-dessus. L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans un objet communicant conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé d’exécution tel que décrit ci-dessus. Chacun de ces programmes peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. L’invention vise aussi un support d'information ou un support d’enregistrement lisibles par un ordinateur, et comportant des instructions d’un programme d'ordinateur tel que mentionné ci-dessus. Le support d'information ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur, ou une mémoire flash. D'autre part, le support d'information ou d’enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'information ou d’enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés de surveillance, de gestion, d’utilisation et d’exécution selon l’invention. Selon un autre aspect, l’invention vise aussi un système de brouillage comprenant : au moins un équipement de confiance associé à un utilisateur conforme à l’invention, configuré pour surveiller des objets communicants ; au moins un serveur conforme à l’invention ; et une pluralité d’objets communicants comprenant au moins un objet communicant conforme à l’invention (typiquement un objet communicant configuré pour mettre en œuvre le procédé d’exécution et/ou un objet communicant configuré pour mettre en œuvre le procédé d’utilisation). Les avantages associés à ce système de brouillage sont les mêmes que ceux cités précédemment pour l’équipement de confiance et pour le serveur ainsi que pour les procédés de surveillance et de gestion mis en œuvre respectivement par ces derniers. En outre, comme mentionné précédemment, l’invention s’applique à différents types d’identifiants persistants. Par exemple au moins un dit identifiant persistant est : une adresse MAC, Medium Access Layer ; une adresse IP, Internet Protocol ; un préfixe IP ; un identifiant d’ensemble de service SSID, Service Set IDentifier ; un identifiant de l’équipement de confiance ; ou un identifiant affecté à une interface radio. On peut également envisager, dans d'autres modes de réalisation, que les procédés de surveillance, d’utilisation, d’exécution et de gestion, l’équipement de confiance, le serveur, les objets communicants et le système de brouillage selon l’invention présentent en combinaison tout ou partie des caractéristiques précitées. D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : la représente, dans son environnement, un système de brouillage conforme à l’invention, dans un mode particulier de réalisation ; la représente schématiquement l’architecture matérielle d’un ordinateur pouvant être ou héberger un équipement de confiance ou un serveur ou encore un objet communicant du système de brouillage de la ; la représente les principales étapes d’un procédé de surveillance selon l’invention telles que mises en œuvre dans un mode particulier de réalisation par un équipement de confiance du système de brouillage de la ; la représente les principales étapes d’un procédé d’exécution selon l’invention, telles que mises en œuvre dans un mode particulier de réalisation par un objet communicant du système de brouillage de la ; la représente les principales étapes d’un procédé de gestion selon l’invention telles que mises en œuvre dans un mode particulier de réalisation par un serveur du système de brouillage de la ; la illustre un exemple de cartes d’objets communicants émulant un identifiant persistant et évoluant dans le temps (figure 6A puis figure 6B) ; et la représente les principales étapes d’un procédé d’utilisation selon l’invention, telles que mises en œuvre dans un mode particulier de réalisation par un objet communicant du système de brouillage de la . Description de l’invention La représente un système 1 de brouillage (ou « jamming » ou « blurring » en anglais) conforme à l’invention, dans un mode particulier de réalisation. Le système 1 de brouillage est configuré pour offrir à des utilisateurs un service S dit de brouillage, aussi désigné ici par MANTEC pour « MANaging privacy inferred by nearby connecTEd objeCts » en anglais. Ce service MANTEC S consiste à détecter l’utilisation d’identifiants persistants par des objets communicants, ces identifiants persistants étant susceptibles de divulguer des informations d’identification relatives auxdits utilisateurs (par exemple informations sur leurs identités, leurs habitudes, leurs comportements, leurs localisations, etc.), et à déclencher des actions de brouillage d’une telle utilisation afin de rendre caduques lesdites informations d’identification qu’on pourrait ainsi obtenir. Le système 1 de brouillage rend ainsi inexploitables les informations qu’on pourrait tirer de l’utilisation d’identifiants persistants, notamment à des fins frauduleuses. Aucune hypothèse n’est faite quant à la nature des objets communicants susceptibles d’utiliser de tels identifiants persistants, ni sur les identifiants persistants en question. Ainsi, par exemple, les objets communicants peuvent être des capteurs, des terminaux tels que des smartphones ou des tablettes numériques, des montres connectées, des écouteurs sans fil, des caméras de type webcam, etc., disposant d’une ou de plusieurs interfaces de communication via laquelle ou lesquelles ils peuvent échanger des données avec d’autres entités. Une telle interface de communication peut être une interface radio (ex. Bluetooth, Wi-Fi, réseau mobile cellulaire, etc.), une interface de réseau IP (câblée ou sans fil ou les deux), etc. Par ailleurs, un identifiant persistant désigne tout type d’information identifiant de façon unique ou non ambigüe le dispositif communicant auquel il est associé, de sorte que son utilisation de façon prolongée (c’est-à-dire de façon persistante, d’où son appellation) offre la possibilité à des tiers d’obtenir des informations sur (y compris de tracer) l’identité, le comportement et/ou les habitudes de l’utilisateur du dispositif communicant en question. Il peut s’agir par exemple d’une adresse MAC, d’une adresse IP ou d’un préfixe IP, d’un UUID ou SSID, d’un nom associé au dispositif communicant diffusé ou affecté à une interface de communication (ex. « écouteurs de Bob »), etc. La durée d’utilisation au-delà de laquelle il est considéré par le système 1 de brouillage qu’un identifiant est persistant peut varier en fonction du contexte et de la nature de l’identifiant. Par exemple, on peut considérer une durée d’utilisation maximale de 24h pour une adresse IP, ou de 60 minutes pour une adresse MAC. Dans le mode de réalisation décrit ici, pour offrir le service S, le système 1 de brouillage comprend les éléments suivants : au moins un équipement 2 de confiance, conforme à l’invention, et associé à au moins un utilisateur U ayant souscrit auprès d’un opérateur OP au service S, un utilisateur U pouvant comprendre une ou plusieurs personnes (par exemple, un groupe d’employés d’une entreprise). Par exemple, l’équipement 2 de confiance a été choisi par l’utilisateur U et déclaré en tant que tel par celui-ci auprès de l’opérateur OP lors de la souscription au service S ou ultérieurement. Cette confiance accordée à l’équipement 2 par l’utilisateur U peut être motivée par différentes raisons ; par exemple, l’utilisateur U est propriétaire de l’équipement 2 de confiance, ou il le gère, ou encore il en assume la responsabilité d’utilisation. Elle peut être renforcée par des moyens informatiques ou logiciels, ou par tout autre moyen (par exemple matériels ou contextuels). Un tel équipement 2 de confiance peut être notamment le smartphone de l’utilisateur U ou sa montre connectée, un équipement de type CPE ou une set-top-box, une télévision connectée, une caméra de type webcam, ou un objet dédié à l’invention, etc. On note que l’équipement 2 de confiance peut être indifféremment fixe ou mobile ; au moins un serveur 3 conforme à l’invention (aussi désigné par « serveur MANTEC 3 » dans la suite de la description), apte à communiquer avec l’équipement 2 de confiance et à l’assister, sur requête de ce dernier, pour la mise en œuvre d’actions de brouillage ; et une pluralité d’objets communicants comprenant notamment des objets communicants O1, …, Om, m désignant un entier supérieur ou égal à 1, gérés par ledit au moins un serveur MANTEC 3 et auxquels le serveur MANTEC 3 peut s’adresser pour exécuter des actions de brouillage lorsqu’il assiste l’équipement 2 de confiance. Les objets communicants O1, …, Om sont donc aptes à et configurés pour, sur demande du serveur MANTEC 3, exécuter des actions de brouillage de l’utilisation d’un ou de plusieurs identifiants donnés, indiqués par le serveur MANTEC 3 (un même objet communicant peut exécuter des actions de brouillage de plusieurs identifiants distincts, et plusieurs objets communicants peuvent exécuter des actions de brouillage d’un même identifiant). Dans le mode de réalisation décrit ici, les objets communicants O1, …, Om sont conformes à l’invention et l’action de brouillage qu’ils sont en mesure d’exécuter est l’utilisation d’un ou plusieurs identifiants désignés par le serveur MANTEC 3 selon un mode d’utilisation défini par le serveur MANTEC 3. Différents modes d’utilisation de ce ou ces identifiants peuvent être envisagés. Ainsi, par exemple, une action de brouillage exécutée par un objet communicant O1, …, Om peut consister à émuler un identifiant, c’est-à-dire à « simuler » son utilisation : l’identifiant en question est affecté à une interface de communication de l’objet communicant (l’interface en question peut être choisie par l’objet communicant ou par le serveur MANTEC 3) et annoncé par celui-ci de sorte à le rendre visible des équipements situés dans son voisinage immédiat et qui sont à l’écoute des signaux et/ou des messages émis via cette interface. En revanche, dans le cadre de cette émulation, cet identifiant n’est pas utilisé par l’objet communicant pour les besoins des services pour lesquels l’objet communicant est nativement utilisé et auxquels l’objet communicant est destiné (par exemple, pour collecter des données qui peuvent être transmises à un contrôleur externe de façon régulière). En variante, on peut envisager que le serveur MANTEC 3 demande à un objet communicant d’utiliser de façon réelle un identifiant donné, c’est-à-dire de l’affecter à l’une de ses interfaces (l’interface en question peut être choisie par l’objet communicant ou par le serveur MANTEC 3), de l’annoncer, et d’établir des connexions avec d’autres entités sur la base de cet identifiant. De tels objets communicants peuvent être destinés exclusivement à la mise en œuvre de l’invention (c’est-à-dire être des objets communicants dédiés au brouillage d’identifiants persistants) ou non. Il peut s’agir d’objets communicants déjà existants et prévus à d’autres fins et exploités par ailleurs pour les besoins de l’invention (par exemple, des CPE, des hotspots, des routeurs, ou des objets de l’IoT). Chaque équipement 2 de confiance associé à l’utilisateur U est configuré pour surveiller des objets communicants O1’, O2’, …, Ok’, k désignant un entier supérieur ou égal à 1, situés dans son « voisinage ». Tout ou partie de ces objets communicants peuvent être conformes à l’invention et disposer de modules configurés pour mettre en œuvre un procédé d’exécution selon l’invention pour participer à la mise en œuvre du service S. Le cas échéant, les objets communicants ainsi configurés parmi les objets communicants O1’, O2’, …, Ok’ appartiennent au système 1 de brouillage. Dans l’exemple envisagé ici, les objets communicants O1’, O2’, …, Ok’, se trouvent dans le voisinage immédiat de l’équipement 2 de confiance, lequel voisinage peut être un voisinage radio, c’est-à-dire que l’équipement 2 de confiance est en mesure de recevoir des signaux radio émis le cas échéant par de tels objets communicants (ex. signaux Bluetooth, Wi-Fi, etc.), et/ou un voisinage réseau, c’est-à-dire que l’équipement 2 de confiance est en mesure de recevoir des messages émis le cas échéant par de tels objets, par exemple via un réseau local (ex. messages ARP (pour « Address Resolution Protocol » en anglais) diffusés en broadcast). Par exemple, à titre illustratif, l’équipement 2 de confiance peut être un CPE raccordé à un réseau local et les objets communicants O1’, O2’, …, Ok’ des dispositifs connectés au réseau local. En variante, on peut également envisager que l’équipement 2 de confiance soit configuré pour surveiller en outre des objets communicants situés dans un voisinage moins immédiat comprenant le voisinage radio/réseau immédiat du voisinage radio/réseau immédiat de l’équipement 2 de confiance qui vient d’être décrit. En d’autres termes, selon cette variante, les objets communicants se trouvant dans le voisinage radio et/ou réseau des objets communicants détectés par l’équipement 2 de confiance dans son voisinage radio et/ou réseau immédiat, peuvent également être surveillés par l’équipement 2 de confiance. A cet effet, l’équipement 2 de confiance peut recevoir les signaux et/ou messages envoyés par les objets communicants se trouvant dans son voisinage moins immédiat via les objets communicants se trouvant dans son voisinage immédiat ou via d’autres dispositifs intermédiaires. Ainsi, selon cette variante, dès lors que l’équipement 2 de confiance est en mesure de détecter des signaux et/ou des messages envoyés par un objet communicant reçus directement de cet objet communicant ou via un dispositif intermédiaire, l’objet communicant en question est considéré comme se trouvant dans le voisinage de l’équipement 2 de confiance et est susceptible d’être surveillé par celui-ci. Il convient de noter que les objets communicants surveillés par l’équipement 2 de confiance n’appartiennent pas nécessairement à l’utilisateur U. Il se peut toutefois que le contexte dans lequel ils opèrent, et/ou la corrélation des identifiants persistants qu’ils utilisent, peuvent révéler des informations d’identification de l’utilisateur U. On note en outre qu’un équipement 2 de confiance peut être configuré par l’utilisateur U pour opérer une telle surveillance de façon permanente ou seulement lorsqu’il se trouve dans une zone dite de surveillance donnée (par exemple une zone dans laquelle l’utilisateur U se trouve ou envisage de se rendre). Une telle zone de surveillance peut être caractérisée par un ou plusieurs paramètres tels qu’un identifiant de réseau (ex. un identifiant SSID pour « Service Set IDentifier » d’un réseau local de type WLAN (pour « Wireless Local Access Network » en anglais)), une adresse ou un préfixe IP (IPv4 ou IPv6) alloué à l’équipement 2 de confiance, des coordonnées GPS (pour « Global Positioning System » en anglais), ou encore une combinaison de tels paramètres. Elle peut comprendre plusieurs sous-zones définies pour un même équipement 2 de confiance par exemple au moyen d’une opération OU « OR(value1,value2,…) » où « value1, value2,… » désignent des valeurs du paramètres considéré dans les sous-zones en question, ou une opération ET « AND(value1,value2,…) » lorsque plusieurs paramètres sont envisagés pour caractériser la zone de surveillance, ou encore une combinaison logique de ces opérations. En variante, la zone de surveillance peut être définie au moyen d’une opération d’exclusion « NOT(value1) », autrement dit la zone de surveillance correspond à toute zone pour laquelle la valeur du paramètre considéré est distincte de « value1 ». A titre illustratif dans l’exemple envisagé ici, on suppose qu’une zone Z2 de surveillance est définie pour l’équipement 2 de confiance pour l’utilisateur U : en d’autres termes, l’équipement 2 de confiance est configuré pour mettre en œuvre le service S lorsqu’il détecte qu’il se trouve dans cette zone Z2 de surveillance ; en dehors de cette zone Z2 de surveillance, il ne participe pas à la mise en œuvre du service S pour l’utilisateur U. Chaque équipement 2 de confiance est configuré ici avec une liste de serveurs MANTEC 3 auxquels il peut s’adresser si besoin pour déclencher des actions de brouillage ; chaque serveur MANTEC 3 est identifié dans la liste par au moins une information de joignabilité telle qu’une adresse IP, un nom de domaine, un numéro de port, etc. En variante, la liste de serveurs MANTEC peut être obtenue dynamiquement par l’équipement 2 de confiance, par exemple en interrogeant une autre entité telle qu’une base de données accessible par l’équipement 2 de confiance. Il convient de noter que cette liste peut évoluer dans le temps, dépendre de la position de l’équipement 2 de confiance ou d’autres paramètres. Dans l’exemple envisagé à la , par souci de simplification, on considère un seul équipement 2 de confiance associé à un unique utilisateur U et configuré avec un seul serveur MANTEC 3 susceptible d’apporter son assistance à l’équipement 2 de confiance. Ces hypothèses ne sont toutefois pas limitatives en soi et d’autres configurations du système 1 de brouillage peuvent être envisagées, telles que par exemple plusieurs équipements 2 de confiance associés à un même utilisateur en fonction de la zone géographique dans laquelle il se trouve ou de sa mobilité, ou plusieurs serveurs MANTEC 3 configurés auprès d’un équipement 2 de confiance situés dans des zones géographiques différentes (ceci permet avantageusement à l’équipement 2 de confiance de contacter concomitamment plusieurs serveurs MANTEC 3 sans requérir de coordination particulière des serveurs MANTEC 3 entre eux), ou un même équipement 2 de confiance associé à plusieurs utilisateurs, etc. On suppose qu’une relation de confiance existe entre l’équipement 2 de confiance et chaque serveur MANTEC 3 avec lequel il est configuré, via par exemple la mise en œuvre d’une procédure d’association entre ces équipements. Ainsi, des informations d’authentification peuvent être fournies à l’équipement 2 de confiance pour qu’il puisse s’authentifier lors de cette association auprès d’un serveur MANTEC 3, une telle procédure d’authentification étant déclenchée par l’établissement d’une connexion entre l’équipement 2 de confiance et le serveur MANTEC 3. On suppose qu’une seule connexion est établie entre l’équipement 2 de confiance et le serveur MANTEC 3 pour l’utilisateur U. Une telle association permet à l’équipement 2 de confiance et au serveur MANTEC 3 d’échanger divers types d’informations pour la mise en œuvre du service S, et notamment permet au serveur MANTEC 3 d’être en mesure d’identifier l’utilisateur U pour lequel il est sollicité. Le serveur MANTEC 3 peut dès lors accéder à un profil de cet utilisateur U (stocké localement ou accessible auprès d’une entité distante) et mettre en place des actions de brouillage en accord avec les politiques définies par ce profil. Un tel profil peut notamment définir tout ou partie des informations suivantes : une ou des zones Z3 d’intervention du serveur MANTEC 3, placée sous son contrôle dans le cadre du service S, et dans laquelle ou lesquelles des actions de brouillage peuvent être exécutées (c’est-à-dire à laquelle ou auxquelles est rattachée tout ou partie des objets O1, …, Om gérés par le serveur MANTEC 3). L’organisation des zones d’intervention et leur association avec des serveurs MANTEC reflète la mise en place d’une politique locale de l’opérateur qui fournit le service S. Une telle politique locale peut être instanciée à partir d’informations fournies par les utilisateurs du service S (par exemple par l’utilisateur U, en fonction de sa localisation à un instant donné ou de ses prévisions de déplacement). Une telle zone Z3 d’intervention peut être associée à une zone géographique (par exemple un quartier, une ville, un département, une région, un pays, etc.), ou en variante à un réseau particulier (ex. réseau local de l’utilisateur, réseau d’opérateur, etc.), ou à un service (ex. télémédecine, etc.). Elle peut être définie au moyen des opérations OR, AND et NOT évoquées précédemment. Si aucune zone d’intervention Z3 n’est définie dans le profil de l’utilisateur U, on peut envisager d’utiliser une zone d’intervention par défaut, correspondant par exemple à un réseau local domestique de l’utilisateur ; le niveau de brouillage souhaité (ex. niveau de duplication de l’utilisation des identifiants persistants) ; le ou les types d’identifiants persistants concernés ; le nombre d’identifiants maximum à brouiller associés à l’utilisateur ; l’identité des équipements 2 de confiance associés à cet utilisateur ; etc. Tout ou partie des informations contenues dans le profil de l’utilisateur U peuvent être fournies par l’utilisateur U lui-même lors de sa souscription au service S par exemple, ou à tout autre moment, et/ou être fournies par l’opérateur OP du service S en fonction du type de souscription de l’utilisateur U (qui peut être défini par exemple en fonction de la nature et du nombre maximum de zones d’intervention), du contexte, de la mobilité de l’utilisateur U, de la nature et des capacités des objets connectés gérés par les serveurs MANTEC 3, etc. L’association, et plus spécifiquement la connexion, entre l’équipement 2 de confiance et un serveur MANTEC 3 peut être permanente, c’est-à-dire pendant toute la durée de mise en œuvre du service S pour l’utilisateur U, ou ponctuelle, c’est-à-dire n’être établie que si l’équipement 2 de confiance a besoin de l’assistance du serveur MANTEC 3 pour la mise en œuvre du service S pour l’utilisateur U. On note que lorsque l’équipement 2 de confiance est associé à plusieurs utilisateurs, on peut envisager d’établir une ou plusieurs associations/connexions (par exemple une connexion par utilisateur) entre l’équipement 2 de confiance et le serveur MANTEC 3. Si une seule connexion est utilisée, l’identifiant d’un utilisateur doit alors être renseigné par l’équipement 2 de confiance lors de ses échanges avec le serveur MANTEC 3 pour que celui-ci puisse associer une demande de brouillage au profil de l’utilisateur concerné. Dans le mode de réalisation décrit ici, chaque équipement 2 de confiance, chaque serveur MANTEC 3 et chaque objet communicant du système 1 de brouillage (notamment les objets communicants O1, …, Om et les objets communicants parmi les objets O1’, …, Ok’ qui sont configurés pour mettre en œuvre un procédé d’exécution selon l’invention) a l’architecture matérielle d’un ordinateur 4 telle que représentée schématiquement sur la , ou est hébergé par un tel ordinateur. L’ordinateur 4 comprend notamment un processeur 5, une mémoire vive 6, une mémoire morte 7, une mémoire non volatile 8, et des moyens de communication 9 permettant notamment aux entités du système 1 de brouillage de communiquer entre elles. La mémoire morte 7 de l’ordinateur 4 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 5 et sur lequel est enregistré un programme d’ordinateur conforme à l’invention. Plus spécifiquement, la mémoire morte 7 de l’ordinateur 4 comprend, lorsque ce dernier est ou héberge un équipement 2 de confiance conforme à l’invention, un enregistrement d’un programme d’ordinateur PROG2, comportant des instructions définissant les principales étapes d’un procédé de surveillance selon l’invention. Ce programme PROG2 définit des modules fonctionnels de l’équipement 2 de confiance qui s’appuient sur ou commandent les éléments matériels 5 à 9 de l’ordinateur 4 cités précédemment. Ces modules comprennent notamment, dans le mode de réalisation décrit ici : un premier module 2A de détection, configuré pour détecter si l’équipement 2 de confiance se trouve dans sa zone Z2 de surveillance, et activer le cas échéant les autres modules de l’équipement 2 de confiance participant à la mise en œuvre du service S pour l’utilisateur U. A cet effet, le premier module 2A de détection utilise le ou les paramètres caractérisant la zone Z2 de surveillance (ex. identifiant de réseau, adresse ou préfixe IP, coordonnées GPS ou combinaison de ces paramètres) avec lequel ou lesquels l’équipement 2 de confiance a été préalablement configuré par l’utilisateur U. Dans le mode de réalisation décrit ici, le premier module 2A de détection est configuré pour surveiller de façon continue (c’est-à-dire sans interruption) si l’équipement 2 de confiance se trouve ou non dans sa zone Z2 de surveillance. En variante, il peut être configuré statiquement ou dynamiquement par l’utilisateur U pour opérer cette surveillance sur une plage de temps donnée, via une interface utilisateur prévue à cet effet ; un second module 2B de détection, configuré pour détecter une utilisation par au moins un objet communicant O1’,…,Ok’ surveillé par l’équipement 2 de confiance d’au moins un identifiant persistant. A cet effet, le second module 2B de détection est configuré ici pour balayer (i.e. scanner) en continu ou à fréquence déterminée (par exemple à fréquence régulière) les signaux et/ou les messages émis par les objets communicants O1’,…,Ok’ se trouvant dans son voisinage radio et/ou réseau, comme évoqué précédemment, et pour analyser ces signaux et/ou messages. Comme indiqué précédemment, dans une variante dans laquelle l’équipement 2 de confiance est configuré pour surveiller également des objets communicants situés dans son voisinage moins immédiat (typiquement, non directement visibles à l’équipement 2), il peut recevoir ces signaux et/ou messages de dispositifs intermédiaires (typiquement d’objets communicants parmi les objets communicants situés dans son voisinage immédiat) ; et un module 2C de déclenchement, configuré pour déclencher au moins une action de brouillage d’une telle utilisation détectée par le second module 2B de détection. Dans le mode de réalisation décrit ici, le module 2C de déclenchement comprend trois sous-modules : un premier sous-module 2C1, configuré pour déterminer quel(s) type(s) d’action(s) de brouillage déclencher suite à la détection du second module 2B de détection, et en particulier si une telle action de brouillage est déclenchée auprès de l’objet communicant à l’origine de l’utilisation détectée et/ou auprès d’un serveur MANTEC 3 distant. Le premier sous-module 2C1 peut à cet effet tenir compte des capacités de l’objet communicant à l’origine de l’utilisation détectée, de son appartenance ou non à l’utilisateur U, de l’identifiant persistant détecté, du niveau de brouillage souhaité, etc., comme décrit davantage ultérieurement ; un deuxième sous-module 2C2 et un troisième sous-module 2C3, activés sélectivement ou cumulativement par le premier sous-module 2C1. Le deuxième sous-module 2C2, respectivement le troisième sous-module 2C3, est configuré pour déclencher une action de brouillage de l’utilisation détectée auprès de l’objet communicant à l’origine de cette utilisation, respectivement auprès d’un serveur MANTEC 3 distant auquel l’équipement 2 de confiance requiert une assistance. Les fonctions des modules 2A à 2C de l’équipement 2 de confiance sont décrites plus en détail ultérieurement en référence aux étapes du procédé de surveillance selon l’invention illustrées sur la . Lorsque l’ordinateur 4 est ou héberge un serveur MANTEC 3 conforme à l’invention, la mémoire morte 7 de l’ordinateur 4 comprend un enregistrement d’un programme d’ordinateur PROG3, comportant des instructions définissant les principales étapes d’un procédé de gestion selon l’invention. Ce programme PROG3 définit des modules fonctionnels du serveur MANTEC 3 qui s’appuient sur ou commandent les éléments matériels 5 à 9 de l’ordinateur 4 cités précédemment. Ces modules comprennent notamment, dans le mode de réalisation décrit ici : un module 3A de réception, configuré pour recevoir en provenance d’au moins un équipement de confiance associé à un utilisateur (en l’occurrence dans l’exemple envisagé ici, de l’équipement 2 de confiance associé à l’utilisateur U), au moins une instruction pour déclencher une utilisation d’au moins un identifiant persistant donné par au moins un objet communicant géré par le serveur MANTEC 3 ; un module 3B de sélection, configuré pour sélectionner pour ledit au moins un identifiant persistant désigné dans ladite au moins une instruction et pour ledit utilisateur, d’au moins un objet communicant parmi une pluralité d’objets communicants O1, …., Om gérés par le serveur MANTEC 3 apte à utiliser ledit au moins un identifiant persistant. Comme évoqué précédemment, à cet effet le module 3B de sélection peut considérer les informations contenues dans le profil de l’utilisateur en question ; et un module 3C de contrôle, configuré pour envoyer une commande audit au moins un objet communicant sélectionné pour qu’il utilise ledit au moins un identifiant persistant. Cette commande peut comporter une indication d’un mode d’utilisation dudit au moins un identifiant persistant (par exemple indiquer si l’utilisation doit être réelle ou fictive (émulation) et/ou indiquer un comportement à adopter par l’objet communicant en cas de tentative et/ou de demande d’établissement d’une connexion par une entité tierce avec l’objet communicant sur la base dudit au moins un identifiant). Une tentative d’établissement d’une connexion (aussi connue sous le nom de « partial request » en anglais) consiste ici à initialiser une demande de connexion via l’envoi d’un message à l’objet communicant sans toutefois terminer cette demande de connexion. Les fonctions des modules 3A à 3C du serveur MANTEC 3 sont décrites plus en détail ultérieurement en référence aux étapes du procédé de gestion selon l’invention illustrées par la . Lorsque l’ordinateur 4 est ou héberge un objet communicant Oj, j=1, …, m conforme à l’invention, la mémoire morte 7 de l’ordinateur 4 comprend un enregistrement d’un programme d’ordinateur PROG, comportant des instructions définissant les principales étapes d’un procédé d’utilisation selon l’invention. Ce programme PROG définit des modules fonctionnels de l’objet communicant Oj qui s’appuient sur ou commandent les éléments matériels 5 à 9 de l’ordinateur 4 cités précédemment. Ces modules comprennent notamment, dans le mode de réalisation décrit ici : un module 10A de réception configuré pour recevoir, en provenance d’un serveur MANTEC 3, une commande pour utiliser un identifiant persistant déjà utilisé par un autre objet communicant, cette commande fournissant à l’objet communicant Oj une indication d’au moins un comportement à adopter par celui-ci en cas de tentative et/ou de demande d’établissement d’une connexion par un dispositif tiers au moyen dudit identifiant persistant. Comme mentionné précédemment, ce comportement définit plus particulièrement le mode d’utilisation de l’identifiant persistant (par exemple utilisation réelle ou utilisation fictive) préconisé par le serveur MANTEC 3 ; et un module 10B d’exécution configuré pour utiliser ledit identifiant persistant et mettre en œuvre ledit au moins un comportement. Enfin lorsque l’ordinateur 4 est ou héberge un objet communicant Oi’ nombre entier appartenant à {1, …,k} (par exemple i=1 sur la ), conforme à l’invention, la mémoire morte 7 de l’ordinateur 4 comprend un enregistrement d’un programme d’ordinateur PROG’, comportant des instructions définissant les principales étapes d’un procédé d’exécution selon l’invention. Ce programme PROG’ définit des modules fonctionnels de l’objet communicant Oi’ qui s’appuient sur ou commandent les éléments matériels 5 à 9 de l’ordinateur 4 cités précédemment. Ces modules comprennent notamment, dans le mode de réalisation décrit ici : un module 11A de communication, configuré pour utiliser un identifiant persistant ; un module 11B de réception, configuré pour recevoir en provenance de l’équipement 2 de confiance une commande pour que l’objet communicant Oi’ exécute une action de brouillage de l’utilisation de l’identifiant persistant par le module 11A de communication ; et un module 11C d’exécution configuré pour exécuter cette action de brouillage. Nous allons maintenant décrire en référence aux figures 3 à 7 les principales étapes des procédés de surveillance ( ), de gestion ( ) et d’utilisation ( ) mis en œuvre respectivement par l’équipement 2 de confiance associé à l’utilisateur U, par le serveur MANTEC 3, et par les objets communicants O1, …, Om dans un mode particulier de réalisation. La illustre les principales étapes d’un procédé d’exécution mis en œuvre le cas échéant par un objet communicant parmi les objets communicants O1’,…,Ok’ surveillés par l’équipement 2 de confiance. En référence à la , comme évoqué précédemment, dans le mode de réalisation décrit ici, le premier module 2A de détection de l’équipement 2 de confiance associé à l’utilisateur U surveille si l’équipement 2 de confiance se trouve dans sa zone Z2 de surveillance (étape test E10). A cet effet par exemple, il utilise le ou les paramètres caractérisant la zone Z2 de surveillance et le ou les compare au(x) paramètre(s) correspondant(s) de la zone dans laquelle il se trouve. Ainsi, à titre illustratif, si le paramètre utilisé pour caractériser la zone Z2 de surveillance est un identifiant de réseau dont la valeur est NwID, le premier module 2A de détection compare l’identifiant du (ou des) réseau(x) au(x)quel(s) est connecté l’équipement 2 de confiance avec la valeur NwID ; s’il détecte une coïncidence, cela signifie que l’équipement 2 de confiance se trouve dans sa zone Z2 de surveillance, et sinon qu’il est en dehors de cette zone. Comme évoqué précédemment, la zone Z2 de surveillance peut être en variante définie par une opération d’exclusion d’une valeur spécifique du paramètre en question, par exemple « NOT(NwID) ». Dans ce cas, le premier module 2A de détection détecte que l’équipement 2 de confiance se trouve dans sa zone Z2 de surveillance si l’équipement 2 de confiance n’est connecté à aucun réseau ayant pour identifiant NwID. Tant que l’équipement 2 de confiance ne se trouve pas dans sa zone Z2 de surveillance (réponse « non » à l’étape test E10), les modules 2B à 2C de l’équipement 2 de confiance reste inactifs. Lorsque le premier module 2A de détection détecte que l’équipement 2 de confiance se trouve dans sa zone Z2 de surveillance (réponse « oui » à l’étape E10), il active les autres modules de l’équipement 2 de confiance, et plus particulièrement le second module 2B de détection. Suite à cette activation, le second module 2B de détection procède au balayage des signaux radio (p. ex. signaux Bluetooth, Wi-Fi) et/ou des messages (ex. messages broadcast ARP) émis par les objets communicants O1’, …, Ok’ se trouvant dans son voisinage radio et/ou réseau immédiat (étape E20), en vue de détecter si l’un au moins d’entre eux utilise un identifiant persistant. Par souci de simplification ici, on suppose que l’équipement 2 de confiance ne surveille que les objets communicants situés dans son voisinage immédiat. Toutefois, comme détaillé précédemment, en variante, on peut également envisager que l’équipement 2 de confiance surveille également des objets communicants situés dans un voisinage moins immédiat, par exemple situés à une plus grande distance de l’équipement 2 de confiance et qui sont connectés via une interface réseau ou radio aux objets communicants situés dans le voisinage immédiat de l’équipement 2 de confiance. Pour détecter l’utilisation d’identifiant(s) persistant(s), le second module 2B de détection peut être configuré pour reconnaître parmi les données véhiculées par les signaux/messages détectés dans son voisinage des identifiants particuliers (ex. adresse MAC, adresse IP, etc.) ou des séquences de données utilisées de façon récurrente. Cette configuration peut consister par exemple en la spécification d’entêtes de messages et/ou de types d’identifiants à rechercher parmi ces données. Pour chaque objet communicant détecté et surveillé dans son voisinage, le second module 2B de détection met à jour, dans le mode de réalisation décrit ici, une liste LIST comprenant les identifiants véhiculés par ces objets communicants (étape E30) et analyse la durée d’utilisation de ces identifiants par lesdits objets communicants pour déterminer s’il s’agit d’identifiants persistants susceptibles de révéler des informations d’identifiant sur l’utilisateur U. A cet effet, une durée Dmax de persistance maximale tolérée est configurée au niveau du second module 2B de détection. Il convient de noter que cette durée de persistance maximale peut dépendre de l’utilisateur U, des identifiants détectés, du contexte dans lequel se trouvent les objets communicants O1’, …, Ok’ surveillés par l’équipement 2 de confiance (ex. environnement sécurisé ou non), etc. Une telle durée est par exemple 2h, 24h, 1 semaine, etc. En variante, le second module 2B de détection peut être configuré avec des paramètres acquis via l’exécution d’un algorithme d’apprentissage machine ou « Machine Learning » en anglais, dont l’exécution peut reposer par exemple sur la production et l’exploitation d’un réseau de neurones, permettant de détecter l’existence d’identifiants persistants dans des données, et fournissant la durée de persistance et le type de chaque identifiant persistant ainsi détecté. Les types d’identifiants persistants peuvent être explicitement indiqués dans les messages présentant ces identifiants persistants ou déduits par comparaison avec d’autres types connus d’identifiants (ex. adresse MAC), ou encore résulter d’une configuration par l’opérateur OP ou par l’utilisateur U, etc. A partir de la liste LIST et de la ou des durées Dmax de persistance maximales tolérées, le second module 2B de détection est donc en mesure d’identifier les objets communicants utilisant des identifiants persistants (étape test E40). Dans la suite de la description, on désigne par OBJ1, …, OBJn, n désignant un entier supérieur ou égal à 1 et inférieur ou égal à k, les objets communicants parmi les objets communicants O1’, …, Ok’ utilisant des identifiants persistants détectés le cas échéant par le second module 2B de détection. On note que les objets communicants OBJ1, …, OBJn peuvent utiliser un ou plusieurs identifiants persistants. Dans un souci de simplification, on considère que chaque objet communicant OBJ1, …, OBJn utilise un unique identifiant persistant, noté respectivement P-ID1, …, P-IDn ; toutefois dans l’hypothèse où plusieurs identifiants persistants sont utilisés par un même objet communicant, ce qui est décrit pour un identifiant persistant dans la suite est reproduit pour tous les identifiants persistants utilisés. Pour chaque objet communicant OBJj, j=1, …, n (étapes E50 et E110), l’équipement 2 de confiance détermine alors via son premier sous-module 2C1 quel(s) type(s) d’action(s) de brouillage déclencher pour brouiller l’utilisation par cet objet communicant OBJj de l’identifiant persistant P-IDj. Pour cela, dans le mode de réalisation décrit ici, l’équipement 2 de confiance tient compte des deux facteurs suivants : la possibilité de contrôler l’objet communicant OBJj (afin que l’équipement 2 de confiance puisse lui envoyer des commandes et que celles-ci soient acceptées par l’objet communicant OBJj), et la capacité de l’objet OBJj, le cas échéant, à exécuter lui-même une action de brouillage (commandée par l’équipement 2 de confiance) comme par exemple le remplacement de l’identifiant persistant qu’il utilise par un autre identifiant. Le premier sous-module 2C1 détermine donc, dans un premier temps, s’il est en mesure, ou plus spécifiquement l’utilisateur U, de contrôler l’objet communicant OBJj utilisant l’identifiant persistant P-IDj (étape test E60). A cet effet, dans le mode de réalisation décrit ici, le premier sous-module 2C1 détermine si l’objet communicant OBJj appartient à l’utilisateur U ou s’il le gère. Plusieurs techniques peuvent être utilisées à cette fin par le premier sous-module 2C1. Par exemple, si l’équipement 2 de confiance est un CPE de l’utilisateur U connecté à un réseau local de l’utilisateur U et l’identifiant persistant P-IDj est une adresse MAC, le premier sous-module 2C1 peut consulter la table des connexions actives dans le réseau local maintenue par l’équipement 2 de confiance (par exemple table ARP (pour « Address Resolution Protocol » en anglais) ou base de données DHCP pour « Dynamic Host Configuration Protocol » en anglais) et vérifier si l’objet OBJj est connecté au réseau local avec son adresse MAC P-IDj. Selon une autre technique, pour déterminer si l’objet communicant OBJj peut être contrôlé par l’utilisateur U, le premier sous-module 2C1 peut échanger des messages avec l’objet communicant OBJj, par exemple des messages ICMP (pour « Internet Control Message Protocol » en anglais) ou en établissant une association avec l’objet communicant OBJj selon une interface de radio utilisée par celui-ci (ex. Bluetooth). Selon une autre technique encore, le premier sous-module 2C1 peut solliciter l’utilisateur U pour qu’il indique s’il est en mesure de contrôler cet objet OBJj (par exemple pour qu’il indique si l’objet OBJj lui appartient ou s’il le gère), par exemple en affichant un message sur un terminal (ex. smartphone, écran d’affichage d’un CPE, télévision connectée) de l’utilisateur U. Selon une autre technique encore, le premier sous-module 2C1 peut appuyer sur des déclarations faites par l’utilisateur U lors de la souscription au service S. Bien entendu, d’autres techniques peuvent être envisagées en complément ou en remplacement des techniques précédentes. Comme mentionné précédemment, le fait que l’objet communicant OBJj soit sous le contrôle de l’utilisateur U le rend ici contrôlable par l’équipement 2 de confiance (désigné en tant que tel par l’utilisateur U) et permet ainsi à l’équipement 2 de confiance d’adresser des commandes d’exécution d’actions de brouillage à l’objet communicant OBJj, celui-ci étant configuré pour accepter ces commandes et les exécuter s’il est en mesure de le faire. Dans le mode de réalisation décrit ici, si l’objet communicant OBJj n’est pas sous le contrôle de l’utilisateur U (réponse « non » à l’étape test E60), alors le premier sous-module 2C1 déclenche par l’intermédiaire du troisième sous-module 2C3 une action de brouillage de l’utilisation de l’identifiant persistant P-IDj par l’objet communicant OBJj auprès d’un serveur MANTEC 3 (étape E70), comme décrit plus en détail ultérieurement. Si l’objet communicant OBJj est sous le contrôle de l’utilisateur U (réponse « oui » à l’étape test E60), par exemple parce qu’il appartient à l’utilisateur U, le premier sous-module 2C1 vérifie dans un deuxième temps si l’objet communicant OBJj est capable d’exécuter une action de brouillage de son utilisation de l’identifiant persistant P-IDj (étape test E80). Plus particulièrement, dans le mode de réalisation décrit ici, le premier sous-module 2C1 détermine si l’objet communicant OBJj est en mesure d’exécuter une action de randomisation de l’identifiant persistant P-IDj qu’il utilise. Une telle technique comprend par exemple le choix ou la génération à la demande par l’objet communicant OBJj d’un nouvel identifiant de même nature que l’identifiant P-IDj (dans l’exemple : d’une adresse MAC ou d’une adresse IP, la génération d’une nouvelle adresse MAC ou d’une nouvelle adresse IP respectivement), par exemple de façon aléatoire, et l’utilisation par l’objet communicant OBJj du nouvel identifiant ainsi généré à la place de l’identifiant P-IDj. En variante, le nouvel identifiant de même nature que l’identifiant persistant P-IDj peut être choisi ou généré par une autre entité telle que l’équipement 2 de confiance ou une entité tierce, et être fourni à l’objet communicant OBJj par l’équipement 2 de confiance ou directement par cette autre entité. Le premier sous-module 2C1 peut déterminer l’aptitude de l’objet communicant OBJj à exécuter une telle action de brouillage de différentes façons. Par exemple, il peut interroger l’objet communicant OBJj ou consulter une base de données dans laquelle une telle capacité est reportée. En variante, on peut envisager la définition d’une option DHCP ou DHCPv6 ou ICMPv6 spécifique, envoyée par l’objet communicant OBJj (par ex. lors de sa connexion au réseau local de l’équipement 2 de confiance lorsque celui-ci est un CPE ou en réponse à un message ICMP envoyé par l’équipement 2 de confiance à l’objet communicant OBJj). A titre illustratif et nullement limitatif, nommons cette option spécifique « MAC_UPDATE » lorsque l’identifiant en question est une adresse MAC. Cette option peut contenir un identifiant d’API (pour « Application Programming Interface » en anglais) supportée par l’objet communicant OBJj pour demander le renouvellement d’une adresse MAC ; une telle API est par exemple la procédure RECONFIGURE de reconfiguration DHCP décrite dans le document RFC 8415 édité par l’IETF intitulé « Dynamic Host Configuration Protocol for IPv6 (DHCPv6) », novembre 2018 (paragraphe 16.11). En variante, d’autres procédures peuvent être utilisées. Si l’objet communicant OBJj n’est pas en mesure d’exécuter une action de brouillage (réponse « non » à l’étape test E80) et plus particulièrement ici, une action de randomisation de l’identifiant persistant P-IDj qu’il utilise, le premier sous-module 2C1 déclenche alors, par l’intermédiaire du troisième sous-module 2C3, une action de brouillage de l’utilisation de l’identifiant persistant P-IDj par l’objet communicant OBJj auprès d’un serveur MANTEC 3 (étape E70), comme décrit plus en détail ultérieurement en référence à la . Si au contraire, l’objet communicant OBJj est en mesure d’exécuter une action de brouillage (réponse « oui » à l’étape test E80), et plus particulièrement ici, une action de randomisation de l’identifiant persistant P-IDj qu’il utilise, il s’agit d’un objet communicant conforme à l’invention, utilisant un identifiant persistant P-IDj (cf. étape H10 sur la ), et disposant de modules configurés pour la mise en œuvre d’un procédé d’exécution selon l’invention (cf. modules 11A-11C représentés en traits discontinus sur la pour l’objet O1’). Le premier sous-module 2C1 déclenche alors l’exécution d’une telle action de brouillage au niveau de l’objet communicant OBJj via le deuxième sous-module 2C2 de l’équipement 2 de confiance, pour forcer l’utilisation par l’objet communicant OBJj d’un autre identifiant de même nature que l’identifiant P-IDj (étape E90). Le deuxième sous-module 2C2 de l’équipement 2 de confiance envoie une commande CMD à l’objet communicant OBJj en ce sens. A titre illustratif, une telle commande CMD comporte l’instruction de déclenchement d’une procédure RECONFIGURE de reconfiguration DHCP et comprend l’option spécifique évoquée précédemment (option MAC_UPDATE pour un identifiant de type adresse MAC) incluant une indication d’un intervalle de renouvellement de l’identifiant persistant, préférentiellement inférieur ou égal à la durée de persistance maximale tolérée pour l’identifiant en question. Selon un autre exemple, aucune indication d’intervalle de renouvellement n’est fournie, mais le deuxième sous-module 2C2 de l’équipement 2 de confiance est configuré pour déclencher le renouvellement de l’identifiant persistant régulièrement (avec une période préférentiellement inférieure ou égale à la durée de persistance maximale tolérée pour l’identifiant en question) ou à des instants donnés (ex. lorsque l’objet communicant OBJj est sollicité pour répondre à une commande générée par un contrôleur). En référence à la , suite à la réception de la commande CMD de l’équipement 2 de confiance (étape H20), l’objet communicant OBJj exécute l’action de brouillage qui lui est demandée, à savoir ici, une action de randomisation de l’identifiant persistant P-IDj (étape H30). Plus spécifiquement, il obtient un nouvel identifiant IDj’ de même nature que l’identifiant P-IDj (il peut par exemple le générer ou utiliser un nouvel identifiant IDj’ fourni par l’équipement 2 de confiance ou par une entité tierce comme évoqué précédemment) et l’utilise en remplacement de l’identifiant P-IDj conformément aux instructions indiquées par la commande CMD. Par exemple, il utilise cet identifiant IDj’ pour toutes ses connexions en cours qui utilisaient l’identifiant persistant P-IDj. Suite au renouvellement de l’identifiant persistant P-IDj par l’objet communicant OBJj par le nouvel identifiant IDj’ de même nature, l’équipement 2 de confiance peut, si cela s’avère nécessaire, procéder à une mise à jour des règles d’acheminement et/ou de filtrage de trafic relatives à l’objet communicant OBJj pour tenir compte du nouvel identifiant IDj’ utilisé par celui-ci (étape E100). Lorsque l’équipement 2 de confiance est un CPE, cette mise à jour peut être réalisée directement par l’équipement 2 de confiance. En variante, elle peut être déclenchée par l’équipement 2 de confiance auprès d’une autre entité appropriée. Cette mise à jour a pour objectif d’éviter que le service fourni par l’objet communicant OBJj ne soit impacté par la modification de l’identifiant (en particulier du point de vue de l’accès au service), et notamment d’éviter une dégradation de ce service. Nous allons maintenant décrire plus en détail le déclenchement par l’équipement 2 de confiance d’une action de brouillage auprès d’un serveur MANTEC 3 de l’utilisation par l’objet communicant OBJj de l’identifiant persistant P-IDj, telle qu’envisagée notamment à l’étape E70. Il convient de noter que dans le mode de réalisation décrit ici, l’assistance d’un serveur MANTEC 3 est sollicitée par l’équipement 2 de confiance lorsque l’objet communicant OBJj n’est pas sous le contrôle de l’utilisateur U ou lorsque l’objet communicant OBJj n’est pas en mesure d’exécuter lui-même une action de brouillage donnée, comme par exemple ici une technique de génération d’identifiants aléatoires. Ces hypothèses ne sont toutefois pas limitatives, et on peut envisager de solliciter un serveur MANTEC 3 dans d’autres cas. Notamment, le serveur MANTEC 3 peut être sollicité y compris lorsque l’objet communicant OBJj est sous le contrôle de l’utilisateur et lorsqu’il est en mesure d’exécuter lui-même une action de brouillage donnée pour renforcer le brouillage de l’utilisation de l’identifiant persistant P-IDj par l’objet communicant OBJj (et augmenter le niveau de bruit associé à ce brouillage). L’intervention d’un serveur MANTEC 3 est décrite en référence à la et aux principales étapes d’un procédé de gestion selon l’invention alors mis en œuvre par ledit serveur MANTEC 3. Il s’agit d’un déclenchement d’une action de brouillage de l’utilisation de l’identifiant persistant P-IDj par l’objet communicant OBJj au sens de l’invention. Plus particulièrement, l’intervention d’un serveur MANTEC 3 est déclenchée lors de l’étape E70 par le troisième sous-module 2C3 de l’équipement 2 de confiance qui, après avoir établi une association/connexion avec le ou les serveur(s) MANTEC 3 avec le(s)quel(s) il a été configuré pour l’utilisateur U, envoie au(x) serveur(s) MANTEC 3 un message de commande comprenant une instruction pour déclencher une utilisation de l’identifiant persistant P-IDj utilisé par l’objet communicant OBJj par au moins un autre objet communicant sélectionné par le(s) serveur(s) MANTEC 3. Comme indiqué précédemment, dans l’exemple envisagé ici par souci de simplification, le troisième sous-module 2C3 de l’équipement 2 de confiance envoie le message de commande à un unique serveur MANTEC 3. Dans le mode de réalisation décrit ici, le message de commande adressé au serveur MANTEC 3 s’appuie sur une méthode spécifique, dédiée à l’invention, c’est-à-dire définie à cet effet, nommée par exemple MIRROR. Le message de commande MIRROR comprend une liste d’identifiants persistants à utiliser (par exemple une liste des identifiants à émuler, c’est-à-dire à utiliser « artificiellement » dans le but de bruiter leur utilisation originelle, par les objets communicants sélectionnés par le serveur MANTEC 3. Il convient de noter que la liste d’identifiants persistants contenue dans le message de commande MIRROR peut regrouper les identifiants persistants utilisés par plusieurs objets communicants OBJ1, …, OBJn, ou le ou les identifiants persistants utilisés par un seul objet communicant OBJj. Autrement dit, le message de commande MIRROR peut regrouper des instructions relatives à plusieurs objets communicants OBJj, j=1, …, n et donc plusieurs identifiants persistants P-IDj utilisés respectivement par ces objets communicants, ou des instructions relatives à un seul d’entre eux. Dans ce dernier cas de figure, un message de commande MIRROR est envoyé pour chaque objet OBJj éligible (c’est-à-dire pour lequel il a été décidé de déclencher l’assistance du serveur MANTEC 3). Le message de commande MIRROR peut en outre comprendre d’autres informations optionnelles, comme par exemple une indication de l’utilisateur U concerné par le message, une indication d’une durée d’utilisation des identifiants persistants désignés par le message de commande et/ou une zone à laquelle doi(ven)t être rattaché(s) le ou les objets communicants sélectionnés par le serveur MANTEC 3 qui vont utiliser ce ou ces identifiants persistants, un mode d’utilisation des identifiants persistants par les objets communicants sélectionnés par le serveur MANTEC 3 (par exemple utilisation réelle ou fictive ou un mix des deux). En variante, ces informations peuvent être obtenues autrement par le serveur MANTEC 3, par exemple en consultant le profil de l’utilisateur U. Selon une autre variante, le serveur MANTEC 3 peut utiliser des valeurs définies par défaut (par ex. 24h pour la durée d’utilisation) en l’absence de mention de ces informations dans le message de commande MIRROR ou dans le profil de l’utilisateur U. Si l’équipement 2 de confiance souhaite renouveler l’intervention du serveur MANTEC 3 au-delà des indications fournies dans le message de commande MIRROR, dans ce cas, il peut envoyer un nouveau message de commande MIRROR au serveur MANTEC 3. A l’inverse, si l’équipement 2 de confiance souhaite interrompre l’intervention du serveur MANTEC 3, il peut lui envoyer un message à cet effet, par exemple en s’appuyant sur une méthode DELETE telle que définie par le protocole RESTCONF, adaptée de sorte à ce qu’elle indique la liste des identifiants persistants concernés par l’interruption. Aucune limitation n’est attachée au protocole utilisé pour supporter les communications entre l’équipement 2 de confiance et le serveur MANTEC 3. Il peut s’agir par exemple du protocole TCP (« Transmission Control Protocol » en anglais), QUIC, RESTCONF, HTTP (pour « HyperText Transfer Protocol » en anglais), CoAP (pour « Constrained Application Protocol » en anglais), etc. Pour les protocoles HTTP, RESTCONF ou CoAP, la méthode MIRROR peut être indifféremment implémentée à l’aide des mécanismes PUT ou POST supportés par ces protocoles. En référence à la , le message de commande MIRROR est reçu par le serveur MANTEC 3 (étape F10). Dans la suite de la description, par souci de simplification, on suppose que le message de commande MIRROR reçu par le serveur MANTEC 3 comprend un seul identifiant persistant P-IDj utilisé par l’objet communicant OBJj. L’homme du métier n’aurait aucune difficulté à adapter les étapes qui suivent lorsque le message de commande comprend plusieurs identifiants persistants utilisés par un même objet communicant ou par plusieurs objets communicants distincts. Dans le mode de réalisation décrit ici, sur réception du message de commande MIRROR par son module 3A de réception en provenance de l’équipement 2 de confiance, le serveur MANTEC 3, via son module 3A de réception, détermine l’utilisateur U concerné par le message de commande MIRROR et auquel l’équipement 2 de confiance est associé. Cette information peut être obtenue par le module 3A de réception grâce à l’association préalable de l’équipement 2 de confiance avec le serveur MANTEC 3 réalisée lors de l’établissement de leur connexion et sur la base de laquelle l’équipement 2 de confiance a envoyé son message de commande. Le module 3A de réception vérifie alors que l’équipement 2 de confiance est habilité (c’est-à-dire autorisé) à lui adresser un tel message pour l’utilisateur U (étape test F20). Une telle vérification peut consister par exemple à authentifier la demande d’établissement de connexion de l’équipement 2 de confiance. D’autres contrôles peuvent être réalisés lors de cette vérification, comme par exemple s’assurer que l’équipement 2 de confiance est bien autorisé à adresser des messages de commande relatifs à l’utilisateur U, ou que l’équipement 2 de confiance peut encore adresser des demandes de brouillage pour l’utilisateur U au regard du nombre d’identifiants maximum à brouiller associés à l’utilisateur U, etc., les informations permettant d’effectuer ces vérifications pouvant être obtenues par le serveur MANTEC 3 à partir du profil de l’utilisateur U ou à partir d’informations déclarées par l’utilisateur U lors de sa souscription au service S. Si l’équipement 2 de confiance est utilisé par plusieurs utilisateurs et qu’une seule connexion est utilisée avec le serveur MANTEC 3 pour les besoins du service S, on peut envisager que le message de commande MIRROR identifie l’utilisateur U et que le serveur MANTEC 3 consulte le profil de l’utilisateur U indiqué par l’équipement 2 de confiance dans le message MIRROR pour déterminer si celui-ci est explicitement associé audit utilisateur. Si l’équipement 2 de confiance n’est pas habilité (réponse « non » à l’étape test F20), le message de commande MIRROR est rejeté par le serveur MANTEC 3 via son module 3A de réception (étape F30). Autrement dit, aucune action de brouillage n’est mise en œuvre par le serveur MANTEC 3. Sinon (réponse « oui » à l’étape test F20), le module 3A de réception du serveur MANTEC 3 valide le message de commande MIRROR et extrait les diverses informations contenues dans le message (liste des identifiants persistants à utiliser, et éventuellement durée de l’utilisation, zone dans laquelle déclencher l’utilisation, etc.) (étape F40). Ainsi, à titre illustratif, dans l’exemple envisagé ici, le module 3A de réception extrait l’identifiant persistant P-IDj du message MIRROR et détermine que l’utilisateur U est concerné par ce message (directement à partir du message MIRROR ou de l’association avec l’équipement 2 de confiance comme évoqué précédemment), ce qui lui permet d’accéder aux éléments contenus dans le profil de l’utilisateur U concernant le brouillage à adopter mentionnés précédemment (ex. zone d’intervention Z3 du serveur MANTEC 3, niveau de brouillage souhaité, types d’identifiants persistants, etc.). A partir de ces éléments, le module 3B de sélection du serveur MANTEC 3 sélectionne un ou plusieurs objets communicants parmi les objets communicants O1, …, Om qu’il gère pour utiliser (en plus de l’objet communicant OBJj) l’identifiant persistant P-IDj extrait du message MIRROR (étape F50). On désigne par S-OBJ1, …, S-OBJi(j), i(j) désignant un entier supérieur ou égal à 1 et inférieur ou égal à m, le ou les objets communicants ainsi sélectionnés par le module 3B de sélection pour utiliser l’identifiant P-IDj. Le nombre i(j) dépend du niveau de brouillage souhaité c’est-à-dire du niveau de bruit que l’on souhaite introduire lors du brouillage de l’utilisation de l’identifiant P-IDj pour annuler l’effet de l’utilisation de cet identifiant P-IDj de manière persistante par l’objet communicant OBJj. Ce niveau de bruit peut refléter une préférence exprimée par l’utilisateur, ou être imposé par l’opérateur OP du service S, par exemple en fonction des conditions de souscription de l’utilisateur U au service S, ou déterminé en fonction du contexte, etc. Il est défini ici dans le profil de l’utilisateur U. Le module 3B de sélection détermine également, dans le mode de réalisation décrit ici, pour chacun des objets S-OBJ1, …, S-OBJi(j) sélectionnés, le mode d’utilisation de l’identifiant persistant P-IDj par ces objets. Ce mode d’utilisation peut différer d’un objet à l’autre (et d’un identifiant à l’autre en cas d’utilisation de plusieurs identifiants persistants par un même objet), par exemple, certains objets peuvent être sélectionnés pour émuler l’identifiant persistant P-IDj, et d’autres pour l’utiliser de façon réelle. Ce mode d’utilisation est, dans l’exemple envisagé ici, caractérisé par le(s) comportement(s) à adopter par l’objet en question en cas de tentative et/ou de demande d’établissement d’une connexion par une autre entité avec l’objet sur la base de l’identifiant persistant P-IDj, par exemple, rejeter la tentative et/ou la demande d’établissement, mémoriser la tentative et/ou la demande d’établissement (i.e. pour les tracer), accepter la tentative et/ou la demande d’établissement, etc. Cette hypothèse n’est toutefois pas limitative en soi et on peut envisager de caractériser le mode d’utilisation retenu pour un objet communicant S-OBJ1, …, S-OBJi(j) différemment (par exemple en associant au mode d’utilisation une désignation particulière (par exemple « EMUL ») qui fait écho au(x) comportement(s) à adopter chez l’objet communicant (par exemple « rejeter toute tentative et/ou demande de connexion »). On note que le mode d’utilisation de l’identifiant persistant P-IDj peut être choisi par le serveur MANTEC 3 seul et/ou en tenant compte d’une consigne fournie par l’équipement 2 de confiance (par exemple dans le message MIRROR comme évoqué précédemment), ou encore être défini par défaut. Dans l’exemple illustratif envisagé ici, on suppose par souci de simplification que le module 3B de sélection requiert une émulation de l’identifiant persistant P-IDj par chacun des objets S-OBJp, p=1, …,i(j). Comme évoqué précédemment, une telle émulation de l’identifiant persistant P-IDj consiste pour un objet S-OBJp, p=1, …,i(j) à utiliser artificiellement l’identifiant P-IDj pour que son utilisation par l’objet communicant OBJj ne soit plus en mesure de révéler des informations caractéristiques de l’utilisateur U, c’est-à-dire susceptibles de l’identifier ou de révéler des éléments sur son comportement ou encore ses habitudes. Autrement dit, grâce à cette émulation, d’autres objets communicants que l’objet communicant OBJj qui peut être « rattaché » à l’utilisateur U (bien que ne lui appartenant pas nécessairement comme évoqué précédemment) vont être associés à l’utilisation de l’identifiant P-IDj. Ces objets communicants se trouvant dans un contexte dûment choisi (par exemple dans une zone géographique « insignifiante » pour l’utilisateur U, typiquement une zone dans laquelle il a peu de chances de se trouver), l’utilisation simultanée de l’identifiant P-IDj par les objets S-OBJ1, …, S-OBJi(j), et par l’objet communicant OBJj vont annihiler toute possibilité de déduire de cette utilisation des informations critiques pour l’utilisateur U. Plus particulièrement, l’émulation de l’identifiant persistant P-IDj par un objet communicant S-OBJp consiste ici à affecter l’identifiant P-IDj à l’une des interfaces de l’objet communicant S-OBJp de telle sorte qu’il soit visible des équipements qui scannent la zone à laquelle il est rattaché ou qui procèdent à ladite association. L’objet communicant S-OBJp est par ailleurs configuré pour ne pas utiliser cet identifiant P-IDj pour ses besoins propres (par exemple, lorsqu’il envoie un rapport d’activité à la demande d’un contrôleur externe), et pour rejeter toute tentative et/ou demande d’établissement de connexion qu’il reçoit de tiers sur la base de cet identifiant. Les objets communicants S-OBJ1, …, S-OBJi(j) peuvent être sélectionnés parmi les objets communicants O1, …, Om gérés par le serveur MANTEC 3 selon différents critères : de façon aléatoire, en fonction d’au moins une contrainte définie pour ou par l’utilisateur U (ex. zone Z3 d’intervention, situation de mobilité, etc.), etc. Dans l’exemple envisagé ici, les objets communicants S-OBJ1, …, S-OBJi(j) sont sélectionnés dans la zone Z3 d’intervention définie le cas échéant dans le profil de l’utilisateur U. Par exemple, l’utilisateur U est une personne exerçant une mission commerciale dans une entreprise ; la zone Z2 surveillée par l’équipement 2 de confiance correspond au réseau local de l’entreprise, tandis que la zone Z3 est définie pour cet utilisateur U en fonction du planning de déplacement de l’utilisateur U en lien avec sa mission commerciale (il s’agit par exemple d’une zone dans laquelle l’utilisateur U doit se rendre dans le cadre de cette mission). Les objets communicants S-OBJ1, …, S-OBJi(j) sont choisis uniformément répartis dans la zone Z3. En variante, on peut envisager une zone Z3 éloignée des lieux concernés par le planning de déplacement de l’utilisateur U. En variante, l’identification de cette zone Z3 d’intervention peut être véhiculée dans le message MIRROR reçu de l’équipement 2 de confiance, ou être définie par défaut. Les objets communicants S-OBJ1, …, S-OBJi(j) sélectionnés peuvent être connectés au même réseau que le serveur MANTEC 3 ou appartenir à un réseau dédié, et sont rattachés à la zone Z3 d’intervention. La zone d’intervention Z3 peut être un quartier, une ville, un réseau de CPE, un réseau de hotspot, etc. Comme pour la zone Z2, le rattachement à la zone Z3 d’intervention n’est donc pas nécessairement lié à une localisation géographique ; une zone d’intervention Z3 peut être par exemple caractérisée par un identifiant de réseau, un préfixe ou une adresse IP, des coordonnées GPS délimitant une zone géographique ou une combinaison de tels paramètres. Les objets communicants rattachés à cette zone Z3 d’intervention sont gérés par le serveur MANTEC 3 et sous son contrôle. Ainsi, à l’issue de l’étape F50 de sélection, le serveur MANTEC 3 dispose d’une « carte » d’objets communicants à contacter pour exécuter des actions de brouillage de l’utilisation de l’identifiant persistant P-IDj par l’objet communicant OBJj, et plus particulièrement ici pour émuler l’identifiant P-IDj. On note que la carte en question peut évoluer dans le temps (régulièrement ou à des instants déterminés) comme illustré par les figures 6A et 6B, par exemple pour émuler une situation de mobilité (autrement dit, les objets communicants sélectionnés par le module 3B de sélection, et éventuellement leur nombre, peuvent être différents dans le temps). Les figures 5A et 5B illustrent un exemple d’évolution d’une carte d’objets communicants entre deux instants t=t0 et t=t1, les ronds blancs représentant les objets communicants O1, …, Om gérés par un serveur MANTEC 3 et les ronds gris les objets communicants S-OBJ1, …, S-OBJi(j) sélectionnés par le serveur MANTEC 3 pour émuler l’identifiant persistant P-IDj. Le serveur MANTEC 3 envoie alors, via son module 3C de contrôle, aux objets communicants S-OBJ1, …, S-OBJi(j) ainsi sélectionnés une commande pour utiliser l’identifiant persistant P-IDj (étape F60). Cette commande peut être exécutée par l’objet communicant concerné dès sa réception ou à compter d’un instant indiqué dans la commande (notamment en cas d’évolution des objets communicants sélectionnés pour émuler l’identifiant P-IDj dans le temps). Une telle commande peut être par exemple un message conforme aux protocoles NETCONF ou RESTCONF, par exemple nommé SET dans l’exemple envisagé ici, comprenant l’identifiant P-IDj à utiliser ainsi qu’éventuellement d’autres informations comme par exemple la durée d’utilisation de cet identifiant P-IDj par l’objet communicant auquel s’adresse la commande, ou le(s) comportement(s) à adopter en cas de demandes de connexion associées à cet identifiant (par exemple accepter la demande d’association, procéder seulement à la diffusion de l’identifiant mais sans accepter de demande d’association, ou garder une trace des demandes d’établissement de connexions), ou plus généralement le mode d’utilisation de l’identifiant P-IDJj par l’objet communicant, etc. Il convient de noter que selon les détails d’implémentation choisis pour mettre en œuvre l’invention, le message SET peut comporter implicitement le mode d’utilisation de l’identifiant persistant P-IDJj choisi par le module 3B de sélection (par exemple, émulation de l’identifiant persistant P-IDJj) ou comprendre un paramètre indiquant explicitement ce mode d’utilisation (par exemple une certaine valeur du paramètre indiquant un comportement à adopter en cas de tentative et/ou de demande d’établissement d’une connexion basée sur l’identifiant persistant ou indiquant plus généralement un mode d’utilisation de l’identifiant persistant avec le ou les comportements associés, par exemple « EMUL », ce mode d’utilisation étant associé au comportement « rejeter toute tentative et/ou demande d’établissement d’une connexion basée sur l’identifiant P-IDj»)). En référence à la , suite à la réception (G10) de la commande SET du serveur MANTEC 3 via leurs modules 10A de réception respectifs, les objets communicants S-OBJ1, …, S-OBJi(j) exécutent par l’intermédiaire de leurs modules 10B d’exécution les instructions contenues implicitement et/ou explicitement dans la commande et utilisent l’identifiant P-IDj en accord avec ces instructions (G20). Il s’en suit avantageusement un brouillage de l’utilisation de l’identifiant P-IDj par l’objet OBJj. On note que si le serveur MANTEC 3 a déjà été sollicité par un autre équipement 2 de confiance pour l’utilisateur U et pour l’identifiant persistant P-IDj, le serveur MANTEC 3 peut décider d’utiliser les objets communicants sélectionnés lors de la sollicitation de l’autre équipement de confiance et étendre la durée d’utilisation de l’identifiant P-IDj par ces objets communicants. A tout moment, le serveur MANTEC 3 peut contacter les objets communicants S-OBJ1, …, S-OBJi(j) sélectionnés pour utiliser l’identifiant P-IDj pour annuler ou renouveler l’utilisation par ces objets communicants de l’identifiant P-IDj (étape optionnelle F70). Ceci peut se faire au moyen d’une commande appropriée, par exemple conforme aux protocoles NETCONF ou RESTCONF. On note que l’invention vient d’être décrite dans un mode particulier de réalisation dans lequel le système 1 de brouillage comprend au moins un équipement de confiance associé à l’utilisateur, au moins un serveur MANTEC et une pluralité d’objets communicants gérés par ce serveur MANTEC et configurés pour mettre en œuvre un procédé d’utilisation selon l’invention. D’autres configurations peuvent bien entendu être envisagées. Le système 1 de brouillage peut notamment inclure un ou plusieurs objets communicants parmi les objets communicants surveillés par l’équipement de confiance, configurés pour mettre en œuvre un procédé d’exécution selon l’invention. De manière générale, le système 1 de brouillage s’appuie sur une pluralité d’objets communicants conformes à l’invention qui peuvent être configurés pour mettre en œuvre le procédé d’exécution selon l’invention et/ou le procédé d’utilisation selon l’invention. Procédé de surveillance d’objets communicants (O1’,…,Ok’) par un équipement de confiance (2) associé à un utilisateur, ledit procédé de surveillance comprenant : une étape (E40) de détection d’une utilisation par au moins un objet communicant (OBJj) d’au moins un identifiant persistant (P-IDj) ; et une étape (E70,E90) de déclenchement d’au moins une action de brouillage de ladite utilisation par ledit au moins un objet communicant dudit au moins un identifiant persistant. Procédé de surveillance selon la revendication 1 comprenant en outre, pour au moins un dit objet communicant (OBJj) identifié lors de l’étape de détection et au moins un identifiant persistant (P-IDj) utilisé par cet objet communicant, une étape (E60,E80) de détermination si ledit objet communicant est apte à exécuter une dite action de brouillage de l’utilisation de cet identifiant persistant, l’étape de déclenchement comprenant le cas échéant un envoi (E90) d’une commande à cet objet communicant pour qu’il exécute ladite action de brouillage. Procédé de surveillance selon la revendication 2 dans lequel ladite action de brouillage comprend une utilisation par ledit objet communicant d’un autre identifiant de même nature que ledit identifiant persistant à la place de celui-ci. Procédé de surveillance selon la revendication 3 dans lequel ledit autre identifiant est choisi par ledit objet communicant ou par ledit équipement de confiance. Procédé de surveillance selon la revendication 3 ou 4 comprenant en outre une étape (E100) de mise à jour d’au moins une règle d’acheminement et/ou de filtrage de trafic relative audit objet communicant avec ledit autre identifiant. Procédé de surveillance selon l’une quelconque des revendications 1 à 5 dans lequel pour au moins un dit objet communicant identifié lors de l’étape de détection et au moins un identifiant persistant utilisé par cet objet communicant, ladite étape de déclenchement comprend un envoi (E70) à au moins un serveur distant d’une instruction de déclencher une utilisation de cet identifiant persistant par au moins un autre objet communicant sélectionné par ledit au moins un serveur distant. Procédé de surveillance selon la revendication 6 dans lequel ladite instruction comprend en outre une indication d’une durée d’utilisation dudit identifiant persistant par ledit au moins un autre objet communicant et/ou d’une zone à laquelle doit être rattaché ledit au moins un autre objet communicant. Procédé de gestion d’objets communicants par un serveur (3), ledit procédé de gestion comprenant : une étape (F10) de réception, en provenance d’un équipement de confiance (2) associé à un utilisateur, d’une instruction de déclencher une utilisation d’au moins un identifiant persistant donné par au moins un objet communicant géré par ledit serveur ; une étape (F40) de sélection, pour ledit au moins un identifiant persistant désigné dans ladite instruction et pour ledit utilisateur, d’au moins un objet communicant (S-OBJ1, …, S-OBJi(j)) parmi une pluralité d’objets communicants (O1, …, Om) gérés par le serveur, apte à utiliser ledit au moins un identifiant persistant ; et une étape (F50) d’envoi d’une commande audit au moins un objet communicant sélectionné d’utiliser ledit au moins un identifiant persistant. Procédé de gestion selon la revendication 8 comprenant en outre avant d’exécuter l’étape de sélection et l’étape d’envoi, une étape d’authentification de l’équipement de confiance associé à l’utilisateur. Procédé de gestion selon la revendication 8 ou 9 dans lequel ledit au moins un objet communicant est sélectionné par ledit serveur parmi une pluralité d’objets communicants gérés par le serveur et rattachés à une zone (Z3) définie pour ledit utilisateur. Procédé de gestion selon l’une quelconque des revendications 8 à 10 dans lequel au moins un dit objet communicant est sélectionné aléatoirement par ledit serveur ou en fonction d’au moins une contrainte définie pour ledit utilisateur. Procédé de gestion selon l’une quelconque des revendications 8 à 11 comprenant en outre pour au moins un dit objet communicant sélectionné pour ledit utilisateur, une étape (F60) d’annulation ou une étape (F60) de renouvellement de ladite commande d’utilisation dudit au moins un identifiant persistant pour lequel ledit objet communicant a été sélectionné. Procédé selon l’une quelconque des revendications 1 à 12 dans lequel au moins un dit identifiant persistant est : une adresse MAC, Medium Access Layer ; une adresse IP, Internet Protocol ; un préfixe IP ; un identifiant d’ensemble de service SSID, Service Set IDentifier ; un identifiant de l’équipement de confiance ; ou un identifiant affecté à une interface radio. Procédé d’utilisation d’un identifiant par un objet communicant (S-OBJp), ledit procédé comprenant : - une étape (G10) de réception, en provenance d’un serveur (3), d’une commande d’utiliser un identifiant persistant déjà utilisé par un autre objet communicant, ladite commande fournissant audit objet communicant une indication d’au moins un comportement à adopter par ledit objet communicant en cas de tentative et/ou demande d’établissement d’une connexion par un dispositif tiers avec l’objet communicant au moyen dudit identifiant persistant ; - une étape (G20) d’utilisation dudit identifiant persistant et de mise en œuvre dudit au moins un comportement. Procédé d’exécution d’une action de brouillage par un objet communicant, ledit procédé comprenant : - une étape (H10) d’utilisation d’un identifiant persistant ; - une étape (H20) de réception d’une commande en provenance d’un équipement de confiance associé à un utilisateur (U) pour que l’objet communicant exécute une action de brouillage de l’utilisation dudit identifiant persistant ; et - une étape (H30) d’exécution de ladite action de brouillage. Equipement (2) de confiance associé à un utilisateur, configuré pour surveiller des objets communicants, ledit équipement de confiance comprenant : un module (2B) de détection, configuré pour détecter une utilisation par au moins un objet communicant d’au moins un identifiant persistant ; et un module (2C) de déclenchement, configuré pour déclencher au moins une action de brouillage de ladite utilisation par ledit au moins un objet connecté dudit au moins un identifiant persistant. Serveur (3) configuré pour gérer des objets communicants, ledit serveur comprenant : un module (3A) de réception, configuré pour recevoir en provenance d’au moins un équipement de confiance associé à un utilisateur, au moins une instruction de déclencher une utilisation d’au moins un identifiant persistant donné par au moins un objet communicant géré par ledit serveur ; un module (3B) de sélection, configuré pour sélectionner pour ledit au moins un identifiant persistant désigné dans ladite au moins une instruction et pour ledit utilisateur, d’au moins un objet communicant parmi une pluralité d’objets communicants gérés par le serveur apte à utiliser ledit au moins un identifiant persistant ; et un module (3C) de contrôle, configuré pour envoyer une commande audit au moins un objet communicant sélectionné d’utiliser ledit au moins un identifiant persistant. Objet communicant (Oj) comprenant : - un module (11A) de communication, configuré pour utiliser un identifiant persistant ; - un module (11B) de réception, configuré pour recevoir en provenance d’un équipement de confiance associé à un utilisateur (U) une commande pour que l’objet communicant exécute une action de brouillage de l’utilisation dudit identifiant persistant par ledit module de communication ; et - un module (11C) d’exécution configuré pour exécuter ladite action de brouillage. Objet communicant (O1, …., Om) comprenant : - un module (10A) de réception configuré pour recevoir, en provenance d’un serveur, une commande pour utiliser un identifiant persistant déjà utilisé par un autre objet communicant, ladite commande fournissant audit objet communicant une indication d’au moins un comportement à adopter par ledit objet communicant en cas de tentative et/ou de demande d’établissement d’une connexion par un dispositif tiers avec l’objet communicant au moyen dudit identifiant persistant ; - un module (10B) d’exécution configuré pour utiliser ledit identifiant persistant et mettre en œuvre ledit au moins un comportement. Système (1) de brouillage comprenant : au moins un équipement (2) de confiance associé à un utilisateur selon la revendication 16, configuré pour surveiller des objets communicants ; au moins un serveur (3) selon la revendication 17 ; et une pluralité d’objets communicants comprenant au moins un objet communicant (Oj’) selon la revendication 18 et/ou au moins un objet communicant (O1, …., Om) selon la revendication 19.