FR 3155333 A1 20250516 FR 2312312 A 20231110 Un procédé comprend: une détection, sur la base de données contextuelles à une interaction d’un utilisateur avec une application logicielle, d’une intention implicite de l’utilisateur de déclencher une opération relative à un produit ou un service; sur la base de la détection, une décision de déclenchement autonome de l’opération au nom de l’utilisateur sans requérir préalablement de consentement explicite de l’utilisateur; une transmission d’une requête d’analyse de risque à un module d’analyse de risque à base d’apprentissage automatique, la requête d’analyse de risque incluant les données contextuelles et des informations sur l’opération détectée; une réception en provenance du module d’analyse de risque d’un indicateur représentatif d’un niveau de risque que l’intention de l’utilisateur n’est pas de déclencher l’opération détectée; une prise de décision pour déterminer, sur la base au moins de l’indicateur, si l’opération est autorisée ou non. Figure pour l’abrégé: Fig. 6 Procédé et système de déclenchement autonome d’une opération La présente description concerne un procédé et système de déclenchement autonome d’au moins une opération et un procédé d’analyse de risque. Arrière-plan technique Différents types d’assistants virtuels peuvent être utilisés lorsqu’un utilisateur interagit avec une application logicielle (par exemple, une application web ou une application mobile) afin d’assister l’utilisateur relativement à des opérations susceptibles de correspondre à ses besoins et/ou de proposer automatiquement des opérations susceptibles de correspondre à ses besoins ou souhaits. Ces assistants virtuels reposent sur un système d’apprentissage automatique et peuvent interagir avec l’utilisateur, dans le but par exemple de faciliter et simplifier l’usage de l’application logicielle ou d’automatiser des tâches. Ces assistants virtuels peuvent toutefois avoir des capacités de prise de décision limitées, par exemple ne pas être capables de répondre aux besoins changeants d'un utilisateur en temps réel. En outre, ces assistants virtuels peuvent être conçus avec des objectifs (par exemple, des objectifs commerciaux) pouvant entrer en conflit avec les besoins effectifs ou l’intention de l'utilisateur. Par ailleurs, ces limitations ou défauts peuvent induire des problèmes de confiance et/ou de sécurisation pour les actions exécutées par ces assistants. Il apparaît un besoin d’améliorer l’expérience utilisateur lors de l’interaction avec une application logicielle associée à une fonctionnalité d’assistant virtuel tout en apportant un niveau de sécurité élevé pour le déclenchement d’opération. Résumé L'étendue de la protection est définie par les revendications. Selon un premier aspect, la présente description concerne un procédé comprenant: une détection, sur la base de données contextuelles à une interaction d’un utilisateur avec une application logicielle, d’une intention implicite de l’utilisateur de déclencher une opération relative à un produit ou un service; sur la base de la détection, une décision de déclenchement autonome de l’opération au nom de l’utilisateur sans requérir préalablement de consentement explicite de l’utilisateur; une transmission d’une requête d’analyse de risque à un module d’analyse de risque à base d’apprentissage automatique, la requête d’analyse de risque incluant les données contextuelles et des informations sur l’opération détectée; une réception en provenance du module d’analyse de risque d’un indicateur représentatif d’un niveau de risque que l’intention de l’utilisateur n’est pas de déclencher l’opération détectée; une prise de décision pour déterminer, sur la base au moins de l’indicateur, si l’opération est autorisée ou non. Dans un ou plusieurs modes de réalisation, lorsque l’opération est autorisée, un envoi d’une notification à un système informatique pour déclencher l’exécution de l’opération. Dans un ou plusieurs modes de réalisation, lorsque l’opération n’est pas autorisée, un envoi d’une notification à un système informatique pour déclencher l’exécution de l’opération. Dans un ou plusieurs modes de réalisation, lorsque l’indicateur est inférieur à une première valeur de seuil et supérieur à une deuxième valeur de seuil non nulle, un envoi vers l’utilisateur d’une demande de validation explicite du déclenchement de l’opération ; lorsque l’indicateur est supérieur à la première valeur de seuil, un envoi d’une notification de refus de l’opération ; lorsque l’indicateur est inférieur à la deuxième valeur de seuil, un envoi d’une notification à un système informatique pour déclencher l’exécution de l’opération. Dans un ou plusieurs modes de réalisation, le procédé comprend: une obtention d’au moins un paramètre de configuration définissant des droits accordés à l’application logicielle par l’utilisateur pour le déclenchement autonome d’opérations au nom de l’utilisateur; une configuration de l’application logicielle sur la base du paramètre de configuration. Dans un ou plusieurs modes de réalisation, dans lequel l’application logicielle est ou comprend un assistant virtuel et les données contextuelles comprennent un contenu d’une interaction avec l’assistant virtuel. Dans un ou plusieurs modes de réalisation, le niveau de risque est déterminé sur la base de points saillants d’une transcription d’un contenu texte d’une conversation et/ou interaction avec l’assistant virtuel et de scores évalués pour ces points saillants. Dans un ou plusieurs modes de réalisation, dans lequel la requête d’analyse inclut au moins un élément d’information parmi : des informations sur un profil utilisateur, des informations sur les préférences de l’utilisateur, des informations sur les usages de l’utilisateur, des informations sur une recommandation d’un produit ou service, des informations sur un historique d’opérations déclenchées pour l’utilisateur. Dans un ou plusieurs modes de réalisation, dans lequel l’opération est une transaction de paiement pour l’achat d’au moins un produit et/ou d’au moins un service et dans lequel la notification est une notification de paiement incluant par exemple un jeton de paiement. Dans un ou plusieurs modes de réalisation, le niveau de risque prend en compte d’une part le fait que l’achat semble répondre au besoin de l’utilisateur et d’autre part que l’intention de l’utilisateur est effectivement de procéder au paiement. Selon un autre aspect la présente description concerne un système comprenant des moyens informatiques de mise en œuvre d’un procédé selon le premier aspect. Les moyens informatiques peuvent comprendre des moyens logiciels et/ou des moyens matériels, par exemple des moyens électroniques. Les moyens électroniques peuvent comprendre par exemple un ou plusieurs circuits configurés pour exécuter une ou plusieurs ou toutes les étapes du procédé selon le premier aspect. Les moyens électroniques peuvent comprendre par exemple au moins un processeur et au moins une mémoire comprenant des instructions de programme configurées pour, lorsqu’elles sont exécutées par le processeur, causer l’exécution par le dispositif d’une ou plusieurs ou toutes les étapes du procédé selon le premier aspect. Selon un autre aspect, la présente description concerne un support d'enregistrement lisible par un processeur de données sur lequel est enregistré un programme comprenant des instructions de programme configurées pour causer l'exécution par le processeur de données d’une ou plusieurs ou toutes les étapes du procédé selon le premier aspect. Selon un autre aspect, la présente description concerne un programme d'ordinateur comportant des instructions de programme configurées pour causer l'exécution par un processeur de données d’une ou plusieurs ou toutes les étapes du procédé selon le premier aspect. Selon un deuxième aspect, la présente description concerne un procédé comprenant: une réception, en provenance d’une entité de vérification par un module d’analyse de risque à base d’apprentissage automatique, de données contextuelles à une interaction d’un utilisateur avec une application logicielle et d’informations sur une opération relative à un produit ou un service destinée à être exécutée, l’opération ayant été identifiée sur la base des données contextuelles; une génération par le module d’analyse de risque d’un indicateur représentatif d’un niveau de risque que l’intention de l’utilisateur ne soit pas de déclencher l’opération identifiée; une transmission de l’indicateur à l’entité de vérification. Selon un autre aspect la présente description concerne un dispositif comprenant des moyens informatiques de mise en œuvre d’un procédé selon le deuxième aspect. Les moyens informatiques peuvent comprendre des moyens logiciels et/ou des moyens matériels, par exemple des moyens électroniques. Les moyens électroniques peuvent comprendre par exemple un ou plusieurs circuits configurés pour exécuter une ou plusieurs ou toutes les étapes du procédé selon le deuxième aspect. Les moyens électroniques peuvent comprendre par exemple au moins un processeur et au moins une mémoire comprenant des instructions de programme configurées pour, lorsqu’elles sont exécutées par le processeur, causer l’exécution par le dispositif d’une ou plusieurs ou toutes les étapes du procédé selon le deuxième aspect. Selon un autre aspect, la présente description concerne un support d'enregistrement lisible par un processeur de données sur lequel est enregistré un programme comprenant des instructions de programme configurées pour causer l'exécution par le processeur de données d’une ou plusieurs ou toutes les étapes du procédé selon le deuxième aspect. Selon un autre aspect, la présente description concerne un programme d'ordinateur comportant des instructions de programme configurées pour causer l'exécution par un processeur de données d’une ou plusieurs ou toutes les étapes du procédé selon le deuxième aspect. Brève description des figures D'autres caractéristiques et avantages résulteront de la description détaillée qui va suivre, effectuée sur la base de modes de réalisation et d’exemples donnés à titre illustratif et non limitatif, en faisant référence aux figures annexées. FIG. 1 représente schématiquement un système de déclenchement d’opération selon exemple de réalisation. FIG. 2 est un organigramme illustrant un système et procédé de déclenchement d’opération selon un exemple de réalisation. FIG. 3 est un schéma illustrant un système et procédé de déclenchement d’opération selon un exemple de réalisation FIG. 4 est un schéma illustrant un système et procédé de déclenchement d’opération selon un exemple de réalisation. FIG. 5 est un schéma illustrant un système et procédé de déclenchement d’opération selon un exemple de réalisation. FIG. 6 est un organigramme d’un procédé de déclenchement d’opération selon un exemple de réalisation. FIG. 7 est un organigramme d’un procédé d’analyse de risque selon un exemple de réalisation. FIG. 8 est un organigramme d’un procédé d’analyse de risque selon un exemple de réalisation. FIG. 9 est un organigramme d’un procédé d’analyse de risque selon un exemple de réalisation. Description détaillée Divers exemples de réalisation vont maintenant être décrits plus en détail en référence aux dessins. Des détails structurels et/ou fonctionnels spécifiques divulgués ici sont utilisés pour permettre une compréhension des différents modes de réalisation possibles. Cependant, la personne du métier comprendra que les exemples de réalisation peuvent subir diverses modifications et peuvent être mis en œuvre sans tous ces détails. La présente description concerne des procédés et systèmes permettant un déclenchement automatique de l’exécution d’une ou plusieurs opérations sur la base de données contextuelles à une interaction de l’utilisateur avec une application logicielle sans qu’une action de validation explicite de l’utilisateur ne soit requise préalablement à ce déclenchement. On parlera plus précisément dans le contexte de ce document de «déclenchement autonome» de l’exécution d’une opération. L’opération à exécuter peut être n’importe quelle opération, simple ou complexe. L’opération à exécuter est par exemple une transaction (par exemple une transaction bancaire, une transaction de paiement, etc), un achat de produit ou de services, une transmission de message et/ou de données ou documents, un accès à un ou des contenus multimédia, un transfert d’un ou plusieurs contenus multimédia, un accès à un compte utilisateur, la génération d’un document signé, etc. L’opération à exécuter peut être une opération proposée par un prestataire avec lequel l’utilisateur interagit au moyen de l’application logicielle. L’application logicielle peut être elle-même un assistant virtuel ou inclure des fonctions d’un assistant virtuel ou être associée à un assistant virtuel. Dans un ou plusieurs modes de réalisation, l’opération à exécuter est déclenchée sans action de validation explicite de la part de l’utilisateur: l’intention de l’utilisateur relativement à l’exécution de l’opération est détectée sur la base des données contextuelles d’interaction mais aucune action explicite n’est nécessaire de la part de l’utilisateur pour formuler son accord ou confirmer son intention: le consentement de l’utilisateur est ici considéré comme implicite. Dans un ou plusieurs modes de réalisation, la détection et/ou l’identification de l’opération à exécuter peut être effectuée par un assistant virtuel à base d’apprentissage automatique («Machine Learning», ML) avec lequel l’utilisateur interagit. L’assistant virtuel peut être inclus dans ou associé à une application logicielle avec laquelle l’utilisateur interagit également ou être indépendant de cette application logicielle avec laquelle l’utilisateur interagit également. Dans le contexte de ce document, on désignera par «assistant virtuel» tout composant logiciel configuré pour assister un utilisateur lors d’interaction avec une application logicielle ou un système. Un tel assistant virtuel ou assistant numérique peut être un assistant personnel numérique, ou tout composant logiciel (par exemple dans un objet connecté) avec fonctions d’assistance à l’utilisateur et susceptible de proposer des opérations à l’utilisateur. Dans un ou plusieurs modes de réalisation, afin de sécuriser ce mode de déclenchement autonome, un niveau de confiance que l’intention de l’utilisateur est effectivement de déclencher l’opération est calculé afin d’évaluer quantitativement le risque d’erreur quant à l’intention de l’utilisateur. Ce niveau de confiance est également un niveau de risque que l’intention de l’utilisateur n’est pas de déclencher l’opération. Le risque évalué ici concerne aussi bien l’identification de l’opération souhaitée par l’utilisateur que le fait qu’il y ait consentement. Ce risque est un risque de nature technique lié aux limitations techniques de la solution logicielle (notamment l’assistant virtuel) à base d’IA et d’apprentissage automatique quant à l’identification de l’opération à déclencher et au consentement. Il est entendu que d’autres types de risques, par exemple de nature juridique, peuvent découler de ce déclenchement autonome d’une opération, mais ces risques ne sont pas évalués par le module d’analyse de risque. Les applications potentielles sont nombreuses. Cette solution peut être utilisée par exemple pour tous les marchés numériques pour l’exécution d’opérations consistant en une transaction d’achat et/ou de paiement: dans ces marchés numériques, la facilité d'utilisation, la rapidité et la sécurité des interactions et des paiements sont essentielles. Cette solution peut être utilisée également dans tous les secteurs où les tâches et les processus nécessitent une automatisation numérique importante, tels que la fabrication de produits manufacturés ou autres produits, ainsi que la logistique. En outre, l'assistant virtuel peut être conçu pour aider les consommateurs dans leur vie quotidienne, par exemple en les aidant à suivre leurs tâches, à faire des achats et à gérer leur emploi du temps à l'aide de quelques interactions naturelles simples. Cette solution est ainsi adaptée à une gamme variée d'applications qui nécessitent des services numériques sans friction, efficaces, voire personnalisés, reposant sur des décisions de déclenchement d’opération(s) prises de manière autonome sur la base des données contextuelles d’interaction et sans consentement explicite de l’utilisateur. Dans un ou plusieurs modes de réalisation, le système permet de prendre compte pour la décision de déclenchement autonome des données contextuelles variées relatives au contexte d’interaction. Par exemple, les données contextuelles peuvent inclure la conversation (notamment texte, image(s) ou audio de la conversation) avec l’assistant virtuel et/ou des informations relatives à une interaction effectuée avec l’assistant virtuel et/ou l’application logicielle. Par exemple, les données contextuelles peuvent inclure le profil utilisateur (préférences, nom, lieu de résidence, etc) et/ou des informations relatives aux usages de l’utilisateur (habitudes, historique d’opérations réalisées pour l’utilisateur, etc). Le profil utilisateur peut être le profil enregistré auprès d’un prestataire avec lequel l’utilisateur interagit au moyen de l’application logicielle. Par exemple, les données contextuelles peuvent inclure des données sur l’environnement (par exemple géolocalisation, pays, température, météo, etc) de l'utilisateur lors de l’interaction. Par exemple, les données contextuelles peuvent inclure des informations sur le contexte général lors de l’interaction telles que: date, heure, jour de la semaine, mois, saison, etc. Ainsi le système permet un déclenchement transparent de l’exécution de l’opération avec prise en compte des besoins et des habitudes de l'utilisateur, une hyper automatisation et une interaction avec une interface utilisateur naturelle et intuitive via l’assistant virtuel. Le système fournit aux utilisateurs finaux un système d'interaction offrant une expérience fluide grâce à une exécution transparente d’opérations. Le système permet de réduire les frictions liées à des opérations, telles que les paiements, nécessitant souvent une succession de saisies de données. Dans le cas particulier d’un paiement, le système peut évaluer le contexte d’interaction pour déterminer la légitimité du déclenchement d’un paiement et éviter la nécessité d'un consentement explicite de l'utilisateur lorsque le niveau de risque d’erreur est suffisamment faible (par exemple, sous un seuil donné). Dans un ou plusieurs modes de réalisation, l’évaluation du risque associé à la décision de déclenchement autonome est effectuée par un module d’analyse de risque à base d’apprentissage automatique («Machine Learning», ML) configuré pour effectuer une analyse du contexte d’interaction afin de quantifier le risque lié au déclenchement autonome de l’opération à exécuter et de calculer un niveau de risque. Sur la base du niveau de risque, il est possible de déterminer s’il est possible de passer outre le consentement explicite de l'utilisateur ou, à défaut, en cas de refus de l’exécution de l’opération lorsque le risque est au-delà d’un seuil, d’utiliser une méthode traditionnelle pour obtenir un consentement explicite et/ou requérir une authentification (ou réauthentification) de l’utilisateur avant d’autoriser l’exécution de l’opération. Cette solution permet de simplifier et fluidifier l’expérience utilisateur puisque l’utilisateur n’a pas besoin d’effectuer d’action d’authentification lorsque l’assistant procède de manière autonome à un paiement sauf, lorsque le risque est évalué comme étant trop élevé et aboutit à un refus d’exécution de l’opération, auquel cas une authentification forte et/ou une validation explicite de l’utilisateur pourra (pourront) être requise(s). Par authentification forte, on entend une authentification basée sur la vérification d’au moins deux facteurs d’authentification de types différents. Il existe trois types de facteurs d’authentification : - facteurs biométriques (basé sur des données biométriques); - facteurs de connaissance (basé sur des informations secrètes connues seulement de l’utilisateur); - facteurs de possession (basé sur l’usage d’un dispositif matériel propre à utilisateur). Dans un ou plusieurs modes de réalisation, l’application logicielle et/ou l’assistant virtuel est paramétrable de sorte que l’utilisateur peut conférer des droits à l’application logicielle et/ou l’assistant virtuel pour le déclenchement autonome d’opérations au nom de l’utilisateur et configurer ces droits. Par exemple, l’utilisateur peut ou non autoriser cet assistant virtuel autonome à prendre des décisions de déclenchement autonome et configurer des paramètres de l’assistant virtuel autonome en fonction de ses exigences et/ou ses préférences relatives au déclenchement autonome d’opérations. Ces paramètres incluent par exemple: un ou des prestataires autorisés (ou respectivement interdits), la nature des produits ou services pouvant faire l’objet d’un déclenchement autonome, un nombre maximal de transactions autorisées par période de temps, un montant maximal à payer si les opérations sont payantes, etc. La FIG. 1 représente schématiquement un système 100 de déclenchement d’opération selon exemple de réalisation. Le système inclut une application logicielle 110 associée à ou incluant un assistant virtuel 120. L’application logicielle 110 (et/ou l’assistant virtuel 120) est en communication opérationnelle avec un système informatique 130 d’un prestataire proposant, par exemple via un catalogue, des opérations relatives à un ou des produits et/ou à un ou des services. L’application logicielle 110 (ou plus spécifiquement l’assistant virtuel 120) est configurée pour détecter, sur la base de données contextuelles à une interaction d’un utilisateur avec l’application logicielle, une intention implicite de l’utilisateur de déclencher une opération relative à un produit ou un service. L’application logicielle 110 (ou plus spécifiquement l’assistant virtuel 120) est configuré pour, sur la base de la détection, décider et requérir au nom de l’utilisateur le déclenchement de l’opération détectée sans requérir préalablement de consentement explicite de l’utilisateur. La requête de déclenchement peut être envoyée au système informatique 130 du prestataire, Une entité de vérification 150 est configurée pour recevoir, du système informatique 130 du prestataire (ou directement de l’assistant virtuel 120) une demande de validation d’une décision de déclenchement autonome d’une opération et déterminer si l’opération est autorisée ou refusée. Dans les cas d’exemple où l'assistant virtuel est un service du prestataire ou dans le cas l'entité de vérification fournit aussi l’assistant virtuel, la demande de validation peut être reçue directement de l’assistant virtuel 120, sans passer par le système informatique 130 du prestataire. L’entité de vérification 150 est configurée pour transmettre une requête d’analyse de risque à un module 160 d’analyse de risque d’erreur à base d’apprentissage automatique. La requête d’analyse de risque peut inclure les données contextuelles collectées par l’assistant virtuel et des informations sur l’opération détectée. Le système informatique 180 est configuré pour exécuter une ou plusieurs opérations. Le système informatique 180 peut faire partie du système informatique 130 du prestataire ou être lié au système informatique 130 ou encore être un système informatique d’un tiers intervenant dans l’exécution de l’opération à exécuter. Dans le cas où l’opération à exécuter est une transaction de paiement, le système informatique 180 peut inclure une passerelle de paiement configuré pour prendre une décision et traiter une transaction de paiement. Lorsque l’entité de vérification 150 détermine, sur la base du niveau de risque, qu’une opération est autorisée, l’entité de vérification 150 transmet au système informatique 180 une notification afin que le système informatique 180 exécute l’opération autorisée. Afin de rendre plus concret le fonctionnement du système et d’illustrer ses possibilités, des modes de réalisation vont être décrits en détails au regard des figures 3 à 5 dans le cas d’exemple où l’opération est une transaction de paiement: de telles transactions nécessitent en effet un haut degré de sécurisation. Ces modes de réalisation des figures 3 à 5 se généralisent à toute autre opération. La FIG. 2 représente schématiquement un système 200 de déclenchement d’opération permettant d’effectuer des transactions de paiement selon exemple de réalisation. Le système 200 permet à une application logicielle 210 avec une interface utilisateur intelligente (par exemple, un assistant virtuel) à base d’Intelligence Artificielle (IA) de mener des actions conduisant à la fin à déclencher une transaction de paiement au nom de l’utilisateur. Ce paiement n'a pas besoin du consentement explicite de l'utilisateur pour être traité. Le déclenchement de la transaction de paiement peut être décidé et requis de manière autonome suite à la détection, sur la base de données contextuelles relatives à une interaction de l’utilisateur avec l’application logicielle 210 (ou plus particulièrement avec l’assistant virtuel), d’une intention implicite de l’utilisateur de déclencher une opération relative à un produit ou un service. L’interface utilisateur intelligente comprend des interfaces d'interaction par le biais d'un système d'entrée de données pour la saisie d'informations et un système de sortie pour l'extraction d'informations relatives aux transactions à déclencher. Le système de sortie peut comprendre un module chargé de stocker et d'extraire les données contextuelles relatives aux interactions avec l'utilisateur. L’interface utilisateur intelligente et/ou le système informatique 220 du prestataire peut comprendre un module de mise en forme des données contextuelles qui recueille, analyse, voire filtre, les données pertinentes de l'utilisateur, y compris ses habitudes, ses informations personnelles et ses demandes, afin de formuler une ou des recommandations de produits(s) et/ou service(s) personnalisé(es) pour l’utilisateur en vue de l’identification d’une opération à déclencher (ici transaction de paiement pour une commande). Le système informatique 220 du prestataire peut recevoir, en provenance de l’application logicielle 210 les données contextuelles et les enrichir avec des données additionnelles telles que les habitudes de l’utilisateur, préférences de l’utilisateur, services et/ou produits au catalogue du prestataire. Le système informatique 220 du prestataire peut enrichir données contextuelles avec des informations sur la ou les recommandations réalisées. Une entité de vérification de paiement 250 s’appuie sur ou comprend un module d'analyse de risque pour déterminer un niveau de risque (et donc un niveau de confiance) relatif à la décision de déclanchement autonome de l’exécution de la transaction de paiement. Le module d'analyse de risque s'appuie sur des données contextuelles caractérisant le contexte d’interaction entre l’utilisateur et l'interface utilisateur intelligente, optionnellement enrichies par le système informatique 220 du prestataire pour générer un niveau de risque servant à prendre une décision concernant la validation ou le refus de la transaction. Par exemple, si le niveau de risque généré par le module d'analyse de risque est faible (inférieur à un seuil S1 non nul), alors la transaction est autorisée (i.e. validée). Si le v est élevé (supérieur à un seuil S2 non nul), alors la transaction est refusée. Si le niveau de risque est entre les seuils S1 et S2, alors un doute existe et la transaction peut être refusée ou un processus avec consentement «manuel», (c’est-à-dire non automatique et explicite de la part de l'utilisateur final) peut être initié pour recueillir le consentement de l’utilisateur. Le module d'analyse de risque ajoute de la valeur aux systèmes classiques de gestion des transactions de paiement. Ce module d'analyse de risque traite les données contextuelles recueillies par l'interface utilisateur intelligente et/ou par le système informatique 220 pour estimer, avec l'aide de l'IA, les risques liés aux décisions autonomes prises par l'interface utilisateur intelligente. Une vérification classique de la transaction peut être effectuée sur la base d’informations transactionnelles telles que le montant de la transaction, le nom du client, le code de catégorie du commerçant, le bénéficiaire, le moyen de paiement, etc. Une vérification supplémentaire est ici effectuée sur la base des données contextuelles, contenant le cas échéant les habitudes du client à l'égard du commerçant, l'historique des achats, les journaux/transcriptions des échanges entre l'assistant autonome et le client, entre autres. Sur la base de ces données contextuelles, un niveau de risque est calculé et une décision est prise sur la base du niveau de risque (et éventuellement sur la base d'au moins un seuil appliqué à ce niveau de risque) afin de valider (approuver) ou de rejeter (refuser) la transaction. Le seuil peut évoluer dynamiquement grâce à un mécanisme de retour d'information visant à réduire les contestations liées à la prise de décision autonome. Dans un ou plusieurs modes de réalisation particuliers, lorsque l'interface utilisateur intelligente détecte une intention d’achat, la transaction d’achat et le paiement associé n'est pas immédiatement déclenchée. Au lieu de cela, l'interface utilisateur intelligente peut attendre pendant une durée définie avant d'être exécuté, afin de donner à l'utilisateur la possibilité de modifier sa demande ou même de changer d'avis et d'annuler explicitement le paiement/la demande. Une fois ce délai écoulé, l'utilisateur ne peut plus modifier sa demande ou annuler le paiement, et seul le niveau de risque généré par le module d’analyse détermine s'il faut accepter, rejeter la transaction de paiement ou demander le consentement explicite de l'utilisateur. Le système répond à des problèmes techniques tels que la fourniture d'une expérience de paiement sécurisée, l'interprétation des données contextuelles de l'utilisateur pour comprendre ses besoins, et la déduction du consentement implicite de l'utilisateur pour les décisions de paiement. Le système offre un service numérique sans friction, efficace et personnalisé reposant sur des décisions prises de manière autonome. Le système interprète les données contextuelles relatives au contexte d’interaction via l'interface utilisateur intelligente pour comprendre les besoins de l'utilisateur, pour déduire le consentement implicite de l'utilisateur et les utilise pour prendre des décisions de paiement. Le système permet ainsi de traiter les paiements sans le consentement explicite de l'utilisateur. Le module d’analyse de risque peut, dans le cas où l’opération à exécuter est une transaction de paiement associée à un achat, faire la distinction entre le consentement pour les besoins identifiés par l’assistant (par identification de l’objet de l’achat, c’est-à-dire identification d’un produit ou service à acheter) et le consentement pour le paiement, validant les paiements sans le consentement direct de l'utilisateur. Par exemple, lors d'une conversation avec l’assistant virtuel il peut y avoir des informations relatives au choix que l’utilisateur veut faire sur les produits / services mais aussi sur notre volonté à aller au bout de la procédure d'achat / paiement. Lors de l’analyse du contexte, le module d’analyse de risque peut déterminer que la proposition d’achat générée par l’assistant ne semble pas répondre au besoin de l’utilisateur. Si la proposition d’achat ne répond pas au besoin, alors le paiement ne doit pas être effectué, et donc le risque est fort. De plus, dans le cas où la proposition d’achat par l’assistant correspond au besoin de l’utilisateur, le module d’analyse de risque évalue également l’interaction qui a donné lieu à cette proposition. S’il ne ressort pas du contexte une volonté, a minima implicite, de la part de l’utilisateur de procéder à l’achat proposé, et donc au paiement associé, alors le risque associé est également considéré comme élevé. Dans le cas où le module d’analyse de risque détecte une volonté de l’utilisateur de payer pour le produit ou service issu de l’interaction qu’il a eu avec l’assistant, alors le risque associé est considéré comme faible. Dans un cas où l’utilisateur valide explicitement le paiement vis-à-vis de l’assistant, le risque est considéré comme faible indépendamment de la pertinence de la proposition d’achat issue de l’assistant concernant le besoin initial. Par exemple dans le cas d’un restaurant, l’utilisateur commande un plat, le serveur prend la commande, puis revient voir l’utilisateur juste après pour signaler que le plat choisi n'est plus disponible et propose à l’utilisateur autre chose. L’utilisateur peut valider tout de même la commande, même si elle ne correspond pas exactement à son choix initial. En outre, le système récupère les données contextuelles relatives aux paiements, qu'elles soient basées sur l'IA ou non, afin de sélectionner un module d'analyse de risque adapté pour traiter ces données contextuelles. Enfin, le système peut fournir des justifications et/ou informations explicatives pour les opérations déclenchées de manière autonome et offre un service de paiement numérique hautement personnalisé et efficace. Le paiement autonome initié par l'IA est un système alimenté par l'IA qui interagit de manière transparente avec les utilisateurs, détermine leurs besoins et déclenche des paiements de manière autonome sans que le consentement explicite de l'utilisateur soit nécessaire. La FIG. 3 présente un exemple de scénario avec transaction de paiement qui inclut des étapes de vérification pour évaluer les risques inhérents associés aux paiements déclenchés de manière autonome. Le scénario implique un serveur (ou plus généralement un système informatique) d’un prestataire (ici un marchand vendant des produits et/ou services). Le scénario implique en outre un assistant virtuel autonome: cet assistant virtuel autonome est un assistant virtuel adapté pour prendre des décisions de déclenchement autonome de transactions de paiement. Dans des modes de réalisation, cet assistant virtuel autonome est paramétrable de sorte que l’utilisateur peut déléguer des droits à cet assistant virtuel autonome pour le déclenchement autonome de transactions de paiement et configurer ces droits. Par exemple, l’utilisateur peut ou non autoriser cet assistant virtuel autonome à prendre des décisions de déclenchement autonome de transactions de paiement et configurer des paramètres de l’assistant virtuel autonome en fonction de ses exigences et/ou ses préférences relatives au déclenchement autonome de transactions de paiement. Ces paramètres incluent par exemple: un montant maximum de paiement, un ou des prestataires autorisés (ou respectivement interdits), la nature des produits ou services pouvant faire l’objet d’un déclenchement autonome de transactions de paiement, etc. Dans le scénario d’exemple, l'utilisateur ne communique pas directement avec la plateforme du prestataire. Au lieu de cela, un assistant virtuel autonome sert d’interface entre l’utilisateur et la plateforme du prestataire et agit au nom de l’utilisateur. Dans la première étape (301), l'assistant virtuel autonome détecte, sur la base de données contextuelles à une interaction d’un utilisateur via une interface utilisateur intelligence, une intention implicite de l’utilisateur de déclencher une commande relative à un produit ou un service. Sur la base de cette détection, l'assistant virtuel autonome décide de déclencher de manière autonome, sur la base de données contextuelles, la commande et le paiement associé auprès du prestataire (ici un marchand) via un serveur associé (ou plus généralement un système informatique du prestataire) et un message incluant les informations sur la commande est envoyé vers le système informatique du prestataire. Au cours de l'étape (302), les données nécessaires au traitement de la transaction de paiement relative à la commande sont collectées. Outre les informations transactionnelles (montant, bénéficiaire, client, moyen de paiement, etc) usuellement utilisées pour passer une commande et effectuer un paiement, les données contextuelles servant à l’analyse de risque sont jointes ou incluses dans les données collectées pour le traitement de la transaction de paiement. Les données contextuelles peuvent être enrichies par rapport à celles collectées par l’assistant virtuel et qui sont relatives à l’interaction et au contenu des échanges avec l’assistant virtuel. Les données contextuelles peuvent comprendre par exemple un ou plusieurs éléments parmi: des informations sur un profil utilisateur, des informations sur les préférences de l’utilisateur, des informations sur les usages de l’utilisateur à l'égard du prestataire, un historique des achats précédents, des informations sur une recommandation d’un produit ou service, etc. En outre, une étiquette est jointe ou incluse dans les données collectées pour le traitement de la transaction de paiement: cette étiquette sert à indiquer la nature autonome (alimentée par l'IA) de la décision de déclenchement de la transaction de paiement à effectuer. Cette indication sur le mode de déclenchement du paiement peut être fournie dans un message selon la norme ISO 20022 qui définit un format standard flexible pour l’échange de messages relatifs à des transactions financières. Au cours de l'étape (303), une demande de validation est adressée depuis le système informatique du prestataire à une entité de vérification pour que l’entité de vérification traite la transaction de paiement afin de déterminer s'il convient ou non d’autoriser la transaction de paiement. L’entité de vérification est par exemple une entité d’un fournisseur de moyen de paiement ou d’un prestataire de paiement. Ce fournisseur ou prestataire peut être un prestataire mettant en œuvre une application «Wallet» ou application porte-monnaie. L'entité de vérification peut aussi être une entité opérée par le marchand. La demande de validation inclut les informations transactionnelles usuellement utilisées pour réaliser un paiement relatif à une commande et en outre les données contextuelles (éventuellement enrichies) et l'étiquette indiquant le caractère autonome de la décision de déclenchement de la transaction. Au cours de l'étape (304), une requête d’analyse de risque est transmise à un module d'analyse de risque sur la base de la demande de validation. La requête d’analyse de risque peut comprendre les mêmes informations que la demande de validation: les informations transactionnelles usuellement utilisées pour passer réaliser un paiement relatif à une commande et en outre les données contextuelles (éventuellement enrichies) et l'étiquette. Au cours de l'étape (305), le module d'analyse de risque peut demander à une API (application programme interface) de formater les données contextuelles relatives au client et à la transaction. Les données contextuelles peuvent être contenues dans la requête d’analyse de risque ou être obtenues auprès du système informatique du prestataire. Les données contextuelles sont formattées, de préférence cryptées puis envoyées lors de l'étape (307) au module d’analyse de risque pour évaluation du risque lié à la transaction de paiement. Les résultats de cette analyse sont ensuite transmis à l’entité de vérification au cours de l'étape (308), en réponse à la requête d’analyse de risque. Les résultats de cette analyse comprennent un niveau de risque. Les résultats de cette analyse peuvent comprendre des informations complémentaires à ce niveau de risque, par exemples des informations explicatives sur le niveau de risque obtenu. Ces informations explicatives servant de justifications peuvent être sous forme de texte et indiquer sur quelles données contextuelles repose le niveau de risque. Ces informations explicatives peuvent être utilisées pour qu'un être humain (côté prestataire ou utilisateur) puisse comprendre le niveau de risque obtenu. Après réception des résultats de l’analyse, l’entité de vérification détermine si la transaction est autorisée ou non. Si, sur la base des résultats de l’analyse, la transaction de paiement est autorisée, l’entité de vérification envoie lors de l’étape 309 les résultats de l'analyse de la transaction au système informatique du prestataire. Le système informatique du prestataire transmet ensuite la notification de paiement (incluant un jeton de paiement) à la passerelle de paiement (étape 310) afin de déclencher le paiement. Les données encryptées dans le jeton numérique incluent les informations transactionnelles associées au paiement (identification du bénéficiaire, du débiteur, montant de la transaction, etc). Les données encryptées dans le jeton numérique peuvent inclure le niveau de risque. Les données encryptées sont transmises par exemple sous forme de jeton de paiement ou sous tout autre forme numérique garantissant leur authenticité et provenance de sorte que le résultat de l'analyse de risque ne puisse être falsifié. La passerelle de paiement détermine sur la base des données cryptées reçues si la transaction est approuvée ou non. Des vérifications sur le paiement peuvent être effectuées par la passerelle de paiement préalablement à l’exécution de la transaction de paiement. La vérification effectuée par la passerelle de paiement inclut par exemple les vérifications usuelles relatives à la détection de fraude, à la validité des moyens de paiement, etc. Si la transaction est approuvée par la passerelle de paiement, la transaction de paiement est exécutée et les informations sur la transaction réalisée sont envoyées à la banque du prestataire à l'étape (311). Une confirmation de la commande et du paiement est également fournie au système informatique du prestataire (étape 312). Si, sur la base des résultats de l’analyse reçus à l’étape 308, la transaction de paiement est considérée par l’entité de vérification comme valide mais trop risquée (i.e. le niveau de risque est supérieur à un seuil S1 non nul): deux options sont possibles. Dans une première option, la transaction est refusée, ce qui met fin au processus: cette première option peut être choisie par exemple quand le niveau de risque est au-delà d’un seuil S2 non nul, avec S2 > S1. Dans une deuxième option, une étape de validation explicite (315) avec authentification forte éventuelle de l’utilisateur peut être réalisée avant d’exécuter la transaction: cette deuxième option peut être choisie par exemple quand le niveau de risque est en dessous du seuil haut S2, mais néanmoins au-dessus du seuil bas S1. La FIG. 4 est un schéma illustrant un système et procédé de déclenchement d’opération selon un exemple de réalisation. La FIG. 4 correspond au même scénario que la FIG. 3 et fournit des détails de réalisation supplémentaires par rapport à la FIG. 3 . Les aspects et caractéristiques décrits par rapport à la FIG. 3 sont applicables et combinables avec ceux décrits par rapport à la FIG. 4 . Lors de l’étape 401, l’utilisateur délègue des droits à un assistant virtuel autonome pour la prise de décision de déclenchement autonome de transaction de paiement au nom de l’utilisateur. Lors de l’étape 402, l'assistant virtuel autonome détecte, sur la base de données contextuelles à une interaction d’un utilisateur avec une application logicielle, une intention implicite de l’utilisateur de déclencher une commande relative à un produit ou un service. Sur la base de cette détection, l’assistant virtuel autonome prend une décision de déclenchement autonome de transaction de paiement au nom de l’utilisateur et envoi au nom de l’utilisateur une demande de déclenchement de la transaction au système informatique du prestataire. Par décision autonome ou déclenchement autonome, on entend ici que le consentement explicite de l’utilisateur n’est pas sollicité pour ce déclenchement et cette décision. Lors de l’étape 403, le système informatique du prestataire demande à l’entité de vérification de valider la transaction de paiement et lui fournit les informations transactionnelles sur la transaction de paiement relative à la commande. Outre les informations transactionnelles usuellement utilisées pour passer une commande et effectuer un paiement, les données contextuelles servant à l’analyse de risque sont transmises. Lors de l’étape 404, le système informatique du prestataire peut demander à l’entité de vérification si cette entité de vérification a la capacité de traiter une transaction de paiement avec déclenchement autonome et la capacité à obtenir et/ou traiter des données contextuelles associées à une telle transaction. Lors de l’étape 405, suite à l’étape 404, selon un premier mode de réalisation, l’entité de vérification peut répondre qu’elle n’a pas la capacité de traiter une transaction de paiement avec déclenchement autonome ou qu’elle n’a pas la capacité à obtenir et/ou traiter des données contextuelles associées à une telle transaction. Lors de l’étape 406, suite à l’étape 405 selon le premier mode de réalisation, le système informatique du prestataire répond à la demande de déclenchement autonome de transaction de paiement de l’étape 402 en indiquant à l’assistant virtuel que le traitement de la transaction n’est pas possible. Lors de l’étape 407, suite à l’étape 406 selon le premier mode de réalisation, l’assistant virtuel peut décider de solliciter une validation de l’utilisateur pour la transaction de paiement. Cette validation peut comporter une authentification (de préférence une authentification forte) de l’utilisateur, par la saisie de données d’authentification afin vérifier l’identité de l’utilisateur procédant à la validation. Lors de l’étape 410, suite à l’étape 404, selon un deuxième mode de réalisation, l’entité de vérification peut répondre qu’elle a la capacité de traiter une transaction de paiement avec déclenchement autonome et qu’elle n’a pas la capacité à obtenir et/ou traiter des données contextuelles associées à une telle transaction. Lors de l’étape 411, suite à la réception de la réponse à l’étape 410, le système informatique du prestataire peut demander à l’assistant virtuel de lui transmettre les données contextuelles sur la base desquelles est fondée la décision de déclenchement autonome de la transaction. Lors de l’étape 412, en réponse à l’étape 411, l’assistant virtuel transmet au système informatique du prestataire les données contextuelles sur la base desquelles est fondée la décision de déclenchement autonome de la transaction. Lors de l’étape 413, suite à l’étape 412, le système informatique du prestataire envoie une demande de validation de transaction en transmettant à l’entité de vérification les données contextuelles sur la base desquelles est fondée la décision de déclenchement autonome de la transaction ainsi que les informations relatives au paiement à effectuer. Lors de l’étape 420, une procédure de détection de fraude peut être réalisée par l’entité de vérification. Une telle procédure de détection de fraude peut se dérouler selon toute manière connue et ne sera pas décrite en détail, n’étant pas l’objet de la présente description. L’étape 420 peut être exécutée avant, après ou en parallèle avec l’étape 430. Lors de l’étape 430, une analyse de risque est effectuée sur requête de l’entité de vérification, sur la base des données contextuelles sur la base desquelles est fondée la décision de déclenchement autonome de la transaction. Cette analyse de risque peut être effectuée par un module d’analyse de risque selon tout mode de réalisation décrit dans ce document. En résultat de l’analyse, un niveau de risque (i.e. un niveau de confiance) est obtenu. L’entité de vérification prend une décision de valider ou non la transaction de paiement sur la base du risque obtenu. Selon le niveau de risque obtenu, l’une des étapes 440, 450, 460 est exécutée après l’étape 430. Si le niveau de risque est faible (inférieur à un seuil S1 non nul), alors l’étape 440 est exécutée. Si le niveau de risque est élevé (supérieur à un seuil S2 non nul), alors l’étape 450 est exécutée. Si le niveau de risque est entre S1 et S2, alors l’étape 460 est exécutée. Lors de l’étape 440, l’entité de vérification répond au système informatique du prestataire en envoyant une notification indiquant sa décision de valider la transaction de paiement. Cette notification peut comprendre le niveau de risque et/ou une information relative au niveau de risque. L’exécution de la transaction peut être déclenchée par le système informatique du prestataire. Lors de l’étape 441, suite à l’étape 440, le système informatique du prestataire répond à l’assistant virtuel autonome en indiquant que la transaction de paiement est exécutée. Lors de l’étape 442, suite à l’étape 441, l’assistant virtuel autonome informe l’utilisateur de la commande et de l’exécution de la transaction de paiement. Lors de l’étape 450, l’entité de vérification répond au système informatique du prestataire en envoyant une notification indiquant sa décision quant au doute sur la validité de la transaction de paiement. Cette notification peut comprendre le niveau de risque ou une information explicative relative au niveau de risque. Lors de l’étape 451, suite à l’étape 450, le système informatique du prestataire répond à l’assistant virtuel autonome en sollicitant un consentement explicite de l’utilisateur. Lors de l’étape 452, suite à l’étape 451, l’assistant virtuel autonome sollicite un consentement explicite de l’utilisateur. Selon que l’utilisateur consent ou non, un processus «classique» de déclenchement de l’exécution de la transaction peut être déclenchée ou non. Lors de l’étape 460, l’entité de vérification répond au système informatique du prestataire en envoyant une notification indiquant sa décision de refus de l’exécution de la transaction de paiement. Cette notification peut comprend le niveau de risque ou une information relative au niveau de risque. Lors de l’étape 461, suite à l’étape 460, le système informatique du prestataire répond à l’assistant virtuel autonome en indiquant que la transaction de paiement est refusée. Le processus peut s’arrêter là. Alternativement, l’assistant virtuel autonome peu solliciter un consentement explicite de l’utilisateur. Selon que l’utilisateur consent ou non, un processus «classique» de déclenchement de l’exécution de la transaction peut être déclenchée ou non. La FIG. 5 est un schéma illustrant un système et procédé de déclenchement d’opération selon un exemple de réalisation. Les aspects et caractéristiques décrits par rapport à la FIG. 3 et à la FIG. 4 sont applicables et combinables avec ceux décrits par rapport à la FIG. 5 . La FIG. 5 correspond à un scénario d’exemple dans le cas d’une transaction de paiement pour un achat de produit et/ou de service(s). Lors de l’étape 511, l’utilisateur délègue des droits à un assistant virtuel autonome pour la prise de décision de déclenchement autonome de transaction de paiement au nom de l’utilisateur. Lors de l’étape 512, l'assistant virtuel autonome détecte, sur la base de données contextuelles à une interaction d’un utilisateur avec une application logicielle, une intention implicite de l’utilisateur de déclencher une commande relative à un produit ou un service. Lors de l’étape 513, l’assistant virtuel autonome prend une décision de déclenchement autonome de transaction de paiement au nom de l’utilisateur et envoi au nom de l’utilisateur une demande de déclenchement de la transaction au système informatique du prestataire. Par décision autonome ou déclenchement autonome, on entend que le consentement explicite de l’utilisateur n’est pas requis pour ce déclenchement ou cette décision. Lors de l’étape 514, l’assistant virtuel autonome transmet au système informatique du prestataire les données contextuelles sur lesquelles est fondée la décision de déclenchement autonome. En alternative, la transmission des données contextuelles se fait dans l’étape 512 et l’étape 513 n’est pas exécutée. Lors de l’étape 515, le système informatique du prestataire demande à l’entité de vérification de valider la transaction de paiement et lui fournit les informations transactionnelles de la transaction de paiement relative à la commande. Outre les informations transactionnelles usuelles relatives au paiement à effectuer (montant, bénéficiaire, débiteur, moyen de paiement, etc), le système informatique du prestataire envoie les données contextuelles sur la base desquelles est fondée la décision de déclenchement autonome de la transaction. Lors de l’étape 525, une analyse de risque est effectuée sur requête de l’entité de vérification, sur la base des données contextuelles sur la base desquelles est fondée la décision de déclenchement autonome de la transaction. Cette analyse de risque peut être effectuée par un module d’analyse de risque selon tout mode de réalisation décrit dans ce document. En résultat de l’analyse, un niveau de risque est obtenu. Lors de l’étape 526, l’entité de vérification répond au système informatique du prestataire en envoyant le niveau de risque et/ou par exemples des informations explicatives sur le niveau de risque obtenu. Lors de l’étape 530, l’entité de vérification prend une décision d’autoriser (i.e. valider) ou non la transaction de paiement sur la base du risque obtenu. Si la transaction est autorisée (i.e. validée), l’étape 531 est exécutée suite à l’étape 530: la passerelle de paiement reçoit une notification avec les informations transactionnelles relatives à la transaction de paiement à exécuter. La passerelle de paiement peut procéder à d’autres vérifications sur la transaction de paiement à exécuter (par exemple une détection de fraude) avant d’exécuter la transaction de paiement. A défaut l’étape 535 est exécutée suite à l’étape 530, la transaction est refusée et le processus prend fin. Alternativement ou en combinaison, l’entité de vérification (ou le système informatique du prestataire) sollicite un consentement explicite de l’utilisateur via l’assistant virtuel. Selon que l’utilisateur consent ou non, un processus «classique» de déclenchement de l’exécution de la transaction peut être déclenchée ou non. La FIG. 6 est un organigramme d’un procédé de déclenchement d’opération selon un exemple de réalisation. A l’étape 610, une détection d’une intention implicite de l’utilisateur de déclencher une opération relative à un produit ou un service est effectuée. Cette détection est effectuée sur la base de données contextuelles à une interaction d’un utilisateur avec une application logicielle. A l’étape 620, sur la base de la détection, une décision de déclenchement autonome de l’opération au nom de l’utilisateur est prise sans requérir préalablement de consentement explicite de l’utilisateur. A l’étape 630, une requête d’analyse de risque est transmise à un module d’analyse de risque à base d’apprentissage automatique. La requête d’analyse de risque inclut les données contextuelles sur lesquelles est basée la décision de déclenchement autonome et des informations sur l’opération détectée. A l’étape 640, un indicateur représentatif d’un niveau de risque que l’intention de l’utilisateur n’est pas de déclencher l’opération détectée est reçu en réponse, en provenance du module d’analyse de risque. Le niveau de risque est aussi un niveau de confiance que l’intention de l’utilisateur est effectivement de déclencher l’opération détectée. A l’étape 650, une décision est prise pour déterminer, sur la base au moins de l’indicateur, si l’opération est autorisée ou non. Chacune des étapes 610, 620 peut être réalisée par l’application logicielle et/ou un assistant virtuel autonome et selon l’un quelconque des modes de réalisations décrit dans ce document. Chacune des étapes 630, 640, 650 peut être réalisée par une entité de vérification et selon l’un quelconque des modes de réalisations décrit dans ce document. La FIG. 7 est un organigramme d’un procédé d’analyse de risque selon un exemple de réalisation. Les étapes de ce procédé peuvent être mises en œuvre par un module d’analyse de risque à base d’apprentissage automatique et selon l’un quelconque des modes de réalisation décrit dans ce document. A l’étape 710, des données contextuelles à une interaction d’un utilisateur avec une application logicielle et des informations sur une opération relative à un produit ou un service destinée à être exécutée sont reçues en provenance d’une entité de vérification, l’opération ayant été identifiée sur la base des données contextuelles. A l’étape 720, un indicateur est généré: cet indicateur est représentatif d’un niveau de risque que l’intention de l’utilisateur ne soit pas de déclencher l’opération identifiée. Le niveau de risque est aussi un niveau de confiance que l’intention de l’utilisateur est effectivement de déclencher l’opération identifiée. L’opération est une opération faisant l’objet d’une décision de déclenchement autonome fondée sur les données contextuelles. A l’étape 730, l’indicateur est transmis à l’entité de vérification. L’entité de vérification est configurée pour prendre une décision de valider ou non l’exécution de l’opération sur la base du niveau de risque obtenu. Le module d’analyse de risque peut être mis en œuvre au moyen de grands modèles de langage (Large Language Models, LLM) et de l'ingénierie d'invite («Prompt Engineering»). Le processus d’analyse est par exemple basé sur un LLM automatique capable de décomposer un dialogue entre l’utilisateur et un assistant virtuel en plusieurs étapes successives afin d'extraire des méta-informations telles que des pensées, des réflexions, des idées et des points saillants, ce qui lui permet de comprendre l’intention implicite du client de déclencher une transaction de paiement. En outre, des invites («prompts») dédiées permettent au LLM de se concentrer sur les différents objectifs intermédiaires de chaque itération. Les "prompts" utilisés dans le cadre de l’analyse de risque propre à l'exemple d'une conversation textuelle permettent au modèle d'être conditionné pour se concentrer sur une tache particulière selon ce qui est illustré par exemple par le mode de réalisation de la FIG. 9 . Ce conditionnement influence le résultat retourné par le modèle LLM, ainsi que l'approche utilisée pour arriver à ce résultat. Dans l’exemple de la FIG. 9 , on génère des points saillants de la conversation, une réflexion, pour finalement arriver à un niveau de risque et une justification (informations explicatives) de ce niveau de risque. La FIG. 8 est un organigramme d’un procédé d’analyse de risque selon un exemple de réalisation. Cette figure illustre un algorithme générique d’analyse de risque. Cet algorithme est applicable à tous les modes de réalisation décrits dans ce document, notamment par rapport aux figures 1 à 7. Dans l’étape 810, le contexte de l’interaction est récupéré. Le contexte peut inclure différents types de données contextuelles comme décrit dans ce document dans les différents modes de réalisation. Dans l’étape 815, un formatage multimodal du contexte en représentation vectorielle est effectué. Dans l’étape 820, des cycles successifs d’interprétation de la représentation vectorielle du contexte à des fins d’estimation du risque associé à la transaction de paiement sont répétés tant qu’un critère d’arrêt basé sur la convergence de l’interprétation n’est pas vérifié (étape 830). Suite à l’étape 830, quand le critère d’arrêt est vérifié, un niveau de risque est calculé à l’étape 840 sur la base de l’interprétation obtenue. En outre, une transcription de l’interprétation en interaction naturelle est générée à l’étape 845: des informations explicatives sur le niveau de risque sont générées. Ces informations explicatives permettent par exemple de mettre en évidence les données contextuelles ayant pesé le plus dans l’évaluation du risque. De plus, des transformations (méta concepts) du contenu à des fins de réflexions (idées) peuvent être générées. Par exemple, ces informations explicatives peuvent indiquer quelles sont les parties du contenu de la conversation avec l’assistant virtuel qui ont été significatives dans l’interprétation et/ou de générer des nouvelles entrées permettant une explication du contenu. Dans l’étape 850, le niveau de risque est ensuite utilisé pour prendre une décision de valider ou non une opération (notamment transaction de paiement). Par ailleurs, les informations explicatives associées peuvent être utilisées comme justification de la prise de décision à posteriori. La FIG. 9 est un organigramme d’un procédé d’analyse de risque selon un exemple de réalisation. Elle illustre un algorithme d’analyse de risque adapté pour analyser une conversation avec un assistant virtuel en mode texte. Cet algorithme est applicable à tous les modes de réalisation décrits dans ce document, notamment par rapport aux figures 1 à 8. Le niveau de risque est déterminé sur la base de points saillants d’une transcription d’un contenu texte de la conversation avec l’assistant virtuel et de scores évalués pour ces points saillants. Dans l’étape 910, le contexte de l’interaction est récupéré. Le contexte peut inclure différents types de données contextuelles comme décrit dans ce document dans les différents modes de réalisation. Les données contextuelles incluent dans cet exemple un contenu texte de la conversation avec un assistant virtuel. Dans l’étape 915, une transcription du contenu texte de la conversation est générée. Dans l’étape 920, des points saillants de la transcription sont générés, un point saillant correspondant à un contenu texte. Dans l’étape 921, des évaluations (i.e. scores) des points saillants sont générées. Dans l’étape 922, les meilleurs points saillants générés dans l’étape 920 sont retenus sur la base de leurs évaluations respectives effectuées dans l’étape 921. Par exemple, avec les générations, points saillants et scores suivants: Génération GenA: contenu ABC, score 5/10 Génération GenB: contenu DFE, score 7/10 Génération GenC: contenu GHI, score 8/10 on sélectionnera les contenus "DFE" et "GHI" parce que leurs scores sont les plus élevés. Dans l’étape 930, des réflexions sont générées sur la base de la transcription de la conversation et des points saillants ayant les meilleures évaluations. Dans cette étape 930, le modèle est conditionné grâce aux points saillants afin de générer une réflexion, néanmoins la transcription de la conversation est également fournie afin d’affiner la réflexion. Dans l’étape 940, des évaluations des réflexions sont générées. Dans l’étape 950, la meilleure réflexion est sélectionnée. Dans l’étape 960, une évaluation globale est effectuée sur la base de la meilleure réflexion afin de générer un niveau de risque et d’explications liées à ce risque. En outre, l'assistant virtuel lui-même peut s'appuyer sur un LLM qui interagit avec l'utilisateur pour fournir un service, par exemple en accédant aux informations nécessaires par le biais d'une base de données d'informations des catalogues de produits et services des prestataires auquel il est autorisé à accéder via une interface de programmation d'applications (API). Les différents systèmes décrits dans ce document peuvent comprendre différentes fonctions ou avantages consistant à: - Offrir une expérience de paiement sûre, fiable, conviviale et transparente ; - Interpréter les données échangées dans un contexte d’interaction pour comprendre les besoins de l'utilisateur ; - Utiliser les données échangées dans le contexte d’interaction pour prendre des décisions de paiement; - Analyser le contexte d’interaction pour déduire le consentement implicite de l'utilisateur; - Faire la distinction entre le consentement pour les besoins et le consentement pour le paiement; - Valider les paiements sans le consentement explicite de l'utilisateur ; - Récupérer les informations relatives aux paiements (qu'elles soient ou non basées sur l'identification automatique de la transaction) afin de calculer le risque associé à la légitimité du paiement; - Permettre des processus de paiement autonomes conformes aux normes de paiement actuelles. Les systèmes intègrent des modules intelligents permettant un déclenchement autonome de transactions et une analyse du risque transactionnel lié à une transaction déclenchée de manière autonome. Les systèmes sont capables d'évaluer efficacement les risques transactionnels en temps réel et de permettre des transactions fluides et sécurisées sans nécessiter d'interventions manuelles. Ces modules sont capables de gérer la complexité et la nature dynamique des transactions pilotées par l'IA et de donner aux utilisateurs l'assurance que leurs transactions sont sûres et efficaces. Dans la description des différentes phases et procédés, bien que les étapes soient décrites de manière séquentielle, certaines étapes peuvent être omises, combinées, réalisées dans un ordre différent et/ou en parallèle. Une ou plusieurs ou toutes les étapes d’un ou des procédés décrits dans ce document peuvent être mises en œuvre par un logiciel ou programme d'ordinateur et/ou par du hardware, par exemple par circuit, programmable ou non, spécifique ou non. Les fonctions, étapes et procédés décrits dans ce document peuvent être mises en œuvre par logiciel (par exemple, via un logiciel sur un ou plusieurs processeurs, pour exécution sur un ordinateur à usage général ou à usage spécifique) et/ou être mises en œuvre par du hardware (par exemple un ou plusieurs circuits, et/ou tout autre composant matériel). La présente description concerne ainsi un logiciel ou programme d'ordinateur, susceptible d’être exécuté par un dispositif hôte, respectivement un système hôte (tel que système de déclenchement d’opération, système informatique), au moyen d’un ou plusieurs processeurs de données, ce logiciel / programme comportant des instructions pour causer l'exécution par ce dispositif (respectivement système) hôte de tout ou partie des étapes de l’un ou des procédés décrits dans ce document. Ces instructions sont destinées à être stockées dans une mémoire du dispositif (respectivement système) hôte, chargées puis exécutées par un ou plusieurs processeurs de ce dispositif (respectivement système) hôte de sorte à causer l’exécution par ce dispositif (respectivement système) hôte du procédé considéré. Ce logiciel / programme peut être codé au moyen de 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 partiellement compilée, ou dans n’importe quelle autre forme souhaitable. Le dispositif (respectivement système) hôte peut être mis en œuvre par une ou plusieurs machines physiquement distinctes. Le dispositif (respectivement système) hôte peut présenter globalement l’architecture d’un ordinateur, incluant un ou des constituants d’une telle architecture : mémoire(s) de données, processeur(s), bus de communication, interface(s) matérielle(s) pour la connexion de ce dispositif (respectivement système) hôte à un réseau ou un autre équipement, interface(s) utilisateur, etc. Dans un mode de réalisation, tout ou partie des étapes d’un procédé de déclenchement d’opération ou d’un autre procédé décrit dans ce document sont mises en œuvre par un dispositif ou système doté de moyens de mise en œuvre de ces étapes de ce procédé. Ces moyens peuvent comprendre des moyens logiciels (software) (par exemple, des instructions d'un ou plusieurs composants d’un programme) et/ou moyens matériels (hardware) (par exemple, circuit(s), mémoire(s) de données, processeur(s), bus de communication, interface(s) matérielle(s), etc). Ces moyens peuvent comprendre par exemple un ou plusieurs circuits configurés pour exécuter une ou plusieurs ou toutes les étapes d’un des procédés décrits ici. Ces moyens peuvent comprendre par exemple au moins un processeur et au moins une mémoire comprenant des instructions de programme configurées pour, lorsqu’elles sont exécutées par le processeur, causer l’exécution par le dispositif d’une ou plusieurs ou toutes les étapes d’un des procédés décrits ici. Des moyens mettant en œuvre une fonction ou un ensemble de fonctions peuvent correspondre dans ce document à un composant logiciel, à un composant matériel ou bien à une combinaison de composants matériels et/ou logiciels, apte à mettre en œuvre la fonction ou l’ensemble de fonctions, selon ce qui est décrit ci-dessous pour les moyens concernés. La présente description concerne aussi un support d'informations lisible par un processeur de données, et comportant des instructions d'un programme tel que mentionné ci-dessus. Le support d'informations peut être n'importe quel moyen matériel, entité ou dispositif, capable de stocker les instructions d'un programme tel que mentionné ci-dessus. Les supports de stockage de programme utilisables incluent les mémoires ROM ou RAM, les supports de stockage magnétiques tels que des disques magnétiques et des bandes magnétiques, les disques durs ou des supports de stockage de données numériques à lecture optique, ou toute combinaison de ces supports. Dans certains cas, le support de stockage lisible par ordinateur n'est pas transitoire. Dans d’autres cas, le support d'informations peut être un support transitoire (par exemple, une onde porteuse) pour la transmission d’un signal (signal électromagnétique, électrique, radio ou optique) porteur des instructions de programme. Ce signal peut être acheminé via un moyen de transmission approprié, filaire ou non filaire : câble électrique ou optique, liaison radio ou infrarouge, ou par d'autres moyens. Un mode de réalisation concerne également un produit programme d'ordinateur comprenant un support de stockage lisible par ordinateur sur lequel sont stockées des instructions de programme, les instructions de programme étant configurées pour causer la mise en œuvre par le dispositif (respectivement système) hôte (par exemple un ordinateur) de tout ou partie des étapes d’un ou des procédés décrits ici lorsque les instructions de programme sont exécutées par un ou plusieurs processeurs et/ou un ou plusieurs composants matériels programmables du dispositif (respectivement système) hôte. Procédé de déclenchement autonome d’au moins une opération, le procédé comprenant: une détection (610), sur la base de données contextuelles à une interaction d’un utilisateur avec une application logicielle, d’une intention implicite de l’utilisateur de déclencher une opération relative à un produit ou un service; sur la base de la détection, une décision (620) de déclenchement autonome de l’opération au nom de l’utilisateur sans requérir préalablement de consentement explicite de l’utilisateur ; une transmission (630) d’une requête d’analyse de risque à un module d’analyse de risque à base d’apprentissage automatique, la requête d’analyse de risque incluant les données contextuelles et des informations sur l’opération détectée; une réception (640) en provenance du module d’analyse de risque d’un indicateur représentatif d’un niveau de risque que l’intention de l’utilisateur n’est pas de déclencher l’opération détectée; une prise de décision (650) pour déterminer, sur la base au moins de l’indicateur, si l’opération est autorisée ou non. Procédé selon la revendication 1, comprenant: lorsque l’opération est autorisée, un envoi d’une notification à un système informatique pour déclencher l’exécution de l’opération. Procédé selon la revendication 1 ou 2, comprenant: lorsque l’opération n’est pas autorisée, une opération visant à obtenir un consentement explicite de l’utilisateur et/ou à requérir une authentification de l’utilisateur.. Procédé selon la revendication 1, comprenant : lorsque l’indicateur est inférieur à une première valeur de seuil et supérieur à une deuxième valeur de seuil non nulle, un envoi vers l’utilisateur d’une demande de validation explicite du déclenchement de l’opération ; lorsque l’indicateur est supérieur à la première valeur de seuil, un envoi d’une notification de refus de l’opération ; lorsque l’indicateur est inférieur à la deuxième valeur de seuil, un envoi d’une notification à un système informatique pour déclencher l’exécution de l’opération. Procédé selon l’une quelconque des revendications précédentes, comprenant: une obtention d’au moins un paramètre de configuration définissant des droits accordés à l’application logicielle par l’utilisateur pour le déclenchement autonome d’opérations au nom de l’utilisateur ; une configuration de l’application logicielle sur la base du paramètre de configuration. Procédé selon l’une quelconque des revendications précédentes, dans lequel l’application logicielle est ou comprend un assistant virtuel et les données contextuelles comprennent un contenu d’une interaction avec l’assistant virtuel. Procédé selon l’une quelconque des revendications précédentes, dans lequel la requête d’analyse inclut au moins un élément d’information parmi : des informations sur un profil utilisateur, des informations sur les préférences de l’utilisateur, des informations sur les usages de l’utilisateur, des informations sur une recommandation d’un produit ou service, des informations sur un historique d’opérations déclenchées pour l’utilisateur. Procédé selon l’une quelconque des revendications 2 à 7, dans lequel l’opération est une transaction de paiement pour l’achat d’au moins un produit et/ou d’au moins un service, dans lequel la notification est une notification de paiement, le niveau de risque prenant en compte d’une part le fait que l’achat semble répondre au besoin de l’utilisateur et d’autre part que l’intention de l’utilisateur est effectivement de procéder au paiement. Système comprenant des moyens informatiques pour mettre en œuvre un procédé de déclenchement autonome d’au moins une opération, le procédé comprenant : une détection, sur la base de données contextuelles à une interaction d’un utilisateur avec une application logicielle, d’une intention implicite de l’utilisateur de déclencher une opération relative à un produit ou un service; sur la base de la détection, une décision de déclenchement autonome de l’opération au nom de l’utilisateur sans requérir préalablement de consentement explicite de l’utilisateur ; une transmission d’une requête d’analyse de risque à un module d’analyse de risque à base d’apprentissage automatique, la requête d’analyse de risque incluant les données contextuelles et des informations sur l’opération détectée; une réception en provenance du module d’analyse de risque d’un indicateur représentatif d’un niveau de risque que l’intention de l’utilisateur n’est pas de déclencher l’opération détectée; une prise de décision pour déterminer, sur la base au moins de l’indicateur, si l’opération est autorisée ou non. Procédé d’analyse de risque, comprenant : une réception (710), en provenance d’une entité de vérification par un module d’analyse de risque à base d’apprentissage automatique, de données contextuelles à une interaction d’un utilisateur avec une application logicielle et d’informations sur une opération relative à un produit ou un service destinée à être exécutée, l’opération ayant été identifiée sur la base des données contextuelles; une génération (720) par le module d’analyse de risque d’un indicateur représentatif d’un niveau de risque que l’intention de l’utilisateur ne soit pas de déclencher l’opération identifiée ; une transmission (730) de l’indicateur à l’entité de vérification.