Se figurer un problème dans une équipe confinée : confrontation et projection

La première façon pour se figurer un problème public dans une équipe confinée, est la confrontation : en exposant un monde possible (projet d’application) aux autres participants, aux acteurs extérieurs à l’équipe, le collectif de code met le projet à l’épreuve.

Ils sont amenés à reconsidérer leur premier « problem statement », et, par conséquence, revoir le cahier des charges.

Lors du hackathon Hack4Good (4-6 octobre 2016) une des équipes confinées constituée exclusivement des développeurs, a choisi pour projet d’adresser le problème de manque d'hébergement pour les personnes sans domicile fixe. L'objectif de ce projet, appelé

« BeWarm », consistait initialement à prototyper une application permettant aux bénévoles de proposer un hébergement, un repas ou une douche chaude aux personnes sans domicile fixe. A la fin du premier jour du hackathon l'équipe a présenté le projet pendant un des points d'étape, qui était organisé devant une caméra web et transmise en direct aux autres pays participants. Les auteurs du projet BeWarm ont été confrontés à deux questions critiques de la part de l’équipe de Biélorussie : « Comment les personnes sans domicile fixe pourront accéder à ces informations? N'y a t-il pas de soucis de sécurité si on donne l'accès aux adresses des personnes à tout le monde ? »

Suite à cette question une discussion a été ouverte qui a impliqué les autres participants du hackathon. Elle a porté sur les problèmes de la fracture numérique d'un côté et de la sécurité et des données privées de l'autre. Le débat a conduit les participants à remettre en cause le principe même du fonctionnement de l'application, de revoir son architecture.

Si initialement l'application prévoyait un applicatif crowdsourcing (donc, une solution technique impliquant une base de données collaborative et ouverte, les données produites par les usagers), après ce reality-check qui a démontré la fragilité du schéma choisi, l'application a été repensée. Nouvelle architecture impliquait une double interface : une interface utilisateur pour le bénévole qui propose l’hébergement, et une « backoffice » destinée aux services spécialisés (comme Fondation Abbé Pierre, ou le 115). Le collectif de code s'est donc élargi et a inclut un nouvel acteur, une organisation non-gouvernementale spécialisé en aide aux personnes sans domicile fixe.

90

Au début ce nouvel acteur n’existait que comme une projection. Cependant le matin du deuxième jour un des développeurs a réussi à joindre la Fondation Abbé Pierre par téléphone et a eu une discussion avec une des employées à propos de leur projet d'application.

L'employée a confirmé que la Fondation aurait hypothétiquement besoin de renfort car les asiles de nuit n'ont souvent pas de places libres, surtout en hiver. Elle a ensuite précisé que la Fondation disposait déjà d’une base de données des bénévoles, et qu'il était possible d'intégrer les données provenant de l'application dans cette base, plutôt que de développer une deuxième interface back-office.

Cette petite conversation téléphonique a transformé le projet, car elle a montré une opportunité réelle de greffer l'application à un réseau existant. Cette entrée par la passerelle technique (l’API qui connecterait l’application BeWarm avec la base des données de l’ONG) ouvre potentiellement une possibilité d’enrôler des acteurs (Fondation Abbé Pierre) et, à travers eux, toucher la population fragile, à qui l'application voulait apporter de l'aide dès le départ mais qui n'était pas si accessible.

Paradoxalement, pour que l'application puisse apporter de l'aide à un SDF il a fallu rendre les données inaccessibles aux SDF, mais passer par une ONG spécialisée. Il a fallu rallonger le réseau, y faire venir un nouvel acteur pour le rendre robuste. La solution technique finale a été donc une application de crowdsourcing unilatéral, avec une base de données fermée et destinée qu’aux organisations spécialisées.

L'expérience du problème est importante pour définir les besoins et s'approcher au maximum au « réalisme » attendu (assurer la possibilité de faire advenir ce monde possible, de le raccorder aux autres mondes). Nombreux cas de projets que j’ai observés du début à la fin démontrent cette tendance du collectif de code à s’ouvrir à de nouveaux acteurs, dotés de l’expérience du terrain. Ainsi par exemple, pour la Croix Rouge Française le travail sur leur application « CartoCrise »⁵⁶ a commencé au sein d’un collectif confiné. La première réunion de préparation a été organisée dans les locaux de Orange, à Villa Bonne Nouvelle, avec un objectif de travailler sur ce que les organisateurs appelaient des « use-case », des projets plus ou moins développés et concrétisés d’applications.

A cette première rencontre, le collectif de code comportait seulement les représentants de la Direction du Service Informatique de la CRF, experts en informatique, Angélique, Lorent et Thierry. Ils ont déterminé les premières grandes lignes de travail : un outil d’aide à la décision adressé aux coordinateurs de la Croix Rouge, « une sorte de dashboard où on aurait toutes les données nécessaires sous la main ». Selon ce collectif confiné, cette application ne devait

56 Application CartoCrise pour géolocalisation des dégâts causés par des catastrophes naturelles a été prototypée en février 2015 au hackathon BigData Orange. J'ai été amenée à suivre l'équipe dès le début et même assister aux réunions avec les « métiers » (secouristes) du premier meet-up du 16 décembre (préparation au hackathon) jusqu'à la fin de l'épreuve.

91

pas être accessible aux bénévoles de la Croix Rouge. Comme m’a expliqué Angélique, employée du pôle développement et applications, « on ne veut pas confier ces données au grand public, on a des protocoles à suivre très précis, et l’application doit servir à ce but de coordination, gestion de tâches ».

Cependant, après cette première réunion de brainstorming, Angélique m’a confié que, à part la squelette d’interface et des idées de comment relier les différentes sources de données (les données sur les crues du site Vigicrue, les données météo et précipitations, les données statiques sur les personnes fragiles récoltées d’auprès des mairies et des préfectures etc.) ils ne voyaient pas quel aspect précis ça devait avoir. Comment positionner ces informations, comment les placer pour que les coordinateurs puissent naviguer facilement au sein du dispositif et pouvoir l’utiliser réellement en cas d’urgence. Angélique m’a alors annoncé que la prochaine étape de travail sur l’application était d’intéresser les « métiers » (mot des acteurs de la CRF pour désigner les secouristes qui travaillent sur le terrain).

Le collectif de code devait donc être ouvert, pour y laisser rentrer et s’exprimer ceux qui connaissent le terrain et sa réalité changeante. « Ils ont une très bonne connaissance des situations de crise, c’est presque intuitif pour eux, de décider qui fait quoi en cas de crue ou des canicules par exemple », - précise Angélique. Il s’agit ici des connaissances tacites, d’une expertise incorporée et acquise en cours de travail dans des conditions de gestion des véritables périples naturelles. Ces connaissances tacites pourraient donc permettre d’identifier de quelles données les secouristes ont véritablement besoin et en quel ordre (car

« il y a un protocole à respecter »).

Le travail sur l'application, qui a entretemps reçu le nom de « CartoCrise » initialement confié aux départements administratifs et techniques de la CRF, a été donc ouvert aux « métiers », qui ont contribué dans l'élaboration des différentes catégories de données nécessaires pour l'aide à la décision et coordination des bénévoles dans les cas des catastrophes et crises variées. Il n’a pas été facile d’enrôler ce genre d’acteurs : entre la première réunion de préparation du hackathon et la rencontre avec les secouristes, un mois a passé.

Le 19 janvier 2015, j'ai pu finalement assister à la séance de concrétisation du projet, qui a eu lieu dans les locaux de la Croix Rouge. Cette fois-ci Angélique était la seule responsable informatique présente, avec deux acteurs de terrain : le jeune, Gaël, commandant, secouriste de terrain, sapeur-pompier, qui a participé aux nombreuses missions de la CRF, par exemple, à la mission suite au passage de l’ouragan à Paris Roissy en 2005, la mission qu'il avait citée lors de la réunion pour expliquer le besoin d'avoir les données sur les précipitations intégrées dans l'application en temps réel. Il a aussi rappelé l’importance des défibrillateurs : les données à propos de cet équipement sont mises à disposition par les villes. L’autre secouriste, Cédric, plus âgé, a proposé une vision complétement différente du projet. Selon lui, il fallait utiliser la base des bénévoles de la Croix Rouge qui sont nombreux et actifs, mais qui n’ont pas beaucoup de choses à faire en temps de « paix » : il faut s’appuyer sur ce réseau, leur donner accès à l’application, pour qu’ils puissent déclarer des

92

cas de danger ou aider à analyser les nombreux tweets et photos publiés sur les réseaux sociaux après les catastrophes.

Ainsi, le projet initial d’un dashboard fermé en mode « back-office », inaccessible à des publics « profanes », s’est donc ouvert et s’est transformé en une application de crowdsourcing où les bénévoles, les coordinateurs et les secouristes partagent le même champ d’action, tout en apportant chacun ses compétences, et peuvent ainsi co-construire une carte des crises prenant en compte des sources diverses.

Même si initialement le travail sur l'application devait être réservé au pôle Applications et Développement, Gaël s’est joint à l'équipe et a participé à tous les deux jours du hackathon, du 15 et 16 février 2015. La restitution du projet devant le jury a été organisé sous la forme d'une petite mise en scène de passage d'un typhon, coordonnée par Gaël qui a pris soin d'inventer les étapes de déroulement de cette mise en scène, en adéquation avec le règlement des secouristes de la CRF.

Sur ces deux exemples on peut voir que l'expérience du problème et du terrain est importante parce qu'elle permet de faire dérouler la traduction 1 (réduction d’un défi social vers le code) tout en gardant la possibilité de réaliser la traduction 3 (retour vers le grand monde, vers le défi), en veillant que les choix techniques restent en accord avec les réseaux existants. En absence de cette expérience immédiate, en absence de possibilité de confrontation ou de dialogue avec les porteurs de problèmes, les équipes confinées sont amenées à chercher d'autres dispositifs de vérification et de contrôle de la traduction, qui permettraient de dire si les mondes possibles, des solutions socio-techniques envisagées au sein du laboratoire d'un hackathon civique, sont bien transposables à l’extérieur de ce laboratoire. Dans ce cas, pour se figurer un problème une équipe confinée peut se baser sur le sens commun ou bon sens, passer par des projections ou mises en scène d'expérience utilisateur.