Brevet FR3144884A1 — publié le 20240712

L’invention divulgue une méthode de gestion d’au moins une ressource d’un ensemble de ressources fournies par une pluralité de clients comprenant, ladite méthode étant mise en œuvre par un serveur et comprenant: la définition, par un serveur, dans une structure définissant des droits d’accès pour un ensemble de ressources fournies par une pluralité de clients, et à la réception d’une première requête d’un premier client de ladite pluralité de clients, des droits d’accès d’au moins une ressource fournie par ledit premier client; la réception d’une requête d’une premier client de ladite pluralité de clients, demandant l’accès à au moins une ressource fournie par un deuxième client, la fourniture, par ledit serveur de l’accès à ladite au moins une ressource audit premier client si les droits d’accès le permettent. Figure de l’abrégé : Figure 2 METHODE ET SERVEUR DE GESTION DE DROITS D’ACCES A DES RESSOURCES PARTAGEES La présente divulgation relève du domaine du partage des ressources informatiques. Plus particulièrement, elle relève du domaine de la gestion des droits d’accès à des ressources informatiques partagées. Le partage, ou mutualisation, de ressources informatiques consiste à partager, entre plusieurs acteurs, des ressources détenues par les différents acteurs. Le partage de ressources peut s’opérer entre plusieurs clients d’au moins un serveur, qui envoient des requêtes au serveur pour partager leurs ressources et accéder à celles d’autres clients. Le partage de ressources apporte des bénéfices aux clients dans de nombreux domaines. Par exemple, les clients peuvent partager des fichiers, mais aussi des bases d’entrainement de moteurs d’apprentissage automatique afin de mutualiser leurs bases d’apprentissage. La mutualisation de ressources peut encore par exemple porter sur des éléments fédérés de jumeaux numériques. Cependant, le partage d’une ressource par un client comporte le risque d’accès non désiré à la ressource par des tiers, ou d’usage abusif de la ressource par un autre client. Ce risque est particulièrement fort lorsqu’il existe une différence importante d’importance entre deux clients, et peut freiner l’adoption de solutions de mutualisation de ressources par des clients. Il y a donc besoin de solutions de partage de ressource entre plusieurs clients, permettant à chaque client de contrôler les droits d’accès aux ressources qu’il fournit. Résumé La présente divulgation vient améliorer la situation. Il est proposé une méthode de gestion d’au moins une ressource d’un ensemble de ressources fournies par une pluralité de clients, ladite méthode étant mise en œuvre par au moins un serveur et comprenant : la définition, par l’au moins un serveur, dans une structure définissant des droits d’accès pour un ensemble de ressources fournies par une pluralité de client, et à la réception d’une première requête d’un premier client de ladite pluralité de clients, des droits d’accès d’au moins une ressource fournie par ledit premier client ; la réception, par l’au moins un serveur, d’une deuxième requête d’un deuxième client de ladite pluralité de clients, demandant l’accès à l’au moins une ressource fournie par le premier client ; la fourniture, par l’au moins un serveur, de l’accès à l’au moins une ressource audit deuxième client si les droits d’accès le permettent. On entend par "structure" une organisation de données permettant de formaliser des données informatiques. Une structure peut par exemple être un tableau ou une base de données. On entend par "ressource" un élément utilisable par une application pour son exécution. Une ressource peut être: une ressource matérielle, tel qu'une ressource de calcul, une ressource mémoire, une ressource réseau, etc. du contenu pouvant être utilisé par des applications, tels que du contenu multimédia, des lignes de codes, des mots de passe, etc. Le contenu peut être par exemple défini dans des fichiers ou bases de données, des modèles entraînés grâce à du contenu fourni par le premier client, etc. une API permettant l'exécution d'une fonction spécifique. On entend par "client" une entité envoyant des requêtes au serveur afin de fournir du contenu, définir des droits d'accès et/ou accéder à du contenu. Un client peut par exemple être défini par un terminal utilisateur, un utilisateur d'un terminal, une entreprise ou une application exécutée par exemple dans une machine virtuelle ou un conteneur. Ceci permet un partage de ressources entre plusieurs clients, tout en permettant à chaque client de contrôler les droits d’accès aux ressources qu’il fournit. Dans d’autres termes, la méthode proposée permet d’orchestrer la mutualisation de ressources entre plusieurs clients avec une sécurité renforcée. Selon un autre aspect, il est proposé un serveur de gestion d’au moins une ressource d’un ensemble de ressources fournies par une pluralité de clients comprenant : un accès à un ensemble de ressources fournies par une pluralité de clients; un accès à une structure définissant des droits d’accès pour l’ensemble de ressources; au moins une unité de calcul configurée pour : définir dans ladite structure, à la réception d’une première requête d’un premier client de ladite pluralité de clients, les droits d’accès d’au moins une ressource fournie par ledit premier client; recevoir une requête d’un deuxième client de ladite pluralité de clients, demandant l’accès à au moins une ressource fournie par le premier client ; fournir l’accès à ladite au moins une ressource audit deuxième client si les droits d’accès le permettent. On entend par « unité de calcul » un composant électronique apte à effectuer des calculs électroniques ou informatiques pour effectuer une fonction déterminée. Une unité de calcul peut désigner tout type de processeur ou composant électronique apte à effectuer des calculs numériques. Par exemple, une unité de calcul peut être un circuit intégré, un ASIC (de l’acronyme anglais « Application-Specific Integrated Circuit », littéralement en français « circuit intégré propre à une application », un microcontrôleur, un microprocesseur, un DSP (de l’acronyme anglais « Digital Signal Processor », littéralement en français « processeur de signal numérique »), un processeur, un GPU (de l’acronyme anglais « Graphics Processing Unit », littéralement en français « unité de calcul graphique »). Une unité de calcul selon l’invention n’est pas limitée à un type particulier d’architecture de calcul. Par exemple, un processeur peut mettre en œuvre une architecture de type Harvard ou Von Neumann. Selon un autre aspect, il est proposé un programme informatique comportant des instructions pour la mise en œuvre de tout ou partie d’une méthode telle que définie dans les présentes lorsque ce programme est exécuté par un processeur. Selon un autre aspect, il est proposé un support d’enregistrement non transitoire, lisible par un ordinateur, sur lequel est enregistré un tel programme. Selon un autre aspect, il est proposé un dispositif informatique comprenant au moins une unité de calcul configurée pour exécuter tout ou partie d’une méthode telle que définie dans les présentes. Les caractéristiques exposées dans les paragraphes suivants peuvent, optionnellement, être mises en œuvre, indépendamment les unes des autres ou en combinaison les unes avec les autres : Avantageusement, la méthode est mise en œuvre par au moins une unité de calcul d’un hyperviseur dudit serveur apte à lire et écrire ladite structure. Ceci permet de renforcer la sécurité de la gestion des droits d’accès. Avantageusement, la méthode comprend une notarisation électronique de chaque requête relative à une ressource dudit ensemble par ladite au moins une unité de calcul de l’hyperviseur. On entend par "Notarisation électronique" une certification et un archivage électroniques de la date, de l'origine et de la destination d'une requête. Ceci permet de conserver et de certifier un historique des droits d’accès, et des requêtes d’accès aux ressources. Avantageusement, la méthode comprend une synchronisation, par ladite au moins une unité de calcul de l’hyperviseur, desdits droits d’accès avec au moins un hyperviseur distant exécuté par au moins une unité de calcul distante sur au moins un serveur distant. Ceci permet de synchroniser des droits d’accès entre plusieurs serveurs, et donc de conserver des droits d’accès à jour entre les différents serveurs pour un nombre de ressources aussi élevé que possible entre des serveurs recevant des requêtes différentes sur en ensemble de ressources partagées. Avantageusement, la méthode comprend une communication du serveur avec au moins un serveur central configuré pour maintenir une structure de droits d’accès de référence. On entend par "serveur central" un serveur centralisant un traitement pour le compte de plusieurs serveurs. Ceci permet de centraliser, pour le compte de plusieurs serveurs, la gestion de la synchronisation des droits des clients, et donc de faciliter la synchronisation de la gestion des droits d’accès entre les serveurs. Avantageusement, ladite méthode est mise en œuvre par au moins une unité de calcul d’une virtualisation au niveau du système d’exploitation exécutée par un hyperviseur, ladite virtualisation au niveau du système d’exploitation étant apte à lire et écrire ladite structure. On entend par "virtualisation au niveau du système d'exploitation" une instance utilisateur fournissant un système d'exploitation virtuel. Une virtualisation au niveau du système d'exploitation peut par exemple être nommé dans certains types de systèmes d'exploitation conteneur, serveur privé virtuel, partition, environnement virtuel ou noyau virtuel. Un conteneur contient les éléments nécessaires à la virtualisation. Ceci permet une grande flexibilité dans le déploiement des droits d’accès aux ressources, car la gestion des droits d’accès peut être implémentée au sein de systèmes d’exploitation virtuels exécutables par des hyperviseurs déjà déployés. Avantageusement, ladite au moins une ressource est un modèle d’apprentissage machine entraîné avec des données fournies par ledit premier client. Ceci permet de partager l’entraînement de modèles d’apprentissage machine tout en garantissant à chaque client fournissant des données d’apprentissage le contrôle sur les autres clients ayant accès au produit de l’entraînement. Avantageusement, la deuxième requête est une requête d’utilisation du modèle d’apprentissage machine sur des données fournies par le deuxième client ; la méthode comprend : l’envoi, par ledit serveur, d’un résultat de ladite utilisation du modèle d’apprentissage machine au deuxième client ; la réception, par ledit serveur, d’un retour dudit deuxième client sur ledit résultat ; le déclenchement, par ledit serveur : d’une phase d’amélioration dudit modèle à partir dudit retour, et d’une association audit modèle amélioré de droits d’accès accordés par ledit deuxième client. On entend par "déclenchent" l'entraînement d'une ou plusieurs actions. Le déclenchement d'actions par l'au moins une unité de calcul peut par exemple consister en l'exécution des actions par l'unité de calcul, ou l'envoi d'instructions à une unité de calcul distante d'effectuer les actions. Par exemple, l'unité de calcul distante peut être une unité de calcul d'un serveur central, et l'au moins une unité de calcul peut fournir le retour au serveur central pour réaliser l'amélioration du modèle sur le serveur central. On entend par "phase d'amélioration" une phase d'entraînement du modèle comprenant une amélioration de l'entraînement préalable du modèle. Par exemple, la phase d'amélioration peut être une phase d'apprentissage par renforcement et ledit résultat peut être une récompense accordée par le deuxième client. On entend par "retour" (en anglais "feedback") une indication fournie par le deuxième client de la qualité du résultat fourni. Par exemple, dans le cadre d'un apprentissage par renforcement, le retour peut être une récompense Ceci permet d’entraîner un modèle avec des données fournies par plusieurs clients, tout en s’assurant à tout moment que l’utilisation du modèle est subordonnée à la fourniture de droits d’accès par tous les clients ayant contribué à l’entraînement. Avantageusement, la méthode comprend : la réception, par ledit serveur, dudit modèle d’apprentissage machine depuis serveur central ; la fourniture, par ledit serveur, dudit ledit retour au serveur central afin de déclencher ladite phase d’amélioration Ceci permet de centraliser l’apprentissage du modèle auprès du serveur central. Avantageusement, l’ensemble de ressources comprend une pluralité de modèles fédérés d’un jumeau numérique d’un élément monde physique ; la méthode comprend : à la réception de la deuxième requête, l’exécution, par le serveur, d’une fédération de simulations dudit élément du monde physique pour tous les modèles fédérés de ladite pluralité pour lesquels le deuxième client dispose des droits d’accès ; à la réception d’un retour du deuxième client, le déclenchement, par le serveur, : d’une mise à jour desdits modèles fédérés ; et d’une association audit modèles fédérés mis à jour de droits d’accès accordés par ledit deuxième client. On entend par "modèles fédérés" un ensemble de modèles participant conjointement à la modélisation d'un élément du monde physique. Par exemple, les modèles fédérés peuvent correspondre à des modèles de différentes parties de l'élément. On entend par "jumeau numérique" une réplique numérique d'un élément du monde physique. Ceci permet de partager une fédération de modèles du monde physique entre plusieurs clients, et les retours permettant d’améliorer les modèles, tout en garantissant à chaque client fournissant des retours permettant d’améliorer les modes le contrôle sur les autres clients ayant accès modèles fédérés bénéficiant du retour. Avantageusement, la méthode comprend : la réception, par le serveur, desdits modèles fédérés depuis un serveur central ; la fourniture, par le serveur, dudit retour au serveur central afin de déclencher ladite mise à jour des modèles fédérés Ceci permet de centraliser la fédération des modèles auprès du serveur central. Avantageusement, ladite structure est une table indiquant, pour chaque paire de client, les droits d’accès accordés par le premier client de la paire au deuxième client de la paire, et du deuxième client de la paire au premier client de la paire, les autorisations appartenant à un groupe comprenant : un droit de création ; un droit de lecture ; un droit de mise à jour ; un droit de suppression. Ceci permet de définir de manière déterministe les droits d’accès donnés par les clients entre eux. D’autres caractéristiques, détails et avantages apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels : Fig. 1 montre un exemple de serveur selon un ensemble de modes de réalisation. Fig. 2 montre un exemple de modules mis en œuvre par un serveur selon un ensemble de modes de réalisation de l’invention, dans lequel la gestion de l’accès aux ressources est effectuée par un hyperviseur. Fig. 3 montre un exemple d’un réseau de serveurs dans lesquels la gestion de l’accès aux ressources est mis en œuvre par un hyperviseur selon un mode de réalisation. Fig. 4 montre un exemple de modules mis en œuvre par un serveur selon un ensemble de modes de réalisation de l’invention, dans lequel la gestion de l’accès aux ressources est effectuée par un conteneur. Fig. 5 montre un exemple de méthode de gestion d’au moins une ressource d’un ensemble de ressource selon un ensemble de modes mode de réalisation de l’invention. Fig. 6 montre un exemple de partage de ressources relatives à un modèle d’apprentissage machine selon un ensemble de modes de réalisation de l’invention. Fig. 7 montre un exemple de partage de ressources relatives à des modèles fédérés d’un jumeau numérique selon un ensemble de modes de réalisation de l’invention. Fig. 8 montre un exemple de structure définissant des droits d’accès selon un ensemble de modes de réalisation. Il est maintenant fait référence à la . La représente un serveur selon un ensemble de modes de réalisation de l’invention. Le serveur Serv1 est un serveur de gestion d’au moins une ressource d’un ensemble de ressources fournies par une pluralité de clients. Le serveur Serv1 est ainsi apte à gérer l’ensemble de ressources, c’est-à-dire créer, modifier, ou encore donner accès aux ressources de l’ensemble. Le serveur Serv1 permet donc à une pluralité de clients d’échanger des ressources. La représente deux clients Clt1 et Clt2. Les clients peuvent être de différents types. Un client peut par exemple être un terminal utilisateur, un utilisateur d'un terminal, une entreprise ou une application. Le serveur Serv1 peut comprendre un ou plusieurs liens de communication pour communiquer avec les clients. Un lien de communication avec un client peut comprendre tout moyen de communication. La communication avec les clients peut par exemple s’effectuer par le biais d’un réseau internet ou un réseau mobile. Le lien de communication avec les clients permet ainsi au serveur de recevoir des requêtes des clients. Les requêtes peuvent par exemple consister en des requêtes d’ajout de ressources, de modification de droits d’accès aux ressources, ou encore de demande d’accès à une ressource. Le serveur Serv1 peut également comprendre des moyens d’authentification des clients, afin de sécuriser les échanges de données entre clients. La représente deux clients distincts Clt1 et Clt2. Ce nombre est bien sûr fourni à titre d’exemple non limitatif uniquement, et l’invention est applicable à tout nombre de client supérieur ou égal à 2. Le serveur Serv1 comprend également un accès à un ensemble de ressources fournies par la pluralité de clients. Comme indiqué ci-dessus, les ressources peuvent comprendre tout type de ressource informatique, par exemple des ressources matérielles, logicielles ou du contenu pouvant être échangées entre les clients. Les ressources peuvent par exemple être stockées dans au moins une mémoire Mem à laquelle le serveur Serv1 a accès. L’au moins une mémoire Mem peut appartenir à différents types de stockage de données apte à stocker les ressources. Il peut par exemple s’agir d’une mémoire vive, d’une mémoire morte, d’une mémoire volatile, d’une mémoire flash ou encore d’une mémoire virtuelle. L’au moins une mémoire comprendre au moins une mémoire interne et/ou au moins une mémoire externe au serveur Serv1. Une mémoire externe peut être par exemple une mémoire contenue dans un dispositif relié au serveur Serv1 par une connexion filaire, ou une mémoire située dans un serveur situé sur le même réseau que le serveur Serv1, par exemple un serveur central. Ainsi, l’accès à l’au moins une mémoire peut se faire par le biais d’une connexion interne au serveur Serv1, ou d’une connexion externe sécurisée vers le dispositif comprenant la mémoire. La représente deux ressources Res1, Res2. Ce nombre est bien sûr fourni à titre d’exemple non limitatif uniquement, et l’invention est applicable à ensemble de ressources comprenant au moins une ressource. Les ressources peuvent également être dupliquées sur plusieurs mémoires, afin de garantir leur accès en cas de défaillance de l’une des mémoires. Elles peuvent être stockées directement dans les mémoires, mais également encryptées, stockées en bases de données, etc. Le serveur Serv1 comprend également un accès à une structure Struct1 définissant des droits d’accès pour l’ensemble de ressources. La structure Struct1 peut par exemple être stockée sur l’au moins une mémoire Mem. Dans l’exemple de la , les ressources Res1 et Res2 sont situées dans la même mémoire que la structure Struct1. Cet exemple est fourni à titre d’exemple non limitatif uniquement, et les ressources et structures peuvent être stockées sur des mémoires différentes. La structure Struct1 peut par ailleurs être dupliquée sur plusieurs mémoires pour garantir son accès en cas de défaillance d’une des mémoires, et/ou être stockée par parties sur plusieurs mémoires. Le serveur Serv1 comprend au moins une unité de calcul Calc. L’unité de calcul est configurée pour recevoir des requêtes de clients, et fournir ou non l’accès aux ressources, par exemple en mettant en œuvre la méthode P5 représentée en , ou en participant à la mise en œuvre des scénarios représentés en et 7. La gestion de l’accès aux ressources par les clients Clt1, Clt2 peut être mise en œuvre au niveau de l’hyperviseur (représenté à la ) ou au niveau d’un conteneur ou d’une machine virtuelle (représenté à la ). Il est maintenant fait référence à la . La montre un exemple de modules mis en œuvre par un serveur selon un ensemble de modes de réalisation de l’invention, dans lequel la gestion de l’accès aux ressources est mis en œuvre par un hyperviseur. Le serveur Serv2 représenté en peut par exemple être le serveur Serv1 représenté en . Le serveur Serv2 met en œuvre plusieurs modules. Dans l’exemple de la , le serveur comprend un système d’exploitation OS2 apte à mettre en œuvre un hyperviseur Hypvsr2 apte à lire et écrire une structure Struct2 définissant les droits d’accès à l’ensemble de ressources. Dans cet exemple, la gestion de l’accès aux ressources s’effectue donc au niveau de l’hyperviseur Hypvsr2 qui est configuré pour lire et écrire la structure Struct2 et déterminer les droits d’accès. L’hyperviseur Hypvsr2 est également apte à contrôler et gérer un ou plusieurs conteneurs Cont12, Cont22, … Contn2 ou une ou plusieurs machines virtuelles. On notera qu’une machine virtuelle est une virtualisation de ressources matérielles et logicielles dont un système d’exploitation, permettant d’exécuter une requête d’un client en s’exécutant sur l’hyperviseur. Un conteneur est une virtualisation des ressources matérielles et logicielles sans instanciation du système d’exploitation. En effet, un conteneur partage un même système d’exploitation avec d’autres conteneurs. Cette architecture permet de renforcer la sécurité des droits d’accès. En effet, si l’hyperviseur peut contrôler et gérer les conteneurs Cont12, Cont22, … Contn2 exécutant du code tiers, la gestion des droits d’accès s’effectue au niveau de l’hyperviseur lui-même, et peut donc être totalement contrôlée. Dans cet exemple, l’hyperviseur peut non seulement gérer l’accès aux ressources, mais également effectuer une notarisation électronique de chaque requête relative à une ressource. Ainsi, la notarisation permet d’archiver la date, de l'origine et de la destination de chaque requête relative à une ressource, par exemple les requêtes de création de ressource, de modification de droits d’accès, d’édition d’une ressource, d’accès à une ressource, etc. Ceci permet notamment d’identifier a posteriori toute requête d’accès à une ressource. Ceci permet de garder trace de toute tentative d’accès ou de modification, autorisée ou non, aux ressources, mais également de quantifier l’accès aux ressources. En effet, le partage de ressources par les clients peut s’effectuer dans le cadre de contrats commerciaux d’échanges de ressources entre les clients. La notarisation des requêtes permet ainsi le cas échéant de quantifier l’accès aux ressources par chaque client, qui peut être un objet du contrat. L’accès à une ressource peut également être fourni par un premier client à un deuxième pour un nombre défini d’accès. Ce nombre défini peut être un nombre d’accès total, ou un nombre d’accès par unité de temps (par jour, par semaine, par mois, etc.). La notarisation des requêtes permet alors de vérifier si le nombre limite d’accès à une ressource est dépassé ou non, et de fournir ou non l’accès à la ressource en conséquence. Il est maintenant fait référence à la . La montre un exemple d’un réseau de serveurs dans lesquels la gestion de l’accès aux ressources est mis en œuvre par un hyperviseur selon un mode de réalisation. Dans l’exemple de la , un réseau Res3 de serveurs comprend trois serveurs Serv13, Serv23 et Serv33. Chacun des trois serveurs Serv13, Serv23 et Serv33 est semblable au serveur Serv2, ayant accès à des ressources partagées et comprenant un hyperviseur apte à effectuer la gestion des droits d’accès aux ressources et exécuter des conteneurs. Par exemple, les serveurs les serveurs Serv13, Serv23 et Serv33 sont respectivement aptes à exécuter les hyperviseurs Hypvsr13, Hpyvsr23 et Hypvsr33. Par analogie avec le serveur Serv2, le serveur Serv13 comprend un système d’exploitation OS3, l’hyperviseur Hypvsr13 apte à lire et écrire la structure Struct13 définissant des droits d’accès pour un ensemble de ressources, et à exécuter les conteneurs Cont113, Cont213 et Contn13. De même, les hyperviseurs Hypvsr23 et Hypvsr33 sont respectivement aptes à lire et écrire les structures Struct23 et Struct33 définissant des droits d’accès pour même ensemble de ressources. Les serveurs Serv13, Serv23 et Serv33 sont des serveurs distants les uns des autres, c’est-à-dire qu’ils sont situés dans des emplacements physiques différents. Les serveurs Serv13, Serv23 et Serv33 sont en communication par un réseau, par exemple un réseau internent Intnt. Les serveurs Serv13, Serv23 et Serv33 sont configurés pour fournir l’accès à un même ensemble de ressources, mais peuvent être en communication avec des clients différents. Les ressources peuvent ainsi être partagées sur des zones mémoires accessibles aux trois serveurs et/ou dupliquées sur des zones mémoires accessibles à chacun des serveurs. Cependant, les hyperviseurs Hypvsr13, Hypvsr23 et Hypvsr33 sont configurés pour synchroniser les droits d’accès à l’ensemble de ressources, tels que définis dans les structures respectives Struct13, Struct23 et Struct33. Ainsi, les droits d’accès peuvent être partagés et mis à jour entre les clients de plusieurs serveurs, ce qui permet d’augmenter le nombre de clients et de ressources pouvant participer au partage de ressources, puisque les clients de plusieurs serveurs, et les ressources fournies par ces clients, peuvent intervenir dans le partage. De plus, cela permet de mettre en œuvre des techniques de « edge computing », dans lesquelles des serveurs sont placés au plus près des clients tout en ayant accès à des ressources partagées de manière plus large, et en garantissant le respect des règles d’accès définies par chaque client entre les serveurs. La représente un exemple dans lequel un réseau de serveurs comprend trois serveurs. Cet exemple est cependant fourni à titre d’exemple non limitatif uniquement, et l’invention est applicable à tout nombre de serveur en réseau supérieur ou égal à deux. La synchronisation des droits d’accès entre les serveurs peut s’effectuer de différentes manières. Par exemple, des algorithmes de synchronisation distribués peuvent être mis en œuvre. Par exemple, les serveurs peuvent maintenir la synchronisation des droits d’accès via une blockchain. Il est également possible de centraliser la gestion de la synchronisation. Par exemple, tous les serveurs peuvent communiquer avec un serveur central configuré pour maintenir une structure de droits d’accès de référence. Le serveur central peut être l’un des serveurs, ou un autre serveur dédié à la maintenance de la structure de référence. Il est maintenant fait référence à la . La montre un exemple de modules mis en œuvre par un serveur selon un ensemble de modes de réalisation de l’invention, dans lequel la gestion de l’accès aux ressources est effectuée par un conteneur. Le serveur Serv4 représenté en peut par exemple être le serveur Serv1 représenté en . Le serveur Serv4 met en œuvre plusieurs modules. Dans l’exemple de la , le serveur comprend un système d’exploitation OS4 apte à mettre en œuvre un hyperviseur Hypvsr4. L’hyperviseur Hypvsr4 est apte à exécuter un ou plusieurs conteneurs Cont14, Cont24, … Contn4. Dans cet exemple, l’un des conteneurs, le conteneur Contn4, est apte à lire et écrire une structure Struct4 définissant les droits d’accès à l’ensemble de ressources. Dans cet exemple, la gestion de l’accès aux ressources s’effectue donc au niveau du conteneur Contn4 qui est configuré pour lire et écrire la structure Struct4 et déterminer les droits d’accès. Cet exemple est fourni à titre d’exemple on limitatif, et le même principe peut être appliqué à d’autres types de virtualisations au niveau du système d’exploitation, tels que des machines virtuelles. La gestion des droits d’accès aux ressources peut donc s’effectuer au sein de conteneurs, ou d’autres virtualisations au niveau du système d’exploitation, exécutés par des hyperviseurs déjà déployés, ce qui permet une grande flexibilité dans le déploiement des droits d’accès aux ressources. Par exemple, la gestion des droits d’accès peut être mise à jour par la modification d’un conteneur, sans avoir à modifier l’hyperviseur. IL est maintenant fait référence à la . La montre un exemple de méthode P5 de gestion d’au moins une ressource d’un ensemble de ressource selon un ensemble de modes mode de réalisation de l’invention. La méthode P5 peut par exemple être mise en œuvre par l’un des serveurs Serv1, Serv2, Serv13, Serv4 pour gérer au moins une ressource telle que les ressources Res1 et Res2. La méthode P5 comprend une première étape S51 de définition par l’au moins un serveur, dans une structure définissant des droits d’accès pour un ensemble de ressources fournies par une pluralité de clients, et à la réception d’une première requête d’un premier client de ladite pluralité de clients, des droits d’accès d’au moins une ressource fournie par ledit premier client. En pratique, l’étape S51 peut par exemple s’effectuer : à la réception d’une requête d’ajout de la ressource, accompagnée de droits d’accès à la ressource ; à la réception d’une requête de modification des droits d’accès d’une ressource déjà existante fournie par le premier client. Les droits d’accès peuvent être de différents types. Par exemple, les droits peuvent par exemple être des droits de type « CRUD » (de l’anglais Create, Read, Update, Delete », en français « Création, Lecture, Mise à jour, Suppression »). Les droits peuvent être fournis par exemple à des clients ou groupes de clients spécifiques. Les droits peuvent également être assorties de conditions spatiales, temporelles, de nombre d’utilisations, etc. Les droits d’accès peuvent être fournis aux autres clients, mais également aux serveurs eux-mêmes. La méthode P3 comprend ensuite une deuxième étape S52 de réception, par l’au moins un serveur, d’une requête d’un deuxième client de ladite pluralité de clients, demandant l’accès à au moins une ressource fournie par le premier client. Une requête d’accès à la ressource peut être de différents types, selon le type de ressource concernée. Par exemple, la requête d’accès à la ressource peut être une requête de lecture ou de modification d’un fichier, une requête d’accès à des bases de données d’entraînement d’un modèle d’apprentissage machine, une requête d’utilisation d’un modèle fédéré d’un jumeau numérique, etc. La méthode P3 comprend ensuite, à la réception de la requête d’accès, une troisième étape S53 de vérification par l’au moins un serveur de si les droits d’accès permettent l’accès à l’au moins une ressource par le deuxième client. Si les droits d’accès le permettent, l’au moins un serveur fournit à la quatrième étape S54 l’accès à l’au moins une ressource audit deuxième client. Sinon, l’au moins un serveur rejette la requête d’accès à l’étape S55. Ainsi, les droits d’accès définis par le premier client sont pris en compte pour la fourniture ou non de l’accès aux ressources. Selon différents modes de réalisation de l’invention, les étapes de la méthode P5 peuvent être mises en œuvre par un serveur unique, ou une pluralité de serveurs, par exemple un réseau de serveurs tels que représenté en . Si la méthode est mise en œuvre par une pluralité de serveurs, les différentes étapes peuvent être réalisées par plusieurs serveurs distincts. Par exemple, l’étape S51 peut être réalisée par un premier serveur qui reçoit une ressource d’un premier client, et les étapes S52 à S54 par un deuxième serveur qui reçoit une requête d’accès à la ressource d’un deuxième client. Il est maintenant fait référence à la . La montre un exemple de partage de ressources relatives à un modèle d’apprentissage machine selon un ensemble de modes de réalisation de l’invention. L’exemple de la représente l’accès une ressource, qui est un modèle d’apprentissage machine Mod16 entraîné avec des données fournies par le premier client Clt1. Le modèle entraîné est dans cet exemple stocké sur le serveur Serv6, en relation avec un serveur ServCtr6, qui centralise des modèles d’apprentissage machine partagés entre plusieurs serveurs. Dans cet exemple, le modèle Mod16 est un modèle permettant de détecter des personnes dans une image, et de compter le nombre de personnes dans une image. Cet exemple est fourni à titre d’exemple non limitatif, et l’exemple de la peut être étendu à d’autres types de modèles d’apprentissage machine. La décrit un scénario P6 d’utilisation du modèle Mod16 par un deuxième client. Dans ce scénario, les droits d’accès du modèle Mod16 définis par le premier client Clt1 permettent au deuxième client Clt2 d’utiliser et de mettre à jour le modèle Mod16. Dans le scénario P6, le deuxième client Clt2 envoie au serveur Serv6 une requête Rq6 d’utilisation du modèle Mod16 sur la base d’une image qu’il fournit. Comme les droits d’accès définis par le premier client le permettent, le serveur Serv6 utilise UtMod16 le modèle Mod16 sur l’image fourni par le deuxième client pour compter le nombre de personnes dans l’image, puis renvoie le résultat Res6 au deuxième client Clt2. Le deuxième client Clt2 fournit alors un retour Ret6 au serveur sur ledit résultat. Le retour peut par exemple consister en une validation du nombre de personne, ou au contraire une indication que le nombre de personnes comptées est inexact, d’un nombre de personne exact, ou d’une localisation précise des personnes effectivement présentes sur la photo. Comme les droits fournis par le premier client Clt1 permettent la mise à jour du modèle Mod26 par le deuxième client, le retour Ret6 déclenche une phase d’amélioration du modèle par le serveur à partir du retour, pour obtenir un modèle amélioré Mod26. La phase d’amélioration peut en pratique être réalisée par le server Serv6 lui-même, ou un serveur distant, tel que par exemple le serveur central ServCtr6. Le serveur central ServCtr6 peut ainsi centraliser l’apprentissage des modèles. Par exemple, le serveur Serv6 peut recevoir le modèle Mod16 du serveur central ServCtr6, renvoyer le retour Ret6 au serveur central ServCtr6, et recevoir du serveur central le modèle amélioré Mod26. Le serveur central peut aussi centraliser les modèles, sans faire l’apprentissage lui-même. Par exemple, le serveur central ServCtr6 peut stocker le modèle Mod16, l’envoyer dans une étape TransMod16 au serveur Serv6 avant utilisation sur le serveur Serv6, le serveur Serv6 peut faire la mise à jour puis renvoyer le modèle mis à jour Mod26 au serveur central ServCtr6 dans une étape TransMod26. Comme le modèle amélioré Mod26 est entraîné en partie avec des données fournies par le deuxième client, le retour Ret6 et l’amélioration du modèle entraînent également une association au modèle amélioré Mod26 de droits d’accès accordés par ledit deuxième client. Dit autrement, le modèle amélioré Mod26 ne pourra être utilisé par un troisième client que si les droits d’accès fournis à la fois par le premier client et le deuxième client le permettent. Si seuls les droits d’accès fournis par le premier client permettent l’accès au modèle par le troisième client, alors celui-ci pourrait utiliser le modèle Mod16, mais pas le modèle amélioré Mod26 par exemple. Ce principe peut de manière plus générale être appliqué à tout modèle entraîné à partir des données fournies par plusieurs clients. Ainsi, dans un mode de réalisation, si une ressource est un modèle entraîné avec les données fournies par une pluralité de clients initiaux, l’accès au modèle ne pourra être fourni à un client final, faisant partie ou non de la pluralité de clients initiaux, que si les droits d’accès fournis par chacun des clients initiaux de ladite pluralité le permettent. Ceci permet à des clients de participer de manière collaborative à la création de modèles d’apprentissage communs, tout en permettant à chaque client de s’assurer des conditions d’accès aux modèles entraînées avec les données qu’il fournit. Il est maintenant fait référence à la . La montre un exemple de partage de ressources relatives à des modèles fédérés d’un jumeau numérique selon un ensemble de modes de réalisation de l’invention. L’exemple de la représente l’accès à un ensemble de ressources, qui est une pluralité de modèles fédérés ModFed17 d’un jumeau numérique d’un élément du monde physique Elt7. Dans l’exemple de la : L’élément du monde physique Elt7 est une usine ; Les modèles fédérés ModFed17 sont stockés sur un serveur central ServCtr7, et comprennent un modèle Mod7 d’un sous-élément de l’usine fourni par le client Clt7. Dans cet exemple, une pluralité clients participent à la fédération de modèles en fournissant des modèles de sous-éléments de l’élément Elt7. Les clients de la pluralité se sont mutuellement fourni les droits d’exécution et de mise à jour des modèles fédérés, de sorte que chaque client peut effectuer une simulation de la fédération de modèle, et mettre à jour les modèles si la simulation ne correspond pas aux observations issues du monde physique. Les clients peuvent ici correspondre à différentes entités participant à la gestion de l’usine. Par exemple, le client Clt7 peut être un opérateur de l’usine, et les autres clients fournissant des modèles fédérés des fournisseurs de divers équipements de l’usine, et/ou des opérateurs d’usines identiques. La représente plus spécifiquement un scénario P7, dans lequel un incident est survenu dans l’usine. L’usine est équipée de capteurs permettant de suivre le fonctionnement de l’usine, et envoie Sens17 des mesures prises par les capteurs pendant l’incident, complétées au besoin par des mesures prises avant l’incident au client Clt7. Le client Clt7 envoie au serveur Serv7 une requête ReqSim7 de simulation de la fédération de modèles sur la base des mesures capteurs. Comme les droits d’exécution de l’ensemble de la fédération de modèle ont été accordés au client Clt7, le serveur Serv7 effectue une simulation Sim7 des modèles fédérés comprenant une évaluation de scénarios et la détermination d’un jeu de commandes pour mettre un terme à l’incident. Le serveur Serv7 renvoie au client Cl7 un retour de la simulation accompagné du jeu de commandes. Le client Clt7 envoie ensuite le jeu de commandes Clt7 à l’usine Elt7, qui va procéder à l’exécution Exec7 des commandes. Une fois les commandes exécutées par l’usine, l’usine Elt7 renvoie un nouveau jeu d’observations de capteurs Sens27 au client Clt7, qui renvoie à son tour un retour RetSim27 de simulation au serveur Serv7 comprenant le nouveau jeu d’observations Sens27. Le nouveau jeu d’observations Sens27 peut être différent des prédictions des modèles fédérés. Afin de mettre à jour les modèles, le serveur Serv7 déclenche Upd7 une mise à jour des modèles fédérés sur la base du nouveau jeu d’observations. Dans l’exemple de la , le nouveau jeu d’observation est transmis au serveur central ServCtr7, qui va procéder à la mise à jour. Dans d’autres modes de réalisation de l’invention, c’est le serveur Serv7 qui est en charge de la mise à jour. Dans l’exemple de la , la mise à jour des modèles fédérés est faite à partir de données fournies par le client Clt7. La mise à jour des modèles fédérés s’accompagne donc d’une association aux modèles fédérés mis à jour ModFed27 de droits d’accès accordés par le client Clt7. Cet exemple démontre la capacité de l’invention de permettre l’utilisation de modèles fédérés de jumeaux numériques d’éléments du monde physique, tout en permettant à chaque client de gérer les droits d’accès aux modèles entraînés avec les données qu’il fournit. Cet exemple est cependant fourni à titre d’exemple uniquement d’un scénario d’application de l’invention à des modèles fédérés. L’invention est de manière plus générale applicable à tout scénario basé sur des modèles fédérés, dans lequel chaque client peut définir les droits d’accès aux modèles qu’il fournit ou contribue à entraîner, et dans lequel un client ne peut accéder à une fédération de modèles que si tous les clients qui ont contribué à fournir ou entraîner les modèles lui en donnent la permission. Il est maintenant fait référence à la . La montre un exemple de structure définissant des droits d’accès selon un ensemble de modes de réalisation. La structure Tab8 se présente sous la forme d’un tableau à deux dimensions définissant les droits d’accès fournis par chacun des clients. Dans cet exemple, les clients sont des applications, représentées par les lettres « App 1 », « App 2 », « App n ». Par mesures de lisibilité, seuls trois clients sont représentés dans cet exemple, mais une structure de ce type est bien entendu applicable à un nombre de client plus élevé. Les lettres « PCE » représentent quant à elle le serveur lui-même, qui peut également recevoir ou fournir des droits d’accès. Dans le tableau Tab8 : chaque ligne représente l’entité qui fournit des droits d’accès ; chaque colonne représente l’entité qui reçoit les droits d’accès. Dans cet exemple, les droits accordés peuvent être de 4 types, selon la dénomination « CRUD » : « C » (de l’anglais « Create ») : un droit de création ; « R » (de l’anglais « Read ») : un droit de lecture ; « U » (de l’anglais « Update ») : un droit de mise à jour ; « D » (de l’anglais « Delete ») : un droit de suppression. Chaque case comprend les lettres correspondant aux droits parmi les 4 droits possibles accordés par l’entité caractérisant la ligne de la case à l’entité caractérisant la colonne de la case. Par exemple : la cellule Cel18, située sur la 3 e ligne « App 2 » et sur la première colonne « PCE », représente les droits accordés par l’ « App 2 » au serveur. Ici, les 4 droits C, R, U et D sont fournis ; la cellule Cel28, située sur la 1 e ligne « PCE » et la 3 e colonne « App 2 », représente les droits accordés par le serveur à l’ « App 2 ». Ici, seul le droit de lecture R est fourni. On peut ici remarquer que : Toutes les colonnes dans la diagonale de la table comprennent les 4 droits C,R,U,D. En effet, les cellules dans la diagonale définissent les droits donnés par une entité à elle-même ; Les droits ne sont pas nécessairement accordés de manière symétrique. Par exemple, les cellules Cel18 et Cel28 montrent que « App2 » accorde plus de droits au serveur que le serveur n’en accorde à « App2 ». La table Tab8 fournit un exemple illustratif et non limitatif d’une structure définissant des droits d’accès selon l’invention. Selon d’autres modes de réalisation de l’invention, d’autres types de structures peuvent être mises en œuvre. De même, les droits d’accès peuvent utiliser un formalisme différent et/ou comprendre un plus grand nombre de types de droits d’accès. Les droits d’accès peuvent également être associés à des caractéristiques additionnelles telles que des zones géographiques, des périodes de temps, un nombre limite d’accès, etc. La présente divulgation ne se limite pas aux exemples de méthode, serveur, dispositif informatique et programme informatique décrits ci-avant, seulement à titre d’exemple, mais elle englobe toutes les variantes que pourra envisager l’homme de l’art dans le cadre de la protection recherchée. Méthode (P5) de gestion d’au moins une ressource d’un ensemble de ressources (Res1, Res2) fournies par une pluralité de clients (Clt1, Clt2), ladite méthode étant mise en œuvre par au moins un serveur (Serv1 ; Serv2 ; Serv13 ; Serv4) et comprenant : la définition (S51), par l’au moins un serveur (Serv1 ; Serv2 ; Serv13 ; Serv4), dans une structure (Struct1) définissant des droits d’accès pour un ensemble de ressources (Res1, Res2) fournies par une pluralité de clients (Clt1, Clt2), et à la réception d’une première requête d’un premier client de ladite pluralité de clients, des droits d’accès d’au moins une ressource fournie par ledit premier client ; la réception (S52), par l’au moins un serveur, d’une deuxième requête d’un deuxième client de ladite pluralité de clients, demandant l’accès à l’au moins une ressource fournie par le premier client ; la fourniture (S54), par l’au moins un serveur, de l’accès à l’au moins une ressource audit deuxième client si les droits d’accès le permettent (S53). Méthode selon la revendication 1, ladite méthode étant mise en œuvre par au moins une unité de calcul d’un hyperviseur (Hypvsr2 ; Hypvsr13) dudit serveur apte à lire et écrire ladite structure. Méthode selon la revendication 2, comprenant une notarisation électronique de chaque requête relative à une ressource dudit ensemble par ladite au moins une unité de calcul de l’hyperviseur. Méthode selon l’une des revendications 2 et 3, comprenant une synchronisation, par ladite au moins une unité de calcul de l’hyperviseur, desdits droits d’accès avec au moins un hyperviseur distant (Hypvsr23 ; Hypvser33) exécuté par au moins une unité de calcul distante sur au moins un serveur distant (Serv23 ; Serv23). Méthode selon l’une des revendications précédentes, comprenant une communication du serveur avec au moins un serveur central configuré pour maintenir une structure de droits d’accès de référence. Méthode (Serv4) selon la revendication 1, ladite méthode étant mise en œuvre par au moins une unité de calcul d’une virtualisation au niveau du système d’exploitation exécutée par un hyperviseur (Hypvsr4), ladite virtualisation au niveau du système d’exploitation étant apte à lire et écrire ladite structure. Méthode selon l’une quelconque des revendications précédentes, dans lequel ladite au moins une ressource est un modèle d’apprentissage machine entraîné avec des données fournies par ledit premier client. Méthode selon la revendication précédente, dans laquelle : la deuxième requête (Rq6) est une requête d’utilisation du modèle d’apprentissage machine (Mod16) sur des données fournies par le deuxième client ; la méthode comprend : l’envoi, par ledit serveur, d’un résultat (Res6) de ladite utilisation (UtMod6) du modèle d’apprentissage machine au deuxième client ; la réception, par ledit serveur, d’un retour (Ret6) dudit deuxième client sur ledit résultat ; le déclenchement, par ledit serveur : d’une phase d’amélioration dudit modèle à partir dudit retour, et d’une association audit modèle amélioré (Mod26) de droits d’accès accordés par ledit deuxième client. Méthode selon la revendication précédente, comprenant : la réception, par ledit serveur, dudit modèle d’apprentissage machine depuis serveur central (ServCtr6); la fourniture, par ledit serveur, dudit ledit retour au serveur central afin de déclencher ladite phase d’amélioration. Méthode selon l’une quelconque des revendications 1 à 6, dans lequel : l’ensemble de ressources comprend une pluralité de modèles fédérés (ModFed17) d’un jumeau numérique d’un élément (Elt7) monde physique ; la méthode comprend : à la réception de la deuxième requête (ReqSim7), l’exécution, par le serveur, d’une fédération de simulations (Sim7) dudit élément du monde physique pour tous les modèles fédérés de ladite pluralité pour lesquels le deuxième client dispose des droits d’accès ; à la réception d’un retour (RetSim27) du deuxième client, le déclenchement, par le serveur, : d’une mise à jour desdits modèles fédérés ; et d’une association audit modèles fédérés mis à jour (ModFed27) de droits d’accès accordés par ledit deuxième client. Méthode selon la revendication précédente, comprenant : la réception, par le serveur, desdits modèles fédérés depuis un serveur central (ServCtr7) ; la fourniture, par le serveur, dudit retour au serveur central afin de déclencher ladite mise à jour des modèles fédérés. Méthode selon l’une quelconque des revendications précédentes, dans lequel ladite structure est une table (Tab8) indiquant, pour chaque paire de client, les droits d’accès accordés par le premier client de la paire au deuxième client de la paire, et du deuxième client de la paire au premier client de la paire, les autorisations appartenant à un groupe comprenant : un droit de création ; un droit de lecture ; un droit de mise à jour ; un droit de suppression. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon la revendication 13 lorsque ce programme est exécuté par un processeur. Dispositif informatique comprenant au moins une unité de calcul configurée pour exécuter une méthode selon l’une des revendications 1 à 12. Serveur (Serv1 ; Serv2 ; Serv13 ; Serv4) de gestion d’au moins une ressource d’un ensemble de ressources (Res1, Res2) fournies par une pluralité de clients (Clt1, Clt2) comprenant : un accès à un ensemble de ressources (Res1, Res2) fournies par une pluralité de clients (Clt1, Clt2) ; un accès à une structure (Struct1) définissant des droits d’accès pour l’ensemble de ressources; au moins une unité de calcul (Calc) configurée pour : définir dans ladite structure, à la réception d’une première requête d’un premier client de ladite pluralité de clients, les droits d’accès d’au moins une ressource fournie par ledit premier client; recevoir une requête d’un deuxième client de ladite pluralité de clients, demandant l’accès à au moins une ressource fournie par le premier client ; fournir l’accès à ladite au moins une ressource audit deuxième client si les droits d’accès le permettent. .