Chapitre 11.7 — Maintenance et mises à jour d’une instance

Partie 11 : Niveau expert — Chapitre 7/8 Public : dev/ops responsable d’une instance Moodle dans la durée. Version de référence : Moodle 5.2 (PHP 8.3+, racine web public/).

⏱️ TL;DR

• Cycle de release (rappel ch. 1.5) : une version tous les 6 mois, des correctifs (.1, .2) ~toutes les 4 semaines, des LTS ~tous les deux ans. Stratégie : suivre les correctifs de sa branche (obligatoire), planifier les majeures.
• Chemin d’upgrade : on ne saute pas les paliers arbitrairement. Vérifier les versions intermédiaires requises et les environment checks (PHP, BDD) avant de monter vers 5.2.
• Procédure scriptée : sauvegarde (base + moodledata + code) → mode maintenance → bascule du code (git, branche stable) → php admin/cli/upgrade.php → purge des caches → tests de fumée → maintenance OFF.
• Plugins tiers : le point de casse n°1 d’un upgrade. Auditer leur compatibilité avant, les mettre à jour ou les retirer.
• Jamais de fork ni de patch du core : chaque upgrade l’écraserait. Tout se fait en plugins.
• Monitoring durable : cron qui tourne, tâches en échec, logs, et données qui grossissent (logs, fichiers orphelins, trashdir) à purger.

🎯 Objectifs

• Définir une stratégie de mise à jour (correctifs vs majeures, LTS).
• Établir le chemin d’upgrade vers 5.2 (paliers, environment checks).
• Exécuter une procédure d’upgrade scriptée et sûre.
• Gérer les plugins tiers et éviter les forks du core.
• Maintenir une prod : monitoring, backups, données qui grossissent.

1. Stratégie de mise à jour

Rappel du chapitre 1.5 : Moodle sort deux versions/an (avril, octobre), des correctifs ~toutes les 4 semaines, et des LTS environ tous les deux ans. Deux rythmes distincts à ne pas confondre :

• Suivre les correctifs de sa branche (5.2.1, 5.2.2…) : obligatoire et léger (pas de changement d’API). Ce sont surtout des patchs de sécurité. À faire régulièrement, quasi automatiquement.
• Passer à la majeure suivante (5.2 → 5.3) : planifié et plus lourd (changements d’API possibles, plugins à vérifier). À décider selon la fin de support de la version actuelle, les besoins fonctionnels et la compatibilité des plugins.

⚠️ Piège : figer une instance sur une version pour « éviter les mises à jour ». La dette explose à l’upgrade forcé (fin de vie/faille) : plusieurs majeures à franchir d’un coup, tous les plugins à réparer en même temps. Le bon rythme : suivre les correctifs, planifier les majeures avant la fin de support.

2. Le chemin d’upgrade vers 5.2

On ne monte pas d’une version très ancienne à la 5.2 d’un seul bond. Il faut :

• Vérifier les paliers requis : Moodle impose parfois de passer par une version intermédiaire (l’upgrade de schéma d’une très vieille version vers la cible n’est pas testé directement). La page de release de moodledev.io indique le chemin d’upgrade supporté.
• Passer les environment checks : la 5.2 exige PHP 8.3+ et des bases récentes (PostgreSQL 16, MySQL 8.4, MariaDB 10.11+, ch. 1.5). L’upgrade refuse de démarrer si l’environnement ne remplit pas les prérequis. Mettez à niveau PHP/BDD d’abord.
• Auditer la racine public/ (nouveauté 5.1) : le document root web doit pointer sur public/. Une montée depuis une version pré-5.1 implique de reconfigurer le serveur web.

⚠️ Piège : lancer l’upgrade sans avoir vérifié le chemin de paliers ni les prérequis. Résultat : un upgrade qui échoue à mi-course (schéma incohérent) ou qui refuse de démarrer. Lisez d’abord les upgrade notes de la version cible et les environment checks de l’interface (Administration → Serveur → Environnement).

3. La procédure scriptée

C’est la procédure du chapitre 6.7, appliquée à l’instance entière (core + plugins). Ne déviez pas : un upgrade raté sur une prod d’étudiants est un incident majeur.

# 0. SAUVEGARDER — non négociable. Base + moodledata + code.
pg_dump moodle > /backups/moodle-$(date +%F).sql       # (date à passer par la CI, pas dans le script versionné)
tar czf /backups/moodledata-$(date +%F).tgz /var/moodledata
git -C /var/www/moodle rev-parse HEAD > /backups/code-version.txt
 
# 1. Mode maintenance (les utilisateurs voient une page d'attente)
php admin/cli/maintenance.php --enable
 
# 2. Vérifier l'environnement AVANT de basculer le code
php admin/cli/checkupgrade.php   # (ou la page Environnement)
 
# 3. Basculer le code vers la branche stable cible
git -C /var/www/moodle fetch
git -C /var/www/moodle checkout MOODLE_502_STABLE
git -C /var/www/moodle pull
#    + mettre à jour chaque plugin tiers vers sa version compatible 5.2 (§4)
 
# 4. Jouer les mises à niveau de schéma (core + plugins)
php admin/cli/upgrade.php --non-interactive
 
# 5. Purger les caches
php admin/cli/purge_caches.php
 
# 6. Tests de fumée (login, page de cours, une activité, le carnet de notes…)
 
# 7. Sortir du mode maintenance
php admin/cli/maintenance.php --disable

Les principes (déjà vus, ici à l’échelle instance) :

• Sauvegarder d’abord : base et moodledata et la référence du code. Sans point de restauration, un upgrade raté est irréversible.
• Mode maintenance pendant la migration de schéma : sinon les écritures utilisateur sur un schéma en cours de modification créent des incohérences.
• CLI, pas l’interface web : fiable, scriptable, sans timeout de navigateur.
• Tests de fumée avant de rouvrir : login, cours, activité, notes, dans le thème et les modes utilisés.

⚠️ Piège : rouvrir le site (maintenance OFF) avant d’avoir fait les tests de fumée. Un upgrade peut « réussir » techniquement mais casser un plugin critique. Testez avant de rendre la main aux utilisateurs. Et préproduction d’abord (ch. 11.4) : jamais un premier essai directement en prod.

4. Les plugins tiers : le point de casse n°1

À chaque majeure, les plugins tiers sont ce qui casse le plus (ch. 8.4 pour les thèmes, ch. 6.7 pour la compatibilité). Avant l’upgrade :

1. Lister tous les plugins tiers installés (Administration → Plugins → Vue d’ensemble).
2. Vérifier leur compatibilité 5.2 sur le plugin directory (ch. 1.4) ou leur dépôt.
3. Pour chacun : mettre à jour vers la version compatible, ou retirer si abandonné/incompatible.
4. Tester en préproduction avec les plugins à jour avant la prod.

Un plugin incompatible peut faire échouer l’upgrade (erreur de schéma) ou casser des fonctionnalités en silence. Moodle signale les plugins « manquants » ou « incompatibles » pendant l’upgrade.

⚠️ Piège : découvrir en pleine prod qu’un plugin critique n’a pas de version 5.2. Auditez en amont : si un plugin indispensable n’est pas compatible, l’upgrade attend (ou vous cherchez une alternative). Ne lancez pas la majeure en espérant que « ça passera ».

5. Jamais de fork ni de patch du core

Rappel absolu (ch. 6.1) : ne modifiez jamais le code du core (« core hack »), et ne maintenez pas un fork. Pourquoi c’est fatal en maintenance :

• Chaque git pull / upgrade écrase vos modifications core → elles disparaissent ou provoquent des conflits.
• Un fork vous coupe des correctifs de sécurité et des upgrades officiels : vous devez rejouer chaque patch amont à la main, indéfiniment.

Tout besoin est réalisable en plugin (Parties 6–8) ou, en dernier recours, par une contribution au core (proposée en amont, ch. 1.4) — jamais par une modification locale non tracée. Si vous vous surprenez à vouloir hacker le core, reformulez le besoin : c’est presque toujours un signe qu’un thème, un plugin ou un hook fait l’affaire.

6. Backups et restaurations d’instance

• Trois éléments à sauvegarder, toujours ensemble : la base de données, le dossier moodledata (fichiers uploadés), et le code (ou sa référence git + la liste des plugins). Une sauvegarde de la base seule est inutile sans moodledata.
• Cohérence : idéalement en mode maintenance ou via des snapshots cohérents (LVM, snapshot cloud), pour éviter une base et un moodledata désynchronisés.
• Tester la restauration : une sauvegarde jamais restaurée est une hypothèse, pas une garantie. Faites des restaurations d’essai périodiques sur une instance de test.
• Ne pas confondre avec la sauvegarde de cours (.mbz, Partie 6) : celle-ci sauvegarde un cours (contenu + éventuellement données utilisateur), pas l’instance. Les deux sont complémentaires.

7. Monitoring d’une production dans la durée

Rappel du chapitre 11.2, côté exploitation :

• Cron : l’incident silencieux n°1. Moodle alerte si le cron n’a pas tourné récemment (Serveur → Tâches). Un cron arrêté = notifications, notation différée, nettoyages stoppés. Alerte en priorité dessus.
• Tâches en échec : surveiller les scheduled_task/adhoc_task en erreur.
• Logs : erreurs PHP, requêtes lentes (ch. 11.2), événements de sécurité (ch. 11.1).
• Sécurité : suivre les annonces de sécurité Moodle et appliquer les correctifs de sa branche rapidement.

8. Les données qui grossissent

Une instance vieillit et accumule. À surveiller et purger (via tâches ou CLI) :

• Logs : la table des logs peut devenir énorme. Moodle a une politique de rétention des logs (durée de conservation) — configurez-la (Rapports → Logs).
• Fichiers orphelins et trashdir : moodledata/trashdir accumule les fichiers supprimés en attente de nettoyage ; une tâche cron les purge (vérifier qu’elle tourne).
• Sauvegardes automatiques de cours : si activées, elles s’accumulent dans moodledata — surveiller l’espace disque.
• Sessions, caches expirés, brouillons : nettoyés par des tâches planifiées ; s’assurer qu’elles s’exécutent.

⚠️ Piège : un moodledata qui remplit le disque (logs + trashdir + backups auto non purgés) met le site hors service (plus d’écriture possible). Surveillez l’espace disque comme métrique critique, configurez la rétention des logs, et vérifiez que les tâches de nettoyage tournent (donc que le cron tourne).

9. Synthèse

Maintenir une instance = suivre les correctifs (léger, obligatoire) et planifier les majeures (lourd) avant la fin de support ; établir le chemin d’upgrade (paliers + environment checks PHP/BDD + racine public/) ; exécuter une procédure scriptée (backup base+moodledata+code → maintenance → bascule git → upgrade.php → purge → tests de fumée), préproduction d’abord ; auditer les plugins tiers (le point de casse n°1) ; jamais de fork/patch du core ; et monitorer durablement (cron, logs, sécurité) en maîtrisant les données qui grossissent. Une instance bien tenue est le fruit d’une discipline, pas d’un one-shot. Reste, pour boucler la partie, à publier vos plugins à la communauté.

✏️ Exercices

Exercice 1 — Deux rythmes. Distinguez la mise à jour 5.2.3 → 5.2.4 de 5.2 → 5.3 : lourdeur, fréquence, ce qu’on vérifie.

Exercice 2 — Upgrade qui refuse de démarrer. Vous lancez l’upgrade vers 5.2 et il s’arrête sur une erreur d’environnement. Cause probable et démarche ?

Exercice 3 — Ordre de la procédure. Remettez dans l’ordre : purge des caches ; upgrade.php ; maintenance ON ; sauvegarde (base+moodledata+code) ; bascule du code git ; tests de fumée ; maintenance OFF.

Exercice 4 — Plugin incompatible. Un plugin critique n’a pas de version 5.2 annoncée à trois semaines de l’upgrade prévu. Que faites-vous ?

Exercice 5 — Disque plein. La prod devient inaccessible : moodledata a rempli le disque. Causes probables et prévention ?

🧠 Quiz de révision

Q1. Quelle est la stratégie de mise à jour recommandée ?

Q2. Que vérifier avant de monter une vieille instance vers 5.2 ?

Q3. Quels trois éléments sauvegarder, et pourquoi ensemble ?

Q4. Pourquoi ne jamais forker ni patcher le core ?

Q5. Quels sont les principaux postes de « données qui grossissent » et comment les maîtriser ?

Chapitre suivant : 08 — Publier son plugin sur moodle.org — le plugin directory de bout en bout : prérequis stricts (GPL, privacy provider, standards moodle-cs, CI), le processus de review réel (délais, allers-retours), la fiche plugin, la gestion des versions publiées, la maintenance d’un plugin communautaire (issues, traductions AMOS), et les modèles de monétisation réalistes en écosystème GPL.