Depuis quelques mois maintenant, je travaille dans un centre de recherche en pédagogie. J’ai été engagé pour travailler sur un projet européen nommé PALETTE. Ce projet – pour le résumer grossièrement – tente de mettre en place / construire / développer des logiciels pour faire émerger des communautés de pratique médiatées dans des contextes d’apprentissage. Belle idée, s’il en est ! D’autant que le projet partait sur des bases libristes.

La mise en place d’un tel projet s’avère quelque peu plus difficile. Outre les problèmes de communication habituels liés à la gestion d’un large réseau social de chercheurs européens, le projet se confronte régulièrement à des obstacles de fond mettant en cause la compréhension de certaines notions clefs.

Ce fût, dans un premier temps, la notion d’outil (tool) qui posa des problèmes. Du point de vue d’un informaticien, un outil, c’est – dit grossièrement – un logiciel. Du côté des pédagogue, c’est moins simple. Il s’agit alors là non seulement d’un logiciel (au sens de technologie), si l’on parle de dispositifs d’apprentissages médiatés par exemple, mais il peut s’agir aussi d’outil pédagogique. Le terme outil, dans le sens d’outil pédagogique, peut être utilisé pour simplement nommer le support papier d’un cours, que pour parler des références bibliographiques, ou encore des simples concepts.

Comme vous pouvez vous l’imaginer, cela conduit assez rapidement à des discussions ubuesques dans lesquelles chacun pense que sa compréhension de la notion fait l’unanimité, ou alors (et c’est parfois pire), est persuadé que son interlocuteur fera de lui-même l’effort de traduction.

Après s’être confronté à quelques-unes de ces incompréhensions, on arrive à la conclusion que le partage d’un référentiel commun va être un des objectifs sous-jacents du projet de recherche. Dans le cas particulier de la notion d’outil, la solution adoptée après maintes et maintes discussions sur le sujet, fût de garder uniquement le terme outil lorsqu’il était nécessaire en temps que concept générique, mais de le troquer contre ceux de fonctionnalités / propriétés / services lorsqu’il s’agissait de jouer avec. Un premier obstacle était franchi, et jusqu’à aujourd’hui, il nous a permis de produire des rapports de projet qui fondent l’accord entre les partenaires.
Plus tard, mais de manière encore plus flagrante et problématique, c’est la notion de scénario qui posa des problèmes d’intercompréhension.

La notion de scénario

Un scénario, dans le langage commun désigne “un déroulement planifié ou prévu des événements”. Le terme couvre plusieurs réalités. On peut parler de scénario dans un sens de prévision, de projection ou d’évaluation prospective, ceci dans un contexte cinématographique, théâtral, romanesque ou pourquoi pas pédagogique. Les supports de scénarisation sont eux aussi différents : tandis que les météorologues vont rechercher des cartes prises par satellite pour en faire des projections empiriques, certains informaticiens font de l’UML afin de scénariser l’utilisation de leur outil (sic). Cela ne nous dit pas en quoi ces différentes manières de faire peuvent être compatibles, opposées, concurrentes ou parallèles. Soyons donc plus concret.

Si l’on considère un dispositif technique simple, comme ce toboggan pour enfant, et qu’on décide de travailler dessus afin d’élaborer un scénario. Plusieurs options sont possibles en fonction du point de vue à partir duquel on se place :

• Un ingénieur / développeur expliquerait que son dispositif permet à un être vivant composé de deux membres porteurs de grimper les marches (construites d’un matériau capable de supporter un poids maximum de 60 kilogrammes) afin de se retrouver à une hauteur suffisante à même de procurer l’inertie nécessaire au corps pour descendre sur la piste glissante.

• Un sociologue des techniques prendra comme point départ les manoeuvres des actants en présence (que ceux-ci soient humain ou non-humain) afin d’en étudier les limites d’action et par là-même les contraintes artefactuelles. En aucun cas, il ne se permettra de mettre en cause le dispositif technique, et encore moins l’ontologie des acteurs humains. Sa vision, contrairement à celle de l’ingénieur, sera exclusivement descriptive (au mieux, il fera de l’évaluation prospective).

• Le pédagogue quant à lui, aura un point de départ opposé. Alors que l’ingénieur développe un dispositif technique en fonction d’une suite d’actions imaginées ; le pédagogue, par contre, ne réfléchit en terme d’actions qu’à condition que ces dernières aient une finalité autre que les actions elles-mêmes. Ainsi, un scénario pédagogique prendra en compte l’utilisation du dispositif technique non pas en lui-même mais à des fins d’apprentissage qui elles-mêmes dépassent l’activité d’utilisation. Le psychomotricien considérera le toboggan en tant que dispositif permettant à l’enfant en bas âge de prendre connaissance de ses mouvements et de son poids afin qu’il développe des aptitudes physiques.

La question à résoudre, consiste à savoir si l’ingénieur / développeur a besoin de l’aide du pédagogue pour faire fonctionner son toboggan et si inversement le pédagogue a besoin de connaître toute l’ingénierie technique du développeur pour élaborer des scénarios d’apprentissage y afférant. La question est évidemment oui, sinon, l’intérêt d’un projet comme PALETTE, n’aurait même pas lieu d’être. Mais il s’agit de savoir ou et à quel moment doit intervenir la jonction entre les points de vue. On peut imaginer trois situations contrastées :

• Soit l’on considère qu’il faut que les dispositifs techniques soient développés et terminés pour que le pédagogue y mette son nez. On demande ainsi à l’ingénieur des façons idéales d’utiliser leurs outils et le pédagogue vient ensuite construire des scénarios pédagogiques autour des scénarios idéaux prédéfinis par les developpeurs. Dans ce cas, le rôle du pédagogue consiste au mieux à donner quelques recommandations aux développeurs en fin de process (d’ordre ergonomique ou d’accessibilité).
• Soit, l’on considère que le travail de conception doit se dérouler de manière collaborative dans le respect consensuel tant des impératifs techniques que pédagogiques. On travaille alors par co-construction avec des allers-retours permanents entre les scénarios des différents acteurs-concepteurs. Dans ce cas de figure, on parle de méthodologie utilisant un développement agile ou en spirale. Vous comprendrez que ce sont ces tendances qui ont le plus de succès (du moins dans la vision des lanceurs de projet et du point de vue théorique).
• Dans une dernière hypothèse, les ingénieurs ont besoin dés le départ des recommandations des pédagogues. Cela suppose que les pédagogues aient préalablement des scénarios idéaux pour l’apprentissage et des idées très précises sur la manière dont ce dernier doit être conçu.

Jusqu’à présent, je n’ai pas trouvé de solution à cette problématique. La seule conclusion que je peux tirer est la suivante : il me parait inconcevable qu’en abordant dés le départ les scénarios de deux points de vue divergents (que sont ceux des ingénieurs et ceux des pédagogues), on arrive à une conciliation.