Apprentissage adaptatif pour votre MVP EdTech

L'apprentissage adaptatif, c'est un logiciel qui modifie ce que l'apprenant voit ensuite en fonction de ses résultats sur ce qui précède. Une bonne réponse, on avance. Trois erreurs d'affilée sur les fractions, et au lieu du quiz suivant on propose un exemple corrigé et un exercice plus facile. Le parcours est personnel, calculé en temps réel, et différent pour chaque utilisateur.

Voilà toute l'idée, et elle existe bien avant le battage médiatique autour de l'IA. Les systèmes tutoriels intelligents des années 1980 faisaient déjà bifurquer les élèves selon leurs réponses. Ce qui a changé récemment, ce sont les données et la modélisation. Les systèmes d'apprentissage adaptatif actuels suivent des milliers de petites interactions par apprenant et s'appuient sur cet historique pour estimer ce que la personne maîtrise et ce qu'elle devrait tenter ensuite.

Pour un fondateur, le bon cadrage tient en une phrase : l'apprentissage adaptatif n'est pas une fonctionnalité qu'on greffe à la fin. C'est une boucle. Présenter un contenu, observer une réponse, mettre à jour son estimation des connaissances de l'apprenant, puis choisir l'élément suivant. Tout le reste de ce guide consiste à bâtir une version fine et honnête de cette boucle dans un premier produit livrable en quelques semaines plutôt qu'en années.

En retirant le vernis marketing, un moteur adaptatif enchaîne quatre étapes en boucle.

D'abord, il présente un élément : une question, une vidéo, une lecture, un exercice de code. Ensuite, il enregistre la réponse et les signaux qui l'entourent : correcte ou non, temps passé, indices utilisés, nombre de tentatives. Puis il met à jour un modèle de l'apprenant, une estimation continue de son niveau de maîtrise pour chaque compétence du programme. Enfin, il applique une politique de sélection qui lit ce modèle mis à jour et choisit l'élément suivant, en jonglant entre deux objectifs : garder l'apprenant dans la zone où le travail est assez difficile pour enseigner, mais pas au point de le faire abandonner.

Le modèle de l'apprenant, c'est la partie qu'on sous-estime. Une approche courante et bien comprise est le Bayesian Knowledge Tracing, qui représente chaque compétence par une probabilité de maîtrise et fait monter ou descendre cette probabilité après chaque réponse. Une autre famille, la théorie de réponse à l'item (IRT), estime à la fois la difficulté de chaque élément et le niveau de chaque apprenant sur la même échelle, ce qui permet de les apparier. Les deux tournent en production depuis des années et aucune n'exige un grand modèle de langage.

La politique de sélection peut tenir en quelques règles. Si la maîtrise de la compétence X passe sous 0,6, on reprend la compétence X. Si elle dépasse 0,95, on saute en avant. Des règles transparentes, faciles à déboguer, et bien suffisantes pour une première version. Vous passerez à une sélection par optimisation plus tard, une fois assez de données d'apprenants pour la justifier.

On parle de l'IA appliquée à l'apprentissage adaptatif comme si tout reposait sur la même technologie. C'est faux. Il y a deux couches distinctes, qui résolvent des problèmes différents.

La première couche, c'est la modélisation qui alimente l'adaptativité elle-même : suivi des connaissances, estimation de la difficulté des items, choix de l'élément suivant. Ce sont des techniques statistiques et de machine learning, et elles sont matures. Le Deep Knowledge Tracing, qui utilise des réseaux de neurones pour prédire la probabilité qu'un apprenant réponde correctement à la prochaine question, est publié et reproduit largement depuis 2015. Vous pouvez implémenter une version sérieuse de cette couche sans toucher à un modèle de fondation.

La deuxième couche, c'est l'IA générative, et c'est là que les grands modèles de langage trouvent leur place. Ils excellent à produire du contenu et du feedback à grande échelle : rédiger des questions d'entraînement rattachées à une compétence, générer les distracteurs d'un QCM, expliquer une mauvaise réponse en langage clair, ou résumer la semaine d'un apprenant. Ils sont faibles dès qu'il faut noter de manière fiable une réponse ouverte, ou produire quelque chose qui doit être exact sans relecture humaine.

Un découpage concret pour un premier build : confier à du ML classique la décision de quoi montrer ensuite, et réserver le LLM à la génération et à l'explication de contenu, sous revue. La partie qui doit rester prévisible le reste, et la génération sert là où une erreur coûte peu et se corrige vite. Pour intégrer proprement cette couche dans votre stack, c'est le cœur de tout projet d'intégration d'IA.

Avant de construire, regardez ce qui existe déjà : une partie se rachète ou s'intègre au lieu de s'écrire.

Les plateformes d'apprentissage adaptatif établies se rangent dans quelques catégories. Il y a les systèmes de courseware complets, utilisés dans le supérieur et le scolaire, qui possèdent le contenu et le moteur de bout en bout. Il y a les applis de langues et de compétences qui ont bâti leur propre adaptativité autour d'un domaine étroit. Et il y a les fournisseurs de moteur seul ou de composants, qui exposent le suivi des connaissances ou la sélection d'items via une API : vous fournissez le contenu, ils fournissent les maths.

Pour un MVP, la question construire ou intégrer dépend de l'endroit où se situe votre différenciation. Si votre avantage tient au contenu, à votre méthode pédagogique, à votre conception des évaluations, à vos données sur une population d'apprenants précise, alors construisez un moteur léger et investissez votre énergie dans le contenu. Si votre avantage tient au moteur lui-même, une façon plus fine de modéliser les connaissances, alors vous construisez la partie difficile et vous ne devez pas gaspiller votre trésorerie à recréer un outil de création de contenu que vous pourriez licencier.

La plupart des fondateurs que nous accompagnons sont dans le premier cas. Leur technologie d'apprentissage adaptatif est un moyen de transmettre une intuition pédagogique, pas le produit en soi. Cela pointe vers un petit moteur que vous possédez plutôt qu'une plateforme lourde à plier à vos besoins.

Un MVP n'est pas une version réduite du produit final. C'est la plus petite chose qui prouve votre pari central. Pour un produit adaptatif, le pari est souvent : personnaliser le parcours améliore-t-il réellement l'apprentissage ou l'engagement de nos utilisateurs, comparé à un parcours fixe ?

Pour le tester, il vous faut une matière, un type d'apprenant et une boucle complète. Choisissez un seul domaine de compétences où vous pouvez écrire ou générer disons 80 à 150 items bien étiquetés, répartis sur quelques niveaux de difficulté. Construisez le cycle en quatre étapes décrit plus haut sur ces seuls items. Laissez de côté le multi-matières, les tableaux de bord enseignants, la gamification et les intégrations tant que la boucle ne les a pas mérités.

Une discipline utile : lancez une comparaison A/B dès le premier jour. La moitié de vos utilisateurs reçoit le parcours adaptatif, l'autre moitié une séquence fixe et raisonnable. Si l'adaptativité ne fait pas bouger votre métrique clé (complétion, maîtrise, rétention), vous avez appris quelque chose de bien plus précieux qu'une fonctionnalité soignée, et vous l'avez appris à moindre coût.

C'est ici qu'un modèle à périmètre et budget fixes aide vraiment. En EdTech, la tentation est d'ajouter sans cesse des matières et des rôles, parce que chaque pédagogue veut une chose de plus. Verrouillez le MVP sur une boucle, une cohorte, une métrique, et livrez en quelques semaines. Vous étendrez une fois que de vrais apprenants vous auront dit que le moteur mérite d'être étendu. Si le moteur doit ensuite s'insérer dans un système plus large, une feuille de route vers un logiciel sur mesure évite que le MVP léger ne devienne une impasse.

Le modèle de données, c'est là que les produits adaptatifs réussissent ou échouent en silence. Bien le poser tôt, et ajouter des matières plus tard devient simple. Le rater, et vous reconstruisez de zéro au pire moment.

Commencez par un graphe de compétences, parfois appelé carte des connaissances. Listez les compétences distinctes que votre contenu enseigne et les liens de prérequis entre elles : on ne fait pas de division posée avant de savoir soustraire des chiffres seuls. Même une liste plate de 20 à 40 compétences avec quelques flèches de prérequis suffit pour démarrer, et c'est l'ossature dans laquelle le modèle de l'apprenant vient écrire.

Chaque item de contenu (une question, une vidéo, une lecture) a besoin de métadonnées : la ou les compétences qu'il touche, sa difficulté, son type, et la bonne réponse avec ses variantes acceptables. Cet étiquetage est le travail ingrat qui rend tout le reste possible. Un item non rattaché à une compétence, c'est un item sur lequel votre moteur ne peut pas raisonner.

Vient ensuite la donnée d'interaction : le journal de chaque réponse (apprenant, item, compétence, résultat, horodatage, temps passé, indices utilisés). Ce journal, c'est la mémoire de votre produit et vos futures données d'entraînement. Stockez-le proprement dès le premier jour, même si vous n'en faites rien pour l'instant : reconstituer l'historique d'un apprenant après coup est impossible.

Côté conformité, l'EdTech touche souvent des mineurs et des dossiers scolaires : prévoyez-le tôt plutôt que de le rajouter en catastrophe. Des cadres comme le RGPD en Europe, ou FERPA et COPPA aux États-Unis, fixent des attentes sur les données des élèves, le consentement parental et la minimisation de ce que vous collectez. Ce sont des informations générales, pas un avis juridique ; faites appel à un conseil qualifié pour votre produit et vos marchés. Le point d'action côté build est concret : ne collectez que les données dont votre boucle a besoin, gardez-les séparables par apprenant, et concevez la suppression dès le départ.

Quelques schémas coulent les MVP adaptatifs, encore et encore.

Le manque de contenu est le plus fréquent. L'adaptativité a besoin d'assez d'items par compétence, sur assez de niveaux de difficulté, pour avoir quelque part où envoyer l'apprenant. Si vous avez huit questions sur une compétence et que le moteur veut en proposer une plus facile après une erreur, il n'a rien à donner. Les fondateurs sous-estiment largement le volume de contenu, puis accusent le moteur.

Le démarrage à froid arrive en deuxième. Quand un apprenant débarque, vous ne savez rien de lui, donc votre modèle n'a rien sur quoi agir. Un court diagnostic, ou des valeurs par défaut raisonnables qui supposent un niveau moyen et s'ajustent vite, règle la question, dans le même esprit qu'un bon accueil des nouveaux utilisateurs. L'ignorer, c'est rendre la première session, celle qui décide si la personne reste, la moins adaptative de toutes.

La sur-ingénierie du moteur arrive en troisième, et elle séduit les fondateurs techniques. Un modèle profond de suivi des connaissances par réseau de neurones est intéressant, mais il lui faut des données de milliers d'apprenants pour battre un modèle simple. Avec zéro utilisateur, le modèle simple gagne : il marche et vous pouvez le déboguer. Construisez la version sophistiquée quand les données la justifient.

Enfin, méfiez-vous d'optimiser la mauvaise métrique. Un moteur qui maximise les bonnes réponses peut rendre le travail trop facile et n'enseigner rien. L'adaptativité doit viser l'effort productif, cette bande de difficulté où l'apprenant est mis à l'épreuve mais réussit assez souvent pour rester engagé. Choisissez-la comme cible avant de régler quoi que ce soit.

Si vous êtes au stade de l'idée, posez sur le papier votre graphe de compétences pour une matière et l'unique métrique qui prouverait que l'adaptativité en vaut la peine. Ce document vaut plus que n'importe quelle décision technique en ce moment, parce qu'il vous force à nommer le pari.

À partir de là, le chemin est court : étiquetez un petit fonds de contenu, implémentez un modèle de l'apprenant simple, branchez une politique de sélection à base de règles, journalisez tout, et mettez le résultat devant de vrais apprenants avec une comparaison A/B. C'est un vrai produit adaptatif, et il tient dans un build de quelques semaines plutôt que de plusieurs trimestres. La modélisation plus fine et le programme plus large viennent après que la boucle a fait ses preuves, financés par les données que ces premiers apprenants génèrent. Avancer vite sur ce premier socle, sans sacrifier la qualité de la boucle, est exactement ce qui fait la différence entre un MVP qui apprend quelque chose et un projet qui s'enlise.