LE CODE NE PARLE PAS POUR LUI-MÊME : LES FAILLES DANS LA DOCUMENTATION DU CODE

Mon enquête auprès de l’équipe KP a montré le rôle crucial de la documentation dans le développement informatique. La documentation (ou encore le « spec », en langage des développeurs) est l’ensemble de règles précisées d’habitude avant le code lui-même, qui explique les noms des paramètres à utiliser et décrit le code en « langage humain ». En effet, le code ne parle pas par lui-même, il faut que le développeur « parle » pour faire parler le code. La documentation est cette irruption de la parole du développeur qui sert à donner sens au code et pouvoir l’expliquer aux autres. Elle permet notamment de préciser le système de catégories et leurs significations.

En absence de cette documentation, les nouveaux membres des collectifs de code doivent faire des opérations supplémentaires d’interprétation et d’analyse afin de « rentrer dans le code » (« vyehat’ v kod », mot des acteurs). Comme le notent Bowker et Star, « nous devons toujours comprendre les systèmes de classification en fonction des tâches qu’elles effectuent

185

et du réseau dans lequel ils sont insérés… Des nouveaux membres des mondes sociaux qui entrent dans l’espace de computation d’une communauté, vont souvent trouver ça très compliqué de représenter leurs propres traditions de développement au sein de cet espace.

Ils vont sentir la pression de devoir réinterpréter leur propre passé selon les schémas disponibles ou vont exercer la pression pour changer ces schémas » (Bowker, Star : 1998, p.

238).

Travailler avec le code d’un autre s’avère être une tâche particulièrement difficile. En effet, Alexey avait attribué dans son code des « identifiants valides » ou « significations valides » (validnye znacheniya) mais n’a pas fait de documentation technique. Sans les connaître, on ne sait pas comment créer un protocole propre entre client et serveur.

Toute la période de développement des applications mobiles KP sera alors marquée par des tensions psychologiques, des burn-outs de certains membres de l’équipe, dû à ce problème de traduction. Notamment Dmitry K qui, au bout de deux semaines d’erreurs permanentes va confier qu’il souhaite abandonner le projet si aucun aide ne vient du développeur initial, Alexey K, absent de la discussion les deux premières semaines :

« Si j’essaie de transmettre le mimeType et le nom du fichier, on me dit ‘erreur d’envoi’, et le statut [de la plainte] n’est pas modifié. Si je ne les indique pas, alors la plainte est envoyée, je la vois sur le site, mais je ne la vois plus dans la version mobile.

Stanislav, il faut certainement vérifier ce qui se passe du côté serveur, il faut qu’Alexey nous aide. Je ne sais vraiment plus quoi faire… J’essaie de mettre ce maudit nom dans différents endroits mais sans succès… Il faut voir ce que le serveur renvoie, et qu’est-ce qui nous manque. Sinon, on va passer des siècles à chercher une épingle dans une botte de foin » (Document « Chat des développeurs KP, message du 15.02.2014).

Lorsqu’Alexey apparaît enfin dans le chat, il avoue que « le code n’est pas très propre j’ai codé ‘sur mes genoux’ [na kolenkah]». En effet, l’application KP a été développée pendant un camp d’été organisé par les militants du mouvement « Observateurs de Saint-Pétersbourg ». Alexey a commencé à la coder dehors, à ciel ouvert, et devait finaliser le projet en très peu de temps. La temporalité et les conditions matérielles de codage rapprochent ici des conditions des hackathons analysées dans le Chapitre 1. L’équipe devait donc reprendre un code assez impropre sans une documentation technique précise.

En effet, même si tous les développeurs sont experts dans leurs domaines, le code sans documentation n’est pas un matériau suffisant pour pouvoir le comprendre et travailler avec.

Ils ont besoin d’un narratif, des explications de l’auteur du code, de ses explications pour comprendre qu’est-ce qu’il voulait dire. En effet, dans le travail de développement l’organisation de travail passe par la documentation et la spécification qui sont des formes de classification. Un manque de documentation résulte en problème d’organisation de travail.

186

Donald Knuth, dans son livre « The Art of Computer Programming », compare la programmation et les recettes dans un livre de cuisine, dans le sens où les deux représentent un ensemble de règles à suivre. « Les algorithmes, comme la cuisine, fournissent une méthode, un ensemble de procédures formelles définies qui doivent être performées afin d’accomplir la tâche en un nombre fini de pas » (Fuller, 2008 : p. 237). Si on développe cette métaphore, reprendre le code de quelqu’un est comme récupérer un plat que quelqu’un avait déjà commencé à cuisiner et a abandonné en cours de route. Il n’est pas clair si le plat a suffisamment de sel ou d’épices. Alors, on est obligé d’essayer, de goûter, de se tromper.

Dans les 300 pages d’échanges analysés, les participants avouent à de nombreuses reprises qu’ils ne savent pas exactement où ils vont : « je l’ai fait à l’arrache » (« ya delal naugad »),

« j’ai cliqué à l’aveugle » (« ya tykal vslepuu »), « ça a marché enfin mais je ne sais pas comment je l’ai fait » (« nakonec-to srabotalo, no ya tak y ne ponyal kak ») etc. Ce n’est que le 27 février, plus de deux semaines après le début de travail sur les versions mobiles de KP, que Alexey a rejoint le chat et a pu préciser la nature des erreurs, qui étaient causés par un problème de traduction entre clients et serveur (le langage unique que le serveur comprend) :

« Le serveur pète les plombs à cause des paramètres inconnus. Utilise <str>

au lieu de <street>, et tout va être OK. Ce que j’ai utilisé : region [ID de la région]

Les deux développeurs mobiles, Roman (Android) et Dimitry (iOS), ont dû veiller à ne pas utiliser de paramètres « étrangers » au serveur (exemple : <str> et non pas <street> pour le paramètre « rue »), car si le nom du paramètre est mal choisi, l’appel (call) ne passera pas entre client (qui crée une plainte en chargeant le formulaire du serveur) et le serveur (qui reçoit la plainte et l’intègre dans la base de données, sur la carte collaborative, et qui, finalement, l’envoie à l’administration).

La plainte, elle, se présente ici comme un assemblage : chaque élément de ce qui au final peut nous paraître un texte lisse, est au fait représenté par un élément précis de code, possède son propre « id » (les régions et les villes notamment ont des « ID » officielles de

187

l’état réglementées par des documents comme FIAS et KLADR⁹⁰). La « génération » de la plainte (« obrasheniye ») est au fait un processus de va-et-vient entre le serveur et le client mobile : le client « appelle » le serveur qui stocke les informations nécessaires pour

« assembler » la plainte. La standardisation des paramètres (surtout les régions, villes et adresses) a ici un rôle crucial pour établir la compréhension entre les clients et les serveurs, et entre les usagers et les administrations, comme si les administrations étaient des « serveurs » qui ne peuvent réagir à des plaintes que si les paramètres sont correctement rentrés. La génération d’une plainte par l’application est une forme d’écriture granuleuse, discontinue et compartimentée. Le texte final de la plainte fait ressortir des éléments de l’écriture non-humaine.

Il est intéressant de souligner que les développeurs russes disent qu’ils « assemblent » une application (« sobirat’ prilojeniye ») et non pas « écrivent » ou « développent ». L’application apparaît dans ce sens comme un ensemble de fonctionnalités. On n’écrit pas une application comme un texte lisse, mais on peut travailler sur les fonctionnalités une par une. Le mot anglais « build » utilisé par les développeurs (qui veut à la fois dire le processus de codage et un produit de code) a aussi une connotation de construction (dans le sens d’assemblage d’éléments). L’écriture du code qu’on a tendance à voir comme un texte quasi littéraire (Fuller, 2008), se présente ici comme une activité discontinue, compartimentées, discrète. Il a été d’ailleurs intéressant d’observer, à travers les lectures d’échanges entre développeurs, la non-linéarité de ce processus. Lorsque Roman présente son premier « assemblage » de l’application (« sborka »), qui est prêt pour le 18 février, il décrit l’application à ses collègues comme une liste de fonctions.

« Alors, collègues, à ce jour nous avons : Login, logout.

Choix de catégorie

Choix automatique de lieu sur la carte, ou bien la possibilité de rentrer l’adresse à la main.

Chargement de la photo du problème (mais pas encore de la solution).

Aperçu de toutes mes plaintes (« obrasheniya »), y compris celles qui n’ont pas été envoyées (et on peu les renvoyer)

90 FIAS (Federalnaya Informatsionnaya Adressnaya Sistema, Système Fédéral Informationnel des Adresses, https://fias.nalog.ru/ ) et KLADR (Classificateur des Adresses de la Fédération de Russie http://kladr.ws/ ) sont deux standards de notation des adresses utilisés sur le territoire de la Fédération de Russie. FIAS est plus récent que KLADR et possède une API ce qui facilite son intégration dans les applications. Il est utilisé dans plusieurs applications citoyennes, par exemple, Zalivaet.spb.

188

Choix de paramètres supplémentaires

Et modification du texte avant l’envoie ! (oui, je ne m’y attendais pas moi-même) Le problème connu : pas dans tous les cas l’information supplémentaire est envoyé.

Je peux donc assembler l’app pour ceux qui veulent jouer ».

Les « catégories de problèmes » sont également présentées comme un ensemble d’identificateurs, avec les catégories « mères » et les sous-catégories imbriquées.

Dans les 300 pages d’échanges, les « bugs » les plus courants répertoriés par les développeurs ont été liés au choix des catégories (« je choisis une catégorie, et ça plainte… »), aux images et photos « lourdes » (le choix d’utiliser les icônes au lieu des photos est justement lié à ce problème). Cependant, même si aucun problème n’est observé au niveau « client-serveur », et le protocole de communication s’exécute sans failles dans les laboratoires, les difficultés peuvent s’apercevoir aux moments « quand l’expérience rencontre le formel-structurel » (Bowker and Star, 2007 : p. 274).

189