Alexandre Venet

Avant-propos

Cet article est le fruit d’une réflexion libre et personnelle. Je suis un joueur enthousiaste de Project Spark.

Je ne prétends pas me substituer aux auteurs ou ayants droits de Project Spark. Je ne prétends pas répondre au nom de ces personnes ou marques ou entreprises. Je ne cherche à faire aucune propagande, aucun détournement de ligne éditoriale ou commerciale. Je m’exprime en mon nom et ne cherche en aucun cas à ternir l’image de qui ou quoi ce que ce soit.

Mes réflexions sont le fruit d’une expérience personnelle. Elles ne sauraient remplacer l’avis d’un spécialiste du droit.

Par souci de concision, je n’ai pas traité des points suivants :

• l’acquisition d’objets sanctionnée par un achat,
• le remix sanctionné par acquisition d’objets.

Présentation

Project Spark est un jeu gratuit (avec boutique et micro-paiement) de type « bac à sable » développé par Team Dakota et publié par Microsoft Studios. Le jeu est disponible pour Windows 8.1 et Xbox One.

Project Spark est un jeu permettant de créer des jeux. Il propose :

• un éditeur de terrain,
• une multitude d’objets gratuits ou payants (avec argent virtuel ou réel),
• un code de programmation : le Kode,
• la gestion de la capture de mouvement et d’enregistrement de musique grâce à Kinect,
• un moteur de recherche pour jouer aux jeux réalisés par les joueurs,
• la possibilité de « remixer » le jeu d’un autre joueur,
• sur Xbox One uniquement, à l’heure où j’écris, des joueurs peuvent se connecter sur le même monde et créer ensemble,
• une évolution par « niveaux » des champions (Karlsnor, Scarlett…).

Jouer à Project Spark, c’est s’amuser à créer un jeu-vidéo par soi-même, éventuellement s’initier à un langage de programmation simplifié, imbriquer des objets entre eux, des sons, des effets, etc. Personnellement, je retrouve le plaisir que j’avais, enfant, d’imbriquer mes cubes Lego et de les dessiner en perspective avant de tout détruire et de me relancer dans une nouvelle construction.

Jouer à Project Spark, c’est également jouer aux créations d’une communauté d’utilisateurs.

Spécificités

Les jeux réalisés dans Project Spark ne sont accessibles qu’à partir de Project Spark. Le Kode et tous les éléments fournis dans Project Spark sont dits « propriétaires » : ils appartiennent exclusivement aux auteurs ou ayants droits de Project Spark.

Impossible de créer un jeu et de penser l’exploiter à part entière en dehors de Project Spark. Une création dans Project Spark ne peut être vendue. Les utilisateurs ne peuvent ni exploiter leurs créations en tant qu’œuvres originales ni en tirer de quelconques droits d’auteur.

Project Spark est un jeu-vidéo et, même s’il permet de développer d’ambitieux projets, ne doit pas être confondu avec une véritable plateforme de développement logiciel (par exemple, impossible de récupérer la date de l’ordinateur, de réaliser des exécutables…).

Parcours de joueur

L’utilisateur se lance dans la réalisation de son propre jeu. Il imbrique les éléments selon ses désirs, tout en respectant les conditions d’utilisation (pas d’incitation à la haine, de discrimination, de pornographie, etc.). Cet utilisateur est responsable moralement de sa création.

Une fois sa création terminée, l’utilisateur l’enregistre sur son terminal ou en ligne et peut y jouer. Il peut s’arrêter à cela, n’utiliser le programme qu’en mode « hors ligne », jouer à la « quête des champions » ou à ses propres jeux.

Mais il peut vouloir aller plus loin et proposer de « partager » sa création avec les autres utilisateurs. Le jeu va ainsi être mis en ligne, répertorié dans les nouveautés et profitera ainsi d’une petite mise en avant.

Les utilisateurs peuvent « noter » les jeux d’un « pouce en l’air » ou d’un « pouce en bas ». Ils peuvent également choisir de ne pas noter.

Sur la vignette du jeu publié apparaissent le nom et la vignette de l’utilisateur, le nombre de fois que le jeu est joué ainsi que la note globale des utilisateurs.

Une fonction très mal intégrée permet d’envoyer des commentaires. Mais il faut alors « quitter » Project Spark pour un navigateur Internet, se connecter au service, etc. ce qui n’est guère confortable. Personnellement, cette fonction, pourtant essentielle dans la mise en relation des utilisateurs, est si mal intégrée que laisser un commentaire en devient rebutant.

La création est en ligne, visible, trouvable, jouable, appréciable, et après ?

Les utilisateurs ont la possibilité de « remixer » une création (un utilisateur peut également remixer sa propre création). Cela signifie qu’ils font une copie intégrale de cette création et en éditent le contenu (Kode, terrain, objets…). À l’issue de ce « remix », le joueur ayant remixé une création devient alors « co-créateur » et publie sa version du jeu original. Le jeu original et ses « remix » sont alors regroupés par « lignée » et chacun peut être joué ou édité indépendamment des autres.

Enfin, plus spécifiquement, le joueur qui édite une création peut récupérer des éléments (Kode, objets imbriqués…) et les enregistrer dans sa bibliothèque personnelle. Ainsi, si vous avez fait une voiture de sport avec moteur physique, je peux la récupérer intégralement et la placer dans une de mes créations. Vous, en tant qu’auteur, n’apparaissez alors nulle part… ce qui peut générer une grande frustration.

Parents et propriétaires

La problématique de Project Spark est débattue sur le forum officiel : quid de la paternité du contenu ?

La première réponse, apparaissant dans les conditions d’utilisations XBox, c’est qu’un utilisateur ne peut réclamer aucun droit sur le produit (sauf ceux relatifs à l’utilisation proprement dite du produit, évidemment).

• Les CGU Xbox

La deuxième réponse, spécifique à Project Spark (voir plus haut), c’est qu’un utilisateur ne peut espérer tirer aucun droit sur ses créations. Les utilisateurs sont des joueurs et non des auteurs de contenu original.

Ces réponses suffisent à résoudre le problème de paternité. Mais en dehors de l’aspect contractuel, comment la paternité de contenu se présente-t-elle dans Project Spark ? Pour cela, voyons les termes employés.

Désignations

Regardons comment sont employés les termes « partager », « remixer » et « co-créateur » dans Project Spark.

Le mot « partager » signifie ici : publier la création dans la communauté des joueurs. Autrement dit, il s’agit de montrer sa création à autrui. Le jeu créé est listé dans la partie « nouveautés ». (Plus spécifiquement, le jeu peut apparaître également dans le site Internet de Project Spark ; c’est d’ailleurs là que l’on retrouve les commentaires dont je parlais plus haut.)
Partage-t-on réellement une création dans Project Spark ? De véritables inconnus jouent à des jeux et ne donnent souvent aucun retour, avis, commentaire. Je joue et remixe les jeux d'autres utilisateurs mais Project Spark ne propose aucun moyen efficace de contacter ces utilisateurs.
Conclusion : je reste dans mon petit coin et imagine que je « partage » Project Spark.

Le terme « remix », quant à lui, signifie : reprendre l’intégralité d’une création et en faire ce que l’on veut. Autrement dit, si vous avez fait une voiture de sport avec moteur physique, je peux tout désosser et fabriquer un arbre à fleurs volantes de feu. Le contenu peut devenir radicalement différent et un « remixeur » n’est pas tenu de respecter quoi que ce soit de la création originale, ni de demander l’autorisation de remixer, ni même de citer le nom de l’auteur. Mais c’est aussi le meilleur moyen d’apporter des modifications, nécessaires ou personnelles, à une création.
Une précision s’impose : non, le « remix » ne modifie pas la création originale. Il s’agit bien d’une copie qui, elle, sera modifiée et republiée. Mais la création originale reste intègre.

Le terme « co-créateur » est à lui tout seul une problématique : en effet, si je réalise une copie d’une création, en quoi puis-je être considéré comme cocréateur de la création originale puisque je n’interviens pas sur cette dernière ? Bon, Team Dakota a sans doute utilisé ce terme pour mettre en filiation les utilisateurs et permettre de suivre l’évolution d’un projet.

Réclamations

De nombreux utilisateurs, sur le forum officiel, expriment leur mécontentement quant à la reconnaissance de paternité.
En effet, certains n’hésitent pas à remixer pour obtenir une visibilité dans la partie « nouveauté » ou des gains d’expérience et ainsi détourner les joueurs de la création originale. Ces « remixeurs sauvages » gagnent ainsi en renommée au détriment de la création originale et de son auteur.
Conséquence : les créateurs initiaux se sentent frustrés. Ils ont parfois travaillé dur sur leur création. Se voir dépossédés aussi vite et simplement de leur « bébé » est vécu comme un déchirement. Les plus virulents parlent de plagiat.
Tout légitimement, ils demandent donc à Team Dakota d’intervenir sur cette fonction de « remix » :

• la supprimer définitivement (solution radicale),
• donner la possibilité au créateur de décider s’il veut ou non que les joueurs remixent sa création (solution de libre choix),
• imposer un « crédit d’auteur » (citation obligatoire que l’on retrouve dans le droit d’auteur),
• permettre le remix uniquement au bout d’un certain temps, d’une certaine note, d’un certain nombre de fois que la création a été jouée (solution par retardement).

Encore une fois, nous nous plaçons dans le cadre d’un produit reposant sur un accord de conditions d’utilisation. Il y a donc un problème de conformité entre les réclamations des joueurs et les conditions qu’ils ont pourtant acceptées pour jouer à Project Spark. Au nom de quoi ces joueurs peuvent-ils réclamer une quelconque paternité de contenu quand ce contenu lui-même ne leur appartient pas et qu’ils ont accepté cette clause ? Cela dépasse même le cadre du contrat puisque ces utilisateurs se verraient inévitablement confrontés au droit d’auteur attaché au produit Project Spark, donc à la loi encadrant le droit d’auteur.

On peut répondre à cela que les créateurs restent « propriétaires de la mise en forme » des éléments fournis par Project Spark. Même argument : cela n’est ni conforme au produit Project Spark ni à ses conditions d’utilisation.

Voilà tout de la situation. Je vais maintenant essayer d’apporter des éléments de réflexion à ce problème de paternité de contenu, ce qui implique des détours par la philosophie et la politique.

Analyse

D’abord, Project Spark est un jeu qui repose sur la disponibilité de ses éléments. Le Kode, les objets et imbrications d’objets, tout ce qui compose une création d’utilisateur peut être librement réutilisé. Voilà le coeur de Project Spark.
Les utilisateurs rageusement attachés à l’idée d’avoir créé une « killer-app » n’ont pas compris le principe initial du jeu : les éléments disponibles dans Project Spark n’appartiennent qu’à Team Dakota, les utilisateurs en ont simplement la jouissance.
Autrement dit, le Kode et les éléments que les joueurs manipulent dans Project Spark peuvent être considérés comme un « bien public » fourni, garanti, préservé, amélioré par Team Dakota.

Plus d’informations sur le site du Sénat :

• Le bien public
• Le bien public mondial

Évidemment, Team Dakota peut décider de fermer son service à tout moment car nous sommes dans le cadre d’une entreprise privée et non d’un État, a fortiori démocratique où les décisions sont prises collectivement. La spécificité de l’hypothétique « bien public » relatif à Project Spark, c’est qu’il serait modifiable et propriétaire ; ce ne serait donc pas véritablement un bien public, sauf si l’on considère Project Spark comme un écosystème. Mais retournons à notre analyse.

Les utilisateurs de Project Spark qui réclament la suppression de la fonction « remix » sont donc attachés à l’idée de propriété de leur réalisation. Contradiction : ils ont signé un accord qui stipule qu’ils ne peuvent tirer aucun droit de « leurs » créations ou d’une quelconque mise en forme d’éléments s’apparentant à une création originale.

Or, Project Spark propose un principe de communauté. Il peut être considéré comme une simulation de communauté où le bien public ne peut être utilisé que pour le mettre en forme sans en tirer de contrepartie.

Dans ce contexte, comment gérer la frustration des utilisateurs qui se sentent victime de remix sauvage ?
La source de cette frustration me semble être le manque de reconnaissance. Si je n’ai pas droit de propriété sur une création dans Project Spark, le « système » doit obliger les individus à faire preuve de reconnaissance à mon égard et non renvoyer la question de la reconnaissance à la moralité, au civisme, au sens éthique des individus. Pouvoir utiliser le bien public mis en forme sans reconnaître la personne qui l’a fait passerait pour de l’indifférence voire une violence infligée à cette personne. Que signifierait alors le terme « communauté » si les personnes qui composent cette communauté ne font pas l’objet de considération ?
D’un autre point de vue, ce devoir de reconnaissance peut être ressenti comme une privation de liberté. Pourquoi, au nom de la communauté, devrais-je être forcé à la reconnaissance d’autrui quand cet autrui, peut-être, ne mériterait pas tant de considération, surtout si sa « création » s’apparente à du remix sauvage, de la copie, voire un plagiat ? Ou alors, de quelle considération parlons-nous ?
Enfin, pourquoi ne pas considérer la frustration d’un utilisateur comme son problème personnel ? Pourquoi la communauté ou autrui devrait-ils prendre en charge ce problème personnel ? Est-t-il légitime de réclamer de la reconnaissance pour une chose quand aucun attachement n’est attendu ?

Tentative de réponse

Voici un extrait de la page Wikipédia relative à la « propriété » :

Globalement on peut dire que le statut donné à la propriété, et surtout à la propriété privée, scinde les courants politiques en deux camps, qu'on peut qualifier grossièrement de socialistes et libéraux. Les libéraux ont tendance à défendre farouchement le droit de propriété, au nom de la défense de la liberté individuelle, tandis que les socialistes ont plutôt tendance à restreindre et limiter le droit de propriété, au nom de l'équité, des Droits de l'homme, de l'intérêt général, ou aujourd'hui de l'écologie politique et des droits des générations futures.

Wikipedia

En suivant cette citation, voici quelques pistes « socialistes » :

• désigner les utilisateurs comme des « contributeurs »,
• valoriser les créations avec liste obligatoire des contributeurs et non attacher un utilisateur unique à une création (cela répond au problème des créations collectives où n’émerge aucun auteur principal),
• distribuer les « gains » équitablement selon les rôles ou l’implication de chaque utilisateur (gain d’expérience, d’argent virtuel…),
• créer des comptes utilisateurs partagés.

Quelques pistes « libérales » :

• empêcher le remix ou le mettre sous conditions,
• placer l’individu « avant » ou « devant » ses créations,
• proposer aux utilisateurs des moyens de restreindre le droit d’accès aux créations (dans les deux sens : quand je consulte un jeu et quand je « partage » un jeu),
• permettre de tirer des droits de propriété sur les créations, d’exploiter ces dernières au regard du droit d’auteur,
• contractualiser les rapports entre co-créateurs.

Avec la notion de « bien public », de la globale et grossière division « socialiste » et « libérale » (cf. Wikipédia), Project Spark semble faire une proposition intermédiaire : la notion de propriété « s’assouplit » et le bien public apparaît « sous contrôle ».

D’un autre point de vue, Project Spark révèle des subtilités du droit d’auteur. Si je peux créer avec Project Spark, est-il légitime de m’imposer une « absence de droits d’auteur » sur mes créations sous prétexte que le produit fait déjà l’objet de droits d’auteur ? Au fond, c’est comme si j’écrivais cet article avec un logiciel de traitement de texte mais que cet article restait la propriété du développeur de ce traitement de texte… voire du traitement de texte lui-même.

Ouvertures

Mon humble avis là-dedans ? Je n’en ai pas. Je voulais simplement évoquer une problématique.

Les jeux de type « bac à sable » ouvrent la voie à des questions éthiques, légales et politiques, inédites. Par exemple : renoncer à ses droits moraux pour intégrer ses oeuvres dans un univers virtuel a-t-il du sens selon le code français de la propriété intellectuelle ?

À quand un programme démocratique où les utilisateurs voteraient pour des améliorations que les développeurs – ou les utilisateurs eux-mêmes – seraient alors en devoir d’intégrer ? Sous réserve de faisabilité...

Merci et à bientôt !