Zam
L’histoire assez personnelle d’un produit collectif.
Prologue #
L’archer qui ne partage pas avec les autres sa joie de l’arc et de la flèche ne connaîtra jamais ses propres qualités et ses propres défauts.
Avant de commencer quoi que ce soit, donc, cherche des alliés — des gens qui s’intéressent à ce que tu fais.
Attention, je ne suis pas en train de dire : « Cherche d’autres archers. » Je dis simplement : « Trouve des personnes qui ont d’autres talents, car la voie de l’archer n’est pas différente d’une autre voie suivie elle aussi avec enthousiasme. »
La Voie de l’Archer, Paulo Coelho
Contexte #
Je suis contacté par Raphaël il y a deux ans pour rejoindre une Startup d’État, après avoir travaillé sur datagouv pendant un temps puis avoir planté une autre startup. Dans un tel contexte, on ne sait jamais ce qui va pousser après. Dans mon cas, ça avait quand même fait germer une petite graine sur l’importance d’un·e responsable produit ainsi que la présence d’une personne ayant des compétences en UX.
Je souligne l’aspect personnel de ce retour en introduction car nous sommes aussi en train de compiler une histoire collective de cette aventure et j’espère que nous pourrons la rendre publique tant les points de vue des autres membres de l’équipe sont riches et pertinents.
Cela faisait un moment que je m’intéressais au processus législatif car il me semblait que cela était un élément clé de la démocratie. Aussi, je réponds naïvement « oui » et me voilà embarqué dans un wagonnet de montagnes russes. Enfin — canadiennes en fait — vu que nous avons pu concevoir l’intégralité du produit en étant à distance.
Ainsi naissait mon implication dans Zam (cache).
Objectif #
L’objectif est de proposer un outil numérique permettant de réduire la pénibilité (et le nombre de pages jusque là imprimées) lors de la rédaction des réponses aux amendements soumis par les député·e·s et/ou sénateur·ice·s de la part du gouvernement afin de préparer le débat législatif au sein des instances parlementaires (Assemblée Nationale et Sénat).
Exprimé ainsi il faut s’accrocher, aussi je vous propose un exemple sous forme de chronologie et un peu simplifié (les dates sont inventées mais proches de la réalité) :
- Lundi, le gouvernement soumet un projet de loi à l’Assemblée Nationale ;
- Jusqu’à vendredi midi, les député·e·s soumettent des amendements dans l’intention d’améliorer le texte initial ;
- De vendredi midi à lundi, les services du gouvernement travaillent pour avoir une réponse précise/pertinente à chaque amendement (c’est généralement la nuit/fin de semaine, oui) ;
- Le lundi suivant, la séance publique commence et le ou la ministre dispose de réponses permettant de prendre la parole dans l’hémicycle ;
- Au cours du débat parlementaire qui prend quelques jours, les amendements sont acceptés ou rejetés en fonction des votes en séance, le texte est modifié en conséquence avant de passer au Sénat.
Zam intervient à l’étape 3 lorsqu’il s’agit de rédiger ces réponses dans des délais courts, avec la plus grande expertise possible et une chaîne de validation conséquente. Cet outil vient remplacer un processus à base de (beaucoup de) papier, d’outils de traitement de texte/tableur et de longues heures de sommeil perdues.
Zam est sporadiquement utilisé en étape 4 pour les conseillers qui sont sur les bancs de l’Assemblée Nationale et a même été utilisé par une ministre en direct sur une tablette. Achievement unlocked.
Approche #
Tout a commencé à échelle humaine sur un projet de loi bien précis et surtout avec une personne clé qui connaissait bien les rouages des processus existants, au point de vouloir les changer. Ce que l’on appelle une intrapreneuse. Puis ça s’est rapidement emballé suite à la satisfaction des utilisateur·ice·s qui ont apprécié les veillées moins stressantes et les nuits plus complètes (!), ces personnes étaient jusqu’alors en souffrance. On a commencé à enchaîner les projets de loi et les ministères concernés.
Pour tenir dans la durée, il faut réussir à trouver un rythme qui soit soutenable pour tou·te·s. En étant à distance et sur un fuseau horaire différent, cela signifie s’adapter pour trouver un créneau quotidien d’échange qui tourne autour d’une heure. C’est un moment important autant pour le travail à réaliser que pour maintenir l’humeur de l’équipe à un niveau enthousiasmant. Non pas comme une suite de sprints mais comme un ultra-marathon avec plein de pacers.
En parallèle de ces discussions, il y a nos échanges avec les personnes utilisant le produit dont l’avis est essentiel pour pouvoir continuer à être pertinents. Cela arrive environ toutes les deux semaines et nous mettons un canal de réception en place pour les personnes ne pouvant pas être sur place. C’est vraiment important pour moi d’arriver à avoir ces retours sans intermédiaires de façon à développer mon empathie pour les utilisateur·ice·s.
Tous les six mois environ (?), on prend un peu de recul sur ce que l’on a fait et compris — sur notre nouvelle façon de voir les choses aussi — pour réajuster le cap si on en ressent le besoin. Cela permet d’échanger sur des émotions qui sont passées entre les mailles du filet quotidien.
Technique #
J’ai parlé un peu de technique récemment et la pile de technologies que l’on a utilisé pour ce projet me semble être relativement stable et compréhensible. Le code est accessible sur Microsoft Github sous licence AGPL-3, on peut voir que la répartition est assez équilibrée entre Ronan et moi. C’est du Python 3 annoté pour les types qui utilise Pyramid comme framework web. Rien de très exotique et c’est intentionnel considérant que nous souhaitions à un moment transmettre le produit (voir plus bas).
Ce qui est peut-être un peu plus inhabituel c’est de ne pas utiliser Microsoft npm pour gérer nos dépendances JavaScript, cela permet de bien voir ce que l’on ajoute, une sorte de friction (cache) manuelle qui m’est chère lorsqu’on parle de faire tourner mon code sur la machine de beaucoup d’autres.
Les principaux défis techniques ont été de gérer des données en entrée en provenance des sites parlementaires qui n’étaient pas forcément très stables. Lorsque toute la pertinence du produit repose sur la fraîcheur des données à un moment clé du processus législatif, c’est quelque peu anxiogène de se dire que l’on n’a aucun contrôle dessus !
La plus grande victoire technique est certainement d’avoir eu envie de reprendre ce code pour la suite (voir plus bas) au lieu de partir sur quelque chose de neuf.
Transmission #
Une Startup d’État est un service public numérique développé par une équipe autonome pour répondre à un problème lié à une politique publique, financée par une administration porteuse. Elle n’a pas pour objectif de faire du profit et n’a le plus souvent pas de personnalité juridique propre au moment de son lancement (même si elle peut devenir par la suite un service national au sein d’une administration ou au sein d’un GIP autonome). Sa vocation est de maximiser son impact social en répondant aux besoins de ses utilisateurs.
Au bout d’un moment, lorsqu’on s’est prouvé que le produit conçu a de la valeur pour des personnes grâce à leurs retours récurrents, on songe à décliner le service à plus large échelle. C’est ce qui s’est passé pour Zam avec une généralisation de l’outil numérique de gestion des amendements pour l’ensemble des administrations au début de l’année 2020.
Je vais être honnête, ça s’est (pas) fait dans la douleur.
Nous étions dans une optique de transmission là où la direction qui devait dorénavant assurer la continuité de ce service s’attendait à un produit fini qu’il suffirait de brancher comme on peut le faire avec de l’électroménager. Autant dire que le choc des cultures a été assez violent… et le résultat relativement frustrant.
Le service est officiellement arrêté depuis le 1er janvier et nous avons tout de même maintenu une instance afin d’en assurer la continuité malgré tout, estimant qu’il était important pour nos utilisateur·ice·s de continuer à disposer d’un outil qui leur facilitait la vie au quotidien. D’autant plus lorsqu’un projet de loi comme celui des retraites s’en vient et que l’on pense pouvoir éviter l’abattage d’une forêt en rendant inutile l’impression multiple de 42 000 amendements !
Bref, ça ressemble à un loupé. Mais l’essentiel n’était peut-être pas là :-).
Entracte #
Il existe deux types de tir.
Le premier est celui que l’on fait avec précision mais sans âme. Dans ce cas, l’archer, bien qu’il possède une grande maîtrise de la technique, s’est exclusivement concentré sur la cible — et il n’a donc pas évolué, il a machinalement répété un geste, il n’a pas réussi à grandir, et il abandonnera un jour la voie de l’archer parce qu’il trouvera que tout est devenu routine.
Le second tir est celui que l’on fait de toute son âme. Lorsque l’intention de l’archer se transforme pour devenir le vol de la flèche, ses doigts s’ouvrent au bon moment, le son de la corde fait chanter les oiseaux et le fait de tirer en direction de quelque chose au loin provoque — paradoxalement — un retour sur soi, une rencontre avec soi-même.
La Voie de l’Archer, Paulo Coelho
Satisfactions #
Je vais me concentrer sur trois satisfactions importantes au cours de ces deux dernières années :
- Être suffisamment à l’écoute des utilisateur·ice·s pour que cela crée un climat de confiance et que ces personnes prennent part à l’aventure, aboutir à une telle proximité est vraiment crucial pour concevoir un produit pertinent qui soit adopté. Cela a changé ma façon d’appréhender les problèmes en passant de la théorie à la pratique.
- Faire équipe, je me suis déjà longuement exprimé sur le sujet et cette tension positive entre ses membres transforme la qualité et la pertinence du produit.
- Collaborer à distance, pas seulement en pensant à distance mais en apprenant et en grandissant à distance. Je mesure d’autant plus aujourd’hui — lorsque cette distance est imposée — à quel point c’est un avantage comparé à d’autres équipes qui se retrouvent désemparées. Non seulement pour être efficaces mais aussi et surtout pour continuer à avoir le sentiment d’être ensemble dans des moments d’incertitudes.
D’un point de vue plus personnel, j’apprécie le fait de garder l’enthousiasme de travailler sur un même produit et avec une même équipe dans la durée. Au point de vouloir continuer à faire des choses avec l’un et l’autre. C’est assez rare pour que je m’en réjouisse :-).
Regrets #
Je vais en garder trois aussi pour équilibrer :
- La frustration de ne pas réussir à transmettre un produit et, peut-être pire, une façon de le produire. Cela remet en question pas mal de choses au sujet de mon implication dans des initiatives comme betagouv. C’est un regret qui est encore aujourd’hui assez difficile à digérer.
- La souffrance d’avoir construit un groupe de travail autour d’un produit qui va être ignoré alors qu’il est la clé de sa réussite auprès des utilisateur·ice·s actuel·le·s. Avoir un sentiment de gâchis d’énergie (et d’argent public).
- La peine d’avoir voulu essayer de transmettre le produit à une autre entité pour vérifier si cela était faisable alors qu’une externalisation au sein d’un GIP ou autre aurait probablement été possible à un moment donné. J’espère que notre retour permettra aux autres équipes de ne pas faire la même erreur.
Il y en aurait un autre de regret un peu meta qui est la prise de conscience que l’appareil démocratique de la Cinquième République est complètement défaillant lorsqu’il y a une majorité. J’aurais pu m’en rendre compte depuis l’extérieur mais avoir les mains dans ces données permet de constater à quel point les séances à l’Assemblée Nationale ou au Sénat peuvent être inutiles dans les faits. C’est bien triste car il s’agit ici du contre-pouvoir nécessaire à l’exécutif.
Suite #
Ce qui est réjouissant dans tout ça, c’est qu’il y a une saison 2 qui se prépare, nom de code : Visam !
On reprend l’équipe, une partie du code et on va rencontrer les personnes en souffrance pour proposer une solution adaptée. Ou du moins c’était le plan, et vu qu’il ne se déroule pas tout à fait comme prévu à cause d’un petit bout d’ARN plutôt résistant, on s’adapte.
L’avantage d’être une équipe distribuée, c’est d’a priori être à même de pouvoir proposer des usages qui correspondent à la situation actuelle. La suite au prochain épisode…
Ailleurs #
Le code source de Zam est disponible depuis le début sous licence AGPL 3.
Maïtané a écrit une série d’articles sur le sujet, pour l’instant il y en a 9 de publiés mais 19 sont prévus (!!!). Cela permet de suivre l’évolution du produit dans le temps, c’est trop bien.
Deux articles sur le blog de betagouv :
- Zam : simplifier le processus de réponse aux amendements (cache)
- Paroles d’intrapreneuses #2 : Mélodie Dahi de la Startup d’Etat Zam (cache)
Une émission de radio a été réalisée par DaScritch.
Il y a eu au moins un article dans la presse (cache), en tout cas c’est le seul dont j’ai connaissance.
On réfléchit à d’autres formes de transmissions/interactions, notamment orales, potentiellement en visio, bref si vous avez des idées et/ou questions on est super ouvert·e·s.
Épilogue #
Une fois que la flèche a été décochée, l’archer ne peut plus rien faire, si ce n’est suivre des yeux son trajet vers la cible. Dès lors, la tension nécessaire au tir n’a plus de raison d’être.
L’archer garde alors les yeux fixés sur le vol de la flèche, mais son cœur se repose, et il sourit.
La Voie de l’Archer, Paulo Coelho
P.S.: le Japon me manque.
Mise à jour quelques heures après publication : Karl répond en parlant de poisson (cache) et ne sait pas à quel point il tombe juste :-).