1.1.1. Objets produits

10 L’algorithme est une formalisation. Mais, définir ce que l’algorithme formalise varie en fonction de l’utilisatrice. Les mathématiciennes y voient les fonctions récursives qui délimitent l’univers mathématique calculable, tandis que les logiciennes y voient des ensembles de relations, cette double perspective engendrant des débats poussés sur la nature des algorithmes (Naibo et Seiller, 2023). Les programmeuses manifestent des fonctions récursives et des relations entre objets à travers la manipulation de langages informatiques de plus ou moins haut niveau. Les designers manipulent ensuite les résultats de l’exécution de la production des programmeuses.

11 En miroir de l’influence d’Alexander sur le paradigme de la POO, la variabilité des objets produits à travers le logiciel se retrouve conceptualisée également dans le monde du design. Les objets conçus par Bernard Cache et Patrick Beaucé, sculptés à l’aide d’une fraiseuse numérique, tous différents et néanmoins obéissant aux mêmes principes géométriques et à la même logique de fabrication, sont baptisés objectiles par Gilles Deleuze, dans le but de saisir en un vocable cette malléabilité mathématique et géométrique (Deleuze, 1988 ; Cache, 1998). Robert Woodbury, d’autre part, définit ces objets par leur qualité paramétrique : ils relèvent de règles logiques définies par la conceptrice, ils sont modifiables en permanence et permettent donc le développement d’alternatives de conception parallèles au cours du processus (Woodbury, 2010). La confrontation répétée à la définition des propriétés des objets virtuels reflète la difficulté que représente le saut de l’objet conçu à l’objet physique dans le champ du design (Evans, 1995), et la navigation de l’un à l’autre qui est le propre de cette activité.

12 La difficulté de cette confrontation est renforcée par la variabilité des objets produits virtuels et la dissonance qu’elle crée non seulement avec l’objet physique figé ensuite matérialisé, mais aussi avec les traces matérielles conventionnelles des processus de conception algorithmiques : dessins, rendus, plans d’exécution. Cette variabilité se matérialise pourtant dans d’autres traces matérielles. Les modèles 3D paramétrables, à la géométrie en constante évolution possible, la capturent tout en la laissant difficilement visible. Logigrammes et pseudo-codes saisissent la logique de ces modifications, tout en demeurant peu visibles aux novices. Une trace matérielle se détache cependant, reflétant avec exactitude cette propriété nouvelle des objets produits algorithmiquement : le catalogue (Witt, 2021). Collection sans fin d’alternatives produites par les systèmes paramétriques, le catalogue se dévoile à travers les grilles d’objets diffusées en ligne et dans les présentations des projets. Matérialisation de la difficulté à figer en un seul objet produit final le processus de design, il constitue aussi une trace caractéristique des objets algorithmiques.

1.1.2. Environnements techniques

13 Se pencher de plus près sur les conditions de la programmation révèle les très nombreux objets matériels qui encadrent cette pratique.

14 Un vaste ensemble d’infrastructures techniques permet d’interagir avec le monde numérique : souris, claviers, stylets, écrans, cartes-mères. Cet environnement technique comprend aussi des dispositifs physiques de dessin ou de construction de maquettes propres au design. C’est le cas du crayon optique et de l’écran du célèbre programme de dessin précurseur Sketchpad. C’est aussi le cas du projet Seek, développé entre 1969 et 1970 au sein de l’Architecture Machine Group du Massachusetts Institute of Technology. Seek est un programme qui a pour objectif d’adapter le plan d’une ville en fonction du comportement de ses usagers, déplaçant les lieux aux endroits les plus pertinents en regard des allées et venues (Brand, 1987). Un prototype du système est construit, où des gerbilles hébergées dans une grande cage en verre font office d’usagers. Celles-ci évoluent au milieu de piles de blocs métalliques légers qui font office d’environnement urbain. En fonction des déplacements qu’elles causent dans les blocs qui forment la « ville » autour d’elles en les cognant lors de leurs mouvements, le système robotique qui les surplombe remet les blocs en place ou les déplace, adaptant le plan aux activités des gerbilles, ce qui manifeste matériellement une cybernétique logicielle.

15 Autre projet mobilisant un système de cubes en guise d’interface physique, mais cette fois-ci pour des utilisatrices humaines : l’Universal Constructor, conçu par John et Julia Frazer avec leurs étudiants de la AA School of Architecture au début des années 1990 (Frazer, 2001). Le projet propose un système de cubes à manipuler à la place des traditionnels claviers et souris. Le motif créé par les cubes est prévu pour être lu comme un motif structurant un système, selon plusieurs possibilités d’interprétation : structure du programme, structure du bâtiment ou encore structure des interactions. Les cubes constituent ainsi une représentation physique des relations logiques entre les éléments, quels que soient les éléments considérés. Là encore, nous observons des manifestations matérielles de l’abstraction logicielle.

1.1.3. Objets textuels

16 Le code constitue lui aussi une matérialisation des algorithmes à part entière. Le code désigne, en informatique, un « ensemble d’instructions en langage machine ou symbolique constituant un programme » ou un « ensemble de règles permettant de représenter des données d’une manière univoque sous une forme discrète, en vue de faciliter leur traitement automatique ou leur transmission » (Abelson et Sussman, 1979, pp. 40-41). En bref, le code, c’est le texte saisi pour transmettre les ensembles d’instructions qui composent un algorithme à la machine qui doit l’exécuter. Les scripts, eux, désignent un morceau de code transmis d’une programmeuse à l’autre ou d’un programme à l’autre. Ce morceau de code n’est pas nécessairement fonctionnel, ne produit pas forcément de résultats s’il est exécuté seul. Mais, comme le code complet, il est constitué d’un morceau de texte qui peut être copié, collé, envoyé, réusiné (Fowler et al., 1999).

17 Lorsque les algorithmes sur mesure s’allongent, le travail de programmation peut être très long. Les bibliothèques permettent de contourner cet écueil et de gagner du temps : il s’agit de collections de blocs de code prédéfinis, développés par des programmeuses comme des raccourcis vers des fonctions déjà écrites. Les bibliothèques sont des répertoires de fonctions auxquelles faire appel depuis l’environnement de programmation dans lequel on code. Elles sont donc associées à des langages — Python, C++, C#, MEL ou Processing — dans lesquels les fonctions sont écrites, puis résumées en un mot qui, lorsqu’écrit dans le code, fait appel à cette fonction directement. En plus de fournir une économie de temps non négligeable lorsqu’il s’agit de coder des algorithmes longs, les bibliothèques constituent donc une extension des possibilités de codes dans un langage donné et un important soutien aux pratiques de programmation. En effet, une programmeuse peut faire appel à des bibliothèques codées par elle-même, mais aussi à celles d’une autre programmeuse. Les bibliothèques de code peuvent être comparées à des bibliothèques physiques : des collections de ressources collectives à utiliser. Il existe des bibliothèques publiques, privées, ou partagées seulement par quelques individus. Néanmoins, une différence significative est le degré d’abstraction que permet une bibliothèque de programmation : par exemple, le travail de décennies de recherches en implémentations mathématiques peut être et résumé, et utilisé par le biais d’un simple mot, tel que numpy, bibliothèque de code qui permet alors à la programmeuse d’utiliser ces opérations mathématiques dans son code.

18 Cette écologie d’objets textuels est complétée par un autre ensemble, plus éloigné de la manipulation directe du code, mais tout aussi crucial dans l’appréhension des pratiques de programmation et de leurs manifestations matérielles. La modification des codes, comme l’apprentissage de la programmation, repose sur de fréquents échanges écrits entre programmeuses. Nombre de ces échanges sont publics puisqu’ils ont lieu sur les forums en ligne qui soutiennent ces pratiques : par exemple, GitHub ou Reddit pour la programmation en général, et les forums de Processing ou de Grasshopper pour les pratiques de programmation plus directement associées au design. Reflets des interactions avec la matière du code, ces échanges en sont une matérialisation à part entière.

1.2.1. Mise en scène

20 Le code devient d’abord, au fil des expositions et des magazines, un élément de mise en scène dans la présentation des projets, un étendard visuel des pratiques de design computationnel. Cela est particulièrement visible dans le domaine très codifié de la représentation architecturale : portes, fenêtres ou mobilier sont rarement présents sur les dessins. Épaississeur des traits, pointillés ou flèches qui permettent usuellement de comprendre l’espace à partir du dessin s’effacent également. Coupes, élévations et plans ne sont plus obligatoires pour présenter un projet. L’enjeu n’est plus tant de parvenir à lire l’espace créé que d’en comprendre la logique de conception. Font donc irruption, dans la présentation des projets, des diagrammes permettant de saisir cette logique. Ces diagrammes cherchent à saisir des ensembles d’opérations mathématiques et à les donner à comprendre au spectateur. En complément, le code s’invite lui aussi dans les catalogues et sur les murs des expositions. Il se dévoile sous forme d’encarts de texte, de lignes de codes superposées à une vue du projet — l’un ou l’autre servant de toile de fond —, opposant ses austères successions de caractères à l’exubérance des formes qu’il produit. Les variations qu’un programme permet d’obtenir, elles-mêmes devenues un élément à part entière de la présentation du projet, s’accompagnent d’une petite légende qui les identifie par un nom et/ou un numéro, mais aussi par les variables qui ont permis leur obtention, minuscule extrait de code suivant chaque forme générée. L’exposition scriptedbypurpose, organisée à la FUEL Gallery de Philadelphie en 2007, en est un exemple emblématique, du fait que son propos même est de donner codes et espaces à voir ensemble. Son manifeste est le suivant :

1. toutes les entrées affichées doivent faire appel à des techniques de code.
2. afin d’éviter que la génération précédente ne soit régie par des exposés génériques sur les « techniques », tous les codes et outils personnalisés doivent être affichés à côté de l’œuvre.(Fornes, 2007).

21 Le titre de l’exposition — scriptedbypurpose [1] — et l’usage du mot « entrée » — qui fait référence à une entrée de code — pour désigner les projets dans le manifeste complètent ici cette esthétique avec un vocabulaire ancré dans la pratique de la programmation. La retranscription partielle du code dans les expositions et les magazines ne permet pourtant pas de comprendre véritablement les algorithmes présentés ou de les reproduire. Sur les panneaux d’exposition s’affichent souvent à peine quelques lignes, ou tout juste la retranscription complète d’une ou de deux des fonctions clés. Mais, ni la relation entre ces fonctions ni les quelques centaines, voire les quelques milliers de lignes du code complet, ne sont montrées. Il s’agit donc bien d’une esthétique, d’un marqueur qui permet aux praticiennes de s’identifier au sein d’un territoire commun.

1.2.2. Archivage et analyse

22 La volatilité des supports met aussi en question les méthodes d’archivage et d’analyse par les conservatrices et les historiennes. Les sources premières offrant des matériaux à consulter pour contribuer à des histoires du logiciel sont assez conventionnelles : archives privées et publiques, en particulier celles des architectes informaticiennes et des éditrices de logiciels de CAO. En observant le travail des historiennes, plusieurs techniques se dévoilent, en association avec de nouvelles traces matérielles du travail algorithmique.

23 Le développement d’espaces de préservation appropriés, qui permet de sauvegarder la matière algorithmique sur le long terme, fait partie des stratégies de travail. Le musée des malware (Hyponen, 2016) ou encore la base de données FID Baudigital, dédiée aux modèles 3D produits par les architectes au cours du travail de conception (Arndt et al., 2022), sont des exemples de ces espaces et des traces qu’ils génèrent à leur tour. Autre approche, l’étude des métadonnées des fichiers pour reconstituer le processus de conception. C’est le cas du travail mené par le Centre Canadien d’Architecture (CCA) sur les modèles de l’Embryological House de Greg Lynn. Les archives numériques données par l’architecte, composées d’une multitude de fichiers natifs pour différents logiciels, n’étaient en grande partie plus lisibles. Pour comprendre l’évolution du processus de modélisation comme de la forme du projet, les équipes du CCA sont parvenues à reconstituer l’histoire numérique de cet objet architectural seulement à partir d’une petite quantité de métadonnées directement accessibles pour chacun de ces fichiers (Bird et LaBelle, 2010). Cette reconstruction interroge néanmoins la nature des sources pour le travail des historiennes : quel est le statut de ces nouveaux objets algorithmiques ?

24 En cas de déliquescence des matériaux initiaux, d’autres peuvent également aider à étudier la structure et les résultats des algorithmes : la documentation de travail telle que les commissions ou les directives, les organigrammes, les notes préparatoires et les diagrammes, ainsi que les publications sur les forums, les tutoriels et les entretiens avec les programmeuses. Extraits de codes, pseudo-codes, environnements de programmation et logiciels utilisés, diagrammes explicatifs, descriptifs textuels et audios, flux de travail permettent de reconstituer les détails du processus de conception des algorithmes. Un document en particulier retient l’attention dans les pratiques de design computationnel, à la frontière entre les deux mondes. De nombreuses praticiennes travaillent avec des esquisses de projet algorithmiques. Mélanges de logigrammes et de croquis éclairant les étapes précédant les sorties que les praticiennes cherchent à obtenir, ces esquisses sont précieuses pour saisir la logique d’aller-retour entre intentions de conception et écriture de l’algorithme. Ensemble, ces usages du code produisent de nouvelles traces matérielles tout en mettant en question l’interaction de professions non formées à la programmation avec les algorithmes-en-tant-qu’objets : designers, architectes, historiennes, sociologues.

25 Il y a donc bien des existences matérielles des algorithmes en tant que médiums du design dont nous pouvons observer les traces. Ces derniers, et les programmes qu’ils composent, se révèlent au travers d’assemblages robotisés qui incarnent physiquement la possibilité de configurer des algorithmes, de représentations privées et textuelles par le biais de bibliothèques de code, ou encore de mises en scène lors d’expositions publiques. À chaque fois, ce sont différents domaines et différentes professions qui l’envisagent selon différentes modalités : l’environnement physique, les lignes de codes ou encore les impressions affichées.

26 Envisager l’algorithme au premier abord en tant qu’interface permettant de désigner des produits dits computationnels fait émerger est un faisceau d’indices pointant vers l’algorithme comme objet du design : conception, modification, présentation d’un résultat plutôt qu’une simple interface qui se limiterait alors à l’invisibilité précédemment évoquée. Il s’agit néanmoins bien de remédiations, de la présentation d’un nouveau médium par le biais de médiums précédents. Si le code est un objet qui n’est ni physique, ni textuel, ni visuel, quel genre de matériau est-il ?

2.2.1. Les relations

35 L’utilisation de techniques de visualisation permet également de faire sens de la structure de l’objet développé (Diehl et Görg, 2006), au-delà des références discursives que nous venons de voir. Une telle visualisation dépend notamment du fait que la structure d’un programme puisse être considérée comme celle d’un graphe (Bernhardt, 2021) et qu’un algorithme puisse se définir sur le plan de la géométrie (Naibo et Seiller, 2022).

36 Le programme-objet peut donc être pensé sous la forme d’un réseau de relations dynamiques, telles que celles de fonctions entre elles (call graph), de classes entre elles (inheritance graph) ou de modules de code entre eux (dependency graph) ; ces relations peuvent être intrinsèques au programme, dans les deux premiers cas, ou extrinsèques, dans le second cas. Cet aspect relationnel est explicité par la notion de milieu associé (Simondon, 2012), qui consiste en l’ensemble des éléments mobilisés par un objet technique et résultant en une individuation de cet objet technique. Cette individuation montre bien que l’objet technique se définit en tant qu’entité distincte, mais se révèle aussi en tant qu’interface pour son milieu associé. Par exemple, un algorithme tel que les T-Splines, qui permet de dessiner des courbes d’une certaine qualité au sein du logiciel de conception industrielle Fusion 360, existe en tant qu’entité individuelle (qui peut d’ailleurs être soumise aux lois du marché, puisqu’elle a été acquise par Autodesk en 2011), mais aussi en tant que mise en relation avec d’autres entités, telles que les entités de surface et les entités solides (Sohi, 2020). L’algorithme en tant qu’objet qu’est le T-Spline peut donc être considéré comme un objet et aussi comme une interface.

2.2.2. La navigation

37 La structure relationnelle d’un programme peut donc être considérée par les programmeuses comme un objet, un artefact concrétisé, mais peut ensuite devenir médium pour les utilisatrices par cette même vertu de mise en relation. Un autre aspect de la matérialité du programme, c’est-à-dire de sa possibilité d’être saisi par l’utilisatrice, est donc celui de la navigation.

38 Par exemple, la conception et l’utilisation du logiciel de conception pour applications multimédia en temps réel TouchDesigner nous montrent la traduction de cette structure en termes visuels. Chaque programme de TouchDesigner est composé de nœuds, lesquels maintiennent des données et effectuent des opérations sur les données procurées par d’autres nœuds. La clarté et la propreté d’un programme TouchDesigner peuvent être visuellement représentées par la minimisation des interconnexions entre nœuds, avec des lignes visibles dans l’interface graphique établissant les relations programmatiques entre chaque composant. La qualité de l’objet peut être également mise en avant par l’utilisation d’une navigation en réseau permettant le déplacement de l’utilisatrice à l’intérieur ou à l’extérieur d’un nœud, lequel va alors être considéré comme objet ou interface, respectivement.

39 Cette navigation fait référence enfin à un autre aspect de l’existence d’un programme : celle des ordres de grandeur. Un programme existe bien à différents niveaux, niveaux d’abstraction qui parcourent un dégradé depuis la concrétisation du hardware jusqu’à l’abstraction de l’objet mental (Détienne, 2002). Suivant que la designer tout comme l’utilisatrice du programme se déplacent le long de ce dégradé, les propriétés d’un programme vont présenter des natures différentes (Hui, 2016).

2.2.3. Le temps

40 Il est également intéressant de noter certaines propriétés temporelles des programmes résultant de cette mise en relation. Par exemple, le terme de software rot [5] fait référence au phénomène de dégradation d’un programme qui, sans se faire de manière purement matérielle (les bits du programme ne se dégradent pas), est tout de même une réalité de l’existence et de l’utilisation d’un programme. Il s’agit de la désynchronisation d’un programme avec l’environnement (le milieu associé) dans lequel il opère. Certains programmes peuvent être plus fragiles et plus sensibles que d’autres au changement de leur environnement : un programme dépendant d’une interface concrète telle qu’une carte graphique sera plus facilement sujet à des évolutions externes qu’un programme opérant sur lui-même, tel un programme de calcul. L’évolution dans le temps est une évolution dans l’écosystème et demande donc aux concepteurs de programmes de repenser l’aspect temporel de l’objet créé.

41 D’autre part, nous pouvons aussi saisir la temporalité des programmes non pas par la manière dont ils changent dans le temps, mais par la manière dont ils conçoivent une certaine approche du temps : Baptiste Mélès (2017) montre que la notion du temps dans les systèmes d’exploitation UNIX est conçue par les créateurs du programme, des temps internes et externes, tandis que Gabriel Alcaras (2022) montre comment le programme Git permet une conception du temps qui se conjugue à l’organisation productive. La conception d’un programme n’est donc pas strictement celle de relations à un temps donné, mais également de relations dans le passé et le futur, relations plus complexes que celles d’une conception classique, mais néanmoins pas limitées à des objets digitaux, comme Lewis Mumford l’a montré dans son analyse de l’horloge comme objet produisant des secondes (Mumford, 1934).

42 En abordant la sensibilité des designers d’objets algorithmiques par une analyse discursive, nous avons abordé ces objets algorithmiques à travers une double perspective spatiotemporelle. La perspective spatiale a révélé les affordances d’échelles et de navigation propres aux objets digitaux, tandis que la contrepartie temporelle a révélé des possibilités parallèles d’historicité, mais aussi de déliquescence de l’abstraction à long terme, dévoilant une nouvelle/ancienne matérialité de l’infrastructure numérique.

43 La notion d’ordre de grandeur, adaptée aux objets digitaux, nous permet donc de voir le rapport objet-médium, tel qu’il existe au sein d’un environnement numérique, de manière plus relative. Après avoir montré que les objets digitaux circulent dans les médiums du design, nous avons vu que ceux-ci sont eux-mêmes le résultat d’un processus de design. C’est vers cette imbrication que nous nous tournons à présent, en considérant les algorithmes comme des objets médiatisants.