Comme nous pouvons le voir, ces lignes de force soulignent l'anatomie et les déformations du personnage (Figure 73) et reposent sur un certain nombre de règles et structures de bases conseillées. L'une des plus importantes est la gestion des triangles et des quadrilatères concaves qui cassent l'écoulement du maillage « flow ».
(Figure 74)

<figure><img src="image_77.png" /><figcaption>Figure 74 : l'utilisation de triangle casse l'écoulement du maillage</figcaption></figure>

C'est donc en tenant compte de contraintes à la fois esthétiques et algorithmiques que les artistes numériques ont développé un savoir empirique permettant de structurer leur géométrie. Celle-ci porte sur les lignes de force qui sous-tendront la déformation du maillage (Figure 75).

<figure><img src="image_78.png" /><figcaption>Figure 75 : test de déformation faciale</figcaption></figure>
### 2.2.2.2 Mixage de forme, expression faciale et modélisation

Je vais ici me focaliser un peu plus sur la modélisation du visage. Ce dernier doit posséder une flexibilité particulièrement développée afin de pouvoir afficher des expressions convaincantes. Les méthodes de modélisation sont multiples et dénotent là encore de ce que je pourrais appeler la débrouillardise et le pragmatisme des artistes numériques, car beaucoup d'entre elles reposent sur un détournement ou une réinterprétation d'opérations mathématiques.

L'une des principales méthodes, le morphing de forme (ou blendshape, ou morphtarget), se fonde sur un principe simple qui consiste à avoir deux maillages avec la même **topologie** et le même nombre de polygones afin d'obtenir un troisième maillage à partir d'une moyenne pondérée, vertex par vertex, des points qui composent la forme (Figure 76). Il faut donc modéliser une forme neutre (comme toujours) puis des déformations possibles de chaque partie. Il existe différentes approches pour la création de ces déformations possibles : la première est de penser les formes locales pouvant se combiner ou alors les expressions plus globales comme, par exemple, une expression de joie ou de douleur.

Il suffit donc de créer les formes des différentes expressions et de les combiner pour pouvoir créer les expressions que nous voulons. Si, encore actuellement, la création de ces formes est une opération manuelle reposant sur le talent des artistes, des chercheurs essayent d'automatiser ce processus (Akimoto, Suenaga, et Wallace 1993). J'ai utilisé cette méthode pour créer mes expressions pour *Between the lines* (Plessiet et Passedouet 2007) où j'ai modélisé les phonèmes A E<fnref n="1" /> I, les fermetures des yeux et quelques moues supplémentaires.

<figure><img src="image_79.png" /><figcaption>Figure 76 : la forme neutre en bleu, les formes de blendshapes autour et le résultat de la combinaison du blendshape en rouge</figcaption></figure>

<footnote n="1">¹ J'utilisais la même forme de bouche pour le O et le U</footnote>
## Partie 2 Sculpture Matrice

Le *Facial Action Coding System* (FACS) issu des travaux de du psychologue spécialiste des émotions Ekman (Ekman et Friesen 1978) repose sur une liste finie de formes de base, les Action Unit (AU)<fnref n="1" /> auquelles on associe une intensité (Figure 77). Les artistes numériques peuvent donc construire ces différentes formes qui en théorie peuvent, en se combinant, exprimer toutes les émotions humaines jusqu'à intégrer la notion de micromouvement dans leur animation. Il existe bien sûr d'autres formes de système d'encodage des expressions faciales, comme le Face Modeling Language (Arya et DiPaola 2007) qui repose sur des fichiers xml, ou le système AMA (Magnenat-Thalmann, Primeau et Thalmann 1988) qui fut utilisé par les époux Thalmann sur le film *Rendez-vous à Montréal*. Actuellement, le système FACS semble avoir la préférence des professionnels

<figure><img src="image_80.png" /><figcaption>Figure 77 : quelques combinaisons de FAU (Campbell 2014)</figcaption></figure>

Mais modéliser toutes les expressions de base (une cinquantaine) pour chaque visage est une tâche longue et fastidieuse pour un artiste indépendant. J'ai donc développé ces formes uniquement sur les personnages qui servent de point de départ à ma modélisation et je génère les nouvelles formes en ajoutant la différence entre le maillage de ma doublure numérique et le maillage neutre que j'ajoute à l'ensemble de mes formes FAU (Figure 78). Ceci me permet de générer l'ensemble des expressions nécessaires à la création de mes expressions, malheureusement ce n'est qu'un travail préparatoire qui nécessite un travail de retouche.

<footnote n="1">¹ Dans notre domaine, nous portons notre intérêt sur les 46 formes de base</footnote>
<figure><img src="image_81.png" /><figcaption>Figure 78 : retargetting des FAU d'un maillage de base à un scan projeté sur un maillage de base</figcaption></figure>

Pour l'installation *autoportrait à l'écran*, mon double virtuel n'exprimant que peu d'émotion faciale, j'ai essayé de scanner directement les FAU utiles pour les retravailler individuellement. Si les formes obtenues gagnent en réalisme, ceci entraîne un coût rédhibitoire en temps et en disponibilité du modèle. De plus, un certain nombre de FAU sont difficilement numérisables. Paradoxalement, en cherchant à donner une potentialité de mouvement, ne sommes-nous pas en train de tomber sur une
problématique consistant à multiplier les sculptures spécifiques dans une immense combinatoire ?

### 2.2.2.3 De l'armature au simulacre bio mécanique

Pour pouvoir modifier de manière plus globale le corps d'un personnage, nous utilisons depuis les années 80 des systèmes basés sur le principe des « *Joint Dependent Local Deformation* » afin de créer des « squelettes articulés » (Gourret, Magnenat-Thalmann et Thalmann 1989). Cette technique avait permis, dès 1987, d'animer des doublures numériques une de Marilyn Monroe et une autre de Humphrey Bogart pour le film *Rendez-vous à Montréal* (Magnenat-Thalmann et Thalmann 1987).

Les méthodes implémentées dans les logiciels 3D ont peu évolué, le travail s'étant déporté non pas sur l'utilisation de joints symbolisant l'armature déformante<fnref n="1" />, mais plutôt sur le fait d'obtenir une déformation plus cohérente. Je note en particulier les travaux sur le skinning implicite (Vaillant et al. 2013 ; Turchet, Fryazinov et Romeo 2015) qui bien que n'étant pas encore implémentés dans les logiciels 3D, présenteraient une avancée notable dans la déformation des personnages.

Même si ces principes permettent une mise en pose efficace du personnage, je suis néanmoins toujours surpris par l'aspect illogique d'un tel système quand on le compare au fonctionnement bio mécanique réel. En effet, ce ne sont pas nos os qui, en bougeant déforment la peau, mais nos muscles qui en s'actionnant la déforment et font mouvoir nos os.

Ceci entraîne des aberrations anatomiques amusantes, je pense par exemple à l'ajout « d'os » pour contrôler la poitrine des femmes et les masses graisseuses de personnages obèses, ou les déformations complexes comme nous pouvons les rencontrer pour simuler les déformations générées par les mouvements de la clavicule et de l'omoplate. Pour obtenir des déformations plus correctes, en particulier pour les fesses et les cuisses lorsque la jambe est repliée, ou les plissements de certaines zones du visage, nous pouvons avoir recours à des mixages de formes comme décrit en 3.2.2.2 dont l'intensité est contrôlée par la rotation des joints.

<footnote n="1">¹ Ce que d'ailleurs beaucoup de logiciels désignent sous le terme d'os (bones) et de squelette (skeletal),</footnote>
Cette méthode de déformation permet un contrôle fin de la forme finale. C'est pourquoi il devient de plus en plus courant d'utiliser, en plus des *blendshapes* de visages, une structure de joints afin de garantir une mobilité excellente des différentes zones de la tête. C'est d'ailleurs cette méthode que j'utilise depuis 2016 pour les déformations du visage.

Les logiciels du commerce ont très récemment intégré des systèmes musculaires, mais ces derniers n'agissent toujours pas comme des « muscles qui contrôlent les os et déforment la peau », mais comme des intermédiaires contrôlés par les os pour déformer plus correctement la peau. Les muscles, dans ces situations, sont plus des simulacres qui ont pour mission de faire croire, en se gonflant ou s'étirant, à l'existence d'un véritable système musculaire. Notre sculpture peut être mise en position avec à la fois un certain degré de contrôle et une « impression » de réalisme et peut donc exprimer une possibilité de mouvement.

### 2.2.3 Une sculpture matrice

Comme nous l'avons décrit auparavant, cette sculpture est cependant dépourvue d'expression et sa position est tout sauf expressive. Pour cela, L'étape de rigging – qui consiste à créer une armature d'animation<fnref n="1" /> – est assez symptomatique du rapport étrange que l'artiste numérique nourrit entre réel et virtuel, simulation et simulacre.

Si de prime abord une sculpture-matrice doit disposer d'un rig pour se mouvoir, je conçois également cette sculpture-matrice comme un réceptacle pour accueillir un système complexe qui permettra à cette dernière d'évoluer à un nouveau stade conceptuel, où interviendraient aussi bien un processus décisionnel qu'une activité motrice.

<footnote n="1">¹ Je préfère le terme architecture (au sens informatique du terme) à armature, même si je suis conscient de la portée de ce mot, car elle consiste en l'assemblage de structure spécifique prise par l'artiste technicien en vue de résoudre une problématique spécifique</footnote>
### 2.2.3.1 Au-delà du figé

C'est en visionnant le film « Le grand cirque de Calder » (Painlevé et al. 1955) sur cette œuvre cinétique de 1927 (Figure 79), que j'ai pris conscience du lien fort unissant mon travail à l'art cinétique : mon travail a ceci de commun avec la sculpture cinétique qu'il révèle son potentiel expressif dans le mouvement et dans l'interaction. Je crois que c'est aussi en grande partie l'aspect ludique de l'œuvre de Calder qui a trouvé le plus d'écho en moi.

<figure><img src="image_82.png" /><figcaption>Figure 79 : le grand cirque de Calder (Painlevé et al. 1955)</figcaption></figure>

Sans mouvement, l'œuvre cinétique perd une partie de son intérêt, car elle est créée pour se mouvoir. Il en est de même pour ma perception de l'art numérique : si mes créatures ne bougent pas, alors nous ne pouvons pas savourer la complexité de l'œuvre.

Si Uli Aschenborn ne se revendique pas spécifiquement artiste cinétique, certaines de ces œuvres ont une énorme influence sur mon travail personnel, en particulier Ovahimba dessin vivant (2009) (Figure 80). Ce visage de jeune femme africaine dont les yeux suivent le spectateur, fait écho à certaines de mes créations dans lesquelles le modèle suit les spectateurs du regard. C'est pourquoi je me sens proche à la fois de la mouvance hyperréelle, des suréalistes et des cinétique. Je porte mon intérêt à créer un « double autre » de personnes existantes et par là même à interroger la réalité, que j'ancre dans une bulle de plausibilité autre, puis que j'interroge en le considérant comme une œuvre interagissante, ludique et en mouvement.
<figure><img src="image_83.png" /><figcaption>Figure 80 : Ovahimba de Uli Aschenborn</figcaption></figure>

Là où Uli Aschenborn utilise le mouvement du spectateur pour animer son œuvre (qui finalement est passive), je voudrais que mon œuvre agisse par elle-même, le spectateur n'étant, après tout, qu'un stimulus extérieur, auquel elle peut, ou non, réagir. Ceci induit qu'il faut la doter de mécanismes décisionnels, la sculpture numérique n'étant pour finir qu'une forme ayant pour vocation de devenir autre chose. C'est pourquoi j'appelle cette sculpture une **Sculpture Matrice**.

### 2.2.3.2 Enveloppe et mécanisme interne ?

Je conçois cette **sculpture numérique** comme une enveloppe vide dans laquelle nous allons placer un ensemble de mécanismes logiques et moteurs qui vont lui donner vie. Ces mécanismes n'ont pas vocation à être visibles, car je ne cherche pas à montrer comment ni pourquoi la sculpture numérique bouge. Il y a en réalité une réelle séparation entre enveloppe numérique et mécanismes de contrôle. C'est d'ailleurs en pensant à une certaine interchangeabilité modulaire que je conçois à la fois mes corps et mes contrôleurs. C'est l'une des raisons qui m'ont poussé à adopter une telle architecture dans la construction de ma **bibliothèque de programmation AKeNe**.

Cette approche de module décisionnel interconnecté a été fortement marquée par la manière dont Marvin Minsky présentait l'intelligence artificielle (Minsky 1988). Même si je reconnais que ce modèle est daté, surtout lorsque l'on voit les courants
d'intelligence artificielle actuels. Mais nous detaillerons cet aspect plus loin dans cet essai.

Je vois aussi un lien fort avec la conception hindouiste de l'avatar et de cette enveloppe numérique, à savoir un véhicule qui doit être habité par une entité manipulatrice. Cette entité peut être humaine, ou purement artificielle. Mais quoi qu'il en soit, nous avons bien une séparation entre entité manipulée et entité manipulatrice. Je remarque, d'ailleurs que le **moteur de jeu Unreal** adopte au passage, une logique assez similaire dans sa manière de concevoir les différentes entités qui composent le niveau de jeu, puisqu'il fait la différence entre les enveloppes et les entités manipulatrices qui prennent le contrôle de ces enveloppes. La différence est moins claire dans le moteur de jeu **Unity**, mais rien n'empêche d'adopter cette même philosophie

Ceci est suffisamment notable pour souligner qu'une telle architecture séparant corps et esprit va à l'encontre de ce que les sciences cognitives ont observé dans la réalité où le schéma corporel et le mécanisme décisionnel sont étroitement liés (Berthoz 2013 ; Varela 1989). Il faudrait, si nous voulions nous rapprocher d'une véritable simulation, imaginer la création du processus moteur et de l'enveloppe en parallèle, en imaginant une co évolution et une cocréation à la manière des travaux de Karl Sims (Sims 1994), qui utilisaient un algorithme génétique pour créer à la fois l'enveloppe et son mécanisme interne (réseau de neurones). Ce sont d'ailleurs des problématiques que nous évoquerons au chapitre 5.1.1.3.

Mais ma priorité n'est pas, là encore, de simuler un fonctionnement scientifiquement correct, mais plutôt de créer une interaction sensible qui fait croire que cette enveloppe vit en « jouant les symptômes de la vie ». Bref, l'enveloppe est un rôle, le contrôleur un acteur qui l'interprète.

### 2.2.3.3 De l'enveloppe à la sculpture matrice

C'est cette association corps/esprit qui me fait considérer cette **Sculpture Matrice** comme le réceptacle pour générer quelque chose d'autre. Je définis ainsi une **Sculpture Matrice**, comme un moule qui donnera vie à une nouvelle entité qui sera la combinaison d'une enveloppe, du processus moteur et du processus décisionnel.
## Partie 2 Sculpture Matrice

Ceci conforte encore davantage le fait qu'il faut penser la sculpture numérique comme une étape d'ouverture vers cet « autre chose » et non pas comme une finalité à l'image de la sculpture réelle. C'est pourquoi elle se doit d'offrir une potentialité de mouvement dépourvu d'intention.

Je dois ici revenir sur la notion d'intention, car le simple acte de créer une forme dénote une intention de l'artiste qui « typera » la **Sculpture Matrice** dans une potentialité d'action spécifique, or il s'agit ici de ne pas entraver l'évolution possible de l'entité dans toute sa plausibilité. Il est donc tout à fait cohérent d'interdire tel ou tel mouvement par des contraintes biomécaniques, car ceci entraînerait une perte de la plausibilité de l'entité.
3 Marionnette Virtuelle
La sculpture-matrice est une enveloppe vide, conçue à la fois sur des critères esthétiques et sur une possibilité de mouvements n'attendant qu'à s'exprimer, mais dans l'impossibilité de le faire par elle-même. Ainsi, si nous voulons qu'elle puisse prendre une pose, il nous faut réfléchir à un système manipulatoire.

Ce système manipulatoire peut être de formes multiples. Et nous nous intéresserons dans cette partie, à la plus simple d'entre elles, à savoir le recours à un manipulateur externe, faisant de notre sculpture matrice, une **Marionnette Virtuelle**.

## 3.1 Marionnette et marionnettiste

Notre sculpture-matrice est finalisée. Elle contient en elle-même une potentialité de mouvement qui, pour s'exprimer, doit disposer d'un mécanisme actionneur. Nous allons commencer par nous intéresser au cas le plus simple, où la décision de mouvement et le mouvement ne proviennent pas de l'entité.

Dans cette approche, les deux phénomènes — décision et mouvement — se produisent à l'extérieur de la créature virtuelle. La **Marionnette Virtuelle** n'est qu'un véhicule pour un marionnettiste qui est à la fois à l'origine du mouvement et à l'origine de la décision de ce mouvement. Une telle approche retire à l'entité virtuelle toute capacité kinesthétique et cognitive, en les reportant sur un tiers. Il se crée donc un binôme marionnette/marionnettiste qu'il convient d'étudier. Comment s'effectue la manipulation ? Comment se ressent la manipulation d'un « autre corps » du point de vue du manipulateur ?

### 3.1.1 De la sculpture matrice au binôme
**marionnette/marionnettiste**

Sans l'intervention du marionnettiste, le pantin reste immobile, sans vie. Mais cette dépendance n'est pas uniquement dans le sens **Marionnette/Marionnettiste** : en effet, le manipulateur s'il veut « exister » sur le plan virtuel de la **Marionnette Virtuelle** n'a pas d'autre choix que de la manipuler. Il se crée ainsi une interdépendance : la **Marionnette Virtuelle** ayant besoin du marionnettiste pour se mouvoir, le
marionnettiste ayant besoin de la **Marionnette Virtuelle** s'il veut agir dans le monde virtuel.

### 3.1.1.1 Un mouvement extérieur à l'entité virtuelle

Un pantin articulé a lui aussi une potentialité de mouvement. Il peut prendre une certaine pose, mais pour cela quelqu'un doit manipuler ses membres. Un tel dispositif fonctionne donc de manière très analogue au théâtre de marionnettes : un marionnettiste par manipulation d'un squelette articulé, transfert un mouvement à une marionnette (Figure 81).

<figure><img src="image_84.png" /><figcaption>Figure 81 : Une marionnette à fils et ses marionnettistes (source wikipedia)</figcaption></figure>

Nous pouvons le mettre en position, mais le contrôle ne sera pas forcément aisé. Le pantin devient marionnette à partir du moment où on va l'équiper d'un certain nombre de mécanismes pour le manipuler aisément. Les mécanismes sont divers et spécifiques à la marionnette, ainsi une marionnette à gaine se présente comme un gant dans lequel le marionnettiste glisse sa main, la marionnette à tige dont les mains
sont contrôlées par des baguettes en fil de fer rigide, la marionnette à fils où les pantins sont suspendus à des fils par plusieurs points d'attache et que l'on manipule via une des croix d'attelle. Ainsi, chaque marionnette exige du marionnettiste l'apprentissage de son mécanisme spécifique de manipulation.

Il en est de même pour ce que j'appelle la **Marionnette Virtuelle** : notre Sculpture Matrice, équipée d'un certain nombre de mécanismes, est en mesure d'être manipulée par une entité extérieure. Cette entité extérieure peut être constituée d'un ou de plusieurs manipulateurs humains ou encore d'un processus informatique. Ce qu'il est important de comprendre, c'est que ce processus se déroule hors de la **Marionnette Virtuelle**.

Le processus est à peu près équivalent, que nous soyons dans une optique **temps réel** ou **précalculé**, à savoir celui d'un personnage extérieur qui manipule un pantin. Mais comme nous le décrirons plus tard, le rapport au temps est différent, puisque l'un manipule en direct, alors que l'autre manipule dans un rapport au temps différent.

Il s'agit de créer une armature puis un ensemble de « contrôleurs » c'est-à-dire d'outils de manipulation qui opèrent comme une « interface » et qui sont destinés à faciliter la mise en position du personnage sans avoir à sélectionner un par un les éléments de l'armature. Le processus de création de cette interface de contrôleurs, dont certains peuvent être très complexes, s'appelle le **rigging** (Figure 82).

Si le **rigging** facilite beaucoup l'animation de notre **Marionnette Virtuelle**, il réduit en contrepartie le nombre de paramètres influençables et limite donc les possibilités de mouvements. Il y a alors un compromis à trouver entre facilité et liberté de mouvement.
<figure><img src="image_85.png" /><figcaption>Figure 82 : Rig simple FK/IK pour la doublure numérique d'Audrey Payelle pour Arpege</figcaption></figure>

Le manipulateur a une position particulière : il décide du mouvement qu'il va transmettre à la **Marionnette Virtuelle** dans un cadre contraint par le rig et avec un point de vue externe, puis il manipule cette interface intermédiaire pour essayer de mettre son personnage en position.

### 3.1.1.2 Une décision extérieure à l'entité virtuelle

Ce point de vue d'observateur/manipulateur est fondamental : il a été l'objet de plusieurs articles rédigés avec Georges Gagneré(Gagneré, Plessiet et Sohier 2018 ; Gagneré et Plessiet 2018, 2017). Ce marionnettiste à l'origine du mouvement est extérieur à la marionnette, dans le sens où il ne l'incarne pas.

Cette position externe conditionne la prise de décision, car elle se fait avec les informations collectées par le manipulateur d'un point de vue extérieur. Les sens sont tronqués, la kinesthésie est absente, ce qui entraîne un biais dans le mécanisme décisionnel. Le manipulateur doit donc tenir un raisonnement particulier et plus les mécanismes de manipulation sont complexes, plus le biais sera marqué. Nous
comprenons donc que l'embodiement (l'incarnation) aura un impact significatif sur le contrôle de la **Marionnette Virtuelle**<fnref n="1" />.

Comme la manipulation se fait via un mécanisme, il y a une séparation entre le raisonnement (ce que j'imagine obtenir comme mouvement) et le système moteur (les mécanismes que je dois actionner pour obtenir ce mouvement). Le marionnettiste, surtout s'il est humain, doit donc -être en mesure d'effectuer un travail décisionnel complexe, réalisé en adoptant un point de vue externe à la **Marionnette Virtuelle**.

Je peux donc définir la **Marionnette Virtuelle** comme un « pantin virtuel ne disposant pas de capacité décisionnelle et manipulé de l'extérieur par une entité autre. Celle-ci n'est donc la source ni de sa décision ni de son mouvement qui sont d'origine externe » (Figure 83).

<figure><img src="image_86.png" /><figcaption>Figure 83 : Positionnement de la Marionnette Virtuelle par rapport à l'origine de la décision et du mouvement</figcaption></figure>

### 3.1.1.3 Une interdépendance marionnette/marionnettiste

Il s'ensuit que la marionnette doit avoir un marionnettiste pour s'animer. En l'absence de ce marionnettiste, elle ne bougera pas. Paradoxalement, le marionnettiste a besoin de la marionnette s'il veut « un corps dans ce monde virtuel » : on se retrouve ici complètement dans la logique de l'avatar décrit par la religion hindouiste (Bassuk 1987), « avatâra » se traduisant par « descente » en sanskrit : il s'agit d'une incarnation divine, un véhicule emprunté par une entité supérieure pour aller sur terre. Ce sont dans leurs grandes majorités des incarnations divines partielles,

<footnote n="1">¹ Nous détaillerons plus amplement ceci en 3.2.2</footnote>
seul *Krisna* est un avatar complet de *Vishnou*. Car *Krisna* est lui aussi un Dieu disposant des mêmes possibilités d'actions que *Vishnou*

Chaque incarnation sous-entend l'acceptation d'une perte de niveau de contrôle de mouvement, entre la transition corps réel/corps virtuel : il va falloir bouger par l'intermédiaire du corps d'un autre et donc avec sa potentialité de mouvement. Le processus décisionnel reste intact. Quand *Vishnou* s'incarne dans *Masya le poisson*, il conserve sa réflexion divine, mais se retrouve avec la potentialité de mouvement d'un poisson.

L'acceptation d'un changement de potentiel de mouvement se fait au regard d'une intéressante contrepartie : ce corps virtuel manipulé est le seul intermédiaire possible pour que l'entité extérieure puisse entrer en interaction avec le monde virtuel. La **Marionnette Virtuelle** devient alors, de façon évidente, une « forme de compromis » entre deux possibilités de mouvements : celle contenue dans la sculpture matrice et celle du manipulateur, par l'intermédiaire du mécanisme, le rig dans le cas de l'image de synthèse. Mais c'est aussi le médium par lequel le manipulateur peut entrer en interaction avec le monde virtuel.

C'est donc une interdépendance marionnette/marionnettiste qui se crée : la **Marionnette Virtuelle** ne pouvant se mouvoir que par l'intermédiaire du marionnettiste et le marionnettiste ne pouvant entrer en interaction avec le monde virtuel que par cette enveloppe articulée.

## 3.1.2 De la transposition du mouvement

Il y a donc le transfert d'un mouvement du manipulateur vers la **Marionnette Virtuelle**. En effet, une action du manipulateur déclenche une réponse de la **Marionnette Virtuelle**. Après avoir défini ce qu'est pour nous une **Marionnette Virtuelle** et le couple marionnette/marionnettiste, nous allons nous intéresser à la transposition du mouvement du marionnettiste vers la **Marionnette Virtuelle**. Comment s'effectue la manipulation de la **Marionnette Virtuelle** ? Les manipulations sont-elles toutes perceptibles ? Et la manipulation en elle-même peut-elle être vue comme un transfert de mouvement du marionnettiste à la **Marionnette Virtuelle** ? Ou,
au contraire avons-nous affaire à une réinterprétation par la **Marionnette Virtuelle**, du geste du marionnettiste ?

### 3.1.2.1 Manipulation visible et manipulation invisible

Quand le marionnettiste effectue une action, nous nous attendons généralement à ce que la **Marionnette Virtuelle** exécute en réponse un geste visible. Mais nous pouvons également imaginer que le mouvement du manipulateur, bien qu'influençant la **Marionnette Virtuelle**, ne se traduise pas par des indices visuels.

Il s'agirait alors d'un mouvement extérieur entraînant une modification interne de la **Marionnette Virtuelle**, par exemple, l'action d'un marionnettiste sur le changement d'une variable, ou d'un « état », une transformation certes invisible aux yeux du spectateur, mais pourtant bien réalisée.

Dans *Between the lines* (Plessiet et Passedouet 2012) (cf. chapitre 1.3.2.3), la **Marionnette Virtuelle** était un **Double Autre** de l'artiste Maflohé Passedouet figurant une disease de bonne aventure et que l'on contrôle par des gestes au-dessus d'une **leap-motion**. Le mécanisme de contrôle est un simple **automate à états**, disposant de deux états :

* L'état « attente » : qui joue une animation en boucle.

* L'état « prédiction » : qui joue une animation de prédiction.

Lorsque le manipulateur effectue une passe de main au-dessus de la boule de cristal, un compteur se met en marche sans qu'aucun retour visuel ne soit affiché. Une fois que le manipulateur arrête sa passe, le compteur se fige et déclenche l'animation du personnage virtuel associée à la valeur du compteur. Nous avons bien ici un mécanisme basique qui change le fonctionnement du personnage de manière invisible.

Dans cet exemple, la "voyante" virtuelle est bien une **Marionnette Virtuelle** : elle ne dispose pas d'un contrôle moteur sur ses mouvements ; ce sont des animations préenregistrées qui sont appliquées telles quelles sur le personnage. Elle n'a pas non plus de mécanisme décisionnel, car elle ne décide pas de ses prédictions. C'est le manipulateur, qui, sans le savoir, « choisit » la prédiction qui sera tirée.
### 3.1.2.2 Transfert de mouvement mimétique

Dans le cas d'un transfert de mouvement mimétique, le mouvement du marionnettiste sera le même – ou se voudra le même – que le mouvement de la **Marionnette Virtuelle**. Nous désignons dans ce cas le manipulateur sous le terme de **mocapteur**, car on capture le mouvement de l'acteur par l'intermédiaire d'un dispositif de **capture de mouvement** (motion capture ou mocap) pour l'appliquer à la **Marionnette Virtuelle**.

C'est en particulier le cas des systèmes de capture de mouvement. C'est ce que nous avons mis en place pour le projet *Labex art h2H Scène augmenté et Agamemnon redux* (Lavander et al. 2017) (Figure 84).

<figure><img src="image_87.png" /><figcaption>Figure 84 : extrait d'Agamemnon redux où les marionnettes ont le même mouvement que l'acteur/manipulateur (Lavander, 2017)</figcaption></figure>

Cooper (Cooper 1995) décrit trois paradigmes de l'interface :

* Le paradigme technologique, qui se base sur la compréhension du fonctionnement de l'objet ;

* Le paradigme de la métaphore, où on invite l'utilisateur à deviner de manière intuitive le mode de fonctionnement de l'objet ;
* Le paradigme idiomatique, où l'utilisateur assimile l'utilisation de l'objet par apprentissage comme l'apprentissage de l'utilisation de la souris, par exemple.

L'utilisation d'un système de capture de mouvement pourrait se rapprocher du paradigme de la métaphore, mais va bien au-delà, car il y a une parfaite cohérence entre le mouvement du manipulateur et le mouvement de la marionnette. Nous pouvons aussi voir une liaison forte à ce que Jean-François Jego désigne, dans un environnement immersif, par le terme « couplage de mouvement colocalisé et direct » (Jego 2013, page 60).

Avec le projet *Agamemnon redux* (Lavander et al. 2017), nous sommes dans un paradigme de métaphore poussé à l'extrême : l'objet servant de base à la compréhension de l'« interface marionnette » est le corps même de l'utilisateur dans une « recopie » la plus exacte possible, par l'intermédiaire d'algorithmes de **motion retargeting** (Gagneré, Plessiet et Sohier 2018).

Il est extrêmement intéressant de noter que le signifiant du geste du manipulateur dans le monde réel n'est pas forcément le même dans le monde virtuel. Nous avons d'ailleurs fortement mis en avant cet aspect dans les projets *Agamemnon redux* (Lavander et al. 2017) et *La vie en rose* (Filacanapa et al. 2017) où le geste de l'acteur équipé peut être complètement détaché de la position de la marionnette dans le monde virtuel.

Au-delà de ce détournement du geste, il peut y avoir une réelle réinterprétation. Dans *La vie en rose*, un acteur masqué équipé du dispositif joue le rôle d'un psychiatre. Il contrôle en parallèle un personnage féminin (représentation du souvenir de la compagne d'un autre personnage). Le patient voit dans son imaginaire. Par un choix judicieux de la gestuelle de l'acteur, la signification du personnage virtuel est totalement différente à l'écran. Lorsque le médecin range des médicaments, à l'écran la femme prépare le repas, lorsqu'il tente de raisonner le patient, elle meurt dans les flammes (Figure 85). Un tel décalage offre des perspectives de mises en scène très prometteuses.
<figure><img src="image_88.png" /><figcaption>Figure 85 : La vie en rose (Filacanapa, 2017), le geste du manipulateur renvoie une signification différente lorsqu'il est transmis à l' avatar</figcaption></figure>

### 3.1.2.3 Transfert de mouvement idiosyncratique

À l'opposé, s'il n'y a pas de correspondance logique entre le geste du marionnettiste et le geste de la marionnette, je qualifie ce **transfert de mouvement idiosyncratique**. C'est le cas rencontré le plus fréquemment. Prenons le cas d'un joueur de jeu vidéo<fnref n="1" /> s'acharnant sur un jeu de combat comme *Street Fighter 2* (Okamoto 1992) : Comment deviner qu'appuyer sur la combinaison des touches « flèche bas », « flèche diagonale bas », « flèche droite », « bouton triangle », permet à un personnage de tirer une boule de feu ? Le joueur contrôle un avatar, mais il n'y a pas d'adéquation entre les touches que le joueur presse et la réaction de la **Marionnette Virtuelle** (Figure 86).

<figure><img src="image_89.png" /><figcaption>Figure 86 : *Street Fighter 2* (Okamoto 1992)</figcaption></figure>

<footnote n="1">¹ Tous les avatars dans les jeux vidéo ne sont pas des marionnettes virtuelles, comme nous le décrirons plus loin.</footnote>
De la même manière, dans un jeu de tir à la première personne comme *Doom* (Carmack et al. 1993), les touches du clavier permettent de gérer les déplacements du personnage et la souris contrôle la tête et le tir. À nouveau, nous avons un réel décalage entre les contrôles du manipulateur et les réactions de l'**Avatar** (Figure 87).

<figure><img src="image_90.png" /><figcaption>Figure 87 : *Doom* (Carmack et al. 1993)</figcaption></figure>

Ce comportement entraîne un engagement haptique (Witkowski 2012) que le
manipulateur acquière par la pratique, ce qui permet d'automatiser le geste à un niveau
allant jusqu'au réflexe (Clais et Roustan 2003). Il y a une analogie profonde avec ce
qu'Adalbert Kapandji évoque à propos de l'intégration du violon tenu en main par le
violoniste dans son *schéma corporel* devenant ainsi un *schéma corporel* étendu
(Kapandji 2016).

Rémy Sohier a mené une réflexion pour une interaction sensible au service du gameplay (Sohier 2016, 2012) où il démontre de véritables possibilités artistiques exploitant les codes du paradigme de la métaphore et des mouvements dissemblables

Quoi qu'il en soit, nous voyons bien que le rapport à la manipulation de la **Marionnette Virtuelle** change complètement par rapport au mouvement mimétique. Le mouvement dissemblable exige une modification du schéma corporel et nécessite une réappropriation du corps virtuel qui, à la différence de la réappropriation du mocapteur vers la **Marionnette Virtuelle** dans le cas du transfert de mouvement idiosyncratique, induit un travail plus lourd des mécanismes de contrôle.
Dans le cas d'un transfert de mouvement idiosyncratique, nous désignons le
manipulateur par le terme de *manipulacteur*, car nous utilisons une manipulation pour
contrôler la **Marionnette Virtuelle** (Gagneré, Plessiet et Sohier 2017).

3.1.3 Manipulation contrôlée et involontaire et
marionnette apprivoisée

La marionnette peut donc soit exprimer un mouvement mimétique vis-à-vis de
son (ou de ses) manipulateur(s), soit un mouvement dissemblable. Quoi qu'il en soit,
nous n'avons envisagé dans les chapitres précédents que le cas où le manipulateur
est conscient qu'il anime une **Marionnette Virtuelle**. Pourrions-nous imaginer d'autre
cas de figure ? Dans ce cas, en quoi cela modifie-t-il le rapport **Marionnette Virtuelle**
/marionnettiste ?

3.1.3.1 Manipulation contrôlée

Par l'expression « manipulateur volontaire », je désigne un manipulateur conscient de son action d'animateur : il sait exactement ce que son geste va entraîner comme réaction de la part de la **Marionnette Virtuelle**.

Si le manipulateur est conscient de son pouvoir manipulatoire sur la marionnette, il se positionne comme l'utilisateur d'un outil, car il sait qu'une action de sa part entraîne une réponse de la part de la **Marionnette Virtuelle**.

Par exemple, dans le cas de la version de l'installation *Between the Lines*
(Plessiet et Passedouet 2012) présentée à Londres (Grande-Bretagne) et *Lubjuana*
(Slovénie), l'artiste Maflohé Passedouet, grimée en diseuse de bonne aventure, est
consciente que les mouvements de ses mains au-dessus de la boule de cristal, captés
par une **leap-motion** dissimulée, déclenchent les réactions de la diseuse de bonne
aventure virtuelle.

C'est sur ce même paradigme que nous avons construit les Marionnettes
Virtuelles pour le *Labex art H2H* scène augmentée : dans ce projet, une attention
particulière était portée à la recherche d'une méthode pour éduquer les acteurs à
devenir **mocapteur**. En effet, bouger avec une tenue de capture de mouvement bâtie
sur des matrices inertielles comme une **Neuron Mocap**, nécessite pour l'acteur
d'adopter une gestuelle particulière (Figure 88). Le jeu masqué oblige les acteurs à bouger autrement. C'est pourquoi nous avons essayé de voir s'il n'y avait pas la possibilité de transférer des techniques issues de la *Comedia del Arte* au profit de l'enseignement du jeu mocapé.

<figure><img src="image_91.png" /><figcaption>Figure 88 : Mocapteur contrôlant son avatar au cours d'un atelier du Labex art H2H scène augmentée</figcaption></figure>

Quoi qu'il en soit, l'utilisation d'un dispositif de captation visible transforme indubitablement le manipulateur en **manipulateur volontaire**. Il serait d'ailleurs très intéressant de prendre le contre-pied de ce « phénomène » en « théâtralisant » l'appareillage du manipulateur tout en le confrontant à une entité totalement autonome. Le manipulateur se persuadera-t-il qu'il a une quelconque influence sur l'entité, par « effet placebo », ou au contraire se rendra-t-il compte de la supercherie ? Nous ne sommes d'ailleurs pas loin du principe d'une technique d'expérimentation dans laquelle les testeurs interagissent sans le savoir avec un système informatique qu'ils pensent autonome, mais qui est en fait contrôlé par un manipulateur humain : cette technique s'appelle *magicien d'Oz*.
### 3.1.3.2 Manipulation involontaire

Nous sommes partis d'une situation où le manipulateur est parfaitement conscient qu'il manipule un outil. Mais nous pouvons également cacher cette information. Un **manipulateur involontaire** ne sait pas qu'il anime la **Marionnette Virtuelle** et par conséquent ne dispose pas de grille de correspondance entre ses gestes et les gestes de la **Marionnette Virtuelle**.

Pour que le manipulateur n'ait pas conscience de son « pouvoir de manipulation » sur la **Marionnette Virtuelle**, le dispositif de captation doit être le plus discret possible.

Dans l'installation *Rêverie* (Plessiet 2018f) une **Marionnette Virtuelle**, construite à partir de la Sculpture Matrice de Kelly Mézino(Figure 89), est animée par le biais d'un **automate à états finis** composé de 3 états « attente », « regard », « agacement » et d'un périphérique de type Kinect2. Grâce à ce capteur, nous récupérons la position de la tête du spectacteur et le bruit ambiant. La **Marionnette Virtuelle** (Figure 90) sort de son état d'attente lorsqu'un excès de bruit la fait basculer dans l'état d'agacement, ou lorsque la présence du spectateur dans le champ de captation déclenche chez la **Marionnette Virtuelle** l'action de le suivre du regard.

<figure><img src="image_92.png" /><figcaption>Figure 89 : Rêverie</figcaption></figure>
Le spectacteur n'est donc pas conscient que la doublure de Kelly n'est qu'une **Marionnette Virtuelle** qu'il contrôle. Pourtant il a l'impression d'être présent devant un « autre » qui est doté d'une intelligence propre. Bien entendu, si le spectateur prend connaissance du fonctionnement de l'œuvre, la Kelly Virtuelle perd alors à ses yeux une autonomie qu'elle n'a, en réalité, jamais eue.

<figure><img src="image_93.png" /><figcaption>Figure 90 : L'automate à états de Rêverie</figcaption></figure>

### 3.1.3.3 Manipulation apprivoisée

Lorsque le manipulateur commence à comprendre les liens ou mécanismes qui unissent ses actions aux actions de la **Marionnette Virtuelle**, il sort de la **manipulation involontaire** sans pour autant que cela ne lui garantisse un contrôle total.

C'est lors de la présentation de mon installation artistique *Papillons pixel* au centre des arts d'Enghien-les-Bains (Plessiet 2005) que j'ai pu constater pour la première fois ce type de **manipulation apprivoisée**. Dans cette œuvre, des papillons autonomes réagissent à la présence et au bruit par l'intermédiaire d'un micro et d'une webcam. Ils sont « effrayés » par le bruit, mais « intrigués » par le mouvement. Durant l'exposition, une petite fille s'est mise à danser pour attirer les papillons, puis à claquer des mains pour les faire fuir. En comprenant les règles qui régissaient cette création, elle a réinventé une manière d'appréhender l'œuvre. C'est d'ailleurs en la regardant jouer avec mes papillons que j'ai eu envie par la suite de collaborer avec de vrais danseurs.
Dans cet exemple, la manipulatrice a compris le fonctionnement de la marionnette ; mais il existe un autre cas où le manipulateur, tout en ayant parfaitement connaissance des mécanismes manipulatoires, n'est pas en mesure d'effectuer automatiquement une manipulation contrôlée. Le manipulateur oscille alors entre manipulation contrôlée et manipulation involontaire. C'est ce que j'ai essayé de recréer par la suite dans un spectacle confrontant des créatures virtuelles au danseur de Bûto Atsuchi Takenouchi, à la scénographe Maflohé Passedouet et à la musicienne *Hiroko Komiya* (Figure 91). Le spectacle, intitulé *8 seasons*, reposait sur une cocréation progressant au fur et à mesure de la découverte des interactions, chacun n'ayant qu'une compréhension parcellaire des possibilités mises à leur disposition (Plessiet 2007b; Takenouchi et al. 2007).

<figure><img src="image_94.png" /><figcaption>Figure 91 : Atsuchi Takenouchi interagissant avec mes poissons virtuels</figcaption></figure>
## 3.2 La Marionnette Virtuelle, le manipulateur et son rapport au temps et à l'espace

Ainsi la **Marionnette Virtuelle** ne peut s'activer que par le jeu d'un marionnettiste, ce dernier n'étant pas nécessairement conscient de son statut. Nous devons donc considérer un couple en interconnexion. Et si nous avons analysé le mode de transfert du mouvement entre le marionnettiste et sa **Marionnette Virtuelle**, il nous faut nous intéresser maintenant au marionnettiste. Ces deux entités : manipulateur et **Marionnette Virtuelle** sont en effet distincts. Ils n'ont pas forcément le même rapport au temps puisque le manipulateur se trouve dans le temps du monde réel alors que la **Marionnette Virtuelle** se trouve dans un temps simulé. Il n'a pas non plus le même rapport à l'espace, puisque l'un est dans le monde réel et l'autre dans un plan virtuel. Qu'est-ce que cette déconnexion introduit dans son lien à la **Marionnette Virtuelle** ?

### 3.2.1 L'animateur traditionnel et le temps différé

Nous nous concentrerons tout d'abord sur l'impact du temps sur la relation marionnettiste/**Marionnette Virtuelle**. Le fait que le rapport au temps de la marionnette et du marionnettiste oblige à un travail particulier comment le marionnettiste rationalise son rapport au temps ? Dans le cas du **précalculé**, en quoi le fait d'être dans une temporalité différente affecte-t-il le lien **Marionnette Virtuelle** /marionnettiste ? Est-ce que le lien manipulateur/**Marionnette Virtuelle** est différent s'ils se trouvent, au contraire, dans une même temporalité, à savoir celle du temps réel ?

#### 3.2.1.1 De pose en pose

Qu'il utilise les techniques traditionnelles (stop motion, animation sur sable, dessin, etc.) ou numériques (logiciels 2D ou 3D), un animateur travaille dans un rapport au temps particulier. En effet, il doit donner l'illusion d'un mouvement en alternant dans le temps, une succession de poses qui, en fonction du médium, peuvent être dessinées, photographiées, sculptées... (Figure 92).
<figure><img src="image_95.png" /><figcaption>Figure 92 : Extrait d'une animation de la « Pin-up » par Preston Blair pour les studios Tex Avery (Blair 2016)</figcaption></figure>

L'affichage successif de ces poses à une vitesse suffisante exploite le phénomène de persistance rétinienne<fnref n="1" /> pour donner l'illusion du mouvement. La création de ces poses-clés et la gestion du rythme de l'animation sont des travaux de longue haleine. Dans le cadre d'une production industrielle, les animateurs animent seulement quelques secondes par semaine. La lenteur du processus impose parfois certains compromis pour respecter les budgets engagés : par exemple en diminuant le nombre de poses-clés au prix de la qualité des animations ainsi produites. C'est de cette manière que les productions de films d'animation japonais à destination de la télévision travaillent à moindre coût, par économie de poses-clés et développent, par la force des choses, un parti-pris artistique, tout comme celui de Bill Plymton par exemple (Denis 2011).

L'usage de l'ordinateur apporte avant tout la possibilité de générer automatiquement les images intermédiaires entre les poses clés par interpolation. Il fournit une meilleure visualisation, à l'aide de l'affichage des trajectoires dans la fenêtre de travail du logiciel 3D (Figure 93a) et du rythme du mouvement par la modification

<footnote n="1">1 La persistance rétinienne est de 10 images par seconde, mais nous avons plutôt l'habitude, en fonction des standards audiovisuels, de travailler avec 24 ou 25 images par seconde.</footnote>
de courbes. Ces courbes, pour chaque paramètre animé, présentent, généralement, en abscisse le temps et en ordonnée la valeur du paramètre (Figure 93b).

<figure><img src="image_96.png" /><figcaption>Figure 93 : (a) affichage de la trajectoire de la main droite du personnage et (b) courbes de translation dans l'éditeur de courbe</figcaption></figure>

La capacité de l'animateur à donner l'illusion de vie provient de sa capacité à imaginer puis traduire sous la forme de dessin ou de courbe, l'évolution d'une trajectoire complexe dans le temps. Le rythme devient alors un outil et certains grands animateurs le théoriseront, comme Walt Disney qui a développé l'idée de 12 principes d'animation caractérisant le style cartoon (Thomas et Johnston 1995)..

C'est bien la capacité à dissocier les poses-clés du mouvement de sa marionnette avec le temps de l'animation qui permet à l'animateur de « se mettre à la place de » la marionnette, mais dans un temps différé qui est au cœur de sa pratique.

### 3.2.1.2 Un autre rapport empathique

Le travail particulier de l'animateur consiste tout d'abord à se mettre à la place du personnage qu'il doit animer et à imaginer, en fonction de la personnalité de ce personnage, les réactions et les gestes effectués par le pantin. On rejoint la définition de l'empathie comme « simulation mentale consciente de la subjectivité d'autrui » donnée par Jean Decety (Decety 2004, page 87).

Mais ici le travail va plus loin qu'une simple empathie. Certes l'animateur se met « à la place de » sa marionnette pour imaginer le mouvement que cette dernière doit effectuer, mais il doit aussi se « détemporaliser », c'est-à-dire dissocier sa propre perception du temps, du temps du geste à recréer.
Pour cela, il n'est d'ailleurs pas rare de le voir se filmer en train d'interpréter l'action du personnage, ou s'appuyer sur d'autres références comme un jeu d'acteurs. Cela a par exemple été le cas pour le personnage de *Betty-Boop*, où l'animation a été décalquée à partir de films en prise en vue réelle d'une jeune danseuse (Figure 94). Cette technique s'appelle la *rotoscopie*. Elle fut perfectionnée par Max et Dave Fleischer pour la série *Out of the Inkwell* (Cabarga 1988).

<figure><img src="image_97.png" /><figcaption>Figure 94 : Betty Boop et l'extrait de référence</figcaption></figure>

C'est pourquoi les animateurs possèdent généralement de bonnes aptitudes d'acteur<fnref n="1" />, pour effectuer cette opération empathique consistant à imaginer le mouvement du personnage à animer, tout en conservant des compétences analytiques suffisantes pour pouvoir retranscrire en temps différé cet enchaînement de poses. Ceci change donc fondamentalement le rapport à la marionnette, car il n'y a pas de possibilité de « lâcher-prise » de l'animateur par rapport à l'animé, à savoir corriger le mouvement de la marionnette en direct en fonction de son ressenti spécifique à un instant t. L'animation n'est plus modifiable après coup ; elle est, comme figée dans le temps, contrairement au marionnettiste ou à l'acteur qui conserve la possibilité d'improviser et d'interagir.

<footnote n="1">1 Plusieurs écoles du RECA enseignent à leurs étudiants l'art du mime, ou le théâtre.</footnote>
### 3.2.1.3 Animateur/Animation, Marionnette/Marionnettiste, l'impact du temps

Il y a donc une différence fondamentale entre la démarche qui caractérise un animateur, c'est-à-dire de quelqu'un qui travaille-en précalculé et celle d'un manipulateur en **temps réel**, qu'il soit **mocapteur** ou **manipulacteur**. L'animateur fournit un « produit fini » livré tel quel et qui ne sera donc pas modifiable<fnref n="1" />. Cette animation est donc, une fois terminée, déconnectée de son environnement et de sa temporalité.

Dans le cas d'une animation **précalculée**, l'environnement est modifié, par exemple en déplaçant la chaise sur laquelle la marionnette doit s'asseoir (animation faite au préalable par l'animateur), l'animation de notre marionnette sera totalement incohérente.

Dans le cas d'une scène en **temps réel**, il sera tout à fait possible pour le manipulateur de s'adapter à ce changement de décor et donc d'adapter le mouvement de la marionnette afin de correspondre au nouvel aménagement de la scène. Ainsi le manipulateur sera en mesure, en temps réel d'adapter le mouvement de la marionnette afin que la marionnette s'assoie sur la chaise déplacée.

Le **temps réel** permet donc de garder une grande spontanéité dans le contrôle de la marionnette et la possibilité d'improviser, de prototyper rapidement des scénarios ou des interactions. À l'inverse, en précalculé, l'animateur peut réaliser un travail très propre sur les mouvements du personnage, dont la finesse visuelle, dans les mains d'un animateur compétent, sera plus qualitative qu'une interaction temps réel. Pour faire une analogie avec la musique, je dirai que nous avons d'un côté l'énergie d'un concert par rapport à la perfection d'un enregistrement audio retravaillé par un ingénieur du son.

Chacune de ces approches a un intérêt spécifique et c'est pourquoi, dans le projet de **prévisualisation on-set** que j'ai dirigé, *Outilnum* (Plessiet et al. 2013), il me semblait important de disposer de la possibilité de faire des allers-retours entre les

<footnote n="1">1 Ou alors en vue de leur réutilisation comme source d'une nouvelle animation en s'appuyant par exemple sur des technologies d'animations non linéaires (NLA) qui permettent de les combiner entre elles</footnote>
deux méthodes. Ainsi le système permet un prototypage rapide par la manipulation en direct des marionnettes par les **mocapteurs** et les **manipulacteurs**, mais aussi de retoucher ce prototypage par l'intermédiaire d'un travail d'animation traditionnelle. En effet le logiciel **Motion-Builder** est interconnecté à la plateforme *Outilnum* et dispose des outils nécessaires pour retravailler des animations enregistrées par des méthodes d'animation par Image clé.

## 3.2.2 Capture de mouvement et contrôle de marionnette

Si nous avons observé qu'il y a un travail particulier dans la manipulation par le marionnettiste, de la **Marionnette Virtuelle**, nous avons évoqué aussi le fait que le travail du mocapteur reposait sur un transfert de mouvement mimétique, la **Marionnette Virtuelle** répliquant le geste du mocapteur. Il nous faut donc nous intéresser à ce mocapteur. En quoi ce transfert de mouvement mimétique définit-il un nouveau type d'acteur ? Quelle est la chaîne de traitement qui permet de partir d'un geste acté à un geste d'interaction numérique ?

### 3.2.2.1 Remettre l'acteur au cœur du processus d'animation

C'est avec le projet de prévisualisation on-set *Outilnum* que j'ai pris conscience de la nécessité de réfléchir au rôle de l'acteur dans le travail de captation de gestes.

Jusqu'alors, je pensais que l'acteur devait avant tout « fournir du geste », puis c'était surtout le travail sur le logiciel qui permettait de transférer ces gestes à l'acteur virtuel. Cette manière de me focaliser sur le processus informatique datait sans doute de mon travail au sein du studio *Animazoo* dans les années 2002-2004. À cette époque, les projets sur lesquels je travaillais m'amenaient à travailler avec des danseurs et des mimes, plutôt qu'avec des acteurs venant du théâtre ou du cinéma. La technologie de captation de l'époque nous obligeait à avoir des personnes capables de fournir des gestes « exagérés » sur commande, plutôt que de fournir une performance d'acteur.
Je n'avais donc jamais eu réellement l'occasion de réfléchir à la façon d'indiquer à l'acteur le type de geste qu'il devait fournir. En fait, je n'avais pas saisi l'importance de la nécessité de « former l'acteur »,

Mais les conclusions du projet *Outilnum* montraient que nous avions oublié la direction d'acteur réel –donc l'acteur réel lui-même– dans le processus, en nous concentrant de trop sur les avatars, l'immersion et le prototype technologie (Plessiet, Chaabane et Khemiri 2015). Ma rencontre et mes nombreuses discussions avec le metteur en scène et chercheur George Gagneré ont confirmé mon intuition et c'est ainsi qu'a commencé notre collaboration.

Nous nous sommes tout d'abord intéressés aux différences et points communs dans la direction d'acteur virtuel et réel (Gagneré and Plessiet 2015) puis, au cours des ateliers *Idefi Creatics du geste acté au geste d'interaction numérique*, nous avons brassé des étudiants acteurs de théâtre, d'ATI et d'autres filières.

### 3.2.2.2 Du pupetting à la capture de mouvement, réfléchir au langage

Dès notre rencontre et nos premiers échanges, Georges Gagneré et moi avons pris conscience qu'il fallait décloisonner les « équipes monde réel » (Acteurs réels, metteurs en scène...) et les « équipes monde virtuel » (artistes numériques et des techniciens-développeurs...) pour aboutir à une véritable co-création. Ceci nécessite que chaque équipe fasse un pas l'une vers l'autre. En effet, dans mes collaborations passées (Plessiet et Passedouet 2012; Passedouet et Plessiet 2009; Takenouchi et al. 2007), j'avais été marqué par la séparation, pas forcément intentionnelle, des équipes, chacune travaillant, dans son champ de compétence, dans un rapport client/fournisseur.

C'est pourquoi nous avons décidé avec Georges Gagneré, de transformer ces relations de travail pour dépasser le rapport client/fournisseur et en faire « autre chose » comme le relate notre entretien avec la chercheuse Isabella Pluta (Pluta Isabella 2017). J'aurais tendance à utiliser le terme binôme, dans une logique *extreme programming* (une méthodologie de développement agile qui repose sur une sorte de concept pilote/copilote) pour décrire cette « autre chose », car bien que chacun garde sa spécificité, il me semble que chacun des éléments du binôme doit mener la réflexion ensemble dans un dialogue constant.
Ce besoin de décloisonner la frontière nous a amenés à créer un certain nombre de concepts qui, auparavant, n'étaient pas nécessaires, puisqu'il ne nous était pas utile de communiquer notre processus de création (Plessiet et Gagneré 2015; Gagneré et Plessiet 2018, 2017; Gagneré et al. 2018; Gagneré, Plessiet et Sohier 2018).

<figure><img src="image_98.png" /><figcaption>Figure 95 : chaînes de contrôle du mocapteur vers l'avatar complexe</figcaption></figure>

Les premiers termes formulés concernaient les étapes de traitement qui adaptent le mouvement capté d'un acteur réel vers une **Marionnette Virtuelle** (Figure 95). On pouvait distinguer :

* **Le mocapteur** – terme que nous avions défini en 3.1.2.2 contraction de Motion capture Acteur, acteur dont le mouvement est capté par un dispositif de **capture de mouvement** (système à matrice inertielle type **Perception Neuron**, système optique...) – envoie les données à l'ordinateur par un **transfert de mouvement mimétique**;

* **Le datacteur** est l'intermédiaire informatique entre le **mocapteur** et l'avatar neutre. Il récupère les données envoyées par le dispositif de capture de mouvement et les traite pour les rendre compatibles avec le **moteur de jeu**. Il y a donc un **datacteur** spécifique par type de capture de mouvement;
* L'**avatar neutre** transforme les données numériques issues du **datacteur** en données exploitables par le moteur de jeu. Il est invisible pour les spectateurs, mais visible pour l'artiste numérique. Cette notion disparaîtra par la suite.

<figure><img src="image_99.png" /><figcaption>Figure 96 : chaîne de contrôle entre mocapteur et manipulacteur</figcaption></figure>

Par la suite, nous avons travaillé sur deux nouvelles notions, afin de préciser la différence d'interaction que je décris en 3.1.2 (Figure 96) :

* Le **manipulacteur**, terme que nous avions défini en 3.1.2.3, contrôle la **Marionnette Virtuelle** par l'intermédiaire de périphériques dans un **transfert de mouvement idiosyncratique**;

* Le **puppeteer** qui se charge d'appliquer les informations issues du **datacteur** vers notre **Marionnette Virtuelle**. Nous détaillerons plus précisément le fonctionnement du **Puppeteer** par la suite (chapitre 3.3.2.2).

L'ensemble de ce vocabulaire a évolué au fur et à mesure de nos réflexions, en même temps que notre dispositif évoluait au cours de notre collaboration. Ces termes sont issus de notre réflexion commune et certains problèmes que j'avais tendance instinctivement à contourner et auxquels Georges Gagneré m'a obligé à me
confronter m'ont obligé à mener une véritable réflexion sur le processus même de
captation.

3.2.2.3 Du geste acté au geste d'interaction numérique

Pour le projet *Outilnum* (Figure 97a) et pour le premier *atelier Idéfi Creatic* (Figure 97b), nous avions basé la captation des mouvements du mocapteur sur l'utilisation d'un système optique (un dispositif Optitrack de 16 caméras), mais nous nous sommes intéressés par la suite à d'autres dispositifs.

<figure><img src="image_100.png" /><figcaption>Figure 97 : (a) mocapteur immergé d'Outilnum et le rig Caméra et une mocaptrice dans l'atelier Idéfi Creatic de 2015</figcaption></figure>

Le problème majeur de l'utilisation du dispositif optique, au-delà du coût financier, est la lourdeur de l'infrastructure. Ce système est sensible aux conditions d'éclairage et nécessite un espace de captation conséquent.

Pour le second *atelier Idéfi Creatic* (Plessiet 2016b, Plessiet et Gagneré 2015) et le premier *Creative Workshop du Labex Art H2H Scène augmentée* (Gagneré et Plessiet 2016), j'ai donc développé une passerelle pour pouvoir utiliser un dispositif Kinect 1 puis Kinect 2 (Figure 98). L'un espace de captation était certes plus limité, mais aussi beaucoup moins coûteux. En effet le coût est d'une centaine d'euros pour
la Kinect contre un budget de seize mille euros pour un dispositif optique de 12 caméras Optitrack. Au demeurant, ce dispositif optique fait partie du « bas de gamme » du domaine, puisqu'à l'époque, les dispositifs haut de gamme de capture optique pouvaient monter au-delà de dix mille euros la caméra Vicon.

Malgré tout, nous avons été confrontés à plusieurs problèmes majeurs :

* La qualité de la captation était bien en deçà de celle d'un dispositif optique ;

* L'obligation de jouer toujours en face de la Kinect interdisait tout demi-tour ou mouvement de profil ;

* La zone de captation était réduite (environ 2m²) ;

* Capper les mains<fnref n="1" /> du mocapteur était impossible ;

<figure><img src="image_101.png" /><figcaption>Figure 98 : Le dispositif CW3 du Labex Art H2H Scène Augmenté avec la Kinect posé au sol</figcaption></figure>

En 2017, la découverte et l'achat d'un dispositif **Neuron Mocap** a eu un impact significatif sur notre travail. La **Neuron Mocap** est un dispositif de capture de

<footnote n="1">¹ Sur la Kinect 2, on peut juste détecter le mouvement de préhension dans certaines conditions</footnote>
mouvement léger qui repose sur des centrales à inertie<fnref n="1" /> placées sur différentes parties du corps. Outre son faible coût (un peu moins de 1200 euros), le dispositif procure un grand nombre d'avantages :

* Une bien meilleure qualité de captation (certes toujours en deçà de ce que permettrait un système optique, mais meilleur qu'une **Kinect** ) ;

* Une zone de captation limitée uniquement à la couverture wifi du système (Figure 99) ;

* La captation des mouvements des doigts ;

* La possibilité de capter efficacement et en simultané plusieurs personnes, sans risque de gêne : il suffit pour cela que chaque mocapteur soit équipé d'une **Neuron Mocap**.

<figure><img src="image_102.png" /><figcaption>Figure 99 : zone de captation de la Kinect (en bleu) et de la Neuron Mocap (en rouge)</figcaption></figure>

Malgré tout, nous devons faire face à un certain nombre de limitations qui sont à prendre en considération lorsque nous travaillons avec un tel système :

* La captation nécessite d'être très souvent recalibrée, toutes les dix minutes en moyenne. Ceci obligea les différents metteurs en scène du

<footnote n="1">¹ Une centrale inertielle ou IMU (Inertial Measurement Unit) est un dispositif qui peut mesurer accélération et vitesse angulaire et ainsi peut déduire une position relative à son dernier point de calibration</footnote>
projet à intégrer la succession de gestes à effectuer pour la procédure
de calibration dans leur mise en scène ;

* Il faut un point d'appui stable sur le sol pour tout mouvement pour que la position captée soit correcte. En l'absence de points de contact, le dispositif « approximatise » sa position et les erreurs sont donc fréquentes ;

* Une sensibilité magnétique élevée nous oblige à éviter le port de tout métal et à tenir compte du champ magnétique terrestre.

Le **mocapteur** doit alors apprendre à mouvoir son nouveau corps, en évitant les gestes qui pourraient perturber le système : saut, perte du contact au sol, arrachage de capteur. Une situation de crise s'est produite durant la présentation effectuée au centre d'art numérique le cube d'Issy-les-Moulineaux, lorsque le mocapteur a déconnecté le capteur de tête en gesticulant un peu trop. Ceci l'obligea à improviser et j'ai dû intervenir, dès son retour en coulisse, pour le reconnecter.

Il faut donc que le **mocapteur** apprenne à jouer avec le système de capture de mouvement, car le geste doit tenir compte du dispositif technique (Figure 100). Ce n'est pas sans rappeler les longues années d'apprentissage que l'acteur masqué doit effectuer pour maîtriser son masque. Je note, avec amusement, que les acteurs avec qui j'ai travaillé ont la patience de passer 6 ou 7 années pour maîtriser un masque et que, paradoxalement, ne font pas du tout preuve de la même patience pour apprendre à maîtriser le dispositif technique.

À cela s'ajoutent des problèmes de **motion-retargeting**. En effet, il faut tenir compte des mensurations et de la taille des membres de l'acteur réel pour les projeter sur l'acteur virtuel. Au début, j'avais effectué moi-même le développement d'un algorithme de **motion-retargeting** sous forme d'un **plug-in** pour le logiciel **Unreal**. Par la suite, j'ai décidé de déporter les calculs sur un autre logiciel, **Motion Builder**<fnref n="1" />, qui dispose actuellement de la librairie **HumanIK**, l'un des meilleurs algorithmes commerciaux du domaine.

<footnote n="1">¹ Il est à noter qu'une telle technologie sera intégrée quelques années plus tard dans Unreal</footnote>
<figure><img src="image_103.png" /><figcaption>Figure 100 : séance de répétition avec deux mocapteurs et deux avatars</figcaption></figure>

### 3.2.2.4 De la captation des expressions

Les périphériques décrits dans le chapitre précédent nous permettent de capter les mouvements du corps du **mocapteur**. Se pose également la question de la captation du visage. Il est vrai que pour les studios de capture de mouvement, il est maintenant tout à fait possible, avec l'équipement adéquat, de capter le corps et le visage par des technologies de performance capture (Figure 101). La performance-capture est une évolution des technologies de capture de mouvement qui est capable de capturer à la fois le corps et les expressions faciales du **mocapteur**, ce qui permet une capture globale de sa performance. Mais de tels dispositifs restent pour le moment inaccessibles à de nombreux utilisateurs à cause de leur coût prohibitif et des ressources humaines nécessaires.
<figure><img src="image_104.png" /><figcaption>Figure 101 : L'acteur Andy Serkis en séance de performance capture (Garcia 2014)</figcaption></figure>

Paradoxalement, les metteurs en scène avec qui nous avons collaboré sur le projet Labex Art H2H Scène Augmenté ont laissé de côté les possibilités de contrôle des expressions implantées dans les différentes sculptures-matrices. Nous les avions pourtant liés, Georges et moi, à un système de pupettage et un manipulacteur aurait pu les contrôler (une touche permettant ainsi de déclencher une expression), mais ceci n'a pas du tout été mis en œuvre. Je pense que le recours au masque a inconsciemment influencé l'ensemble des participants à avoir des avatars numériques au visage inexpressif.

Cela n'a pas été le cas pour mes autres travaux. Ainsi pour animer le visage de mes avatars je me suis tourné vers des méthodes alternatives pour ces différents projets. Pour *Between the lines* (Plessiet et Passedouet 2012), je me suis inspiré des travaux de Tan et Dermody pour animer la bouche de la **Sculpture Matrice** de Maflohé Passedouet (Tan et al. 1996). J'ai tout d'abord enregistré la voie de Maflohé Passedouet puis j'ai utilisé une *transformée en ondelettes rapides*<fnref n="1" /> pour me servir ensuite de cette décomposition pour associer les ondelettes obtenues à une forme de

<footnote n="1">1 Fast Wavelet Transform: une méthode de décomposition d'un signal assez semblable aux transformées de Fourier</footnote>
bouche. Je reconnais que l'association entre ondelettes et formes de bouche a été
assez empirique, mais j'ai finalement réussi à animer les lèvres de la Tzigane virtuelle.

Pour les installations *Rêverie* (Plessiet 2018f), *Arpège* (Plessiet 2018a) et *Ca bug dans les rotations* (Plessiet 2018c), j'ai eu recours à un logiciel spécifique, *Brekel Face*, pour capter les expressions du visage grâce à une **Kinect 2**. Puis j'ai retravaillé l'ensemble dans le logiciel dédié **Motion Builder**. Il est d'ailleurs très important, de noter qu'il est possible d'interconnecter **Motion Builder** – par l'intermédiaire de ma bibliothèque **AKeNe** – à un moteur de jeu bien avant l'introduction en natif de cette fonctionnalité en 2018 (ma première intégration de cette fonctionnalité remonte à 2010). Je n'ai pas encore eu l'occasion de le mettre en œuvre dans une pièce de théâtre : nous pourrions ainsi contrôler les mouvements de tête et les expressions de visage d'une **Marionnette Virtuelle** en temps réel.

Pour l'installation *Un regard moderne* (Plessiet 2018g), j'utilise directement les capacités de la bibliothèque de programmation **SAPI 5.0** qui intègre, des outils permettant d'associer à une forme de bouche, un son généré par **Text To Speech** c'est-à-dire qui permet de faire lire par une voix de synthèse un texte écrit par un ordinateur.

3.2.3 Contrôle externe et contrôle incarné

Si nous nous sommes concentrés dans les parties précédentes sur l'animation
de la marionnette et les techniques de captation des gestes du mocapteur, il est temps
d'étudier le rapport que le mocapteur entretient avec ce corps virtuel qu'il anime.

Si le mocapteur contrôle un corps virtuel, nous pouvons nous interroger sur la localisation de ce contrôle : est-il à l'extérieur de ce corps virtuel ? Et, si oui, comment se positionne-t-il et qu'est-ce que cette position entretient dans cette relation acteur réel/corps virtuel ?

S'il est immergé dans ce corps virtuel par l'intermédiaire de dispositifs de réalité virtuelle, qu'est-ce que cela entraîne dans son jeu et en quoi ce corps, qui n'est pas le sien, affecte son rôle ? Ceci change-t-il le rapport de l'animateur vis-à-vis de la marionnette accentuant ainsi la traversée de la frontière réelle/virtuelle ?
### 3.2.3.1 À l'extérieur du corps, un travail empathique...

Durant le projet Labex Art H2H scène augmentée se sont déroulé un certain nombre d'ateliers autour du jeu masqué et du jeu mocapé appelé Creative Workshop (ou CW). Lors des différents Creative Workshop menés, nous nous sommes interrogés sur l'organisation de l'espace entre acteur réel, mocapteur, avatar et spectateur. Ainsi, pour le premier CW3 auquel j'ai participé, les différents participants étaient positionnés comme sur la Figure 102 (Gagneré et Plessiet 2016).

<figure><img src="image_105.png" /></figure>

STUDIO A 169
Paris 8
Dispositif CW#3
07/05/2016

<caption>Figure 102 : organisation du Créative Workshop 3 (1) et (2) acteur masqué, (3) mocapteur, (4) avatar (5) manipulacteur, (4) directeur d'acteur</caption>

Le mocapteur se retrouve dans une position de contrôle externe de l'avatar tout en visualisant à distance l'avatar qu'il manipule. Nous avons mené des expérimentations où nous avons effectué une transformation des mouvements de l' avatar afin qu'il soit ou non en miroir par rapport au manipulacteur. Ainsi en mode miroir, la main droite du mocapteur correspond à la main gauche de l' avatar. Ceci n'est pas sans rappeler les expérimentations menées par Alain Berthoz, Michel Bret et Marie-Hélène Tramus sur les interactions entre une funambule réelle et la funambule autonome<fnref n="1" /> dans l'œuvre La funambule (Thirioux et al. 2009).

<footnote n="1">1 Ceci est une différence de taille, car la funambule de Michel Bret fonctionne à base de réseau de neurones artificiels, contrairement à notre dispositif où nous avons affaire à une simple marionnette virtuelle.</footnote>
Nous avons remarqué qu'il était beaucoup plus difficile pour le **mocapteur** de contrôler son avatar en mode miroir, qu'en mode normal. Ceci confirme le lien empathique qui unit l'avatar à son **mocapteur**, à l'image du test imaginé par Bavelas et cité par Gerard Jorland et qui lui permet d'écrire qu'une « *relation de sympathie* l'observateur imite le sujet où l'observateur imite le sujet en miroir, il doit se pencher du même côté. Autrement dit, l'empathie établit, dans ce cas, une symétrie de rotation, la sympathie est une symétrie de réflexion » (Jorland 2011).

Pour le **manipulacteur**, la situation est très différente et même si nous n'avons pas spécifiquement identifié si elle était empathique ou sympathique, le mécanisme de contrôle est, en tout cas, plus proche de la marionnette comme décrite en 3.1.1.2. Nous étudierons plus précisément cette relation au chapitre suivant.

### 3.2.3.2 Redéfinir les espaces

Notre dispositif permet de modifier l'agencement des espaces des différents acteurs, **mocapteurs** et **manipulacteurs**. L'une de nos organisations de départ reposait sur un **mocapteur** qui se trouvait hors de la scène (Figure 103) :

<figure><img src="image_106.png" /><figcaption>Figure 103 : Le Mocapteur hors public</figcaption></figure>

Dans ce dispositif, nous devions garantir au **mocapteur** une bonne compréhension de la scène et du rendu final. C'est pourquoi nous avons dû positionner plusieurs retours vidéo pour que le mocapteur puisse interagir correctement avec l'acteur. Le **mocapteur** doit opérer un travail complexe en adoptant le point de vue de l'avatar dans ses adresses — où regarde l'avatar et à qui il s'adresse — c'est-à-dire qu'il doit comprendre à la fois l'espace de la scène et l'espace virtuel pour que nous,
spectateur puissions lire et comprendre ses actions. Ceci fut le cadre d'un certain nombre d'ateliers où nous avons transposé des exercices du jeu masqué vers le jeu mocapé (Figure 104).

<figure><img src="image_107.png" /><figcaption>Figure 104 : Atelier workshop au Conservatoire national d'art dramatique</figcaption></figure>

À la suite de l'achat de nouvelles tenues de captures de mouvement de type **Neuron Mocap**, nous avons pu créer des mises en scène avec plusieurs **mocapteurs**, pouvant se retrouver dans le même espace ou dans des espaces de captures différents. Ceci est en grande partie lié aux problèmes de délocalisation que nous évoquions en 3.2.2.3 : si nous avions opté pour un système de capture de mouvement optique, nous aurions été obligés d'utiliser un même espace de captation.

<figure><img src="image_108.png" /><figcaption>Figure 105 : Plusieurs mocapteurs en interaction avec des acteurs</figcaption></figure>
Plus nous multiplions les **mocapteurs** et les acteurs (Figure 105), plus nous ajoutons de la complexité. Chaque marionnette se trouve dans son propre espace virtuel. Et les adresses monde virtuel/monde réel ne sont pas très différentes de ce que nous évoquions pour la disposition précédente. Ceci devient donc complexe lorsque les deux avatars doivent interagir entre eux (Figure 106). Là encore, la difficulté provient du fait que les dispositifs de captation fonctionnent sur des positions relatives et non pas absolues. Cette complication aurait donc pu être évitée si nous avions utilisé un dispositif optique.

L'autre dispositif de mise en scène que nous utilisons consiste à faire que l'acteur soit aussi le **mocapteur**. Cette disposition est extrêmement intéressante, car, outre l'intérêt scénique, elle interroge le rôle de l'acteur qui se trouve ainsi dédoublé dans des corps différents, réel et virtuel.

<figure><img src="image_109.png" /><figcaption>Figure 106 : Acteur/mocapteur</figcaption></figure>

Un tel dispositif entraîne une lecture différente de l'action, que ce soit au niveau de l'avatar ou de l'acteur. C'est le cas dans la pièce *Agamemenon redux* (Lavander et al. 2017) où les acteurs, bien que face au public, ne sont pas dans la même position dans le monde virtuel et dans le monde réel. Ainsi un **mocapteur** contrôle plusieurs personnages qui se trouvent de part et d'autre de l'escalier (Figure 107), dans des corps différents et dont le geste n'a pas la même signification dans le monde réel et le monde virtuel. Dans le cas d'Agamemnon redux, la scène virtuelle est
comme une métaphore de ce qui se passe dans la scène réelle : il n'y a donc pas d'interaction de part et d'autre de la frontière réelle/virtuelle.

<figure><img src="image_110.png" /><figcaption>Figure 107 : Agamemnon redux prototype</figcaption></figure>

### 3.2.3.3 Immerger l'acteur

À la différence des ateliers Labex Art H2H où nous avons travaillé avec un **mocapteur** contrôlant de l'extérieur une **Marionnette Virtuelle**, le projet *Outilnum* (Plessiet et al. 2013 ; Plessiet, Chaabane et Khemiri 2015), *Creatic 2* (Plessiet 2016b) et *Lucky* (Plessiet 2012), impliquait un **mocapteur** « immergé corporellement » dans un environnement virtuel, grâce à un casque de réalité virtuelle et un système de captation corporelle. Par « immergé corporellement », j'entends que le **mocapteur** était doté d'un corps virtuel dont les mouvements correspondaient aux mouvements du mocapteur<fnref n="1" />.

Pour ce faire, l'idée est de recueillir les informations corporelles du **mocapteur** par un système de captation, puis de les réutiliser pour contrôler le corps virtuel du mocapteur. Ce corps virtuel ne doit pas disposer d'une géométrie pour la tête, car sinon le point de vue du mocapteur serait obstrué. Pour *Outilnum*, nous avons utilisé

<footnote n="1">1 Contrairement à l'installation Deep Blue (Plessiet 2004) où le spectacteur n'était pas immergé corporellement, c'est-à-dire qu'il n'avait pas de corps dans ce monde virtuel</footnote>
le dispositif de capteur de mouvement optique du laboratoire et pour le second atelier *Creatic* et *Lucky*, nous avons utilisé une simple **Kinect**.

Pour ma part, il m'a toujours semblé important de doter le **mocapteur** immergé d'une représentation corporelle. Dans l'installation *Cigale*, à laquelle plusieurs de mes collègues de l'équipe de recherche INREV ont contribué, l'utilisateur immergé ne dispose pas de représentation corporelle (Tramus et al. 2018). Il serait d'ailleurs intéressant de voir si le fait de doter le mocapteur d'un corps, ne transforme pas la relation qu'il noue avec l'acteur virtuel.

Judith Guez et Jean-François Jego soulignent que lors de l'utilisation d'un casque de réalité virtuelle, l'utilisateur ne voit pas son propre corps et que cette approche peut être un parti-pris artistique. Mais il peut être aussi extrêmement intéressant de le doter d'un corps qu'il n'est pas nécessaire pour l'immersion du mocapteur qu'il soit très poussé (Jégo et Guez 2011). Ce fut d'ailleurs le cas pour le projet *Creatic 2* puisque le corps virtuel des **mocapteurs** était composé de simples lignes et cubes. Il est d'ailleurs pertinent de noter que le corps que le **mocapteur** perçoit dans le casque est différent du corps que voient les spectateurs situés à l'extérieur. A contrario, nous avons par deux fois dû aménager le corps virtuel de nos acteurs, car ils n'étaient plus en mesure de se mouvoir correctement. L'incapacité de mouvements, pour l'un des cas, a été jusqu'à l'immobilisation complète pendant une vingtaine de secondes, car la **mocaptrice** immergée ne reconnaissait plus son corps.
Le problème a été corrigé de manière empirique.
## 3.3 Au-delà du couple
marionnette/marionnettiste

Comme nous l'avons évoqué précédemment, s'il faut au moins un
manipulateur pour animer la **Marionnette Virtuelle**, ce ou ces manipulateurs
s'intègrent dans une équipe plus large où interviennent **mocapteur, manipulacteur,**
techniciens et artistes numériques, chacun interagissant dans une collaboration
complexe.

Nous devons nous interroger sur la façon dont chaque membre de cette équipe trouve sa place dans la collaboration. En outre, quels sont, au sein de nos différents projets, les outils spécifiques que nous avons développés pour permettre cette collaboration ? Ceci nous amène à interroger ce couple **Marionnette Virtuelle /marionnettiste** : ne sommes-nous pas en face d'autre chose que son équivalent réel ? Ne pouvons-nous pas imaginer utiliser, comme nous, les manipulations improvisées pour feindre une certaine autonomie ?

### 3.3.1 Un travail collaboratif

Étudions tout d'abord la collaboration entre les différents membres de l'équipe. Comment chacun trouve-t'il sa place, entre « le fournisseur de geste » et les multiples membres de l'équipe ? Et si les marionnettes à plusieurs marionnettistes sont courantes, n'y a-t-il pas moyen de s'inspirer de pratique déjà en vigueur pour définir le lien collaboratif **mocapteur/datacteur** ? Ceci sans oublier que la collaboration peut se faire en combinant **temps réel** et **précalculé**.

#### 3.3.1.1 Le mocapteur comme fournisseur de gestes

Dans le cadre d'une production précalculée pour un film ou un jeu vidéo, le mocapteur se retrouve dans une position particulière, au sens où son travail doit être intégré à une chaîne de production impliquant d'autres métiers et d'autres processus. Lorsque Andy Serkis évoque son travail d'acteur pour la capture de mouvement, il a
tendance à limiter le rôle de son équipe<fnref n="1" /> à celle de simples « maquilleurs » qui habillent
la performance du mocapteur (Woerner 2014).

Ceci reviendrait à minimiser l'importance du reste de l'équipe. Mais comme l'a
souligné un animateur « Sans les gars des effets spéciaux, il serait juste un Anglais
en collant prétendant être une créature magique »<fnref n="2" /> (Mancini 2014). Je rejoindrai les
propos de Matt Reeves, réalisateur de La planète des singes : L'affrontement (Reeves
2014) « Mais il y a deux niveaux des plus élevés des arts pour créer César. L'un est
une performance et c'est 100 % Andy. »<fnref n="3" /> (Toro 2015)

Lorsque j'enseigne la capture de mouvement à mes étudiants, j'ai coutume
d'utiliser l'image suivante : « John Wayne est un acteur extraordinaire, mais si l' avatar
que vous devez animer est Lara Croft<fnref n="4" /> et que votre mocapteur est John Wayne, nous
obtenons Lara Croft qui marche comme John Wayne». Car le mocapteur ne fait que
fournir une performance enregistrée qui sera l'entrée d'une chaîne de traitement où
interviennent d'autres artistes. Si la performance ne convient pas, les autres artistes,
quel que soit leur talent, n'arriveront pas à obtenir le résultat souhaité.

Le processus nécessite donc une compréhension de l'ensemble de la chaîne,
car si l'artiste numérique n'est qu'un « maquilleur » alors le mocapteur doit prendre
conscience qu'il n'est qu'un « fournisseur de données gestuelles ». Mon propos,
volontairement provoquant pour aller à l'encontre de ceux de Serkis, cherche à
souligner la nécessité d'avoir des données de qualité pour que la chaîne de traitement
soit efficace. La prestation du mocapteur sera retravaillée afin d'aboutir au
mouvement final. Donc, plus la performance sera de qualité, c'est-à-dire fournissant
les données nécessaires au re-travail du mouvement, plus l'ensemble du reste de la
chaîne sera optimal. En ce sens, il faut apprécier les initiatives de création d'école de
mocapteurs, comme celle proposée par Serkis depuis 2010 (Thorpe 2010), où les
mocapteurs sont formés à s'intégrer le mieux possible à la chaîne de production.

<footnote n="1">¹ Il aurait adouci son discours comme me l'a relaté une connaissance commune</footnote>

<footnote n="2">² «Without the VFX guys, he's just a British guy in a leotard pretending to be a magical creature. »</footnote>

<footnote n="3">³ «But there's two levels of the highest kind of artistry that are going on in order to create Caesar. One is a performance. And that is 100 percent Andy. »</footnote>

<footnote n="4">⁴ L'héroïne du jeu Tomb Raider</footnote>
### 3.3.1.2 Un travail à plusieurs mains

Dans une démarche **temps réel**, le mouvement de la **Marionnette Virtuelle** ne se fait pas dans une chaîne de traitement, mais en parallèle, chaque manipulateur manipulant en même temps la Sculpture Matrice.

<figure><img src="image_111.png" /><figcaption>Figure 108 : Une marionnette Bunkaru et ses trois marionnettistes</figcaption></figure>

Cet avatar devient la somme de sources de contrôle différentes ce qui rappelle le fonctionnement des marionnettes *Bunraku* (Figure 108). Le *Bunraku* est un théâtre de marionnettes japonais, qui serait originaire d'Osaka et qui daterait du XVIIe siècle. Un récitant, accompagné de musiciens, raconte le récit et interprète l'ensemble des rôles, pendant que les manipulateurs animent les différentes marionnettes. Chaque marionnette, d'une taille comprise entre 120 et 150 cm, est manipulée simultanément par trois marionnettistes. Le *omo zukai* manipule la tête et le bras droit, le *hidari zukari* le bras gauche et le *ashi zukari*, les pieds. Les trois marionnettistes sont organisés en fonction d'une hiérarchie établie : l'*omo zukai* est le maître et doit avoir une expérience d'au moins vingt ans, alors que le *ashi zukari* tient la place du novice. Le *omo zukai* entraîne le mouvement et les autres suivent son intervention.

Une hiérarchie un peu similaire s'est installée au cours du projet du Labex Art H2H Scène Augmentée. Le **mocapteur** contrôle le corps et a donc la plus grande
responsabilité sur la gestuelle de la **Marionnette Virtuelle** : il devient le leader du mouvement, les **manipulacteurs** devenant ses accompagnateurs.

Dans le futur, je me demande s'il serait possible de travailler dans la logique des grilles d'improvisation des jazzmen (Michel 2010) où chacun, par sa maîtrise des outils, ses compétences artistiques et sa connaissance des thèmes de mouvement, serait en mesure d'improviser le geste. Une telle perspective est déjà amorcée comme le montre le travail de Gregory Doran sur la Tempête de Shakespeare au Royal Shakespeare Theatre en 2017, spectacle qui a combiné **mocapteur** et **datacteur** pour la transformation du personnage d'Ariel joué par Mark Quartley (Figure 109).

<figure><img src="image_112.png" /><figcaption>Figure 109 : Le personnage d'Ariel en Harpie dans la pièce la Tempête de Shakespeare par Gregory Doran</figcaption></figure>

### 3.3.1.3 Combiner temps réel et précalculé dans une mécanique complexe

Nous venons de voir les différences que nous rencontrons lorsque le mouvement enregistré est destiné à être traité en précalculé, ou bien lorsqu'il agit en temps réel. Mais dans ma série de portraits interactifs, je combine les deux. En effet, je retravaille des enregistrements de capture de mouvement<fnref n="1" /> que je manipule et déforme en temps réel.

<footnote n="1">¹ J'utilise la capture de mouvement, car je ne suis pas du tout animateur. Il va de soi que ce qui me semble important est le mouvement final, et non la manière dont je l'ai obtenu.</footnote>
Comme je l'avais évoqué pour *Rêverie* dans le chapitre 3.1.3.2, je procède souvent par la création d'un **automate à états**, ou, plus rarement, par un **arbre de comportement** qui enchaînera la lecture des animations enregistrées en fonction des actions du **manipulacteur**. Ceci forme la trame principale de l'animation de la marionnette et permet de simuler un certain nombre de phénomènes difficiles à recréer par manipulation **temps réel**. Je pense, par exemple, au mouvement respiratoire, aux clignements des yeux ou à de l'animation faciale. Mais l'utilisation d'une deuxième piste de manipulation **temps réel** permet de reconnecter la **Marionnette Virtuelle** avec le moment présent et répond ainsi à la partie de mon travail qui interroge la frontière entre le monde virtuel et le monde réel.

C'est dans ce contexte que j'introduis des mécanismes modificateurs, par exemple le fait de suivre du regard le manipulacteur, jouant sur le fait que la **Marionnette Virtuelle** rentre en dialogue avec un élément du monde réel. Ceci peut-être un manipulacteur, conscient ou nom de son contrôle, ou un élément du décor comme pour le projet en cours<fnref n="1" /> *les bulles de savon* où, la **Marionnette Virtuelle** suit du regard les bulles réelles qui sont émises du dispositif situé derrière le tableau (cf Figure 110).

<figure><img src="image_113.png" /><figcaption>Figure 110 : bulle : en interaction avec des bulles réelles</figcaption></figure>

<footnote n="1">¹ Autant la partie informatique est opérationnelle, autant il me reste à faire la partie mécanique</footnote>
## 3.3.2 Le mécanisme de puppetter

Si nous nous sommes intéressés à l'aspect humain de la relation **Marionnette Virtuelle** /manipulateur et avons noté les différents « métiers » qui se cachent derrière le terme de manipulateur, il est temps de nous interroger sur la partie informatique de cette relation. Comment avons-nous mis au point les **algorithmes** qui permettent de transférer les actions de manipulateurs vers la **Marionnette Virtuelle** ? Qu'est-ce que cela entraîne comme possibilité et/ou contrainte ?

### 3.3.2.1 Une évolution de plusieurs mécanismes

Comme nous allons le voir, l'ensemble de ces mécanismes est le fruit d'une évolution constante et évoluera encore. Dans le cadre du projet *Outilnum* (Plessiet, Chaabane et Khemiri 2015) nous avions mis en place pour **Unity**, un système que nous avions appelé *behavioral layer* et qui permettait de combiner des mouvements d'origines différentes. Nous détaillerons ces *behavioral layer* dans le chapitre 5.2.2. Ce système contenait une première réflexion pour gérer et combiner des animations issues de manipulacteur de mocapteur (et d'animation comportementale).

Par la suite, dans le cadre des premiers prototypes réalisés avec le département théâtre pour le projet *Labex art H2H scènes augmentées*, j'ai développé un système de **motion retargeting** : l'idée était de pouvoir capitaliser les mouvements, quelle que soit la géométrie des personnages. Nous avons abandonné ce développement pour profiter de la puissance du système de **motion retargeting** directement intégré au logiciel **Unreal**, tout en travaillant comme nous l'avions évoqué auparavant en 4.1.2.3 sur une passerelle **AKeNe /Motion Builder**.

Les travaux futurs se baseront certainement sur la nouvelle technologie *Live Link* développée par le moteur **Unreal** qui permet d'interconnecter **Unreal** avec d'autres logiciels (Unreal Engine 2018). Comme le projet est open source (licence MIT), nous pourrons ainsi l'adapter plus facilement à nos besoins.

### 3.3.2.2 AKN_ActingInput, AKN_Datactor et AKN_puppetter

Nous avons ainsi développé une architecture informatique qui permet de transférer le mouvement d'un **manipulacteur** ou d'un **mocapteur** vers une
**Marionnette Virtuelle.** Derrière cette architecture se cache l'idée que notre **Marionnette Virtuelle** est contrôlée par plusieurs « marionnettistes ». Chaque marionnettiste a sa propre interface de contrôle pour créer une action de jeu sur la Marionnette Virtuelle. De la même manière que pour une marionnette *bunraku*, nous avons un marionnettiste avec un type de manipulateur pour le bras droit et le haut du corps, un autre pour le bras gauche et un dernier pour les jambes.

Dans cette architecture l'AKN_ActingInput, pourrait être assimiler à la croix d'attelle d'une marionnette à fils. Il existe deux types d'AKN_ActingInput :

* La première catégorie centrée sur l'opérateur humain, qu'il soit mocapteur ou manipulacteur, est associée à un type de périphérique d'entrée (un dispositif de capture de mouvement, un joystick ou une manette midi) ;

* La deuxième catégorie est axée sur un opérateur logiciel, comme un algorithme de détection de chemin le plus court ou autre.

Une marionnette peut être contrôlée par plusieurs AKN_ActingInput : t il est possible de les ajouter, de les supprimer, de les activer ou de les désactiver en temps réel. Ceci apporte une grande liberté et une grande modularité dans l'ensecret – c'est-à-dire l'étape qui consiste à relier la marionnette à son mécanisme de contrôle – de notre **Marionnette Virtuelle** (Figure 111).

<figure><img src="image_114.png" /><figcaption>Figure 111 : AKN_ActingInput et AKN_Pupetter</figcaption></figure>
Ces AKN_ActingInput manipulent la **Marionnette Virtuelle** par l'intermédiaire d'un AKN_Puppeter<fnref n="1" /> que l'on pourrait assimiler aux fils de la marionnette à fils, le AKN_Puppeter relie ainsi les différentes articulations de la **Marionnette Virtuelle** au AKN_ActingInput(Figure 112).

<figure><img src="image_115.png" /><figcaption>Figure 112 : un AKN_Puppeter (la figure rouge) relie un AKN_NeuronMocapActingInput à la Marionnette Virtuelle</figcaption></figure>

### 3.3.2.3 Des possibilités à explorer

Il est dès lors possible de combiner plusieurs AKN_Puppeter pour une seule **Marionnette Virtuelle**. Ceci permet par exemple à un premier mocapteur de contrôler le haut du corps de la marionnette et à un second mocapteur de contrôler le bas du corps de la marionnette (Figure 113) (Gagneré, Plessiet et Sohier 2017).

<footnote n="1">1 Au début, cet objet s'appelait AKN_Puppeteer, Puppeteer signifiant « marionnettiste », mais nous avons décidé de retirer un « e » afin de l'appeler AKN_Puppeter, car il nous semblait que la notion derrière ce terme n'était pas tout à fait la même, mais plutôt reliée à une logique plus hybride de « marionnettage » introduisant une notion de « méta marionnettisme », mais il est fort possible que nous revenions dans la prochaine version à AKN_Puppeteer qui personnellement me semble plus logique</footnote>
<figure><img src="image_116.png" /><figcaption>Figure 113; une Marionnette Virtuelle contrôlée par plusieurs puppeters, un premier puppeter contrôlant le haut du corps, un second puppeter contrôlant le bas du corps et la tête</figcaption></figure>

Nous pouvons aussi imaginer de nombreuses configurations en combinant par exemple un AKN_PathFinding_ActingInput et un AKNGamepad_ActingInput. Le AKN_PathFinding_ActingInput déplace la **Marionnette Virtuelle** d'un point A à un point B et fera l'objet d'un traitement plus complet dans le chapitre ... dédié au **Golem Virtuel**. Le AKNGamepad_ActingInput contrôle la rotation d'un membre. Nous pourrions tout aussi bien le combiner avec un AKN_LookAt_ActingInput qui oriente un membre, généralement la tête, dans la direction d'un objet.

<figure><img src="image_117.png" /><figcaption>Figure 114 : une Marionnette Virtuelle contrôlée par deux mocapteurs et un contrôle joystick</figcaption></figure>
Dans le futur, j'aimerais appliquer la même méthode au visage, en me basant
sur les FACS (pour *Facial Action Coding System*, le système de codage des
expressions faciales mis au point par Eckman) que nous avons définies en 2.2.2.2. Ce
système est déjà en cours de programmation, mais nécessite encore un grand nombre
de développements. En l'état actuel, nous avons déjà un terrain exploratoire
intéressant. Nous pouvons aller beaucoup plus loin que le couple **mocapteur**
**/manipulacteur** mis en place durant le Labex Art H2H Scène Augmentée. J'imagine
notamment des créatures non anthropomorphes, contrôlées par plusieurs
**mocapteurs** ou **manipulacteurs** (Figure 114), par exemple la déesse Shiva, ou
encore des hommes mille-pattes, bref, des créatures difficiles à obtenir sur une scène
de théâtre sans avoir recours à des maquillages et des mécanismes coûteux.

3.3.3 Inverser marionnettiste et marionnette

En soi, cette architecture de code permet un lien fort entre le (ou les)
manipulateur(s) et la **Marionnette Virtuelle**. Il serait maintenant intéressant de
considérer comment se comportent les champs d'action délimités par le manipulateur
et la marionnette. Mais serait-il possible d'inverser cette relation ? De faire que le
marionnettiste devienne « marionnette » ?

3.3.3.1 La relation manipulateur/manipulé plus complexe qu'il n'y parait

Dans notre présentation, nous avons mis en avant un dispositif qui permet
d'associer à une action du manipulateur une réaction de la **Marionnette Virtuelle**. Le
manipulateur, tout comme la marionnette, disposent chacun d'une certaine potentialité
de mouvement. Le module AKN_Puppeter ne produit finalement qu'une
correspondance entre une partie des potentialités du manipulateur et une partie des
potentialités de la **Marionnette Virtuelle**, bref, le plus petit dénominateur commun
entre deux potentialités. Si nous voulons utiliser une potentialité de la marionnette, il
nous faudra créer le mécanisme que pourra actionner le manipulateur.

À ceci s'ajoute le fait que c'est l'ordinateur qui sert de mécanisme de support
à cette interaction, et, comme je l'ai souligné dans (Plessiet 2007b), il y a un travail de
traduction entre ce que le manipulateur imagine dans la reproduction du geste, le programmeur programmant le geste<fnref n="1" /> et la **Marionnette Virtuelle** qui exprime le geste.

Ceci implique que même la création du mécanisme doit être pensée et planifiée. Plus la pensée est longue et complexe, plus les incompréhensions seront élevées et surtout, moins elles seront modulables. Dans une telle logique, nous proposons de respecter systématiquement les règles suivantes <fnref n="2" />:

* Si le même élément d'une marionnette peut être contrôlé par deux manipulateurs, il est possible, en l'absence de la programmation de niveau de priorité d'observer un conflit entre deux propositions de jeu. Il est donc important d'introduire une hiérarchie entre les différents manipulateurs (qui n'est pas obligé d'être la même pour les différents puppeteer);

* S'assurer que le mouvement peut être interrompu ou repris;

* Si nous utilisons des mouvements préenregistrés, plus les mouvements sont longs et caractéristiques, mobilisant de nombreuses parties du corps, plus ils sont difficilement combinables. Ainsi, si nous avons un mouvement de marche triste qui est déclenché par une action d'un manipulacteur, il sera très difficile de le combiner avec un mouvement de roulade. Il convient donc de faire des mouvements simples.

Ceci n'est pas sans rappeler la manière dont le design de mouvement est réalisé dans les jeux vidéo (D'Angelo 2017). Peut-être serait-il intéressant de combiner ce savoir-faire avec celui de marionnettiste traditionnel.

Quoi qu'il en soit, ce qui est novateur dans ces nouvelles **marionnettes virtuelles** est que, contrairement à une marionnette réelle, elles peuvent combiner des

<footnote n="1">¹ Pour supprimer un intermédiaire et donc un risque de mauvaise interprétation de l'information, nous pouvons fusionner le manipulateur et le programmeur. Mais ceci entraîne la nécessité d'un savoir à la fois de manipulateur et de programmeur. C'est un petit peu dans cette démarche que Georges Gagneré a décidé d'apprendre et de m'aider à la mise au point de l'outil.</footnote>

<footnote n="2">² Je propose ces règles d'un point de vue ergonomique, mais tout dépend de la volonté artistique qui se cache derrière la création de la marionnette virtuelle.</footnote>
animations qui se lisent dans le temps et des animations ponctuelles qui peuvent se modifier et s'influencer.

### 3.3.3.2 Créer un dialogue manipulateur/marionnettiste virtuelle

Lors de ma conférence/performance *Cou2garnak* (Plessiet 2016a) donnée dans le cadre du Labex Art H2H Scène Augmentée, j'avais créé une **Marionnette Virtuelle** à mon effigie (Figure 115).

<figure><img src="image_118.png" /><figcaption>Figure 115 : *Cou2garnak* (2016)</figcaption></figure>

Cette marionnette reposait là encore sur l'utilisation d'une **Kinect2** et d'un automate à états. J'ai utilisé plusieurs gestes que j'ai tendance à faire de manière inconsciente<fnref n="1" />. J'ai par exemple, tendance à me gratter la tête ou positionner mes mains sur mes hanches. Ces gestes caractéristiques sont très simples à identifier et je n'ai eu aucun mal à pouvoir les détecter sans avoir recours à des techniques très évoluées d'analyse d'image.

Pendant ma conférence, j'ai orchestré une interruption inopinée de la part de ma doublure numérique se mettant à commenter mon propos : il s'en suivait une conversation entre mon avatar et moi, que je tentais de contrôler par mes positions gestuelles. Je n'étais, cependant, jamais très sûr de savoir quel geste il avait reconnu

<footnote n="1">¹ Je m'en étais aperçu en regardant un de mes cours qui avait été enregistré</footnote>
et sur quelle piste narrative il allait m'entraîner. Nous reviendrons plus en détail sur le souci de scénarisation que ce genre de dispositif nécessite dans le chapitre 4.3.2.

Cette performance/conférence fut très enrichissante pour moi, car bien que conscient du statut de **Marionnette Virtuelle** de l'entité se trouvant face à moi, je ne pouvais garantir à cent pour cent le comportement de ma **Marionnette Virtuelle**. Il y a donc une surprise et un jeu créé entre l'animateur et la créature virtuelle. Mais au-delà de cette première expérience, j'aimerais surtout réussir à explorer « l'inversion de l'interaction » ou, en tout cas, interroger le sens qui voudrait que le manipulateur manipule la marionnette !

### 3.3.3.3 Inverser la relation

C'est dans ce sens que j'ai réalisé *Ca bug dans les rotations* (Plessiet 2018c); le portrait interactif de Georges Gagneré. Ce tableau est né d'une anecdote, Georges Gagneré me faisant remarquer que l'une de mes Marionnettes Virtuelles avait sa rotation déviée au cours du temps. Pour le taquiner, j'ai fait ce portrait de lui (Figure 116a).

Le dispositif est une simple **Marionnette Virtuelle**. En dessous de l'écran se trouve une petite manette de jeu qui permet de faire tourner la tête soit à droite soit à gauche. Si nous ne faisons rien, au bout d'un moment la tête du **double autre** de Georges Gagneré se met à se tordre (Figure 116b). Le **double autre** se met alors à appeler à l'aide et demande d'actionner le mécanisme soit à droite soit à gauche.

En actionnant le mécanisme, le manipulateur peut essayer de suivre les ordres ou de désobéir et la marionnette s'énervera (ou plutôt l'action du manipulateur déclenchera des animations de la marionnette qui s'énerve). Il est extrêmement dur de ramener la tête de la marionnette à sa position neutre, à cause de l'inertie du système.

Mais qui est le vrai manipulateur ? Est-ce la personne qui actionne le mécanisme ? La marionnette qui donne l'ordre de redresser sa tête ? ou le créateur du dispositif ? Quoi qu'il en soit, même si nous sommes bien en face d'une simple marionnette, le scénario a été écrit de manière que le manipulacteur obéisse (ou désobéisse) en tout cas réagisse. Ceci inverse donc bien l'interaction dans une boucle
de rétroaction. J'aimerais par la suite travailler encore sur des scénarisations, peut-être plus complexes, pour donner l'impression d'une vie propre de la marionnette. C'est une tromperie, bien sûr, puisque cette **Marionnette Virtuelle** n'est qu'un dispositif qui réagit aux actions d'un interacteur.

<figure><img src="image_119.png" /><figcaption>Figure 116 : Ça bug dans les rotations (a) avant la rotation de la tête (b) et en cours d'interaction</figcaption></figure>
4 Golem Virtuel
Dans la partie précédente, nous avons étudié la notion de **Marionnette Virtuelle** en la définissant comme une **Sculpture Matrice** dotée d'une potentialité de mouvement, mais dont les prises de décisions et les éléments moteurs sont déclenchés par un marionnettiste extérieur. Nous nous sommes intéressés aux relations de dépendance liant marionnettiste et marionnette, procédant par des contrôles mimétiques ou dissociés. Même inconscient de l'influence de ses actions sur l'entité virtuelle, le marionnettiste reste à l'origine du mouvement de cette dernière.

Nous allons à présent examiner la possibilité de l'existence d'une entité dotée d'initiative de mouvement, une entité que nous pourrions alors assimiler au Golem obéissant des contes fantastiques

## 4.1 Golem et Cybernétique

Penchons-nous tout d'abord sur le Golem, cette créature magique issue des légendes hébraïques. Créée par un rabbin s'appuyant sur la mystique juive, cette statue de pierre a été conçue pour servir son maître et lui obéir aveuglément. Mais comment cette statue d'argile devient-elle, du fait de sa force immense et de sa croissance hors de contrôle, à la fois protectrice et destructrice ?

Au-delà du mythe, la kabbale juive, pratique ésotérique qui s'appuie sur les lettres et les chiffres n'aurait-elle pas eu une influence sur Norbert Wiener ?

Ne peut-on pas imaginer un Golem numérique qui serait une entité virtuelle issue d'une Sculpture Matrice et que la cybernétique pourrait doter des compétences nécessaires pour répondre aux ordres de son maître ?

### 4.1.1 Mystique hébraïque et créature d'argile

Le Golem peuple les légendes juives et les écrits fantastiques. On y relate l'histoire d'un homme détenteur du savoir magique issu de la kabbale<fnref n="1" /> capable de créer une statue d'argile s'animant pour lui obéir et le protéger en serviteur docile.

<footnote n="1">¹ Définition cnrl de la Kabbale : XVle siècle. Emprunté de l'hébreu qabbala, « tradition ». Dans la tradition juive, interprétation de la Bible dans un sens symbolique et</footnote>
Mais parfois, ce Golem échappe au contrôle de son maître. Ainsi, au lieu d'être protecteur, il devient un destructeur dont la force et la taille gigantesque deviennent alors source de malheur pour ceux qu'il était supposé servir.

Le lien entre le Golem et le robot paraît évident : ne sont-ils pas tous les deux des serviteurs construits par les hommes pour les aider dans leurs tâches, mais qui s'ils sont mal programmés ou mal utilisés, portent en eux le risque d'une destruction de leurs créateurs/manipulateurs.

### 4.1.1.1 Un gardien d'argile

Le Golem est généralement décrit comme une statue d'argile, un colosse de forme surhumaine, qui ne dispose pas de libre arbitre et ne prononce aucun mot. Dans certaines légendes, son front est marqué par le mot אמת "Emeth" qui veut dire "Vérité", l'un des noms de Dieu dans la tradition hébraïque.

<figure><img src="image_120.png" /><figcaption>Figure 117 : rabbin Loew et le Golem de Prague par Mikoláš Aleš (1899)(source wikipedia)</figcaption></figure>

Si l'on trouve des traces du Golem dans le livre des psaumes<fnref n="1" /> et dans le folklore juif polonais, une des légendes les plus connues date du XVle siècle et

<footnote>ésotérique ; l'ensemble des commentaires où a été consignée cette tradition. Les docteurs de la kabbale.(cnrtl, s. d.)</footnote>

<footnote n="1">¹ Psaumes 139 : 16 Tes yeux m'ont vu, lorsque j'étais comme une masse informe (Golem), et sur ton livre étaient inscrits tous les jours qui m'étaient réservés, quand aucun d'eux n'existait.</footnote>
rapporte qu'un rabbin de la ville de Prague, le rabbi Yehida Loew, aurait créé un Golem
pour protéger la communauté juive accusée par les chrétiens de meurtres rituels
d'enfants (Figure 117) (Baer 2017). Pour arrêter les dégâts engendrés par sa créature
d'argile, le Rabbin lui demanda de s'agenouiller pour refaire son lacet et il effaça la
lettre א à l'inscription sur le front du Golem formant ainsi le mot מת "Meth" - "Mort", alors
le Golem cessa de s'animer.

Cette légende qui est la plus connue, a été l'objet d'un grand nombre
d'adaptations, comme le film expressionniste allemand *Le Golem de Paul Wegener et
Carl Boese* (Wegener et Boese 1920), ont certains éléments ne sont pas sans rappeler
ceux du roman *Frankenstein ou le Prométhée moderne de Mary Shelley* (Shelley
1831).

4.1.1.2 La créature qui échappe à son maître

Le Golem est un être ambivalent, à la fois protecteur et destructeur (Morel et Ackerman 2017). Il est souvent vu comme le gardien de la communauté juive, tout en étant porteur d'une certaine monstruosité<fnref n="1" />. Cependant il est intéressant de noter que les différentes versions des légendes n'expliquent pas toutes de la même manière l'apparition de ce caractère destructeur.

Certaines évoquent des ordres mal donnés : par exemple la femme du Rabbi de Prague ordonnant au Golem de remplir des tonneaux par une mauvaise formulation conduisant la créature à inonder la maison, car cette dernière ne s'arrêtait plus de les remplir (Baer 2017). Il est intéressant de noter, dans ce cas, que le Golem devient destructeur par des ordres mal donnés. D'autres versions mettent en cause la taille du Golem, en perpétuelle croissance (Heudin 2008) : les gestes de celui-ci devenant de plus en plus malhabiles sont ainsi cause de de destructions.

Alors, le risque apparaît double : celui de la créature à qui l'on adresse des
ordres mal formulés et celui de l'entité détruisant non pas par cruauté, mais du fait de
son évolution physique même.

<footnote n="1">¹ Ce que certains spécialistes associent à une certaine forme d'antisémitisme déguisé (Gelbin 2010, page 74).</footnote>
La figure du Golem véhicule une idée forte qui trouve un écho dans ma pratique, mais aussi dans la robotique et l'informatique actuelle, celle du pouvoir de création de la vie, même si elle est artificielle. Elle reprend ainsi ce qui a été pensé par les religions comme l'apanage de dieu, mais bien entendu à condition « d'être suffisamment sage, travailleur et savant....

### 4.1.1.3 La métaphore du Robot

Il existe un lien fort entre le Golem de la tradition juive et le robot de $R \cup R^1$ (Rossum's Universal Robots), une pièce de théâtre écrite en 1920 par Karel Čapek(Vas-Deyres 2015). Le terme de « robot », utilisé pour la première fois dans cette pièce, a été inventé par Josef Čapek, le frère de Karel Čapek. Si le mot désigne des créatures d'apparence humaine dépourvues de libre arbitre, c'est surtout son étymologie qui interpelle, *robota* désigne corvée et *rob* veut dire esclave dans les langues slaves, donc « un travailleur qui accomplit les corvées »

Dans la pièce de Čapek, j'ai remarqué qu'il n'y a pas, à l'origine, de rébellion de la part des robots, même lorsque des personnages sont susceptibles de les pousser à la révolte<fnref n="2" />:

**DOMIN**

> Ma chère Mlle Glory, nous avons eu près de cent sauveurs et prophètes ici. Chaque navire nous en apporte. Missionnaires, anarchistes, Armée du Salut, toutes sortes. Il est étonnant de voir combien d'églises et d'idiots existent dans le monde.

**HELENA**

> Et vous les laissez parler aux Robots ?

**DOMIN**

<footnote n="1">¹ Dans cette pièce de théâtre d'anticipation, des androïdes dénués de sensibilité et d'émotion travaillent dans une usine Ils finissent par se révolter après qu'un ingénieur eut décidé de leur donner des sentiments et un peu plus d'intelligence.</footnote>

<footnote n="2">² Traduction personnelle</footnote>
> Jusqu'à présent, nous les avons tous laissés, pourquoi pas ? Les robots se souviennent de tout, mais c'est tout. Ils ne se moquent même pas de ce que les gens disent. Vraiment, c'est assez incroyable. Si cela vous amuse, mademoiselle Glory, je vous emmènerai dans l'entrepôt de robots. Il en détient environ trois cent mille. (Čapek 1924, page 23)

Cependant, la pièce évolue quand le docteur Gal dote le robot Radius d'un cerveau plus grand et d'une âme. La machine décide alors de ne plus obéir et de devenir le "maître des hommes". Ainsi, quand on le dote d'une « âme » et d'un libre arbitre il devient destructeur pour l'homme en brisant et en inversant la relation maître esclave.

## 4.1.2 Norbert Wiener et le Golem

Norbert Wiener élabore sa théorie de la **cybernétique** en 1947. Il est ainsi à l'origine de l'informatique telle qu'on la connaît aujourd'hui, mais comme nous allons le voir, il n'a jamais caché l'influence que le Golem a eue sur ses recherches.

Qu'elle serait l'analogie entre la kabbale et l'informatique ? Ce parallèle, audacieux et intéressant, s'inscrit dans la continuité de ma réflexion consistant à percevoir les langages de programmation comme un "outil à matérialiser de l'imaginaire".

Est-ce que Wiener pressent le danger potentiel de cette science nouvelle dont il est l'un des créateurs ? A-t-il conscience que, si cette science n'est pas en elle-même la source d'où provient le risque, elle pourrait le devenir, comme pour le Golem, par une mauvaise compréhension de ses tenants et aboutissants ?

### 4.1.2.1 Le père de la cybernétique

Wiener commence à théoriser la cybernétique (Wiener 1962) après le premier cycle des conférences de Macy. Ces conférences se sont déroulées à New York en deux cycles successifs, le premier entre 1946 et 1948 et le second entre 1949 et 1953.
Les organisateurs, la *Fondation Macy*<fnref n="1" /> et le neuropsychiatre Warren McCulloch souhaitaient des réflexions interdisciplinaires, mêlant mathématiciens, biologistes, économistes, psychologues, afin de penser une "science générale du fonctionnement de l'esprit". Si cette volonté de recherche interdisciplinaire autour d'une science émergente est vraiment fructueuse, je pense que le regard décalé des artistes aurait pu, déjà à l'époque, enrichir le débat. La cybernétique influencera grandement notre conception moderne de l'informatique, bien que sa finalité dépasse ce seul domaine et a vocation à s'appliquer à tout système, qu'il soit conceptuel, sociétal ou technologique.

La première cybernétique repose sur la notion de feed-back (Figure 118) au sein d'un système que l'on assimile à une boîte noire, entre des récepteurs qui récupèrent des stimuli dans l'environnement, c'est-à-dire des informations et des émetteurs qui retournent des réponses. Le système agit donc à la fois sur son environnement et sur lui-même, dans un feed-back : la réponse influence les stimuli d'entrées qui « en retour » modifient les réponses en sortie dans une boucle sans fin (boucle de rétroaction).

<figure><img src="image_121.png" /><figcaption>Figure 118:La boucle cybernétique (Bret 2002)</figcaption></figure>

<footnote n="1">¹ « En 1930, une héritière de la famille (Macy), Kate Macy Ladd, dote la fondation en spécifiant que les revenus devront servir principalement les sciences médicales, mais que la biologie et les sciences sociales pourront être admises en tant que sciences auxiliaires. Sous la direction scientifique d'un neurologue-psychiatre, Frank Fremont-Smith, la Fondation Macy va organiser dans les années 40 et 50 un nombre important de cycles annuels de conférences résidentielles. » (Winkin 1984, page 87)</footnote>
### 4.1.2.2 L'influence de la mystique juive

Mais au-delà de cette théorie de la cybernétique, c'est la personnalité de Weiner qui m'a, finalement, aussi influencé. En effet, bien qu'agnostique, mais d'origine juive, il n'a jamais caché l'influence de la kabbale et donc du Golem(Vas-Deyres 2015) sur la **cybernétique** (Wiener et Mopsik 2016).

Dans le livre fondateur de la **cybernétique**, Cybernetics: or control and communication in the animal and the machine, Norbert Wiener écrit :

> « Ce désir de produire et d'étudier les automates a toujours été exprimé par la technique. Au temps de la magie, nous avions affaire au bizarre et sinistre concept de Golem, cette figure d'argile à laquelle le Rabbin de Prague a donné vie en utilisant de manière blasphématoire l'ineffable nom de Dieu » (Wiener 1962, pages 39-40)

La kabbale est, avant tout, une mystique ésotérique juive qui suggère que, derrière les textes sacrés de la Thora, Jehova aurait caché les règles secrètes qui gouvernent le monde. La Kabbale repose avant tout sur un ensemble de règles permettant de déchiffrer le sens caché des choses en se basant à la fois sur un ouvrage majeur, le *Sefer Yetsirah* et des règles numérologiques (Figure 119) qui permettent de permuter les lettres (Scholem and Dan 2007).

<figure><img src="image_122.png" /><figcaption>Figure 119 : les correspondances entre lettre et nombre</figcaption></figure>
Mais ce n'est pas dans cet aspect mystique que « *la machine* (...) est l'homologue moderne du Golem du rabbin de Prague » (Wiener et Mopsik 2016). Dans la Kabbale, la combinaison de lettres, chacune associée une valeur numérique<fnref n="1" /> permet d'élaborer une formule magique. Il y a, pour Michel Faucheux, une analogie avec le langage binaire :

> Pour Scholem plusieurs caractéristiques permettent d'établir une analogie entre l'ordinateur et le Golem. D'abord si l'ancien Golem était fabriqué au moyen des vingt-deux lettres de l'alphabet hébraïque, l'ordinateur est, lui, basé sur un système mathématique reposant sur les nombres "Il me semble que les vieux kabbalistes éprouveraient aujourd'hui une certaine satisfaction s'ils pouvaient avoir connaissance de cette simplification de leur invention". Il y a ici progrès de même, les deux Golems sont agis par une énergie : l'énergie du discours, le SHem ha-Meforash pour, le nom de Dieu pleinement interprété, exprimé, différencié pour l'un et l'énergie électronique pour l'autre (Faucheux 2008, page 27)

Tout comme la Kabbale prétend définir et manipuler notre monde par la combinaison de lettres et de mots régis par des règles numérologiques, l'informatique utilise une combinaison de lettres et de mots régis également par des règles mathématiques pour définir et manipuler notre monde (la répétition est à la fois volontaire et ironique).

Si l'analogie est forte, je pense que nous ne devons pas la prendre au pied de la lettre, il n'en demeure pas moins que le parallèle entre la **cybernétique** et le Golem que fait Wiener est parfaitement compréhensible, ainsi que sa mise en garde sur une mauvaise utilisation de ses théories.

<footnote n="1">¹ Je ne peux m'empêcher d'y voir une analogie avec les codes ASCII utilisés en informatique.</footnote>
### 4.1.2.3 La peur du Golem

Malgré sa participation à un programme militaire<fnref n="1" /> de défense anti-aérienne pendant la Seconde Guerre mondiale, Wiener était un pacifiste<fnref n="2" /> partageant une vision idéaliste de la science (Cassou-Noguès 2014). Il n'hésitait pas à mettre en garde contre une mauvaise utilisation de ses technologies comme cette citation mentionnée par Daniel Moatti :

> *En sorcellerie, on doit toujours demander ce qu'on veut vraiment et non quelque chose qu'on semble vouloir. C'est la même chose avec l'automatisme moderne ; il est très facile de demander ce qu'on pense vouloir et qu'on ne veut pas. C'est un danger réel, spécialement de nos jours, quand il y a la possibilité d'employer les machines qui apprennent, qui jouent le jeu de la guerre, pour contrôler quand on doit pousser le bouton déclenchant une guerre mondiale. Le seul moyen de l'éviter est de considérer la machine non comme but en soi-même, mais comme un moyen de satisfaire les demandes de l'homme, comme une partie d'un système humano-mécanique (Moatti 2011, page 15).*

Cet extrait saisissant souligne deux problèmes, le premier avec l'analogie à la sorcellerie montre à quel point Wiener était sensible au risque d'incompréhension de la machine face à une instruction manquant de clarté. Le second souligne qu'au moment où la machine à la capacité d'autonomie (apprentissage, etc.) la laisser décider seule à la place des humains représente un danger qui pourrait conduire à la destruction de l'humanité. La solution de Wiener face à ce danger est de collaborer avec la machine dans un système humano-mécanique où l'humain garderait sa responsabilité. Ceci rejoint les risques mis en scène par Čapek, ou ceux soulignés plus récemment par le physicien Stephen Hawking dans *un entretien à la BBC*, le 3 décembre 2014, avec Rory Cellan-Jones :

<footnote n="1">¹ il refusa par contre de travailler sur le projet Manhattan (élaboration de la bombe « atomique »).</footnote>

<footnote n="2">² Il a été traumatisé par la guerre, la terreur nazie et les camps de concentration, ce qui l'a amené à une certaine forme de perte de confiance en l'homme.</footnote>
> « Les formes primitives d'intelligence artificielle que nous avons déjà se sont montrées très utiles. Mais je pense que le développement d'une intelligence artificielle complète pourrait mettre fin à l'humanité».(Rory Cellan-Jones 2014)

Les prédictions d'Hawking ne sont pas sans rappeler les dégâts engendrés par la croissance du Golem :

> « Une fois que les hommes auraient développé l'intelligence artificielle, celle-ci décollerait seule et se redéfinirait de plus en plus vite ».(Rory Cellan-Jones 2014)

Si je comprends et partage en partie l'opinion sur les dangers évoqués plus haut, j'espère que le développement de l'une (une intelligence artificielle) n'entraînera pas obligatoirement la destruction de l'autre (l'humanité), mais conduira plutôt à une co- évolution par la création de ce que Wiener appelle un système humano-mécanique.

## 4.1.3 Le Golem informatique

À partir de cette description du Golem de la tradition juive, nous pouvons par analogie définir le Golem informatique comme une **Sculpture Matrice** que l'on va doter de mécanismes moteurs, mais qui ne disposera pas de « libre arbitre », c'est-à-dire de mécanisme décisionnel.

Le rapport change donc entre l'opérateur et l'entité informatique : dans le cas de la **Marionnette Virtuelle**, nous avons un rapport entre un manipulateur et un manipulé et dans le cas du **Golem Virtuel**, nous avons une relation entre un maître et un esclave, autrement dit entre un donneur et un exécuteur d'ordre.

Si avant nous devions élaborer pour la **Marionnette Virtuelle** des mécanismes de manipulation nous devons doter notre Golem d'un mécanisme lui permettant de comprendre les ordres et de capacités pour pouvoir agir par lui-même.

### 4.1.3.1 Mouvement intérieur et décision extérieure

Nous avons démontré au chapitre 3.1 que la **Marionnette Virtuelle** a besoin d'une entité extérieure à elle-même comme source du mouvement et de la décision.
Le concept de **Golem Virtuel** repose sur une différence fondamentale : il peut se mouvoir par lui-même. Là où la **Marionnette Virtuelle** a besoin d'un manipulateur pour être actionnée, le Golem, lui, dispose de mécanismes actuateurs qui lui permettent d'agir sur son environnement et sur lui-même.

Le Golem est donc en mesure de " produire du mouvement " et si nous souhaitons exactement prévoir son comportement (sans que cela soit pour autant obligatoire), nous devons alors comprendre sa "manière de penser". Auparavant, nous n'avions qu'un transfert de mouvement de l'un à l'autre, soit en temps réel (**mocapteur /datacteur**), soit en temps différé (animateur traditionnel).

Je distingue deux types de mouvements à simuler : d'une part les gestes qui n'entraînent pas de lien direct avec l'environnement, par exemple, se gratter la tête ou cligner des yeux et d'autre part, ceux qui entrent en interaction avec l'environnement, par exemple marcher sur le sol ou prendre quelque chose.

Le premier type de mouvement nécessite avant tout des mécanismes kinesthésiques, alors que le second doit en plus utiliser des systèmes de modélisation du monde virtuel comme il en existe pour la catégorie « des acteurs autonomes dotés de capacités d'action et de perception dans le monde virtuel » définie par Thalmann (Thalmann 1996).

Au-delà de ces mécanismes moteurs, nous devons doter notre Sculpture Matrice de la capacité à percevoir et à analyser une instruction donnée, quand bien même celui qui décide de l'ordre reste une entité extérieure.

En résumé, le **Golem Virtuel** est une **Sculpture Matrice** dotée de mécanismes générateur de mouvement, mais qui ne dispose pas de libre arbitre (Figure 120).
<figure><img src="image_123.png" /><figcaption>Figure 120 : le positionnement du Golem dans notre cartographie</figcaption></figure>

### 4.1.3.2 Un rapport maître/esclave ?

Le rapport entre l'utilisateur et l'entité virtuelle change complètement. Auparavant, il y avait une manipulation directe, alors que dans la relation qui se noue avec le **Golem Virtuel**, un ordre est soumis à l'interprétation du **Golem Virtuel**. Je ne manipule plus l'entité virtuelle pour qu'elle aille d'un point A à un point B, j'indique au **Golem Virtuel** le point B à atteindre et il va planifier son chemin. Est-ce que le chemin qu'il prendra sera celui auquel, moi, utilisateur, j'ai pensé ?

La relation évolue, basculant d'un rapport "manipulateur/manipulé" à un rapport "maître/esclave": le maître ordonne, l'esclave<fnref n="1" /> obéit en utilisant ses compétences propres. Ceci entraîne le risque de multiplier les biais de traductions. L'ordre peut être mal compris et mal exécuté.

Toujours par opposition avec la **Marionnette Virtuelle**, si auparavant l'entité extérieure était mobilisée sur l'ensemble du processus manipulatoire, elle peut à présent en déléguer une partie au **Golem Virtuel** et ainsi acquérir un nouveau statut de "méta-manipulateur", c'est-à-dire un manipulateur agissant à un niveau d'abstraction supérieure.

<footnote n="1">¹ J'utilise le terme esclave, plutôt que serviteur, pour souligner que cette entité sans condition de liberté, est sous la dépendance totale d'un maître. Le terme serviteur induisant une volonté de la part de l'entité à servir le maître dans le cadre d'un contrat ou d'un échange choisi et pouvant se rompre (salaire, gite...).</footnote>
Ceci entraîne un réagencement des mécanismes empathiques mis en place jusqu'à présent par le **manipulacteur** et le **mocapteur** dans la manipulation de l'entité, car il n'est plus nécessaire de "se mettre à la place de". Le **Golem Virtuel** s'autonomise et gagne son statut "d'entité propre" là où, auparavant, la marionnette était un outil relié à son manipulateur dans une boucle d'interaction simple.

Nous nous apercevons tout de suite que l'architecture du **Golem Virtuel** devient beaucoup plus complexe que celle évoquée dans la **Marionnette Virtuelle** (cf. Chapitre 3.1.1) et introduit un élément important dans son fonctionnement : la capacité à exécuter une succession d'ordres.

### 4.1.3.3 Algorithmie et exécution d'ordres

La spécificité du **Golem Virtuel** se situe dans sa capacité à exécuter un algorithme pour pouvoir obéir à son maître. Mais qu'est-ce qu'un **algorithme** ? S'il existe des définitions formelles et mathématiques, la définition de Hervé Bernard correspond mieux à ma perception du fonctionnement du **Golem Virtuel** :

> *Un algorithme, c'est tout simplement une façon de décrire dans ses moindres détails comment procéder pour faire quelque chose (...) Le but est d'évacuer la pensée du calcul, afin de le rendre exécutable par une machine numérique (ordinateur...). On ne travaille donc qu'avec un reflet numérique du système réel avec qui l'algorithme interagit (Bernard 2018)*

Nous devons donc décrire la succession des étapes exécutables par le **Golem Virtuel**, qui interagit avec une modélisation, un reflet numérique du système réel. Cette suite d'instructions pourra être invoquée à tout moment par le "maître du **Golem Virtuel**". Le Golem ne fait que suivre une succession d'ordres en fonction d'une demande externe et agira dans son environnement.

Si l'**algorithme**, en tant que succession d'ordres à suivre, est un des composants essentiels du **Golem Virtuel**, ce dernier doit également disposer de senseurs pour capter des informations externes ou internes et des actuateurs pour agir sur lui-même et dans l'environnement. Ceci n'est donc pas sans nous rappeler la définition de la **cybernétique** du premier ordre telle que décrite par Wiener. La boîte noire contient les **algorithmes** qui se situent entre les entrées et les sorties.
Ainsi, l'architecture d'un **Golem Virtuel** devient beaucoup plus complexe que celle de la **Marionnette Virtuelle**. Pour cette dernière, nous n'avons qu'un système de captation des entrées des manipulateurs, un mécanisme d'actuation (sorties) et un système de correspondance entre les entrées et les sorties, alors que pour le **Golem Virtuel** nous avons :

* Un mécanisme d'écoute de l'environnement ;

* Un mécanisme d'écoute du méta-manipulateur ;

* Un mécanisme de modélisation de son environnement ;

* Un mécanisme d'exécution de l'ordre ;

* Un mécanisme d'actuation.
## 4.2 « Obéît à ton maître ! »

Le **Golem Virtuel** est donc une entité actante qui dispose des moyens d'obéir aux ordres : s'il fait preuve d'une certaine autonomie, il n'en reste pas moins un exécutant dont les capacités et les modalités d'actions sont développées et fixées une fois pour toutes au moment de sa conception.

Le système de figurants développé dans le cadre du projet *OutilNum*, décrit plus longuement dans la partie 5.2.2, est un parfait exemple de **Golem Virtuel**. Ces entités disposent d'un certain degré d'autonomie définie par une série d'algorithmes qui leur permettent d'agir et de répondre aux ordres dans une application de prévisualisation on-set à destination du cinéma.

Les éléments qui composent ces "figurants virtuels" deviendront par la suite les modules de base pour la création du **Golem Virtuel** Lucky au centre de mon installation artistique *Lucky 2.0*. Directement inspiré du personnage de Lucky dans la pièce de théâtre *En attendant Godot* de Samuel Beckett(Beckett 1952), il a été exposé dans plusieurs festivals.

### 4.2.1 Donner les moyens d'obéir aux ordres

Pour qu'il y ait **Golem Virtuel**, il faut qu'il y ait un mécanisme de perception de son environnement externe, mais aussi de son état interne et un mécanisme de décision. Si les mécanismes d'entrée ont déjà été évoqués, en 0 et les mouvements des marionnettes virtuels ont fait l'objet du chapitre 4.1.2, les différences sont importantes entre la « boite noire » de la **Marionnette Virtuelle** et celle du **Golem Virtuel**.

Il y a nécessité pour le **Golem Virtuel** de créer une modélisation de son environnement, car c'est à lui d'agir dans le monde en fonction de sa propre perception de celui-ci, alors que la **Marionnette Virtuelle** n'est que le vecteur de l'action du marionnettiste, issu de l'extérieur. L'exemple est assez flagrant lorsque nous étudions la mise en place d'algorithme de navigation (**pathfinding**) ou des mécanismes de préhensions.
### 4.2.1.1 Percevoir son environnement et percevoir son statut interne

Nous avons évoqué en 4.3.2.2 le système d'*acting_input*, qui permet à notre Sculpture Matrice de percevoir les données issues des actions du marionnettiste. Le système présenté dans ce chapitre est la version simplifiée d'un mécanisme plus général.

Les AKNActingInput ne sont en réalité qu'une **classe** plus spécialisée d'une notion plus large, les AKN_Sensor, qui désigne un ensemble de senseurs, registres sensoriels et filtres sensoriels, mais aussi un accès à la mémoire à court terme en lecture.

Ces AKN_Sensor sont de trois ordres :

*   **AKN_RW_Sensor** : entrée issue du monde réel (les AKNActingInput sont en fait une généralisation de ces classes), RW étant les initiales de Real World (par exemple une webcam ou un microphone) ;

*   **AKN_VW_Sensor** : entrée issue du monde virtuel par exemple la position de l'objet à atteindre, ou une position spatiale à regarder, VW étant les initiales de Virtual World ;

*   **AKN_Internal_Sensor** : entrée provenant de la structure interne du **Golem Virtuel**, par exemple des informations biomécaniques<fnref n="1" /> (AKN_BodyInput) ou des informations sur son état (en désignant par exemple l'état en cours et la matrice de connexion d'un **automate à état**);

Cette architecture sera détaillée dans la partie 4.2.1.3, mais il est dès à présent intéressant de percevoir sa logique évolutive (Figure 121), puisque nous pouvons aisément ajouter ou spécifier de nouvelles entrées héritant de AKN_Sensor.

Le principe d'un AKN_Sensor (dans le cas d'un AKN_VW_Sensor ou d'un AKN_Internal_Sensor) est d'utiliser en entrée une donnée informatique discrétisée. Les AKN_RW_Sensors traitent une donnée issue du monde réel, non discret, qui sera

<footnote n="1">¹ Par exemple l'angle entre le bras et l'avant-bras.</footnote>
discrétisée à la suite d'un traitement informatique. Ce dernier cas peut faire appel à l'utilisation de **bibliothèques** de programmation spécifiques, comme **Opencv** pour le traitement d'une image issue d'une webcam ou d'un appareil photographique, ou la bibliothèque **SAPI 5.0** pour le traitement de la **reconnaissance vocale**.

<figure><img src="image_124.png" /><figcaption>Figure 121 : hiérarchie de la classe AKN_Sensor et de ses classes enfants</figcaption></figure>

### 4.2.1.2 Représenter le monde

Si les AKN_Sensor nous permettent de modéliser les "sens" du **Golem Virtuel**, il faut lui trouver un moyen de représenter son monde et ses connaissances. Le travail réalisé autour de la représentation du monde et des connaissances accumulées par le **Golem Virtuel** est sans doute celui qui a le plus évolué durant mes recherches : dans mes premiers travaux, rien n'était précisément implémenté, alors que dans mes travaux plus récents, j'ai fait un effort de structuration plus ontologique.

Ainsi, si mon **Golem Virtuel** doit se déplacer dans le monde virtuel, je dois doter ce monde d'une représentation de l'espace de navigation. Ceci peut se faire par
un graphe de navigation, même si je privilégie à présent une solution de navigation directement intégrée au moteur (Figure 122). Je suis malgré tout parfaitement conscient qu'il existe en informatique des approches plus rigoureuses pour résoudre les problèmes de navigation et plus en accord avec les sciences cognitives de personnage 3D.

Pour les données et informations que le **Golem Virtuel** doit se remémorer à court et moyen terme, les approches les plus traditionnelles consistent à stocker la valeur reçue en entrée dans une variable prévue à cet effet. Par exemple, je peux stocker une chaîne de caractères contenant le nom de l'interlocuteur du **Golem Virtuel** dans une variable nom_interlocuteur, ceci dès que le **Golem Virtuel** aura obtenu cette information par une ou plusieurs de ses entrées.

Ce système est trop limité, car il manque de flexibilité. J'ai fait le choix, dans un premier temps, de l'utilisation de dictionnaires<fnref n="1" /> capables de contenir des variables définies au cours de l'existence du **Golem Virtuel**. Par la suite, j'ai opté pour une architecture reposant sur un **blackboard** (Millington et Funge 2009, pages 459-466) tout d'abord implémentée par moi-même, puis directement présente dans le moteur **Unreal**. Je dois d'ailleurs noter ici avoir ressenti un sentiment ambigu. Je suis à la fois content d'avoir anticipé la nécessité d'un développement informatique en le réalisant moi-même, fier de conster plus tard que cela a été implémenté directement dans une nouvelle version du logiciel Unreal, ceci confirmant que l'idée était bonne, mais aussi d'un peu de désappointement face à cette course sans fin, en même temps stimulante, entre un travail de recherche et l'innovation commerciale

Actuellement, comme nous le décrirons dans le chapitre 6.2.3.3, la représentation des différentes informations enregistrées par le **Golem Virtuel** est directement inspirée par une structure fortement basée de la notion de **STRIP**. Mais nous verrons que cette façon de mémoriser les informations rencontre des limites, celles liées à une profonde différence avec notre propre fonctionnement humain et

<footnote n="1">¹ En informatique, un dictionnaire de données est une structure de données qui utilise des couples composés d'un identifiant unique (la clé) et d'une valeur et qui permettent de retrouver rapidement une valeur donnée.</footnote>
celles dues à la nécessité de mémoriser des données discrétisables compréhensibles par un ordinateur.

<figure><img src="image_125.png" /><figcaption>Figure 122 : le navmesh en vert généré automatiquement par le moteur de jeu Unreal</figcaption></figure>

### 4.2.1.3 Suivre les ordres

Nous venons d'exposer la manière dont notre **Golem Virtuel** est doté de sens (voir le chapitre 4.2.1.1), d'une représentation mentale de son environnement et de lui-même (voir le chapitre 4.2.1.2). Il faut maintenant porter notre attention sur les mécanismes qui lui permettent d'exécuter l'ordre : une fois l'ordre perçu par le Golem, ce dernier doit traiter la série d'étapes à réaliser pour mener à bien l'ordre reçu, ce qui correspond à la définition même d'un algorithme.

Les informaticiens ont développé de nombreux algorithmes pour répondre à des problèmes spécifiques : ainsi, l'algorithme $A^*^1$ est particulièrement adapté pour trouver un chemin pour aller d'un point A à un point B. Les **automates à états**, les **arbres de décisions** et les **arbres de comportements** sont quant à eux efficaces pour définir une succession de tâches à effectuer en fonction d'un ordre reçu. Ces algorithmes reposent tous sur des **graphes**<fnref n="2" />. En faisant ressortir ce point commun,

<footnote n="1">¹ L'algorithme $A^*$ est un algorithme de recherche de chemin inspiré de l'algorithme de Dijkstra qui repose sur un graphe entre un nœud initial et un nœud final grâce à une fonction heuristique (distance par exemple)</footnote>

<footnote n="2">² Les graphes sont d'ailleurs les bases architecturales d'AKeNe</footnote>
nous pouvons donc en déduire que le « cerveau » d'un **Golem Virtuel** doit pouvoir
analyser des **graphes**<fnref n="1" />.

C'est pourquoi, dans mon architecture, l'objet AKN_Brain peut lire un **graphe**
dont chaque noyau peut contenir un de ces différents algorithmes qui, en fonction des
valeurs en entrées, actionnent les actuateurs correspondants. Ces algorithmes
reposant sur des graphes, nous pouvons facilement imaginer un système récursif
Figure 123) de **graphes** dont les nœuds contiennent des algorithmes qui contiennent
eux-mêmes des **graphes**, cette récursion pouvant se répéter indéfiniment en fonction
des besoins<fnref n="2" />...

<figure><img src="image_126.png" /><figcaption>Figure 123 : l'architecture récursive</figcaption></figure>

À partir de cette architecture, nous pouvons décrire les ordres que peut
comprendre le **Golem Virtuel** et la façon de les exécuter : ce n'est plus qu'un travail
qui combine écriture scénaristique et réflexion informatique.

4.2.1.4 Agir sur soi et sur le monde

Notre **Golem Virtuel** peut sentir le monde, se faire une représentation de celui-
ci et planifier une série d'ordres. Il doit également être maintenant en mesure de les
exécuter en agissant soit sur lui-même soit sur le monde.

<footnote n="1">¹ Une liste chainée, étant la version la plus simple d'un graphe.</footnote>

<footnote n="2">² Je concède que pour le moment, je n'ai pas poussé très loin mon niveau de
récursion dans mes tests...</footnote>
Ceci se fait grâce à une classe AKN_Actuator qui modélise une interaction avec son environnement (Figure 124). On pourrait la conceptualiser comme la symétrique des AKN_Sensor (cf. chapitre 4.2.1.1) ainsi nous retrouvons :

*   **AKN_RW_Actuator** : qui ont, à la base, pour mission d'agir sur le monde réel (RW étant les initiales de Real World), mais qui ont vu leur fonction évoluer pour, au final, agir sur tout ce qui est extérieur au logiciel utilisé : par exemple, nous pouvons utiliser des AKN_RW_Actuator pour communiquer avec une application extérieure en utilisant un protocole réseau (**OSC**, ou notre propre protocole<fnref n="1" />);

*   **AKN_VW_Actuator** : ces actuateurs peuvent manipuler des objets : appuyer sur un bouton, prendre un objet dans le monde virtuel (VW étant les initiales de Virtual World) ou manipuler la structure externe du **Golem Virtuel**, par exemple le déplacer dans l'espace, ou lancer l'animation de tel ou tel membre. Nous avions développé en 3.2.2.2 le concept d'AKN_Puppetter. En réalité, ces AKN_Puppetter sont des AKN_VW_Actuator spécialisés ;

*   **AKN_Internal_Actuator** : les actuateurs internes permettent d'activer un comportement en urgence dans le cerveau (par exemple le AKN_Impulse<fnref n="2" /> qui peut déclencher une « réaction réflexe »), ainsi que d'enregistrer une information dans sa représentation du monde (comme les objets héritant de la classe AKN_Memorizer).

<footnote n="1">¹ Ce protocole n'est pas encore complètement stabilisé pour le moment.</footnote>

<footnote n="2">² Cette classe permet d'envoyer un message qui court-circuite toute la chaine de traitement elle peut s'appliquer aussi bien à l'entité elle-même ou à d'autres entités virtuelle, l'œuvre *la louve* que nous décrivons en 4.3.2.2 repose sur cette technique.</footnote>
<figure><img src="image_127.png" /><figcaption>Figure 124 : les AKN_Actuators</figcaption></figure>

Nous voyons comme l'architecture de notre **Golem Virtuel** s'est fortement complexifiée par rapport à celle de la **Marionnette Virtuelle**. L'architecture que nous avons choisie n'est pas la solution unique ; en fait, il n'existe pas une « architecture » de **Golem Virtuel**, mais plutôt un certain nombre de prérequis que l'architecture se doit de prendre en compte pour qu'elle puisse définir un **Golem Virtuel**. Nous pouvons en imaginer bien d'autres, il faut juste qu'elles comportent un système de captation d'entrées, un système d'actions dans l'environnement, un moyen de mémoriser des informations et un système pour exécuter des ordres.

## 4.2.2 Outilnum et le module « figurant »

Dans le projet *Outilnum*, nous voulions pouvoir occuper la scène avec des figurants virtuels qui obéissent aux ordres du metteur en scène et qui, en l'absence d'indications, « jouent à l'autonomie » (ce qui est en soi déjà un ordre). Ce sont donc
clairement des **Golems virtuels** que nous souhaitions réaliser. Nous avons donc décidé de mettre à l'épreuve le modèle décrit précédemment.

### 4.2.2.1 Un outil de prévisualisation on set à destination du cinéma

Ce système devait permettre à une équipe réduite de prototyper rapidement une scène, que ce soit dans le placement des éléments du décor, les interactions entre les acteurs, ainsi que le placement des éclairages et de la caméra. L'approche métier visait à découper l'application en différents modules, chacun dédié à une spécialité (Figure 125).

<figure><img src="image_128.png" /><figcaption>Figure 125 : les différents modules d'Outilnum</figcaption></figure>

* Le module Cameraman : Le rig caméra<fnref n="1" /> comprend un appareil Kinect et un trièdre permettant un suivi des mouvements de la caméra par un système de capture de mouvement optique. La caméra virtuelle reproduit le mouvement

<footnote n="1">¹ Un rig caméra est un dispositif qui équipe une caméra afin d'apporter des fonctionnalités supplémentaires.</footnote>
du rig caméra et les images générées par ordinateur sont affichées sur l'écran du rig caméra (Figure 126) ;

<figure><img src="image_129.png" /><figcaption>Figure 126 : le module acteur immergé et le module cameraman</figcaption></figure>

* Le module metteur en scène : une tablette tactile et une technologie de réalité augmentée permettent au metteur en scène de manipuler les objets 3D et des lumières de la scène virtuelle en manipulant des marqueurs réels (Figure 127) ;

* Le module acteur immergé : un acteur réel est immergé dans le monde virtuel à l'aide d'un casque de réalité virtuelle. Ses mouvements corporels sont captés par le système de capture de mouvement et transférés sur son corps virtuel (Figure 126) ;

* Le module avacteur décrit plus précisément en 1.3.3.3 permet d'intégrer une « image en relief » d'un acteur réel dans le monde virtuel ;
<figure><img src="image_130.png" /><figcaption>Figure 127 : Le module metteur en scène</figcaption></figure>

* Le module *acteur virtuel* : par ce module le metteur en scène peut donner des ordres à des figurants virtuels. Si aucun ordre n'est donné, ils exécutent le programme prédéfini (Figure 128).

<figure><img src="image_131.png" /><figcaption>Figure 128 : module acteur virtuel</figcaption></figure>

Ces modules présents sur des machines séparées étaient interconnectés entre eux par un protocole réseau spécifique.
### 4.2.2.2 Des fonctions de base

Les **Golems virtuels** d'OutilNum devaient être en mesure de traiter quatre problèmes principaux :

* Interagir avec des manipulateurs humains qui pouvaient utiliser la parole, les gestes, ou une interface utilisateur multisupport ;

* Interagir avec l'environnement et les objets du décor, dont la localisation, ou même la présence, pouvaient évoluer dans le temps ;

* Simuler une autonomie afin de ne pas rester statiques en l'absence d'ordre ;

* Lancer une animation précédemment enregistrée à la volée afin d'ajouter ou d'affiner au fur et à mesure des prises l'ensemble de la prévisualisation de la scène.

Pour interagir avec les manipulateurs humains, nous avons utilisé 3 AKN_RW_Sensor :

* Un AKN_SpeechRecognition_Sensor basé sur SAPI5 qui détecte quel mot parmi une liste prédéfinie a été prononcé par un des utilisateurs ;

* Une version "prototype" du AKN_Body_ActingInput exposé en 3.3.2.2 et qui permettait de récupérer les mouvements du mocapteur immergé à partir d'un système de capture de mouvement optique Optitrack ;

* Un ensemble de AKN_ActingInput destiné au module metteur en scène et qui permettait, soit à l'aide d'une tablette soit à l'aide de commande vocale, de donner des ordres aux figurants virtuels.

### 4.2.2.3 Déplacer l'intelligence

Pour permettre aux figurants virtuels de se représenter leur monde virtuel, nous avons développé le concept d'objet intelligent (ou **smart-object**) inspiré de la série de jeux vidéo Les Sims (Forbus et Wright 2001 ; Wright 2000). Dans ce jeu, un objet dispose, en plus des informations visuelles (forme et couleur de l'objet) et de sa
localisation dans l'environnement virtuel, d'un « manuel d'utilisation », ainsi que de la
liste des besoins que l'objet satisfait.

Par exemple, un **smart-object** de chaise contient sa localisation dans l'espace
et sa forme, mais également le fait qu'elle permet de se reposer (en diminuant la
variable fatigue du **Golem Virtuel**) et l'animation de l'action « s'asseoir » qu'exécutera
le **Golem Virtuel**. Notre figurant virtuel n'a plus à savoir « comment utiliser la chaise »,
il a juste à savoir comme obéir à l'objet intelligent **chaise** qui le manipulera pour le faire
asseoir, transformant ainsi le **Golem Virtuel** "figurant" en **Marionnette Virtuelle**
"figurante", le temps de son interaction avec la chaise.

<figure><img src="image_132.png" /><figcaption>Figure 129 : Les Sims (Wright 2000)</figcaption></figure>

Le « cerveau » de notre figurant virtuel doit donc être en mesure de choisir
l'objet le plus intéressant pour satisfaire ses besoins ; pour cela, nous utilisons un
algorithme simple appelé **Goal Oriented Behavior (GOB)** qui permet de choisir à un
instant t le comportement le plus à même de satisfaire l'entité virtuelle. Cet algorithme
pourrait être avantageusement remplacé par un autre algorithme **Goal Oriented
Action Planing** qui permet de gérer des enchainements d'actions (là où le GOB ne
gère qu'une action) et non plus juste une action à court terme. Ce dernier a d'ailleurs
été implémenté dans notre bibliothèque par une élève ingénieure **Héla Rida** au cours
de son projet de fin d'études sous ma direction(Ridha 2010).
### 4.2.2.4 De la Marionnette Virtuelle au Golem Virtuel

Un **Golem Virtuel** peut temporairement se comporter comme une **Marionnette Virtuelle** ; nous pouvons tout à fait programmer notre **Golem Virtuel** pour qu'il suive nos mouvements (mais la réciproque n'est pas vraie, une **Marionnette Virtuelle** ne peut pas évoluer et atteindre le statut de **Golem Virtuel**). Ceci est au cœur de notre mécanisme de *calques de comportement* (Figure 130) que nous avons mis au point pour le développement d'OutilNum.

Le système fonctionne sur un empilement de calques de comportements classés par ordre de priorité. Plus le comportement est situé haut dans la pile plus ce comportement sera prioritaire par rapport aux comportements en dessous et l'animation qui en découle recouvrira les animations de moins haute importance.

<figure><img src="image_133.png" /><figcaption>Figure 130 : les calques de comportements mis en place dans OutilNum</figcaption></figure>

À chaque calque, on associe un pourcentage d'opacité : par exemple si nous avons le comportement au sommet de la pile avec un degré de 40% et un comportement en dessous à 100%, l'animation qui en découle sera une moyenne pondérée de l'animation générée par le comportement du sommet de la pile pondérée à 40% et l'animation générée par le comportement du dessous pondéré à (100% - 40% =) 60% de la pile.
Les 5 calques de comportements, ordonnés de la plus grande à la plus faible priorité, sont :

* L'animation du **mocapteur**;

* L'animation du **datacteur**;

* Une animation issue des piles de comportements de la prise précédente;

* L'animation issue du mécanisme de **smart-object** décrit en Déplacer l'intelligence;

* Une animation de placement issue d'un cycle de marche préalablement enregistré auquel nous appliquions une combinaison des algorithmes de **pathfinding** et un système de champs de forces que nous avions appelé *influence map* (Figure 131), qui permettait à nos agents de se tenir hors du premier plan de la caméra.

<figure><img src="image_134.png" /><figcaption>Figure 131 : Une influence map, plus la zone est rouge, plus le Golem Virtuel sera repoussé</figcaption></figure>

Ce mécanisme de calque de comportements permet de contrôler l'ensemble des articulations de notre figurant virtuel et sa position dans le monde virtuel. Ceci entraîne un certain nombre de problèmes dont voici les deux principaux exemples :
manque de synchronisation entre les animations issues de différentes couches, phénomène de glissement des pieds du Golem sur le sol dans certains états de transitions.

Cette méthodologie a cependant servi de base pour le développement des AKN_Pupetter que nous avons décrits en 3.3.2.2 Les améliorations que j'aimerais apporter seraient de trois ordres :

* Une meilleure imbrication de ce système avec le mécanisme de puppetteer actuel, pour entraîner un "morcellement" des calques de comportements (comportemental layers) aux différentes parties du corps du Golem ; cette partie est déjà en cours de développement ;

* L'utilisation de la **logique floue** pour signifier la puissance des différents comportements plutôt que des données numériques ;

* Une animation résultante qui ne serait pas le résultat de la moyenne pondérée des différentes animations calculée par les différents calques de comportements, mais bien une moyenne des comportements eux-mêmes ; pour l'instant la réflexion sur sa mise en œuvre n'est pas entamée.

Ce figurant virtuel est opérationnel et a confirmé un potentiel que je continue d'explorer.

### 4.2.3 Lucky, métaphore du Golem

En effet, les recherches sur *OutilNum* ont été pour moi le point de départ de la création des différentes versions de l'installation artistique *Lucky* (Plessiet 2012). Ce travail est directement inspiré du personnage de Lucky de la pièce de théâtre *En attendant Godot* de Samuel Beckett(Beckett 1952).

Dans cette partie nous étudierons plus précisément la mise en œuvre du Golem *Lucky* qui repose sur le détournement artistique de l'architecture des figurants virtuels mis en place pour *OutilNum* (cf. chapitre 4.2.2).
### 4.2.3.1 En attendant Godot

Comme je l'ai expliqué précédemment, le théâtre de l'absurde a toujours eu sur moi une influence particulière, peut-être parce que j'y vois en filigrane une certaine métaphore de l'informatique. Marvin Minsky avait imaginé un défi pour les intelligences artificielles, le défi du canard, dont voici le texte :

Utilisateur : Tous les canards volent. Charlie est un Canard.

Système expert : Alors Charlie vole

Utilisateur : Charlie est mort

Système expert : Alors Charlie ne vole pas

Un tel dialogue pourrait trouver sa place dans une pièce du théâtre de de l'absurde, qui repose sur l'énonciation de non-sens dans une structure parfaitement logique, ou au contraire sur des actions sensées dans un environnement dirigé par l'illogique (ou dont la logique n'est pas énoncée clairement<fnref n="1" />).

Ainsi, je peux voir mon rapport avec l'outil dans cet aller-retour entre la création de règles qui mal énoncées, mènent au non-sens et la compréhension d'un environnement informatique dont la logique n'est pas évidente au premier abord.

Pour dire vrai, il n'est pas rare, quand j'essaye de comprendre pourquoi mon programme ne marche pas, de me retrouver comme le roi Bérenger Ier de la pièce de Ionesco *Le Roi se meurt* (Ionesco 1962) à essayer sans y parvenir de donner des ordres.

Je suis bien-sûr parfaitement conscient que cette interprétation est très personnelle, car le théâtre de l'absurde ne s'est jamais voulu une métaphore de l'outil informatique, puisque ces technologies n'existait pas ou alors de manière embryonnaire et qu'il se veut être une réflexion beaucoup plus profonde comme l'absurdité de l'homme et de la vie.

<footnote n="1">¹ Je pense par exemple à la pendule de la cantatrice chauve(Ionesco 1950) qui sonne selon une logique qui lui est propre.</footnote>
<figure><img src="image_135.png" /><figcaption>Figure 132 : Pozzo tenant en laisse Lucky dans la mise en scène de En attendant Godot de Beckett du festival d'Avignon de 1978</figcaption></figure>

Dans la pièce de théâtre *En attendant Godot de Beckett*, le personnage de Lucky est l'esclave de Pozzo. Tenu en laisse, il obéit docilement à son maître et semble totalement dénué de libre arbitre (Figure 132). Sa docilité oblige Pozzo à devoir décrire chacune des différentes étapes de son action comme le montre l'extrait suivant :

> POZZO (d'un geste large). - Ne parlons plus de ça. (Il tire sur la corde.)
> Debout ! (Un temps.) Chaque fois qu'il tombe, il s'endort. (Il tire sur la
> corde.) Debout, charogne ! (Bruit de Lucky qui se relève et ramasse
> ses affaires. Pozzo tire sur la corde.) Arrière ! (Lucky entre à reculons.)
> Arrêt ! (Lucky s'arrête.) Tourne ! (Lucky se retourne). (...) Plus près !
> (Lucky avance.) Arrêt ! (Lucky s'arrête. À Vladimir et Estragon.). (...)
> (À Lucky.) Manteau ! (Lucky dépose la valise, avance, donne le
> manteau, recule, reprend la valise.) Tiens ça. (Pozzo lui tend le fouet,
> Lucky avance et, n'ayant plus de mains, se penche et prend le fouet
> entre ses dents, puis recule. Pozzo commence à mettre son manteau,
> s'arrête.) Manteau ! (Lucky dépose tout, avance, aide Pozzo à mettre
> son manteau, recule, reprend tout.) Le fond de l'air est frais. (Il finit de
boutonner son manteau, se penche, s'inspecte, se relève.) Fouet !
(Lucky avance, se penche, Pozzo lui arrache le fouet de la bouche,
Lucky recule.) (...) (À Lucky.) Pliant ! (Lucky dépose valise et panier,
avance, ouvre le pliant, le pose par terre, recule, reprend valise et
panier. Pozzo regarde le pliant.) Plus près ! (Lucky dépose valise et
panier, avance, déplace le pliant, recule, reprend valise et panier.
Pozzo s'assied, pose le bout de son fouet contre la poitrine de Lucky
et pousse.) Arrière ! (Lucky recule.) Encore. (Lucky recule encore.)
Arrêt! (Lucky s'arrête. À Vladimir et Estragon.) C'est pourquoi, avec
votre permission, je m'en vais rester un moment auprès de vous, avant
de m'aventurer plus avant. (À Lucky.) Panier ! (Lucky avance, donne
le panier, recule.) Le grand air, ça creuse. (Il ouvre le panier, en retire
un morceau de poulet, un morceau de pain et une bouteille de vin. À
Lucky.) Panier ! (Lucky avance, prend le panier, recule, s'immobilise.)
Plus loin! (Lucky recule.) Là! (Lucky s'arrête.) il pue. (Il boit une rasade
à même le goulot.) À la bonne nôtre. (Il dépose la bouteille et se met
à manger.) (Beckett 1952, pages 29-31)

Lucky agit finalement de manière très semblable à notre **Golem Virtuel**.
D'ailleurs, quand on lui demande de réfléchir par lui-même et donc de faire preuve
d'un certain libre arbitre, il "bug". Remarquons que ces bugs sont assez proches de
ceux de *Max Headroom* (cf Chapitre 1.1.3.1). Et si, dans le premier acte, Lucky est un
"outil efficace" pour Pozzo, dans le second acte Pozzo, devenu aveugle, est totalement
dépendant de Lucky. Là encore, on pourrait voir une métaphore intéressante d'un
autre risque de l'outil informatique à savoir la dépendance de l'homme par rapport à la
machine, même si je suis parfaitement conscient que Beckett n'a pas imaginé le couple
Pozzo/Lucky comme une métaphore des nouvelles technologies.

4.2.3.2 Lucky 2.0

Lucky a eu un profond impact sur ma perception de l'ordinateur et de
l'informatique, car comme je l'ai écrit précédemment, j'ai vu dans le lien unissant Lucky
à son maître Pozzo, une métaphore du rapport de l'utilisateur à l'ordinateur.
L'installation repose sur deux entités virtuelles différentes : Pozzo est l'avatar du spectacteur. C'est une **Marionnette Virtuelle** incarnée. Le personnage de Lucky est un Golem conçu pour obéir. Il est plus complexe, car il doit obéir à un certain nombre d'ordres vocaux, interagir avec le décor et réagir aux tractions de la corde. Ainsi, il se crée un lien étrange entre le spectacteur et le **Golem Virtuel**.

<figure><img src="image_136.png" /><figcaption>Figure 133 : Le dispositif de Lucky 1.0</figcaption></figure>

Comme nous l'avons relaté en 1.3.4.3, le système a bien évolué d'un point de vue matériel, depuis la première version en 2012 jusqu'à sa version de 2015 puisque la première version reposait sur le logiciel **Unity**, un capteur de mouvement **Kinect 1.0** et un casque de réalité virtuelle **Oculus dk1**, alors que la dernière version tournait sur le logiciel **Unreal**, un casque de RV **Oculus dk2** et un capteur de mouvement **Leap Motion**. Mais au-delà de ces évolutions hardware et graphique, le fonctionnement du **Golem Virtuel** Lucky reste à peu près semblable pour les deux versions (Figure 133).
4.2.3.3 Une marionnette et un Golem

Le système repose donc sur une **Marionnette Virtuelle** et un **Golem Virtuel**.
La **Marionnette Virtuelle** permet au **mocapteur** de contrôler le corps de Pozzo.

Pour le Golem Virtuel Lucky, nous utilisons deux AKN_RW_sensors :

* Un AKN_SAPI_Speech_Sensor, qui repose sur la **bibliothèque SAPI5** et qui permet de reconnaître une vingtaine d'ordres (va à droite, à gauche, tourne, prend la valise, va à l'arbre, viens...).

* Un AKN_Falcon_Haptic_Sensor qui permet de récupérer la tension dans la corde et qui applique dans un monde virtuel une force de même ampleur et de même direction au cou de Lucky.

Si dans la première version, Lucky utilisait un automate à état et un algorithme
classique de **pathfinding** (utilisation d'un navmesh), nous avons, dans la seconde
version, intégré les mécanismes de **smart-object** pour les valises que peut saisir
Lucky.

Comme nous pouvons le voir, malgré des mécanismes relativement simples,
*Lucky 2.0* (*Plessiet 2012)*, permet de revisiter la relation maître/esclave Pozzo/Lucky
de la pièce et de peut-être mieux comprendre les liens qui les unissent. Elle fait
expérimenter physiquement et émotionnellement cette relation par le spectateur grâce
à la corde qu'il tient dans ses mains et qui le relie interactivement à l'être virtuel qui
réagit et qu'il voit face à lui en relief comme s'il était présent.

L'œuvre interroge la violence de cette relation maître/esclave qui déshumanise Lucky et paradoxalement aliène Pozzo et par extension renvoie à une critique plus large de l'interdépendance exploiteur/exploité.
## 4.3 Simulation d'intelligence, multiplicité et émergence

Comme nous l'avons décrit dans les chapitres précédents, le **Golem Virtuel** n'a pas de libre arbitre. Il n'a donc pas d'esprit d'initiative et se comportera selon une programmation figée sans avoir la possibilité de gérer les événements non prévus par le programme.

À partir de cette remarque, pouvons-nous travailler sur un « simulacre d'intelligence » ? Existe-t-il des moyens de tricher, afin de faire croire que notre **Golem Virtuel** est sensible, libre et autonome ?

Peut-on faire parler un **Golem Virtuel**, afin d'échanger avec lui ? Et si oui, cela ne remettrait-il pas en question le **test que Turing** avait imaginé pour évaluer l'intelligence d'un programme informatique ?

Que se passerait-t-il si nous multiplions les **Golems Virtuels** ? Qu'arriverait-t-il si nous demandions à des **Golems Virtuels** d'obéir à un des leurs ? S'agirait-il d'une piste pour l'émergence de comportements inédits ?

### 4.3.1 Multiplicité et émergence

Il peut être efficace d'ajouter des verrous scénaristiques afin de créer une cohérence et de parer aux erreurs, mais comme nous avons pu le voir, plus nous introduisons de règles ou de systèmes de contrôle, plus nous pouvons introduire le risque d'une erreur de compréhension.

Il existe un lien évident entre multiplicité et complexité. Un système composé d'éléments simples peut lui-même acquérir des caractéristiques qui ne sont pas présentes dans les unités de base. Ceci est très visible lorsque l'on s'intéresse au système de foule.

La multiplicité d'éléments dans un système entraîne l'apparition d'un comportement autre à l'échelle du système ce que l'on a tendance à résumer par la
fameuse phrase : le tout est supérieur à la somme des parties. Ne serait-ce pas le début de l'émergence ?

### 4.3.1.1 La multiplicité comme verrou scénaristique et le risque d'incompréhension

Comme je l'ai évoqué précédemment, le principe de verrou scénaristique est un système mis en place pour parer au risque d'incompréhension. Par exemple dans *Kelly Conférencière* (Plessiet 2018e), deux verrous scénaristiques ont été mis au point pour "verrouiller" l'attention du **Golem Virtuel** Kelly. Le premier verrou est relativement classique : l'appeler par son prénom pour bloquer son intention et ainsi lui permettre de comprendre quand on s'adresse à elle. Dans ce cas-là, elle saura que la prochaine phrase prononcée sera un ordre. Nous retrouvons ce mécanisme présent dans les assistants électroniques de Google, Microsoft ou Apple.

La deuxième repose sur l'exécution de grands gestes au-dessus de la **Leap Motion** : dans ce cas-là elle demande le silence et abaissera son niveau de sensibilité auditive pour réagir à des sons moins fort.

De tels mécanismes permettent de masquer un certain nombre de bugs que pourrait rencontrer le système. Mais, plus nous ajoutons de verrous scénaristiques, plus nous ajoutons des possibilités de quiproquo, nous risquons donc de transformer notre **Golem Virtuel** en entité incontrôlable.

Cela été par exemple le cas pour la première version de Lucky, où je collaborais avec deux doctorantes étrangères qui avaient un léger accent. Lorsqu'elles parlaient, certains mots étaient mal compris par Lucky, comme l'ordre « **TOURNE** », ou « **ARBRE** ». Nous avions compris que le son [k.] posait un problème et nous avons donc décidé d'ajouter deux ordres « **TOUNE** » et « **ABE** » à notre **Golem Virtuel**. Ceci a eu un effet pernicieux, car Lucky ne réagissait plus du tout correctement et reconnaissait des ordres là où il n'y en avait pas.

Il est donc nécessaire de réfléchir le verrou comme un dispositif global et non pas comme un moyen de résoudre un problème particulier, car plus nous introduisons de règles : plus nous créons le risque de faire émerger de nouveaux comportements.
## 4.3.1.2 Multiplions les Golems, gérer la foule

S'il y a risque d'émergence quand on ajoute de nouveaux ordres au **Golem Virtuel**, il y a aussi émergence quand on multiplie le nombre de Golems, à l'instar du jeu de la vie, dans lequel nous constatons l'apparition de comportements plus complexes (Figure 134).

L'algorithme du jeu de la vie est simple (Delahaye 2009). Le plateau de jeu se présente sous la forme d'un damier, dont chaque case contient une cellule. Une cellule peut-être soit vivante soit morte. Chaque cellule du jeu de la vie ne fait que suivre les trois règles très simples suivantes :

* Si une cellule a exactement trois voisines vivantes, elle est vivante à l'étape suivante;

* Si une cellule a exactement deux voisines vivantes, elle reste dans son état actuel à l'étape suivante;

* Si une cellule a strictement moins de deux ou strictement plus de trois voisines vivantes, elle est morte à l'étape suivante.

L'algorithme est donc simple et ne laisse pas suspecter l'étonnante complexité du système ainsi obtenu. Comme le décrit Heudin (Heudin 1994, page 48) le jeu de la vie est un système chaotique entraînant ainsi un certain nombre de caractéristiques comme l'impossibilité de savoir à un instant $t$, l'état du tableau de jeu à $t-1$. Mais au-delà de ce constat, on voit l'apparition de motifs complexes comme les planeurs, ces structures se déplaçant le long du plateau de jeu, ou les feux clignotants (Figure 134).

Nous voyons bien qu'en multipliant les entités simples, il y a eu émergence de nouveaux comportements non prévus par les règles de base. En allant plus loin, Heudin écrit en parlant du jeu de la vie :

> Pour ce faire, il suffit de montrer que ses (le jeu de la vie) capacités sont nécessaires et suffisantes pour réaliser une machine universelle de Turing. Du fait du principe même de la démonstration de Turing, on peut alors en conclure que toute
« machine arbitraire » peut potentiellement apparaître dans le « jeu de la vie », ou du moins y être représentée.

Il n'existe pas d'algorithme général pour décider si un ensemble de règles d'un réseau d'automates cellulaires supporte ou non la réalisation d'une machine de Turing. La seule méthode simple revient à « construire » une telle machine sur la base des éléments dont on dispose. Notons au passage qu'un échec ne constituerait pas une démonstration de sa non-universalité, il laisserait simplement cette question sans réponse(Heudin 1994, page 49).

<figure><img src="image_137.png" /><figcaption>Figure 134 : Quelques exemples simples de comportements émergeants</figcaption></figure>

Nous pouvons même assister à la création de systèmes autopoïétiques, c'est-à-dire qui ont la capacité de se reproduire eux-mêmes : l'exemple le plus connu est l'Automate de Langton en 1984 (Figure 135). Cet automate cellulaire se compose de
cellules ne disposant que de 8 états, mais qui se comportent comme une colonie de coraux (Heudin 1994, pages 52-53).

<figure><img src="image_138.png" /><figcaption>Figure 135 : Boucle de Langton</figcaption></figure>

Si l'exemple précédent montre que de nouveaux comportements peuvent émerger à partir d'automates cellulaires, il en est de même avec des structures s'appliquant à des entités plus complexes.

Ainsi le système de boids (Reynolds 1987) et son évolution, les steerings behavior, issus des travaux de Craig Reynolds (Reynolds 1999) et qui sont encore très couramment utilisés dans les effets spéciaux<fnref n="1" />, reposent sur des entités simples qui suivent un nombre très limité de règles de base.

Dans le cas des boids, les règles sont au nombre de trois :

* La cohésion : une entité doit se diriger au centre des entités qu'elle voit ;

* L'alignement : une entité doit avoir la même vitesse et la même direction que les entités qu'elle voit ;

* La séparation : une entité doit s'éloigner des entités qu'elle voit.

Il ne reste plus qu'à faire une moyenne pondérée de ces trois comportements pour obtenir la direction et la vitesse de l'entité. Derrière cette simplicité, nous pouvons sans problème simuler des phénomènes complexes comme, par exemple, les

<footnote n="1">¹ Ils font d'ailleurs partie de l'enseignement que je donne au sein du département Arts et Technologies de l'Image (ATI).</footnote>
mouvements des bancs de poissons ou des foules. C'était d'ailleurs sur ce principe que j'avais développé mon **plug-in** (Plessiet 2007c) de simulation de bancs de poissons (Figure 136)<fnref n="1" /> pour le film de l'attraction *On a marché sous l'eau* (XLargo 2008).

<figure><img src="image_139.png" /><figcaption>Figure 136 : On a marché sous l'eau</figcaption></figure>

### 4.3.1.3 Émergence ou perte de contrôle ?

Donc plus nous multiplions les **Golems virtuels**, ou les mécanismes à l'intérieur du **Golem Virtuel**, plus cette multiplicité entraîne un risque de perte de contrôle ou d'émergence. Le système fait ce qu'on lui a ordonné de faire, mais les ordres et contre-ordres (est-ce réellement des contre-ordres ?) sont trop nombreux pour que l'on puisse prédire le comportement du **Golem Virtuel** le transformant ainsi en système chaotique.

Il devient donc primordial de les organiser et de les hiérarchiser. Marvin Minsky propose un modèle fondé sur des modules simples qui formeraient ce qu'il appelle une société de l'esprit (Minsky 1988, 1991). Il se pose la question de ce qui caractérise

<footnote n="1">¹ Avec quelques ajouts notables comme la simulation du stress et l'utilisation de la logique floue.</footnote>
l'esprit humain et de la manière dont il fonctionne. Ainsi, il imagine que nous pouvons
le modéliser, non pas par un simple agent complexe, mais « *une multitude d'agents
extrêmement spécialisés interagissant les uns avec les autres qui travaillent en
département* » (Agency)<fnref n="1" />.

Quand nous regardons le fonctionnement des modules d'AKeNe décrits
précédemment, nous voyons l'influence que la proposition de Marvin Minsky a eue sur
ma façon d'envisager le développement de la bibliothèque AKeNe : les dispositifs mis
en place reposent sur de nombreux agents spécialisés, path finding, chatbot, acting
input, automate à état et arbre de comportement pour les principaux. Chacun de
ces modules est d'ailleurs considéré comme devant fonctionner de manière autonome.
C'est d'ailleurs en ce sens que j'ai conçu le système de test unitaire de la bibliothèque
AKeNe. Un test unitaire est une procédure permettant de vérifier le bon
fonctionnement d'une partie précise d'un logiciel ou d'une portion d'un programme.
C'est cependant l'architecture logicielle globale qui me semble primordiale, fortement
basée sur l'utilisation de patron de conception (Gamma et al. 1994) afin de garantir
une évolutivité de la bibliothèque.

Mais le **Golem Virtuel** –quelle que soit la complexité du système mis en place
pour le contrôler– est le fruit du travail de son créateur et ne pourra évoluer que dans
le champ d'action délimité par ce dernier. Tout au plus le créateur n'a pas envisagé
toutes les évolutions possibles du système dans son cadre d'autonomie. Si nous
voulons franchir une étape pour dépasser le **Golem Virtuel**, nous devons réfléchir à
ce que le système de contrôle puisse échapper au champ d'action développé par son
créateur en s'auto-modifiant, dépassant ainsi ce que nous appelons la première
cybernétique, la cybernétique de Norbert Wiener vers une seconde cybernétique celle
définie par Von Foester qui peut s'autoadapter.

4.3.2 Interaction et Scénarisation

Dans mes *Portraits de Double-Autre*, j'utilise le **Golem Virtuel** comme une manière de « peindre autrement » mon sujet, son comportement programmé

<footnote n="1">¹ Traduction personnelle du terme Agency, peut-être qu'il se contente de décrire des agencements, mais cette organisation va plus loin que ce simple terme.</footnote>
devenant, au même titre que la qualité de sa Sculpture Matrice, un élément esthétique sensible.

Ceci nous amène à penser autrement l'interaction spectacteur/Golem Virtuel.
Comment créer, une interaction suffisamment intéressante pour que l'absence de libre
arbitre de notre « sujet peint » ne vienne pas remettre en cause la Bulle de Plausibilité
en train de se créer ?

Finalement, il nous faut travailler sur un simulacre d'intelligence pour que le
**Golem Virtuel** ne vienne pas trahir sa nature programmée, que ce soit pour une œuvre
artistique, ou même pour un jeu vidéo.

4.3.2.1 Le Golem Virtuel comme portrait sensible

Lorsque je me suis mis à travailler sur ma série de *portrait de double autre*,
l'idée qui m'animait était de créer des portraits virtuels de mes amis et de mes proches
tout en leur attribuant des capacités de sensation, de perception et d'interaction, afin
de créer un lien personnel entre le « sujet peint » et le spectacteur.

Paradoxalement, malgré mon aspiration pour le réalisme photographique, j'ai
réalisé ces œuvres en m'inspirant de l'histoire et de la pratique du portrait peint, étant
plus sensible aux portraits de Johannes Vermeer ou de Georges de La Tour, qu'à ceux
d'Arnold Newman ou des photographes du Studio Harcourt.

En outre, je ne cherche pas à créer un « être vivant » enfermé dans un tableau,
à la manière des tableaux magiques de *Harry Potter*<fnref n="1" /> ou d'autres films fantastiques,
mais plutôt créer une « peinture » qui, par son mouvement, puisse refléter le regard
que je porte sur mon sujet.

L'œuvre se fait à la fois dans le visuel immédiatement offert au spectacteur, mais également dans la relation que je propose de nouer avec le sujet peint. En projetant par la programmation des interactions évoquant quelques traits caractéristiques de mon « modèle », je souhaite créer pour le spectateur, une peinture mouvante et sensible de ma relation à cette personne. La création du **Golem Virtuel** n'a donc pas pour vocation à simuler une personne, mais à créer un « double autre »

<footnote n="1">¹ C'est malgré tout, l'une des remarques que j'ai le plus entendu au cours de mes différentes expositions.</footnote>
en révélant par l'interaction mon interprétation du modèle. La programmation des comportements devient alors un acte artistique au même titre qu'un autre.

Les portraits *Bug dans les rotations* (Plessiet 2018d), *Rêverie* (Plessiet 2018g), *Mains Vertes* et *Les Miens* (Plessiet 2018c) sont plus proches de la **Marionnette Virtuelle**, car les mouvements des entités sont directement connectés au mouvement du manipulateur/spectacteur (conscient ou inconscient de la situation). À l'inverse, des portraits comme *Ange* (Plessiet 2018a), *L'institE*, *La Louve* (Plessiet 2018f) s'inscrivent dans une logique différente, car ce sont des **Golems Virtuels** dont j'ai conçu le cerveau, les comportements, les senseurs et les actuateurs, que je propose à l'interaction du spectacteur.

Je conçois donc la construction de ces **Golems Virtuels** sur deux plans : un plan algorithmique et un plan scénaristique. Par algorithmique, je parle bien sûr de la partie programmatique, à savoir quelle technique je vais utiliser, ou comment je vais gérer les déplacements du Golem. Par scénaristique, j'entends l'aspect narratif des interactions proposées par le Golem à son interacteur, inconscient de se trouver devant une créature programmée. Ainsi le spectateur « ressent » dans l'action ce que mon intention d'artiste lui propose, durant son interaction avec le **Golem Virtuel**. Durant ce temps d'interaction, l'entité virtuelle interagissant avec un humain crée une bulle de plausibilité qui ne doit pas être brisée.

### 4.3.2.2 Les verrous scénaristiques : meta-Golem et effet Perceval

En cela je trouve pertinent de revenir sur l'effet ELIZA, c'est-à-dire la tendance que nous avons d'assimiler le comportement d'un programme informatique à celui d'un être humain. Pour comprendre l'effet ELIZA, nous devons revenir au **chatbot** ELIZA, créé en 1966 par Joseph Weizenbaum (Weizenbaum 1966).

Ce **chatbot** simule un psychanalyste en utilisant un certain nombre de règles pour transformer les réponses de l'utilisateur en question. Voici un exemple de conversation avec ELIZA (Güven et Franchi 1995) :

> Jeune femme : Vous n'êtes pas très agressif, mais je pense que vous ne voulez pas que je le remarque.

> ELIZA : Qu'est-ce qui vous fait penser que je ne suis pas très agressif?
Jeune femme : Tu ne discutes pas avec moi.

ELIZA: Pourquoi pensez-vous que je ne discute pas avec vous?

Jeune femme : Tu as peur de moi.

ELIZA: Est-ce que ça vous fait plaisir de croire que j'ai peur de vous?

Jeune femme : Mon père a peur de tout le monde.

ELIZA: Qu'est-ce qui vous vient à l'esprit quand vous pensez à votre père?<fnref n="1" />

Si nous associons généralement l'effet ELIZA à du dialogue textuel, je pense que nous devons généraliser ce concept en considérant toute action du **Golem Virtuel** comme contribuant à l'effet ELIZA. Le programme ELIZA m'avait particulièrement intéressé par l'utilisation que fait Joseph Weizenbaum de questions ouvertes lorsque le programme ne sait pas quoi répondre. Ceci m'a fait penser qu'il fallait créer des structures scénaristiques qui permettraient d'éviter tout comportement qui briserait la bulle de plausibilité. Par extension, j'ai appelé *verrou scénaristique* toute structure visant à conserver intacte la bulle de plausibilité. Par exemple, *La Louve* (Plessiet 2018f) utilise un *verrou scénaristique* que j'ai baptisé *Meta-Golem*.

Le portrait *La Louve* présente une mère et ses deux enfants interagissant entre eux et avec le spectacteur(Figure 137). Le processus décisionnel se situe à deux niveaux : le premier niveau est présent dans chacun des trois *Sub-Golems Virtuels* (la mère et ses deux enfants) et le deuxième niveau plus global gère la synergie des trois personnages. Ce deuxième niveau agit comme un **Golem Virtuel** unique, *La Louve*, avec trois corps. C'est pour cela que je décris cette architecture comme un Meta Golem Virtuel (Figure 138).

<footnote n="1">¹ « Young woman: You are not very aggressive but I think you don't want me to notice that.
ELIZA: What makes you think I am not very aggressive?
Young woman: You don't argue with me.
ELIZA: Why do you think I don't argue with you?
Young woman: You are afraid of me.
ELIZA: Does it please you to believe I am afraid of you?
Young woman: My father is afraid of everybody.
ELIZA: What else comes to mind when you think of your father? »</footnote>
Ainsi les deux **Golems Virtuels** enfants réagissent aux stimulus extérieurs, à savoir les mouvements extérieurs captés par un **Tobii** (par un AKN_Tobii_Sensor) et en fonction de leur état interne, réagissent à la présence des spectateurs. La mère interagit avec ses deux enfants, oscillant entre une attitude de réconfort et de protection. Ainsi, les trois **Golems virtuels** ne font en réalité que suivre chacun un algorithme très simple, mais le *Meta-Golem*, par la combinaison de ces comportements individuels donne l'impression d'un comportement complexe.

<figure><img src="image_140.png" /><figcaption>Figure 137 : La Louve</figcaption></figure>
<figure><img src="image_141.png" /><figcaption>Figure 138 : Architecture de la louve</figcaption></figure>

Lorsque les *Sub-Golems Virtuels* ne savent plus quoi faire, ils se mettent à interagir entre eux en attendant de retrouver un état comportemental cohérent. Par exemple, la mère et les enfants échangent entre eux des regards et des animations, coupant toute interaction avec le monde réel jusqu'à ce que le *Meta-Golem Virtuel* retrouve les éléments nécessaires pour relancer un de ses comportements spécifiques.

Nous trouvons fréquemment cette stratégie dans le jeu vidéo, en particulier pour simuler le comportement d'une escouade (Gorniak et Davis 2007) où le comportement des Golems virtuels est défini à la fois sur l'individu et à l'échelle du groupe.

J'ai baptisé un autre de ces verrous scénaristiques *Effet Perceval* en référence au personnage Perceval de la série *Kaamelott*. Ce dernier est connu pour répondre « *Ce n'est pas faux* » à toute phrase qu'il n'a pas comprise et je l'ai utilisé énormément dans *Cou2Garnack* (Plessiet 2016) et *Kelly Conférencière* (Plessiet 2018e). Cette technique consiste à utiliser des phrases extrêmement informelles qui, bien que n'apportant rien à la conversation, ne montrent pas que le **Golem Virtuel** n'a pas compris le sens de la phrase (par exemple « *faut voir* », « *ça dépend* », « *intéressant* »). Ainsi mon double autre, dans *Cou2Garnack* (Plessiet 2016), ne fait qu'utiliser des phrases **Effet Perceval** pendant toute notre interaction. Pourtant, lors
de l'analyse post-mortem<fnref n="1" /> a posteriori du projet, les spectateurs m'ont dit qu'ils croyaient que je discutais réellement avec mon double autre.

### 4.3.2.3 De Captain Blood à Façade

À ce stade, il me semble très important d'étudier comment le jeu vidéo utilise le scénario pour tenter de créer un lien empathique entre le joueur et les **Golems Virtuels** présents dans le jeu. Un jeu vidéo ne cherche pas à créer des personnages non joueurs "intelligents", mais plutôt à faire croire au joueur que ceux-ci sont intelligents. C'est donc par le scénario et dans une moindre mesure par le **game design**, que l'on fera croire que ce **Golem Virtuel** fait preuve de sentiment et de réflexion. Je ne peux m'empêcher d'ailleurs de relater une anecdote : un vendeur du magasin de jeu vidéo me vantait l'intelligence des personnages du jeu vidéo *Metal Gear* « car quand ils ne font rien, ils fument », alors que ce n'est pas une preuve d'intelligence, mais juste une animation qui se lance en l'absence d'interaction.

Si cette anecdote est plutôt humoristique, d'autres exemples montrent comment un **game design** inventif et une bonne scénarisation peuvent camoufler les faiblesses du **Golem Virtuel**. Je vois dans le système conversationnel du jeu *L'Arche du Captain Blood* (Ulrich 1988) un bel exemple de **game design** efficace. Le système, baptisé UPCOM, repose sur une écriture logographique composée de 120 icônes que l'on utilise pour communiquer avec les extraterrestres que l'on croise dans le jeu (Figure 139). Nous trouvons l'explication aux incohérences des réponses des personnages que nous rencontrons dans nos propres difficultés à nous exprimer via le UPCOM. Nous sommes nous mal exprimés ? Est-ce que c'est lui qui s'exprime mal ? N'est-il pas logique que notre interlocuteur virtuel éprouve des difficultés à se faire comprendre, car je rencontre les mêmes difficultés à m'exprimer ?

<footnote n="1">¹ Un post-mortem est une analyse que l'on effectue à la fin d'un projet et où nous étudions ce qui a fonctionné, ce qui a moins bien fonctionné, ce que nous pouvons capitaliser, et ce que nous pouvons améliorer.</footnote>
<figure><img src="image_142.png" /><figcaption>Figure 139: le système de communication UPCOM</figcaption></figure>

Le jeu Façade (Mateas et Stern 2003) créé par les chercheurs Mathieu Mateas et Andrew Stern, pousse encore plus loin l'interaction avec les personnages virtuels (Figure 140). Ce drame interactif est conçu à la fois autour d'une problématique artistique (raconter un drame) et autour d'une problématique scientifique (interagir en langage naturel) (Mateas et Stern 2005). Il nous permet en effet de communiquer en langage naturel avec un couple de personnages virtuels, Grace et Trip, gérés par l'ordinateur. Les deux chercheurs les désignent comme des intelligences narratives (Mateas et Sengers 1999) et montrent que l'écriture de cette intelligence se doit d'être transdisciplinaire aussi bien littéraire, qu'informatique et implique de ne plus considérer la création d'un personnage virtuel comme une simple mise en place technique.

<figure><img src="image_143.png" /><figcaption>Figure 140 : le jeu Facade</figcaption></figure>
J'irai plus loin en émettant l'hypothèse que la force du lien entre le **Golem Virtuel** et l'utilisateur dépend de la construction d'une histoire du personnage virtuel, d'une identité, d'un présent, s'élaborant par l'interaction avec son environnement, avec les utilisateurs, en accord avec les buts qu'on lui a fixés.

### 4.3.3 Robot conversationnel et écriture de dialogue

Nous pouvons donc leurrer le spectacteur et lui faire croire que notre **Golem Virtuel** dispose d'une forme d'intelligence, ceci reposant davantage sur un travail d'écriture que sur la création d'une forme véritable d'intelligence. Si l'utilisateur sent une forme d'intelligence là où le **Golem Virtuel** ne fait que suivre un programme rigide, c'est peut-être parce qu'il dépasse la position de donneur d'ordre et rentre dans une forme de communication naturelle plus complexe.

À partir de cette hypothèse, nous devons nous intéresser à nos méthodes de communication avec le **Golem Virtuel** en cherchant à nous rapprocher de nos méthodes de communication « humaines » comme le langage naturel, ainsi que nous l'avons vu dans le jeu * facade*. Il s'agit donc de réfléchir autrement à cette interaction Golem/utilisateur. Si, en tant que programmeur du **Golem Virtuel**, nous savons qu'il ne fait qu'exécuter un algorithme et que le spectacteur ne le sait pas, comment pouvons-nous générer une forme d'empathie dans un processus communicationnel complexe ?

#### 4.3.3.1 Communiquer et non ordonner...

Si *L'Arche du Captain Blood* et * facade* sont des jeux aussi marquants dans leur interaction avec l'utilisateur, c'est qu'ils réussissent à faire oublier que nous discutons avec des agents informatiques. En effet dans ces deux cas, l'interaction entre utilisateur et **Golem Virtuel** a été réfléchie en termes de communication en accordant un même niveau d'importance aux deux « individus » et non plus en termes de manipulation maître/esclave. C'est-à-dire que l'interaction n'est plus pensée en tant qu'ordre efficient, mais comme une proposition d'interaction qui considère le risque de non-compréhension entre les deux parties comme partie intégrante de l'exercice communicationnel.
C'est donc une interaction au-delà du schéma "presse-bouton" qui est proposée : nous remplaçons « appuyer sur tel bouton afin que le **Golem Virtuel** exécute cet ordre associé à ce dernier » par « transmettre de la description de l'ordre que nous voulons voir exécuter par le **Golem Virtuel** », description qui sera analysée par l'entité virtuelle qui trouvera l'ordre correspondant le mieux aux informations données. Soit, dans le premier cas, nous pouvons appuyer sur le bouton qui incrémente la variable "joie" présente dans le **Golem Virtuel**, soit dans le deuxième cas, nous pouvons lui dire "ne soit pas triste", qui correspondra certainement au même ordre (à savoir incrémenter la variable "joie"), mais qui aura pour effet de "camoufler la nature informatique du **Golem Virtuel**".

Une telle approche entraîne le risque que le **Golem Virtuel** ne perçoive ou ne comprenne pas l'ordre. C'est pourquoi il peut être utile d'habiller un message technique du système (« j'ai compris le message », « je n'ai pas compris le message ») par une phrase plus « littéraire ». Durant ma présentation du **Golem Virtuel** basé sur la **Sculpture Matrice** de Kelly Messino à l'International Festival of Theater Research de Belgrade en 2018 (Plessiet 2018e) – une conférence-performance dans la lignée de Cou2Garnak (Plessiet 2016) – j'ai mis en place un tel système, de manière à ne pas avoir un **Golem Virtuel** incontrôlable en pleine conférence. Je dois d'ailleurs reconnaître que ma crainte était plus focalisée sur la possibilité de cette perte de contrôle, plutôt que sur des remarques ou questions difficiles des auditeurs vis-à-vis de mes travaux de recherche.

Ce **Golem Virtuel**, Kelly Conférencière (Figure 141) réagit à la voix captée par microphone et un AKN_SpeechRecognition_Sensor et au geste de la main et des doigts par un capteur de mouvement **Leap-Motion** et un AKN_LeapMotion_Sensor. Pour amorcer le processus de contrôle, je devais l'appeler à haute voix par son prénom et si elle avait compris que je m'adressais à elle, elle me répondait – en anglais, difficulté supplémentaire à gérer – soit par "oui", "oui, monsieur", "oui, Cédric". En l'absence de réponse, je pouvais comprendre qu'il y avait un problème et alors mettre en action mon verrou de sécurité, c'est-à-dire secouer ma main pour "attirer son attention". Sa réponse était alors "excuse-moi, je n'écoutais pas", "désolée je suis un petit peu distraite"...
<figure><img src="image_144.png" /><figcaption>Figure 141 : Kelly conférencière</figcaption></figure>

De plus quand elle comprenait un ordre, elle me le répétait, sinon elle utilisait
l'effet Perceval, pour masquer son incompréhension. Nous obtenions alors des
dialogues intéressants dont voici un extrait :

--- Moi : Kelly ?

--- Kelly : Oui Cédric ?

--- Moi : Tu peux te présenter ?

--- Kelly : Je me présente : je m'appelle Kelly, je suis un
double autre d'une actrice qui s'appelle Kelly Mezino et je suis
ici pour rendre la présentation de Cédric plus amusante

--- Moi : Kelly ?

--- Kelly : Oui ?

--- Moi : Je veux prendre contrôle de ta tête

--- Kelly : excuse-moi, mais tu as un très mauvais
accent anglais

--- Moi (en articulant et en parlant plus fort) : JE
CONTROLE TA TETE

--- Kelly : Ok, tu contrôles ma tête.

(Et à partir de ce moment, je contrôlais les rotations de
sa tête et ses expressions faciales avec ma main)

Ainsi l'effet Perceval m'a permis de récupérer le contrôle sur une erreur et de
cacher l'incompréhension de l'ordre donné « je contrôle ta tête ». De ma pratique, j'en
ai conclu qu'il valait mieux qu'il y ait une action, même fausse, que pas d'action du tout.

### 4.3.3.2 Chat-Bot et AIML

Dans cette approche communicationnelle, l'utilisation du langage naturel a donc toute sa place. Il existe beaucoup d'algorithmes de **chatbot**, certains, reposant sur d'immenses bases de données de réponses possibles comme *Alice* ou *Elbot*, d'autres, plus récents, utilisent des modèles basés sur des réseaux de neurones(Li et al. 2016). Au-delà de mon intérêt initial pour le **chatbot ELIZA**, j'ai rapidement éprouvé un intérêt tout aussi vif pour le **chatbot Alice** dont les capacités sont beaucoup plus puissantes(AbuShawar et Atwell 2002, 2015).développé par Richard Wallace autour d'un langage balisé l'**AIML** (Wallace 2003).

Je me suis intéressé à *Alice*, pour plusieurs raisons. Tout d'abord l'**AIML** est fondé sur le langage **XML**, il est bien défini et il existe de nombreux projets open source de parser<fnref n="1" /> **AIML**. De plus Jean Louis Campion a créé une base **AIML** en français et il existe des bases de données dans beaucoup d'autres langues(Alicebot 2011) qui peuvent servir de base pour créer notre propre **chatbot** en langue française. Au-delà de ces deux avantages, il existe un certain nombre de logiciels qui permettent de réaliser et tester facilement des fichiers **AIML**. J'utilise pour ma part GaitoBot (Springwald Software s. d.) disponible gratuitement sur Internet.

Mon *Autoportrait à l'écran* (Plessiet 2018b) repose sur une mise en œuvre simple d'un **chatbot AIML**. Je n'ai d'ailleurs que très peu modifié la base conversationnelle française. Car ce qui m'intéresse le plus dans cette œuvre se trouve dans ce face à face absurde **Golem Virtuel** Moi Virtuel/Moi réel par écran interposé (Figure 142). J'aime beaucoup l'idée que mon double autre, utilisant une base de données générique, affiche des goûts très différents des miens, à l'image des personnalités que les gens se construisent sur Internet, cachés derrière l'anonymat de leur écran.

<footnote n="1">¹ Un parser analyse syntaxiquement un texte source à partir 'un langage formel, défini par un ensemble de règles de syntaxe formant une grammaire formelle.</footnote>
<figure><img src="image_145.png" /><figcaption>Figure 142 : Autoportrait à l'écran</figcaption></figure>

4.3.3.3 Humour accidentel et Logoré

On comprend assez rapidement que ce type de **chatbot** ne fait pas preuve d'une réelle forme d'intelligence. Nous avons juste un système dont l'algorithme est conçu pour le faire passer pour un humain. C'est d'ailleurs là les limites du **test de Turing** (Turing 1950). En effet, Turing, avait imaginé le test suivant : un humain mène une conversation en aveugle avec un ordinateur et un autre humain. S'il n'est pas en mesure de faire la différence entre l'ordinateur et l'humain, alors on considère que l'ordinateur est intelligent. Mais Turing n'avait d'ailleurs jamais réellement envisagé ce test comme une évaluation de l'intelligence de la machine et dans son article il relève déjà certaines objections(Lassègue 1995).

Dans mon approche, le fait que la machine ne soit pas réellement « intelligente » n'est pas un problème, puisque je ne cherche pas à créer une entité intelligente, mais une entité capable d'évoluer dans sa propre bulle de plausibilité. Je
juge plus intéressant d'avoir un système de **chatbot** facilement programmable, me permettant ainsi un travail plus artistique.

La multiplicité de règles entraîne le risque d'être mal compris, mais ceci peut être l'occasion de quiproquos intéressants comme le montre l'extrait de la conversation suivante avec mon « double-autre » :

Utilisateur : Est-tu intelligent ?
ORDINATEUR : En tout cas, moi, je connais mes conjugaisons.

Cette réponse pourrait être perçue comme une preuve d'humour, mais ce trait spirituel n'est pas une réponse issue de son intelligence, mais la réponse générique à la faute de grammaire EST-TU.

Pour m'amuser, j'avais créé dans les années 2000 un **chatbot** baptisé *Emeth* en référence à la phrase gravée sur le front d'un Golem comme nous l'avions détaillé au chapitre 5.1.1.1. *Emeth* se décomposait en deux versions qui partageaient la même base conversationnelle : la première était une application faite sous le logiciel *Virtools* (Figure 143) et une deuxième sous la forme d'un **plug-in** pour le logiciel de messagerie *Trillian*.

<figure><img src="image_146.png" /><figcaption>Figure 143 : le chatbot *Emeth*</figcaption></figure>
J'avais décidé de créer un "**chatbot** apprenant" assez sommaire. Ainsi, *Emeth* utilisait un **algorithme** qui ajoutait à sa base de données, la phrase entrée par l'utilisateur comme réponse possible. Par exemple si *Emeth* me dit « **bonjour** » et que je lui répondais « **bonjour toi** », il ajoutait « **bonjour toi** » comme réponse possible à « **bonjour** » et ainsi de suite.

Mais il ajoutait aussi n'importe quelle réponse donnée par l'utilisateur, ainsi si on répondait « *j'aime la choucroute* » à « *bonjour* » il considérait cette phrase pourtant incongrue comme une réponse tout à fait valable à « *bonjour* ». Très rapidement *Emeth* devint incontrôlable, répondant n'importe quoi à n'importe qui. Ceci n'est pas sans rappeler ce qui est arrivé au **chatbot Tay** de *Microsoft* qui se mit à tweeter des horreurs racistes(Lee 2016).
5 Acteur Virtuel
Comme nous l'avons vu précédemment, le **Golem Virtuel** est à l'initiative de son mouvement, mais pas de son processus décisionnel. Il évolue dans un cadre précis en fonction de sa programmation et des ordres qui lui sont donnés. La création d'une telle entité oblige son créateur à réfléchir à la programmation du golem comme une « scénarisation » de son action. Le golem n'agit pas par lui-même, il exécute : donc, si nous voulons qu'il montre un semblant de personnalité, c'est par un travail d'écriture scénaristique que nous pouvons l'en doter.

Nous avons vu qu'il était néanmoins possible de créer un phénomène d'émergence, en multipliant les structures et les entités. Mais s'il y a bien création de nouveaux comportements, elle est liée à une réinterprétation ou une recombinaison de règles existantes plutôt qu'à la création d'une véritable décision. Pourrions-nous détourner ce phénomène d'émergence pour créer un **Acteur Virtuel** qui serait l'initiateur de sa décision ?

Une telle autonomie permettrait de changer le rapport entre l'artiste et la Sculpture Matrice, qui passe de « manipulateur/manipulé » à « maître/esclave » pour aboutir à un dialogue plus égalitaire « collaborateur/collaborateur ». Un tel type de relation n'entraîne-t-elle pas le risque d'obtenir finalement un agent difficilement « utilisable », car trop autonome ? Et si oui, peut-on trouver des structures pour canaliser un « trop-plein de liberté » ?

Nous ne serions alors plus ici dans la création d'un serviteur docile, somme toute pas très différent d'un l'outil, mais dans celle d'un partenaire autonome, d'un autre être, d'une statue qui prend vie comme dans le mythe de Pygmalion et Galatée, ou d'un pantin de bois, Pinocchio, sculpté par Gepetto qui devient petit garçon comme dans le roman de Collodi.

## 5.1 Être à l'initiative de sa propre décision

Comme nous l'avons décrit dans le chapitre précédent, le **Golem Virtuel** ne dispose pas d'initiative. Il se contente d'exécuter les ordres qu'on lui donne. Mais nous avons aussi en parallèle évoqué les capacités d'émergence dont disposent les systèmes complexes et chaotiques. À l'opposé d'un système autonome, il n'a plus besoin d'un ordre extérieur pour agir par lui-même.
Mais avant de réfléchir à l'autonomie, nous devons nous interroger sur les méthodes qui nous permettraient d'émanciper notre créature, de lui permettre de faire ses propres choix et d'apprendre ainsi de ses expériences. Mais comment peut-on doter notre créature de mécanisme d'apprentissage ? Et cet apprentissage lui permettra-t-il de devenir son propre maître ? Un **Golem Virtuel** qui apprend est-il un **Golem Virtuel** qui exécute l'ordre d'apprendre ?

Et si l'apprentissage peut être la source de l'émancipation de notre golem, sa prise d'initiative décisionnelle ne peut se faire si le **Golem Virtuel** apprenant s'émancipe de son tuteur, en apprenant aussi par lui-même, en faisant ces propres expérimentations.

En introduisant cette couche d'apprentissage autonome, nous redéfinissons les interactions qui unissent la créature à son environnement, dépassant ainsi « l'interactivité presse-bouton » comme l'avaient appelée Michel Bret, Edmond Couchot et Marie-Hélène Tramus vers une seconde interactivité (Tramus, Bret et Couchot 2003). Mais n'y a-t-il pas un risque que cette seconde interactivité ne déplace notre entité vers des territoires la rendant inexploitable, l'entité se libérant trop du rôle que l'on a défini pour elle ?

### 5.1.1 Obéissance contre éducation

Le **Golem Virtuel** obéit à des ordres, en déroulant les algorithmes qui leur correspondent et ceci docilement, sans les remettre en cause. Il paraîtrait donc tout à fait pertinent d'ajouter un ordre d'apprentissage, dont l'algorithme consisterait à lui faire ajouter un nouvel algorithme.

Un véritable apprentissage nécessite une certaine forme de compréhension et d'assimilation, voire de remise en cause par l'expérimentation : de manière à transformer une prescription en expérience. Il faut donc que la prescription soit mise à l'épreuve de l'expérimentation, afin qu'elle soit digérée et puisse nourrir de futures réflexions, car sinon, nous n'aurons que des ajouts de règles qui ne conduiront pas à une émergence réelle, mais plutôt à un camouflage de manque d'autonomie.
### 5.1.1.1 Un Golem Virtuel apprenant est-il toujours un Golem Virtuel qui exécute l'ordre d'apprendre ?

À la manière d'Emeth (cf. Chapitre 4.3.1.3), il est relativement simple d'implémenter un ordre qui permet l'ajout d'un nouvel **algorithme** au cerveau de notre **Golem Virtuel**. Par exemple, nous pourrions ajouter une fonction dont l'exécution associe un nouvel algorithme à un nouvel ordre. Ceci n'est en soi qu'un cas basique d'utilisation d'une Machine de Turing universelle (Turing et Girard 1999) dont l'ordinateur n'est, au final, qu'une mise en application<fnref n="1" />. Ce concept est composé de quatre éléments :

* Un ruban infini divisé en cases consécutives, dont chacune contient un symbole ;

* Une tête de lecture/écriture qui peut se déplacer sur le ruban, soit à gauche soit à droite et qui est capable d'écrire un symbole ;

* Un registre d'état qui mémorise l'état de la machine. Le nombre d'états est toujours fini et il existe un état initial qui sera le point de départ ;

* Une tête d'action qui indique l'action qui est exécutée par la machine en fonction du symbole lu par la tête de lecture et l'état courant.

La Machine de Turing universelle a ceci de particulier qu'elle est capable de simuler n'importe quelle machine de Turing existante et possède ainsi la possibilité d'exécuter n'importe quel **algorithme**.

Il est tout à fait envisageable de créer un **Golem Virtuel** de ce type, enrichissant ses compétences au fur et à mesure qu'on lui donne de nouveaux algorithmes qu'il peut exécuter. Mais cette catégorie de **Golem Virtuel** n'est pas en mesure de créer ses propres solutions : il est seulement capable d'enregistrer de nouvelles méthodes de résolution pour un problème donné. Si nous ne lui donnons pas exactement l'ensemble de la procédure pour traiter ce cas, il ne sera pas en mesure d'improviser sa propre solution.

<footnote n="1">¹ Si l'on omet le fait qu'en théorie Turing imagine sa machine avec un ruban infini, alors que les ordinateurs ont une mémoire bornée.</footnote>