BAVC, San Francisco, 8 juin 2011
Après plusieurs postes d’administrateur de systèmes Unix, Mark Hellar s’est intéressé aux arts médiatiques par le biais de son travail à la Bay Area Video Coalition1 à San Francisco et au San Francisco Art Institute2. Il travaille actuellement pour le SFMOMA3, où il est chargé de la préservation d’une partie des œuvres àccomposantes informatiques, dans le cadre du programme Matters in Media Art4. Pour l’une de ces œuvres, Agent Ruby5, créée en 2002 par Lynn Hershman Leeson, il a testé le potentiel de la virtualisation en tant que stratégie de préservation pour les œuvres basées sur le Web. Emanuel Lorrain (PACKED vzw) l’a interrogé sur son parcours et sa connaissance des machines virtuelles utilisées par le SFMOMA pour montrer certaines œuvres de la collection.
PACKED : Pouvez-vous nous décrire votre parcours et nous expliquer comment vous en êtes venu à travailler avec les arts médiatiques ?
Mark Hellar : J’ai appris ce métier grâce à différentes formations, mais également de manière autodidacte. J’ai un diplôme de sciences humaines que j’ai complété cela avec des cours du soir. J’ai travaillé dans des entreprises d’informatique de 1996 à 2003, où je concevais des serveurs Linux. Mon premier poste dans ce secteur consistait à construire et à entretenir une grappe de serveurs Unix. C’était du travail d’informaticien assez basique. Je l’appréciais, mais après sept ans ça devenait lassant. Comme j’avais étudié le montage vidéo à l’université, j’ai postulé à une bourse de 300 heures de formation à la Bay Area Video Coalition (BAVC). J’y ai appris à manipuler les technologies vidéo et des logiciels tels qu’Avid6, Final Cut Pro7, Max MSP Jitter8, Flash9 et les outils Adobe10.
Fort de ces nouvelles compétences, j’ai trouvé un emploi au San Francisco Art Institute, à North Beach. J’y suis resté environ cinq ans, comme responsable des technologies de l’université. Je supervisais les laboratoires de médias numériques, les salles informatiques, les salles de photographie numériques, entre autres. Beaucoup d’artistes venaient là en résidence, comme le collectif indien Raqs11. Leurs demandes en matière de technologie étaient très différentes de celles auxquelles j’avais affaire auparavant ; il s’agissait par exemple d’installer un capteur sur un escalier, afin qu’une image soit projetée quand quelqu’un passe. Ce n’était pas ma spécialité, mais j’étais très heureux de travailler dans un monde mêlant technologie et création. Avec le temps, j’ai développé des compétences et une sensibilité dans ce domaine.
PACKED : C’est donc là que vous avez commencé à appliquer à l’art vos connaissances en informatique ?
Mark Hellar : Oui, et je me plaisais beaucoup dans ce milieu artistique. En informatique pure, les demandes sont toujours très formatées, standardisées, et il existe des recettes toutes prêtes pour à peu près tout. Au San Francisco Art Institute, c’étaient plus des choses du genre « J’aimerais une application qui ralentit la vidéo ». Je devais donc créer des patches Jitter, utiliser des circuits Arduino12, des microcontrôleurs13 pour installer les capteurs, etc. Il n’y avait pas de recettes toutes faites, c’était à moi de trouver des moyens intéressants pour faire ce qu’on me demandait. Ensuite, BAVC m’a offert un poste, quand ils ont eu une connexion gigabit en fibre de verre. Je me suis dit qu’ils étaient à la pointe de la technologie et que ces infrastructures offraient de nombreuses possibilités aux artistes.
PACKED : Est-ce que vous travaillez encore pour BAVC aujourd’hui ?
Mark Hellar : Oui, mais pas comme employé. Je dirige une entreprise, Hellar Studio’s LLC, où je suis seul, et par laquelle j’ai de nombreux contrats pour Bay Area Video Coalition. Je supervise une partie de leurs systèmes de diffusion et je suis chargé d’une plus grande partie encore du travail informatique général. Je suis resté chez BAVC pendant un moment, puis je suis parti pour devenir directeur informatique dans un musée de la technologie pour enfants, dans le centre-ville, où nous organisions des expositions interactives et des choses comme ça. Je suis ensuite revenu au BAVC pour participer au déménagement d’une station de télévision qu’ils avaient reprise. C’était de l’autre côté de la ville. Il fallait déménager les transmetteurs et tous les équipements. C'est une station de télévision qui émet 24h sur 24 et sept jours sur sept et il fallait garder un signal ininterrompu.
En plus de celui avec BAVC, j’ai un contrat de trois ans au SFMOMA dans le cadre du programme Matters in Media Art, où je me consacre uniquement à la préservation des œuvres d’art numériques. L’année dernière, nous avons travaillé sur des pièces telles qu’Agent Ruby de Lynn Hershman Leeson ou Predictive Engineering214 de Julia Sher, pour la préservation desquelles nous avons eu recours à la virtualisation.
PACKED : Quel a été votre premier contact avec le SFMOMA et avec les problèmes liés à la préservation des arts médiatiques ?
Mark Hellar : J’ai commencé à discuter avec le SFMOMA quand je travaillais chez BAVC. Il y avait à San Francisco une petite institution du nom de New Langton Arts qui existait depuis une trentaine d’années. Ils m’ont contacté en 2008 parce qu’ils proposaient une bourse financée par Richard Reinhard du Pacific Film Archive à Berkeley15. La bourse était destinée à une étude de cas du Variable Media Questionnaire (VMQ) de John Ippolito16, dans lequel de nombreuses personnes telles que Christiane Paul17, et institutions telles que Franklin Furnace18 ou Performance Archive, à New York, avaient introduit des œuvres. Il y avait différents types d’œuvres, des installations, des performances, etc. J’ai participé à l’introduction d’une œuvre de New Langton Arts19 dans le VMQ. C’était mon premier contact avec la préservation des arts médiatiques. J’ai trouvé leur démarche très intéressante.
Par la suite, Jill Sterrett, la directrice des collections et de la conservation au SFMOMA, à qui j’avais été présenté, m’a contacté. En 2001-2002, il y avait un commissaire d’exposition au SFMOMA, Benjamin Weil, qui s’intéressait aux arts numériques et qui a créé une galerie en ligne, l’« e.space ». Il y a eu une exposition en ligne avec des œuvres de Julia Sher, Lynn Hershman Leeson, Mark Napier et d’autres artistes, mais le SFMOMA n’a jamais acquis d’œuvres officiellement. Il y a deux ans, Rudolf Frieling est devenu le nouveau commissaire d’exposition pour les œuvres nouveaux médias et a voulu les acquérir de manière formelle. Quand ils ont demandé au service de préservation du BAVC ce qu’ils devaient faire pour Agent Ruby, le directeur exécutif les a renvoyés vers moi.
PACKED : Le SFMOMA cherchait-il une stratégie afin de préserver ce type d’œuvres ?
Mark Hellar : Oui. En résumé, Rudolf Frieling s’est d’abord demandé : « comment acquérir cette œuvre ? » ; puis Jill Sterrett s’est demandé : « comment la conserver ? » La première fois que j’ai vu l’œuvre, en 2000, c’était sur un vieux serveur Linux Redhat 520, qui tournait sur un vieux PC à la cave. L’œuvre tournait depuis cette vieille machine qui avait un lecteur de disquettes et des ports PS/221. Elle avait été mise en ligne et tournait, dans leur salle de serveurs, depuis l’exposition. Elle fonctionnait toujours, mais le matériel avait dix ans.
PACKED : A-t-on vérifié, durant cette période, si tout fonctionnait bien ?
Mark Hellar : Oui, le SFMOMA a un autre collaborateur chargé de la maintenance sur cette œuvre. Il a procédé à des vérifications, à des réparations, à la maintenance, mais il était d’avis que le musée devait l’installer sur une machine virtuelle. J’ai dit à Jill Sterrett que tout le monde utilisait des machines virtuelles. Elle m’a répondu : « Je ne pense pas que ce soit du ressort du service informatique. » J’ai objecté que ce l’était en partie, parce qu’il faut bien installer ces machines virtuelles, mais on ne peut cependant pas simplement regarder dans l’annuaire et appeler un informaticien pour ce genre de travail. Il faut quelqu’un avec une certaine sensibilité étant donné qu’il s’agit d’une œuvre d’art. Cette double compétence est nécessaire : un processus de décision cohérent, et une compréhension artistique. Un musée doit posséder ces nouvelles compétences pour appréhender ce type d’œuvres. Agent Ruby est un site web contenant des dossiers, un programme Java, une base de données ainsi que des algorithmes basés sur l’intelligence artificielle. L’œuvre reçoit les données du visiteur, les confronte à sa base de données, répond au visiteur, recueille des informations, etc. C’est un objet physique, mais l’objet lui-même n’est pas seulement physique, il est aussi logiciel.
PACKED : Le musée avait-il sauvegardé le système à l’époque ?
Mark Hellar : Il y a eu des sauvegardes, entre autres choses, mais j’ai simplement fait une copie du disque tout entier. J’avais peur que le disque dur cesse de fonctionner. J’ai créé une image de la machine, j’ai commencé à l’examiner puis j’ai créé une machine virtuelle.
PACKED : Avez-vous utilisé VMware22pour créer la machine virtuelle ?
Mark Hellar : Oui, j’ai utilisé VMware parce que le service informatique du SFMOMA possède une très bonne infrastructure et travaille déjà avec ce programme. Ils ont de multiples serveurs, avec un sandbox23. Il y a des machines virtuelles qui font tourner des bases de données de gestionnaires d’actifs, les serveurs de courrier électronique, et le stockage. Ils ont 20 ou 30 teraoctet de stockage dans le sandbox. Comme l’infrastructure est très solide, je me suis contenté de créer une image VMware, puis je l’ai réglée et testée. Les images VMware sont de simples fichiers. J’ai donc pu simplement les ouvrir et les faire tourner dans cette infrastructure. La priorité numéro un était de parvenir à un environnement sûr et stable. Puis il y a les autres avantages de la virtualisation. Ce n’est pas cher, c’est portable, et à l’avenir, une institution comme New Langton Arts pourrait pourquoi pas n’être qu’une petite galerie d’arts logiciels dont on pourrait voir l’archive en ligne sur le cloud d’Amazon24.
PACKED :Agent Rubyest une œuvre basée sur le Web, dont le hardware, ce PC doté d’un système Linux, n’est que le support. Est-ce aussi pour cela qu’on peut facilement la virtualiser, parce que le hardware a peu d’importance pour l’œuvre ?
Mark Hellar : Nous avons longuement interrogé Lynn Hershman Leeson au sujet de l’œuvre, pour savoir ce qu’on pouvait faire ou non. Avant cela, le service informatique n’avait pas été sensibilisé à ce genre d’œuvres. Donc quand ils ont vu l’ordinateur, ils se sont demandé : « qu’est-ce que c’est que ce truc qui traîne à la cave? »
PACKED : Prévoyez-vous d’accueillir d’autres œuvres numériques de la collection du SFMOMA dans cette infrastructure ?
Mark Hellar : Oui, et c’était déjà le cas avant. Plusieurs œuvres indépendantes les unes des autres se trouvaient sur ce vieil ordinateur et si l’une d’elles avait des problèmes ou se faisait pirater, cela aurait pu endommager l’ensemble. Maintenant il y a plusieurs machines virtuelles. En gros, s’il y a un problème quelque part, ça ne va pas faire planter tout le serveur, puisqu’il y a plusieurs machines virtuelles. Prenons l’œuvre de Julia Sher, par exemple : tout ce dont elle a besoin, c’est un serveur web, puisqu’elle se compose de fichiers Flash. Agent Ruby est une œuvre plus complexe, il lui faut une base de données et une machine virtuelle Java25.
PACKED : Quel type de base de données utiliseAgent Ruby? À quoi sert-elle ?
Mark Hellar : La base de données est composée de plusieurs fichiers XML26. Ce n’est pas une vraie base de données comme MySQL27. Agent Ruby ne pouvait pas prendre d’instantanés régulièrement, mais quand on interagit avec l’œuvre, elle recueille des éléments d’information et garde un fichier sur le visiteur. Tous ces fichiers XML se modifient légèrement au fil du temps. Quand j’ai commencé à travailler dessus, il y avait 8 gigaoctet d’historiques de conversations allant de 1999 à aujourd’hui. Rudolf Frieling, le commissaire d’exposition, était très content qu’on ait une trace des interactions avec le public. La plupart du temps, c’est impossible.
PACKED : Ces fichiers vous permettent-ils d’avoir une vue d’ensemble sur l’évolution de l’œuvre ?
Mark Hellar : Oui. Si elle avait été virtualisée dès le départ et qu’un instantané avait été pris chaque année, on pourrait faire tourner toutes les versions en même temps et comparer comment l’Agent Ruby de 2000 et celle de 2010 répondent à la même question. Il y aurait probablement une différence basée, par exemple, sur ce qui s’est passé entre-temps : la guerre en Irak, l’ouragan Katrina, etc.
PACKED : Une machine virtuelle peut donc être utilisée pour documenter des œuvres qui grandissent ou se transforment ?
Mark Hellar : Oui. C’est le cas d’Agent Ruby. Lynn Hershman la décrit comme une machine capable d’apprendre. Elle apprend, et même si elle n’est pas aussi solide qu’on le penserait, il y a quand même 8 gigaoctet d’historique. On peut se demander s’il faut aller plus loin avec une œuvre plus complexe comme celle-ci. Selon moi, nous sommes dans une position confortable. Si une œuvre était créée aujourd’hui, mettons une Agent Rubyavec la technologie actuelle, on pourrait prendre un instantané chaque année.
Avec des clones ou des sandbox, l’environnement de travail permet de prendre le clone d’une œuvre pour faire des recherches dessus, ou encore d’examiner en profondeur un serveur sans affecter l’original. On pourrait faire des tests de mises à jour plus facilement en le faisant sur une seule machine. Agent Ruby tournait sous Java 1.1, un système qu’il aurait fallu changer. Le musée possédait le code source en Java, et nous avons pu le recompiler en Java 1.4 pour qu’il soit conforme et sûr. Cette procédure a été effectuée avec un clone et non avec l’original. Mais en même temps, qu’est-ce qu’un original dans le domaine des œuvres d’art numériques ? Le fait de pouvoir cloner ces œuvres pose-t-il un problème ? Ce sont des questions intéressantes.
PACKED : Est-ce que le SFMOMA envisage aujourd’hui de prendre des instantanés d’Agent Ruby?
Mark Hellar : J’ai donné à l’équipe de la collection un programme de choses à faire : chaque mois, tous les six mois, chaque année… Nous avons également parlé de cycles de maintenance pour l’œuvre. Elle est montrée en permanence. Mais comme l’œuvre se confronte au public, on sait très vite s’il y a un problème.
PACKED : Y a-t-il eu des problèmes lors de la mise à jour de Java ?
Mark Hellar : J’ai dû faire de petites modifications sur les fichiers de configuration, mais rien de trop important. J’ai pu le faire dans la machine virtuelle que j’ai créée. Je garde aussi des traces de ces interventions.
PACKED : La version qui est montrée actuellement est donc un clone modifié qui tourne sur une machine virtuelle ?
Mark Hellar : Oui, elle tourne actuellement sur un serveur VMware ESX. Il existe également une version Palm28 qu’on peut télécharger ; je leur ai demandé s’il fallait essayer de la ressusciter aussi. On pourrait trouver un vieux Palm sur eBay, y installer l’œuvre, trouver le code source et porter le tout sur un autre système.
PACKED : Vous voulez dire, créer une applicationAgent Rubypour iPhone, par exemple ?
Mark Hellar : Oui, une version pour Android ou pour iPhone, quelque chose comme ça. On pourrait en parler dans les années qui viennent.
PACKED : Au moment de l’acquisition, le SFMOMA n'a-t-il reçu de la part de l’artiste que l’application Flash compilée, le fichier SWF ?
Mark Hellar : Oui, le musée n’a reçu que le fichier Flash compilé. Il n’a pas eu le fichier .FLA. C’est devenu un problème quand j’ai dû remplacer la vieille adresse AOL de Lynn Hershman Leeson par sa nouvelle dans l’application. J’en ai parlé avec un des techniciens qui travaillaient avec elle à l’origine, et je lui ai demandé si je pouvais décompiler le fichier Flash.
PACKED : Pourquoi décompiler le fichier SWF29pour obtenir le code source ? L’artiste ou ses techniciens n’avaient-ils pas le fichier .FLA ?
Mark Hellar : Non, ils n’avaient pas le fichier source. Décompiler le fichier était le seul moyen pour que je puisse apporter des petites modifications à certains endroits, comme ce changement d’adresse e-mail. En fait, l’interface est basée sur trois fichiers Flash différents. Il y avait des fichiers .FLA sur l’ordinateur, mais pas toute l’arborescence avec l’ensemble des codes sources, etc. Heureusement, le script ActionScript est assez simple, ce qui m’a permis de décompiler le fichier SWF sans problème.
Quand j’ai examiné le serveur, j’ai trouvé un tas de choses : du code Java, des modèles 3D, différentes versions de l’interface Flash. Au moment de la création de l’œuvre, l’interface Flash était tout à fait différente. Dans DiNA, une autre œuvre de Lynn Hershman, l’arrière est similaire à celui d’Agent Ruby, mais avec un avatar 3D dont les lèvres bougent côté face. Un modèle 3D de Ruby existait. Il y avait donc cette espèce de caverne archéologique. Le serveur ne contenait pas seulement l’œuvre finale. Ça ressemblait plutôt à un atelier.
PACKED : Comment est-ce qu’ActionScript30communique avec le programme Java dansAgent Ruby?
Mark Hellar : Grâce à un fichier de configuration31 qui permet le dialogue entre le programme Java et l’interface Flash. Le programme Java tourne en arrière-plan, avec son propre serveur web qui s’appelle Jetty. C’est un serveur web Java. L’interface envoie et reçoit des données par le port 2001. ActionScript dit par exemple : « analyse cet élément et envoie-le par le port 2001 », et ainsi de suite. Cela fonctionne par un système de requêtes et de réponses.
PACKED : Avez-vous parlé à la personne qui a créé l’application Flash et le programme Java ?
Mark Hellar : J'étais en contact avec le technicien de l'artiste et nous avons pu l'interviewer. En revanche nous n'avons jamais parlé au programmeurs originaux. Il y avait un petit nombre de notes de programmeurs qui expliquaient en quoi consistait le programme Java, et comment il communiquait par ce port. Il existait un fichier de configuration pour modifier ce port. On n’a donc pas besoin de toucher au fichier .FLA.
PACKED : Le SFMOMA a-t-il tenté d’obtenir les fichiers sources ?
Mark Hellar : Oui, il a été question de cela. Je leur ai expliqué qu’ils devaient mettre la main sur le code source. Je leur ai aussi expliqué en quoi consistait la décompilation lorsque j’ai dû le faire pour un projet de Julia Sher. Je leur ai dit : « Décompiler, c’est comme si on rangeait tous les objets d’une maison en jolies petites piles, afin de pouvoir conceptualiser un nouvel agencement et de tout reconstruire. Sans le code source, on ne peut pas le compiler, et donc tout ce processus est impossible. » Heureusement, avec Flash, on peut décompiler l’application.
PACKED : Ces questions sont-elles abordées au cours des entretiens avec les artistes ?
Mark Hellar : Oui, il y a des discussions avec les artistes à ce stade-là. Dans le cas d’Agent Ruby, nous avons pu poser beaucoup de questions à l’artiste, qui est encore vivante. Si on demande à Agent Ruby« qui est le Président? », par exemple, elle répond George W. Bush. J’ai demandé à Lynn Hershman Leeson si on pouvait mettre ça à jour pour qu’elle réponde Barack Obama. Elle m’a répondu : « Non, vous ne pouvez pas, c’est l’intelligence de Ruby, y compris comment elle a évolué ou non. » Ensuite je lui ai demandé si nous pouvions modifier le code source et le recompiler en Java 1.4, et elle a répondu oui. Si je ne l’avais pas fait, je l’aurais exposée au monde, ce qui aurait posé des problèmes de sécurité.
PACKED : Était-ce pour des raisons de sécurité que vous avez mis à jour le programme Java ?
Mark Hellar : Oui, parce que l’œuvre est confrontée au monde sans arrêt. La machine virtuelle d’archivage qui tourne avec le vieux Java 1.1 existe encore. Le musée peut mettre ce fichier au frais dans son sandbox ou sur ses bandes LTO et le reprendre dans cent ans ou plus, pour comprendre comment les faire tourner sur les nouveaux systèmes qu’ils utiliseront à ce moment là.
PACKED : Dans votre présentation d’Agent Rubyau Sommet DOCAM, vous avez parlé de « préparation aux catastrophes ». Qu’est-ce que cela englobe?
Mark Hellar : Ça fait partie de mon bagage d’informaticien (rires). Pour vous donner un exemple, le serveur VMware comprend une sorte d’endroit où il garde un clone de la machine virtuelle à tout moment. Ainsi, on peut lui dire d’aller directement vers le clone si le serveur est inaccessible après 30 millisecondes. Comme ce ne sont que des fichiers, il n’y a pas besoin de tout décortiquer, d’installer un nouveau serveur, de déplacer les fichiers et de le lancer. À la place, j’ai cette copie instantanée. C’est typique d es infrastructures à grande accessibilité comme les serveurs de courrier électronique de Microsoft ou IBM : s’il y a un problème, c’est que des données pourraient être corrompues. Donc il y a en permanence une copie invisible. Bien sûr, avec Agent Ruby, un problème ne peut se manifester qu’après un certain temps. Mais c’est ce que je voulais dire par l’idée de « préparation aux catastrophes ». C’est positif, puisque, s’agissant d’une œuvre d’art, elle devrait avoir dans un musée la même valeur qu’une sculpture ou une peinture.
PACKED : Quand l’œuvre est arrivée au SFMOMA pour l’exposition, était-elle déjà montrée depuis le serveur situé dans le musée ?
Mark Hellar :Je pense qu’elle a toujours été montrée depuis ce serveur.
PACKED : Et le nom de domaine ? Le SFMOMA a-t-il dû l’acquérir aussi ?
Mark Hellar : Il y avait un nom de domaine : Agentruby.com, qui renvoyait au serveur du SFMOMA. Il appartenait au musée, mais il lui a échappé quand il a expiré. Quelqu’un l’a acheté et essaie maintenant de le revendre pour 500 $. Le musée va peut-être le racheter. Pour l’instant, on y a accède via l’adresse http://agentruby.sfmoma.org/. C’était intéressant, la question du nom de domaine est importante pour les œuvres basées sur le Web. Je l’ai ajoutée à ma check-list.
L’année prochaine, nous travaillerons sur Learning To Love You More32, une œuvre de Harrell Fletcher et Miranda July. C’est un site web en PHP pour lequel le problème du nom de domaine s’est déjà posé. Je leur ai conseillé d'effectuer un transfert de propriétaire, puis de payer pour une dizaine d’années. D'un point de vue technique, ce n’est pas difficile.
PACKED : Quels sont, d’après votre expérience, les défauts ou les limites de la virtualisation ?
Mark Hellar : L’un des gros problèmes, ce sont les instantanés. Si vous prenez des instantanés d’Agent Ruby, ça prend environ trois gigabytes, mais il faut les stocker au sein du service informatique. Une autre question : combien faut-il d’instantanés ? J’ai proposé d’en prendre un chaque mois. En réalité, le stockage de ces instantanés n’est pas un problème insurmontable parce que le stockage ne coûte pas cher, et coûte d’ailleurs de moins en moins cher.
PACKED : La réponse à cette question, à quelle fréquence faut-il archiver les instantanés, n’est-elle pas différente pour chaque œuvre ?
Mark Hellar : Si, cela dépend de l’œuvre. Dans Agent Ruby, il y a par exemple un historique des conversations qui ne sont jamais les mêmes. On pourrait simplement sauvegarder ces historiques, je suppose, mais d’autres éléments changent également, comme la base de données qu’Agent Ruby utilise pour dialoguer avec l’utilisateur. En revanche, j’ai travaillé sur une œuvre de Julia Sher, créée en Flash, dont rien ne pouvait changer, et il fallait donc réaliser un checksum des fichiers pour vérifier qu’ils n’aient pas changé, etc. Les instantanés sont importants pour une œuvre comme Agent Ruby. C’est la même chose pour beaucoup d’œuvres basées sur le Web, sur Rhizome33 par exemple, qui vont chercher des données sur Internet et assemblent différentes choses. Pour des œuvres statiques, un ou deux instantanés pourraient suffire. Ces questions doivent être soulevées lors de l’examen technique de l’œuvre.
PACKED : Quel est votre sentiment concernant l’avenir de toutes les œuvres qui utilisent des données externes sur Google, Yahoo, Flickr, Facebook, etc. ou même les œuvres situées dans des mondes virtuels comme Second Life ?
Mark Hellar : J’ai un jour parlé à quelqu’un qui réfléchissait à des moyens d’archiver ces mondes virtuels. Je me suis dit « Bon courage! » : rien que pour Second Life, il y a une ferme de serveurs entière. Qu’est-ce qu’on peut faire ? Cloner les modèles, décortiquer le script et mettre tout ça sur un serveur unique ? Oui, mais ce n’est pas une tâche facile. Pour certaines œuvres, on peut réexaminer ses outils, prendre un instantané, créer une base de données locale, puis les faire tourner, exécuter les protocoles de maintenance, garder un œil sur Flickr, par exemple, changer l’API34 dans deux ans ou quand Flickr se fait racheter par quelqu’un d’autre. Mais est-ce qu’il faut tout modifier ? C’est une bonne question. À mon avis, il faut collecter les données le plus longtemps possible, mais ça risque d’être difficile de faire tourner ces œuvres indéfiniment, vu la nature de ces flux de données.
PACKED : On aurait donc une sorte de document vivant qu’on pourrait utiliser ?
Mark Hellar : Oui, afin que le public comprenne ce qu’était l’œuvre, mais il faut essayer de la garder en ligne le plus longtemps possible. Cela dit, les artistes ont peut-être un avis différent.
PACKED : Jusqu’à présent, vous vous êtes limité aux œuvres basées sur le Web, mais vous allez travailler sur d’autres types d’œuvres basées sur l’informatique pour le SFMOMA. La virtualisation peut-elle être utilisée comme une approche générale dans une collection ?
Mark Hellar : J’étais au SFMOMA l’autre jour, et je parlais avec Bill Fontana de son œuvre Sonic Shadows, qui utilise un patch Max/MSP, sur un Macintosh. En outre, il y a un ensemble de composants électroniques et d’accéléromètres. Il les avait placés à plusieurs endroits dans la salle des chaudières, afin d’y capter de subtiles vibrations. L’œuvre transmettait les signaux analogiques des accéléromètres au patch Max/MSP, qui étaient ensuite diffusés par les amplificateurs et les enceintes dans l’atrium du musée. Les patches Max/MSP contrôlaient les servomoteurs, qui orientaient les enceintes. Nous avons rencontré l’artiste et lui avons parlé de ce nous pensions faire avec Agent Ruby. Il s’est alors demandé si le SFMOMA pourrait montrer cette œuvre pendant cent ans s’il l’avait acquise. C’est un sacré défi pour une œuvre en Max/MSP. Cycling7435, l’éditeur du logiciel, est une toute petite entreprise située ici à San Francisco, et on ne sait pas combien de temps elle existera encore. C’est Miller Puckette qui a développé ce logiciel avant qu’il ne soit racheté par Opcode Systems36. Maintenant c’est Cycling74 qui l’a repris et qui se charge de la maintenance. Ça vous montre à quel point les choses changent. La même chose s’est produite avec Flash.
PACKED : Les applications créées dans Max/MSP ne pourraient-elles pas tourner sur une machine virtuelle ?
Mark Hellar : Elles pourraient, mais il y a aussi beaucoup de composants matériels dans cette œuvre : les accéléromètres, les petites enceintes sur mesure en Mylar qui coûtent environ 2000 dollars, etc. La virtualisation semble magique à première vue. C’est le cas pour certaines choses, mais ça ne marche pas pour le hardware. J’ai expliqué à l’artiste et au musée qu’il faudrait faire des schémas pour les composants électroniques.
PACKED : Même avant d’aborder les éventuels problèmes de hardware, peut-il y avoir des problèmes de communication entre les applications et les composants matériels lorsqu’on passe par une machine virtuelle ?
Mark Hellar : Dans VMware, je peux voir tous les ports série, les ports USB. Je peux, par exemple, programmer un Arduino depuis une machine virtuelle. Mais si on utilise une machine virtuelle dans dix ans, est-ce qu’elle pourra communiquer avec un appareil via un port série ? Est-ce que cela fonctionnera si l’appareil n’utilise plus l’USB mais le Thunderbolt ? C’est une bonne question. Je ne peux pas y répondre. On pourrait sans doute se débrouiller, mais c’est une question bien réelle. Dans le cas d’œuvres d’art comme celle-ci, il faudrait établir des recommandations détaillées et un protocole de maintenance lorsqu’on virtualise la première génération. Par exemple : vérifier tel élément précis dans deux ans, vérifier s’il y a encore des ports USB, etc. Mais je ne pense pas qu’on soit tranquille pour cent ans, même comme ça.
PACKED : La documentation de ces œuvres au SFMOMA inclut-elle une maintenance régulière ?
Mark Hellar : Oui. Jill Sterrett est très exigeante sur la documentation. Nous avons donc ce qu’on appelle des protocoles de maintenance, qu’on associe au fichier et à toutes les informations fondamentales, les descriptions techniques, ce qui a déjà été fait, ce qui doit être fait, etc.
PACKED : À quelle fréquence ces protocoles de maintenance sont-ils exécutés ?
Mark Hellar : Pour Agent Ruby, c’est après un mois, six mois, un an, deux ans. Ensuite, on examine, avant la fin de cette période de deux ans, s’il faut prolonger ou rectifier les protocoles de maintenance, en fonction des problèmes détectés. Il est aussi crucial, d’après moi, de prendre des notes pour les prochaines personnes qui seront chargées de ce travail : une liste de choses à prendre en compte, que les suivants mettront à jour. Quelque chose de similaire aux formulaires utilisés lorsque l'on transfert une vidéo, ou à un SIP, comprenant les notes des transferts, celles des techniciens, les données des checksums et les programmes de maintenance. Il est capital d’instaurer une sensibilité autour de cela.
PACKED : Dans le cas d’Agent Ruby, en quoi consiste ce protocole de maintenance ?
Mark Hellar : Pour Agent Ruby, il s’agit surtout de vérifier la version de Java, patcher la dernière version d’Ubuntu, comment le faire… C’est du vrai travail d’informaticien, mais appliqué aux composants spécifiques d’Agent Ruby. Ce n’est peut-être pas suffisant, d’autant que se pose la question du hardware : sera-t-il possible d’envoyer ce protocole RS-23237 vers le nouveau port, via la machine virtuelle ? Je suis content qu’on parle de hardware, parce que jusqu’ici il ne s’agissait que de software. Le hardware, c’est un domaine tout à fait différent. C’est très difficile aujourd’hui, d’autant plus que les installations électroniques comprennent de nombreux composants très spéciaux.
Nous devrions peut-être nous pencher sur les FPGA38, qui sont des espèces de machines virtuelles pour les composants électroniques. Je suis très loin de tout ça, mais quelqu’un a réussi à reconstituer un Commodore 64 entier au moyen de ces FPGA. C’est une puce, grâce à laquelle cette personne a créé un émulateur de Commodore 6439, mais en hardware, pas en software. Le langage de programmation VHDL40 est nécessaire pour l’utiliser ; on conçoit un circuit, on le télécharge, et ça devient une machine virtuelle, mais au niveau du hardware. J’imagine qu’un jour, on pourra utiliser ce genre d’outils pour préserver des installations basées sur du hardware, puisqu’il fait office de machine virtuelle pour les composants électroniques.
PACKED : Idéalement, quelle devrait être la marche à suivre lors d’une acquisition ? Que doit demander un musée lorsqu’il achète une œuvre ?
Mark Hellar : Agent Ruby avait déjà été acquis quand je suis arrivé, mais j’ai créé ce type de consignes cette année, pour le département d’architecture et de design du SFMOMA. Ils possèdent actuellement des fichiers aux formats H26441 et Divx42. Je leur ai recommandé de recontacter les créateurs pour leur demander des fichiers non compressés ou compressés sans perte, pour les copies d’archives. J’ai fait un exposé sur les codecs au SFMOMA. J’y ai expliqué les différents niveaux de compression en commençant par les formats non compressés, pour les encourager à préférer les fichiers les moins compressés (ou pas compressés du tout, si possible), tout en disposant d’une copie d’exposition en H264 par exemple. Cela est maintenant intégré dans leurs processus d’acquisition. Donc nous travaillons sur cet aspect. Concernant le software, je leur recommande de se procurer le code source, tout en étant conscients que des plateformes comme Flash sont liées à une entreprise qui disparaîtra peut-être un jour. J’essaie de les sensibiliser à ces problématiques.
PACKED : Ce processus a-t-il lieu durant l’examen technique de l’œuvre ?
Mark Hellar : L’examen de l’œuvre n’est pas purement technique : il décrit également l’œuvre et ce qu’elle fait. Il faut utiliser tous les outils à notre disposition pour examiner l’œuvre avec soin : tous les composants, les fichiers, l’électronique. La moindre information doit être intégrée à la documentation : le PDF d’un circuit Arduino s’il y en a un, les caractéristiques techniques de je ne sais quel obscur capteur, les instructions du programmeur, etc. La documentation doit expliciter la manière dont toutes les parties fonctionnent ensemble, en incluant éventuellement des schémas. Je sais que tout le monde n’a pas forcément le temps de faire ça, mais si l’on veut conserver ces œuvres, il faut développer de nouvelles compétences.
PACKED : Cela se base également sur l’entretien que vous avez eu avec l’artiste.
Mark Hellar : Oui. Jill Sterrett, Rudolf et moi avons eu une longue conversation avec Lynn Hershman Leeson et son technicien. C’était très important, parce que l’artiste expliquait qu’on pouvait « sans problème mettre à jour le programme Java, mais pas modifier les entrées de la base de données ». Cela nous a donc paru très important. Comme l’artiste est encore en vie, nous essayons de l’interroger chaque fois qu’il faut faire une migration, une mise à jour ou une transformation importante. Ces entretiens sont évidemment consignés. Dans cent ans, on pourra retrouver les intentions de l’artiste. Ce n’est pas un système parfait, mais ces informations sont très précieuses.
PACKED : Quand vous recevez une œuvre basée sur un ordinateur, où tout fonctionne et pourra fonctionner pendant les dix années suivantes, ne serait-il pas utile, au niveau de la documentation, de prendre un ordinateur similaire, d’y installer le même système d’exploitation et les mêmes logiciels, puis de faire tourner l’œuvre pour voir si rien ne change ? Même en installant le même OS ou la même application, il y a beaucoup d’options qu’on peut activer ou désactiver.
Mark Hellar : Oui, on peut le faire, pour savoir ce dont on a besoin ou non. C’est une excellente question. Il faudrait connaître la configuration recommandée du système, je suppose, mais Agent Ruby peut tourner sur n’importe quelle machine, vu que c’est en Java. J’ai créé un nouveau serveur Linux Ubuntu, avec prise en charge pour les cinq prochaines années, sur lequel je n’ai installé qu’Apache, Java et quelques autres logiciels ; ça donne un joli petit serveur Linux. Quand on installe un système d’exploitation, on peut choisir de ne pas installer la langue allemande ou MS Paint, par exemple. Nous avons décidé de garder une version épurée de Linux.
S’il est possible d’obtenir de l’artiste la configuration recommandée pour l’installation sur un nouveau système, je privilégierais cette option. Malheureusement, ce n’est pas une information facile à obtenir de l’artiste. Si c’est impossible et que l’œuvre a déjà été acquise, VMware est doté de l’outil P2V. Grâce à cet outil, on peut transformer une machine réelle en une machine virtuelle. Puis, après s’être assuré que tout fonctionne, on peut tester chaque configuration et arriver à une description technique très complète. Pour Agent Ruby, nous avons décomposé chaque partie pour voir la configuration nécessaire et la manière dont le tout fonctionnait. Nous en avons aujourd’hui une compréhension très claire.
Le P2V n’est pas parfait, mais c’est un bon outil. Chacun a ses propres outils ; un conservateur spécialisé dans la pierre a sa boîte à outils. Nous devons connaître les outils qui sont à notre disposition dans notre domaine et développer un ensemble de compétences. Je suis sûr que ce sera bientôt le cas, mais à l’heure actuelle il n’y a pas beaucoup de programmes en conservation des nouveaux médias dans les universités. Tout ce qu’on a aujourd’hui, ce sont des artistes qui souhaitent nous laisser leurs œuvres afin d’identifier les outils adéquats pour leur conservation, et qui sont prêts à partager de telles connaissances.
PACKED : Des accords avec l’artiste au moment de l’acquisition peuvent également se révéler importants. Cette part du travail de préservation précède donc ce qui est fait quand l’œuvre intègre la collection ?
Mark Hellar : Oui, il faut récolter le plus d’informations possible ; le fait d’avoir le code source peut avoir une grande influence. Je parlais avec Richard Reinhardt de fichiers programmés en C43 et compilés pour Windows 95, et il m’a dit : « J’ai besoin du code source », que l’artiste n’avait pas. Il se l’est quand même procuré et s’il ne peut pas le décompiler, il pourra peut-être le faire tourner indéfiniment sur une machine virtuelle. C’est un bon exemple d’outil – la machine virtuelle –utilisé pour montrer une œuvre.
PACKED : Est-il difficile de développer ces compétences en interne, même pour des œuvres moins complexes ? Comment un musée peut-il gérer les différents types de compétences et de connaissances nécessaires pour la conservation des œuvres numériques, qui englobent souvent de nombreux domaines technologiques ? De Java à Arduino ou Flash, la palette de connaissances à acquérir est très large. Quels types de connaissances les musées doivent-ils rechercher ?
Mark Hellar : Oui, parfois ces technologies peuvent sembler très ésotériques (rires). Selon moi, il faut appliquer la philosophie du Media Lab du MIT : « Si vous ne connaissez pas quelque chose, apprenez-le. » Au SFMOMA, nous créons un modèle afin de couvrir au moins les œuvres de la collection. Les musées ont besoin de ces nouvelles compétences et ils doivent s’interroger sur la manière de les acquérir. La plupart d’entre eux se posent déjà la question : si nous voulons acquérir ce type d’œuvres, de quoi aurons-nous besoin ? On voit apparaître de nouveaux programmes qui abordent les technologies numériques, mais les musées en ont besoin dès aujourd’hui. Les musées doivent donc se demander de quel type de compétences ils ont besoin et comment ils peuvent les développer.
PACKED : Si les musées n’acquièrent pas ces compétences, tout ce savoir pourrait disparaître, puisque très peu de personnes veulent apprendre à manipuler des technologies aussi anciennes que ces composants électroniques ou à programmer avec ActionScript, par exemple. Pour certains, cela n’a pas de sens de revenir en arrière.
Mark Hellar : Oui, ou apprendre comment fonctionnait un programme en Pascal44. En même temps, ces recherches sont amusantes, passionnantes ; mais ça prend beaucoup de temps. Évidemment, je comprendrais que certains ne veuillent pas revenir aux vieux fichiers en Pascal ou chercher de vieux Palm Pilot sur eBay (rires).
PACKED : Est-ce que vous conseilleriez aux musées de se procurer les logiciels nécessaires aux fichiers ? Si on achète une œuvre en Flash, par exemple, faut-il se procurer un CD d’installation de Flash 5 ou une licence Max/MSP ?
Mark Hellar : Il serait intéressant – mais nous n’en sommes pas là – de créer une base de données commune aux différentes institutions, et de mener une enquête sur les anciennes œuvres médiatiques qu’elles acquièrent et sur les éléments logiciels dont elles ont besoin. Avec une sorte de base de données centrale ou de fichier central répertoriant chaque œuvre, une description technique, etc., on pourrait déterminer le type d’outils nécessaires. Ensuite, on pourrait avoir une réserve centrale pour ceux-ci, mais je ne sais pas si ça pourrait marcher.
PACKED : Il pourrait y avoir des problèmes de droits et de licences.
Mark Hellar : En effet, se constituer sa propre réserve de logiciels ne serait pas une chose facile. J’espère qu’Archive.org se chargera d’une bonne partie de ce travail. J’ai vu qu’ils avaient commencé à archiver des programmes comme des patches de jeux vidéo, des applications open source des années 90 comme Winrar, Hotdog Professional, une sorte de prédécesseur de Dreamweaver… Ensuite, il pourrait y avoir des problèmes de licences selon les outils choisis ; par exemple QuickTime versus Flash versus Ogg Vorbis ou webM. J’ai dû prendre de telles décisions lorsque je travaillais sur l’œuvre d’un artiste en Processing et Java, afin d’avoir le code source. J’aurais pu le faire en Max/MSP et lui donner le code source, mais si Max/MSP disparaît, est-ce qu’il pourra encore le faire tourner? Il aurait probablement dû le faire sur une machine virtuelle, mais il y a des risques de ralentissements ou autres. Pour éviter les problèmes de licences et de droits, j’essaie autant que possible d’utiliser des solutions open source.
PACKED : Il s'agit là du cas dans le quel vous aideriez un artiste à développer une œuvre, mais que feriez-vous si vous receviez un élément qui n’a pas été créé en open source mais avec des logiciels propriétaires ? Disons qu’en vidéo, je pourrais numériser toutes mes bandes Digibeta en MJPEG2000 avec un conteneur MXF pour qu’elles soient open source par exemple, mais feriez-vous la même chose pour une œuvre numérique, en la portant de Max/MSP à Pure Data à des fins de conservation par exemple ?
Mark Hellar : Ce sont de très bonnes questions. Je pense qu’il faut en discuter avec l’artiste aussi. Heureusement, pour les œuvres du SFMOMA, les artistes sont encore en vie. On peut donc entretenir un dialogue avec eux, mais ils finiront par s’en aller. Pour ma part, je pense qu’il faut convertir les fichiers Flash en HTML5, au moins à un stade expérimental. Adobe développe un outil pour convertir le Flash en HTML5, mais je n’en ai pas encore essayé la version bêta. Je me suis rendu à une conférence sur l’opposition Flash versus HTML5. Il y a beaucoup de choses que le HTML5 est encore incapable de faire, surtout au niveau du son. Nous envisageons de convertir l’œuvre de Julia Sher en HTML5, mais j’ai entendu que le son avait été un peu laissé de côté. Le HTML5 n’est pas encore la solution ultime, mais je pense que nous allons tout de même le tester.
PACKED : Avez-vous déjà rencontré des problèmes de son avec VMware ?
Mark Hellar : Je n’ai pas beaucoup travaillé sur le son autrement que via un fichier Flash issu d’une interface web. La plupart des œuvres sur lesquelles j’ai travaillé étaient basées sur le Web. Je n’utilisais donc pas de machine virtuelle avec un patch Max/MSP par exemple, mais je suppose que les pilotes pour le son peuvent poser des problèmes.
PACKED : Il semble qu’il y ait parfois des problèmes de décalage.
Mark Hellar : Oui, il peut y avoir des décalages parce que le son doit passer par l’hôte et l’hyperviseur avant la machine virtuelle. Cela peut sans doute s’améliorer. En effet, même si ça fait longtemps que la virtualisation existe, ce n’est que vers 1996 que sont apparus des outils tels que VMware, Virtual Box ou l’environnement Xen. C’est devenu une tendance très importante aujourd’hui. Amazon EC2, Google Cloud et d’autres solutions utilisent une énorme infrastructure de machines virtuelles.
Packed : En passant de Flash au HTML5, on choisit la migration comme stratégie de préservation. En revanche, en utilisant une machine virtuelle, il n’y a pas besoin d'utiliser un format différent de celui de l’œuvre. Cet aspect vous paraît-il important ?
Mark Hellar : Tout à fait. C’est formidable pour ce type d’œuvres, parce qu’on peut faire tourner, sur une machine virtuelle, un Atari 40045 avec une œuvre créée en Pascal, le tout sur du matériel récent.
Packed : Avec des technologies comme la virtualisation ou le standard HTML5, comment pensez-vous qu’évoluera la préservation des œuvres d’art numériques ?
Mark Hellar : Ça évolue très très rapidement. J’espère que cela profitera à ce genre d’œuvres. Mais en même temps, toutes ces solutions de virtualisation sont pensées pour le Web et sont basées sur des serveurs, pas tellement sur les clients et le multimédia. Cette évolution pourrait être moins favorable au domaine de la préservation des œuvres numériques. C’est comme ça. Ces technologies sont extrêmement intéressantes pour la conservation, mais c’est du business avant tout. La culture technologique dominante est celle de l’obsolescence, mais maintenant on prend ce même produit virtuel et on l’utilise pour la postérité. Nous verrons bien de quoi l’avenir sera fait.
Notes: