[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.

 

Un geek à Hogwarts

 

On peut mesurer sa progression en informatique à la part de xkcd que l'on comprend ou bien, pour les non-scientifiques dans mon cas, à la part de magie qui subsiste dans le fonctionnement de l'ordinateur. Par exemple, le passage d'un langage lisible par l'être humain en bits utilisables par la machine est pour moi de la magie. Je sais que le tour de prestidigitation a pour nom compilation mais je n'en connais pas le truc. Du coup, la création d'un langage me semble un acte démiurgique, qui me rappelle l'abîme de perplexité dans lequel m'avait plongé cet adage de mon ex-beau-père : « Si tu ne trouves le livre que tu cherches, écris-le. » Aujourd'hui, cela me paraît évident mais ma réaction, à douze ans, était de me demander comment diable je pourrais écrire un livre si ce que je ne savais pas était justement dedans. Treize ans plus tard, j'ai de nouveau douze ans en informatique : comment diable peut-on faire reconnaître à la machine un langage qu'elle ne connaît pas si c'est par celui-ci qu'on lui transmet des directives ? On dirait un mauvais remake de Rousseau sur l'origine de la langue. Exeunt la poule et l'œuf, place à la magie.

S'initier à l'informatique, c'est faire refluer la magie. Le cours réseau s'est ainsi chargé de me faire comprendre que les câbles, la fibre et le WiFi ne sont que matériaux, ondes et électricité. Finis les 0 et les 1 vert fluo qui circulent dans les câbles comme dans une guirlande de Noël clignotante : voilà les hertz, ohms, microns et calculs de masques de réseau (ça a l'air un peu chiant comme ça mais je vous rassure : ça l'est). Exit la magie, place à la physique. Sur le coup, on a un peu l'impression de se faire avoir au change mais ce n'est pas toujours le cas : les cours d'algorithmie et de programmation, notamment, m'ont appris ce qui se cachait dans un programme et c'est là que ça devient excitant. Exit la magie, place aux formules magiques. Pour être honnête avec vous, les formules magiques ne sont que logique et linguistique. Cela dit, l'apprentissage du geek ressemble beaucoup à celui de l'apprenti sorcier : très peu d'Hermione et beaucoup de résultats inattendus. Mais avec beaucoup d'entraînement, cela paraîtra vraiment magique aux moldus. Prêts pour une introduction aux sortilèges algorithmiques ? Promis, je serai moins ennuyeuse que professeur Flitwick et vous allez être surpris du peu de notions croisées.

 

Image extraite de Matrix

 

L'algorithmie : une affaire de boîtes à chaussures et d'aiguillages de train

 

Les suppléments sont là pour approfondir mais peuvent être allègrement sautés si vous commencez à en avoir assez.
 

Les boîtes à chaussures

Les boîtes à chaussures vont nous permettre de ranger tout un tas de choses dedans : ce sont des variables, qui permettent de stocker des valeurs. Ces valeurs sont de différents types, selon que les boîtes contiennent des baskets, des escarpins, des mocassins, des tongs... c'est-à-dire, des chiffres, des chaînes de caractères ou des booléens qui, comme les interrupteurs n'ont que deux valeurs : allumé/éteint, vrai/faux, oui/non.

Le supplément André. On ne peut pas mettre n'importe quelle paire de chaussure dans une boîte à chaussure : des chaussures de sports ne peuvent pas aller dans une boîte de chaussures à talons et vice-versa (bah, oui, les chaussures de sports puent). En revanche, des chaussures à talons peuvent aller dans la boîte d'autres chaussures à talons ; il faut juste faire attention à ce que la boîte soit assez grande de manière à ce que les talons ne soient pas ratiboisés. Les chaussures à talons sont des données numériques : on peut faire entrer un chiffre entier (des petits talons) dans une variable qui accepte les chiffres à virgule (des talons aiguilles) mais pas l'inverse, sous peine de faire perdre sa virgule au chiffre (talons ratiboisés).

Le supplément Louboutin. Les chaussures que nous manions sont particulièrement fragiles : toute paire de chaussure posée par terre est désintégrée. Pour échanger les boîtes de deux paires de chaussures, il en faudra donc une troisième, vide.

 

Les armoires

Les armoires vont nous permettre de ranger toutes les boîtes à chaussure que nous avons utilisées : ce sont des tableaux, dans lesquels ranger des variables.

Le supplément Ikéa. Si vous avez des centaines de paires de chaussures, les trier ne sera pas du luxe – par prix, date d'achat, pointure, couleur... en ordre croissant en décroissant. Il existe plusieurs techniques pour cela, dont une qui porte le nom très poétique de « tri à bulles ». Dans tous les cas, il vous faudra un critère de tri et un test en fonction duquel ranger les chaussures. Par exemple, pour un tri selon la saison à laquelle elles se portent : si ce sont des chaussures d'hiver, elles vont en haut de l'armoire, sinon, ce sont des chaussures d'été, elles vont en bas. C'est là que nous allons devoir brutalement changer de métaphore : on ne peut pas faire des kilomètres à pied avec des talons aiguilles ; nous allons donc prendre le train (après tout, les wagons ne sont toujours que de grosses boîtes à chaussures).

 

Les aiguillages

Les aiguillages permettent en un point donné d'orienter les trains selon leur destination prévue : ce sont des tests, où une certaine action est effectuée si la condition est remplie.

Le supplément SNCF. Si un TGV en provenance de Lille arrivant à Paris a pour direction Bordeaux, on l'envoie vers le sud-ouest ; s'il a pour direction Avignon, on l'envoie au sud-est. Plus court : s'il a pour direction Bordeaux, on l'envoie vers le sud-ouest, sinon vers le sud-est. Imaginons que l'on ne sait pas d'où vient le TGV (la SNCF permet un tel débordement d'imagination) ; nous avons alors un embranchement de plus et le test ressemblera à : si le TGV a pour direction Bordeaux, on l'envoie au sud-ouest ; s'il a pour direction Lille, on l'envoie au nord, sinon on l'envoie au sud-ouest. De deux choses l'une : soit le TGV vers Strasbourg est en grève, soit il fonctionne et tous les trains vers Strasbourg vont se retrouver vers Avignon, auquel cas, il faut encore rajouter une condition : si le TGV a pour direction Bordeaux, on l'envoie au sud-ouest ; s'il a pour direction Lille, on l'envoie au nord ; s'il a pour direction Strasbourg, on l'envoie à l'est, sinon on l'envoie au sud-ouest. Vous avez vu les principales formes de test :
– si (condition) alors (conséquence)
– si (condition) alors (conséquence), sinon (autre conséquence)
– si (condition 1) alors (conséquence 1), si (condition 2) alors (conséquence 2), si (condition n) alors (conséquence n)
– si (condition 1) alors (conséquence 1), si (condition 2) alors (conséquence 2), si (condition n) alors (conséquence n), sinon (conséquence par défaut)

Le supplément omnibus. Pour être précis, il faudrait en réalité que les conditions soient multiples. Non pas « si le TGV est à destination de Strasbourg » mais « si le TGV est à destination de Reims ou de Reitz ou de Strasbourg ». Je vous épargne toutes les directions desservies à partir de Lyon.

 

Les boucles d'or

Les boucles d'or, c'est boucle d'or qui revient à chaque fois qu'on lit Boucle d'or et les trois ours. Parce qu'il est dans la nature des contes d'être répétés mais qu'un adulte vire beaucoup plus vite fou que l'enfant à qui il le lit chaque soir, on a imaginé d'enregistrer le conte et de laisser la cassette ou le mp3 à l'enfant pour qu'il se le repasse ad vitam aeternam s'il le veut. Comme la boucle infinie n'est pas très pratique dans la mesure où l'on attend d'autres choses du gamin, genre aller à l'école ou prendre un bain, le parent fixe une limite : tu pourras écouter Boucle d'or et les trois ours trois fois d'affilée maximum ou tu pourras l'écouter jusqu'à ce qu'il soit l'heure du bain. Les boucles d'or sont tout simplement les boucles par lesquelles on automatise le traitement de tâches répétitives, en fixant une condition d'arrêt.

Le supplément fins alternatives. Imaginons maintenant que Boucle d'or et les trois ours soit transformé en livre dont vous êtes le héros (merci de faire comme si vous ne m'aviez jamais vue avec une casquette d'éditrice) : certains choix vous font traverser toute l'histoire quand d'autres vous en éjectent rapidement (l'ours tue boucle d'or d'un revers de pâte, boucle d'or n'a pas sommeil et se contente de manger à tous les râteliers avant de se tirer...). Vous avez une magnifique boucle qui exécute une action (continuer l'histoire) tant que l'on n'a pas rencontré la fin (c'est-à-dire tant que l'on nous donne un numéro de section auquel se rendre). Tant que et jusqu'à : voilà vos deux types de boucles.

Voilà, c'est tout.

Je vous la refais : c'est tout. Genre, c'est fini, vous avez tous les éléments en main. Quand le prof d'algo nous a sorti ça, j'ai cru que ça rentrait dans sa moyenne d'une blague toutes les dix minutes. Sauf que non, on a vraiment tous les éléments en main : boîtes à chaussures, armoires, aiguillages de train et boucles d'or. Le cocktail Molotov qui résulte de la combinaison de tous ces éléments est un programme informatique. Si vous n'arrivez pas à envoyer des armoires de boîte à chaussures à Bordeaux tant qu'il y a un gamin qui écoute boucle d'or dans le train, le cocktail explosera et, lorsque la fumée se dissipera, vous verrez surgir un bug. On n'imagine pas la menace sanitaire que représentent les métaphores mal filées.

 

Sculpture en lego de Nathan Lawaya

 

Notre-Dame de Paris en lego

 

Imaginer coder Twitter, Photoshop ou Candy Crush avec si peu d'outils algorithmiques, c'est un peu comme si on vous demandait de construire la cathédrale Notre-Dame de Paris avec une boîte de lego, quand un pauvre cabanon de jardin vous donne déjà des sueurs froides. Pour vous donner du cœur à l'ouvrage, on vous apprend que, lorsque vous aurez trouvé quelle forme donner à une pierre pour la façade, vous n'aurez pas à recommencer, mais seulement à filer le mode d'emploi au tailleur de pierres, qui vous les fournira au moment d'élever le mur. C'est le principe d'une fonction, un petit bout de code (pas toujours petit, d'ailleurs), qu'on peut réutiliser à volonté. Certaines fonctions sont présentes de base dans le langage (des fonctions mathématiques qu'on trouverait dans une calculatrice, par exemple) et on en crée d'autres selon ses besoins.

Mais les besoins sont immenses pour une cathédrale : l'architecte, qui ne peut pas être à fois vitrier, charpentier, maçon et sculpteur, va donc chercher le savoir-faire là où il se trouve – dans des bibliothèques, qui sont des recueils de fonctions dans lesquels on peut piocher. S'il a beaucoup de chance, l'architecte trouve une bibliothèque-sculpteur qui va lui fournir une fonction-gargouille prête à l'emploi. Mais, la plupart du temps, il ne trouvera qu'un nez de singe et des cornes de bœuf avec lesquels il devra composer lui-même sa gargouille. Rien ne dit que en plus que les cornes seront à la bonne taille, que les pattes seront assez solides pour supporter la tête ou que le nez sera dans la bonne matière : on trouve parfois la bibliothèque dont on rêve... dans un autre langage que celui de notre programme. Si l'on a de la chance dans son malheur, le matériau initial supporte qu'on lui ajoute un revêtement, faisant ainsi dialoguer les deux langages ; sinon... pas de chance. Ces bibliothèque sont un peu comme du prêt-à-porter taille unique : ça peut aller du premier coup mais, dans la plupart du temps, il faudra des retouches, beaucoup de retouches, encore des retouches. Et donc, du temps, beaucoup de temps, encore du temps. Et de même, des développeurs qu'il faudra bien manager, sous peine de s'apercevoir trop tard que le sublime vitrail composé à la perfection est trop grand par rapport à l'espace qu'on lui a réservé dans la façade.

Imaginez un peu l'organisation qu'il faut. Au bout de cinq minutes, tous les plans et modes d'emplois rassemblés auprès des différents corps de métier sont éparpillés, les informations sur la clé de voute perdues sous des dessins de gargouille. Pour éviter ça, on rassemble les modes d'emplois et outils spécifiques à un élément dans un même endroit, une même classe. Avec la classe « pierre de façade », on pourra utiliser autant de pierre qu'on en a besoin (pourvu qu'on n'ait pas oublié de les commander au tailleur de pierre) ; avec la classe « gargouille », on obtiendra autant de bêtes cornues qu'on voudra, même si un sculpteur s'occupe du museau et un autre des pattes. Simple, non ? Sauf que, deux minutes, plus tard, c'est à nouveau le bazar : classe « pierre de façade », classe « gargouille », classe « vitrail rond », classe « vitrail vertical », classe « pierre de colonne », classe « sculpture de saint », classe « pierre de voûte »... On créé donc des classes mères, qui contiennent des classes filles : la classe mère « pierre » chapeautera les classes filles « pierre de façade », « pierre de colonne », « pierre de voûte », tandis que les classes filles « vitrail rond », « vitrail vertical » hériteront de la classe mère « vitrail ». Et vous pouvez jouer longtemps aux poupées russes, comme ça, avec des filles qui deviennent à leur tour mère, sur des générations.

Alors, ça vous botte, les lego ? On peut faire de grandes choses en lego. Ou pousser des hurlements en posant les pieds sur des pièces éparpillées par terre, perdre l'équilibre sous l'effet de la douleur et s'étaler sur la gargouille en construction (vous aurez reconnu les bugs, métamorphosé en pièces de lego). C'est pour ça qu'on commencera par le cabanon de jardin. Ok, c'est moins glamour, mais franchement, a-t-on jamais autant rêvé que dans une cabane dans le jardin de ses grands-parents ? C'est ça, la magie de l'informatique : commencer petit et avancer sur des épaules de géants.