Entretien avec Mark Hellar (Hellar LLC)

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.

 

Les locaux de BAVC à San Francisco. Photo : PACKED vzw.

 

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.

 

Capture d'écran de l'œuvre de Julia Sher Predictive Engineering2.

 

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.

 

À gauche, le server Red Hat original de l'œuvre de Lynn Hershmann <i>Agent Ruby</i> et à droite les serveurs VMware du SFMOMA. Photo : Mark Hellar.

 

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.

 

Capture d'écran de l'œuvre web de Lynn Hershman Leeson's, <i>Agent Ruby</i>.

 

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.

 

Un palmOne Tungsten T5.

 

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.

 

Capture d'écran de Learning To Love You More de Harrell Fletcher et Miranda July.

 

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.

 

Vue de l'installation de Bill Fontana <i>Sonic Shadows</i> dans l'Atrium du SFMOMA. Photo : Randy Yau, 2010.

 

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.

 

Détail de l'installation de Bill Fontana <i>Sonic Shadows</i> dans l'Atrium du SFMOMA. Photo : Randy Yau, 2010.

 

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.

 

Une carte Arduino. Photo : http://www.arduino.cc

 

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:

 

  • 6. Avid Technology, Inc. est une entreprise américaine spécialisée dans la technologie de production vidéo et audio, et en particulier dans les systèmes numériques de montage non linéaire et les services de management et de distribution. Fondée en 1987, elle a été introduite en Bourse en 1993. Son siège se trouve à Burlington, au Massachusetts. Les produits Avid sont utilisés dans le secteur de la télévision et de la vidéo, pour la création de films, de téléfilms et de publicités. Media Composer, un système de montage non linéaire basé sur un logiciel, est le produit phare d’Avid. Source : Wikipédia
  • 7. Final Cut Pro est un logiciel de montage vidéo non linéaire développé par Macromedia Inc. puis par Apple Inc. La dernière version, Final Cut Pro X, tourne sur les ordinateurs Mac dotés du système d’exploitation Mac OS X 10.6.7 ou ultérieur et d’un processeur Intel. Final Cut Pro permet de traiter et de transférer des vidéos sur un disque dur (interne ou externe), à partir duquel celles-ci peuvent être montées, traitées, et exportées vers un grand nombre de formats. Source : Wikipédia.
  • 8. Max est un logiciel musical et multimédia développé par Cycling74, une compagnie basée à San Francisco. Depuis vingt ans, il est utilisé par de nombreux compositeurs, performeurs, concepteurs de logiciels, chercheurs et artistes pour la création d’enregistrements, de performances et d’installations innovants. Nommé initialement Patcher, Max a été inventé par Miller Puckette au milieu des années 1980 à l’IRCAM. Fonctionnant sur Macintosh, il devait fournir aux compositeurs un outil de création pour la musique électronique interactive. Il fut utilisé pour la première fois dansPluton, une pièce pour piano et ordinateur (écrite en 1988 par Philippe Manoury) dans laquelle le logiciel synchronisait le piano et l’ordinateur et gérait un système Sogitec 4x qui opérait le traitement audio. En 1989, l’IRCAM développa une nouvelle version de Max portée sur la Signal Processing Workstation de l’institut, pour NeXT (et par la suite pour SGI et Linux), appelée Max/FTS (FTS signifiant faster than sound, ou plus rapide que le son ; le système était en quelque sorte un précurseur de MSP amélioré d’un tableau DSP). En 1989, l’IRCAM en céda la licence à Opcode Systems, qui sortit en 1990 une version commerciale du programme appelée Max (développée par David Zicarelli). Mais le logiciel ne correspondit jamais vraiment aux attentes d’Opcode Systems et l’entreprise interrompit son développement au milieu des années 1990. Depuis 1999, la version commerciale actuelle de Max est distribuée par la firme de Zicarelli, Cycling74 (fondée en 1997). En 1996, Miller Puckette publia Pd (abréviation de Pure Data), un logiciel gratuit et entièrement repensé qui, malgré de nombreuses différences avec l’original de l’IRCAM, demeure, en surface, très similaire à celui-ci et constitue une alternative open source à Max/MSP. Entre-temps, Cycling74 développa un catalogue d’extensions pour la vidéo. Un important package nommé Jitter vit le jour en 2003, permettant de manipuler la vidéo en temps réel, la 3D, et le traitement de matrices. Source : Wikipédia.
  • 9. Adobe Flash (auparavant Macromedia Flash) est une plateforme multimédia utilisée pour introduire des animations, des vidéos ou des éléments interactifs dans une page web. Flash est largement utilisé dans la publicité, les jeux et l’animation. Récemment, le programme a été repositionné en tant qu’outil pour « applications Internet riches ». Flash utilise des vecteurs et des images matricielles pour animer du texte, des illustrations et des images. Il permet la diffusion bidirectionnelle de l’audio et la vidéo, et peut intégrer l’action de l’utilisateur via une souris, un clavier, un microphone ou une caméra. Flash intègre un langage orienté objet appelé ActionScript qui permet l’automatisation grâce au langage JavaScript Flash (JSFL). Source : Wikipédia.
  • 10. Adobe Systems Incorporated est une compagnie multinationale américaine d’édition de logiciels informatiques fondée en 1982 et dont le siège se trouve à San Jose, en Californie. Historiquement, l’entreprise s’est consacrée à la création de logiciels créatifs et multimédia, et plus récemment a concentré ses efforts dans le développement d’applications Internet riches. Source : Wikipédia.
  • 11. Voir : http://www.raqsmediacollective.net
  • 12. Un circuit Arduino est un circuit imprimé sur lequel se trouve un microcontrôleur. Cette plateforme populaire, publiée en licence libre, est l’héritière de la plateforme open source Wiring, qui était conçue pour rendre l’électronique plus accessible dans des projets pluridisciplinaires. Un module Arduino consiste en un simple circuit ouvert, doté d’un processeur Atmel AVR et d’entrées et de sorties intégrées. La partie logicielle consiste en un compilateur standard et un bootloader préprogrammé. Source : Wikipédia.
  • 13. Un microcontrôleur est un simple circuit intégré rassemblant les éléments essentiels d’un ordinateur : processeur, mémoire, périphériques programmables d’entrées/sorties. Les microcontrôleurs sont conçus pour des applications embarquées, au contraire des microprocesseurs utilisés dans les ordinateurs personnels ou d’autres applications à usage général. Source : Wikipédia.
  • 14. Voir https://www.sfmoma.org/artwork/2008.231.
  • 15. Voir http://www.bampfa.berkeley.edu/.
  • 16. Voir http://www.variablemedia.net/e/welcome.html/.
  • 17. Christiane Paul est spécialiste de l’art numérique et historienne de l’art et de la technologie. Elle enseigne les arts visuels à The New School et est l’auteur de l’ouvrage incontournable Digital Art. Christiane Paul a enseigné au département d’art informatique de la School of Visual Arts de New York (1999-2008) ; au département Digital+Media de la Rhode Island School of Design (2005-2008) ; ainsi qu’au San Francisco Art Institute et au Center of New Media de l’université de Berkeley (2008). Source : Wikipédia.
  • 18. Voir http://www.franklinfurnace.org/.
  • 19. New Langton Arts était une organisation artistique sans but lucratif fondée en 1975 à San Francisco, en Californie, qui se consacrait à l’art contemporain. L’histoire de New Langton Arts est intimement liée à l’émergence de nouvelles formes artistiques dans les années 1970 – la performance et les arts médiatiques, la vidéo et l’installation, la musique improvisée et électronique, et l’écriture expérimentale. Source : Wikipédia.
  • 20. Red Hat Enterprise Linux (RHEL) est un système d’exploitation basé sur Linux développé par Red Hat et destiné au marché commercial. Red Hat Enterprise Linux existe en version serveur pour x86, x86-64, Itanium, PowerPC et IBM System z, ainsi qu’en version classique pour x86 et x86-64. La prise en charge de RHEL et les formations officielles sur la plateforme ont lieu au Red Hat Certification Program Center*. Red Hat Enterprise Linux est souvent abrégé en RHEL, bien que cela ne soit pas une dénomination officielle. Source : Wikipédia.
  • 21. Le port PS/2 est un connecteur Mini-DIN à six broches utilisé pour connecter certains claviers et souris à un système informatique compatible PC. Son nom provient de la gamme d’ordinateurs personnels IBM Personal System/2, qui furent commercialisés en 1987.
  • 22. VMWare, Inc. est un éditeur de logiciels de virtualisation fondé en 1998 dont le siège se trouve à Palo Alto, en Californie. Source : Wikipédia.
  • 23. En sécurité informatique, un sandbox est un mécanisme de sécurité qui permet de séparer les programmes actifs. On l’utilise souvent pour exécuter des codes non testés ou des programmes douteux provenant de tiers ou de fournisseurs inconnus, d’utilisateurs ou de sites web peu fiables. En général, un sandbox fournit un ensemble de ressources surveillées de près où les programmes peuvent être exécutés, telles que de l’espace destiné à la mémoire temporaire sur un disque ou une unité de mémoire. En général, l’accès réseau et la possibilité d’inspecter le système hôte ou d’écrire des données depuis des appareils tiers, sont bloquées ou fortement limitées. Dans ce sens, les sandbox constituent un certain type de virtualisation. Source : Wikipédia.
  • 24. Amazon Web Services (AWS) est un ensemble de services informatiques à distance (aussi appelés services web) fournis via Internet par Amazon, qui constituent une plateforme de cloud-computing. Les services les plus connus et les plus importants sont Amazon EC2 et Amazon C3. Source : Wikipédia.
  • 25. Une machine virtuelle Java est une machine virtuelle capable d’exécuter du bytecode Java. C’est le composant chargé de l’exécution du code dans la plateforme logicielle Java. Source : Wikipédia
  • 26. Le XML (Extensible Markup Language) est un langage de balisage informatique qui définit une série de règles pour encoder des documents dans un format lisible à la fois par un humain et une machine. Ce langage est défini dans la spécification XML 1.0 établie par le W3C, ainsi que dans d’autres spécifications, toutes gratuites et open source. Source : Wikipédia.
  • 27. MySQL est le système de gestion des bases de données relationnelles (RDBMS) le plus utilisé au monde. Fonctionnant comme un serveur, il fournit à de multiples utilisateurs l’accès à un certain nombre de bases de données. Le projet de développement de MySQL a publié son code source sous la Licence publique générale GNU, mais aussi selon les termes d’autres accords propriétaires. D’abord la propriété d’une entreprise commerciale, la firme suédoise MySQL AB, MySQL est aujourd’hui la propriété d’Oracle Corporation. Source : Wikipédia.
  • 28. Les appareils mobiles Palm étaient des PDA (Personal Digital Assistant) fonctionnant sous le système d’exploitation Palm OS. Source : Wikipédia.
  • 29. Le format SWF est un format Adobe Flash utilisé pour le multimédia, les images vectorielles et ActionScript. Créés par FutureWave Software avant de passer par Macromedia, qui fut lui-même repris par Adobe, les fichiers SWF peuvent contenir des animations ou des applets de divers fonctions et degrés d’interactivité. Actuellement, le format SWF est le format le plus utilisé pour diffuser des images vectorielles « animées » sur le Web. Il peut également servir dans des programmes, notamment des jeux sur navigateur web, grâce à ActionScript. Source : Wikipédia.
  • 30. ActionScript est un langage orienté objet créé par Macromedia Inc. (aujourd’hui devenu la propriété d’Adobe Systems). C’est un dialecte d’ECMAScript (c’est-à-dire un sous-ensemble de la syntaxe et de la sémantique de Javascript, un langage plus largement répandu) utilisé principalement pour le développement de sites web et de logiciels à destination de la plateforme Adobe Flash Player, qu’on retrouve sur des pages web sous la forme de fichiers SWF embarqués. Source : Wikipédia.
  • 31. En informatique, un fichier de configuration est un fichier contenant les informations de configuration d’un programme informatique. Ils servent aux applications utilisateur, aux processus serveur et aux réglages du système d’exploitation. Ces fichiers sont souvent écrits en ASCII (rarement en UTF-8) et structurés en lignes, avec des lignes se terminant par une nouvelle ligne ou, selon le système d’exploitation, le caractère CRLF, qui indique la fin de la ligne ou du texte. On peut les considérer comme des bases de données simples.
  • 32. Voir : http://www.learningtoloveyoumore.com/.
  • 33. Voir : http://rhizome.org/.
  • 34. Une interface de programmation (Application Programming Interface ou API) est une spécification basée sur un code source servant d’interface pour que les composants d’un logiciel communiquent entre eux. Une API peut contenir des spécifications pour des routines, des structures de données, des classes d’objets et des variables. Source : Wikipédia.
  • 35. Voir http://cycling74.com/.
  • 36. Opcode Systems, Inc. fut fondé en 1985 par Dave Oppenheim dans la région de Palo Alto, en Californie. Opcode éditait des logiciels de séquençage MIDI pour Mac OS et Microsoft Windows, qui permettraient par la suite de travailler avec de l’audio numérique, ainsi qu’avec des interfaces hardware MIDI. Le séquenceur MIDIMAC d’Opcode, commercialisé en 1986, fut le premier séquenceur MIDI pour Macintosh, et l’un des tout premiers séquenceurs musicaux disponibles dans le commerce toutes plateformes confondues. Source : Wikipédia.
  • 37. Un port RS-232 équipait à une époque tous les ordinateurs personnels et servait pour les connexions avec les modems, imprimantes, souris, périphériques de stockage, alimentation sans interruption et autres périphériques. Mais la vitesse de transfert limitée, les variations de tension assez importantes et la taille des connecteurs standard entraînèrent le développement de l’USB (Universal Serial Bus) qui remplaça le RS-232 dans la plupart de ses applications comme interface d’un périphérique. De nombreux ordinateurs modernes n’ont pas de port RS-232 et doivent utiliser un adaptateur externe pour se connecter à d’anciens périphériques. On trouve encore certains appareils RS-232, surtout dans les machines industrielles ou les instruments scientifiques. Source : Wikipédia.
  • 38. Un circuit logique programmable (Field-programmable gate array ou FPGA) est un circuit intégré qui peut être reprogrammé après sa fabrication. En général, la configuration du circuit est définie dans un langage de description de matériel (HDL) similaire à celui utilisé dans un circuit intégré propre à une application (ASIC) (auparavant, on utilisait des schémas électroniques pour définir la configuration, tout comme pour les ASIC, mais c’est de plus en plus rare). Les circuits logiques programmables servent à implémenter toutes les fonctions logiques que peut effectuer un ASIC. La possibilité de mettre à jour les fonctionnalités après l’expédition du produit, celle de reconfigurer partiellement une partie du circuit, et les faibles frais non récurrents en comparaison d’un circuit ASIC (malgré son prix à l’unité plus élevé), lui confèrent des avantages dans de nombreuses applications. Source : Wikipédia.
  • 39. Le Commodore 64 est un ordinateur domestique 8-bits commercialisé en janvier 1982 par Commodore International. Il s’en est vendu entre 12,5 et 17 millions d’exemplaires au total, ce qui en fait le modèle d’ordinateur le plus vendu à ce jour. Source : Wikipédia.
  • 40. VHDL (VHSIC Hardware Description Language) est un langage de description de matériel utilisé en automatisation électronique pour représenter les systèmes numériques et mixtes tels que les FPGA (circuits intégrés programmables) et les circuits intégrés. Source:  Wikipédia.
  • 41. Le H.264 est un codec de compression vidéo numérique pour images et vidéo haute définition, qui utilise le standard MPEG-4. Il est développé par le VCRG (Video Coding Experts Group) en partenariat avec le MPEG (Moving Picture Experts Group), également connu sous le nom d’AVC (Advanced Video Coding). Source : Wikipédia.
  • 42. DivX est une marque déposée de DivX, Inc. (anciennement DivXNetworks, Inc.) qui inclut des produits comme le codec DivX, devenu populaire grâce à sa capacité de compression de longs segments vidéo en fichiers de petite taille, tout en conservant une qualité d’image relativement bonne.
  • 43. C est l’un des langages de programmation les plus répandus de l’histoire de l’informatique. Des compilateurs C existent pour la plupart des architectures informatiques. C a influencé de nombreux autres langages de programmation, dont le plus célèbre est C++, qui était au départ une extension de C. Source : Wikipédia.
  • 44. Pascal est un langage de programmation impératif et procédural à l’influence considérable, créé en 1968-69 et dévoilé en 1970 par Niklaus Wirth. Celui-ci le présenta alors comme un langage simple et efficace destiné à encourager de bonnes pratiques de programmation, en utilisant notamment la programmation et des données structurées. Source : Wikipédia.
  • 45. La famille Atari 8-bits désigne une série d’ordinateurs 8-bits conçus entre 1979 et 1992. Tous se basent sur le processeur MOS Technology 6502. Ce furent les premiers ordinateurs domestiques dotés de coprocesseurs spécifiques. Dans les années suivantes, plusieurs versions du même appareil de base furent commercialisées, notamment les Atari 400, 800 et leurs successeurs, les séries XL et XE. Globalement, les ordinateurs Atari 8-bits furent un succès commercial, puisqu’il s’est vendu deux millions d’exemplaires durant la plus importante période de production entre 1979 et 1985, pour un total de quatre millions d’exemplaires vendus.
interview_tag: 
logo vlaamse overheid