Bilan de la maquette EVE :

Cette maquette réalisée, ses principes ont pu en être présentés concrètement aux acteurs du métier, afin de recueillir leurs point de vue sur ce développement particulier, et plus généralement sur la pertinence d’une telle démarche. Il faut toutefois signaler que le développement s’étant fait principalement sur un temps libre estival de certains membres du groupe de travail, et donc majoritairement sur une économie générée en marge de l’intermittence du spectacle, il eût été illusoire de compter sur un résultat pleinement opérationnel.

Les évaluations critiques de cette maquette, par des utilisateurs ou artistes-programmeurs l’ayant essayée ou ayant assisté à une séance de présentation, ainsi que celles de l’équipe l’ayant développée, ont été recueillies à diverses occasions :
La principale critique émise à propos de la maquette, à savoir sa fragilité et la difficulté de sa mise en œuvre, interdisant sa mise en œuvre en situation réelle « de plateau » (laquelle constituerait pourtant une étape nécessaire de test), tient avant tout aux conditions dans lesquelles elle a été produite.
Pour les mêmes raisons, l’ergonomie a été perçue comme restant à un stade de développement, très éloigné des principes d’interface (création/conduite) énoncés dans l’étude préalable.

Malgré ces points négatifs, ce prototype a cependant permis d’éprouver certains des principes directeurs mis en œuvre lors de son développement :
En premier lieu, l’utilisation du protocole Jamoma a notamment été discutée et parfois critiquée par l’équipe de développement, notamment pour sa lourdeur d’utilisation. Il faut toutefois signaler qu’au moment du développement de la maquette, Jamoma n’en était qu’à un stade embryonnaire et a été nettement optimisé depuis.
L’utilisation de Jamoma lors du développement de la maquette a également permis de sensibiliser les développeurs à l’importance et à la complexité d’un protocole d’échange et de communication. La question a été posée de savoir s’il ne serait pas plus simple et plus efficace de recréer un protocole moins lourd, ex-nihilo. Cette question reste ouverte, dans la mesure où la mise au point d’un nouveau protocole aurait toutes les chances de se voir confrontée aux mêmes besoins de généralisation croissante, et en conséquence d’alourdissement incessant, qui est le verrou principal de toute démarche visant la généricité.

Une nouvelle tentative de développement de EVE demanderait alors de faire un nouvel examen de Jamoma pour interroger la pertinence de son utilisation renouvelée.
Cet examen a partiellement été accompli par certains membres du groupe de travail, plusieurs développeurs ou « artistes-programmeurs » intéressés par cette démarche ainsi que toute l’équipe de développement de Jamoma, lors d’un atelier de développement autour de Jamoma ayant eu lieu au mois de mars 2007 (financé par deux structures participant au groupe de travail : Incidents Mémorables et le GMEA).
Un réel progrès a pu être mesuré en l’espace d’un an, mais le protocole Jamoma ne semblait alors pas encore suffisamment au point pour être employé de façon fiable dans l’immédiat. Cet atelier a cependant permis de procéder à un « alpha-testing » de la nouvelle version (fraîchement finalisée) de Jamoma, et d’en détecter et corriger la majeure partie des « bugs ».
À l’issue de l’atelier, l’ensemble des participants a toutefois salué les principes et le sérieux du développement et considérait globalement ce projet comme très prometteur. Nous continuerons donc de suivre son évolution, au cas où les conditions seraient réunies pour lancer une deuxième phase de développement de EVE.

Concernant la maquette EVE, la question du public potentiel d’un tel dispositif a été également posée :
Les tests d’utilisabilité ont notamment révélé d’une part la nécessité d’un travail conséquent d’ergonomie pour qu’un tel dispositif puisse être adopté par un public significatif, non-spécialiste et pourtant confronté à l’utilisation de processus spécifiques. D’autre part, ils ont posé la question d’une « quatrième catégorie » d’utilisateurs (en prenant pour référence la répartition des niveaux d’utilisateurs exposée ci-dessus), ne nécessitant pas l’apprentissage de la configuration du dispositif (qui reste, en l’état, relativement complexe et peu ergonomique), mais seulement de son utilisation : la tâche de la mise au point de configurations spécifiques pour chaque projet artistique restant alors confiée à un développeur, ou du moins à un utilisateur plus confirmé.
En outre, un certain nombre d’artistes-programmeurs spécialistes de Max/MSP, à qui la maquette a été présentée, ont considéré ce prototype comme trop fermé pour leurs besoins, préférant s’en tenir aux spécificités de leurs propres outils et défendant « le minimalisme de la page blanche comme principal outil de programmation ».
Ce public représentait cependant un champ d’utilisateurs à la limite de l’objet de notre étude, dans la mesure où celle-ci concernait finalement davantage les questions de transmission et d’appropriation - en condition de production - de dispositifs complexes mis au point par des tiers, que l’utilisation de ces dispositifs par leurs créateurs, en soi beaucoup moins problématique.
En définitive, la question de la transmission de la pensée créative et des moyens de la réaliser d’un créateur (en l’occurrence créateur de dispositifs génératifs, sous forme de patches Max/MSP) vers un interprète est ici un premier point central que cette étude a adressé à travers de questionnements techniques principalement. Cette question est, par exemple, réglée dans le cas de l’interprétation musicale « traditionnelle » par le moyen de la partition et de la culture d’interprétation transmise par les conservatoires.
En revanche, il est évident que ce domaine de création, relevant des « mutations numériques » dans le spectacle vivant, est en pleine émergence, et ne peut certainement encore trouver de réponse à cette question. Si réponses il doit y avoir, elles émergeront par la pratique et par les choix politiques, technologiques et culturels qui se dessineront dans les années à venir.


Le développement et l’examen de la maquette a permis également de valider certains choix présidant au développement :
- Tout d’abord la logique modulaire a été validée comme justification principale d’un tel dispositif face aux logiciels « commerciaux » fermés : l’ajout de fonctions spécifiques – indispensable pour les projets incluant une part importante d’expérimentation – restant alors possible, tout en gardant l’avantage d’une infrastructure générique pour la réactivité en situation de création « de plateau ».
- L’aspect collaboratif du développement et l’esprit de mutualisation ont également été appréciés par les membres de l’équipe de développement (même si le constat a été fait que ce travail collectif était mené par un noyau dur moteur des choix et de l’organisation sous-tendant le travail de développement). En effet, un tel processus de développement collaboratif est relativement rare dans une culture de travail plutôt « individualiste » puisque issue des domaines de la composition musicale et des arts numériques, arts majoritairement pratiqués de façon solitaire par leurs créateurs.

Ce dernier point – la complexité d’un développement collectif dans des domaines où les frontières entre artistique et technique restent floues – est certainement un second nœud de la problématique adressée par cette étude, avec la confrontation entre deux cultures de travail : une culture de travail solitaire de « l’artiste numérique », et celle , éminemment collective, du spectacle vivant.
De même, la question de la création expérimentale, hautement spécifique, et de son insertion dans un contexte générique reste entière, même si l’expérience de ce développement et de sa mise à l’épreuve de l’usage a permis d’ouvrir quelques pistes et de poser plus précisément les questions.
En effet, il est évident que la pensée artistique –et en particulier dans le cadre des « arts numériques » - interagit en permanence avec le développement de ses outils et/ou l'intégration d'outils prévus à d'autres fins. Cependant, l’insertion de la création numérique « expérimentale », fonctionnant selon ce paradigme, dans un cadre aussi contraint que celui de la production de spectacle vivant – pour lequel l’urgence est bien souvent la règle, et dont le temps de travail est fortement limité par toute une organisation du travail relativement lourde – révèle avec force le besoin de travailler à une amélioration des conditions.