Salle d'attente

Une salle peut vérifier les arrivées : qui suit le lien ne rejoint pas la réunion, il frappe à la porte. Un animateur le laisse entrer, ou l’attente cesse d’elle-même dès qu’un animateur arrive, selon le mode choisi.

C’est une fonctionnalité du périmètre libre, sans module à installer.

Ce que voit la personne qui arrive

Un écran en deux parties : ses périphériques d’un côté, sa demande de l’autre. Elle donne son nom, laisse un mot à l’animateur si elle le souhaite, puis attend. Pendant ce temps elle règle sa caméra, son micro, son haut-parleur et son arrière-plan, de sorte que la réunion ne commence pas par « on ne t’entend pas ».

Tant qu’elle n’est pas admise, elle ne reçoit rien : ni image, ni son, ni conversation, ni la liste des personnes présentes. Ce n’est pas un filtre appliqué après coup, c’est une connexion qui n’existe pas encore.

L’écran ne dit ni le nom de la réunion, ni qui l’anime, ni combien de personnes attendent. Le nom d’une salle est souvent le sujet de la réunion.

Ce que voit l’animateur

Une section En attente en haut du panneau des participants, avec le nom de chaque personne et le mot qu’elle a laissé. Quatre gestes :

• Admettre une personne.
• Tout admettre, ce que l’on fait à l’heure dite quand la moitié d’une classe attend.
• Refuser cette demande, qui laisse la personne redemander plus tard.
• Refuser et ne plus demander, qui ferme la porte pour toute la durée de la réunion : la personne peut recharger la page, sa demande ne revient plus.

Une notification apparaît aussi au-dessus de la vidéo. Elle se regroupe : douze personnes qui arrivent ensemble produisent une seule notification qui les compte, jamais douze. Elle ne s’affiche pas pendant un partage d’écran, pour ne pas poser le nom d’un inconnu sur un document projeté ; la section du panneau, elle, reste.

Un bouton Désactiver la salle d’attente met fin à la vérification pour le reste de la réunion : ceux qui patientent entrent, les suivants n’attendent plus.

Les deux modes

Dès qu’un animateur arrive. L’attente ne porte pas sur une décision mais sur une présence : personne ne décide, et l’arrivée d’un animateur fait entrer tout le monde d’un coup. C’est le mode d’une salle de cours dont le professeur est attendu.

L’animateur admet chaque personne. L’attente porte sur une décision, nom par nom. « Tout admettre » reste disponible à tout moment.

Dans les deux cas, si le dernier animateur quitte la réunion, les personnes déjà présentes y restent et les arrivées suivantes attendent de nouveau.

Qui attend

Deux portées :

• Les invités seulement. Les personnes arrivant par une plateforme pédagogique ou une intégration entrent directement : la plateforme les a déjà authentifiées, et faire admettre trente élèves un par un rendrait l’intégration inutilisable. Seuls les liens nus passent devant l’animateur.
• Tout le monde sauf les animateurs.

Un animateur n’attend jamais, quelle que soit la portée.

Les sous-groupes n’ont jamais de salle d’attente : qui est envoyé dans un sous-groupe a été admis à la réunion quelques minutes plus tôt.

Avec un code d’accès

Les deux barrières se cumulent et s’enchaînent dans cet ordre : le code d’abord, la salle d’attente ensuite. Un code erroné est refusé par le serveur et n’atteint jamais l’animateur.

Le code et le nom sont demandés sur le même écran : une seule porte à franchir, pas deux formulaires à la suite.

Si personne ne répond

Une demande sans réponse expire au bout de dix minutes par défaut, et la personne se le voit dire avec un bouton pour réessayer. Une fenêtre fermée libère sa place en quelques secondes, de sorte que l’animateur ne se voit pas proposer d’admettre quelqu’un qui est parti.

Comment l’activer

À la création de la salle

Par l’API des salles :

curl -X POST https://votre-serveur/api/rooms \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "room_id": "conseil-pedagogique",
    "name": "Conseil pédagogique",
    "waiting_room": "guests",
    "waiting_room_mode": "approval"
  }'

waiting_room vaut off, guests ou all. waiting_room_mode vaut until_moderator ou approval. waiting_room_timeout_secs règle le délai d’expiration, entre 30 et 3600 secondes.

Pour toute l’instance

VUISIO_WAITING_ROOM prend trois valeurs :

• optional (ou absent) : chaque salle décide. C’est le comportement par défaut.
• forced : toutes les salles vérifient les arrivées, et ni un appel d’API ni un animateur en séance ne peut le désactiver.
• off : la fonctionnalité est indisponible sur cette instance.

VUISIO_WAITING_ROOM_MODE fixe le mode de la même façon.

Depuis une plateforme pédagogique

Le paramètre guestPolicy de l’API de compatibilité est traduit automatiquement : ASK_MODERATOR fait attendre les invités avec validation nominative, ALWAYS_ACCEPT ne fait attendre personne.

Ce qu’il en reste après la réunion

Les admissions et les refus figurent dans la chronologie du tableau de bord, avec qui a décidé. Les personnes refusées apparaissent en bas de la feuille de présence exportée, avec le statut « Refusé » : une personne qui n’a pas été admise n’apparaît nulle part ailleurs, et « quelqu’un a-t-il été refoulé ? » est précisément la question posée après coup.

Derrière un proxy

Si vous servez Vuisio derrière votre propre nginx plutôt qu’avec la configuration fournie, les adresses /room/{id}/knock et /room/{id}/waiting doivent être transmises au moteur comme /room/{id}/start. Le client interroge la sienne toutes les deux secondes : une limitation de débit trop basse sur ces adresses rend la salle d’attente inutilisable, et seulement derrière le proxy. Il en va de même pour /room/{id}/start et /room/{id}/exists, que chaque arrivant appelle : une classe entière partage l’adresse de son école. La configuration fournie en laisse passer cent d’un coup puis dix par seconde par adresse ; les essais de code d’accès et les créations de salles sont déjà limités par le moteur lui-même.