De la fonction technique des classifications : entonnoirs entre clients et serveurs

Les classifications servent à établir la communication entre le serveur de l’application et le client (fixe ou mobile). Elles fonctionnent comme des entonnoirs, permettant d’établir des liens de causalité (si X donc Y) entre les catégories choisies par l’utilisateur et les textes des plaintes.

Figure 19 Image 9 : Exemple de code-source de l’application de RosYama avec la catégorie des problèmes et le statut des problèmes, référence

Les catégories « existent » sur le serveur de l’application. Pour chaque usage d’une application mobile, après le choix d’une catégorie le client mobile « appelle » le serveur et reçoit la réponse, un texte de plainte généré. Roman P., développeur de l’application mobile, précise cette communication « client mobile-serveur », via les catégories de problèmes :

« Le site a une API et moi je travaille avec cette API. Je reçois une liste de catégories sur mon appli mobile, c’est tout. Alors, comment ça se déroule techniquement… L’utilisateur sélectionne une catégorie. Il fait une photo, il met son adresse… ça c’est identique pour toutes les catégories. Après il peut sélectionner des paramètres précis qui viennent [du serveur] aussi avec la catégorie. Par exemple, il a choisi « problème sur le trottoir » et il a un paramètre supplémentaire à sélectionner, type de surface

165

« goudron » par exemple, ou bien, « pavés ». Il peut appuyer sur ça et tout ça s’envoi sur le serveur, et le serveur lui renvoi en retour un texte tout prêt. Il peut le modifier un peu, et après appuyer sur « envoyer ». Voilà. Donc on utilise les catégories qui existent sur le serveur, et le texte est généré sur le serveur aussi ».

[Entretien avec Roman P., développeur de l’application mobile version Android pour Krasiviy Peterbourg, référence]

Le langage des catégories n’est donc pas qu’un langage qui détermine la communication entre les humains (citoyens, administrations), entre les humains et non-humains (l’utilisateur et l’interface utilisateur), mais aussi entre les deux machines (client mobile et serveur). Les classifications et catégories sont ainsi, comme le notent Bowker et Star, autant nécessaires pour la communauté que pour les designers du système, car ils permettent d’inscrire des liens de causalité, des commandes qui lient les deux non-humains et permettent, entre autres, la génération d’une plainte.

Dans le cas de l’application WebNabludatel, par ailleurs, les catégories font également un travail important. Elles permettent de construire un lien automatique entre l’action de l’utilisateur sur son client mobile (sélection de réponse « oui » ou « non » à la question de l’application) et l’identification de la fraude. Le serveur contient des éléments, dans sa base, permettant d’identifier, en fonction des réponses de l’utilisateur sur son client mobile, si tel ou tel article du Code électoral a été violé. Par exemple « Y a-t-il des matériaux de propagande présents dans les 50 mètres autour du bureau de vote ? Si oui, alors : violation de l’article 54, alinéa 10 du Code Electoral. L’identification et le comptage (production des statistiques de fraude) se déroulent de façon automatique, et à la fin un récapitulatif est envoyé par le serveur sur le client mobile. L’activité de vérification est alors déléguée à la machine et aux normes techniques et légales, tandis que l’activité de l’utilisateur est focalisée sur les pratiques de l’attention, perception et alerte (Chateauraynaud, Torny, 1999).

166

Figure 20 - Exemple de récapitulatif d’une session d’observation, avec une représentation graphique des fraudes (en rouge) et des règles respectées (en bleu).

Une autre opération « machine-machine » qui devient possible grâce à ce travail de classification est un choix automatique du destinataire et la transmission/redirection des plaintes. Premièrement, le choix du destinataire se fait en fonction de la localisation de l’utilisateur (via une géolocalisation automatique, comme pour les applications mobiles RosYama ou Krasiviy Peterburg, ou grâce à l’indication manuelle de l’adresse de l’anomalie). Le client « appelle » le serveur via une ligne de commande spécifique, qui fouille dans la base (document spécifique) en identifiant l’adresse de l’organisation en question. Ce qui est intéressant est que, pour RosYama par exemple, la base se trouve sur le serveur du site officiel de l’Inspection Routière : l’application « appelle » alors le serveur qui lui interpelle cette base officielle. Cette dépendance technique des applications citoyennes des sites web de l’administration sera objet d’une analyse plus précise dans le chapitre 4 de la thèse.

167

Figure 21 - Extrait de code qui permet d’extraire la base des bureaux du procureur par régions de la Fédération de Russie.

En gris : attribution de numéros aux régions. L’utilisateur indique sa région quand il remplit le formulaire, l’application « appelle » la base et fournit les contacts du bureau de procureur identifié. Le parquet est mobilisé en cas de non-réaction de l’Inspection Routière. Cet extrait de code représente donc une partie de ce qui peut être considéré comme contrôle citoyen du travail des services publics. L’ironie du code est la dépendance des bases de données et serveurs des administrations publiques que les applications sont censées contrôler.

Non seulement la localisation de l’anomalie (la région, l’adresse), mais aussi le choix de catégorie de problème permet une identification automatique de l’institution-destinataire. L’application agit alors comme un entonnoir : l’utilisateur sélectionne une catégorie dans la liste, et si un destinataire spécifique est attribué, dans la base, à cette catégorie de problème, la plainte va être redirigée sur l’adresse de ce destinataire. Ainsi par exemple, les bases de contacts de l’application RosZKH associent différentes instances de surveillance (inspections) aux différents problèmes. L’application « appelle » la base pour associer le problème et son destinataire. L’attribution des responsabilités, qui constitue, selon Daniel Céfaï, un des éléments de construction de problèmes publics, est ainsi automatisée, inscrite dans le code de l’application.

Cette attribution de responsabilités, ou de destinataires, est aussi source d’agencements, de négociations entre l’équipe de l’application (techniciens, militants, juristes) et les administrations publiques. Le code garde les traces de ces négociations. Il est « rouvert » et « réécrit » chaque fois qu’une nouvelle institution accepte de collaborer avec l’application. Par exemple, dans le cas de l’application Krasiviy Peterburg, à partir de 2014 les destinataires ont été modifiés pour les problèmes relatifs aux normes de sécurité sur les chantiers, permis de démolir ou construire, travaux sur la route : l’Inspection Administrative et Technique de l’Etat (GATI) a accepté de recevoir les plaintes directement sur son adresse mail officiel et les traiter dans les délais plus brefs (du 37 au 8 jours).

169