Automatiser les inscriptions Moodle depuis le SIE : scripts ou intégration ?

La plupart des cégeps et des universités qui utilisent Moodle ont un script de provisionnement quelque part. Ce peut être une tâche PHP qui appelle les services web de Moodle, une vue SQL sur le SIE qui alimente le plugin Base de données externe, ou un export CSV déposé chaque nuit dans un dossier. Il lit les groupes-cours et les inscriptions dans Omnivox, Clara, Banner ou PeopleSoft et les transforme en cours et en inscriptions Moodle.

La question de le garder ou non se pose rarement un jour tranquille. Elle surgit quand une mise à niveau de Moodle le brise, quand la personne qui l'a écrit quitte l'établissement, ou pendant la période des ajouts-abandons, quand le soutien informatique croule sous les billets « je ne vois pas mon cours ». Ce comparatif place les deux options côte à côte pour que vous décidiez en ayant les vrais coûts sous les yeux.

Que doit vraiment faire un script d'inscription Moodle ?

« Synchroniser les inscriptions » a l'air d'une seule tâche. Un script qui fait tourner une vraie session en accomplit au moins cinq, et chacune peut échouer à sa façon.

Les deux premières lignes correspondent à ce pour quoi la plupart des scripts ont été écrits. Les trois dernières, c'est là que les heures passent.

Pourquoi un script devient-il plus difficile à maintenir à chaque session ?

Un script fige les hypothèses du jour où il a été écrit. L'établissement, lui, continue d'évoluer.

• Le SIE change. Un nouveau format d'export, une nouvelle codification des sessions, un nouveau statut pour les étudiants en liste d'attente ou une migration complète de SIE obligent à réécrire la partie extraction.
• Moodle change. Chaque mise à niveau majeure, par exemple de la 3.9 LTS à la 4.1 LTS et au-delà, peut modifier le comportement des services web, les paramètres des plugins ou les exigences PHP. Les scripts fragiles expliquent en partie pourquoi des établissements repoussent leurs mises à niveau.
• Les cas particuliers s'accumulent. Groupes-cours annulés, enseignant affecté la semaine précédant la rentrée, étudiants auditeurs, enseignante qui veut fusionner ses trois groupes : chacun devient un cas spécial dans le code ou une correction manuelle.
• Le savoir se concentre. La logique vit dans la tête d'une seule personne et dans quelques centaines de lignes peu documentées. Quand cette personne est en vacances à la fin d'août, personne n'ose toucher à la tâche cron.
• Les pannes sont silencieuses. Une exécution qui saute 30 inscriptions ne déclenche aucune alerte. Ce sont les étudiants et les enseignants qui s'en aperçoivent, souvent dès la première semaine.

Combien coûte vraiment un script maison ?

Le coût visible est faible : un serveur, une entrée cron, quelques jours pour écrire la première version. Le vrai coût s'étale sur chaque session qui suit.

Selon les déploiements de LS2, le temps que les équipes TI consacrent à faire tourner des scripts maison tourne généralement autour de 40 à 80 heures par session. Ce chiffre comprend l'entretien après un changement du SIE ou de Moodle, les exécutions ratées, les corrections manuelles pendant les ajouts-abandons et les fusions de groupes faites à la main. C'est une estimation, et la vôtre peut être plus basse si votre portée est réduite. Demandez aux personnes concernées combien de temps a réellement pris la dernière rentrée, soirées comprises.

D'autres coûts n'apparaissent jamais dans les feuilles de temps des TI :

• Les étudiants inscrits à temps qui ne voient pas leur cours le premier jour, ou qui ont changé de groupe et ne retrouvent plus leurs travaux.
• Les enseignants qui cessent de faire confiance à la liste de classe dans Moodle et inscrivent des étudiants à la main, ce qui crée des inscriptions que le script ne nettoiera jamais.
• Les administrateurs Moodle, dont l'administration Moodle quotidienne se transforme en tri de billets pendant les semaines les plus chargées de l'année.
• La conformité. Quand un étudiant demande qui l'a retiré d'un cours, ou que votre responsable de la protection des renseignements personnels demande comment les changements d'inscription sont tracés, un fichier journal sur un serveur répond rarement. La Loi 25 au Québec et le RGPD en Europe exigent tous deux que l'établissement puisse rendre compte du traitement des renseignements personnels.

Les plugins d'inscription intégrés à Moodle ne suffisent-ils pas ?

Moodle offre de bons outils pour ce travail, et ils méritent un regard juste. Le plugin Base de données externe lit les inscriptions dans une table et peut créer les cours manquants. Le plugin Fichier plat traite un fichier CSV d'opérations d'ajout et de retrait. Les outils de dépôt de cours et de dépôt d'utilisateurs gèrent la création en lot, et la synchronisation des cohortes inscrit toute une population, comme un programme, dans un cours.

Ces plugins sont fiables, et bien des intégrations maison reposent sur eux. Ce qu'ils ne font pas, c'est la partie propre à votre établissement :

• Produire à temps, à partir du SIE, une table ou un fichier propre dans le format attendu par Moodle.
• Décider du nommage, des catégories, des gabarits et des groupes-cours qui partagent un même cours Moodle.
• Choisir un comportement sûr quand un étudiant abandonne. Le paramètre « Action de désinscription externe », par exemple, détermine si l'étudiant retiré est désinscrit, suspendu ou laissé tel quel. Le mauvais choix efface des notes ou laisse un accès ouvert.
• Consigner pourquoi chaque changement a eu lieu, et pas seulement qu'il a eu lieu.

« Plugin intégré plus une vue SQL », c'est donc encore une intégration sur mesure. Le code s'est simplement déplacé du côté du SIE. Combler cet écart, c'est le rôle d'une véritable intégration LMS.

Comment trancher : scripts maison ou intégration maintenue

Le tableau suppose un script qui couvre toute la session, pas seulement la première vague d'inscriptions.

Avant de décider, soumettez votre installation actuelle à ces sept questions :

1. Au moins deux personnes peuvent-elles exécuter, corriger et redéployer le script sans son auteur ?
2. A-t-il survécu à votre dernière mise à niveau de Moodle sans modification du code, et a-t-il été testé sur la version que vous comptez installer ensuite ?
3. Quand un étudiant abandonne, son inscription est-elle suspendue plutôt que supprimée, pour que ses notes et ses remises survivent à une erreur ? (Voir pourquoi des étudiants perdent l'accès pendant les ajouts-abandons.)
4. Construit-il les cours à plusieurs groupes et les cours jumelés, ou quelqu'un les fusionne-t-il à la main ? (Voir comment les méta-cours éliminent les doublons.)
5. Savez-vous qu'une exécution a échoué avant qu'un enseignant vous le signale ?
6. Pour un étudiant donné, pouvez-vous montrer en quelques minutes qui a modifié son inscription, quand, et à partir de quel changement dans le SIE ?
7. Combien d'heures la dernière rentrée a-t-elle réellement demandées, honnêtement comptées ?

Si la plupart des réponses sont oui, votre script est en bon état : documentez-le, surveillez-le et gardez-le. Si trois réponses ou plus sont non, il coûte plus cher qu'il n'y paraît, et le réécrire de zéro tend à recréer les mêmes problèmes. C'est le moment où une intégration maintenue vaut la peine d'être chiffrée.

Comment Classeo s'en charge

Classeo remplace les scripts SQL et les tâches cron par une intégration maintenue entre le SIE et Moodle. Il lit les groupes-cours, les enseignants et les inscriptions dans Jenzabar, PeopleSoft Campus Solutions, Banner, Workday Student, Omnivox, Clara ou COBA, et chaque groupe-cours du SIE devient un cours Moodle au début de la session, sans création manuelle.

La synchronisation des inscriptions se fait en temps réel ou selon un horaire, de sorte que les ajouts et les abandons se rendent dans Moodle en quelques minutes. Les cours à plusieurs groupes et les cours jumelés sont fusionnés dans un méta-cours Moodle : un seul carnet de notes, un seul forum, et un bassin d'inscriptions distinct pour chaque groupe-cours. En fin de session, les cours terminés sont cachés ou archivés selon la politique de l'établissement.

Chaque action de provisionnement, d'inscription et d'archivage est horodatée et associée à son auteur, ce qu'exigent les questions liées à la Loi 25 et au RGPD. Classeo agit comme un relais de synchronisation et ne conserve pas de copie à long terme des données étudiantes ; il est hébergé sur une infrastructure située au Québec. Il prend en charge Moodle 3.9 LTS, 4.1 LTS, 4.3, 4.4 et 4.5, et comme c'est un produit maintenu, suivre les changements de Moodle et du SIE devient la responsabilité de LS2 plutôt que celle de votre équipe.

Un déploiement type prend de quatre à huit semaines, et l'effort TI qui reste est généralement inférieur à quatre heures par session. La page Intégration Moodle-SIE détaille chaque système pris en charge, et la page Plateforme Moodle explique comment Classeo s'insère dans votre Moodle.