Chapitre 5 — Administration du site : réglages, plugins, cron et exploitation

Dans les chapitres précédents, vous avez installé Moodle, compris son modèle de comptes et d’authentification, et exploré la gestion des utilisateurs et des rôles. Ce chapitre change d’échelle : nous ne parlons plus d’un cours ou d’un utilisateur, mais de la plateforme elle-même. C’est le chapitre de l’administrateur système fonctionnel : celui qui règle le site après l’installation, installe et met à jour des plugins, s’assure que le cron tourne, surveille les logs, sécurise l’installation et sait quoi vérifier chaque matin.

Si vous venez du monde Next.js/React, pensez à ce chapitre comme à l’équivalent de tout ce qui, dans votre stack, vit en dehors du code applicatif : le dashboard Vercel, les variables d’environnement, les cron jobs, l’observabilité (Sentry, Datadog), la gestion des dépendances npm et les checklists de mise en production. Moodle regroupe presque tout cela dans une seule zone : Administration du site (Site administration).

Sauf mention contraire, tout ce chapitre se réfère à Moodle 5.2 (avril 2026, PHP 8.3+, Bootstrap 5). Quand une fonctionnalité est apparue ou a changé dans une version antérieure, la version est précisée.

5.1 Tour de la zone d’administration

5.1.1 Accéder à l’administration du site

Connecté avec un compte administrateur, vous voyez dans la navigation principale (la barre horizontale en haut de page, héritée du thème Boost) une entrée Administration du site (Site administration). Elle mène à https://votre-site/admin/search.php, la page centrale de toute l’administration.

Cette zone n’est visible que pour :

• les administrateurs du site (les comptes listés dans Utilisateurs > Permissions > Administrateurs du site) ;
• les utilisateurs disposant d’un rôle avec des capacités d’administration déléguée, par exemple un rôle de « gestionnaire » (manager) assigné au contexte système — ils ne verront alors que les pages autorisées par leurs capacités.

5.1.2 La structure en onglets

Depuis Moodle 4.0, la zone d’administration est organisée en onglets horizontaux (et non plus en arborescence dans un bloc latéral, comme dans les très anciennes versions que vous croiserez sur des captures d’écran datées). Voici les onglets et ce qu’ils recouvrent :

💡 Pour un dev React : l’onglet Plugins est votre package.json rendu navigable. Chaque type de plugin (module d’activité, bloc, thème…) y possède sa page « Gérer les X » avec activation/désactivation, ordre, et réglages. La différence majeure avec npm : la configuration des dépendances vit en base de données, modifiable via l’UI, et non dans des fichiers versionnés — sauf exceptions que nous verrons avec config.php.

5.1.3 La barre de recherche des réglages : votre meilleur ami

En haut de la page d’administration se trouve un champ Rechercher dans l’administration du site. C’est l’outil le plus important de tout ce chapitre. Moodle compte plusieurs centaines de pages de réglages et des milliers de paramètres individuels ; personne, pas même les Moodleurs de vingt ans d’expérience, ne navigue dans les menus pour tout trouver.

La recherche fonctionne sur :

• le nom affiché du réglage (dans la langue de l’interface) ;
• le nom interne du réglage (par exemple forcelogin, cronclionly, loglifetime) ;
• le texte d’aide associé.

Tapez forcelogin et vous atterrissez directement sur le bon paramètre, avec un lien vers sa page d’origine. C’est aussi pour cela que cette documentation vous donnera systématiquement le nom interne des réglages importants : c’est la clé de recherche universelle, indépendante de la langue de votre interface.

💡 Pour un dev React : c’est l’équivalent du Cmd+K de votre dashboard Vercel ou du « command palette » de VS Code. Prenez le réflexe recherche d’abord, navigation ensuite. Dans la suite du chapitre, les chemins de menus sont donnés pour situer les choses, mais en pratique vous taperez presque toujours le nom interne du réglage.

5.1.4 La page « Notifications » : le tableau de bord de santé

Administration du site > Général > Notifications (/admin/index.php) est une page que vous devez comprendre dès maintenant, car Moodle vous y redirigera de force à des moments clés :

• Après l’installation ou l’ajout d’un plugin : Moodle détecte que des fichiers de code ont une version supérieure à celle enregistrée en base, et la page Notifications affiche la liste des mises à jour de schéma en attente (plugins requiring attention / pending upgrades), avec un bouton pour lancer la mise à niveau de la base de données.
• Après une mise à jour du cœur de Moodle : même mécanisme, précédé d’une vérification d’environnement (versions PHP, extensions, base de données — voir section 5.9).
• En temps normal : elle affiche la version exacte de Moodle installée, l’état de l’enregistrement du site auprès de moodle.org, les alertes importantes (cron qui ne tourne pas, mises à jour de sécurité disponibles) et un lien vers le rapport des vérifications de statut.

Retenez la logique fondamentale : le code déclare une version, la base de données enregistre une version installée ; quand les deux divergent, Moodle exige un passage par Notifications pour exécuter les migrations. Tant que cette mise à niveau n’est pas faite, le site est bloqué en mode « mise à jour en cours » pour les non-administrateurs.

💡 Pour un dev React : c’est exactement le modèle des migrations Prisma ou Drizzle. Déposer le code d’un plugin ≈ modifier schema.prisma ; visiter Notifications et cliquer « Mettre à jour la base de données » ≈ prisma migrate deploy. Et comme avec Prisma, on ne saute jamais cette étape : le code et le schéma doivent rester synchronisés.

5.1.5 Réglages en base vs config.php

Presque tous les réglages d’administration sont stockés dans les tables mdl_config et mdl_config_plugins de la base de données, et modifiables via l’UI. Mais le fichier config.php à la racine de Moodle peut forcer n’importe lequel de ces réglages avec la syntaxe $CFG->nomduréglage = valeur;. Un réglage forcé dans config.php apparaît alors grisé et non modifiable dans l’interface, avec la mention « Défini dans config.php ».

Pour l’instant, retenez simplement deux choses :

1. Si un réglage est grisé dans l’UI, cherchez-le dans config.php — quelqu’un l’a verrouillé côté fichier.
2. Cette technique est la façon « infrastructure as code » de gérer Moodle (utile pour garantir qu’un environnement de test n’envoie jamais d’e-mails, par exemple). Le détail des directives de config.php est traité dans la partie développement.

⚠️ Piège : ne confondez pas « valeur par défaut » et « valeur forcée ». Un réglage jamais touché dans l’UI prend sa valeur par défaut, qui peut changer lors d’une mise à jour de Moodle. Un réglage forcé dans config.php est immuable tant que le fichier n’est pas modifié. Lors d’un diagnostic (« pourquoi ce réglage revient-il tout seul ? »), vérifiez toujours config.php en premier.

5.2 Réglages essentiels post-installation

Une installation Moodle fraîche fonctionne, mais elle n’est ni localisée, ni sécurisée, ni présentable. Voici la passe de configuration que tout administrateur effectue dans les premières heures.

5.2.1 Identité du site

Administration du site > Général > Réglages de la page d’accueil (recherche : fullname) :

5.2.2 La page d’accueil (frontpage)

La page d’accueil de Moodle est techniquement un cours spécial (le cours d’identifiant 1 — détail interne que vous recroiserez dans la partie développement). Cela explique qu’elle puisse contenir des blocs et même des activités. Deux jeux de réglages contrôlent son contenu, toujours dans « Réglages de la page d’accueil » :

• frontpage : les éléments affichés aux visiteurs non connectés (anonymes) ;
• frontpageloggedin : les éléments affichés aux utilisateurs connectés.

Pour chacun, vous composez une liste ordonnée parmi : liste des cours, liste des catégories, cours auxquels l’utilisateur est inscrit, actualités du site, boîte de recherche de cours. Un menu « Aucun » laisse la zone vide. S’y ajoutent :

• maxcategorydepth : profondeur d’affichage des catégories imbriquées ;
• frontpagecourselimit : nombre maximal de cours listés ;
• l’activation du mode édition sur la page d’accueil pour y placer des blocs (HTML, calendrier, annonces…), exactement comme dans un cours.

Notez que depuis Moodle 4.x, l’utilisateur connecté arrive par défaut sur son Tableau de bord (Dashboard) ou sur « Mes cours », pas sur la page d’accueil. Le réglage defaulthomepage (recherche : Page d’accueil par défaut de l’utilisateur) arbitre entre Site, Tableau de bord et Mes cours — et peut laisser le choix à l’utilisateur.

⚠️ Piège : beaucoup d’administrateurs peaufinent longuement la page d’accueil… que leurs utilisateurs connectés ne voient jamais, car defaulthomepage pointe vers le tableau de bord. Décidez d’abord de la porte d’entrée de vos utilisateurs, ensuite seulement investissez du temps dans la page correspondante.

5.2.3 Politiques de site (Site policies)

Administration du site > Général > Sécurité > Politiques de site (page historique ; recherche : sitepolicies). Trois réglages y sont décisifs dès le premier jour :

• forcelogin (Forcer la connexion) : si activé, rien n’est visible sans être connecté, pas même la page d’accueil. Indispensable pour une plateforme d’entreprise privée ; à laisser désactivé pour un catalogue de formation public.
• forceloginforprofiles (Forcer la connexion pour les profils) : activé par défaut, il empêche les visiteurs anonymes (et les moteurs de recherche) de consulter les profils des utilisateurs. Ne le désactivez qu’en toute connaissance de cause — c’est une protection des données personnelles.
• opentogoogle (Ouvert à Google) : autorise le robot de Google à entrer dans les cours accessibles aux invités pour les indexer. Sans effet si forcelogin est activé.

C’est aussi sur cette page que se trouvent la taille maximale des fichiers déposés au niveau site (voir section 5.8) et l’URL de la charte du site (site policy), que les utilisateurs doivent accepter à la première connexion — à ne pas confondre avec l’outil RGPD complet Politiques (tool_policy, Administration du site > Utilisateurs > Confidentialité et politiques), qui gère des versions de politiques avec consentements horodatés.

5.2.4 Localisation : fuseau horaire et pays

Administration du site > Localisation > Réglages de localisation :

Toutes les dates stockées par Moodle sont des timestamps UTC ; le fuseau ne joue que sur l’affichage et l’interprétation des saisies. Si vous forcez le fuseau, les utilisateurs perdent le choix dans leurs préférences personnelles.

⚠️ Piège : une date limite de devoir « 23:59 » n’est pas la même à Paris et à Montréal. Si votre plateforme sert plusieurs fuseaux et que vous forcez Europe/Paris, les apprenants québécois verront des échéances exprimées en heure française sans le savoir. En contexte international, laissez le choix du fuseau aux utilisateurs et assurez-vous que le fuseau du serveur (PHP) est lui aussi correctement configuré.

5.2.5 Langues : installer le français et au-delà

Moodle est livré en anglais ; tout le reste s’installe sous forme de packs de langue (language packs), maintenus par la communauté sur lang.moodle.org.

Installer un pack : Administration du site > Général > Langue > Packs de langue (Language packs, /admin/tool/langimport/). Sélectionnez Français (fr) dans la liste des packs disponibles, puis « Installer le pack de langue sélectionné ». Le pack est téléchargé dans moodledata/lang/. Notez l’existence de variantes régionales qui héritent du pack parent : fr_ca (français canadien) ne contient que les chaînes qui diffèrent de fr, lequel retombe lui-même sur l’anglais pour toute chaîne manquante. Cette chaîne d’héritage (fr_ca → fr → en) est le modèle mental à retenir.

Les packs installés sont mis à jour automatiquement par une tâche planifiée (voir section 5.4) ; le bouton « Mettre à jour tous les packs de langue installés » force l’opération.

Réglages de langue (Administration du site > Général > Langue > Réglages de langue) :

• lang : langue par défaut du site (fr après installation du pack) ;
• autolang (Détection de la langue du navigateur) : si activé, la page de connexion s’affiche dans la langue du header Accept-Language du navigateur ; une fois connecté, c’est la préférence de langue du profil utilisateur qui prime ;
• langmenu : affiche un menu de sélection de langue sur la page de connexion ;
• langlist : restreint la liste des langues proposées (ex. en,fr,fr_ca) — utile pour ne pas exposer les 100+ packs si vous en installez plusieurs pour des tests.

Personnalisation de la langue (Language customisation, Administration du site > Général > Langue > Personnalisation de la langue) : cet outil permet de surcharger n’importe quelle chaîne de l’interface sans toucher aux packs. Ouvrez le pack fr pour modification, filtrez par composant (par exemple moodle.php pour le cœur, mod_assign.php pour le module Devoir), trouvez la chaîne par son identifiant ou son texte, saisissez votre variante locale, puis enregistrez les modifications dans le pack. Les surcharges sont stockées dans moodledata/lang/fr_local/ et survivent aux mises à jour des packs et de Moodle. Cas d’usage typique : renommer « Cours » en « Formation » dans toute l’interface d’un Moodle d’entreprise.

💡 Pour un dev React : le système de langues de Moodle, c’est i18next avec fallback en cascade (fr_ca → fr → en), et la personnalisation de langue est l’équivalent d’un fichier de traductions local qui fait un « deep merge » par-dessus les traductions du package — vos overrides vivent dans un dossier séparé (fr_local) et ne sont jamais écrasés par un npm update (ici, la mise à jour automatique des packs).

Mentionnons enfin le filtre multi-langue (Multi-language content filter), un filtre de contenu (Administration du site > Plugins > Filtres) qui permet aux rédacteurs d’écrire un même paragraphe en plusieurs langues avec des balises <span lang="fr" class="multilang">…, Moodle n’affichant que la version correspondant à la langue de l’utilisateur. Il doit être activé dans la gestion des filtres pour fonctionner. Les filtres en général sont traités avec la gestion de contenu.

📚 Aller plus loin : le site lang.moodle.org (AMOS) est l’outil de traduction communautaire : vous pouvez y consulter l’état de traduction du pack fr composant par composant, et même y contribuer vos propres traductions si une chaîne 5.2 n’est pas encore traduite.

5.3 Gestion des plugins

5.3.1 Le modèle de plugins de Moodle

Moodle est une architecture à plugins poussée à l’extrême : le cœur lui-même embarque plus de 400 plugins « standard ». Tout ce qui est fonctionnel appartient à un type de plugin (plugin type), et chaque type a un préfixe (le « composant » Frankenstyle, ex. mod_assign, que vous verrez partout dans les logs et les URL). Les types principaux :

Administration du site > Plugins > Vue d’ensemble des plugins (Plugins overview, /admin/plugins.php) liste tout : version installée, source (standard ou additionnel), disponibilité de mises à jour, et actions (réglages, désinstallation). Un filtre « Plugins additionnels » isole ce que vous avez ajouté vous-même — c’est la liste à auditer avant chaque mise à jour majeure.

💡 Pour un dev React : plugin Moodle ≈ package npm, mais avec trois différences de taille. Un : il n’y a pas de gestion de dépendances transitive digne de ce nom — un plugin peut déclarer dépendre d’un autre, mais rien ne l’installe automatiquement. Deux : les plugins peuvent modifier le schéma de base de données et créent leurs propres tables. Trois : désinstaller un plugin supprime ses données (voir 5.3.5), alors que npm uninstall ne touche jamais vos données. Le « lockfile » de Moodle, c’est la liste des versions dans la vue d’ensemble des plugins — pensez à la documenter.

5.3.2 Installer un plugin depuis le répertoire officiel

Le Moodle plugins directory (moodle.org/plugins) est le npm registry de Moodle : ~2000 plugins validés par un processus de revue avant publication. Deux voies d’installation via l’UI, toutes deux dans Administration du site > Plugins > Installer des plugins (/admin/tool/installaddon/) :

Voie 1 — bouton « Installer des plugins depuis le répertoire Moodle » : ce bouton vous envoie sur moodle.org/plugins ; après connexion avec un compte moodle.org, chaque fiche de plugin propose « Install now » avec la liste de vos sites enregistrés. Vous choisissez le site et la version, et Moodle vous ramène sur votre plateforme pour valider. En pratique, beaucoup d’administrateurs préfèrent la voie 2, plus directe.

Voie 2 — dépôt d’un fichier ZIP : téléchargez le ZIP du plugin depuis le répertoire (en choisissant la version compatible avec Moodle 5.2 — chaque fiche liste les versions de Moodle supportées), puis déposez-le dans la zone « Installer le plugin à partir d’un fichier ZIP ». Moodle :

1. détecte le type de plugin d’après la structure du ZIP (vous pouvez le forcer si la détection échoue) ;
2. valide le paquet : version de Moodle requise, dépendances déclarées, structure des fichiers ;
3. vérifie que le répertoire cible du code est inscriptible par le serveur web — sinon l’installation par UI est impossible ;
4. déploie les fichiers puis vous redirige vers Notifications pour exécuter la mise à niveau de la base (création des tables du plugin, réglages par défaut).

Voie 3 — installation manuelle : décompresser le ZIP directement dans le bon sous-répertoire du code (mod/, blocks/, local/…) via SFTP ou git clone, puis visiter Notifications. C’est la méthode obligatoire quand le répertoire de code n’est pas inscriptible par le serveur web (configuration recommandée en production, justement pour empêcher l’installation par UI). Le détail — et l’industrialisation par Git/CI — est traité dans la partie développement.

⚠️ Piège : la possibilité d’installer des plugins par l’UI signifie que le serveur web peut écrire dans le répertoire de code. C’est confortable en développement, mais en production c’est une surface d’attaque : un compte admin compromis peut alors déployer du PHP arbitraire. La configuration durcie consiste à rendre le code non inscriptible (le formulaire d’installation disparaît alors de lui-même) et à déployer les plugins uniquement par fichiers/Git.

5.3.3 Le processus de mise à jour d’un plugin

Mettre à jour un plugin suit exactement le cycle d’installation : nouveaux fichiers (par ZIP via l’UI, si autorisé, ou par déploiement manuel), puis passage par Notifications qui détecte la montée de version et exécute les migrations du plugin. La page Notifications liste les pending upgrades avec la version actuelle et la version cible ; le bouton « Mettre à niveau la base de données maintenant » exécute tout d’un bloc. Pendant l’opération, le site passe automatiquement en mode « mise à jour en cours » (voir section 5.5).

Moodle peut aussi vous notifier des mises à jour disponibles : Administration du site > Serveur > Notifications de mise à jour (updateautocheck) active une vérification périodique (via tâche planifiée) auprès de moodle.org, pour le cœur et les plugins additionnels ; les administrateurs reçoivent un e-mail et la vue d’ensemble des plugins affiche les mises à jour disponibles. Selon la configuration (updateautodeploy étant resté volontairement conservateur), l’installation en un clic des mises à jour depuis cette page obéit aux mêmes conditions d’inscriptibilité que l’installation par ZIP.

5.3.4 Désactiver vs désinstaller

Deux opérations très différentes :

• Désactiver (œil barré dans « Gérer les activités », « Gérer les blocs », etc.) : le plugin reste installé, ses données et réglages sont intacts, mais il devient invisible/inutilisable. Les instances existantes (ex. les activités d’un module désactivé dans les cours) sont masquées, pas supprimées. Opération réversible instantanément — c’est le geste de premier secours quand un plugin cause un problème.
• Désinstaller (lien « Désinstaller » dans la vue d’ensemble des plugins) : Moodle supprime les tables du plugin, ses réglages, ses instances dans les cours et les données utilisateur associées. Une page de confirmation détaille l’impact. Irréversible sans restauration de sauvegarde.

Subtilité importante : la désinstallation supprime les données mais pas les fichiers de code (Moodle, par prudence, ne supprime les fichiers par l’UI que s’il en a les droits, et vous propose alors de le faire ; sinon il vous demande de les retirer manuellement). Si les fichiers restent en place, Moodle réinstallera le plugin au prochain passage sur Notifications ! Une désinstallation propre = désinstallation UI puis suppression du répertoire de code.

⚠️ Piège : l’ordre inverse est tout aussi piégeux. Si vous supprimez les fichiers d’un plugin sans l’avoir désinstallé, la vue d’ensemble des plugins l’affichera comme « Manquant dans le code » (missing from disk), avec ses tables et données orphelines en base. Le site fonctionne, mais l’état est incohérent et pollue chaque future mise à jour. Remettez les fichiers, puis désinstallez dans les règles.

5.3.5 Plugins additionnels : risques et critères d’évaluation

Chaque plugin additionnel est un engagement de maintenance. Les risques concrets :

• Compatibilité aux upgrades : c’est LE point dur. Une montée de version Moodle (5.2 → 5.3) peut casser un plugin non maintenu ; vous ne pouvez alors pas mettre Moodle à jour sans désinstaller ou remplacer le plugin. Les mises à jour majeures se planifient en commençant par l’inventaire des plugins additionnels.
• Sécurité : le code tiers a le même niveau de privilège que le cœur. Un plugin mal écrit = injection SQL ou XSS potentielle sur toute la plateforme. Le processus de revue du répertoire officiel filtre le pire, mais ne vaut pas audit.
• Performance : certains plugins ajoutent des requêtes sur chaque page ou des observers sur des événements très fréquents.
• Réversibilité : plus un plugin accumule de données (ex. un module d’activité utilisé dans 500 cours), plus il est coûteux de s’en séparer.

Critères d’évaluation d’une fiche du répertoire, dans l’ordre d’importance :

💡 Pour un dev React : c’est la même hygiène que pour choisir un package npm — téléchargements hebdo, date du dernier commit, issues ouvertes — avec un facteur aggravant : il n’y a pas de semver contraignant ni de bundler qui isole les versions. Deux plugins ne peuvent pas embarquer chacun « leur » version d’une dépendance : tout le monde partage le même runtime et les mêmes API du cœur. D’où le poids énorme du critère « suivi des versions majeures de Moodle ».

📚 Aller plus loin : la page « Plugins overview » de moodledev.io documente tous les types de plugins et leurs contrats ; et sur moodle.org/plugins, l’onglet « Stats » de chaque fiche montre la courbe d’adoption par version de Moodle — très parlant pour jauger si la communauté a suivi le plugin sur 5.x.

5.4 Tâches planifiées et cron : le cœur battant de Moodle

Section fondamentale. Un Moodle sans cron fonctionnel est un Moodle cassé, même si les pages s’affichent normalement. C’est la première chose à vérifier sur toute installation.

5.4.1 Pourquoi Moodle dépend du cron

PHP, dans son modèle classique, ne vit que le temps d’une requête HTTP : aucun processus permanent ne tourne en arrière-plan. Tout ce qui doit se passer en dehors d’une action utilisateur doit donc être déclenché par un mécanisme externe : le cron. Concrètement, dépendent du cron :

• l’envoi des e-mails différés : notifications de forum, digests, confirmations, rappels de devoirs ;
• les notifications push mobiles et les messages ;
• les synchronisations : inscriptions LDAP, flux de cohortes, inscriptions par fichier plat, mises à jour des packs de langue ;
• la complétion de cours et l’attribution automatique des badges ;
• les statistiques, le calcul des logs agrégés, le report builder planifié ;
• le nettoyage : sessions expirées, brouillons de fichiers, corbeille (recycle bin), purge des logs (loglifetime), suppression définitive des comptes ;
• les sauvegardes de cours automatiques ;
• l’ouverture/fermeture programmée de quiz et devoirs (certains traitements), la mise en file des travaux de plagiat, etc.

Symptômes classiques d’un cron cassé — apprenez-les par cœur, ce sont des tickets de support que vous recevrez un jour :

Moodle affiche d’ailleurs un avertissement bien visible sur la page Notifications (et dans les vérifications de statut) si le cron n’a pas tourné récemment.

5.4.2 Configurer le cron système

Le principe : le système d’exploitation exécute php admin/cli/cron.php à intervalle régulier. La recommandation officielle est de le lancer toutes les minutes (*/1). Ne craignez rien : chaque exécution ne lance que les tâches effectivement dues ; un passage « à vide » coûte quelques millisecondes.

Linux (crontab) — sous l’utilisateur qui possède les fichiers ou l’utilisateur du serveur web (ex. www-data), jamais root :

* * * * * /usr/bin/php /var/www/moodle/admin/cli/cron.php > /dev/null

Windows (Planificateur de tâches) : créez une tâche de base exécutant C:\php\php.exe C:\chemin\vers\moodle\admin\cli\cron.php, déclencheur « à l’heure prévue, répéter toutes les 1 minute indéfiniment ». (Historiquement, un utilitaire moodle-cron-for-windows a existé ; le Planificateur natif suffit largement.)

Alternative dépréciée — le cron par URL web : historiquement, on pouvait appeler https://votre-site/admin/cron.php depuis un cron distant ou un service de ping. C’est déconseillé : timeouts PHP du serveur web, pas de parallélisme, exposition publique d’un point d’entrée coûteux. Si vous n’avez vraiment pas d’autre choix (hébergement mutualisé sans crontab), il faut désactiver le réglage de sécurité cronclionly (« Exécuter le cron uniquement en ligne de commande », activé par défaut — voir section 5.8) et définir un mot de passe de cron (cronremotepassword), à passer en paramètre : .../admin/cron.php?password=xxx.

💡 Pour un dev React : admin/cli/cron.php toutes les minutes, c’est votre vercel.json avec un cron * * * * * qui frappe une route API — sauf que Moodle inverse le modèle : au lieu de déclarer une route par job, un seul point d’entrée réveille un ordonnanceur interne qui décide quelles tâches sont dues. Vous ne configurez donc la fréquence de chaque tâche pas dans le crontab système, mais dans l’UI de Moodle (section suivante). Le crontab système ne fait que fournir le « tick » d’horloge.

5.4.3 Scheduled tasks vs adhoc tasks

Le sous-système de tâches distingue deux familles :

• Tâches planifiées (scheduled tasks) : récurrentes, déclarées par le cœur et les plugins, avec une planification par défaut modifiable dans l’UI. Exemples : « Envoyer les messages des forums », « Nettoyer les sessions », « Synchroniser les inscriptions LDAP ». Il y en a plus de 200 sur un site standard.
• Tâches ad hoc (adhoc tasks) : ponctuelles, mises en file d’attente par une action, exécutées au prochain passage du cron puis supprimées. Exemples : suppression asynchrone d’une activité (la corbeille), restauration de gros cours, envoi d’un e-mail précis, conversion de documents. Elles peuvent être nombreuses après une opération de masse (une file de milliers de tâches ad hoc après une suppression massive de cours est normale).

Le passage de cron traite d’abord les tâches planifiées dues, puis dépile les tâches ad hoc, dans les limites de temps configurées.

5.4.4 Gérer les tâches dans l’UI

Administration du site > Serveur > Tâches > Tâches planifiées (/admin/tool/task/scheduledtasks.php). Pour chaque tâche : composant d’origine, dernière exécution (avec durée et éventuel échec), prochaine exécution, planification, et actions. En cliquant sur l’engrenage d’une tâche :

• Modifier la planification avec la syntaxe cron classique à cinq champs — minute, heure, jour du mois, mois, jour de la semaine — acceptant *, listes (1,15), plages (8-18) et pas (*/15). Exemple : passer les sauvegardes automatiques de cours à 0 2 * * 6 (samedi 2 h). Un bouton « Réinitialiser aux valeurs par défaut » existe pour chaque tâche.
• Désactiver la tâche (case « Désactivé »). Certaines tâches sont livrées désactivées par défaut (ex. certains nettoyages agressifs) ; d’autres n’apparaissent actives que si la fonctionnalité correspondante est activée.
• Noter qu’une tâche dont le plugin est désactivé s’affiche grisée et ne tourne pas.

Deux outils d’exploitation précieux sur cette même page :

• Exécuter maintenant (Run now) : force l’exécution immédiate d’une tâche, via le serveur web ou en déclenchant le CLI selon configuration (\core\task utilise le réglage « Autoriser Exécuter maintenant », enablerunnow). Idéal pour tester une sync LDAP fraîchement configurée sans attendre la nuit. L’équivalent CLI, encore plus fiable : php admin/cli/scheduled_task.php --execute='\core\task\send_new_user_passwords_task' (le nom exact de la classe est affiché dans l’UI) et php admin/cli/adhoc_task.php --execute pour dépiler la file ad hoc.
• Logs des tâches (Task logs, Administration du site > Serveur > Tâches > Journaux des tâches) : depuis Moodle 3.7, chaque exécution de tâche (planifiée ou ad hoc) est journalisée avec durée, résultat (succès/échec), consommation base de données, et la sortie complète de la tâche consultable en un clic. C’est votre premier réflexe quand « la sync ne marche pas » : lisez le log de la tâche, l’erreur y est presque toujours en toutes lettres. La durée de rétention de ces logs est configurable (task_logretention, ainsi que task_logretainruns pour le nombre d’exécutions conservées par tâche).

5.4.5 Tâches en échec : fail delay et backoff

Quand une tâche lève une exception, Moodle ne la relance pas immédiatement en boucle : il applique un délai d’échec (fail delay) avec backoff exponentiel — 1 minute, puis 2, 4, 8… jusqu’à un plafond de 24 heures. La colonne « Délai en cas d’échec » de la page des tâches planifiées montre ce délai ; une valeur élevée (86400) signifie que la tâche échoue depuis longtemps. Le bouton « Effacer » (Clear fail delay) remet le compteur à zéro pour retenter immédiatement — après avoir corrigé la cause, évidemment. Le même mécanisme s’applique aux tâches ad hoc, dont les échecs répétés sont visibles dans les journaux des tâches ; une page dédiée aux tâches ad hoc (Administration du site > Serveur > Tâches > Tâches ad hoc, ajoutée en 4.x) liste la file, les échecs et leur fail delay.

⚠️ Piège : le backoff est traître en silence. Une tâche de sync LDAP qui a échoué huit fois de suite (mot de passe du compte de service expiré, par exemple) ne retentera que dans 24 h même après correction du mot de passe. Si vous corrigez la cause d’un échec, pensez à effacer le fail delay (ou « Exécuter maintenant »), sinon vous conclurez à tort que votre correction ne fonctionne pas.

⚠️ Piège : « Exécuter maintenant » via l’interface web exécute la tâche avec les limites PHP du serveur web (timeout, mémoire). Pour une grosse tâche (statistiques, sauvegardes), préférez toujours le CLI scheduled_task.php --execute=..., qui tourne sans limite de temps.

5.4.6 Cron parallèle et réglages avancés

Sur les gros sites, un seul processus cron ne suffit plus (imaginez 50 000 e-mails de digest à envoyer). Moodle supporte l’exécution de plusieurs processus cron en parallèle : vous pouvez lancer plusieurs cron.php simultanément (ou plusieurs entrées crontab décalées), le sous-système de tâches posant des verrous pour qu’une même tâche ne soit jamais exécutée deux fois en même temps. Les réglages associés (Administration du site > Serveur > Tâches > Traitement des tâches, Task processing) : nombre maximal de processus cron concurrents (task_scheduled_concurrency_limit, et son pendant ad hoc), durée maximale d’un passage (cron_keepalive sur les versions récentes, le processus restant actif quelques minutes pour dépiler sans attendre le tick suivant). Retenez simplement que c’est le mécanisme prévu pour scaler, et que sa mise au point fine relève de la partie exploitation avancée. Un php admin/cli/cron.php --list affiche l’état des tâches en ligne de commande ; --stop demande l’arrêt propre des crons en cours.

💡 Pour un dev React : scheduled tasks vs adhoc tasks, c’est exactement cron jobs vs message queue (BullMQ/SQS). Les scheduled tasks sont vos crons déclaratifs ; les adhoc tasks sont des jobs poussés dans une queue avec retry et backoff exponentiel — Moodle implémente les deux au-dessus du même « tick » système, avec la table de base de données comme broker. Et le « fail delay », c’est la dead-letter queue du pauvre : le job n’est pas perdu, il est juste reprogrammé loin dans le futur.

📚 Aller plus loin : la page « Cron » de docs.moodle.org (administration) détaille les variantes d’installation système (systemd timers, Kubernetes CronJob, hébergements mutualisés), et la documentation développeur « Task API » sur moodledev.io explique verrous, réentrance et bonnes pratiques — utile à lire même sans coder, pour comprendre ce que font les plugins que vous installez.

5.5 Mode maintenance

5.5.1 Activer via l’UI

Administration du site > Serveur > Mode de maintenance (/admin/settings.php?section=maintenancemode). Deux réglages :

• maintenance_enabled : bascule le site en maintenance ;
• maintenance_message : message HTML affiché aux visiteurs (« Maintenance prévue jusqu’à 7 h, merci de votre patience »).

En mode maintenance, toute personne non administrateur est déconnectée des pages et voit le message ; les administrateurs peuvent toujours se connecter et utiliser le site normalement (c’est le but : opérer pendant que les utilisateurs sont dehors). La page de connexion reste accessible pour permettre aux admins d’entrer.

5.5.2 Activer via CLI

Indispensable pour scripter les fenêtres de maintenance :

php admin/cli/maintenance.php --enable
php admin/cli/maintenance.php --disable
php admin/cli/maintenance.php          # affiche l'état actuel

Le CLI propose aussi --enablelater=MINUTES (bascule différée, laissant aux utilisateurs le temps de terminer) et surtout --enableold : le « vieux » mode maintenance, qui dépose un fichier climaintenance.html dans moodledata. Ce mode-là bloque tout PHP Moodle avant même le chargement de l’application — y compris pour les admins — et c’est le seul vraiment sûr pendant une opération lourde sur la base de données. Pour en sortir : supprimer le fichier moodledata/climaintenance.html.

5.5.3 Le mode « mise à niveau en cours » automatique

Distinct du mode maintenance volontaire : pendant qu’une mise à niveau de la base est en attente ou en cours (après dépôt d’une nouvelle version du code — cf. page Notifications), Moodle bloque automatiquement les non-admins avec un message « mise à jour en cours ». Vous n’avez rien à activer ; mais pour une mise à jour majeure planifiée, la bonne pratique reste d’activer explicitement le mode maintenance avant de toucher au code, pour contrôler le message et le moment.

5.5.4 Pièges du mode maintenance

• Le cron continue de tourner en mode maintenance (les tâches planifiées et ad hoc s’exécutent). C’est généralement souhaitable (les nettoyages continuent), mais si votre maintenance touche la base de données, arrêtez aussi le cron (commentez le crontab ou utilisez --enableold), sinon des tâches écriront en base pendant votre opération.
• Les web services (API mobile notamment) sont également bloqués en maintenance — les utilisateurs de l’app mobile verront des erreurs, pas votre joli message. Prévenez en amont.
• Le mode maintenance UI nécessite que Moodle démarre (PHP + base OK). Si votre opération casse temporairement la base (dump/restore, migration serveur), le mode UI affichera une erreur brute, pas votre message. Pour ces cas : --enableold, ou mieux, une page de maintenance au niveau du serveur web (règle nginx/Apache renvoyant un 503 avec une page statique, ou bascule au load balancer). C’est la seule approche propre pour les grosses opérations : elle ne dépend de rien côté Moodle et renvoie un vrai code 503 aux moteurs de recherche.

💡 Pour un dev React : le mode maintenance UI, c’est un feature flag runtime lu par l’application — il suppose que l’app tourne. La page 503 au niveau nginx/load balancer, c’est la page de maintenance servie par le CDN/edge (comme une rewrite Vercel vers une page statique) : elle fonctionne même app morte. Même raisonnement, mêmes limites : pour toute opération risquée, coupez au-dessus de l’application, pas dedans.

⚠️ Piège : après une maintenance, on oublie une fois sur deux de désactiver quelque chose : le mode maintenance lui-même, le fichier climaintenance.html, ou le crontab commenté. Faites de la checklist de sortie de maintenance un rituel : mode désactivé, cron réactivé, page Notifications propre, un e-mail de test envoyé.

5.6 Notifications et messagerie

5.6.1 Architecture : messages, notifications et message outputs

Le sous-système de messagerie de Moodle distingue :

• les messages personnels (conversations entre utilisateurs, messagerie instantanée intégrée) ;
• les notifications (messages système unidirectionnels : « votre devoir a été corrigé », « nouveau message dans le forum X », « badge obtenu »).

Chaque notification appartient à un type de message déclaré par un composant (le cœur ou un plugin), et peut être délivrée par un ou plusieurs canaux de sortie de message (message outputs), qui sont eux-mêmes des plugins :

(Le canal historique Jabber a été retiré des versions modernes ; des plugins tiers le remplacent au besoin.)

5.6.2 La matrice des notifications

Administration du site > Général > Messagerie > Réglages de notification (Notification settings, /admin/message.php). C’est une matrice types de message × outputs, avec pour chaque case trois états possibles côté administration :

• Verrouillé activé (Locked on / Forced) : le canal est imposé, l’utilisateur ne peut pas le désactiver — typiquement l’e-mail pour les notifications critiques ;
• Activé par défaut (Enabled) : valeur par défaut, mais l’utilisateur peut changer dans ses préférences ;
• Désactivé (Disabled/Off) : canal indisponible pour ce type de message.

En haut de cette page, vous activez/désactivez chaque output globalement (un output désactivé disparaît de toute la matrice), et le réglage général messaging (Fonctions avancées) contrôle l’existence même de la messagerie personnelle entre utilisateurs (les notifications système, elles, restent toujours actives).

Côté utilisateur, chacun règle ses préférences dans Menu utilisateur > Préférences > Préférences de notification : la même matrice, limitée aux cases non verrouillées, souvent avec distinction « connecté / hors ligne » selon les versions et canaux. Retenez le principe : l’admin fixe les défauts et les verrous, l’utilisateur personnalise le reste.

⚠️ Piège : « les utilisateurs ne reçoivent pas les e-mails de X » a trois suspects, dans cet ordre : (1) le cron (la plupart des notifications partent par tâche planifiée) ; (2) la matrice de notifications (canal e-mail désactivé pour ce type de message, ou désactivé par l’utilisateur dans ses préférences) ; (3) la configuration SMTP elle-même. Vérifiez dans cet ordre, vous gagnerez des heures.

5.6.3 E-mail sortant : SMTP et délivrabilité

Administration du site > Serveur > Courriel > Configuration du courriel sortant :

• smtphosts : hôte(s) SMTP (smtp.example.com:587) ; vide, Moodle utilise la fonction mail() de PHP — à éviter en production ;
• smtpsecure (TLS/SSL), smtpauthtype, smtpuser/smtppass : sécurité et authentification SMTP (OAuth 2 est possible pour Microsoft 365/Google via les services OAuth configurés au chapitre 3) ;
• noreplyaddress : l’adresse expéditrice utilisée quand l’expéditeur réel ne doit pas être exposé (noreply@votredomaine) — configurez-la sur un domaine que vous contrôlez ;
• allowedemaildomains / denyemailaddresses : domaines autorisés/refusés pour les adresses des comptes ;
• emailfromvia et les réglages « e-mails toujours envoyés depuis noreply » : de plus en plus nécessaires à l’ère de DMARC, car envoyer « de la part de prof@gmail.com » depuis votre serveur fera rejeter le message.

Mentionnons DKIM : Moodle sait signer ses e-mails sortants en DKIM (réglages emaildkimselector, certificats déposés côté serveur), en complément de SPF et DMARC à configurer dans votre DNS. Sans ce trio, vos notifications finiront en spam — la délivrabilité est un sujet d’infrastructure autant que de Moodle. Un bouton « Tester la configuration du courriel sortant » (Administration du site > Serveur > Courriel > Test de la configuration) envoie un e-mail de test : utilisez-le après chaque changement.

5.6.4 Push mobile : app Moodle et Airnotifier

L’application mobile officielle Moodle reçoit des notifications push via Airnotifier, un service de passerelle. Le chemin standard :

1. Activer les web services mobiles : Administration du site > Général > Fonctions avancées > enablemobilewebservice (« Activer les services web pour les appareils mobiles »). Sans cela, l’app mobile ne peut même pas se connecter au site.
2. Activer l’output Airnotifier dans les réglages de notification, et le connecter : par défaut, Moodle utilise l’instance Airnotifier hébergée par Moodle HQ, avec une clé d’accès demandée en un clic (bouton « Request access key ») — le site doit être enregistré auprès de moodle.org. Les grandes organisations peuvent héberger leur propre Airnotifier.
3. Régler les cases « Mobile » dans la matrice des notifications.

Notez que l’usage de l’app avec les services de Moodle HQ obéit à des plans (limites de notifications selon l’abonnement Moodle Apps) — vérifiez les conditions en vigueur pour votre volumétrie.

5.6.5 Digest des forums

Les notifications de forum, premier consommateur d’e-mails d’un Moodle, offrent un mode digest : au lieu d’un e-mail par message, un récapitulatif quotidien (complet ou par sujets). L’heure d’envoi du digest est un réglage de site (digestmailtime, recherche : digest), et chaque utilisateur choisit son mode dans ses préférences de forum (par défaut modifiable par l’admin). Les digests partent, bien sûr, via le cron — encore lui.

💡 Pour un dev React : la matrice types × outputs est un routeur de notifications multi-canal, comme Novu ou Knock : le composant émet un événement typé, la couche messaging résout les canaux selon (config admin ⊕ préférences utilisateur) et pousse vers les providers (SMTP, push). « Verrouillé activé » = canal forcé côté serveur, hors de portée des préférences client — pensez-y comme une valeur de config non surchargeable par l’utilisateur.

📚 Aller plus loin : la page « Notifications » de docs.moodle.org et la doc « Moodle Apps portal » détaillent les plans de notifications push et la configuration d’un Airnotifier auto-hébergé ; le chapitre développement de cette documentation reviendra sur la Message API pour créer vos propres types de notification.

5.7 Logs et logstores

5.7.1 Architecture : événements et magasins de logs

Depuis Moodle 2.7, toute action significative déclenche un événement (event) : objet structuré portant l’utilisateur acteur, l’objet affecté, le contexte (cours, module…), le niveau éducatif et un nom de classe précis (ex. \mod_quiz\event\attempt_submitted). Les événements sont consommés par des logstores (magasins de journaux), qui sont — vous l’avez deviné — des plugins :

Administration du site > Plugins > Journalisation > Gérer les magasins de journaux (Manage log stores) :

Plusieurs logstores peuvent être actifs simultanément (chaque événement est distribué à tous). L’ordre et l’activation se gèrent sur cette page comme pour tout type de plugin.

Le concept d’événement lui-même — comment en émettre, les observer — relève de la partie développement ; côté admin, la page Administration du site > Rapports > Liste des événements (Events list) cataloge tous les événements existants avec leur composant et leur niveau, précieuse pour construire des filtres de logs pertinents.

5.7.2 Réglages du logstore standard

Sur la page des magasins de journaux, l’engrenage du logstore standard donne accès à :

• loglifetime (durée de conservation) : « Conserver les journaux pendant » — jamais/x jours/x mois. Le réglage le plus important de cette section. Par défaut « jamais supprimer », ce qui signifie que mdl_logstore_standard_log grossit indéfiniment ;
• buffersize (taille du tampon) : nombre d’événements accumulés en mémoire avant écriture groupée en base (défaut 50) — micro-optimisation d’écriture ;
• JSON format : stockage du champ other en JSON (défaut sur les versions récentes).

5.7.3 La table qui mange votre base : mdl_logstore_standard_log

Sur toute installation active, mdl_logstore_standard_log devient rapidement la plus grosse table de la base, souvent 60–80 % du volume total : des dizaines de millions de lignes en quelques années sont banales. Conséquences : sauvegardes plus longues, restaurations interminables, upgrades ralentis, requêtes de rapports pénibles.

Bonnes pratiques de performance :

1. Fixez loglifetime dès la mise en production. Une rétention de 6 à 12 mois couvre l’essentiel des besoins pédagogiques et de support ; les obligations légales de conservation plus longues se traitent par export/archivage externe, pas en gardant tout en production.
2. La purge est effectuée par une tâche planifiée (nettoyage des logs) : après avoir réduit loglifetime sur un site qui a des années de logs, la première purge peut être très lourde — planifiez-la en heures creuses et surveillez-la dans les journaux de tâches.
3. Pour l’analytique long terme, préférez le logstore external database vers une base dédiée, et gardez la production légère.
4. Sachez que supprimer des lignes ne rend pas mécaniquement l’espace disque au système (selon le moteur de base) — la récupération d’espace est une opération DBA distincte.

⚠️ Piège : ne videz jamais la table de logs directement en SQL « pour faire de la place » sans comprendre les dépendances : certains rapports de complétion « d’accès au cours », le bloc d’activité récente et des plugins d’analytique lisent ces données. Réduire loglifetime et laisser la tâche de purge travailler est la voie sûre ; le TRUNCATE sauvage est la voie du ticket de support incompréhensible trois mois plus tard.

5.7.4 Consulter les logs

Administration du site > Rapports > Journaux (Logs, /report/log/index.php) — également accessible dans chaque cours (Administration du cours > Rapports > Journaux, filtré sur le cours). Filtres disponibles :

• cours (ou site entier), et éventuellement groupe ;
• participant (utilisateur) ;
• date (jour) ;
• activité (module précis du cours) ;
• actions (créer/voir/mettre à jour/supprimer) ;
• niveau éducatif : enseignement (actions de l’enseignant), participation (actions de l’apprenant), autre — c’est le champ edulevel des événements, très utile pour séparer « le prof a réglé le quiz » de « l’élève a passé le quiz » ;
• source : quel logstore lire (standard, legacy si activé).

Le résultat est un tableau paginé : heure, nom complet de l’utilisateur, utilisateur affecté, contexte d’événement, composant, nom de l’événement, description (phrase générée, ex. « The user with id ‘123’ submitted the attempt… »), origine (web/cli/ws/restore) et adresse IP. Export possible en CSV/Excel/ODS pour analyse externe.

Journaux en direct (Live logs, Administration du site > Rapports > Journaux en direct) : les 60 dernières minutes, avec rafraîchissement automatique et bouton pause. C’est l’outil de démonstration et de débogage immédiat : « clique sur le bouton, je regarde ce que ça déclenche ».

💡 Pour un dev React : le logstore standard, c’est votre pipeline d’événements analytics (Segment/PostHog) avec un seul sink par défaut : la base de prod. Le rapport Logs est un explorateur d’événements rudimentaire ; le live log, votre tail -f. Et loglifetime, c’est la retention policy que vous configureriez dans n’importe quel outil d’observabilité — sauf qu’ici, l’oublier fait grossir votre base de production, pas la facture d’un SaaS.

📚 Aller plus loin : le Report builder (Administration du site > Rapports > Constructeur de rapports, en cœur depuis Moodle 4.0) permet de créer des rapports personnalisés persistants (sources : utilisateurs, cours, cohortes…), avec planification d’envoi par e-mail et audiences — bien plus confortable que le rapport de logs brut pour un suivi récurrent. Les sources de données du report builder s’enrichissent à chaque version.

5.8 Sécurité de base

Ce qui suit complète le chapitre 3 (mots de passe, MFA, authentification) par le volet plateforme. La sécurité Moodle est un sujet d’infrastructure et de réglages ; voici le socle minimal que tout admin doit maîtriser.

5.8.1 HTTPS partout

En 2026, le débat n’existe plus : $CFG->wwwroot doit être en https:// (défini dans config.php à l’installation), avec un certificat valide et un renouvellement automatisé. Points d’attention Moodle :

• le réglage cookiesecure (Administration du site > Général > Sécurité > Sécurité HTTP) marque les cookies de session Secure — il est forcé automatiquement quand wwwroot est en HTTPS sur les versions modernes ; vérifiez-le ;
• activez HSTS au niveau du serveur web (header Strict-Transport-Security) — Moodle ne le pose pas pour vous ;
• si vous migrez un vieux site HTTP vers HTTPS, l’outil de recherche/remplacement de contenu (admin/tool/httpsreplace) corrige les URL embarquées dans les contenus.

5.8.2 Le menu Sécurité

Administration du site > Général > Sécurité regroupe :

Bloqueur d’IP (IP blocker) : listes d’IP/plages autorisées ou refusées pour l’accès au site entier. Utile en urgence (blocage d’un scraper agressif), mais le blocage au niveau du pare-feu ou du reverse proxy reste préférable à grande échelle.

Réglages de sécurité du site (Site security settings) — les plus importants :

Sécurité HTTP (HTTP security) : au-delà de cookiesecure, cette page contient un réglage critique et sous-estimé : curlsecurityblockedhosts / curlsecurityallowedport (hôtes bloqués et ports autorisés pour cURL). Moodle effectue des requêtes HTTP sortantes pour le compte des utilisateurs (dépôt URL, flux RSS, LTI, import d’images par URL…). Sans restriction, un utilisateur peut faire requêter par le serveur des cibles internes : http://169.254.169.254/ (métadonnées cloud AWS/GCP !), localhost, vos services internes — c’est la faille SSRF (Server-Side Request Forgery, falsification de requête côté serveur). Bloquez au minimum 127.0.0.1, localhost, 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12, 169.254.169.254, et limitez les ports à 443 (et 80 si nécessaire). Cette page héberge aussi les options d’en-têtes (referrer policy, options de frame) selon les versions.

⚠️ Piège : les hôtes bloqués cURL sont vides par défaut sur beaucoup d’installations historiques. Si votre Moodle tourne dans un cloud (AWS, Azure, GCP), l’absence de blocage de 169.254.169.254 permet potentiellement d’exfiltrer les credentials du rôle IAM de la machine via une simple ressource URL. C’est l’un des premiers points que vérifie tout audit de sécurité Moodle — vérifiez-le aujourd’hui.

5.8.3 Le rapport « Vérifications de sécurité »

Administration du site > Rapports > Vérifications de sécurité (Security checks, depuis Moodle 3.9 — auparavant « Security overview »). Ce rapport exécute une batterie de contrôles automatiques et affiche OK / Avertissement / Critique avec explication et lien vers le réglage concerné. Parmi les vérifications : mode debug affiché en production, fichiers de moodledata exposés au web, politique de mots de passe, cronclionly, inscriptions par e-mail ouvertes à tous les domaines, comptes admin sans MFA (versions récentes), embedding autorisé, XSS-risk des rôles attribués, version de Moodle non maintenue, hôtes cURL non restreints… Passez ce rapport en revue après chaque installation et chaque upgrade majeure : c’est un audit gratuit.

5.8.4 Notifications de sécurité et cycle de vie des versions

Enregistrez votre site auprès de moodle.org (Administration du site > Général > Enregistrement) : outre l’accès aux push mobiles (5.6.4), l’enregistrement vous abonne aux annonces de sécurité. Les correctifs de sécurité de Moodle sont publiés à cadence régulière (versions mineures type 5.2.x) et les détails des failles sont rendus publics une semaine environ après la sortie des correctifs : un site non patché après publication est une cible documentée. Abonnez-vous également à la liste de diffusion sécurité de moodle.org et suivez le calendrier de fin de support de votre branche (les branches classiques reçoivent des correctifs de sécurité ~18 mois ; les LTS comme 4.5/5.3, ~3 ans — vérifiez le calendrier officiel pour votre branche exacte).

Le durcissement des comptes administrateurs (MFA — plugin tool_mfa intégré au cœur depuis Moodle 4.4 —, comptes nominatifs, revue régulière de la liste des admins) a été traité au chapitre 3 ; rappelons seulement qu’un unique compte admin partagé « admin/admin2024 » ruine tout le reste de cette section.

Enfin, un mot sur les sauvegardes : la sécurité inclut la capacité à restaurer. Sauvegarde cohérente = base de données + moodledata + code (avec config.php), idéalement prises pendant une fenêtre calme ou avec des mécanismes de snapshot. Les sauvegardes de cours automatiques de Moodle (Administration du site > Cours > Sauvegardes) ne remplacent pas une sauvegarde d’infrastructure — elles servent à restaurer un cours, pas un site. Le détail opérationnel relève de la partie exploitation.

💡 Pour un dev React : le rapport Security checks, c’est npm audit + le « production checklist » de Next.js réunis : un lint de configuration exécuté par la plateforme elle-même. Et la restriction des hôtes cURL est l’exact équivalent de la validation d’URL que vous écririez dans une route API qui fetch une URL fournie par l’utilisateur — même faille SSRF, même parade, sauf qu’ici c’est un réglage et non du code.

📚 Aller plus loin : la page « Security recommendations » de docs.moodle.org est la référence de durcissement complète (permissions fichiers, isolation de moodledata hors racine web, en-têtes serveur) ; et le programme de bug bounty de Moodle documente les classes de vulnérabilités historiques — instructif pour comprendre ce qu’on protège.

5.9 Environment checks et vérifications de statut

5.9.1 La page Environnement

Administration du site > Serveur > Environnement (/admin/environment.php) confronte votre serveur aux exigences de la version courante et des versions futures (menu déroulant : très utile pour anticiper une mise à jour vers 5.3+ des mois à l’avance). Chaque ligne indique OK / à corriger, en distinguant exigences bloquantes et recommandations.

Exigences de Moodle 5.2 (vérifiées sur moodledev.io) :

⚠️ Piège : max_input_vars trop bas ne produit aucune erreur visible : PHP tronque silencieusement les données POST. Symptômes surréalistes : la page des permissions d’un rôle « oublie » des capacités en bas de formulaire à l’enregistrement, un quiz perd ses dernières questions. Si un formulaire long « perd » des données, pensez max_input_vars avant de soupçonner un bug Moodle.

5.9.2 Vérifications de statut, PHP info

• Administration du site > Rapports > Vérifications de statut (Status checks, cousin du rapport sécurité, depuis 3.9) : santé opérationnelle — le cron a-t-il tourné récemment, des tâches sont-elles en échec, la base et les caches répondent-ils. C’est la page à mettre en favori (et elle est interrogeable en supervision — voir plus bas).
• Administration du site > Serveur > PHP info : le phpinfo() complet, sans accès shell.

5.9.3 Performance de base

Deux fondamentaux côté serveur, vérifiés par la page Environnement :

• OPcache : le cache d’opcodes PHP est indispensable (recommandation officielle avec des réglages précis type opcache.memory_consumption) ; sans lui, chaque requête recompile des milliers de fichiers PHP — Moodle est plusieurs fois plus lent.
• Caches applicatifs (MUC, Moodle Universal Cache) : Moodle cache énormément (chaînes de langue, définitions de config, données de cours) via des cache stores configurables (fichiers par défaut, Redis recommandé en production ; Administration du site > Plugins > Caching). La conception de MUC et son paramétrage fin sont traités dans la partie développement/exploitation ; retenez ici l’outil d’exploitation essentiel : purger les caches via Administration du site > Développement > Purger les caches, ou en CLI :

php admin/cli/purge_caches.php

La purge des caches est le « avez-vous essayé de redémarrer ? » de Moodle : après un changement de thème, de chaîne de langue ou un comportement d’affichage incohérent, c’est le premier geste — inoffensif, mais coûteux sur un gros site le temps que les caches se reconstruisent (bref pic de charge).

💡 Pour un dev React : la page Environnement, c’est un preflight check de déploiement — le même rôle que next build qui valide Node version/lockfile avant de déployer, ou qu’un job CI « environment sanity ». Et purge_caches.php est votre rm -rf .next && next build : purge du cache compilé + invalidation des données mémoïsées. Même réflexe, mêmes effets de bord (premier chargement lent).

📚 Aller plus loin : les status checks sont exposés pour la supervision : php admin/cli/checks.php en CLI retourne l’état global (exploitable par Nagios/Zabbix), permettant d’alerter automatiquement sur « cron en retard » ou « tâche en échec » au lieu de le découvrir dans l’UI. Couplez-le à votre supervision existante dès la mise en production.

5.10 Checklist d’exploitation et chemins récapitulatifs

5.10.1 Routine d’exploitation

5.10.2 Chemins UI récapitulatifs du chapitre

Et les trois commandes CLI d’exploitation à connaître par cœur :

php admin/cli/cron.php              # exécuter un passage de cron
php admin/cli/purge_caches.php     # purger tous les caches
php admin/cli/maintenance.php --enable|--disable   # mode maintenance

Résumé

• La zone Administration du site centralise toute la configuration ; la barre de recherche des réglages (par nom interne : forcelogin, loglifetime…) est l’outil de travail principal, et la page Notifications joue le rôle de tableau de bord de santé et d’orchestrateur des migrations (code déposé → upgrade de la base). Tout réglage peut être verrouillé par config.php (il apparaît alors grisé).
• La configuration post-installation couvre l’identité du site, la page d’accueil (versions connecté/anonyme, defaulthomepage), les politiques de site (forcelogin, protection des profils), la localisation (fuseau, pays) et les langues : pack fr avec héritage fr_ca → fr → en, détection navigateur, et surcharge de chaînes via la personnalisation de la langue (stockée dans fr_local, résistante aux mises à jour).
• Les plugins sont typés (mod_, block_, theme_, auth_, enrol_…) ; installation par le répertoire officiel ou par ZIP (si le code est inscriptible — à proscrire en prod durcie), mise à jour via Notifications, et distinction cruciale entre désactiver (réversible) et désinstaller (supprime tables, réglages et données — puis retirer les fichiers, sinon réinstallation automatique). Évaluer un plugin = compatibilité 5.2 déclarée, fraîcheur des releases, nombre de sites, vitalité du dépôt GitHub.
• Le cron est vital : php admin/cli/cron.php toutes les minutes via crontab/Planificateur Windows. Il exécute les tâches planifiées (récurrentes, planification cron modifiable dans l’UI, « Exécuter maintenant ») et dépile les tâches ad hoc (file d’attente avec retry et backoff exponentiel — penser à effacer le fail delay après correction). Journaux des tâches = premier réflexe de diagnostic. Symptômes de cron cassé : e-mails muets, badges non délivrés, syncs inertes.
• Le mode maintenance existe en trois saveurs : UI (les admins passent encore), CLI maintenance.php (avec --enableold qui bloque tout via climaintenance.html), et page 503 au niveau serveur web pour les grosses opérations. Le cron continue de tourner en maintenance : l’arrêter explicitement si l’opération touche la base.
• La messagerie route des types de messages vers des outputs (e-mail, popup web, push mobile Airnotifier) selon une matrice admin (forcé/défaut/désactivé) affinée par les préférences utilisateur ; l’e-mail sortant exige un SMTP propre, une adresse noreply maîtrisée et SPF/DKIM/DMARC pour la délivrabilité.
• Les logs : événements consommés par des logstores (Standard actif, Legacy déprécié, External DB pour l’analytique) ; mdl_logstore_standard_log devient la plus grosse table du site — fixer loglifetime dès le premier jour. Consultation via Rapports > Journaux (filtres cours/utilisateur/date/niveau éducatif) et Journaux en direct.
• Sécurité : HTTPS + cookies secure + HSTS, cronclionly activé, taille max d’upload maîtrisée, et surtout blocage des hôtes cURL internes (SSRF, métadonnées cloud). Le rapport Vérifications de sécurité audite tout cela automatiquement ; l’enregistrement du site apporte les alertes de sécurité, et les versions mineures se patchent sans délai.
• Environnement 5.2 : PHP 8.3+ (extension sodium, max_input_vars ≥ 5000), PostgreSQL 16 / MySQL 8.4 / MariaDB 10.11 / SQL Server 2019, upgrade depuis 4.4 minimum ; OPcache indispensable, caches MUC purgés via purge_caches.php ; supervision par les status checks (admin/cli/checks.php).
• Une routine d’exploitation quotidienne (cron, tâches en échec), hebdomadaire (Notifications, disque, file ad hoc) et mensuelle (patchs mineurs, sécurité, plugins, logs) transforme l’administration réactive en administration sereine.

Dans le prochain chapitre

Votre plateforme est configurée, sécurisée et exploitée proprement ; il est temps de revenir à la pédagogie outillée. Le chapitre 6 plonge dans l’évaluation et la reconnaissance des acquis : le carnet de notes (gradebook) — catégories, agrégations, pondérations, lettres et échelles, et la mécanique parfois déroutante des notes qui « remontent » des activités —, les badges (critères, délivrance automatique — vous savez désormais pourquoi le cron est leur meilleur ami — et Open Badges), et les compétences (competencies) avec référentiels et plans de formation. De quoi transformer des activités isolées en véritable parcours certifiant.