Des tours de parole dans vos visioconfs

Le contexte

Je co-anime un groupe de parole à Paris autour de la polyamorie depuis quelques années, groupe dans lequel on avait l’habitude d’organiser le débat en notant les demandes de prise de parole sur un bout de papier, et en distribuant la parole dans l’ordre au fur et à mesure. Les groupes allaient de 60 à 100 personnes environ.

Or, il ne vous a pas échappé qu’il y a en ce moment une petite pandémie. Ces réunions-là se sont donc arrêtées du jour au lendemain, laissant un gros vide dans nos activités associatives et sociales. Assez rapidement, certain⋅es orgas ont migré en ligne, sur un logiciel de visioconférence que je ne citerai pas mais qui commence par Z… Je ne sais pas si vous avez déjà participé à une visioconférence à 50 personnes, mais avec la latence et les bruits de fond, c’est absolument impossible de mener une discussion informelle. On a donc essayé de recréer la structure qu’on avait dans nos groupes et qui marchait bien : demande de prise de parole, inscription sur une liste, distribution des tours.

Mais voilà, demander la parole sur ce logiciel c’est pas aussi évident. Au début il fallait regarder toutes les vignettes des gens pour regarder qui lève la main, mais il y a plusieurs pages de vignettes quand on est nombreux/ses. Puis on a dit qu’on pouvait demander sur le chat textuel, et ça nous a juste ajouté un nouvel endroit à regarder 😉 Ensuite le logiciel a ajouté la possibilité de « lever la main » en appuyant sur un bouton, ce qui marche bien mais faut le trouver, le bouton, donc tout le monde ne l’utilise pas. Une fois que la demande est repérée, on l’inscrit sur un document Google partagé entre orgas, puis on distribue la parole en enlevant la ligne du document. Enfin, on gardait un œil sur notre compteur de temps de parole, pour éviter les monologues.
Ça marche, mais c’est fastidieux, ça demande plein de paires d’yeux qui scrutent les écrans et le chat textuel, etc.

Se simplifier la vie

Je me suis dit que c’était l’occasion de simplifier ça avec un programme. Le but serait de permettre aux participant⋅es de demander un tour de parole, qui s’inscrirait automatiquement dans notre liste côté orga. Et que le passage de parole supprime automatiquement le nom de la liste. Oh, et aussi que ça gère en même temps la question du temps de parole, pour qu’on ait pas le compteur à gérer à côté. Et comme notre compteur trie et produit des stats en fonction du genre, il faudrait garder cette possibilité dans la nouvelle appli.

Bon, on a le cahier des charges, y’a plus qu’à. J’ai commencé à fin 2020, et après un démarrage un peu raté je suis assez content de dire qu’on en est à notre 3e utilisation et que ça marche plutôt bien 🙂

Le résultat

Le site est à l’adresse : https://speakinglist.net. Vous pouvez aller y créer votre évènement, et pour simuler des participant⋅es vous pouvez par exemple ouvrir une fenêtre de navigation privée dans votre navigateur, ou tester avec d’autres orgas.

L’interface d’administration sur laquelle vous arrivez en créant un évènement est prévue pour être affichée sur un ordinateur, alors que l’interface pour participant⋅e est prévue pour être utilisée sur un téléphone. Comme ça les participant⋅es ont a la visioconf sur l’ordi, et dans la main le bouton pour demander un tour de parole. On peut aussi, bien sûr, préférer afficher aussi son interface de participant⋅e sur l’ordi, et ça marchera de la même façon.

Lestat ? Lestat le Vampire ?

Non, les stats ! (désolé)
Le fait que les participant⋅es déclarent leurs catégories sociales (genre et race pour l’instant, au choix des orgas) permet de faire des stats intéressantes sur la répartition de la parole entre dominants et dominé⋅es. Et aussi de réorganiser la liste de parole pour que ce ne soient pas toujours les mêmes qui parlent (coucou les mecs blancs on vous voit). En mesurant objectivement le temps de parole, on peut prendre conscience du problème, ce qui est la première étape pour le résoudre. Par exemple, dans nos débats on se rend compte que même si les mecs sont moins nombreux, ils parlent la plupart du temps plus souvent et plus longtemps que les femmes et les personnes non-binaires en proportion de leur nombre. J’ai aussi remarqué que quand on leur dit, en début d’évènement, qu’on mesure cela et qu’on aimerait qu’ils fassent un effort là-dessus, la différence est moindre. Comme on dit en ingénierie, « on ne peut optimiser que ce que l’on peut mesurer ».

Geekerie !

Pour moi, faire un programme dans un cadre associatif est toujours l’occasion d’essayer des technos et des bibliothèques logicielles que je ne connais pas encore. Ici, le défi principal est le temps-réel. Quand on donne la parole à quelqu’un, ça doit se refléter instantanément sur son interface. Pour cela on va préférer le push au polling, plus gourmand en ressources et surtout beaucoup plus lent.

Ça, dans le monde du web, ça veut dire websocket, que je n’avais encore jamais utilisé. Yay ! 🙂 J’en ai profité pour sélectionner pour le backend un framework qui gère nativement l’asynchrone. J’ai commencé avec FastAPI, que je voulais tester depuis longtemps, et on va voir plus tard pourquoi je ne l’ai pas gardé.

Des occasions de tester de nouvelles technos, j’en ai pas 10 par an, donc j’essaye de caser le maximum de trucs intéressants dedans. J’en ai profité pour essayer GraphQL comme protocole d’API, et je dois dire que je suis très content. En plus, GraphQL contient déjà un mécanisme pour le push, appelé subscriptions, ce qui est très adapté à mon cas. Par contre, FastAPI utilise une version de Starlette qui ne gère pas bien les subscriptions dans GraphQL, j’ai donc abandonné FastAPI pour utiliser directement Starlette.

L’asynchrone, c’est beau quand ça marche, mais tout n’est pas encore prévu pour fonctionner nativement avec. Je voulais notamment utiliser l’ORM de SQLAlchemy, parce que la bibliothèque de base de données proposée avec Starlette ne fait pas d’ORM et que j’aime bien ça. Malheureusement, SQLAlchemy ne fait pour l’instant pas d’asynchrone (ça devrait arriver dans la prochaine version, la 1.4). Donc je l’ai utilisée en mode normal (bloquant) en me disant que les connexions à la base de données sont rapides, puisqu’elles sont sur le même serveur. Alleeeeeez, ça va passeeeeer.

C’est pas passé. Enfin, ça a marché, mais dès qu’il y a eu plus de 5 connexions simultanées, on a épuisé le pool de connexions de SQLAlchemy, qui a donc bloqué la demande de nouvelles connexions en attendant qu’une se libère. Et ça, en asynchrone, ça n’arrive jamais : quand c’est bloqué c’est bloqué 🙂 Donc en gros, à la première utilisation en conditions réelles, le programme s’est vautré comme une grosse otarie bourrée à la bière bavaroise. Est-ce que j’aurais dû faire un stress test de l’appli ? Absolument.

J’ai plus ou moins contourné ça en augmentant la taille du pool à 50 connexions et en croisant les doigts pour qu’on ait jamais 50 demandes à la base de données exactement en même temps. J’ai stress-testé, on passe tranquille avec plusieurs centaines d’utilisateurs simultanés. Si un jour on fait des visioconfs débat avec plusieurs centaines de participant⋅es, je crois qu’on aura d’autres problèmes avant celui-là. Mais bon, je serai quand même plus rassuré quand SQLAlchemy gèrera l’asynchrone nativement. En attendant la version finale de la 1.4, ça va tenir comme ça.

Côté front-end, du classique, React avec Customize-CRA, Material-UI et Apollo pour le GraphQL, le tout en Typescript. Je dois dire que je suis très agréablement surpris par Apollo, ça m’a permis d’éviter Redux complètement !

Il va sans dire que l’appli est sous licence libre AGPL. La documentation d’installation n’est pas hyper détaillée mais c’est en gros à base de base de données SQL, serveur d’application Python Uvicorn (pour l’asynchrone), Nginx devant tout ça, et Redis en backend pour les files d’attente de messages. Le code source est ici, et je fournis quelques exemples de fichiers de conf pour le déploiement.

Conclusion

Là, ça marche plutôt bien. Tout le monde n’utilise pas l’appli dans les évènements, mais on peut ajouter manuellement les participant⋅es réfractaires et les traiter comme les autres dans la liste d’attente. Le groupe est content, je suis content, je pense que c’est suffisamment mûr pour être utilisé par d’autres.

N’hésitez pas à me dire ce que vous en pensez, ici en commentaire ou par mail ! Si vous voulez aider, je pense que l’appli pourrait gagner à ce qu’un⋅e graphiste se penche dessus, fasse un vrai logo, choisisse des couleurs, des typos sympa, etc. Ça fonctionne actuellement en français et en anglais, mais si vous voulez ajouter votre langue c’est aussi tout à fait possible. J’accepte aussi les contributions sous forme de code bien sûr, si vous vous y retrouvez dans le mien 😉

Je suis très preneur de retours, dites-moi si vous l’utilisez, sur quelles tailles de groupes, et ce que vous en pensez. Bonnes visios !