FR 3050843 A1 20171103 FR 1653900 A 20160429 1 PROCEDE ET PLATEFORME DE COMMUNICATION HOMOGENE ENTRE HUMAINS ET OBJETS CONNECTÉS DOMAINE TECHNIQUE L'invention se situe dans le domaine des communications bidirectionnelles entre une pluralité de sources et une pluralité de destinataires, et concerne plus spécifiquement un procédé et une plateforme intelligente de communication entre une pluralité de sources et une pluralité de destinataires susceptibles d'échanger des messages et/ou des données via ladite plateforme intelligente, chaque source et chaque destinataire étant susceptible d'utiliser soit des langages construits spécifiques, soit un ou plusieurs langages naturels. L'invention concerne également un programme d'ordinateur mémorisé sur un support d'enregistrement et comportant des instructions pour mettre en oeuvre le procédé selon l'invention lorsqu'il est exécuté par ordinateur. ÉTAT DE LA TECHNIQUE ANTÉRIEURE De plus en plus, les objets communicants, ou objets connectés, et les services numériques sont utilisés comme support à de nombreux services dans la plupart des domaines d'activité personnelle, de la vie professionnelle et aussi de l'environnement public, par exemple, dans le domaine de la santé, de l'assistance aux humains, de la maison connectée, de la ville intelligente, de la sécurité, de l'agriculture, des véhicules autonomes, de la gestion de l'énergie, les robots industriels et de services, etc... Ces objets connectés échangent des informations par l'intermédiaire d'interfaces numériques issues du monde des télécommunications et du monde de l'Internet (web). A cet effet, plusieurs recommandations et plusieurs standards existent, élaborés totalement ou partiellement, par divers organismes tels que l'European Telecommunications Standards Institute (ETSI), le World Wide Web Consortium (W3C), l'Open Interconnect Consortium (01C), la Allseen Alliance, le TeleManagement Forum (TMF), OASIS, etc. Ces différentes recommandations et standards ont notamment pour but : - de permettre un certain niveau d'interopérabilité entre les infrastructures, les objets connectés et les services qui les mettent en oeuvre ; 3050843 2 de limiter les efforts et les coûts de développements, de déploiement et de maintenance de ces objets et services ; de simplifier la mise en oeuvre pour les utilisateurs, en particulier lorsque ceux-ci utilisent les objets et services en nombre important, par exemple en limitant 5 la quantité d'applications nécessaires pour gérer ces objets et services. Cependant, l'abondance et la diversité des objets connectés, des services numériques, des normes et protocoles de communication, provoquent une multiplicité de types de commandes, de paramètres, d'unités, de conventions, de présentations, etc.... de sorte que, pratiquement, chaque objet possède son propre langage de communication 10 avec l'extérieur. Faire face à cette abondance en développant autant d'adaptation ad-hoc qu'il y a d'objets ou de familles d'objets, comme cela se fait au sein des "hubs numériques", est une solution complexe, coûteuse et peu adaptée à l'explosion présente et à venir du nombre d'objets connectés et de services numériques. Par ailleurs, les solutions préconisées à cet effet ne tiennent pas compte des problèmes de communication entre les 15 différents "hubs numériques". En outre, la multiplicité des besoins, des usages, des éditeurs de logiciel, des constructeurs d'objets connectés, des fournisseurs de services numérique en lignes, et des organismes de standardisation conduit à une multitude d'options peu propices à des échanges simples entre les différents composants de ces services (objets, services locaux, services web, etc.), entre les objets eux-mêmes et les 20 utilisateurs de ces services (humains, animaux, robots, autres services, etc.). Enfin, les architectures de communication traditionnelles fonctionnent en silo de sorte que les applications et les mécanismes impliqués dans les échanges entre humains sont différents de ceux mis en oeuvre dans les échanges entre humains d'une part et objets connectés et services numériques d'autre part, ainsi qu'entre objets connectés. 25 Dans le cas des échanges entre humains, le système de communication des architectures de communication traditionnelles s'attache à transmettre l'information en langage naturel (voix, vidéo, texte) sans la déformer. En outre, les échanges entre humains et objets connectés ou services numériques sont essentiellement réalisés à partir d'interfaces graphiques (GUI pour graphical user interface) ou en ligne (CLI pour command-line interface) qui guident les échanges et les restreignent aux possibilités des objets et services 3050843 3 impliqués. Pour leur part, les échanges entre objets connectés impliquant ou non des services numériques sont réalisés à partir d'interfaces spécialisées conçues spécifiquement pour les langages informatiques (API), spécifiques à chaque objet et service, et interconnectés au moyen de plateformes parfois appelées "hubs numériques" 5 Par ailleurs, outre les obstacles dus au foisonnement des modes et des formats de communication des objets connectés et des services numériques, les architectures de communication traditionnelles rencontrent un problème de convergence qui provient du décalage des modes d'échanges entre humains, objets connectés et services numériques. En effet, bien que les d'interfaces utilisateur mises en oeuvre dans les 10 terminaux modernes de type "Smartphones" et tablettes facilitent les échanges entre le monde des humains et le monde du numérique au moyen de graphismes relativement aisés d'utilisation, ces interfaces sont conçues seulement pour canaliser l'expression des utilisateurs vers les capacités restreintes de leurs interlocuteurs numériques (objets et services connectés), leur demandant d'apprendre un 'langage' pour chacun des objets 15 connectés ou des services numériques qu'ils souhaitent utiliser. Ces restrictions dans l'expression humaine constituent un obstacle significatif à la convergence homme/machine. En effet, dans les technologies actuelles les modes de commandes des objets connectés sont précis et fermés et utilisent une liste de commandes avec un lexique, une syntaxe et des paramètres figés, spécifiques à chaque objet ou famille d'objets. De ce 20 fait, les utilisateurs humains de ces objets et services communicants doivent passer par des interfaces utilisateur en ligne (CLI - Command Line Interface) ou graphiques (GUI - Graphical User Interface) qui restreignent leur choix et qui les guident vers un nombre réduit d'options. Les technologies de traitement numérique du langage naturel (Natura I 25 Language Processing - NLP) connues permettent déjà d'utiliser certains équipements ou services à partir du langage naturel, le plus souvent oral. Par exemple Siri© de Apple© ou Cortana© de Microsoft© proposent un service d'assistant virtuel permettant d'effectuer des opérations telles que la recherche d'informations sur Internet ou la réservation de billets de transport en utilisant des commandes vocales ; Nuance Communication© 30 commercialise également des produits et services de support téléphonique à la clientèle à 3050843 4 partir d'agents virtuels simulant des opérateurs humains ; Alexa© de Amazone propose un service d'interface vocale pour des services tiers. Cependant, ces technologies constituent un ajout d'une interface complémentaire aux services que l'on peut appeler NLI (Natural Language Interface) par analogie aux interfaces graphiques (GUI) et en ligne 5 de commande (CLI). En outre, bien qu'elles permettent de simplifier l'accès aux différents services qui les utilisent, ces technologies demandent des développements spécifiques à chaque service et fonction supportés et introduisent de nouvelles rigidités dans les usages, telle que l'utilisation de phrases clés par exemples. En plus, elles ne permettent pas de pallier le problème du foisonnement d'objets connectés et des services numérique utilisant 10 des langages et des protocoles de communications différents. EXPOSÉ DE L'INVENTION Un but de l'invention est de pallier les inconvénients de l'art antérieur décrits ci-dessus. Un autre but de l'invention est d'unifier les échanges que peuvent avoir 15 les humains, les objets connectés et les services numériques entre eux (par exemple entre objets connectés, entre humains et objets, etc.) autour d'un langage naturel commun. D'autres utilisateurs peuvent également être concernés, en particulier les animaux et les robots. Dans la suite de la description, on désignera par langage naturel cible 20 (CNL - Core Natural Langage), le langage naturel commun utilisé, et par langage construit, un langage numérique composé de commandes, paramètres, codages des informations, conventions implicites ou explicites, etc. couplé à un ou plusieurs protocoles de communication permettant de communiquer avec un ou plusieurs objets connectés. Ces langages construits peuvent varier en fonction des objets et des applications. 25 Le langage naturel cible peut par exemple être une langue largement répandue telle que l'anglais, mais d'autres langages naturels sont également possibles. Il est choisi soit par configuration ou tout autre mode (vote, négociation...). Ces buts sont atteints au moyen d'un procédé de communication entre une pluralité de sources et une pluralité de destinataires susceptibles d'échanger des 30 informations, soit en langages construits, soit en langage naturel, via une plateforme 3050843 5 intelligente comportant une pluralité d'unités distribuées de traitement de l'information comprenant au moins une unité bidirectionnelle d'échange en langage naturel NLXS, au moins une première unité de conversion de langage, au moins une première unité d'adaptation de média et de protocole associés à la source, et au moins une deuxième unité 5 de conversion de langage et au moins un deuxième module d'adaptation de média et de protocole associés au destinataire. Notons que les sources et les destinataires peuvent être soit des humains, soit des objets connectés, soit des services numériques et peuvent être soit émetteurs soit récepteurs de messages. 10 Le procédé selon l'invention comporte les étapes suivantes : - côté émission, - intercepter par la première unité d'adaptation de média et de protocole les informations envoyées par au moins une source à au moins un destinataire, - déterminer le type de langage décrivant les informations interceptées, et, 15 si le langage décrivant les informations interceptées est un langage construit, - convertir automatiquement ledit langage construit en langage naturel au moyen de la première unité de conversion de langage, - transmettre lesdites informations en langage naturel au destinataire via le module bidirectionnel d'échange en langage naturel NLXS, et, 20 - côté réception, si le langage du destinataire est un langage construit, convertir automatiquement le message en langage naturel du message émis en un message dans le langage construit au moyen de la deuxième unité de conversion de langage, puis, 25 fournir les informations en langage construit au destinataire via le deuxième module d'adaptation de média et de protocole, si le langage du destinataire est un langage naturel, fournir les informations en langage naturel au destinataire. Le procédé selon l'invention comporte en outre une étape d'analyse des 30 informations échangées en langage naturel entre les humains, les objets et les services 3050843 6 reliés via ladite plateforme intelligente, et une étape de résolution des ambiguïtés et des incohérences relevées au moyen de ladite étape d'analyse. Optionnellement, le procédé selon l'invention comporte une procédure d'apprentissage par la plateforme intelligente des modes d'utilisation par les sources et par 5 les destinataires des langages naturels cibles et des langages construits de manière à améliorer les performances de conversion et de résolutions d'ambiguïté et de cohérence d'un langage naturel humain et d'un langage construit. Préférentiellement, ladite procédure d'apprentissage est exécutée automatiquement, en tâche de fond, sans interférer directement avec les étapes de 10 conversion et de résolutions d'ambiguïté. Ladite procédure d'apprentissage comporte les étapes suivantes : - classer les informations échangées en fonction des différentes sources, - analyser les contenus desdites informations échangées, - enrichir progressivement au moins une base d'information utilisée par 15 l'ensemble des sources de même type ou de même famille. En outre, pour les informations échangées ayant nécessité une procédure de résolution d'ambiguïté ou de cohérence, la procédure d'apprentissage comporte en outre les étapes suivantes : - analyser les contenus desdites informations, 20 - enrichir progressivement au moins une base d'information utilisée par l'ensemble des sources de même type ou de même famille. Le procédé selon l'invention est mis en oeuvre via une plateforme intelligente de communication entre une pluralité de sources et une pluralité de destinataires susceptibles d'échanger des informations soit en langages construits, soit en 25 langage naturel, comportant une pluralité d'unités distribuées de traitement de l'information comprenant au moins une unité bidirectionnelle d'échange en langage naturel NLXS, au moins une première unité de conversion de langage et au moins une première unité d'adaptation de média et de protocole associés à la source, au moins une deuxième unité de conversion de langage et au moins un deuxième unité d'adaptation de 30 média et de protocole associés au destinataire. 3050843 7 La plateforme selon l'invention est caractérisée en ce que : - la première unité d'adaptation de média et de protocole est configurée pour intercepter les informations envoyées par au moins une source à au moins un destinataire et pour déterminer le type de langage décrivant les informations interceptées, 5 et - la première unité de conversion de langage est configurée pour convertir automatiquement le message en langage construit décrivant des informations interceptées en un message en langage naturel, - l'unité bidirectionnelle d'échange en langage naturel NLXS est 10 configurée pour transmettre lesdites informations en langage naturel au destinataire ; - la deuxième unité de conversion de langage est configurée pour convertir automatiquement les messages en langage naturel en messages en langage construit si le langage du destinataire est un langage construit. Dans un mode préféré de réalisation, la plateforme selon l'invention 15 comporte : - une unité de sélection d'un langage naturel cible commun, - une unité bidirectionnelle destinée à aligner les messages et unités en langage naturel vers le langage naturel cible sélectionné (LUTA pour Langage, Units and Time Alignment), 20 - une unité bidirectionnelle de contrôle et de résolution de grammaire, d'ambiguïté et de pertinence des informations échangées en langage naturel cible (LARC, pour Language Ambiguity and Relevance Controller), - une unité bidirectionnelle de conversion des messages entre le langage naturel cible et les langages construits (NLAC pour Natural Langage to API Converter). 25 Ladite plateforme comporte en outre une unité d'apprentissage des modes d'utilisation par les sources et par les destinataires des langages naturels cibles et des langages construits de manière à améliorer les performances de conversion et de résolutions d'ambiguïté d'un langage naturel humain et/ou d'un langage construit. 3050843 8 BRÈVE DESCRIPTION DES DESSINS D'autres caractéristiques et avantages de l'invention ressortiront de la description qui va suivre, prise à titre d'exemple non limitatif, en référence aux figures annexées dans lesquelles : 5 - la figure 1 est un schéma général illustrant une plateforme de communication selon l'invention, - la figure 2 représente schématiquement une architecture de la plateforme de la figure 1 montrant les différentes couches de traitement des informations échangées entre une source et un destinataire via la plateforme de la figure 1, 10 - la figure 3 illustre schématiquement un environnement technique des éléments composant la plateforme de la figure 1, - la figure 4 représente schématiquement et partiellement les unités de la plateforme 1 permettant de réaliser des échanges d'informations entre un humain et un objet connecté, 15 - la figure 5 représente schématiquement et partiellement les unités de la plateforme 1 permettant de réaliser des échanges d'informations entre deux objets connectés, - les figures 6 et 7 représentent respectivement des schémas fonctionnels illustrant de façon détaillée les étapes de traitement des informations échangées entre un 20 humain et un objet connecté via la plateforme selon l'invention, - les figures 8 et 9 représentent des schémas fonctionnels illustrant de façon détaillée les étapes de traitement des informations échangées entre deux objets connectés via la plateforme selon l'invention, - les figures 10A et 10E3 illustrent respectivement les étapes essentielles 25 des traitements appliqués à un message transmis par une source distante à un destinataire, et les étapes essentielles des traitements appliqués à un message en langage naturel cible transmis par le destinataire en réponse au message reçu de ladite source distante, - la figure 11 est un organigramme détaillé illustrant l'alignement du langage naturel de la source distante sur un langage naturel cible sélectionné, 3050843 9 - figure 12 est un organigramme détaillé de l'étape d'alignement des unités utilisées par la source distante sur celles utilisées par le destinataire, - la figure 13 est un organigramme détaillé de l'étape d'alignement des références de date, d'heure et de durée utilisées par la source distante sur celles utilisées 5 par un objet connecté ou un service numérique, - la figure 14 est un organigramme détaillé de l'étape d'alignement des références de date, d'heure et de durée utilisées par un destinataire, émetteur d'un message en langage naturel cible, sur celles utilisées par la source distante de la figure 10, - la figure 15 est un organigramme détaillé de l'étape d'alignement des 10 unités utilisées par le destinataire, émetteur d'un message en langage naturel cible, sur celles utilisées par la source distante de la figure 10, - La figure 16 est un organigramme détaillé de l'étape d'alignement du langage naturel cible du destinataire, émetteur vers le langage naturel de la source distante de la figure 10, 15 - la figure 17 représente une vue détaillée d'une unité de résolution d'ambiguïté et de pertinence de la plateforme selon l'invention, - la figure 18 représente un organigramme des étapes de contrôle d'ambiguïté et de pertinence d'un message en langage naturel cible d'un utilisateur distant au moyen de l'unité de la figure 17, 20 - la figure 19 représente un organigramme des étapes de transformation des informations en langage naturel cible vers un langage construit utilisé par un objet connecté ou un service numérique, - la figure 20 représente un organigramme des étapes de transformation des informations en langage construit (format numérique de pilotage des objets connectés 25 ou format numérique de pilotage des services numériques) en langage naturel cible, - la figure 21 illustre schématiquement les étapes d'un échange relatif à une demande d'assistance entre deux objets communicants. 3050843 10 EXPOSÉ DÉTAILLÉ DE MODES DE RÉALISATION PARTICULIERS La figure 1 représente une vue générale montrant des sources et des destinataires de différentes natures susceptibles de communiquer via une plateforme 1 selon l'invention. Ces sources et ces destinataires peuvent être soit des humains 2 munis 5 d'un dispositif de communication tel que par exemple un ordinateur, une tablette 4, ou un Smartphone, soit des robots connectés 6, ou encore des animaux 7 munis de boîtiers électroniques comportant des moyens de connexion à la plateforme 1 et permettant de transmettre aux animaux des informations représentant des consignes, ou de recevoir de ces animaux informations relatives à leur comportement par exemple. Les humains 10 peuvent s'exprimer en langage naturel en parlant dans un microphone avec transcription automatique en texte 8, ou par texte saisi au moyen d'un clavier classique 10 ou d'un clavier en Braille 12 reliés à un dispositif de communication. Ils peuvent également s'exprimer au moyen d'un transcripteur de langage de signes 14 ou par détection d'activité cérébrale 16. Les objets connectés peuvent être de différentes natures, tels que par 15 exemple des robots industriels, des robots de service, des capteurs miniaturisés associés à des habits 17 tels que par exemple des combinaisons à usage professionnel, des capteurs et actionneurs localisés dans des locaux d'habitation 34, des véhicules 36, des usines et bureaux 31, dans le domaine public 32, etc. Les sources et les destinataires peuvent en outre être des services numériques fournis par des serveurs distants 30. 20 Dans la suite de la description, le terme « langage naturel » désignera un langage naturellement utilisé par les êtres humains tel que l'anglais, le français, le chinois mandarin, etc., et « langage naturel cible » désignera un langage naturel sélectionné parmi plusieurs langages naturels en fonction de sa zone d'utilisation, de son étendue d'utilisation ou encore de la facilité de son apprentissage automatique. Il peut être modifié par 25 configuration, élection ou tout autre moyen pour tenir compte des spécificités des sources et des destinataires et de l'application envisagée. On désignera par langage construit un langage formel comportant un ensemble de symboles qui servent à en construire les différentes structures. Il est défini par une grammaire formelle, telle que les grammaires algébriques et les langages 30 informatiques, et est susceptible d'être analysé par des automates. Un exemple type de 3050843 11 langage construit sont les interfaces de programmation applicative (APIs - Application Programming Interface) constituées d'un ensemble de classes, de fonctions, de paramètres, de conventions de codage, etc. par lesquelles les objets connectés et les services numériques offrent des services à d'autres applications logicielles. 5 La figure 2 représente une architecture en couches de la plateforme 1 selon l'invention. Cette architecture comporte une première couche de contrôle 40 qui regroupe des unités qui assurent les fonctions classiques de contrôle d'accès à la plateforme 1, en particulier, les fonctions centralisées d'authentification et d'autorisation d'accès pour les utilisateurs de toute nature, de comptage pour des raisons de statistiques, 10 de facturation, d'annuaires, et de sécurité, et une deuxième couche regroupant des unités de gestion 42 qui assurent les fonctions centralisées de supervision des communications, de sélection d'un langage naturel cible, de mises à jour des logiciels de traitement des données échangées via la plateforme 1, de calculs statistiques, de gestion de la disponibilité et des améliorations. Les unités de contrôle 40 et de gestion 42 sont par exemple des 15 applications logicielles téléchargées à partir de serveurs locaux ou distants contrôlés par le gestionnaire de la plateforme 1. Les fonctions décrites ci-dessus peuvent résider au sein de la couche de contrôle 40 ou à l'extérieur de cette couche et être interfacées avec elle. La couche de contrôle 40 assure également la fonction de traitement des exceptions en cas d'échec 20 d'une procédure de résolution d'ambiguïtés constatées au cours des échanges d'informations via la plateforme 1 ou en cas d'échec d'une transaction, par exemple, en cas de refus répétés par un objet connecté de fournir une information ou d'exécuter une commande. L'architecture de la figure 2 comprend une unité bidirectionnelle 25 d'échange en langage naturel 50 connectée aux dispositifs de communication associés à chaque source et à chaque destinataire enregistrés sur la plateforme 1, et un ensemble d'unités de traitement comprenant une unité logicielle et/ou matérielle d'adaptation de média et de protocole 52, une unité logicielle et/ou matérielle de conversion de langage 54, une unité logicielle et/ou matérielle de contrôle et de résolution d'ambiguïté et de 30 pertinence 56, une unité logicielle et/ou matérielle bidirectionnelle 58 de conversion d'un 3050843 12 langage naturel utilisé par une source ou par un destinataire en un langage naturel cible sélectionné, et d'alignement des unités de valeurs physiques et des unités de temps contenus dans les informations échangées, et une interface bidirectionnelle 60 qui réalise l'adaptation entre l'unité bidirectionnelle d'échange en langage naturel 50 et chaque unité 5 bidirectionnelle 58 de conversion d'un langage naturel. Les unités logicielle et/ou matérielle d'adaptation de média et de protocole 52-60, peuvent être implémentées de façon répartie sur les terminaux de communication et de traitement de données (serveurs, ordinateurs, tablettes, Smartphones, boîtiers, ...) utilisés par chaque source et par chaque destinataire connecté à 10 la plateforme 1, ou encore implémentées au sein d'une ou plusieurs plateformes locales ou centralisées, ou encore partiellement implémentées sur les terminaux, des plateformes locales et des plateformes centralisées. Pour des raisons de clarté, dans la suite de la description, des références identiques désigneront les éléments qui assurent des fonctions identiques dans les 15 différentes implémentations et applications de l'invention. Les différentes unités de l'architecture de la figure 2 seront désignées par les acronymes suivants : - CTRL (Control layer, en anglais), pour la couche de contrôle 40, - MNGT (Management module, en anglais) pour la couche regroupant des unités de 20 gestion 42 qui assurent les fonctions centralisées de supervision des communications, de sélection d'un langage naturel cible commun aux humains, aux objets connectés et aux services numériques, de mises à jour des logiciels de traitement des données échangées via la plateforme 1, de calculs statistiques, de gestion de la disponibilité et des améliorations...), 25 - NLXS 50 (Natural Langage eXchange Services, en anglais) pour les unités bidirectionnelles d'échange en langage naturel, - MPA-x 52 (Media and Protocol Adaptor, en anglais) pour les unités d'adaptation de média et de protocole, x indiquant le type de source ou de destinataire auquel est associée l'unité MPA, x = H pour les humains, x = O pour les Objet connectés, et x = 30 S pour les services numériques), 3050843 13 - NLAC 54 (Natural Langage to API Converter, en anglais) pour les unités de conversion de langage, - LARC 56 (Langage Ambiguity and Relevance Controller en anglais) pour les unités logicielles et/ou matérielles de contrôle et de résolution d'ambiguïté et de 5 pertinence des informations échangées, - LUTA 58 (Langage, Units and Time Alignment, en anglais) pour les unités, logicielles et/ou matérielles, bidirectionnelles de conversion d'un langage naturel utilisé par une source ou par un destinataire dans le langage naturel cible sélectionné 10 - IF _NLX 60 (Interface with the Natural Language eXchange services, en anglais), pour les interfaces bidirectionnelles. Comme cela est illustré par la figure 3, les différentes unités de la plateforme de la figure 1 peuvent accéder à des ressources fournies par des serveurs distants tels que par exemple une base linguistique 70, un service de traduction 72 ou un 15 service d'annuaire 74. Les différentes unités se connectent automatiquement en cas de besoin à ces serveurs distants 70, 72 74 via une unité de description 76 de l'objet connecté ou du service numérique pour obtenir : - des éléments de description de l'objet connecté ou du service numérique dont elles ont la charge : identité, description, capacités, paramètres, unités, syntaxe, API, etc. 20 - des ressources extérieures de type "base linguistique" telles que services de traduction, bases d'ontologies et listes de synonymes, hyponymes, hyperonymes, corpus de langage naturel et bases de données diverses pour accomplir ou parfaire leurs fonctions respectives, - d'autres services, par exemple des services d'annuaire, de traduction en ligne et des 25 bases de données diverses peuvent également être utilisés. La figure 4 représente schématiquement la répartition des unités composant l'architecture de la plateforme 1 du côté d'une source 2, un être humain, muni d'un premier ensemble terminal de communication et de traitement de données 82 (un ordinateur, une tablette ou un Smartphone par exemple) et du côté d'un destinataire 6, 3050843 14 une station météo par exemple, équipée de fonctions de communication et de traitement de données et complétée par des fonctions hébergées par une plateforme centrale 85. L'ensemble terminal de communication et de traitement de données pour l'utilisateur humain 2 comporte une interface de type clavier, écran, microphone, 5 écouteur, caméra, etc. vers l'utilisateur, une unité MPA 52 d'adaptation de média et de protocole, une interface IF_NLX 60 pour communiquer en langage naturel via le module NLXS 50 et un émetteur/récepteur vers le réseau de transit 84. L'ensemble de communication et de traitement de données pour l'objet connecté comporte les dispositifs nécessaires pour échanger et traiter les messages en 10 langage construit sur le réseau de rattachement. La plateforme centrale 85 comporte un émetteur/récepteur 83 vers le réseau de rattachement de l'objet connecté, une unité MPA 52 d'adaptation de média et de protocole, une unité NLAC 54 de conversion de langage, une unité LARC 56 de contrôle et de résolution d'ambiguïté et de pertinence des informations échangées, une unité LUTA 15 58 de conversion d'un langage naturel utilisé par la source en langage naturel cible, une interface IF_NLX 60 pour communiquer en langage naturel via le module NLXS 50 et un émetteur/récepteur vers le réseau de transit 84. La figure 5 représente schématiquement la répartition des unités composant l'architecture de la plateforme 1 du côté d'une source 2, une chaudière 20 connectée équipée de fonctions de communication et de traitement de données et complétée par des fonctions hébergées par une plateforme centrale 85, et du côté d'un destinataire 6, une station météo par exemple, équipée de fonctions de communication et de traitement de données et complétée par des fonctions hébergées par une plateforme centrale 85. 25 Les fonctions de communication et de traitement de données comportent les dispositifs nécessaires pour échanger et traiter les messages en langage construit sur le réseau de rattachement. En fonctionnement, les unités bidirectionnelles d'échange en langage naturel NLXS 50 assurent les échanges des informations en langage naturel entre les 30 différents interlocuteurs humains, robots, objets ou plateformes de services numériques. 3050843 15 Ces unités comportent des moyens de communication connus, tels que des services de SMS (Short Message Service) ou MMS (Multimedia Message Service), des services de courriels, des services de messagerie instantanée ou toute autre application adaptée pour échanger des informations en langage naturel. 5 Les unités d'adaptation de média et de protocole MPA-x 52 tels que par exemple, un adaptateur radio LPWAN (low power wide area network) avec ses protocoles de transport (COAP, MQTT...), une interface wifi ou une interface Ethernet avec ses drivers logiciels et ses protocoles de transport (HTTP, TLS, ...) font le lien entre les utilisateurs (humains, objets ou services) connectés à la plateforme 1 et les unités NLAC 54. Dans le cas 10 d'utilisateurs humains, ces unités MPA-H 52 prennent en charge des échanges écrits (textes), vocaux ou de tout autre type selon la nature de l'interaction (par exemple le langage des signes). Dans le cas des objets communicants et des services numériques, les unités MPA-O 52 implémentent le protocole de commande numérique des objets (API, pour Application Programming Interface) et l'adaptation éventuelle au média avec lequel 15 les objets sont connectés. Ces MPA-O 52 sont par exemple des fonctions logicielles qui implémentent en général le côté 'client' de l'interface avec l'objet connecté, celui-ci étant considéré comme un serveur (de données) dans une architecture client/serveur par exemple de type REST (representational state transfer). Les unités de conversion de langage NLAC 54 assurent la transformation 20 entre, d'un côté, les informations en langage naturel cible, et de l'autre côté, les informations au format numérique de pilotage des objets connectés ou au format des données échangées avec des services numériques. Des informations complémentaires telles que images, sons, fichiers, indicateurs d'émotions ou de prosodie par exemple, peuvent optionnellement être adjoints aux informations en langage naturel. 25 Les unités de contrôle et de résolution d'ambiguïté et de pertinence des informations échangées LARC 56 sont installées dans les récepteurs des sources 2 et des destinataires 6 et sont configurées pour analyser les informations reçues depuis les unités bidirectionnelles LUTA 58 d'une part et depuis unités de conversion de langage NLAC 54 afin de déterminer le niveau d'ambiguïté des messages échangés en langage naturel cible 30 et de s'assurer que les unités NLAC 54 seront capables d'effectuer correctement la 3050843 16 conversion de langage souhaitée. Dans le cas où les unités LARC 56 jugent que le niveau d'ambiguïté ou d'incohérence est trop élevé, elles effectuent une procédure de résolution d'ambiguïté, par exemple en demandant à la source du message de répéter la requête ou encore en lui demandant de la reformuler différemment. En cas d'échecs répétés de cette 5 procédure, les unités LARC 56 signalent l'abandon de l'échange à la source des informations ainsi qu'aux unités de contrôle 40 et aux unités de gestion 42. Les unités bidirectionnelles LUTA 58 de conversion d'un langage naturel utilisé par une source ou par un destinataire 6 en un langage naturel cible sélectionné sont configurées pour convertir, lorsque cela est nécessaire, le langage des messages de 10 manière à utiliser le langage naturel de l'utilisateur humain ou un langage naturel cible sélectionné pour communiquer avec des objets et des services numériques. Ces unités bidirectionnelles LUTA 58 effectuent également la conversion des unités (par exemple degré Celsius/degré Fahrenheit ou encore centimètres/pouces, etc.), des dates et de l'heure (en particulier les fuseaux horaires et le changement de jour). 15 Les interfaces bidirectionnelles IF_NLX 60 réalisent l'adaptation entre les unités NLXS 50 et les unités LUTA 58. En particulier, ils choisissent le média le plus adapté parmi les unités NLXS 50 lorsqu'il y en a plusieurs (par exemple un service SMS plutôt qu'un service courriel) et assurent l'émission et la réception des messages numériques vers et depuis ces différents média. Les interfaces IF_NLX 60 sont par exemple des fonctions 20 standard telles que client courriel (google©, outlook©, yahoo©...), client chat de microsoft skype©, google hangout©, client sms/mms, etc. Les unités NLAC 54, LARC 56 et LUTA 58 peuvent optionnellement se connecter automatiquement aux serveurs distants 70-74 pour obtenir, en temps réel ou en différé, des ressources extérieures telles que des services de traduction, des bases 25 d'ontologies et des listes de synonymes, hyponymes, hyperonymes, corpus de langage naturel et des bases de données diverses. La figure 6 décrit en détail les traitements successifs de la requête de la figure 5 par les différentes unités de l'architecture de la plateforme 1. A l'étape 200, la requête formulée par la source 2 est interceptée par 30 l'unité MPA-H d'adaptation de média et de protocole 52 affectée à la source 2. 3050843 17 Dans l'exemple de la figure 6, le langage de la requête interceptée est un langage naturel humain. Dans ce cas, à l'étape 200, l'unité MPA-H 52 transmet la requête interceptée « Quelle température fait-il maintenant ? » à l'interfaces bidirectionnelles IFNLX 60 sans modifications. 5 A l'étape 202, l'interface bidirectionnelle IF-NLX 60 transmet la requête à l'unité bidirectionnelle d'échange en langage naturel NLXS 50. La transmission est réalisée par exemple au moyen d'un service de courriel vers l'adresse courriel my_weatherstation@messagerie.com, « messagerie » étant le nom du service de messagerie électronique utilisé par la station météorologique. 10 Notons que l'unité NLXS 50 peut également utiliser un service SMS, un service de messagerie instantanée ou toute autre application qui permet d'échanger des informations numériques en langage naturel et en temps réel ou en temps très peu différé. Dans l'exemple de la figure 6, l'unité NLXS 50 est un service courriel public auprès duquel la station météo 6 est préalablement enregistrée avec l'adresse courriel 15 my weatherstation@messagerie.com. L'unité NLXS 50 reçoit la requête de l'interface bidirectionnelle IF-NLX 60 sur le client courriel my weatherstation@messagerie.com et transmet ladite requête à l'interface bidirectionnelle IF-NLX 60 implémentée du côté de la station météo 6 à l'étape 204. 20 A l'étape 206, l'interface bidirectionnelle IF-NLX 60 implémentée du côté de la station météo 6 reçoit la requête sur le client courriel my weatherstation@messagerie.com et transmet ladite requête à l'unité bidirectionnelle LUTA 58 implémentée du côté de la station météo 6. A l'étape 208, à l'unité bidirectionnelle LUTA 58 reçoit la requête « Quelle 25 température fait-il aujourd'hui ? » et effectue la conversion du langage naturel utilisé, le français dans ce cas, au langage naturel cible sélectionné, qui est par exemple l'anglais dans ce cas, puis transmet la requête convertie en anglais (par exemple « how warm is it today ? ») à l'unité de contrôle LARC 56 implémentée du côté de la station météo 6. A l'étape 210, ladite unité de contrôle LARC 56 reçoit la requête, l'analyse 30 et, en cas d'ambiguïté, exécute une procédure de résolution d'ambiguïté et de pertinence 3050843 18 des informations échangées. En cas de non ambiguïté, l'unité de contrôle LARC 56 transmet la requête en langage naturel cible, l'anglais, à l'unité de conversion de langage NLAC 54 installée du côté de la station météo 6. A l'étape 212, l'unité NLAC 54 convertit la requête en langage naturel 5 cible « How warm is it today ? » en langage construit en utilisant la commande « getmeasure » de l'API associée à la station météo 6: httplimy_weatherstation.com/api/getmeasure,access_token-[TOKEffldevice_id [DEVICEIffltype-Temperature. ». L'unité NLAC 54 transmet ensuite la commande de mesure de température à l'unité MPA-O d'adaptation de média et de protocole 52 10 implémentée côté station météo 6. A l'étape 214, ladite unité MPA-O 52 d'adaptation de média et de protocole transmet la requête à la station météo 6 sur le media et le protocole utilisé pour joindre la station météo 6. La figure 7 illustre la réponse de la station météo 6 à la requête de la 15 source 2. A la réception de la commande de mesure de température, la station météo 6 effectue la mesure demandée et génère le message ("status" :"ok", "body" :11"beg_time" :123456500, "value" : [69.8]]]], puis transmet ce message, à l'étape 300, à l'unité MPA-O 50. 20 A l'étape 302, l'unité MPA-O 50 reçoit le message de la station météo 6 effectue une adaptation au média (radio, Ethernet, etc.) et aux protocoles de transport (http, tls, mqtt, coap...) et le transmet à l'unité NLAC 54 installée du côté de la station météo 6. A l'étape 304, ladite unité NLAC 54 reçoit le message en langage construit transmis par l'unité MPA-O 50, le convertit automatiquement en langage naturel cible, 25 l'anglais dans cet exemple, « the current temperature is 69.8°F », et transmet le message en langage naturel cible à l'unité de contrôle LARC 56 installée du côté de la station météo 6. A l'étape 306, l'unité de contrôle LARC 56 reçoit le message en langage naturel cible «the current temperature is 69.8°F», et le transmet sans traitement à l'unité 30 bidirectionnelle LUTA 58 installée du côté de la station météo 6. 3050843 19 A l'étape 308 l'unité bidirectionnelle LUTA 58 reçoit le message en langage naturel cible «the current temperature is 69.8°F» et effectue la conversion du langage naturel cible en langage naturel de la source 2, le français dans ce cas, puis effectue une conversion de l'unité de mesure de degrés Fahrenheit en degrés Celsius pour obtenir 5 le message en langage naturel utilisateur « la température est 21 degrés Celsius », et transmet ensuite ce message à l'interface bidirectionnelle IF-NLX 60 coopérant avec la station météo 6. A l'étape 310, l'interface bidirectionnelle IF-NLX 60 envoie le message en langage naturel utilisateur vers le client dont l'adresse courriel est alice@aliceaddress.com. 10 A l'étape 312, l'unité NLXS 50 reçoit le message de l'interface bidirectionnelle IF-NLX 60 et le retransmet vers le client courriel à l'adresse source@sourceaddress.com, A l'étape 314, l'interface bidirectionnelle IF-NLX 60 en charge de la source 2 transmet le contenu du message en langage naturel utilisateur « la température est 21 15 degrés Celsius » à l'unité MPA-H d'adaptation de média et de protocole 52 installée dans le terminal de la source 2. A l'étape 316, l'unité MPA-H 52 délivre le message en langage naturel utilisateur « la température est 21 degrés Celsius » à la source 2, soit par un message vocal, soit par un affichage sur l'écran du terminal de la source 2. 20 La figure 8 représente les étapes des traitements appliqués à une requête envoyée par une chaudière connectée à la station météo. La chaudière peut par exemple être programmée pour requérir des informations à la station météo 6 à intervalles réguliers afin d'effectuer un réglage automatique de ses paramètres de fonctionnement en adaptant sa puissance à la température mesurée. 25 La chaudière et la station météo échangent les messages au moyen de leurs ensembles de communication et de traitement de données respectifs 85 représentés à la figure 5. A l'étape 402, la chaudière 400 transmet à l'unité d'adaptation de média et de protocole MPA-O 52 une requête dans le langage construit et en utilisant le média et les protocoles qu'elle implémente : « GET : http://xxxx/api/gettemperature? ». 3050843 20 A l'étape 404, l'unité MPA-O 52 transmet la requête dans le langage construit de la chaudière à l'unité de conversion de langage NLAC 54 en charge de la chaudière et qui la convertit automatiquement, à l'étape 406, en un message en langage naturel cible préalablement sélectionné, l'anglais par exemple : « what is the temperature 5 now ? », puis transmet la requête en langage naturel cible à l'unité LARC 56 de contrôle et de résolution d'ambiguïté et de pertinence. A l'étape 408, l'unité LARC 56 transmet le message en langage naturel cible « what is the temperature now ?» sans modification à l'unité LUTA 58 de conversion de langage naturel en charge de la chaudière 400. 10 A l'étape 410, l'unité LUTA 58 transmet le message en langage naturel cible « what is the temperature now ?» sans modification à l'interfaces bidirectionnelle IFNLX 60 en charge de la chaudière 400. A l'étape 412, l'interface bidirectionnelle IF-NLX 60 transmet le message en langage naturel cible à l'unité NLXS 50 pour être remis au client courriel d'adresse 15 my weatherstation@messagerie.com, « messagerie » étant le nom du service de messagerie utilisée par la station météo. A l'étape 414, l'unité NLXS 50 d'échange en langage naturel reçoit le message en langage naturel cible et le transmet à l'interface bidirectionnelle IF-NLX 60 en charge de la station météo 6. 20 L'interface bidirectionnelle IF-NLX 60 reçoit le message sur le client courriel my weatherstation@messagerie.com et le transmet, à l'étape 416, à l'unité LUTA 58 installée côté station météo 60. A l'étape 418, l'unité LUTA 58 transmet le message en langage naturel cible « what is the temperature now ?» sans modification à l'unité LARC 56 en charge de la 25 station météo 6. A l'étape 420, ladite unité LARC 56 effectue une analyse d'ambiguïté du message reçu en langage naturel cible. Si l'unité LARC 56 juge que le message reçu n'est pas ambigu et est cohérent avec le rôle et les capacités de l'objet dont elle est chargée, elle le transmet sans 30 modification à l'unité NLAC 54 de la station météo 6. 3050843 21 A l'étape 422, l'unité NLAC 54 de la station météo 6 effectue une conversion du message reçu en langage naturel cible « what is the temperature now ?» vers le langage construit de la station météo, en l'occurrence une commande « getmeasure » : G ET: http://my weatherstation.com/api/getmeasure,access_token- 5 ITOKEALl&device id-IDEVICEID]&type-Temperature » et transmet le message obtenu à l'unité d'adaptation de média et de protocole MPA-O 52 en charge de la station météo 6. A l'étape 424, l'unité MPA-O 52 transfère la commande en langage construit à la station météo 6 en utilisant les protocoles et le média utilisés par la station météo 6. 10 A la réception de cette commande, la station météo 6 génère une réponse à la requête. La figure 9 représente les étapes des traitements appliqués à la réponse à envoyer par la station météo 6 à la chaudière. A l'étape 500, la station météo envoie la température mesurée par la 15 réponse à la commande « getmeasure », exprimée en langage construit de l'API qui lui est associée, à son unité MPA-O 52, en utilisant les protocoles et le média utilisés par la station météo 6. A l'étape 502, l'unité MPA-O 52 transmet le message reçu en langage construit de la station météo à l'unité de conversion de langage NLAC 54 en charge de la 20 station météo 6. A l'étape 504, l'unité NLAC 54 convertit automatiquement le message en langage construit en un texte en anglais qui est le langage naturel cible préalablement sélectionné : « the current temperature is 69.8°F », et transmet la réponse, en anglais, à l'unité LARC 56 en charge de la station météo 6. 25 A l'étape 506, l'unité LARC 56 en charge de la station météo 6 transmet le message en langage naturel cible « the current temperature is 69.8°F » sans modification à l'unité LUTA 58. A l'étape 508, l'unité bidirectionnelle LUTA 58 reçoit le message en langage naturel cible «the current temperature is 69.8°F», conserve le message en anglais 30 puisque c'est la langue naturelle utilisée par la chaudière, puis effectue, si cela est 3050843 22 nécessaire, une conversion de l'unité de mesure de degrés Fahrenheit en degrés Celsius pour obtenir le message en langage naturel cible « the current temperature is 21°C », et transmet ensuite ce message à l'interface bidirectionnelle IF-NLX 60 en charge de la station météo 6. 5 A l'étape 510, l'interface bidirectionnelle IF-NLX 60 de la station météo 6 transmet ce message en langage naturel cible à l'unité NLXS 50 d'échange en langage naturel pour remise à l'adresse courriel heather@heatheraddress.com (adresse courriel attribuée à la chaudière) A l'étape 512, l'unité NLXS 50 reçoit le message en langage naturel cible 10 et le retransmet à l'interface bidirectionnelle IF-NLX 60 en charge de la chaudière. Celle-ci le transmet, à l'étape 514, à l'unité LUTA 58 en charge de la chaudière. A l'étape 516, l'unité LUTA 58 transmet le message en langage naturel cible « the current temperature is 21°C » sans modification à l'unité LARC 56. A l'étape 518, ladite unité LARC 56 effectue une analyse d'ambiguïté du 15 message reçu. Si l'unité LARC 56 juge que le message reçu en langage naturel cible n'est pas ambigu et est cohérent, elle le transmet sans modification à l'unité NLAC 54 en charge de la chaudière. A l'étape 520, l'unité NLAC 54 en charge de la chaudière 400 convertit la 20 réponse en langage naturel cible « the current temperature is 21°C » vers le langage construit de la chaudière, en l'occurrence la réponse à la commande 'gettemperature' : ("status" :"ok", "body" :11 "beg_time ":123456500, "value" : 121.00, et transmet la réponse convertie à l'unité d'adaptation de média et de protocole MPA-0 52 en charge de la chaudière. 25 A l'étape 522, l'unité MPA-O 52 transmet ce message à la chaudière en utilisant les protocoles et le média utilisés par la chaudière 400. La figure 10A illustre les étapes essentielles des traitements appliqués par l'unité LUTA 58 à un message transmis en langage naturel par une source distante à un destinataire via l'unité IF-NLX 60 en charge de la source. 3050843 23 A l'étape 598, le message de la source distante est transmis en langage naturel à l'unité LUTA 58 via l'unité IF-NLX 60. A l'étape 600 l'unité LUTA 58 convertit le langage naturel de la source distante au langage naturel cible sélectionné. 5 A l'étape 602 l'unité LUTA 58 aligne les unités utilisées par la source distante sur celles utilisées par le destinataire. A l'étape 604 l'unité LUTA 58 aligne les références de date, d'heure et de durée utilisées par la source distante sur celles utilisées par le destinataire. A l'étape 606, l'unité LUTA 58 transmet le message traité par les étapes 10 598-604 vers l'unité LARC 56 du destinataire. La figure 10E3 illustre les étapes essentielles des traitements appliqués par l'unité LUTA 58 au message en langage naturel cible transmis par une source locale vers un destinataire. A l'étape 610 le message en langage naturel cible est transmis à l'unité 15 LUTA 58 via l'unité LARC 56 en charge de l'objet connecté local. A l'étape 612, l'unité LUTA 58 aligne les références de date, d'heure et de durée utilisées dans le message sur celles utilisées par le correspondant distant. A l'étape 614, l'unité LUTA 58 aligne les unités utilisées dans le message sur celles utilisées par le correspondant distant. 20 A l'étape 616, l'unité LUTA 58 convertit le message en langage naturel cible au langage naturel utilisé par le correspondant distant. A l'étape 620 l'unité LUTA 58 transmet le message en langage naturel utilisé par le correspondant distant vers l'unité IF-NLX 60. La figure 11 est un organigramme détaillé de l'étape 600 de conversion 25 du langage naturel de la source distante au langage naturel cible sélectionné. A la réception du message en langage naturel transmis par la source distante, à l'étape 700, l'unité LUTA 58 du destinataire examine le texte du message pour déterminer le langage naturel de la source distante. 3050843 24 Si le langage naturel de la source distante est reconnu, à l'étape 702, l'unité LUTA 58 du destinataire vérifie si le langage reconnu est le même que le langage naturel cible sélectionné préalablement. Si le langage naturel de la source distante est le même que le langage 5 naturel cible sélectionné, le traitement de la figure 10A se poursuit à partir de l'étape 602. Sinon, à l'étape 704, l'unité LUTA 58 en charge du destinataire 6 vérifie s'il est possible de convertir localement, automatiquement, le message en langage naturel de la source distante au langage naturel cible. Si une telle conversion automatique est possible localement, à l'étape 10 706, l'unité LUTA 58 en charge du destinataire effectue la conversion. Le traitement de la figure 10A se poursuit alors à partir de l'étape 602. Sinon, à l'étape 708, l'unité LUTA 58 du destinataire vérifie si la conversion peut être déléguée à un serveur de traduction distant. Si une conversion automatique du langage naturel de la source distante 15 vers le langage naturel cible peut être déléguée à un serveur de traduction distant, à l'étape 710, le serveur de traduction distant effectue la conversion. Le traitement de la figure 10A se poursuit alors à partir de l'étape 602 Sinon, à l'étape 712, l'unité LUTA 58 en charge du destinataire 6 génère un message d'échec et transmet ce message à la source distante, à l'unité de contrôle 40, 20 et à l'unité de gestion 42. Si à l'issue du test de l'étape 700 le langage naturel de la source distante n'est pas reconnu par l'unité LUTA 58 en charge du destinataire, à l'étape 714, l'unité LUTA 58 vérifie si le langage naturel de la source distante est indiqué dans le dossier d'inscription de celle-ci sur la plateforme 1. 25 Si oui, la procédure d'alignement du langage naturel de la source distante sur le langage naturel cible sélectionné se poursuit à partir de l'étape 702. Sinon, à l'étape 716, l'unité LUTA 58 en charge du destinataire 6 vérifie si le langage naturel de la source distante est indiqué dans un annuaire extérieur. Si oui, la procédure d'alignement du langage naturel de la source distante 30 sur le langage naturel cible sélectionné se poursuit à partir de l'étape 702. 3050843 25 Sinon, à l'étape 718, l'unité LUTA 58 en charge du destinataire 6 vérifie si le langage naturel de la source distante 2 a pu être appris par examen des messages précédents. Si oui, la procédure d'alignement du langage naturel de la source distante 5 sur le langage naturel cible sélectionné se poursuit à partir de l'étape 702. Sinon, à l'étape 712, l'unité LUTA 58 en charge du destinataire génère un message d'échec et transmet ce message à la source distante, à l'unité de contrôle 40, et à l'unité de gestion 42. La figure 12 est un organigramme détaillé de l'étape 602 de la figure 10 10 d'alignement des unités utilisées par la source distante sur celles utilisées par le destinataire. A l'étape 720, l'unité LUTA 58 en charge du destinataire vérifie si les unités de longueur, de surface et de volume présentes dans le message reçu de l'utilisateur distant sont identiques aux unités utilisées par l'utilisateur local destinataire du message. 15 Sinon, A l'étape 722, l'unité LUTA 58 en charge du destinataire transforme les unités de longueur, de surface et de volume du message reçu en unités de longueur utilisées par l'utilisateur local destinataire du message. Si oui, A l'étape 724, l'unité LUTA 58 en charge du destinataire vérifie si les unités de masse et de poids sont identiques aux unités utilisées par l'utilisateur local 20 destinataire du message. Si les unités de masse et de poids ne sont pas alignées, à l'étape 726, l'unité LUTA 58 en charge du destinataire transforme les unités de masse et de poids du message reçu en unités utilisées par l'utilisateur local destinataire du message. Si les unités de masse et de poids sont alignées, à l'étape 728, l'unité LUTA 25 58 en charge du destinataire vérifie si les unités de température sont identiques aux unités utilisées par l'utilisateur local récepteur du message. Si les unités de température ne sont pas alignées avec celles de l'utilisateur local récepteur du message, à l'étape 730, l'unité LUTA 58 en charge du destinataire transforme les unités de température du message reçu en unités de 30 température utilisées par l'utilisateur local récepteur du message. 3050843 26 Si les unités de température sont alignées, à l'étape 732, l'unité LUTA 58 en charge du destinataire vérifie si les unités de date, d'heure et de durée sont identiques aux unités utilisées par l'utilisateur local récepteur du message. Si les unités de date, d'heure et de durée ne sont pas alignées, à l'étape 5 734, l'unité LUTA 58 en charge du destinataire transforme les unités de date, d'heure et de durée en unités utilisées par l'utilisateur local récepteur du message. Si les unités de date, d'heure et de durée sont alignées, à l'étape 736, la procédure d'alignement du langage naturel de la source distante sur le langage naturel cible sélectionné se poursuit à partir de l'étape 604 de la figure 10A. 10 La figure 13 est un organigramme détaillé de l'étape 604 d'alignement des références de date, d'heure et de durée utilisées par la source distante sur celles utilisées par un objet connecté ou un service numérique. A l'étape 740, l'unité LUTA 58 en charge du destinataire 6 vérifie si les références de date utilisées par l'objet connecté ou le service numérique fournissant le 15 message sont identiques aux références utilisées par l'utilisateur local récepteur du message. Sinon, A l'étape 742, l'unité LUTA 58 en charge du destinataire transforme les références de date reçues en références de date utilisées par l'utilisateur local récepteur du message. 20 A l'étape 744, l'unité LUTA 58 en charge du destinataire vérifie si les références d'heure utilisées par l'objet connecté ou le service numérique sont alignées avec celle de l'utilisateur local récepteur du message. Sinon, à l'étape 746, l'unité LUTA 58 en charge du destinataire transforme les références d'heures reçues en références d'heures utilisées par l'utilisateur local 25 récepteur du message. Si oui, à l'étape 748, l'unité LUTA 58 en charge du destinataire vérifie si les références de durée sont identiques aux références utilisées par l'utilisateur local récepteur du message. 3050843 27 Sinon, à l'étape 750, l'unité LUTA 58 en charge du destinataire transforme les références de durée du message reçu en références de durée utilisée par l'utilisateur local récepteur du message. A l'étape 752, l'unité LUTA 58 en charge du destinataire transmet le 5 message à l'unité LARC 56 installée dans le récepteur du destinataire du message pour analyser l'ambiguïté des informations reçues. La figure 14 est un organigramme détaillé de l'étape 612 d'alignement des références de date, d'heure et de durée utilisées par une source locale émettrice d'un message en langage naturel cible sur celles utilisées par le destinataire. 10 A l'étape 760, l'unité LUTA 58 en charge de la source vérifie si les références de dates utilisées par l'utilisateur destinataire du message reçu sont identiques aux références utilisées par la source locale. Sinon, à l'étape 762, l'unité LUTA 58 en charge de la source transforme les références de date du message en références de date utilisées par le destinataire. 15 Si oui, à l'étape 764, l'unité LUTA 58 en charge de la source vérifie si les références d'heures sont identiques aux références d'heures utilisées par la source distante. Sinon, à l'étape 766, l'unité LUTA 58 en charge de la source transforme les références d'heures du message en références d'heures utilisées par le destinataire. 20 Si oui, à l'étape 768, l'unité LUTA 58 en charge de la source vérifie si les références de durée du message sont identiques aux références de durée utilisée par le destinataire. Sinon, à l'étape 770, l'unité LUTA 58 en charge de la source transforme les références de durée du message en références de durée utilisée par le destinataire. 25 Si oui, à l'étape 772, l'unité LUTA 58 en charge de la source transmet le message en langage naturel cible issu du destinataire vers la fonction permettant d'effectuer l'alignement vers les unités préférées du destinataire. La figure 15 est un organigramme détaillé de l'étape 614 d'alignement des unités utilisées par une source locale, émetteur d'un message en langage naturel cible, 30 sur celles utilisées par le destinataire. 3050843 28 A l'étape 780, l'unité LUTA 58 en charge de la source locale vérifie si les unités de longueur, de surface et de volume sont identiques aux unités utilisées par le destinataire du message. Sinon, à l'étape 782, l'unité LUTA 58 en charge de la source locale 5 transforme les unités de longueur, de surface et de volume du message en unité de longueur utilisé par l'utilisateur destinataire. Si oui, à l'étape 784, l'unité LUTA 58 en charge de la source locale vérifie si les unités de masse et de poids sont identiques aux unités utilisées par l'utilisateur destinataire du message. 10 Sinon, à l'étape 786, l'unité LUTA 58 en charge de la source locale transforme les unités de masse et de poids du message en unités utilisées l'utilisateur destinataire du message. Si oui, à l'étape 788, l'unité LUTA 58 en charge de la source locale vérifie si les unités de température sont identiques à celles utilisées par l'utilisateur destinataire 15 du message. Sinon, à l'étape 790, l'unité LUTA 58 en charge de la source locale transforme les unités de température du message en unités utilisées par le destinataire 6. Si oui, à l'étape 792, l'unité LUTA 58 en charge de la source locale vérifie si les unités de date, d'heure et de durée sont identiques à celles utilisées par l'utilisateur 20 destinataire du message. Sinon, à l'étape 794, l'unité LUTA 58 en charge de la source locale transforme les unités de date, d'heure et de durée du message en unités utilisées par l'utilisateur destinataire du message. Si oui, à l'étape 796, l'unité LUTA 58 en charge de la source locale 25 transmet le message reçu en langage naturel cible vers la fonction permettant d'effectuer l'alignement vers le langage naturel de l'utilisateur distant. La figure 16 est un organigramme détaillé de l'étape 616 d'alignement par une source du langage naturel cible vers le langage naturel de l'utilisateur distant. 3050843 29 A l'étape 800, l'unité LUTA 58 en charge de la source locale vérifie si le langage naturel de l'utilisateur distant est indiqué dans son dossier d'inscription sur la plateforme 1. Si oui, à l'étape 802, l'unité LUTA 58 en charge de la source locale vérifie 5 si le langage naturel de l'utilisateur distant indiqué est identique au langage naturel cible. Sinon, à l'étape 804, l'unité LUTA 58 en charge de la source locale vérifie si une conversion automatique locale en langage de l'utilisateur distant est possible. Si oui, à l'étape 806, l'unité LUTA 58 en charge de la source locale effectue la traduction automatique locale du langage naturel cible vers langage de l'utilisateur 10 distant et transmet, à l'étape 808, le message en langage naturel l'utilisateur distant au module IF-NLX 60 de cet utilisateur distant. Si le langage naturel de l'utilisateur distant n'est pas indiqué dans son dossier d'inscription sur la plateforme 1, à l'étape 814, l'unité LUTA 58 en charge de la source locale vérifie si le langage naturel de cet utilisateur distant est indiqué dans un 15 annuaire extérieur. Si oui, la procédure d'alignement du langage naturel cible vers le langage naturel de l'utilisateur distant se poursuit à partir de l'étape 802. Sinon, l'unité LUTA 58 en charge de la source locale transmet, à l'étape 816, le message en langage naturel cible au module IF-NLX 60 en charge de la source locale 20 pour transmission à l'utilisateur distant. Les messages en un langage naturel cible échangés entre les interfaces bidirectionnelles IF-NLX 60 implémentées respectivement du côté d'une source et du côté d'un destinataire peuvent comporter des ambiguïtés grammaticales ou syntaxiques. Ces messages sont transmis aux unités de contrôle et de résolution d'ambiguïté et de 25 pertinence LARC 56 respectivement depuis les unités bidirectionnelles LUTA 58 et depuis les unités de conversion de langage NLAC 54 installées respectivement du côté des sources et du côté des destinataires afin de déterminer le niveau d'ambiguïté des messages échangés et de s'assurer que les unités NLAC 54 seront capables d'effectuer correctement la conversion de langage souhaitée. 3050843 30 La figure 17 représente une vue détaillée d'une unité de résolution d'ambiguïté et de pertinence LARC 56. Celle-ci comporte un bloc d'émission 820 un bloc de résolution 822 et un bloc de réception 824. Le bloc d'émission 820 comporte un premier multiplexeur 826 destiné à 5 conserver une copie des messages émis par l'utilisateur local et un deuxième multiplexeur 828 destiné à transmettre des messages à l'utilisateur distant à travers le module LUTA 58. Le bloc de résolution 822 comporte un module de résolution d'ambiguïté grammaticale 830, un module de résolution d'incohérence 832, un module de réponse aux messages de résolution 834, et un module d'assistance aux utilisateurs 836. 10 Le bloc de réception 824 comporte un module d'analyse grammaticale de message 840, un module d'interception des messages de résolution des ambiguïtés, des confirmations et des incohérences 842, un module d'interception des messages de demandes d'assistance des utilisateurs 844, et un module d'analyse de cohérence de messages 846. 15 La figure 18 représente un organigramme des étapes de contrôle, par l'unité LARC 56, d'ambiguïté et de pertinence d'un message en langage naturel cible provenant d'un utilisateur distant, et reçu à partir d'une unité bidirectionnelle LUTA 58 en charge du destinataire. A l'étape 850, le module d'analyse grammaticale de message 840 de 20 l'unité LARC 56 en charge du destinataire vérifie si le message reçu est suffisamment conforme à la grammaire (lexique, syntaxe, etc.) du langage naturel cible. Si le message reçu n'est pas suffisamment conforme, à l'étape 852, le module 840 transmet le message au module de résolution d'ambiguïté grammaticale 830 qui élabore un message de demande résolution d'ambiguïté grammaticale en langage 25 naturel cible et le transmet vers l'utilisateur distant à travers l'unité bidirectionnelle LUTA 58 en charge du destinataire. Si le message reçu est suffisamment conforme, à l'étape 854, le module d'interception des messages de résolution des ambiguïtés, des confirmations et des incohérences 842 vérifie si le message reçu est un message de demande résolution des 30 ambiguïtés grammaticales, des confirmations ou des incohérences. 3050843 31 Si oui, à l'étape 856, le module 842 transmet le message au module de réponse aux messages de résolution 834 qui élabore un message de réponse à la demande de résolution d'ambigüité grammaticale en langage naturel cible et le transmet à l'utilisateur distant à travers l'unité LUTA 58. 5 Sinon, à l'étape 858, un module d'interception des messages de demandes d'assistance des utilisateurs 844 vérifie si le message est une demande d'assistance de la part de l'utilisateur distant. Si le message est une demande d'assistance de la part de l'utilisateur distant, à l'étape 860, le module 844 transmet le message au module d'assistance aux 10 utilisateurs 836 qui élabore un message de réponse à la demande d'assistance en langage naturel cible et le transmet à l'utilisateur distant à travers l'unité LUTA 58. Sinon, à l'étape 862, le module d'analyse de cohérence de messages 846 vérifie si le message reçu est cohérent par rapport à la nature et aux capacités de l'utilisateur local, objet ou service connecté. 15 Si le message est suffisamment cohérent, il est transmis à l'unité NLAC 54 de conversion de langage. Sinon, à l'étape 864, le module 846 transmet le message au module de résolution des incohérences 832 qui élabore un message de demande de résolution des confirmations et des incohérences et transmet le message à l'utilisateur distant à travers 20 le module LUTA 58. Les messages en langage naturel échangés entre une source 2 et un destinataire 6 transitent via les unités de conversion de langage NLAC 54 qui sont chargées d'effectuer la transformation entre d'un côté les informations en langage naturel cible vers un langage construit utilisé par un objet connecté ou un service numérique et de l'autre les 25 messages en langage construit (format numérique de pilotage des objets connectés ou format numérique de pilotage des services numériques) en langage naturel cible. Les figures 19 et 20 illustrent les étapes pour effectuer ces transformations respectivement dans le premier cas et dans le deuxième cas. En référence à la figure 19, à la réception d'un message en langage 30 naturel cible transmis à un objet connecté ou à un service numérique par un utilisateur 3050843 32 distant, l'unité NLAC 54 en charge de l'objet connecté ou du service numérique mémorise le message reçu à l'étape 870 pour améliorer l'élaboration de l'éventuelle réponse en langage naturel cible. A l'étape 872, le langage naturel utilisé dans le message mémorisé est 5 converti vers le langage construit de l'objet ou du service connecté. Une vérification de cette conversion est opérée à l'étape 874. Si la conversion est jugée réussie, à l'étape 876, l'unité NLAC 54 transmet le message en langage construit de l'objet ou du service connecté vers le module MPA-O 52 d'adaptation de média et de protocole implémentée en charge de l'objet connecté ou 10 du service numérique. Sinon, à l'étape 878, l'unité NLAC 54 transmet un message d'erreur circonstancié à l'utilisateur distant en langage naturel cible à travers le module LARC 56, et aux unités de contrôle CTRL 40 et de gestion 42. En référence à la figure 20, à la réception d'un message en langage 15 construit transmis par un objet connecté ou un service numérique, à l'étape 880, l'unité NLAC 54 en charge de l'utilisateur distant vérifie si le message reçu est un message d'erreur ou non. Si oui, à l'étape 882, ladite unité NLAC 54 émet un message d'erreur circonstancié à l'utilisateur distant en langage naturel cible à travers l'unité LARC 56, et aux 20 unités de contrôle CTRL 40 et de gestion 42. Sinon, à l'étape 884, l'unité NLAC 54 convertit le message reçu en langage construit vers le langage naturel cible. Une vérification de cette conversion est effectuée à l'étape 886. Si la conversion est jugée réussie, à l'étape 888 le module NLAC 54 25 transmet le message en langage naturel cible vers l'utilisateur destinataire à travers le module LARC 56. Sinon, à l'étape 882, l'unité NLAC 54 transmet un message d'erreur circonstancié en langage naturel cible à l'utilisateur distant à travers le module LARC 56 ainsi qu'aux unités de contrôle CTRL 40 et de gestion 42. 3050843 33 Notons que la résolution des ambigüités est opérée selon une stratégie de qui dépend du niveau de problème. Ainsi, elle peut consister à demander à l'utilisateur distant de : - Répéter le message ; 5 - Reformuler le message ; - Confirmer le message en lui indiquant ce qui a été compris ; - Reformuler le message en lui indiquant quel(s) mot(s) n'est (ne sont) pas compris ; - Reformuler le message en lui recommandant de le simplifier ; - Reformuler le message en lui indiquant qu'il y a un risque d'interprétation multiple ; 10 - Reformuler le message en lui indiquant quel(s) mot(s) ou concept(s) ne s'applique (ent) pas à l'objet communicant ou au service numérique ; - Etc. Pour chacune des stratégies ci-dessus, les unités de contrôle et de résolution d'ambiguïté et de pertinence des informations échangées sont configurées pour 15 utiliser des expressions en langage naturel suffisamment diverses pour ne pas lasser un utilisateur humain. Ces expressions seront également suffisamment simples pour être comprises à la fois par un utilisateur distant de type humain ainsi que par les modules d'interception des messages de résolution des ambiguïtés, des confirmations et des incohérences 842 équipant les unités LARC des objets et services connectés. 20 La stratégie de résolution des ambigüités peut évoluer soit si la précédente stratégie n'a pas apporté de solution satisfaisante soit pour éviter de lasser un utilisateur distant humain Après un nombre donné (éventuellement variable) de tentatives infructueuses, la fonction de résolution des ambigüités pourra déclarer l'abandon de la 25 transaction en le signalant à l'utilisateur distant ainsi qu'aux unités de contrôle CTRL 40 et de gestion 42. Tout ou partie des données (étapes, messages, stratégies, etc.) utilisées et générées par la fonction de résolution des ambigüités sont mémorisées pour être utilisées ultérieurement, en particulier par la fonction de gestion des améliorations de 30 l'unité de gestion 42. 3050843 34 Notons que la réponse aux messages de résolution des ambigüités, des confirmations et des incohérences est activée par la fonction d'interception des messages de résolution d'ambigüité, des confirmations et des incohérences du bloc de réception, par exemple lors de la réception d'une demande de répétition, de confirmation, etc. Elle 5 possède également une copie du message initial qui a été émis depuis le bloc d'émission et dont on cherche à éliminer les ambigüités ou les incohérences. En fonction de la stratégie de résolution choisie par les fonctions de résolution des incohérences, des confirmations ou des ambigüités distantes, la fonction de réponse consistera, par exemple, à : - Répéter le message ; 10 - Reformuler le message ; - Préciser le message en fonction des indications données par la fonction de résolution distance ; - Confirmer simplement le message ; - Confirmer la compréhension qu'à la fonction distante du message ; 15 - Abandonner la transaction ; - Etc. La fonction de réponse aux messages de résolution peut évoluer soit si elle constate que l'attitude précédente n'a pas apporté de solution satisfaisante soit encore pour éviter de lasser un utilisateur distant humain. 20 Après un nombre donné (éventuellement variable) de tentatives infructueuses, la fonction de réponse aux messages de résolution pourra déclarer l'abandon de la transaction en le signalant à l'utilisateur distant ainsi qu'aux unités de contrôle CTRL 40 et de gestion 42. Tout ou partie des données (étapes, messages, attitudes, etc.) utilisées et 25 générées par la fonction de réponse aux messages de résolution sont mémorisées pour être utilisées ultérieurement, en particulier par la fonction de gestion des améliorations de l'unité de gestion 42. 30 3050843 Assistance aux utilisateurs. La fonction d'assistance aux utilisateurs est activée par la fonction d'interception des messages de demande d'assistance du bloc de réception. Ces demandes d'assistance peuvent être de diverses natures, par exemple : 5 - Des informations sur la nature, l'identité et la capacité de l'objet communicant ou du service numérique ; - Des informations sur l'état opérationnel (ON/OFF) ou l'état administratif (activé/désactivé) de l'objet ou du service ; - La liste des actions que l'objet ou le service peut entreprendre ou des informations 10 qu'il peut fournir ; - Des exemples de phrases en langage naturel pour communiquer avec cet objet ou ce service ; - Des conseils pour résoudre les problèmes les plus fréquents ; - La conduite à tenir en cas de situation d'urgence ; 15 - Etc. L'interface d'assistance aux utilisateurs 836 reçoit et traite les demandes d'assistance selon leur nature. Elle y répond en langage naturel en y joignant éventuellement des données complémentaires (fichiers de documentation détaillées, liens Web vers des didacticiels, etc.). 20 La figure 21 illustre schématiquement un échange lié à une demande d'assistance entre deux objets communicants, une chaudière et une station météo. Dans cet exemple, le langage naturel cible sélectionné est l'anglais. Comme illustré par cette figure, les échanges se font entre les blocs de réception 824 équipant les unités LARC 56 respectives de chaque objet connecté. 25 A titre d'exemple, la chaudière envoie à la station météo le message en langage naturel cible « Can you tell me what are your capacities? ». A la réception de ce message via son unité LARC 56, la station météo génère, par exemple, automatiquement le message en langage naturel cible « I'm able to measure the current temperature and humidity » et le renvoie à la chaudière via l'unité 30 LARC 56 de cette dernière. 3050843 36 Notons que tout ou partie des données reçues et générées par les interfaces d'assistance aux utilisateurs 836 sont mémorisées pour être utilisées ultérieurement, en particulier par l'unité de gestion 42. L'invention prend ainsi en considération les contraintes liées à 5 l'environnement de chaque type de communication et exploite le fait que le langage naturel est le plus adapté à véhiculer des informations riches (données pures, données contextuelles, émotions, etc.) au prix d'une certaine ambigüité. Les objets connectés et les services numériques sont configurés pour accepter les variations lexicales et syntaxiques des messages, et pour échanger entre supporter une tolérance à l'ambigüité de façon à 10 simplifier et à élargir leur capacité de communication. L'invention tire ainsi avantage de la relative simplicité des objets communicants et des services numériques pour déplacer la contrainte depuis les humains vers les objets et services au moyen des traitements numériques du langage naturel (NLP - Natural Langage Processing) dans la mesure où ces objets et services communicants 15 effectuent le plus souvent un nombre limité de tâches simples (ou en tout cas suffisamment spécialisées pour être exprimées simplement). Ceci est mis à profit par l'invention pour réaliser des fonctions de compréhension du langage naturel restreintes aux missions dévolues à ces objets et services. On réalise ainsi le déplacement de la contrainte depuis les personnes humaines (qui doivent s'adapter aux langages artificiels 20 des objets et services) vers les objets et services (qui doivent s'adapter au langage naturel des humains). Il est possible d'implémenter l'invention à partir d'un nombre différent de modules, certains d'entre eux pouvant être optionnels ; par ailleurs différents regroupements peuvent être réalisés pour des questions pratiques ou technologiques, 25 sans changer la nature de l'invention. Il peut être également envisagé de modifier l'ordre de certains des modules sans modifier significativement la portée de l'invention. REVENDICATIONS1. Procédé de communication entre une pluralité de sources (2,6) et une pluralité de destinataires (2,6) susceptibles d'échanger des informations, soit en un langage construit, soit en un langage naturel, via une plateforme intelligente (1) comportant une pluralité d'unités distribuées de traitement de l'information comprenant au moins une unité bidirectionnelle d'échange en langage naturel (50), au moins une première unité de conversion de langage (54) et au moins une première unité d'adaptation de média et de protocole (52) associées à chaque source, au moins un deuxième unité de conversion de langage (54) et au moins une deuxième unité d'adaptation de média et de protocole (52) associées à chaque destinataire, procédé caractérisé par les étapes suivantes : - du côté émission, - intercepter par la première unité d'adaptation de média et de protocole (52) les informations envoyées par au moins une source à au moins un destinataire, - déterminer le type de langage décrivant les informations interceptées, et, si le langage décrivant les informations interceptées est un langage construit, - convertir automatiquement lesdites informations reçues en langage construit vers le langage naturel au moyen de la première unité de conversion de langage (54), - transmettre lesdites informations en langage naturel au destinataire via le module bidirectionnel d'échange en langage naturel NLX (50), et, - du côté réception, si le langage du destinataire est un langage construit, - convertir automatiquement les informations reçues en langage naturel vers le langage construit au moyen de la deuxième unité de conversion de langage (54), puis, - fournir les informations en langage construit au destinataire via la deuxième unité d'adaptation de média et de protocole (52), si le langage du destinataire est un langage naturel, fournir les informations en langage naturel au destinataire. 3050843 38 2. Procédé selon la revendication 1 dans lequel lesdites sources et lesdits destinataires sont, soit des humains (2), soit des objets connectés (6), soit des services numériques (30). 5 3. Procédé selon la revendication 2 comportant en outre une étape d'analyse des informations échangées en langage naturel entre les humains (2), les objets connectés (6) et les services numérique (30) reliés via ladite plateforme intelligente (1), et une étape de résolution des ambiguïtés et des incohérences relevées au moyen de ladite étape d'analyse. 10 4. Procédé selon la revendication 3 comportant une étape préalable consistant à choisir un langage naturel cible. 5. Procédé selon l'une des revendications précédentes comportant une 15 procédure d'apprentissage par la plateforme intelligente (1) des modes d'utilisation par les sources (2, 6) et par les destinataires (2,6) des langages naturels cibles et/ou des langages construits de manière à améliorer les performances de conversion et de résolutions d'ambiguïté d'un langage naturel humain et d'un langage construit. 20 6. Procédé selon la revendication 5 dans lequel la procédure d'apprentissage est exécutée automatiquement, en tâche de fond, sans interférer directement avec les étapes de conversion et de résolutions d'ambiguïté. 7. Procédé selon la revendication 6 dans lequel la procédure 25 d'apprentissage comporte les étapes suivantes : - classer les informations échangées en fonction des différentes sources (2,6), - analyser les contenus desdites informations échangés, 3050843 39 - enrichir progressivement au moins une base d'information utilisée par l'ensemble des sources (2,6) et l'ensemble de destinataires (2,6) de même type ou de même famille. 5 8. Procédé selon la revendication 7 dans lequel, pour les informations échangées ayant nécessité une procédure de résolution d'ambiguïté ou de cohérence, la procédure d'apprentissage comporte en outre les étapes suivantes : - -analyser les contenus desdites informations, - enrichir progressivement au moins une base d'information utilisée par 10 l'ensemble des sources (2 ,6) et l'ensemble de destinataires (2,6) de même type ou de même famille. 9. Plateforme intelligente (1) de communication entre une pluralité de sources (2 ,6) et une pluralité de destinataires (2 ,6) susceptibles d'échanger des 15 informations soit un langage construit, soit un langage naturel, comportant une pluralité d'unités distribuées de traitement de l'information comprenant au moins une unité bidirectionnelle d'échange en langage naturel (50), au moins une première unité de conversion de langage (54) et au moins une première unité d'adaptation de média et de protocole (52) associées à la source, au moins une deuxième unité de conversion de 20 langage (54) et au moins une deuxième unité d'adaptation de média et de protocole (52) associées au destinataire, plateforme caractérisée en ce que: - la première unité d'adaptation de média et de protocole (52) est configurée pour intercepter les informations envoyées par au moins une source à au moins un destinataire et pour déterminer le type de langage utilisé pour les informations 25 interceptées, et - la première unité de conversion de langage (54) est configurée pour convertir automatiquement un message en langage construit décrivant des informations interceptées vers un langage naturel, - l'unité bidirectionnelle d'échange en langage naturel (50) est configurée pour transmettre lesdites informations en langage naturel au destinataire ; 3050843 40 - la deuxième unité de conversion de langage (54) est configurée pour convertir automatiquement un message en langage naturel vers un langage construit si le langage du destinataire est un langage construit. 5 10. Plateforme intelligente selon la revendication 9 dans laquelle lesdites sources (2,6) et lesdits destinataires (2,6) sont, soit des humains (2), soit des objets connectés (6) ou soit des services numériques (30). 11. Plateforme intelligente selon la revendication 10 comportant en outre 10 - au moins une unité de sélection d'un langage naturel cible, - au moins une unité bidirectionnelle (58) destinée à convertir un message en langage construit vers un langage naturel cible sélectionné et réciproquement, - une unité de contrôle (56) et de résolution d'ambiguïté et de pertinence des informations échangées. 15 12. Plateforme intelligente selon l'une des revendications 9 à 11 comportant en outre une unité d'apprentissage des modes d'utilisation par les sources (2,6) et par les destinataires (2,6) des langages naturels cibles et des langages construits de manière à améliorer les performances de conversion et de résolutions d'ambiguïté d'un 20 langage naturel humain et/ou d'un langage construit. 13. Programme d'ordinateur mémorisé sur un support d'enregistrement et comportant des instructions pour mettre en oeuvre le procédé selon les revendications 1 à 8 lorsqu'il est exécuté par ordinateur. 25