FR 3155921 A1 20250530 FR 2313090 A 20231127 La présente description concerne une assistance mise en œuvre par un dispositif informatique, comportant : - établir un graphe sémantique courant d’un texte obtenu à partir d’un message courant (S34), de demande d’assistance que reçoit ledit dispositif informatique, - rechercher, dans une base de données (BDD) de connaissances métier répertoriant des étapes de processus en correspondance de graphes sémantiques, au moins un graphe similaire au graphe sémantique courant (S36), pour identifier une étape de processus (S37) correspondant au message courant, et - générer un signal (SIG) comprenant des données de recommandations (S39) relatives au moins à l’étape identifiée. Figure de l’abrégé : Figure 3 Assistance d’un utilisateur par analyse de graphe sémantique La présente description concerne un traitement de données intervenant dans des applications informatiques, notamment mais non limitativement dans des applications bureautiques. Dans le cadre de « l’entreprise digitale », les processus sur lesquels des utilisateurs travaillent, ou auxquels ces utilisateurs contribuent, requièrent plusieurs applications informatiques et de nombreuses personnes intervenantes pour avancer dans le temps : client, opérateur, équipe support, partenaire, systèmes vocaux ou tchat. L’expérience est la somme des essais / erreurs ou essais / réussites pour atteindre un objectif. Pour un utilisateur donné, l’expérience permet de faire avancer un « processus » et tient donc compte de sa sensibilité et de son historique d’intervention sur un tel processus. Lorsqu’un utilisateur est sollicité pour intervenir sur une partie spécifique du processus et amené à interagir avec une tierce personne ou système (via échange vocal, tchat ou mail), l’utilisateur n’a pas conscience de ce qui a été réalisé d’équivalent lors de l’exécution d’autres instances du même processus et quelles ont été les connaissances métiers utiles des personnes ayant un rôle similaire à celui de l’utilisateur et de l’impact, positif ou négatif, de l’exploitation de ces connaissances. L’utilisateur n’a en général accès qu’à l’historique de l’instance courante du processus et qu’à ses propres expériences. Les retours d’expérience et leur exploitation se font souvent difficilement et après quelques temps. Or, il est important d’exploiter ces retours d’expérience et notamment ceux des différents acteurs. Pour collecter des retours d’expériences, il est possible de s’adresser naturellement aux autres acteurs métiers afin de leur poser des questions concernant une situation/problématique courante afin de déterminer s’ils ont vécu une situation analogue ou s’ils recommandent d’autres acteurs métiers à consulter. Cependant, ce moyen de recherche de l’information peut être coûteux en termes de temps et peut être inefficace si un acteur métier dispose d’un réseau de contacts restreint. Résumé La présente divulgation vient améliorer la situation. Il est proposé un procédé d’assistance mis en œuvre par un dispositif informatique, comportant : - établir un graphe sémantique courant d’un texte obtenu à partir d’un message courant, de demande d’assistance que reçoit ledit dispositif informatique, - rechercher, dans une base de données de connaissances métier répertoriant des étapes de processus en correspondance de graphes sémantiques, au moins un graphe similaire au graphe sémantique courant, pour identifier une étape de processus correspondant au message courant, - générer un signal comprenant des données de recommandations relatives au moins à l’étape identifiée. On entend par « processus » un ensemble d’étapes devant être réalisées, par exemple par un utilisateur dans un cadre professionnel. Les étapes d’un processus peuvent par exemple s’enchaîner selon une succession d’étapes. Il est alors proposé de fournir des recommandations pertinentes à un utilisateur sur un processus en cours, et notamment sur une étape à réaliser dans ce processus et éventuellement sur une ou plusieurs étapes qui suivent l’étape à réaliser (pour guider l’utilisateur dans le fil de la réalisation du processus). Ces recommandations peuvent être pertinentes grâce notamment : - à la richesse (en termes de nombre et/ou de diversité d’éléments par exemple), voire l’exhaustivité, de la base de données, d’une part, et - à la recherche de similarité(s) entre le graphe courant et les graphes de la base de données, d’autre part. Dans au moins une réalisation, des scores de similarité avec le graphe sémantique courant peuvent être estimés pour une partie au moins des graphes de la base de données, pour rechercher au moins un graphe ayant le meilleur score de similarité. Le signal généré peut alors comprendre des données de recommandations relatives au moins à l’étape identifiée comme correspondant au graphe ayant le meilleur score de similarité précité, par exemple. Par exemple, la mesure de similarité peut s'effectuer par rapport à des nœuds et/ou des arêtes et/ou une structure de graphes. Dans au moins une réalisation, il est recherché dans la base de données une pluralité de graphes ayant de meilleurs scores de similarité, et le procédé comporte en outre une estimation d’un score d’efficacité pour respecter des règles métier, ce score d’efficacité pouvant être affecté à une partie au moins des graphes de la pluralité de graphes précitée. Dans au moins une réalisation où la base de données contient des données de recommandations associées à chaque graphe de la base, une telle réalisation peut permettre par exemple d’ordonner une liste des recommandations respectivement associées aux graphes, en fonction de leurs scores d’efficacité. Ainsi, dans une telle réalisation, le procédé peut comporter un ordonnancement de données de recommandations associées aux graphes de la pluralité précitée de graphes, en fonction des scores respectifs d’efficacité affectés aux graphes de la pluralité de graphes. Ainsi, le signal généré peut comprendre les données de recommandations ordonnancées selon ces scores d’efficacité. Pour la construction du corpus de graphes de la base de données, on peut prévoir, dans une réalisation, un stockage de données du graphe courant dans la base de données si le meilleur score de similarité est associé à une similarité inférieure à une similarité associée à une première valeur de score de similarité. Par exemple, si les scores de similarité sont croissants avec la similarité, alors le stockage des données du graphe courant intervient si son score de similarité est inférieur à la première valeur précitée. Par exemple, cette première valeur peut être une valeur seuil, qui peut être fixe ou variable en fonction par exemple d’un nombre de graphes déjà stockés pour le même processus dans la base de données. Ainsi, dans une telle réalisation, il est choisi de sauvegarder le graphe courant en le rattachant à une étape en cours (l’étape identifiée, précitée) si ce graphe est suffisamment différent des autres graphes de la base, également rattachés à la même étape. Si aucun graphe de la base n'est similaire au graphe courant au-delà de la première valeur précitée (avec des scores croissant en fonction de la similarité), alors les informations que comporte le graphe courant sont nouvelles et il convient de les sauvegarder dans la base. Sinon (scores de similarité au-delà de la première valeur), il est possible de créer simplement un lien qui persiste l’information apportée par le graphe courant dans la base. Ce lien peut être une association entre un identifiant d’instance du processus en cours, un identifiant d’étape et un identifiant de graphe le plus similaire dans la base. De manière générale, les données d’un graphe de la base peuvent par exemple être référencées en correspondance d’un identifiant d’instance et un identifiant d’étape, par exemple. On entend par « instance de processus » typiquement une réalisation effective du processus. La réalisation précitée, visant à stocker des graphes qui « diffèrent » de ceux stockés dans la base, peut aider à répertorier toutes les idées échangées dans les messages, donc toutes les expériences, afin de participer à offrir une grande variété de solutions possibles à l’utilisateur. Si le graphe correspondant est différent des graphes de la base de données, il est privilégié la sauvegarde de ce graphe dans la base avec ses spécificités. Si le graphe est similaire aux autres graphes, on enregistre un lien de l'instance du processus en cours avec le graphe similaire de la base. Ainsi, on peut limiter les duplications inutiles des informations métier qui peuvent être pertinentes. Dans au moins une réalisation, le signal généré peut comprendre des données de recommandations relatives au moins à une étape qui suit l’étape identifiée dans le processus de l’étape identifiée. Une telle réalisation peut aider l’utilisateur à visualiser la suite des étapes du processus et organiser ainsi sa propre réalisation de l’étape en cours. Dans au moins une réalisation, la génération du signal comprenant les données de recommandations peut être déclenchée au moins en fonction d’une humeur détectée dans le message courant. Dans au moins une réalisation, la génération du signal comprenant les données de recommandations peut être déclenchée au moins sur détection d’une forme interrogative, propre à une question, dans le message courant. Par exemple, si une forme interrogative est détectée et/ou si l’humeur détectée dans le message (au-delà d’un seuil par exemple) est de la peur et/ou de la colère et/ou tristesse, alors un ordinateur de travail de l’utilisateur, exécutant le procédé ci-avant, peut proposer spontanément à l’utilisateur une assistance en lui indiquant (par exemple dans une fenêtre « popup » s’affichant sur un écran de travail connecté à l’ordinateur) que des recommandations pour exécuter l’étape objet de son message sont disponibles. Si l’utilisateur clique sur la fenêtre par exemple, alors l’ordinateur peut par exemple piloter l’affichage sur l’écran d’une page de recommandations pour réaliser l’étape du processus en cours. L’estimation de similarité du graphe courant par rapport aux graphes de la base de données (et son stockage éventuel dans la base) peut, en revanche, correspondre à une tâche de fond, exécutée en permanence par l’ordinateur précité, sans nécessiter une intervention particulière de l’utilisateur. Dans au moins une réalisation, le procédé peut comporter en outre, préalablement à l’établissement du graphe sémantique courant, une structuration des données de texte que comporte le message courant. Une telle réalisation peut aider notamment à filtrer des graphes de la base de données similaires au graphe courant. Cette structuration de données attachées aux étapes d'un processus vise un traitement dit de « Process Mining ». En rattachant un graphe courant à une étape donnée, si la mesure de similarité révèle que de nombreux graphes de la base sont attachés à la même étape A, le process mining peut aider à identifier en outre une autre caractéristique dans le message qui peut être par exemple une zone géographique particulière. Ainsi, il peut être possible de filtrer les graphes attachés à l'étape A d'une part et qui ont la même valeur 'zone géographique' d'autre part. Il peut être possible ensuite de mesurer à nouveau la similarité sémantique des graphes ainsi filtrés avec le graphe courant. Il s’agit alors d’une optimisation possible pour identifier les graphes et contextes similaires, afin de de suggérer de meilleures actions (ou tout au moins des actions pertinentes) à un utilisateur. Dans au moins une réalisation, le message courant peut être un message vocal, et le procédé peut comporter une transcription du message vocal en données de texte, avant l’établissement du graphe sémantique courant. La présente description vise aussi un dispositif informatique comportant un circuit de traitement pour la mise en œuvre du procédé selon les présentes. Selon un autre aspect, il est proposé un programme informatique comportant des instructions pour la mise en œuvre de tout ou partie d’un procédé tel que défini dans les présentes lorsque ce programme est exécuté par un processeur. Selon un autre aspect, il est proposé un support d’enregistrement non transitoire, lisible par un ordinateur, sur lequel est enregistré un tel programme. 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 montre un exemple de traitement d’un message selon un mode de réalisation. Fig. 2 FIG. 2 montre un exemple de recherche de similarité entre graphes sémantiques selon un mode de réalisation. Fig. 3 FIG. 3 montre un exemple de procédé pour traiter un message et mettre à jour une base de données BDD stockant un corpus de graphes sémantiques selon un mode de réalisation. Fig. 4 FIG. 4 montre un exemple d’un dispositif pour la mise en œuvre du procédé de la FIG. 3 , selon un mode de réalisation. Dans une réalisation, le procédé exposé ci-après propose une combinaison des techniques informatiques dites de « Process Mining » et de représentation par graphes sémantiques telle que par exemple la représentation « AMR » (pour « Abstract Meaning Representation ») pour déterminer des retours d’expérience de l’utilisateur et possiblement d’autres acteurs en lien avec une situation courante, afin d’améliorer la conduite d’un processus utilisant une pluralité d’applications informatiques, notamment bureautiques. Le « Process Mining » est utilisé pour identifier les étapes de processus très proches d’une étape en cours d’exécution (dans le cadre d’une application par exemple) avec leurs caractéristiques et/ou leur indice d’efficacité selon des critères choisis (par exemple des indicateurs clés de performance ou « KPI » d’une entreprise). La technique d’AMR reposant sur des graphes de représentation sémantique est utilisée pour modéliser les échanges d’informations en cours et les faire persister à différentes étapes du processus pour compléter un moteur d’expériences. Il est ainsi possible par exemple de réaliser des comparaisons de graphes inter-instances de processus par la suite (et ce, dans une même application informatique ou dans différentes applications informatiques). Le procédé précité met en œuvre un traitement de données des applications en cours d’exécution pour proposer à un utilisateur courant de ces applications des recommandations de résolution de problème et/ou d’optimisation de la manière de réaliser une étape de processus. De telles recommandations peuvent être fournies notamment lors d’un échange vocal ou textuel de l’utilisateur avec un autre utilisateur ou un agent de type chatbot ou autre. A cet effet, le procédé s’appuie sur un ensemble d’expériences antérieures de l’utilisateur courant et d’autres utilisateurs, en suggérant l’affichage de données de connaissances métiers sur le processus en cours et tenant compte de critères comme notamment des objectifs d’une entreprise employant l’utilisateur courant (par exemple un indice de satisfaction client, une réduction de coûts, une réduction de bilan carbone, un indice de satisfaction d’un salarié, ou autres éléments de stratégie d'une entreprise). Dans un premier exemple, l’utilisateur courant peut recevoir un appel vocal en lien avec l’exécution d’une étape de processus (dans le cadre d’une exécution d’une ou plusieurs applications informatiques). La conversation pendant l’appel vocal est alors transcrite et le module AMR synthétise la conversation en cours sous forme de graphe. D’une part, l’analyse du graphe permet d’identifier un questionnement ou un problème à résoudre dans la conversation. D’autre part, d’autres applications, telles qu’un composant dit « d’analyse de sentiment », peuvent par exemple détecter un mécontentement d’au moins un des interlocuteurs. Ainsi, au moins un composant d’analyse de graphe AMR (éventuellement en combinaison avec un autre composant tel qu’un analyseur de sentiment) peut déclencher l’exécution d’un moteur d’expérience (si par exemple un indice de questionnement et/ou un indice de mécontentement sont supérieurs à un seuil). Une mise en œuvre possible du procédé peut s’appuyer ainsi sur un tel composant d’analyse de sentiment qui, sur détection d’un sentiment négatif, active le déclenchement du moteur d’expérience. Le moteur d’expérience filtre les instances de processus similaires (par exemple celles ayant le même chemin d’opérations jusqu’à une opération en cours) et prend en compte le graphe AMR pour le comparer avec d’autres graphes AMR présents dans la base d’expériences. Par exemple, il est possible de rechercher des processus ayant des portions similaires, avec des enchainements identiques au niveau des étapes et des actions réalisées. Un signal de sortie peut alors comporter des données de connaissances métier associées au processus et notamment à une opération courante du processus. Ces éléments peuvent être sélectionnés en fonction de leur indice d’efficacité (notamment en fonction du nombre d’échantillons de situations similaires et de l’efficacité de la recommandation donnée dans lesdites situations similaires). Dans un deuxième exemple, l’utilisateur courant peut recevoir un appel vocal d’une personne en lien avec l’exécution d’une étape de processus et la conversation est transcrite. Le module AMR synthétise la conversation sous forme de graphe. L’analyse du graphe permet de filtrer et de ne conserver que les branches en lien avec une connaissance métier associée à l’activité en cours. Le moteur d’expérience conserve alors en mémoire le graphe lié à l’instance du processus, même après la fin du processus, ce qui est nommé ci-après une « persistance du graphe à l’instance du processus ». Par ailleurs, on entend ici par « instance » la réalisation effective d'un processus (ou d’une partie tout au moins de ce processus). Ainsi, chaque mise en œuvre particulière du processus est une instance du processus. Chaque instance a donc les mêmes étapes (ou un sous-ensemble de ces étapes) que le processus lui-même. En effet, le processus global peut être défini par une succession de plusieurs étapes, selon une notion ainsi plus globale qu’une étape isolée. Un exemple de processus peut ainsi être le « raccordement à la fibre », contenant un certain nombre d’étapes distinctes. Une instance de ce processus exprime typiquement le raccordement d'une personne en particulier qui a suivi les étapes dans un ordre qui lui est propre. Le procédé décrit ici peut délivrer ainsi des recommandations aux utilisateurs, opérateurs ou assistants techniques de processus. Il peut aussi leur offrir une visibilité sur les chemins possibles de réalisation du processus. Il convient de noter que ces recommandations peuvent être proposées à des utilisateurs courants, humains, ou à des opérateurs robots de type chatbot ou autres. Le procédé peut permettre ainsi une prise en compte, en temps réel ou quasi-réel, de solutions issues d’expériences similaires ayant un bon indice d’efficacité, grâce notamment à l’analyse de graphes AMR dans une conversation. Il est détaillé ci-après le fonctionnement du moteur d’expériences précité dans certains modes de réalisation. Ce moteur agrège l’ensemble des ‘expériences’ sur un même processus. Pour assurer le fonctionnement de ce moteur, il peut être prévu deux composants principaux : - Un premier composant responsable d’une collecte au fil de l’eau des données significatives d’expériences des acteurs métiers du même processus, et - Un deuxième composant délivrant des suggestions de connaissances métier (ou « recommandations » ci-après) pour une opération donnée du processus, ces connaissances métier ayant le meilleur indice d’efficacité. Pour la mise en œuvre du premier composant, les données d’expériences métier sont collectées sous format de deux types : - des données audio et/ou textuelles reflétant un échange entre acteurs métiers et captant une expertise métier exprimée dans l’échange, et - des données d’analyse d’exécution des processus métier relatives à l’expérience des acteurs métier en termes de séquencement et enchainement de réalisation des opérations dudit processus. Le premier composant peut avoir comme objectif de stocker ces expériences sous un format spécifique dans une base d’expériences ayant une structure facilitant leur requêtage : en exploitant le modèle spécifique du process mining précité et une représentation sémantique de type AMR. Le deuxième composant précité, quant à lui, peut filtrer les données d’expériences ayant le même chemin jusqu’à l’étape en cours du processus (par exemple l’Etape 1 de la FIG. 2 commentée plus loin). Le deuxième composant identifie les chemins ‘futurs’ possibles, par exemple ceux satisfaisant à certains critères, comme dans l’exemple de la FIG. 2 ceux ayant un bon indice d’efficacité (Etape 2 – FIG. 2 ). Le deuxième composant analyse les graphes AMR des expériences associées pour comparaison avec le graphe en cours afin d’identifier des connaissances non présentes dans le graphe en cours et de proposer ces connaissances non présentes à l’utilisateur courant (Etape 4 et 5 – FIG. 2 ). Par ailleurs, une étape (Etape 0) de construction de la base de données des connaissances, incluant des données de graphes sémantiques, est prévue d’être menée avant et/ou en parallèle des étapes 1 à 4 (en tâche de fond continue par exemple). Dans ce qui suit, on détaille chaque composant. Pour le premier composant réalisant la collecte au fil de l’eau, il est prévu, dans cet exemple de réalisation, la mise en œuvre d’au moins quatre étapes (illustrées à titre d’exemple sur la FIG. 1 ). La première étape vise à collecter les données issues des échanges entre les acteurs métiers (étapes 1 et 1’ de la FIG. 1 ). Ces données peuvent être sous format audio (par exemple des données d’enregistrement d’un appel téléphonique) et/ou sous format textuel (données de caractères dans un email, tchat, ou autre) par exemple. Lors d’une deuxième étape 2, les données audios sont transcrites sous format textuel. La troisième étape 3 génère, à partir du format textuel d’un échange, un graphe AMR qui résume l’échange (étape 3, FIG. 1 ). Par exemple, chaque échange « collecté » peut ainsi être transmis sous forme AMR. On rappelle qu’un graphe AMR est destiné à s'abstraire des représentations syntaxiques, en ce sens que les phrases dont le sens est similaire se voient attribuer le même graphe AMR, même si elles ne sont pas formulées de manière identique. Un composant d’analyse AMR peut typiquement repérer des mots d’une phrase pour les définir en tant que nœuds du graphe, pour leur assigner des valeurs respectives appelées « arguments » (par exemple ARG0, ARG1, etc., dans l’exemple de graphe AMR ci-dessous). Par exemple, les phrases suivantes sont identifiées dans une conversation : # ::snt Pour étendre le réseau, il y a plusieurs possibilités. Avez-vous pensé à utiliser le courant porteur ? Le graphe AMR correspondant s’écrit alors : (m / multi-sentence …:snt1 (ii / intend-01 ………:ARG0 (w / we) ………:ARG1 (r / regard-01 ………………:ARG0 w ………………:ARG1 (r2 / réseau))) …:snt2 (p / possible-01 …...…:ARG1 (u / utilize-01 ……….……:ARG0 (y / you) …………….:ARG1 (p2 / porteur ………………..:mod (c / courant))) ………:mod (p3 / plus-ieur)) ….:snt3 (t / think-01 ……....:ARG0 (y2 / you) ……...:ARG1 (u2 / use-01 ………………:ARG0 y2 ………………:ARG1 p2))) Comme illustré en FIG. 1 , le procédé peut comprendre (Etape 4 – FIG. 1 ) un attachement du graphe à une étape de processus en cours, par l’identification de graphes similaires. Il peut comprendre notamment une analyse du graphe obtenu pour l’échange courant pour le comparer à des graphes existants. Par exemple, des scores de similarité d’un graphe courant (pour l’étape courante d’un processus métier) avec des graphes de référence de ce processus métier peuvent être calculés. Par exemple, le ou les graphes de référence ayant un (ou des) score(s) de similarité élevé(s) relativement au graphe en cours peut indiquer l’étape de processus faisant l’objet du message d’un utilisateur. La détermination de similarité et l’estimation d’un score de similarité entre graphes sémantiques, par exemple de type AMR, par rapport à des nœuds et/ou des arêtes et/ou une structure de graphes, peuvent être mises en œuvre de différentes façons selon les modes de réalisation. Par exemple, elles peuvent être mises en œuvre de façon similaire à ce qui est décrit dans ce document : « AMR Similarity Metrics from Principles », de Juri Opitz, Letitia Parcalabescu, et Anette Frank, dans Transactions of the Association for Computational Linguistics (Sept. 2020) 8 : pp 522–538. Par exemple, l’étape d’un processus en cours peut être identifiée dans un échange de messages entre deux acteurs métier, en fonction du meilleur score de similarité entre : - le graphe AMR courant, tiré des messages échangés, et - des graphes AMR de référence, répertoriés dans une base de données dans laquelle chaque graphe AMR est propre à une étape de processus. Cette base de données peut être construite en définissant, pour chaque étape de processus, un graphe AMR qui peut être assez exhaustif (le plus exhaustif possible par exemple), pour caractériser cette étape de processus par similarité avec un graphe AMR courant (par exemple pour la caractériser avec un score élevé de similarité avec un graphe AMR courant). Dans une telle réalisation, un opérateur humain par exemple peut définir des questions/réponses appropriées (et par exemple exhaustives) permettant de définir l’étape de processus correspondante. Dans une réalisation décrite ci-après, la base de données précitée est construite au fil de l’eau, au gré des interactions entre des acteurs métier. Les graphes AMR de référence sont alors stockés dans la base de données selon le principe précité de « persistance de graphes ». Le déclenchement de cette persistance peut être la variabilité du graphe courant. Par exemple, si un graphe similaire est présent dans la base de données, alors on peut lui ajouter des références d’instance (instance ID), d’étape (étape ID) et de graphe (graphe ID). On peut alors retrouver les instances qui ont exploité les mêmes graphes, tout en conservant ainsi autant d’informations métier que possible. Ainsi, une étape de processus peut avoir plusieurs graphes de référence et il est possible de traiter une étape de processus selon différentes dimensions et différents degrés de granularité de graphes de référence. La base de données des graphes de référence peut alors être exhaustive et en particulier représentative de la variabilité des solutions, actions, réponses apportées par les opérateurs. Par exemple, un ensemble de graphes sémantiques référant à un ensemble d’échanges qui se sont déroulés pour réaliser une même instance de processus peut être stocké dans la base de données pour une même instance. Les différents ensembles de graphes de référence peuvent être répertoriés notamment en fonction d’un identifiant d’instance (instance ID), par exemple. Par ailleurs, des scores d’efficacité propres à chaque étape de processus peuvent être affectés, par exemple en fonction de l’importance de cette étape dans le processus, en fonction des règles métier dont cette étape tient compte, etc. Ainsi, un mode de réalisation de la présente description peut aller plus loin qu’une simple estimation de score de similarité entre graphes AMR. Dans l’exemple illustré sur la FIG. 2 , le graphe sémantique de référence ayant le meilleur score de similarité est celui lié à l’étape B du processus identifié (illustré en grisé). Néanmoins, il peut être estimé en outre, comme décrit ci-avant, un score d’efficacité d’une étape donnée d’un processus. Typiquement, dans l’exemple de la FIG. 2 , s’il est estimé que plusieurs recommandations qui peuvent être données à l’utilisateur sur les étapes A et B ont des scores d’efficacité similaires de 0.8, relativement au processus en cours, alors deux recommandations concernant les étapes A et B peuvent être données à l’utilisateur. Ces scores d’efficacité sont construits à partir d’indices d’efficacité qui peuvent être fonction des caractéristiques de l’étape et d’objectifs métiers donnés (tels que par exemple la sécurité des équipes d’intervention, la satisfaction client, le bilan carbone, etc.). Ces scores d’efficacité peuvent ainsi pondérer des scores de similarité de graphes de référence d’un même processus pour proposer à l’utilisateur des informations pertinentes sur une ou plusieurs étapes du processus. Ces scores d’efficacité (ou « d’indices de performance ») peuvent être calculés à la volée pour un message courant à traiter et, dans un exemple de réalisation, ils peuvent ne pas être persistés dans les graphes de la base de données, afin de prendre en compte de façon dynamique d’éventuelles nouvelles règles qui définissent la « performance » précitée. La FIG. 3 illustre un exemple de succession d’étapes selon un procédé au sens de la description. Lors d'une première étape S31, un message MESS échangé entre des acteurs métier est traité. Un premier traitement du message peut comporter par exemple une retranscription en données de texte s’il s’agit d’un message audio. Le traitement S31 peut comprendre en outre, par exemple : - une recherche d’une forme interrogative dans le message pour interpréter le message comme une question posée (destinée à un autre acteur par exemple), et/ou - une identification d’émotion dans le message (par exemple de la peur, de la colère ou de la tristesse, caractérisant un stress de l’utilisateur). Dans l’un et/ou l’autre de ces cas, le moteur de recommandations peut interpréter le message MESS comme nécessitant une recommandation, avec la mise en œuvre des étapes suivantes décrites ci-après. Typiquement, le message MESS peut être traité en outre pour être représenté par des données structurées à l’étape S32. Cette étape S32 peut par exemple comprendre une identification de mots clés dans les données de texte (à la manière d’un moteur de recherche) pour filtrer à l’étape S33 les messages non pertinents, typiquement qui ne sont pas en lien avec un processus métier potentiel. Si des mots-clés de ce message sont identifiés comme étant potentiellement liés à un processus métier (flèche ok en sortie du test S33), le graphe sémantique courant de ce message est construit à l’étape S34, à partir des données de texte du message (non nécessairement sous forme structurée). A l’étape S35, le corpus des graphes AMR de référence relatifs à toutes les étapes de processus (ou possiblement à une partie des instances de processus s’il est tenu compte de mots-clés particuliers dans le message à l’étape S33) est recherché dans la base de données BDD, afin d’estimer un score de similarité de chacun de ces graphes de référence avec le graphe courant obtenu à l’étape S34. A l’étape S36, le graphe de référence ayant le meilleur score de similarité est retenu. Alternativement, il est possible de retenir un nombre N choisi de graphes de référence ayant les N meilleurs scores de similarité avec le graphe courant. Ces graphes de référence sont réputés être rattachés à la même étape de processus, d’après leur score de similarité avec le graphe courant. Ils peuvent indiquer ainsi une instance du processus directement en lien avec le message traité (étape S37). Par exemple, il est possible de rechercher les graphes rattachés à l’étape en cours et éventuellement aux étapes suivantes du processus et de calculer à l’étape S38 les indices de performance associés pour donner à l'utilisateur une liste de recommandations, ordonnée selon ces estimations d’indices de performance (étape S39). Ainsi, l’utilisateur est guidé dans ces recommandations et peut même visualiser le chemin que peut prendre le processus par la suite, selon l’orientation choisie. Ces recommandations sont ainsi : - d’une part, en lien avec le message formulé à l’étape initiale S31, et - d’autre part, apportent, du contenu informatif pertinent par rapport à des règles métier et/ou des connaissances métier prédéfinies. De tels modes de réalisation peuvent donc aider à proposer à l’utilisateur des recommandations pertinentes par rapport à son activité courante. A l’étape S40, il peut être évalué l’intérêt de stocker le graphe sémantique du message courant en tant que graphe de référence de la base de données BDD. Par exemple, il peut être prévu de stocker ce graphe courant si le message associé exprime notamment une variation d'expérience, et/ou des idées données, par rapport aux autres graphes de référence similaires. Dans un tel cas par exemple, la persistance peut être déclenchée pour un stockage dans la base de données BDD. Par ailleurs, si l'expérience sous la forme du graphe courant est déjà présente dans la base de données, on peut créer une relation entre instance et graphe pour éviter de faire grossir le nombre de données à stocker dans la base BDD. On peut se baser encore sur un calcul de similarité pour décider de la persistance d'un graphe dans la base BDD. Si le score de similarité est très proche d'un autre graphe de référence attaché à une même étape, il peut être décidé de ne pas avoir besoin de stocker le graphe courant dans la base et de faire persister juste le lien entre l’instance du processus, l’étape identifiée et le graphe de référence. Les messages échangés par un utilisateur peuvent être suivis pour déterminer s’il a pu progresser dans la réalisation des étapes du processus. Ainsi, le moteur de recommandations peut suivre les mises en œuvre des processus par les utilisateurs, et donc les évolutions des échanges au fil de ces mises en œuvre. Les graphes sémantiques peuvent être mis à jour, au fil de l’eau, dans la base de données BDD, pour conserver les informations sur l'exécution d’un processus et ainsi permettre une capitalisation sur d'autres instances de ce processus. Ainsi, un moteur de recommandations de « connaissances métier » vise à suggérer des connaissances métiers à des acteur métiers lors de leurs interactions avec d’autres acteurs afin d’aider à améliorer l’efficacité de ces interactions (pour aider par exemple à les optimiser). Ce moteur peut exploiter au fil de l’eau (en temps réel) : - des données d’un état d’avancement d’une instance de processus sur laquelle travaillent ces acteurs, - des données d’autres instances en cours ou terminées, - des données d’échanges de messages ou de conversations audios transcrites en texte, ces données étant « structurées » dans un premier temps pour pouvoir filtrer les échanges non pertinents (S33) et qui ne sont pas en lien avec un processus, ces données n’étant pas nécessairement ensuite « structurées » pour l’établissement des graphes sémantiques (S34, S40), et - des données pour l’estimation d’indices d’efficacité rattachés aux instances de processus. Dans le mode de réalisation de la FIG. 3 , le moteur de recommandations peut par exemple présenter les expériences selon leur indice d’efficacité (étape S39). Le moteur peut présenter des graphes sémantiques de référence (ou ensembles de prédicats), qui sont pertinents par rapport à des processus métier concrets en lien avec le graphe de l’échange en cours (conversation audio et/ou écrite). Le moteur peut réaliser en particulier un ordonnancement des recommandations en fonction de leur score d’efficacité pour proposer à l’utilisateur des connaissances métier associées selon un ordre de présentation pertinent. Ces connaissances métier peuvent présenter par exemple des prédicats qui ne sont pas présents dans la conversation en cours et qui peuvent suggérer à l’utilisateur de nouvelles idées. Les indices d’efficacité peuvent être estimés en fonction de coefficients correspondant à des objectifs d’une entreprise, tels que la durabilité, la satisfaction client, la satisfaction du salarié, etc. Par exemple, si dans un prédicat du graphe illustrant l’une des recommandations possibles, il est question d’un remplacement de matériel par un équipement recyclé, une pondération élevée (par exemple de 1) peut être affectée au coefficient relatif à la durabilité. Ainsi, un indice de performance élevé peut être estimé pour cette recommandation. De même, si dans un prédicat il est question de changement d’une pièce de l’équipement sans remplacement complet de l’équipement, une pondération élevée peut être retenue. Si dans un prédicat du graphe de recommandation, il est question d’un suivi personnalisé d’un problème à traiter ou d’une analyse d’un sentiment positif d’un client dans une conversation, une pondération élevée peut être affectée au coefficient relatif à la satisfaction client, etc. Si la stratégie de l’entreprise privilégie la durabilité par rapport à d’autres objectifs, la pondération de ce coefficient de durabilité peut avoir une valeur plus importante. Par ailleurs, ces recommandations peuvent concerner l’étape en cours à exécuter mais aussi des étapes suivantes. Ainsi, il peut être recherché dans la base de données BDD une similarité jusqu'à l'étape courante et ensuite rechercher des graphes à une ou plusieurs étapes suivantes pour suggérer des actions susceptibles de faire avancer le processus globalement. Un tel procédé peut être exécuté par un processeur PROC ( FIG. 4 ) coopérant avec une mémoire de travail MEM et avec une interface INT d’accès à la base de données BDD, typiquement d’un circuit de traitement CT d’un dispositif informatique tel qu’un poste de travail (ordinateur, tablette, ou autre) par exemple à disposition de téléconseillers ou de membres d’équipes support de processus métier, par exemple sur des plateaux d’assistance technique virtualisés ou autres. Le circuit de traitement précité CT comporte alors en outre une interface de sortie OUT pilotée par le processeur PROC pour générer un signal SIG (un signal visuel sur un écran ECR et/ou un signal audio sur un haut-parleur HP, l’écran et le haut-parleur reliés à l’interface de sortie OUT). Ce signal SIG comprend alors des données de recommandations pertinentes, relatives à l’étape identifiée (étape S37), ou plus globalement au processus dont l’étape a été identifiée. Procédé d’assistance mis en œuvre par un dispositif informatique, comportant : - établir un graphe sémantique courant d’un texte obtenu à partir d’un message courant (S34), de demande d’assistance que reçoit ledit dispositif informatique, - rechercher, dans une base de données (BDD) de connaissances métier répertoriant des étapes de processus en correspondance de graphes sémantiques, au moins un graphe similaire au graphe sémantique courant (S36), pour identifier une étape de processus (S37) correspondant au message courant, - générer un signal (SIG) comprenant des données de recommandations (S39) relatives au moins à l’étape identifiée. Procédé selon la revendication 1, dans lequel des scores de similarité avec le graphe sémantique courant sont estimés pour une partie au moins des graphes de la base de données, pour rechercher au moins un graphe ayant le meilleur score de similarité (S36), et dans lequel le signal généré comprend des données de recommandations relatives au moins à l’étape identifiée comme correspondant au graphe ayant ledit meilleur score de similarité. Procédé selon l'une des revendications précédentes, dans lequel il est recherché dans la base de données une pluralité de graphes ayant de meilleurs scores de similarité (S36), le procédé comportant en outre une estimation d’un score d’efficacité pour respecter des règles métier, affecté à chacun des graphes de ladite pluralité de graphes. Procédé selon la revendication 3, comportant un ordonnancement de données de recommandations associées aux graphes de ladite pluralité de graphes, en fonction des scores respectifs d’efficacité affectés aux graphes de la pluralité de graphes, le signal généré comprenant les données de recommandations ordonnancées selon lesdits scores d’efficacité. Procédé selon l'une des revendications 2 à 4, comportant un stockage de données du graphe courant dans la base de données (BDD) si le meilleur score de similarité est associé à une similarité inférieure à une similarité associée à une première valeur de score de similarité. Procédé selon l'une des revendications précédentes, dans lequel le signal généré comprend des données de recommandations (S39) relatives au moins à une étape qui suit l’étape identifiée dans le processus dont l’étape est identifiée. Procédé selon l'une des revendications précédentes, dans lequel la génération du signal (SIG) comprenant les données de recommandations (S39) est déclenchée au moins en fonction d’une humeur détectée dans ledit message courant. Procédé selon l'une des revendications précédentes, dans lequel la génération du signal (SIG) comprenant les données de recommandations (S39) est déclenchée au moins sur détection d’une forme interrogative, propre à une question, dans le message courant. Procédé selon l'une des revendications précédentes, comportant, préalablement à l’établissement du graphe sémantique courant une structuration des données de texte que comporte le message courant (S32), pour filtrer des graphes de la base de données similaires au graphe courant. Procédé selon l'une des revendications précédentes, dans lequel le message courant est un message vocal, le procédé comportant une transcription du message vocal en données de texte, avant l’établissement du graphe sémantique courant. Dispositif informatique comportant un circuit de traitement (CT) pour la mise en œuvre du procédé selon l’une des revendications précédentes. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications 1 à 10 lorsque ce programme est exécuté par un processeur (PROC) d’un circuit de traitement (CT).