Pour le responsable formation ou le directeur IT d'école qui a dépassé la maintenance de Moodle, Rizon construit le produit d'apprentissage dont vous avez vraiment besoin et vous en transfère la propriété.
Si vous quittez Moodle, trois voies existent vraiment : continuer à le maintenir, passer à un LMS hébergé ou construire une plateforme autour de votre propre méthode d'enseignement. La troisième a du sens lorsque les contournements font désormais partie du travail.
J'ai déjà vu le moment où cela bascule : une équipe pédagogique demande un rapport précis, un ingénieur cherche lequel des 14 plugins le gère, et personne ne sait ce que la prochaine mise à jour changera. Moodle est capable. Il faut aussi l'exploiter.
Pour qui c'est fait : Cette page s'adresse à Samira, responsable des opérations, qui a besoin d'un produit d'apprentissage à l'image de son organisation plutôt que d'une installation assemblée au fil des ans.
.mbz backups
Source: Moodle Docs
Un Moodle auto-hébergé demande de l'hébergement, des mises à jour, des sauvegardes et quelqu'un qui connaît l'installation. C'est raisonnable pour un établissement qui possède cette compétence. C'est lourd pour une petite équipe de formation qui veut surtout publier et améliorer ses cours.
Le répertoire de plugins Moodle est utile. Chaque plugin ajouté pose tout de même une question de version, de compatibilité et de responsabilité. La documentation Moodle recommande de choisir les plugins pour la version exacte utilisée et de tester les mises à jour hors production.
Les thèmes et la configuration changent beaucoup, mais l'expérience de cours part toujours du modèle de données Moodle. Dès que votre produit a besoin d'un autre parcours d'inscription, de cohorte, de paiement ou de progression, cette structure apparaît.
Le code Moodle est open source. L'hébergement, le temps technique, la supervision, le développement sur mesure et le support ne le sont pas. Une comparaison réaliste inclut ces coûts, pas seulement la ligne de licence.
| Dimension | Rizon (sur mesure) | Moodle |
|---|---|---|
| Propriété du code | Vous recevez le code de l'application et le transfert du déploiement. | Code open source ; votre équipe contrôle l'installation qu'elle exploite. |
| Hébergement et maintenance | Un plan d'hébergement et de support convenu, avec un accès direct à la stack. | Auto-hébergé ou hébergé par un prestataire Moodle ; la maintenance fait toujours partie du modèle. |
| Expérience apprenant | Conçue autour de vos cours, de vos apprenants et de votre marque. | Utilise l'interface établie du produit et ses options de configuration. |
| Niveau de personnalisation | Les fonctionnalités sont cadrées et développées pour votre mode de travail. | Limitée par les réglages du produit, les extensions ou la roadmap de l'éditeur. |
| Intégrations | Connectez les systèmes que vous utilisez déjà, y compris le SSO, les paiements et LTI lorsque nécessaire. | Les intégrations disponibles dépendent du forfait, de la marketplace et du support du produit. |
| Modèle de support | Travaillez directement avec l'équipe qui réalise le produit. | Communauté, partenaires certifiés ou votre équipe interne. |
| Modèle de coût | Un développement cadré, puis l'hébergement et le support que vous choisissez. | Pas de licence logicielle en auto-hébergement ; l'hébergement, le support et le développement ont tout de même un coût. |
| Risque de mise à jour | Les changements sont planifiés selon votre code et votre processus de livraison. | Les mises à jour du cœur et des plugins demandent des contrôles de compatibilité et des tests. |
Une université disposant d'administrateurs Moodle expérimentés et d'un processus de mise à jour rigoureux peut tirer beaucoup d'un logiciel qu'elle héberge elle-même.
Moodle possède une grande communauté de plugins et une longue histoire dans l'enseignement formel. Reconstruire une installation très utilisée et riche en standards par goût de la nouveauté serait un gaspillage.
Si vos besoins correspondent au produit de base et à un ensemble connu de plugins, commencer ainsi est généralement plus rapide que commander une plateforme sur mesure.
Nous commençons par recenser les cours, fichiers, utilisateurs, inscriptions, plugins et intégrations. Ensuite, nous testons les exports, déplaçons un cours représentatif et décidons quels historiques conserver. Les paquets SCORM et les intégrations LTI ont leurs propres contrôles d'acceptation ; rien ne suppose qu'une simple copie les préservera.
Au départ, oui. Le code de Moodle est gratuit, pas un développement. La comparaison honnête part de ce que Moodle vous coûte déjà : l'hébergement, une personne qui connaît l'installation, l'entretien des plugins et cette mise à jour que vous repoussez car vous ignorez ce qu'elle va casser. Chiffrez cela. Une plateforme qui vous appartient peut alors devenir plus intéressante sur quelques années.
Souvent, une bonne partie. Les contenus de cours, fichiers, utilisateurs et inscriptions s'exportent généralement proprement. Les paquets SCORM, l'historique des notes et les données gérées par un plugin demandent chacun leur propre mapping et une importation test avant toute promesse.
Si vous les utilisez réellement, oui. Je fixe les versions exactes dont vous dépendez et je reconstruis volontairement ces lancements, au lieu de supposer que chaque comportement historique doit suivre.
Une première version concentrée prend généralement de 8 à 12 semaines. Une grande bibliothèque de cours, du reporting sur mesure ou plusieurs intégrations allongent ce délai. Vous voyez un logiciel fonctionnel chaque semaine, sans attendre des mois une grande révélation.
C'est votre choix. Je peux exploiter et maintenir l'hébergement, ou vous remettre une infrastructure documentée pour que votre équipe ou votre prestataire s'en charge. Vous ne dépendez pas de moi pour garder le service en ligne.
Amenez les parties de votre configuration actuelle qui vous font mal. Nous vous dirons ce qui mérite d'être reconstruit, ce qui doit rester, et où un logiciel sur mesure serait du gaspillage.
Réserver un appel de 30 minutes