# Le logiciel libre dans un studio d'animation

Damien Picard

► To cite this version:

Damien Picard. Le logiciel libre dans un studio d'animation. Art et histoire de l'art. Université Paris VIII - Vincennes à Saint-Denis, 2020. Français. NNT: 2020PA080051. tel-03692591

HAL Id: tel-03692591

https://theses.hal.science/tel-03692591

Submitted on 9 Jun 2022

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

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

Distributed under a Creative Commons Attribution - ShareAlike 4.0 International License
UNIVERSITÉ PARIS 8 – VINCENNES SAINT-DENIS

UFR ARTS, PHILOSOPHIE, ESTHÉTIQUE

ÉCOLE DOCTORALE ESTHÉTIQUE, SCIENCES ET TECHNOLOGIES DES ARTS

# Thèse

Pour obtenir le grade de

DOCTEUR DE L'UNIVERSITÉ PARIS 8

Discipline : Esthétique, sciences et technologies des arts

Spécialité : Images numériques

## Le logiciel libre dans un studio d'animation

Présentation et soutenance le 2 décembre 2020 par Damien PICARD

Thèse dirigée par Alain LIORET

En codirection avec Anne-Laure GEORGE-MOLLAND

### Membres du jury

Alain LIORET (PR) Université Paris 8

Sébastien BROCA (MCF) Université Paris 8

Réjane HAMUS-VALLÉE (PR) Université d'Évry

Manthos SANTORINEOS (PR) École des beaux-arts d'Athènes

Anne-Laure GEORGE-MOLLAND (MCF) Université Paul Valéry Montpellier 3
Résumé

L'animation, la pratique consistant à donner vie à des images en mouvement
créées de toutes pièces, utilise aujourd'hui largement l'informatique pour la créa-
tion des images. Cela signifie que les graphistes, les techniciens et développeurs
utilisent des programmes spécialisés pour mener à bien toutes les étapes de créa-
tion.

Parmi ces logiciels, il en est une catégorie particulière : le logiciel libre, auquel
les studios d'animation s'intéressent de plus en plus depuis le début de la décennie.
Ce type de programmes présente des particularités juridiques qui permettent à
leurs utilisateurs de les utiliser comme bon leur semble, à l'inverse des logiciels
dits propriétaires, dont l'utilisation est sévèrement restreinte par les conditions
imposées par leurs licences. Les licences de logiciels libres permettent en particulier
d'utiliser, d'étudier, de modifier et de distribuer le code source des programmes, ce
qui permet un développement collaboratif par les communautés de développeurs
et d'utilisateurs.

Certaines applications de création, comme Blender et Krita, sont aujourd'hui
considérées comme des alternatives crédibles à leurs équivalents propriétaires, et
peuvent trouver leur place au sein des pipelines de fabrication des studios. Ces
derniers peuvent ainsi contribuer par leur savoir-faire à l'amélioration des pro-
grammes, pour le bien de l'ensemble de la communauté d'utilisateurs.

Ils peuvent également distribuer sous licence libre leurs propres scripts et pro-
grammes, qu'ils élaborent souvent dans le cadre de leurs productions. Différents
studios peuvent ainsi collaborer sur des outils, profiter de moyens de production
communs et ainsi partager leurs coûts de développement, plutôt que d'espérer
garder des secrets de fabrication propriétaires et recommencer toujours les mêmes
développements.

Mots-clefs : animation, 3D, création, logiciel libre, open source, pipeline

Abstract

Animation, the practice of giving life to moving pictures created ex nihilo,
broadly uses computers to create images. Artists, technicians and developers thus
use specialised programs to achieve all steps of creation.
There is one particular category of software in which animation studios have a growing interest since the beginning of the decade: free software. This type of software has unique legal particularities, which enable its users to use them as they see fit, contrary to so-called proprietary software, whose use is severely restrained by the conditions imposed by their licenses. Free software licenses allow especially the use, study, modification and distribution of the programs, which enables a collaborative development by user and developer communities.

Some content creation applications, such as Blender and Krita, are now considered credible alternatives to their proprietary equivalents, and may find a place in the animation studios' pipelines. The studios may in turn contribute to improving those programs using their professional skills, which profits the whole user community.

The studios may as well distribute their own scripts and programs under free software licenses, when they create such in-house tools for their own projects. Multiple studios may then collaborate to create and improve tools, thus sharing their development costs, rather than hoping to keep proprietary trade secrets, and developing the same tools over and over again.

**Keywords:** animation, 3D, creation, free software, open source, pipeline
Remerciements

Une thèse, il paraît que c’est long et difficile, je le savais avant même le début. Alors que j’écris ces lignes, je suis encore loin de l’avoir terminée, mais si vous les lisez, c’est que c’est fait et que tout va bien. Pour mener à bien cette entreprise, je n’ai pas été tout seul et je veux remercier des tas de gens. En voici quelques-uns.

Maman et Papa. Mon frère. Sa femme, ma belle sœur.

Virginie, qui m'a proposé de faire cette thèse, allant même jusqu'à insister bien longtemps. J'ai dit oui.

Anne-Laure "ALGM" George-Molland, ma codirectrice de thèse, qui m'a accompagné, suivi, et supporté sans relâche, et sans qui je n'aurais pas fini, ou en tout cas avec autant de rigueur.

Mon collègue-associé-superviseur-ami Flavio Perez (¡Hola señor!), qui a été d'une aide précieuse pour cette thèse : il m'a appris une partie de mon métier (celle où je fais comme si j'étais un TD), montré plein de choses, relu, veillé à ma santé et généralement été un bon copain.

Merci aux gens que j'ai interrogés et que je cite dans ma thèse : Damien Coureau, Flavio Perez, François Grassard, Léa Cluzel, Loqmane Bahri.

Mes colocataires, avec qui j'ai vécu plusieurs années de ma vie, mais pas tous en même temps : Max, Flavio, Duy Kévin, Alina, Mina, Lindsay, Floriane, Julien. Pour la plupart, ils furent également mes collègues — comparer avec le paragraphe suivant — et nous avons vécu en bonne intelligence malgré ça.

Mes collègues des Fées spéciales, avec qui nous avons collaboré, fait de belles choses, pas mal rigolé et partagé ensemble des moments forts, bons ou mauvais. Merci à Alina,
Amin, Aude, Carolina, Clémence, Clémentine, Cyrille, Duy Kévin, Emmeline, Eric, Ève, Gabrièla, Guilhem, Jeanne-Sylvette, Joris, Loqmane, Léa, Léo, Marie, Marion, Marthe, Mathieu, Max, Meryl, Mina, Natalène, Oriane, Philippe, Sophie, Vincent, Yann.

Mes relectrices et relecteurs, encore les mêmes : Anne-Laure, Duy, Flavio, Floriane, Natalène.

Je remercie les équipes des projets sur lesquels j'ai travaillés, en particulier :

— *Dilili* : Michel, Jean-Claude, Malek;

— *Musée de Lodève* : Stéphane, Noisette.

Je remercie les auteurs et contributeurs des logiciels libres et projet suivants, sans
qui cette thèse n'aurait pas eu grand-chose à étudier :

— Blender;

— Godot;

— Krita;

— CGWire;

— Kabaret;

— OpenStreetMap.

Enfin, je remercie les copains, que je ne vois pas tous souvent, mais qui n'en sont
pas moins là. En plus des copains déjà mentionnés parce qu'ils sont aussi des collègues,
je remercie donc Adam, Alix, Clarisse, Eddy, Émilie, Erwan, Florine, François, Freddy,
Gabriel, Gabriel, Gaspard, Guillaume, Juliette, Kévan, Laure, Louis-Julien, Lucile, Mat-
thieu, Nicolas, Noélie, Ouirich, Pascal, Romain, Simon, ainsi que les membres de ma
famille, qui se reconnaîtront sans ambiguïté possible.
# Table des matières

Résumé 2

Remerciements 4

Table des matières 6

Introduction générale 11

# I L'animation et le libre : contexte de recherche 14

## I.1 Le secteur de l'animation 16

I.1.1 Les studios d'animation 16

I.1.2 Le pipeline de fabrication 21

I.1.2.1 Préproduction 24

I.1.2.2 Fabrication 28

I.1.2.3 Post-production 35

I.1.2.4 Gestion d'assets et suivi de production 37

## I.2 Le logiciel libre 42

I.2.1 Historique 43

I.2.1.1 Le logiciel dans le milieu universitaire 43

I.2.1.2 Privatisation et commercialisation 44

I.2.1.3 Richard Stallman et les valeurs de partage 45

I.2.2 Fondements juridiques 46

I.2.2.1 Systèmes de protection : brevets et droits d'auteur 46

I.2.2.2 Copyright et droit d'auteur 47

I.2.2.3 Les licences logicielles : droits et restrictions de l'utilisateur 48

I.2.2.4 Licences libres 49

I.2.3 Libre et Open Source : confusion et approches idéologiques 50
<table><tr><td>I.2.4</td><td>Open data</td><td>52</td></tr><tr><td>I.2.4.1</td><td>Données d'élévation de la NASA</td><td>53</td></tr><tr><td>I.2.4.2</td><td>OpenStreetMap</td><td>54</td></tr></table>

# II Enjeux du libre pour l'animation 60

## II.1 Obligations et libertés juridiques 62

<table><tr><td>II.1.1</td><td>Les quatre libertés du logiciel libre</td><td>62</td></tr><tr><td>II.1.1.1</td><td>Utiliser</td><td>63</td></tr><tr><td>II.1.1.2</td><td>Étudier</td><td>65</td></tr><tr><td>II.1.1.3</td><td>Modifier</td><td>70</td></tr><tr><td>II.1.1.4</td><td>Distribuer</td><td>78</td></tr><tr><td>II.1.2</td><td>Pérennité du code et maintenabilité</td><td>80</td></tr><tr><td>II.1.3</td><td>Choix des licences</td><td>84</td></tr><tr><td>II.1.3.1</td><td>Licences Copyleft</td><td>84</td></tr><tr><td>II.1.3.2</td><td>Licences permissives</td><td>87</td></tr><tr><td>II.1.3.3</td><td>Exemple de publication : un script pour Blender</td><td>88</td></tr><tr><td>II.1.4</td><td>Œuvres sous licence de libre diffusion</td><td>92</td></tr></table>

## II.2 La place du libre dans l'économie des studios d'animation 97

<table><tr><td>II.2.1</td><td>Acquisition de logiciels existants</td><td>98</td></tr><tr><td>II.2.1.1</td><td>Le logiciel commercial propriétaire, solution par défaut</td><td>98</td></tr><tr><td>II.2.1.2</td><td>Le logiciel libre : l'alternative</td><td>100</td></tr><tr><td>II.2.2</td><td>Développement interne des logiciels</td><td>102</td></tr><tr><td>II.2.2.1</td><td>Contrôle de la chaîne de fabrication</td><td>102</td></tr><tr><td>II.2.2.2</td><td> Fonctionnalités développées par la communauté</td><td>103</td></tr><tr><td>II.2.3</td><td>Financement du développement logiciel</td><td>105</td></tr></table>

## II.3 Usages du libre : considérations techniques 110

<table><tr><td>II.3.1</td><td>Innovation des logiciels de création</td><td>110</td></tr><tr><td>II.3.2</td><td>Interopérabilité et standardisation</td><td>113</td></tr><tr><td>II.3.2.1</td><td>Formats d'échange</td><td>113</td></tr><tr><td>II.3.2.2</td><td>Organismes de standardisation</td><td>119</td></tr><tr><td>II.3.3</td><td>Contributions à un projet libre</td><td>120</td></tr><tr><td>II.3.3.1</td><td>Des manières de publier un add-on</td><td>122</td></tr><tr><td>II.3.3.2</td><td>Publication indépendante d'add-ons</td><td>123</td></tr></table>
<table><tr><td>II.3.3.3</td><td>Maintenance officielle d'add-ons</td><td>125</td></tr><tr><td>II.3.3.4</td><td>Harmonisation du code entre contributeurs</td><td>127</td></tr></table>

# III Vers un pipeline libre 132

## III.1 Projets pour l'émergence d'un pipeline libre 134

III.1.1 *Dilili à Paris* 134

III.1.2 *Antarctica* 136

III.1.2.1 Exposition au musée des Confluences 136

III.1.2.2 Films documentaires télévisés 138

III.1.3 Exposition pour le musée de Lodève 139

III.1.3.1 Archéologie : films animés 140

III.1.3.2 Modélisation et création d'objets physiques 140

## III.2 Préproduction 142

III.2.1 Storyboard et animatique 142

III.2.1.1 Fonctionnalités essentielles des logiciels de storyboard 143

III.2.1.2 Solutions existantes 145

III.2.1.3 Storyboarder 145

III.2.1.4 Storymatic, une solution interne aux Fées spéciales 147

III.2.2 Layout 150

III.2.2.1 Outils spécifiques pour le layout des Fées spéciales 150

III.2.2.2 Publication sous licence libre 153

## III.3 Fabrication 154

III.3.1 Rigging et animation de personnages : les pantins 155

III.3.1.1 Initiation et historique du projet 155

III.3.1.2 Contraintes 158

III.3.1.3 Solutions existantes 163

III.3.1.4 Développement de l'outil de rig de pantins 164

III.3.1.5 Publication libre 176

III.3.2 Rendu 176

III.3.2.1 Types de moteurs existants 177

III.3.2.2 Moteurs utilisés par les Fées Spéciales 177

III.3.3 Compositing 180

III.3.3.1 Logiciels prédominants 180
<table><tbody><tr><td>III.3.3.2 Natron</td><td>181</td></tr><tr><td>III.3.3.3 Blender</td><td>183</td></tr><tr><td><strong>III.4 Post-production</strong></td><td><strong>184</strong></td></tr><tr><td>III.4.1 Validation des images</td><td>184</td></tr><tr><td>III.4.1.1 Développement d'une solution maison fondée sur des programmes libres</td><td>185</td></tr><tr><td>III.4.2 Livraison des masters</td><td>187</td></tr><tr><td><strong>III.5 Outils transversaux</strong></td><td><strong>189</strong></td></tr><tr><td>III.5.1 Logiciels de gestion de production et d'assets</td><td>190</td></tr><tr><td>III.5.1.1 Suivi de production : CGWire</td><td>190</td></tr><tr><td>III.5.1.2 Gestion d'assets : Kabaret</td><td>192</td></tr><tr><td>III.5.2 Communication avec d'autres studios</td><td>194</td></tr><tr><td>III.5.2.1 Format maison</td><td>196</td></tr><tr><td>III.5.2.2 Export de la déformation</td><td>197</td></tr><tr><td>III.5.2.3 Import dans Maya</td><td>198</td></tr><tr><td><strong>III.6 Exploitation de données ouvertes</strong></td><td><strong>200</strong></td></tr><tr><td>III.6.1 Les trajets des équipes</td><td>201</td></tr><tr><td>III.6.2 Le cœur</td><td>203</td></tr><tr><td>III.6.3 L'écoulement de la banquise</td><td>207</td></tr><tr><td>III.6.4 Cartes de l'Antarctique</td><td>210</td></tr><tr><td><strong>III.7 Acquisition et usinage 3D</strong></td><td><strong>212</strong></td></tr><tr><td>III.7.1 Contraintes techniques pour la muséographie</td><td>214</td></tr><tr><td>III.7.1.1 Réalisation de maquette schématique</td><td>214</td></tr><tr><td>III.7.1.2 Réalisation d'œuvres hybrides physiques-virtuelles</td><td>216</td></tr><tr><td>III.7.2 Transformations numériques d'objets réels</td><td>220</td></tr><tr><td>III.7.2.1 Recomposition en 2D d'un relief 3D</td><td>221</td></tr><tr><td>III.7.2.2 Sculpture numérique</td><td>225</td></tr><tr><td>III.7.3 Photogrammétrie libre</td><td>227</td></tr><tr><td>III.7.3.1 MicMac</td><td>228</td></tr><tr><td>III.7.3.2 Colmap, openMVG, openMVS, MVE, Meshlab, etc.</td><td>230</td></tr><tr><td>III.7.3.3 Meshroom</td><td>231</td></tr><tr><td>III.7.4 Conclusion</td><td>232</td></tr></tbody></table>
Conclusion générale 235

Glossaire 244

Table des figures 253

Bibliographie 256

Annexe A Exemple de fichier JSON pour *Dilili à Paris* 265

Annexe B Autonomisation des artistes : *Music Road* 267

B.1 Cahier des charges 270

B.2 Rendu graphique de la carte 272

B.3 Itinéraire 273

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

B.5 Conclusion 278

Annexe C Les pantins en dehors du studio : Loqmane Bahri 280

Annexe D Méthode pour le nombre de films 285

Annexe E Guide d'entretien semi-directif 288
# Introduction générale

Le secteur du cinéma d'animation connaît des changements constants et rapides. Outre les changements esthétiques, visibles par le public, les méthodes de fabrication évoluent également. Depuis plusieurs décennies maintenant, la fabrication des films d'animation est en grande partie, ou intégralement numérique. Cela implique que soient utilisés des logiciels, dont l'usage évolue également au gré de « modes ». Parmi les logiciels, il existe une catégorie particulière : le logiciel libre. Ce mouvement existe depuis les années 1980, et il commence trente ans plus tard à produire des logiciels adoptés par les studios. La fabrication de chaque film, de chaque œuvre, a ses particularités, mais l'utilisation du logiciel libre crée des problématiques singulières car elle demande de considérer le logiciel autrement, que l'on soit développeur ou contributeur, utilisateur ou formateur.

Cette thèse de doctorat étudiera les possibilités et les limitations actuelles de l'usage du logiciel libre dans un petit studio d'animation.

Les logiciels changent constamment, et les processus aussi. Plutôt que de décrire une solution d'un bout à l'autre, cette thèse expose donc des briques logicielles existantes ou conçues au sein d'un studio, et la logique sous-jacente du développement et de la publication de ces outils.

Cette thèse a été menée dans le cadre d'une convention Cifre avec une entreprise du secteur du cinéma d'animation, les Fées spéciales (cf. section I.1.1). De ce fait, une grande partie du temps de recherche s'est effectuée au sein de l'équipe Recherche et Développement (R&D*<fnref n="1" />) de l'entreprise. Ainsi, mon rôle a été de concevoir, mettre en œuvre, tester, valider des programmes et processus pour la création audiovisuelle. La

<footnote n="1">1. Les termes suivis d'une astérisque sont définis dans le glossaire.</footnote>
jeunesse et la taille réduite de la structure étaient propices à la recherche et à l'innovation. Une grande latitude m'a donc été laissée dans la méthode et le choix des solutions techniques. En effet, l'équipe R&D, qui ne portait même pas ce nom à mon arrivée, était composée de deux à trois programmeurs, et la responsabilité de développement s'est partagée assez naturellement, selon les compétences de chacun. De plus, la plupart du travail réalisé en entreprise a consisté à résoudre des problèmes ciblés, et n'a pas nécessité de méthode de développement complexe, mais plutôt d'une élaboration organique des scripts*, programmes et processus.

Ce poste était très technique, mais n'excluait pas des composantes artistiques, à deux titres. D'abord, j'ai participé directement à des productions en tant que graphiste, en particulier pour des programmes nécessitant des compétences techniques relativement avancées. Ensuite, j'ai collaboré avec des graphistes pour mettre en œuvre des solutions techniques pour le pipeline* de fabrication. La conception des outils a été le fruit d'un processus itératif, d'un aller-retour avec les graphistes, de l'étape du cahier des charges et des prototypes au support en cours de production, afin d'obtenir des outils adaptés aux productions de la structure, mais également de recueillir les opinions, habitudes de travail et expériences des utilisateurs principaux.

À ce poste, j'ai également pris part à des décisions concernant la stratégie de développement open source, dans l'évaluation et le choix de solutions existantes, comme dans la communication et la publication à l'extérieur de nos propres solutions, et c'est en partie dans ce cadre que je me suis documenté sur les aspects historiques, juridiques, organisationnels et communicationnels du développement de logiciel libre.

En parallèle de mon travail de R&D en entreprise, j'ai profité de périodes de recherche à l'extérieur pour faire des expériences artistiques plus personnelles et moins directement soumises aux contraintes de la production. Ces expériences ne sont pas toujours parties d'hypothèses précises, mais plutôt d'intuitions. Cet état d'esprit a permis d'explorer plus librement mon champ de recherche, et ont fourni un matériau d'analyse riche.

Ma démarche personnelle s'inscrit donc dans un processus de recherche-création en ce que les œuvres qui en résultent sont utiles à l'élaboration de ma recherche, et ne sont
pas destinées à exister uniquement en dehors de cette recherche. Elles entrent dans la catégorie que CHAPMAN et SAWCHUK [10] appellent la création comme recherche, c'est-à-dire « l'élaboration de projets dans lesquels la création est requise pour que puisse émerger la recherche ». Il est à noter que le terme de recherche-création est généralement considéré dans un contexte de sciences humaines. Dans mon cas, à la suite des études que j'ai suivies dans le département Arts et Technologies de l'Image à l'Université Paris VIII, une composante essentielle est pratique et technique, et s'attache à déterminer l'influence de la technique sur les possibilités créatrices.

Par ailleurs, la méthode que j'adopte exploite une sorte de sérendipité dans l'ex-
périmentation, en tâchant d'éviter de présupposer des résultats que pourraient fournir
une expérience, mais en orientant cette expérience pour que ses résultats, quels qu'ils
soient, portent des points de données intéressants. C'est une méthode que j'avais déjà
employée lors de ma recherche en master en 2014 sur le sujet de La boucle d'animation,
que j'avais appelée « pour voir comment ça fait », ce qui ne semble pas au premier
abord une méthode bien rigoureuse, mais est à la base de ma méthode de recherche
artistique expérimentale. Aujourd'hui, je la reformulerais en « on verra bien ce que ça
donne », en remarquant le fait que les deux formulations touchent d'abord au visuel
et à la potentialité, car on ne prévoit pas à l'avance les sentiments provoqués par une
création ; et aux résultats, qu'il faut comprendre comme des résultats esthétiques, mais
aussi comme des résultats expérimentaux, propres à dégager des conclusions théoriques.

Cette thèse comporte trois parties. Je commencerai par exposer dans la partie I le
contexte de recherche. Il est nécessaire d'avoir plusieurs notions en tête pour comprendre
les spécificités du logiciel libre et open source. C'est pourquoi j'exposerai des points
historiques, idéologiques, et juridiques.

La partie II analysera en détail les modalités de cette mise en œuvre par les studios à
travers trois facettes concrètes et complémentaires : économique, juridique et pratique.
Enfin, la partie III sera consacrée aux solutions existantes et à développer pour mettre
en œuvre une chaîne de fabrication libre aussi complète que possible.
Première partie

L'animation et le libre : contexte de
recherche
# Introduction

Afin de bien appréhender l'élaboration d'une chaîne de fabrication libre dans un studio d'animation, il est nécessaire de bien connaître d'une part les spécificités de ce type de structure, et d'autre part de comprendre ce que constitue le logiciel libre et open source.

Cette partie décrira donc les studios d'animation en général, et le studio Les Fées spéciales en particulier, dans la mesure où ce studio a une stratégie active d'utilisation et de développement de logiciel libre, et où j'y ai travaillé trois ans. Je décrirai également une chaîne de fabrication typique de film animé en 3D, de la préproduction à la post-production, et le rôle de chaque département dans la chaîne globale.

J'aborderai ensuite le logiciel libre, en rappelant rapidement son histoire et ses spécificités juridiques et idéologiques, qui sont la fondation du mouvement et des méthodes de développement open source. Je mentionnerai également les bases de données ouvertes, qui fonctionnent selon un principe similaire à celui des logiciels libres, et peuvent être de précieuses ressources pour certains projets d'animation.
# Chapitre I.1

## Le secteur de l'animation

### Introduction

L'animation est un ensemble de techniques, de médiums* et de supports de création ayant en commun la création de séquences animées, c'est-à-dire, pour simplifier, en mouvement. Les images qui constituent ces séquences peuvent être des dessins, des images de synthèse, des photographies d'objets physiques (sculptures, êtres vivants, etc.), ou souvent une combinaison de plusieurs de ces sources.

Le paysage de l'animation change continuellement depuis le début du XXe siècle, et se formalise de plus en plus en des pratiques industrielles uniformes. Si de l'animation peut être produite dans des contextes très différents, la plupart des productions se font dans un environnement semblable et utilisent des techniques similaires.

Je présenterai dans ce chapitre ces deux aspects de l'animation. L'environnement, c'est le studio d'animation, une entreprise dédiée à l'animation. Quant aux techniques, elles sont formalisées au sein d'un studio sous la forme d'un « pipeline » que je décrirai.

### I.1.1 Les studios d'animation

Certains animateurs travaillent seuls, avec pour seul support du papier et pour seuls outils des crayons, mais la grande majorité de la production de films d'animation se fait
au sein d'entreprises communément appelées des studios d'animation, par des équipes plus ou moins nombreuses constituées de graphistes, de techniciens, et de personnel non productif (administration, production). Parmi les graphistes et techniciens, de nombreuses compétences sont nécessaires à la fabrication d'un film, et de nombreuses spécialités interviennent durant la fabrication (cf. section I.1.2). Cette diversité existe dans les médiums dits traditionnels comme le dessin animé, mais elle est encore plus prégnante sur les œuvres en images de synthèse.

## Rôle de l'informatique dans les studios

Dans la production actuelle de cinéma d'animation, les studios utilisent l'informationique dans différentes mesures. Certains se servent de programmes spécifiques pour simplifier ou accélérer certaines étapes du processus de fabrication, par exemple le montage ou le compositing, y compris sur des productions utilisant un médium physique comme le dessin animé ou la stop motion. Pour d'autres, l'œuvre est fabriquée d'un bout à l'autre par ordinateur, que ce soient des films en image de synthèse ou des dessins animés dessinés par ordinateur. Dans tous les cas, les studios utilisent des logiciels spécialisés, qui constituent leurs outils de production.

## Convergence des médiums dans l'animation

De plus, on observe actuellement une convergence dans la fabrication des médiums artistiques utilisant l'informatique, parmi lesquels figurent l'animation, mais aussi le jeu vidéo, la réalité virtuelle, et les « nouveaux médias »<fnref n="1" />. Les techniques ne sont pas les mêmes dans ces différents médias, mais elles ont assez de points communs pour que les acteurs de ces industries créent des liens entre elles, autant du côté des studios, que des développeurs de logiciels, et des financeurs.

De fait, le studio au sein duquel j'ai effectué ma thèse s'intéresse à des formes,

<footnote n="1">1. À titre d'exemple, la conférence Rencontres Animation Développement Innovation, destinée aux professionnels du secteur de l'animation et se tenant chaque année à Angoulême, a vu des interventions sur le sujet chaque année depuis 2016, concernant la réalité virtuelle et les moteurs dits « temps réel » provenant du jeu vidéo [22].</footnote>
techniques et médias divers : il a été amené à travailler sur du long-métrage et de la série d'animation, des effets spéciaux, de la modélisation d'objets pour un musée, des applications interactives (jeu vidéo, réalité virtuelle et augmentée). Ces multiples projets sont rapprochés par les similarités des compétences nécessaires à accomplir chaque type d'œuvre. Sans affirmer que ces compétences sont les mêmes, elles sont assez proches dans le domaine de la 3D pour pouvoir les compter dans la définition plus générale de l'animation.

Je me suis intéressé principalement pour cette thèse au film d'animation et à d'autres médias liés (série télévisée et web, muséographie), mais la proximité croissante des médias me fera également faire des incursions dans des médias connexes.

## Le studio d'animation Les Fées spéciales

La société Les Fées spéciales est une entreprise basée à Montpellier, dont l'objet est principalement la fabrication de films d'animation, mais également la production et la réalisation. Elle crée aussi d'autres formes d'œuvres audiovisuelles ou interactives, propose des formations aux logiciels pour l'animation, et développe des outils de création graphique. Elle a été fondée en 2015 par quatre professionnels de l'animation sous la forme juridique de SCOP (société coopérative et participative), un des statuts de sociétés coopératives françaises. Ce statut, qui s'insère dans le mouvement de l'économie sociale et solidaire (ESS), a pour particularités une gouvernance démocratique et le fait d'être obligatoirement détenue à plus de la moitié par les salariés de l'entreprise.

Les quatre fondateurs de la structure ont tous une grande expérience de la production de film d'animation, pour avoir travaillé dans divers studios, notamment à Paris. Trois d'entre eux ont quitté cette ville pour s'installer à Montpellier et essayer de faire du film d'animation d'une manière nouvelle, qui se manifeste entre autres choses par le choix du statut coopératif, qui est très rare en France<fnref n="2" /> dans ce secteur. Elle se présentait ainsi en 2017, dans un dossier de candidature à un appel d'offre :

<footnote n="2">2. D'après la base de données Sirene® recensant les entreprises françaises, en 2019 seules trente-neuf sociétés coopératives ont pour objet la production de films et de programmes pour la télévision ou pour le cinéma, ou de films institutionnels et publicitaires, sur un total de 35 714.</footnote>
« [Les Fées spéciales] est une SCOP qui fait le vœu d'ouvrir un nouveau chapitre de la fabrication de films d'animation numérique (FAN) dans le sud de la France, à contre-courant de la délocalisation des emplois et de la taylorisation des tâches et contribue ainsi au rayonnement médiatique de la Région Occitanie. LFS adopte une perspective citoyenne, pédagogique, et s'attache à la valorisation du patrimoine culturel. Elle fait le choix d'une production artisanale, éthique et écologique, qui repose sur l'utilisation et l'amélioration, de logiciels libres. En s'investissant également dans la formation, les Fées Spéciales démocratisent l'accès à ces logiciels. »

Je ne détaillerai pas ici toutes les particularités du mouvement SCOP, des statuts de l'entreprise, des aspirations de gouvernance démocratique de ce type de structure. Cependant, il est utile de préciser quelques points pour comprendre l'approche de l'entreprise sur les logiciels libres.

Les sociétés coopératives de production se distinguent de leurs homologues « classiques » par plusieurs aspects juridiques. Elles sont légalement possédées à plus de la moitié par les salariés travaillant pour la structure. Ces derniers peuvent devenir associés (sociétaires) en achetant des parts sociales de l'entreprise. À ce titre, ils acquièrent un pouvoir de décision dans la gestion de la structure, à hauteur d'une voix par personne, contrairement aux autres sociétés, pour lesquelles le pouvoir décisionnaire est à hauteur du nombre d'actions possédées. Il existe une limite à la proportion des bénéfices reversés aux sociétaires, et inversement, une partie des bénéfices doit être réinvestie dans la structure, et une autre partie échoit aux salariés.

Les SCOP ont donc en commun une ambition d'utilité sociale, comme en témoigne la loi de 2014 relative à l'ESS [68]. On peut rapprocher cette ambition de la définition de *logiciel libre*, que nous donnerons plus loin (cf. chapitre I.2), qui se distingue de celle de l'open source (cf. section I.2.3). Retenons pour l'instant que le logiciel libre est à considérer, comme dans la définition de la Free Software Foundation [33], comme un mouvement à portée sociale, correspondant bien à l'ambition de la SCOP.

Dans les statuts de l'entreprise est inscrite la volonté d'utiliser « notamment les
logiciels libres », et cette volonté est généralement paraphrasée au sein de la structure en « autant que possible ». C'est d'ailleurs partant de cette volonté qu'a été initiée ma thèse, qui correspond assez justement au but de déterminer la place possible des logiciels libres dans l'animation.

## La recherche et développement aux Fées spéciales

La plupart des jeunes studios d'animation utilisent des techniques, processus et outils déjà connus, des programmes éprouvés dominant le marché et enseignés dans les écoles (cf. section II.2.1). À l'opposé de cette tendance, les Fées spéciales ont choisi dès leur création de mettre en œuvre une stratégie de recherche et développement (R&D*) visant à s'en affranchir.

Cette stratégie a plusieurs conséquences. Elle signifie la création de postes techniques en plus des postes de graphisme et de production. Ces postes ne sont pas forcément directement productifs, mais ils permettent de développer des outils sur mesure, d'apporter de nouvelles possibilités graphiques, ou d'augmenter la productivité des graphistes en automatisant une partie de leur travail.

La création de ces postes a un coût substantiel, mais la société estimait que l'utilisation de logiciels libres nécessiterait de la R&D dès le premier projet (cf. section III.1.1), et que les outils qui résulteraient de ces développements pourraient être valorisés et réutilisés dans de futurs projets. De fait, l'équipe chargée de la R&D est polyvalente et intervient à tous les stades de la fabrication. Cette polyvalence a conduit à parler d'équipe technique, plutôt que R&D, certaines missions étant plus proches du métier de TD* que de celui de chercheur.

## Rôle dans la structure

C'est dans cette équipe technique que j'ai été embauché par l'entreprise en convention industrielle de formation à la recherche (Cifre). Mes responsabilités à ce poste étaient donc multiples, centrées surtout sur la R&D*, mais aussi sur quelques tâches de graphisme, et demandaient donc une grande polyvalence. Le point commun de mes
attributions était donc leur côté technique, et on peut grossièrement les diviser en quatre.

— J'ai développé des outils graphiques au sein des logiciels de création, afin de faciliter la tâche des graphistes, en particulier dans les domaines du rig, de l'animation, et du layout.

— J'ai développé et utilisé des scripts* de pipeline* pour permettre des échanges de données.

— J'ai travaillé sur des tâches de graphisme pour des programmes audiovisuels, en particulier celles demandant des compétences techniques de scripting, de cartographie, d'animation procédurale, de conception assistée par ordinateur.

— J'ai enfin fait de l'administration et de la maintenance informatique.

Ces différentes expériences peuvent approximativement être résumées en un sigle : TD*<fnref n="3" />. Chacune d'elles demande d'utiliser des logiciels métiers spécialisés, et chacune a donc été l'occasion de tester des logiciels libres et leurs implications dans la production.

## I.1.2 Le pipeline de fabrication

Cette thèse étudie l'impact de l'utilisation et du développement de logiciels libres pour l'animation. Il est important dans ce contexte de définir la notion de pipeline*, qui est un élément fondamental dans la manière de fabriquer les œuvres animées, car le choix des logiciels et processus de développement a une grande influence sur le pipeline, et par extension, sur le travail de conception et de fabrication, et potentiellement sur les œuvres elles-mêmes.

Ce mot anglais faisait à l'origine référence aux tuyaux permettant d'acheminer des fluides sur de grandes distances (aqueducs, gazoducs, oléoducs, etc.). Il est ensuite passé dans le jargon informatique, pour désigner une manière de passer des données d'un processus à l'autre, avant d'être adopté dans le contexte de la création d'image.

La notion même de pipeline est malheureusement ambiguë, et peut désigner plusieurs principes connectés mais distincts. Flavio Perez, dans son mémoire de recherche sur le

<footnote n="3">3. Dans son mémoire de master [19], Pierre Lelièvre analyse en détail les différents rôles de ce poste dans les studios de post-production français.</footnote>
pipeline du film d'animation [20], analyse ces différentes définitions et leur emploi dans le contexte de l'animation 3D en France. Il ne parvient pas à en donner une seule définition, en raison de la multiplicité et de la confusion des emplois. Néanmoins, il parvient à la circonscrire à un champ d'intervention à travers deux définitions.

Dans la première définition, plus informelle, on entend par « pipeline » la chaîne de fabrication, le processus permettant de conduire une production depuis l'idée initiale jusqu'à l'œuvre définitive. Dans cette définition, on considère chaque étape, ou chaque département, comme un maillon de la chaîne. Le pipeline est donc une vue d'ensemble du processus de fabrication et de l'organisation du travail : comment le travail réalisé par une équipe est utilisé par l'équipe suivante ; comment une étape dépend d'une ou plusieurs étapes préalables. Cette définition est quasiment synonyme d'un autre terme anglais, le workflow, qui désigne plus explicitement le flux de travail, les tâches et opérations des graphistes, et leur interdépendance dans une production.

Une autre définition, qui étend la précédente, se concentre en plus sur la manière dont les données circulent d'un département à l'autre, quelles solutions techniques sont employées, quelles structures de données, quels logiciels, quelle architecture. On parle alors, en complément du workflow, du dataflow, le flux de données d'un pôle à l'autre. On considère par exemple dans cette définition l'organisation et le nommage des fichiers dans les dossiers de travail ; les formats de fichiers contenant les données, et leur organisation interne ; les programmes avec lesquels on les manipule, c'est-à-dire les logiciels de création mais aussi des programmes et scripts* uniquement dédiés à l'organisation elle-même et permettant de simplifier ou d'automatiser les tâches des graphistes. Cette définition est celle des TD* , dont le rôle est de concevoir, mettre en œuvre et maintenir une chaîne de fabrication optimale, en contrôlant chaque étape et surtout les passages (les tuyaux dans la métaphore plombière) entre les étapes 4 .

Dans tous les cas, la notion de pipeline est essentielle car c'est elle qui structure
la collaboration au sein d'une équipe. Si un graphiste isolé peut s'organiser comme
bon lui semble, ranger aussi bien ou aussi mal ses affaires qu'il l'entend, un studio

<footnote n="4">4. Une table ronde organisée en 2017 par l'Université de Lorraine aborde le pipeline du point de vue du TD, en particulier du *dataflow* [12].</footnote>
emploie par essence plusieurs personnes sur un même projet. Ces personnes doivent communiquer avec un langage commun et une organisation commune. Le pipeline est la formalisation, et la mise en œuvre de cette organisation. Il est à noter que même dans le cas où un graphiste serait seul à travailler sur un projet, le fait d'être au sein d'une structure implique que le travail opéré pour le projet pourra à l'avenir être réutilisé, et éventuellement, par quelqu'un d'autre. Il est donc nécessaire, même dans ce cas de figure, de suivre des règles établies dans le studio.

<figure><img src="image_2.png" /><figcaption>FIGURE I.1.1 – Schéma de la chaîne de fabrication d'un film d'animation. Les crédits photographiques des figures sont donnés dans la table des figures en fin d'ouvrage.</figcaption></figure>

On peut donc considérer le pipeline comme l'ensemble des techniques et étapes d'une production, et les liens entre elles. Je détaillerai ces différentes étapes indépendamment les unes des autres, c'est-à-dire sans donner d'exemple de * workflow * ni de * dataflow * global. D'autres ouvrages, comme la thèse de GEORGE-MOLLAND [18] ou l'ouvrage de MASSON [5] expliquent en détail ces processus, mais il est néanmoins utile de repréciser ici ce qu'on entend par chacune des étapes, et en particulier celles qui sont plus pertinentes dans le
contexte du studio où s'est déroulée ma thèse. Elles sont présentées ici séquentiellement selon un ordre logique, mais elles sont souvent en réalité traitées en parallèle, ou dans un ordre différent ou chaotique.

Les étapes ne sont même pas forcément clairement délimitées entre elles, mais ce qui les sépare en pratique est la validation par la hiérarchie, les responsables de la technique et de la direction artistique, et par le client. Une fois un élément (modélisation, cadrage, animation, plan*, effet, etc.) terminé, on évite de revenir dessus, car cela entraînerait d'incessants allers et retours, particulièrement avec des interlocuteurs perfectionnistes, et nuirait finalement à la production, et à son accomplissement dans les temps et dans le budget. Cependant, les allers et retours peuvent être au contraire prévus dans le budget, ou facturés au cas par cas. C'est souvent le cas dans des plus grosses productions, particulièrement de culture nord-américaine.

### I.1.2.1 Préproduction

#### Scénario et concept

La création d'une œuvre animée, que ce soit un film d'animation ou un autre médium*, commence généralement par l'élaboration d'une idée et d'une histoire. Tout comme dans les films en prise de vue réelle, le scénariste rédige un scénario plus ou moins détaillé pour avoir une idée précise du déroulement du film. C'est un document de travail contenant les dialogues et les indications de mise en scène nécessaires à la compréhension de l'action, telles que les mouvements des personnages, conditions d'éclairage, décors, costumes, etc. Ce document respecte en général un format normalisé<fnref n="5" /> et doit permettre d'estimer la qualité de l'histoire et de la narration avant la mise en scène, ainsi que la durée prévue du film.

Le scénario est l'occasion de faire un premier découpage technique du film en séquences*, donnant dès le départ une structure au film, et cette structure aura une

<footnote n="5">5. Le format normalisé, respecté avec rigueur dans le cinéma en prise de vue réelle, l'est beaucoup moins en animation, sans doute du fait que le médium est intrinsèquement plus plastique. Les auteurs d'animation joignent souvent des illustrations aux scénarios.</footnote>
influence sur l'organisation de la production. Cette structure peut évoluer en cours de production, selon les contraintes du projet, aussi bien artistiques que techniques et économiques. Une première version du scénario s'avère bien souvent trop complexe et coûteuse à réaliser, et il est alors modifié en accord avec la production pour rendre la fabrication plus faisable.

Le scénariste peut être un collaborateur du studio, de la maison de production, ou un indépendant. Dans la culture francophone du film d'auteur, le scénario est souvent écrit par le réalisateur 6. Il peut aussi souvent être coécrit par plusieurs personnes.

Selon les cas, l'étape de scénario peut également intégrer un dossier de recherche de financement, soit auprès des maisons de production, soit auprès des collectivités publiques susceptibles d'accorder des subventions.

Le scénario raconte l'histoire du film et sa narration. Dans le film d'animation, ce n'est pas le seul élément qu'il faut connaître pour qualifier le film avant sa fabrication. En effet, l'esthétique graphique est de première importance, et elle est généralement conçue au même moment. C'est l'étape du concept artistique, ou *concept art*. Elle est à la charge de l'équipe de direction artistique, et son but est de décider des codes graphiques qui serviront pour tout le film, et de concevoir des éléments concrets, comme l'apparence et le style des personnages et des décors. Les *concept arts* sont fondamentaux pour obtenir une cohérence graphique tout au long du film, mais ils fournissent également des documents servant de référence au cours de la production, tels que les model sheets* (cf. section I.1.2.2).

## Storyboard

Parfois appelé « scénarimage » en français, ce document de mise en scène est un développement graphique du scénario. Se présentant un peu comme une bande dessinée, avec des strips (bandes) de dessins illustrant l'action, il donne de précieuses indications de découpage. Il comprend lui aussi les indications de mise en scène du scénario (dialogues,

<footnote n="6">6. D'après des chiffres de la base de données IMDb, sur l'ensemble des longs métrages d'animation répertoriés pour lesquels les réalisateurs et scénaristes sont connus, plus de la moitié (55,3%) recense au moins une personne comme scénariste-réalisateur. Pour plus de détails, voir en annexe D.</footnote>
actions, etc.), ce qui permet d'avoir une idée de la durée nécessaire pour dire le dialogue du plan*. Le storyboard n'est pas exclusif au film d'animation, et on le trouve aussi souvent en prise de vue réelle, en particulier pour les films figurant beaucoup d'effets spéciaux.

À ce stade de la préproduction, le film est découpé en plan. Chaque plan est décrit par une ou plusieurs vignettes, selon sa complexité. Les mouvements de caméra (panoramiques, zooms, travellings, etc.) et les actions des personnages doivent être montrées avec assez de précision pour être interprétées fidèlement lors de la fabrication. La conception du storyboard nécessite des talents de mise en scène et des qualités graphiques. En général, le réalisateur le dessine lui-même ou travaille étroitement avec un ou plusieurs spécialistes, les storyboarders.

Un studio peut être seulement prestataire sur une partie d'un projet. Dans ce cas, le storyboard peut être fourni par l'auteur-réalisateur, et ne pas faire partie des documents de travail produits en interne. Par exemple, sur le film *Dilili à Paris* (cf. section III.1.1), le storyboard était dessiné sur papier par le réalisateur Michel Ocelot. À l'inverse, le studio peut s'occuper de développer le storyboard, comme ça a été le cas pour les films d'archéologie du musée de Lodève (cf. section III.1.3.1).

## Animatique

Une fois le film découpé en plans dans le storyboard, chaque vignette est photographiée et insérée dans un premier montage, constituant une vidéo appelée *animatique*. Ici, de nouvelles indications plus précises peuvent être ajoutées, principalement en ce qui concerne le minutage ou *timing* des plans et des actions. Le montage pourra évoluer pendant la fabrication, mais en principe les plans du film définitif auront sensiblement la même durée que ceux de l'animatique. On peut dire que le montage, dans le film d'animation, a lieu à cette étape, bien avant que les images ne soient fabriquées, et l'animatique est d'ailleurs souvent confiée à un monteur.

Si les dialogues ont été enregistrés avant le début de l'animatique, ils peuvent être utilisés pour fixer la durée des plans. Dans le cas contraire, des dialogues témoins tem-
poraires peuvent être utilisés en attendant la bande-son définitive.

C'est une étape cruciale pour plusieurs raisons. Elle permet de bien se rendre compte de la mise en scène avant de créer les plans, de les dénombrer, de quantifier le temps nécessaire d'animation et de fabrication, et d'estimer la quantité d'éléments à produire. Pour l'œil exercé, l'animatique est suffisante pour comprendre le film en tant que tel. Il faut garder en tête que dans le film d'animation, chaque seconde est fabriquée à partir de rien et est donc coûteuse, et qu'il convient d'animer les plans au plus juste du montage final, dans l'idéal sans rien couper de ce qui a déjà été fabriqué, et donc anticiper ce montage <fnref n="7" />. C'est donc un outil pour la mise en scène, mais également pour la production.

Layout

Le terme anglais de *layout* est un héritage direct d'un département des maisons de production de dessin animé traditionnel [4]. Dans ce contexte, il désignait l'acte de prévoir les mouvements de caméra, les cadrages, les actions des personnages et les minutages de manière extrêmement précise, à l'image près. On consignait ces décisions dans des documents standards, les feuilles d'exposition, qui servaient à toute la suite de la production : les décors, l'animation, la prise de vue. C'est à cette étape, toujours avant le début de l'animation, que se faisait la mise en scène définitive du film.

Dans l'animation 3D, les problématiques sont différentes. Les décors ne sont plus peints à la main, ni les personnages dessinés à chaque image. Néanmoins, le fond du problème reste le même. Il faut bien connaître la mise en scène avant même le début de la production pour savoir quels éléments (accessoires, décors, etc.) il sera nécessaire et suffisant de fabriquer, et combien de séquences*, plans* et images il faudra pour raconter l'histoire. C'est pourquoi le terme s'est transmis en 3D.

En image de synthèse, le layout demande, pour chaque séquence du film, de créer la scène 3D contenant l'action ; d'y placer un décor provisoire mais représentatif du cadre final ; d'y placer une ou plusieurs caméras dont les réglages (focale, position, orientation,

<footnote n="7">7. Cette affirmation est théorique, mais dans la pratique il arrive de couper des plans au montage, y compris des plans déjà finalisés. C'est particulièrement le cas sur des productions à gros budget, où la coupe de plans, voire le remaniement total du film à quelques mois de sa sortie, s'est déjà vue.</footnote>
animation) pourront être repris tels quels dans la version finale du film s'ils n'évoluent pas entre temps ; de placer des versions temporaires des personnages et accessoires dans les plans, et de les animer de manière schématique pour donner les indications de timing nécessaires. Une séquence est composée de plusieurs plans, et au stade du layout une scène 3D contient donc une caméra par plan.

Les opérateurs layout créent ces scènes 3D et génèrent des séquences vidéo à chaque étape de validation, avec la bande son si elle a été enregistrée. Ces séquences sont regardées par les équipes layout et par la réalisation et leur servent à discuter de la mise en scène et des éléments. Le rendu effectué à ce stade est loin d'être aussi travaillé que celui qui apparaîtra dans le film final, et il doit seulement être assez lisible pour comprendre la mise en scène. Il est donc nécessaire, contrairement aux rendus plus tard dans la production, d'avoir un rendu rapide plutôt que beau. La plupart des logiciels de 3D permettent d'obtenir ce type de rendu rapide, souvent appelé *playblast* dans les studios, d'après la terminologie de Maya.

### I.1.2.2 Fabrication

#### Modélisation

La modélisation est la première étape où l'on passe véritablement dans la production. Elle consiste à créer les éléments volumiques à partir des documents de préproduction, qu'il s'agisse de dessins de concept, de *model sheets*^8, ou de références photographiques. On peut la diviser en modélisation de personnages, d'accessoires, de décor et d'environnement^8, qui demandent chacune des compétences différentes, artistiquement ou techniquement : anatomie, botanique, mécanique, etc.

Plusieurs techniques de modélisation ont été développées au fil des ans. Dans les années 1990, la modélisation par NURBS était répandue. Elle permet de contrôler des courbes pour définir des surfaces. Son modèle mathématique permet d'obtenir une pré-

<footnote n="8">8. Les deux termes « décor » et « environnement » se recouvrent largement, mais l'environnement désigne plus souvent une partie plus lointaine et moins détaillée du décor, parfois réalisée en matte painting.</footnote>
cision arbitraire. Elle est toujours utilisée en CAO*, mais son usage en animation a pratiquement disparu. En 2019, la technique la plus utilisée est celle de la modélisation polygonale, qui consiste à définir des polygones dans l'espace. Ces polygones sont constitués de sommets, d'arêtes et de facettes, et leur ensemble au sein d'un objet est un maillage. Ce maillage définit la forme de l'objet. Il est souvent subdivisé, afin d'obtenir un plus haut niveau de détail et un maillage moins anguleux, tout en ayant une complexité limitée dans le contrôle du maillage.

La modélisation demande des compétences artistiques pour interpréter fidèlement les concepts et obtenir des objets crédibles ou expressifs, mais également des compétences techniques particulières, afin que la forme soit non seulement juste, mais techniquement exploitable par la suite. Il faut en particulier que l'ensemble des points, arêtes et faces qui composent le modèle, ainsi que la manière dont elles sont agencées (leur topologie), respectent des contraintes rigoureuses de densité, d'orientation des faces, de circulation des lignes de force. Par exemple, pour pouvoir animer un visage, il faut que le maillage soit suffisamment dense pour pouvoir se déformer, mais aussi que les lignes qui composent sa surface suivent les creux et les bosses, et celles selon lesquelles il sera déformé. Pour plisser le front, il faut des rides.

De plus en plus, les modeleurs, en plus de manipuler directement les éléments du maillage, peuvent utiliser une autre technique de modélisation, la sculpture numérique ou *sculpt*, qui permet de manipuler la forme de l'objet de manière plus intuitive, à l'aide d'interfaces rappelant la pratique du modelage. Ces techniques permettent dans une large mesure de s'affranchir des détails techniques de la modélisation au cours de la création, en particulier la topologie, pour se concentrer sur la forme. Une fois cette forme validée, on pourra se préoccuper de topologie dans une étape à part, la retopologie.

## Rigging

Le rigging est une tâche très technique au cours de laquelle on prépare les personnages à l'animation. Contrairement au dessin animé « traditionnel », l'animateur 3D ne dessine pas chaque image, mais doit déplacer et déformer le personnage modélisé dans
une scène virtuelle. Pour déformer le personnage, qui peut être un objet géométrique composé de milliers ou de millions de points, il faut déplacer chacun de ces points. Il n'est pas réaliste d'espérer obtenir un mouvement fluide en déplaçant autant de points manuellement, à chaque image. On crée donc, pour faciliter ce travail, un ensemble de contrôleurs qui seront une interface entre l'animateur et le modèle.

Le rigging consiste d'abord à créer et placer des objets virtuels qu'on appelle des os (bones) dans le personnage. Ils sont grossièrement analogues aux os réels en ce qu'ils sont en général invisibles et servent de structure pour la locomotion<fnref n="9" />. Cette analogie, quoique pratique, s'arrête là, car les os virtuels ont des propriétés toutes différentes de leurs homologues biologiques. D'abord, comme les autres objets virtuels, ils n'ont pas de propriétés physiques intrinsèques : pas de masse, pas de résistance mécanique, pas même de volume à proprement parler.

Les propriétés qui définissent les os virtuels sont géométriques et logiques. Grossièrement, un os seul est défini par une transformation dans l'espace, qui définit la place qu'il occupe au repos. Le squelette virtuel est constitué d'un ensemble d'os reliés entre eux par des relations hiérarchiques de parent à enfant, ou par d'autres contraintes.

On trouve plusieurs types d'os dans un squelette virtuel. Le premier est le contrôleur.

Les contrôleurs sont les os avec lesquels l'animateur interagit. Ils flottent à la surface ou autour des parties constituant le personnage et devant être animées. Ils correspondent à des unités logiques de cinématique. Par exemple, on trouvera communément un ou plusieurs contrôleurs pour le torse, pour le bras, l'avant-bras et la main, etc. En déplaçant ou en tournant un contrôleur, la partie du corps qui lui correspond y est « attachée » avec la technique du skinning*, et se déplace en même temps. L'animateur peut les saisir et les déplacer pour mouvoir le personnage.

Souvent, l'histoire est plus complexe. Les contrôleurs basiques décrits précédemment ne suffisent toujours pas à obtenir les mouvements souhaités, ou sont d'utilisation encore trop complexe. On peut alors créer des mécanismes qui ajouteront des fonctionnalités au personnage. Par exemple, il faut plusieurs os pour créer une cinématique inverse<fnref n="10" />.

<footnote n="9">9. Manière par laquelle les animaux se déplacent.</footnote>

<footnote n="10">10. Technique qui facilite l'animation de la marche ou de la préhension d'objets, en permettant de</footnote>
De même, un rig facial est complexe et nécessite de nombreux os.

Les « mécanismes » sont des objets qui servent à améliorer le mouvement du personnage, mais sont en quelque sorte « bas niveau », c'est-à-dire qu'ils ne sont pas censés être utilisés directement par l'animateur. Ils sont donc reliés, asservis aux contrôleurs, pour fournir à l'animateur un accès facile à leurs fonctionnalités.

On regroupe les os, qu'ils soient des contrôleurs ou non, dans un objet ou groupe d'objets que l'on désigne en général sous les noms d'armature, de squelette, ou de rig, comme dans l'animation de marionnettes en stop motion.

## Shading

Le shading, qui se fait souvent en parallèle du rigging, consiste à paramétrer le comportement optique des matériaux à la surface des objets. Dans le monde réel, chaque matériau réagit différemment à la lumière. Un matériau est par exemple plus sombre quand il absorbe une plus grande partie de la lumière incidente, ou plus clair s'il la renvoie. Les métaux renvoient une partie de la lumière de manière spéculaire, concentrée, tandis que des matériaux comme le plâtre ou le papier la renvoient de manière diffuse, dans toutes les directions ; le verre et l'eau transmet une partie de la lumière qu'il reçoit, etc. Pour obtenir une simulation réaliste de ces phénomènes, il faut indiquer au moteur de rendu (voir plus bas) quelle proportion de la lumière reçue par une surface est réémise dans chacun de ces composants, et quelles couleurs ont les surfaces en chaque point.

## Surfacing

Une des manières pour spécifier ces couleurs et comportements de la lumière est de peindre les informations à la surface des objets. Pour cela, les graphistent préparent la « surface » des modèles en la dépliant comme un patron de couture (dépliage UV)<fnref n="11" />.

<footnote>déplacer seulement l'extrémité d'un membre, plutôt que toutes les parties qui le constitue. Par exemple, on pourra positionner une main à l'endroit souhaité, plutôt que de devoir faire tourner les articulations de l'épaule, du bras et du poignet.</footnote>

<footnote n="11">11. L'étape du dépliage UV est de plus en plus souvent abandonnée, grâce aux possibilités des programmes récents de peindre « directement » sur la surface de l'objet 3D, plutôt que dans un programme de peinture, sur une image qui constituera la texture.</footnote>
Ils y appliquent ensuite des couleurs et des textures (cartes, ou *maps*) décrivant le comportement de la lumière. Avec ces cartes, les textures, il est possible de créer toutes sortes de matériaux. On distingue en général les matériaux réalistes, imitant le comportement physique des surfaces, des matériaux expressifs, plus plastiques et sans souci de réalisme. Par exemple, les rendus de type cartoon, c'est-à-dire évoquant l'esthétique du dessin animé traditionnel, entrent dans la catégorie des rendus expressifs.

Une autre manière de procéder est d'utiliser des algorithmes pour générer les textures plutôt que de les peindre à la main. On parle alors de textures procédurales. Cette technique permet d'accélérer la création de certains types de textures, mais n'est pas incompatible avec une peinture manuelle. Ce type de texture se développe beaucoup car il permet un prototypage rapide des textures, mais surtout leur réutilisation pour différents assets* 3D. Dans ce paradigme, popularisé notamment par les programmes Substance Painter et Substance Designer [54], il est relativement aisé d'appliquer à la surface, non plus des textures représentant une composante de la surface, mais directement des matériaux (métallique, plastique, etc.).

## Animation

Étape la mieux connue du grand public, l'animation consiste, presque littéralement, à insuffler la vie aux personnages. Pour cela, l'animateur fait bouger les personnages au cours du temps, à l'aide des contrôleurs mis en place lors du rigging. On leur donne une succession de poses qui doivent être correctement placées dans l'espace, et correctement minutées, c'est-à-dire espacées dans le temps. On parle communément de *timing*.

Il faut considérer le volume, la gravité, l'inertie, la vitesse et l'accélération, le comportement physique des objets, pour finalement arriver à l'intention des personnages, à un mouvement expressif, transmettant au public l'émotion souhaitée. L'animation est proche de la comédie<fnref n="12" />, en ce que l'animateur doit interpréter son personnage de manière crédible pour que le public puisse s'y identifier. Une différence notable est la tempora-

<footnote n="12">12. Comédie étant entendue au sens de « jeu d'acteur » et non de « forme d'expression destinée à faire rire ».</footnote>
lité de la création : contrairement à la comédie, l'animation n'est pas « en temps réel », mais chaque phase du mouvement est construite patiemment, membre par membre, pose par pose, parfois image par image. Les animateurs 3D créent de l'ordre d'une à dix secondes d'animation par jour, selon le type de média, le style d'animation, et la qualité souhaitée (souvent imposée par des décisions budgétaires).

L'animation peut se faire en plusieurs phases, de plus en plus précises. On crée d'abord les positions les plus importantes et représentatives du mouvement et de la silhoudette (poses clefs ou blocking). On ajoute ensuite des positions intermédiaires (breakdowns), décomposant un peu plus le mouvement, et on termine par les intervalles, qui permettent d'obtenir une animation fluide. Chaque phase peut faire l'objet d'une validation pour vérifier qu'elle est conforme à la narration et à l'esthétique de l'œuvre.

## Effets spéciaux

Que ce soit dans les films en prise de vue réelle ou dans les films d'animation, en 2D ou en 3D, on ajoute souvent à l'image des effets <fnref n="13" /> spéciaux. Ces effets se répartissent en effets visuels et effets de personnages <fnref n="14" />.

Les effets visuels, réalistes ou non, simulent des phénomènes dynamiques, ou renforcent l'image et la narration. C'est un champ très vaste, allant de l'ajout d'effets de fumée dans un dessin animé à la création complète d'un environnement réaliste dans un film tourné sur fond vert ; du maquillage numérique d'un comédien à la simulation réaliste d'un raz-de-marée ou d'un phénomène astronomique.

Dans le dessin animé 2D, il s'agit tout comme pour l'étape de l'animation, de dessiner l'effet image par image, mais les animateurs FX se concentrent sur le phénomène représenté plutôt que sur les personnages.

Dans l'animation 3D, on utilise des logiciels spécialisés pour simuler les phénomènes

<footnote n="13">13. On emploie souvent l'abréviation « FX » pour parler des effets spéciaux, car elle se prononce presque pareil en anglais que le mot « effects ». On peut ainsi parler de SFX (*special effects*) pour les effets spéciaux, de VFX (*visual effects*) pour les effets visuels, et de CFX (*character effects*) pour les effets de personnages.</footnote>

<footnote n="14">14. Ces deux types d'effets sont généralement créés dans des départements distincts utilisant des processus différents, mais leur finalité étant similaire, ainsi que le stade du pipeline où ils interviennent, je les place ici dans un même groupe.</footnote>
physiques dans le même espace que celui de l'action, mais ici encore l'ajout des effets
spéciaux se fait généralement après l'animation principale. En 3D, on trouve aussi, en
plus des effets visuels, les effets de personnages (CFX, *Character Effects*), dont le but
est de simuler les vêtements, cheveux et poils, c'est-à-dire des éléments réagissant à
des forces physiques telles que la gravité et les collisions, selon leurs charactéristiques
internes comme la masse et la rigidité.

Cette thèse évoque peu les logiciels libres permettant de créer des effets dynamiques
3D, car ce sont globalement les mêmes que les logiciels d'animation <fnref n="15" />.

Éclairage et rendu

Une fois que tous les éléments du plan* sont prêts (les caméras sont cadrées, les personnages, les décors et les accessoires sont modélisés et animés), on procède à leur éclairage et à leur rendu.

L'éclairage est une étape où le graphiste spécialisé, le lighter (éclairagiste) place des
sources de lumière virtuelles dans la scène 3D. Ce travail a le même but que celui de
l'éclairagiste de théâtre ou de cinéma, mais ses techniques sont propres à l'animation 3D
car il est possible de créer des éclairages qui seraient impossibles dans la réalité.

Le rendu est une étape de calcul au cours de laquelle les données 3D sont transformées
en images, par des méthodes de simulation du comportement de la lumière.

Le moteur de rendu est le programme chargé de réaliser cette opération. Il prend
en entrée, pour chaque image, les données géométriques de la scène et une description
des matériaux, des surfaces et des lumières, et utilise des simulations d'illumination
plus ou moins inspirées de l'étude scientifique de l'optique, du transport de la lumière,
pour générer des images. C'est un des domaines de l'image de synthèse faisant l'objet
du plus de recherches, dans les entreprises comme dans les universités, et de nouveaux
algorithmes sont fréquemment intégrés dans les logiciels de création.

On distingue souvent le rendu photoréaliste du rendu non-photoréaliste ou stylisé.

<footnote n="15">15. Il existe des logiciels dédiés uniquement aux effets spéciaux, mais presque tous les logiciels de création 3D* proposent aussi des modules de simulation d'effets spéciaux plus ou moins complets. Dans les logiciels libres, Blender permet de faire plusieurs types de simulations physiques.</footnote>
Le premier cherche à reproduire la manière dont les caméras physiques capturent les images, afin de tromper nos yeux pour nous faire croire à l'existence des objets simulées en image de synthèse. Le rendu non-photoraliste, quant à lui, comprend tout le reste, et en particulier les rendus « cartoon », qui ne cherchent pas à être conforme aux habitudes photographiques, mais à véhiculer efficacement les intentions et émotions, à travers l'apparence plastique des images. Formellement, ils imitent souvent des outils traditionnels : crayon, plume, aquarelle, etc.

Les images rendues peuvent être séparées en couches afin de faciliter l'intégration : les éléments sont répartis en couches (décor, arrière-plan, personnages, etc.), et par composante de lumière (albédo, lumière diffuse, lumière spéculaire, ombre, etc.).

### I.1.2.3 Post-production

#### Compositing

Les couches précédemment rendues ne sont pas les images qui apparaîtront dans le film, mais constituent un matériau de base qui sera assemblé, retraité, amélioré dans une étape appelée *compositing*. On peut y ajouter des effets « 2D » pour rendre l'image plus conforme aux demandes artistiques. Par exemple, il est fréquent dans les films de style photoraliste de trouver des effets de particules ou d'aberrations optiques (déformation de lentille, aberrations chromatiques, facteur de flare, etc.). De manière générale, toute altération de l'image s'effectue à cette étape. Dans les films en prise de vue réelle et à effets spéciaux, c'est aussi là que les éléments virtuels sont intégrés aux images filmées, en faisant en sorte que le raccord soit invisible à l'image.

L'étalonnage ou *grading*, quant à lui, est une étape de retouche colorimétrique et d'harmonisation finale, en vue de coller au plus prêt aux intentions colorées de la direction artistique, et éventuellement aux spécifications techniques des diffuseurs. Elle permet par exemple, dans une séquence* passant du jour à la nuit, d'harmoniser des plans* aux couleurs disparates, et de créer une continuité entre eux.
## Son

Le son est souvent moins considéré que l'image dans l'animation, mais il joue un rôle primordial dans l'esthétique d'un film. C'est la moitié de l'expression « audiovisuel ».

Cette négligence est assez logique dans la mesure où le son est plutôt complémentaire qu'intrinsèque à la création d'image, et demande des savoirs et compétences bien distinctes.

Je ne connais presque rien à ce domaine, ni dans son esthétique, ses enjeux narratifs et suggestifs, ni dans ses techniques de création. De plus, dans les œuvres sur lesquelles j'ai travaillé professionnellement et personnelment, je n'ai pas été en contact avec les personnes chargées du son.

Je me permettrai donc, dans cette thèse, de continuer à négliger cette partie essentielle.

## Mastering

Souvent intégré au compositing et rarement considéré comme une étape de fabrication à part entière par les studios d'animation — du moins les petits — le *mastering* consiste à générer, à partir des images et de la bande son définitives, les fichiers livrables au client ou au diffuseur. En général, on confie le mastering à une entreprise spécialisée, un laboratoire cinématographique. Cependant, les studios sont parfois amenés à s'en charger eux-mêmes, notamment pour les projets à petit budget et en vidéo.

Dans ce cas, il est fondamental de respecter strictement les spécifications de diffusion, que ce soit pour le cinéma, la vidéo, la télévision, Internet, la muséographie, etc. Dans le cas contraire, la livraison serait certainement refusée par un client exigeant, ou bien être diffusée telle quelle, en courant le risque que la diffusion soit altérée, ou non conforme au résultat escompté, ou même impossible à diffuser.

Cette étape nécessite de bonnes connaissances techniques des formats de fichiers, conteneurs et codecs, d'espaces colorimétriques, de compression, etc. Dans les petits studios obligés de s'occuper de cette étape, on préfère souvent ne pas trop y penser pendant la production, et on se réveille le jour de la livraison pour lire la documentation, tester
les solutions et résoudre les nombreux problèmes qu’on peut rencontrer. Ces problèmes peuvent être anticipés en ayant connaissance des spécifications.

### I.1.2.4 Gestion d'assets et suivi de production

Toutes les étapes décrites ci-dessus sont à peu près distinctes les unes des autres. Les graphistes sont en général spécialisés dans une ou deux d'entre elles et se concentrent, au cours d'un projet, sur une ou quelques tâches restreintes. Mais il existe aussi des postes transversaux, qui interviennent à toutes les étapes de la production, et s'assurent de sa bonne marche.

On peut citer les postes liés à la production (directeurs, chargés, coordinateurs et assistants de production), les postes de supervision, et les postes techniques : la R&D*, et les TD*, qui sont souvent distincts. Si tous ces postes doivent très bien connaître l'ensemble du workflow pour faire un suivi efficace, les TD doivent également connaître le dataflow (cf. section I.1.2), car ce sont en général eux qui le mettent en place.

Rappelons que si le but final d'un projet d'animation est d'avoir une œuvre prête à être diffusée, composée de nombreuses images et d'une bande son, les étapes pour y parvenir demandent la création d'un grand nombre d'éléments, représentés par des fichiers informatiques et plus rarement par des documents physiques. Ainsi, il faut conserver et organiser les scénarios, dessins de concept, storyboards et animatiques. De même, on crée de nombreuses versions des décors, personnages, accessoires et scènes 3D pour chaque plan*, et à chaque étape de production, on génère des images rendues intermédiaires, des fichiers de compositing et de montage, et finalement, les masters. Tous ces fichiers peuvent représenter une somme colossale de données, et une grande complexité. Il faut donc structurer l'organisation de la production. Pour ce faire, plusieurs outils sont nécessaires.

Le premier outil est le gestionnaire d'éléments, ou *asset*\* *manager*<fnref n="16" />. Il s'agit d'un programme spécialisé qui permet d'abstraire et de consolider la gestion des versions, et le

<footnote n="16">16. On parle volontiers en français de gestion d'assets, et on emploie souvent même l'expression anglaise : asset management.</footnote>
passage d'une variation à l'autre. Par exemple, dans un pipeline* primitif, la production
se ferait du début à la fin dans une même scène 3D. Il apparaît rapidement que cette
façon de faire est limitée pour un seul graphiste, et a fortiori ingérable en collaboration.
On peut donc créer des versions à chaque modification majeure, en faisant *Enregistrer
sous...*, et en renommant le fichier en cours, soit avec un numéro différent, soit carrément
un nouveau nom, avec par exemple un suffixe pour le département. C'est un début
d'organisation des fichiers selon une nomenclature.

Plutôt que de faire créer des versions manuellement aux graphistes travaillant sur un
même projet, l'asset manager permet de faire ces opérations de renommage sans risque
de se tromper. Mais l'asset manager peut aller plus loin, en évitant par exemple à plu-
sieurs personnes travaillant dans le même département de travailler sur le même fichier
en même temps, au risque d'écraser le travail de l'autre. Pour cela, l'asset manager met
en œuvre un système de verrouillage des fichiers. C'est également lui qui sera chargé de
créer les variations pour les différents départements : un plan* donné du film gardera
son nom tout au long de la production, et plusieurs variations seront créées, pour chaque
étape. Par exemple, le plan 1 de la séquence* 1 aura successivement une variation pour
le layout, une pour l'animation, une pour le shading, etc. Et pour chacune de ces varia-
tions, plusieurs versions existeront, pour garder une trace des changements effectués, et
éventuellement pouvoir revenir en arrière en cas de changement d'avis ou de corruption
des données.

L'asset manager peut également être chargé, à chaque nouvelle version, d'exécuter
automatiquement des tâches. Par exemple, vérifier que la nomenclature d'une scène est
conforme à la spécification pour le projet, ou rendre des prévisualisations des plans et
les envoyer aux superviseurs pour validation.

Ces différents problèmes peuvent sembler abstraits, mais ils sont omniprésents en
production, et l'automatisation est indispensable.

Contrairement aux suites de création, dont une poignée se partage la quasi-totalité
du marché, il existe bien quelques solutions de gestion d'assets, mais les studios créent
généralement leurs propres outils internes. Le directeur technique des Fées spéciales Fla-
vio Perez explique ainsi les raisons pour lesquelles les studios développent leurs propres
outils :

« C'est bien le manque de solutions commerciales qui a poussé les studios à écrire leurs solutions. Manque de solutions lié à l'impossibilité de formaliser universellement le pipeline.

« Il existe aujourd'hui des solutions mais adoptées timidement : Elara de Foundry n'est encore qu'un concept en circuit fermé ; Shotgun Toolkit est sûrement le plus utilisé ; Tactics ne perce pas malgré le fait qu'il soit ancien.

« On n'utilise plus vraiment les solutions du jeu vidéo (type Alienbrain ou Perforce). Jarvis est une solution d'automatisation mais pas vraiment un asset manager. Est sorti de terre il y a peu Prisme et puis Kabaret [cf. section III.5.1.2] qui est un peu à part (un framework* pas du tout clé en mains) ; Avalon [...].

« Mais on a presque fait le tour et une grande majorité de ces solutions ont moins de 5 ans, c'est très récent donc.<fnref n="17" /> »

Il est donc particulièrement intéressant d'étudier les possibilités du logiciel libre dans ce domaine, car les studios peuvent gagner à avoir des outils en commun, le plus standard possible, et que la tâche de les développer ne soit pas redondante. En contrepartie, il faut garder à l'esprit que chaque studio, et chaque projet, est différent, et qu'un outil doit être suffisamment souple pour s'y adapter : l'inverse est rarement possible, dans la mesure où un projet d'animation a en général des singularités impossibles à prévoir.

Le deuxième outil nécessaire à la structuration des projets est le suivi de production. C'est la tâche du chargé de production, qui consiste à élaborer et surveiller le calendrier de production en fonction du budget et de l'avancée quotidienne du projet, et à répartir les tâches entre les graphistes pour optimiser le travail. Une partie du travail de chargé de production se fait en collaboration avec les superviseurs d'équipes, afin de coordonner le travail des graphistes. C'est également le chargé de production qui communique avec le client, pour programmer les validations, recueillir les corrections (retakes*), et les distribuer aux graphistes. L'outil fondamental de visualisation de la production est le

<footnote n="17">17. Entretien semi-directif avec Flavio Perez, 6 février 2019.</footnote>
tableur, permettant d'établir, confronter et projeter les chiffres pour que la production soit la plus fluide possible.

Puisque ce travail repose en partie sur les chiffres, le chargé de production doit recueillir les informations à jour de tout le projet, presque en temps réel. Pour cela, il établit un dialogue permanent avec les superviseurs, graphistes et clients. C'est indispensable pour avoir des informations qualitatives sur l'avancée du projet, mais il est également important de disposer d'informations quantitatives : combien de plans* ont-ils été fabriqués cette semaine pour cette séquence* ? combien de décors, de personnages ? combien de secondes d'animation ? combien en reste-t-il ? quelles retakes sont prévues, et quel temps prendront-elles ? quel était le délai initial prévu, et comment celui-ci évoluera-t-il en fonction de l'avancée en cours ? faut-il embaucher des graphistes pour être dans les temps ? Le chargé de production est amené à répondre à ce genre de questions, et une méthode efficace pour recueillir les informations permettant d'y répondre est d'interroger une base de données construite collaborativement par les graphistes, les superviseurs et lui-même. Cette base de données est le logiciel de suivi de production.

Ce logiciel permet donc le suivi par le chargé de production, mais aussi la communication au sein du studio. Par exemple, une fois que le chargé de production a assigné des tâches aux graphistes, ceux-ci peuvent se connecter au logiciel et voir chaque jour quelles tâches ils doivent réaliser, et indiquer en retour le statut de la tâche, selon qu'elle soit seulement prévue, en cours de fabrication, en attente de validation par le superviseur ou le client, ou terminée.

Il permet à tous les intervenants de visualiser l'avancement du projet, en générant des tableaux récapitulatifs. Il peut également servir pour la validation par le client, en affichant par exemple pour chaque séquence en cours, la dernière version de la vidéo, et en entrant directement les critiques, qui pourront être ensuite consultées par les graphistes qui traiteront les retakes.

Ce logiciel est donc aujourd'hui quasiment indispensable pour qu'une production d'une certaine envergure se déroule bien. Il demande de la rigueur de la part de tous, du côté artistique et du côté production, pour remplir correctement les informations au
quotidien. Mais, correctement utilisé, il soulage le chargé de production d'une partie de
son travail de recueil des informations.

Le logiciel de suivi de production peut aussi être connecté au gestionnaire d'assets,
afin que les informations entrées dans l'un soient copiées dans l'autre. Par exemple, si un
graphiste a terminé une version d'un plan et la publie dans le gestionnaire d'assets, cette
publication peut être « poussée » dans le suivi de production en même temps qu'une
image ou une vidéo, et des informations à jour sur le plan, telles que sa durée, les assets
utilisés, etc.

Tout comme les gestionnaires d'assets, il existe des solutions commerciales de suivi
de projet, et certains studios développent aussi leurs outils internes.

Conclusion

Les studios d'animation sont des sociétés particulières, autant dans leur activité que
dans leur organisation.

Ce chapitre a permis de montrer ces particularités en abordant les différentes facettes
opérationnelles des studios, en prenant comme référence le studio Les Fées spéciales :
les types de contenus sur lesquels ils sont amenés à travailler, le rôle de la R&D* dans la
structuration de la chaîne de fabrication. Afin de mieux définir mon champ de recherche,
j'ai exposé mon rôle en tant que TD* au sein d'une telle structure, et la manière dont
j'ai abordé autant des aspects techniques qu'artistiques.

J'ai également donné une vue d'ensemble du processus complexe de fabrication, de
la préproduction à la post-production, demandant des compétences techniques et artis-
tiques très variées, et utilisant plusieurs logiciels métiers spécialisés à chaque étape.
# Chapitre I.2

## Le logiciel libre

### Introduction

Les questions d'informatique sont centrales dans la création numérique. Par définition, le point commun de tout le champ de la création numérique est de s'appuyer sur l'outil informatique comme matériau de création ou comme médium de présentation. L'outil informatique est tellement omniprésent dans les studios d'animation qu'il est devenu une évidence : on ne fait pas de film sans ordinateur.

Depuis l'écriture du scénario jusqu'à la livraison des masters, toutes les étapes peuvent se faire numériquement, en utilisant des programmes spécialisés. Ces programmes complexes doivent permettre de simplifier ou d'automatiser des tâches, et se plier à la créativité des graphistes. Pour cela, les logiciels doivent tenir compte des besoins de ces derniers, et être conçus exprès pour des applications graphiques.

On trouve dans le commerce nombre de ces logiciels, dont certains sont presque omni-présents dans les studios d'animation<fnref n="1" />. La plupart de ces logiciels sont créés, développés et commercialisés par des éditeurs, et on les appelle « propriétaires ». Cela signifie que leur code source* n'est pas accessible publiquement, et que les utilisateurs n'ont pas le droit d'y accéder et de le modifier. Cette interdiction est généralement vue comme la norme, puisque c'est le cas dans tous les secteurs de l'informatique. On la considère

<footnote n="1">1. Voir la section II.2.1 sur l'aquisition des logiciels existants.</footnote>
nécessaire pour que les éditeurs puissent vendre leurs programmes, être rémunérés pour leur développement, et continuer à les améliorer et à les corriger.

Un autre modèle de développement et de mise à disposition des programmes informatiques existe : celui des logiciels libres. Ces logiciels permettent par définition aux utilisateurs de les utiliser comme bon leur semble, d'étudier leur code source pour comprendre comment ils fonctionnent, de les modifier, et de les redistribuer. Comme dans beaucoup de secteurs utilisant l'informatique, il existe des logiciels libres spécialisés dans celui de l'animation.

Les logiciels libres abordés dans cette thèse peuvent être soit des applications telles que Blender, Krita, etc., ou des scripts* et add-ons*. En d'autres termes, on s'intéressera de près aux méthodes, environnements, algorithmes et implémentations permettant à la production d'œuvres de procéder, et à l'artiste d'exercer ses talents.

Nous ferons donc dans ce chapitre un rapide tour de ce que sont les logiciels libres, dans la mesure où ils concernent la création artistique dans le contexte de l'animation. En effet, si leur histoire est encore récente dans la création artistique, cette histoire est riche et complexe. De nombreux concepts proviennent des champs de l'informatique, du droit, en particulier de la propriété intellectuelle, et il convient de les définir correctement.

## I.2.1 Historique

Le logiciel libre a une histoire technique, idéologique et sociale complexe et cette thèse n'a pas pour vocation de l'évoquer dans son intégralité, mais seulement de donner les indications suffisantes pour en comprendre les enjeux pour l'animation, autant dans l'utilisation que font les studios de logiciels et formats libres, que dans les modalités selon lesquelles ils peuvent développer et publier eux-mêmes du code sous licence libre.

### I.2.1.1 Le logiciel dans le milieu universitaire

À l'origine de l'informatique, les programmeurs étaient des savants, des mathématiciens, des logiciens, des ingénieurs. Ils ont conçu les bases théoriques de l'informatique
selon les mêmes principes que ceux de la recherche, en favorisant une libre circulation des
idées à travers la publication d'articles, d'ouvrages, et à travers leurs correspondances
et leurs conférences<fnref n="2" />.

Au départ, les ordinateurs sont inextricablement liés aux programmes, et l'on conçoit
les machines pour une application précise. Dès l'invention d'ordinateurs capables d'exé-
cuter n'importe quel programme <fnref n="3" />, on peut échanger des supports contenant ces pro-
grammes, qu'il s'agisse des sources du programme imprimées, de cartes perforées, ou
de supports plus modernes comme les disques, ou plus tard la transmission directe en
réseau. Avant l'arrivée de la micro-informatique et la démocratisation de l'informatique
dans les entreprises, puis auprès du public, les ordinateurs sont rares et coûteux, et les
programmes livrés avec les machines ne sont pas considérés comme des biens marchands
à part entière. Ils sont souvent co-développés par les clients et les constructeurs, qui
leur livrent directement les codes sources. La circulation des programmes continue donc
à se faire comme avant : librement, sans volonté de les rendre inaccessibles. Jusqu'aux
années 1970, les informaticiens des universités de sciences font circuler les programmes
auprès des collègues, et par extension, ils les corrigent, les améliorent, et les redistribuent
à leur tour. Cette émulation contribue à une évolution rapide de l'informatique.

**I.2.1.2 Privatisation et commercialisation**

À la fin des années 1960, la situation change quand le plus gros constructeur infor-
matique, IBM, est affecté par une décision de justice très médiatisée, initiée par l'admi-
nistration états-unienne afin de faire appliquer la législation sur la concurrence, la « loi
antitrust ». En effet, la pratique d'IBM de livrer ses logiciels en même temps que ses
machines est jugée anticoncurrentielle dans un contexte où la société domine le marché
de l'informatique. La décision force donc la société à séparer la facturation du matériel
et du logiciel, et le reste des constructeurs s'engage dans cette voie [9]. Le logiciel devient
un bien commercial en soi, bien qu'il soit encore livré à cette époque sous forme de code

<footnote n="2">2. À l'exception des nombreuses innovations militaires, qui sont par nature confidentielles.</footnote>

<footnote n="3">3. Dans la limite de ses capacités de mémoire et de puissance de calcul.</footnote>
source*.

C'est à partir des années 1980 que les logiciels peuvent faire aux États-Unis l'objet d'une protection par le copyright, y compris dans leur version compilée. Le contrôle de la distribution des logiciels revient donc entièrement, comme pour les œuvres de l'esprit qui les ont précédés, à leurs auteurs. Le marché explose dans les années qui suivent, et le logiciel propriétaire devient en moins d'une décennie le modèle de distribution standard. La conséquence est que le logiciel, qui était jusqu'alors une affaire de spécialistes et manipulé presque exclusivement par des informaticiens, devient une commodité et un secret industriel jalousement gardé des éditeurs, et protégé légalement. D'autres juridictions suivent rapidement le mouvement, et dès 1985 la loi française considère les logiciels comme des œuvres de l'esprit, protégées par le droit d'auteur.

### I.2.1.3 Richard Stallman et les valeurs de partage

Revenons en arrière, au milieu des années 1970. Dans les laboratoires des universités techniques des États-Unis, en particulier au Massachusetts Institute of Technology (MIT), existe depuis plusieurs années une culture, celle des hackers. Il faut entendre ce terme comme « bricoleur, bidouilleur » et pas du tout comme « pirate » [8]. Les hackers considèrent leur pratique comme un jeu : démonter, étudier, comprendre, modifier, remonter, améliorer... Le terme s'est étendu à l'informatique, et les hackers se posent des problèmes comme des énigmes à résoudre, et redistribuent le résultat sans y penser, comme on donnerait la réponse d'une charade à un copain. Dans ce contexte, il leur semble d'autant plus normal de pouvoir accéder aux sources des programmes qu'ils utilisent, y compris ceux des constructeurs.

L'invention du logiciel libre est due à Richard Stallman [1, 8], qui, devant le développement du logiciel « propriétaire » et la protection du copyright dans les années 1980, regrette l'esprit de libre échange qu'il a connu lorsqu'il étudiait et travaillait au MIT. L'anecdote dit qu'un jour qu'une imprimante dysfonctionnait, il aurait été surpris de ne pas pouvoir la réparer en modifiant les pilotes. En effet, jusque-là les constructeurs avaient toujours rendu les pilotes disponibles. Il s'est senti ce jour-là à la merci
du constructeur, privé de sa liberté de réparer un appareil qu'il avait acquis légalement,
d'où l'idée qu'un logiciel qu'on ne peut pas réparer et améliorer soit « privateur ». À
lui qui avait connu une situation différente, cette pratique semblait intolérable.

Conformément à son esprit et à sa culture hacker, et dans sa capacité d'excellent
développeur logiciel, Stallman a donc cherché un moyen de contourner les lois du copy-
right afin de pouvoir créer et diffuser des programmes qui ne pourraient pas retirer aux
utilisateurs leurs libertés d'utiliser, d'inspecter, de modifier et de redistribuer le code.
Il travaille au milieu des années 1980 sur le projet de système d'exploitation (*operating
system*, OS) libre GNU<fnref n="4" />, comprenant tous les programmes nécessaires pour remplacer
les OS propriétaires. Il crée dans ce cadre les premières licences libres pour les pro-
grammes qu'il écrit et distribue pour le projet GNU. Bientôt, les différentes licences des
programmes sont unifiées en une licence unique, la GNU General Public License (GPL),
qui réécrite plusieurs fois, compte encore aujourd'hui parmi les licences libres les plus
utilisées.

Le fait qu'une même licence soit utilisée pour de nombreux logiciels permet de les
rendre compatibles entre eux, c'est-à-dire que du code écrit pour un programme peut être
réutilisé dans un autre, sans que les termes des différentes licences soient mutuellement
exclusifs.

Le principe de la licence libre est né, et par la suite d'autres licences libres sont écrites
et adoptées par les projets de logiciels libres et open source.

## I.2.2 Fondements juridiques

### I.2.2.1 Systèmes de protection : brevets et droits d'auteur

Dans les années 1980, quand les producteurs de logiciels commencent à vouloir proté-
ger leur propriété intellectuelle, la législation états-unienne décide de deux mécanismes

<footnote n="4">4. GNU (GNU's Not Unix!) est le nom donné à un projet de système d'exploitation libre, initié par Richard Stallman et développé par de nombreux contributeurs. Ce projet n'a jamais vu le jour en tant qu'OS complet et indépendant, mais une grande partie des programmes écrits pour GNU sont utilisés dans le système GNU/Linux*.</footnote>
de protection : les brevets et le copyright 5. Ces deux mécanismes existaient déjà, dans un cas pour les inventions, et dans l'autre pour les œuvres de l'esprit. Les licences de logiciels sont écrites en termes juridiques pour expliciter les droits conférés aux utilisateurs dans le cadre des législations sur le copyright et les brevets. Il convient d'approfondir les mécanismes sur lesquels reposent les licences libres pour comprendre ce qui leur donne leur force juridique, et desquels découlent toutes les considérations techniques et économiques.

Il y a donc deux mécanismes de protection pour les logiciels : le droit d'auteur5 et les brevets. Les brevets permettent une protection légale limitée dans le temps, et portent sur des idées, des algorithmes, des prototypes. Le brevet logiciel porte plus spécifiquement sur un logiciel, sur du code. L'obtention d'un brevet garantit, dans le pays où il est enregistré, un monopole d'exploitation de l'idée protégée. Pour qu'un concurrent ait le droit de l'utiliser dans son produit, il doit obtenir une licence, une permission de la part de la personne qui a enregistré le brevet.

Malgré des tentatives de législation dans les années 2000, suite à un intense lobbying des industriels, notamment Microsoft, et une longue lutte juridique, les brevets logiciels n'ont pas été reconnus en Europe. L'ouvrage de PERLINE et NOISETTE [6] relate notamment cet épisode, et combien il a influencé l'essor du logiciel libre en Europe. En 2019, la seule protection légale pour les logiciels en Europe est donc le droit d'auteur (ou le copyright, selon les juridictions), et les brevets sont souvent ignorés dans les discussions européennes autour du logiciel libre.

### I.2.2.2 Copyright et droit d'auteur

Le copyright et le droit d'auteur sont deux formes de protection des œuvres de l'esprit. Ils sont équivalents, mais ne sont pas mis en œuvre de la même manière selon les pays. Grossièrement, le droit d'auteur a cours dans les juridictions de droit civil comme la France et la Belgique, et le copyright, celles de common law comme la Grande-Bretagne

<footnote n="5">5. L'équivalent du copyright en France est le droit d'auteur. Malgré des différences, j'emploierai les deux termes de manière équivalente. Voir section I.2.2.2.</footnote>
ou les États-Unis. Dans cette thèse, il n’est pas besoin d’entrer dans les détails, et l’on peut retenir que ces lois ont sensiblement les mêmes fonctions et des implications très similaires.

Le droit d'auteur a pour but de protéger les auteurs d'une part, et les personnes et entités exploitant commercialement les œuvres d'autre part : les éditeurs, les diffuseurs. En France, le droit d'auteur est régi par le Code de la propriété intellectuelle. Une majorité des pays du monde reconnaissent le droit d'auteur ou des concepts similaires. En effet, la convention de Berne, ratifiée en 1886, crée une équivalence mondiale entre les systèmes de protection des auteurs, et garantit donc une protection internationale dès la publication d'une œuvre.

### I.2.2.3 Les licences logicielles : droits et restrictions de l'utilisateur

Quand les éditeurs ont commencé à vouloir protéger la propriété intellectuelle de leurs programmes, le droit d'auteur 6 est une des solutions juridiques existantes, au côté des brevets donc, vers lesquelles s'est tournée la législation. Le droit d'auteur est d'abord prévu pour protéger les œuvres d'art et garantit à l'auteur une exclusivité de l'exploitation de l'œuvre. Dans le cas des logiciels, qui ont généralement un but pratique, le copyright seul ne suffit pas à préciser les droits de l'utilisateur sur le programme, comme le précisent JULLIEN et ZIMMERMANN [13]. Cela conduit les éditeurs à signer des contrats avec leurs utilisateurs, stipulant dans quelles conditions ces derniers peuvent utiliser les programmes. Pour un marché où la reproduction du produit (le logiciel) est triviale et où de grands nombres d'unités peuvent être vendus, ce contrat de licence n'est généralement pas rédigé pour et signé par chaque client ou utilisateur, mais rédigé de manière générique. L'acceptation de ce contrat 7 est alors tacite de la part de l'utilisateur, et il peut soit l'accepter pour utiliser le programme, soit contacter l'éditeur pour tenter

<footnote n="6">6. Ou le copyright, selon les pays. Voir section I.2.2.2.</footnote>

<footnote n="7">7. Ce type de contrat est souvent appelé « contrat de licence utilisateur final », en anglais *End-User License Agreement* ou EULA dans le contexte du logiciel propriétaire.</footnote>
de signer un autre contrat d'utilisation. Il va sans dire que cette dernière option est
rarissime pour l'utilisateur lambda.

I.2.2.4 Licences libres

Les licences libres et open source ne sont pas différentes des autres contrats de li-
cence dans leur nature : elles stipulent les droits que concède l'auteur ou le détenteur
des droits, à l'utilisateur. Dans le cas des logiciels propriétaires, les clauses du contrat
peuvent décrire le domaine précis d'utilisation, le droit de modification et de distribution
du programme, une limitation géographique ou temporelle, le nombre de machines sur
lesquelles le programme peut être installé, les données personnelles que collecte l'éditeur,
les modalités de mise à jour, etc.

Les licences de logiciel libre définissent elles aussi les droits et limitations de l'uti-
lisateur, mais dans un but globalement différent : tandis que les licences propriétaires
ne permettent à l'utilisateur que ce que l'éditeur a prévu, les licences libres cherchent à
garantir au plus grand nombre les libertés d'utiliser, étudier, modifier et redistribuer le
logiciel. Ces quatre libertés sont en fait au cœur des définitions du logiciel libre et du
logiciel open source. Elles seront étudiées plus en détail dans le contexte du secteur de
l'animation dans la section II.1.1.

Leurs quatre principes de base, communs par définition à toutes les licences libres,
sont que tous les utilisateurs, quelle que soit leur situation nationale, puissent :

— utiliser le logiciel à n'importe quelle fin, prévue ou non par l'éditeur;

— disposer du code source*, et pas seulement une version exécutable, et pouvoir
l'étudier;

— le modifier, afin de l'améliorer ou de le corriger, d'y ajouter ou retrancher des
fonctionnalités;

— redistribuer leurs modifications à d'autres utilisateurs.

N'importe quel contrat de licence incluant implicitement ou explicitement ces quatre
conditions est une licence libre et open source. Chacun peut écrire une licence libre pour
son programme, mais la plupart des développeurs de logiciels libres choisissent parmi
les licences existantes, parmi lesquelles GNU GPL et LGPL, MIT (Expat), Apache, etc. Chacune de ces licences offre des particularités, dont certaines sont étudiées dans la section II.1.3. Il y a plusieurs intérêts à choisir une licence répandue. D'abord, ses termes sont connus des autres développeurs et des utilisateurs attentifs, qui pourront connaître rapidement les droits qu'elle leur confère. Ensuite, une licence est un contrat légal liant deux parties. Une licence utilisée depuis longtemps peut être mieux étudiée par les juristes, et offrir une protection avérée<fnref n="8" />. Enfin, il est plus facile de combiner entre eux des logiciels disparates si leurs licences sont compatibles (cf. section II.1.3.1).

Cela peut se traduire aussi par des interdictions ou obligations pour l'utilisateur, qui peuvent être ressenties par certains comme des contraintes privatrices de liberté. Par exemple, la licence copyleft (cf. section II.1.3.1) GPL explique clairement que l'utilisateur qui déciderait de transmettre le programme est dans l'obligation d'en livrer, au minimum, la version non-compilée, le code source*. Ce point de vue est développé dans la section II.1.3.1, mais il est important de comprendre la notion de liberté comme sociale, c'est-à-dire que le but du logiciel libre est d'offrir au plus grand nombre la plus grande liberté possible.

### I.2.3 Libre et Open Source : confusion et approches idéologiques

Le logiciel libre est depuis le milieu des années 1990 marqué par un débat terminologique. En effet, le terme de logiciel libre, en anglais *free software*, crée une confusion entre les concepts de gratuité et de liberté, exprimés en anglais par le même mot *free*<fnref n="9" />. Afin de réduire cette confusion, certains auteurs, à commencer par RAYMOND [7], proposent le nouveau terme d'*Open Source*, rapidement adopté et répandu dans la communauté et au-dehors.

<footnote n="8">8. Il convient pour s'en assurer de consulter un avocat spécialiste de la propriété intellectuelle.</footnote>

<footnote n="9">9. Cette homonymie est fâcheuse, car comme en témoigne la tableau I.2.1, le prix n'entre nullement en considération dans la classification des modèles de licences. S'il est vrai que les logiciels libres sont souvent gratuits, et les logiciels libres souvent payants, d'innombrables contre-exemples existent.</footnote>
<table><caption>TABLE I.2.1 – Comparaison des modèles de licences</caption><thead><tr><th>Modèle</th><th>Utiliser</th><th>Étudier</th><th>Modifier</th><th>Distribuer</th><th>Payant</th></tr></thead><tbody><tr><td>Logiciel propriétaire</td><td>X</td><td></td><td></td><td></td><td>Parfois</td></tr><tr><td><i>Source-available</i></td><td>X</td><td>X</td><td>X</td><td></td><td>Parfois</td></tr><tr><td>Logiciel libre</td><td>X</td><td>X</td><td>X</td><td>X</td><td>Parfois</td></tr><tr><td>Open source</td><td>X</td><td>X</td><td>X</td><td>X</td><td>Parfois</td></tr></tbody></table>

Ces deux termes sont souvent considérés comme synonymes par le profane, si bien qu'une expression rassemblant les deux, *Free and Open Source Software* ou FOSS, voire *Free/Libre and Open Source Software* (FLOSS), a été utilisée un peu plus tard. Le fait qu'il existe dans la communauté un clivage, et même chez certains une animosité, semble contre-productif. Cela s'explique pourtant par des différences assez profondes dans la manière de concevoir le mouvement. Le courant du logiciel libre est né d'une volonté idéologique de créer une économie de partage et de garantir la liberté des utilisateurs, ce dont témoigne l'adjectif « libre ». L'ouvrage de BROCA [1] développe ainsi la thèse selon laquelle ce mouvement est une nouvelle forme d'utopie sociale. L'expression « open source » est quant à elle beaucoup plus descriptive. Ses défenseurs la qualifient de pragmatique et non idéologique, et mettent en avant l'efficacité des méthodologies de développement issues du logiciel libre, plutôt que son rôle social.

Sur la forme, les deux définitions sont quasiment identiques (cf. tableau I.2.1). Dans les deux cas, elles désignent des programmes dont les sources sont distribuées selon les termes d'une licence qui les rend exécutables, accessibles, modifiables et redistribuables. Les logiciels libres sont également open source par définition, mais le contraire est plus difficile à évaluer, puisqu'il faut entrer dans les domaines de l'éthique, voire de la philosophie politique, et que les critères sont multiples, mal définis et parfois contradictoires. Richard Stallman [37] cite par exemple le cas de programmes utilisant du code open source, mais accessibles uniquement sur des plate-formes non-libres. Il soutient que ces programmes ne sont pas libres parce qu'il est impossible à l'utilisateur de les utiliser d'une manière non prévue par le constructeur, et d'accéder à toutes leurs capacités<fnref n="10" />.

Cette distinction, souvent mal comprise, est néanmoins utile à garder en tête pour

<footnote n="10">10. Cette pratique porte le nom de « tivoïsation » d'après celui d'un produit : le Tivo.</footnote>
connaître le positionnement des acteurs, notamment des développeurs et éditeurs de
logiciels.

Pour brouiller un peu plus encore les définitions, il y a souvent une confusion entre
logiciel open source, et logiciel dont les sources sont accessibles, ou *source-available*. Ce
modèle de licence offre effectivement la possibilité d'utiliser et d'examiner les sources
sous certaines conditions (souvent contre paiement), mais pas les autres libertés de les
modifier, et surtout de redistribuer. Il n'a donc rien à voir, ni avec l'open source, ni avec
le logiciel libre. Ce modèle sera étudié plus en détail dans la section II.1.1.4.

I.2.4 *Open data*

On assiste depuis plusieurs années à une volonté de la part des instances publiques, mais également d'initiatives privées ou associatives, de rendre accessibles des bases de données, en diminuant les contraintes d'accès. Cela s'applique donc à des bases internationales, gouvernementales ou régionales, et à des associations ou organisations non-gouvernementales dont le but est le recueil, la construction ou la consolidation de données. Il peut s'agir de données scientifiques telles que des photographies, images de synthèse, données d'expériences brutes ou traitées, modèles ; de données cartographiques comme des relevés cadastraux ou des plans d'urbanismes ; de données citoyennes comme les horaires de transports ; de données juridiques et législatives comme les lois et arrêtés, etc.

De la même manière que le logiciel libre utilise et détourne le droit de la propriété
intellectuelle pour permettre aux utilisateurs de s'approprier les programmes, il existe
des licences proches en esprit et spécialement conçues pour les bases de données. En
effet, les bases de données ne sont pas protégées par les mêmes lois que les œuvres sou-
mises au droit d'auteur (œuvres de l'esprit), mais elles bénéficient généralement d'une
protection similaire dans le code de la propriété intellectuelle : un monopole d'exploita-
tion est accordé au producteur de la base de données, qui peut donc décider de la rendre
disponible selon les termes qu'il entend [2], et donc éventuellement choisir une licence
de base de données ouverte telle que la licence ODbL*.

Ces données peuvent être directement utiles aux studios d'animation, et j'en montre-
rai deux exemples. Ces deux exemples concrets ont tous deux été utilisés en production,
pour des films d'animation ou des installations muséographiques, ce qui montre leur uti-
lité pour l'animation. L'utilisation par les Fées spéciales sera étudiée aux sections III.1.2
et III.1.3. J'ai également utilisé des données ouvertes dans le projet *Music Road*, qui est
décrit dans l'annexe B.

**I.2.4.1 Données d'élévation de la NASA**

L'Administration nationale de l'aéronautique et de l'espace ou *National Aeronautics and Space Administration* (NASA) est l'agence gouvernementale états-unienne responsable du programme spatial états-unien. Il s'agit avant tout d'une agence scientifique qui élabore de nombreuses missions pour étudier l'espace, et la Terre depuis l'espace.
Le gouvernement états-unien a pour politique de placer des données d'une partie de ses agences dans le domaine public <fnref n="11" />.

La NASA, comme d'autres agences, publie donc beaucoup de données sur ses diffé-
rents sites <fnref n="12" />. Puisque cette agence dispose de nombreux équipements de haute techno-
logie, notamment des instruments de mesure avancés à bord de satellites, elle est bien
placée pour disposer de données uniques et extrêmement utiles à des fins de visualisation
et d'étude scientifique, mais également à des fins artistiques.

Parmi ces données se trouve une catégorie très intéressante pour la fabrication
d'images de synthèse : les données d'élévation terrestres (figure I.2.1). Il s'agit de mesures
de la surface de la planète, se présentant sous la forme d'une liste faisant correspondre
à chaque point du globe une mesure de l'élévation, c'est-à-dire la distance verticale par
rapport au niveau de la mer. Concrètement, ces données peuvent être représentées sous la

<footnote n="11">11. Le domaine public est l'absence de toute protection juridique pour des œuvres, les rendant uti-
lisables et accessibles à tous. C'est la forme la plus extrême de licence libre. En France, les œuvres ne
sont dans le domaine public que plusieurs décennies après la mort de leur auteur, et celui-ci ne peut
pas y placer volontairement ses œuvres. En revanche, d'autres pays le permettent.</footnote>

<footnote n="12">12. En particulier le site principal de données ouvertes, https://data.nasa.gov/ et le site de données scientifiques sur la Terre, https://earthdata.nasa.gov/.</footnote>
<figure><img src="image_3.png" /><figcaption>FIGURE I.2.1 – Image composite à partir de deux cartes publiées par la NASA : une carte d'élévation terrestre et une carte de bathymétrie.</figcaption></figure>

forme d'un fichier texte, ou d'une image standard dans laquelle chaque pixel correspond
à une zone géographique réduite, et sa valeur à son élévation. Il est donc possible d'uti-
liser cette image dans un programme de 3D pour créer une sphère déformée localement,
avec une grande fidélité visuelle à la Terre.

Un studio d'animation peut se servir de ces données directement pour créer des visualisations, des modèles ou des animations de la Terre (cf. section III.7.1.2).

I.2.4.2 OpenStreetMap

OpenStreetMap (OSM) est une base de données cartographiques commencée en 2004
en Grande-Bretagne. Couvrant la totalité de la surface de la Terre, avec un niveau de
précision inégal mais en constante amélioration, elle est le fruit des contributions de
millions 13 de volontaires. Chacun peut y contribuer, en proposant des améliorations ou
des mises à jour à la base de données.

<footnote n="13">13. Les statistiques du projets affichent plus de 5 500 000 utilisateurs en 2019. Voir https://www.openstreetmap.org/stats/data_stats.html</footnote>
<figure><img src="image_4.png" /><figcaption>FIGURE I.2.2 – Rendu du continent antarctique avec la surface déplacée par la carte précédente.</figcaption></figure>

## Nature de la base de données

Il convient d'insister sur le fait qu'OpenStreetMap est une base de données, et non pas un service en ligne présentant des informations, comme les sites plus connus de Google, Apple et Microsoft (Bing) Maps<fnref n="14" />. Le « produit » offert par OpenStreetMap n'est pas le site web, mais une base de données colossale librement utilisable. Cette base de données peut être utilisée pour plusieurs applications, par plusieurs acteurs, et surtout avec peu de restrictions d'usage. Aussi, le site web openstreetmap.org est une de ces applications : il utilise la base de données pour faire le rendu de la carte qui est affiché.

<footnote n="14">14. On peut arguer que les cartes de Google, Apple ou Microsoft sont également des bases de données accessibles par d'autres moyens que via le site web, à savoir une API* pour les développeurs, permettant de créer des ressources cartographiques dérivées. C'est vrai dans une certaine mesure, mais les conditions d'utilisation du service sont très restrictives. Il est par exemple interdit aux utilisateurs d'extraire des données ou de les garder en mémoire, de créer des cartes dérivées, ou de créer et diffuser des listes de points d'intérêt, le but du service étant de dépendre de l'infrastructure de Google. Il est également interdit de mélanger des sources, en ajoutant des données extraites des cartes Google à d'autres fonds de cartes. De plus, l'utilisation des données est interdite dans certains pays ou territoires. Ces utilisations interdites sont au contraire encouragées par OpenStreetMap. Il est possible de télécharger et de garder à jour l'intégralité de la base de données, pour une utilisation hors-ligne.</footnote>
Mais d'autres groupes et entreprises offrent aussi des cartes fondées sur les mêmes données. Elles peuvent avoir un autre rendu, une autre langue, utiliser d'autres technologies, viser un public différent, ou simplement offrir un service commercial alternatif, avec le support qui s'y rattache. La base de données est également utilisée pour la visualisation scientifique, du calcul d'itinéraire, de l'aide humanitaire, ou toute autre application.

## Licence de base de données ouverte

Les données d'OpenStreetMap sont publiées sous la licence ODbL*<fnref n="15" />, spécialement conçue pour les bases de données. Comme la licence GNU GPL, c'est une licence libre à copyleft fort (cf. section II.1.3.1). On peut donc l'utiliser à n'importe quelle fin, mais à deux conditions : l'attribution et le partage dans les mêmes conditions. Si je veux présenter une version modifiée de la base de données, je dois afficher clairement l'origine des données, et je dois distribuer la version dérivée sous la même licence, ODbL. En revanche, je peux créer une œuvre dérivée utilisant la base de données (par exemple un plan* dans un film) en indiquant seulement l'origine des données, sans que ce film ne doive être publié sous la même licence. Cela permet une exploitation commerciale du film, selon les termes que je choisis.

## Organisation de la base

Comme souvent avec le contenu libre, son organisation est au départ déroutante, à la fois dans sa mission que dans l'accès aux données. En effet, le site web du projet présente une carte ressemblant aux services en ligne comme Google Maps. Les fonctionnalités sont similaires, quoique plus faibles que celles d'autres services : navigation sur la carte du monde, de l'échelle globale à l'échelle locale ; géolocalisation ; recherche d'adresses et de points d'intérêts ; calcul d'itinéraire ; informations sur des zones géographiques ou des points d'intérêt.

<footnote n="15">15. On peut trouver la page expliquant les droits associés à la base de données ici : https://www.openstreetmap.org/copyright</footnote>
Tout comme dans Google Maps, l'utilisateur peut créer un compte et proposer une modification de la carte pour l'améliorer, au bénéfice de tous les autres utilisateurs. La différence se trouve dans la manière dont les modifications sont intégrées à la base de données. Elles ne sont pas validées par une société, mais modérées par la communauté, c'est-à-dire par d'autres contributeurs. Tout comme dans Wikipédia où chaque article peut être modifié par tout le monde, la modification apparaît immédiatement et la construction d'OpenStreetMap est organique. La viabilité de ces projets repose sur l'idée que la majorité des utilisateurs veuille y contribuer de bonne foi — et il existe des mesures contre les modifications des utilisateurs malveillants.

## Contribution

Chaque utilisateur peut contribuer à la base de données. Ils restent les auteurs de leur contribution, mais la publient sous la même licence que les autres données, et la base dérivée qui en résulte est également libre. Ce n'est pas le cas des contributions que l'on peut faire à Google Maps. Dans les deux cas, j'en reste l'auteur, et je donne une licence irrévocable d'utiliser, stocker, modifier, distribuer, et créer des œuvres dérivées de ma contribution. Mais la différence est que pour OpenStreetMap, je donne cette licence à tous les utilisateurs, tandis que dans le cas de Google Maps, comme spécifié dans ses termes d'utilisation, je n'accorde cette licence qu'à Google, et non aux autres utilisateurs. La société a donc dans les faits un quasi-monopole sur ma contribution, et la contrôle juridiquement et techniquement. Ce contrôle juridique s'applique aussi à l'exploitation commerciale de mes données.

## Conclusion

Le logiciel libre est un mouvement qui a pris une ampleur considérable au cours des dernières décennies, mais dont les principes sont encore mal compris, y compris au sein des studios d'animation qui en utilisent quotidiennement, directement ou indirectement.

J'ai rapidement abordé l'histoire du logiciel libre, pour bien garder en tête ses fonds-
tions idéologiques et pratiques ; les principes juridiques sur lesquels reposent sa diffusion
et son élaboration, à savoir le droit d'auteur. J'ai montré la manière dont les licences
de logiciels libres détournent les principes initiaux du droit d'auteur pour donner la
possibilité aux développeurs et aux utilisateurs de créer un bien commun, utile à tous.

J'ai enfin abordé un thème connexe, celui des données ouvertes (open data), qui reposent sur des principes similaires à ceux des logiciels libres, et donnent des possibilités de création inédites aux studios.
# Conclusion de la première partie

Cette première partie a permis d'exposer les deux domaines disjoints qui sont étudiés, comme son nom l'indique, dans cette thèse : l'animation et le logiciel libre.

Dans le chapitre I.1, j'ai abordé les particularités des studios d'animation en tant que structure, et en tant qu'entité utilisant des processus complexes qui reposent sur l'outil informatique. Pour circonscrire ma recherche, j'ai évoqué le studio dans lequel j'ai passé la majeure partie de la durée de ma thèse, Les Fées spéciales.

J'ai également montré une chaîne de fabrication (pipeline*) typique d'un petit studio d'animation, en décrivant chaque étape de la chaîne. Ces étapes sont interconnectées, mais peuvent être indépendantes les unes des autres. Certaines peuvent aujourd'hui être accomplies en utilisant des logiciels libres, d'autres difficilement.

Le chapitre I.2 a permis de décrire ce que constituent le logiciel libre et le logiciel open source — et ce qui les distingue. J'ai rappelé leur histoire au sein de la micro-informatique et les principes juridiques qui les sous-tendent, utilisant le droit d'auteur d'une manière pour laquelle il n'avait pas été pensé antérieurement.

Ces éléments sont indispensables à la suite de cette thèse, afin de comprendre la place que peut avoir le logiciel libre dans l'animation, à la fois dans la simple utilisation de logiciels existants, et dans le développement, la collaboration et la publication au sein des studios de scripts et d'applications, que nous aborderons dans la partie suivante.
Deuxième partie

Enjeux du libre pour l'animation
# Introduction

On observe depuis plusieurs années un engouement pour certains logiciels libres au sein des studios. Les raisons de ce choix sont multiples : elles peuvent être liées au coût perçu pour les structures, à la souplesse que leur confère ce modèle de développement et de publication, à la perspective d'une coopération, voire d'une entraide entre les studios, ou simplement à la performance de certains programmes.

Mais au-delà de ces raisons, les problématiques liées à l'utilisation du logiciel libre sont complexes. Une partie des questionnements est plus généralement applicable aux structures utilisant ou contribuant aux logiciels libres, et d'autres sont spécifiques aux activités des studios d'animation. Cette partie explorera ces problématiques, regroupées en plusieurs thématiques, qui porteront sur les facteurs juridique (chapitre II.1), économique (chapitre II.2), et technique (chapitre II.3).
# Chapitre II.1

## Obligations et libertés juridiques

### Introduction

Tout comme un film d'animation, le produit d'un développement logiciel est une œuvre protégée par le droit d'auteur. Et de la même manière que les studios doivent se préoccuper des aspects administratifs et juridiques du droit d'auteur pour publier leurs productions ou simplement engager des auteurs, ils doivent avoir des notions de propriété intellectuelle pour publier ou contribuer à des programmes.

Cette connaissance juridique est d'autant plus fondamentale que dans le cas du logiciel libre et open source, c'est sur elle que reposent les principes de base du logiciel en tant que bien commun, et du développement collaboratif.

Ce chapitre exposera donc l'intérêt pour les studios d'utiliser et de contribuer au logiciel libre, ce qu'ils doivent savoir pour ce faire, et les difficultés juridiques qui y sont attachées.

### II.1.1 Les quatre libertés du logiciel libre

Les définitions du logiciel libre et du logiciel open source comprennent toutes deux la nécessité de publier un programme sous une licence offrant à l'utilisateur quatre libertés fondamentales : utiliser, étudier, modifier et distribuer le code source*. Ces quatre li-
bertés peuvent être précisées explicitement dans le texte de la licence, ou implicitement, comme c'est par exemple le cas de la licence permissive What The Fuck Public License (WTFPL) [70] , qui mentionne simplement que l'utilisateur peut faire ce qu'il veut avec le programme.

Ces quatre libertés, déjà mentionnées dans la partie I, sont donc au fondement juridique du logiciel libre et open source, et je détaillerai dans cette section les problématiques associées à chacune d'entre elles pour un studio d'animation.

II.1.1.1 Utiliser

La première liberté associée au logiciel libre est d'utiliser le logiciel à n'importe quelle fin, sans restriction de but ou de domaine d'utilisation. À l'inverse, les logiciels propriétaires, à travers leur contrat de licence, interdisent souvent des utilisations, ou bien les restreignent à quelques utilisations précises.

Nombre d'installations simultanées

Dans la mesure où les conditions d'utilisation sont fixées par les éditeurs, ces derniers peuvent décider qu'une licence donnée ne puisse être installée que sur un nombre limité de postes, ou utilisée par une seule personne. Ainsi, les termes d'utilisation d'un acteur dominant du secteur de l'animation comme Autodesk [27] stipulent dans la version de mai 2018 :

« Pour toute Offre incluant des Logiciels qu'Autodesk met à votre disposition ou Vous livre, sous réserve du respect des présentes Conditions Générales et de toutes les obligations de paiement, Autodesk Vous concède une licence non-exclusive, non-cessible et ne pouvant être l'objet de sous-licences, pour la durée de Votre abonnement, afin d'installer et d'utiliser les Logiciels (et de permettre à Vos Utilisateurs Autorisés de les installer et de les utiliser) uniquement (i) conformément à la Documentation de l'Offre et à toutes Conditions Particulières applicables, le cas échéant, et (ii) dans le périmètre de Votre abonnement, y compris le nombre autorisé, le Type de Licence, le Territoire et autres spécificités précisées pour le
type et le niveau que Vous avez choisis au moment de la souscription de l'Offre. »

Cette clause signifie que l'utilisation du logiciel est limitée dans le temps, dans le nombre d'installations, et dans la zone géographique <fnref n="1" />. En pratique, cette limitation est appliquée par des moyens techniques de *Digital Rights Management* (DRM), typiquement par un serveur d'identification de licence. Dans certains cas, le logiciel ne pourra pas être exécuté sans connexion à Internet, afin de l'authentifier auprès des serveurs de l'éditeur et empêcher ainsi toute utilisation non prévue par le contrat d'utilisation.

Dans le contexte spécifique du secteur de l'animation, la limitation de durée peut rapidement devenir problématique. En effet, il est fréquent que les studios souhaitent garder une compatibilité avec des fichiers créés sur d'anciennes versions du logiciel, collaborer avec des graphistes utilisant différentes versions, ou simplement terminer un projet avec la version avec laquelle il a été commencé, pour éviter des problèmes de mise à jour en pleine production. Sachant que la fabrication d'un film d'animation peut durer des années, une production peut être amenée à être en retard de plusieurs versions d'un logiciel.

Ce problème a été bien illustré en 2019, et assez largement médiatisé dans le secteur [25], quand l'éditeur Adobe a interdit l'utilisation des anciennes versions de ses logiciels Creative Cloud, les contrevenants pouvant s'exposer à des poursuites. Je n'ai pas eu connaissance de productions d'animation ayant été mises en difficulté par cette annonce, mais elle a néanmoins fait parler d'elle, dans la mesure où un grand nombre de professionnels préfèrent garder d'anciennes versions plutôt que s'exposer à des problèmes de compatibilité.

<footnote n="1">1. En octobre 2019, dans le contexte de la présidence de Donald Trump, les entreprises États-Uniennes se sont vues interdire toute relation commerciale avec le Venezuela. Une conséquence directe dans le secteur de l'animation a été l'arrêt complet de l'export des logiciels de la suite Adobe (Photoshop, After Effects, etc.). Suite à cette annonce, les utilisateurs devaient voir leurs abonnements « cloud » suspendus, sans remboursement ni négociation possible. Adobe a reçu une dérogation de son gouvernement le mois suivant pour pouvoir continuer à exporter ses produits au Venezuela, mais cette expérience a montré clairement la dépendance industrielle et économique aux éditeurs de logiciels.</footnote>
Restrictions d’usage

L'utilisateur peut se voir limité aux usages prévus par l'éditeur. C'est le cas par exemple des licences d'évaluation, qui sont en général gratuites et interdisent une utilisation commerciale. Voici un autre exemple, extrait de la version de mars 2020 des conditions générales d'utilisation des produits Adobe [26] :

« **Utilisation inappropriée.** Vous ne devez pas utiliser de manière inappropriée les Services ou les Logiciels. Par exemple, vous ne devez pas : [...]

« (E) utiliser les Logiciels pour créer tout type de base de données ou jeu de données; »

Cette clause vise directement à contrôler le type de contenu que les utilisateurs peuvent créer. Sachant que la limite entre une œuvre et une base de données regroupant plusieurs documents ou œuvres est difficile à déterminer en pratique, cette clause peut potentiellement restreindre la liberté de création des artistes.

Le choix de travailler avec des logiciels libres évacue toutes ces problématiques de restriction d'utilisation imposée par les logiciels propriétaires. En effet, la première liberté associée au logiciel libre est d'utiliser le logiciel à n'importe quelle fin, sans restriction de but ou de domaine d'utilisation. L'utilisateur peut copier le logiciel, l'installer sur un nombre illimité de machines, pour une durée illimitée. Cela lui garantit de pouvoir continuer à utiliser le programme même lorsque celui-ci est déclaré en fin de vie par son éditeur, voire des décennies plus tard, du moment qu'il parvient à compiler ou exécuter le programme sur sa machine. Il peut utiliser le programme pour n'importe quel usage, prévu ou non, déclaré ou non.

II.1.1.2 Étudier

La deuxième liberté offerte par les logiciels sous licence libre et open source est celle d'en étudier le code. On parle souvent de « boîte noire » pour décrire les programmes, fonctions ou modules dont le comportement est connu et éventuellement documenté,
mais dont l'implémentation ou même les algorithmes sont inconnus, voire inaccessibles.
C'est le cas de la majorité du code propriétaire, à l'exception des licences dites « code-
accessibles », qui ne remplissent pas les conditions de l'open source et du libre mais dont
le code peut être consulté dans des conditions définies par l'éditeur.

Le code libre et open source est donc par définition accessible, lisible et étudiable.
La licence GPL va plus loin en demandant à ce que le code source* soit distribué « sous
sa forme privilégiée » [64, §1], c'est-à-dire tel que conçu par l'auteur, sans modification
ultérieure ayant pour but de la rendre illisible ou inaccessible <fnref n="2" />.

La base du développement collaboratif

Cette liberté présente plusieurs intérêts pour l'utilisateur. D'abord, il est évident que
c'est une condition indispensable au travail de développement collaboratif. Les éventuels
contributeurs sont bien forcés de prendre connaissance du code pour être en mesure
de le corriger, de l'améliorer. L'idée énoncée par RAYMOND [7], selon laquelle « avec
suffisamment d'yeux, tous les bugs sont superficiels », et connue sous le nom de loi
de Linus, très répandue dans le monde de l'open source, découle précisément de cette
liberté. En étudiant le code, les développeurs qualifiés peuvent repérer régulièrement les
bugs et les corriger. Cette possibilité n'existe pas dans le logiciel propriétaire.

Il en découle logiquement les modèles de développement propres à l'open source, que
nous étudierons plus en détail à la section suivante dans le cas spécifique du secteur de
l'animation (cf. section II.1.1.3).

Valeur pédagogique

Ensuite, l'étude d'un code source de qualité est une manière extrêmement utile d'ap-
prendre à développer. Le code constitue en effet un ensemble d'algorithmes, de méthodes
évaluables par la machine, mais on peut également le considérer comme une œuvre des-

<footnote n="2">2. Cette pratique, l'offuscation, a pour but de se prémunir d'une utilisation non autorisée de propriété intellectuelle ou de secrets commerciaux. Dans le cas de langages compilés, les exécutables constituent en eux-mêmes une offuscation, puisque le code source est difficile à reconstruire. Dans les langages interprétés comme Python, il n'existe pas de distinction formelle entre le code source et l'exécutable. Cependant, il est possible de rendre illisible, ou difficilement lisible, du code interprété.</footnote>
tinée à être lue par d'autres humains. C'est pour cette raison que les guides de développement informatique liés à des projets ou des groupes de développeurs incluent souvent des recommandations sur la lisibilité du code. Celui-ci est destiné à être lu bien plus souvent qu'il n'est écrit. La documentation a un rôle d'ingénierie, puisqu'elle permet d'expliciter le fonctionnement, l'usage et les détails d'implémentation d'un programme. Elle permet également la transmission des savoirs, décisions, desseins des développeurs à d'autres développeurs, présents ou à venir.

Pour m'appuyer sur un exemple concret, je propose de relater mon expérience personnelle en matière d'apprentissage de la programmation informatique. J'ai appris à développer des scripts* de plusieurs manières. La première, à l'université, m'a été enseignée en licence dans un cours de scripting pour Maya. En parallèle à une nécessaire introduction au langage, la méthode consiste à apprendre les fonctions de l'API* en exécutant les commandes du programme. Après chaque opération, Maya affiche dans une console la commande correspondante. Ainsi, pour reproduire ou automatiser un processus connu, on cherche l'opération dans l'interface, on récupère la commande, et on effectue une recherche dans la documentation de l'API*. On peut ainsi connaître les options disponibles, lire les exemples, et les adapter à la tâche voulue. Cette méthode, si elle est très précieuse et efficace pour le début, ne peut enseigner que des « atomes » de programmation, que sont les commandes individuelles permettant d'élaborer des manipulations de données plus complexes. Elle est très adaptée au scripting de l'API `cmds` dans Maya<fnref n="3" />. Pour apprendre d'autres API et des principes de programmation plus avancés, j'ai trouvé cette méthode insuffisante.

Cela m'amène à la deuxième méthode que j'ai employée pour apprendre le développement. Je l'ai utilisée lorsque j'ai commencé à scripter dans le logiciel d'animation 3D Blender, dont la documentation en matière de scripting, et les ressources pédagogiques étaient à l'époque, vers 2012, succinctes. Il existait bien quelques pages expliquant le minimum pour commencer à écrire des scripts dans l'interface de Blender, ainsi que quelques tutoriaux vidéo. Seulement, ils étaient insuffisants pour comprendre correcte-

<footnote n="3">3. Cette API Python livrée avec Maya permet de manipuler les données du programme. Elle est conçue selon un paradigme procédural dérivé du langage MEL propre à Maya [30].</footnote>
ment la logique propre à l'API, sans maîtriser préalablement d'autres API organisées de manière similaire. Il fallait donc consulter les exemples mis à disposition au sein du programme par les développeurs. Ces exemples, bien documentés et commentés, permettaient d'acquérir une meilleure idée des principes, des structures de données et des moyens d'y accéder, des opérateurs, de l'interface graphique, etc. Mais pour pouvoir concevoir des scripts plus avancés, il était nécessaire, puisque je n'avais pas les connaissances préalables, de lire, en plus de la documentation, du « vrai » code, de vrais additions* fonctionnels et correctement conçus. Une partie de cette démarche se résume à recopier et adapter des bouts de code à ses besoins, mais un autre aspect fondamental est d'être exposé à des problèmes inconnus, et surtout à leur solution. Plutôt que de chercher une solution originale, il est profitable d'apprendre à mettre en œuvre des solutions déjà éprouvées, souvent plus efficaces, et même parfois intégrées au langage de programmation. Il est bien sûr aussi possible de lire intégralement les documentations du langage et de l'API, ce qui est également utile tôt ou tard, mais plutôt indigeste. Le fait de voir une solution utilisée en condition réelle permet de la comprendre beaucoup mieux, et de la retenir.

Cette manière d'apprendre est efficace dans les premiers temps, quand on apprend à programmer, et elle demeure utile plus tard, en production, quand on rencontre un problème nouveau, ce qui arrive souvent dans un secteur aux problématiques de développement très spécifiques comme celui de l'animation. Je continue donc à apprendre, et à programmer de cette manière, et cette expérience m'a fait prendre conscience du rôle joué par le libre dans l'apprentissage et la pratique du développement pour l'animation, qui m'est pratiquement indispensable aujourd'hui.

Cependant, bien qu'il soit utile de lire du code pour apprendre à en écrire soi-même il convient que le code soit de bonne qualité, autant dans sa conception que dans sa documentation.
Qualité du code

S'il est possible pour les développeurs au sein d'un studio d'étudier le code source de programmes publiés sous licence libre, l'inverse est aussi vrai : un studio qui publie son code peut le voir étudié par n'importe qui. Du code destiné à être reliu et évalué par d'autres ne sera pas écrit comme du code réservé à l'intimité de l'entreprise. Il en résulte souvent un code de meilleure qualité dans deux domaines :

D'abord, en destinant du code à publication, et par extension à une éventuelle collaboration, les studios d'animation sont forcés à considérer des cas plus généraux que ceux de leur propre production, de leur propre pipeline*. En raison des conditions de production, la publication de code open source par les studios se fait généralement en deux temps. Les programmeurs écrivent d'abord rapidement des outils visant à résoudre des problèmes pratiques rencontrés en cours de production. Un outil jugé utile à un plus vaste public peut ensuite voir son code nettoyé, refactorisé en vue de sa publication. De cette manière, l'outil peut être rendu indépendant des particularités du pipeline du studio.

Ensuite, pour qu'un outil puisse être utilisé par quelqu'un d'autre que par ses concepteurs, il est nécessaire qu'il soit convenablement documenté. Bien sûr, une documentation doit être correcte pour tout type de programme, libre ou propriétaire, mais dans le cas de programmes open source, le code source lui-même peut faire partie de la documentation technique, à travers les commentaires des développeurs.

Or, dans le contexte d'un studio d'animation, la préoccupation générale est plus de publier une œuvre audiovisuelle que d'écrire des programmes. L'écriture de code clairement conçu et bien documenté n'est donc pas prioritaire, a fortiori quand on sait, ou que l'on croit, qu'on écrit du code à usage unique.

En mars 2019, j'ai mené une enquête par entretien semi-directif auprès de développeurs au sein de studios d'animation français collaborant à des projets open source, pour recueillir leurs regards sur le rôle du logiciel libre dans leur pratique du développement pour l'animation 4. Comme le confirme l'un d'eux, TD* dans un petit studio

<footnote n="4">4. Un guide d'entretien se trouve en annexe E.</footnote>
d'animation :

« [...] C'est un autre aspect intéressant de l'open source d'ailleurs : quand tu codes avec l'état d'esprit de partage, tu codes avec le retour de tes pairs en tête. Ça pousse à la rigueur. Mon code pour des trucs persos est carrément moins propre que celui des projets open ! J'aime beaucoup documenter mon code. Avant, pour clarifier les idées, et après pour valider que tout est simple et solide. Mais ma doc préférée c'est les commentaires à l'intérieur du code. C'est l'occasion de laisser des petites blagues, de mettre de l'esprit dans un code, de rendre les choses plus vivantes. Je reçois régulièrement des messages à propos des blagues dans les commentaires, parfois à propos de code que j'ai écrit il y a 10 ans à IMG [Illumination Mac Guff] ! C'est un plaisir et ça me pousse à le faire de plus en plus. <fnref n="5" /> »

### II.1.1.3 Modifier

Dès lors qu'un développeur a accès au code source d'un programme, il est en mesure de le modifier et de l'exploiter pour ses propres fins, qui ne sont pas nécessairement celles de l'auteur original du programme. Il peut réparer ce qui ne marche pas ou plus, améliorer ce qui pourrait mieux marcher, ou ajouter des fonctionnalités non prévues.

#### Support technique des développeurs

On constate souvent une méfiance des studios vis-à-vis des logiciels libres, en raison du fait que ceux-ci ne sont généralement pas commerciaux, et qu'ils n'offrent donc pas de support technique régis par contrat. En théorie, le fait de s'acquitter du coût d'une licence auprès d'un éditeur donne au studio le droit à un support technique, qui peut s'étendre à du développement, et à la résolution de bugs en particulier.

Un TD interrogé sur le sujet modère quant à lui cette affirmation :

« Mais le support sur les softs historiques est en pratique inexistant de toute façon, à moins de payer extrêmement cher en plus du prix des licences. Et même là je

<footnote n="5">5. Entretien semi-directif réalisé par Internet avec Damien Coureau, 13 mars 2019.</footnote>
doute de la qualité des réponses face au bug... Personnellement je vois le [dévelop-
pement] comme un outil fondamental dans la structure d'un studio vfx/anim.<fnref n="6" /> »

Lorsqu'on utilise un programme d'animation propriétaire et que l'on rencontre un bug, le seul recours est de contacter le service après-vente pour le leur rapporter, en espérant qu'il soit corrigé dans la version suivante. En attendant, il faut trouver une manière de contourner le bug<sup>7</sup>.

On peut donc penser que les développeurs de logiciels libres n'étant pas engagés
dans une relation à des clients, ils ne sont pas tenus de s'occuper de la maintenance. De
fait, la plupart des licences libres incluent même une clause stipulant que le développeur
ne doit pas d'assistance à l'utilisateur<sup>8</sup>. Cependant, deux éléments viennent contredire

« Pour la gestion du cache* disque : dans After, quand tu fais un rendu ou quand tu travailles dans la timeline*, pas forcément en rendu mais juste la RAM preview, il stocke le contenu de chaque calque dans le cache disque. C'est-à-dire qu'il stocke le résultat de rendu d'un calque. Donc il remplit le disque avec un certain nombre de Go maximum que tu définis, et il est censé réutiliser ce cache disque au moment des autres previews bien sûr, mais il est capable aussi de les réutiliser au moment du rendu. Et donc le gros challenge pour eux, c'est de savoir ce qu'ils peuvent réutiliser, et ce qu'ils ne peuvent pas. S'il y a eu des mises à jour, il va faire un rendu qui correspond aux dernières modifications que tu as faites. Et ça, depuis la 2014, depuis qu'ils ont extrait le moteur de rendu du moteur d'interface, c'est-à-dire que le moteur de rendu est un service qui tourne en arrière-plan, et qui n'est pas lié à l'interface, mais l'interface lui lance des appels. Ça permet par exemple de lancer un rendu ou une preview, et de se balader dans l'interface sans que ce soit bloquant.

« Quand ils ont fait ça, ils ont retiré beaucoup de choses : le multiprocessing — même s'ils essaient encore de l'utiliser, mais on peut considérer qu'After n'utilise qu'un cœur — et surtout, le gros problème, y compris avec la version 2019, et j'ai encore eu le problème il y a deux semaines : parfois, il croit que l'image qui se trouve sur le disque correspond à une image en cache, et il se trompe. Donc, tu rends une animation et tu te retrouves avec une image qui a été lue du cache disque et qui n'a rien à voir du tout. Ça peut même venir d'un autre projet.

« Donc quand tu lances un rendu, il faut purger le cache disque et la RAM, et tu n'as plus les avantages que tu avais en cours de travail.

« Il y a encore des problèmes avec ça, ça traîne depuis la version 2014. »

<footnote n="6">6. Entretien semi-directif réalisé par Internet avec Damien Coureau, 13 mars 2019.</footnote>

<footnote n="7">7. Interrogé à ce sujet, François Grassard, utilisateur du programme After Effects depuis la première version, mentionne le bug suivant, qui est toujours présent dans le programme cinq ans après avoir été signalé :</footnote>

<footnote n="8">8. Un exemple est donné en annexe C, abordant la question de la documentation publique des outils</footnote>
cette théorie. D'abord, les développeurs de logiciels libres peuvent être contactés pour rapporter des problèmes, et selon les ressources du projet et la complexité des bugs, ils sont souvent traités rapidement.

Ensuite, les utilisateurs, et les studios en particulier, peuvent participer eux-mêmes à l'effort de maintenance, soit en modifiant directement le programme, soit en le faisant faire par d'autres, soit au minimum en communiquant avec les développeurs.

## Réparer soi-même

Par la liberté de modifier le code, les utilisateurs de logiciels open source qui rencontrent un problème peuvent tenter de le résoudre eux-mêmes. Pour cela, on peut ouvrir et lire le code source* pour en comprendre la logique, utiliser des outils de debug, et éventuellement corriger les bugs.

Une fois un bug résolu, on peut envoyer la modification correctrice à l'équipe du programme, sous la forme d'un patch*. Les responsables du logiciel décident ensuite s'ils doivent l'intégrer, en faire modifier des parties, ou le rejeter complètement s'il est trop éloigné des ambitions du projet, ou de trop faible qualité. Dans tous les cas, même si le patch est rejeté, le studio peut garder le correctif pour son usage personnel, et le fournir à d'autres, voire mobiliser la communauté pour le faire intégrer dans le programme.

Une fois qu'un bug a été corrigé, il peut être intégré dans le code source du programme, et lorsque la version suivante sortira, elle inclura donc le correctif. Mais il peut passer du temps entre deux sorties, plusieurs mois, voire plusieurs années selon les projets. L'utilisateur lambda ne profitera donc pas immédiatement de l'amélioration, puisqu'il devra attendre la sortie de la nouvelle version pour pouvoir la télécharger. Cependant, il est aussi possible de profiter immédiatement des améliorations en compilant soi-même le programme dans sa version en cours de développement 9.

Pour citer un exemple concret, le cas de figure s'est produit dans mon travail aux Fées spéciales, pendant la production de *Dilili à Paris*. Au cours du layout, nous importions

<footnote>des studios lorsqu'ils les publient.</footnote>

<footnote n="9">9. Certains projets permettent aussi de télécharger chaque jour une version compilée du programme pour pouvoir utiliser les dernières mises à jour.</footnote>
dans Blender la bande-son de l'animatique pour vérifier que les mouvements étaient synchronisés avec les dialogues. Pour chaque plan*, nous produisions ensuite un rendu rapide (*playblast*), avec le son. Une fois le layout de chaque séquence* achevé, nous créions un montage incluant les plans. La bande-son de chaque plan était ainsi superposée avec celle de la séquence complète, et aurait dû correspondre parfaitement. Or, il y avait systématiquement un décalage d'une image. Après rapide enquête, l'équipe technique a conclu qu'il s'agissait d'un bug. Pour en avoir la certitude, nous avons ouvert le code source de l'opérateur qui s'occupait d'exporter le son, et avons constaté en effet que la logique était mauvaise. Flavio Perez, responsable technique, a ouvert un rapport de bug* sur le site des développeurs de Blender<fnref n="10" />. Il y explique le problème rencontré et suggère un patch*. De fait, les développeurs n'ont eu qu'à appliquer le correctif suggéré et à tester le logiciel. Sur cette page, il y a peu de commentaires, mais on constate que le bug a été corrigé trois jours après avoir été ouvert, week-end inclus.

Grâce à cela, nous avons pu utiliser la version que nous avions compilée en interne pour continuer notre production. Comme les versions bêta, les versions en cours de développement sont généralement moins stables que les versions officielles, et leur usage n'est pas recommandé en production, mais elles peuvent néanmoins être salvatrices pendant un projet.

Dans l'exemple précédent, le bug était trivial, et nous avons pu le corriger, même sans connaissances du langage de programmation ni du code. Pour des bugs plus complexes, nous aurions été incapables de trouver nous-mêmes la modification à faire, soit par manque de connaissances, soit par manque de moyens, car il faut y consacrer un temps dont on ne dispose pas toujours en production. L'exemple est néanmoins utile pour illustrer la possibilité qu'offre le logiciel libre de résoudre soi-même ses problèmes, et d'en faire profiter les autres utilisateurs.

Il existe d'autres exemples, toujours avec Blender, de modifications plus profondes apportées au logiciel, d'abord par un studio pour ses besoins propres, puis proposées aux développeurs, acceptées et intégrées dans le programme. Quelques-unes sont décrites

<footnote n="10">10. Le rapport de bug peut être trouvé à cette adresse : https://developer.blender.org/T49172</footnote>
dans la section II.2.2.2.

## Faire réparer par d'autres

La possibilité de modifier le code et de réparer un programme entraîne souvent une critique : tout cela est réservé à une élite capable de comprendre le code et de le modifier. Mais cette critique est décalée par rapport à la proposition du logiciel libre. Celle-ci ne dit pas que tout le monde doit être capable de modifier le code, mais que tout le monde en a le droit, quitte à demander à quelqu'un d'autre de le faire.

On peut faire une analogie avec un propriétaire de voiture, qui a le droit d'en ouvrir le moteur pour l'inspecter, et de le réparer s'il en est capable. S'il en est incapable, comme c'est souvent le cas, il a également la possibilité de la mener chez le garagiste, qui pourra faire les révisions ou améliorations nécessaires. En informatique, ce droit qui semblait naturel n'existe plus avec les logiciels propriétaires puisqu'ils ne sont pas la propriété de l'utilisateur<fnref n="11" />. Dans un écosystème de sources fermées, il est impossible d'envisager, comme le garagiste, des prestataires en mesure de réparer, de modifier ou d'améliorer le produit.

En revanche, le logiciel libre donne cette possibilité, et de fait il existe des sociétés dédiées au développement spécifique pour le logiciel libre. Ces sociétés dites « de services en logiciels libres » et détaillées par l'April dans [61], proposent du développement, du support et de la maintenance pour des logiciels métiers libres. Il n'en existe pas à ma connaissance dans le secteur de l'animation, mais elles pourraient se développer.

## Transparence du développement

Même pour les utilisateurs ayant une expérience solide de programmation, il est difficile de corriger des bugs dans un programme composé de millions de lignes de code inconnues. Il est donc plus efficace de demander aux développeurs qui connaissent déjà

<footnote n="11">11. Paradoxalement, cet état de fait s'étend aujourd'hui à d'autres produits que l'informatique, du fait de la présence d'ordinateurs dans un nombre croissant d'objet de consommation, y compris les automobiles.</footnote>
bien le code de le corriger eux-mêmes. L'organisation du développement open source permet à tous de suivre le développement.

Après avoir fait un rapport de bug*, l'utilisateur peut suivre la conversation dans un fil de discussion sur le site de développement du projet, et voir à quel endroit dans le code source* le problème a lieu. On peut ainsi estimer, en fonction des discussions (ou de l'absence de discussions), si le bug sera corrigé, et si oui avoir un délai approximatif, selon la priorité du bug pour les développeurs, et sa difficulté.

Grâce au développement public et en ligne, les utilisateurs non-développeurs, en particulier les graphistes ou leurs superviseurs qui seraient amenés à faire des rapports de bugs* aux développeurs peuvent au moins bénéficier d'une plus grande transparence qu'avec les logiciels propriétaires.

## Un risque pour le développeur-créateur

Un argument de développeur-créateur s'opposant à la liberté de modifier les programmes, est celui donné par Lucas Pope, développeur des jeux vidéo *Papers, Please* et *Return of the Obra Dinn*, dans son journal de développement pour ce dernier jeu. Sur le forum où il publie ce message, il explique les étapes de conception et de développement du jeu. Il utilise la version LT de Maya<fnref n="12" /> et se plaint des limitations artificielles de fonctionnalités imposées par cette version<fnref n="13" />, par rapport à la version complète, et les contournements qu'il est obligé de réaliser pour atteindre son but. Pourtant, quand un autre membre du forum lui suggère d'essayer Blender, qui n'a pas ce genre de limitations puisqu'il est open source, voici sa réponse [35] :

> « Je suis sûr que Blender, ou n'importe quel autre outil, a aussi des fonctionnalités manquantes. Changer de programme me ferait juste échanger les bizarreries d'un logiciel, et la manière de les contourner, contre celles d'un autre. Ce qui est important pour moi, c'est la difficulté de contourner ces limitations. Pour l'ins-

<footnote n="12">12. LT signifie *light*, légère. Il s'agit d'une version moins chère du programme, qui n'inclut pas toutes les fonctionnalités de la version complète.</footnote>

<footnote n="13">13. Il mentionne par exemple une fonctionnalité manquante, l'impossibilité de transférer l'animation d'un rig à l'autre en utilisant le rig HumanIK.</footnote>
tant, Maya LT n'est pas trop mal. Mais je vais certainement réessayer Blender et d'autres programmes après ce projet.

« Personnellement, Blender m'effraie un peu parce qu'il est open source et qu'il n'y a aucune limite à ce qu'on peut réparer soi-même. Au moins, avec Maya LT, je peux dire « c'est irréparable et il faut que je contourne le problème, et que je passe à autre chose ». Avec Blender, je serais capable de passer des jours à modifier les sources ou à écrire des plugins complexes. Amusant, mais contre-productif. <fnref n="14" /> »

Ce point de vue est celui d'un créateur de jeu vidéo indépendant qui a un niveau technique élevé pour avoir été développeur d'outils dans plusieurs studios. Il crée ses jeux pratiquement seul, conçoit le game design, et réalise toutes les étapes de création artistique, y compris les plus techniques, le développement, le son et la musique. Dans ce contexte, sachant que la création de ses jeux dure plusieurs années, et qu'il élabore déjà lui-même ses méthodes de fabrication avec ses propres outils, il est logique qu'il ne veuille pas en plus consacrer du temps à développer les suites de création 3D*, sans limite comme il le dit.

De tels arguments pourraient être repris à leur compte par des créateurs de films indépendants, mais le contexte au sein d'un studio (de jeu vidéo ou d'animation) est dif-férent, puisque les équipes sont plus nombreuses. Cela signifie que le développement d'un outil performant et réutilisable est d'autant plus profitable au projet et à la structure, que cet outil sera utilisé de nombreuses fois par de nombreuses personnes.

De plus, le développement est dans tous les cas indispensable aux studios d'anima-tion, et le choix de développer un outil en script* ou de modifier le code du programme appartient aux TD* ou à la R&D*, selon la facilité de mise en œuvre, les connaissances techniques de l'équipe, et les bénéfices techniques espérés. Dans un contexte d'entre-prise, la possibilité de se laisser entraîner à du travail intempestif est un problème de management. En d'autres termes, l'acte de modifier les sources du programme est un choix technique, stratégique et économique.

<footnote n="14">14. Traduction de l'auteur.</footnote>
Dépendance de l'utilisateur au développeur

Les exemples précédemment cités sont des cas documentés où le développement de
nouvelles fonctionnalités par un studio ou la correction de bugs a bien fonctionné, c'est-à-
dire que le code a été réintégré dans le programme amont*, et que toute la communauté
a pu en profiter. Cela implique que la proposition correspondait aux objectifs du dé-
veloppeur, autant en ce qui concerne le design (architecture, interface), que la qualité
du code. Ce cas de figure ne se présente pas toujours, car les développeurs de logi-
ciels libres doivent prendre en compte les besoins perçus de leur communauté, pour les
utilisateurs cibles. Il s'ensuit que certaines propositions de modifications ne sont pas
retenues. Par exemple, la fondation Blender a pendant des années déclaré que les utili-
sateurs visés étaient les indépendants solitaires, et éventuellement les petits studios <fnref n="15" />.
Les fonctionnalités de pipeline* permettant d'utiliser le logiciel dans un contexte de plus
grosse production manquaient, les développeurs de Blender ne considéraient pas de leur
responsabilité de les développer. Quelle qu'en soit la raison, et quel que soit le proces-
sus de gouvernance, ce sont les développeurs qui décident des critères pour inclure une
fonctionnalité.

Pour illustrer, Flavio Perez, directeur technique, raconte avoir souhaité pendant des
années l'intégration dans Blender de Qt, un ensemble de bibliothèques* permettant de
créer des interfaces graphiques. Qt est très utilisé par les autres logiciels du secteur, au
point d'être devenu un standard de fait <fnref n="16" />. Son intérêt est qu'une interface développée
avec Qt peut être rapidement portée dans un autre programme intégrant aussi Qt.
Cela augmente donc l'operérabilité* et permet de réduire les coûts de développement.
Flavio aurait souhaité voir la bibliothèque intégrée dans Blender, mais ses aspirations
n'étaient pas celles des développeurs de Blender. Il raconte sa rencontre avec eux :

« La première fois que j'ai été à la Blender Conference et que j'ai discuté avec des développeurs et que j'ai dit « C'est super Blender, mais il y a quelques trucs

<footnote n="15">15. La Blender Foundation, dans une communication officielle au salon Siggraph en 2013, définisait ainsi Blender : « Une solution de création 3D complète, libre et open source, pour les artistes indépendants et les petites équipes. » [23]</footnote>

<footnote n="16">16. On parle de « standard de fait » quand une technique n'est pas codifiée par un organisme de normalisation, mais très largement adoptée au sein d'une industrie.</footnote>
qui manquent pour que ça fonctionne en équipe [...] », je m'en suis pris plein la vue : « Ah non, c'est pas comme ça qu'on utilise Blender, il faut t'adapter à [sa] façon de faire [...] ». Et ce que je demandais, ce n'était même pas forcément une adaptation de Blender à une standardisation des autres, mais juste [...] laisser la porte ouverte à une autre façon d'utiliser le logiciel, plutôt que de la fermer. Et dire par exemple que si vous intégrez Qt dans Blender, ça veut pas dire que vous allez faire comme les autres, mais qu'on va pouvoir faire plus de choses que vous avez pas prévues. Et ce discours a été très mal entendu.<fnref n="17" /> »

En conclusion, malgré les difficultés afférentes à la possibilité de modifier le code source, cette liberté permet aux studios d'animation de résoudre des problèmes ou d'améliorer leurs outils, soit en modifiant eux-mêmes le code pour obtenir leur propre version, soit en demandant à un prestataire de faire ce développement pour eux. Cela réduit la dépendance vis-à-vis des éditeurs, et peut donc permettre aux studios de corriger les problèmes plus rapidement, y compris en cours de production.

### II.1.1.4 Distribuer

Cette quatrième et dernière liberté est à la fois celle dont les implications sont les moins souvent comprises, et celle qui donne tout leur sens aux logiciels libres et open source. En effet, sans la possibilité de publier un programme réutilisant du code, la portée en est limitée à un usage privé.

Pour qu'une collaboration entre des développeurs puisse s'établir, pour qu'ils créent ensemble un même programme, il faut que chaque développeur ait la capacité légale de redistribuer une œuvre dont il n'est pas l'auteur original. Pour que chacun puisse apporter sa pierre à l'édifice qu'est le programme, la somme des contributions, il doit exister un moyen légal de créer une œuvre dérivée. Chaque contributeur conserve le droit d'auteur de ce qu'il a écrit, mais offre aux autres, via la licence libre, le droit de l'utiliser.

<footnote n="17">17. Entretien semi-directif avec Flavio Perez, 6 février 2019.</footnote>
Le *source-available* n'est pas open source

On comprend souvent l'open source comme un programme dont le code peut être simplement lu, comme du code « ouvert ». Cette condition est insuffisante pour qu'un programme puisse être qualifié d'open source. Pour bien illustrer la distinction, je parlerai d'un autre modèle, celui des programmes à sources disponibles (*source-available*), souvent confondu avec le modèle open source.

Dans ce modèle de distribution, un développeur donne également à l'utilisateur la possibilité de consulter le code source*. La licence qui lie l'utilisateur à l'auteur lui permet de les télécharger, de les étudier et même de les modifier pour son propre bénéfice. Il peut aussi réparer ce qui ne marche pas et améliorer ce qui ne marche pas assez bien. Mais lorsqu'il fait une amélioration, il est le seul à pouvoir en bénéficier; il ne peut pas en faire profiter son voisin, ou a fortiori le monde entier. S'il décide malgré tout de redistribuer les sources modifiées, que ce soient les sources complètes, une partie du code, ou simplement un *patch* permettant d'obtenir la même fonctionnalité, c'est de la contrefaçon, et il s'expose à des poursuites. Dans ces conditions, ce qui fait l'open source, à savoir un contrôle partagé de la distribution, et un développement collaboratif, est impossible.

Le moteur de jeu vidéo d'Epic Games, Unreal Engine, parfois mentionné pour la possibilité offerte aux développeurs d'accéder aux sources, est par exemple disponible selon une licence *source-available*. Dans ce cas précis, la licence d'utilisateur final [32] stipule que l'on peut étudier et modifier le code, mais que la seule entité à qui il est permis de le redistribuer est l'éditeur, Epic. Cela signifie qu'il conserve non seulement un monopole commercial sur ses développements, mais qu'il acquiert également un monopole d'exploitation sur *toutes* les contributions à son moteur.

Un autre point illustrant la différence entre les licences source-available et les licences open source est l'incompatibilité entre les modèles de licences. En effet, quand on évalue des licences logicielles pour le libre, on prend en compte leur compatibilité avec d'autres licences, afin que du code publié sous une licence libre puisse être utilisé dans un autre projet libre, et ce même si les deux projets n'ont pas la même licence. On prend souvent
comme référence la GNU GPL, qui est parmi la plus ancienne, et une des plus drastiques.

Or, une licence comme le contrat d'utilisateur de l'Unreal Engine stipule qu'il est
interdit d'y intégrer les licences libres copyleft telles que GPL, ou Creative Commons
Attribution Share-Alike, deux licences copyleft fort. La raison est que tout programme
incluant du code sous licence copyleft fort est considéré comme une œuvre dérivée, et
doit être publié sous la même licence. Dans la mesure où l'utilisateur ne possède pas
le droit de redistribuer le code de l'Unreal Engine, il n'est pas en mesure non plus
de le distribuer sous licence libre. En revanche, il est tout à fait possible d'inclure du
code sous licence libre permissive, telles que les licences Apache, BSD ou MIT, car ces
dernières ne demandent pas que le code dérivé soit publié selon les mêmes conditions. Une
modification de l'Unreal Engine comprenant du code sous une de ces licences resterait
donc la propriété de son éditeur, Epic.

J'ai exposé dans cette section le modèle de distribution source-available, pour mieux
expliciter par contraste le modèle open source. La possibilité de redistribuer le code est
fondamentale pour permettre le développement collaboratif propre à l'open source, et
elle est aussi vitale pour la liberté de l'utilisateur chère au logiciel libre. En effet, sans
cette liberté, les améliorations des contributeurs ne leur appartiennent pas, mais à un
éditeur, et il est alors impossible d'en profiter comme d'un bien commun.

## II.1.2 Pérennité du code et maintenabilité

### L'accès à ses propres données

Dans tous les domaines utilisant l'informatique, la pérennité des outils est un facteur
fondamental dans le choix d'une solution technique. Si j'adopte un outil dans mon work-
flow, j'attends de pouvoir l'utiliser pendant longtemps, si possible indéfiniment, ou au
minimum que les données que je crée restent compatibles avec d'autres systèmes que je
pourrais utiliser plus tard (operérabilité). L'informatique évolue vite, particulièrement
dans le secteur de l'animation, où de nouveaux programmes apparaissent régulièrement,
et où d'anciens programmes cessent d'être supportés, parfois du jour au lendemain.
Un exemple typique est celui de Softimage|XSI, un logiciel d'animation très utilisé par les studios d'effets spéciaux ou de jeux vidéo dans les années 2000-2010. Il était originellement développé par la société Softimage, Co. Celle-ci a été rachetée plusieurs fois au cours des années 1990, et la dernière fois en 2008 par Autodesk. Suite à ce rachat, le programme a continué à être développé jusqu'en 2014, quand Autodesk a annoncé à la surprise générale que le programme ne serait plus vendu. Cela signifiait aussi qu'il ne serait plus ni développé, ni supporté, ni maintenu. La raison officielle donnée par Autodesk pour cet abandon est que la fin du programme permettrait à l'éditeur de concentrer ses efforts sur ses autres produits, Maya et 3ds Max, et en faire de meilleures solutions.

Les utilisateurs du programme se sont donc retrouvés avec la dernière version du programme, sans possibilité de le voir continuer à s'adapter au marché, aux dernières technologies, ni même de voir les bugs corrigés. En effet, Autodesk est toujours proprietary du code de Softimage. Les studios ont donc eu plusieurs choix. Ils pouvaient continuer d'utiliser une version vieillissante et fatalement de moins en moins compatible à cause de l'érosion logicielle<fnref n="18" />, mais cette solution n'aurait été bonne qu'à court terme, le temps d'un projet ou deux, puis serait devenue ingérable ensuite. L'alternative était donc de changer de logiciel pour les productions suivantes, sans doute selon un remplacement graduel dans le pipeline*. Il va sans dire que quand un pipeline mûr est fondé sur un logiciel donné, il est extrêmement long et coûteux de le remplacer par un autre, puisque les outils de création graphique et les processus d'échange de données doivent être en grande partie, voire intégralement repensés et réécrits, et les graphistes formés à nouveau. L'abandon du développement de Softimage a donc coûté cher à bon nombre de studios, mais également fait prendre conscience de la grande dépendance des utilisateurs envers les éditeurs de logiciels.

Il est fréquent que le développement de logiciels libres soit aussi abandonné, pour diverses raisons : par exemple, faute de financement, ou par manque de temps ou d'intérêt des développeurs. Mais la différence fondamentale est que si le développement d'un

<footnote n="18">18. L'environnement qui continue à évoluer tandis que le programme stagne.</footnote>
logiciel libre s’arrête, il est toujours possible à d’autres développeurs ou aux utilisateurs
eux-mêmes, de continuer à en faire la maintenance, du moment qu’une copie du code
source soit encore accessible. Ils peuvent au minimum corriger les bugs et le garder
compatibles, ou continuer à développer des fonctionnalités et à le faire évoluer.

Bien sûr, les logiciels d’animation sont très complexes, et en reprendre le développement en cas d’abandon serait une tâche très lourde. Il faudrait être appuyé par une solide structure financière ou une communauté très impliquée, ce qui pourrait rendre faible la possibilité d’une continuation. Mais avec du code libre, c’est du moins légalement possible.

D'autre part, même si le développement d'un logiciel libre était complètement arrêté
du jour au lendemain, les utilisateurs pourraient a minima continuer à se procurer la
dernière version en date, et ouvrir ainsi leurs fichiers de production pour les convertir vers
d'autres systèmes de création. Même cette possibilité n'est pas garantie avec un logiciel
propriétaire s'il n'est plus commercialisé, en particulier lorsque le format de fichier n'est
pas libre (sans code source ni spécification publique, ou breveté). De plus, avec un modèle
de distributon de type cloud, du moment que le serveur de l'éditeur ne peut plus activer
le programme, il devient impossible de l'utiliser, et donc d'accéder à ses anciens fichiers,
et à sa propre propriété intellectuelle.

Libération du code

Blender était à l'origine un logiciel propriétaire, développé au sein d'un studio d'animation. Une tentative de commercialisation a échoué, et le logiciel allait être abandonné au début des années 2000, quand une campagne de financement participative a permis de lever des fonds pour racheter à son éditeur les droits afin de le rendre disponible sous la licence libre GNU GPL. On pourrait donc imaginer une solution similaire pour un autre logiciel commercial.

Outre le coût de développement substantiel que représenterait la libération d'un programme comme XSI, un tel changement de licence doit être mûrement réfléchi. En effet, un programme incluant une bibliothèque* non-libre ne peut pas devenir libre sans que
cette bibliothèque ne le soit aussi. L'éditeur voulant libérer du code dans ces conditions
devra obtenir qu'elle lui soit fournie sous une licence libre, c'est-à-dire en demander la
permission ou négocier avec les auteurs de la bibliothèque. Or, ces derniers n'ont pas
forcément envie que leur œuvre soit libre. Ainsi, le responsable de la division « industrie
du spectacle » à Autodesk, Maurice Patel, répondant dans un entretien à une question
sur l'avenir de Softimage et la possibilité de le vendre ou de le faire développer par une
autre société, explique [65] :

« On ne va pas se contenter de balancer le logiciel [à une autre société] avant de
s'enfuir, et nous ne pouvons pas le faire. Il y a trop de choses intégrées au logiciel
pour qu'on puisse le faire sans danger. On s'est posé la question de rendre open
source, non seulement Softimage mais aussi d'autres applications, mais ce genre de
choses n'est pas trivial. Il y a les codebases, de la propriété intellectuelle tierce, et
il faut qu'on passe tout ça en revue pour comprendre d'où viennent ces propriétés
intellectuelles, etc. Donc toute transition demandera de notre part des ressources
et la question est : cela vaut-il le coup ?<fnref n="19" /> »

Le reste de l'entretien est très éclairant sur les priorités commerciales que donne un
éditeur comme Autodesk à ses différentes divisions, et les raisons qui le conduisent à
prendre la décision inopinée d'en fermer une. En substance, il explique que la décision a
été prise très rapidement pour répondre aux changements rapides de la haute technologie.
Il ajoute que malgré tous les efforts de la part d'Autodesk pour réduire les coûts du
développement, c'est-à-dire le délocaliser à Singapour, le programme n'était pas assez
rentable. Enfin, qu'il était en compétition avec deux autres logiciels du même éditeur,
Maya et 3ds Max, pour les ressources de développement. Il conclut sur la question
de la possibilité de revendre le logiciel : il explique que la société l'avait acquis pour
bénéficier de la propriété intellectuelle et de l'expertise des ingénieurs, et que les concepts
de Softimage étaient aussi utilisés dans les autres programmes d'Autodesk. Pour cette
raison, la société n'avait aucune intention de le revendre — même si cela provoquait des
ennuis pour leurs clients utilisateurs de Softimage.

<footnote n="19">19. Traduction de l'auteur.</footnote>
Sans aller jusqu'à dire que le logiciel propriétaire met systématiquement en danger
ses utilisateurs, car tous n'ont pas la même politique et que ce type d'abandon est malgré
tout assez rare, il n'en reste pas moins indéniable que rien ne garantit aux utilisateurs
la pérennité des programmes propriétaires, ni le droit de continuer à accéder à leurs
propres données. Il est intéressant de comparer avec le cas de logiciels libres comme
Krita ou Blender, qui ne peuvent pas subir d'abandon irrévocable, du fait qu'ils soient
sous licence GPL. Dût le développement cesser, quelqu'un d'autre aurait toujours le droit
de le reprendre, ou bien de récupérer des parties pour les intégrer à un autre programme.

II.1.3 Choix des licences

Pour qu’un logiciel soit considéré comme libre, il faut qu’il soit publié selon les termes d’une licence libre (cf. section I.2.2.4). Parmi les nombreuses licences libres, il est difficile de savoir laquelle ou lesquelles choisir pour publier du code. La langue dans laquelle elles sont écrites est celle des juristes, et leurs implications sont rarement claires pour le profane. De plus, les plus courantes ne sont pas rédigées en français mais en anglais, et qui plus est, conçues pour le copyright états-unien et non pour le droit d’auteur français. Elles peuvent tout de même s’appliquer plus ou moins directement aux œuvres ou aux contributions françaises, mais il faut être vigilant.

Nous aborderons ici les grandes catégories de licences existantes, et celles qui sont
utilisées par les créateurs de logiciels libres et par les studios.

II.1.3.1 Licences *Copyleft*

La première catégorie historique de licences libres est dite copyleft. La licence GNU General Public License (GPL) en est l'exemple le plus connu et le plus répandu. Les licences de cette catégorie reposent sur le principe de copyleft, qu'on pourrait à peu près traduire par « abandon du droit de copie », et qui est en anglais un jeu de mot avec le copyright, et les mots pour droite et gauche. Elles exposent ainsi la volonté de créer un modèle de propriété intellectuelle différent du modèle traditionnel dans lequel les
auteurs renoncent à une partie de leurs droits sur leurs œuvres, au profit des utilisateurs et d'autres développeurs.

Le principe de base d'une licence copyleft est que toute modification du programme doit être redistribuée selon les termes de la même licence. Cela entraîne plusieurs conséquences. D'abord, c'est une garantie légale que le code reste libre. En effet, si je publie un programme sous une licence copyleft, personne n'a le droit d'en modifier la licence <fnref n="20" />. Si quelqu'un modifie mon programme, et qu'il choisit de redistribuer sa version modifiée du programme, il sera donc obligé d'utiliser la même licence copyleft. Si j'ai choisi par exemple la licence GPL, cela signifie également que le programme devra impérativement être au moins distribué sous forme de code source*, et éventuellement sous forme binaire. De ce fait, les utilisateurs ont la garantie de pouvoir lire le code qu'ils utilisent, de pouvoir le modifier et le redistribuer (cf. section II.1.1).

Ensuite, si je veux inclure du code sous licence copyleft dans un programme, je ne peux le faire qu'à la condition que les licences soient compatibles, c'est-à-dire que les différentes licences n'aient pas de clauses mutuellement exclusives. Typiquement, si j'utilise du code écrit par quelqu'un d'autre et publié sous une licence copyleft, qu'il s'agisse d'une partie d'un programme ou d'une bibliothèque* liée dans une application, je dois impérativement publier également mon programme sous la même licence, puisqu'il est considéré comme dérivé du code que j'ai réutilisé. Cela signifie que je ne peux pas publier mon code sous licence propriétaire. C'était le but initial du logiciel libre de Richard Stallman, qui souhaitait empêcher l'appropriation du code. Cela entraîne aussi que je ne peux pas publier mon programme sous une autre licence open source.

Ce fait suscite des opinions divergentes sur les licences copyleft : d'une part, en empêchant l'appropriation du code, elles garantissent une liberté inaliénable aux utilisateurs. D'un autre côté, elles empêchent d'utiliser le code de n'importe quelle façon, et certains développeurs ont le sentiment d'y perdre une partie de leur liberté.

Un bon exemple est celui du moteur de jeu libre Godot. Il s'agit d'un environnement

<footnote n="20">20. En tout cas, personne ne vivant dans un pays respectant les droits d'auteur via la convention de Berne. En pratique, la question peut être plus complexe puisqu'elle dépend des systèmes juridiques et de la jurisprudence.</footnote>
de développement de jeu vidéo, avec un logiciel d'édition permettant de concevoir les graphismes, le son, la logique, et le code du jeu vidéo. Les jeux vidéo sont des programmes, et donc protégés par le droit d'auteur. Ils peuvent donc, comme tous les programmes, être protégés par des licences logicielles. Or, en utilisant un moteur de jeu pour créer son jeu vidéo, le développeur intègre une partie de ce moteur dans le jeu : par exemple, les jeux vidéo utilisant le moteur Unity intègrent du code écrit et possédé par Unity. Pour Godot, cela signifie que le jeu vidéo intègre du code sous licence libre. Si la licence choisie pour Godot avait été copyleft, GPL par exemple, tous les jeux vidéo créés avec Godot seraient nécessairement sous GPL également, puisqu'ils intégreraient du code du moteur. Cela pose problème à l'immense majorité des développeurs de jeux qui souhaitent garder un monopole d'exploitation sur leur jeu, monopole impossible à obtenir avec la licence GPL.

Godot a donc été publié sous une licence permissive (cf. section II.1.3.2), une catégorie imposant comme son nom l'indique des conditions d'utilisation beaucoup moins contraignantes aux utilisateurs.

## Copyleft fort et copyleft faible

Dans la catégorie des licences copyleft, il existe une subdivision entre les copylefts dits forts et faibles. La licence GPL évoquée précédemment fait partie de la première catégorie : lorsqu'un programme utilise du code sous licence GPL, il doit nécessairement adopter la même licence, même si le code dérivé n'intègre pas directement le code d'origine. C'est par exemple le cas des bibliothèques*. Une bibliothèque sous licence GPL forcera les développeurs qui feraient appel à des fonctions de la bibliothèque à publier leur code sous la même licence GPL.

La condition de redistribution sous la même licence ne s'applique pas de la même manière pour les licences copyleft faibles. En effet, elles demandent également de redistribuer une version dérivée sous la même licence, mais permettent d'utiliser des fonctions d'une bibliothèque externe sans que les termes s'appliquent à l'ensemble de l'application qui utilise ces fonctions. La Lesser General Public License (LGPL) est un exemple de
licence à copyleft faible, préconisée par ses auteurs de la Free Software Foundation pour
les bibliothèques logicielles. Ainsi, si je développe une application et que je lie<sup>21</sup> une
bibliothèque sous licence LGPL, je ne serai pas obligé de distribuer mon programme
sous la même licence, et je pourrai donc choisir, par exemple, une licence propriétaire.
En revanche, je devrai redistribuer le code source des éventuelles modifications que je
pourrai faire à la bibliothèque elle-même.

II.1.3.2 Licences permissives

Les licences permissives, au contraire des licences copyleft, ne demandent pas la redistribution dans les mêmes conditions. Il en existe un grand nombre, dont les plus répandues sont les licences MIT (Massachusetts Institute of Technology), Apache, BSD (Berkeley Software Distribution), chacune pouvant avoir des variations.

Ces licences sont souvent plus courtes, beaucoup plus souples, et permettent en
particulier de changer la licence d'une version dérivée. Cela a également des conséquences
importantes pour la publication de programmes. Les sources peuvent être intégrées avec
d'autres codes sources, qu'ils soient libres ou propriétaires, et devenir donc elles-mêmes
propriétaires. Ces licences ne demandent pas une redistribution sous forme de code
source. Elles permettent donc de modifier un programme, en général à la simple condition
que le programme dérivé inclue les noms des auteurs et les termes de la licence. C'est
pourquoi les logiciels propriétaires utilisant du code sous licence permissive donnent
accès à une liste de licences et de noms d'auteurs<sup>22</sup>, pour chaque composant utilisé dans
le programme.

Pour revenir à l'exemple de Godot, publié sous licence MIT, les œuvres dérivées que
sont les jeux vidéo peuvent être publiées sous n'importe quelle licence, y compris pro-
priétaires, à condition que les utilisateurs puissent lire le texte de la licence quelque part
dans le programme. Cela règle le problème des développeurs voulant exploiter commer-

<footnote n="21">21. Lier du code à un programme (de l'anglais *link*) est une opération réalisée à l'aide d'un programme spécialisé, l'éditeur de liens, qui crée l'exécutable final à partir des différents composants compilés au préalable. Dans le cas présent, l'exécutable inclut donc la bibliothèque préexistante.</footnote>

<footnote n="22">22. Liste que personne ne lit jamais, à part peut-être certains développeurs.</footnote>
cialement leur jeu vidéo en utilisant un modèle économique propriétaire habituel, et sans
que leur programme puisse être modifié plus qu’ils ne le souhaitent.

Comme la majorité des programmes de 3D, Godot s’appuie sur des bibliothèques*
pour proposer des fonctionnalités ou faciliter le développement. Le choix d’une licence
permissive signifie aussi que les développeurs de Godot ne peuvent pas utiliser de biblio-
thèque sous licence copyleft sans être forcés d’utiliser la même licence, ce qui nuirait, on
l’a vu, à la possibilité des créateurs de jeux de publier sous licence propriétaire.

L'exemple de Godot est intéressant parce qu'il permet d'aborder le statut d'œuvre d'art des programmes. Un jeu vidéo est plus souvent reconnu comme une œuvre d'art que la plupart des logiciels métiers, programmes industriels, ou n'ayant pas de vocation artistique. Il peut donc sembler logique de protéger la vision artistique de son créateur, comme il est rare de voir des réalisateurs accueillir avec bienveillance des changements sur leur film, ou une distribution non autorisée 23.

Il existe bien des jeux vidéo libres, mais ce sont en général des projets financés par les
dons, par crowdfunding ou pas financés du tout, et qui n'ont pas pour vocation de créer
un monopole d'exploitation. À l'inverse, Godot, comme la plupart des moteurs de jeu, a
pour vocation d'être utilisé par des studios pour développer des produits commerciaux,
et l'opinion des développeurs de Godot est que cela serait impossible en utilisant une
licence copyleft, puisque le jeu serait immédiatement redistribuable par tout acquéreur.

II.1.3.3 Exemple de publication : un script pour Blender

Pour les studios d'animation, ces questions de licences peuvent sembler hors de pro-
pos, mais dès lors qu'une partie de leur activité est la publication ou la contribution à
des projets open source, il est indispensable de connaître le sujet.

En effet, c'est la licence du programme qui régira les droits accordés aux utilisateurs.
Il arrive souvent de vouloir publier un petit script* ou un bout de code, sur un forum par
exemple, dans l'idée qu'il puisse être utile aux lecteurs. Le processus n'est pas forcément
aussi évident cependant, et outre le choix de la licence, il y a une procédure pour publier

<footnote n="23">23. Distribution qui constitue légalement une contrefaçon.</footnote>
du code libre.

Afin d'illustrer le processus du choix et de la publication sous licence libre, j'abor-
derai l'exemple d'un script* pour le programme Blender, qui présente des particularités
intéressantes.

Pour qu'un programme puisse être publié sous licence libre, il faut avant tout qu'il soit protégé par le droit d'auteur, puisque les licences libres utilisent le droit d'auteur pour conférer des libertés aux utilisateurs. Le droit d'auteur s'applique par défaut à toute œuvre originale, mais il vaut mieux que le nom de l'auteur du script soit identifiable dans le code lui-même, généralement dans l'en-tête. En pratique, cette mention ressemble à ceci :

# Copyright (C) 2019 Les Fées Spéciales
# voeu@les-fees-speciales.coop

Ces lignes sont écrites à l'intérieur du script. Les croisillons # signifient dans la syntaxe du langage Python que les lignes en question sont des commentaires, et ne seront donc pas exécutées avec le programme.

Dans le cas d'une société, comme ici par exemple Les Fées spéciales, c'est la personne morale qui est considérée, et non pas les personnes physiques travaillant pour l'entreprise et ayant écrit le script.

Le fait de préciser la paternité de l'œuvre est insuffisante pour conférer de quelconques droits aux utilisateurs, sinon éventuellement la lecture du code. En effet, la protection du droit d'auteur auquel est soumis le code dans de nombreuses juridictions, y compris le droit français, empêche notamment la modification et la redistribution, qui pourrait être qualifiée de contrefaçon. Pour attacher une licence à du code source*, il faut procéder à deux étapes :

1. Mentionner la licence en tête des fichiers sources, et

2. dans le cas où le projet ne serait pas un fichier unique, il est d'usage d'ajouter également à la racine du dossier du projet un fichier nommé LICENCE, ou LICENSE pour un projet international (anglophone).
Il faut donc nécessairement une licence. En général, les éditeurs de logiciels propriétaires écrivent ou font écrire une licence spécifique pour un logiciel, souvent appelée EULA (End-User License Agreement ou accord de licence de l'utilisateur final).

Quand les Fées spéciales ont commencé à publier des scripts sous licence libre, elles ont consulté un avocat spécialiste de la propriété intellectuelle 24, qui a conseillé d'utiliser une des licences CeCILL, corédigées par le CEA, le CNRS et l'INRIA. Ces licences ont un grand intérêt pour les sociétés françaises : elles sont rédigées en français et tiennent compte du droit français, et sont donc mieux à même de faire respecter les termes de la licence devant la loi. Il en existe plusieurs variantes, dont une à copyleft fort 25 (CeCILL-A), une licence permissive (CeCILL-B), et une à copyleft faible (CeCILL-C)25.

Au début, le code écrit en production a donc été publié sous la licence CeCILL-A. Mais un élément m'a poussé à reconsidérer ce choix, en accord avec les décisionnaires de la société, pour les scripts Blender. En effet, Blender est publié sous la licence copyleft fort GNU GPL. Cela signifie que non seulement le programme, mais également les scripts doivent nécessairement être publiés sous la même licence. La FAQ de Blender [28] explique :

> « If you share or publish Python scripts they have to be made available compliant to the GNU GPL as well, if they use Blender Python API* calls. »

> « Si vous partagez ou publiez des scripts Python — s'ils utilisent des appels à l'API de Blender — ils doivent également être disponibles en accord avec la [licence] GNU GPL. » Il y a deux raisons pour lesquelles les scripts doivent être publiés sous cette licence.

D'abord, dès lors qu'un script Blender inclut la ligne de code `import bpy`, il lie la bibliothèque* `bpy` (en terminologie de Python, on parle de *module*). C'est le cas de la quasi-totalité des scripts pour Blender, puisque c'est par ce module que sont exposées les fonctions de Blender. Cela signifie qu'un script Blender est légalement considéré comme une œuvre dérivée du module `bpy`.

<footnote n="24">24. Comme devrait le faire toute société publiant du code, tant la question peut être complexe.</footnote>

<footnote n="25">25. Cf. section II.1.3.1.</footnote>
Ensuite, la licence GPL étant copyleft, elle inclut une clause empêchant l'utilisateur
de republier le code sous une autre licence [64]. En cas de modification et de publication
d'un fichier source sous licence GPL, il faut impérativement le rendre disponible sous la
même licence.

Puisque le script est dérivé de Blender et que tout dérivé doit être publié sous la
même licence, il découle logiquement qu'un script Blender doit être distribué dans les
mêmes conditions, sous licence GNU GPL.

Cette conclusion est somme toute d'ordre légale et théorique. En pratique, il est
rare que le fait d'utiliser du code trouvé sur Internet aille jusqu'à une action judiciaire.
Néanmoins, lors de la publication d'un script Blender sans licence GPL, les auteurs
de Blender, principalement la Blender Foundation, mais également de nombreux autres
contributeurs, pourraient demander de supprimer le code ou de le publier sous licence
GPL. Quoique peu probable, ils pourraient également intenter un procès.

De même, pour un morceau de code sous licence GPL trouvé sur Internet, sur un
forum par exemple : si ce bout de code est clairement identifiable et attribué à quelqu'un,
et que ce bout code est utilisé dans un programme, l'auteur original peut intenter un
procès si le script n'est pas couvert par la même licence.

Bien que faible, le risque existe, et augmente avec l'audience d'un programme, et
éventuellement ses revenus.

Une autre raison d'utiliser la GPL, outre l'obligation légale liant le développeur aux auteurs originaux, est que c'est dans l'esprit du logiciel libre : s'appuyer sur du code libre pour utiliser, étudier, modifier et distribuer de nouvelles idées au public.

Cet exemple complexe montre bien les difficultés que présente le choix de licence, et
l'intérêt que peuvent avoir les studios à consulter des spécialistes dès lors qu'ils souhaitent
publier du code. Chaque situation est différente, selon le pays, le type de programme
(application, script, bibliothèque), l'utilisation éventuelle de code couvert par une licence
libre, et la vision qu'a l'auteur du logiciel libre et open source.
II.1.4 Œuvres sous licence de libre diffusion

Une question fréquente à l'intersection des milieux de la création et du logiciel libre est celle de la publication de contenus libres, dans d'autres domaines que le logiciel. Dans une réflexion proche de celle des logiciels libres, les licences de libre diffusion ambitionnent de changer la manière d'utiliser le droit d'auteur pour protéger les œuvres, et d'en faire des biens communs plutôt que d'en conserver la jouissance exclusive à leurs auteurs.

Ce type de licences tire son nom du fait que les œuvres les utilisant peuvent être librement diffusées, sans nécessairement correspondre à la définition stricte de la licence libre. Concrètement, certaines licences de libre diffusion permettent de redistribuer une œuvre, mais pas de la modifier, ni de créer des versions dérivées ou des œuvres composites. D'autres permettent la modification, mais interdisent une utilisation commerciale. On pourrait dire que sur les quatre libertés du logiciel libre (cf. section II.1.1), les licences de libre diffusion ne retiennent que celles d'utiliser, d'étudier, et parfois de redistribuer dans certaines conditions. Les licences libres sont donc des licences de libre diffusion, mais l'inverse n'est pas forcément vrai.

Les licences de la famille Creative Commons sont les plus connues parmi celles qui visent à protéger des œuvres autres que du code source. Elles suivent un principe similaire à celui des licences de logiciels libres, mais sont recommandées pour tout type de documents (images, vidéos, sons, textes, etc.). Elles exploitent également les mécanismes de copyright pour permettre de réutiliser, remixer et modifier les œuvres. Elles peuvent en principe répondre à des enjeux sociaux tout comme les logiciels libres, mais elles ont des obstacles propres.

Le logiciel open source existe depuis maintenant des décennies et a démontré son efficacité. Les développeurs y sont acculturés, et il pénètre toute l'industrie informatique. C'est d'ailleurs de ce milieu que proviennent les licences de libre diffusion pour les œuvres. La culture open source ou libre ne s'étend pas encore généralement aux producteurs de contenus, mais des initiatives existent, y compris dans le milieu de l'animation.

La plus visible de ces initiatives est celle de la Blender Foundation, l'organisme initialement chargé de la coordination du développement du logiciel Blender, qui développe
également depuis 2005 des projets de films animés. Ces productions ont plusieurs buts.
D'abord, dans le cadre du développement de Blender, d'améliorer la qualité du pro-
gramme en l'utilisant en conditions réelles, c'est-à-dire pour créer un film. L'équipe des
films de la Blender Foundation est en effet composée de graphistes professionnels, enga-
gés pour le temps du projet, et de développeurs. Ils travaillent ensemble : les graphistes
rapportent les bugs qui surviennent, et peuvent faire des demandes aux développeurs
pour améliorer des fonctionnalités existantes ou en implémenter de nouvelles. Les amé-
liorations faites dans le cadre du projet sont ensuite reversées dans la version publique.
Ainsi, la dernière version de Blender, 2.8, a beaucoup bénéficié d'un de ces projets,
*Spring*, sorti début 2019. L'équipe a commencé le film en utilisant la version précédente,
et basculé en cours de production vers la nouvelle, alors que beaucoup de fonctionna-
lités précédemment disponibles étaient en train d'être ré-implémentées, que l'interface
changeait chaque jour, et que le programme était généralement instable. Cette situation
inconfortable pour l'équipe a néanmoins permis au développement d'aller à une grande
vitesse, compte tenu de l'ambition de cette nouvelle version.

Ce paradigme de production, consistant à faire un film pour développer un pro-
gramme, est parfois adopté par d'autres éditeurs, en particulier de moteurs de jeux
comme Unity et Epic Games 26. Il semble évident que ce paradigme n'est pas adapté de
manière générale pour les studios, dont l'activité principale est de faire des films et non
des logiciels de création.

Le deuxième but affiché par les projets de la Blender Foundation est de créer une
vitrine technologique pour le programme, en montrant qu'il est possible de créer du
contenu de haute qualité avec Blender et d'autres logiciels libres. Ce deuxième but a
été largement atteint, comme le montrent plusieurs indicateurs. Les films de la Blender
Foundation, s'ils ne sont pas aussi connus que les courts-métrages du studio Pixar, par
exemple, ont néanmoins joui d'une forte diffusion sur Internet et au-dehors, avec des
millions de vues sur les plate-formes de vidéos comme YouTube. En effet, outre leurs

<footnote n="26">26. Il existe au sein d'Unity une équipe spécifiquement dédiée à la production de films et au développement du programme dans cette optique. Cette équipe a réalisé un film en utilisant et en développant Unity, Adam [42].</footnote>
qualités techniques et artistiques, ils en ont une autre, beaucoup plus rare : la licence
sous laquelle ils sont publiés, qui permet leur diffusion et leur réutilisation sans devoir
obtenir une autorisation. Ils ont été utilisés pour tester des algorithmes de traitement
d'image ou de vision par ordinateur, pour des démonstrations d'écrans et de téléviseurs
dans des salons, etc. Ils ont donc une grande valeur pour différentes industries, du fait
de leur libre diffusion.

Leur financement n'est pas non plus tout à fait conventionnel. En plus de subven-
tions publiques classiques de l'État néerlandais, les projets de la Blender Foundation ont
fait l'objet de campagnes de financement participatif, soit par la prévente des supports
vidéo (DVD, téléchargement), soit plus tard par un abonnement à un service de télé-
chargement de contenus pédagogiques, de films et d'éléments 3D, le Blender Cloud. Le
financement participatif n'est pas un phénomène nouveau, ni dans le divertissement, ni
en informatique, puisqu'en particulier Blender avait pu libérer son code source* en 2002
grâce à une telle campagne. Néanmoins, il est intéressant de mettre en regard ce modèle
de financement avec celui de la diffusion des films, puisque, tout comme les logiciels
libres, non seulement les individus ayant participé au financement du film peuvent se
l'approprier, mais tous les autres aussi peuvent regarder, télécharger, modifier, redistribuer
le film en vertu des termes de la licence Creative Commons Attribution.

Une autre source de financement à mentionner est celle qui a eu lieu pour le film
Sintel, qui a consisté à crowdsourcer une partie du travail de modélisation d'assets*. Les
créateurs du film ont demandé aux utilisateurs de Blender, via les canaux d'information
de la communauté, de les aider à modéliser des éléments de décor, qu'ils ont utilisés
dans le film. De cette manière, les coûts sont réduits puisqu'une partie des graphistes
est amatrice et bénévole. Il est douteux que ce procédé soit généralisable, à moins de
fédérer une forte communauté autour d'un studio ou d'un projet.

À l'heure actuelle, ces modèles de financement, s'ils sont très adaptés aux films de la
Blender Foundation en tant que développeur de logiciel, rencontrent des obstacles dans
le cadre de studios d'animations. Comme le souligne Flavio Perez, la Blender Foundation
elle-même est en train de se restructurer afin de développer son activité de production
de films sous une nouvelle entité, le Blender Animation Studio, et rencontre ce même
obstacle pour produire son premier long-métrage<fnref n="27" /> sous licence de libre diffusion :

« Il y a des initiatives. Mais là par exemple, même la Blender Foundation a renoncé [à la diffusion sous licence de libre diffusion]. Ils savent très bien que leur long-métrage ne pourra pas être libre comme ils le souhaitent. Déjà parce qu'ils achètent la propriété intellectuelle d'un personnage à quelqu'un [le personnage de bande dessinée, l'agent 327], et ensuite parce que Ton Roosendaal [président de la fondation] l'a très bien dit, si on rend le film libre dès le premier jour, personne ne va vouloir nous l'acheter pour le sortir en salle. Puisqu'il sera librement disponible sur Internet, librement redistribuable, personne ne va vouloir nous acheter les droits DVD. Personne ne va vouloir nous acheter les droits d'exploitation en salle. Même Netflix, ça ne l'intéressera pas, puisqu'ils n'ont pas l'exclusivité. [...] que faire avec le contenu ? Si même la Blender Foundation n'a pas encore répondu à ces questions... je crois qu'on ne peut pas y répondre, nous, directement. <fnref n="28" /> »

En général, dans un studio d'animation les droits d'exploitation des œuvres com-
manditées par les clients se négocient, et peuvent appartenir soit aux auteurs, soit aux
clients. Cela implique qu'une publication sous licence libre doit être préalable à la créa-
tion. Cette décision peut avoir des conséquences importantes sur la vente du contenu, et
n'est pas nécessairement bien vue par le client.

Cette expérience n'a pas eu lieu au sein des Fées spéciales, car la plupart des travaux
réalisés étaient en prestation pour un client. Pour pouvoir proposer une telle solution,
il faudrait soit que le client soit déjà favorable à ce type de publication, soit que nous
puissions le convaincre de son bien-fondé, notamment économique, et que des contraintes
externes ne l'empêchent pas de prendre cette décision (producteurs et diffuseurs, pouvoir
publics dans le cas d'un appel d'offre, etc.).

Il serait sans doute plus envisageable de faire une expérience limitée dans ce do-
maine pour les projets produits en interne par la structure, mais là encore la décision

<footnote n="27">27. Ce film, intitulé *Agent 327*, est adapté d'une bande dessinée néerlandaise de Martin Lodewijk. Un court-métrage faisant office de *teaser* et produit par la Blender Foundation est déjà sorti en 2017, et en 2019 le long-métrage est en phase de financement.</footnote>

<footnote n="28">28. Entretien semi-directif avec Flavio Perez, 6 février 2019.</footnote>
dépendrait de la volonté des financeurs et diffuseurs. Ce n’est pas encore la voie qu’a
choisie l’entreprise, qui s’est jusque-là concentrée sur l’élaboration de pipelines* libres
et la contribution au libre, mais c’est une piste d’exploration pour les nouvelles formes
de production et d’exploitation.

Conclusion

Comme nous l'avons vu en début de ce chapitre, le but du logiciel libre est de garantir
à ses utilisateurs des libertés lui permettant de s'affranchir de l'éditeur. En lui permettant
d'utiliser le programme comme bon lui semble ; d'apprendre comment il fonctionne en
l'étudiant ; de le modifier pour le rendre plus adéquat à ses propres besoins et de le
garder à jour ; et enfin de redistribuer ses modifications pour contribuer à son essor au
sein d'une communauté, le logiciel libre change complètement la manière de consommer
le logiciel.

Le logiciel libre n'a pas pour but de fidéliser des clients, mais de rendre plus auto-
nomes des utilisateurs, ou simplement de créer un logiciel très performant dans le cas
de l'open source. Il permet donc souvent de résoudre des problèmes de compatibilité,
d'interopérabilité, et de pérennité des données.

En contrepartie de ces avantages, l'utilisation du logiciel libre demande aux utili-
sateurs de s'habituer à sa culture, particulièrement pour les plus avancés, qui seraient
amenés à contribuer du code. Pour ceux-là, il est presque nécessaire d'avoir des solides
notions de propriété intellectuelle pour comprendre le principe de fonctionnement des
licences logicielles, les engagements pris vis-à-vis des auteurs et des autres utilisateurs,
et les droits que l'auteur renonce, en contribuant, à faire valoir sur son œuvre.
# Chapitre II.2

## La place du libre dans l'économie des studios d'animation

### Introduction

Pour les studios, comme pour toutes les entreprises fondant leur production sur le numérique, le logiciel est fondamental dans la stratégie économique. Acquérir des logiciels commerciaux, développer ses propres solutions internes au sein d'une équipe R&D*, ou un mélange de ces stratégies, sont les solutions que peut choisir une entreprise pour s'équiper en logiciels.

Ces différentes stratégies peuvent être appliquées au logiciel propriétaire comme au logiciel libre. Ce dernier a développé des modèles économiques alternatifs, et souvent méconnus. Une des discussions les plus fréquentes autour des logiciels libres et open source concerne la manière de financer leur développement, de les rendre rentables pour les sociétés qui les développent, comme pour celles qui les utilisent, et par extension comment les rendre compétitifs avec leurs équivalents propriétaires.

Je montrerai dans ce chapitre les différentes stratégies économiques propres au logiciel libre pour les studios, autant dans l'acquisition de logiciels existants et dans l'achat de services de développement, que dans le développement interne ou collaboratif d'applications, de bibliothèques et de scripts.