A la recherche des feedbacks des apprenants

Mars 2020, pour raisons sanitaires, le gouvernement français a fermé ses universités, générant un usage accru des systèmes d’informations (SI) dans l’enseignement. Des modalités pédagogiques du type « ex cathedra » (Freinet, 1964, Inv. n° 16) se trouvèrent encapsulés dans des SI tels que Zoom ou Discord. Une situation rappelant le basculement historique du théâtre vers le cinéma. Dans ce contexte, la prise en compte des réactions des étudiants et des enseignants questionne. Où retrouver les mains levées du passé, les froncements de sourcils, les sous-entendus d’un enseignant ? Au-delà du constat du silence microphonique et de l’obscurité digitale que rencontrent les enseignants, se pose la question de l’engagement des étudiants : « Quand le prof parle, j’éteins ma caméra et je fais ma vaisselle » titrait la presse. La digitalisation d’une pédagogie ex cathedra serait-elle alors insatisfaisante ? Question d’autant plus pertinente que cette transformation s’inscrit à une période contemporaine où l’utilisation des jeux vidéo est maintenant le fait de la majorité de la population française.  Cependant, si le jeu vidéo, média non narratif, riche en interactivité et feedbacks s’est installé avec constance dans les chaumières, il n’est disponible que de façon marginale à l’Université, sous forme de jeux sérieux. Que ce soit, à l’aide d’une diapositive digitale ou d’un serious game, existe cependant le même besoin de tenir compte des feedbacks des étudiants et des systèmes qu’ils utilisent dans un cadre distancié. Le COVID-19 problématise la nécessité pour les instances enseignantes de maîtriser les feedbacks d’acteurs ou de joueurs apprenant par l’intermédiaire de SI.

Le bug, un exemple de feedback coûteux

Le jeu vidéo appartiendrait à la famille des SI (Cowley, 2008, p. 2) et la présence des feedbacks dans ces SI est clairement exprimée par le game designer Daniel Cook. Celui-ci parle d’atomes de compétences d’un jeu vidéo (Cook, 2007, p.3). Les ingrédients individuels d’un atome de compétence incorporeraient action du joueur, simulation et feedback du système et enfin, la modélisation mentale du joueur. Autant dire que l’atome de compétence est une interaction entre joueur et SI. Ajoutons que la notion de feedback est une transformation qui entraine, par rétroaction, au moins une seconde transformation (Ramaprasad, 1983 p.4). Dans ce contexte, le terme bug, couramment employé en développement SI, peut-il dans un jeu vidéo, se penser comme une rétroaction entre un utilisateur et un système, puis au-delà, entre cet utilisateur du système bogué et une organisation responsable du système ? Si l’on considère le premier bug répertorié de l’histoire, qui a donné son nom aux autres, l’insecte enregistré le 09/09/1947 à 15H45, conservé sous adhésif dans un cahier de maintenance d’un SI du type Mark II avec l’inscription : « Premier cas réel de détection d’un bug » (Kidwell , 1998, p. 5), la réponse est doublement « oui ». Nous sommes bien en présence d’une rencontre malencontreuse entre un insecte volant et un système en fonction (deux transformations en cours), il s’agit alors bien d’un écart entre une situation réelle (une panne) divergente d’un état de référence (un système qui fonctionne) et d’une modification rétroactive de cet écart par une organisation (une intervention de maintenance entrainant à nouveau une transformation). Le bug fait donc partie des feedbacks possibles en SI et l’analyse de la capacité d’une organisation à gérer des bugs est indicative des difficultés inhérentes à l’organisation d’une ingénierie des feedbacks. Pour plus de simplicité, nous proposons dans cet article que bugs et feedbacks puissent se gérer de façon équivalente.

Que se passe-t-il lors d’un feedback défaillant, notamment un bug de jeu vidéo ? On peut facilement concevoir que la rétroaction du joueur – c’est-à-dire son comportement – se modifie mais, qu’en est-il de l’organisation associée au jeu, entreprise ou Université en cas de jeux sérieux ? La première façon qu’aura une organisation de s’adapter, ressemblerait à un non-changement. « (…) La capacité de l’organisation à rester stable dans un contexte changeant dénote une sorte d’apprentissage » (Argyris, Schön, 1978, p. 18). Cette stabilité, s’incarnerait dans une réaction au changement par simple boucle. Vient ensuite, si besoin seulement, la double boucle (ib., p. 22), nécessitant de parvenir à « mettre fin aux processus auto-entretenus » de l’organisation (id., p. 17). On suppose qu’un bug soit une mauvaise nouvelle pour une organisation. Paul Carlile caractérise alors les passages d’informations – notamment les mauvaises nouvelles – au travers des cloisons d’une organisation. Il classe ces cheminements en trois groupes, respectivement nommés : transfert, translation et transformation (Carlile, 2004, p. 558). Le transfert de Carlile ressemble à la simple boucle d’Argyris et de Schön. Les processus de traduction et transformation de Carlile, indiquerait par contre un passage difficile d’une information au travers des cloisonnements d’une organisation. Le bug est à ce titre couteux, si le coût de correction d’un bug en SI durant sa phase de spécification coute 1, il coûterait de 5 à 10 durant le développement et les tests, de 10 à 100 après livraison (McConnell, 2005, p. 31). On le comprend, une organisation a alors des raisons d’ignorer un feedback qui ressemblerait à un bug.

Une gestion par AMDEC peu fiable

Les bugs sont majoritairement classés par niveau de score dans des SI nommés bug trackers (e.i. mantis , bugzilla …). Une proportion de 88% des bugs trackers identifiables sur internet fonctionnent comme une AMDEC (Kingston, 2020, p. 136). L’AMDEC (FMECA, standard MIL-STD-1629A) classe les bugs par une multiplication, au minimum, de scores associés à la fréquence et à la conséquence d’un bug (Rhee et al., 2003, p. 179). Deux scores subjectifs, ce qui entraine une fiabilité faible des classements de l’outil. La démonstration de ce manque de fiabilité a été faite par une équipe médicale, des chercheurs ont expliqués qu’une AMDEC utilisée par deux équipes montre une incohérence dans les résultats produits, « environ un tiers des modes de défaillance nécessitant des actions correctives nécessaires ont été communément identifiés par les deux équipes » (Oldenhof et al., 2010, p. 594). Une explication que nous proposons de cette non fiabilité de l’AMDEC, outil par ailleurs répandu sous la forme de bug trackers, consiste à suggérer que l’AMDEC serait principalement un support de négociation collective, un objet frontière. A ce titre, comme indiqué dans la figure 1, les décisions offertes par l’AMDEC nous semblent se résumer finalement à deux cas : une prise en compte ou une non prise en compte d’un bug et éventuellement d’un feedback lorsqu’on raisonne en termes d’ingénierie des feedbacks (annexe méthodologique).

Figure 1. Modele-organisationnel-dacceptation-dun-feedback

Le modèle organisationnel d’acception d’un feedback (MOAF) proposé ici est un modèle rétroactif dépendant (flèche (2)) d’une décision des acteurs d’une organisation qui n’ont pas nécessairement la connaissance ou le locus (Von HIPPEL, 2002, p. 826) d’un usage de jeu vidéo, jeu sérieux ou SI. Ils sont cependant impliqués dans le cycle de vie de cette réalisation humaine ou artéfact. Nous pouvons ainsi observer (flèches (4), (5) (7) et (8)) une rétroaction positive ou régulation d’un feedback ou observer (flèches (3) et (6)) une rétroaction négative ou amplification de l’effet d’un feedback. Le point de départ étant un bug, subséquemment aussi, un éventuel blocage cognitif estudiantin face à un feedback de jeu sérieux.

Notons que le MOAF ne prend pas en compte les doubles boucles dans les situations de traduction et transformation décrites par Carlile. En pareils cas, à savoir une interprétation difficile du bug (translation) et un besoin de transformation conceptuelle ou organisationnelle engendré par celui-ci, les parties prenantes n’ont peut-être pas d’autres choix que de ne pas réagir (flèche (3)). La marge de manœuvre organisationnelle est déterminée par l’objet frontière en bout de propagation d’un feedback, (flèches (1) et (2)). Par ailleurs, avec le MOAF, on perçoit l’importance d’une intégrité des données (flèche (2)). Anticiper, comprendre et réagir à un feedback devient alors la clef d’une régulation vertueuse d’un ensemble interactif combinant SI et organisation. Une ingénierie des feedbacks est cependant difficile à mettre en place. Nous avons en effet proposé à deux très petites entreprises (TPE) du domaine des SI de confronter les bugs connus de leurs SI avec des bugs trouvés par des étudiants. Nos résultats semblent alors montrer une difficulté à tenir compte formellement d’une chaine de propagation d’un feedback de SI (flèches (1) et (2)) et de réagir à cette information (flèches (3) et (6)). Ces recherches empiriques suggèrent que malgré l’abondance d’outils du type bug trackers, certains collectifs et projets peinent à tenir compte des feedbacks en provenance d’usagers finaux.

Fédérer les acteurs, définir les feedbacks prioritaires

Outre la « passivité » médiatisée des étudiants, nous avons aussi évoqué métaphoriquement « l’obscurité » et le « silence » que rencontrent les enseignants. Nous suggérons ainsi qu’élèves et enseignants manquent de feedbacks. Cependant, hormis les coûts financiers, une raison explicative d’une ludification lente des contenus pédagogiques a sans doute un lien avec la difficulté technique de concevoir conjointement le contenu thématique et le contenant technologique. La perspective d’une ingénierie du feedback dans le cadre du MOAF semble alors apporté un éclairage organisationnel des changements à venir. En effet, le développement d’outils de prise en compte des feedbacks des apprenants revient finalement à outiller une ingénierie des feedbacks de façon adéquate. Concepteurs et enseignants auraient un objet offrant la possibilité d’un langage commun et de négociations. De plus, la conception de cours devenant moins artisanale, celle-ci serait sans doute dupliquée, générant un effet de mutualisation du coût d’un cours avec SI. On perçoit aussi, qu’avec une montée en puissance des SI dans l’éducation, la valeur ajoutée enseignante s’intègre en amont du face-à-face avec l’apprenant, dans la conception, en aval, en accompagnement et enfin, complétement en aval, last but not least, dans l’analyse des feedbacks. Ainsi faisant, boucles de rétroactions avec le jeu et l’organisation conceptrice seraient conjointement contrôlées.

Les ressources d’une organisation et à plus forte raison d’une TPE ne sont pas illimitées. Une ingénierie tenant compte des feedbacks suppose la mise à disposition d’un outil de négociation permettant de définir des règles de priorités, une des fonctions principales de l’AMDEC qu’il s’agit de rendre paramétrable. La pertinence organisationnelle de cet outil ou objet frontière nous semble porter sur deux facteurs. D’une part l’outil de gestion des feedbacks à la différence d’un objet intermédiaire, (Vinck, 2009, p. 66) devra fédérer les parties prenantes hétérogènes d’une organisation. Un outil donnant trop d’importance à un acteur par rapport à un autre, ayant alors a priori, moins de chances d’être globalement accepté. En second lieu, la gestion des feedbacks doit permettre des règles modulables de définition des priorités de feedbacks pour permettre de faire avec les ressources disponibles d’une organisation donnée. C’est à ces conditions, que les SI assimilés à certains jeux sérieux amélioreront leur taux d’adoption pour approximer ceux que connaissent les jeux vidéo.