# Chapitre III.6

## Exploitation de données ouvertes

### Introduction

Une des activités de la société Les Fées spéciales est de concevoir et fabriquer des programmes animés pédagogiques pour des musées et des films. Ces programmes sont généralement conçus pour des clients ayant une exigence élevée de véracité scientifique, ou du moins de fidélité. Même si les programmes sont conçus pour rendre des phénomènes complexes accessibles au grand public, et sont donc forcément des approximations ou des simplifications, il faut que les explications soient fondées sur des modèles scientifiques à jour.

Dans une situation idéale, les données et modèles sont fournis par le client. En réalité, les documents fournis sont souvent de trop faible qualité pour être utilisé dans la production d'animation. Il faut donc soit inventer les données manquantes (la fameuse vue d'artiste), soit s'appuyer sur d'autres sources, parmi lesquelles les données ouvertes (cf. section I.2.4) peuvent être salvatrices.

Ce chapitre explorera plusieurs questions de visualisation scientifique rencontrées lors de la production des projets *Antarctica* (cf. section III.1.2), dans lesquels les programmes audiovisuels avaient pour but la visualisation, particulièrement cartographique. Il analysera donc le rôle des données ouvertes dans la fabrication de ces programmes.
III.6.1 Les trajets des équipes

Conçue pour l'exposition du musée des
Confluences (cf. section III.1.2), cette ani-
mation figure un planisphère à la surface
duquel sont tracés les chemins parcourus
par les deux équipes (hommes, et matériel)
ayant participé à l'expédition, entre Paris
et Dumont d'Urville, la base scientifique
française en Terre Adélie (figure III.6.1).
Les équipes font plusieurs escales sur leurs
trajets, et les courbes décrivant les tra-
jets doivent donc passer par ces points
en Grande-Bretagne, aux Émirats arabes
unis, en Australie et en Antarctique. Le
planisphère doit être reconnaissable par le
public, et proche des représentations car-
tographiques conventionnelles. La défor-
mation doit être limitée et le nord en haut

de la carte. La fabrication de ce plan* m'a conduit à explorer à la fois différentes pro-
jections de cartes, et la manière de les obtenir avec des programmes open source, en
collaboration avec la direction artistique.

Des bases de données cartographiques sont disponibles sous licences ouvertes<fnref n="1" /> (cf. section I.2.4). Pour ce plan, la direction artistique demandait seulement de disposer des contours des continents, aussi j'ai utilisé un simple fond de carte disponible sur Wikimedia Commons [66]. Cette carte a été rendue disponible dans le domaine public par son auteur<fnref n="2" />, et on peut donc la réutiliser dans n'importe quel but. Il est indispensable,

<figure><img src="image_18.png" /><figcaption>FIGURE III.6.1 – Le plan illustrant le trajet qu’ont suivi l’équipe de tournage. En cyan, le trajet des personnes ; en blanc, celui du matériel.</figcaption></figure>

<footnote n="1">1. Il n'existe pas de répertoire global de ces bases de données, et il faut donc, lors de ses recherches, vérifier systématiquement sous quels termes les données sont publiées.</footnote>

<footnote n="2">2. Il s'agit d'une version modifiée d'une carte de la CIA, qui publie tout comme la NASA une partie de ses données dans le domaine public. Il est à noter que l'auteur est vraisemblablement états-unien.</footnote>
quand on utilise des images ou données trouvées sur Internet, de vérifier sous quelles conditions elles sont publiées. Sur les sites de la fondation Wikimedia, cette information est disponible pour tous les médias, et certaines licences ne sont pas adaptées à une utilisation commerciale.

La carte originale utilise une projection equirectangulaire³. Pour essayer différentes projections cartographiques, j'ai écrit des scripts utilisant la bibliothèque* Python pyproj [56]. Elle permet la conversion de coordonnées d'une projection à l'autre (par exemple, passer d'une projection latitude-longitude à celle de Mollweide). Cette bibliothèque permet des manipulations complexes de données cartographiques.

<figure><img src="image_19.png" /><figcaption>FIGURE III.6.2 – Différents essais de projections cartographiques utilisant la direction artistique</figcaption></figure>

Pour déterminer la projection qui réponde le mieux à nos critères, j'ai collaboré avec le directeur artistique Eric Serre. Nous avons étudié plusieurs projections (figure III.6.2). Eric avait dessiné sur un fond de carte ses intentions artistiques, et ce design a été à chaque fois reprojeté pour obtenir des cartes aux formes diverses, mais avec la même direction artistique. Nous avons fait des essais d'animation de caméra pour mettre en scène le plan, et avons finalement opté pour la projection transverse de Mercator. C'est

S'il avait été français, il n'aurait pas eu le droit de publier une œuvre dans le domaine public, le droit d'auteur français protégeant obligatoirement les œuvres. Il aurait pu en revanche y associer une licence libre très permissive telle que Creative Commons CC0 1.0 universel (CC0 1.0) [63].

3. Aussi appelée latitude-longitude, c'est une projection très simple, pratiquement la plus basique, puisqu'elle fait simplement correspondre un degré de longitude ou de latitude à une unité de distance sur la carte.
une projection cylindrique, c'est-à-dire que la sphère est projetée sur la surface d'un cylindre qui l'entoure. Dans cette projection, contrairement à la projection de Mercator, très répandue, l'axe du cylindre se situe sur l'équateur et non dans l'axe du globe. En choisissant la rotation du globe le long de son axe, on peut faire tourner les continents autour des pôles pour les placer de manière reconnaissable.

Le plan, une fois terminé, devait recommencer en boucle pour les visiteurs de l'ex-position. Le plan étant fixe, la première solution envisagée était simplement de faire disparaître à nouveau les courbes des trajets. Mais un des avantages de cette projection est que le haut et le bas se raccordent, puisque le cylindre se déplie dans une direction nord-sud. Nous avons donc pu faire boucler la séquence* dans un travelling vertical entre l'Europe et l'Antarctique. Cette solution n'était pas anticipée, mais semble rétrospectivement élégante et évidente, et permet de tirer pleinement parti des possibilités offertes par une représentation cartographique non conventionnelle.

D'un point de vue cartographique, il est très déstabilisant d'utiliser une projection inhabituelle parce qu'on ne sait plus comment appeler les directions sur la carte. Par exemple, si la carte est centrée sur le pôle Sud, on a envie d'appeler le bas, le sud ; la gauche, l'ouest, etc. Mais c'est faux, tous les points sont au sud. On se rend compte que la seule manière est d'utiliser des angles (70°S, 90°E), même de manière approximative. On est ainsi obligé de comprendre les latitudes et longitudes.

## III.6.2 Le cœur

Ce plan* était une animation expliquant le mouvement de la banquise au cours de l'année : son expansion et sa fonte. Le nom du plan « le cœur » est une métaphore visuelle, puisque la banquise s'étend et se rétracte au cours de l'année. C'est également une métaphore sémantique, car il explique que la banquise fait partie des mécanismes essentiels de régulation du climat sur Terre.

La création de l'animation a consisté à utiliser des données précises de visualisation scientifique pour parvenir à un résultat qui est non seulement plaisant visuellement, mais
<figure><img src="image_20.png" /><figcaption>FIGURE III.6.3 – Les données fournies par le client, insuffisantes pour obtenir une séquence juste et détaillée.</figcaption></figure>

beaucoup plus réaliste que si nous avions dû créer l’animation à partir de rien.

En effet, les données qui nous avaient été initialement fournies par le client (figure III.6.3) étaient des vignettes à basse résolution (environ 100 pixels) et non sourcees. Il y avait une vignette par mois de l’année, et l’animation que nous devions réaliser était censée être fluide, vivante et détaillée. Nous aurions pu détourner ces petites vignettes pour obtenir une forme grossière, et l’affiner en inventant des détails, mais cette démarche aurait conduit à des résultats fantaisistes et peu intéressants.

Il était plus logique de chercher une source de données plus détaillée, que nous pourrions réutiliser afin de créer notre version. Il a donc fallu se renseigner sur le sujet pour connaître assez de vocabulaire pour faire des recherches pertinentes. Une vidéo appropriée a été publiée en 2012 par la NASA (figure III.6.4), sous une licence permettant une réutilisation. Plutôt qu’un jeu de données directement extrait de mesures satellites,
<figure><img src="image_21.png" /><figcaption>FIGURE III.6.4 – Images extraites de la vidéo de la NASA illustrant l'évolution de la banquise au cours de l'année 2010 [41].</figcaption></figure>

il s'agit ici d'une visualisation scientifique, c'est-à-dire déjà une vidéo de synthèse présentant les données de manière compréhensible pour le public. Il a donc fallu, plutôt que de traiter des données sources, procéder en sens inverse en partant de la vidéo pour en extraire les données, et recréer dans un second temps une autre vidéo dérivée.

Pour cela, il a été possible d'utiliser une technique de compositing assez classique, à savoir un keying pour séparer la mer et la glace et obtenir un masque noir et blanc. Cette opération a été réalisée dans Natron (cf. section III.3.3), dont les outils de keying étaient très adaptés à ce type de plan.

La majeure partie du travail a ensuite été d'adapter la direction artistique à la séquence de la NASA (figure III.6.5), en retrouvant les couleurs et les effets de matière du fond, de la banquise et du continent, et les textes et repères géographiques. Pour cela
<figure><img src="image_22.png" /><figcaption>FIGURE III.6.5 – Antarctica : processus graphique pour la séquence de la banquise aussi, Natron a été utilisé pour reconstruire le plan dans ses détails graphiques et son animation réaliste.</figcaption></figure>

Comme pour la carte décrite à la section précédente, il est évident qu'avant de songer
à réutiliser une vidéo existante, il est nécessaire de bien lire les conditions sous lesquels elle est publiée, en particulier si le détournement est autorisé à des fins commerciales ou pédagogiques, et le cas échéant, s'il faut citer des groupes ou individus précis au générique de l'œuvre dérivée.

### III.6.3 L'écoulement de la banquise

Ce plan* illustre la manière dont les banquises du continent s'écoulent lors de leur fonte annuelle. Le continent est plus ou moins recouvert de glace toute l'année, mais une partie fond l'été, et de l'eau s'écoule depuis les glaciers jusqu'à l'océan. L'animation devait donc visualiser de manière réaliste cet écoulement ressemblant à un système hydrographique avec des rivières et des fleuves sur toute la surface du continent.

L'équipe du film nous a fourni quelques documents, mais ils ne donnaient que très peu d'indications, et le client recommandait encore une fois « d'inventer » un mouvement sans référence précise, le but étant d'illustrer un principe général plutôt que des données exactes. Il fallait donc montrer les mouvements des glaciers sur toute la surface du continent, sans connaître particulièrement ni la topologie, ni l'hydrographie, ni aucune discipline qui aurait pu nous permettre de créer une animation, sinon véridique, du moins réaliste. C'est pourquoi, ici encore, j'ai commencé par me documenter, d'abord sur les phénomènes en jeu, puis rapidement sur les jeux de données disponibles et permettant d'utiliser un modèle scientifique afin d'être au plus près des connaissances actuelles sur le sujet.

La NASA, au sein du National Snow and Ice Data Center, a publié les données d'une expérience mesurant précisément les mouvements des glaces antarctiques. [40] En vertu de la politique de données des agences gouvernementales états-uniennes, l'utilisation de ces données est libre, à la seule condition de citer les auteurs de l'étude [34]. Nous avons donc pu traiter ces données scientifiques à des fins d'illustration, et obtenir des images non seulement justes, mais également intéressantes esthétiquement du fait de l'interprétation que nous en avons faite.
<figure><img src="image_23.png" /><figcaption>FIGURE III.6.6 – Antarctica : processus graphique pour la séquence de l'écoulement</figcaption></figure>

J'ai commencé ce plan en trouvant et téléchargeant les données et en les préparant. Ces données sont des vecteurs de déplacement pour chaque point échantillonné sur le continent. J'ai pour cela examiné le format de données qui m'était inconnu, NetCDF, et écrit un script* pour les extraire vers un format plus facile à utiliser. Cette extraction
n'était pas très complexe, car le format NetCDF est simple à lire. Destiné à stocker
des tableaux de données, il est auto-documenté, c'est-à-dire que l'en-tête contient les
informations nécessaires : les différents tableaux contenus dans le fichier <fnref n="4" />, les dimensions
des tableaux, la projection cartographique utilisée, ainsi que des descriptions et des
références. J'ai créé à partir de ce fichier une image TIFF non compressée contenant les
mêmes données, mais plus facile à charger dans un script pour manipulation future et
plus facile à visualiser qu'un long tableau texte (figure III.6.6a).

Une fois ces données extraites, mon collègue Duy Kévin Nguyen a traité le plan en
s'occupant de la conception graphique et de la traduction en images. Duy, pour générer
les images présentes dans l'exposition, a utilisé l'environnement de développement libre
Processing, connu pour sa facilité de prototypage itératif. La méthode employée a été
de créer un système de particules émises sur toute la surface du continent, et déplacées
(advectées) par les vecteurs présents dans la carte. Puisque ces vecteurs représentent
la quantité de déplacement en une année pour chaque point, il lui a fallu amplifier les
valeurs afin d'obtenir un mouvement perceptible. Il a procédé en générant de nombreuses
séquences d'images (figure III.6.6b) à partir de ces particules, qui devaient ensuite servir
de masques colorisés et composités pour obtenir le plan final (figure III.6.6c), par-dessus
d'autres passes générées à partir de cartes d'élévation.

Cette manière de travailler a demandé de constants aller-retours entre une approche
d'ingénieur, afin de comprendre, interpréter, analyser les données et leur signification,
et une démarche de graphiste pour créer des images lisibles, belles et intéressantes. Du
fait de l'utilisation de données ouvertes, elle demande une plus grande rigueur qu'une
création arbitraire sans référence, mais offre aussi un résultat impossible à obtenir sans
ces données.

<footnote n="4">4. Ici, il s'agissait des composantes horizontale et verticale des vecteurs de déplacement, exprimées en mètre par an, et d'une estimation de l'erreur pour chaque point. La précision est de 450 mètres, c'est-à-dire qu'un point du tableau représente un carré de 450 mètres de côté. Le tableau représentant le continent entier est un carré de 12445 points de côté, ce qui fait une quantité de données assez importante.</footnote>
### III.6.4 Cartes de l'Antarctique

Au cours des films, plusieurs sites sont montrés sur le continent. Or le public n'est pas familier avec l'Antarctique, et il a donc fallu créer des cartes afin de situer l'action, par exemple sur la base scientifique Dumont D'Urville et la péninsule antarctique. Ces cartes devaient avoir un rendu tirant vers le réalisme, et nous les avons fabriquées en utilisant les données d'élévation de la NASA (cf. section I.2.4.1). Des problèmes sont apparus, qui ont pu être réglé en partie grâce à la nature open source de Blender et à son modèle de distribution.

En effet, nous avons utilisé un système dans Blender permettant de créer un relief en fonction d'une map au moment du rendu, grâce à un déplacement (*displacement*) et à une subdivision adaptative. Cela signifie que la géométrie est plus ou moins subdivisée selon la distance à la caméra. À l'époque, ce système de « micro-déplacement » était en bêta, et donc indisponible dans la version stable de Blender. La fonctionnalité était en phase active de développement et des améliorations sont arrivées en cours de fabrication dans les dernières builds*.

La solution du micro-déplacement donne des images de haute qualité, mais le problème avec ce projet était le format d'image 4K UHD, c'est-à-dire de 3840×2160 pixels. Pour que l'image soit de bonne qualité, il fallait que le maillage soit très subdivisé pour que la taille des facettes soit inférieure ou égale à celle des pixels, sans quoi des artefacts seraient apparus. Il fallait donc calculer un grand nombre de pixels, et chaque pixel était long à calculer en raison de la précision du maillage, à tel point que pour certains plans* particulièrement longs, il est devenu manifeste que nous n'arriverions pas à calculer les images sur nos ordinateurs, même en distribuant les calculs sur toutes les machines, certaines étant même incapables de calculer ne serait-ce qu'une image.

Afin de pallier ce problème, nous avons fait appel à un service de rendu en ligne, Qarnot Computing. Le fonctionnement de ce genre de services est le suivant : le client envoie une scène à rendre à travers une interface dédiée, le calcul est effectué sur les serveurs du prestataire, et le client est notifié quand les images sont prêtes à être téléchargées. Il est intéressant de faire appel à un prestataire quand une entreprise a besoin
de scalabilité*, ou ne souhaite pas investir dans une ferme de rendu, dans le principe du
*cloud computing*. Ceci dit, les sociétés qui fournissent ces services limitent généralement
le nombre de logiciels et de versions disponibles au client, afin de faciliter la maintenance.

Or, nous avions besoin de calculer nos images avec le micro-déplacement, qui était in-
disponible dans la version officielle de Blender proposée par Qarnot. Nous avons contacté
l'équipe de Qarnot afin de leur demander d'installer les builds récentes, non-officielles,
de Blender, dont nous avions besoin. Ils ont consenti à le faire, en les intégrant dans leur
système interne de gestion de calculs. Cette expérience était intéressante parce que non
seulement nous pouvions utiliser des versions expérimentales du programme 5, mais nous
avons pu demander à un prestataire d'en installer un grand nombre sur ses nœuds de
calcul. Certes, leur service client était très réactif, mais c'est en partie la disponibilité de
Blender qui leur a permis de nous aider à rendre le projet à temps. Les raisons juridiques
de cette possibilité sont expliquées en section II.1.1.1.

<footnote n="5">5. Cette pratique n'est pas nécessairement des plus sages, car un programme bêta peut être instable, corrompre les données, dysfonctionner de diverses manières. Mais le logiciel libre la rend au moins techniquement et légalement possible.</footnote>
# Chapitre III.7

## Acquisition et usinage 3D

### Introduction

Bien que l'animation 3D utilise principalement des outils numériques, des liens se tissent depuis une dizaine d'années entre les processus de conception numérique et le monde physique, suite à la facilité d'accès aux techniques de numérisation 3D et de prototypage rapide<fnref n="1" />. Ces liens existent dans les deux sens : en passant des objets physiques à leur modèle numérique, et en fabriquant des objets physiques à partir de modèles informatiques.

Les studios ne se limitent plus, comme naguère, à utiliser la numérisation pour la capture de références photographiques pour les textures, mais s'étend à la numérisation complète d'objets volumiques complexes. L'utilisation du LIDAR et de la photogrammétrie pour numériser un décor de cinéma comme référence pour l'ajout d'effets spéciaux est devenue importante pour les grosses productions de cette industrie. Pour le film d'animation et le jeu vidéo, ces techniques sont elles aussi de plus en plus abordables et répandues, pour la création d'assets* notamment.

Dans l'autre sens, celui du numérique vers le physique, la CAO* trouve plusieurs

<footnote n="1">1. En particulier avec le mouvement *makers* et la création de nombreux fab labs. Des équipements comme les imprimantes 3D et les scanners 3D deviennent accessibles aux petites entreprises et même au grand public, et leur qualité s'est aussi considérablement amélioré au cours de la décennie 2010. L'open source a aussi joué un rôle important, notamment du côté du matériel.</footnote>
usages pour l'animation. Par exemple, elle est souvent utilisée pour les productions de
films en stop motion. Pour animer un visage, plutôt que de modeler chaque expres-
sion faciale, certains animateurs préfèrent préparer le visage sur ordinateur, construire
les différentes positions, et ensuite les imprimer en 3D. Ces hybridations entre créa-
tion numérique et monde physique peuvent créer de nouvelles formes d'expression, ou
simplement simplifier la création des formes existantes<fnref n="2" />.

La nature des projets sur lesquels j'ai travaillé au cours de cette thèse ne m'a pas permis d'explorer ces deux domaines (fabrication d'assets et animation stop-motion). J'ai en revanche participé à un projet composé de différents médias à vocations artistique et pédagogique, dont un des axes principaux était la numérisation et l'usinage de pièces volumiques : le musée de Lodève (cf. section III.1.3). Cette riche expérience a permis d'explorer ces domaines avec plusieurs cas d'étude complémentaires.

Afin de préciser les problématiques de numérisation et d'usinage 3D, j'analyserai donc
le travail qui a été entrepris pour les différentes expositions du musée. Je détaillerai les
problèmes soulevés par la réalisation de ces pièces, et les difficultés rencontrées en 2018
par le studio pour les résoudre avec des solutions libres.

Pour cela, j'exposerai d'abord certaines contraintes typiques de la création muséo-
graphique en volume, à la fois dans la place des œuvres au sein de la muséographie, et
dans leur processus de fabrication. J'examinerai ensuite deux techniques ayant permis de
modifier numériquement les objets fabriqués pour le musée, afin d'obtenir des résultats
cohérents avec les souhaits de mise en scène. Je finirai par évoquer certaines des solutions
libres existant en 2019 pour la photogrammétrie, c'est-à-dire la capture photographique
des volumes.

<footnote n="2">2. Par exemple, le studio d'animation états-unien Laika est reconnu depuis Coraline (2009) pour ses films utilisant les techniques de prototypage rapide pour l'animation de ses personnages. Le studio a reçu en 2016 une récompense aux Oscars scientifiques (*Scientific and Engineering Awards*) pour ses innovations dans ce domaine.</footnote>
### III.7.1 Contraintes techniques pour la muséographie

Les contraintes d'élaboration d'un modèle 3D destiné à sa fabrication physique sont différentes de celles des assets* de films d'animation, particulièrement en matière de topologie (cf. section I.1.2.2). En effet, tandis que la topologie d'un personnage animé doit permettre de déformer précisément et de manière prévisible le volume, ici la pièce fabriquée sera entièrement statique. Il n'est donc pas besoin, par exemple, de subdiviser une surface plane, puisqu'une seule facette suffit à la décrire. En revanche, d'autres contraintes existent. Pour que le programme chargé de transformer le modèle 3D en instructions pour la machine qui fabrique la pièce (que ce soit une imprimante 3D ou une fraiseuse à commande numérique), il faut que le modèle soit « étanche », c'est-à-dire qu'aucune erreur de topologie ne soit présente dans le modèle. Il ne peut y avoir deux sommets au même point, ou deux arêtes ou deux faces se chevauchant, ou encore deux sommets reliés par deux arêtes différentes. Il ne peut pas non plus y avoir de trou dans la surface. Si toutes ces situations peuvent poser problème aussi pour le film, en particulier pour le rendu et les effets spéciaux, on peut souvent s'en accommoder, voir ne jamais les détecter. Ce n'est pas vrai de la CAO, où il faut s'assurer de les éliminer.

D'autres contraintes existent, d'ordre géométrique. Il faut modéliser selon les cotes prévues, et avec la précision demandée. Si pour un film, on allonge une partie d'un accessoire de quelques millimètres, rien de grave ne se produit. Si en revanche, on modélise une maquette quelques millimètres trop large, elle risque de ne pas entrer dans la vitrine où elle doit être installée.

Je vais à présent décrire différents types de travaux réalisés.

#### III.7.1.1 Réalisation de maquette schématique

La première pièce volumique réalisée pour le musée est la maquette du causse du Larzac, une formation géologique proche de Lodève. Elle présente une vue en coupe d'un plateau, avec en contrebas une rivière reliée à une grotte souterraine. Dans cette grotte, des habitants du néolithique entreposaient des poteries pour y recueillir de l'eau, d'où
<figure><img src="image_24.png" /><figcaption>FIGURE III.7.1 – Schéma de la maquette dessiné par l’archéologue Noisette Bec.</figcaption></figure>

son nom, la grotte citerne. Dessinée d'après un schéma (figure III.7.1) de l'archéologue chargée de l'exposition, Noisette Bec, la maquette a été sculptée en 3D dans Blender (figure III.7.2). Ce logiciel est parfaitement adapté pour une telle tâche, dans la mesure où il permet de modéliser des maillages avec un grand nombre de polygones, et où il offre des outils de sculpture performants, ainsi que des outils permettant de repérer les problèmes de topologie empêchant l'usinage.

<figure><img src="image_25.png" /><figcaption>FIGURE III.7.2 – Rendu en élévation du modèle 3D de la maquette.</figcaption></figure>

Le schéma était dessiné à la ligne, montrant la coupe de la grotte. La maquette est certes en volume, mais elle a été usinée avec une fraiseuse à commande numérique, et il était compliqué de creuser sur une grande profondeur avec cet équipement, et surtout d'avoir un volume en saillie, se détachant de la surface. Par exemple, on pourrait imaginer
que les cavités soient représentées creusées, et que les stalactites tombant du plafond se détachent de la paroi, mais l'entreprise chargée de la fabrication nous a précisé que ce serait trop complexe pour ce projet. La grotte a donc été modélisée en bas-relief, et les volumes sculptés strictement à partir du schéma, laissant peu de place à l'improvisation. À chaque étape de conception, la maquette était validée par l'archéologue, et elle l'a été également plusieurs fois par l'entreprise chargée de l'usinage, afin de s'assurer que ce dernier serait possible.

<figure><img src="image_26.png" /><figcaption>FIGURE III.7.3 – Maquette installée dans l'exposition.</figcaption></figure>

### III.7.1.2 Réalisation d'œuvres hybrides physiques-virtuelles

L'intérêt que peut avoir un studio d'animation à concevoir des pièces volumiques pour l'exposition d'un musée est qu'il peut mettre en œuvre ses compétences d'animation, et augmenter l'œuvre par ce médium. Cela peut se faire en projetant une animation sur l'objet, à l'aide d'écrans juxtaposés, ou même en créant une installation interactive. Ces
deux volets de l'œuvre peuvent être élaborés à partir des mêmes données volumiques, et
créer donc un tout harmonieux.

Les Fées spéciales sont intervenues sur deux installations de ce type pour le musée de Lodève, la première utilisant des écrans, et la deuxième des projections directement à la surface de l'œuvre.

Animation : dalle des empreintes

<figure><img src="image_27.png" /><figcaption>FIGURE III.7.4 – Dalle fabriquée et installée dans l'exposition.</figcaption></figure>

La première installation mettant en œuvre une pièce physique enrichie par de l'ani-
mation se situe dans le parcours géologique du musée. Une salle entière est consacrée
à une dalle posée au sol, à la surface de laquelle on peut voir des traces de pas d'ani-
maux préhistoriques (figure III.7.4). L'attrait de cette installation est la présentation
simultanée de médias diffusés dans la salle et montrant également la dalle.

De chaque côté de la salle, des écrans jouent une animation des deux animaux préhis-
<figure><img src="image_28.png" /></figure>

FIGURE III.7.5 – Image extraite du film de la dalle des empreintes. Les traces sur le sol sont les mêmes que celles visibles sur la dalle, et le point de vue de l'écran sur la dalle correspond à l'animation.

toriques qui ont laissé leurs empreintes<fnref n="3" />. Les points de vue des écrans correspondent à leur placement par rapport à la dalle (figure III.7.5). Dans cette installation multimédia, les empreintes au sol devaient donc correspondre à une séquence fictionnelle imaginée par les scientifiques, mais fidèle aux connaissances actuelles sur la locomotion de ces créatures. La recréation numérique de la dalle prenait ainsi tout son sens : les films et l'objet physique étaient conçus en même temps à partir des mêmes données 3D. Le processus de fabrication de la dalle sera étudié dans la section III.7.2.1.

## Utilisation de données ouvertes : cartes projetées

La deuxième installation consiste en des cartes animées de la région que les Fées spéciales ont conçues afin d'illustrer des phénomènes géologiques et archéologiques. Elles prennent la forme de cartes en relief placées sur des tables dans l'exposition. Sur ces

<footnote n="3">3. Ces animaux étaient un dimétrodon, reptile préhistorique à la démarche plutôt lourde, et un éryops, qui nageait à la surface de l'eau à une époque où le sol était immergé, et dont les pattes griffues pouvaient l'atteindre.</footnote>
<figure><img src="image_29.png" /><figcaption>FIGURE III.7.6 – Carte projetée d'archéologie dans l'exposition.</figcaption></figure>

supports sont vidéoprojetés des programmes animés depuis un projecteur caché dans le sous-plafond. Le public peut ainsi se pencher pour observer les animations et lire les explications comme sur un écran, mais en relief. La société a été chargée de concevoir les cartes, c'est-à-dire les modéliser et produire les animations projetées. Tout comme pour la dalle, le même modèle 3D a été utilisé pour fabriquer l'objet physique et pour créer les animations projetées dessus. Ainsi, l'œuvre exposée forme un tout cohérent.

Comme les programmes cartographiques du musée des Confluences (cf. section III.6.4), la modélisation utilise des données ouvertes, publiées par l'agence spatiale états-unienne NASA (cf. section I.2.4.1) et par le projet OpenStreetMap. Contrairement à cette première exposition où on voyait le continent antarctique dans son ensemble, il fallait ici des données de beaucoup plus haute précision, car la zone géographique montrée sur les cartes est centrée sur le Lodévois, et mesure quelques dizaines de kilomètres de côté.

Ici encore, les données d'élévation ont été utilisées directement dans Blender pour
déformer la surface d'un plan et obtenir le volume de la table, en réglant seulement l'épaisseur de la table et l'intensité du déplacement, qui est exagérée pour que le relief soit bien perceptible. Cette présentation d'animations en relief demande une assez bonne justesse dans le volume, mais offre une grande liberté artistique, puisqu'on touche au *projection mapping*<fnref n="4" />, et qu'indépendamment de la carte relief, assez belle en soi, tout l'intérêt de la pièce est la vidéo qui est projetée à sa surface, et les phénomènes qui y sont illustrés.

L'image projetée sur la carte a aussi été en partie générée à partir de données ouvertes. Ainsi, le fond de carte constitué des villes, des cours d'eau et de la mer, a été extrait de la base de données ouverte OpenStreetMap (cf. section I.2.4.2), tandis que des courbes de niveaux ont également été générées à l'aide de la carte d'élévation de la NASA.

L'intérêt majeur d'utiliser ces données a été de respecter une correspondance stricte entre la surface imprimée et les images générées. De plus, il a été possible d'automatiser la création d'une partie des cartes est, plutôt que de les dessiner manuellement. Pour donner une idée de l'intérêt que cette automatisation représente, on peut la comparer avec la méthode choisie par la directrice artistique qui a conçu l'identité visuelle des cartes, Marie Saby. Dans les dessins de concept qu'elle a créés, elle est partie d'un fond de carte, dont elle a décalqué les courbes de niveau, et colorisé chaque pallier, ce qui représente un travail de titan. En utilisant les données ouvertes, j'ai pu obtenir un résultat de qualité équivalente en quelques minutes, une fois que les données d'altimétrie étaient en place.

### III.7.2 Transformations numériques d'objets réels

Comme dans beaucoup de musées, la majorité des collections n'est pas exposée mais dans les réserves, étudiées par les scientifiques et rarement ou jamais montrée au public. Il peut y avoir plusieurs raisons à cela : fragilité des pièces, impossibilité de concevoir

<footnote n="4">4. Le *projection mapping* est une technique consistant à utiliser des objets physiques comme support de projection pour des animations. Plutôt qu'un simple écran plat, il utilise les reliefs de la surface, les met en valeur ou en retrait par l'image portée. L'œuvre qui en résulte dépend donc autant de son support physique que de l'image projetée.</footnote>
des vitrines adaptées, ou simplement un nombre trop grand de pièces pour pouvoir tout exposer en même temps.

Ces différents problèmes peuvent être réglés par la reproduction des pièces en réserve. Les techniques de numérisation et d'usinage 3D sont parfaitement adaptées à cette application. De plus, elles permettent de modifier numériquement les pièces avant usinage, pour pouvoir recomposer les pièces manquantes, combler les trous, voire même modifier complètement la forme de la pièce tout en conservant son esprit. Plusieurs pièces que nous avons fabriquées étaient soit des adaptations de pièces physiques dans la collection du musée, soit des reproductions.

J'exposerai dans cette section les processus d'acquisition et de traitement de deux objets conservés dans les collections du musée de Lodève.

### III.7.2.1 Recomposition en 2D d'un relief 3D

<figure><img src="image_30.png" /><figcaption>FIGURE III.7.7 – Moulages de la dalle prêtés par le musée pour la numérisation, dans l'atelier des Fées spéciales</figcaption></figure>

La dalle des empreintes (cf. section III.7.1.2) du musée de Lodève est une pièce de grande dimension installée au sol dans une des salles du musée. On peut y voir des empreintes de pas fossiles d'animaux préhistoriques. Ces traces de pas ont été retrouvées
<figure><img src="image_31.png" /><figcaption>FIGURE III.7.8 – Scans des moulages sous la forme de cartes de hauteur.</figcaption></figure>

lors de fouilles sur un site industriel, et des moulages ont été faits sur place et conservés
dans les collections du musée (figure III.7.7). Le site ayant depuis été recouvert, les
moulages sont les seuls éléments accessibles à l'équipe du musée. Mais ces moulages sont
fragiles et incomplets : seules certaines portions de la dalle ont été levées. Or, le musée
souhaitait reconstituer une dalle de 40 m^2 pour l'exposition. Les Fées spéciales ont donc
été chargées de concevoir la dalle complète à partir des fragments disponibles. Pour cela,
nous avons numérisé les fragments existants et recomposé l'objet les réordonnant et en
comblant les parties manquantes.

Afin d'obtenir une numérisation précise des morceaux de la dalle, nous avons essayé
plusieurs techniques. La plus simple à mettre en œuvre est celle de la photogrammétrie,
puisque le seul équipement à posséder est un appareil photo, un ordinateur puissant,
et un programme spécialisé. Nous souhaitions utiliser pour cela des logiciels libres, et
avons donc essayé plusieurs programmes en amont de la production. Les résultats étaient
acceptables, mais le processus complexe à l'époque, du fait que tous les programmes exis-
tants devaient nécessairement s'exécuter en ligne de commande, sans disposer d'interface
graphique. Ces programmes sont abordés dans la section III.7.3.

Au final, les contraintes de production nous ont fait revoir notre méthode. Étant
débutants en photogrammétrie, et n'ayant pas eu assez de préparation pour être certains
d'avoir un bon résultat dans un temps très court, nous avons utilisé un scanner 3D à
main. Celui-ci a très bien fonctionné, mais le programme fourni par le constructeur est
propriétaire. Il existe bien des logiciels open source, et des scanners dont le matériel
même est open source, mais ils n'étaient pas adaptés à la numérisation d'objets aussi
grands. Même si nous avions trouvé un tel matériel, le temps de préparation manquait
pour l'acquérir ou le fabriquer, et pour apprendre à s'en servir correctement.

Une fois les morceaux de dalle scannés, j'ai abordé leur recomposition en vue d'ob-
tenir un objet fidèle aux demandes narratives des films projetés, à la muséographie et à
la fidélité scientifique. Pour cela, il aurait été possible de procéder en 3D, avec des tech-
niques de sculpture, mais il était beaucoup plus efficace de créer une carte d'élévation
à partir de chacune des plaques (figure III.7.8), de les recomposer dans un logiciel de
peinture, et finalement de les réappliquer sur le maillage 3D à l'aide d'un displacement.
En effet, l'objet fabriqué est en relief, mais il n'y a pas de volumes superposés : tout le
relief peut être décrit en plan.

Pour obtenir ces cartes d'élévation, j'ai fait un rendu des scans avec un matériau
permettant d'obtenir la hauteur de chaque point en niveaux de gris (figure III.7.8). Ce
rendu devait être impérativement fait dans un format d'image permettant de stocker
<figure><img src="image_32.png" /><figcaption>FIGURE III.7.9 – Dalle recomposée numériquement à partir des morceaux.</figcaption></figure>

plus de 8 bits par canal, car une précision standard est insuffisante pour représenter
le niveau de détail nécessaire, et un PNG 8 bits, par exemple, aurait fait apparaître
des artefacts dûs à la perte de précision. Il fallait également que l'espace colorimétrique
n'utilise pas de fonction de transfert, pas de gamma, mais soit simplement linéaire. J'ai
donc utilisé le format openEXR, avec des nombres flottants de 16 bits, dont la précision
est suffisante pour cette application.

J'ai d'abord essayé d'utiliser le logiciel libre de peinture Krita pour recomposer la
dalle. Le logiciel offrait déjà toutes les fonctions nécessaires (lecture et écriture d'EXR
16 bits, tampon de clonage pour combler les trous, calques, filtres, etc.), mais ses per-
formances étaient insuffisantes. En effet, nous avions déterminé la résolution du fichier
d'après celle des fraiseuses qui allaient fabriquer la pièce, soit 1500 pixels par mètre.
Il fallait pouvoir traiter la dalle dans son intégralité, et le fichier faisait donc environ
85 mégapixels. De plus, le fichier comprenait un grand nombre de calques, et les opéra-
tions de peinture étaient trop lentes dans ces conditions sur Krita. Le studio disposant
de quelques licences de la suite de création d'Adobe, j'ai testé avec Photoshop. Les performances en peinture étaient assez faibles sur un fichier de cette envergure, mais plus acceptables que sur Krita.

Une fois le dessin de la dalle validé figure III.7.9, à ce stade le document de travail n'était encore qu'une image plane représentant le relief, et l'équipe de fabrication avait besoin de fichiers 3D dans un format standard et aux bonnes dimensions. Afin de générer ces fichiers, j'ai appliqué l'image comme un déplacement dans Blender de façon à générer un relief, puis découpé de nouveau l'objet en douze parties, tel que le prévoyait le plan de fabrication.

### III.7.2.2 Sculpture numérique

De la même manière que pour la dalle précédemment évoquée, les collections du musée contiennent de nombreux os d'animaux préhistoriques, dont un spécimen assez complet de caséidé. Le squelette fossile de cet animal était très fragile et il était impossible d'exposer l'original aux visiteurs. De plus, il manquait des morceaux à beaucoup d'entre elles. Il a donc été décidé de les numériser, de les réparer virtuellement, de les fabriquer, et de les peindre d'après les couleurs et matières des os originaux, afin de donner l'illusion qu'il s'agissait effectivement des vrais os, tout en les gardant protégés dans la réserve.

Pour ces pièces, dont la précision devait être bien plus grande que pour la dalle en raison de leur petite taille, l'équipe a fait appel à une entreprise spécialisée dans la numérisation 3D. Celle-ci a utilisé un scanner laser et a livré les fichiers 3D. Puisque le travail était sous-traité à un prestataire, il n'y avait pas de choix possible des logiciels et méthodes de numérisation.

L'utilisation de logiciel libre pour l'acquisition est dans ces cas limitée aux seuls formats d'échange négociés avec le sous-traitant. En l'occurrence, le choix par défaut est le format STL<fnref n="5" />, qui est assez simple et ancien, et très utilisé dans le domaine de la CAO* pour transmettre des objets 3D. Ses capacités sont assez limitées par rapport aux formats d'échange pour le film ou le jeu vidéo, mais il peut être lu et écrit dans la

<footnote n="5">5. Abréviation de stereolithography, du nom d'une technique d'impression 3D.</footnote>
<figure><img src="image_33.png" /><figcaption>FIGURE III.7.10 – Squelette d’animal préhistorique dans l’exposition.</figcaption></figure>

plupart des programmes, sa spécification est ouverte (cf. section II.3.2), et il est donc nécessaire de l'utiliser pour communiquer avec des équipes spécialisées dans la CAO.

Une fois ces scans 3D obtenus, leur traitement a pu commencer. Duy Kévin Nguyen, qui travaillait également au sein de l'équipe technique des Fées spéciales, les a importés dans Blender afin de reconstituer les parties manquantes et de nettoyer les modèles numérisés (figure III.7.11). Les techniques de sculpture numérique utilisées pour cela sont très proches de celles qui ont cours dans les studios d'animation pour la création d'assets. Le but étant de retrouver les parties manquantes tout en restant réaliste, Duy a appliqué une symétrie sur des os existants lorsqu'ils existaient, et le reste du temps sculpté les modèles d'après des références photographiques.

Malgré les possibilités existantes, la démarche d'utiliser des logiciels libres est parfois compromise par des problèmes de performance ou de stabilité. Ces problèmes peuvent
<figure><img src="image_34.png" /></figure>

FIGURE III.7.11 – Un os sculpté dans Blender à partir du scan. On voit les parties reconstituées, plus lisses.

être résolus en découpant le travail de plus de manière efficace, ou en contactant les développeurs et en leur faisant part des problèmes rencontrés, mais ces deux solutions prennent plus de temps et leur issue est plus incertaine que celle d'utiliser un programme déjà connu, et pour lequel on a déjà des licences.

Dans tous les cas, un travail préparatoire de veille et de test est indispensable pour être prêt dès le début du projet. Ce travail prend un temps qui n'est pas toujours compatible avec les contraintes de projet auxquels sont soumis les studios d'animation. Ce fait demeure un des obstacles à l'adoption des logiciels libres dans les plus petites structures, dont les équipes techniques disposent d'un temps encore plus limité.

### III.7.3 Photogrammétrie libre

La photogrammétrie est un ensemble de principes, d'algorithmes et de techniques permettant de faire une numérisation d'un objet physique à partir de plusieurs photo-
graphies de cet objet. Les principes ont d'abord été développés pour la cartographie, et fondés sur des prises de vue aériennes, bien avant l'invention de l'informatique. Elle a trouvé de nouvelles applications depuis le début du millénaire, et s'est rapidement répandue dans l'animation et les effets spéciaux, avec la facilité de prise de vue des appareils photo numériques et l'augmentation de la puissance de calcul des ordinateurs personnels. Aujourd'hui, il est très facile de s'équiper pour faire de la photogrammétrie.

La photogrammétrie est techniquement constituée de plusieurs étapes, exécutées séquentiellement : établir des points de correspondance entre les images, retrouver les emplacements des points de vue dans l'espace, estimer la distance des points depuis la caméra pour chaque image, projeter ces points dans un espace 3D, interpoler ce nuage de point pour obtenir un nuage de points dense, éliminer les erreurs de mesure, créer un maillage à partir du nuage de point, et projeter la couleur des photogrammes sur ce maillage. Il existe des variations sur ce processus, et plusieurs algorithmes existent pour chaque étape.

De nombreux programmes propriétaires performants existent pour faire les calculs permettant d'obtenir un maillage 3D à partir d'une série d'images. Le but de cette section n'est ni de décrire en détail chaque étape, ni chaque programme, mais d'exposer quelques exemples de solutions libres de photogrammétrie, la logique qui les sous-tend, et l'utilisation que peuvent en faire les studios.

### III.7.3.1 MicMac

MicMac [16] est un programme de photogrammétrie composé d'un ensemble de commandes exécutables avec ou sans interface graphique, dont chacune correspond à une étape du processus exposé plus haut. Principalement destiné aux scientifiques, ce programme est difficile d'utilisation, et je n'ai pas réussi à en obtenir de résultats satisfaisants lors de la phase de veille préalable au projet. Il est néanmoins intéressant à mentionner.

En effet, j'ai pris connaissance de ce programme en 2017 lors d'une conférence de
Maxime Seguin, qui était à l'époque archéologue auprès de l'INRAP 6 de Montpellier, sur l'application de la photogrammétrie à l'archéologie [24]. Dans cette conférence, il présentait MicMac en exposant sa méthodologie de numérisation lors des fouilles d'un site archéologique proche de Montpellier, le Mas Rouge.

D'après M. Seguin, ce programme destiné aux scientifiques n'est pas facile d'utilisation, mais il donne des résultats d'une grande précision s'il est bien utilisé. L'utilisation d'un logiciel libre par les scientifiques a le grand avantage qu'on peut en lire le code source pour connaître ses algorithmes, contrairement au logiciel propriétaire Agisoft Photoscan que la plupart des archéologues utilisent et qui a popularisé la photogrammétrie parmi eux, mais dont il est impossible d'évaluer l'erreur.

Le conférencier a également mentionné l'intérêt du logiciel libre dans la conservation de données à moyen et long terme. Selon lui, l'utilisation d'un format de données propriétaire et fermé ne donne pas la certitude de pouvoir le conserver, le rouvrir et l'exploiter à long terme. Cette problématique n'est pas propre aux domaines scientifiques. Elle est fondamentale pour n'importe quelle organisation, et elle est explorée plus en détail dans la section II.1.2.

Ces conclusions de scientifique ne sont pas entièrement pertinentes pour un studio d'animation. En effet, un levé architectural ou archéologique doit être le plus exact possible pour pouvoir être utilisé dans des recherches scientifiques, mais dans la création numérique il suffit que les résultats soient visuellement crédibles, ce qui signifie que de petites erreurs de mesure ont peu de conséquences. En revanche, la facilité d'utilisation et la performance d'un programme sont beaucoup plus importantes, dans la mesure où la photogrammétrie n'est pas l'outil principal des graphistes, et qu'ils ne peuvent pas passer longtemps à paramétrer un programme pour obtenir des résultats très fins. Or, MicMac est précisément à l'opposé. Son interface, en ligne de commande, est très difficile à prendre en main, et il faut très bien connaître le programme pour obtenir des résultats corrects. Il n'est donc pas adapté à une utilisation occasionnelle de la photogrammétrie pour l'animation.

<footnote n="6">6. Institut National de Recherches Archéologiques Préventives</footnote>
### III.7.3.2 Colmap, openMVG, openMVS, MVE, Meshlab, etc.

Comme je l'ai expliqué en introduction de ce chapitre, le processus de photogrammétrie est composé de multiples étapes, et chaque étape peut être traitée par plusieurs méthodes et algorithmes. Aussi, il existe tout un écosystème de logiciels libres de photogrammétrie, chacun étant conçu pour une étape précise. Mais pour avoir un processus complet, il faut que les différentes étapes soient compatibles, c'est-à-dire que les données sortant d'un programme soient interopérables* avec le suivant. C'est le cas de plusieurs programmes de photogrammétrie libres. Ces programmes peuvent être utilisés ensemble, et certaines parties du processus peuvent être traitées par l'un ou l'autre programme. Certains programmes, comme Colmap et Meshlab, ont une interface graphique, tandis que d'autres ne s'exécutent qu'en ligne de commande. Cette approche est conceptuellement intéressante, parce que sa modularité permet de choisir le programme le plus adapté pour chaque étape. Si un algorithme ou une implémentation plus performante est publiée, il suffit de remplacer une partie du pipeline* photogrammétrique, sans devoir jeter tout le reste.

Cependant, bien que ce processus soit plus facile à mettre en œuvre que MicMac, il est nécessaire de scripter un minimum pour obtenir un pipeline facile d'utilisation, ce qui ne les met pas à la portée de tous les utilisateurs. En revanche, un pipeline entièrement scriptable peut être extrêmement utile à des utilisateurs avancés, en particulier pour traiter de grandes quantités de données.

Colmap est dans cet écosystème le seul programme entièrement dédié à la photogrammétrie à fournir une interface graphique optionnelle, et incluant toutes les étapes <fnref n="7" />. Il est donc assez accessible, avec des réglages corrects par défaut et un processus simple, tout en proposant une grande souplesse et de nombreux réglages.

<footnote n="7">7. L'autre programme disposant d'une interface graphique est MeshLab, qui est beaucoup plus polyvalent et permet de très nombreuses opérations sur des maillages et nuages de points.</footnote>
### III.7.3.3 Meshroom

Meshroom est un logiciel libre de photogrammétrie développé depuis 2010. Il a suscité beaucoup d'intérêt dans la communauté de l'animation lors de sa sortie publique en 2018, car c'est le premier à offrir des algorithmes performants derrière une interface graphique facile à prendre en main par des non-spécialistes. C'est en fait un regroupement de différents programmes développés au sein de plusieurs laboratoires publics français, tchèque et norvégiens, et du studio Mikros Image.

Comparé aux autres programmes sus-mentionnés, il a pour particularité d'avoir été conçu spécifiquement pour les besoins industriels des studios d'animation, en particulier concernant l'interface graphique, qui suit des conventions habituelles pour les logiciels de création 3D : présence d'une vue 3D, pipeline photogrammétrique paramétrable représenté par une interface nodale, export de caméras animées, de nuages de points colorés et de maillages texturés au format standard Alembic, paramètres par défaut équilibrés.

Meshroom est en fait une interface graphique pour un framework* de photogrammétrie, Alicevision, et les deux projets sont développés en même temps. Il est donc possible, tout comme les autres programmes, de scripter un processus différent de celui prévu par défaut dans l'interface graphique. De plus, il est à noter qu'Alicevision se fonde en partie sur plusieurs des programmes libres en ligne de commande mentionnés, en particulier sur openMVG.

Nous avons fait un bref tour d'horizon des solutions libres de photogrammétrie qui pouvaient être utilisées par les studios d'animation. Au cours de la décennie 2010, on a vu rapidement se développer des programmes dédiés efficaces et accessibles. L'arrivée de Meshroom, co-développé par un studio d'animation et d'effets spéciaux, témoigne de l'intérêt croissant des studios pour ces techniques, qui les utilisent sur de nombreux projets de films.
### III.7.4 Conclusion

Ce chapitre consacré à la numérisation et à l'usinage d'objets physiques a mis en évidence la possibilité de faire reposer un pipeline sur le logiciel libre, en dépit de la difficulté d'utilisation de certaines solutions. Comme dans d'autres domaines, un pipeline reposant sur des logiciels libres doit être activement développé par les studios, ce qui demande généralement des ressources initialement plus élevées qu'avec un équivalent propriétaire clef en main.

Il y a dans tous les cas un fort potentiel pour les studios d'animation souhaitant s'intéresser à ces techniques, dans la mesure où d'une part, la convergence est en train de s'établir entre les techniques, et où d'autre part ils sont les mieux à même de proposer des œuvres hybrides mêlant l'image animée à l'installation physique (muséographie, création volumique, vidéoprojection).
Conclusion de la troisième et
dernière partie

Cette dernière partie a permis d'explorer la conception et la constitution d'un pipeline libre dans le studio d'animation Les Fées spéciales, à travers certains des projets qui ont été le support de cette réflexion. Nous avons vu que s'il existait des applications performantes permettant de répondre aux besoins de certains départements, d'autres étaient encore lacunaires.

Cependant, plus important que cet état des lieux des logiciels à un instant précis, il a été intéressant d'examiner la manière dont les studios peuvent être moteurs dans le développement de leurs propres outils. Ces outils peuvent être des solutions complètes à un problème donné, comme l'exemple de Storymatic (cf. section III.2.1.4), ou des éléments pouvant être réutilisés dans d'autres contextes, des bibliothèques ou frameworks (cf. section III.5.1.2) ou des add-ons (cf. section III.2.2). Ils sont souvent en premier lieu uniquement destinés aux productions internes d'un studio, mais peuvent également à terme être mises à disposition de tous, comme l'a été l'outil de création de pantins (cf. section III.3.1).

Nous avons également étudié les pratiques d'utilisation de données ouvertes, et comment elles peuvent être utiles aux studios dans la création de certains types de programme, en particulier à visée scientifique.

Enfin, nous avons fait une incursion dans les techniques d'acquisition et d'usinage 3D, permettant de passer du réel au virtuel, et inversement. Cette hybridation est de plus en plus accessible en utilisant des logiciels libres de capture, de modélisation 3D et
de CAO*, et les studios d'animation peuvent donc être amenés à diversifier leur activité,
sans pour autant bouleverser leur pipeline.
# Conclusion générale

Cette thèse menée en entreprise a permis d'examiner l'utilisation et le développement du logiciel libre ou open source dans l'animation 3D. En étudiant les programmes et les manières de les utiliser, j'ai pu dégager des conclusions selon deux axes importants. Le premier axe, et le plus fondamental, s'est intéressé aux changements que peuvent apporter l'utilisation et le développement de logiciel libre dans le secteur de l'animation, et au regard que peuvent porter les studios sur les moyens de production que constituent les logiciels. Le deuxième axe est celui de la possibilité de mise en œuvre d'un pipeline libre, c'est-à-dire les programmes que les studios peuvent utiliser aujourd'hui dans le cadre de leurs productions, et les éléments qu'ils doivent considérer pour diffuser leurs propres solutions internes en open source.

## Contexte de recherche

Une première étape de cette thèse a été d'exposer le contexte de recherche, qui est la rencontre entre deux mondes : le cinéma d'animation et le logiciel libre.

## L'animation

Le cinéma d'animation présente un environnement de production particulier, car il mêle des processus de haute technicité à une grande expertise artistique. Le contexte professionnel de ces productions est généralement une entreprise appelée un studio d'animation. Cette thèse s'intéressant à l'utilisation professionnelle des logiciels, j'ai expliqué les particularités de ce type de structure.
En particulier, j'ai évoqué le studio dans lequel j'ai effectué la majeure partie de ma
thèse, la SCOP Les Fées spéciales. Ce jeune studio a choisi de mettre un accent particulier
sur la R&D*, c'est-à-dire sur le développement de solutions techniques destinées à la
fabrication des images. J'ai montré comment mon rôle au sein du département technique
de l'entreprise m'a permis d'explorer l'ensemble de la chaîne de fabrication d'un studio,
structurée sous la forme de son *pipeline*.

Pour bien comprendre les enjeux que peut représenter l'utilisation de logiciels libres
pour la production, j'ai décrit un *pipeline* typique d'un petit studio, c'est-à-dire les
différentes étapes permettant de passer du concept à l'œuvre finie, et découpées en
départements.

Le logiciel libre

La deuxième facette de cette thèse est l'étude des logiciels libres, une catégorie de
programme définie par des concepts juridiques complexes, une histoire riche, et des
valeurs idéologiques qu'il est important d'appréhender pour comprendre la démarche
des créateurs de logiciels libres, et celle que peuvent aussi adopter les utilisateurs.

J'ai donc évoqué la création des logiciels libres en réaction à la fermeture et à la
marchandisation progressives des programmes informatiques dans les années 1970 et
1980, en particulier l'œuvre de Richard M. Stallman, un développeur états-unien qui
conçut les premières licences de logiciels dites *libres*, ainsi que des programmes diffusés
selon les termes de ces licences (cf. section I.2.1).

J'ai analysé les licences elles-mêmes dans une approche de propriété intellectuelle (cf. section I.2.2), la partie des lois gouvernant la protection des logiciels. J'ai évoqué comment la licence logicielle, un contrat entre l'auteur et l'utilisateur, spécifiait les droits accordés à ce dernier, et comment les licences libres détournent ce principe pour accorder beaucoup plus de droits que ne l'envisageait une lecture plus classique de la propriété intellectuelle. En particulier, j'ai évoqué les quatre libertés qui constituent la définition même du logiciel libre et de l'open source : utiliser, étudier, modifier et distribuer le code source informatique.
## Enjeux

Le cœur de cette recherche se situe dans la confrontation de ces deux sphères d'activité, pour dégager ce qui caractérise l'utilisation du libre par les studios d'animation. Les interactions entre le logiciel libre et la production d'animation sont complexes, c'est pourquoi j'ai décomposé mon analyse selon trois critères complémentaires : juridiques, économiques, et techniques (cf. partie II).

## Juridique

En s'appuyant sur le droit d'auteur, ou copyright dans ses équivalents anglo-saxons, les développeurs de logiciels libres donnent à leurs utilisateurs quatre libertés, qui entrent dans la définition du logiciel libre comme du logiciel open source. Pour un studio, ces quatre libertés (cf. section II.1.1) présentent en théorie de nombreux avantages.

Le studio peut utiliser le programme à sa guise, sans être restreint par un contrat qui le priverait de certains types d'utilisations, sur autant de machines qu'il le désire, dans tous les pays, et sans limitation de durée.

Il peut étudier le code source du programme et vérifier qu'il se comporte comme prévu. Il peut apprendre comment il fonctionne pour réutiliser ses algorithmes dans d'autres programmes. Dans certains cas, il peut même réutiliser directement du code.

Si les équipes rencontrent un dysfonctionnement, elles peuvent le résoudre par elles-mêmes ou engager quelqu'un pour le faire. Elles peuvent modifier le programme pour mettre en œuvre des fonctionnalités manquantes nécessaires aux projets en cours.

Même dans le cas où le studio ne disposerait pas d'une équipe R&D dédiée, les TD* ou les graphistes eux-mêmes peuvent être encouragés à faire aux développeurs des rapports de bugs*, qui sont souvent traités rapidement – selon les capacités de développement du projet.

Du fait que les licences libres donnent un droit d'utilisation illimité, la disponibilité du programme n'est pas soumise aux décisions mercantiles de l'éditeur. Contrairement aux programmes propriétaires, un logiciel libre qui ne serait plus développé par ses développeurs originaux peut continuer d'être utilisé et maintenu par une communauté
d'utilisateurs et de développeurs (cf. section II.1.2).

Si l'utilisation de logiciels libres ne requiert pas de contrepartie, les utilisateurs sont encouragés à y contribuer à leur tour, à la mesure de leurs ressources et de leurs compétences. Cette contribution peut être financière ou technique. Les studios peuvent ainsi, en accord avec les communautés de développeurs et d'utilisateurs, s'impliquer directement dans le développement de leurs logiciels, en écrivant du code, en rapportant les bugs et problèmes de conception, en traduisant les interfaces, en complétant la documentation, ou en publiant leurs outils internes.

## Économique

Le logiciel libre n'est pas nécessairement gratuit. En fait, les notions de liberté et de gratuité sont orthogonales. Ceci dit, les logiciels libres sont aussi gratuits la plupart du temps, en vertu du fait que chacun puisse librement redistribuer les programmes, d'après la définition même des licences libres, et qu'il soit donc difficile aux éditeurs de se garantir un monopole commercial (cf. section II.2.1).

En première approche, il peut donc être financièrement intéressant pour les studios d'utiliser les logiciels libres, qui sont généralement gratuits. Une licence peut être redistribuée, ce qui signifie qu'un logiciel libre peut être installé sur un nombre arbitraire de machines, sans devoir négocier l'achat ou la location de licences lorsque la taille de l'équipe fluctue, offrant donc la plus grande souplesse aux entreprises.

Cependant, j'ai montré que le prix des logiciels n'est pas seulement celui qui est attaché aux licences : les studios peuvent toujours payer pour du support technique, du développement prioritaire, ou simplement faire des dons aux communautés de développement pour financer le développement des programmes.

Dans un contexte d'entreprise, la gratuité apparente s'avère vite fausse, en particulier quand une équipe R&D doit être engagée pour faire fonctionner le logiciel et l'adapter aux processus de fabrication (cf. section II.2.2).

Même dans le cas où le studio paie le développement des logiciels libres, soit par ses salariés, soit par des sous-traitants, ces développements peuvent profiter à tous les
autres utilisateurs, puisque le logiciel libre constitue un bien commun. Ainsi, les studios peuvent mettre en commun leurs ressources pour développer des solutions libres plutôt que d'essayer de conserver un secret industriel, en recommençant de zéro ce qui a souvent déjà été fait (cf. section II.2.3).

## Usages

En plus de ses particularités économiques et juridiques, le logiciel libre peut créer de nouveaux usages au sein des studios d'animation.

J'ai ainsi montré que certains logiciels libres étaient non seulement très performant, mais créaient des fonctionnalités novatrices sans équivalent chez leurs équivalents propriétaires. Il faut garder à l'esprit que cette observation n'est pas généralisable, ni nécésairement imputable au fait que qu'il s'agisse de logiciels libres, mais elle est néanmoins utile pour montrer que le modèle du logiciel libre permet de développer des programmes performants.

J'ai évoqué deux exemples de fonctionnalités intégrées au cours des dernières années au logiciel d'animation Blender : le Grease Pencil, un outil de dessin animé dans un espace 3D, qui permet une hybridation des techniques d'une manière jamais vue dans un logiciel public ; et Eevee, un moteur de rendu utilisant les techniques de rendu « temps réel » des jeux vidéo, pour offrir un rendu interactif de haute qualité (cf. section II.3.1).

Un autre aspect primordial pour les studios est celui de l'operérabilité et de la standardisation (cf. section II.3.2). Il désigne la capacité de différents logiciels à être utilisés ensemble, en particulier par le biais de formats de fichiers ouverts, dont les spécifications sont accessibles à tous, et qui peuvent être lus et écrits depuis différents programmes. Pour les studios d'animation, cela signifie que plusieurs logiciels peuvent être utilisés dans une même chaîne de fabrication, et les données passer facilement de l'un à l'autre. Dans l'animation, il existe plusieurs formats d'échange importants, comme Alembic et OpenEXR, développés au sein de studios et rendus open source pour en généraliser l'usage. Ces formats sont ouverts et leurs spécifications publiques, mais ils comportent aussi des bibliothèques* logicielles leur permettant d'être intégrés dans n'importe quel
logiciel de création, qu'il soit libre ou propriétaire.

Enfin, j'ai abordé la participation d'un studio au développement de logiciels libres (cf. section II.3.3), qu'ils soient initiés par le studio et publiés ensuite, ou déjà existants. Les logiciels libres tirent leur force de leur communauté, et les studios disposent souvent des compétences leur permettant de participer utilement au développement, puisqu'ils écrivent souvent des outils destinés à leurs productions internes. Cette collaboration communautaire n'est pas nécessairement facile, et j'ai aussi montré les situations qui peuvent freiner les studios, en particulier quand les besoins ou les méthodes de développement de la communauté ne s'aligne pas avec ceux du studio.

## Un pipeline libre : possibilités et limites

Parmi les logiciels libres existants dans le domaine de l'animation numérique, plusieurs ont démontré aujourd'hui être des alternatives viables à des programmes plus courants. Entre le système d'exploitation GNU/Linux*, les logiciels de création Blender et Krita, et jusqu'au lecteur vidéo DJV View (cf. section III.4.1) ou au logiciel de storyboard Storyboarder (cf. section III.2.1.3), des alternatives existent en 2019 pour de nombreuses tâches. Dans une démarche de développement collectif, un nombre croissant de studios adopte également des outils de gestion d'assets et de suivi de production libres, comme Kabaret et CGWire (cf. section III.5.1). Il faut aussi observer que de nombreux composants libres sont utilisés pour créer d'autres logiciels, y compris propriétaires, tels que les bibliothèques OpenEXR (cf. section II.3.2.1), ou le langage de script Python, et que ces composants sont même devenus indispensables aux studios comme aux éditeurs.

Cependant, certaines étapes de travail importantes n'ont à ce jour pas d'alternative libre crédible, à une échelle industrielle ou même artisanale. Parmi ces tâches, on trouve en particulier le compositing et le motion design, pour lesquels le logiciel Adobe After Effects est pratiquement incontournable (cf. section III.3.3.1).

Il est important toutefois de nuancer ces premières conclusions, car une telle liste de logiciels, utilisables ou pas, équivalents ou non à des solutions établies, n'est valable qu'à un moment précis. Elle peut s'avérer caduque rapidement, en raison de la vitesse à
laquelle les modes changent dans le milieu.

Ainsi, le logiciel libre de montage vidéo Olive [50] existe depuis 2018 et au moment où j'écris ces lignes, début 2020, il commence à faire parler de lui. Si son rythme de développement et d'adoption continue, il pourrait vite devenir référence dans son domaine. Il pourrait aussi cesser d'être développé du jour au lendemain et tomber dans l'oubli.

Un autre exemple, celui de Natron (cf. section III.3.3.2), a montré que des ressources suffisantes pouvaient mener à la création d'un programme performant dans le domaine du compositing.

Ce même exemple a montré, de manière plus intéressante, que si le prix des logiciels libres est souvent nul, son développement a un coût. Les utilisateurs, et en premier lieu les entreprises utilisant du logiciel libre, ont donc intérêt à financer ce développement en accord avec les développeurs, afin d'éviter qu'il ne se voie arrêté après quelques années (cf. section II.2.3).

## Le logiciel libre, une approche différente de la production

Une conclusion découlant de cette étude a été que l'utilisation quotidienne de logiciels libres pour la production n'est pas intrinsèquement différente des logiciels propriétaires. Blender est très différent de Maya, mais pas plus que ne l'est Houdini, un autre logiciel propriétaire.

Quoiqu'instructif, faire une liste de logiciels libres utilisables en production a un intérêt limité, car le logiciel libre présente des différences fondamentales par rapport au logiciel propriétaire : le premier voit le logiciel en tant que bien commun, tandis que le deuxième le considère comme un bien de consommation.

## Les données ouvertes, un pas vers la culture libre

Le logiciel libre et open source est maintenant établi depuis des décennies dans d'autres secteurs que celui de l'animation, et commence à pénétrer celui-ci. D'autres types d'informations, de contenus, de « propriété intellectuelle » font l'objet de mouvements similaires.
Ainsi, le mouvement de l'open data prend son essor (cf. section I.2.4). De plus en plus d'organisations publiques ou privées voient dans ce modèle un moyen de créer de la richesse partagée, en mettant leurs données à disposition de tous à l'aide d'outils juridiques spécifiques, de façon à créer un bien commun, sur lequel tous puissent s'appuyer pour créer. Dans certains cas, comme OpenStreetMap, ces bases de données sont établies de manière collaborative, et chacun peut les enrichir.

Les studios peuvent s'appuyer sur ces bases de données ouvertes pour créer leurs œuvres, c'est-à-dire créer de la richesse à partir de ce bien commun. Tout comme pour le logiciel libre, les studios peuvent également, et ils ont intérêt à le faire, contribuer dans leurs capacités à ces bases de données, pour que le fruit de leur travail puisse être exploité par d'autres individus qui comme eux, ont utilisé le travail d'une communauté.

## Ouvertures

Cette thèse ouvre à plusieurs perspectives de recherche, en particulier les licences de libre diffusion (cf. section II.1.4), un autre type de contrat prévu pour diffuser, non plus les logiciels spécifiquement, mais tout type de contenu protégé par les lois de la propriété intellectuelle, tel que textes, sons, images, polices d'écriture, et vidéos. Ces licences ont permis la création de projets tels que Wikipédia, dans lesquels tous les contenus sont réutilisables par tous pourvu qu'ils respectent les termes de la licence.

Dans le domaine de l'animation, certaines initiatives existent, comme les films de la Blender Foundation et le projet Morevna, mais ces initiatives sont encore marginales. En effet, ce type de publication est très peu connu, et il existe une difficulté à trouver des modèles de financement fiables et pérennes pour la production. Néanmoins, dans une société où le contexte économique, social et culturel est en transformation rapide, ces modèles peuvent représenter des alternatives importantes à la diffusion de masse de quelques gros acteurs, qui demeure aujourd'hui la norme.

Un autre aspect du logiciel libre, d'une importance capitale mais pas toujours pris en considération, voire parfois méprisé, est le rôle social que peut jouer le logiciel libre, en permettant en particulier aux utilisateurs, qu'ils soient salariés ou indépendants, de
s'approprier leurs outils, leurs moyens de production, pour mieux s'émanciper. Cet aspect est très politique, et c'est la raison pour laquelle dans beaucoup de communautés open source, il est ignoré, voire décrié : il devrait s'effacer devant une prétendue neutralité politique, ou devant la simple performance technique des programmes. Bien sûr, l'étude politique n'est pas le sujet de cette thèse, mais le contact que j'ai eu avec le logiciel libre m'a fait prendre conscience que cet aspect était au cœur de la question, et que les principes sous-tendant le logiciel libre pourraient avoir une influence sur le cinéma d'animation.

Par exemple, l'animation française bénéficie de nombreuses subventions publiques, qui lui permettent souvent de survivre. Par ailleurs, un mouvement se développe actuellement, en particulier au sein de la communauté du logiciel libre, dont le but est de demander que tout programme financé par le public soit également disponible pour le public, c'est-à-dire publié sous licence libre. Cette revendication s'étend à la recherche privée financée par des fonds publiques, qui protège souvent ses fruits par des brevets. Cela pourrait également s'étendre à l'animation, c'est-à-dire à la fois aux solutions techniques développées par les studios avec des subventions publiques, mais au-delà, aux contenus audiovisuels. Ces questions de propriété intellectuelle et de biens communs sont aussi bien pertinentes pour la technique que pour la création artistique, et il serait bon que les producteurs de contenu comme leurs consommateurs s'y intéressent.
# Glossaire

**add-on** Un add-on, mot anglais signifiant à peu près « ajout », aussi appelé plug-in, « qui se branche », et parfois greffon en français, est un ajout de fonctionnalité à une application hôtesse principale. C'est donc en soi un programme informatique, mais qui ne peut exister sans être ajouté à un autre programme. Un add-on est typiquement écrit en utilisant l'API* du programme hôte, et on le considère souvent de ce fait comme un script*. La distinction est que l'add-on forme un tout cohérent, intégrant des fonctionnalités liées entre elles, et distribuées ensemble. L'add-on peut typiquement permettre d'ajouter de nouvelles fonctions et opérations, de modifier l'interface, de créer des possibilités non prévues par les développeurs du programme hôte. 43, 68, 103, 121, 122, 124, 127, 164, 167, 168, 178, 185, 198, 270

**amont** En développement logiciel, on parle d'amont et d'aval lorsqu'une version dérivée d'un programme est créée. C'est ce qui arrive notamment en cas de fork*, qui est un procédé normal dans le développement open source. Les sources amont sont celles d'origines, celles d'aval, les versions dérivées. Plusieurs dérivations peuvent se succéder, et une version pourra alors avoir à la fois une source en amont, et plusieurs descendants en aval. Si une version amont adopte les changements de sa version aval, on dit qu'ils sont reversés en amont. En anglais, on parle d'*upstream* et *downstream*. 77, 247

**API** Une API (Application Programming Interface) est une interface de programmation applicative. Il s'agit initialement de la spécification d'un ensemble de fonctions et de protocoles permettant de simplifier le développement logiciel en faisant abstraction de l'implémentation logicielle ou matérielle. Dans cette thèse je donne à
l'acronyme une définition légèrement différente, celle d'une bibliothèque permettant le développement de scripts au sein d'une application. De la même manière que l'interface graphique expose à l'utilisateur les fonctionnalités d'une application, l'API permet d'utiliser l'application via du code. Concrètement, il s'agit d'une bibliothèque dans un langage de programmation. Cette bibliothèque offre des classes et fonctions permettant manipuler les données dans le programme. On peut s'en servir pour faire des scripts, c'est-à-dire des groupes d'opérations, ou bien des outils, qui étendent les capacités du programme hôte. Par exemple, l'API Python de Blender, *bpy*, permet d'automatiser des tâches en applicant plusieurs opérations à la suite, ou de créer de nouveaux outils dans l'interface graphique, tenant compte des entrées de l'utilisateur. 55, 67, 90, 111, 122, 153, 156, 191, 244, 251

**asset** Un asset (qu'on peut traduire littéralement en français par « actif », mais qui est plus justement appelé un « élément ») est un ensemble de données informatiques réutilisables pour un projet de film ou de jeu vidéo. Par exemple, un décor, un personnage, un accessoire, sont des assets, et chacun sera constitué de modèles 3D, de textures, de rigs, d'animations, etc. 32, 37, 94, 150, 190, 212, 214

**bibliothèque** Une bibliothèque est un type de programme informatique. C'est un ensemble de routines réutilisables, permettant de manipuler un type précis de données, ou de répondre à un problème particulier. Contrairement aux applications ou aux scripts, une bibliothèque n'est pas faite pour être utilisée directement, mais pour être appelée depuis un autre programme. L'intérêt est que le développeur d'applications puisse s'appuyer sur du code partagé, souvent bien testé, et de développer donc plus vite, sans recommencer de zéro. Les améliorations apportées à une bibliothèque, quand elles ne cassent pas la compatibilité avec les versions précédentes, bénéficient à tous les développeurs qui l'utilisent. La publication de bibliothèques est essentielle pour les écosystèmes logiciels, car elles permettent de réutiliser du code pour différentes applications et donc de réduire les coûts de développement. C'est une manière d'obtenir une architecture modulaire et non monolithique. 77, 82, 85, 86, 88, 90, 103, 115, 120, 168, 183, 186, 202, 239, 270
**build** Une build est une version binaire, compilée d'un programme. À partir d'un même code source, un développeur peut générer différentes builds, selon les outils et options de compilation. Lorsqu'on installe la version officielle d'un programme, il s'agit d'une build, mais il est aussi possible, lorsqu'on dispose des sources, de compiler une build. Certains projets proposent également des builds quotidiennes à télécharger pour tester les dernières fonctionnalités ou correctifs, en-dehors de la distribution habituelle. 210

**cache** Un cache est une manière de stocker des données, indépendamment de la manière dont elles sont calculées. Lorsqu'un programme effectue un calcul complexe, il est intéressant de garder le résultat de ce calcul, et de l'enregistrer dans un cache. Par exemple, une simulation physique complexe pour des effets spéciaux sera généralement enregistrée dans un cache sur le disque pour éviter de le recalculer plusieurs fois. De même, un programme de compositing peut mettre les images d'une séquence en cache, pour pouvoir les lire de manière fluide, plutôt que de les recalculer à chaque lecture.

Ce procédé présente plusieurs intérêts. D'abord, il permet d'accélerer les processus, puisque les calculs ne sont faits qu'une fois. Ensuite, dans le cas où un calcul n'est pas déterministe, comme c'est le cas de certaines simulations physiques, on peut obtenir à chaque fois le même résultat en le mettant en cache. Enfin, un cache permet d'améliorer l'interopérabilité*. En effet, deux programmes qui n'utilisent pas les mêmes algorithmes pour évaluer un calcul peuvent être rendus compatibles s'ils se contentent d'échanger le résultat de l'évaluation. Par exemple, une animation de personnage réalisée dans un logiciel donné peut être exportée en cache et se retrouver à l'identique dans un autre programme utilisant un système de rig complètement différent. 71, 103, 197

**CAO** La conception assistée par ordinateur (CAO) est la modélisation d'objets et de leurs propriétés physiques, en vue de leur fabrication. Elle permet d'obtenir des plans de fabrication et de montage, et parfois directement de commander les machines de fabrications, telles que les fraiseuses à commande numérique et les im-
primantes 3D, pour transformer des modèles numériques en objets physiques. 29, 212, 225, 234

**CNC** Le Centre national du cinéma et de l'image animée est une organisation publique française chargée en particulier d'aider à la production et à la diffusion des films, mais aussi d'autres types d'œuvres (séries, jeux vidéo). 107, 191

**code source** Le code source d'un programme est un ensemble de fichiers informatiques écrits dans un langage de programmation. Il permet de générer le programme, et décrit son comportement, la manière dont il traite les données et fait ses calculs. Il est nécessaire d'avoir accès au code source pour pouvoir modifier un programme, en créer une version différente, ou l'intégrer à un autre programme. 42, 44, 49, 50, 62, 66, 72, 75, 79, 85, 89, 94, 108, 109, 114, 126, 183, 192

**fork** Un fork est une version alternative d'un logiciel open source. Un développeur crée un fork d'un programme en le modifiant et en le redistribuant. Cela peut faire partie du processus normal de développement si les changements sont ensuite réintégrés dans la version amont*. Mais dès lors qu'un fork s'écarte assez de sa source pour être incompatible avec elle, les deux versions peuvent entrer en concurrence, et il devient difficile de réintégrer les modifications de l'une dans l'autre. 112, 113, 127, 244

**format de fichier** Un format de fichier est une manière de représenter des données. Un format spécifie selon quelle logique, quel ordre, quelle structure les données sont représentées. Il existe des milliers de formats de fichiers pour représenter tout type de données. La spécification d'un format comprend au minimum sa structure de données, et éventuellement des algorithmes (de compression et décompression, par exemple), et des implémentations. 113

**framework** Un framework est un ensemble de code informatique facilitant le développement logiciel dans un domaine donné, en fournissant un niveau d'abstraction plus élevé. Il se charge des détails de bas niveau, et offre au développeur une interface simplifiée ou unifiée. 39, 108, 193, 231, 270, 276
**GNU/Linux** GNU/Linux est le système d'exploitation libre le plus utilisé. Son nom est un sujet délicat. En effet, un système d'exploitation est composé de nombreux sous-systèmes, et « Linux » n'est à proprement parler que le noyau, un composant essentiel mais inutile isolément. Richard Stallman et la Free Software foundation préfèrent parler de GNU/Linux, car GNU était à l'origine le projet de développement d'un OS libre complet, auquel le noyau Linux de Linus Torvalds a été intégré par la suite. Je parle néanmoins dans cette thèse du système Linux, par raccourci. 46, 107, 164, 185, 240

**IK** La cinématique inverse (inverse kinematics, IK) est une technique de rigging et d'animation permettant de faciliter certains mouvements. Plutôt que d'animer chaque articulation, comme c'est le cas avec la cinématique directe (forward kinematics, FK), l'IK permet de bouger seulement l'extrémité du membre. Par exemple, pour animer une main, je n'aurai pas besoin de faire tourner l'épaule, le coude et le poignet ; je déplacerai simplement la main, et la position des autres articulations sera déduite automatiquement. 160

**interopérabilité** L'interopérabilité désigne la capacité qu'ont les programmes et les processus de travail d'être compatibles entre eux. C'est un problème récurrent en informatique, qui existe quand plusieurs solutions existent pour traiter un problème. Par exemple, si j'utilise un programme donné pour éditer un document écrit, je veux pouvoir l'ouvrir et l'éditer sur différentes plate-formes ou systèmes d'exploitation, dans différents programmes. Une solution à ce problème est de concevoir des formats de fichiers normalisés, qui pourront servir à faire passer les données d'un environnement à l'autre. On parle alors de formats d'échange. Mais si le programme que j'utilise ne permet pas de lire et écrire dans un format standard, ou si le standard n'est pas implémenté rigoureusement, c'est impossible. Dans l'exemple des documents textes, le format Open Document permet en théorie de passer d'un logiciel de traitement de texte à l'autre, si tant est qu'ils implémentent correctement le format. 77, 115, 246

**interopérable** 230, voir *interopérabilité*
**JSON** JSON est un format de fichier ouvert et standard, conçu pour échanger des données entre processus et entre applications. C'est un format simple, portable car utilisable dans la plupart des langages de programmation, et lisible par les humains. Il est très utilisé par exemple dans le web pour communiquer des données entre le serveur et le client (navigateur), pour mettre à jour une page de manière dynamique. 146, 197

**Linux** 99, 119, voir GNU/Linux

**logiciel de création 3D** Un logiciel de création 3D, ou suite de création 3D, souvent appelé DCC (Digital Content Creation, création de contenu numérique) est un programme permettant de réaliser les nombreuses opérations de l'animation et des effets spéciaux numériques 3D (cf. section I.1.2). Parmi les plus utilisés en 2019, on trouve Maya et 3DS Max d'Autodesk, Houdini de SideFX, Modo de Foundry, Cinema 4D de Maxon et le logiciel libre Blender. 34, 98, 99, 111, 115, 118, 119, 150, 152, 156, 164, 176, 193

**model sheet** Une model sheet ou planche de modélisation est un document graphique montrant un élément (personnage, décor, accessoire) dessiné avec assez d'indications pour pouvoir être modélisé en 3D. Généralement, y figureront au moins une vue de face, une vue de profil et une vue de dos, l'une à côté de l'autre et correspondant exactement dans la hauteur. Les hauteurs les plus caractéristiques, comme le sommet du crâne ou le bas des mains, pourront être reliées par des lignes pour bien voir la correspondance entre les vues. 25, 28

**multi-plans** La caméra multi-plans est une version évoluée du banc titre, dans laquelle plusieurs couches de décors et de celluloids sont placés sur des vitres parallèles entre elles. En déplaçant ces couches de décor l'une par rapport à l'autre, on donne à l'image l'illusion de la profondeur grâce à la parallaxe entre ces couches. 151, 152

**médium** Un médium est le moyen par lequel une œuvre est transmise au public. Il comprend le support physique et les dispositifs de diffusion, mais aussi la technique de création de l'œuvre. 16, 24, 155, 267, 281
**ODbL** La licence ODbL (*Open Database License*) est un contrat de licence destiné à être attaché à des bases de données ouvertes. Elle repose sur une logique similaire à celle des licences copyleft (cf. section II.1.3.1), mais a été conçue pour les spécificités juridiques des bases de données. 53, 56

**patch** Un patch est, par analogie avec le mot anglais pour le pansement ou la rustine, un correctif pour un bug informatique. Concrètement, c'est un fichier décrivant les lignes à ajouter, supprimer ou modifier dans le code source pour obtenir une nouvelle version. Les développeurs l'utilisent pour échanger du code, sans devoir s'envoyer des millions de lignes à chaque modification. En ne stockant dans le fichier que le différentiel, ce qui a changé entre les versions, on a un système facile à créer, transmettre et appliquer. 72, 73, 79, 104, 125

**pipeline** Le pipeline d'un studio ou d'un projet est la manière dont en est structurée la chaîne de fabrication. Il comprend les définitions des départements et étapes logiques de fabrication ; les arborescences et nomenclatures de fichiers et d'éléments au sein de ces fichiers ; les échanges de données d'un département à l'autre, d'un programme à l'autre ou d'un studio à l'autre (voir section I.1.2). 12, 21, 38, 59, 69, 77, 81, 96, 103, 108, 109, 113, 118, 123, 128, 135, 140, 143, 150, 154, 155, 164, 178, 185, 189, 193, 194, 230, 236, 267, 283

**plan** Le plan est la plus petite unité de découpage d'un film, après l'image. Il est caractérisé par la continuité de l'image, et deux plans sont séparés par une transition ou une coupure. 24, 26, 27, 34, 35, 37, 38, 40, 56, 73, 136, 143, 148, 150, 151, 181, 185, 186, 191, 193, 197, 199, 201, 203, 207, 210, 281

**plug-in** 163, 183, voir add-on

**R&D** La recherche et développement (R&D) est une pratique industrielle consistant à mener des recherches fondamentales ou appliquées sur un sujet donné, et à développer des produits, services, procédés, algorithmes, programmes. Cette activité est indispensable dans de nombreuses industries, y compris dans l'animation. Une entreprise dotée d'un service de R&D effectue de la veille technologique pour
connaître les pratiques modernes dans l'industrie, et développe ses propres solutions pour répondre au mieux aux problématiques de production. 11, 20, 37, 41, 76, 97, 98, 102, 106, 120, 131, 236, 284

**rapport de bug** Un rapport de bug, de l'anglais *bug report*, parfois aussi appelé « rapport d'anomalie », est une procédure courante dans le développement logiciel, selon laquelle un utilisateur signale un bug, une anomalie ou un dysfonctionnement aux développeurs du programme qu'il utilise. Un rapport de bug peut être interne au groupe développant le programme, comme c'est le cas lors de tests d'assurance qualité, ou provenir d'utilisateurs réels. C'est un processus indispensable pour améliorer la stabilité des programmes. La correction des bugs demande d'importantes ressources de développement. 73, 75, 237

**retake** Une retake, mot emprunté au vocabulaire du cinéma et signifiant littéralement reprise, est une modification demandée par la hiérarchie. Elle a lieu lors d'une validation auprès du superviseur ou auprès du client, lorsque des changements sont demandées sur un élément, plan ou séquence. Elle fait partie intégrante de la création d'œuvres animées, et peut intervenir à tout moment de la fabrication. 39, 147, 185, 191, 281

**scalabilité** La scalabilité d'un système ou d'un processus est sa capacité à être exploité à plus grande échelle en ajoutant des ressources. De l'anglais *scale*. 211, 281

**script** Un script est un court programme permettant d'appeler des fonctions et de manipuler des données au sein d'une application, via une API*. Il permet d'automatiser des tâches, ou d'ajouter des fonctionnalités au programme de base. Il se distingue donc des bibliothèques, qui sont appelées par les applications, et des applications elles-mêmes, qui peuvent s'exécuter indépendamment. 12, 21, 22, 43, 67, 76, 88, 89, 103, 123, 141, 169, 174, 185, 198, 208, 244, 270, 283

**skinning** Le skinning est un principe permettant de lier une surface à un rig. La surface est considérée comme une peau (en anglais *skin*) bougeant avec le squelette. Cette liaison permet d'animer des objects complexes dont la surface se déforme, par exemple des personnages. 30, 164, 172
**suite de création 3D** 76, voir logiciel de création 3D

**séquence** Une séquence est un groupe de plans constituant une unité narrative, souvent une unité de temps et de lieu. C'est grossièrement l'équivalent d'un chapitre en littérature. 24, 27, 35, 38, 40, 73, 156, 179, 184, 203

**TD** Le TD ou technical director — distinct en France du directeur technique — est dans l'animation un poste spécialisé, dont la tâche est d'élaborer le pipeline au sens le plus large : il conçoit l'architecture et l'organisation du projet, choisit les solutions techniques adaptées et crée des outils pour faciliter le travail des graphistes et de la production. Il intervient à toutes les étapes pour fluidifier les échanges et la fabrication. 20–22, 37, 41, 69, 76, 106, 131, 141, 190, 193, 237, 284

** timeline ** La timeline, mot anglais pour « ligne de temps », désigne en infographie une interface de visualisation du temps. Elle est généralement représentée par un large rectangle horizontal, dans lequel la gauche marque le début et la droite, la fin. Une ligne verticale peut symboliser l'instant sélectionné, et on peut aller avancer ou reculer en déplaçant cette ligne. 71, 145, 186
Table des figures

<table><tr><td>I.1.1</td><td>Chaîne de fabrication © Les Fées spéciales</td><td>23</td></tr><tr><td>I.2.1</td><td>Carte d'élévation de la Terre © NASA</td><td>54</td></tr><tr><td>I.2.2</td><td>Élévation appliquée à la surface d'une sphère. © NASA</td><td>55</td></tr><tr><td>III.1.1</td><td>Affiche du film <i>Dilili à Paris</i> © Nord-Ouest, Michel Ocelot</td><td>135</td></tr><tr><td>III.1.2</td><td>Affiche de l'exposition <i>Antarctica</i> © Musée des Confluences, Vincent Munier, Laurent Ballesta, intégral Ruedi Baur</td><td>137</td></tr><tr><td>III.2.1</td><td><i>Dilili à Paris</i>, plans de décors © Nord-Ouest, Michel Ocelot</td><td>151</td></tr><tr><td>III.3.1</td><td>Interface de rig de pantin dans Maya © Jean-Claude Charles</td><td>157</td></tr><tr><td>III.3.2</td><td>Concept art pour <i>Dilili à Paris</i> © Michel Ocelot</td><td>158</td></tr><tr><td>III.3.3</td><td>Image du layout de <i>Dilili</i> correspondant au concept précédent. © Nord-Ouest, Michel Ocelot</td><td>160</td></tr><tr><td>III.3.4</td><td>Rig de personnage pantin © Nord-Ouest, Michel Ocelot, Les Fées spéciales</td><td>161</td></tr><tr><td>III.3.5</td><td>Aristide Bruant dessiné par Michel Ocelot © Nord-Ouest, Michel Ocelot</td><td>162</td></tr><tr><td>III.3.6</td><td>Aristide Bruant découpé en morceaux © Nord-Ouest, Michel Ocelot, Les Fées spéciales</td><td>166</td></tr><tr><td>III.3.7</td><td>Squelette généré par l'add-on Rigify</td><td>169</td></tr><tr><td>III.3.8</td><td> mistake dans l'ordre des plaques © Nord-Ouest, Michel Ocelot</td><td>170</td></tr><tr><td>III.3.9</td><td>Espace ment des plaques dans un pantin éclaté © Nord-Ouest, Michel Ocelot</td><td>171</td></tr><tr><td>III.3.10</td><td>Interface d'édition des variations colorées © Les Fées spéciales</td><td>175</td></tr></table>
<table>
  <tbody>
    <tr>
      <td>III.6.1</td>
      <td>Musée des confluences : trajet des équipes © Les Fées spéciales</td>
      <td>201</td>
    </tr>
    <tr>
      <td>III.6.2</td>
      <td>Essais de projections cartographiques © Les Fées spéciales</td>
      <td>202</td>
    </tr>
    <tr>
      <td>III.6.3</td>
      <td>Musée des confluences : images de la banquise fournies par le client</td>
      <td>204</td>
    </tr>
    <tr>
      <td>III.6.4</td>
      <td>Musée des confluences : images de la banquise par la NASA © NASA</td>
      <td>205</td>
    </tr>
    <tr>
      <td>III.6.5</td>
      <td>Antarctica : processus graphique pour la séquence de la banquise © Les Fées spéciales (b) et (c)</td>
      <td>206</td>
    </tr>
    <tr>
      <td>III.6.6</td>
      <td>Antarctica : processus graphique pour la séquence de l'écoulement © Les Fées spéciales</td>
      <td>208</td>
    </tr>
    <tr>
      <td>III.7.1</td>
      <td>Schéma de la maquette du causse © Musée de Lodève</td>
      <td>215</td>
    </tr>
    <tr>
      <td>III.7.2</td>
      <td>Rendu 3D de la maquette du causse © Musée de Lodève, Les Fées spéciales</td>
      <td>215</td>
    </tr>
    <tr>
      <td>III.7.3</td>
      <td>Maquette du causse dans l'exposition © Musée de Lodève, Les Fées spéciales</td>
      <td>216</td>
    </tr>
    <tr>
      <td>III.7.4</td>
      <td>Dalle des empreintes dans l'exposition © Musée de Lodève, Les Fées spéciales</td>
      <td>217</td>
    </tr>
    <tr>
      <td>III.7.5</td>
      <td>Image extraite du film de la dalle des empreintes © Musée de Lodève, Les Fées spéciales</td>
      <td>218</td>
    </tr>
    <tr>
      <td>III.7.6</td>
      <td>Carte projetée dans l'exposition © Musée de Lodève, Les Fées spéciales</td>
      <td>219</td>
    </tr>
    <tr>
      <td>III.7.7</td>
      <td>Moulages de la dalle dans l'atelier © Les Fées spéciales</td>
      <td>221</td>
    </tr>
    <tr>
      <td>III.7.8</td>
      <td>Scans des moulages sous la forme de cartes de hauteur © Musée de Lodève, Les Fées spéciales</td>
      <td>222</td>
    </tr>
    <tr>
      <td>III.7.9</td>
      <td>Dalle recomposée numériquement © Musée de Lodève, Les Fées spéciales</td>
      <td>224</td>
    </tr>
    <tr>
      <td>III.7.10</td>
      <td>Squelette d'animal préhistorique © Musée de Lodève, Les Fées spéciales</td>
      <td>226</td>
    </tr>
    <tr>
      <td>III.7.11</td>
      <td>Os sculpté dans Blender à partir du scan © Musée de Lodève, Les Fées spéciales</td>
      <td>227</td>
    </tr>
    <tr>
      <td>B.1</td>
      <td>Accueil du site web Music Road</td>
      <td>268</td>
    </tr>
    <tr>
      <td>B.2</td>
      <td>La partie backend est complète, mais la carte ne s'affiche pas encore.</td>
      <td>274</td>
    </tr>
  </tbody>
</table>
<table><tr><td>B.3</td><td>Architecture finale de l'application, comprenant le frontend, le backend, et le service externe.</td><td>275</td></tr></table>
# Bibliographie

## Livres

[1] BROCA, Sébastien, *Utopie du logiciel libre : du bricolage informatique à la réinvention sociale*, Le passager clandestin, 2013, 288 p., ISBN : 978-2-916952-95-6, URL : http://lepassagerclandestin.fr/catalogue/essais/utopie-du-logiciel-libre.html.

[2] CARON, Christophe, * Droit d'auteur et droits voisins*, 5e éd., Paris : LexisNeis, 2017, ISBN : 978-2-7110-2845-0, URL : https://www.lgdj.fr/droit-d-auteur-et-droits-voisins-9782711028450.html (visité le 05/02/2018).

[3] ÉLIE, François, *Économie du logiciel libre*, Paris : Eyrolles, 2009, ISBN : 978-2-212-12463-7.

[4] MACLEAN, Fraser, *Setting the Scene : The Art & Evolution of Animation Layout*, Chronicle Books, 16 nov. 2011, 270 p., ISBN : 978-0-8118-6987-4, Google Books : AoajuAAACAAJ.

[5] MASSON, Terrence, *CG 101 : A Computer Graphics Industry Reference*, Indianapolis, Ind : New Riders, 1999, 500 p., ISBN : 978-0-7357-0046-8.

[6] PERLINE et NOISETTE, Thierry, *La bataille du logiciel libre : dix clés pour comprendre*, Paris : La Découverte, 2006, ISBN : 978-2-7071-4880-3.

[7] RAYMOND, Eric S., *The Cathedral & the Bazaar : Musings on Linux and Open Source by an Accidental Revolutionary*, 1st ed, Beijing : Cambridge, Mass : O'Reilly,
1999, 268 p., ISBN : 978-1-56592-724-7, URL : http://www.catb.org/~esr/writings/cathedral-bazaar/.

[8] STALLMAN, Richard M., WILLIAMS, Sam et MASUTTI, Christophe, *Richard Stallman et la révolution du logiciel libre : une biographie autorisée*, Eyrolles, 14 jan. 2010, 345 p., ISBN : 978-2-212-12609-9, Google Books : F1En17x8j0YC.

## Articles

[9] BROCA, Sébastien et CORIAT, Benjamin, « Le logiciel libre et les communs », in : *Revue internationale de droit économique* t. XXIX.3 (27 nov. 2015), p. 265-284, ISSN : 1010-8831, URL : https://www.cairn.info/revue-internationale-de-droit-economique-2015-3-page-265.htm (visité le 27/08/2019).

[10] CHAPMAN, Owen B. et SAWCHUK, Kim, « Research-Creation : Intervention, Analysis and “Family Resemblances” », in : *Canadian Journal of Communication* 37.1 (13 avr. 2012), ISSN : 1499-6642, DOI : 10.22230/cjc.2012v37n1a2489, URL : https://www.cjc-online.ca/index.php/journal/article/view/2489 (visité le 25/01/2019).

[11] CIANCARINI, Paolo, RUSSO, Daniel, SILLITTI, Alberto et SUCCI, Giancarlo, « Reverse Engineering : A European IPR Perspective », in : *Proceedings of the 31st Annual ACM Symposium on Applied Computing - SAC ’16*, The 31st Annual ACM Symposium, Pisa, Italy : ACM Press, 2016, p. 1498-1503, ISBN : 978-1-4503-3739-7, DOI : 10.1145/2851613.2851790, URL : http://dl.acm.org/citation.cfm?doid=2851613.2851790 (visité le 06/08/2019).

[12] GEORGE-MOLLAND, Anne-Laure, PLESSIET, Cédric, PÊCHEUX, Étienne et VIDAL, Dominique, « Le métier de technical director, hybridation entre expertise technique et création artistique au sein des pipelines d'effets spéciaux numériques », in : La Création Collective au Cinéma, 24 nov. 2017, URL : https://creationcollectiveaucinema.com/revue-n02-2019/.
[13] JULLIEN, Nicolas et ZIMMERMANN, Jean-Benoît, « Le logiciel libre : une nouvelle approche de la propriété intellectuelle », in : *Revue d'économie industrielle* 99.1 (2002), p. 159-178, DOI : 10.3406/rei.2002.3021, URL : https://www.persee.fr/doc/rei_0154-3229_2002_num_99_1_3021 (visité le 29/01/2019).

[14] KAINZ, Florian, BOGART, Rod, STANCZYK, Piotr et HILLMAN, Peter, « Technical Introduction to OpenEXR », in : (), p. 21.

[15] LUXEN, Dennis et VETTER, Christian, « Real-Time Routing with OpenStreetMap Data », in : ACM Press, 2011, p. 513, ISBN : 978-1-4503-1031-4, DOI : 10.1145/2093973.2094062, URL : http://dl.acm.org/citation.cfm?doid=2093973.2094062 (visité le 27/05/2018).

[16] RUPNIK, Ewelina, DAAKIR, Mehdi et PIERROT DESEILLIGNY, Marc, « MicMac – a Free, Open-Source Solution for Photogrammetry », in : *Open Geospatial Data, Software and Standards* 2.1 (5 juin 2017), p. 14, ISSN : 2363-7501, DOI : 10.1186/s40965-017-0027-2, URL : https://doi.org/10.1186/s40965-017-0027-2 (visité le 05/09/2019).

[17] TION, Guillaume, « Effets spéciaux : Pierre Buffin, la grande illusion », in : *Li-bération* (21 avr. 2017), URL : https://next.liberation.fr/images/2017/04/21/effets-speciaux-pierre-buffin-la-grande-illusion_1564388 (visité le 21/06/2019).

## Thèses et mémoires

[18] GEORGE-MOLLAND, Anne-Laure, « La collaboration au cœur du processus de création des œuvres audiovisuelles numériques : analyse des transformations apportées par le développement des technologies et par l'évolution des savoir-faire. », Paris 8, 12 déc. 2007, 368 p.
[19] LELIÈVRE, Pierre, *Définition du rôle de TD, Technical Director, au sein des studios de fabrication d'images numériques*, Saint-Denis : ENS Louis Lumière, juin 2012, p. 191, URL : https://www.ens-louis-lumiere.fr/index.php/definition-du-role-de-td-technical-director-au-sein-des-studios-de-fabrication-dimages-numeriques.

[20] PEREZ, Flavio, *Le pipeline de l'image de synthèse : définitions et enjeux pour les œuvres collaboratives*, Mémoire de master, Saint-Denis : Université Paris 8, 2017.

Conférences

[21] JON MANNING, « Making Night in the Woods Better with Open Source » (Game Developers Conference, San Francisco, Californie, USA), 2017, URL : https://youtu.be/Qsiu-zzDYww (visité le 29/04/2019).

[22] MULLER, Mathieu et LE LEVIER, Bruno, « Actualité du temps réel », Rencontres Animation Développement Innovation (Pôle Image Magelis, Angoulême, France), 18 nov. 2016, URL : https://www.rencontres-animation-formation.org/synthese_2016.

[23] ROOSENDAAL, Ton, « Blender Foundation – Community Meeting », Siggraph (Anaheim, Californie, États-Unis d'Amérique), 2013, URL : https://www.blender.org/bf/sig2013.pdf.

[24] SEGUIN, Maxime, « La 3D au service de la connaissance », Rencontres d'archéologie de la Narbonnaise (Salle des Synodes, Narbonne), 29 sept. 2017, URL : http://www.prehistoire.org/offres/gestion/actus_all_515_31942-1/la-3d-au-service-de-la-connaissance.html.
Pages web

[25] ADOBE SYSTEMS INCORPORATED, *Changes to Creative Cloud Download Availability*, 2018, URL: https://theblog.adobe.com/changes-to-creative-cloud-download-availability (visité le 11/07/2019).

[26] ADOBE SYSTEMS INCORPORATED, *Conditions d'utilisation pour les produits et services Adobe*, avr. 2020, URL: https://www.adobe.com/fr/legal/terms.html (visité le 14/07/2020).

[27] AUTODESK, *Conditions Générales d'Utilisation*, 18 mai 2018, URL: https://www.autodesk.com/company/terms-of-use/fr/general-terms#software (visité le 01/09/2019).

[28] BLENDER FOUNDATION, FAQ, URL: https://www.blender.org/support/faq/ (visité le 12/03/2019).

[29] CHRISTOPHE ARCHAMBAULT, *Asset Managers*, 13 nov. 2018, URL: http://lepipeline.org/asset-managers (visité le 23/09/2019).

[30] DOMBROVA, Chad, *Why PyMEL?*, 2009, URL: https://download.autodesk.com/us/maya/2011help/PyMel/why_pymel.html (visité le 15/03/2019).

[31] ELECTRONIC FRONTIER FOUNDATION, *Coders' Rights Project Reverse Engineering FAQ*, 6 août 2008, URL: https://www.eff.org/issues/coders/reverse-engineering-faq (visité le 06/08/2019).

[32] EPIC GAMES, INC., *EULA*, URL: https://www.unrealengine.com/en-US/eula (visité le 18/07/2019).

[33] FREE SOFTWARE FOUNDATION, INC., *What Is Free Software and Why Is It so Important for Society?*, URL: https://www.fsf.org/about/what-is-free-software (visité le 28/01/2019).

[34] NATIONAL SNOW AND ICE DATA CENTER, *Use and Copyright*, URL: https://nsidc.org/about/useCopyright.html (visité le 21/05/2019).
[35] POPE, Lucas, *Return of the Obra Dinn*, 14 août 2014, URL : https://forums.tigsource.com/index.php?topic=40832.msg1051550#msg1051550 (visité le 17/07/2019).

[36] ROUSSEAU, Frank, *TNZPV Studio Sponsors January Features for Kitsu*, 7 jan. 2019, URL : https://medium.com/cgwire/tnzpv-studio-sponsors-january-features-for-kitsu-301405ed23e1 (visité le 21/07/2019).

[37] STALLMAN, Richard, *Why Open Source Misses the Point of Free Software*, 2007-2019, URL : https://www.gnu.org/philosophy/open-source-misses-the-point.html (visité le 09/08/2019).

[38] *Tone.Js*, URL : https://tonejs.github.io/ (visité le 27/05/2018).

[39] VISUAL EFFECTS SOCIETY TECHNOLOGY COMMITTEE, *VFX Reference Platform*, 2014-2019, URL : https://vfxplatform.com/ (visité le 27/09/2019).

## Données

[40] RIGNOT, Eric, MOuginot, Jeremie et SCHEUCHL, Bernd, *MEaSUREs InSAR-Based Antarctica Ice Velocity Map, Version 2*, 2017, DOI : 10.5067/d7gk8f5j8m8r, URL : https://nsidc.org/data/nsidc-0484/versions/2 (visité le 21/05/2019).

## Films et vidéos

[41] KOSTIS, Helen-Nicole, *Pulse of Snow and Sea Ice*, avec la coll. de STARR, Cindy et MARKUS, Thorsten, 2012, URL : https://svs.gsfc.nasa.gov/3944 (visité le 05/09/2019).

[42] VESELIN EFREMOV, *Adam*, 2016, URL : https://unity3d.com/pages/adam (visité le 01/09/2019).
Logiciels, scripts, plug-ins

[43] COUREAU, Damien, *Kabaret Studio*, 2012, URL : https://www.kabaretstudio.com (visité le 20/09/2019).

[44] ESAU, Andreas, *Cutout Animation Tools*, version 1.0.4, 2015-2018, URL : https://github.com/ndee85/coa_tools (visité le 17/04/2019).

[45] FORMAN, Charles, *Storyboarder*, version 1.13.0, Wonder Unit Inc., 2016, URL : https://wonderunit.com/storyboarder/ (visité le 30/08/2019).

[46] HARVEY, Geoff, *Hoafaloaf/Seqparse*, 2017, URL : https://github.com/hoafaloaf/seqparse (visité le 26/03/2020).

[47] HOLOWKA, Alexander, *YarnSpinnerTool/YarnSpinner*, Secret Lab, 2015, URL : https://github.com/YarnSpinnerTool/YarnSpinner (visité le 22/10/2019).

[48] ISRAEL, Justin, *Justinfx/Fileseq*, 2012, URL : https://github.com/justinfx/fileseq (visité le 26/03/2020).

[49] MAPBOX, *TileMill*, 2010-2019, URL : https://tilemill-project.github.io/tilemill/ (visité le 27/05/2018).

[50] OLIVE TEAM, *Olive-Editor/Olive*, Olive Team, 2018, URL : https://github.com/olive-editor/olive (visité le 18/03/2020).

[51] *Openexr/Openexr*, OpenEXR, 2003, URL : https://github.com/openexr/openexr (visité le 25/10/2019).

[52] PEREZ, Flavio, *Storymatic*, Les Fées Spéciales, 2016, URL : https://github.com/LesFeesSpeciales/storymatic (visité le 18/10/2019).

[53] ROUSSEAU, Frank, *CGWire*, 2017, URL : https://www.cg-wire.com/ (visité le 20/09/2019).

[54] *Substance*, Adobe, URL : https://www.substance3d.com/ (visité le 09/03/2020).

[55] Van NIEUWENHUIZEN, Jasper, *2d Animation Tools*, 2014-2017, URL : https://github.com/jasperges/2dTools (visité le 04/03/2019).
[56] WHITAKER, Jeffrey, *Pyproj4/Pyproj*, pyproj4, 2013, URL : https://github.com/pyproj4/pyproj (visité le 05/09/2019).

[57] YAMAGUCHI, Kota, *Psd-Tools*, psd-tools, 2012, URL : https://github.com/psd-tools/psd-tools (visité le 20/02/2020).

[58] YATES, Charles et DENNEDY, Dan, *MLT*, MLT Framework, 2003, URL : https://github.com/mltframework/mlt (visité le 21/02/2020).

Divers

[59] ADOBE SYSTEMS INCORPORATED et KNOLL, Thomas, *Adobe Photoshop File Formats Specification*, 1990-2016, URL : https://www.adobe.com/devnet-apps/photoshop/fileformatashtml/ (visité le 04/03/2019).

[60] ALEXANDRE PROKOUDINE, *The Demise of Natron : How We Got Here and Where We Go Further*, avec la coll. d'ALEXANDRE GAUTHIER-FOICHAT et FRÉDÉRIC DEVERNAY, 25 nov. 2018, URL : http://libregraphicsworld.org/blog/entry/the-demise-of-natron (visité le 23/08/2019).

[61] APRIL, Association, *Livre Blanc Sur Les Modèles Économiques Du Logiciel Libre*, déc. 2007, URL : http://www.april.org/livre-blanc-sur-les-modeles-economiques-du-logiciel-libre (visité le 03/10/2017).

[62] CENTRE NATIONAL DE LA CINÉMATOGRAPHIE, *Soutien financier aux industries techniques du cinéma, de l'audiovisuel des autres arts et industries de l'image animée — Présentation générale*, 2019, URL : https://www.cnc.fr/documents/36995/159604/pr%C3%A9sentation+du+Soutien+financier+aux+industries+techniques.pdf/1b3f18fa-a53f-5cdc-866b-230fbed6ebfd.

[63] CREATIVE COMMONS, *Creative Commons — CC0 1.0 Universel*, 2009, URL : https://creativecommons.org/publicdomain/zero/1.0/deed.fr (visité le 05/09/2019).
[64] FREE SOFTWARE FOUNDATION, INC., *GNU General Public License, Version 2*, 1991, URL: https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
(visité le 19/02/2019).

[65] HUGHES, Kerrie, *Autodesk Answers Your Questions on the Demise of Softimage*, avec la coll. de PATEL, Maurice, 20 avr. 2014, URL: https://www.creativebloq.com/3d/autodesk-answers-your-questions-demise-softimage-31411069
(visité le 26/08/2019).

[66] JOHN HARVEY, *Blank Map World Equirectangular*, avec la coll. de CANUCKGUY et CENTRAL INTELLIGENCE AGENCY, 2008, URL: https://en.wikipedia.org/wiki/File:BlankMap-World6-Equirectangular.svg (visité le 05/09/2019).

[67] KYU LAB, *Étude sur l'identification des besoins en competences et en formation des studios*, juin 2018, URL: http://www.cpnef-av.fr/les-etudes/films-d-animation-quels-besoins-en-competences- (visité le 22/07/2019).

[68] LOI n° 2014-856 du 31 juillet 2014 relative à l'économie sociale et solidaire, 31 juil. 2014, URL: https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000029313296 (visité le 26/07/2019).

[69] MPEG LA, *MPEG LA's AVC License Will Not Charge Royalties for Internet Video That Is Free to End Users through Life of License*, 26 août 2010, URL: http://www.mpegla.com/Lists/MPEG%20LA%20News%20List/Attachments/74/n-10-08-26.pdf.

[70] SAM HOCEVAR, *What The Fuck Public License*, URL: http://www.wtfpl.net/about/ (visité le 01/09/2019).
# Annexe A

## Exemple de fichier JSON pour les exports de *Dilili à Paris*

```json
{
  "files": [
    {
      "use textures": true,
      "group": "PANTIN",
      "fbx": "PANTIN.fbx",
      "visibility": {}
    },
    {
      "use textures": false,
      "group": "RLO",
      "fbx": "RLO.fbx",
      "cache": "RLO.pc2"
    },
    {
      "use textures": false,
      "group": "DECOR_REF",
      "fbx": "DECOR_REF.fbx",
      "visibility": {}
    },
  ]
}
```
```json
{
    "use textures": true,
    "group": "DECOR_RND",
    "fbx": "DECOR_RND.fbx",
    "visibility": {}
},
{
    "use textures": true,
    "group": "CAMERA",
    "fbx": "camera.fbx",
    ".focalLength": {}
}
],
"sounds": [
    {
        "start_frame": 1,
        "file": "DIL_S12_P0041_son-maquette_v1.wav"
    }
],
"settings": {
    "frame_start": 101,
    "resolution_x": 2048,
    "frame_end": 172,
    "resolution_y": 1080
}
}
```
# Annexe B

## Autonomisation des artistes : Music Road

*Music Road* est un projet personnel conçu pour explorer des questions liées au logiciel libre mais, s'éloignant du cinéma d'animation, faire une incursion dans le monde du web. Plus précisément, je cherchais à déterminer dans quelle mesure une œuvre créée par un seul artiste pouvait s'appuyer sur du code et des données open source. Il n'a pas été réalisé dans le cadre de l'entreprise, et ne répond donc pas du tout aux mêmes contraintes industrielles de production. Il n'explore pas les relations entre studios et développeurs de logiciels libres, ni l'élaboration d'un pipeline* complexe, mais plutôt la carte en tant que médium* artistique, un mode de représentation qui m'intéresse par le rapprochement qu'il fait entre l'art et la science.

### Principe du projet

Le projet *MusicRoad* (figure B.1) consiste en une application dont le fonctionnement est le suivant : une carte permet de calculer un itinéraire, à la façon des services comme Mappy et Google Maps, en plaçant des points (marqueurs) sur la carte. En plus de calculer et d'afficher l'itinéraire, le programme propose également une mélodie, calculée à partir des mêmes données. On obtient ainsi, pour chaque ensemble de points de départ, d'arrivée, et d'escales, une mélodie unique associée à un trajet.
<figure><img src="image_35.png" /><figcaption>FIGURE B.1 – Accueil du site web, interface de l’application.</figcaption></figure>

Pour générer une mélodie, l'idée initiale était de transposer l'itinéraire de la manière suivante, choisie en partie arbitrairement, mais selon une logique déterministe<fnref n="1" /> fondée sur la musique et le sens de lecture occidentaux :

— Chaque instruction (changement de direction) correspond à un changement de note.

— Les virages à gauche signifient une note plus grave.

— Les virages à droite signifient une note plus aiguë.

— Les virages serrés signifient une note plus éloignée de la précédente que les plus faibles inflexions de direction.

— La durée d'une note est fonction de la distance parcourue entre deux instructions.

Cette version de l'algorithmes de génération musicale a été complexifiée au cours de l'implémentation, afin d'apporter de la variété, mais en respectant le principe fondamen-

<footnote n="1">1. En d'autres termes, le hasard n'intervient pas dans la génération. Un seul trajet et une seule mélodie sont calculées d'après les données en entrée.</footnote>
tal qu’un itinéraire donné doit correspondre à une et une seule mélodie. L’inverse n’est pas vrai : une même mélodie peut être jouée sur plusieurs trajets différents.

Une première itération de ce programme, conçue avant le début de ma thèse, faisait appel à l’API de Google Maps. En envoyant une requête comprenant les coordonnées ( latitude, longitude) des différents points constituant l’itinéraire, on obtenait un document contenant les instructions du trajet. Il était facile de faire une analyse syntaxique de ce document ( parsing ) pour générer la mélodie. Des méthodes étaient également fournis pour intégrer une carte Google Maps dans une page web, ainsi que l’itinéraire. Cependant, les indications retournées par la requête étaient insuffisamment détaillées à l’époque (en 2014, je n’ai pas réessayé depuis) pour permettre de calculer une mélodie.

Quelques années plus tard, au cours de ma thèse et de mon activité profession-
nelle, j’ai été amené à élaborer des cartes animées pour des films et des musées (cf.
sections III.1.2 et III.1.3). J’ai donc pris connaissance de certains éléments de l’écosys-
tème d’outils et de bases de données cartographiques, en particulier libres.

La démarche de ce travail est de se servir le plus possible de ressources open source.
Un autre critère était initialement de ne s’appuyer sur aucun service en ligne (logiciel en
tant que service, *Software As A Service*)<fnref n="2" />, pour trois raisons : garantir la disponibilité du
programme sans dépendre de celle des services utilisés et, dans l’hypothèse de données
confidentielles, l’accès aux données et le contrôle de ces données ; pouvoir offrir le service
hors ligne, dans le cadre d’une installation artistique in situ par exemple ; avoir une plus
grande liberté dans le rendu des éléments graphiques, en pouvant modifier le code, les
images et les données.

L'application finale est disponible sur Internet, sur mon site personnel <fnref n="3" />.

<footnote n="2">2. Les *Software As A Service* sont un type d'infrastructure *cloud* où un logiciel est exécuté sur un serveur distant, et non pas sur la machine de l'utilisateur. C'est le cas de tous les sites proposant des fonctionnalités requérant du calcul ou des données en ligne. C'est le cas également pour ce projet, lorsqu'il est utilisé depuis le site web, et non pas chez l'utilisateur, comme c'était l'intention de départ.</footnote>

<footnote n="3">3. Le site est disponible à l'adresse suivante : https://swagosaure.com/music_road/</footnote>
## Processus créatif

La conception du projet *Music Road* a consisté à utiliser des bibliothèques*, des composants logiciels publiés sous licences libres, ainsi que des données ouvertes, afin de créer une œuvre originale. Il a été l'occasion d'une recherche sur ce qui caractérise l'utilisation de bibliothèques libres pour la création. Cette section développera le processus de développement de l'application, et examinera les intérêts pour l'artiste, ainsi que les difficultés qui existent à appréhender un vaste écosystème de composants logiciels. Cette application développée pour le web se détache quelque peu des outils utilisés ordinairement dans l'animation, mais le processus de développement est similaire, dans la mesure où des composants logiciels existants peuvent être utilisés pour développer des outils pour l'animation (voir l'exemple de pyproj dans la section III.6.1). Les étapes de conception (cahier des charges, veille, prototypage, implémentation), sont aussi sensiblement les mêmes que celles qui sont décrites ici. L'approche est aussi différente et complémentaire, car si je connais assez bien le développement d'add-ons* et de scripts* pour l'animation 3D, le web était à l'époque un domaine que j'abordais tout juste. Les enseignements que je tire de cette expérience d'apprentissage peuvent être transposés au développement pour l'animation.

## B.1 Cahier des charges

Une fois définies l'idée globale et les mécanismes de l'application (cf. annexe B), la première étape de ce projet a été de déterminer de quels composants logiciels j'aurais besoin pour la construire. En voici une liste issue des premières réflexions.

- jeu de données cartographiques,

- bibliothèque d'affichage de ces données dans le navigateur, générateur de tuiles;

- programme ou bibliothèque de calcul d'itinéraire,

- bibliothèque client d'affichage d'itinéraire compatible;

- framework* JavaScript, environnement de développement;
— bibliothèque de synthèse sonore (serveur ou client);

La première phase de recherche m'a conduit à l'idée fausse qu'il serait facile de trouver des implémentations libres de ces composants, puisqu'il en existait un grand nombre sous licence libre répondant à ces besoins. Pour mener à bien ce projet, j'ai évalué les composants suivants : Node.js, OpenStreetMap, Leaflet, Mapnik, Tilemill, OSRM, Leaflet Routing Machine, Flocking, Tone.js, timbre.js. Chacun de ces composants est plus ou moins bien documenté, et facile à installer, paramétrer, utiliser, modifier et étendre. J'en détaillerai certains plus loin, mais cette énumération suffit à se rendre compte que l'abondance d'applications dans l'écosystème de développement web constitue en soi un obstacle à la conception d'une application par un artiste développeur. C'est bien sûr vrai de tout travail de création, mais ici la complexité est d'autant plus accablante qu'elle part en tous sens, et que chaque nouveau problème a de nombreuses solutions existantes possibles à explorer et valider 4.

Le composant essentiel, qui permet à ce projet d'exister, est la base de données OpenStreetMap (cf. section I.2.4.2). L'intérêt de cette base de données pour une application comme celle-ci est que les données peuvent être téléchargées, utilisées comme matériau de base de création, mélangées avec des données originales, et remixées. Le téléchargement de la base de données complète est simple, mais une contrainte à considérer est son poids, d'environ 800 Go<fnref n="5" /> en 2017. Ne disposant pas de quoi stocker et traiter cette quantité de données, j'ai choisi de me concentrer sur un extrait de l'ancienne région où je réside, le Languedoc-Roussillon, qui est facilement téléchargeable 6.

<footnote n="4">4. Cette problématique est directement applicable au développement d'outils pour l'animation. Par exemple, l'équipe technique des Fées spéciales a eu besoin à un moment de traiter des séquence d'images, et donc d'analyser les images présentes dans un dossier, trouver le nombre de chiffres de la séquence, et repérer les images manquantes. C'est un problème récurrent dans l'animation. Nous avons cherché des bibliothèques Python permettant de simplifier ce problème, et bien qu'elles soient assez mal référencées, nous en avons trouvé plusieurs [46, 48], aux fonctionnalités similaires mais aux interfaces différentes. Suite à une phase de test, le choix entre ces bibliothèques a été plus ou moins arbitraire.</footnote>

<footnote n="5">5. Ce chiffre est donné pour un extrait mondial de la base de données, c'est-à-dire toutes les données à un instant donné. Le poids de la base entière, comprenant tout l'historique du projet, n'est pas directement disponible, et je ne peux pas la récupérer pour la peser, mais il est certain que c'est plus du double. La page https://wiki.openstreetmap.org/w/index.php?title=Planet.osm donne régulièrement le poids à jour de la base.</footnote>

<footnote n="6">6. La page https://wiki.openstreetmap.org/wiki/Planet.osm#Country_and_area_extracts explique où télécharger des extraits de zones internationales, nationales, ou régionales.</footnote>
## B.2 Rendu graphique de la carte

Les sites proposant des cartes en ligne reposent sur de lourdes bases de données géographiques, comprenant des données dans l'espace (points représentant des coordonnées terrestres, lignes reliant ces points, polygones délimitant des zones), et des métadonnées associées à ces primitives géométriques, définissant les caractéristiques des objets décrits. Par exemple, les routes sont constituées de lignes, auxquelles on associe des informations telles que le type (de l'impasse piétonne à l'autoroute), le nom, les sens uniques, les limitations de vitesse, etc. De la même manière, on peut décrire géographiquement les infrastructures, les bâtiments, les étendues d'eau, les paysages, etc. Ces bases de données SIG (Système d'Information Géographique) forment la partie des données qui est invisible pour l'utilisateur. Car avant d'être servies sur la page web, ces données sont rendues en images appelées tuiles (tiles). Ces images sont ainsi nommées car la surface de la carte est découpée en petites parties, qui une fois juxtaposées, permettent d'afficher la carte. L'avantage est que l'utilisateur n'a pas besoin de charger l'intégralité de la carte, qui pèserait bien trop lourd pour être transférée et affichée en une fois.

Mon intention initiale était d'utiliser les données téléchargées (la région Languedoc-Roussillon) dans deux buts différents : rendre les tuiles de la carte, et calculer l'itinéraire. Pour le premier problème des tuiles, j'ai commencé par installer les composants logiciels recommandés sur le wiki d'OpenStreetMap<fnref n="7" /> pour un serveur complet, à savoir un serveur web (Apache), un moteur de base de données (PostgreSQL), dans lequel la base téléchargée précédemment est importée. Une extension du serveur web Apache (mod_tile) permet la gestion des tuiles : lors d'une requête de tuile, un cache est consulté pour savoir si la tuile existe et est suffisamment récente. Dans le cas contraire, elle est rendue, stockée, et servie à l'utilisateur. Le rendu se fait d'après un système complexe de feuilles de style. Je ne décrirai pas ce système en détail ici, car la création de ces feuilles de style est un sujet à part entière. En effet, de nombreux systèmes existent, pas nécessairement compatibles. Cependant, je suis parvenu à installer et utiliser un autre programme de

<footnote n="7">7. Des explications sont disponibles ici : https://wiki.openstreetmap.org/wiki/Deploying_your_owned_Slippy_Map</footnote>
création de styles de carte, Tilemill [49], qui permet de faire des sélections dans un langage proche du CSS<fnref n="8" />.

Si passionnants que soient les métiers de designer et de cartographe, j'ai finalement renoncé à la création d'un design nouveau pour ce site, en raison du temps limité dont je dispose, et de la difficulté de maîtriser les outils, tant pour le façonnage que pour le rendu. Sachant, d'une part, qu'après plusieurs jours infructueux, le serveur de rendu de tuiles ne marchait pas, et que le style auquel j'étais parvenu était au mieux un rudimentaire essai d'amélioration par rapport aux styles d'exemple, et d'autre part que les tuiles d'OpenStreetMap.org peuvent être utilisées par d'autres sites, j'ai décidé de faire cette concession, et de faire pointer mon serveur web directement sur celui des tuiles d'OSM. Cela constitue une entorse aux contraintes initiales, puisque cela implique que des données venant d'un serveur externe seront utilisées par le programme. En cas d'indisponibilité du serveur, mon site le sera également. La même chose se produit si un changement de format ou d'API rend incompatibles les solutions mises en œuvre. On peut également considérer le cas où OpenStreetMap déciderait de changer le style ou le rendu de ses cartes : MusicRoad changerait en conséquence sans que j'en aie fait le choix, peut-être même sans que je le sache. Ce ne serait pas dramatique et n'affecterait pas nécessairement l'expérience de l'utilisateur, mais dans la mesure où je n'aurais pas de contrôle dessus, pourrait-on encore dire que j'en serais l'auteur, même en tenant compte du fait que mon œuvre est dérivée d'une autre ? Cela étant, cela illustre bien la difficulté à l'heure actuelle de faire du développement de services web en se passant des SaaS (Software as a Service), malgré l'existence du logiciel libre. C'est aussi une contrainte pour l'artiste, qui perd en contrôle ce qu'il gagne en facilité de mise en œuvre.

## B.3 Itinéraire

<footnote n="8">8. Langage de mise en forme pour le web. Il permet de définir les caractéristiques de forme de chaque élément : textes, tableaux, images, divisions de la page, etc., indépendamment du contenu. Pour les cartes, les éléments sont les points, lignes, surfaces, noms et attributs, et ils peuvent être coloriés ou hachurés, représentés par des idéogrammes, les textes placés et mis en forme, etc.</footnote>
<figure><img src="image_36.png" /><figcaption>FIGURE B.2 – La partie backend est complète, mais la carte ne s'affiche pas encore.</figcaption></figure>

L'étape suivante fut la recherche des programmes et bibliothèques permettant le calcul de l'itinéraire et l'affichage de la page web. En ce qui concerne le premier point, plusieurs programmes capables de traiter les données OpenStreetMap pour générer un itinéraire existent. J'ai choisi OSRM (Open Source Routing Machine) [15]. La raison initiale en était la page de démonstration très convaincante, et le fait que ce programme soit utilisé sur le site officiel d'OpenStreetMap, ce qui laissait à présager de sa robustesse. De plus, un exemple de frontend (page web connectée au serveur de calcul d'itinéraire) était donné dans les dépôts. Notons que ce choix est encore une fois assez arbitraire, car le wiki d'OSM liste une dizaine de programmes écrits dans six langages différents. Comment choisir, lorsque le temps et les connaissances manquent, et qu'aucune autorité ne peut donner de conseils ? La veille est bien sûr une part essentielle du travail de recherche, mais dans un cas comme celui-ci, où l'investissement est lourd par rapport à la finalité (à savoir, mélanger des technologies existantes pour créer un programme finalement simple), il faut parfois se résoudre à s'en tenir à la première impression, ou à faire confiance à ce que disent des inconnus sur des forums ou des wikis. Le serveur ne fut pas difficile à compiler en suivant les instructions. OSRM traite ensuite les données géographiques extraites de la base de données OSM, pour créer un fichier dédié spécifiquement au calcul d'itinéraire.

J'ai dit qu'OSRM était un serveur. Cela signifie que pour obtenir les informations d'itinéraire, il faut faire une requête HTTP sur un port spécifique, dans un format donné. C'est ce qu'il se passe lorsqu'on consulte n'importe quel site web. Il faut par ailleurs un autre serveur HTTP, le serveur web communiquant avec l'extérieur, qui sera chargé d'envoyer les pages web lorsque l'utilisateur se connectera via son navigateur. Il faut
donc que le serveur web puisse recevoir une requête d'itinéraire depuis la page web, la transmette localement au serveur OSRM, puis transmette la réponse dans l'autre sens. On le voit dans la figure B.2, où le serveur Apache envoie la page au frontend, chez le client.

<figure><img src="image_37.png" /><figcaption>FIGURE B.3 – Architecture finale de l’application, comprenant le frontend, le backend, et le service externe.</figcaption></figure>

La partie *backend* de cette application est simple : elle se contente de servir une page statique comprenant un formatage HTML simple, le code client JavaScript, et la gestion de la requête d'itinéraire expliquée plus haut. Pour cela, lorsqu'une requête HTTP comprenant les options propres à OSRM lui parvient, le serveur fait une nouvelle requête locale, et retourne, sans y toucher, le résultat de cette requête. Cela permet que toutes les requêtes (page et itinéraires) passent par le même serveur Apache, qui se charge d'en détecter le type et de faire la bonne action en conséquence : servir directement les fichiers web, ou faire la requête au serveur OSRM. Dans la figure B.2, on voit que le
serveur web est en mesure de communiquer avec la page, et d'envoyer des requêtes au serveur d'itinéraire, mais il n'a nulle part où les envoyer, parce que le composant chargé d'afficher la carte n'est pas encore intégré.

Le frontend, partie du code écrite en JavaScript et exécutée dans le navigateur chez le client, utilise quant à lui plusieurs bibliothèques de cartographie web (figure B.3) : Leaflet, qui s'occupe du rendu de cartes glissantes à la manière de Google Maps, et Leaflet Routing Machine, chargée de l'itinéraire. Cette dernière bibliothèque permet de créer sur la carte des points d'itinéraire, de départ, d'arrivée, et éventuellement d'étapes ; c'est aussi elle qui fait la requête au serveur d'itinéraire via le serveur web, et qui affiche, d'une part, l'itinéraire sous forme d'instructions, et d'autre part la ligne décrivant cet itinéraire, directement sur la carte. C'est enfin elle qui sera chargée d'appeler une autre bibliothèque, qui générera la musique.

## B.4 Procédure de génération musicale

Jusqu'ici, j'ai décrit la méthode que j'ai suivie pour intégrer des données cartographiques existantes dans une page web simple, en me servant autant que possible de données et de programmes locaux. Je parlerai maintenant de ce qui fait la particularité de cette application : la génération de musique à partir de données affichées en temps réel. Ici encore, j'ai été confronté au même problème : il existe une multitude de solutions, plus ou moins complexes. La plus évidente, et la plus difficile, est de faire appel directement à l'API audio du web, en cours de standardisation, et présente sur tous les navigateurs modernes. Les appels à cette API permettent la synthèse sonore à partir d'oscillateurs ou de tampons (buffers), et de filtres simples, interconnectés à la façon d'un synthétiseur modulaire. Si cette approche est très puissante pour la manipulation audio, elle est de relativement bas niveau et ne comprend aucune structure de données ou procédure pour faciliter la génération musicale. Il existe des frameworks* intégrant ces possibilités. Comme dans les autres cas de figure, cela implique de chercher une solution appropriée parmi de nombreux candidats plus ou moins aboutis, aux fonctionnalités se
recoupant parfois. J'ai choisi Tone.js [38] après avoir lu les présentations de cinq frameworks différents. Ce dernier est conçu pour la création musicale interactive. À l'inverse d'autres frameworks, il n'intègre pas d'éléments d'interface utilisateur, mais permet de prototyper rapidement un instrument virtuel, et d'en jouer les notes, soit lors d'événements, soit à l'aide de motifs déclarés préalablement. Tone.js comprend également un système permettant de synchroniser de l'animation graphique avec le son. C'est cette dernière fonction qui m'a fait choisir cette bibliothèque, sachant que j'en aurais besoin pour animer la carte. L'intégration a ensuite été assez aisée : à chaque fois que l'utilisateur déplace des marqueurs sur la carte, un nouvel itinéraire est demandé. Lorsqu'il arrive, il est affiché immédiatement par Leaflet, et passe en parallèle vers Tone.js. Ce dernier, d'après les règles de composition choisies, synthétise la mélodie en réagissant au mouvement du point le long de la ligne de l'itinéraire.

Une fois validée la possibilité de jouer du son, je me suis attelé à l'élaboration de l'instrument virtuel. Dans Tone.js, un instrument est décrit en déclarant un objet de type **Synth** (synthétiseur) avec un ensemble de paramètres. Par exemple, l'instrument que j'utilise pour *MusicRoad* consiste en deux oscillateurs, un sinusoïdal et un triangulaire ; ce dernier passe dans une enveloppe ADSR (Attack, Delay, Sustain, Release), et dans un filtre passe-bas. Cette combinaison donne une sorte de gentil piano à l'attaque rapide, sous lequel on peut entendre la note à l'octave inférieure pour plus de profondeur. Cet instrument, à vrai dire, ressemble plutôt à un piano-jouet qu'à un piano de concert, mais le critère premier était surtout de ne pas avoir les oreilles détruites pendant le développement de l'application.

Une fois encore, ce processus m'a confronté à un problème : le projet est celui d'un touche-à-tout, qui ne maîtrise pas tout ce qu'il touche. J'ai fait ce rapide exposé de synthèse audio, non afin d'expliciter chaque composant d'un synthétiseur numérique, mais dans le but d'illustrer que, quoique j'aie quelque connaissance dans ce domaine, cette connaissance s'est avérée insuffisante pour concevoir un instrument véritablement plaisant, ou adapté à son application, en un mot, *designé*.

J'envisage deux solutions possibles à ce problème : la première consisterait à consa-
crer le temps nécessaire à tout apprendre correctement. Ce n'est pas faisable en pratique,
le champ de la connaissance humaine étant plus vaste qu'une vie pourrait explorer. La
deuxième serait la collaboration. Quel modèle envisager pour une telle collaboration ?
Avec qui collaborer ? Rappelons que l'ambition initiale pour ce projet était de tout conce-
voir moi-même, dans ma tour d'ivoire. À ce stade du prototype fonctionnel, je n'ai pas
élucidé cette question. En ce qui concerne les modèles collaboratifs, il serait intéressant
de faire suffisamment connaître le projet pour créer une petite communauté de déve-
loppement sur un dépôt de code public. Elle pourrait utiliser à la fois des procédés et
des principes du logiciel libre, mais dans un but de création plutôt que de résolution de
problème.

## B.5 Conclusion

En décrivant en détail le processus de création<fnref n="9" /> du site web MusicRoad, j'ai cherché
à déterminer le rôle des outils et données libres en tant que facilitateurs de la création
artistique sur le web. De fait, ce projet simple (il consiste en seulement 380 lignes de
code, sans compter les différents composants externes, qui comptent des dizaines de
milliers de lignes de codes) a permis de valider l'hypothèse que l'existence et l'accès
à du code et à des données libres facilitent la création. Le projet a également mis en
lumière les difficultés que posent ces mêmes technologies. En effet, en raison de l'aspect
abondant et nébuleux de l'écosystème, plus de la moitié du temps a été consacrée à la
recherche de programmes et de données existantes, compatibles, et à leur intégration.
Les étapes de conception, fabrication, test, debug, ajustements, qui sont d'ordinaire les
plus importantes en art numérique, sont presque mineures en comparaison.

Cependant, malgré l'investissement non négligeable que représente la recherche de
solutions libres, une fois ces technologies connues et maîtrisées, le gain de temps com-
pense largement cet investissement, pour le reste du processus et pour d'éventuels projets
à venir. En effet, l'artiste se repose sur du code existant, éventuellement tenu à jour et

<footnote n="9">9. J'ai toutefois passé sous silences plusieurs étapes de sélection de bibliothèques.</footnote>
amélioré par une communauté de développeurs, ce qui peut lui offrir une plus grande efficacité, voire simplement lui permettre d'accomplir sa tâche. Sans l'existence de cette richesse de ressources, de code, de données et de documentation, je peux affirmer que je n'aurais pas pu mener à bien ce projet. D'abord, ce petit projet repose indirectement sur l'effort de milliers d'individus, en particulier en ce qui concerne l'élaboration de la base de données cartographiques (OpenStreetMap). Ensuite, contrairement aux nombreux auteurs des outils utilisés pour le projet, le développement web ne compte pas parmi mes compétences habituelles.

Mais aussi, l'investissement a ceci d'intéressant que la connaissance des standards, procédés et outils, permet de stimuler l'imagination, de faire des rapprochements entre des éléments disparates, de faire du neuf avec du vieux, en un mot de créer. Si le code est l'outil de l'artiste, et le concept son matériau, l'environnement lui pourrait servir d'inspiration. La puissance du logiciel libre et de ses communautés est bien illustrée par le fait que des applications à portée artistique ou expérimentale existent sur Internet, servant à leur tour d'inspiration à d'autres œuvres et outils faciles d'accès, réutilisables et détournables.

Le détournement est un aspect essentiel du projet. Les technologies évoquées ici sont dans la majorité des cas utilisées dans des applications purement cartographiques (localisation, guidage), pédagogiques ou commerciales. Dès lors, on peut parler de détournement puisque le but affiché de l'application est esthétique et ludique. L'utilisateur n'est pas dépaysé par les codes de représentation et d'interface, qui sont omniprésents. Il peut commencer immédiatement à jouer avec la carte, chercher des endroits intéressants musicalement, créer et partager ses trouvailles, ou ses compositions s'il adopte lui-même la démarche créative de placer plusieurs points de trajet, d'écouter, de modifier, et de recommencer.
# Annexe C

## Les pantins en dehors du studio :
Loqmane Bahri

Au cours de mon emploi aux Fées spéciales, j'ai rencontré un jeune réalisateur de film d'animation, Loqmane Bahri, qui était à l'époque en stage dans la société. En tant que membre de l'équipe de fabrication des pantins, il faisait de la colorisation, du détourage et du rig de personnages, et utilisait notamment le système d'autorig. Il a par la suite travaillé aux concepts sur d'autres projets. Après la fin de son stage, il a entrepris un nouveau film en utilisant entre autres certaines techniques apprises pendant son stage. Alors que son projet approchait de sa fin, j'ai parlé avec lui de cette expérience pour essayer de déterminer le rôle que pouvaient avoir la publication d'outils libres d'un studio pour de jeunes artistes comme lui. Je m'appuierai ici sur son témoignage.

La première de mes interrogations était la raison du choix de la technique des pantins pour sa pratique personnelle. C'est une technique que Loqmane avait déjà utilisée pour d'autres projets, mais pas avec les mêmes outils. Son choix est donc d'abord esthétique, comme il le précise :

> « Elle permet dans un premier temps de garder une esthétique fidèle aux traits de l'auteur. En effet, une certaine personne m'a dit un jour que mon style de dessin serait impossible à mettre en œuvre en animation... Je suis content d'avoir enfin
trouvé une technique qui s'adapte parfaitement au style de dessin que j'adopte.<fnref n="1" /> »

Cette raison est effectivement la même que celle invoquée par Michel Ocelot, et d'autres adeptes de la technique, et aussi une des raisons premières pour les Fées spéciales. Plus encore que dans le cas de Loqmane, pour le studio, l'esthétique peut être très différente d'un projet à l'autre, selon le médium*, le type de projet, la direction artistique, et les choix et contraintes artistiques. L'intérêt est donc évident par rapport à d'autres techniques d'animation 3D, dans lesquelles une traduction doit forcément être faite entre le style visuel des concepts et celui des images animées du film. Mais comme l'explique l'artiste, son choix est également technique :

> « De plus, c'est une technique qui permet d'effectuer des corrections rapidement. En effet, si je dois corriger un petit défaut de la tête, ou modifier une main, il me suffit de corriger directement sur le PNG en question ou de redessiner une nouvelle main par exemple. C'est une technique modulable qui permet cela.

> « Je la trouve assez rapide à mettre en œuvre une fois la prise en main de celle-ci. De plus elle est tout de suite très efficace lorsque le découpage du pantin est top.

> « C'est une technique qui prend moins de temps que la 3D et donc moins onéreuse en coût de production et de temps de vie, ahah. »

Cette analyse de l'artiste est éclairante, car elle montre un autre aspect de la technique : sa souplesse, et par extension sa scalabilité*. Comme il le dit, les corrections sont rapides. Il explique avoir dessiné et animé les personnages seul dans son projet, assisté par des collaborateurs pour le rig. La situation est donc plus simple que pour un long-métrage, réalisé par une grande équipe au sein d'un studio, mais a fortiori dans ce dernier cas, le gain de temps est d'autant plus appréciable qu'il y a plus de personnages, de plans*, et que les réalisateurs sont plus exigeants — et demandent plus de retakes*.

Un autre intérêt que souligne Loqmane est d'ordre pédagogique, car la technique demande un investissement moindre que celui de la 3D :

> « Pour l'animation c'est très pratique surtout pour une personne qui « débute » dans l'animation de personnage. La prise en main est rapide!! Je n'ai pas de

<footnote n="1">1. Entretien par courriel avec l'auteur, 22 mars 2019.</footnote>
« formation » d'animateur mais je peux tout de même animer les pantins.

« La 3D ne m'attire absolument pas pour le moment. »

Cet aspect du discours m'intéresse tout particulièrement. Comme il le dit, Loqmane a de l'expérience pour avoir réalisé plusieurs films durant ses études, mais il a reçu peu de formation théorique dans l'art et la technique de l'animation. Contrairement à l'animation 3D, qui demande tant de connaissances qu'elles demandent à être divisées en spécialisations, l'animation des pantins, même numériques, peut être assez rapidement apprise, et entièrement maîtrisée par une seule personne sur un projet. Paradoxalement, Blender est un programme d'une grande complexité, mais grâce au processus des pantins, il peut être utilisé par des artistes ne connaissant qu'une petite partie de ses fonctions — quitte à en apprendre plus par la suite.

Sachant que Loqmane avait appris les outils conçus au sein du studio, je l'ai questionné sur l'utilisation qu'il en faisait dans sa pratique personnelle. Mais je sais également qu'il existe d'autres outils que ceux des Fées spéciales, libres ou non, pour m'en être en partie inspiré en premier lieu. J'ai donc demandé quels outils il aurait choisi si ceux-ci n'avaient pas existé, et si même il aurait animé des pantins :

« Oui, j'aurais tout de même animé des pantins avec Blender en m'inspirant des pantins papier type Michel Ocelot. Si je n'avais pas connu Blender je serais allé vers After Effects qui permet la même technique mais plus complexe à mettre en place. [...] Pendant un an, 2015-2016, j'ai utilisé After Effects pour mon premier film. Un collègue m'a fait découvrir DUIK, mais au départ dur dur de comprendre comment ça marche... on a galéré comme des fous furieux à comprendre, c'était horrible. Jamais plus je ne l'utiliserai. Vive Blender et les pantins! [...] C'est très efficace, on s'y retrouve facilement quand on anime les pantins. L'ergonomie des controllers est très bien pensée. Cela permet une production de masse de pantins avec un protocole assez clair, je pense.

« De plus, le rig des fées est une excellente base si on veut pousser encore plus loin cette technique. Ce qui est bien c'est qu'on peut l'adapter, le modifier, en fonction du genre des pantins. »
L'affirmation que les outils des Fées étaient plus faciles à utiliser que DUIK m'a beaucoup surpris, car sans l'avoir utilisé beaucoup moi-même, j'en connais les fonctionnalités, et j'en ai surtout entendu des compliments de la part d'animateurs. Peut-être est-il trop complet, ou trop complexe à utiliser pour un non-spécialiste. Un autre point intéressant est la notoriété des outils cités : ils ne sont pas forcément les plus connus dans le milieu par les animateurs, qui apprennent plus fréquemment ToonBoom pour le film, ou Spine pour le jeu vidéo.

Un dernier point soulevé par Loqmane est complémentaire aux fonctionnalités du programme, et concerne son support, et en particulier la facilité d'installation. En effet, au sein du studio, les outils de pantins font partie du pipeline*, et des solutions ont été mises en œuvre pour qu'ils soient automatiquement déployés sur tous les postes de travail, pour chaque graphiste. C'est loin d'être le cas dès que les outils sont publiés et utilisés en dehors de la société qui les a créés. La majorité des programmes open source sont rendus disponibles sur des forges, des services comme GitHub ou GitLab, qui permettent de faciliter le développement collaboratif, le déploiement, et le support technique des programmes, en particulier pour des programmeurs « amateurs », dont l'édition de logiciels n'est pas l'activité principale. C'est le cas pour les scripts* des Fées spéciales, publiés entre autres sur GitHub. Mais le support technique sur une telle plate-forme n'est pas des plus intuitifs pour qui n'a pas un minimum d'expérience de programmation. Loqmane raconte par exemple avoir eu des difficultés à installer les outils :

> « Dur dur au départ quand Kévin [collaborateur au studio] et toi aviez essayé d'installer le tout sur mon ordinateur. Souviens-toi, je suis sur Windows, il a fallu que tu installes je ne sais plus quoi pour pouvoir commencer à installer les outils des fées. Je ne sais plus si vous l'aviez fait mais je pense qu'il serait judicieux de faire un tuto, une page [...] dédiée à l'installation des outils qui explique de A à Z le processus d'installation que l'on soit sur Windows ou autre. La difficulté d'installation peut en rebuter plus d'un. »

Il est indéniable que le fait de concevoir et maintenir un outil qui réponde à la fois aux
besoins internes du studio et à ceux de tous les utilisateurs potentiels demande du temps,
que l'on n'a pas nécessairement en production. De fait, beaucoup de programmes libres
ont l'habitude d'être fournis « en l'état », comme l'indiquent la plupart des licences
libres, c'est-à-dire sans garantir qu'ils fonctionnent pour un usage précis, ou même tout
court. Cela ne veut pas dire que les développeurs de logiciels libres ne fassent jamais
attention à l'expérience de l'utilisateur, mais que dans un contexte comme le nôtre, elle
est secondaire. Et même si Loqmane avait connu le système de support technique intégré
à GitHub, il n'est pas certain qu'il l'aurait utilisé pour demander de l'aide, et il est encore
moins certain que les créateurs du programme aient eu le temps d'y répondre.

Mais malgré les difficultés d'installation, le simple fait que Loqmane, qui a peu de
connaissances en 3D, moins encore en scripting, qui n'a pas de studio de fabrication pour
l'appuyer, ni une équipe de TD* ou de R&D* pour l'assister, a pu réaliser avec succès
son film en utilisant les outils développés au départ pour un usage interne, est révélateur
du rôle potentiel du logiciel libre pour les artistes individuels, dont les seules ressource
sont leurs propres argent, savoir-faire et temps.
# Annexe D

## Méthode pour trouver le nombre de films dont le scénariste est aussi réalisateur

Dans la section I.1.2.1, j'affirme que beaucoup de films sont écrits et réalisés par la même personne. Mon collègue Flavio Perez m'a fait remarquer à juste titre que cette affirmation était douteuse. Pour le vérifier, j'ai téléchargé un extrait de la base de données du film IMDb<fnref n="1" />. J'ai choisi les fichiers `title.basics.tsv`, décrivant les films et `title.crew.tsv`, listant les réalisateurs et scénaristes. J'ai ensuite créé une base de données SQLite3 pour comparer les informations des films et des créateurs, et ne garder que les entrées pertinentes. J'utilise pour cela le script suivant :

```
-- Copyright © 2019 Damien Picard <dam.pic@free.fr>
```

```
-- This work is free. You can redistribute it and/or modify it under the
```

```
-- terms of the Do What The Fuck You Want To Public License, Version 2,
```

```
-- as published by Sam Hocevar. See http://www.wtfpl.net/ for more details.
```

<footnote n="1">1. Cette base de données non-libre est disponible à l'adresse https://www.imdb.com/interfaces/. Il n'existe pas de base de données ouverte (cf. section I.2.4) sur les œuvres cinématographiques, c'est-à-dire pouvant être utilisée à n'importe quelle fin, y compris commerciale, modifiée, agrégée et redistribuée. L'utilisation de ces données demande d'afficher le message suivant : Information courtesy of IMDb (http://www.imdb.com). Used with permission.</footnote>
```sql
-- Création des tables contenant les films et les équipes
CREATE TABLE movies
  (tconst TEXT, titleType TEXT, primaryTitle TEXT, originalTitle TEXT,
   isAdult BOOL, startYear INT, endYear INT, runtimeMinutes INT, genres TEXT);

CREATE TABLE crew
  (tconst TEXT, directors TEXT, writers TEXT);
```

```sql
-- Passer en mode tabulation pour respecter le format des fichiers
.mode tab

-- Importer les fichiers dans les tables précédemment créées
.import ./title.basics.tsv movies
.import ./title.crew.tsv crew
```

```sql
-- Passer en mode CSV (valeurs séparées par des virgules),
-- et exporter la requête suivante
.mode csv
.output title_crew.csv
```

```sql
-- Requête joignant les deux tables et sélectionnant les entrées pertinentes
SELECT * FROM movies INNER JOIN crew USING (tconst) WHERE (
  -- Sélectionner les films (œuvres de type 'movie')...
  titleType == 'movie'
  -- et dont le genre est 'Animation'...
  AND INSTR(genres, 'Animation')
  -- et dont le réalisateur et le scénariste sont renseignés
  AND directors != '\N'
  AND writers != '\N'
);
```

J'obtiens le fichier `title_crew.csv`. J'utilise ensuite ce script Python pour déterminer quels films ont été écrits et réalisés par au moins une personne :

```bash
#!/usr/bin/env python3
#
# Copyright © 2019 Damien Picard <dam.pic@free.fr>
# This work is free. You can redistribute it and/or modify it under the
```
```
# terms of the Do What The Fuck You Want To Public License, Version 2,
# as published by Sam Hocevar. See http://www.wtfpl.net/ for more details.
```

```python
import csv
```

```
# Ouvrir le fichier CSV et en lire les lignes
```

```python
with open('./title_crew.csv') as f:
```

```python
rows = list.csv_reader(f))
```

```
# Initialiser deux compteurs à 0
same = 0
```

```python
diff = 0
```

```python
# Pour chaque ligne,
for r in rows:
```

```python
# Récupérer les deux dernières valeurs,
# correspondant aux scénaristes et aux réalisateurs
directors, writers = r[-2:]
```

```python
# Il peut y avoir plusieurs scénaristes ou plusieurs réalisateurs
# On crée donc des ensembles (set()) pour les comparer
directors = set(directors.split ','))
writers = set(writers.split ','))
```

```python
# Intersection des deux ensembles.
if directors & writers:
```

```python
# Si l'intersection contient au moins un élément, on incrémente same
same += 1
```

```python
else:
```

```python
# Sinon, on incrémente diff
diff += 1
```

```python
# Afficher le nombre de lignes où un élément est contenu
# dans les deux colonnes, et le nombre où ce n'est pas le cas
print("Identique: ", same, "\nDifférent: ", diff)
```

```python
# Afficher le pourcentage
print("{:.2f} %".format(same / (same + diff) * 100.0))
```

```python
# Si l'intersection contient au moins un élément, on incrémente same
same += 1
```

```python
else:
```

```python
# Sinon, on incrémente diff
diff += 1
```

```python
# Afficher le pourcentage
print("{:.2f} %".format(same / (same + diff) * 100.0))
```

```python
# Afficher le nombre de lignes où un élément est contenu
# dans les deux colonnes, et le nombre où ce n'est pas le cas
print("Identique: ", same, "\nDifférent: ", diff)
```

```python
# Afficher le nombre de lignes où un élément est contenu
# dans les deux colonnes, et le nombre où ce n'est pas le cas
print("Identique: ", same, "\nDifférent: ", diff)
```

```python
# Afficher le pourcentage
print("{:.2f} %".format(same / (same + diff) * 100.0))
```

```python
# Afficher le pourcentage
print("{:.2f} %".format(same / (same + diff) * 100.0))
```

```python
# Afficher le pourcentage
print("{:.2f} %".format(same / (same + diff) * 100.0))
```

```python
# Afficher le nombre de lignes où un élément est contenu
# dans les deux colonnes, et le nombre où ce n'est pas le cas
print("Identique: ", same, "\nDifférent: ", diff)
```
# Annexe E

## Guide d'entretien semi-directif

### Confidentialité

- Puis-je enregistrer cet entretien ?

### But de la recherche, positionnement

- Thèse de doctorat sur FLOSS dans l'animation

- Orientation technique, éventuellement artistique, donc questions à des techniciens (TD...)

### Utilisation

- Utilises-tu le logiciel libre en production ?

- Depuis quand ?

- Si oui, pourquoi avoir changé ?

- Dans quels domaines ?

- OS

- création

- DCC 3D

- texturing / painting

- compositing

- montage

- simulation

- autre :

- langages et environnements de développement
☐ python ou autre langage script

☐ VCS

☐ IDE

☐ autre :

☐ pipe

☐ asset management

☐ production management

☐ autre :

☐ outils divers

☐ gestion de ferme de calcul

☐ encodage de médias

☐ format d'image

☐ étalonnage / color pipeline

☐ communication

☐ autre :

— Quelle utilisation fais-tu du logiciel libre ?

— Quels intérêts techniques vois-tu au logiciel libre ?

— Innovation ?

— Accès au code, extensibilité, adaptation au pipeline ?

— Concernant les outils ? les DCCs ?

— Pérennité ? (exemple XSI)

— Quels freins vois-tu à l'adoption du logiciel libre ?

— Investissement R&D, temps de développement ?

— Limitations techniques ? pipeline ? artistiques ? juridiques ?

— Amateurisme ?

— Problèmes de sécurité ?

— Support technique ?

## Contribution

— As-tu contribué à des projets de logiciel libre ?

— De quelle manière ? (utilisation, design, code, bugfix, rapport d'erreur, suggestions...)

— Si publication : outil maison ? lib/framework ? application ?
## Juridique

- T'es-tu renseigné sur les licences logicielles pour utiliser ou publier du code ?

- As-tu déjà lu le texte d'une licence libre ?

- As-tu déjà consulté un avocat concernant le droit d'auteur ?

- Fais-tu une distinction entre Logiciel libre et Open Source ?

- Cette distinction est-elle importante pour ton travail ?

- De manière générale ?

## Données, contenus libres

- As-tu déjà vu des films sous licences ouvertes ? (ex. CC)

- T'intéresses-tu à ce type de contenus ?

- Économiquement ? (financement, crowdfunding, etc.)

- Pour les possibilités créatives ? (Remix, réutilisation)

- De diffusion ? (copie libre)

- Éthiquement ? (société du partage)

## Talon

- Nombre de salariés sur une prod. moyenne :

- Secteur

- Animation

- Post-production / VFX

- Autre :

- Poste

- TD

- Dev

- Graphiste

- Production

- Autre :