Contexte et solution apportée
Contexte
Dans le cadre du plan de relance, une solution de classe virtuelle du ministère de l'Enseignement Supérieur et de la Recherche (ESR), s'appuyant sur logiciel libre et open source BigBlueButton (BBB), a été déployée à l'échelle nationale.
Plus d'informations peuvent être retrouvées sur les sites suivants :
- https://doc.numerique-esr.fr/
- https://www.enseignementsup-recherche.gouv.fr/fr/classes-virtuelles-et-webinaires-pour-l-enseignement-superieur-90257
Pour les établissements n'ayant jamais eu d’infrastructure locale BigBlueButton, l'utilisation de cette solution de classe virtuelle (BBB ESR) est simple à mettre en œuvre.
Cependant, pour les établissements ayant auparavant une infrastructure locale BBB, l'utilisation du BBB de l'ESR présente des impacts aux usagers.
Cette documentation peut alors être utile pour ces établissements.
Impacts
Changer d'infrastructure est extrêmement simple, que cela soit pour n'importe quelle plateforme :
- Pod : changer le paramétrage du module des Réunions dans le fichiers custom/settings_local.py, à savoir BBB_API_URL et BBB_SECRET_KEY
- Moodle (v4) : changer le paramétrage, accessible via le module d'Administration du site, à savoir l'URL du serveur BigBlueButton et le Secret partagé BigBlueButton.
- Greenlight : changer le paramétrage dans le fichier .env, à savoir BIGBLUEBUTTON_ENDPOINT et BIGBLUEBUTTON_SECRET
En modifiant ces paramètres, la plateforme pointe alors sur la nouvelle architecture BBB.
Pour les usagers, les impacts concernent les enregistrements, qui ne seront alors plus visibles.
En effet, les sessions/réunions sont toujours accessible aux usagers, car ils sont sauvegardés dans la plateforme concernée, mais pas les enregistrements.
Il faut savoir que ces enregistrements sont sauvegardés directement sur l'infrastructure BBB (soit sur le serveur BBB soit sur le serveur Scalelite).
Dans les plateformes, les liens vers ces enregistrements sont alors affichés au moment de la consultation de la session / réunion.
Au final, lors d'un changement d'infrastructure, les anciens enregistrements ne s'affichent plus aux usagers; et lorsque l'ancienne architecture BBB sera arrêtée, les anciens enregistrements ne seront même plus disponibles, si rien n'a été réalisé avant.
Contraintes
Voici un rappel des contraintes à prendre en compte et qui explique la solution proposée :
- Contrainte vis-à-vis de Pod : nous ne souhaitons plus utiliser l'ancien module BBB de Pod, qui est amené à disparaître rapidement.
- Contrainte de l'API BBB : les participants et modérateurs ne sont disponibles que lorsque la session BBB est en cours. Une fois arrêtée, l'information n'y est plus dans BBB. Nous n'avons alors ces informations que dans le client BBB, à savoir Pod ou Moodle (ou Greenlight...).
- Contrainte BBB : par défaut, il est possible de reconstruire un enregistrement BBB (typiquement pour avoir l'enregistrement au format vidéo) que si les fichiers raw sont encore présents. Par défaut, ces fichiers raw sont supprimés au bout de 14 jours. On ne peut alors baser la solution sur la reconstruction des enregistrements.