Préface

Lorsque je préparais, il y a deux ans, ma soutenance de diplôme en design graphique, une professeure m’a permis de comprendre la spécificité de ma pratique en tant que designer : j’ai un profil résolument technicien. Cela m’a amené à répondre à des sujets d’une façon assez personnelle, parfois alternative, en développant par exemple des outils générateurs de logotypes, ou encore en réalisant des expérimentations graphiques à l’aide d’algorithmes. J’aborde donc ce travail de recherche en assumant une démarche très empirique : comme beaucoup, je dois expérimenter pour comprendre. Compte tenu de la dimension relativement technique de l’écriture algorithmique, sa pratique constitue pour moi l’approche de recherche en design la plus adaptée à mon profil, et permet de concrétiser l’étude théorique en proposant des solutions appliquées.

Dans ce mémoire, je ne cherche pas à répondre à une question récurrente notamment sur les réseaux sociaux : “les designers devraient-ils coder ?”¹ En effet, je ne vois pas la pratique du code comme une compétence dont la nécessité devrait être débattue. Selon moi, il s’agit plutôt d’un outil dont le designer peut s’emparer, voire d’un matériau dont la manipulation – l’écriture algorithmique – met en jeu des outils. Ce mémoire s’intéresse donc à ces outils, les interfaces d’écriture de programmes, en particulier dans les pratiques créatives telles que le design.

Introduction

La place de l’algorithme

Qu’est-ce qu’un algorithme ?

Un algorithme est une séquence d’instructions qui vise à être exécutée afin de produire un résultat. Pour comprendre ou enseigner la notion d’algorithme, on fait bien souvent appel à des cas concrets que l’on rencontre dans la vie quotidienne. Une recette de cuisine, par exemple, constitue un algorithme : on y trouve des paramètres variables (les ingrédients, quantités, ustensiles utilisés) ainsi que des instructions (casser en morceaux, cuire au bain-marie, couper en dés). Enfin, le résultat obtenu lorsqu’on suit minutieusement cette recette de cuisine est le plat qu’on a alors préparé. Cette vision nous fournit une première définition du concept d’algorithme, donnée par Serge Abiteboul et Gilles Dowek² dans leur ouvrage “Le temps des algorithmes”.

Un algorithme est un procédé qui permet de résoudre un problème, sans avoir besoin d’inventer une solution à chaque fois. Avec cette définition, il est clair que, depuis l’aube de l’humanité, nous inventons, utilisons et transmettons des algorithmes : cuisine, taille du silex, pêche à la ligne, culture des lentilles et du blé, etc.³

Les algorithmes dans la société

Nous entretenons donc une relation quotidienne avec les algorithmes, et ce depuis l’aube de l’humanité. Toutefois, avec l’apparition de l’informatique au siècle dernier, les algorithmes se sont ancrés encore plus profondément dans nos vies. Au fil des années, ils se sont répandus de telle sorte qu’on les rencontre aujourd’hui partout, sans même nous en apercevoir. Abiteboul et Dowek établissent une liste d’usages variés d’algorithmes, qui existent aujourd’hui sous forme de programmes embarqués dans nos équipements numériques :

• le calcul : transformer des données – généralement des nombres –, résoudre des équations algébriques, encoder ou décoder un message ;
• la gestion de l’information : stocker, archiver et indexer des données ;
• la communication : faire circuler l’information via des protocoles de communication ;
• l’exploration : parcourir un grand nombre de possibilités afin de définir celle qui correspond le mieux à un problème donné – plus court chemin, meilleure répartition, etc. – on appelle aussi cette méthode la recherche exhaustive ou “recherche par force brute”⁴ ;
• l’analyse des données : agréger des statistiques et les classifier, afin par exemple de prédire des comportements – suggestions, recommandations ou encore publicité ciblée grâce au big data⁵ ;
• mais aussi : le traitement du signal (transformer, amplifier ou compresser une image ou un son), la commande d’un objet (établir la conduite d’une voiture autonome à partir des données captées), la fabrication de biens (automatiser la production industrielle), la modélisation et la simulation (dans la recherche scientifique, en établissant des théories) ;
• et enfin, dans le champ du design, comme dans le cas d’intelligences artificielles mises au profit de la création.⁶

La présence croissante des algorithmes dans nos vies peut soulever des craintes – pour certaines justifiées – et en font aujourd’hui l’objet de débats sociétaux. Dans ce contexte, on tend toutefois à oublier une caractéristique fondamentale des algorithmes : ils sont écrits par des êtres humains. Les programmes que nous utilisons au quotidien sont conçus par des développeurs, qui emploient des outils spécifiques à leur tâche et mobilisent des savoirs associés à ces outils : mathématiques, connaissance des langages, gestion de projet, etc. Ce sont ces outils qui forment le domaine d’étude précis de ce mémoire, que je mène avec une approche dite “de design”, c’est-à-dire centrée sur les utilisateurs et les usages.

L’algorithme et le designer

Bricodage

Les contextes d’application et problématiques envisageables liés à la programmation algorithmique – ou code – sont infiniment variés : conception de systèmes, développement d’objets numériques, création artistique, visualisation de l’immatériel, etc. En tant que designer, je souhaite m’intéresser plus particulièrement aux diverses pratiques mobilisant l’écriture de programmes informatiques dans un but créatif, aujourd’hui regroupées sous le terme de creative coding⁷.

Mon étude concerne le codeur amateur, situé à mi-chemin entre le codeur néophyte et le développeur confirmé. En effet, je ne me concentre pas sur la question de l’apprentissage du code, qui concerne des novices – souvent des enfants. Ce contexte est au cœur de l’actualité, car l’enseignement du code se fait de plus en plus entendre comme un besoin essentiel de nos jours. De nombreux projets et programmes existent ou se développent, avec le souci commun de proposer une découverte pédagogique et accessible des nombreuses possibilités qu’offre la pratique du code, ce n’est pas l’objectif de ma recherche. Je ne traite pas non plus des méthodes de travail de développeurs confirmés, notamment car les domaines dans lesquels ils exercent, très pointus techniquement, ne relèvent que rarement d’une forme de créativité artistique – mais plutôt d’une créativité technique caractérisée par la recherche d’une méthode logicielle optimale pour répondre à un objectif donné. Le champ d’étude de ce mémoire se concentre donc sur le niveau médian à ces deux extrêmes : celui des développeurs créatifs hybrides, des designers-codeurs amateurs. J’appellerai cette catégorie de pratiquants les “bricodeurs”, pour reprendre le terme de “bricodage” que David-Olivier Lartigaud propose dans son article du même nom, paru dans l’ouvrage Art++.

Le jeu de mot “bricoder” […] pourrait décrire l’attitude “esthétique” qui consiste à bricoler/programmer “l’objet informatique”. Le “bricodage” serait cette curiosité, ce désir d’ouvrir la “boîte noire” à des fins réflexives, artistiques ou esthétiques. Une approche de l’informatique “au-delà” du simple bidouillage qui offre “prise” sur la machine.⁸

Fig. 1 : Champ d’étude du mémoire

Lartigaud base sa définition du bricodage sur celle du bricolage, proposée par Claude Lévi-Strauss. Dans “La pensée sauvage”, celui-ci établit une distinction entre bricoleur et ingénieur.

On pourrait être tenté de dire que [l’ingénieur] interroge l’univers, tandis que le bricoleur s’adresse à une collection de résidus d’ouvrages humains, c’est-à-dire à un sous-ensemble de la culture. […] La différence n’est donc pas aussi absolue qu’on serait tenté de l’imaginer ; elle demeure réelle, cependant, dans la mesure où […] l’ingénieur cherche toujours à s’ouvrir un passage et à se situer au delà, tandis que le bricoleur, de gré ou de force, demeure en deçà, ce qui est une autre façon de dire que le premier opère au moyen de concepts, le second au moyen de signes.⁹

Ainsi, l’ingénieur est, selon Lévi-Strauss, extérieur au monde dans lequel il développe son projet, tandis que le bricoleur, au contraire, fait partie du monde dans lequel il doit construire avec des “résidus d’ouvrages humains”, ou “moyens du bord”.

Le bricoleur est apte à exécuter un grand nombre de tâches diversifiées ; mais […] son univers instrumental est clos, et la règle de son jeu est de toujours s’arranger avec les “moyens du bord”, c’est-à-dire un ensemble à chaque instant fini d’outils et de matériaux […].¹⁰

Par ailleurs, Lévi-Strauss voit le bricoleur comme une sorte d’esthète, prenant plaisir dans la simple combinaison nouvelle qu’il réalise : le résultat obtenu demeure secondaire, et la satisfaction du succès éventuel n’est pas primordiale. Ainsi, le bricoleur ne fait pas que résoudre des problèmes : il est également créateur, puisqu’il compose à partir d’éléments disparates. Il est donc à la fois technicien et créatif : une description qui convient tout autant au designer, se laissant surprendre et inspirer par l’inconnu et l’inattendu.

Concevoir ses outils

Le bricodeur est donc un praticien pour qui le code n’est pas seulement un outil mais également un matériau, au même titre que le bois ou le métal pour un bricoleur. En manipulant ce matériau, il exerce une prise de recul consciente sur ses outils et sa propre pratique. Cette démarche permet de questionner ces mêmes outils, de les détourner, voire, en supposant que la variété des outils existants est parfois insuffisante – lorsque ceux-ci s’avèrent inadaptés à un objectif donné –, de concevoir ses propres outils.

Les logiciels traditionnels du design – par exemple la suite Adobe, dont la maîtrise est enseignée dans les écoles de design – contiennent et mettent à disposition des algorithmes rendus “invisibles”, délivrés sous la forme d’outils et fonctions, souvent métaphoriques : tracé, duplication, transformation ou encore processus passent par l’usage d’une “plume”, d’un “pinceau” ou d’un “lasso”. Cet ensemble de fonctionnalités, souvent regroupés dans des “barres d’outils”, peuvent être remis en question par le bricodeur qui conçoit ses propres alternatives. Les processus algorithmiques sont ainsi rendus visibles, ce qui est une première étape vers leur modification en tant que matériau¹¹.

Cette philosophie peut être illustrée par la démarche de John Maeda. À la fois artiste, graphiste, enseignant et chercheur au MIT¹², Maeda a acquis une renommée mondiale en tant que pionnier d’une discipline mêlant les arts plastiques, le design, la typographie et l’interactivité, avec pour moyens récurrents l’ordinateur et la programmation : il a particulièrement contribué au développement du creative coding avec la création du logiciel Design By Numbers¹³, qui donna naissance à Processing¹⁴. Ainsi, le cœur de la démarche de Maeda est de créer les dispositifs avec lesquels il produit ensuite des œuvres, notamment graphiques. Comme l’écrit Paola Antonelli dans la préface de l’ouvrage de Maeda “Design By Numbers”, “la partie la plus importante de sa production, et celle dont il est le plus fier, n’est pas l’objet final, mais plutôt le processus.” L’auteure italienne précise l’idée fondamentale de Maeda : “pour bien designer avec un ordinateur, il faut créer soi-même le programme que l’on utilise – ou à défaut, le comprendre.”¹⁵

Parue en 2012, la dix-huitième édition de la publication “Graphisme en France”, intitulée “code <> outils <> design”, traite dans une série d’interviews, menée par Casey Reas et Chandler McWilliams, de cette question spécifique de la création d’outils individuels.

Nous avons posé deux questions […] :

• 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’œuvre finale ?

[…] 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. […] En créant de tels outils, uniques, les créateurs s’ouvrent de nouveaux horizons.¹⁶

Quels sont donc les outils génériques qui constituent l’environnement technique du designer-codeur amateur, ou bricodeur, et quels sont les outils innovants ? Comment le créatif interagit-il avec ces interfaces numériques ? Quels sont les cadres conventionnels de l’écriture du code, et quels autres cadres alternatifs, peuvent exister ? Et pour quels bénéfices ? Telles sont les questions qui animent ce mémoire, qui s’inscrit dans la continuité des initiatives de Maeda et s’articule autour d’une question similaire : comment faciliter¹⁷ et encourager¹⁸ l’intégration de processus algorithmiques dans une pratique créative ?

Le matériau algorithme

Je reviens à la définition d’un algorithme donnée en introduction : “un algorithme est une séquence d’instructions qui vise à être exécutée afin de produire un résultat”. Dans cette vision générique s’inscrit une catégorie plus réduite d’algorithmes spécifiques, un ensemble que l’on nomme “algorithmes symboliques”.¹⁹ La spécificité des algorithmes symboliques est qu’ils manipulent des symboles écrits : chiffres, lettres, assemblés en nombres, en mots et en phrases, et vecteurs de sens.²⁰ Deux notions clés se dessinent ici :

• celle de l’écriture, d’abord, qui s’impose comme le moyen, le processus de manipulation du matériau algorithmique – j’y reviendrai dans un second temps ;
• et celle de la manipulation, exercée par le biais d’instructions : si un algorithme est une séquence d’instructions, qu’est-ce qu’une instruction ?

Algorithme et instruction

Le sens du terme “instruction” est double : il s’agit à la fois de l’action d’instruire, au sens de “former l’esprit”, et dans un second temps, de l’ordre donné, qui dispose – qui met quelque chose dans une disposition en vue d’un résultat.

L’instruction comme action d’instruire

Selon le CNRTL, le premier sens du terme “instruction” fait donc référence à l’enseignement, au fait de “former l’esprit, la personnalité de quelqu’un par une somme de connaissances liées à l’expérience, à la vie, aux événements”. Cette notion de formation de l’esprit découle directement de l’étymologie latine du verbe “instuire” : instruere signifie “assembler, élever, bâtir, munir, outiller”. Ainsi, s’instruire veut dire “acquérir la connaissance, l’expérience”. Dans un sens métonymique, une instruction fait également référence à son contenu, à ce qui doit être fait, voire au fait même de suivre l’instruction. Cela nous amène au second sens du terme “instruction”, celui de l’ordre.

L’instruction comme ordre

L’instruction est, dans un sens métonymique, un discours indiquant ce qui doit être fait. L’instruction comme ordre soulève donc un sens presque militaire : instruire des soldats signifie leur faire acquérir les connaissances théoriques et pratiques, les qualités physiques et morales nécessaires à l’accomplissement de leur mission. Chez l’animal, on parle de “dresser”. L’ordre fait appel à une procédure protocolaire d’actions : on met quelqu’un ou quelque chose dans une disposition en vue d’un résultat défini.

Selon cette définition, un algorithme peut ainsi être perçu comme un ensemble d’instructions qui disposent – ou gouvernent selon le philosophe américain Alexander R. Galloway²¹ – des actions, mais surtout des opérations. Quelles sont alors les instructions fondamentales d’un algorithme ?

Quatre instructions fondamentales

Les algorithmes se ressemblent : ils sont constitués d’un nombre restreint d’expressions structurantes similaires, que l’on retrouve fréquemment, agencées différemment selon la finalité recherchée. Selon Abiteboul et Dowek, n’importe quel algorithme symbolique peut être exprimé à partir de quatre instructions élémentaires : la séquence, l’affectation, l’itération et la condition.²² Je développe et illustre ci-après ces quatre instructions sous le prisme de leur usage en programmation informatique.

Séquence

Fig. 2 : Séquence

La séquence est l’ordre même dans lequel les instructions sont agencées, c’est-à-dire la structure de l’algorithme elle-même : “fait ceci, puis cela”. Lorsqu’il est représenté – c’est-à-dire écrit ou dessiné –, on lit classiquement un algorithme de haut en bas, conformément au sens de lecture de nombreux langages.²³ Il est possible de s’émanciper, d’une certaine manière, de cette séquence, notamment en spécifiant expressément à l’algorithme d’éluder une partie des instructions dans certains cas précis. On groupe alors les instructions en ensembles – que l’on peut appeler des fonctions –, auxquels on peut ensuite faire référence. La “tête de lecture” de l’algorithme, ou son positionnement à un instant donné de son exécution – qui est extrêmement rapide mais pas instantanée –, ne déroule donc pas nécessairement la structure de cet algorithme de manière linéaire : elle peut effectuer des aller-retours, sauter des parties, y revenir, etc.

Affectation

Fig. 3 : Affectation

L’affectation est le fait d’attribuer une valeur à une variable – par exemple, “a prend la valeur de b”. Une variable est constituée d’un nom (son identifiant) et d’une valeur unique à chaque instant. Cette valeur peut être numérique (un nombre entier ou décimal, naturel ou relatif), textuelle (un caractère ou une chaîne de caractères) ou encore un booléen : vrai (true) ou faux (false).²⁴ Une variable peut également accueillir un ensemble de données comme un tableau (array en anglais). Comme son nom l’indique, une variable peut prendre plusieurs valeurs au cours du temps, à l’exception des constantes – dont la valeur est figée.

Itération

Fig. 4 : Itération

L’itération, communément appelé boucle, est le fait de répéter une série d’instructions. Ce concept est fondamental, puisque les algorithmes ont généralement pour but d’automatiser des tâches répétitives. On trouve plusieurs types de boucles, en voici une liste non exhaustive :

• la boucle “pour” (for loop en anglais), qui exécute les instructions pour un nombre donné d’itérations : “répète 10 fois ceci” ;
• la boucle “tant que” (while en anglais), qui exécute les instructions tant qu’un énoncé est valide : “tant que ceci est vrai, fait cela” ;
• la boucle “pour chaque” (for each en anglais), qui exécute les instructions pour chaque entité d’une liste (des contacts dans un annuaire par exemple) : “pour chaque ceci, fait cela”.

Condition

Fig. 5 : Condition

Enfin, la condition, ou test conditionnel, permet d’effectuer ou non une instruction – ou série d’instructions – selon la valeur d’une variable donnée : par exemple, “si ceci est vrai, faire cela”. On appelle généralement expression conditionnelle le schéma “si, alors, sinon” (if, then, else). De plus, on trouve parfois dans ces structures un nombre plus ou moins important d’expressions du type sinon si (else if), qui permettent des conditions imbriquées. Ici encore, cette notion est extrêmement importante, en cela qu’elle permet à un algorithme de prendre des chemins différents, de s’adapter à la complexité éclectique des données réelles qui lui sont fournies, et ainsi d’être plus polyvalent. À noter qu’on peut faire prendre des chemins différents à un algorithme en prenant comme conditions des valeurs générées aléatoirement : “choisis un nombre entre 1 et 10, s’il est supérieur à 5, fais ceci, sinon, fais cela”.

Puisque l’algorithme dispose de ces quatre opérations fondamentales, qui peuvent être instruites, celles-ci peuvent être concrétisées et réalisées par une machine. Ansi, le sens de l’algorithme est virtuel tant qu’il n’a pas été actualisé par la machine, qui exécutera les instructions initialement abstraites : quelles sont ces concrétisations techniques, ces machines qui exécutent des algorithmes ?

Concrétisation techniques et historiques

Je propose à présent une approche chronologique : quelles machines capables d’exécuter des algorithmes l’Homme a-t-il inventées ? Comment, et via quels progrès techniques, les algorithmes – symboliques – ont-ils évolué ? Cette question sera particulièrement traitée en focalisant l’étude sur les outils mis en œuvre au fil des époques.

De la main à la machine

Remontons aux origines des algorithmes symboliques, il y a 5 000 ans. À cette époque, les mathématiciens ont déjà mis au point des algorithmes servant à résoudre des calculs algébriques simples tels que des additions et des multiplications, mais ceux-ci sont exécutés à la main par les scribes. Des tâches répétitives qu’on aurait tout intérêt à déléguer aux machines, afin que celles-ci s’effectuent mécaniquement.

S’ensuivent cinq millénaires d’innovations techniques. Les premiers abaques²⁵, suivis quelques siècles plus tard de leurs proches dérivés, les bouliers, assistent les hommes dans ces calculs mais ne sont pas encore autonomes. Au Moyen Âge, les cloches au sommet des cathédrales sonnent chaque heure sans intervention humaine : ce sont les premières machines capables d’exécuter des algorithmes symboliques. En 1642, l’inventeur français Blaise Pascal²⁶ met au point la première machine à calculer, qu’il nomme “machine arithmétique” ; elle est retravaillée quelques 30 ans plus tard par Gottfried Leibniz²⁷ qui y ajoute une interface permettant de réaliser de façon automatique des multiplications et des divisions. Leibniz définit formellement la machine arithmétique par sa caractéristique universelle au sein du calculus ratiocinator, une machine calculatoire théorique.

Jacquard, ou le tissage programmé

En 1801, l’inventeur lyonnais Joseph Jacquard met au point un système de métier à tisser qui portera son nom : le fameux “métier Jacquard”. Celui-ci combine les métiers à tisser classiques avec le principe de cartes perforées inventé en 1728 par Jean-Baptiste Falcon – qui lui-même reprenait l’idée des rubans perforés que Basile Bouchon, son maître, proposait trois ans plus tôt. En perçant ou non un trou à un emplacement spécifique d’une carte, on peut programmer la machine : une fois insérée en entrée de la machine, les cartes guident les crochets qui soulèvent les “fils de chaînes” – dont l’agencement produit le motif sur le textile tissé. Ce dispositif est souvent considéré comme la première forme de stockage d’informations binaires (tout ou rien, vrai ou faux), et le métier Jacquard comme l’ancêtre de l’ordinateur.

Ce procédé laborieux de perforation est peut-être une des raisons pour lesquelles certaines personnes non initiées s’imaginent qu’un “informaticien” code en tapant des séries de 0 et de 1. Il semble toutefois important de distinguer l’unité d’information binaire “un trou ou un plein” de celle qui constitue la base de l’informatique moderne : le bit²⁸. En effet, une nuance importante s’observe sur la dimension physique de ces deux types d’unités : le trou et le plein peuvent être vus, touchés, respectivement rebouché ou perforé : en bref, ils sont tangibles. Le bit informatique, lui, nous est invisible et impalpable – à notre échelle, “à l’œil”. Par ailleurs, un trou ou un plein, dans la conscience du tisserand, est interprété comme un résultat : il peut être visualisé comme la présence ou l’absence d’une maille à un endroit précis du motif. Dans le cas des cartes perforées, une parfaite connaissance et maîtrise du matériel est donc essentielle à la programmation. À l’inverse en informatique, le programmeur ne se soucie – généralement – pas du stockage et de la transmission de l’information binaire.

La machine analytique de Babbage

Si le métier Jacquard est parfois considéré comme l’ancêtre de l’ordinateur, ces machines ne sont pas encore des ordinateurs à proprement parler. Il leur manque pour atteindre ce statut une caractéristique majeure : l’universalité. En effet, les machines citées plus haut en exemples sont chacune destinée à une unique fonction ; là où un ordinateur est polyvalent, universel, capable d’exécuter n’importe quel algorithme symbolique imaginable : en résumé, une “machine à tout faire”.

Au cours du XX^ème siècle, l’apparition des premières machines analytiques va transformer les usages des algorithmes. En 1834, le visionnaire britannique Charles Babbage²⁹ débute le développement d’une machine d’un concept alors nouveau, qu’il qualifie de “machine analytique”. Celle-ci reprend le principe des machines à calculer mécaniques qui existent alors depuis plusieurs siècles déjà. Mais l’inventeur a l’idée d’ajouter à ces systèmes le principe des cartes perforées apparues avec les métiers Jacquard. Les composants de cette machine sont similaires à ceux qui équipent un ordinateur moderne.³⁰

Pendant qu’il travaille sur ce projet, Babbage entre en correspondance avec Ada Lovelace. Pionnière de la science informatique, c’est elle qui, en 1843, sera à l’origine du premier algorithme destiné à être exécuté sur une machine : la machine à différences de Charles Babbage. Cet algorithme, considéré comme le premier programme informatique à proprement parler, sert alors à calculer la suite des nombres de Bernouilli³¹. Ada Lovelace est ainsi connue comme la première programmeuse de l’histoire.

La révolution Turing

Les travaux de Lovelace et Babbage trouvent écho un siècle plus tard, dans les années 1930, grâce notamment aux recherches d’Alan Turing³². Cet inventeur, figure emblématique de la recherche mathématico-scientifique du XX^ème siècle, conçoit en 1936 la “machine de Turing”, en vue de donner une définition précise au concept d’algorithme et à sa représentation formelle et technique de “procédure mécanique”.

[La machine de Turing] consiste en deux éléments principaux :

1. une machine représentée par une tête de lecture/écriture susceptible de se trouver dans un nombre fini d’états,
2. une bande (magnétique par exemple) de longueur infinie […] devant laquelle se meut la tête de lecture et qui alimente en données cette machine. […]

Turing montre qu’une partie de la bande peut contenir la description de la table d’actions élémentaires d’une autre machine de Turing : une machine peut en simuler une autre. C’est grâce à cette construction schématique […] que Turing peut démontrer qu’il existe des machines de Turing dites universelles capables d’imiter toute autre machine de Turing.³³

Turing illustre ainsi la notion d’universalité telle qu’elle avait été formulée par Lovelace et Babbage : après la machine de Turing, il illustre la machine universelle de Turing, considérée comme la genèse des travaux de John von Neumann. En effet, ce mathématicien et physicien américano-hongrois propose en 1945 un modèle utilisé encore aujourd’hui dans nos ordinateurs modernes : l’architecture de von Neumann³⁴.

Fig. 6 : Architecture de von Neumann

En transposant ces composantes dans notre vocabulaire matériel contemporain, on confirme la proximité entre ce modèle, vieux de plus de 70 ans, et les ordinateurs que nous utilisons au quotidien :

• le processeur effectue les opérations ;
• la mémoire vive (RAM) stocke les données en cours d’utilisation ; et les disques durs – ou autres supports de stockage – contiennent des données pérennes ;
• les périphériques en tout genre permettent l’interaction en entrée (clavier, souris, écran tactile, microphone, caméra, port USB, lecteur de disque, etc.) et en sortie (écran, haut-parleurs, etc.)

Nous arrivons à ce stade à l’ordinateur tel que nous le connaissons, appareil nécessaire à la programmation algorithmique, capable d’exécuter des logiciels. On pourra donc considérer que l’ordinateur est la machine du programmeur, mais une machine universelle, capable de simuler elle-même un environnement d’outils – les logiciels de programmation.

Or, ce sont ces logiciels de programmation qui permettant la manipulation du matériau algorithmique, et cette manipulation passe par l’action de programmer : pour être exécutés par la machine, les algorithmes doivent être écrits. Cette remarque conclut cette première partie sur ce qu’est le matériau algorithme, et me permet de me focaliser à présent sur sa manipulation : l’écriture algorithmique.

L’écriture algorithmique

Afin d’être exécutés par une machine, les algorithmes doivent être transposés de l’intelligence du programmeur vers un support pérenne et interprétable par cette machine. Parce que les ordinateurs ont été conçus pour manipuler des symboles, la méthode de communication qui s’est naturellement imposée est l’écriture. Programmer, vu de l’extérieur, c’est avant tout taper une succession de lettres et de chiffres sur un clavier : dans cette partie, je m’intéresse donc à cette action d’écriture.

Qu’est-ce qu’écrire ?

L’écriture, formalisation du langage

L’écriture est une méthode de communication qui consiste à représenter un langage via l’inscription de signes graphiques sur des supports variés. En cela, elle est une forme d’inscription, tel que le terme est défini par Bruno Bachimont.

L’écriture, que nous prenons de manière large comme un système graphique permettant de constituer des inscriptions visant à véhiculer une signification. Elle associe donc un substrat matériel à une forme d’expression : de l’encre sur du papier mobilisé conformément à la forme textuelle par exemple.³⁵

L’écriture est née quatre millénaires avant notre ère, en Mésopotamie, afin de conserver des traces d’échanges – notamment commerciaux –, la mémoire humaine n’étant pas infaillible et encore moins illimitée. Le philosophe François Dagognet nous rappelle l’adage latin : “Verba volant, scripta manent” – les paroles s’envolent, les écrits restent.³⁶ Mais Dagognet souligne aussi que dans ce transfert de la parole à l’écrit, le discours n’est pas forcément transcrit scrupuleusement, mais peut au contraire subir des modifications.

De ce que le vocalisé s’insinue dans le texte et aide à le comprendre, il ne s’ensuit pas que l’imprimé ne le dépasse pas. Si le graphisme ne supprime pas entièrement le gestuel, il l’amoindrit, tend à l’éloigner, voire à l’enjamber.³⁷

En résumant sa pensée, je retiendrai ceci : si l’écriture découle de la parole comme une nouvelle forme d’échange communicationnel, elle n’en est pas une forme strictement identique. Un énoncé vocal ne transmet pas seulement la nature de l’énoncé, mais également sa forme – la tonalité, la prononciation, l’attitude –, au même titre que la représentation graphique joue sur des variations de représentation – graphie, tracé, composition, contraste – pour véhiculer une information qui enrichit le contenu même de l’écrit. Ce propos rejoint la thèse d’Anne-Marie Christin, professeure spécialiste de l’écriture et des relations entre texte et image. Selon elle, l’écriture ne reproduit pas la parole, mais la rend visible : elle est le résultat de la fusion entre le langage, qui régit les échanges à l’intérieur d’un groupe, et l’image, composée de figures et de supports.³⁸

L’écriture présuppose donc un emploi du langage. Selon le TLFi, le terme langage implique une définition multiple, selon que l’on parle du langage comme faculté et comme système, ou bien comme moyen d’expression, comme usage. Un langage est généralement doté d’une sémantique, et fréquemment d’une syntaxe – deux branches de la linguistique symétriquement opposées. La sémantique étudie les signifiés : ce dont on parle, ce que l’on cherche à transmettre – en résumé, le fond de l’énoncé. La syntaxe, pour sa part, se concentre sur le signifiant : la langue, la représentation graphique, la grammaire employée, etc. – en résumé, la forme de l’énoncé.³⁹

En conclusion de la définition de l’écriture, je citerai à nouveau Bruno Bachimont qui distingue l’écriture algorithmique comme singulière. Il établit trois raisons – méthodes de raisonnements – : la raison orale, la raison graphique et la raison computationelle. L’écriture algorithmique appartient à cette troisième catégorie.

L’hypothèse que nous formulons est que l’informatique, sous la forme des systèmes formels automatiques, fournit précisément un nouveau type de support, les supports dynamiques, auquel doit correspondre un type spécifique de synthèse, et par conséquent une rationalité spécifique, que nous proposons de baptiser “raison computationnelle”.

Trois typologies d’écriture

La notion d’écrit, au sens large, désigne donc les diverses formes que peuvent prendre la traduction graphique de l’information communiquée : dessins, symboles, chiffres, lettres, etc. Toutefois, le sens généralement admis du terme écrit désigne trois grandes catégories de systèmes : logographique, syllabique et alphabétique.

• l’écriture logographique emploie des logogrammes, caractères – ou glyphes – représentant un mot ou un morphème – une fraction de mot. Plus précisément, on parle d’un pictogramme lorsqu’on représente directement un objet (par exemple, le blé), et d’un idéogramme lorsqu’on cherche à symboliser une idée (par exemple, la vitalité).
• l’écriture syllabique emploie un syllabaire, composés de symboles exprimant chacun une syllabe. Les différentes formes d’écritures chinoises et japonaises en sont les exemples les plus courants.
• enfin, l’écriture alphabétique est celle que nous connaissons le mieux, pour l’utiliser quotidiennement. Elle utilise un ensemble de symboles, dont chacun représente un phonème – plus petite entité linguistique –, composés de manière à former des mots. Une trentaine de signes alphabétiques suffisent généralement à écrire une langue.⁴⁰

L’écriture algorithmique appartient classiquement à cette troisième catégorie : quelle forme prendrait la programmation si l’on changeait de catégorie, en préférant par exemple une écriture logographique ? Je propose une première réponse à cette question avec une expérimentation intitulée “emoji2code”, permettant de coder à partir d’un enchaînement d’emoji. Ici, l’écriture n’est pas classique – on ne tape pas sur les touches du clavier pour former des mots et des phrases –, il est d’avantage question de composition⁴¹ : il suffit de cliquer sur un emoji pour le voir apparaître dans la zone de saisie. Chaque emoji correspond à une instruction (par exemple “boucler”, “écrire dans la console”) ou un élément (une variable, une opération mathématique). Dans l’exemple ci-dessous, je réalise simplement une boucle permettant de compter de 0 à 9. Fig. 7 : emoji2code, une interface d’écriture algorithmique à l’aide d’emoji

La littérature, ou l’art écrit

La pratique de l’écriture se place comme acte fondateur de la littérature. Par “littérature”, j’entends la conception de l’écriture comme une forme d’art. Cet art recouvre de nombreux genres et styles : genre pictural, genre narratif, genre dramatique, contenu, ou encore registre.⁴²

Nul besoin de traiter en détail les formes d’écritures que nous connaissons le mieux : page par page, alignant des mots dans un alphabet latin, de la gauche vers la droite et du haut vers le bas. Pour questionner le potentiel créatif de la pratique de l’écriture, je m’intéresse plus particulièrement à ses représentations alternatives, non-conventionnelles. Pour Anne-Marie Christin, l’exemple le plus pertinent qui a libéré l’écriture occidentale est une œuvre de Stéphane Mallarmé, poète français du XIX^èmesiècle. On le décrit aujourd’hui comme un des premiers “poèmes typographiques”.

Tout a changé dans la pensée occidentale de l’écrit avec le Coup de Dés de Mallarmé. Pour la première fois de leur histoire, les héritiers de l’alphabet que nous sommes ont pris conscience du fait qu’ils ne disposaient pas simplement, avec ces quelques signes, d’un moyen plus ou moins commode de transcrire graphiquement leur parole mais d’un instrument complexe, double, auquel il suffisait de réintégrer la part visuelle – spatiale – dont il avait été privé pour lui restituer sa plénitude active d’écriture.⁴³

Fig. 8 : Extrait du "Coup de Dés" de Mallarmé

Ici, le fait de voir le poème participe à sa lecture et à sa compréhension : l’ordonnancement du poème figure le poème même. Sur le même principe, le poète français Guillaume Apollinaire publie en 1918 un ouvrage intitulé “Calligrammes”, terme qu’il invente à partir de la contraction de calligraphie – l’art graphique du dessin de caractères – et d’idéogramme. Cette forme particulière de poésie est parfois nommée “poésie graphique”.

Fig. 9 : Calligramme "Il Pleut" d’Apollinaire

On notera que François Dagognet classe le travail d’Apollinaire dans une catégorie qu’il intitule “iconographies ordinatrices et inventives”. Celle-ci est constituée de productions graphiques et littéraires qui font usage de métaboles, terme qu’il emprunte au groupe µ⁴⁴ dans son ouvrage “Réthorique Générale” : un métabole désigne tout espèce de changement du langage.⁴⁵ Comme dans beaucoup de pratiques créatives, la nouveauté passe donc par le changement, l’émancipation des artistes vis-à-vis des formes ordinaires, au profit de formes nouvelles, alternatives.

En reportant ces distinctions au champ des algorithmes, on pourrait facilement s’interroger sur la forme que pourrait prendre une “écriture alternative” d’un algorithme, comme par exemple une écriture poétique, c’est-à-dire une écriture qui privilégie l’expressivité de la forme – les mots disant plus qu’eux-mêmes par leur choix et leur agencement. Le livre “./code --poetry” de Daniel Holden et Chris Kerr, ainsi que le site web associé⁴⁶, présentent des exemples de programmes s’affranchissant des conventions habituelles – j’y reviendrai – et dont le résultat est essentiellement esthétique : en résumé, du “code poétique” qui ouvre la voie à une littérature algorithmique⁴⁷, qui traite le code comme matière. On peut notamment citer pour exemple Flocking.go, un programme dans le langage Go, mêlant poésie classique et algorithmique, pour un résultat animé qui fait écho avec la sémantique du texte.
Fig. 10 : Flocking.go, un programme poétique animé dans le langage Go

L’écriture algorithmique

Attardons-nous davantage sur la spécificité de l’écriture dans le cas d’un programme informatique : quelle différence y a-t-il entre l’action de coder et la rédaction d’un article ou d’un poème ? On notera tout d’abord que dans ce contexte informatique, les algorithmes prennent la forme de programmes, rédigés dans un langage de programmation spécifique, grâce à un ordinateur. Toutefois, algorithme et programme sont deux notions différentes bien qu’étroitement liées, tout comme informatique et ordinateur : il convient donc de les clarifier.

De l’ordinateur à l’informatique

La définition du terme “ordinateur”, dans son sens admis populairement, se base sur les travaux d’Alan Turing.

Un ordinateur est un système de traitement de l’information programmable tel que défini par Turing et qui fonctionne par la lecture séquentielle d’un ensemble d’instructions, organisées en programmes, qui lui font exécuter des opérations logiques et arithmétiques.

Les composants technologiques des ordinateurs modernes traitent des informations binaires. Là où les cartes perforées de Falcon utilisaient des trous ou des pleins pour signifier un des deux états uniques qui composent un bit, nos ordinateurs, dont le fonctionnement est basé sur l’électricité, utilisent pour signifier une valeur la présence ou l’absence de courant, de charge ou de tension électrique – suivant qu’il soit question de stocker ou de transmettre une donnée.

Les racines mathématiques de l’ordinateur se retrouvent dans l’étymologie même du terme. En 1955, Fançois Girard, responsable du service publicité d’IBM France, fait appel à son ancien professeur de lettres, Jacques Perret, afin de trouver ensemble une traduction au mot anglais “computer”. Perret propose alors l’appellation “ordinatrice électronique”, inspirée de l’ordonnateur, ce composant de la machine décrit par Babbage comme celui qui “prend et reporte les nombres, et les soumet à l’opération demandée”. L’intitulé est ensuite simplifié en ordinateur et entre rapidement dans le langage populaire.

La notion d’informatique est intimement liée à l’univers des ordinateurs. Si en anglais, ordinateur se dit “computer”, la notion d’informatique est tout simplement désignée par la formule “computer science” – to compute signifiant calculer en français. Certains penseurs affirment toutefois que l’on ne peut pas définir l’informatique comme “la science des ordinateurs”. On attribue notamment à Edsger Dijkstra, informaticien néerlandais reconnu, l’aphorisme suivant : “L’informatique n’est pas plus la science des ordinateurs que l’astronomie n’est celle des télescopes.” Les auteurs de cette phrase sont en réalité Michael Fellows et Ian Perberry, et la citation complète – traduite – est la suivante :

L’informatique n’est pas plus la science des ordinateurs que l’astronomie n’est celle des télescopes, la biologie celle des microscopes, ou la chimie celle des béchers et des tubes à essais. La science ne traite pas des outils. Elle traite de notre manière de les utiliser, et de ce que l’on découvre en les utilisant.⁴⁸

Dans “Qu’est-ce que l’informatique ?”, l’universitaire français Franck Varenne propose et critique de nombreuses ébauches définitionnelles – c’est là le cœur de l’ouvrage – avant de conclure par la description suivante :

[L’informatique est] une technologie (dans son caractère instumental et de délégation opératoire) et une discipline (dans ses versants cognitifs et réthoriques) de démultiplication, d’entrelacement, d’application […] et/ou de confrontation des voies de la référence. Plus brièvement : elle est une technologie d’entrecroisement automatique et programmable des voies de la référence.⁴⁹

Varenne nomme “voies de la référence” la faculté des symboles utilisés en informatique (nombres, lettres, signes, etc.) à faire référence à un ou plusieurs autres symboles. En ce qui concerne le calcul numérique, les voies sont au nombre de deux : la concrétisation ou l’abstraction. La concrétisation est le fait de rapprocher le théorique de l’expérience, et l’abstraction est le phénomène inverse : celui de tirer l’expérience vers le théorique. Varenne synthétise cette dualité inhérente à l’ordinateur dans une interview donnée suite à la parution de “Qu’est-ce que l’informatique ?”.

En ce sens, l’ordinateur est une machine particulière, une machine qu’on peut dire mi-matérielle, mi-formelle, ou encore mi-concrète, mi-abstraite. L’informatique passe ainsi pour une technologie de conciliation extraordinaire.

Si elle en est fondamentalement inspirée, l’informatique va au-delà du calcul et joue sur les niveaux de symboles mis en œuvre : les symboles sont hybridés via des procédés de sous-symbolisation et de simulation. On pourrait illustrer cette distinction par un phénomène de “couches” superposées, où chacune est une symbolisation de celle sur laquelle elle s’appuie : cette superposition constitue ainsi une forme de simulation récursive, chaque strate jouant le rôle de la précédente sous une autre forme.

Fig. 11 : Schéma de la simulation récursive

De l’algorithme au programme

Un programme informatique est une suite d’instructions qui effectue une ou plusieurs tâches spécifiques lorsqu’elle est exécutée par un ordinateur.⁵⁰ Franck Varenne attire notre attention sur une possible origine de la confusion entre algorithmes et programmes. Il cite Charles Hoare, professeur et informaticien britannique, également connu pour la conception de nombreux algorithmes encore utilisés aujourd’hui. Hoare déclare que “la programmation informatique est une science exacte en ce que toutes les propriétés d’un programme […] peuvent être découvertes à partir du texte du programme lui-même au moyen de raisonnement purement déductif.” Varenne y oppose l’argumentation de James Fetzer, philosophe américain spécialisé notamment en informatique : la vision de Hoare amène à confondre les algorithmes et les programmes. Selon Varenne, rien n’implique une exacte similitude entre le comportement supposé du programme – à la lecture donc – et les conséquences réelles de son exécution sur la machine.

Les algorithmes sont des solutions formelles (abstraites en ce sens) et effectives pour certains problèmes bien formulés. Les programmes chargés en mémoire (exécutables) sont en revanche des modèles causaux (car physiques) de ces algorithmes. Alors que les algorithmes sont des modèles abstraits des programmes exécutables, les programmes exécutables sont des modèles causaux des algorithmes.⁵¹

Varenne qualifie donc ces modèles d’imparfaits : le programme ne peut jamais être vérifié formellement, mais seulement de façon empirique. En effet, on peut établir la validité d’un programme, notamment en développant une sémantique qui régule le code écrit par le programmeur. On résout alors les erreurs de programmation : variables sans valeur définie, fautes de syntaxe, structure erronée ou illogique, etc. Toutefois, la machine peut elle-même faire preuve de dysfonctionnement du fait même de sa dimension physique : processeur défectueux, espace de stockage corrompu, mémoire vive saturée, etc.

Cette marge d’incertitude entre le programme que l’on voit et ce que l’on obtient lorsqu’il est exécuté a été baptisée WYSINWYX, pour What You See Is Not What You eXecute – littéralement “ce que vous voyez n’est pas ce que vous exécutez”.⁵² Cet acronyme est une référence au paronyme duquel il est inspiré : le terme WYSIWYG —What You See Is What You Get, soit “ce que vous voyez est ce que vous obtenez” – désigne, en informatique, les interfaces utilisateurs où l’on compose directement le résultat final souhaité.⁵³

Cet écart entre ce que l’on pense avoir programmé et ce qui se produit réellement est une caractéristique propre à la programmation, qu’on ne retrouve pas dans les outils de création classiques, tels que ceux de la suite Adobe – qui sont justement des outils WYSIWYG. Dans sa thèse “Designing Design Tools”, Nolwenn Maudet définit ces deux catégories comme les extrêmes d’un panel d’outils potentiels, hybrides, à concevoir.

Aujourd’hui, la programmation et les interfaces graphiques sont deux ensembles d’outils mutuellement exclusifs. Nous pouvons les considérer comme deux limites opposées d’un large éventail d’outils de conception possibles. Je soutiens que nous devons inventer de nouveaux objets interactifs et de nouvelles interactions pour remplir cette gamme.⁵⁴

Par ailleurs, les programmes informatiques impliquent d’être écrits dans les langages spécifiques, appelés langages de programmation – ou langages informatiques –, sur lesquels je me penche à présent.

Langages informatiques

Il existe une grande variété de langages de programmation, comme en témoigne la liste établie sur Wikipédia⁵⁵. Tous possèdent des règles de syntaxe, un vocabulaire, une sémantique, un vocabulaire et des identifiants qui leur sont propres – mais ils partagent également de nombreux points communs. À la vue de cette liste de plus de 600 langages référencés, on peut se poser la question suivante : pourquoi y a-t-il autant de langages de programmation ? Sur le site communautaire de programmation StackOverflow⁵⁶, l’ingénieur Matt Sherman propose dans un article⁵⁷ plusieurs éléments de réponse :

• les différents langages constituent une multitude d’outils, chacun plus ou moins adapté à des usages précis – il s’agit de choisir pour chaque finalité le langage qui sera le plus efficace, sûr et rapide à manier ;
• les programmeurs ont des goûts personnels – et des compétences qui leur sont propres. Tel ou tel langage est souvent choisi en fonction des connaissances de l’équipe de programmation ;
• la variété des langages de programmation est ainsi riche, en ce qu’elle permet plus de flexibilité en fonction des tâches à accomplir et des personnes qui vont employer ces langages.

Il faut aussi prendre en compte la faculté qu’ont les langages à disparaître – tels des langues mortes –, et le fait que certains ne soient que très peu utilisés, car trop spécifiques, ou tout simplement conçus pour le divertissement plutôt que dans l’optique d’une application logicielle concrète. Par ailleurs, on peut catégoriser les langages de programmation en paradigmes⁵⁸ de programmation : en résumé, un paradigme désigne la façon que le programmeur a d’envisager la structure et le fonctionnement du programme.

Les langages de programmations les plus populaires de nos jours sont JavaScript, Python, Ruby, Java, PHP ou encore C++ – d’après une étude⁵⁹ menée par la plateforme de développement collaboratif GitHub⁶⁰. Je m’attarde un instant sur un autre langage qui me semble s’en démarquer : le pseudo-code. Il s’agit d’une façon de décrire un algorithme dans un langage naturel, sans faire référence à un langage de programmation particulier. Sans réelle règle ou convention établie, l’écriture en pseudo-code permet de mesurer la difficulté de la conception d’un algorithme, et ainsi d’anticiper une structure flexible et adaptée au développement réel qui a lieu dans un second temps : ici, un exemple de pseudo-code décrivant un algorithme de résolution du problème FizzBuzz.

Fig. 12 : Un exemple de pseudo-code

Il existe des points communs entre ces langages – notamment dans l’exercice de leur écriture – mais également des différences évidentes. Qu’est-ce qui distingue un langage informatique du langage courant que nous utilisons au quotidien ? Comment est-il régi ? Comment s’écrit-il ? En résumé, quelle est la particularité du langage informatique ?

Langages naturels et langages formels

En linguistique, on appelle “langage naturel” un langage qui a évolué naturellement au travers de l’utilisation humaine et de sa répétition, sans planification particulière ou préméditation consciente de la part du peuple qui l’utilise – comme le français ou l’anglais par exemple. On y oppose la notion de “langage formel”, parfois également appelé “langage construit” ou encore “langage artificiel”.⁶¹ À l’inverse, il s’agit ici d’un langage créé de toutes pièces dans un temps relativement court, par une population bien plus restreinte – éventuellement l’œuvre d’un seul auteur. On peut distinguer trois catégories parmi ces langages construits :

• les langages conçus, ou engelangs (de l’anglais engineered), à nouveau divisés en langages logiques (par exemple les langages de programmation informatique), philosophiques ou expérimentaux ;
• les langages auxiliaires, ou auxlangs, créés pour la communication internationale – un des plus célèbres étant l’Esperanto ;
• les langages artistiques, ou artlangs, comme ceux inhérents à une œuvre de science-fiction ou de fantaisie – par exemple les langues créées par l’auteur J.R.R. Tolkien.

Le terme de langage formel fait davantage référence au champ des mathématiques et de l’informatique : cette notion intègre à la fois l’ensemble des séquences de caractères et des symboles qui sont employés et les différentes règles qui déterminent leurs usages. C’est donc à cette catégorie que je m’intéresse en particulier dans la suite de cet exposé, centrée sur les langages informatiques.

En m’interrogeant sur la dualité entre langage naturel et langage formel dans notre manière de communiquer à la machine – notamment des instructions –, je propose la question suivante : ne peut-on pas utiliser d’autres formes de langage qu’un langage de programmation ? J’ai entamé une proposition de réponse grâce à une interface intitulée text2code⁶², qui permet de “coder” en langage naturel, c’est-à-dire en écrivant de l’anglais intelligible par tous – ce qui implique une traduction “cachée” en langage JavaScript, exécutable par un navigateur.
Fig. 13 : text2code, une interface d’écriture algorithmique en langage naturel
Cette expérimentation rejoint la notion de pseudo-code : les instructions sont données en langage naturel, mais doivent ensuite être concrétisées, pour reprendre le terme de Varenne, en un langage de programmation. En réalisant cette expérience, je me suis rendu compte que la richesse d’un langage naturel pouvait donner lieu à des résultats inattendus lorsqu’on cherchait à le “simplifier” en un langage exécutable.

Lignes de code, règles et conventions

Le code, tel que le définit l’archéologue et linguiste Clarisse Herrenschmidt, est “un moyen de chiffrer, propre à la machine qui crypte et décrypte.”⁶³ C’est la forme de programmation la plus classique : la quasi-intégralité des produits numériques, logiciels et autres applications que nous utilisons aujourd’hui ont été écrits, ligne par ligne, symbole par symbole. Les langages de programmation emploient une syntaxe – un ensemble de contraintes qui régissent la combinaison des symboles – qu’il convient de respecter pour assurer la bonne exécution du programme. Sinon, le compilateur rencontrera une anormalité et le “debugger” (ou la “console”) va afficher un message d’erreur. Le respect des règles imposé par un langage de programmation assure que celui-ci pourra être décrypté par la machine, et ainsi exécuté : le code est dit “valide”.

Outre la dimension fonctionnelle, un programmeur se doit de respecter un certain nombre de conventions afin d’être compris par d’éventuels autres programmeurs qui viendraient à lire ce code : la question n’est plus seulement “ce code est-il lisible par la machine ?”, mais “ce code est-il lisible par un humain ?”. On intègre alors à son écriture des principes visuels, de composition, ou encore de choix sémantiques. Un certain nombre de principes graphiques sont utilisés. Par exemple, l’indentation consiste à ajouter des espaces – ou des tabulations – en début de chaque ligne de code de façon à structurer visuellement l’ensemble du programme.⁶⁴ Dans certains langages, les espaces vides sont ignorés lors de l’interprétation par la machine, ils sont donc utilisés selon la convenance pour faciliter la lecture. À l’inverse, dans d’autres langages – comme le Python –, cette structuration est essentielle car elle définit le fonctionnement même du programme, il n’est donc pas ici question uniquement de style ou de clarté. Un autre principe graphique employé pour la lisibilité est la coloration syntaxique (ou syntax highlighting en anglais), qui formate automatiquement les éléments du texte – notamment par le changement de couleur mais parfois aussi de typographie – afin d’en simplifier la lecture. Ce système répond d’ailleurs à un problème énoncé par Franck Varenne, faisant lui-même référence au philosophe Gilles Gaston Granger : “des symboles qui peuvent être écrits côte à côte dénotent des types d’entités différents”.⁶⁵

Voici d’autres exemples de conventions courantes :

• les commentaires, exprimés en langage naturel (souvent en anglais), non pris en compte dans l’exécution du script : ils servent à clarifier le fonctionnement du programme à un endroit précis auprès de potentiels futurs lecteurs ;
• l’indentation, comme expliqué plus haut, dont on définit les points de retours à la ligne ou le nombre d’espaces ;
• la longueur des lignes, pour garantir l’affichage complet en largeur du code au sein d’un éditeur de texte ;
• le nommage des variables, notamment sur la façon de concaténer – mettre bout à bout plusieurs chaînes de caractères – des intitulés. On parle notamment de casse, c’est-à-dire de l’usage des lettres capitales pour assurer la lisibilité d’un mot-valise⁶⁶ ;
• et d’autres encore, liées aux “bonnes pratiques” et principes divers qui permettent l’intelligibilité, l’efficacité, la flexibilité ou encore la sécurité d’un programme.

Fig. 14 : Un exemple de programme simple dans le langage JavaScript

L’action de programmer relève donc d’une écriture. Celle-ci se fait dans des langages informatiques, sous forme de lignes de codes, régies par des règles et des conventions. Quels sont les outils qui permettent cette pratique ?

Outils d’écriture algorithmique

Il existe différents outils employés dans les processus de conception algorithmique. Ceux-ci présentent des points communs et des différences, et tous conditionnent le travail de programmation d’une manière qui leur est propre. Quels sont ces outils, ces interfaces, et quels sont leurs impacts sur la pratique du bricodeur ?

IDE et éditeurs de texte

On parle “d’environnement de développement” ou d’IDE pour désigner l’ensemble des outils employés par un programmeur pour développer un programme informatique. Un IDE est généralement un logiciel dont l’interface propose un ensemble d’outils et de fonctions : le plus généralement, on trouve un éditeur de texte où le programmeur saisit des lignes de codes. Celui-ci est généralement accompagné d’un debugger – pour débusquer et corriger les bugs – ou encore, si le langage l’implique, d’un compilateur – utilisé pour “traduire” le langage de programmation en langage machine, c’est-à-dire en instructions exécutables par l’ordinateur. Le choix de tel ou tel logiciel de programmation – de tel ou tel environnement – dépend généralement du langage utilisé dans le cadre d’un projet, ainsi que des goûts personnels du développeur. Certains outils, ayant une communauté plus active, se développent particulièrement grâce à la contribution collective – lorsque le logiciel est open-source – tandis que d’autres tombent en désuétude, les années passant et les technologies évoluant en conséquence.

La définition stricte d’IDE désigne donc ces outils composés, multiples, et les oppose aux simples “éditeurs de texte”. Un éditeur de texte – text editor en anglais – est un programme permettant l’écriture ou la modification de texte brut, c’est-à-dire dénué de mise en forme : ces logiciels utilisent souvent une typographie monochasse, permettant l’alignement vertical des caractères et favorisant ainsi la lisibilité du code. Les fonctions les plus courantes sont le copier/coller, la recherche et remplacement, la coloration syntaxique, etc. Par abus de langage, ces éditeurs de texte sont généralement inclus dans la définition au sens large d’IDE, à juste titre : ils font bel et bien partie de l’environnement de développement du programmeur.

Fig. 15 : Capture d’écran du logiciel de programmation Atom

Programmation visuelle

La programmation peut également prendre une forme graphique, visuelle. C’est le cas notamment des représentations algorithmiques en diagrammes, aussi appelées algorigrammes – ou flowcharts en anglais. Les instructions sont divisées dans autant de formes géométriques normalisées – un rectangle pour une opération, un losange pour un test, etc. – qui sont ensuite reliées entre elles pour symboliser l’enchaînement des instructions. Apparue il y a un siècle dans le domaine de l’ingénierie industrielle, cette représentation est utilisée dans certains logiciels de programmation comme Flowgorithm, qui est un intermédiaire entre la conception algorithmique visuelle et la programmation textuelle : le diagramme créé par l’utilisateur peut être traduit en un des langages de programmation les plus courants. Cette catégorie d’outils est notamment utilisée dans l’éducation, auprès de novices, afin de leur faire assimiler la logique sans introduire les langages de programmation comme difficulté supplémentaire.

Fig. 16 : Capture d’écran du logiciel Flowgorithm

La programmation visuelle peut aussi s’affranchir de la représentation normalisée d’un algorigramme. L’exemple le plus connu est le logiciel Scratch, développé par le MIT depuis une quinzaine d’années. Scratch propose de voir la programmation algorithmique comme un jeu de puzzle, constitué de “blocs” représentant chacun un type d’opération particulier, imbriqués pour constituer la structure du programme. Son interface simple et colorée et son intuitivité en font l’outil parfait pour les plus jeunes créatifs, et un excellent moyen d’appréhender la réflexion logique et mathématique.

Fig. 17 : Capture d’écran du logiciel Scratch

Workflow : l’outil adapté à l’usage

Les méthodes de travail d’un développeur sont souvent bien maîtrisées. On parle de workflow – “flux de travail” – pour désigner les méthodes d’organisation systématiques qu’il applique afin de fluidifier le processus de programmation et de se prévenir de complications diverses – notamment lorsque d’importantes quantités de données sont manipulées, et que l’erreur humaine peut intervenir à tout moment. Une des solutions les plus couramment appliquées de nos jours est la gestion de versions – le versionning en anglais. J’ai déjà mentionné le logiciel git, qui permet d’enregistrer des points clés – des commits – dans l’avancement d’un projet numérique. Pour comprendre la valeur de cette méthode, il faut noter la nature spécifique de l’écriture algorithmique. À l’image de l’auteur qui écrit un paragraphe, revient en arrière, effectue des modifications le lendemain et finit par rayer des passages, le développeur a une écriture non linéaire. Les commits assurent une traçabilité de cette évolution d’un projet dans le temps, et permettent de revenir à une version antérieure lorsque l’on fait fausse route. Les outils de programmation, mais également les plateformes d’hébergement comme GitHub par exemple, permettent de comparer deux versions d’un même extrait de code en visualisant leurs différences, grâce aux diffs : les parties ajoutées sont surlignées en vert, les parties supprimées en rouge.

Fig. 18 : Visualisation d’un diff sur GitHub

Par ailleurs, lorsqu’on souhaite aborder une nouvelle fonctionnalité ou une modification majeure au sein d’un projet, on utilise un principe de branches : créer une branche signifie diverger de la version principale, et continuer à travailler sur une version différente. Tout comme on peut revenir en arrière dans son travail grâce aux commits, on peut passer librement de branche en branche, afin de travailler sur des fonctionnalités en parallèle tout en conservant une autonomie totale de chaque branche : indépendantes, elles n’entrent pas en collision les unes avec les autres. Elles peuvent cependant être fusionnées à n’importe quel moment, afin par exemple d’appliquer les modifications apportées par une branche à la version principale du projet. Les outils de gestion de versions sont donc particulièrement adaptés aux méthodes de travail spécifiques des développeurs, mais qu’en est-il des méthodes de travail du bricodeur ?

On peut observer différents modes de travail chez les développeur comme chez le créatif, ainsi que dans les profils mixtes qui s’inscrivent entre les deux. Un premier mode est celui de l’efficacité : il s’agit de planifier, de procéder avec méthode, de chercher des solutions techniques avec un objectif fonctionnel précis, d’optimiser, de rationaliser. On trouve à l’opposé une démarche plus créative, basée sur l’expérimentation : il est question d’ouverture, on cherche des alternatives, propose des hypothèses, les abandonne, y revient plus tard. Dans un logiciel de création graphique classique, le créatif crée des formes, les duplique pour les modifier individuellement, déplace, rapproche, réutilise des éléments… Comment le bricodeur pourrait-il s’adapter à la logique de git dans son processus créatif ? Ou, plus intéressant encore, comment la logique de git pourrait s’adapter au processus créatif du bricodeur ? Cette question me laisse imaginer une interface permettant de visualiser différentes versions, différentes propositions envisagées par le créatif, et de naviguer entre elles. Et en s’écartant de git, la question reste centrale : comment la programmation algorithmique en général peut-elle se singulariser afin de s’adapter aux spécificités du processus créatif propre au bricodeur ?

Modes singuliers de programmation algorithmique

Lorsqu’un designer utilise la programmation dans une recherche formelle ou conceptuelle, il adopte une démarche créative qui bouscule le matériau qu’est l’écriture algorithmique : le créatif a une pratique singulière du code, ses outils doivent donc être adaptés à cet usage, voire le favoriser.

Pratiques singulières

Comment s’émanciper de la programmation “classique” ? Quelles sont les pratiques singulières du code, à la fois champ de questionnements et méthodes de recherche pratique de ce mémoire ? Comment le designer se comporte-il face au code, avec sa capacité à remettre en question des acquis ? Voici quelques éléments de réponse.

Le code auto-modifiant

Et si le code n’était plus seulement clos, modifiable uniquement par l’homme en vue d’un résultat externe, mais qu’il accueillait lui-même un résultat, une modification ? Qu’adviendrait-il d’un programme capable d’éditer sa propre teneur, avant de s’exécuter à nouveau en prenant en compte les modifications apportées ?

Cette idée m’a inévitablement motivé à me lancer dans une expérimentation fonctionnelle. C’était sans compter la complexité technique et intellectuelle d’un tel programme, comme l’expliquent Geoff Cox, Alex McLean et Adrian Ward dans un article paru dans Art++, intitulé “Praxis de la programmation : reconsidérer "L’esthétique du code génératif"”.

Dans notre exemple […], un éditeur de texte produit un code qui a la propriété de se modifier lui-même durant son exécution. […] Bien entendu, cela a des répercussions majeures sur l’acte de programmation. Le programmeur doit à présent réfléchir non seulement à ce que le logiciel fera et à la façon dont il interagira, mais aussi à la façon dont il se modifiera tout en restant fonctionnel et actif. Un code qui réfléchit à sa propre création ne peut être considéré comme un simple outil – il est réflexif.⁶⁷

Par complexité technique et intellectuelle, j’ai donc abandonné cette expérimentation, tout en gardant à l’esprit la particularité de cette démarche, et l’idée d’un outil s’auto-façonnant.

Langages ésotériques

Il existe une catégorie de langages de programmation tout à fait particulière, celle des langages dits “ésotériques”, parfois appelés langages exotiques – esoteric languages en anglais, ou esolangs dans la forme contractée. Le terme “ésotérique” désigne une forme d’enseignement secret ou hermétique, réservé à des initiés. En effet, qu’ils se présentent comme des œuvres logicielles, des exercices intellectuels ou même de simples plaisanteries⁶⁸, ces langages nécessitent une certaine maîtrise antérieure des langages de programmation classiques pour être compris, voire manipulés. Parmi les plus connus se trouve le Brainfuck : en n’employant que 8 caractères distincts, ce langage amène à produire du code particulièrement obfusqué.⁶⁹ Un autre exemple particulièrement intéressant d’esolang est le Piet, nommé d’après le célèbre peintre néerlandais Piet Mondrian. Ce langage n’est pas textuel mais graphique : les programmes prennent la forme d’images semblables à de l’art abstrait – librement inspiré des travaux du peintre éponyme.

Fig. 19 : Exemples de langages ésotériques

Ici, l’écriture algorithmique n’est plus seulement un outil au service de la création d’une œuvre, mais elle est une œuvre en soi⁷⁰ : l’opération devient l’opus. D’aucuns affirmeraient que le code étant une production humaine, sa pratique est nécessairement créative, voire artistique : cette thèse soulève des considérations esthétiques, qui m’intéressent naturellement en tant que designer.

Esthétiques du code

Qu’est-ce que le “beau” code ? Beau code, bon code, code propre… Ces adjectifs font partie du langage du programmeur, mais font référence à un type de “beau” bien précis : on parle ici en réalité de code astucieux, bien pensé, réfléchi. Dans Art++, l’informaticienne Sylvie Tissot est interrogée sur sa définition d’un “beau” programme, elle cite un certain nombre de principes qui permettent d’évaluer la qualité d’un programme : une condition “si” doit toujours être suivie d’un “sinon”, les sorties exceptionnelles – type exit – sont prohibées, la limite d’imbrication de conditions ou de boucles est fixée à 7, etc.⁷¹

Mais l’exemple cité plus haut des langages ésotériques peut aussi répondre au qualificatif de “beau” code – non pas sur un plan intellectuel, mais émotionnel. Le code poétique est, par ce statut, une forme de beau code.⁷² On distinguera ici deux catégories : l’art logiciel – software art – et l’art algorithmique, aussi appelé art génératif. Le discernement est fait à deux reprises dans l’ouvrage Art++, d’abord par le chercheur doctorant en littérature Florian Cramer dans son article “Dix hypothèses au sujet de l’art logiciel”. La sixième est intitulée “L’art logiciel n’est pas synonyme d’art algorithmique”. Il cite d’abord l’artiste chercheur Philip Galanter pour clarifier la notion d’art génératif.

L’art génératif renvoie à toute pratique artistique dans laquelle l’artiste crée un processus […] mis en œuvre ensuite avec un certain degré d’autonomie et contribuant ou aboutissant à une œuvre artistique achevée.⁷³

Puis, Florian Cramer compare cette définition avec celle de l’art logiciel et montre ainsi leur écart.

L’art logiciel, pour sa part, ne satisfait pas aux critères de l’art génératif, ou du moins n’est en mesure d’y satisfaire que dans un sens métaphorique et non technique, c’est-à-dire lorsqu’il produit un logiciel dysfonctionnel et imaginaire. C’est le cas des codeworks⁷⁴, par exemple.

Plus loin dans l’ouvrage, il reprend et approfondit cette distinction dans un chapitre au titre sans équivoque : “Art génératif ≠ Software art”. Il le conclut à l’aide d’un tableau comparatif⁷⁵ que je synthétiserai ici.

Art génératif	Software art
S’attache avant tout à la surface créée par un processus génératif.	S’attache au processus génératif susceptible de générer des surfaces ou d’autres résultats.
Considère le logiciel comme un outil pragmatique/neutre servant à produire un certain résultat : l’outil lui-même n’est pas questionné.	Aborde le logiciel comme une culture qu’il s’agit de questionner ; s’intéresse aux significations esthétiques et politiques sous-jacentes ; le logiciel peut être “expérimental” et “non pragmatique”.
Le logiciel en tant qu’outil pragmatico-génératif.	Le logiciel ou le code en tant qu’œuvre à part entière (éventuellement expérimentale).
Code efficace (“de beaux algorithmes”).	Le code comme excès, le code comme extravagance, pas nécessairement efficace.
Fascination du génératif.	S’intéresse à la “performativité” du code.

Le code assume donc un double rôle : il est à la fois outil et matière. Or, ces deux notions se rapportent à une dimension physique, tangible : l’outil et la matière sont manipulés. Ce terme, dont l’étymologie latine manipulare signifie “conduire par la main”, implique donc une première définition liée au fait de manier une substance ou un instrument, en vue d’une opération technologique ou scientifique. Au sens figuré, manipuler peut également désigner un ensemble d’actions mené sur quelque chose – ou le plus souvent, quelqu’un – par des moyens détournés, occultes, voire suspects, pour l’amener à ce qu’on souhaite. Enfin, on peut considérer que ce qui peut être manipulé est donc tangible, vérifiable.⁷⁶ Comment manipule-t-on, au sens physique, l’outil-matière algorithmique ?

Programmation tangible : la réflexion par la main

En déportant la réflexion distanciée qu’implique l’usage d’une interface – métaphorique – de programmation classique, à une manipulation – non métaphorique – plus directe, tangible, on permet une nouvelle façon de penser et d’imaginer des options créatives : on ne pense pas de la même manière avec sa tête ou avec ses mains. Le philosophe français Henri Bergson soulignait d’ailleurs dans son “Essai sur les données immédiates de la conscience”, la place centrale de la manipulation dans un processus scientifique – par exemple une création algorithmique.

Il est de l’essence de la science, en effet, de manipuler des signes qu’elle substitue aux objets eux-mêmes.

Cette notion de manipulation est la genèse d’un projet intitulé Dynamicland⁷⁷, initié notamment par Bret Victor⁷⁸. Dynamicland est un concept d’ordinateur alternatif, nouveau médium informatique collaboratif, où les utilisateurs travaillent à plusieurs en manipulant des objets physiques réels plutôt que des objets virtuels au travers d’écrans.

Pas d’écrans, pas d’appareils. Simplement des matériaux physiques ordinaires – papier et pâte à modeler, jetons et voitures en plastique – rendus vivants grâce à une technologie dissimulée au plafond. […] Dynamicland est un ordinateur avec lequel on travaille ensemble, en face-à-face, les yeux dans les yeux et avec les mains – beaucoup de mains. […] On pense avec nos mains. On pense avec nos corps. On s’étale, on se déplace, on compare différentes possibilités. On improvise, on expérimente, avec tout.

Fig. 20 : Des utilisateurs interagissant avec Dynamicland

Dans le cas de Dynamicland, on manipule des objets, captés par des caméras et reconnus grâce à un système de points colorés : ils sont ainsi interprétés par des algorithmes “classiques”.⁷⁹ Si le mode d’interaction est nouveau, la matière algorithmique, dissimulée, n’est pas directement tangibilisée et manipulée. Quelle forme prendrait un langage de programmation tangible ? Le collectif d’arts numériques transdisciplinaire [foam] propose une réponse : ils travaillent en 2017 sur une installation nommée “Pattern Matrix”, qui n’est autre qu’un langage de programmation matériel, tangible. Celui-ci a littéralement été créé de toutes pièces : on opère l’installation en tournant une série de “jetons” qui cachent des senseurs magnétiques. Des informations visuelles sont superposées grâce à la réalité augmentée, permettant de visualiser – et ainsi de comprendre – les états de chaque composant et les échanges qui s’exercent entre eux. Un premier essai du dispositif a été fait dans le cadre d’une performance musicale live à Brighton : bien qu’expérimentale et particulièrement singulière, cette interface-outil peut nourrir une pratique créative.⁸⁰

Fig. 21 : Pattern Matrix, un langage de programmation tangible

Je me suis interrogé sur la nature qu’aurait une interface de programmation “hors de l’écran”, au travers d’une expérimentation mettant en jeu la manipulation : en utilisant la surface tactile d’un smartphone, et en transmettant les données en temps réel à un ordinateur connecté, un algorithme de reconnaissance de formes permet de comprendre une forme “tracée” du doigt, et attribuée à une fonction précise. Par exemple, le dessin d’une boucle peut faire apparaître une boucle itérative dans le code, ou l’exécuter de façon éphémère. On peut également faire réagir des variables ou des objets virtuels grâce à cette interaction : modification d’une valeur, déplacement dans un espace en deux ou trois dimensions. On peut également tirer parti des fonctionnalités technique du smartphone, notamment l’accéléromètre et le gyroscope. L’appareil devient alors une extension de l’interface de programmation, à l’instar d’une télécommande programmable.

Modes de représentation

Les différents modes de représentation des algorithmes permettent donc de s’emparer de la programmation comme matière. Quels écarts de perception existent entre la lecture d’un algorithme au sein d’un éditeur de texte, la visualisation de sa transcription visuelle, ou encore la manipulation, simulée ou tangible, de celui-ci ?

Représenter les algorithmes

La représentation visuelle d’un processus algorithmique permet d’appréhender l’algorithme en question d’une manière plus intuitive, car sensorielle, que dans le cas d’une lecture réfléchie du code. Dans le monde scientifique et informatique, c’est un véritable exercice de style. Ces visualisations permettent en effet de comprendre en profondeur la démarche et l’efficacité d’un algorithme pour répondre à un problème donné : génération aléatoire de points dans un espace, tri de données⁸¹, pathfinding – recherche du chemin le plus rapide entre deux points –, etc. Le designer de visualisations Michael Bostock illustre ces exemples au sein d’un article intitulé Visualizing Algorithms. Il cite en introduction le professeur en sciences cognitives Donald Norman, qui témoigne de l’importance de ces outils qui “aident” à la compréhension :

Les capacités de l’esprit sans aide extérieure sont fortement surestimées. Les facultés réelles proviennent de la conception d’aides externes qui améliorent les capacités cognitives.

Dans un essai intitulé “Learnable Programming”⁸², Bret Victor réfléchit au design de systèmes de programmation permettant de mieux comprendre les programmes. Il introduit son propos avec une théorie qui rejoint celle de Donald Norman :

On comprend ce que l’on peut voir. Si un programmeur ne peut pas voir ce qu’un programme est en train de faire, il ne peut pas le comprendre.

Cet essai est donc construit autour d’une question au cœur de mon sujet : comment peut-on voir le résultat de ce que l’on code, au moment exact où on le code ?

Visualiser au sein de l’IDE

Dans une conférence donnée au CUSEC de 2012, Bret Victor dénonce le délai, qui, dans un processus créatif, peut séparer l’apparition d’une idée et sa matérialisation.

Il est essentiel, dans un processus créatif, de pouvoir essayer une idée à l’instant où l’on y pense. S’il y a le moindre délai dans cette boucle de feedback⁸³ entre la conception d’une chose, sa visualisation et sa réalisation, alors un monde entier d’opportunités créatives disparaît. Ce sont des pensées que l’on ne peut penser.⁸⁴

Pour illustrer son propos, Bret Victor prend l’exemple d’un dessin algorithmique, programmé en JavaScript et restitué visuellement dans un canvas – une toile numérique – au sein d’un explorateur web.

Voici comment fonctionne la programmation : vous tapez un tas de code dans un éditeur de texte, en essayant d’imaginer ce que chaque ligne de code va faire. Puis, vous compilez et exécutez ce code, et quelque chose en sort. […] Mais s’il y a une erreur, ou si vous souhaitez faire des modifications, vous devez retourner dans le code, le modifier, compiler et exécuter à nouveau, et voir à quoi il ressemble. La majeure partie de ce processus se passe dans l’éditeur, où l’on travaille aveuglément, sans connexion immédiate avec ce que l’on cherche réellement à produire.⁸⁵

Victor dénonce ici ce que l’on pourrait qualifier de “niveau zéro” de la créativité algorithmique : lorsque la conception et la réalisation d’une œuvre implique de passer constamment du code au résultat, cela impose un délai dans le feedback, et la fluidité que suppose une démarche créative en est mécaniquement impactée. Il propose donc une interface binaire, scindée verticalement : à gauche le résultat, à droite l’éditeur de texte avec le programme. Lorsqu’on modifie une ligne ou une valeur dans le code, le résultat est directement visible, en temps réel – en cela, sa proposition ressemble beaucoup à Processing. L’expérience de la programmation est améliorée, facilitée : on est au “niveau un”. Un autre exemple pourrait être celui de la superposition du code et du résultat, comme le propose VedaJS, un framework⁸⁶ adapté à la création de shaders – images de synthèse simulant graphiquement de la lumière, des textures et des animations.

Manipuler au sein de l’IDE

Mais Bret Victor va plus loin que la simple juxtaposition du programme et du résultat produit. Pour simplifier l’édition des valeurs – notamment chiffrées – utilisées dans un algorithme, il propose un nouveau type d’interaction : au lieu de devoir effacer des caractères pour les remplacer, chaque valeur devient draggable⁸⁷, ce qui permet de faire évoluer ces variables. On peut également modifier les couleurs via une palette. Cet usage innovant est aussi disponible dans Processing via le mode “Tweak Mode”, ainsi que dans la librairie JavaScript dat.GUI⁸⁸ pour un usage sur le web.

Dans sa conférence Inventing on Principle, Bret Victor applique cette interaction à une variable liée au positionnement des feuilles dans un dessin d’arbre. Cela permet de révéler une opportunité d’animation : en faisant varier en continu une valeur, les feuilles semblent s’agiter comme si le vent soufflait, et le designer souligne l’apparition d’un nouveau champ de possibles créatifs : “comment aurais-je découvert cela si j’avais dû compiler et exécuter le code entre chaque changement ?”.

Bret Victor propose en ce sens diverses interventions au sein d’outils de programmation dans son essai “Learnable Programming”, ponctué d’expérimentations démonstratives. Il conçoit de nombreuses fonctionnalités et autant d’interactions liées, qu’il illustre dans des vidéos que je présente en partie ici.

Fig. 22 : Mise en évidence du résultat précis d’une expression en la survolant

Fig. 23 : Exploration de l’exécution du programme à chaque étape grâce à un slider⁸⁹

Fig. 24 : Visualisation de l’évolution dans le temps du programme, via une timeline – frise chronologique – interactive

Fig. 25 : Auto-complétion⁹⁰ des expressions et fonctions fréquentes, avec valeurs par défaut

Fig. 26 : Mise en relation des variables par drag and drop – glisser-déposer – et création de fonctions et introduction de variables “intelligentes”

Bien d’autres micro-interactions sont à découvrir dans son article illustré. Dans un registre similaire, le développeur indépendant de jeux vidéo et d’expériences interactives Nicky Case travaille en 2017 sur JOY.js, une interface qui propose de manipuler et visualiser des algorithmes en langage JavaScript grâce à un éditeur de texte interactif et une visualisation en temps réel. En survolant du haut vers le bas le numéro d’une ligne initiant une boucle, on peut par exemple avancer pas à pas dans les itérations. De plus, chaque paramètre survolé dans le code “vacille” pendant une demi-seconde – elle varie légèrement, positivement et négativement – afin de montrer immédiatement son impact dans le dessin final.

Fig. 27 : JOY.js, un outil interactif de manipulation de programmes JavaScript

Ces interactions concordent avec deux observations énoncées plus haut : on comprend ce que l’on peut voir, mais on comprend aussi ce que l’on peut manipuler⁹¹. Et c’est précisément en comprenant le comportement de son programme que le bricodeur gagne un plus grand contrôle sur le résultat qu’il cherche à produire : en quelque sorte, l’outil est là pour lui simplifier la tâche, mais également pour lui ouvrir des possibilités créatives.

Deux typologie d’outils

On distingue donc deux catégories, deux typologies d’outils, dont un grille de lecture peut être donnée selon leur façon de conditionner le travail :

• l’outil qui “se rapproche”, s’adapte, simplifie, rend plus efficace le travail du programmeur ;
• l’outil qui “s’éloigne”, nous déplace, incite, invite à une découverte des potentiels créatifs, nous permet de comprendre mieux et d’imaginer autrement.

Outils qui se rapprochent

Les éditeurs de texte les plus connus, comme Atom ou Sublime Text, empruntent aux IDE leur capacité à être un outil professionnel, utilisé par des développeurs. En questionnant sur Twitter des développeurs et bricodeurs sur les fonctionnalités qu’ils préfèrent au sein de leur outil, j’ai pu discerner plusieurs catégories : l’efficacité, la personnalisation, et la polyvalence. Je détaille ce-dessous ces trois notions et cite quelques verbatim.

L’efficacité se mesure par l’emploi de raccourcis claviers et de méthodes d’auto-complétion, qui permettent d’aller plus vite dans l’écriture du code ou de naviguer entre les différents fichiers qui composent un projet.

Le gros plus : les raccourcis pour les codes de base sur NetBeans :
“sout” + tab => System.out.println("");
“fori” + tab => for (int i = 0; i < t.length; i++) { … }
– @AntoineKia

La faculté de Vim à se déplacer précisément à n’importe quel endroit d’un document en quelques frappes du clavier.
– @GeoffreyFrogeye

Le “Ctrl + clic” pour la redirection vers les variables, objets ou fonctions directement dans le bon fichier !
– @Sacha_Roxas

La notion de personnalisation, ou customisation, est liée à la faculté d’un outil à intégrer des plugins, des extensions permettant d’avoir accès à un nouveau lot de fonctionnalités. Outre ces plugins, on retrouve également cette notion de personnalisation dans les paramètres généraux de ces outils : la plupart d’entre eux permet de définir ses préférences liées à l’affichage de l’interface, l’écriture d’un document, et plus encore.

J’adore les plugins Electron de customisation de l’éditeur comme VedaJS, l’exécution de script depuis l’éditeur, l’intégration de GitHub, tout depuis l’éditeur…
– @MAKIO135

Le retour d’expérience ci-dessus fait également état de la polyvalence de l’outil, qui s’observe lorsque celui-ci intègre des fonctionnalités a priori externes directement en son sein – exécution d’un script depuis l’éditeur, panneau git au sein de l’interface, etc.

J’aime bien aussi une bonne intégration de git, et un bon terminal dans l’UI.
– @Stoltheds

J’ai questionné la notion d’auto-complétion avec une maquette d’un éditeur, suggérant la suite d’une ligne alors qu’elle est tapée. Ici, j’imagine que l’outil “comprend” que l’on souhaite créer une condition liée à une variable nommée i, et qu’il propose naturellement la valeur suivante par rapport à la condition exprimée au dessus – après 1 vient 2.
Fig. 28 : Maquette d’autocomplétion else/if

Outils qui s’éloignent

Processing, Scratch ou encore Flowgorithm sont des exemples d’outils alternatifs, qui permettent de penser le code différemment. En proposant une visualisation et une manipulation virtuelle du code à produire, ils permettent au créatif d’accéder non seulement à une compréhension accrue de l’algorithme, mais à un monde de nouvelles possibilités créatives : c’est la thèse de Bret Victor, et l’objectif précis des outils qu’il crée lui-même.

J’ai donc cherché à m’inspirer de ses expérimentations, données en exemple plus haut, pour produire moi-même de nouvelles façons de visualiser et manipuler le code. J’imagine un plugin pour l’éditeur de texte Atom, permettant l’affichage d’un panneau intitulé “Visual hints” – indices visuels. Celui-ci donne à voir différentes notions de programmation relativement complexes à se figurer, et permet leur manipulation via diverses interactions.

J’ai d’abord traité l’affectation de variable, afin de prévoir une valeur en fonction des valeurs qui composent son calcul. Ici, la variable freq dépend de la valeur de a, je propose donc une courbe dans un repère orthogonal. On peut faire varier a grâce à un slider, choisir les valeurs minimale et maximale de cette variation au clic – ici 0 et 1 –, et survoler la courbe pour obtenir les valeurs de a sur l’axe des abscisses, et freq sur l’axe des ordonnées. On remplace donc le calcul mental par une visualisation interactive.
Fig. 29 : Maquette d’un outil de visualisation d’affectation de variable

Une deuxième maquette porte sur la notion de concaténation : il s’agit de la juxtaposition de plusieurs chaînes de caractères pour n’en former qu’une seule. Cet exercice peut être difficile en raison de la rigourosité syntaxique du code : le moindre caractère manquant produira une erreur. Ici, une boucle à sept étapes génère une expression d’une couleur au format HSL⁹². Les sept expressions concaténées sont retranscrites dans un tableau afin de s’assurer de leur validité, et les sept couleurs produites sont prévisualisées via une pastille – on imagine que les expressions de couleur sont ainsi reconnues et interprétées. Je propose également un cercle chromatique permettant de comprendre la répartition des couleurs en fonction de l’angle donné.
Fig. 30 : Maquette d’un outil de visualisation de concaténation de chaînes de caractères

Une troisième recherche porte sur les boucles et conditions imbriquées. Le code ci-dessous génère un tableau en deux dimensions via l’imbrication de deux boucles – une pour les lignes, une pour les colonnes –, et une série de conditions avec quatre valeurs potentielles détermine la valeur de chaque cellule : 64 possibilités sont ainsi générées. Pour naviguer dans ces options, je propose une série de quatre tableaux, chacun correspondant à une option de la chaîne de conditions, dépendant ici de r. Les cellules peuvent ainsi être survolées pour afficher l’expression du calcul de leur valeur avec un maximum de variables remplacées par leur valeur dans cette configuration. En survolant une cellule précise d’un des tableaux board, la cellule concernée est mise en évidence dans le tableau this.data.
Fig. 31 : Maquette d’un outil de visualisation de boucles et conditions imbriquées

Conclusion

Plusieurs questions ont été soulevées dans ce mémoire, mais toutes s’articulent autour d’une problématique commune : comment faciliter et encourager l’intégration de processus algorithmiques dans une pratique créative ? D’abord, la programmation s’inscrit en tant qu’outil, qui lui-même génère des outils : la pratique du code permet au bricodeur de concevoir ses propres outils, sous forme d’interfaces de création, de procédés liés à des données en temps réel ou encore de génération algorithmique. Cette capacité à programmer un outil offre un plus grand contrôle sur l’œuvre produite, l’auteur de l’algorithme pouvant à sa guise modifier les paramètres qui interviennent dans le procédé créatif. En intégrant des processus algorithmiques dans sa pratique, le designer-codeur donne donc lieu à de multiples possibilités créatives.

Bien sûr, cette pratique demande une connaissance suffisante de la programmation : la manipulation des algorithmes est régie par des langages et des règles incontournables, afin de communiquer des instructions à la machine informatique. Une certaine maîtrise de l’écriture algorithmique est donc nécessaire, tout comme la maîtrise d’un métier Jacquard est nécessaire à son usage.

Mais le code n’est pas qu’un outil, il est également un matériau à traiter, voire à jouer. À titre comparatif, si le designer graphique a pour matériau la couleur, la typographie ou encore la composition, et si le designer de produits a pour matériau les formes et les matières, il semble cohérent d’avancer que le bricodeur a, de la même manière, la programmation pour matériau. En percevant ainsi la pratique de l’écriture algorithmique, le créatif peut s’affranchir de certaines conventions, et proposer des approches singulières. En remettant en question la neutralité initiale du code, le créatif insuffle une notion esthétique dans ce matériau. Déjà présente dans la production finale d’un art dit “algorithmique”, qui traite exclusivement le logiciel comme outil, elle l’est à présent également dans le matériau initial : on parle alors d’art logiciel, où le code est perçu comme œuvre à part entière.

Les outils du bricodeur doivent donc être polyvalents et adaptés à leur utilisateur. Ils doivent d’une part correspondre à son niveau technique, en représentant les algorithmes de façon à faire disparaître la latence dans la boucle de feedback, et en proposant des interactions qui permettent de manipuler, virtuellement ou physiquement, la matière algorithmique. D’autre part, ces outils ne doivent pas obstruer de pistes créatives, mais au contraire en favoriser, par les visualisations et manipulations qu’ils permettent. L’outil conditionne la pensée de l’utilisateur : un outil de créativité doit donc seconder et nourrir une pensée libre et inventive. On distingue alors deux types de réponses possibles : celle des interfaces qui se “rapprochent” de la pratique pour en favoriser la maîtrise, et celle des interfaces qui “s’éloignent” des modes classiques de représentation afin d’alimenter cette créativité.

Ressources

Bibliographie

1

2

3

6

7

8

9

10

11

12

13

Webographie

Awesome Algorithms, liste collaborative, GitHub

14

19

20

21

22

Remerciements

Ce mémoire n’aurait pas été possible sans l’implication de mes tuteurs, Jean-Baptiste Joatton et Guillaume Giroud. Je tiens à les remercier grandement pour leur aide, leur expertise et leurs précieux conseils tout au long de ma recherche.

Je remercie également l’ensemble de l’équipe pédagogique du DSAA pour leur accompagnement, et celle du Pôle Supérieur de Design plus généralement pour ces cinq années où j’ai pu m’épanouir pleinement en découvrant le métier de designer.

Enfin, je remercie ma famille pour leur présence indéfectible et mes camarades de promotion sans qui, assurément, mes études n’auraient pas eu la même saveur.

À propos

Ce mémoire a été rédigé en Markdown grâce à l’application web StackEdit, et publié régulièrement sur GitHub pour assurer la conservation d’un historique de versions. Les caractères utilisés sont Source Sans Pro et Source Code Pro, dessinés par Paul D. Hunt. Le choix d’une publication web plutôt qu’imprimée a non seulement été motivé par le sujet même de cette recherche, mais s’inspire également des thèses d’Anthony Masure et de Nolwenn Maudet. La mise en page reponsive – adaptée à toutes les tailles d’écrans – a été réalisée en HTML et CSS, et les interactions en JavaScript et jQuery avec l’éditeur de texte Atom : il est possible de changer la taille du texte à la convenance du lecteur, et également de passer en mode "nuit" pour une lecture plus confortable dans un environnement sombre.

---

1. Alan Cooper, développeur américain reconnu pour ses travaux effectués dans le champ du design UX, donne son avis sur le sujet dans un article intitulé “Should Designers Code?”. Il explique surtout pourquoi la question n’est, selon lui, pas vraiment pertinente : dans ce débat, il est moins question de vérité absolue que de goût personnel. ↩︎

2. Serge Abiteboul et Gilles Dowek sont chercheurs à l’INRIA et professeurs à l’ENS de Paris-Saclay. ↩︎

3. 1:11 ↩︎

4. La recherche par force brute (brute force en anglais), aussi connue sous le nom “générer et tester” est une technique générale de résolution de problème qui consiste à énumérer tous les candidats possibles à une solution et vérifier chacun d’eux afin de déterminer lequel répond le mieux au problème. ↩︎

5. Le sociologue français Dominique Cardon propose une classification des typologies d’algorithmes qui régissent notre quotidien – notamment sur le web. Il distingue quatre familles, qu’il illustre spatialement : “les mesures peuvent se trouver à côté, au-dessus, dans ou en dessous des données numériques”. 2:17–18 ↩︎

6. Divers exemples d’algorithmes d’intelligence artificielle dans le design sont énumérés sur le site algorithms.design. ↩︎

7. Le creative coding – ou “code créatif” – est un type de programmation informatique où les langages de programmation sont employés à des fins d’innovation expressive – souvent esthétique – plutôt que fonctionnelle. ↩︎

8. 11:328 ↩︎

9. 12:29–30 ↩︎

10. 12:27 ↩︎

11. Le terme “matériau” suggère ici une relation de proximité : en se rapprochant du fonctionnement et de la logique d’un algorithme, le bricodeur a une meilleure capacité à le façonner, le transformer, l’adapter selon ses envies. ↩︎

12. Le MIT est un institut de recherche américain spécialisé dans les domaines de la science et de la technologie. ↩︎

13. Design by Numbers, (parfois noté DBN), est une expérimentation logicielle menée par John Maeda et ses étudiants du MIT en 1999. Il s’agit d’un outil de conception graphique par le code : les choix (formes, tracés, positionnements…) sont matérialisés par une succession d’instructions algorithmiques. ↩︎

14. Processing est un langage de programmation intégré à un IDE, initié au MIT en 2001 par Casey Reas et Ben Fry – deux élèves de John Maeda. ↩︎

15. 10:10–11 ↩︎

16. 13:25 ↩︎

17. Par faciliter, j’entends “aider en rendant plus facile” : il s’agit d’ôter les éventuels obstacles ou difficultés qui pourraient empêcher la réalisation d’une chose. ↩︎

18. Par encourager, j’entends le fait de donner le désir et les moyens d’entreprendre une action, soutenir quelqu’un dans une démarche intellectuelle ou morale. ↩︎

19. Par abus de langage, et en raison de notre contexte technologique contemporain, la notion d’algorithmes symboliques a presque remplacé celle, plus générique, d’algorithmes : l’informatique a orienté l’emploi même du mot. ↩︎

20. Étymologiquement, le terme algorithme est d’ailleurs issu de la combinaison du mot grec arithmos, qui signifie “nombre”, et du mot latin algorismus, dérivé du nom du mathématicien Al-Khwarizmi – scientifique perse du VII^ème siècle, auteur d’un ouvrage classifiant les procédés algébriques de son époque. ↩︎

21. 24:6–8 ↩︎

22. 1:18–19 ↩︎

23. On pourrait d’ailleurs s’interroger sur ce qu’il adviendrait d’un algorithme lu à l’envers… ↩︎

24. Un booléen est un type de variable à deux états. Cette terminologie fait référence aux travaux de George Boole, célèbre logicien et mathématicien britannique, qui en 1845 a établi les bases de la “logique booléenne”, n’acceptant que deux valeurs numériques : 0 et 1. Cet algèbre connaîtra une importance capitale dans l’informatique et est encore énormément employée de nos jours. ↩︎

25. Le terme abaque désigne tout instrument mécanique plan facilitant le calcul. ↩︎

26. Blaise Pascal était un mathématicien, physicien, inventeur et philosophe français. À 19 ans, il invente la première machine à calculer, dénommée machine d’arithmétique, puis pascaline. ↩︎

27. Gottfried Leibniz était un philosophe, scientifique, mathématicien et logicien allemand. ↩︎

28. Le bit, abréviation de binary digit (chiffre binaire) est l’unité d’information la plus basique : un chiffre binaire ne peut avoir que deux valeurs, et ainsi être représenté avec un dispositif à deux états. Ces valeurs d’états sont le plus souvent représentées comme 0 ou 1. ↩︎

29. Charles Babbage était un mathématicien et inventeur britannique du XIX^ème siècle. Il fut l’un des principaux précurseurs de l’informatique. ↩︎

30. Machine analytique – Description et fonctionnement sur Wikipédia ↩︎

31. En mathématiques, les nombres de Bernoulli constituent une suite de nombres rationnels. Ces nombres ont d’abord été étudiés par Jacques Bernoulli, mathématicien et physicien suisse du XVII^èmesiècle. ↩︎

32. Alan Turing était un mathématicien et cryptologue britannique, dont les travaux ont fondé l’informatique moderne. Après l’invention de la machine de Turing – qui contribue à la thèse de Church-Turing autour de la notion de problème de calculabilité –, il participe au décryptage des codes secrets de la machine allemande Enigma pendant la Seconde Guerre Mondiale – ce qui joua un rôle essentiel dans la victoire des Alliés. Turing poursuit des recherches en informatique et formule le “test de Turing”, fondamental dans le champ de l’intelligence artificielle. ↩︎

33. 3:16–18 ↩︎

34. Architecture de von Neumann sur Wikipédia ↩︎

35. 23:2 ↩︎

36. 7:15 ↩︎

37. 7:26 ↩︎

38. 8:7–8 ↩︎

39. La notion de “signifiant et signifié” a été théorisée par le linguiste suisse Ferdinand de Saussure dans son ouvrage “Cours de linguistique générale”. Tel qu’il les définit, le signifié désigne le concept, et le signifiant désigne l’image sonore : de Saussure exclut donc les autres formes de représentation – graphique, gestuelle, etc. ↩︎

40. “Les systèmes d’écriture” sur BNF ↩︎

41. Le terme de composition, dont l’étymologie signifie “poser ensemble”, peut s’entendre dans deux sens : soit celui de faire un tout à partir d’éléments différents, soit celui d’accorder, de mettre en ordre. Ici, on suppose qu’il existe des règles de composition préalablement définies : un syntaxe permettant à la machine d’interpréter le code. ↩︎

42. Voici une liste non exhaustive énumérant quelques grandes catégories de genres littéraires : poétiques (poésies, poèmes, haïkus, chansons mais aussi calligrammes), narratifs (romans, comptes, nouvelles, biographie), théâtraux (pièces de théâtre de tous registres), épistolaires (constitués de lettres échangées), argumentatifs (essais, pensées ou même pamphlets), graphiques (roman graphique, bande dessinée), ou encore formes brèves (proverbes, aphorisme, énigme, blague, etc.) ↩︎

43. 8:10 ↩︎

44. Le groupe µ – prononcer “mu” – est un collectif interdisciplinaire de chercheurs en linguistique, sociologie ou encore sémiotique, fondé en 1967. ↩︎

45. Les auteurs décrivent quatre opérations fondamentales qui peuvent constituer une métabole : l’addition, la suppression, la substitution ou la permutation d’unités phonétiques ou morphologiques. Dagonet distingue ces “iconographies ordinatrices et inventives” d’une autre catégorie appelée “iconographies nouménalisantes et explicatives”, parmi lesquelles il compte notamment la représentation des molécules en chimie, ou le dessin des volumes géométriques. ↩︎

46. Voir quelques exemples visuels et animés sur le site ./code --poetry ↩︎

47. On distinguera la poétique de l’écriture du code – la manière de l’écrire, sa forme graphique de conditions imbriquées par exemple – et la poétique du code même – ce que fait le programme, ce que ces conditions imbriquées vont produire comme résultat. Dans les exemples cités ici, ces deux formes de “poésie algorithmique” sont volontairement couplées. ↩︎

48. 5 ↩︎

49. 3:67 ↩︎

50. Programme informatique sur Wikipédia ↩︎

51. 3:46 ↩︎

52. 4 ↩︎

53. What you see is what you get sur Wikipédia ↩︎

54. 25 ↩︎

55. Liste de langages de programmation sur Wikipédia ↩︎

56. Stack Overflow est une plateforme web où chacun peut poser des questions ou apporter des réponses sur de nombreux thèmes liés à la programmation informatique. Il fait partie du réseau de sites Stack Exchange, qui intègre de nombreux services basés sur le même principe d’entraide communautaire, dans des disciplines variées. ↩︎

57. “Why are there so many programming languages?” sur StackOverflow ↩︎

58. Quelques exemples : la programmation orientée objet, où l’on considère le programme comme une collection d’objets en interaction ; la programmation procédurale qui fait appel à une suite de fonctions ; la programmation déclarative qui consiste à déclarer les données d’un problème puis à le faire résoudre par le programme ; etc. On remarquera que certains langages mêlent plusieurs paradigmes : le JavaScript par exemple, créé en 1995 et aujourd’hui un des plus présents notamment sur le web, est multi-paradigme – il est à la fois orienté objet, impératif et déclaratif. ↩︎

59. GitHub Octoverse 2017 ↩︎

60. GitHub est une plateforme d’hébergement de gestion de versions collaborative. Basé sur le logiciel git, qui permet d’enregistrer des versions de son travail à différentes étapes de l’avancement du projet, GitHub est communautaire et chacun peut dupliquer le code d’autrui – si celui-ci est ouvert, ou open-source –, y apporter des modifications ou des remarques. ↩︎

61. Ces trois termes – construit, artificiel et formel – soulèvent trois notions. Pour le langage construit, on soulignera son aspect délibéré. Le langage artificiel s’oppose au caractère naturel – au sens de culturel, spontané –, il est donc élaboré. Enfin, le langage formel désigne une forme dénuée de contenu, c’est-à-dire de référence. Ainsi, tout langage artificiel n’est pas nécessairement formel, mais tout langage formel est nécessairement artificiel. ↩︎

62. Voir une démonstration en vidéo du prototype “text2code” sur Twitter, et les réponses à ce tweet : certains de mes contacts se sont emparés de mon expérimentation pour produire leur propre proposition. ↩︎

63. 9:395 ↩︎

64. Le choix entre espaces et tabulations pour l’indentation est depuis de nombreuses années sujet à débats dans la sphère informatique, chaque option ayant son lot d’avantages et d’inconvénients. Des tendances statistiques s’observent selon le langage utilisé, comme le montre une recherche menée sur GitHub. ↩︎

65. 3:39 ↩︎

66. Les plus connus sont le camelCase, le PascalCase et le snake_case, dont les intitulés même illustrent leur principe : des capitales au début de chaque mot – incluant ou non le premier –, ou des underscores entre les mots. ↩︎

67. 17:86–87 ↩︎

68. Le site esoteric.codes regroupe plusieurs exemples créatifs mettant en jeu des langages ésotériques. ↩︎

69. En programmation, “obsfuquer” signifie rendre un programme illisible, en transformant notamment le nom des variables afin de rendre la structure globale de l’algorithme incompréhensible et inexploitable. ↩︎

70. On retrouve d’ailleurs ici un effet similaire à la notion de littérature algorithmique et aux exemples de code poétique cités plus haut. ↩︎

71. 18:49 ↩︎

72. En mathématiques, on parle aussi de “belle” démonstration pour qualifier une preuve dont l’esthétique se caractérise par sa simplicité et son économie de moyens. ↩︎

73. 16:107 ↩︎

74. Le terme de codework – dérivé d’artwork, “œuvre d’art” en français – désigne une écriture poétique dont la syntaxe et le vocabulaire sont empruntés aux langages de programmation. Le projet Code Peoms du designer Ishac Bertran regroupe une série d’exemples de codeworks. ↩︎

75. 15:148–149 ↩︎

76. Une définition plus exhaustive comprend également un registre d’état qui mémorise l’état courant de la machine, ainsi qu’une table des transitions pour savoir si la tête de lecture doit aller à gauche ou à droite en fonction de son état et de la bande. ↩︎

77. Voir les vidéos sur le site Dynamicland. ↩︎

78. Bret Victor est un designer d’interaction et informaticien, dont le travail porte notamment sur les outils et les interfaces permettant de comprendre et de créer. ↩︎

79. Ici c’est la forme, la surface, voire la matière de l’interface qui change, mais elle demeure une interface directe, agissant sur une autre interface indirecte qui sera interprétée et retraduite par l’ordinateur. ↩︎

80. “How to design a tangible programming language” sur [foam] ↩︎

81. Les méthodes de tri – sorting algorithms – les plus connues sont illustrées sous forme d’animations sur la page Sorting Algorithms Animations du site d’offre d’emplois toptal. ↩︎

82. 14 ↩︎

83. Le feedback – “rétroaction” en français – est une forme de retour d’information qui, dans le contexte d’une interface numérique, permet à l’utilisateur de prendre conscience de la validité ou non de l’action qu’il entreprend. Ici, on entend plus généralement le terme feedback comme l’échange entre la machine et l’utilisateur. ↩︎

84. Bret Victor - Inventing on Principle sur Vimeo ↩︎

85. Bret Victor - Inventing on Principle sur Vimeo ↩︎

86. Un framework, ou “cadre de travail”, désigne un ensemble d’outils de programmation structurant les bases techniques et architecturales d’un projet. ↩︎

87. Le qualificatif draggable est ici utilisé comme dérivé de drag and drop – en français glisser-déposer. Un élément d’interface draggable a donc la faculté d’être déplacé à l’écran. Ici, les variables restent fixes, seule leur valeur change en fonction des mouvements de la souris. ↩︎

88. dat.GUI est une librairie JavaScript qui injecte une interface graphique de contrôle paramétrique au sein d’une page web. Le créateur d’une expérimentation graphique peut par exemple le mettre en place pour faire varier facilement les paramètres de son œuvre, mais également le diffuser tel quel afin que chacun puisse intervenir sur les contrôleurs. ↩︎

89. Un slider, ou “curseur de défilement”, est un composant d’interface graphique permettant de faire varier une valeur numérique en déplaçant un curseur sur une échelle graduée. ↩︎

90. L’auto-complétion – ou “complètement automatique” – est une fonctionnalité permettant à l’utilisateur de limiter la saisie, en se voyant proposer un complément qui pourrait convenir à la chaîne de caractères qu’il a commencé à taper. Ce principe est souvent rencontré dans les moteurs de recherches, qui affichent un certain nombre de suggestions à la suite des mots-clés tapés. ↩︎

91. Un des premiers défenseurs de cette thèse fut Ben Schneiderman, notamment dans son article Direct Manipulation paru en 1997. ↩︎

92. Le modèle HSL – pour hue saturation lightness, en français TSL, pour “teinte saturation luminosité” –, est un format d’écriture des couleurs. La teinte est donnée sous forme d’angle autour du cercle chromatique, et la saturation et la luminosité par un indice entre 0 et 100. ↩︎