Ce que les interfaces font aux plaintes

«Une situation problématique n'a de sens que si elle se rend racontable » Daniel Céfaï (2013 : p. 18) Les interfaces des applications, avec leur système de check-list, de standardisation et classification des expériences de trouble, font quelque chose au langage même des plaintes, à la manière dont les utilisateurs mettent en récit leurs problèmes. Le besoin de construire un langage et un système de classification qui serait à la fois efficace pour l’interaction « homme-machine », « machine-machine » et « citoyen-administrations » transforme la manière de communiquer.

L’exemple de l’application Stop Le Contrôle au Faciès est dans ce sens assez impressionnant. Partant des nombreux témoignages oraux des cas de contrôle, de violence verbale et physique récoltés pendant trois ans d’existence du Collectif SLCAF, les militants et développeurs sont arrivés à produire une check-list assez fermée, consistant en une liste de questions bien précises. C’est à partir des réponses à ces questions que le caractère abusif du contrôle, et le délit du faciès doivent se constituer (ou pas). Les enquêtes menées par les membres du SLCAF, ensemble avec les défenseurs des droits, l’expertise du Guide du Contrôlé ont été synthétisées et incorporées en une check-list simple :

170

L’interface actuelle de l’application traduit le récit oral dans une forme graphique stricte, proposant de sélectionner, par exemple, entre les « types de violence ». Les dernières mises à jour (que j’ai suivie dans le bureau du Collectif mais aussi à travers les échanges de mails) ont montré que cette question était très compliquée pour les utilisateurs : les développeurs ont donc été obligés de permettre de faire plusieurs choix (physique ET verbale…). Les débordements de ce cadrage du récit seront traités de manière plus extensive dans le chapitre 3 consacré aux limites de l’organisation du monde « par interfaces ».

Le back-office de l’application représente les histoires (auparavant longues, non-structurées et non-linéaires, comme on l’a vu plus haut) en forme de lignes :

Figure 23 Capture d’écran réalisée le… d’un cas déclaré sur l’application SLCAF (back-office), le 19 juin à 01 :10 par un homme, année de naissance 1967

L’application RosZKH agit, elle aussi, sur la mise en récit des situations problématiques, par son design même. Au fait, lorsqu’il veut porter plainte, l'utilisateur doit remplir très peu de champs : région, nom, prénom, patronyme, code postale, ville, rue, maison, appartement, e- mail. Dès qu'il choisit sa région, on lui propose les institutions auxquelles il veut envoyer sa déclaration : l'Inspection du Fond de Logement de sa région, l'administration de sa région, le Comité de Logement, Service Fédérale de Surveillance en Matière des Droits des Consommateurs etc. Il peut cocher plusieurs cases (ou toutes les cases) mais pas rajouter une institution en plus. Ensuite il a une possibilité de « décrire le contenu du problème » dans un champ prévu à cet égard. Le champ d’expression libre est limité à 350 caractères. Pour Dimitri T., modérateur actuel de l’application, c'est un moyen technique de contrôle de l'aspect « émotionnel » qui, selon lui, peut nuire à un texte juridique et le rendre moins crédible aux yeux des fonctionnaires :

171

« Tout d’abord, comme l’expérience le montre, c’est suffisant pour… Certains problèmes, on peut les décrire en 140 caractères, format Twitter. Et 350… c’est suffisant. Deuxièmement, on a décidé de se protéger, nous-mêmes et les services de l’Etat, contre les personnes qui aiment bien écrire beaucoup et hors sujet. Vous savez, il y a cette espèce de plaignant professionnels, qui aiment décrire la situation pendant des heures, alors qu’on peut tout décrire en 5-7 lignes ».

[entretien avec Dimitri T., modérateur actuel de RosZKH]

On retrouve cette même obligation (ou consigne) d’écrire « sans émotions » dans l’interface de l’application Zalivaet.spb. Quand un utilisateur crée une nouvelle plainte, une fenêtre pop-up s’ouvre en lui rappelant : « décrivez l’essentiel de votre problème, en quelques lignes, sans émotions ».

Le formatage par le design, le choix automatisé du cadre de description redéfinissent les pratiques de plainte en Russie considérées par les historiens comme un genre littéraire à part entière. Elena Bogdanova, dans son analyse des plaintes à Vladimir Poutine en termes de justification, proposés par Boltanski et Thévenot (1991), démontre que le « texte des plaintes contient le langage des deux côtés, l’auteur et le destinataire » (Bogdanova, 2013 : p. 13). Dans le cas des applications citoyennes, le langage de l’auteur est remplacé, totalement ou en grande partie, par celui de la machine. La justification en termes de catégories d’expérience personnelle est remplacée par une légitimation qui se réfère aux normes légales et techniques. Cette traduction à un double sens, comme je voulais le montrer ici, à la fois technique et politique. La proposition d’une classification standardisée et d’un langage de description unique permet d’automatiser certains processus de traitement des données, mais aussi d’avoir une homogénéité des données. Comme le notent Timmermans et Berg, « les standards visent à rendre les actions comparables dans le temps et dans l’espace » (1997, p. 273). En produisant cette comparabilité des cas isolés, on rend possible une manipulation des données, une interprétation de celles-là qui peut aider les porteurs de problème de le publiciser.

Les interfaces transforment non seulement les pratiques de plainte, mais aussi les pratiques d’attention, de perception, de vigilance. Comme Francis Chateauraynaud et Didier Torny le notent, la vigilance citoyenne commence à partir des actes basiques de perception directe de ce qui ne va pas : voir, sentir, toucher une anomalie (2013). Mais, comme l’affirment les auteurs, cette perception initiale n’est que le premier pas vers un acte de lancement d’alerte : les citoyens doivent traduire leurs perceptions en un narratif, ou en code. Ils doivent construire un événement pour rendre leurs expériences tangibles et communicables aux autres. Les applications construisent l’activité perceptive des acteurs, en leur fournissant des systèmes de classifications et des interfaces qui sont, elles, des formes particulières de penser, d’organiser spatialement, temporellement et graphiquement les informations. Une application est un outil de représentation des actes individuels de vivre une anomalie : passée à travers des filtres techno-juridiques d’une application citoyenne, l’expérience se

172

transforme en une alerte transcodée, formatée, exprimée en un langage des institutions auxquelles on s’adresse. Et, pour les administrations, comme le notent les auteurs, « c’est à proprement parler le codage qui construit l’événement » (Chateauraynaud & Torny, 2013, p.38).

173

CONCLUSION DU CHAPITRE 2

Dans le présent chapitre je me suis concentrée sur le développement des interfaces des applications citoyennes, et notamment, sur les opérations de classification, de catégorisation et de standardisation des expériences. J’ai démontré comment, pour les collectifs que j’ai suivis, leur « rencontre » avec le trouble, cette expérience déstabilisante et problématique, est devenue le point de départ d’une reproblématisation et redescription de la situation. L’expérience d’une communication inefficace avec les acteurs institutionnels les a amenés à rechercher d’autres moyens de communiquer avec les administrations publiques, de réattribuer les responsabilités et de produire d’autres des comptes rendus du problème.

Je me suis arrêtée dans la deuxième section sur différents dispositifs qui ont servi aux acteurs dans leur travail d’attribution du sens aux situations de trouble dans lesquelles ils se trouvaient : les guides, les formulaires imprimés, les tableaux Excel. Ces dispositifs, d’accumulation des connaissances, d’accompagnement de la récolte des données et encadrement les activités d’alerte et d’attention, ont produit des premières descriptions, classifications, standardisations des situations problématiques. Fort de cet équipement, les acteurs se sont lancés dans le développement d’interfaces numériques, des objets plus solides. Cependant, la traduction en application a généré une déformation de ces matériaux, avec une certaine forme de perte de matière, de complexité dans la description des problèmes. De ce fait, ces dispositifs scripturaux n’ont pas été totalement substitués par les interfaces numériques, mais continuent à être employés et constituent, pour les utilisateurs, une façon de contourner le cadrage par les interfaces.

Dans la troisième section j’ai examiné l’élaboration des catégories de problèmes et des menus des applications citoyennes. Je montre l’importance des normes juridiques et techniques pour le développement des classifications. Réutiliser, traiter, simplifier la loi et la « mettre en code » permet d’assurer une intermédiation entre utilisateur, serveur de l’application avec son système de traitement des données, et institutions publiques.

J’interroge aussi la signification des catégories pour le code informatique et la communication entre le client et le serveur. Les classifications de problèmes ont un double sens, à la fois pour les développeurs et pour le public porteur du problème, car elles définissent un cadre commun de référence. Ce cadre de référence fait quelque chose à partir du langage des plaintes, encadre la mise en récit des expériences personnelles, les rend à la fois « racontables » et « audibles » et les inscrits dans un horizon de problèmes publics. Les applications citoyennes ainsi décrites deviennent des dispositifs d’énonciation qui reconfigurent la communication entre citoyens et administrations concernés. Daniel Céfaï explique « la disponibilité des catégories publiques ménage une place dans le monde social où il devient possible de questionner sa propre expérience; de l'analyser et de la verbaliser: cette expérience devient audible, intelligible et significative du point de vue du public. On peut être un mineur silicosé ou un habitant irradié, une femme battue ou un Noir discriminé,

174

on n'est rien tant que n'existe pas un dispositif d'énonciation pour le voir et le dire publiquement – soit un langage, une place d'énonciateur et une place de destinataire…» (Céfaï, 2013 : p. 19)

Les opérations de standardisation et classification, étudiées dans ce chapitre, permettent à des problèmes d'émerger. Etablir des classifications de problèmes (anomalies, défauts, fraudes) paraît indispensable pour mettre en place un système de traitement automatisé des plaintes individuelles, leur visualisation sur les cartes collaboratives. Ces contre-listes, qui réutilisent le langage des administrations et s’appuient sur des documents administratifs et techniques, sont autant des moyens de réappropriation du problème qui renforcent la capacité d’agir des applications citoyennes.

Cependant, pour faire les utilisateurs parler en ces « catégories publiques » les applications font quelque chose qu’on peut appeler « verrouillage par la conception » (by design) : restrictions du nombre de caractères, de la quantité et de la taille des photos, le parcours utilisateur déterminé. Ce formatage par le design, ce choix automatisé du cadre de description redéfinissent les pratiques de plainte. Des questions se posent à cet égard.

Premièrement, ne s’agit-il pas d’une certaine monopolisation des problèmes publics ? Les collectifs porteurs de problèmes (ou « problem owners », expression très activement utilisée au sein des communautés hackathon) tendent à s’approprier de la définition du trouble et revendiquent le droit de déterminer, proposer et mettre en place les « meilleures solutions ». Daniel Céfaï décrit ce processus en parlant de la « routinisation des questions et des réponses », le moment où « la structure a saisi le processus », les rôles et les modes d’actions ont été attribués aux acteurs et aux institutions (Céfaï, 2013 : p. 15) Cette question rejoigne la critique portée par Daren Brabham (2013) sur les technologies de crowdsourcing. Selon Brabham, « lorsque le lieu de contrôle [locus of control] est placé du côté de l’organisation, la « foule » n’est qu’un instrument » (Brabham, 2013). Dans ce contexte asymétrique, le projet de crowdsourcing, ses termes et modes de participation, sont prédéfinis par l’organisation, tandis que les utilisateurs n’ont qu’une marge de manœuvre très limitée.

Des questions se posent alors : les interfaces des applications citoyennes peuvent-elles aussi contenir ce risque de verrouillage ou de monopolisation ? Est-ce que les listes de catégories de problèmes permettent de prendre en compte toutes les expériences problématiques ? Des cas particuliers, des « monstres » qui échappent à la classification existent-ils ? Et que fait-on avec ces cas orphelins, ces situations qui résistent à la mise en applications ? Et finalement, quelle est la place des utilisateurs dans ces nouvelles configurations d’intermédiation et de communication ? Acceptent-ils le langage des applications, ou bien essaient-ils de leur côté de contourner le formatage par le design, « hacker » les interfaces des applications ?

175

Dans le chapitre 3 de la thèse je parlerai des limites de la mise en code des problèmes publics, en me focalisant sur le moment où les applications citoyennes sont mises à l’épreuve (des objets techniques, de l’expérience, des usages).

176

Chapitre 3. Le problème « comme il est » : les