Designer, programmer, développer

Afin de comprendre comment certains programmes numériques peuvent donner lieu à des inventions, il nous apparaît important d’étudier les relations que peuvent entretenir designers et programmeurs. Comment ces deux approches de la technique peuvent-elles dialoguer ? Comment favoriser « l’individuation » et l’invention ? Pour traiter ces questions, nous commencerons par revenir sur le mythe de l’adéquation de l’homme à la technique. Nous verrons ensuite que la distinction entre programmeur et développeur peut soutenir une pratique du projet comme entité toujours développable. Enfin, nous nous demanderons comment le design peut jouer un rôle dans la lecture du « fonctionnement opératoire » des programmes.

Le processus d’intériorisation et d’extériorisation des images que formule Simondon dans sa conception de « l’invention dans les techniques » conteste l’idée d’une période historique dans laquelle l’homme aurait été en parfaite adéquation avec ses objets. Pourtant, l’histoire du design est jalonnée de prises de positions qui semblent lui refuser sa part industrielle. Dans le champ du graphisme, un ouvrage comme La typographie moderne de Robin Kinross nous instruit à propos de résistances à des standardisations provoquées par l’automatisation des tâches. Si de telles craintes peuvent être fondées, l’auteur rappelle qu’il est vain de chercher dans le passé un état de la technique qui aurait été stabilisé. Le supposé déclin de la qualité de la production ne découle pas d’un « développement technique » :

[…] il suffit d’examiner un produit imprimé courant aux premiers temps de l’imprimerie mécanisée pour comprendre que cette idée d’appauvrissement de la qualité est un mythe. [La] répartition du texte entre différents travailleurs était déjà instituée à l’époque de la composition manuelle. [Ce] n’est pas le développement technique en tant que tel qui causa la perte de contrôle sur la réalisation du produit, mais plutôt le fait que les nouvelles machines aient été intégrées dans un processus plus large où la qualité était sacrifiée dans l’optique de conserver, voire d’augmenter les profits […]⁶⁷⁶.

Il est donc impossible de soutenir une façon de faire du design qui chercherait à revenir à une association harmonieuse où la « qualité » était stabilisée. Cet âge d’or n’a jamais existé. Plus encore, il n’est pas souhaitable qu’il existe. Comme nous l’apprend Simondon, l’acte d’individuation n’existe que dans un processus continu de transformation. L’équilibre, la stabilité sont les manifestations d’un système qui ne peut plus rien donner. Un tel équilibre n’est porteur d’aucune force, « il correspond au plus bas niveau d’énergie possible⁶⁷⁷ ».

Dans le champ du graphisme, pour poursuivre notre exemple, et plus précisément en typographie, de nombreux débats opposent les tenants d’une présence manuelle du tracé de la lettre dans les caractères en plomb, puis dans les logiciels de tracé vectoriel comme FontLab⁶⁷⁸ ou Robofont⁶⁷⁹ [ Fig. 233 ]. Fig. 233 Alors que la plume ou le burin gardent trace des outils traditionnels reliés à une matière physique, comment transférer cette culture séculaire dans des logiciels qui abordent la lettre comme une construction à partir de points formant un contour et non une masse ? L’authenticité problématique du plomb puis du numérique nécessite des réflexions sur la « traduction » de formes dans d’autres époques techniques [ Fig. 234 ]. Fig. 234 De même, certains graphistes sont tentés de surjouer l’emploi de formes aléatoires ou accidentées afin d’affirmer une singularité dans leurs pratiques⁶⁸⁰. Comme l’indique à dessein Annick Lantenois, un tel projet rejoue des craintes plus anciennes :

Comme le désir de donner à voir de façon démonstrative, voire spectaculaire, le savoir-faire du designer à un moment où la technologie et, en particulier les médias numériques, déplacent ce savoir-faire vers un savoir-comprendre, un savoir-maîtriser la logique de ces outils et de ces médias, un savoir concevoir selon d’autres paradigmes. Comme la nécessité de renouer avec l’incertitude et l’inachèvement alors que l’intervention des logiciels entre le designer et l’objet à mettre en forme réactualise la crainte de l’uniformisation déjà posée par le système technique industriel au xix^e siècle⁶⁸¹.

Pour Annick Lantenois, cette expression d’une intériorité créatrice par des aléas et coulures court le risque de ne devenir qu’une suite ininterrompue et homogène de « témoignages ». À l’inverse de cette « apparence de bricolage », nous pouvons penser qu’une façon de faire du design au fait de sa dimension mécanique pourrait œuvrer à manifester la présence (voire le fonctionnement) des matrices productives. Pris « entre économie et morale », le type de design que cherche à penser Annick Lantenois affronte le deuil d’une « défonctionnalisation : celle d’un équilibre qui était parvenu à s’instituer entre l’individu et le système technique industriel⁶⁸² ». Il s’agit donc de porter une responsabilité réconciliatrice — tâche peut-être impossible — sans revenir à des situations techniques révolues. Le développement des logiciels reconfigure les places des « utilisateurs ignorants⁶⁸³ » et de ceux qui peuvent accéder au savoir. Comme l’indique Annick Lantenois, chaque seuil de poussée technique entraîne un « élargissement de l’espace de paroles aux non-experts […], alternance [volontaire] qui autorise l’extension des domaines de compétences, des rôles et des responsabilités⁶⁸⁴ ». Reste à savoir comment cette extension des compétences a lieu, et si cet espace de parole ne reste pas pris dans un système de contrôle, de l’ordre du « dispositif ». En prenant parti pour la « numérisation » contre la « dématérialisation », Annick Lantenois éclaire le champ du numérique d’une façon qui n’oppose pas les médias et les époques :

La numérisation généralisée, ce sont des textes de programmation qui conditionnent l’accès à des dispositifs et à leur appropriation. […] Ces textes si peu accessibles, voire invisibles, qu’ils savent se faire oublier ou ignorer dans l’usage, renouent avec le secret dans lequel fut maintenu l’écriture […]. Cette énigme, aujourd’hui, est rejouée par l’écriture et la lecture de ces textes de programmation dont la détention des clefs d’accès – l’apprentissage de leur déchiffrage – constitue de nouveau un enjeu de pouvoir et de domination. Et c’est cet enjeu qui est posé dans le débat opposant les logiciels fermés et les logiciels libres⁶⁸⁵.

On retrouve ici une idée centrale développée par Simondon, celle du développement d’une « culture technique » à même de faire décroître l’ignorance des « utilisateurs ». Les programmes emportent plus que des conditionnements : de la morale et du pouvoir. Donner à comprendre ces « clefs d’accès » est un enjeu que le designer peut travailler. La séparation entre logiciels « ouverts » et logiciels « fermés » (distinction sur laquelle nous reviendrons) serait alors une façon de faire qui donnerait à voir la « zone obscure » (Simondon) des codes sources. Le déchiffrage est littéralement ce qui renverse le chiffre et par là le calcul, où il s’agit, comme le dit Yves Bonnefoy, de « guérir le nombre de sa propre extériorité⁶⁸⁶ ». Comme l’indique à dessein Annick Lantenois, déjouer le pouvoir de la mise au secret du calcul passe par une conception renouvelée de la notion de programmation. Il y a bien plusieurs manières de designer du code. Certaines sont de l’ordre de l’« énigme », d’autres favorisent la compréhension du fonctionnement des programmes. Tenir ces textes particuliers dans l’ignorance, c’est accepter des conditionnements, des dispositifs dont l’appropriation ne sera que plus difficile.

Dans le monde dit professionnel, celui que Annick Lantenois appelle « auteur des programmes » est appelé programmeur ou développeur. Étudier cette distinction nous permettra de dégager différentes façons de faire. À choisir, les « programmeurs » préfèrent se dire « développeurs ». Un développeur réfléchirait, conceptualiserait davantage qu’un programmeur, qui serait voué à la pure exécution d’une demande. On distingue aussi les « programmeurs » du terme encore plus péjoratif, chez les informaticiens, de « codeur ». Ce glissement terminologique semble indiquer une défiance quant aux orientations des programmes, qui conditionneraient le travail même de conception. Que le programme puisse être autre chose qu’une programmatique, cela s’entend peut-être davantage dans le terme de « développeur ». Étymologiquement, développer renvoie à « sortir (quelque chose, quelqu’un) de ce qui l’enveloppe », « parcourir une certaine distance », « faire prendre toute sa croissance à » ou encore « exposer dans le détail⁶⁸⁷ ». Le développeur serait ainsi celui qui serait capable de faire croître quelque chose qui, sans son travail, resterait caché dans son « enveloppe ». Les codes sources pourraient ainsi rester à couvert, ou être développés. En géométrie, on parle de « surface développable » pour désigner ce « qui peut être projeté (sur une surface plane) ». Ainsi, le développeur informatique serait celui qui, sur des écrans, ferait croître ce qui était de l’ordre du secret. Mise à plat, l’énigme des langages formels est susceptible d’être projetée « en dehors », de faire l’objet d’un travail de parution. Dit autrement : la mise à plat des langages formels qu’opère le développeur serait une façon de donner forme à la « zone obscure⁶⁸⁸ » des programmes. Le travail de développement des codes sources consisterait ainsi à les faire paraître d’une façon qui favoriserait leur croissance.

À l’inverse de cette mise au dehors du secret, il est des façons de faire du numérique qui renforcent la tentation de l’énigme. Les programmes « propriétaires » vont bien sûr dans ce sens, en interdisant l’accès à la lecture de leurs codes sources. Il n’est pas possible de comprendre ce qui s’opère derrière les interfaces puisque le code est « compilé », c’est-à-dire écrasé et réduit dans un ou plusieurs fichiers qui ne sont plus « développables » (dépliables). D’autres facteurs de mise à distance sont aussi à considérer. Le logiciel Adobe Photoshop 1.0 (sorti en 1990) comprenait 128 000 lignes de code⁶⁸⁹, là où les versions récentes en ont plusieurs dizaines de millions. Il est ainsi intéressant de lire les observations ayant suivi la mise à disposition du code source de Photoshop 1.0 par Adobe en février 2013 :

En ouvrant les fichiers […], je me pris un peu pour Howard Carter lorsqu’il pénétra pour la première fois dans la tombe de Toutânkhamon. Qu’est-ce qui m’arrêta de si merveilleux ? […] L’architecture du système est très bien structurée. Il y a une nette séparation entre l’interface et les abstractions⁶⁹⁰, et les choix de design effectués pour compartimenter ces abstractions […] sont faciles à suivre. […] Tout est fait pour rendre la texture du système plus simple et compréhensible. Le manque de commentaires n’est pas un problème. […] Il est délicieux de retrouver des vestiges [d’autres codes sources], […] ce qui me rappelle qu’aucun code n’est une île. C’est le type de code que j’aspire à écrire⁶⁹¹.

La lecture du code source de Photoshop se donne à lire comme un récit d’exploration. La pertinence du code est ici évaluée au regard de sa facilité à être compris. En l’occurrence, l’auteur de ce compte rendu fait une nette différence entre la simplicité initiale et les versions récentes de ce même logiciel, dont le code source est encombré de fonctions et de formats de fichiers hétéroclites. De tels programmes peuvent ainsi être considérés comme difficiles à « développer ». Il est très compliqué de leur faire « parcourir une certaine distance ». Leur puissance reste prisonnière d’une trop grande abstraction.

On retrouve alors la distinction opérée par Gilbert Simondon entre le « mode mineur » et le « mode majeur » d’accès aux techniques. Il est possible de penser qu’un programme qui serait allé trop loin (mais jusqu’où fixer la limite ?) dans la complexité et l’encombrement de son architecture interne se situerait du côté d’une fusion avec la technique. Incapable de représenter abstraitement la vue d’ensemble du programme, cette façon de faire « est initiatique et exclusive », pour reprendre les termes de Simondon, car opérant « à l’intérieur d’une communauté déjà tout imprégnée des schèmes d’un travail déterminé⁶⁹² ». Ainsi, le développeur informatique court toujours le risque de passer de l’autre côté du programme, programmant lui-même son travail dans un auto-conditionnement. Un tel design du code détermine alors les usages qui pourront être faits du programme, fermant la voie à des développements imprévus. Le potentiel de croissance de ce type de programme est limité par sa conception tournée vers l’intérieur, elle ne permet pas « la nécessaire projection en dehors et vers l’avant » induite dans la notion de « projet », tel que l’entend Annick Lantenois :

Il ne devrait pas être très difficile de croiser [les compétences du designer graphique] avec celles de l’auteur des programmes. Car si nous nous attachons au terme « programmation », si nous le comprenons comme une pensée des pratiques et de leurs limites, de leurs possibles, comme une conception de leur conditions de mise en acte de ce programme, alors les deux registres de compétences sont plus proches qu’il ne semble. Ils se rejoignent dans la nécessaire projection en dehors et vers l’avant, dans la notion de projet […]⁶⁹³.

Ce qui s’énonce ici, c’est un rapprochement entre le designer (graphique) et « l’auteur des programmes », sur un mode qui ne soit pas immédiatement celui d’une opportunité économique. Leur association peut s’organiser autour de la notion de « programmation ». Le préfixe « pro » désigne ce qui vient avant, avant la lettre, et avant le « jet », c’est-à-dire vers l’avant. Mais ce que cette citation dit aussi, c’est que l’activité de projection, sans laquelle aucun avenir n’est possible, ne doit pas uniquement chercher à anticiper ce qui peut advenir. Rapprocher la projection de la programmation permet de s’interroger sur la « conception [des] conditions de mise en acte [des] programme[s] ». Comme le dit Annick Lantenois, la notion de projet est une projection qui va « en dehors et vers l’avant ». La projection regarde alors aussi vers l’arrière. Que peut faire le designer pour sortir de cet « oubli dans l’usage » ? Annick Lantenois précise les relations du design aux langages industriels :

László Moholy-Nagy […] rappelle que « vers 1920, les nouveaux artistes découvrirent la dimension esthétique inhérente au travail de l’ingénieur⁶⁹⁴ ». Aujourd’hui, les technologies en réseau sont le dispositif matériel permettant la rationalisation de cette coopération. Ce sont des enjeux similaires à ceux que les concepteurs découvrirent au début du xx^e siècle qu’il faut aujourd’hui accepter de redécouvrir. Dans la culture numérique, le travail de l’ingénieur est l’écriture du langage de programmation par lequel nous accédons à cette culture, aux contenus, aux pratiques. Il est un interlocuteur au même niveau que le designer graphique. Les compétences du designer concerneraient alors et notamment, les conditions d’accès, de visibilité et de lisibilité des strates des multiples interventions dans les processus de production des savoirs et des informations, les questions d’indexation, d’organisation des contenus qui sont les garanties de la crédibilité des contenus⁶⁹⁵.

Comme le rappelle en creux Annick Lantenois, le développement des « logiciels libres » est ainsi directement relié à l’apparition d’Internet puis du Web. Les réseaux numériques permettent de coordonner des compétences dispersées. Dans cette mise en relation, « l’ingénieur du code » aurait en charge la qualité de l’écriture des langages formels, dont nous avons vu avec l’exemple de Photoshop 1.0 qu’ils pouvaient être porteurs d’élégance. Le designer, quant à lui, aurait pour tâche de rendre le monde lisible.

Designers et programmeurs-développeurs ont à discuter dans un rapport critique. Cette relation fructueuse est souvent occultée dans la défense de supposées différences disciplinaires. Il en est de même dans certains types processus de design, comme ceux se réclamant du « design thinking », où la réussite d’une collaboration se mesure à l’efficience du temps passé sur un projet. Cette projection-prévision uniquement tournée vers l’avant se rêve comme un flux purgé de toute aspérité. L’idée d’un « développement » des programmes s’oppose directement à celle de l’adéquation d’une réponse à un besoin, qui ne produit que des « utilisateurs ignorants⁶⁹⁶ ». La notion de programme peut interroger le designer sur sa culture du projet, sur l’articulation logique de nouveaux langages, matières informables aux propriétés singulières. Le designer peut réfléchir sur la mise en acte même du programme, sur son effectuation et déroulé. Le design des programmes peut alors se comprendre comme le design des modes d’accès et de circulation des textes des programmes, souvent occultés derrière des interfaces-écran. Ces codes peuvent faire l’objet d’une réflexion sur leurs conditions de visibilité et d’appareillage ; coordonner la façon dont les codes s’exécutent et paraissent à l’écran [ Fig. 236 ], Fig. 236 donner à lire ces circulations, etc. Cette façon de faire du numérique travaille aussi l’envers des programmes, celle qui est habituellement confiée à des spécialistes⁶⁹⁷. La collaboration critique entre designers et développeurs travaille la question de l’expertise et de la démocratisation. Le dialogue n’est jamais un acquis, la constitution d’un espace de jeu est toujours à négocier. La tâche du designer serait alors de trier, d’opérer des sélections parmi ce qu’il serait pertinent ou non de faire croître — tel est le sens étymologique du mot culture.