Brevet FR3059862A1 — publié le 20180608

Arrière-plan de l'invention L'invention se rapporte au domaine des télécommunications et porte plus particulièrement le traitement d'une tentative de communication entre plusieurs individus. De nombreuses solutions de télécommunications sont aujourd'hui à disposition pour permettre l'établissement d'une communication entre deux personnes. Divers types de réseaux de communications (3G, 4G etc.) ont été déployés ces dernières années par les opérateurs pour offrir des services de communications adaptés aux besoins de leurs abonnés. Pour joindre un tiers, un utilisateur peut aujourd'hui faire usage d'un quelconque terminal afin d'établir une communication écrite ou orale, en effectuant par exemple un appel téléphonique ou en envoyant un message de type SMS, email, message via une messagerie instantanée... La mise en relation entre l'appelant, à l'origine de la tentative de communication, et l'appelé, destinataire de cette communication, n'est toutefois pas toujours aisée. La tentative de communication initiée par l'appelant est susceptible d'échouer sans qu'il n'en connaisse la raison, par exemple parce que l'utilisateur appelé n'est pas disponible. Cet aléa quant aux chances de succès d'une mise en relation entre deux terminaux peut poser problème et décourage parfois l'utilisateur appelant de tenter cette communication en premier lieu. Il existe aujourd'hui un besoin pour faciliter la mise en relation de plusieurs individus. Objet et résumé de l'invention A cet effet, la présente invention concerne un premier procédé de traitement d'une communication, mis en oeuvre par un premier serveur d'applications, comprenant les étapes suivantes : réception d'une requête de communication provenant d'un premier terminal d'un utilisateur appelant, ladite requête visant à établir une communication avec un deuxième terminal d'un utilisateur cible, le premier serveur d'applications étant compris dans un réseau de communication associé au deuxième terminal ; envoi, à un premier agent conversationnel automatisé associé à l'utilisateur cible, d'une commande de déclenchement pour activer ledit premier agent 3059862 2 conversationnel automatisé, ce dernier étant situé hors du réseau de communication du deuxième terminal ; et traitement, sous le contrôle du premier agent conversationnel automatisé, de la requête de communication, ledit traitement comprenant l'établissement d'un 5 dialogue entre le premier agent conversationnel automatisé et au moins l'un parmi le premier terminal et un deuxième agent conversationnel automatisé associé à l'utilisateur appelant. La présente invention permet de faciliter la mise en relation de deux personnes ou plus. Une communication initiée par un utilisateur source peut être traitée en temps réel 10 par l'agent conversationnel automatisé de l'utilisateur cible afin d'optimiser les chances pour l'utilisateur source de rentrer en contact avec l'utilisateur appelé. L'utilisateur source, qui a initié la communication, est ainsi moins susceptible d'hésiter à contacter un tiers dans la mesure où la communication sera traitée selon les souhaits prédéfinis du tiers. L'agent conversationnel automatisé de l'utilisateur cible peut fournir 15 toutes les informations nécessaires à l'utilisateur source sous la forme d'une notification simple, ou sous la forme d'un dialogue interactif par exemple. L'agent conversationnel automatisé de l'utilisateur cible peut par exemple indiquer à l'utilisateur source, sur son terminal, que l'utilisateur cible n'est pas disponible et/ou lui indiquer une date et/ou heure à laquelle il sera probablement disponible. Un dialogue peut s'établir si besoin entre le 20 terminal de l'utilisateur source et l'agent conversationnel automatisé de l'utilisateur cible afin de répondre aux éventuelles questions de l'utilisateur source ou pour permettre la mise en oeuvre d'un service particulier. Selon le paramétrage choisi, l'agent conversationnel automatisé de l'utilisateur cible peut inviter l'utilisateur source à réitérer sa tentative de communication à un moment 25 opportun, via le même réseau de communication de l'utilisateur cible ou via un autre réseau de communication utilisé par l'utilisateur cible. L'agent conversationnel automatisé de l'utilisateur cible est positionné à l'extérieur de chacun des réseaux de communications associés à l'utilisateur cible, ce qui permet à ce dernier de recevoir de façon centralisée les évènements émis par chacun des réseaux de 30 communications associé à l'utilisateur cible. Cette disposition permet en outre à l'agent conversationnel automatisé de l'utilisateur cible de piloter à distance le serveur d'applications situé dans le réseau de l'utilisateur cible et, le cas échéant chacun des autres serveurs d'applications associés à l'utilisateur cible, afin de traiter une quelconque communication entrant à destination de l'utilisateur cible. 35 Selon un mode de réalisation particulier, le premier procédé de traitement comprend un envoi, au premier agent conversationnel automatisé, d'au moins un évènement indicatif de la disponibilité de l'utilisateur cible afin de permettre audit premier agent 3059862 3 conversationnel automatisé d'adapter ledit traitement en fonction dudit évènement. De façon avantageuse, cela permet à l'agent conversationnel automatisé de l'utilisateur cible de récolter des informations pertinentes concernant les activités de l'utilisateur cible et, plus généralement, sur son état de disponibilité présent et/ou futur. A partir de ces 5 informations, l'agent conversationnel automatisé de l'utilisateur cible peut en déduire par exemple si l'utilisateur cible est actuellement disponible, ou sera disponible dans un futur plus ou moins proche (à définir), pour communiquer avec l'utilisateur source. Selon un mode de réalisation particulier, le premier procédé de traitement comprend un envoi, au premier agent conversationnel automatisé, d'un identifiant de l'utilisateur 10 appelant inclus dans la requête de communication afin de permettre audit premier agent conversationnel automatisé d'adapter ledit traitement en fonction de l'utilisateur appelant. Il est ainsi possible de personnaliser le traitement de la communication entrante en fonction de l'identité de l'utilisateur source. Selon un mode de réalisation particulier, le premier procédé de traitement comprend 15 une réception d'un identifiant du deuxième agent conversationnel automatisé associé à l'utilisateur appelant, ledit traitement comprenant l'établissement d'une communication entre les premier et deuxième agents conversationnels automatisés afin de traiter collectivement ladite requête de communication. De cette manière, l'agent conversationnel automatisé de l'utilisateur cible est capable de rentrer en contact avec 20 l'agent conversationnel automatisé de l'utilisateur source de sorte à ce qu'une coopération s'effectue entre les deux agents conversationnel automatisés. Cette coopération permet de traiter de façon optimale la communication, facilitant ainsi la mise en relation des deux utilisateurs concernés. Un service peut notamment être mis en oeuvre lors de cette coopération. 25 Dans un mode particulier de réalisation, les différentes étapes du premier procédé de traitement sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans un dispositif tel qu'un serveur, ou plus généralement dans un ordinateur, ce programme comportant des 30 instructions adaptées à la mise en oeuvre des étapes d'un premier procédé de traitement tel que définis ci-dessus. L'invention vise aussi un support d'enregistrement (ou support d'informations) lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. 35 La présente invention concerne également un deuxième procédé de traitement d'une communication, mis en oeuvre par un premier agent conversationnel automatisé, comprenant les étapes suivantes : 3059862 4 réception d'une commande de déclenchement provenant d'un serveur d'applications, pour traiter une requête de communication provenant d'un premier terminal d'un utilisateur source visant à établir une communication avec un deuxième terminal d'un utilisateur cible, 5 ledit serveur d'applications étant compris dans un réseau de communication associé au deuxième terminal et ledit premier agent conversationnel automatisé étant situé hors dudit réseau de communication ; vérification que des évènements indicatifs de la disponibilité de l'utilisateur cible ont été reçus en provenance du réseau de communication du deuxième terminal 10 et en provenance d'au moins un autre réseau de communication associé à l'utilisateur cible ; détermination de l'état de disponibilité du deuxième utilisateur à partir d'au moins un dit évènement reçu ; et contrôle à distance du serveur d'applications pour réaliser un traitement de la 15 requête de communication en fonction de l'état de disponibilité de l'utilisateur cible. La présente invention permet de faciliter la mise en relation de deux personnes ou plus. Une communication initiée par un utilisateur source peut être traitée en temps réel par l'agent conversationnel automatisé de l'utilisateur cible afin d'optimiser les chances 20 pour l'utilisateur source de rentrer en contact avec l'utilisateur appelé. Les avantages énoncés ci-avant en relation avec le premier procédé de traitement s'appliquent de façon analogue au deuxième procédé de traitement de l'invention. Selon un mode de réalisation particulier, le deuxième procédé de traitement comprend une réception d'une pluralité de dits évènements indicatifs de la disponibilité de 25 l'utilisateur cible, en provenance du réseau de communication du deuxième terminal et en provenance dudit au moins un autre réseau de communication associé à l'utilisateur cible. L'agent conversationnel automatisé de l'utilisateur cible est ainsi capable de déterminer, à partir de ces évènements, l'état de disponibilité de l'utilisateur cible. Selon un mode de réalisation particulier, le deuxième procédé de traitement 30 comprend l'établissement d'un dialogue entre le premier agent conversationnel automatisé et au moins l'un parmi le premier terminal et un deuxième agent conversationnel automatisé associé à l'utilisateur appelant. De cette manière, l'agent conversationnel automatisé peut traiter de façon interactive la communication avec l'utilisateur source ou son agent conversationnelle automatisé, et ainsi répondre de façon 35 adaptée à chaque cas d'espèce. Selon un mode de réalisation particulier, lors de l'étape de détermination du deuxième procédé de traitement, si l'utilisateur cible est déterminé comme n'étant pas 3059862 5 disponible, le premier agent conversationnel automatisé réalise au moins l'une des actions définies ci-après. selon une première action, le premier agent conversationnel automatisé obtient une donnée de disponibilité renseignant sur l'état de disponibilité de l'utilisateur 5 cible et commande l'envoi, par le serveur d'applications, de ladite donnée de disponibilité à au moins l'un parmi le premier terminal et le deuxième agent conversationnel automatisé. De cette manière, l'utilisateur source peut recontacter l'utilisateur cible à un moment approprié et optimiser ses chances de joindre l'utilisateur cible dans de bonnes conditions ; 10 - selon une deuxième action, le premier agent conversationnel automatisé envoie une notification de communication audit au moins un autre réseau de communication associé à l'utilisateur cible, ladite notification de communication informant de la tentative de communication initiée par le premier terminal. L'envoi de cette notification permet d'informer l'utilisateur cible de la tentative de 15 communication initiée par le premier terminal sur le réseau de l'utilisateur cible. Cette notification comporte par exemple l'identifiant de l'utilisateur source afin d'informer l'utilisateur cible de l'identité de l'utilisateur source, ce qui permet à l'utilisateur cible de recontacter ultérieurement l'utilisateur source si besoin ; - selon une troisième action, le premier agent conversationnel automatisé définit, 20 par l'intermédiaire du serveur d'applications, un rendez-vous en coopération avec le premier terminal ou le deuxième agent conversationnel automatisé, et enregistre une nouvelle entrée indicative du rendez-vous dans des données d'agenda associées à l'utilisateur cible. L'utilisateur cible peut ainsi prendre connaissance, par l'intermédiaire d'un réseau de communication autre que le 25 réseau initialement visé, du nouveau rendez-vous enregistré par son agent conversationnel automatisé ; selon une quatrième action, le premier agent conversationnel automatisé détermine un identifiant de l'utilisateur cible dans ledit au moins un autre réseau de communication et commande l'envoi, par le serveur d'applications, d'une 30 invitation comportant ledit identifiant pour inviter l'utilisateur appelant à contacter l'utilisateur cible via ledit au moins un autre réseau de communication. L'utilisateur source peut ainsi tenter de contacter l'utilisateur cible sur un réseau de communication autre que le réseau initialement visé, optimisant ainsi les chances de joindre l'utilisateur cible dans de bonnes conditions ; 35 selon une cinquième action, le premier agent conversationnel automatisé surveille l'état de disponibilité courant de l'utilisateur cible et, sur détection que l'état de disponibilité courant du deuxième utilisateur atteint un état prédéfini, commande 3059862 6 l'envoi, par le serveur d'applications, d'une notification informant de l'état prédéfini à l'attention de l'utilisateur appelant. De cette manière, l'utilisateur source est informé dès que l'utilisateur cible est disponible, et éventuellement sous quelle condition il est disponible (type de communication acceptée etc.), ce qui permet 5 de faciliter la mise en communications des deux parties. Selon un mode de réalisation particulier, le deuxième procédé de traitement comprend une réception, en provenance du serveur d'applications, d'un identifiant de l'utilisateur appelant, ledit traitement causé par le premier agent conversationnel automatisé lors du contrôle à distance étant fonction dudit identifiant de l'utilisateur 10 appelant. Il est ainsi possible pour le premier agent conversationnel automatisé de personnaliser le traitement de chaque communication initié à l'attention de l'utilisateur cible. Selon un mode de réalisation particulier, le deuxième procédé de traitement comprend une détermination d'un niveau d'urgence de la requête de communication à 15 partir de l'identifiant de l'utilisateur appelant ; et si le niveau d'urgence atteint un niveau prédéfini, le premier agent conversationnel automatisé cause l'envoi, par le serveur d'applications, d'une notification d'urgence à l'attention de l'utilisateur cible via le réseau de communications ou via ledit au moins un autre réseau de communications. L'utilisateur cible peut ainsi juger de l'importance d'une 20 communication entrante et traiter en priorité les communications qu'il juge importante. Selon un mode de réalisation particulier, le deuxième procédé de traitement comprend les étapes suivantes : envoi d'une commande au serveur d'applications visant à établir, en réponse à ladite requête de communication, une communication entre les premier et 25 deuxième terminaux ; déclenchement d'un décompte de temps à compter de l'envoi de la commande visant à établir une communication entre les premier et deuxième terminaux ; et en l'absence de réponse positive du deuxième terminal après un délai prédéfini, détermination que l'utilisateur cible n'est pas actuellement disponible. 30 L'agent conversationnel automatisé peut ainsi déterminer si l'utilisateur cible est actuellement disponible ou non et rentrer si besoin en communication avec l'utilisateur source et/ou l'agent conversationnel automatisé de ce dernier afin de traiter au mieux la communication. Selon un mode de réalisation particulier, le deuxième procédé de traitement 35 comprend une réception, en provenance du serveur d'applications, d'un identifiant du deuxième agent conversationnel automatisé associé à l'utilisateur appelant, ladite étape de contrôle à distance comprenant l'établissement d'une communication entre les premier 3059862 7 et deuxième agents conversationnels automatisés via le serveur d'applications afin de traiter collectivement ladite requête de communication. De cette manière, l'agent conversationnel automatisé de l'utilisateur cible peut coopérer de façon interactive avec l'agent conversationnel automatisé de l'utilisateur source, de sorte à ce qu'ensemble ils 5 répondent de façon adaptée à chaque cas d'espèce. Selon un mode de réalisation particulier, lors dudit contrôle à distance, les premier et deuxième agents conversationnels automatisés échangent, via le serveur d'applications, des données associées aux utilisateurs appelant et cibles de sorte à réaliser collectivement au moins une action prédéterminée. Les agents conversationnels automatisés peuvent 10 ainsi mettre en oeuvre au moins un service permettant par exemple de faciliter la mise en relation immédiate ou future de l'utilisateur source et de l'utilisateur cible. Dans un mode particulier de réalisation, les différentes étapes du deuxième procédé de traitement sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support 15 d'informations, ce programme étant susceptible d'être mis en oeuvre dans un dispositif tel qu'un serveur, ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un deuxième procédé de traitement tel que définis ci-dessus. L'invention vise aussi un support d'enregistrement (ou support d'informations) lisible 20 par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. A noter que les programmes mentionnés dans le présent exposé peuvent utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme 25 partiellement compilée, ou dans n'importe quelle autre forme souhaitable. De plus, les supports d'enregistrement mentionnés ci-avant peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par 30 exemple une disquette (floppy disc) ou un disque dur. D'autre part, les supports d'enregistrement peuvent correspondre à un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. 35 Alternativement, les supports d'enregistrement peuvent correspondre à un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. 3059862 8 La présente invention vise en outre un serveur d'applications comprenant : un module de réception configuré pour recevoir une requête de communication provenant d'un premier terminal d'un utilisateur appelant, ladite requête visant à établir une communication avec un deuxième terminal d'un utilisateur cible, le 5 premier serveur d'applications étant compris dans un réseau de communication associé au deuxième terminal ; un module d'envoi configuré pour envoyer, à un premier agent conversationnel automatisé associé à l'utilisateur cible, une commande de déclenchement pour activer ledit premier agent conversationnel automatisé, ce dernier étant situé 10 hors du réseau de communication du deuxième terminal ; et un module de traitement configuré pour réaliser un traitement de la requête de communication sous le contrôle du premier agent conversationnel automatisé, ledit traitement comprenant l'établissement d'un dialogue entre le premier agent conversationnel automatisé et au moins l'un parmi le premier terminal et un 15 deuxième agent conversationnel automatisé associé à l'utilisateur appelant. La présente invention vise également un agent conversationnel automatisé comprenant : un module de réception configuré pour recevoir une commande de déclenchement provenant d'un serveur d'applications, pour traiter une requête de communication provenant d'un premier terminal d'un utilisateur appelant 20 visant à établir une communication avec un deuxième terminal d'un utilisateur cible, ledit serveur d'applications étant compris dans un réseau de communication associé au deuxième terminal et ledit agent conversationnel automatisé étant situé hors dudit réseau de communication ; 25 un module de vérification configuré pour vérifier si des évènements indicatifs de la disponibilité de l'utilisateur cible ont été reçus en provenance du réseau de communication du deuxième terminal et en provenance d'au moins un autre réseau de communication associé à l'utilisateur cible ; un module de détermination configuré pour déterminer l'état de disponibilité du 30 deuxième utilisateur à partir d'au moins un dit évènement reçu ; et un module de contrôle configuré pour contrôler à distance le serveur d'applications de sorte à réaliser un traitement de la requête de communication en fonction de l'état de disponibilité de l'utilisateur cible. A noter que les différents modes de réalisation définis ci-avant en relation avec le 35 premier procédé de traitement, d'une part, et avec le deuxième procédé de traitement, d'autre part, ainsi que les avantages associés à ces procédés, s'appliquent respectivement 3059862 9 par analogie aux serveur d'applications et à l'agent conversationnel automatisé définis ci-avant. Selon un mode de réalisation particulier, l'invention est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme « module » peut 5 correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels. Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la 10 description faite ci-dessous, en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures: la figure 1 représente schématiquement un environnement comportant notamment un serveur d'applications et un agent conversationnel automatisé conformes à un mode de réalisation particulier de l'invention ; 15 la figure 2 représente schématiquement la structure d'un serveur d'applications conforme à un mode de réalisation particulier de l'invention ; la figure 3 représente schématiquement la structure d'un agent conversationnel automatisé conforme à un mode de réalisation particulier de l'invention ; et la figure 4 représente, sous forme d'un ordinogramme, les étapes d'un premier 20 procédé de traitement mis en oeuvre par un serveur d'applications et les étapes d'un deuxième procédé de traitement mis en oeuvre par un agent conversationnel automatisé, conformément à un mode de réalisation particulier de l'invention. 25 Description détaillée de plusieurs modes de réalisation Comme indiqué précédemment, la technique proposée se rapporte au traitement d'une tentative de communication initiée par un premier terminal de communication à destination d'un tiers utilisant un autre terminal de communication. L'invention se propose de faciliter la mise en relation entre un utilisateur appelant et 30 un utilisateur appelé en utilisant au moins un agent conversationnel automatisé destiné à traiter automatiquement une demande de communication initié par l'utilisateur appelant à destination de l'utilisateur appelé. L'agent conversationnel automatisé peut centraliser des informations indicatives de la disponibilité de l'utilisateur appelé et traiter la demande de communication en fonction de la disponibilité de l'appelé afin de faciliter les interactions 35 entre appelant et appelé. L'invention, selon divers modes de réalisation, met ainsi en oeuvre un serveur d'applications situé dans le réseau de communication auquel est connecté le terminal d'un 3059862 10 utilisateur cible, ce serveur étant configuré pour recevoir une requête de communication provenant du terminal d'un utilisateur appelant, pour déclencher un agent conversationnel automatisé associé à l'utilisateur cible, et pour traiter cette requête de communication sous le contrôle de l'agent conversationnel automatisé. L'invention, selon divers modes de 5 réalisation, concerne également un tel agent conversationnel automatisé, configuré pour être activé par le serveur d'applications, pour déterminer l'état de disponibilité de l'utilisateur cible à partir de données (ou évènements) reçues d'au moins un réseau de communication associé à l'utilisateur cible, et pour contrôler à distance le serveur d'applications afin de traiter la requête de communication de façon appropriée, 10 notamment en fonction de l'état de disponibilité de l'utilisateur cible. D'autres aspects et avantages de la présente invention ressortiront des exemples de réalisation décrits ci-dessous en référence aux dessins mentionnés ci-avant. Dans le présent exposé, des exemples de mise en oeuvre de l'invention sont décrits dans le cadre d'un premier utilisateur tentant d'établir une communication avec un 15 deuxième utilisateur. Dans ce contexte, la communication initiée par le premier utilisateur peut être de type quelconque, telle que par exemple un appel vocal initié par le premier utilisateur ou encore un message de type texte (SMS, email, message via un service de messagerie instantanée...) envoyé par le premier utilisateur. En outre, toujours dans ce contexte, l'utilisateur à l'origine de la communication (c.-à-d. initiant la communication) 20 est dit utilisateur appelant ou utilisateur source, tandis que le deuxième utilisateur destinataire de la communication est dit utilisateur appelé ou utilisateur cible. Dans le cas d'une conférence téléphonique, on peut également envisager que plusieurs utilisateurs appelants initient un appel vers un même utilisateur cible. Sauf indications contraires, les éléments communs ou analogues à plusieurs figures 25 portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité. Un mode de réalisation particulier de l'invention est à présent décrit en référence à la figure 1, où un utilisateur UA tente d'établir une communication vocale avec un autre 30 utilisateur UB. Comme décrit par la suite, d'autres types de communication sont toutefois possibles dans le cadre de l'invention. Pour ce faire, l'utilisateur UA, dit utilisateur appelant ou utilisateur source, initie un appel téléphonique en direction du terminal TB1 de l'utilisateur cible UB. Dans l'exemple considéré ici, le terminal TA de l'utilisateur UA est par exemple 35 associé (ou connecté) à un premier réseau de communications R1, tandis que le terminal TB1 de l'utilisateur cible UB est associé (ou connecté) à un deuxième réseau de communications R2. Les terminaux TA et TB1 peuvent être de quelconques équipements 3059862 11 aptes à établir ensemble une communication vocale, tels que des téléphones mobiles ou fixes etc. Les réseaux R1 et R2 peuvent être par exemple des réseaux de téléphonie fixe ou mobile (de type 3G, 4G etc.). Dans cet exemple, un premier serveur d'applications SA1 situé dans le réseau de 5 communications R1 fait le relais entres les appels de l'utilisateur appelant UA et l'extérieur. Lorsque l'utilisateur UA tente d'appeler l'utilisateur UB, le serveur d'applications SA1 est ici configuré pour transférer une requête de communication RQ1, émise par le terminal TA de l'utilisateur appelant UA, vers le réseau de communications R2 de l'utilisateur cible UB. 10 Le serveur d'applications SA1 présente ici la structure d'un ordinateur et comporte notamment au moins un processeur (non représenté) et une mémoire non volatile MR1 (ROM ou Flash par exemple) constituant un support d'enregistrement, lisible par le serveur d'applications SA1, et sur lequel est enregistré un programme d'ordinateur PG1 conforme à un mode de réalisation particulier. 15 Dans l'exemple représenté en figure 1, le serveur d'applications SA1 contient en mémoire un identifiant ID-A de l'utilisateur UA dans le réseau Rl. Cet identifiant ID-A est ici enregistré en association avec un identifiant ID-BOTA d'un agent conversationnel automatisé BOTA qui sera décrit ultérieurement. Toujours dans cet exemple, un deuxième serveur d'applications SA2, situé dans le 20 réseau de communications R2, est chargé de recevoir les appels à destination de l'utilisateur cible UB et de les transférer si besoin vers le terminal TB1 destinataire de l'appel. Sur réception de la requête d'appel RQ1, le serveur d'applications SA2 est ici configuré pour transférer l'appel au terminal TB1 ou pour activer un agent conversationnel automatisé BOTB associé à l'utilisateur cible UB, cet agent 25 conversationnel automatisé BOTB étant situé hors du réseau R2. Le serveur d'applications SA2 présente ici aussi la structure d'un ordinateur et comporte notamment au moins un processeur (non représenté) et une mémoire non volatile MR2 (ROM ou Flash par exemple) constituant un support d'enregistrement, lisible par le serveur d'applications SA2, et sur lequel est enregistré un programme d'ordinateur 30 PG2 conforme à un mode de réalisation particulier. Dans cet exemple, le serveur d'applications SA2 dispose aussi en mémoire d'un identifiant ID-BOTB de l'agent conversationnel automatisé BOTB en association avec un identifiant ID-B1 de l'utilisateur cible UB dans le réseau R2. Sur réception de la requête d'appel RQ1 émise par le terminal source TA, le serveur 35 d'applications SA2 peut ainsi envoyer une commande CMD1 de déclenchement à l'agent conversationnel automatisé BOTB, cette commande visant à activer ledit agent 3059862 12 conversationnel automatisé BOTB pour qu'il traite l'appel entrant initié par l'utilisateur source UA. Dans le présent exposé, un agent conversationnel automatisé désigne une interface homme-machine configurée pour traiter de façon interactive la ou les requêtes d'un 5 utilisateur (par exemple l'utilisateur source UA). Pour ce faire, l'agent conversationnel automatisé (désigné aussi sous l'appellation anglaise « chatbot » dans le présent exposé) est apte à dialoguer ou coopérer avec l'utilisateur de façon automatisée, sur la base de critères prédéfinis. L'agent conversationnel automatisé peut proposer certains services et prend le cas échéant en compte les demandes ou réponses de l'utilisateur avec lequel il 10 interagit. Dans le cas présent, le chatbot BOTB se présente sous la forme d'un programme d'ordinateur PG3 stocké dans une mémoire non-volatile MR3 (ROM ou Flash par exemple) et exécutable par au moins un processeur (non représenté) d'un équipement informatique, tel qu'un serveur, un ordinateur ou tout autre équipement informatique 15 apte à exécuter ce type d'interface logicielle. Le chatbot BOTB utilise une interface de programmation applicative (API), notée APIA, pour coopérer à distance avec le serveur d'applications SA2 se trouvant dans le réseau de communications R2. Selon un exemple particulier, le chatbot BOTB met en oeuvre un service de 20 messagerie vocale configuré pour traiter les communications entrantes à destination de l'utilisateur cible UB. Par ailleurs, le chatbot BOTB est configuré pour recevoir le cas échéant des données (ou évènements) EV en provenance du réseau de communications R3 ainsi qu'en provenance d'au moins un autre réseau de communications associé à l'utilisateur cible UB, 25 tel que les réseaux R3 et R4 représentés ici en figure 1. Ces évènements EV sont des données indicatives de la disponibilité de l'utilisateur associé, à savoir l'utilisateur cible UB dans cet exemple. Comme indiqué par la suite, divers types d'évènements EV peuvent être reçus par le chatbot BOTB. On suppose ici que le réseau de communication R3 est un autre réseau auquel a 30 souscrit l'utilisateur cible UB et auquel est associé (connecté) un autre terminal TB2 de l'utilisateur cible UB. Dans cet exemple, un serveur d'applications SA3 situé dans le réseau R3 est configuré pour traiter des appels émis ou à destination du terminal TB2. Le serveur d'applications SA3 est par exemple configuré pour envoyer le cas échéant au chatbot BOTB un ou des évènements EV indicatifs de la disponibilité de l'utilisateur cible UB. 35 Le serveur d'applications SA3 présente ici aussi la structure d'un ordinateur et comporte notamment au moins un processeur (non représenté) et une mémoire non volatile MR4 (ROM ou Flash par exemple) constituant un support d'enregistrement, lisible 3059862 13 par le serveur d'applications SA3, et sur lequel est enregistré un programme d'ordinateur PG4 conforme à un mode de réalisation particulier. Dans cet exemple, le serveur d'applications SA3 dispose aussi en mémoire de l'identifiant ID-BOTB de l'agent conversationnel automatisé BOTB, associé par exemple à un identifiant ID-B2 de 5 l'utilisateur cible UB dans le réseau R3. Les réseaux de communications R2 e R3 sont ici des réseaux distincts mis en oeuvre par des opérateurs différents. La nature des évènements EV susceptibles d'être transmis par les réseaux de communication R2 et R3 au chatbot BOTB peut varier selon le cas d'usage. Ces 10 évènements EV sont des données informant le chatbot BOTB des activités ou de la disponibilité de l'utilisateur cible UB. Un évènement EV envoyé par le serveur d'applications SA2 (ou respectivement SA3) peut par exemple indiquer que l'utilisateur cible UB a été impliqué dans un appel téléphonique à une certaine date et/ou heure, ou que l'utilisateur cible UB est en cours de communication. L'évènement EV peut par 15 exemple spécifier que la communication en cours (ou passée) est une communication entrante (initiée par un tiers) ou sortante (initiée par l'utilisateur UB). Le type d'évènement EV peut varier en fonction du type de communication que l'utilisateur cible UB peut réaliser via le réseau R2 (respectivement R3) auquel il a souscrit. Dans un exemple particulier, l'évènement EV indique par exemple que l'utilisateur UB est 20 en cours de discussion sur un service de messagerie instantanée. Selon un autre exemple, l'évènement EV comprend une information sur la localisation de l'utilisateur cible UB. A partir de cette information de localisation, le chatbot B peut ainsi déterminer l'état de disponibilité de l'utilisateur cible UB. Comme représenté en figure 1, on suppose également dans cet exemple que le 25 réseau de communications R4 est encore un autre réseau mettant en oeuvre un service auquel a souscrit l'utilisateur cible UB. Dans le cas considéré ici, le serveur d'applications SA4 met par exemple en oeuvre un service de messagerie de type OutlookTm ou équivalent capable d'envoyer au chatbot BOTB des évènements EV indicatifs de la disponibilité de l'utilisateur cible UB. Un tel évènement EV peut être par exemple un 30 évènement d'agenda indiquant une activité ou un rendez-vous de l'utilisateur cible UB à des dates et heures données. Un évènement EV émis par le serveur d'applications SA4 peut également correspondre à une activité de l'utilisateur cible UB détectée sur le service de messagerie, telle que la préparation ou l'envoi d'un email etc. On comprendra que l'exemple de ce service de messagerie n'est pas limitatif et que d'autres types de services 35 et d'évènements sont possibles. En variante, le service mis en oeuvre par le serveur d'applications SA4 est un réseau social tel que FacebookTm, TwitterTm etc. 3059862 14 Dans l'exemple de réalisation décrit ici, le serveur d'applications SA4 présente aussi la structure d'un ordinateur et comporte notamment au moins un processeur (non représenté) et une mémoire non volatile MR5 (ROM ou Flash par exemple) constituant un support d'enregistrement, lisible par le serveur d'applications SA4, et sur lequel est 5 enregistré un programme d'ordinateur PG5 conforme à un mode de réalisation particulier. Concernant à nouveau le chatbot BOTB, ce dernier est par ailleurs configuré pour surveiller les évènements EV qu'il est susceptible de recevoir des différents réseaux R2, R3, R4 associés à l'utilisateur cible UB, ces évènements EV étant indicatifs de l'état de disponibilité dudit utilisateur cible UB. Comme représenté en figue 1, le chatbot BOTB 10 peut enregistrer dans une mémoire les évènements EV et les traiter si besoin. A partir de ces évènements EV, le chatbot B est configuré pour déterminer l'état de disponibilité ou d'accessibilité (courant et/ou futur) de l'utilisateur associé, à savoir l'utilisateur cible UB dans cet exemple. Cet état de disponibilité peut indiquer si l'utilisateur cible UB est actuellement en position ou non pour recevoir une communication entrante (tel quel un 15 appel téléphonique entrant dans cet exemple). L'état de disponibilité peut aussi renseigner sur la capacité de l'utilisateur cible UB à recevoir une communication dans le futur. Dans cet exemple, le BOTB contient également en mémoire l'identifiant respectif ID-B1, ID-B2 et ID-B3 de l'utilisateur cible UB dans chacun des réseaux R2, R3 et R4. On 20 comprend que l'utilisateur cible UB dispose d'un identifiant propre pour chaque réseau de communication R2, R3 et R4 dont il est usager, cet identifiant lui étant par exemple attribué par l'opérateur du réseau correspondant. Un identifiant peut être une adresse email, un numéro de téléphone, un identifiant de messagerie instantanée ou autre, selon le cas. 25 Toujours dans cet exemple, le chatbot BOTB stocke également en mémoire des données DN1 à partir desquelles le chatbot BOTB peut déterminer comment un appel entrant doit être traité. Les données DN1 sont ici des règles de traitement prédéfinies, ces règles pouvant par exemple être définies à l'avance par l'utilisateur cible UB ou un tiers. Ces règles de traitement DN1 peuvent définir notamment : 30 - quand (date, heure...) l'utilisateur UB accepte ou non de répondre à une communication ; - à quel type de communication l'utilisateur UB accepte ou non de répondre ; - de quel utilisateur source il accepte ou non de recevoir une communication etc. - dans quelles situations il accepte ou non de répondre à une communication. 35 La situation évoquée ci-dessus peut concerner notamment la localisation de l'utilisateur UB. Les règles de traitement DN1 peuvent combiner un ensemble de critères quelconques, parmi notamment ceux indiqués ci-dessus, afin de permettre au chatbot 3059862 15 BOTB de déterminer dans chaque situation si l'utilisateur cible UB souhaite ou non accepter une communication entrante. Ces règles de traitement DN1 définissent ici dans quelles conditions l'utilisateur cible UB est d'accord pour accepter une communication entrante sur le réseau de 5 communication R2 dont il est l'usager. On comprend toutefois que des règles de traitement DN1 du même type peuvent être stockées et utilisées par le chatbot BOTB pour traiter des communications entrantes à destination de l'utilisateur cible UB sur un autre réseau de communication auquel il est abonné, comme par exemple le réseau R3 dans cet exemple. 10 A titre d'exemple, une règle de traitement DN1 peut définir les règles suivantes : - l'utilisateur UB est disponible pour les communications téléphoniques entre 9 heure et 19 heures, sauf s'il est en cours de communication sur l'un des réseaux de communications (ici R4) auquel il a souscrit ; - l'utilisateur UB accepte toujours des communications écrites par messagerie 15 instantanée sauf s'il est localisé à son domicile ou en cours de déplacement... L'homme du métier peut naturellement adapter notamment les règles de traitement DN1 et les types d'évènement EV remontés par les réseaux de communication R2-R4 à l'agent conversationnel automatisé BOTB de l'usager afin de répondre de façon appropriée à chaque cas d'espèce. 20 Le serveur d'applications SA2 et le chatbot BOTB forment ensemble un système de traitement SY apte à traiter une requête de communication RQ1 émise par le terminal UA de l'utilisateur UA pour initier une communication avec l'utilisateur cible UB. Selon le mode de réalisation particulier considéré ici en figure 1, un deuxième agent conversationnel automatisé (ou chatbot) BOTA, associé cette fois à l'utilisateur source UA, 25 est situé hors du réseau de communications Ri de sorte à pouvoir interagir à distance avec le serveur d'applications SA1 situé dans le réseau de communications SA1. En variante, le chatbot BOTA peut être situé dans le réseau Rl. Le chatbot BOTA est par exemple mis en oeuvre par le serveur d'applications SA1 lui-même. Comme expliqué par la suite dans un exemple de réalisation particulier, le chatbot BOTA est configuré pour 30 coopérer si besoin avec le chatbot BOTB de l'utilisateur cible UB afin de traiter par exemple l'appel initié par l'utilisateur source UA à l'attention de l'utilisateur cible UB. Pour ce faire, les chabots BOTA et BOTB comprennent chacun dans cet exemple une interface de communication leur permettant de communiquer ensemble. Comme expliqué par la suite, des variantes de réalisation sont toutefois possibles selon lesquelles le deuxième 35 agent conversationnel automatisé BOTA associé à l'utilisateur source UA n'est pas mis en oeuvre ou du moins n'est pas utilisé. 3059862 16 Dans l'exemple considéré ici, le chatbot BOTA présente une structure identique ou analogue au chatbot BOTB. Plus précisément, Le chatbot BOTA se présente sous la forme d'un programme d'ordinateur PG6 stocké dans une mémoire non-volatile MR6 (ROM ou Flash par exemple) et exécutable par au moins un processeur (non représenté) d'un 5 équipement informatique, tel qu'un serveur, un ordinateur ou tout autre équipement informatique apte à exécuter ce type d'interface logicielle. Le chatbot BOTA utilise une API, notée API-A, pour coopérer à distance avec le serveur d'applications SA1 se trouvant dans le réseau de communications R1. Dans cet exemple, le chatbot BOTA comprend aussi en mémoire des règles de 10 traitement DN2 analogues aux règles de traitement DNA du chatbot BOTB, ces règles DN2 permettant le cas échéant au chatbot BOTA de déterminer la manière dont une communication doit être traitée, comme expliqué ultérieurement. Bien que cela ne soit pas décrit ci-après par souci de simplicité, le chatbot BOTA peut également fonctionner de façon analogue au chatbot BOTB afin de traiter une 15 communication qu'un tiers tenterait d'initier à l'attention de l'utilisateur UA, prenant cette fois la position de l'utilisateur cible. Selon un exemple particulier, le chatbot BOTA met en oeuvre un service de messagerie vocale configuré pour traiter les communications entrantes à destination de l'utilisateur UA. On comprendra que certains éléments généralement présents dans notamment un 20 serveur d'applications, dans un chatbot ou encore dans un réseau de communications, ont été volontairement omis car ils ne sont pas nécessaires à la compréhension de la présente invention. On comprendra que l'environnement représenté en figure 1, et notamment le système de traitement SY, n'est qu'un exemple de réalisation, d'autres mises en oeuvre 25 étant possibles dans le cadre de l'invention. L'homme du métier comprendra en particulier que certains éléments de cet environnement ne sont décrits ici que pour faciliter la compréhension de l'invention, ces éléments n'étant pas nécessaires pour mettre en oeuvre l'invention. Selon un mode de réalisation particulier représenté en figure 2, le serveur 30 d'applications SA2 (et plus particulièrement son processeur) piloté par le programme d'ordinateur PG2 met en oeuvre un certain nombre de modules, à savoir : un module de réception MD2, un module d'envoi MD4, un module de traitement MD6 et un module de suivi d'évènements MD8. Le module de réception MD2 est configuré pour recevoir la requête RQ1 de 35 communication provenant du terminal source TA comme représenté en figure 1, cette requête visant à établir une communication entre le terminal source TA et le terminal cible TB1. 3059862 17 Le module d'envoi MD4 est configuré pour envoyer, au chatbot BOTB associé à l'utilisateur cible UB, une commande de déclenchement CMD1 (figure 1) pour activer ledit chatbot BOTB. Le module de traitement MD6 est configuré pour réaliser notamment un traitement 5 de la requête de communication RQ1 reçue par le module de réception MD2, ce traitement étant réalisé sous le contrôle du chatbot BOTB qui commande le serveur d'applications SA2 à distance (c.-à-d. depuis l'extérieur du réseau R2). Comme expliqué par la suite, le traitement réalisé par le module de traitement MD6 peut comprendre l'établissement d'un dialogue ou d'une interaction entre le chatbot BOTB et au moins l'un 10 parmi le terminal source TA de l'utilisateur appelant UA et le chatbot BOTA de l'utilisateur appelant UA. Si, dans une variante, l'utilisateur source UA ne dispose pas d'un chatbot pour l'assister, le dialogue se fait nécessairement entre le chatbot BOTB et le terminal TA de l'utilisateur source UA. Plus généralement, on comprendra que le module de traitement MD6 peut être 15 configuré pour réaliser un quelconque traitement en réponse à des instructions émises par un agent conversationnel automatisé externe au réseau de communications R2. Selon le cas, le traitement réalisé par le module de traitement MD6 peut par exemple être piloté à distance par le chatbot BOTB ou par un autre chatbot (tel que le chatbot BOTA) associé à un autre utilisateur que l'utilisateur UB. 20 Selon un mode de réalisation particulier représenté en figure 3, l'agent conversationnel automatisé BOTB (et plus particulièrement son processeur) piloté par le programme d'ordinateur PG3 met en oeuvre un certain nombre de modules, à savoir : un module de réception MD10, un module de vérification MD12, un module de détermination MD14 et un module de contrôle MD16. 25 Le module de réception MD10 est configuré pour recevoir la commande de déclenchement CMD1 provenant du serveur d'applications SA1, cette commande déclenchant le traitement par le chatbot BOTB de la requête RQ1 de communication provenant du terminal TA de l'utilisateur source UA. Le module de vérification MD12 est configuré pour vérifier si un ou des évènements 30 EV indicatifs de la disponibilité de l'utilisateur cible UB ont été reçus en provenance du réseau de communication R2 du terminal TB1 et en provenance d'au moins un autre réseau de communication associé à l'utilisateur cible UB, à savoir les réseaux R3 et R4 dans cet exemple. Le module de détermination MD14 est configuré pour déterminer l'état de 35 disponibilité (courant et/ou futur) de l'utilisateur cible UB à partir d'au moins un évènement reçu EV reçu. 3059862 18 Le module de contrôle MD16 est configuré pour contrôler à distance (c'est-à-dire depuis l'extérieur du réseau R2) le serveur d'applications SA2 de sorte à réaliser un traitement de la requête de communication RQ1 en fonction de l'état de disponibilité de l'utilisateur cible UB. Comme déjà indiqué et comme illustré par la suite, le module de 5 contrôle MD16 peut prendre en compte un certain nombre de paramètres pour déterminer l'état de disponibilité de l'utilisateur UB et la manière dont une communication entrante doit être traitée, en appliquant notamment les règles de traitement prédéfinies DN1 dans le cas présent. Plus généralement, on comprendra que le module de contrôle MD16 peut être 10 configuré pour contrôler, depuis l'extérieur du réseau R2, le serveur d'applications SA2 de sorte à réaliser un traitement adapté à chaque cas d'espèce. Comme représenté en figure 1, le chatbot B est positionné à l'extérieur de chacun des réseaux de communications associés à l'utilisateur cible UB (à savoir R2, R3 et R4 dans cet exemple). Cette position externe du chatbot BOTB permet à ce dernier de 15 recevoir de façon centralisée les évènements EV émis par chacun des réseaux de communications R2, R3, R4 auquel l'utilisateur UB a souscrit. Cette disposition permet en outre au chatbot BOTB de piloter à distance le serveur d'applications SA2 et, le cas échéant chacun des serveurs d'applications SA3 et SA4, afin de traiter une quelconque communication entrant dans un réseau de communication R2, R3 ou R4 à destination de 20 l'usager UB. Le fonctionnement des modules MD2-MD8 du serveur d'applications SA2 (figure 2) et des modules MD10-MD16 du chatbot BOTB (figure 3) apparaîtra plus précisément dans les exemples de réalisation décrits ci-après en référence à la figure 4. On comprendra que ces modules ne constituent qu'un exemple de mise en oeuvre non 25 limitatif de l'invention, des variantes étant à la portée de l'homme du métier. Un mode de réalisation particulier de l'invention est à présent décrit en référence à la figure 4. Plus précisément, le serveur d'applications SA2 et l'agent conversationnel automatisé BOTB illustrés en figures 1-3 mettent chacun en oeuvre un procédé de traitement en exécutant respectivement le programme d'ordinateur PG2, PG3. 30 Comme déjà expliqué en référence à la figure 1, on supposera à présent que l'utilisateur source UA utilise son terminal TA afin d'initier une communication vers le réseau de communications R2 à destination de l'utilisateur cible UB. Dans l'exemple considéré ici, on suppose que l'utilisateur source UB tente d'établir une conversation vocale en initiant un appel téléphonique à destination de l'utilisateur cible TB1. 35 Dans cet exemple, lors de l'initiation de l'appel, le terminal TA de l'utilisateur source UA envoie une requête RQ1 de communication qui est reçue en B2 par le serveur d'applications SA1. La requête RQ1 comprend l'identifiant ID-B1 de l'utilisateur cible UB 3059862 19 dans le réseau de communications R2. A partir de cet identifiant ID-B1, le serveur d'applications SA1 détermine vers quelle destination doit être transmise la requête RQ1 de communication. Dans cet exemple, cette requête RQ1 comprend en outre l'identifiant IDA de l'utilisateur UA à l'origine de l'appel, bien que des variantes de réalisation sans 5 l'inclusion d'un tel identifiant dans la requête RQ1 sont possibles (cas d'un appel anonyme par exemple). Le serveur d'applications SA1 insert (B3) ensuite l'identifiant ID-BOTA du chatbot BOTA dans la requête RQ1 et envoie (B4) ladite requête RQ1, comportant l'identifiant IDBOTA, au réseau de communication R2. Le serveur d'applications SA2 reçoit la requête 10 RQ1 en C4. Dans cet exemple de réalisation, le serveur d'applications SA2 détecte, à partir de l'identifiant ID-B1 présent dans la requête RQ1, que la communication entrante est destinée à l'utilisateur cible UB. Le serveur d'applications SA2 envoie (C6) alors une commande de déclenchement CMD1 au chatbot BOTB chargé de traiter les 15 communications de l'utilisateur cible UB. Le serveur d'applications SA2 détermine que le chatbot BOTB est en charge du traitement des communications à partir de l'identifiant IDBOTB enregistré en association avec l'identifiant ID-B1 de l'utilisateur cible UB dans le réseau R2. On comprendra que des variantes sont possibles selon lesquelles le serveur 20 d'applications SA2 tente dans un premier temps de joindre l'utilisateur cible UB sur son terminal TB1 et, en cas d'échec (par exemple en cas de non réponse après un délai prédéfini), procède alors à l'envoi C6 de la commande de déclenchement CMD1. Dans l'exemple envisagé ici, la commande de déclenchement CMD1 envoyée en C6 par le serveur d'applications SA2 comprend l'identifiant ID-A de l'utilisateur source UA, 25 l'identifiant ID-B1 de l'utilisateur cible UB et l'identifiant ID-BOTA du chatbot BOTA de l'utilisateur UA. Comme illustré en figure 4, le chatbot BOTB de l'usager UB reçoit la commande de déclenchement CMD1 en D6. Sur réception de cette commande CMD1, le chatbot BOTB traite la communication entrante comme expliqué ci-après. 30 En parallèle, le chatbot BOTB reçoit (D7) au moins un évènement EV émis par l'un quelconque des réseaux de communications R2, R3, R4 associés à l'utilisateur cible UB, cet évènement EV étant indicatif de la disponibilité (ou de l'état d'accessibilité) de l'utilisateur UB. Dans un exemple particulier, le chatbot BOTB reçoit (D7) une pluralité de dits évènements EV en provenance du réseau de communication R2 et en provenance des 35 autres réseaux de communication R3 et R4 associés à l'utilisateur cible UB. Le chatbot BOTB peut traiter chaque évènement EV en temps réel. 3059862 20 Dans l'exemple représenté en figure 4, on suppose que le chatbot BOTB reçoit (D8) un premier évènement EV1 émis (C8) par le serveur d'applications SA2, reçoit (D10) un deuxième évènement EV2 émis (F10) par le serveur d'applications SA3 et reçoit (D12) un troisième évènement EV3 émis (G12) par le serveur d'applications SA4. On comprend que 5 chaque des évènements EV1, EV2, EV3 (notés collectivement EV) peut être reçu dans un ordre quelconque, avant ou après l'étape de réception D6 de la commande de déclenchement CMD1. Dans cet exemple, les évènements EV1, EV2 et EV3 contiennent respectivement l'identifiant ID-B1, ID-B2 et ID-B3 de l'utilisateur cible UB dans chacun des réseaux R2, R3 10 et R4. Comme déjà indiqué, l'utilisateur cible UB dispose d'un identifiant propre pour chaque réseau de communication R2, R3 et R4 dont il est l'usager. Le chatbot BOTB enregistre chaque évènement EV reçu dans sa mémoire et réalise si besoin tout traitement approprié. Comme déjà indiqué, le chatbot BOTB contient en mémoire chacun des identifiants 15 ID-B1, ID-B2 et ID-B3 de l'utilisateur cible UB. Le chatbot BOTB détecte ainsi que les évènements EV reçus concernent l'utilisateur UB et enregistre par conséquent ces évènements EV en association avec l'utilisateur cible UB. Le chatbot BOTB vérifie ensuite en D13 si des évènements EV indicatifs de la disponibilité de l'utilisateur cible UB ont bien été reçus en provenance des réseaux de 20 communications associés à l'utilisateur UB, à savoir les réseaux R2, R3, R4. Pour ce faire, le chatbot BOTB consulte ici sa mémoire et détecte les évènements EV1, EV2 et EV3 enregistrés en association avec l'utilisateur cible UB. En D14, le chatbot BOTB détermine l'état de disponibilité de l'utilisateur cible UB à partir des évènements EV détectés en association avec l'utilisateur cible UB, et 25 éventuellement à partir des règles de traitement DN1. L'état de disponibilité renseigne sur la capacité courante, et éventuellement future, de l'utilisateur cible UB à recevoir et traiter une nouvelle communication entrante. Le chatbot BOTB peut en outre prendre en compte en D14 l'identifiant ID-A de l'utilisateur source UA pour déterminer l'état de disponibilité de l'utilisateur cible UB. Il est 30 ainsi possible de personnaliser le traitement de la communication entrante en fonction de l'utilisateur source UA. Des variantes sont toutefois possibles selon lesquelles l'identité de l'utilisateur appelant n'est pas prise en compte par le chatbot BOTB. Le chatbot BOTB contrôle (D16) ensuite à distance le serveur d'applications SA2 situé dans le réseau R2 pour réaliser un traitement de la requête de communication RQ1 émise 35 par le terminal source TA, ce traitement étant fonction de l'état de disponibilité de l'utilisateur cible UB obtenu en D14. Le chatbot BOTB se comporte ici en tant que maître vis-à-vis du serveur d'applications SA2 qui se comporte comme esclave. 3059862 21 Dans cet exemple, le chatbot BOTB applique en outre en D16 la ou les règles de traitement DN1 pour déterminer, sur la base des évènements EV et éventuellement d'autres paramètres (l'identité ID-A de l'utilisateur source UA, localisation de l'utilisateur UB, date et/ou heure...), comment la communication initiée par l'utilisateur source UA à 5 destination de l'utilisation cible UB doit être traitée. Il est ainsi possible d'adapter à chaque situation la meilleure manière de traiter une nouvelle communication. Lors de ce contrôle à distance D16, le chatbot BOTB pilote le serveur d'applications SA2 en lui envoyant des commandes (ou instructions) et en traitant des données émises par le serveur d'applications SA2. Cette coopération entre le chatbot BOTB et le serveur 10 d'applications SA2 (via des APIs adaptées) permet d'assurer le traitement automatisé de la communication initiée par l'utilisateur source UA, en conformité le cas échéant avec les règles prédéfinies DN1, et en prenant compte de l'activité de l'utilisateur cible UB sur les différents réseaux de communications R2, R3, R4 dont il est l'usager. Le serveur d'applications SA2 traite (C16) ainsi, sous le contrôle du chatbot BOTB, la 15 requête RQ1 de communication. Comme représenté en figure 4, le traitement C16 commandé par le chatbot BOTB comprend par exemple l'établissement d'un dialogue (ou coopération) 20 entre le chatbot BOTB et le terminal TA de l'utilisateur source UA et/ou un dialogue (ou coopération) 30 entre le chatbot BOTB et le chatbot BOTA de l'utilisateur source UA. La ou les entités avec 20 lesquelles le chatbot BOTB décide d'interagir dépend de la configuration de ce dernier et du cas d'espèce. Selon un mode de réalisation particulier, le chatbot BOTB est configuré pour coopérer (20, 30) avec le terminal TA et avec le chatbot BOTA lorsqu'un tel chatbot est disponible pour assister l'utilisateur source UA. Si un tel chatbot BOTA n'est pas disponible, le chatbot BOTB ne coopère qu'avec le terminal TA. Selon une autre variante, 25 le chatbot BOTB n'interagit qu'avec le chatbot BOTA si ce dernier est disponible. Dans l'exemple considéré, on suppose que le chatbot BOTB décide (D16), sur la base des évènements EV obtenus et des règles de traitement DN1 appliquées, d'interagir avec le terminal TA et avec le chatbot BOTA. Pour ce faire, le chatbot BOTB envoie (D16) par exemple une commande CMD2 comportant l'identifiant ID-A de l'utilisateur source UA 30 dans le réseau R1, l'identifiant ID-B1 de l'utilisateur cible UB dans le réseau R2 et l'identifiant ID-BOTA du chatbot BOTA de l'utilisateur source UA. Le serveur d'applications SA2 reçoit cette commande CMD2 en C18 puis, en réponse à cette commande CMD2, envoie (C20) par exemple un message MSG2 vers le réseau Ri. Ce message MSG2 peut être identique à la commande CMD2 ou être obtenu à partir de cette commande CMD2. 35 Dans cet exemple, le message MSG2 comprend également l'identifiant ID-A de l'utilisateur source UA dans le réseau R1, l'identifiant ID-B1 de l'utilisateur cible UB dans le réseau R2 et l'identifiant ID-BOTA du chatbot BOTA de l'utilisateur source UA. 3059862 22 Comme représenté en figure 4, le serveur d'applications SA1 reçoit le message MSG2 en B20 et transmet (B22) des messages MSG3 et MSG4 respectivement au terminal TA et au chatbot BOTA. L'utilisateur UA peut ainsi recevoir toute information utile de la part du chatbot BOTB. Le chatbot BOTB peut par exemple indiquer à l'utilisateur source 5 UA, sur son terminal TA, que l'utilisateur cible UB n'est pas disponible et/ou lui indiquer une date et/ou heure à laquelle il sera disponible. Un dialogue peut s'établir si besoin entre le terminal TA et le chatbot BOTB afin de répondre aux éventuelles questions de l'utilisateur source UB ou pour permettre la mise en oeuvre d'un service particulier. Selon un exemple particulier, le chatbot BOTB met en oeuvre un service de 10 messagerie vocale qui permet un dialogue ou une interaction 20 entre l'utilisateur source UA et le chatbot BOTB. Par ailleurs, le chatbot BOTA de l'utilisateur source UA peut également prendre connaissance de la situation à partir du message MSG4 reçu en E22 puis coopérer avec le chatbot BOTB afin de réaliser un traitement approprié. A titre d'exemple, les chatbots 15 BOTA et BOTB peuvent coopérer ensemble pour définir un rendez-vous entre les utilisateurs UA et UB en fonction de leur disponibilité respective, en utilisant par exemple des données d'agenda auxquelles les chatbots BOTA et BOTB ont accès (sous forme d'évènements EV par exemple). Pour ce faire, les chatbots BOTA et BOTB établissent un canal de communication bidirectionnel passant par le serveur d'applications SA2 et par le 20 réseau RI. (en passant éventuellement par le serveur d'applications SA1). De façon générale, le chatbot BOTB communique (D16) avec le terminal TA et/ou avec le chatbot BOTA par l'intermédiaire du réseau R2, et plus particulièrement via le serveur d'applications SA2 dans cet exemple de réalisation. Une relation de confiance existe de préférence entre l'opérateur du réseau R2 et le chatbot BOTB, cette confiance 25 étant par exemple établie à partir d'une authentification du chatbot BOTB réalisée au préalable auprès du réseau R2. En faisant passer les échanges émis par et à destination du chatbot BOTA par le réseau R2, l'utilisateur source UA et son chatbot BOTA ont ainsi la garantie de l'authenticité du chatbot BOTB. Dans l'exemple considéré ici, lors du traitement C16, le serveur d'applications SA2 30 assure un échange de données associées à l'utilisateur appelant UA et de données associées à l'utilisateur appelé UB entre l'agent conversationnel automatisé BOTB, d'une part, et le terminal TA et/ou le chatbot BOTA, d'autre part, de sorte à réaliser au moins une action prédéterminée. De façon avantageuse, lors de ce dialogue, le chatbot BOTB propose au moins un service donné à l'utilisateur source UA et/ou au chatbot BOTA, afin 35 par exemple de faciliter la mise en relation actuelle ou future de l'utilisateur source UA avec l'utilisateur cible UB. Dans un exemple particulier, ce dialogue comporte l'envoi par le serveur d'applications SA2, sous le contrôle du chatbot BOTB, d'une proposition 3 05 9862 23 d'exécuter au moins un service exécutable par le réseau de communication R2 de l'utilisateur cible UB. On comprend que diverses configurations sont envisageables dans le cadre de l'invention. Selon un exemple particulier, lors de l'étape D14 de détermination, si 5 l'utilisateur cible UB est déterminé comme n'étant pas disponible, le chatbot BOTB réalise au moins l'une des actions suivantes : o le chatbot BOTB obtient une donnée de disponibilité renseignant sur l'état de disponibilité (courant et/ou futur) de l'utilisateur cible UB, cette donnée correspondant par exemple à au moins un évènement EV reçu ou cette donnée 10 étant obtenue à partir d'un ou plusieurs évènements EV reçus. Le chatbot BOTB commande alors l'envoi (D16), par le serveur d'applications SA2, de ladite donnée de disponibilité à au moins l'un parmi le terminal TA et l'agent conversationnel automatisé BOTA. L'utilisateur source UA et/ou son chatbot BOTA prennent ainsi connaissance de l'état de disponibilité actuel et/ou futur de l'utilisateur cible UB. La 15 donnée de disponibilité peut indiquer si l'utilisateur cible UB est actuellement disponible ou non, en fonction par exemple du type de communication (appel téléphonique, email, SMS...) considéré. Cette donnée de disponibilité peut comporter un degré de probabilité que l'utilisateur cible UB sera disponible dans un point dans le temps déterminé (dans 10 minutes à compter de l'initiation de 20 l'appel par exemple), ce degré de probabilité étant préalablement déterminé par le chatbot BOTB, par exemple à partir des évènements EV et éventuellement des règles de traitement DN1. De cette manière, l'utilisateur source UA peut recontacter l'utilisateur cible UB à un moment approprié et optimiser ses chances de joindre l'utilisateur cible UB dans de bonnes conditions. 25 o le chatbot BOTB envoie une notification de communication à un réseau de communication (R3 par exemple) associé à l'utilisateur cible UB, autre que le réseau de communication R2. Cette notification permet d'informer l'utilisateur cible UB de la tentative de communication initiée par le premier terminal TA sur le réseau R2. Cette notification comporte par exemple l'identifiant ID-A de 30 l'utilisateur appelant UA afin d'informer l'utilisateur cible UB de l'identité de l'appelant, ce qui permet à l'utilisateur cible UB de recontacter ultérieurement l'utilisateur source UA si besoin. o le chatbot BOTB définit, par l'intermédiaire du serveur d'applications SA2, un rendez-vous en coopération avec le premier terminal TA ou avec l'agent 35 conversationnel automatisé BOTA, et le cas échéant il enregistre une nouvelle entrée indicative du rendez-vous dans des données d'agenda associées à l'utilisateur cible UB. Le chatbot BOTB envoie par exemple cette nouvelle entrée 3059862 24 d'agenda au serveur d'applications SA4 du réseau R4 pour mettre à jour l'agenda de l'utilisateur cible UB en conséquence. Dans un exemple particulier, le chatbot BOTB envoie vers le réseau R4 à destination de l'utilisateur cible UB une notification relative à ladite nouvelle entrée. L'utilisateur cible UB peut ainsi 5 prendre connaissance, à partir d'un terminal approprié (non représenté) connecté au réseau R4, du nouveau rendez-vous enregistré par son chatbot BOTB. o le chatbot BOTB détermine un identifiant (par exemple ID-B2 ou ID-B3) de l'utilisateur cible UB dans un réseau de communication (respectivement R2 ou R3) et commande l'envoi, par le serveur d'applications SA2, d'une invitation à 10 destination de l'utilisateur source UA, par exemple sur son terminal TA associé au réseau R1. Cette invitation comporte l'identifiant ID-B2 et/ou ID-B3 de l'utilisateur cible UB afin d'inviter l'utilisateur source UA à contacter l'utilisateur cible UB via le réseau de communication correspondant dont l'utilisateur cible UB est l'usager. L'utilisateur source UA peut ainsi tenter de contacter l'utilisateur cible UB sur un 15 réseau de communication autre que le réseau R2 initialement visé, optimisant ainsi les chances de joindre l'utilisateur cible dans de bonnes conditions. o Le chatbot BOT surveille l'état de disponibilité courant de l'utilisateur cible UB (à partir des évènements EV reçus) et, sur détection que l'état de disponibilité courant de l'utilisateur cible atteint un état prédéfini (par exemple état 20 « disponible » ou « disponible pour les appels téléphoniques »), le chatbot BOTB commande l'envoi, par le serveur d'applications SA2, d'une notification informant de l'état prédéfini à destination de l'utilisateur source UA, par exemple sur son terminal TA. De cette manière, l'utilisateur source UA est informé dès que l'utilisateur cible UB est disponible, et éventuellement sous quelle condition il est 25 disponible (type de communication acceptée etc.), ce qui permet de faciliter la mise en communications des deux parties. Parmi les actions possibles, le chatbot BOTB peut également causer l'envoi, par le serveur d'applications SA2, à destination de l'utilisateur source UA, d'un ou d'une pluralité d'actions prédéfinies parmi lesquelles l'utilisateur source UA pourra choisir en fonction du 30 cas d'espèce. Chaque action prédéfinie (ou option) proposée par le chatbot BOTB permet de faciliter les interactions entre les utilisateurs UA et UB. Ces propositions peuvent comporter au moins l'une quelconque parmi les exemples d'action décrits ci-avant (définition d'un rendez-vous, surveillance de l'état de disponibilité de l'utilisateur cible UB etc.). Ces propositions d'actions prédéfinies peuvent être adaptées par le chatbot BOTB 35 en fonction de divers critères tels que par exemple l'identité de l'utilisateur source UA, afin de personnaliser le traitement la communication. 3059862 25 Selon une variante de réalisation, le chatbot BOTB ne prend pas en compte l'identité de l'utilisateur source UA pour déterminer en D14 l'état de disponibilité de l'utilisateur source UB et/ou pour déterminer en D16 le traitement à appliquer. Tel est le cas par exemple lorsque l'identifiant ID-A de l'utilisateur source UA n'est pas renseigné 5 (communication anonyme) dans la requête RQ1 de communication envoyée en A2 (figures 1 et 4). Par ailleurs, comme déjà indiqué, l'invention s'applique à divers types de communication, de type texte, vocale, vidéo par exemple. Lorsque la communication initiée par un utilisateur source est un appel téléphonique par exemple, cette tentative de 10 communication peut viser un terminal particulier de l'utilisateur cible. Des variantes sont toutefois possibles selon lesquelles la tentative de communication initiée par l'utilisateur source vise une identité d'un utilisateur cible qui est indépendante d'un terminal donné. Ainsi, selon un mode de réalisation particulier, la communication initiée par l'utilisateur source UA en A2 est par exemple un message de type email, qui vise une identité d'un 15 destinataire, cette identité étant indépendante du terminal pouvant être utilisé par l'utilisateur cible UB. Dans ce cas particulier, le serveur d'applications SA2 reçoit l'email en C4 puis demande en C6 au chatbot BOTB de traiter cet email (D7-D16) de façon analogue à celle décrite ci-avant en référence à un appel vocal. L'invention permet ainsi à l'utilisateur UA à l'origine de l'email d'être informé de lIndisponibilité courante du 20 destinataire UB, d'un autre moyen de communication qu'il est invité à utiliser pour joindre le destinataire UB et/ou encore, un autre moment plus approprié pour contacter le destinataire UB. Si le chatbot BOTA est mis en oeuvre, ce dernier est aussi en mesure de coopérer avec le chatbot BOTA pour offrir des services à l'utilisateur UA et/ou à l'utilisateur UB. 25 La présente invention permet de faciliter la mise en relation de deux utilisateurs (voire plus de deux utilisateurs). Une communication initiée par un utilisateur appelant peut être traitée en temps réel par l'agent conversationnel automatisé de l'utilisateur cible afin d'optimiser les chances pour l'utilisateur appelant de rentrer en contact avec l'utilisateur appelé, et ce dans les meilleurs conditions possibles. Un utilisateur appelant 30 est ainsi moins susceptible d'hésiter à contacter un tiers dans la mesure où l'appel sera traité selon les souhaits prédéfinis du tiers. L'agent conversationnel automatisé de l'utilisateur cible peut fournir toutes les informations nécessaires à l'utilisateur appelant sous la forme d'une notification simple, ou sous la forme d'un dialogue interactif. En particulier, selon le paramétrage choisi, l'agent conversationnel automatisé de l'utilisateur 35 cible pourra inviter l'utilisateur appelant à tenter une nouvelle communication à un moment particulier, à tenter une communication via un autre réseau de communication ou à destination d'un autre identifiant. 3059862 26 De manière générale, divers services peuvent être mis en oeuvre par les chatbots BOTA et BOTB coopérant ensemble, ou alternativement par le chatbot BOTB sans l'intervention du chatbot BOTA. Les chatbots BOTA et BOTB peuvent par exemple dialoguer ensemble pour définir un rendez-vous, réserver une ressource quelconque 5 (achat ticket de transport, réservation d'une salle de réunion ou d'une place à un évènement etc.) et prévenir chacun leur utilisateur respectif des dispositions qui ont été prises, éventuellement sous réserve de validation de la part des utilisateurs concernés. Dans un exemple particulier, le chatbot BOTB, et éventuellement le chatbot BOTA lorsque celui-ci est mis en oeuvre, s'appuie sur une intelligence artificielle pour prendre 10 des décisions et traiter chaque communication de la façon la plus appropriée. Le chatbot BOTB par exemple peut apprendre au cours du temps la meilleure manière de traiter chaque situation donnée et ainsi adapter en conséquence son comportement à une situation ultérieure. Par ailleurs, on notera que la mise en oeuvre d'une synthèse vocale et/ou d'une 15 reconnaissance vocale sont possibles pour permettre un dialogue aisé entre l'utilisateur source UA et le chatbot BOTB de l'utilisateur cible UB. Dans un premier exemple de réalisation, la communication initiée par l'utilisateur source UA est de type vocale et, lors dudit contrôle à distance D16 (figure 4), l'agent conversationnel automatisé BOTB commande au serveur d'applications SA1 la réalisation 20 d'une synthèse vocale à partir de données texte, et la réalisation d'une reconnaissance vocale de données vocales reçues par le serveur d'applications SA1 depuis le premier terminal TA. Autrement dit, dans ce premier cas, c'est le serveur d'applications SA2 qui se charge de faire le traitement sur la voix, en réalisant la synthèse vocale pour générer de la voix à l'attention de l'utilisateur cible et pour reconnaître la voix émise par l'utilisateur 25 source UA. Selon un deuxième exemple de réalisation, la communication initiée par l'utilisateur source UA est de type vocale et, lors dudit contrôle à distance D16 (figure 4), l'agent conversationnel automatisé BOTB envoie au serveur d'applications SA2 des données vocales (générées par BOTB) pour transmission au terminal source TA, et réalise une 30 reconnaissance vocale de données vocales reçues depuis le terminal source TA via le serveur d'applications SA2. Autrement dit, dans ce deuxième cas, c'est le chatbot BOTB qui se charge de faire le traitement sur la voix, en réalisant la synthèse vocale pour générer de la voix à l'attention de l'utilisateur cible et pour reconnaître la voix émise par l'utilisateur source UA. 35 Quel que soit le mode de réalisation considéré, le chatbot BOTB de l'utilisateur cible UB peut être configuré pour adapter la langue de dialogue en fonction l'utilisateur source UA, par exemple en tenant compte de l'identifiant ID-A du terminal TA. 3059862 27 Par ailleurs, selon une variante du mode de réalisation représenté en figure 4, le chatbot BOTB est configuré pour vérifier via le serveur d'applications SA2 si l'utilisateur cible UB est actuellement disponible sur son terminal TB1 en réponse à la requête RQ1 de communication émise par le terminal source TA. Pour ce faire, le chatbot BOTB envoie 5 une commande au serveur d'applications SA2 visant à établir, en réponse à ladite requête RQ1 de communication, une communication entre les terminaux TA et TB1. Sur réception de cette commande, le serveur SA2 tente d'établir ladite communication. Le chatbot BOTB déclenche en outre un décompte de temps à compter de l'envoi de ladite commande visant à établir une communication entre les terminaux TA et TB1. En l'absence de 10 réponse positive du terminal TB1 de l'utilisateur cible UB (par exemple, l'utilisateur cible UB décroche son téléphone) après un délai prédéfini (30 secondes par exemple), le chatbot BOTB détermine (D14) alors que l'utilisateur cible UB n'est pas actuellement disponible. Le chatbot BOTB peut alors déterminer (D14) la disponibilité future de l'utilisateur cible UB à partir du ou des évènements EV reçus (D7) et piloter (D16) le 15 serveur d'applications SA2 comme déjà expliqué en référence à la figure 4. Selon une variante du mode de réalisation représenté en figure 4, le chatbot BOTB de l'utilisateur cible UB détermine en D16 un niveau d'urgence de la requête RQ1 de communication à partir de l'identifiant ID-B1 de l'utilisateur source. Ce niveau d'urgence peut est déterminé à partir des règles de traitement DN1 (figure 1), en prenant compte 20 divers critères prédéfinis (la date/l'heure, le réseau ou le terminal sur lequel l'utilisateur cible est contacté etc.). Si le niveau d'urgence atteint un niveau prédéfini (par exemple un niveau 3 d'urgence sur une échelle de 5), le chatbot BOTB cause l'envoi d'une notification d'urgence à l'attention de l'utilisateur cible UB via le réseau de communications R2 (par l'intermédiaire du serveur d'applications SA2), ou via l'un parmi les autres réseaux R3, R4 25 de l'utilisateur cible UB. L'utilisateur cible UB peut ainsi juger de l'importance d'une communication entrante et traiter en priorité les communications qu'il juge importante. Un homme du métier comprendra que les modes de réalisation et variantes décrits ci-avant ne constituent que des exemples non limitatifs de mise en oeuvre de l'invention. En particulier, l'homme du métier pourra envisager une quelconque adaptation ou 30 combinaison des modes de réalisation et variantes décrits ci-avant afin de répondre à un besoin bien particulier. REVENDICATIONS1. Procédé de traitement d'une communication, mis en oeuvre par un premier serveur d'applications (SA2), comprenant les étapes suivantes : réception (C4) d'une requête (RQ1) de communication provenant d'un premier terminal (TA) d'un utilisateur appelant (UA), ladite requête visant à établir une communication avec un deuxième terminal (TB1) d'un utilisateur cible (UB), le premier serveur d'applications (SA1) étant compris dans un réseau de communication (R2) associé au deuxième terminal (TB1) ; envoi (C6), à un premier agent conversationnel automatisé (BOTB) associé à l'utilisateur cible (UB), d'une commande de déclenchement (CMD1) pour activer ledit premier agent conversationnel automatisé, ce dernier étant situé hors du réseau de communication (R2) du deuxième terminal (TB1) ; et traitement (C16), sous le contrôle du premier agent conversationnel automatisé (BOTB), de la requête de communication (RQ1), ledit traitement comprenant l'établissement d'un dialogue entre le premier agent conversationnel automatisé (BOTB) et au moins l'un parmi le premier terminal (TA) et un deuxième agent conversationnel automatisé (BOTA) associé à l'utilisateur appelant (UA). 2. Procédé selon la revendication 1, comprenant un envoi (C8), au premier agent conversationnel automatisé (BOTB), d'au moins un évènement (EV1) indicatif de la disponibilité de l'utilisateur cible (UB) afin de permettre audit premier agent 25 conversationnel automatisé (BOTB) d'adapter ledit traitement en fonction dudit évènement. 3. Procédé selon la revendication 1 ou 2, comprenant un envoi (C6), au premier agent conversationnel automatisé (BOTB), d'un identifiant (ID-A) de l'utilisateur appelant 30 (UA) inclus dans la requête (RQ1) de communication afin de permettre audit premier agent conversationnel automatisé (BOTB) d'adapter ledit traitement en fonction de l'utilisateur appelant. 4. Procédé selon l'une quelconque des revendications 1 à 3, comprenant une 35 réception (C4) d'un identifiant (ID-BOTA) du deuxième agent conversationnel automatisé (BOTA) associé à l'utilisateur appelant (UA), ledit traitement comprenant l'établissement 3059862 29 d'une communication entre les premier et deuxième agents conversationnels automatisés (BOTB, BOTA) afin de traiter collectivement ladite requête (RQ1) de communication. 5. Procédé de traitement d'une communication, mis en oeuvre par un premier agent 5 conversationnel automatisé (BOTB), comprenant les étapes suivantes : réception d'une commande de déclenchement (CMD1) provenant d'un serveur d'applications (SA1), pour traiter une requête (RQ1) de communication provenant d'un premier terminal (TA) d'un utilisateur source (UA) visant à établir une communication avec un deuxième terminal (TB1) d'un utilisateur cible (UB), 10 ledit serveur d'applications (SA1) étant compris dans un réseau de communication (R2) associé au deuxième terminal (TB1) et ledit premier agent conversationnel automatisé (BOTB) étant situé hors dudit réseau de communication (R2) ; vérification que des évènements indicatifs de la disponibilité de l'utilisateur cible 15 ont été reçus en provenance du réseau de communication (R2) du deuxième. terminal (TB1) et en provenance d'au moins un autre réseau de communication (R3) associé à l'utilisateur cible ; détermination de l'état de disponibilité du deuxième utilisateur à partir d'au moins un dit évènement reçu ; et 20 contrôle à distance du serveur d'applications (SA2) pour réaliser un traitement de la requête de communication (RQ1) en fonction de l'état de disponibilité de l'utilisateur cible. 6. Procédé selon la revendication 5, comprenant une réception d'une pluralité de dits évènements indicatifs de la disponibilité de l'utilisateur cible, en provenance du réseau de communication (R2) du deuxième terminal (TB1) et en provenance dudit au moins un autre réseau de communication (R3) associé à l'utilisateur cible. 7. Procédé selon la revendication 5 ou 6, le traitement comprenant l'établissement 30 d'un dialogue entre le premier agent conversationnel automatisé (BOTB) et au moins l'un parmi le premier terminal (TA) et un deuxième agent conversationnel automatisé (BOTB) associé à l'utilisateur appelant (UA). 8. Procédé selon l'une quelconque des revendications 5 à 7, dans lequel lors de 35 l'étape de détermination, si l'utilisateur cible est déterminé comme n'étant pas disponible, le premier agent conversationnel automatisé (BOTB) réalise au moins l'une des actions suivantes : 3059862 obtention d'une donnée de disponibilité renseignant sur l'état de disponibilité de l'utilisateur cible (UB) et commande d'envoi, par le serveur d'applications (SA2), de ladite donnée de disponibilité à au moins l'un parmi le premier terminal (TA) et le deuxième agent conversationnel automatisé (BOTB) ; 5 envoi d'une notification de communication audit au moins un autre réseau de communication (R3) associé à l'utilisateur cible, ladite notification de communication informant de la tentative de communication initiée par le premier terminal (TA) ; définition, par l'intermédiaire du serveur d'applications (SA2), d'un rendez-vous en 10 coopération avec le premier terminal (TA) ou le deuxième agent conversationnel automatisé (BOTA), et enregistrement d'une nouvelle entrée indicative du rendez-vous dans des données d'agenda associées à l'utilisateur cible ; détermination d'un identifiant de l'utilisateur cible dans ledit au moins un autre réseau de communication (R3) et commande d'envoi, par le serveur d'applications 15 (SA2), d'une invitation comportant ledit identifiant pour inviter l'utilisateur appelant à contacter l'utilisateur cible via ledit au moins un autre réseau de communication ; et surveillance de l'état de disponibilité courant de l'utilisateur cible et, sur détection que l'état de disponibilité courant du deuxième utilisateur atteint un état prédéfini, 20 commande d'envoi, par le serveur d'applications (SA2), d'une notification informant de l'état prédéfini à l'attention de l'utilisateur appelant 9. Procédé selon l'une quelconque des revendications 5 à 8, comprenant une réception, en provenance du serveur d'applications (SA2), d'un identifiant (ID-A) de 25 l'utilisateur appelant (UA), ledit traitement causé par le premier agent conversationnel automatisé (BOTB) lors du contrôle à distance étant fonction dudit identifiant de l'utilisateur appelant. 10. Procédé selon la revendication 9, comprenant une détermination d'un niveau 30 d'urgence de la requête (RQ1) de communication à partir de l'identifiant (ID-A) de l'utilisateur appelant (UA) ; et si le niveau d'urgence atteint un niveau prédéfini, le premier agent conversationnel automatisé (BOTB) cause l'envoi, par le serveur d'applications (SA2), d'une notification d'urgence à l'attention de l'utilisateur cible (UB) via le réseau de communications (R2) ou 35 via ledit au moins un autre réseau de communications (R3). 3059862 31 11. Procédé selon l'une quelconque des revendications 5 à 10, comprenant une réception, en provenance du serveur d'applications (SA1), d'un identifiant (IDBOTA) du deuxième agent conversationnel automatisé (BOTA) associé à l'utilisateur appelant (UA), ladite étape de contrôle à distance comprenant l'établissement d'une communication entre 5 les premier et deuxième agents conversationnels automatisés (BOTB, BOTA) via le serveur d'applications (SA2) afin de traiter collectivement ladite requête (RQ1) de communication. 12. Procédé selon la revendication 11, dans lequel, lors dudit contrôle à distance, les 10 premier et deuxième agents conversationnels automatisés (BOTB, BOTA) échangent, via le serveur d'applications (SA2), des données associées aux utilisateurs appelant et cible de sorte à réaliser collectivement au moins une action prédéterminée. 13. Programme d'ordinateur (PG2 ; PG3) comportant des instructions pour l'exécution 15 des étapes d'un procédé selon l'une quelconque des revendications 1 à 12 lorsque ledit programme est exécuté'par un ordinateur. 14. Serveur d'applications (SA2) comprenant : un module de réception (MD2) configuré pour recevoir une requête (RQ1) de 20 communication provenant d'un premier terminal (TA) d'un utilisateur appelant (UA), ladite requête visant à établir une communication avec un deuxième terminal (TB1) d'un utilisateur cible (UB), le premier serveur d'applications (SA1) étant compris dans un réseau de communication (R2) associé au deuxième terminal (TB1) 25 un module d'envoi (MD4) configuré pour envoyer, à un premier agent conversationnel automatisé (BOTB) associé à l'utilisateur cible (UB), une commande de déclenchement (CMD1) pour activer ledit premier agent conversationnel automatisé, ce dernier étant situé hors du réseau de communication (R2) du deuxième terminal (TB1) ; et 30 un module de traitement (MD6) configuré pour réaliser un traitement de la requête de communication (RQ1) sous le contrôle du premier agent conversationnel automatisé (BOTB), ledit traitement comprenant l'établissement d'un dialogue entre le premier agent conversationnel automatisé (BOTB) et au moins l'un parmi le premier terminal (TA) et un deuxième agent conversationnel automatisé (BOTA) associé à l'utilisateur appelant (UA). 15. Agent conversationnel automatisé (BOTB) comprenant : 3059862 32 un module de réception (MD10) configuré pour recevoir une commande de déclenchement (CMD1) provenant d'un serveur d'applications (SA1), pour traiter une requête (RQ1) de communication provenant d'un premier terminal (TA) d'un utilisateur appelant (UA) visant à établir une communication avec un deuxième 5 terminal (TB1) d'un utilisateur cible (UB), ledit serveur d'applications (SA2) étant compris dans un réseau de communication (R2) associé au deuxième terminal (TB1) et ledit agent conversationnel automatisé (BOTB) étant situé hors dudit réseau de communication (R2) ; 10 un module de vérification (MD12) configuré pour vérifier si des évènements indicatifs de la disponibilité de l'utilisateur cible ont été reçus en provenance du réseau de communication (R2) du deuxième terminal (TB1) et en provenance d'au moins un autre réseau de communication (R3) associé à l'utilisateur cible ; un module de détermination (MD14) configuré pour déterminer l'état de 15 disponibilité du deuxième utilisateur à partir d'au moins un dit évènement reçu ; et un module de contrôle (MD16) configuré pour contrôler à distance le serveur d'applications (SA2) de sorte à réaliser un traitement de la requête de communication (RQ1) en fonction de l'état de disponibilité de l'utilisateur cible. 20