La présente invention a trait aux systèmes à événements discrets, et plus particulièrement aux procédés de contrôle de l’évolution séquentielle des ressources de tels systèmes.

On entend ici par système à évènements discrets tout système qui évolue dans le temps par occurrence d'évènements ou, par opposition à un système continu, tout système dont on n'a pas besoin d'observer l'évolution continûment mais seulement à l'occurrence d'évènements prédéfinis. Ces systèmes se caractérisent par un espace d'états discret et de transitions, par saut et non de façon continue, pour mettre en œuvre respectivement, sur occurrence d’évènements prédéfinis, un changement de l’état courant de ressources depuis un premier état vers un deuxième état. De ce fait, des modèles ou diagrammes états-transitions ou des graphes à évènements sont souvent utilisés pour contrôler ces systèmes à évènements discrets tels qu'un automate à états finis, un Grafcet, un réseau de Pétri, un diagramme d'activité UML (abréviation anglo-saxonne de « Unified Modeling Language ») ou un modèle algébrique, comme l'algèbre « Max Plus ».

La dynamique d'un système à évènements discrets correspond à l’évolution séquentielle de ses ressources par l'enchaînement des états de celles-ci par des transitions selon un processus (ou workflow selon une terminologie anglo-saxonne) régi par l'occurrence d'événements ponctuels. Ces évènements comprennent des conditions logiques telles que la détection d’un signal, la saisie d'un paramètre d'entrée par un utilisateur du système, l’achèvement d’une tâche, un changement de valeur d'une donnée ou, plus généralement, la vérification d'au moins une condition interne ou externe au système.

Des implémentations informatiques de systèmes à évènements discrets existent. A titre d’exemple, le document « Maar HAMRI et al. « Discrete event design patterns » DO1 10.1145/2486092.2486138, ISBN : 978-1-4503-2193-8, 19/05/2013s » divulgue une implémentation orientée objet qui est centrée sur l’événement selon laquelle une instance d’un objet événement, en fonction de l’événement produit et de l’état actuel d’une machine à états finis, détermine le prochain état de ladite machine à états finis. Un tel document divulgue en outre un mode de réalisation alternatif selon lequel un couple (événement produit, état courant de la machine à états finis) sélectionne une transition à déclencher qui, à son tour, modifie l’état suivant de ladite machine. Le document EP2182435A1 divulgue quant à lui un mode de programmation d’une machine à états finis selon lequel un objet peut prendre successivement plusieurs états définis par ladite machine d’états finis à la suite d’évènements et peut désigner une fonction dont l’exécution peut être déclenchée lors de la transition d’un premier état vers un deuxième état. Par ailleurs, des bases de données centrales ou distribuées sont généralement prévues pour y enregistrer ou récupérer des données du système.

Un inconvénient des modélisations existantes des systèmes à évènements discrets est qu'elles conduisent à des implémentations propres à chaque système, y compris pour des systèmes substantiellement similaires. Par exemple, des systèmes de billetterie en ligne ou, plus généralement, de vente en ligne présentent, indépendamment du bien proposé à la vente, souvent un même espace d'états caractérisant respectivement les ressources, en l’espèce des billets de réservation pour un système de billetterie, et de transitions entre ces états. Ils se traduisent pourtant par autant de mises en œuvre systèmes qu’il existe de biens proposés à la vente.

Il en résulte une multiplication des ressources informatiques nécessaires à la mise en œuvre de systèmes distincts bien que similaires, une surcharge des bases de données hébergeant les données de ces derniers ainsi que de nombreux inconvénients qui en découlent tels que la sécurité des données compte tenu de leur hétérogénéité, la maintenance de tels systèmes ou l'impact carbone des infrastructures informatiques pour les mettre en œuvre. Par ailleurs, toutes les applications susceptibles de requérir des changements d’états courants de ressources de tels systèmes doivent se conformer à, c’est- à-dire être développées pour satisfaire, des politiques de transitions d’états souvent distinctes d’une ressource à une autre ou d’un système à un autre. De telles applications ne sont donc pas à l’heure actuelle, capables de contribuer à l’évolution d’une pluralité de ressources concernées par des critères ou politiques d’évolutions distinctes. Il en résulte de nombreux développements redondants d’applications et une interopérabilité quasi impossible pour contribuer à l’évolution de ressources de différents systèmes à évènements discrets.

Un objet de la présente invention est de faciliter et d’optimiser le contrôle des systèmes à évènements discrets.

Un autre objet de la présente invention est de proposer des procédés de contrôle de l’évolution séquentielle de ressources de systèmes à évènements discrets, lesdites ressources pilotant leur évolution de manière autonome en réponse à des requêtes en changement de leur état courant.

Un autre objet de la présente invention est d'améliorer le contrôle des systèmes à évènements discrets en agissant sur leurs modélisations pour faciliter le déploiement de nombreuses ressources présentant des mêmes critères d’évolution séquentielle et leur conférer un contrôle autonome et homogène de leurs évolutions respectives quelles que soient les applications qui requièrent une telle évolution.

Un autre objet de la présente invention est de proposer un procédé de contrôle de l’évolution séquentielle d’une ressource d’au moins un système à évènements discrets en réponse à des requêtes en changement de l’état courant de cette ressource depuis un premier état vers un deuxième état de l’automate modélisant cette ressource.

A cet effet, il est proposé, en premier lieu, un procédé mis en œuvre par une infrastructure informatique pour le contrôle de l’évolution séquentielle d’une ressource d’au moins un système à évènements discrets modélisée par un automate présentant une pluralité d’états et au moins une transition pour mettre en œuvre, sur occurrence d'un évènement prédéfini, un changement de l’état courant de ladite ressource depuis un premier état vers un deuxième état de ladite pluralité d'états, ledit procédé comprenant, lors d’une requête en changement de l’état courant de ladite ressource, les étapes suivantes :

- lecture dans une mémoire de ladite infrastructure informatique d’un premier objet informatique représentant ladite ressource du système à évènements discrets, ledit premier objet informatique décrivant l’état courant de ladite ressource et comprenant une fonction destinée à être exécutée automatiquement par ladite infrastructure informatique lors d’une requête en changement de l’état courant de ladite ressource depuis le premier état vers le deuxième état ;

- exécution de ladite fonction associée à la transition d’états requise depuis le premier état vers le deuxième état ;

- mise à jour de l’état courant dudit premier objet informatique et/ou génération d’un deuxième objet informatique pour représenter tout ou partie de ladite ressource, le nouvel état courant décrit par le premier objet informatique et/ou le nouvel état courant décrit par le deuxième objet informatique étant respectivement déterminés par le résultat de l’exécution de ladite fonction associée à la transition d’états requise ;

- enregistrement dans ladite mémoire de ladite infrastructure informatique du premier et/ou deuxième objets informatiques.

Avantageusement, un tel procédé de contrôle basé sur le franchissement (ou tir) des transitions d’états favorise la factorisation de ladite fonction associée à la transition d’états requise entre plusieurs systèmes à évènements discrets intégrant cette même transition d’états. Une telle factorisation a pour avantage d'optimiser et de simplifier le contrôle des systèmes à évènements discrets.

Diverses caractéristiques supplémentaires peuvent être prévues, seules ou en combinaison : le premier objet informatique comprend au moins un attribut de la ressource du système à évènements discrets, ladite fonction étant apte à effectuer un traitement de données sur une valeur de l'attribut ;

- la fonction est apte à effectuer un traitement de données sur un paramètre d'entrée fourni lors de l’exécution de cette fonction ;

- la fonction est apte à réaliser un apprentissage automatique à partir de données prédéfinies ;

- la fonction comprend une condition portant sur une donnée temporelle ;

- le procédé comprend, en outre, une étape de génération préalable dudit premier objet informatique ;

- ladite mémoire est une base de données distribuée distante.

Il est proposé, en deuxième lieu, une infrastructure informatique configurée pour mettre en œuvre le procédé présenté ci-dessus, cette infrastructure informatique comprenant une base de données distribuée distante pour y enregistrer ou récupérer au moins une information relative au premier objet informatique.

Diverses caractéristiques supplémentaires peuvent être prévues, seules ou en combinaison :

- ladite au moins une information comprend un état auquel est associé le premier objet informatique ;

- ladite au moins une information comprend au moins une valeur d’un attribut d'une ressource du système à évènements discrets à un état auquel est associé le premier objet informatique.

D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement et de manière concrète à la lecture de la description ci-après de modes de réalisation, laquelle est faite en référence aux dessins annexés dans lesquels :

- la figure 1 illustre de manière schématique des états d'un automate selon divers modes de réalisation contrôlant l’évolution séquentielle d’une ressource d’un système à événements discrets ;

- la figure 2 illustre de manière schématique une infrastructure informatique mettant en œuvre un procédé pour le contrôle de l’évolution séquentielle de ressources selon un tel automate selon divers modes de réalisation ;

- la figure 3 illustre schématiquement des étapes d’un procédé mis en œuvre par une infrastructure informatique pour le contrôle de l’évolution séquentielle d’une ressource d’au moins un système à évènements discrets modélisée par un automate.

En se référant à la figure 1 , il est affiché un premier et un deuxième état 1 , 2 d'un automate 10, ou encore dénommé « machine à états » 10, modélisant une évolution séquentielle possible d’une ressource d’un système à évènements discrets. Une transition 21 permet, sur occurrence d'un évènement prédéfini, de mettre en œuvre un changement de l’état courant d’une ressource depuis un premier état 1 vers un deuxième état 2. Ce n'est que pour des raisons de simplicité que seulement deux états 1 , 2 de l’automate

10 sont représentés sur la figure 1. Cet automate 10 peut, bien entendu, comprendre d’autres états ainsi que des transitions entre ces états pour modéliser l’évolution séquentielle des ressources d’un système à évènements discrets.

Un objet 11 informatique (que nous pourrions également nommer « jeton

11 numérique », voire encore « structure numérique 11 enregistrée dans une mémoire ») représente une ressource du système à évènements discrets. Cet objet 11 informatique décrit l’état courant d’une ressource, par exemple l’état 1 de l’automate 10. En fonction des évolutions respectives de différentes ressources du système à évènements discrets, un ou plusieurs objets informatiques 11-13, associés respectivement auxdites différentes ressources, décrivent un même état courant ou des états courants différents de l’automate 10. Par exemple, lorsque le système à évènements discrets est un système de billetterie en ligne, des ressources de ce système (à savoir, des billets) sont représentées respectivement par un ou plusieurs objets 11-13 informatiques éventuellement associés à des états 1 , 2 différents de l’automate 10 (par exemple, « billet en vente », « billet vendu », « billet remboursé », « billet en revente », ou « billet modifié »).

Dans le paradigme de programmation orientée objet ou de programmation par objet (dite « Object oriented programming » selon une terminologie anglo-saxonne), l'objet 11 informatique comprend des données descriptives, appelées attributs, d’au moins une ressource du système à évènements discrets auquel est associé l’objet 11 informatique. Un attribut peut être une valeur simple ou un conteneur pouvant stocker plusieurs informations. Un attribut décrit l’état courant de la ressource à laquelle l’objet 11 informatique est associé. Dans un autre mode de réalisation, une propriété de l’objet 11 informatique décrit l’état courant de la ressource à laquelle cet objet 11 informatique est associé.

L'objet 11 informatique comprend, en outre, par transition d’états possible, au moins une fonction, une méthode et/ou une procédure (dites «. Function » ou « Method » selon des terminologies anglo-saxonnes) désignées ci-dessous indifféremment par « fonction ». Cette fonction est apte à effectuer un traitement de données ou un calcul sur les valeurs des attributs et/ou sur des paramètres d'entrée, également nommés « arguments ».

En liaison avec la figure 1 , au moins une fonction de l'objet 11 informatique est destinée à être exécutée lors du franchissement (également nommé « tir ») de la transition 21. Cette fonction de franchissement de la transition 21 comprend un script ou un programme exécutable automatiquement par un ordinateur ou plus généralement par une infrastructure informatique requérant le franchissement de cette transition 21. Autrement dit, le franchissement requis de la transition 21 sur occurrence d'un évènement prédéfini provoque l'exécution par l’infrastructure informatique d'au moins une fonction de l'objet 11 informatique. Une fonction de l'objet 11 informatique est exécutée lors du franchissement de la transition 21 en utilisant des attributs de l’objet 11 informatique et/ou ceux d’un autre objet 13 informatique, des paramètres de contexte (par exemple la date, l’heure ou la localisation géographique de l'exécution) et/ou en provoquant l’exécution d’une autre fonction dont le résultat est considéré comme paramètre d'entrée ou de façon interactive en utilisant des paramètres d'entrée (c’est-à-dire des données « extérieures ») fournis lors de l’exécution de cette fonction, par exemple par un utilisateur du système via une interface homme-machine d’entrée, telle qu’un clavier d’ordinateur ou une interface graphique ou tactile, voire de pointage.

Une fonction de l'objet 11 informatique peut être appelée ou invoquée (c’est-à-dire dont l’exécution peut être provoquée) par une autre fonction de ce même objet 11 informatique ou d'un autre objet informatique. Deux objets informatiques peuvent communiquer entre eux par envoi de messages de façon à pouvoir appeler une fonction déclarée dans un premier objet informatique depuis un deuxième objet informatique. L'objet 11 informatique est susceptible de participer de façon autonome à des processus impliquant plus d'un objet informatique.

Le franchissement d'une transition 21 se traduit par l’exécution d’au moins une fonction de l'objet 11 informatique. L'exécution d'une fonction de l'objet 11 informatique lors du franchissement de la transition 21 provoque, en effet, la mise en œuvre de l’évolution séquentielle des ressources du système à évènements discrets.

Un arc 121 orienté reliant le premier état 1 à la transition 21 (la transition 21 étant en aval de l'état 1 par rapport au sens de l'arc 121 orienté) est nommé ou comporte une étiquette. Cette étiquette intègre une référence (par exemple un nom) de l'objet 11 informatique. Dans un mode de réalisation, cette étiquette intègre, en outre, une référence de la fonction de l’objet 11 informatique destinée à être exécutée lors du franchissement de la transition 21. Par exemple, lorsque le système à évènements discrets se rapporte à un système de tenue de carnets d'entretien de véhicules automobiles et que l'objet 11 informatique matérialise un carnet d'entretien (éventuellement chiffré) d'un certain véhicule automobile associé au premier état 1 , une fonction de cet objet 11 informatique peut être un procédé d'authentification (éventuellement avec des clés de déchiffrement) impliquant le propriétaire du véhicule automobile (par exemple, fourni comme attribut dans l'objet 11 informatique) et/ou l'organisme d'entretien (par exemple fourni comme paramètre d'entrée) pour pouvoir mettre à jour le carnet d'entretien du premier état 1 (par exemple une première révision d’un plan d’entretien) à un deuxième état 2 (par exemple une deuxième révision du plan d’entretien postérieure à la première révision). Une telle fonction permet, avantageusement, de garantir la conformité du suivi de l'entretien du véhicule automobile quelle que soit l’application ou l’infrastructure informatique qui requiert l’évolution séquentielle dudit carnet d’entretien. Des attributs d’un carnet d’entretien peuvent comprendre, par exemple, un ou plusieurs identifiants d’un véhicule automobile, une ou plusieurs informations relatives au propriétaire actuel (et, éventuellement, aux propriétaires précédents), au fabricant et/ou à l’utilisateur du véhicule automobile, un contenu (historique des interventions par exemple), une ou plusieurs échéances concernant des prochaines interventions, des droits de lecture et/ou d’écriture dans le carnet d’entretien.

Dans un autre exemple, lorsque le système à évènements discrets concerne un système de suivi en plusieurs étapes de transactions financières et que l'objet 11 informatique représente une transaction dont l’état courant est le premier état 1 , une fonction de cet objet 11 informatique peut être un procédé de vérification de l'identité des clients (processus connu sous le nom « connaissance du client » ou selon l’acronyme anglo-saxon KYC pour « Know your customer »), notamment dans le cadre d'une démarche de lutte contre le blanchiment de capitaux (ou selon l’acronyme anglo-saxon AML pour « Anti-Money Laundering »), pour que la transaction puisse passer (transition 21) du premier état 1 (par exemple, « identité vérifiée ») à un deuxième état 2 (par exemple, « transaction autorisée ») du processus de suivi. Une telle fonction permet avantageusement de faciliter les levées de fond par finance décentralisée tout en vérifiant la KYC-AML directement dans le workflow. Dans ce système, les clients peuvent également être représentés par des objets informatiques, comportant des attributs et/ou des fonctions, associés à des états d’un automate modélisant une évolution séquentielle des statuts de ces clients.

Dans un autre exemple, lorsque le système à évènements discrets est un système de facturation selon différentes législations et impliquant plusieurs monnaies et que l’objet 11 informatique représente un document de facture associé au premier état 1 (« facture émise », « en attente de paiement »), une fonction de cet objet 11 informatique peut être un convertisseur à jour de devises, un calculateur d'une pénalité de retard ou une procédure propre à une certaine législation pour passer ce document de facture du premier état 1 à un deuxième état 2 (tel que « facture acquittée », « facture validée » ou « facture relancée »).

Dans un mode de réalisation, l'objet 11 informatique comprend une fonction apte à réaliser un apprentissage automatique à partir de données mises à sa disposition. Ces données peuvent être des données relatives aux états 1 , 2 courants et/ou antérieurs des ressources du système à évènements discrets, des données relatives à des utilisateurs de ce système, des valeurs d’un ou plusieurs attributs d’une pluralité d’objets informatiques et/ou des données de contexte. Les données d'apprentissage peuvent être fournies dans une base de données distribuée et/ou être associées à un état d'apprentissage de l'automate 10. Un tel apprentissage automatique permet, par exemple, à une fonction de modifier la valeur d'un attribut compris dans l'objet informatique ou de sélectionner une fonction à appeler parmi une pluralité de fonctions. Une fonction d’apprentissage automatique permet, par exemple, d’adapter le prix d’un billet électronique proposé à la vente à partir de données d’apprentissage, telles que l’offre et la demande lors du franchissement de la transition 21 , les prix antérieurs, l’évolution dans le temps de la demande, des données météorologiques, la présence/absence d’alternatives concurrentes par exemple.

L’exécution automatique de la fonction de l’objet 11 informatique lors du franchissement de la transition 21 permet de mettre à jour cet objet 11 informatique, qui représente une ressource du système à évènements discrets, de sorte que l’attribut décrivant l’état courant de la ressource corresponde au deuxième état 2 de l’automate 10. Ainsi, le nouvel état courant de la ressource est déterminé par l’exécution automatique de la fonction associée à la transition 21 qui a été requise et/ou de la transition d’états requise. Dans un mode de réalisation, le résultat de la fonction conditionne l’assignation de l’objet 11 informatique au deuxième état 2 de l’automate 10. Dans un autre mode de réalisation, l’exécution de la fonction de l’objet 11 informatique déclenche la génération d’un deuxième objet 12 informatique pour représenter au moins une partie de ladite ressource. Ce mode de réalisation est particulièrement avantageux notamment lorsque cette ressource est divisible et l’événement produit ne concerne qu’une partie de cette ressource. Ce deuxième objet 12 informatique est associé au deuxième état 2, c’est-à-dire que l’attribut dudit deuxième objet informatique décrivant l’état courant de la division de la ressource représentée par l’objet 11 informatique, correspond à l’état 2. Lorsqu’un deuxième objet 12 informatique est généré à la suite de l’exécution de ladite fonction, le premier objet 11 informatique est mis à jour ou adapté en conséquence. Cette mise à jour porte, notamment, sur la valeur d’un attribut décrivant l’état courant de la ressource que l’objet 11 informatique représente. Par exemple, lorsque l’objet 11 informatique représente un ensemble de ressources d’un système à évènements discrets (tel qu’une première pluralité de billets à vendre ou une deuxième pluralité de billets achetés par une personne dans un système de billetterie en ligne) et l’évènement produit associé à la transition 21 est lié à un sous-ensemble desdites ressources (requête d’achat d’un premier sous- ensemble de la première pluralité ou une requête d’annulation d’un deuxième sous-ensemble de la deuxième pluralité), un nouvel objet 12 informatique représentant ce sous-ensemble de ressources est associé au deuxième état 2. Ce sous-ensemble de ressources est déduit de l’objet 11 informatique lors d’une mise à jour de ce dernier par une instanciation par exemple.

Dans un mode de réalisation avantageux, une fonction de l’objet 11 informatique peut utiliser comme paramètre d'entrée, lors du franchissement de la transition 21 , la valeur d’au moins un attribut d’un ou plusieurs autres objets 13 informatiques, par exemple, les états courants respectifs de ces autres objets informatiques, le nombre d’objets informatiques associés à un certain état de l’automate 10 ou, plus généralement, une valeur d’un attribut de l’un de ces objets informatiques.

Plus généralement, l'exécution d’une fonction de l’objet 11 informatique permet de déterminer comment cet objet 11 informatique évolue dans le « workflow » ou processus d’évolution du système à évènements discrets. L'exécution de cette fonction lors du franchissement de la transition 21 détermine la valeur de l’attribut de l'objet 11 informatique pour que ce dernier décrive le deuxième état 2 en lieu et place du premier état 1 ou en génère un autre et l’associe au deuxième état 2. Il en résulte que l'objet 11 informatique est avantageusement actif dans le sens où les fonctions respectivement associées aux transitions d’états courants possibles déterminent, lors d’une transition requise, le prochain état courant de la ressource à laquelle il est associé.

La capacité de l'objet 11 informatique à maîtriser son évolution selon les différents états de l'automate 10 par franchissement de ses transitions permet, avantageusement, de programmer un workflow complet d'un système à évènements discrets, de s'assurer qu'un cheminement particulier de la valeur de l’attribut décrivant l’état courant de la ressource représentée par l'objet 11 informatique est respecté. L’évolution de l’objet 11 informatique à l’intérieur du workflow est gouvernée par les fonctions associées aux différentes transitions d’états possibles des ressources du système à évènements discrets.

Par exemple, dans le cas d'une fonction de l'objet 11 informatique comprenant une condition qui, lors du franchissement de la transition 21 , n'est pas satisfaite (à titre d'exemples non limitatifs un délai expiré, un échec d'authentification ou une valeur seuil dépassée), le nouvel état courant demeure le premier état 1 et n’est pas modifié pour correspondre au deuxième état 2 si la condition avait été satisfaite. Autrement dit, l'objet 11 informatique demeure associé au premier état 1 malgré la transition d’état requise. Une condition portant sur une donnée temporelle permet, avantageusement, de conférer une composante « temps » à la ressource représentée par l'objet 11 informatique permettant, notamment, de lui donner une durée de vie ou de validité.

L’utilisation d'une fonction issue de l'objet 11 informatique pour franchir une transition 21 et pour indiquer à cet objet 11 informatique le prochain état auquel il sera associé permet, avantageusement, de faciliter le suivi de l'exécution de l'automate 10.

Dans un mode de réalisation, au moins une information relative à l'objet 11 informatique (des attributs, des paramètres d'entrée d'au moins une fonction, des données de sortie générées par au moins une fonction, l'évolution d'un objet 11 informatique, et/ou l'état 1 , 2 auquel est associé cet objet 11 informatique) est enregistrée ou récupérée dans ou depuis une base de données distribuée distante, notamment une blockchain. Une factorisation des états de l'automate 10 ou, plus précisément, de l'objet 11 informatique entre plusieurs systèmes à évènements discrets similaires est ainsi possible. Un seul automate 10 peut être utilisé pour imposer l'exécution d’un même workflow pour une pluralité de ressources. Ainsi, un objet informatique type peut être déterminé en tant que modèle. Par instanciation d’un tel modèle, il est possible d’associer respectivement à plusieurs ressources des objets informatiques présentant des attributs et fonctions identiques. De même, la programmation d'une pluralité de workflows peut être factorisée en un seul. Par exemple, un objet 11 informatique peut être conçu de façon à couvrir plusieurs plateformes de vente en ligne de biens et/ou de services, où généralement seuls des attributs sont à adapter (vendeur, biens proposés à la vente, monnaie, tarifs, ou coordonnées bancaires par exemple). Une telle factorisation a pour avantage d'optimiser et de simplifier le contrôle des systèmes à évènements discrets.

A l'occurrence d'un évènement associé à la transition 21 de l’automate 10 décrivant l’évolution séquentielle autorisée d’au moins une ressource d'un certain système à évènements discrets,

- les informations relatives à l'objet 11 informatique représentant au moins une ressource de ce système à l'état 1 sont récupérées depuis la base de données distribuée, ledit objet informatique étant lu ou collecté depuis une telle base de données ;

- la fonction associée à la transition requise 21 est exécutée par la plateforme informatique requérant ladite transition d’état 21 , dont le résultat d’exécution détermine la valeur du nouvel état courant de la ressource,

- la transition 21 étant franchie, l’objet 11 informatique (ou un nouvel objet 12 informatique) est associé au deuxième état 2, c’est-à-dire l’attribut décrit l’état courant de la ressource est mis à jour pour qu’il décrive l’état 2 en lieu et place de l’état 1 ; et

- l’objet informatique 11 est enregistré dans la base de données distribuée.

Dans une mise en œuvre illustrative de divers modes de réalisation, la figure 2 décrit une représentation graphique d'un automate 10 comprenant une succession d’états et de transitions associées à des événements.

Les états 1-5 de l'automate 10 représentent des évolutions possibles d'une pluralité de ressources de systèmes à évènements discrets. Ces systèmes peuvent appartenir à des personnes morales ou physiques différentes. A titre d'exemple non limitatif, ces systèmes à évènements discrets sont des systèmes de vente en ligne de biens et/ou de services ou, plus généralement, de tout objet matériel ou immatériel pouvant être proposé à la vente, tels que des droits d'entrée, des billets de transport, des actions en bourse, des biens physiques, des biens d'occasion, ou des biens culturels. Dans un autre mode de réalisation, les systèmes à évènements discrets peuvent se rapporter à des systèmes de réservation ou de prise de rendez- vous en ligne, d'appels d'offres en ligne ou de tenue de registres pour la gestion de patrimoine immobilier, de qualifications d'un utilisateur, ou encore de transactions d'un compte bancaire.

Dans un mode de réalisation, une modélisation orientée objet des systèmes à évènements discrets est réalisée au moyen d'un réseau de Petri (notamment pour des workflows comportant des phénomènes de concurrence, de synchronisation, et/ou de parallélisme), un Grafcet, un diagramme d'activité UML, une chaîne de Markov ou un modèle algébrique.

Une implémentation dans une infrastructure 20 informatique d'une modélisation orientée objet d'une pluralité de systèmes à évènements discrets peut être obtenue, par exemple, par la bibliothèque SNAKES (disponible à la date de dépôt de la présente demande sur https://snakes.ibisc.univ-evry.fr/), toute version ultérieure de celle-ci, ou tout autre moyen équivalent. L’infrastructure 20 informatique comprend les matériels et les logiciels permettant la mise en œuvre de l’automate 10. Une implémentation de l’automate 10 peut, par exemple, être hébergée sur un serveur Web et/ou un serveur d'applications accessibles via un site Web ou une application mobile.

Par exemple, un automate 10 décrivant l’évolution séquentielle autorisée de billets de réservation émis par des billetteries en ligne (par exemple, de spectacles, d'expositions ou de transports) est traduit par des fonctions et attributs d’un ensemble d’objets informatiques instanciés depuis un modèle. Les ressources (billets de réservation) représentées respectivement par lesdits objets informatiques sont d'abord mises en vente (état 1) par des vendeurs 31. Les attributs décrivant les états courants des ressources sont initialisés pour décrire l’état 1. Ces ressources peuvent être hétérogènes de diverses catégories de services appartenant à des vendeurs 31 différents. Un objet 11 informatique représentant un billet à cet état 1 peut comprendre des attributs concernant ce billet proposé à la vente (tels que l'identité du vendeur 31 , nom du spectacle, numéro de place, date du spectacle, prix, offre promotionnelle, frais applicables par la plateforme de revente, d’enchère, ou de mise en relation ou par l’opérateur de l’infrastructure 20 informatique). Ces attributs, conjointement à l’objet informatique 11 , peuvent être enregistrés dans une base de données distribuée 30 distante telle qu'une blockchain.

Sur demande d'achat d'un billet proposé à la vente par un acheteur 32 (évènement associé à la transition 21 ), une fonction de l'objet 11 informatique, ce dernier étant initialement associé à l'état courant 1 , est exécutée lors du franchissement requis de la transition 21 afin de valider un paiement et transférer la propriété (mise à jour des valeurs des attributs) du billet depuis un vendeur 31 à l'acheteur 32. Une fois cette fonction exécutée, l'objet 11 informatique représentant ce billet est associé à l'état 2 de billet vendu. Cette association, découlant de la mise à jour de l’attribut décrivant le nouvel état courant de la source, est enregistrée (publiée) dans la base de données distribuée 30.

Dans le cas d'un report de la date du spectacle pour lequel est destiné le billet acheté (évènement associé à la transition 22), une modification de l’état du billet est requise. Automatiquement, la fonction associée à la transition 22 est exécutée. Selon le résultat de ladite exécution, le nouvel état du billet est déterminé. L’attribut de l'objet informatique 11 représentant ce billet et décrivant l’état courant de ladite ressource prend la valeur correspondant à l'état 3. En l’absence de fonction (ou fonction identité, « yes function » selon une terminologie anglo-saxonne) associée à une transition possible, aucune condition de franchissement d’une telle transition n’est requise, ladite transition étant systématiquement acceptée par l’objet informatique. En variante, une telle absence de fonction peut signifier une impossibilité de satisfaire une telle requête en transition (« no function » selon une terminologie anglo-saxonne).

Sur requête de l'acheteur 32 souhaitant revendre son billet (évènement associé à la transition 23 de l’automate 10), la validité du billet est vérifiée par l’exécution automatique de la fonction associée à ladite transition possible. Selon le résultat de ladite exécution, les attributs de l’objet informatique 11 sont mis à jour lors du franchissement de la transition 23. Le billet est ensuite mis à l'état 4 de revente, c’est-à-dire que l’attribut de l’objet 11 informatique décrivant l’état courant du billet, prend une nouvelle valeur correspondant à l’état 4. Dans le cas d'une décision d’annulation du spectacle issue du vendeur 31 ou une demande d’annulation du billet issue de l’acheteur 32 (évènements associés à la transition 24), une fonction de remboursement est automatiquement exécutée lors du franchissement requis de la transition 24 et l’attribut de l'objet 11 informatique décrivant l’état courant du billet est mis à jour (état 5) pour préciser que le billet est un billet remboursé.

L'état de l'automate 10 décrit par tout objet informatique (dont l’objet 11 informatique) peut être sauvegardé à tout moment dans la base de données distribuée 30 et rechargé, lors d’une lecture/collecte subséquente dudit objet informatique pour poursuivre l’évolution séquentielle de la ressource présentée par ledit objet informatique, notamment en réponse à une nouvelle requête en modification de l’état de la ressource à la suite d’une occurrence d'un évènement associé à l'une quelconque des transitions 21-24 possibles.

L’infrastructure 20 informatique désigne ici le matériel et les logiciels (tel qu’un ou plusieurs serveurs WEB (abréviation anglo-saxonne de « World Wide Web » c’est-à-dire des serveurs accessibles au moyen de navigateurs), un ou plusieurs serveurs d’application ou équivalents permettant d’offrir des capacités suffisantes de traitement pour mettre en œuvre l'automate 10 traduit par l’exécution automatique des fonctions associées aux transition possibles véhiculées par les objets informatiques et de lecture/collecte ou enregistrement de ces derniers dans la base de données 30, avantageusement distribuée.

Un tel matériel d’une infrastructure 20 informatique peut avantageusement se présenter sous la forme d’un ou plusieurs microcontrôleurs ou microprocesseurs. Ce ou ces derniers coopèrent notamment avec une mémoire de données pour enregistrer ou lire des données élaborées par la mise en œuvre dudit automate ainsi que des paramètres de fonctionnement, ou plus généralement toutes données produites ou préenregistrées, qu’elles consistent en des données intermédiaires ou de résultats. De tels moyens de traitement comportent en outre une mémoire de programmes pour enregistrer des instructions d’un programme d’ordinateur dont l’exécution provoque la mise en œuvre de procédés. On entend par « mémoire de données ou de programmes » toute mémoire informatique volatile ou, avantageusement, non volatile. Une mémoire non volatile est une mémoire informatique dont la technologie permet de conserver ses données en l’absence d’une alimentation en énergie électrique. Elle peut contenir des données résultant de saisies, de calculs, de mesures et/ou des instructions de programmes. Les principales mémoires non volatiles actuellement disponibles peuvent être inscriptibles et/ou effaçables électriquement. Elles s’appuient sur les technologies EPROM (acronyme anglo-saxon de « Erasable Programmable Read-Only Memory »), EEPROM (acronyme anglo-saxon de « Electrically Erasable Programmable Read-Only Memory »), flash, SSD (acronyme anglo-saxon de « Solid-State Drive »), etc. Les mémoires « non volatiles » se distinguent des mémoires dites « volatiles » dont les données sont perdues en l’absence d’une alimentation électrique. Les principales mémoires volatiles actuellement disponibles sont de type RAM (acronyme anglo-saxon de « Random Access Memory » ou encore nommée « mémoire vive »), DRAM (acronyme anglo-saxon de « Dynamic Random Access Memory » désignant une mémoire vive dynamique, nécessitant une réactualisation régulière), SRAM (acronyme anglo-saxon de « Static Random Access Memory » désignant une mémoire vive statique nécessitant une telle réactualisation lors d’une sous-alimentation électrique), DPRAM ou VRAM (acronymes anglo-saxons respectifs de « Dual Ported Random Access Memory » et « Video Random Access Memory » désignant des mémoires particulièrement adaptées à la vidéo), etc. Une « mémoire de données », dans ce document, peut être volatile ou non volatile.

Avantageusement, une infrastructure 20 informatique supportant une telle mise en œuvre de l’automate 10 pourvu d'une bibliothèque d'objets 11 informatique (intégrant, par exemple, des fonctions de paiement, de vérification de conditions, d’authentification, de calcul, d’apprentissage, ou de validation) décrivant divers comportements de systèmes à évènements discrets permet de supporter et de gérer simultanément plusieurs systèmes à évènements discrets.

Il en résulte que l’infrastructure 20 informatique est agencée pour mettre en œuvre un procédé pour le contrôle de l’évolution séquentielle de ressources d’au moins un système à évènements discrets modélisée par l’automate 10. Ce procédé comprend :

- une étape de génération 40 préalable d’au moins un premier objet 11 informatique représentant une ressource du système à évènements discrets, cet objet 11 informatique décrivant l’état 1 courant de ladite ressource et comprenant une fonction destinée à être exécutée automatiquement par l’infrastructure 20 informatique lors d’une requête en changement de l’état 1 courant de ladite ressource depuis le premier état 1 vers un deuxième état (2) ;

- lors d’une requête en changement de l’état courant de ladite ressource, une étape de lecture 41 dans une mémoire de l’infrastructure 20 informatique du premier objet 11 ;

- une étape d’exécution 42 de ladite fonction associée à la transition d’états requise depuis le premier état 1 vers le deuxième état 2 lors du franchissement de la transition 21 ;

- une étape de mise à jour 43 de l’état courant du premier objet informatique et/ou une étape de génération 44 d’un deuxième objet 12 informatique pour représenter tout ou partie de ladite ressource, le nouvel état courant décrit par le premier objet 11 informatique et/ou le nouvel état courant décrit par le deuxième objet 12 informatique étant respectivement déterminés par le résultat de l’exécution de ladite fonction associée à la transition d’états requise ;

- une étape d’enregistrement 45 dans ladite mémoire de l’infrastructure informatique 20 du premier et/ou deuxième objets 11 , 12 informatiques. Cette implémentation informatique d’un système à événements discrets est centrée sur le franchissement (ou tir) des transitions d’états de l’automate 10 modélisant l’évolution séquentielle d’au moins une ressource du système à événements discrets.