1Comment se créent les logiciels que nous utilisons chaque jour ? Qui construit les infrastructures informatiques de nos sociétés contemporaines ? De quoi le numérique est-il fait ? Ces questions appellent quotidiennement des réponses tantôt idéalisantes, tantôt désenchantées. Quel que soit le ton du discours, une seule chose semble sûre : l’informatique est une machinerie efficace, qui produit des effets sur le monde social. Les débats croissants sur les algorithmes, notamment concernant leur pouvoir et leur opacité, illustrent parfaitement cette logique particulière d’interprétation du monde informatique. Même si les études consacrées à l’appropriation des techniques mettent en garde contre une vision déterministe des technologies et documentent « les possibilités d’autonomie et d’émancipation pour les individus et les groupes » (Proulx, 2015), les infrastructures numériques conservent leur aura de dispositifs fascinants, à la fois incroyablement complexes et parfaitement ordonnés.

2Pour interroger cette illusion d’ordre et d’efficacité, une stratégie possible est d’entrer au cœur du dispositif : « de l’extérieur, on est frappé par l’agencement merveilleux des éléments, bien alignés les uns par rapport aux autres, harmonieusement solidaires ; de l’intérieur on découvre les éléments retors, les froissements, les blocages, les aspérités » (Dodier, 1995, p. 5). Mais quel « intérieur » explorer quand les infrastructures sont si vastes, si diverses ? Doit-on s’occuper des bâtiments, des circuits imprimés, des serveurs, des câbles du réseau, des bases de données, des logiciels, des plateformes ou de quantité d’autres objets − sans parler des personnes qui les créent, les maintiennent et les utilisent ? Faire un choix n’est pas évident, surtout face à la polysémie du terme numérique, dont les usages et les définitions varient grandement selon les contextes (Moatti, 2012 ; Drot-Delange et Bruillard, 2012 ; Baron, 2018).

1. Programmer ou coder ?

1.1. Hacker, geek, entrepreneur : au-delà des figures mythiques

6Rendre compte de ces représentations constitue incontestablement une force pour la recherche sociologique et anthropologique. Grâce à ces travaux, nous avons gagné une compréhension beaucoup plus fine d’éléments essentiels de la culture technique (Coleman, 2010), politique (Coleman, 2013 ; Auray, 2007 ; Broca, 2013) et économique (Rosental, 2017 ; Vincente 2017) des milieux informatiques. Ces discours nous aident à comprendre l’intérêt pour le code, les rapports qu’entretiennent les individus avec leur activité ou encore les stratégies de distinction et de légitimation déployées par certains groupes sociaux. Mais les discours, si opérants soient-ils, ne sont pas les pratiques. Si les premiers ont été remarquablement investis par la recherche, nous ne pouvons pas en dire autant des secondes. Lorsque des enquêtes sont menées sur l’activité informatique, elles l’abordent souvent par le prisme de ces discours, que ce soit pour les vérifier ou pour les infirmer. En dépit des réponses qu’apportent ces travaux, les questions restent, dans l’ensemble, inchangées − et ce sont ces questions qu’il s’agit aujourd’hui de renouveler.

1.2. Sortir de la réduction algorithmique

7Quand elle ne s’efface pas derrière ces figures mythiques, l’informatique se trouve régulièrement réduite au problème des algorithmes. La centralité croissante du concept d’algorithme se comprend d’ailleurs aisément. D’une part, les algorithmes paraissent trouver toujours plus d’applications concrètes et plus de données à traiter, depuis la recommandation de biens culturels, comme la musique (Beuscart et al 2019), jusqu’à la diffusion d’informations (Benkler, 2018) en passant par la justice (Christin, 2017), la police prédictive (Benbouzid, 2017) et tant d’autres, sans oublier les sciences sociales elles-mêmes (Edelman et al. 2020). D’autre part, les algorithmes ne cessent, semble-t-il, de gagner en autonomie grâce à des systèmes tels que les réseaux de neurones (Cardon et al. 2018). La crainte est que ces technologies, présentées comme capables d’apprendre, absorbent les inégalités inhérentes aux données et reproduisent des dispositifs d’oppression (Noble, 2018). Les algorithmes s’inscrivent désormais dans une double mise en scène, qui les présente à la fois dans leur manque de transparence et dans leur toute-puissance. La force du « drame algorithmique » (Ziewitz, 2017) tient à ce jeu entre opacité et pouvoir qui se renforcent mutuellement. Même en partant du principe que les algorithmes ont du pouvoir, il n’est pas aisé de comprendre comment ils l’exercent, ce qui les rend d’autant plus mystérieux. Inversement, leur opacité peut être interprétée comme un signe supplémentaire de leur puissance. Bref, à défaut de savoir ce que sont et ce que font les algorithmes, tout le monde s’accorde sur leur statut d’objets de pouvoir.

9L’algorithme n’est donc pas toujours la bonne porte d’entrée pour comprendre l’activité informatique ; une concentration excessive sur les algorithmes peut même finir par occulter une grande partie des pratiques, des savoirs et surtout du sens de l’activité informatique. Notre propos n’est pas de contester l’algorithme en tant qu’objet sociologique − plusieurs articles de ce numéro traitent d’ailleurs de cette question en l’abordant sous un angle différent − mais plutôt de le remettre à sa place parmi les nombreux autres objets de l’activité informatique.

1.3. S’emparer de l’écriture des codes

11S’intéresser à l’écriture des codes signifie tout d’abord faire passer l’activité au premier plan. Le but est de se détacher, ne serait-ce qu’un instant, des figures mythiques et des discours qui l’entourent afin de penser cet objet dans ses aspects ordinaires, routiniers, vulnérables. Écrire un logiciel ne se résume pas à produire du nouveau code. Bon nombre d’opérations relèvent par exemple d’un « care des choses » à l’égard d’infrastructures scripturales qu’il faut maintenir (Denis & Pontille, 2012 ; Denis & Pontille, 2020). D’autres consistent simplement à comprendre et à gérer le code existant (Couture, 2012). Comme dans toute étude anthropologique des infrastructures, l’enquête fait la lumière sur ces actions laborieuses, ennuyeuses ou invisibles pour mieux explorer ce jeu entre le transparent et l’opaque (Star, 1999). Comprendre l’écriture du code dans toutes ses nuances révèle comment ces différences servent de support à des distinctions, à des stratégies de légitimation, par exemple lorsqu’un ingénieur automatise ce qu’il considère comme du travail « manuel » ingrat (Alcaras, 2020), et plus largement à la construction d’un ethos professionnel (Zarca, 2009).

12Étudier l’informatique comme elle s’écrit implique aussi de prendre en compte le rapport que les codeur·euses entretiennent avec cette activité. Ce parti pris s’inscrit résolument dans une démarche sociologique qui a le souci de la technique (Desrosières, 2013 ; Dagiral et Martin, 2017) et qui refuse de « laisser de côté les réalités vécues par celles et ceux qui développent, distribuent et promeuvent les logiciels et technologies concernés » (Vinck & al., 2018). Au-delà de cette approche compréhensive, le rapport à l’écriture logicielle participe à la construction des identités au sens professionnel (Perrenoud et al, 2018) comme au sens large à travers, par exemple, la performance du genre (Faulkner, 2000) dans un monde du travail dominé par les hommes (Jorgenson, 2002 ; Collet, 2006). Enfin, puisque le travail ainsi que le rapport à l’activité informent la structure et les valeurs des professions (Abbott, 1988), s’intéresser au contenu et à l’expérience de l’écriture logicielle éclaire les mondes professionnels de l’informatique dans leur ensemble.

13Prendre pour objet l’écriture des codes nous invite enfin à considérer cette activité dans toute sa matérialité, en commençant par les conditions concrètes de travail. Si l’informatique s’écrit partout, elle s’écrit différemment selon ces conditions de production. Les mondes informatiques témoignent en effet d’une vaste hétérogénéité de statuts (de la développeuse freelance à l’ingénieur salarié), de contextes (espaces militants, service technique dans une autre industrie, entreprise star de la Silicon Valley), d’échelles (des petits scripts personnels aux vastes projets des multinationales du numérique) et d’espaces (bureau traditionnel, espaces de co-working, télétravail). L’analyse de la matérialité de l’écriture logicielle se poursuit dans le rapport à la matière du code. Alors que l’algorithme permet de penser en termes de dispositif, le code incite à se pencher sur l’acte concret d’écriture des programmes, c’est-à-dire la production d’un texte qui sera interprété ou compilé par les machines, inséré dans des infrastructures matérielles et logicielles, lu et amendé par des collègues, copié-collé par des amateur·ices ou hobbyistes et ainsi de suite. En ancrant solidement notre analyse de l’informatique dans la matérialité du code, nous pouvons alors rendre compte de la diversité, des tensions ou des conflictualités qui traversent ces pratiques, c’est-à-dire comment s’écrivent les codes.

14L’ambition de ce numéro spécial n’est pas de proclamer que tout est code ou que le code serait le seul objet valable ; cela reviendrait à dénoncer un réductionnisme pour le remplacer immédiatement par un autre. Séparer complètement le programme du code serait artificiel ; en revanche, cette distinction peut nous aider à penser l’informatique sous tous ses angles. Ainsi, si programmer se rapporte à la planification et à l’architecture informatique, alors coder désigne le rapport concret et matériel à la construction logicielle. En nous intéressant de près aux codes, nous ne documentons pas seulement une activité essentielle et quotidienne de l’informatique : nous pouvons également observer et analyser comment d’autres objets, algorithmes ou autres, se manifestent dans les pratiques matérielles. C’est pourquoi ce numéro spécial prend l’écriture informatique à la fois comme objet d’analyse et comme porte d’entrée dans « l’intérieur » des infrastructures numériques.

2. Poser d’anciennes questions à un nouvel objet

15L’informatique a beau s’être démocratisée, massifiée puis banalisée durant les quatre dernières décennies, le code donne encore aujourd’hui l’impression d’être un nouvel objet pour la sociologie. Cette sensation de nouveauté s’explique probablement par le peu de recherches empiriques qui existent au regard de l’immensité du terrain informatique. Par conséquent, le code peut parfois apparaître comme un objet effrayant, demandant des efforts considérables de théorisation pour se laisser apprivoiser. Selon nous, l’écriture informatique présente justement l’avantage de se trouver à l’intersection de nombreuses traditions de recherches. Autrement dit, cet objet permet de mobiliser un vaste éventail d’ancrages théoriques, de questions heuristiques et de stratégies empiriques. Dans l’esprit de la revue RESET, ce numéro spécial est donc une invitation à emprunter et à faire évoluer des questions sociologiques anciennes, voire classiques, afin de les appliquer aux codes.

2.1. Du pouvoir des algorithmes aux savoir-faire informatiques

16Les discours sur les figures mythiques du numérique comme sur les algorithmes insistent, chacun à leur manière, sur la puissance de l’informatique. La représentation du hacker met l’accent sur le rôle émancipateur de cette activité pour l’individu, tandis que la réduction algorithmique se drape plus volontiers dans les plis du déterminisme technologique. Malgré leurs différences, ces discours posent d’abord la question du pouvoir. S’intéresser à l’écriture des codes, c’est mettre de côté − au moins temporairement − la question de ce que peut l’informatique pour enquêter sur ce que savent les informaticien·nes.

17Comment une ingénieure trouve-t-elle la bonne ligne de code pour résoudre un bug ? Pourquoi un codeur choisit-il telle convention de style plutôt qu’une autre ? Comment un architecte système se sent-il contraint par des décisions prises plus de trente ans auparavant ? Comment un groupe de développeurs développe-t-il une représentation collective du code sur lequel ils travaillent ? Que veut dire cette personne quand elle déclare devoir réparer cette infrastructure « à la main » ? Nous proposons, en somme, de revenir aux premières questions de l’anthropologie cognitive et de les appliquer aux personnes qui écrivent les logiciels. Qu’ont-elles besoin de savoir pour faire ce qu’elles font ? Comment s’y prennent-elles pour savoir ce qu’elles savent (Hutchins, 1994) ? L’écriture informatique se révèle alors comme un vaste ensemble de pratiques, de savoirs et, surtout, de savoir-faire.

18Étonnamment, ce déplacement du politique vers l’épistémique ne limite pas l’informatique à un simple exercice intellectuel. Au contraire, étudier l’informatique comme elle s’écrit nous invite à la considérer comme une activité concrète. Le code se présente comme un texte, c’est-à-dire comme une matière qui dispose de ses propres contraintes. Cette matière devient un objet de connaissance et d’action grâce à de nombreux outils qui composent un environnement numérique. En tant qu’inscription, le code se trouve de facto dès le départ étroitement inséré dans une vaste infrastructure scripturale (Denis, 2018) qui résulte elle-même d’une longue histoire de construction et de maintenance. Analyser l’écriture informatique, c’est enquêter sur des savoir-faire en prise avec la matérialité du texte, qui s’appuient sur des connaissances et sur des actions situées dans un environnement scriptural, qui héritent des contraintes techniques passées et qui se développent autour de normes et de représentations collectives.

19En mettant la lumière sur ce que savent les travailleur·euses du code, nous nous apercevons aussi de tout ce qui échappe à leur connaissance. Écrire du code, c’est constamment se heurter à des zones d’ombre, à des imprévus, ne serait-ce que dans le cas anodin d’un bug qui se manifeste sans cause apparente. L’ignorance peut aussi être plus radicale et pourtant ne poser aucun problème, par exemple quand des ingénieurs utilisent un algorithme sans comprendre comment il fonctionne. La sociologie de l’écriture informatique peut alors dessiner les contours des savoirs informatiques en action, expliquer pourquoi certaines zones d’ombre passent inaperçues tandis que d’autres deviennent des territoires à explorer, et souligner les stratégies mises en œuvre à la fois pour contourner l’obscurité ou pour y faire la lumière.

2.2. L’acte d’écriture pour interroger le pouvoir du code

20Petit à petit, interroger ces savoir-faire de l’écriture informatique précise ce que peuvent faire les codeur·euses et, in fine, ce que peut véritablement le code. L’analyse fine de ces pratiques évite le piège du « fétichisme du code » dénoncé par Wendy Chun, une pionnière des études du code (Chun, 2008). Cet écueil consiste, dit-elle, à confondre le code source et son exécution par la machine. Cette confusion s’explique par l’histoire militaire et genrée de l’informatique : « dans l'armée, il n'est pas censé y avoir de différence entre un ordre donné et un ordre exécuté » (p. 304). Cette approche critique du pouvoir du code l’amène à contester la célèbre expression « code is law » de Lawrence Lessig. Selon la chercheuse, ce précepte exprime un fantasme de ce que devrait être la loi, fondé sur une image embellie de l’exécution du code. Elle invite plutôt à s’étonner du fait qu’un logiciel puisse résulter d’un code et à se demander comment le code peut devenir exécutable.

21Si l’objet algorithmique permet de réfléchir en termes de dispositifs, il favorise une vision intellectuelle de la programmation, détachée des moyens avec lesquels le code est implémenté. Rappelons que la programmation n'est pas nécessairement liée au numérique, ni même aux ordinateurs (Aspray, 1990). Avant l’apparition des premiers langages alphanumériques dans les années 1950, les algorithmes étaient directement programmés à l’aide d’artefacts matériels, comme les fameuses cartes perforées du métier Jacquard ou les machines tabulatrices (Gardey 2008, p. 263–267). Alan Turing (1937) emploie d’ailleurs le terme computer pour désigner un « calculateur », c’est-à-dire non pas une machine, mais un être humain qui calcule (Mélès, 2015). De même, les dernières évolutions du machine learning rendent possible l’exécution d’instructions qui n’ont pas été explicitement codées. Compris comme méthodes systématiques pour résoudre un problème, les algorithmes existent même en dehors de la sphère numérique, par exemple dans la résolution de casse-têtes comme le Rubik’s Cube. En somme, pour emprunter les termes de l’anthropologie de l’écriture, le code et les algorithmes désignent des technologies intellectuelles et des cultures matérielles différentes (Goody, 1979) qui, si elles se recoupent parfois, ne sont pas équivalentes.

23En même temps, nous pouvons aussi considérer comment l’acte d’écriture, une fois qu’il a pris effet, fait autorité dans les milieux informatiques. Cette autorité explique pourquoi les ingénieurs préfèrent recourir à des logiciels plutôt qu’à de simples guides de conduite pour faire respecter des normes techniques. Elle explique également pourquoi certains codes peuvent devenir un enjeu de luttes pour des groupes aux intérêts divergents. Penser l’informatique comme une forme d’écriture interroge ainsi la construction technique et sociale d’un pouvoir scriptural, tout en prenant au sérieux la réalité des effets que produit l’écriture (Denis, 2018).

2.3. Discours de codification, pratiques du code

24Ainsi l’activité d’écriture du code n’échappe-t-elle pas au processus de « rationalisation intellectualiste que nous devons à la science et à la technique scientifique » (Weber, 1959). En effet, certains discours insistent sur le caractère « maîtrisé », « efficace » et « prévisible » de la pratique. Plutôt que de renforcer cette illusion d’un domaine entièrement normé et rationalisé, à l’instar des « discours de vérité » des promoteurs du Web 2.0 (Bouquillion et Matthews, 2010), nous appelons à « montrer comment les acteurs sociaux négocient la signification de chacun de ces mots avant de les imposer aux autres comme des vérités premières » (Callon, 2013). Pour répondre à ces discours, bien des recherches montrent que les usages d’une technique peuvent échapper à ses producteur·ices (Jouët, 2000 ; Proulx, 2015), par exemple quand les utilisateur·ices s’approprient, détournent ou réinventent les scripts (Akrich 1987 ; 2010). Les contributions de ce numéro empruntent le pas à ces travaux et les prolongent en examinant les usages des personnes qui produisent les logiciels. Autrement dit, coder n’est pas seulement créer ; c’est aussi utiliser des outils et des techniques.

25Cette perspective nous conduit à distinguer les pratiques du code et les discours sur le code, qui sont souvent des discours de codification. Dans un texte intitulé « Habitus, code et codification » (1986), Pierre Bourdieu s’intéresse aux processus sociaux de formalisation des normes, en particulier dans les domaines juridique et linguistique. Selon lui, « codifier, c’est à la fois mettre en forme et mettre des formes » : les règles censées formaliser la pratique deviennent un enjeu de lutte et de contrôle en elles-mêmes. L’écriture informatique est traversée par des phénomènes similaires. Nous y observons des processus de codification aussi bien formels, par exemple la mise en place et la négociation de standards du web au sein du W3C, qu’un jeu sur des pratiques informelles, comme l’usage du copier-coller à partir de la plateforme de questions/réponses StackOverflow. La maîtrise du code s’accompagne donc d’une maîtrise des codes, qu’ils soient explicites ou implicites.

26Le respect des normes (« se mettre en règle »), leur subversion (« jouer avec les règles ») ou leur abrogation (« briser les règles ») n’auront pas la même valeur symbolique selon le contexte : rationalisation et optimisation des processus de production dans l’ingénierie, valeurs prônées par l’éthique hacker, appréciation esthétique du code comme forme d’art (Knuth, 1974), proximité avec la « matrice disciplinaire » académique (Millet, 2003). En étudiant les rapports entre activité et discours, entre code et codification, entre le « faire » et le « dire sur le faire » (Lahire, 1998), les écrits informatiques se placent dans la continuité des écrits littéraires, scolaires et ordinaires.

27Pour ce faire, les propos des codeurs qui donnent une cohérence et un sens aux pratiques a posteriori doivent être considérés comme tels. Voilà pourquoi étudier l’informatique comme elle s’écrit ne peut faire l’économie d’une observation empirique de l’écriture, afin d’éclairer un ensemble de pratiques informelles, de micro-pratiques et de pratiques invisibles. La sociologie de l’écriture informatique se trouve alors confrontée à deux défis. Le premier défi est de surmonter une double difficulté méthodologique : que signifie « observer » dans le contexte d’un terrain numérique ? Comment comprendre ce qui se joue dans ces pratiques sans s’appuyer systématiquement sur les discours de codification, mais sans non plus oublier l’importance de ces derniers ? Le deuxième défi pose, quant à lui, le problème de l’écriture scientifique. Comment décrire une activité foisonnante sans perdre le fil de l’analyse ? Comment rendre compte du désordre sans faire désordre ? Comment mettre en forme ces compte-rendus sans reprendre à notre compte les mêmes discours de codification ?

28De toute évidence, ces interrogations traversent toute recherche en sciences sociales. Si la tâche paraît encore difficile en ce qui concerne l’informatique, c’est sans doute que nous ne disposons encore que d’un petit nombre de travaux qui documentent les embûches spécifiques à ces terrains (Mahoney, 2008). Nous sommes donc d’autant plus heureux de regrouper, dans ce numéro spécial de RESET, sept recherches qui proposent chacune une manière originale d’aborder l’écriture informatique, chacune répondant par l’exemple et à sa manière aux questions que nous venons de soulever.

3. Enquêter sur l’écriture informatique

29Ce numéro s’ouvre sur une enquête dans le monde des développeurs de la Silicon Valley, qui situe l’informatique dans ses conditions matérielles d’écriture. Olivier Alexandre y explore le quotidien et les spécificités de carrières professionnelles caractérisées par un fort degré d’incertitude. À travers des observations, des entretiens et un suivi d’activité en ligne, l’auteur présente les multiples stratégies mobilisées par ces travailleurs pour répondre aux différentes manifestations de ces incertitudes, que ce soit dans les opérations de conception et de maintenance, dans l’orientation au sein des projets ou dans leurs trajectoires professionnelles. Loin des représentations d’un travail maîtrisé et prévisible, la carrière de développeur informatique est dépeinte comme une course d’orientation au sein d’une pluralité de médiations et d’outils. En faisant apparaître les « prises » individuelles susceptibles d’orienter l’action et de réguler l’incertitude, par exemple l’obsolescence rapide de certaines compétences, cette contribution nous renseigne plus finement sur les processus à l’œuvre au sein d’un marché du travail traversé par des injonctions récurrentes à « l’évolution, l’agilité et la fluidité ».

3.1. Savoir et ignorance dans la production logicielle

30Après cette analyse des carrières de l’ingénierie logicielle, deux ethnographies nous plongent dans le détail de l’écriture informatique, en particulier dans ses aspects épistémiques et pratiques.

31Tout d’abord, Tudor Ionescu consacre une étude ethnographique d’une grande richesse à une pratique courante et pourtant considérée comme mauvaise, le hardcoding. Cette pratique consiste à spécifier un mécanisme ou une donnée de la manière la plus explicite possible dans le code lui-même, sans se donner la peine de réfléchir à une solution plus générale à un problème précis. À travers plusieurs vignettes, l’auteur suit les péripéties d’une équipe de développement qui doit prochainement faire la démonstration d’un robot intelligent sur une chaîne d’assemblage. Or les ingénieurs n’ont ni le temps, ni les moyens de développer cette technologie. Ils ont donc recours au hardcoding et dictent de façon extrêmement précise et − littéralement − millimitrée les mouvements que la machine doit effectuer, plutôt que d’inventer une intelligence qui déciderait des mouvements par elle-même. Alors que le code reflète l’étendue de ce que la machine ne sait pas faire, son exécution aboutit à une performance convaincante de la part du robot, qui donne l’impression que cette intelligence artificielle est à portée de main. En plus de documenter un grand nombre de problèmes typiques de l’écriture informatique industrielle (dette technique, integration hell), cette enquête propose une réflexion passionnante sur la dualité entre code et exécution ainsi que sur la question de la performativité. L’auteur montre également comment l’écriture du code est directement liée aux contraintes de l’économie de la promesse, au fonctionnement par projets et aux exigences de production.

32L’article suivant ouvre une fenêtre sur une séquence particulièrement ordinaire de l’écriture informatique : un épisode de débuggage. Dans une étude méticuleuse, Florian Jaton choisit de décortiquer étape par étape une scène de quelques minutes à peine afin de mieux entrer dans la profondeur − parfois vertigineuse − de chaque moment d’écriture. Au sein d’un laboratoire de traitement de l’image et au côté d’une chercheuse qui rencontre un bug, l’auteur montre comment la codeuse adopte temporairement une attitude d’enquêtrice et cherche à comprendre d’où vient le problème. Pendant quelques instants, son poste de travail se transforme en une sorte de laboratoire qui sera le théâtre de multiples petites expérimentations visant à isoler la ligne responsable du bug. L’auteur observe et décrit de près ces diverses expériences, qui vont de l’utilisation de documentation, de forums en ligne et d’instruments techniques comme un débuggueur. Au gré de cette description dense, au formalisme original, l’activité gagne progressivement en consistance. La chercheuse mobilise différents savoir-faire pour renseigner l’état « d’entités lointaines » mal connues, comme l’interpréteur, à travers une série d’inscriptions (code, documentation, sortie de l’interpréteur) qu’il faut parvenir à aligner correctement. Ces petits moments de production de connaissances, assez proches de la démarche scientifique, font la lumière sur ces instants anodins et éphémères de l’écriture du code.

3.2. La codification du code : du style aux standards

33Les pratiques du code, comme le hardcoding ou le débuggage, se trouvent souvent en prise à des processus de codification. Ces interactions entre code et codification font l’objet des deux contributions suivantes de ce numéro. La première revient sur la standardisation dans le domaine du web ; la seconde s’intéresse à la codification du style dans l’industrie informatique.

34En s’intéressant aux arènes de standardisation que sont le W3C et l’IETF, Julien Rossi décrit les discussions, les controverses et les formes de consensus qui s’y développent. Dans ces espaces où la communication a lieu au croisement de rencontres en présence et d’outils numériques de coordination, l’auteur documente les enjeux méthodologiques à multiplier les types de matériaux. Entretiens, observations, analyses de compte-rendus de réunions et de listes mail ouvrent ainsi des pistes pertinentes, à condition d’en identifier les limites respectives et de resituer la genèse de ces sources. Dans ces espaces où « l'injonction au consensus » est omniprésente, les acteurs privilégient le régime de justification technique pour exprimer leurs désaccords et leurs critiques. Cette norme est renforcée et régulée par les formes de sanction et de (re)cadrages qui ont lieu dans les débats. Le croisement des matériaux donne alors à voir les postures critiques et politiques des intervenants et révèle les stratégies discursives qui se déploient dans ces espaces de négociation.

35Pierre Depaz aborde, quant à lui, une autre sphère de la codification de l’écriture informatique : la régulation et la négociation du style. L’auteur y analyse la tension entre la dimension subjective du style, comme une préférence personnelle dans l’utilisation d’un point-virgule à la fin d’une ligne de code, et l’émergence de normes collectives. Ces dernières visent à maintenir la cohérence du style sur l’ensemble d’un projet, même quand plusieurs personnes y participent. Ces normes sont souvent codifiées dans des guides de style, qui constituent l’objet central de l’article. En comparant trois guides de style populaires qui s’appliquent au langage Javascript, l’auteur cherche à comprendre comment le contenu de ces guides est négocié, quels arguments sont mobilisés et quels registres de justification finissent par l’emporter. Si le répertoire argumentatif est commun aux trois guides, chacun présente ses spécificités, en particulier quand le guide s’accompagne d’un logiciel qui relève, voire corrige automatiquement les passages qui dérogent à ses normes. L’article explore ainsi, parmi d’autres tensions entre code et codification, la force de l’argument d’autorité technique.

3.3. L’autonomie de l’écriture informatique en question

36Ce numéro s’achève par deux contributions qui étudient comment l’écriture informatique s’insère dans un ensemble de pratiques industrielles. Elles examinent ainsi l’autonomie relative de l’écriture informatique, tout d’abord face à des processus d’insécurisation dans le cadre du développement d’un protocole de chiffrement ; ensuite face à un ensemble de pratiques de guidage dans le contexte de l’élaboration d’algorithmes de recommandation.

37Dans une enquête sur des développeurs qui travaillent sur un protocole cryptographique, Sylvain Besençon explore les enjeux autour de la sécurité du code informatique. En s’intéressant à la fois aux moments critiques et aux instants routiniers de maintenance et de soin apportés au code, il explicite les efforts constants pour le rendre moins vulnérable. Loin de la représentation d’un univers de la sécurité régulièrement perturbé par des failles et des coups d’éclat, il insiste sur la dimension collective et cyclique de sécurisation et d’insécurisation du code. Chaque nouvelle inscription risque de rendre le code plus fragile, même lorsque l’écriture vise à résoudre un problème de sécurité. En renseignant des pratiques peu documentées à l’aide d’un matériau varié (conférences publiques, entretiens, observations, discussions en ligne, plateformes de partage du code), l’auteur invite à déplacer le regard sensationnel porté sur les enjeux de sécurité vers l’examen de pratiques routinières de clarification, d’amendements ponctuels et de maintenance quotidienne. L’(in)sécurisation est ainsi analysée comme un processus de continuité plutôt que de rupture, inscrit dans des dynamiques de collaboration au croisement de différentes sphères d’acteurs (organisations, entreprises, monde académique).

38Le dernier article montre comment un certain nombre d’outils, notamment algorithmiques, équipent l’écriture du code. Camille Roth et Jérémie Poiroux examinent de nombreux entretiens avec des personnes responsables du développement d’algorithmes de recommandation. Les auteurs montrent que cette écriture s’appuie sur un grand nombre d’infrastructures et d’outils algorithmiques afin de réparer, d’ajuster ou de faire évoluer le code de leurs propres algorithmes. Ils s’intéressent en particulier à la pratique fort répandue, mais jusqu’ici peu documentée, de l’A/B testing. Cette dernière consiste à proposer différentes versions d’une même fonctionnalité afin de quantifier l’effet de chaque variation sur les usages d’une plateforme donnée. L’exploration de ces pratiques souligne que, contrairement à l’image d’une ingénierie logicielle complètement rationalisée et planifiée, nombre de développeurs bricolent. Ils ne cherchent pas vraiment à ouvrir les boites noires algorithmiques qu’ils déploient ; la plupart se contentent de multiplier les tests afin de retenir les variations qui semblent donner le meilleur résultat. Les auteurs discutent des conséquences théoriques et méthodologiques de ce résultat puisqu’in fine, cette forme d’écriture informatique semble moins traversée par des problèmes algorithmiques que par des enjeux de quantification et de benchmarking.

4. Conclusion. L’informatique comme pratique et comme croyance

39Dans leur fameux article L’informatique comme pratique et comme croyance, Michel Gollac et Francis Kramarz (2000) constatent « l’impossibilité d’un “champ informatique” autonome » en parlant de toute pratique liée à l’utilisation d’un ordinateur, de la bureautique à l’écriture du code. Sans négliger les recherches qui considèrent les programmes et leurs usages numériques dans leur globalité, ce numéro montre l’intérêt d’adopter une définition plus précise de l’informatique, saisie par les pratiques du code. Si la piste de l’écriture informatique nous semble particulièrement prometteuse, elle n’est qu’un point de départ parmi d’autres pour explorer « l’intérieur » des infrastructures numériques.

40Poser de nouvelles questions, construire de nouveaux objets : ce numéro est avant tout une invitation à explorer l’informatique sous toutes ses coutures, avec une curiosité et un enthousiasme renouvelés. Au-delà des questions théoriques et de leurs éclairages sur l’activité informatique, nous espérons surtout que les contributions de ce numéro contribueront à fournir des exemples concrets d’enquêtes et de compte-rendus originaux sur ce type de terrain, susceptibles d’encourager l’exploration des pratiques et des croyances des mondes informatiques.