📍 Article principal : EdTech francophone open-source 2026
Introduction
Une école de formation professionnelle à Cotonou voulait digitaliser son offre de formation continue mais hésitait entre solution SaaS et auto-hébergement. Le SaaS demandait 200 dollars par mois, l’auto-hébergement supposait des compétences techniques absentes en interne. La solution adoptée : déploiement Moodle géré par un consultant externe sur Hetzner CX32 avec une formation initiale du responsable pédagogique pour l’administration courante. Coût total : 30 euros par mois infrastructure plus 200 euros mensuels pour l’accompagnement consultant les 3 premiers mois. Résultat après 6 mois : 240 apprenants actifs, 18 cours en catalogue, autonomie complète de l’équipe pédagogique sur la gestion quotidienne. Ce tutoriel détaille le déploiement complet de Moodle 4.5 sur Hetzner avec les choix d’architecture qui rendent l’opération durable et économique.
Prérequis
- Compte Hetzner Cloud avec moyen de paiement
- Domaine pour la plateforme (par exemple
cours.example.sn) - Connaissances de base SSH et Linux
- Email pour la configuration des notifications Moodle
- Niveau : intermédiaire — Temps : 3-4 heures
Étape 1 — Provisionner le VPS
Moodle est confortable sur un CX32 (4 vCPU, 8 Go RAM, 80 Go SSD) à 8,49 euros HT par mois. Cette configuration tient 200-500 apprenants actifs simultanés sans optimisation particulière. Pour des volumes plus importants, monter à CX42 (16 Go RAM) à 16 euros HT par mois. Localisation : Falkenstein (FSN1) ou Nuremberg (NBG1) — latence vers l’Afrique de l’Ouest comparable. Une fois le serveur provisionné, configurer le firewall Hetzner pour n’ouvrir que les ports 22, 80, 443.
Pour le système, choisir Debian 13 ou Ubuntu 24.04 LTS. Les deux fonctionnent parfaitement avec Docker et offrent un support de mises à jour de plusieurs années. Premier réflexe après connexion SSH : créer un utilisateur non-root et désactiver l’auth root. Voir notre tutoriel VPS SSH hardening 2026 pour les détails. Cette étape de hardening prend 30 minutes mais protège contre 95 % des attaques opportunistes.
Étape 2 — Installer Docker
Docker simplifie le déploiement de Moodle en encapsulant toutes les dépendances. Installation via le script officiel.
curl -fsSL https://get.docker.com | sh
usermod -aG docker votre_utilisateur
systemctl enable --now dockerVérifier avec docker --version qui doit retourner Docker 26 ou supérieur. Pour Docker Compose v2, généralement déjà inclus dans l’installation moderne. Tester avec docker compose version. Si absent, installer via apt install docker-compose-plugin.
Étape 3 — Déployer Moodle 4.5 avec Docker Compose
Pour Moodle, l’image Bitnami est la plus stable et maintenue. Elle inclut Apache, PHP, et toutes les configurations sensées par défaut. Créer le fichier docker-compose.yml dans /srv/moodle.
cd /srv/moodle
cat > docker-compose.yml <<'EOF'
services:
moodle:
image: bitnami/moodle:4.5
restart: unless-stopped
ports: ["127.0.0.1:8080:8080"]
environment:
MOODLE_DATABASE_HOST: mariadb
MOODLE_DATABASE_PORT_NUMBER: 3306
MOODLE_DATABASE_USER: moodle
MOODLE_DATABASE_NAME: moodle
MOODLE_DATABASE_PASSWORD: ${DB_PASSWORD}
MOODLE_USERNAME: admin
MOODLE_PASSWORD: ${ADMIN_PASSWORD}
MOODLE_EMAIL: admin@example.sn
MOODLE_SITE_NAME: École numérique
MOODLE_LANG: fr
MOODLE_HOST: cours.example.sn
MOODLE_REVERSEPROXY: 'yes'
volumes:
- moodle_data:/bitnami/moodle
- moodle_html:/bitnami/moodledata
depends_on: [mariadb]
mariadb:
image: bitnami/mariadb:10.11
restart: unless-stopped
environment:
MARIADB_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}
MARIADB_DATABASE: moodle
MARIADB_USER: moodle
MARIADB_PASSWORD: ${DB_PASSWORD}
volumes: [mariadb_data:/bitnami/mariadb]
volumes:
moodle_data: {}
moodle_html: {}
mariadb_data: {}
EOF
cat > .env <<EOF
DB_ROOT_PASSWORD=$(openssl rand -base64 32)
DB_PASSWORD=$(openssl rand -base64 32)
ADMIN_PASSWORD=$(openssl rand -base64 24)
EOF
docker compose up -dLe démarrage initial prend 5 à 10 minutes : téléchargement de l’image, initialisation de MariaDB, installation de Moodle, configuration des composants français. Suivre les logs avec docker compose logs -f moodle pour vérifier que tout se passe bien. Quand le message « Application started » apparaît, Moodle est prêt.
Étape 4 — Reverse proxy Caddy avec HTTPS
Caddy gère HTTPS automatiquement via Let’s Encrypt. Le DNS du domaine doit pointer vers l’IP du VPS avant cette étape (CNAME ou enregistrement A).
apt install -y caddy
cat > /etc/caddy/Caddyfile <<EOF
cours.example.sn {
reverse_proxy localhost:8080 {
header_up X-Forwarded-Proto https
}
encode gzip
header {
Strict-Transport-Security "max-age=31536000"
X-Content-Type-Options "nosniff"
}
log {
output file /var/log/caddy/cours.log
format json
}
}
EOF
systemctl reload caddyTester avec un navigateur : https://cours.example.sn doit afficher l’interface de connexion Moodle en français. Premier réflexe critique : se connecter avec admin et le mot de passe généré, puis changer ce mot de passe pour un mot de passe robuste mémorisable et le stocker dans un gestionnaire (1Password, Bitwarden).
Étape 5 — Configuration française complète
Bien que le pack français soit installé, plusieurs ajustements sont nécessaires pour une expérience locale optimale. Dans Administration du site → Localisation → Paramètres de localisation : régler le fuseau horaire sur Africa/Dakar ou Africa/Abidjan selon le pays. Dans Administration du site → Localisation → Paquetages de langues : vérifier que le français est bien le défaut, ajouter wolof ou bambara si pertinent (packs communautaires disponibles). Dans Administration du site → Apparence → Thème : choisir un thème francophone moderne ou personnaliser le thème par défaut avec les couleurs de l’école.
Pour les paramètres SMTP afin que Moodle envoie les emails (notifications, mots de passe oubliés), configurer dans Administration → Serveur → Email les credentials d’un service SMTP fiable : Brevo (ex-Sendinblue) avec son plan gratuit jusqu’à 300 emails par jour, ou Resend avec 3 000 emails gratuits par mois. Pour les structures qui veulent leur propre serveur SMTP, Postal ou Mailcow auto-hébergés sont des options mais demandent plus de maintenance.
Étape 6 — Sauvegardes automatisées
Les données apprenants sont irremplaçables. Configurer des sauvegardes nocturnes chiffrées vers Hetzner Object Storage avec rétention 30 jours. Voir notre tutoriel sauvegardes rclone pour le pattern complet. Pour Moodle spécifiquement, deux composants à sauvegarder : la base MariaDB et le dossier moodledata qui contient les fichiers uploadés (devoirs, ressources, certificats).
#!/usr/bin/env bash
DATE=$(date +%Y%m%d)
docker exec moodle-mariadb-1 mariadb-dump -uroot -p${DB_ROOT_PASSWORD} moodle \
| gzip \
| gpg --batch --passphrase-file /root/.backup-pass --symmetric \
| rclone rcat hetzner:moodle-backups/db-${DATE}.sql.gz.gpg
docker run --rm -v moodle_html:/data alpine tar czf - /data \
| gpg --batch --passphrase-file /root/.backup-pass --symmetric \
| rclone rcat hetzner:moodle-backups/files-${DATE}.tar.gz.gpg
# Rétention 30 jours
rclone delete --min-age 30d hetzner:moodle-backups/Cron quotidien à 3h GMT. Tester la restauration trimestriellement sur un VPS de test pour valider que la procédure fonctionne réellement. Sans ce test régulier, la sauvegarde ne donne qu’une fausse impression de sécurité.
Étape 7 — Optimisations performance
Pour des performances optimales, quatre optimisations standard. Premièrement, activer le cache Moodle (Redis ou Memcached) pour réduire les requêtes base de données répétées. Configuration via Administration → Serveur → Performance. Deuxièmement, activer la compression Caddy (déjà fait dans notre Caddyfile). Troisièmement, configurer le cron Moodle qui doit tourner toutes les minutes pour les notifications, certificats automatiques, indexation. Crontab : * * * * * docker exec moodle-moodle-1 php /opt/bitnami/moodle/admin/cli/cron.php > /dev/null. Quatrièmement, configurer l’opcache PHP qui accélère significativement le chargement des pages.
Pour les fichiers statiques (images, PDF de cours), envisager Cloudflare en frontal qui cache agressivement et sert depuis ses PoPs Lagos et Accra. Cette optimisation transforme l’expérience pour les apprenants ouest-africains : pages qui chargent en moins d’une seconde au lieu de 3-4 secondes sans cache.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| Moodle inaccessible après deploy | DNS non propagé | Attendre 30 min, vérifier avec dig |
| Erreur SSL handshake | Mode SSL Cloudflare incorrect | Passer en Full strict |
| Lenteur sur certaines pages | Cron Moodle non configuré | Crontab toutes les minutes |
| Emails non envoyés | SMTP mal configuré | Tester via Administration → Email tests |
| Plugin non installé | Manque permissions filesystem | Vérifier perms moodle_data |
| Backup MariaDB échoue | Mot de passe root introuvable | Récupérer depuis .env du déploiement |
Adaptation au contexte ouest-africain
Trois aspects pratiques. Premièrement, la latence depuis l’Afrique de l’Ouest vers Hetzner Falkenstein est typiquement 90-130 ms. Cloudflare en frontal réduit cela à 30-50 ms pour les ressources cachées. Pour les sessions live BBB, héberger BBB dans un datacenter avec PoP africain quand possible. Deuxièmement, le paiement Hetzner depuis l’Afrique se fait via Wave Visa, Wise, ou virement SEPA. Voir notre tutoriel Paiement Hetzner Afrique. Troisièmement, pour les structures publiques qui ont des exigences de localisation des données, Hetzner Allemagne convient pour les données non strictement nationales. Pour les structures qui doivent absolument héberger en Afrique, des fournisseurs locaux émergent (Africloud, Sénégal Numérique SA) à des tarifs plus élevés mais conformes.
Pour le coût total de fonctionnement d’une plateforme Moodle pour 200-500 apprenants, le total mensuel inclut : VPS Hetzner CX32 à 8 euros, sauvegardes Object Storage à 5 euros, SMTP Brevo gratuit, monitoring Better Stack à 25 dollars (optionnel). Total typique 15-50 euros par mois selon options — bien inférieur aux 200-500 euros d’une solution SaaS équivalente.
Tutoriels frères
Pour aller plus loin
- 🔝 Pilier : EdTech francophone 2026
- Articles : Hetzner Cloud Afrique
- Doc : Moodle Installation Guide
FAQ
Combien d’apprenants un CX32 supporte-t-il ?
Confortablement 200-500 apprenants actifs simultanés. Au-delà, monter à CX42 ou optimiser cache.
Faut-il un développeur PHP pour personnaliser Moodle ?
Pour la configuration standard non. Pour des plugins custom oui. La majorité des besoins se couvrent via plugins existants ou configuration sans code.
Comment migrer depuis une autre plateforme LMS ?
Moodle accepte des imports depuis SCORM, IMS, et formats spécifiques (Open edX, Chamilo). Pour des plateformes propriétaires, export CSV des utilisateurs et recréation manuelle des cours.
Quelle stratégie de mise à jour Moodle ?
Suivre les mises à jour mineures mensuelles (corrections sécurité). Migrations majeures (4.5 vers 5.0) tous les 12-24 mois en environnement de staging d’abord.
Sécurité applicative Moodle
Au-delà du hardening serveur, Moodle propose plusieurs mécanismes de sécurité applicative à activer dès le déploiement. Premièrement, la 2FA via le plugin Authenticator officiel : tous les comptes administrateurs et formateurs doivent l’activer. Deuxièmement, la politique de mots de passe robuste : minimum 12 caractères, mélange de casse, chiffre, symbole. Configuration dans Administration → Politique de site. Troisièmement, le verrouillage temporaire après échec de connexion : 5 tentatives en 5 minutes provoque un blocage de 10 minutes — protection contre brute force. Quatrièmement, l’audit log des actions sensibles via le plugin Logstore Database : chaque modification de cours, suppression de devoir, accès à donnée sensible est tracé.
Pour les structures qui visent une certification (ISO 27001, conformité RGPD), Moodle fournit aussi des fonctionnalités spécifiques : consentement explicite des apprenants, droit à l’effacement, export des données personnelles. Ces fonctionnalités, longtemps optionnelles, deviennent progressivement obligatoires pour les plateformes opérant en Afrique de l’Ouest avec la maturation des cadres réglementaires de protection des données.
Évolution de la stack avec la croissance
Une plateforme Moodle évolue avec son volume. Aux premiers stades (sous 200 apprenants), l’installation single-server sur CX32 tient parfaitement. À 500-1 000 apprenants, ajouter Redis pour le cache et un serveur dédié pour BigBlueButton si beaucoup de sessions live. À 2 000-5 000 apprenants, séparer la base de données sur un serveur dédié avec read replica pour les rapports. Au-delà, architecture multi-serveurs avec load balancer et stockage partagé. Pour la majorité des écoles ouest-africaines qui démarrent, ces optimisations restent prématurées et l’architecture simple convient les premières années.
Cette évolutivité progressive évite l’erreur classique de sur-architecturer dès le départ. Construire une infrastructure Kubernetes pour 50 apprenants, c’est gaspiller du temps et de l’argent. Démarrer simple avec une roadmap d’évolution préparée mentalement permet d’adapter quand les besoins réels apparaissent. Cette discipline pragmatique distingue les déploiements EdTech qui réussissent de ceux qui s’enferment dans la complexité.
Trois cas réels observés en 2025-2026
Pour situer la mise en œuvre concrète, voici trois projets observés cette année. Premier cas : un institut de formation comptable à Lomé qui sert 350 apprenants en formation continue. Stack Moodle CX32 sur Hetzner avec Cloudflare frontal, sauvegardes Object Storage. Coût total infrastructure 22 euros mensuels, maintenance par consultant local 1 jour par mois. Trois ans d’opération sans incident majeur, taux de complétion des formations supérieur à 80 %. Deuxième cas : une école de langues à Cotonou qui propose des cours de wolof et de bambara aux Africains de la diaspora. Modèle freemium avec contenu de base gratuit et certification payante. 1 200 apprenants actifs, monétisation via Wave et carte bancaire internationale. Troisième cas : un programme de formation gouvernemental au Burkina Faso pour les agents publics, déployé sur Moodle hébergé localement avec partenariats internationaux pour les contenus pédagogiques. Volume 5 000 agents formés en 18 mois, modèle entièrement subventionné par les bailleurs.
Ces trois cas illustrent la diversité des modèles que la même base technique peut servir.