Un MOOC à base de technologies issues du GTLL

Ce billet relate l'expérience d'un MOOC ERP5 et des outils qui ont été mise en place pour parvenir à enseigner les ERP à 1500 étudiants. On y montre l'importance et les coûts de la création des contenus ainsi que de la correction des copies. On y montre également les possibilités d'automatisation partielle du travail de l'enseignant.
  • Last Update:2013-08-09
  • Version:001
  • Language:fr

TU Dresden, Supinfo et Nexedi ont lancé début 2013 un MOOC (Massive Open Online Course - Cours en ligne ouvert et massif) pour former plus 1500 étudiants aux ERPs, ainsi que toute personne qui souhaite s'y inscrire. Ce MOOC est d'abord le résultat de bonnes relations avec des enseignants et ensuite le résultat d'un investissement technologique significatif. Une partie de cet investissement a d'ailleurs été financé par le groupe de travail logiciel libre (GTLL) du pôlede compétitivité Systematic et par un projet Eurostars. Nexedi publie ce billet car plusieurs personnes autour de nous ont indiqué que cette expérience leur avait été utile.

Tous les renseignements sur ce MOOC sont disponibles dans un communiqué de presse publié sur le site OSOE: http://www.osoe-project.org/news-ERP5.MOOC

Historique

A l'origine, ce MOOC est né comme cours donné à Télécom Lille 1. Sabine Leroy avait eu l'heureuse idée de nous inviter à former ses étudiants aux ERP, avec une partie théorique de gestion et une partie pratique sur le logiciel ERP5. Ce cours a été renommé "One Student One ERP" (OSOE). Il a été donné dans d'autres universités et évolué  au fil des années. Une partie programmation en ligne qui a été intégrée, notamment avec un TP de 3 x 8 heures sur le thème "comment développer un équivalent libre de Salesforce" conçu pour démystifier la complexité du SaaS ou du Cloud. La liste des sessions et des dates est disponible sur le site OSOE à l'URL:  http://www.osoe-project.org/meeting. Cette liste de dates permet de comprendre le processus de maturation d'un contenu pédagogique sur plusieurs années. 

Les problèmes à résoudre, les solutions

Plusieurs problèmes techniques ont été résolus peu à peu avant de pouvoir donner un cours à 1500 étudiants et d'en assurer la correction des copies.

  • Problème 1: fournir un ERP configuré à chaque étudiant
  • Problème 2: fournir aux étudiants un moyen de développer sur un réseau où tout est bloqué
  • Problème 3: fournir aux étudiants un support de cours qui est synchronisée avec la version du logiciel utilisée
  • Problème 4: former les professeurs dans un mode "formateur de formateur"
  • Problème 5: accélérer le temps de correction l'examen final (qui est un mini-projet de configuration d'un ERP pour une PME)

Le problème 1 a été résolu avec SlapOS (ou son ancêtre TiolIve). L'idée de SlapOS est venue de Chistophe Cérin, professeur à Paris 13 et spécialiste du grid computing. SlapOS a permis à ce jour de fournir plusieurs dizaines de milliers d'instances d'ERP5, configurées automatiquement. On pourrait de la même façon utiliser SlapOS pour fournir un environnement configuré pour n'importe quel autre logiciel à enseigner (une sorte d'appstore éducatif). A ce jour, une centaine d'applications ont déjà été portées.

Le problème 2 a été résolu en utilisant l'IDE "SlapOS Webrunner" qui combine un client Cloud9 (une sorte d'Eclipse en Javascript) avec un système de build permettant d'enseigner n'importe quelle technologie (C, C++, MariaDB, PGSQL, Couchbase, Node, etc.). In fine, chaque étudiant dispose d'un environnement de développement adapté à chaque cours de programmation, sans rien avoir à installer sur son PC sous Windows, dont les droits d'administration ont été bloqués par son université comme cela arrive de plus en plus souvent.

Le problème 3 a été résolu avec un petit développement logiciel appelé "RunMyDocs" qui permet de rédiger une documentation en HTML5/SVG, de produire automatiquement une présentation ou un PDF à partir du source HTML5 et surtout qui permet d'embarquer dans le document des instructions de test. Regardez par exmeple le code HTML5 de la page suivante:

vous noterez le terme "openAndWait". Ce code permet de tester que la documentation peut être "exécutée" sur la dernière version du logiciel ERP5. A chaque nouvelle version, on lance "RunMyDcos" pour vérifier que le cours fonctionne toujours et pour mettre à jour les recopies d'écran. Le même document peut d'ailleurs etre utilisé en cours magistral ou en webconférence:

La résolution du problème 3 - un problème d'assurance qualité des supports d'enseignement - est une des clés qui a permis de passer de la formation de quelques dizaines d'étudiants à quelques milliers.

Le problème 4 a été traité avec un forum. Rien de plus.

Le problème 5 a été traité avec une combinaison assez sophistiquée d'outils et de technologies.

Nous avons utilisé d'abord un moteur de formulaire avec des arbres de décision et des workflows. Ensuite, nous avons constitué une base d'exemples sur plus de 200 PME. Nous avons alors utilisé deux technologies de "machine learning", l'une issue de Télécom Bretagne, l'autre de Rapid-I (leader européen) pour automatiser les corrections des étudiants à partir de la base d'exemples. L'idée est simple: corriger de la même façon les nouveaux étudiants que les anciens, à partir d'exemples de bonnes ou de mauvaises copies.


L'interface de correction automatique.

Le fait de devoir enseigner les ERP à 1500 étudiants et non plus à des groupes de 10 ou 15, a totalement modifié notre approche de l'enseignement, en y introduisant une forme de productivisme ou d'industrialisation qui n'existait pas initialement. Il est d'ailleurs intéressant de constater que c'est dans le cadre de Supinfo - et non de l'université ou d'écoles d'ingénieur - que nous avons eu cette incitation à imaginer comment diviser par 10 ou 100 le coût d'un enseignement. Les promotions d'université ou d'écoles d'ingénieur sont souvent trop fragmentées pour que l'on parvienne à industrialiser un cours au sens MOOC (> 1,000 voire > 10,000).

Concernant l'examen de notre MOOC, nous demandons à un élève d'effectuer une sorte de mini-cahier des charges pour un ERP, avec des questions telles que "quels sont les interlocuteurs principaux de l'entreprise" ou encore "décrivez un processus de gestion que l'entreprise considère avoir bien mis en oeuvre". Il faut alors distinguer les réponses bateau (ex. "améliorer la communication dans l'entreprise dans le cadre d'une stratégie internationale") avec les réponses précises (ex. "réduire de 10% les invendus de fin de saison sur la ligne de produit enfant").

Il faut plusieurs mois pour former un professeur pour corriger ce type d'examen. Corriger à la main une copie prend environ une heure. Or, nous devons corriger toutes les copies en quelques semaines, avec un budget proche de zéro. Nous avons donc opté pour la voie de l'intelligence artificielle avec un système de correction à plusieurs niveaux, qui permet de réduire de une heure à quelques minutes le temps passé par un humain pour corriger une copie, grâce à un outil d'aide à la correction. Il a fallu près de deux ans de R&D pour parvenir à ce résultat. Nous espérons l'améliorer pour ensuite enseigner à 10,000 voire 100,000 étudiants.

Notons enfin que nous ne cherchons pas à remplacer les enseignants, comme on a peu le lire dans d'autres expériences, mais à permettre à un enseignant de donner son cours à des milliers d'étudiants au lieu de le donner à quelques étudiants seulement.

Les coûts des MOOC

On néglige souvent quand on pense aux MOOC le coût de la pédagogie et de la production de contenu, en ne pensant qu'aux questions de plate-forme qui sont in fine déjà largement résolus. Dans notre cas, l'investissement pour le MOOC ERP5 a été de plusieurs hommes année pour obtenir le début d'un cours raisonnable. Ce cours est en effet le résultat de plusieurs années d'expérience d'enseignement et d'un effort de formalisation important d'un contenu.

L'exemple du MOOC ERP5 montre donc que l'investissement pour la réalisation d'un MOOC se situe principalement dans la production du contenu et dans la réduction du coût de l'examen (sans en baisser la qualité). Or, avec la technologie HTML5, la production du contenu est devenue avant tout un problème humain de pédagogie et non plus technologique, car les outils disponibles sont déjà nombreux. Plusieurs problèmes techniques de MOOC sont déjà résolus par des technologies libres (SlapOS, RunMyDocs, ERP5 AI Toolkit, Rapid-I, etc.) que l'on pourrait utiliser pour produire d'autres MOOC: gestion de projet, programmation, algorithmique CRM, gestion documentaire, etc.

Nexedi espère donc que la mode actuelle du MOOC en France conduire d'abord à financer des contenus pédagogiques et que nous n'assisterons pas aux dérives passées des mécanismes d'aides à l'innovation qui conduiraient dans le cas du MOOC à réinventer des technologies similaires à celles qui existent déjà sous forme de logiciels libres édités par des PME.

Afin de donner quelques chiffres, si Nexedi devait embaucher une nouvelle équipe pour produire un nouveau MOOC, les principaux couts seraient les suivants: 1.000 EUR pour le packaging du logiciel, au moins 100.000 EUR pour la conception et la rédaction du contenu du cours (en comptant les tests et le fait d'essayer le cours avec des étudiants avant de le diffuser largement), au moins 200.000 EUR pour la création d'une base d'exemples permettant de corriger des copies selon un procédé un peu plus sophistiqué qu'un QCM et un bon machine learning. Le seul cout technique est le packaging (1.000 EUR). Tout le reste relève de compétences non informatiques liées à la pédagogie.

Il existe cependant un type d'outil que nous aimerions mieux intégrer dans notre chaine de production. Contrairement à ce que l'on imagine, un MOOC n'est pas déshumanisé. Il y a nécessairement une interaction avec un professeur. Pour l'instant, cette interaction repose sur des outils de type webex ou openmeetings en complément du forum. Ces outils ont encore quelques limitations pour une application au MOOC. Un système tel que Videodesk appliqué aux MOOC me semblerait intéressant à expérimenter pour pouvoir passer aisément quelques minutes de façon interactive avec un participant à un forum qui a du mal à comprendre une réponse.

Conclusion

Le MOOC ERP5 est un succès: il a permis d'enseigner les ERP à 1500 étudiants avec un bien meilleur résultat que toutes les expériences passées qui reposaient sur des logiciel et des contenus plus traditionnels. 

Au delà du cas des ERP, l'approche MOOC pourrait permettre de réduire le coût de l'enseignement dans des proportions sensiblement équivalentes aux réductions de coûts apportées par le Cloud en matière d'informatique d'entreprise: un facteur 10 à 100, selon les cas. L'impact de cette réduction pourrait être similaire: une démocratisation de l'enseignement aussi importante que l'a été l'introduction de l'école obligatoire. Le contexte français dans le supérieur peut cependant sembler défavorable au MOOC. La production d'un MOOC complet (cours + examens) nécessite pour etre rentable un effet de masse (ex. 10,000 étudiants) qu'il est difficile à atteindre aujourd'hui avec la fragmentation des cursus. Il est donc fort probable que ce sont les pays avec des institutions d'enseignement de grande taille qui domineront cette forme d'enseignement.

Il existe cependant des exemples d'initiatives communautaires qui peuvent donner espoir. Sesamath prouve qu'une communauté nationale d'enseignants peut produire un contenu de très haute qualité. Il ne faut par ailleurs par considérer que les MOOC sont une panacée, pas plus que l'enseignement public de masse n'a remplacé le cours particulier.

Contact

  • Photo Klaus Wölfel
  • Logo Nexedi
  • Klaus Wölfel
  • klaus (dot) woelfel (at) nexedi (dot) com
  • Photo Jean-Paul Smets
  • Logo Nexedi
  • Jean-Paul Smets
  • jp (at) nexedi (dot) com
  • Jean-Paul Smets is the founder and CEO of Nexedi. After graduating in mathematics and computer science at ENS (Paris), he started his career as a civil servant at the French Ministry of Economy. He then left government to start a small company called “Nexedi” where he developed his first Free Software, an Enterprise Resource Planning (ERP) designed to manage the production of swimsuits in the not-so-warm but friendly north of France. ERP5 was born. In parallel, he led with Hartmut Pilch (FFII) the successful campaign to protect software innovation against the dangers of software patents. The campaign eventually succeeeded by rallying more than 100.000 supporters and thousands of CEOs of European software companies (both open source and proprietary). The Proposed directive on the patentability of computer-implemented inventions was rejected on 6 July 2005 by the European Parliament by an overwhelming majority of 648 to 14 votes, showing how small companies can together in Europe defeat the powerful lobbying of large corporations. Since then, he has helped Nexedi to grow either organically or by investing in new ventures led by bright entrepreneurs.