Transcription

• Speaker #0

  Bonjour, je suis Aristide Boucaret, la voix de Novagogy, le podcast des innovations pédagogiques de CY Alliance. Nous sommes toujours au Moodle Mood de 2025 à Paris et pour cette deuxième partie de hors-série, nous allons nous intéresser aux termes le plus utilisés, après communauté, lors de ces trois jours. Plugin, on va chercher à comprendre comment marche un plugin, comment est-ce qu'il peut être implémenté. à quoi ça sert et comment le présenter à la communauté. Quand je dis on, je parle un peu de moi mais aussi et surtout d'un revenant nommé Astor, on l'avait déjà interviewé lors du model-mode sur Mars et de Jean-Marie. Merci à vous deux pour votre disponibilité et vos éclairages. Il ne me reste plus qu'à vous souhaiter un bon épisode. Bonjour à toutes et à tous, on se retrouve pour ce nouvel épisode de Nova Goji qui se déroule en direct du Moodle Moodle numéro 20 à Paris. Et donc pour ce nouvel épisode de Nova Goji, on est face à des personnes qui sont en train de jouer un jeu d'échecs géant. C'est la finale tant attendue entre Larusse, Moudelovski. Et l'américaine tchèque naturalisée Pluginovich. Et en fait, là, on est assez imprégné par cette finale parce qu'il se passe des choses, il y a des retournements. Là, punaise, il y a le roi qui vient d'être déplacé. Enfin, il y a plein de choses incroyables. Et on va profiter de ce moment pour aussi parler de Plugin. Alors déjà, je vais vous poser une première question, c'est... qui vous êtes, est-ce que vous pouvez vous présenter, et ensuite me dire c'est le combien de tièmes Moodle Mood auquel vous participez s'il vous plaît.

• Speaker #1

  Eh bien, je commence. Donc je m'appelle Astor, je suis développeur de plugins à l'université de Grenoble. Quand je dis développeur de plugins, c'est-à-dire que c'est mon métier, c'est vraiment la mission pour laquelle je suis engagé, c'est faire des plugins. pour le projet Moodle sur lequel je suis, mais également de les partager en open source sur le store des plugins Moodle. C'est mon troisième MoodleMoot, j'étais déjà là l'année dernière à Marseille où j'ai pu participer à un épisode de Novagogy déjà, donc je suis ravi de le refaire.

• Speaker #2

  Bonjour, je m'appelle Jean-Marie. Je suis à l'université de Caen, je suis ingénieur pédagogique et administrateur de plateforme Moodle, forcément. Pendant plusieurs années, j'ai maintenu en fonctionnement des plateformes et des plugins, justement. Et là maintenant, je suis chargé d'expérimentation en partie de plugins.

• Speaker #0

  Donc vous l'aurez compris, la thématique de cette première discussion, ça sera autour des plugins. Alors la première question, elle va être assez simple parce que moi j'aime bien définir les termes avant qu'on puisse commencer la discussion. C'est quoi un plugin s'il vous plaît ?

• Speaker #2

  Je te laisse commencer.

• Speaker #1

  Allez, j'essaie de répondre. C'est vrai que c'est pas forcément facile de donner une définition simple et claire. Un plugin au sens Moodle, c'est... Un ensemble de fonctionnalités qui vont pouvoir être ajoutées pour enrichir Moodle de ses fonctionnalités. Quand je dis que ça va se rajouter à Moodle, je pense que ça s'appelle un plugin. C'est quelque chose qui peut se rajouter. L'idée d'un plugin Moodle, c'est qu'un plugin qui fonctionne sur une instance de Moodle dans une université va également fonctionner sur un autre Moodle d'une autre université. Et c'est ce qui fait cette richesse de Moodle et de ce store de plugins. C'est que des plugins qui sont développés dans une université pour un Moodle en particulier, s'ils sont partagés par les développeurs en se disant « tiens, ça peut peut-être servir à quelqu'un » , eh bien oui, ça va pouvoir servir à quelqu'un parce qu'automatiquement, ça va réussir à être ajouté à Moodle. Pour revenir juste recadrer sur la définition de ce qu'est un plugin, il en existe de plein de sortes dans Moodle. Ça peut être un type d'activité, ça peut être un blog, quelque chose qui va s'afficher sur le côté d'un cours, ça peut être une méthode d'inscription à un cours, ça peut être plein de choses. Est-ce que tu veux ajouter quelque chose à ça, compléter ?

• Speaker #2

  J'ai une définition un petit peu plus simple, mais je ne suis pas développeur, peut-être pour ça. Pour moi, c'est une extension du logiciel qui est optionnelle et qu'on va pouvoir installer du coup si on en a le besoin.

• Speaker #0

  Ok.

• Speaker #2

  Comme c'est une option qui sont développées par des tiers. On a toute la problématique derrière de la maintenance. Est-ce que l'équipe qui développe ça va le maintenir ? Et ça nous pose tout un tas de questions derrière.

• Speaker #0

  Alors c'est bien parce que tu es en train d'anticiper la première question que je me posais et que je voudrais vous poser. C'est comment est-ce qu'on fait pour proposer un plugin et comment ça fonctionne un plugin sur Moodle ? Est-ce que, par exemple, il y a des protocoles à respecter ou on est un petit peu libre ? libre dans notre manière de construire un plugin ?

• Speaker #1

  C'est une question surtout pour moi, je pense. Je pense que du coup, un premier élément de réponse, je vais essayer de faire dans la chronologie de la naissance d'un plugin Moodle. Donc ça part à la base d'une idée, d'un besoin. Le besoin n'est pas forcément crucial. Des fois, ça peut être juste un développeur ou un enseignant qui d'ailleurs s'improvise développeur de plugin, qui se dit j'aimerais bien faire ça et qui se dit allez, je n'ai pas trouvé actuellement de plugin qui faisait cette chose qui m'intéresse ou pas exactement, je me lance, je vais faire quelque chose qui répond à mon besoin. Donc, soit il le fait lui-même, soit il fait appel à un développeur. En l'occurrence, mon boulot de développeur, c'est surtout d'échanger avec la communauté enseignante, de se rendre compte des besoins et éventuellement de développer les nouveaux plugins dont il y a besoin. Donc, la première étape, c'est identifier quel est le type de plugin à mettre en place. Est-ce que c'est un nouveau type d'activité ? Est-ce que c'est quelque chose juste un affichage à côté ? Ne serait-ce que ça. Je veux que telle information puisse être affichée dans tous mes cours. Le type de plugin n'est pas forcément clair. Est-ce qu'on veut que ça soit un bloc optionnel ? Est-ce qu'on veut que ça soit quelque chose qui va s'afficher automatiquement dans tous les cours, auquel cas ça va être encore un autre type de plugin ? C'est déjà pas évident comme question. Pour donner un autre exemple concret, Par exemple, si jamais on veut enrichir l'expérience d'enseignants et d'étudiants quand ils participent à un quiz, enfin un test en français, donc un ensemble de questions auxquelles les étudiants répondent, déjà il y a plusieurs types de plugins qui se branchent à ce type d'activité. Il y a les types de questions, il y a les comportements de questions qui n'offrent pas la même richesse. Déjà un vrai besoin à identifier là-dessus. Et ça je pense que c'est quelque chose qui vient avec l'expérience à la fois Moodle et de développement, de se rendre compte de quel plugin fait quoi et qu'est-ce qui est adapté dans quelle situation.

• Speaker #0

  Toi si tu as besoin d'un plugin ou tu as une option ou quelque chose que tu veux faire, comment est-ce que tu fonctionnes ? Tu essayes déjà de trouver quelque chose qui existe ? De quelle manière tu procèdes si tu as une action que tu veux faire ?

• Speaker #2

  Quand j'ai un besoin, la première chose... Ce que je regarde, c'est est-ce que la fonctionnalité existe déjà dans la plateforme Moodle en mode natif ? C'est-à-dire sans avoir besoin d'ajouter quelque chose. Parce que moi, ma hantise, c'est d'ajouter un plugin. Parce qu'à chaque fois, je me dis, ajouter un plugin, est-ce qu'on peut éviter ? C'est la première chose à faire. Parce que souvent, il y a un certain nombre d'utilisateurs qui ajoutent plein de plugins. Parce qu'ils ne savent pas que la fonctionnalité existe par ailleurs déjà dans la plateforme ou qu'elle est déjà couverte par un plugin qu'ils ont déjà installé, mais qu'ils ont des fois un peu oublié. Ou qu'on peut le faire du coup en paramétrant d'une certaine manière l'existant. Donc moi déjà c'est déjà d'identifier est-ce que l'objectif recherché... peut se faire avec les moyens existants ? Ça, c'est ma première question, moi. Et souvent, on voit, d'ailleurs, il y a des plugins qui sont développés et je me dis, le développeur, quand il a développé ça, je ne sais pas qu'est-ce qu'il avait dans l'idée parce que ça existe déjà. On n'a pas tout à fait le même regard, on n'est pas du même côté de la barrière. Moi, je suis très utilitaire.

• Speaker #1

  C'est une question que tu te poses, mais qu'on est censé se poser aussi en tant que développeur. Est-ce qu'on n'est pas en train de réinventer la roue, de recoder quelque chose qui existe, que ce soit en natif ou sur le store Moodle, justement. On essaye autant que possible d'éviter ça. Mais ça reste qu'il y a souvent des gens qui trouvent que même l'existant, si ça ressemble, ça ne répond pas exactement aux besoins et on se retrouve à rajouter quelque chose.

• Speaker #0

  Et après, il peut y avoir ce truc de, dans une nouvelle version de Moodle, un plugin qui était un plugin extérieur devient natif sur une nouvelle version et que le plugin, il existe déjà. Après, tu me diras, on ne peut pas le réinstaller par-dessus.

• Speaker #2

  C'est très rare comme situation, en fait, d'avoir un plugin qui était un plugin tiers, externe, et qui devient, du coup, qui s'intègre. C'est le cas de BigBlueButton, par exemple, qui est un des plugins emblématiques qui a fait ce chemin-là. Mais c'est très rare ce genre de situation. Les gens qui gèrent du coup le Moodle ont tendance à intégrer plutôt des correctives, des améliorations de l'existant, mais ils sont frileux d'intégrer beaucoup de choses nouvelles parce que forcément, qui dit beaucoup de choses intégrées dans le cœur, dit plus de maintenance et donc des coûts à assumer supplémentaires. Donc ils sont très scrupuleux dans leur choix.

• Speaker #0

  C'est le cas de H5P aussi, il me semble, qui était tiers et qui est devenu natif.

• Speaker #2

  Exactement, parce qu'H5P, effectivement, a été intégré au cœur, parce que c'est un autre projet de développement open source qui partageait les mêmes valeurs, finalement, que... que Moodle, de la même manière que TinyMCE par exemple, qui est un autre développement tiers qui est intégré justement. Et là on est vraiment sur une intégration où au lieu de réinventer l'eau chaude, c'est exactement ça, ils se sont dit il y a un projet open source qui existe et si on développait du coup une intégration de ce projet au lieu de refaire la même chose en moins bien.

• Speaker #1

  Je pense que pour les développeurs, c'est un petit peu le saint graal de se dire « Waouh, mon plugin a tellement plu, a été tellement une évidence à utiliser qu'il a été intégré au cœur. » Je pense que ça fait vraiment plaisir si jamais ça arrive.

• Speaker #0

  Et donc là, on va continuer notre chemin réflexif. Si ce que tu cherches n'existe pas en natif, qu'est-ce que tu fais ? Comment est-ce que tu procèdes ?

• Speaker #2

  Alors ça va dépendre de l'établissement où on est et la politique d'installation des plugins qu'on a dans notre établissement. Parce que moi je suis dans un établissement qui est un grand établissement où quand on installe un plugin, on va l'installer pour plus de 2000 enseignants et plus de 30 000 étudiants. Donc on ne peut pas installer n'importe quoi, n'importe comment sur une plateforme comme ça qui est aussi volumineuse. Donc là, du coup, s'il doit y avoir une installation, ça passe par tout un process dans notre établissement de validation par des instances où on propose du coup l'ajout. On doit l'argumenter, le justifier, montrer justement que ça n'existe pas, que c'est un besoin réel, apporter souvent des témoignages d'enseignants qui demandent du coup telle fonctionnalité. Parce que derrière, ça va impliquer tout un ensemble de maintenance. Pour l'équipe qui gère du coup la plateforme, qui est supplémentaire. Donc il y a un coût pour l'établissement. Et avec des risques associés à chaque plugin, puisque c'est un plugin additionnel, rien ne nous dit qu'il existera encore dans deux ans. Or nous, comme on a une communauté qui est importante, quand un plugin est en cours d'utilisation, on ne peut pas arrêter l'utilisation comme ça en claquant des doigts, parce qu'on a des centaines d'enseignants qui vont utiliser le même objet. Et donc nous, ça a un coût énorme quand un plugin n'est plus maintenu, parce que derrière, ça déclenche... Il faut trouver une solution de rechange et ensuite il faut accompagner l'ensemble des utilisateurs à changer de solution. Le coût humain pour nous est énorme. Donc on a tout un protocole rigoureux pour justement garantir la pérennité des outils qui sont mis à disposition de nos enseignants.

• Speaker #0

  Alors je pensais vraiment pas qu'on allait vers ce chemin dans la discussion et je trouve que c'est vachement intéressant et c'est ça que je trouve cool avec les différents épisodes que je fais avec Nova Goji, c'est que je m'imagine des choses, je m'imagine comment la discussion elle va mener et à chaque fois on arrive à dévier de ce que je pense et je suis toujours surpris donc merci beaucoup pour cette surprise. Et donc si t'as quelque chose à rajouter par rapport à ça, toi Astor, parce que toi t'es pas au même niveau, toi t'es de l'autre côté.

• Speaker #1

  J'ai forcément des tas de choses à répondre à ça, évidemment. C'est effectivement un autre point de vue des éléments de ce qui se passe. Déjà, première étape sur la question de la fiabilité de ce qu'on installe. Comme tu disais, ça doit être testé par un certain nombre d'instances, savoir qu'est-ce qui se passe. Déjà... Il faut se poser la question de comment est-ce qu'un plugin se retrouve sur le store Moodle des plugins. Une fois que le plugin est développé, un développeur peut choisir volontairement, c'est vraiment une démarche d'un développeur, d'aller le déposer sur le store Moodle. En faisant ça, il crée un nouveau plugin qui pour l'instant n'est absolument pas publié, n'est visible par personne. Et il y a dans quelque part chez Moodle, je ne sais pas si c'est dans le Moodle HQ, quelque part ailleurs, des bénévoles, honnêtement je ne sais pas qui c'est. qui viennent regarder les nouveaux plugins qui sont soumis sur le Moodle Store, qui viennent à la fois les tester évidemment, mais également faire une revue du code, vérifier qu'ils ne font pas de fourberies n'importe où, qu'ils sont codés correctement. Ils vérifient également un certain nombre de choses en termes de bonne pratique de code, non pas simplement des questions de génie logiciel parce qu'ils ne sont pas là pour ça. mais uniquement des bonnes pratiques de code à l'intérieur de Moodle pour s'assurer que ça marchera sur tous les Moodle, sur toutes les versions qui sont prévues par le plugin. Donc il y a cette vérification qui est faite. Si jamais ils trouvent quelque chose de bloquant, qui selon eux pourrait faire, vraiment pose problème pour la publication du plugin, ils bloquent la publication du plugin, ils envoient un message au développeur en disant « Ton plugin il est cool, mais il y a tel problème, tel problème, tel problème. » Ça leur arrive également de juste dire bon Il y a tel problème, tel problème à régler, mais ce n'est pas bloquant, parce que c'est juste, ça serait mieux que ça soit comme ça, mais pour l'instant, on peut le lancer, et pour ta prochaine mise à jour, s'il te plaît, résous ce problème et ce problème, et comme ça, tout le monde est content. Donc déjà, un plugin qui se retrouve sur le Moodle Store a quand même été revu. Ce n'est pas juste quelqu'un qui l'a envoyé là, et on ne sait pas d'où sort le code et s'il a été revu, mais il est là pour une raison. Après, je mets quand même un bémol là-dessus. C'est que cette vérification n'est effectuée que pour la première publication d'un plugin. C'est-à-dire, si moi, en tant que développeur, je publie un nouveau plugin, il y a cette vérification qui est faite. Mais si je publie une mise à jour, aussi importante soit-elle, par exemple, je peux passer de version 1 à version 2 avec double des fonctionnalités et j'enlève des fonctionnalités qu'il y avait avant, à ce moment-là, il n'y a pas de revue. Moodle n'effectue pas de revue de ce nouveau code. Donc, la confiance est acquise juste à partir du moment où il y a eu la première publication. Donc c'est important effectivement de maintenir cette notion de test de plugin qu'on installe, surtout s'il s'agit de développeurs qui potentiellement n'ont qu'un seul plugin sur le store, donc qui n'ont pas forcément beaucoup d'expérience sur comment ça marche, quelles sont les bonnes pratiques et tout. Donc c'est vraiment extrêmement important d'avoir des plateformes de test. et de ne pas installer des plugins du Moodle Store sur vos plateformes de production avec des vrais utilisateurs immédiatement parce que les développeurs aussi, autant de bonne volonté soit-il, peuvent faire des erreurs et ça peut avoir des conséquences parfois largement plus grandes que ce que les développeurs avaient prévu parce que selon la taille de la plateforme, selon son échelle, selon son nombre d'utilisateurs des fois il y a des... Des petites choses que le développeur se dit « bon, telle chose, c'est pas optimal, mais c'est pas grave parce que ça consomme pas grand chose » . Oui, mais si vous avez 10 000 utilisateurs sur la plateforme, en fait c'est 10 000 fois pas grand chose et ça a des conséquences. Nous on s'en est rendu compte, heureusement sur notre plateforme à nous, mais on a eu ce problème. Un truc qui n'a pas été optimisé, je plaide coupable, mais qui effectivement sur notre plateforme de test avec 5 utilisateurs posait pas de problème, au développement posait pas de problème. Mais avec 10 000 utilisateurs plus des bots qui font du scraping, donc qui visitent les pages internet au hasard pour regarder quelles sont les informations, il y en a plein sur internet, ça faisait des requêtes, ça faisait ramer tout le site pour rien. Donc les développeurs peuvent faire des erreurs. Testez vraiment les plugins que vous installez. Les développeurs... Sont de bonne volonté, vraiment. Je n'imagine pas un développeur malfaisant poster quelque chose sur le Mood Duster. Ce n'est pas impossible, mais je n'imagine pas ça. Mais testez vraiment ce qui se passe avant de les installer.

• Speaker #2

  Et c'est d'autant plus important de tester sur une installation, pas seulement en production avec les étudiants, mais une installation qui est très proche de la sienne et de son contexte local, parce qu'on a des effets contexte. C'est-à-dire qu'on a une installation avec des technologies qui sont derrière. Une plateforme Moodle, ce n'est pas juste un logiciel, c'est toute une infrastructure derrière avec des serveurs web, un serveur de base de données, toute une installation très localisée avec des technologies spécifiques et un équipement en plug-in spécifique. Or, on n'est pas à l'abri d'avoir des interactions inopinées entre un développement qui a été peut-être bien pensé et qui est peut-être très bien fait. mais qui a une interaction inattendue avec notre infrastructure ou alors un autre plugin qui n'a pas été testé avec lui ensemble. Et là, on peut avoir des soucis majeurs qui émergent dans cette situation.

• Speaker #1

  Là, tu soulèves un point très intéressant sur l'interaction des plugins. Si vous testez un plugin quelque part, ne le testez jamais tout seul sur une installation propre. Testez-le vraiment sur la même installation que vous avez en prod, en disant juste qu'est-ce que ça change si on rajoute ce plugin, cette fonctionnalité. Parce que j'ai développé des plugins qui ont du mal à interagir avec d'autres plugins. Par exemple, le plugin... Ah non, toi c'est les degrés de certitude dont je parlais. J'ai fait un plugin qui affiche des éléments sur une page de cours, de manière dynamique, et bien ça interagit très très mal avec par exemple le format tuile des formats de cours. Parce que j'ai commencé à le développer sans prendre en compte ce format additionnel de cours, qui pour le coup donne un format de page totalement différent, donc le plugin se comporte très mal. C'est pas un bug qui est très grave dans le sens où c'est juste, bon, la fonctionnalité marche pas. Les utilisateurs s'en remettent ces bloquants pour personne, mais c'est effectivement un problème qui peut survenir et c'est important de le tester.

• Speaker #2

  Donc quand on est admin, souvent les bonnes pratiques recommandées, c'est de tester déjà le plugin sur une installation la plus simple possible et la plus standard pour déjà vérifier que le plugin fonctionne bien, qu'on comprenne comment le plugin fonctionne. Et ensuite seulement, on le teste sur une installation qui est la plus proche possible de la version réelle qui est utilisée par les usagers, de façon à voir si dans notre écosystème complet, il y a un effet d'interaction qui se produit.

• Speaker #1

  En fait, je n'ai pas fini de répondre à ce qu'a dit Jean-Marie. Je sais, j'ai beaucoup de choses à raconter. En même temps, le sujet est vaste, il y a beaucoup de choses à dire. Donc tu permets que je continue ? C'était sur le deuxième point que Jean-Marie t'a abordé tout à l'heure, qui est la question de la maintenance des plugins. Vaste sujet, encore une fois, à cet endroit-là. déjà ne serait-ce que la question de bon... On a un plugin qu'on a installé parce qu'un développeur, Thier, l'a fait. Mais sur le Moodle Store, c'est écrit que ce plugin marche uniquement jusqu'à la version Moodle 4.2. Et nous, on aimerait bien passer à la version Moodle 4.5 cet été. Et qu'est-ce qu'on fait ? Déjà, une information facile à donner, c'est que les versions compatibles de Moodle sont purement déclaratives. Sur le Moodle Source, c'est le développeur qui juste déclare « Ok, mon plugin est compatible avec telle version, telle version, telle version. » Il ne dit pas « C'est incompatible avec telle autre version. » Juste, c'est une liste de versions compatibles. Donc pour peu que soit il n'ait pas coché la version, enfin il ait sauté une version, ça ne veut pas dire que c'est incompatible. Et si c'est une version plus récente, c'est pareil, ça ne veut pas dire que c'est incompatible. Le plus probable étant juste que ce développeur n'a pas encore testé le plugin sur cette nouvelle version et n'a pas encore coché la case « oui, c'est compatible avec cette version » . Sachant qu'il y a de bonnes chances quand même pour que le plugin soit bel et bien compatible avec cette nouvelle version. Donc moi là, je vais donner mon point de vue de développeur. Quelque chose de très agréable, c'est quand on a un utilisateur qui nous envoie un commentaire sur un plugin en disant « Bon, ce n'était pas marqué comme compatible, mais moi j'ai testé ce plugin sur la version 4.5, il marche nickel. » Parce que ça, pour le coup, moi en tant que développeur, ça me fait gagner du temps. Déjà, ça me rappelle que, ah oui, tiens, j'avais oublié de marquer ce plugin, enfin de tester que ce plugin était compatible et de le marquer comme compatible. Mais ça me fait gagner du temps. Ça fait que, déjà, ça me met en confiance. Je fais une rapide vérification que oui, bon, ça va, ça marche bien quand même. Histoire de... J'engage ma responsabilité quelque part quand je dis que c'est compatible. Donc je vais tester par moi-même. Mais ça me fait gagner du temps. J'y vais plus confiant. et si tout a l'air de bien marcher, je veux dire bah oui. effectivement c'est compatible, tout va bien alors que je n'ai fait aucun changement de version c'est exactement le même plugin tout ce que j'ai fait c'est cocher la case en disant oui oui c'est bon il est compatible donc c'est une première information à avoir que c'est pas parce que c'est pas marqué que c'est compatible que immédiatement tout votre Moodle va casser si vous faites un changement de version Maintenant, pour revenir sur la question de la maintenance, parce que j'entends qu'on installe un plugin, si au moment où on l'installe, on a vu dernière release il y a deux semaines, cool, ça veut dire que c'est actif. Et que deux ans plus tard, dernière release il y a deux ans et deux semaines, c'était la dernière fois que le développeur a posé ses doigts dessus, effectivement ça peut poser problème, surtout si, en l'occurrence, on avance vers des versions de Moodle avec lesquelles ça n'est plus compatible. Parce que le QR Moodle évolue, donc il y a des plugins qui ne sont plus compatibles avec des versions plus récentes et qui demandent des mises à jour. J'ai pas de solution miracle en disant, bah oui, si en fait vous avez moyen que ça soit maintenable, non. Forcément. Maintenant, il y a, ceci dit, un débat intéressant que je trouve, c'est la question de moyens que les administrations ont envie de mettre, que les... Je te vois ricaner. Je le dis dans le micro parce que son ricanement ne s'entend pas. On a eu cette question sur le plugin des degrés de certitude que j'ai fait dont tu parlais, qui est en train d'être installé sur tous les Moodle et l'EA qui vont passer en version 4.5 cet été. Et on a eu la question, quand j'avais fait une visio avec les responsables, qui disaient « Ok, on veut installer ce plugin, mais quitte de la maintenabilité » . En fait, on s'était dit « Déjà, moi, je suis développeur en CDI à l'Université de Grenoble. Pour l'instant, je vais le maintenir, il n'y a pas de souci. Mais effectivement, dans cinq ans, je ne sais pas ce que je ferai de ma vie. Donc, on n'est jamais à l'abri de ça. » Maintenant, effectivement, si une institution croit en l'utilité d'un plugin, elle peut mettre des moyens, si à un moment il n'est plus maintenu, pour que quelqu'un reprenne le plugin, afin de pouvoir le rendre compatible avec une nouvelle version. Car c'est quand même l'intérêt de l'open source, c'est l'intérêt de la licence GPL sous laquelle sont normalement publiés tous les plugins. qui est que c'est maintenable, modifiable par n'importe qui. Donc une institution, si elle croit en un plugin et qu'elle y met les moyens, peut tout à fait reprendre un plugin, même s'il n'est plus maintenu, ne serait-ce que pour elle, ne serait-ce que pour cette institution, afin de la rendre compatible. Ce qui, en général, en plus, n'est vraiment pas un gros boulot. Développer de nouvelles fonctionnalités pour un plugin, c'est un gros travail. Maintenir un plugin juste pour qu'il continue à fonctionner dans les versions suivantes de Moodle... généralement, ce n'est pas plus de 10 lignes de code à changer par version de Moodle, dans le pire cas.

• Speaker #2

  Je vais être obligé de te contredire. Parce que la maintenance pour avoir commencé à regarder et avoir un collègue qui fait de la maintenance d'un plugin... C'est pas tant du coup la maintenance de version, c'est plutôt répondre aux usagers qui vont faire des commentaires. Il y a tout un travail de réponse, d'accompagnement de la communauté, répondre, des fois d'avoir des bugs qui apparaissent quand on change une version d'un logiciel, etc. Et là qui demande à être vraiment calé, de se plonger dans le code. Or, par exemple, moi mon collègue qui fait la maintenance d'un plugin, il le fait une fois par an. Mes résultats, c'est très chronophage à chaque fois, parce qu'il fait très peu de développement de ce genre à chaque fois. Et donc à chaque fois, c'est un coin important pour se remettre dedans. Et ça, ma direction a beaucoup, beaucoup d'objectifs à faire passer. Et bien souvent, l'objectif de maintenance du plugin, ça passe souvent loin, loin. Et on se retrouve régulièrement avec la question de quand est-ce qu'on met à jour ? Ah bah oui mais pas tout de suite parce que là on a cette urgence là. Ah bah oui mais pas tout de suite parce que là on en a encore une autre. Et souvent on va repousser parce que nos administrations ne sont pas forcément dotées d'un équipement en développement. développement permanent. On fonctionne actuellement beaucoup dans la fonction publique française sur des appels à projets qui sont limités dans le temps, avec des nouveaux contrats précaires, des CDD de projet, qui fait que le développement est bien assuré pendant la période du projet, mais après, c'est une véritable inconnue, puisqu'on demande aux établissements de faire des économies, et en même temps, du coup, on leur demande de faire du pérenne. C'est très compliqué comme équation.

• Speaker #0

  C'est super intéressant et on a de moins en moins de temps parce qu'en fait j'essaye de ne pas faire des choses trop longues à chaque fois pour l'écoute et du coup je voudrais qu'on aille sur une dernière thématique c'est, alors donc on a fait toutes les étapes j'ai créé mon plugin que j'ai appelé le Nova Plug voilà le plugin de Nova Goji il a passé toutes les étapes, il est dans le Moodle Store Comment est-ce que je fais pour moi si je suis développeur pour le faire connaître et si je suis dans un rôle d'ingénieur pédagogique par exemple et que je trouve un plugin soit intéressant, soit forcément pas adapté, comment est-ce que moi je peux faire en sorte qu'un avis plus fin soit donné autour de ce plugin en plus de la description qui est donnée ?

• Speaker #1

  J'ai une première réponse sur comment faire connaître le plugin. Déjà la question c'est, est-ce qu'on a tellement envie d'absolument chercher à ce que le plugin soit connu ? Parce qu'il y a pas mal de gens qui publient les plugins juste dans l'espoir qu'un jour ça soit utile à quelqu'un, mais qui de toute façon l'ont développé pour eux et c'est une bouteille à la mer, tant pis. Même si je trouve que c'est dommage, parce que souvent les plugins sont de très belles additions et pourraient être utiles à des gens pour peu qu'ils en entendent parler, parce qu'il y a beaucoup de besoins et ils ne se rendent pas compte qu'ils les ont, mais... Le jour où ils découvrent, ils se disent « mais c'est génial en fait ce truc que je ne faisais pas sur Moodle parce que c'était trop compliqué » et là ça devient simple donc je trouve ça bien. Moi j'ai une réponse degré zéro, c'est venez à un Moodle Moodle. En fait, venez, que ce soit présenter le plugin ou en parler au détour d'une pause café de « hé on a développé ça, c'est vachement bien » , ça marche à fond. C'est vraiment le conseil que je peux donner là-dessus.

• Speaker #2

  Une première réponse effectivement évidente, venir à la rencontre des éventuels usagers et leur présenter son travail qui souvent est de qualité et qui est très bien accueilli. Donc les communautés accueillent avec bras ouverts justement les créateurs de plugins parce que, ah enfin un nouveau plugin, qu'est-ce qu'il fait ton plugin ? Et on a une communauté en général très accueillante. Une autre stratégie, c'est de créer un forum dédié à son plugin pour que justement... les gens puissent venir poser des questions dans un fil de discussion qui est dédié. Et là, en général, ça marche très très bien, justement. Parce que c'est d'ailleurs poussé dans les recommandations en disant que quand on a un plugin qu'on veut populariser, le fil de discussion, c'est vraiment un bon outil.

• Speaker #0

  Est-ce que vous avez un dernier mot concernant le Moodle Mood, concernant la vie, concernant même vos passions avant la fin de cet épisode de podcast ?

• Speaker #1

  Un mot de conclusion concernant ma vie, le Moodle Mood, je ne sais pas.

• Speaker #0

  Est-ce que vous avez un plugin à nous conseiller ?

• Speaker #1

  C'est le moment de l'autopromotion, c'est ça ? Non, je ne vais pas faire ça. Je vais juste rappeler que le Moodle Moodle, c'est une super opportunité pour rencontrer la communauté Moodle, des gens qui ont des usages, des professions différentes des nôtres quand on y vient. A chaque fois que je viens à un Moodle Moodle, que je présente ou pas, j'en repars avec une liste de devoirs à la maison longue comme le bras parce que j'ai parlé de mes plugins, que des gens en ont entendu parler et qu'ils ont dit et « Eh mais il manque ça, ça serait bien qu'il y ait ça. » Et vraiment, à chaque fois, je repars avec une to-do list, j'ai l'impression que j'en ai pour l'année. Et en fait, quand j'arrive à la fin de l'année, il y a un nouveau Moodle Mood et c'est reparti pour un tour. Mais c'est un plaisir à chaque fois parce que c'est une communauté qui est vivante. Et c'est pour ça que je fais ce métier en fait. Parce que je sais que ce que je fais est utile, est utile à des gens. Et je le vois parce que ces gens, je les rencontre et ils me disent « Est-ce que tu as fait, c'était utile ? » Et je suis absolument ravi pour ça.

• Speaker #2

  De mon côté, c'est pareil. Je reviens avec plein de choses à tester et ma direction à chaque fois me dit tout ça.

• Speaker #0

  Merci beaucoup de votre présence et de votre acuité à répondre à des questions qui paraissent vagues au début, mais vous arrivez à sortir des choses très profondes. Très cher Jody Therese, je vous dis à très bientôt pour un nouvel épisode et au revoir. Ciao. Ciao. Salut. Ce podcast, à l'image du Moodle Mood, a une vocation collaborative. N'hésitez pas à nous dire en commentaire si vous avez la même définition qu'Astor et Jean-Marie des plugins. D'ailleurs, est-ce que vous utilisez des plugins ? Si oui, lesquels ? Et pour quoi faire ? Un grand merci encore à Jean-Marie Astor pour leur disponibilité et leur concentration, malgré la partie d'échec assez incroyable qui se déroulait sous nos yeux. Un grand merci aussi à Alice Mokreki pour le montage. C'était le dernier épisode avant la rentrée. Bonnes vacances et ciao les pédagos !