À la fin des années 1960, à l’université McMaster de Hamilton, au Canada, les enseignants de médecine avaient un problème que beaucoup d’entre nous reconnaîtront sans être médecins. Leurs étudiants savaient leurs cours. Ils récitaient les mécanismes, les classifications, les protocoles. Devant un patient réel, avec une plainte mal formulée et des examens incomplets, ils ne savaient plus par où commencer. Le savoir était là. Il ne se mettait pas en mouvement.
Le curriculum de 1969 a tranché d’une façon encore contre-intuitive aujourd’hui : on a cessé d’empiler les disciplines avant d’exposer les étudiants à la clinique. On les a placés d’abord devant des situations, assez tôt pour que le cours ne puisse plus servir de mode d’emploi. Les connaissances venaient ensuite, cherchées parce qu’elles manquaient pour ce patient, cette incertitude. C’est l’origine de l’apprentissage par problèmes, l’APP, parfois appelé PBL. Tout le reste, y compris les versions édulcorées qu’on croise dans nos maquettes, vient de cette inversion.
Ce que Barrows a refusé de laisser flou
Howard Barrows, qui a beaucoup formalisé le modèle après McMaster, a passé une partie de sa carrière à répéter une chose que les catalogues de « pédagogies actives » ont tendance à oublier. Un problème d’APP n’est pas un exercice habillé en récit. Il est mal structuré : plusieurs pistes sont défendables, des informations manquent, et la « bonne réponse » n’est pas cachée au troisième paragraphe. Si l’étudiant peut réussir en reconnaissant le chapitre du semestre, vous avez réécrit un TD.
C’est aussi pour cela que Maastricht, aux Pays-Bas, a donné une forme opératoire à la séance, le « seven-jump ». On clarifie les termes, on définit le problème, on l’analyse, on formule des questions d’apprentissage, on va chercher, on revient, on synthétise. La séquence n’est pas une liturgie à recopier. Elle existe pour une raison très concrète : un groupe, livré à lui-même, saute à la solution. Il débat d’une option avant d’avoir nommé ce qu’il ne sait pas. Le cycle force ce détour.
L’APP a ensuite quitté la médecine, assez vite, parce que le constat n’était pas médical. Il était professionnel. En ingénierie, en gestion, en droit, en formation des enseignants, on retrouve la même scène : l’étudiant qui a suivi, qui a une moyenne, et qui se fige dès que l’énoncé ne dit plus quel outil utiliser. En France, on le croise dans les facultés de santé, dans certains IUT, dans des écoles qui ont besoin que quelqu’un tienne une situation plutôt qu’une leçon. Jacques Tardif, en parlant de familles de situations plutôt que de cours bien suivis, décrit à peu près le même déplacement. L’APP est une manière de fabriquer ces situations assez tôt pour que l’étudiant soit obligé de chercher.
Il vaut mieux le distinguer de deux cousins qu’on lui substitue souvent. L’étude de cas arrive fréquemment après la théorie, comme une illustration. L’apprentissage par projet s’étire dans le temps et vise un livrable. Les trois peuvent se parler. Ils ne font pas le même travail. L’APP commence par un problème qu’on n’a pas encore les moyens de résoudre.
Pourquoi s’en donner la peine
Le bénéfice le plus intéressant n’est pas l’engagement, même si une séance bien lancée est plus vivante qu’un cours qui précède un cas. C’est le rapport au savoir qui change. On n’apprend plus pour restituer une leçon. On apprend parce qu’un trou bloque le groupe, et que sans ce trou le travail s’arrête. Le magistral n’est pas interdit. Il arrive au moment où la question existe déjà, ce qui n’est pas du tout la même écoute.
Il y a aussi le transfert, celui qu’on mesure mal en QCM et qu’on voit trop bien en stage, en clinique ou en SAÉ. Savoir que Porter existe, ou qu’une procédure de sécurité existe, ne dit pas si l’étudiant saura s’en servir quand personne n’aura écrit le nom de l’outil dans l’énoncé. L’APP rend cette épreuve banale, dès le semestre, au lieu de la réserver au monde professionnel.
Le groupe, enfin, cesse d’être un découpage de rapport. Formuler le problème ensemble, se répartir des recherches, revenir avec des sources et défendre une piste contre une autre, c’est un autre métier que coller trois parties bout à bout la veille. Une partie de ce métier consiste simplement à nommer ce qu’on ne sait pas, à aller le chercher, puis à le rapporter sans noyer les autres. Cette habitude-là survit au module. C’est probablement ce que Barrows attendait le plus de ses étudiants de médecine.
Rien de tout cela n’est garanti par l’étiquette. Les travaux sur l’APP sont plus prudents que les brochures : l’effet dépend des conditions. Un problème trop fermé redevient un exercice. Un tuteur qui, au bout de vingt minutes, ne supporte plus le silence et livre la solution, referme le dispositif. Un groupe de quinze, sans rôle et sans regard sur les contributions, produit deux personnes qui travaillent et une galerie. L’APP n’est pas une méthode magique. C’est une discipline de conception.
Tenir un semestre, pas une séance démonstration
Le vrai travail, avant l’outil, c’est d’écrire le problème. Une situation ancrée dans le métier visé, avec un client, un patient, une collectivité ou une équipe pressée, des données incomplètes, parfois contradictoires, et plusieurs actions défendables. Assez de friction pour que le cours ne suffise pas, pas assez pour que le groupe se perde et attende d’être sauvé.
« Appliquez les cinq forces de Porter à cette entreprise » n’est pas un problème. L’outil est déjà nommé, l’étudiant exécute. Une PME qui perd des parts, un dirigeant qui veut une décision pour lundi, des chiffres partiels et un concurrent qui change de modèle, ça en est un. Porter peut arriver. Il n’est plus le titre de la feuille.
Le tuteur, dans ce cadre, n’enseigne pas le problème. Il relance : qu’est-ce qui est un fait, qu’est-ce qui est une hypothèse, qu’iriez-vous chercher ce soir. Il accepte un inconfort que le cours magistral nous évite, celui de ne pas clore trop tôt. Les groupes restent petits, six à huit si l’on suit Maastricht, non par folklorisme mais parce qu’au-delà quelqu’un disparaît. En amphi de 80, on ne fait pas un APP de 80. On fait plusieurs groupes sur le même problème, et on accepte de piloter un rythme plutôt qu’une performance unique.
Sur un semestre, il n’est pas nécessaire de jeter la maquette. Il faut un cycle que les étudiants voient : le problème en séance, assez longtemps pour formuler des questions d’apprentissage ; un temps de recherche ; un retour sur ce qui a été trouvé et ce qui reste flou ; un livrable intermédiaire, clairement distinct du rapport final ; un regard extérieur, pairs ou enseignant, tant que le groupe peut encore changer d’avis ; puis seulement une synthèse, une défense, une décision. Si la seule chose que vous notez est le fichier de fin, ils feront ce qu’ils savent déjà faire, un document propre, écrit trop tard, éventuellement par une IA. C’est le même diagnostic que Barras et Sarrasin posent pour l’évaluation en général, et il est encore plus net ici : le problème étant mal structuré, une IA produit volontiers une solution lisse. Elle ne vous dira pas comment le groupe a cherché, tranché, ou abandonné une piste.
Deux habitudes aident à tenir ça. Dire avant le travail ce qui sera regardé (le questionnement, les sources, la réponse à un retour, la contribution de chacun, l’usage de l’IA s’il est autorisé), parce qu’un APP flou sur l’évaluation dégénère en négociation de note. Et séparer franchement les cycles formatifs, où l’on a le droit de se tromper, du moment certificatif. Si chaque étape pèse sur la moyenne, le groupe arrête d’explorer.
Là où une plateforme change la charge, pas l’idée
L’APP échoue rarement sur le papier. Il échoue sur la logistique, surtout passé 60 ou 80 étudiants : qui a rendu le questionnement, qui a lu le livrable intermédiaire, qui a disparu du groupe, où est le retour avant la synthèse. Sans ça, on revient aux tableurs, et le tuteur passe son temps à reconstruire le film au lieu de relancer le raisonnement.
ChallengeMe sert à ça, pas à « faire de l’APP à votre place ». Vous pouvez scénariser le parcours (questionnement, recherche, version, regards croisés, défense) avec une date et une grille à chaque étape, de sorte que la timeline soit lisible pour vous et pour eux. Les pairs peuvent relire le raisonnement plutôt que le vernis du livrable, comme dans l’expérimentation d’Antoine Chollet. L’intra-groupe rend visible, dès la troisième semaine, le passager clandestin qui est le poison classique de ces dispositifs. Un assistant, calibré par vous sur les erreurs que vous voyez revenir, peut challenger une première analyse sans donner la solution, sur le même principe qu’Amathilde Labez à Montpellier Management : le retour arrive tant que le groupe peut encore s’en servir. Un journal réflexif, de son côté, garde souvent plus de traces utiles que le fichier final, parce qu’il force à dire pourquoi une piste a été prise puis laissée.
Dans tous les cas l’enseignant reste le juge. L’IA propose, les pairs commentent, la validation reste humaine. On n’est pas loin, alors, de ce que Tardif décrit pour l’évaluation des compétences : l’APP fournit la situation, encore faut-il évaluer le processus qui s’y déploie, et pas seulement la photographie du dernier jour.
Si vous voulez essayer sans tout reconstruire, partez d’un cours que vous connaissez déjà. Écrivez un seul problème, mal structuré, ancré dans le métier, et retirez le cours qui le précède, quitte à le remettre après la première recherche, ou à ne pas le remettre si le groupe a trouvé. Le signal est assez simple. Quand les étudiants parlent de ce qui leur manquait, vous tenez un APP. Quand ils demandent encore de quelle partie du cours il s’agissait, vous avez probablement réécrit un TD.
Envie d’essayer ChallengeMe ?
Demander une démo