FR 3110452 A1 20211126 FR 2005231 A 20200520 La présente divulgation concerne un système de virtualisation pour plateau de jeu (GB), comprenant un premier module (M1) et un deuxième module (M2) connectés entre eux au moyen d’un réseau local (NET), le premier module étant adapté pour - capturer (110) une image d’un espace physique (JS) correspondant au plateau de jeu et comprenant au moins un élément physique (P1) ; - analyser (120) l’image capturée pour déduire un état physique de l’élément physique ; - transmettre (130), au deuxième module, via le réseau local, l’état physique déduit, le deuxième module étant adapté pour : - générer (220), sur réception (210) de l’état physique, une représentation virtuelle (JV) de l’espace physique, l’espace virtuel comprenant un élément virtuel respectif (P1’) de l’élément physique ; et - attribuer (230), à l’élément virtuel, un état virtuel représentatif de l’état physique de l’élément physique respectif. Figure de l’abrégé : Figure 4 Système de virtualisation pour plateau de jeu Arrière-plan de l’invention L’invention relève du domaine des systèmes de virtualisation pour plateau de jeu. En particulier, l’invention relève du domaine de la dématérialisation de supports physiques utilisés sur, ou en combinaison avec, un plateau de jeu. Dans un jeu de société standard de type jeu de plateau, des utilisateurs déplacent des éléments matériels tels que des pions, par exemple des jetons ou des figurines réalisés en plastique, et les font évoluer sur une aire de jeu figurée par un plateau et selon différentes règles prédéterminées. Un tel jeu de société standard peut aussi faire intervenir d’autres éléments matériels utiles à l’expérience de jeu, par exemple des cartes, des dés, des tables de score, etc. En particulier, un utilisateur qui participe à un jeu de plateau peut déplacer un pion suivant des positions prédéfinies sur le plateau de jeu, ou manipuler une carte ou un dé de façon à déclencher une action contextuelle. Plusieurs autres utilisateurs peuvent aussi déplacer, à tour de rôle, des pions jouables ou non jouables d'un certain nombre de positions sur le plateau de jeu, l’ensemble de ces déplacements étant régi par différentes règles prédéfinies, par exemple à la demande d’un maître de jeu. Ces règles peuvent aussi définir les actions contextuelles déclenchées par l’un des utilisateurs du jeu, de manière volontaire ou automatique, par exemple lorsqu’un pion se trouve sur une case identifiée et spécifique du plateau de jeu, ou lorsque plusieurs pions se rencontrent sur une même case. Il incombe alors aux utilisateurs de connaître les règles qui correspondent aux actions déclenchées, et à les appliquer. Dans ce cadre, il est connu des systèmes permettant de remplacer certaines fonctionnalités de jeux de plateau au moyen l’utilisation de la réalité virtuelle. Ces systèmes permettent ainsi de fournir une expérience de jeu améliorée, de par l’emploi de dispositifs électroniques tels qu’une interface graphique, des tables virtuelles, des hologrammes ou encore des casques de réalité virtuelle. Par exemple, un casque de réalité virtuelle permet, à un utilisateur qui le porte, de visualiser des animations personnalisées du plateau de jeu ou d’éléments disposés sur celui-ci, par exemple au moyen d’une superposition d’éléments virtuels sur un écran d’affichage. Par exemple, un affichage automatique de scores ou d’indicateurs peut ainsi être fourni, de même qu’un partage de messages informatifs, d’animations vidéo ou encore d’illustrations d’actions contextuelles qui ont été déclenchées par un utilisateur. Cependant, et bien que ces systèmes améliorent considérablement le caractère immersif d’un jeu de société donné, de tels systèmes nécessitent l’emploi combiné de plusieurs dispositif électroniques, par exemple un casque de réalité virtuelle personnel et de supports physiques et logiciels spécifiques au jeu auquel les utilisateurs participent. Or, les dispositifs électroniques de réalité virtuelle sont souvent onéreux et peu propices à une utilisation familiale ou avec un grand nombre d’utilisateurs. En outre, chaque utilisateur donné est tenu de posséder les supports physiques nécessaires au jeu, et donc d’acquérir préalablement l’ensemble des pions, cartes et éléments matériels utiles à la mise en place du jeu et à son bon fonctionnement. En outre, ces systèmes impliquent une réduction du nombre d’éléments physiques partagés entre les utilisateurs, ce qui réduit la convivialité définissant l’esprit d’un jeu de société. La nécessité de disposer de tous ces éléments matériels spécifiques au jeu, en ce compris le plateau du jeu lui-même, réduit donc l’ergonomie fournie par ces systèmes. En outre, ceci diminue aussi l’accessibilité des utilisateurs à de tels systèmes, en particulier lorsque ceux-ci sont éloignés les uns des autres dans le cadre d’une partie de jeu mise en œuvre à distance. Un autre inconvénient de ces systèmes est qu’ils sont souvent sujets à des erreurs de détection et de numérisation, par exemple lorsque le dispositif électronique d’un utilisateur est mal positionné par rapport au plateau de jeu. Encore un autre inconvénient est que ces systèmes sont souvent encombrants et nécessitent une consommation électrique importante, ce qui réduit l’intérêt d’une combinaison de ces systèmes avec des jeux de plateau qui se veulent ergonomiques, efficaces énergétiquement, et écologiques. Objet et résumé de l’invention Afin d’améliorer la situation et de répondre à ce ou à ces inconvénients, il est proposé, de façon générale, un système de virtualisation pour plateau de jeu, le système de virtualisation comprenant un premier module et un deuxième module, lesdits modules étant connectés entre eux au moyen d’un réseau local, le premier module étant adapté pour - capturer une image d’un espace physique correspondant audit plateau de jeu et comprenant au moins un élément physique ; - analyser l’image capturée pour déduire un état physique dudit au moins un élément physique ; - transmettre, au deuxième module, via ledit réseau local, l’état physique déduit de l’au moins un élément physique, le deuxième module étant adapté pour : - générer, sur réception de l’état physique transmis, une représentation virtuelle de l’espace physique, dit espace virtuel, de sorte que ledit espace virtuel comprend un élément virtuel respectif pour l’au moins un élément physique ; et - attribuer, audit élément virtuel, un état virtuel représentatif de l’état physique de l’élément physique respectif. Dans les présentes, le pion est un élément physique générique, qui peut aussi correspondre à un jeton, une carte ou encore un élément interactif. Ce moyen de virtualisation comprend, premièrement, une analyse d’un environnement physique associé à un jeu en cours afin d'identifier les éléments physiques utilisés par les utilisateurs de ce jeu et de créer une représentation digitale fidèle de la scène réelle de jeu. Le moyen de virtualisation comprend, deuxièmement, une transformation de cette représentation de la scène réelle en représentation digitale fidèle du jeu, en d’autres mots, une digitalisation du jeu pour déterminer les éléments caractéristiques de l'état actuel de la partie en cours. Troisièmement, le moyen de virtualisation comprend une conversion de cette représentation digitale de l'espace physique en éléments virtuels de l'espace digital. Ceci fournit donc un moyen de virtualisation d’un jeu de plateau et d’éléments physiques utilisés en combinaison avec celui-ci, de sorte à pouvoir fournir aux joueurs, c’est-à-dire à des utilisateurs qui interagissent avec le jeu de plateau et les éléments physiques qui lui sont associés, une contrepartie virtuelle qui est représentative de ce jeu de plateau et de ces éléments physiques. Dans une réalisation, l’état physique, respectivement l’état virtuel, comprend au moins l’un parmi un identifiant, un attribut de détermination, une position physique dans l’espace physique, respectivement une position virtuelle dans l’espace virtuel, et une orientation physique par rapport à l’espace physique, respectivement une orientation virtuelle par rapport à l’espace virtuel. Ceci permet d’associer, à chaque élément physique dans l’élément physique, une contrepartie digitale dans l’espace virtuel, cette contrepartie digitale présentant des caractéristiques d’identité, de localisation et de direction dans l’espace représentatives des caractéristiques correspondantes à celles de l’élément physique. Ceci permet aussi d’enrichir la virtualisation au moyen de contenus digitaux supplémentaires, par exemple des informations, des sons, de la musique et/ou des animations de sorte que la contrepartie digitale puisse fournir aux joueurs, c’est-à-dire aux utilisateurs du jeu, une expérience de jeu plus immersive. Dans une réalisation, le deuxième module est en outre adapté pour fournir à un dispositif tiers connecté au deuxième module, sur attribution dudit état virtuel à l’élément virtuel, un affichage de la représentation virtuelle générée. Ceci permet d’afficher la représentation digitale de l'espace physique sur un écran ou sur tout autre moyen d’affichage visible pour l’ensemble des utilisateurs interagissant avec le jeu de plateau. Dans une réalisation, l’état physique de l’au moins un élément physique est renseigné par un marqueur visuel disposé sur ledit élément physique, ledit marqueur visuel comprenant au moins l’un parmi une image, un code barre linéaire, un code barre matriciel et un marqueur composite. Ceci permet de simplifier l’analyse d’une image capturée au moyen de repères visuels pouvant être imprimés et apposés sur les éléments physiques. Tout type d’élément physique pouvant être utilisé, ceci améliore également l’ergonomie du système puisque une distinction entre éléments physiques peut se faire simplement à l’aide de marqueurs visuels distincts. Dans une réalisation, le plateau de jeu est une surface plane comprenant une pluralité de cellules adjacentes définissant des éléments physiques respectifs du plateau de jeu. Ceci permet d’améliorer l’efficacité de la virtualisation du plateau de jeu en discrétisant ce dernier sous la forme d’une pluralité d’objets dont l’état physique est déductible de l’analyse d’une image capturée, au même titre que l’état physique d’autres éléments physiques tels que des pions, des jetons, des cartes, des boutons virtuels, etc. Dans une réalisation, l’élément virtuel respectif de l’au moins un élément physique est un pion, ledit pion étant configuré pour être déplaçable de manière contrainte dans l’espace virtuel en fonction d’un déplacement dudit au moins un élément physique respectif dans l’espace physique. Ceci permet d’établir une correspondance stricte entre des règles conditionnant le mouvement de pions sur le plateau de jeu et les limites des déplacements autorisés par les éléments virtuels qui leur correspondent dans l’espace virtuel. Selon différentes variantes de cette réalisation, l’au moins un élément physique est une carte ou un bouton de commande, ladite carte ou ledit bouton de commande étant configuré pour être déplaçable de manière contrainte dans l’espace virtuel en fonction d’un déplacement dudit au moins un élément physique respectif dans l’espace physique. Dans une réalisation, l’élément virtuel respectif de l’au moins un élément physique est un bouton de commande, ledit bouton de commande étant configuré pour déclencher un évènement dans l’espace virtuel en fonction d’une interaction d’un utilisateur avec ledit au moins un élément physique respectif dans l’espace physique. Ceci permet de fournir des moyens de jeu interactifs pouvant être opérés directement par un utilisateur du jeu et lui permettant d’agir sur des éléments virtuels dans l’espace virtuel. Dans une réalisation, la génération de l’espace virtuel comprend détecter une position physique relative et/ou une orientation physique relative de l’élément physique par rapport au plateau de jeu. Ceci permet d’augmenter l’immersion des utilisateurs par rapport à la représentation virtuelle de l’espace physique au moyen d’informations spatiales. Dans une réalisation, l’analyse de l’image capturée comprend détecter une position physique relative de l’au moins un élément physique par rapport au plateau de jeu et projeter ladite position détectée sur un plan du plateau de jeu et selon une direction anti-normale au plateau de jeu, la transmission, au deuxième module, via ledit réseau local, de l’état physique déduit de l’au moins un élément physique comprenant ladite position projetée. Ceci permet d’améliorer la précision de la détection et de la localisation d’éléments physiques tridimensionnels par rapport à un plateau de jeu bidimensionnel en raison d’effets d’obstruction ou de perspective non souhaités. Dans une réalisation, la transmission de l’état physique déduit est mise en œuvre au moyen d’un échange d’un message du premier module au deuxième module via un canal de communication TCP du réseau local, ledit message comprenant l’état physique sous la forme d’un format JSON. Avantageusement, l’emploi de canaux TCP permet un déploiement efficace d’une communication entre les deux modules, puisqu’un tel protocole permet des communications multiplateformes, et facilite l’attribution d’adresses IP à chaque module, ce qui les rend identifiables sur le réseau local. En outre, le format JSON à l’avantage d’être exploitable par un grand nombre de systèmes, indépendamment du langage informatique utilisé. L’emploi du format JSON permet également d’utiliser un volume de données plus faible que d’autres formats tels que le format XML. Dans une réalisation, le premier module est un dispositif d’enregistrement vidéo d’un téléphone mobile. Ceci permet d’améliorer l’accessibilité de la virtualisation au moyen de dispositifs disponibles au public et fournissant à la fois un moyen d’affichage, une interface utilisateur et un moyen de communication configurable pour transmettre des données par l’intermédiaire du réseau local. Par exemple, lorsque le dispositif d’enregistrement vidéo est un téléphone mobile, un autre téléphone mobile peut aussi être utilisé en tant que deuxième module. Dans une réalisation, le deuxième module est un processeur d’un dispositif électronique, ledit dispositif électronique comprenant un écran d’affichage connecté audit processeur, l’écran d’affichage étant adapté pour recevoir, du processeur, la représentation virtuelle générée et afficher, en temps réel, ladite représentation virtuelle. Ceci permet de partager un affichage du plateau de jeu et des éléments virtualisés, éventuellement enrichis de contenus digitaux, entre une pluralité d’utilisateurs du jeu. Selon un autre aspect, il est proposé, de façon générale, un procédé de virtualisation pour plateau de jeu, ledit procédé étant mis en œuvre par un premier module et un deuxième module connectés entre eux au moyen d’un réseau local, le procédé comprenant: - capturer, avec ledit premier module, une image d’un espace physique comprenant audit plateau de jeu et comprenant au moins un élément physique ; - analyser, avec le premier module, l’image capturée pour déduire un état physique dudit au moins un élément physique ; - transmettre, avec le premier module, au deuxième module, via ledit réseau local, l’état physique déduit de l’au moins un élément physique ; - générer, avec le deuxième module, sur réception de l’état physique transmis, une représentation virtuelle de l’espace physique, dit espace virtuel, de sorte que ledit espace virtuel comprend un élément virtuel respectif pour chaque élément physique ; et - attribuer, avec le deuxième module, audit élément virtuel, un état virtuel représentatif de l’état physique de l’élément physique respectif. Selon un autre aspect, il est proposé, de façon générale, un programme informatique comportant des instructions pour la mise en œuvre du procédé selon le procédé précédent, lorsque lesdites instructions sont exécutées par un processeur d’un circuit de traitement informatique. Selon un autre aspect, il est proposé, de façon générale, un élément physique pour plateau de jeu adapté pour qu’un état physique dudit élément physique soit déductible d’une analyse, par un module, d’une image capturée d’un espace physique correspondant audit plateau de jeu, le plateau de jeu comprenant l’élément physique, la capture de l’image étant mise en œuvre par ledit module, l’état physique de l’élément physique étant renseigné par un marqueur visuel disposé sur l’élément physique. De par ces différentes réalisations et aspects du système, du procédé, du programme informatique et/ou de l’élément physique pour plateau de jeu, il est possible de fournir une virtualisation d’un jeu de plateau et d’éléments physiques pour lequel il n’est pas nécessaire d’acquérir un matériel spécifique, puisque les éléments physiques et/ou le plateau de jeu peuvent être dématérialisés ou simplement imprimés sur du papier. 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 : , la figure 1, qui illustre un espace physique et un espace virtuel du jeu de plateau selon une réalisation ; , la figure 2, qui illustre une discrétisation d’un espace physique selon une réalisation ; , la figure 3, qui illustre une virtualisation de l’espace virtuel selon une réalisation ; , la figure 4, qui illustre un organigramme d’étapes d’un procédé de virtualisation selon une réalisation ; , la figure 5, qui illustre une détection d’un élément physique selon une réalisation ; , la figure 6, qui illustre une virtualisation d’interactions effectuées au moyen d’éléments physiques interactifs ; , la figure 7, qui illustre une détection d’un élément physique selon une réalisation ; , la figure 8 qui illustre une virtualisation d’un déplacement d’un élément physique par le premier module selon une réalisation; , la figure 9, qui illustre une virtualisation d’un déplacement d’un élément physique par le deuxième module selon une réalisation ; , la figure 10, qui illustre une communication de messages entre le premier module et le deuxième module selon une réalisation ; et , la figure 11, qui illustre un dispositif adapté pour mettre en œuvre un procédé de virtualisation selon une réalisation. Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité. Les dessins et la description ci-après contiennent, pour l’essentiel, des éléments de caractère certain. Ils pourront donc servir à mieux faire comprendre la présente divulgation et à contribuer à sa définition, le cas échéant. Il est maintenant fait référence à la figure 1, qui illustre la complémentarité entre un espace physique et un espace virtuel du jeu de plateau. Comme illustré, le plateau forme une zone de jeu sur laquelle un jeu de plateau se déroule. Cette zone de jeu est duale et peut se séparer en une partie matérielle et une partie digitale formant, respectivement, un espace physique JS et un espace virtuel JV. Dans l’espace physique JS, l'environnement dans lequel évoluent les joueurs est représenté par le plateau du jeu GB. De préférence, cet environnement définit une représentation simplifiée en raison des contraintes inhérentes au type de support, qui est généralement inerte, en deux dimensions et/ou de taille limitée. Dans l’espace physique JS, un personnage correspondant à un joueur est typiquement représenté par un pion P1, d’autres objets comme l’objet O1 peuvent comprendre des cartes ou des jetons, et des règles du jeu peuvent comprendre des points d’intérêt définis par un utilisateur choisi comme étant un maître de jeu. L’espace virtuel JV n'est lui pas soumis aux contraintes matérielles de l’espace physique JS, et complète ainsi le plateau GB en apportant une représentation complète de l’environnement du jeu, enrichi de contenus vidéo. Cet espace virtuel JS définit ainsi une représentation digitale, en trois dimensions, et pouvant s’accompagner de contenu audiovisuel tel que de la musique ou des bruitages. Dans l’espace virtuel JV, le personnage P1 d’un joueur est typiquement représenté par un avatar P1’ accompagné d’animations, l’objet O1 est un objet 3D O1’, et les règles du jeu comprennent des actions liées aux points d’intérêts et déclenchées par un gestionnaire de jeu. Comme pour un jeu de société traditionnel, les avatars des joueurs sont configurés pour interagir avec les éléments physiques du jeu, et les éléments digitaux répondent à ces interactions physiques. La correspondance établie entre l’espace physique JS et l’espace virtuel JV est permise, premièrement, par une étape d’analyse de de la partie matérielle de la zone de jeu afin d'identifier les éléments physiques en jeu, deuxièmement, par une étape de virtualisation, comprenant une détermination des éléments caractéristiques de l’état courant d’une partie de jeu en cours et permettant de transformer une représentation de la scène réelle dans l’espace physique JS en représentation fidèle du jeu dans l’espace virtuel JV et, troisièmement, par une étape de traduction comprenant une conversion de ladite représentation digital en éléments virtuels. Dans les présentes, un jeu de plateau est entièrement jouable au moyen d'interactions d’utilisateurs avec les éléments physiques de la partie matérielle du jeu. Dès lors, il n'est pas indispensable d'interagir systématiquement avec la partie digitale du jeu, par exemple en utilisant un contrôleur tel qu’une manette, une souris ou encore un écran tactile. Il est maintenant fait référence à la figure 2, qui illustre une discrétisation de l’espace physique selon un exemple de réalisation. Comme illustré, le plateau de jeu GB définit une zone de jeu de l’espace physique JS sur laquelle évolue un pion P1 d’un utilisateur ou tout autre objet O1. Dans les présentes, la zone de jeu représentée par le plateau de jeu GB est définie par ses dimensions. Ce plateau de jeu est éventuellement tridimensionnel et/ou constitué d'un ensemble de cases qui, assemblées entre elles, forment un environnement cohérent. Dans le cas d’un plateau de jeu rectangulaire, la zone de jeu est ainsi définie par une longueur et une largeur. Structurellement, le plateau de jeu peut donc être vu comme une zone de dimension finie, généralement rectangulaire, qui, par la discrétisation décrite ci-après, permet de définir un ensemble fini de cellules. Ceci définit une relation entre les tuiles et les cellules, les tuiles pouvant être non uniformes, c’est-à-dire pouvant être de tailles et de formes variées. Une telle discrétisation d’un plateau de jeu GB peut être mise en œuvre au moyen des étapes suivantes : fournir une surface plane SP de dimension finie, apposer sur cette surface plane SP une grille G2 de dimension deux, la grille G2 étant constituée de cellules C_1, C_2, …, C_N avec N un nombre entier prédéterminé, et définir des tuiles de jeu correspondantes, une tuile étant définie comme une regroupement d'une ou de plusieurs cellules adjacentes de la grille G2, une même cellule ne pouvant appartenir qu'à une seule tuile. Dans le cas présent, et de manière non limitative, on a représenté le cas où N est égal à 42. A l’issue de ces différentes étapes, le plateau de jeu discrétisé peut alors être défini au moyen d’un paramètre de surface, par exemple SP, d’un paramètre de grille, par exemple G2, et d’une liste de tuiles correspondantes. Ceci permet aussi de définir la position d’une tuile et/ou d’un pion, et plus généralement d’un élément physique, de manière relative par rapport à un repère associé à la grille G2. Lorsqu’une tuile définit un élément physique, cette tuile est de préférence munie d’un marqueur visuel permettant de l’identifier comme tel. Selon un exemple, la position d’un pion est définie au moyen d’un identifiant de la tuile du plateau sur laquelle il se trouve. Dans la mesure où une tuile est définie comme un regroupement de cellules de la grille, une cellule ne pouvant appartenir qu'à une seule tuile, il est possible d'identifier de façon unique une tuile à partir d'une cellule de la grille. En particulier, la position du pion peut être définie au moyen de coordonnées discrètes exprimant la position de la cellule dans laquelle il se trouve, et exprimées dans le repère de la grille du plateau. Ces coordonnées définissent ainsi un vecteur de nombres entiers, appelé vecteur « BoardPosition ». De préférence, la grille G2 est une grille régulière, dans laquelle toutes les cellules sont identiques (mêmes formes, mêmes tailles). Une grille régulière rectangulaire G2 peut être définie au moyen des paramètres suivants : le nombre de cellules, la forme des cellules, par exemple carrée ou hexagonale, la taille des cellules et les espaces entre les cellules, par exemple horizontal ou vertical. La grille G2 peut aussi définir un repère orthonormé, ce qui facilite la localisation des cellules puisque chaque cellule peut alors être identifiée par des coordonnées discrètes dans ce repère. De préférence, une tuile est définie au moyen des paramètres suivants : un numéro d’identification et une position, par exemple les coordonnées de la tuile dans le repère orthonormé mentionné précédemment. Dans les présentes, une correspondance est définie entre l’espace physique JS et l’espace virtuel JV. En particulier, cette correspondance est définie par des contraintes de déplacement de pions dans les zones de l'environnement PG, qui doivent être cohérentes avec les contraintes de déplacement des tuiles du plateau de jeu GB. Par exemple, si une zone donnée « Z » correspond à une tuile « T », alors on définit une fonction telle que pour toute zone « Zi » atteignable par un pion ou un objet à partir de la zone « Z », une tuile « Ti » correspondant à « Zi » est atteignable à partir de la tuile « T », et vice-versa. Ayant défini que si une zone « Z » est la contrepartie d'une tuile « T », on peut alors définir une contrainte de déplacement correspondante. Par exemple, considérant que chaque tuile correspond dans un cas simplifié à une seule cellule de la grille G2, la tuile C_1 se situe à l'origine d’un repère orthonormé « XY » défini par la grille, d’axes X et Y orthogonaux entre eux, et de coordonnées (0, 0). La tuile C_2 aurait pour coordonnées (1,0), la tuile C_3 aurait pour coordonnées (2, 0), etc. Dans le cas présent, la tuile C_N correspond à la tuile C_42, qui aurait pour coordonnées (6, 5). Selon différents exemples, une unité d’une coordonnée donnée dans le repère orthonormé « XY » correspond à une distance de trois centimètres, ou à une distance d’un centimètre. Tant dans l’espace physique JS que dans l’espace virtuel JV, l’utilisation de grilles permet de définir un tel repère orthonormé « XY ». En outre, un repère orthonormé « XYZ » peut aussi être défini, les coordonnées de la tuile C_1 étant alors (0, 0, 0) dans ce repère. Le repère « XYZ » est formé à partir du repère « XY », de sorte que l'axe Z est orthogonal aux axes X et Y. Dans les présentes, un repère « XY » ou « XYZ » permet aussi de définir la position d’objets tels que des pions. En particulier, un pion est généralement défini au moyen des paramètres suivants : un identifiant du pion, par exemple un numéro d’identification unique, et un état de jeu, ledit état de jeu comprenant en particulier une position du pion sur le plateau de jeu et une orientation de ce pion. En particulier, la connaissance de la position du pion permet de déterminer sa position relative par rapport à d’autres objets, en ce compris la tuile sur laquelle le pion est situé, et la connaissance de l’orientation du pion permet de déterminer dans quelle direction celui-ci est orienté. En outre, l’état de jeu d’un pion peut aussi comprendre une information binaire indiquant si ledit pion est considéré comme étant en jeu ou non. Par exemple, l’orientation d’un pion peut être définie au moyen d’un vecteur de nombres entiers, appelé vecteur « Forward », exprimant la position relative de la cellule dans laquelle se trouve le pion par rapport à la position de la cellule vers laquelle ce pion est orienté. Cette position relative peut être exprimée dans le repère de la grille du plateau. Ainsi, un pion qui serait situé sur la tuile C_2 et regarderait vers la tuile C_42 peut se voir associer un vecteur « Forward » exprimant la position relative de la tuile C_2 par rapport à la tuile C_42, c’est-à-dire un vecteur de coordonnées (5,5). Il est maintenant fait référence à la figure 3, qui illustre une virtualisation de l’espace virtuel selon une réalisation possible. Comme illustré, l’espace virtuel JV définit un environnement de jeu tridimensionnel PG dans lequel peuvent évoluer les avatars des utilisateurs, c’est-à-dire les joueurs. Ainsi, l’environnement PG est un équivalent digital du plateau de jeu GB. Pour garantir cette équivalence, l’environnement PG est découpé en un ensemble de zones Z1, Z1, …, Z_M correspondant aux tuiles du plateau de jeu discrétisé. Structurellement, l’environnement PG définit une surface 3D de dimension finie (non représentée), appelé terrain de jeu, et découpé en un ensemble fini de volumes. Comme précédemment pour la discrétisation du plateau de jeu GB, la discrétisation de l'environnement de jeu tridimensionnel PG peut être mis en œuvre à l'aide d'une grille plane bidimensionnelle, ici G2’, disposée sur un plan, ici appelé plan principal de l'environnement. Les cellules ainsi définies par cette grille, appelés parallélépipèdes, sont ensuite regroupées pour définir des zones de l'environnement PG. Une telle virtualisation peut être mise en œuvre au moyen des étapes suivantes : générer un terrain de jeu définissant une surface 3D de dimension finie, disposer la grille plane bidimensionnelle G2’ sur le plan principal de l'environnement afin de découper l’environnement en parallélépipèdes, et définir des zones de jeu correspondantes, une zone de jeu étant définie comme un regroupement d'un ou de plusieurs parallélépipède, un même parallélépipède ne pouvant appartenir qu'à une seule zone. Ceci définit une relation entre les zones et les parallélépipèdes. La grille G2’ peut définir un repère orthonormé « XYZ », ce qui facilite la localisation des zones et des parallélépipèdes puisque chacun de ces éléments peut alors être identifié par des coordonnées discrètes dans le repère « XYZ ». En particulier, la grille G2’ peut être construite, pour l’espace virtuel JV, d’une manière similaire à la grille G2, pour l’espace physique JS, mais avec des paramètres éventuellement différents. Ainsi, la grille G2’ peut comporter des valeurs différentes de ces paramètres par rapport à celles de la grille G2, par exemple pour ce qui concerne le nombre de cellules, la forme des cellules, la taille des cellules, les espaces entre les cellules. Une zone regroupant des parallélépipèdes de G2’ peut être définie au moyen des paramètres suivants : un numéro d’identification, unique, et une position, par exemple les coordonnées du parallélépipède dans le repère de la grille, de la ou des cellules de la grille définissant celui-ci, appelée position « EnvPosition ». L'environnement d’une partie de jeu peut être défini à partir de paramètres choisis parmi un paramètre de terrain, appelé paramètre « BoardPlane », un paramètre de grille, appelé paramètre « BoardGrid » et une liste de zones, appelée liste « List ». Dans les présentes, l'environnement PG de l'espace virtuel JV est une contrepartie digitale du plateau de jeu GB de l'espace physique JS ; de même, les zones de l'environnement PG sont des contreparties digitales des tuiles du plateau de jeu GB. La cohérence de cette contrepartie est garantie par des exigences structurelles décrites ci-après, afin d’avoir autant de zones dans l'environnement PG que de tuiles sur le plateau GB. Dans un exemple, et pour qu’à chaque tuile du plateau corresponde une et une seule zone de l'environnement, on définit une fonction bijective « #f » qui associe à chaque tuile du plateau une zone de l'environnement. En particulier, cette fonction peut fixer l’identifiant d’une zone donnée comme étant égal à l’identifiant de la tuile correspondante. Dans le cas présent, les coordonnées d'une tuile dans le repère défini par la grille G2 du plateau de jeu GB ne sont pas nécessairement égales aux coordonnées de la zone correspondante dans le repère défini par la grille G2’ de l'environnement. En outre, les dimensions des zones de l'environnement PG, ainsi que les espaces possibles entre ces zones, ne sont pas contraints par les éléments sur ou formant le plateau de jeu GB. De plus, pour garantir la cohérence de l’agencement des tuiles du plateau de jeu et des zones de l'environnement PG de chaque côté des grilles G2 et G2’, une disposition et un ordre similaire peut être imposé entre les tuiles et les zones correspondantes. Lorsque cette contrainte est respectée, deux zones correspondant à deux tuiles contigües du plateau de jeu GB ne sont pas nécessairement contigües dans l'environnement PG. En effet, l'environnement PG peut comporter des espaces formés par des cellules qui n’ont pas de contrepartie sur le plateau de jeu GB en termes de tuiles. Dans ce cas, il est considéré que ces espaces ne sont pas pris en compte dans le jeu, mais peuvent par exemple intervenir en tant qu’éléments de décor. Dans les présentes, tout élément physique et tout élément virtuel respectif peut être orienté, c’est-à-dire caractérisé par une direction. En particulier, un pion P1 représentant un avatar d’un utilisateur peut être positionné et orienté dans l’environnement de jeu tridimensionnel PG. Pour ce faire, la position du pion P1, appelée position « WorldPosition », est discrétisée dans l’espace virtuel sous la forme d’une position discrétisée, appelée position « EnvPosition ». La position « EnvPosition » d'un avatar est définie par un vecteur de nombre entiers dans le repère discret de la grille G2’, et correspondant à la position de la zone dans laquelle se trouve l'avatar. De même, une orientation d’un avatar peut être définie par un vecteur, ce vecteur permettant d’indiquer une rotation de l’avatar au cours du temps ou lors d’un déplacement du pion correspondant. Par exemple, lorsqu'un utilisateur joueur tourne un pion P1 sur le plateau de jeu, on peut déterminer la nouvelle orientation de P1, qui est aussi la nouvelle orientation attendue de l'avatar correspondant, comme décrit ci-après. De préférence, cette nouvelle orientation est mise à jour plusieurs fois par secondes, ou au moins une fois pour chaque image capturée, et peut donc être utilisée directement pour mettre à jour en temps réel l'orientation de l'avatar. Dans certains cas, le déplacement de l'avatar respectif du pion P1 peut être tel que son orientation est désynchronisée de celle du pion P1, mais synchronisée à la fin du déplacement complet. Pour éviter ce problème de discontinuité, on peut sélectionner l'orientation attendue en tant qu'orientation cible de l'avatar. Si l'avatar n'est pas en mouvement, on peut configurer son orientation de sorte à pointer vers sa direction cible, c’est-à-dire une direction alignée avec celle de l'orientation du pion P1 telle que déductible d’une image capturée. Si l'avatar est en mouvement, la direction de son déplacement peut être utilisée pour configurer son orientation. En outre, chaque zone de l'environnement PG est définie comme comprenant un repère orthonormé local propre, par exemple dont l’origine se situe au centre de la cellule correspondante et telle que les axes de ce repère orthonormé local sont alignés avec ceux du repère de la grille G2’. Une position d’un avatar dans cette zone peut alors être définie au moyen d’une position locale, appelée position « CellPosition ». Une position « CellPosition » d'un avatar est, de préférence, un vecteur de nombres réels correspondant à des coordonnées exprimées dans le repère orthonormé local de la zone dans laquelle se trouve l'avatar. Ceci permet d'obtenir, pour une zone donnée de l’environnement PG identifiée par une position « EnvPosition » correspondante, les coordonnées de l’avatar dans ce repère, appelées coordonnées « XcellCenterWorid, YcellCenterWorid, ZcellCenterWorld ». En outre, la position « CellPosition » d'un avatar peut être paramétrée au moyen d’un identifiant de la zone de l’environnement où il se situe, par exemple au moyen des coordonnées de cette zone dans le repère de la grille, « EnvPosition », et d’une position de l'avatar dans la zone, c’est-à-dire la position « CellPosition » correspondante. Dans les présentes, on définit l'avatar d’un utilisateur dans l’environnement PG de l'espace virtuel JV comme étant une contrepartie digitale du pion de cet utilisateur sur le plateau de jeu GB de l'espace physique JS. De préférence, un avatar comprend un modèle animé d’un personnage correspondant au joueur, affichable en trois dimensions et orienté, c’est-à-dire présentant une orientation dans l’environnement PG. Un avatar peut être de deux types, soit un avatar contrôlable soit un avatar non-contrôlable par un utilisateur. Il doit y avoir autant d'avatars contrôlables dans l’environnement PG que de pions d’utilisateurs sur le plateau de jeu GB. Dans un exemple, et pour qu’à chaque avatar corresponde un et un seul pion d’un utilisateur, on définit une fonction bijective « #a » qui associe à chaque pion sur le plateau de jeu GB un avatar dans l'environnement PG. En particulier, cette fonction peut fixer l’identifiant d’un pion comme étant égal à l’identifiant de l’avatar correspondant. II peut y avoir plus d'avatars que de pions : dans ce cas, les avatars qui ne sont pas associés à un pion sont définis comme étant des avatars non-contrôlables, appelés avatars « PNJ ». De préférence, un avatar est défini au moyen des paramètres suivants : un numéro d’identification unique, une position dans l'environnement de jeu, permettant de le situer relativement par rapport aux autres objets et avatars, une orientation et éventuellement une animation courante. Dans les présentes, les déplacements et/ou les évènements déclenchés sont soumis à des règles de jeu. De manière générale, une règle de jeu est une action contextuelle effectuée au cours d’une partie de jeu de plateau. Selon un exemple, une règle de jeu est mise en œuvre lorsqu’un avatar est déplacé sur une tuile particulière, lorsqu’un objet lié à une action est mis en jeu par un utilisateur, lors d’un choix contextuel d’un utilisateur, par exemple la sélection d’une option, ou encore lorsqu’une condition de jeu prédéterminée est remplie (par exemple au début du quatrième tour de la partie de jeu). Selon un autre exemple, une règle de jeu est mise en œuvre sous la forme d'un point d'intérêt, ce point d’intérêt étant configuré pour s'exécuter lorsqu'un utilisateur déplace son pion sur une tuile identifiée du plateau. En particulier, une association entre une tuile est un point d’intérêt peut être définie préalablement. Un ensemble de telles associations fournit alors une cartographie des points d'intérêts du jeu. Selon encore un autre exemple, une règle de jeu est mise en œuvre sous la forme de contraintes de déplacement de pions et/ou d’objets sur le plateau de jeu GB, par exemple sous la forme de chemins exclusifs pouvant être suivis par ces pions et/ou objets de jeu. En particulier, on peut définir une contrainte de déplacement au niveau d'une tuile donnée comme étant une liste des tuiles adjacentes à celle-ci et pouvant être accessibles à partir de celle-ci, par un pion ou un objet de jeu quelconque. Il est maintenant fait référence à la figure 4, qui représente sous forme d’organigramme un exemple d’étapes d’un procédé de virtualisation d’un plateau de jeu. Comme représenté, une étape 110 concerne la capture, par un premier module M1, d’une image d’un espace physique JS comprenant le plateau de jeu GB ainsi qu’au moins un élément physique par exemple un pion P1, ou encore des pions, des cartes ou des jetons. Le module M1, qui correspond par exemple à une application « CAMERA » installée sur un dispositif électronique muni d’une caméra, met ensuite en œuvre une étape 120 d’analyse de l’image capturée pour en déduire, au cours d’une digitalisation, un état physique de l’au moins un élément physique, ici un état physique du pion P1, tel que sa position sur le plateau de jeu. La mise en œuvre de l’application « CAMERA » repose par exemple sur l’utilisation de téléphones mobiles dotés de caméra, et éventuellement, de capacités d'exploitation de la réalité augmentée. Cette caméra est apte à filmer et analyser les éléments physiques du jeu, afin de déterminer en temps réel leurs états. Selon des réalisations possibles, l'étape d'analyse 120 comprend par exemple une identification des éléments physiques dans l’espace physique JS parmi lesquels le plateau de jeu GB, des pions, des cartes, des jetons, etc. L’étape d’analyse 120 comprend par exemple une détermination des états de ces éléments physiques, parmi lesquels leur position ou leur orientation, ou des identifiants qui leur sont associés. De préférence, l'état d'un élément physique est défini par sa position et son orientation par rapport à un repère orthonormé comme décrit ci-après. Cette position et cette orientation peuvent être déterminées par rapport à l'origine du plateau de jeu GB, et définies par les coordonnées d’un vecteur de nombres réels à associé à l'élément physique, et par exemple exprimées en centimètres dans un repère orthonormé. De préférence, pour pouvoir déterminer l'état d'un élément physique, l'application « CAMERA » identifie et/ou associe préalablement un repère orthonormé continu au plateau de jeu GB. Une étape 130, qui suit l’étape 120, concerne la transmission, du premier module M1 vers un deuxième module M2, via un réseau local NET, de l’état physique déduit de l’au moins un élément physique, le réseau local NET étant configuré pour permettre la communication de messages entre les modules M1 et M2. Le module M2 correspond par exemple à une application « SCREEN » installée sur un autre dispositif électronique qui est relié à un écran d’affichage. La mise en œuvre de l’application « SCREEN » repose par exemple sur l’utilisation de supports de jeux vidéo, par exemple une console de jeu ou des interfaces graphiques dédiées telles que des tablettes. Des restitutions d’environnements visuels et/ou sonores ainsi que l'orchestration du jeu peuvent par ailleurs incomber à l'application « SCREEN ». Une étape 210, concerne la réception, par le deuxième module M2, de l’état physique transmis au cours de l’étape 130. Au cours de l’étape 220, qui suit l’étape 210, le deuxième module M2 génère une représentation virtuelle de l’espace physique, dit espace virtuel JV, comprenant un élément virtuel respectif pour chaque élément physique, par exemple un avatar P1’ correspondant au pion P1 et un environnement PG correspondant au plateau de jeu GB dans l’espace physique JS. Une étape 230 concerne ensuite l’attribution, avec le deuxième module M2, à chaque élément virtuel généré, d’un état virtuel représentatif de l’état physique de l’élément physique respectif. Par exemple, l’attribution d’une position de l’avatar P1’ dans l’environnement PG de l’espace virtuel JV en fonction d’une position du pion P1 sur le plateau de jeu GB dans l’espace physique JS. Ainsi, le module M1 muni de l’application « CAMERA » permet d’analyser l’espace physique JS d’un jeu en cours de partie tandis que le module M2, muni de l’application « SCREEN », est en charge de la traduction des états reçus et permet de construire puis d’afficher un espace virtuel JV correspondant à la partie du jeu. En outre, les dispositifs électroniques sur lesquels sont installées les applications « CAMERA » et « SCREEN » peuvent donc être des produits connus sur lesquels il est possible d'installer un programme informatique mettant en œuvre les étapes ici décrites. Les étapes 110 à 230 fournissent ainsi un mécanisme de digitalisation-traduction pour produire, au final, une version digitale de la partie de jeu, qui est synchronisée entre les différents éléments physiques digitalisés et peut être affichée sur un écran. Il est maintenant fait référence à la figure 5, qui illustre une détection d’un élément physique au cours d’une étape d’analyse telle que précédemment décrite. Une telle détection est mise en œuvre au moyen de l'analyse d’images filmées par la caméra associée au module M1 et sur lequel est installée l'application « CAMERA ». Cette détection repose sur l’emploi de marqueurs visuels, par exemple le marqueur visuel physique Mi, dont sont munis les éléments physiques à détecter. Chaque marqueur visuel correspond à un marqueur visuel physique dans l’espace physique JS et à un marqueur digital dans l’espace virtuel JV. De préférence, un marqueur visuel physique est une copie physique imprimée d’une image donnée ayant des dimensions prédéfinies et connues. Un marqueur digital comprend une image numérisée, par exemple un fichier de format JPG ou PNG, dont la taille est également prédéfinie et connue. La détection comprend ainsi l’association d’un marqueur visuel physique à un élément physique donné, ce marqueur visuel physique étant préalablement imprimé et/ou apposé sur cet élément physique. Lors de la détection, le module M1 muni de l’application « CAMERA » associe une copie digitale, appelée « Targetlmage », du marqueur visuel Mi à l'élément physique virtuel correspondant, par exemple un avatar P1’ définissant le correspondant digital d’un pion P1. Au cours de cette association, il peut être vérifié que la taille du marqueur visuel digital correspond aux dimensions réelles prédéfinies du marqueur visuel physique. Toujours lors de la détection, les images captées par M1 sont analysées en temps réel pour effectuer une recherche de ces marqueurs visuels dans l’image. Lorsqu’un marqueur est détecté dans l'image, par exemple le marqueur visuel physique Mi, l'application « CAMERA » positionne l'élément digital correspondant à l'emplacement où le marqueur a été détecté. Par exemple, l’application peut déterminer une position et/ou une orientation du marqueur digital en fonction de la position et de l’orientation du marqueur visuel physique Mi dans un repère « XY » ou « XYZ », comme défini ci-après. Comme illustré, la structure d'un marqueur Mi peut être définie en fonction de la taille et de la position de celui-ci sur le plateau de jeu GB. En particulier, la position du marqueur Mi est définie par les coordonnées Xi et Yi permettant de repérer l’un des coins de Mi dans le repère « XY », la taille du marqueur est définie par les dimensions Li et li exprimant la longueur et la largeur de celui-ci, en centimètres par exemple, et l’orientation du marqueur est définie par les composantes du vecteur Vi, par exemple défini par la direction de la diagonale de Mi passant par deux coins du marqueur et ne passant pas par le coin utilisé pour repérer la position du marqueur Mi. Bien entendu, toute autre convention de repérage de la position et de l’orientation peut être utilisée de manière équivalente. De préférence, l'application « CAMERA » connait préalablement la taille du marqueur visuel physique à détecter. Puisque l'image analysée est une image plane en deux dimensions, la taille fournit une information permettant de déterminer la profondeur de l’élément physique sur lequel est apposé le marqueur Mi, cette profondeur étant définie comme étant sa distance par rapport à la caméra, ou encore sa hauteur relative par rapport à un autre élément physique. Lors de la détection de deux marqueurs visuels physiques Mi1 et Mi2 correspondant à deux marqueurs visuels distincts imprimés et apposés sur deux pions séparés, la capture d’une image comprenant ceux-ci et effectuée selon un axe orthogonal au plan des marqueurs permet par exemple de révéler que la taille de Mi1 apparaît comme étant plus petite que la taille de Mi2. Dans ce cas, il peut en être déduit que si Mi1 et Mi2 ont la même taille réelle, par exemple un carré de 3 centimètres sur 3 centimètres, alors Mi1 est plus loin de la caméra que Mi2, et donc plus bas par rapport à un axe vertical « Z ». Si, en revanche, Mi1 a une taille réelle inférieure à celle de Mi2, alors il est possible que Mi1 et Mi2 se situent à une distance égale de la caméra capturant l’image, et donc à une même hauteur par rapport à l’axe vertical « Z ». En conséquence, de préférence, il convient de fournir les tailles physiques des marqueurs visuels au premier module M1 afin de pouvoir déduire plus précisément l’état physique des éléments physiques analysés dans une image capturée correspondante. En outre, le premier module M1 est configuré pour déterminer la position et l’orientation du plateau de jeu GB, notamment afin d’en déduire un repère de référence. Bien que la position et l’orientation du plateau de jeu GB ne résulte pas de l’analyse de l’image capturée, celui-ci permet de définir le repère de référence de l'application « CAMERA », et par rapport auquel les états de tout élément physique sont déterminés. De préférence, le plateau de jeu GB est muni d’un marqueur visuel correspondant. Ce marqueur visuel doit pouvoir être présent dans toute image capturée par le module M1 afin de mettre en œuvre les étapes du procédé. Ceci permet d’associer le plateau de jeu à une image unique. Selon un premier exemple, le marqueur visuel correspondant au plateau de jeu GB est un marqueur visuel unique, appelé « Targetlmage », et dont le marqueur visuel physique correspondant recouvre tout ou partie du plateau de jeu physique. Selon un deuxième exemple, le marqueur visuel correspondant au plateau de jeu GB est un marqueur visuel composite, appelé « MultiTarget », et composé de plusieurs marqueurs visuels « Targetlmage » répartis sur le plateau de jeu GB. En particulier, un marqueur composite est composé de plusieurs images, reliées entre-elles par une structure rigide. Avantageusement, un marqueur composite peut être correctement détecté dès lors qu'au moins l'une des images le composant est détectée. L'utilisation d'un marqueur composite revient ainsi à l'utilisation de plusieurs marqueurs pour la détection d'un seul élément physique, tel que le plateau de jeu GB. Plus grand est le nombre de marqueurs visuels utilisés, plus il y a de chances de fournir une détection précise et correcte du plateau de jeu GB ou d’éléments physiques sur celui-ci, puisque la probabilité de voir tous les marqueurs occultés simultanément à la caméra est réduite. De manière générale, la taille des marqueurs visuels physiques utilisés est de l’ordre de plusieurs centimètres, et du moins suffisamment grande que pour en faciliter et en stabiliser la détection lors de l’analyse d’une image capturée, notamment en raison de risques d’occultation partielle du marqueur visuel physique par un autre objet. Quelle que soit la convention utilisée, par exemple l’association du plateau de jeu à un marqueur visuel unique ou composite, quand l'application « CAMERA » détecte le marqueur du plateau elle peut, grâce aux informations définies dans la structure du marqueur, positionner correctement le plateau autour de celui-ci. Elle peut également fixer la taille du plateau au regard de la taille détectée de son marqueur, ce qui revient à positionner le plateau de jeu GB sur une axe vertical et normal au plan du repère « XY ». Une fois que le plateau GB est correctement détecté et positionné, l’application « CAMERA » peut définir un repère de référence comme étant le repère orthonormé « XYZ » formé par le plan « XY » du plateau et par la normale « Z » a ce plan et dont l'origine se situe au centre du plateau. En outre, on peut détecter des éléments physiques en trois dimensions, tels que des cubes, des parallélépipèdes, etc. Ceci permet en particulier de détecter différentes faces d’un même élément et d’associer ces faces à des images distinctes. Ceci permet d’améliorer la détection d'un élément physique, par exemple du plateau de jeu lui-même, en lui associant plusieurs images distinctes. Ainsi, il est par exemple possible de détecter le résultat d’un jet de dé, qui est un élément physique tridimensionnel. S’il n'est pas possible de déterminer a priori quelle face sera exposée vers la caméra à l’issue du jet, lorsque ce dé est muni d’un marqueur visuel composite, par exemple sur au moins trois de ces faces, de préférence sur ses six faces, la position et l’orientation de ce dé est détectable dans la majorité des situations normales d'utilisation. Ceci permet au système de pouvoir déterminer tout résultat d’un lancer de dé effectué par un utilisateur dans l’espace physique JS, ce résultat étant défini par la face supérieure du dé. Un marqueur visuel peut aussi être utilisé pour définir les états d’un bouton virtuel, par exemple lorsqu’il est prévu qu’une interaction d’un utilisateur avec ce bouton de jeu déclenche un évènement, par exemple sous la forme d’une pression ou d’un relâchement virtuel de ce bouton. Une telle pression ou relâchement est mise en œuvre au moyen d’une occultation temporaire d’une zone du marqueur visuel apposé sur le bouton virtuel, cette zone définissant une sous-surface du marqueur visuel. Quand une image captée est analysée pour identifier des marqueurs visuels, on déterminer si la zone est obstruée : si oui, alors le bouton virtuel est considéré comme étant dans un état pressé, sinon, le bouton virtuel est considéré étant dans un état relâché. Un évènement d’activation appelé « OnButtonPressed » est ainsi défini lorsque le bouton virtuel passe d'un état relâché à un état pressé, et un évènement de désactivation appelé « OnButtonReleased » est défini lorsque le bouton virtuel passe d'un état pressé à un état relâché. Il est maintenant fait référence à la figure 6, qui illustre une virtualisation d’interactions effectuées au moyen d’un élément physique interactif, tel qu’un bouton virtuel. Comme illustré, l’espace physique JS peut comporter une pluralité d’objets physiques interactifs O_1, O_2, …, O_n avec lesquels, au cours d’un jeu, un utilisateur peut interagir. Une interaction comprend par exemple une sélection d’une option. Un pion ou tout autre objet de jeu de l’espace physique peut ainsi être utilisé en tant qu’objet physique interactif pour permettre le déclenchement d’un évènement dans l’espace virtuel JV,. A un ou plusieurs de ces objets physiques interactifs correspondent, dans l’espace virtuel JV, un ou plusieurs objets virtuels, appelés boutons virtuels VB_1, VB_2, …, VB_l, éventuellement en nombre différent. Un bouton virtuel donné permet d'associer chaque type d'interaction qui est mise en œuvre par un ou plusieurs objets physiques interactifs au déclenchement d’un ou de plusieurs évènements Evt_1, Evt_2, …, Evt_m correspondants dans l’espace virtuel JV. Un objet physique peut ainsi déclencher un évènement lorsqu'il subit une interaction, par exemple lorsqu’il est pressé, tourné ou déplacé par un utilisateur. Par exemple, une interaction que peut subir un objet est choisie parmi maintenir, relâcher, tourner vers la gauche ou déplacer vers le haut. Dans les présentes, un bouton virtuel de l'espace virtuel JV est donc une contrepartie digitale d’un objet physique interactif du plateau de jeu GB de l'espace physique JS. Un tel bouton virtuel est un objet de jeu, appelé objet « GamePiece », qui est cliquable, c’est-à-dire qu’il est configuré pour déclencher un évènement lorsqu’un utilisateur interagit avec l’objet physique interactif correspondant. Un bouton virtuel peut être défini à partir de paramètres choisis parmi un identifiant, un état de jeu et une information d’évènement, cette information pouvant être binaire, et par exemple associée à une indication d’une pression de l’objet physique interactif ou une indication d’un arrêt de pression de celui-ci. Selon un exemple, on définit un bouton virtuel unique de la partie de jeu, comprenant un identifiant unique : dans ce cas, le bouton virtuel écoute un ou plusieurs même(s) objet(s) physique(s) interactif(s). Selon un autre exemple, on définit un bouton virtuel associé au pion d’un utilisateur donné : dans ce cas, le bouton virtuel écoute plusieurs objets physiques interactifs successivement, par exemple régulièrement ou en fonction du contexte de la partie de jeu. Des interactions pouvant être gérées par un bouton virtuel comprennent des interactions de type « bouton », par exemple Appuyer, maintenir, relâcher, des interactions de type « rotation », par exemple tourner vers la droite ou tourner vers la gauche, ou encore des interactions de type « mouvement », par exemple déplacer vers le haut, déplacer vers le bas, déplacer vers la gauche, déplacer vers la droite. Il est maintenant fait référence à la figure 7, qui illustre un exemple de résolution d’erreurs de perspectives lors de la détection et de la virtualisation d’un élément physique. Au cours d’une étape d’analyse comme précédemment décrit, et à l'issue de cette étape d'analyse, la position réelle d’un élément physique tel qu’un pion P1 est définie sous la forme d’un vecteur dont les coordonnées continues sont exprimées dans le repère orthonormé « XYZ ». Pour déterminer la position « BoardPosition » de P1, il convient d'exprimer ces coordonnées dans le repère discret de la grille du plateau en effectuant un changement de repère. Ce changement de repère est effectué au moyen d’une fonction adaptée qui, à partir des coordonnées d'un point du repère orthonormé défini par le plateau, renvoie les coordonnées de la cellule dans laquelle se trouve ce point et exprimées dans le repère discret de la grille du plateau. Cependant, si le pion P1, ou de manière générale tout élément physique, présente une hauteur ceci peut générer des erreurs de positionnement puisque le marqueur visuel, lorsqu’apposé sur une surface supérieure du pion P1, ne se situe pas au niveau du plan formé par le plateau de jeu GB. Dans la mesure où l'analyse est réalisée à partir d'une projection des éléments que comprend l’image capturée, qui est en deux dimensions, des effets de perspectives peuvent mener à des erreurs dans la détermination de la position « BoardPosition » de P1. Par exemple, et comme illustré, le centre CMi1 d’un marqueur visuel Mi1 qui est apposé sur la surface supérieure du pion P1 peut apparaitre comme étant décalé par rapport à d’autres points de référence visuels, par exemple un point CP1 du bord du pion P1 en contact avec le plateau de jeu GB et situé du même côté que le premier module M1 responsable de la capture de l’image. Une solution est alors de prendre pour référence la partie visible du pion P1 située entre le point CP1 et le centre CMi1 d’un marqueur visuel Mi1, et de construire une projection PJ1 obtenue en projetant cette référence sur un plan parallèle au plan du plateau GB dans une direction anti-normale à celui-ci. Le point de l'espace qui est le résultat de cette projection PJ1 est dans ce cas un marqueur de jeu, appelé marqueur « TargetMarker » et qui peut être associé à un objet correspondant à l’élément physique, ici le pion P1, et utilisé par l'application « CAMERA » pour en déterminer l'état. L'orientation de P1 est ici identique à l'orientation de son état. Par conséquent, l’état obtenu de l’étape d'analyse est conservée telle quelle, et aucun traitement n'est requis. Il est maintenant fait référence aux figures 8 et 9, qui illustrent une virtualisation d’un déplacement d’un avatar dans l’espace virtuel en fonction d’un déplacement du pion correspondant dans l’espace physique, par le premier module et le deuxième module, respectivement. Lorsqu’un utilisateur déplace un pion P1 sur le plateau de jeu GB, l'application « SCREEN » identifie en temps réel la nouvelle position du pion et détermine la nouvelle position attendue de l'avatar P1’ qui lui correspond dans l’environnement PG. La nouvelle position attendue de l'avatar, appelée « WorldPosition », est indiquée par un vecteur dans le repère « XYZ » et est déterminée à partir de la position du pion sur le plateau, appelée « BoardPosition », définie au moyen des coordonnées de la tuile sur laquelle se trouve le pion physique. Ceci permet de passer d'une représentation discrète à une représentation continue. Les applications « CAMERA », du premier module M1, et « SCREEN », du deuxième module M2, sont configurées pour mettre à jour la destination de l’avatar sur la base des positions « WorldPosition » et « BoardPosition ». Cette mise à jour met en œuvre les étapes successives S11, S12, S13, S14 et S15, par le premier module M1, et les étapes successives S21, S22, S23, S24, S25, S26 et S27, par le deuxième module M2, comme décrit ci-après. Selon différents exemples, les étapes S13, S14 et S15 sont mises en œuvre par un sous-module RC_SRV de contrôle à distance de serveur, appelé composant « RemoteControlServer », et compris dans l’application « CAMERA » du premier module M1 et les étapes … sont mises en œuvre par un sous-module RC_CLT de contrôle à distance de client, appelé composant « RemoteControlClient », et compris dans l’application « SCREEN » du deuxième module M2, ces sous-modules étant configurés pour permettre une transmission de données et de messages entre les deux modules M1 et M2, comme décrit ci-après. L’étape S11 concerne la détection de l’élément physique, ici le pion P1 d’un joueur, à partir du marqueur visuel physique qui lui est associé. L’étape S12 comprend une traduction de l’état correspondant à ce pion P1 dans le repère du plateau de jeu GB, suivie de l’étape S13 qui met à disposition cet état la forme d’un état de joueur, appelé « PlayerState ». Suivant une collecte des états de joueur associés à l’ensemble des pions en jeu, et lors de l’étape S14, tous les états sont centralisés dans une liste appelée « GamePlayerState », comprenant de préférence l’identifiant de chaque élément physique concerné, sa position « BoardPosition » et son orientation. Cette liste est ensuite transmise à l’application « SCREEN » du deuxième module M2 sous la forme d’un message d’état au cours de l’étape S15. Concernant l’avatar P1’, l’étape S21 concerne la réception du message d’état transmis, et son décodage pour en déduire les positions « BoardPosition ». L’étape S22 comprend la traduction des positions « BoardPosition » de chaque état de joueur « PlayerState » sous la forme position « EnvPosition ». L’étape S23 comprend la mise à jour, pour chaque utilisateur, de l’état de joueur « PlayerState » si l’état reçu lors de l’étape S21 est valide, par exemple si cet état respecte des règles de jeu prédéfinies. Lors de l’étape S24, la position du pion est ensuite mise à jour à partir de l’état de joueur « PlayerState ». Lors de l’étape S25, et dès que l’application « CAMERA » indique que le pion P1 correspondant à l’avatar P1’ est resté immobile sur une même case pendant un intervalle de temps prédéterminé, de préférence trois secondes, la position occupée par le pion P1 est définie comme étant sa destination finale. L’application « SCREEN » met en œuvre ces étapes de manière itérative, c’est-à-dire qu’il n’est pas nécessaire d’effectuer un déplacement direct de l’avatar P1’ jusqu’à sa destination finale. Typiquement, lorsqu'un joueur déplace le pion P1 sur le plateau de jeu GB, il effectue un déplacement case par case ; par conséquent, le joueur peut se tromper de case ou bien vouloir encore essayer les différentes destinations accessibles avant d'en choisir une. En conséquence, l’application « SCREEN » n’initie le déplacement de l'avatar P1’ qu'une fois sa destination finale réelle connue. Passé un délai de quelques secondes, de préférence trois secondes durant lesquelles le pion P1 est resté immobile, l’application « SCREEN » considère la nouvelle destination comme définie et initie le déplacement de l'avatar P1’ vers cette destination. Ainsi, la nouvelle position attendue de l'avatar est utilisée par l’application « SCREEN » du deuxième module M2 pour déterminer sa destination au cours du déplacement. Pour chaque image capturée, l’application « SCREEN » calcule ainsi la nouvelle destination courante de chaque avatar à partir de la position reçue du pion respectif. Si cette destination est différente de la position actuelle de l'avatar, alors il est considéré que le pion a changé de case sur le plateau de jeu et que l'avatar doit se déplacer, conformément aux contraintes de déplacement prédéfinies. Suite à l’étape S25, l’étape S26 concerne alors le déplacement de celui-ci vers sa destination courante, ce qui permet de connaître la destination de l’avatar P1’ correspondant à la position discrète « EnvPosition ». L’étape S27 concerne alors la détermination de sa destination continue correspondant à la position « WorldPosition », déterminée à partir de la position discrète « EnvPosition ». Celle-ci est traduite en une position continue, par exemple en utilisant le centre de la zone identifiée par la position « EnvPosition » et la position continue qu’a l’avatar P1’ dans cette zone. La position « WorldPosition » est ainsi déterminée à partir des positions « EnvPosition » et « CellPosition. Il est maintenant fait référence à la figure 10, qui illustre une communication de messages entre le premier module et le deuxième module du système de virtualisation. En particulier, la communication de messages est mise en œuvre au moyen de plusieurs canaux de communication établis entre l’application « CAMERA » et l’application « SCREEN », ces canaux permettant l'échange de données et de messages transitant par le réseau local NET auquel les premier et deuxième module M1 et M2 sont connectés. Comme illustré, le premier module M1 comprend le composant serveur RC_SRV tandis que le deuxième module M2 comprend le composant client RC_CLT. Ces composants s’appareillent automatiquement lorsque les applications « CAMERA » et « SCREEN » sont mises en fonctionnement, en vue d’établir un ou plusieurs canaux de communication entre les deux modules. De préférence, l'échange de flux de données entre les applications « SCREEN » et « CAMERA » est mis en œuvre au moyen d’un protocole TCP lors de leur découverte respective, les informations ensuite échangées entre les deux applications étant contenues dans des objets de format JSON. Lors de la mise en fonctionnement des deux applications, celles-ci se découvrent automatiquement sur le réseau local, par exemple via transmission UDP, et échangent leurs adresses IP et établissent des connexions au moyen d’un protocole TCP pour l’échange ultérieur de données. Lors de la phase de découverte, un canal UDP est établi entre un composant UDP_SRV du premier module M1 et un composant UDP_CLT du deuxième module M2. En particulier, le canal UDP permet un établissement d’une communication entre les deux modules par transmission d’une paire question-réponse, cette paire comprenant, d’une part, l’émission d’une requête de présence RQ depuis le composant UDP_SRV et, d’autre part, sur réception de ladite requête par le composant UDP_CLT, d’une émission d’un accusé de réception ACK du composant UDP_CLT vers le composant UDP_SRV, l’accusé de réception ACK indiquant la présence, la disponibilité et/ou une adresse IP du deuxième module M2 au premier module M1. Ensuite, de préférence sur réception de l’accusé de réception ACK, un ou plusieurs canaux TCP sont établis entre un composant TCP_SDR du premier module M1 et un composant TCP_REC du deuxième module M2. De préférence, deux canaux TCP sont ainsi établis pour permettre l’échange d’informations et de messages entre le composant TCP_SDR du module M1 sur lequel l’application « CAMERA » est installée et le composant TCP_REC du module M2 sur lequel l’application « SCREEN » est installée. De manière non limitative, au moins un troisième canal supplémentaire peut être établi entre les applications « CAMERA » et « SCREEN » pour permettre l’échange de messages, en particulier des messages qui ne sont ni des messages d’états, ni des messages d’événements. Les messages échangés au moyen de ce troisième canal comprennent par exemple des données indicatives d’éventuels problèmes ayant survenu lors de la détection d’éléments physiques, d’une mise en pause volontaire de l’application « CAMERA », etc. En particulier, un premier canal C_8010 est établi pour permettre la communication d’états de jeu d’éléments physiques via un port 8010, et un deuxième canal C_8011 est établi pour permettre la communication d’évènements de jeu via un port 8011. De manière non limitative, d’autres ports que les ports 8010 et 8011 peuvent être utilisés. Les états de jeu des éléments physiques sont ainsi mis à jour par l'application « CAMERA » au cours de cycles de calculs successifs, avant d’être envoyés vers l’application « SCREEN ». De préférence, ces états de jeu sont transmis à intervalles réguliers, par exemple tous les quatre cycles successifs. En variante, la transmission de ces états est mise en œuvre lorsque ceux-ci sont modifiés, ce qui permet d’optimiser la consommation énergétique du premier module ou de tout autre dispositif sur lequel est installée l’application « CAMERA ». Par exemple, si un pion n’est pas manipulé par un utilisateur, il n’est pas nécessaire de transmettre l’état de jeu correspondant. Avantageusement, ceci permet de réduire le volume de données échangées d’un facteur 100 à 400, ce qui augmente la rapidité de la virtualisation. Les états de jeu sont généralement des objets au format JSON, convertissables en messages envoyés par le composant TCP_SDR sur le canal C_8011. Le composant TCP_REC les décode ensuite pour mise en œuvre des étapes suivantes de la virtualisation. La communication d’évènements de jeu via le deuxième canal C_8011 est mise en œuvre de sorte que ceux-ci soient transmis du module M1 au module M2 de manière unitaire. Chaque évènement est ainsi envoyé par l'application « CAMERA sous la forme d’un objet JSON qui est converti en un message, par exemple sous la forme d’un tableau de bits, et reçu par le composant TCP_REC de l'application « SCREEN » pour décodage ultérieure. Une fois que les messages envoyés par l'application « CAMERA » ont été reçus et traités par l'application « SCREEN », celle-ci construit dans l’espace virtuel JV une représentation digitale fidèle du jeu dont les images ont été captées dans l'espace physique JS. L’application « SCREEN » met ensuite en œuvre une traduction, cette traduction comprenant une conversion de cette représentation digitale de l'espace physique JS en éléments virtuels de l'espace virtuel JV. Ainsi, il est possible d'associer chaque état « PlayerState » contenu dans la liste « GamePlayerState » à l'élément virtuel correspondant à un élément physique donné. Tout comme les états de jeu et les évènements de jeu, l’environnement PG définissant l’équivalent digital du plateau de jeu GB dans l’espace virtuel JV est construit par l’application « SCREEN » du deuxième module M2 à partir de données fournies par l’application « CAMERA » du premier module M1. En particulier, une définition de l’environnement PG, c’est-à-dire de l’aire de jeu, peut être communiquée au moyen d’un objet JSON appelé objet « BoardMap », cet objet comprenant l'ensemble des éléments permettant de définir la zone de jeu, par exemple matérialisés sous la forme d'une liste. Cet objet peut définir différentes zones, appelées « BoardZone », de l’environnement PG, enrichi des contraintes de déplacements associées à chacune de ces zones. En particulier, l’objet « BoardMap » est fourni par l’application « SCREEN », celui-ci définissant indirectement la structure du jeu, que ce soit le plateau de jeu dans l’espace physique JS ou l’environnement correspondant dans l’espace virtuel JV, qui sont cohérents entre eux. Par ailleurs, l’application « CAMERA » n’a pas nécessairement besoin de disposer des informations contenues dans l’objet « BoardMap », seules les définitions des états relatifs au repère du plateau de jeu GB lui étant nécessaires. La traduction est mise en œuvre par l’application « SCREEN ». qui est en outre configurée pour vérifier les contraintes définies entre les éléments physiques de l’espace physique JS et leurs correspondants virtuels dans l’espace virtuel JV. De préférence, une zone « BoardZone » comprend en outre des données de position telles qu’une position « EnvPosition » associée, la position « BoardPosition » de la tuile correspondante du plateau de jeu GB, des définitions de l'ensemble des zones contribuant à l'environnement PG, des correspondances entre les zones de l'environnement PG jeu et les tuiles du plateau GB, des contraintes de déplacements d’éléments physiques entre plusieurs zones, une liste de points ou de zones d'intérêts, etc. Il est maintenant fait référence à la figure 11, qui illustre un dispositif adapté pour mettre en œuvre le procédé de virtualisation décrit selon les exemples décrits précédemment. Le dispositif 1000, qui est de préférence un circuit intégré, est compris dans le premier module M1 et/ou dans le deuxième module M2. Le dispositif 1000 comprend un espace 1002 de stockage, par exemple une mémoire MEM, et une unité 1004 de traitement équipée par exemple d'un processeur PROC. L’espace 1002 de stockage est par exemple une mémoire non volatile (ROM ou Flash, par exemple), et peut constituer un support d’enregistrement, ce support d’enregistrement pouvant en outre comprendre un programme d’ordinateur. Lorsqu’il constitue un support d’enregistrement, l’espace 1002 de stockage peut être lu par l’un quelconque des modules M1 et M2. Le dispositif 1000 comprend en outre un module de communication permettant audit dispositif de se connecter à un réseau local, par exemple au réseau NET, et d'échanger des données avec d'autres dispositifs par l'intermédiaire dudit réseau local. Par exemple, le module de communication peut être une interface réseau Wifi ou Ethernet, ou encore un module de communication Bluetooth. Le module de communication du dispositif 1000 comprend un module 1006 de réception de données, par exemple un récepteur IN, et un module 1008 d’émission de données, par exemple un émetteur OUT. Le module 1006 est configuré pour recevoir une demande de connexion ou de déconnexion du dispositif 1000 en provenance de tout autre dispositif électronique. En particulier, le module 1006 est configuré pour recevoir une requête RQ ou des messages parmi ceux décrits précédemment. Le module 1008 est configuré pour émettre des demandes de connexion vers tout type de dispositif électronique, par exemple l’un des modules M1 et M2, une caméra ou encore un écran d’affichage. L’espace 1002 de stockage, qui peut être sécurisé, est configuré pour enregistrer et stocker toute donnée lue par le module 1006, traitée par l’unité 1004 et/ou envoyée par le module 1008. L'unité 1004 de traitement, qui peut être pilotée par un programme, est configurée pour mettre en œuvre le procédé de virtualisation selon l’un ou l’autre des exemples précédemment décrits. À l'initialisation, les instructions d’un programme pilotant l’unité 1004 de traitement, sont par exemple chargées dans une mémoire vive (RAM, par exemple) non représentée que comprend le dispositif 1000 avant d'être exécutées par le processeur de l'unité 1004 de traitement. En particulier, lorsque le dispositif 1000 est intégré au premier module M1, l’unité 1004 de traitement est configurée pour mettre en œuvre des étapes de capture d’une image d’un espace physique, d’analyse de l’image capturée pour déduire un état physique d’au moins un élément physique, tandis que le module de communication du dispositif 1000 est configuré pour mettre en œuvre une étape de transmission, vers un autre module, via ledit réseau local, de messages comprenant par exemple un état physique déduit de l’au moins un élément physique. Lorsque le dispositif 1000 est intégré au deuxième module M2, le module de communication que celui-ci comprend est configuré pour recevoir de tels messages. En outre, l’unité 1004 de traitement est configurée pour mettre en œuvre une étape de génération, sur réception d’un état physique, d’une représentation virtuelle de l’espace physique, de sorte que ledit espace virtuel comprend un élément virtuel respectif pour l’au moins un élément physique, et une étape d’attribution, à cet élément virtuel, d’un état virtuel représentatif de l’état physique de l’élément physique respectif. Différents aspects et caractéristiques décrits ci-dessus peuvent être mis en œuvre ensemble, ou séparément, ou bien substitués les uns aux autres, et l’ensemble des différentes combinaisons et sous combinaisons des aspects et caractéristiques font partie de la portée de l’invention. En outre, il se peut que certains systèmes et équipements décrits ci-dessus n’incorporent pas la totalité des éléments et fonctions décrits pour les modes de réalisation préférés. L’invention ne se limite pas aux exemples de systèmes, procédés, terminaux, serveurs, unités de traitement de données, supports d’enregistrement et programmes 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. Système de virtualisation pour plateau de jeu (GB), le système de virtualisation comprenant un premier module (M1) et un deuxième module (M2), lesdits modules étant connectés entre eux au moyen d’un réseau local (NET), le premier module (M1) étant adapté pour - capturer (110) une image d’un espace physique (JS) correspondant audit plateau de jeu (GB) et comprenant au moins un pion (P1) ; - analyser (120) l’image capturée pour déduire un état physique dudit au moins un pion ; - transmettre, au deuxième module (M2), via ledit réseau local (NET), l’état physique déduit de l’au moins un pion (P1), le deuxième module étant adapté pour : - générer (220), sur réception (210) de l’état physique transmis, une représentation virtuelle (JV) de l’espace physique (JS), formant un espace virtuel, de sorte que ledit espace virtuel comprend un élément virtuel respectif (P1’) pour l’au moins un pion (P1) ; et - attribuer (230), audit élément virtuel, un état virtuel représentatif de l’état physique de l’au moins un pion respectif. Système de virtualisation selon la revendication 1, dans lequel l’état physique, respectivement l’état virtuel, comprend au moins l’un parmi un identifiant, un attribut de détermination, une position physique dans l’espace physique (JS), respectivement une position virtuelle dans l’espace virtuel, et une orientation physique par rapport à l’espace physique (JS), respectivement une orientation virtuelle par rapport à l’espace virtuel. Système de virtualisation selon l’une quelconque des revendications précédentes, dans lequel le deuxième module (M2) est en outre adapté pour fournir à un dispositif tiers connecté au deuxième module (M2), sur attribution dudit état virtuel à l’élément virtuel, un affichage de la représentation virtuelle générée. Système de virtualisation selon l’une quelconque des revendications précédentes, dans lequel l’état physique de l’au moins un pion (P1) est renseigné par un marqueur visuel (Mi1) disposé sur ledit pion, ledit marqueur visuel comprenant au moins l’un parmi une image, un code barre linéaire, un code barre matriciel et un marqueur composite. Système de virtualisation selon l’une quelconque des revendications précédentes, dans lequel le plateau de jeu (GB) est une surface plane comprenant une pluralité de cellules adjacentes définissant des éléments physiques respectifs du plateau de jeu. Système de virtualisation selon l’une quelconque des revendications précédentes, dans lequel l’élément virtuel respectif de l’au moins un pion (P1) est configuré pour être déplaçable de manière contrainte dans l’espace virtuel en fonction d’un déplacement dudit au moins un pion respectif dans l’espace physique. Système de virtualisation selon l’une quelconque des revendications précédentes, dans lequel l’élément virtuel respectif de l’au moins un pion (P1) est un bouton de commande, ledit bouton de commande étant configuré pour déclencher un évènement dans l’espace virtuel en fonction d’une interaction d’un utilisateur avec le pion respectif dans l’espace physique. Système de virtualisation selon l’une quelconque des revendications précédentes, dans lequel la génération de l’espace virtuel comprend détecter une position physique relative et/ou une orientation physique relative de l’au moins un pion (P1) par rapport au plateau de jeu (GB). Système de virtualisation selon l’une quelconque des revendications précédentes, dans lequel l’analyse de l’image capturée comprend détecter une position physique relative de l’au moins un pion (P1) par rapport au plateau de jeu (GB) et projeter ladite position détectée sur un plan du plateau de jeu (GB) et selon une direction anti-normale au plateau de jeu (GB), la transmission, au deuxième module (M2), via ledit réseau local (NET), de l’état physique déduit de l’au moins un pion (P1) comprenant ladite position projetée. Système de virtualisation selon l’une quelconque des revendications précédentes, dans lequel la transmission de l’état physique déduit est mise en œuvre au moyen d’un échange d’un message du premier module (M1) au deuxième module (M2) via un canal de communication TCP du réseau local (NET), ledit message comprenant l’état physique sous la forme d’un format JSON. Système de virtualisation selon l’une quelconque des revendications précédentes, dans lequel le premier module (M1) est un dispositif d’enregistrement vidéo d’un téléphone mobile. Système de virtualisation selon l’une quelconque des revendications précédentes, dans lequel le deuxième module (M2) est un processeur d’un dispositif électronique, ledit dispositif électronique comprenant un écran d’affichage connecté audit processeur, l’écran d’affichage étant adapté pour recevoir, du processeur, la représentation virtuelle générée et afficher, en temps réel, ladite représentation virtuelle. Procédé de virtualisation pour plateau de jeu (GB), ledit procédé étant mis en œuvre par un premier module (M1) et un deuxième module (M2) connectés entre eux au moyen d’un réseau local (NET), le procédé comprenant: - capturer (110), avec ledit premier module (M1), une image d’un espace physique (JS) comprenant audit plateau de jeu (GB) et comprenant au moins un pion (P1); - analyser (120), avec le premier module (M1), l’image capturée pour déduire un état physique dudit au moins un pion (P1); - transmettre (130), avec le premier module (M1), au deuxième module (M2), via ledit réseau local (NET), l’état physique déduit de l’au moins un pion (P1); - générer (220), avec le deuxième module (M2), sur réception (210) de l’état physique transmis, une représentation virtuelle (JV) de l’espace physique (JS), formant un espace virtuel, de sorte que ledit espace virtuel comprend un élément virtuel respectif (P1’) pour l’au moins un pion (P1) ; et - attribuer (230), avec le deuxième module, audit élément virtuel, un état virtuel représentatif de l’état physique de l’au moins un pion respectif. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon la revendication précédente, lorsque lesdites instructions sont exécutées par un processeur d’un circuit de traitement informatique. Pion (P1) pour plateau de jeu (GB) adapté pour qu’un état physique dudit pion (P1) soit déductible d’une analyse, par un module (M1), d’une image capturée d’un espace physique (JS) correspondant audit plateau de jeu (GB), le plateau de jeu (GB) comprenant le pion (P1), la capture de l’image étant mise en œuvre par ledit module, l’état physique du pion (P1) étant renseigné par un marqueur visuel (Mi1) disposé sur le pion.