Programmer avec...

Maîtrise technique et innovation sont deux aspects indissociables de l’histoire très riche des arts visuels. L’invention de l’imprimerie constitue un excellent exemple de la manière dont une évolution technologique peut se répercuter dans l’ensemble de la société. Au xxie siècle, en revanche, l’innovation en matière de design revient bien souvent à exploiter toutes les possibilités offertes par les ordinateurs pour explorer de nouvelles voies des arts visuels. Et si l’écriture de logiciels n’est généralement pas une activité habituelle des designers, ils sont de plus en plus nombreux à produire des logiciels sur mesure. Notre expérience personnelle de ces dix dernières années, sans se prétendre exhaustive, nous a cependant montré les avantages et les inconvénients associés à l’écriture logicielle dans le cadre de la pratique des arts visuels. Elle influence la typographie, la photographie et la composition. Elle a également donné naissance à de toutes nouvelles pratiques pour les designers, parmi lesquelles la conception de supports en réseau (navigateurs web, téléphones mobiles, tablettes) et les installations interactives. Et plus important encore, peut-être, les designers qui conçoivent des logiciels repoussent les limites de la réflexion en matière de design. Pour entrer directement dans le vif du sujet, nous avons posé deux questions, toutes simples en apparence, à un groupe de designers exceptionnels :

◥ Pourquoi écrivez-vous vos logiciels plutôt que d’utiliser des outils existants ?

◥ En quoi le fait d’écrire vos propres logiciels affecte-t-il votre processus de création et les qualités visuelles de l’oeuvre finale ?

Si les réponses reflètent l’expérience individuelle propre à chaque designer et à ses méthodes de travail, de grandes lignes s’en dégagent. Réponse la plus courante : le fait d’écrire soi-même ses programmes permet un meilleur contrôle, lequel est souvent présenté comme une liberté individuelle. Autre thème récurrent : écrire ses logiciels est un moyen de s’éloigner des solutions génériques. Les nouveaux outils sont synonymes de nouvelles opportunités. Les designers expérimentés savent qu’un logiciel tout prêt n’offre en aucun cas les qualités d’un logiciel sur mesure en tant que support d’expression et de communication. En créant de tels outils, uniques, les créateurs s’ouvrent de nouveaux horizons.

Erik van Blokland

Quand j’ai commencé à développer mes propres outils, je suis devenu plus critique envers les outils existants… et beaucoup moins patient face aux limites imposées par d’autres. Le fait de créer soi-même ses outils offre une perspective très puissante sur la conception : le code est là au service de l’idée, et non l’inverse. Il y a moins de compromis à faire et quand c’est le cas, au moins ils viennent de moi et c’est plus facile à vivre. Je ne pense pas être un puriste, j’utiliserais avec plaisir les outils existants s’ils étaient adaptés à la tâche, avec des critères très variables. L’idée et, partant, l’axe suivi pour le design devraient orienter le processus, et non les limites arbitraires imposées par les outils existants. Quand on ne parvient pas à réaliser quelque chose avec un outil donné, il faut essayer de l’améliorer ou d’en créer un meilleur, sans nécessairement passer un compromis entre l’idée de départ et les contraintes spécifiques de cet outil. Les bonnes idées sont rares – il faut en cultiver des millions, avec une patience infinie, pour en trouver une. Il serait vraiment trop bête de la tuer dans l’oeuf.
Dans certains de mes projets, le code influence les formes elles-mêmes, comme des filtres qui synthétisent le détail ou génèrent des motifs ou une texture. On peut ainsi produire (relativement) rapidement des choses assez complexes, et les évaluer. Faire ces choses « à la main », même en utilisant un ordinateur, prendrait bien plus de temps et me contraindrait à m’engager selon un ensemble de paramètres sans en saisir toutes les implications. Ces projets sont très spécifiques, très personnels et très proches du design. Écrire, générer. Évaluer. Bricoler (le code, les paramètres ou les deux), générer à nouveau, répéter. Les itérations du design sont les itérations du code, le code étant aussi ouvert que le design lui-même.
Souvent, pourtant, le code semble être derrière l’écran, ne pas avoir d’impact direct sur les formes, autoriser de nouvelles directions, créer des arborescences ou des arborescences d’images. Il peut cependant, par exemple, impliquer des librairies qui standardisent des objets représentant des données spécifiques ; ou, à l’inverse, un format ouvert, documenté, qui remplace un « standard du secteur » propriétaire et non documenté. En raison de ces abstractions, il est (parfois) un peu plus difficile de trouver l’énergie de créer, mais les outils que l’on en retire sont très puissants. Ici, structure et collaboration ont leur importance. À quel niveau pouvons-nous nous mettre d’accord et que pouvons-nous partager ? Quelle voie suivre pour rester soi-même ? Ce sont des questions très intéressantes, auxquelles il n’est pas facile de répondre, mais qui nous obligent à réfléchir sur le travail créatif (design, art, code) et sur nos méthodes de travail (et celles que nous aimerions appliquer).

Erik van Blokland et Just van Rossum ont cofondé LettError en 1989 aux Pays-Bas. Cette fonderie en ligne leur permet de diffuser leurs créations, aboutissement de leur collaboration mixant typographie et programmation. http://www.letterror.com

 Catalogtree

« Dis-moi ce que tu manges, et je te dirai qui tu es. » Nous écrivons nos propres logiciels principalement pour effectuer automatiquement diverses tâches répétitives, mais cette méthode est également importante pour nous dans le cadre de nos efforts de création expérimentale d’outils. Choisir une technique de production est une décision importante pour nous et le fait de créer nos propres outils, qu’il s’agisse des logiciels ou du matériel, est un moyen d’éviter des choix trop évidents.
Mais ce processus est incertain, voire quelque peu « bricolé ». Par choix, nous sommes amateurs en la matière. C’est pourquoi nous n’utilisons pas tous ces outils pour nos commandes. Nous n’avons d’ailleurs toujours pas d’utilité directe pour : un projecteur de diapositives contrôlé par iPod, un dispositif assez précis de projection de punaises sur cibles mouvantes, un scanner 3D, des fusées à eau et une armée de vibro¬bots prévus pour dessiner sur un cadre d’impression. Ce qui est important, finalement, c’est que les plus beaux sites transgressent les limites imposées.
La programmation est le processus. Voici déjà quelque temps, nous avons travaillé un an sur des sites séparés : Daniel dans un immeuble de bureaux à Rotterdam (avec une vue géniale) et Joris dans un studio au fond de son jardin (avec le chant des oiseaux). On travaillait le design par téléphone. Et même si ce n’était pas idéal, ce n’était pas non plus complètement aberrant pour nous. Nous utilisons notre propre vocabulaire pour discuter des projets et nous faisons les schémas en nous les décrivant les uns aux autres. La plupart se basent sur le langage et sont finalisés avant même d’adopter une forme visuelle. Au téléphone, il ne sert à rien de décrire chaque page d’un livre, chaque marge, chaque modification d’interlettrage d’un titre. Mais il faut parfois seulement cinq secondes pour décrire un système qui part de la plus petite unité d’information pour arriver, par exemple, à un envol d’oiseaux sur l’écran.
Dans un système d’intelligence en essaim, une unité ne permet pas de prédire le comportement du groupe. Notre objectif est de concevoir des designs ayant, dans une certaine mesure, ces mêmes propriétés, où nous savons comment se comportera la plus petite unité d’information mais pas à quoi ressemblera la forme définitive. Pour nous, un travail réussi ne se résume pas à la somme de ses parties.
Pourtant, un design réussi signifie aussi choisir le rose qui convient le mieux et la bonne police de caractères. Nous ne suivrons pas un algorithme de façon dogmatique s’il ne génère pas les bons résultats. Il ne s’agit pas seulement de connaître les règles, mais de savoir ce qu’il faut faire quand on se retrouve face à une situation où elles n’ont plus cours. Il devient alors possible de créer le petit plus qui fera toute la différence.

Catalogtree est un atelier fondé en 2001 par Daniel Gross et Joris Maltha, basé à Arnhem aux Pays-Bas. Il est notamment réputé pour ses réalisations dans le domaine de la visualisation de données, du design génératif et de la typographie. http://www.catalogtree.net

Amanda Cox

Mad Libs est un jeu où les mots clés d’une histoire sont remplacés par des blancs. Les joueurs remplissent les blancs avec des éléments de discours prédéfinis (« nom », « adverbe », etc.) ou des catégories de mots (« partie du corps », « type de liquide »), sans connaître le reste de l’histoire. Certaines phrases sont très drôles, mais personne n’y verrait un moyen de produire de la grande littérature.
De la même manière, les gabarits prédéfinis ne génèrent que très rarement des graphiques exceptionnels. Certes, les solutions génériques fonctionnent très bien dans certains cas. Par exemple : « _____ (indice boursier) a ____________ (adverbe) chuté depuis ________ (année). [Schéma : courbe]. » Mais il est peu probable que ces graphiques soient très révélateurs ou incitent à voir le monde d’un oeil nouveau.
Au contraire, les graphismes les plus frappants exploitent des structures uniques, exclusivement dédiées à certains types de données. Or, cela requiert un contrôle bien supérieur à celui qu’offre une solution préfabriquée, car le même format appliqué à un sujet différent ne révèlerait rien d’intéressant.
Mais si l’on sait manier les points, les lignes et le texte, on peut faire à peu près ce que l’on veut. Et l’on se retrouve alors à explorer les possibilités, à réfléchir à haute voix et à se demander « et si… ? », au lieu de perdre du temps à tenter de contourner les paramétrages par défaut d’un programme tout prêt. Avec un peu de chance, on peut même aller jusqu’à trouver un côté fascinant à son travail.

Amanda Cox travaille depuis 2005 pour le New York Times où elle imagine les tableaux, les diagrammes et les cartes qui sont reproduits dans l’édition papier et sur le site internet du journal. Elle est titulaire d’un master de statistique de l’université de Washington. http://www. nytimes.com

Nicholas Felton

Depuis quelques années, mon travail est entièrement axé sur les données et mon processus de design de plus en plus centré autour d’une approche basée sur des règles. J’ai développé un ensemble de protocoles destinés à créer des cartes et des graphiques, efficaces mais laborieux et chronophages. Il est rapidement devenu évident que pour produire plus et travailler sur de plus grandes quantités de données, je devais trouver un moyen d’automatiser les tâches répétitives. Avec Processing, j’ai pu concevoir des applications utilisant mes méthodes, au lieu de devoir les plier aux exigences des logiciels existants. Il reste toujours possible d’intervenir sur ces applications : si le résultat ne correspond pas à mes attentes, j’ai ainsi la possibilité de modifier le code pour identifier et résoudre le problème. Par défaut, ces applications sont aussi très malléables, ce qui me permet d’adapter le code à chaque projet.
Quand j’ai débuté dans l’écriture de logiciels, les programmes que je concevais me permettaient simplement de faire le même travail plus rapidement et avec plus de souplesse. Le logiciel n’avait donc pas d’impact sur le produit final. Mais quand j’ai appris à mieux connaître ces outils, et accumulé un peu d’expérience, j’ai commencé à produire des oeuvres qui auraient été très difficiles, voire impossibles à produire avec des méthodes manuelles. J’ai fait des essais avec des cartes reposant sur des algorithmes complexes et développé des outils qui me permettent de tester toutes sortes de variables avant d’obtenir une visualisation finale.

Concepteur de systèmes complexes de visualisation de données, Nicholas Felton s’est spécialisé dans le design d’information. Il a réalisé de nombreux rapports d’activité, notamment ceux liés à la sienne propre, grâce à des systèmes inventifs de tableaux, cartes et diagrammes. http://www.feltron.com

FIELD (Marcus Wendt)

Quand j’étais étudiant, j’adorais la nouvelle esthétique de la peinture et de l’architecture modernes. Je voulais associer des structures élégantes et minimalistes avec la complexité et la richesse émotionnelle. Comme si j’avais été capable de réunir Zaha Hadid et Gerhard Richter.
Il m’a fallu de nombreuses tentatives pour me rendre compte du fait qu’écrire du code pouvait jouer un rôle important en ce sens. Les outils traditionnels du design rappellent cette image vieillissante de l’artiste seul, laborieusement courbé sur son bureau pour créer des images statiques à grand renfort de travail manuel. À mesure que j’apprenais à coder, je me rendais compte à quel point travailler avec ces outils pouvaient être une source immense de dynamisme. Car il est possible de générer des créatures numériques vivantes, des films qui semblent différents à chaque nouveau visionnage et des outils de design capables de produire 10 000 peintures numériques par jour.
L’écriture de code suit une approche architecturale ascendante et insiste donc davantage sur le processus que sur le résultat final. Au lieu de travailler vers une image unique, on commence à penser en termes de possibilités d’un système. Concevoir un processus plutôt que son résultat final contraint celui qui le crée à rester très ouvert, à accepter de travailler avec des résultats inattendus et parfois, à adopter le produit final malgré quelques surprises.
Il n’est pas facile de tricher quand on travaille avec du code : avant d’écrire quelque chose, il faut déjà avoir les idées claires. C’est un peu comme planifier puis construire une maison, la grande différence étant qu’avec le code, une fois le travail terminé, il est toujours possible de revenir en arrière pour modifier les fondations et obtenir un résultat entièrement différent.

FIELD (Marcus Wendt) est un studio de création graphique et d’art numérique fondé à Londres en 2009 par Marcus Wendt et Vera-Maria Glahn. Ils développent de nombreux projets pour lesquels le code est un outil prépondérant. Ils réalisent des installations, des illustrations et des dispositifs interactifs. http://www.field.io

LUST

Dans notre studio, la forme est le résultat d’un processus. Quand nous abordons un projet, nous essayons d’être aussi ouverts que possible. Par la recherche et l’analyse, nous laissons le projet prendre vie, celui-ci ayant déjà sa propre existence mais devant être mis en valeur. À partir de là, nous cherchons le meilleur moyen d’exécuter cette idée et, ce faisant, d’aller plus loin pour développer la forme et le concept.
Avec cette façon d’aborder les projets, les logiciels/outils existants sont souvent insuffisants pour exécuter correctement une idée. Nous avons aussi tendance à suivre des idées qui impliquent de nouvelles façons d’aborder les choses, de la typographie aux données en passant par l’interactivité. Dans ces différents cas, le développement de logiciels et outils sur mesure est une évolution naturelle du processus, et un aspect parfois décisif dans le cadre du développement d’une idée.
Si la programmation s’éloigne nettement des méthodes dites « classiques », des processus de ce type ont pourtant toujours été présents dans notre travail. Depuis les débuts de notre studio il y a quinze ans, nous avons adopté une méthodologie basée sur le processus, par laquelle un processus analytique débouche sur un produit final qui s’autoconçoit. Cela coïncide parfaitement avec l’idée d’écrire notre propre code et de construire nos propres outils. La transition de méthodes plus « traditionnelles » vers des méthodes de ce type s’est faite tout naturellement.
En effet, à un certain moment, on comprend qu’il n’y a pas d’autre moyen d’exécuter une idée que de la réaliser soi-même à partir de zéro. C’est un moyen de s’affranchir des contraintes des logiciels préfabriqués et cela permet de rester en lien étroit avec ses idées, ce qui ne serait pas possible autrement. Si tout support a un impact sur le résultat visuel d’un projet, nous sen¬tons bien que le fait de construire des outils spécifiques à chaque projet nous donne l’opportunité de définir et contrôler leurs performances en fonction de chacun d’entre eux. Finalement, la qualité visuelle d’une oeuvre doit être inhérente au projet lui-même et non enracinée dans une approche ou une technique particulière. Le résultat doit parler de lui-même.

Créé en 1996 par Jeroen Barendse, Thomas Castro et Dimitri Nieuwen¬huizen, LUST est un atelier pluridisciplinaire situé à La Haye aux Pays-Bas. Leur travail va de l’édition à la visualisation de données et de l’interactivité à la cartographie. http://www.lust.nl

Boris Müller

Il est assez étonnant de constater que la plupart des outils logiciels que nous utilisons au quotidien ressemblent à une activité spécifique du monde analogique, ou même du passé analogique. Même les oeuvres créatives, visuelles, sur ordinateur, se basent sur des données manuelles. Le designer utilise des outils logiciels pour obtenir manuellement un résultat formel.
Mais la créativité n’est en aucun cas l’apanage du travail manuel. Elle concerne aussi les idées. Et pour ce qui est des idées, le logiciel offre de vastes possibilités. Comme tout langage, les langages de programmation sont là pour exprimer des idées. Ils nous permettent de créer des choses excessivement complexes, mais pourtant stables et cohérentes.
Ainsi, au lieu de faire apparaître manuellement une image, je formule une idée dans un langage formel afin de la transformer en vue d’obtenir le nombre d’images de mon choix.
Les plus belles idées ne génèrent pas forcément les plus belles images. Au cours du processus de design, je dois travailler à deux niveaux différents. Le premier consiste à faire d’une idée un système abstrait. Le second est de traduire le système en une forme visuelle. Il n’y a aucun déterminisme dans le processus de traduction. Parfois, il est évident et fortement lié au système abstrait. Mais bien souvent, je dois prendre un grand nombre de décisions en matière de design qui reposent uniquement sur la qualité du résultat visuel. Pour qu’une idée abstraite devienne une image à part entière, il faut toujours passer par le cerveau du designer.

Boris Müller réalise de nombreux projets incluant la programmation. Il réalise notamment l’identité visuelle du festival de littérature de Brême, Poetry on the road, travail pour lequel il a reçu de nombreux prix. Il enseigne à l’université de Potsdam et est associé dans le studio One/One.
http://www.esono.com

onformative

Les logiciels existants limitent souvent les possibilités de mise en oeuvre, imposant ainsi des solutions et des résultats. En écrivant nos propres logiciels, nous passons outre ces barrières et créons simultanément de nouvelles façons de concevoir le processus de design, avec des outils qui grandissent et se développent au fur et à mesure. Ce cheminement est passionnant.
Bien entendu, quand cela s’avère pertinent, nous utilisons aussi des logiciels existants. Nous croyons en effet que l’association habile de logiciels génériques avec nos propres outils est le moyen le plus efficace d’arriver aux meilleurs résultats. Quoi qu’il en soit, il est assez rare d’écrire soi-même l’ensemble des programmes, la tendance étant plutôt d’utiliser des éléments existants ou de piocher des éléments dans une librairie et des extraits de code dans une autre. On peut alors associer l’ancien code et le nouveau et obtenir ainsi des résultats basés sur ses propres idées.
Cette méthode est possible grâce aux échanges très actifs au sein de certaines communautés, comme le forum processing.org.
Dès lors, le processus de design ne se divise plus aussi nettement entre les étapes de définition du concept, du design et de la production. Au contraire, le travail de conception se mêle à la production, et le projet se crée via plusieurs petites étapes d’itération dans lesquelles idée, design et programmation sont toujours étroitement liés. Quand on écrit ses propres logiciels, le travail de création et la mise en oeuvre sont deux étapes interdépendantes. La séparation entre design et production est abolie. Parce que l’on voit alors d’un oeil nouveau les méthodes de travail et le détail des processus de son logiciel, il devient beaucoup plus facile de tenter de nouvelles expériences, ce qui a un effet direct sur la qualité du travail.

onformative a été fondé par Julia Laub et Cedric Kiefer à Berlin. Leur activité intègre la conception de livres et la visualisation de données. Ils développent également des projets expérimentaux liés aux nouvelles technologies. http://www.onformative.com

Jonathan Puckey

J’adore la sensation que procure l’immersion dans les arcanes d’un langage visuel conçu par mes soins. J’enfile ma casquette de développeur et je réfléchis aux fonctionnalités dont j’ai besoin en tant qu’utilisateur. Je pense à l’équilibre entre la touche personnelle que j’apporte via la conceptualisation et la fabrication du logiciel. Je pense aussi à la touche personnelle que je peux apporter, ou que d’autres peuvent apporter, en utilisant le logiciel de différentes manières. Quand j’utilise mes outils, je veux oublier la complexité sous-jacente de leur fonctionnement et me concentrer sur la manière dont mes données génèrent une production.
Je sépare le processus de design en deux. D’abord je conçois un outil, puis je l’utilise. Souvent, je parviens à saisir le concept du projet que j’élabore en travaillant sur le fonctionnement de l’outil de façon à le rendre plus souple et facile à explorer au moment de l’utiliser. Je considère que les travaux réalisés grâce à mes outils sont réussis quand l’utilisateur parvient à identifier la synergie (ou au contraire l’opposition) entre la simplicité de l’outil et la complexité des données à traiter.

Graphiste, Jonathan Puckey est installé à Amsterdam aux Pays-Bas. Son travail est un mélange de programmation et d’intuition. Il est notamment attentif au processus de création et aux différentes étapes de conception de ses projets, des outils à la réalisation finale. http://www.jonathanpuckey.com

Sosolimited

La programmation a beaucoup de points communs avec la cuisine. Quand on apprend à la faire soi-même, on prend un grand plaisir à associer les ingrédients de son choix et à goûter le résultat. Peu à peu, cela devient une habitude et il n’est plus du tout nécessaire d’acheter des produits tout prêts pour se nourrir. Autre point commun entre la cuisine et la programmation : les deux sont de puissants instruments de séduction.
Le MIT (Massachusetts Institute of Technology) a joué un rôle capital en nous faisant découvrir cette façon de penser. Quand on a un pneu crevé, pourquoi en acheter un nouveau si l’on peut réinventer la roue ? Délibérément, on ne nous a pas appris à utiliser des programmes tout prêts. Quand j’y repense, on ne nous a pas appris non plus à utiliser des ordinateurs. L’idée était plutôt la suivante : construisez ce qu’il faut pour arriver au résultat que vous voulez, mais pour cela, utilisez la technologie. C’est pourquoi nous avons désormais naturellement tendance à écrire nos propres logiciels.
Ainsi le design n’est-il jamais gravé dans le marbre. C’est une improvisation permanente. Nous ne savons jamais exactement de quelle manière vont se répercuter nos changements, mais une grande confiance dans le processus et l’envie de jouer génèrent souvent des résultats aussi inattendus qu’agréables. C’est un peu comme donner un feutre à un enfant, écrire une liste de ce qu’il peut et ne peut pas faire, et laisser libre cours à sa créativité dans son salon.
Les qualités visuelles de notre travail reflètent les structures, les itérations, les récursions et les limites du code tournant sur un ordinateur. Pour créer un visuel de type organique, il est préférable de chercher activement à masquer l’origine numérique du projet. En revanche, pour essayer de révéler des structures dans un flux d’information, il est intéressant d’adopter et d’amplifier ces mêmes qualités liées au code. Peu importe, finalement : l’oeuvre achevée est telle qu’elle est car il s’agit d’une extension directe des machines pensantes qui l’ont créée.

Sosolimited Studio créé en 2003 par Justin Manor, John Rothenberg et Eric Gunther, qui se sont rencontrés durant leurs études au MIT. Ils interviennent dans les domaines des nouvelles technologies, de l’art du design. http://www.sosolimited.com

Trafik

Création d’un environnement visuel basé sur la programmation qui réagit en temps réel au son diffusé lors des performances du musicien Mondkopf (2011).
Le graphisme et la programmation sont au coeur de beaucoup de nos projets et cette association est la base fondatrice de Trafik (depuis 1997). Depuis le début, nous avons estimé que la programmation pouvait être utilisée à des fins créatives, même si les langages de programmation ont été imaginés essentiellement pour fabriquer des outils. Lorsque nous écrivons un programme, nous sommes confrontés à des interrogations d’ordre technique auxquelles nous devons répondre : résoudre le code pour assurer le fonctionnement du programme. Mais en étudiant les résultats esthétiques générés, en opérant nos propres choix visuels, nous nous inscrivons dans une démarche artistique.
Appliquer la programmation au design graphique est une approche particulière par sa nature. En pratique, le code, utilisé comme matériel de base, est abstrait et délié des formes engendrées. Écrire du code, le compiler, le voir se générer en formes tangibles, tout cela contribue à créer un rapport sensible avec la programmation. Celle-ci, utilisée ensuite dans le design graphique, nous permet d’élaborer des objets plastiques dépassant les outils existants.
Toutefois, se contraindre à produire ses propres instruments est une méthode empirique capable d’obtenir des résultats justes, précis et adaptés mais provoquant aussi, parfois, des résultats inattendus. Ainsi, le code, par la complexité et la diversité qu’il peut générer, arrive à nous surprendre et à dépasser ce que nous avions imaginé au préalable. Par exemple, le code crée souvent une esthétique singulière qui dégage une sorte de radicalité visuelle dénuée de toute sophistication.
En utilisant la programmation, le processus de création nous semble plus complet : lorsqu’il s’agit de produire des visuels, des installations ou des animations, nous travaillons avant tout sur le fonctionnement, la « vie » de ceux-ci. Le projet se construit alors au fur et à mesure du développement, par un échange permanent entre les propositions du graphiste et celles du programmeur. Ces deux métiers nourrissent par leurs interactions l’ensemble de notre création pour aboutir à des objets plastiques spécifiques et maîtrisés.

Bureau de développement graphique et multimédia, pluridisciplinaire et interactif, Trafik créé en 2000 est dirigé par Joël & Pierre Rodière et Julien Sappa. Ils conçoivent des installations interactives et développent de nouveaux concepts pour divers commanditaires. http://www.lavitrinedetrafik.fr