Le smartphone comme instrument de la relation de service

Petite histoire d’un projet phénix

Nous avons vu, lors du chapitre précédent, que les hackathons peuvent être envisagés comme des dispositifs de coopération dont l’organisation vise à cadrer la participation sur un temps très court. Ici, la situation est toute autre, puisque c’est pour une durée de quatre à six mois que l’équipe lauréate s’est engagée contractuellement à développer l’application avec l’aide de Transilien, pour, à la fin du contrat, céder le produit à l’opérateur de transport. Une première étape pour le collectif de code consistait ainsi à déterminer quels membres du collectif souhaitaient continuer et s’inscrire dans un programme d’accompagnement de l’innovation. En effet, si dans les hackathons on trouve généralement de nombreuses startups et autoentrepreneurs, la plupart des membres de l’équipe Hackcess Angels ne se connaissaient pas auparavant, et nul n’avait prévu de s’engager dans un programme plus long que le hackathon2. Nous avons vu que lors de l’événement, l’équipe était constituée de sept personnes, la plupart ayant déjà des engagements universitaires ou professionnels. Après une première réunion en décembre 2013, Serge a décliné l’option de prendre pleinement part à l’équipe, n’étant pas assez disponible pour s’impliquer fortement dans le projet. Cependant, l’agent est resté disponible tout le long du développement lorsque nous avions des questions sur les métiers de la SNCF. Par ailleurs, suite au hackathon, Benjamin a été recruté par l’entreprise Snips, entreprise partenaire de la SNCF et spécialisée dans la gestion de grands volumes de données3. Sont donc restées cinq personnes : Édouard, Sylvia, Éric, Cédric et moi. Une convention de partenariat nous associait à la fois collectivement et individuellement à Transilien dans l’objectif de réaliser une version de l’application en conditions réelles (dans des gares) dans un horizon de quatre à six mois. Du côté de SNCF Transilien, nous étions en relation avec Viviane, Responsable Pôle Innovation et Partenariats, et Laurence, Chef de produits Service Accessibilité. S’ajoutait, en position d’accompagnement auprès de Transilien, Léa, de l’agence de conseil FiveByFives, prestataire de Transilien pour travailler sur la politique d’innovation ouverte comme nous l’avons vu au premier chapitre La collaboration entre le collectif de code4 et les responsables de Transilien s’est structurée en deux temps : le premier, de janvier à avril 2014, a consisté en la découverte par l’équipe du contexte organisationnel et technologique de Transilien. Cette découverte se donne à voir tant dans les relations de travail (Transilien et l’équipe Hackcess apprennent à travailler ensemble) que dans les démarches visant à inscrire l’application dans l’environnement technologique et organisationnel de l’opérateur de transport, bien différent de celui envisagé lors du hackathon. Le second temps, d’avril à juillet 2014, recoupe les moments de crise de la relation de collaboration. S’il y a toujours un apprentissage réciproque, celui-ci se fait alors dans une tension croissante, vécue par l’équipe comme un basculement d’une relation de collaboration vers un travail de prestation déguisée, dénoncé comme une injustice.

Découvrir le contexte organisationnel et technologique de Transilien

La collaboration entre Transilien et l’équipe Hackcess Angels s’est d’abord constituée par le moyen d’une enquête que j’ai réalisée au profit du projet. En effet, j’ai bénéficié dans l’observation participante d’une position singulière qui, tout en me permettant d’acquérir beaucoup d’informations pour la thèse, a aussi joué un rôle non négligeable dans la poursuite du projet. En janvier 2014, alors que signions la convention, aucun des membres de l’équipe, à part moi, n’était disponible pour travailler la semaine avec les responsables de Transilien. Chacun d’entre eux avait déjà des engagements académiques ou professionnels. De leur côté, Viviane et Laurence, les responsables de Transilien, avaient des horaires de bureau classiques, finissant leurs journées de travail entre 18h et 19h, ce qui signifie que lorsque les membres de l’équipe de conception étaient disponibles pour travailler sur l’application, les responsables de Transilien ne l’étaient plus. Bien que l’envoi d’informations par mail permette de travailler collectivement de façon asynchrone, les réunions étaient nécessaires. Étant le seul à pouvoir être présent aux horaires des uns et des autres, j’ai été chargé, malgré mon absence de compétences en matière de développement de logiciel, de la coordination du projet, et je me rendais régulièrement en fin d’après-midi à des rendez-vous auprès de Transilien pour présenter nos avancées et nos questions, et puis transmettais dans la soirée les informations auprès de l’équipe. Les réunions d’équipe nécessitaient elles aussi une certaine organisation puisque, d’une part, nous étions éclatés géographiquement entre Rennes et Paris (il nous fallait donc être équipés d’ordinateurs et logiciels de visioconférence), et d’autre part, à Paris, nous ne disposions pas de lieu étant à la fois accessible et connecté à internet. En effet, comme j’ai pu le mentionner au chapitre précédent, Éric était myopathe et tétraplégique, il se déplaçait en fauteuil roulant électrique, généralement accompagné de sa mère, Christine, qui l’assistait dans ses déplacements et contribuait parfois aux échanges sur l’application. Malgré nos demandes répétées auprès de Transilien, l’opérateur de transport n’a pas réussi à nous trouver une salle de réunion ouverte en début de soirée répondant aux doubles critères d’accessibilité et de connectivité. Bien qu’anecdotique, ce simple problème de salle de travail est symptomatique de toute l’ambiguïté qu’il peut y avoir à faire du numérique et de la connexion à internet un outil central dans la mobilité des personnes handicapées : bien que nous prenons souvent pour acquise la présence d’une connexion wifi dans les espaces urbains, l’accès au réseau au réseau est souvent bien plus fragile que cela – un problème en l’instance redoublé par le manque d’espaces accessibles disponibles dans les espaces professionnels de Transilien. Les premières semaines ont été consacrées à prendre la mesure de l’environnement technologique et organisationnel dans lequel nous devions développer l’application. Alors que, lors du hackathon, notre méconnaissance du contexte était valorisée car elle nous permettait d’innover, de penser « hors de la boîte », il nous fallait ensuite réarticuler le produit dit innovant au monde de Transilien. Très pratiquement, cette contrainte s’est d’abord matérialisée dans le langage informatique et les marques de smartphone que nous devions utiliser : alors que le projet avait été initialement développé pour des systèmes d’exploitation Android, l’ensemble des agents étaient équipés d’iPhones, doté du système d’exploitation iOS. Cela signifiait que le code informatique devait être écrit dans un autre langage informatique pour pouvoir être utilisé par l’entreprise. Or, aucun développeur de notre équipe n’avait appris ce langage auparavant. Pendant trois mois, Transilien a donc souscrit un contrat de mentorat avec un développeur spécialiste de l’iOS, Bastien, afin que trois membres du collectif de code, Édouard, Sylvia et Éric, puissent suivre trois heures de cours de programmation hebdomadaire, spécifiquement orientées autour du développement de l’application. S’est ajoutée à cela la fourniture par Transilien d’équipements informatiques aux développeurs (iPhones, ordinateurs Apple et licences de programmation). Cependant, l’infrastructure réseau était fournie par Éric, mettant à disposition ses propres serveurs pour ne pas dépendre des autorisations de Transilien lors du développement de l’application. Les questions de licence, généralement difficiles à négocier dans les relations avec des entreprises (Trupia, 2019), ont été très rapidement tranchées : dans la continuité des objectifs présentés au hackathon (ouverture des données, partenariat avec des associations promouvant le logiciel libre), ce sont des licences libres qui ont été choisies pour le développement de l’application. Pendant que l’application était traduite d’un langage informatique vers un autre, j’étais en charge d’affiner notre connaissance des « besoins utilisateurs », c’est-à-dire de réaliser des entretiens et parfois des suivis de trajets avec de potentiels utilisateurs rencontrant des situations de handicap. J’allais également à la rencontre des agents de gare pour comprendre comment l’application aurait pu s’insérer dans leur quotidien. Une des questions principales des responsables de Transilien tenait notamment dans l’usage que les agents faisaient de leur smartphone : l’utilisaient-ils beaucoup ? Quelles différences d’usage pouvait-on identifier en fonction de leurs âges ? Quels « freins et leviers » pouvais-je repérer dans l’utilisation de l’équipement ? Je n’avais pas pour autant de liberté dans le choix des personnes à interviewer : elles m’étaient désignées par les services de SNCF Transilien, après discussion avec les représentants des associations de handicap siégeant au Conseil Consultatif de l’Accessibilité de la SNCF et avec la direction des services concernant le travail des agents. La conception de l’application a ainsi été réalisée en s’appuyant sur trois entretiens et deux suivis de trajet avec des personnes à mobilité réduite, et trois entretiens (individuels et collectifs) avec des agents en gare dans trois gares différentes d’Île-de-France. 

De la collaboration à la prestation ?

Tensions et transformations de la relation de travail du code Ont rapidement émergé des tensions tenant à la fois au statut inhabituel de l’équipe de développement (ni salariée, ni prestataire, mais quasi-bénévole – une faible rétribution financière nous attendait à la livraison de l’application) et à l’appréhension des responsables de Transilien vis-à-vis des deux types de public de l’application, à savoir les voyageurs à mobilité réduite et les agents. Le 16 avril 2014, un premier atelier était organisé par les équipes de Transilien et le cabinet de conseil pour présenter l’application au Conseil Consultatif de l’Accessibilité ainsi qu’à quelques responsables de gare (celles où j’ai réalisé des entretiens mais aussi d’autres, telles que Versailles Chantier, dans laquelle devaient avoir lieu les premiers tests) 7 . L’équipe organisatrice (les responsables de Transilien, Viviane et Laurence, mais aussi Léa la consultante de FiveByFive) avait une certaine appréhension vis-à-vis de la réception du travail de l’équipe Hackcess Angels. Ces appréhensions les ont conduites à une décision qui a détérioré les relations entre le collectif de code et Transilien : plutôt que d’utiliser les visuels de l’application produits par l’équipe, les employés de Transilien ont utilisé des maquettes très simplifiées (on pourrait dire, sans design), qui ne rendaient pas compte du travail déjà effectué par Édouard, le designer de l’équipe. Selon Léa et Laurence, le choix de mettre des captures d’écran simplifiées répondait à la crainte que les visuels existants donnent l’impression que le projet était terminé et que l’atelier, se voulant participatif, sembla alors inutile aux participants. Au chapitre précédent, j’ai pu montrer comment les collectifs de code produisaient des démos (Rosental, 2009) pour convaincre le jury de l’intérêt et de la solidité du projet en dépit de ses fragilités techniques et de la méconnaissance du contexte dans lequel il devait être mis en œuvre. À l’inverse de ces démos qui se caractérisent par leur caractère fermé, affirmatif, la présentation de l’atelier devait être une démonstration ouverte, mettant en scène un exercice plus démocratique, permettant l’interrogation, la discussion (Callon, 2003). Il s’agissait de manier l’incertitude plutôt que la certitude, la faillibilité plutôt que la robustesse, les possibles bifurcations plutôt que le plan d’action. Seulement, dans cet exercice, représentant le collectif  de code, j’éprouvais une certaine contradiction, un certain malaise, puisque l’état d’avancement réel était finalement tu. Sans causer de troubles majeurs, cette situation a néanmoins provoqué quelques quiproquos. Certaines images, préparées dans la précipitation, ont heurté les personnes concernées en leur rappelant la violence des catégories à travers lesquelles les organisations travaillent et classent les personnes (Star, 1990) – un faux pas qui aurait pu être évité. Ainsi, une vignette désignait les personnes en fauteuil roulant du terme « fauteuil », comme des objets alors que les autres indiquaient des mentions institutionnelles aux handicaps (figure 3.1). Une participante (interrompant l’échange au sujet de la diapositive qui vient d’être projeté) : Je ne suis pas sûr que la dénomination de fauteuil soit réussie, mais bon … Autre participante : Je suis un fauteuil … Rires, brouhaha Un participant : Mobilité réduite ? Parce que, fauteuil c’est … Laura : Ce qui nous intéressait, c’est le type d’équipement qu’il peut y avoir à manipuler … mais effectivement, l’intitulé c’est « votre situation ». Extrait d’un échange lors de l’atelier du 16 avril 2014.