Automatiser des données de sessions depuis Moodle : ce que montre le cas CLES
Saisie, synchronisation, affichage et contrôle : quatre étapes distinctes pour publier des données Moodle dans un calendrier public, avec leurs limites.
Dans ce guide
Beaucoup d’organisations tiennent à jour des informations dans un outil interne et les republient à la main ailleurs. Les dates de sessions d’un organisme de certification en sont un bon exemple : les centres les déclarent dans Moodle, et les candidats les cherchent sur un site public. Pour le CLES (Certificat de compétences en langues de l’enseignement supérieur), j’ai travaillé sur un calendrier public alimenté depuis Moodle. Voici ce que ce cas apprend sur la façon de découper une automatisation de données.
Le calendrier réalisé pour le CLES
Capture du calendrier public CLES conservée le 7 octobre 2026. Elle illustre l’interface livrée ; les dates et les sessions affichées ne sont pas des informations actualisées en temps réel.
Flux simplifié : Moodle → scénario Make → fichier sur GitHub → calendrier public. Le contrôle compare ensuite les informations affichées avec celles attendues à la source. Le cas CLES présente le périmètre de la mission et ses autres livrables.
Quatre étapes, pas une
Une « synchronisation » paraît être une seule opération. En pratique, ce sont quatre étapes qui peuvent chacune échouer sans que les autres le sachent.
- La saisie. Les sessions sont créées dans Moodle par les équipes. La qualité de ce qui sera publié dépend de ce qui est saisi ici : langue, niveau, centre, dates, état des inscriptions.
- La synchronisation. Un scénario récupère les données depuis Moodle, les prépare et les écrit dans un fichier structuré. Dans le cas CLES, ce scénario tourne dans Make et met à jour un fichier hébergé sur GitHub.
- L’affichage. Un calendrier HTML lit ce fichier et propose des filtres par langue, niveau, centre et mois. Le site est servi comme des fichiers statiques : GitHub Pages publie directement le contenu d’un dépôt.
- Le contrôle. Quelqu’un ou quelque chose vérifie que ce que voit le visiteur correspond bien à la dernière saisie. C’est l’étape que l’on oublie.
Export ou API : choisir selon le contexte
Il y a deux façons de sortir des données de Moodle.
- Un export (fichier produit à la main ou par un rapport planifié) est simple à comprendre et ne demande pas de droits techniques particuliers. Mais il dépend d’une action humaine ou d’un rapport à maintenir, et le fichier peut dater.
- Les web services de Moodle permettent à un système externe d’interroger la plateforme. Cela suppose qu’un administrateur active les web services, choisisse les fonctions autorisées et crée un jeton pour le compte utilisé. Les données sont alors lues à la demande, mais l’intégration dépend des droits accordés et de la stabilité des fonctions exposées.
Le bon choix dépend de qui administre Moodle, de la fréquence de mise à jour attendue et de la tolérance à un décalage. Dans tous les cas, la décision doit être prise avec l’administrateur de la plateforme, et les accès documentés en dehors du site public.
Ce que le contrôle doit vérifier
La réussite d’un transfert ne suffit pas. Trois contrôles simples :
- Horodatage visible. Le fichier publié porte la date de sa dernière génération ; le calendrier peut l’afficher. Un visiteur, ou vous, sait alors si la donnée date d’hier ou du mois dernier.
- Comparaison de comptages. Le nombre de sessions à venir côté Moodle et côté fichier doivent correspondre. Un écart signale un filtre ou une erreur de préparation.
- Rafraîchissement réel. Un fichier mis à jour peut rester invisible si le navigateur ou l’hébergeur sert une version en cache. Le contrôle doit se faire côté visiteur, pas seulement dans le journal du scénario.
C’est pour cette raison que je traite le contrôle comme une étape à part entière, et non comme une vérification facultative après coup.
Ce qu’il ne faut pas publier
Un calendrier public ne doit jamais exposer les paramètres de connexion à Moodle, le jeton du compte de service, les adresses d’administration ni les identifiants internes. Ils restent dans la configuration du scénario et dans une documentation d’accès réservée.
Ce que cela change pour votre projet
Avant de parler d’outil, décrivez les quatre étapes de votre propre flux et qui est responsable de chacune. Si la quatrième n’a pas de réponse, l’automatisation n’est pas terminée. Le cas CLES détaille le calendrier, la structure de données et le scénario livrés ; l’offre IA et automatisation décrit la façon dont j’aborde ce type de travail.
Pour choisir votre premier chantier et en comparer le coût au travail actuel, utilisez la grille d’audit automatisation pour PME. Elle intègre la relecture, la supervision et les exceptions dans le temps restant après automatisation.
Une recette à adapter avant de mettre un calendrier en ligne
| Situation à vérifier | Résultat attendu |
|---|---|
| Une session est ajoutée à la source | Elle apparaît après le cycle de synchronisation prévu |
| Une date ou un centre est corrigé | La modification apparaît sans créer de doublon |
| Une session est annulée | Le traitement correspond à la règle définie avec l’équipe |
| Une donnée obligatoire manque | L’anomalie est repérée avant d’afficher une information trompeuse |
| Le transfert échoue | L’équipe sait que la mise à jour n’est pas arrivée |
| Le visiteur consulte sur mobile | Les filtres et les informations restent utilisables |
Cette grille est une méthode de recette proposée, pas l’attestation que chaque mécanisme de surveillance est installé dans le cas présenté. Le délai entre la saisie et l’affichage doit être convenu avec l’équipe : aucune fréquence unique ne convient à tous les calendriers.
Faut-il une IA pour cette automatisation ?
Non. Le flux décrit repose sur des données structurées, des règles de préparation et leur affichage. Une IA n’est pas nécessaire pour recopier correctement une date ou un centre. Il faut d’abord stabiliser la source et les contrôles.
Peut-on appliquer cette méthode à un autre outil métier ?
Oui, si l’outil permet une extraction adaptée et si les droits nécessaires sont disponibles. Les fonctions d’export, les web services, les données autorisées et la maintenance doivent être vérifiés pour l’outil concerné.
Vous republiez manuellement des informations issues de plusieurs outils ? Présentez votre source, votre destination et les erreurs à éviter pour cadrer une automatisation.