En 1909, le psychologue allemand Max Wertheimer écrivait:
Je casse un bout de bois en deux. Une approche dira: «À présent, j’en ai ‹deux›.» (Deux quoi? C’est immatériel; à présent, j’ai deux—nouvelles—unités.) L’arithmétique procède par un saut; nous avons d’abord un—un bout de bois—, puis deux […] Entre le premier et le deuxième état de choses, un vide a été ignoré.
Mais appelons un bout de bois un bout de bois. Mieux encore: appelons un bout de bois un bout de bois, puis deux bouts de bois, sans oublier que «un» et «deux» sont des mots et qu’ils ne renvoient donc qu’à des concepts externes. Inutile également de les remplacer par les chiffres «1» et «2»—ce sont aussi des symboles, ils se substituent à quelque chose. Ce quelque chose, c’est le concept de nombre, et sa description la plus simple est celle d’une mesure de quantité. En réalité, ce concept s’avère bien plus étrange. Les glissements sémantiques des mots nous sont familiers; ils sont contextuels, subjectifs, intrinsèquement relatifs et «signifient» en signalant leur proximité ou leur éloignement par rapport à d’autres mots. Les nombres, pour leur part, sont censés être définis, absolus, éternels. On nous répète qu’ils n’ont rien à voir avec les mots. Or Wertheimer savait qu’une telle supposition était fausse; les nombres peuvent eux aussi être relatifs, et l’addition de leurs parties ne produit pas nécessairement une somme entière. Le psychologue était au fait de l’étude mathématico-philosophique sur l’essence des nombres réalisée par le mathématicien allemand Richard Dedekind et publiée en 1893. Ce dernier soutenait que les nombres ne sont pas liés de manière concrète à une grandeur mesurable. Il expose sa thèse dans la préface à l’article «Que sont et à quoi servent les nombres?»:
Les nombres sont de libres créations de l’esprit humain, ils servent de moyen pour saisir plus aisément et plus précisément la *diversité* des choses.
Dedekind poursuit en apparentant les nombres à un produit de «la capacité de l’esprit à relier des choses à des choses». Son argument reposait sur la théorie naïve des ensembles élaborée à la même époque par son ami et collègue Georg Cantor. La théorie des ensembles constitue la logique de base des mathématiques; elle précède l’arithmétique basique, les nombres et même le calcul. Cette théorie renvoie principalement à l’étude de groupes d’objets ou d’ensembles et de leurs éléments. On peut par exemple décrire un ensemble de fruits à travers ses éléments {pomme, orange, banane, mangue}, tandis que les éléments {voiture, camion, vélo, cheval} constituent un ensemble de véhicules. Pour formuler une définition des nombres cohérente, Dedekind recherchait à dégager une propriété commune aux deux ensembles. Si l’on établit une relation particulière entre un fruit et un véhicule spécifique et que ce groupement par paires utilise les deux ensembles de sorte que chaque élément du premier ensemble est associé avec un élément du second, leur propriété commune est leur «nombre». Dans cet exemple, ce nombre est 4.
Cette approche du nombre semble procéder dans le mauvais sens. Dedekind suggère (enfin, il prouve) que le calcul n’est pas un réflexe inné, et que les nombres ne renvoient pas à des propriétés immuables. Ces derniers ne nous sont pas transmis par le plan astral mais sont *produits* par les similarités et les différences qui distinguent les ensembles. On peut donc, en résumé, dire des nombres qu’ils sont la marque d’une *relation* entre deux choses ou deux ensembles de choses.
La théorie des ensembles porte ces relations sur un plan encore plus abstrait. C’est une lasagne logique dans laquelle les ensembles incluent d’autres ensembles voire s’incluent eux-mêmes. On considère que deux ensembles sont égaux lorsqu’ils possèdent les mêmes éléments. Bien que les nombres proviennent des correspondances entre les ensembles, il est tout autant possible et utile de concevoir des ensembles de nombres. Tel que l’ensemble infini des nombres entiers positifs (qu’on appelle nombres naturels). On énumère ses éléments selon le modèle {1, 2, 3… ∞}. Mentionnons également l’ensemble des nombres irrationnels—c’est-à-dire les nombres qu’on ne peut pas écrire sous la forme d’une fraction de deux nombres entiers. Ces deux ensembles, les naturels et les irrationnels, laissent entrevoir à quel point le nombre est un concept étrange et malléable. Par exemple, le «nombre» d’éléments au sein de l’ensemble des naturels est ∞. Si l’on retire un élément de cet ensemble, mettons l’élément «1», le nombre d’éléments demeure ∞. Par ailleurs, aucun élément de l’ensemble des irrationnels ne peut être décrit précisément à l’aide des chiffres existants. On ne peut que proposer une approximation de leur valeur au moyen d’une série de décimaux infinie ou leur attribuer un symbole représentant ce «nombre». π en est un excellent exemple. Certains irrationnels existent dans l’anonymat, dépourvus de nom propre.
On dit de deux ensembles qu’ils sont «similaires» si on peut les intervertir continuellement au moyen de la même fonction. Les ensembles de nombres entiers en fournissent l’explication la plus claire. Ainsi, les ensembles {1, 2, 3, 4} et {1, 4, 9, 16} sont dit similaires car on peut transformer chaque élément du premier en n’importe quel élément du second ensemble en le multipliant par lui-même. 1×1=1, 2×2=4 et ainsi de suite.
Revenons à notre bout de bois, qui nous permettra de nous extirper de ce dédale arithmétique. Au lieu de nous évertuer à compter les objets discrets, nous pouvons à la place penser en termes de *transformations*. Au bout de bois suivi d’un vide puis de deux bout de bois, substituons un matériau—soit un bout de bois—transformé en deux configurations différentes. Au lieu d’objets, nous pouvons penser en termes de moments ou d’états.
Songez à la fonction «suivi des modifications» de Microsoft Word. Elle permet d’identifier immédiatement où, comment et quand un texte a été modifié, et tente de rendre visible dans sa totalité l’évolution d’un fichier. Et que dire de Time Machine d’Apple? Cette fonction de niveau système effectue à intervalles réguliers un backup conséquent des fichiers de votre ordinateur. L’interface de Time Machine vous permet de remonter le temps comme par magie pour rouvrir un fichier dans une version sauvegardée antérieurement tandis que le reste de votre ordinateur conserve ses paramètres actuels. Grâce à la barre latérale de Wikipédia, on peut aisément comparer les changements récents effectués sur une page et la version de celle-ci. Pour les logiciels, l’outil «diff», qui compare plusieurs versions en mettant leurs différences en évidence, permet d’identifier efficacement ce qui a changé ou non. Les navigateurs web conservent l’historique des différents sites que vous avez récemment visités, et une page que vous consultez aujourd’hui est susceptible de changer le lendemain. Il existe même un méta-«suivi des modifications» de l’Internet tout entier appelé Wayback Machine. Tapez l’adresse d’un site dans la barre de recherche du site web.archive.org, et la Wayback Machine vous fournira des instantanés de ce site à intervalles réguliers aussi loin que 1996. Cliquez sur une date spécifique, et vous serez transporté sur cette page. Les liens hypertexte fonctionnent aussi bien au sein du site qu’en dehors, et vous permettent de surfer sur le Web de 1996 en 2013, sur un MacBook Air de 2012 équipé de Safari v. 6.0.3.
Le versionnage se complexifie terriblement lorsqu’il s’agit de créer un logiciel au lieu de l’utiliser. Les logiciels actifs sont des travaux en cours, sujets à des révisions constantes. Chaque fois qu’un produit est mis sur le marché, celui-ci contient des fonctionnalités supplémentaires et de nouveaux bugs. Lorsque ces derniers sont corrigés, une nouvelle version est mise en circulation, et le processus suit son cours. La plupart des logiciels suivent un schéma de versionnage basé sur trois nombres séparés par des points, à l’instar d’OS X 10.8.3. Le premier nombre permet d’identifier un changement majeur, le deuxième une amélioration de second plan, et le troisième une légère révision. D’autres modèles vont et viennent, comme l’ajout de l’année la suite du nom du produit, à la manière d’Adobe Illustrator 88 ou de Microsoft Windows 95. Les versions de TeX de Donald Knuth se distinguent par l’ajout d’un chiffre tiré d’une séquence infinie de l’approximation décimale de π. Knuth affirme que son logiciel, actuellement dans sa version 3,1415926, s’éteindra avec lui. Le projet sera gelé, et la série de chiffres approximatifs actuelle sera remplacée par son symbole purement irrationnel.
Pour les développeurs, le versionnage devient une affaire périlleuse. Le développement d’un logiciel commercial mobilise une équipe potentiellement vaste dont les membres ne travaillent pas nécessairement dans la même pièce voire au même moment. Ce processus de développement relève d’une logistique absolument baroque et suit un schéma modulaire. Les langages de programmation modernes sont conçus selon un modèle orienté objet dans lequel des sections de code sont traitées comme des boîtes noires pouvant être développées individuellement, connectées à une structure plus vaste, révisées séparément puis redéfinies. Le génie logiciel est dépourvu de la clarté linéaire propre aux chaînes de montage—les processus de travail sont enchevêtrés et cryptiques. De légers changements opérés dans une partie du code peuvent avoir des conséquences notables dans une étape ultérieure du projet; il est donc essentiel de surveiller le travail de tous les développeurs. Les programmes de gestion de versions (VCS—Version Control Systems) répondent à cette exigence, et permettent à une équipe importante de travailler simultanément sur des fichiers partagés sans se marcher sur les pieds ou réécrire les fonctions de leurs collègues. L’un des plus anciens de ces programmes, le Source Code Control System (SCCS), a vu le jour en 1972 dans les laboratoires Bell Labs. Il fut ensuite actualisé et remplacé par un salmigondis de protocoles alphabétiques, parmi lesquels RCS (1982), CVS (1986), CVSNT (1998) et SVN (2000). L’obsolescence rapide de ces sigles souligne la complexité du problème face à la multiplication des programmes et à leur circulation toujours plus vaste. En 1991, le programmeur finnois Linus Torvalds diffusa une invitation déguisée:
Je travaille actuellement sur un système d’exploitation (libre et gratuit) (c’est juste un hobby, ce ne sera pas grand et professionnel comme GNU)…
Cette annonce signa l’acte de naissance de Linux, à une époque où les projets prenaient une telle envergure qu’il devenait impossible de saisir toute la complexité de leur processus de développement. Linux est un projet de logiciel libre bâti à partir des contributions bénévoles de centaines de milliers de programmeurs, coordonné à travers une base de codes en ligne. La version actuelle est la v. 3.8.8. Elle contient plus de 12 millions de lignes de code réparties dans 36000 fichiers individuels. À mesure que le projet prit de l’ampleur, Torvalds, de plus en plus insatisfait des gestionnaires de version existants, élabora son propre logiciel: Git.
Git a été rapidement et massivement adopté, en partie parce qu’il s’agit d’un gestionnaire de version explicitement *distribué*. Plutôt qu’un dépôt centralisé de données unique (généralement stocké sur un serveur) abritant les fichiers maîtres du projet, Git peut fonctionner avec un nombre variable de dépôts mis en lien. Chaque instance du code et chaque dépôt sont équivalents, sans qu’il y ait besoin de «document maître». À la place, Git identifie le document maître comme un ensemble complexe de relations versionnées entre des copies individuelles. Le logiciel négocie les transactions nécessaires pour garder chaque copie à jour au moyens de commandes telles que push (envoyer), pull (recevoir), clone (cloner), branch (branche), merge (fusionner) et commit (commettre). On peut également stocker un dépôt en ligne sur certains sites, à l’instar de Github.com, «dépôt de dépôts» comparable à un vaste entrepôt abritant des codes partagés publiquement. À la différence des systèmes de gestion de version antérieurs, Git ne suit pas l’historique de tel ou tel fichier, mais surveille à la place toutes les données brutes du projet (quel que soit le fichier qui les abrite), créant en permanence des instantanés de l’ensemble. Voilà peut-être l’aspect le plus radical et puissant du modèle Git, dans la mesure où il n’assure pas le suivi des modifications mais surveille les transformations. Revenir à une version antérieure est un jeu d’enfant—on compare les clichés via la commande diff, tandis qu’un graphique en arborescence montrant les branches, les commits et les fusions permet de suivre l’évolution du projet.
Cinquante ans plus tôt, le designer industriel suisse Max Bill évoquait le versionnage dans l’essai «Konstanz und Veränderung» [«Continuité et changement»]. S’il écrivait sur le matériel et non sur le software, les termes qu’il employait n’en demeurent pas moins familiers. Il distingue la continuité comme ce qui persiste et le changement comme ce qui se transforme. Il limite l’emploi de ces termes à une catégorie de produits bien spécifique:
Nous jugeons une chaise, par exemple, non seulement vis-à-vis de ses qualités individuelles, mais aussi en tant qu’objet représentatif de son type—les chaises dans leur ensemble, à l’aune d’une temporalité plus longue.
Pour Bill, la forme figurait l’agencement harmonieux et stable des relations d’un produit. Celles-ci incluaient non seulement les choix de forme spécifiques arrêtés pour le design d’une montre, par exemple, mais aussi la relation entre une montre spécifique et la catégorie tout entière des «montres». Le bon design produit la forme la plus «typique» et valide, en accord total avec son type. Bill concédait cependant la difficulté de cet idéal, et se référait à l’évocation des chapeaux haut de forme par l’architecte viennois Adolf Loos dans «Von der Sparsamkeit» [«De la parcimonie»], article paru en 1924:
Il existe une grande variété de chapeaux haut de forme. Imaginez une centaine de ces couvre-chefs placés côte à côte. Lorsque j’essaie différents modèles, je me rends compte que la plupart sont impossibles à porter, ridicules, et qu’il n’y a qu’un seul chapeau qui me convienne. Mettons qu’il s’agit du modèle de 1924. Ce haut-de-forme est le seul qui m’aille et qui convienne au style de mon temps.
Loos poursuit sa supplication en disqualifiant ce contre-exemple qu’il met sur le compte des effets de mode: «Je rejette la folie de l’innovation sous toutes ses formes.» «Nous devrions évaluer la beauté à l’aune de critères temporels», affirme-t-il dans le paragraphe suivant. Loos défendait une approche différentielle et éternelle du design tout en admettant que la pertinence d’une forme, comme celle du chapeau haut de forme de 1924, ne se démontrait qu’à un moment spécifique. Il ne tolérait pour autant une justification moins linéaire. Le temps ne se représente pas sous la forme d’une ligne droite. (Il suffit de jeter un œil sur les versions enchevêtrées et les arborescences complexes d’un projet développé sur Git.) Toute forme, ainsi que le jugement que l’on porte sur elle à un moment spécifique, n’est pertinente que vis-à-vis de ce dernier, et son statut pourra se transformer ultérieurement, de manière rétroactive: une nouvelle forme apparaît, qui affecte la classe toute entière et le statut de chaque élément qu’elle contient, avec pour effet de recentrer la catégorie. Bill suggérait que la morphologie—l’étude de la forme dans le temps—formait peut-être le meilleur outil pour comprendre ce processus de versionnage.
Les études morphologiques peuvent se mener de manière empirique et visuelle, mais il existe une variété encore plus précise: la morphologie mathématique est un langage formalisé voué à identifier des transformations dans le temps. Sa langue natale est la théorie des ensembles. La morphologie mathématique analyse des groupes entiers et l’évolution de leurs relations afin d’établir le nombre de transformations qu’une forme subit dans le temps. On trouve une application typique de cette méthode dans le traitement d’images numériques au moyen d’un procédé qu’on nomme «Top Hat Transform» («transformation chapeau haut de forme»). La forme de cette fonction évoque celle du couvre-chef qui lui prête son nom.
Appliquée à la grille en deux dimensions d’une image en niveaux de gris, la fonction compare ses valeurs de pixels à une structure de limitation, une sorte de «document maître». Le «Top Hat Transform» dessine des zones de similarité et de différence pour produire une image composite qui met les transformations ou leur absence en évidence. On peut l’appliquer d’un seul tenant, le long d’un ensemble infini d’images, afin de révéler les rapports formels qu’elles entretiennent. Elle est comparable en ce sens à une commande diff appliquée à des images.
La gestion de version est utile pour le hardware (les produits) et essentielle pour les softwares. Mais qu’en est-il lorsque la chose qui change n’est ni un produit, ni un logiciel? Avec le récent avènement de l’impression 3D, il est désormais possible de fabriquer de «vrais» objets directement à partir de données numériques. La technologie devient toujours plus abordable et répandue, donnant lieu à une communauté de choses en expansion qui ne sont ni exactement hard, ni exactement soft. Ce sont des hybrides dont les formes sont constituées de relations liant les données qui les définissent et le moment et le lieu de leur production. Il suffit d’effectuer un léger ajustement sur le modèle informatique et d’appuyer sur la commande «imprimer» pour obtenir une nouvelle forme. Le matériau source étant numérique, toute transformation opérée entre ces deux instances spécifiques devient une manipulation informatique directe et continue.
Ce n’est nullement un pas de géant que d’imaginer étendre le «Top Hat Transform» bidimensionnel à l’évolution morphologique et chronologique d’un objet imprimé en 3D. Nous pourrions visualiser instantanément l’historique géométrique d’une forme donnée dans sa totalité, recueillir de manière programmatique un passage donné à travers le temps, l’assembler comme un modèle, et l’imprimer pour produire, par exemple, une tasse en quatre dimensions incorporant toutes ses formes et ses temporalités. D’une autre manière, nous pourrions imaginer un modèle retraçant «en accéléré» l’évolution de la tasse.
Or, le texte que vous êtes en train de lire formait initialement la troisième section d’un essai plus long intitulé «G-E-S-T-A-L-T»1, publié en ligne sous forme de PDF par The Serving Library, et figurant dans le cinquième numéro des Bulletins of the Serving Library. Deux tirages séparés des Bulletins ont été produits et distribués par The Sheridan Group aux États-Unis et par Sternberg Press en Europe. Entre-temps, «Le versionnage infini» a été adapté sous la forme d’un récit pour une séance de diapositives commentée et éponyme le 30 mai 2013 à Venise, en Italie. La conférence a eu lieu avant la publication du texte en ligne, bien qu’il était déjà achevé à ce moment-là. Après de légers ajustements, ce récit a ensuite été présenté le 23 juillet 2013 au Banff Centre à Alberta, au Canada. Environ un mois plus tard, «Le versionnage infini» a été retravaillé pour accompagner un ensemble de photographies réalisées par Jason Fulford pour un livre à paraître chez Blind Spot (New York) début 2014 et intitulé Gestalt, or the Whole Enchilada. Au milieu de tout cela, un certain nombre de choses ont changé dans cette version, y compris sa conclusion.
Il se trouve que Git (ou plutôt sa communauté en ligne hébergée sur www.github.com) a développé un logiciel très proche de ce que j’ai décrit deux paragraphes plus tôt. Appelé «3D File Diffs»2, il permet aux utilisateurs collaborant sur le design du même produit de recenser les transformations physiques survenues *dans le temps*. Le visualiseur compare les transformations opérées dans un ensemble de données tridimensionnelles et restitue les informations à l’écran à travers une interface interactive. Le Diff Viewer permet aux utilisateurs de manipuler les objets dans un environnement en 3D et de signaler les modifications effectuées dans les versions postérieures avec un code couleur. Il est même possible de naviguer à travers les différentes étapes du design grâce au bien nommé «Revision Slider» («curseur de révision»).
Il est cependant peu probable que ces extravagances technologiques répondent à un réel besoin. Peut-être nous faut-il simplement développer un regard plus lent—une nouvelle manière de voir qui nous permettrait d’observer des formes entières à l’aune de temporalités plus longues assemblées dans le temps. Cette sensation de mouvement pur, sans objet—une transformation en soi—, signale la zone démilitarisée sise à la frontière des choses et des processus. Ici, les objets sont avantageusement suspendus dans le temps et apparaissent sous la forme d’ensembles de transformations reliés dans leur intégralité, et non pas d’une composition unique et résolue. La tâche est moins difficile qu’il n’y paraît. Nous sommes déjà entrainés à nous représenter la multitude de versions discrètes décomposant le mouvement d’une porte battante, la trajectoire d’un boomerang, le vol d’un avion, ou le cheminement d’une pensée.
-
«G-E-S-T-A-L-T» est publié à l’adresse http://www.servinglibrary.org/read.html?id=77066. ↩
-
On trouve une description et une démonstration du 3D File Diffs et du visualiseur sur le blog de GitHub à l’adresse https://github.com/blog/1633-3d-file-diffs. ↩
Published on <o> future <o>, June 9, 2014.
- Translation
- Jean-François Caro
- License
- CC BY-ND 3.0 France