Brevet FR3116915A1 — publié le 20220603

Procédé de gestion d’un accès à une pluralité de bots (8), dans lequel une interface de recherche, exécutée sur un premier terminal (1), effectue ce qui suit. Lors d’un premier accès d’un utilisateur à l’interface de recherche : réception d’un identifiant associé à un terminal mobile cible (1, 1’) et d’une indication de consentement de l’utilisateur ; stockage sur le premier terminal de l’identifiant associé au terminal mobile cible et de l’indication de consentement ; et réception d’une demande de lancement d’une opération de recherche en vue de sélectionner un bot et d’ouvrir une conversation entre celui-ci et le terminal mobile cible. Lors d’un accès ultérieur : pré-affichage de l’identifiant et de l’indication de consentement stockés ; et réception d’une nouvelle demande de lancement de l’opération de recherche en vue de sélectionner un nouveau bot et d’ouvrir une conversation entre celui-ci et le terminal mobile cible. Figure 1 Procédé de gestion d’un accès à une pluralité de bots avec pré-affichage d’informations propres à l’utilisateur, produit programme d'ordinateur, médium de stockage et terminal correspondant. 1. DOMAINE TECHNIQUE Le domaine de l’invention est celui des bots. Un bot (contraction de « robot ») se définit comme un programme informatique (logiciel) opérant de manière autonome et automatique, et capable de traiter (c'est-à-dire de comprendre) des informations (un dialogue par exemple) et de déclencher des actions. La mission principale d’un bot consiste à effectuer des tâches précises de façon répétée. Les chatbots (aussi appelés « robots conversationnels ») sont une catégorie particulière de bots. Un chatbot est un programme informatique qui simule des conversations (par exemple en langage naturel) avec de vrais utilisateurs. Il sert notamment mais non exclusivement à résoudre des problèmes (par exemple pour un support client avant-vente et/ou après-vente), passer des commandes, etc. A l’origine, les chatbots se basaient sur des bibliothèques de questions/réponses avec des scénarios prédéfinis. Au fur et à mesure des progrès, grâce à l’intelligence artificielle, certains chatbots sont devenus capables d’analyser et comprendre les messages par le biais de traitement du langage naturel, et d’apprendre avec l’apprentissage automatique (« machine learning »). Plus précisément, l’invention concerne une solution de gestion d’un accès à une pluralité de bots (y compris des chatbots) par un utilisateur disposant d’au moins un terminal mobile. Par « terminal mobile », on entend notamment un smartphone ou une tablette. 2. ARRIÈRE-PLAN TECHNOLOGIQUE Actuellement, lorsqu’un utilisateur souhaite « lancer » un bot (c'est-à-dire communiquer (converser) avec un bot) depuis son terminal mobile, il est obligé à chaque fois de saisir un identifiant associé à son terminal mobile (par exemple un numéro de téléphone, une identité SIP URI (Session Initiation Protocol - Uniform Resource Identifier) ou autre), avant d’initialiser la communication (conversation) avec ce bot. A cet effet, le terminal mobile envoie une requête contenant l’identifiant qui lui est associé auprès d’un serveur de l’opérateur de télécommunications auprès duquel est abonné l’utilisateur, de manière à valider cet identifiant. Si cet identifiant est bien valide, le terminal mobile est alors mis en relation avec le bot, via un serveur de mise en relation contrôlé par le serveur de l’opérateur de télécommunications. A chaque lancement de bot, l’utilisateur doit également fournir explicitement son consentement, pour que le bot puisse joindre l’utilisateur sur l’identifiant (numéro de téléphone, identité SIP URI ou autre) que ce dernier fournit. L’obligation pour l’utilisateur de fournir l’identifiant associé à son terminal mobile et son consentement, à chaque lancement de bot, vise à garantir le respect du règlement général sur la protection des données (RGPD). Ainsi, l’utilisateur est protégé, c’est-à-dire qu’il est contacté par un bot seulement s’il le souhaite. Inversement, côté réseau, le service qui fournit le bot est également protégé, le bot ne conversant qu’avec des utilisateurs qui le souhaitent et dont l’identifiant précité a été validé. Malheureusement, cette gestion des données utilisateurs dans le respect du RGPD (avec obligation de saisie de l’identifiant précité et de fourniture du consentement), rend fastidieux l’usage des bots par l’utilisateur. Il y a donc un besoin de garantir le respect du RGPD tout en facilitant les actions demandées à l’utilisateur pour lancer des bots et pouvoir communiquer (converser) avec eux. 3. RÉSUMÉ Dans un mode de réalisation particulier de l’invention, il est proposé un procédé de gestion d’un accès à une pluralité de bots par un utilisateur, dans lequel une interface de recherche de bots, exécutée sur un premier terminal dont dispose l’utilisateur, effectue les étapes suivantes : lors d’un premier accès de l’utilisateur à l’interface de recherche de bots : réception, via une interface utilisateur, d’un identifiant associé à un terminal mobile cible et d’une indication de consentement de l’utilisateur, ledit terminal mobile cible appartenant au groupe comprenant le premier terminal s’il est de type mobile et au moins un deuxième terminal mobile différent du premier terminal ; stockage sur le premier terminal de l’identifiant associé au terminal mobile cible et de l’indication de consentement ; et réception, via l’interface utilisateur, d’une demande de lancement d’une opération de recherche en vue de sélectionner un des bots et d’ouvrir une conversation entre le terminal mobile cible et le bot sélectionné ; lors d’un accès ultérieur de l’utilisateur à l’interface de recherche de bots : pré-affichage, via l’interface utilisateur, de l’identifiant associé au terminal mobile cible et de l’indication de consentement stockés ; et réception, via l’interface utilisateur, d’une nouvelle demande de lancement de l’opération de recherche en vue de sélectionner à nouveau un des bots et d’ouvrir une conversation entre le terminal mobile cible et le bot nouvellement sélectionné. Ainsi, la solution proposée repose sur l’utilisation, dans une phase initiale dite de recherche, d’une interface de recherche de bots qui gère d’une part l’obtention d’informations propres à l’utilisateur (identifiant associé au terminal mobile cible et consentement) et d’autre part la recherche proprement dite (en lançant une opération de recherche qui va permettre la sélection d’un des bots et l’ouverture d’une conversation entre le terminal mobile cible et le bot sélectionné). Après chaque accès de l’utilisateur à l’interface de recherche de bots, celle-ci dispose donc d’un bot sélectionné et d’informations propres à l’utilisateur (identifiant associé au terminal mobile cible et consentement). Ces informations sont utilisées dans une phase suivante, dite de conversation, pour permettre (dans le respect du RGPD) l’ouverture d’une conversation entre le bot sélectionné et l’utilisateur, et plus précisément son terminal mobile cible. La solution proposée repose également sur le fait que le fonctionnement de l’interface de recherche de bots diffère selon qu’il s’agit d’un premier accès ou d’un accès ultérieur de l’utilisateur à cette interface de recherche : s’il s’agit d’un premier accès, l’utilisateur fournit les informations qui lui sont propres : identifiant associé au terminal mobile cible et indication de son consentement ; s’il s’agit d’un accès ultérieur, l’utilisateur n’a pas à fournir à nouveau les informations qui lui sont propres car celles-ci sont pré-affichées par l’interface de recherche (qui les avait stockées lors du premier accès), pour confirmation ou modification par l’utilisateur. Un avantage de la solution proposée est que l’utilisateur fournit une seule fois les informations qui lui sont propres (identifiant associé au terminal mobile cible et consentement), lors du premier accès. A chaque accès ultérieur, il n’a pas à les ressaisir. Il peut simplement les confirmer, mais si nécessaire il peut également les modifier. Un autre avantage de la solution proposée est que, côté réseau, elle offre une protection commune à tous les services fournissant les bots pouvant être recherchés. En effet, lors du premier accès, l’utilisateur fournit les informations qui lui sont propres (identifiant associé au terminal mobile cible et consentement) pour tous les bots qu’il va rechercher (aussi bien lors du premier accès que lors de chaque accès ultérieur) en vue de converser avec eux. Encore un autre avantage de la solution proposée est que le premier terminal qui exécute l’interface de recherche avec laquelle est effectuée la recherche de bots n’est pas obligatoirement le terminal mobile cible qui entre en conversation avec le bot sélectionné. Dans ce cas, le premier terminal peut être de type mobile ou fixe (ordinateur par exemple). C’est alors un deuxième terminal mobile qui est le terminal mobile cible. En d’autres termes, s’il le souhaite, l’utilisateur peut déporter la recherche de bots sur un premier terminal (mobile ou fixe) différent du terminal mobile cible utilisé pour converser avec les bots. Les avantages d’un tel déport peuvent être divers : économiser la batterie du terminal mobile cible ; économiser les frais de connexion mobile du terminal mobile cible (par exemple dans le cas d’un forfait mobile limité) ; permettre à l’utilisateur d’effectuer la recherche de bots même quand il ne dispose pas de son terminal mobile cible ou bien si celui n’est pas opérationnel (batterie déchargée par exemple) ou bien est en accès non mobile (Wifi, ADSL (Asymmetric Digital Subscriber Line), fibre…) ; utiliser un premier terminal plus facile d’utilisation (par exemple un terminal fixe de type ordinateur ou tablette) pour réaliser la recherche de bots ; ne pas divulguer, au moment de la recherche de bots, une identité particulière (professionnelle par exemple) liée à l’identifiant associé au terminal mobile cible ; etc. Selon une caractéristique particulière, dans l’étape de pré-affichage, l’identifiant pré-affiché est modifiable. Si l’étape de pré-affichage est suivie d’une étape de réception d’une modification, via l’interface utilisateur, de l’identifiant pré-affiché par un identifiant associé à un autre terminal mobile cible, alors la réception, via l’interface utilisateur, de la nouvelle demande de lancement de l’opération de recherche est en vue de sélectionner à nouveau un des bots et d’ouvrir une conversation entre ledit autre terminal mobile cible et le bot nouvellement sélectionné. Ainsi, l’utilisateur peut changer de terminal mobile cible, par exemple en fonction du type du bot sélectionné. Selon une caractéristique particulière, dans l’étape de pré-affichage, l’identifiant pré-affiché est modifiable. Si l’étape de pré-affichage est suivie d’une étape de réception d’une modification, via l’interface utilisateur, de l’identifiant pré-affiché par un autre identifiant associé au terminal mobile cible, alors la réception, via l’interface utilisateur, de la nouvelle demande de lancement de l’opération de recherche est en vue de sélectionner à nouveau un des bots et d’ouvrir une conversation entre le terminal mobile cible, sur ledit autre identifiant, et le bot nouvellement sélectionné. Ainsi, l’utilisateur peut choisir, par exemple en fonction du type du bot sélectionné, un identifiant parmi plusieurs associés au même terminal mobile cible (cas par exemple d’un terminal mobile cible équipé de plusieurs cartes SIM (« Subscriber Identification Module »)). Selon une caractéristique particulière, l’étape de réception, via l’interface utilisateur, de l’identifiant associé au terminal mobile cible et de l’indication de consentement de l’utilisateur, est suivie d’une étape de lancement d’une vérification, auprès d’un serveur d’un opérateur de télécommunication, de l’identifiant reçu, et en ce que seule une vérification positive de l’identifiant reçu autorise une exécution de l’étape de réception, via l’interface utilisateur, de la demande de lancement de l’opération de recherche. La vérification de l’identifiant associé au terminal mobile cible fourni par l’utilisateur permet d’éviter qu’un tiers malintentionné utilise les identifiants associés à des terminaux d’utilisateurs (sans l’accord de ces derniers) pour les faire entrer en conversation avec des bots liés à ce tiers malintentionné. Selon une caractéristique particulière, l’interface de recherche de bots est exécutée depuis un client de messagerie installé sur le premier terminal. De cette façon, l’interface de recherche de bots est aisément accessible pour l’utilisateur. Selon une caractéristique particulière, avant la réception de la demande de lancement de l’opération de recherche ou la réception de la nouvelle demande de lancement de l’opération de recherche, l’interface de recherche de bots effectue une étape d’affichage, via l’interface utilisateur, d’un lien vers des conditions générales s’appliquant à la pluralité de bots, ledit lien étant activable via l’interface utilisateur. De cette façon, on facilite la proposition d’accès de l’utilisateur aux conditions générales (« Terms and Conditions » en anglais) s’appliquant à la pluralité de bots, dans le respect du RGPD. Dans un autre mode de réalisation de l'invention, il est proposé un produit programme d'ordinateur qui comprend des instructions de code de programme pour la mise en œuvre du procédé précité, dans l’un quelconque de ses différents modes de réalisation, lorsque ledit programme est exécuté sur une machine de calcul (ordinateur, processeur, etc.) comprise dans un terminal. Dans un autre mode de réalisation de l'invention, il est proposé un médium de stockage lisible par ordinateur et non transitoire, stockant un programme d’ordinateur comprenant un jeu d’instructions exécutables par une machine de calcul (ordinateur, processeur, etc.) pour mettre en œuvre le procédé précité dans l’un quelconque de ses différents modes de réalisation. Dans un autre mode de réalisation de l'invention, il est proposé un premier terminal configuré pour gérer un accès à une pluralité de bots par un utilisateur, qui comprend une machine de calcul configurée pour exécuter une interface de recherche de bots effectuant les opérations suivantes : lors d’un premier accès de l’utilisateur à l’interface de recherche de bots : réception, via une interface utilisateur, d’un identifiant associé à un terminal mobile cible et d’une indication de consentement de l’utilisateur, ledit terminal mobile cible appartenant au groupe comprenant le premier terminal s’il est de type mobile et au moins un deuxième terminal mobile différent du premier terminal ; stockage sur le premier terminal de l’identifiant associé au terminal mobile cible et de l’indication de consentement ; et réception, via l’interface utilisateur, d’une demande de lancement d’une opération de recherche en vue de sélectionner un des bots et d’ouvrir une conversation entre le terminal mobile cible et le bot sélectionné ; lors d’un accès ultérieur de l’utilisateur à l’interface de recherche de bots : pré-affichage, via l’interface utilisateur, de l’identifiant associé au terminal mobile cible et de l’indication de consentement stockés ; et réception, via l’interface utilisateur, d’une nouvelle demande de lancement de l’opération de recherche en vue de sélectionner à nouveau un des bots et d’ouvrir une conversation entre le terminal mobile cible et le bot nouvellement sélectionné. Ce premier terminal mobile est apte à mettre en œuvre dans tous ses modes de réalisation le procédé de gestion d’un accès à une pluralité de bots qui vient d'être décrit. 4. LISTE DES FIGURES D’autres caractéristiques et avantages de l’invention apparaîtront à la lecture de la description suivante, donnée à titre d’exemple indicatif et non limitatif, et des dessins annexés, dans lesquels : illustre une première mise en œuvre de l’invention dans laquelle le numéro de téléphone qui est saisi et stocké lors d’un premier accès de l’utilisateur, est celui d’un terminal mobile cible identique au premier terminal sur lequel est exécutée l’interface de recherche de bots ; présente un organigramme d’un mode de réalisation particulier du procédé selon l’invention ; présente un exemple d’une première fenêtre d’interface de recherche, lors d’un premier accès de l’utilisateur et avant fourniture d’un numéro de téléphone du terminal mobile cible et d’un consentement ; présente un exemple d’une deuxième fenêtre d’interface de recherche, lors d’un premier accès de l’utilisateur et après fourniture d’un numéro de téléphone du terminal mobile cible et d’un consentement, dans le cas où le numéro de téléphone fourni est valide ; présente un exemple d’une troisième fenêtre d’interface de recherche, lors d’un premier accès de l’utilisateur et après fourniture d’un numéro de téléphone du terminal mobile cible et d’un consentement, dans le cas où le numéro de téléphone fourni n’est pas valide ; présente un exemple d’une quatrième fenêtre d’interface de recherche, lors d’un accès ultérieur de l’utilisateur et après pré-affichage du numéro de téléphone du terminal mobile cible et du consentement ; illustre une deuxième mise en œuvre de l’invention dans laquelle le numéro de téléphone qui est saisi et stocké lors d’un premier accès de l’utilisateur, est celui d’un terminal mobile cible différent du premier terminal sur lequel est exécutée l’interface de recherche de bots ; illustre un système permettant une mise en œuvre particulière de l’opération de recherche (lancée aux étapes 26 et 210 de la ) ; illustre une recherche par mot(s)-clef(s) dans le système de la ; présente un exemple de fenêtre d’interface utilisateur affichant le résultat d’une recherche par mot(s)-clef(s) ; illustre une recherche par catégorie(s) dans le système de la ; présente un exemple de fenêtre d’interface utilisateur invitant un utilisateur à choisir une catégorie ; présente un exemple de fenêtre d’interface utilisateur affichant le résultat d’une recherche par catégorie(s) ; illustre le principe général d’un serveur de médiation du système de la ; présente un organigramme d’un mode de réalisation particulier de l’opération de recherche, pour les opérations effectuées par le premier terminal ; et présente la structure des terminaux précités, selon un mode de réalisation particulier de l'invention. 5. DESCRIPTION DÉTAILLÉE Sur toutes les figures du présent document, les éléments et étapes identiques sont désignés par une même référence numérique. Dans la suite de la description, on considère à titre d’exemple non-limitatif le cas particulier où l’identifiant associé à un terminal mobile est un numéro de téléphone associé au terminal mobile. Ce numéro de téléphone est par exemple le MSISDN (Mobile Station International Subscriber Directory Number) attribué à une carte SIM (« Subscriber Identification Module ») insérée dans le terminal mobile. Le numéro de téléphone est par exemple au format « +33ZABPQMCDU ». La présente invention n’est pas limitée à cet exemple et s’applique également à tout type d’identifiant associé à un terminal mobile, notamment mais non exclusivement une identité SIP URI (Session Initiation Protocol - Uniform Resource Identifier), par exemple au format « sip:+33ZABPQMCDU@domain ». On présente maintenant, en relation avec la , une première mise en œuvre d’une solution de gestion d’un accès à une pluralité de bots par un utilisateur. Comme détaillé ci-après, dans cette première mise en œuvre, le numéro de téléphone qui est saisi et stocké lors d’un premier accès de l’utilisateur, est celui d’un terminal mobile cible identique à un premier terminal mobile 1 sur lequel est exécutée l’interface de recherche de bots. On suppose donc que l’utilisateur U dispose d’un premier terminal mobile 1 (par exemple un smartphone ou une tablette) qui exécute une interface de recherche de bots. Dans un mode de réalisation particulier, le premier terminal mobile 1 exécute un premier client de messagerie qui permet lui-même d’exécuter l’interface de recherche. Soit le premier client de messagerie intègre en natif l’interface de recherche, soit il fait appel à un navigateur (exécuté par le premier terminal mobile 1) pour lancer cette interface de recherche. Par « client de messagerie », on entend notamment mais non exclusivement un client de messagerie SMS (Short Message Service), un client de messagerie MMS (Multimedia Messaging Service), un client de messagerie RCS (Rich Communication Services) ou encore un client de messagerie instantanée (Facebook Messenger, Whatsapp, Skype, etc.). Comme détaillé par la suite (voir ), à chaque accès de l’utilisateur à l’interface de recherche, celle-ci permet, dans une phase de recherche (référencée I), d’une part l’obtention d’informations propres à l’utilisateur (numéro de téléphone du terminal mobile cible et consentement) et d’autre part la recherche proprement dite en lançant une opération de recherche (voir détails ci-dessous, avec les figures 8 à 15) en vue de sélectionner un des bots et d’ouvrir une conversation entre le terminal mobile cible et le bot sélectionné. Comme détaillé par la suite, les informations propres à l’utilisateur sont saisies par l’utilisateur lors du premier accès à l’interface de recherche de bots, puis sont pré-affichées (pour être confirmées ou modifiées) lors de chaque accès ultérieur à l’interface de recherche de bots. Puis, dans une phase de conversation (référencée II), une conversation est ouverte entre le bot sélectionné et le terminal mobile cible, dont le numéro de téléphone a été obtenu pendant la phase de recherche I. Pour converser avec le bot sélectionné, le terminal mobile cible exécute un client de messagerie compatible avec le canal de communication associé au bot sélectionné (par exemple, le canal de communication Skype associé à l’application Skype ou le canal de communication Messenger associé à l’application Skype). Sur la , les bots sélectionnés (un à chaque accès à l’interface de recherche) sont référencés B, B’ et B’’. Il s’agit par exemple de chatbots (robots conversationnels), mais l’invention n’est pas limitée à ce type particulier de bot. Ainsi, dans l’exemple de la , on a illustré trois accès successifs de l’utilisateur U à l’interface de recherche : lors du premier accès (A1), l’interface de recherche permet, dans la phase de recherche I, d’une part une saisie et un stockage d’informations propres à l’utilisateur (numéro de téléphone du terminal mobile cible 1 et consentement) et d’autre part une recherche aboutissant à la sélection du bot référencé B. Puis, dans la phase de conversation II, une conversation est ouverte entre le bot sélectionné B et le terminal mobile cible 1 ; lors du deuxième accès (A2), l’interface de recherche permet, dans la phase de recherche I, d’une part le pré-affichage (pour confirmation ou modification) des informations stockées lors du premier accès et d’autre part une recherche aboutissant à la sélection du bot référencé B’. Puis, dans la phase de conversation II, une conversation est ouverte entre le bot sélectionné B’ et le terminal mobile cible 1, en supposant ici que le numéro de téléphone pré-affiché a été confirmé pendant la phase de recherche I ; lors du troisième accès (A3), l’interface de recherche permet, dans la phase de recherche I, d’une part le pré-affichage (pour confirmation ou modification) des informations stockées lors du premier accès et d’autre part une recherche aboutissant à la sélection du bot référencé B’’. Puis, dans la phase de conversation II, une conversation est ouverte entre le bot sélectionné B’’ et le terminal mobile cible 1’, en supposant ici que le numéro de téléphone du terminal mobile cible 1 a été remplacé par celui d’un autre terminal mobile cible 1’ pendant la phase de recherche I ; … (d’autres accès, non illustrés, peuvent bien sûr suivre). La illustre une deuxième mise en œuvre d’une solution de gestion d’un accès à une pluralité de bots par un utilisateur. Elle se distingue de la première en ce que le numéro de téléphone qui est saisi et stocké lors du premier accès de l’utilisateur, est celui d’un terminal mobile cible 1’ différent du premier terminal mobile 1 sur lequel est exécutée l’interface de recherche de bots. Ainsi, dans l’exemple de la , on a illustré trois accès successifs de l’utilisateur U à l’interface de recherche : lors du premier accès (A1), l’interface de recherche permet, dans la phase de recherche I, d’une part une saisie et un stockage d’informations propres à l’utilisateur (numéro de téléphone de l’autre terminal mobile cible 1’ et consentement) et d’autre part une recherche aboutissant à la sélection du bot référencé B. Puis, dans la phase de conversation II, une conversation est ouverte entre le bot sélectionné B et l’autre terminal mobile cible 1’ ; lors du deuxième accès (A2), l’interface de recherche permet, dans la phase de recherche I, d’une part le pré-affichage (pour confirmation ou modification) des informations stockées lors du premier accès et d’autre part une recherche aboutissant à la sélection du bot référencé B’. Puis, dans la phase de conversation II, une conversation est ouverte entre le bot sélectionné B’ et l’autre terminal mobile cible 1’ en supposant ici que le numéro de téléphone pré-affiché a été confirmé pendant la phase de recherche I ; lors du troisième accès (A3), l’interface de recherche permet, dans la phase de recherche I, d’une part le pré-affichage (pour confirmation ou modification) des informations stockées lors du premier accès et d’autre part une recherche aboutissant à la sélection du bot référencé B’’. Puis, dans la phase de conversation II, une conversation est ouverte entre le bot sélectionné B’’ et encore un autre terminal mobile cible 1’’, en supposant ici que le numéro de téléphone de l’autre terminal mobile cible 1’ a été remplacé par celui de cet encore autre terminal mobile cible 1’’ pendant la phase de recherche I ; … (d’autres accès, non illustrés, peuvent bien sûr suivre). La présente un organigramme d’un mode de réalisation particulier du procédé selon l’invention. On détaille les différentes étapes (opérations) effectuées par l’interface de recherche de bots, elle-même exécutée par le premier terminal mobile 1 dans l’exemple de la , dans la phase de recherche I. Dans une étape 21, l’interface de recherche détecte un premier accès de l’utilisateur. La présente un exemple d’une première fenêtre d’interface de recherche 31 à ce stade, c'est-à-dire lors d’un premier accès de l’utilisateur et avant fourniture d’un numéro de téléphone (du terminal mobile cible) et d’un consentement. Les différentes zones suivantes n’ont donc pas encore été renseignées : zone de code pays (« Country Code ») 32, zone de numéro de téléphone mobile (« Mobile Phone Number ») 33, zone pour accepter les conditions générales (« I accept the Terms and Conditions ») 34 (avec un lien sur celles-ci), la zone pour que l’interface de recherche se souvienne du numéro de téléphone une fois saisi (« Remember my phone number ») 35. De même, le bouton 36 pour lancer une opération de recherche (« Go to Bot Directory ») n’est pas encore activable. Dans une étape 22, l’interface de recherche reçoit, via une interface utilisateur, des informations saisies par l’utilisateur et qui lui sont propres : numéro de téléphone du terminal mobile cible et indication de consentement. On se place ici à nouveau dans le mode de réalisation particulier considéré plus haut, dans lequel le premier terminal mobile 1 joue deux rôles : il exécute l’interface de recherche de bots et c’est le terminal mobile cible. Dans une étape 23, l’interface de recherche affiche, via l’interface utilisateur, les informations saisies à l’étape 22 ainsi qu’un lien vers des conditions générales (« Terms and Conditions » en anglais) s’appliquant à la pluralité de bots (aspects RGPD). Le lien est activable via l’interface utilisateur. La présente un exemple d’une deuxième fenêtre d’interface de recherche 41 à ce stade, c'est-à-dire lors d’un premier accès de l’utilisateur et après fourniture d’un numéro de téléphone (du terminal mobile cible) et d’un consentement. Les différentes zones suivantes ont donc été renseignées : saisie du code de la France dans la zone de code pays 32, saisie d’un numéro à neuf chiffres (« 123456789 ») dans la zone de numéro de téléphone mobile 33, case cochée dans la zone pour accepter les conditions générales 34, case cochée dans la zone pour que l’interface de recherche se souvienne du numéro de téléphone saisi 35. Dans cet exemple, on suppose que le numéro de téléphone fourni est valide, donc le bouton 36 pour lancer une opération de recherche est activable. La présente un exemple d’une troisième fenêtre d’interface de recherche 51 à ce stade, mais contrairement au cas de la , un numéro à dix chiffres (« 1234567896 »), non correct, a été saisi dans la zone de numéro de téléphone mobile 33. Ce numéro est détecté invalide (cf. message référencé 37 : « This phone number is not valid ») et en conséquence les cases des zones 34 et 35 ne peuvent pas être cochées et le bouton 36 pour lancer une opération de recherche n’est pas activable. De retour à la , dans une étape 24, l’interface de recherche lance une vérification, auprès d’un serveur d’un opérateur de télécommunication, du numéro de téléphone saisi. Seule une vérification positive du numéro de téléphone saisi autorise une exécution des étapes 25 et 26. Le principe de vérification peut prendre diverses formes (par exemple, une solution à code unique et limité dans le temps (OneTimePassword), une authentification déléguée, etc.), bien connues de l’homme du métier et donc non décrite en détail ici. Dans l’étape 25, l’interface de recherche stocke sur le premier terminal mobile 1 les informations saisies par l’utilisateur. Le stockage est par exemple effectué dans des zones de stockage connues de l’homme du métier (« local storage », « session storage », « cookies », etc.). Le principe de stockage local des informations saisies par l’utilisateur permet de gérer les abus ou la sécurité liés à l’usurpation d’identité (« spoofing »). Le stockage des informations liées à l’utilisateur reste associé au terminal qui effectue la recherche. Dans l’étape 26, l’interface de recherche reçoit, via l’interface utilisateur, une demande de lancement d’une opération de recherche (voir détails ci-dessous, avec les figures 8 à 15) en vue de sélectionner un des bots et d’ouvrir une conversation entre le terminal mobile cible et le bot sélectionné. Dans une étape 27, l’interface de recherche détecte un accès ultérieur de l’utilisateur. Dans une étape 28, l’interface de recherche pré-affiche, via l’interface utilisateur, les informations stockées à l’étape 25 (numéro de téléphone du terminal mobile cible et indication de consentement), ainsi que le lien précité vers les conditions générales (voir étape 23). La présente un exemple d’une quatrième fenêtre d’interface de recherche 61 à ce stade, c'est-à-dire lors d’un accès ultérieur de l’utilisateur et après pré-affichage du numéro de téléphone du terminal mobile cible et du consentement. Les zones 32 à 35 ont donc été renseignées automatiquement. Dans cet exemple, et comme dans le cas de la , le numéro de téléphone stocké étant valide, le bouton 36 pour lancer une opération de recherche est activable. Dans une étape 29 effectuée seulement si l’utilisateur souhaite modifier le numéro de téléphone pré-affiché, l’interface de recherche reçoit, via l’interface utilisateur, une modification du numéro de téléphone pré-affiché : soit par le numéro de téléphone d’un autre terminal mobile cible 1’ ; soit par un autre numéro de téléphone du terminal mobile cible 1. Dans une étape 210, l’interface de recherche reçoit, via l’interface utilisateur, une nouvelle demande de lancement de l’opération de recherche (voir détails ci-dessous, avec les figures 8 à 15) en vue de sélectionner à nouveau un des bots et d’ouvrir une conversation entre le bot sélectionné et : le terminal mobile cible 1, sur le numéro pré-affiché et non modifié, ou bien le terminal mobile cible 1 mais sur le numéro modifié à l’étape 29, ou bien l’autre terminal mobile cible 1’, sur le numéro modifié à l’étape 29. On présente maintenant, en relation avec la , un système permettant une mise en œuvre particulière de l’opération de recherche lancée aux étapes 26 et 210 de la . Dans l’exemple de la , le système comprend : au moins le terminal mobile 1 qui, dans le mode de réalisation particulier considéré et comme déjà discuté plus haut, joue deux rôles : c’est le terminal (appelé plus haut « premier terminal ») qui exécute l’interface de recherche de bots et c’est également le terminal mobile cible ; il héberge un ou plusieurs clients de messagerie compatibles chacun avec un canal de communication propre ; un ensemble 2 de serveurs frontaux (« front-end server » en anglais) assurant des fonctions de découverte de bots quand ils reçoivent des requêtes de recherche en provenance du terminal mobile 1 en tant que terminal qui exécute l’interface de recherche de bots, via un canal de recherche 10 indépendant du ou des canaux de communication avec le(s)quel(s) est(sont) compatible(s) le(s) client(s) de messagerie installé(s) sur le terminal mobile 1. Dans l’exemple illustré, l’ensemble 2 de serveurs frontaux comprend au moins un serveur de recherche textuelle 3 et au moins un serveur de recherche graphique 4. Ces serveurs 3 et 4 permettent également de passer à un serveur de médiation 7, via un serveur d’arrière-plan 5, l’information du numéro de téléphone du terminal mobile 1 (du fait qu’il s’agit du terminal mobile cible), pour la mise en relation du bot sélectionné avec l’utilisateur du terminal mobile 1 ; au moins un serveur d’arrière-plan 5 (« back-end server » en anglais) coopérant avec une base de données DB (contenant elle-même des données relatives à une pluralité de bots, avec par exemple pour chacun un identifiant, un logo, des informations descriptives, etc.) ; le serveur d’arrière-plan 5 est interrogé par les serveurs de recherche 3 et 4 pour permettre à ces derniers de répondre, via le canal de recherche 10, aux requêtes de recherche transmises par le terminal mobile 1 ; un réseau de communication 6 sur lequel est établi un canal de communication 9a sélectionné, à l’issue d’une recherche ayant permis de sélectionner un bot 8 et ce canal de communication 9a qui lui est associé ; au moins un bot 8 (celui sélectionné à l’issue de la recherche précitée) avec lequel un utilisateur du terminal mobile 1 (du fait qu’il s’agit du terminal mobile cible) peut communiquer ; dans la suite de la description, on suppose qu’il s’agit d’un chatbot (robot conversationnel), mais l’invention n’est pas limitée à ce type particulier de bot ; et au moins un serveur de médiation 7, effectuant une adaptation entre le canal de communication sélectionné 9a, qui relie le terminal mobile 1 (du fait qu’il s’agit du terminal mobile cible) et le serveur de médiation 7, et un canal de substitution 9b qui relie le serveur de médiation 7 au chatbot 8. Pour ce faire, le serveur de médiation 7 communique avec le serveur d’arrière-plan 5. L’accolade référencée I indique la branche d’équipements utilisée dans le cas d’une recherche textuelle et comprenant les éléments suivants : le terminal mobile 1, le serveur de recherche textuelle 3, le serveur d’arrière-plan 5 et la base de données DB. L’accolade référencée II indique la branche d’équipements utilisée dans le cas d’une recherche graphique et comprenant les éléments suivants : le terminal mobile 1, le serveur de recherche graphique 4, le serveur d’arrière-plan 5 et la base de données DB. La illustre également une variante de réalisation dans laquelle le terminal 1, qui dans ce cas peut être de type fixe ou mobile, exécute l’interface de recherche de bots, mais ne joue pas le rôle du terminal mobile cible. C’est un autre terminal mobile, référencé 1’ sur la , qui est le terminal mobile cible et qui de ce fait communique avec le bot sélectionné 8, via le canal de communication sélectionné 9a. La présente un organigramme d’un mode de réalisation particulier de l’opération de recherche de bots selon l’invention, pour les opérations effectuées par le terminal mobile 1 (« premier terminal »). On se place ici à nouveau dans le mode de réalisation particulier considéré plus haut, dans lequel le terminal mobile 1 joue deux rôles, c’est-à-dire qu’il exécute l’interface de recherche de bots et qu’il est le terminal mobile cible. Dans une étape 151, le terminal mobile 1 transmet au moins une requête de recherche à au moins un des serveurs de recherche de bots 3 et 4, via le canal de recherche 10 qui est indépendant du ou des canaux de communication 9a avec le(s)quel(s) est(sont) compatible(s) le(s) client(s) de messagerie installé(s) sur le terminal mobile 1. Divers types de requête de recherche peuvent être envisagés : requête de recherche par mot(s)-clef(s), requête de recherche par catégorie(s) ou encore requête pour engager une conversation avec un bot de recherche (par exemple un chatbot de recherche offrant un service de recherche d’autres chatbots, rendue par une mécanique propre non décrite dans le présent document). Dans une étape 152, le terminal mobile 1 reçoit, via le canal de recherche 10 et en provenance du ou des serveurs de recherche de bots 3 et 4, un résultat de recherche comprenant au moins un couple comprenant un bot et un canal de communication associé. Il s’agit par exemple d’une liste de couples comprenant chacun un chatbot (représenté par exemple par son identifiant et/ou son logo) et un canal de communication associé. Un même chatbot peut être mentionné dans différents couples, à chaque fois avec un canal de communication distinct. Le résultat peut aussi parfois comprendre un unique couple. Les différents bots formant le résultat de la recherche peuvent faire l’objet d’un tri et d’une présentation selon différents critères paramétrables (tri et hiérarchisation par valorisation de l’intérêt d’une marque, sponsorisation d’une marque, critères de géolocalisation, etc.). Dans une étape 153, le terminal mobile 1 sélectionne, dans le résultat de recherche, un couple comprenant un bot et un canal de communication associé. Dans l’exemple de la , on suppose que le couple sélectionné comprend le chatbot 8 et le canal de communication 9a (il s’agit par exemple du chatbot « Orange Football Club » avec lequel l’application Facebook Messenger, exécutée sur le terminal mobile 1, va communiquer en utilisant le canal de communication Messenger). Dans une implémentation particulière, la sélection effectuée à l’étape 153 (sélection d’un couple comprenant un bot et un canal de communication associé) est fonction d’une information de choix reçue par le terminal mobile 1 via une interface utilisateur. Dans une variante, la sélection effectuée à l’étape 153 est fonction d’un choix automatique effectué par le terminal mobile 1 en fonction d’au moins un critère de choix (par exemple choix d’un couple comprenant un canal de communication avec lequel est compatible un client de messagerie en cours d’utilisation, ou encore choix d’un couple comprenant un canal de communication avec lequel est compatible un client de messagerie par défaut). Dans une étape 154, le terminal mobile 1 lance l’ouverture d’une conversation entre le terminal mobile 1, en tant que terminal mobile cible, et le bot 8 du couple sélectionné, en utilisant le canal de communication 9a du couple sélectionné (dans l’exemple précité, le canal de communication Messenger avec lequel est compatible l’application Facebook Messenger). Dans la variante de réalisation précitée, dans laquelle le terminal 1 exécute l’interface de recherche de bots, mais le terminal mobile cible est un autre terminal mobile 1’, l’étape 154 est légèrement différente : le terminal mobile 1 lance l’ouverture d’une conversation entre le terminal mobile cible 1’ et le bot 8 du couple sélectionné, en utilisant le canal de communication 9a du couple sélectionné. Dans une mise en œuvre particulière illustrée sur la , l’ouverture de la conversation avec le bot 8 du couple sélectionné est effectuée en utilisant le serveur de médiation 7, qui effectue une adaptation entre d’une part le canal de communication 9a du couple sélectionné (premier canal situé entre le terminal mobile cible (terminal mobile 1 ou terminal mobile 1’) et le serveur de médiation 7) et d’autre part le canal de substitution 9b (deuxième canal situé entre le serveur de médiation 7 et le chatbot 8 du couple sélectionné). Le serveur de médiation 7 initie la conversation en envoyant un message, via le canal de communication sélectionné 9a, vers le terminal mobile cible (terminal 1 ou terminal 1’) de l’utilisateur. Le serveur de médiation 7 a préalablement obtenu le numéro de téléphone du terminal mobile cible et un identifiant du chatbot 8, grâce aux données échangées avec les serveurs de recherche 3 et 4 et avec le serveur d’arrière-plan 5 (voir étapes 151 à 153). Dans une variante, l’ouverture de la conversation est effectuée sans le serveur de médiation 7, c'est-à-dire avec un canal de communication reliant le terminal mobile cible (terminal mobile 1 ou terminal mobile 1’) et le chatbot 8. Le terminal mobile cible a préalablement obtenu un identifiant du chatbot 8 permettant de le joindre directement, grâce aux données échangées avec les serveurs de recherche 3 et 4 et avec le serveur d’arrière-plan 5 (voir étapes 151 à 153). Un inconvénient de cette variante est que le chatbot 8 est développé de manière spécifique à un canal de communication et n’est accessible qu’à travers celui-ci. Pour une accessibilité via d’autres canaux de communication, il faut donc développer plusieurs chatbots possédant sensiblement les mêmes fonctionnalités mais propres chacun à un canal de communication particulier. La mise en œuvre avec le serveur de médiation 7 a précisément pour but de pallier cet inconvénient, en permettant au bot sélectionné 8 d’être en conversation avec un client de messagerie exécuté sur le terminal mobile cible, qui n’est pas obligatoirement compatible avec le canal de communication 9b pour lequel a été développé le bot 8 (l’adaptation à ce canal de communication 9b étant réalisée par le serveur de médiation 7). Dans une première implémentation, le terminal mobile 1 exécute un client de messagerie (appelé ci-après « premier client de messagerie ») qui intègre en natif l’interface de recherche qui effectue les étapes 151 à 153. Dans une deuxième implémentation, le terminal mobile 1 exécute un client de messagerie (également appelé ci-après « premier client de messagerie ») qui n’intègre pas en natif l’interface de recherche précitée mais fait appel à un navigateur exécuté par le terminal mobile pour lancer cette interface de recherche qui effectue les étapes 151 à 153. Si le canal de communication du couple sélectionné à l’étape 153 est différent du canal de communication avec lequel est compatible le premier client de messagerie, le terminal mobile 1, en tant que terminal mobile cible, effectue l’ouverture de la conversation à l’aide d’un second client de messagerie compatible avec le canal de communication du couple sélectionné. Par exemple, si le premier client de messagerie au sens précité est l’application Skype (compatible avec le canal de communication Skype) et si le couple sélectionné à l’étape 153 comprend le chatbot « Orange Football Club » 8 et le canal de communication Messenger, alors le terminal mobile 1 effectue, dans l’étape 154, l’ouverture de la conversation avec le chatbot 8 à l’aide de l’application Skype qui constitue le second client de messagerie compatible au sens précité. La illustre une recherche par mot(s)-clef(s) (aussi appelée « recherche textuelle ») dans le système de la . Le terminal mobile 1 transmet au serveur de recherche textuelle 3 (via le canal de recherche 10, cf. ) une requête de recherche comportant au moins un mot-clef fourni par l’utilisateur via une interface utilisateur d’un client de messagerie exécuté par le terminal mobile 1. Pour répondre à cette requête, le serveur de recherche textuelle 3 interroge le serveur d’arrière-plan 5 (qui coopère avec la base de données DB) et obtient en retour des éléments de réponse permettant de construire une liste de bots en relation avec le mot-clef fourni. Le serveur de recherche textuelle 3 retourne au terminal mobile 1 une réponse comportant cette liste de bots, en précisant pour chacun un canal de communication associé. En d’autres termes, la réponse comprend une liste de couples comprenant chacun un bot et un canal de communication associé. La présente un exemple de fenêtre d’interface utilisateur 101 affichant le résultat d’une recherche par mot(s)-clef(s). On suppose dans cet exemple que l’utilisateur a recherché un bot relatif au centre d’intérêt « football ». Depuis le client de messagerie exécuté sur son terminal mobile 1, l’utilisateur a par exemple entré le mot-clef « foot » (voir la zone de recherche référencée 102). La requête de recherche qui a été générée était par exemple au format décrit dans le document de la GSMA RCC.07 (exemple de requête : https://domain/?ho=...&client_version=...&client_vendor=...&start=0&num=10&i=...&q=foot). La requête a été envoyée vers le serveur de recherche textuelle 3 qui lui a retourné la liste des chatbots en relation avec le mot-clef « foot ». Cette liste de chatbots est affichée à l’utilisateur, au sein de la fenêtre 101, dans la zone de résultat référencée 104. Dans cet exemple, le canal de communication associé à chaque chatbot de la liste n’est pas affiché dans la zone référencée 104. C’est par exemple parce que ne sont affichés que les chatbots dont le canal de communication associé est compatible avec le client de messagerie en cours d’utilisation (pour effectuer la recherche) ou avec au moins un des autres clients de messagerie installés sur le terminal. Une autre explication est que l’affichage des canaux de communication associés aux chatbots listés nécessite une action de l’utilisateur via l’interface utilisateur (par exemple un appui sur un bouton « + » affiché à proximité d’un identifiant et/ou un logo d’un chatbot donné permet d’afficher le canal de communication associé, voire une pluralité de canaux associés s’il s’agit d’un chatbot accessible via le serveur de médiation 7). Dans le cas où plusieurs canaux de communication sont affichés, si l’utilisateur choisit un canal qui n’est pas celui associé au client de messagerie en cours d’utilisation, alors le terminal mobile 1 effectue un basculement vers un autre client de messagerie associé au canal de communication choisi, permettant ainsi l’ouverture d’une conversation avec le chatbot donné. Dans l’exemple illustré, la fenêtre 101 comporte une autre zone de résultat, référencée 103, qui liste des discussions en relation avec le mot-clef « foot ». La illustre une recherche par catégorie(s) (aussi appelée « recherche graphique ») dans le système de la . Le terminal mobile 1 transmet au serveur de recherche graphique 4 (via le canal de recherche 10, cf. ), une requête de recherche comportant au moins une catégorie choisie par l’utilisateur via une interface utilisateur d’un client de messagerie exécuté par le terminal mobile 1. Pour répondre à cette requête, le serveur de recherche graphique 4 interroge le serveur d’arrière-plan 5 (qui coopère avec la base de données DB) et obtient en retour des éléments de réponse permettant de construire une liste de bots en relation avec la catégorie fournie. Le serveur de recherche graphique 4 retourne au terminal mobile 1 une réponse comportant cette liste de bots, en précisant pour chacun un canal de communication associé. On présente maintenant, en relation avec les figures 12 et 13, un exemple d’implémentation d’une recherche par catégorie(s). Depuis son client de messagerie exécuté sur son terminal mobile 1, l’interface de recherche ouvre une page (fenêtre d’interface utilisateur référencée 121 sur la ) qui offre un exemple d’organisation par catégories pour effectuer la recherche de bot. Une zone de recommandation 123 (« recommended ») permet de pousser des bots sponsorisés pour être directement joints. L’utilisateur peut affiner sa recherche en sélectionnant une catégorie parmi celles (125a, 125b …) listées dans la zone référencée 124, ou en entrant un mot-clef dans la zone de recherche référencée 122 et comportant une invitation à saisir un mot-clef (« find chatbot »). Dans le cas illustratif où l’utilisateur a sélectionné la catégorie « Santé & Forme » (« Health & Fitness »), la page suivante qui est affichée (fenêtre d’interface utilisateur référencée 131 sur la ) comporte une zone de résultat référencée 132. Dans cette dernière, une liste de chatbots est affichée à l’utilisateur. Chaque ligne correspond à un chatbot et comporte un logo, un nom et un bref descriptif de celui-ci, ainsi qu’un bouton de démarrage (« Start »), référencé 135a, 135b, 135c sur la . Dans cet exemple, et comme dans l’autre exemple discuté plus haut (voir ), le canal de communication associé à chaque chatbot de la liste n’est pas affiché. La illustre le principe général du serveur de médiation 7. On se place encore une fois dans le mode de réalisation particulier considéré plus haut, dans lequel le terminal mobile 1 joue deux rôles : il exécute l’interface de recherche de bots et c’est le terminal mobile cible. On suppose qu’un utilisateur 71 dispose du terminal mobile 1 sur lequel sont installés : une interface de recherche 72a, mettant en œuvre les étapes 151 à 154 de la figure 15 et utilisant un canal de recherche 73a et une plateforme associée 74a ; ainsi qu’un ou plusieurs clients de messagerie (RCS 72b, SMS 72c, Messenger 72d, Skype 72e, Whatsapp 72f, etc.), utilisant chacun un canal de communication propre (73b à 73f) et une plateforme de communication associée (74b à 74f). D’un premier côté, le serveur de médiation 7 est relié à chacun des canaux précités (73a à 73f) via la plateforme de communication associée (74a à 74f). D’un deuxième côté, le serveur de médiation 7 est relié, via des canaux de substitution 9b, à une pluralité de plateformes hébergeuses (75a à 75g), hébergeant chacune des bots. Dans l’exemple illustré, la plateforme hébergeuse 75a héberge notamment le chatbot 8 de la et est reliée, via le canal de substitution 9b, au serveur de médiation 7. Le rôle du serveur de médiation 7 est d’effectuer une adaptation de canal, de sorte que chaque bot, hébergé sur une des plateformes hébergeuses (75a à 75g), puisse communiquer, via au moins un (et préférentiellement plusieurs) des canaux de communication (73b à 73f), avec au moins un (et préférentiellement plusieurs) des clients de messagerie (72b à 72f) installés sur le terminal mobile 1 en tant que terminal mobile cible. Il évite la complexité d’avoir à développer et mettre en œuvre autant de bots que de canaux de communication (73b à 73f) à joindre. La présente la structure 160 des terminaux précités (1, 1’, 1’’), des serveurs de recherche 3 et 4, du serveur d’arrière-plan 5 et du serveur de médiation 7 selon un mode de réalisation particulier de l'invention. Cette structure 160 comprend une mémoire vive 161 (par exemple une mémoire RAM), une mémoire morte 163 (par exemple une mémoire ROM ou un disque dur) et une unité de traitement 161 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur 1630 stocké dans la mémoire morte 163. A l'initialisation, les instructions de code du programme d'ordinateur 1630 sont par exemple chargées dans la mémoire vive 161 avant d'être exécutées par le processeur de l'unité de traitement 161. Cette illustre seulement une manière particulière, parmi plusieurs possibles, d’implémenter les dispositifs précités (1, 1’, 1’’ 3, 4, 5 et 7). En effet, ils s’implémentent indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel). Dans le cas d’une implémentation sur une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d’instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur. En variante, le medium de stockage peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens. Alternativement, chaque medium de stockage peut être 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 d’un procédé conforme à l’invention. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet. Procédé de gestion d’un accès à une pluralité de bots par un utilisateur, caractérisé en ce qu’une interface de recherche de bots, exécutée sur un premier terminal dont dispose l’utilisateur, effectue les étapes suivantes : lors d’un premier accès (21) de l’utilisateur à l’interface de recherche de bots : réception (22), via une interface utilisateur, d’un identifiant associé à un terminal mobile cible et d’une indication de consentement de l’utilisateur, ledit terminal mobile cible appartenant au groupe comprenant le premier terminal s’il est de type mobile et au moins un deuxième terminal mobile différent du premier terminal ; stockage (25) sur le premier terminal de l’identifiant associé au terminal mobile cible et de l’indication de consentement ; et réception (26), via l’interface utilisateur, d’une demande de lancement d’une opération de recherche en vue de sélectionner un des bots et d’ouvrir une conversation entre le terminal mobile cible et le bot sélectionné ; lors d’un accès ultérieur (27) de l’utilisateur à l’interface de recherche de bots : pré-affichage (28), via l’interface utilisateur, de l’identifiant associé au terminal mobile cible et de l’indication de consentement stockés ; et réception (210), via l’interface utilisateur, d’une nouvelle demande de lancement de l’opération de recherche en vue de sélectionner à nouveau un des bots et d’ouvrir une conversation entre le terminal mobile cible et le bot nouvellement sélectionné. Procédé selon la revendication 1, caractérisé en ce que dans l’étape de pré-affichage (28) l’identifiant pré-affiché est modifiable, et en ce que, si l’étape de pré-affichage est suivie d’une étape de réception d’une modification (29), via l’interface utilisateur, de l’identifiant pré-affiché par un identifiant associé à un autre terminal mobile cible, alors la réception (210), via l’interface utilisateur, de la nouvelle demande de lancement de l’opération de recherche est en vue de sélectionner à nouveau un des bots et d’ouvrir une conversation entre ledit autre terminal mobile cible et le bot nouvellement sélectionné. Procédé selon la revendication 1, caractérisé en ce que dans l’étape de pré-affichage, l’identifiant pré-affiché est modifiable, et en ce que, si l’étape de pré-affichage est suivie d’une étape de réception d’une modification (29), via l’interface utilisateur, de l’identifiant pré-affiché par un autre identifiant associé au terminal mobile cible, alors la réception (210), via l’interface utilisateur, de la nouvelle demande de lancement de l’opération de recherche est en vue de sélectionner à nouveau un des bots et d’ouvrir une conversation entre le terminal mobile cible, sur ledit autre identifiant, et le bot nouvellement sélectionné. Procédé selon l’une quelconque des revendications 1 à 3, caractérisé en ce que l’étape de réception, via l’interface utilisateur, de l’identifiant associé au terminal mobile cible et de l’indication de consentement de l’utilisateur, est suivie d’une étape de lancement d’une vérification (24), auprès d’un serveur d’un opérateur de télécommunication, de l’identifiant reçu, et en ce que seule une vérification positive de l’identifiant reçu autorise une exécution de l’étape de réception, via l’interface utilisateur, de la demande de lancement de l’opération de recherche. Procédé selon l’une quelconque des revendications 1 à 4, caractérisé en ce que l’interface de recherche de bots est exécutée depuis un client de messagerie installé sur le premier terminal. Procédé selon l’une quelconque des revendications 1 à 5, caractérisé en ce que, avant la réception (26) de la demande de lancement de l’opération de recherche ou la réception (210) de la nouvelle demande de lancement de l’opération de recherche, l’interface de recherche de bots effectue une étape (23, 28) d’affichage, via l’interface utilisateur, d’un lien vers des conditions générales s’appliquant à la pluralité de bots, ledit lien étant activable via l’interface utilisateur. Produit programme d'ordinateur, comprenant des instructions de code de programme qui, quand elles sont exécutées par une machine de calcul, provoquent la réalisation du procédé selon l’une quelconque des revendications 1 à 6. Médium de stockage lisible par ordinateur et non transitoire, stockant le produit programme d’ordinateur selon la revendication 7. Premier terminal configuré pour gérer un accès à une pluralité de bots par un utilisateur, caractérisé en ce qu’il comprend une machine de calcul configurée pour exécuter une interface de recherche de bots effectuant les opérations suivantes : lors d’un premier accès de l’utilisateur à l’interface de recherche de bots : réception, via une interface utilisateur, d’un identifiant associé à un terminal mobile cible et d’une indication de consentement de l’utilisateur, ledit terminal mobile cible appartenant au groupe comprenant le premier terminal s’il est de type mobile et au moins un deuxième terminal mobile différent du premier terminal ; stockage sur le premier terminal de l’identifiant associé au terminal mobile cible et de l’indication de consentement ; et réception, via l’interface utilisateur, d’une demande de lancement d’une opération de recherche en vue de sélectionner un des bots et d’ouvrir une conversation entre le terminal mobile cible et le bot sélectionné ; lors d’un accès ultérieur de l’utilisateur à l’interface de recherche de bots : pré-affichage, via l’interface utilisateur, de l’identifiant associé au terminal mobile cible et de l’indication de consentement stockés ; et réception, via l’interface utilisateur, d’une nouvelle demande de lancement de l’opération de recherche en vue de sélectionner à nouveau un des bots et d’ouvrir une conversation entre le terminal mobile cible et le bot nouvellement sélectionné.