Programmation visuelle — État des lieux

Engagés dans la création artistique œuvrant avec les technologies numériques et attentifs aux outils de création par la programmation mis en œuvre par le designer graphique, nous avons choisi de mener une recherche sur les langages de programmation visuelle. Parce que les origines de ce domaine de la programmation informatique ne sont pas nécessairement évidentes et claires, il nous semble important de les exposer dans un texte à caractère historique qui tente de situer la position de ce paradigme de programmation dans les pratiques contemporaines de création graphique et visuelle. Un panorama des formes majeures que prend la programmation graphique, le data Flow et l’assemblage de blocs, est proposé afin d’en spécifier les caractéristiques principales et d’en identifier les concepts fondateurs. A la suite de cela, nous essayons de mettre en perspective certains aspects théoriques suscité par la programmation visuelle à travers la problématique qui a motivé notre engagement dans cette recherche.

I — À la croisée des champs 
La programmation informatique à base de texte utilise des successions de chaînes de caractères pour former des mots-clés (tokens, ou éléments-clés), assemblés en des expressions qui permettent de construire des suites d’instructions dont l’objectif est de décrire des processus qui pourront être exécutés par l’ordinateur. Bien que certains langages de programmation tentent de s’approcher autant que possible des langages naturels et plus spécifiquement de l’anglais, comme nous pouvons le constater avec la plupart des langages de script de style « verbeux ¹ », l’écriture d’un programme ne semble pas parvenir pas à être aussi intuitive et souple que l’écriture d’un texte dans l’une des langes que les êtres humains pratiquent quotidiennement entre eux pour tenter de se comprendre mutuellement. Mais peu après son invention, l’ordinateur a rapidement montré une forte capacité de génération et de manipulation d’images, capacité qui donna naissance au domaine spécifique de l’imagerie par ordinateur (Computer Graphics). L’interactivité, notion fondamentale dans une grande majorité des pratiques de l’informatique œuvrant en temps réel, provient d’une spécificité technique de l’ordinateur qui a donné, elle aussi, naissance à un champ scientifique de recherche particulier interrogeant la façon dont un être humain peut entrer dans une relation d’interaction avec un système informatique : la recherche en Interface Homme-Machine (IHM).

La programmation visuelle se situe à la croisée de ces deux champs de recherche attaché aux sciences de l’informatique, car il s’agit de la création de langages de programmation utilisant des éléments graphiques manipulables (et donc interactifs).

La programmation visuelle se distingue fondamentalement de la programmation textuelle par le fait qu’elle utilise plus d’une dimension afin d’apporter une sémantique, c’est à dire pour apporter un certain sens aux éléments utilisés dans la formation d’un programme. En effet, dans la programmation textuelle, une première dimension (sur l’axe des x, pourrions-nous dire) permet d’agencer, en les alignant, différents éléments symboliques (token), comme des mots-clés et des signes de ponctuation, les uns à la suite des autres selon la convention de l’écriture occidentale qui construit des phrases à partir de mots (et eux-mêmes à partir de lettres) dans un certain ordre et séparés par des espaces pour forger un sens. La seconde dimension (sur l’axe y) n’est utilisée que pour faciliter l’écriture et la lecture des codes sources et pour distinguer les lignes entre elles afin de séquencer les instructions, mais ne participe pas véritablement à la réalisation sémantique d’un algorithme.Ainsi, dans la majorité des langages de programmation textuelle, la seconde dimension ne porte aucune charge sémantique, la preuve en est qu’une grande partie de ces langages (dont les standards C, C++, Java, etc.) transforment en une grande et unique ligne de code les programmes au moment de leur compilation.

La multi-dimensionnalité des langages de programmation visuelle est donc la caractéristique qui les distingue le plus nettement de la programmation textuelle ². Mais le fait qu’une telle distinction existe ne signifie pas que l’objectif de la programmation visuelle est d’éviter le texte à tout prix. Comme nous allons le voir, l’écriture de texte conserve une position importante dans ces langages, mais il n’endosse pas le même statut et les mêmes fonctions que dans la programmation en lignes de code.

II — Projets précurseurs 
Deux projets de recherche sont considérés comme étant pionniers dans le champ de la programmation visuelle : Graphical Program Editor et Pygmalion, que nous invoquons ici afin d’introduire les problématiques de la programmation visuelle.

II • 1 — Pygmalion, David C. Smith 
Pygmalion est un langage de programmation visuelle expérimental réalisé en 1975 fondé sur l’usage d’icônes qui permettent de construire des programmes selon la manière dont ils sont agencés dans l’espace d’une zone de l’écran, équivalente à un « tableau noir » selon l’auteur. Dans son texte de commentaires sur la création de ce langage ³, David C. Smith fait état de ses réserves face au système « classique » de programmation par langage textuel, à savoir l’écriture d’une suite d’instructions qui doivent être compilées puis exécutées pour être mises effectivement en œuvre. Cette chaîne imposée par le code informatique, édition – compilation – exécution, implique le plus souvent la découverte d’erreurs à la dernière étape, l’exécution, qui demande alors la recherche et la correction des erreurs (le débogage), activité qui introduit le plus souvent de nouvelles erreurs et relance ainsi le processus édition – compilation – exécution en boucle et rend le travail d’écriture de programme fastidieux et lent. Selon l’auteur, les principaux défauts de cette méthodologie de la programmation textuelle « classique » sont les suivants :
– Le niveau d’abstraction est trop élevé pour laisser place à l’intuition. Pour pouvoir écrire un programme de façon efficace et juste, le programmeur doit construire mentalement un modèle de l’état de la machine lorsqu’elle exécute le code. Très rapidement, la complexité du programme devient trop importante pour permettre cette construction mentale, ce qui favorise toujours plus l’introduction d’erreurs lors de l’écriture.

– Ce système est non-interactif. La boucle édition — compilation — exécution — débogage est une séquence de moments séparés dans le temps qui rend impossible la visualisation des résultats d’une instruction immédiatement après son écriture. Le temps d’attente lors de la compilation et le fait de devoir exécuter le programme en tout ou partie pour découvrir les erreurs et pouvoir commencer à les corriger aboutit à une chaîne de développement faiblement productive. L’interprétation à la volée est une des méthodes permettant d’améliorer cette situation, mais ses performances sont plus faibles que la compilation/exécution.

– La prédominance de la représentation symbolique (ces langages sont des systèmes formels) au détriment de la représentation analogique ou iconique participe à réduire l’intuitivité de la programmation. La description algorithmique d’un triangle à l’aide d’un système formel (mathématique) pourrait être remplacée par l’image du triangle lui-même, sans pour autant lui enlever ses propriétés et ses données (trois points de coordonnées reliés entre eux par des segments dans un espace géométrique normé).

Pygmalion est l’une des premières tentatives de création d’un langage de programmation permettant d’organiser un programme visuellement à l’aide d’icônes. L’auteur précise que la notion d’icône « englobe la notion de variable, de fonction et d’image ⁴ ». L’objectif est de permettre aux programmeurs de concevoir leurs programmes comme étant une séquence d’images ou de dessins s’enchaînant les uns après les autres pour aboutir à un résultat. Après avoir déposé les icônes à l’écran, des valeurs peuvent leur être attribuées et modifiées par manipulation directe (clic sur l’objet graphique et écriture d’une valeur numérique par ex.), l’aspect des icônes représente alors ces changements, de sorte à ce que le programme puisse être modifié « à la volée », sans nécessiter de compilation et d’exécution en dehors de l’environnement d’édition de Pygmalion. Ces principes font que Pygmalion est aussi considéré comme l’un des premiers langages de « programmation par démonstration », un type de langage dans lequel le programmeur « démontre » des états ou des fonctions à l’environnement d’édition-exécution par la construction de diagrammes (ou d’autres formes d’agencements d’icônes). Notons ici que la réunion de l’environnement d’édition (authoring) et de celui d’exécution – et donc de consultation – ne sont plus séparés, ce qui rend le débogage plus intuitif et immédiat. La quasi totalité des langages de programmation visuelle effectue cette réunion.

II • 2 — Graphical Program Editor, William Sutherland 
Graphical Program Editor est un langage visuel créé par William Sutherland entre 1965 et 1966. Il fait suite au célèbre projet d’Ivan Sutherland (son frère) de 1962 Sketchpad, considéré comme étant la première application graphique de l’histoire de l’informatique. En utilisant un stylet « lumineux » (lightpen – un stylet qui permet de faire s’afficher un curseur à l’écran lorsqu’il en est assez proche) à l’aide duquel l’utilisateur peut tracer des formes géométriques directement à l’écran (vectoriel à l’époque). Sketchpad intégrait un grand nombre de fonctionnalités qui sont devenues des standards par la suite dans les logiciels de dessin assisté par ordinateur, à commencer par la notion de scène qui fait de l’écran une fenêtre ouverte sur un espace « inscriptible », l’auto-aimantation du pointeur sur les points et les segments les plus proches, des outils d’assistance dans le tracé des courbes (arcs et cercles), la possibilité de créer des formes réutilisables et dont les modifications sont automatiquement répercutées sur l’ensemble de ces instances et même la possibilité de visualiser des objets en trois dimensions depuis quatre angles simultanément (face, dessus, côté et perspective). Ce système était révolutionnaire pour l’époque et fonctionnait sur le Lincoln TX-2, ordinateur historique prenant l’espace de plusieurs armoires. C’est sur ces bases que le Graphical Program Editor a été conçu et réalisé. Le système de dessin et de gestion des formes y est exactement similaire à Sketchpad, mais ici il est utilisé pour dessiner des formes qui représentent des fonctions de programmation. Une banque de formes peut ainsi être préparée et l’assemblage d’un certain nombre de leurs instances, à l’aide de segments les reliant, forme un diagramme représentant le programme. Ce diagramme peut ensuite être exécuté par la machine de sorte à fournir un résultat. La notion de flux de données (dataflow) apparaît ici car, dans un environnement de programmation utilisant deux dimensions, il faut orienter explicitement les informations entre les différents éléments du programme (qui sont, comme en programmation textuelle, des tokens), car chacun peut être relié à plusieurs autres de ses voisins. Des points d’entrée et de sortie sont donc définis pour chaque token et la direction que les données doivent prendre est inscrite sur les segments qui lient une forme à l’autre.

Les programmes du Graphical Program Editor de William Sutherland prennent l’aspect de diagrammes qui ne sont pas sans rappeler la représentation schématique et technique des circuits électriques et électroniques. L’idée de « câbler », voire de « tisser » des modules opératoires et fonctionnels (des briques de programmes) entre eux afin de contrôler un flux de données sera très largement reprise par des logiciels de création de programmes postérieurs dont nous allons faire l’analyse.

III — Panorama des paradigmes de programmation visuelle 
III • 1 — Diagrammes opératoires 
L’un des paradigmes les plus utilisés par les langages de programmation visuelle est celui du flux de données (dataflow). Il s’agit, d’une façon générale, d’une programmation qui utilise des éléments graphiques qui peuvent être disposés librement dans la surface d’une fenêtre et reliés les uns aux autres à l’aide de segments, symbolisant des tuyaux dans lesquels les données transitent de module en module pour être traitées. Une certaine syntaxe de formes doit être créée pour ce type de langages, en fonction du degré d’abstraction graphique dont il fait preuve. Par exemple, il est habituellement nécessaire en programmation impérative de distinguer les variables des fonctions ⁵. Pour rappel, une variable est un espace mémoire réservé au stockage d’un certain type de données dont la valeur peut être modifiée comme consultée à tout moment par le programme au cours de son exécution. Une fonction est un bloc d’instructions dont la mission est de réaliser un certain nombre d’opérations sur des données (généralement représentées par des variables) et de retourner, ou non, un résultat. Les fonctions permettent de généraliser certaines suites d’opérations qui sont régulièrement utilisées par un programme et en facilitent l’appel et le réemploi. Parce que la programmation visuelle reste de la programmation, elle doit nécessairement s’adapter à ce qu’est fondamentalement l’ordinateur, à un niveau ou à un autre. C’est pourquoi les différents modules graphiques utilisés dans les langages de type dataflow présentent des variations : si une variable est représentée par un petit rectangle aux contours fins contenant une valeur numérique exprimée textuellement, une fonction pourra être représentée par un rectangle aux contours épais ou doublés contenant le nom de la fonction (« setPixel » par exemple), ou bien par un rectangle dont l’un des côtés présente un renfoncement en forme de triangle ou une autre variation graphique.

Le vocabulaire graphique de ces langages peut donc être plus ou moins riche et plus ou moins proche des langages plus traditionnels en lignes de code. Entrer avec précision dans les syntaxes de tous les langages que nous souhaitons évoquer ici nous ferait sortir du cadre généraliste que nous souhaitons donner à l’historique que nous tentons de dresser ici. Il s’agit ici de cerner les grandes caractéristiques des langage de programmation visuelle les plus représentatifs du type dataflow.

a. Prograph
Initié en 1982 par Tomasz Pietrzykowski, Stan Matwin et Thomas Muldner à l’université de Acadia (Nova Scotia – Canada), et commercialisé en 1988 par la société TGS Systems, Prograph est considéré comme étant le premier environnement de développement informatique utilisant un langage visuel suffisamment robuste et complet pour être utilisé dans des activités professionnelles et industrielles. Les recherches qui aboutirent sur ce langage visuel trouvent leurs origines dans des constats équivalents à ceux fait par David C. Smith dans son travail précurseur sur Pygmalion que nous avons évoqué plus haut : la programmation textuelle nécessite beaucoup de temps d’apprentissage, ces langages sont trop rigides pour laisser place à l’intuition, leur haut niveau d’abstraction complique leur usage et force à une construction mentale préalable des processus exécutés par l’ordinateur, etc. La représentation des programmes à l’aide de diagrammes ou d’organigrammes est une pratique qui consiste à réaliser des schémas qui aident à la conception des programmes avant l’écriture de code dans un langage. Différents niveaux de profondeur peuvent être visés par ces schématisations : il peut s’agir d’une vue d’ensemble de l’architecture du programme ou d’une de ses parties qui nécessite la mise en place d’algorithmes complexes qu’un diagramme permet de mieux conceptualiser grâce à la visualisation. La difficulté supposée par la construction mentale d’un programme, évoquée par David C. Smith, est donc légèrement réduite par ces organigrammes. Cette pratique est à la source de Prograph. Les auteurs de ce langage ont imaginé la suppression de la phase d’adaptation des organigrammes en codes sources pour les rendre directement exécutables. Un gain de temps dans la réalisation de briques logicielles est donc envisageable grâce à cette méthode de programmation visuelle.

Dans Prograph des icônes de différentes formes représentent des variables, des fonctions ou des objets et la programmation en elle-même consiste en un « câblage » des différentes icônes entre elles de sorte à définir un « flux de données ». Il s’agit, en quelque sorte, de « dessiner du code ». Chaque icône possède des entrées et des sorties, permettant le tissage de différents câbles. A la sortie d’une icône, les données sont transformées puis envoyées à l’icône suivante. Lorsque deux entrées sont disponibles, la réunion des données entrantes peut être faite, de même qu’elles peuvent être séparées lorsque deux sorties sont possibles. L’ensemble du diagramme ainsi produit peut être disposé librement dans l’espace sans que la direction du flux ne soient perdue. Il est également possible d’imposer des temps d’attente à l’intérieur du programme de sorte à synchroniser l’exécution de certaines de ses parties, l’insertion de certaines données devant se faire dans un ordre différent de celui défini par les câbles. En dehors de ces éléments, on trouve dans Prograph un grand nombre d’autres principes d’organisation des icônes qui seront repris dans d’autres langages, comme la possibilité de créer des parcelles de diagrammes et de les envelopper dans un objet graphique plus petit pour éviter ainsi de provoquer l’effet « spaghetti », c’est à dire une surcharge d’éléments qui rendent le programme difficile à lire et à décortiquer (ou à démêler).

Prograph est un environnement de développement intégré complet, qui offre une panoplie d’outils : un éditeur graphique et interactif de code source, un interpréteur, un débogueur graphique et un éditeur visuel d’interface graphique utilisateur. L’une des caractéristiques importante de Prograph est que son langage est de type généraliste, c’est à dire qu’il peut être utilisé pour réaliser tout type d’application. Ceci marque une différence importante avec d’autres environnements de développement à langages de programmation graphiques, comme LabVIEW, de National Instrument. Commercialisé en 1986. LabVIEW (acronyme de Laboratory Virtual Instrumentation Engineering Workbench) est un logiciel spécialisé dans la simulation de systèmes électrotechniques à destination des laboratoires de recherche et de l’industrie. Il est utilisé principalement pour l’acquisition de données, le contrôle d’instruments (robotisés par exemple), l’automatisation de chaîne de production, etc. Le langage de programmation de LabVIEW, nommé G, fait partie de la même famille que celui de Prograph, c’est un langage visuel à base d’icônes et fonctionnant selon le principe de dataflow. Mais, à la différence de Prograph, LabVIEW n’est a priori prévu que pour permettre un certain genre de développement, relativement spécialisé. Dans ce logiciel, deux vues différentes sont utilisées. La première permet de disposer des éléments graphiques représentant le plus souvent des appareils utilisés dans les laboratoires de sciences physiques. La seconde permet de fabriquer le programme qui permet à l’ensemble de ces éléments techniques de fonctionner ensemble pour produire la situation expérimentale attendue. Cette approche « biface », offrant en « vue de face » une apparence plus ou moins réaliste d’appareils électroniques et en « vue arrière » un dispositif de programmation de ces appareils se retrouve dans certains logiciels d’édition audio, tels que Reason de Propellerhead.

Aujourd’hui, la dernière entreprise propriétaire en date de Prograph (Pictorius) a cessé ses activités, les bénéfices engendrés par les ventes de licences étant trop faibles. Le logiciel a été repris en 2008 sous le nom de Marten ⁶. Si l’un des objectifs de la programmation visuelle et de faciliter l’accès à la programmation informatique et de permettre aussi à des utilisateurs novices en programmation textuelle de pouvoir réaliser des programmes, Prograph reste un outil orienté vers les professionnels du développement informatique. En effet, la complexité des notions auxquelles il fait appel laisse finalement peu de place aux néophytes et à l’intuition. Cet aspect encore un peu trop « rigide » de Prograph est perceptible dans l’ouvrage de référence sur ce langage qui fait aussi office de manuel d’apprentissage, Visual Programming With Prograph CPX ⁷, dans lequel les diagrammes de Prograph sont régulièrement mis en miroir de code C++. D’une part, ceci permet de supposer que l’apprentissage d’un tel langage visuel s’effectue plus simplement et plus rapidement si l’on a déjà une bonne connaissance de la programmation textuelle, ce qui semble répondre à une certaine logique car, comme nous l’avons déjà remarqué plus haut, la programmation visuelle reste de la programmation et doit donc répondre aux exigences de ce domaine d’une manière ou d’une autre. D’autre part, cela donne un certain crédit aux langages de programmation visuelle de type dataflow, car s’ils sont capables, comme Prograph, de reproduire des programmes écrits dans l’un des langages de programmation textuelle les plus utilisés dans l’informatique (le C++) par des diagrammes exécutables, alors leur mise en œuvre dans les projets complexes est envisageable et permet d’imaginer que de nouvelles générations de langages visuels apparaîtront et seront tout aussi puissantes mais peut-être plus abordables par les néophytes.

b. La programmation par « patches »
Directement héritées des recherches sur la programmation visuelles et le paradigme du flux de données (ou dataflow) dont nous venons d’évoquer les origines, un environnement auteur destiné à la création artistique et musicale a su s’imposer dans les pratiques des arts et technologies numériques : Max/MSP/Jitter (que nous appellerons Max ⁸ dans la suite du texte). Comme dans Prograph, Max est à la fois un langage et un environnement de développement intégré, comportant un éditeur de programmation visuelle, un interpréteur et un débogueur interactif. L’une des différences principales que l’on peut trouver entre Max et Prograph et le degré de « vivacité » de son langage.La notion de « vivacité », traduction du terme anglais liveness, a été introduite par Steven L. Tanimoto en 1990, lors de ses recherches sur les langages de programmation visuelle ⁹. La vivacité correspond au retour qu’un langage de programmation fait au programme en temps réel, ou autrement dit, « à vif ». La terminologie anglaise utilise l’expression « live feedback », qui amène le terme de liveness, une variation du mot liveliness. Quatre niveaux de vivacité ont été déterminés par Steven L. Tanimoto de façon à classifier les langages visuels, que nous résumons ci-dessous :

1. La représentation visuelle est une source d’information employée par le programmeur mais pas par l’ordinateur. Typiquement, il s’agit de l’organigramme utilisé pour représenter visuellement la structure du programme afin d’aider à sa conception. Un langage de programmation textuel « classique » est utilisé pour l’implémentation effective, l’organigramme n’est ni intégré dans une interface d’aide au développement ni rendu interactif ou exécutable, il n’est qu’un accompagnement à l’écriture de lignes de code. Il s’agit d’un niveau strictement informatif.

2. La représentation visuelle consiste en la spécification effective des processus qui doivent être exécutés par l’ordinateur. S’il s’agit d’un organigramme, celui-ci peut d’abord être réalisé à l’aide d’une interface graphique interactive, puis exécuté en tant que programme par la machine. A partir de ce niveau, il est question simultanément des aspects informatifs et signifiants.

3. Dans une représentation visuelle du programme, toute action de l’utilisateur a pour conséquence de déclencher la mise à jour de l’aspect du programme par rapport à l’état actuel du traitement des données. Par exemple, le fait de cliquer sur une des cellules d’un tableau dans une feuille de calcul provoque la mise à jour de l’ensemble des valeurs du tableau, et donc le calcul de l’ensemble des opérations. Une fois la mise à jour de l’affichage effectuée, le programme peut continuer à s’exécuter mais sans retour visuel immédiat, une nouvelle action de l’utilisateur étant nécessaire pour que ce « rafraîchissement » ait lieu. Ce niveau est donc informatif, signifiant et « sensible » (ou ponctuellement interactif).

4. Tout en accumulant les trois premiers niveaux de vivacité, la représentation visuelle du programme est en constante activité : l’ensemble des processus exécutés provoque la mise à jour de l’affichage des parcelles du programme de sorte à ce que la représentation reflète l’état courant du programme en temps réel (ou en live). Aussi, l’édition du programme peut être faite « à la volée », sans interrompre son exécution, comme ce serait le cas dans la chaîne traditionnelle de développement déjà critiquée par David C. Smith, à savoir la boucle édition – compilation exécution.

Max est un environnement de programmation dont l’origine se trouve dans le champ de la composition musicale assistée par ordinateur. Initialement, il s’agit d’un logiciel réalisé en 1986 par Miller Puckette à l’IRCAM ¹¹ dont l’objectif était de simplifier le contrôle de l’ordinateur 4X, un assemblage de divers terminaux dédié à la génération et au traitement du signal sonore en temps réel. Il s’agissait essentiellement de permettre la création d’applications pour cet ordinateur complexe à l’aide d’un langage unifiant l’appel à des processus programmés en temps réel ainsi qu’à des contrôleurs d’appareils MIDI. Pensé pour être modulaire, Max se présentait alors comme une suite de fonctions textuelles qui pouvaient se transmettre des messages et donc être assemblées les unes aux autres afin de constituer une suite de lignes d’instructions à faire exécuter par le 4X. L’usage d’un tel langage permettait un gain de temps important compte tenu de la complexité de cet ordinateur ¹². Par la suite, Miller Puckette généralisa certains principes de Max afin de le faire évoluer pour devenir un logiciel de création musicale autonome spécialisé dans le traitement du signal et des données en temps réel. Une version fonctionnant sur Macintosh est réalisée et l’élément fondamental de Max devient alors la fenêtre, à l’intérieur de laquelle peuvent être écrites des lignes de commandes, des tableaux ou des Patchers. Nous trouvons les plus anciennes traces écrites du terme Patcher dans une publication de Miller Puckette portant ce même nom, The Patcher ¹³, dans laquelle nous pouvons trouver la description suivante :

« Le Patcher propose la visualisation d’un objet dans MAX sous la forme d’une boîte située dans une fenêtre, montrant certains états de l’objet. Chaque boîte dans la fenêtre du Patcher possède un certain nombre d’entrées et de sorties représentées graphiquement. La connexion entre deux objets est représentée par un segment allant de la sortie d’un objet vers une des entrées d’un autre objet. Une nouvelle connexion peut être créée en sélectionnant n’importe quelle sortie de n’importe quel objet et en faisant un “ glisser-déposer ” vers une des entrées d’un autre objet ; un segment apparaît alors entre eux. Une sortie peut être reliée à plusieurs entrées et vice-versa. Les sorties sont toujours situées sur le côté inférieur des boîtes, les entrées étant sur le dessus. Un objet est généralement considéré comme possédant sa propre première entrée, à travers laquelle vous pouvez diriger n’importe quel type de message à l’objet associé ; les autres entrées sont utilisées pour des fonctions spécifiques, de sorte à ce que des messages standards puissent être utilisés pour provoquer différentes actions sur le même objet ¹⁴».Ainsi, dans son article, Miller Puckette explique le principe de ce « nouveau » langage de programmation qui n’est autre qu’une application du paradigme de dataflow des langages de programmation visuelle : il s’agit de réaliser un diagramme de programme dans une fenêtre à l’aide d’un certain nombre de « boites » qui, reliées entre elles par des segments, permettent d’effectuer différents traitements des données et du signal. Compte tenu de cette définition du Patcher, terme provenant du verbe anglais to patch (rapiécer) et faisant écho à l’aspect visuel des programmes faits de boites « tissées » entre elles, il est surprenant de constater qu’aucune mention de Prograph n’est faite par Miller Puckette. A l’inverse, on peut s’étonner également qu’aucune mention ne soit faite de Max dans les publications issues de la recherche sur les langages de programmation visuelle ¹⁵.

Max possède pourtant une vivacité de quatrième niveau selon la graduation proposée par Steven L. Tanimoto en 1989, une année après la sortie de Max sur Macintosh, là ou Prograph n’atteint que le second niveau. En effet, les objets graphiques de Max voient leur apparence mise à jour de façon automatique, même lorsque le programmeur n’agit pas sur l’un des éléments du diagramme. Le niveau de feedback et d’interactivité du langage est donc à son maximum dès les premières versions du logiciel, en 1988. L’obligation du traitement temps réel qu’impose le contexte de la performance musicale en « live » a certainement favorisé cet aspect important de Max.

D’abord dédié exclusivement au traitement de flux de données dans l’objectif de contrôler des appareils MIDI, Max se verra adjoindre MSP en 1997, un module spécialisé dans le traitement du signal audio, puis Jitter en 2003, un autre module spécialisé dans le traitement des matrices en temps réel apportant de puissantes fonctionnalités orientées vers le traitement vidéo temps réel. Max permet l’ajout d’objets réalisés par les utilisateurs. Nommés externals, ces objets d’extension des capacités du logiciel et de son langage. Les externals doivent être écrits dans un langage de programmation textuel, ici encore le C et C++, nous voyons donc que la programmation textuelle conserve une certaine place dans cet environnement auteur, bien qu’il soit a priori réservé à des spécialistes. A l’instar de Prograph, Max est un environnement de développement intégré complet, incluant un interpréteur et un débogueur qui permet d’observer l’exécution du programme étape par étape. Tout ceci fait de Max un langage de programmation dit général, c’est à dire qu’il permet de créer tous types de programmes. Une autre particularité fondamentale de Max est le fait qu’il soit dès son origine un environnement auteur à destination d’artistes praticiens et, en l’occurrence, de musiciens. Il en va de même pour vvvv et Quartz Composer, qui sont tous deux des logiciels très utilisés par les artistes de la scène musicale et plus spécifiquement les Visual Jockey (VJ – l’équivalent dans le champ des arts visuels des Disc Jockey ou DJ).

Max est l’un des principaux représentant d’une catégorie d’environnements auteur qui compte un certain nombre de logiciels, dont les plus célèbres sont PureData (Pd), sur lequel nous reviendrons car il s’agit d’un projet initié par Miller Puckette et faisant suite à son travail sur Max, vvvv ¹⁶, orienté vers le traitement et la génération vidéo en temps réel et réservée à la plateforme Windows, et Quartz Composer ¹⁷, logiciel auteur intégré dans la suite des outils pour développeurs d’Apple réservé à Mac OS X et également spécialisé dans la création vidéo, dont la version préliminaire a été conçue et réalisée en 2002 par Pierre-Olivier Latour sous le nom de PixelShox ¹⁸. L’ensemble de ces logiciels de création utilisent le paradigme de programmation visuelle dataflow. L’interface principale y est une fenêtre représentant un canevas vide sur lequel sont déposées des boites pouvant représenter des données ou des fonctionnalités et possédant des entrées et des sorties qui doivent être reliées entre elles pour faire programme. Les programmes réalisés avec ces langages sont également appelés des patchs en conséquence de l’aspect « tissé » et « câblé » de ces organigrammes exécutables. Parce que l’apparence visuelle des valeurs résultantes de l’exécution du programme a lieu en continu et en temps réel, tous ces langages de programmation visuelle disposent d’une vivacité de quatrième niveau.

Aussi, nous pouvons remarquer qu’il n’y a pas de séparation entre un mode « création » et un mode « consultation » dans ces logiciels. Les patchs peuvent être manipulés alors même qu’ils sont en cours d’exécution, ce qui rapproche ces langages des systèmes à interprétation comme les scripts. Cette spécificité participe à une certaine facilité d’usage de ces environnements logiciels auteur et favorise aussi leur succès auprès d’une certaine catégorie de créateurs et d’artistes qui mettent l’accent sur l’usage de technologies numériques en temps réel.

III • 2 — L’assemblage de blocs 
Nous avons observé différents environnements logiciels auteur mettant en œuvre des langages de programmation visuelle fondés sur le paradigme dataflow, dans lequel des boites représentant graphiquement des éléments de programme sont reliées les unes aux autres par des segments qui tissent un câblage au travers duquel les données transitent. Un autre paradigme a réussi a trouver une place dans les logiciels de création d’applications interactives, y compris artistiques, il s’agit de celui des pièces de puzzle. La juxtaposition de pièces représentant des parcelles de programme est donc ici préférée à leur liaison par des segments. On trouve les origines de ce paradigme dans le langage visuel BLOX de Ephraim P. Glinert, initié à l’occasion d’une recherche sur la programmation visuelle en 1986 ¹⁹. Dans ce langage expérimental et précurseur, des fonctions et des instructions prédéterminées sont représentées par des pièces de puzzle dans lesquelles sont inscrits textuellement le nom d’une fonction. L’idée de flux de données est aussi présente dans ce type de mise en forme graphique des programmes, car les instructions sont exécutées dans un certain ordre, de la même façon que dans les langages textuels ou dans les langages de type diagramme à dataflow. Selon la fonction écrite dans la pièce, celle-ci prendra une certaine forme qui impose certains montages et en interdit d’autres. En effet, la métaphore de la pièce de puzzle est ici utilisée de façon à guider le programmeur dans son travail de construction du programme : les protubérances des pièces ne permettent leur assemblage qu’avec certaines autres dont les cavités sont adaptées. Ainsi, certaines erreurs « d’écriture » ne sont pas possibles, certaines constructions n’étant pas « légales » selon les règles imposées par les différentes formes des pièces.

Ce paradigme introduit par BLOX se retrouve dans plusieurs logiciels de création émanant des recherches sur les langages de programmation à but éducatif des laboratoires du MIT. On trouve ainsi une forme d’évolution du principe de programmation inauguré par BLOX dans un grand nombre de projets du Lifelong Kindergarten, l’un des groupes de recherche du MediaLab du MIT.

a. Logo en blocs
L’une des premières apparitions de ce type de programmation visuelle est LogoBlock, un environnement de programmation visuelle qui tente de simplifier la création de programmes permettant le contrôle des jouets LEGO, dans leur version technique et robotisée. Comme son nom l’indique, LogoBlock est dérivé du langage Logo, initié par Seymour Papert et les autres membres du laboratoire de recherche sur l’intelligence artificielle qu’il fonda aux côté de Marvin Minsky au MIT dans les années 1960.

Logo est un langage de programmation textuelle dont l’ambition est de permettre une forme d’auto-apprentissage de la logique procédurale qui régit le fonctionnement de l’ordinateur. Fondée en grande partie sur les travaux de Jean Piaget (avec qui Seymour Papert a travaillé), selon lesquels la connaissance évolue et se développe à travers une relation de l’individu à son environnement, l’idée de Logo est d’être un outil favorisant le développement de la capacité de résolution des problèmes chez les enfants et, par extension, de leur capacité à acquérir des connaissances. Ce langage de programmation permet la construction de séquences d’ordres (ou d’instructions) à l’aide de mots clés faciles à comprendre et dont le sens est proche de celui du langage courant. Ces programmes visent à contrôler les déplacements dans l’espace d’un objet susceptible de laisser des traces, il s’agit donc, essentiellement, de faire tracer des traits sur une surface d’inscription à l’aide de séquences d’instructions simples. L’objet traçant est devenu rapidement caractéristique de Logo : la célèbre tortue. En effet, les premières expérimentations de Seymour Papert, vers le début des années 1970, impliquaient un petit robot directement inspiré des « tortues » robotisées des années 1950 du neurophysiologiste William Grey Walter. Ces petits robots à roulettes, protégés par une coque de plastique transparent semi-sphérique, pouvaient simultanément se déplacer dans une direction, changer d’orientation en tournant sur eux-mêmes et baisser ou lever un marqueur ou un stylo installé à l’intérieur de la machine. Le langage de programmation permettait de contrôler ce robot de sorte à ce qu’il trace au sol des formes géométriques. Ce robot s’est rapidement vu adapté à l’écran sous la forme d’un triangle orienté dans la direction vers laquelle il va se déplacer, ou encore sous la forme d’un dessin de tortue, selon les très nombreuses implémentations du langage ²⁰. Le langage Logo est orienté objet et dérivé du langage Lisp, dont il est une version plus lisible et quelque peu simplifiée.

Logo est donc très clairement positionné dans le champ de la pédagogie et peut être vu comme étant un outil d’apprentissage destiné à des personnes ignorant la programmation informatique par le truchement d’une mise en pratique effective de celle-ci en offrant des résultats visuels presque immédiats (dans le cas où la tortue de dessin est utilisée du moins). Il est aujourd’hui fait référence à cette forme de pédagogie sous le terme de constructionisme, dérivé de la méthode dite constructiviste de Jean Piaget. Le projet et la philosophie initiés avec Logo ont entraîné l’apparition de plusieurs « héritiers » dont LogoBlocks, datant de 1996, fait partie. LogoBlocks est une adaptation de LEGO/Logo ²¹, lui-même une des évolutions du langage Logo qui était destinée au contrôle de moteurs et de capteurs faisant partie de la panoplie des LEGO. Afin de rendre la programmation des robots LEGO toujours plus abordable, le style textuel de Logo a fait place à une version visuelle du langage, fondée sur le principe d’assemblage de pièces de puzzle ou de blocs. Il s’agit ici de rendre la programmation accessible à des enfants et à de jeunes adolescents ²². Des blocs de différentes formes sont utilisés pour représenter différentes catégories de fonctionnalité : actions, variables, capteurs et procédures. Chaque bloc possède une forme particulière pensée de façon à pouvoir s’assembler à certaines autres pièces. Des couleurs permettent d’identifier rapidement la catégorie à laquelle appartient chaque blocs. Un système d’aimantation est activé lorsque les blocs sont proches les uns des autres, ce qui permet au programmeur de les déposer de façon approximative là où il souhaite et de laisser au système le soin d’assembler visuellement les blocs avec précision. On peut voir dans ce système d’assemblage de blocs colorés une forte influence des LEGO « classiques », eux aussi composés de blocs colorés qui peuvent ou non être assemblés entre eux selon leur disposition (il n’y a cependant pas d’affirmation concernant cette influence du jeu de construction dans les publications traitant de LogoBlocks).

L’une des spécificités de ce langage visuel fait de blocs est d’être une adaptation stricte de sa version textuelle : une fenêtre permet d’afficher l’équivalent en lignes de code Logo d’un programme fait en LogoBlocks. Il y a donc une équivalence exacte entre les éléments structurant du langage Logo (structures de contrôles, opérateurs, etc.) et leur version « bloc », puisque l’une des sources peut être transformée en l’autre et, a priori, vice-versa.

b. Scratch : la programmation pour les enfants
Toujours au Lifelong Kindergarten du MIT MediaLab, l’environnement de programmation Scratch est en développement depuis 2003. Scratch a pour objectif « d’introduire la programmation à ceux qui n’en ont aucune expérience préalable ²³ ». S’il n’est pas fondé directement sur Logo (mais sur Squeak ²⁴), il s’inspire très largement de sa philosophie tout en proposant un langage alternatif. En effet, le langage de Scratch s’inscrit dans la suite des recherches initiées avec le projet LogoBlock, il s’agit donc d’un langage de programmation visuelle utilisant la métaphore des blocs (ou pièces de puzzle) que l’on assemble pour construire un programme. La référence au jeu de montage LEGO est cette fois clairement énoncée : « Lorsque l’on joue avec des briques de LEGO, on ne rencontre pas de message d’erreur. Les différentes parties ne s’assemblent entre elles que d’une certaine manière, et il est donc plus simple de faire les choses bien plutôt que mal ²⁵ ».

L’une des spécificités de Scratch est de permettre aisément l’usage de divers médias : images, sons et vidéos. Le programmeur peut donc intégrer ses propres médias sans difficulté de sorte à pouvoir les mettre en œuvre rapidement dans son programme. Ceci fait de Scratch un environnement de création propice à l’apprentissage des fondements de la programmation, car un résultat visuel et/ou sonore est immédiatement observable. Un autre aspect de Scratch et son degré de « vivacité », qui pourrait être considéré comme étant de quatrième niveau, car le programme peut être modifié par l’utilisateur alors qu’il est en cours d’exécution et l’apparence des sketchs (c’est ainsi que sont nommés les programmes faits de blocs) est adaptée en temps réel. Cette possibilité de modification à la volée du programme est référencée sous le terme anglais tinkerability ²⁶, dont un équivalent construit avec des termes français pourrait être la remaniabilité.

La grammaire de formes de Scratch est inspirée de LogoBlock et le même principe d’aimantation des formes proches facilite leur assemblage. On trouve quatre grands types de blocs : les commandes, les fonctions, les déclencheurs et les structures de contrôles. Certains blocs intègrent des champs de texte offrant accès à l’édition de leurs paramètres. Scratch est explicitement orienté vers les enfants et se veut être un outil de pédagogie passant par la création de scènes animées interactives. Le nombre de blocs disponibles est volontairement limité afin de préserver une grande accessibilité à cet outil compte tenu du public auquel il s’adresse. Mais cela peut aussi entraîner des difficultés dans la réalisation de certains programmes. Par exemple, Scratch n’intègre pas le principe de récursivité qui, en informatique, permet à une fonction ou, plus généralement, à un algorithme de faire appel à lui-même. Cette impossibilité peut parfois compliquer la construction d’un programme. Aussi, Scratch ne permet pas la réalisation de procédures, c’est à dire la mise en place de fonctions n’ayant pas de valeur de retour. Afin de palier à ces manques, un projet dérivé de Scratch a été initié pour proposer une version plus orientée « adultes » et intégrant des principes de programmation plus évolués, il s’agit de Build Your Own Blocks, ou BYOB, débuté en 2010 ²⁷. Scratch continue d’évoluer aujourd’hui et sa communauté d’utilisateurs reste constante, le fait que son équipe de développement se soit dotée très tôt d’un site internet à l’aide duquel les utilisateurs peuvent s’échanger des sketchs et échanger à propos de leurs expériences, qu’ils soient enseignants ou élèves, aide au succès de cet environnement auteur.

c. Vers une plus grande portée : OpenBlocks
En 2007, Ricarose Vallarta Roque soutient son mémoire de Master au département d’ingénierie électrique et de science informatique du MIT avec le titre suivant&thinsp: « OpenBlocks&thinsp: framework extensible pour un système de programmation par blocs ²⁸ ». Les recherches restituées dans ce mémoire constituent un nœud important dans l’évolution de la programmation visuelle par assemblage de pièces de puzzle dont nous avons trouvé les premières manifestations dans BLOX de Ephraim P. Glinert en 1986. OpenBlocks a permis le transfert des systèmes de programmation par blocs intégrés dans des environnements auteurs spécialisés dans un certain domaine, tels que LogoBlock et Scratch, vers des systèmes plus généraux non réservés à la réalisation d’un type de programme particulier. Le système d’OpenBlocks est fondé sur une étude très précise du langage de programmation intégré dans StarLogo TNG, dont nous résumons ici les origines et le principe.

StarLogo « The Next Generation » (TNG), est une évolution de l’environnement de programmation textuelle StarLogo (lui-même dérivé de Logo) dont l’ambition était de permettre la modélisation de systèmes décentralisés afin d’étudier les types d’interactions qui apparaissent entre de nombreux agents. Il peut donc autant s’agir de la conception et de l’étude d’une foule se déplaçant dans un espace que de l’analyse de la formation de motifs visuels lors de l’évolution d’un banc de poissons. StarLogo TNG a pour objectif de rendre accessible au plus grand nombre cet outil de modélisation graphique des comportements complexes. Pour ce faire, l’extension du langage textuel Logo réalisée dans StarLogo est remplacée par un langage visuel du type blocs et l’environnement graphique est transposé en 3D temps réel. Aussi, la possibilité de réaliser des prototypes de jeux vidéo a été intégré afin de rendre l’apprentissage de l’outil plus motivant encore. La grammaire de formes du langage de StarLogo TNG est similaire à celle de Scratch tout en étant un peu plus vaste et adaptée aux exigences de StarLogo. L’analyse en profondeur des différents aspects du langage et de l’environnement de programmation de StarLogo TNG amène Ricarose V. Roque à constater que, malgré la certaine facilité d’accès à la programmation informatique que permet cet outil, sa portée ²⁹ reste strictement limitée à une rigoureuse adaptation de StarLogo et centrée sur un usage spécifique au contexte de StarLogo TNG. Le projet OpenBlocks a pour objectif d’étendre au maximum la portée du langage visuel de StarLogo TNG et d’en faire ainsi un outil de conception de nouveaux langages pouvant s’adapter à tout types de besoins.

Comme nous l’avons observé avec Scratch et LogoBlocks, les blocs représentent visuellement une structure de programme qui peut être interprétée à la volée (Scratch), ou éventuellement « traduite » en langage textuel pour être interprétée à la volée (LogoBlocks), ou encore compilée puis exécutée. Ceci induit qu’un bloc n’est que la représentation d’une instruction dont la véritable mécanique sous-jacente a été définie au préalable, au-delà de la mécanique propre aux blocs et à leurs interactions en tant qu’éléments visuels dans un canevas, sorte de mécanique visuelle. Le plus souvent, un langage textuel « traditionnel » tel que le C++ ou Java est utilisé pour mettre en place les fonctionnalités effectives des blocs. Afin d’étendre la portée de ce langage de programmation, il est donc nécessaire de fournir aux programmeurs les outils nécessaires autant à la redéfinition de la mécanique visuelle que sous-jacente des blocs afin de pouvoir les adapter à différents objectifs et différents contextes. Tel est le projet d’OpenBlocks.Fondamentalement, OpenBlocks permet de redéfinir l’implémentation et la définition des blocs à l’aide d’un unique fichier de description. Grâce à cela, il devient a priori possible d’intégrer OpenBlocks dans une application qui permet l’usage d’un langage de script. L’ensemble des éléments constituant un bloc peuvent donc être décrits précisément&thinsp: type, forme de base, couleur, nombre de connexions en entrée et en sortie, nom, nombre de paramètres modifiables, etc. Il s’agit ensuite de déterminer leur implémentation, c’est à dire la façon dont ils prennent en charge un certain type de processus. D’une certain façon, nous arrivons à une forme de correspondance entre l’idée des blocs visuels et celle des blocs d’instructions des langages textuels ayant une syntaxe héritée du langage C (délimités dans le texte par des accolades { } et utilisés pour décrire des fonctions utilisateurs ou des blocs de structures de contrôle comme if ou while).

Mais parce que OpenBlocks a été écrit en langage Java, son intégration dans un programme déjà existant n’est pas aussi universelle que l’on pourrait l’espérer : la compatibilité entre Java et d’autres langages n’est pas assurée d’emblée et lorsqu’elle est possible, elle n’est pas simple à mettre en œuvre. Ainsi, OpenBlocks ne peut être mis en œuvre aisément qu’avec des programmes conçus et réalisés avec Java. Google a mis à profit cette aisance d’intégration pour réaliser un outil de création d’applications pour son système d’exploitation pour écrans mobiles Androïd : AppInventor, rendu accessible au grand public en 2010. Il s’agit d’un environnement de développement d’applications pour écrans mobiles fonctionnant sous l’OS Androïd. Initié par Google avant d’être repris par le MIT, AppInventor se compose en deux grandes parties&thinsp: une interface de conception des éléments graphiques constituants l’application et un éditeur de script. L’interface de conception graphique permet d’organiser et de caractériser les éléments visuels fondamentaux de l’application, tels que les fenêtres, les boutons, les images, ou encore des effets d’animation précalculés. L’interface et le modèle graphique de l’application sont donc décidés à l’aide de cet éditeur de type WYSIWYG. Le comportement des ces éléments peut être défini à l’aide d’un environnement de création de scripts qui n’est autre qu’une version adaptée d’OpenBlocks.

Pour clore le panel que nous dressons ici des environnements de programmation à interface graphique par assemblage de blocs, nous pouvons évoquer le logiciel TurtleArt, l’une des applications intégrées dans le projet One Laptop Per Child. Débuté en 2006, l’objectif de la fondation et association à but non lucratif américaine One Laptop Per Child est de permettre l’usage d’ordinateurs à des enfants suivant un cursus scolaire dans des pays dits en voie de développement. Un ordinateur portable spécifique, le XO, a été conçu et produit massivement par la fondation dans l’optique de ne pas dépasser une valeur de 100 $. L’ordinateur est livré avec une version du système d’exploitation open source Linux et une interface graphique particulière, Sugar, qui n’utilise pas la métaphore du bureau héritée du Xerox Star, mais propose une vue en plein-écran d’un menu regroupant l’ensemble des « activités » (ou application) intégrées. Une seule activité/application peut être utilisée à la fois, dans un principe semblable à celui des plateformes mobiles comme l’iOS ou Android dans lesquelles une application occupe systématiquement l’ensemble de l’écran et ne peut pas être utilisée conjointement avec une autre. Parmi les activités intégrées à Sugar dans le XO, on trouve TurtleArt, une version de Logo programmable avec un langage visuel inspiré par Scratch. De la même façon que Scratch, TurtleArt se veut être un outil d’introduction à la programmation informatique fondé sur Logo et proposant des résultats visuels immédiats et un langage de « haute vivacité ³⁰ ».

Artemis Papert (fille de Seymour Papert) a utilisé cet outil afin de réaliser une série de livres autoproduits ³¹ à partir de 2009 intitulés Turtle Art Book qui donnent à voir sur chaque double page le code source textuel (et non sa version en blocs) et l’image qu’il a permis de réaliser. Au delà du fait qu’il s’agisse sans doute d’un hommage aux travaux de son père, l’attitude que l’auteur adopte et qui consiste à tenter un rapprochement entre la programmation informatique et les pratiques artistiques, semble relativement naturelle, puisque Logo est historiquement associé à sa tortue qui permet de réaliser des dessins. Le fait de présenter côte-à-côte un programme en tant qu’élément textuel et l’image qu’il a engendrée dans un ouvrage papier est un procédé qui a déjà été utilisé par d’autres dans le passé, comme nous allons le voir dans la prochaine partie traitant des langages de programmation textuelle spécifiquement conçus pour les artistes et les graphistes et non pour des enfants, comme c’est le cas de Logo.

IV — Un champ d’investigation dépassé ? 
Le panorama historique que nous venons de proposer sur la programmation visuelle fait appel à des références scientifiques qui s’avèrent être plus dense dans les années 1990 que de dans les décennies qui suivent. En effet, si certains projets comme Scratch et OpenBlocks et ses dérivés gardent une certaine actualité, nous pouvons constater que la mise en œuvre de langages de programmation visuelle dans des outils de production est plutôt rare. Le domaine dans lequel s’inscrit notre investigation étant celui de la création graphique œuvrant avec les technologies numériques, c’est à partir de ce champ que nous observons les outils mis en œuvre par les praticiens artistes et designers. De manière générale la programmation informatique est manipulée dans ces pratiques afin d’automatiser des tâches répétitives (traitement de fichiers images en série, mise en page automatique), de réaliser des objets graphiques interactifs (sites internet, applications mobiles, livres électroniques) ou encore afin de créer des objets ou des compositions graphiques à l’aide de structures algorithmiques (« art génératif », visualisation de données, robots d’impression à comportement autonome). Le paysage des outils de programmation permettant de répondre à ces besoins et d’accomplir ces différents types de projets sont majoritairement textuels : la lignée des langages issues de Design By Numbers, fortement inspiré de Logo, qui passe par Processing et aboutit sur des outils comme OpenFramework, ou bien le langage de script permettant de rendre les document Web interactifs, JavaScript, sont des langages textuels et sont parmi les outils les plus utilisés par les artistes et les designers contemporains.Il semble alors légitime de s’interroger sur cette prédominance du paradigme textuel dans les outils de création graphique qui sont pourtant, a priori, destinés à des créateurs que l’on imagine plus enclins à utiliser des méthodes de conception visuelles et graphiques plutôt que programmatique. La programmation visuelle formerait-elle un champ de recherche qui n’aurait pas fait ses preuves et serait dès lors abandonné au profit du paradigme textuel, qui par conséquent règne en souverain sur les outils de conception par la programmation ?

Il semblerait que la recherche sur la programmation visuelle ait effectivement perdu son souffle dans l’un des ses domaines d’émergence, les sciences informatiques, car le nombre de publications sur ce sujet est relativement réduit aujourd’hui. Cependant, la situation n’est pas aussi tranchée dans l’ensemble des domaines qui œuvrent avec la programmation, qu’il s’agisse de bas ou de haut niveau et que la porté des langages concernés soit vaste ou étroite.

IV • 1 — Langage de script visuel 
Les langages de script sont des langages de programmation interprétés. En opposition au langages compilés, qui demandent une traduction intégrale en langage machine avant de pouvoir être exécutés, les langages interprétés permettent une flexibilité d’exécution assez large est très avantageuse dans les outils de création artistique. En effet, l’interprétation permet à un programme source d’être modifié à la volé et donc d’influencer leur résultat perceptible (image ou son) en « live ». On comprend alors pourquoi de nombreux langages de programmation visuelle sont basés sur un principe d’interprétation puisqu’il permet d’atteindre une grande « vivacité » des représentations graphiques des programmes que nous avons abordé plus haut. Mais une autre caractéristique des langages de scripts entre ici en ligne de compte. En effet, cette catégorie de langage est aussi généralement utilisée pour permettre la mise en œuvre de bibliothèques logicielles complexes qui peuvent être écrites dans d’autres langages, voire même être sous leur formes compilées et exécutables. Le cas le plus classique que nous pourrions évoquer ici est celui de JavaScript, qui permet de programmer le comportement des objets utilisés dans la construction d’un document Web. En effet, JavaScript ne permet pas en lui-même de créer des objets textuels ou graphique et d’en changer le style d’apparence pour composer une page Web. Il est le langage de script qui permet d’employer les librairies logicielles qui sont utilisées pour créer le logiciel maître, la clef de voûte de toute navigation dans des pages Web : le navigateur Internet. Ce navigateur est conçu pour s’intégré dans un système d’exploitation qui prend déjà en charge de nombreux aspects fonctionnels : système de fichier, affichage, contrôleurs physiques (souris, clavier) gestion des médias et des éléments d’interface graphique, des polices de caractère et de l’affichage du texte, etc. Un navigateur Internet est donc un logiciel qui provient d’une agrégation de différentes fonctionnalités « systèmes » et de développements spécifiques pour répondre aux spécifications logicielles et aux protocoles préconisés par les consortiums qui tentent d’en réguler le fonctionnement technique global (le W3C étant certainement le plus connu). En tant que logiciel, le navigateur internet peut donc être regardé comme une collection de fonctionnalités génériques qui permettent l’affichage de pages Web selon le protocole HTML, qui est lui-même influencé par CSS pour transformer le style des éléments affichés dans une page. JavaScript permet d’accéder à ces fonctionnalités par la programmation sans imposer au programmeur de modifier le code source du navigateur, il devient alors possible de construire entièrement une page HTML à l’aide d’un programme JavaScript car il permet de faire appelle directement aux fonctionnalités mêmes qui sont employées par le navigateur lorsqu’il interprète une page décrite en HTML pour l’afficher dans une fenêtre. Dans ce cas, nous pouvons dire de JavaScript, dans le contexte de sa mise en œuvre dans les navigateur Web, fait le pont avec les fonctionnalités «&thinspnatives&thinsp» du navigateur et permet par conséquent de produire de nouvelles fonctionnalités « par dessus ».

Mais rien n’oblige les concepteurs logiciel à s’imposer le paradigme textuel dans la forge de leur langage de script. En effet, puisque les langages de script sont par nature interprétés et utilisé pour mettre en œuvre des librairies logicielles existantes, ils sont de très bons candidats à la mise en œuvre de la programmation visuelle. Il n’est donc pas étonnant de voir aujourd’hui de nombreux langages de script intégré dans des logiciels complexe de création artistique « hériter » des recherches émanant des sciences de l’informatique au sujet de la programmation visuelle. Les champs logiciels majoritairement concernés sont la postproduction vidéo et audio, l’image de synthèse et l’animation, comme le montrent les captures d’écran ci-dessous.

Une liste exhaustive des logiciels de création intégrant un langage de script visuel serait probablement impossible à réaliser, de nouveaux outils apparaissant fréquemment. Bien qu’il ne nous semble pas indispensable de dresser cette liste dans le cadre du présent texte, nous pouvons émettre l’hypothèse selon laquelle un recensement aussi complet que possible accompagné de captures d’écrans des environnements et des langages de programmation visuelle permettrait une analyse graphique précise des différentes grammaires visuelles mise en œuvre dans ce champ. Un tel travail aboutirait probablement à des constats utiles pour la forge d’un langage visuel issus de notre recherches et interrogeant ainsi notre problématique par une mise en pratique des outils du design. Le travail mené par Eric Hosick, engagé dans la création d’outils de création fondés sur la programmation visuelle, qui recense un grand nombre de langages visuels de toutes natures à l’aide de captures d’écrans, pourrait nous servir de référence pour un tel travail ³².

Bien que nous ne souhaitions pas fournir ici un surplus d’exemples de l’existant, il nous semble important de signaler l’apparition récente d’outils de programmation visuelle qui reposent sur les technologies du web. En effet, même si l’environnement technique du web intègre déjà un langage de script (JavaScript, comme nous l’avons déjà vu), il semblerait que de plus en plus de projets d’éditeurs de graphismes interactifs se constituent comme des surcouches de JavaScript. Une forme d’emboîtement est alors opéré&thinsp: un langage de script textuel, JavaScript, et la fondation d’un langage de script visuel. C’est ce que propose meemoo, un outil d’assemblage (ou de remix selon l’auteur) de différents outils prédéfinis selon le paradigme du dataflow et qui permet de réaliser des composition graphiques. Nous remarquons aussi le projet NoFlo, qui a pour objectif de proposer un environnement de développement complet exécuté dans le contexte JavaScript d’un navigateur et fondé sur un langage visuel dataflow.

IV • 2 — D’un paradigme à l’autre  NodeBox 
Nous avons vu que si la programmation visuelle cherche à utiliser des éléments graphiques pour permettre la construction de séquences d’instructions, cela ne signifie pas pour autant qu’elle évacue le texte, comme l’affirme sans ambiguïté Margaret Burnett&thinsp: «&thinspUne mécompréhension habituelle est que la recherche sur la programmation visuelle en générale et sur les langages de programmation visuelle en particulier est d’éliminer le texte » ³³. En effet, la plus grande partie des langages visuels ont recourt au texte, mais la place qui lui est donnée n’est pas équivalente selon les langages et les paradigmes. D’une façon générale, on peut dire que dans ces langages, le texte a une fonction essentiellement descriptive, car il informe sur la fonction et le type de processus que représentent les éléments graphiques opératoires qui composent le langage. Aussi, nous avons remarqué que certains langages visuels avaient des équivalents stricts sous une forme textuelle, le plus souvent dans le sens ou les éléments graphiques du langage visuel sont une représentation « directe » de fonctions ou d’éléments structurants d’un langage de programmation textuelle. On peut alors dire que c’est principalement l’aspect du langage et la méthode d’assemblage de ses fonctions et des ses structures qui change. Mais fondamentalement, la logique est rigoureusement la même dans un paradigme comme dans l’autre. Dans ce cas, pourquoi construire un langage visuel alors qu’un langage textuel existant permet de faire exactement la même chose ? Quelle peut être la motivation d’une telle transposition&thinsp? Quel est l’apport du paradigme visuel sur le paradigme textuel ?

« Les objectifs les plus communs recherchés par la programmation visuelle ont été (1) de rendre la programmation plus compréhensible à un certain public, (2) d’améliorer la justesse avec laquelle les personnes effectuent des tâches de programmation, (3) d’améliorer la vitesse à laquelle les personnes effectuent des tâches de programmation ³⁴ ». La première raison énoncée par Margaret Brunett est l’une des majeure de l’évolution du langage de programmation utilisé par NodeBox, outil de création de graphismes vectoriels et de visualisation de données initié par le groupe de recherche EMRG (Experimental Media Research Group) de l’université d’art de Sint Lucas d’Anvers, Belgique. Débuté en 2004, l’outil était alors un ensemble de composants logiciels qui visaient à former une librairie orientée « création graphique » en langage Python ³⁵. Un environnement de développement minimal permettait d’écrire le programme et d’observer ses résultats graphiques dans une fenêtre adjacente. L’ensemble du « dispositif » de NodeBox était alors très proche de celui de Processing, la différence résidant principalement dans le langage de programmation utilisé (Processing utilisant Java).

L’une des méthodologies de recherche et d’évaluation de NodeBox mise en œuvre par ses auteurs est de proposer des workshop à des étudiants en écoles et universités d’art. La structure de ces atelier est sensiblement toujours la même. Une affiche de visualisation de données doit être réalisée dans une période de cinq jours consécutifs selon l’organisation suivante :
1^er et 2^e jours, introduction aux problématique de la visualisation de données dans le design graphique et initiation à NodeBox
3^e jour, travail sur la définition du projet des étudiants, collecte et nettoyage des bases de données, recherches graphiques préliminaires ;
4^e jours, prototypage et réalisation du projet graphique sous NodeBox
5^e jour, finalisation et impression des affiches.
Lors de ces workshop, la plus grande part des problèmes récurrents qui obligeaient une intervention technique des auteurs étaient dues aux fautes de syntaxe que les étudiants faisaient par inadvertance. Ainsi, même si la logique de conception imposée par l’outil était comprise par des étudiants souvent novices en programmation informatique, l’écriture du texte qui fait programme constituait un frein souvent important.C’est la raison pour laquelle l’équipe de recherche de EMRG a pris la décision d’implémenter un langage visuel de type dataflow dans NodeBox 2, afin de minimiser les difficultés rencontrée par les étudiants participant aux workshop et, de manière plus générale, pour facilité l’accès à leur outil. Cependant, la transition vers un langage visuel à base de « nœud » n’était que partielle dans le sens ou le diagramme réalisé trouver sont équivalent stricte en langage python : une forme visuelle et une forme textuelle du même programme était « concurrentes », car l’une comme l’autre pouvaient être éditées, ce qui avait pour conséquence de produire à la fois une composition graphique mais aussi de générer l’autre forme du programme (qu’il s’agisse de la version visuelle ou textuelle).

Ce choix de « coprésence » des deux paradigmes de programmation présente un intérêt pédagogique non négligeable, car il affirme le fait que les deux paradigmes sont au service de la production d’un même objet graphique et reposent donc sur la même logique de conception mais n’en propose pas la même représentation. Il permet aussi de comparer les deux formes que prend le programme, car aucune d’entre elle n’est facultative, l’une engendrant l’autre quel que soit le lieu de la manipulation de l’utilisateur : le diagramme dataflow ou les lignes de codes. Finalement, il permet aussi de faire une forme d’étude sur les préférences des utilisateurs et, particulièrement, des étudiants en écoles d’art. Le constats effectués par l’équipe de EMRG à l’aide de cette version de NodeBox était relativement attendu : parce qu’il permet de concevoir et de représenter visuellement le processus de réalisation de l’image, parce qu’il permet intrasequement d’éviter les erreurs de syntaxe et les fautes de frappe, l’éditeur de diagramme est particulièrement apprécié des étudiants artistes et designers. C’est ce qui a décidé les auteurs du logiciel de création à « évacuer » la forme textuelle du programme dans la version 3 de NodeBox, seul l’éditeur visuel restant.

Aujourd’hui, Frederik De Bleser, l’un des fondateurs de NodeBox, c’est engagé dans la forge d’un outil héritier de NodeBox pour le Web utilisant un langage de programmation graphique. Actuellement toujours en cours de développement, cet outil nommé Maak montre le point auquel la programmation visuelle possède une actualité riche et qui, il semblerait, risque de gagner en densité dans les années à venir.