Grignotages de mimylasouris

[Deuxième partie d'un compte-rendu de lecture sur l'essai Geek Sublime: Writing Fiction, Coding Software, de Vikram Chandra. La première concernait la sociologie du geek. La troisième, à venir, porte sur la critique littéraire indienne avec laquelle l'aspect informatique est mis en regard.]

Geek, man and machine

Le but premier et ultime d'un programme informatique est qu'il fonctionne, c'est-à-dire qu'il compile (pas d'erreur qui empêche de le transformer en langage binaire exécutable par l'ordinateur) ET qu'il fait ce qu'on veut qu'il fasse (un ordinateur est bête : il fait toujours ce qu'on lui dit de faire, pas nécessairement ce qu'on veut qu'il fasse). Pourtant, rappelle Knuth (le dieu que révère Vikram Chandra), programmer, ce n'est pas seulement indiquer à un ordinateur ce que l'on veut qu'il fasse ; c'est aussi expliquer à un être humain ce qu'on vaut que l'ordinateur fasse. Cet être humain peut aussi bien être un collègue que vous-même quelques mois après l'écriture du code ; rien de tel, en effet, que de reprendre un ancien bout de code pour vérifier que je est un autre. Pour que votre moi du futur remercie votre moi du passé, il faut, nous dit Knuth, bien choisir le nom des variables (ok), expliquer ce qu'elles représentent (sous forme de commentaires), et introduire les concepts dans l'ordre qui sied à la compréhension humaine (yolo, Boileau). Comme s'il y avait un mode de compréhension humaine. Chacun a donc son idée sur la question, et ses propres critères pour en juger. On retrouve cependant avec récurrence l'idée qu'un code ne devrait pas se répéter.

D'une manière générale, le geek voit la répétition d'un mauvais œil : c'est le boulot de la machine, pas le sien - « any repetition of effort seemed like an insult. » (p. 15) Le geek pourra donc passer cinq heures à coder l'automatisation d'une tâche qui lui aurait pris 30 minutes – et ce, même s'il est probable voire certain qu'il n'aura pas à la reproduire 9 autres fois. Le geek, comme l'homme dont il hérite, est un animal raisonnable : ce n'est pas parce qu'il peut être raisonné qu'il est d'emblée rationnel.

 

 

 

Le plaisir de coder

Le code peut-il être esthétique ? « The beauty of code » est l'un des leitmotiv de l'essai de Vikram Chandra, et le titre de son chapitre central. Pour autant, vous pouvez ranger Kant, l'émotion esthétique due au vertige des interprétations infinies n'est pas à l'ordre du jour. Vu qu'un programme a pour finalité d'être exécuté par une machine, mieux vaut qu'il n'ait qu'un sens bien défini ; contrairement aux interprétations, les boucles gagnent à ne pas être infinies. Exit la polysémie.

Exit le plaisir esthétique. Bonjour le plaisir sportif. Oui, vous avez bien lu. Pour Yukihiro Matz Matsumoto, le beau code a vocation à rendre le développeur « heureux et productif » (p. 122), et à en croire Vikram Chandra, cela passerait très concrètement par les endorphines : face à problème ardu, « the world fell away, my body vanished, time receded. And three or five hours later, when the pieces of the problem came together just so and clicked into a solution, I surfed a swelling wave of endorphins. » (p. 19) Et si le développeur était accro au code comme d'autres aux sport ?

En 6 ans de Palpatine, je peux vous dire qu'un geek, un vrai geek, ne lâche jamais le morceau. Lorsqu'un problème lui résiste, il y pense tout le temps, fusse en arrière-plan : en marchant (très péripatétique), sous la douche (un grand classique), au concert (la musique aère l'esprit et permet à la pensée de mieux circuler), mais aussi en société, ce qui peut parfois occasionner un freeze en pleine conversation : les pièces click into a solution, réelle ou supposée. (Je le soupçonne de continuer à ruminer au lit, mais il y a des choses que je préfère ne pas savoir avec certitude).

 

 

De quoi la métaphore du code comme art est-elle la revendication ?

Palpatine rappelle régulièrement à qui veut l'entendre qu'en France, le code est régi par le code de la propriété intellectuelle, exactement comme un roman (eh non, un programme ne se brevète pas). La métaphore du code comme art a de quoi surprendre, parce que l'on oublie généralement que l'artiste est d'abord un artisan. Le développeur n'est pas un mécanicien qui sert des boulons binaires, c'est un artisan, qui adapte, polit, peaufine… et revendique donc un savoir-faire. Car non, coder, ce n'est pas (uniquement) appliquer des principes mécaniques qui s'enchaîneraient comme le développement d'une équation ; c'est structurer une réalité foisonnante, la mettre en forme, la concevoir. On ignore généralement que le bon développeur est créatif – on l'imagine rusé, oui, mais pas créatif.

Si les développeurs se comparent à des peintres, des musiciens ou des essayistes, c'est pour faire valoir cet aspect méconnu de leur travail. Et revendiquer le statut qui devrait aller avec. Id est la considération, le salaire et… le sex appeal ? Vikram Chandra cite l'interprétation toute personnelle de Ceglowski sur le recours aux comparaisons artistiques : « Great paintings… get you laid in a way that great computer programs never do […] especially if you have the slighteste hint of being a tortured, brooding soul about you… » (p. 8-9). En bref : le geek ne veut pas être un nerd (le retour en grâce du terme geek, employé à tout va, ne doit pas nous faire oublier qu'à la base, c'est un synonyme de nerd, le mec antisocial un peu zarb avec qui on n'a pas du tout envie de traîner)(Palpatine, en tant que 'vrai geek', s'offusque régulièrement de ce que n'importe quel bidouilleur soit aujourd'hui honoré d'un qualificatif qu'il a eu à souffrir comme insulte avec ses camarades pendant sa jeunesse ; être geek, ça se mérite !).

 

Architecture

L'art est utile comme métaphore pour exprimer les rapports de proportions et d'harmonie. On pourra dire, par exemple, qu'un beau programme est comme une symphonie : chaque morceau en est une phrase musicale, qui peut être jouée seule, mais trouve sa raison d'être au sein de l'oeuvre, nuancée, enrichie par les phrases musicales qui la précèdent, la suivent, et l'entourent de leurs résonances. « Each small part is coherent, singular in its purpose, and although all these small sections fit together like the pieces of a complex mosaic, they come apart easily when one element needs to be changed or replaced. » (p. 123) Cette modularité, je me la représente sous la forme des sas de station spatiale, par lesquelles les astronautes des films passent toujours pour entrer et sortir sans danger. En cas d'urgence (et dans les films comportant des astronomes, il y a toujours une urgence), ces sas permettent de se défaire d'une partie endommagée sans détruire l'ensemble de la station. C'est-à-dire, pour le développeur, de modifier facilement une fonctionnalité pour le client qui a encore changé d'avis et veut son nouveau choix là tout de suite ; mieux vaut, donc, ne pas avoir à aller fouiller dans tous les recoins du programme pour modifier une fonctionnalité réduite.

 

Big Ball of Mud

L'effet boule de neige boue

L'architecte, qui veille au bon agencement de toutes les parties, joue ainsi un rôle primordial. Et ce n'est pas de la tarte : même un projet très simple se révèle toujours plein d'exceptions et de cas spéciaux qu'il faut gérer (si possible, sans faire rejaillir la complexité de ces exceptions sur les manipulations ordinaires). On a vite fait, les deadlines aidant, de se laisser embringuer : « you know that functionality should be somewhere else but you don't have the time to bother, the users ask for a new feature and you patch it in, and of course you mean to come back later and clean everything up, but then, before you know it, you are trapped inside an unwholsome, uncontrollable atrocity, a Big Bull of Mud » (p. 126), « and yes, it is a technical term of art » (p. 127). Devenue incontrôlable, une Big Ball of Mud peut atteindre un nombre de ligne et une complexité tels que le programme échappe purement et simplement à la capacité de conception humaine. Plus personne ne comprend comment il fonctionne de bout en bout. « No temple, no cathedral has ever contained as many moving parts. » (p. 124)

 

 

[Go to indique au programme d'aller à telle ou telle ligne... qui a de fortes chances de bouger lors du développement. C'est le truc crade par excellence, à ne pas faire. Une pratique qui vaut -42, vous dira Plapatine.]

 

Dinosaures sous respiration artificielle

Comment traquer des bugs et ajouter des fonctionnalités à un programme que l'on ne comprend pas, quand la moindre modification effectuée dans un coin peut avoir des répercussions inattendues à l'autre bout du système ? Généralement, nous dit Vikram Chandra, on est pris de l'envie de tout réécrire de manière propre. Sauf qu'on n'en a jamais le temps ni le budget. Alors on rajoute une rustine, un peu de boue à la Big Ball of Mud.

Il existe ainsi des programmes qui tournent depuis des décennies et qui ne peuvent pas être correctement maintenus ni mis à jour parce que plus personne ne comprend comment ils fonctionnent dans leur ensemble. C'est par exemple le cas du logiciel comptable du Pentagone, apparemment célèbre pour ses erreurs dans les fiches de paye des soldats (p. 128)… Le secteur bancaire est également un beau tas de boue : 90 % des transactions financières dans le monde se font via des logiciels en COBOL, « the computing equivalents of Mesopotamian cuneiform dialects ». Hé oui, le site web tout beau tout neuf tout responsive de votre banque cache un système vieilli jusqu'à la moelle (p. 129)…

 

La programmation orientée objet

Au milieu des années 1980, on a imaginé de rassembler à un même endroit du code les différentes types de données et ce qu'on peut faire avec (i.e. les fonctions qui s'y rapportent). En encapsulant ces informations thématiques dans des objets, on espérait en mettre un peu moins partout. Et cela a fonctionné. Un peu. La programmation orientée objet a résolu certains problèmes, parfois même avec une certaine élégance, souligne Vikram Chandra ; elle a permis de mettre de l'ordre dans la « spaghetti code jungle » (la jungle est de Foote et Yoder, dans Big Ball of Mud, mais le « code spaghetti » est aussi un terme technique consacré, désignant les kilomètres de lignes de code enchevêtrées, issus de la programmation procédurale.). Pour autant, la programmation orientée objet n'est pas une solution miracle et les Big Balls of Mud continuent de proliférer (un peu comme le bordel dans mon studio en dépit des placards)…

« If you've ever writen code, the fact that so much software works so much of the time can seem profoundly miraculous. » (p. 124) Le bug est la normalité, pas le fonctionnement. Comme dirait Palpatine, ça « tombe en marche ».

 

Les travaux et les jours

Les bons outils font les bons… jongleurs ?

Un précepte geek enjoint de ne pas réinventer la roue et de se hisser sur les épaules d'un géant, en utilisant ce qui a déjà été fait. Il existe ainsi tout un tas de briques pré-construites qui permettent de réutiliser le travail déjà fait, des librairies dans lesquelles aller piocher un savoir patiemment accumulé ; et tout un tas d'outils pour gérer le code et éviter sa prolifération anarchique. Git, par exemple, permet de gérer le versionnement, pour que plusieurs personnes puissent travailler sur le même programme sans risquer d'effacer le travail des autres, et que l'on puisse à tout instant revenir à une version antérieur. Un outil puissant et précieux, donc, mais complexe à utiliser, qui constitue une compétence en soi (au point de figurer sur les annonces d'emploi au même titre que les langages à maîtriser).

 

Les outils, remarque Vikram Chandra, deviennent un savoir à part entière – problème du moyen qui devient une fin. « Each tool and pre-constructed library solves a problem that you must otherwise solve yourself, but each solution is a separate body of knowledge you must maintain. » (p. 139-140) D'où pour certains développeurs l'impression de ne plus être à l'aise dans quoi que ce soit. L'assurance d'avoir toujours quelque chose de nouveau à apprendre est l'un des attraits du métier, mais cela peut aussi se transformer en course épuisante contre la montre et l'obsolescence. Se former aux nouveaux langages pour les projets de demain tout en bossant à fond sur les projets en cours…

 

Le nouveau langage à la mode

« Our industry [remarks Steve Yegge] is fashion-driven to a degree that would embarrass haute couture designers from New York to Paris… » Aussi surprenant que cela peut paraître de l'extérieur, la mode dicte les langages que les gens étudient à l'école, qu'il utilisent ensuite dans projets professionnels, ceux à propos desquels des bouquins sont publiés, etc. Palpatine pestait récemment contre les choix de langage faits par ses associés : parce qu'un geek, par principe, peste toujours contre les langages qui ne sont pas ses préférés, mais aussi parce que le choix du langage n'en a pas été un. Il n'a pas fait l'objet d'un choix rationnel après mise en balance avec d'autres langages et étude de leurs avantages et inconvénients pour ce projet particulier ; ses associés l'ont choisi parce que c'est ce qui se fait et ce qu'ils savent faire. (Je soupçonne tout de même Palpatine d'un léger snobisme geek, à kiffer des langages paraît-il d'une grande élégance, mais à peu près jamais utilisés dans l'industrie.)(Un mignon snob, évidemment.

 

Et demain ?

À l'heure où l'on taquine l'idée d'enseigner le code à l'école, Vikram Chandra remarque que la promesse de démocratisation du code, déjà ancienne, n'a jamais vraiment été tenue. La forme de programmation la plus courante dans les entreprises, au final, est celle des feuilles Excel. « The biggest problem is that anyone can create Excel spreadsheets – badly. » (Kwak, The Importance of Excel). Même quand on maîtrise Excel, surtout quand on le maîtrise et qu'on y fait des calculs complexes, ce type de programmation peut s'avérer dangereux, car il est très difficile à auditer et débuguer – pas fait pour. J'ai d'autant moins de mal à le coire qu'il y avait un pro des tableaux Excel dans l'équipe où j'étais en apprentissage ; vous n'avez pas idée du nombre d'entrées et de formules qu'il y avait là-dedans, d'une complexité telle que… lui seul pouvait s'y retrouver. Vikram Chandra cite même le cas d'une erreur financière monstrueuse (à plusieurs millions) due à une feuille de calcul où une cellule calculait la somme au lieu de la moyenne… (p. 142)

Ouais, je sais, c'est moyen glamour d'envisager le futur sous la forme d'un tableau Excel. Du coup, Vikram Chandra se lâche pas mal en imaginant tout un tas de trucs, dont une rencontre du troisième type entre programmation informatique et génétique. Si vous voulez lire là-dessus, je vous conseille plutôt l'article d'Eliness où elle explique son métier de bio-informaticienne.

[Ceci est la première partie d'un compte-rendu de lecture (augmenté de digressions et de jeux de mots pourris, évidemment) sur l'essai Geek Sublime: Writing Fiction, Coding Software, de Vikram Chandra. Je me concentre ici sur l'aspect sociologique du geek ; un deuxième volet est prévu sur la notion de beauté/d'élégance dans le code… et son absence ; et sûrement un troisième sur la critique littéraire indienne avec laquelle le tout est croisé.]

 

Il y a geek et geek

C'est quoi, un geek ? Pour mon père, on est geek quand on a un blog, un compte Twitter et qu'on passe plus d'une heure par jour sur son ordinateur – je suis donc une indécrottable geekette à ses yeux. Ce qui n'est rien pour le bidouilleur de code. Lequel, à son tour, sera pris de haut par un architecte (parce que oui, on parle d'architecture pour la structure d'un programme). Vikram Chandra nous propose une petite typologie du geek en trois persona.

Tout d'abord, il y a Mel, qui comprend tellement bien la machine qu'il peut programmer en langage machine. En gros, on peut lui mettre des 0 et des 1 à défiler comme les $ dans les yeux de Picsou. Mel, c'est un vieux de la vieille, une espèce en voie de disparition. Typiquement, mon prof de C à Paris 7 est un Mel ; on a parlé de trucs tellement bas niveau qu'on n'a pas eu le temps d'arriver jusqu'aux pointeurs. *oups*

Après Mel, nous avons Einstein, expert en architecture, à la fois bas et haut niveau : il sait comment fonctionne la machine et en tient compte, voire en tire parti, dans son code, qui sera bien bâti et pourra être facilement maintenu. Einstein, typiquement, c'est Palpatine (ouais, je couche avec une rockstar dans son domaine ; jalousez). Palpatine = new.Einstein() (un homme-objet, hihi)(pardon, je m'égare)

Et puis, à côté de Mel et Einstein, vous avez Mort, qui bricole en chopant des trucs à droite à gauche. Le code de Mort, c'est du patchwork : il peut être fonctionnel, voire vraiment efficace, mais ne sera jamais du sur mesure (clairement, la haute couture est l'affaire d'Einstein). Mon année d'initiation au code ferait de moi une Mort-padawan ; j'en sais juste assez pour savoir que je ne pourrai jamais devenir une Einstein, et j'avoue, du coup, avoir moyennement envie de me casser le cul à devenir une Mort. « The vast majority of programmers in the world today are Morts » nous dit Vikram Chandra, qui s'inclut dedans (p. 49). Les Einsteins méprisent généralement les Morts, mais les sous-estimer serait une erreur, car ils sont légion. L'armée des Morts peut être vue comme une bonne chose, le signe d'une (relative) démocratisation du code, aussi bien que comme une plaie pour l'humanité, car ils produisent du code dégueu, que Palpatine appelle généralement du « code d'Indien » (après avoir vérifié qu'il n'y avait a priori aucun Indien parmi ses pioupious). Vikram Chandra propose en filigrane une explication à cet étonnant relent de racisme chez notre Einstein humaniste…

 

Le geek indien

Vikram Chandra rapporte l'anecdote d'un ami indien travaillant aux États-Unis, à qui l'on reprochait son humilité et à qui l'on conseillait : « walk smart », avec plus d'assurance. Ce reproche d'humilité paraît aberrant à l'auteur, pour qui les étudiants indiens en informatique ont toujours paru insupportablement prétentieux… Incompréhension culturelle : le développeur indien type ne dit jamais non ; cela fait partie d'une culture de face-saving, que ne parviennent pas à saisir les Américains, lesquels, cash, passent en retour facilement pour malpolis. L'endroit de la médaille, c'est que, si on lui reproche de ne pas avoir assez la niaque, on reconnaît au développeur indien une qualité essentielle : la patience. « Indian programmers are also tolerant enough to do the 'shit' work. That is: going through somebody else's code. » (N. Sivakumar, cité p. 86) Le revers, c'est que, dans ces conditions, les programmeurs indiens (tout comme leurs collègues chinois) se retrouvent avec un champ de compétences plus élargi mais plus superficiel, prennent moins d'initiatives et sont moins susceptibles d'innovations que leurs homologues américains, qui ont un champ de compétences plus réduit mais qu'ils maîtrisent à fond. D'où, au final, l'impression d'avoir des spécialistes d'un côté, et une main d’œuvre polyvalente de l'autre – ce qui est malheureusement assez cohérent avec le système éducatif hérité du colonialisme. Les universités technologiques mises en place par le système britannique préparaient en effet à un travail de subalterne. Un étudiant qui voulait étudier les technologies les plus modernes devait partir à l'étranger ; le brain drain vers le MIT était tel que certains professeurs ont fini par refuser de faire des lettres de recommandation… Lors de la décolonisation, des IIT (Indian Institute of Technologies) ont été mis en place mais apparemment, les résultats ne seraient pas encore tout à fait à la hauteur des attentes – pour la masse des programmeurs lambda, rappelle l'auteur. Car des Einsteins, on en trouve peu, mais un peu partout ; l'enjeu, c'est d'avoir des Morts d'un bon niveau. D'ailleurs, quand on vous dit que la France manque de programmeurs, ce n'est qu'à moitié vrai : on manque surtout d'Einsteins, c'est-à-dire d'architectes.

 

Le geek qui ne savait pas comment fonctionnait un ordinateur

Si les Morts ont tendance à produire du code dégueu, it's « because they don't know how the machine really works, and, what's worse, more Morts don't want to know » (p. 50) Comment diable peut-on avoir des informaticiens professionnels qui ne savent pas comment fonctionnent les ordinateurs ? C'est qu'il y a un monde entre le langage binaire et les langages haut niveau dans lesquels on programme, qui possèdent une grammaire et peuvent être lus. Chaque couche est ajoutée pour masquer la complexité de la précédente : le langage binaire (0, 1) est repackagé en langage assembleur (8B, EC, bref, de l'hexadécimal), lequel est repackagé en langage haut niveau (avec non plus des chiffres, mais des mots, truc de ouf). Le passage d'une couche à l'autre est très coûteuse en ressources ; l'unique raison pour laquelle on ne s'en aperçoit pas, c'est que les composants augmentent considérablement en puissance chaque année (dans l'esprit des développeurs pressés, plus de puissance signifie manifestement une obligation moindre d'optimiser le code - d'où que les ordinateurs, toujours plus puissants, finissent toujours par ramer autant).

Avec toutes ces couches, du coup, il est assez facile d'oublier les 0 et les 1, et surtout, surtout, d'ignorer comment les 0 et les 1 peuvent avoir à la fois être matériel et logiciel. Vikram Chandra prend ainsi le temps d'un chapitre pour nous expliquer le passage du hardware au software, via les logical gates, « portes logiques ». Avec des 0 et des 1, on peut faire des trucs aussi délirant que des additions et des soustractions dont les mécanismes, tenez-vous bien, peuvent être reproduits mécaniquement. 0 et 1, c'est false et true, c'est éteint et allumé, c'est off et on, etc. Voilà toute la magie. Car si j'ai appris un truc au contact de Palpatine, c'est qu'il n'y a jamais de magie. À chaque fois que vous êtes tentés de voir de la magie quelque part, remplacez mentalement l'incantation par un travail laborieux ; plus vous l'imaginerez laborieux, plus vous aurez de chances d'être proche de la réalité. (Oui, je sais, heureusement que je ne suis pas RH dans l'IT.)

 

The bug slayer

D'où vient, se demande Vikram Chandra, que le développeur se représente comme un bug slayer alors que, si l'on considère la minutie et la patience déployées, il serait bien davantage un bug sweeper ? On pourrait y voir une sorte de compensation, comme lorsqu'un complexe d'infériorité s'inverse en complexe de supériorité. Mais pourquoi cette revendication prend-t-elle une forme agressive alors qu'elle est parfaitement explicitée, par exemple, comme on l'a vu au début, dans la métaphore du code comme art ? L'hypothèse de Vikram Chandra, étayée de multiples études et citations, est que l'agressivité qui règne dans le monde des développeurs n'est pas une vérité universelle, mais un fait culturel que l'on pourrait rattacher à la mythologie américaine du Far West et du cowboy. Le plus fort, c'est celui qui écrase l'autre ; le meilleur, c'est un killer : un lien s'est insidieusement établi entre testostérone et qualification. Le code est devenu un truc de mec, de vrai, pas de mauviette, et l'agressivité, une manière de gagner le respect de ses paires – fusse contre-productif. Vikram Chandra note ainsi que l'agressivité entre développeurs est particulièrement visible dans le mouvement open-source, pourtant fondé sur les contributions volontaires – tant pis si cela fait fuir des contributeurs potentiels…

//Le côté fun de la chose, quand même, c'est que la virulence générale donne des citations pas piquées des hannetons… //

 

Geek and gender : où sont les geekettes ?

La geekette vintage

Vikram Chandra lie la problématique de la parité à la mythologie guerrière du milieu, et propose là une hypothèse expliquant pourquoi la programmation est devenue un milieu essentiellement masculin. Devenue parce que, oui, il y avait des femmes aux débuts de la programmation, quand programmer était encore un synonyme de câbler (les ordinateurs n'étaient pas encore multi-tâches ; il fallait effectuer des changements physiques pour que la machine réalise des opérations logiques différentes). Les femmes réalisaient alors les schémas pensés… par les hommes. Des secrétaires de la programmation, en quelque sorte. Pas de quoi crier à la parité, donc, même si certaines ne se limitaient pas à leur rôle d'exécutantes : Vikram Chandra rapporte l'histoire de Betty Holberton qui, après avoir insisté sur le caractère humain et donc faillible des branchements opérés, a obtenu que soit implémenté une fonctionnalité d'arrêt dans les programmes (si j'ai tout bien compris ; j'avoue ne pas être très sûre de mon anglais sur ce coup-là).

Lorsque les programmeurs ont commencé à obtenir la reconnaissance de leur travail intellectuel, on s'est dit que le moyen le plus sûr de recruter des développeurs de type Einstein était de les recruter sur leurs compétences mathématiques et logiques. Et, à l'époque, les personnes les plus susceptibles d'avoir reçu une formation académique dans ces domaines sont évidemment des hommes. La standardisation du processus de recrutement et la reconnaissance de la programmation comme métier intellectuel a écarté les femmes à une époque où elles étaient, dans l'ensemble de la société, cantonnées à des rôles subalternes.

En bref, ce n'était pas brillant, mais pas franchement pire que dans d'autres secteurs. Pourquoi, alors, y a-t-il toujours aussi peu de filles dans ce secteurs-là (alors que, par exemple, les amphis de droit sont pleins de futures avocates) ? Les critères de sélection choisis ont abouti au recrutement d'hommes matheux et asociaux, caractéristiques qui ont fini par devenir des prérequis. Inconsciemment, la logique s'est inversée : pour être (bon) développeur, il faut être (un homme) asocial et matheux. Et il n'est pas totalement absurde de supposer que horde masculine a répondu à la stigmatisation dont elle a fait l'objet en en rajoutant dans la testostérone dont on la soupçonnait de manquer (dans les teen movies, le nerd, souvent incarné par un maigrichon ou un bedonnant, et le beau gosse sportif, souvent présenté comme benêt, ne forment à peu près jamais une seule et même personne…). Nous voilà revenus aux bug slayers des temps présents.

 

Culture dominante, culture invisible

« The rudeness of the elite programmers – the explaination goes – is actually the necessarily blunt, no-bullshit-style of problem-soving engineers who value results over feeling » (p. 67). Dans ce système, c'est la valeur du code qui a de l'importance, indépendamment de l'origine nationale ou ethnique du programmeur. La culture ne serait pas pertinente ; elle serait même inexistante : tout serait le résultat d'un processus naturel et, selon cette logique, s'il n'y a pas de femme dans le milieu, c'est qu'elles savent pas ou ne veulent pas coder. Signe d'une culture dominante : elle réussit à devenir invisible ou, du moin, à se présenter comme le résultat d'un processus naturel.

 

WASP n'est pas geekette

Vikram Chandra rapporte un fait curieux pour nous occidentaux : alors que l'Inde n'est pas franchement réputée pour être un modèle en terme de parité, le pourcentage de femmes développeuses y est plus élevé qu'aux États-Unis. Le développeur n'y a pas du tout la même image : loin du stéréotype de geek/hacker, il est vu comme une personne bosseuse, intelligente, méticuleuse, qui aide ceux qui en ont besoin et participe volontiers aux activités sociales, sport compris (p. 81). Du coup, les filles sont plus enclines à envisager ce secteur comme discipline dans lequel faire valoir leurs compétences intellectuelles. Sans compter qu'en Inde, ajoute l'auteur, travailler dans un bureau est vu pour les femmes comme un moyen de se protéger du monde extérieur. Cette corrélation entre image du geek et taux de féminisation serait corroboré par des études menées en Iran, à Hong Kong, à Taïwan… et même, par la négative, aux États-Unis : en effet, les filles d'origine étrangère sont statistiquement plus nombreuses que les filles WASP (enfin « Non-Hispanic white girls »)… Citant Varma, Vikram Chandra avance donc que l'inégalité des sexes dans la programmation aux États-Unis semble être spécifique à ce pays et ne pas être un phénomène universel comme on a coutume de le penser. Vu qu'on a aussi le problème en Europe, il faudrait quand même élargir à l'Occident, mais l'hypothèse comme quoi le faible taux de femmes dans la profession est corrélée à l'image du programmeur viril, agressif, héritée de l'imaginaire américain du Far West, est pour le moins intéressante – surtout, donc, quand on observe que cette vision-là du geek ne s'est pas propagée partout.

 

// Parenthèse franco-française nombriliste

J'ai aperçu sur Twitter quelques louables tentatives pour promouvoir les femmes dans le numérique, mais je reste dubitative sur l'efficacité des chartes graphiques rose pétant… On ne masquera pas l'image négative d'un univers geek quasi-exclusivement masculin avec un coup de peinture, mais plutôt en donnant vie à une nouvelle image globale. Pour changer la composante genrée du cliché du geek comme mec matheux et asocial, il faudrait je crois changer les autres également. Faire connaître la sociabilité et la culture geek dans sa diversité, au-delà des mangas et des jeux vidéos, avec ses films, ses livres (je ne me suis toujours pas remise de la preuve de l'inexistence de Dieu par Dieu lui-même dans The Hitchhiker's Guide to the Galaxy), mais aussi et surtout son histoire et ses modèles féminins. Parce que oui, il y en a ! Et pas des moindres : le premier programme informatique a été écrit par Ada Lovelace. Or, en-dehors des geeks, je ne crois pas que grand monde ait ouïe dire de l'existence de cette pionnière… Ni de Grace Hopper, qui a conçu le premier compilateur (le truc qui transforme un programme écrit avec des mots en chiffres compréhensibles par la machine).

Il pourrait également être utile d'y aller mollo sur la culture de warrior / survivor entretenue et même revendiquée par des écoles comme Épita/Épitech ou 42. Le côté koh-lanta de la piscine m'aurait probablement découragée de faire l'école 42 (même si je comprends son utilisation pour marquer la rupture d'avec un enseignement traditionnel et récupérer les élèves qui ne s'y sentaient pas bien) : les blagues de cul des mecs et le travail à outrance ne me dérangent pas si et seulement si j'ai dormi plus de 7h dans mon lit et pris un petit-déjeuner consistant. On peut être intelligent et motivé mais pas très résistant physiquement. Ou simplement aimer son confort. Alors votre devise officieuse de « Dormir, c'est tricher », vous pouvez vous la mettre où je pense.

Enfin, surtout, surtout, il faudrait dire haut et fort que la programmation (sauf dans certains cas bien précis mais pas majoritaires), ce ne sont pas des maths, mais de la logique. On se fout que vous sachiez résoudre des équations du second degré si vous kiffiez les énigmes du Journal de Mickey. Un langage de programmation, c'est comme son nom l'indique un langage. Captain obvious, je sais. Rappeler que la composante linguistique est essentielle dans la programmation ne serait pourtant pas une mauvaise idée quand on sait que les classes de L sont quasi-exclusivement féminines. Il faut venir chercher les filles là où elles sont ! *Comme par hasard*, on était bien plus proche de la parité dans mon master d'informatique réservé aux étudiants issus des sciences humaines que dans les classes d'ingénieurs issus de S où Palpatine donne cours… Je regrette aujourd'hui de ne pas avoir su plus tôt qu'il y a dans l'apprentissage des langages de programmation un plaisir intellectuel similaire à l'apprentissage des langues étrangères ou au décorticage d'une phrase latine (j'ai d'ailleurs une amie passionnée de lettres classiques qui a assez naturellement bifurqué vers la linguistique informatique). Il me semble retrouver dans l'architecturation du code un plaisir conceptuel et créatif similaire à l'ordonnancement des idées dans une dissertation de philosophie, par exemple… On voit les choses prendre forme. Et bonheur supplémentaire : ça marche ou ça ne marche pas ; on le voit immédiatement.

Alors oui, il y sûrement une question de légitimité (est-ce que je me sens capable de faire ces études ?), mais je crois qu'on néglige pas mal la question de l'appétence (ai-je envie de faire ces études ?), qui me semble bien plus efficace pour parer à la pénurie de femmes dans le numérique. En tant que première de la classe un brin arrogante, je n'aurais pas eu besoin qu'on me donne confiance mais qu'on me donne envie… Je n'ai tout simplement jamais songé à m'orienter vers l'informatique : c'était dans mon esprit un truc de matheux et les mathématiques me donnaient beaucoup moins de plaisir que les lettres ; j'ai préféré aller en L, au grand dam de mon professeur de physique… et de ma prof de français, manifestement plus élitiste encore que littéraire.

 

Peu à peu, je deviens réceptive à la sensibilité japonaise. Déjà, la lenteur a disparu dans un frémissement de l'être. C'est quelque chose que je trouve très beau, cette attention portée à toute chose de manière égale, également délicate : au frémissement des feuilles, des haricots rouges, aussi bien que de l'âme humaine. Ce continuum replace l'homme dans son environnement et ouvre la possibilité d'un rapport apaisé au monde. Il faut simplement prendre le temps, nous dit la vieille dame qui encourage ses haricots rouges sur la longue route qui les attend avant d'être dégustés confis, au cœur d'un dorayaki ; accepter que tout prend du temps, c'est-à-dire que nous sommes mortels et que, peut-être, ce n'est pas si grave : même si nous ne réussissons pas notre vie, nous dit-elle, nous pouvons lui donner un sens, en tant qu'observateurs du monde, qui faisons exister la beauté qui s'y trouve en la contemplant.

Attentifs aux belles choses, nous devenons attentifs aux autres, et c'est une belle relation que celle de cette vieille dame aux mains tordues et du gérant d'une échoppe de dorayakis à qui elle est venue réclamer un job malgré ses 76 ans – elle a toujours rêvé de travailler dans un endroit comme cela, dit-elle, rapportant se délicieuse pâte de haricots confits pour persuader le « patron » de l'embaucher. C'est rare, au cinéma, de voir de belles histoires, intenses, qui ne soient pas des histoires d'amour (ni d'amitié, ni de famille) – entre des personnages de générations différentes, qui plus est. À ces deux générations se joint d'ailleurs une troisième en la personne d'une jeune cliente qui irait bien au lycée, mais dont la mère préfère qu'elle ramène de quoi manger – les dorayakis ratés du patron, en l'occurrence (elle est encore collégienne).

Le passé des personnages, leur futur très incertain, ou trop certain, tout est évoqué par touches, et c'est à peine si l'on quitte l'échoppe de dorayakis, un instant, pour raccompagner chacun chez soi dans la nuit noire, voir la lune, observer le frémissement des feuilles, le soleil qui filtre à travers, et les fleurs des cerisiers qui marquent à elles seules le passage des saisons. C'est très beau sans être jamais esthétisant – et plein d'humour ! Car la vieille dame est un sacré personnage, qui n'hésite pas à houspiller celui qu'elle appelle révérencieusement « patron »… Il faut l'entendre pousser un soupir d'aise à la première bouchée de dorayakis, puis un uuuh d'incrédulité (j'adore cette langue pleine d'onomatopées !) en apprenant que, jusque là, le patron n'avait jamais réussi à en finir un seul : « Malgré vos compliments, vous me décevez. » Les Délices de Tokyo, eux, m'ont enchantée.

 

Forcément, le film ouvre l'appétit : je ne vous raconte pas le bonheur ensuite de croquer dans un tempura crevette chaud et croustillant – avec un bol de soupe, exactement comme dans le film. Même envie pour moi et Paplatine – qui a eu le culot de me tapoter sur la cuisse d'un air entendu lorsque la vieille dame a objecté au patron que cela ne la dérangeait pas, que c'est vivant, les jeunes filles saoulantes. Outrée, j'étais ; je l'ai mimé haut et fort, bouche bée puis de Donald Duck courroucé. Non mais, je t'en foutrais de la jeune fille saoulante… je suis un délice de souris. Au moins.

 

Le sujet de Carol n'est pas Carol mais Therese, Therese Belivet, sorte de Peggy Olsen qui aurait emprunté le minois d'Audrey Hepburn. Le film n'aurait probablement pas la même saveur sans son bonnet mutin et ses grands yeux verts écarquillés… devant Carol, donc, la femme fatale américaine dans toute sa splendeur, riche, blonde, mise en pli impeccable et sourire en coin rouge, rouge, rouge. Carol est l'objet : l'objet du film, l'objet de la fascination de Therese, totalement bewitched – dixit son petit ami Richard qui désespère de jamais la voir devenir sa femme. Therese lui rétorque qu'elle aime les gens avec qui on peut parler librement ; nice, répond Richard, le sourcil levé, reprenant à son compte l'ironie dont est chargée la scène : lorsqu'elle est en présence de Carol, Therese n'a plus rien du moineau volubile qu'elle peut être en présence de ses amis ; c'est à peine si elle peut aligner un mot, muette de désir pour cette femme si autre, qui cultive le mystère malgré elle, comme s'il devait y avoir quelqu'un d'autre retranché derrière son image de femme séduisante, suave, grave, capiteuse¹…

Objet du désir, Carol est pourtant loin d'être passive : c'est elle la femme d'expérience, qui fait des avances à Therese. Elle est jeune, lui rappelle Abby, son ex et amie de toujours² ; sait-elle au moins ce qu'elle fait ? Elle ne l'a jamais su. Comme un primum mobile, Carol attire à elle tous les regards, subjuguant Therese comme elle a autrefois tourné la tête à son mari, et détermine bon gré mal gré la conduite de ceux qui l'entourent… jusqu'à finalement se décider à prendre sa propre vie en main – non sans avoir poussé Therese à faire de même en l'encourageant à montrer ses photos. Ce revirement estampillé c'est-la-vie donne à Carol l'épaisseur qui lui manquait un peu, substituant au vague mystère la nostalgie bien réelle d'un être qui sait ce qu'est de perdre le lien avec les êtres qu'elle chérit. Et là, avec cette épaisseur, voilà enfin quelqu'un que Therese peut étreindre…

Un sourire et de grands yeux, Cate Blanchett et Rooney Mara, la fascination amoureuse à l'état pur.