FR 3112630 A1 20220121 FR 2007484 A 20200716 Les modes de réalisation de la présente invention fournissent un procédé, un système et un produit de programme informatique pour le gestion d’événement variable dans un environnement à locataires multiples. Dans un mode de réalisation de l’invention, un procédé de gestion d’événement variable dans un environnement à locataires multiples comprend la réception d’un événement placé sur un bus d’événement dans un système de traitement de données événementiels, l’événement correspondant à une multiplicité d’instances différentes d’un gestionnaire d’événement unique, chaque instance ayant été adaptée pour traiter l’événement. Le procédé comprend en outre le décodage de l’événement pour identifier une version d’une application cible pour l’événement et la mise en correspondance de la version de l’application cible avec un point d’arrivée pour un gestionnaire d’événement particulier parmi les différents gestionnaires d’événement. Enfin, le procédé comprend l’acheminement de l’événement vers le point d’arrivée correspondant. Figure pour l’abrégé : Figure 1 SÉLECTION VARIABLE DE DIFFÉRENTES VERSIONS D’UN GESTIONNAIRE D’ÉVÉNEMENT Domaine technique de l’invention La présente invention concerne le domaine de l’informatique à locataires multiples et plus particulièrement la gestion d’événement dans un environnement informatique à locataires multiples. Arrière-plan technique L’informatique traditionnelle comprend l’exécution d’un programme informatique dans la mémoire d’un ordinateur par un processeur de l’ordinateur. En règle générale, un utilisateur unique accède à un programme informatique unique correspondant à tout moment ; cependant, certains programmes informatiques multi-utilisateurs permettent l’accès simultané au programme informatique et aux données produites et accessibles dans celui-ci. Au sein d’une organisation unique, il est logique de prendre en charge un programme informatique multi-utilisateurs. À cet égard, au sein d’une organisation unique, le partage des données est autorisé et, par conséquent, chaque personne accédant au programme informatique multi-utilisateurs peut être autorisée à accéder aux mêmes données. De même, dans la mesure où différents utilisateurs au sein d’une même organisation bénéficient de droits d’accès différents à des données différentes, certaines parties des données peuvent être interdites d’accès à différents utilisateurs. Les ressources informatiques requises pour soutenir l’exécution d’une application unique sont généralement limitées et donc gérables. Même pour une petite organisation, le maintien d‘un placard minimal de ressources informatiques n’est qu’une petite charge. Mais, pour soutenir l’exécution de plusieurs programmes informatiques de manière à accueillir un grand nombre d’utilisateurs simultanés au sein d’une organisation, un grand nombre de ressources informatiques est nécessaire. C‘est pourquoi de nombreuses organisations choisissent d’externaliser l’hébergement des ressources informatiques physiques vers un site distant et géré. De même, dans la mesure où les différents utilisateurs d’une organisation peuvent être géographiquement dispersés, l‘hébergement de plusieurs ressources informatiques dans un lieu centralisé ou même dans plusieurs lieux différents peut être d‘une grande importance. Néanmoins, malgré les gains d’efficacité réalisés en plaçant à distance ses propres programmes informatiques multi-utilisateurs dans une ferme de serveurs hébergés, les services gérés et hébergés peuvent être assez coûteux - notamment en termes de frais de licence de logiciel. Par conséquent, les tendances modernes de l’informatique capitalisent sur la notion d’environnement informatique à locataires multiples. Un environnement informatique à locataires multiples est un environnement informatique hébergé dans lequel une instance unique d’un programme informatique s’exécute dans une infrastructure informatique centralisée tout en restant accessible à de multiples utilisateurs différents dans de multiples organisations. En particulier, par rapport à une architecture multi-instance, dans un environnement à locataires multiples, chaque locataire est un groupe d’utilisateurs partageant un accès commun avec des privilèges spécifiques à une seule instance du programme informatique. Chaque locataire bénéficie alors d‘une part spécifique de l’instance unique du programme informatique, y compris les données correspondantes, la configuration, la gestion des utilisateurs, les fonctionnalités individuelles des locataires et les propriétés non fonctionnelles. La préoccupation fondamentale de l’abonnement à un environnement à locataires multiples hébergé commence et se termine par la sécurité des données. Une organisation souscrivant à une instance d’application dans un environnement à locataires multiples doit être assurée de la sécurité des données organisationnelles contre l’accès par d’autres organisations souscrivant également à la même instance d’application. Par conséquent, l’environnement à locataires multiples typique sépare les données organisationnelles dans différents magasins de base de données distincts, de sorte qu’une organisation n’est pas autorisée à accéder au magasin de base de données d’une autre. De même, les communications de données entre les différents utilisateurs des différentes organisations de l’instance d’application unique restent séparées les unes des autres, chaque organisation ayant son propre ensemble de canaux de communication établis avec l’instance unique de l’application. L’architecture à locataires multiples présente l’avantage particulier que tous les abonnés, également appelés « locataires », ont accès à la version la plus récente d’une application couramment utilisée, puisque la mise à jour de l’application pour un locataire signifie nécessairement la mise à jour de l’application pour tous les locataires. Toutefois, l’inconvénient moins évident, mais tout aussi important, d’un environnement à locataires multiples est que tous les abonnés sont obligés d’utiliser une version identique d’une application puisque tous les abonnés accèdent à la même instance de la même application à tout moment donné. Par conséquent, dans la mesure où l’un des abonnés, par exemple les locataires, cherche à accéder à une version ancienne ou légèrement plus ancienne d’une application, cet abonné est alors contraint d’accéder à une instance complètement différente de l’application en dehors de l’architecture à locataires multiples ou dans une architecture à locataires multiples complètement distincte. Ainsi, de manière inefficace, le gestionnaire d’application doit alors gérer deux déploiements différents de la même application dans un environnement hébergé. Les modes de réalisation de la présente invention comblent les lacunes de l’art antérieur par rapport à la gestion d’événement dans un environnement informatique à locataires multiples et fournissent un procédé, un système et un produit de programme informatique nouveaux et non évidents pour la gestion d’événement variable dans un environnement à locataires multiples. Dans un mode de réalisation de l’invention, un procédé de gestion d’événement variable dans un environnement à locataires multiples comprend la réception d’un événement placé sur un bus d’événement dans un système de traitement de données événementiels, l’événement correspondant à une multiplicité d’instances différentes d’un gestionnaire d’événement unique pour des versions respectivement différentes d’une application cible, chaque instance ayant été adaptée pour traiter l’événement. Le procédé comprend en outre le décodage de l’événement pour identifier une version de l’application cible pour l’événement et la correspondance de la version de l’application cible à un point d’arrivée pour un gestionnaire d’événement particulier parmi les différents gestionnaires d’événement. Enfin, le procédé comprend l’acheminement de l’événement vers le point d’arrivée correspondant. Dans un aspect du mode de réalisation, l’événement est reçu dans le bus d’événement en connexion avec un nom d’événement et, éventuellement, avec la version d’événement, l’application cible et un propriétaire ou un déployeur de l’application cible. Ainsi, la correspondance utilise le nom d’événement, l’application cible et le propriétaire comme clé dans une table d’acheminement stockée dans la mémoire cache du système de traitement de données événementiels pour identifier le point d’arrivée. À cet égard, le point d’arrivée peut comprendre un préfixe d’emplacement ajouté au nom d’événement, de sorte que l’acheminement insère le nom d’événement avec un préfixe sur le bus d’événement. Par exemple, le préfixe d’emplacement peut comprendre une concaténation d’un identificateur de déploiement, d’un identificateur d’archive et d’un identificateur d’application. En option, en cas de perte de données, le procédé peut inclure une reconstruction dynamique de la table d’acheminement. Plus précisément, à la suite d’une perte de données dans le système de traitement de données événementiels, le procédé comprend en outre l’interrogation de chaque instance de l’application cible et, ensuite, la réception, en réponse à l’interrogation de chaque instance correspondante de l’application cible, de l’identificateur de déploiement, de l’identificateur d’archive et de l’identificateur d’application pour chaque propriétaire souscrivant à l’instance correspondante de l’application cible. Pour chaque propriétaire, un enregistrement est créé dans la table d’acheminement qui met en corrélation le propriétaire, l’identificateur d’application et l’événement avec l’identificateur de déploiement, l’identificateur d’archive et l’identificateur d’application. Dans un autre mode de réalisation de l’invention, un système de traitement de données est adapté pour la gestion d’événement variable dans un environnement à locataires multiples. Le système comprend une plate-forme informatique hôte qui comprend un ou plusieurs ordinateurs, chacun avec une mémoire et au moins un processeur. Le système comprend également un module de gestion d’événement variable. Le module comprend des instructions de programme informatique qui, pendant leur exécution dans la plate-forme informatique hôte, sont capables de recevoir un événement placé sur un bus d’événement dans un système de traitement de données événementiels, l’événement correspondant à une multiplicité d’instances différentes d’un gestionnaire d’événement unique, chaque instance ayant été adaptée pour traiter l’événement. Les instructions du programme informatique décodent en outre l‘événement pour identifier une version de l’application cible pour l’événement et faire correspondre l’application cible à un point d’arrivée pour un gestionnaire d’événement particulier parmi les différents gestionnaires d’événement. Enfin, les instructions de programme acheminent l’événement vers le point d’arrivée correspondant. D’autres aspects de l’invention seront exposés en partie dans la description qui suit, et en partie seront évidents d’après la description, ou pourront être appris par la pratique de l’invention. Les aspects de l’invention seront réalisés et atteints au moyen des éléments et combinaisons particulièrement indiqués dans les revendications annexées. Il est entendu que la description générale qui précède et la description détaillée qui suit sont toutes deux exemplaires et explicatives et ne sont pas restrictives de l’invention, telle qu’elle est revendiquée. Brève description des figures Les dessins d’accompagnement, qui sont incorporés dans le présent cahier des charges et en font partie intégrante, illustrent des modes de réalisation de l’invention et, avec la description, servent à expliquer les principes de l’invention. Les modes de réalisation illustrés ici sont actuellement préférés, étant entendu, toutefois, que l’invention ne se limite pas aux arrangements et instruments précis indiqués, dans lesquels : La est une illustration d’un procédé de gestion d’événement variable dans un environnement à locataires multiples ; La est une illustration schématique d’un système de traitement de données informatiques à locataires multiples ou d’une gestion d’événement variable ; et, La est un diagramme d’étapes illustrant un procédé de gestion d’événement variable dans un environnement à locataires multiples. Description détaillée de l’invention Les modes de réalisation de l’invention fournissent une gestion d’événement variable dans un environnement à locataires multiples. Selon un mode de réalisation de l’invention, un certain nombre de versions différentes d’une application s’exécutent dans un environnement informatique à locataires multiples, chacune des versions étant formée en partie d’une collection de différents gestionnaires d’événement, chacun étant adapté pour traiter des événements reçus sur un bus d’événement dans l’environnement informatique. Ainsi, des différentes versions de l’application diffèrent en fonction de différentes dispositions des gestionnaires d’événement, certains de ces gestionnaires d’événement ayant une programmation suffisante pour traiter le même événement, bien que selon une logique de programme différente. Pour acheminer correctement un événement particulier sur le bus d’événement vers le gestionnaire d’événement approprié, un événement reçu peut être décodé pour identifier une version particulière parmi les versions impliquées par l’événement de sorte qu’une adresse de point d’arrivée spécifique pour un gestionnaire d’événement approprié parmi les gestionnaires d’événement pour l’événement correspondant à la version particulière puisse recevoir l’événement pour traitement. De cette manière, multiples locataires différents peuvent accéder à différentes versions de la même application dans le même environnement informatique à locataires multiples en affichant les mêmes événements sur le bus d’événement de l’environnement sans tenir compte des versions spécifiques de l’application visée par les événements. La est une illustration imagée d’un traitement de gestion d’événement variable dans un environnement à locataires multiples. Comme le montre la , un environnement informatique à locataires multiples 100 héberge différentes versions d’applications 110, 120 d’une application unique. Chacune des différentes versions 110, 120 comprend une combinaison correspondante de différents gestionnaires d’événement 130A, 130B, 140A, 140B. Certains des différents gestionnaires d’événement 130A, 130B sont configurés pour traiter un événement commun. Ainsi, multiples versions différentes 110, 120 de la même application s’exécutent simultanément dans l’environnement informatique à locataires multiples 100 en faisant varier différents des gestionnaires d’événement 130A, 130B, 140A, 140B pour traiter des événements communs. En fonctionnement, un événement 160A est placé sur un bus d’événement 150 dans l’environnement informatique à locataires multiples 100. Un routeur d’événement 170 reçoit l’événement 160A sur le bus d’événement 150 et en extrait un nom d’événement pour l’événement, une application cible pour l’événement et un propriétaire d’application pour l’application cible. Le routeur d’événement 170 combine ensuite le nom d’événement, l’application cible et le propriétaire d’application dans une clé 180 et soumet la clé 180 comme une interrogation à une table d’acheminement de gestionnaire d’événement 190. En réponse à l’interrogation, le routeur d’événement 170 reçoit un point d’arrivée correspondant à la clé 180. À cet égard, le routeur d’événement 170 reçoit de la table d’acheminement de gestionnaire d’événement 190 une combinaison d’un identificateur de déploiement, d’un identificateur d’archive et d’un identificateur d’application cible. Le routeur d’événement 170 combine ce qui précède en un préfixe et concatène le préfixe avec l’événement pour produire un point d’arrivée 160B. Enfin, le routeur d’événement 170 place le point d’arrivée 160B sur le bus d’événement 150 pour qu’elle soit traitée par l’un des gestionnaires d’événement 130A, 130B, 140A, 140B adaptés pour traiter l’événement 160A. Le traitement décrit à la peut être mis en œuvre dans un système de traitement de données informatiques. En outre, la est une illustration schématique d’un système de traitement de données informatiques à multiples locataires configuré ou d’un gestion d’événement variable. Le système comprend une plate-forme informatique hôte 200 accessible depuis un réseau de communication informatique 290 par différents utilisateurs finaux distants 295 et qui comprend un ou plusieurs ordinateurs 210, chacun avec un ou plusieurs processeurs 220 et une mémoire 230. La plate-forme informatique hôte 200 comprend également une mémoire 240 dans laquelle est stockée une table d’acheminement 260. La table d’acheminement 260 comprend un ensemble d’enregistrements mettant en corrélation les clés individuelles avec les données d’acheminement correspondantes, les clés comprenant chacune une identification d’un événement et un propriétaire d’application pour l’application cible et les données d’acheminement comprenant une indication d’un identificateur de déploiement, d’un identificateur d’archive et d’un identificateur d’application cible. La plate-forme informatique hôte 200 supporte un environnement informatique à locataires multiples dans lequel sont présentées les différentes versions 280 d’une application, chaque version étant définie par différentes combinaisons des différents gestionnaires d’événement 270, chacun s’exécutant dans la mémoire 230 de la plate-forme informatique hôte 200. À cet égard, les différents gestionnaires d’événement 270 sont adaptés pour traiter le même événement lorsqu’ils sont placés sur le bus d’événement 250 avec un routeur d’événement 300 interrogeant la table d’acheminement 260 pour déterminer un point d’arrivée pour un gestionnaire d’événement sélectionné parmi les gestionnaires d’événement 270 pour traiter un événement donné. Le routeur d’événement 300 détermine le point d’arrivée sur la base d’une clé assemblée à partir d’une combinaison d’une identification de l’événement donné et d’un propriétaire d’application d’une application cible incluse avec l’événement donné. Le routeur d’événement 300 place ensuite le point d’arrivée déterminé sur le bus d’événement 250 pour qu’il soit traité par le gestionnaire d’événement sélectionné parmi les gestionnaires d’événement 270. Pour illustrer encore davantage le fonctionnement du routeur d’événement 300, la est un organigramme illustrant un processus de gestion d’événement variable dans un environnement à locataires multiples. À partir du bloc 310, un événement est reçu sur le bus d’événement et dans le bloc 320, l’événement est décodé en un identificateur d’événement, un identificateur d’application cible et un identificateur d’un propriétaire d’application de l’application cible. Ensuite, dans le bloc 330, une clé est formulée avec une combinaison de l’identificateur d’événement, de l’identificateur d’application cible et de l’identificateur de propriétaire d’application. Dans le bloc 340, une table d’acheminement est interrogée avec la clé afin de récupérer un enregistrement spécifiant un identificateur de déploiement d’un gestionnaire d’événement spécifié, un identificateur d’une archive contenant le gestionnaire d’événement spécifié et un identificateur de l’application cible à laquelle le gestionnaire d’événement spécifié appartient. Dans le bloc 350, l’identificateur de déploiement précédent, l’identificateur d’une archive et l’identificateur de l’application cible sont combinés en un préfixe qui est ensuite concaténé avec l’événement du bloc 360 de manière à former un point d’arrivée. Enfin, dans le bloc 370, l’événement est acheminé vers le gestionnaire d’événement spécifié, accessible à un emplacement pouvant être résolu par le point d’arrivée. De cette manière, multiples versions différentes d’une application peuvent coexister dans le même environnement à locataires multiples de manière à permettre à différents utilisateurs finaux d’utiliser simultanément différentes versions. La présente invention peut être incorporée dans un système, un procédé, un programme informatique ou toute combinaison de ceux-ci. Le programme informatique peut comprendre un support de stockage lisible par ordinateur ou un support sur lequel se trouvent des instructions de programme lisibles par ordinateur pour amener un processeur à exécuter des aspects de la présente invention. Le support de stockage lisible par ordinateur peut être un dispositif tangible qui peut conserver et stocker des instructions à utiliser par un dispositif d’exécution d’instructions. Le support de stockage lisible par ordinateur peut être, par exemple, un dispositif de stockage électronique, un dispositif de stockage magnétique, un dispositif de stockage optique, un dispositif de stockage électromagnétique, un dispositif de stockage semi-conducteur ou toute combinaison appropriée de ce qui précède, sans toutefois s’y limiter. Les instructions de programme lisibles par ordinateur décrites ici peuvent être téléchargées à partir d’un support de stockage lisible par ordinateur ou sur un ordinateur externe ou un périphérique de stockage externe via un réseau, sur les dispositifs de calcul/traitement respectifs. Les instructions lisibles par ordinateur peuvent être exécutées entièrement sur l’ordinateur de l’utilisateur, en partie sur l’ordinateur de l’utilisateur, en tant que progiciel autonome, en partie sur l’ordinateur de l’utilisateur et en partie sur un ordinateur distant ou entièrement sur l’ordinateur ou le serveur distant. Certains aspects de la présente invention sont décrits ici à l’aide d’organigrammes et/ou de schémas fonctionnels de procédés, d’appareils (systèmes) et de produits de programmes informatiques sur la base des modes de réalisation de l’invention. Il est entendu que chaque bloc des organigrammes et/ou des schémas fonctionnels, ainsi que les combinaisons de blocs des organigrammes et/ou des schémas fonctionnels, peuvent être réalisés au moyen d’instructions de programme lisibles par ordinateur. Ces instructions de programme lisibles par ordinateur peuvent être fournies à un processeur d’un ordinateur à usage général, d’un ordinateur à usage spécifique ou d’un autre appareil de traitement de données programmable pour produire une machine, de sorte que les instructions, qui sont exécutées par l’intermédiaire du processeur de l’ordinateur ou d’un autre appareil de traitement de données programmable, créent des moyens pour exécuter les fonctions/actions spécifiées dans le ou les blocs des organigrammes et/ou des schémas fonctionnels. Ces instructions de programme lisibles par ordinateur peuvent également être stockées dans un support de stockage lisible par ordinateur qui peut diriger un ordinateur, un appareil de traitement de données programmable et/ou d’autres dispositifs pour fonctionner d’une manière particulière, de sorte que le support de stockage lisible par ordinateur dans lequel sont stockées des instructions comprend un article de fabrication comprenant des instructions qui exécutent des aspects des fonctions/actions spécifiées dans le ou les blocs des organigrammes et/ou des schémas fonctionnels. Les instructions de programme lisibles par ordinateur peuvent également être chargées sur un ordinateur, un autre appareil de traitement de données programmable ou un autre dispositif pour provoquer l’exécution d’une série d’étapes opérationnelles sur l’ordinateur, un autre appareil programmable ou un autre dispositif pour produire un procédé exécuté par ordinateur, de sorte que les instructions qui exécutent sur l’ordinateur, un autre appareil programmable ou un autre dispositif mettent en œuvre les fonctions/actions indiquées dans le ou les blocs des organigrammes et/ou des schémas fonctionnels. L’organigramme et les schémas fonctionnels présentés dans les figures illustrent l’architecture, la fonctionnalité et le fonctionnement d’implémentations possibles de systèmes, de procédés et de produits de programmes informatiques sur la base des diverses modes de réalisation de la présente invention. À cet égard, chaque bloc de l’organigramme ou des schémas fonctionnels peut représenter un module, un segment ou une partie d’instructions, qui comprend une ou plusieurs instructions exécutables pour mettre en œuvre la ou les fonctions logiques spécifiées. Dans certaines implémentations alternatives, les fonctions notées dans le bloc peuvent se produire dans l’ordre indiqué dans les figures. Par exemple, deux blocs montrés successivement peuvent, en fait, être exécutés sensiblement simultanément, ou les blocs peuvent parfois être exécutés dans l’ordre inverse, sur la base de la fonctionnalité impliquée. Il convient également de noter que chaque bloc des schémas fonctionnels et/ou des organigrammes, et les combinaisons de blocs des schémas fonctionnels et/ou des organigrammes, peuvent être mis en œuvre par des systèmes matériels spéciaux qui effectue les fonctions ou les actes spécifiés ou exécutent des combinaisons de matériel spécial et d’instructions informatiques. Enfin, la terminologie utilisée dans le présent document ne vise qu’à décrire des modes de réalisation particuliers et ne vise pas à limiter l’invention. Dans le présent document, les formes singulières "un/une", et "le/la" s’entendent également du pluriel, à moins que le contexte n’indique clairement le contraire. Il sera en outre entendu que les termes "comprend" et/ou "comprenant", lorsqu’ils sont utilisés dans la présente spécification, précisent la présence de caractéristiques, entiers, étapes, opérations, éléments et/ou composants indiqués, mais n’excluent pas la présence ou l’ajout d’une ou plusieurs autres caractéristiques, entiers, étapes, opérations, éléments, composants et/ou groupes de ceux-ci. Les structures, matériaux, actes et équivalents correspondants de tous les moyens ou éléments de l’étape et de la fonction dans les revendications ci-dessous sont destinés à inclure toute structure, tout matériau ou tout acte pour exécuter la fonction en combinaison avec d’autres éléments revendiqués comme revendiqué spécifiquement. La description de la présente invention a été présentée à des fins d’illustration et de description, mais ne se veut pas exhaustive ou limitée à l’invention sous la forme divulguée. De nombreuses modifications et variations seront apparentes aux hommes du métier sans s’écarter de la portée et de l’esprit de l’invention. Le mode de réalisation a été sélectionné et décrit afin d’expliquer au mieux les principes de l’invention et son application pratique, et de permettre à d’autres hommes du métier de comprendre l’invention pour diverses modes de réalisation avec diverses modifications adaptées à l’usage particulier envisagé. Après avoir ainsi décrit l’invention de la présente demande en détail et par référence à ses modes de réalisation, il apparaîtra que des modifications et des variations sont possibles sans s’écarter de la portée de l’invention définie dans les revendications ci-jointes comme suit : Procédé de gestion d’événement variable dans un environnement à locataires multiples comprenant les étapes consistant à : recevoir un événement placé sur un bus d’événement dans un système de traitement de données événementiel, l’événement correspondant à une multiplicité d’instances différentes d’un gestionnaire d’événement unique, chaque instance étant adaptée pour traiter l’événement ; décoder l’événement pour identifier une version d’une application cible pour l’événement ; faire correspondre la version de l’application cible à un point d’arrivée pour un gestionnaire d’événement particulier parmi les différents gestionnaires d’événement ; et acheminer l’événement vers le point d’arrivée correspondant. Procédé selon la revendication 1, dans lequel l’événement est reçu dans le bus d’événement en connexion avec un nom d’événement, la version de l’application cible et un propriétaire de la version de l’application cible, la correspondance utilisant le nom d’événement, la version de l’application cible et le propriétaire comme clé dans une table d’acheminement stockée dans la mémoire cache du système de traitement de données événementiel pour identifier le point d’arrivée. Procédé selon la revendication 2, dans lequel le point d’arrivée est un préfixe d’emplacement ajouté au nom d’événement, l’acheminement comprenant l’insertion du nom d’événement avec un préfixe sur le bus d’événement. Procédé selon la revendication 3, dans lequel le préfixe d’emplacement comprend une concaténation d’un identificateur de déploiement, d’un identificateur d’archive et d’un identificateur d’application. Procédé selon la revendication 4, comprenant en outre la reconstruction dynamique de la table d’acheminement à la suite d’une perte de données dans le système de traitement de données événementiels en interrogeant chaque instance de l’application cible en recevant, en réponse à l’interrogation de chaque instance correspondante de la version de l’application cible, l’identificateur de déploiement, l’identificateur d’archive et l’identificateur d’application pour chaque propriétaire souscrivant à l’instance correspondante de la version de l’application cible. Système de traitement de données adapté au gestion d’événement variable dans un environnement à locataires multiples, le système comprenant : une plate-forme informatique hôte comprenant un ou plusieurs ordinateurs, chacun comprenant de la mémoire et au moins un processeur ; et, un module de gestion d’événement variable comprenant des instructions de programme informatique activées lors de l’exécution dans la plate-forme informatique hôte pour exécuter les étapes consistant à : recevoir un événement placé sur un bus d’événement dans un système de traitement de données événementiels, l’événement correspondant à une multiplicité d’instances différentes d’un gestionnaire d’événement unique, chaque instance étant adaptée pour traiter l’événement ; décoder l’événement pour identifier une version d’une application cible pour l’événement ; faire correspondre la version d’application cible à un point d’arrivée pour un gestionnaire d’événement particulier parmi les différents gestionnaires d’événement ; et acheminer l’événement vers le point d’arrivée correspondant. Système selon la revendication 6, dans lequel l’événement est reçu dans le bus d’événement en connexion avec un nom d’événement, la version de l’application cible et un propriétaire de la version de l’application cible, la correspondance utilisant le nom d’événement, la version de l’application cible et le propriétaire comme clé dans une table d’acheminement stockée dans la mémoire cache du système de traitement de données événementiels pour identifier le point d’arrivée. Système selon la revendication 7, dans lequel le point d’arrivée est un préfixe d’emplacement ajouté au nom d’événement, l’acheminement comprenant l’insertion du nom d’événement avec un préfixe sur le bus d’événement. Système selon la revendication 8, dans lequel le préfixe d’emplacement comprend une concaténation d’un identificateur de déploiement, d’un identificateur d’archive et d’un identificateur d’application. Système selon la revendication 9, comprenant en outre la reconstruction dynamique de la table d’acheminement à la suite d’une perte de données dans le système de traitement de données événementiels en interrogeant chaque instance de la version de l’application cible en recevant, en réponse à l’interrogation de chaque instance correspondante de la version de l’application cible, l’identificateur de déploiement, l’identificateur d’archive et l’identificateur d’application pour chaque propriétaire souscrivant à l’instance correspondante de la version de l’application cible. Produit de programme informatique pour le gestion d’événement variable dans un environnement à locataires multiples, le produit de programme informatique comprenant un support de stockage lisible par ordinateur ayant des instructions de programme incorporées, les instructions de programme étant exécutables par un dispositif pour faire en sorte que le dispositif exécute un procédé comprenant les étapes consistant à : recevoir un événement placé sur un bus d’événement dans un système de traitement de données événementiels, l’événement correspondant à une multiplicité d’instances différentes d’un gestionnaire d’événement unique, chaque instance étant adaptée pour traiter l’événement ; décoder l’événement pour identifier une version d’une application cible pour l’événement ; faire correspondre l’application cible à un point d’arrivée pour un gestionnaire d’événement particulier parmi les différents gestionnaires d’événement ; et acheminer l’événement vers le point d’arrivée correspondant. Produit de programme informatique selon la revendication 11, dans lequel l’événement est reçu dans le bus d’événement en connexion avec un nom d’événement, la version de l’application cible et un propriétaire de la version de l’application cible, la correspondance utilisant le nom d’événement, la version de l’application cible et le propriétaire comme clé dans une table d’acheminement stockée dans la mémoire cache du système de traitement de données événementiels pour identifier le point d’arrivée. Produit de programme informatique selon la revendication 12, dans lequel le point d’arrivée est un préfixe d’emplacement ajouté au nom d’événement, l’acheminement comprenant l’insertion du nom d’événement avec un préfixe sur le bus d’événement. Produit de programme informatique selon la revendication 13, dans lequel le préfixe d’emplacement comprend une concaténation d’un identificateur de déploiement, d’un identificateur d’archive et d’un identificateur d’application. Produit de programme informatique selon la revendication 14, dans lequel le procédé comprend en outre la reconstruction dynamique de la table d’acheminement à la suite d’une perte de données dans le système de traitement de données événementiels en interrogeant chaque instance de l’application cible en recevant, en réponse à l’interrogation de chaque instance correspondante de l’application cible, l’identificateur de déploiement, l’identificateur d’archive et l’identificateur d’application pour chaque propriétaire souscrivant à l’instance correspondante de la version de l’application cible.