Choisir un plugin IA pour Moodle : les 5 questions à poser avant de signer

Le catalogue de plugins Moodle compte désormais plusieurs dizaines d’extensions estampillées IA. Toutes affichent des captures d’écran convaincantes. Peu documentent la façon dont elles s’articulent avec la plateforme, et encore moins ce qu’elles font des données qui les traversent.

Pour un administrateur Moodle ou un responsable de plateforme, la difficulté n’est pas de trouver un outil. Elle est de distinguer une intégration conçue pour durer d’un connecteur assemblé rapidement autour d’une clé d’API.

Voici les cinq questions que nous poserions à un fournisseur, y compris à nous-mêmes. Elles sont classées par ordre d’importance décroissante, et la première élimine déjà une bonne partie du marché.

1. Le plugin utilise-t-il le sous-système IA natif de Moodle ?

C’est la question technique la plus discriminante, et la moins posée.

Moodle a introduit un sous-système IA officiel avec la version 4.5. Son architecture repose sur une séparation stricte entre deux types de composants : les Placements, qui gèrent l’interface et l’endroit où l’IA apparaît dans la plateforme, et les Providers, qui gèrent la communication avec le modèle. Un gestionnaire central orchestre les deux et applique les politiques.

Cette architecture n’est pas décorative. Elle centralise l’acceptation de la politique d’usage de l’IA par les utilisateurs, les rapports d’utilisation, les contrôles d’accès et l’intégration aux mécanismes de sécurité de Moodle. Un plugin qui s’y conforme hérite de tout cela. Un plugin qui l’ignore doit tout réimplémenter, en général moins bien.

Or beaucoup de plugins IA pour Moodle ont été conçus avant l’arrivée de ce sous-système, ou l’ont contourné pour aller plus vite. Ils embarquent leur propre gestion de clés d’API, leurs propres écrans de configuration, leur propre logique de stockage. Le résultat fonctionne, jusqu’à la prochaine montée de version majeure.

Ce que nous vous suggérons de demander, formulé simplement : « Votre plugin est-il déclaré comme Provider, comme Placement, ou comme les deux ? Et sur quelle version minimale de Moodle ? » Un fournisseur qui maîtrise son sujet répond en une phrase. Un fournisseur qui hésite vous renseigne tout autant.

Vérification complémentaire, gratuite : dans le catalogue officiel des plugins Moodle, la fiche indique les versions supportées et la date de dernière mise à jour. Un plugin IA non mis à jour depuis plus d’un an, dans un domaine qui évolue à ce rythme, mérite au minimum une question.

2. Quel régime juridique s’applique aux données, et quels sont les sous-traitants ?

Deux questions distinctes, souvent confondues avec celle de la localisation des serveurs.

La localisation compte, mais elle ne suffit pas. Ce qui détermine qui peut accéder aux données, c’est le droit dont relève l’entreprise qui les traite. Une société soumise au droit américain reste tenue de répondre à une réquisition sur des données qu’elle contrôle, y compris stockées en Europe, en vertu du CLOUD Act.

Les questions concrètes :

• Quelle est la nationalité juridique de l’entité qui traite, et celle de sa maison mère ?
• La liste des sous-traitants est-elle publiée et tenue à jour ?
• Les identifiants des apprenants sont-ils pseudonymisés avant tout appel externe, ou l’identité Moodle transite-t-elle telle quelle ?
• La durée de conservation est-elle administrable depuis Moodle ?
• Le plugin implémente-t-il la Privacy API de Moodle, qui permet l’export et la suppression des données d’un utilisateur ?

Ce dernier point est un excellent révélateur. La Privacy API est le mécanisme standard par lequel Moodle honore les demandes RGPD. Un plugin qui stocke des conversations sans l’implémenter place votre établissement en difficulté dès la première demande de suppression. Et c’est vérifiable dans le code.

Depuis le 2 août 2026, l’AI Act ajoute ses propres obligations de transparence et de traçabilité à celles du RGPD.

3. L’outil est-il conçu pour faire travailler l’apprenant, ou pour lui éviter de travailler ?

La démonstration ne permet pas de trancher cette question. Un assistant qui répond vite et bien fait toujours bonne impression.

La recherche récente est pourtant sans ambiguïté sur les conséquences. L’étude de Bastani et ses collègues, publiée en 2025 dans les Proceedings of the National Academy of Sciences, a suivi près d’un millier de lycéens. Avec l’IA disponible pendant les exercices, les résultats progressent nettement : +48 % pour le groupe disposant d’un assistant standard, +127 % pour celui disposant d’un assistant doté de garde-fous pédagogiques.

Mais lorsque l’accès est retiré et que les élèves passent l’examen seuls, le groupe ayant utilisé l’assistant standard obtient 17 % de moins que le groupe n’ayant jamais eu accès à l’IA. Le point décisif de l’étude est là : cette pénalité disparaît largement chez le groupe encadré. Les garde-fous n’ont pas amélioré la performance finale, ils ont évité qu’elle se dégrade.

Le garde-fou en question était simple : demander à l’IA de fournir des indices conçus par les enseignants plutôt que la réponse.

Ce qu’il faut donc examiner :

• L’assistant pose-t-il une question avant de répondre, ou délivre-t-il directement la solution ?
• Existe-t-il des paliers d’aide progressifs, et sont-ils paramétrables ?
• Que fait l’outil quand un apprenant demande explicitement qu’on rédige son devoir à sa place ?

Demandez une démonstration sur ce dernier scénario. C’est le test le plus rapide et le plus révélateur qui soit.

4. Le comportement est-il paramétrable au niveau de l’activité ?

Un réglage global pour toute la plateforme ne suffit pas.

Un même cours contient des activités de découverte, où un accompagnement généreux est souhaitable, et des évaluations, où il ne l’est pas. Si le plugin ne propose qu’un interrupteur global, l’administrateur devra arbitrer entre deux mauvaises options : désactiver partout, ou accepter la présence de l’IA pendant les tests.

Trois niveaux de granularité à vérifier :

Par activité. Le formateur peut-il désactiver l’assistant sur un test précis, sans intervention de l’administrateur ?

Par rôle. Les capacités Moodle sont-elles utilisées, ou le plugin réimplémente-t-il sa propre gestion des droits ? Le premier cas s’intègre à votre matrice de permissions existante, le second crée un système parallèle à maintenir.

Par défaut. Quel est le comportement livré à l’installation ? La majorité des utilisateurs ne modifie jamais les réglages initiaux. Un plugin livré avec l’assistant actif partout, y compris dans les évaluations, a pris une décision pédagogique à votre place.

5. Que se passe-t-il dans deux ans ?

Le marché des outils IA connaît un taux de disparition élevé. Cette question n’est pas théorique.

Maintenance et compatibilité. Quel est l’engagement du fournisseur sur le support des futures versions de Moodle ? Un plugin conforme au sous-système officiel a structurellement moins de risque de casser lors d’une montée de version qu’un plugin qui manipule le cœur.

Réversibilité. Si vous arrêtez le service, que devient l’existant ? Les activités générées restent-elles des activités Moodle standard, exploitables sans le plugin ? Ou dépendent-elles d’un format propriétaire qui les rendrait inutilisables ? C’est la différence entre un outil qui produit du Moodle et un outil qui produit du contenu captif.

Modèle économique. Sur quelle base la tarification évolue-t-elle ? Les coûts d’inférence des modèles varient fortement, et un fournisseur qui ne peut pas expliquer sa structure de coûts vous expose à une révision brutale.

Une remarque sur la façon dont ces questions sont accueillies

Nous développons un plugin IA pour Moodle, ces questions nous sont donc posées, et nous les posons nous-mêmes à nos fournisseurs.

Notre observation, après plusieurs mois d’échanges sur le sujet : la qualité de la réponse compte davantage que son contenu. Un fournisseur qui répond « nous ne sommes pas encore conformes au sous-système 4.5, voici notre calendrier » inspire plus confiance qu’un fournisseur qui affirme tout maîtriser sans entrer dans le détail.

Un outil qui traite des données d’apprenants dans un établissement public engage la responsabilité de cet établissement. Les fournisseurs qui l’ont compris savent répondre précisément. Les autres parlent d’expérience utilisateur.

Références

• Moodle Developer Resources, AI Subsystem, moodledev.io — architecture Provider/Placement introduite en Moodle 4.5 (MDL-80888)
• Bastani, H., et al. (2025). Generative AI without guardrails can harm learning: Evidence from high school mathematics. PNAS, 122(26), e2422633122.
• Règlement (UE) 2024/1689 sur l’intelligence artificielle
• 18 U.S.C. § 2713, CLOUD Act (2018)