Cela dit, la plus-value de l’outil informatique comme moyen de construction de cours ne réside évidemment pas dans la plus grande souplesse d’usage d’un traitement de texte (versus l’écriture classique ou la machine à écrire). Elle tient plutôt à la possibilité d’insérer des fichiers en les téléchargeant, que ces fichiers soient porteurs de textes, de formes sonores ou d’images fixes ou animées. Autrement dit, pour qu’un dispositif de création de cours, non formé des supports concrets, soit réellement en adéquation avec une utilisation en situation ‘virtuelle’, il est nécessaire qu’il soit conçu de telle sorte que l’enseignant puisse ‘aller chercher sur le web’des ressources, mais aussi que l’enseigné puisse, lui aussi, éventuellement s’en servir pour explorer des bases de données afin d’y trouver des documents pertinents pour son apprentissage.

L’objet de cet article concerne la conception d’un outil multimédia qui a pour vocation de permettre la création d’un tel type de cours pour un enseignant dont le domaine disciplinaire est, en l’occurrence, l’automatique. Nous nous placerons en amont de l’usage effectif de l’artefact pédagogique en situation d’enseignement; nous étudierons une situation de ‘test’ d’un prototype de l’outil en question. C’est dire que nous nous intéresserons à une situation où le développeur et l’utilisateur agissent conjointement pour faire évoluer un premier état du prototype. Tel est le but qui préside à leurs échanges.

Dans un premier temps, nous décrirons précisément le dispositif informatique qui constituera l’outil mis à disposition de l’enseignant créant son cours. En décrivant finement la dynamique cognitive, nous analyserons, dans un second temps, l’apparition de cette irréversibilité qui conduit à ‘une bonne solution’pour le développement du prototype. Pour conclure, nous discuterons de la pertinence de ce type de mise en situation eu égard à la conception de tels outils virtuels, qui permettent d’envisager une nouvelle façon de thématiser la relation enseigné-enseignant.

Dans les premiers mois du projet [1] qui nous occupe ici, une base de données a été créée contenant des éléments relatifs au domaine d’expertise des enseignants concernés, les automaticiens. Elle est à disposition des concepteurs du prototype, elle contient des fichiers texte, son et image (fixe ou animée); c’est la BDL (Base de Données Locale). Tout fichier disponible sur internet devrait être également accessible et en lien avec le système. Le premier ensemble de fichiers est tel que l’utilisateur en connaît la teneur (organisation et contenu de tous les fichiers de la base de données locale); le second est tel qu’il ne peut en avoir de représentation exhaustive… et pour cause puisqu’il s’agit là de l’ensemble des fichiers présents sur le web et potentiellement aptes à répondre à ses attentes en matière de dépannage des systèmes automatisés ! Le statut différencié de ces deux ensembles documentaires dans la genèse de la construction du cours est évidemment très important. On le sent bien intuitivement et on verra par la suite que cette question est à l’origine de l’irréversibilité qui marquera la dynamique cognitive des acteurs de l’amélioration du prototype.

La séance dure une heure et trente minutes. DEV assis à droite de ENS décrit l’état du prototype. Il le fait en parlant et en manipulant la souris. Son activité manuelle consiste en un balayage intense de l’écran; il sélectionne, il pointe, il clique, il double-clique, il fait glisser, il fait dérouler. Autant d’actions qu’il accompagne de commentaires, de descriptions, d’éclaircissements et d’illustrations. La plupart du temps, on observe une concomitance thématique entre ses dires et ses déplacements à l’écran. Il arrive cependant qu’il parle d’un sujet alors qu’il agit à l’écran relativement à une question qui n’a pas de rapport immédiat avec ce sujet. De son côté, ENS, les yeux rivés sur tous les événements à l’écran, écoute, interrompt, questionne, s’étonne, commente, suggère. Il pointe sur quelques emplacements à l’écran avec le doigt ou la main mais jamais avec le curseur (il ne saisira jamais la souris au cours de la séance). La première demi-heure comporte une description détaillée des fonctionnalités de l’outil en son état, proposée par DEV à ENS qui, par un ensemble d’accords explicitement énoncés, montre qu’il comprend le travail réalisé. Rappelons que DEV a déjà longuement travaillé sur le prototype. Anticipant l’usage qu’un enseignant pourra faire de l’outil, il a déjà résolu un grand nombre de problèmes relatifs principalement à l’interface et à la souplesse de construction du cours. L’ensemble de l’outil est développé à partir de Microsoft® Word®.

On aura compris que c’est la mobilisation de ressources non intégrées à la partie écrite du cours qui constitue la plus-value du dispositif. Dès le début de la séance, DEV dit en parlant des liens : sachant que le contenu ça peut être n’importe où sur la planète (2’28”). Or il est bien évident que ni DEV, ni le créateur du cours, n’en ont une connaissance exhaustive. Il est donc question de réfléchir au mode de recherche de ce type de ressources. C’est précisément ENS qui va mettre ce sujet au centre de la discussion (et donc de l’activité conjointe d’amélioration du prototype). C’est un sujet d’une extrême importance dans le cadre de cette séance (nous sommes, au sein d’un projet ANVAR, en collaboration avec une entreprise qui veut vendre l’outil en cours de conception). C’est précisément sur ce point que portera notre analyse de l’activité conjointe. Voyons comment advient le traitement de ce sujet, crucial pour les acteurs.

Dans le cadre restreint de cet article il n’est pas question de faire une analyse approfondie, pas à pas, de l’ensemble du mécanisme conversationnel qui conduit les deux concepteurs à l’idée (et à sa formulation explicite) de prévisualisation [3]. Nous nous contenterons de relever plusieurs éléments. Il est clair que ENS constate, au long de la description que lui en a fait DEV, que l’outil en l’état a une faiblesse : il est nécessaire de connaître la base de données pour y rechercher une ressource. Or ceci ne peut convenir à ENS. D’où l’évaluation du caractère inutilisable de l’outil ! Grave critique s’il en est dont la formulation mérite d’être examinée. ENS ne la livre pas de front; il commence effectivement pas un simple “Ça va pas être facile” laissé en suspens par un “hein” et complété par DEV par l’usage du terme “utiliser”, lui-même validé par un “ouais”. Ainsi ENS et DEV sont-ils tous deux responsables de l’énoncé “ça va pas être facile de l’utiliser”, conjointement proféré. Cette constatation va être à nouveau exprimée avec force par ENS qui enfonce le clou à deux reprises : “sinon c’est inutilisable”, reformulé deux minutes plus tard par un “c’est impossible d’utiliser cela comme ça” devenu définitif … et ratifié clairement par DEV. En proférant “d’accord bon” au début de DEV9, DEV valide en effet ce qui devient ainsi quelque chose qui ne sera plus remis en question dans toute la suite de la séance. Mieux, DEV met en mots la compréhension qu’il a du ‘problème’relevé par ENS et qui le conduit à proposer le terme de prévisualisation, en le soulignant d’un “si tu veux” que ENS ne tarde pas à accepter. ENS soulève la question, DEV la prend au sérieux, les interlocuteurs en assurent conjointement la formulation. On relèvera que les statuts cognitifs et sociaux des deux acteurs à l’égard du dispositif sont clairement marqués par l’usage des pronoms personnels. Tout se joue lorsque ENS profère ENS4 et ENS5. ‘Je’, ‘On’et ‘Toi’désigne respectivement ENS, les enseignants utilisateurs potentiels et DEV. En disant cela, il marque que c’est son statut à la fois d’utilisateur et de découvreur de l’outil en l’état qui le conduit à pointer un manque dans sa conception actuelle. En substance, il dit à DEV qu’il a conçu l’outil en oubliant que d’autres (et en particulier les futurs utilisateurs premiers) ne connaissent pas le contenu de la BDL… et donc se heurteront à un problème de repérage des ressources qu’il est question d’importer grâce aux liens hypertextes (qui, rappelons-le, font la plus-value de l’outil). Autrement dit, la présence de l’utilisateur joue ici à plein pour un moment crucial de l’histoire de l’enrichissement de l’artefact au centre du processus de conception : l’identification d’une insuffisance notoire. Un peu plus tard, ENS a l’occasion de présenter de façon détaillée à DEV (qui là encore validera clairement) ce qu’il appelle son ‘problème’:

On aura pu observer que la formulation conjointe du problème s’est déroulée dans une séquence relevant plutôt de la génération de formes langagières. Certes, ce qui se passe à l’écran joue un rôle de médiateur entre les deux acteurs. Comme tout au long de la séance, ENS ne quitte pas les déplacements du curseur des yeux; par ailleurs il y a une simultanéité très forte entre les paroles et les actions de DEV. Lorsqu’en DEV5, le développeur dit “il faudrait il faudrait aussi faire en sorte que ici quand tu choisis un lien voilà tu choisis ça tu choisis ça que ici (inaudible) et que avant de sélectionner tu puisses dire je veux voir ce que c’est” [4], il manipule la souris. Il déroule un premier menu, sélectionne ‘ça’en disant “tu choisis ça”… qui ouvre un deuxième menu où il sélectionne ‘ça’en redisant “tu choisis ça”. Cette cascade est suivie précisément par ENS pour qui les antécédents des deux déictiques ‘ça’sont clairement identifiés. Lorsque DEV termine son intervention en énonçant “je veux voir ce que c’est”, il fait un geste de la main qui balaye l’espace vers le plafond, comme pour désigner l’ailleurs, un ailleurs virtuel renvoyant évidemment au réseau. ENS ne s’y trompe pas qui reformule un peu plus tard “donc ma solution c’est d’aller chercher sur internet les éléments” (ENS12). La souris, le curseur, l’écran supportent les référents concrets des formes langagières; ils constituent pour une part le sens des énoncés des interactants. Nous verrons cependant que le rôle constitutif de ces objets sera plus massif dans la production conjointe de la solution.

À cet instant, il reste aux acteurs à trouver un moyen de prévisualisation qui permettra à tout enseignant d’insérer dans le cours, en toute connaissance de cause, ce qu’il aura pu trouver sur internet.

Nous en sommes alors revenus à la prévisualisation dont les acteurs comprennent bien qu’elle est tout à fait inévitable. Depuis le début, les événements à l’écran étaient pour ainsi dire des illustrations du développement explicatif de DEV; c’est-à-dire que ce dernier appelait ces événements pour les besoins de son exposé. La situation de médiation sujets-artefacts se renverse alors tout à fait soudainement. Les paroles prononcées par les interlocuteurs vont être alors des commentaires de l’actualité de l’écran. Les circonstances vont les conduire à activer une fonctionnalité du logiciel (Microsoft^® Word^® ) non encore utilisée.

DEV15 révèle une grande hésitation de la part du développeur. Son intervention est truffée de négations (“je sais pas où”, “j’en sais rien”) de modalisateurs discursifs (deux ‘euh’, ‘peutêtre’) qui marquent le fait qu’il essaye, qu’il tâtonne, qu’il ne domine pas ce que l’écran va présenter à la suite de ses manipulations de souris. Il apparaît qu’il n’a pas essayé la fonctionnalité qu’il met en œuvre en DEV17. “C’est un peu le cas ici” le montre en pleine tentative, d’expérimentation. Une fenêtre apparaît alors à l’écran. C’est une boîte de dialogue; il s’agit plus précisément de la boîte d’insertion d’images de Microsoft® Word®. Elle saute aux yeux des acteurs. DEV énonce “à la limite ça serait même bien”… surprise marquée par ce conditionnel. ENS dit sa satisfaction immédiate; il utilise l’indicatif présent, “voilà c’est ça”. Le ‘même bien’est même immédiatement reformulé par DEV en ‘idéal’.

Contrairement à la première partie de la séance (qui a duré presqu’une heure), l’écran n’est plus l’artefact dont l’usage permet l’accompagnement des dires. Pendant une heure, DEV a exposé ce qui est en quelque sorte un assujettissement des événements de l’écran à sa conception du prototype. Quand je veux réaliser telle action, il se passera ceci à l’écran. Si cela ne se passe pas c’est que l’interface n’est pas encore au point. Cet exposé a débouché sur une insatisfaction pointée par ENS et sur une insuffisance co-exprimée par les deux acteurs de la conception. À partir de cet instant, l’écran ‘ne suivra plus’les instructions de DEV; et pour cause, il s’agit d’inventer une chose à laquelle il n’a pas pensé auparavant. Une manœuvre hasardeuse, presque fortuite (du type ‘on pourrait peut-être essayer ça’) provoque un état de l’écran qui va se révéler très vite déterminant. L’état de cet écran exhibe clairement une solution, la boîte d’insertion d’objets. Ce dispositif est tout à fait adéquat. Il s’agit, en effet, d’une fenêtre où les éléments à insérer apparaissent sous forme graphique à l’instar de l’aperçu avant impression bien connu. ENS ne s’y trompe pas qui claironne immédiatement “Voilà c’est ça”; mais qu’en est-il du développeur ?

On relève de très nombreuses traces de son adhésion à la solution dans son discours de la dernière demi-heure de la séance. Ces traces sont bien évidemment majoritairement d’ordre langagier. En voici quelques unes, toutes proférées par le développeur :

Ces formes langagières, dont la dernière n’est plus au conditionnel et qui traduisent clairement son accord, scandent un long commentaire où DEV montre en quoi cette boîte est pertinente. Tout se passe comme s’il acquérait cette conviction au cours de la glose associée à la fenêtre qu’il ne manque pas de manipuler abondamment pendant cette dernière demi-heure. On observe aussi un autre mode d’action qui montre son acceptation de l’issue de la discussion. Cette boîte de dialogue, d’insertion d’objets, reste plein cadre à l’écran sans en être effacée, pendant un long moment (16 minutes). Au bout de quatre minutes, il saisit cet objet virtuel de façon tout à fait significative. Comme on brandit en réunion un fascicule, un compte rendu, un document pour insister sur son importance dans la discussion en cours, comme on pointe en tapotant un transparent à l’endroit où réside la clé de l’exposé, comme on empoigne un outil pour montrer à autrui son caractère indispensable, DEV s’empare de la fenêtre comme pour en estimer la pertinence. Il le fait en manipulant la souris de façon saccadée et circulaire ce qui a pour effet un déplacement rotatif rapide de la fenêtre qu’il contrôle parfaitement. À cet moment précis (qui dure deux secondes), DEV dit cette chose tout à fait importante “Et l’outil c’est quasiment que ça, c’est que le bout là” (57’47”). En quelque sorte, c’est comme s’il agrippait cet objet, devenu la clé du processus de conception. D’une certaine façon, débordé par un dispositif qu’il avait conçu ‘à sa main’pour exposer l’état du prototype, DEV montre là une sorte d’appropriation de ce qui lui avait échappé. Le contrôle de cet état de choses, de cet artefact dont l’actualisation a été produite presque par hasard dans le monde matériel de l’interaction, passe par une possession virtuelle d’un objet virtuel.

C’est en tant qu’élément concret, perceptible, de l’environnement de l’interaction que cette fenêtre acquiert un rôle actif dans le processus de conception. Il s’agit là de ce que Vinck appelle un objet intermédiaire (Jeantet, 1998; Vinck, 1999). C’est en ce sens que nous disons que la dynamique cognitive est située, dans une perspective proche des propositions des sociologues de l’action située [5]. Par ailleurs, la coresponsabilité des acteurs relativement à ce processus nous conduit à parler également de cognition distribuée, distribuée sur les individus au centre du dispositif intersubjectif [6].

Il ne nous semble plus possible d’étudier les phénomènes intersubjectifs en faisant l’économie de la part non langagière de l’engendrement du sens en interaction. Il est nécessaire de prendre en compte la mobilisation des corps interagissant ainsi que celle de la matérialité ambiante, et en particulier les objets qui la composent. Le rôle des événements à l’écran, dans ce qu’ils ont de non actualisés intentionnellement, est majeur dans la prise de décision, dans la production d’une irréversibilité, dans la génération d’une construction conceptuelle. La fenêtre advenant à l’écran au cours du travail, de façon non programmée, supporte très effectivement et efficacement le devenir de la conversation; cette boîte d’insertion est la solution recherchée. Elle apparaît solution au sens où les fonctionnalités qu’elle présente répondent à l’insatisfaction de ENS et comblent les insuffisances du prototype de DEV. Ces fonctionnalités sont là sous les yeux des acteurs, elles sont agies au moyen de manipulations sur le monde concret (souris, écran), elles sont portées par l’artefact éminemment présent dans l’espace intersubjectif. Ancrée dans le monde des objets, la conception est située.

Ce type de mise en situation s’inscrit dans le mouvement de l’ingénierie que l’on dit concourante. Comme dans les autres corpus que nous travaillons [7], une dimension cruciale est là présente : la multi-expertise. Nous parions sur la plus-value d’une rencontre entre sujets cognitifs à expertises différenciées; plus-value obtenue par la mise en présence d’individus ayant des statuts, des histoires différentes par rapport au produit à concevoir. ENS a un savoir-faire et une histoire personnelle concernant la construction d’un cours d’automatique. De même, pour DEV à propos de l’élaboration d’un logiciel multimédia. En l’occurrence, ces statuts différenciés par rapport au produit à concevoir sont centraux dans la dynamique de création.

L’originalité de la démarche de conception que nous avons analysée réside d’une part dans le fait que l’usager futur de l’outil intervient très tôt dans le processus de son élaboration, et d’autre part, dans le fait que l’artefact est présent dans l’ici et maintenant de l’intersubjectivité mais aussi mobilisé effectivement lors de l’interaction développeur-utilisateur. La centration sur l’objet, enjeu des échanges, est centrale dans la conduite de l’analyse.