FR 3136080 A1 20231201 FR 2205197 A 20220531 Un procédé de traitement d’une requête d’un service numérique dans un environnement interactif, le procédé comprenant : générer une requête enrichie en fonction d’une interprétation de signaux reçus d’un ensemble multimodal d’interactions homme-machine résultant des interactions homme-machine (300, 310, 320, 330, 340, 350, 360, 370) issues d’actions coordonnées d’une pluralité d’utilisateurs distincts dans l’environnement interactif, chaque interaction homme-machine, considérée individuellement, étant indicative seulement d’une requête simple, la requête enrichie déclenchant une émission d’au moins une commande (700, 710). Figure de l’abrégé : Figure 5 Fusion d’interactions multimodales multi-utilisateurs La présente divulgation relève du domaine des interactions homme-machine. Plus particulièrement, la présente divulgation se rapporte à un procédé de traitement d’une requête d’un service numérique, à un programme informatique comprenant des instructions pour exécuter un tel procédé, et à un terminal pour la mise en œuvre d’un tel procédé. La multimodalité dans les services numériques actuels permet de proposer aux utilisateurs d’un service d’interagir avec celui-ci en utilisant une ou plusieurs modalités parmi l’ensemble des modalités gérées par le service. Ainsi pour les interactions entrantes l’utilisateur peut choisir par exemple le tactile ou le vocal pour émettre ses demandes. Dans des services numériques plus évolués, des procédés de fusion des modalités d’interactions permettent de faire coopérer plusieurs modalités d’interactions en même temps pour un même et unique transfert d’information, c’est-à-dire une commande de l’utilisateur, et ceci en prenant en compte différents types de coopération de modalités, telles que la complémentarité, la redondance, ou la concurrence. Ces modalités d’interactions peuvent être un geste, l’appui sur des touches, le vocal, le regard, ... Il est connu, dans des services numériques actuels, d’interpréter certaines modalités, et de décider de les fusionner ou non pour en déduire une commande entière unique, ou plusieurs commandes séparées, à exécuter. Par exemple, comme illustré sur la , un utilisateur peut donner une instruction vocale 100 d’allumer une lampe, et en même temps donner une instruction par geste 110 en tendant son bras en direction de la lampe du salon. Un module d’interprétation d’interactions entrantes 1, au sein du service numérique, fusionne ces deux interactions, reçues de deux interfaces d’entrée 10, 11 pour décider une action unique d’allumer la lampe du salon seule. Cette action est exprimée sous la forme d’une commande 900 émise à travers une interface de sortie 90. Ainsi, comme illustré sur la , il est connu de prévoir un module d’interprétation d’interactions entrantes 1 qui permet de collecter différentes modalités 100, 110, 120, 130 issues d’un unique utilisateur et reçues par exemple par une pluralité d’interfaces d’entrée 10, 11, 12, 13. Le module d’interprétation d’interactions entrantes 1 est capable de combiner certaines interactions entrantes et de décider d’actions distinctes à mettre en œuvre par l’émission de commandes indépendantes 900, 910 à travers des interfaces de sortie 90, 91. Comme illustré sur la , l’analyse d’interactions entrantes directes peut, dans certains services numériques, être enrichie d’informations contextuelles 50 issues de précédentes interactions 500 directes ou indirectes. On entend par interaction indirecte une détection par un service numérique d’une information liée à l’utilisateur sans que ce dernier ne soit conscient de cette interaction: il s’agit par exemple d’une détection de présence dans une pièce, d’une détection de jambe dans le plâtre, le niveau de bruit, de luminosité, ... Le traitement de la coopération de modalités entrantes issues d’un même utilisateur avec le procédé de fusion est une opération assez complexe du fait que chaque individu est unique et donc interagit différemment, selon le contexte, même en utilisant les mêmes modalités d’interactions pour une même commande. De ce fait dans les services numériques actuels, chaque interaction entrante directe, aussi nommée interaction entrante intentionnelle, c’est-à-dire émise dans l’intention de déclencher une commande, est associée dans un cas simple à une seule commande. Même dans les cas plus complexes, où une requête est formulée par une coopération de modalités entrantes, cette coopération est individuelle et locale. C’est-à-dire que, comme illustré sur la , la coopération est associée à un unique utilisateur, qui est l’auteur de l’ensemble des modalités considérées, et à un unique lieu, qui correspond à l’endroit où se trouve cet utilisateur. En d’autres termes, lorsque des premières modalités entrantes sont identifiées comme émanant d’un premier utilisateur et des deuxièmes modalités entrantes sont identifiées comme émanant d’un deuxième utilisateur distinct du premier utilisateur notamment au moyen d’un module d’identification (non illustré) recevant les premières et deuxièmes modalités entrantes, il est connu de fournir un premier module d’interprétation 1 pour interpréter les modalités entrantes émanant d’un premier utilisateur et un deuxième module d’interprétation 2 pour interpréter les modalités entrantes émanant d’un deuxième utilisateur, les deux modules d’interprétation fonctionnant de manière séparée et indépendante. Chaque module d’interprétation est dédié à l’interprétation de requêtes exprimées par un utilisateur spécifique et utilise pour ce faire un ensemble donné d’interfaces d’entrée et de sortie. Ainsi, selon la , le premier module d’interprétation 1 reçoit en entrée, depuis des interfaces d’entrée 10, 11, 12, 13, différentes premières interactions entrantes 100, 110, 120, 130 avec différentes premières modalités, les interprète et émet en sortie des commandes 900, 910 à travers des interfaces de sortie 90, 91. De manière analogue, le deuxième module d’interprétation 2 reçoit en entrée, depuis des interfaces d’entrée 20, 21, 22, 23, différentes deuxièmes interactions entrantes 200, 210, 220, 230 avec différentes deuxièmes modalités, les interprète et émet en sortie des commandes 800, 810 à travers des interfaces de sortie 80, 81. Or il existe un besoin pour un environnement interactif capable d’interagir simplement, de manière naturelle et ergonomique, non pas avec un seul utilisateur à la fois, mais avec plusieurs utilisateurs collectivement. Il serait également souhaitable qu’un tel environnement interactif soit compatible avec une répartition de ses utilisateurs sur différents sites. Résumé La présente divulgation vient améliorer la situation. Il est proposé un procédé de traitement d’une requête d’un service numérique dans un environnement interactif, le procédé comprenant : générer une requête enrichie en fonction d’une interprétation de signaux reçus d’un ensemble multimodal d’interactions homme-machine résultant des interactions homme-machine issues d’actions coordonnées d’une pluralité d’utilisateurs distincts dans l’environnement interactif, chaque interaction homme-machine, considérée individuellement, étant indicative seulement d’une requête simple, la requête enrichie déclenchant une émission d’au moins une commande. Le procédé proposé permet d’améliorer l’ergonomie du service numérique car il offre une prise en compte efficace d’interactions multimodales liées issues d’utilisateurs distincts. Il contribue ainsi à renforcer un comportement naturel et spontané de la part des utilisateurs du service numérique. L’expression « environnement interactif » désigne un ensemble d’interfaces homme-machine permettant l’interaction entre le service numérique et ses utilisateurs. Ces interfaces homme-machine comprennent des interfaces d’entrée et de sortie. Les interfaces d’entrée englobent par exemple un clavier, un système de pointage et/ou un écran tactile. Les interfaces de sortie peuvent inclure par exemple un écran ou encore une sortie son couplée à un module de synthèse vocale. Un visiocasque est un exemple de terminal comprenant un ensemble de capteurs de mouvement en tant qu’interface d’entrée et un dispositif d’affichage en tant qu’interface de sortie. Une caméra couplée à un module de reconnaissance automatique de gestes, ou une interface utilisant la voix comme organe d’entrée couplée avec un module de reconnaissance automatique de la parole, sont d’autres exemples d’interfaces d’entrée. L’environnement interactif peut être ainsi par exemple intégré à une application de visioconférence utilisant les interfaces d’entrée audio et vidéo des participants à une réunion. Dans ce contexte, le service numérique peut s’appuyer sur l’environnement interactif pour interpréter automatiquement différents types de signaux correspondant à des instructions fournies conjointement par les participants. Ces signaux peuvent par exemple désigner un geste d’un premier participant, une instruction orale d’un deuxième participant, une interaction d’un troisième participant avec un bouton, etc. Une requête dite « simple » présente un caractère individuel en ce qu’elle peut être déterminée à partir d’une seule interaction homme-machine émanant d’un unique utilisateur. A l’inverse, une requête dite « enrichie » présente un caractère conjoint en ce qu’elle ne peut être déterminée qu’à partir d’une pluralité d’interactions homme-machine émanant, collectivement, d’utilisateurs distincts. Le procédé proposé peut comprendre une détection que des utilisateurs distincts sont à l’origine des signaux reçus. En considérant par exemple une requête enrichie visant à envoyer un e-mail à un groupe d’utilisateurs, un titre de l’e-mail peut être automatiquement proposé sur la base de l’analyse d’une interaction directe, par exemple textuelle ou vocale, émanant d’un premier utilisateur, tandis que le contenu de l’e-mail peut être déterminé sur la base de l’analyse d’une autre interaction émanant d’un second utilisateur. Ainsi, dans cet exemple, une requête enrichie est élaborée à partir de deux requêtes simples émanant de deux utilisateurs distincts. Le procédé peut en outre comprendre une interprétation des signaux reçus déterminant la requête enrichie en fonction d’au moins un des éléments suivants : - de requêtes simples extraites des signaux reçus ; - pour chacun des signaux reçus, des utilisateurs à l’origine des signaux reçus ; - du résultat d’une détection que des utilisateurs distincts sont à l’origine des signaux reçus. L’interprétation peut être mise en œuvre par une entité logique, nommée ici analyseur ou module d’interprétation des signaux. L’analyseur peut en outre comporter plusieurs modules élémentaires interprétant chacun exclusivement des signaux qui auraient préalablement été associés à un utilisateur identifié en tant que source desdits signaux par le module d’identification évoqué. L’analyseur permet à un générateur de générer une ou plusieurs requêtes enrichies. Cette ou de ces requêtes enrichies déclenchent automatiquement des commandes correspondant à cette ou ces requêtes. Dans un exemple, le procédé comporte une identification, pour chaque signal reçu, d’un utilisateur à l’origine du signal reçu. . L’identification peut être une partie de l’interprétation d’un signal reçu, par exemple des signaux vocaux peuvent être analysés pour retrouver une empreinte vocale d’une personne. L’identification peut aussi être fondée sur un identifiant d’utilisateur à l’origine d’un signal reçu, il peut par exemple s’agir d’une adresse IP identifiant un utilisateur connecté individuellement au service numérique. L’identification permet d’interpréter différemment un signal donné en fonction de l’utilisateur identifié comme étant à l’origine de ce signal. Par exemple, une requête enrichie peut être formulée à partir à la fois d’un premier signal indiquant une proposition d’envoyer un fichier aux utilisateurs intéressés et d’une série de deuxièmes signaux issus d’utilisateurs distincts manifestant chacun leur intérêt pour la proposition. Une série de commandes « envoyer le fichier à X » peut ainsi être émise, où X désigne chaque utilisateur identifié associé à au moins un deuxième signal. En outre, lorsque plusieurs signaux reçus sont chacun associé à un utilisateur identifié, l’interprétation d’une combinaison desdits signaux reçus peut être effectuée en fonction de l’identification des utilisateurs qui en sont à l’origine. Ainsi, une fusion de modalités entrantes peut être opérée différemment selon que ces modalités entrantes sont issues d’un seul utilisateur identifié ou de plusieurs utilisateurs identifiés distincts. En particulier, il peut être considéré un exemple où plusieurs modalités liées émanant d’un même utilisateur identifié, contribuent, avec une ou plusieurs modalités supplémentaires émanant d’un ou plusieurs utilisateurs identifiés distincts, à la génération, par un générateur, d’une requête enrichie. Pour déterminer, dans cet exemple, que les modalités émanant d’un même utilisateur identifié sont liées, il est possible par exemple de se baser sur un historique de modalités émanant de cet utilisateur identifié et d’en extraire une habitude de coordination temporelle constituant une caractéristique propre à cet utilisateur identifié. Dans un exemple, l’un au moins desdits signaux comporte un identifiant d’utilisateur et générer la requête enrichie comporte au moins une des étapes suivantes : - générer la requête enrichie en fonction de l’interprétation des signaux reçus et des identifiants d’utilisateur associés, - générer la requête enrichie en adaptant, en fonction des identifiants d’utilisateur, la requête enrichie obtenue par l’interprétation des signaux reçus. Dans un exemple, l’un au moins desdits signaux comporte une information contextuelle et la génération de la requête enrichie adapte la requête enrichie en fonction d’une interprétation de cette information contextuelle. En considérant par exemple une requête enrichie visant à allumer une lampe parmi un ensemble de lampes, l’identification exacte de la lampe à allumer peut être effectuée sur la base d’un bas niveau de luminosité détecté dans une zone donnée. Le bas niveau de luminosité est ici un exemple d’information contextuelle qui vient implicitement compléter une requête enrichie formulée par fusion de modalités entrantes et qui contribue ainsi à l’interprétation des signaux reçus et à l’adaptation de la requête enrichie par le service numérique. En considérant par exemple un utilisateur situé dans un environnement bruyant, il peut être prévu d’isoler la voix de l’utilisateur du bruit ambiant afin de ne prendre en compte en tant qu’instructions vocales potentielles de l’utilisateur que ses propres paroles et non celles d’une éventuelle autre personne, située à proximité de l’utilisateur mais n’étant pas elle-même un utilisateur du service numérique. Le niveau sonore ambiant est ici un exemple d’information contextuelle associé à une interface d’entrée recevant une interaction homme-machine. Cet élément est interprété, dans ce cas précis, pour discriminer les signaux reçus par cette interface d’entrée et ainsi, de manière plus générale, adapter la ou les requêtes enrichies issues de la coordination de modalités entrantes. L’isolement des sons issus de chaque utilisateur peut aussi permettre par exemple de trouver une pluralité de sons issus d’une pluralité d’utilisateurs utilisant le même capteur sonore attaché à la même interface d’entrée. En d’autres termes, il est possible d’isoler, dans un flux audio entrant, plusieurs sons susceptibles de renfermer chacun une requête simple tout en identifiant l’auteur de chacun des sons isolés, en vue de la génération de la requête enrichie. Une information contextuelle peut être associée à un utilisateur et peut désigner par exemple une préférence ou caractéristique propre à l’utilisateur, ou encore une interaction indirecte de l’utilisateur avec le service numérique. Une information contextuelle associée à une interface d’entrée peut désigner par exemple une caractéristique propre à un terminal et indépendante de l’utilisateur, c’est-à-dire commune aux signaux reçus par l’interface d’entrée depuis ce terminal, et ce que ces signaux émanent d’un utilisateur unique ou au contraire de plusieurs utilisateurs distincts. De manière générale, une information contextuelle est une donnée numérique utilisable comme aide à l’interprétation d’une interaction directe de l’utilisateur avec le service numérique. Les données numériques évoquées dans les exemples ci-dessus, c’est-à-dire l’identifiant d’utilisateur et l’information contextuelle, ne sont pas nécessairement incluses directement dans un ou plusieurs signaux reçus mais peuvent plus généralement être obtenues de toute manière techniquement envisageable, que ce soit notamment par une transmission distincte ou par une détermination, par exemple par l’interprétation des signaux reçus, une telle détermination pouvant être mise en œuvre localement, ou de manière centralisée, ou encore à l’aide de moyens informatiques en nuage. Dans un exemple, le procédé proposé comprend en outre horodater des instants au moins de début de réceptions desdits signaux, interpréter des écarts temporels entre les instants de début de réceptions respectives desdits signaux, et adapter la requête enrichie en fonction de l’interprétation de ces écarts temporels. La coordination temporelle de modalités liées, telles qu’une instruction gestuelle couplée à une instruction vocale, varie d’un utilisateur à l’autre. Ces différences sont susceptibles de porter aussi bien sur la durée de chaque modalité en fonction de l’utilisateur qui la met en œuvre que sur la synchronisation des modalités. En dépit de ces différences, il est possible de définir un seuil en-deçà duquel deux modalités, notamment deux modalités différentes, au moins en ce qu’elles sont issues d’utilisateurs distincts, sont réputées liées, c’est-à-dire se rapportant à la génération de la même requête enrichie. A titre de variante, il est possible d’associer un écart temporel entre le début de modalités d’interaction entrantes à un niveau de probabilité que ces modalités soient liées. Ainsi, une même commande finale peut être obtenue à partir d’une combinaison d’un signal indicatif d’une instruction gestuelle avec un signal indicatif d’une instruction vocale, indépendamment de l’utilisateur auteur de chaque instruction. Par exemple, au moins une partie desdits signaux reçus peut être issue d’une pluralité d’interfaces d’entrée réparties sur des sites différents. Ainsi, le procédé proposé permet à des utilisateurs répartis sur différents sites, et disposant chacun d’au moins une interface d’entrée, d’agir de manière coordonnée pour formuler leurs intentions. Les signaux reçus par les interfaces d’entrée traduisent ces intentions associées à des utilisateurs distincts. Ces signaux combinés sont utilisés par le service numérique pour formuler une requête enrichie correspondant aux intentions des utilisateurs et émettre la commande correspondant à la requête enrichie formulée. Par exemple, le procédé proposé peut comporter en outre : horodater des instants au moins de début de réceptions desdits signaux, corriger des instants de début de réceptions respectives desdits signaux en fonction d’une latence entre lesdits sites, interpréter des écarts temporels corrigés entre des instants horodatés corrigés, et adapter la requête enrichie en fonction de l’interprétation des écarts temporels corrigés. Ainsi, le procédé proposé prend en compte la latence dans une communication entre différents sites. En synchronisant les référentiels temps de chaque utilisateur, le procédé proposé permet une meilleure identification de modalités coordonnées comme étant liées. Selon un autre aspect, il est proposé un programme informatique comportant des instructions pour la mise en œuvre du procédé proposé, lorsque lesdites instructions sont exécutées par un processeur. Selon un autre aspect, il est proposé un dispositif de traitement d’une requête d’un service numérique dans un environnement interactif, le dispositif de traitement comprenant au moins un générateur d’une requête enrichie en fonction d’une interprétation de signaux reçus d’un ensemble multimodal d’interactions homme-machine résultant des interactions homme-machine issues d’actions coordonnées d’une pluralité d’utilisateurs distincts dans l’environnement interactif, chaque interaction homme-machine, considérée individuellement, étant indicative seulement d’une requête simple, la requête enrichie déclenchant une émission d’au moins une commande. Le dispositif de traitement peut comporter en outre un analyseur apte à interpréter des signaux reçus déterminant la requête enrichie en fonction d’au moins un des éléments suivants : - de requêtes simples extraites des signaux reçus ; - pour chacun des signaux reçus, des utilisateurs à l’origine des signaux reçus. Le dispositif de traitement peut comporter en outre un identificateur d’utilisateur apte à identifier, pour chaque signal reçu un utilisateur à l’origine du signal reçu. Le dispositif de traitement peut être implémenté par exemple dans au moins un dispositif parmi les suivants : - un terminal, - un gestionnaire d’objets connectés apte à commander au moins un objet connecté à un réseau de communication au moyen d’au moins une commande correspondant à la requête enrichie à destination d’au moins un objet connecté. Par exemple, le dispositif de traitement peut comprendre un circuit de traitement comprenant une mémoire de stockage stockant le programme informatique proposé et un processeur raccordé à la mémoire de stockage et à une ou plusieurs interfaces du terminal. Alternativement, le dispositif de traitement peut être dénué d’un tel circuit de traitement, qui est alors déporté et configuré pour échanger avec le dispositif de traitement par le biais d’un canal de communication. D’autres caractéristiques, détails et avantages apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels : Fig. 1 illustre un traitement connu d’une requête découlant d’actions émanant d’un unique utilisateur d’un service numérique, où deux modalités d’interaction sont fusionnées pour construire une commande. Fig. 2 illustre une variante connue du traitement de la , où plusieurs modalités d’interaction sont traitées pour construire plusieurs commandes. Fig. 3 illustre une variante connue du traitement de la , où des données contextuelles sont prises en compte pour interpréter une ou plusieurs interactions entrantes. Fig. 4 illustre côte à côte deux traitements identiques connus selon la . Les traitements concernent chacun un utilisateur unique et sont effectués de manière totalement isolée l’un de l’autre, chaque traitement relatif à un utilisateur distinct découlant uniquement d’interactions dont cet utilisateur est à l’origine et construisant une commande distincte. Fig. 5 illustre un traitement de requêtes découlant d’actions coordonnées de plusieurs utilisateurs d’un service numérique, selon un exemple de réalisation. Fig. 6 illustre une variante du traitement de la , où des données contextuelles sont prises en compte pour interpréter une ou plusieurs interactions entrantes. Fig. 7 illustre les différences de coordination de modalités liées pour une requête individuelle donnée en fonction de leur auteur. Fig. 8 illustre un exemple de coordination de modalités liées pour une requête collective donnée. Fig. 9 illustre un exemple particulier de traitement de modalités d’interaction particulières, selon le principe général de la , pour construire une commande particulière. Fig. 10 illustre un autre exemple particulier de traitement de modalités d’interaction particulières, toujours selon le principe général de la , pour construire une commande particulière. Procédé de traitement d’une requête d’un service numérique dans un environnement interactif, le procédé comprenant : générer une requête enrichie en fonction d’une interprétation de signaux reçus d’un ensemble multimodal d’interactions homme-machine résultant des interactions homme-machine (300, 310, 320, 330, 340, 350, 360, 370) issues d’actions coordonnées d’une pluralité d’utilisateurs distincts dans l’environnement interactif, chaque interaction homme-machine, considérée individuellement, étant indicative seulement d’une requête simple, la requête enrichie déclenchant une émission d’au moins une commande (700, 710). Procédé selon la revendication 1, comprenant en outre : détecter que des utilisateurs distincts sont à l’origine des signaux reçus. Procédé selon la revendication 1 ou 2, dans lequel le procédé comprend une interprétation des signaux reçus déterminant la requête enrichie en fonction d’au moins un des éléments suivants : - de requêtes simples extraites des signaux reçus ; - pour chacun des signaux reçus, des utilisateurs à l’origine des signaux reçus ; - du résultat d’une détection que des utilisateurs distincts sont à l’origine des signaux reçus. Procédé selon l’une des revendications 1 à 3, dans lequel le procédé comprend une identification, pour chaque signal reçu, d’un utilisateur à l’origine du signal reçu. Procédé selon l’une des revendications précédentes, dans lequel l’un au moins desdits signaux comporte un identifiant d’utilisateur et générer la requête enrichie comporte au moins une des étapes suivantes : générer la requête enrichie en fonction de l’interprétation des signaux reçus et des identifiants d’utilisateur associés, et générer la requête enrichie en adaptant, en fonction des identifiants d’utilisateur, la requête enrichie obtenue par l’interprétation des signaux reçus. Procédé selon l'une des revendications précédentes, dans lequel, lorsque l’un au moins desdits signaux comporte une information contextuelle (50), la génération de la requête enrichie adapte la requête enrichie en fonction d’une interprétation de cette information contextuelle. Procédé selon l'une des revendications précédentes, comportant en outre : horodater des instants au moins de début de réceptions desdits signaux, interpréter des écarts temporels entre les instants de début de réceptions respectives desdits signaux, et adapter la requête enrichie en fonction de l’interprétation de ces écarts temporels. Procédé selon l’une des revendications précédentes, dans lequel au moins une partie desdits signaux reçus est issue d’une pluralité d’interfaces d’entrée (30, 31, 32, 33, 34, 35, 36, 37) réparties sur des sites différents. Procédé selon la revendication 8, comportant en outre : horodater des instants au moins de début de réceptions desdits signaux, corriger des instants de début de réceptions respectives desdits signaux en fonction d’une latence entre lesdits sites, interpréter des écarts temporels corrigés entre des instants horodatés corrigés, et adapter la requête enrichie en fonction de l’interprétation des écarts temporels corrigés. Programme informatique comportant des instructions pour la mise en œuvre du procédé de traitement selon l’une des revendications 1 à 9, lorsque lesdites instructions sont exécutées par un processeur. Dispositif de traitement d’une requête d’un service numérique dans un environnement interactif , le dispositif de traitement comprenant au moins : un générateur d’une requête enrichie en fonction d’une interprétation de signaux reçus d’un ensemble multimodal d’interactions homme-machine résultant des interactions homme-machine (300, 310, 320, 330, 340, 350, 360, 370) issues d’actions coordonnées d’une pluralité d’utilisateurs distincts dans l’environnement interactif, chaque interaction homme-machine, considérée individuellement, étant indicative seulement d’une requête simple, la requête enrichie déclenchant une émission d’au moins une commande (700, 710). Dispositif de traitement selon la revendication 11, dans lequel le dispositif de traitement comporte un analyseur (3) apte à interpréter des signaux reçus déterminant la requête enrichie en fonction d’au moins un des éléments suivants : - de requêtes simples extraites des signaux reçus ; - pour chacun des signaux reçus, des utilisateurs à l’origine des signaux reçus. Dispositif de traitement selon la revendication 12, dans lequel le dispositif de traitement comporte un identificateur d’utilisateur apte à identifier, pour chaque signal reçu un utilisateur à l’origine du signal reçu. Dispositif de traitement selon l’un quelconque des revendication 11 à 13, dans lequel le dispositif de traitement est implémenté dans au moins un dispositif parmi les suivants : - un terminal, - un gestionnaire d’objets connectés apte à commander au moins un objet connecté à un réseau de communication au moyen d’au moins une commande correspondant à la requête enrichie à destination d’au moins un objet connecté.