Terrain 10 — Administration du site

Administration du site (Utilisateurs, Cours, Notes, Plugins, Apparence, Serveur, Sécurité…) est l’arbre complet de config. Une recherche en haut permet de trouver un réglage par mot-clé — le réflexe quand on ne sait plus où il est.

La page Notifications affiche version, mises à jour disponibles, problèmes détectés, et déclenche les mises à jour de base après ajout d’un plugin. Premier écran à consulter après tout changement structurel.

Cours → Gérer les cours et catégories : arborescence à plusieurs niveaux (ex. Département → Filière). Les catégories sont des contextes (héritage de rôles, terrain 11). Bien les penser structure toute la plateforme.

Administration → Langue → Packs de langue : installe/mets à jour les traductions. « Langue par défaut » fixe la langue du site. Moodle est nativement multilingue (filtre multilang possible).

Apparence → Sélecteur de thèmes : le thème par défaut est Boost. On peut en installer d’autres (ou en développer, terrain 14). Le thème peut varier par appareil/catégorie/cours selon la config.

Les réglages du thème (logo, couleur, SCSS custom, pied de page) personnalisent l’identité sans coder. Boost expose une couleur primaire et un champ SCSS brut pour aller plus loin. Base du branding.

On installe depuis le Moodle plugins directory (recherche intégrée) ou par zip. Après copie des fichiers, Moodle détecte le nouveau plugin et lance la mise à jour de base (jeu 2). Toujours sur test d’abord.

Installer des plugins → Téléverser un ZIP : pour un plugin non listé ou ton plugin (terrains 13–15). ⚠️ N’installe que des sources fiables (du code s’exécute). Vérifie la compatibilité de version.

Administration → Plugins → Vue d’ensemble liste tous les plugins par type, avec version, activation, réglages, désinstallation. On y désactive/désinstalle proprement. Un plugin non maintenu = risque (sécurité/compat).

Moodle supporte plusieurs auth : manuelle, e-mail auto-inscription, LDAP, OAuth2 (Google/Microsoft), CAS/SSO, Shibboleth… Chacune est un plugin. On combine (ex. SSO pour le personnel + manuel). Cœur de l’intégration en entreprise.

L’auth par e-mail laisse les visiteurs créer un compte (confirmation par mail). À activer seulement si le site est public et souhaite des inscriptions ouvertes. Sinon (site fermé), on la laisse désactivée. Décision de sécurité.

Le plugin Politiques (Tool Policy) gère politiques de site + consentement obligatoire + versions. Couplé au Privacy API (export/suppression de données, terrain 16), c’est la base de la conformité RGPD de Moodle.

Administration → Utilisateurs → Champs de profil : ajoute des champs (texte, menu, case…) à tous les comptes. Utilisables pour l’affichage, l’import CSV et les restrictions par champ (terrain 08, jeu 11). Personnalise les données utilisateur.

Notes → Réglages généraux définit les défauts du carnet pour tous les cours (agrégation par défaut, affichage, décimales). Cadrer ces défauts évite que chaque enseignant réinvente. Cohérence à l’échelle de l’établissement.

Administration → Fonctionnalités avancées → Activer le suivi d’achèvement (et badges, résultats, etc.). Certaines fonctions de cours (terrain 08) ne sont dispo que si l’admin les active globalement. À vérifier si une option manque à l’enseignant.

Administration → Page d’accueil : ce que voient visiteurs et connectés (liste/recherche de cours, sections, blocs). C’est la vitrine publique (distincte du Tableau de bord personnel, terrain 01). Personnalisable avec blocs et contenu.

Administration → Apparence → Tableaux de bord par défaut : l’admin définit (et peut verrouiller) la disposition initiale des blocs pour tous. Garantit une expérience homogène aux nouveaux utilisateurs.

Administration → Messagerie : active les canaux (web, e-mail, mobile) et leurs défauts. La configuration e-mail (SMTP) du serveur est ici cruciale : sans elle, aucun mail ne part (problème n°1 en local, terrain 12).

Moodle exécute des tâches planifiées (cron) : nettoyage, envois, calculs, sauvegardes. Elles supposent un cron système qui appelle admin/cli/cron.php régulièrement. Tes plugins pourront en déclarer (terrain 15). Sans cron, beaucoup de choses « ne se passent pas ».

Moodle cache énormément (langue, définitions de plugins, thèmes). Purger les caches après un changement de code/langue/thème est LE réflexe de dev (terrain 12). Sinon, tu débogues une version périmée.

Les journaux (logs) tracent chaque action (vue, remise, connexion). Filtrable, exportable. Base de l’analytique, du support (« que s’est-il passé ? ») et de l’audit de sécurité. Alimentés par le Events API (terrain 15).

Les live logs affichent les événements en quasi temps réel — utile pour vérifier qu’une action déclenche bien un event (débogage de plugin, terrain 15) ou surveiller un pic d’activité.

Cours → Sauvegardes → Sauvegarde automatisée : planifie des sauvegardes régulières de tous les cours (via une tâche planifiée). Filet de sécurité à l’échelle du site. Complète les sauvegardes serveur (base + moodledata).

Administration → Serveur → Mode maintenance ferme le site aux utilisateurs (message custom) pendant une mise à jour/migration. En CLI : admin/cli/maintenance.php. À activer avant toute opération risquée en prod.

Environnement vérifie versions PHP/BDD, extensions requises, réglages — vert/rouge. À consulter avant une mise à jour majeure de Moodle (prérequis). Équivalent du « Santé du site » de WordPress.

phpinfo() intégré : versions, limites (mémoire, upload), extensions. Précieux pour diagnostiquer un upload qui échoue (taille max), une extension manquante, etc. Réflexe de dev/admin.

Politiques : force des mots de passe, protection des identités, ouverture des profils, en-têtes de sécurité, anti-bot à l’inscription (reCAPTCHA). Cadre la sécurité globale. À revoir dès la mise en ligne (terrain 16 pour le code).

Moodle offre des rapports (activité, participation) et, via Analytics, des modèles prédictifs (risque de décrochage). Data au service de la réussite. Certains nécessitent activation + cron.

config.php (racine) contient identifiants BDD, $CFG->wwwroot, $CFG->dataroot (→ moodledata, le stockage de fichiers hors web). Moodle = base + dossier moodledata + code. On l’édite vraiment au terrain 12. Ne jamais l’exposer publiquement.

Tu administres Moodle de bout en bout. Le dernier maillon de gouvernance : le système rôles & permissions en profondeur (terrain 11), socle de la sécurité — y compris celle de tes futurs plugins.