FR 3112057 A1 20211231 FR 2006717 A 20200626 Procédé et dispositif de sélection d’un réseau en mode non connecté. Ce procédé permet à un dispositif (100) de sélectionner un réseau fonctionnant en mode non connecté (N j ) parmi une pluralité de réseaux en mode non connecté (N 1 , N n ). Le dispositif (100) est déclaré auprès de ces réseaux. Il comporte une table (TP) pouvant mémoriser au moins deux profils (PROF 100, N1 , PROF 100, Nj ), chacun desdits profils (PROF 100, Nj ) correspondant à un (N j ) desdits réseaux en mode non connecté (N 1 , N n ). Le procédé comporte : - une étape (E30) de sélection d’un profil (PROF 100, Nj ) de ladite table (TP) ; et - une étape (E40) de connexion au réseau (N j ) correspondant audit profil en utilisant ledit profil (PROF 100, Nj ). Fig. 6 Procédé et dispositif de sélection d’un réseau en mode non connecté. L’invention se rapporte au domaine général des télécommunications, et plus particulièrement à celui de la sélection d’un réseau sans fil non connecté par un dispositif. L’homme du métier des réseaux de communication sans fil fait la distinction entre les réseaux en mode connecté et les réseaux en mode non connecté. Les réseaux en mode connecté (ou fonctionnant en mode connecté) sont les réseaux dans lesquels il existe un canal de communication établi en permanence entre le réseau et les dispositifs terminaux communiquant sur ces réseaux. A titre d’exemples, les réseaux GSM, Wi-Fi (marque déposée) et Bluetooth (marque déposée) sont des réseaux en mode connecté. Comme précisé dans le document https://fr.wikipedia.org/wiki/Mode_connecté, le mode connecté vise plus précisément « l'établissement d'une session de communication entre deux parties qui veulent échanger des données, cette session comportant e un début, une fin et une validation (vérification des erreurs), classiquement un identifiant et un mot de passe. Elle correspond à la couche n o 5 dite « session » du modèle OSI, entre les couches « présentation » et « transport » ». Au contraire, dans un réseau en mode non connecté, il n’existe pas de canal de communication établi en permanence entre les dispositifs terminaux et le réseau. Il n’existe pas non plus de mécanisme d’appairage entre les dispositifs terminaux et le réseau. A titre d’exemple, des réseaux fonctionnant en mode non connecté sont les réseaux fonctionnant selon le protocole LoRaWan (pour « Long Range Wide-area network »). La figure 1 illustre quatre objets connectés OC 1 à OC 4 , deux passerelles GW 1 , GW 2 , un serveur réseau NS et un serveur d’application AS dans un réseau fonctionnant selon le protocole LoRaWan (ou réseau LoRaWan) conforme à l’état de la technique. Les objets connectés OC 1 à OC 4 sont par exemple des équipements sans-fils basse consommation. Ils communiquent avec les passerelles GW 1 , GW 2 dans la bande de fréquences libres ISM en utilisant la modulation LoRa (marque déposée) développée par la société Semtech Corporation (marque déposée). Les passerelles GW 1 , GW 2 ne sont pas adressées spécifiquement par les objets connectés OC 1 à OC 4 : toutes les passerelles présentes dans la zone de couverture reçoivent les messages et les traitent. Elles jouent donc le rôle de passerelle entre une modulation LoRa, et une communication IP. Les informations transmises au serveur réseau NS par les objets connectés OC i sont authentifiées grâce à une clé AES 128 bits (en anglais « Advanced Encryption Standard ») appelée Network Session Key : NwkSKey OCi . Cette clé NwkSKey OCi sert à l’authentification entre un objet connecté OC i et un serveur réseau NS. Plus précisément, et de façon connue, afin de réaliser cette authentification entre l’objet connecté OC i et le serveur réseau NS, un champ MIC (pour « Message Integrity Control ») est ajouté à la trame. Il est calculé en fonction des données transmises et de la clé NwkSKey OCi . A réception, le même calcul est effectué par le serveur réseau NS. Si les clés NwkSKey OCi sont identiques dans l’objet connecté OC i et dans le serveur réseau NS alors les deux valeurs MIC calculées doivent correspondre. En plus de l’authentification, le serveur réseau NS gère d’autres fonctions de sécurité. Il élimine aussi les paquets en doublon, lorsque plusieurs passerelles ont reçu le même message d’un objet connecté. Le serveur d’application AS analyse les données reçues des objets connectés OC i . Par exemple, si les objets connectés sont des capteurs de température, le serveur d’application AS peut analyser et traiter les mesures de températures reçues de ces objets connectés via le réseau LoRaWAN. Le serveur d’application AS mémorise les identifiants ID OCi des objets connectés sous sa gestion. Les messages transmis au serveur d’application AS par les objets connectés OC i sont chiffrés grâce à une clé AES 128 bits appelée Application Session Key : AppSKey OCi . La figure 2 représente un objet connecté OC i conforme à l’état actuel de la technique. Il mémorise notamment un profil, ou plus généralement une structure de données, PROF i comportant son identifiant unique ID OCi , sa clef d’authentification NwkSKey OCi auprès du serveur réseau NS et sa clé de chiffrement AppSKey OCi . Il comporte également une application métier AM qui utilise ces informations pour envoyer des données au serveur d’application AS via le réseau correspondant à la clef d’authentification NwkSKey OCi . Les réseaux LoRaWAN sont maintenant répandus et des centaines de millions d’objets à travers le monde sont connectés via différents réseaux LoRaWAN, dont plus d’une centaine sont gérés par des opérateurs et bien davantage par des gestionnaires privés, notamment dans les pays où la couverture offerte par les opérateurs est insuffisante. Aujourd’hui, très peu d’opérateurs LoRaWAN sont interconnectés par des accords d’itinérance (en anglais « roaming ») et de nombreux gestionnaires privés souhaitent conserver des solutions propriétaires. Les initiatives de la LoRa Alliance pour faciliter l’interconnexion entre les réseaux LoRaWan, notamment par les principes d’itinérance passive et active définis par les spécifications v.1.1 n’ont à ce jour pas permis d’éviter un double morcellement des réseaux LoRaWAN, entre réseaux privés et réseaux opérés par des opérateurs publics d’une part, et entre les réseaux publics d’opérateurs n’ayant pas conclu d’accord d’itinérance d’autre part. L’invention vise à une solution à ce problème. Elle s’applique en particulier aux réseaux de type LPWA (pour « Low Power Wide Area ») fonctionnant en mode non connecté, ne présentant pas de fonctionnalités natives d’itinérance (« roaming » en terminologie anglo-saxonne). Ainsi, elle s’applique en particulier aux réseaux LoRaWAN mais plus généralement à tout réseau en mode non connecté. Plus précisément, l’invention concerne un procédé de sélection d’un réseau fonctionnant en mode non connecté parmi une pluralité de réseaux fonctionnant en mode non connecté, ce procédé étant mis en œuvre par un dispositif déclaré auprès de ces réseaux et comportant une table pouvant mémoriser au moins deux profils, chaque profil correspondant à un de ces réseaux en mode non connecté. Ce procédé comporte : - une étape de sélection d’un profil de la table ; et - une étape de connexion au réseau correspondant à ce profil en utilisant ledit profil. Corrélativement, l’invention concerne un dispositif comportant : - une table pouvant mémoriser au moins deux profils, chacun de ces profils correspondant à un réseau fonctionnant en mode non connecté parmi une pluralité de réseaux fonctionnant en mode non connecté auprès desquels le dispositif est déclaré. Ce dispositif comporte: - un module de sélection d’un profil de la table ; et - un module configuré pour connecter le dispositif au réseau correspondant à ce profil en utilisant ledit profil. Par souci de simplification, un réseau fonctionnant en mode non connecté est dit « réseau en mode non connecté » et un réseau fonctionnant en mode connecté est dit « réseau en mode connecté ». La déclaration préalable du dispositif auprès d’un réseau en mode non connecté consiste essentiellement à communiquer les éléments nécessaires à ce réseau, pour que le dispositif puisse se connecter au réseau en utilisant son profil. Dans un mode particulier de réalisation, chacun desdits profils comporte au moins une donnée permettant au dispositif de se connecter au réseau correspondant à ce profil et le dispositif se connecte à ce réseau en utilisant cette donnée. Dans un mode particulier de réalisation, l’invention est mise en œuvre dans des réseaux LoraWAN. L’invention peut plus généralement être mise en œuvre dans tout réseau en mode non connecté, et en particulier dans d’autres réseaux étendus à faible consommation énergétique (LPWAN, en anglais Low Power Wide Area Network). L’invention trouve une application particulière mais non limitative dans le contexte de l’Internet des Objets (IoT, en anglais Internet of Things). Dans un mode particulier de réalisation, le dispositif est intégré dans un objet connecté, par exemple un dispositif de mesure, une montre, … De façon remarquable, le procédé de sélection selon l’invention peut être est mis exclusivement en œuvre par les dispositifs se connectant au réseau en mode non connecté, autrement dit par les objets connectés, sans aucun impact sur les autres équipements du réseau, en particulier, dans le cas d’un réseau LoRaWAN, sur le serveur réseau au sens de la figure 1. En ce sens, le procédé de sélection selon l’invention peut être qualifié d’autonome. L’invention offre ainsi un mécanisme permettant à un objet connecté de sélectionner un réseau, sans impact sur le réseau. Elle offre ainsi une solution au problème d’interconnexion des réseaux, que ceux-ci soient gérés par des opérateurs publics ou par des gestionnaires privés. Elle ne requiert pas d’accord d’itinérance entre les opérateurs de réseau. L’invention peut être utilisée dans un modèle statique dans lequel le dispositif n’est pas nécessairement susceptible de se déplacer, mais susceptible d’être connecté à différents réseaux en mode non connecté. Par exemple, l’invention trouve une application dans laquelle le dispositif peut être utilisé dans différents pays, la table de profils comportant un profil pour chacun de ces pays. Dans un mode particulier de mise en œuvre, le dispositif sélectionne les profils dans la table de façon aléatoire ou cyclique. En reprenant l’exemple dans lequel le dispositif peut être utilisé dans différents pays, le dispositif peut sélectionner les profils de la table les uns après les autres jusqu’à ce que le profil correspondant au pays d’utilisation soit sélectionné. Dans un mode particulier de réalisation, le procédé de sélection comporte une étape pour détecter une éventuelle perte d’une capacité du dispositif à communiquer avec ledit réseau et, le cas échéant : - une étape de sélection d’un profil de la table ; et - une étape de connexion au réseau correspondant à ce profil, en utilisant ce profil. On considère par exemple que le dispositif perd une capacité à communiquer avec ledit réseau s’il sort de zone couverte par le réseau ou s’il cesse d’être authentifié ou autorisé à communiquer avec le réseau. En ce sens, le procédé de sélection selon l’invention peut être qualifié de « dynamique » puisqu’il permet avantageusement au dispositif de se connecter à un nouveau réseau en réaction à la détection d’une perte de capacité à communiquer avec le réseau auquel le dispositif est connecté à un instant donné. L’invention trouve ainsi une application en mobilité et permet de garantir une continuité de service lorsque le dispositif quitte la couverture d’un premier réseau et entre sous la couverture d’un deuxième réseau. Le dispositif selon l’invention peut par conséquent être mobile, par exemple porté par un objet connecté mobile ou par une personne. Dans un mode particulier de réalisation, la table est une table de profils priorisés, les profils étant associés à des priorités respectives mémorisées dans la table et la sélection d’un profil étant effectuée en fonction de sa priorité. L’invention permet ainsi de privilégier le premier réseau sélectionné selon différents critères ou de basculer dynamiquement une connexion établie sur un premier réseau vers un deuxième réseau plus pertinent au sens de ces critères. Les critères de sélection d’un réseau peuvent être de toute nature. Dans un mode particulier de réalisation, le procédé de sélection comporte une étape de modification d’au moins une des priorités. Le dispositif peut ainsi privilégier ou au contraire défavoriser certains réseaux dynamiquement, par exemple en fonction de la fiabilité de ces réseaux. Dans un mode particulier de réalisation, ladite table peut être mise à jour pour ajouter un profil à la table et/ou supprimer un profil de la table et/ou modifier la priorité d’au moins un des profils de la table. En effet, si la table de profils d’un dispositif doit pouvoir comporter plusieurs profils, cette table peut ne comporter aucun profil ou un seul profil. Le premier profil peut par exemple être chargé par un terminal incorporant le dispositif par tout moyen, par exemple via un câble USB, par lecture d’une étiquette RFID … Les autres profils peuvent être téléchargés dans la table par ce mêmes moyens ou par un mécanisme OTA (en anglais Over The Air). Dans un mode particulier de réalisation, le procédé de sélection comporte une étape pour détecter une éventuelle modification de la table et, le cas échéant : - une étape de sélection d’un profil de ladite table ; et - une étape de connexion au réseau correspondant audit profil en utilisant ce profil. Ce mode de réalisation permet en particulier au dispositif de se connecter ou de basculer vers un nouveau réseau dès qu’un profil associé à ce réseau est téléchargé dans la table de profils. Dans un mode particulier de réalisation, la donnée comprise dans le profil et permettant au dispositif de se connecter à un réseau en mode non connecté est une clef d’authentification permettant au dispositif de s’authentifier auprès d’un serveur de ce réseau. Dans un mode particulier de réalisation, les profils comportent en outre une clé de chiffrement associée à un serveur d’application. Le procédé de sélection selon l’invention est une solution purement logicielle. Il peut être mis en œuvre par un programme d’ordinateur. Par conséquent, l’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un dispositif ou plus généralement dans un ordinateur. Ce programme comporte des instructions permettant la mise en œuvre d’un procédé tel que décrit ci-dessus. Ce programme 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, les supports peuvent 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 une disquette (floppy disc) ou 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'informations 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 de l’un des procédés tels que décrits précédemment. 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 figure 1 déjà décrite représente un réseau LoRaWAN de l’état actuel de la technique ; la figure 2 déjà décrite représente un objet connecté conforme à l’état actuel de la technique ; la figure 3 représente un exemple d’environnement dans lequel l’invention peut être mise en œuvre; la figure 4 représente l’architecture matérielle d’un dispositif conforme à un mode particulier de réalisation ; la figure 5 représente un exemple de profil pouvant être utilisé dans un dispositif conforme à un mode particulier de réalisation ; la figure 6 représente sous forme d’ordinogramme un procédé de sélection conforme à un mode particulier de réalisation ; et la figure 7 représente l’architecture fonctionnelle d’un dispositif conforme à un mode particulier de réalisation. Description détaillée de modes de réalisation particuliers La figure 3 représente un exemple d’environnement dans lequel l’invention peut être mise en œuvre. Dans cet exemple, on considère n réseaux en mode non connecté, par exemple de type LoRaWAN N 1 à N n. Chaque réseau N j comporte une ou plusieurs passerelles GW et un serveur réseau NS j . Un serveur d’application AS est relié aux réseaux N 1 à N n par un réseau étendu, par exemple le réseau Internet.. La figure 4 représente l’architecture matérielle d’un dispositif 100 conforme à l’invention. Dans l’exemple de réalisation décrit ici, ce dispositif 100 a l’architecture matérielle d’un ordinateur. Il comporte notamment un processeur 10, une mémoire vive de type RAM 11, une mémoire morte de type ROM 12, une mémoire non volatile réinscriptible de type Flash 14 et des moyens de communication 13. La mémoire morte 12 constitue un support conforme à un mode particulier de réalisation de l’invention. Cette mémoire comporte un programme d’ordinateur PGSD conforme à un mode particulier de réalisation de l’invention, qui lorsqu’il est exécuté par le processeur 10, met en œuvre le d’un procédé de sélection conforme à l’invention et décrit ultérieurement en référence à la figure 6. Dans le mode de réalisation décrit ici, la mémoire 14 du dispositif 100 comporte une table TP de profils priorisés. Dans l’exemple de la figure 4, la table TP comporte trois profils PROF 100, N1 , PROF 100, N2 et PROF 100, Nj de priorités respectives p 1 , p 2 , et p j permettant au dispositif 100 de s’authentifier respectivement auprès des réseaux N1, N2 et Nj. A titre d’exemple, la figure 5 représente le profil PROF 100, Nj : il comporte l’identifiant unique ID 100 du dispositif 100, sa clef d’authentification NwkSKey 100, Nj auprès du serveur NS j du réseau Nj et sa clé de chiffrement AppSKey 100 associée au serveur d’application AS. La figure 6 représente sous forme d’ordinogramme les principales étapes d’un procédé de sélection conforme à un mode particulier de réalisation. Dans le mode de réalisation décrit ici, ce procédé est mis en œuvre par le dispositif 100 de la figure 4. On suppose dans cet exemple que le dispositif 100 a préalablement été déclaré auprès des serveurs réseau NS 1 , NS 2 et ND j , le dispositif 100 étant susceptible de se trouver à un moment donné sous la couverture d’au moins une passerelle des réseaux N 1 , N 2 ou N j . La déclaration auprès du serveur réseau NS j peut être effectuée via un portail ou via une API (en anglais « Application Programming Interface ») d’une plateforme de l’opérateur ou du gestionnaire du réseau N j . Au cours d’une étape E10, les profils PROF 100, N1 , PROF 100, N2 et PROF 100, Nj du dispositif 100 pour les réseaux respectifs N 1 , N 2 ou N j sont enregistrés dans la table de profils priorisés TP. Chacun des profils PROF 100, Nj est associé initialement à une priorité p. On suppose dans cet exemple qu’initialement, un profil PROF 100, Nj est associé à la priorité p j , la priorité p 1 étant la plus prioritaire. Les profils de la table TP et la priorité de ces profils sont susceptibles de varier dans le temps, en particulier de façon dynamique : de nouveaux profils peuvent être ajoutés à la table de profils TP, des profils peuvent être supprimés de la table des profils TP et les priorités d’un ou plusieurs profils présents dans la table de profils TP peuvent être modifiées. Par exemple, si le dispositif 100 détecte qu’un critère de connectivité d’un réseau N k diminue, il modifie la priorité p k de ce réseau pour que celui-ci devienne moins prioritaire. Ce critère de qualité de connectivité, ou de qualité globale de connectivité peut par exemple tenir compte de la fréquence d’utilisation du réseau, de taux de non joignabilité, de taux d’erreurs, etc. Par exemple la table de profils TP peut être mise à jour à travers le réseau selon un mécanisme OTA (en anglais « Over The Air ») par une trame reçue du serveur réseau NS. Elle peut aussi être mise à jour depuis un terminal (par exemple un téléphone intelligent, en anglais « smartphone ») si le dispositif 100 peut établir une communication (USB, BLE, NFC …) avec ce terminal. Elle peut également être mise à jour par lecture d’une étiquette RFID si le dispositif 100 est configuré pour pouvoir lire de telles étiquettes. Dans le mode de réalisation décrit ici, le procédé exécute alors une boucle infinie comportant les étapes E20 à E80 décrites ci-après. Au cours d’une étape E20, le dispositif 100 obtient la liste des profils enregistrés dans la table des profils TP. Dans un mode de réalisation, au cours d’une étape E30, le dispositif 100 sélectionne le profil de priorité la plus élevée puis (étape E40) essaie de se connecter au réseau correspondant à ce profil. Par conséquent, dans l’exemple particulier décrit ici, le dispositif 100 essaie de se connecter au réseau N 1 , puis s’il échoue au réseau N 2 , puis s’il échoue au réseau N j . Pour se connecter au réseau N 1 par exemple, le dispositif 100 utilise la clé d’authentification NwkSKey 100, N1 auprès du serveur NS 1 , comprise dans le profil PROF 100, N1 . Lorsque le réseau en mode non connecté est un réseau de type LoRaWAN, la tentative de connexion peut être effectuée par l’envoi d’une commande de type JOIN_ACCEPT. Dans un autre mode de réalisation, le dispositif sélectionne le profil de manière aléatoire. Dans le mode de réalisation décrit ici, le résultat du test E40 est positif si le dispositif 100 parvient à s’authentifier auprès d’un réseau et négatif dans le cas contraire. On suppose dans cet exemple que le dispositif 100 parvient effectivement à s’authentifier auprès du serveur réseau NS 1 . Au cours d’une étape E50, le dispositif 100 exécute son application métier AM. Cette application métier embarquée dans le dispositif 100 correspond à la fonction première du dispositif 100, par exemple acquérir une mesure (température, fréquence vibratoire) avec un capteur du dispositif 100 et à envoyer cette mesure au serveur d’application AS. L’application métier utilise à cet effet la clé d’authentification NwkSKey 100, N1 auprès du serveur NS 1 et la clé de chiffrement AppSKey 100 associée au serveur d’application AS. Ces clés sont donc des variables de l’application métier AM. Au cours d’une étape E60, le dispositif 100 vérifie s’il est toujours apte à communiquer avec ledit réseau, par exemple s’il est toujours dans une zone couverte par le réseau et authentifié auprès du réseau (en l’occurrence avec le réseau N 1 dans cet exemple). Lorsque le réseau en mode non connecté est un réseau de type LoRaWAN, cette vérification peut consister à envoyer une demande d’état LINK_CHECK_REQUEST. Elle peut aussi consister à vérifier si des messages de confirmation ont été reçus en réponse à des messages envoyés par le dispositif 100 au serveur NS ou au serveur d’application AS. Si le dispositif considère qu’il n’est plus en mesure de communiquer avec le réseau (en l’occurrence N1), le résultat du test E60 est positif et le dispositif 100 exécute à nouveau l’étape E30 pour sélectionner le profil de priorité la plus élevée (en l’occurrence le profil PROF 100, N2 ) et essayer (étape E40) de se connecter au réseau N 2 correspondant à ce profil. Si au cours du test E60 le dispositif 100 détermine que la connexion en cours est toujours active, le résultat du test E60 est négatif et le dispositif 100 exécute une étape E70 pour déterminer si sa table des profils TP a été mise à jour (ajout d’un nouveau profil, suppression d’un profil, modification d’une priorité). Si tel est le cas le résultat du test E70 est positif et le procédé exécute à nouveau l’étape E20 d’obtention de sa table de profils, afin de sélectionner le profil de priorité la plus élevée (étape E30) pour tenter de se connecter (étape E40) au réseau associé à ce profil. Si la table de profils TP n’a pas été modifiée, le résultat du test E70 est négatif. Dans le mode de réalisation décrit ici, le dispositif 100 détermine au cours d’une étape E80 si la priorité des profils de la table TP doit être modifiée. Si c’est le cas, le dispositif 100 modifie les priorités au cours de cette même étape. Les priorités peuvent par exemple être modifiées automatiquement par le dispositif 100 pour privilégier les réseaux les plus fiables ou les plus fréquemment connectés, par exemple selon un mécanisme de pondération. Par exemple, dans un mode de réalisation, le dispositif 100 mémorise un historique de ses connexions précédentes avec les différents réseaux et modifie les priorités des profils associés à ces réseaux en en fonction de cet historique. Cet historique peut par exemple enregistrer les critères de connectivité mentionnés précédemment (fréquence d’utilisation du réseau, taux de non joignabilité, taux d’erreurs, etc). Par exemple si le dispositif 100 détermine qu’un réseau N k est statistiquement plus disponible que les autres, ou qu’un critère de connectivité augmente pour ce réseau, le dispositif 100 peut choisir de relever la priorité du profil associé à ce réseau. La priorité associée à un réseau peut aussi être modifiée par le dispositif 100 en fonction de paramètres obtenus ou mesurés par le dispositif, par exemple représentatifs de sa localisation, de l’heure courante, de son niveau de batterie … Puis le dispositif 100 exécute à nouveau l’application métier (par retour à l’étape E50), par exemple pour acquérir une nouvelle mesure et l’envoyer cette mesure au serveur d’application AS. La figure 7 représente l’architecture fonctionnelle d’un dispositif 100 conforme à l’invention. Dans l’exemple de réalisation décrit ici, le dispositif 100 comporte : - un capteur CAP ; - une table TP de profils telle que mentionnée ci-dessus ; - un module MSP configuré pour sélectionner un profil de ladite table TP ; et - un module MCR configuré pour connecter le dispositif 100 à un réseau N j en utilisant les données comprises dans un profil de la table TP associé à ce réseau; - une application métier AM configurée pour envoyer des mesures acquises par le capteur CAP à un serveur d’application AS, ces mesures étant chiffrées par une clé de chiffrement AppSKey 100 comprise dans le profil ; - un module MDP configuré pour détecter une perte de connexion du dispositif 100 ; et - un module MDM configuré pour détecter une modification de la table de profils. Les modules MSP, MCR, MDP et MDM peuvent être implémentés selon l’architecture matérielle décrite en référence à la figure 4. Procédé de sélection d’un réseau fonctionnant en mode non connecté (N j ) parmi une pluralité de réseaux en mode non connecté (N 1 , N n ), ledit procédé étant mis en œuvre par un dispositif (100) déclaré auprès des réseaux (N 1 , N n ) et comportant une table (TP) pouvant mémoriser au moins deux profils (PROF 100, N1 , PROF 100, Nj ), chacun desdits profils (PROF 100, Nj ) correspondant à un (N j ) desdits réseaux fonctionnant en mode non connecté (N 1 , N n ), ledit procédé comportant : - une étape (E30) de sélection d’un profil (PROF 100, Nj ) de ladite table (TP) ; et - une étape (E40) de connexion au réseau (N j ) correspondant audit profil (PROF 100, Nj ) en utilisant ledit profil (PROF 100, Nj ). Procédé de sélection selon la revendication 1 dans lequel ladite table (TP) est une table de profils priorisés, lesdits profils (PROF 100, N1 , PROF 100, Nj ) étant associés à des priorités respectives (p j ) mémorisées dans ladite table (TP), la sélection (E30) d’un profil étant effectuée en fonction de sa priorité. Procédé de sélection selon la revendication 1 ou 2 dans lequel ladite table (TP) peut être mise à jour dynamiquement pour ajouter un profil à ladite table et/ou supprimer un profil de ladite table et/ou modifier la priorité d’au moins un des profils de ladite table. Procédé de sélection selon l’une quelconque des revendications 1 à 3 comportant une étape (E60) pour détecter une éventuelle perte d’une capacité du dispositif (100) à communiquer avec ledit réseau (N j ) et, le cas échéant : - une étape (E30) de sélection d’un profil (PROF 100, Nj ) de ladite table (TP) ; et - une étape (E40) de connexion au réseau (N j ) correspondant audit profil (PROF 100, Nj ) en utilisant ledit profil (PROF 100, Nj ). Procédé de sélection selon l’une quelconque des revendications 1 à 4 comportant une étape (E70) pour détecter une éventuelle modification de ladite table (TP) et, le cas échéant : - une étape (E30) de sélection d’un profil (PROF 100, Nj ) de ladite table (TP) ; et - une étape (E40) de connexion au réseau (N j ) correspondant audit profil (PROF 100, Nj ) en utilisant ledit profil (PROF 100, Nj ). Procédé de sélection selon l’une quelconque des revendications 2 à 5 comportant une étape (E100) de modification d’au moins une desdites priorités (p j ). Procédé de sélection selon l’une quelconque des revendications 1 à 6 dans lequel chacun desdits profils (PROF 100, Nj ) comporte une donnée (NwkSKey 100, Nj ) permettant au dispositif (100) de se connecter au réseau correspondant audit profil. Procédé de sélection selon la revendication 7, dans lequel ladite donnée est une clef d’authentification permettant audit dispositif (100) de s’authentifier auprès d’un serveur (NS j ) d’un (N j ) desdits réseaux en mode non connecté (N 1 , N n ). Procédé de sélection selon l’une quelconque des revendications 1 à 7 dans lequel lesdits profils (PROF 100, Nj ) comportent une clé de chiffrement (AppSKey 100 ) associée à un serveur d’application (AS). Procédé de sélection selon l’une quelconque des revendications 1 à 9 dans lequel lesdits réseaux en mode non connecté (N 1 , N n ) sont des réseaux LoraWAN. Dispositif (100) comportant : - une table (TP) pouvant mémoriser au moins deux profils (PROF 100, N1 , PROF 100, Nj ), chacun desdits profils (PROF 100, Nj ) correspondant à à un réseau fonctionnant en mode non connecté (N j ) parmi une pluralité de réseaux fonctionnant en mode non connecté (N 1 , N n ) auprès desquels ledit dispositif (100) est déclaré, ledit dispositif comportant : - un module (MSP) de sélection d’un profil (PROF 100, Nj ) de ladite table (TP) ; et - un module (MCR) configuré pour connecter ledit dispositif (100) au réseau (N j ) correspondant audit profil (PROF 100, Nj ) en utilisant ledit profil (PROF 100, Nj ). Programme d’ordinateur (PGSD) comportant des instructions configurées pour mettre en œuvre les étapes d’un procédé de sélection selon l’une quelconque des revendications 1 à 10 lorsqu’elles sont exécutées par un ordinateur (100).