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 !

Auteur : Aurélien

I know nothing.

6 réflexions sur « Des tours de parole dans vos visioconfs »

  1. Super !

    Il y a quelques temps je suis allé à un framapéro avec un pote anarchiste pour bosser sur un truc de ce genre.

    On l’a jamais fait, parce qu’entre temps je suis tombé malade (demande à Haikel si tu veux des détails) et le covid est passé par là donc c’est la merde jusqu’à l’hôpital…

    En tout cas, je suis hyper content que tu l’ai fait, ça a l’air génial, tout comme on voulait le faire. 😀

    Merci Aurélien !

    J'aime

  2. Salut merci beaucoup pour cette application c’est une super idée , esque c’est prevu d’implemanter les doubles listes ou triples listes ?
    La double liste est souvent utilisé pour eviter la monopilisation de la parole et prioriser les personnes qui parle moins.

    Double liste : priorité aux personnes qui n’ont pas encore pris la parole (si une personne n’ayant pas encore pris la parole la demande après une personne l’ayant déjà prise, on lui donne la parole avant celle-ci : celleux qui ont déjà pris la parole ne parleront à nouveau que si personne n’ayant encore jamais parlé ne demande la parole).

    Triple liste : priorité aux personnes qui n’ont pas encore pris la parole + à celle que l’on définit comme ayant plus de freins pour prendre la parole (les femmes, les personnes maîtrisant mal le français, les personnes qui viennent pour la première fois…).

    http://www.education-populaire.fr/methodes-en-vrac/

    Solidairement

    Aimé par 1 personne

    1. Très intéressant. A priori j’ai pas prévu ça, par contre la liste d’attente :
      – indique combien de fois la personne a déjà pris la parole
      – indique combien de temps elle a déjà parlé
      – peut être réordonnée

      Du coup quand tu vois dans la liste quelqu’un qui a déjà beaucoup parlé, tu peux le faire glisser tout en bas de la liste 🙂
      La liste indique aussi les catégories sociales déclarées de la personne (pour l’instant genre et racialisation) donc tu peux la réordonner en fonction de ces critères aussi.

      Quand on est sur des listes papier on peut pas facilement réordonner, d’où des listes multiples, mais je pense qu’en numérique c’est plus simple d’avoir une liste unique qu’on réordonne plutôt que plusieurs listes dans lesquelles on pioche. Mais je peux me tromper hein 🙂

      J'aime

  3. Hello Aurélien ! Je me colle au graphisme je te ferai plusieurs propales.
    Dis moi sur quelle boite mail je te fais parvenir les codes.
    Yves de la chorale « Envie de chanter »
    Basse, barbu chauve

    J'aime

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s