Classéo vs scripts manuels : la meilleure façon d'automatiser les inscriptions aux LMS en 2026

Chaque équipe TI de collège québécois qu'on a rencontrée a une version de la même histoire : un script PHP sur un serveur dans un placard, une tâche cron qui « roule, c'est tout », et trois personnes qui comprennent plus ou moins ce qu'il fait. Il lit un export du PGI, appelle l'API Web Service de Moodle, crée les cours, inscrit les étudiants. Ça marche jusqu'à ce que ça ne marche plus.

Ce billet est une comparaison lucide entre garder ce script et le remplacer par une intégration gérée comme Classéo. On regarde quatre dimensions : temps TI total, taux d'erreurs, ce qui arrive dans les cas limites, et les coûts cachés qu'on ne voit pas avant la fête du Travail.

1. Temps TI total par session

Les scripts manuels, ce n'est pas juste « le temps que le script s'exécute ». C'est :

• Maintenir le script quand le format d'export du PGI change.
• Déboguer les runs ratés à 2h du matin.
• Former une nouvelle recrue TI qui doit lire 400 lignes de PHP sans commentaires.
• Corrections manuelles pour les étudiants qui s'inscrivent après le run nocturne.
• La fusion de métacours, que la plupart des scripts ne gèrent pas et qui se fait à la main.

Moyenné sur les 50+ institutions qu'on a mesurées, le coût réel d'un script « maintenu » est de 80 à 120 heures TI par session. Une intégration Classéo gérée demande à la même équipe environ 3 à 5 heures par session — gestion des exceptions et configuration initiale des nouveaux gabarits de cours.

2. Taux d'erreurs

C'est là que ça devient intéressant. Les scripts n'échouent pas fort — ils échouent en silence.

Ce taux de 2–5 % de pertes silencieuses est le vrai tueur. Dans une institution avec 8 000 étudiants, ça signifie que 160 à 400 étudiants par session manquent d'au moins un cours où ils devraient être. Habituellement ils s'en rendent compte à la semaine 2 quand ils ne peuvent pas remettre un devoir.

3. Que se passe-t-il dans les cas limites ?

La vraie vie Moodle n'est pas un manuel. Chaque institution avec qui on a travaillé a certains de ces cas :

• Métacours et fusion de sections. L'enseignant veut les sections A à F unifiées. Mal fait, vous créez un cours Moodle où les étudiants de A voient le carnet de notes de B.
• Étudiants auditeurs et « inscriptions spéciales ». Le PGI ne sait pas qu'ils auditent; le registraire le gère dans un chiffrier.
• Profs qui enseignent dans deux institutions. Même personne, deux comptes Moodle, deux ensembles de cours.
• Changements de cours tardifs. Une section est annulée, rouverte sous un autre numéro, les étudiants doivent être transférés.

Un script maison gère peut-être le premier scénario. Le reste devient des tickets. Les intégrations gérées doivent gérer tous ces cas parce qu'on les a vécus avec d'autres collèges.

4. Coûts cachés qui n'apparaissent pas la première année

• Conformité et Loi 25. Votre script peut-il montrer un journal d'audit de qui a accédé à quelles données étudiantes ? La plupart ne peuvent pas.
• Mises à jour de Moodle. L'API Web Service change entre les versions majeures. Tous les 18 mois, votre script a besoin d'une révision.
• Facteur bus. Quand Jean-François prend sa retraite, est-ce que quelqu'un dans l'équipe comprend réellement le script ?
• Reporting. Quand quelqu'un demande « combien de cours ont été touchés la session dernière et par qui ? », le script n'a pas de réponse. Classéo oui.

Le test honnête pour savoir si votre script actuel vaut la peine d'être gardé : le confieriez-vous, avec sa documentation, à une sysadmin fraîchement embauchée et lui feriez-vous confiance pour la session ? Si non, le script « qui marche » est une bombe à retardement.