Brevet FR3155335A1 — publié le 20250516

Il est proposé un procédé de conversion d'une commande ainsi qu’un programme d’ordinateur, un support d’enregistrement et un interpréteur correspondants. La commande est exprimée au moins en partie en langage naturel et concernant un état d’un équipement, en une instruction logique La technique proposée comprend une obtention de l’instruction logique par l'intermédiaire d'un interpréteur de ladite commande sollicitant un modèle de langage avec une requête comprenant la commande et un ensemble de règles d’interprétation comprenant uniquement des premières règles d’interprétation, l’instruction logique étant conforme à ce que produirait une interprétation de la commande par application d’une deuxième règle d’interprétation dérivable à partir de l’ensemble de premières règles, la deuxième règle d’interprétation étant distincte des premières règles d’interprétation. Figure de l’abrégé : Figure 1 Procédé de conversion d'une commande La présente divulgation concerne un procédé de conversion d'une commande ainsi qu’un programme d’ordinateur, un support d’enregistrement et un interpréteur correspondants. Actuellement, pour piloter, par des commandes en langage naturel, orales ou écrites, des équipements électroniques, tels que des lampes, des volets roulants, un système de chauffage, des robots, des ordinateurs, … (il en existe une très grande variété), il est nécessaire de disposer d’un mécanisme d’interprétation du langage naturel, baptisé NLU en anglais (Natural Language Understanding), construit spécifiquement pour prendre en compte toutes les commandes susceptibles d’être formulées. Or un tel système pose généralement au moins deux problèmes. D’une part, il est fastidieux à construire, car il demande d’anticiper, pour chaque commande, toutes les formulations possibles. D’autre part, même avec un bon niveau d’anticipation, un tel système s’avère généralement insuffisant, car bien des variantes d’une formulation auront été oubliées. En outre, plus le nombre de règles NLU est important, pour prendre en compte une grande variété de formulations, plus le système devient complexe à maintenir. Résumé La présente divulgation vient améliorer la situation. Il est proposé, selon un aspect, un procédé de conversion d'une commande, exprimée au moins en partie en langage naturel et concernant un état d’un équipement, en une instruction logique, le procédé comprenant une obtention de l’instruction logique par l'intermédiaire d'un interpréteur de ladite commande sollicitant un modèle de langage avec une requête comprenant la commande et un ensemble de règles d’interprétation comprenant uniquement des premières règles d’interprétation, l’instruction logique étant conforme à ce que produirait une interprétation de la commande par application d’une deuxième règle d’interprétation dérivable à partir de l’ensemble de premières règles, la deuxième règle d’interprétation étant distincte des premières règles d’interprétation. Il est proposé, selon un autre aspect, un programme d’ordinateur comprenant des instructions qui, lorsque le programme est mis en œuvre par un processeur, conduisent à mettre en œuvre ledit procédé. Il est proposé, selon un autre aspect, un support d’enregistrement non transitoire lisible par un ordinateur sur lequel est enregistré ledit programme informatique. Il est proposé, selon un autre aspect, un interpréteur d’une commande, exprimée au moins en partie en langage naturel et concernant un état d’un équipement, en une instruction logique, l’interpréteur étant configuré pour obtenir l’instruction logique en sollicitant un modèle de langage avec une requête comprenant la commande et un ensemble de règles d’interprétation comprenant uniquement des premières règles d’interprétation, l’instruction logique étant conforme à ce que produirait une interprétation de la commande par application d’une deuxième règle d’interprétation dérivable à partir de l’ensemble de premières règles, la deuxième règle d’interprétation étant distincte des premières règles d’interprétation. La présente divulgation permet, sous chacun de ses aspects, d’optimiser la communication entre les utilisateurs et tout équipement contrôlé par des moyens informatiques. Elle facilite l'interaction en langage naturel tout en offrant la possibilité d'une exécution précise et fiable des commandes par le biais d'une transformation en instruction logique. Dans un exemple, l’instruction logique est adaptée pour entraîner un changement d’état de l’équipement d’un état actuel vers un état souhaité lorsque l’instruction logique est exécutée par un moteur de raisonnement logique. Cela a pour avantage de rendre les interactions avec les systèmes automatisés plus accessibles et intuitives pour les utilisateurs, tout en maintenant une grande précision dans l'exécution des commandes. Cela réduit également le risque d'erreurs dues à des malentendus ou à des interprétations incorrectes du langage naturel, améliorant ainsi la fiabilité du système. Dans un exemple, l’instruction logique est adaptée pour entraîner une transmission d’un signal spécifiant l’état actuel lorsque l’instruction logique est exécutée par un moteur de raisonnement logique. Il est ainsi possible, par exemple, de fournir un retour immédiat à l'utilisateur sur l'état actuel de l'équipement, ce qui peut être crucial dans des situations où la connaissance de l'état actuel de l'équipement est nécessaire pour prendre des décisions éclairées ou pour assurer la sécurité. Dans un exemple, l’ensemble de premières règles contient une règle relative à une désignation de l’équipement et une règle relative à une désignation de l’état souhaité. Cela a pour avantage de faciliter la configuration et la personnalisation du système, car les utilisateurs peuvent désigner spécifiquement l'équipement et l'état souhaité en utilisant leur propre langage. Cela rend la technique proposée plus flexible et plus facile à utiliser, même pour ceux qui ne sont pas familiers avec la technologie. Dans un exemple, la requête comprend en outre une donnée descriptive de l’état actuel de l’équipement. Prendre en compte l'état actuel de l'équipement lors de l'interprétation des commandes renforce la robustesse et la fiabilité de la technique proposée. Cela assure que les actions entreprises sont toujours pertinentes et appropriées à la situation actuelle. Dans un exemple, le procédé comprend ou le système prévoit en outre une transmission de l’instruction logique à un moteur de raisonnement logique pour une exécution de l’instruction logique. Le moteur de raisonnement logique participe à l’exécution des commandes et contribue à une interaction fluide entre l’utilisateur et le système chargé de traiter les commandes. 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 FIG. 1 représente un système de traitement d’une commande dans un exemple de réalisation. Fig. 2 FIG. 2 représente un circuit de traitement adapté pour mettre en œuvre un procédé de conversion d'une commande, exprimée au moins en partie en langage naturel, en une instruction logique. Fig. 3 FIG. 3 représente, sous la forme d’un ordinogramme, un algorithme permettant au circuit de traitement de FIG. 2 de mettre en œuvre le procédé de conversion précité. Dans la description qui va suivre, des chiffres de référence identiques désignent des pièces identiques ou ayant des fonctions similaires. FIG. 1 représente les éléments principaux d’un système (100) convenant pour traiter une commande exprimée au moins en partie en langage naturel et pour gérer un ensemble d’équipements. Les éléments du système sont mis en œuvre par des moyens informatiques, par exemple par un ou plusieurs circuits de traitement (200) tels que celui représenté en FIG. 2 , qui comprend un processeur (202) ayant une fonction de traitement de données, raccordé à une mémoire (204) ayant une fonction de stockage de données, et à une interface de communication (206) ayant une fonction de réception et/ou de transmission de données. Le système peut avoir une fonction domotique, les équipements gérés étant installés dans une habitation et comprenant par exemple des lampes, un système de chauffage, des volets, un système de sécurité, des équipements multimédia, etc. Alternativement, le système peut être destiné à la gestion d’équipements industriels, tels que des robots installés sur un ou plusieurs sites. Il peut avoir pour fonctions de contrôler de telles machines ou d’obtenir des informations sur leur état, à des fins notamment de sécurité et d’efficacité. Un autre domaine possible d’application est le service client, dans l’optique de permettre à des agents de fournir des réponses plus précises et pertinentes en temps réel à des demandes de leurs clients. Le système peut aussi trouver une application dans les domaines de l’assistance médicale et/ou de l’accessibilité, permettant à des personnes à mobilité réduite de contrôler différents appareils médicaux ou d’assistance à domicile, afin d’améliorer leur qualité de vie. Une interface homme-machine (102) permet au système de recevoir une commande énoncée en langage naturel par un utilisateur, par exemple un habitant dans le cas d’un système domotique ou un opérateur dans le cas d’un système de gestion d’équipements industriels. L’interaction peut être fournie sous tout format approprié dans le cas d’espèce, en particulier textuel ou vocal. La commande représente une intention sous-jacente de l’utilisateur. L’intention de l’utilisateur peut concerner un pilotage d’un équipement géré, en particulier un changement d’état de l’équipement géré vers un état souhaité. Par exemple, dans le cas d’un système domotique, il peut s’agir d’allumer ou d’éteindre la lampe du salon. Alternativement, l’intention de l’utilisateur peut porter sur une demande d’information, qui peut être ou non en lien avec un état d’un équipement géré. Par exemple, l’intention de l’utilisateur, habitant, peut être de savoir si, à un instant courant, la lampe du salon est allumée. Alternativement, l’intention de l’utilisateur peut être d’obtenir une réponse à une question de culture générale sans rapport avec l’ensemble d’équipements gérés. Un interpréteur de commande (104) est prévu pour permettre d’interpréter la commande ainsi reçue. Pour cela, l’interpréteur est susceptible de solliciter un ou plusieurs modules du système, en particulier un modèle de langage (106), LLM en anglais pour « Large Language Model », une base de données (108) et/ou un générateur en langage naturel (110) et/ou un processeur de traitement de langage naturel ou « processeur NLU » (non représenté). Le résultat de l’interprétation de la commande par l’interpréteur de commande (104) est une formule logique représentant l’intention sous-jacente de l’utilisateur. Un modèle de langage (106) est un service dont l’utilisation est désormais démocratisée. Son principe de fonctionnement simplifié repose sur la génération d'une séquence de mots en sortie, réalisée par une prédiction successive mot à mot. Cette prédiction se base sur une séquence de mots fournie en entrée. Les modèles de langage modernes, en particulier ceux basés sur des architectures de type transformateur, intègrent de nombreux autres éléments dans leur fonctionnement, tels que l'attention, les plongements lexicaux et les couches de neurones. La base de données (108) contient des informations descriptives se rapportant aux équipements gérés par le système. En reprenant l’exemple de la lampe du salon dans un système à fonction domotique, la base de données peut être conçue pour stocker une information descriptive indiquant l’état courant de la lampe, c’est-à-dire si elle est par exemple allumée ou éteinte, et dans le cas d’une lampe ayant des paramètres réglables tels que l’intensité ou la couleur, la valeur courante de ces paramètres. Un mécanisme approprié peut être prévu pour mettre à jour les informations descriptives dans la base de données à chaque changement d’état de l’équipement correspondant. La base de données (108) contient également des règles de compréhension de langage naturel, ou règles NLU, prédéterminées et le générateur en langage naturel (110) est conçu pour accéder à ces règles NLU et les appliquer afin d’interpréter des commandes reçues. Il peut être prévu que l’interpréteur de commande sollicite d’abord le générateur en langage naturel ou le processeur NLU pour tenter d’interpréter la commande et, seulement en cas d’échec, sollicite ensuite le modèle de langage. Cette démarche séquentielle permet de tirer parti de règles NLU déjà prévues, notamment de règles NLG (Natural Langage Generation) qui explicitent comment passer d’une formule logique à une phrase en langage naturel, et peut présenter des avantages en matière de rapidité et d’économie de ressources. Alternativement, il peut être prévu que l’interpréteur de commande sollicite toujours à la fois le générateur en langage naturel ou le processeur NLU pour obtenir un premier résultat d’interprétation et le modèle de langage pour obtenir un deuxième résultat d’interprétation. Cette approche parallèle permet de mettre en œuvre une validation croisée qui renforce la robustesse de l’interprétation. Elle permet aussi de mettre en œuvre, par des moyens d’intelligence artificielle appropriés, un algorithme d’amélioration continue des règles NLU applicables par le générateur en langage naturel. Le choix entre l’une de ces deux approches peut dépendre des besoins spécifiques du système, de types de commande attendus et des ressources disponibles. L’interpréteur de commandes peut être configuré pour accéder à tout ou partie du contenu de la base de données, en particulier aux données descriptives et aux règles NLU ou aux règles NLG, en vue de transmettre tout ou partie de ce contenu au modèle de langage. Des mécanismes de filtrage ou de masquage peuvent être prévus pour diverses raisons. Une raison peut être d’empêcher, par exemple, de transmettre au modèle de langage des informations sensibles qui seraient contenues dans la base de données. Une autre raison peut être d’éviter de transmettre au modèle de langage des informations jugées inutiles à l’interprétation de la commande. Des exemples d’échanges entre l’interpréteur de commande et les modules précités sont détaillés plus loin dans le présent document à travers FIG. 3 et plusieurs exemples particuliers. Le système est également configuré pour mettre en œuvre un moteur de raisonnement logique (112) et une fabrique d’actions (114) pour, in fine, exécuter des actions dès lors qu’elles sont jugées pertinentes. En particulier, l’interpréteur de commande peut être configuré pour transmettre la formule logique au moteur de raisonnement logique (112), qui peut soit valider l’intention et transmettre une instruction à la fabrique d’actions (114) afin de mettre en œuvre l’action correspondante, soit ne pas valider l’action et, en conséquence, ne pas transmettre ladite instruction à la fabrique d’actions. Le moteur de raisonnement logique peut, par exemple, être implémenté sous la forme de règles précisant une ou plusieurs formules logiques comme antécédent et une ou plusieurs formules logiques en guise de conclusion. Les formules logiques précisées comme antécédent peuvent se rapporter à une ou plusieurs données descriptives issues de la base de données (108). Des règles et des formules logiques associées sont détaillées plus loin dans le présent document à travers plusieurs exemples particuliers. Le moteur de raisonnement logique (112) peut aussi mettre en œuvre un moteur de planification d’actions (116), par exemple de type PDDL pour « Planning Domain Definition Language » en anglais. Les actions issues de la fabrique d’actions et concernant un équipement donné sont transmises à une interface (118) de commande chargée de commander l’équipement concerné. Le système peut être configuré pour transmettre un retour à l’utilisateur après un traitement de la commande par le système. Le retour peut être un simple accusé de réception faisant suite à la réception de la commande par l’interface homme-machine (102). Le retour peut aussi contenir une indication se rapportant à l’intention de l’utilisateur et faisant suite à l’interprétation de la commande par l’interpréteur (104). Par exemple, lorsque l’intention sous-jacente de l’utilisateur concerne une demande d’information, l’interpréteur de commande peut être configuré pour fournir une réponse à cette demande d’information. Par exemple, lorsque l’intention sous-jacente de l’utilisateur concerne un changement d’état d’un équipement géré, le moteur de raisonnement logique peut être configuré pour envoyer un message à l’utilisateur pour lui indiquer si une action correspondant à ce changement d’état est validée ou non. Il est à présent fait référence à FIG. 3 qui décrit de manière détaillée le processus suivi par l’interpréteur de commandes lorsqu'il reçoit une commande exprimée en langage naturel et interagit avec le modèle de langage (LLM) pour générer une instruction logique destinée au moteur de raisonnement logique. Lorsqu'une commande est reçue par l'interface homme-machine, elle est transmise (302) à l'interpréteur de commande. Comme déjà indiqué, la commande peut être de diverses natures, allant d'une demande d'action sur un équipement géré à une question d'ordre général. L’interpréteur commence par obtenir (304) un ensemble de règles d’interprétation. Ces règles peuvent être stockées dans la base de données et comprennent à la fois des règles NLU prédéfinies et potentiellement des règles générées par une interaction précédente avec le modèle de langage. En parallèle, l’interpréteur peut récupérer (306) les données descriptives concernant l’équipement mentionné dans la commande depuis la base de données. Par exemple, si la commande concerne l'état d'une lampe dans le salon, l’interpréteur peut récupérer la ou les données descriptives de l'état actuel de cette lampe dans la base de données. L’interpréteur transforme la commande reçue en une requête structurée à destination du modèle de langage. Cette requête structurée, également appelée « prompt » en anglais, est composée d’une série d’instructions et d’informations qui aident le modèle de langage à comprendre et à traiter la commande. La requête structurée inclut la commande de l'utilisateur ainsi qu'un ensemble spécifique d’une ou plusieurs règles d'interprétation, que nous appellerons ici les « premières règles d'interprétation ». Ces premières règles sont directement fournies au modèle de langage pour guider sa compréhension et son interprétation de la commande. La requête peut aussi comprendre une ou plusieurs données descriptives, jugées utiles pour aider le modèle de langage à comprendre le contexte, mais cela n’est pas strictement nécessaire. Dans un mode de réalisation, le modèle de langage peut traiter plusieurs requêtes successives, créant ainsi un fil de discussion avec l'utilisateur. Dans ce cas, il peut être suffisant de transmettre uniquement la commande en tant que requête pour obtenir une réponse satisfaisante, à condition qu'une requête structurée complète ait été transmise précédemment dans le même fil de discussion. L’interaction cruciale avec le LLM s'effectue lorsque l'interpréteur le sollicite (308) en lui soumettant la requête, exploitant ainsi sa puissance pour générer une représentation logique de l'intention de l'utilisateur. Le modèle de langage répond en générant une formule logique qui représente cette intention. Si une règle d'interprétation présente dans la requête correspond directement à la commande, la formule logique générée est identique au résultat obtenu en appliquant directement cette règle à la commande. Cependant, il est possible que la commande nécessite l'application d'une règle d'interprétation spécifique, différente des premières règles fournies, que nous nommerons « deuxième règle d'interprétation ». Il n’est pas nécessaire que cette deuxième règle d'interprétation soit explicitement présente dans l'ensemble de règles initialement fourni au modèle de langage. Il suffit qu’elle puisse être logiquement dérivée ou inférée à partir de ces premières règles d'interprétation, pour que le modèle de langage ait la capacité de comprendre correctement la commande et de générer une réponse appropriée. En d'autres termes, même si la règle exacte nécessaire pour interpréter la commande n'est pas directement fournie dans la requête, le modèle de langage peut fournir un résultat correspondant à l’application de cette règle à partir des informations qu'il a reçues, assurant ainsi une interprétation correcte et précise de l'intention de l'utilisateur. Une formule logique est ainsi obtenue (310) et transmise (312) au moteur de raisonnement logique. Si l'intention concerne une action, le moteur peut vérifier si cette action est possible ou pertinente étant donné l'état actuel des équipements, tel qu'il est décrit dans la base de données. Si l'intention concerne une demande d'information, le moteur peut directement répondre en consultant la base de données et, par exemple, informer l'utilisateur que la lampe est déjà allumée. Le processus ainsi décrit permet donc de convertir une commande exprimée en langage naturel en une instruction logique claire et précise, facilitant la prise de décision et l'action par le système. Plusieurs exemples de traitement de commandes particulières sont à présent décrits. Dans chacun de ces exemples, le processus de conversion présenté ci-dessus est mis en œuvre pour obtenir une formule logique, qui est ensuite traitée par le moteur de raisonnement logique, Dans un premier exemple, l’utilisateur demande d’allumer la lampe du salon. Un exemple simplifié de requête destinée au modèle de langage, présenté arbitrairement sous la forme d’une série d’objets JSON, est le suivant : { role: system, content: Tu es un système NLU capable de comprendre le langage naturel Instructions : ... Connaissance : … Actions : - pour allumer ou éteindre un équipement utilise l'intention (is-switched ?device ?state) - … Entités : - pour désigner la lampe du salon utilise le symbole living-room-light - … }, { role: user, content: colorie le rectangle 1 en bleu }, { role: assistant, content: (I ?user (is-colored rectangle-1 blue)) }, { role: user, content: quelle est la température actuelle dans la chambre }, { role: assistant, content: (I ?user (B ?user (current-temperature bedroom ?temperature)) }, …, { role: user, content: allume la lampe du salon } Les pointillés renvoient à des informations qui peuvent être contenues dans la requête mais ne sont pas reprises ici car non pertinentes pour les besoins de l’explication. Spécifiquement, des données descriptives peuvent être fournies dans la rubrique intitulée « Connaissance ». Un ensemble de premières règles d’interprétation est également fourni dans les rubriques intitulées « Actions » et « Entités », et la commande est fournie sous la forme de son propre objet JSON à la fin de la requête. Dans cet exemple, l’ensemble de premières règles d’interprétation est conceptuellement divisé en deux parties, l’une relative à la désignation d’états spécifiques d’équipements quelconques, et l’autre relative à la désignation d’équipements spécifiques. Dans cet exemple, la requête contient d’autres informations, notamment un en-tête, éventuellement des instructions spécifiques, ainsi que plusieurs commandes précédentes, l’une relative à une demande d’action, l’autre relative à une demande d’information, et le résultat d’interprétation associé à chacune. Ces différentes informations supplémentaires peuvent compléter ou se substituer à certaines règles d’interprétation. Sur la base de la requête fournie, le modèle de langage fournit un résultat d’interprétation de la commande visant à allumer la lampe du salon. Le résultat attendu est la formule logique suivante : (I ?user (is-switched living-room-light on)) Cette formule logique représente l’intention de l’utilisateur et est de la forme « (I ?user ?phi) » ; elle indique que l’utilisateur ?user à l’intention que la formule ?phi soit vraie. Plus spécifiquement, elle indique que l’utilisateur ?user a l’intention que la lampe désignée par « living-room-lamp » soit allumée. Le moteur de raisonnement logique est configuré pour recevoir et traiter la formule logique en appliquant un nombre limité de règles prédéterminées génériques, qui comprennent chacune une ou plusieurs formules logiques en entrée et une ou plusieurs formules logiques en sortie. Les règles prédéterminées sont génériques en ce que les formules logiques qui y figurent ne nécessitent aucune référence à un équipement particulier ou à un état particulier, ce qui contribue à les rendre compatibles avec le traitement d’un grand nombre de formules logiques spécifiques susceptibles d’être générées par le modèle de langage et fournies en entrée. Deux règles prédéterminées sont ici fournies à titre d’exemples. La première règle prédéterminée prévoit de signaler à l’utilisateur, suite à la réception d’une instruction visant à allumer un équipement, une situation où l’instruction ne peut pas être appliquée car l’équipement concerné est déjà allumé. La première règle prédéterminée est la suivante : (I ?user (is-switched ?dev on)) & (is-switched ?dev on) -> (I self (B ?user (is-switched ?dev on)) Elle contient deux formules logiques en tant qu’antécédent, la première sous la forme « (I ?user ?phi) » et obtenue en sortie de l’interpréteur de commande et la seconde sous la forme « ?phi » et correspondant à une donnée descriptive stockée dans la base de données. Elle contient également une formule logique en sortie sous la forme « (I self (B ?user ?phi)) » exprimant l’intention du système (self) de communiquer une donnée descriptive spécifique correspondant à « ?phi » à l’utilisateur. La deuxième règle prédéterminée prévoit d’allumer l’équipement si celui-ci est éteint. La deuxième règle prédéterminée est la suivante : (I ?user (is-switched ?dev on) & (is-switched ?dev off) -> (I self (is-switched ?dev on) Tout comme la première règle prédéterminée, elle contient deux formules logiques en tant qu’antécédent, la première sous la forme « (I ?user ?phi) » et obtenue en sortie de l’interpréteur de commande et la seconde sous la forme « ?phi » et correspondant à une donnée descriptive stockée dans la base de données. Elle contient également une formule logique en sortie sous la forme « (I self ?phi) », exprimant l’intention du système (self) de réaliser l’action ?phi. Par exemple, s’il existe une action permettant de satisfaire l’intention (« est-ce que le dispositif est allumé ? », en anglais « is switched device on ?"), cette action (qui dans le cas présente allume le dispositif) sera automatiquement exécutée. Les deux règles prédéterminées ainsi décrites permettent au moteur de raisonnement logique de traiter de manière adéquate une instruction visant à allumer la lampe du salon. Si la lampe du salon est d’ores et déjà allumée, le moteur de raisonnement logique le sait en consultant les données descriptives disponibles. Il peut alors décider d’envoyer un message à l’utilisateur pour lui indiquer que la lampe en question est déjà allumée. Si la lampe du salon est initialement éteinte, alors le moteur de raisonnement logique peut procéder à l’émission d’une instruction visant à l’allumer conformément à l’intention de l’utilisateur. Dans un deuxième exemple, l’utilisateur demande si la lampe du salon est allumée. La requête correspondante peut être générée par l’interpréteur de commande de manière à contenir les mêmes informations que celles figurant dans la requête indiquée dans le premier exemple, à l’exception de la commande, qui est formulée comme : { role: user, content: la lampe du salon est-elle allumée }. Sur la base de la requête fournie, le modèle de langage fournit un résultat d’interprétation de la commande visant à indiquer si la lampe du salon est allumée. Le résultat attendu est : « (I ?user (B ?user (is-switched living-room-lamp on)) ». Il s’agit d’une formule logique de la forme « (I ?user (B ?user ?phi)) », qui signifie que l’utilisateur ?user à l’intention de connaître une donnée descriptive spécifique correspondant à « ?phi ». Une formule logique ayant la même structure « (I ?user (B ?user (current-temperature bedroom ?temperature)) » est fournie dans la requête : elle retranscrit une intention de l’utilisateur de connaître la température dans une chambre. Dans le deuxième exemple, la formule logique attendue « (I ?user (B ?user (is-switched living-room-lamp on)) » signifie que l’utilisateur à l’intention de savoir si la lampe du salon est allumée. Le moteur de raisonnement peut être configuré pour traiter cette formule logique en appliquant une troisième règle prédéterminée prévoyant que si l’utilisateur veut connaître une donnée descriptive spécifique correspondant à « ?phi » alors le système à l’intention de lui communiquer cette donnée descriptive. La troisième règle prédéterminée est la suivante : (I ?user (B ?user ?phi)) -> (I self (B ?user ?phi)) Dans un troisième exemple, l’utilisateur demande à mettre le salon de son logement en mode cinéma. On suppose qu’un tel mode implique plusieurs équipements simultanément. Par exemple, le mode cinéma peut correspondre à une situation où les volets sont fermés et les lampes réglées de manière à obtenir une luminosité faible. Dans la mesure où plusieurs actions doivent potentiellement être mises en œuvre, il peut être prévu de calculer un plan d’actions correspondant à l’aide d’un planificateur, par exemple de type PDDL. Un résultat possible d’interprétation de la commande par le modèle de langage est : (I ?user (movie-mode living-room on)) Pour obtenir un tel résultat, une possibilité est que l’ensemble de règles prédéterminées fourni dans la requête contienne une ou plusieurs règles prédéterminées spécifiant de traduire la référence au mode cinéma dans la commande par l’expression « movie-mode » dans la formule logique, ainsi que de traduire la référence au salon dans la commande par l’expression « living-room » dans la formule logique. Même si de telles règles spécifiques sont absentes, un nombre suffisant de règles prédéterminées suffisamment variées peut permettre au modèle de langage de fournir ce résultat. Le moteur de raisonnement peut être configuré pour traiter cette formule logique en appliquant une quatrième règle prédéterminée prévoyant que si l’utilisateur a l’intention d’atteindre un objectif « ?phi » et s’il existe un plan à même de satisfaire l’objectif « ?phi » alors le système à l’intention d’exécuter ce plan. La quatrième règle prédéterminée est la suivante : (I ?user ?phi) & (exists ?plan ?phi)) -> (I self (done ?plan)) La technique proposée offre de multiples avantages techniques comparativement aux systèmes et procédés connus basés exclusivement sur l’application de règles NLU prédéterminées. Notamment, la technique proposée permet à l’utilisateur de recourir de manière plus libre au langage naturel pour exprimer ses commandes. La technique proposée permet de simplifier le développement de systèmes de commandes d’équipements en s’affranchissant de la nécessité de prévoir de très nombreuses règles NLU. La technique proposée permet en outre de conserver un contrôle des commandes à mettre en œuvre par l’intermédiaire du moteur de raisonnement logique, car ce dernier peut s’appuyer sur des données stockées dans la base de données pour autoriser ou non l’exécution d’une action. Ainsi, par exemple, si la base de données possède une donnée descriptive se rapportant à l’âge de l’utilisateur, il peut décider de ne pas réaliser l’action correspondant à son intention d’allumer le four. Un autre avantage de la technique proposée est qu’il n’impose pas de communiquer au modèle de langage, le contenu, en termes de code, des actions qu’il est possible de réaliser. Cet avantage et celui exprimé précédemment offrent de solides garanties de sécurité. Un autre avantage de la technique proposée est qu’il permet, grâce au moteur de raisonnement logique, en combinant les commandes exprimées en langage naturel par l’utilisateur avec d’autres types d’interactions (tactiles, haptiques, …), de mettre en œuvre des interactions multimodales. Ainsi, par exemple, si l’utilisateur dit « allume cette lampe » et si le système dispose, par ailleurs, d’une connaissance quant à l’objet désigné par l’utilisateur, alors il peut envoyer cette connaissance au modèle de langage, qui produit alors une formule logique reflétant fidèlement l’intention correspondante. Un autre avantage de la technique proposée est la possibilité de mettre en œuvre via le moteur de raisonnement un moteur de planification afin d’exécuter non pas une action mais un plan d’actions pour satisfaire l’intention de l’utilisateur. Procédé de conversion d'une commande, exprimée au moins en partie en langage naturel et concernant un état d’un équipement, en une instruction logique, le procédé comprenant une obtention (310) de l’instruction logique par l'intermédiaire d'un interpréteur (104) de ladite commande sollicitant (308) un modèle de langage (106) avec une requête comprenant la commande et un ensemble de règles d’interprétation comprenant uniquement des premières règles d’interprétation, l’instruction logique étant conforme à ce que produirait une interprétation de la commande par application d’une deuxième règle d’interprétation dérivable à partir de l’ensemble de premières règles, la deuxième règle d’interprétation étant distincte des premières règles d’interprétation. Procédé selon la revendication 1, dans lequel l’instruction logique est adaptée pour entraîner un changement d’état de l’équipement d’un état actuel vers un état souhaité lorsque l’instruction logique est exécutée par un moteur de raisonnement logique (112). Procédé selon la revendication 1 ou 2, dans lequel l’instruction logique est adaptée pour entraîner une transmission d’un signal spécifiant l’état actuel lorsque l’instruction logique est exécutée par un moteur de raisonnement logique (112). Procédé selon l’une des revendications 1 à 3, dans lequel l’ensemble de premières règles contient une règle relative à une désignation de l’équipement et une règle relative à une désignation de l’état souhaité. Procédé selon l’une des revendications 1 à 4, dans lequel la requête comprend en outre une donnée descriptive de l’état actuel de l’équipement. Procédé selon l’une des revendications 1 à 5, comprenant en outre une transmission (312) de l’instruction logique à un moteur de raisonnement logique (112) pour une exécution de l’instruction logique. Programme d’ordinateur comprenant des instructions qui, lorsque le programme est mis en œuvre par un processeur (202), conduisent à mettre en œuvre le procédé selon l’une des revendications 1 à 6. Support d’enregistrement non transitoire (204) lisible par un ordinateur sur lequel est enregistré le programme informatique selon la revendication 7. Interpréteur (104) d’une commande, exprimée au moins en partie en langage naturel et concernant un état d’un équipement, en une instruction logique, l’interpréteur étant configuré pour obtenir (310) l’instruction logique en sollicitant (308) un modèle de langage (106) avec une requête comprenant la commande et un ensemble de règles d’interprétation comprenant uniquement des premières règles d’interprétation, l’instruction logique étant conforme à ce que produirait une interprétation de la commande par application d’une deuxième règle d’interprétation dérivable à partir de l’ensemble de premières règles, la deuxième règle d’interprétation étant distincte des premières règles d’interprétation.